Editorial Note

随着5G技术与边缘计算的发展，流媒体的视频技术也将越发精湛。现在的技术更多从视频媒体，包括流媒体的一个容器、技术、存储协议，以及在传输层面做的一些优化，这些技术都将成为实现超低时延而需要的关键技术，而超低时延将成为未来视频技术的主流。超低时延的形成也将离不开边缘计算的辅助，良好的边缘计算技术也是形成超低时延的重要辅助。本次LiveVideoStackCon 2021上海站我们邀请到了Akamai纪永康分享播放器、格式和容器编解码和视频内容准备，网络协议和数据传输，互联网流量增长趋势。

文 / 纪永康

整理 / LiveVideoStack

大家好，我是来自Akamai的纪永康。我们非常感谢LiveVideoStack的邀请来进行这个演讲。从第一届LiveVideoStackCon开始，每次都会与大家聊关于视频技术方面的演进。之前Akamai的首席视频架构师也是DASH协议组的主席Will Law和大家聊过CMAF DASH；前一届时，我们也讲过动态协议优化方面的技术方面尝试和进展。

本次我将更多从视频媒体，包括流媒体的容器、技术、存储协议，以及在传输层面优化的角度来分享。

Akamai主要提供出海客户的CDN和安全以及边缘计算的服务。Akamai是全球最大的一家CDN，同时也是CDN概念的发明者。当时的发明者和创始人麻省理工计算机系教授Tom Leighton现在依然是Akamai的CEO。

本次分享主要分为六个主题。分别是在播放器、格式和容器在过去20年以及未来的技术发展趋势；编解码和视频内容准备包括内容生产方面的技术的演进；网络协议和数据传输协议方面的演进；从Akamai平台的角度分析互联网流量增长趋势，Akamai平台承载了非常多的音视频内容，大部分视频直播是Akamai承载的包括苹果发布会，绝大多数是Akamai做的全球分发包括奥运会、世界杯；如何在大规模流量的情况下做不同层面的优化，以及最后对本次演讲内容的总结。

01

播放器、视频格式和容器

1.1 流量媒体格式和容器进展

上图是关于播放器、视频格式和容器方面的一些进展，可以看出，针对流媒体协议本身，更多且较成熟地大规模运用还是从2010年开始的。从大家一开始做流媒体协议而熟悉的RTMP，包括我们现在在做的personal broadcasting 或者个人网红直播用的FLV协议，都和RTMP有着密切的关系。

在2010年左右，当时已经有HAS技术的进展，最常见的是技术非常成熟的HLS和DASH，但当时大家还是用和厂商相关的协议，比如苹果的HLS、微软的SMOOTH等等，都是厂商的私有协议偏多。

随着协议的发展，2015年DASH出现了。它是基于ISO开放标准，与平台无关的协议。2020年，可以看到针对切片层面协议，大家更多的是在做LL，也就是超低时延的协议，包括LL的HLS和LL的DASH。2016左右，苹果也终于从它的HLS里，支持从TS变到Fragment MP4，像CMAF格式的出现。它要解决当时两大主流HLS和DASH协议之间不一致的问题，如此无论用HLS或在苹果平台或者安卓等其他平台都可以使用Fragment MP4。在用DASH的情况下，都可以用CMAF统一格式来解决存储、编码方面的二次工作或者冗余的工作量。我们认为未来在直播协议、流协议层面只会有这两个基于CMAF的HLS和DASH协议，这样协议碎片化的问题最终会被解决掉。

国内从2015年开始，大量的直播APP的协议还是FLV。从标准化的情况来看，我们认为FLV还是一个私有协议。在国内的这种生态是非常完备的，但在国外的使用环境下不是非常充足，所以如果要在海外做一些大规模的直播、直播带货、赛事直播，首选是切片协议。一方面它对于CDN的分发非常友好；另一方面，它基于标准，这对于它的生态也会逐渐完整。在国外，无论基于HLS还是DASH的应用都非常多，包括Twitch的游戏直播、YouTube还是赛事，都是基于切片协议的。在海外这样的应用非常普遍，这和我们国内做直播的场景有着很大的不同。

1.2 HLS和DASH的区别

我们具体来看看它们之间的区别。上图是一个简单的示意图，可以看到像传统的HLS和DASH是没有小切片的方式，它们一个一个地拿，拿到一个传输一个。苹果最早的建议是每个切片10秒钟，它至少要拿10个切片才能开始播放，这样本身的时延就达到30秒以上。为了解决这个问题，我们的思路非常的直接，把它做成类似于边下边播的形式，不需要一个完整的段，只要拿到其中一部分就可以开始播放，从而有效降低时延。对于HLS来说道理也是类似的。

1.3 直播流媒体的延迟

上图是这几个录屏的结果。上方是CMAF DASH，下方是CMAF HLS的方式。两个协议的时延都能低于5秒。或许大家觉得5秒在国内的直播情况下很普遍，但如果你要做一个全球事件，如世界杯、游戏直播、以及直播带货等，全球范围内实现一个相对稳定的时延并不容易。从下面在全球范围内做的具体数据可以看到，它的时延基本上不到3秒。因此CMAF可以在全球范围内做到更低的时延和更好的交互。

上图是与我们的合作伙伴THEO一起做的，以从波士顿的编码器到美西的播放器作为场景，跨越北美大陆，它可以做到稳定低于0.5秒的时延。你这边做很低的时延，是会有些trade off，卡顿也会有所上升。时延越低，抗卡顿能力就越小。从技术上来看，通过切片协议可以非常有效的做到用户所需要的低时延交互形式。

1.4 聚合视频格式

CMAF可以有效地被大家接受是因为CMAF有效地解决了HLS和DASH的分割，原来的HLS是用传统广电的TS容器，DASH一直用的是mp4的格式，现在苹果终于接受了Fragment MP4，可以通过CMAF统一的格式，让你的生产、分发和在用户的缓存层面所有的都变成一份，而不是为了适应HLS和安卓，需要有两份的存储、缓存和转码。现在通过CMAF只要一份就可以适应不同的格式。不同播放器情况下，CMAF时延的情况会不太一样，但好处在于通过CMAF分装可以适应不同的平台。左下方是LL-HLS的播放器，左上方是标准的DASH播放器，右侧是传统的HLS播放器，他们都是通过CMAF分装，但时延都不一样，在用LL-HLS和LL-DASH的情况下都可以达到2秒的时延，而用传统播放器，时延就可能要8秒甚至更长。好处是如果你有三种不同类型的客户端，那在CDN层面的缓存、存储和转码可以复用，可以有效提升缓存热度，降低存储压力，也可以提升工作流的简捷性。

上图是一些具体内容的截图。在CDN层面，它的第一个请求是没有缓存的，但随着后面几个播放器的加入，第一个播放器就CACHE HIT了，这也就证明整个缓存是可以复用的。

1.5 CMAF/CBCS

国内对于内容安全层面，包括内容版权、防盗链和有些版权方要求的DRM系统保护等层面的关注度不大。在这个层面，CMAF也做了最大程度上的沟通。可以看到CBCS的统一加密方式应该是最终的未来。虽然现在还有CTR和CBCS两种不同的加密方式，但我们认为在最终情况下，随着时间的演进和从Akamai平台上监测到的加密方式来看，绝大部分的设备都会支持CBCS。

02

编解码和内容准备

第二个主题是针对编解码和内容准备，包括转码、分装层面的一些变化。

2.1 视频质量

上图是关于视频质量的参数，包括链接、分辨率、帧数等。在过去10多年时间，有非常多的协议进行演进，包括HDMI；分辨率从1080p到4k甚至到8k；帧率也从25、30帧到现在60帧；对于SDR等技术的演进是非常快速的。从视频标准来看，更多关注的是视频编码标准，它的编码标准演化周期较长，通常情况下在7-10年会出现一个演化周期。现在大家用的最多的像AVC等，已经17年了，而现在更多的像HEVC等更强的编码算法还在不停地出现，但它的替换周期还是比较长的。现在我们依然在用相当于17年前的编码算法。

2.2 编码策略的演变

从编码的策略的来看，大家一开始还是更多以固定码率为主。

到现在来看，大家更希望做到码率自适应和编码格式的根据内容的不同的自适应，比如一个动画片和一个动作片的码率就不一样。

对于编码策略的变化，我们认为也是要自适应的。

2.3 视频压缩率和选择编码方式

像我刚才说的AVC依旧是比较主流的编码方式，但是它已经用了17年了。大家可能更加考虑的点是，我们怎么去选择一个编码方式。

我认为有几个考虑的点。但更重要的是大家做To C或者To B的业务，关心的是用户的感知质量。这之下会考虑编码成本、存储成本和交付成本有多高。如果我的设备支持HEVC、AAC这种高阶的视频解码，还是要考虑我们的内容是冷还是热，热内容我们就选择高效率的压缩，会减少我们的存储和交付成本；但如果内容非常冷，比如短视频，每个内容就访问个几次，这时候用高阶算法就会花很大的力气去压缩，那之后会不会有效是需要大家去考虑的。所以我们选择认为编码是一个动态的场景而不是一个静态，也不是说我所有的场景都会用HEVC或者AAC等等，而是要看到场景的不同选择不同的编码来做。

可以把公式反过来。在保证用户感知质量不变的情况下，我怎么去优化我的编码成本、存储成本和交付成本这几个层面。

2.4 动态编码的重要性

把编解码作为动态来实现非常关键，在海外，大家通常都会做ABR，也就是做动态码率。在海外的场景下，用户的网络情况变化非常大。如印度的网络环境已经有非常大的提升，他们的4G甚至5G的覆盖率都已经非常高，但是4G网络建设非常不均衡，他们的覆盖点很多都在大城市。这时候就能看到一现象，虽然印度观众对于视频的卡顿、帧数等有较好的容忍度。但大家还是希望能够看到比较好的场景，但这样，码率的变化范围就特别大，在大城市的码率会达到1Mb，但在某些农村就只有200kb甚至更低，才能让他进行播放。

2.5 视频分辨率

不论是长视频的OTT、优酷、腾讯等等，还是短视频的up主，短视频的抖音、快手等，都在追求高分辨率。从以前在手机上的480p，到现在很多短视频的up主都在做720p甚至1080p的视频。

现在像奇异在大陆做虚拟的演唱会或者综艺节目，分辨率已经可以做的非常高了，2K、4K甚至更高的分辨率。当然现在很多电视都支持8K，虽然8K的内容还是很少的，但是这并不妨碍8K电视的普及会对4K内容造成非常大的推动作用，我们会看到越来越多的4K内容会出现。

03

协议层面

下面我们进入到第三个层面：协议层面。协议层面会对做网络优化的人来说会比较熟悉。过去这么多年来，HTTP协议在最近几年的演变非常快。在过去十几年基本上都是HTTP1.1，在5年之前，H2的协议被采纳。现在可能更多的谈论QUIC、H3这样的一些协议。但从Akamai平台的数据来看虽然H2协议出来这么年了，采纳率依然有待提升，QUIC也是一样的。不论是从客户端的支持层面还是浏览器的层面来讲，对QUIC来讲还是在逐步的演进过程当中。因为从Akamai平台来看，大概是3年前开始在全网做QUIC，我们看到有一些长视频的用户在用gQUIC去做，而现在一些视频客户和其他客户开始考虑IETF QUIC。我们认为在今年或者明年的范围内，IETF QUIC会逐渐替代掉gQUIC，因为gQUIC是一个厂商私有协议。如果大家现在做QUIC可以考虑一下演进路线，以便将来比较容易的升级到IETF QUIC。

3.1 协议的影响

这一块是拥塞控制算法，现在用的比较多的、比较新的是谷歌BBR。从Akamai本身的数据来看，我们认为BBR并不能适应所有的场景，所以从Akamai看到的现网数据来看，我认为对拥塞控制算法的选择也是要做动态的。

现在你有非常多的运算控制算法去做，像BBR、QDK、FastTCP等，它们的算法都有自己不同的特点，需要考虑的因素也非常多，会考虑RTT、数据丢包、抖动甚至考虑服务器的负载等等。Akamai的建议是大家可以考虑综合的场景来选择合适的运算控制算法。我们也能发现现在的机器学习，包括AI的技术应用得也非常广泛。Akamai也认为动态选择也可以通过机器学习来实现，它在通过不同场景和时间的数据情况下，可以做一个动态选择，Akamai将这个选择叫做DPO(Dynamic Protocol Optimization)，即动态协议优化，你可以根据当时网络的场景不同来做一个优化。

我们也非常建议尤其是在高并发链接的情况下去采纳HTTP2协议，因为HTTPP2协议的优化结果还是很不错的。

3.2 网络协议栈

在整个网络协议栈上面看到比较多的是这三个HTTP协议，另外更多的是WebSocket和WebRTC协议，会有非常多的选择在不同的应用场景。这些都是比较主流的协议。

现在依然是手动选择的方式，在不同场景下选择不同的协议。现在像IETF和W3C也在规划新的WebTransport网络协议栈。希望能够做一种自适应的动态的选择，根据用户不同的应用场景来选择H2、QUIC还是用其他的一些协议。当然WebTransport还是处于在IETF和W3C的草案阶段。我们认为在今年下半年甚至明年的时候会有更多的应用场景和定稿出来。需要去适应不同的场景，是要可靠连接还是不可靠连接，说到底这和之前的方法论是类似的，希望动态选择是根据场景的选择，而不是一个固定选择。

04

流量规模增长

最后我们来看一下整个流量的增长规模以及在CDN层面能做哪些优化。

4.1 流量规模增长

上图是Akamai平台上显示的过去十年整个流量增长情况，是实际的峰值数据。因为去年的疫情，这个峰值量在原有的基础上有提升了40%，在这种情况下，对于整个网络的压力非常大。大家有印象的话，大概在去年4、5月份，在印度和欧洲疫情非常严重的时，欧洲的运营商，对YouTube、Amazon等几个大型在线视频厂商，TikTok短视频应用等要求降低码率。因为当时他们看到非常巨量的互联网流量，对运营商的核心网造成了非常大的压力。基于这一点，Akamai也与运营商进行了非常多的合作，在那期间CDN起到了非常大的作用，因为CDN有效地降低互联网在核心网之间带宽的拥塞。现在有的CDN厂商的思路是建设大节点，和云计算的思路类似的，比如在全球建100个大节点来覆盖全球大多数用户。从Akamai的角度来讲，我们依然认为CDN的价值是在边缘，因为CDN更多的是放在更靠近用户的地方，所以Akamai建了大概2000多个节点，我们的做法更加接近用户，和全球90%-95%的互联网用户在同一个运营商网络。在疫情期间所体现的价值会更明显，这样的架构可以有效地降低网间穿越流量，降低核心网的压力。

4.2 规模与性能

我们知道规模肯定是长的，虽然编码效率有提升，但是分辨率、用户上传的内容和视频产出的内容呈几何级数的增长。我们要统筹好规模与性能之间的关系。

4.3 Akamai对规模与性能做的探索与技术实现

大的方面是容量、性能和成本，需要做到平衡。在这方面，Akamai做了相应的探索和技术的实现。下面我将从容量模型、服务器性能、磁盘延迟、源站优化、全球网络部署这六个层面来讲述Akamai是怎么做的。

4.3.1 容量模型

现在硬件设备便宜了，内存可以做得非常大，网络接口可以做到20G、45G甚至100G。对于Akamai来讲，除了堆设备外，依然要考虑成本和最高效利用率的问题。为了达到目标缓存率，需要了解你的存储需要多大、内存需要多大；当达到相同的目标缓存率，你的运用场景不同，数据是否也会不一样，比如一个长视频或短视频或冷热视频，它的内容不同，它对缓存命中是有非常大的影响的；最后它的热度有多高，它的内容被缓存下来，是被很多人访问还是只有个别的人在访问。Akamai根据现有的流量模型做了一套算法，我们希望能够实现最合理的容量来达到最合理的缓存命中率的效果。我们针对最上层的缓存做一个曲线，就可以看到多大的缓存就可以实现特定的缓存命中率。这样的情况下，我们在和一些用户合作，比如一些用户会特别关心源站的出口带宽或源站流出的流量，我们可以把最后的回源节点做成某个用户专有的，比如回源节点的特定能力只供特定客户来用，他需要多少存储，就可以通过上图来进行判断。

4.3.2 服务器性能

第二块是说我们的服务器性能。通常对CDN来讲，如何找到特定的缓存，它的时效性非常关键。通常大家会通过HASH算法来做，我们认为HASH算法在小范围的情况下，HASH算法是非常有效的。如果在切片的情况下文件特别多；用户量大的情况下，文件特别多时，HASH算法的效率就不会很高。在这种情况下，我们Akamai就采用布隆过滤器，我们通过布隆过滤器和专有的算法，当请求到来的时候它的时延可以做到最低，当然它不能保证你的缓存能100%被找到，它有一定的错误率，但这个错误度是可以去做平衡的。采用了我们的布隆过滤器和更好的搜索算法，服务器的命中率，包括网络的使用率和硬盘的效率都有提升。上图显示的是采用前后的变化，可以看出采用前每秒的写入数是更高的，采用后，每秒的写入数变少，从而使缓存的查找效率变高。

4.3.3 磁盘延迟

第三块是指磁盘的延迟。磁盘的延迟对于CDN来讲很关键，我们希望能够把内容尽快吐出去，所以磁盘延迟是非常重要的。当然，磁盘的延迟和文件的大小是有关的。通常情况下，磁盘有个零延迟的阈值，这个值大概是800k左右，但通过Akamai的优化以后，当值大于800k时或者更大一些的时候，磁盘延迟依旧可以降到比较低的程度。

4.3.4 边缘计算实现源站卸载

上图内容是关于如何去降低源站压力。比如可以把源站的逻辑和计算卸载到CDN边缘实现，通常的计算包括边缘鉴权和中央鉴权、防盗链，甚至做一些业务逻辑，做一些访问的控制，如特定的区域用户才能访问这个内容，所以很多业务逻辑需要在边缘里去实现的。我们Akamai希望能够把更多的业务逻辑下沉到边缘，我们认为CDN是天然的、非常适合做边缘的平台，所以在CDN作为边缘计算的情况下，我们可以有效降低源站压力，把很多复杂的计算从源站扔到边缘里去做，这样一方面可以降低运维方面的压力，另一方面可以降低业务部门对运维的压力。比如说，基于 Token Authentication，并基于分布式控制，控制某个内容的访问频率，区域的限制，甚至做一些AB TEST和token的一些计算等，很多的业务逻辑都可以到边缘去实现。上图是我们为印度客户做板球世界杯直播时，它们访问量非常大。在过去两三年里，他们的直播阈值都在千万级别，而且这些访问都是在移动互联网的基础上来做的。可以看到，印度的版权方在培养了几年的用户习惯之后，他们在去年逐渐地做收费的策略，有收费之后就会出现版权墙，很多人会尝试去突破版权墙来达到免费收看的问题。但因为印度的直播是切片做的，在做切片时，你怎么把用户的访问给吊销掉，也就是说，过边缘或者源站的业务逻辑判断出你是一个盗链用户，或你是一个非付费用户的情况下，如何在你还在访问的情况下把你的访问给吊销掉，可以在边缘实现。所以一开始可以看到盗链的情况会非常高，但随着在边缘开始做封禁，它的量级就会慢慢下降，当然你很难禁掉所有的盗链，所以要在维持一定成本的情况下把尽量多的盗链给禁掉。

4.3.5 全球网络

最后一点我们从Akamai网络建设层面做的一些事情，从全球网络来看，用户访问到你的源站分为三个部分:第一个部分是first mile，也就是用户到CDN节点，这一块的事情依然延续Akamai过去一直在做的把边缘节点靠近用户，让first mile对用户的影响更小，你的CDN越接近用户，你的last mile的影响数就越小。第二部分是middle mile，指的是从CDN 节点到源站之间的网络，这一块是CDN 发挥非常大的作用的一个地方，能把你中间回源的路径，它的丢包、时延和带宽的效率提升。Akamai有一些动态的选路机制，选择各个不同运营商的路径；另一方面我们也建设了专线网络，这样能把Akamai一些中间层的点直接连接起来，让Akamai有更多的选择空间。很多客户希望CDN的回源尽可能小，Akamai做了两个方面，一方面是我们的CDN节点可以和用户的源站建立直连，通过Cross Connect直连的方式和你的源站连接起来，当然这时在源站流量特别大的情况下，比如至少10G以上，这样我们的直连才有意义；第二方面是Akamai在靠近用户源的地方部署了一些专有缓存，这个缓存就是利用了刚才的缓存算法能算出来多大的缓存量就能够回源一次，这样我们就能为某一个客户划定一个存储空间来实现他的专有缓存回源尽可能少的一个场景。

总之，视频技术在各个方面都在快速发展，流媒体的未来会向着更加高效、融合、统一的方向演进。谢谢大家。

- The cover by Sarah Pflug from Burst

讲师招募 LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社会公开招募讲师，欢迎通过 speaker@livevideostack.com 提交个人及议题资料，无论你的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的，我们将会在24小时内给予反馈。