無人機能夠一躍進入大眾視野，并迅速在大眾市場火熱發展，是很多人始料未及的。從剛開始的空中攝錄，到后來的實時攝錄，方便的無人機圖傳功能無疑為無人機加足了籌碼，賺足了眼球。博主就來分析一下無人機圖傳技術。

一。觀念

從“圖傳”的叫法可以發現，這并非一個專業的定義，大概是從某些資深航模玩家口中發展而來。專業的航空航天器并沒有獨立的視頻圖像傳輸設備。圖傳的概念只存在于消費類無人機領域。

二。限制

1.成本：

不必去懷疑可以通訊多快多遠，無線通訊技術發展到今天，沒有人懷疑火星傳回的1080P圖像了。百公里以上無人機圖傳并非不可實現，但百萬元以上的價格也相對昂貴。目前市場上的1080P圖傳產品售價基本均在1700美元以內，成本也就成為了消費類無人機圖傳設計的第一條限制。

2.法律：

中國無線電管理的最高法律文件是《中華人民共和國無線電管理條例》，立法機關為國務院和中央軍委，由各級無線電管理機構執行監管。如果使用者希望給圖傳單獨申請執照，則需要該圖傳首先獲得《無線電發射設備型號核準證》，其依據是國家《無線電頻率劃分規定》中的有關無線電發射設備技術指標的規定。取得專業電臺執照并不是不可操作，只是在消費類無人機領域沒有辦法推廣。對于專業航空航天器來說，頻譜劃分時已留有專門的測控頻段，而消費類無人機只能老老實實地屈就于ITU-R（ITU Radio Communication Sector，國際通信聯盟無線電通信局）的ISM頻段（Industrial Scientific Medical，工業化科學醫療頻段）。

13.56Mhz、27.12Mhz、40.68MHz、433Mhz、915Mhz、2.4Ghz、5.8GHz都是1W以內無需執照發射的；

433MHz及以下頻段通常很難滿足高清圖傳的帶寬要求； 915Mhz頻段有一半已經被GSM占用； L波帶寬并不富裕； S波段的2.4GHz也就成了1080P獲得遠距離的首選，但4K或者更高清晰度的圖傳設計者卻很難在S波段的帶寬上找到便宜； C波段的5.8G則可以做得更寬，不過相同發射功率和接收靈敏度下5.8G與2.4G相比通訊距離僅為41.4%，并且其衰減對水氣更敏感，實際通訊距離則不到30%，兩者各有利弊。

圖1 無線頻譜

三。編碼技術

1.軟/硬件結構：OpenMAX IL + Venus 2.編碼標準：H.264（APQ8074）/H.265（APQ8053） 3.碼率控制：CBR（Constant Bit Rate）網絡傳輸中所謂的 CBR 一般是 ABR（平均碼率），即單位時間內的平均碼率恒定，編碼輸出有緩沖可以起到平滑波動的作用。

圖2 碼率

4.碼率/幀率自適應：Dynamic video rate adaptation （rave）是Qualcomm提供的算法庫，基于變化的Wi-Fi帶寬和信道質量，計算出合適的視頻流碼率和幀率，這有助于最大限度地減少延遲和圖像損壞問題。 5.I幀間隔調整：30fps幀率下，30幀或者60幀一個I幀。能在較低的碼率下達到較高的圖像質量。 6.I幀重傳：如果I幀丟失或者損壞，圖像會有較長時間的卡頓。當接收端反饋此情況，發送端立即重傳I幀，會減少卡7.頓時間。 8.I幀攜帶SPS/PPS信息：缺少SPS/PPS信息，接收端將不能正確解碼，所以流中需要帶這些信息，防止斷線重連后黑屏。

四。通用協議

1.RTP

1.1.協議簡單，易組入 1.2.jrtp開源庫：X許可，幾乎無限制。 1.3.針對H.264/H.265編碼特點進行優化：不同的組包策略。 1.4.擴展可配置發包間隔：平衡碼率波動，防止瞬時碼率過大。 1.5.使用RTP擴展頭：傳遞幀號，用于算法的數據同步。 1.6.使用內存池：減少模塊間內存拷貝，降低延遲。

圖3 RTP

2.RTSP

2.1.支持組播：Live555開源庫 2.2.LGPLv2.1許可，可以在商業軟件中引用。 2.3.相關類說明

圖4 RTSP相關類

2.4.數據傳遞示意圖：RTSP server接收到RTSP開始后，PreviewH264OnDemandMediaSubsession創建了H264PreviewSouce類和H264VideoStreamDiscreteFramer類之后H264PreviewSouce通過隊列從Rtspsink中獲取h264數據，經過處理后發送到手機端。

圖5 RTSP 數據流

3.圖傳開發中遇到的問題

實時播放過程，最難解決的問題是圖像卡頓，圖像花瓶問題，圖像在各個手機表現不一樣，在性能好的手機上面，會出現圖像抖動厲害的情況等等。

要解決圖像卡頓的問題，先要知道卡頓的原因： 1.由數據在傳輸過程中丟失，沒有數據，造成的卡頓 2.app端接收不及時，造成數據丟失而引起的卡頓 3.為了減少花屏，而造成的卡頓，比如說剛好丟失了i幀，為了后面顯示不花屏，會對后面的p幀進行拋掉，直到下一個i幀才開始顯示

我們都知道花屏的原因是因為丟幀造成的，比如說丟失了 i幀，關鍵幀，后面的p幀送去給ffmpeg解碼得到的圖像是花屏，或者馬賽克等等（也有一種是大p，小p的說法，這里就不詳細說了），【注意，這個傳輸過程沒有用到b幀，整個傳輸過程只有兩種幀 i幀，個p幀】，多一點花屏，可以減少卡頓，客戶更能接受的是卡頓，而不是花屏。

解決方案： 第一個問題：由數據在傳輸過程中丟失，沒有數據，造成的卡頓，有外部環境的影響，也有圖傳板信號的穩定性影響等等，app端沒有很好的解決方法，無非就兩個選擇，一個是tcp傳輸，一個是udp傳輸。根據實測，tcp效果更好一點。 tcp ：數據傳輸過程，能保正數據的完整，所以花屏少點，距離相對upd會近一點， udp：傳輸過程不保證數據的完整性，容易花屏，距離比較遠

第二個問題：app端接收不及時，造成數據丟失而引起的卡頓，我這里遇到的情況是這樣的，之前的接收數據跟解碼同一個線程，顯示另外一個線程，這樣就有一種情況就是解碼不及時，會造成接收線程阻塞，從而影響了數據的接收（udp），解決方案是接收數據自己一個線程，解碼跟顯示一個線程，中間通過緩存隊列來進行數據的共享，即增加緩存，基本所有的在線播放都是用這個方式。

第三個問題：就客戶需求而定，我這里為了不花屏，會直接丟掉

項目使用mpv+EventBus的方式非常靈活，模塊的替換，復用，重寫都很靈活，而且java層沒有特殊必要，一般都不會動，優化各個方面都是在jni層，也主要是圖傳的優化，這樣也方便版本的迭代，要不客戶版本升級要多痛苦。