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

[Joakim Plate]

Martin Storsj? <martin <at> martin.st> writes:

> 
> In that setup, one would get reordering if the packets are already in the 
> kernel buffer, but if we're forced to wait for the packet, we'd just 
> return it immediately. Then there's no extra delay.
> 
> That said, I'm not in favour of this approach - if we really want 
> reordering, we should also be ok with some extra delay, since the out of 
> order packets very well can arrive with some delay. And if we want a very 
> low delay, set the max_delay parameter to a sufficiently low value to 
> avoid all reordering/queuing.
> 
> // Martin
> 


Can't say i like this approach either. For an application that has further
fifo's after demuxing, some extra delay at demuxing would be better
otherwise the client app must take care to avoid asking for more demux
packets when it's fifo is reasonably full.

It's better if lavf took care of that for us, so that whenever there is
glitch in the rtp packets, the playback delay increases. Obviously there
would be a glitch in playback right at that point if there is no fifo
(for a live stream), but after that things should be fine.

/Joakim