如何看待嗶哩嗶哩的開源 HTML5 播放器內核 flv.js?

01-14

https://github.com/Bilibili/flv.js
（準確的說開發者在開發該內核時在嗶哩嗶哩上班而已，在開源該內核後已離職。如何看待嗶哩嗶哩的 flv.js 作者月薪不到 5000 元？ http://www.zhihu.com/question/53686737?utm_source=qqutm_medium=social ）

謝邀，抱歉拖延到現在才來回答問題。

利益相關：flv.js 作者

GitHub - Bilibili/flv.js: HTML5 FLV Player

flv.js 做了三件事：

1. HTML5 原生僅支持播放 mp4/webm 格式，flv.js 實現了在 HTML5 上播放 FLV 格式視頻

2. 使 Bilibili 網頁端平滑過度到 HTML5 播放器，歷史遺留不再是障礙

3. 對於視頻直播，在 HTML5 上支持了延遲極低 HTTP FLV 播放，解開網頁端直播對 Flash 的依賴

一些人問我為什麼不直接採用 MP4 格式，並表示對 FLV 格式的厭惡

這個問題一方面是歷史遺留問題，由於視頻網站前期完全依賴 Flash 播放而選擇 FLV 格式；

另一方面，如果仔細研究過 FLV/MP4 封裝格式，你會發現 FLV 格式非常簡潔，而 MP4 內部 box 種類繁雜，結構複雜固實而又有太多冗餘數據。FLV 天生具備流式特徵適合網路流傳輸，而 MP4 這種使用最廣泛的存儲格式，設計卻並不一定優雅。

這裡我不想談論多媒體封裝格式的優劣。flv.js 是在 HTML5 上實現自定義視頻格式播放的一個較好的範例，充分利用了 Media Source Extensions, Fetch API 以及 ECMAScript 6 等 HTML5/Web 上較新的技術，並考驗著這些 API：開發期間發現 Edge 對 Fetch API 的支持存在 bug，發現各個瀏覽器在 MSE 的實現細節上都有一些差異和問題，發現 Safari 的 MSE 實現健壯度較差（滑稽）

在 flv.js 項目初期，Media Source Extensions (MSE) 在國內處於無人問津的狀態；而 MSE API 已經過近 4 年的發展演進，是 HTML5 多媒體相關最重要的 API 之一。MSE 是 HTML5 上實現自定義格式播放的關鍵，flv.js 開源也是希望 MSE 能被更廣泛地了解和應用。

最後，Chrome 等瀏覽器正在加速 Flash 淘汰的進程，HTML5 video 由各瀏覽器廠商實現了高性能硬解，MSE 作為媒體格式擴展的補充，flv.js 證明了當前 HTML5 多媒體技術已超越陳舊的 Flash。

其實很多人不明白這個東西的意義。其實國內所有直播網站都有幾秒的延遲，因為普遍對直播實時性要求不高，但是有些直播對實時性要求特別高。

假如你有這樣一個需求，你需要直播拉斯維加斯一個賭桌上，一個荷官在玩21點的遊戲。如果延時很高。比如用HLS來直播，那麼會有超過10秒以上的延時。你看到服務端發過來的牌點數，但是視頻上的荷官10秒後才發牌，完全不能用。

那麼只能選擇低延遲的直播協議，而所有直播協議延遲和實時性最好的就是RTMP，在中國看美國的視頻直播延遲也能控制在1秒內，很神奇的一個協議。但是RTMP有個缺點，他只能在PC端上用flash來直播，不支持移動端。如果要在手機上網頁端用html5播放，那麼只能選擇HLS，而且HLS在中國看美國的視頻直播有時候高達18秒的延遲。

而真正能解決這個需求的，目前來說只有flv.js，通過HTTP-FLV，在手機網頁端用html5播放，延遲是能控制在1秒內的。

其實很多外國遊戲直播網站都是用RTMP來直播。他們都是在手機上用APP，用C++來解析的。看過一個英文論壇上的討論，他們的技術對於網頁端播放低延遲直播幾乎無解，網頁端非常難。很多人都沒有意識到，這是非常有技術含量，非常偉大的一項技術。

至於很多人為什麼不用MP4，而表示對FLV的厭惡的問題。做為一個技術控，我是能理解B站為什麼用FLV。因為adobe的RTMP和FLV的格式，都設計的非常的簡潔和漂亮，所以才有如此神奇的性能。而對於開發者也是一種解脫，無論用C或者js處理，代碼也都非常簡潔。如果你讓他用js去寫MP4那一坨坨代碼，就陷入無窮的技術坑。所以做為一個技術控，用FLV是再自然不過的事情。用FLV，性能好速度快用戶爽，代碼易讀易控開發者爽，只是噴子不爽。

厲害了我的哥……

剛出來 h5 播放器的時候我猜測了一下，大概是 B 站用 emscripten 封裝了 flv2mp4 一類的 c++ 程序（反正有 asm.js 嘛），然後 slice 一下交給 Blob API 然後 Stream 給 video tag…畢竟自己搞過一個 MIDI Player (https://ACGSounds.com) 大概是這麼玩的…然後 flv.js 開源了…了…大吃一驚！竟然用 native js 直接讀了一遍 metadata, AAC Stream 和視頻流…然後 remux

（我曾經受 videojs-contrib-hls 啟發把 ffmpeg 一類的東西用 emscripten 造大新聞…那個 pack 實在是太恐怖了……

B站損失了一個他們沒意識到價值的技術大牛，視頻、直播、h5界卻認識了一個了不起的flv.js和其作者！

Flv.js的幾個意義：

1，h5上實現直播的目前已知的最優解決方案，性能不弱於原生app直播：直播延遲控制到1秒內。帶寬、存儲其實比原生app普遍採用的mp4更優。

2，h5上用js實現高質量音視頻解碼、並支持h5富媒體標準mse使其得到應用、重視，從而促進h5具備原生應用多媒體能力得以大大提升。

3，這是中國程序員在h5音視頻領域的一項傑出成果！考慮到類似成果之前還基本出自非中國程序員，這個價值特別值得一說。

概括下，3大價值：

h5視頻直播、播放極優的解決方案；

推進h5多媒體標準、提升h5能力；

填補中國程序員在h5音視頻領域的貢獻弱勢、欠缺。

這個flv.js解決了使用flv作為視頻容器，並在html5播放器播放出來的一個難點。

不過。。。需求不高。。。如果我要做全html5的網站，存mp4不就好了。

不過這個是media source extension實現的，算是給了我們一個用這個介面的不錯的正面例子。

挺好的，用這個框架能改出個 HLS 播放器來。這就使得瀏覽器端視頻直播除了 FLASH 和 WebRTC 之外有了第三種普適的選擇。

更正一下：我沒看過 hls.js 的代碼，想當然的認為是 C++ 代碼轉的，沒法維護修改。評論中有指正，大家可以看評論。

另外，目前看來 Web 端視頻播放的基礎設施已經慢慢地生長起來了，http＋WebSocket＋MSE ＋MPEG dash＋Video標籤＋Audio標籤＋WebGL＋WebRTC，這幾項技術應該能組合出不弱於 native 級的視頻播放系統（非線編輯和混音暫時就別想了，不太現實），目前暫時每一個模塊內部成熟度還不夠，不過 Web 視頻複雜應用的開發條件已經呼之欲出了。

對於其他為了廣告守著 flash 的廠商來說，bilibili 是一股清流。。。

我愛死這個破網站了。。( ゜- ゜)つロ

東西是個好東西，但局限性很大

別的站用flv的準備繼續用flash來實現高端的廣告功能（如x酷）

而使用html5播放器的大部分網站都會選擇將視頻存儲轉為純mp4

像我們這些第三方的卻又被cors阻擋難以實現

（早前有人問過相關人為什麼還存flv，flash遲早要死。回答說「不就是個remux的事，又費不了多少資源」……）

不過也不是完全沒有路

如果第三方需要引入flv.js來播放b站flv，最簡單的方法，使用http://xxx.xxx.xxx.xxx/ws.acgvideo.com地址就可以獲得任意域名播放支持

今晚我那邊是準備進行嘗試支持的

編輯：00:00

做了一晚上，但是緩存跳轉的時候還是沒有cors，所以選擇放棄

--大半年後的修改--

時隔這麼久再回來重看

作者已經離開b站繼續學習，然後我找著報問題也順便算是爬上了大腿（不

在下不才，五一的時候用非常混亂的方法給flvjs加了個mp4 demuxer，於是做出了一個同時能播放分段flv和分段mp4的版本，還成功體驗了一把mp4格式的box天堂（

順手完成了一個優酷播放器（做了個庫好歹得有個成品對吧，不然都沒有什麼成就感的）

我不在乎什麼flash烤大腿之類的，反正神船滿載也就50-60度。。。我在意的是！

HTML5開幾十個視頻不崩潰啊！

flash超過7個必死無疑！

我就說一句，能做出來這個，確實很值得驕傲和自豪，而且這個的過程，確實值得敬佩。

前排膜qianqian。@謙謙

個人曾經也想寫過這麼一個項目，但是由於對mp4封包不清楚以及其他問題，就沒有做，估計自己如今做也需要花巨量的時間。

說實話，能寫出這麼一個東西出來，絕對算得上是一線大牛，首先js過關，然後要極其熟悉html5的video和audio的解碼api，最後要精通flv和mp4的解封包格式，看過flvjs的代碼風格，這個人絕對算的上可以。

對於flv.js的作用，個人持看中立態度，首先，這個東西有必要存在，為什麼這麼說呢，首先，國內直播主要傳輸協議都是httpflv，因為httpflv擁有極低的延時和極好的穿透性，還有，flv這個封裝格式極其簡單，對伺服器開發人員友好。所以，國內主流直播平台都是httpflv為主線路，比如鬥魚熊貓。然而，html5可不支持flv格式的解碼，所以，前有hls.js,後有flv.js，就是通過html5，獲取http視頻流數據，比如獲取flv格式流數據，然後解包flv至aach264，然後再次封包成mp4，mp4就直接能用html5播放了，值得注意的是整個過程可用了N多html5技術。

但是這麼做有缺點，那就是耗費cpu，首先，js這個東西，算不上快，而且是單線程，解flv然後封裝為mp4，餵給html5，這是個既簡單也算複雜的計算過程，有點耗費cpu的，所以，低端設備比如手機，這個東西就別想了，甚至在pc瀏覽器端，這也並不是一個很優秀的選擇，用優化過後的flv.js和flash來播放一段httpflv流，flash佔用cpu反而稍微低一點點。

最後，反正flash詬病很多，總要被淘汰的，而如今直播協議中，延時低且具有http穿透性而且封裝簡單，那首當其衝的就是httpflv了，flv.js算是歷史長河中應有的存在。

貌似熊貓tv的pc端，也有這個的直播技術了，用上了html5播放器來播放httpflv。

flv.js 爆出來就知道作者是大牛 B站不是損失 B站是自己拋棄了一個大牛，然而之前他們只給這個大牛5000RMB ，同時也曝光了一系列公司制度問題。聽著挺滲人的。

不錯的開源項目。不過更有可能成為一個試驗性的和備用的方案。

本質上來說這個是依賴於 Media Source Extensions 這個實現的，詳情參考 Media Source Extensions

這就意味著這個東西在移動端上要面對 ios safari 這個無解的東西，從而把 flv 在瀏覽器中播放帶給移動端的可能性在短期內斬斷了。

在實現思路上來講，比較接近 hls.js ，就是自己拉取視頻資源切片然後拼接餵給 video 元素。

最後非常希望這項目能長久的走下去，因為這是我看到的又一次對 flash 和視頻網站解決方案積極挑戰。還有，它是開源的、開源的、開源的！

上hackernews首頁了厲害

解決了mac看B站電腦起飛的問題

順便補一句，自打各大視頻網站開啟了彈幕功能，我只要一打開彈幕功能電腦就起飛了，想想，還是B站良心，作為一隻不入流混跡在RTB公司的前端汪，沒少和視頻打交道，已經把部分視頻播放替換成flv.js 過程不太順利期待更好

去BAT迎娶白富美走上人生巔峰啦！

媒體擴展發展了好幾年，但是還是比我想像中弱很多，flv.js之前只是有人成功的支持過dash，dash的問題在於直播延時過大，player這一邊基本又只有dash.js可用，實在是讓人不能有更多想法。

ISO BMFF實際上是一個變種的fragment mp4格式，支持直播最好的方案應該就是直接在瀏覽器做remux了。

http-flv又比較好的解決了http的傳輸問題，如果直播延遲可以控制的話，flv.js算真正的是解決了h5直播的最後一公里問題。為作者無私的貢獻點贊。

另外可能這個仍然不是延遲最低的解決方案，最好的辦法應該是在伺服器直接打包iso bmff，但是這樣伺服器端基本就沒有通用解決方案了。

很好。我國內的谷歌瀏覽器能上B站了。哈哈。

雖然我不知道這是多麼厲害的一大壯舉，但是看各位的回答總感覺很牛很牛的樣子，膜拜一下

大兄弟你知道hls.js嗎