A ten-second scene history is not the same thing as a ten-second reference upload. If you are building a video editor around Gemini Omni 1.1 Flash, keep those two input routes separate in both the interface and the request validation.
In its August 27 announcement, Google describes two different controls:
| Creative task | What the article says | What not to infer |
|---|---|---|
| Continue an existing scene | Scene extension can analyze up to 10 seconds of prior context. The API example passes previous_interaction_id=previous_video_interaction.id. |
This does not establish a ten-second reference-upload allowance. |
| Use video as multimodal reference material | You can reference up to three seconds of video when crafting a scene. | This is not the same mechanism as continuing the prior interaction. |
The distinction matters for a shot such as a dancer turning toward the camera. Continuing the existing shot and using a short turn as motion reference for a new composition are different creative intentions. A single “video context length” control would blur that distinction.
A practical editor design
My recommendation is to expose two explicit actions:
- Extend this scene: retain the prior interaction identity and let the user describe what happens next. Label the ten-second figure as the article’s prior-context window, not as an upload limit or a promise that every earlier detail will survive.
- Use a video reference: let the user select the short motion segment they intend to carry into a new scene. Show the selected interval before submission rather than silently trimming a longer upload; trimming could remove the turn or pose that motivated the reference.
The announcement is not a complete upload specification. In particular, its three-second wording does not settle per-file versus aggregate duration handling for multiple references. Confirm the current endpoint documentation and payload schema before encoding that rule. Do not turn an ambiguous announcement sentence into a universal file validator.
Test the route before judging the picture
For an integration test plan, separate request handling from creative evaluation:
- Confirm that the extension action retains the intended prior interaction, while the reference action sends the deliberately selected reference material. Do not assume the two payloads are interchangeable.
- Once the documented reference-duration rule is resolved, test inputs just below, at, and above that boundary. Record acceptance or rejection without treating the ten-second extension window as the reference limit.
- Evaluate the resulting clips separately: check motion direction, pose and framing for reference-conditioned scenes; check those details across the join for extensions. A request being accepted would not prove visual continuity.
These are proposed checks, not reported API results. The source supports a useful design boundary—extension history and uploaded reference duration need separate controls—but it does not prove how a particular endpoint will reject an oversized upload or how faithfully any generated shot will preserve its reference.