展望2018:WebRTC和下一代编解码器

简介: ...

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1


WebRTC的优势与短板,编解码器的未来是属于FVC还是AV1?FPGA、ASIC、GPU等专用硬件编解码器的应用前景如何?来自网宿科技的投稿对此进行了深度分析,本文也是『2017-2018音视频技术回顾与展望』系列的第二篇,如果您对音视频技术的未来有分析和洞见,欢迎联系 contribute@livevideostack.com。


文 / 网宿CDN事业部

策划 / LiveVideoStack


WebRTC让音视频通信开发变得简单


WebRTC的主要优势在于提供了一整套完备的音视频通信方案,使得音视频通信开发变得简单。


WebRTC提供了完整的端到端处理方案。包括了采集、回声消除、噪声抑制、自动增益控制、编码等近端处理,以及自适应抖动缓冲区、丢包隐藏、解码、播放等远端处理。其中编解码器包含免费高效的OPUS、VP8/9等,音频自适应抖动/丢包隐藏则可以在较高延迟/丢包率下依然保持良好的通话水平。


当然,这个完整的方案并不完美,比如没有服务器实现,比如回声消除在安卓系统上效果不一。做服务器实现时除了信令外,做合流的话还需要处理丢包情况,否则会出现音频断续等问题。总的来说,WebRTC为音视频通信开发者提供了开发简单的入门框架,然而要实现较好的效果,开发者需要做的额外工作并不少。


AV1未来机会巨大


所谓下一代编码器,主要就是H.266/FVC和AV1了。关于这个大家应该是有共识的,即AV1是(专利)免费、开源的,而H.266按惯例则是要收取不菲的专利费的,因此性能差别不是非常大的情况下,毫无疑问大家会拥抱AV1(AV1对比H.265的目标码率节省是30%)。另外考虑到目前移动端流量的高占比以及高复杂度的编解码导致软件实现困难,硬件编解码器的重要性不言而喻,H.265的巨大掣肘之一就是硬件支持不佳。


由于专利费等影响,预期H.266也不能摆脱这个难题。AV1则在标准制定过程中始终将硬件实现考虑进来,并且联合硬件厂商制定并推动AV1的硬件产品化。然而硬件开发的周期预计将以年为单位,再加上终端产品的换代周期以及生态开发的时间,AV1需要数年后才有可能大面积应用。


长远来看,AV1的机会非常大,而目前来说,H.264/5的主导地位不会改变。


专有编解码器并不适合CDN


我们评估了许多硬件转码方案,包括FPGA、ASIC以及GPU。大规模转码对转码系统的要求很苛刻。


首先从性能上来说,由于硬件实现的诸多限制(比如B帧、参考帧数目、运动矢量搜素范围等),大部分硬件编码器(尤其是FPGA/ASIC)的编码效率(即固定码率下的画质)达不到甚至远差于软件编码器,这种情况下我们作为CDN厂商无法应用,不可能在带宽不变的情况下降低客户的画质。此外还往往限制指定的分辨率帧率才可以转。


其次是成本,大规模转码由于有机房的限电问题,对单位功耗的转码能力敏感,而GPU的功耗其实不算低,导致了其对比软编的编码速度提升幅度受限。


最后是集成,ASIC/FPGA大多没有完备的第三方(比如FFmpeg)集成实现,需要额外的开发时间以及成本。GPU虽然相对完善些,但依然需要一定的适配工作,包括性能/平台定制化开发以及如何进行精准的负载检测等。


以上这些限制导致了硬件转码方案目前还不能完全取代软件转码,只能在一些符合要求的特定场景下应用。


LiveVideoStack 2018年春季招聘


LiveVideoStack是专注在音视频、多媒体开发的技术社区,通过传播最新技术探索与应用实践,帮助技术人员成长,解决企业应用场景中的技术难题。如果你有意为音视频、多媒体开发领域发展做出贡献,欢迎成为LiveVideoStack的一员。我们正在招募商务助理,高级编辑,策划编辑,课程经理。


通过job@livevideostack.com联系,或在LiveVideoStack公众号回复『商务助理』,『高级编辑』,『策划编辑』,『课程经理』了解详情。

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
数据库 UED Python
1、基于python多进程+pyqt5开发流畅界面程序
使用python+pyqt5开发界面程序,利用多进程分离界面和任务执行功能,达到界面流畅不卡顿的要求。 本文程序示例:https://github.com/AlvinsFish/UiExample
2958 0
1、基于python多进程+pyqt5开发流畅界面程序
|
Java 开发工具
【GDAL-java的四个常用代码示例】
【GDAL-java的四个常用代码示例】
816 0
|
存储 关系型数据库 MySQL
Docker(五)进阶:Docker卷(volumes)
数据卷:设计用来持久化数据的,它的生命周期独立于容器,不会因为容器被删除后自动删除,并且也不存在垃圾回收这样的机制来处理没有任何容器引用的 数据卷。
2041 0
Docker(五)进阶:Docker卷(volumes)
|
Java 定位技术 数据处理
windows下gdal的java开发环境搭建
本文介绍了gdal在windows环境下怎么搭建java开发,同时提供一个开发示例,通过输出gdal支持的数据驱动来演示其支持的数据类型,同时表明我们的环境搭建完成,可以基于java进行相应开发。
1680 0
windows下gdal的java开发环境搭建
|
7月前
|
JavaScript 安全 前端开发
Vue2 和 Vue3 中 Vue Router 用法与原理详解
本文深入解析 Vue Router 在 Vue2(v3)与 Vue3(v4)中的核心用法与原理,涵盖安装配置、声明式与编程式导航、路由守卫、懒加载、动态路由及性能优化。对比版本差异,揭示其基于响应式系统实现的路由匹配与视图更新机制,助力开发者构建高效、可维护的单页应用。
645 2
|
8月前
|
SQL 人工智能 BI
智能体协作革命:基于LangGraph实现复杂任务自动分工
本文探讨大模型应用中多智能体协作的必要性,剖析单智能体局限,并基于LangGraph框架详解多智能体系统构建。通过子图状态共享与Network架构实战,展示如何打造高效、可控的AI协作系统,助力迈向组织级AI。建议收藏,深入学习。
1631 6
|
9月前
|
人工智能 Java 机器人
基于Spring AI Alibaba + Spring Boot + Ollama搭建本地AI对话机器人API
Spring AI Alibaba集成Ollama,基于Java构建本地大模型应用,支持流式对话、knife4j接口可视化,实现高隐私、免API密钥的离线AI服务。
6998 2
基于Spring AI Alibaba + Spring Boot + Ollama搭建本地AI对话机器人API
|
存储 算法 安全
程序员必知:分布式一致性Raft与JRaft
程序员必知:分布式一致性Raft与JRaft
402 0
|
并行计算 PyTorch Linux
从一无所有的服务器到建立容器,安装jupyter并远程启动,安装MMdetection过程记录
配置环境: conda+pytorch 1.8.1+cuda 11.1+cudnn 8.0.5 jupyter notebook mmcv-full 1.4.6+mmdet 2.19.0
781 0
从一无所有的服务器到建立容器,安装jupyter并远程启动,安装MMdetection过程记录

热门文章

最新文章