[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets
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
if you have misordering you get
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.
are more annoying obviously
lu - mandating fragmentation at rtp level wasn't a good idea...
More information about the ffmpeg-devel