Most discussions of AI video compare models by duration — five seconds, ten, thirty. For anyone shipping a product on top of them, duration is the least interesting axis. A long clip is harder to generate. A short clip is harder to ship, because every weakness gets amplified: one identity drift is the whole video, one desync is the whole punchline, and one failed retry can cost more than the output is worth.
These are the constraints we keep running into while building Hookai, which turns one photo — or two, for a duo — into a five-to-fifteen second vertical rap video with vocals and a beat.
1. Identity has to survive a frame with two faces
Single-subject image-to-video is a solved-enough problem in 2026. Two subjects in one shot is not. The moment two faces share the frame, the model has to hold both identities stable while also rendering contact between them — a handshake, a shoulder, a hug — and contact is exactly where occlusion destroys identity. Bodies interpenetrate, a jaw gets redrawn, and the person on the left quietly turns into someone else by frame 40.
The workaround that costs nothing in quality is to stop asking the model to improvise. Lock the cast to the reference photos for the whole render, and let the scene absorb the variation instead. A fixed set — a hotel lobby, a stage — is not a creative limitation, it is a consistency device: if the background is constant, the only variable left to drift is the one you are trying to protect.
2. Audio bolted on afterwards always needs alignment
There are two architectures for a music video, and they fail in different places.
The first generates footage, then attaches a finished song. It is cheap and works with any track, but someone has to force-align the mouth to the audio. That alignment degrades exactly where short-form video lives: fast head movement, profile angles, two performers overlapping. The second generates the performance and the audio together, so timing is a constraint during generation rather than a cleanup step afterwards.
We took the second path — vocals and beat are generated as part of the clip, not dubbed onto it. The tradeoff is real and we accept it: you cannot import an arbitrary MP3. Lyrics paste and track upload are both on the roadmap and neither is shipped, and we would rather say that on the homepage than let people find out after paying.
3. The retry is the product
At five to fifteen seconds, a video is cheap enough that users expect several attempts. That makes retry cost the actual unit economics, and the credit system should be read as a retry budget rather than a price list. The same ten-second 720p render costs roughly $1.70 to $9.00 depending on how credits were bought — a spread of more than 5×, and that single number is what decides your retry policy.
Two consequences follow. First, at the top of that range a 30% miss rate is unshippable, so failed jobs have to be refunded at the queue layer and not negotiated in support tickets. Second, first-try success rate has to be visible before the user pays — which is why finished samples are free to watch and only real renders need an account.
4. Gate the input before you spend the render
A failed render is expensive in a way a rejected upload is not. Rejection costs a few milliseconds of detection; a failed generation costs credits, queue time, and a support thread. So the admission check belongs on the server, before a job is queued, not in the browser where it can be skipped:
The thresholds are not industry constants; they are the values where our own outputs stop being reliable. What matters architecturally is where the check sits. Front-end validation is advice. Backend admission is a guarantee — and it is the only version that protects your compute bill from a client that was never updated.
5. Only expose the tiers you can actually deliver
Every resolution tier is a support burden as well as a compute bill. Aspect ratios are trivial switches; resolutions are not. We ship 480p because iteration should be cheap and 720p because that is what survives re-encoding on social platforms, and we have not shipped 1080p because a resolution tier nobody can render reliably is worse than a missing one. The same logic applies to the model selector: fast and standard are defaults, pro and ultra exist for people who already know what they want.
6. If you are building a photo-to-video pipeline
- Reject unusable inputs server-side, before queueing. Detection is cheap; retries are not.
- Lock the cast per project, not per render, or consistency becomes a QA job instead of a product feature.
- Keep one template parameter fixed while you are still measuring identity drift; two variables at once makes failures unreadable.
- Refund failed jobs automatically in the queue. It is the cheapest trust you will ever buy.
- Expose only the tiers you can render reliably — a disabled button reads as a roadmap, a broken one reads as a scam.
FAQ
Do I need two photos? One is enough for a solo video. Two switches it to a duo performance.
Can I use my own song? Not yet. Audio is generated with the clip; track import is planned.
How long is a video? 5 to 15 seconds, vertical by default, no watermark on paid renders.
Short-form is not the low-effort end of AI video. It is the end where identity, audio and retry cost all land at once, with no room to hide behind a long timeline. If you want to see how these constraints behave in practice, you can turn one photo into a short rap video and judge the sync yourself — a fifteen-second clip is a fair sample of a pipeline's honesty.
