2016年，是中國無人機市場的元年，無人機能夠一躍進入大眾視野，并迅速在大眾市場火熱發(fā)展，是很多人始料未及的。從剛開始的空中攝錄，到后來的實時攝錄，方便的無人機圖傳功能無疑為無人機加足了籌碼，賺足了眼球。博主就來分析一下無人機圖傳技術(shù)。
一.觀念
從“圖傳”的叫法可以發(fā)現(xiàn)，這并非一個專業(yè)的定義，大概是從某些資深航模玩家口中發(fā)展而來。專業(yè)的航空航天器并沒有獨立的視頻圖像傳輸設(shè)備。圖傳的概念只存在于消費類無人機領(lǐng)域。
二.限制
1.成本：
不必去懷疑可以通訊多快多遠，無線通訊技術(shù)發(fā)展到今天，沒有人懷疑火星傳回的1080P圖像了。
百公里以上無人機圖傳并非不可實現(xiàn)，但百萬元以上的價格也相對昂貴。
目前市場上的1080P圖傳產(chǎn)品售價基本均在1700美元以內(nèi)，成本也就成為了消費類無人機圖傳設(shè)計的第一條限制。
2.法律：
中國無線電管理的最高法律文件是《中華人民共和國無線電管理條例》，立法機關(guān)為國務(wù)院和中央軍委，由各級無線電管理機構(gòu)執(zhí)行監(jiān)管。如果使用者希望給圖傳單獨申請執(zhí)照，則需要該圖傳首先獲得《無線電發(fā)射設(shè)備型號核準證》，其依據(jù)是國家《無線電頻率劃分規(guī)定》中的有關(guān)無線電發(fā)射設(shè)備技術(shù)指標的規(guī)定。取得專業(yè)電臺執(zhí)照并不是不可操作，只是在消費類無人機領(lǐng)域沒有辦法推廣。
對于專業(yè)航空航天器來說，頻譜劃分時已留有專門的測控頻段，而消費類無人機只能老老實實地屈就于ITU-R（ITU Radio Communication Sector，國際通信聯(lián)盟無線電通信局）的ISM頻段（Industrial Scientific Medical，工業(yè)化科學醫(yī)療頻段）。
13.56Mhz、27.12Mhz、40.68MHz、433Mhz、915Mhz、2.4Ghz、5.8GHz都是1W以內(nèi)無需執(zhí)照發(fā)射的；
433MHz及以下頻段通常很難滿足高清圖傳的帶寬要求；
915Mhz頻段有一半已經(jīng)被GSM占用；
L波帶寬并不富裕；
S波段的2.4GHz也就成了1080P獲得遠距離的首選，但4K或者更高清晰度的圖傳設(shè)計者卻很難在S波段的帶寬上找到便宜；
C波段的5.8G則可以做得更寬，不過相同發(fā)射功率和接收靈敏度下5.8G與2.4G相比通訊距離僅為41.4%，并且其衰減對水氣更敏感，實際通訊距離則不到30%，兩者各有利弊。
圖1 無線頻譜
三.編碼技術(shù)
1.軟/硬件結(jié)構(gòu):OpenMAX IL + Venus
2.編碼標準:H.264(APQ8074)/H.265(APQ8053)
3.碼率控制:CBR(Constant Bit Rate)網(wǎng)絡(luò)傳輸中所謂的 CBR 一般是 ABR（平均碼率），即單位時間內(nèi)的平均碼率恒定，編碼輸出有緩沖可以起到平滑波動的作用。
圖2 碼率
4.碼率/幀率自適應(yīng):Dynamic video rate adaptation (rave)是Qualcomm提供的算法庫，基于變化的Wi-Fi帶寬和信道質(zhì)量，計算出合適的視頻流碼率和幀率，這有助于最大限度地減少延遲和圖像損壞問題。
5.I幀間隔調(diào)整:30fps幀率下，30幀或者60幀一個I幀。能在較低的碼率下達到較高的圖像質(zhì)量。
6.I幀重傳:如果I幀丟失或者損壞，圖像會有較長時間的卡頓。當接收端反饋此情況，發(fā)送端立即重傳I幀，會減少卡7.頓時間。
8.I幀攜帶SPS/PPS信息:缺少SPS/PPS信息，接收端將不能正確解碼，所以流中需要帶這些信息，防止斷線重連后黑屏。
四.通用協(xié)議
1.RTP
1.1.協(xié)議簡單，易組入
1.2.jrtp開源庫:X許可，幾乎無限制。
1.3.針對H.264/H.265編碼特點進行優(yōu)化:不同的組包策略。
1.4.擴展可配置發(fā)包間隔:平衡碼率波動，防止瞬時碼率過大。
1.5.使用RTP擴展頭:傳遞幀號，用于算法的數(shù)據(jù)同步。
1.6.使用內(nèi)存池:減少模塊間內(nèi)存拷貝，降低延遲。
圖3 RTP
2.RTSP
2.1.支持組播:Live555開源庫
2.2.LGPLv2.1許可，可以在商業(yè)軟件中引用。
2.3.相關(guān)類說明
圖4 RTSP相關(guān)類
2.4.數(shù)據(jù)傳遞示意圖:RTSP server接收到RTSP開始后,PreviewH264OnDemandMediaSubsession創(chuàng)建了H264PreviewSouce類和H264VideoStreamDiscreteframer類之后H264PreviewSouce通過隊列從Rtspsink中獲取h264數(shù)據(jù)，經(jīng)過處理后發(fā)送到手機端。
圖5 RTSP 數(shù)據(jù)流
3.圖傳開發(fā)中遇到的問題
實時播放過程，最難解決的問題是圖像卡頓，圖像花瓶問題，圖像在各個手機表現(xiàn)不一樣，在性能好的手機上面，會出現(xiàn)圖像抖動厲害的情況等等。
要解決圖像卡頓的問題，先要知道卡頓的原因：
1.由數(shù)據(jù)在傳輸過程中丟失，沒有數(shù)據(jù)，造成的卡頓
2.app端接收不及時，造成數(shù)據(jù)丟失而引起的卡頓
3.為了減少花屏，而造成的卡頓，比如說剛好丟失了i幀，為了后面顯示不花屏，會對后面的p幀進行拋掉，直到下一個i幀才開始顯示
我們都知道花屏的原因是因為丟幀造成的，比如說丟失了 i幀，關(guān)鍵幀，后面的p幀送去給ffmpeg解碼得到的圖像是花屏，或者馬賽克等等（也有一種是大p,小p的說法，這里就不詳細說了），【注意，這個傳輸過程沒有用到b幀，整個傳輸過程只有兩種幀 i幀，個p幀】,多一點花屏，可以減少卡頓，客戶更能接受的是卡頓，而不是花屏。
解決方案：
第一個問題：由數(shù)據(jù)在傳輸過程中丟失，沒有數(shù)據(jù)，造成的卡頓，有外部環(huán)境的影響，也有圖傳板信號的穩(wěn)定性影響等等，app端沒有很好的解決方法，無非就兩個選擇，一個是tcp傳輸，一個是udp傳輸。根據(jù)實測，tcp效果更好一點。
tcp ：數(shù)據(jù)傳輸過程，能保正數(shù)據(jù)的完整，所以花屏少點，距離相對upd會近一點，
udp：傳輸過程不保證數(shù)據(jù)的完整性，容易花屏，距離比較遠
第二個問題：app端接收不及時，造成數(shù)據(jù)丟失而引起的卡頓，我這里遇到的情況是這樣的，之前的接收數(shù)據(jù)跟解碼同一個線程，顯示另外一個線程，這樣就有一種情況就是解碼不及時，會造成接收線程阻塞，從而影響了數(shù)據(jù)的接收（udp）,解決方案是接收數(shù)據(jù)自己一個線程，解碼跟顯示一個線程，中間通過緩存隊列來進行數(shù)據(jù)的共享，即增加緩存，基本所有的在線播放都是用這個方式。
第三個問題：就客戶需求而定，我這里為了不花屏，會直接丟掉
項目使用mpv+EventBus的方式非常靈活，模塊的替換，復用，重寫都很靈活，而且java層沒有特殊必要，一般都不會動，優(yōu)化各個方面都是在jni層，也主要是圖傳的優(yōu)化，這樣也方便版本的迭代，要不客戶版本升級要多痛苦。
分享是人類進步的源泉，可參考：
http://blog.csdn.net/ad3600/article/details/54706102
http://blog.csdn.net/tpyangqingyuan/article/details/54574977
?