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 };

而AVFormatContext的成员iformat就是AVInputFormat类的，它是如何拿到AVInputFormat信息的呢？在avformat_open_input中，调用 init_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 多态的实现

在这里就是循环遍历libavformat/demuxer_list.c中的demuxer_list数组，和输入的url进行匹配，不同的输入匹配不同的AVInputFormat类的对象（全局变量）。ffmpeg在各个格式的c文件中定义了AVInputFormat类的对象（全局变量），最后被加入到demuxer_list数组中。这样实现多态。

这样AVFormatContext的成员iformat就根据avformat_open_input的第二个成员filename——字符串（一般是url）——从指针数组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输入的url进行解析，接着统一的操作如下：

这种统一操作，不管啥格式的，都走这个流程，就像linux的一切皆文件一样，这种设计模式是为模版模式。

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的拉流方法read_packet:
s->iformat->read_packet(s, pkt);

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

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

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

6.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