🎬 Janusly Benchmark — Rodada 28

Por que rodamos: R27a validou que character_orientation="video" destrava 30s nativo no Kling v3. Próximo passo: vídeo de criador real (Pedro 77s) pra ver se o pipeline escala. Tentamos via Replicate primeiro e quebramos: conta com <$5 de crédito caiu pra rate limit burst=1 (6 req/min) e os 3 chunks paralelos retornaram 402/429. Solução: comprar o Trial Package oficial da Kling ($14, 100 unidades, 5 concurrent, 30 dias) e ir direto na API api-singapore.klingai.com. Funcionou tecnicamente: 3 chunks paralelos de verdade, JWT HS256, hidden param funcionando, vídeo bonito de 77s.

⚠️ Surpresa de custo (consultado via /account/costs): meu chute inicial de "$0.30/call" tava errado. O custo real, batido com a API de billing do Kling, foi 27 unidades por chunk de 30s e 15.3 unidades pelo chunk de 17s. Total 69.3 unidades = $9.70 a $0.14/unidade do Trial. Pra 3min seriam ~162u = $22.68/vídeo. Não é pricing de produto — é pricing de prototipagem.

Resultado — Pedro 77s completo no Kling oficial

Por que rodamos: R26 ficou ótimo mas o pipeline tem 4 chunks em paralelo + stitching + autocut. Pedro perguntou: "em vez de cortes de 8-10s dá pra gerar com mais tempo? quanto custa 3min?". Pesquisamos e achamos duas saídas pra fugir do stitching. (A) Kling v3 motion-control tem um param hidden character_orientation="video" que destrava 30s na mesma chamada (não documentado oficialmente, mas o modelo aceita). (B) Wan 2.2 Animate aceita 30s nativo direto na input — sem trick. Mesmo char_image do R26 (cena gpt-image-2 podcast studio), mesmo source video do Pedro 30s.

Comparação 3-way — todos os 30s do mesmo source do Pedro

Por que rodamos: R25 validou que Kling v3 funciona via Replicate, mas usamos a imagem errada (headshot raw). Pedro apontou que o cenário ficou ruim e cobrou o teste real: 30s stitched + autocut estilo R24, mas agora com v3. Esta é a reprodução fiel do R24 trocando só o modelo (kling-v2.6-motion-control → kling-v3-motion-control), mesma estratégia V2 (char_image fixa = scene composta no gpt-image-2), 4 chunks de 7.5s rodados em paralelo, mesmo prompt/seed.

Output R26 — stitched bruto (28.80s)

Output R26 com autocut — moderado (25s) vs agressivo (20s)

Comparação direta — R24 (Kling v2.6) vs R26 (Kling v3)

Por que rodamos: Kling v3 saiu em fev/2026 e a gente ainda tava em v2.6. Pra entender se vale migrar, rodamos o mesmo input do Pedro (vídeo 10s + headshot podcast) em duas vias. Replicate é drop-in (já usamos lá pra v2.6, basta trocar o slug do modelo) — caro mas zero setup. Oficial SDK precisa de auth JWT HS256 (Access Key + Secret Key), URL pública pro vídeo de input (servimos via Cloudflare Pages), mas dá acesso a std e pro mode com pricing direto da fonte.

Achado importante sobre Extend: a doc oficial é explícita — Extend feature (estende vídeo até 3min em blocos de 5s) só funciona pra V1.0/V1.5/V1.6, NÃO pra motion-control v2.6 ou v3. A estratégia "gerar 30s + estender até 3min" não funciona com motion-control. Long video continua sendo client-side stitching.

Output R25 — Replicate (1080p) vs Oficial std (720p)

Por que rodamos: as R22.1 e R23 tentaram esconder as junções dos chunks com transições. Pedro propôs uma virada de chave: e se a gente parar de tentar esconder e fizer um vídeo onde cortes são parte do estilo? É como Lucas Arrial, Mila Markson, conteúdo TikTok/Reels é editado — auto-editor (e o "remover suspiros" do CapCut) cortam pausas/silêncios e deixam o vídeo denso com cortes constantes. As junções dos chunks viram só "mais cortes" entre dezenas — ficam invisíveis. Bonus: vídeo mais curto e dinâmico = mais retenção.

Output R24 — moderado (25s) vs agressivo (20s)

Por que rodamos: dos 4 testes da R22.1, a V2 (char_image fixa) ficou a melhor — identidade preservada do início ao fim sem drift. Mas ainda tinha "quebra" nos cortes entre chunks. A V4 tentou mascarar com zoom mas usou crop centralizado uniforme (afasta de todos os lados igual ao invés de puxar pra cara) — não parece transição, parece glitch. R23 corrige isso: zoom convergindo pro rosto do Pedro (~centro-x, ~30% do topo no half-body podcast 768×1168), 1.0× → 1.15× → 1.0× ao longo de 0.8s nas 3 junções (7.2s, 14.4s, 21.6s). O frame puxa pro rosto e relaxa, igual câmera de cinema.

Output R23 — V2 + face-zoom transition

Comparação — V4 (crop centralizado) vs R23 (face-zoom)

Por que rodamos: a R21 validou o pipeline visual (gpt-image-2 cena + Kling v2.6 motion-control) mas com limite estrito de <10s no Kling. Pedro mandou: "como fazer um vídeo mais longo, igual ao modelo de referência (30s)?" Duas estratégias possíveis: usar um modelo que aceita 30s direto (Wan 2.2 Animate) ou costurar 4 chunks de Kling com frame continuity. Test data: mesmo source de 30s do Pedro (pedro-video-30s.mp4), mesma cena custom da R21 (scene-1791a11fa43dc161.png, podcast studio half-body), mesma seed/cfg quando aplicável.

Output final — Wan 2.2 (single call 30s) vs Kling v2.6 stitched (4 chunks 7.5s)

R22.1 — Resolvendo o "drift de identidade" do Kling stitched

Pedro identificou que a versão B (Kling stitched) "vai perdendo a identidade original" ao longo do tempo. Causa raiz: frame continuity é "xerox de xerox" — o último frame do chunk N (já uma reinterpretação do Kling) vira o char_image do chunk N+1, e cada iteração compõe pequenos drifts. Rodamos 3 estratégias em paralelo pra atacar o problema:

Output das 4 variantes (mesmo source, mesma cena, mesma seed)

Por que rodamos: sair do "scripts soltos" e validar o pipeline rodando num app visual real (~/dev/flow, Next.js + React Flow + Zustand). Template Cena → Motion Transfer: 1 foto + prompt → gpt-image-2 gera a cena profissional → essa cena vira image + vídeo source vira driving no Kling v2.6 motion-control → vídeo final preserva gestos/áudio do source com Pedro/Diego em cenário de IA. Test data: Pedro (foto headshot real + vídeo 30s trim 9.5s) e Diego (foto + vídeo 9s) rodando o mesmo template, mesmo prompt ("in a modern podcast studio, warm lighting, looking at the camera, half-body shot"), cfg_scale 0.5, seed 42.

Output final — Pedro vs Diego (mesmo template, mesma config)

Por que rodamos: Luma anunciou Uni-1 (a API pública só expõe photon-1 ainda) e mantém Ray-2 como modelo de vídeo. Hipótese: pode ser mais barato e mais rápido que o stack atual (gpt-image-2 multi-frame + Wan 2.2 Animate). Pegamos os mesmos 4 frames do Pedro NYC (R17) e mandamos como character_ref pro Photon-1, depois usamos a char_image vencedora da R17 v3 como keyframe0 pro Ray-2 gerar 5s de vídeo livre. Comparar: identidade (Photon vs gpt-image-2) e qualidade cinematográfica do vídeo curto sem driving (Ray-2 vs Wan).

R18 — Identidade: Photon-1 vs gpt-image-2 multi-frame (Pedro NYC half-body)

Luma Photon-1 (4 char_ref)

gpt-image-2 multi-frame (R17 v3)

R19 — Vídeo cinematográfico: Ray-2 a partir da char_image R17 v3

5 segundos de vídeo livre (sem driving), prompt natural ("man speaks naturally with subtle hand gestures, NYC golden hour"). 102s de geração, 720p, 9:16. Compare com a Wan da R17 v3 logo abaixo (que precisou de driving video do Pedro real e levou ~20min).

Frames Ray-2 @ 0.5s, 2.5s, 4.5s

@ 0.5s — mãos abertas

@ 2.5s — mãos juntas

@ 4.5s — mão no peito + crowd real

Diagnóstico que motivou esta rodada: na Rodada 14 (Pedro NYC, source 77s) o output do Wan ficou perfeito nos primeiros 30s e foi degradando conforme avançou — efeito de drift temporal porque o Wan ancora forte na character_image nos primeiros segundos e depois passa a se basear cada vez mais nos próprios frames gerados, acumulando erro. Hipótese dupla: (1) cortar o source pra 30s mantém o Wan dentro da janela onde a ancoragem na char_image ainda é forte; (2) char_image multi-frame — em vez de 1 frame único do source (que pode ter olho fechado, expressão estranha, mão na frente do rosto), sintetizar a identidade a partir de 5 frames variados via gpt-image-2 com image[] multi-input, gerando uma "DNA visual" mais robusta.

Etapa 1 — Selecionar 5 frames variados (eyes-open, sem oclusão)

Pra Diego (12s) extraímos frames a cada ~0.5s e visualmente filtramos os 5 com olhos abertos e expressão limpa: 0.5s, 2.5s, 7.0s, 7.5s, 9.0s. Pra Pedro (30s) extraímos a 2s, 8s, 15s, 22s, 28s e cropamos 576×720 do topo pra remover as legendas hard-coded em PT-BR que estavam no terço inferior. O ponto chave: 1 frame ruim contamina a char_image (problema observado na Rodada 16 quando o frame escolhido tinha o Diego de olho meio fechado). 5 frames variados deixam o gpt-image-2 sintetizar a identidade mediana, mais resiliente a artefato pontual.

Diego — frame 0.5s

Diego — frame 2.5s

Diego — frame 9.0s

Pedro — frame 2s (cropado)

Pedro — frame 15s (cropado)

Pedro — frame 28s (cropado)

Etapa 2 — gpt-image-2 sintetiza identidade dos 5 frames

Endpoint /v1/images/edits com model=gpt-image-2, size=1024x1536, quality=high. Em vez do image singular, mandamos image[] 5 vezes via multipart. Prompt explícito: "Hyper-realistic photo of the same man shown across the multiple reference frames — synthesize his identity (face structure, beard, hair, build) from all of them." Resultado: char_image significativamente mais fiel ao real do que a v2 (single-frame) — Pedro com a barba grisalha real, cabelo bagunçado natural, olhar seguro; Diego com o tom certo de cabelo grisalho e expressão de pessoa-conversando.

Diego v3 — char_image multi-frame ★

Sintetizada a partir de 5 frames do source (0.5s, 2.5s, 7.0s, 7.5s, 9.0s). Identidade do Diego mais firme — cabelo grisalho com a textura real, olhar limpo, mão na pose certa de gesticulação.

Pedro v3 — char_image multi-frame ★

Sintetizada a partir de 5 frames do source (2s, 8s, 15s, 22s, 28s). Identidade muito mais fiel: barba mista grisalha, cabelo bagunçado, estrutura facial certa. Pose com as duas mãos no peito, ideal como anchor pro Wan.

Etapa 3 — Wan 2.2 Animate: Pedro 30s v2 (single-frame) vs v3 (multi-frame)

Mesmo source de 30s, mesmo cenário NYC. v2 usa a char_image gerada de 1 frame único da Rodada 14 (gpt-image-2 single). v3 usa a char_image multi-frame desta rodada (gpt-image-2 multi). Custo Wan: $0.40 cada. Tempos: v2 1213s (~20.2min), v3 1135s (~18.9min). Nota: uma terceira variante (v1, char com gpt-image-1 single-frame) estava planejada mas Replicate ficou sem crédito antes do disparo — pode ser adicionada depois.

Frames de comparação (5s · 15s · 25s):

v2 @ 5s

v3 @ 5s ★

v2 @ 15s

v3 @ 15s ★

v2 @ 25s

v3 @ 25s ★

Etapa 4 — Diego v3 multi-frame (12s, podcast studio)

Mesmo source de 12s da Rodada 16, mas com char_image multi-frame em vez do single-frame da v2 (que usou 1 frame extraído @5s). Comparar com a Rodada 16 v2 ★ pra ver se a multi-frame faz diferença visível em vídeo curto onde o drift é mínimo.

O que essa rodada faz: primeira validação de ponta-a-ponta do conceito original do Janusly — "your two faces, one video". Pega um frame qualquer de um vídeo casual do Diego (gravação caseira com guitarras na parede e mic de podcast amador), regera esse mesmo Diego em um studio profissional via OpenAI gpt-image-1 preservando identidade (rosto, barba, cabelo), e usa essa imagem como character_image do Wan 2.2 Animate junto com o vídeo casual original como driving video. Resultado: Diego no studio profissional fazendo exatamente os mesmos movimentos e dizendo exatamente as mesmas coisas do vídeo caseiro.

Etapa 1 — Extração do frame de referência

Do media/diego-heygen/diego-3min.mp4 (gravação curada de 3min) cortamos um clipe de 12s começando aos 30s e extraímos um frame aos 5s do clipe. Frame mostra Diego em ambiente totalmente caseiro: guitarras pendurads na parede, mic de podcast caseiro do lado direito, camiseta azul, gesticulando com as duas mãos no nível do peito.

Source casual — vídeo de 12s (driving video)

Recorte do diego-3min.mp4 começando aos 30s. Diego fala naturalmente em ambiente doméstico com mic amador.

Frame extraído @5s do clipe

Foto fonte (64KB) usada como referência de identidade pro OpenAI gpt-image-1 reimaginar em outro ambiente.

Etapa 2 — OpenAI reimagina em studio profissional (comparativo gpt-image-1 vs gpt-image-2)

Endpoint /v1/images/edits com size=1024x1536, quality=high. Prompt descreve: studio de podcast profissional, painéis acústicos navy escuro, mic broadcast SM7B no boom arm, iluminação LED warm com key light difuso à esquerda, lente 50mm cinematográfica, t-shirt navy fitted, mãos visíveis em pose de gesticulação, vertical 9:16. Rodamos em 2 modelos pra comparar: o gpt-image-1 (geração anterior) e o gpt-image-2 (lançado em 2026-04-21, mais recente da OpenAI). Custo: $0.06 cada.

Frame casual (input)

Home setup: guitarras, mic amador, camiseta azul, iluminação flat.

gpt-image-1 (geração anterior)

Identidade preservada, mas framing apertado e pose um pouco rígida. Iluminação correta porém menos cinematográfica.

gpt-image-2 (★ mais recente)

Framing aberto natural, prateleira com vaso à esquerda dando profundidade, anel + relógio nas mãos, textura de pele realista. Realismo claramente superior.

Etapa 3 — Wan 2.2 Animate transfere movimentos + voz original (v1 vs v2)

Modelo wan-video/wan-2.2-animate-animation recebe (1) video=clipe casual de 12s, (2) character_image=Diego no studio gerado pelo OpenAI, (3) merge_audio=true pra preservar a voz/áudio original do source. Wan extrai os movimentos faciais, gestos das mãos, postura corporal do source casual e aplica esses mesmos movimentos no Diego do studio. Rodamos 2 vezes — uma com character do gpt-image-1 (v1, 12.7min) e outra com character do gpt-image-2 (v2, 11.1min). Custo: $0.40 cada.

O que essa rodada faz: a Rodada 13 (Reels Neuralink v3/v4) ficou pronta com custo marginal de ~$1.51/vídeo (Wan 2.2 Animate $0.40 + sync/lipsync-2 $1.38, com a voz do ElevenLabs IVC v2 já fora do cálculo porque é assinatura mensal). Esta rodada explorou 2 frentes pra reduzir esse custo: (1) HeyGen Audio-to-Video direto via API, que em tese eliminaria o lipsync do Replicate aproveitando o Digital Twin já treinado, e (2) kwaivgi/kling-lip-sync como substituto do sync/lipsync-2. Em paralelo, refatoramos o NeuralinkShort.tsx em BRollComposition<Theme> pra que o próximo Reels não precise fork do componente — só plugar dado.

1️⃣ HeyGen Audio-to-Video direto via API — falhou

Hipótese: como o Diego já tem Digital Twin treinado na conta HeyGen, podia usar a rota POST /v2/video/generate passando character.type=avatar + voice.type=audio com audio_asset_id do MP3 do ElevenLabs já clonado. Se funcionasse, custo marginal por Reels iria pra ~$0.40 (só Wan, sem lipsync). Upload do áudio passou (200 OK), mas a chamada de geração retornou MOVIO_PAYMENT_INSUFFICIENT_CREDIT. Investigação confirmou: o plano mensal HeyGen cobre só "studio credits" (uso via interface web). Rota API precisa de "api credits" comprados à parte (~$0.30/min Avatar III, $1.30/min Avatar IV) com depósito mínimo de $5. Pesquisa de pricing completa em docs/heygen-api-pricing-2026-05.md: nenhum plano API HeyGen vence o sync/lipsync-2 ($1.38/53s) com qualidade equivalente.

2️⃣ kwaivgi/kling-lip-sync — funciona pra clipes curtos, falha em escala

Hipótese: o Kling tem lipsync próprio (kwaivgi/kling-lip-sync v8311467f, oficial Kuaishou, 43k runs no Replicate) que poderia ser concorrente do sync/lipsync-2. Testamos com um chunk de 9s do vídeo Diego + áudio ElevenLabs v2. Resultado abaixo — qualidade boa, fundo escuro preservado, boca sincroniza naturalmente. Bloqueio: teto de 10s por chamada. Pra cobrir os 53s do Reels precisaria fatiar em 6 chunks + stitch (frame-perfect alignment é não-trivial). Processing também é 4.5× mais lento por segundo (21.9× realtime vs 4.9× do sync/lipsync-2). Sem vantagem de custo nem de qualidade. Análise completa em docs/lipsync-kling-vs-sync-2026-05.md.

3️⃣ Refactor: NeuralinkShort → BRollComposition<Theme>

A composição estava monolítica — toda lógica de B-roll, captions, PiP avatar, soundtrack e brand label hardcoded no NeuralinkShort.tsx. Pra próximo Reels (Anthropic, OpenAI, etc) seria fork do componente. Refatoramos pra dado + componente genérico:

Pra criar Reels novo agora: criar themes/anthropic.ts com segments + captions + avatarVideo + brandLabel, adicionar no array themes do Root.tsx, plugar B-roll em public/broll/, rodar npx remotion render src/index.ts AnthropicShort out/anthropic.mp4. Zero código React novo. Smoke test do refactor: rerendizamos o Neuralink com a versão genérica e comparamos com o pré-refactor — frames idênticos, mesma duração (53.226s), mesmo audio (aac 48kHz stereo 317kbps), mesmo número de frames (1595). Variação só no tamanho do arquivo (29.7MB vs 37MB) — não-determinismo do x264 com --concurrency=4, sem impacto visual.

Veredito: investigação que não mudou o pipeline mas validou que ele é o ótimo local. Em ambos os benchmarks, o setup atual venceu — HeyGen API por preço, Kling lipsync por escalabilidade. O refactor abriu espaço pra próximo Reels ser questão de dado, não de código. Conhecer o teto é tão valioso quanto subir o teto.

O que essa rodada faz: pega o vídeo bruto do Diego falando sobre Neuralink (gravado em chroma green pelo HeyGen Digital Twin), troca a voz robotizada do HeyGen pela voz clonada no ElevenLabs (IVC PT-BR), re-sincroniza a boca via sync/lipsync-2 e compõe via Remotion um Reels vertical 1080×1920 com (1) avatar do Diego em PiP circular pulsante no canto superior direito, (2) 9 segmentos de b-roll com imagens reais de notícia (Wikimedia + Fox News + MIT Tech Review) sincronizados com o discurso via Whisper word-level, (3) captions cinéticas word-by-word com reveal animado, (4) Ken Burns em diagonal nas imagens, (5) progress bar com gradiente cyan→verde, (6) badge contador "01/09" e título/subtítulo grandes por segmento. Tudo declarado como componente React, renderizado headless via remotion render.

Mapa do roteiro × b-roll (9 segmentos · timestamps via Whisper no áudio v2)

Veredito v3: a v2 sofreu de um erro grosseiro de IVC — usei os 51s da voz do HeyGen como sample de treino, e o ElevenLabs clonou fielmente a voz... robotizada. Resultado: dois clones com a mesma cara. A v3 corrige isso treinando o IVC com 3min do áudio REAL do Diego (vídeo OBS de 2026-01-23, fala natural sem TTS no meio). Agora sim a prosódia é o Diego de verdade — respiração, pausa, "tipo", "sacou" — não a versão sintética. Aprendizado pra reter: nunca treinar voice clone com áudio sintético, sempre com gravação original do humano. Fluxo final v3: OBS (sample real) → ElevenLabs IVC v2 → TTS roteiro → Whisper word-level → sync/lipsync-2 → Remotion (Reels). Próximo: abstrair em BRollComposition<Theme> e plugar no fim do pipeline Janusly como output opcional "formato Reels".

A/B da voz — 3 fontes (HeyGen × ElevenLabs com sample errado × ElevenLabs com áudio REAL)

Comparação das 3 versões de voz no mesmo roteiro Neuralink. Modelo eleven_multilingual_v2 nas duas IVCs, mesmas settings stability=0.45 similarity_boost=0.85 style=0.25. Aprendizado central: o sample que alimenta o IVC define o ceiling de qualidade — clonar uma voz já robotizada produz outra voz robotizada.

O que essa rodada resolve: Rodada 12 (Wan + FLUX studio) cumpriu a promessa Janusly mas com cenário neutro (estúdio cinza) e enquadramento headshot — Wan replicou o crop apertado, cortou as mãos. Esta rodada testa cenário custom (Nova York, terno navy, golden hour) com referência meio-corpo gerada pelo OpenAI. v1 usou gpt-image-1; v2 (★) repete tudo com gpt-image-2 (lançado 2026-04-21) — realismo nitidamente superior, profundidade cinematográfica, micro-detalhes (Chrysler Building ao fundo, pedestres, golden hour mais quente).

Imagens de referência — gpt-image-1 vs gpt-image-2 ★

v1 — gpt-image-1

Pedro de terno navy, NYC, mãos abertas — primeira geração

v2 — gpt-image-2 ★

Mesmo prompt, modelo novo: pele com micro-textura, profundidade real, táxis e pedestres definidos

Vídeo final — Wan Animate v1 vs v2 ★ (77s, single pass)

Comparação lado a lado — casual vs v1 vs v2 ★

5s — casual

5s — v1 (gpt-image-1)

5s — v2 (gpt-image-2) ★

35s — casual

35s — v1

35s — v2 ★

65s — casual

65s — v1

65s — v2 ★

Veredito: esta rodada prova que o pipeline Janusly escala pra qualquer cenário, não só estúdio. A descoberta da v2 é que OpenAI gpt-image-2 (★, lançado 2026-04-21) vira o gerador padrão pra cenários custom (NYC, escritório, livraria) — supera FLUX e o próprio gpt-image-1 em profundidade, micro-detalhes e identidade. FLUX fica reservado só pra cenários neutros econômicos. Próximo: validar com mais sujeitos além do Pedro e otimizar throughput.

O que essa rodada resolve: Rodada 10 (Kling Stitched) entregou "Pedro pro" mas em horizontal 1168×768 (perdeu o formato vertical do source) e com pequenas inconsistências entre os 8 cortes. Esta rodada usa Wan 2.2 Animate Animation em uma única chamada com character_image=Pedro de terno em estúdio (FLUX) + video=source 77s + merge_audio=true. Resultado: vídeo único de 77s mantendo aspect ratio vertical original, Pedro consistente do início ao fim, voz original preservada e gestos do source replicados (mão na testa aos 5s, postura aos 35s, gestos aos 65s).

Vídeo final (77s, single pass Wan Animate)

Comparação lado a lado — mesmo timestamp, casual vs pro

5s — casual

5s — pro (Wan)

35s — casual

35s — pro (Wan)

65s — casual

65s — pro (Wan)

Veredito: esta é a Janusly real. Casual virou pro, mantém voz, gestos e identidade, em formato vertical (igual o source). Custo viável ($0.40 por 77s) e pipeline limpo (FLUX + Wan, dois passos). Próximo: testar com cenários customizados além de "estúdio cinza" (escritório, podcast booth, livraria), validar com sujeitos além do Pedro, e otimizar throughput pra reduzir os 75min de processamento.

O que essa rodada faz: pega o Pedro (Digital Twin já treinado no HeyGen + voice clone + vídeo source de 9s) e roda 4 testes paralelos. Dois pelo HeyGen — Digital Twin gera o avatar falando o texto com voz clonada, em chroma green e em foto de cenário podcast. Dois pelo Janusly stack — FLUX Kontext gera headshot do Pedro num cenário diferente (estúdio vs podcast), Kling v2.6 transfere os movimentos do vídeo casual de 9s pro Pedro novo. Mesma identidade source, mesmas configurações em cada par. Permite ver o trade-off real: HeyGen tem áudio sintético consistente e enquadramento controlado, Janusly tem movimento autêntico e áudio original.

Headshots gerados (FLUX Kontext, input: pedro-headshot-real.jpg)

Estúdio cinza, blazer escuro

Estúdio podcast, painel acústico

Cenário 1 — Estúdio

Cenário 2 — Podcast

Veredito: são produtos diferentes. HeyGen é "fábrica de conteúdo" — você grava 1 vez, gera infinitos vídeos com texto novo. Janusly é "transformação de gravação real" — toda vez que você grava, vira pro. O Pedro é o caso onde a gente já tem material pra comparar honestamente: se você quer escalar conteúdo de marca pessoal, HeyGen ganha. Se você quer que esse vídeo específico fique pro mantendo a fala original, Janusly ganha. Os dois caminhos coexistem no mesmo sujeito.

O que essa rodada resolve: a Rodada 8 (Background Replacement) preserva 100% o Pedro mas só troca o fundo — Pedro continua casual com fundo de estúdio, não vira "Pedro profissional". A premissa Janusly é mais ambiciosa: casual virou pro de verdade. O caminho validado original (FLUX Kontext + Kling motion-control) entrega isso, mas Kling v2.6 cap em 10s. Esta rodada quebra a barreira: cortamos os 77s em 8 segmentos de ~9.66s, rodamos os 8 em paralelo no Kling com mesma seed (42), mesmo headshot, mesmo prompt, costuramos com ffmpeg concat e overlay do áudio original. Resultado: vídeo inteiro de 75s do Pedro pro fazendo exatamente os mesmos gestos do Pedro casual, voz original do Pedro preservada.

Vídeo final (77s costurado de 8 segmentos Kling)

Comparação lado a lado — mesmo timestamp, casual vs pro

5s — casual

5s — pro (Kling)

42s — casual

42s — pro (Kling)

68s — casual

68s — pro (Kling)

Veredito: esta é a Janusly real. A Rodada 8 (bg replacement) era honesta sobre identidade mas não cumpria a promessa de transformação — era "Pedro casual com fundo de estúdio", não "Pedro profissional". A Rodada 10 cumpre: Pedro vira pro, mantém os movimentos, mantém a voz, mantém a identidade. O custo de $2.40 por vídeo de 77s é viável pra um produto que cobra $19-49/mês com créditos limitados. Próximo passo: testar consistência entre segmentos com seeds variadas, validar com mais sujeitos além do Pedro, integrar bg customizado via composite pós-Kling.

Mudança de premissa: as rodadas anteriores usaram o Pedro como sujeito de teste. Esta rodada inverte e usa o próprio Diego (dono do projeto) — confirma que a stack HeyGen Digital Twin funciona tal qual no Pedro com sujeito novo, e abre porta pra usar o avatar do Diego em conteúdo real. Cortamos os 3 primeiros minutos do source de 1h05 (2026-01-23 10-40-27.mp4), subimos pro POST /v3/avatars com type=digital_twin, e em ~15 min o HeyGen entregou o avatar treinado + voice clone auto-gerado da fala do Diego. Geramos dois vídeos comparativos com o mesmo avatar.

A) Roteiro inédito sobre Neuralink — fundo escuro

B) Mesmo avatar em chroma key verde — pra editor cortar

Veredito: validação prática de que o avatar Diego está usável pra conteúdo real (vídeo Neuralink) e pra workflow de editor (chroma green). Não muda a conclusão estratégica das rodadas com Pedro — Background Replacement (Rodada 8) ainda é o caminho Janusly real porque preserva o sujeito original. Mas o avatar Diego no HeyGen vira ferramenta utilitária pra conteúdo onde o Diego não precisa gravar a cada vez.

Mudança de premissa: as Rodadas 1-7 todas pediram pro modelo gerar um Pedro novo (avatar, motion transfer, etc). Mesmo no teto comercial (HeyGen Digital Twin), o output sempre virou "avatar AI falando", nunca "Pedro casual virou pro". Esta rodada inverte: a gente não toca no Pedro — só troca o fundo. Stack: arielreplicate/robust_video_matting extrai foreground com green-screen alpha (~120s), depois ffmpeg compõe sobre o estúdio FLUX 1.1 Pro com chromakey + despill + grading cinematográfico (contrast, saturation, gamma). Áudio do Pedro 100% preservado, motion 100% preservado, identidade 100% preservada. Só o sofá vira estúdio.

Veredito: esse é o caminho. As 7 rodadas anteriores provaram que gerar um Pedro pro é tecnicamente possível mas semanticamente errado pro Janusly — sempre vira talking head genérico. Trocar só o fundo respeita a tese central da marca: a sua face real, a sua voz real, os seus movimentos reais, em ambiente que parece estúdio. Próximas iterações: relight via ComfyUI/IC-Light pra casar iluminação do Pedro com o estúdio (ataca a primeira fraqueza da lista), bgs alternativos (escritório, café cool, cenário corporativo), e talvez um leve lipsync correction caso o áudio for trocado depois.

Salto de tier: a Rodada 6 já estava no teto do Photo Avatar (avatar gerado a partir de UMA foto). Mas o HeyGen tem um tier acima — Digital Twin, que treina o avatar a partir de um vídeo real do usuário. Mandamos o vídeo de 77s do Pedro pra POST /v3/avatars com type=digital_twin — aceito sem briga (o mínimo declarado de 2min é orientação, não bloqueio). Em ~10 min o HeyGen entregou: 1 look digital_twin (motion aprendido do vídeo) + 3 looks photo_avatar com engine avatar_iv (best-frame selection) + voice clone auto-gerado da fala do Pedro. Geramos três comparativos abaixo.

A) Avatar IV (photo_avatar best-frame) + voice clone TTS

B) Digital Twin (vídeo-treinado) + voice clone TTS — caso escalável

C) Digital Twin + áudio real do Pedro — caso autêntico

Veredito: esta é a melhor versão do HeyGen sobre nosso input — vídeo-treinado + voz real + áudio original. Confirma que mesmo no tier máximo o HeyGen entrega avatar do Pedro falando profissional, não Pedro casual virou profissional. A diferença é semântica mas crítica pro Janusly. Comparação direta entre B e C ajuda a separar o efeito do TTS vs áudio real; comparação entre A e B mostra se o digital_twin entrega motion diferente do photo_avatar IV. Os três vídeos juntos esgotam o que o HeyGen tem a oferecer — daqui pra frente, motion transfer real só fora desse stack.

Por que repetir o HeyGen: a Rodada 5 ficou aquém do que o HeyGen entrega no marketing — figura olhando pro nada, mexendo pouco, falando texto qualquer. Diagnóstico: usamos o tier mais básico (Photo Avatar TTS + fundo cinza chapado + framing "normal"). Esta rodada explora o teto real do produto: áudio real do Pedro extraído do vídeo casual (ffmpeg -vn -ar 22050 -ac 1 -b:a 64k), background de podcast estúdio gerado via FLUX 1.1 Pro (LED panels, bokeh quente, foam acústico), framing closeUp com matting ligado.

Veredito: este é o teto real do HeyGen sobre nosso input — bem acima da Rodada 5. Mostra que a primeira rodada estava subaproveitando o produto, não que o produto não entrega. Mas mesmo no teto, o HeyGen entrega avatar AI com voz real, não vídeo do Pedro virou profissional. Mantém a conclusão da Rodada 5: ótimo benchmark de teto comercial, ruim como pipeline Janusly. Próximos testes precisam atacar motion transfer + identidade junto (Wan + Magic Hour Face Swap, Hedra Character-3, etc).

Hipótese desta rodada: resultados anteriores (Wan Animation/Replace + GFPGAN) ainda não chegaram numa "visão real possível da pessoa em outro ambiente". Estratégia: usar pack multi-frame do Pedro (10 prints extraídos do vídeo casual em timestamps variados) e treinar um Photo Avatar dedicado no HeyGen. HeyGen Avatar V tem o melhor Face Similarity de mercado em 2026 (0.840 vs Veo 3.1 = 0.714).

Pipeline: 10 frames Pedro → Upload Asset (HeyGen) → Create Photo Avatar Group → Add Looks (3 lotes de 4) → Train (12 min) → Generate Video com voz "Pedro Lima - Friendly" (PT-BR) → output 720p.

Veredito: HeyGen Avatar V resolve identidade visual perfeitamente, mas quebra a tese fundadora do Janusly: deixa de ser "sua gravação real virou profissional" e vira "avatar AI fala um script". É o melhor produto comercial pra avatar talking head, mas não é o produto que estamos construindo. Útil como benchmark de teto, não como pipeline de produção.

Hipótese testada: a perda de feição nos outputs Wan vinha da etapa FLUX Kontext (que reconstrói a foto de headshot, perdendo traços do rosto original). Refeitos os dois testes Wan usando uma foto real do Pedro (crop do pedro-foto-3.jpg, sem FLUX no meio). Em seguida, aplicamos GFPGAN v1.4 frame-a-frame (paralelo, 8 threads via Replicate) pra restaurar nitidez facial sobre os dois outputs.

Animation (foto real Pedro + driving video)

Replace (sobre Luma Ray3, foto real Pedro)

Veredito desta rodada: comparar A1 vs A2 e B1 vs B2 lado a lado pra decidir se GFPGAN entra na pipeline default. A escolha entre Animation e Replace já estava clara — Animation ganha pelo áudio nativo. A pergunta agora é: GFPGAN melhora identidade o suficiente pra justificar +$0.30 e +3min? Ou Wan + foto real já é suficiente?

Como funciona: recebe vídeo + áudio e re-sincroniza a boca do vídeo pra bater exatamente com o áudio fornecido. Usado como pós-processo sobre o melhor output do Wan 2.2 Animate (a versão Animation, que já tem áudio do Pedro), para corrigir qualquer dessincronia labial residual.

Pipeline final candidata: Foto Pedro → FLUX Kontext (headshot pro) → Wan 2.2 Animate Animation (cenário + movimentos + áudio merged) → LatentSync (lipsync corrigido). Custo total estimado: ~$0.30-0.60 por vídeo. Tudo via Replicate, escalável.

Como funciona: Wan 2.2 Animate tem 2 modos. Animation anima uma foto-alvo (Pedro headshot pro) seguindo os movimentos faciais e corporais de um vídeo source — equivalente teórico ao Act-Two do Runway, mas open-source via Replicate. Replace faz o oposto: substitui o personagem dentro de um vídeo existente (no nosso caso, o resultado Luma Ray3) pelo personagem da foto-alvo, usando segmentação SAM2 internamente.

O que era esperado: Act-Two é a feature do Runway desenhada exatamente pro caso Janusly — "performance capture": pega 1 vídeo de driving performance + 1 imagem/vídeo de character e anima o character com os movimentos faciais e gestos do driving. Em teoria, é o que o Janusly precisa: identidade da foto + movimentos do vídeo casual.

Observação: única plataforma do benchmark com áudio gerado nativamente (no caso, voz/ambiente sintetizados — não a voz real do Pedro). Veo 3 é image-to-video, então a entrada foi a foto do Pedro + prompt do estúdio. Primeira tentativa foi rejeitada pelo content filter (E005, alegação "sensitive content"); a 2ª passou usando google/veo-3-fast e prompt sem termos de "preservação de identidade".

Observação: "Edit Video" é literalmente posicionada como "Swap backgrounds, lighting, angles - all without reshooting" — descrição idêntica ao caso Janusly. Truncou pra 5s. SDK Runway é maduro.

Como funciona: recebe foto-alvo + vídeo source → transfere movimentos e fala do source pra figura da foto. Não é "swap de fundo" puro, é motion transfer com pessoa-alvo já em ambiente novo (a foto define o cenário).