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

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.

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.

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.

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.