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

[Michael Niedermayer]

On Mon, May 17, 2010 at 05:48:55PM +0300, Martin Storsj? wrote:
> On Mon, 17 May 2010, Michael Niedermayer wrote:
> 
> > On Mon, May 17, 2010 at 10:19:32AM +0300, Martin Storsj? wrote:
> > > On Mon, 17 May 2010, Luca Abeni wrote:
> > > 
> > > > Hi Martin,
> > > > 
> > > > On 05/16/2010 09:41 PM, Martin Storsj? wrote:
> > > > [...]
> > > > > So, here's a more proper implementation of RTP packet reordering.
> > > > 
> > > > Just a small suggestion: I think the queue size should be configurable
> > > > (when I want to receive a stream with a very low latency, a lost packet
> > > > is sometimes better than receiving the packet after some reordering
> > > > delay).
> > > 
> > > That's a good idea. How should the user of libavformat convey this desire 
> > > to the rtpdec code? There's the AVFormatContext->max_delay parameter, but 
> > > real world time doesn't map directly into a certain number of packets. 
> > > One would have to make some kind of educated guess about the number of 
> > > packets per second, in order to map the max_delay parameter into a packet 
> > > queue length.
> > 
> > rtp packets have timestamps, dont they?
> 
> Yes, but the reordering is done based on packet sequence numbers - one 
> frame can be split to many packets with the same timestamp, but with 
> unique sequence numbers. I guess we could allocate a large enough packet 
> queue (and perhaps enlarge it if needed), and change the "queue full" 
> condition to check the range of timestamps in the queue, though.
> 
> Isn't max_delay usually 0 unless set to something else - it doesn't even 
> seem to have an AVOption for estting it? For this scenario, I think Ronald 
> would agree that we'd by default want to have a non-zero default for the 
> reordering queue length.

the default should be moved from ffmpeg.c to AVOptions
a description should be added to the field in AVFormatContext


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100517/0dfe793f/attachment.pgp>