[FFmpeg-devel] movenc produces improper QuickTime files

[Baptiste Coudurier]

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Jun 02, 2007 at 12:45:28PM +0200, Baptiste Coudurier wrote:
>> 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 ?
> 
> ok
> 

Done.

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