優化視頻的大小和質量

在過去的幾年裡，越來越多的項目將視頻作為應用程序的一個組成部分。 這是一個很好的方向，因為視頻比靜態照片更具吸引力（視頻可以使轉化率翻倍並增加在網站上花費的時間），因此可以真正吸引客戶探索有關產品和服務的細節。 但是，當出現與視頻播放相關的問題時，這一切都會發生。

視頻播放問題與視頻的大小和比特率直接相關。 大尺寸或高比特率的視頻下載時間會更長，並且需要更高速度的網絡才能流暢播放。 這會導致更長的啟動時間，如果網絡不能足夠快地提供視頻，視頻將在視頻播放期間停止。

不過有解決辦法！ 通過在將視頻添加到我們的網站之前對其進行基本優化，我們可以永久防止這些問題的發生——嗯，大部分都是這樣。 我們真正需要做的就是以一種或另一種方式使文件更小。 所以，現在的訣竅是：我們如何在不降低質量的情況下使文件更小？

在本文中，我們將介紹您可以採取哪些工具和一些步驟來優化您的視頻以供播放- 所有這些都是為了避免停頓並給您的寶貴客戶留下深刻印象！

真實世界數據

找到具有超大視頻的網站並不罕見 - 例如，用作英雄背景視頻。 在我的研究中，我正在研究 2020 年 12 月的移動 HTTPArchive 中發現的網站，不難發現很多網站默認加載巨大的視頻文件，無論是在移動設備上還是在桌面設備上。

當然，您能否實現與我將在此處展示的相同的節省，這是值得懷疑的，但您會在處理視頻時獲得一些有用的指示和提示。 事實上，如果您不小心，很容易在您的網站上意外放置超大視頻，導致大多數客戶幾乎無法使用它們。

南瓜補丁的故事

想像一下現在是 10 月中旬，您正在尋找一塊南瓜地和一個玉米迷宮，以便與家人度過一個週末的下午。 在舒適的台式機上，您可以在網上搜索附近的位置並找到完美的位置。 該網站看起來很可愛，頁面頂部播放了一段漂亮的無人機 4K 視頻。 您選擇 URL 並將其發送給您自己和您所愛的人，這樣您就可以在旅途中繼續探索此選項。

但是當您在手機上打開頁面時，您會注意到一個小故障：視頻正在拼命嘗試在您的手機上播放，但不幸的是未能播放。 視頻不斷停頓並一遍又一遍地重新啟動，比在您的計算機上更具破壞性和煩人。 最終，您繼續前進，為 URL 添加書籤，然後繼續您的日常工作。

在度過了有趣的泥濘的一天（好吧，我最近住在西雅圖和英國，所以南瓜地很泥濘），你又回到了你的電腦上：也許你又想起了那個視頻，你想知道為什麼它沒有播放在你的手機上。 好吧，讓我們診斷一下發生了什麼。

您可以從在瀏覽器中打開 DevTools 開始。 加載頁面後，我們可以移動到網絡選項卡，並按“媒體”過濾以查看所有視頻文件：

我們看到正在下載一個 MP4 文件。 該文件不是作為獨立文件通過網絡傳輸的； 相反，流服務必須將文件分成幾個片段，因此您可能會看到對同一文件的多個206 （部分內容）請求。

查看此文件的響應標頭，我們可以發現一些細節：

 accept-ranges: bytes access-control-allow-headers: x-test-header, Origin, X-Requested-With, Content-Type, Accept access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS Content-Length: 87690242 Content-Range: bytes 70025216-157715457/157715458 content-type: video/mp4 date: Fri, 22 Jan 2021 15:27:26 GMT last-modified: Mon, 24 Jun 2019 05:13:04 GMT server: Apache

現在，其中一些數字有點嚇人，因為它們有點大。 事實上，它們通常很大，以至於我發現自己養成了添加逗號的習慣，因此我可以了解文件的實際大小。 在這種情況下，部分下載為 87 MB，整個文件為 157,715,457 字節。 是的，沒錯，這個視頻是 157MB，今天早些時候它（嘗試）加載到我的手機上！ 難怪沒有成功。

那麼這個視頻是怎麼回事？

讓我們深入一點。 顯然，視頻太大，無法在內存較低且網絡較慢的手機上流暢播放。 但是我們需要解決什麼問題呢？ 為了弄清楚究竟是什麼問題，我們可以使用開源和免費的 FFMPEG，它被證明是優化視頻的最可靠工具之一。 我們可以無休止地調整 FFMPEG 中的配置，但讓我們在本文中只涉及一些重要的配置。

那麼，讓我們從名為 FFprobe 的診斷工具開始。 FFprobe 從多媒體流中收集信息，並為您提供有關視頻編碼方式和播放方式的詳細信息。 它是 FFMPEG 包的一部分，實際上非常易於使用。

更好的是：如果您的視頻已經在線，我們可以立即跳轉到 ffprobe 的在線版本。 因此，讓我們在表單中輸入 URL，然後獲取有關視頻的詳細信息（例如視頻尺寸、比特率和相當多的元數據）。

當我從南瓜農場添加 MP4 URL 時，我們立即看到了其中一個問題。 來自 ffprobe 的show_format響應返回一個摘要：顯然，有 2 個流，長度為 62 秒（這聽起來很正常，不會引起任何懷疑）。 但是當我們得到size 和 bitrate時，我們會立即看到視頻失敗的地方。

如上所述，習慣於為這些大數字添加逗號可能是個好主意。 事實證明，在場地上空飛行的無人機鏡頭確實是 157MB，比特率是每秒 20MB！ 這意味著要無縫播放視頻，網絡必須能夠以高於 20 MBPS 的速率傳輸視頻，這正是它在手機上停滯不前的原因。

理想的播放比特率是多少？

為了避免停頓，我們需要以適當的速率流式傳輸視頻。 這就是比特率變得重要的地方。 比特率是視頻的播放速度。 為了讓瀏覽器流暢地播放視頻，視頻的下載速度必須快於播放速度——這意味著視頻只有在網絡速度超過 20 MBPS 時才能流暢播放。 當我想到網絡速度時，我傾向於依賴 WebPageTest 的流量配置文件：

從上面的概述中我們可以看出，視頻可能在“本地連接”和超快光纜 FIOS 連接上播放良好（20 MBPS 正是所需的速度，所以希望不需要在背景）。 但是，所有其他連接的下行速度都明顯低於 20 MBPS 。 如果視頻以這些速度加載，播放器將嘗試以比下載速度更快的速度消耗視頻，並且視頻將永久停止。

視頻的比特率設置了客戶可以使用的最低網絡速度。 一般來說，視頻的比特率應該是網絡上可用吞吐量的 80% 左右。 因此，20 MBPS 的視頻確實需要 24 MBPS 的網絡吞吐量才能無縫播放視頻。 連接速度較慢的每個人的體驗都會很差，並且可能根本無法觀看視頻。 更具體地說，這意味著我們要在 4G 上流暢流暢地播放，比特率必須保持在 7.2 MBPS 以下。

我們可以降低此視頻的比特率嗎？

是的！ 讓我們看看我們可以用來降低此視頻比特率的一些配置。 但首先，讓我們看看我們從 FFprobe 獲得的數據。 非常值得注意的一件事是r_frame_rate值，它是視頻中每秒的幀數。 其值為 60000/1001。 這意味著視頻的幀速率為每秒 60 幀。 但是，網絡上的典型幀速率是 25–30，所以我們可以做的第一件事就是用較低的比特率重新編碼視頻。

要記住的另一件事是恆定速率因子。 在 FFMPEG 中，主要的質量/大小基準是恆定速率因子 (CRF) 壓縮，其值範圍從0 （無壓縮）到50 （高壓縮）。 FFMPEG 中 CRF 的默認值為23 （如果省略 CRF 參數，您的視頻將使用該值）。 以我個人的經驗，23-28 的值仍然可以產生高質量的視頻，在網絡上看起來不錯並且文件大小大大減小。

所以讓我們從 30fps 和23的 CRF 開始。 終端命令將如下所示：

 ffmpeg -i input.mp4 -vcodec h264 -acodec aac -crf 23 -strict -2 :v fps=fps=30 output.mp4

瞧！ 這會產生一個 81.5 MB 的視頻——已經提高了 48%。 但視頻仍然很大，比特率為 10 MBPS。 如果我們將 CRF 設置為 28，則文件將下降到 35.4MB，比特率為 4.5 MBPS，這在 4G 連接上更有可能播放良好。

這是對原始視頻的五倍改進。 為了使該視頻更易於訪問，我們可以調整視頻的大小以使其更小。 這就是我們將在下面的流媒體部分討論的內容。

餓了比薩的故事

想像一下，您在洛杉磯，可能從國外訪問並在手機上漫遊，當然還想吃一片披薩。 你在手機上找到了一個很棒的披薩店，並決定前往那裡。 您可能已經註意到頁面上的一些視頻和英雄圖片，但實際上，每個披薩店看起來都一樣，所以您沒有費心觀看視頻。 在返回酒店之前，您先去拿一兩片。

那天晚上，您從運營商那裡收到一條短信，說您使用的數據比您想像的要多得多（而且絕對比您最初計劃的要多！）。 幾輛出租車，還有比薩網站——比薩網站又貴了多少？

您將披薩網站彈出到 WebPageTest 並在移動連接上檢查它：

44 MB 的視頻。 它來自哪裡？ 除此之外，當我們更詳細地檢查源和瀑佈時，我們可以看到實際上有兩個視頻！ 幸運的是（或不幸的是？），兩者都未能完全下載：

這引起了一些擔憂和一些問題。

首先，為什麼沒有自動播放時下載了這麼多視頻？ 我們還沒有設法點擊任何東西，但已經使用了近 40 MB 的數據。 一如既往，答案在於源頭。 嗯，“查看源代碼”，就是這樣。

 <video class="video-js vjs-big-play-centered" controls preload="auto" width="1050" height="591" poster="assets/home_poster.jpg" data-setup='{"fluid": true}'>
  <source src="assets/home_1.mp4" type='video/mp4'> <source src="assets/home.webm" type='video/webm'>
  <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p> </video>

馬上，我們至少看到兩個問題：

• 預載=“自動”
  當我們設置preload="auto"時，我們將覆蓋瀏覽器的默認設置，強制執行視頻下載——無論您的客戶是否按下了“播放”。 默認的preload屬性是metadata ，並且會導致下載幾個 100KB。 誠然，對於永遠不會觀看此視頻的網站訪問者來說，這是一個更好的結果。
• 視頻訂購
  如果您有多個版本的視頻（在這種情況下：h264 .mp4 和 VP8 .webm 編碼的視頻），瀏覽器將選擇它知道如何播放的第一個視頻。 現在，每個現代瀏覽器都支持 mp4，而大多數現代瀏覽器也支持 webm（根據 CanIUse 的數據，全球支持率為 95.4%）。

我喜歡使用的一個技巧是使用 Javascript 插入適當的視頻源代碼行。 這樣，如果您選擇不在某些屏幕上提供視頻，那麼您只有一個空的 <video> 標籤——並且無法下載任何視頻。

window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }

如果我們現在對這兩個視頻運行 ffprobe，我們會發現大小的顯著差異：

webm 小了 90%，但瀏覽量為 0 ，因為每個瀏覽器都支持 mp4。 這兩個視頻都是 640×360 和 140 秒長。 在 mp4 上運行ffmpeg命令會生成 12.4 MB 的視頻，因此開發人員很可能也遵循了類似的過程來壓縮和編碼 .webm 變體。 也許擁有 12.5 MB 的preload="auto"畢竟不會那麼糟糕。

第二個視頻（餐廳內的無人機鏡頭）以全高清 (1080p) 拍攝，但同樣從 140MB 壓縮到 35MB。 因此，使用 FFMPEG 的 120s 可以將此頁面上的視頻重量從 160 MB 減少到 57 MB。 翻轉 webm/mp4 順序將為 95% 可以支持該格式的瀏覽器節省額外的幾 MB。

如果我們想要做得更好，也許讓視頻響應各種尺寸的屏幕怎麼辦？ 好吧，讓我們製作更小的視頻 - 使用響應式視頻！

<video> 標籤不支持媒體查詢來為不同的屏幕提供不同的視頻文件，因此我們需要一種不同的方式來提供適合設備屏幕大小的視頻。 實現這一目標的最簡單方法是使用視頻流。 這將為需要的視頻播放器添加一些 Javascript 和其他資產，但視頻節省肯定會彌補這些額外的數據。

我們可以使用 FFMPEG 創建視頻流（我過去曾使用過這樣的 bash 腳本），但這需要我們知道我們想要使用的所有大小和設置（如前所述，FFMPEG 有很多設置！ ）。

為了更輕鬆地流式傳輸視頻，您可以在其中上傳視頻的 API（例如 api.video 和 Mux），這些工具會為您創建視頻流並託管您的視頻。 完整的披露，我確實在前一個工作，所以為了簡化我的視頻處理管道，我將使用 api.video 來轉碼和託管我的視頻。 使用上傳 API，我可以上傳任何視頻，該工具將創建許多不同尺寸和比特率（目前為 240p、360p、480p、720p、1080p 和 4K）的流媒體版本。

隨著視頻尺寸的減小，較小視頻的比特率會大大降低。 這意味著視頻在較小的屏幕上需要較少的網絡容量，並將在較慢的網絡上播放。

為簡潔起見，我們將僅測試南瓜補丁視頻。 我收到了與無人機視頻類似的結果（另一個比薩視頻只有 360p，因此它不會從較小的尺寸中受益）。

注意：請記住，該視頻目前是 60fps 的 1080p mp4 視頻，所有訪問者的大小為 157 MB。

通過一些優化（CRF 28 並將幀速率降低到 30fps），視頻減少到35.7 MB 。 使用 DevTools，我們可以模擬設備以查看在不同大小的屏幕上播放流視頻的視頻使用了多少數據。

下表顯示了使用的總流量。 對於 HLS 視頻，有一個 JavaScript 播放器、CSS、字體等會增加大約 1 MB 的額外開銷。 這包括在以下總數中：

在 1080p 時，為流下載了大約 4MB 的額外資源，但對於其他大小，可以節省大量數據，而不會損失視頻質量。 不僅視頻大小適合設備，而且停頓的可能性要小得多，因為最有可能在較慢的移動連接上的設備的比特率降低了。

視頻流處理幀速率、視頻大小和質量問題——確保在任何尺寸的屏幕和任何速度的網絡上都能快速播放。

“

視頻流的另一個優勢：如果網絡速度較慢（或突然變慢），播放器可以調整正在顯示的視頻，並播放較低質量的視頻版本——確保在設備上播放——即使在網絡條件較差的情況下也是如此。 （您可以使用 StreamOrNot 測試不同的視頻，這是我不久前發布的一個小型開源項目。

現在，是不是有點太多的開銷？ 我們不能用 YouTube 或 Vimeo 做同樣的事情（只是更快）嗎？ 我們當然可以，但是我們無法從視頻中完全刪除品牌或廣告，更不用說在視頻播放器 iframe 中加載的腳本開銷了。 另外，有時您可能希望將視頻用作產品頁面上的背景視頻，並完全避免使用任何類型的外部品牌。

結論

我們不會將相機中的圖像直接部署到網絡上，但我們會壓縮和調整它們的大小以平衡質量和網絡性能。 視頻文件也應該這樣做。 較小的視頻開始播放速度更快，停頓的頻率更低，從而改善了網站的用戶體驗。

在本文中，我們通過幾個簡單的步驟來優化我們的視頻，例如降低質量和幀率。 我們還研究了視頻流如何讓我們為 Web 構建響應速度更快的視頻體驗——自動提供適合設備屏幕大小的視頻。

感謝您的閱讀，如果您想了解更多信息，您可能想在此處、Smashing Magazine 和我的博客上閱讀更多有關視頻最佳實踐的信息：

• Web 上的視頻播放：視頻的當前狀態（第 1 部分）
• Web 上的視頻播放：視頻交付最佳實踐（第 2 部分）
• 在移動網絡上隱藏視頻