[FFmpeg-devel] Reworking the codec lookup system

[Nicolas George]

Le duodi 22 prairial, an CCXV, Baptiste Coudurier a ?crit?:
> I don't see the need for family name, IMHO codec_id is sufficient and 
> unique, and should be used to identify what a decoder/encoder can 
> decode/encode, but I can see the ambiguity between some variants of 
> MPEG-4 (part 2), which really caused that mess, IMHO codec_tag + 
> codec_id should be sufficient to identify.

Alas, it does not work that way. CodecID is neither an identifier of the
codec, nor of the codec family. For example, there are both CODEC_ID_MPEG4
and CODEC_ID_XVID, although they are in the same codec family. On the other
hand, there is only CODEC_ID_VORBIS for the vorbis and libvorbis encoders.

Something needs to be cleaned up deeply there.

> Native encoders/decoders are always preferred.

As far as I understand the code, the real answer is that the first matching
encoder is always preferred, meaning that the actual result depends on the
order of the codec in the global table. I think that an explicit priority
flag would be somewhat more robust.

>						 I don't really see the 
> need of having another decoder/encoder if ffmpeg already has one

In the case of decoders, the need is quite small. But in the case of
encoders, there are so much variables that lavc can not always be the best
one available for all cases.

> in favor of improving the native one

Of course, improving the native one is a good thing. But at the same time,
being able to use a better third party encoder is also a good thing.

> Well, I don't really see why you want to get rid of that.

See above: CodecID is not clear: it sometimes identifies what I called a
codec, and sometimes identifies what I called a codec family. Therefore,
rework is needed.

Obviously, since there already is a codec name that is unique, CodecID must
somehow become what I called codec family. While we are at it, I believe it
would be a good thing to get rid of one global table that needs to be kept
in sync.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070610/f427fd82/attachment.pgp>