基于安卓的超高清視頻導播系統的設計與實現

關鍵詞：帶貨直播 超高清 音視頻 低延時 導播

第一章 前言

1.1研究背景

目前火爆全網的帶貨直播激發了用戶對音視頻體驗的要求越來越高，音視頻體驗整體表現為超高質量、超高流暢度、極低時延、低成本。超高質量：分辨率要求從2K、4K到8K、12K，觀看沉浸式體驗要求也從2D、3D到VR、AR;幀率也從30幀、60幀向120FPS邁進。超高流暢度：從無卡頓到不高于百分之三的丟包重傳率;極低時延：從主播和觀眾實時交互到不高于50ms的極低時延;低成本：音視頻技術的飛速發展降低了行業門檻，流量、算力及存儲消耗因為硬件成本的降低導致總價越來越親民。高效便捷的直播導播系統或設備逐漸像手機一樣進入更多人的生活和工作之中。

1.2研究意義

2019年底爆發的新冠疫情持續至今并沒有結束的跡象，疫情促生的隔離經濟加速了直播行業的發展：如帶貨直播、視頻會議、遠程教育、企業在線培訓等，直播已成很多人在生活、工作中重要的工具，也成為企業和個人適應調整當前疫情經濟下的友好支撐。直播的實時性和連麥互動帶來的強烈的互動感、現場感促進了人與人之間的連接關系，科技與生俱來的優勢也成為直播帶貨得以風靡全網的重要原因。

傳統的導播臺不僅需要切換臺，還需要調音臺、錄機、電腦等大型硬件設備，攜帶非常不方便，加上硬件設備疊加的成本很高，一般的個人或者企業只能望而卻步。這類設備一般是通過工控主板，接入USB攝像頭的方式實現的，除了設備專業復雜、價格非常昂貴等弊端外，也很難實現畫面特效、虛擬場景等各種視頻實時編輯功能，亦無法滿足當前靈活多變的市場需求。如果能夠開發出一套專業便捷的直播導播系統，通過植入到一臺設備中就可以實現全部的功能：視頻編輯導播在本地，視頻實時存儲在云端，用戶只需要一臺手機就可以在線觀看。不但省去視頻后期剪輯的大量工作而且節約了軟硬件的直接成本，很大程度上改善了用戶體驗，是非常值得深入研究并實現的。

第二章 平臺需求

2.1 硬件平臺

●高通驍龍八核處理器;

●多路HDMI輸入，全高清4K+分辨率;

●多網絡聚合;

●多類型接口HDMI、USB、網絡;

2.2 軟件平臺

●安卓9.0

●多機位1080P導播切換;

●高性能H264/H265視頻編解碼;

●連麥視頻會議模塊;

●4G/5G網絡自由選擇;

●多音頻混合輸入;

●視頻輸入自由編輯功能：機位切換、畫中畫、綠幕摳圖、水印、換背景圖等;

●支持多平臺推流、三方平臺無推流、地址推流;

●超高清視頻的本地及云端存儲;

第三章 設計實現

設備的CPU使用高通驍龍八核處理器kyro架構，屬于在智能終端上的最高性能方案之一。設備的操作系統采用普遍使用的安卓操作系統，穩定易用性高。在輸入/輸出接口方面，采用擴展HDMI USB 輸入接口，支持超高清4K視頻輸入;以兩路HDMI 輸入、兩路USB 1080P輸入、兩路網絡輸入、一路本地輸入，實現七路不同機位和設備的實時輸入為例，同時支持聲音混流，加嵌、解嵌等。

本地視頻存儲采用SSD的固態硬盤存儲方案，網絡流和圖片庫提供云端地址接口支持云端存儲。推流地址的獲取支持直接掃碼自動填寫。

3.1 快速切換設計原理及方法

快速切換是指不同機位或者是網絡流和背景之間的切換，從當前正在推流的畫面快速切換到備用預覽的其他畫面。當用戶切換畫面的時希望導播系統能實時無縫的切換到期望的畫面，然后推流到服務器端，用戶看到的畫面和導播用戶看到的畫面需要保持一致。為避免出現畫面黑屏、疊影、中斷等異常情況，需要在整個鏈路上進行優化，而快速切換設計在用戶體驗中發揮很關鍵的作用。

為達到以上目的，HDMI及網絡、USB攝像頭等多路流切換前后始終保持編解碼不斷開，開啟預覽后所有的視頻流都一直處于解碼狀態。當推流發生切換，編碼器立即更換編碼流id，繼續編碼推流，并且發送新的視頻頭部信息。通過提前準備好數據流來實現多機位視頻的無縫切換，而切換之后發送新一路流的視頻頭部信息可以避免切換延遲。當發現新的數據流會清掉前面部分的數據，立即切換到新的數據流。通過以上方法實現了視頻快速無縫切換并推流的目的。

3.2 低延時設計原理和方法

低延時主要包括兩個部分：直播低延時和連麥互動低延時。

直播延時的原因分析及低延時設計

首先是啟動過程產生的延時分析，導播編碼系統在對不同機位的流進行切換和組合時需要進行協議轉換和編解碼。如果切換的時候才開始獲取數據流并進行編解碼，再去拉取流進行處理，就會增加切換觸發過程和啟動過程耗時。針對該問題，該導播平臺針對所有輸入在全鏈路上進行預熱，提前啟動協議轉換、媒體編解碼和解封裝的處理任務，預監和推流同時并行運行，即使關閉推流功能，各個預覽畫面的編解碼任務也會一直運行工作，這樣在重新打開推流功能時能立即取到內容并推流到服務器端。

其次鏈路緩存是整條直播鏈路產生延時的主要原因。為盡可能避免緩存延時，提前緩存數據是優化網絡抖動比較有效的方法，鏈路緩存存在輸入流的輸出端，編解碼器內部和數據傳輸的網絡層。導播系統需要在導播切換的時候丟棄掉之前緩存的大部分備用數據，而選擇最接近當前時間的關鍵幀開始發送數據，在編解碼內部，采用合理的編解碼參數調節以及隨時最大限度的主動推流的方式降低編解碼產生的延時。鏈路選擇上，采用最近的節點就近傳輸，然后再通過服務器FORWARD到對應的節點，用戶端也可以就近選擇拉流觀看。

另外，播放器緩存也是延遲優化很關鍵的部分。大多數播放器會緩存解碼一部分的視頻數據第一幀畫面才開始展示，這樣能夠防止因為鏈路抖動而使得畫面觀看起來更流暢，通常來說播放器緩存引起的延時占據了整體延時的60%。所以播放器主要是從緩存和解碼效率兩個方面降低延遲。

互動連麥低延時設計

針對連麥等實時性要求極高的互動就需要使用比如WEBRTC等更實時的播放協議，可以將延時進一步調整到100ms以內。所以一般連麥互動和視頻傳輸分開，連麥采用超低延時的WEBRTC協議，不超過100ms的延遲讓互動身臨其境;文字和視頻傳輸采用比較穩定的RTMP協議，降低網絡抖動引起的信息損耗，而視頻傳輸還能更具用戶的網絡環境選擇適合自己的最佳線路，從而為每個觀看者帶來最佳的視聽體驗。

3.3 多平臺推流

“一播多用”是為了直播可以在各個平臺同時發布和播放，不但支持在不同平臺的用戶同時觀看，更減少了視頻后期分發的工作。只要事先設置好推流參數，就可以實時推流到抖音、快手、B站、虎牙等平臺。如果有的平臺需要加上自己的水印才可以推流，就需要在客戶端選擇水印圖片疊加之后再推流。多平臺推流可以直接通過客戶端實現兩份數據的復制推流，也可以通過云端實現轉推。

客戶端嵌入式推流的實現硬件都只需要做一次解碼，只需要推流部分實現流的復制和轉推。硬件平臺直接推流到多個平臺，需要消耗客戶端的性能，但是也分散了服務器端的壓力。而且能夠實現各個平臺延遲最小。

服務器云端實現多平臺推流，是通過服務器軟件來實現將流FORWORD到各個平臺。這種多平臺推流實際是通過平臺轉發來實現的。主要消耗服務器的計算資源，針對Intel系列的V3以下的CPU，一路直播流編解碼基本上需要消耗一個邏輯核資源。

3.4 無需推流地址推流

鑒于各大平臺對自身服務器端的保護機制，推流地址的獲取越來越復雜，對于普通的用戶來說無疑是增加了難度。為了減少推流的難度，導播設備可以結合第三方平臺實現一套完整的無推流地址的解決方案。

具體實現方法重載系統底層camera回調函數，自研客戶端實現HDMI和USB已經網絡流的切換并實現畫面編輯，并在啟動抖音等第三方客戶端的同時系統會自動啟動自研的客戶端。導播系統自有客戶端在實現本地流的切換和組合及編輯之后可以隨時收起成一個小圖標，處理完的數據流會倒回camera，然后抖音等第三方服務平臺再從camera獲取到數據流，最終推流到抖音等第三方的服務器端。這樣三方服務平臺客戶端這里所有的流程都不做改變，但是實際拿到的流是經過處理和導播的視頻流。這樣就完美解決了第三方服務器端地址無法獲取或者減少地址獲取的工作量。為非專業人員的直播推流減少了難度，節省了時間。真正實現一鍵直播和推流。這種方式適用其他所有的三方服務平臺客戶端，不需要一一定制。

第四章 主要問題及分析

4.1底層功能

1）安卓手機默認的系統架構并不是完全適配HDMI的，比如在熱拔插、幀率選擇等特殊問題需要大量改動。原先攝像頭架構體系和代碼太龐大也會增加更改難度。

2）本方案中HDMI輸入芯片選用TC358840，由于市場上資料比較少，必須依靠供應商提供資料，其提供的資料有任何問題，就會影響導播系統的效果。任何產品都有自身的缺陷，包括在調840驅動時，也有遇到寫入大小端不一致、寄存器寫入不起作用、芯片識別到后數據流異常等問題。

3）芯片跟硬件聯調，也存在抗干擾問題，導致HDMI在熱拔插的時候容易死機。音頻輸入方面也有碰到芯片電壓不匹配等問題，造成軟件開發難度加大。后續還需要解決的問題有：外部信號輸入需要動態調節，比如同一個信號輸入源分辨率、幀率的改變，設備能實現自適應調節。

4.2性能瓶頸

客戶端性能瓶頸

導播設備包含兩路HDMI高清輸入、一路USB本地輸入、三路網絡流輸入、一路本地視頻流輸入預覽，同時還支持本地更換圖片背景。如果同時打開預覽窗和推流窗，就會消耗非常多的計算資源。從源端獲取到camera的數據流并解碼，然后調用底層encoder封裝轉碼為目標格式，然后以高清碼率和高幀率推流到服務器端。由于編解碼和轉封裝非常消耗CPU，同時開啟多路預覽的時候CPU資源會成為瓶頸，這就需要通過業務和性能優化多種思路來解決這個問題。

其中業務端方面可以通過預覽窗口不獲取所有的數據幀，即抽幀的方式來減少CPU的消耗，既預覽窗口只需要每秒10幀以下的播放速度展示。一旦切換到當前窗口推流，客戶端立即向底層發起請求，底層立即以正常的幀率60幀每秒的速度從camera獲取數據并通過客戶端推流到服務器端。只要保持當前推流的窗口是正常幀率就不影響業務使用，預覽窗口通過抽幀的方式則極大降低了資源的消耗。

另一方面，通過優化安卓系統的底層進程和線程個數來減少不必要的資源消耗，盡可能降低資源利用。還可以通過硬編碼的方式來減少軟件帶來的計算資源壓力。此外，對于循環播放的網絡流可以通過本地加載若干數據，來減少從網絡獲取數據的壓力。不但減少了帶寬資源也減少了cpu的壓力。

服務器性能瓶頸

服務器收到推流請求，接受并存儲rtmp協議的流，支持同時存儲為多個碼率存儲，包括超高清、高清和標清模式。這些碼率需要通過服務器端實時轉碼存儲，消耗大量的CPU資源。

服務器端性能的優化主要通過協議棧性能調優的方式來降低資源消耗，比如增加MTU的大小來減少數據傳輸的頻率，從而降低CPU的消耗。數據采用分布式存儲，降低IO吞吐帶來的壓力，從而降低資源的消耗。

4.3穩定性

與傳統硬件導播臺相比，傳統的導播設備定制硬件、專線網絡、固定格式的流媒體輸入;而本系統是基于安卓平臺開發的導播系統，它使用通用硬件平臺，網絡環境和設備環境也是復雜多變，意外和突發事件概率加大，穩定性上面臨著更大挑戰。為了提升穩定性，直播導播系統需要在應用層和服務器端實現實時異常檢測和故障調度，有效應對單點故障等異常，同時提供預覽導播、快速切換、緊急網絡墊片流等多項應急功能也是解決穩定性的有效選擇。云端服務器則通過主備集群、備份默認節點、服務過載自啟動新的節點等方式來提高業務的穩定性。

4.4三方服務平臺限制瓶頸

為了避免服務器資源的浪費和繞過第三方平臺構建的商業壁壘，三方平臺的服務器端逐漸關閉了推流地址的自由獲取，專業設備的直播地址獲取變得越來越復雜。初期已經實現的推流地址填寫并推流的功能已經在很多平臺失效。安卓系統的開源為解決這一問題帶來了便利，通過重載和模擬camera的行為，新增并擴展了手機的前后置攝像頭，并虛擬出類camera的屬性。原始的前后置攝像頭可以被擴展為多路HDMI的輸入，而類camera則可以實現模擬原始攝像頭的能力，從而修改了三方平臺的原始數據流。實現視頻數據流的編解碼和編輯功能，從而完美解決了推流地址獲取的問題。

綜上，該功能是利用了三方視頻平臺對安卓操作系統的兼容性實現了不需要獲取推流地址就可以推專業設備的視頻流到三方服務器平臺。

第五章 性能結果和使用場景

5.1設備性能

客戶端設備能同時支持一路60幀4K、一路30幀1080P、三路網絡視頻流、一路本地視頻流、一路圖片切換。在網絡環境良好的條件下，支持以上各路視頻無縫切換導播，并實時畫中畫疊加推流、同時推流到3個以上平臺。畫質清晰流暢，無卡頓花屏等異常問題，滿足了客戶端設備性能的各類要求。

5.2使用場景

該視頻導播系統可以在游戲、教育，會議、電商直播、婚禮活動等場景中，進行畫面導播和視頻編輯。此類場景主要通過視頻推流直播結合視頻的內容分發網絡，實現在全國各地都可以就近獲取到最近的流媒體視頻，從而獲取最佳的用戶體驗。

此外，該系統也可以用于圓桌會議、連麥等場景，支持少數人的在線實時互通，和多數人的在線直播觀看。連麥需要視頻整個鏈路延遲100ms以內，保證人的視聽基本感受不到網絡帶來的延遲感。而多數人的在線觀看可以支持延遲1-5s內，視頻直播再疊加上文字互動。從而達到相對優質的用戶體驗。

第六章 局限性

本設備存在的局限性主要是和外部環境的變化有關系。

一方面是性能瓶頸的局限性：該導播平臺使用安卓9.0系統，目前的手機硬件平臺就成為設備的一大局限，因此無法從性能上超越目前主流手機的主芯片性能。

另一方面，由于第三方平臺的服務器會做各種限制，比如推流碼率、幀率等的限制，無法徹底擺脫三方視頻平臺的制約。視頻質量也因此存在一定程度的局限性。如果設備推過高碼率和幀率的視頻會被三方視頻平臺檢測到并被拒絕，或者特別異常的提醒信息影響用戶體驗。另外，有些視頻平臺必須有本平臺水印才被認為是合法內容，三方平臺的改變也會需要設備跟隨著改變，這也增加了設備的維護和升級頻率。

第七章 結語

總之，與傳統導播臺相比，本導播平臺擁有低成本、方便快捷、支持彈性擴展、多協議兼容、場景豐富等多項優勢，適用于多視角直播、跨城同屏直播、在線教育、直播帶貨等多種場景。該導播系統方便易用，只需要一臺內置本系統的集成設備及攝像頭就可以實現不同場景的一鍵導播直播需求。

第八章 附錄

[1]陳戈.智能導播助力2021春晚新媒體節目創新——淺析人工智能切換技術的應用[J].現代電視技術，2021（03）：35-40.

[2]張韻.淺析綜藝演播室新聞虛擬制作音頻技術方案[J].現代電視技術，2021（10）：139-142.

[3]吳天亭. H.264視頻軟導播系統的設計與實現[D].成都信息工程學院，2013.

[4]鄭堃，劉強，殷茂森.全媒體互動直播的探索與實踐[J].演藝科技，2020（05）：58-63.

[5]方霽，鄭倩，王一梅，馬特.關于云導播臺交互方式的探討[J].廣播電視信息，2021，28（08）：22-25.DOI：10.16045/j.cnki.rti.2021.08.002.

作者簡介：鄒世明：女，漢族，廣東深圳。 中國人民大學計算機應用專業