gemini-omni-1.2-flash en pratique : 3 scénarios métier de génération vidéo et une checklist de mise en production

Confirmer d'abord la forme d'entrée et les limites des paramètres

Le modèle public actuellement intégré par HiAPI, gemini-omni-1.2-flash, produit des vidéos et propose quatre modes de génération : texte vers vidéo, image de première frame vers vidéo, transition première/dernière frame, image de référence vers vidéo. Avant d'écrire du code, il est plus efficace de déterminer « ce que je vais lui fournir cette fois » que de choisir d'abord un scénario.

Les capacités actuellement non disponibles incluent : l'édition vidéo, le prolongement vidéo, l'utilisation de vidéo ou d'audio en entrée, et le paramètre seed. Les workflows qui dépendent de ces capacités ne peuvent pas être réalisés avec ce modèle.

Paramètres de requête

• prompt : seul champ obligatoire, doit être une chaîne non vide, 20000 caractères maximum.
• duration : entier, de 3 à 15 secondes, valeur par défaut 10 secondes.
• resolution : 360p / 720p / 1080p / 4k, valeur par défaut 720p. 1080p et 4k sont des sorties agrandies ; la 4k peut ne pas contenir de piste audio.
• aspect_ratio : 16:9 ou 9:16, valeur par défaut 16:9.

Paramètres d'image et relations d'exclusivité

• image_urls : 1 à 10 images de référence HTTP(S) publiques, déclenche le mode image de référence vers vidéo. Même avec une seule image, il s'agit toujours du mode image de référence, sans bascule automatique vers le mode première frame.
• first_frame_url : spécifie l'image de départ, utilisable seule pour former le mode image de première frame vers vidéo.
• last_frame_url : doit être utilisé conjointement avec first_frame_url pour former la transition première/dernière frame. Le mode première/dernière frame est limité à 10 secondes maximum, et la requête ne doit pas inclure negative_prompt ni system_prompt.
• image_urls est exclusif avec first_frame_url et last_frame_url ; une requête ne peut utiliser qu'un seul de ces modes.
• Tous les paramètres d'image n'acceptent que des URL HTTP(S) accessibles publiquement ; Base64 n'est pas pris en charge.

Attentes à établir dès le départ : aucune garantie que chaque mode produise du son, une synchronisation labiale, ou un texte exact, ni que le sujet ou la marque dans le résultat corresponde exactement à la référence. Tout cela nécessite une validation humaine.

Base de coût : tarif à la seconde par palier de résolution

Ce modèle facture selon la durée de la requête, avec un prix unitaire variable selon le palier de résolution. Les tarifs actuels au multiplicateur par défaut sont les suivants :

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

Le calcul du budget est : prix unitaire de la résolution choisie × durée de la requête × nombre de vidéos. À spécification et durée identiques, chaque nouvelle tâche réussie ajoute généralement au budget le montant d'une tâche, et ne double pas le budget cumulé de chaque cycle.

La facturation réelle et le multiplicateur applicable font foi selon le panneau tarifaire du site. La facturation est calculée sur la durée de la requête et ne peut pas être déduite à l'inverse des secondes décimales dans le conteneur du fichier de sortie.

Deux règles opérationnelles directement liées au budget : recréer une tâche parce que le résultat ne convient pas ajoute le budget d'une tâche ; en cas de timeout réseau, consultez d'abord l'état des tâches existantes et confirmez qu'aucune n'a été créée avec succès avant de décider d'en créer une nouvelle.

Scénario un : essais créatifs textuels

Cas d'usage : vous disposez uniquement d'un brief textuel et devez comparer plusieurs directions visuelles avant de passer à la production formelle. C'est l'usage le plus direct du texte vers vidéo.

Méthode

• Réécrire le brief en une description visualisable. « Une jeune femme marche rapidement dans une rue urbaine au petit matin, tenant un café à la main, caméra en travelling » est plus exécutable que « transmettre un mode de vie dynamique ».
• Ne transmettre que le prompt, sans aucun paramètre d'image, et soumettre une tâche par direction.
• Contrôler le budget unitaire avec une duration courte : la phase d'essai n'a pas besoin de longues vidéos ; gardez duration et resolution identiques au sein d'un même lot pour faciliter la comparaison transversale.
• Documentation structurée : archivez ensemble prompt, duration, resolution, ID de tâche et URL du résultat pour disposer d'une référence lors de l'itération suivante.

Limites

Les essais servent à aider au choix d'une direction, pas de matériel de diffusion ; les détails du storyboard, les logos de marque et les sous-titres conformes nécessitent généralement une production professionnelle ultérieure. Si l'image finale doit correspondre à des éléments existants, il faut passer au mode image de première frame vers vidéo ou image de référence vers vidéo.

Scénario deux : animation d'une image de première frame

Cas d'usage : vous disposez déjà d'une image fixe de haute qualité — photo produit, couverture, illustration, affiche — et souhaitez animer l'image tout en conservant le sujet d'origine.

Méthode

• Spécifiez l'image de départ avec first_frame_url ; le prompt ne décrit que le mouvement et la caméra (léger zoom avant, orbite lente, jeu de lumière), sans redécrire le sujet.
• Pour spécifier une image de fin, transmettez à la fois first_frame_url et last_frame_url pour former la transition première/dernière frame ; dans ce cas, duration ne doit pas dépasser 10 secondes, et la requête ne doit pas inclure negative_prompt ni system_prompt.
• Placez d'abord l'image à un emplacement public : seules les URL HTTP(S) accessibles publiquement sont acceptées ; les adresses internes et Base64 sont inutilisables.
• Enregistrez chaque tâche en base : conservez l'URL de l'image source, le prompt, la duration, la resolution et l'ID de tâche pour la traçabilité et la réutilisation.

Différence avec le mode image de référence

first_frame_url détermine « où commence » la vidéo ; image_urls fournit une référence de style et de contenu. Les deux sont exclusifs et ne peuvent pas être utilisés simultanément dans une même requête ; une seule image_urls ne déclenche pas le mode première frame.

Scénario trois : contrainte visuelle par image de référence

Cas d'usage : vous avez besoin d'un lot d'éléments qui se rapprochent d'une identité visuelle établie en termes de teintes, de texture et d'habitudes de composition, la qualité d'une vidéo individuelle n'étant pas le principal enjeu.

Méthode

• Transmettez 1 à 10 images de référence publiques via image_urls, en choisissant peu d'éléments représentatifs du style cible ; évitez de mélanger des images de référence aux objectifs contradictoires et vérifiez les résultats générés.
• Confirmez qu'il s'agit bien du mode image de référence : même avec une seule image, il s'agit toujours du mode image de référence vers vidéo, sans première frame ni première/dernière frame.
• Établissez des points de contrôle fixes : teinte dominante, orientation de la lumière, densité visuelle, zones de texte, à comparer transversalement sur les nouveaux lots produits.
• En cas de dérive, vérifiez d'abord les images de référence, puis ajustez le prompt, au lieu de relancer aveuglément — une relance crée une nouvelle tâche facturée à la seconde.

Limites

Les images de référence peuvent contraindre le style, mais ne garantissent pas une correspondance parfaite du sujet ou de la marque ; un contrôle humain par échantillonnage reste nécessaire. Considérez-les comme une « base de style » et non comme une « assurance de style » : vos attentes seront plus proches de la réalité.

Checklist de mise en production

Vérifier chaque point avant de commencer aide à détecter tôt les problèmes de paramètres d'entrée et de budget.

Capacités et paramètres

• Le mode de cette exécution est-il clairement défini : texte vers vidéo, image de première frame vers vidéo, transition première/dernière frame, ou image de référence vers vidéo ?
• Le prompt est-il non vide et inférieur ou égal à 20000 caractères ?
• La duration est-elle un entier de 3 à 15 secondes ? Le mode première/dernière frame est-il bien ramené à 10 secondes maximum ?
• La resolution et l'aspect_ratio sont-ils choisis selon l'usage (720p et 16:9 par défaut) ?
• Un seul type de source d'image est-il utilisé : image_urls ou first_frame_url/last_frame_url ?
• Toutes les images sont-elles des URL HTTP(S) publiques, sans Base64 ?
• Les champs negative_prompt et system_prompt ont-ils été retirés des requêtes première/dernière frame ?
• Utilisez-vous l'édition vidéo, le prolongement, l'entrée vidéo/audio ou le seed ? Ces capacités ne sont actuellement pas disponibles.

Coût

• Le budget est-il calculé comme prix unitaire de la résolution choisie × durée × nombre de vidéos, et non à l'estime ?
• Le budget est-il estimé sur le « nombre de candidats » plutôt que sur le « nombre de livrables » ?
• Est-il clair qu'à spécification et durée identiques, chaque nouvelle tâche réussie ajoute le budget d'une tâche ?
• La facturation réelle se fonde-t-elle sur le panneau tarifaire du site et le multiplicateur applicable, plutôt que sur une déduction à partir des secondes décimales du conteneur de fichier ?

Ingénierie

• La soumission des tâches est-elle asynchrone, sans blocage côté requête en attente de la vidéo ?
• L'ID de tâche est-il conservé et enregistré en base, avec prompt, duration, resolution et URL du résultat ?
• Existe-t-il une machine à états explicite et une clé d'idempotence pour éviter les soumissions en double ?
• En cas de timeout réseau, interrogez-vous d'abord les tâches existantes au lieu d'en recréer immédiatement ?
• La concurrence est-elle limitée, avec des tâches par lots en attente dans une file ?

Qualité et validation

• Les critères d'acceptation sont-ils fixés à l'avance : intégrité du sujet, éléments de marque, zones de texte, conformité du son ?
• Le taux de contrôle humain par échantillonnage est-il maintenu, sans baisse lors du passage à l'échelle ?
• Des coupe-circuits et des alertes sont-ils définis pour le budget quotidien ou par lot ?

Les quatre modes partagent la même forme d'interface ; seule diffère la nature des paramètres d'entrée. Choisissez le bon mode, intégrez les relations d'exclusivité dans la validation des paramètres, calculez clairement le budget par nombre de vidéos, puis passez au traitement par lots : le chemin de mise en production devient limpide.