gemini-omni-1.2-flash na prática: 3 cenários de negócio de geração de vídeo e uma checklist de implementação

Primeiro, confirme o formato de entrada e os limites dos parâmetros

O modelo público atualmente integrado na HiAPI, gemini-omni-1.2-flash, gera vídeos e oferece quatro modos de geração: texto para vídeo, imagem de primeiro frame para vídeo, transição entre primeiro e último frame, e imagem de referência para vídeo. Antes de escrever código, definir "o que vou fornecer desta vez" é mais eficaz do que escolher primeiro o cenário.

As capacidades atualmente não disponíveis incluem: edição de vídeo, continuação de vídeo, entrada de vídeo ou áudio e parâmetro seed. Fluxos que dependam dessas capacidades não podem ser implementados com este modelo.

Parâmetros da requisição

• prompt: único campo obrigatório, deve ser uma string não vazia, com no máximo 20000 caracteres.
• duration: inteiro, com valor de 3 a 15 segundos, padrão 10 segundos.
• resolution: 360p / 720p / 1080p / 4k, padrão 720p. 1080p e 4k são saídas ampliadas; 4k pode não conter faixa de áudio.
• aspect_ratio: 16:9 ou 9:16, padrão 16:9.

Parâmetros de imagem e relação de exclusividade

• image_urls: 1 a 10 imagens de referência públicas via HTTP(S), aciona o modo imagem de referência para vídeo. Mesmo passando apenas uma imagem, continua sendo imagem de referência; não se converte automaticamente para o modo primeiro frame.
• first_frame_url: define a cena inicial, pode ser usado sozinho, formando o modo imagem de primeiro frame para vídeo.
• last_frame_url: deve ser usado junto com first_frame_url, formando a transição entre primeiro e último frame. O modo primeiro e último frame tem duração máxima de 10 segundos e a requisição não pode incluir negative_prompt nem system_prompt.
• image_urls é exclusivo em relação a first_frame_url e last_frame_url: uma requisição só pode usar um desses modos.
• Todos os parâmetros de imagem aceitam apenas URLs HTTP(S) publicamente acessíveis; Base64 não é suportado.

Expectativas a estabelecer desde já: não há garantia de que todos os modos tenham som, sincronização labial ou texto preciso, nem de que o sujeito ou a marca no resultado gerado correspondam exatamente à referência. Tudo isso exige validação humana.

Base de custo: preço por segundo dividido por resolução

O modelo cobra pela duração da requisição, e o preço unitário varia conforme a resolução. Os preços atuais sob o multiplicador padrão são:

• 360p: US$ 0,0229/segundo
• 720p: US$ 0,0343/segundo
• 1080p: US$ 0,0343/segundo
• 4k: US$ 0,0800/segundo

A conversão do orçamento é: preço unitário da resolução escolhida × duração da requisição × quantidade de vídeos. Para a mesma especificação e a mesma duração, cada nova tarefa bem-sucedida normalmente acrescenta ao orçamento o valor de uma tarefa, e não dobra o orçamento acumulado a cada rodada.

A fatura real e o multiplicador aplicável seguem o painel de preços do site. A cobrança é feita pela duração da requisição e não pode ser inferida a partir dos segundos fracionários no contêiner do arquivo de saída.

Duas normas operacionais diretamente ligadas ao orçamento: recriar uma tarefa por insatisfação com o resultado acrescenta o orçamento de uma tarefa; em caso de timeout de rede, consulte primeiro o status da tarefa existente e, só depois de confirmar que ela não foi criada com sucesso, decida se deve criar uma nova.

Cenário 1: teste de conceito a partir de texto criativo

Situação aplicável: há apenas um briefing em texto e é preciso comparar várias direções visuais antes de entrar na produção formal. É o uso mais direto do texto para vídeo.

Como fazer

• Reescreva o briefing em uma descrição visualizável. "Uma jovem caminha rapidamente por uma rua urbana ao amanhecer, segurando um copo de café, com a câmera acompanhando" é mais executável do que "transmitir um estilo de vida vibrante".
• Passe apenas o prompt, sem nenhum parâmetro de imagem, e envie uma tarefa para cada direção.
• Use uma duration curta para controlar o orçamento por vídeo; na fase de teste não é preciso vídeo longo. Mantenha duration e resolution iguais no mesmo lote para facilitar a comparação lado a lado.
• Registro estruturado: arquive prompt, duration, resolution, ID da tarefa e endereço do resultado juntos; só assim a próxima iteração terá referência.

Limites

O resultado do teste de conceito serve para ajudar a escolher a direção, não como material de veiculação; detalhes de storyboard, identidade da marca e legendas de conformidade normalmente ainda exigem produção profissional posterior. Se o quadro final precisar corresponder a materiais existentes, deve-se usar imagem de primeiro frame para vídeo ou imagem de referência para vídeo.

Cenário 2: animação de primeiro frame a partir de imagem

Situação aplicável: já existe uma imagem estática de alta qualidade — foto de produto, capa, ilustração, pôster — e deseja-se animar o quadro mantendo o sujeito original.

Como fazer

• Use first_frame_url para definir a cena inicial; o prompt descreve apenas o movimento e a câmera (aproximação leve, órbita lenta, fluxo de luz e sombra), em vez de redescrever o sujeito.
• Quando for necessário especificar a cena final, passe first_frame_url e last_frame_url juntos, formando a transição entre primeiro e último frame; nesse caso, duration não pode passar de 10 segundos e a requisição não pode incluir negative_prompt nem system_prompt.
• Publique a imagem em um local público primeiro: aceita-se apenas URL HTTP(S) publicamente acessível; endereços internos ou Base64 não funcionam.
• Registre cada item no banco: anote a URL da imagem de origem, prompt, duration, resolution e ID da tarefa, para rastreamento e reutilização.

Diferença em relação ao modo imagem de referência

first_frame_url define "onde começa"; image_urls fornece referência de estilo e conteúdo. Os dois são exclusivos e não podem ser usados na mesma requisição; passar apenas um image_urls não converte para o modo primeiro frame.

Cenário 3: restrição visual por imagem de referência

Situação aplicável: é preciso que um lote de materiais se aproxime de um visual estabelecido em tom, textura e hábitos de composição, e a qualidade de um vídeo isolado não é o principal problema.

Como fazer

• Use image_urls para enviar de 1 a 10 imagens de referência públicas, escolhendo poucos materiais que melhor representem o estilo-alvo; evite misturar referências com objetivos conflitantes e verifique o resultado real gerado.
• Deixe claro que é o modo imagem de referência: mesmo enviando apenas uma imagem, continua sendo imagem de referência para vídeo, sem envolver primeiro frame ou primeiro e último frame.
• Estabeleça itens de verificação fixos: tom dominante, tendência de iluminação, densidade do quadro e área de texto, comparando os novos lotes lado a lado.
• Ao detectar desvio, verifique primeiro os materiais de referência e depois ajuste o prompt, em vez de simplesmente refazer a geração — refazer cria tarefas cobradas por segundo.

Limites

A imagem de referência pode restringir o estilo, mas não garante que o sujeito ou a marca sejam exatamente iguais; ainda é necessário fazer amostragem manual. Entenda-a como "linha de base de estilo" e não como "garantia de estilo"; assim a expectativa ficará mais próxima da realidade.

Checklist de implementação

Confirmar item por item antes de começar ajuda a identificar cedo problemas de parâmetros de entrada e de orçamento.

Capacidades e parâmetros

• Está claro qual modo será usado desta vez: texto para vídeo, imagem de primeiro frame para vídeo, transição entre primeiro e último frame ou imagem de referência para vídeo?
• O prompt está não vazio e dentro de 20000 caracteres?
• duration é um inteiro de 3 a 15 segundos? No modo primeiro e último frame, já foi reduzido para até 10 segundos?
• resolution e aspect_ratio foram escolhidos conforme o uso (padrão 720p, 16:9)?
• Foi usada apenas uma das fontes de imagem: image_urls ou first_frame_url/last_frame_url?
• Todas as imagens são URLs HTTP(S) públicas, sem Base64?
• A requisição de primeiro e último frame já removeu negative_prompt e system_prompt?
• Foram usadas edição de vídeo, continuação, entrada de vídeo/áudio ou seed? Esses recursos não estão disponíveis no momento.

Custo

• O orçamento foi calculado como preço unitário da resolução escolhida × duração × quantidade de vídeos, e não por estimativa?
• O orçamento foi estimado pela "quantidade de candidatos" e não pela "quantidade de entregas"?
• Está claro que, para a mesma especificação e a mesma duração, cada nova tarefa bem-sucedida acrescenta o orçamento de uma tarefa?
• A fatura real segue o painel de preços do site e o multiplicador aplicável, e não uma inferência a partir dos segundos fracionários do contêiner do arquivo?

Engenharia

• O envio de tarefas está assíncrono, sem bloquear o lado da requisição esperando o vídeo?
• O ID da tarefa é mantido e armazenado no banco, incluindo prompt, duration, resolution e endereço do resultado?
• Há uma máquina de estados explícita e chave de idempotência para evitar envios duplicados?
• Em caso de timeout de rede, consulta-se primeiro a tarefa existente, em vez de recriar diretamente?
• A concorrência está limitada e as tarefas em lote aguardam na fila?

Qualidade e aceitação

• Os critérios de aceitação foram definidos antecipadamente: integridade do sujeito, elementos de marca, área de texto e som conforme o esperado?
• Mantém-se um percentual de amostragem manual, sem reduzi-lo ao escalar o volume?
• Foram configurados disjuntores e alertas para o orçamento diário ou por lote?

Os quatro modos compartilham a mesma forma de interface; a diferença está apenas nos parâmetros de entrada. Escolher o modo certo, validar a relação de exclusividade na checagem de parâmetros e calcular o orçamento por quantidade de vídeos: assim o caminho de implementação fica claro antes de entrar em lote.