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

[Martin Storsjö]

Hi,

Howard Chu recently pointed out a Youtube RTSP url that didn't work well 
with ffmpeg:

rtsp://v4.cache7.c.youtube.com/CkYLENy73wIaPQlAxD6Aps4FuxMYEiASFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFpbGD82u-DktbbwUsM/0/0/0/video.3gp

The audio track uses MP4A-LATM, which isn't supported at the moment, but 
the video is H.264 which should be supported, but regardless of that 
didn't work well at all.

It turned out to be that this video sends H.264 RTP packets out of order, 
or at least I always received the packets shuffled.

That is, if dumping the RTP seq values, I get something like this:
17
19
21
23
25
16
18
20
27
22
24
26

So all packets were received, but the receiver needs to buffer quite a few 
of them in order to decode it.

The attached patch is a first (ugly) stab at solving this, with this 
applied, I'm able to decode the video track of the URL above quite well.

The question to those that know more on RTP than me is, is there any 
sensible reason why the google RTSP server would intentionally send data 
out of order like this, or is it all due to the network? The server 
doesn't seem to support TCP interleaving, so that can't be used to rule 
out the network.

Even if this isn't intentional, it may be beneficial for us to do a little 
reordering of packets, if using UDP transport.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Buffer-a-few-RTP-packets-in-order-to-reorder-them-pr.patch
Type: text/x-diff
Size: 3094 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100516/3b762d1e/attachment.patch>