[Ffmpeg-devel] raw video support in quicktime wrongly assumesrawaudio

Tomas Stenlund tomas.stenlund
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 
assumesrawaudio


> 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:
>>
>> -----8<----------8<-----------8<-----------8<----------8<-----------8<--------
>>
>> 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.
>> -----8<----------8<-----------8<-----------8<----------8<-----------8<--------
>>
>>
>
> 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
>> particular.
>> 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
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 





More information about the ffmpeg-devel mailing list