Video streaming gstreamer管道中的rtpjitterbuffer

我目前正在调试一对gstreamer管道，涉及Jetson TX2发送和接收音频和视频。我正试图找出是什么原因导致了TX2流中的图形瑕疵，其中通过rtp捕获和流式传输h264（本机生成h264流，TX2仅负责加载和发送）的摄像头。在视频接收管道上线之前，该传输流的性能是可接受的，此时传输流的视频质量急剧下降

我已经在接收桌面上设置了一个动态gstreamer管道，它记录调试语句，并利用延迟为0的rtpjitterbuffer来监视TX2正在传输的流上的统计信息

传统的gstreamer智慧是，向接收桌面管道添加队列和/或rtpjitterbuffer应该可以改善一些问题。添加和删除具有各种设置的队列和jitterbuffers会导致在12个不同测试中，每推送100k个数据包，平均会丢失大约100个数据包。不用说，视频质量没有提高，因为没有队列或抖动缓冲区，平均每100k丢失95个数据包

现在，我不顾传统智慧和文档，还测试了在TX2传输端管道上放置队列和jitterbuffer，并发现了显著的改进。通过简单地添加一个队列（每100k 52个），接收端的数据包丢失减少了一半，并且当与jitterbuffer结合时（即使延迟设置为0），数据包丢失也会下降到每100k 0个

问题是：为什么？虽然有一个完全缓解我所看到的问题的解决方案很好，但我也需要一个合理的解释来支持这个解决方案。有人有想法吗？也许，在TX2方面寻找证据的地方

---

---

20年12月22日

经过更多的挖掘，这个问题似乎围绕着同时发送和接收多媒体。在我们的系统中，TX2的工作是发送和接收视频/音频，当向TX2发送AV的编码器在网络上处于活动状态时（它是多播），就会发生数据包丢失。通过gstreamer调试和wireshark日志读取数据包，说明当AV编码器和TX2都是与IDR帧（视频关键帧）相关的突发数据包时，数据包丢失的情况。在Jetson视频流的两端设置wireshark显示丢失的数据包正在发送到接口驱动程序，但在到达接收计算机的接口时消失。这很容易被认为是网络丢失，但是，网络并不繁忙，查看接口卡上的I/O流量可以发现，它的容量远远不够（100 Mbit连接中约11 Mbit）

仍然在试图弄清楚为什么Tx端jitterbuffer可以解决这个数据包丢失问题。根据建议，我在网络接口内核设置上增加了写缓冲区和读缓冲区的大小，但这并没有解决问题。使用netstat-sanu进行检查确实显示，在所有运行的程序中都注册了一些“发送缓冲区错误”，但是使用诸如bmon之类的应用程序进行的网络监控不会报告丢失的数据包。目前正在重新编译内核，以便Jetson允许我运行dropwatch