MediaLive without timecode: what Video Aligned Locking changes in redundancy

A MediaLive STANDARD channel runs two pipelines in different Availability Zones. The upstream system sends the same signal to both inputs, MediaLive processes in parallel, and each output group delivers two copies — one per pipeline — to the downstream (MediaPackage, your own origin, a CDN). Redundancy lives in the downstream being able to pick either copy at any moment.

What breaks: two independent encoders do not start on the same frame. Each receives the signal with its own jitter, starts encoding at its own instant, and cuts segments at its own points. Without synchronization, segment 1042 on pipeline 0 and segment 1042 on pipeline 1 contain different content — shifted by a few dozen frames. When the origin switches pipelines, the player sees a jump forward or a repeat. In sports, that is the goal the viewer watched twice.

The historical answer: embedded timecode (SMPTE 12M, VITC, ancillary data). With timecode, both encoders know "this frame is 14:32:07:12" and cut at the same point. That is the SOURCE_TIMECODE method, MediaLive's default to this day. It works well in traditional broadcast, where the whole chain carries timecode from the camera onward.

Where the historical answer stops: most digital flows I have seen over SRT, RTMP push or IP contribution simply carry no timecode — or carry one that resets, jumps, or comes from two encoders with different clocks. In those cases MediaLive falls back to approximate synchronization, which in practice means "do not trust the failover". The alternative was specialized hardware in front of the encoder, or external orchestration. The cost of keeping that alive for years, not of buying it: one more failure point and one more on-call rotation.

Pipeline locking lives in encoderSettings.globalConfiguration and has two layers the documentation keeps carefully apart.

Mode (outputLockingMode): DISABLED, PIPELINE_LOCKING (pipelines lock to each other) or EPOCH_LOCKING (both lock to the Unix epoch — or to a CustomEpoch from 2000-01-01T00:00:00 onward, CMAF Ingest and MediaPackage V2 only). The default on a standard channel is PIPELINE_LOCKING, and it is best-effort: when it cannot lock, MediaLive keeps processing and does not treat that as a fault. This matters more than it looks — nothing stops, nothing alarms, the failover just stops being frame-accurate.

Method (outputLockingSettings.pipelineLockingSettings.pipelineLockingMethod): only exists inside PIPELINE_LOCKING. SOURCE_TIMECODE uses embedded timecode; VIDEO_ALIGNMENT computes a visual signature per frame in each encoder and aligns the frames whose content matches. With VIDEO_ALIGNMENT, any existing timecode is ignored for locking decisions — it is not a fallback, it is a replacement.

The pool: participating pipelines form a locking pool with one reference pipeline. The reference's InputVideoAligned metric is always 1; the others only report 1 once aligned with it. A standard channel has both pipelines in the pool. A SINGLE_PIPELINE channel joins the pool through linked channels: a primary channel owns the group, a follower points at the primary's ARN — same account, one follower per primary, and the primary does not need to be running for the follower to work. That is what lets two single-pipeline channels in different regions behave like a two-AZ standard channel.

A timeline detail: the VIDEO_ALIGNMENT value already showed up in the SDK on December 26, 2025; the What's New post is from September 2026. If your IaC already exposes the field, it is not an accident.

Use VIDEO_ALIGNMENT when: the source is SRT, RTMP push, RTP or an Elemental Link without reliable timecode; both pipelines receive exactly the same content; and what you want is failover between copies or frame-accurate input switching. Use SOURCE_TIMECODE when the chain already carries clean timecode from the camera onward — it remains the method with the longest production track record and the only one covering Microsoft Smooth. Use EPOCH_LOCKING when you need unrelated channels to produce segments with the same absolute time boundaries; it requires embedded timecode within 2 minutes of epoch and does not combine with VIDEO_ALIGNMENT.

Now the rules nobody reads and that cost a night shift:

Incompatible inputs raise no validation error. MP4_FILE, TS_FILE, URL_PULL with HLS and RTMP_PULL make video alignment run in open loop — processing, but not locking. The channel saves, starts, and reports InputVideoAligned = 0. This is deliberate, to allow input switching with mixed sources; it is also the most common trap.

An HLS input kills locking for the whole channel. If the channel contains an HLS input, MediaLive stops trying to lock and does not resume even after switching to another input. An "emergency" HLS slate in the input list voids the redundancy you designed.

Frame rate needs a simple conversion. Input and output must be whole-number multiples of each other: 29.97 → 59.94 works; 59.94 → 60 does not; 45 → 60 does not. MediaLive decides at input switch and does not re-evaluate if the frame rate changes mid-source. ComplexFRCPresent = 1 is the tell. And Framerate control must be Specified, never Initialize_from_source.

Looping content confuses the signature. A 10-second slate on repeat has identical frames at different positions; the comparator may align on the wrong frame or oscillate. The documentation lists this as a cause of InputVideoAligned flipping between 0 and 1.

Locking is best-effort and silent, so observability is not optional — it is the only way to know whether the redundancy you paid for exists right now.

Three metrics, dimensions ChannelId and Pipeline, statistic Minimum:

• PipelinesLocked: 1 when every eligible pair is synchronized; 0 when at least one is not. Applies to standard, epoch and linked channels, and reports the same state under VIDEO_ALIGNMENT. No datapoints means the channel is stopped.
• InputVideoAligned: 1 when the pipeline is aligned with the pool's reference. The reference always reports 1. No datapoints means the method is not VIDEO_ALIGNMENT or the pipeline has not processed a frame yet.
• ComplexFRCPresent: 1 means complex frame-rate conversion and no locking attempt at all.

My minimum alarm set: PipelinesLocked with Minimum < 1 for 3 periods of 1 minute on a channel that should be locked, and InputVideoAligned transitioning more than N times in 5 minutes — oscillation is a symptom of unstable network between the two contribution paths or of looping content, and both need a human. Without those alarms, the first news that the lock dropped arrives from the viewer who saw the replay twice.

Cost: MediaLive bills per hour of input, output and add-on, rounded up to the minute above a 10-minute minimum. A 1080p AVC 5 Mbps 30 fps output costs US$0.702/h on-demand in us-east-1; a 12-month reservation brings it to roughly US$0.1726/h. A standard channel costs less than two identical single-pipeline channels in the same region — so the two-linked-single-pipeline design only pays off when you need two regions, not two AZs. Locking itself has no line on the invoice; what it costs is the second contribution path into the other region.