HTML5中一個十分重要的提高就是對音視頻的無插件支持,不管是各個端瀏覽器對各類視頻容器格式愈來愈豐富的支持,仍是Media Source Extension(MSE)對Video擴展性的提高,咱們如今能對瀏覽器上的音視頻作愈來愈多的新奇嘗試。但也由於Web技術的開放,對於國內的移動端瀏覽器而言,很多公司都對HTML5 Video能力進行了一系列的私有化的技術改造,其中包括(不限於):github
因爲音視頻相比於文字和圖片而言有更大的信息承載,同時隨着網速的提升,已經成爲了一個內容重要的入口,以上的修改對於商業公司來講是情有可原的。可是對於開發者而言,各家瀏覽器的行爲不一致給需求的實現帶來了極高的難度,同時也形成了極爲糟糕的用戶體驗。瀏覽器
如何破除這種魔咒?咱們從一個實際的開發示例上講起。微信
自從快手和抖音流行以後,短視頻逐漸成爲風口,有很多公司開始嘗試短視頻的產品形式。固然,咱們公司也一樣作起了「短視頻+電商」的創業項目,其中咱們的產品主要以模仿抖音的「沉浸式短視頻」爲主提出需求。ide
「沉浸式短視頻」的技術方案對於Native端來講是比較成熟且成體系的,可是Web端因爲上面的各類技術緣由,目前暫時沒有看到成體系的方案。同時,對於渠道端而言,咱們更但願咱們的「沉浸式短視頻」方案可以在微信的WebView中運行,方便進行產品的推廣和流量拓展。post
但對於微信的WebView而言,其主要是集成的X5引擎,其中對Video作了至關多的修改,其中不限於文章開頭提到的技術限制,但其中比較嚴重的有兩個:性能
因爲這兩個限制,咱們很難完成相似抖音的「沉浸式短視頻」的方案。測試
在全民直播時,咱們使用WebAssembly進行H264軟解,編寫了可以進行直播的FLV播放器QMInlinePlayer,在開發調研過程當中咱們測試了在當時比較主流的幾款機器,獲得了比較使人欣喜的結果,如圖: ui
其編寫的思路也很簡單:既然視頻文件由圖像數據和音頻數據組成,咱們爲何不進行軟解獲得原始的圖像數據和音頻數據,本身進行繪製和播放。整個程序的思路如圖所示: 加密
固然,因爲當時公司內部比較混亂波折,咱們並無對這以方案進行開源,但好在社區後來也出現了很多相似的實踐,例如:
在今年,因爲咱們的需求開始逐步涉獵短視頻業務,而且但願在微信WebView中傳播。所以咱們根據在全民直播時的經驗,對QMInlinePlayer進行了大量的修改提高:
同時,咱們也拓展支持了更多的瀏覽器,提高其兼容性,目前的兼容性支持包括(不限於):
從QMInlinePlayer到WXInlinePlayer咱們從新出發,並將其開源在Github上供你們使用。固然,WXInlinePlayer目前穩定跑在咱們本身的產品好惠買當中,整個微信端產品的體驗並不輸於Native的體驗(加載/秒開),取得了很好的效果。
同時,咱們也對現有的H264的相似方案進行了性能和內存佔用相關的比較,WXInlinePlayer在各個方面都相較於其餘會有很大的提高。
此測試爲屢次均值,不一樣設備會有不一樣結果,測試視頻取自WXInlinePlayer的測試視頻,BroadwayJS所需的MP4同由此測試視頻經ffmpeg進行轉碼。
WXInlinePlayer目前的總體功能只是覆蓋了咱們本身產品的需求,更多的需求以及功能的實現須要更多人可以參與到WXInlinePlayer中,幫助咱們更好完善WXInlinePlayer,固然目前咱們本身的提高計劃也包括了:
更多信息你能夠 點擊這裏 查看WXInlinePlayer的文檔。
方老溼,您學會了麼?