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

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

應(yīng)用場景

單向視頻流的場景

這是這個方案著重解決的場景。

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

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

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

穩(wěn)定性是從傳輸大數(shù)據(jù)量和可靠性兩個角度衡量。

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

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

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

解碼性能

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

• simd解碼

simd介紹見這個鏈接 WebAssembly中的simd。
在emscripten中通過msimd128編譯選項進行了支持。
實測效果，simd比ffmpeg的軟件解碼方式，性能提高了一倍。

• 硬解碼

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

雙向視頻流的場景

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

有音頻流的場景

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