1.Five symptoms of poor video performance
1.1 視頻加載緩慢
?Perceived Wait Time
Time to first frame (TTFF):
? 播放開始所需的adaptive bitrate(ABR)流媒體段的數量。(我們稍后將對此進行更詳細的討論。)
? 視頻請求發送到視頻加載之間的時間(即接收到足夠的數據來渲染第一幀)。如果客戶端實現預取或在本地存儲視頻的副本，則它可能比PWT高得多。
Network-level metrics：
? 用于連接性能分析的技術指標。這包括DNS解析時間、連接握手時間、下載速度和帶寬利用率。
1.2 Video pauses randomly:
? try to measure the issue with these metrics:
? Number of stalls per-play:
視頻回放暫停并進入“緩沖”狀態的頻率。這是加權的視頻長度時，我們聚合多個回放會話。
? Time-to-resume (lag length):
從用戶看到停止播放的視頻到重新播放的時間。
1.3 Low picture quality
性能差的另一個癥狀是圖像質量低，這通常是由于沒有足夠的帶寬來提供更高質量的視頻流的結果。這也可能是由于視頻優化不佳或基礎設施滯后造成的。為了確定它是哪個場景，我們回顧以下指標:
-
Video variant usage
測量在單個ABR段水平上使用和計數每個視頻變體的次數。
-
A number of variant changes during playback
視頻改變顯示給用戶的變量的頻率。
-
Bandwidth utilization
視頻流占用了多大的可用帶寬
1.4 When seeking (scrubbing) through a video it takes a while for it to resume
? 我們使用稱為“特技模式延遲”的指標來監控此滯后。
1.5 Video is out of sync with audio or doesn’t play altogether
? 這種現象可能是由多種原因引起的，但通常是由于終端設備功率不足所致。 為了更好地理解此問題，我們使用了有關設備功能的信息，包括有關我們使用的編解碼器的硬件支持數據以及回放過程中設備資源利用率的數據。
2 我們的補救措施：調整良好的自適應比特率（ABR）流
為了實現高效的流傳輸并減輕上面列出的一些問題，我們使用了自適應比特率流傳輸，這是當前視頻交付的行業標準。 ABR流的兩種最流行的實現是Apple的HLS和MPEG-DASH。 這兩種技術都通過將源視頻文件編碼為具有不同比特率的多個流而起作用。 然后，這些流將以相似的持續時間（例如幾秒鐘）分成較小的段。 然后，視頻播放器會根據可用帶寬和其他因素在流之間無縫切換。 這樣，當信號較差時，視頻仍可以播放（質量較低），而當信號增強時，視頻可以跳至較高質量的視頻流。
2.1 Tuning ABR streaming
使用ABR的棘手部分是對每個流的配置進行微調，以使它們在產品中發揮最佳性能。 值得一提的是，沒有一種配置可以普遍應用于所有產品。 這是一種高度針對產品的設置，會隨著時間的推移而變化。 在Pinterest，我們主要處理簡短的預生成內容（例如VoD），當用戶滾動瀏覽其家庭供稿時，這些內容會自動播放。 它主要用于帶寬可能受到限制的各種移動設備上。 讓我們討論可以調整哪些參數以滿足該條件。
整個過程本質上都是“漂洗和重復”。 您選擇起始參數，觀察回放如何在實時流量上執行，并根據這些信號調整您的配置。 隨著網絡基礎架構和設備功能的不斷變化，您可能需要繼續更新配置。 收集上述指標確實可以簡化流程。
Number of streams, resolutions and bitrates
我們最初決定要提供多少個流以及要使用哪些分辨率是基于兩條信息。 首先，我們對可能出現視頻的所有產品表面及其尺寸都有很好的了解。 其次，我們利用我們所運營的主要市場中可用的網絡基礎設施的知識來設置初始比特率。
推出初始設置后，我們便開始收集指標：PWT，TTFF，視頻播放器多久更改一次使用的流以及我們的流表示可用帶寬的緊密程度。 根據這些信號，我們進一步調整了設置以最小化PWT。
Frame rate
您為視頻流選擇的幀速率會顯著影響平滑播放所需的必要帶寬。 它還可能會改變視頻的感覺。 有三種常用的流幀率。
24fps：過去在電影院中使用。 在現代設備上可能有點生澀。
30fps：這是大多數流媒體服務的標準，并且對于大多數類型的內容都表現良好。 快速動作序列（例如運動）和想要“真實生活”效果的情況（例如新聞，戲劇，自然視頻）可以從更高的幀頻中受益。
60fps：這非常接近人眼可以處理的信息量。 除非您打算在播放過程中放慢視頻播放速度，否則通常不會超出此級別。 它通常用于高節奏的場景，以及當您想要視頻的“真實生活”時。 這不是一種很棒的電影體驗，因為它看起來像真實的生活，并且揭示了太多的細節（例如，化妝，服裝，風景中的瑕疵）。 因此，觀看者不會像使用30fps（甚至24fps）的電影那樣感受到“電影魔力”。 但是，這對于快速動作游戲非常有用。
對于我們的用例，根據經驗，30 fps幀速率效果很好。 隨著媒體庫的發展，我們計劃向某些媒體文件添加60fps的變體。 值得一提的是，降低幀速率以獲得最低質量的比特率是有意義的。 對于Pinterest，我們以15幀/秒的速度對視頻進行重新編碼，因為我們發現，用戶對視頻停滯不滿意，而對視頻的視線略有些生澀。
Segment size and duration
在互聯網上有許多關于段持續時間的建議。 很長一段時間以來，Apple建議的段時間為10s，最近他們將HLS流的段時間修改為6s。 最適合Pinterest的分段持續時間為4s。 我們使用以下準則來做出此決定
- 一些視頻播放器（最著名的是iOS AVFoundation）會在實際開始播放之前加載一些視頻片段。 對于高質量的流和較長的段，這可能會導致很高的PWT。
- 段越長，根據網絡狀況的變化進行回放所花費的時間就越長。
- 使段非常短（例如1s）會導致對服務器的大量請求，從而增加網絡和處理開銷。
- 根據經驗，每個段的字節大小應小于1MB。 這導致大多數CDN提供者的驅逐率較低。
Video and audio codecs
When deciding which codec to use, there are two limiting factors:
- 首先是您用于流式傳輸的技術。 例如，HLS會強制您堅持使用h.264視頻編解碼器和一些受支持的音頻編解碼器之一。 DASH可以與編解碼器無關，因此更加靈活。
- 第二個因素是用戶設備提供的功能。 Pinterest可在全球范圍內使用，我們的許多用戶使用的舊設備處理能力有限。 為了他們的緣故，我們使用最廣泛支持的配置– h.264編解碼器，主要配置文件，級別為3.1，并附帶用于音頻通道的HE-AAC v1和v2編解碼器。
Fine tuning
- 最后的一些小調整包括選擇用于第一段回放的流的質量。 為了使PWT最小化，我們在播放的前四秒使用中等質量的流，而不是使用高質量的流。
- 另一個設置強制我們的編碼器將IDR幀放置在每個段的開頭。 這樣一來，視頻播放器就不必在開始渲染幀之前加載整個片段，從而大大減少了PWT和恢復時間指標。
- 我們還確保啟用特技模式時支持流技術。 HLS和DASH都支持此功能，并啟用了性能擦除，從而最大程度地減少了特技模式延遲指標。
- 最終的優化是確保我們的交付基礎架構非常快。 為了保證這一點，我們使用了多個CDN提供商，然后為每個用戶選擇最快的a。
要使視頻播放產品在大型產品中表現出色，需要進行大量調整。 建議使用最適合產品其他流技術和設置。
