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

[belcampo]

Raimund Berger wrote:
> 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.
> _______________________________________________
> MEncoder-users mailing list
> MEncoder-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
Looking at

Re: [MEncoder-users] Merging H.264/AAC movies [HELP]
from 05/20/08 22:02

it looks like a current SVN-problem not a general problem as you suggest.


Raimund Berger wrote:
 >>> >>> It's one of several issues I ran into with svn. By now, I tend to
 >>> >>> advise against using it and rather revert to rc2, if reliable and
 >>> >>> predictable behavior is desired.
 >> >> I don't pay much attention to quicktime stuff, but if the ffmpeg
 >> >> developers are unaware of deficiencies in the lavf demuxer, you 
ought to
 >> >> file a bugreport for them.
 > >
 > > Sure, when I come around to it. I believe it's a known issue though,
 > > as there have been page long discussions on the handbrake forums about
 > > mplayer not correctly handling their video due to it's ignoring edit
 > > lists.

I don't know how much overlap there is between ffmpeg and handbrake
development; just because something is known to some people doesn't mean
it's known to the ffmpeg developers.  :)

I just searched the ffmpeg issue tracker and didn't find anything, so
reporting the bug would be nice, and would make it more likely to be
fixed. Even if it is a known bug, I'm pretty sure getting it into the
tracker would be appreciated.

-Corey