关于使用ffmpeg的一些牢骚

0
12

一、啰嗦几句

好几年不写博客了,一是工作计算机都加密了没法编辑提交;二是各种语言混用,什么都会就是什么都不会,delphi、c#、vb、python、c++要说我精通啥,啥也不精,所以不敢乱写。

最近做一个关于视频处理的项目,用到ffmpeg,实在是憋不住,在此记录一下摸索的过程。可以毫不夸张的说,网上关于ffmpeg的使用,大部分用命令行方式,调用api方式的很少,而且盲目抄袭甚盛,斗胆妄言,罪过罪过。

二、感谢

我是通过学习雷神的博客逐渐掌握了ffmpeg的一些东西,好歹把项目做完了,效果很好,在此向雷神由衷的表示感谢。雷神由浅入深的介绍了ffmpeg的使用方法,有理论有实践,可以说网上的很多文章很难与雷神媲美,而且国内这方面的文章太少了,这么多做视频方面的,怎么就没有这方面的优质文章,在此是个疑点。可惜的是雷神花费了大量时间开放自己的学习探索的心得,当逐步的到达核心地带时,戛然而止,雷神去世了,天妒英才呐。在此沉痛缅怀并致以崇高的敬意!

在本文中,没有直接可运行的代码,一是加密,无法拷贝;二是提倡动手实践,先把雷神的实例代码挨个学习调试,自会有极大的提高;

三、项目背景

核心一句话:接收高清视频流(H264+mp3 TS流),每30分钟存储一个mp4文件,相邻两个文件的播放要顺畅不能丢帧。为啥说是高清呢,30分钟文件就有5个G。

编程语言c++

四、踩过的坑

4.1进程方式

网上很多文章都是用命令行的,这种方式只能说测试还行,真正项目应用差点意思了,因为你要管理这个进程,他是个什么状态,你不知,但你又不能不管,关键做不到前后两个视频无缝衔接,咋整,鸡肋啊,做个测试、验证等可以,做项目不行。用api吧,资料太少,项目组意见不一,最后举个例子达成一致了,前面有个碉堡,我们明知道用手榴弹不行,还坚持让大家扔手榴弹,这是瞎耽误工夫;拿zha yao肯定行,但是有人得牺牲(扔手榴弹站在远处扔就行,zha yao包得有人扛到跟前),要想彻底解决就得用彻底的办法。所以很多时候我们缺少的就是沉下心的耐力和扛zha yao包的勇气,溃痈虽痛胜于养毒,把雷神用api的例子全部从头调试一遍,总结出流程,都需要哪些要素,时间基、采样率、音视频流是啥用来做啥,搞明白就完事了。

4.2 ffmpeg rtp

ffmpeg可以直接接收RTP,也有提供转换MP4的方法,要注意的是接收和处理放在一个线程中有问题,容易丢帧,因为UDP通信必须设置缓存大小,但是一旦处理堵住了,数据绝对会丢失。程序在现场长时间不间断运行,很难保证不出现丢帧的情况,经简单测试,直接抛弃该方式。

五、我的实现方法

1、使用UDP方式接收组播视频流,并写入文件中,文件按时间命名。

2、当检测到够30分钟时,停止写入当前文件,开始写入另一个文件。

3、通知视频转换线程,处理当前写完的文件。

4、视频转换线程,读取文件,

打开输入文件流(avformat_open_input),

创建输出上下文(avformat_alloc_output_context2),我们要根据文件转成mp4。

查找视频信息(avformat_find_stream_info),查找输入的码流:视频流、音频流、字幕流。

根据输入码流创建输出码流,流的参数拷贝就行(avcodec_parameters_copy),特别要注意的是输入输出流的时间基(time_base)。

打开输出流,写入文件头,设定一个文件结尾的阈值,当输入流剩余字节数小于该值时并且找到最后一个关键帧,则写入到输出流后,将剩余输入文件的结尾置换到下一个文件的开头中,这样前后两个文件无缝衔接,第一个文件最后一个关键帧是第二个文件开头的第一帧,所以无缝衔接了。

循环读取输入流(av_read_frame)根据流索引确定是音频还是视频流,如果是视频流写入文件的第一帧必须是关键帧。写入时特别注意音频和视频的pkt的时间(pts、dts、duration)需要根据自己的时间基重新换算(av_rescale_q_rnd),并记录第一帧的时间戳pts,换算后的pts和dts要减去第一帧的pts,这样每个文件播放就是从头开始了。写入输出流用av_interleaved_write_frame。

读取文件转换成mp4,在现场机器(高速缓存设备)上总共需要不到15秒钟。

六、最终效果

项目部署5个多月,内存(103M左右,峰值180M)、cpu(3%–8%),非常稳定,无异常崩溃退出,视频无马赛克、前后视频衔接很棒。

七、总结

坚持实践就是硬道理,无论什么职位、角色都不能眼高手低。

抄别人代码一千遍不如自己动手调一遍。

<

发布回复

请输入评论!
请输入你的名字