http://blog.chinaunix.net/u3/94873/article_109981_1.html

为什么需要两个库文件 libavformat 和 libavcodec ：许多视频文件格式（AVI就是一个{zh0}的例子）实际上并没有明确指出应该使用哪种编码来解析音频和视频数据；它们只是定义了音频流和视频流（或者，有可 能是多个音频视频流）如何被绑定在一个文件里面。这就是为什么有时候，当你打开了一个AVI文件时，你只能听到声音，却不能看到图象－－因为你的系统没有 安装合适的视频解码器。所以， libavformat 用来处理解析视频文件并将包含在其中的流分离出来， 而libavcodec 则处理原始音频和视频流的解码。

打开视频文件：
首先{dy}件事情－－让我们来看看怎样打开一个视频文件并从中得到流。我们要做的第 一件事情就是初始化libavformat/libavcodec:

av_register_all();
这一步注册库中含有的 所有可用的文件格式和编码器，这样当打开一个文件时，它们才能够自动选择相应的文件格式和编码器。要注意你只需调用一次 av_register_all()，所以，尽可能的在你的初始代码中使用它。如果你愿意，你可以仅仅注册个人的文件格式和编码，不过，通常你不得不这么 做却没有什么原因。

下一步，打开文件：
AVFormatContext *pFormatCtx;
const char      *filename="myvideo.mpg";
// 打开视频文件
if(av_open_input_file(&pFormatCtx, filename, NULL, 0, NULL)!=0)
  handle_error(); // 不能打开此文件


{zh1}三个参数描述了文件格式，缓冲区大小（size）和格式参数；我们通过简单地指明NULL或0告诉 libavformat 去自动探测文件格式并且使用默认的缓冲区大小。请在你的程序中用合适的出错处理函数替换掉handle_error()。
下 一步，我们需要取出包含在文件中的流信息：
// 取出流信息
if(av_find_stream_info(pFormatCtx)<0)
  handle_error(); // 不能够找到流信息

这一步会用有效的信息把 AVFormatContext 的流域（streams field）填满。作为一个可调试的诊断，我们会将这些信息全盘输出到标准错误输出中，不过你在一个应用程序的产品中并不用这么做：
dump_format(pFormatCtx, 0, filename, false);

就像在引言中提到的那样，我们仅仅处理视频流，而不是音频流。为了让这件事情更容易理解，我 们只简单使用我们发现的{dy}种视频流：

int            i, videoStream;
AVCodecContext *pCodecCtx;
//  寻找 {dy}个视频流
videoStream=-1;
for(i=0; i<pFormatCtx->nb_streams; i++)
  if(pFormatCtx->streams->codec.codec_type==CODEC_TYPE_VIDEO)
  {
      videoStream=i;
      break;
  }
if(videoStream==-1)
  handle_error(); // Didn't find a video stream

// 得到视频流编码上下文的指针
pCodecCtx=&pFormatCtx->streams[videoStream]->codec;

好 了，我们已经得到了一个指向视频流的称之为上下文的指针。但是我们仍然需要找到真正的编码器打开它。

AVCodec *pCodec;

//  寻 找视频流的解码器
pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
if(pCodec==NULL)
  handle_error(); // 找不到解码器

// 通知解码器我们能够处理截断的bit流－－ie，
// bit流帧边界可以在包中
if(pCodec->capabilities & CODEC_CAP_TRUNCATED)
  pCodecCtx->flags|=CODEC_FLAG_TRUNCATED;

// 打开解码器
if(avcodec_open(pCodecCtx, pCodec)<0)
  handle_error(); // 打不开解码器

（那么什么是 “截断bit流”？好的，就像一会我们看到的，视频流中的数据是被分割放入包中的。因为每个视频帧的数据的大小是可变的，那么两帧之间的边界就不一定刚好 是包的边界。这里，我们告知解码器我们可以处理bit流。）


存储在 AVCodecContext结构中的一个重要的信息就是视频帧速率。为了允许非整数的帧速率（比如 NTSC的  29.97 帧），速率以分数的形式存储，分子在 pCodecCtx->frame_rate，分母在 pCodecCtx->frame_rate_base 中。在用不同的视频文件测试库时，我注意到一些编码器（很显然ASF）似乎并不能正确的给予赋值（ frame_rate_base 用1代替1000）。下面给出修复补丁：

//  加入这句话来纠正某些编码器产生的帧速错误
if(pCodecCtx->frame_rate>1000 && pCodecCtx->frame_rate_base==1)
  pCodecCtx->frame_rate_base=1000;

注意即使将来这个bug解决了，留下这几句话也并没有什么坏 处。视频不可能拥有超过1000fps的帧速。

只剩下一件事情要做了：给视频帧分配空间以便存储解码后的图片：

AVFrame *pFrame;

pFrame=avcodec_alloc_frame();

就这样，现在我们开始解码这些视频。

解 码视频帧
就像我前面提到过的，视频文件包含数个音频和视频流，并且他们各个独自被分开存储在固定大小的包里。我们要做的就是使用 libavformat依次读取这些包，过滤掉所有那些视频流中我们不感兴趣的部分，并把它们交给 libavcodec 进行解码处理。在做这件事情时，我们要注意这样一个事实，两帧之间的边界也可以在包的中间部分。
听起来很复杂？幸运的是，我们在一个例程中封装了 整个过程，它仅仅返回下一帧：

bool GetNextFrame(AVFormatContext *pFormatCtx, AVCodecContext *pCodecCtx,
  int videoStream, AVFrame *pFrame)
{
  static AVPacket packet;
  static int      bytesRemaining=0;
  static uint8_t  *rawData;
  static bool     fFirstTime=true;
  Int bytesDecoded;
  Int frameFinished;

//  我 们{dy}次调用时，将 packet.data 设置为NULL指明它不用释放了
  if(fFirstTime)
  {
      fFirstTime=false;
      packet.data=NULL;
  }

// 解码直到成功解码完整的一帧
  while(true)
  {
       //  除非解码完毕，否则一直在当前包中工作
      while(bytesRemaining > 0)
      {
      //  解码下一块数 据
          bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame,
              &frameFinished, rawData, bytesRemaining);

              // 出错了？
          if(bytesDecoded < 0)
          {
              fprintf(stderr, "Error while decoding frame\n");
              return false;
          }

          bytesRemaining-=bytesDecoded;
          rawData+=bytesDecoded;

              // 我们完成当前帧了吗？接着我们返回
          if(frameFinished)
              return true;
      }

      // 读取下一包，跳过所有不属于这个流的包
      do
      {
          // 释放旧的包
          if(packet.data!=NULL)
              av_free_packet(&packet);

          // 读取新的包
          if(av_read_packet(pFormatCtx, &packet)<0)
              goto loop_exit;
      } while(packet.stream_index!=videoStream);

      bytesRemaining=packet.size;
      rawData=packet.data;
  }

loop_exit:

      // 解码{zh1}一帧的余下部分
  bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame, &frameFinished,
      rawData, bytesRemaining);

      // 释放{zh1}一个包
  if(packet.data!=NULL)
      av_free_packet(&packet);

  return frameFinished!=0;
}

现在，我们要做的就是在一个循环中，调用 GetNextFrame () 直到它返回false。还有一处需要注意：大多数编码器返回 YUV 420 格式的图片（一个亮度和两个色度通道，色度通道只占亮度通道空间分辨率的一半（译者注：此句原句为the chrominance channels samples at half the spatial resolution of the luminance channel））。看你打算如何对视频数据处理，或许你打算将它转换至RGB格式。（注意，尽管，如果你只是打算显示视频数据，那大可不必要这么做；查 看一下 X11 的 Xvideo 扩展，它可以在硬件层进行 YUV到RGB 转换。）幸运的是， libavcodec 提供给我们了一个转换例程 img_convert ，它可以像转换其他图象进行 YUV 和 RGB之间的转换。这样解码视频的循环就变成这样：

while(GetNextFrame(pFormatCtx, pCodecCtx, videoStream, pFrame))
{
  img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24, (AVPicture*)pFrame,
      pCodecCtx->pix_fmt, pCodecCtx->width, pCodecCtx->height);

  // 处理视频帧（存盘等等）
  DoSomethingWithTheImage(pFrameRGB);
}

RGB 图象pFrameRGB （AVFrame *类型）的空间分配如下：

AVFrame *pFrameRGB;
int     numBytes;
uint8_t *buffer;

// 分配一个AVFrame 结构的空间
pFrameRGB=avcodec_alloc_frame();
if(pFrameRGB==NULL)
  handle_error();

// 确认所需缓冲区大小并且分配缓冲区空间
numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
  pCodecCtx->height);
buffer=new uint8_t[numBytes];

// 在pFrameRGB中给图象位面赋予合适的缓冲区
avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
  pCodecCtx->width, pCodecCtx->height);

xx
好了，我们已经处理了我们的视 频，现在需要做的就是xx我们自己的东西：
// 释放 RGB 图象
delete [] buffer;
av_free(pFrameRGB);

// 释放YUV 帧
av_free(pFrame);

// 关闭解码器（codec）
avcodec_close(pCodecCtx);

// 关闭视频文件
av_close_input_file(pFormatCtx);

完成！
更新（2005年4月26 号）：有个读者提出：在 Kanotix （一个 Debian 的发行版）上面编译本例程，或者直接在 Debian 上面编译，头文件中avcodec.h 和avformat.h 需要加上前缀“ffmpeg”，就像这样：

#include <ffmpeg/avcodec.h>
#include <ffmpeg/avformat.h>

同样 的， libdts 库在编译程序时也要像下面这样加入进来：

g++ -o avcodec_sample.0.4.9 avcodec_sample.0.4.9.cpp \
  -lavformat -lavcodec -ldts -lz

 

几个月前，我写了一篇有关使用ffmpeg下libavformat 和 libavcodec库的文章。从那以来，我收到过一些评论，并且新的ffmpeg预发行版(0.4.9-pre1) 最近也要出来了，增加了对在视频文件中定位的支持，新的文件格式，和简单的读取视频帧的接口。这些改变不久就会应用到CVS中，不过这次是我{dy}次在发行 版中看到它们。（顺便感谢 Silviu Minut 共享长时间学习CVS版的ffmpeg的成果－－他的有关ffmpeg的信息和demo程序在这里。）

在这篇文章里，我仅仅会描述一下以 前的版本(0.4.8)和{zx1}版本之间的区别，所以，如果你是采用新的 libavformat / libavcodec ，我建议你读前面的文章。

首 先，说说有关编译新发行版吧。用我的编译器（ SuSE 上的 gcc 3.3.1 ），在编译源文件 ffv1.c 时会报一个编译器内部的错误。我怀疑这是个精简版的gcc－－我在编译 OpenCV 时也遇到了同样的事情－－但是不论如何，一个快速的解决方法就是在编译此文件时不要加优化参数。最简单的方法就是作一个make，当编译时遇到编译器错 误，进入 libavcodec 子目录（因为这也是 ffv1.c 所在之处），在你的终端中使用gcc命令去编译ffv1.c，粘贴，编辑删除编译器开关（译者注：就是参数）"-O3"，然后使用那个命令运行gcc。然 后，你可以变回ffmpeg主目录并且重新运行make，这次应该可以编译了。

都有哪些更新？
有那些更新呢？从一个程序员的角度 来看，{zd0}的变化就是尽可能的简化了从视频文件中读取个人的视频帧的操作。在ffmpeg 0.4.8 和其早期版本中，在从一个视频文件中的包中用例程av_read_packet()来读取数据时，一个视频帧的信息通常可以包含在几个包里，而另情况更为 复杂的是，实际上两帧之间的边界还可以存在于两个包之间。幸亏ffmpeg 0.4.9 引入了新的叫做av_read_frame()的例程,它可以从一个简单的包里返回一个视频帧包含的所有数据。使用av_read_packet()读取 视频数据的老办法仍然支持，但是不赞成使用－－我说：摆脱它是可喜的。

这里让我们来看看如何使用新的API来读取视频数据。在我原来的文 章中（与 0.4.8 API相关），主要的解码循环就像下面这样：

while(GetNextFrame(pFormatCtx, pCodecCtx, videoStream, pFrame))
{

  img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24, (AVPicture*)pFrame,
      pCodecCtx->pix_fmt, pCodecCtx->width, pCodecCtx->height);

  // 处理视频帧（存盘等等）
  DoSomethingWithTheImage(pFrameRGB);
}

GetNextFrame() 是个有帮助的例程，它可以处理这样一个过程，这个过程汇编一个完整的视频帧所需要的所有的包。新的API简化了我们在主循环中实际直接读取和解码数据的操 作：

while(av_read_frame(pFormatCtx, &packet)>=0)
{
  // 这是视频流中的一个包吗？
  if(packet.stream_index==videoStream)
  {
      // 解码视频流
      avcodec_decode_video(pCodecCtx, pFrame, &frameFinished,
          packet.data, packet.size);

      // 我们得到一帧了吗？
      if(frameFinished)
      {
          // 把原始图像转换成 RGB
          img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24,
              (AVPicture*)pFrame, pCodecCtx->pix_fmt, pCodecCtx->width,
              pCodecCtx->height);

          // 处理视频帧（存盘等等）
          DoSomethingWithTheImage(pFrameRGB);
      }
  }

  // 释放用av_read_frame分配空间的包
  av_free_packet(&packet);
}

看 {dy}眼，似乎看上去变得更为复杂了。但那仅仅是因为这块代码做的都是要隐藏在GetNextFrame()例程中实现的（检查包是否属于视频流，解码帧并 释放包）。总的说来，因为我们能够xx排除 GetNextFrame ()，事情变得更简单了。
我已经更新了demo程序使用{zx1}的API。简 单比较一下行数（老版本222行 Vs新版本169行）显示出新的API大大的简化了这件事情。

0.4.9的另一个重要的更新是能够在视 频文件中定位一个时间戳。它通过函数av_seek_frame() 来实现，此函数有三个参数：一个指向 AVFormatContext 的指针，一个流索引和定位时间戳。此函数在给定时间戳以前会去定位{dy}个关键帧。所有这些都来自于文档。我并没有对av_seek_frame()进行测 试，所以这里我并不能够给出任何示例代码。如果你成功的使用av_seek_frame() ，我很高兴听到这个消息。

捕获视频 (Video4Linux and IEEE1394)
Toru Tamaki 发给我了一些使用 libavformat / libavcodec 库从 Video4Linux 或者 IEEE1394 视频设备源中抓捕视频帧的样例代码。对 Video4Linux,调用av_open_input_file() 函数应该修改如下：
AVFormatParameters formatParams;
AVInputFormat *iformat;

formatParams.device = "/dev/video0";
formatParams.channel = 0;
formatParams.standard = "ntsc";
formatParams.width = 640;
formatParams.height = 480;
formatParams.frame_rate = 29;
formatParams.frame_rate_base = 1;
filename = "";
iformat = av_find_input_format("video4linux");

av_open_input_file(&ffmpegFormatContext,
               filename, iformat, 0, &formatParams);

For IEEE1394, call av_open_input_file() like this:

AVFormatParameters formatParams;
AVInputFormat *iformat;

formatParams.device = "/dev/dv1394";
filename = "";
iformat = av_find_input_format("dv1394");

av_open_input_file(&ffmpegFormatContext,
               filename, iformat, 0, &formatParams);