[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:15 +0000, M?ns Rullg?rd wrote:
>> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> > On Sun, 2008-01-20 at 16:05 +0000, M?ns Rullg?rd wrote:
>> >> Based on what you say, I have to consider the entire concept of
>> >> codec_tag flawed.  Since the decoder does not in general (and
>> >> certainly should not) know what container the data came in, it cannot
>> >> know how to interpret the value of codec_tag.  Similarly a muxer,
>> >> whether transcoding or copying, does not know the source of the
>> >> codec_tag value, and thus cannot interpret it one way or another.
>> >
>> > 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.

You guys really are deep in the dark...

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