Recently I sat at a café with my colleague Mark Ogle, senior streaming solutions engineer at Unified Streaming (and someone far smarter than I).
Unified Virtual Channel was our subject: the new product from Unified Streaming that lets you do all sorts of cool things. Mark happens to be the lead developer of Unified Virtual Channel. So I figured hey, he’s the guy to talk to.
Hi Mark, how do you take your coffee?
Just black, thanks.
Here you go.
Thanks. You’re not having anything?
Nope. Congratulations on the launch of Unified Virtual Channel!
Thanks, it was a group effort.
People might see the words “virtual channel” and say, hey, what’s that?
So a virtual channel’s an OTT-only live linear channel. It gets produced virtually from other sources.
What sources?
Well, they could be pre-encoded VOD (video on demand) assets, or other live streaming channels that are already being produced with a more traditional workflow, where you have a broadcast playout system feeding into an encoder, feeding into a packager.
And why would you want to launch a virtual channel, anyhow?
Lots of reasons. You can have a live sports channel that wants to fill time in between live events with thematic VOD content. You might have regional channels, where you’re switching to a localized feed, just for the news and weather, or to play alternate content if there are regional blackouts, or if content rights aren’t available. And of course, the exciting thing at the moment is a FAST channel.
Oh you mean the free advertising-supported TV model that lets you—
Reuse your existing VOD library and intersperse it with ads, so you can create new channels and open up new revenue streams. Yes. That’s the one.
Why Unified Virtual Channel now?
Well, around a year and a half ago we developed a VOD2Live solution that didn’t handle seamless transitions between playlists. It was a complex setup for customers and it didn’t include support for live sources. Since then the market’s changed, particularly in the way FAST aggregation platforms have grown. The market changes raised new challenges that we needed to find a way to solve.
Can you name a few of the challenges?
Sure, a few examples would be seamlessly transitioning to a new playlist without breaking playback, updating an existing channel, or running a truly 24/7, linear service, where you’re switching to a new playlist every day.
Seems like a lot. How’d you plan?
We came up with a few goals for the new solution. First we wanted to simplify the deployment of all the tools and the associated workflows. And we wanted to make it API-driven so it’s really easy for a system developer to interact with. We really needed to solve the problem of transitions between playlists and make sure they’re truly seamless. And we also wanted to start supporting the stitching of live and VOD sources.
How’d you solve those issues?
The concept we came up with is a fix we’re calling transitions. They let you update an already running channel by switching seamlessly either to a new VOD2Live playlist, or to a live source. So if you wanted to swap out the program at 8 p.m. today, you could create a new playlist for the entire day with this change of the program at 8 p.m. And then you schedule a transition to the new playlist anytime between now and 8 p.m.
Can you show me?
Sure.
[Mark takes out some colored markers from his jacket and draws a diagram on a napkin.]
The red line here is the Virtual Channel output. What you’re seeing initially is that we’re playing out from VOD2Live playlist A.
At a specific time we want to switch to a live source to play out a live event. So we schedule this transition, and then the Unified Virtual Channel output switches at that time to this live source X.
Once the live event is over, we want to switch to a different VOD2live playlist, playlist B. So we schedule a transition to this new playlist at the time that the event ends, and the virtual channel output switches over to the different playlist.
Now, another example that’s kind of similar is reusing these playlists, so we might want to have a single playlist for the entire day, but we just switch out for a specific time block for a live event, and then we switch back to this playlist.
How’s that work?
Well, again, we start with the virtual channel output being based on the VOD2Live playlist A. It looks like this.
When it comes time for the live event, we transition to this live source X. Then, at the end of the live event, we schedule a new transition where we transition back to playlist A, but this is always moving forward. So it’s basically a new instance of this same playlist that’s used for the virtual channel output.
So in order to support both of these use cases of using live and VOD sources, we have two types of inputs that are supported. They’re all based on the SMIL playlist standard. So you can have a VOD2Live playlist that basically has a configuration section in the header and a media playlist in the body, where the media playlist is just listing a whole set of assets to be played in order.
If you do this, then a VOD2Live channel will start at the time specified and the playlist will just loop forever.
What if you want to use an external live channel as a source?
We support that, too. Obviously there’s no media playlist being used. So the configuration is just a link to the live source that’s being streamed from an external Unified Origin.
So how does all this actually work?
What we provide is Unified Virtual Channel, which is basically this “virtual channel in a box” concept. It’s a set of Docker containers that run all of the services provided with a Docker compose file. So basically it’s really easy to launch and you just run it, and everything is there.
Actually using it, everything starts with a SMIL playlist. Like this.
Cool diagram. You drew that really quickly.
Thanks.
What am I looking at here?
This is a picture of the workflow. You deliver a SMIL playlist to the API. That’s then going to trigger an automated workflow to process this playlist, which runs Unified Remix, it runs mp4split, it checks all of the media, makes sure everything is available and lined up, and then makes it available on a Unified Origin, ready to be streamed out.
Then you give your players URLs for HLS or DASH manifests, as normal. And the player makes a request exactly, as they always do. But in this case, there’s a new component which we’re calling manifest proxy that sits in front of the Unified Origin to handle all of the complicated logic around making a seamless transition between different sources.
The great thing that this manifest proxy with transitions allows us to do, is use external live sources. So you can schedule a transition to a live source that’s being played out in a kind of traditional way, where you have a playout system feeding into a live encoder, feeding into a live origin to do the packaging, and then it’s going to a CDN.
You can pull that live stream from the CDN.
So you’re reusing all of the media segments that are already in a CDN and already cached.
Right, and you just create a new virtual channel that references those media segments.
And are the API and manifest proxy like, deluxe add-ons? Separates? Part of an expansion pack?
No. The API, manifest proxy, it’s all baked into the product. It’s all one. You get Unified Virtual Channel, you get everything.
Very cool. You want a top-up on your coffee?
No, thanks, I gotta run.
Thanks, Mark!
Any time.
How about tomorrow?
No.
