Como funciona a renderização determinística de frames, e porque é que frames perdidos arruínam um anúncio

A renderização determinística de frames funciona ao definir um tempo virtual preciso, pintar a cena para esse tempo e capturar o resultado uma vez para cada frame de saída. Como o renderizador avança por timestamps conhecidos, e não pela velocidade de reprodução real, um browser lento não consegue saltar silenciosamente parte do movimento.

O que é um frame perdido?

Um vídeo é uma sequência de imagens fixas mostradas a uma taxa fixa. A 30 frames por segundo, uma cena de três segundos precisa de 90 posições de frame distintas. Cada uma representa um ponto planeado na timeline.

Um frame perdido acontece quando o processo de captura falha ao registar uma dessas imagens esperadas ou repete outra imagem no seu lugar. Isso pode acontecer quando um gravador de ecrã e a página que está a gravar dependem ambos do tempo real. A página tenta animar, o gravador tenta amostrá-la, e a máquina tenta fazer muitas outras coisas ao mesmo tempo.

Se um frame demorar demasiado tempo a pintar, o relógio da animação continua a avançar. O gravador pode apanhar a cena depois de esta já ter saltado para a frente. O ficheiro terminado pode continuar a indicar a taxa de frames pedida, porque imagens repetidas ou atrasadas preenchem o contentor, mas o movimento lá dentro já não segue o percurso pretendido.

Isto é fácil de não notar numa pré-visualização em bruto. Num anúncio polido, aparece como um engasgo, uma mudança súbita de velocidade, ou texto que treme durante um movimento.

Porque é que os frames perdidos são especialmente visíveis em imagens de produto?

As interfaces contêm arestas retas, tipo de letra pequeno, colunas alinhadas e espaçamento repetido. O olho usa essas características como uma grelha. Um movimento de câmara irregular contra essa grelha expõe rapidamente erros de tempo.

Imagine um dashboard a mover-se para a esquerda a uma velocidade constante. Com um espaçamento de frames uniforme, cada coluna percorre a mesma distância entre imagens. Se um frame for repetido e o seguinte recuperar o atraso, o dashboard para e salta. O movimento pode durar menos de um segundo, mas a mudança é visível porque a grelha dá ao olho uma régua.

Os frames perdidos também enfraquecem o tempo dos cortes. Um acento da banda sonora pode cair no timestamp planeado enquanto o visual chega atrasado. Uma legenda pode sair antes de a fala terminar. A revelação de um botão pode perder o pequeno assentamento que a torna legível.

Um bom material de origem não consegue corrigir isso depois da captura. As imagens reais captadas no browser protegem a própria interface, mas o relógio de renderização é que tem de proteger a forma como essas imagens se movem.

Como é que um relógio virtual muda o processo?

Um renderizador determinístico não carrega em play e espera que a cena consiga acompanhar. Controla o tempo.

Para cada frame, segue uma sequência:

1. Calcular o timestamp a partir do número do frame e da taxa de frames.
2. Definir o relógio virtual da cena para esse timestamp.
3. Pedir à cena para renderizar o seu estado de forma síncrona.
4. Deixar o browser terminar o layout e a pintura.
5. Capturar uma imagem fixa.
6. Avançar para o timestamp seguinte.

A 30fps, o timestamp do frame i baseia-se em i × 1000 ÷ 30 milissegundos. A captura pode demorar mais do que um trigésimo de segundo em tempo real. Isso não muda a posição virtual representada pela imagem.

A sequência de imagens fixas é depois codificada a 30fps. A codificação decide a rapidez com que os espectadores veem as imagens, não a rapidez com que a máquina conseguiu criá-las.

O que torna uma cena determinística?

A cena precisa de uma única fonte de tempo. Cada propriedade em movimento deve ser derivada do timestamp fornecido pelo renderizador: posição, escala, opacidade, máscaras, contadores e o beat ativo.

Inputs não controlados quebram a repetibilidade. Um pedido de rede em tempo real pode devolver conteúdo diferente. Uma animação CSS pode avançar segundo o seu próprio relógio. Um valor aleatório pode mover uma partícula para um novo lugar em cada renderização. Uma webfont que carregue tarde pode mudar as quebras de linha depois de os primeiros frames já terem sido capturados.

Uma cena fiável usa, por isso, recursos capturados locais, dimensões fixas, tipos de letra conhecidos e movimento guiado pelo timestamp. Carrega essas dependências antes de a sequência de frames começar. Se for necessária aleatoriedade para uma textura ou padrão, deve usar uma semente estável.

A repetibilidade torna a revisão mais segura. Mude um título e o tempo mantém-se igual. Ajuste um recorte e todos os outros planos ficam no sítio. Renderize os mesmos inputs outra vez e consegue comparar os resultados sem se perguntar se a carga da máquina mudou a animação.

Como é que o tempo da voz se encaixa na timeline determinística?

A voz é medida antes de a timeline final ser definida. Cada fala gerada tem uma duração de áudio real, e essa duração torna-se o tempo mínimo disponível para a sua cena. Um ritmo pedido pode acrescentar uma pausa, mas não deve cortar uma fala a meio.

Assim que o início e o fim da cena são conhecidos, os seus pontos de corte também guiam a banda sonora. Um pulso ou impacto pode cair na transição real, em vez de numa estimativa escrita antes de o áudio existir.

Isto importa para a edição descrita em o que faz um sizzle reel prender a atenção. O ritmo vem de beats com significado. O tempo determinístico mantém esses beats intactos ao longo da produção.

O que é que a codificação acrescenta depois de os frames existirem?

Os frames numerados ainda não são um ficheiro de entrega prático. Um codificador transforma-os num stream de vídeo comprimido e faz o mux desse stream com a voz e a música.

No sizzledraft, os formatos de entrega são vertical 1080x1920 ou horizontal 1920x1080 a 30fps. O vídeo usa h264 com o formato de pixel yuv420p para ampla compatibilidade de reprodução. A voz e a banda sonora sintetizada são misturadas, normalizadas para -14 LUFS, e acrescentadas como um stream de áudio AAC.

A codificação não consegue recuperar um frame que nunca foi renderizado. O seu trabalho é preservar e empacotar a sequência que recebe. É por isso que o processo de frames e as definições de codec devem ser tratados como fases separadas.

Como é que uma renderização pode ser verificada em vez de apenas aberta?

Abrir o MP4 e ver os primeiros segundos é útil, mas não prova que o ficheiro cumpre o seu contrato. A verificação automatizada pode inspecionar várias propriedades independentes.

Primeiro, sondar o ficheiro:

• A largura e a altura correspondem ao formato escolhido
• A taxa de frames é 30fps
• A duração está dentro da tolerância permitida
• O codec de vídeo é h264
• O formato de pixel é yuv420p
• Existe um stream de áudio

Segundo, inspecionar a cena criada em timestamps de amostra à procura de elementos que ultrapassem o viewport. Um layout pode parecer bem no início e cortar durante um movimento.

Terceiro, descodificar frames selecionados do MP4 terminado e comparar os seus hashes. Se todas as imagens amostradas forem idênticas, uma cena que devia mover-se pode ter congelado. Amostras dentro de cada beat e entre beats dão uma verificação básica de que a mudança sobreviveu à codificação.

Estas verificações não substituem uma revisão criativa. Apanham falhas técnicas para que a revisão humana se possa concentrar no gancho, na legibilidade e na afirmação.

A renderização determinística torna toda a animação boa?

Não. Torna a animação pretendida reproduzível. Uma curva de ease fraca, um recorte ilegível ou um frame sobrecarregado vão ser reproduzidos na perfeição até alguém os mudar.

A vantagem de produção é que os defeitos se tornam específicos. Se um movimento parece abrupto, ajuste a sua função de tempo. Se uma legenda sai cedo demais, mude o seu intervalo. Se o produto fica demasiado pequeno em formato vertical, crie uma composição mais próxima. O sistema deixa de acrescentar erros aleatórios de reprodução ao diagnóstico.

Comece pelas escolhas editoriais certas. Escolha vertical ou horizontal a partir do destino, e escreva um gancho que as imagens consigam provar. Depois deixe que um relógio exato leve essas escolhas até ao ficheiro.

Pode transformar um site público num anúncio renderizado de forma determinística com o sizzledraft. O resultado não é a gravação de um browser a tentar desempenhar-se em tempo real. É uma sequência em que cada frame tinha um compromisso marcado.