Liste de contrôle pour le choix de Gemini Omni 1.2 Flash : modes d'entrée, spécifications et budget

Ce que vérifie cette liste

gemini-omni-1.2-flash est accessible publiquement via HiAPI. Lors du choix, vérifiez d'abord quatre points : si les modes d'entrée couvrent votre chaîne de production de contenus, si les paramètres de spécification satisfont les contraintes produit, si le budget peut être calculé clairement selon la résolution et la durée, et quels effets ne sont pas garantis. La liste ci-dessous décrit uniquement les capacités publiques actuelles et n'inclut ni tests réels de concurrents ni classements.

Modes d'entrée : quatre chemins disponibles et règles d'exclusion mutuelle

Les modes d'entrée actuellement publics comprennent :

• Texte vers vidéo : générer une vidéo uniquement à partir d'un prompt.
• Image de première frame vers vidéo : spécifier l'image de départ avec first_frame_url pour animer l'image.
• Transition entre première et dernière frame : spécifier simultanément first_frame_url et last_frame_url pour générer une transition entre les images de début et de fin ; ce mode est limité à 10 secondes maximum et ne peut pas inclure negative_prompt ni system_prompt.
• Image de référence vers vidéo : transmettre 1 à 10 images de référence HTTP(S) publiques via image_urls pour contraindre le style ou le sujet ; même avec une seule image, il s'agit toujours d'une image de référence, et non d'une première frame.

Faites particulièrement attention aux limites d'exclusion mutuelle : image_urls est mutuellement exclusif avec first_frame_url/last_frame_url ; last_frame_url dépend de first_frame_url et ne peut pas être utilisé seul. first_frame_url peut spécifier seul l'image de départ. Tous les paramètres d'image n'acceptent que des URL HTTP(S) publiques, et non le Base64.

Les capacités non disponibles incluent : l'édition vidéo, le prolongement vidéo, l'entrée vidéo ou audio, et le seed. Si vous avez besoin de ces capacités, ne placez pas ce modèle parmi les candidats.

Paramètres de spécification : obligatoires, valeurs par défaut et contraintes strictes

prompt est le seul champ obligatoire, doit être non vide et comporter au maximum 20000 caractères. Les autres paramètres se définissent selon les besoins :

• 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 ; 4k peut ne pas inclure de piste audio.
• aspect_ratio : 16:9 ou 9:16, valeur par défaut 16:9.

Outre la limite de 10 secondes maximum, le mode première et dernière frame ne peut pas utiliser simultanément negative_prompt ni system_prompt. Le mode image de référence est soumis à une contrainte de 1 à 10 images et au format URL. Intégrer ces contraintes dans la validation des paramètres produit est plus simple que de corriger après un échec d'appel.

Budget : prix unitaire selon la résolution × durée de la requête × nombre de vidéos

Les tarifs actuels par défaut, différenciés selon la résolution, sont :

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

Budget = prix unitaire de la résolution choisie × durée de la requête × nombre de vidéos. La facture réelle et le multiplicateur applicable font foi ; ne déduisez pas la facturation à partir du nombre de secondes dans le conteneur du fichier (par exemple les secondes décimales). La durée de la requête doit être calculée selon le paramètre duration, et non selon les métadonnées du fichier vidéo.

Il faut distinguer deux types d'événements de coût : un succès mais insatisfaisant nécessite de recréer une tâche, ce qui augmente le budget ; un véritable échec est traité selon les règles de remboursement de la plateforme. Ne présumez pas que tous les échecs sont remboursés ou qu'aucun ne l'est ; la facture réelle fait foi. En cas de délai réseau, ne recréez pas directement la tâche ; interrogez d'abord la tâche existante pour éviter qu'une même requête soit facturée deux fois.

Éléments non garantis : ces effets doivent être validés par vous-même

Une capacité publique ne constitue pas une promesse d'effet. Il n'est actuellement pas garanti que tous les modes incluent du son, une synchronisation labiale, un texte exact, ni une cohérence parfaite du sujet ou de la marque. 1080p et 4k sont des sorties agrandies ; 4k peut ne pas inclure de piste audio. Lors du choix, ne déduisez pas la qualité, le temps de traitement ou les avantages de coût à partir de la page des paramètres ; sans données de test réelles, il ne faut pas non plus inventer de comparaisons ou de classements de concurrents.

Valider avec vos propres échantillons : qualité, délai de traitement et coût applicable

Il est recommandé d'utiliser le même lot de prompts, le même lot d'images de référence ou d'images de première frame, et d'exécuter séparément le texte vers vidéo, l'image de première frame vers vidéo, la transition entre première et dernière frame et l'image de référence vers vidéo (le cas échéant), en consignant trois séries de résultats :

• Qualité : dans vos scénarios typiques, combien de générations donnent un résultat directement utilisable ; ne regardez pas seulement la meilleure.
• Délai de traitement : le temps écoulé entre la soumission de la tâche et l'obtention d'un résultat utilisable, y compris les nouvelles tentatives et interrogations nécessaires.
• Coût applicable : calculez le budget selon votre résolution, votre durée et votre nombre de vidéos, en incluant les reprises des succès mais insatisfaisants, et non seulement le prix unitaire.

Lors de la validation, fixez les entrées et les paramètres, consignez chaque point, et ne mélangez pas dans une même comparaison des résultats de résolutions, de durées ou de modes d'entrée différents. Seuls vos propres échantillons peuvent indiquer si ce modèle convient à votre produit.

Points à vérifier avant l'intégration

• Votre produit a-t-il besoin d'édition vidéo, de prolongement vidéo, d'entrée vidéo ou audio, ou de seed ? Si oui, ce modèle ne convient pas.
• Votre chaîne de production de contenus peut-elle fournir des URL d'images HTTP(S) publiques ? Si vous ne disposez que de Base64, il faut d'abord adapter le téléversement et l'hébergement.
• Utilisez-vous simultanément image_urls et les paramètres de première/dernière frame ? Les deux sont mutuellement exclusifs et doivent être bloqués au niveau de la validation des paramètres.
• Dans le mode première et dernière frame, la durée dépasse-t-elle 10 secondes, ou negative_prompt ou system_prompt sont-ils inclus par erreur ?
• Le budget est-il calculé comme prix unitaire selon la résolution × durée de la requête × nombre de vidéos, avec une marge prévue pour les reprises des succès mais insatisfaisants ?
• En cas de délai réseau, interrogez-vous d'abord la tâche existante au lieu de la recréer directement ?

Grâce à l'interface unifiée de HiAPI, vous pouvez d'abord réaliser une validation sur petit échantillon selon la liste ci-dessus, puis décider de l'intégration en production. Le choix doit se fonder sur la qualité, le délai de traitement et le coût applicable que vous avez mesurés vous-même, et non sur des conclusions comparatives non testées.