[Ffmpeg-devel] Naming conventions

Aurelien Jacobs aurel
Tue Mar 6 00:31:09 CET 2007

On Mon, 05 Mar 2007 16:16:16 +0100
Panagiotis Issaris <takis.issaris at uhasselt.be> wrote:

> I think all agree that all public API functions should be prefixed with
> at least "av" and possibly "av_".


> Personally, I see various possibilities for structuring function names.
> The names could in some way include:
> * The name of the library: So, a prefix such as avc, avu and avf. It has
> the disadvantage that if functions are migrated to another library,
> they'll have to be renamed and thus cause ABI breakage. Libavcodec in
> some way seems to use this convention: avcodec_thread_init,
> avcodec_version, ... Libavformat and libavutil do not.

I don't really like avc, avu and avf. They could be confusing
(avc ? you mean mpeg4 avc, aka h264 ? and avf ? do you mean
libavformat or libavfilter ?)
avcodec_ or simply av_ both have pros and cons. I have no strong
opinion on which one to choose. Maybe a slight preference for av_
because I think next point (the type "it works on") should be clear
enough to guess in which lib a function is defined.

> * The name of the type "it works on". Libavformat uses this for some of
> its functions: av_parser_init, av_parser_parse, av_parser_change,
> av_bitstream_filter_init, avpicture_alloc, avpicture_free, ...

But I would prefer avpicture_* to be renamed to av_picture_*.

> * And of course the actual description of what the function does, the
> action.

Of course.

> How should these possibly included parts be ordered? The previously
> mentioned functionnames used the "type_action" order, but there also
> appear functions which do not use this order:
> av_init_packet, av_new_packet, av_get_packet, av_dup_packet,
> av_free_packet, ...
> _Personally_, I prefer the "type_action" type of names, and having all
> of them prefixed with some FFmpeg specific part, so that the chance of
> namecollisions is greatly reduced.

Same preference for me.

As already stated by Mans, I think we should be careful about such an
invasive API change. It would be a good thing but need to be done very
cleanly and libav* users should only need to modify there software once.
And they should be provided with a timeline stating when they can
begin the transition, what need to be changed, and when the old API
will be finally removed.

IMO, the first thing to do before any change is to write a clear naming
policy document and enforce it for any new function added to the public


More information about the ffmpeg-devel mailing list