# MediaLive sem timecode: o que o Video Aligned Locking muda na redundância

O MediaLive passou a sincronizar pipelines por assinatura visual dos frames, sem depender de timecode embutido — exatamente a peça que faltava para fontes SRT/RTMP de campo e para canais single-pipeline ligados entre regiões. Disseco o padrão: o problema que ele resolve, a anatomia dos modos e métodos de locking, as regras de frame rate e de input que derrubam a sincronização em silêncio, e as três métricas que precisam de alarme antes de ir para produção.

- URL: https://fernando.moretes.com/blog/medialive-sem-timecode-o-que-o-video-aligned-locking-muda-na-redundanc-aws-elementa

- Markdown: https://fernando.moretes.com/blog/medialive-sem-timecode-o-que-o-video-aligned-locking-muda-na-redundanc-aws-elementa/article.md?lang=pt

- Published: 2026-09-13T10:14:40.690Z

- Category: IA & Agentes

- Tags: MediaLive, live-streaming, pipeline-locking, multi-region, resilience, observability, media-services, SRT

- Reading time: 7 min

- Source: [AWS Elemental MediaLive enables frame-accurate pipeline locking for streams without timecode](https://aws.amazon.com/about-aws/whats-new/2026/09/medialive-pipeline-locking/)

---

Todo desenho de streaming ao vivo com redundância promete a mesma coisa: se o pipeline A cair, o player continua no B sem que o espectador perceba. O que quase ninguém escreve no ADR é a condição para essa promessa valer — os dois pipelines precisam estar no mesmo frame, no mesmo instante, com os mesmos limites de segmento. Durante anos isso exigiu timecode embutido na fonte, e timecode é coisa de caminhão de externa, não de encoder SRT num estádio ou de um push RTMP saindo de um estúdio pequeno. O Video Aligned Locking do AWS Elemental MediaLive, anunciado em 12 de setembro de 2026, tira essa dependência: o encoder compara assinaturas visuais dos frames entre os pipelines e alinha por conteúdo. Vale entender o que ele resolve, o que ele não resolve e onde ele falha sem avisar.

## O problema: redundância que só funciona no slide

Um canal `STANDARD` do MediaLive roda dois pipelines em Availability Zones diferentes. O sistema upstream manda o mesmo sinal para as duas entradas, o MediaLive processa em paralelo e cada output group entrega duas cópias — uma por pipeline — para o downstream (MediaPackage, um origin próprio, um CDN). A redundância está no downstream escolher qualquer uma das duas a qualquer momento.

**O que quebra:** dois encoders independentes não começam no mesmo frame. Cada um recebe o sinal com jitter próprio, começa a codificar num instante próprio e corta segmentos em pontos próprios. Sem sincronização, o segmento 1042 do pipeline 0 e o segmento 1042 do pipeline 1 têm conteúdos diferentes — deslocados por algumas dezenas de frames. Quando o origin troca de pipeline, o player vê um salto para frente ou uma repetição. Em esporte, isso é o gol que o espectador viu duas vezes.

**A resposta histórica:** timecode embutido (SMPTE 12M, VITC, ancillary data). Com timecode, os dois encoders sabem que "este frame é 14:32:07:12" e cortam no mesmo ponto. É o método `SOURCE_TIMECODE`, padrão do MediaLive até hoje. Funciona bem em broadcast tradicional, onde a cadeia inteira carrega timecode desde a câmera.

**Onde a resposta histórica não chega:** a maioria dos fluxos digitais que vi passar por SRT, RTMP push ou contribuição por IP simplesmente não carrega timecode — ou carrega um que reinicia, salta ou vem de dois encoders com relógio diferente. Nesses casos, o MediaLive cai para sincronização aproximada, o que na prática significa "não confie no failover". A alternativa era hardware especializado antes do encoder, ou orquestração externa. Custo de manter isso por anos, não de comprar: mais um ponto de falha e mais um plantão.

## Anatomia: modos, métodos e o pool de locking

O pipeline locking vive em `encoderSettings.globalConfiguration` e tem duas camadas que a documentação separa com cuidado.

**Modo (`outputLockingMode`):** `DISABLED`, `PIPELINE_LOCKING` (os pipelines travam um no outro) ou `EPOCH_LOCKING` (os dois travam no Unix epoch — ou num `CustomEpoch` a partir de `2000-01-01T00:00:00`, só para CMAF Ingest e MediaPackage V2). O padrão num canal standard é `PIPELINE_LOCKING`, e ele é best-effort: quando não consegue travar, o MediaLive continua processando e não trata isso como falha. Esse detalhe importa mais do que parece — nada para, nada alarma, o failover só deixa de ser frame-accurate.

**Método (`outputLockingSettings.pipelineLockingSettings.pipelineLockingMethod`):** só existe dentro de `PIPELINE_LOCKING`. `SOURCE_TIMECODE` usa o timecode embutido; `VIDEO_ALIGNMENT` calcula uma assinatura visual por frame em cada encoder e alinha os frames cujo conteúdo bate. Com `VIDEO_ALIGNMENT`, o timecode existente é ignorado para qualquer decisão de locking — não é fallback, é substituição.

**O pool:** os pipelines participantes formam um pool de locking com um pipeline de referência. A métrica `InputVideoAligned` da referência é sempre 1; os demais só marcam 1 quando alinharam com ela. Um canal standard tem os dois pipelines no pool. Um canal `SINGLE_PIPELINE` entra no pool via **linked channels**: um canal primary é o dono do grupo, um follower aponta para o ARN do primary — mesma conta, um follower por primary, e o primary não precisa estar rodando para o follower funcionar. É isso que permite dois single-pipeline em regiões diferentes se comportarem como um standard de duas AZs.

**Um detalhe de linha do tempo:** o campo `VIDEO_ALIGNMENT` já aparecia no SDK em 26 de dezembro de 2025; o What's New é de setembro de 2026. Se sua IaC já expõe o campo, não é acidente.

## Video Aligned Locking: dois pipelines, um follower cross-region, um pool

O mesmo sinal sem timecode chega a três encoders; o pool compara assinaturas visuais, alinha o corte de segmento e expõe o estado em duas métricas. O downstream troca de cópia sem salto.

### 🟧 AWS us-east-1 — canal STANDARD

- Pipeline 0 · AZ-a referência do pool (compute)
- Pipeline 1 · AZ-b segue a referência (compute)

### 🟧 AWS us-west-2 — SINGLE_PIPELINE linked

- Follower channel aponta para o ARN do primary (compute)

### 🔧 Pool de locking — VIDEO_ALIGNMENT

- Assinatura visual por frame, por encoder (ai)
- Comparação de frames alinha corte de segmento (security)
- CloudWatch PipelinesLocked · InputVideoAligned (network)

### 📤 Distribuição

- MediaPackage / CMAF Ingest segmentos idênticos por pipeline (storage)
- CDN → player failover sem salto (edge)

### Fluxos

- src -> p0: entrada A
- src -> p1: entrada B (mesmo conteúdo)
- src -> fol: contribuição cross-region
- p0 -> sig: frames
- p1 -> sig: frames
- fol -> sig: frames (mesmo pool)
- sig -> cmp: frame N ↔ frame N
- cmp -> p1: ajusta offset
- cmp -> fol: ajusta offset
- cmp -> cw: 1 travado / 0 open loop
- p0 -> mp: cópia 0
- p1 -> mp: cópia 1
- fol -> mp: cópia regional
- mp -> cdn: troca de cópia no mesmo frame

## Quando usar — e as regras que derrubam o lock em silêncio

Use `VIDEO_ALIGNMENT` quando: a fonte é SRT, RTMP push, RTP ou um Elemental Link sem timecode confiável; os dois pipelines recebem exatamente o mesmo conteúdo; e o que você quer é failover entre cópias ou troca de input frame-accurate. Use `SOURCE_TIMECODE` quando a cadeia já carrega timecode limpo desde a câmera — ele continua sendo o método com mais histórico em produção e o único que cobre Microsoft Smooth. Use `EPOCH_LOCKING` quando precisa que canais **sem relação entre si** produzam segmentos com os mesmos limites de tempo absoluto; ele exige timecode embutido dentro de 2 minutos do epoch e não combina com `VIDEO_ALIGNMENT`.

Agora as regras que ninguém lê e que custam uma madrugada:

**Inputs incompatíveis não geram erro de validação.** `MP4_FILE`, `TS_FILE`, `URL_PULL` com HLS e `RTMP_PULL` fazem o video alignment rodar em open loop — processando, mas sem travar. O canal salva, sobe e reporta `InputVideoAligned = 0`. Isso é deliberado, para permitir input switching com fontes mistas; também é a armadilha mais comum.

**Input HLS mata o locking do canal inteiro.** Se o canal contém um input HLS, o MediaLive para de tentar travar e **não retoma** nem depois de trocar para outro input. Um slate HLS "de emergência" na lista de inputs anula a redundância que você desenhou.

**Frame rate precisa de conversão simples.** Entrada e saída devem ser múltiplos inteiros uma da outra: 29.97 → 59.94 funciona; 59.94 → 60 não; 45 → 60 não. O MediaLive decide na troca de input e não reavalia se o frame rate mudar no meio. `ComplexFRCPresent = 1` é o sinal. E `Framerate control` precisa ser `Specified`, nunca `Initialize_from_source`.

**Conteúdo que faz loop confunde a assinatura.** Um slate de 10 segundos repetido tem frames idênticos em posições diferentes; o comparador pode alinhar no frame errado ou oscilar. A documentação lista isso como causa de `InputVideoAligned` alternando entre 0 e 1.

## Três formas de travar pipelines no MediaLive
| Critério | Configuração | Exige timecode? | Outputs cobertos | Quando escolher |
| --- | --- | --- | --- | --- |
| PIPELINE_LOCKING + SOURCE_TIMECODE (padrão) | `outputLockingMode: PIPELINE_LOCKING`, método padrão | Recomendado; sem ele cai para sincronização aproximada | HLS live, MediaPackage, CMAF Ingest, UDP/SRT segmentado, Microsoft Smooth | Cadeia broadcast com timecode limpo desde a origem |
| PIPELINE_LOCKING + VIDEO_ALIGNMENT | `pipelineLockingSettings.pipelineLockingMethod: VIDEO_ALIGNMENT` | Não; timecode existente é ignorado | HLS live, MediaPackage, CMAF Ingest, UDP/SRT segmentado (sem Smooth) | SRT/RTMP push sem timecode; linked channels cross-region; inputs sem file/HLS/RTMP_PULL |
| EPOCH_LOCKING | `outputLockingMode: EPOCH_LOCKING`, opcional `CustomEpoch` | Sim, dentro de 2 minutos do epoch | Os mesmos, mas desliga SCTE-35 passthrough e manifest decoration em HLS/MediaPackage | Canais independentes que precisam de limites de segmento em tempo absoluto |

## Operar isso: métricas, alarmes e o custo real

O locking é best-effort e silencioso, então a observabilidade não é opcional — é a única forma de saber se a redundância que você pagou existe agora.

**Três métricas, dimensões `ChannelId` e `Pipeline`, estatística `Minimum`:**

- `PipelinesLocked`: 1 quando todos os pares elegíveis estão sincronizados; 0 quando pelo menos um não está. Vale para standard, epoch e linked channels, e reporta o mesmo estado com `VIDEO_ALIGNMENT`. Sem datapoints significa canal parado.
- `InputVideoAligned`: 1 quando o pipeline alinhou com a referência do pool. A referência marca 1 sempre. Sem datapoints significa que o método não é `VIDEO_ALIGNMENT` ou o pipeline ainda não processou frame algum.
- `ComplexFRCPresent`: 1 significa conversão complexa de frame rate e nenhuma tentativa de locking.

Meu alarme mínimo: `PipelinesLocked` com `Minimum < 1` por 3 períodos de 1 minuto num canal que deveria estar travado, e `InputVideoAligned` transitando mais de N vezes em 5 minutos — oscilação é sintoma de rede instável entre os dois caminhos de contribuição ou de conteúdo em loop, e os dois exigem ação humana. Sem esses alarmes, a primeira notícia de que o lock caiu chega pelo espectador que viu o replay duplicado.

**Custo:** o MediaLive cobra por hora de input, output e add-on, arredondado ao minuto acima de um mínimo de 10 minutos. Um output 1080p AVC 5 Mbps 30 fps custa US$ 0,702/h on-demand em `us-east-1`; reservado por 12 meses cai para cerca de US$ 0,1726/h. Um canal standard custa menos que dois single-pipeline idênticos na mesma região — então o desenho de dois single-pipeline ligados só se justifica quando você precisa de duas **regiões**, não de duas AZs. O locking em si não tem linha própria na fatura; o que ele custa é o segundo caminho de contribuição até a outra região.

## Anti-padrões que vi em desenhos de redundância ao vivo

- **Slate HLS na lista de inputs**: um input HLS de emergência faz o MediaLive parar de travar o canal inteiro e não retomar — a redundância morre no dia em que ninguém está olhando.
- **Confiar no save do canal como validação**: `RTMP_PULL` e file inputs passam sem erro e rodam em open loop; só `InputVideoAligned` conta a verdade.
- **`Initialize_from_source` no frame rate de saída**: a documentação diz que não funciona bem com locking; `Specified` com numerador/denominador explícitos é o único caminho previsível.
- **Dois single-pipeline na mesma região para "ter controle"**: custa mais que um standard e não ganha nada em zona — linked channels são para cross-region.
- **Epoch locking com SCTE-35 em HLS/MediaPackage**: o canal desliga passthrough e manifest decoration; a inserção de anúncio some sem que o time de ads saiba por quê.
- **Caminhos de contribuição assimétricos**: mandar o sinal para a segunda região por uma rota com jitter muito diferente faz a assinatura oscilar; o lock vira intermitente, o pior estado possível.

> **Teste de aceitação antes do primeiro evento:** Suba o canal com o input real, espere `InputVideoAligned = 1` nos dois pipelines, e então force a troca de cópia no origin — no MediaPackage, alternando o endpoint de ingest ativo — enquanto grava a saída com um relógio de burn-in visível no vídeo. Se o relógio salta ou repete um frame, o lock não está fazendo o que o ADR promete. Repita com o input de backup ativo. Vinte minutos de teste valem mais que qualquer diagrama.

> **Nota de curadoria:** Eu trocaria para `VIDEO_ALIGNMENT` em qualquer canal cuja fonte seja SRT ou RTMP push de campo, e deixaria `SOURCE_TIMECODE` só onde a cadeia inteira é broadcast com timecode auditado. Antes de trocar, eu removeria todo input HLS e `RTMP_PULL` do canal e colocaria alarme em `PipelinesLocked` e `InputVideoAligned` no mesmo commit da mudança — não na semana seguinte. A lição dura por trás disso: em sistema best-effort, a ausência de erro não é prova de funcionamento; a única prova é a métrica em 1 no momento em que você força a falha. Já vi redundância desenhada, paga e apresentada em comitê que nunca esteve travada um único minuto — e ninguém soube até o evento.

## Veredito

Video Aligned Locking é a peça que faltava para tratar fontes digitais sem timecode com a mesma seriedade que o broadcast tratava as suas — e a combinação com linked channels torna viável um canal ativo-ativo em duas regiões sem hardware na frente do encoder. Adote quando: a fonte não tem timecode confiável, os dois caminhos de contribuição entregam o mesmo conteúdo com jitter comparável, os inputs são todos compatíveis e o frame rate de saída é múltiplo inteiro do de entrada. Fique no `SOURCE_TIMECODE` quando a cadeia já carrega timecode limpo ou quando precisa de Microsoft Smooth. Em qualquer dos casos, o que decide se a redundância existe não é a configuração — é o alarme em `PipelinesLocked` que você vai ou não vai criar.

**Rating:** Adote com alarmes / Adopt with alarms

## Referências

- [AWS What's New — MediaLive enables frame-accurate pipeline locking for streams without timecode (2026-09-12)](https://aws.amazon.com/about-aws/whats-new/2026/09/medialive-pipeline-locking/)
- [MediaLive User Guide — Implementing pipeline locking (modes, methods, applicable outputs)](https://docs.aws.amazon.com/medialive/latest/ug/pipeline-lock.html)
- [MediaLive User Guide — Input and output requirements, incl. requirements for video aligned locking](https://docs.aws.amazon.com/medialive/latest/ug/pipeline-locking-verify-input.html)
- [MediaLive User Guide — Setting up for locking (console fields, framerate control)](https://docs.aws.amazon.com/medialive/latest/ug/pipeline-locking-set-up.html)
- [MediaLive User Guide — Pipeline locking troubleshooting (ComplexFRCPresent, InputVideoAligned)](https://docs.aws.amazon.com/medialive/latest/ug/pipeline-locking-tshoot.html)
- [MediaLive User Guide — Pipeline locking metrics (PipelinesLocked, InputVideoAligned)](https://docs.aws.amazon.com/medialive/latest/ug/eml-metrics-output-lock.html)
- [MediaLive User Guide — Channel class and linked channels for single-pipeline channels](https://docs.aws.amazon.com/medialive/latest/ug/channel-class.html)
- [CloudFormation — AWS::MediaLive::Channel PipelineLockingSettings (CustomEpoch, PipelineLockingMethod)](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-medialive-channel-pipelinelockingsettings.html)