[FFmpeg-devel] movenc produces improper QuickTime files

[Michael Niedermayer]

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

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/20070602/26530eaf/attachment.pgp>