LiveVideoStack和腾讯云音视频联合出品了《2024音视频技术发展报告》,其中一个调查是关于使用的多媒体处理框架:
答案选项有点匪夷所思,就不吐槽了。
虽然调查结果受参与者背景影响,具体数值可能和实际有偏差,FFmpeg占据首位基本没有什么疑问。抛开这个调查问题,我更想知道的是FFmpeg在不同领域的使用情况。
既然没有调研,我就信口开河,讲讲我的观察。我姑妄言之,读者姑妄听之。
1、PC端:FFmpeg开发者大本营
这里说的PC主要是Windows和Linux。和很多早期开源项目一样,FFmpeg开发者多数使用Linux环境,而Windows用户更多,所以Windows和Linux的开发支持力度最大。
macOS虽然也属于PC,但是显然不怎么受开发者待见,支持力度很小,一个功能break很长时间都没人发现。我个人因为办公环境使用macOS,所以顺便给它做一些支持。
PC时代,国内的一众视频播放和转码App都是在FFmpeg基础上做业务,并且保持不开源的传统。PC时代过去了,FFmpeg耻辱柱也成历史了。
2、云时代的音视频服务:都在靠FFmpeg吃饭
PC时代用FFmpeg做音视频相关的可能是首选,但不是必选,其他选项还有不少。而在云时代做音视频业务,基本绕不开FFmpeg。你可以不用它的流媒体传输,不用它的封装解封装,可以自己去封装第三方的编码器,但很难绕开FFmpeg的解码器。
j-b开玩笑说,Demuxed会议上,一半的演讲主题是“我们做了一个项目让FFmpeg更易用”。Ronald补充说,Demuxed另一半的主题是“我们做了一个点播服务”(把FFmpeg称为他们的技术栈)。
12:52 <j-b> jamrial: you are a hacker
12:52 <j-b> If you look at Demuxed
12:52 <j-b> half talks are "here is a project to make FFMpeg easy to use"
12:52 <j-b> :D
12:53 <jamrial> "we're going to explain filtergraphs. have your staff and grimmoire at hand"
12:54 <BBB> the other half is "we made a vod service" and their "stack" is ffmpeg
如果你不是刻意回避FFmpeg,FFmpeg的mux/demux、decoder/encoder、filter都是可以直接拿来做业务的。FFmpeg的IO部分比较弱,虽然实现的协议多,但拿来做服务有些勉强(简单场景还可以)。
另外一个趋势是,大家习惯了把自研的一些功能作为组件塞到FFmpeg里,用FFmpeg实现调用接口的统一。FFmpeg不支持插件化,往里面加东西时,不注意可能把FFmpeg改的面目全非,长期维护是个麻烦。
做音视频服务的,用FFmpeg多,贡献也多。特别是Intel,通过支持FFmpeg来支持它的服务器芯片业务(当然也有PC业务)。
3、移动端:用的多,贡献少
移动时代 + 短视频 + 直播,移动端大体量的App基本离不开FFmpeg,并且很多Android App里,会同时包含多个版本的FFmpeg(点播组件引入一个FFmpeg,视频剪辑组件引入一个FFmpeg)。
一些简单的快速成型的App,直接拿FFmpeg-Kit做功能。头部App性能优化比较好的情况,会更多的使用硬件编解码和GPU处理,拿FFmpeg做异常情况兜底逻辑。
Android和iOS都有自己的多媒体框架,理论上可以不用FFmpeg做音视频业务。实际情况是,总有地方离不开FFmpeg,或者像FFmpeg-Kit这种,通过FFmpeg命令行形式大大降低了音视频的门槛。
移动时代讲究快,快速做业务。我的观察是,FFmpeg在移动应用中用的非常多,但移动应用开发者对FFmpeg投入不多,深入研究的少,给FFmpeg贡献少。
移动应用开发者对FFmpeg贡献少,FFmpeg开发者对移动应用兴趣寥寥,形成一个有些割裂的局面。
一个例子是,FFmpeg里很长时间都没有Android硬件编码的封装。不断的有用户提这个需求,但是FFmpeg开发者谁也没兴趣去实现,而Android开发者又没有参与进来,主动贡献这个功能。当然,MediaCodec糟糕的设计,NDK MediaCodec残废的接口也是影响因素。
另一个现实是,虽然用的很多,FFmpeg在移动应用里已经是配角的角色了,哪怕是必不可少的配角。H.264软件解码可以,H.265软件解码功耗有点高,FFmpeg本身自H.264开始已经没有自带的软件编码了。
FFmpeg作为一个hub的功能,集成一堆第三方库封装的功能,可能慢慢超越它自己实现的功能了。
4、Web端:还能这么玩?
FFmpeg开发者自己也想不到,FFmpeg能运行在Web里(Chrome浏览器里内置的FFmpeg不算)。WebAssembly是个神奇的发明。
与WebAssembly相结合,我比较看好FFmpeg muxer/demuxer能力、音频编解码能力。我不看好拿FFmpeg做视频解码,虽然业内有很多实践,原因如下:
- WebAssembly + FFmpeg解码H.265功耗太高
- FFmpeg里的汇编优化没法用,重写汇编优化可以提高性能,但是投入成本高
- 并且,一旦浏览器决定从内部支持H.265,投入的开发成本浪费了。虽然在用户升级浏览器之前,FFmpeg解码方案仍然有价值,我个人是不愿花时间做这类即抛型开发工作
- 跳过H.265,直接使用AV1是更好的方案
5、嵌入式:严重碎片化
这里主要指嵌入式Linux环境。虽然FFmpeg支持BSD,估计嵌入式BSD系统加FFmpeg的应用场景微乎其微。
都说Android碎片化,至少Android是一个统一的系统(不管谁怎么改),有个统一的framework,而嵌入式天生的百花齐放。
嵌入式领域没有统一的硬件编解码API。虽然PC端也不统一,占主流的就那几个。嵌入式领域,芯片厂商各搞各的。
你可以说有一个标准openmax,各家基本都支持openmax。Android糟糕的mediacodec一部分原因来自openmax,如今Android也抛弃openmax了。openmax今天的地位,可能不如东周天子的地位。
如果要推选一个标准的话,我最看好V4L2作为统一的视频编解码标准接口。
再说FFmpeg和嵌入式音视频领域的关系。嵌入式领域FFmpeg用的也很多,但设备性能限制,FFmpeg视频软件编解码很难用上。各家芯片厂商维护自己私有编解码API,维护一个自己定制的FFmpeg,很少向FFmpeg提交自己的视频编解码支持。FFmpeg里现在有部分树莓派的支持,有瑞芯微解码支持(很久没更新了)。整体局面是,社区不怎么关心嵌入式,嵌入式领域很少参与FFmpeg社区。没动力参与,参与门槛高,社区不友好(经常被说的是,这个社区有毒☠️😂)等都是原因。
嵌入式领域不得不提下gsteamer。同属媒体框架,别的领域被FFmpeg压制,嵌入式领域不好说谁胜谁负。gstreamer的插件化模式,挺适合嵌入式碎片化的生态。各家厂商提供自己的gstreamer插件,可以宽松处理license问题。gstreamer对嵌入式领域的硬件编解码支持明显好于FFmpeg。gstreamer配置pipeline的使用方式,也比FFmpeg API更简单。
FFmpeg社区正在做RISC V的汇编优化,也算是嵌入式领域最大的进展。
6、结语
PC、云服务、移动端都是我工作的范围。工作之外,我更想了解FFmpeg支持不完善的领域,比如Web和嵌入式。
我不懂Web开发,想和Web开发者交流关于Web与音视频技术,看看FFmpeg里能做些什么。
嵌入式领域,FFmpeg支持openmax编码,不支持openmax解码,看openmax现状再补解码支持好像没多少必要了。V4L2值得去完善一下。
FFmpeg还有哪些不足,还有哪些新鲜东西值得做,欢迎来聊。
PS:今天看到一个libavfilter由文字插入二维码的patch,这种就是我说的“新鲜东西”。
作者:quink
来源:Fun With FFmpeg
原文:https://mp.weixin.qq.com/s/m83Dwc_ZY19QBJsdKndgdA
版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。