Delivering a high-quality live OTT experience has always been an interesting challenge. As an end user, I would always crave for best-in-class live experience, which would consist of the following:
- Channel change shall be fast!
- Video and audio quality shall be top-notch.
- Latency (time gap between a video frame seen on say Satellite/Cable broadcast to Live OTT) shall be minimal.
- No buffering, please!
On top of these, as an OTT solution provider, we always need to be aware of escalating CDN costs as our subscriber base grows!
So seemingly we have requirements that need contradictory solutions, for example
- One way to reduce channel change time is to start with the lowest bit rate segments to reduce initial buffering delay and then gradually improve the quality in an adaptive (to network speed for user) manner. However, that would entail bad AV quality post-tuning to the channel (unacceptable especially while the user is watching content on bigger screens)!
- Another popular technique to reduce channel change time is to reduce segment duration. However, that will make playback prone to frequent buffering!
- Similarly reducing segment size improves latency (vis-a-vis Satellite broadcast) of OTT playback, it makes playback prone to frequent buffering!
- An obvious solution to keep CDN cost in check is to reduce the encoding bit rate. However, this will adversely impact the user AV experience.
- Increasing segment duration would improve buffering and make encoding more efficient (thus reducing bandwidth), but would increase latency (vis-a-vis Satellite broadcast) and time to tune to the channel.
Perplexed after reading so far?
Recently at Zee5, we have undertaken an initiative to improve the live OTT user experience on our application. The following sections depict the changes done on encoding/packaging of the OTT content side and how it has significantly improved user experience on this front.
Improved user experience is quite perceptible, however, for this document, we depict the benefits with respect to relevant matrices gathered from Conviva.
We have not introduced low latency live yet on our platform. The usage of low latency live is beyond the scope of this document.
Table of Contents
Techniques Used
Setting the right segment size
This is one of the most important things to get right for any Live OTT solution. After multiple iterations, we zeroed in on 4 seconds of segment size across all our channels.
We have seen very good results with this in terms of reduction on re-buffering, but it did not impact latency (vis-a-vis broadcast) and channel tune time in an adverse way!
Transitioning to HLS CMAF
In Zee5, live OTT content was always served using HLS TS format to all devices. One of the conscious decisions we have taken is to move away from HLS TS to HLS CMAF everywhere possible for the following reasons
- CMAF (fMp4) inherently as container format ensures metadata about AV content is centralized) and often kept out of segments (in the form of init segment), thus doesn’t waste bandwidth. Also, the packing of TS packets can cause wastage of bandwidth.
- Apple has mandated HEVC can be carried only on HLS CMAF (not on HLS TS). Thus, 4K (AVC encoding of 4K is extremely expensive in term of bandwidth) can be served with HEVC encoding on 4K.
- Low latency solutions are mostly available by specs on CMAF.
- HLS CMAF is widely supported on all players/devices.
Today more than 80% of the live channels available on Zee5 are served through HLS CMAF.
Fine Tuning Encoding Parameters
The next and most important aspect of optimization was fine-tuning encoder parameters. We have fine-tuned mostly the following parameters
- Standardizing profiles and levels for different resolutions across all channels.
- Fine-tuning bit rate and QVBR level (QVBR settings are specific to AWS encoders)
- GOP length
- Positioning and frequency of open GOPs vis-a-vis closed GOP.
These changes made significant changes in bit rates for generated variants across all channels (more on this in the Results section) at absolutely no perceptual loss of AV experience!
Results for Live OTT Streaming
Reduction of Bandwidth Usage
For live, generated ABR variants pertaining to live channels from Noida (a city near New Delhi) data centre is pushed to the AWS Mumbai data centre over an MPLS, and then over Direct Connect it enters to AWS cloud. Please see below the Cloudwatch graph depicting the drop in bandwidth usage on the Direct Connect side.
As can be seen, the average usage has come down from 500 Mbps to around 370 Mbps, which is about a 25% reduction in bandwidth.
The same can be seen in the MPLS partner’s metrics in the diagram below.
Improvements Observed on Live OTT End-User Experience
We measure improvements in the end-user experience with Conviva Metrics. Some of the metrics that clearly depict end-user experience and we focus are –
- Rebuffering Ratio —> Measurement of buffering encountered by end users
- Video Start time —> Time to see first video frame from initiation of user action (i.e. channel change time in this case). Conviva includes pre-roll ad start time as part of the video start time.
- Average bit rate —> Average bit rate consumed by end users has a direct bearing on CDN cost.
- Exit before video start —> Measure of playability of content.
- Play success percentage → Ratio of attempts to play and successful plays
- Streaming Performance Index —> It is a measurement of user experience provided by Conviva.
The following table depicts the improvements on the aforementioned key parameters (we started making changes in the last week of May and ended in mid-June).
| Date Range | Rebuffering Ratio | Video Start Time* | Average Bit rate | Exit Before Video Start | Play Success Percentage | Streaming Performance Index |
| 1st January to 31st March, 2023 | 0.325% | 5.02 seconds | 3.36 Mbps | 9.78% | 88.2% | 77.2 |
| 1st April to 30th April, 2023 | 0.237% | 4.07 seconds | 3.34 Mbps | 9.73% | 87.8% | 82.2 |
| 1st May to 31st May, 2023 | 0.228% | 3.96 seconds | 3.27 Mbps | 9.58% | 88.6% | 82.1 |
| 1st June to 30th June, 2023 | 0.189% | 4 seconds | 3.12 Mbps | 8.18% | 89.9% | 86 |
The average bit rate in the first two weeks of July stands at 2.76 Mbps!
Rahul Banerjee
Rahul Banerjee is a Principal Engineer at Zee5. In his current role, he is spearheading continuous AV experience improvement for end users. Prior to working at Zee5, Rahul filed a patent on optimizing I-frame delivery in ABR content and is the author of multiple published papers.
Previously, Rahul worked at Synamedia/CISCO/NDS, Marvell Semiconductor, and LSI Logic.
