<div dir="ltr"><div><div><div>I am using GStreamer 0.10.30 (please, no comments) to send an H264 RTP stream. This starts from a GStreamer RTSP server and the architecture is a bit strange. There is an app that receives MP2T packets from the network and writes them to the loopback interface after decrypting them. I have an app that receives those MP2T packets and transmuxes them to RTP, also writing the packets to the loopback interface. The RTSP server pipeline reads from the loopback interface and writes to eth1. The problem is that I seem to be losing RTP packets on the loopback interface. I believe this to be true because I added a log message in gstrtph264pay.c to log the RTP sequence number of each packet that is pushed and I compared that list of sequence numbers to a packet capture. The logged RTP sequence numbers monotonically increase but the packet capture sequence numbers show gaps. Needless to say, the remote display is bad, which confirms that packets are missing.<br>
<br></div><div>There is one important point to note. There are a lot of MP2T packets. The average frame is 10-12 K bytes. MP2T packets have 188 bytes. The loopback interface is quite busy.<br></div><div><br></div>IFCONFIG doesn't display any dropped packets or errors for the loopback interface. The default txqueuelen for that interface is 0. I changed it to 1000 but that didn't make any difference. I added a call to usleep(500) (500 microseconds) between packets (not frames) and that didn't make any difference.<br>
<br></div>This system is running on a server that runs several LXC containers, so it is virtualized. I don't know anything about the effect that has on the loopback interface performance.<br><br></div>I am out of ideas. Can anyone make any suggestions?<br>
<br>Thank you,<br>Chuck Crisler<br></div>