摘要：
看这篇文章你需要对ffmpeg已经有一定的使用经验，知道如何read帧，解帧，或者write等。 ffmpeg内部使用跑结构体表函数指针的方式，实现了类似C++的多态性，，我们来简析一下。 【注册表】 我们使用ffmpeg，首先要执行av_register_all，这个玩意儿把全局的解码器、编码器等结构体注册到一些全局的对象表里，以便后面跑表调用。 注册的类型有：解复用器、重复用器、解码器、编码器、包解析器、BitStreamFilter（位流处理器）。 【解封装（解复用器
看这篇文章你需要对ffmpeg已经有一定的使用经验，知道如何read帧，解帧，或者write等。
ffmpeg内部使用跑结构体表函数指针的方式，实现了类似C++的多态性，，我们来简析一下。
【注册表】
我们使用ffmpeg，首先要执行av_register_all，这个玩意儿把全局的解码器、编码器等结构体注册到一些全局的对象表里，以便后面跑表调用。
注册的类型有：解复用器、重复用器、解码器、编码器、包解析器、BitStreamFilter（位流处理器）。
【解封装（解复用器）】
解复用的工作主要有：
1、判断流格式是否支持（正确）。
2、提取流的头信息，比如视频的长宽、音频的声道样本数等。
3、读取压缩的数据流，用于被解码器解码。
这3个步骤，就是我们使用的抽象化的3个函数：
avformat_open_input->av_find_stream_info->av_read_frame。
我们来看一下ffmpeg中解复用器的核心结构（以FLAC音频为例）：
在我们执行av_register_all后，这个flac的AVInputFormat结构体指针会被注册到一个全局对象表里。
而avformat_open_input的工作很简单，其通过avio从来源读取字节流头，然后跑这个全局对象表，一个个去执行read_probe函数，如果哪个read_probe认了就行了。
我们看flac的read_probe实现：
这个probe仅仅只是判断了头是不是fLaC这个字符，是就是ok了，我认了，不是，让avformat_open_input继续匹配文件扩展名（如果有的话）。
如果全部的probe函数都不认，则open失败。
如果有一个probe认了，本来按照理论上来说，read_header应该是在av_find_stream_info执行的，但是ffmpeg还是将其放在了avformat_open_input，其实效果也一样，我们来看看flac的read_header：
首先，我们看到它avformat_new_stream了一个流，因为flac音频只有一个流。
然后我们可以看到，它设置了codec的type和id，就像在DShow里面我们设置MajorType和SubType一样。
我们看到下面有行代码：st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
这个是指示parser（包解析器）的flag，后面说。
再来就进入遍历flac的metadata块过程。
因为我们不是分析flac格式，我这里也不会说flac的metadata块是如何如何，我们只说，当read_header后，AVFormatContext这个结构体，变成啥样了。
flac文件的流信息存储在FLAC_METADATA_TYPE_STREAMINFO块里面，我们看到，在跑FLAC_METADATA_TYPE_STREAMINFO块的时候：
首先，codec->extradata有数据了（就像H264解码器需要SPS\PPS\NAL头一样）。
然后代码里，我们可以看到，流的总长度有了，流的采样率有了，我们再看看avpriv_flac_parse_streaminfo函数：
可以看到，解码一个音频需要的东西都有了，声道、采样率、速率、声道布局、样本总数都已经保存起来了。
而这些信息全部设置在AVCodecContext里，由此，我们可以得出结论，read_header就是一个提取解码器需要的私有信息的函数。
read_header完成，基本上avformat_open_input就要返回了，此时AVCodecContext虽然有一些信息了，但是AVFormatContext还是挺空虚的（此时它已经有流的总数），我们需要填充它，就应该到调用av_find_stream_info的时候了。
av_find_stream_info主要做的工作有几个：
1、填充AVFormatContext信息，比如总长度，timebase、pts、dts和一些内部信息。
2、初始化解码器需要的一些信息。
3、如果需要，则初始化包解析器（parser）。
4、如果需要，尝试解码一些数据，来获取媒体信息。
这里我们忽略前面二点，因为他们跟解封装的关系不大，而第三点，则是跟解封装有莫大关联的。
我们先假设，我们av_find_stream_info成功了。此时我们可以av_read_frame了。
我们知道，av_read_frame读出来的AVFrame，如果是视频，则是视频的一帧(IPB中)，如果是音频，则是几帧。
但是av_read_frame不会有断帧的情况，就是不会有0.5帧这种情况，这个到底是如何做的呢，我们来看。
首先我们回到上面的：
我们看了read_probe用于判断，read_header用于解析头，那还有一个关键的东西没看，就是那个read_packet。
我们可以看到，flac这里的read_packet指向了一个公用函数ff_raw_read_partial_packet，我们来看看这个函数：
这个函数那真是十分简单，其注意做的工作就是：
1、新建一个1024字节的AVPacket。
2、从IO读1024字节的数据（如果当前指针到文件尾没有1024字节，即读差值）。
3、把实际读取到的数据写回包size（av_shrink_packet）。
我们可以看到，这玩意儿每次就读个1024字节，可就算是音频文件，也不可能说所有帧在文件里面的偏移都对齐到1024个字节，也不可能说一个帧大小必定是1024字节，而且对视频文件，读到的1024字节的数据还会穿插着视频\音频帧，所以这个AVPacket肯定不会是我们调用av_read_frame出来的那么漂亮的AVPakcet，必然是经过“修整”的，那这个修整模块在哪里呢？即为parser。
我们来看flac的parser结构：
我们可以看到，demuxer和parser都关联了同一个codec的id，即AV_CODEC_ID_FLAC，表明他们是连接在一起的。
parser结构由av_find_stream_info初始化，av_find_stream_info会执行av_parser_init通过codec_id给一个个流初始化parser。
av_parser_init的查找方式也是跟查找demuxer一样，parser已经注册在了全局的表里面，跑表匹配即可。
关于包解析器，下次细说。
ffmpeg内部使用跑结构体表函数指针的方式，实现了类似C++的多态性，，我们来简析一下。
【注册表】
我们使用ffmpeg，首先要执行av_register_all，这个玩意儿把全局的解码器、编码器等结构体注册到一些全局的对象表里，以便后面跑表调用。
注册的类型有：解复用器、重复用器、解码器、编码器、包解析器、BitStreamFilter（位流处理器）。
【解封装（解复用器）】
解复用的工作主要有：
1、判断流格式是否支持（正确）。
2、提取流的头信息，比如视频的长宽、音频的声道样本数等。
3、读取压缩的数据流，用于被解码器解码。
这3个步骤，就是我们使用的抽象化的3个函数：
avformat_open_input->av_find_stream_info->av_read_frame。
我们来看一下ffmpeg中解复用器的核心结构（以FLAC音频为例）：
在我们执行av_register_all后，这个flac的AVInputFormat结构体指针会被注册到一个全局对象表里。
而avformat_open_input的工作很简单，其通过avio从来源读取字节流头，然后跑这个全局对象表，一个个去执行read_probe函数，如果哪个read_probe认了就行了。
我们看flac的read_probe实现：
这个probe仅仅只是判断了头是不是fLaC这个字符，是就是ok了，我认了，不是，让avformat_open_input继续匹配文件扩展名（如果有的话）。
如果全部的probe函数都不认，则open失败。
如果有一个probe认了，本来按照理论上来说，read_header应该是在av_find_stream_info执行的，但是ffmpeg还是将其放在了avformat_open_input，其实效果也一样，我们来看看flac的read_header：
首先，我们看到它avformat_new_stream了一个流，因为flac音频只有一个流。
然后我们可以看到，它设置了codec的type和id，就像在DShow里面我们设置MajorType和SubType一样。
我们看到下面有行代码：st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
这个是指示parser（包解析器）的flag，后面说。
再来就进入遍历flac的metadata块过程。
因为我们不是分析flac格式，我这里也不会说flac的metadata块是如何如何，我们只说，当read_header后，AVFormatContext这个结构体，变成啥样了。
flac文件的流信息存储在FLAC_METADATA_TYPE_STREAMINFO块里面，我们看到，在跑FLAC_METADATA_TYPE_STREAMINFO块的时候：
首先，codec->extradata有数据了（就像H264解码器需要SPS\PPS\NAL头一样）。
然后代码里，我们可以看到，流的总长度有了，流的采样率有了，我们再看看avpriv_flac_parse_streaminfo函数：
可以看到，解码一个音频需要的东西都有了，声道、采样率、速率、声道布局、样本总数都已经保存起来了。
而这些信息全部设置在AVCodecContext里，由此，我们可以得出结论，read_header就是一个提取解码器需要的私有信息的函数。
read_header完成，基本上avformat_open_input就要返回了，此时AVCodecContext虽然有一些信息了，但是AVFormatContext还是挺空虚的（此时它已经有流的总数），我们需要填充它，就应该到调用av_find_stream_info的时候了。
av_find_stream_info主要做的工作有几个：
1、填充AVFormatContext信息，比如总长度，timebase、pts、dts和一些内部信息。
2、初始化解码器需要的一些信息。
3、如果需要，则初始化包解析器（parser）。
4、如果需要，尝试解码一些数据，来获取媒体信息。
这里我们忽略前面二点，因为他们跟解封装的关系不大，而第三点，则是跟解封装有莫大关联的。
我们先假设，我们av_find_stream_info成功了。此时我们可以av_read_frame了。
我们知道，av_read_frame读出来的AVFrame，如果是视频，则是视频的一帧(IPB中)，如果是音频，则是几帧。
但是av_read_frame不会有断帧的情况，就是不会有0.5帧这种情况，这个到底是如何做的呢，我们来看。
首先我们回到上面的：
我们看了read_probe用于判断，read_header用于解析头，那还有一个关键的东西没看，就是那个read_packet。
我们可以看到，flac这里的read_packet指向了一个公用函数ff_raw_read_partial_packet，我们来看看这个函数：
这个函数那真是十分简单，其注意做的工作就是：
1、新建一个1024字节的AVPacket。
2、从IO读1024字节的数据（如果当前指针到文件尾没有1024字节，即读差值）。
3、把实际读取到的数据写回包size（av_shrink_packet）。
我们可以看到，这玩意儿每次就读个1024字节，可就算是音频文件，也不可能说所有帧在文件里面的偏移都对齐到1024个字节，也不可能说一个帧大小必定是1024字节，而且对视频文件，读到的1024字节的数据还会穿插着视频\音频帧，所以这个AVPacket肯定不会是我们调用av_read_frame出来的那么漂亮的AVPakcet，必然是经过“修整”的，那这个修整模块在哪里呢？即为parser。
我们来看flac的parser结构：
我们可以看到，demuxer和parser都关联了同一个codec的id，即AV_CODEC_ID_FLAC，表明他们是连接在一起的。
parser结构由av_find_stream_info初始化，av_find_stream_info会执行av_parser_init通过codec_id给一个个流初始化parser。
av_parser_init的查找方式也是跟查找demuxer一样，parser已经注册在了全局的表里面，跑表匹配即可。
关于包解析器，下次细说。
- 顶