Frame drop when playing RTP stream using SDP file

[Tim Müller]

On Wed, 2016-05-18 at 08:54 -0400, Nicolas Dufresne wrote:

> I've looked into the payloader/depayload code, I'm not sure this is
> done correctly. First part is on the payloader, my quick read tells
> me it's splitting frames in 10 chunks rather then calculating the
> appropriate divider from the MTU size. This means the sender may
> endup producing large UDP packets that get split by the protocol. It
> also produce burst. On the receiver side, the depayloader does not
> expose it's latency. Unless the video frame fit into a single UDP
> packet, it's impossible to reconstruct that frame without inducing
> latency. The latency the number of chunk per frame - 1 (we usually
> round up to the number of chunk so we give the display a little more
> time to react). For the tearing and green bar at start, that would
> seem the result of missing packets at start and drops. I think the
> depayloader should just drop the packet until it gets the first line
> of the following frame. I doubt it's doing that atm. You will still
> get green lines whenever a packet was dropped, though drops should be
> rate if you get the burst part fixed.

In case of rtpvrawpay, a raw video frame might be split up into many
thousand RTP/UDP packets.

What the payloader is trying to do is not split up the frame as a whole
into N thousand packets, and then send those all at once by pushing
them to the udpsink in one go, but rather payload a part of the frame,
then send those RTP/UDP packets already to udpsink to send out, then go
and payload the next part of the frame, etc.

This should reduce burstiness and latency.

The behaviour can also be configured with the "chunks-per-frame"
property.

Cheers
 -Tim


-- 
Tim Müller, Centricular Ltd - http://www.centricular.com