[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Sun Jan 20 16:45:37 CET 2008
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:
>>> 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
>>>>> 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
> 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 ?
I think I would agree to set codec_tag to mime type if it is the way to
detect types of attachment in matroska, this is IMHO in line with the
API and the use of codec_tag.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel