[MPlayer-users] Bug: av sync, bframes, dwStart issues

[Nico Sabbi]

Corey Hickey wrote:

> I agree, though, it's not at all ideal. I'm open to suggestions. At the
> moment, I don't see how to make mencoder recognize how many frames
> decoder output has been delayed (I'm not implying it can't be done--just
> that I haven't figured out how).
>  
>

the delay may be variable (depending on the number of bframes present),
so it should be updated for every frame in the encoding loop

>  
>
>> Corey asked if I was sure that there could be a variable number (or 0)
>> bframes in video sequences.  I did a little investigation and found
>> that both x264 and xvid can produce variable numbers of bframes in
>> a video sequence.  x264 will not insert a bframe if it does not improve
>> bitrate and xvid will refrane from inserting bframes depending on
>> some PSNR thresholds that can be set.
>>   
>
>
> Yes; lavc will do that too, depending on the vb_strategy parameter (see
> also b_sensitivity and brd_scale).
>
> What I was wondering, though, was whether the B-frame variation actually
> affected A/V sync within the file, as you had indicated. Have you
> observed this effect with any video players? I just ran a test with
> mplayer and there wasn't a problem.
>
> 1. To establish the baseline, encode a file with B-frames. This
> particular source file has a very recognizable sound synchronized with
> the first picture after a series of black frames.
> $ mencoder serenity_m420p.mov -oac pcm -ovc lavc -o normal.avi \
> -frames 240 -lavcopts turbo:vmax_b_frames=1
>
> 2. Play the file with dwStart recognized. Make sure synchronization is
> correct.
> $ mplayer normal.avi
>
> 3. Play the file without dwStart. The audio should be one video frame
> early because it's not delayed to compensate for the video delay.
> $ mplayer normal.avi -ignore-start
>
> 4. Now, encode the same file with B-frames, but with an invalid
> vb_strategy. This makes lavc encode the file with B-frames specified but
> choose not to actually use any. Currently, there is no vb_strategy=3;
> this might not be true in the future.
> $ mencoder serenity_m420p.mov -oac pcm -ovc lavc -o tricked.avi \
> -frames 240 -lavcopts turbo:vmax_b_frames=1:vb_strategy=3
>
> 5. Check the file to be sure there aren't any B-frames:
> $ mplayer tricked.avi -v -lavdopts debug=1 -nosound -vo null \
> -benchmark 2>&1 | tr '\r' '\n' | awk '/^\[mpeg4/ {print $5}' \
> | sort | uniq -c
>      7 I
>    233 P
>
> 6. Check the file to make sure it still uses dwStart:
>
> 7. Do the same listening tests. I'm seeing/hearing the same results.
> If the video weren't being delayed in sequences without B-frames, then
> playing the file with dwStart would result in the audio being one frame
> too late (and, without dwStart, being in sync).
>
> -Corey
>  
>

due to the variability of the decoding2display delay the value of dwStart
can't be relied upon to keep exact sync (consequently there's no way
to keep in sync an avi with a video stream with b-frames, even less so 
when the
number of consecutive b-frames is variable)