Aviso: GPT Image 2.6 Flare y Sunburst ya están disponibles con un 20 % de descuento por tiempo limitado, pruébalo ahora
HiAPI
Blog

Tutorial

gemini-omni-1.2-flash en la práctica: 3 escenarios de negocio de generación de video y una lista de verificación para la implementación

Tres escenarios de aplicación: creatividad a partir de texto, dinamización de primer fotograma y restricción visual mediante imágenes de referencia

Nov 11, 2026
以半透明玻璃片叠错形成的冷蓝色条带几何封面图,米白底、构图克制。
En esta página

Primero confirma la forma de entrada y los límites de los parámetros

El modelo público gemini-omni-1.2-flash que HiAPI tiene integrado actualmente genera video y ofrece cuatro modos: texto a video, imagen de primer fotograma a video, transición entre primer y último fotograma, e imágenes de referencia a video. Antes de escribir código, definir «qué le voy a dar de comer esta vez» es más eficaz que elegir primero el escenario.

Las capacidades actualmente no disponibles incluyen: edición de video, continuación de video, video o audio como entrada y el parámetro seed. Los flujos que dependan de estas capacidades no pueden realizarse con este modelo.

Parámetros de la solicitud

  • prompt: el único campo obligatorio, debe ser una cadena no vacía de 20000 caracteres como máximo.
  • duration: entero, de 3 a 15 segundos, por defecto 10 segundos.
  • resolution: 360p / 720p / 1080p / 4k, por defecto 720p. 1080p y 4k son salidas ampliadas; 4k puede no incluir pista de audio.
  • aspect_ratio: 16:9 o 9:16, por defecto 16:9.

Parámetros de imagen y relaciones de exclusión mutua

  • image_urls: de 1 a 10 imágenes de referencia públicas por HTTP(S), activa el modo de imágenes de referencia a video. Si solo se pasa una, sigue siendo modo de referencia y no se convierte automáticamente en modo de primer fotograma.
  • first_frame_url: especifica la imagen inicial; puede usarse sola y da lugar al modo de imagen de primer fotograma a video.
  • last_frame_url: debe usarse junto con first_frame_url y da lugar a la transición entre primer y último fotograma. El modo de primer y último fotograma admite como máximo 10 segundos, y la solicitud no puede incluir negative_prompt ni system_prompt.
  • image_urls es excluyente con first_frame_url y last_frame_url; en una solicitud solo se puede elegir uno de estos modos.
  • Todos los parámetros de imagen solo aceptan URL HTTP(S) de acceso público; no se admite Base64.

Expectativas que conviene fijar de antemano: no se garantiza que todos los modos incluyan sonido, sincronización labial ni texto preciso, ni que el sujeto o la marca del resultado generado coincidan exactamente con la referencia. Todo esto requiere validación humana.

Ilustración conceptual; solo ayuda a explicar la entrada, el flujo o el presupuesto, y no representa datos de pruebas reales del modelo.

Criterio de coste: tarifa por segundo según la resolución

Este modelo factura según la duración de la solicitud, y el precio unitario varía según la resolución. Las tarifas actuales con el multiplicador por defecto son las siguientes:

  • 360p: $0.0229/segundo
  • 720p: $0.0343/segundo
  • 1080p: $0.0343/segundo
  • 4k: $0.0800/segundo

El presupuesto se calcula así: precio unitario de la resolución elegida × duración de la solicitud × número de tareas. Con la misma especificación y la misma duración, cada nueva tarea exitosa suele añadir al presupuesto el importe de una tarea, y no duplicar el presupuesto acumulado de cada ronda.

La factura real y el multiplicador aplicable se rigen por el panel de precios del sitio. La facturación se calcula según la duración de la solicitud y no puede inferirse a partir de los segundos decimales del contenedor del archivo de salida.

Dos normas operativas directamente relacionadas con el presupuesto: volver a crear una tarea porque el resultado no convence añade al presupuesto el importe de una tarea; ante un tiempo de espera de red, primero consulta el estado de las tareas existentes y decide si crear una nueva solo tras confirmar que no se creó correctamente.

Escenario uno: pruebas de concepto creativas a partir de texto

Situación de uso: solo se dispone de un brief de texto y es necesario comparar varias direcciones visuales antes de pasar a la producción formal. Es el uso más directo de texto a video.

Cómo hacerlo

  • Reescribe el brief como una descripción visualizable. «Una mujer joven camina a paso rápido por una calle urbana al amanecer, sostiene un café en la mano y la cámara la sigue» es más ejecutable que «transmitir un estilo de vida vitality».
  • Pasa solo prompt, sin ningún parámetro de imagen, y envía una tarea por cada dirección.
  • Usa una duration corta para controlar el presupuesto de cada tarea; en la fase de prueba no hacen falta videos largos. Mantén duration y resolution iguales dentro del mismo lote para poder comparar horizontalmente.
  • Registro estructurado: archiva juntos prompt, duration, resolution, ID de tarea y dirección del resultado; solo así la siguiente iteración tendrá referencia.

Límites

El producto de las pruebas sirve para elegir una dirección, no como material de campaña; los detalles del guion gráfico, los logotipos de marca y los subtítulos conformes suelen requerir todavía producción profesional posterior. Si la imagen final debe coincidir con material existente, conviene usar imagen de primer fotograma a video o imágenes de referencia a video.

Ilustración conceptual; solo ayuda a explicar la entrada, el flujo o el presupuesto, y no representa datos de pruebas reales del modelo.

Escenario dos: dinamización de una imagen de primer fotograma

Situación de uso: ya se dispone de una imagen estática de alta calidad —fotografía de producto, portada, ilustración, póster— y se quiere que la escena se mueva conservando el sujeto original.

Cómo hacerlo

  • Usa first_frame_url para especificar la imagen inicial; el prompt solo describe el movimiento y la cámara (acercamiento leve, órbita lenta, flujo de luz y sombra), sin volver a describir el sujeto.
  • Cuando haya que especificar la imagen final, pasa first_frame_url y last_frame_url a la vez para crear una transición entre primer y último fotograma; en ese caso duration no puede superar los 10 segundos y la solicitud no puede incluir negative_prompt ni system_prompt.
  • Coloca primero las imágenes en una ubicación pública: solo se aceptan URL HTTP(S) de acceso público; las direcciones de red interna y Base64 no sirven.
  • Guarda cada tarea en la base de datos: registra la URL de la imagen de origen, prompt, duration, resolution e ID de tarea para poder rastrear y reutilizar.

Diferencia con el modo de imágenes de referencia

first_frame_url decide «dónde empieza», mientras que image_urls aporta referencia de estilo y contenido. Ambos son excluyentes y no pueden usarse en la misma solicitud; pasar una sola image_urls no activa el modo de primer fotograma.

Ilustración conceptual; solo ayuda a explicar la entrada, el flujo o el presupuesto, y no representa datos de pruebas reales del modelo.

Escenario tres: restricción visual mediante imágenes de referencia

Situación de uso: se necesita un lote de materiales más cercanos en tono, textura y hábitos de composición a una identidad visual establecida, y la calidad de cada pieza individual no es el problema principal.

Cómo hacerlo

  • Pasa de 1 a 10 imágenes de referencia públicas en image_urls; elige pocas piezas que representen mejor el estilo objetivo, evita mezclar referencias con objetivos contradictorios y revisa los resultados generados.
  • Ten claro que es el modo de imágenes de referencia: aunque solo pases una, sigue siendo imágenes de referencia a video, sin primer ni último fotograma.
  • Define puntos de control fijos: color dominante, tendencia de la luz, densidad de la imagen y zona de texto; compara horizontalmente los nuevos lotes generados.
  • Si detectas desviaciones, revisa primero el material de referencia y luego ajusta el prompt, en lugar de volver a ejecutar a ciegas, ya que cada nueva ejecución añade tareas facturadas por segundo.

Límites

Las imágenes de referencia sirven para restringir el estilo, pero no garantizan que el sujeto o la marca coincidan exactamente; sigue siendo necesario el muestreo manual. Entiéndelo como una «línea base de estilo» y no como un «seguro de estilo», y las expectativas se acercarán más a la realidad.

Lista de verificación para la implementación

Confirmar cada punto antes de empezar ayuda a detectar a tiempo problemas de parámetros de entrada y de presupuesto.

Capacidades y parámetros

  • ¿Está claro qué modo se usa esta vez: texto a video, imagen de primer fotograma a video, transición entre primer y último fotograma o imágenes de referencia a video?
  • ¿El prompt no está vacío y no supera los 20000 caracteres?
  • ¿duration es un entero de 3 a 15 segundos? ¿En el modo de primer y último fotograma ya se ha reducido a 10 segundos o menos?
  • ¿Se han elegido resolution y aspect_ratio según el uso (por defecto 720p, 16:9)?
  • ¿Se ha usado solo una fuente de imágenes: image_urls o first_frame_url/last_frame_url?
  • ¿Todas las imágenes son URL HTTP(S) públicas, sin Base64?
  • ¿Se han eliminado negative_prompt y system_prompt en la solicitud de primer y último fotograma?
  • ¿Se usan edición de video, continuación, entrada de video/audio o seed? Actualmente no están disponibles.

Coste

  • ¿El presupuesto se calcula como precio unitario de la resolución elegida × duración × número de tareas, y no a ojo?
  • ¿El presupuesto se estima según el «número de candidatos» y no según el «número de entregables»?
  • ¿Está claro que, con la misma especificación y duración, cada nueva tarea exitosa añade al presupuesto el importe de una tarea?
  • ¿La factura real se rige por el panel de precios del sitio y el multiplicador aplicable, y no se infiere de los segundos decimales del contenedor del archivo?

Ingeniería

  • ¿El envío de tareas es asíncrono y el lado de la solicitud no se bloquea esperando el video?
  • ¿Se conserva el ID de tarea y se guarda en la base de datos, incluidos prompt, duration, resolution y dirección del resultado?
  • ¿Existe una máquina de estados explícita y una clave de idempotencia para evitar envíos duplicados?
  • ¿Ante un tiempo de espera de red se consultan primero las tareas existentes en lugar de volver a crearlas directamente?
  • ¿Se limita la concurrencia y se deja que las tareas por lotes esperen en cola?

Calidad y validación

  • ¿Los criterios de validación están definidos de antemano: integridad del sujeto, elementos de marca, zona de texto y si el sonido cumple lo esperado?
  • ¿Se mantiene una proporción de muestreo manual que no se reduce al escalar?
  • ¿Se han configurado umbrales de corte y alertas para el presupuesto diario o por lote?

Los cuatro modos comparten la misma forma de interfaz; la diferencia está solo en los parámetros de entrada. Si eliges bien el modo, incluyes las relaciones de exclusión mutua en la validación de parámetros y calculas el presupuesto por número de tareas, antes de pasar al lote, el camino de implementación queda claro.

Artículos relacionados

Ver todos los artículos →

Empieza a crear con artefactos de IA persistentes

Consigue tu API key y llama a modelos de imagen, vídeo y audio a través de una única API basada en tasks.

Leer la documentación de la API