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

[Michael Niedermayer]

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


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


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


> 
> Since this is becoming a recurrent issue, I'll just forbid setting
> 'stsd' tag 

ok


> nor 'esds' objectype id to something specs does not define
> for 3gp/mp4. I'll apply the modifications soon.

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20080120/d5a6998f/attachment.pgp>