networking problem...losing packets...looking for ideas

[Sebastian Dröge]

On Mo, 2013-12-09 at 16:03 -0500, Chuck Crisler wrote:
> 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.
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> I am out of ideas. Can anyone make any suggestions?

Which sequence numbers show gaps? The RTP stream you create, or the
MPEGTS stream already? Does everything work fine if you just capture the
MPEGTS stream to a file, also how do you capture it currently, what's
the pipeline you have?

As a first step I would try to isolate the problem by first checking if
it's on sender or receiver side, and then cutting down the pipeline as
much as possible.


-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131213/4f221aa9/attachment.pgp>