在阅读本文前，如果关于音频有些知识不懂，可以看看前面的文章。
1.音频解码过程
音频解码过程如下图所示：
AAC的音频格式送到音频解码器，然后得到PCM收据，音频解码器也有分为硬件或软件解码器，这里就以FFmpeg解码器为主作讲解。
2.FFmpeg音频解码流程
先看看整个流程图，如下:
1.通过解码器id，avcodec_find_decoder去指定解码器。
2.获取裸流解析器， av_parser_init，并返回解析器上下文信息。这个上下文是可以读出相关头信息。
3.avcodec_alloc_context3分配解码器上下文信息。
4.avcodec_open2，将解码器和解码器上下文进行关联。
5.读取文件到缓冲区进行解码，fread，如果 data_size = fread(inbuf, 1, AUDIO_INBUF_SIZE, infile) 大于 0，就持续的去解码。
6.持续送pkt进去解码。前面已经能够解析出一个完整的数据包，所以到这里送进来的就是一个完整的数据包。
7.发送完整的包给解码器，并得到解码后的数据。
接收帧，可能要接收很多次，也就是说送进去一个packet，可能解码都要多次，才能解码完整。
8.获取单个sample所占用的字节，这个仅仅表示的是单个通道
2.debug调试音频解码过程
通过这里先加个断点。如下图:
这里是第一笔data进来的数据。
换算成16进制，这里是以FF开头的。表示就是AAC数据。这里end表示一个缓冲的末尾。
关键数据结构
关键数据结构说明：
AVCodecParser：用于解析输入的数据流并把它分成一帧一帧的压缩编码数据，确保数据是完整的一包，尤其是在把包读到内存中，如果不是完整包，再从内存读出来，实时播放，就会有断断续续的现象。比较形象的说法就是把的一段连续的数据“切割”成一段段的数据。
比如AAC aac_parser:
从AVCodecParser结构的实例化我们可以看出来，不同编码类型的parser是和CODE_ID进行绑定的。所以也就可以解释。可以通过CODE_ID查找到对应的码流 parser。
3.avcodec编解码API介绍
avcodec_send_packet、avcodec_receive_frame的API是FFmpeg3版本加入的。为了正确的使用它们，有必要阅读FFmpeg的文档说明:链接处
:https://www.ffmpeg.org/doxygen/4.1/group__lavc__encdec.html#details。
FFmpeg提供了两组函数，分别用于编码和解码：
(1)解码：avcodec_send_packet()、avcodec_receive_frame()。
(2)编码：avcodec_send_frame()、avcodec_receive_packet()。
建议的使用流程如下：
(1)设置并打开编解码器上下文AVCodecContext。
(2)输入有效的数据：
解码：调用avcodec_send_packet()给解码器传入包含原始的压缩数据的AVPacket对象。
编码：调用 avcodec_send_frame()给编码器传入包含解压数据的AVFrame对象。
两种情况下推荐AVPacket和AVFrame都使用refcounted（引用计数）的模式，这样效率高，否则libavcodec可能不得不对输入的数据进行拷。
(3)在一个循环体内去接收codec的输出，即周期性地调用avcodec_receive_*()来接收codec输出的数据。
解码：调用avcodec_receive_frame()，如果成功会返回一个包含未压缩数据的AVFrame。
编码：调用avcodec_receive_packet()，如果成功会返回一个包含压缩数据的AVPacket。
注意，这都是完整的包。
反复地调用avcodec_receive_packet()直到返回 AVERROR(EAGAIN)或其他错误。返回AVERROR(EAGAIN)错误表示codec需要新的输入来输出更多的数据。
对于每个输入的packet或frame，codec一般会输出一个frame或packet，但是也有可能输出0个或者多于1个，多个的情况也不少。
(4)注意:流处理结束的时候需要flush（冲刷） codec。因为codec可能在内部缓冲多个frame或packet，出于性能或其他必要的情况（如考虑B帧的情况）。 处理流程如下：
调用avcodec_send_*()传入的AVFrame或AVPacket指针设置为NULL。 这将进入draining mode（排水模式）。实时流应该不存在这些情况，除非输入流结束。
反复地调用avcodec_receive_*()直到返回AVERROR_EOF，该方法在draining mode时不会返回AVERROR(EAGAIN)的错误，除非你没有进入draining mode。
当重新开启codec时，需要先调用 avcodec_flush_buffers()来重置codec。
(5)编码或者解码刚开始的时候，codec可能接收了多个输入的frame或packet后还没有输出数据，直到内部的buffer被填充满。上面的使用流程可以处理这种情况。
(6)理论上，只有在输出数据没有被完全接收的情况调用avcodec_send_*()的时候才可能会发生AVERROR(EAGAIN)的错误。你可以依赖这个机制来实现区别于上面建议流程的处理方式，比如每次循环都调用avcodec_send_*()，在出现AVERROR(EAGAIN)错误的时候再去调用avcodec_receive_*()。
(7)并不是所有的codec都遵循一个严格、可预测的数据处理流程，唯一可以保证的是 “调用avcodec_send_*()/avcodec_receive_*()返回AVERROR(EAGAIN)的时候去avcodec_receive_*()/avcodec_send_*()会成功，否则不应该返回AVERROR(EAGAIN)的错误。”一般来说，任何codec都不允许无限制地缓存输入或者输出。
(8)在同一个AVCodecContext上混合使用新旧API是不允许的，这将导致未定义的行为。
4.avcodec_send_packet
函数：int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt);
作用：支持将裸流数据包送给解码器
注意:
(1)输入的avpkt-data缓冲区必须大于AV_INPUT_PADDING_SIZE，因为优化的字节流读取器必须一次读取32或者64比特的数据。
(2)不能跟之前的API(例如avcodec_decode_video2)混用，否则会返回不可预知的错误。
(3)在将包发送给解码器的时候，AVCodecContext必须已经通过avcodec_open2打开
参数：
avctx：解码上下文
avpkt：输入AVPakcet.通常情况下，输入数据是一个单一的视频帧或者几个完整的音频帧。调用者保留包的原有属性，解码器不会修改包的内容。解码器可能创建对包的引用。如果包没有引用计数将拷一份。跟以往的API不一样，输入的包的数据将被完全地消耗，如果包含有多个帧，要求多次调用avcodec_recvive_frame，直到avcodec_recvive_frame返回VERROR(EAGAIN)或AVERROR_EOF。输入参数可以为NULL，或者AVPacket的data域设置为NULL或者size域设置为0，表示将刷新所有的包，意味着数据流已经结束了。第一次发送刷新会总会成功，第二次发送刷新包是没有必要的，并且返回AVERROR_EOF,如果×××缓存了一些帧，返回一个刷新包，将会返回所有的解码包。
返回值：
0: 表示成功
AVERROR(EAGAIN)：当前状态不接受输入，用户必须先使用avcodec_receive_frame() 读取数据帧；
AVERROR_EOF：解码器已刷新，不能再向其发送新包；
AVERROR(EINVAL)：没有打开解码器，或者这是一个编码器，或者要求刷新；
AVERRO(ENOMEN)：无法将数据包添加到内部队列。
5.avcodec_receive_frame
函数：int avcodec_receive_frame ( AVCodecContext * avctx, AVFrame * frame )
作用：从解码器返回已解码的输出数据。
参数：
avctx: 编解码器上下文
frame: 获取使用reference-counted机制的audio或者video帧（取决于解码器类型）。请
注意，在执行其他操作之前，函数内部将始终先调用av_frame_unref(frame)。
返回值：
0: 成功，返回一个帧
AVERROR(EAGAIN): 该状态下没有帧输出，需要使用avcodec_send_packet发送新的packet到解码器。
AVERROR_EOF: 解码器已经被完全刷新，不再有输出帧
AVERROR(EINVAL): 编解码器没打开
其他<0的值: 具体查看对应的错误码。
注意：当剩余数据小于阈值时，需要处理，如下:
最终由AAC生成PCM格式:
可以看出这个PCM这个压缩率还是高，并且还能够保证比较好的音质。
本篇文章就分享到这里，欢迎关注，点赞，收藏，转发，如果需要测试代码，可以先关注，私信我。