[FFmpeg-devel] [PATCH] attachments support in matroska demuxer

Baptiste Coudurier baptiste.coudurier
Tue Jan 22 01:48:07 CET 2008


Michael Niedermayer wrote:
> On Mon, Jan 21, 2008 at 11:58:50PM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
>>>>>> Hi
>>>>>>
>>>>>> Michael Niedermayer wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
>>>>>>>> Hello,
>>>>>>>> On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote:
>>>>>>>> [...]
>>>>>>>>>>> iam against some undocumented char *type
>>>>>>>>>>> please document precissely what it repressents and how it differs from
>>>>>>>>>>> codec_tag, stream_codec_tag and codec_id
>>>>>>>>>>> or even better get rid of it and use codec_tag or explain why the type
>>>>>>>>>>> here should be special cased relative to these funny codec id strings in
>>>>>>>>>>> matroska
>>>>>>>>>> Currently, *type stores the standard mime type of the attachment.
>>>>>>>>> so it idetifies what the attachment is ...
>>>>>>>>> thats what codec_tag does alraedy ...
>>>>>>>> Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag
>>>>>>>> certainly does not. E.g. for mp4 files all kind of audio has mp4a as
>>>>>>>> codec_tag and some other things like that.
>>>>>>> the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt
>>>>>>> agree with the API. And choose to set codec_tag to something else than what
>>>>>>> it is supposed to be
>>>>>> We already discussed this issue, it is unclear in mp4 if codec_tag is
>>>>>> 'stsd' tag or 'esds' objecttype id. 
>>>>> no it is not unclear
>>>>> let me quote from ISO/IEC 14496-12
>>>>> -----
>>>>> C.5 Storage of new media types
>>>>> There are two choices in the definition of how a new media type should be stored.
>>>>> First, if MPEG-4 systems constructs are desired or acceptable, then:
>>>>>            a) a new ObjectTypeIndication should be requested and used;
>>>>>            b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor;
>>>>>            c) the access unit format should be defined for this media.
>>>>> The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a
>>>>> sampleentry of type "mp4v".
>>>>> If the MPEG-4 systems layer is not suitable or otherwise not desired, then:
>>>>>            a) a new sampleentry four-character code should be requested and used;
>>>>>            b) any additional information needed by the decoder should be defined as boxes to be stored within
>>>>>               the sampleentry;
>>>>>            c) the file-format sample format should be defined for this media.
>>>>> Note that in the second case, the registration authority will also allocate an objecttypeindication for use in
>>>>> MPEG-4 systems.
>>>>> -----
>>>>> Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the
>>>>> codec identifer is somewhere else
>>>>>
>>>>> If its not a mp4 based container, stsd is used
>>>> Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd,
>>> Which spec says that?
>>> Please quote the specific part or provide a URL to that spec, id like to
>>> read it!
>> In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as
>> keyword, SVC amendment looks really similar.
>>
>> "To enable the best visibility of, and access to, those features, and to
>> enhance the opportunities for the interchange and interoperability of
>> media, this standard defines a storage format for video streams
>> compressed using AVC and using carrying within the MPEG-4 Systems
>> Framework (ISO/IEC 14496-1:2001 and its various amendments)."
>> "This specification defines a storage format based on, and compatible
>> with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which
>> is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG
>> 2000 file format (ISO/IEC 15444-3) among others.
>>
>> class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){
>> 	AVCConfigurationBox	config;
>> 	MPEG4ExtensionDescriptorsBox ();	// optional
>> }
>>
>> I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change.
>>
>> I see nowhere in the document the mention of 'mp4v', but document
>> mention the possible use of MPEG-4 Systems mechanisms (object type id)
>>
>> Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag.
> 
> If the only spec we have mandates avc1 then it is not variable
> If its not varible it cannot be changed by the user codec_tag or otherwise
> because otherwise files wouldnt be compliant
> 
> besides the thing is a file format spec identifer not a codec identifer

This does not make any sense.
"this standard defines a storage format for video streams
compressed using AVC"

Furthermore, you can check all mp4 with h.264, none that I have have an
'esds' atom, therefore no object type id, so how to indentify h.264 if
not checking 'stsd' tag ?

> the "avc FILE FORMAT" spec mandates "avc1", other file format derivates
> of the iso format mandate differnt ones

Is that what you call not unclear ?
Besides, I have no knowledge of any other derivative mandating
differente one, also:

"This specification is not a standalone specification; it only specifies
how AVC content shall be stored in an ISO Media File format compliant
format. Therefore, this specification must always be used in the context
of a concrete specification, such as the MP4 file format, derived from
the ISO Media File format."

> switching them is like switching between -f mp4 -f 3gp

3gp mandates the use of ISO 14496-15 for wrapping h.264.

>>>> so this just becomes untrue, that is if its .mp4 stsd can contain
>>>> something else than "mp4v/a/t/s". This is exactly what is unclear, and
>>>> maybe some other codecs allow that (thinking of jpeg2k).
>>>>
>>>> What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is
>>>> used to define the codec.
>>>>
>>>> Problem is what to do when user set codec_tag and use mp4 muxer ? We set
>>>> objecttype id or/and stsd tag ?
>>> objecttype id
>>>
>> But we loose the possibility to support other codecs not using 'mp4v' or
>> 'mp4a' as 'stsd' tags. Well, I really think mp4 tags
> 
> This statement just doesnt make any sense, stsd name is not a codec identifer
> in .mp4

What are you calling .mp4 exactly ? Files conforming to which
specifications, which documents ?

Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ?
I don't think so.

Therefore 'stsd' tag name CAN BE a codec identifier in .mp4.
It is stated that ISO 14496-15 defines how to wrap h.264 in any iso
media derivative.
According to svc amendment you can now even have 'avc1', 'avc2', 'svc1'
as 'stsd' tag.

> its value is mandated by the specific derivative of the mp4 spec

And ISO 14496-15 overrides it for h.264, and probably other codecs in
the future. I persist to say that since you at least have 2 possible
stsd tag value in mp4, stsd tag CAN BE a codec identifier.

> the spec specifying how to store h264 mandates avc1 it seems
>
> A spec mandating something else will almost certainly also require other
> chanegs like differnt NAL unit packing ...
> 
> 
>> (stsd and object
>> type id) should be enforced.
> 
> you keep saying this but its not clear what you mean
> stsd is mandated by a spec setting that to codec_tag generates an invalid
> file. object id has many values for the same codec for example mpeg2, the
> muxer does not know the correct value
> 

Object types for mpeg-2 corresponds to all mpeg-2 profiles.
Muxer has to parse mpeg2 packet to fetch profile, and put correct object
type id (not that hard imho), it should also be done when wrapping aac I
must say.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312




More information about the ffmpeg-devel mailing list