解析世界杯超大规模直播场景下的码率控制

摘要: 这一次的世界杯,与以往世界杯最大的区别在于,有很多互联网用户观看直播,而不是在电视上。在互联网观看直播,互联网的网络条件不一样,观众会看不同码率的视频。所以主要分享下阿里云在直播中怎么做码率控制。

在本月的重庆云栖大会飞天技术汇专场中,阿里云高级算法专家黄海宇分享了题为《超大规模直播码率控制》的议题,从生产的链路角度来说世界杯怎么让观众看到更加清晰的视频。

这一次的世界杯,与以往世界杯最大的区别在于,有很多互联网用户观看直播,而不是在电视上。在互联网观看直播,互联网的网络条件不一样,观众会看不同码率的视频。所以主要分享下阿里云在直播中怎么做码率控制。

分享分三个部分,首先讨论一下为什么要关注码率控制、其次是宏观上怎么做码率控制,最后是介绍下微观上怎么做码率控制。

为什么我们要关注码率控制
我们先看一下个直播的一个简单的过程。

世界杯通常会拿到一个非常高清的直播源,它的码率非常大,不太适合在互联网上直接传输。所以整条链路中会有一个视频内容的再生产的过程,这个再生产的过程最重要的就是视频的转码,将这个转成不同分辨率的几个档位。比如说我们看视频有流畅的、标清、高清、超清的视频,这些都是为了让不同网络的用户可以流畅的观看视频。在进行转码以后,视频流会经过CDN放大,很多用户会进行观看。

其中,码率控制是发生在转码这个环节,就是把高清视频进行解码再进行重新编码,视频的转码是一个有损的压缩的过程,把原来的视频进行处理,将里面的细节进行忽略,这样能够以一个更低的带宽去满足用户播放流畅的需求。

码率控制有什么影响

第一,码率控制对清晰度有影响。我们通常的概念是清晰度越高码率越高,要求用户的下行的带宽更高。

第二,码率控制影响用户流畅度的影响,用户播放的网络各不相同,当用户的带宽大于视频码率时,才够流畅播放。

第三,码率控制的影响是成本的影响,在整个世界杯直播的过程中,最大的费用在CDN带宽上,CDN的总带宽消耗为不同的码率以及这种码率并发在线人数的乘积之和。

所以我们的问题是用户的网络是有限的,我们如何在有限的网络下最好的控制码率,提供给用户最清晰的视频。

宏观码率控制
下图是一个在世界杯期间直播的例子,左边是另外一个直播平台做的一个视频直播,右边是优酷上面的。可以清楚的看到左边的视频在抢角球的场景是很模糊的,而右边的视频是看起来比较光滑和细腻的,这两个视频是相同的码率,左边是1080P的2.5M,右边是720P的2.5M,但是为什么会出现这样的场景?

我们先看一下整个视频编码的过程是怎么样的:

下图上面这条线是一个1080P的视频转成1080P的视频进行播放的一个流程,首先是解码,这一步是不会有视频清晰度的损失的;然后是视频的编码,比如说一个视频25帧,需要把这25帧的图像编码成3M的1080P的图像,在这个过程中,为了保证输出码率为3M,有大量的细节损失;第三步是这个视频经过了CDN网络的传输到达用户的播放器,用户会进行解码播放,这一步是没有信息的损失。最后一步是播放器的渲染,这一步也没有信息损失。

我们再来看720P转码,经过1080P的视频解码,下采样到720P,720P编码,传输,解码,最后在播放器端进行上采样,重新编成1080P以及渲染的过程。这个过程中有两次的视频清晰度的损失,第一次是发生在上采样以及下采样的过程中,这个信息实际上是一个固定的损失,它和我们的采样算法有关系;第二是在720P的图像编码成3M的视频中发生的。为什么1080P不如720P清晰,是因为在720P编码中,我们可以把720P的每一个象素都描述得非常清晰,这部分的信息损失加上采样的信息损失只和小于1080P编码时的信息损失。

所以总结一下我们需要控制码率。码率控制的目的就是在一定的带宽条件下,需要使每一个比特都能够发挥它的作用,把它分配到最需要他的地方,从而提升用户的观看体验。

说到把每一个比特分配到最需要它的地方,通常会有很多方式,在整个编码过程中什么地方有信息的损失,就可以在哪里做。比如:
第一是在分辨率做文章,对给定的码率,可以选择不同的分辨率进行调整。
第二是在帧率做文章,对给定的码率,可以选择不同的帧率。
第三是在视频中码率在不同的帧间进行码率分配,对于复杂的场景,分配更多码率,对于简单的场景,分配较少的码率。
第四是在帧内进行码率分配,在一帧之内,根据图像的复杂程度和人眼敏感程度进行码率分配。
在世界杯实现的场景中,要考虑到播放器的兼容性,使用的是分辨率、帧间码率,帧内码率的优化手段。

宏观码率控制——分辨率
首先看一下在宏观的码率选择上,如何去根据码率选择一个最佳的分辨率。

这是一个对世界杯的视频做的试验,采用不同的分辨率来进行编码,相同的码率进行编码。上图可以看到信息的损失量,我们可以在相同的码率下,随着我们的分辨率的增高,实际上视频的清晰度逐渐升高。到了一个最高点以后,反而会由于视频的分辨率的增加,它的清晰度会降低。这也验证了之前我们看到例子。

所以根据这样一条曲线可以得到分辨率和码率的模型,对于任何一个分辨率可以找到一个最佳的码率。在实际上世界杯的这个场景中,我们把视频分成了很多码率,在给定的任意一个码率上我们都能找到相应的分辨率。

如果关注过阿里云的直播,会看到转码的建议上会给出很多不常见的分辨率,比如说432P、648P这样的分辨率,这些分辨率通常能在相应档位的码率上得到很好的清晰度。

微观码率控制——帧间码率
说到微观上的码率控制的时候,第一件事情就是如何将码率在很多帧间进行分配。

上图给出了多种码率分配的算法,第一个算法是传统的CBR,就是说不管视频的变化是怎么样,统一采用相同的码率对视频进行编码,尽量做到每一秒的码率是相同的。CBR是途中的红线,我们可以看到实际上视频清晰度的损失波动非常大,在红线中可以看到高的时候可以非常高,低的时候非常低。在播放的时候肯定不希望能够看到一个清晰度剧烈抖动的视频,这对人眼的观看是极其糟糕的,于是我们尝试用一种叫CQP的方式进行视频编码,这实际是确定了视频编码的量化步长,这个情况下可以得到清晰度相对稳定的视频。但是采用这种编码不是没有代价的,采用CBR时码率比较稳定,但是采用CQP,在画面比较复杂的地方,为了把这个清晰度提高,码率就会非常高,可以看到,在右图中,CQP(绿线)的码率飙到了12mbps,这对普通用户来说显然是不可以接受的。所以最终采用了VBR+VBV的方式。当使用VBR+VBV的控制策略以后,蓝线比红线的码率质量波动会稍微好一点,VBV模型也能保证用户带宽在达到VBV指定最大码率时,视频一定能够流畅播放。

VBR的烦恼
VBR在大规模直播中也会带来一些问题,这张图是在世界杯的开幕式的时候一张CDN的带宽的分布图,横坐标是时间,纵坐标是CDN的带宽。

这个图就可以看到两个非常明显的波动,第一个发生在中场休息,第二个发上在23:00,开幕式结束,比赛正式开始前。第一个波动很好解释,因为中场休息时很多观众离开,中途的精彩进球会回来一部分观众,下半场开始又有很多观众继续观看。在前面的波谷就不太好解释了,通过观察了码率的分布图,我们发现当时码率非常低,实际上,在这段时间正好是普京讲话,这是一个相对静止的画面,由于采用了VBR,码率发生了剧烈的波动,从而引起带宽剧烈波动。

这种波动对通常的直播是没有问题的,不同的用户在看不同的直播,所以码率的峰值叠加起来会趋向于码率的平均值。但是世界杯的场景下,有70%的流量都观看相同的直播内容, CDN的带宽非常高,这使得CDN的带宽随着码率的波动而波动。通常的CDN通常会使用当前的水位来评估一个新进用户应该放在什么CDN节点,或者说根据一些历史的状况估计CDN放在什么节点。在世界杯中,这个问题通过CDN引入新型的调度策略来解决。

帧内码率分配

帧内码率分配考虑的是如何在一帧图像内对码率分配,以得到最好的视觉效果,我们会根据人眼的关注点来调整码率分配。在上图中,人眼关注的重点毫无疑问是梅西的头像,人眼可能会对后面虚化的内容不关注。所以在做转码处理的时候,会优先考虑这个图像的聚焦区在那里,在这些地方提高它的码率。另一方面,人眼对规则的纹理非常敏感,这部分也需要分配更多的码率,而在脱焦区域,我们会适当的减少一些码率。通过上述手段,整个视频的码率没有上升,但人眼的主观感觉会更清晰。

原文链接

本文为云栖社区原创内容,未经允许不得转载。

原文地址:http://blog.51cto.com/13952056/2170180

时间: 2024-11-02 04:58:20

解析世界杯超大规模直播场景下的码率控制的相关文章

[转帖]etcd 在超大规模数据场景下的性能优化

etcd 在超大规模数据场景下的性能优化 阿里系统软件技术 2019-05-27 09:13:17 本文共5419个字,预计阅读需要14分钟. http://www.itpub.net/2019/05/27/1958/ 不明觉厉 作者 | 阿里云智能事业部高级开发工程师 陈星宇(宇慕) 划重点 etcd 优化背景 问题分析 优化方案展示 实际优化效果 本文被收录在 5 月 9 日 cncf.io 官方 blog 中,链接:https://www.cncf.io/blog/2019/05/09/p

不同直播场景的CDN技术简析

随着直播行业的兴起,各种直播应用.平台和产品万花齐放,直播场景也越来越多元化,这就对视频技术的发展提出了"日新月异"的需求.那么,目前视频直播的场景主要有哪些?不同类型的直播场景对视频技术又有怎样不同的要求?本文将通过分享一些个人经验,简要分析不同直播类型的CDN技术要点. 要说清楚这个问题,我们需要从头说起: 基础网络的发展路径 80后.90后都是见证互联网崛起的一代,互联网的发展史,本质上就是网络速度的发展史.刚开始的时候,网民用电话线拨号上网,下行速度只有不到几十K,打开一个复杂

互联网业务场景下消息队列架构

消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中. 同步VS异步 通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:"同步通信"和"异步通信".根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无.同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟.现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信.同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消

Redis5.0:这些场景下使用,高效还降低成本!

华为云分布式缓存Redis,能应对很多典型的场景,比如很多大型电商网站.视频直播和游戏应用等,存在大规模数据访问,对数据查询效率要求高,且数据结构简单,不涉及太多关联查询.这种场景使用Redis,在速度上对传统磁盘数据库有很大优势,能够有效减少数据库磁盘IO,提高数据查询效率,减轻管理维护工作量,降低数据库存储成本. Redis对传统磁盘数据库是一个重要的补充,成为了互联网应用,尤其是支持高并发访问的互联网应用必不可少的基础服务之一.以下举几个典型样例:(电商网站)秒杀抢购电商网站的商品类目.推

从强提醒说起——社交场景下的万有“隐力”

2018年的最后一天,微信推出了上线以来的第7个大版本:微信v7.0.在微信v7.0里,微信推出了三个大功能:即刻视频,好看和强提醒.分别代表了社交场景下的3个热点:流媒体.Timeline.即时通讯.作为一个即时通讯行业的从业者,看到“强提醒”这样的功能在微信上亮相,想和大家聊聊这背后的碰撞和演变. 打开新版微信,在你关心的联系人会话页面点击右上角,除了过去的置顶聊天和消息免打扰,新增了一个强提醒开关.打开开关,微信会将对方3小时内发送的第一条消息全屏提醒,并伴随着震动.无论你是打开了微信ap

百度技术沙龙 - 大数据场景下主题检索应用

第48期百度技术沙龙上的<大数据场景下主题检索应用>讲座介绍了很多训练大规模主题模型的技术细节.讲座回来后,我粗略整理了下讲座上涉及的主题模型和训练大规模模型相关的资料和文献. 1. 主题模型的发展历史 a. 布尔模型 Boolean model b. 向量空间模型 VSM (Vector space model) c. 潜在语义索引 LSI (Latent semantics index) - 首先作为一种降维技术, 对doc-word矩阵进行SVD分解 d. 概率潜在语义分析pLSA e.

缓存在高并发场景下的常见问题

缓存一致性问题 当数据时效性要求很高时,需要保证缓存中的数据与数据库中的保持一致,而且需要保证缓存节点和副本中的数据也保持一致,不能出现差异现象.这就比较依赖缓存的过期和更新策略.一般会在数据发生更改的时,主动更新缓存中的数据或者移除对应的缓存. 缓存并发问题 缓存过期后将尝试从后端数据库获取数据,这是一个看似合理的流程.但是,在高并发场景下,有可能多个请求并发的去从数据库获取数据,对后端数据库造成极大的冲击,甚至导致 “雪崩”现象.此外,当某个缓存key在被更新时,同时也可能被大量请求在获取,

多线程场景下延迟初始化的策略

1.什么是延迟初始化 延迟初始化(lazy initialization,即懒加载)是延迟到需要域的值时才将它初始化的行为.如果永远不需要这个值,这个域就永远不会被初始化.这种方法既静态域,也适用于实例域. 最好建议“除非绝对必要,否则就不要这么做”. 2.延迟初始化线程安全的一个策略:同步 延迟初始化的一个好处,是当域只在类的实例部分被访问,并且初始化这个域的开销很高,那就可能值得进行延迟初始化. 但是在大多数情况下,正常的初始化要优先于延迟初始化.因为在多线程的场景下,采用某种形式的同步是很

【Vue】浅谈Vue不同场景下组件间的数据交流

浅谈Vue不同场景下组件间的数据“交流” Vue的官方文档可以说是很详细了.在我看来,它和react等其他框架文档一样,讲述的方式的更多的是“方法论”,而不是“场景论”,这也就导致了:我们在阅读完文档许多遍后,写起代码还是不免感到有许多困惑,因为我们不知道其中一些知识点的运用场景.这就是我写这篇文章的目的,探讨不同场景下组件间的数据“交流”的Vue实现 父子组件间的数据交流 父子组件间的数据交流可分为两种: 1.父组件传递数据给子组件 2.子组件传递数据给父组件 父组件传递数据给子组件——pro