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

[Michael Niedermayer]

On Sun, Jan 20, 2008 at 04:45:37PM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Sun, Jan 20, 2008 at 01:40:00PM +0000, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
> >>
> >>> 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.
> >> Still after years of working on FFmpeg, I have yet to figure out the
> >> purpose of codec_tag.  In my own apps using lav*, I have never read
> >> nor set it, and everything has always worked just fine without it.
> > 
> > try to play a avi with XVIX or UMP4 fourcc or some really old divx or
> > xvid
> > anyway, codec_tag is not only there to workaround bugs during decodig but
> > also to allow to preserve the container specific codec identifer
> > during foobar->foobar stream copy. And to allow preserving the 
> > container specific codec identifer even between containers if both support
> > the codec identifer. But if the target doesnt then select a correct identifer
> > for it and the codec_id.
> > 
> > you arent doing any transcoding IIRC ...
> > 
> > 
> >> I would certainly not consider using codec_tag a proper substitute for
> >> a MIME type field.  There of course the issue of MIME types not having
> >> complete coverage, but that's beside the point.
> > 
> > You misunderstand me i think, iam not objecting to a mime type field. Iam
> > objecting to people not setting codec_tag and instead introduce new fields
> > to do the very same.
> > If matroska did set codec_tag then matroskas various codec identifers could
> > often be preserved during stream copy and the same is true for attachments.
> > With a seperate way to identify them it will need seperate (duplicated) code
> > to handle.
> > 
> 
> If I understand well, do we need CODEC_TYPE_ATTACHMENT at all ? Would
> not be CODEC_TYPE_DATA sufficient ?

ive thought the same when i saw it, but iam unsure ...
ATTACHMENT is more of the single file in extradata kind, DATA is more a
continuous stream with timestamps ...
just my feeling ...

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

Democracy is the form of government in which you can choose your dictator
-------------- 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/f8ec33ee/attachment.pgp>