视频帧的UDP传输问题

一. 前言

之前做过设备到手机的图像传输需求，由设备端开启热点，手机连接其WiFi后使用UDP Socket进行传输即可，由于这样的环境较为简单，导致自己除了碰到丢包问题，其它的UDP传输问题一个也没碰到，而此次是局域网下的视频帧传输，由于存在路由器转发以及多个路由器连接的可能，之前那套自以为是的“稳定”的代码，变得几乎不能用了，以此文记录这次遇到的问题与解决方案。

二. 问题

1. 由于视频帧会很大，这里我们需要将视频帧进行拆包发送，既可以防止数据大小超过Socket发送缓冲区总大小而导致send失败，也可以防止传输过程中的IP层分片导致的丢包问题

2. 重复收包问题，附上自己的抓包数据 image-20201116184430565.png
3. 包乱序问题，附上自己的抓包数据 image-20201116184645296.png

三. 处理后的效果

附上处理后的对比视频，手机为处理过乱序、重复包的效果，pad为未处理后的效果 test.gif

四. 问题及解决思路

1. 重复收包

这里假设一帧被拆分为5个包，每个包的大小为100字节，那么我们可以根据包编号*100作为偏移量，如第4包重复收到，那么偏移量为400，重复收到第4包后还是向偏移量400处拷贝100字节，如此就算收到重复包，帧数据也不会混乱

2. 帧内乱序

这里还是假设一帧被拆分为5个包，每个包大小为100字节，编号分别为0、1、2、3、4，假设接收端的接收顺序为1、0、2、4、3，这里收到数据后，还是像重复收包的方案，根据编号向指定位置复制数据即可，但是这里衍生出一个问题，我们如何知道所有的包都到齐了呢，之前我们是以最后一个包序号，也就是4为基准，但是发现不可行，因为如上例子，第4包有可能比第3包先到。因此我们使用了一个int定义的recv_count字段来记录收到的包总个数，每收到一个包，recv_count+1，直到recv_count为5时，代表收到了完整数据，但是此情况又衍生出一个问题，当收到重复的包时，recv_count也进行了+1，这样可能在它等于5时，还没有收到完整的数据，因此我们又定义了一个bool map[5]的数组，用这个数组构建一个简单的hash map，每当到来一个包时，使用这个包的序号作为下标访问数组元素，为false时才进行recv_count+1，并把下标中对应值赋为true，这样重复包到达时，访问该数组下标元素为true，recv_count不变，如此解决帧内乱序问题

3. 帧间乱序

图1

如图1，因为存在帧间乱序的可能，因此我们要为每一帧设置各自的缓冲区来等待数据接收完成，假设我们的缓冲区个数为3，此时有3帧数据，编号分别为0，1，2，每帧数据都被拆分成了n个包发送，假设第0帧数据还没有收完全的情况下，第1帧数据完整到达，那么此时我们能不能向解码器推入第1帧呢，在第1帧不是关键帧的情况下，答案是否定的，因为P帧是前向预测帧，它需要参考前面的帧来进行解码，因此假如这里第0帧与第1帧都是P帧时，在第0帧没有收完全时，是不能像编码器推入第1帧的，只有等第0帧收完全了，才能将第0帧与第1帧推入解码器

4. 延时问题

图2.png

假设缓冲区足够大，能容纳很多帧的情况下，如图2，最坏的情况下，第0帧未完整接收，而后续7帧全部接收完毕，那么只有一直等到第0帧完整接收才能推入后续帧，此时延时已经到达了8帧左右，因此此处缓冲区的大小问题直接决定了延时的长短

五. 总结

对UDP的认知，可能大家听说的最多的都是丢包、乱序、无拥塞等，却忽略了重复的问题，其实TCP/IP详解卷一里是有说过UDP是不提供重复消除功能的，如下图（来自TCP/IP详解卷一第十章）

tcp.jpg