做者:Anton Garcia Diaz翻譯:瘋狂的技術宅前端
原文:https://www.freecodecamp.org/...程序員
未經容許嚴禁轉載web
網絡視頻一直都很火。雖然在頁面上嵌入 Instagram 和 Youtube 視頻很是簡單,可是有愈來愈多的需求 —— 好比許多電子商務的場景 —— 要求定製的視頻傳輸方法。面試
在設置視頻處理和傳輸管道時,首先要考慮的是要服務的視頻格式。 用戶體驗、支持(瀏覽器和系統)、壓縮效率或編碼速度等方面可能與此項選擇相關。segmentfault
根據我 web 商業媒體優化的經驗,我將會試着強調須要考慮的主要方面。若是你正在尋找關於使用 ffmpeg 的簡單轉碼和優化選項,你還能夠查看這篇文章。瀏覽器
與一般的圖像格式相比,意識到容器和編碼標準之間的區別是很是重要的。文件擴展名只能告訴咱們它屬於哪一個容器,而不是使用哪一個編解碼器。所遵循的編碼標準決定了瀏覽器或系統是否支持它。安全
例如,雖然 Web 視頻格式通常都用了 mp4 容器和 H264 標準進行編碼,但並不是每一個 mp4 文件都能受到廣泛支持,由於它可能採用了不一樣的標準編碼,如 H265。服務器
它甚至在自適應比特率(ABR)方面變得更加複雜,這爲響應用戶的網絡和設備功能帶來了最佳方式。微信
讓咱們看一下容器,編碼和交付標準的主要組合,以及它們在支持、壓縮效率、編碼速度和用戶體驗方面的差別。網絡
視頻格式之王採用帶有 H264/AVC 編碼的mp4容器。有時你也會在 m4v 容器(Handbrake 中的默認格式)中看到它,這是 Apple 爲具備 DRM 保護的 H264 視頻開發的 mp4 衍生產品。
每一個瀏覽器和系統 —— 以及iOS和Android中的本機應用程序 —— 都支持這種格式。這是避免兼容性問題的安全選擇。
此外,幾乎全部臺式機和移動設備都支持 H264 的硬件加速。編解碼速度很快。、
總而言之,對這種格式編碼和使用都很是簡單。與圖像同樣,你只需用 HTML5 插入視頻連接,就能夠在任何瀏覽器下使用。
大約 2000 kbps 和超過幾秒的延遲時間可能會影響視覺質量。當經過移動網絡或網絡高峯時段觀看時,可能會出現停頓和從新緩衝。若是使用下降圖像質量的方案將會產生模糊、飛蚊或塊狀之類的僞影。
這是一種使用相同的容器並用 H265 HEVC 編碼的強大的視頻格式,能夠產生更高的壓縮效率(體積減小約50%),除了模糊以外的其餘問題要小得多。這種格式的主要問題在於支持僅限於 Apple 設備,其中包括其價格中的高額版稅。幾乎只有 Safari 和 iOS 應用才能使用它。若是你有許多 iPhone 或 Mac 用戶,能夠把它做爲 H264 的後備版。他們的體驗會更好。
即便用了硬件加速(幾乎只在Apple設備中可用)這種格式更高的複雜性意味着會使編碼速度明顯變慢 ,所以生成交付文件須要更多的運算和時間。
這是 Google 提供的免費開源的視頻格式。它使用 webm 容器代替 mp4,基本上是 mkv 容器,但將編碼標準設置爲 VP8 或 VP9。用 H265 也能帶來相似的好處,也許是效率低一點但與 H264 相比仍然要多得多。一樣,它容許減小大小,除了模糊以外的僞影要小得多。編碼速度相似於 H265,這很慢。
注意,雖然之前的版本(VP8)也有相同的支持,但咱們根本不推薦,由於它不會給已經廣泛支持的 H264 帶來任何好處。只有經過 VP9 編碼才能使用 webm。
固然,對 webm 的支持僅限於 Google 的世界。這意味着只有 Chrome 和 Android 纔會支持。
該標準的第一個穩定版本於 2018 年 3 月發佈,其中包含 MP4 和 MKV 容器的映射。與 H265 相比,它能夠提供類似或稍高的壓縮效率增益,同時許可免費。與 H265 相比,最後的實現也提升瞭解碼速度,AV1 是 web 視頻傳輸的一個引人注目的替代品
參與建立該格式的開放媒體聯盟承諾不久的未來爲其提供普遍的支持。
參與 AV1 的開放媒體聯盟合做夥伴
可是,目前可用的實現應該仍然是實驗性的,其瓶頸仍然是編碼速度。缺少硬件加速顯然是一個問題,預計今年年末將有第一個解決方案。
負責 H264 AVC 和 H265 HEVC 的委員會正在快速追蹤新標準,預計將於 2020 年發佈。目前所考慮的方法的初步測試與 H265 和 AV1 相比性能已顯着增長。我把它做爲一個將來主義的可能性包含在這裏,只是爲了代表視頻編碼的競爭彷佛遠未結束。
這是漸進格式的一個很是有趣的替代方案。它創建在基於 HTTP 的媒體流通訊協議之上。這種方法把視頻做爲主播放列表提供。播放列表可提供具備不一樣的分辨率和比特率的選項,可知足不一樣的視口大小、網絡帶寬和設備。
此外,視頻被分紅片斷或塊,以便客戶端能夠從一個質量級別跳轉到另外一個質量級別。它可以適應用戶當前的條件,即網絡速度,也適應視口大小 —— 如切換到全屏。
ABR 爲優化移動設備的用戶體驗帶來了巨大的優點,避免了在移動網絡下的停頓或從新緩衝。若是你正在尋找真正的響應式的行爲,這顯然是應該採起的方法。它有兩個主要標準:HLS 和 MPEG-DASH。
儘管人們廣泛認爲 ABR 只對很長的視頻有意義,但根據個人經驗,不少狀況下至關短的剪輯也能夠從這種方法中受益。
由 Apple 開發,這種 ABR 協議依賴於以 mp4 格式分割的不一樣再現。最初使用 H264,如今也支持 H265。可是做爲折衷方案,我建議堅持對 HLS 使用 H264 編碼,由於它能夠在各類客戶端案例中實現更好的兼容性。
這個標準的一個重點是最近的 Apple 設備的支持。對於 Safari 或本機 iOS 應用之外的客戶端,你須要一個 viewer。但這不是個大問題,由於有很好的開源選擇,好比 videojs。或者你須要付出一些努力,來定製它並將其用於本身的前端程序。另外還提供很棒的轉碼和傳送服務,爲你完成全部這些工做提供方便。
因爲每一個播放應該以恆定的比特率編碼,因此我建議將 HLS與 per-title encoding 結合使用。 也就是說,基於視頻的內容選擇播放的比特率。
這是針對 ABR 的編解碼器無關的協議,所以除了 H264 和 H265 以外,它還能夠用 VP9 編碼,甚至可使用 AV1 等新的替代方案。缺點是它的相對年輕,這意味着與 HLS 相比支持較少。這就是爲何咱們不建議大多數 Web 企業使用它的緣由。
多年來 H264 AVC 壓縮的優點很明顯,新的方法正在 web 視頻增添動力。在顯示尺寸和分辨率方面的競爭促進了新格式的發展,可以在相同帶寬下提供更多的內容。
webm 中的 VP9 對壓縮效率有着顯着的提高(約30%),沒有版權問題,並且受到 Google 解決方案(Chrome,Android)的支持。更進一步來講,與 H264 相比,H265/HEVC 只用了一半的比特率就達到了至關的主觀質量。因爲它們都沒有被廣泛支持,所以仍然須要 H264,至少做爲後備方案。
自適應比特率是一種引人注目的替代方案,可提供無與倫比的用戶體驗。在這方面,HLS 在開源 viewers 的幫助下獲得了普遍的支持。它多是中型網絡的最佳選擇。因爲 videojs 等開源計劃,以及可以提供極具競爭力價格的第三方服務,顯着減輕了 viewer 的需求所帶來的複雜性。若是你採用最後一條技術路線,請務必要求 per-title encoding。