[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.
/Joakim
More information about the ffmpeg-devel
mailing list