huibin.yun的博客

虽然都是c语言，但都是采用的面向对象思想，然后又考究了其他oopc源码，也是同样的规则。所以这种规则是oopc的通用规则吧，或者说共识。

rtsp协议的tcp链接创建及链接。

可以在ffmpeg一些数据结构（oopc的类表示）中见到“void *priv_data”这种形式的成员，它有啥作用？

ffmpeg是面向对象的思想写的代码，自然模拟了oopc的实现套路。

前者是应用层协议，比如rtsp，http等，后者是实际协议的底层承载体，比如open，tcp等。先是匹配输入格式，然后再匹配url协议类。

说人话的话，那就是从理解的角度看，mux就是融合数据或复合数据，demux就是分离复合数据。开源项目里常把demux或者mux作为前缀或者后缀，比如live555，ffmpeg等。其实还有一种理解，mux就是多合一，放到数学上叫“降维”。demux就是还原，一分多。在流媒体里，mux被翻译成“复用”，demux被翻译成“解复用”。在数学软件（matlab等）或者流媒体开源项目里，常见到它们的身影。

如果让你写个拉流程序，输入的url，如果是本地文件路径，那就读取本地文件，然后输出一帧一帧的音视频数据，如果是网络流媒体传输协议比如http或者rtsp等，那么也得实现。

ffmpeg支持很多配置——拉流配置推流配置等等——那么庞大的繁杂的配置项，如果是你，该如何实现呢？

oopc中，这种继承是个老套路，也是经典讨论，linux中，还有rtthread RTOS的内核实现中常用这种套路，这个应该是oopc的经典。可以看到它实际分配的内存是FFFormatContext 然后返回的地址是AVFormatContext *类型的，这就是典型的oopc的。可以看到第1个成员就是AVFormatContext 类型的，avformat_alloc_context返回的就是这个成员的地址，其实。所谓接口继承，就是创建子类返父类的地址，这是多态实现的基础。

这让我想起来一件好玩的事，有些搞linux内核驱动的只会c的开发人员不知道linux内核是面向对象的，他们看到智能指针，继承，this指针也不认识。因为查rtsp相关问题，接触了下ffmpeg源码，发现它和linux内核一样，虽然都是c写的，但是都是面向对象的思想，c的面向对象称之为oopc。这就是怎么说，这个代码是c写的没错，但是它采用的思想是不受非c面向过程的束缚，非c半生思想——面向过程。也就是说采用的思想超出了这个编程语言的伴生思想，那就不能仅仅会这门语言了。