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

[Nico Sabbi]

Corey Hickey wrote:

>Nico Sabbi wrote:
>  
>
>>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).
>>    
>>
>
>Isn't that the reason muxer_lavf doesn't currently work with B-frames
>correctly? It sets pts directly from the stream timer, which increases
>linearly while at the same time frames arrive in decoding order.
>
>pkt.pts = (stream->timer /
>av_q2d(priv->oc->streams[pkt.stream_index]->time_base) + 0.5);
>  
>

exactly

>
>muxer_lavf will still work with the application of this patch because
>the stream timer doesn't get adjusted in the absence of B-frames. The
>other muxers (I think) don't care about the stream timers -- they just
>write frames in the order they arrive. Am I mistaken? 
>

you are right: avi doesn't even use stream->timer and muxer_mpeg makes 
its good
bunch of dirty work

>You know much more
>about that than I do. How does mpeg handle a-v sync?
>  
>

it doesn't handle sync (it's mencoder's task), but it surely assigns 
correct timestamps
because it parses video and audio frames individually (and consequently 
it can tell
B frames)

>  
>
>>All in all I think that your patch may somehow help, but it won't assign 
>>the correct timestamp to
>>frames.
>>    
>>
>
>In any case, I've been mulling over the idea of, instead of adjusting
>the stream timer, leaving it be and having mencoder compensate when it
>calculates the AV_delay variable. If there's an advantage to that
>aproach, I can do it.
>
>-Corey
>
>  
>

I have the feeling that the new code would be equivalent to the current 
patch: only mencoder's core
is affected.

    Nico