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

[Måns Rullgård]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Sun, 2008-01-20 at 18:38 +0000, M?ns Rullg?rd wrote:
>> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> 
>> > On Sun, 2008-01-20 at 18:15 +0000, M?ns Rullg?rd wrote:
>> >> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> >> > You cannot always interpret the value unless you know which
>> >> > container it is from. However you CAN know the container and
>> >> > in that case it's better than nothing.
>> >> >
>> >> > Decoders can only map container-specific codec tags to
>> >> > FFmpeg-specific codec id values if the codec in question is
>> >> > known to FFmpeg (and not always even in that case). Demuxers
>> >> > in libavformat can still be useful even if FFmpeg does not
>> >> > recognize the specific codec, but that requires exporting the
>> >> > container-specific codec type information somehow.
>> >> 
>> >> I consider this a design flaw in FFmpeg.  I'm afraid it's well
>> >> beyond correcting now, though.
>> >
>> > What exactly is a design flaw? That it exports information that
>> > allows using it with codecs which FFmpeg itself does not
>> > recognize? And you'd want to "correct" that so it's impossible to
>> > identify codecs from FFmpeg demuxer output unless it's one of the
>> > codecs known by FFmpeg? That seems absurd but I don't see what
>> > else you could mean...
>> 
>> No, I mean the opposite.  It is impossible for a demuxer to identify
>> an unsupported codec in a container-independent fashion.
>
> Where did you get "container-independent" from?

In all other matters, Michael insists that everything in FFmpeg be
independent of any particular implementation.  I fail to see what's so
special about the codec identifier used by the container.

> I specifically talked about "exporting the container-specific codec
> type information". And Michael said in an earlier message "codec_tag
> is intended to identify the codec in a container specific way".

Well, it's not doing a very good job of that.  Being an 'unsigned
int', it has no chance of representing e.g. matroska codec
identifiers.  To be generic, it would have to be a pointer/size pair
like extradata.

Some people have really close horizons.

-- 
M?ns Rullg?rd
mans at mansr.com