舞臺現場直播由于場景復雜度高，對各環節的可靠性要求也非常高。YY音視頻技術專家朱明亮在LiveVideoStack線上交流分享中結合YY直播實踐詳細解析了直播中涉及的視頻采集卡編程，軟硬件編碼，視頻濾鏡處理等內容。本文由LiveVideoStack整理而成。

文 / 朱明亮

整理 / 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.?穩定性與可靠性

?

為保證整個系統運行的穩定性與可靠性，我們做出了以下三個方面的實踐與努力：在方案上我們采用了雙線路推流與硬編備份的高可用方案，使得每條線路都有兩條編碼與推流，其中硬編作為備份；在硬件選擇上我們選擇高可靠性的采集卡與攝像機；在系統維護上我們實行日志機制與實時監控報警，多管齊下確保系統正常運行。

具體來說，我們在確保系統穩定可靠上做出的探索，主要包括機器性能、編解碼錯誤事件、網絡狀況及傳輸性能三個方面數據的實時上報與碼率自適應，相信這些探索能顯著提升系統整體運行的安全穩定。

精品文章推薦

技術干貨：

• HDR視頻生態系統縱覽
  

• 2018:視頻標準混戰的元年序幕

• Demuxed：編解碼器和壓縮的未來

• 愛奇藝視頻版權保護技術與維權實踐

• VP9如何給Twitch的電競直播帶來價值？

• 精致前處理，精準碼控 — 極致視覺效果

• DeepFocus，基于AI實現更逼真的VR圖像

• 基于QoE的實時視頻編碼優化：低功耗，低延時，高質量

總結

以上是生活随笔為你收集整理的舞台现场直播技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。