1. 項(xiàng)目概述為什么我們需要在Web端無插件播放H264/H265幾年前如果你要在網(wǎng)頁里播放一個(gè)視頻大概率會看到一行提示“請安裝Flash Player”。那個(gè)時(shí)代插件是繞不開的門檻。后來HTML5的video標(biāo)簽帶來了曙光但格式支持又成了新問題。時(shí)至今日H264AVC已經(jīng)幾乎成為網(wǎng)絡(luò)視頻的“普通話”而H265HEVC則因其更高的壓縮效率在4K/8K、低碼率直播等場景下越來越普及。然而當(dāng)你興沖沖地想把一個(gè)H265的監(jiān)控錄像或?qū)I(yè)攝像機(jī)素材在自家網(wǎng)頁上播放時(shí)瀏覽器很可能給你一個(gè)冷冰冰的圖標(biāo)告訴你“不支持此視頻格式”。這就是我們面臨的核心痛點(diǎn)瀏覽器原生解碼能力的局限性與日益增長的視頻編碼需求之間的矛盾。主流瀏覽器對H264的支持尚可但對H265的支持卻參差不齊尤其是在桌面端的Chrome、Firefox等出于專利、性能等多方面考慮并未默認(rèn)開啟H265的硬解支持。而“無插件”的要求則是為了極致的用戶體驗(yàn)和跨平臺兼容性用戶點(diǎn)開即看無需任何額外的安裝、授權(quán)或安全警告。所以“Web端無插件解碼播放H264/H265”這個(gè)命題本質(zhì)上是在探索如何利用現(xiàn)代Web技術(shù)在瀏覽器這個(gè)“沙箱”里自力更生地完成那些瀏覽器本身不太樂意或不能直接完成的高性能視頻解碼任務(wù)。這不僅僅是播個(gè)視頻那么簡單它涉及到流媒體協(xié)議、二進(jìn)制數(shù)據(jù)處理、WebAssembly性能榨取、GPU加速等一系列底層技術(shù)。接下來我們就深入拆解這里面的門道。1.1 核心需求與場景解析我們先明確一下哪些場景會強(qiáng)烈需要這個(gè)能力安防與監(jiān)控平臺這是需求最迫切的領(lǐng)域。?？?、大華等主流攝像頭的編碼格式正在從H264向H265快速遷移以節(jié)省存儲和帶寬。監(jiān)控平臺需要在一個(gè)Web后臺里同時(shí)預(yù)覽幾十上百路H265視頻流不可能要求每個(gè)運(yùn)維人員去安裝特定插件。在線教育/視頻會議為了在弱網(wǎng)環(huán)境下提供更清晰的畫面部分高端服務(wù)開始嘗試采用H265編碼。確保所有參會者或?qū)W生無論使用什么電腦、什么瀏覽器都能無縫接入。專業(yè)媒體管理與協(xié)作廣告公司、影視制作團(tuán)隊(duì)需要在網(wǎng)頁上審閱H265編碼的4K樣片進(jìn)行打點(diǎn)評論。文件可能來自專業(yè)攝影機(jī)編碼格式不可控。智慧物聯(lián)網(wǎng)與車聯(lián)網(wǎng)車載攝像頭、無人機(jī)回傳的視頻流為了高效利用無線信道常采用H265編碼。指揮中心的大屏需要Web化展示。通用視頻云服務(wù)像七牛云、阿里云視頻云等需要為客戶提供一種“萬能”的播放器SDK無論客戶上傳什么格式都能在客戶的網(wǎng)頁上穩(wěn)定播放降低客戶的使用門檻。這些場景的共同特點(diǎn)是格式不可控、終端環(huán)境復(fù)雜、對即時(shí)可用性要求極高。因此解決方案必須足夠“軟”完全依賴前端技術(shù)棧同時(shí)又必須足夠“硬”能實(shí)時(shí)處理高碼率、高分辨率的視頻數(shù)據(jù)。2. 技術(shù)路線全景圖從“指望瀏覽器”到“自力更生”面對H264/H265的播放難題我們有三條技術(shù)路線可選其依賴性和能力依次遞進(jìn)。2.1 路線一原生video標(biāo)簽與MSE這是最理想、最省力的方案前提是瀏覽器支持。原理利用HTML5的video標(biāo)簽并通過Media Source Extensions (MSE) API動(dòng)態(tài)喂入視頻數(shù)據(jù)。對H264幾乎完美支持。只要你的視頻封裝格式是瀏覽器兼容的如MP4 with AVC直接設(shè)置src屬性或通過MSE喂入fmp4片段即可。對H265這就是坑所在。支持情況極其碎片化Safari (macOS iOS)從某個(gè)版本開始已經(jīng)支持在video標(biāo)簽中直接播放MP4封裝的H265視頻MSE支持也相對較好。Edge (Chromium內(nèi)核)在Windows 10/11上如果系統(tǒng)安裝了HEVC視頻擴(kuò)展并且顯卡驅(qū)動(dòng)支持Edge可以硬解H265。但這依賴用戶系統(tǒng)環(huán)境。Chrome / Firefox (桌面端)默認(rèn)不支持。雖然內(nèi)核有能力但出于專利費(fèi)等原因默認(rèn)編譯選項(xiàng)關(guān)閉了H265解碼器。這是一個(gè)致命的“不可控”因素。優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)性能最佳硬解功耗最低實(shí)現(xiàn)最簡單。缺點(diǎn)對H265的支持不可控?zé)o法作為通用解決方案。你無法對用戶說“請先檢查你的Windows是否安裝了HEVC擴(kuò)展并更新顯卡驅(qū)動(dòng)。”實(shí)操心得在項(xiàng)目初期一定要用MediaSource.isTypeSupported(video/mp4; codecshev1.1.6.L93.B0)或hev1.1.6.L93.B0兩種常見的H265 codec字符串來檢測瀏覽器支持度。但這只能用于能力探測不能作為功能依賴因?yàn)椴恢С质浅B(tài)。2.2 路線二WebAssembly (Wasm) 軟解碼當(dāng)瀏覽器原生不給力時(shí)我們只能自己動(dòng)手豐衣足食。WebAssembly為我們提供了在瀏覽器中運(yùn)行接近原生性能代碼的能力。原理將用C/C/Rust編寫的高性能視頻解碼庫如FFmpeg的libavcodec編譯成Wasm模塊。在網(wǎng)頁中加載這個(gè)Wasm模塊將獲取到的視頻流數(shù)據(jù)如H.265 NALU單元傳遞給這個(gè)模塊進(jìn)行解碼。解碼輸出通常是YUV幀數(shù)據(jù)然后通過Canvas或WebGL進(jìn)行渲染。核心組件解碼器Wasm模塊這是核心。業(yè)界常用的是將FFmpeg中的H264/H265解碼部分單獨(dú)編譯。由于FFmpeg龐大需要精細(xì)配置編譯選項(xiàng)只保留必要的編解碼器以控制Wasm文件體積。數(shù)據(jù)源可以是HTTP-FLV、WebSocket傳輸?shù)穆懔饕部梢允峭ㄟ^MSE無法直接播放的MP4文件。需要前端自行解封裝提取出編碼幀。渲染器解碼得到的是YUV數(shù)據(jù)需要轉(zhuǎn)換為RGB才能在Canvas上繪制。純JavaScript轉(zhuǎn)換性能堪憂必須使用WebGL。編寫一個(gè)簡單的WebGL著色器Shader來完成YUV到RGB的轉(zhuǎn)換和縮放效率極高。優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)真正的全兼容。只要瀏覽器支持Wasm和WebGL就能播放無視瀏覽器自身的解碼能力。格式控制靈活甚至可以支持一些非標(biāo)變種。缺點(diǎn)性能消耗大軟解碼完全依賴CPU播放高清如1080p視頻可能就會吃滿一個(gè)核心更不用說4K。風(fēng)扇狂轉(zhuǎn)筆記本續(xù)航驟降。首屏延遲需要下載和初始化Wasm模塊可能好幾MB解碼流水線也需要時(shí)間啟動(dòng)。實(shí)現(xiàn)復(fù)雜度高需要處理音視頻同步、內(nèi)存管理、錯(cuò)誤恢復(fù)等一系列底層問題相當(dāng)于實(shí)現(xiàn)一個(gè)簡易播放器內(nèi)核。2.3 路線三WebCodecs API未來之星這是谷歌主導(dǎo)推動(dòng)的新一代瀏覽器底層編解碼API旨在為Web提供直接訪問媒體編解碼器的能力。原理它允許JavaScript直接創(chuàng)建視頻解碼器VideoDecoder和編碼器VideoEncoder對象。你可以直接把編碼后的數(shù)據(jù)塊EncodedVideoChunk塞給解碼器解碼器回調(diào)返回解碼后的視頻幀VideoFrame這個(gè)幀對象可以直接交給video標(biāo)簽或Canvas進(jìn)行渲染?，F(xiàn)狀截至我撰寫本文時(shí)WebCodecs已在Chrome、Edge新版中穩(wěn)定支持Firefox和Safari仍在實(shí)驗(yàn)或規(guī)劃階段。關(guān)鍵在于它允許瀏覽器調(diào)用其底層可能存在的硬件解碼能力。也就是說即使瀏覽器默認(rèn)不開放H265給video標(biāo)簽但只要系統(tǒng)有H265硬解能力通過WebCodecs API可能就能調(diào)用到。與Wasm方案對比WebCodecs可能走硬解路徑性能、功耗遠(yuǎn)優(yōu)于Wasm軟解。WebCodecs是瀏覽器API無需加載巨大的Wasm解碼庫啟動(dòng)更快。但兼容性目前不如Wasm方案Safari的支持是關(guān)鍵短板。優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)高性能可能硬解、低延遲、接口相對Wasm方案更簡潔。缺點(diǎn)兼容性仍是中期內(nèi)的挑戰(zhàn)并且API較為底層仍然需要開發(fā)者管理解碼隊(duì)列、幀緩存等邏輯。路線選擇策略 一個(gè)健壯的商業(yè)播放器通常會采用混合策略首先嘗試使用原生video MSE對于H264或特定環(huán)境下的H265。如果不支持檢測WebCodecs API可用性并嘗試用它創(chuàng)建H265解碼器。如果WebCodecs也不可用或不支持H265則降級到Wasm軟解碼方案。這樣能在支持硬解的環(huán)境下提供最佳體驗(yàn)在不支持的環(huán)境下通過軟解保證功能可用。3. 實(shí)戰(zhàn)構(gòu)建一個(gè)Wasm軟解碼H265播放器讓我們聚焦于最復(fù)雜但也最通用的Wasm軟解碼方案看看如何一步步實(shí)現(xiàn)它。這里我們以播放一個(gè)HTTP-FLV格式的H265直播流為例。3.1 環(huán)境準(zhǔn)備與工具鏈FFmpeg源碼我們需要從中編譯出libavcodec包含HEVC解碼器、libavutil等核心庫的Wasm版本。Emscripten工具鏈這是將C/C代碼編譯為Wasm的編譯器。確保安裝并配置好。前端構(gòu)建環(huán)境一個(gè)現(xiàn)代的JavaScript項(xiàng)目使用Webpack或Vite管理依賴和打包。我們將把編譯好的.wasm文件作為資源引入。編譯FFmpeg為Wasm 這是一個(gè)關(guān)鍵且繁瑣的步驟。目標(biāo)是最小化輸出體積。# 這是一個(gè)高度簡化的配置示例實(shí)際需要大量調(diào)優(yōu) emconfigure ./configure \ --prefix$(pwd)/dist-wasm \ --target-osnone \ --archx86_32 \ --enable-cross-compile \ --disable-x86asm \ --disable-inline-asm \ --disable-stripping \ --disable-programs \ --disable-doc \ --disable-avdevice \ --disable-avfilter \ --disable-postproc \ --disable-swresample \ --disable-avformat \ # 注意我們通常不需要libavformat因?yàn)榻夥庋b在前端JS做 --enable-decoderhevc,h264 \ # 只啟用我們需要的解碼器 --enable-parserhevc,h264 \ --enable-demuxerflv \ # 如果需要前端解封裝FLV可以啟用但通常用JS庫更簡單 --disable-encoders \ --disable-muxers \ --disable-filters \ --disable-protocols \ --disable-network \ --extra-cflags-Os \ --extra-cxxflags-Os \ --ccemcc \ --cxxem \ --aremar \ --ranlibemranlib \ --cpugeneric \ --disable-hwaccels \ --disable-debug編譯后我們會得到libavcodec.a,libavutil.a等靜態(tài)庫。然后我們需要寫一個(gè)C的“膠水”代碼暴露幾個(gè)關(guān)鍵函數(shù)給JavaScript調(diào)用create_decoder,decode_frame,destroy_decoder。3.2 前端架構(gòu)設(shè)計(jì)與數(shù)據(jù)流播放器的前端架構(gòu)可以分解為以下幾個(gè)模塊它們通過隊(duì)列或事件機(jī)制連接[ 網(wǎng)絡(luò)流 (HTTP-FLV) ] - [ FLV解封裝器 (JS) ] - [ 數(shù)據(jù)隊(duì)列 ] - [ Wasm解碼器 ] - [ YUV幀隊(duì)列 ] - [ WebGL渲染器 ] - [ Canvas ] | | | | | (Socket/ Fetch) (flv.js 或自研) (ArrayBuffer) (FFmpeg Wasm) (YUV-RGB Shader)流獲取與解封裝使用fetch或WebSocket加載FLV流。推薦使用成熟的JS庫如flv.js的流解析部分或者使用mux.js。它們的職責(zé)是從FLV容器中分離出視頻TagH265 NALU 時(shí)間戳和音頻Tag。我們將得到的視頻Tag一個(gè)包含NALU的ArrayBuffer放入一個(gè)“待解碼隊(duì)列”。Wasm解碼器模塊編寫一個(gè)DecoderWrapper類負(fù)責(zé)加載Wasm模塊管理解碼器實(shí)例的生命周期。它從“待解碼隊(duì)列”中取出ArrayBuffer通過Wasm模塊的內(nèi)存操作Module._malloc,Module.HEAPU8.set將數(shù)據(jù)拷貝到Wasm線性內(nèi)存中。調(diào)用暴露的decode_frame函數(shù)。這個(gè)C函數(shù)內(nèi)部會調(diào)用avcodec_send_packet和avcodec_receive_frame。解碼成功后C函數(shù)將YUV數(shù)據(jù)可能是Y、U、V三個(gè)平面從Wasm內(nèi)存中拷貝出來或者更高效地直接返回指向Wasm內(nèi)存中YUV數(shù)據(jù)的指針和描述信息寬度、高度、格式給JS。渲染模塊這是性能關(guān)鍵。我們不能在JS里用循環(huán)把YUV轉(zhuǎn)成RGB。創(chuàng)建一個(gè)WebGL上下文編寫一個(gè)片段著色器Fragment Shader專門用于將YUV420格式轉(zhuǎn)換為RGB。解碼器輸出一幀YUV數(shù)據(jù)后我們創(chuàng)建三個(gè)WebGL紋理分別對應(yīng)Y、U、V平面用gl.texImage2D上傳數(shù)據(jù)。在著色器中采樣這三個(gè)紋理按照YUV到RGB的轉(zhuǎn)換矩陣進(jìn)行計(jì)算輸出最終顏色。每解碼一幀就觸發(fā)一次WebGL繪制。3.3 核心代碼環(huán)節(jié)剖析JavaScript側(cè)解碼調(diào)用示例class WasmDecoder { constructor(module) { this.module module; // Emscripten模塊對象 this.decoderPtr this.module._create_decoder(/* codec_id */); } decode(dataArrayBuffer) { // 1. 分配Wasm內(nèi)存并拷貝數(shù)據(jù) const dataPtr this.module._malloc(dataArrayBuffer.byteLength); const wasmHeap new Uint8Array(this.module.HEAPU8.buffer); wasmHeap.set(new Uint8Array(dataArrayBuffer), dataPtr); // 2. 調(diào)用解碼函數(shù) // 假設(shè)我們的C函數(shù)返回一個(gè)結(jié)構(gòu)體指針包含解碼狀態(tài)、YUV數(shù)據(jù)指針等 const resultPtr this.module._decode_frame(this.decoderPtr, dataPtr, dataArrayBuffer.byteLength); // 3. 從結(jié)果結(jié)構(gòu)體中提取信息 const success this.module.getValue(resultPtr, i32); // 解碼是否成功 const yPtr this.module.getValue(resultPtr 4, i32); // Y平面指針 const width this.module.getValue(resultPtr 8, i32); const height this.module.getValue(resultPtr 12, i32); if (success) { // 4. 將YUV數(shù)據(jù)從Wasm內(nèi)存中“視圖”出來注意不是拷貝 const ySize width * height; const uvSize (width / 2) * (height / 2); const yData new Uint8Array(this.module.HEAPU8.buffer, yPtr, ySize); const uData new Uint8Array(this.module.HEAPU8.buffer, yPtr ySize, uvSize); const vData new Uint8Array(this.module.HEAPU8.buffer, yPtr ySize uvSize, uvSize); // 5. 將 yData, uData, vData 傳遞給WebGL渲染器 this.renderer.updateYUVTexture(yData, uData, vData, width, height); } // 6. 釋放分配的內(nèi)存 this.module._free(dataPtr); this.module._free(resultPtr); } }WebGL YUV渲染著色器核心片段著色器precision mediump float; uniform sampler2D yTexture; uniform sampler2D uTexture; uniform sampler2D vTexture; varying vec2 v_texCoord; void main() { // 采樣YUV三個(gè)紋理 float y texture2D(yTexture, v_texCoord).r; float u texture2D(uTexture, v_texCoord).r - 0.5; float v texture2D(vTexture, v_texCoord).r - 0.5; // YUV to RGB 轉(zhuǎn)換矩陣 (ITU-R BT.601) float r y 1.402 * v; float g y - 0.344 * u - 0.714 * v; float b y 1.772 * u; gl_FragColor vec4(r, g, b, 1.0); }3.4 音視頻同步與性能優(yōu)化單純的解碼和渲染是不夠的還需要讓播放“順滑”。音視頻同步解碼出的每一幀都有其解碼時(shí)間戳DTS和呈現(xiàn)時(shí)間戳PTS。我們需要一個(gè)基于PTS的同步時(shí)鐘。建立一個(gè)音頻播放線程使用Web Audio API作為主時(shí)鐘。視頻渲染根據(jù)當(dāng)前音頻時(shí)鐘來決定是立即顯示當(dāng)前幀還是需要等待幀率過快或是需要跳幀解碼過慢。這是一個(gè)復(fù)雜的邏輯簡單的實(shí)現(xiàn)可以先以視頻幀率為主但音畫不同步會很明顯。性能優(yōu)化關(guān)鍵點(diǎn)內(nèi)存零拷貝如上例所示讓W(xué)asm解碼器將YUV數(shù)據(jù)輸出到其線性內(nèi)存的固定區(qū)域然后JS端通過TypedArray的“視圖”直接引用那塊內(nèi)存用于WebGL紋理上傳。避免在JS和Wasm之間來回復(fù)制大的YUV數(shù)據(jù)這是性能生命線。解碼器多實(shí)例對于多路視頻播放如監(jiān)控墻可以為每一路創(chuàng)建一個(gè)獨(dú)立的Wasm解碼器實(shí)例。雖然Wasm模塊代碼只加載一次但每個(gè)解碼器的狀態(tài)內(nèi)存是獨(dú)立的。動(dòng)態(tài)分辨率/碼率切換在網(wǎng)絡(luò)差或CPU吃緊時(shí)可以通知后端推送更低碼率的子流或者在前端主動(dòng)跳幀如只解碼I幀和P幀跳過B幀以降低解碼壓力。Worker隔離將整個(gè)解碼渲染流水線放入Web Worker中避免阻塞主線程的UI交互。主線程只負(fù)責(zé)流獲取和UI控制。Worker與主線程通過postMessage傳遞控制命令和渲染后的圖像數(shù)據(jù)甚至可以用OffscreenCanvas直接讓W(xué)orker進(jìn)行WebGL渲染。4. 常見問題、排查技巧與選型建議在實(shí)際開發(fā)和線上運(yùn)維中你會遇到各種各樣的問題。下面是我踩過的一些坑和總結(jié)的經(jīng)驗(yàn)。4.1 Wasm解碼方案典型問題排查表問題現(xiàn)象可能原因排查思路與解決方案播放黑屏但控制臺無錯(cuò)誤1. WebGL上下文創(chuàng)建失敗或著色器編譯錯(cuò)誤。2. YUV數(shù)據(jù)格式與著色器預(yù)期不符如YUV420SP vs YUV420P。3. 紋理上傳數(shù)據(jù)指針或尺寸錯(cuò)誤。1. 檢查gl.getError()在著色器編譯后檢查gl.getShaderInfoLog()。2. 確認(rèn)解碼器輸出的YUV平面順序和采樣格式。用一張簡單的測試圖如色彩條驗(yàn)證解碼和渲染管線。3. 打印紋理的寬度、高度檢查gl.texImage2D調(diào)用參數(shù)。播放卡頓CPU占用率極高1. 軟解碼CPU算力不足。2. JS與Wasm間內(nèi)存拷貝開銷大。3. 渲染YUV轉(zhuǎn)RGB在JS中進(jìn)行。1. 降低視頻分辨率或幀率。檢測機(jī)器性能考慮降級策略。2.務(wù)必使用“視圖”而非“拷貝”的方式獲取Wasm內(nèi)存數(shù)據(jù)。3. 確保使用WebGL進(jìn)行YUV渲染絕對不能用JS循環(huán)轉(zhuǎn)換。內(nèi)存持續(xù)增長最終崩潰1. Wasm內(nèi)存泄漏解碼器內(nèi)部未釋放幀。2. JS端緩存隊(duì)列未清理。3. WebGL紋理未及時(shí)刪除。1. 確保C代碼中每個(gè)av_frame_alloc()都有對應(yīng)的av_frame_free()。2. 設(shè)置解碼隊(duì)列和渲染隊(duì)列的最大長度丟棄過期幀。3. 在切換視頻源或銷毀播放器時(shí)主動(dòng)調(diào)用gl.deleteTexture()。首幀顯示非常慢1. Wasm模塊文件太大下載和編譯耗時(shí)。2. 解碼器初始化解碼參數(shù)慢。1. 對Wasm文件進(jìn)行g(shù)zip壓縮。使用instantiateStreamingAPI邊下載邊編譯。2. 考慮將解碼器初始化提前或在空閑時(shí)預(yù)加載。音畫不同步1. 僅以解碼速度驅(qū)動(dòng)渲染無同步機(jī)制。2. 時(shí)間戳處理錯(cuò)誤DTS當(dāng)PTS用。3. 音頻或視頻隊(duì)列堆積。1. 實(shí)現(xiàn)以音頻時(shí)鐘為基準(zhǔn)的同步邏輯。簡單版可以基于幀PTS和系統(tǒng)時(shí)鐘做對齊。2. 確認(rèn)從封裝格式中提取的是PTS。FLV的timestamp就是PTS。3. 監(jiān)控隊(duì)列長度在視頻落后時(shí)跳幀在視頻超前時(shí)等待。4.2 WebCodecs API的兼容性與實(shí)戰(zhàn)注意點(diǎn)如果你決定嘗試WebCodecs需要注意異步接口VideoDecoder的decode()是異步的返回Promise。你需要妥善管理解碼請求的順序防止幀亂序。配置hardwareAcceleration創(chuàng)建VideoDecoder時(shí)可以指定hardwareAcceleration: prefer-hardware。但這只是一個(gè)提示瀏覽器不一定遵守。實(shí)際是硬解還是軟解需要看VideoDecoder返回的VideoFrame的format屬性或者通過性能分析判斷。Safari的鴻溝目前Safari不支持WebCodecs這意味著你的方案必須要有可靠的降級回退到Wasm。檢測代碼要寫好if (VideoDecoder in window) { ... }。4.3 選型與架構(gòu)建議對于不同的團(tuán)隊(duì)和場景我的建議如下初創(chuàng)團(tuán)隊(duì)或快速驗(yàn)證項(xiàng)目優(yōu)先使用商業(yè)播放器SDK。例如一些云服務(wù)商提供的播放器SDK已經(jīng)內(nèi)置了Wasm解碼的降級方案。這能節(jié)省你數(shù)月甚至一年的底層開發(fā)、調(diào)試和優(yōu)化時(shí)間。自己造輪子的成本極高。有音視頻處理背景的中型團(tuán)隊(duì)可以考慮基于開源庫進(jìn)行二次開發(fā)。例如使用Broadway.js一個(gè)H264解碼器或libde265.js一個(gè)H265解碼器的Wasm版本作為基礎(chǔ)專注于業(yè)務(wù)邏輯和渲染優(yōu)化。但要注意這些庫可能版本較舊需要自己維護(hù)和更新。大型公司或?qū)w驗(yàn)、可控性要求極高的項(xiàng)目走自研路線。從編譯FFmpeg Wasm開始完全掌控解碼流水線。這需要配備專業(yè)的C/C工程師和圖形學(xué)工程師。架構(gòu)上一定要采用“Worker OffscreenCanvas”將解碼渲染與主線程隔離并設(shè)計(jì)良好的降級策略WebCodecs - Wasm。最后一點(diǎn)個(gè)人體會無插件播放H265尤其是Wasm方案是一個(gè)在“兼容性”和“性能”之間走鋼絲的工程。它證明了Web平臺的強(qiáng)大但也暴露了其限制。在啟動(dòng)這類項(xiàng)目前務(wù)必用真實(shí)的目標(biāo)流分辨率、碼率在最低端的設(shè)備如低配Chromebook上進(jìn)行性能評估。很多時(shí)候技術(shù)能實(shí)現(xiàn)但體驗(yàn)不一定能接受。這時(shí)候與后端協(xié)商是否能為不支持H265的客戶端提供一份H264的轉(zhuǎn)碼流往往是更經(jīng)濟(jì)、用戶體驗(yàn)更好的選擇。技術(shù)方案的選型永遠(yuǎn)是為業(yè)務(wù)目標(biāo)和用戶體驗(yàn)服務(wù)的。