[FFmpeg-devel] [PATCH] rtpdec: Better logic for immediately returning packets from the queue

[Martin Storsjö]

Hi,

I realized the RTP reordering/queing logic could be improved a bit: If we 
receive packets 1-5 as 2, 3, 4, 5, 1, we first just queue up packets 2-5, 
and when we've got packet 1, we parse/depacketize that one.

If that returns 1, there's more data to return from the packet, and we 
return that to the caller. If the depacketization returns 0, we return the 
data and check with has_next_packet() that we've actually got the next 
packet in the sequence, too, so we return 1 to the caller, indicating that 
we can be called immediately and return more data.

But what if packets 1-5 were one single large fragmented packet? Then the 
depacketization of packet 1 would return AVERROR(EAGAIN), and return no 
data until the whole frame has been depacketized. Currently, we'd return 
the control to the caller, and only proceed to check packet 2 the next 
time we're called. These patches instead make sure we check if we have the 
next packet in sequence, and try to parse that, if the current parsing 
returned < 0.

I've tested this with the VP8 depacketizer that uses this logic, with an 
intentionally scrambled/reordered sender, and it seems to work as I intend 
now.

Opinions?

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-rtpdec-Don-t-call-the-depacketizer-to-return-more-da.patch
Type: text/x-diff
Size: 1379 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101008/f69a9f7a/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-rtpdec-Parse-the-next-packet-in-the-sequence-if-it-i.patch
Type: text/x-diff
Size: 3834 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101008/f69a9f7a/attachment-0001.patch>