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

[Michael Niedermayer]

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>