Making Video from a Single Image — Kling·Veo·Sora vs Wan·HunyuanVideo, What to Pick and When

• Introduction — The Answer, Up Front
• What a Hosted API Actually Costs Per Second
• Why Kling Has No "Per-Second Price" — and the Truth About the Numbers Floating Around
• The Constraints That Actually Bite When You Feed an Image
• Do the Open Weights Actually Run on My GPU?
• Licensing — If You're Reading from South Korea, This Section Changes the Conclusion
• What You Can and Can't Measure from a Demo Reel
• So, What Do You Pick?
• Closing
• References

Introduction — The Answer, Up Front

"I want to feed in a single image, write a prompt, and get a video — what should I use?" As of July 2026, the short answer to that question is this.

If you are going to run open weights in South Korea, it's Wan2.2. Not because of performance, because of the license. The license document for the HunyuanVideo family states, from its very first lines, that it does not apply in the European Union, the United Kingdom, and South Korea. Wan2.2 is Apache 2.0 for both code and weights. If you are going to use a hosted API, the first fork is whether you need audio — Veo 3.1's price sheet itself is "audio included," while Kling charges exactly 2x when you turn audio on. And if your input image has a human face, Sora drops out of the running. OpenAI's docs state directly that input images with human faces are currently rejected.

This post traces where those three sentences come from, following each vendor's primary documentation. The architecture story (DiT, 3D VAE, flow matching) was already covered in an analysis of SOTA video-generation models, so here we look only at the numbers you need to choose one and run it: price, VRAM, generation time, and licensing.

One thing up front. Every number in this post was taken directly from each vendor's official price sheet or docs, and all the source pages are listed at the end. The image quality in vendor demo reels and phrases like "cinematic quality" are not covered here — because they are not measurable values. Why that is, I discuss separately below.

What a Hosted API Actually Costs Per Second

OpenAI and Google have public, flat-rate price sheets. Anyone can view them without logging in, and the price is written per second.

OpenAI's price sheet states "Prices per second" and lists the following.

Use the Batch API and it is exactly half. For a pipeline that does not need a real-time response, that is a 50% discount you get essentially for free.

Google's Gemini API price sheet lists Veo like this. The column header of the table is "Paid Tier, per second in USD," and the important part is that each row is named "video with audio price (default)" — Veo's price includes audio.

The three Veo 3.1 variants (veo-3.1-generate-preview, veo-3.1-fast-generate-preview, veo-3.1-lite-generate-preview) are all preview, and Google attaches the warning "Preview models may change before becoming stable and have more restrictive rate limits." The free tier is "Not available" across every Veo model.

There is one more sentence on the price sheet worth noticing: "You will only be charged if your video is successfully generated." Meaning you are not billed if generation fails. OpenAI's price sheet has no corresponding sentence.

I will also record one odd thing as-is. The same page still lists Veo 3 (veo-3.0-generate-001) and Veo 2 (veo-2.0-generate-001), both carrying the warning "deprecated and will be shut down on June 30, 2026." As of July 17, 2026, the day I am writing this, that date has already passed. Whether the page simply was not updated or the shutdown was postponed cannot be known from the docs alone, so instead of an unverified guess I copy only what the docs say. For new code, Veo 3.1 is the right thing to look at.

Why Kling Has No "Per-Second Price" — and the Truth About the Numbers Floating Around

Investigate Kling and you hit a wall immediately. Search and you get a pile of numbers like "Kling 3.0 from $0.075 per second" and "Kling API at $0.084–$0.168 per second." But the source for all of those numbers is not Kling but third-party API resellers — intermediaries like PiAPI, kie.ai, evolink, and costbench.

I opened Kling's official developer pricing page and checked directly. Two things become clear.

First, the string 0.075 never appears even once on Kling's official pricing page. And the "Kling 3.0" table on that page is not a video table but an image model table (Text to Image / Image to Image / Image Editing). The newest video model listed on Kling's official API price sheet is Kling-V2-6. In other words, "Kling 3.0 video at $0.075 per second" is a price Kling has never announced. It may be a reseller's own rate, but that is not Kling's price.

Second, Kling has no concept of a "per-second price" to begin with. Kling bills by clip — either 5 seconds or 10 seconds. The Kling-V2-6 rows on the official price sheet look like this.

The right-hand "per-second conversion" column is not a value Kling published — it is a value I divided out myself. Kling's price sheet has only the two left columns. This distinction matters because for the per-second conversion to hold, you have to ignore the fact that there are only two points, 5s and 10s. You cannot make a 7-second video on Kling. You make 10 seconds and cut it, and then you pay the 10-second rate. This is a fundamentally different billing model from Sora, which specifies length by the second and bills by the second.

There is one more thing to read off the table. pro x 5s is $0.35 without audio and $0.70 with audio on — exactly 2x. With Kling, audio is optional and doubles the price, whereas with Veo audio is included by default and the price sheet literally reads "video with audio price (default)." If you also need audio, the right comparison is Veo 3.1 Fast 720p ($0.10 per second, audio included) versus Kling-V2-6 pro + audio ($0.14 per second equivalent). If you do not need audio, Kling-V2-6 std ($0.042 per second equivalent) is the cheapest on this table.

There is an exception too. On Kling's price sheet, only Kling-Video-O1 and Motion Control bill by the second.

The "$0.084–$0.168" floating around in search results appears to come from here. Except that is Kling-Video-O1's price, not Kling's general image-to-video price.

Finally, one structural difference. The Kling API works on a prepaid resource pack model. The price sheet has a separate points column called "Resource Pack Unit Deduction," and actual billing happens by deducting points. Cross-check the points against dollars and, for video models, one point consistently comes out to $0.14 (std 5s = 1.5 points = $0.21, pro 10s + audio + voice control = 12 points = $1.68 — divide either and you get $0.14). The arithmetic lines up. But unlike OpenAI and Google, where you pay after the fact for what you used, you have to buy a pack ahead of time — which, from a procurement standpoint, is a different story.

The Constraints That Actually Bite When You Feed an Image

This is where the image-to-video minefield is. Constraints invisible when you feed only text jump out the moment you feed an image.

Sora: input images with human faces are rejected. Copying the Guardrails section of OpenAI's docs verbatim, it reads:

Only content suitable for audiences under 18 (a setting to bypass this
restriction will be available in the future). Copyrighted characters and
copyrighted music will be rejected. Real people—including public figures—
cannot be generated. Character uploads that depict human likeness are
blocked by default. Input images with faces of humans are currently rejected.

The last sentence is the key one — "Input images with faces of humans are currently rejected." If your use case is animating a photo of a person, Sora is simply out of the running. The word "currently" is attached, so it may be lifted later, but if the docs say "currently rejected," then as of today it is rejected. This is not a failure-rate problem; it is a missing-feature problem.

The rest of Sora's image-related spec is this. Feed an image via input_reference and it becomes the first frame of the video. Length can go up to 20 seconds, and via extension you can stitch on up to 20 seconds at a time, up to 6 times, reaching a total of 120 seconds. The docs do warn about latency, however — "Longer durations and 1080p jobs can take materially longer to complete" — and note that "a single render may take several minutes." For reference, the old remix endpoint is being retired, and the guidance for new integrations is to use edits.

Veo: feed an image and the length may be locked to 8 seconds. Google's docs describe the durationSeconds parameter like this — the value is one of "4", "6", "8", but it must be "8" when you use extension, a reference image, 1080p, or 4k. The very sentence introducing Veo 3.1 reads "Veo 3.1 is a model for generating 8-second videos (720p, 1080p, or 4k) with natively generated audio." In other words, any plan to cheaply pull a short 4-second clip out of Veo collapses the moment you use a reference image. Aspect ratio is only "16:9" (default) and "9:16".

Veo's image input comes in two flavors. One is image-to-video, which in the docs' words is "Veo uses the input image as the initial frame" — the same first-frame approach as Sora. The other is reference images, where Veo 3.1 takes up to 3 to keep the appearance of a person, character, or product consistent. The latter is what runs into the 8-second lock mentioned above.

Veo: the person-generation option changes depending on the input method. The personGeneration parameter allows only allow_all in text-to-video, but only allow_adult in image-to-video, interpolation, and reference images. There is a regional restriction too — the docs say that "In EU, UK, CH, MENA locations," Veo 3 and 3.1 allow only allow_adult. South Korea is not on this list.

Veo: generated videos disappear from the server after 2 days. This is an easy-to-miss operational trap. Verbatim from the docs: "Generated videos are stored on the server for 2 days, after which they are removed. To save a local copy, you must download your video within 2 days of generation." If you do not put a download step in your pipeline, you lose your output. And videos Veo makes carry a SynthID watermark. This is not optional.

To summarize:

The cells marked "couldn't confirm" do not mean the feature is absent; they mean I did not find that item within the range of official docs I checked. Writing something absent as present is a wrong answer, and so is pretending to know what you don't — so I leave the blanks blank.

Do the Open Weights Actually Run on My GPU?

Now the other side. Here there are exactly two questions — does it fit on my card, and how long does it take.

Wan2.2 (Alibaba). The numbers the repository README gives are these.

What this table says is clear. The only one you can actually run on a consumer card is TI2V-5B. The A14B family demands 80GB on a single GPU, so on an RTX 4090 (24GB) you cannot even start. And even TI2V-5B's 24GB is the number with all three offloading options turned on. The README advises that with 80GB or more you should drop those options to raise speed.

What about speed? Copying the README's sentence verbatim: "Without specific optimization, TI2V-5B can generate a 5-second 720P video in under 9 minutes on a single consumer-grade GPU." Nine minutes for a 5-second video. This is Alibaba's own measurement, and it carries the condition "without specific optimization." Which card is not specified in this sentence (it only says "consumer-grade GPU").

An honest note here. The Wan2.2 README has a "Computational Efficiency on Different GPUs" table with per-GPU generation times and peak memory, but that table is posted as an image file. It is a PNG, not text. So I did not quote the numbers in that table here. Better to leave them out than to transcribe machine-unreadable values and get them wrong. Instead I used only the "9 minutes," "24GB," and "80GB" written as text in the README body.

On structure, just briefly: A14B is an MoE — split into a high-noise expert and a low-noise expert, each about 14B, 27B combined, with 14B active per step. TI2V-5B is a plain dense model, but the Wan2.2-VAE has a compression ratio of 4x16x16, reaching a total compression of 64, and with patchification added it becomes 4x32x32. That compression ratio is the basis for being able to pull 720P at 24fps.

HunyuanVideo-1.5 (Tencent). This is the newest line, released November 21, 2025. The repository README's numbers are these.

• 8.3B parameters — DiT + 3D causal VAE, 16x spatial / 4x temporal compression
• Minimum GPU memory 14GB (measured with model offloading on). The README notes this value assumes offloading, and says that if you have enough memory you should turn offloading off to raise speed
• Resolutions are 480p and 720p; 1080p is upscaled by a separate super-resolution network
• Default length is --video_length 121 frames, and since the example code saves at 24fps, that is about 5 seconds
• The 480p I2V step-distilled model released December 5, 2025 runs in 8–12 steps, and by Tencent's measurement "On RTX 4090, end-to-end generation time is reduced by 75%, and a single RTX 4090 can generate videos within 75 seconds"

The last line stands out. 75 seconds on an RTX 4090. You will want to compare that to Wan2.2 TI2V-5B's "9 minutes," but you have to stop right here. The two numbers are not comparable. Hunyuan's 75 seconds is measured at 480p, with the step-distilled model (8–12 steps), on a specified RTX 4090. Wan's 9 minutes is at 720p, no distillation, on a card described only as "consumer-grade GPU." The resolution differs, the step count differs, and whether the card is named differs. Each measured a value on its own repo under conditions favorable to itself, and no common benchmark exists. Putting the two vendors' own measurements side by side and writing "Hunyuan is 7x faster" is just wrong arithmetic.

The Hunyuan README also makes a claim about SSTA (Selective and Sliding Tile Attention) — a 1.87x end-to-end speedup over FlashAttention-3 on 10-second 720p synthesis. This is a comparison between attention implementations, and it is the authors' own measurement. It is not a comparison against another model.

Licensing — If You're Reading from South Korea, This Section Changes the Conclusion

I've dragged the performance discussion this far, but for a South Korean user this one section matters more than all the tables above.

HunyuanVideo, HunyuanVideo-I2V, HunyuanVideo-1.5 — the license documents of all three repositories begin with the same sentence.

TENCENT HUNYUAN COMMUNITY LICENSE AGREEMENT
Tencent HunyuanVideo 1.5 Release Date: November 21, 2025
THIS LICENSE AGREEMENT DOES NOT APPLY IN THE EUROPEAN UNION, UNITED
KINGDOM AND SOUTH KOREA AND IS EXPRESSLY LIMITED TO THE TERRITORY, AS
DEFINED BELOW.

And the definitions section defines "Territory" like this.

l. "Territory" shall mean the worldwide territory, excluding the territory
   of the European Union, United Kingdom and South Korea.

That is, South Korea is left out of the territory the license permits. And clause 5 (c) nails down the meaning of this exclusion.

c. You must not use, reproduce, modify, distribute, or display the Tencent
   Hunyuan Works, Output or results of the Tencent Hunyuan Works outside
   the Territory. Any such use outside the Territory is unlicensed and
   unauthorized under this Agreement.

The part to read is "Output or results." It is written that not only downloading and using the weights but also the videos you produce with them cannot be used outside the permitted territory. On top of that, an operator exceeding 100 million monthly active users must request a separate license from Tencent (and Tencent may refuse at its discretion), and the governing law is that of the Hong Kong Special Administrative Region.

By contrast, Wan2.2 is Apache 2.0. This is confirmed independently in three places.

The Hugging Face check matters for a reason. The code license and the weights license can differ. The repository being Apache while the weights carry separate terms is common. Wan2.2's Wan-AI/Wan2.2-TI2V-5B and Wan-AI/Wan2.2-I2V-A14B model cards are both apache-2.0, so it does not have that trap.

There is an interesting contrast here. The same Tencent used Apache 2.0 when it released Hy3 — with no regional restriction and no field-of-use restriction. In other words, this is not a "because it's a Chinese vendor" problem but a per-model-line policy problem. The same company releases its language model under Apache and puts a regional restriction on its video model. This is why you cannot guess a license from the vendor's name alone.

Two things I'll make clear. First, I am not a lawyer and this is not legal advice. The quotations above are the original text of documents Tencent posted to its own repositories, and all I did was find them and copy them. Second, how this clause is actually interpreted and enforced in South Korea cannot be known from the docs alone. What I can say stops exactly here — Tencent's distributed license document explicitly excludes South Korea from the permitted territory, and if your company plans to use this model, it is not a sentence to wave past without legal review. An individual experimenting locally and putting it into a product are different matters, and this post cannot make that judgment for you.

What You Can and Can't Measure from a Demo Reel

Time to explain why this post has no image-quality comparison.

Each vendor's project page has a slick demo video. Wan2.2 touts "cinematic-level aesthetics," Kling calls its own model the "master" tier, and HunyuanVideo-1.5 writes "state-of-the-art among open-source models." What can be said honestly about these phrases is this — that demo reel is marketing, and you cannot get a measurable value out of it. It is a result from a prompt the vendor chose, a seed the vendor chose, and an unknown number of runs the vendor picked from. Failed generations do not make it into the reel.

So the values this post did and did not cover split like this.

Measurable and verifiable — price per second (written as a number on the vendor price sheet), maximum and permitted length values (API parameter specs), VRAM floor (written as a number in the README), license clauses (original document text), output retention period (stated in the docs), presence of a watermark (stated in the docs). These are not up for debate. Open the page and it either says so or it does not.

Vendor's own measurements, to be read together with their conditions — Wan's "9 minutes," Hunyuan's "75 seconds" and "1.87x." All are values each measured on its own repo under its own conditions, and because the conditions differ, no cross-comparison holds. This is why this post places these numbers side by side but does no subtraction or division on them.

Not measurable at all — "which model has better image quality." Every answer the vendor docs give to that question is self-promotion, and no independent benchmark comparing the five models under common conditions exists within the range I checked. So this post does not answer that question. Writing "no such figures have ever been published" is more accurate than inventing an answer.

The practical conclusion this implies is simple. You have to test image quality yourself. With your actual input images and your actual prompts. Fortunately this can be done cheaply — one 5-second video at sora-2 720p is $0.50, and Kling-V2-6 std 5 seconds is $0.21. Run ten of each and it is the price of a cup of coffee. Licensing and VRAM, by contrast, are not things you can find out by testing, which is why this post spent its page count on those.

So, What Do You Pick?

Boiled down to decision rules, it goes like this. Just come down them in order.

1. Is there a human face in the input image? If yes, Sora is out. The docs say it is currently rejected. Go with Veo, setting personGeneration to allow_adult.

2. Are you putting open weights into a product in South Korea? If so, Wan2.2. The HunyuanVideo family's license document excludes South Korea from the permitted territory, and it states that the exclusion reaches the output too. Apache 2.0's Wan2.2 does not have that problem.

3. Is your GPU 24GB or 80GB? With 24GB (RTX 4090 class), your options are effectively Wan2.2 TI2V-5B (720p, 9 minutes for 5 seconds) or HunyuanVideo-1.5 (min 14GB, 75 seconds on a 4090 with the 480p distilled model). Wan's A14B family starts at 80GB. If your GPU can't run open weights at all, item 2 is automatically moot.

4. Do you need audio? If you do, Veo 3.1 is the simplest — it is included in the price, and Fast 720p is $0.10 per second. Kling charges 2x when you turn audio on ($0.35 → $0.70 for pro 5 seconds).

5. Do you need free choice of length? If you need arbitrary lengths like 7 or 13 seconds, it's Sora (specify by the second, up to 20 seconds, 120 seconds via extension). Veo is only 4/6/8 seconds and locks to 8 seconds if you use a reference image. Kling has only two points, 5 and 10 seconds.

6. Can you run it in batch? If so, sora-2 batch at $0.05 per second at 720p is, among the per-second billing options, the cheapest along with Veo 3.1 Lite ($0.05 per second, but audio included). That said, if you are fine with 5- or 10-second lengths, a Kling-V2-6 std 5-second clip is $0.21 — lower at a $0.042-per-second conversion. Keep in mind that lining up clip-based billing and per-second billing on a single line was never a valid comparison to begin with.

I'll also note when not to use each.

• Setting up open weights just to make a handful of videos is almost always a loss. Factor in the cost of renting a GPU and the setup time, and up to dozens of 5-second clips, hosted is overwhelmingly cheaper. Open weights earn their keep when volume is large, when you can't send data out, or when you need fine-tuning.
• Don't use Veo without putting a download step in your pipeline. It disappears from the server after 2 days.
• If a watermark is a problem for your use case, drop Veo from the running. SynthID is not an opt-in item.
• Don't quote a reseller's price sheet as Kling's official price. As we saw, numbers that are not on Kling's official page float around search results as if they were fact.

Closing

What actually decides an image-to-video model choice was not the image quality of the demo reel. Open the vendor docs and check directly, and the decisive things are three — the structure of per-second pricing (Sora and Veo bill by the second, Kling by 5- and 10-second clips), the constraints that bite the moment you feed an image (Sora's face rejection, Veo's 8-second lock and 2-day retention and SynthID), and licensing (Wan2.2 is Apache 2.0; the HunyuanVideo family excludes South Korea from the permitted territory).

Of those, the cheapest advice for someone reading from South Korea is still the one in the first paragraph. If you are going to put open weights into a product, open the LICENSE file before you look at benchmarks. That 30-second step beats spending weeks comparing the performance of Wan2.2 and HunyuanVideo-1.5 only to then read the license's first line. And that first line is not the same just because it's a different model from the same company — as when Tencent released its language model under Apache and put a regional restriction on its video model.

The rest — which model has better image quality — cannot be answered for you by anyone, because there is no common benchmark. But that too is something you can check for yourself today with ten of your own images and a few dollars. Licensing and VRAM are not.

References

• OpenAI API Pricing — per-second price table for video-generation models (sora-2, sora-2-pro, standard/batch)
• OpenAI — Video generation guide (input_reference, seconds, extension, Guardrails)
• Gemini API Pricing — Veo 3.1 / Veo 3 / Veo 2 per-second prices and deprecation notice
• Gemini API — Veo docs (durationSeconds, personGeneration, reference images, 2-day retention, SynthID)
• Kling AI Developer — API pricing page (Kling-V2-6, Kling-Video-O1, resource-pack points)
• Wan-Video/Wan2.2 — repository README (TI2V-5B 24GB / A14B 80GB, 5-second 720P in 9 minutes, MoE structure)
• Wan-Video/Wan2.2 — LICENSE.txt (Apache License 2.0)
• Wan-AI/Wan2.2-TI2V-5B — Hugging Face model card (weights license apache-2.0)
• Tencent-Hunyuan/HunyuanVideo-1.5 — repository README (8.3B, min 14GB, RTX 4090 75s distilled model, SSTA)
• Tencent-Hunyuan/HunyuanVideo-1.5 — LICENSE (Tencent Hunyuan Community License, Territory definition)
• Tencent-Hunyuan/HunyuanVideo — LICENSE.txt (same territorial exclusion clause)
• tencent/HunyuanVideo-1.5 — Hugging Face model card (license: other, tencent-hunyuan-community)
• Tencent Hy3 — a case where the same company released its language model under Apache 2.0 (related post)
• Analysis of SOTA Video Generation Models — DiT/3D VAE architecture (related post)