本發(fā)明涉及通信領(lǐng)域，具體說，涉及一種用于移動流媒體直播的自適應(yīng)編碼和傳輸方法。

背景技術(shù)：

隨著移動4g網(wǎng)絡(luò)的普及和“互聯(lián)網(wǎng)+”理念的提出，移動流媒體應(yīng)用，特別是用戶自主創(chuàng)建內(nèi)容的實時視頻直播等應(yīng)用，越來越受到行業(yè)和個人用戶的重視。但是在移動互聯(lián)網(wǎng)絡(luò)環(huán)境下，流媒體直播面臨諸多挑戰(zhàn)：在數(shù)據(jù)傳輸方面，隨著用戶的位置移動和網(wǎng)絡(luò)信號的切換，終端設(shè)備可能處于wifi、4g和3g等不同網(wǎng)絡(luò)環(huán)境，可用帶寬差異巨大。在擁塞發(fā)生時，傳統(tǒng)的丟包算法往往采用丟棄非關(guān)鍵幀的方法，這樣處理固然可以降低畫面?zhèn)鬏數(shù)臄?shù)據(jù)量，但是較為復(fù)雜，因為丟包策略與具體壓縮算法和參數(shù)有關(guān)。另外，丟棄已經(jīng)編碼的圖片浪費(fèi)了移動終端有限的處理能力和電量。比較經(jīng)濟(jì)和高效的做法是實時地根據(jù)可用傳輸帶寬來反向控制畫面錄制的幀率。在數(shù)據(jù)處理方面，市面上的智能終端設(shè)備種類繁多，處理能力也各不相同，為了獲得較好的用戶體驗，實時視頻直播等應(yīng)用需要仔細(xì)設(shè)置各類編碼參數(shù)，但普通用戶難以理解和配置這些參數(shù)。如若應(yīng)用能根據(jù)設(shè)備能力和用戶選擇的場景自動設(shè)置最優(yōu)的編碼參數(shù)，無疑會明顯提升用戶體驗。另一方面，視頻直播屬于計算密集型應(yīng)用，其中的圖像壓縮算法往往涉及數(shù)字濾波、快速傅立葉變換、矩陣運(yùn)算等大量的乘法累加運(yùn)算，如果全部依靠終端的通用處理器（cpu）來處理，不僅會因能效比較低而導(dǎo)致耗電和發(fā)熱問題，還會嚴(yán)重影響用戶界面的響應(yīng)速度。因此，現(xiàn)代智能終端幾乎全部采用專用的圖形處理芯片（gpu）來實現(xiàn)視頻編解碼運(yùn)算，但僅限于本地圖像錄制和播放，難以實時地將編碼后數(shù)據(jù)輸出給移動流媒體應(yīng)用。如能實現(xiàn)一種跨平臺的解決方案，在實時視頻直播等應(yīng)用中利用專用芯片和指令完成畫面處理工作，將會大大提高編碼效率和用戶界面響應(yīng)速度，并節(jié)省電量和減少發(fā)熱，從而顯著提升用戶體驗。

技術(shù)實現(xiàn)要素：

本發(fā)明要解決的技術(shù)問題是，在移動流媒體直播中，使上層應(yīng)用能夠：1、根據(jù)用戶設(shè)置以及智能終端的處理能力和操作系統(tǒng)特性，自動采用經(jīng)過優(yōu)化的編碼參數(shù)和編碼方式，以盡可能高效的方式實施流媒體處理；2、根據(jù)實時網(wǎng)絡(luò)傳輸帶寬，反射式地通過控制畫面錄制幀率實現(xiàn)與壓縮算法無關(guān)的擁塞控制。

為解決上述問題，本發(fā)明提出了一種用于移動流媒體直播的自適應(yīng)編碼和傳輸方法，其特征在于：一是根據(jù)終端的硬、軟件特性，自動設(shè)定媒體編碼參數(shù)和編碼方式，以高效、節(jié)能的方式實施媒體數(shù)據(jù)處理；二是通過傳輸隊列反向控制畫面采樣幀率，以盡可能高效的方式實現(xiàn)平滑帶寬抖動和保證直播實時性之間的平衡。所述移動流媒體直播的自適應(yīng)編碼和傳輸方法包含如下步驟：

步驟110，在建立直播會話時，上層應(yīng)用將用戶設(shè)置的錄制場景、畫面分辨率、實時要求等參數(shù)傳遞給底層庫函數(shù)，后者動態(tài)偵測終端設(shè)備cpu核數(shù)、主頻、硬件編碼能力等特征，結(jié)合上述用戶設(shè)置參數(shù)，通過特定算法映射到適當(dāng)?shù)膆.264編碼參數(shù)集，在后續(xù)的圖像編碼過程中加以應(yīng)用；

步驟120，會話開始后，底層庫函數(shù)將音、視頻等流媒體數(shù)據(jù)進(jìn)行必要的轉(zhuǎn)換、處理，逐幀編碼后存入特定長度的傳輸隊列，由專用線程以異步方式按mpeg2ts格式進(jìn)行混成、切塊并通過rtp協(xié)議傳輸；

步驟130，如果出現(xiàn)持續(xù)超過一定時間的網(wǎng)絡(luò)擁塞，傳輸隊列將會被填滿，進(jìn)而阻塞后續(xù)入隊列操作。通過實現(xiàn)周密的同步互斥機(jī)制，阻塞將最終傳遞到上層應(yīng)用的圖像采樣操作，從而自適應(yīng)地降低采樣幀率。

進(jìn)一步的，上述方法還可具有以下特點，在運(yùn)行時根據(jù)終端的硬、軟件特性以及用戶設(shè)置的錄制場景和參數(shù)等，根據(jù)特定算法映射到適當(dāng)?shù)膆.264壓縮參數(shù)集，這一映射算法可確保在終端硬件處理能力范圍內(nèi)，實現(xiàn)特定場景下最佳的h.264編碼效率和解壓后畫面質(zhì)量。

進(jìn)一步的，上述方法還可具有以下特點，在運(yùn)行時確定終端是否支持硬件編碼，并根據(jù)應(yīng)用設(shè)置確定是否開啟硬件編碼。

進(jìn)一步的，上述方法還可具有以下特點，將已經(jīng)編碼的流媒體數(shù)據(jù)存放在一定長度的發(fā)送隊列中，持續(xù)一定時間的網(wǎng)絡(luò)擁塞將會導(dǎo)致隊列溢出，后續(xù)入隊列操作將被阻塞，通過實現(xiàn)完備的同步互斥機(jī)制，阻塞將被傳遞至畫面采樣的回調(diào)處理，從而從根源上降低了傳輸帶寬需求。

附圖說明

圖1是本發(fā)明實例方法的圖片壓縮參數(shù)設(shè)置流程圖

圖2是本發(fā)明實例方法的工作過程示意圖

圖3是本發(fā)明實例方法的智能移動終端軟硬件編碼的視頻上傳過程。

具體實施方式

以下結(jié)合附圖和具體實施例對本發(fā)明作進(jìn)一步說明。

如圖1所示，本發(fā)明的實施以底層庫函數(shù)封裝為軟件開發(fā)套件（sdk）的形式提供，分為android和ios兩個版本，向上提供統(tǒng)一的c++語言api接口。

在進(jìn)行視頻直播時，上層應(yīng)用首先調(diào)用openencoder接口，傳遞直播場景（如風(fēng)景、比賽）、實時性要求和畫面尺寸等參數(shù)，該接口創(chuàng)建和初始化相關(guān)對象及線程。如圖2中步驟所示，在初始化過程中，底層庫主要完成以下工作（以android系統(tǒng)為例）：

2.1檢測終端系統(tǒng)是否支持硬件編碼的外部調(diào)用（如有緩存，則直接讀取緩存結(jié)果）。一般而言，android系統(tǒng)的媒體服務(wù)器（mediaserver）遵循openmaxil架構(gòu)，理論上可以調(diào)用該架構(gòu)的相關(guān)接口實現(xiàn)音、視頻編碼硬件加速。但由于android系統(tǒng)并未公開openmaxil相關(guān)接口，所以在具體設(shè)備上需要進(jìn)行動態(tài)檢測才能確保硬件加速可用于直播應(yīng)用（即是否可實時獲得h.264nalu）。該檢測用時在200毫秒以內(nèi)，只需進(jìn)行一次。僅當(dāng)設(shè)備支持硬件編碼且用戶設(shè)置未禁止硬件編碼時，硬件編碼標(biāo)識位才設(shè)置為真；

2.2如不使用硬件編碼，讀取設(shè)備的cpu核數(shù)，據(jù)此設(shè)置h.264的視頻壓縮線程數(shù)等參數(shù)。經(jīng)實際測試，線程數(shù)設(shè)置為cpu核數(shù)時，可獲得較均衡的壓縮效率；

2.3如不使用硬件編碼，讀取設(shè)備的cpu主頻，作為設(shè)置h.264預(yù)置參數(shù)presets（包括profile和preset）的參考。一般而言，presets的級別與視頻壓縮的計算強(qiáng)度和耗時成正比，因此設(shè)置presets時還要考慮實時性要求。presets中的preset由下述得分映射表得到（為確保接收端可利用硬件解碼，profile統(tǒng)一設(shè)置為baseline）：

2.4讀取直播場景設(shè)置，據(jù)此設(shè)置視頻直播的初始錄制幀率（缺省值為ntsc制式幀率29.97fps，取整為30fps）。一般而言，所需幀率與錄制畫面的運(yùn)動程度成正比。

2.5獲取網(wǎng)絡(luò)制式，據(jù)此設(shè)置初始傳輸碼率。針對缺省錄制幀率30fps，下表列出了經(jīng)實測調(diào)優(yōu)的不同網(wǎng)絡(luò)制式下各種畫面尺寸的初始傳輸速率。

（本圖主要以視頻數(shù)據(jù)處理為例）：

3.1采樣線程將設(shè)備采集到的一幅畫面或一組音頻數(shù)據(jù)傳遞給編碼過程，該調(diào)用為同步調(diào)用，即調(diào)用

者等媒體編碼完畢并成功放入傳輸隊列后才會返回；

3.2如果設(shè)置了硬件編碼標(biāo)識位，編碼過程在對圖片數(shù)據(jù)進(jìn)行色彩格式等必要轉(zhuǎn)換后（采用支持單指令流多數(shù)據(jù)流的neon指令），調(diào)用android系統(tǒng)的openmax接口通過圖形處理硬件（gpu）實現(xiàn)圖像編碼；

3.3如未設(shè)置硬件編碼標(biāo)識位，編碼過程調(diào)用x264的相關(guān)過程進(jìn)行圖像編碼，編碼參數(shù)由圖2所示的初始化過程設(shè)置；

3.4編碼過程在圖像編碼完成后，以阻塞方式將編碼結(jié)果寫入傳輸隊列，即等待直至入隊列成功；

3.5寫入傳輸隊列完成后，成功返回視頻編碼過程；

3.6完成一幀畫面的編碼和傳輸后，采樣線程回到3.1，進(jìn)入下一次循環(huán)；

3.7多路復(fù)用與傳輸線程以阻塞方式讀取傳輸隊列，即等待隊列非空并獲得數(shù)據(jù)后才返回；

3.8多路復(fù)用與傳輸線程讀取傳輸隊列成功返回；

3.9多路復(fù)用與傳輸線程在內(nèi)部緩沖區(qū)將音、視的編碼數(shù)據(jù)多路復(fù)用為mpeg2ts格式的數(shù)據(jù)包之后，通過rtp協(xié)議向接收端發(fā)送（即所謂mpeg2tsoverrtp）。發(fā)送完成后回到3.7進(jìn)入下一次循環(huán)。

上述步驟3.4-3.8所示的讀、寫隊列操作為臨界區(qū)，以posix互斥鎖加以保護(hù)，并以posix條件變量喚醒等待線程。