當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

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

發(fā)布時間：2025/3/8 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了《周四橄榄球之夜》流媒体视频拆解：Twitch VS Amazon Prime 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

文 / Phil Cluff

譯 / 王月美

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

文章轉(zhuǎn)載自LiveVideoStack公眾號
想要技術(shù)干貨文章，歡迎關(guān)注網(wǎng)易云信博客。

了解網(wǎng)易云信，來自網(wǎng)易核心架構(gòu)的通信與視頻云服務(wù)。

在英格蘭長大的我會公開承認(rèn)美式橄欖球并非我的第一運動項目選擇，但無論以任何人的標(biāo)準(zhǔn)，美式橄欖球都是非常流行的。去年亞馬遜在其Prime Video平臺上開始直播流媒體《周四橄欖球之夜》。幾個月前，他們宣布將此協(xié)議延長了兩年。

最近，亞馬遜開始通過在亞馬遜Prime Video和Twitch上舉辦《周四橄欖球之夜》來進行自我競爭（提醒：亞馬遜在2016年以約9.7億美元收購了Twitch）。據(jù)我所知，這是第一次在Twitch上直播大型（非電子競技）體育賽事。

我在舊金山辦公室的同事們都對夢幻橄欖球賽很是著迷，所以當(dāng)我發(fā)現(xiàn)自己和團隊一起觀看《周四橄欖球之夜》時，我想，“嘿，這背后的堆棧是什么？”和“Twitch 流媒體與在Twitch播放器中播放的亞馬遜Prime 流媒體是同一個嗎？”

好吧，接下來讓我們深入了解一些體育盛會流媒體架構(gòu)吧！

怎樣理解流媒體架構(gòu)？

研究流媒體服務(wù)背后的技術(shù)堆棧實際上并不那么難，尤其是在業(yè)內(nèi)多年從事調(diào)試各種奇怪的客戶設(shè)置并幫助他們過渡到新系統(tǒng)之后。我在這里所做的一切你都可以自己進行嘗試，而你需要的只是一個瀏覽器，curl，bento工具包，以及良好的網(wǎng)絡(luò)視頻工作知識。

亞馬遜Prime—流媒體堆棧拆解

我們將主要關(guān)注桌面瀏覽器的策略，因為它是最容易調(diào)試的平臺。因此，讓我們?nèi)硇耐度?#xff0c;并在Chrome中加載Amazon Prime播放器，然后啟動網(wǎng)絡(luò)檢查器。

我們需要找什么呢？首先，讓我們假設(shè)Amazon和Twitch正在使用完善的流媒體技術(shù)，如HLS或MPEG DASH。而這兩種技術(shù)都依賴于稱為“清單”的文本文件來描述視頻呈現(xiàn)并讓瀏覽器知道從哪里獲取視頻片段以進行回放。

對于HLS，我們通常是在網(wǎng)絡(luò)檢查器中查找.m3u8文件；而對于DASH，我們要查找.mpd請求，或者有時只查找.xml請求。幸運的是，該這種情況下， Amazon Prime似乎正在為它們的流使用MPEG DASH和更傳統(tǒng)的.mpd文件擴展名。

如果我們將請求過濾到.mpd并觀察視頻流一段時間，我們會注意到每隔幾秒就會重新請求清單。這樣播放器就可以知道最新的內(nèi)容塊何時可用以及從何處獲取內(nèi)容。通過查看清單，我們可以了解很多有關(guān)Amazon Prime視頻傳輸環(huán)境的信息。我們來看看下面的（稍微縮短的）清單。

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

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

包裝：MPEG DASH，H.264以2秒fMP4片段編碼

如果我們看一下清單中的一些表示（即處理），會發(fā)現(xiàn)亞馬遜正在使用的編解碼器和媒體包裝技術(shù)。我們可以檢查“編解碼器”字符串以了解正在使用的編解碼器，以及通過“mimeType”來檢查打包方式。編解碼器字符串實際上包含了許多編碼為RFC 6381字符串的信息，包括正在使用的H.264的profile。在清單中傳輸此信息非常有用，因為它允許您使用API來確保該特定版本的編解碼器可在設(shè)備上解碼。亞馬遜使用的是用于視頻的H.264和用于音頻的AAC的通用組合方式。亞馬遜為其臺式機播放器使用了9個視頻再現(xiàn)，范圍從288p到720p30p @ 8 Mbit。他們還以4種不同語言展示了1個解復(fù)用的音頻再現(xiàn)。

檢查清單中的SegmentTemplate，我們可以看到片段正以.mp4文件擴展名提供（一般情況下，但有些人選擇為其片段擴展提供.m4f）。如果我們在觀看內(nèi)容時更改我們的過濾器以查找“.mp4”，我們會看到每隔幾秒鐘發(fā)生一次段請求。另外，亞馬遜是分別提供音頻和視頻片段（分解復(fù)用）。

我們還可以使用SegmentTemplate來計算視頻片段的長度。從查看視頻錄像開始，我們看到frameRate設(shè)置為“30/1”。接下來我們可以看到錄像的時間刻度是“30”。當(dāng)我們將它與SegmentTimeline中每個段的聲明持續(xù)時間（d =“60”）結(jié)合起來時，我們可以計算出每個段包含60幀@ 30 FPS，因此為2秒的內(nèi)容。當(dāng)以流式傳輸實時視頻時，段長度是很重要的，因為它會嚴(yán)重影響端到端傳送的延遲。實際上，兩秒是可行的最低段持續(xù)時間，該情況下不會對編碼器性能和終端用戶緩沖體驗產(chǎn)生負(fù)面影響。

廣告的插入：多個DASH周期

我們在DASH清單中看到的頂級元素是Periods。向下滾動清單，我們看到有幾個頂級周期實體。多周期MPEG DASH是一種在直播視頻流中實現(xiàn)廣告插入的方式。在這種情況下，我們會看到長時間的內(nèi)容，然后是包含廣告的多個較短的時段。

我們可以從之前查看的HTTP請求中學(xué)到更多信息，特別是讓我們看一下Segment響應(yīng)中的X-header。

有趣的是X-MediaPackage標(biāo)題，它們是無意中暴露亞馬遜使用AWS的Elemental MediaPackage產(chǎn)品的確鑿證據(jù)。我們可以在清單請求上再次查看標(biāo)題，以確認(rèn)清單是否是由AWS的Elemental MediaTailor產(chǎn)品所提供。 MediaTailor是一種基于清單操作的服務(wù)器端廣告插入（SSAI）解決方案，因此現(xiàn)在我們知道亞馬遜是如何為《周四橄欖球之夜》進行廣告替換的了（可能還有廣告定位）。

DRM：CENC加密

從清單中我們還可以看到亞馬遜是如何保護其內(nèi)容?的——我們可以看到兩個不同的ContentProtection塊嵌套在Representations中。 ContentProtection塊定義了客戶端可用的對內(nèi)容進行解密的不同方法。

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

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

上面的兩個UUID在業(yè)內(nèi)是眾所周知的——它們告訴我們亞馬遜正在使用Widevine（edef8ba9）和Playready（9a04f079）的通用組合。這將在普通桌面、移動平臺以及最流行的OTT設(shè)備上實現(xiàn)相當(dāng)全面的覆蓋。

CDN交付：Akamai和CloudFront

查看亞馬遜的清單，我們可以看到媒體段的BaseURL在其開頭沒有URL方案。這意味著視頻片段通過與清單相同的CDN基礎(chǔ)設(shè)施提供服務(wù)。回到我們原來的過濾器找到清單文件，我們看到清單的主機名（以及段）是https://aivottevtad-a.akamaihd.net。http://akamaihd.net是Akamai擁有的邊緣主機名，它讓我們知道，對于此次視圖，亞馬遜使用Akamai向最終用戶交付其視頻片段。

現(xiàn)在開始就很有趣了，因為我希望將AWS CloudFront視為主要媒體CDN。業(yè)界里眾所周知，AWS正在媒體領(lǐng)域大力推動CloudFront，尤其是在與全球產(chǎn)品相比網(wǎng)絡(luò)連接最佳的美國。我確實和幾個其他觀看相同流的人核實過，并確實也發(fā)現(xiàn)了至少一個CloudFront而非Akamai提供的流。混合中可能還有更多我們還沒有發(fā)現(xiàn)的CDN。在美國公開賽期間，我也發(fā)現(xiàn)Amazon Prime在英國使用Limelight來交付視頻片段。

鑒于Amazon Prime Video的規(guī)模和成熟度，他們將使用多個CDN來提供某種程度的冗余是有道理的。但是，值得注意的是，鑒于他們當(dāng)前的策略是在其清單中使用相對主機名，而不是在其邊緣主機名之上使用任何形式的DNS間接，那么在當(dāng)前架構(gòu)中的中級流CDN切換將無法維持QOS（或至少需要相當(dāng)復(fù)雜的播放器修改）。密切關(guān)注他們的方法，看看他們是否選擇采用中流CDN切換，如果是這樣，那么他們是購買現(xiàn)成的還是建立自己的解決方案呢？這將會很有意思。

視頻編碼器：AWS Elemental Media Live

到目前為止，我們已經(jīng)驗證了亞馬遜正在使用他們自己的AWS Elemental軟件解決方案。我們檢查了他們的包裝和廣告插入技術(shù)，但對編碼器一無所知（讓我們正視它，如果它不是Elemental，我會感到非常震驚）。這有點難以鑒定，但我們可以做一件簡單的事情來獲得一些提示。

對于MPEG-DASH流，初始化段用于每個視頻或音頻再現(xiàn)以在客戶端側(cè)設(shè)置解碼器。我們可以在SegmentTemplate初始化屬性下的DASH清單中看到這些mp4段的URL。可以下載其中一個初始化段并使用Bento的mp4dump工具轉(zhuǎn)儲內(nèi)容。我不想詳細(xì)介紹MP4結(jié)構(gòu)（盡管幾年前我曾在Demuxed上就這個主題發(fā)表了演講），但我們可以在moov/trak/hdlr框中看到以下有趣的層次結(jié)構(gòu)：

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框由編碼器設(shè)置為可識別的東西。在這種情況下，“ETI”是Elemental編碼器設(shè)置的識別標(biāo)識。我不知道它究竟代表什么，但我猜測是“Elemental轉(zhuǎn)碼一些東西”。實際上，我認(rèn)為亞馬遜將再次使用AWS Elemental MediaLive進行實時編碼。

亞馬遜—推測架構(gòu)

警告：一些預(yù)先推測。

當(dāng)我們將上面學(xué)到的所有內(nèi)容放在一起時，我們可以為亞馬遜如何為《周四橄欖球之夜》構(gòu)建他們的視頻傳輸棧提供一個非常全面的圖片——讓我們來看一個架構(gòu)圖。我們假設(shè)亞馬遜至少使用了我們所知道的CDN，當(dāng)然可能還有更多。

實際上，對于這種高profile的東西，我預(yù)計架構(gòu)中也會有一定程度的冗余，可能是在不同AWS區(qū)域運行的多個獨立支路。我們已經(jīng)知道有一些形式的流啟動CDN切換正在進行，但我確信亞馬遜不止于此。

老實說，這是一個非常可靠的實時流媒體架構(gòu)，真正反映了亞馬遜對自己的AWS和Elemental產(chǎn)品目錄的承諾。對于我來說的一大驚喜是Akamai在他們的交付堆棧中處于前沿和中心位置。即使它看起來似乎與CloudFront進行負(fù)載平衡，但是肯定有很多數(shù)據(jù)流經(jīng)Akamai —CloudFront最大的競爭對手之一。

Twitch -流媒體堆棧拆解

那么Twitch到底是什么？它是存在于他們的播放器中但僅僅是相同的內(nèi)容？嗯，這將更有意思......但同時也包含了更多的猜想。從Twitch工程師的談話中我們知道，Twitch在內(nèi)部構(gòu)建了大部分視頻基礎(chǔ)設(shè)施，這使得我們更難以比較業(yè)界已知平臺的響應(yīng)，但讓我們看看我們可以弄清楚一些什么。

我們將采用與上次在Twitch上啟動Chrome游戲并尋找清單請求相同的策略。 Twitch是用Apple HLS格式提供內(nèi)容的忠實擁護者，所以讓我們從尋找.m3u8文件的請求開始。

First try! 如此迅速Twitch似乎不太可能只是輸入亞馬遜Prime視頻流并對其進行重新包裝。讓我們檢查Twitch的主要清單，看看我們可以學(xué)到什么。

#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.

這是一個非常標(biāo)準(zhǔn)的HLS主清單，其中包含一些Twitch元數(shù)據(jù)—根據(jù)HLS規(guī)范，播放器應(yīng)該忽略他們不理解的語句。讓我們看一下在Twitch方面為亞馬遜所看到的相同區(qū)域。

包裝：HLS，H.264以2秒fMP4片段編碼

僅從主清單中我們就可以知道Twitch正在使用哪些編解碼器進行交付——在#EXT-X-STREAM-INF CODECS 字段中，我們可以看到從Amazon Prime上看到的相同編解碼器組合—H.264和AAC。 Twitch提供6個再現(xiàn)，從160p到720p 60fps。這與我們之前在亞馬遜上看到的非常接近。但是，在Twitch的情況下，最高比特率為6.6Mbps，但幀率更高。這可能是高運動內(nèi)容的最佳選擇。同樣值得注意的是Twitch比特率和分辨率比亞馬遜更低，這意味著Twitch正在更加積極地為用戶提供蜂窩或低性能互聯(lián)網(wǎng)連接服務(wù)。

由于Twitch正在使用HLS，我們需要執(zhí)行額外的步驟來獲取精密封裝所使用的任何信息。正如我們在HLS博客文章中所解釋的那樣，HLS使用多個清單——一個清單列出了所有可用的處理，然后另一個清單，用于每個處理中的細(xì)分。因此，讓我們看看其中一個處理清單——我們可以從主清單中提取URL并將其下拉。

這是有意思的地方。由Twitch提供的處理清單包含HLS聲明的版本6(#EXT-X-VERSION:6)，這意味著Twitch正在使用HLS的一些現(xiàn)代和有趣的功能——也確實如此。我們發(fā)現(xiàn),Twitch使用#EXT-X-MAP:URI指向fMP4初始化段——該方法僅包含在最新版本的HLS規(guī)范中。我們也可以下拉清單查看所有的段URL均指向.mp4片段。

這與Twitch通常的策略有很大不同—長期以來，Twitch一直是使用更傳統(tǒng)的傳輸流段包裝格式（.ts）。但是這種新方法是否表明Twitch的戰(zhàn)略發(fā)生了根本性的變化，還是有一些更明顯的原因可以促成這種變化？

事實證明，答案實際非常簡單—Twitch似乎是對《周四橄欖球之夜》流進行DRM。據(jù)我所知，這是Twitch第一次在他們的平臺上對內(nèi)容進行DRM。自從我開始研究這個主題以來，我一直在關(guān)注TwitchPresents頻道，并且我沒有看到DRM被用于任何Pokemon或Bob Ross劇集中。我猜想《周四橄欖球之夜》的合同規(guī)定了DRM的要求。

值得慶幸的是，在HLS中，我們無需進行任何數(shù)學(xué)計算來獲得媒體片段的持續(xù)時間——這些信息整齊地包含在清單中每個媒體片段的正上方。在這種情況下，我們可以看到每個段前面都有 #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加密

那么我們?nèi)绾闻袛郥witch是否在其fMP4 HLS流上使用DRM？當(dāng)然，我們需要再次將Bento MP4傾銷工具拿出來。我們可以獲取在演示清單中聲明的初始化URL并下載它以查看其中包含的數(shù)據(jù)。

這次我們要轉(zhuǎn)儲文件并查找pssh框，這些框聲明了可用于解密文件的可用DRM技術(shù)。在HLS中，關(guān)于內(nèi)容加密的數(shù)據(jù)必須嵌入在媒體中，因為在清單文件中僅提供用于傳遞FairPlay DRM信息的規(guī)范。

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 = [...]

如果我們仔細(xì)觀察這些 system_id ，會注意到它們與我們在Amazon Prime流的DASH清單中的ContentProtection塊中看到的UUID相同。這使得我們可以推斷出Twitch也在使用Playready和Widevine來保護他們的桌面流。

廣告的插入：Twitch Weaver

Twitch的視頻流也有廣告，但不是電視節(jié)目上的廣告。通過查看主清單，我們可以看到正在使用的再現(xiàn)清單URL指向稱為“Weaver”的內(nèi)容https://video-weaver.sjc02.hls.ttvnw.net。

正如我們幾周前在Demuxed上了解到的那樣，Weaver是Twitch的HLS廣告插入服務(wù)，它通過聲明播放列表中的不連續(xù)性并插入廣告內(nèi)容的片段來將廣告拼接到視頻流中。這種方法在業(yè)界是相當(dāng)標(biāo)準(zhǔn)的，并且比使用多周期DASH要簡單得多。

CDN：Twitch （可能）的CDN

現(xiàn)在這里的事情開始變得更加朦朧了。如果我們嘗試重現(xiàn)我們最后一種方法來得出Twitch正在使用什么CDN，我們就會毫無頭緒。查看片段來源的Twitch的URL，我們得到主機名http://video-edge-a242e4.sjc02.abs.hls.ttvnw.net—但這對我們沒有任何幫助。

然而，業(yè)界眾所周知，Twitch運行自己的CDN——我檢查了其他來自Twitch的視頻流，它們似乎來自于與我在觀看《周四橄欖球之夜》時記錄的相同IP范圍內(nèi)的類似主機名。反向DNS查找和IP WHOIS查找沒有顯示任何特別有用的內(nèi)容，僅僅是IP范圍歸Amazon / Twitch所有。

視頻編碼器：Twitch的（可能）編碼器

試圖弄清楚Twitch正在使用的編碼器也是具有挑戰(zhàn)性的。首先，我們可以嘗試使用我們之前使用的相同方法來轉(zhuǎn)儲hdlr框的內(nèi)容，但遺憾的是它給了我們一個非常籠統(tǒng)的答案：

mp4dump --verbosity 3 twitch-init.mp4

[hdlr] size=12+33

??? handler_type = vide

??? handler_name = VideoHandler

然而，我們可以根據(jù)Twitch員工公開發(fā)表的談話進行假設(shè)。去年在Streaming Media East盛會上，Yueshi Shen和Ivan Marcin就Twitch的上一代和下一代轉(zhuǎn)碼架構(gòu)進行了精彩的講解。在這次演講中，Yueshi談到了他們的新架構(gòu)是如何圍繞英特爾的Quick Sync且基于成本，穩(wěn)定性和視覺質(zhì)量的組合上構(gòu)建的。我認(rèn)為最佳的假設(shè)就是Twitch正在使用他們常用的Quick Sync編碼器鏈進行視頻編碼。

Twitch — 推測架構(gòu)

警告：一些預(yù)先推測。

在這個階段，我們已經(jīng)盡可能的學(xué)習(xí)，但沒有獲得有關(guān)Twitch如何構(gòu)建的內(nèi)部知識。我再次提出了一個理論架構(gòu)圖，我認(rèn)為這就是Twitch如何在內(nèi)部布局的。

我提供的評論是，在這種情況下，一切都是Twitch專有軟件，這并不是非常令人震驚的，但是可以肯定地說Twitch的方法在延遲方面獨有優(yōu)勢，我將會在下一節(jié)中進行討論。

用戶體驗

如果我沒有提到最終用戶體驗，我認(rèn)為很失敗。從最終用戶的角度來看，這兩種服務(wù)之間的體驗是不矛盾的且具有可比性。對于我來說—至少在相當(dāng)穩(wěn)定的互聯(lián)網(wǎng)連接上—視頻流暢，在任何平臺上都沒有緩沖或視覺質(zhì)量問題。

但是，我想強調(diào)的是：兩個平臺之間有一些顯著不同的終端用戶體驗。

延遲

在觀看游戲時，顯然Twitch流明顯領(lǐng)先于Amazon Prime Video流。不幸的是，在我們的實驗中，我們無法訪問有線電視流以驗證傳統(tǒng)廣播的差異，因此我無法準(zhǔn)確估計我們正在討論的掛機有多遠(yuǎn)，但我可以給出一些比較數(shù)據(jù)。

為測試相對延遲，我刷新了兩次流，讓流時間穩(wěn)定下來，然后在Twitch流上采用可視標(biāo)記，啟動我的秒表，并等待Amazon Prime流追趕相同的視覺標(biāo)記。

流之間的差異相當(dāng)驚人。平均而言，Twitch流比亞馬遜Prime流提前12秒。在一些嘗試中，差異僅為10秒，而在其他嘗試上則為16秒。

這非常值得深究。在10月的LiveVideoStackCon 2018上，Twitch Principal Research Engineer沈悅時介紹了通過HLS實現(xiàn)的低延遲直播。

如果我們從今年早些時候Akamai的Will Law對Demuxed的“低延遲流”的定義中，我們可以看到Twitch和亞馬遜現(xiàn)在大致落在哪個規(guī)模上。

現(xiàn)在讓我們說亞馬遜的掛機延遲時間約為10-15秒，Twitch約為5秒。Will將把亞馬遜描述為堅定在“遺產(chǎn)延遲范圍”，而Twitch則處于“低延遲范圍”的前沿。

在這個特殊的情況下，Twitter有很長的路要走，亞馬遜需要有一些追趕。

平臺覆蓋

我還想提一下在研究這篇文章時我注意到的另一件事。Twitch為《周四橄欖球之夜》添加DRM似乎對該流可用的平臺產(chǎn)生了影響。

正如Twitch在自己的博客上指出的那樣，流媒體“可在網(wǎng)絡(luò)和移動應(yīng)用上使用” ——這意味著Twitch傳統(tǒng)上達(dá)到的一大堆平臺（包括Chromecast，PS4和XBox One）目前并不支持他們的《周四橄欖球之夜》視頻流。這與Amazon Prime Video的平臺形成鮮明對比，在這個平臺上，在亞馬遜有Prime Video應(yīng)用程序的任何地方直播似乎都可以使用。

總結(jié)

哇，很長的文章，祝賀你學(xué)習(xí)這么久！鑒于我們已經(jīng)完成的工作，我總結(jié)了以下每個實現(xiàn)的關(guān)鍵技術(shù)細(xì)節(jié)：

作者注：此數(shù)據(jù)僅適用于提供給桌面瀏覽器的視頻。其他技術(shù)可能會用于某些本機設(shè)備，特別是iOS應(yīng)用程序。

現(xiàn)在進行一些評論。在構(gòu)建塊級別，該架構(gòu)實際上看起來非常不同，但這里使用的是相同的基本方法，即使技術(shù)堆棧的細(xì)節(jié)有所不同。

兩種方法都使用H.264和AAC，兩者都使用受Widevine和Playready保護的2秒fMP4片段，兩者都使用基于清單操作的SSAI插入策略。但是，Twitch的內(nèi)部編碼，CDN和封裝架構(gòu)使他們能夠以更高的幀速率提供更低延遲的流。而亞馬遜具有顯著更高的頂級比特率和更全面的設(shè)備占用空間的優(yōu)勢。

雖然亞馬遜的方法非常依賴AWS Elemental的產(chǎn)品，但它也是一個很好的參考架構(gòu)——他們可以使用AWS Elemental產(chǎn)品套件進入市場并說“嘿，它應(yīng)用于《周四橄欖球之夜》”，那在高端直播流媒體市場中是非常有價值的。

最后一個想法。在Twitch上花費近10億美元之后，在觀眾延遲顯著降低的情況下，如果Twitch的方法似乎提供了相同的體驗質(zhì)量（這對于直播體育是至關(guān)重要的），那為什么亞馬遜不將其用于它們的Prime Video流呢？

總結(jié)

以上是生活随笔為你收集整理的《周四橄榄球之夜》流媒体视频拆解：Twitch VS Amazon Prime的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：互联网1分钟 |1129
下一篇： Facebook全面推出Watch Pa