文 / Evan Farina
翻譯 / 元寶
原文
https://engineering.linkedin.com/blog/2019/01/how-linkedin-uses-data-to-improve-video-performance 在LinkedIn，我們使用資料來改善會員在使用我們網站時的體驗。在視訊團隊中，我們看重的是能夠洞察我們的視訊需要多長時間加載、為什麼某些視訊比其他視訊更受關注、以及我們的成員如何與網絡、iOS和Android上的視訊進行互動的名額。簡而言之，通過在LinkedIn上播放視訊時收集的各種資料點，可以極大地提高視訊性能。技術用詞
這篇文章将提到以下術語，為了友善您，定義如下：
iframe：一個可以在内部呈現外部網頁内容的元素。這在視訊中非常有用，因為它允許我們直接在我們的網站内呈現來自第三方（例如Youtube、Vimeo）域的視訊。
視口：螢幕上可見的網站部分。
DOM：将網頁表示為由許多内容節點組成的樹。
在播放期間捕獲資料
我們的系統捕獲反應視訊在播放過程中如何執行的大量資料。我們發現通過關注以下資料點，我們已經能夠顯着提高LinkedIn.com上的視訊性能：
- 媒體初始化開始：當播放器開始初始化時。
對于通過iframe播放的視訊（例如第三方視訊），此名額會标記iframe首次在頁面上呈現的時間。
對于直接在頁面上呈現的HTML5或本機視訊，此名額會标記視訊播放器發出loadstart事件的時間。
- 媒體初始化結束：播放器初始化完成後。
此度量标準實際上标記了視訊發出loadeddata事件的時間。
- 媒體緩沖開始：媒體在視訊播放之前首先開始緩沖。
- 媒體緩沖結束：在視訊開始播放之前，媒體停止緩沖。
- 開始時間（TTS）：播放器初始化和播放器準備播放視訊之間的時間。
注意：這是視訊在初始化和緩沖上花費的時間總和。
- 感覺的開始時間（PTTS）：成員請求播放視訊和視訊實際開始播放之間的時間。
- 媒體初始化時間：媒體初始化開始和媒體初始化結束事件之間的時間。
- 媒體初始化率：一種資料點，用于确定進入視口并在退出視口之前成功加載視訊的百分比。
如果這個比率下降，則會告訴我們，我們的視訊可能需要很長時間才能加載。
稍後在本文中，我們将放大一些利用上述許多資料點的實驗來改進我們最重要的名額之一，PTTS。
使用資料來讓我們的會員受益
現在我們已經積累了大量富有洞察力的視訊播放資料，我們如何使用它來改善我們會員的體驗呢？我們用兩種方法解決這個問題。
詳細的實時名額報告
在LinkedIn，我們利用多種内部工具和服務，使我們能夠實時存儲資料并可視化這些資料的變化。其中一個特别有用的工具叫做InGraphs，它允許我們可視化在産品中收集的許多資料點。
除了InGraphs提供的圖表之外，我們還提供服務，以便在任何核心名額低于預設門檻值時通知相關團隊。如果我們發現某個産品中的會員體驗出現退化，這些工具可以使我們立即采取行動。
功能的持續A / B測試
我們不斷嘗試新功能，并對現有功能進行調整，其首要目标是為我們的會員提供最佳體驗。我們将名額與InGraphs等報告工具結合使用，可以清晰地描繪出一個給定的實驗如何影響整個網站的使用者互動。
例如，想象一個虛構的實驗，在這個實驗中，我們測試了僅顯示每個成員的Feed中前30個文章的視訊内容的效果。最初看起來似乎是成功的，因為我們的會員觀看的視訊數量增加了。但是，在仔細研究InGraphs之後，我們注意到我們的會員共享的文章數量下降了。通過對這種相關性的了解和對這兩種影響的考慮，實驗将會因為對會員體驗的負面影響而終止
確定我們的資料準确無誤
資料的有用程度取決于它的準确性。如果我們不能相信我們存儲的資料是準确的，那麼就沒有基礎來測試我們建立的各種實驗。除了上面提到的資料監控服務之外，我們還大量使用自動（單元，內建和驗收）測試來確定給定功能正常工作。正如您所想象的，在開發新功能的過程中，以LinkedIn的規模手工測試所有現有功能是不可伸縮的。相反，測試用于單獨運作的現有功能，并保證通過各種互動，功能能夠按預期地執行。例如，我們可以編寫一個測試，它斷言單擊視訊的播放按鈕會導緻視訊開始播放，并捕獲有關視訊加載性能的資料。是以，自動化測試使我們的工程師能夠保證在建立功能後很長時間内，其功能發出的名額是準确的。除了自動化測試之外，LinkedIn工程師還有一些友善使用的工具（請參閱之前部落格文章中提到的跟蹤覆寫大規模的工程基礎設施
https://engineering.linkedin.com/blog/2016/11/engineering-infrastructure-at-scale--test-tracking），以便于驗證給定功能發出的名額。
使用資料擷取視訊性能
由于視訊資源的自然大小，視訊性能需要一種獨特的方法：我們需要一種方法來下載下傳足夠的視訊，以便它立即開始播放，同時還確定我們不會減慢在頁面上呈現元素的速度。
案例研究：感覺開始時間（PTTS）
在LinkedIn，我們測量感覺加載時間，以了解我們的會員等待視訊播放的時間。我們用來深入了解視訊加載時間的主要名額是感覺啟動時間（PTTS）。PTTS測量浏覽器下載下傳視訊所需的時間，以及視訊在播放前緩沖的時間。
讓我們看一下上面的圖表，它提供了一些特定會員等待加載視訊的經驗。一旦視訊進入視口，視訊初始化需要2,700ms，然後在視訊開始播放之前再進行3,300ms的視訊緩沖。在這種情況下，PTTS大約是6,000毫秒。我們現在可以使用此名額以及其他的數百萬個資料點，作為加速視訊加載實驗的基本指南。讓我們看一下我們運作的幾個實驗。
急切加載DOM中的所有視訊
在LinkedIn，我們已經嘗試了預先加載視訊的和延遲加載視訊。預先加載視訊是在視訊進入DOM後立即開始下載下傳視訊。這與延遲加載不同，通過該加載，視訊在進入視口之前不會下載下傳。預先加載允許視訊在進入視口之前在背景加載。這提供了很好的使用者體驗，因為視訊一進入視口就會開始播放，幾乎沒有緩沖。乍一看，這個實驗是成功的，因為它減少了PTTS，意味着視訊開始播放的時間更短了。然而，當我們仔細研究名額時，我們發現了一些有趣的結果。雖然帶寬較強的會員确實享受PTTS的減少，但帶寬較弱的那些媒體初始化速率降低，媒體初始化時間增加。想象一下，例如，一名會員在乘坐地鐵時在他或她的手機上滾動LinkedIn Feed。鑒于地鐵的網際網路連接配接較弱，會員在加載内容方面已經面臨滞後，更不用說視訊資産了。在急切加載的情況下，我們不僅在視口中下載下傳内容，我們還嘗試在幕後加載視訊。正如您想象的那樣，這會對成員相對較弱的連接配接施加過大的負載，進而可能導緻沒有任何Feed的文章加載。這種現象解釋了前面提到的媒體初始化率下降和媒體初始化時間增加，這也是我們下一次實驗的動機。
排隊視訊加載
排隊加載是一種加載政策，在這種政策中，視訊被添加到加載隊列中，并一次加載一個，而不是一次加載DOM中的所有視訊（如預先加載的情況）。排隊加載旨在結合預先加載（減少的PTTS）和延遲加載（對于網絡帶寬較少的成員更容易通路）的好處。它通過在視口外部加載視訊來完成此操作，但隻有在視口中的視訊成功加載後才能這樣做。對于排隊加載，我們觀察到PTTS略有增加，可能是因為視口外部加載的視訊較少，但媒體初始化率增加，而網絡連接配接較弱的成員的媒體初始化時間減少。
結論
由于視訊資源的大尺寸以及對其快速加載而不會對網站其他部分的速度造成負面影響的期望，使得視訊性能成為一個固有的難以解決的問題。為了進一步使問題複雜化，我們還必須在運作與性能相關的實驗之前，考慮網絡速度和浏覽器功能方面的差異，以及成員使用站點的不同方式。通過正确使用資料，我們可以快速查明并疊代性能下降，同時確定在此過程中不會出現性能退化。
緻謝
我要感謝Shane Afsar和Kris Teehan在撰寫這篇文章時給予的幫助，以及Kevin O'Connell和LinkedIn工程部落格團隊在編輯這篇文章時提供的幫助。向紐約的視訊團隊緻敬，他們不懈地緻力于提高視訊性能和整體視訊體驗。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/86522004「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。