内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

FFmpeg开发中的坑起坑落

2017-11-08 11:02 出处:清屏网 人气: 评论(0

对于FFmpeg每一个从事音视频开发的小伙伴都不会感到陌生,它可以说涵盖了音视频开发中绝大多数的领域,不过在FFmpeg开发中也会遇到可移植性、转码压缩音视频不同步、多线程编解码等等问题,本文是“大师兄”刘歧在LiveVideoStack Meet北京站上的分享,他将与大家分享FFmpeg实践开发中遇到的技术难点和经验。

谢谢大家,谢谢主持人,因为今天时间有限,所以就简单的介绍一些套路。先做下自我介绍,我是一个音视频流媒体的爱好者,目前和几个朋友一起成立了公司,专门做音视频编解码处理,当然不是做编码器,是专门做在线处理。此外我是FFmpeg的维护者之一,再就是以前玩过嵌入式处理,是从44B0开始的;也做过存储,参与开发过广电的大规模存储;在中科创达专门做手机时做过设备驱动开发;也做过一些流媒体,当时主要基于高通平台;之后去蓝讯之后开始做流媒体系统设计,当时担任流媒体架构师,主要是做直播部分。

在正式开始前,跟大家分享一组图片,第一个是现实世界色彩风格的我,第二个是泰坦尼克色彩风格的我,第三个是斯巴达克斯色彩风格的我,三种不同的风格,这个是我前两天调色彩风格时专门生成的一套模板,所有的视频处理完成之后,你会得到各种各样的效果。

我今天要分享的主题前面也有提到,整体内容大概会分为五部分,首先是基础介绍,然后会大致分享做FFmpeg开发的规则,开发过程中遇到的坑,以及面对这些坑如何分析问题,最后我会做一个简单的总结。

基础介绍

  • 基本概念

什么是压缩,很多人都会遇到过客户要求把MP4转码成FLV,但如果里边是H.264的话是不需要去做转码的,只需要做remux,也就是转封装即可,那封装是什么?我们用一个很生动的例子来说明——液化气罐,它就是一个封装,它里面装的是咱们压缩的东西,可以理解为里面装的是H.264,如果我把开关打开之后,里面的水将会变成气体,这个气体可以理解为咱们看到的YUV或者PCM,这些数据量是很大的,然后做一些压缩,把它装到一个封装里面,这个封装就是液化气罐,我们把液化气罐砸了就是个解封装的过程。

在现实生活中,我们看一些视频或者是做一些编解码处理的时候会遇到一些问题,比如说看到这张图片,这个是从封装里面解耦气体的时候出现了异常,但这个异常又不是特别严重,那么出现的现象就是右边花屏的状态,这样的情况顶多是丢了一帧,还没有导致严重的错误。

如果再稍微过分一点,它就会导致成上图显示的现象——播放器基本已经没法用了,你需要有两种处理方式,当然不可能是拿水往电脑上泼,那么这张图上的处理方式就是播放器自动帮你处理——退出、崩溃。这里不得不提到FFmpeg中fatal error跟error两者的区别,我们前面看到的第一张图就是一个error,也就是说虽然出错了,但是还能继续去处理下一个包;但如果要是遇到了fatal error,比如说没有idr帧,它的帧整个都是乱序的,或者是播放器的Buffer已经溢出了,或者是干脆无法解码,这个时候它就是一个fatal error,播放器就会退出来了。

  • FFmpeg常用功能&软件

大概介绍一下FFmpeg,其实FFmpeg中大家常用的功能主要是libavformat、libavcodec和libavfilter,当然还有一些包括采样率的转换、缩放、格式的转换,比如YUV转成RGB,以及最近非常火的人工智能,做一些头像识别等等,那么做头像识别之前,我们知道人眼看到的内容是有色彩的,如果想去识别它,可以把它转成一个RGB格式,那么我们再看到这个图像的时候,它将会是头发是黑的,脸有可能是白的,那么它就可以去做识别了,这部分实际可以通过滤镜部分去处理,此外转换的时候通过scale做处理。再就是AVUtil,我个人认为它是非常厉害的功能,它里面会抛出来一些函数,那些函数和接口或者一些条件判断、一些流程控制,都是通过util抛出来的,在FFmpeg官方文档中有util的目录。还有libavdevice,在做一些AVFoundtion,或者是qtkit、xorg、dshow、alsa等等一些设备在里面是可以拿到。

接下来介绍下FFmpeg四个比较常用的软件,第一个是ffmpeg,大家做转码常用的,或者是测一些流是否可以被正常播放,或者在有异常的时候,通过它input下看是否能正常获取到。第二个是ffprobe,它的功能很强大,通过它可以分析到关于音视频各个维度的的数据,比如我拿到一个音频包,这个包多大,头部存了什么东西?如果主播推流,中间被其他人抢占,再重新推流这个过程中,客户端首先会收到metadata,然后是Sequence Header,紧接着就是视频或者音频的流,主播重新推流之后就会出现多一个metadata的情况,那这些用ffprobe是可以看到的。或者时间戳是否连续、时间戳跳变等等也可以通过ffprobe可以看到。ffprobe可以read packets、 read frames、read streams,如果你想看整个帧的排列,可以分析它的frames,通过导出CSV格式文件转换成图像——柱状图。

第三个是ffplay,实际上很多时候可以用ffplay直接去播放,可以立即看到效果,不必再等待FFmpeg转码。需要注意的是ffplay在2015年中旬,从SDL1.2转成SDL2.0,如果出现编不出ffplay的情况,可能需要装一下SDL2.0。最后是ffserver,虽然目前也还会有很多人使用,但确实已经没落了。

FFmpeg开发规则

接下来介绍下FFmpeg开发的基本规则,其实这个规则很简单,但是不符合大部分人的使用习惯。

  • 会读文档是成功的第一步

FFmpeg会提供一个很全面的文档,因此首先你得会看文档,文档的结构很清晰,首先第一步就是advanced options,下面是各个封装部分和codec部分,最后是滤镜部分。

第二个是Wiki,这个文档都是通过texi文件去写的,我们可以看到document下面有muxer和codec的.texi文件,在增加或者是删除一个选项的时候,这个文件是必须要改的,否则代码是无法被合并的,然而它只是纯文字的,有些抽象的东西无法举例的时候,就会写一个Wiki放到track里面。此外就是API使用文档。

  • 套路满满的玩

除了这些基本规则外,还要掌握一些套路,比如说看代码看不懂的时候怎么办?邮件列表是个很好的手段,它是全球完全公开的,通过它可以帮助你了解这段代码是如何实现的,或者它有怎样的问题等等。这里跟大家分享一个问题。

这段代码是用HLS的duration做了一个四舍五入,HLS的duration分成两部分:一个是最上边的header部分taget duration,还有就是最下边的INF里边要设置duration。标准文档规定,在做round的四舍五入时, taget具体切的duration,也就是每个切片实际的duration必须小于taget duration,但是在官方文档中写的比较晦涩。这个问题最终通过邮件列表的方式得以解决,所以善用邮件列表可以帮助大家解决很多问题。

  • 入坑也是要按“基本法”的

了解完文档和基本套路,接下来就是入坑了,我的建议还是要仔细阅读文档,这是最简单的,也是最直接的,它包括了常见的FAQ、支持的封装格式、编码格式、滤镜以及外部库。再就是开发者说明文档,在提交代码之前先要阅读开发者说明文档,它会告诉我们怎么去开发,怎么去生成Patch,怎么去发一个邮件。此外还有Git的基本使用,比如通过Git cherry-pick命令可以把另一个开源社区代码的commit ID直接合并到你branch的commit ID上,避免在move过程中丢失author信息,但也会有冲突,就需要自己手动fix,它相当于是一个项目管理,你可以通过git去管理多个branch代码。最后是自动化测试环境,如果你想提代码,比如想给HLS加一个选项,在生成HLS的时候,m3u8,最后会加一个endlist,而下次再去写这个文件时,因为FFmpeg没有追加的功能,它会从头重新生成一遍,这样就会导致像CDN中常见的一个场景——主播推流断了之后重新推上来,因为原来的流被覆盖掉了,所以一部分手机播放会出现卡顿,如果增加这个功能,它实际上是把endlist去掉,加了一个discontinuity的tag。

那年那坑那些经验

  • 踩坑实录第一弹

接下来跟大家分享下过往遇到的坑和一些经验,首先是CDN,做CDN服务不能针对某一个业务做优化,而是需要针对所有的业务,这里给大家举个例子:有的客户会要求直接基于FLV去追加,但是假如用户在推流过程中出现抖动,就会导致断开连接,就需要重新推流上来,而很多情况下会要求算成一次推流,那么就需要去解决拼接的问题。

第二个是时常变化的标准,比如像DASH、MPEGTS或者HLS,前段时间MPEGTS增加了一个音频的Codec——OPUS,而HLS最近也终于定版——RFC。

第三点是文档信息,这部分经常会出现文档信息不全,像OpenCV很多文档是基于代码直接生成的,也有手动去写的,之前我在解决OpenCV人脸识别问题的时候,发现原来是函数接口名变了,但文档中没有变更,而FFmpeg在这方面还是不错的,它在你提代码的时候会强制你写文档。

最后是想要的功能不支持,比如facedetect,就需要自己把它加进去,这时首先需要研究里面有哪些东西、大概是做什么的,比如人脸识别是放在AVFilter的滤镜中,因此其中会有对应的参考;再比如缩放,缩放是很耗资源的,在FFmpeg中把缩放计算这部分做了硬件加速,包括VAAPI、QSV、NVIDIA和Intel对应的计算,都是通过AVFilter去做的。

刚才提到不支持人脸识别功能,就需要分析VF overlay,这个.C文件里面,我们可以看到它处理了RGB、 YUV以及gray,其中是各种不同的叠加,那么它既然能这样处理,说明在这个滤镜里面肯定有Input和Output,那么我就可以直接把它的Input数据放到OpenCV里面,再把OpenCV中处理过的数据,也就是Output数据放到Outputlabel里面就可以了,实际上它的整个操作是很简单的,而且除了Overlay这个滤镜,其他的滤镜处理也很简单,代码都不会超过500行。

  • 踩坑实录第二弹

第二个坑就是FFmpeg不支持DASH Demuxer,像我们平时看的YouTube、BBC、CNN,它们的直播流有两种——没有RTMP和FLV,其中一个是HLS,另一个是DASH,包括我们看到的Netflix中很多直播也都是支持的。现在的FFmpeg也已经可以支持,虽然暂时还不支持多码率。第二点是对HLS Muxer的支持,HLS在以前仅仅可以做到大概的解,在封装成m3u8的时候,其中很多功能都不支持,比如single_file或者切多片时的设置,在切多片的时候就需要用到类似single_file的功能,比如做到三百兆一个片,这样就可以避免HLS都是零零碎碎的小片,对硬盘做到一定的保护以及提升一些硬盘读取的速度,而且IO消耗并没有那么高。最后是FLV,我们在以前做FFmpeg封装的时候,推流出去后,由CDN给录制成FLV,它的metadata里是没有keyframe index的,如果用Flash播放器去播放或者拖动的时候是很慢的,因为它需要下载这个数据,但是假如有这个信息,就能够做到很快的定位,因为所有的keyframe信息都在keyframe index中记录,而它在metadata里,我只需要解一下metadata就可以把它拿出来。

分析问题的基本套路

其实学习和使用FFmpeg是需要一个基本套路的,我认为这个套路就是复现问题。当遇到一个问题时,首先复现这个问题,从中找到它的规则。然后有针对性的去看参考文档,如果参考标准里面并没有完全的说明,那就只能去支持它的这种不标准;如果在参考标准中明确提出,就需要做更改,因为代码不能被合并。第三件事是分析,分析正确的与不正确之间的差别,这里举个例子,我在做HLS支持的时候,HLS 我将FMP4支持上去后发现最开始无法播放,我就跟苹果的FMP4作对比,分析两者的区别,发现是yuvj422p的pixfmt,然后按照常规的yuv420p做编码压缩在封装fmp4,就可以了,就是通过这样的对比找到最终问题所在,这个也是当初做服务大概的思路。

那么遇到问题应该怎么办?作为程序员经常会遇到这样一种情况。

产品经理或者客服直接找到你,说客户过来报bug了,说你的代码有问题,必须马上解决。

这种时候我特别想给他一枪,把他解决了,问题也就解决了,相信很多人也会跟我有一样的想法(哈哈)。但现实却是,经过一番苦战之后,“是在下输了”。

  • 复现问题——DASH篇

这时候就需要开始分析这些问题、复现问题,首先需要有一本标准文档,针对DASH支持这个具体问题上,我们还需要找一个播放器测试,以及了解FFmpeg的框架,在实际往FFmpeg里加DASH功能时,第一步我先分析它是一个切片文件列表,然后我开始去分析HLS,因为它们之间有很多相似之处,区别在于一个是纯文本,一个是xml,此外还需要注意标准中描述的一些细节,比如DASH实际上不仅仅通过CX,逐个递增的切片,还有一种timeline的方式,需要按照它的时间去做文件的获取,但它不会写明切片的连接是什么,只会告诉你计算方式,如果算错就会导致拿不到文件,这个时候就需要特别注意:比如我的第一片first_seq_no,获取当前时间get_current_time,获得availability_start_time以及time_shift_buffer_depth,还包括time的计算方式fragment_timescale等等。

  • 复现问题——HLS篇

再跟大家分享另一个案例——HLS,图片中生成的这个切片,如果不仔细观察可能看不出有问题,实际上这个视频少写了一帧,大家可以看到生成的最后一片和拿到的最后一片,它们duration时间是不同的,所以我分析是,它是在append的时候直接就退出了,并没有写最后一帧。

  • 套路的基本点

接下来介绍下FFmpeg中写Demuxer需要注意的几个基本点:首先read_probe, 注意它不能直接返回0,这个是需要注意的,需要去访问Maxscore命令的size才可以,或者max size score除以2,当然这是正确的情况,如果不正确的可以直接返回0,那么解析将会结束;接着就是解析header,这个header就是FLV的头,或者DASH的xml文件;然后是read_packet,实际它在调用API的时候更加常用,对于写封装而言用到它的机会并不会很多,它是在IO操作中,使用read_packet调里面的回调,再就是read_close和read_seek。

write部分其实主要是三部分——write_header、write_packet和write_trailer,这里需要注意一点,很多人在写MP4的时候经常会Ctrl+C,这个时候你剩下的MP4就播不了,因为两次Ctrl+C的时候是不写trailer的,写一半被中断了,而moov box是根据你的MDat记录的所有信息计算出来的,然后通过一个flag,把moov box移到最前面。

最后再介绍下IO操作部分,当你read_packet的时候,实际上它会调AVFormatContext,其中的pb就是具体封装的context,你可以去通过IO接口设置,把它挂到AVFormatContext的pb里,此后所有的操作其实就都是操作这个pb,也就是说read_packet的时候是在read里面的回调——类似于read_data,拿到read_data就可以正常解析音视频数据。

其实总体而言,套路的基本点就是静下心来多看代码,读文档,写代码,除了这三件大事更重要的就是交流,因为独学而无友则孤陋而寡闻。以上是我分享的内容,感谢大家。

分享给小伙伴们:
本文标签: FFmpeg

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.