Re: [MEncoder-users] number of yuv4mpeg frames does not match audio length
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 Henk Schoneveld
However this is what I get with mplayer, mencoder and ffmpeg. ffmpeg gives by far the strangest output.
mplayer -harddup -noframedrop -vo yuv4mpeg -ao null test.vob
333 frames
mencoder test.vob -vf-add harddup -vf-add =i420 -ovc raw -of rawvideo -nosound -o mencoder.420
333 frames
ffmpeg -i test.vob -f yuv4mpegpipe ffmpeg.yuv
342 frames (starting with 1 totally green frame)
Especially the ffmpeg output is quite surprising. I guess the mplayer/mencoder output could be correct, and the sync problem is elsewhere, though this still doesn't account for the missing frame...
Any advice would be greatly appreciated!
Maarten
Henk Schoneveld <belcampo@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.
Raimund Berger wrote:
Henk Schoneveld <belcampo@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@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
belcampo <belcampo@zonnet.nl> writes:
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@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.
Not sure what you mean by "general", but it seems I said svn. Again, it depends on the mp4 demuxer. In rc2, it defaults to mencoders own mov/mp4 demuxer, which does take account of elst atoms. In svn though, somewhere along the way, the lavf demuxer was made the default, and that one does not honor edit lists. Obviously, the latter is a known issue, as it has been noted on that ffmpeg task list. The reason I mentioned it here was just to prevent people wasting time when it turns out that the MP4Box delay parameter has no effect whatsoever on playback with mplayer svn, *unless* they explicitly turn on the internal mov demuxer. Apart from that I didn't suggest anything, as far as I can tell.
Raimund Berger wrote:
belcampo <belcampo@zonnet.nl> writes:
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@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.
Not sure what you mean by "general", but it seems I said svn.
Again, it depends on the mp4 demuxer. In rc2, it defaults to mencoders own mov/mp4 demuxer, which does take account of elst atoms. In svn though, somewhere along the way, the lavf demuxer was made the default, and that one does not honor edit lists. Obviously, the latter is a known issue, as it has been noted on that ffmpeg task list.
The reason I mentioned it here was just to prevent people wasting time when it turns out that the MP4Box delay parameter has no effect whatsoever on playback with mplayer svn, *unless* they explicitly turn on the internal mov demuxer. Apart from that I didn't suggest anything, as far as I can tell. I mentioned it in the first place because in my experiments with the MP4Box delay parameter, I found that Quicktime Player also does not seem to honour the delay, which is kind of a big deal if you are encoding for iPod, Apple TV, playback through Front Row, or any of those Apple Quicktime related things. YMMV.
participants (4)
-
belcampo -
Henk Schoneveld
-
James Hastings-Trew -
Raimund Berger