[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets
Luca Barbato
lu_zero
Tue May 25 02:09:28 CEST 2010
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
More information about the ffmpeg-devel
mailing list