DRM: CENC Encryption
From the manifest we can also see how Amazon is protecting its content - we can see two distinct ContentProtection blocks nested within the Representations. The ContentProtection blocks define the different methods available to the client to decrypt the content.
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"/>
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95"/>
The two UUIDs above are well known in the industry - they tell us that Amazon is using the common combination of Widevine (edef8ba9) and Playready (9a04f079). This will achieve them fairly comprehensive coverage across common desktop and mobile platforms, as well as most popular OTT devices.
CDN Delivery: Akamai and CloudFront
Looking at Amazon’s manifest we can see that the BaseURL for media segments doesn’t have a URL scheme at the start of it. This means that the video segments are being served through the same CDN infrastructure as the manifest. Going back to our original filter to find the manifest file we see that the hostname for the manifest (and thus, segments) was https://aivottevtad-a.akamaihd.net. akamaihd.net is an Akamai owned edge hostname, which lets us know that for this view Amazon is using Akamai in this case to deliver their video segments to end users.
Now, this is interesting because I would have expected to see AWS CloudFront as the primary media CDN here. It’s well known in the industry that AWS is pushing CloudFront very heavily in the media sector, particularly in the USA where it’s best connected when compared against the worldwide offering. I did check around with a few other people watching the same streams and did spot at least one stream which was being served from CloudFront rather than Akamai. It's likely that there are also more CDNs in the mix that we haven’t spotted yet. During the US Open I did also see that Amazon Prime was using Limelight to deliver segments in the UK.
It would make sense given Amazon Prime Video’s scale and maturity that they would be using multiple CDNs to provide some level of redundancy. However, it's worth noting that given their current strategy of using relative hostnames within their manifests, and not using any form of DNS indirection on top of their edge hostnames, that mid-stream CDN switching to maintain QOS wouldn’t be possible in the current architecture (or at least would require fairly messy player modifications). It’ll be interesting to keep an eye on their approach here and see if they choose to adopt mid-stream CDN switching, and if so, if they buy off the shelf or build their own solution.
Packaging: HLS, H.264 encoded in 2 second fMP4 fragments
From the master manifest alone we can tell which codecs that Twitch is using for delivery - In the #EXT-X-STREAM-INF CODECS field, we can see the same combination of codecs we saw on Amazon Prime - H.264 and AAC. Twitch is delivering 6 renditions from 160p, up to 720p 60fps. This is fairly close to what we saw on Amazon earlier. However, in Twitch’s case the top bitrate is 6.6Mbps, but at a higher frame rate. This may be preferable for high motion sports content. It's also worth noting that Twitch goes to a lower bottom bitrate and resolution than Amazon, which implies that Twitch is catering more actively to users on cellular or low performance internet connections.
Because Twitch is using HLS, we need to perform an extra step to get any information about the exact packaging used. As we explained in our HLS blog post, HLS uses several manifests - one master manifest which lists all the available renditions, and then one manifest for the segments within each rendition. So let’s take a look at one of the rendition manifests - we can just pull the URL from the master manifest and pull it down.
Here’s where it gets interesting. The rendition manifest delivered by Twitch contains the HLS declared version of 6 (#EXT-X-VERSION:6) which immediately implies that Twitch is using some modern and interesting features of HLS - and they are. We see Twitch using the #EXT-X-MAP:URI to point to an fMP4 initialization segment - this approach was only included in recent versions of the HLS specification. We can also look down the manifest to see that all the segment URLs point to .mp4 fragments.
This differs dramatically from Twitch’s usual strategy - Twitch has been a long time user of the more traditional Transport Stream segment packaging format (.ts). But does this new approach point to a fundamental change in strategy for Twitch or is there some more obvious reason for this change?
It turns out the answer is actually fairly simple - Twitch seems to be DRM-ing the Thursday Night Football streams. To my knowledge, this is the first time Twitch has DRM’d content on their platform. I’ve been keeping an eye on the TwitchPresents channel since I started researching this subject and I don’t see DRM being used on any of the Pokemon or Bob Ross episodes being shown on there. I assume that a requirement for DRM was stipulated on the contract for Thursday Night Football.
Thankfully in HLS we don’t need to do any math to get the duration of the media segments - we have that information neatly contained right above each media segment in the manifest. In this case we can see each segment is preceded by #EXTINF:2.002, which indicates the segments are a little over 2 seconds long:
#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 Encryption
So how can we tell that Twitch is using DRM on their fMP4 HLS streams? Well, we again need to get our Bento MP4 dumping tools out. We can take the initialization URL declared in the rendition manifest and download it to look at the data contained within it.
This time we’re going to dump the file and look for the pssh boxes which declare the available DRM technologies that can be used to decrypt the file. In HLS the data about the encryption of the content has to be embedded in the media because there is only a specification for delivering FairPlay DRM information in the manifest file.
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 = [...]
If we look closely at these system_ids, we’ll notice that they’re the same as the UUIDs which we saw up in the ContentProtection blocks in the DASH manifest for the Amazon Prime stream. This allows us to deduce that Twitch is also using Playready and Widevine to protect their desktop streams.
Return to Home