【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

网易视频云:从处理流程到细节优化,解读点播直播背后的技术

  • 2016-12-08
  • 本文字数:4043 字

    阅读完需:约 13 分钟

编者按

2016 年被视为直播元年,根据相关数字显示,目前中国互联网约有二百多款直播 App 和四百多家直播平台。其实,视频编码的研究由来已久,互联网规模化的视频服务也已经十余年。在 Vimeo 和 YouTube 正式成立前,最早的视频网络服务雏形可以追溯到 1997 年的一个网站。

网易第一个产品广为熟知是 2010 年的“全球名校视频公开课栏目”,首批上线有 1200 集课程,网易称其视频的技术积累已有十五年;如今,网易向外推出了视频云服务,支持点播和直播两种模式,其中直播又分为单向直播和互动直播。那么,网易视频云背后的技术沉淀是怎样的?除了传统的点播,如何应对新时代的直播业务?如何应对移动互联网等技术背景环境的变化?又怎样看待 VR、AR 浪潮对视频界的冲击?带着这些问题,InfoQ 采访了网易杭州研究院视频技术专家郭再荣先生,本文整理自采访内容。

嘉宾简介

郭再荣,网易杭州研究院视频技术专家,武汉大学通信专业硕士。十年音视频行业开发经验,从事视频编解码算法研发。在网易负责带领网易视频云音视频技术研发团队,主导音视频转码系统、实时视频通话引擎、流媒体服务器和网易视频云平台的研发工作。擅长音视频编解码器、视频加密、视频点播、互动直播服务的开发。

互联网视频产品始于六年前

在视频技术方面,网易最早开发视频点播服务、播放器、后台转码工具,主要用于网易系内部产品,比如网易门户网站视频、公开课、云音乐等产品,属于产品内部研发团队。后来随着需求的逐步增大,我们逐渐把把这些公共技术提取出来,整合成通用的平台工具,并服务于网易有视频需求的产品。

在视频转码系统的开发方面,前期我们已经累积了丰富的经验,经过不断的改进优化,已经逐渐形成了一套分布式转码集群:支持同步和异步的转码任务,负责多媒体数据的处理,这目前已经成为视频云产品的核心底层系统。同时,在提供视频点播服务中累积了丰富的流媒体分发网络方面的经验,包括中心调度策略、分发节点的选择、节点的加速传输方面的优化等,这套系统就是现在视频云产品的 CDN 分发网络的前身。

视频的处理流程及架构总览

通常而言,按时间的横向视频处理流程,一个视频从在客户端上传,到最后播放在另外一个播放器中,经历的流程如下:

视频的构架主要包括音视频采集、预处理、编码、传输、服务端处理、解码等步骤。

网易视频云视频处理包括推流端的预处理,服务端转码处理,播放器端的后处理几个部分,如下图所示。

点播 VS 直播的流处理

我们网易视频云目前为需求者提供点播和直播服务,同时包含互动直播服务,也提供视频转码和视频处理服务。对于视频云平台来说,拥有庞大的流媒体分发网络、强大的转码系统、海量分布式存储服务、功能完善的全平台 SDK 包非常重要。

在点播和直播的异同点上,我们通过如下构架图来表示,其实主要区别是视频源的生产方式不同,流媒体分发网络是一样,播放器端是一样,另外点播需要存储系统,而转码两者都可以有,具体要看各自的应用场景。

算法、硬件和网络三个维度

首先,网易视频云对音视频算法进行了深度优化。对于互联网视频,最重要的就是在保证视频同等质量的情况下,进行码率压缩。这样,在网络不佳时,尽量保证流畅;在网络抖动时,减少对播放带来的影响。除了压缩之外,对于近来兴起的直播业务,还需要对视频预处理。

在对音视频数据压缩编码时,要进行一些预处理,同时编码算法上尽量保证码率平滑。先来谈谈对于音频处理:从麦克风采集的音频,一般是 PCM 格式,视频从摄像头抓取图像,也可以抓取屏幕图片,一般是 YUV 格式。而采集到的原始音视频体积非常大的,需要经过压缩技术处理来提高传输效率。当有混音需求时,也可以通过采集声卡的音频数据,然后再跟麦克风的声音进行混音。对于采集的音频一般先要进行降噪处理,因为在户外环境下,噪声会比较明显。如果涉及到互动直播,在双向通话的情况下,还需要对音频进行回声抑制处理,防止出现回声效果。

再谈谈图像处理,对于直播业务:我们对于采集的图像会进行特效滤镜处理,比如黑白、黄昏、提亮、美颜等,但是这些处理非常耗费性能,一般都需要用 OpenGL ES 来实现,同时也可以进行图像叠加,比如给主播加个帽子,或者为了保护版权,加个水印图片。在播放器显示的时候也可以在头像上做一些处理,比如全屏的时候图像拉伸、填黑边、裁剪,也可加上走马灯,进行版权保护。再举例说明,比如在实时监控的场景中,要实现对于局部画面的实时放大;相对于直播中的预处理,这类操作属于后处理范畴。算法层面的加工主要有三点:预处理、后处理和编码。

其次,在硬件上面,客户端是依赖于用户已有的设备,我们的发力点是在服务器端。网易视频云有分布式转码集群,并采用软件和硬件结合的转码方式,对应到芯片依赖类别上则是 CPU 和 GPU,权衡两者结合使用:对于大并发的任务,利用 CPU 资源进行软件转码模式;而对于高实时性要求的任务就利用 GPU 资源进行硬件转码模式,特别是对于高清视频的转码,能达到更快的转码速度。结合直播应用而言,虽然依靠 CPU 计算的软件转码可以实时得到结果,但是这会造成资源的浪费。

另外,视频云自建流媒体分发网络,在全国部署了接流源站和分发节点,资源节点数量达到 500 个以上,并利用自有的智能调度系统,保证直播的流畅性;同时网易也自建了海外专线,保证海外数据流回到国内时走专门优化的链路,确保流畅度。

应对移动网络干扰

不管是直播还是点播服务,都存在一个端到端的数据传输链路问题。我们采用智能调度策略来解决这个问题,就是根据客户端的网络类型、地域、出口 IP 等信息,选择最优节点给客户端。最优节点的方案有两种:

  • 一种是根据客户端的 DNS 域名来选择就近的节点,当 DNS 配置有误的时候,可能会存在调度不准的问题。

  • 另外一种是根据客户端的出口 IP 来选择节点,这种调度方式会比较准确一些。同样对于播放器端也是采用类似的方式来选择流媒体服务器集群的边缘节点,另外也可以用 HTTP 302 跳转的方式来优化播放链路。

具体对应到两种播放模式的处理上:

对于点播来说,可以对同一个视频源部署多条流,即不同分辨率和码率的视频源,这样用户在观看的时候可以切换选择。

对于直播来说,视频云也提供实时转码功能,可以转码出多条不同分辨率和码率的直播流,这样用户在观看的时候可以切换选择。

视频界的发展历程及未来挑战

音视频编码既要尽可能地对文件压缩,同时又追求最高的音频和图像质量,还要能有更少的计算量,这三个目的指标是相互矛盾的。

从事视频编码近十年,在我看来:音视频编码标准正变得越来越复杂,能达到的音频和图像的质量也更好,压缩率也有较大提高,但是对应的算法计算量也越来越大,比如目前发展势头很猛的 H.265 标准。这一切的发展都是基于硬件设备性能越来越强大,可以承受更多的计算量。现在的手机 CPU 都能做 2K 的实时编码;若采用专有硬件编码芯片,那么性能就会更好。编码标准发展了,同等编码质量下的码率降低了,特别对于网络视频服务来说,用户观看视频更加流畅清晰了,企业的带宽成本也降低了。

在直播快速发展的同时,VR、AR 已经非常火爆,结合两者也是将来视频发展的趋势。但是在我看来,视频 VR 直播目前还有几大难点:包括采集设备、图像拼接算法、视频编码器、画面显示设备等。而目前的 VR 技术是从实验室刚开始转入应用的阶段,很多地方不完善,尤其是体验效果不佳、会让人感觉晕眩。此外,如果想要实际应用到网络视频,必须过了传输这关。VR 视频的分辨率非常高,至少 2K 以上,否则效果会比较差。多幅图像拼接之后,编码的码率就会非常高,一般在 10Mb 以上,互联网的传输也会有问题。因此,现在最多的也是一些离线的 VR 展示。另外,现在优质的采集和显示设备也比较贵,还达不到平民级的消费。目前还是在发展中,当然这是视频将来的方向。

其他问答

InfoQ:目前网易视频云对H.265 编码技术的研发是处于什么阶段?

郭再荣:H.265 的编码的研发目前仅限于内部,自编自解是没有问题的。但是 H.265 的解码技术在业内还没有普及,对于 web 播放器或者第三方播放器很可能无法播放。

不过 H.265 肯定是将来的趋势, 因为在画面越来越清晰之后,对于编码会造成很大的压力,同时带宽的需求压力也会上升。举例说明,如果使用 H264 编码需要至少 1.5M,使用 H.265 编码预计 1M 左右即可达到同样的效果。

InfoQ:用户是否可以在不同端之间切换观看?如果是的话,怎样做到内容的播放点的同步?

郭再荣:播放点的同步需要用 PTS 来做,首先切换流的时候,播放器要记住前一次的播放点的 PTS,然后再往前几秒发送切换流的 seek 请求,服务器会从一个关键帧开始发送数据,播放器定位到前一个 PTS 点,再开始播放,这样就可以做到同步。原理就是同一个视频源的多条流的 PTS 是一致的。

InfoQ:网易视频云进行了 WebRTC 协议框架的全方位支持。可否从技术角度分析下,什么样的直播场景中比较适合采用 WebRTC?

郭再荣:这里需要提及下我们的两种直播方式:单向直播、互动直播。我们首先完善了实时视频通讯系统,支持单向直播,在其基础上扩展多路混屏,旁路直播等功能。WebRTC 技术推荐适用于互动直播的场景。单向直播其实也可以采用 WebRTC 技术;不过一般而言,基于 RTP 传输技术能够保证更好的流畅度,特别是在网络环境比较差、丢包相对严重的情况下。而互动直播对低延时要求比较高,要实现多人通话,肯定是需要 WebRTC 技术,因为传统的 rtmp 直播技术,延时比较大。想利用浏览器直接进行实时音视频通信,或者进行直播服务,必须要采用 WebRTC 技术,这是他最大的一个优点,而且无需安装任何插件。

InfoQ:视频处理、图像处理中多大程度地应用了机器学习?对视频分类和实时监控中有多少人工参与的环节?

郭再荣:目前视频云已经接入网易易盾产品,在视频直播同时进行实时鉴黄,这个服务就是应用了机器学习:先对视频流进行截图,然后对图像进行智能分析以判断是否有违规内容,再上报到实时监控平台,最后经过人工审核,确保不会遗漏任何的违规行为。视频分类一般都是人工处理,是用户根据自身产品进行分类,而实时监控一般最后一关是人工审核,但占比重比较少。

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2016-12-08 18:00114114
用户头像

发布了 58 篇内容, 共 42.5 次阅读, 收获喜欢 35 次。

关注

评论

发布
暂无评论
发现更多内容

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。

老姜

二胖参数校验的坎坷之路

java金融

Java springboot 参数校验 级联校验 Hibernate-Validator

第四周直播总结笔记

Carlos

Kafka面试题——20道Kafka知识点

古月木易

Kafka知识点

架构师训练营第 4 周 总结

时来运转

以懂行助力加速:华为中国生态之行2020蕴藏的时代钥匙

脑极体

万文长字JVM总结,面试必备

java金融

Java CMS JVM 垃圾回收

命题作业和总结—第四周

于江水

极客大学架构师训练营

Elasticsearch从入门到放弃:分词器初印象

Jackey

elasticsearch

从业务代码到Openjdk源码的debug之路

飞影

Java debug 深入理解JVM Openjdk TLAB

架构师第四课总结

老姜

架构师训练营 第4周作业

Lingjun

极客大学架构师训练营

以应用为中心:开放应用模型(OAM)初探

郭旭东

Kubernetes OAM

第四周总结

石刻掌纹

爱恨交织的红黑树

ytao

数据结构 算法

架构师训练营 -- 第四周作业

花花大脸猫

极客大学架构师训练营

架构师训练营 第四周 学习总结

一雄

学习 极客大学架构师训练营 第四周

分布式柔性事务之事务消息详解

奈学教育

分布式事务

第四周作业

田振宇

一份还热乎的蚂蚁金服面经(已拿Offer)!附答案!!

猿灯塔

Java

架构师训练营 第四周 作业

一雄

极客大学架构师训练营 作业 第四周

管理学概念 - 特纳论断

石云升

核心竞争力 特纳论断

【架构师训练营 - 作业 -4】互联网应用面对的问题

小动物

极客大学架构师训练营 作业 第四周

架构师训练营第四周作业

Linuxer

极客大学架构师训练营

架构师训练营 -- 第四周学习总结

花花大脸猫

极客大学架构师训练营

一路“开挂”,完美诠释“年少有为”——90 后首席科学家王乃岩

二叉树视频

写作平台 二叉树 年少有为

分布式柔性事务之事务消息详解

古月木易

分布式柔性事务‘’

游戏夜读 | 不受欢迎的那个人

game1night

架构师训练营 第 4 周总结

Lingjun

极客大学架构师训练营

Kafka面试题——20道Kafka知识点

奈学教育

Kafka知识点

企业级业务架构设计读书总结

烟雨濛濛

网易视频云:从处理流程到细节优化,解读点播直播背后的技术_服务革新_木环_InfoQ精选文章