[FFmpeg-devel] movenc produces improper QuickTime files

[Michael Niedermayer]

Hi

On Wed, May 30, 2007 at 12:43:23AM +0200, Diego 'Flameeyes' Petten? wrote:
> On Wed, 30 May 2007 00:04:10 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > umm [1] does not look like the quicktime spec so i fear its contents
> > have no relevance here
> Okay, well, I tried to find the best thing from [2] that had some
> specific value.
> 
> [2] http://wiki.multimedia.cx/index.php?title=MOV 
> 
> > movenc does not use anything besides the value it is told to use
> > and that one is in your case likely simply what the input file used
> > using any other value is incorrect
> Well, it uses only the denominator of the time_base...

thats not wrong ...


> 
> > ask your favorite math professor/teacher/book why you cant just use 3 
> > instead of pi ...
> 3.14 is not pi either... 

of course not


> 
> > before a fix comes a bugreport, and between fix and bugreport comes
> > some anaysis of the problem, you are jumping over a few things here
> > and are lucky i dont flame you to death for trying to hack the
> > timebase in the demuxer
> Okay, so let me try to explain the problem the best I can:
> 
> QuickTime does not support MOV/ISO Media/Whatever-you-want-to-call-it
> files that have mdhd atoms version 1 (64-bit based time), it only
> accepts version 0 (32-bit based time). Sure, it can be called a bug in
> QuickTime, but at least I expected ffmpeg to produce QT-playable files
> when declaring them being QuickTime files (the "qt  " specifier at the
> begin of the file should identify the file as QuickTime-compatible, or
> am I wrong?).

you are correct, the mov muxer should fail with an error message if
a timebase is required which quicktime does not support


> 
> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070530/a1da64d4/attachment.pgp>