# Transitioning Broadcast to Cloud
## 2 Processing Chains in Broadcast and Cloud-Based Online Video Systems
### Delay, Random Access, Fault Tolerance, and Signal Discontinuities  
In broadcast systems, many essential signal processing operations--format conversions, editing, switching, etc., are normally done with uncompressed video streams, carried over by SDI (Serial Digital Interface) [78; 79], or more recently by SMPTE (Society of Motion Picture and Television Engineers) 2110 [80] over IP. This enables all such operations to be performed with extremely short delays and with frame-level temporal precision. When redundant processing chains are employed, the switching between them in SDI domain also happens seamlessly. When streams are encoded, this increases random access granularity to about 0.5 s, which is a typical GOP length in broadcast streams.  
In streaming, as discussed earlier, the delivery of encoded videos to clients is done using segments. Such segments cannot be made arbitrarily small due to CDN efficiency reasons. In practice, 2-, 6-, and 10-s segments are most commonly used [44]. Same segmented media representations are also commonly used internally in cloud-based processing workflows. This simplifies exchanges, avoids additional transcoding or transmuxing operations, and reduces many basic stream-level operations to manifest updates. However, such design also makes random access and delay capabilities in cloud video systems much worse compared to broadcast.  
What also makes things in cloud complicated, is a distributed and inhomogeneous nature of processing resources. For instance, physical servers (or cloud \"instances\") responsible for running video processing tasks may be located in different datacenters, have somewhat different characteristics of hardware, non-synchronized local clocks, etc. The network-induced delays in accessing such instances may also be different. Processing jobs thus have to be scheduled dynamically and in anticipation of all such possible differences. Moreover, occasionally cloud instances may become unstable, non-responsive, or terminated by the cloud service provider. These are rare, but relatively \"normal\" events. Cloud workflows must be designed to be \"immune\" to such events.  
To illustrate how fault tolerance in cloud may be achieved, in Figure 3 we show an example of a live streaming system with 2-way redundancy introduced. There are two contribution feeds, marked as A and B respectively, and two processing chains, including ingest, transcoding, and packaging stages. The outputs of packages are DASH or HLS media segments and manifests. This system also deploys two redundancy control modules. These modules check if manifest and segments' updates along route A or B are arriving at expected times, and if so they just leave manifests unchanged. However, if they detect that either of these processing chains become non-functional, they update manifest to include a discontinuity marker, and then continue with segments arriving from an alternative path.  
As easily observed, this system remains operational in case if either of the chains A or B fails. It also stays operational in case of failure of one of the redundancy control units. However, what is important to note, is that in case of a failure, the switch between videos in chains A and B may not be perfectly time-aligned. The output stream will be decodable, but it may exhibit time-shift discontinuity in media content at time of switch/fallback. This comes as a result of operation in a distributed system with variable delays and different processing resources that may be utilized along chains A and B. Naturally, with some additional effort, the magnitude of such misalignment could be minimized, but that will necessarily increase complexity and delay of the system. Perfect synchronization, in principle, is one of the most challenging problems in the cloud.  
The observed differences in delays, random access granularity, and also possible discontinuities in signals coming from cloud-based workflows are among most critical factors that must be considered in planning migration of signal processing functionality in cloud.