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

[Corey Hickey]

John Stebbins wrote:
> More feedback for anyone interested in this thread.

I'm interested, but I've been busy with other junk...

> Something that I stumbled across last night that hadn't occurred to me
> before.  If you re-encode an avi file that already has audio delayed, you
> will be incrementally delaying the audio even more.  E.g. you have
> high quality archive of h.264 and you want to transcode to lower
> resolution for a portable device.  To do this correctly, the user needs
> to be aware that the audio will need to be manually adjusted
> (e.g. -audio-delay -0.83) to get the proper sync. Note the value of
> the manual adjustment depends on the amount of delay that was
> inserted into the high quality archive copy and has nothing to do with
> the new encoding format. So the user also must remember the original
> settings used to encode their archive.

You can also use -ignore-start, if dwStart hasn't been altered for other
reasons.

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).

> 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:
$ mplayer tricked.avi -v -frames 0 2>&1 | grep -A10 'STREAM Header'
====== STREAM Header =====
Type: vids   FCC: FMP4 (34504D46)
Flags: 0
Priority: 0   Language: 0
InitialFrames: 0
Rate: 2997/125 = 23.976
Start: 0   Len: 241
Suggested BufferSize: 32187
Quality 0
Sample size: 0
==========================
--
====== STREAM Header =====
Type: auds   FCC:  (1)
Flags: 0
Priority: 0   Language: 0
InitialFrames: 1
Rate: 48000/1 = 48000.000
Start: 2002   Len: 478478
Suggested BufferSize: 96000
Quality 0
Sample size: 4
==========================

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