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

[Michael Niedermayer]

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!


> 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


> 
> >> 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.

yes, thats the way it should be, codec_tag is just the identifer stored in
the file, if the files has a wrong identifer codec_tag is wrong as well.
One could add a special case and export another fake codec_tag but i dont
see much sense in that in this case ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080121/4f99d456/attachment.pgp>