# Output locking use cases
<a name="output-locking-general"></a>

Implement output locking for either or both of these reasons:
+ To enhance output redundancy.
+ To implement distributed encoding.

**Topics**
+ [

# Use case 1: Enhancing output redundancy
](output-locking-output-redundancy.md)
+ [

# Use case 2: Distributed encoding
](output-locking-distributed-encoding.md)
+ [

# Use case 3: Distributed encoding with output redundancy
](output-locking-distrib-plus-redundancy.md)

# Use case 1: Enhancing output redundancy
<a name="output-locking-output-redundancy"></a>

You can implement output locking to enhance output redundancy. You can set up output redundancy to work on the same or different Elemental Live appliances:
+ If you set up both events on the same appliance, you achieve resiliency if there is a problem with one event. However, if the entire appliance fails, both outputs stop, and there is no fallback.
+ If you set up each event on a different appliance, you achieve resiliency if there is a problem with one event or if the entire appliance fails. If the entire appliance fails, the other event (on the other appliance) still provides output to the downstream system.

**Adding output locking**

You can add output locking to output redundancy. When you do this, the failover from one output to the other is seamless:
+ Without output locking, the two outputs are probably not frame accurate with each other. At a specific timecode, the content in the frame in one output is not identical to the content in the frame in the other output. When the downstream system switches between outputs, there might be a noticeable repetition of a few frames. Or there might be a noticeable discontinuity.
+ With output locking, the two outputs are frame accurate with each other. At a specific timecode, the content in both outputs is identical. The downstream system can use the timecode to synchronize the content when it switches from one output to the other. In this way, the switch is seamless. There are no duplicate frames and no missing frames.

Output locking ensures a seamless failover because the outputs are frame accurate with each other. The exact same frame has the exact same timecode. The outputs are locked together. 

When you add output locking to an output redundancy setup, you must set up each event on a different appliance. 

The following diagram illustrates a typical setup of two events that are a redundant pair.

![\[Two events with HLS output groups connected to video components, illustrating redundancy.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-redundancy.png)


# Use case 2: Distributed encoding
<a name="output-locking-distributed-encoding"></a>

You can set up output locking to implement distributed encoding. A typical use case for distributed encoding is to build an ABR stack that consists of different renditions (resolutions) of the same video content.

You can set up two or more events, each on a separate appliance. All the events handle the same sources, but each event produces different parts of the ABR stack. The source content for all the events is always identical, so the video picture in all the outputs is identical. 

You set up all the events so that their outputs are locked together. In this way, all the outputs are frame accurate with each other—the exact same frame has the exact same timecode. 

The downstream system receives all of the outputs. The downstream system has been set up to put the ABR stack together. The downstream system can use the timecodes to synchronize the frames. In this way, when the player switches from one rendition to another, the switch occurs with no missing frames and with no duplicate frames.

The following diagram illustrates a setup of several events that together produce the outputs for an ABR stack.

![\[Diagram showing three HLS output groups connected to an ABR stack with high, medium, and low resolution video outputs.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-abr.png)


# Use case 3: Distributed encoding with output redundancy
<a name="output-locking-distrib-plus-redundancy"></a>

You might combine distributed encoding with output redundancy, and also include output locking. For example, you might create three events, each producing a separate output. To add redundancy, duplicate each of those events (outputs) to create *event pairs*. Then to include output locking, make sure that each event in the pair is on a different appliance. 

In the following illustration, event A and event D are a pair. The high-resolution video that event A produces is identical to the high-resolution video that event D produces. Similarly, event B and event E are a pair, and event C and event F are a pair.

In this scenario, the downstream system must determine that there are duplicates of each rendition. The downstream system decides which outputs to choose initially, to construct the ABR stack. Then later, if there is a problem with one of the initial renditions of the stack, the downstream system must be able switch to the other rendition. 

The following diagram illustrates a setup that combines distributed encoding and redundancy. There are three pairs of redundant events. In each pair, the two events produce the same rendition.

![\[Downstream system choosing HLS outputs to construct the ABR stack.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-abr-redundancy-combo.png)