概況

這個主要是參加“深圳 liveVideoStack” 的ppt的文字版的分享。

深圳 liveVideoStack

講師介紹

關于Jessibuca

• 官網地址：jessibuca.com
• Demo: Demo
• Doc：Doc
• Github地址：Github

關于JessibucaPro

• 地址：JessibucaPro
• Demo: Demo
• AI:AI
• 插件：插件

進入主題

大家好：今天我給大家?guī)淼姆窒淼念}目是：Web端專業(yè)級H264/H265 直播流播放器實現 - jessibucaPro 播放器實現。

本次分享主要介紹‘背景’，‘架構，兼容性，性能’，還有”展望未來“三個部分。

第一部分(背景)

直播行業(yè)概況

我們看下現在的直播行業(yè)概況。

目前主要使用到直播的三個領域，分別是監(jiān)控平臺，直播平臺，還有互動直播。其中監(jiān)控平臺，例如道路車輛監(jiān)控，馬路安全監(jiān)控平臺，主要是安防領域，比如?？?#xff0c;大華等。
然后就是直播平臺，比較典型的是斗魚，虎牙，抖音這種面向c端的平臺。最后就是互動直播領域，主要有在線教育，音視頻會議這種，像騰訊會議，zoom等。

web端直播協議

目前web端支持的直播格式有：

• hls(m3u8+ts/mp4)
• HDL(flv)
• FMP4
• Raw(H264,H255)

web端支持的直播的協議有：

• HTTP
• WebSokcet
• WebTransport
• Webrtc

H.264 vs H.265

對比H.264 格式和 H.265 格式,可以看出

1. H.264優(yōu)勢在于兼容性高，pc和移動端都支持。H.265兼容性低，兼容依賴瀏覽器版本和底層硬件支持。
2. H.265的壓縮比、視頻質量、性能要高于H.264。

壓縮比：同等分辨率情況下，H.265 所需要的帶寬要低于h264所需的帶寬。

視頻質量：H.264能夠支持到最高2k，但是H.265可以支持到4k。

性能：H.264的性能要遠低于H.265。

H.264對比H.265兼容性如圖：

紅的完全不支持，暗綠色是部分支持(需要一定條件才能支持)，綠色是完全支持。

對比可以發(fā)現：左邊，H.264，一片綠，說明支持度非常高，對于pc端的chrome，edge，safari，firefox，opera，ie，移動端安卓的chrome，ios的safari都支持。

右邊，H.265，只有小部分綠，大部分都是暗綠，依賴一定條件的支持，對于pc端，大部分瀏覽器（chrome，edge，opera，ie）需要底層硬件支持，firefox完全不支持，移動端安卓chrome也需要底層硬件支持，只有pc 端的safa和移動端的ios 上的safari支持。

Webassembly 兼容性

基本也是全綠，除了IE 。其他pc 和移動端都支持。

WebAssembly（縮寫為 wasm）是一種使用非 JavaScript 代碼，并使其在瀏覽器中運行的方法。這些代碼可以是 C、C++ 或 Rust 等。它們會被編譯進你的瀏覽器，在你的 CPU 上以接近原生的速度運行。這些代碼的形式是二進制文件，你可以直接在 JavaScript 中將它們當作模塊來用。

業(yè)務需求

業(yè)務所需：

• 水印-用來版權保護防盜錄，內容識別等。
• 低延遲-安防監(jiān)控，直播會議所需。
• 視頻流加密-主要是為了保護直播流的安全。
• 電子放大-主要是安防安防領域所需。
• 廣角渲染-廣角攝像頭，主要是安防安防領域所需。
• 音頻g711a/u格式-攝像頭支持的音頻格式，主要是安防安防領域所需。
• 實時框-主要是ai識別畫識圖。

低延遲直播流播放器

在這些web端的需求和背景下，我們需要一款能夠支持各種直播協議（http、websocket、webtransport等），支持H.264、H.265硬解碼+軟解碼，支持豐富功能（水印、低延遲、視頻流加密等）的直播流播放器。

第二部分(架構、兼容性、性能)

介紹完背景部分，第二部分，我們來看下播放器的架構，在瀏覽器兼容性兼容性的解決方案，以及一些性能優(yōu)化部分。

架構

首先我們看下播放器的架構部分，整個播放器主要由7大模塊組成。

左邊是核心模塊，從上到下，分別是Stream模塊、Demux模塊、Decoder模塊、Render模塊。右邊擴展模塊，從上到下，分別是UI模塊、Crypto模塊、Recorder模塊。

Stream模塊

主要是網絡請求模塊：支持http、websocket、webtransport、webrtc協議。借助web端提供的fetch、websocket、xmlhttprequest等方法請求到流數據。

目前播放器支持的請求協議有 15種格式：

• ws(s)-raw 即ws://host-name:port/jessica/live/test (該協議只對接了monibuca服務器,其他服務器需要額外對接)
• ws(s)-flv 即ws://host-name:port/jessica/live/test.flv（chrome下ip會報安全錯誤，建議域名形式訪問，檢查下端口范圍chrome瀏覽器是否允許，chrome會默認禁用很多端口）
• http(s)-flv 即http://host-name:port/hdl/live/test.flv
• Hls 即http://host-name:port/hls/live/test.m3u8 (支持H264/H265)
• WebTransport 即wt://host-name:port/play/live/test (該協議只對接了monibuca服務器,其他服務器需要額外對接)
• Webrtc 即 webrtc://host-name:port/webrtc/play/live/test (支持H264/H265, 僅支持https://或者http://localhost環(huán)境)
• Webrtc-zlmediakit 即 webrtc://host-name:port/index/api/webrtc?app=live&stream=stream-name&type=play (支持H264, 僅支持https://或者http://localhost環(huán)境)
• Webrtc-srs 即 webrtc://host-name:port/rtc/v1/play/live/test (支持H264, 僅支持https://或者http://localhost環(huán)境)
• Webrtc-others 即 webrtc://host-name:port/live/test (支持H264, 僅支持https://或者http://localhost環(huán)境)
• http(s)-fmp4 即http://host-name:port/your-path/live/test.(f)mp4
• ws(s)-fmp4 即ws://host-name:port/your-path/live/test.(f)mp4
• http(s)-h264 即http://host-name:port/jessica/live/test.h264
• ws(s)-h264 即ws://host-name:port/jessica/live/test.h264
• http(s)-h265 即http://host-name:port/jessica/live/test.h265
• ws(s)-h265 即ws://host-name:port/jessica/live/test.h265
• ws(s)-mpeg4 即ws://host-name:port/your-path/live/test.mpeg4

從中可以小結下：

• 協議同時支持https、wss
• 同時支持H264和H265編碼格式
• 支持webcodecs硬解碼(H264+H265)和MSE硬解碼(H264+H265)
• 支持HLS(H264+H265)軟解碼、硬解碼
• 支持m7s webrtc(H264+H265(軟解碼、硬解碼))，
• 支持zlmediakit webrtc(H264)
• 支持srs webrtc(H264)
• 支持others webrtc(H264)
• 支持加密流(國標SM4、m7s加密流)
• 支持裸流(H264+H265)
• 支持Fmp4格式(H264+H265)
• 支持mpeg4格式(H264)

Demux模塊

這個模塊主要的工作是：將流數據進行解封裝出一幀一幀H264、H265數據。

目前播放器支持的封裝格式有：

• hls (http) (m3u8+ts/mp4) 視頻(H264、H265) 音頻(AAC、MP3)
• Flv (http+ws) 視頻(H264、H265) 音頻(AAC、MP3、G711A、G711U)
• M7S (ws) 視頻(H264、H265) 音頻(AAC、MP3、G711A、G711U)
• FMP4 (http) 視頻(H264、H265) 音頻(AAC、MP3)
• MPEG4 (ws) 視頻(H264)
• Raw (ws) 視頻(H264、H265)

Decoder模塊

decoder模塊主要是負責解碼，默認播放器支持三種解碼模式(兩種硬解碼，一種軟解碼)

• MediaSource 硬解碼
• Webcodec 硬解碼
• ffmpeg(Webassembly) 軟解碼

MediaSource 硬解碼

主要是將一幀一幀H264、H265數據再次封裝成Fmp4片段，然后喂給MediaSource來通過播放器底層硬解碼音視頻數據。渲染在video標簽上面。

Webcodec 硬解碼

主要是將一幀一幀H264、H265數據解碼成videoFrame對象，可以通過canvas 或者 video 渲染。

ffmpeg(Webassembly) 軟解碼

主要是將一幀一幀H264、H265數據解碼成YUV數據,可以通過canvas 或者 video 渲染。

Render模塊

主要是渲染模塊，目前播放支持video標簽+canvas標簽渲染。

對于各個解碼模塊后續(xù)的渲染模塊，支持程度：

解碼器	video渲染	canvas渲染
MediaSource	?	?
Webcodec	?	?
ffmpeg(Webassembly)	?	?

UI模塊

目前播放器支持的UI模塊有：

• 全屏 測試地址
• 聲音控制 測試地址
• 網速顯示測試地址
• 截圖 測試地址
• 進度條 測試地址
• 播放倍率 測試地址
• 顯示比例 測試地址
• 視頻錄制 錄制FLV、WEBM，錄制Mp4
• 分辨率切換 測試地址
• ptz指令操作 測試地址
• 右鍵菜單 測試地址
• 性能面板 測試地址
• 電子放大 測試地址
• 快捷鍵
• 水印（局部，全屏，動態(tài)，幽靈）測試地址

Crypto模塊

目前播放器支持的加密模式有

• m7s 私有格式 測試地址
• SM4 國標加密 測試地址
• XOR 加密
• 支持擴展加密其他私有加密格式

Recorder模塊

目前播放器支持的錄制格式有

• flv 格式 測試地址
• Webm格式 測試地址
• Mp4 格式 測試地址

兼容性

介紹完播放器的整體架構，接下來我們看下播放器在web端兼容性上面的解決方案。

主要分享6個業(yè)務場景，分別是：

• 電腦硬件不支持H265硬解碼
• IOS不支持MediaSource硬解碼
• 音頻格式是G711a/G711u
• Webrtc如何播放H265的流
• 兼容國產系統(tǒng)/國產瀏覽器
• MediaRecorder不支持錄制mp4(MPEG-4)格式

電腦硬件不支持H265硬解碼

目前的現狀是：

1. chrome 107版本以上外加需要硬件支持才能夠支持硬解碼H265。
2. edge 79版本以上外加需要硬件支持才能夠支持硬解碼H265。
3. FireFox 直接就不支持。

播放器的解決方案是：

1. 使用ffmpeg+webassembly,通過軟解碼來支持H265解碼。
2. 使用sharedArrayBuffer，來提升軟解碼性能。
3. 使用SIMD指令集加速解碼，來提升硬解碼性能。

效果如下：

另外測試地址： 測試地址

IOS不支持MediaSource硬解碼

目前的現狀是：

1. iPadOS 13+ 才支持。
2. ios 完全不支持。

播放器的解決方案是：

1. 使用ffmpeg+webassembly。
2. IOS16.3+使用webcodec解碼。

效果如下：

音頻格式是G711a/G711u

目前的現狀是：

1. Fmp4只支持aac/mp3格式的音頻，不支持G711a/G711u格式的音頻。

播放器的解決方案是：

1.使用FFmpeg+Webassembly進行軟解碼，然后借助AudioContext進行播放。

Webrtc如何播放H265的流

目前的現狀是：

1. WebRTC本身只支持VP8、VP9、H264、AV1格式。

播放器的解決方案是：

1. 流媒體服務器（monibuca）通過DataChannel傳輸音視頻數據，借助MediaSource/Webcodec/Webassembly解碼播放。

兼容國產系統(tǒng)/國產瀏覽器

目前的現狀是：

1. 國產操作系統(tǒng)（麒麟等）/瀏覽器（統(tǒng)信等），對于H264/H265硬解碼支持度不夠，使用的Chromium內核版本都比價低。

播放器的解決方案是：

1. 當不支持硬解碼的時候，使用ffmpeg+WebAssembly進行軟解碼播放。

MediaRecorder不支持錄制mp4(MPEG-4)格式

目前的現狀是：

1. MediaRecorder只支持錄制成webm格式文件。

播放器的解決方案是：

1. 使用ffmpeg+WebAssembly錄制成mp4格式文件。

測試地址：測試地址

性能

介紹完了播放器在web兼容性上面的解決方案，我們再看下播放器在性能優(yōu)化上面的一些方案。

主要介紹四種優(yōu)化方案：

1. 低延遲優(yōu)化
2. Worker線程降低主線程壓力
3. 多線程軟解碼提升軟解碼性能
4. OffscreenCanvas優(yōu)化渲染

低延遲優(yōu)化

為了保證低延遲，播放器設計實現了緩沖區(qū)JitterBuffer，添加延遲丟幀機制，添加網絡延遲檢測機制。

達到的效果：

通過盡可能的優(yōu)化，播放器做到了，

1. 首屏時間小于1s
2. 公網環(huán)境網絡穩(wěn)定的情況下延遲小于1s
3. 內網環(huán)境下可以通過配置使得延遲低于0.8s

Worker線程降低主線程壓力

通過worker線程，播放器可以通過配置支持將網絡請求模塊stream，解封裝模塊demux，和解碼模塊decoder全部放在worker線程里面進行，然后將解碼之后的數據傳輸到主線程進行渲染和播放。

達到的效果

多線程軟解碼提升軟解碼性能

開啟多線程解碼，借助多核來進行軟解碼，來提升解碼性能。

首先需要再編譯ffmpeg的時候添加多線程參數。然后在將ffmpeg編譯打包成webassembly的時候，也需要配置多線程參數。在編寫c的業(yè)務代碼的時候也需要配置使用的多核數量，最后播放器在瀏覽器上面運行的時候，需在網站的相應頭上面添加兩個相應參數。這樣播放器就使用多線程來軟解碼音視頻了。

達到的效果

左邊圖是沒有開啟多線程的，右邊的開啟了多線程的。對比我們可以發(fā)現，例如同樣是webassembly軟解碼265的1080p 在機器是cpu i7_8700k 顯卡是rtx2080的機器上面可以支持同時4路流播放，但是如果開啟了多線程，那就可以支持到8路流同時播放。性能翻倍了。

OffscreenCanvas優(yōu)化渲染

最后，我們看下offscreen canvas 離屏畫布。

支持兩種模式：

transfer

worker 線程創(chuàng)建OffscreenCanvas，使用webgl進行繪制，然后將生成的ImageBitmap ，通過postmessage到主線程，然后借助canvas 進行渲染

commit

主線程創(chuàng)建OffscreenCanvas，然后通過postmesage將canvas句柄傳遞到worker線程，然后worker 線程使用webgl進行繪制渲染。

區(qū)別

區(qū)別就是transfer需要一直postmessage 傳遞數據，而commit模式只需要主線程一次將canvas句柄傳遞到worker線程。 根據業(yè)務情況采用不同的模式。

達到的效果

展望未來

介紹完了播放器在web端的一些性能優(yōu)化，我們再看下展望未來。

播放器可以支持人臉識別，物品識別，讓播放器端提供ai能力。可以支持馬賽克檢查，視頻遮擋檢查，黑屏、 綠屏檢查。 來提升播放效果。

人臉識別、物品識別

對于人臉識別，物品識別，我們可以采用的方案有：opencv 、 mediapipe

1. opencv 是一個跨平臺的計算機視覺庫，可以支持增強現實，人臉識別，動作識別等領域。底層庫。
2. mediapipe：谷歌基于opencv開發(fā)出來的功能強大的機器學習框架。 兩個都可以借助webassembly 在web端跑運行。

人臉識別

人臉識別測試地址 測試地址

物品識別

物品識別測試地址 測試地址

馬賽克檢查，視頻遮擋檢查，黑屏、 綠屏檢查

黑屏、綠屏、花屏、馬賽克檢查 測試地址 測試地址

遮擋物檢查測試地址測試地址

最后

關于Jessibuca

• 官網地址：jessibuca.com
• Demo: Demo
• Doc：Doc
• Github地址：Github

關于JessibucaPro

• 地址：JessibucaPro
• Demo: Demo
• AI:AI
• 插件：插件

謝謝大家。