标签：获取   arm   不为   不同的   需求   维护   tps   pts   分享   

如果有定制ffmpeg滤波器的需求，有两个结构体是必须要了解的：AVFilter、AVFilterPad，所定制的滤波器主要就是通过填充这两个结构体来实现的。我们下面将详细解析这两个结构体，并通过对滤波器的初始化流程以及滤波流程进行分析，进一步加深对ffmpeg滤波框架的了解。

AVFilter

AVFilter就是一个滤波器的主体，其结构体定义如下：

typedef struct AVFilter {
    const char *name;
    const char *description;
    const AVFilterPad *inputs;
    const AVFilterPad *outputs;
    const AVClass *priv_class;
    int flags;
    int (*preinit)(AVFilterContext *ctx);
    int (*init)(AVFilterContext *ctx);
    int (*init_dict)(AVFilterContext *ctx, AVDictionary **options);
    void (*uninit)(AVFilterContext *ctx);
    int (*query_formats)(AVFilterContext *);
    int priv_size;      
    int flags_internal; 
    struct AVFilter *next;
    int (*process_command)(AVFilterContext *, const char *cmd, const char *arg, char *res, int res_len, int flags);
    int (*init_opaque)(AVFilterContext *ctx, void *opaque);
    int (*activate)(AVFilterContext *ctx);
} AVFilter;

其各个成员变量有如下含义：

AVFilterPad

AVFilterPad是滤波器的出口或者入口，其结构定义如下：

struct AVFilterPad {
    const char *name;
    enum AVMediaType type;
    AVFrame *(*get_video_buffer)(AVFilterLink *link, int w, int h);
    AVFrame *(*get_audio_buffer)(AVFilterLink *link, int nb_samples);
    int (*filter_frame)(AVFilterLink *link, AVFrame *frame);
    int (*poll_frame)(AVFilterLink *link);
    int (*request_frame)(AVFilterLink *link);
    int (*config_props)(AVFilterLink *link);
    int needs_fifo;
    int needs_writable;
};

各成员变量具有如下含义：

初始化流程

首先是avfilter_graph_create_filter，即创建滤波器实例。如前面所说，这个函数会在最开头调用滤波器的preinit函数，然后创建滤波器实例并做一些简单的初始化，解析输入的字符串，最后调用滤波器的init函数。

在构建好一整个AVFilterGraph后，就可以调用avfilter_graph_config来做graph最后的配置。

其中graph_insert_fifos中就会对设定了needs_fifo=1的input pad所在的link插入名为fifo的滤波器。

            if (!link->dstpad->needs_fifo)
                continue;

            fifo = f->inputs[j]->type == AVMEDIA_TYPE_VIDEO ?
                   avfilter_get_by_name("fifo") :
                   avfilter_get_by_name("afifo");

            snprintf(name, sizeof(name), "auto_fifo_%d", fifo_count++);

            ret = avfilter_graph_create_filter(&fifo_ctx, fifo, name, NULL,
                                               NULL, graph);

            ret = avfilter_insert_filter(link, fifo_ctx, 0, 0);

graph_config_formats中如前一篇文章所说，就是对整个graph中滤波格式进行协商，协商过后可以确定所有link上的格式。

graph_config_links主要目的就是调用pad中的config_props，那么config_props就能根据前面协商得到的link格式做进一步的操作。

滤波流程

一般来说，用户会按照如下方式调用滤波API来进行滤波处理：

    ret = av_buffersrc_add_frame(in_filter, pFrame);

    while((ret = av_buffersink_get_frame(out_filter, pFrame))>=0){
        //TODO
    }

向graph输入帧

滤波的流程都是首先调用av_buffersrc_add_frame，从向buffersrc输入帧开始的

可以看到调用了buffersrc的request_frame函数，该函数最后用ff_filter_frame向outlink输出帧。、

从graph提取帧

然后调用av_buffersink_get_frame，尝试获得buffersink输出的帧，如果返回值大于0则表明得到了一帧，正常情况下如果无法获得帧通常会返回EAGAIN，这表明要求用户向buffersrc输入更多的帧。

av_buffersink_get_frame会向下调用到get_frame_internal，该函数主要作用就是调用滤波器进行滤波，并返回滤波完成的帧。函数实现如下：

static int get_frame_internal(AVFilterContext *ctx, AVFrame *frame, int flags, int samples)
{
    BufferSinkContext *buf = ctx->priv;
    AVFilterLink *inlink = ctx->inputs[0];
    int status, ret;
    AVFrame *cur_frame;
    int64_t pts;

    if (buf->peeked_frame)
        return return_or_keep_frame(buf, frame, buf->peeked_frame, flags);

    while (1) {
        ret = samples ? ff_inlink_consume_samples(inlink, samples, samples, &cur_frame) :
                        ff_inlink_consume_frame(inlink, &cur_frame);
        if (ret < 0) {
            return ret;
        } else if (ret) {
            /* TODO return the frame instead of copying it */
            return return_or_keep_frame(buf, frame, cur_frame, flags);
        } else if (ff_inlink_acknowledge_status(inlink, &status, &pts)) {
            return status;
        } else if ((flags & AV_BUFFERSINK_FLAG_NO_REQUEST)) {
            return AVERROR(EAGAIN);
        } else if (inlink->frame_wanted_out) {
            ret = ff_filter_graph_run_once(ctx->graph);
            if (ret < 0)
                return ret;
        } else {
            ff_inlink_request_frame(inlink);
        }
    }
}

该函数有如下实现逻辑：

1. 调用ff_inlink_consume_frame，看是否可以获得滤波完成的帧，如果得到了滤波后的帧，则调用return_or_keep_frame进行返回。
2. 调用ff_inlink_acknowledge_status，查看滤波过程中是否出了差错，或者是否到了EOF，是则返回错误。
3. frame_wanted_out用于表明当前滤波器是否已经获得了前一个滤波器输出的一帧，等于1则表示未获得，那么需要调用ff_filter_graph_run_once；等于0则表示已获得一帧，或者是第一次调用该函数。

跳出get_frame_internal里面的while循环只有下面几种情况：

1. ff_inlink_consume_frame返回值不为0，表明可以返回滤波后的帧。
2. ff_inlink_acknowledge_status返回值不为0，表明滤波器运行过程中出错。
3. ff_filter_graph_run_once返回值小于0，一般情况下为EAGAIN，表明滤波器需要输入更多的帧作为原料。

如果是第一次调用av_buffersink_get_frame，当进入该函数时，正常情况下会按照如下步骤执行：

1. 由于是第一次调用，因此frame_wanted_out为0，那么第一次循环会去执行ff_inlink_request_frame，这个函数会把frame_wanted_out设置为1，表明当前滤波器未获得前一个滤波器输出的帧。
2. 然后下一次循环时由于frame_wanted_out为1，会去调用ff_filter_graph_run_once。
3. 通常来说，经过几次循环调用ff_filter_graph_run_once后，会得到滤波后的帧，此时ff_inlink_consume_frame会返回1，因此就能调用return_or_keep_frame来向用户返回滤波后的帧了。
4. 如果需要输入更多的帧才能继续进行滤波，那么会从ff_filter_graph_run_once返回EAGAIN。

激活滤波器

我们前面提到的ff_filter_graph_run_once就是查找已经就绪（ready）的滤波器实例，并对该滤波器进行激活。所得到的滤波器实例会满足两个条件：

1. 滤波器的ready值（优先级）更高的会被选上
2. 在此基础上，因为查找顺序是按照用户调用avfilter_graph_create_filter的顺序，因此最先创建的滤波器实例会被选中。

AVFilterContext *avfilter_graph_alloc_filter(AVFilterGraph *graph,
                                             const AVFilter *filter,
                                             const char *name)
{
    s = ff_filter_alloc(filter, name);
    graph->filters[graph->nb_filters++] = s;
}

int ff_filter_graph_run_once(AVFilterGraph *graph)
{
    filter = graph->filters[0];
    for (i = 1; i < graph->nb_filters; i++)
        if (graph->filters[i]->ready > filter->ready)
            filter = graph->filters[i];
    if (!filter->ready)
        return AVERROR(EAGAIN);
    return ff_filter_activate(filter);
}

选出优先级最高的滤波器实例后，首先把该滤波器就绪状态清零，然后开始执行激活操作：如果该滤波器实现了activate函数，则调用该函数，否则调用默认的激活函数ff_filter_activate_default。

int ff_filter_activate(AVFilterContext *filter)
{
    filter->ready = 0;
    ret = filter->filter->activate ? filter->filter->activate(filter) :
          ff_filter_activate_default(filter);
}

如果调用的是默认的激活函数，则会按照以下优先级进行激活处理：

static int ff_filter_activate_default(AVFilterContext *filter)
{
    unsigned i;

    for (i = 0; i < filter->nb_inputs; i++) {
        if (samples_ready(filter->inputs[i], filter->inputs[i]->min_samples)) {
            return ff_filter_frame_to_filter(filter->inputs[i]);
        }
    }
    for (i = 0; i < filter->nb_inputs; i++) {
        if (filter->inputs[i]->status_in && !filter->inputs[i]->status_out) {
            av_assert1(!ff_framequeue_queued_frames(&filter->inputs[i]->fifo));
            return forward_status_change(filter, filter->inputs[i]);
        }
    }
    for (i = 0; i < filter->nb_outputs; i++) {
        if (filter->outputs[i]->frame_wanted_out &&
            !filter->outputs[i]->frame_blocked_in) {
            return ff_request_frame_to_filter(filter->outputs[i]);
        }
    }
    return FFERROR_NOT_READY;
}

可以发现共有三种激活处理方式，分别为：

• 从上往下传递滤波完成的帧。
• 从上往下传递错误代码。
• 从下往上传递帧的请求。

前面的方式优先级更高。下面我们会对这三种方式进行较为详细的分析

ff_filter_frame_to_filter

触发条件是：当前滤波器实例的input link上的samples_ready。这samples_ready表明了前面的滤波器实例已经执行ff_filter_frame向当前滤波器实例的input link输出了帧。

有了上述条件，那么为了完成当前滤波器实例的滤波操作，接下来会执行：

1. 从input link上提取出帧。
2. 调用当前滤波器的filter_frame函数来执行滤波操作。
3. 一般来说滤波处理完成过后也会调用ff_filter_frame来把滤波完成的帧输出到output link。
4. ff_filter_frame接下来会把下一个滤波器实例设为就绪状态。
5. 如果在执行filter_frame时出错，没能完成滤波处理，则会把错误代码写入input link的status_out，表明该link无法顺利输出frame到当前filter。
6. 如果执行filter_frame成功，考虑到前一个滤波器实例可能输出了不止一帧，因此再次把当前滤波器实例设为就绪状态，如果前一个滤波器确实输出了多个帧，这部操作会使得这多个帧都被当前滤波器实例滤波完成后才会执行下一个滤波器实例的滤波处理。

foward_status_change

触发条件是：当前滤波器实例的input link上有status_in && !status_out。status_in不为0表明调用前一个滤波器实例的request_frame时出现了错误，status_in的值就是错误代码，我们需要向后面的滤波器实例传播这个错误代码。

forward_status_change是传播错误代码的入口，传播错误代码的很大一步分的实现都在ff_request_frame函数内。基于上述条件，即调用前一个滤波器实例的request_frame时出现了错误。

1. forward_status_change会调用当前滤波器实例的request_frame来传输错误代码，request_frame一般内部都会调用到ff_request_farme函数。
2. 错误代码status_in会导致ff_request_frame走入错误处理分支。
3. 把status_out的值设置为status_in。
4. 那么返回值也会是该错误代码，这用于表示当前request_frame也出现了错误。
5. 因此在返回的时候会把下一个滤波器实例的input link（即当前滤波器实例的output link）上的status_in设置为错误代码。
6. 把frame_wanted_out设置为0用于表示当前滤波器实例的错误处理已完成，避免再次调用当前滤波器实例的request_frame函数做重复的错误处理。
7. 把下一个滤波器实例设置为就绪状态。

ff_request_frame_to_filter

触发条件是：当前滤波器的output link上有frame_wanted_out以及!frame_blocked_in。其中frame_blocked_in用于防止重复对同一个link执行request frame操作，重要的是frame_wanted_out。我们前面也说过，如果一个link上的frame_wanted_out=1，表明该link的dst要求src输出帧，具体一点，就是这会导致执行src的request_frame函数。那么这里的output link上的frame_wanted_out=1就会导致：

1. 当前的滤波器实例的request_frame被执行。
2. request_frame内一般会调用ff_request_frame函数。一般情况下，该函数会把input link的frame_wanted_out设置为1。
3. 然后把前一个滤波器实例设为就绪状态。
4. 如果request_frame出错的话，就是request_frame没能处理完成，则会把错误代码写入outlink的status_in，表明该link无法顺序求得当前滤波器实例的帧。

注意：上面所描述的三种处理方式只是比较常见方式。在实际应用中，有些滤波器在filter_frame内调用ff_request_frame，也有些滤波器在request_frame内调用ff_filter_frame的，而且实现了activate函数的滤波器并不会执行上述流程，如果全部都列出来就过于冗余了，具体问题具体分析是很重要的。

此外，我们可以看到在执行ff_filter_frame时会把ready值设置为300；在执行ff_request_frame时会吧ready值设置为100；在保存错误代码时会把ready值设置为200。这表明了优先进行滤波处理，其次是错误处理，最后才是帧请求。

滤波的激活处理可以按照如下进行总结：

1. 优先执行滤波处理，如果前面的滤波器实例输出帧，当前的滤波器实例就可以执行滤波处理，并把滤波后得到的帧向后传递。
2. 如果在滤波时缺乏帧作为原料，则向前要求前面的滤波器实例输出帧，这个要求会一直往前发送，直到有滤波器实例可以输出帧。
3. 如果在滤波或者请求帧的过程中出错了，就把错误往后传递，典型的如EOF就是这种传递方式。

ffmpeg定制滤波器

标签：获取   arm   不为   不同的   需求   维护   tps   pts   分享   

原文地址：https://www.cnblogs.com/TaigaCon/p/10171464.html