While streaming media is rapidly becoming the dominant way in which video is consumed, current technology only offers limited flexibility when it comes to making on the fly changes to content, such as serving specific parts of a stream or inserting clips.

Up until recently, video streaming solutions focused on making video streaming as efficient as possible, while offering compatibility with all devices. If you wanted more flexible play out options, custom players on the client side were the only way forward. But such solutions hurt overall compatibility.

Which content provider doesn’t wish for personalized streams, replaceable ads or an endless live archive that is easy to maintain?

Now, Unified Remix offers the next step in the evolution of streaming technology by providing flexibility without a loss in overall compatibility. This is a welcome change for content providers that have been longing for a more flexible, all-round streaming architecture that can deliver a more capable and versatile product.

Which content provider doesn’t wish for personalized streams, replaceable ads or an endless archive of their livestream that is easy to maintain? These are but a few of the possibilities that Unified Remix opens up.

This blog post will first explain how Remix works, then detail several use cases and concludes by showing how its containerized setup can be managed with an orchestration layer that allows it to be deployed with a single command, despite its advanced multi-component configuration.

Multiple Components

The basic idea of Unified Remix is that it ​‘mixes’ clips (which can come from various sources) into a single stream. As the player on the client side won’t notice any difference or discontinuity between a stream that is or isn’t ​‘mixed’, Remix guarantees a combination of high flexibility and full compatibility.

Figure 1: Overview of a full Unified Remix setup

To achieve this, a full Remix setup consists of several separate components that work together. In essence, Remix’s overall architecture starts with a playlist written out in XML with SMIL as the markup language. This is the responsibility of a ​‘SMIL origin’.

The playlist’s construction can be rule based, consumer defined, use the info from an Electronic Programming Guide (EPG) or even the response from an ad network. From the input, the playlist defines which content from which sources should be stitched together.

As such, the SMIL origin acts as the intermediary between Unified Remix and the other parts of a video streaming setup. Because a SMIL playlist is a simple, standardized format, Remix can be deployed in a wide variety of existing setups quite easily.

Based on the contents of the playlist, Remix will generate an MP4 file that contains the references from the playlist. And while this MP4 still doesn’t contain the actual media data, it does allow the Unified Origin component to create a new, continuous stream that does, in DASH, HLS, HDS and Smooth.

A Container for Each

To make the deployment of Remix as flexible as the product itself, each of the components described above runs in a separate Docker container, which makes Remix a distributed app. We strongly believe in this approach to deployment, which ensures flexibility and compatibility and has been gaining a lot of traction over the past years.

For those not familiar with Docker: a container wraps up a piece of software in a complete file system that only contains the pieces it needs to run. Taking the complexity of a full Remix setup into consideration, the main advantage is that a container will always run in the same manner, regardless of the environment it is running in.

Remix’s containerized setup ensures it is highly flexible when it comes to customization.

Another advantage of using Docker is that containerized software, apart from always running in the same manner regardless of the environment, can be run in a wide variety of setups, because the Docker software is available for many platforms. Furthermore, it allows you to deploy the whole Remix setup by using a single Docker Compose script.

Focusing more on Remix specifically, its containerized setup ensures a lot of flexibility when it comes to customization. Because all containers run on their own it’s a straightforward process to replace a specific container with one that offers similar functionality catered to a specific use case.

This choice in setup, with many containers each running a single service, is also the reason why we chose Docker instead of a solution like LXC. While LXC is catered more towards running containerized multi service environments, similar to a lightweight Virtual Machine, the idea behind Docker is to reduce a container to a single process as much as possible, which is exactly what our approach to Remix is about.

A good example of the customization that such a setup enables, would be the creation of a specialized SMIL origin. Within most setups, a customized SMIL origin will be necessary, as it acts as an integration point with the rest of the video streaming platform and will need to create playlists based on the specific use case.

Or, another example in which you can easily customize your Remix setup is to replace the caching proxies in front of each main component. The setup we provide uses Apache caching proxies, but these can easily be replaced with Nginx, Varnish or similar.

Remixing VOD

There are several use cases for which Remix is already being used, some of them which can be tried live on our demo site. Moreover, many new Remix features will be added in 2017. The use cases which are currently being demonstrated focus on remixing VOD content.

All of Remix’s use cases work on all devices without the need for any client side customization.

So, would you like to add a clip mid-roll or after having played out the main content? You can test it right now. Or you could present a short part of a longer piece of content as if it’s a clip on its own, without the need to actually store this ​‘new clip’, because the clip generated by Remix doesn’t copy but just references the selected timeframe of the original content. Demo that here. Plus, you could even use such a clip as a bumper, or a mid-roll.

And most importantly: these use cases work on all devices without the need for any customization on the side of the customer. So yes, you could do bumpers before Remix, as well as playing a clip mid-roll or taking a short part from a longer clip and making that available. But it wasn’t possible with the kind of efficiency of Remix, nor with the wide-ranging compatibility that is offers. No need for special players, nor for extra server side storage. A ​‘Remixed’ stream just works.

Live to VOD

One thing that content providers have been struggling with for some time, is how to make the contents of a livestream available on demand in a quick and efficient manner. For broadcasters, capturing every individual program from a livestream has been a common practice, but one that has several downsides.

For example: to account for unforeseen changes in a broadcast schedule, the length of the captured clip will need to contain a margin of error (e.g. when a sports match goes into extra time). As these margins will overlap with other programs that will be captured, this practice will lead to content that is captured and stored more than once, thus increasing storage needs.

Assuming a margin of 10 minutes up front and 15 minutes after a program’s scheduled time slot (these numbers are taken from a client’s use case), this setup will be especially inefficient when dealing with a large portion of short programs (such as a weather report).

Unified Remix solves this problem because it allows for added margins without archiving any content more than once, as all of the recordings will be virtual clips. Remix can create such clips from both the archive and the live window of the livestream. Serving on demand clips from the archive is an option that can also be tested on our demo site.

With Remix a higher number of recordings won’t increase storage needs.

Another related option that is unique to Remix would be the ability for customers to record self-defined timeslots in the cloud, thus offering them freedom of choice as well as competitive recording capacities. This is possible because, as explained, a Remix recording does not contain the actual contents, but only references to content (which is stored in an archive or still part of the live window).

Thus, with Remix a higher number of recordings won’t increase storage needs. And for the same reason, you won’t run into content that’s stored more than once when making a livestream available as on demand clips, even if you would take add a margin of error to each of those clips, like described earlier.

Dynamic Ads

Apart from the use cases mentioned above, one of the most obvious applications of Remix is ad insertion. Using a server side solution like Remix to do this, has a huge advantage, as Remix ensures that there will be no discontinuity in the stream. This means that a player won’t be able to differentiate the newly inserted clip from the rest of the stream, thus giving ad blockers a run for their money and content providers a viable way to monetize a stream.

Of course, straightforward ad insertion is possible with Remix, such as playing a specific ad for everyone in front of on-demand content, or inserting a clip partway through or at the end of it. Because of Remix’s flexibility, any combination is allowed.

A more complex setup makes it possible to insert ads dynamically. In such a setup, the client’s content management system will query an ad network (based on session ID and cookies, for example). This query will result in a URL that the SMIL origin can integrate into a playlist, so that the Remix will be able to request the corresponding ad clip from the network and insert it into the original content that’s part of the playlist as well. The result of this process will be served as a new, continuous clip.

Orchestration and Deployment

Apart from the flexibility and customization that a containerized setup provides, another advantage is the variety of ready to use orchestration layers available for such setups, for example: Docker Swarm, Docker Cloud, Apache Mesos, Kubernetes and Rancher.

In a multi-container setup, these software solutions take care of a lot of the tasks of deployment, so that you don’t have to. In case a certain setup requires more instances of a certain service to run adequately, you can simply start extra instances of this service via the orchestration layer which should deal with scheduling and balancing load across them.

All of the orchestration layers that work with Docker containers, work with Unified Remix as well.

In most setups, an additional management layer will run on top of the orchestration layer. If this management layer is tied into monitoring tools, it opens up the possibility of automating certain processes based on things like the number of requests per second that a container gets, like having the orchestration layer start or stop an instance of the container when a certain threshold is reached.

As the different orchestration layers mentioned above all work with Docker containers, all of them work with Unified Remix as well. Taking Rancher as an example and with a Docker Compose script as a starting point, you only need to add a relatively simple Rancher script to be able to deploy a fully customized Remix setup with one command.

And using your own customized Rancher script, it doesn’t matter whether you want to deploy your setup on your own server or in the cloud, as the setup of services like Amazon AWS and Microsoft Azure accept Rancher scripts to automate the whole process of deployment in the cloud.

Want to know more? Curious about the way in which Unified Remix could work to your advantage? Please contact us and we will be more than happy to have a look at your use case.

‍