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

[Michael Niedermayer]

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
the "avc FILE FORMAT" spec mandates "avc1", other file format derivates
of the iso format mandate differnt ones

switching them is like switching between -f mp4 -f 3gp


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

This statement just doesnt make any sense, stsd name is not a codec identifer
in .mp4
its value is mandated by the specific derivative of the mp4 spec
the spec specifying how to store h264 mandates avc1 it seems

A spec mandating something else will almost certainly also require other
chanegs like differnt NAL unit packing ...


> (stsd and object
> type id) should be enforced.

you keep saying this but its not clear what you mean
stsd is mandated by a spec setting that to codec_tag generates an invalid
file. object id has many values for the same codec for example mpeg2, the
muxer does not know the correct value


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

a patch is welcome ...

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20080122/286f4e3f/attachment.pgp>