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

[Baptiste Coudurier]

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.

>> 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 (stsd and object
type id) should be enforced.

Now considering stream copy from mp4 to mov, it is not safe to put
objectype id in 'stsd', so codec_tag must be ignored and recomputed to
create compliant files, and I don't feel like breaking stream copy right
now.

I guess the FIXME in libavformat/utils.c concerning codec tags should be
fixed before any action.

[...]

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