在阅读本文前，如果关于音频有些知识不懂，可以看看前面的文章。
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这个压缩率还是高，并且还能够保证比较好的音质。
本篇文章就分享到这里，欢迎关注，点赞，收藏，转发，如果需要测试代码，可以先关注，私信我。