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

Michael Niedermayer michaelni
Tue May 25 19:43:02 CEST 2010

On Tue, May 25, 2010 at 02:09:28AM +0200, Luca Barbato wrote:
> 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.

droping is insane
you should never ever drop an incomplete frame

with "max_delay"=0 you should wait until you have either
A. a complete frame (in which case you return it)
B. the first packet of the next frame (in which case you return the incomplete
   previous frame)

> situations like
>    1234   0
>    1238   12
>    1235   0
>    1236   0
> are more annoying obviously

yes, obviously

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

its a great idea and required for error resilience. Of course it only
works with implementations that dont drop perfectly decodeable parts of a

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
-------------- 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/20100525/f86b6346/attachment.pgp>

More information about the ffmpeg-devel mailing list