# 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: Dados & Plataformas

- 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)