ffmpeg开发指南.docx
《ffmpeg开发指南.docx》由会员分享，可在线阅读，更多相关《ffmpeg开发指南.docx（16页珍藏版）》请在冰豆网上搜索。
ffmpeg开发指南
ffmpeg开发指南
lsosa2006-05-20
ffmpeg中的Libavformat和libavcodec库是访问大多数视频文件格式的一个很好的方法。
不幸的
是，在开发您自己的程序时，这套库基本上没有提供什么实际的文档可以用来作为参考（至少我没有找到
任何文档），并且它的例程也并没有太多的帮助。
这种情况意味着，当我在最近某个项U中需要用到1ibavformat/1ibavcodec库时，需要作很多试验来搞清楚怎样使用它们。
这里是我所学习的一一希望我做的这些能够帮助一些人，以免他们重蹈我的覆辙，
作同样的试验，遇到同样的错误。
你还可以从这里下载一个demo程序。
我将要公开的这部分代码需要0.4.8版本的ffmpeg库中的1ibavformat/1ibavcodec的支持（我正在写最新版本）。
如果您发现以后的版本
与我写的程序不能兼容，请告知我。
在这个文档里，我仅仅涉及到如何从文件中读入视频流；音频流使用儿乎同样的方法可以工作的很好，
不过，我并没有实际使用过它们，所以，我没于办法提供任何示例代码。
或许您会觉得奇怪，为什么需要两个库文件1ibavformat和1ibavcodec：
许多视频文件格式（AVI就是一个最好的例子）实际上并没有明确指出应该使用哪种编码来解析音频和视频数据；它们只是定义了
音频流和视频流（或者，有可能是多个音频视频流）如何被绑定在一个文件里面。
这就是为什么有时候,
当你打开了一个AVI文件时，你只能听到声音，却不能看到图象一一因为你的系统没有安装合适的视频解码器。
所以，libavformat用来处理解析视频文件并将包含在其中的流分离出来，而libavcodec则处理原始音频和视频流的解码。
打开视频文件：
首先第一件事情一一让我们来看看怎样打开一个视频文件并从中得到流。
我们要做的第一件事情就是初始
化libavformat/libavcodec：
av_register_all（）;
这一步注册库中含有的所有可用的文件格式和编码器，这样当打开一个文件时，它们才能够自动选择相应
的文件格式和编码器。
要注意你只需调用一次av_register_all（）,所以，尽可能的在你的初始代码中使
用它。
如果你愿意，你可以仅仅注册个人的文件格式和编码，不过，通常你不得不这么做却没有什么原因。
下一步，打开文件：
AVFormatContext*pFormatCtx;
constchar*filename=，，myvideo.mpg/z:
//打开视频文件
if（av_open_input_file（&pFormatCtx,filename,NULL,0,NULL）!
=0）handle_error（）;//不能打开此文件
最后三个参数描述了文件格式，缓冲区大小（size）和格式参数；我们通过简单地指明NULL或0告诉
libavformat去自动探测文件格式并且使用默认的缓冲区大小。
请在你的程序
中用合适的出错处理函数替
换掉handle_error（）。
下一步，我们需要取出包含在文件中的流信息：
//取出流信息
if（av_find_stream_info（pFormatCtx）<0）
handle_error（）;//不能够找到流信息
这一步会用有效的信息把AVFormatContext的流域（streamsfield）填满。
作为一个可调试的诊断，我
们会将这些信息全盘输出到标准错误输出中，不过你在一个应用程序的产品中并不用这么做：
dump_format（pFormatCtx,0,filename,false）;
就像在引言中提到的那样，我们仅仅处理视频流，而不是音频流。
为了让这件事情更容易理解，我们只简
单使用我们发现的笫一种视频流：
inti,videoStream;
AVCodecContext*pCodecCtx;
//寻找第一个视频流
videoStreanpT;
for（i=0;inb_strearns;i++）
辻（pFormatCtx-〉streams-〉codec.codec_type二二CODEC_TYPE_VIDEO）
{
videoStream=i;
break;
}
if（videoStream~-l）
handle_error（）:
//Didn,tfindavideostream
//得到视频流编码上下文的指针
pCodecCtx=&pFormatCtx->streams[videoStream]->codec;
好了，我们已经得到了一个指向视频流的称之为上下文的指针。
但是我们仍然需要找到真正的编码器打开
它。
AVCodec*pCodec;
//寻找视频流的解码器
pCodec=avcodec_find_decoder（pCodecCtx->codec_id）;if（pCodec=NULL）
handle_error（）:
//找不到解码器
//通知解码器我们能够处理截断的bit流一一ie,//bit流帧边界可以在包中
辻（pCodec->capabCities&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=l）pCodecCtx~>frame_rate_base=1000;
注意即使将来这个bu名解决了，留下这儿句话也并没有什么坏处。
视频不可能拥有超过lOOOfps的帧速。
只剩下一件事情要做了：
给视频帧分配空间以便存储解码后的图片：
AVFrame*pFrame;
pFrame=avcodec_alloc_frame（）;
就这样，现在我们开始解码这些视频。
解码视频帧
就像我前面提到过的，视频文件包含数个音频和视频流，并且他们各个独自被分开存储在固定大小的包里。
我们要做的就是使用libdvformat依次读取这些包，过滤掉所有那些视频流中
我们不感兴趣的部分，并把
它们交给libavcodec进行解码处理。
在做这件事情时，我们要注意这样一个
事实，两帧之间的边界也可
以在包的中间部分。
听起来很复杂？
幸运的是，我们在一个例程中封装了整个过程，它仅仅返回下一帧：
boolGetNextFrame（AVFormatContext*pFormatCtx,AVCodecContext
*pCodecCtx,
intvideoStream,AVFrame*pFrame）
staticAVPacketpacket;
staticintbytesRemaining=O;
staticuint8_t*rawData;
staticboolfFirstTime二true;
IntbytesDecoded;
IntframeFinished;
//我们笫一次调用时，将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,"Errorwhiledecodingframe\n，z）:
returnfalse;
}
bytesRemaining-=bytesDecoded;rawData+=bytesDecoded;
//我们完成当前帧了吗？
接着我们返回
if（frameFinished）
returntrue;
}
//读取下一包，跳过所有不属于这个流的包
do
{
//释放旧的包
if（packet・data!
=NULL）
av_free_packet（&packet）;
//读取新的包
if（av_read_packet（pFormatCtx,&packet）<0）
gotoloop_exit;
}while（packet・stream_index!
=videoStream）;
bytesRemaining=packet・size;
rawData=packet・data;
}
loop_exit:
//解码最后一帧的余下部分
bytesDecoded=avcodec_decode_video（pCodecCtx,pFrame,AframeFinished,rawData,bytesRemaining）;
//释放最后一个包
if（packet・data!
=NULL）
av_free_packet（&packet）;
returnframeFinished!
=0:
}
现在，我们要做的就是在一个循环中，调用GetNextFrame（）直到它返回falseo还有一处需要注意：
大多数编码器返回YUV420格式的图片（一个亮度和两个色度通道，色度通道只占亮度通道空间分辨率
的一半（译者注：
此句原句为thechrominancechannelssamplesathalfthespatialresolutionof
theluminancechannel））。
看你打算如何对视频数据处理，或许你打算将它转换至RGB格式。
（注意，尽管，如果你只是打算显示视频数据，那大可不必要这么做;查看一下XII的Xvideo扩展，它可以在硬件层进行YUV到RGB转换。
）幸运的是，1让avcodec提供给我们了一个转换例程img_convert,它
可以像转换其他图象进行YUV和RGB之间的转换。
这样解码视频的循环就变成这样：
while（GetNextFrame（pFormatCtx,pCodecCtx,videoStream,pFrame））{
img_convert（（AVPicture*）pFrameRGB,PIX_FMT_RGB24,
（A\Ticture*）pFrame,
pCodecCtx->pix_fmt,pCodecCtx-〉width,pCodecCtx~>height）;
//处理视频帧（存盘等等）
DoSomethingWithThelmage（pFrameRGB）;
}
RGB图象pFrameRGB（AVFrame*类型）的空间分配如下：
AVFrame*pFrameRGB:
intnumBytes;
uint8_t*buffer;
//分配一个AVFrame结构的空间
pFrameRGB=avcodec_alloc_frame（）;
辻（pFwmeRGB二二NULL）
handle^error（）;
//确认所需缓冲区大小并且分配缓冲区空间
numBytes=avpicture_get_size（PIX_FMT_RGB24,pCodecCtx-〉width,pCodecCtx->height）;
buffer=newuint8_t[numBytes];
//在pFrameRGB中给图象位面赋予合适的缓冲区
avpicture_f订1（（AVPicture♦）pFrameRGB,buffer,PIX_FMT_RGB24,pCodecCtx-〉width,pCodecCtx-〉height）;
清除
好了，我们已经处理了我们的视频，现在需要做的就是清除我们自己的东西:
//释放RGB图象
delete[]buffer;
av_free（pFrameRGB）;
//释放YUV帧
av_free（pFrame）;
//关闭解码器（codec）
avcodec_close（pCodecCtx）;
//关闭视频文件
av_c1ose_input_file（pFormatCtx）;
完成！
更新（2003年4月26号）：
有个读者提出：
在Kanotix（一个Debian的发行版）上面编译本例程，或者直接在Debian上面编译，头文件中avcodec.h和avformat.h需要加上前缀“ffmpeg”，就像这样：
^include
^include
同样的，libdts库在编译程序时也要像下面这样加入进来：
g++-oavcodec_sample.0.4.9avcodec_sample.0.4.9.cpp\
-1avformat-lavcodec-ldts-lz
儿个月前，我写了—篇有关使用ffmpeg下libavformat和libavcodec库的文章。
从那以来，我收到过一些评论，并且新的ffmpeg预发行版（0.4.9-prel）最近也要出来了，增加了对在视频文件中定位的支持，
新的文件格式，和简单的读取视频帧的接口。
这些改变不久就会应用到CVS中，不过这次是我第一次在发行版中看到它们。
（顺便感谢SilviuMinut共享长时间学习CVS版的ffmpeg的成果他的有关ffmpeg
的信息和dem。
程疗;在这里。
）
在这篇文章里，我仅仅会描述一下以前的版本（0.4.8）和最新版本之间的区别，所以，如果你是采用新的libavformat/libavcodec,我建议你读前面的文章。
首先，说说有关编译新发行版吧。
用我的编译器（SuSE上的gcc
3.3.1）,在编译源文件ffvl.c时会报一个编译器内部的错误。
我怀疑这是个精简版的呂cc一一我在编译OpenCV时也遇到了同样的事悄一一但是不论如何，一个快速的解决方法就是在编译此文件时不要加优化参数。
最简单的方法就是作一个make,当编译时遇到编译器错误，进入libavcodec子目录（因为这也是ffvl.c所在之处），在你的终端中使用gcc命令去编译ffvl.c,粘贴，编辑删除编译器开关（译者注：
就是参数）〃-03〃，然后使用那个命令运行gcc。
然后，你可以变回ffmpeg主目录并且重新运行make,这次应该可以编译了。
都有哪些更新？
有那些更新呢？
从一个程序员的角度来看，最大的变化就是尽可能的简化了从视频文件中读取个人的视频
帧的操作。
在ffmpeg0.4.8和其早期版本中，在从一个视频文件中的包中用例程av_read_packet（）来读取数据时，一个视频帧的信息通常可以包含在儿个包里，而另情况更为复杂的是，实际上两帧之间的边界还可以存在于两个包之间。
幸亏ffmpeg0.4.9引入了新的叫做av_read_frame（）的例程,它可以从一个简单的包里返回一个视频帧包含的所有数据。
使用av_read_packet（）读取视频数据的老办法仍然支持，但
是不赞成使用一一我说：
摆脱它是可喜的。
这里让我们来看看如何使用新的API来读取视频数据。
在我原来的文章中（与
0.4.8API相关），主要的解码循环就像下面这样：
while（GetNextFrame（pFormatCtx,pCodecCtx,videoStream,pFrame））
{
img_convert（（AVTicture*）pFrameRGB,PIX_FMT_RGB24,（AVPicture*）pFrame,
pCodecCtx~>pix_fmt,pCodecCtx->width,pCodecCtx->height）;
//处理视频帧（存盘等等）
DoSomethingWithThelmage（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（（AVTicture*）pFrameRGB,PIX_FMT_RGB24,
（AVPicture*）pFrame,pCodecCtx->pix_fmt,pCodecCtx-〉width,pCodecCtx~>height）;
//处理视频帧（存盘等等）
DoSomethingWithThelmage（pFrameRGB）;
}
}
//释放用av_read_frame分配空间的包
av_free_packet（&packet）;
}
看第一眼，似乎看上去变得更为复杂了。
但那仅仅是因为这块代码做的都是要隐藏在GetNextFrameO例程中实现的（检查包是否属于视频流，解码帧并释放包）。
总的说来，因为我们能够完全排除GetNextFrame（）,事情变得更简单了。
我已经更新了demo程序使用最新的API。
简单比较一下行数（老版本222行Vs新版本169行）显示出新的API大大的简化了这件事情。
0.4.9的另一个重要的更新是能够在视频文件中定位一个时间戳。
它通过函数av_seek_frame（）来实现，此函数有三个参数：
一个指向AVFormatContext的指针，一个流索引和定位时间戳。
此函数在给定时间
戳以前会去定位笫一个关键帧。
所有这些都来自于文档。
我并没有对av_seek_frame（）进行测试，所以这里我并不能够给出任何示例代码。
如果你成功的使用av_seek_frame（）,我很高兴听到这个消息。
捕获视频（Video4LinuxandIEEE1394）
ToruTamaki发给我了一些使用libavformat/libavcodec库从Video4Linux或者IEEE1394视频设备源中抓捕视频帧的样例代码。
对Video4Linux,调用av_open_input_file（）函数应该修改如下：
AVFormatParametersformatParams;
AVInputFormat*iformat;formatParams.device="/dev/videoO";
formatParams.channel=0;
formatParams.standard="ntsc";
formatParams・width=640;
formatParams.height=480;
formatParams・frame_rate=29;
formatParams・frameratebase=1:
filename="”；
iformat=av_find_input_format（，zvideo41inux，z）;
av_open_input_file（&ffmpegFormatContext,
filename,iformat,0,&formatParams）;
ForIEEE1394,callav_open_input_file（）likethis:
AVFormatParametersformatParams;
AVInputFormat*iformat;
formatParams.device="7dev/dvl394";
filename=
iformat=av_find_input_format（z/dvl394/z）;
av_open_input_file（&ffmpegFormatContext,filename,iformat,0,&fo:
nnatPa:
ranis）;继续。
。
。
如果我碰巧遇到了一些有关libavformat/libavcodec的有趣的信息，我计
划在这里公布。
所以，如果你有任何的评论，请通过这篇文章顶部给出的地址联系我。
标准弃权：
我没有责任去纠正这些代码的功能和这篇文章中涉及的技术。
时间戳
媒体内容在播放时，最令人头痛的就是音视频不同步。
从技术上来说，解决音
频同步问题的最佳方案就是时间戳：
首先选择一个参考时钟（要求参考时钟上的
时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上
时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，
同
时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考
时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；
如
果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者
索性将这块数据“丢弃”，以使播放进度追上参考时钟）。
可见，避免音视频不同步现象有两个关键一一一是在生成数据流时要打上正
确的时间戳。
如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也
于
事无补。
假如，视频流内容是从Os开始的，假设10s时有人开始说话，要求配上音频流，那么音频流的起始时间应该是10s,如果时间戳从Os或其它时间开
始打,
则这个混合的音视频流在时间同步上本身就出了问题。
打时间戳时，视频流和
频流都是参考参考时钟的时间，而数据流之间不会发生参考关系：
也就是说，视
频
流和音频流是通过一个中立的第三方（也就是参考时钟）来实现同步的。
第二个
关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或
晚
到采取
升级会员 