Input video must be a video that was generated by VEO that has been processed. — Veo API video extension error
The exact error
Input video must be a video that was generated by VEO that has been processed.
What it means
You asked Veo to extend a video, and the Gemini API did not accept the input video as one of its own recent generations.
Google’s Veo docs set the rules for extension on the Gemini API:
- “Gemini API only supports video extensions for Veo-generated videos.” The video should come from a previous generation, such as
operation.response.generated_videos[0].video. - Generated videos are stored for 2 days. Referencing a video for extension resets that timer, and you can only extend videos generated or referenced in the last two days.
- Input videos must be 720p, 9:16 or 16:9, and 141 seconds or less. Each extension adds 7 seconds, up to 20 times.
- Extension is available for Veo 3.1 and Veo 3.1 Fast, not Veo 3.1 Lite.
The error has come up in three situations:
- Downloaded and re-uploaded. In forum thread 113599, a developer saved a Veo output to Cloud Storage, uploaded it again through the Files API, and passed that file’s URI. They got this 400. A reply from a Google-affiliated forum member repeated the docs rule above: pass the original generation result. The developer then asked whether extension is impossible after the 2-day retention window. That question got no answer.
- Raw video bytes. In js-genai issue #1059, a js-genai contributor explained that the Gemini API only allows extension of previously generated videos, and that uploaded bytes were not accepted for it at the time. They pointed to the Vertex AI backend for extending arbitrary videos.
- A long chain of extensions. In forum thread 135652, a developer extended a video segment by segment in a loop. It worked for a few rounds, then failed with this message on a later segment, even though they passed the previous generation’s result each time. That thread has no resolution.
Merged variant: the aspect ratio message
A related 400 INVALID_ARGUMENT reads Aspect ratio of the input video must be 16:9, but got: 9:16. In js-genai issue #1176, a user got it when extending a 9:16 video that Veo 3.1 had generated. Google’s docs say 9:16 is supported for extension. A js-genai contributor replied that the extension call’s config omitted aspectRatio, and that adding aspectRatio: "9:16" fixed it in their reproduction. The issue was then closed as stale.
How to confirm it’s this
- The call is an extension: the request carries a
videoinput. - Trace where that video came from. If it went out to your storage, a download or the Files API and came back in, that matches the failing report in thread 113599.
- Check the age of the source generation. If more than 2 days have passed since it was generated or last referenced, the docs say it can no longer be extended.
- Check the documented limits: 720p, 141 seconds or less, no more than 20 extensions, and a model that supports extension.
- For the aspect ratio variant, compare the
aspectRatioin your extension config with the source video.
Fix
- Pass the generation result, not a copy. In the SDKs, use the
videoobject from the previous operation’s response. Google’s REST example sendsinstances[0].videoasinlineDataholding base64 data “from a previous generation.” It does not say how that base64 is obtained, so prefer the SDK route of passing the response object, which is what the replies in thread 113599 and issue #1059 pointed to. - Extend within 2 days. If your pipeline waits for approval before extending, schedule the extension inside the retention window. Each extension resets the timer, and the docs say extended videos count as newly generated.
- Keep your own copy separately. Download for storage, but do not feed that copy back into extension on the Gemini API.
- Set
aspectRatioto match a portrait source when extending 9:16 videos. - For videos Veo did not generate on this API, the js-genai contributor pointed to Vertex AI. That is a different backend with Google Cloud project auth, so check its own docs first.
Retry or not
No. The rejection is about the input video itself, so an identical request with the same video fails the same way. Once a video has aged out of the 2-day window, no retry will bring it back, so an agent should fail fast and regenerate. For the chained-extension case in thread 135652, no cause has been confirmed, and there is no documented reason to expect a retry to succeed.
When it’s not this
`fileUri` isn't supported by this model.You sent the video by reference in a shape the Gemini API does not accept. That message is about the request shape, not the video’s origin.video parameter is not supported in Gemini API.A different message, from js-genai issue #1059. A contributor could not reproduce it on SDK v1.28.0 and asked the reporter to try the latest version.- Audio or safety blocks on the extended output. Those come back after the job runs.
Related errors
- fileUri isn’t supported by this model
- last_frame parameter is not supported in Gemini API
- Use case not supported
- Veo audio issue
- Veo videos filtered out
Error text last verified against the sources below on .