MediaMelon QBR Review: Optimizing Video Streams One-by-One

The easiest way to conceptualize MediaMelon QBR is as a server-side, per-title delivery mechanism. That is, whereas per-title encoding analyzes your video file before encoding to determine the optimal bitrate ladder, QBR analyzes the stream after encoding but before delivery. Then, QBR delivers segments at “the optimal visual quality,” rather than the highest bandwidth conditions would currently support.

MediaMelon claims QBR reduces bandwidth costs and buffering, and delivers “complex scenes at higher bitrates than the average available data rate, improving perceived quality.” After a quick primer on how to implement MediaMelon QBR, we’ll discuss whether our testing confirmed these claims.

How it Works

QBR works in both VOD and live applications. There are multiple integration modes, but the one we tested was probably most typical, and involves both server and player integration (Figure 1). Specifically, you add the QBR Plug-in at the server to analyze each encoded file and create a metadata map of the visual complexity of the stream. You integrate QBR functionality into your player via an SDK. During playback, the player downloads the metadata file first, which it integrates into the playback decision tree. That is, at any specific bandwidth level, it tells the player which stream to retrieve based upon relative quality. Communicating with the player, the QBR Dashboard tracks efficiency savings and performance.

Figure 1. The prototypical QBR architecture.

Figure 2 shows the playback side; note the analysis of scene complexity on the lower left. On the top right, the typical ABR player will retrieve streams based upon bandwidth. In all three scenarios shown, the bandwidth is sufficient to retrieve the Medium layer.

QBR has two modes—bitrate and quality—which you control when you integrate the SDK into the player, though it can change from video to video. In bitrate mode, or QBR (a) in Figure 2 (the middle option on the right), QBR delivers acceptable quality with maximum bitrate savings. In the Figure, you see QBR (a) dropping the data rate during low complexity scenes, but not boosting it when scenes get more complex. In bitrate mode, QBR retrieves less data than the legacy player, saving bandwidth costs.

Figure 2. The player side of QBR.

In Quality mode, QBR delivers the best possible quality while saving bandwidth when it gets the chance. On the bottom right, you see QBR (b) both decreasing the data rate during low complexity regions, and increasing the data rate during higher complexity regions. In essence, the player “saves up” bandwidth for the high bitrate stream in the complex regions by retrieving low bitrate streams when scene complexity is low, improving quality while also reducing bandwidth costs, at least for the example shown.

QBR works with H.264 and H.265, and in HLS, DASH, Smooth Streaming, and HDS ABR formats. All software modules are free, and you pay based upon two models, either total hours consumed or number of subscribers.

One Major Short Term Caution

On its website, MediaMelon claims “QBR upgrades existing streaming workflows and systems. It uses the encoders, players and asset libraries you already have, simply adding new metadata that allows packagers and players to optimize adaptive bitrate streaming.” While this may be true in some cases, it’s definitely not true in all cases, at least in the short term. Here’s why.

As currently implemented (and tested), QBR can only choose between streams encoded at the same resolution. Looking at Figure 2, for example, QBR would only work if all streams shared the same resolution. If the streams were 360p, 720p, and 1080p, the technology wouldn’t work. According to company officials, cross-resolution switching is in beta testing, and should be available soon, perhaps by the time this article is released. While that’s good news, since many encoding ladders don’t have many repeated resolutions, it also adds to the technical challenge undertaken by the server side module that creates the complexity map that controls operation.

Specifically, today, the non-referential content analyzer only has to compare streams of the same resolution, assessing, for example, how much better a 6 mbps 1080p streams looks than a 4.5Mbps stream 1080p stream. Once MediaMelon releases cross resolution operation, it will have to compare 360p @ 1.2Mbps with 540p @1.8 Mbps, balancing the quality loss inherent to scaling to lower resolutions with the greater compression loss of the lower bits per pixel values of higher resolution videos.

As an example, Netflix solves this riddle by encoding at multiple resolutions and quality levels and comparing the results with VMAF, a time-consuming, brute force approach that’s warranted by the amount of video views each Netflix video normally achieves. YouTube uses a neural network, and other vendors, like Brightcove and Capella Systems, encode the content one or more times to gauge complexity. All use referential quality control metrics that compare the encoded file with the original, a luxury that MediaMelon doesn’t have.

How well MediaMelon can manage this transition, and whether they can still perform it for live video, remains to be seen. Still, analyzing what’s in front of us today, MediaMelon delivered on most promises, though your results will vary by content type, encoding ladder, and average viewer bandwidth.

Testing Overview

We focused our tests on two issues; does QBR save bandwidth, and can it save up bits during simple regions to enable higher bitrate delivery for complex regions.

To make our encoded media receptive to QBR operation, we created an encoding ladder with three instances of 360p resolution, at 500 Kbps, 900Kbps, and 1300Kbps, two at 720p, at 1.8 Mbps and 2.6Mbps, and three at 1080p, at 4.3Mbps, 5.7Mbps, and 8.1Mbps. Originally, we encoded our test clips ourselves and sent them to MediaMelon, but after several corrections, we sent the original media files to MediaMelon for their preparation. We played back all videos from a test page created by MediaMelon that used the hls.js player.

We tested at multiple bandwidths by using a hardware throttling tool and recording segments downloaded with the Charles Web Debugging Proxy. Not surprisingly, our results varied significantly by effective throughput. Two issues that impacted the throughput levels that we tested are illustrated in Netflix’s ISP Speed Index and Akamai’s State of the Internet report, which paint very different pictures.

According to the Netflix, “The Netflix ISP Speed Index is a measure of prime time Netflix performance on particular ISPs (internet service providers) around the globe, and not a measure of overall performance for other services/data that may travel across the specific ISP network.” That said, if you’re an OTT service distributing over the Internet, you would expect your rates to be similar. Notably, in August, the peak rate reported by Netflix was 3.99 Mbps. In contrast, Akamai’s Q1 2017 State of the Internet Connectivity report found that the average US bandwidth for 1Q2017 was 18.7Mbps.

Best Case Bandwidth Tests

Initial tests focused on determining bandwidth savings under ideal conditions, using a simple talking head video clip retrieved at 15Mbps and then 4Mbps. Figure 3 shows the results obtained from the MediaMelon player. On the right, you can see the encoding profile used. On the top right, you see that the ABR default player would have retrieved 117.56MB compared to 62.24MB retrieved by QBR in quality mode, a savings of 47.06%.

Figure 3. QBR results courtesy of MediaMelon’s test player.

The graph in the playback window shows the theoretical ABR retrieval in yellow, and the actual QBR retrieval in blue. In this simple clip, there was no region where QBR retrieved a higher bitrate than ABR. For this reason, there was no “segment uplift” as detailed in the figures on the upper right.