PCM audio encoding loses synchronization with video

[logic]

Summary of the bug: I was looking to work around the bug in ticket #2322, and decided to produce an intermediate file with lossless encoding (x264 qp=0 and PCM audio) which I could then re-encode with the desired output codec and get subtitles properly synchronized. This approach generally worked, but I ran into an issue where the synchronization between audio and video was significantly shifted. Without adequate knowledge of the internals, I am nevertheless ascribing this to the fact that PCM audio was used in the intermediate file. I do not know whether the synchronization was lost as part of writing the intermediate file, or as part of playing it back for the second-phase transcode (or perhaps even some and some).

How to reproduce:

c:\mplayer\mencoder.exe br://1 -bluray-device D:\ -utf8 -vf harddup,crop=1920:858:0:136,scale=1280:572 -sws 9 -mc 0 -o IntermediateFile.avi -ovc x264 -x264encopts qp=0 -alang eng -alang eng -oac pcm -ni

c:\mplayer\mencoder.exe IntermediateFile.avi -sub SongsOnly.srt -utf8 -vf harddup -sws 9 -mc 0 -ass -ass-color FFFFFF00 -subfont subfont.ttf -nofontconfig -ass-font-scale 1.4 -o WithSubtitles.avi -ovc x264 -x264encopts crf=20:subq=7:frameref=6:me=umh:8x8dct:partitions=all:bframes=3:b_adapt:b_pyramid=normal:weight_b:qcomp=0.7:keyint=1000 -oac mp3lame -lameopts vbr=3:br=192:q=0:aq=0:mode=1

With this reproduction, the output file has its subtitles correctly lined up (whereas directly applying them to the br:// URL produces synchronization problems -- as described in ticket #2322), but the audio is a full second behind the video.

For this particular transcode, I was able to get the audio properly synchronized with the video by adding the following option to the second-phase transcode:

-delay 1.032

I also had to correspondingly shift all the subtitles in the SRT file by -1.032 seconds.

(For anybody curious, the title is 110 minutes long, and the intermediate file with x264 lossless encoding and PCM audio came out to 52.2 GB :-3 It also both encoded and plays back extremely slowly, but that isn't a problem for the transcode, and the final output file is just a few GB and plays nicely.)

[logic]

I forgot to mention the MPlayer version in the summary. I performed this transcode with SVN r37927. As of writing this comment, there have been 4 commits since then, but it is pretty much HEAD.

[logic]

Two additional comments:

• The delay of 1.032 seconds was arrived at through experimentation and playing with the +/- numeric keypad buttons to fiddle with the audio delay. It is certainly not definitely an "exact" value to the millisecond.

• I've just discovered that the audio delay is different when the same file is played in VLC Player. From my past experience, I'm willing to chalk this up to VLC Player being a bit "funny", but I thought I'd mention it for completeness.
  • When played in MPlayer, with -delay 1.032, the audio and video appear, to the naked eye, to be synchronized.
  • When played in VLC, the exact same file has the audio perhaps 0.2 or 0.3 seconds ahead of the video. Close, but no cigar!