I recently worked on a project to address the disparate nature of many streaming use-cases, and the modifications needed in the manifest to support them. The manifest is the central cog of any streaming workflow and yet workarounds are often fudged together and not really performed in a way that takes into account the bigger picture, such as support for the many niche uses-cases that are present today. In this article I’ll explain how adding a post-processing step after the origin can help address such issues and ultimately simplify workflows.
Video streams today must be highly dynamic and capable of supporting many use cases and 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 bitrate profiles, timings and more. If the player you’re using doesn’t fulfill all the criteria of your end-user experience, 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, negatively impacting 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 some form of editing of the manifest can help resolve. Here are just a handful of examples:
- Videos starting at the wrong ABR level
- Compatibility issues with third-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.
WHY POST-PROCESSING THE MANIFEST IS DIFFERENT
By post-processing a manifest right after its generation, before it goes into the cache/CDN, a number of these issues can be resolved. It’s a function we at Unified Streaming call “Manifest Edit.” By adding this step you can make all the modifications needed to support downstream components at an earlier stage, and, crucially, at the same stage—which avoids the need to fudge solutions later on and creates a single point to look at when troubleshooting.
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.
This post-processing approach offers greater flexibility when delivering to different services and devices. A broadcaster in Europe, say, may want audio in its streams to default to the local language. However, this may not be possible in the player they are using, so viewers would have to begin the stream in English and change the audio track manually if they wanted to view content in their native tongue.
This is a pretty poor experience, but it’s a fairly common issue without an obvious solution. By post-processing the manifest, they would be 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.
POST-PROCESSING THE MANIFEST: 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 multistage 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.
The manifest is the central cog of video streaming but in many workflows 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, with a view of the bigger picture in mind. Post-processing the manifest offers the best workaround in my opinion.
Linzi McRae is project manager at Unified Streaming.
