无人机开发-图传技术浅析

无人机能够一跃进入大众视野，并迅速在大众市场火热发展，是很多人始料未及的。从刚开始的空中摄录，到后来的实时摄录，方便的无人机图传功能无疑为无人机加足了筹码，赚足了眼球。博主就来分析一下无人机图传技术。

一.观念

从“图传”的叫法可以发现，这并非一个专业的定义，大概是从某些资深航模玩家口中发展而来。专业的航空航天器并没有独立的视频图像传输设备。图传的概念只存在于消费类无人机领域。

二.限制

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层，也主要是图传的优化，这样也方便版本的迭代，要不客户版本升级要多痛苦。