Créer des vidéos courtes avec Kling 3.0 image-vers-vidéo via l'API HiAPI

Les vidéos courtes sont un format que tout pipeline de contenu finit tôt ou tard par devoir prendre en charge, et la manière la moins coûteuse de les produire de façon fiable à grande échelle est l'image-vers-vidéo : prenez une image fixe que vous maîtrisez déjà — une photo de produit, un design de personnage, une keyframe générée — et laissez un modèle vidéo la mettre en mouvement. Le point de terminaison image-vers-vidéo de Kling 3.0 sur HiAPI excelle dans ce domaine, et offre une fonctionnalité que la plupart des modèles i2v ignorent : vous pouvez fournir à la fois une première et une dernière image, de sorte que le modèle anime entre deux états au lieu de simplement extrapoler un mouvement à partir d'une seule image.

Ce tutoriel construit un flux de travail complet et scriptable : générer une première image, la soumettre à l'API de tâches asynchrones de Kling 3.0, interroger jusqu'à l'achèvement et télécharger un clip fini avec un audio synchronisé natif — le tout via de simples appels HTTP que vous pouvez glisser directement dans des tâches par lots.

Pourquoi choisir image-vers-vidéo plutôt que texte-vers-vidéo

Le texte-vers-vidéo vous réserve une surprise à chaque fois. L'image-vers-vidéo vous donne un point de départ que vous avez déjà validé — ce qui compte lorsque cette image est une photo de produit, un personnage de marque ou toute chose qui doit avoir une apparence précise avant de s'animer. Le modèle image-vers-vidéo de Kling 3.0 pousse cela plus loin grâce au contrôle première image + dernière image : passez une image de référence et le modèle la traite uniquement comme point de départ ; passez-en deux et la seconde devient l'état final cible, le modèle interpolant le mouvement entre les deux. C'est en pratique une animation par keyframes programmable en un seul appel API, sans aucun éditeur de timeline.

Structure de la requête

Kling 3.0 image-vers-vidéo s'exécute sur le point de terminaison unifié de tâches asynchrones de HiAPI — POST /v1/tasks, puis interrogation de GET /v1/tasks/{id} jusqu'à son achèvement. Le schéma d'entrée de ce modèle est délibérément minimal :

{
  "model": "kling-3.0/image-to-video",
  "input": {
    "prompt": "a lantern slowly lighting up as the camera pushes in, warm cinematic glow",
    "image_urls": ["https://static.hiapi.ai/blog/kling-3-0-image-to-video-short-form-workflow/first-frame-v2.jpg"],
    "duration": 3,
    "resolution": "720p",
    "sound": true
  }
}

Avant de construire quoi que ce soit autour de cela, quelques points méritent d'être connus :

• image_urls accepte 1 ou 2 entrées. Une image signifie « anime à partir de cette image ». Deux images signifient « anime de la première vers la seconde » — c'est le contrôle première image + dernière image mentionné plus haut. Il n'existe pas de champ tail_image_url séparé ; tout s'exprime par la position dans le tableau.
• duration est un entier de 3 à 15 secondes. Les plateformes de vidéos courtes préfèrent généralement des clips de 3 à 8 secondes, donc pour une scène unique, vous voudrez en général le bas de cette fourchette.
• resolution peut monter jusqu'à 4K, plus que le modèle frère kling-3.0-turbo (plafonné à 1080p). Le prix à payer, c'est le coût — voir la tarification ci-dessous — donc 720p ou 1080p couvrent la plupart des cas d'usage de vidéos courtes sans payer pour une résolution que personne ne remarquera sur un écran de téléphone.
• sound est un booléen, et il s'agit d'une véritable génération audio synchronisée, pas d'un clip muet sur lequel on a plaqué de la musique après coup. Activez-le lorsque le mouvement de votre scène produit naturellement du son (une porte qui claque, du vent, des pas) : le résultat sera nettement plus crédible qu'un rendu muet.
• Il n'y a pas de champ aspect_ratio — le format de sortie correspond au rapport d'image que possède déjà votre image d'entrée.

Script de bout en bout

Voici le flux complet en Python : créer la tâche, interroger jusqu'à l'achèvement, télécharger le résultat.

import requests
import time

API_KEY = "YOUR_HIAPI_KEY"
BASE = "https://api.hiapi.ai/v1/tasks"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

def submit_i2v(image_url, prompt, duration=3, resolution="720p", sound=True):
    payload = {
        "model": "kling-3.0/image-to-video",
        "input": {
            "prompt": prompt,
            "image_urls": [image_url],
            "duration": duration,
            "resolution": resolution,
            "sound": sound,
        },
    }
    resp = requests.post(BASE, headers=HEADERS, json=payload, timeout=60)
    resp.raise_for_status()
    return resp.json()["data"]["taskId"]

def wait_for_result(task_id, poll_interval=5, timeout_s=600):
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        resp = requests.get(f"{BASE}/{task_id}", headers=HEADERS, timeout=30)
        resp.raise_for_status()
        task = resp.json()["data"]
        if task["status"] == "success":
            return task["output"][0]["url"]
        if task["status"] == "fail":
            raise RuntimeError(task.get("error"))
        time.sleep(poll_interval)
    raise TimeoutError(f"task {task_id} did not finish in {timeout_s}s")

task_id = submit_i2v(
    image_url="https://static.hiapi.ai/blog/kling-3-0-image-to-video-short-form-workflow/first-frame-v2.jpg",
    prompt="a lantern slowly lighting up as the camera pushes in, warm cinematic glow",
)
video_url = wait_for_result(task_id)
print(video_url)  # temporary signed URL — download immediately, don't store it as a permanent link

Un détail fait facilement trébucher lorsqu'on branche cela dans un pipeline réel : le output[0].url que vous récupérez est un lien temporaire qui expire. Téléchargez immédiatement les octets et déplacez-les dans votre propre stockage, au lieu de conserver durablement l'URL de sortie de la tâche quelque part.

Voici la première image utilisée dans cet exemple, et le clip que Kling 3.0 en a généré avec sound: true :

Un clip de 3 secondes en 720p avec audio comme celui ci-dessus coûte un peu plus de 0,40 $ — assez peu cher pour itérer plusieurs fois sur le prompt avant de fixer la version à livrer.

Tarification : la résolution et l'audio influencent tous deux le coût

Kling 3.0 image-vers-vidéo est facturé à la seconde de durée de sortie, et la résolution comme l'activation de l'audio influencent le tarif :

Résolution	Sans audio	Avec audio
720p	0,10 $/s	0,143 $/s
1080p	0,129 $/s	0,193 $/s
4K	0,479 $/s	—

Exemple de calcul : un clip de 3 secondes en 720p avec son coûte environ 0,43 $. Un clip de 5 secondes en 1080p sans audio coûte 0,645 $ ; le même clip avec audio coûte 0,965 $. Pour du contenu vidéo court dont la plupart des clips finis tiennent dans une fourchette de 3 à 8 secondes, 720p ou 1080p est presque toujours le bon choix — la tarification 4K ne se justifie que si vous devez composer le clip dans quelque chose en aval qui bénéficiera réellement de la résolution supplémentaire. Avant de lancer quoi que ce soit à grande échelle, consultez la tarification actuelle, car des détails comme les tarifs à la seconde méritent d'être vérifiés sur la page en direct plutôt que mémorisés.

Passer au traitement par lots dans un vrai flux de travail

Pour du contenu vidéo court, quelle que soit l'échelle, vous ne voulez pas soumettre une tâche puis la fixer du regard — vous voulez émettre un lot de tâches d'un coup et récupérer les résultats à leur arrivée. Chaque tâche étant indépendante et identifiée par son propre taskId, le schéma est simple : soumettez d'abord toutes les requêtes image-vers-vidéo, stockez les identifiants de tâche renvoyés, puis interrogez-les en boucle et n'agissez que lorsque chaque tâche passe à success ou fail. Votre pipeline tourne ainsi au débit réel de la plateforme, au lieu de se sérialiser sur la génération la plus lente.

Quelques habitudes à prendre dès le départ :

• Vérifiez l'accessibilité des images sources avant de soumettre. L'API de tâches acceptera volontiers une URL, puis la tâche échouera plus tard si l'image est inaccessible — une requête HEAD préalable évite une génération gaspillée.
• Traitez l'état fail comme un résultat normal, pas comme une exception. Les sorties du modèle refusent parfois une combinaison prompt/image donnée ; enregistrez l'échec et passez à l'élément suivant plutôt que d'interrompre tout le lot.
• Réutilisez les clips entre variantes autant que possible. Si vous testez plusieurs sous-titres ou bandes sonores sur la même animation générée, inutile de régénérer la vidéo elle-même — c'est purement une étape d'édition en aval.

Si vous configurez une clé API et l'authentification pour la première fois, le guide de démarrage rapide de HiAPI couvre les bases pour obtenir une clé et effectuer votre premier appel authentifié, après quoi vous pourrez construire dessus un pipeline de traitement par lots complet.

En résumé

Le modèle image-vers-vidéo de Kling 3.0 transforme, en un seul appel HTTP, une simple image fixe — ou deux si vous voulez un contrôle première image + dernière image — en un court clip avec audio synchronisé, à un tarif qui évolue de manière prévisible selon la durée, la résolution et la présence ou non du son. Pour un pipeline de vidéos courtes, la combinaison de ce contrôle, d'un coût par clip modéré en 720p/1080p et d'une API de tâches asynchrones simple vous permet de passer facilement d'« une image fixe » à « un lot de clips finis », sans jamais ouvrir un éditeur vidéo.