[MPlayer-dev-eng] [PATCH] mencoder, B-frames, and video/audio delay

[Nico Sabbi]

Corey Hickey wrote:

>Corey Hickey wrote:
>  
>
>>Meanwhile, I'm going to just prepare a patch that makes mencoder's XviD
>>encoding set the encoder delay based on the number of B-frames.
>>Realistically, that should do exactly the same thing. Using a variable
>>set by XviD would just be nicer/cleaner.
>>    
>>
>
>Ok, here's the current patch. Unfortunately, it seems for x264 I can't
>access mod->x264->frames.i_delay because x264.h doesn't expose any
>details about the x264_t structure. So, I had to stick with
>mod->param.i_bframe instead.
>
>Does the attached patch look ok? Should I apply it?
>
>-Corey
>  
>
>------------------------------------------------------------------------
>
> 
>Index: libmpdemux/muxer.c
>===================================================================
>RCS file: /cvsroot/mplayer/main/libmpdemux/muxer.c,v
>retrieving revision 1.13
>diff -u -r1.13 muxer.c
>--- libmpdemux/muxer.c	9 Jan 2006 19:35:44 -0000	1.13
>+++ libmpdemux/muxer.c	23 Jan 2006 21:17:35 -0000
>@@ -142,7 +142,7 @@
>       // VBR
>       s->h.dwLength++;
>     }
>-    s->timer=(double)s->h.dwLength*s->h.dwScale/s->h.dwRate;
>+    s->timer=(double)(s->h.dwLength + s->encoder_delay) * s->h.dwScale/s->h.dwRate;
>     s->size+=len;
>     
>  
>
Are you sure that this patch fixes desync? Since the delay is constant 
(and not per frame)
mplayer will start with the first pts being correct (because it's 
necessarily an I frame) but all
B frames will still have  pts(b) > pts(p) because frames come out in 
decoding order (P3 B1 B2).

All in all I think that your patch may somehow help, but it won't assign 
the correct timestamp to
frames.

BTW, when I tried to implement a framer for mpeg1/2 video (my patch must 
be still
archived in gmane) I noticed that mencoder and mplayer really _hated_ 
seeing frames' pts
moving backwards (P->B transition), causing , much more desync than the 
use of a framer
layer was supposed to fix).

    Nico