互联网视频是怎样送进千家万户的

前些天同学聚餐,有人提了个问题:很多人同时看电视不卡,同时看网上的视频直播为什么就卡呢?电视是广播(跟收音机本质一样),而互联网视频走的是点对点的 IP 网络,多一个人看视频,服务器就要多发一份数据。

互联网视频究竟是怎样送到千家万户的呢?我从通信领域顶级学术会议 SIGCOMM 2013 里窃取了一些科普知识与大家分享。

互联网视频的进化

第一阶段:1992 ~ 2004

这是互联网视频刚刚起步的年代,当时的视频主要是组织内部的,因此大家都在网络上做文章,用预留带宽、优化包调度算法之类的办法来保证视频的流畅。

对于多人视频会议这样的场景,研究者们早就想到了多一个人看视频就多一份数据的问题,于是有了 IP Multicast,视频服务器只发一个包,上面标着多个目标地址,网络设备就会把包复制若干份送到每个目标那里。

视频的分层结构就诞生于这个年代:

  1. 网络抽象层:视频传输协议或视频文件格式,如 RTP/IP 用于实时网络视频,MP4 用于视频文件存储,MMS 用于流媒体,MPEG-2 用于广播。视频文件的扩展名就是这一层的。
  2. 视频编码层:这一层决定视频流是如何被编码和压缩的,过程很复杂,这就是传说中的 codec 了,如 MPEG-2,MPEG-4 ACP,H.264/AVC,H.265/HEVC。一般越新的编码标准在相同质量的前提下压缩率越高,编码所需的计算资源也更多。如下图所示,codec 只规定了如何解码而没有规定如何编码。一般音频流和视频流是独立编码的。
    h264-1h264-1

这个年代 PC 市场刚刚起步,各公司纷纷推出私有视频标准抢占蓝海。Web 仍然是纯粹的网页浏览,视频还局限于客户端上。以 BitTorrent 为代表的 P2P 技术以整个文件的形式分发视频。

video1video1

第二阶段:2005 ~ 2011

2005 年 Youtube 创立,标志着互联网进入了在线视频时代。越来越多的传统电视台在互联网上播出,草根创作的视频打破了电视媒体的禁区。

这个年代,Flash 是互联网视频技术的事实标准。它可以在所有操作系统和浏览器上工作,使用 Adobe 的专有 RTMP 协议。Flash 也在不断改进,如 2006 年的 Flash Player 9.0 + ActionScript 3.0 采用了新的虚拟机和 JIT 编译器,提高了 Flash 执行速度10倍以上。

CDN(Content Delivery Network)技术在不断成熟,这样不用一台服务器往所有客户端发视频数据了,可以把视频数据发给 CDN 节点,再让 CDN 节点就近发给客户端,降低了单台机器的负载,更重要的是提高了用户访问视频的速度。

video4video4

第三阶段:2011 至今

2010 年,移动互联网的热潮袭来。iPhone 和 iPad 都不支持 Flash,Adobe 也在 2012 年宣布停止 Android 平台上 Flash 的支持。

现在,互联网视频要考虑四种不同的屏幕:PC、智能手机、平板、智能电视。不同的屏幕上用户行为和视频应用都有所不同。这还不说 Windows、Mac、GNU/Linux、Android、iOS、Windows Phone 等多个操作系统平台。

视频分发协议的进化

第一代:HTTP 下载

video3video3

最简单的方案是浏览器把视频下载完,再送给播放器播放。这样不仅不能直播,看一个视频还要先等很久。于是做了改进:

  1. 浏览器下载一个 meta file(元信息文件)
  2. 浏览器启动对应的播放器,把 meta file 交给它
  3. 播放器自己去跟 server 建立 TCP 连接下载视频文件,边下边播
    下面这段示例代码就是用的这种改进方案:
    ` <video poster=”http://www.html5rocks.com/en/tutorials/video/basics/star.png“ controls>
    &lt;source src="http://www.html5rocks.com/en/tutorials/video/basics/Chrome_ImF.ogv" type='video/ogg; codecs="theora, vorbis"' /&gt;
    
    </video>`
    然而,简单的 HTTP 会尽可能快地下载。比如我的网速是 10Mbps,而视频的码率只有 1Mbps,则缓冲就会越积越多,浪费的系统资源和网络带宽。

此外,HTTP 下载的是一个固定码率的大文件,不能根据网络情况动态调整。如果网络条件很差,我宁愿看标清,也不愿意忍受着卡顿看高清。

第二代:专有流媒体协议

以 Adobe 的 RTSP 和 RTMP 为代表的专有流媒体协议基于 TCP 或 UDP,而非 HTTP。一般有一个控制连接,一个数据连接(就像 FTP 一样),控制连接为流媒体开始、复位、快进、暂停等提供了原生支持,不再需要用 HTTP Range Request 模拟了。

浏览器端的架构跟第一代的改进方案没有区别。服务器端维护着连接状态。

不过,专有流媒体服务器的授权价格高昂,而且所用的专有端口容易被防火墙封锁。

第三代:HTTP 流媒体

HTTP 流媒体相比第二代技术,除了端口号换成了 80,承载协议换成了 HTTP,最重要的区别是由客户端维护状态和控制逻辑,服务器无需维护状态。这本质上是 “瘦客户端” 与 “胖客户端” 之争,在服务器性能随着用户量增加越来越成问题、客户端计算资源过剩的大背景下,很多 Web 应用都把本来是服务器端做的事转移到客户端上,顺便还提高了操作的响应速度。

服务器将视频内容预先转换成不同的码率,分好块,每块都以关键帧(key frame)开始,这样块与块之间就是互相独立的。客户端通过一个 “反馈循环” 动态决定该采用怎样的码率。根据一块的下载速度估计带宽(下图左上角橙色块),选择当前带宽下最高可行的码率(绿色)。客户端决定需要下载新块的时候(蓝色),就会去下载当前码率的下一个块。

video5video5

视频为什么会卡

video2video2

大家都知道互联网视频是有 “缓冲” 的。开始看视频时,首先缓冲一定时间的内容,然后一边下载新内容一边播放,如果播放的速度高于下载速度,没有可播放的内容时,就会暂停下来下载内容,直到又缓冲了一定时间的内容,再恢复播放。

video6video6

上面提到,客户端会通过 “反馈循环” 动态调整码率。可惜的是,实验结果显示,这种反馈不会使各客户端的码率趋向平衡,而是出现了像下图一样的抖动(横坐标时间,纵坐标码率,三条线是三个客户端,黑框圈起来的是抖动剧烈的部分)

video7video7

另一个问题是客户端间的公平性。按说不论何时开始下载,得到的码率应该都差不多。但考虑如下的情况,客户端 A、B 同时开始下载,客户端C在另一个时刻开始下载。理想情况下,A、B 的下载速度永远是 1Mbps,C 的下载速度永远是 2Mbps,根据 “反馈循环” 算法,A、B 看到的码率永远比 C 低。

video8video8

究其原因,一方面是采用了高层的 HTTP 协议,只知道一个视频块的整体下载时间,而无从得知每个包的延迟;另一方面是每个客户端 “各自为政”,没有中心协调。因此,基于 HTTP 的无状态协议不是万灵药,有得必有失。

衡量视频分发的质量

传统的视频分发质量测试是计算视频的信噪比,再发一大堆调查问卷请观众打分,看这两组数据间的相关性;互联网时代,发调查问卷过时了,采用的是更加客观的指标,比如视频被播放的时长(如果视频质量不好,用户就会中途退出);也不用信噪比这种学术味浓厚的指标了,代之以缓冲时间、平均码率等用户实际感受得到的指标。

事实上,主流视频网站都会悄悄上传一些统计信息,包括开始播放失败的次数、开始播放的缓冲时间、卡播比(播放过程中缓冲时间的比例)、缓冲速度、平均码率、显示帧率等。

video9video9

用视频被播放的时长比例作纵轴,用各种指标作横轴,就得到了如下图所示的曲线:

video10video10

显然,卡播比(Buffering Ratio)对用户体验的影响最大,也就是比开始播放时间、码率、显示帧率等都更重要。另一项研究显示,卡播比每增加 1%,用户播放时间就会降低 3 分钟。

video14video14

当然,相关不意味着因果。是否有可能是某些因素的组合比任何单个因素都重要呢?这些因素之间是否有相关性呢?可以用 information gain 等方法来深入探究。(让我想起了概率论与数理统计课程……)

该用哪个 CDN 节点?

在天朝这种运营商互联互通极差的环境里,CDN 显得尤为重要。简单想想也是,就近下载肯定比从远处下载要好。问题是,大型视频网站会在多地、多个 ISP 部署 CDN 节点,如何决定哪个节点是 “就近” 呢?

互联网由于管理的需要,将 IP 地址划分为数千个 “自治区域”(Autonomous System),每个自治区域有一个唯一的编号(ASN)。一个自治区域一般归属一个组织,例如科大就是一个自治区域。如果两个客户端位于同一个自治区域,则基本可以肯定它们属于同一运营商。

只根据自治区域号(ASN)还是不够的,因为同一个自治区域有可能横跨大江南北,这样不同地理位置理应访问地理上比较近的 CDN 节点。因此,还需要基于 GeoIP 数据库,划分若干目标用户区域(Designed Market Area,DMA)。

对每个(ASN,DMA,CDN)三元组,统计卡播比、开始播放时间、失败率等指标,得出如下所示的图(左右两侧各是一个 CDN 节点):

video11video11 video12video12

对每个(ASN,DMA)组合,取出最优的 CDN 节点,就得到了想要的 CDN 分发方案。当然,这里没有讨论时间的影响,有些地区白天和晚上的网络情况还不一样,此时可以做更细粒度的分析。

video13video13

互联网视频的生态系统

几个月前,几家运营商联合宣称微信要收费,引发了一场舆论风暴。事实上,我们应该从一个生态系统的角度看待这个问题,因为链条中的任何一个环节都不可能做亏本生意。例如互联网视频就是由版权提供商、平台提供商、CDN 提供商、网络运营商、最终用户、广告商等多种实体构成的生态系统。

video15video15

随着视频占据互联网流量越来越大的比例(如今已经达到一半以上,还在不断增长),互联网视频对整个互联网基础架构的压力再也不能等闲视之了。生态系统中的各方共同进化,将是互联网视频发展的必然趋势。

本文回顾了互联网视频的进化、视频分发协议的进化,讨论了视频卡顿背后的原因和解决方案,以及如何选择 CDN 节点。我们也看到了越来越多样化的客户端平台、越来越大的视频市场,以及现有网络架构给视频分发带来的一系列问题。本人才疏学浅,也不是专业做这个的,欢迎批评指正 和/或 深入讨论。

References

  1. Internet Video: Past, Present and Future. http://conferences.sigcomm.org/sigcomm/2013/ttliv.php
  2. Overview of the H.264/AVC video coding standard. http://ip.hhi.de/imagecom_G1/assets/pdfs/csvt_overview_0305.pdf