Video Delivery Methods: Broadcast, the Cloud, and the Future

The Future of Video

While online video systems were initially viewed only as competitors to traditional broadcast systems, there is a case to be made for converging the two systems. By reviewing the production and distribution workflows of each, we find several possible architectures for this convergence that we can use as a roadmap toward the future of video.

Broadcast Video Delivery Systems

Terrestrial broadcast TV systems have been historically the first technologies for delivery of videos to the masses. Cable and DTH (direct to home) satellite technologies came next as natural and highly successful evolutions of such systems. And historically, these systems have been deployed on premises, using purposely built facilities, hardware, and dedicated networks / links enabling transmission of video feeds between different facilities and entities in the distribution chain.

A conceptual diagram of the broadcast distribution system is shown in the figure below.

As shown in this figure, there are two classes of content used as input to broadcast systems. Live content typically arrives in the form of live video feeds from remote and field production. Pre-recorded, or on-demand content, may also be provided in the form of mezzanine files from production studios or video distributors.

Both live and pre-recorded videos are then directed as inputs to the master control or playout systems, responsible for the formation of a set of live TV channels. The compositions of video segments inserted from different sources in each channel is called a program. Playout systems are also typically responsible for the insertion of channel logs (“bugs”), lower thirds, slots for ads, captions, metadata, etc. Broadcast playout systems are human operated, and traditionally deployed in dedicated facilities (master control rooms).

After playout, all channel streams are subsequently encoded and passed to a multiplexer, which combines them in a multi-program transport stream (also known as TS or MPEG-2 TS) intended for distribution. In addition to the channel’s media content, the final multiplex TS also carries program and system information (PSIP), SCTE-35 ad markers, and other metadata as required for broadcast distribution. All such operations are also typically performed on-prem, by using hardware broadcast encoders, multiplexers, modulators, and other purpose-built equipment.

As further shown in the above figure, the distribution chain in broadcast systems may have multiple tiers - from the main network center to local stations and also multichannel video programming distributors (MVPDs), such as cable or satellite TV companies. At each stage, media streams corresponding to each channel can be extracted, modified (e.g., by adding local content or ads), re-multiplexed into a new set of channels, with new program tables and other metadata inserted, and then again sent down to distribution or next headend.

Cloud-based OTT Video Delivery Platforms

Typical workflows used in today’s cloud-based online video platforms (OVPs)are shown in the figure below.

Similar to broadcast systems, such workflows also ingest videos from a variety of live and pre-recorded content sources. However, most of today’s OVP platforms don’t include master control or playout functionality, and don’t form or multiplex channels for distribution. They simply encode input content as is, and package it in formats suitable for OTT delivery. Most commonly, HTTP-based adaptive streaming protocols, such as HLS or DASH are used as final delivery formats.

All processing steps in cloud-based OPV systems are typically implemented in software and operated using the infrastructure of cloud service providers, such as AWS, GCP, Azure, etc.

The Differences Between Broadcast and Cloud-based OTT Video Delivery Systems

The use of software implementations and cloud-based deployment has a number of well-known advantages. It minimizes investments in hardware, allows pay-as-you-go operation, solves scalability problems, simplifies management, upgrades, makes the whole design more flexible and future-proof, etc. However, it also brings some unique requirements and forces designs of various components and coordination mechanisms in cloud-based systems to be done differently as compared to on-prem systems.

Specific differences include:

• Granularity of data processing and delays in cloud-based OTT vs on-prem broadcast systems;
• Mechanisms used for enabling redundancy and fault tolerant operation of such systems;
• Means of scalability, load-balancing, resource provisioning, and other operations as unique to cloud-based operation;
• Mezzanine formats, contribution links and transport protocols used for ingest in cloud vs on-prem broadcast systems;
• Broadcast encoders and multiplexers vs encoders and packagers used for OTT delivery;
• Implementations of ad-splicing and ad-impression analytics; etc.

The Convergence of Broadcast and Cloud-based Delivery Systems

There are several possible architectures enabling convergence of broadcast and cloud-based OTT systems, as we see them evolving in the future.

The figure below shows the simplest model of such integration, already used in many deployments today.

As easily observed, this model offers a coupling of the existing broadcast and cloud-based OTT workflows by means of adding several extra contribution encoders, directing fully formed broadcast channels/programs to the cloud-based OTT platform.

Minimum integration efforts are needed to launch such a system. However, it requires extra contribution encoders to be installed on-prem, and only offloads functionality related to OTT delivery chain in the cloud. All broadcast-essential operations remain to be on-prem.

A diagram of a system enabling much more complete offload of broadcast-related functionality in the cloud is shown in the next figure.

Here, most broadcast-chain operations are effectively implemented in the cloud.

The most critical component that enables such migration is the cloud playout system. It operates entirely in the cloud, but enables human control and monitoring from remote terminals in the broadcast center. Functionally it is fully equivalent to the existing broadcast systems, enabling frame-accurate switching, editing, ad break placements, and other control operations as required in broadcast.

The move of playout in cloud also enables the feeds from remote and field production to be collected by the cloud platform. This eliminates the need in maintaining a farm or receiver / decoders, file servers, and various other equipment typically used for ingest. It also enables much more effective distributed, and if needed – world-scale operations, as cloud platform data centers are present in most regions.

Finally, once the playout system moves to the cloud, most subsequent operations needed for broadcast distribution – broadcast encoding and multiplexing – can also be easily migrated to cloud. This further eliminates the need in installing and maintaining farms of broadcast encoders, multiplexers, splicers, and various other equipment in broadcast facilities.

This makes the whole system much simpler to operate and maintain, and enables all other benefits of cloud operation: scalability, future proof, increased reliability, etc.

Evolution of the Brightcove Video Cloud Platform

At Brightcove, we are always looking at ways of improving our Video Cloud platform and making it a natural choice for broadcasters considering expanding their OTT offerings and/or offloading components of their existing workflows in the cloud.

In recent years, we’ve made considerable efforts in this direction. This includes:

• Adding support for broadcast-native ingest protocols: TS over RTP, SMPTE 2022-1, SMPTE 2022-2, SRT, etc.
• Improving ingest capabilities of our transcoders: improved handling of interlace content, telecine, mixed cadence content, gradual refresh streams, etc.
• Improved pre-processing and dynamic profile generation (denoising, high-quality format conversion, context-aware encoding),
• Improving our encoders to generate broadcast compliant streams (strict HRD control, CBR operation, pass-through of broadcast specific metadata, etc.)
• Improving live redundancy and fault-tolerance capabilities of the system
• Adding Cloud Playout capability to the platform.

But indeed, our work continues and we are looking forward to many other ways of improving our system and working with broadcast customers, cloud platform providers, and other technology vendors towards making mass-scale broadcast operations in the cloud a reality.

More information can be found in the October 2021 Issue of SMPTE Motion Imaging Journal. Find the article "Transitioning Broadcast to Cloud", written by Brightcove’s own engineering experts.