Video generation

Studio presents several video-oriented workbenches, but their runtime readiness differs. Image to Video has a verified provider-dependent path when a source image and FAL configuration are present. Text to Video is not wired. Cinematic Scene and Character Motion can remain setup-required. Use the current status rather than treating the Video Studio entry point as proof that every video mode is live.

Choose a model

Choose the capability before choosing a model. Text-to-video and image-to-video have separate input contracts and do not share one readiness state.

For image-to-video, inspect the current model and provider status. The verified live path requires FAL setup, represented by FAL_KEY, and a source image. A model card can still appear when the provider is setup-required or unavailable.

Text-to-video has a workbench shell, but the runtime is not wired. Do not select a model and proceed as though a generated clip will be returned. Specialized video apps such as Cinematic Scene or Character Motion may expose controls while retaining a setup-required state.

Model and provider inventories are dynamic. Avoid publishing fixed counts or a permanent support matrix.

Inputs

Image-to-video requires a reference image. The media API rejects that modality when the source image is absent. Use a current Studio asset or another supported reference input only when the workbench can access it.

The prompt should describe motion, camera behavior, timing, and the elements that must remain consistent with the source image. Avoid assuming that a still image can provide missing depth, off-frame content, or identity details that are not visible.

Text-to-video can accept design intent in the UI, but no live request path is verified. Keep the prompt as a draft and do not describe a successful submission procedure.

Safety preflight applies before an accepted media job. Do not use reference media that you are not authorized to process, and do not include credentials or unrelated sensitive data.

Duration and format

Duration and format controls can appear in panel configuration, but the repository does not establish that every visible option reaches every provider. Treat them as workbench-specific settings.

For image-to-video, select only options enabled for the current provider and model. A disabled value, preview label, or readiness note indicates that the choice is not available. Do not publish fixed duration limits, file-size limits, frame rates, or format guarantees.

Changing duration can affect cost estimates and processing time, but no permanent public pricing or latency contract is verified. Estimated credits remain estimates.

Generation

Image-to-video follows the media job flow when its prerequisites are satisfied. The request needs a prompt, video modality, source image, compatible model, provider configuration, and a passing safety result. Accepted work returns HTTP 202 and creates a non-production-durable job.

Client phases can include validating, estimating, generating, finalizing, and completed. Provider setup or an unavailable model can stop the request before generation. A safety decision can block it or require consent.

Text-to-video should stop at the current Not wired yet state. Do not route around that limitation with a guessed provider call. Marketing prompt packs may generate selected images when OpenAI is configured, but their video handoff stays disabled without a real image or reference and FAL setup.

Review results

For an accepted image-to-video job, inspect the current job state and resulting asset reference. Confirm which capability ran, which provider state was reported, and whether the result is live, mock, fallback, failed, or disabled.

A completed job does not prove durable storage. The API identifies local private-beta storage and marks it non-production-durable. Keep a separate copy of an important result through a supported enabled action.

Extend, upscale, export, publish, and cross-app handoff actions may be visible but disabled. Do not document them as functional unless the specific control is enabled and its path is sourced.

Limitations

• Text-to-video is not wired.
• Image-to-video requires a reference image and current FAL setup.
• Cinematic Scene and Character Motion can remain setup-required.
• Provider and model availability are environment-dependent.
• Durations, formats, prices, latency, and quotas are not fixed documentation values.
• Result actions can be private-beta placeholders.
• Jobs and assets are not verified as production durable.

When a video idea requires an unavailable capability, preserve the prompt and reference materials as a project design. Do not present a mock preview, storyboard, or disabled timeline as a generated video.

Capability matrix

Use this separation whenever a user says “video generation.” The shared modality name does not erase the different contracts.

Source-image preparation

For image-to-video, choose a stable, legible source image with the subject fully visible. The route requires a reference image; a text description cannot replace it. Keep the source available until the job has accepted it, since the current asset store may not be durable.

Video-workbench evidence does not define public size or format limits. Follow current validation messages instead of publishing guessed constraints.

Provider setup

FAL setup is required for the verified live image-to-video path. The presence of FAL_KEY in implementation evidence supports that dependency, but documentation should not expose the value or invent a provider configuration URL. If the current environment reports setup required, stop before submission.

Processing and review

Video jobs can remain active longer than image jobs, but no latency guarantee is verified. Inspect queued, planning, running, or processing states through Studio Jobs. A completed record should be checked for a result asset and capability label.

If a panel shows a storyboard or timeline before generation, treat it as planning UI. It is not evidence that frames or clips were rendered.

Disabled post-processing

Extend, upscale, export, and handoff can appear as result actions while remaining disabled. Their visibility helps describe the intended workbench, but documentation must not turn them into steps. Preserve the result through an enabled path and record the limitation.

Text-to-video planning

The text-to-video shell can help organize a prompt, controls, storyboard, or timeline, but the runtime is not wired. Any preview shown there should be labeled as planning content. Do not create a job-state narrative or result-review steps for a request that cannot be submitted.

Image-to-video validation

Before submission, verify source image presence, prompt, modality, model, provider status, and safety outcome. The API rejects image-to-video without a reference. A source asset that cannot be resolved by the workbench is equivalent to a missing reference for the current request.

FAL dependency

The verified live path depends on FAL configuration. This is a provider setup fact, not a guarantee of availability or performance. The documentation should not expose the key, its format, or a fixed setup process beyond the current supported environment controls.

Video job interpretation

An accepted job enters the same broad media job system but can have different processing characteristics. Do not publish a fixed wait time. Track the job by identifier, state, and result reference. If a provider error falls back to mock behavior, label the result before review.

Format review

Use only the format and duration controls enabled for the current panel. If an output arrives in another form, describe the observed result rather than claiming automatic conversion. Export and extension remain separate actions and may be disabled.

Long-term use

A generated clip can be evaluated in the current stage even when storage is non-durable. Retain important media through a working enabled action and keep the job reference for provenance. Do not rely on the Studio history alone.

Motion prompt review

For image-to-video, separate subject motion, camera motion, and environmental motion. This makes the intended change easier to inspect without claiming a particular provider interprets the prompt deterministically. Avoid instructions that require unseen details outside the source image.

Source-asset provenance

Confirm whether the reference came from a completed live image job, fallback, mock, upload, or another source. The provenance affects how the video result should be described and whether the asset is likely to remain available.

Failure boundaries

Missing reference media should be corrected at input. Missing FAL setup is an environment issue. “Not wired” for text-to-video is a capability limit. Safety block is a content decision. These outcomes require different responses and should not be reduced to one video-generation error.

Storyboard and timeline status

A storyboard or timeline can organize planned scenes and motion. Unless a live video job uses those values, they remain planning data. Do not describe arranging cards as rendering, editing, or exporting a clip.

Consent and source rights

Use a source image that you have permission to animate. The safety preflight can evaluate the request, but the documentation cannot promise a complete rights or identity review. Privacy and Terms remain the approved references.

Accepted-job checkpoint

After HTTP 202, preserve the video job identifier before leaving the workbench. If the asset store is temporary, that reference may be the only way to correlate the current result during the session.

Unsupported text-to-video result

A text-to-video panel may display controls or illustrative output. Since the runtime is not wired, do not assign those elements a provider, job, usage estimate, or completion state.

Reference continuity

Keep the exact source image available through job acceptance and result review. A thumbnail or project association may not provide the same media bytes to the provider path.

Preview-only panels

A complete-looking panel can still be setup-required or unwired. Status and provider readiness take precedence over visual completeness.

Current conclusion

Only image-to-video has a verified provider-dependent path. Text-to-video and setup-required panels should remain planning surfaces until their runtime is inspected and enabled.

A planning storyboard can be retained for later implementation, but it should never be counted as a rendered clip, completed media job, or provider-produced asset.