[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets
Sun May 16 00:02:27 CEST 2010
Howard Chu recently pointed out a Youtube RTSP url that didn't work well
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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3094 bytes
More information about the ffmpeg-devel