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

James Hastings-Trew jimht at shaw.ca
Sat May 24 15:26:30 CEST 2008


Raimund Berger wrote:
> belcampo <belcampo at 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 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.
>>     
>
> 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.



More information about the MEncoder-users mailing list