[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Michael Niedermayer
michaelni
Tue Jan 22 03:11:41 CET 2008
On Tue, Jan 22, 2008 at 01:48:07AM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > 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
>
> This does not make any sense.
> "this standard defines a storage format for video streams
> compressed using AVC"
>
> Furthermore, you can check all mp4 with h.264, none that I have have an
> 'esds' atom, therefore no object type id, so how to indentify h.264 if
> not checking 'stsd' tag ?
you identify the specification with the stsd, that is 14496-15 for avc1
14496-15 only allows h.264 so no need for a codec identifer
>
> > the "avc FILE FORMAT" spec mandates "avc1", other file format derivates
> > of the iso format mandate differnt ones
>
> Is that what you call not unclear ?
> Besides, I have no knowledge of any other derivative mandating
> differente one
"mp4a" being an example for some audio codecs in .mp4
its not == "avc1" and its written in a different spec
> , also:
>
> "This specification is not a standalone specification; it only specifies
> how AVC content shall be stored in an ISO Media File format compliant
> format. Therefore, this specification must always be used in the context
> of a concrete specification, such as the MP4 file format, derived from
> the ISO Media File format."
yes
>
> > switching them is like switching between -f mp4 -f 3gp
>
> 3gp mandates the use of ISO 14496-15 for wrapping h.264.
yes
"avc1" always identifies ISO 14496-15 it thus identifies the ISO format
derivative used NOT the codec, it just happens to, by coincidence identify
the codec here too.
codec_tag is NOT a file format derivative identifer
[...]
>
> Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ?
Huh, why should it enforce that?
> I don't think so.
>
> Therefore 'stsd' tag name CAN BE a codec identifier in .mp4.
stsd can in some cases be used to identfy the codec, you can also
in some cases use the filename or extension to identify the codec
but the value in stsd is NOT a generic codec identifer, that is if you
just copy it per stream copy while ignoring the differences in the spec
it refers too (like esds) you will have a broken file.
It identifies the spec and format used to store things not directly
the codec.
> It is stated that ISO 14496-15 defines how to wrap h.264 in any iso
> media derivative.
> According to svc amendment you can now even have 'avc1', 'avc2', 'svc1'
> as 'stsd' tag.
well i dont have that amendment so i cant comment on what exactly these
other values mean
[...]
>
> > 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
> >
>
> Object types for mpeg-2 corresponds to all mpeg-2 profiles.
> Muxer has to parse mpeg2 packet to fetch profile, and put correct object
> type id (not that hard imho), it should also be done when wrapping aac I
> must say.
It should be done by the AVParser not duplicated in several muxers
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct awnser.
-------------- 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/c3c484a3/attachment.pgp>
More information about the ffmpeg-devel
mailing list