文 / 朱明亮
整理 / LiveVideoStack
直播回放
https://www.baijiayun.com/web/playback/index?classid=18122048034091&token=Jv7T0C-YExG1r0cPh106AjAUFyC70_gPZ0Q5yXJijyDhyxC9yFqkUsWhhzWOZ5uojAk6Qj2pOAo 大家好，我是來自YY的朱明亮。今天我将從以下幾個方面，為大家介紹YY在舞台現場直播領域的技術實踐。
1. 總體直播方案
1.1 背景介紹
每年，YY都會舉辦粉絲嘉年華活動，這是網絡主播與粉絲線下見面的機會，很多主播會來到現場表演與互動；每年年末YY還會舉辦年度盛典，旨在表彰平台上一年内最優秀的網絡主播，其中包括紅毯與晚會等活動；除此之外，YY平台上一些高人氣主播的高品質直播活動也需要我們強有力的技術支援，我們會允許主播使用相關直播方案，保證直播的品質及穩定性。
上圖展示的就是年度盛典現場，複雜絢麗的舞美燈光音效對直播方案提出了更高的技術要求。
1.2 普通直播方案
為了保障規模巨大場景複雜的大型直播活動高品質進行，我們需要選擇可靠高效的直播解決方案。對一些優先級與複雜程度一般的直播活動我們會選用較為普通的直播解決方案，前端采集畫面資料的為普通攝像頭或高清錄影機，采集到的資料通過采集卡輸入至導播軟體；除此之外，導播軟體也可讀取本地檔案如片花或片頭等以應對如直播剛開始時攝像頭或高清錄影機無信号等突發情況，待采集端裝置恢複正常工作後再将信号源切換到攝像頭或高清錄影機；視訊資料經過導播軟體的編碼推流等一系列處理流程後會被上傳至YY平台，并通過YY的私有協定或RTMP協定進行分發，最終，使用者可以通過PC、移動端與網頁端等進行觀看。
1.3 高可靠直播方案——雙源雙線路
如果面對的是如年度盛典與YY粉絲嘉年華等高規格高優先級的大型直播活動，我們需要高可靠直播方案為整場活動的順利進行保駕護航。我們的思路是采用雙源雙線路的模式，前端采用多機位高清錄影機采集現場畫面，多路視訊資料接入現場的硬體導播台，導播台分出的一路HD SDI信号會先經過采集卡再到達軟體導播并在軟體導播處進行一系列音視訊與畫面處理，随後處理完成的資料經由編碼與YY的私有協定推至YY雲平台，這是上圖展示的線路1；為了提升整個系統的可靠性，我們的直播頻道采用多線路直播方案，一旦某個線路出現斷路或推流失敗，系統會自動将其他可用線路信号切換到該頻道，進而保障直播的穩定；除此之外，每條線路還有備用直播方案，硬體導播台會繼續分出一路HD SDI信号至硬體編碼機并由此推流至平台，備用推流主要用于該線路主推流方案失效時確定直播過程的順利進行；除了上述兩條線路，我們還把由硬體導播台分出的第三路信号通過衛星發送并用衛星接收機在活動現場之外接收，此路信号會被傳輸至軟體導播台，而後被推流至YY雲中的同一頻道，也就是上圖展示的線路2；我們會為線路1與線路2選用不同的營運商，進而避免由營運商網絡故障造成對直播活動的影響。雙源雙線路可有效提高直播活動的整體可靠性。
2. 軟體導播台
這裡着重介紹一下之前提到的軟體導播台MShow。
2.1 MShow簡介
MShow是一個PC端的編碼推流軟體，可實作信号切換、音視訊處理、編碼推流、提供高品質直播服務等，為YY的重大直播活動提供可靠技術保障。同樣，MShow支援4K/H.265硬體編碼直播與1080P/30fps/H.265軟體編碼直播。
2.2 MShow整體架構
MShow主要基于VideoSDK開發音視訊處理功能包括編解碼、采集、濾鏡、渲染、推流等等；當被運用在YY平台時，MShow依賴YY的業務系統包括頻道邏輯、開播邏輯、流管理、帳戶體系等等；而被運用于第三方平台時則不依賴上述業務邏輯。
2.3 MShow音視訊架構
音視訊架構主要由視訊與音頻兩部分組成。在視訊部分，資料由包括采集卡、攝像頭與檔案組成的前端輸入Video Source，并在随後的Video Filter進行濾鏡處理，最後傳輸至編碼器；音頻部分的流程與視訊類似，資料由麥克、聲音回放系統或采集卡組成的前端輸入Audio Source，進行後續的一系列處理。需要注意的是，上圖展示的由Video Source指向Audio Source的虛線表示有的視訊采集卡本身涵蓋了音頻信号，這些Video端收集到的音頻信号可傳輸至音頻處理部分與來自音頻前端的資料一起進行編碼等後續處理，這些處理完畢的碼流會通過YY協定上傳至平台，并進行封裝與轉碼進而形成多碼流。
3. 關鍵技術實踐
3.1 音視訊時戳處理
設計整個架構經曆的關鍵技術實踐值得我們探索，首先是音視訊時戳處理。所謂時戳處理就是在切換不同視訊源時進行的防止時戳突變或不同步的必要處理過程，有時一些片源其本身就包含了不規範的時戳，會出現突變或倒退，此時就需要我們主動對其進行修正。上圖右側展示的示意圖中，藍色橫線表示整個直播流的一條時間軸，其儲存的目前直播流的最大時間戳一直随着直播單調遞增；當第一段視訊結束之後，系統就會儲存此視訊的最大時戳，當然需對第一段視訊的時戳進行變換，變換到系統時戳的時基；當切換到下一段視訊時，如果下一段音視訊的時戳不是從0開始，那麼系統就會對此時間軸的時戳進行标準化處理，也就是将時戳最小規範到0，加上目前系統儲存的最大時間戳再，最後将新時戳變換到其所在的音視訊時間軸之上進而保證音視訊切換平滑流暢。
3.2 視訊濾鏡處理
MShow會根據前端信号與所需編碼推流的一些參數如寬高分辨率等形成特定的Filter字元串，并将其傳遞給avfilter graph alloc，再借助avfilter graph parse ptr解析此字元串，生成相應的Filter Graph；與此同時，MShow會将由采集卡擷取的原始視訊資料通過av buffersrc add frame傳至BufferSrc，視訊幀會經過FFmpeg Filter Graph的處理，處理完成後會通過av buffersink get frame被編碼推流至MShow，完成視訊濾鏡的整個處理流程。
3.3 采集音視訊預覽
采集音視訊預覽主要在導播界面上進行。在采集卡接收到音頻音效之後，操作者可能聽不到聲音，此時我們就需要對采集音視訊進行預覽。視訊預覽較為簡單，主要過程就是接收到資料之後直接使用DX/OpenGL等渲染得到預覽畫面；音頻預覽則是在采集卡擷取到原始音頻資料之後使用SDL播放。如果音頻資料并非來自采集卡而是來自系統回放裝置則不需要預覽播放，否則會出現回聲現象。
4. 采集卡程式設計
采集卡程式設計主要分為兩種常見類型：DirecShow采集與Decklink采集。前者多用于攝像頭與Magewell，後者則多用于Blackmagic。
4.1 DirectShow采集
DirectShow采集流程如上圖所示：首先，DirectShow會建立Filter Graph Manager，Filter Graph Manager則建立Graph，再建立一個可從采集卡上擷取原始信号的Capture Filter并加入Graph，再建立Grabber Filter，加入Graph，并實作ISampleGrabber接口，可将采集到的原始資料傳入MShow，由Mshow進行後續處理。
整體流程主要是，首先使用者選擇所需采集的裝置，随後系統建立Filter Graph并枚舉所有裝置比對使用者所選；然後根據使用者所選裝置建立Capture Filter，同時加入Graph；接下來，系統會建立SampleGrabberCallback用來接收原始資料，根據使用者需求設定視訊格式并啟動Graph。
4.2 Decklink采集
Decklink采集的流程如上圖所示：首先MShow使用者選擇一個合适的Decklink Device，之後系統會建立一個Decklink Device Discovery執行個體，此執行個體會發現系統中的所有decklink裝置并根據使用者選擇建立Device Instance，并從該裝置查詢擷取一個IDecklink input Object；此Object會進行一系列實際操作如設定音視訊資料回調、設定音頻擷取參數、采樣率、聲道數等等；接下來，系統會啟用AudioInput與VideoInput，其中的VideoInput會根據使用者選擇的分辨率或幀率為其比對一個最佳的模式并調用StartStreams，啟動采集流程。一般情況下，根據輸入裝置不同，Decklink中隻有一種格式是有效的，設定正确方可成功采集視訊，不比對則會出現黑屏；為了自動偵測采集卡視訊格式，需要實作Format Changed通知函數；如果設定的格式與采集卡的格式不一緻，就會觸發Format Changed事件，在該函數裡擷取正确的視訊參數，重新配置視訊參數，并通知應用程式及時改變設定，比如MShow得到通知後需改變Filter Graph。調用SetCallBack，設定接收原始視訊資料的回掉，采集到的原始視訊資料由此回傳至MShow。
在Decklink程式設計中我們需要注意以下幾點：
1）Decklink一般僅支援兩種顔色空間：8BitBGRA與8bitYUV。如果選擇8BitBGRA那麼其對應的FFmpeg中的顔色空間應為8BitBGR0而非8BitBGRA，否則畫面就會出現混亂的現象。8bitYUV對應到FFmpeg裡的YUYV422。
2）大部分裝置使用Decklink僅有一種有效視訊格式。啟用EnableVideo時需要使用bmdVideoInputEnableFormatDetection用以自動偵測實際支援的格式并觸發Format Change事件，需實作VideoInputFormatChanged，我們需要重置采集流程并重設視訊參數；同時通知外部APP重置Filter Graph。
3）一般情況下錄影機輸入的格式為Interlaced，此時我們需要在DShow上啟用Deinterlace。
5. 穩定性與可靠性
為保證整個系統運作的穩定性與可靠性，我們做出了以下三個方面的實踐與努力：在方案上我們采用了雙線路推流與硬編備份的高可用方案，使得每條線路都有兩條編碼與推流，其中硬編作為備份；在硬體選擇上我們選擇高可靠性的采集卡與錄影機；在系統維護上我們實行日志機制與實時監控報警，多管齊下確定系統正常運作。
具體來說，我們在確定系統穩定可靠上做出的探索，主要包括機器性能、編解碼錯誤事件、網絡狀況及傳輸性能三個方面資料的實時上報與碼率自适應，相信這些探索能顯著提升系統整體運作的安全穩定。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/85814606「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。