[Ffmpeg-devel] raw video support in quicktime wrongly assumesrawaudio
Fri Nov 3 17:37:06 CET 2006
----- Original Message -----
From: "Baptiste Coudurier" <baptiste.coudurier at smartjog.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu>
Sent: Friday, November 03, 2006 4:55 PM
Subject: Re: [Ffmpeg-devel] raw video support in quicktime wrongly
> Tomas Stenlund wrote:
>>> Yes. Point is that 'hdlr' atom can be located after 'stsd' atom,
>>> therefore codec type is not known while parsing 'stsd'.
>> In the Quicktime file format document they say:
>> Atoms within container atoms do not have to be in any particular order,
>> with the exception of handler
>> description atoms. Handler description atoms must come before their
>> data. For example, the media
>> handler description must come before a media information atom. A data
>> handler description atom
>> must come before a data information atom.
> hum, seems right for mov, however :
> Quote from 14496-12, isom media (mp4/3gp):
> 2) It is strongly 'recommended' that all header boxes be placed first in
> their container: these boxes are
> the Movie Header, Track Header, Media Header, and the specific media
> headers inside the Media
> Information Box (e.g. the Video Media Header).
> Strictly speaking, it is not mandatory, and I have at least one sample
> where it comes after, and Quicktime reads it well.
Agree, I wasn't trying to argue a case here. The implementation of a
filereader that assumes ordering when ordering is not enforced by the
standard is bound to fail miserably:
But by drawing the mp4 and 3gp into the discussion here I assume you are
considering a generic reader since they all share the same base.
>> And they always show the layouts of the atoms and structures in a
>> I'm a bit confused here, what atoms are handler description atoms ? But
>> I guess you are
>> correct, that the order is not given and that it is better to be safe
>> than sorry.
>>> Solution is to delay 'stsd' parsing until we are sure about the codec
>>> type. Im actually working on it.
>> Reading in the entire moov structure or just that part ?
> Just 'stsd' part. Anyway it seems that not overwriting codec_type might
> be better than nothing. It will not be perfect though.
Who is ;-)
> Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
> SMARTJOG S.A. http://www.smartjog.com
> Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
> Phone: +33 1 49966312
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel