Coding Style

Code formatting conventions

The code is written in K&R C style. That means the following:

    for (i = 0; i < filter->input_count; i++) {

    switch (link->init_state) {
    case AVLINK_INIT:
        av_log(filter, AV_LOG_INFO, "circular filter chain detected");
        return 0;

    const char *avfilter_configuration(void)

    if (!pic || !picref)
        goto fail;

There are the following guidelines regarding the indentation in files:

The presentation is one inspired by indent -i4 -kr -nut.

The main priority in Libav is simplicity and small code size in order to minimize the bug count.


Use the JavaDoc/Doxygen format (see examples below) so that code documentation can be generated automatically. All nontrivial functions should have a comment above them explaining what the function does, even if it is just one sentence. All structures and their member variables should be documented, too.

Avoid Qt-style and similar Doxygen syntax with ! in it, i.e. replace //! with /// and similar. Also @ syntax should be employed for markup commands, i.e. use @param and not \param.

 * @file
 * MPEG codec.
 * @author ...

 * Summary sentence.
 * more text ...
 * ...
typedef struct Foobar {
    int var1; /**< var1 description */
    int var2; ///< var2 description
    /** var3 description */
    int var3;
} Foobar;

 * Summary sentence.
 * more text ...
 * ...
 * @param my_parameter description of my_parameter
 * @return return value description
int myfunc(int my_parameter)

C language features

Libav is programmed in the ISO C90 language with a few additional features from ISO C99, namely:

These features are supported by all compilers we care about, so we will not accept patches to remove their use unless they absolutely do not impair clarity and performance.

All code must compile with recent versions of GCC and a number of other currently supported compilers. To ensure compatibility, please do not use additional C99 features or GCC extensions. Especially watch out for:

Naming conventions

All names should be composed with underscores (_), not CamelCase. For example, avfilter_get_video_buffer is an acceptable function name and AVFilterGetVideo is not. The only exception are structure names; they should always be CamelCase.

There are the following conventions for naming variables and functions:

Furthermore, name space reserved for the system should not be invaded. Identifiers ending in _t are reserved by POSIX. Also avoid names starting with or _ followed by an uppercase letter as they are reserved by the C standard. Names starting with _ are reserved at the file level and may not be used for externally visible symbols. If in doubt, just avoid names starting with _ altogether.

Miscellaneous conventions

Additional information

The following subpages provide additional information regarding the coding style used in Libav.

CategoryWIP CategoryHowTo