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

Michael Niedermayer michaelni
Tue May 25 18:07:50 CEST 2010

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100525/6d141ac0/attachment.pgp>

More information about the ffmpeg-devel mailing list