FFMPEG中关于avcodec库中相关注释的简单翻译

最近帮忙处理了下公司有关H264解码器中的问题，正好是在这个工具里面修改的，再加上好久都没有更新博客了，顺便刷下存在感，这三年忙懵了，趁着最近有时间，赶紧写点东西，吼吼~~

主要就是大概翻译了下关键的注释部分，其余的不太重要的部分我没太转义，直接大白话翻译过来了，建议大家看英文原版。

编码/解码基本步骤：
1、安装并打开AvcodecContext;
2、发送有效的输入：
   对于解码，调用avcodec_send_packet()传递给解码器一个包含压缩数据的AVPackage；
   对于编码，调用avcodec_send_frame()传递给编码器一个包含未压缩视频或音频数据的AVFrame；
   在这两种条件下，建议计数AVpackages与AVFrames，否则libavcodec可能会复制输入的数据（libavformat通常会返回计数的AVPackets，av_frame_get_buffer()分配计数的AVFrames）
3、循环接收输出，定期调用一个avcodec_receive_*()函数来处理它们的输出：
   对于解码，调用avcodec_receive_frame()，成功的话， 会返回一个包含未压缩视频与音频数据的AVFrame;
   对于编码，调用avcodec_receive_packet()，成功的话，会返回一个包含压缩帧数据的AVPackage;
   重复调用，直到返回AVERROR(EAGAIN)或者一个错误。AVERROR(EAGAIN)表示需要新的输入数据才会产生新的输出，在这种条件下，继续发送输入。对于每个输入的帧或者分组，编解码器通常会返回一个输出的帧或分组，但是这个数字也可能会是0或者大于1。

在编解码开始时，编解码器会接收到很多帧/分组数据却没有返回一个帧数据，直到缓冲池数据溢出。如果按照上面的步骤操作，这种情况就会被透明地处理。

理论上，发送数据可以导致EAGAIN结果-只有在没有收到所有的输出时才会导致这个问题。你可以使用以下方案来构建除上述建议之外的替代解码或编码循环的方案。例如，你可以尝试在每次迭代时发送新输入，如果返回EAGAIN，则尝试接收输出。

流结束的情况下，需要刷新（也称之为排泄）编解码器，因为出于性能考虑编解码器可能在内部缓冲多个帧或者分组是不必要的（考虑B帧数据）
处理方式如下：
-代替有效的输入方式，发送NULL给avcodec_send_packet()(解码)或者avcodec_send_frame()(编码)函数，这会进入排泄模式；
-在循环中调用avcodec_receive_frame()(解码)或者avcodec_receive_packet()(编码)，直到返回AVERROR(EAGAIN)，除非忘记进入排泄模式，否则这些函数将不会返回AVERROR(EAGAIN)；
-可以再次恢复解码器之前，编解码器必须调用avcodec_flush_buffers()来重置；

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

并非所有编解码器都遵循严格且可预测的数据流;唯一的保证是一端发送/接收呼叫的AVERROR（EAGAIN）返回值意味着另一端的接收/发送呼叫将成功，或者至少不会因AVERROR（EAGAIN）而失败。 通常，没有编解码器将允许无限制地缓冲输入或输出。

这个API取代了以下遗留的功能：
-avcodec_decode_video2()与avcodec_decode_audio4():使用avcodec_send_packet（）将输入提供给解码器，然后使用avcodec_receive_frame（）在每个数据包之后接收解码帧。与旧的视频解码API不同，多个帧可能来自数据包。对于音频，通过部分解码分组将输入分组分成帧对于API用户变得透明。你永远不需要将AVPacket提供给API两次（除非它被AVERROR（EAGAIN）拒绝 - 然后没有从数据包中读取数据）。
此外，只需要发送一次刷新/排空数据包。

不允许在同一AVCodecContext上混合新旧函数调用，这会导致未定义的行为。

有些编解码器可能需要使用新的API; 使用旧API将在调用时返回错误。 所有编解码器都支持新API。