gemini-omni-1.2-flash in practice: 3 video generation business scenarios and a go-live checklist

First confirm the input form and parameter boundaries

The publicly available model currently integrated by HiAPI, gemini-omni-1.2-flash, outputs video and offers four generation modes: text-to-video, first-frame image-to-video, first-and-last-frame transition, and reference-image-to-video. Before writing code, deciding "what am I feeding it this time" is more effective than picking the scenario first.

Capabilities that are currently not available include: video editing, video extension, video or audio as input, and the seed parameter. Workflows that depend on these capabilities cannot be implemented with this model.

Request parameters

• prompt: the only required field; must be a non-empty string with a maximum of 20000 characters.
• duration: integer, values 3–15 seconds, default 10 seconds.
• resolution: 360p / 720p / 1080p / 4k, default 720p. 1080p and 4k are upscaled outputs; 4k may contain no audio track.
• aspect_ratio: 16:9 or 9:16, default 16:9.

Image parameters and mutual exclusion

• image_urls: 1–10 publicly accessible HTTP(S) reference images, which uses reference-image-to-video. Passing only one image still means reference-image mode; it does not automatically become first-frame mode.
• first_frame_url: specifies the starting frame and can be used alone to form first-frame image-to-video.
• last_frame_url: must be used together with first_frame_url to form a first-and-last-frame transition. First-and-last-frame mode is capped at 10 seconds, and the request must not include negative_prompt or system_prompt.
• image_urls is mutually exclusive with first_frame_url and last_frame_url; only one of these modes can be chosen per request.
• All image parameters accept only publicly accessible HTTP(S) URLs; Base64 is not supported.

Expectations to establish in advance: there is no guarantee that every mode includes sound, lip sync, or accurate text, nor that the subject or brand in the generated result will exactly match the reference. All of these require human review.

Cost basis: per-second pricing tiered by resolution

This model is billed by request duration, with unit prices tiered by resolution. The current prices under the default multiplier are as follows:

• 360p: $0.0229/second
• 720p: $0.0343/second
• 1080p: $0.0343/second
• 4k: $0.0800/second

The budget conversion is: unit price for the selected resolution × request duration × number of items. For the same specification and duration, each additional successful task usually adds the cost of one task to the budget, rather than doubling the cumulative budget for each round.

The actual bill and applicable multiplier are subject to the pricing panel on the site. Billing is calculated by request duration and cannot be inferred backward from the fractional seconds in the output file container.

Two operational rules directly related to budget: recreating a task because you are dissatisfied with the result adds the budget of one more task; when a network timeout occurs, first query the status of existing tasks and confirm that no task was created before deciding whether to create a new one.

Scenario 1: Text-based creative drafts

Applicable situation: you only have a text brief and need to compare multiple visual directions before entering formal production. This is the most direct use of text-to-video.

Approach

• Rewrite the brief into a visualizable description. "A young woman walks briskly on a city street in the early morning, holding a cup of coffee, camera tracking her" is more executable than "convey an energetic lifestyle."
• Pass only prompt, with no image parameters, and submit one task per direction.
• Use a shorter duration to control the per-item budget; the draft stage does not need long videos. Keep duration and resolution consistent within the same batch for easy side-by-side comparison.
• Record in a structured way: archive prompt, duration, resolution, task ID, and result URL together so the next iteration has a reference point.

Boundaries

The output of drafts is meant to help choose a direction, not to serve as delivery material; shot details, brand identifiers, and compliant subtitles usually still require subsequent professional production. If the final visuals must match existing assets, use first-frame image-to-video or reference-image-to-video instead.

Scenario 2: Animating a first-frame image

Applicable situation: you already have a high-quality static image—product shot, cover, illustration, poster—and want to make the scene move while preserving the subject from the original image.

Approach

• Use first_frame_url to specify the starting frame, and have prompt describe only motion and camera movement (slight push-in, slow orbit, flowing light and shadow) rather than re-describing the subject.
• When an ending frame is needed, pass both first_frame_url and last_frame_url to form a first-and-last-frame transition; in this case duration must not exceed 10 seconds, and the request must not include negative_prompt or system_prompt.
• Host images in a public location first: only publicly accessible HTTP(S) URLs are accepted; intranet addresses and Base64 are not usable.
• Store each item in the database: record the source image URL, prompt, duration, resolution, and task ID for traceability and reuse.

Difference from reference-image mode

first_frame_url determines "where to start," while image_urls provides style and content references. The two are mutually exclusive and cannot be used in the same request; passing only one image_urls does not turn into first-frame mode.

Scenario 3: Reference-image-constrained visuals

Applicable situation: a batch of assets needs to be closer to an established visual style in color tone, texture, and composition habits, while the quality of any single item is not the main concern.

Approach

• Use image_urls to pass 1–10 public reference images, choosing a small set that best represents the target style; avoid mixing reference images with conflicting goals, and check the actual generated results.
• Make it explicit that this is reference-image mode: even if only one image is passed, it is still reference-image-to-video and does not involve first-frame or first-and-last-frame.
• Establish fixed check items: dominant color, lighting tendency, visual density, and text areas, and compare newly produced batches side by side.
• When drift is found, check the reference material first, then adjust prompt, rather than blindly rerunning—rerunning creates additional tasks billed by the second.

Boundaries

Reference images can constrain style but do not guarantee that the subject or brand will match exactly, so manual spot checks are still required. Understanding it as a "style baseline" rather than "style insurance" will bring expectations closer to reality.

Go-live checklist

Confirming each item before starting helps catch input and budget issues early.

Capabilities and parameters

• Is it clear which mode is used this time: text-to-video, first-frame image-to-video, first-and-last-frame transition, or reference-image-to-video?
• Is prompt non-empty and no more than 20000 characters?
• Is duration an integer between 3 and 15 seconds? Has first-and-last-frame mode been reduced to within 10 seconds?
• Are resolution and aspect_ratio chosen according to use (default 720p, 16:9)?
• Is only one image source used: image_urls or first_frame_url/last_frame_url?
• Are all images public HTTP(S) URLs with no Base64?
• Have negative_prompt and system_prompt been removed from first-and-last-frame requests?
• Are video editing, extension, video/audio input, or seed used? These are currently unavailable.

Cost

• Is the budget calculated as the unit price for the selected resolution × duration × number of items, rather than by feel?
• Is the budget estimated based on the "number of candidates" rather than the "number of deliverables"?
• Is it clear that, for the same specification and duration, each additional successful task adds the budget of one more task?
• Is the actual bill based on the site pricing panel and applicable multiplier, rather than inferred from fractional seconds in the file container?

Engineering

• Has task submission been made asynchronous so the request side does not block waiting for video?
• Are task IDs retained and stored in the database, including prompt, duration, resolution, and result URL?
• Are there an explicit state machine and idempotency keys to avoid duplicate submissions?
• On network timeout, are existing tasks queried first rather than directly recreated?
• Is concurrency limited, with batch tasks waiting in a queue?

Quality and acceptance

• Are acceptance criteria fixed in advance: subject integrity, brand elements, text areas, and whether sound meets expectations?
• Is a manual spot-check ratio retained and not lowered when scaling up?
• Are circuit breakers and alerts set for daily or per-batch budgets?

The four modes share the same API shape; the only difference is the input parameters. Choose the right mode, encode the mutual exclusion rules into parameter validation, calculate the budget clearly by item count, and then move to batch production—the go-live path becomes clear.