Demands on video streaming workflows are increasing. This is due in part to the sharp increase in OTT audiences, with streaming services now commonplace in most homes, and also to an increase in viewer expectations when it comes to content availability, reliability and the user experience. Any buffering or disruptions that may have impacted viewing a few years ago are simply not tolerated anymore.

Video streams today must be highly dynamic and capable of supporting many niche use-cases with a number of third-party components. There is an abundance of players to choose from, for example, and they all operate in slightly different ways with different rules for handling adaptive bit-rate profiles, timings and more. If the player you’re using doesn’t fulfil all the criteria of the broadcaster or streaming provider, then the options are either to sacrifice the desired use-case or find a fix by manipulating the manifest file.

The manifest file underpins many factors in the end user streaming experience but is often not managed well. Frequently, solutions to streaming problems are fudged together via the manifest by one or two engineers at some unspecified point in the workflow and not documented effectively, or workarounds are made that are not visible to other third-party components that can then be affected as a result.

Working towards a single format with clear specifications remains the goal to achieve a universally workable manifest, but experience shows this takes time and is still a while away. Meanwhile, streaming platforms are forced to drop crucial features that are detrimental to the all-important user experience, or rely on a series of workarounds that are often highly inefficient and can cause delays in troubleshooting while bugs are found, let alone fixed.

There are many common issues that we’ve come across at Unified Streaming which can be fixed in the manifest. Here are just a handful of examples:

• Videos starting at the wrong ABR level
• Compatibility issues with 3^rd party components
• False security alerts being triggered
• Out of sync UTC clocks causing playback issues
• Having to re-process content in order to support new languages

At the moment such use-cases are often solved through ugly non-supported workarounds later in the workflow, but these can cause unnecessary inefficiencies and headaches, especially when it comes to troubleshooting when time is often wasted trying to find out where issues are, let alone being able to fix them.

The solution: post-process the manifest

The solution is to post-process a manifest right after its generation, before it goes into the cache/​CDN. It’s a function we call Manifest Edit and it introduces all the modifications needed to enable downstream components at an earlier stage, and at the same stage, which avoids the need to fudge solutions later on. The manifest can be created according to industry specifications enabling a universal approach to development, but the post-processing approach offers the flexibility for streaming providers to step away from the spec on purpose, with a good justification, without ​“hurting” the ​“real” origin.

The post-processing approach offers greater flexibility when delivering to different services and devices. One European broadcaster we work with wanted audio in its streams to default to the local language when the viewer pressed ​“Play.” However, they found it was not possible to do this in the player they were using, so viewers would begin the stream in English and have to change the audio track manually if they wanted to view content in their native tongue. This is a pretty poor experience, but the broadcaster was struggling to find a solution. The issue was resolved when they began post-processing the manifest. They were able to step away from the manifest spec, but in a controlled and well-documented way, and adjust the default language settings.

Post-processing also creates a single point to go to for troubleshooting. This approach reduces time and inefficiencies in locating and fixing bugs because you know where to look. It also offers more flexibility and can help resolve issues more quickly with third party components. For example, if there’s a bug with the player there could be a delay in getting it resolved while you enter the process of raising a ticket and waiting for the player provider to respond. But a workaround could be achieved in the manifest to resolve the issue quicker so that it doesn’t affect the end user.

Manifest Edit: how it works

At the core of this post-processing approach is a python pipeline processing ​“engine” – no hard-coded manifest editing logic is required inside the executable. The kind of manifest manipulation that can be achieved is entirely dependent on the plugin’s capabilities and the ways they can be assembled into a multi-stage processing pipeline.

The flexibility comes from the fact that each plugin is configurable using a simple yaml syntax and that there are several ways of combining one or more existing plugins by means of a simple configuration file into the pipeline. This allows the freedom for a creative approach to problem solving/​troubleshooting. New plugins can be delivered in a short time thanks to Python’s rapid development times.

2020 has seen our industry really embrace OTT but it is clear that streaming workflows, and end user experiences, continue to differ massively from one service to another. Competition for viewer attention, and the resulting revenues, is fierce and there is increasing pressure to get the user experience right while finding efficiencies in the workflow. The manifest is the central cog of video streaming but it is handled in a very inefficient way. In time there will be a single format with clear specifications, but until that point it’s important to treat the manifest more seriously.

This article was published on TVTechnology