web端的解碼及渲染的實(shí)現(xiàn)

在前面的文章中介紹了ZLMediaKit的修改方法，在web端的播放器可以參照這個(gè)實(shí)現(xiàn)，基于wasm H265播放器。
基本思路就是通過(guò)emscripten將ffmpeg的編譯成wasm，可以直接在瀏覽器中運(yùn)行的軟解碼器。然后用webgl渲染出圖像。

應(yīng)用場(chǎng)景

單向視頻流的場(chǎng)景

這是這個(gè)方案著重解決的場(chǎng)景。

webrtc datachannel(基于ZLMediaKit) + wasm解碼 + webgl渲染。這種方案，非常適合單向視頻流的應(yīng)用場(chǎng)景，比如：web看攝像頭。在這樣的場(chǎng)景中，視頻流是單向的，碼流從攝像頭到ZLMediaKit到瀏覽器并且沒(méi)有音頻。

但是方案的應(yīng)用有兩個(gè)需要考慮的問(wèn)題：

datachannel通道的穩(wěn)定性

穩(wěn)定性是從傳輸大數(shù)據(jù)量和可靠性?xún)蓚€(gè)角度衡量。

datachannel是可以傳輸大數(shù)量的，并且也有可靠性保證：丟包重傳和保證有序。為此我做了兩個(gè)場(chǎng)景的測(cè)試：

1. 內(nèi)網(wǎng)測(cè)試：ZLMediaKit與rtmp推流端，web都部署在內(nèi)網(wǎng)。web通過(guò)datachannel拉8M的H265碼流，并沒(méi)有出現(xiàn)過(guò)丟包。
2. 外網(wǎng)測(cè)試：ZLMediaKit部署在外網(wǎng)，rtmp推流端和web部署在內(nèi)網(wǎng)。web拉H265碼流，根據(jù)云服務(wù)的帶寬設(shè)置推流碼率大小，只要碼率值小于帶寬，則并不會(huì)出現(xiàn)丟包和亂序(說(shuō)明datachannel通道是有可靠性保證的)。

關(guān)于延遲，對(duì)于webrtc datachannel通道的延遲我并沒(méi)有專(zhuān)門(mén)進(jìn)行測(cè)試，但是在后續(xù)的播放器整體測(cè)試時(shí)，webrtc datachannel通道并沒(méi)有引入不可接受的延遲。

解碼性能

瀏覽器通過(guò)ffmpeg軟解碼，對(duì)于分辨率大，碼流大的情況或多路視頻時(shí)，還是會(huì)出現(xiàn)性能不足的情況?？梢酝ㄟ^(guò)以下兩種方式進(jìn)行優(yōu)化：

• simd解碼

simd介紹見(jiàn)這個(gè)鏈接 WebAssembly中的simd。
在emscripten中通過(guò)msimd128編譯選項(xiàng)進(jìn)行了支持。
實(shí)測(cè)效果，simd比f(wàn)fmpeg的軟件解碼方式，性能提高了一倍。

• 硬解碼

瀏覽器已經(jīng)可以支持對(duì)H265的硬解碼，但是有瀏覽器的版本限制。
在chrome 瀏覽器中可以通過(guò)webcodec的API來(lái)使用硬解碼。
可以看下這個(gè)鏈接，chrome支持hevc硬編解碼。

雙向視頻流的場(chǎng)景

我沒(méi)有實(shí)際的測(cè)試經(jīng)驗(yàn)，但是基于webrtc datachannel + wasm 編解碼的方案應(yīng)該是能走通的。首先data channel通道是支持雙向流，穩(wěn)定性也不錯(cuò)。編碼性能方面可以通過(guò)simd編碼或硬編碼解決。

有音頻流的場(chǎng)景

有音頻流最大的難點(diǎn)是要做音視頻同步，也意味著web端不再只是單純的解碼，渲染，回放。還需要與ZLMediaKit服務(wù)器交互時(shí)間同步信息(比如rtcp的sr包)。這種需求比單向視頻流的場(chǎng)景復(fù)雜很多，并且大概率效果還不好(因?yàn)橄拗铺?。所以如果同時(shí)有音視頻流場(chǎng)景，還是在服務(wù)端做轉(zhuǎn)碼，將H265轉(zhuǎn)成H264，然后在web端通過(guò)webrtc實(shí)現(xiàn)音視頻處理更好。