Como planejar órbita, zoom e clipe em loop no Gemini Omni 1.1 Flash?

Pedir "câmera orbitando o objeto" no prompt é torcer

Desenhar o primeiro e o último frame do plano é dirigir

Fala aí, beleza? O Google soltou em 27 de agosto de 2026 o Gemini Omni 1.1 Flash, atualização do modelo multimodal de geração e edição de vídeo, e ele veio com dois controles que mudam o jogo pra quem pensa em plano e não em clipe solto: o controle de primeiro e último frame (você dá a imagem de como o plano começa e a de onde ele termina, e o modelo gera a metragem entre elas) e a extensão de cena

A ideia é simples: em vez de descrever o movimento em palavras e torcer pra IA adivinhar, você desenha as duas pontas dele 🙂

O que você precisa antes de planejar o movimento

Lista curta, sem enrolação:

• Acesso ao modelo: ele está disponível no Google AI Studio e na Gemini Enterprise Agent Platform. O Omni 1.1 está disponível globalmente no Flow para assinantes Google AI Plus, Pro e Ultra, e a extensão de cena também chega ao app Gemini para esses assinantes
• As duas imagens de keyframe: uma do início do plano e outra do fim. Esse é o insumo principal, é literalmente o seu storyboard
• Opcional, até 3 segundos de vídeo de referência: dá pra mandar vídeo na entrada multimodal pra guiar movimento, contexto visual e consistência de personagem
• A decisão de resolução: a resolução é definida pelo parâmetro resolution dentro do video_config, que aceita 360p, 720p (padrão), 1080p e 4k. O 360p é o modo de rascunho

Na API, o identificador é gemini-omni-1.1-flash, e a edição e o refino por conversa em linguagem natural acontecem pela Interactions API

Se quiser conferir a fonte antes de seguir, o recurso está no anúncio oficial do Google e na documentação da Gemini API

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Passo a passo: planejando um movimento de câmera com keyframes

A lógica aqui é a mesma de qualquer set de filmagem: o movimento é decidido ANTES da câmera rodar

1. Decida o movimento e escreva o plano em uma frase

Órbita? Zoom in? Zoom out? Loop? Escolhe um, e um só

Escreve pra você mesmo, tipo uma nota de direção:

Plano 01
Movimento: orbita horizontal, ~90 graus, sentido horario
Sujeito: tenis sobre a base de concreto, centro do quadro
Luz: mesma fonte, lateral esquerda, do inicio ao fim
Lente: mesma distancia focal nos dois frames

O erro comum deste passo: trocar geometria por adjetivo. "Épico", "cinematográfico" e "dinâmico" não descrevem um movimento, e vale lembrar que não existe lista oficial publicada de termos de câmera reconhecidos pelo modelo, então o que você controla de verdade são os dois frames

2. Construa o frame inicial já pensando no fim

O frame de abertura não é uma imagem bonita solta, ele é metade de um par

Enquanto monta, pergunta: o que dessa cena precisa continuar existindo no último frame?

O erro comum deste passo: caprichar num início lindo que não tem como "virar" no final sem teletransportar o cenário

3. Construa o frame final como consequência geométrica do movimento

Na órbita, é o MESMO objeto visto de outro ângulo

No zoom, é o mesmo eixo com o enquadramento mais fechado ou mais aberto

O erro comum deste passo: entregar dois frames que não compartilham a mesma cena, a mesma iluminação ou a mesma lente. Aí o modelo tem que inventar a ponte, e o movimento vira transformação estranha em vez de câmera andando

4. Rode o rascunho em 360p antes de gastar

O 360p gera até 60% mais rápido e custa cerca de um terço do 720p, então é ali que você descobre se a intenção do movimento se sustenta

O erro comum deste passo: pular o rascunho e ir direto pro caro, descobrindo só no final que os dois frames não conversavam

5. Refine por conversa em vez de recomeçar

A edição e o refino acontecem por linguagem natural via Interactions API, então dá pra ajustar o que saiu em vez de jogar tudo fora e gerar de novo do zero

O erro comum deste passo: recomeçar a cada correção pequena e pagar geração nova por um detalhe que era ajuste

6. Só então suba a resolução final

Aqui você mexe no resolution dentro do video_config e entrega o plano definitivo

O erro comum deste passo: esperar geração nativa em 1080p ou 4k. A documentação descreve essas saídas como upscaled, a geração nativa acontece em resolução menor. Saber disso muda a expectativa de nitidez do seu plano final

Órbita, zoom e loop: como cada movimento se traduz em dois frames

O Google indica o controle de primeiro e último frame exatamente pra três coisas: órbitas de câmera, transições de zoom e transições e clipes em loop

Se liga em como cada uma vira um par de imagens

Órbita: mesmo objeto, posições angulares diferentes

Frame 1: o sujeito visto de frente

Frame 2: o MESMO sujeito, mesma distância, mesma altura de câmera, só que deslocado no ângulo

O que faz a órbita ler como órbita é o que NÃO muda: fundo coerente, luz na mesma direção, escala do objeto igual

Quanto mais elementos fixos os dois frames compartilham, mais o movimento entre eles parece uma câmera girando em volta, e menos parece duas fotos diferentes coladas

Transição de zoom: mesmo eixo, distâncias diferentes

Aqui o segredo é o eixo

Os dois frames precisam estar na mesma linha imaginária que sai da câmera e entra no ponto de interesse, mudando só a distância

Zoom in: começa aberto, termina fechado no detalhe

Zoom out: começa no detalhe, termina revelando o contexto

E tem o uso mais interessante: o par de frames como TRANSIÇÃO entre dois planos do seu roteiro. O último frame de um plano vira o ponto de partida do próximo, e o zoom faz a costura

Clipe em loop: o fim precisa bater com o começo

Clipes em loop são um dos casos de uso que o Google indica pro controle de primeiro e último frame

A lógica é velha e simples: se o quadro que fecha o clipe é visualmente igual ao quadro que abre, a emenda some na repetição

Mesma posição de câmera, mesma luz, mesmo enquadramento nas duas pontas

Aí o loop roda e ninguém acha o corte 😀

E o vídeo de referência, entra quando?

Quando você tem MAIS de um plano e precisa que o personagem continue sendo o mesmo personagem

Dá pra mandar até 3 segundos de vídeo de referência na entrada multimodal pra guiar movimento, contexto visual e consistência de personagem

É o tipo de coisa que salva sequência: dois planos gerados separados, mesma pessoa nos dois

Como estender o plano sem quebrar a continuidade do movimento

Movimento elaborado costuma pedir tempo, e é aí que a extensão de cena entra

Ela acontece em incrementos de 10 segundos, até um total cumulativo de 40 segundos

O detalhe que importa pra direção: a extensão analisa até 10 segundos de contexto do vídeo anterior, contra 1 segundo (o último frame ou segundo) dos modelos Veo anteriores

Parece número seco, mas muda tudo

Com 1 segundo de contexto, o modelo só sabia como o quadro TERMINOU. Com até 10 segundos, ele tem material pra perceber pra onde a coisa estava indo, e é isso que sustenta uma órbita longa ou um movimento contínuo atravessando vários trechos

Na prática, dirigindo:

1. Divida o movimento em trechos de 10 segundos desde o planejamento, sabendo que o teto acumulado é 40 segundos
2. Mantenha a MESMA intenção de movimento em cada extensão, porque órbita que vira zoom no segundo trecho e volta a ser órbita no terceiro não lê como um plano só, lê como três clipes empilhados
3. Termine o movimento antes do teto, deixando folga em vez de encostar no limite e cortar no susto

O erro comum aqui: desenhar um plano que precisa de mais tempo do que o total acumulado permite e só descobrir isso depois de já ter gerado os primeiros trechos

E um ponto de honestidade: não achei documentado se dá pra encadear extensão de cena em cima de um clipe gerado por interpolação de primeiro e último frame, nem como o teto de 40 segundos se comporta nesse encadeamento. Então, se o seu plano depende disso, valide antes de prometer entrega pro cliente 😛

Rascunho ou final? Resolução, velocidade e custo por segundo

O preço é por segundo de vídeo gerado e muda conforme a resolução escolhida:

A lógica de fluxo se escreve sozinha olhando a tabela

Você itera o movimento no rascunho, erra barato, ajusta os dois frames quantas vezes precisar

E paga o final só quando o plano já está certo

Dirigir keyframe é tentativa e erro, e sair testando ângulo direto em 4k é o jeito mais caro de descobrir que o frame final não conversava com o inicial

Planejar antes de gerar: o mesmo princípio no código

Essa ideia de validar barato antes de comprometer o resultado final não é exclusividade de vídeo, ela aparece igualzinho na hora de programar com IA

Pra começar do zero com esse raciocínio, este vídeo do canal mostra o Loop Engineering, a evolução do vibe coding que faz a IA não quebrar o que já funciona:

Conclusão

Movimento de câmera complexo no Gemini Omni 1.1 Flash não sai de adjetivo empilhado no prompt

Sai do par de frames bem pensado: mesma cena, mesma luz, mesma lente, mudando só o que o movimento exige mudar

A órbita é o mesmo objeto em ângulos diferentes, o zoom é o mesmo eixo em distâncias diferentes, e o loop é o fim batendo com o começo

A extensão de cena entra depois, pra dar fôlego ao plano em incrementos de 10 segundos até os 40 segundos cumulativos

Próximo passo concreto, e faz hoje: escolhe um movimento simples (um loop curtinho já serve), monta os dois frames, roda em 360p pra ver se a intenção se sustenta e só depois sobe a resolução

Aí você vai sentir a diferença entre gerar vídeo e dirigir vídeo 😀

até o próximo post!