ffmpeg面向对象-rtsp拉流相关对象

1.AVFormatContext和FFFormatContext类。

1.1 概述

ffmpeg5.x以后，把AVFormatContext类进行了拆分，把用户需要看到的共性部分抽取为父类AVFormatContext类，把用户用不到/不需要知道的剩余部分变成了子类FFFormatContext类——隐藏用户不用关心的内容。

5.x以后，实例化流对象FFFormatContext，然后返回给用户可见的基类AVFormatContext指针。

其他的函数调用就是以FFFormatContext这个类为中心，实质是实例化这个类（初始化，构造函数）、调用这个类的方法，最后销毁这个类对象。
比如拉流的必经流程:
avformat_open_input
av_read_frame
avformat_close_input

很明显的对应构造，调用方法和析构函数。

1.2 构造函数

rtsp拉流第一步都是avformat_open_input，同时也是流对象FFFormatContext的构造函数。

AVFormatContext *fmt_ctx = NULL;
result = avformat_open_input(&fmt_ctx, input_filename, NULL, NULL);

其中fmt_ctx 如何分配内存的？如下

int avformat_open_input(AVFormatContext **ps, const char *filename,
                        const AVInputFormat *fmt, AVDictionary **options)
{
    AVFormatContext *s = *ps;
    FFFormatContext *si;
    AVDictionary *tmp = NULL;
    ID3v2ExtraMeta *id3v2_extra_meta = NULL;
    int ret = 0;

    if (!s && !(s = avformat_alloc_context()))
……
}

avformat_alloc_context来给fmt_ctx 分配内存的，看它实质分配的内存有多大:

AVFormatContext *avformat_alloc_context(void)
{
    FFFormatContext *const si = av_mallocz(sizeof(*si));
    AVFormatContext *s;

    if (!si)
        return NULL;

    s = &si->pub;
    s->av_class = &av_format_context_class;
    s->io_open  = io_open_default;
    s->io_close = ff_format_io_close_default;
    s->io_close2= io_close2_default;

    av_opt_set_defaults(s);

    si->pkt = av_packet_alloc();
    si->parse_pkt = av_packet_alloc();
    if (!si->pkt || !si->parse_pkt) {
        avformat_free_context(s);
        return NULL;
    }

    si->shortest_end = AV_NOPTS_VALUE;

    return s;
}

1.3 oopc的继承实现

可以看到它实际分配的内存是FFFormatContext这么大的，但是返回的地址是AVFormatContext *类型的，缩小了。这就是典型的oopc的接口继承。

FFFormatContext类如下实现：

typedef struct FFFormatContext {
    /**
     * The public context.
     */
    AVFormatContext pub;

    /**
     * Number of streams relevant for interleaving.
     * Muxing only.
     */
    int nb_interleaved_streams;
    ……
}

oopc的继承实现是结构体套结构体。如上结构体，FFFormatContext继承自AVFormatContext。

同时可以看到它的特点，一般父类都是作为子类第一个成员，这样方便强转更改访问权限。
FFFormatContext第1个成员就是父类AVFormatContext的成员，把它命名为pub——注释中说是public公共上下文——公共的——这就是面向对象中常用的抽象出的基类的基本方法。

所谓接口继承，就是创建子类返父类的地址，这是多态实现的基础。

oopc中，这种继承是个老套路，也是经典套路，linux中，还有rtthread RTOS的内核实现中常用这种套路，这个应该是oopc的经典。

对应的对象图简略示意图如下：

2. AVInputFormat 类。

就像linux一切统一于文件，ffmpeg的一切拉流输入格式统一于AVInputFormat类——对所有拉流输入格式进行了抽象——体现了面向对象的抽象与多态——不同子类的方法不同，在oopc中就是采用函数指针实现。
什么意思？在代码上，说的“子类”具体代码体现在demuxer_list指针数组——定义在libavformat/demuxer_list.c中——该文件是编译FFMPEG configure的时候生成的（也就是说下载的源码中是没有的，config时才生成），举例生成的数组如下:

static const AVInputFormat * const demuxer_list[] = {
    &ff_aa_demuxer,
    &ff_aac_demuxer,
    &ff_ac3_demuxer,
    &ff_acm_demuxer,
    &ff_act_demuxer,
    &ff_adf_demuxer,
    &ff_adp_demuxer,
    &ff_ads_demuxer,
    &ff_adx_demuxer,
    &ff_aea_demuxer,
    &ff_afc_demuxer,
    &ff_aiff_demuxer,
    &ff_aix_demuxer,
    &ff_amr_demuxer,
    &ff_amrnb_demuxer,
    &ff_amrwb_demuxer,
    &ff_anm_demuxer,
    &ff_apc_demuxer,
    &ff_ape_demuxer,
    &ff_apng_demuxer,
    &ff_aptx_demuxer,
    &ff_aptx_hd_demuxer,
    &ff_aqtitle_demuxer,
    &ff_asf_demuxer,
    &ff_asf_o_demuxer,
    &ff_ass_demuxer,
    &ff_ast_demuxer,
    &ff_au_demuxer,
    &ff_avi_demuxer,
    &ff_avr_demuxer,
    &ff_avs_demuxer,
    &ff_bethsoftvid_demuxer,
    &ff_bfi_demuxer,
    &ff_bintext_demuxer,
    &ff_bink_demuxer,
    &ff_bit_demuxer,
    &ff_bmv_demuxer,
    &ff_bfstm_demuxer,
    &ff_brstm_demuxer,
    &ff_boa_demuxer,
    &ff_c93_demuxer,
    &ff_caf_demuxer,
    &ff_cavsvideo_demuxer,
    &ff_cdg_demuxer,
    &ff_cdxl_demuxer,
    &ff_cine_demuxer,
    &ff_codec2_demuxer,
    &ff_codec2raw_demuxer,
    &ff_concat_demuxer,
    &ff_data_demuxer,
    &ff_daud_demuxer,
    &ff_dcstr_demuxer,
    &ff_dfa_demuxer,
    &ff_dirac_demuxer,
    &ff_dnxhd_demuxer,
    &ff_dsf_demuxer,
    &ff_dsicin_demuxer,
    &ff_dss_demuxer,
    &ff_dts_demuxer,
    &ff_dtshd_demuxer,
    &ff_dv_demuxer,
    &ff_dvbsub_demuxer,
    &ff_dvbtxt_demuxer,
    &ff_dxa_demuxer,
    &ff_ea_demuxer,
    &ff_ea_cdata_demuxer,
    &ff_eac3_demuxer,
    &ff_epaf_demuxer,
    &ff_ffmetadata_demuxer,
    &ff_filmstrip_demuxer,
    &ff_fits_demuxer,
    &ff_flac_demuxer,
    &ff_flic_demuxer,
    &ff_flv_demuxer,
    &ff_live_flv_demuxer,
    &ff_fourxm_demuxer,
    &ff_frm_demuxer,
    &ff_fsb_demuxer,
    &ff_g722_demuxer,
    &ff_g723_1_demuxer,
    &ff_g726_demuxer,
    &ff_g726le_demuxer,
    &ff_g729_demuxer,
    &ff_gdv_demuxer,
    &ff_genh_demuxer,
    &ff_gif_demuxer,
    &ff_gsm_demuxer,
    &ff_gxf_demuxer,
    &ff_h261_demuxer,
    &ff_h263_demuxer,
    &ff_h264_demuxer,
    &ff_hevc_demuxer,
    &ff_hls_demuxer,
    &ff_hnm_demuxer,
    &ff_ico_demuxer,
    &ff_idcin_demuxer,
    &ff_idf_demuxer,
    &ff_iff_demuxer,
    &ff_ilbc_demuxer,
    &ff_image2_demuxer,
    &ff_image2pipe_demuxer,
    &ff_image2_alias_pix_demuxer,
    &ff_image2_brender_pix_demuxer,
    &ff_ingenient_demuxer,
    &ff_ipmovie_demuxer,
    &ff_ircam_demuxer,
    &ff_iss_demuxer,
    &ff_iv8_demuxer,
    &ff_ivf_demuxer,
    &ff_ivr_demuxer,
    &ff_jacosub_demuxer,
    &ff_jv_demuxer,
    &ff_lmlm4_demuxer,
    &ff_loas_demuxer,
    &ff_lrc_demuxer,
    &ff_lvf_demuxer,
    &ff_lxf_demuxer,
    &ff_m4v_demuxer,
    &ff_matroska_demuxer,
    &ff_mgsts_demuxer,
    &ff_microdvd_demuxer,
    &ff_mjpeg_demuxer,
    &ff_mjpeg_2000_demuxer,
    &ff_mlp_demuxer,
    &ff_mlv_demuxer,
    &ff_mm_demuxer,
    &ff_mmf_demuxer,
    &ff_mov_demuxer,
    &ff_mp3_demuxer,
    &ff_mpc_demuxer,
    &ff_mpc8_demuxer,
    &ff_mpegps_demuxer,
    &ff_mpegts_demuxer,
    &ff_mpegtsraw_demuxer,
    &ff_mpegvideo_demuxer,
    &ff_mpjpeg_demuxer,
    &ff_mpl2_demuxer,
    &ff_mpsub_demuxer,
    &ff_msf_demuxer,
    &ff_msnwc_tcp_demuxer,
    &ff_mtaf_demuxer,
    &ff_mtv_demuxer,
    &ff_musx_demuxer,
    &ff_mv_demuxer,
    &ff_mvi_demuxer,
    &ff_mxf_demuxer,
    &ff_mxg_demuxer,
    &ff_nc_demuxer,
    &ff_nistsphere_demuxer,
    &ff_nsp_demuxer,
    &ff_nsv_demuxer,
    &ff_nut_demuxer,
    &ff_nuv_demuxer,
    &ff_ogg_demuxer,
    &ff_oma_demuxer,
    &ff_paf_demuxer,
    &ff_pcm_alaw_demuxer,
    &ff_pcm_mulaw_demuxer,
    &ff_pcm_f64be_demuxer,
    &ff_pcm_f64le_demuxer,
    &ff_pcm_f32be_demuxer,
    &ff_pcm_f32le_demuxer,
    &ff_pcm_s32be_demuxer,
    &ff_pcm_s32le_demuxer,
    &ff_pcm_s24be_demuxer,
    &ff_pcm_s24le_demuxer,
    &ff_pcm_s16be_demuxer,
    &ff_pcm_s16le_demuxer,
    &ff_pcm_s8_demuxer,
    &ff_pcm_u32be_demuxer,
    &ff_pcm_u32le_demuxer,
    &ff_pcm_u24be_demuxer,
    &ff_pcm_u24le_demuxer,
    &ff_pcm_u16be_demuxer,
    &ff_pcm_u16le_demuxer,
    &ff_pcm_u8_demuxer,
    &ff_pjs_demuxer,
    &ff_pmp_demuxer,
    &ff_pva_demuxer,
    &ff_pvf_demuxer,
    &ff_qcp_demuxer,
    &ff_r3d_demuxer,
    &ff_rawvideo_demuxer,
    &ff_realtext_demuxer,
    &ff_redspark_demuxer,
    &ff_rl2_demuxer,
    &ff_rm_demuxer,
    &ff_roq_demuxer,
    &ff_rpl_demuxer,
    &ff_rsd_demuxer,
    &ff_rso_demuxer,
    &ff_rtp_demuxer,
    &ff_rtsp_demuxer,
    &ff_s337m_demuxer,
    &ff_sami_demuxer,
    &ff_sap_demuxer,
    &ff_sbc_demuxer,
    &ff_sbg_demuxer,
    &ff_scc_demuxer,
    &ff_sdp_demuxer,
    &ff_sdr2_demuxer,
    &ff_sds_demuxer,
    &ff_sdx_demuxer,
    &ff_segafilm_demuxer,
    &ff_shorten_demuxer,
    &ff_siff_demuxer,
    &ff_sln_demuxer,
    &ff_smacker_demuxer,
    &ff_smjpeg_demuxer,
    &ff_smush_demuxer,
    &ff_sol_demuxer,
    &ff_sox_demuxer,
    &ff_spdif_demuxer,
    &ff_srt_demuxer,
    &ff_str_demuxer,
    &ff_stl_demuxer,
    &ff_subviewer1_demuxer,
    &ff_subviewer_demuxer,
    &ff_sup_demuxer,
    &ff_svag_demuxer,
    &ff_swf_demuxer,
    &ff_tak_demuxer,
    &ff_tedcaptions_demuxer,
    &ff_thp_demuxer,
    &ff_threedostr_demuxer,
    &ff_tiertexseq_demuxer,
    &ff_tmv_demuxer,
    &ff_truehd_demuxer,
    &ff_tta_demuxer,
    &ff_txd_demuxer,
    &ff_tty_demuxer,
    &ff_ty_demuxer,
    &ff_v210_demuxer,
    &ff_v210x_demuxer,
    &ff_vag_demuxer,
    &ff_vc1_demuxer,
    &ff_vc1t_demuxer,
    &ff_vivo_demuxer,
    &ff_vmd_demuxer,
    &ff_vobsub_demuxer,
    &ff_voc_demuxer,
    &ff_vpk_demuxer,
    &ff_vplayer_demuxer,
    &ff_vqf_demuxer,
    &ff_w64_demuxer,
    &ff_wav_demuxer,
    &ff_wc3_demuxer,
    &ff_webm_dash_manifest_demuxer,
    &ff_webvtt_demuxer,
    &ff_wsaud_demuxer,
    &ff_wsd_demuxer,
    &ff_wsvqa_demuxer,
    &ff_wtv_demuxer,
    &ff_wve_demuxer,
    &ff_wv_demuxer,
    &ff_xa_demuxer,
    &ff_xbin_demuxer,
    &ff_xmv_demuxer,
    &ff_xvag_demuxer,
    &ff_xwma_demuxer,
    &ff_yop_demuxer,
    &ff_yuv4mpegpipe_demuxer,
    &ff_image_bmp_pipe_demuxer,
    &ff_image_dds_pipe_demuxer,
    &ff_image_dpx_pipe_demuxer,
    &ff_image_exr_pipe_demuxer,
    &ff_image_j2k_pipe_demuxer,
    &ff_image_jpeg_pipe_demuxer,
    &ff_image_jpegls_pipe_demuxer,
    &ff_image_pam_pipe_demuxer,
    &ff_image_pbm_pipe_demuxer,
    &ff_image_pcx_pipe_demuxer,
    &ff_image_pgmyuv_pipe_demuxer,
    &ff_image_pgm_pipe_demuxer,
    &ff_image_pictor_pipe_demuxer,
    &ff_image_png_pipe_demuxer,
    &ff_image_ppm_pipe_demuxer,
    &ff_image_psd_pipe_demuxer,
    &ff_image_qdraw_pipe_demuxer,
    &ff_image_sgi_pipe_demuxer,
    &ff_image_svg_pipe_demuxer,
    &ff_image_sunrast_pipe_demuxer,
    &ff_image_tiff_pipe_demuxer,
    &ff_image_webp_pipe_demuxer,
    &ff_image_xpm_pipe_demuxer,
    &ff_image_xwd_pipe_demuxer,
    NULL };

ffmpeg支持的每一个输入格式都统一抽象为AVInputFormat类，支持的每个输入格式都实例化一个AVInputFormat对象出来（oopc就是变量或全局变量），然后放到这个指针数组中——聚合到一起了。

而AVFormatContext的成员iformat就是AVInputFormat类的指针，它就是匹配到上面指针数组里的成员的呢！那么如何匹配的呢？通过av_demuxer_iterate循环遍历指针数组demuxer_list拿到的。
具体调用链如下:
avformat_open_input => init_input => av_probe_input_format2 => av_probe_input_format3 => av_demuxer_iterate。

const AVInputFormat *av_demuxer_iterate(void **opaque)
{
    static const uintptr_t size = sizeof(demuxer_list)/sizeof(demuxer_list[0]) - 1;
    uintptr_t i = (uintptr_t)*opaque;
    const AVInputFormat *f = NULL;
    uintptr_t tmp;

    if (i < size) 
    {
        f = demuxer_list[i];
    } 
    else if (tmp = atomic_load_explicit(&indev_list_intptr, memory_order_relaxed)) 
    {
        const AVInputFormat *const *indev_list = (const AVInputFormat *const *)tmp;
        f = indev_list[i - size];
    }

    if (f)
        *opaque = (void*)(i + 1);
    return f;
}

2.1 多态的实现

这样，av_demuxer_iterate循环遍历libavformat/demuxer_list.c中的demuxer_list数组，AVFormatContext的成员iformat就匹配到了指针数组demuxer_list中的成员。

ffmpeg在各个格式的c文件中定义了AVInputFormat类的对象（全局变量），最后被加入到demuxer_list数组中。这样实现多态。

这里比如rtsp拉流，输入是“rtsp:”的形式，它会匹配到ff_rtsp_demuxer这个全局变量（通过调用read_probe）——定义在libavformat/rtspdec.c中：

const AVInputFormat ff_rtsp_demuxer = {
    .name           = "rtsp",
    .long_name      = NULL_IF_CONFIG_SMALL("RTSP input"),
    .priv_data_size = sizeof(RTSPState),
    .read_probe     = rtsp_probe,
    .read_header    = rtsp_read_header,
    .read_packet    = rtsp_read_packet,
    .read_close     = rtsp_read_close,
    .read_seek      = rtsp_read_seek,
    .flags          = AVFMT_NOFILE,
    .read_play      = rtsp_read_play,
    .read_pause     = rtsp_read_pause,
    .priv_class     = &rtsp_demuxer_class,
};

AVInputFormat类抽象的这些方法包括:
探测或者称之为辨识是不是本格式的方法probe，
读头信息，读取包数据，等等。把各种格式都抽象统一于此，这样同样的子类但是方法不同，实现了多态。

3.所用设计模式

3.1模板模式

接着统一的操作如下：

当然不仅仅这一种统一操作——但是这种统一操作，不管啥格式的，都走这个流程，这种设计模式是为模版模式。

avformat_open_input中的流程，可以说是对所有输入格式抽象出来的共性流程，这种提取出的共性流程，基本万古不变，变得只是函数指针指向或者参数配置，那么这种流程就像一个“模板”一样，这就是模板模式。

这种模式是常见的模式，因为行业固定，行业对应的业务流程基本能抽出共性的流程，那么随着代码的迭代，共性代码会自然出现，而不是因为“设计模式”才出现模板模式，而是因为这样的代码出现了，对它总结，起个名字叫“模板模式”。设计模式来源于现成代码的概念抽象和总结。

3.2 工厂模式？

从上面AVFormatContext的成员iformat匹配对应的AVInputFormat这种行为，有点类似策略模式（但是策略模式的特点是运行中可以更改算法，但这里不是，初始化完毕就不能动了），又有点像工厂模式，工厂模式会根据不同格式创建不同类，和这个有点异曲同工，也有解析的部分，解析到哪类就实例化哪类。我更倾向于它这种解析匹配子类对象地址的方式是工厂模式。

不管了，反正记住一点，设计模式是对现有代码的抽象，先有代码，再有提出对应设计模式的概念。

3.3 rtsp拉流建链

AVFormatContext的成员iformat匹配到合适的全局变量后，
有个统一操作
s->iformat->read_header(s)。

在rtsp拉流对象对应的就是ff_rtsp_demuxer中的rtsp_read_header，如下实现

static int rtsp_read_header(AVFormatContext *s)
{
    RTSPState *rt = s->priv_data;
    int ret;

    if (rt->initial_timeout > 0)
        rt->rtsp_flags |= RTSP_FLAG_LISTEN;

    if (rt->rtsp_flags & RTSP_FLAG_LISTEN) {
        ret = rtsp_listen(s);
        if (ret)
            return ret;
    } else {
        ret = ff_rtsp_connect(s);
        if (ret)
            return ret;

        rt->real_setup_cache = !s->nb_streams ? NULL :
            av_calloc(s->nb_streams, 2 * sizeof(*rt->real_setup_cache));
        if (!rt->real_setup_cache && s->nb_streams) {
            ret = AVERROR(ENOMEM);
            goto fail;
        }
        rt->real_setup = rt->real_setup_cache + s->nb_streams;

        if (rt->initial_pause) {
            /* do not start immediately */
        } else {
            ret = rtsp_read_play(s);
            if (ret < 0)
                goto fail;
        }
    }

    return 0;

fail:
    rtsp_read_close(s);
    return ret;
}

可以看到很关键，包含了rtsp协议链接到完成。

4.this指针

看下oopc是如何模拟this指针的。
再次突出强调下，rtsp拉流对象是FFFormatContext——对用户看到的是其基类AVFormatContext指针——this指针。

FFFormatContext这个就是流对象。this指针实质指向的就是这个流对象的地址。

看下前面的调用
avformat_open_input
av_read_frame
avformat_close_input
它们几个的第一个形参都是流对象的基类指针。

还有其内部调用方法形式:

s->iformat->read_header(s)，
它模拟的就是面向对象的如下形式：
对象指针->对象方法（形参1，形参2，…）

因为面向对象的this指针是默认参数（c++是this，python是self），代码中不需要显式调用，但是oopc中this指针只能如上形式进行显式调用。

而且，还能发现AVInputFormat对所有格式抽象的方法第一个形参都是AVFormatContext指针，这就是this指针，这里this指针指的就是FFFormatContext的基类对象指针。

再看下av_read_frame这个调用，它第一个形参也是这个this指针，内部怎么调用的呢？截取如下

int av_read_frame(AVFormatContext *s, AVPacket *pkt)
{
    FFFormatContext *const si = ffformatcontext(s);
		……
ret = read_frame_internal(s, pkt);
		……
}

static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
{
    FFFormatContext *const si = ffformatcontext(s);
...
    while (!got_packet && !si->parse_queue.head) {
        AVStream *st;
        FFStream *sti;

        /* read next packet */
      ret = ff_read_packet(s, pkt);
  ……
        
}

int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
{
    FFFormatContext *const si = ffformatcontext(s);
   for (;;) {
……
   err = s->iformat->read_packet(s, pkt);
……

}

调用链一路到了ff_read_packet，最终到了如下调用：

s->iformat->read_packet(s, pkt); 

和之前的形式一样，模拟了面向对象的方法调用形式，但是this指针需要显式调用。

另外AVFormatContext 基类指针怎么取到子类FFFormatContext 指针的呢？ffformatcontext(s)调用，如下

static av_always_inline FFFormatContext *ffformatcontext(AVFormatContext *s)
{
    return (FFFormatContext*)s;
}

很显然，就是强转改变访问权限，不像c++需要维护虚表，运行时选择。因为c没有这个机制，只能这样子，当然linux内核没有做的这么方便，用的是内核第一宏container_of()根据成员地址推算结构体指针，这样父类可以不放到子类结构体的第一个成员。

5.小结

发散下思维，想下面向对象语言的拉流代码怎么写？
伪代码:

s＝new 拉流对象;
while(1)
{
s->读数据方法（packet）;
}
delete s;

oopc模拟的话，类使用结构体表示的，继承一般采用结构体套结构体的形式，多态采用函数指针形式。

拉流结构体 s;
s.方法（s指针即this指针，形参1,形参2，...）

ffmpeg拉流呢，就是模拟的这样，比如创建FFFormatContext类对象，然后返回其父类指针，然后调用AVFormatContext的拉流方法:

s->iformat->read_packet(s, pkt); 

其他的方法都是以这个流对象为中心，实质是对流对象进行操作——构造、析构、方法调用。这个方法包含了各种格式，编码、解码、转换，这个流对象就是中心操作对象——流对象内部存放了百宝箱——有数据有方法——这就是面向对象的类对象。这样化繁为简，统一操作。

如果你学过一门面向对象语言，只要掌握基础的类定义，继承，封装，接口类等基础语法，还有了解下智能指针，再看这个ffmpeg代码或者rtthreadrtos内核源码，那么就会感觉无缝衔接，如果了解过oopc的套路，更加无缝衔接。

如果再学下设计模式，那就能看到设计模式。
设计模式是现有代码再由人总结出来的概念。

6.rtsp拉流对象流程图

各类介绍，看这节。

7.rtsp拉流流程

很多博客有，不再赘述。
如下
https://blog.csdn.net/baidu_41388533/article/details/112728029

https://www.cnblogs.com/caiyingyong/p/16947075.html

https://blog.csdn.net/u013692429/article/details/101698740