Virtual production studio

Why do we need a virtual production studio

Outside broadcasting - OB is a term used for field production done from a location away from a regular television studio. OB is very commonly used during televising of live sports events, music concerts, etc. Raw footage/signal is fed into production truck for processing, recording and possibly transmission.

These production trucks are really mobile production studios, with all the required applications and equipment required for production and post production of live events. These trucks are a very costly piece of equipment.

The notion of a virtual production studio (VPS) is to virtualise the production and post-production applications and host them in a cloud. Raw footage/signal would be supplied to the VPS where actual production and post-production of the content would take place. This will obviously allows the broadcasters the ability to tune their capacity to produce and broadcast live events to meet the actual market demand. Meaning that the capacity to produce content is not limited by the number of production trucks available. The added benefit is that costly equipment need not be on the road.

Ideal platform for these applications

So the idea is to move these production applications into a centrally hosted platform. Important characteristics for the platform would be:

1. Ability to spin up the application platform -VPS- as close to the live event as possible; ideally at the network edge to reduce latency
2. Automation to enable push button launch/deploy of applications.
3. Ability to scale applications (increase or decrease number of instances) to appropriately service number of events being broadcasted.
4. The nature of these applications may also require that the underlying platform be uncontested or must adhere to delivering well defined QoS.

Consider the three (3) basic cloud models for VPS:

1. IaaS: infrastructure as a service
2. PaaS: platform as a service
3. SaaS: software as a service

IaaS

IaaS enables users to spin up workload from OS (Operating System) level and up. This obviously gives a fair amount of control to the user regarding how application is packaged. This requires automation via use of scripting tools. Most commonly used scripting tools are Ansible, Puppet, Chef, etc. Using these scripts and tools, automation is performed by orchestrating the underlying API provided by the IaaS platform (e.g. AWS, Google Cloud Platform, OpenStack distribution, internal hypervisor based cloud, etc).

Drawback of this approach is that the automation script ties you into a certain platform. For e.g. automation scripts developed for AWS would need significant refactoring for Google Cloud Platform. And this is a fairly significant disadvantage as VPS needs to be deployed in various locations. And it won’t be valid to make assumptions on availability of specific IaaS platforms.

SaaS

An application available via SaaS would be an attractive proposition. Reason being that the SaaS model inherently removes the operational risks. Though in this scenario given the critical aspect of reducing latency, following three (3) work against SaaS:

1. Shared platform - most of the SaaS applications are multi-tenanted so will be sharing the platform with other tenants/customers.
2. Location - more often than not, SaaS applications are hosted out of a centralised data centre/cloud which could introduce significant network latency.
3. Integration - VPS would require fair bit of integration between encoding, decoding, mixing applications. Again integrating SaaS based applications involves fair amount of network chatter, potentially introducing latency.

PaaS

PaaS is deployed on top of IaaS and provides best of both the worlds with enough automation and control from IaaS and the necessary abstraction (hiding of technical details) provided by SaaS.

Applications developed and deployed on enterprise ready PaaS like Red Hat OpenShift abstracts the applications from the underlying infrastructure. Red Hat OpenShift can be deployed on almost any infrastructure which can run RHEL 7. This allows for a larger install base than developing application deployment scripts for specifc IaaS platform.

Added benefit of this approach is that Red Hat OpenShift facilitates deployment of applications using micro-services design pattern. OpenShift is built using widely used functional components like:

1. Doker is a very popular implementation of Linux containers. It streamlines packaging of distributed applications.
2. Kubernetes is orchestration, management, and self-healing engine for Linux container.
3. Git for source code management
4. Jenkins for continuous integration framework

This makes PaaS an ideal platform for virtual production studio.