A 56-second film from an eight-second model

The problem

Veo generates a maximum of eight seconds from scratch. The film I needed was about fifty: fifteen lines of dialogue, a character, a robot, one room, a punchline at the end. Every approach to that gap looks the same at first — make a piece, use its ending to make the next piece, repeat.

That instinct is wrong, and it took three attempts and $26 to find out why. The short answer is that chaining does not just fail to fix errors; it manufactures them. Each link copies the previous output, so a defect that enters once is then reproduced faithfully forever, because by the second link it is no longer a defect — it is the source.

What worked instead was giving up continuity between segments and buying identity with it.

The two limits you are actually working against

Generation from scratch stops at eight seconds. No parameter asks for more.

extend stops at 37. Google’s Extend videos page, as of 3 September 2026: the input clip must be between 1 and 30 seconds, each extension adds exactly seven seconds, and a Veo video can be extended to 37 seconds total. Extension also routes through Cloud Storage rather than returning bytes.

Fifteen lines is 93 words. The opening alone spends eight seconds on ten of them, because a board has to fall over and break. That leaves 28 seconds for 83 words plus the whole cleanup. A film that breathes needs 45 to 50. It does not fit in one returned file, and no flag changes that.

Attempt one: the extend chain

Delivered 36.148 seconds, byte for byte the file Veo returned, nothing joined locally.

It reads well for about twenty seconds and then visibly decays:

• The frame tightens on its own. It opens on a full body with the shoes in frame and by around second 29 sits in a much closer shot. Every instruction in the chain asked for a locked camera on a tripod.
• The face drifts. From about second 19 the eyes go narrow and drooping instead of the large round eyes in the reference.
• The robot grows a mouth. The reference has none.
• The brightness climbs one step per extension, and the joins read as hard cuts, because each extension reseats the framing.
• The last second is the worst frame in the film — face smeared, eyes deformed, outline falling apart.

Measured either side of the joins, the clean threshold of an extend chain is about two extensions — roughly 22 seconds, which is exactly where it stops looking deliberate.

The mechanism matters more than the list. Every extension’s input is the previous output. Errors do not average out across a chain; they compound, because each one is re-observed as ground truth by the next call.

Attempt two: chaining last frames by hand

You can do the same thing without extend. instances[0].lastFrame works — sent as bytesBase64Encoded, a sibling of prompt and image inside instances[0]. Each segment’s final frame becomes the next segment’s first frame, generated fresh at eight seconds a piece.

This got to 53.27 seconds and it is better. It also still creeps. From segment 3 onward each segment adds a small push-in, and because each starts from the last frame of the one before, the push-ins add up. I tried four variants of segment 3 to stop it — with a target plate, without, at six seconds, at eight, with camera language and without — and stopped when it became clear more attempts would eat the ending’s budget. I did not eliminate it.

One result from that attempt is worth more than the attempt itself, because it is the opposite of what I expected:

Using lastFrame on continuation segments made continuity worse, not better.

The target plate for segment 2’s ending was drawn from the preceding frame, but came out at a different scale and framing. Veo then did exactly its job and interpolated toward it — producing a camera push-in and a robot that grows relative to the human. Background correlation fell to 0.14. The same generation with no lastFrame, and the locked-camera instruction written out explicitly instead, gave 0.96–0.99.

So lastFrame earns its place only where the final state has to be commanded and cannot be obtained another way. Here that was segment 1 only: first frame the printed slide filling the screen, last frame a drawn plate of the room, so the room is revealed behind the board as it falls. It landed on the plate almost exactly. Everywhere else it was a liability.

The thing I could not see: Veo was cropping my references

Before the third attempt I checked something I had assumed for two days.

Veo crops every reference image to the output aspect ratio, without warning. The character sheet was 1122x1402. At 9:16 output it lost 29.7% of its width, and the front view arrived as half a figure. The robot plate was 1956x900 — it lost 74.1%.

The model was never seeing what I sent. Every judgement I had made about “the model can’t hold this character” was made against material the model had never received.

The fix is not clever: redraw each plate as a single clean view at exactly the output size, 1080x1920. One subject per plate, no sheets, no multi-view turnarounds. If your reference is not already the target ratio, assume it is being cut and check before you conclude anything about the model.

Attempt three: re-anchor every segment to the same plates

Delivered 56.02 seconds, all fifteen lines in order each said once, punchline and sign-off intact — the parts the earlier 36-second cut had lost.

Two changes, both measured before being relied on:

1. Plates redrawn at the output size, per the crop above.

2. Every segment starts from the plates, not from the previous segment’s last frame. All seven segments receive the same three references — person, robot, room. Identity comes from the source every time, instead of copying forward whatever the previous generation happened to get wrong. Nothing degrades, because nothing accumulates.

The segments were then generated in one parallel wave rather than one after another, which is only possible because none of them depends on another’s output. The dependency was the reason the old method was slow, not the model.

Checked afterwards: the same character across all seven segments — same large round eyes with navy irises, same proportions, the snowflake on the chest. Background correlation within each segment, measured on three regions of the upper third, 0.98–0.99.

What re-anchoring costs you

It is a trade, not a free win, and the bill is real:

Reference mode carries no camera position. So the framing differs from segment to segment. Each shot picks its own distance. The result reads as an edit with cuts — ordinary film grammar, and nobody complained — but there is no constant wide shot, and you cannot ask for one this way.

That is the whole choice, stated plainly: chaining gives you continuity and compounding error. Re-anchoring gives you identity and cuts. For a talking short, identity was worth more. For a continuous action shot it would not be.

Two faults worth naming, one fixable

Invented subtitles burned into the picture. Segment 6’s first take came back with subtitles across its whole duration reading “Shouct orst therce mer…”, plus a deformed robot. The fix is Vertex’s own documented advice for exactly this: write dialogue with a colon and no quotation marks. Snowey says: it doesn't work, not Snowey says "it doesn't work". After the change, no letter appears in any frame of the finished film.

Filler noises between lines, and this one does not have a fix. The transcript finds “Oh.” at 18, 21, 29 and 35 seconds, and “No.” and “Hmm.” at 35–36. None are in the script. Veo runs a prompt rewriter that, in Google’s words, adds “transcription and sound effects”, and it cannot be disabled on Veo 3.x. Budget for it, or plan a track that covers it.

Two smaller ones from the chained attempts, kept because they name a pattern: a blue crystal appeared on the monitor from segment 4 and stayed for the rest of the film, and the robot both grew a mouth and started making vocal sounds. Those two are one defect, not two — Veo gives the voice to whoever’s mouth moves. If a character must stay silent, say that its face has no mouth, in the prompt, every time.

What it cost

attempt	delivered	spend
extend chain	36.148 s, decayed after ~22 s	$2.04
last-frame chain	53.27 s, camera creep unresolved	$15.08
re-anchored to plates	56.02 s, complete	$9.04

The working recipe was $9.04 of $10 authorised — $8.64 on video (nine eight-second generations, of which two were rejected) and $0.40 on the two redrawn plates.

It is also the cheapest of the three, and that is not a coincidence. Most of the money in the first two attempts went on regenerating segments to undo damage that the method itself had introduced.

Every call reserved its cost against the cap before it was made, and the ledger records each one with its operation ID. A budget you check after the fact is not a budget.

What is still open, and what I am trying about it

The film is delivered, not finished. Four things are still wrong with it. Two have a candidate fix I have not paid for yet, one has no fix I know of, and one needs a person.

Framing that differs between segments — candidate fix, untested. Reference mode carries no camera position, so each shot picks its own distance. The thing worth trying is the technique that already worked inside a segment: describing the shot in words instead of handing the model a target image. That is exactly the swap that took background correlation from 0.14 to 0.96–0.99 in attempt two. Whether the same wording holds a consistent distance across independent generations is untested, and I would not assume it does — nothing ties two separate calls together.

The robot does not wave at the end — candidate fix, untested. The take that had the wave also had a video-player interface bar drawn along the bottom of the frame. I kept the clean frame and lost the wave. The obvious next move is to put that bar in the negative prompt and re-run the one segment, at about $0.96 for eight seconds. It was not run because the budget was gone, not because it was ruled out.

Debris that stops reading as pieces of a printed board — candidate fix, untested. The board breaks correctly in the opening. By mid-film the pieces on the floor look more like paper. The fix that worked once already was naming the physics in the prompt: saying that everything printed is flat ink on a rigid plate is what stopped the model treating the cards drawn on the board as separate objects that fly off. Naming the debris the same way in each continuing segment is the thing to try.

Filler noises — no fix known. “Oh.”, “No.”, “Hmm.”, none of them in the script. Veo’s prompt rewriter adds them and cannot be disabled on Veo 3.x. Every workaround I can think of covers the symptom rather than removing it: a music bed, or a track laid over the top. That changes what you are delivering instead of fixing what came back. If someone has actually suppressed these on 3.x, I would like to know how.

And the open question behind all of it: the per-second bill. At roughly $0.12 a second, this 56-second film cost $9.04, and every re-run of any segment costs the same again — which is precisely why three of the four faults above are still sitting there unfixed. That is not a viable loop for making video regularly.

So the direction I am testing next is not a better prompt. Watching animated storytime videos frame by frame, the background in the strongest one does not move by a single pixel across five seconds; the only thing that changes is the character — arms, head, mouth, pose. That is not frame-by-frame animation. It is a cut-up character rotated at the joints over a still background, and once the parts are drawn it costs nothing per render, forever.

Whether our character survives being cut into separable parts is genuinely unknown. The requirement is brutal and specific: every arm needs a continuous line of background between it and the torso along its whole length, because a single touching pixel welds the arm to the body and there is nothing to rotate. Nothing here is proven yet — when it is, or when it fails, that will be its own post.

What is not proven

• How the domain is pronounced at the end is UNVERIFIED. Three separate transcriptions wrote it “snowaylabs”, “snowylabs” and “snoweylabs”. I cannot listen to audio; a person has to.
• The camera creep in attempt one was never given a number. The finding is visual, on stills. The 0.14 / 0.96–0.99 correlations quoted above are from attempt two, where I could measure.
• Re-anchoring was tested on one film: seven segments, one character, one robot, one room, 9:16. I do not know where it stops holding — more characters, more locations, or a shot that genuinely has to move through space are all untested.
• Nothing here was published to any platform. The measurements are from local files.