[FFmpeg-devel] movenc produces improper QuickTime files

[Baptiste Coudurier]

Hi Michael,

Michael Niedermayer wrote:
> Hi
> 
> On Wed, May 30, 2007 at 01:38:33AM +0200, Michael Niedermayer wrote:
> [...]
>>> FFmpeg produces files with a timebase too big (10000000), which easily
>>> requires mdhd to move to version 1 and then be QuickTime-incompatible.
>>>
>>> [note: mp4creator from mpeg4ip also has this option:
>>>
>>>   -use64bitstime          Use for 64 Bit times (not QT player
>>> compatible)
>>>
>>> which seems again to point to QT not being able to cope with mdhd
>>> version 1.]
>>>
>>> Now that I exposed the problem, let met try to suggest a possible
>>> solution: as I said my patch was incomplete and broken; probably a
>>> better patch would have a check that the selected output mode is
>>> QuickTime rather than other ISO media format, and then try to reduce
>>> the timebase to a value that can fit 32-bit unsigned integers.
>> first the timebase DOES fit in 32bit unsigned integers its the
>> duration of the movie in timebase units which does not ...
>>
>> second a muxer CANNOT CHANGE THE TIMEBASE!!!!!
>> not only is it not its job it simply does not work, it will lead to
>> wrong timestamps and AV desync
>> now if you try to be smart and rescale timestamps you will in some
>> case break their strict monotonicity and thus generate completely
>> invalid files, you could as well have just left the invalid mdhd ver=1
>> there
> 
> to elaborate on the problem a little
> to change the timebase so that the duration in timebase denominator units
> would fit in a 32bit integer you need to know the duration, but the
> duration is NOT known before you finished encoding the file (think of
> stdin as input)
> now changing the timebase after you encoded and muxed the file is a huge
> hack which will not work (see flames above)
> 
> what can be done though its a huge hack too, is to select some max duration
> like 24h and then choose a simpler timebase for quicktime before encoding
> starts
> 
> comments?

Well, I think quicktime player will have to support it one day or
another anyway, but it is still problematic for older versions.

I would add a warning in write header if timebase is > 100000 for video
since it will probably fail.

About the hack with duration, well if it really helps people why not,
but they can override frame rate when they know it (-r), so a warning in
write header might be sufficient, no ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312