2016年，是中国无人机市场的元年，无人机进入大众视野，迅速在大众市场取得了火热的发展，这是很多人没有想到的。 从最初的空中拍摄到后续的实时拍摄，便捷的无人机拍照功能无疑为无人机增加了芯片，赚了不少钱。 博主来分析一下无人机的摄影技术吧。
一.观念
从“图传”这个称呼可以看出，这并不是一个专业的定义，可能是从一些资深航模玩家嘴里发展出来的。 专业的航空航天器没有独立的视频图像传输设备。 图传的概念只存在于消费者无人机领域。
二.限制
1 .成本：
不用怀疑能多快通信。 无线通信技术发展到今天，没有人怀疑从火星传来的1080P图像。
百公里以上的无人机拍照并不是不能实现，但100万元以上的价格也比较高。
目前，市面上1080P平面产品的售价基本在1700美元以内，成本也成为消费级无人机平面设计的第一个限制。
2 .法律：
中国无线电管理的最高法律文书是《中华人民共和国无线电管理条例》，立法机关是国务院和中央军事委员会，由各级无线电管理机关进行监督管理。 如果用户想要单独申请图纸许可，图纸需要先获得《无线电发射设备型号核准证》，其依据是国家《无线电频率划分规定》关于无线发射设备技术指标的规定。 获得专业的无线电执照并不是不可操作的，只是在消费型无人机领域没有普及而已。
对于专业的航天飞机来说，虽然在进行频谱分割时已经留下了特殊的测量频段，但消费型无人机却一直以来都是ITU-r (国际通信联盟无线通信局)的ISM频段(工业级scial )
13.56Mhz、27.12Mhz、40.68MHz、433Mhz、915Mhz、2.4Ghz、5.8GHz均在1W内无证发射；
433MHz以下频带通常难以满足HD图像传输的带宽要求；
915Mhz频段的一半已经被GSM占用；
L波的带宽并不富裕；
s波段的2.4GHz也是1080P获得远距离的优先事项，但4K和更高分辨率的平面设计者很难在s波段的带宽中找到便宜
C波段的5.8G可以更宽，但在相同的发射功率和接收灵敏度下，5.8G与2.4G相比通信距离仅为41.4%，且其衰减对水气更敏感，实际通信距离小于30%，两者各有利弊。
图1无线电频谱
3 .编码技术
1 .软/硬件结构：OpenMAX IL Venus
2 .编码标准：h.264(APQ8074 )/h.265 (apq 8053 ) )。
3 .编码率控制： CBR (恒定比特率)网络传输中的CBR通常为ABR (平均编码率)。 即，单位时间内的平均编码率是固定的，在编码输出中有缓冲器能够起到平滑的变动的作用。
图2编码率4 .编码率/帧速率自适应：动态适应(rave )是Qualcomm提供的算法库，基于变化的Wi-Fi带宽和信道质量，适当的视频
5.I帧间隔调整：以：30fps帧速率，30帧或60帧一个I帧。 可以以低编码率达到高画质。
6.I帧重传如果：帧丢失或损坏，图像将长于jzdxt。 当接收方反馈该情况时，发送方立即重新发送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.图传开发中遇到的问题
实时播放过程，最难解决的问题是图像jzdxt，图像花瓶问题，图像在各个手机表现不一样，在性能好的手机上面，会出现图像抖动厉害的情况等等。
要解决图像jzdxt的问题，先要知道jzdxt的原因：
1.由数据在传输过程中丢失，没有数据，造成的jzdxt
2.app端接收不及时，造成数据丢失而引起的jzdxt
3.为了减少花屏，而造成的jzdxt，比如说刚好丢失了i帧，为了后面显示不花屏，会对后面的p帧进行抛掉，直到下一个i帧才开始显示
我们都知道花屏的原因是因为丢帧造成的，比如说丢失了 i帧，关键帧，后面的p帧送去给ffmpeg解码得到的图像是花屏，或者马赛克等等（也有一种是大p,小p的说法，这里就不详细说了），【注意，这个传输过程没有用到b帧，整个传输过程只有两种帧 i帧，个p帧】,多一点花屏，可以减少jzdxt，客户更能接受的是jzdxt，而不是花屏。
解决方案：
第一个问题：由数据在传输过程中丢失，没有数据，造成的jzdxt，有外部环境的影响，也有图传板信号的稳定性影响等等，app端没有很好的解决方法，无非就两个选择，一个是tcp传输，一个是udp传输。根据实测，tcp效果更好一点。
tcp ：数据传输过程，能保正数据的完整，所以花屏少点，距离相对upd会近一点，
udp：传输过程不保证数据的完整性，容易花屏，距离比较远
第二个问题：app端接收不及时，造成数据丢失而引起的jzdxt，我这里遇到的情况是这样的，之前的接收数据跟解码同一个线程，显示另外一个线程，这样就有一种情况就是解码不及时，会造成接收线程阻塞，从而影响了数据的接收（udp）,解决方案是接收数据自己一个线程，解码跟显示一个线程，中间通过缓存队列来进行数据的共享，即增加缓存，基本所有的在线播放都是用这个方式。
第三个问题：就客户需求而定，我这里为了不花屏，会直接丢掉
项目使用mpv+EventBus的方式非常灵活，模块的替换，复用，重写都很灵活，而且java层没有特殊必要，一般都不会动，优化各个方面都是在jni层，也主要是图传的优化，这样也方便版本的迭代，要不客户版本升级要多痛苦。
分享是人类进步的源泉，可参考：
http://blog.csdn.net/ad3600/article/details/54706102
http://blog.csdn.net/tpyangqingyuan/article/details/54574977