[FFmpeg-devel] Reworking the codec lookup system

[Baptiste Coudurier]

Hi

Nicolas George a ?crit :
> Hi.
> 
> [...]
> 
> Then, how do we do with ffmpeg? Here is my proposal:
> 
> - Each encoder or decoder structure has a codec name. The codec name is
>   globally unique (except that an encoder and a decoder can have the same).

That's the way it is done.

> - Each codec structure has a codec family name.

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.

> - Each codec structure has a priority value, to set the preference between
>   codecs belonging to the same codec family.

Native encoders/decoders are always preferred. I don't really see the 
need of having another decoder/encoder if ffmpeg already has one, and Im 
in favor of improving the native one, but it might be useful for 
benchmarking though that can be done easily with mplayer, so ...

> - Codec names are in lowercase. Codec family names are in uppercase.

Well I prefer lowercase, but matching can be done case insentively 
(ffmpeg -vcodec XviD should work), and that is more a bikeshed issue.

> - When looking for a codec by name, ffmpeg will first look for an exact
>   match on the codec name field. If there is none, it will look for a
>   case-insensitive match on the codec family name field and take the best
>   priority.

Yes it will match on codec name using 
avcodec_find_encoder/decoder_by_name, then fall back on native one, then 
fallback on first with matching codec_id (given by guess_format if used).

> - CodecIDs are no longer used.

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

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no