最近，亞馬遜開始在Prime Video和Twitch上直播大型體育賽事。流媒體專家Phil Cluff從編解碼器、包裝格式、DRM策略及CDN等方面對兩種平臺的流媒體架構進行了分析、推測。LiveVideoStack對原文進行了翻譯。
文 / Phil Cluff
譯 / 王月美
原文連結：https://mux.com/blog/thursday-night-football-streaming-technology-showdown-amazon-prime-vs-twitch/?from=groupmessage
在英格蘭長大的我會公開承認美式橄欖球並非我的第一運動項目選擇，但無論以任何人的標準，美式橄欖球都是非常流行的。去年亞馬遜在其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和亞馬遜現在大致落在哪個規模上。
在LiveVideoStackCon 2018上，Will Law介紹了通過CMAF提供低延遲直播的探索。
現在讓我們說亞馬遜的掛機延遲時間約為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流呢？
精品文章推薦
線上分享：
技術趨勢：