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

[Luca Barbato]

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.

So basically instead of discarding the misordered packet as we have now
you just introduce some delay before hoping you catch it within this window.

So if your network doesn't play tricks to you you'll never have this
code path triggered. When it happens the application would just risk of
depleting the decode buffer instead of having holes.

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

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero