Operating HESP with low encoding costs
High efficiency streaming with HESP comes with a lot of advantages. It allows for sub second latency over standard HTTP CDNs, with unrivalled channel change times. The high QoE HESP delivers is the result of its main difference with alternative protocols: the use of Initialization Streams, which are streams containing IDR frames at a very high rate. By using an IDR from these Initialization Streams to kick-start the Continuation Streams starting playback of a new track can happen in a few 100ms, which in turn enables fast channel change and allows to reduce buffer sizes and latency dramatically. Initialization Streams do come at a cost: even though they are not streamed to end viewers, they need to be encoded.
When comparing HESP with other streaming protocols, there are several advantages from a cost perspective:
Streaming protocols which usually target sub second latencies such as WebRTC are often session based, which can be very costly. HESP on the other hand can scale cost-efficiently over standard HTTP CDNs.
GOP sizes dramatically impact the end-to-end latency which can be achieved for low latency HLS and MPEG-DASH profiles. Reducing the GOP size has an impact on your compression efficiency. For HESP latency is not linked to its GOP size: (the often large) independent frames can be placed where it makes sense for the content, and no set intervals are needed, allowing for a highly optimal quality-to-bit ratio. In some tests, bandwidth cost savings of about 20% become possible compared to HLS or MPEG-DASH.
There is an extra encoding cost associated to HESP though, but it is possible to tweak your Initialization Stream, as it is not a requirement that every quality in your bitrate ladder contains an Initialization Stream at the full frame rate of the Continuation Stream. When working with scenarios where full Initialization Streams are present for some streams, and sparse Initialization Streams are generated for others we see an increase of encoding CPU usage of only 15 to 23%. When compared with generic sparse frame generation for all but the lowest bandwidth, the increase even goes down to only 3% while impact on switching up remains at a minimum. While in these scenarios the cost for encoding would still go up, this is an increase which should be easily compensated by HESP’s benefits in cost to scale, improvements in GOP size (and cost reduction in egress traffic), and rise in QoE.
Interested to read more? Then definitely check this blog post, written by Pieter-Jan Speelmans, CTO of THEO Technologies.
