这几天写GB28181平台接入层代码，对收到的PS包进行解包时，总是出现误码，最终导致rtsp点播服务中画面花屏。
分析了码流抓包数据之后，发现网络上没有丢包，遂认为PS流解包代码有bug，于是埋头分析了2个小时的解包函数后，没有发现问题。将抓包RTP负载中的PS包数据导出之后，专门利用PS解包代码写了一个小程序，对导出的数据进行处理，又没有问题——后来事实证明解包代码的确没有问题，而且这部分的代码是在其他项目中用过的。自己有些迷糊了，一时想不明白问题出在哪里。
起身转了几圈冷静后分析一下，认为抓包结果中的数据不代表应用实际所接收到的数据，二者之间应该是有差别的，比如数据顺序可能会不一样。遂在收包入口函数中，打印每个收到的RTP包的序号，根据序号终于发现：顺序没有乱，但是不间断的有包丢了。这可是问题了，媒体数据是直接进行PS包封装后再在RTP上传输的，丢了少量的包，会导致整个PS包都难以恢复。好在已经知问题是因为收包丢包导致的，现在又继续分析收包丢包的原因。
问题具体情况是采用UDP承载RTP包，RTP包负载部分是PS格式封包的H264码流，每收到一个RTP包，应用就立即对负载中的PS流进行尝试解包（包括必需的缓冲操作），处理完一个RTP包之后再回头继续收包。这样就导致了每次收包之间，间隔比较明显了。用“UDP收包 丢包”作为关键字在网上搜索了一些之后，了解到
采用UDP进行数据通信，若实际流量较大，但recv buffer又不够大，且没有及时进行收包时，则容易造成recv buffer满而丢包
自己业务是用UDP来接收高清视频码流，流量是不小的，并且自己的实现也的确容易导致没有及时收包，觉得上述说法可能是原因。立马进行修改验证，先将recv buffer增加2MiB，花屏现象消失，根据接收的RTP包的序号确认，现在应用层收到的RTP包没有丢包。
到此接入的问题似乎是已经已经解决了，但现在回头看UDP收包的问题，觉得简单扩大recv buffer不是根本之道，只是在本业务场景中，扩大recv buffer后，新增出的buffer尺寸对应的容量，大于视频媒体数据流量，因而没有使得buffer满而丢包。UDP收包丢包，根本上还是需要应用去及时的收包，将recv buffer的空间腾出，不然若流量继续增加，最终还是会出现buffer满而丢包的问题。
UDP收发包毕竟还是太简单，只在IP层之上简单提供收发包接口功能，不像TCP有拥塞控制和自动重传机制，相比之下应用层就需要额外做对应的收发包控制工作，而使用TCP就省事简单很多（当然实现高效的TCP通讯也不是简单的事情）。
结尾吐槽一句：那些制定GB28181标准的砖家们，你们采用PS over RTP的封包格式时，是不是脑子进水了？要知道PS流只是适合媒体数据存储的，而不是网络传输啊，要进行网络传输，干嘛不用TS封包？
~~ end ~~