[FFmpeg-devel] [PATCH] attachments support in matroska demuxer
Uoti Urpala
uoti.urpala
Sun Jan 20 19:45:47 CET 2008
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? 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". Your reply doesn't seem to match
what you're replying to at all.
More information about the ffmpeg-devel
mailing list