[FFmpeg-devel] MOV Muxer fix to respect the standard

Larbi Joubala larbi.joubala
Fri May 22 16:59:55 CEST 2009


M?ns Rullg?rd a ?crit :
> Larbi Joubala <larbi.joubala at resonate-mp4.com> writes:
>
>   
>> M?ns Rullg?rd a ?crit :
>>     
>>> "Fran?ois Revol" <revol at free.fr> writes:
>>>
>>>
>>>       
>>>>> Hi guys,
>>>>>
>>>>>     I recently found when I generated a mp4 file that this file
>>>>> doesn't totally respect the standard(ISO media file format
>>>>> 14496-12) in particulary for the box 'hdlr'. The handler
>>>>> description(named in the standard as 'name') must be a
>>>>> NULL-terminated string in UTF8 while in the generated file I saw
>>>>> that the string is not NULL-terminated and it is preceded by its
>>>>> size while it is not specifies by the standard.
>>>>>     If you confirm that, I have joined within this mail a patch
>>>>> that you can apply.
>>>>>
>>>>>           
>>>> From what I recall, in many places MOV does use PASCAL strings
>>>> (length + non \0), while MP4 changed this to be C strings (\0
>>>> terminated), which is about the only significant difference
>>>> (sometimes I wondered if it's not just to crash MOV parsers).
>>>>
>>>> I don't have time, but you'll definitely want to check both QT and
>>>> MP4 specs for this.
>>>>
>>>>         
>>> ISO 14496-12 says null-terminated string, and QT says "counted
>>> string", so they are incompatible.  Of course, any size/termination is
>>> unnecessary since the string is the last element of the box and the
>>> box size is known.  Fools writing specs again...
>>>
>>>
>>>       
>> Fortunaletly, the box size is known otherwise any MP4/3GP/MOVdemuxer
>> will fail to parse a file. However, There is a problem if the MOV
>> backend of libavformat really want to be fully compliant with the
>> following standards ISO 14496-12 and MOV.
>> What I propose is to generate a correct 'hdlr' box depending on the
>> file format: name handler with PASCAL strings for MOV files and C
>> strings for 3GP/MP4 files.
>>     
>
> I never meant to imply we could ignore this difference. I was merely
> pointing at a bad design decision on both variants of the format.
>
>   
So, to illustrate my previous proposition, I have attached within this 
mail a patch.

Larbi Joubala

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_movenc.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090522/96fa149d/attachment.txt>



More information about the ffmpeg-devel mailing list