FFmpeg 框架简介和文件解复用

ffmpeg框架简介

八大库：

1. libavformat：复用和解复用，格式封装
2. libavcodec：编码、解码
3. libavutil：通用音视频工具，像素、IO、时间等工具
4. iibavfilter：过滤器，可以用作音视频特效处理
5. libavdevice：设备（摄像头、麦克风）
6. libswscale：视频图像缩放，像素格式互换
7. libswresample：重采样
8. libpostproc：后期处理

libavformat库

libavformat库包含I/O模块和Muxing/Demuxing库，它是一个处理各种媒体容器格式的库。它的两个主要用途是拆分（即将媒体文件拆分为组件流）和反向拆分（以指定的容器格式写入提供的数据）。它还有一个I/O模块，支持访问数据的多种协议（如file、tcp、http等）。除非你绝对确定你不会使用libavformat的网络功能，否则你也应该调用avforamt_network_init()来初始化网络功能。

支持的输入格式（即解复用）由AVInputFormat结构体描述，相反，输出格式（即复用）由AVOutputFormat描述。可以使用av_demuxer_iterate()/av_muxer_iterate()函数遍历所有输入/输出格式。协议层不是公共API的一部分，因此您只能使用avio_enum_protocols()函数获得受支持协议的名称。

用于复用和解复用的主要结构是AVFormatContext，它保存关于读取或写入的文件的所有信息，与大多数Libavformat库的结构体一样，它不能在堆栈上分配或直接使用av_malloc()，要创建AVFormatContext，必须使用avformat_alloc_context()，有些函数会自动分配内存，如avformat_open_input()，最重要的是，AVFormatContext包含：

1. 输入或输出格式。它是自动检测或由用户设置输入。输出总是由用户设置。
2. AVSteams的数组，它描述了存储在文件中的所有基本流。AVStreams通常在这个数组中使用它们的索引来引用。
3. I/O context。对于输入，它是由libavformat库打开的或由用户设置的，对于输出，始终由用户设置，除非您处理AVFMT_NOFILE格式。
   使用AVOptions机制可以配置复用器和解复用器。通用的（与格式无关的）libavformat选项由AVFormatContext提供，它们可以从用户程序中通过调用av_opt_next()/av_opt_find()对分配的AVFormatContext，或其avformat_get_class()中的AVClass进行检查。私有特定于格式的选项由AVFormatContext提供，priv_data当且仅当AVInputFormat，priv_class/AVOutputFormat相应格式结构的priv_class为非null时有效。如果I/O上下文的AVClass为非null，则可以提供进一步的选项

libavformat中的URL由协议、':‘和特定于协议的字符串组成。支持不带协议标识的url和使用’:'来表示本地文件，但已弃用，本地文件应该用’file:'标识

libavcodec库

avcodec_send_packet()/avcodec_receive_frame()/avcodec_send_frame()/avcodec_receive_packet()函数提供了编码/解码API，它将输入作为解码，输出作为编码

该API在编码/解码和音频/视频方面非常相似，工作方式如下：

1. 像往常一样设置并打开AVCodecContext
2. 发送有效的输入：

• 对于解码，调用avcodec_send_packet()以向解码器提供包含原始压缩数据的AVPacket
• 对于编码，调用avcodec_send_frame()以向解码器提供包含未压缩音频或视频的AVFrame
  在两种情况下，建议对AVPackets和AVFrames进行引用计数，否则libavcodec可能需要复制输入数据。（libavformat总是返回引用计数的AVPackets，av_frame_get_buffer()分配引用计数的AVFrames）

3. 在循环接收输出，定期调用avcodec_receive_*()函数并处理其输出：

• 对于解码，调用avcodec_receive_frame()，成功时，它降返回一个包含未压缩音频或视频数据的AVFrame
• 对于编码，调用avcodec_receive_packet()，成功时，它将返回一个带有压缩帧的AVPacket
  重复此调用，直到返回AVERROR(EAGAIN)或错误，AVERROR(EAGAIN)返回值表示需要新的输入数据以生成新的输出。在这种情况下，继续发送输入，对于每个输入帧/包，编解码器通常会返回1个输出帧/包，但也可以是0或多于1个。

在解码或者编码开始时，编解码器可能接受多个输入帧./包而不返回帧，直到其内部缓冲区填满。如果按照上述步骤操作，这种情况会被透明处理。

理论上，发送输入可能导致EAGAIN，这只有在没有接收到全部输出时才会发生。您可以利用这一点来构建除了上面建议的循环之外的其他解码或编码循环。例如，您可以尝试在每次迭代中发送新的输入，并在返回EAGAIN时尝试接收输出。

流结束的情况需要对编码器进行"flush"（也成为draining），因为编解码器可能会在内部缓冲多个帧或包以提高性能或出于必要性（考虑B帧）。处理方式如下：

1. 而不是提供有效的输入，向avcodec_send_packet()解码或avcodec_send_frame()编码函数发送NULL，这将进入排空模式
2. 在循环中调用avcodec_receive_frame()解码或avcodec_receive_packet()编码，直到返回AVERROR_EOF。这些函数不会返回AVERROR(EAGAIN)，除非您忘记进入排空模式。
3. 在解码可以再次开始之前，必须使用avcodec_flush_buffers()重置编解码器。

强烈建议按照上述提纲使用API。但也可以在这种严格的模式之外调用函数。例如，可以反复调用avcodec_send_packet()，而不调用avcodec_receive_frame()，在这种情况下，avcodec_send_packet()将成功，直到编解码器的内部缓冲区被填满（通常是每个输出帧的大小，初始输入后），然后使用AVERROR(EAGAIN)拒绝输入。一旦开始拒绝输入，您别无选择，只能读取至少一些输出。

并非所有编解码器都会遵循严格且可预测的数据流，唯一的保证是在一个端口的send/receive调用返回AVERROR(EAGAIN)意味着在另一端口的receive/send调用将成功，或者至少不会以AVERROR(EAGAIN)失败，总的来说，没有编解码器允许无限制地缓冲输入或输出。

编解码器不允许对发送和接收都返回AVERROR(EAGAIN)。这将是一种无效的状态，可能使编解码器用户陷入无休止的循环。API没有时间的概念：尝试执行avcodec_send_packet()不可能导致AVERROR(EAGAIN)，但在1秒后的重复调用接受包（不涉及其他receive/flush API调用）。API是一个严格的状态机，时间的流逝不应该影响它。在某些情况下，某些依赖于时间的行为可能仍然被视为可以接受的，但绝不能导致在任何时候同时返回EAGAIN的发送/接收。还必须绝对避免当前状态是“不稳定”的且可以在发送/接收API之间“翻转”的情况。例如，编解码器不允许随机决定在刚刚在avcodec_send_packet()调用上返回AVERROR(EAGAIN)后，现在实际上想要消耗一个包而不适宜返回一个帧。

libavdevice库

libavdevice是专用设备muxer/demuxer库

libavdevice是libavformat的补充库。它提供了各种特殊平台特定的muxers和demuxers，例如用于抓取设备，音频捕获和播放等。因此，libavdevice中的(de)muxers是AVFMT_NOFILE类型的，它们使用自己的I/O函数。传递给avformat_open_input()的文件名通常不指向实际存在的文件，但具有某些特定于设备的特殊含义。例如，对于xcbgrab，它是显示名称，

要使用libavdevice，只需要调用avdevice_register_all()来注册所有编译的复用器和解复用器。它们都使用标准的libavformat API。

复用（muxers）和解复用（demuxers）

容器格式

FLV

FLV是Adobe公司推出的一种流媒体格式，由于其封装后的音视频文件体积小，封装简单等特点，非常适合于互联网上使用，目前主流的视频网站基本都支持FLV，采用FLV格式封装的文件后缀为.flv。

FLV封装格式是由一个文件头（file header）和文件体（file body）组成。其中，FLV body由一对对的（Previous_Tag_Size字段+tag）组成，Previous_Tag_Size字段排列在Tag之前，占用4个字节。Previous_Tag_Size记录了前面一个Tag的大小，用于逆向读取处理，FLV header后的第一个Pervious_Tag_Size的值为0。Tag一般可以分为3种类型：脚本，数据类型、音频数据类型、视频数据。FLV数据以大端序进行存储，在解析时需要注意，一个标准FLV文件结构如下图：

Script Tag Data结构（脚本类型、帧类型）

该类型Tag又被称为MetaData Tag，存放一些关于FLV视频和音频的元信息，比如：duration、width、height等。通常该类型tag会作为FLV文件的第一个tag，并且只有一个，跟在File Header后。该类型Tag Data的结构如下所示：

第一个AMF包：
第一个字节表示AMF包类型，一般总是0x02，表示字符串，第2-3个字节为UI16类型值，标识字符串的长度，一般总是0x000A（onMeataData长度）。后面字节为具体的字符串，一般总为onMetaData（6F 6E 4D 65 74 61 44 61 74 61）.
第二个AMF包：
第1个字节表示AMF包类型，一般总是0x08，表示数组，第2-5个字节为UI32类型值，表示数组元素的个数，后面即为各数组元素的封装，数组元素为元素名称和值组成的对。常见的数组元素如下表所示

值	Comment	例如
duration	时长（秒）	210.732
width	视频宽度	768.000
height	视频高度	320.000
videodatarate	视频码率	207.260
framerate	视频帧率	25.000
videocodecid	视频编码ID	7.000（H264为7）
audiodatarate	音频码率	29.329
audiosamplerate	音频采样率	44100.000
stereo	是否立体声	1
audiocodecid	音频编码ID	10.000（aac为10）
major_brand	格式规范相关	isom
minor_version	格式规范相关	512
compatible_brands	格式规范相关	isomiso2avc1mp41
encoder	封装工具名称	Lavf54.63.104
filesize	文件大小（字节）	6636853.000

Audio Tag Data结构（音频Tag）

音频Tag开始的第1个字节包含了音频数据的参数信息，从第二个字节开始为音频流数据

第1个字节的前4位数值表示了音频编码类型

值	含义
0	Linear PCM,platform endian
1	ADPCM
2	MP3
3	Linear PCM,little endian
4	Neltymoser 16-kHz mono
5	Neltymoser 8-kHz mono
6	Neltymoser
7	G.711 A-law logarithmic PCM
8	G.711 mu-law logarithmic PCM
9	reserved
10	AAC
14	MP# 8-kHz
15	Device-specific sound

第1个字节的第5-6位的数值表示音频采样率。

值	含义
0	5.5kHz
1	11kHz
2	22kHz
3	44kHz

从上表可以发现FLV封装格式并不支持48kHz的采样率
第1个字节的第7为表示音频采样精度

值	含义
0	8bits
1	16bits

第1个字节的第8位表示音频类型

值	含义
0	sndMono
1	sndStereo

Video Tag Data结构（视频Tag）

视频Tag也用开始的第1个字节包含视频数据的参数信息，从第2个字节为视频流数据

第1个字节的前4位的数值表示帧类型

值	含义
1	keyframe ( for AVC, a seekable frame )
2	inter frame ( for AVC, a nonseekable frame )
3	disposable inter frame ( H.263 only )
4	generated keyframe ( reserved for server use )
5	video info/command frame

第1个字节的后4位数值表示视频编码类型

值	含义
1	JPEG ( currently unused )
2	Sorenson H.263
3	Screen video
4	On2 VP6
5	On2 VP6 with alpha channel
6	Screen video version 2
7	AVC

MP4

MP4起源于QuickTime，全名是MPEG-4 Part 14，属于MPEG-4的一部分。这部分内容主要规定了多媒体容器的格式。后来成为ISO/IEC 14996-14国际标准，其中MP4就是对这种标准的一种具体实现，基于这个标准进行扩展或者裁剪还产生了像M4V、F4V等封装格式。

MP4文件中的所有数据都装在box中，也就是说MP4文件由若干个box组成，每个box有类型和长度，可以将box理解为一个数据对象块。box中可以包含另一个box，这种box成为container box，一个MP4文件首先会有且只有一个ftyp类型的box，作为MP$格式的标志并包含关于文件的一些信息，之后会有且只有一个moov类型的box，它是一种container box，子box包含了媒体的metadata信息，MPC文件的媒体数据包含在mdat类型的box中，该类型的box也是container box，可以有多个，也可以没有（当媒体数据全部引用其他文件时），媒体数据的结构由metadata进行描述。

Box结构如图所示：

其中，size指明了整个box所占用的大小，包括header部分，如果box很大，超过了uint32的最大数值，size就被设置为1，并且用接下来的8位uint64来存放大小

整体结构

Box 的类型详见下表（其中 * 表示当父 Box 存在时，则必须包含该 Box）：

文件解复用

解复用器（Demuxers）读取媒体文件并将其拆分为数据块（Packet），一个数据包包含一个或多个编码帧，这些帧属于单一的基本流。在libavformat API中，这个过程由以下函数表示：

1. avformat_open_input()用于打开文件。
2. av_read_frame()用于读取单个数据包。
3. avformat_close_input()用于清理工作。

从打开的AVFormatContext中读取数据是通过反复调用av_read_frame()来完成的。每次调用，如果成功，将返回一个AVPacket，其中包含一个AVStream的编码数据，由AVPacket.stream_index字段标识。如果调用者希望解码数据，这个数据包可以直接传递给libavcodec解码函数avcodec_send_packet()或avcodec_decode_subtitle2()。

如果已知，AVPacket.pts、AVPacket.dts和AVPacket.duration时间信息将被设置。如果流没有提供这些信息，它们也可能未设置（例如AV_NOPTS_VSLUE表示pts（播放时间戳）/dts（解码时间戳）未设置，0表示duration未设置）。时间信息的单位是AVStream.tim_base，即必须乘以时间基准才能将其转换为秒。

由av_read_frame()返回的数据包始终是引用计数的，即AVPacket.buf已设置，用户可以无限期保留它，当不再需要数据包时，必须使用av_packet_unref()进行减引用计数。当引用计数为0时，会自动释放内存，或者用av_packet_free()函数释放。

    const char *url = "G:/qtproject/ffmpegTest/source/audio.mp3";
    AVFormatContext *s = NULL;                          // 格式上下文
    int ret = avformat_open_input(&s, url, NULL, NULL); // 打开输入流
    if (ret < 0)
    {
   
        char buf[1024] = {
   0};
        av_strerror(ret, buf, sizeof(buf));
        qDebug() << "open input failed:" << buf;
        return;
    }
    avformat_find_stream_info(s, NULL); // 获取流信息
    av_dump_format(s, 0