“Continuous” survives only if the system survives a miss

Architecture before model

1. Input: accept prompts, proposals, votes, or controls; decide moderation and ordering.
2. Selection: state who decides the next action, when that window closes, and what happens to late or losing input.
3. Generation: measure acceptance-to-ready time, not an advertised frame rate.
4. Deployment: state the client host, inference host, task, adapter, server revision, GPU/host memory, and HTTP response boundary.
5. Buffer: hold enough finished or in-flight playable work for a slow render or retry.
6. Playout: choose the output fps; state filler, transitions, fallback footage, and what black, silence, a frozen frame, or slowed motion means.
7. Delivery and recovery: timestamp the visible result, reconnect sessions, preserve story state if possible, and log the gap.

Workflow scope comes before a continuity design

Project says: FastVideo’s new 8-Step V2 schedule is T2AV-only. ComfyUI says: its current template for the same checkpoint also permits first/last-frame FL2VA. Until that conflict is resolved, do not assume a local FastH3 clip can begin where the last one ended. A buffer cannot repair a missing conditioning contract.

A carried frame is another boundary, not a visible transition

Project says: FastVideo’s Dreamverse FastH3 Preview v1 profile feeds each segment’s last frame into the next segment as first-frame conditioning. The documented profile uses four visible GPUs and 124-frame 768×1344 segments.

This is stronger evidence of an intended continuity mechanism than a bare queue. It still does not say whether the next segment arrives in time, visibly respects the frame, survives a retry, or keeps audio and story coherent. The README’s cold compile warm-up can take tens of minutes, so log boot-to-ready before timing a session.

An API response is another boundary, not the visible result

Project says: vLLM-Omni can serve H3 through an OpenAI-compatible video API. Its stated four-B300 full-H3 FL2VA row returns 209 frames at 1248×768 in 86.964 seconds mean HTTP client latency. The output is about 8.71 seconds at 24 fps.

This tells a builder that remote H3 serving exists and that the named full-H3 condition is far behind playback. It does not reveal endpoint queue time, browser decode, media delivery, retries, or what a viewer sees while waiting. The next system timestamp after “request accepted” must be “playable media ready,” then “first visible frame.”

A fast next clip does not reveal the control-loop wait

Provider says: Yoroll’s YoLive lets a group propose and vote on the next scene. Its launch announcement says H3 Superfast generates 10 seconds of 768p, 24 fps video with native audio in four seconds on eight B200 GPUs. That figure leaves a six-second gross lead over the cited clip duration.

The missing timestamps are proposal close, moderation, winning instruction, generator acceptance, first delivered frame, and visible story turn. Without them, the source supports a faster-than-playback clip claim and a collective next-scene product—not a measured audience response time.

A local channel can close the timing gap by retiming

Community project says: FastH3 Live keeps two prompts queued on one RTX 5090 while it streams a prior clip. Its current dataset card says the named 448×448 route sustains 22.1 fps. The source explains that it retimes the audio and 362 source frames to the pace it can deliver; its earlier 18-fps example is 75% native motion.

This is a valid system design for an unattended channel if its visual format makes the motion compromise acceptable. It is not evidence that a viewer’s command changes the active scene, that 24-fps motion holds, or that the route survives a bad generation without a visible wait.

Open session, group choice, remote service, or buffered clips

Provider says: H3 Max Director uses an open WebRTC session, with new directions sent over a data channel while output tracks play. Provider says: YoLive is a group-selected next-scene route. Project says: vLLM-Omni is a separate H3 service route. Community project says: a local FastH3 channel can keep distinct prepared scenes moving at a source-stated sub-24-fps pace.

These are four different promises. Neither one implies the other three.

Nine questions before you call it live

• Who proposes or directs the change, and who selects it?
• When does that control window close?
• Where does the request run, and when does the inference server accept it?
• How long from a new direction to playable media and then visible change?
• What are the source fps, delivered fps, and visible motion trade-off?
• Which GPU profile, checkpoint, adapter, frame-conditioning asset, server state, and warm-up plan produced the next ready clip?
• How many ready or in-flight clips sit ahead of playback?
• What appears after a miss or a failed render?
• Does the next clip preserve the scene, voice, and viewer’s choice—or begin a new one?