[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Sun Jan 20 16:26:36 CET 2008
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
> 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
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
it causes an unimaginable mess, the whole design breaks down due to this
codec_tag is intended to identify the codec in a container specific
way while codec_id would be container independant
we have code which lists codec_tag-codec_id pairs for each (de)muxer
are you suggesting we should duplicate all that now for AVStream.type ?
If the existing codec_tag system is not flexible enough improve it, dont
write a new system pretending the existing one didnt exist.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel