When you subscribe to a VOD service, you expect the best visual quality possible. For our customers across Sub-Saharan Africa, it’s no different. But, in a region with developing infrastructure and expensive data, OTT services like ours face an inevitable challenge: Providing a service that is both high-quality and affordable.
Africa - continent of challenges
Showmax is part of the Multichoice Group, and with our sister company DStv, we are the leading OTT service on the African continent. It’s a unique market relative to North America and Europe, and you really have to look at things differently. Ideas and approaches that wouldn’t work in other markets may be just the thing for certain parts of Africa.
The African VOD/OTT market is developing quickly, and infrastructure is being improved significantly, but there are still a lot of places - with millions of potential viewers - where data is a luxury. In Africa, no matter where you are, mobile data (all data, really) is expensive. As such, we are constantly looking for ways to deliver a premium streaming experience while consuming as little data as possible. In fact, Showmax was among the first VOD services to introduce a “download” feature.
The reason is simple - mobile is a huge part of our business:
Every bit counts
It’s important to remember that customers pay for our service twice - for their Showmax subscription and for data. That means that every transferred bit counts.
Here’s a rundown of how we are working to squeeze as much as we can into every last bit.
For years now, AVC/H.264 by MPEG-LA has been the primary codec for video streaming - it’s widely used and supported. But it has efficiency limits with 4K/8K resolutions, so two next-gen codecs were introduced to meet these requirements:
- Direct successor - HEVC/H.265: Currently supported by Apple devices, the Safari browser, and some smart TVs (since it became a part of the DVB-T2 standard).
- Direct competitor - VP9 by Google: currently supported by Android devices, web browsers, and some smart TVs.
We ran some tests and experiments, and decided to lower the bitrate ladder by 33% for both codecs - HEVC/H.265 and VP9 - and pushed them to production for new content.
It wasn’t so easy.
New codecs can save bandwidth, but they require more power to encode. In our case, it’s ~4x for HEVC and ~8x for VP9, respectively. So, we came up with a parallel encoding approach that we lay out in detail in a two-part blog post here and here. It helps us keep encoding time within a reasonable range for next-gen codecs (below is a time chart of one asset from our catalogue).
Where next-gen codecs really show their full power is in bandwidth-saving for higher resolutions. HEVC outperforms VP9 here as well. Below, we split a scene from the movie Sintel into thirds to show the difference. 33% in between H.264 and HEVC/VP9 is a reasonable balance for our content set that preserves quality and saves as much bandwidth as possible.
Resolution 360p HEVC and VP9 at 66% of H.264 bitrate.
Resolution 1080p HEVC and VP9 at 66% of H.264 bitrate.
Then, there’s the decoding aspect. In theory, players should choose the variant from the DASH manifest or HLS playlist based on their capabilities and supported codecs. The reality is that some smart TVs and smartphones crash when they don’t recognize the codec in the manifest/playlist, or think they are able to play that codec but can’t. To get around this, we filter out next-gen codecs from the manifests/playlist before passing it to the player on devices where issues may occur, or occurred previously. Beyond that, next-gen codecs can also be omitted if the device has only a software decoder, because it consumes too much battery and could drain it in a matter of minutes.
The future of codecs is interesting. As computational power continues to increase for devices of all kinds, there will certainly be another evolutionary generation of the VCC and AV1 codecs. Recently, AV1 was added to Android with version 10, and it’s slowly being pushed to production around the world. VCC is just slightly behind and should be standardized later this year.
Constant bitrate (CBR) encoding with a fixed bitrate ladder is the keystone of all OTT/VOD services. But videos contain fast and slow scenes, different levels of detail, and other attributes that affect complexity and the required amount of bits to encode an individual scene. In most cases, bits are wasted. To avoid waste, we built a per-title optimization system to select the correct bitrate for the best viewing experience, but no more. Nowadays, all of the big cloud encoding services like Bitmovin, Brightcove, JWPlayer, and Mux, have their own approach.
FFmpeg’s capped Constant rate factor (CRF) is a simple variant of the per-title approach. It lacks the ability to change the number of rungs in the ladder, but it’s a “one pass” method, and advanced methods usually require an extra analysis pass. As Jan Ozer says in One Title at a Time: Comparing Per-Title Video Encoding Options, the results of capped CRF are comparable to advanced technologies.
Capped CRF mode is supported by every codec we use - H.264, HEVC, and VP9. The simplified command looks like this:
ffmpeg -i input_file -crf 23 -maxrate 5000k output_file
Where FFmpeg will encode video at quality level 23 and cap the bit rate at 5000kbps. On the image below, you can see from the screen cap of Sintel that the resulting bitrate is far from the cap.
The table below contains a few examples of final bitrates for all three codecs of 1080p. The original bitrates for CBR mode were 5000kbps and 3340kbps, respectively. Simon’s cat is a simple black and white animation, and the bitrate savings are enormous here. Surprisingly, H.264 outperforms both HEVC and VP9.
|Average bit rate [Kbps]||H.264||HEVC||VP9|
|My Little Pony: Friendship Is Magic s08 e01-26||2782||1963||2442|
|Fast & Furious Presents: Hobbs & Shaw||4206||2945||3187|
|GoT s01 e01-10||3981||2524||3033|
|isiBaya s08 e01-40||4006||2832||3251|
|Simon’s cat s01 e01-48||1040||1165||1588|
Originally, our bitrate ladder started with a resolution of 360p and bitrate of 200Kb/s - which was still not low enough on Edge connectivity. So we introduced two lower steps starting at 144p resolution with a 75Kb/s bitrate focus on mobile devices. Up to this point, audio bandwidth was only a small fraction of overall bitrate, but with such a low video bitrate, we also had to re-think audio codecs. We added HE-AACv2 with 32Kb/s for very low data profiles to pass through the pipes with poor Edge connectivity.
It may sound silly if you live in an area with Fiber or 5G connectivity, but imagine you live in a rural area with limited connectivity and expensive data. The introduction of our Mobile Only subscription gives people on budget the opportunity to consume up to 20 hours of content with a 1GB data plan. It’s important to note that people tend to be more sensitive to lower audio quality than video. On smaller phone screens, the lack of video quality is mitigated while the HE-AACv2 codec keeps audio quality at a pleasant level - even with an extremely low 32kb/s bitrate.
In general, configuring VP9 is quite complicated and it often does not behave as documented - which Pitfalls in VP9 sums up very nicely. We had the biggest issue with overshooting the maximum bitrate. In the end, we switched back to CBR for very low resolutions.
Switching from VP9 to HEVC on Android
In the previous section, I noted that we serve VP9 for only ~2% of Android devices. While we were using the CBR approach, we preferred VP9 on Android as both come from Google and the HEVC and VP9 bitrates were the same. But HEVC with capped CRF provides better results than VP9.
Moreover, we found that most android devices that support VP9 support HEVC as well. That allows us to transfer these devices from VP9 to HEVC and save more bandwidth. Before the change, 25% of androids played VP9 and 23% HEVC. After change it was 2% and 45%, respectively.
After all of these changes, we had to make the important decision to re-encode the whole catalogue - even though viewership is uneven and only a small fraction of assets account for most of the actual content consumed on the app. After only a few weeks of fully utilizing our encoding farm, we can now save bandwidth that will add up to more than 40 thousands hours of content (that’s more than four years).
At the beginning, we were able to save 33% by using new codecs. After switching from CBR to capped CRF mode, we save almost 25% with mature H.264. For the next-gen codecs, the savings reached 39% and 48%, respectively. Modern codecs and per-title techniques were the main drivers of how we managed to reduce bit rate significantly while preserving video quality.