白皮書：提高直播流的7個建議

 

近日，Mux與Touchstream、Datazoom以及Fastly聯合發佈了一份白皮書，其中部份內容詳細討論瞭如何完美的舉行如超級碗、世界盃等大規模賽事的直播活動。

文 / Mux

譯 / 湯宸宇

原文 / https://mux.com/blog/white-paper-7-tips-to-improve-live-streaming/

1) 監控QoE，作出準確的判斷

當咱們在直播一場大規模地活動時，須要深刻地瞭解觀看直播的用戶的體驗——這就是所謂的用戶體驗質量(QoE)。這不只僅是綜合監控與服務質量(QoS)，咱們能夠處理和聚合每一份CDN日誌，以及來自編碼器、打包程序和存儲的每一項數據，但這並不能準確地反映觀衆正此時的實際體驗，在用戶當前使用的設備上收集指標是得到真實用戶體驗數據的惟一方式。

QoE工具如Mux Dat等可以支持實時監視用戶的體驗。它不只僅能讓咱們查看用戶體驗的變化狀況，並且還能幫助咱們深刻了解產生這些變化的根本緣由。

通常來講，現場活動直播須要關注的5個關鍵指標是：

1. 播放失敗率——觀衆流失敗的比率是多少?

2. 開播前退出率——在播放開始前，觀衆關閉頁面或應用程序的比率是多少?

3. 再緩衝率——用戶緩衝的頻率，緩衝的時間如何?

4. 視頻啓動時間——須要多長時間視頻才能開始播放?

5. 同時觀看人數——在特定的時間段內有多少人在同時觀看直播?

其中，「同時觀看人數」在技術上並非一個QoE指標而是一個用來衡量參與度的指標，可是它很是重要。儘管其餘指標在監視體驗質量時應該被關注，但咱們認爲「同時觀看人數」是直播時應被時刻關注的重要指標，而這些都可以在Mux數據儀表板上實時顯示。

這些指標中的任何一個出現尖峯或低谷都代表傳輸鏈的某個地方存在問題——但這隻反映在堆棧中發生的一些變化帶來的影響。要真正理解發生了什麼變化，咱們得深刻到圖表中的每個數據點來查明問題所在：問題是因爲一個特定的ISP？一個特定的CDN？仍是一個特定的設備？沒有快速深刻檢索分析QoE數據的能力，就沒法如咱們所願地對任何明顯更改作出明智的決策——例如將更多的觀衆路由到另外一個CDN。

一個優秀的QoE工具不該該只是跟蹤這些數據點，更應該以一種企業裏全部人都能理解的方式呈現這些數據——爲最重大的直播活動構建一個「戰情室」是十分必要的。「戰情室」是運營大型活動必不可少的關鍵，一個優秀的、易於理解的QoE工具能夠促進客戶支持、運營和工程團隊在戰情室中的協同工做。最好的QoE工具還可以讓咱們以編程方式實時訪問這些數據，而且可以根據來自觀衆的數據進行multi-CDN切換等操做。

展望下一代的QoE工具，咱們指望看到QoE數據收集點分散在整個媒體拍攝製做與傳輸的工做流中，就像現有的QoS工具已經開始探索的那樣。這將有助於VMAF、SSIM或PSNR等對參考圖片質量進行的自動分析的落地以及對音頻/視頻同步的無監督驗證，從而始終保持從源到最終用戶設備的體驗質量。

2) 根據內容和觀衆調整ABR編碼階梯

雖然per-title的解決方案正在成爲按需視頻流的標準，咱們仍然須要一個從統一方法過渡到per-scene的編碼策略，該策略能夠很好地進行跨平臺實時視頻流。而優化的ABR編碼階梯也相當重要。

對於大規模的流媒體直播活動，咱們有機會在活動以前根據測試內容計劃ABR編碼階梯——從編碼器的角度看，根據以前的比賽內容優化下一張比賽的ABR編碼階梯十分必要。

然而，在2019年及之後，咱們應該更深刻地瞭解內容，從內容角度決定ABR階梯應該是什麼樣的。咱們須要知道觀衆是如何瀏覽內容的，從而對階梯佈局作出有根據的決定——這包括考慮基於觀衆的帶寬能力分佈以及他們正在觀看的設備狀況。

好消息是，作出這些決策所須要的數據點與監視體驗質量而觀察的數據點是同樣的——若是咱們可以正確地分析數據，在直播中根據合適條件判斷ABR編碼階梯策略，咱們就可以作出一些更加明智的決定。在接下來的幾年裏，咱們仍是但願看到更多解決方案的出現，以實現可以隨着觀衆觀看條件的變化靈活改變的ABR編碼階梯。

3) 利用multi-CDN保護源

在重要直播活動的業務中使用單個CDN的日子已經結束了。客戶指望的是在處於任何地理位置的任何平臺上，任何事件的任何一秒鐘都能完美地傳輸。這對於單個CDN供應商來講是不可能的。衆所周知，一些CDN在某些區域和某些IPS中表現得很好，而另外一些CDN在其它一些區域表現得更好。除此以外，使用multi-CDN可以在特定範圍內大幅度提高傳輸系統對一個或多個CDN合做夥伴的容錯性。

現代multi-CDN解決方案的體系結構很是強大——例如Citrix(啓用前原名Cedexis)智能交通管理平臺，能夠利用來自各類數據源的數據(包括Mux的數據!)高精度地控制請求路由，從而實現將分段請求在精確的時刻路由到對於終端用戶最好的CDN上。這就是所謂的「Mid-stream」 CDN交換，它能使請求繞過特定ISP或窄點上的擁塞，以及常見的CDN故障。然而，multi-CDN和CDN切換面臨着兩大挑戰——成本和原點縮放。

成本:當選擇使用多個CDN時，現有的成本模型將受到兩大挑戰。首先，與特定CDN協商數據速率的能力將受到限制。隨着提交量的增長，大多數CDN在訂價上更加靈活，因此當使用更多的CDN時，CDN在大容量上提交的能力就受到了限制；另外一個更大的挑戰來自原始數據的輸出空間。由於有更多的CDN回到原點，這將致使成倍的數據從那個點出去。與edge delivery相比，每GB的數據輸出速率每每要高出一個數量級。

一樣值得注意的是，使用多個CDN會產生巨大的財務成本，同時，團隊對其的管理與操做也會產生巨大的操做開銷。這種人力成本不該該被低估，當咱們決定在大型活動中使用多少CDN合做夥伴時，應該考慮到這一點——請記住，團隊規模多是一個限制因素。

原點縮放：因爲如今有多個CDN返回到原點來查找緩存丟失，原點須要適當的進行縮放。起初，這聽起來並非個大問題，但若是原始版本須要擴展5倍(若是使用5個edge CDNs)，這將變得很是昂貴，併爲這些服務引入新的擴展挑戰。

值得慶幸的是，針對這些挑戰有一個愈來愈流行的解決方案——利用 origin shield。origin shields是位於CDN和源之間的緩存層，在源級別未來自多個edge CDN的傳入請求摺疊成一個請求。Fastly的Media Shield是一個很棒的產品，它是目前爲數很少的徹底支持構建origin Shield的解決方案之一。一個好的origin shield能夠減小70%到80%的源負載，即便它前面有一個性能良好的edge CDN。

利用originshield的最大問題是會在傳輸基礎設施中引入單個或少許故障點。咱們應該經過測試找到減輕這種風險的最好方法——可能包括將CDN原點請求分紅兩個shield數據中心而不是一個，或一個自動或手動回退策略，也就是在origin shield的失敗的狀況下，CDN將會切換至使用直接傳輸端口。

4) 擁有冗餘設計的內容攝取、編碼和傳輸路徑

正如咱們所討論的，multi-CDN對於傳輸大規模實時事件相當重要，可是multi-CDN只在傳輸的最後一英里出現故障時提供幫助。對於大規模的直播活動，咱們須要爲高彈性構建端到端流堆棧。這意味着從編碼器、存儲到打包程序、網絡連接以及能想到的全部流程環節步驟都須要加入冗餘設計。

受限於活動的規模，冗餘設計顯然是有限制的。咱們會爲CEO圓桌會議租用多餘的衛星上傳鏈路和發電機嗎？可能不會！那若是是爲了超級碗或者世界盃？徹底必要！

在網絡冗餘設計方面，控制流量併合理路由是一件十分困難的事情，而攝取的過程也充滿挑戰。雖然可能有兩個冗餘的編碼器，可是若是咱們不能經過不一樣的Internet路徑將輸入的數據傳輸到它們，那麼咱們就沒法解決網絡中斷或擁塞問題。一般，最好的解決方案是在信號發出時與不一樣的供應商創建多個光纖鏈接，並確保它們經過不一樣的Internet交換到達最終目的地。

對於編碼器冗餘設計，同步它們的時間碼並鎖定輸入是很重要的。冗餘的編碼器須要採用相同編碼決策，從而使得來自編碼器A和編碼器B的片斷有一段連續時間碼和B/ P幀引用可以按需切換，在編碼鏈被改變時觀衆不會有視覺不連續的體驗。

若是要在雲上構建主工做流，必定要記住須要在不一樣的區域(而不只僅是可用性區域)運行冗餘編碼器、打包程序和存儲。值得慶幸的是，大多數現代雲平臺都提供了簡單的工具來實現這一點，可是要當心——有些雲產品可能存在地區限制，企業在評估供應商時必定要檢查這一點!

咱們在業界看到的一種比較流行的方法是充分利用跨區域的打包和存儲架構，其中每一個編碼器不只將視頻塊輸出到本身的區域，還輸出到冗餘區域，反之亦然。這種冗餘設計很是棒，由於這可以經過打包程序訪問來自冗餘區域的內容從而構建一個徹底冗餘的打包鏈。

若是您已經構建了一個徹底冗餘的流程鏈，那就太好了！可是不該該在出現故障時才第一次使用它——若是有兩個冗餘鏈，那麼在平時的使用中咱們應該平衡兩條鏈之間全部觀衆的負載。這不只可以確保冗餘服務按預期工做，還可以爲每一個冗餘區域保持緩存的活躍，以保證當突發故障出現須要轉移工做鏈路時系統不會遭受級聯故障。

5) 創建並促進合做雙贏的供應商關係

供應商關係是創建可靠靈活直播業務的基礎，須要注意的有如下幾個部分。

首先，在最基本的層面上，供應商關係須要合做而不是競爭。雙方都須要明白在大規模的現場活動中彼此處在一種合做共贏的局面。這多是一個具備挑戰性的狀況，由於說到底這些都是業務關係，而成本在創建關係的過程當中扮演着重要角色。通常來講，將成本談判與正在進行的工程關係分離是一個好主意，這能確保工程級別的協做交互萬無一失，而這對大規模直播活動的成功而言相當重要。

其次，對於大型活動，可能會有多個提供相同服務的供應商相互競爭（若是沒有，想一想剛纔提到的第三點）。在比賽轉播時，將這種共負盈虧的態度發展到傳統廠商之間的競爭關係中是相當重要的。例如，當一個CDN供應商遇到特定ISP的問題時，迅速路由其流量到競爭對手以維護終端觀衆的QoE應該是可接受的。

第三，咱們須要與供應商協調並積極推進直播活動。對於如何組織一個足夠大的活動來吸引供應商，業界有各類各樣的觀點，一些人認爲只有數以萬計的觀衆人數有效，另外一些人則認爲千兆數字的流量更能吸引供應商。然而，對於大型且關鍵的直播業務，咱們須要確保全部供應商都瞭解您的流量計劃並在當天積極參與已創建的、通過測試的升級路由。

在某些狀況下，購買CDNs的冗餘容量是一個好主意，但若是不使用該容量，那麼當須要冗餘時代價可能會很是昂貴。同時，咱們也很難準確地估計需求，由於隨着網絡環境變得擁擠，用戶的帶寬可能會忽然改變，這使得全部的估計都沒有意義。理解骨幹網絡上可能存在的關鍵點也很重要——這一般是ISP和交換供應商須要充分理解的事情。

若是咱們已經成功地與供應商構建了良好的協做環境，那麼咱們更但願構建一個戰情室環境來應對世界上最大規模的活動直播。咱們應該讓來自全部供應商的技術表明在同一個房間中一塊兒工做來解決問題，同時咱們應該監視供應商的服務。須要注意這是在同一間屋子裏，因此培養人際關係很是重要，沒有電話溝通，沒有人互相交談，房間裏的每一個人都想確保活動的成功。

6) 爲最壞的狀況制定應對方案

無論咱們的應急保障機制和冗餘模型設計得有多好，總有可能出現災難性的錯誤。例如若是觀衆人數是預期的兩倍，而且此時得知CDN合做夥伴沒法處理該問題，那麼咱們該怎麼辦?

對於最壞的狀況，如沒法順利地恢復傳輸流，咱們應該有一個應對計劃。正如Donald Rumsfeld曾經說過的，畢竟還有「未知的未知」。

咱們能夠經過一系列舉措下降這些風險：當多個合做夥伴的帶寬都耗盡時，若是須要咱們應該準備下降直播視頻的比特率——歷史上許多大型直播事件都是這樣解決臨場出現的帶寬資源不足問題，而隨着咱們進入超高清直播時代，這樣的操做會越來越家常便飯。在一些超高清直播試驗中，BBC iPlayer等平臺也曾嘗試只讓少數用戶使用超高清版本的流媒體以確保其服務的全部用戶的QoE都能獲得保證。

隨着低延遲流媒體將成爲直播體育賽事的主導力量，咱們極可能也會開始看到平臺在大型賽事期間動態控制終端用戶的延遲以提升負載時的緩存能力。特別是在將來幾年中，低延遲方法的不斷髮展將不可避免地在可放縮性、延遲和實時體育賽事的彈性之間帶來具備挑戰性的權衡。

在這裏，考慮客戶端的行爲也很重要。若是確實發生了災難性的錯誤，服務在幾秒鐘或幾分鐘內運行了500次，應用程序將如何處理這種中斷？當服務已通過載時，它會向服務發送請求嗎？它會完全讓應用程序崩潰嗎？對用戶來講，它看起來只是緩衝嗎？因爲糟糕的客戶端行爲和已經陷入困境的web服務交互，許多大型軟件的故障已經像滾雪球同樣地增加，所以考慮這一點很重要。

若是出現服務宕機，還應該花時間考慮如何與用戶進行溝通。不少平臺都有服務狀態頁面，可是不少用戶不知道在哪裏能夠找到它們。像Twitter和Facebook這樣的平臺也是與用戶交流的好途徑，但咱們也應該考慮在應用程序內顯示服務相關問題。設想用橫幅的方式呈現：「不是您，是咱們（的服務出現了問題）」。

7) 熟能生巧

當咱們在進行世界上規模最大賽事的直播活動時，很難有機會去進行現場練習。在世界盃、超級碗、板球世界盃或英超決賽等重大賽事中，前幾周的準備活動每每比正式的賽事要小一個數量級。

那麼如何測試正式賽事的規模呢?老實說，咱們沒法如咱們所願地實際測試第一層活動請求的數量。這並非說負載測試不是構建大型業務關鍵視頻平臺的關鍵部分，它絕對是；可是以實際的規模測試達到全部CDN邊緣是不現實的。可是，咱們絕對可使用大量公開可用的SAAS和自承載負載測試工具，以有參考價值的規模測試咱們的源、origin shields和編碼器。

除此以外，咱們能作的還有在小型直播活動中試錯。

若是從未實踐過這種行爲，那麼擁有徹底冗餘設計的傳輸鏈就沒有任何意義。Netflix在2011年首次談到了「chaosmonkey」的概念，它會破壞雲基礎設施的組件用以測試冗餘模式。雖然在實際應用中，一個可致使冗餘編碼鏈重啓的應用程序可能看起來有點可怕，但「chaos monkey」將是行業將來幾年的發展方向。在現實世界中，這可能不是咱們如今想要其自動完成的事情，可是在籌備直播項目期間，手動測試彈性模型是很是重要的。

嘗試測試添加冗餘的每一個點。若是有多個編碼器，從新啓動一個，流是否會凍結？用一樣的方法處理包裝器和CDN。確保在組件發生實際故障時，流仍在繼續運行。咱們還應始終牢記，在執行此操做時，要密切關注物理流程環節來判斷是否存在問題，而不是依賴於QoE的集中監視。雖然這些工具對於查看緩衝或分段獲取失敗等狀況很是有效，但它們目前並不擅長檢查視頻幀內的視覺損壞，尤爲是在DRM內容上。

雖然在實際事件上測試以前咱們應該單獨測試這一套方法，可是在任何準備事件中嘗試這個方法都是很是有價值的，咱們至少能夠看到網絡基礎設施在某些負載下是如何恢復的。一樣重要的是，要充分利用準備階段或測試活動的機會，讓團隊熟悉他們將在比賽轉播當天使用的工具和流程。殺死一個編碼器是一個很好的測試，可是咱們不該該讓團隊知道發生了什麼，而是讓他們檢查監視、工具、運行本和流程，從而準確地找出出現故障的那個部分並妥善解決。