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

Joakim Plate elupus
Tue May 25 21:43:27 CEST 2010

Michael Niedermayer <michaelni <at> gmx.at> writes:

> On Tue, May 25, 2010 at 10:29:55AM +0000, Joakim Plate wrote:
> > 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.
> if an application fills a fifo without bound from the demuxer 
> it will read a whole file from disk in the fifo, a few gb maybe.
> so your argument against applies completely independant of rtp design
> or even rtp support. unless you choose not to support playback from
> files at all
> [...]

Well in our case the fifo is bound by a time size. That time size is however 
much much larger than an acceptable delay for startup of a live stream. So that 
is never full when playing live streams -> we are always blocking in lavf 
reading next packet, even if our fifo has something in it.

I suppose we could change the limit when we happen upon a live stream, but 
knowing it's live isn't that easy. So normally we start playback as soon as 
av_find_stream_info has finished and all codecs are done initing (not perfect 
but normally okey).

But okey, suppose I can't contribute much more to this discussion, was just a 
though from a players perspective.


More information about the ffmpeg-devel mailing list