Analysis of compilation options of ffmpeg

Students who are familiar with ffmpeg know that when compiling ffmpeg, you can "customize" some modules, only enable the required modules, and do not enable redundant modules. For example, if we need a video encoding library, it may be enough to only enable x264, use this sentence: –enable-libx264. If you need to parse the RTSP protocol, then only enable the rtsp module, use this sentence: –enable-demuxer=RTSP .In this way, our compilation speed can be improved, and secondly, the compiled library or executable file will not be very large.

Presumably everyone will feel amazing when they first encounter it. Here I will briefly introduce the mystery.

ffmpeg provides a compilation configuration script, FFmpeg configure script, which is the configure file. The configure code looks a bit complicated, and there is no need to go into it and study it. Roughly speaking, this file accepts a series of input configuration parameters and outputs a makefile, a configuration file, and a config.h header file. Among them, in config.h, several macro definitions will be generated according to our input parameters. For example, if the input parameter has –enable-demuxer=RTSP, a macro of CONFIG_RTSP_DEMUXER will be generated.

Open config.h, you can find the following code:

#define CONFIG_RTSP_DEMUXER 1

It can be guessed that the RTSP demuxer related code is naturally included in the Makefile. In this way, when compiling, the RTSP demux related code will be compiled into it.

When we call ffmpeg, first we need to call the function:

av_register_all();

Looking at the implementation in this function, you can see that several macro functions are called multiple times to register muxer\demuxer:

    /* (de)muxers */
    REGISTER_MUXER   (A64,              a64);
    REGISTER_DEMUXER (AA,               aa);
    REGISTER_DEMUXER (AAC,              aac);
    REGISTER_MUXDEMUX(AC3,              ac3);
    REGISTER_DEMUXER (ACM,              acm);
    REGISTER_DEMUXER (ACT,              act);
    REGISTER_DEMUXER (ADF,              adf);
    REGISTER_DEMUXER (ADP,              adp);
    REGISTER_DEMUXER (ADS,              ads);
    REGISTER_MUXER   (ADTS,             adts);
    REGISTER_MUXDEMUX(ADX,              adx);
    REGISTER_DEMUXER (AEA,              aea);
    REGISTER_DEMUXER (AFC,              afc);
    REGISTER_MUXDEMUX(AIFF,             aiff);
    REGISTER_DEMUXER (AIX,              aix);
    ...

On the surface, various protocols are registered. How is it implemented internally? Let's take a closer look.
Look at the definitions of these macro functions:

#define REGISTER_MUXER(X, x)                                            \
    {                                                                   \
        extern AVOutputFormat ff_##x##_muxer;                           \
        if (CONFIG_##X##_MUXER)                                         \
            av_register_output_format(&ff_##x##_muxer);                 \
    }

#define REGISTER_DEMUXER(X, x)                                          \
    {                                                                   \
        extern AVInputFormat ff_##x##_demuxer;                          \
        if (CONFIG_##X##_DEMUXER)                                       \
            av_register_input_format(&ff_##x##_demuxer);                \
    }

#define REGISTER_MUXDEMUX(X, x) REGISTER_MUXER(X, x); REGISTER_DEMUXER(X, x)

Let's take the registration of AAC as an example. We can see that these three macro functions all receive two parameters, AAC and aac, and the third macro function actually executes the first two macro functions once respectively.

The implementation of the first two macro functions is similar. First, declare the ff_aac_muxer\ff_aac_demuxer variable, these two variables will eventually be defined in the file corresponding to aac (but whether to compile these files depends on whether AAC is enabled). Second Then according to the definition of CONFIG_AAC_MUXER\CONFIG_AAC_DEMUXER, decide whether to call av_register_output_format\av_register_input_format.

If we enable AAC in configure, we should see the two macros CONFIG_AAC_MUXER\CONFIG_AAC_DEMUXER have a value of 1 in config.h, so that av_register_output_format\av_register_input_format will eventually be executed. The functions of these two functions are very similar, probably the function , is to place ff_aac_muxer\ff_aac_demuxer into a format list respectively.

The two linked lists are defined as follows:

/**
 * @file
 * Format register and lookup
 */
/** head of registered input format linked list */
static AVInputFormat *first_iformat = NULL;
/** head of registered output format linked list */
static AVOutputFormat *first_oformat = NULL;

In the last blog, I mentioned that when ffmpeg probes, all demuxers will be traversed, probed separately and selected according to their scores. The traversal of demuxers here is actually to traverse the AVInputFormat list.

// 遍历链表
while ((fmt1 = av_iformat_next(fmt1))) {
    ...
}

And av_iformat_next, as the name suggests, is to take the next format of the current format.

And if AAC is not enabled in configure, then ff_aac_muxer\ff_aac_demuxer will not be defined or added to the linked list in the end, so when probe, there will be no AAC participation.

Analysis of compilation options of ffmpeg

Guess you like