網絡視頻一直都很火。雖然在頁面上嵌入 Instagram 和 Youtube 視頻非常簡單，但是有越來越多的需求 —— 比如許多電子商務的場景 —— 要求定制的視頻傳輸方法。下面濟南網站建設 文匯傳媒小編帶大家了解下Web視頻格式。
在設置視頻處理和傳輸管道時，首先要考慮的是要服務的視頻格式。 用戶體驗、支持（瀏覽器和系統）、壓縮效率或編碼速度等方面可能與此項選擇相關。。
容器和編解碼器
與通常的圖像格式相比，意識到容器和編碼標準之間的區別是非常重要的。文件擴展名只能告訴我們它屬于哪個容器，而不是使用哪個編解碼器。所遵循的編碼標準決定了瀏覽器或系統是否支持它。
例如，雖然 Web 視頻格式一般都用了 mp4 容器和 H264 標準進行編碼，但并非每個 mp4 文件都能受到普遍支持，因為它可能采用了不同的標準編碼，如 H265。
它甚至在自適應比特率（ABR）方面變得更加復雜，這為響應用戶的網絡和設備功能帶來了最佳方式。
讓我們看一下容器，編碼和交付標準的主要組合，以及它們在支持、壓縮效率、編碼速度和用戶體驗方面的差異。
漸進式視頻
H264/AVC
視頻格式之王采用帶有 H264/AVC 編碼的mp4容器。有時你也會在 m4v 容器（Handbrake 中的默認格式）中看到它，這是 Apple 為具有 DRM 保護的 H264 視頻開發的 mp4 衍生產品。
每個瀏覽器和系統 —— 以及iOS和Android中的本機應用程序 —— 都支持這種格式。這是避免兼容性問題的安全選擇。
此外，幾乎所有臺式機和移動設備都支持 H264 的硬件加速。編解碼速度很快。、
總而言之，對這種格式編碼和使用都非常簡單。與圖像一樣，你只需用 HTML5 插入視頻鏈接，就可以在任何瀏覽器下使用。
大約 2000 kbps 和超過幾秒的延遲時間可能會影響視覺質量。當通過移動網絡或網絡高峰時段觀看時，可能會出現停頓和重新緩沖。如果使用降低圖像質量的方案將會產生模糊、飛蚊或塊狀之類的偽影。
H265/HEVC
這是一種使用相同的容器并用 H265 HEVC 編碼的強大的視頻格式，可以產生更高的壓縮效率（體積減少約50％），除了模糊之外的其他問題要小得多。這種格式的主要問題在于支持僅限于 Apple 設備，其中包括其價格中的高額版稅。幾乎只有 Safari 和 iOS 應用才能使用它。如果你有許多 iPhone 或 Mac 用戶，可以把它作為 H264 的后備版。他們的體驗會更好。
即使用了硬件加速（幾乎只在Apple設備中可用）這種格式更高的復雜性意味著會使編碼速度明顯變慢 ，因此生成交付文件需要更多的運算和時間。
VP9
這是 Google 提供的免費開源的視頻格式。它使用 webm 容器代替 mp4，基本上是 mkv 容器，但將編碼標準設置為 VP8 或 VP9。用 H265 也能帶來類似的好處，也許是效率低一點但與 H264 相比仍然要多得多。同樣，它允許減少大小，除了模糊之外的偽影要小得多。編碼速度類似于 H265，這很慢。
注意，雖然以前的版本（VP8）也有相同的支持，但我們根本不推薦，因為它不會給已經普遍支持的 H264 帶來任何好處。只有通過 VP9 編碼才能使用 webm。
當然，對 webm 的支持僅限于 Google 的世界。這意味著只有 Chrome 和 Android 才會支持。
AV1
該標準的第一個穩定版本于 2018 年 3 月發布，其中包含 MP4 和 MKV 容器的映射。與 H265 相比，它可以提供相似或稍高的壓縮效率增益，同時許可免費。與 H265 相比，最后的實現也提高了解碼速度，AV1 是 web 視頻傳輸的一個引人注目的替代品
參與創建該格式的開放媒體聯盟承諾不久的將來為其提供廣泛的支持。
參與 AV1 的開放媒體聯盟合作伙伴
但是，目前可用的實現應該仍然是實驗性的，其瓶頸仍然是編碼速度。缺乏硬件加速顯然是一個問題，預計今年年底將有第一個解決方案。
VVC
負責 H264 AVC 和 H265 HEVC 的委員會正在快速追蹤新標準，預計將于 2020 年發布。目前所考慮的方法的初步測試與 H265 和 AV1 相比性能已顯著增加。我把它作為一個未來主義的可能性包含在這里，只是為了表明視頻編碼的競爭似乎遠未結束。
自適應比特率（ABR）
這是漸進格式的一個非常有趣的替代方案。它建立在基于 HTTP 的媒體流通信協議之上。這種方法把視頻作為主播放列表提供。播放列表可提供具有不同的分辨率和比特率的選項，可滿足不同的視口大小、網絡帶寬和設備。
此外，視頻被分成片段或塊，以便客戶端可以從一個質量級別跳轉到另一個質量級別。它能夠適應用戶當前的條件，即網絡速度，也適應視口大小 —— 如切換到全屏。
ABR 為優化移動設備的用戶體驗帶來了巨大的優勢，避免了在移動網絡下的停頓或重新緩沖。如果你正在尋找真正的響應式的行為，這顯然是應該采取的方法。它有兩個主要標準：HLS 和 MPEG-DASH。
盡管人們普遍認為 ABR 只對很長的視頻有意義，但根據我的經驗，很多情況下相當短的剪輯也可以從這種方法中受益。
HLS
由 Apple 開發，這種 ABR 協議依賴于以 mp4 格式分割的不同再現。最初使用 H264，現在也支持 H265。但是作為折衷方案，我建議堅持對 HLS 使用 H264 編碼，因為它可以在各種客戶端案例中實現更好的兼容性。
這個標準的一個重點是最近的 Apple 設備的支持。對于 Safari 或本機 iOS 應用以外的客戶端，你需要一個 viewer。但這不是個大問題，因為有很好的開源選擇，比如 videojs。或者你需要付出一些努力，來定制它并將其用于自己的前端程序。另外還提供很棒的轉碼和傳送服務，為你完成所有這些工作提供方便。
由于每個播放應該以恒定的比特率編碼，所以我建議將 HLS與 per-title encoding 結合使用。 也就是說，基于視頻的內容選擇播放的比特率。
MPEG-DASH
這是針對 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。
希望這幾個 CSS 小知識可以對你有所幫助，然后給濟南小編點個贊再走唄！
