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

Baptiste Coudurier baptiste.coudurier
Mon Jan 28 10:49:13 CET 2008


Michael Niedermayer wrote:
> On Tue, Jan 22, 2008 at 01:48:07AM +0100, Baptiste Coudurier wrote:
>> 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 ?
> you identify the specification with the stsd, that is 14496-15 for avc1
> 14496-15 only allows h.264 so no need for a codec identifer
>>> 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
> "mp4a" being an example for some audio codecs in .mp4
> its not == "avc1" and its written in a different spec
>> , 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."
> yes
>>> switching them is like switching between -f mp4 -f 3gp
>> 3gp mandates the use of ISO 14496-15 for wrapping h.264.
> yes
> "avc1" always identifies ISO 14496-15 it thus identifies the ISO format
> derivative used NOT the codec, it just happens to, by coincidence identify
> the codec here too.
> codec_tag is NOT a file format derivative identifer
> [...]
>> Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ?
> Huh, why should it enforce that?
>> I don't think so.
>> Therefore 'stsd' tag name CAN BE a codec identifier in .mp4.
> stsd can in some cases be used to identfy the codec, you can also
> in some cases use the filename or extension to identify the codec
> but the value in stsd is NOT a generic codec identifer, that is if you 
> just copy it per stream copy while ignoring the differences in the spec
> it refers too (like esds) you will have a broken file.
> It identifies the spec and format used to store things not directly
> the codec.
>> 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.
> well i dont have that amendment so i cant comment on what exactly these
> other values mean

Just remembered of SMPTE RP2025:

"This document was initiated by C24 in response to the need to store
VC-1 coded bitstreams in file formats
derived from the ISO Base Media File Format such as the MP4 file format
and the 3GPP file format."
"The purpose of this specification is to define the necessary structures
for the integration of VC-1 coded
bitstreams in a file format that is compliant with the ISO Base Media
File Format. Examples of file formats that
are derived from the ISO Base Media File Format include the MP4 file
format and the 3GPP file format."

"6 VC1SampleEntry definition
The box type of the VC1SampleEntry Box shall be 'vc-1'."

Now we got 2 differents codecs using stsd tag as a codec identifier.

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