视频编解码FFMPEGWord文档格式.docx
- 文档编号:21964056
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:10
- 大小:20.79KB
视频编解码FFMPEGWord文档格式.docx
《视频编解码FFMPEGWord文档格式.docx》由会员分享,可在线阅读,更多相关《视频编解码FFMPEGWord文档格式.docx(10页珍藏版)》请在冰豆网上搜索。
AVFormatContext*pFormatCtx;
constchar*filename="
myvideo.mpg"
;
//打开视频文件
if(av_open_input_file(&
pFormatCtx,filename,NULL,0,NULL)!
=0)
handle_error();
//不能打开此文件
最后三个参数描述了文件格式,缓冲区大小(size)和格式参数;
我们通过简单地指明NULL
或0下一步,我们需要取出包含在文件中的流信息:
//取出流信息
if(av_find_stream_info(pFormatCtx)<
0)
//不能够找到流信息
这一步会用有效的信息把AVFormatContext的流域(streamsfield)填满。
作为一个可调试的诊断,我们会将这些信息全盘输出到标准错误输出中,不过你在一个应用程序的产品中并不用这么做:
dump_format(pFormatCtx,0,filename,false);
就像在引言中提到的那样,我们仅仅处理视频流,而不是音频流。
为了让这件事情更容易理解,我们只简单使用我们发现的第一种视频流:
inti,videoStream;
AVCodecContext*pCodecCtx;
//寻找第一个视频流
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)
//Didn'
tfindavideostream
//得到视频流编码上下文的指针
pCodecCtx=&
streams[videoStream]->
codec;
好了,我们已经得到了一个指向视频流的称之为上下文的指针。
但是我们仍然需要找到真正的编码器打开它。
AVCodec*pCodec;
//寻找视频流的解码器
pCodec=avcodec_find_decoder(pCodecCtx->
codec_id);
if(pCodec==NULL)
//找不到解码器
//通知解码器我们能够处理截断的bit流,,ie,
//bit流帧边界可以在包中
if(pCodec->
capabilities&
CODEC_CAP_TRUNCATED)
pCodecCtx->
flags|=CODEC_FLAG_TRUNCATED;
//打开解码器
if(avcodec_open(pCodecCtx,pCodec)<
//打不开解码器
(那么什么是“截断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)
frame_rate_base=1000;
注意即使将来这个bug解决了,留下这几句话也并没有什么坏处。
视频不可能拥有超过1000fps的帧速。
只剩下一件事情要做了:
给
AVFrame*pFrame;
pFrame=avcodec_alloc_frame();
就这样,现在我们开始解码这些视频。
解码视频帧
就像我前面提到过的,视频文件包含数个音频和视频流,并且他们各个独自被分开存储在固定大小的包里。
我们要做的就是使用libavformat依次读取这些包,过滤掉所有那些视频流中我们不感兴趣的部分,并把它们交给libavcodec进行解码处理。
在做这件事情时,我们要注意这样一个事实,两帧之间的边界也可以在包的中间部分。
听起来很复杂,幸运的是,我们在一个例程中封装了整个过程,它仅仅返回下一帧:
boolGetNextFrame(AVFormatContext*pFormatCtx,AVCodecContext*pCodecCtx,
intvideoStream,AVFrame*pFrame){
staticAVPacketpacket;
staticintbytesRemaining=0;
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<
fprintf(stderr,"
Errorwhiledecodingframe\n"
);
returnfalse;
bytesRemaining-=bytesDecoded;
rawData+=bytesDecoded;
//我们完成当前帧了吗,接着我们返回
if(frameFinished)
returntrue;
//读取下一包,跳过所有不属于这个流的包
do
//释放旧的包
if(packet.data!
=NULL)
av_free_packet(&
packet);
//读取新的包
if(av_read_packet(pFormatCtx,&
packet)<
gotoloop_exit;
}while(packet.stream_index!
=videoStream);
bytesRemaining=packet.size;
rawData=packet.data;
loop_exit:
//解码最后一帧的余下部分
bytesDecoded=avcodec_decode_video(pCodecCtx,pFrame,&
frameFinished,
rawData,bytesRemaining);
//释放最后一个包
returnframeFinished!
=0;
现在,我们要做的就是在一个循环中,调用GetNextFrame()直到它返回false。
还有一处
需要注意:
大多数编码器返回YUV420格式的图片(一个亮度和两个色度通道,色度通道只
占亮度通道空间分辨率的
while(GetNextFrame(pFormatCtx,pCodecCtx,videoStream,pFrame))
img_convert((AVPicture*)pFrameRGB,PIX_FMT_RGB24,(AVPicture*)pFrame,
pix_fmt,pCodecCtx->
width,pCodecCtx->
height);
//处理视频帧(存盘等等)
DoSomethingWithTheImage(pFrameRGB);
RGB图象pFrameRGB(AVFrame*类型)的空间分配如下:
AVFrame*pFrameRGB;
intnumBytes;
uint8_t*buffer;
//分配一个AVFrame结构的空间
pFrameRGB=avcodec_alloc_frame();
if(pFrameRGB==NULL)
//确认所需缓冲区大小并且分配缓冲区空间
numBytes=avpicture_get_size(PIX_FMT_RGB24,pCodecCtx->
width,
buffer=newuint8_t[numBytes];
//在pFrameRGB中给图象位面赋予合适的缓冲区
avpicture_fill((AVPicture*)pFrameRGB,buffer,PIX_FMT_RGB24,
清除
好了,我们已经处理了我们的视频,现在需要做的就是清除我们自己的东西:
//释放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>
ffmpeg/avformat.h>
同样的,libdts库在编译程序时也要像下面这样加入进来:
g++-oavcodec_sample.0.4.9avcodec_sample.0.4.9.cpp\
-lavformat-lavcodec-ldts-lz
几个月前,我写了一篇有关使用ffmpeg下libavformat和libavcodec库的文章。
从那以来,我收到过一些评论,并且新的ffmpeg预发行版(0.4.9-pre1)最近也要出来了,增加了对在视频文件中定位的支持,新的文件格式,和简单的读取视频帧的接口。
这些改变不久就会应用到CVS中,不过这次是我第一次在发行版中看到它们。
(顺便感谢SilviuMinut共享长时间学习CVS版的ffmpeg的成果,,他的有关ffmpeg的信息和demo程序在这里。
在这篇文章里,我仅仅会描述一下以前的版本(0.4.8)和最新版本之间的区别,所以,首先,说说有关编译新发行版吧。
用我的编译器(SuSE上的gcc3.3.1),在编译源文件ffv1.c时会报一个编译器内部的错误。
我怀疑这是个精简版的gcc,,我在编译OpenCV时也遇到了同样的事情,,但是不论如何,一个快速的解决方法就是在编译此文件时不要加优化参数。
最简单的方法就是作一个make,当编译时遇到编译器错误,进入libavcodec子目录(因为这也是ffv1.c所在之处),在你的终端中使用gcc命令去编译ffv1.c,粘贴,编辑删除编译器开关(译者注:
就是参数)"
-O3"
,然后使用那个命令运行gcc。
然后,你可以变回ffmpeg主目录并且重新运行make,这次应该可以编译了。
都有哪些更新,
有那些更新呢,从一个程序员的角度来看,最大的变化就是尽可能的简化了从视频文件中读取个人的视频帧的操作。
在f文件fmpeg0.4.8和其早期版本中,在从一个视频中的包中用例程av_read_packet()来读取数据时,一个视频帧的信息通常可以包含在几个包里,而另情况更为复杂的是,实际上两帧之间的边界还可以存在于两个包之间。
幸亏ffmpeg0.4.9引入了新的叫做av_read_frame()的例程,它可以从一个简单的包里返回一个视频帧包含的所有数据。
使用av_read_packet()读取视频数据的老办法仍然支持,但是不赞成使用,,我说:
摆脱它是可喜的。
这里让我们来看看如何使用新的API来读取视频数据。
在我原来的文章中(与0.4.8API相关),主要的解码循环就像下面这样:
while(GetNextFrame(pFormatCtx,pCodecCtx,videoStream,pFrame)){
GetNextFrame()是个有帮助的例程,它可以处理这样一个过程,这个过程汇编一个完整的视
频帧所需要的所有的包。
新的API简化了我们在主循环中实际直接读取和解码数据的操作:
while(av_read_frame(pFormatCtx,&
packet)>
//这是视频流中的一个包吗,
if(packet.stream_index==videoStream)
//解码视频流
avcodec_decode_video(pCodecCtx,pFrame,&
packet.data,packet.size);
//我们得到一帧了吗,
//把原始图像转换成RGB
img_convert((AVPicture*)pFrameRGB,PIX_FMT_RGB24,
(AVPicture*)pFrame,pCodecCtx->
//释放用av_read_frame分配空间的包
看第一眼,似乎看上去变得更为复杂了。
但那仅仅是因为这块代码做的都是要隐藏在GetNextFrame()例程中实现的(检查包是否属于视频流,解码帧并释放包)。
总的说来,因为我们能够完全排除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/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);
ForIEEE1394,callav_open_input_file()likethis:
/dev/dv1394"
dv1394"
继续。
。
如果我碰巧遇到了一些有关libavformat/libavcodec的有趣的信息,我计划在这里公布。
所以,如果你有任何的评论,请通过这篇文章顶部给出的地址联系我。
标准弃权:
我没有责任去纠正这些代码的功能和这篇文章中涉及的技术。
/*---------------------------------------------------------------------------------*/
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 视频 解码 FFMPEG
![提示](https://static.bdocx.com/images/bang_tan.gif)