[MEncoder-users] number of yuv4mpeg frames does not match audio length

[Raimund Berger]

Henk Schoneveld <belcampo at zonnet.nl> writes:

>> I am trying to convert a VOB file to h264+aac in an mp4 container (using
>> x264, faac and MP4Box). I don't get the mp4 to be A/V sync (the
>> material has some very obvious points). Investigating this problem, I
>> found that the yuv4mpeg stream that I am using as input for x264 does
>> not have the expected number of frames. As a reference, I look at the
>> duration of the extracted audio:
>>
>> mplayer -vo null -ao pcm test.vob
>>
>> Duration    : 00:00:11.168
>>
>> At my framerate of 29.97, this corresponds with 334.7 frames (not sure 
>> whether to round this up or truncate it)
> Frames do come in a GroupOfPictures. In PAL 25fps it starts with a 
> I-Frame or named keyframe till the next I-frame wich is 0.48 seconds 
> later. Every frame is (1 sec / 25 fps) = 0.04 sec. So every 12th is the 
> start of a new GOP.
> The length of a sound-frame depends on the Samplerate, sampled at 44100, 
> the framelength is half of sound sampled at 22050. So frame length of 
> video and audio differ they will be exactly the same only every now and 
> then. As an example in PAL DVB with sound sampled at 48000 it will be 
> every 1.2 sec.
> Try this for example:
> ffmpeg -i test.vob x264params -f rawvideo test.h264
> ffmpeg -i test.vob faacparams -f rawvideo test.aac
> MP4Box -add test.h264 -add test.aac test.mp4
> If you don't get prefect sync you can resolve this afterwards with
> MP4Box -delay 1=200 test.mp4
> if sound would be delayed by 200ms

While not being sure how that answers the OPs question, I don't really
want to interfere safe the single observation that this little delay
you store there into an edit list atom won't be honoured by the lavf
mp4 demuxer on playback, which is the default in SVN. Kind of for your
eyes only, to prevent waste of time in idle tests.