[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Baptiste Coudurier
baptiste.coudurier
Mon Jan 21 02:24:40 CET 2008
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,
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 ?
>> Now mp3on4 use same object type id
>> as aac, so in that case it won't work anyway.
>
> What wont work? Yes both mp3on4 and aac would have the same codec_tag but
> thats just what is stored in the file (and it violates the spec) the stsd
> of them doesnt differ either or?
It doesn't differ, what won't work is differentiating mp3on4 from aac
based on codec_tag, and therefore being able to identify codec based on
codec_tag.
>> I would agree to set codec_tag to 'esds' objecttype id if mp4 muxer is
>> modified to correctly handle it in case of stream copy,
>
> just change the muxer as well ...
>
>
>> and still where
>> is codec_tag supposed to be put in mp4 ? 'stsd' tag or objecttype id in
>> 'esds' ? We are creating 'isom' brand mp4.
>
> see the spec, stsd is mp4v/mp4a if not its not mp4
See my previous reply.
[...]
--
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