[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets

[Martin Storsjö]

On Tue, 25 May 2010, Michael Niedermayer wrote:

> very low delay is absolutely mandatory for some applications and refusing
> to return the correct packet if you have 2 packets is just insane.

Well, that's what the code currently does, too.

The code we've proposed up til now doesn't make the "minimum delay" case 
any different from what it does now, if the reordering is disabled.

> i dont object to a max_delay (in milli second or such)
> i object to the code returning the wrong packet of several
> that it has immedeately available if max_delay=0 or for example
> if there are 5 packets in the kernel buffer and max_delay=1 to then
> limit reordering to 1 packet (and drop 3 as they kernel buffer overflows
> till the next call of av_read_frame())

I tried implementing something like the thing I outlined above, and this 
should handle these cases where all the necessary packets are in kernel 
buffers but in incorrect orders.

That is, first we try to receive as many packets as we need to get the 
correct one using nonblocking reads. If the correct one isn't available at 
all, then we return the first one of the packets in the reorder queues 
when max_delay has expired.

The attached patches does this - they're untested, but try to show roughly 
how this could be implemented.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-wait-parameter-to-udp_read_packet.patch
Type: text/x-diff
Size: 2196 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100526/04c4ac4c/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Receive-as-many-packets-as-needed-in-nonblocking-mod.patch
Type: text/x-diff
Size: 3142 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100526/04c4ac4c/attachment-0001.patch>