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

[Martin Storsjö]

On Sun, 23 May 2010, Luca Barbato wrote:

> On 05/23/2010 05:39 PM, Michael Niedermayer wrote:
> >> So given this, I still think the reordering should be done at the rtpdec 
> >> layer.
> > 
> > thats what i suggested
> > what is unclear to me is how you intend to decide what and when to return
> > things from the queue.  I suggested that the user application decide. how do
> > you want to handle this, an application might need audio a bit before video
> 
> > And how do you intent to keep the clocks synchronized? currently an application
> > could decode too fast and then get stuck when its out of data and all buffers
> > are empty
> 
> I think the idea is to keep filling the queue without returning till:
> 
> - you have the packet in-order
> - the queue hits its size limit.

This is exactly what the patch does currently.

As long as packets are received in order, they're returned immediately. If 
we miss one, we queue the following ones up, either until the missing 
packet is received, or until the queue is full. Once the queue is full, we 
return the first packet in the queue (and ignore the missing packet if it 
arrives too late), and return all the other sequential packets in the 
queue following this one.

> I agree that the reorder buffer size should be set by the 
> application/user.

Ok, so I'll try to think about a better way of handling this.

// Martin