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

[Luca Barbato]

On 05/24/2010 12:24 PM, Michael Niedermayer wrote:
> please tell me if you
> A. Do understand that your design requires additional delay compared
>    to my suggestion but consider this irrelevant / too difficult to fix
> B. Do not understand that your design requires additional delay compared
>    to reordering and vbv using the same buffer

> iam asking because your mail simply talks about things unrelated
> to the problem

I tried to summarize since this thread is getting lengthy.

I'm not seeing how to get this done w/out leaking rtp specific details
through about 2-3 layer of abstraction. The whole point of this patch is
to trade additional delay for reduced corruption so I think it's pretty
clear that no matter what you do, you are adding delay and make the
whole decoding process lesser and lesser than realtime.

if a frame is split in 4 rtp packets you have
   seqno  ts
   1234   0
   1235   0
   1236   0
   1237   0

if you have misordering you get

   1234   0
   1237   0
   1235   0
   1236   0

now at 1237 we should drop 1234 and the following till we get a newer
frame or queue up 1237 and see what happens. We have to wait till 1237
before outputing a frame, no matter what.

situations like

   1234   0
   1238   12
   1235   0
   1236   0

are more annoying obviously

lu - mandating fragmentation at rtp level wasn't a good idea...

-- 

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