Web 上的視頻播放：視頻交付最佳實踐（第 2 部分）

在我之前的帖子中，我使用 HTTP 存檔中的數據檢查了今天網絡上的視頻趨勢。 我發現許多網站在移動設備和桌面設備上提供相同的視頻內容，而且許多視頻流的傳輸比特率太高而無法在 3G 速度連接上播放。 我們還發現，網站可能會自動將視頻下載到移動設備上，這會損害客戶的數據計劃、電池壽命，因為這些視頻可能永遠不會播放。

TL;DR ：在這篇文章中，我們著眼於優化視頻速度和向客戶交付的技術，並提供 9 種最佳實踐列表來幫助您交付視頻資產。

視頻播放指標

目前使用的主要視頻播放指標有 3 個：

1. 視頻啟動時間
2. 視頻停頓
3. 視頻質量

由於視頻文件很大，將視頻優化為盡可能小將導致更快的視頻傳輸，加快視頻啟動，減少停頓的數量，並最大限度地減少傳輸視頻質量的影響。 當然，我們需要平衡啟動速度和停頓與第三個質量指標（更高質量的視頻通常使用更多數據）。

視頻啟動

當用戶在視頻上按下播放鍵時，他們希望能夠快速觀看視頻。 根據 Conviva（視頻指標分析的領導者）的數據，在 2018 年第一季度，14% 的視頻在用戶按下播放後從未開始播放（即 24 億次視頻播放）。

2.3% 的視頻（4 億視頻請求）在用戶按下播放按鈕後無法播放。 11.54%（2B 播放）在按下播放後被用戶放棄。 讓我們嘗試分解可能導致這些問題的原因。

視頻播放失敗

視頻播放失敗佔所有視頻播放的 2.3%。 什麼可能導致這種情況？ 在 HTTP 存檔數據中，我們看到 0.3% 的視頻請求會導致 4xx 或 5xx HTTP 響應——因此某些百分比的 URL 錯誤或服務器配置錯誤。 另一個潛在問題（在 HTTP 存檔數據中未觀察到）是被 Geolocation 阻止的視頻（根據觀看者的位置和提供者在該區域顯示視頻的許可而被阻止）。

視頻播放放棄

Conviva 報告指出，所有視頻播放中有 11.5%會播放，但客戶在視頻開始播放之前就放棄了播放。 這裡的問題是視頻沒有足夠快地交付給客戶，他們放棄了。 有很多關於移動網絡的研究，其中長時間的延遲會導致網頁被放棄，而且似乎視頻播放也會出現同樣的效果。

Akamai 的研究表明，觀眾會等待 2 秒，但隨後的每一秒，就有 5.8% 的觀眾放棄視頻。

那麼是什麼導致了視頻播放問題呢？ 一般來說，較大的文件需要較長的下載時間，因此會延遲播放。 讓我們看一下可以加快視頻播放速度的幾種方法。 為了減少啟動時放棄的視頻數量，我們應該盡可能“精簡”這些文件，以便它們快速下載（並開始播放）。

MP4：視頻預加載

為了確保在網絡上快速播放，一種選擇是提前將視頻預加載到設備上。 這樣，當您的客戶點擊“播放”時，視頻已經下載，播放速度會很快。 HTML 提供了一個帶有 3 個可能選項的預加載屬性： auto 、 metadata和none 。

preload = auto

當您的視頻使用preload="auto"交付時，瀏覽器會下載整個視頻文件並將其存儲在本地。 這可以大大提高視頻啟動的性能，因為視頻在設備本地可用，並且沒有網絡干擾會減慢啟動速度。

但是，只有在視頻被觀看的可能性很高時才應該使用preload="auto" 。 如果視頻只是駐留在您的網頁上，並且每次都被下載，這將為您的移動用戶增加大量數據損失，並增加您將整個視頻交付給所有用戶的服務器/CDN 成本。

該網站有一個名為“視頻庫”的部分，其中包含多個視頻。 本節中的每個視頻都將 preload 設置為auto ，我們可以將它們在 WebPageTest 瀑布中的下載可視化為綠色水平線：

有一個版塊叫做“視頻庫”，網站這小塊版塊的文件佔頁面下載量的 1460 萬（83%）。 播放一個（許多）視頻的機率可能非常低，因此使用preload="auto"只會為網站產生大量數據流量。

在這種情況下，即使其中一個視頻也不太可能被觀看，但所有視頻都已完全下載，從而為移動網站增加了 14.8MB 的內容（頁面內容的 83%）。 對於播放概率很高的視頻（可能 > 90% 的頁面瀏覽量會導致視頻播放）——預加載整個視頻是一個非常好的主意。 但是對於不太可能播放的視頻， preload="auto"只會通過您的服務器和客戶的移動（和桌面）設備導致額外的內容噸位。

preload="metadata"

當使用preload="metadata"屬性時，會下載視頻的初始片段。 這使播放器可以知道視頻窗口的大小，並可能下載一到兩秒鐘的視頻以立即播放。 瀏覽器只是對視頻內容進行 206（部分請求）。 通過在設備上存儲少量視頻數據，可以減少視頻啟動時間，而不會對傳輸的數據量產生很大影響。

在 Chrome 上，如果未選擇任何屬性，則元數據是默認選擇。

注意：如果視頻很大，這仍然會導致要下載大量視頻。

例如，在一個視頻設置為preload="metadata"的移動網站上，我們只看到一個視頻請求：

並且請求是部分下載，但它仍然導致要下載 2.7 MB 的視頻，因為完整的視頻是 1080p、150 秒長和 97 MB（我們將在下一節中討論優化視頻大小）。

因此，我建議preload="metadata"僅在用戶觀看視頻的可能性很高或視頻很小的情況下才使用。

preload="none"

最經濟的視頻下載選項，因為加載頁面時不會下載視頻文件。 這可能會增加播放延遲，但會導致初始頁面加載速度更快最終用戶明確要求。 在按下播放按鈕之前，嵌入網站的所有 YouTube 視頻都不會下載任何視頻內容，本質上就像preload="none"一樣。

預加載最佳實踐：僅當視頻被觀看的可能性很高時才使用preload="auto" 。 通常，使用preload="metadata"可以在數據使用與啟動時間之間提供良好的平衡，但應監控是否存在過多的數據使用。

MP4 視頻播放技巧

既然視頻已經開始播放，我們如何才能保證視頻播放可以優化到不卡頓並繼續播放。 同樣，訣竅是確保視頻盡可能小。

讓我們看一些優化視頻下載大小的技巧。 有幾個視頻維度可以優化以減小視頻的大小：

聲音的

視頻文件被分成不同的“流”——最常見的是視頻流。 第二個最常見的流是與視頻同步的音軌。 在一些視頻播放應用中，音頻流是分開交付的； 這允許以無縫方式交付不同的語言。

如果您的視頻以靜音方式播放（如循環播放的 GIF 或背景視頻），則從視頻中刪除音頻流是減小文件大小的一種快速簡便的方法。 在背景視頻的一個示例中，完整文件為 5.3 MB，但音軌（從未聽過）接近 300 KB（文件的 5%） 通過簡單地消除音頻，文件將快速傳遞，不會浪費字節。

在 HTTP 存檔中找到的 42% 的 MP4 文件沒有音頻流。

最佳實踐：從無聲播放的視頻中刪除音軌。

視頻編碼

對視頻進行編碼時，可以選擇降低視頻質量（每幀的像素數，或每秒的幀數）。 將高質量視頻縮減為適用於網絡很容易，並且通常不會影響交付給最終用戶的質量。 本文不夠長，無法深入討論可用於視頻的所有各種壓縮技術。 在x264和x265編碼器中，有一個術語稱為恆定速率因子 (CRF)。 使用 23-28 的 CRF 通常會提供良好的壓縮/質量折衷，並且是進入視頻壓縮領域的良好開端

視頻大小

視頻大小會受到許多維度的影響：長度、寬度和高度（您可能也可以在此處包含音頻）。

視頻時長

視頻的長度通常不是 Web 開發人員可以調整的功能。 如果視頻要播放三分鐘，那麼它將播放三分鐘。 在視頻特別長的情況下，諸如preload="none"或流式傳輸視頻之類的工具可以允許最初下載的數據量較少，以減少頁面加載時間。

視頻尺寸

在 HTTP 存檔中找到的所有視頻中有 18% 在移動設備和桌面設備上是相同的。 那些使用響應式網頁設計的人知道如何針對不同的視口優化圖像可以大大減少加載時間，因為對於較小的屏幕，圖像的尺寸要小得多。

視頻也是如此。 具有 30 MB 2560×1226 背景視頻的網站將很難在移動設備上下載視頻（也可能在桌面設備上！）。 調整視頻大小會大大減小文件大小，甚至可能允許提供三個或四個不同的背景視頻：

現在，不幸的是，瀏覽器不支持對 HTML 視頻的媒體查詢，這意味著這不起作用：

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

因此，我們需要創建一個小的 JS 包裝器來將我們想要的視頻傳送到不同的屏幕尺寸。 但在我們去那里之前……

下載視頻，但將其隱藏

對早期響應式網絡的另一個回歸是下載全尺寸圖像，但將它們隱藏在移動設備上。 您的客戶在下載大圖像時會遇到所有延遲（並會影響移動數據計劃，以及額外的電池消耗等），而實際看到圖像並沒有任何好處。 這種情況經常發生在移動設備上的視頻中。 因此，當我們編寫腳本時，我們可以確保較小的屏幕永遠不會請求一開始就不會出現的視頻。

視網膜質量視頻

對於不同的設備屏幕密度，您可能有不同的視頻。 這可能會導致將視頻下載給您的移動客戶的時間增加。 您可能希望阻止在較小屏幕設備或網絡帶寬有限的設備上播放 Retina 視頻，從而回退到這些設備的標準質量視頻。 網絡信息 API 等工具可以為您提供網絡吞吐量，並幫助您決定要為客戶提供的視頻質量。

根據設備大小和網絡質量下載不同的視頻類型

我們剛剛介紹了一些優化將電影傳送到小屏幕的方法，並且還注意到視頻標籤無法在視頻類型之間進行選擇，所以這裡有一個快速的 JS 片段，它將使用屏幕寬度來：

• 不在 500 像素以下的屏幕上投放視頻；
• 為 500-1400 屏幕提供小視頻；
• 向所有其他設備提供更大尺寸的視頻。

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

該腳本將用戶的屏幕分為三個選項：

1. 低於 500 像素，不顯示視頻。
2. 在 500 到 1400 之間，我們有一個較小的視頻。
3. 對於大於 1400 像素寬的屏幕，我們有更大的視頻。

我們的頁面有一個具有兩種不同尺寸的響應式視頻：一種用於移動設備，另一種用於桌面尺寸的屏幕。 移動用戶可以獲得出色的視頻質量，但文件只有 2.6 MB，而桌面視頻則為 10MB。

動畫 GIF

動畫 GIF 是大文件。 雖然 aGIF 和視頻文件都通過寬度和高度維度壓縮數據，但只有視頻文件具有壓縮（通常更大）時間軸。 aGIF 本質上是快速“翻閱”靜態 GIF 圖像。 這種缺乏壓縮會增加大量數據。 值得慶幸的是，可以用循環視頻替換 aGIF，從而為每個請求節省 MB 的數據。

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

在 Safari 中，有一種更奇特的方法：您可以在圖片標籤中放置一個循環播放的 mp4，如下所示：

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

在這種情況下，Safari 將播放動畫 GIF，而 Chrome（和其他支持 WebP 的瀏覽器）將播放動畫 WebP，並回退到動畫 GIF。 您可以在 Colin Bendell 的精彩文章中了解有關此方法的更多信息。

第三方視頻

將視頻添加到您的網站的最簡單方法之一是簡單地從視頻共享服務複製/粘貼代碼並將其放在您的網站上。 但是，就像將任何第三方添加到您的網站一樣，您需要警惕將哪種內容添加到您的頁面，以及這將如何影響頁面加載。 其中許多“簡單地將其粘貼到您的 HTML”小部件中添加了 100 KB 的 JavaScript。 其他人會下載整部電影（想想preload="auto" ），有些人會兩者兼而有之。

第三方視頻最佳實踐：信任但驗證。 檢查添加了多少內容，以及它對頁面加載時間的影響程度。 此外，行為可能會發生變化，因此請定期跟踪您的分析。

流媒體啟動

當請求視頻流時，服務器向播放器提供一個清單文件，列出每個可用的流（帶有尺寸和比特率信息）。 在 HLS 流中，播放器通常選擇列表中的第一個流開始播放。 因此，清單文件中首先定位的流應該針對移動設備和桌面設備上的視頻啟動進行優化（或者可能替代清單文件應該傳送到移動設備和桌面設備）。

在大多數情況下，通過使用較低質量的流開始播放來優化啟動。 一旦播放器下載了幾個片段，它就會更好地了解可用吞吐量，並且可以為後面的片段選擇更高質量的流。 作為用戶，您可能已經看到了這種情況——視頻的前幾秒看起來非常像素化，但在播放幾秒鐘後，視頻會變得清晰。

在檢查從 HTTP 存檔傳送到移動設備的 1,065 個清單文件時，我們發現 59% 的視頻具有低於 1.2 MBPS 的初始比特率 - 並且很可能以 1.6 MBPS 的 3G 數據速率開始流式傳輸而沒有任何延遲。 11% 使用 1.2 和 1.6 MBPS 之間的比特率 - 這可能會減慢 3G 的啟動速度，30% 的比特率高於 1.6 MBPS - 並且無法在 3G 連接上以該比特率播放。 根據這些數據，似乎有 41% 的視頻將無法在移動設備上維持初始比特率——這會增加啟動延遲，並且可能會增加播放期間的停頓次數。

流式啟動最佳實踐：確保清單文件中的初始比特率適用於大多數客戶。 如果播放器在啟動期間必須更改流，播放將延遲，您將失去視頻觀看次數。

那麼，當視頻的比特率接近（或高於）可用吞吐量時會發生什麼？ 下載幾秒鐘後，沒有完整的視頻片段可供播放，播放器停止下載並選擇較低質量的比特率視頻，然後再次開始該過程。 下載視頻片段然後放棄的動作會導致額外的啟動延遲，這將導致視頻放棄。

我們可以通過構建具有不同初始比特率的視頻清單來可視化這一點。 我們測試了 3 種不同的場景：從最低 (215 KBPS)、中等 (600 KBPS) 和最高比特率 (2.6 MBPS) 開始。

從最低質量的視頻開始播放時，從 11 秒開始播放。 幾秒鐘後，播放器開始請求更高質量的流，畫面銳化。

當以最高比特率開始時（在 1.6 MBPS 的 3G 連接上測試），播放器很快意識到無法播放，並切換到最低比特率視頻 (215 KBPS)。 視頻在 17 秒開始播放。 有 6 秒的延遲，視頻質量與第一次測試中交付的低質量相同。

使用中等質量的視頻需要進行一些折衷，視頻以 13 秒（慢 2 秒）開始播放，但從一開始就是高質量的 - 並且沒有從像素化視頻跳轉到更高質量的視頻。

視頻啟動的最佳實踐：為了獲得最快的播放速度，請從最低質量的流開始。 對於較長的視頻，您可以考慮在開始時使用“中等質量”流以在啟動時提供清晰的視頻（延遲稍長）。

WebPageTest 結果：初始視頻流低、中、高（從上到下）。 視頻以最低質量的視頻開始最快。 需要注意的是，17s 的高質量開始視頻與 11s 的低質量開始的質量相同。

流媒體：繼續播放

當視頻播放器可以確定播放的最佳視頻流並且流低於可用網絡速度時，視頻將正常播放。 有一些技巧可以幫助確保視頻以最佳方式交付。 如果我們檢查以下清單條目：

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

信息行報告該流具有 913 KBPS 比特率和 640×360 分辨率。 如果我們查看該行指向的 URL，我們會看到它引用了一個 600k 的視頻。 檢查視頻文件顯示視頻為 600 KBPS，並且清單誇大了比特率。

誇大視頻比特率

• 專業版
  誇大比特率將確保當播放器選擇流時，視頻下載速度比預期快，緩衝區填充速度比預期快，減少卡頓的可能性。
• CON
  通過誇大比特率，傳輸的視頻將是質量較低的流。 如果我們查看報告的比特率與實際比特率的完整列表：

對於 1.6 MBPS 連接的用戶，播放器將選擇 913 KBPS 比特率，為客戶提供 600 KBPS 視頻。 但是，如果準確報告了比特率，則將使用 950 KBPS 比特率，並且可能會毫無問題地進行流式傳輸。 雖然這裡的選擇可以防止停頓，但它們也降低了向消費者提供的視頻的質量。

最佳實踐：稍微誇大視頻比特率可能有助於減少播放中的停頓次數。 但是，太大的值會導致播放質量下降。

在瀏覽器中測試尼爾森視頻，看看能不能讓它來回跳轉。

結論

在這篇文章中，我們介紹了多種方法來優化您在網站上展示的視頻。 通過遵循本文中說明的最佳實踐：

1. preload="auto"
   僅在您的客戶很可能會觀看此視頻時使用。
2. preload="metadata"
   Chrome 中的默認設置，但仍會導致大型視頻文件下載。 謹慎使用。
3. 無聲視頻（循環 GIF 或背景視頻）
   剝離音頻通道
4. 視頻尺寸
   考慮通過桌面向移動設備提供不同大小的視頻。 視頻會更小，下載速度更快，並且您的用戶不太可能看到差異（您的服務器負載也會下降！）
5. 視頻壓縮
   不要忘記壓縮視頻以確保交付
6. 不要“隱藏”視頻
   如果視頻不會顯示 - 不要下載它。
7. 定期審核您的第三方視頻
8. 流媒體
   從較低質量的流開始，以確保快速啟動。 （對於播放時間較長的視頻，請考慮使用中等比特率以獲得更好的啟動質量）
9. 流媒體
   可以在比特率上保持保守以防止失速，但如果走得太遠，流將提供質量較低的視頻。

您會發現頁面上的視頻經過精簡以實現最佳交付，並且您的客戶不僅會喜歡您展示的視頻，而且總體上會享受更快的頁面加載時間。