DASH at Amazon: Analyzing the Prime Video settings

Aside from Netflix, Amazon Prime Video is one of the biggest players in the streaming market. In contrast to Netflix they do not use the Web Crypto API to encrypt communication between the client and the backend. Hence, it is possible to sniff the DASH manifests and take a deeper to look at them.

Specific file attributes

In my test I used Google Chrome and started an episode of a series called “BEAT”.  The first thing to notice is that Amazon adds a query parameter to the request for the manifest: encoding=hex. That way, they tell the backend to hex-encode certain parts of the DASH manifest like the list of segments:

<EncodedSegmentList duration="445" timescale="100">
0000000000000000-0000000000000650;
...
</EncodedSegmentList>

Since Amazon uses gzip to compress the manifests, the difference between the hex-encoded and the unencoded file is not big. However, when the browser decompresses the manifests it becomes noticeable:

  • Hex Encoded manifest
    • Gzipped: 160KB
    • Unzipped: 724KB
  • Unencoded manifest
    • Gzipped: 169KB
    • Unzipped: 947KB

In our case they save approximately 9KB for each gzipped request. At the scale at which Amazon is delivering content this might still have an impact.

Video specific attributes

Next we can take a closer look at the MPD to identify the video encoding settings.

The content is grouped into one adaptation set for video, and three for audio. Each of the 15 different video representations have a framerate of 25 frames per second. The video segment length is listed with approximately 4.5 seconds.  Lets take a deeper look at the encoding settings:

WidthHeightAspect
Ratio
Bitrate
Kbit/s
CodecProfileBits/
Pixel

*Frame
40022416:9100H.264Constr. Main 2.20.044
40022416:9150H.264Constr. Main 2.20.067
51228816:9200H.264Constr. Main 2.20.054
51228816:9300H.264Constr. Main 2.20.081
51228816:9500H.264Constr. Main 2.2
0.135
64036016:9800H.264Main 3.00.138
70439616:91.200H.264Main 3.00.172
70439616:91.800H.264Main 3.00.258
7204803:22.400H.264Main 3.00.278
7205765:42.990H.264Main 3.10.288
96054016:92.995H.264High 3.10.231
128072016:93.000H.264High 3.10.130
128072016:94.500H.264High 3.10.195
1920108016:98.000H.264High 4.00.154
1920108016:915.000H.264High 4.00.289

Amazon offers 15 different video representations. All are encoded in H.264 with different profiles ranging from Constrained Main 2.2 to High 4.0. At the lowest resolution of 400×224 the bitrate is set to only 100Kbit/s. If we compare that to the classic “one-size-fits-all” encoding ladder of Netflix, the difference is comparatively big. Netflix lowest resolution is set to 320×240 with a bitrate of 235 Kbit/s. 
In addition, we can identify three different representations at around 3 Mbit/s. All of them are encoded with different resolutions. We can conclude that not only the bandwidth serves as an input for the quality selection algorithm of the client player, but also the device resolution. For instance, switching up to a resolution of 1280×720 is not necessary on a device whose resolution is limited at 960×540.
Interestingly the aspect ratio is not limited to 16:9 although the manifests clearly specifies a picture aspect ratio of 16:9.

<AdaptationSet contentType="video" group="2"
maxBandwidth="15000000" maxHeight="1080" maxWidth="1920"
mimeType="video/mp4" minBandwidth="100000" par="16:9"
segmentAlignment="true" startWithSAP="1"
subsegmentAlignment="true" subsegmentStartsWithSAP="1">

 Since no additional information on the sample aspect ratio is given we must assume that this attribute is not valid for two of the video representations.

At the highest resolution of 1920×1080 the bitrate goes up to 15 Mbit/s. This seems like a really high value for Full HD content. It would be interesting to know if Amazon applies some kind of title-based encoding ladder. When I compared our test episode to two different movies I always found the same encoding bitrates with slightly different framerates. From that I would conclude that no content specific encoding ladders are used. It seems odd to save bandwidth on comparatively small manifest files while possibly wasting bandwidth and storage costs on the video qualities. However, hex encoding the manifests might be benefiting for the XML parser on the client. <SegmentList> MPDs tend to become very large as each segment is listed directly.

This concludes our small dive into the video settings of Amazon Video. In the next blog post we will dive deeper into the DRM specific configuration.