Genie 4: live world control, few-minute sessions
Google says: its audiovisual world responds to text and camera input, but access is a trusted-tester preview and continuous interaction lasts only a few minutes. The published examples are shortened; price and viewer delay are not public. Check the access and session limit.
Hy-Nomas: a 4090 fit claim, an eight-B200 browser test
Project and community reports: the low-memory RTX 4090 preset has no published viewer rate. The eight-B200 Reactor route generated 18.53 FPS over two minutes; a separate 4090 ComfyUI job took 85 seconds for 10 seconds of 1280×704 video. Decoder-weight rights for paid use need clarification. Compare the routes.
SGF+: a 24-hour paper result, a four-minute browser default, and a slower 5090 file route
Project reports: a B200 Reactor service generates about 19 FPS for 16-FPS browser playback; prompt edits wait for the next chunk and buffered frames. An independent ComfyUI pack needs 56.6 warm seconds for a 20-second 5090 output. Neither establishes a 24-hour viewer session or full cost. Compare the three routes.
Micro-World 2: 42.49 decoded FPS on one MI350X, not a priced viewer session
AMD reports: its 352×640 action-controlled model reaches 42.49 decoded FPS with a lightweight decoder or 32.12 with the original Wan VAE. The faster decoder reduces visual quality; no browser response, accepted long session or full bill is measured. Read the route and decoder check.
SolarWM-H3: 1.15 seconds from keypress to screen, on eight Blackwell GPUs
Project reports: its browser demo reaches a 1.15-second median for a matching frame after a keypress. The integrated backend reports 24.38 steady-state FPS. The documented route is video-only and needs eight Blackwell GPUs; no p95, long-session quality or complete bill is published. Read the browser and hardware check.
EdenLive on a 5090: 25.17 FPS in a file, not yet a browser result
Project reports: LightX2V’s warm 717-frame, 1280×704 proxy-video job runs at 25.17 inference FPS on one RTX 5090. It saves an MP4. EdenLive’s WebRTC service guide lists an 80-GB GPU in its verified environment; action-to-screen delay and a full bill remain unmeasured. Check the two deployment paths.
Reactor ComfyUI: a hosted live window, not local FastH3-Omni
Provider says: Reactor’s nodes connect ComfyUI to its API. FastH3-Omni queues finished audio-video clips before playing them; its displayed $0.75/minute rate is not a delivered-hour bill. Check the route before choosing hardware.
One RTX 5090: 24-fps H3 playout, not measured viewer control
Community project reports: FastH3 Live v2.1.0 makes each 15.08-second 448×448 video-and-audio clip in 10.8 warm seconds on a pinned TaoMate, Light VAE and attention stack. The prefilled channel plays queued scenes; no viewer prompt-to-visible timing or full bill is reported. H3 derivative-weight rights have territorial limits. Read the setup and test boundary.
FastH3 Omni: faster finished clips on eight GB200s, not proven live
Project says: one 15-second, single-image job finished as an MP4 in 14.14 seconds; a 12-reference job took 59.77 seconds on the same eight-GB200 benchmark. Local 5090/ComfyUI setups use different profiles. No receiver delay or full bill is measured. Compare the routes and clocks.
TaoMate-H3: merged video, not yet synchronized AV
Project says: vLLM-Omni merged a one-session WebSocket route on 19 October. The two-H200-class FP8 test reports a 4.74-second median per 4.958-second window, but that is not viewer response. The merged MP4 carries video only; AAC work remains open. Check the route and limits.
fal Worlds: a browser route, not a priced delivered hour
Provider says: Abot World 0 and Lingbot World 2 offer hosted WebRTC worlds with movement and prompt controls. Each lists $0.00125 per generated compute second. Abot is labeled Commercial use; Lingbot Research only. A $4.50 compute-hour does not establish one usable hour on screen. Check the route and cost boundary.
H3 benchmark correction
A four-H100 CI run looked more than three times slower, but the metric returned to normal and the issue closed. The cause was not proven. A new API frame-count PR has no measured full-response gain. Read the measured limits.
Latest check: Self-Forcing stepwise video
Contributor reports: first nine frames at 1.80 seconds on one A800 80 GB, but 81 frames took 10.57 seconds for 5.06 seconds of playback. The branch is open and no remote viewer delay or full cost is measured. Read the stepwise check.
Latest check: H3 video decoding after the first latent
Authors report: a decoded frame 0.04 seconds after the first H3 video latent exists. Their 30-clip reconstruction test loses 0.63 dB PSNR versus the official decoder. Prompt-to-viewer delay and cost are not measured. Read the decoder check.
Latest check: ComfyStreamerH3 on one RTX 5090
Project reports: two 15.08-second 448×256 clips in a 23.51-second warm paired job. Its HLS browser waits for two completed clips and queues a new prompt until the current clip ends. The viewer response is unmeasured; the managed example uses a different GPU and price. Read the two-clock check.
Latest check: StreamForce browser control
Project reports: a force change landed about 13 seconds ahead of the viewer without pacing in one local test, versus six frames ahead after pacing in steady state. The shorter figure is queue position, not remote input-to-screen latency; quality reportedly drifts after roughly 10–15 seconds. Read the buffer and quality check.
Latest check: Waypoint-1.5 browser route
Project reports: one H100 generated 82 FPS and one A10G 25 FPS at 720p from an instance-local client. A separate remote sample delivered 44.6 FPS. The browser route also waited 645 seconds on cold compilation and visibly lost scene coherence after roughly 512 generated frames. Compare the clocks and limits.
Latest check: StreamRender-H3 browser route
Project says: an eight-GB200 racing demo connects a game engine, H3 renderer and browser. Its 218 ms render step is not a measured keypress-to-screen delay; the release card reports about 1.03 seconds between browser publications. Read the three-clock check.
Latest check: TeleFuser LiveKit
One four-H100 LingBot-World v2 replay generated 59.75 seconds of media; the client session lasted 79.25 seconds. This is receiver-timed project evidence, not a priced uninterrupted stream. Check the route and clocks.
Scope: a browser route with a paid-show gate
Project says: its WebRTC guide sends source video, returns generated video and accepts live prompt changes. Community report: one remote-beta H100 event test took about ten minutes to cold-ready; LongLive T2V and StreamDiffusionV2 V2V timings are not interchangeable. The repository alpha license is non-commercial, and event delay, one-hour rollover and full cost remain open. Read the show-readiness check.
Checked 10 October 2026 · Research update 031
Hallo-Live reports 20 FPS on two H200s. The public command saves a file.
Authors report: 20.38 generated FPS and 0.94-second model latency for text-driven joint speech and avatar video. Current inference code writes a final 24-fps MP4, a higher playback rate than the paper throughput; a maintainer estimates about 60 GB peak GPU memory for default inference. Read the model and client check.
What works today
Hallo-Live text-driven avatar: two-H200 paper throughput is promising for new spoken scenes, but the public command is a saved-file path, not a receiver-tested conversation. A 24-GB setup remains theoretical. Read the model and client check.
LiveAvatar audio-driven avatar: five-H100 paper throughput beats playback, but the authors estimate about three seconds with transport. A separate one-H200 cold finished clip took 181.44 seconds in an independent benchmark. Choose the clip or live-conversation job before comparing costs. Read the route and clock check.
ShotStream multi-shot research route: paper-reported 15.95 generated FPS on one H200 at 832×480, but the released example is CSV-to-final-MP4. Test a real prompt change and viewer receiver before calling it an interactive service. Check the evidence.
Veda H3 ComfyUI: a project-reported 5070 sparse-attention route for shorter offline clips, not a live stream. Compare the full 130.1-second job and accepted audio/video before changing a workflow. See the timed setup.
RAVEN ComfyUI preview: incremental H3 T2VA browser media is implemented, but the cited 24-GiB envelope was simulated on an H200 and the long test used synthetic conditioning. The maintainer advises 160 GiB available host RAM; physical 24-GiB full-prompt fit is untested. Check the hardware and prompt split.
Full-duplex preview, not a setup recommendation: Tavus Griffin-Lite has a reported streaming video-to-video conversation route, but no customer access or Griffin-specific price. Its component and benchmark timing must not be read as one end-to-end wait.
New offline control route: H3 mask editing is merged in vLLM-Omni’s video API, while its dedicated ComfyUI client remains open. It returns a completed edited video; do not treat it as mid-session control or borrow FastH3 timing from a different task.
New Hopper lead: the eight-H100 saved-MP4 result beats the clip playback clock, but it does not measure a repeated stream. The project has not completed its quality suite. Compare it only with the exact checkpoint, output and warm state pinned.
New route: TaoMate-H3 documents chunked T2AV on eight H20s. Its first-playable benchmark is not a receiver-visible stream; a 5090 LoRA adaptation is a separate offline route. Sol-H3 makes H3 clips faster than their nominal playback duration on eight B300s in a warm partial-pipeline benchmark. It does not yet add a measured live system. The four-step adapter, hardware count and excluded encoding matter more than the headline multiplier.
S2-Editing is a source-fed visual effect, not a text-to-video story engine. Its documented live transport does not establish viewer-visible delay or reliable long sessions. The recent H3 short-clip timing is a complete-response result, not a live session. The prior longer FastH3 profile returned a different clip before playback ended. Keep their durations and setup conditions separate. Read the long-video boundary.
| Route | What the evidence supports | What it does not prove | Best first move |
|---|---|---|---|
| ShotStream multi-shot model | Paper reports: 15.95 generated FPS at 832×480 on one H200; its example saves 16-FPS MP4. | A public live client, prompt-to-visible delay, receiver continuity, accepted quality or H200 bill. | Timestamp a changed shot prompt through first receiver frame and repeated 16-FPS playout. |
| Veda-on-ComfyUI H3 | Project says: on a 5070 12 GB, one 124-frame 1344×768 T2VA clip fell from 342.1 to 130.1 s with sparse attention. | Playback-rate video, a 7.1× complete-job speedup, accepted quality, 5090 timing or a live stream. | Run a matched whole-clip and quality A/B on the target machine. |
| RAVEN ComfyUI H3 preview | Project says: 192 synthetic-conditioned frames at 1376×768 sampled in 301.30 s on an H200 constrained to 24.100 GiB free; first local fragment at 51.46 s. Peak host RSS was 129.854 GiB. | A physical 24-GiB card, full-size real-prompt run, playback-rate or receiver-visible stream. The separate real-prompt test was 39 frames without a VRAM cap. | Before buying, require the same 192-frame real-prompt job on a physical card with full wait, quality and host RAM recorded. |
| Tavus Griffin-Lite | Provider says: selected-tester full-duplex preview generates 720p video in 320 ms chunks; 0.43 s average audio-to-video generator latency on H100s. NVIDIA VideoFDB reports separate median event timing of 1,892/2,232 ms for generation/perception. | A purchasable setup, complete user-call latency, production continuity, accepted quality, or Griffin-specific price. | Track customer access. Test one disclosed receiver-visible conversation and its bill before ranking it. |
| Hopper FastH3 patched clip route | Project says: 14.375 seconds of 1344×768/24 fps audio-video saved in 13.506 seconds on eight H100 80 GB GPUs after warmup. | Quality acceptance, load/compile, cold recovery, receiver-visible stream, control and cost. Its separate 1.690× A/B used eight H200s, not H100s. | Check accepted quality and bill first; then test repeated clips at a receiver with a missed-job fallback. |
| TaoMate-H3 chunked T2AV | Project says: on eight H20 96 GB GPUs, a ten-second 480×864 job took 14.810 s pure DiT and 17.287 s to benchmark first playable video. | Cold start, internal audio preparation, receiver-visible first frame, later-block margin, live control, accepted quality and delivered-hour cost. The original benchmark command saved a final MP4; the 5090 LoRA adaptation is not the separate merged vLLM streaming runtime. | Ask for repeated receiver timestamps and a prompt change before buying a streaming claim. |
| NVIDIA Sol-H3 | Project says: eight B300s produced 5/10/15-second 1344×768 T2VA outputs with audio in warm medians of 1.653/3.732/6.612 seconds through VAE decode. | Final MP4 encoding, startup, queue, viewer delivery, continuous session, prompt-to-screen response, quality acceptance and cost. The cited 11× comparison also changes a 49-forward base profile to a four-forward adapter. | Pin the exact four-step task/profile and record encoded-to-receiver time, a second clip, quality and billed hardware time. |
| Vidu S2-Editing | Provider says: publish a camera or file stream to RTC, subscribe to the edited result, and optionally relay it to an RTMP destination. Mid-stream reference or scenario changes are documented. Editing bills one credit per on-live second. | Independent control-to-viewer delay, long-session reliability, frame loss, output quality, or a delivered-hour invoice. It does not generate new scenes from text alone. | Test one source feed, one change, and one RTMP receiver. Record the visible change and billed seconds. |
| Remote H3 via vLLM-Omni | Project says: its named two-H100, four-simultaneous-request H3 test was slower with four-way co-batching than ordinary request mode. Its v0.30.0 release adds opt-in Ref2VA long-video continuation; one original-H3 eight-B300 example reports 30.667 seconds of output without a complete wall time. Its current two-RTX-5090 DLO command selects the FL2VA path, which covers T2VA and FL2VA. One 50-step T2VA job returned 124 1344×768 / 24 fps frames in 8 minutes 38 seconds; a separate warmed eight-B300 FastH3 T2VA profile returned a 10.125-second MP4 in 8.678–8.710 seconds. Another named eight-B300 FastH3 Dense test returned a 4.4-second MP4 in 11.7–11.8 seconds. | A complete two-keyframe client workflow, long-video wait or joins, a live endpoint, first visible frame, cold or warm readiness, staggered-arrival capacity, delivery, cost, quality, or FL2VA timing. The two-5090 record is one T2VA validation. | Choose the exact task, adapter file, schedule, output length, and arrival pattern first. Pin server and client revisions, then record the outgoing request, complete MP4, audio track, playable media, first visible frame, and a second queued request. |
| Dreamverse FastH3 profile | Project says: an opt-in FastH3 Preview v1 profile uses four visible GPUs, generates 124-frame 768×1344 audio-video segments, and feeds the prior last frame into the next segment. | A measured transition, a warm segment rate, queue margin, live response, cost, recovery, or consumer-GPU path. | Separate boot-to-ready from warm generation; inspect visible handoff and the fallback after one missed segment. |
| FastH3 8-Step V2 in ComfyUI | Community report: one named Radeon 8060S, 128 GB unified-memory environment completed a 768×1344, 243-frame V2 job in 33 min 9 s. The author says VSA did not engage below 12,288 tokens. | A general consumer baseline, quality result, live capacity, or reliable frame anchoring. FastVideo and the current official Comfy text-to-video template say T2AV only; the paired image-to-video template says T2VA plus first/last-frame FL2VA. | Pin task, package, canvas, frame grid, attention path, and memory; verify FL2VA separately if a transition matters. |
| YoLive / H3 Superfast | Provider says: a group can propose and vote on the next scene; 10 seconds of 768p, 24 fps output with native audio generate in four seconds on eight B200 GPUs. | Vote-to-screen delay, individual control, public uptime, cost, or durable continuity. | Record the control rule, vote window, moderation, delivery time, and what survives into the next scene. |
| H3 Max Director on fal | Provider says: an open WebRTC session can accept directions while audio and video arrive, with carried context between segments. | A permanent channel, measured interaction delay, or a tested restart handoff. | Price a finite session at the current $0.08/generated-second list price before a test. |
| FastH3 queue + playout | Project says: distinct generated clips can sit in build and playout queues. The cited roughly 15-second build is 15.5 s on four B200s and 12.9 s on eight. | Automatic viewer-safe continuity. Clips still hard-cut and reset the scene; timing is not an independent test. | State the GPU count, warm build time, ready seconds, autoplay policy, filler, and empty-queue fallback. |
| FastH3 Preview on one RTX 5090 | Platform benchmark says: a pinned 15.08-second image-to-video run took 55 s at 480×640 and 126 s at 768×1024 on a 32 GB 5090. | A general 5090 baseline, a live response, time to first frame, queue behavior, quality parity, or 8-Step V2 timing. The stated hot boundary excludes queue and model loading. | Use it for a clip-review or prequeue estimate only. Reproduce cold and warm timing with your task, resolution, adapter, and quality bar. |
| One-5090 FastH3 channel | Community project says: a dense four-step route can sustain 22.1 fps at 448×448 while an earlier clip is playing. | Native 24-fps motion, viewer control, continued story state, a normal 16:9 picture, a general 5090 baseline, or an independent result. | Start with the delivered fps, canvas, checkpoint, attention path, prequeue, and motion trade-off. |
| Local MiniMax H3 | Community report: one RTX 5090 and 64 GB RAM setup made roughly 15 seconds at 768×1024 in about 22 minutes. | A general 5090 baseline, a free route, or a live route. | Keep GPU, system RAM, model additions, frames, steps, version, wall time, and failure together. |
The pre-download card
For a frame-carried loop, record readiness first, then the model and adapter, GPU count, frame grid, conditioning asset, and visible handoff. Only after that should you compare warm time, quality, price, queue margin, or audience wait. A carried last frame is not a promise that the next shot holds together.
Choose the required behavior
- I need to edit a finished H3 clip: the vLLM-Omni API accepts source media and masks; check its exact server and client revisions before choosing ComfyUI. A completed edit is not live control.
- I need to alter a camera feed during a live session: inspect Vidu S2-Editing’s RTC input and RTMP relay path; budget its per-live-second charge and measure the change at a viewer receiver.
- I need a longer completed H3 clip: the v0.30.0 Ref2VA continuation route is a lead. Test the full wait, audio/video join, memory, and usable-output cost before treating the 300-second request guard as usable duration.
- I need a first/last-frame H3 transition through vLLM-Omni: inspect the current client scope before choosing hardware. The server recipe can express both frames; the current ComfyUI client cannot send both.
- I need a frame-carried FastH3 editing loop: inspect Dreamverse’s four-GPU Preview v1 profile, then measure readiness, handoff, and the viewer-visible result before promising continuity.
- I need an offline H3 test on two RTX 5090s: the documented DLO launch selects FL2VA, which also serves T2VA. Budget for a 384 GiB host and an eight-minute returned artifact, then test your required task separately.
- I need a fast complete H3 response: inspect vLLM-Omni’s eight-B300 FastH3 T2VA result, then verify cold start, queue, playable media, and first visible frame before you promise live video.
- I want the crowd to choose the next scene: study YoLive’s collective control loop, then ask for a timestamped vote-to-screen record.
- I want viewers to alter a held stream: compare Director’s session behavior with the interaction delay and restart plan you can afford.
- I want a local continuous feed of distinct scenes: investigate the one-5090 FastH3 route as a named workflow, then test its motion, quality, queue, and long-run cost.