《周四橄榄球之夜》流媒体视频拆解：Twitch VS Amazon Prime

文 / Phil Cluff

译 / 王月美

原文链接：https://mux.com/blog/thursday-night-football-streaming-technology-showdown-amazon-prime-vs-twitch/?from=groupmessage

文章转载自LiveVideoStack公众号

想要阅读更多技术干货文章，欢迎关注网易云信博客。

了解网易云信，来自网易核心架构的通信与视频云服务。

在英格兰长大的我会公开承认美式橄榄球并非我的第一运动项目选择，但无论以任何人的标准，美式橄榄球都是非常流行的。去年亚马逊在其Prime Video平台上开始直播流媒体《周四橄榄球之夜》。几个月前，他们宣布将此协议延长了两年。

最近，亚马逊开始通过在亚马逊Prime Video和Twitch上举办《周四橄榄球之夜》来进行自我竞争（提醒：亚马逊在2016年以约9.7亿美元收购了Twitch）。据我所知，这是第一次在Twitch上直播大型（非电子竞技）体育赛事。

我在旧金山办公室的同事们都对梦幻橄榄球赛很是着迷，所以当我发现自己和团队一起观看《周四橄榄球之夜》时，我想，“嘿，这背后的堆栈是什么？”和“Twitch 流媒体与在Twitch播放器中播放的亚马逊Prime 流媒体是同一个吗？”

好吧，接下来让我们深入了解一些体育盛会流媒体架构吧！

Twitch (左图) vs Amazon Prime Video (右图)

怎样理解流媒体架构？

研究流媒体服务背后的技术堆栈实际上并不那么难，尤其是在业内多年从事调试各种奇怪的客户设置并帮助他们过渡到新系统之后。我在这里所做的一切你都可以自己进行尝试，而你需要的只是一个浏览器，curl，bento工具包，以及良好的网络视频工作知识。

亚马逊Prime—流媒体堆栈拆解

我们将主要关注桌面浏览器的策略，因为它是最容易调试的平台。因此，让我们全身心投入，并在Chrome中加载Amazon Prime播放器，然后启动网络检查器。

我们需要找什么呢？首先，让我们假设Amazon和Twitch正在使用完善的流媒体技术，如HLS或MPEG DASH。而这两种技术都依赖于称为“清单”的文本文件来描述视频呈现并让浏览器知道从哪里获取视频片段以进行回放。

对于HLS，我们通常是在网络检查器中查找.m3u8文件；而对于DASH，我们要查找.mpd请求，或者有时只查找.xml请求。幸运的是，该这种情况下， Amazon Prime似乎正在为它们的流使用MPEG DASH和更传统的.mpd文件扩展名。

如果我们将请求过滤到.mpd并观察视频流一段时间，我们会注意到每隔几秒就会重新请求清单。这样播放器就可以知道最新的内容块何时可用以及从何处获取内容。通过查看清单，我们可以了解很多有关Amazon Prime视频传输环境的信息。我们来看看下面的（稍微缩短的）清单。

<?xml version="1.0" encoding="UTF-8"?>

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:scte35="urn:scte:scte35:2013:xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" availabilityStartTime="2018-10-24T06:01:19.831000+00:00" id="201" minBufferTime="PT30S" minimumUpdatePeriod="PT5S" profiles="urn:mpeg:dash:profile:isoff-live:2011" publishTime="2018-10-26T03:17:16" suggestedPresentationDelay="PT2.000S" timeShiftBufferDepth="PT299.000S" type="dynamic" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd">

 <BaseURL>../../../../../../../../../../../SFO/clients/dash/enc/9tojxgpp-1/out/v1/8130a6b1cfb24c2aa27b73b90de12d82/</BaseURL>

包装：MPEG DASH，H.264以2秒fMP4片段编码

如果我们看一下清单中的一些表示（即处理），会发现亚马逊正在使用的编解码器和媒体包装技术。我们可以检查“编解码器”字符串以了解正在使用的编解码器，以及通过“mimeType”来检查打包方式。编解码器字符串实际上包含了许多编码为RFC 6381字符串的信息，包括正在使用的H.264的profile。在清单中传输此信息非常有用，因为它允许您使用API来确保该特定版本的编解码器可在设备上解码。亚马逊使用的是用于视频的H.264和用于音频的AAC的通用组合方式。亚马逊为其台式机播放器使用了9个视频再现，范围从288p到720p30p @ 8 Mbit。他们还以4种不同语言展示了1个解复用的音频再现。

检查清单中的SegmentTemplate，我们可以看到片段正以.mp4文件扩展名提供（一般情况下，但有些人选择为其片段扩展提供.m4f）。如果我们在观看内容时更改我们的过滤器以查找“.mp4”，我们会看到每隔几秒钟发生一次段请求。另外，亚马逊是分别提供音频和视频片段（分解复用）。

我们还可以使用SegmentTemplate来计算视频片段的长度。从查看视频录像开始，我们看到frameRate设置为“30/1”。接下来我们可以看到录像的时间刻度是“30”。当我们将它与SegmentTimeline中每个段的声明持续时间（d =“60”）结合起来时，我们可以计算出每个段包含60帧@ 30 FPS，因此为2秒的内容。当以流式传输实时视频时，段长度是很重要的，因为它会严重影响端到端传送的延迟。实际上，两秒是可行的最低段持续时间，该情况下不会对编码器性能和终端用户缓冲体验产生负面影响。

广告的插入：多个DASH周期

我们在DASH清单中看到的顶级元素是Periods。向下滚动清单，我们看到有几个顶级周期实体。多周期MPEG DASH是一种在直播视频流中实现广告插入的方式。在这种情况下，我们会看到长时间的内容，然后是包含广告的多个较短的时段。

我们可以从之前查看的HTTP请求中学到更多信息，特别是让我们看一下Segment响应中的X-header。

有趣的是X-MediaPackage标题，它们是无意中暴露亚马逊使用AWS的Elemental MediaPackage产品的确凿证据。我们可以在清单请求上再次查看标题，以确认清单是否是由AWS的Elemental MediaTailor产品所提供。 MediaTailor是一种基于清单操作的服务器端广告插入（SSAI）解决方案，因此现在我们知道亚马逊是如何为《周四橄榄球之夜》进行广告替换的了（可能还有广告定位）。

DRM：CENC加密

从清单中我们还可以看到亚马逊是如何保护其内容¬的——我们可以看到两个不同的ContentProtection块嵌套在Representations中。 ContentProtection块定义了客户端可用的对内容进行解密的不同方法。

<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"/>

<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95"/>

上面的两个UUID在业内是众所周知的——它们告诉我们亚马逊正在使用Widevine（edef8ba9）和Playready（9a04f079）的通用组合。这将在普通桌面、移动平台以及最流行的OTT设备上实现相当全面的覆盖。

CDN交付：Akamai和CloudFront

查看亚马逊的清单，我们可以看到媒体段的BaseURL在其开头没有URL方案。这意味着视频片段通过与清单相同的CDN基础设施提供服务。回到我们原来的过滤器找到清单文件，我们看到清单的主机名（以及段）是https://aivottevtad-a.akamaihd.net。akamaihd.net是Akamai拥有的边缘主机名，它让我们知道，对于此次视图，亚马逊使用Akamai向最终用户交付其视频片段。

现在开始就很有趣了，因为我希望将AWS CloudFront视为主要媒体CDN。业界里众所周知，AWS正在媒体领域大力推动CloudFront，尤其是在与全球产品相比网络连接最佳的美国。我确实和几个其他观看相同流的人核实过，并确实也发现了至少一个CloudFront而非Akamai提供的流。混合中可能还有更多我们还没有发现的CDN。在美国公开赛期间，我也发现Amazon Prime在英国使用Limelight来交付视频片段。

鉴于Amazon Prime Video的规模和成熟度，他们将使用多个CDN来提供某种程度的冗余是有道理的。但是，值得注意的是，鉴于他们当前的策略是在其清单中使用相对主机名，而不是在其边缘主机名之上使用任何形式的DNS间接，那么在当前架构中的中级流CDN切换将无法维持QOS（或至少需要相当复杂的播放器修改）。密切关注他们的方法，看看他们是否选择采用中流CDN切换，如果是这样，那么他们是购买现成的还是建立自己的解决方案呢？这将会很有意思。

视频编码器：AWS Elemental Media Live

到目前为止，我们已经验证了亚马逊正在使用他们自己的AWS Elemental软件解决方案。我们检查了他们的包装和广告插入技术，但对编码器一无所知（让我们正视它，如果它不是Elemental，我会感到非常震惊）。这有点难以鉴定，但我们可以做一件简单的事情来获得一些提示。

对于MPEG-DASH流，初始化段用于每个视频或音频再现以在客户端侧设置解码器。我们可以在SegmentTemplate初始化属性下的DASH清单中看到这些mp4段的URL。可以下载其中一个初始化段并使用Bento的mp4dump工具转储内容。我不想详细介绍MP4结构（尽管几年前我曾在Demuxed上就这个主题发表了演讲），但我们可以在moov/trak/hdlr框中看到以下有趣的层次结构：

mp4dump --verbosity 3 amazon-init.mp4

// Trimmed for space saving

[moov] size=8+1693

  [trak] size=8+595

  ...

    [mdia] size=8+495

    ...

      [hdlr] size=12+48

        handler_type = vide

        handler_name = ETI ISO Video Media Handler

通常来说，hdlr框由编码器设置为可识别的东西。在这种情况下，“ETI”是Elemental编码器设置的识别标识。我不知道它究竟代表什么，但我猜测是“Elemental转码一些东西”。实际上，我认为亚马逊将再次使用AWS Elemental MediaLive进行实时编码。

亚马逊—推测架构

警告：一些预先推测。

当我们将上面学到的所有内容放在一起时，我们可以为亚马逊如何为《周四橄榄球之夜》构建他们的视频传输栈提供一个非常全面的图片——让我们来看一个架构图。我们假设亚马逊至少使用了我们所知道的CDN，当然可能还有更多。

实际上，对于这种高profile的东西，我预计架构中也会有一定程度的冗余，可能是在不同AWS区域运行的多个独立支路。我们已经知道有一些形式的流启动CDN切换正在进行，但我确信亚马逊不止于此。

老实说，这是一个非常可靠的实时流媒体架构，真正反映了亚马逊对自己的AWS和Elemental产品目录的承诺。对于我来说的一大惊喜是Akamai在他们的交付堆栈中处于前沿和中心位置。即使它看起来似乎与CloudFront进行负载平衡，但是肯定有很多数据流经Akamai —CloudFront最大的竞争对手之一。

Twitch -流媒体堆栈拆解

那么Twitch到底是什么？它是存在于他们的播放器中但仅仅是相同的内容？嗯，这将更有意思......但同时也包含了更多的猜想。从Twitch工程师的谈话中我们知道，Twitch在内部构建了大部分视频基础设施，这使得我们更难以比较业界已知平台的响应，但让我们看看我们可以弄清楚一些什么。

我们将采用与上次在Twitch上启动Chrome游戏并寻找清单请求相同的策略。 Twitch是用Apple HLS格式提供内容的忠实拥护者，所以让我们从寻找.m3u8文件的请求开始。

First try! 如此迅速Twitch似乎不太可能只是输入亚马逊Prime视频流并对其进行重新包装。让我们检查Twitch的主要清单，看看我们可以学到什么。

#EXTM3U

#EXT-X-TWITCH-INFO:SUPPRESS="true",MANIFEST-NODE="video-weaver.sjc02",BROADCAST-ID="30929838144",MANIFEST-CLUSTER="sjc02",NODE="video-edge-a242e4.sjc02",MANIFEST-NODE-TYPE="weaver_cluster",CLUSTER="sjc02",SERVER-TIME="1540523190.00",TRANSCODESTACK="2017TranscodeEvent_V2",USER-IP="98.210.167.151",SERVING-ID="54fa5e185b94450ab67e1edd3b68cec0",ABS="false",STREAM-TIME="15636.023155"

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="chunked",NAME="720p60 (source)",AUTOSELECT=YES,DEFAULT=YES

#EXT-X-STREAM-INF:FRAME-RATE=60.000,BANDWIDTH=6622552,RESOLUTION=1280x720,CODECS="avc1.4D4020,mp4a.40.2",VIDEO="chunked"

https://video-weaver.sjc02.hls.ttvnw.net/v1/playlist/Ct0Ds6pAbATHFHWuAFVkXteyoZK9Z2PHT-yJpD6-Y3meL9myH6K1DfiSXEGFacqiv-_hmdut19Gn5ye6XZWblmWS1zAKTy8eJONaMYv5Jxz7E0a7hEWxHFnmTUD4IWjEgk57m6IBHHxynZJp5Rp7mIigS6ycHqiTNgWcISWQ9jPpeNtOA9XKISN7GvvI0shGQS7QJZ-DlMPDF39R5o2fbAoHNUekFUcqorg7pOAkfm5SxNO5ikadvXi3g9v1-alJ-Im_LY9ZkQ1BT44uYWsxpqFj15tcgsmY5cSJkCk1AbV9KxXOapla1QQ_Xu1kUpeCdnFzjSk1pTPY0axz3DE_X7ibAMZcsZmNUFDgrN7ofYxdNEAO-fU1C7wWQ697PojkWsd7drfZA478us8lRdSTxeRSOJtnxHArqAeCYBFnxGxzM_TtzOe5k3sHlwoIsY0UmJ6e5drbh7Sm2hZQ46GNRaca4llhzRDg_dkgAZX0WQgHThyga6NxvYM4JJmXeerNjyNxqVSgqOH1LOWwuGZgX22g238GS-b0E39R8rbjTyG6reCUgqMp5A6DGtvvHWQCTliNMjpsu8PSqddYOti2x2Bj3gzI2e3H0w_1OMEmgz8FH491Ye_I5VhCjtUb8yIsEhAuBp5oVXr0Hq_cZ2g8E7B6Ggxg7Pw9W3aEEMZ8Ubk.m3u8

# 5 other renditions removed to save space.

这是一个非常标准的HLS主清单，其中包含一些Twitch元数据—根据HLS规范，播放器应该忽略他们不理解的语句。让我们看一下在Twitch方面为亚马逊所看到的相同区域。

包装：HLS，H.264以2秒fMP4片段编码

仅从主清单中我们就可以知道Twitch正在使用哪些编解码器进行交付——在#EXT-X-STREAM-INF CODECS 字段中，我们可以看到从Amazon Prime上看到的相同编解码器组合—H.264和AAC。 Twitch提供6个再现，从160p到720p 60fps。这与我们之前在亚马逊上看到的非常接近。但是，在Twitch的情况下，最高比特率为6.6Mbps，但帧率更高。这可能是高运动内容的最佳选择。同样值得注意的是Twitch比特率和分辨率比亚马逊更低，这意味着Twitch正在更加积极地为用户提供蜂窝或低性能互联网连接服务。

由于Twitch正在使用HLS，我们需要执行额外的步骤来获取精密封装所使用的任何信息。正如我们在HLS博客文章中所解释的那样，HLS使用多个清单——一个清单列出了所有可用的处理，然后另一个清单，用于每个处理中的细分。因此，让我们看看其中一个处理清单——我们可以从主清单中提取URL并将其下拉。

这是有意思的地方。由Twitch提供的处理清单包含HLS声明的版本6(#EXT-X-VERSION:6)，这意味着Twitch正在使用HLS的一些现代和有趣的功能——也确实如此。我们发现,Twitch使用#EXT-X-MAP:URI指向fMP4初始化段——该方法仅包含在最新版本的HLS规范中。我们也可以下拉清单查看所有的段URL均指向.mp4片段。

这与Twitch通常的策略有很大不同—长期以来，Twitch一直是使用更传统的传输流段包装格式（.ts）。但是这种新方法是否表明Twitch的战略发生了根本性的变化，还是有一些更明显的原因可以促成这种变化？

事实证明，答案实际非常简单—Twitch似乎是对《周四橄榄球之夜》流进行DRM。据我所知，这是Twitch第一次在他们的平台上对内容进行DRM。自从我开始研究这个主题以来，我一直在关注TwitchPresents频道，并且我没有看到DRM被用于任何Pokemon或Bob Ross剧集中。我猜想《周四橄榄球之夜》的合同规定了DRM的要求。

值得庆幸的是，在HLS中，我们无需进行任何数学计算来获得媒体片段的持续时间——这些信息整齐地包含在清单中每个媒体片段的正上方。在这种情况下，我们可以看到每个段前面都有 #EXTINF:2.002，表示段长度超过2秒：

#EXT-X-PROGRAM-DATE-TIME:2018-10-26T03:06:27.559Z

#EXTINF:2.002,live

https://video-edge-a242e4.sjc02.abs.hls.ttvnw.net/v1/segment/LONGTEXT.mp4

DRM：CENC加密

那么我们如何判断Twitch是否在其fMP4 HLS流上使用DRM？当然，我们需要再次将Bento MP4倾销工具拿出来。我们可以获取在演示清单中声明的初始化URL并下载它以查看其中包含的数据。

这次我们要转储文件并查找pssh框，这些框声明了可用于解密文件的可用DRM技术。在HLS中，关于内容加密的数据必须嵌入在媒体中，因为在清单文件中仅提供用于传递FairPlay DRM信息的规范。

mp4dump --verbosity 3 twitch-init.mp4

// Trimmed for space saving

[pssh] size=12+75

    system_id = [ed ef 8b a9 79 d6 4a ce a3 c8 27 dc d5 1d 21 ed]

    data_size = 55

    data = [...]

[pssh] size=12+966

    system_id = [9a 04 f0 79 98 40 42 86 ab 92 e6 5b e0 88 5f 95]

    data_size = 946

    data = [...]

如果我们仔细观察这些 system_id ，会注意到它们与我们在Amazon Prime流的DASH清单中的ContentProtection块中看到的UUID相同。这使得我们可以推断出Twitch也在使用Playready和Widevine来保护他们的桌面流。

广告的插入：Twitch Weaver

Twitch的视频流也有广告，但不是电视节目上的广告。通过查看主清单，我们可以看到正在使用的再现清单URL指向称为“Weaver”的内容https://video-weaver.sjc02.hls.ttvnw.net。

正如我们几周前在Demuxed上了解到的那样，Weaver是Twitch的HLS广告插入服务，它通过声明播放列表中的不连续性并插入广告内容的片段来将广告拼接到视频流中。这种方法在业界是相当标准的，并且比使用多周期DASH要简单得多。

CDN：Twitch （可能）的CDN

现在这里的事情开始变得更加朦胧了。如果我们尝试重现我们最后一种方法来得出Twitch正在使用什么CDN，我们就会毫无头绪。查看片段来源的Twitch的URL，我们得到主机名video-edge-a242e4.sjc02.abs.hls.ttvnw.net—但这对我们没有任何帮助。

然而，业界众所周知，Twitch运行自己的CDN——我检查了其他来自Twitch的视频流，它们似乎来自于与我在观看《周四橄榄球之夜》时记录的相同IP范围内的类似主机名。反向DNS查找和IP WHOIS查找没有显示任何特别有用的内容，仅仅是IP范围归Amazon / Twitch所有。

视频编码器：Twitch的（可能）编码器

试图弄清楚Twitch正在使用的编码器也是具有挑战性的。首先，我们可以尝试使用我们之前使用的相同方法来转储hdlr框的内容，但遗憾的是它给了我们一个非常笼统的答案：

mp4dump --verbosity 3 twitch-init.mp4

[hdlr] size=12+33

    handler_type = vide

    handler_name = VideoHandler

然而，我们可以根据Twitch员工公开发表的谈话进行假设。去年在Streaming Media East盛会上，Yueshi Shen和Ivan Marcin就Twitch的上一代和下一代转码架构进行了精彩的讲解。在这次演讲中，Yueshi谈到了他们的新架构是如何围绕英特尔的Quick Sync且基于成本，稳定性和视觉质量的组合上构建的。我认为最佳的假设就是Twitch正在使用他们常用的Quick Sync编码器链进行视频编码。

Twitch — 推测架构

警告：一些预先推测。

在这个阶段，我们已经尽可能的学习，但没有获得有关Twitch如何构建的内部知识。我再次提出了一个理论架构图，我认为这就是Twitch如何在内部布局的。

我提供的评论是，在这种情况下，一切都是Twitch专有软件，这并不是非常令人震惊的，但是可以肯定地说Twitch的方法在延迟方面独有优势，我将会在下一节中进行讨论。

用户体验

如果我没有提到最终用户体验，我认为很失败。从最终用户的角度来看，这两种服务之间的体验是不矛盾的且具有可比性。对于我来说—至少在相当稳定的互联网连接上—视频流畅，在任何平台上都没有缓冲或视觉质量问题。

但是，我想强调的是：两个平台之间有一些显著不同的终端用户体验。

延迟

在观看游戏时，显然Twitch流明显领先于Amazon Prime Video流。不幸的是，在我们的实验中，我们无法访问有线电视流以验证传统广播的差异，因此我无法准确估计我们正在讨论的挂机有多远，但我可以给出一些比较数据。

为测试相对延迟，我刷新了两次流，让流时间稳定下来，然后在Twitch流上采用可视标记，启动我的秒表，并等待Amazon Prime流追赶相同的视觉标记。

流之间的差异相当惊人。平均而言，Twitch流比亚马逊Prime流提前12秒。在一些尝试中，差异仅为10秒，而在其他尝试上则为16秒。

这非常值得深究。在10月的LiveVideoStackCon 2018上，Twitch Principal Research Engineer沈悦时介绍了通过HLS实现的低延迟直播。

如果我们从今年早些时候Akamai的Will Law对Demuxed的“低延迟流”的定义中，我们可以看到Twitch和亚马逊现在大致落在哪个规模上。

现在让我们说亚马逊的挂机延迟时间约为10-15秒，Twitch约为5秒。Will将把亚马逊描述为坚定在“遗产延迟范围”，而Twitch则处于“低延迟范围”的前沿。

在这个特殊的情况下，Twitter有很长的路要走，亚马逊需要有一些追赶。

平台覆盖

我还想提一下在研究这篇文章时我注意到的另一件事。Twitch为《周四橄榄球之夜》添加DRM似乎对该流可用的平台产生了影响。

正如Twitch在自己的博客上指出的那样，流媒体“可在网络和移动应用上使用” ——这意味着Twitch传统上达到的一大堆平台（包括Chromecast，PS4和XBox One）目前并不支持他们的《周四橄榄球之夜》视频流。这与Amazon Prime Video的平台形成鲜明对比，在这个平台上，在亚马逊有Prime Video应用程序的任何地方直播似乎都可以使用。

总结

哇，很长的文章，祝贺你学习这么久！鉴于我们已经完成的工作，我总结了以下每个实现的关键技术细节：

作者注：此数据仅适用于提供给桌面浏览器的视频。其他技术可能会用于某些本机设备，特别是iOS应用程序。

现在进行一些评论。在构建块级别，该架构实际上看起来非常不同，但这里使用的是相同的基本方法，即使技术堆栈的细节有所不同。

两种方法都使用H.264和AAC，两者都使用受Widevine和Playready保护的2秒fMP4片段，两者都使用基于清单操作的SSAI插入策略。但是，Twitch的内部编码，CDN和封装架构使他们能够以更高的帧速率提供更低延迟的流。而亚马逊具有显着更高的顶级比特率和更全面的设备占用空间的优势。

虽然亚马逊的方法非常依赖AWS Elemental的产品，但它也是一个很好的参考架构——他们可以使用AWS Elemental产品套件进入市场并说“嘿，它应用于《周四橄榄球之夜》”，那在高端直播流媒体市场中是非常有价值的。

最后一个想法。在Twitch上花费近10亿美元之后，在观众延迟显着降低的情况下，如果Twitch的方法似乎提供了相同的体验质量（这对于直播体育是至关重要的），那为什么亚马逊不将其用于它们的Prime Video流呢？