[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets
Mon May 17 16:48:55 CEST 2010
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.
More information about the ffmpeg-devel