# Output locking Revision to output locking section The section on implementing output locking and epoch locking has been completely revised. You can implement output locking to produce video outputs that are *frame accurate *with each other. Implement output locking to enhance output redundancy, or to implement distributed encoding. When outputs are locked together, they are frame accurate with each other. Frame accuracy means that two frames with the same timecode are identical in the following ways: + The same content—the same picture on the video frame. + The same segment number, manifest data, and so on. + The same presentation timestamp (PTS). There are two ways to implement: + [Standard output locking](opl-standard-how-it-works.md). + [Epoch locking](opl-epoch-how-it-works.md). **Note** The information in this section assumes that you are familiar with the general steps for creating an event. **Topics** + [ # About output locking and frame accuracy ](opl-frame-accuracy.md) + [ # Output locking use cases ](output-locking-general.md) + [ # How output locking works ](opl-standard-how-it-works.md) + [ # How epoch locking works ](opl-epoch-how-it-works.md) + [ # Output locking pools ](opl-pools.md) + [ # Output locking pairs ](opl-redundant-pairs.md) + [ # Requirements for inputs and outputs ](output-locking-requirements.md) + [ # Step 1: Design the workflow ](opl-step-get-ready.md) + [ # Step 2: Set up inputs in the events ](output-locking-setup-inputs.md) + [ # Step 3: Set up the global controls ](output-locking-setup-global.md) + [ # Step 4: Set up the output groups and outputs ](opl-setup-output-groups.md) + [ # Step 5: Set up the video encodes ](output-locking-event-setup-stream-video-fields.md) # About output locking and frame accuracy Output locking and frame accuracy You can implement output locking to produce video outputs that are *frame accurate *with each other. The frames from several outputs are *locked *together. Frame accuracy means that two frames with the same timecode are identical in the following ways: + The same content—the same picture on the video frame. + The same segment number, manifest data, and so on. + The same presentation timestamp (PTS). # Output locking use cases Use cases 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 Output redundancy 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 Distributed encoding 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 Distributed encoding with output redundancy 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) # How output locking works This section shows how Elemental Live locks outputs when an event first starts, and how resync works when an event is running. Output locking has these key requirements: + All inputs must have a timecode in the source. You can't set up output locking in events that use the system clock. + The events must be able to communicate with each other over multicast or unicast. **How the initial lock occurs** When you start or restart all of the events, one event is designated as the leader. Subsequent events are followers. At the first segment boundary, each follower uses its own timecode and the leader's timecode to align the frame that it emits with the frame that the leader is emitting. The events are now all locked together. **How resynchronization works** Elemental Live continually checks the timecode for the same segment in all the locked events. If the segment in one event has a different timecode, then it is considered to be out sync. Elemental Live resynchronizes the output of an event by inserting a short segment and a presentation timestamp (PTS) discontinuity tag. Keep this detect-and-correct behavior in mind. Output locking doesn't guarantee that output always staty in sync. Rather, the guarantee is that when a drift occurs, Elemental Live resynchronizes. **Inability to detect and correct** As the event runs, there might be times when the event can't detect and correct. For example, if the current source doesn't include a timecode because it is slate content. Even in this case, Elemental Live continues to attempt to synchronize. For example, if the content changes so that a timecode is present again in the source, then Elemental Live will resync again. # How epoch locking works You can set up to use the epoch locking variation of output locking. Or you can set up to use [standard output locking](opl-standard-how-it-works.md). Epoch locking requires that all of the inputs have a timecode that is in the source. The timecode must show the epoch time in UTC. **Note** We recommend against using epoch locking, for the following reasons: Epoch locking requires that the sources have an epoch timecode. It might be difficult to arrange for this timecode to be inserted in the source. Epoch locking doesn't work well with ad insertion workflows. **How the initial lock occurs** + When each event starts, the event uses its own source timecode to determine the sequence number and timecode to assign to the first segment and to every following segment: + The first sequence number is the number that would be assigned if the event had been running since the start of epoch time. For example, if the event output has segment lengths of 2.02 seconds, the first sequence number is the current epoch time divided by 2.02. + The timecode for that sequence number is the current epoch time. + The event can now predict the sequence numbers and timecodes for each segment: + The expected sequence numbers are predictable. They always increment by 1. + The expected timecode is predictable. It should increment by 2.02 seconds in each segment. + The event now locks to that expectation. As the event continues encoding, it continually compares the timecode of each sequence to the expected timecode. + Every event locks in this way. They all lock to the epoch timecode, which means that in effect they are locked to each other. **How resynchronization works** Each event checks the timecode for the current segment to the expected timecode. If it is different, a drift has occurred. The event will resynchronize by inserting a short segment and a presentation timestamp (PTS) discontinuity tag. Keep this detect-and-correct behavior in mind. Output locking doesn't guarantee that output never becomes out of sync. Rather, the guarantee is that when a drift occurs, Elemental Live resynchronizes. **Inability to detect and correct** As the event runs, there might be times when the event can't detect and correct. For example, if the current source doesn't include a timecode, perhaps because it is slate content. Even in this case, Elemental Live continues to attempt to synchronize. For example, if the content changes so that a timecode is present again in the source, then Elemental Live will resync again. # Output locking pools The events that are locked together are in a *pool of locked events*. The outputs in these events are part of a *pool of locked outputs*. The encodes in the locked outputs are part of a *pool of locked encodes*. If you have a workflow with several types of output groups, it's important to keep track of the pools. If you don't keep track of the pools, you might break the rules for output locking. The following diagram illustrates the event setup to produce an HLS ABR stack (with four renditions), and a Microsoft Smooth Streaming ABR stack (with three renditions), all from the same source. The following pools exist: + Events A, B, and C are one pool of locked events for the HLS ABR stack. + Events D and E are another pool for the Microsoft Smooth Streaming ABR stack. + Outputs A1, B1, C1, and C2 are one pool of locked outputs. + Outputs D1, E1, and E2 are another pool of locked outputs. + The four streams in the HLS events are a pool of locked encodes. + The three streams in the Microsoft Smooth Streaming events are another pool of locked encodes. ![\[Video streaming events with HLS and MSS output groups producing various resolution streams.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-pools.png) # Output locking pairs In an output redundancy implementation, there are also redundant pairs of events, outputs, and encodes. Encode pairs are typically identical. If you have a workflow with several types of output groups, it's important to keep track of the pairs. If you don't keep track of the pairs, you might break the rules for output locking. The following diagram illustrates the event setup to produce a redundant HLS output and a Microsoft Smooth Streaming output, all from the same source. The following pairs exist: + Events A and B are a redundant pair of events. Events C and D are another redundant pair. + Outputs A1 and B1 are a redundant pair of outputs. Outputs C1 and C1 are another redundant pair. + Videos 1 and 2 are a redundant pair of encodes. Videos 3 and 4 are another redundant pair. ![\[Diagram showing four events with HLS and MS Smooth output groups connected to video outputs.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-pairs.png) # Requirements for inputs and outputs Requirements This section describes the requirements for source inputs and outputs, their characteristics, and which work for output locking. **Note** This section refers to *pools* and *redundant pairs*. For an explanation of pools, see [Output locking pools](opl-pools.md). For an explanation of pairs, see [Output locking pairs](opl-redundant-pairs.md). **Topics** + [ ## Supported input types ](#opl-requirements-input-types) + [ ## Input requirements ](#output-locking-input-requirements) + [ ## Supported output types ](#opl-requirements-output-types) + [ ## Output encode requirements ](#output-locking-output-requirements) + [ ## Output locking and SCTE 35 ](#opl-requirements-scte35) ## Supported input types Elemental Live supports output locking with the following types of inputs: + HLS network inputs. Output locking isn't supported with HLS file inputs. + SDI sources: SDI inputs, 4K Quadrant SDI inputs, 4K 2SI inputs, + TS sources: RTP network inputs, SMPTE 2022-6 inputs, SMPTE 2022-7 inputs, SRT inputs, UDP network inputs. + RTMP inputs. + RTSP inputs. ## Input requirements For output locking to be successful, the video sources must meet strict requirements. **Input timecode** The inputs must have a timecode in the source. If the timecode is missing from the source, the event will fail to start. Different types of sources support different types of timecode: + HLS live sources: Embedded timecode. + Inputs that are SDI sources: Embedded or LTC timecode. All the inputs in one event must have the same timecode source. The inputs can't switch from embedded to LTC. All inputs across the pool of locked events must have the same timecode. + Inputs that are transport stream sources: Embedded timecode. The timecode with standard output locking must be HH:MM:SS:FF format. The timecode with epoch locking must be epoch time in UTC. **Note** Both output locking and epoch locking require a timecode in every source. **Video is required** Output locking isn't supported in an audio-only event. **Video characteristics** The sources for all of the events must be identical. Specifically, the outputs won't be frame accurate if the following video characteristics vary across the sources: + Frame rate. The frame rates in the different sources can have different frame rates that are whole number multiples of each other. For example, 30 fps and 60 fps. + Scan type (progressive versus interlaced). Note that these are the only characteristics that must be identical in all sources. Other characteristics, including resolution and GOP structure (I-frame, B-frame, and P-frame patterns) can be different. ## Supported output types Elemental Live supports output locking with the following types of outputs: + HLS output group + MS Smooth output group + UDP/TS output group **Note** All output groups in the event must implement output locking. If an output group can't implement output locking, you can't include it in the pool of locked events. Even when an output group doesn't support output locking, you can't include it in the output locking event. For example, the event can't include a DASH output group. ## Output encode requirements For output locking to be successful, the video outputs must meet strict requirements. ### Video codec The video encodes must use H.264 or H.265. Within a pool of locked encodes, the codecs can be different, as long as they're always H.264 or H.265. In a redundant pair of encodes, the codecs must be the same. ### Frame rate There are two sets of rules for the frame rate: + Rule for the frame rate conversion from the source to the output encode. + Rule for the frame rates in all output encodes in the pool of events. **Rule 1: Conversions from the source to the output encode in the same output** Simple conversions are allowed. The conversion between the input frame and the desired output frame rate must be *simple*, which means that one of these statements must apply: + The output encode frame rate must be a whole number multiple of the source frame rate. For example, the source frame rate might be 30 FPS, and the output encode frame rate might be 60 FPS. + The source frame rate must be a whole number multiple of the output encode frame rate. For example, the source frame rate might be 60 FPS, and the output encode frame rate might be 30 FPS. With these rules, it is possible for the frame rates to be integers. For example, if the source frame rate is 29.97 FPS and the output encode frame rate is 59.94 FPS. Complex conversions aren't allowed. The following are examples of *complex* frame rates. You can't use the input if combinations like these apply to your channel: + Source FPS is 59.4, output FPS is 60. + Source FPS is 45, output FPS is 60. **Rule 2: Frame rates in the outputs in the output pool** The frame rates in the output encodes in the pool of locked outputs can all be different. However, they must be whole number multiples of each other. **Example** In the following diagram, all of the inputs are from the same source. Therefore, they have the same frame rate. Rule 1: In each event, each video encode (the oval inside the stream) must have a frame rate that is a simple conversion of the source frame rate. Rule 2: All the encodes can have a different fran rate, but they must be whole number multiples of each other. ![\[Three appliances showing HLS output groups with varying video resolution streams.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/outputs_opl-framerates.png) ## Output locking and SCTE 35 **Epoch locking and SCTE 35 ** To include SCTE 35 messages in the outputs, you can't implement epoch locking. The presence of SCTE 35 messages is not compatible with the segment length requirements for epoch locking. If the inputs contain SCTE 35 messages, make sure that you don't [pass them through to the output](pass-through-or-removal.md). **Inserting SCTE 35 messages via the REST API** You can implement standard output locking if you want to include SCTE 35 messages in the outputs. The messages can be in the source and/or added when the event is running: + The SCTE 35 messages can be messages that you [pass through from the source](pass-through-or-removal.md). + Or they can be messages that you [insert into a running event](scte-35-message-insertion.md), using the REST API. In this case, make sure to include a time buffer between the time that you enter the message and the time for that message. In other words, don't enter an *immediate* start time for the cue out or the cue in. A message with an immediate start can compromise the frame accuracy of the pool of locked outputs. # Step 1: Design the workflow Step 1: Design workflow When you implement output locking, there are special considerations in your design of the inputs, output groups, outputs, and output encodes (video streams) in the events. **Topics** + [ # Design the inputs ](opl-step-design-inputs.md) + [ # Design the outputs ](opl-step-get-ready-outputs.md) + [ # Example of a workflow ](opl-example.md) # Design the inputs When you design a workflow that implements Elemental Live output locking, you must obtain information about the sources. **Topics** + [ ## Determine the resources ](#opl-step-get-ready-resources) + [ ## Decide how to produce the sources ](#opl-step-get-ready-produce-source) + [ ## Obtain information about the sources ](#opl-step-get-ready-source-info) ## Determine the resources Identify the number of sources, output encodes, and events that you need. **For output redundancy workflows** For output redundancy, you need two sources, two output encodes, and two events. Each event uses one input and produces one output encode. **For distributed encoding workflows** For distributed encoding, calculate the numbers as follows: + The number of output encodes: You need one output encode for each video rendition in the ABR stack. + The number of events: Decide how many output encodes each Elemental Live appliance can handle, based on the density capabilities of the appliance. An appliance might be able to produce only one output encode if that encode is a 4K rendition. However, an appliance might be able to produce several lower-resolution output encodes (renditions). When you know the number of appliances, you know the number of events—one event per appliance. + The number of sources: You need one source for each event. ## Decide how to produce the sources Decide how you will produce the sources: + You might produce the streams for each event using a different contribution encoder for each event. + Instead, you might produce the sources once, then use a video router upstream of Elemental Live to product identical streams. Make sure that the [sources are identical](output-locking-requirements.md#output-locking-input-requirements). ## Obtain information about the sources Obtain the following information: + The characteristics of the video. + The type of timecode that each source includes. # Design the outputs When you design a workflow that implements Elemental Live output locking, you must decide which output group types you will produce, design the outputs in the output groups, and decide on the video encoding characteristics of the output type or types. This section covers considerations that affect your design. **Topics** + [ ## Number of outputs in an output group ](#opl-design-outputs-opg) + [ ## Number of encodes: video encode sharing ](#opl-design-outputs-number-encodes) + [ ## Encodes across the locked events ](#opl-design-outputs-number-encodes-event) + [ ## Features in an output ](#opl-design-output-features) + [ ## Motion graphic overlay ](#opl-design-output-features-motion-gx) ## Number of outputs in an output group For distributed encoding, there will be many cases where one appliance can produce only one output encode. To set up these encodes, create an output group (for example, create an HLS output group), and create one output in that output group. There might also be cases where you have determined that one appliance can produce several one lower-resolution output encodes. To set up these encodes, create an output group (for example, create an HLS output group), and create two outputs. Each output contains one of the encodes. ## Number of encodes: video encode sharing If you have multiple output group types in one event, several different output groups might be able to use the same video encode. For example, if you're producing an HLS package and a UDP/TS package, and both packages are encoded with H.264, you might be able to create one video encode that the two output groups share. This sharing reduces the compute demands on the appliance. To share the encodes, create an output in one output group and an output in the other output group. Create one video stream. Set up both outputs to use the same encode. ![\[Diagram showing two output groups sharing a high resolution video stream.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-shared-encode.png) ## Encodes across the locked events You must set up the video encodes in the locked events as follows: + For an output redundancy implementation, the pair of encodes in the same type of output group must be identical. For example, the encode in the output must be identical to the encode in the redundant output. + For a distributed encoding implementation, each pair of encodes must be identical, so that the main ABR stack and the redundant ABR stack are identical. For example, you might have one ABR stack consisting of encodes A1, B1, C1, D1, and another ABR stack consisting of encodes A2, B2, C2, D2. Encode A1 must be identical to encode A2, B1 identical to B2, and so on. For an explanation of *pairs of encodes*, see [Output locking pairs](opl-redundant-pairs.md). ## Features in an output Some features, such as static graphic overlay, can apply within an individual portion of an event. Make sure that you apply the features in the same way in every locked event. For example, if you implement the static overlay in all outputs in one event, then make sure that you set it up on all outputs in the other event. For more information, including diagrams, see [Insertion options and the effect on outputs](insertion-options-and-the-effect-on-outputs.md). ## Motion graphic overlay We strongly recommend against combining motion graphic overlays and output locking. Frame accuracy can't apply to motion graphic overlays that are applied to the video content. # Example of a workflow Example This section provides an example of the design of an output lock workflow that implements distributed encoding. **Note** This example refers to *pools*. For an explanation of pools, see [Output locking pools](opl-pools.md). The following example workflow has two output packages: HLS and MS Smooth. Notice how the ABR stacks are divided into several events within each package. This division is driven by the processing demands on the encodes. Notice that when two outputs are on the same appliance, they can share the same output group. Pay attention to the pools that are implied by this design: + There are two event pools for five events. One pool contains events A, B, and C. One event contains events D and E. + There are two output group pools. One pool contains the three HLS output groups, shown in yellow. The other contains the two MS Smooth output groups, shown in striped yellow. + There are two output pools. One pool contains four HLS outputs, shown in blue. The other contains three MS Smooth outputs, shown in striped blue. + There are two encode pools. One pool contains four HLS encodes, shown in red. The other contains three MS Smooth outputs, shown in striped red. ![\[Diagram showing 5 appliances with different HLS and MSS events, outputs, and video stream resolutions.\]](http://docs.aws.amazon.com/elemental-live/latest/ug/images/opl-design-hls-mss-4appliances.png) # Step 2: Set up inputs in the events Step 2: Set up inputs After you have identified the sources and ensured that they [support output locking](output-locking-requirements.md#output-locking-output-requirements), you can set them up in the event as inputs. **Note** This section refers to *pools*. For an explanation of pools, see [Output locking pools](opl-pools.md). **To set up the inputs** 1. Create all of the inputs that you have identified. Create the same inputs in each event, and enter them in the same order in each event. 1. Complete all fields that apply to the input type. In the **Input – Video Selector** section of the event: Set the following fields as specified in the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/output-locking-setup-inputs.html) # Step 3: Set up the global controls Step 3: Set up global controls This section shows how to set up global controls to enable output locking and epoch locking in an Elemental Live event. You must set up the controls that apply to the entire event—the timecode and the communications mechanism. **Note** This section refers to *pools* and *redundant pairs*. For an explanation of pools, see [Output locking pools](opl-pools.md). For an explanation of pairs, see [Output locking pairs](opl-redundant-pairs.md). **Topics** + [ ## Set up the timecode ](#output-locking-event-global-tcode) + [ ## Enable output locking ](#output-locking-event-global-comms) ## Set up the timecode In the **Timecode Configuration** section that appears after the **Inputs** section of the event: Set the fields as specified in the following table. This setup configures the timecode for use in all outputs. | Field name | Instruction | Notes | | --- | --- | --- | | Source | Choose any value, but choose the same value in all events in the pool. | This timecode is the timecode for the outputs. It is inserted in all the outputs in the pool of locked events. The downstream system can use this timecode to determine that a frame from one event corresponds to the frame from another event. | | Sync Threshold | Deselect this field. | | | Require Initial Timecode | Select the check box to ensure that the first source does in fact have a timecode. | If you select this check box, the event will fail to start if the first input has no embedded timecode. The event will also fail to start if you stop and restart the event, and the input that is active when you restart has no embedded timecode. | ## Enable output locking You must enable output locking. Make sure that you perform the same setup in all the events in the pool. **To set up to use multicast for standard output locking** To implement standard output locking, the events you are locking together must be able to communicate with each other over multicast or unicast. You can use multicast if you are locking together two events, or if you are locking together several events. 1. In the **Global Processors** section of the event set the **Output Locking** field to **On**. 1. Set the fields as shown in the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/output-locking-setup-global.html) **To set up to use unicast for standard output locking** To implement standard output locking, the events that you're locking together must be able to communicate with each other over multicast or unicast. Unicast is a point-to-point protocol, so you can use unicast only if you're locking together two events. + In the **Global Processors** section of the event set the **Output Locking** field to **On**. Set the fields as shown in the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/output-locking-setup-global.html) **To set up for epoch locking** 1. In the **Global Processors** section, set the **Output Locking** field to **On**. 1. Select **Epoch Locking**. The values of other fields are ignored. # Step 4: Set up the output groups and outputs Step 4: Set up output groups This section shows how to set up output groups and outputs in an Elemental Live event that implements output locking. **Note** This section refers to *pools*. For an explanation of pools, see [Output locking pools](opl-pools.md). After you set up all of the events that you have identified, use the following topics to set up the outputs. **Topics** + [ # Setting up an HLS output group ](opl-setup-hls.md) + [ # Setting up an MS Smooth output group ](output-locking-event-setup-mss-output-fields.md) + [ # Setting up a UDP/TS output group ](opl-setup-udp.md) # Setting up an HLS output group HLS This section shows how to set up an HLS output group to implement Elemental Live output locking. 1. Complete the fields in the **Apple HLS Settings** section of the output group. Set the fields that are listed in the following table as specified in the table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/opl-setup-hls.html) 1. Set other fields in the **Apple HLS Settings** section to suit your workflow. 1. Set the fields in the outputs to suit your workflow. # Setting up an MS Smooth output group MS Smooth This section shows how to set up an MS Smooth output group to implement Elemental Live output locking. 1. Go to the **MS Smooth Settings** section of the output group. Set the fields that are listed in the following table as specified in the table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/output-locking-event-setup-mss-output-fields.html) 1. Set other fields in the **MS Smooth Settings** section to suit your workflow. 1. Set the fields in the outputs to suit your workflow. # Setting up a UDP/TS output group UDP/TS This section shows how to set up a UDP/TS output group to implement Elemental Live output locking. 1. Go to the **UDP/TS Output Group **section of the event. Set the fields as follows. + **Custom Group Name**: Enter the same name across all events in the pool. + Set other fields to suit your workflow. 1. Go to each output. In the **Transport Stream Settings** section, set the fields as specified in the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/opl-setup-udp.html) 1. Set other fields in the outputs to suit your workflow. # Step 5: Set up the video encodes Step 5: Set up encodes This section shows how to set up video encode parameters in an event that implements Elemental Live output locking. **Note** This section refers to *pools*. For an explanation of pools, see [Output locking pools](opl-pools.md). After you have created the output groups and outputs, follow these guidelines to create the video encodes. Set up the output encodes (video streams) in the usual way: 1. In each output group, create as many outputs as you [planned for that output group](opl-step-get-ready-outputs.md). When you add an output, Elemental Live creates a new stream in the **Streams** section. 1. Set the following fields in the **Video** tab as specified. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elemental-live/latest/ug/output-locking-event-setup-stream-video-fields.html) 1. You can set other fields in the **Video** section, the fields in the **Audio** section, and the fields in the **Captions** tab to suit your workflow.