[FFmpeg-devel] [PATCH 2/2] lavf: Add function for accessing Matroska Codec <-> CodecID table

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed May 30 22:10:33 CEST 2012

On Wed, May 30, 2012 at 03:52:52PM -0400, Derek Buitenhuis wrote:
> On 30/05/2012 3:44 PM, Reimar Döffinger wrote:
> > On Wed, May 30, 2012 at 02:53:00PM -0400, Derek Buitenhuis wrote:
> >> On 30/05/2012 2:47 PM, Reimar Döffinger wrote:
> >>> You didn't say for what purpose/why that would be useful.
> >>
> >> To enable users to use other demuxers than lavf (such as haali).
> >>
> >> It is currently not possible to do this without this table.
> > 
> > I don't really understand that. Or rather I have a suspicion,
> > which makes this a bit of a problematic approach, see below.
> What's not to understand? 
> >> For a similar case, see:
> >>
> >> http://ffmpeg.org/doxygen/trunk/group__riff__fourcc.html
> > 
> > The reason for that is that almost every format has a AVI fourcc,
> > thus it is suitable as a universal identifier to players like
> > MPlayer that don't want to rely on CODEC_IDs, particularly since
> > FFmpeg doesn't have one for each codec that exits.
> > However that only works of course if all demuxers translate to
> > a fourcc. That is not unreasonable, since all that want to work
> > with DirectShow or at least VfW have to I think.
> > The case where you need the mkv values seems to be the case where
> > the demuxers just throw out container-specific identifiers.
> > For that case I don't think this approach of one function returning
> > one array is reasonable, because the only logical conclusion would be
> > to have one such function for every single container that exists.
> > So there should a more efficient API then, if it's no longer about
> > supporting conversion from _one single_ common standard.
> Nice writeup, but entirely wrong. Considering I'm the person who
> got Anton to implement those functions in the first place, I'm
> pretty sure I'm the one who is right here. :) They exist solely
> to allow non-lavf demuxer to use lavc.

MPlayer used the AVI fields a long time before those functions existed,
and it used them the way I described. I admit I don't know how they
came to be or what whoever involved thought (and just assumed it was
related to what I needed it for), but if it was the way
you say I think it was a really silly idea already then, basically
the same thing as instead of having a av_find_input_format function
we had av_get_avi_format and a av_get_asf_format and a.... function.

More information about the ffmpeg-devel mailing list