How AI livestreams work

There are two common ways to organise generation. Your application can request short clips and join them together, or it can direct an ongoing generation session. H3 Max and H3 Max Director provide examples of these different interfaces.

The designs below are proposals for a prototype. They have not been tested here against the API, and they do not describe the private infrastructure of projects listed on BornLive.

Give audience input a selection rule

A basic interactive AI livestream might follow this sequence:

        Viewer suggestions
  → moderation and selection
  → next-scene prompt and story state
  → video generation
  → output review and playback buffer
  → shared broadcast
      

A thousand viewers can send a thousand ideas. The stream still has limited screen time. Choose a rule that tells people how a suggestion reaches the show, such as a voting window or an editor selecting one idea per scene.

For a first prototype, we would use a rule as simple as "Suggest the next event. We select one idea for each scene." Then show which suggestion was selected. Viewers should be able to tell whether their idea is waiting, was rejected, or is about to appear.

Keep the show's established facts separately from the incoming suggestions. A selected prompt should change the next event while preserving details the show needs, such as who is present and where the scene takes place.

Generate short clips ahead of playback

In a clip-based system, viewers watch finished material while the application prepares the next video. Each request needs a prompt and whatever context the model accepts.

One way to connect scenes is to extract the final frame of a completed clip and use it as the starting image for the next request. The H3 Max image-to-video API accepts a first-frame image, which makes this workflow possible.

That creates a dependency. You have to receive the previous clip before you can extract its final frame. Generating unrelated scenes in parallel can increase total output, but it does not speed up a sequence that depends on each preceding result.

Pieter Levels discussed this problem in his Infinite Slop follow-up. He considered connecting clips through their final frames and noted that generation slowdowns would make a smooth sequence difficult.

For a sequential chain, plan around this condition:

        Average time to prepare the next usable clip
<
Playable time added by that clip
      

Include processing and review when measuring preparation time. A five-second clip that takes six seconds to prepare will gradually drain the playback buffer if that pace continues.

A buffer gives the system time to absorb an occasional slow request. It cannot keep playback running indefinitely when generation consistently falls behind.

Direct an ongoing generation session

H3 Max Director uses an ongoing session. The fal client receives video and audio over WebRTC and sends control messages to direct generation. fal describes the system as preserving characters, settings, and story continuity.

Your application still has work to do. It chooses audience input, tracks the show's state, and handles session failures. It also needs a plan for what viewers see when the session ends.

A continuous session can still deliver video in chunks and take time to respond to a new prompt. Measure how changes appear on screen before deciding how often viewers should be allowed to redirect the show.

As of September 6, 2026, fal asks users to request access for Director sessions longer than two minutes. Check that limit before designing a channel around one long session.

Measure how long viewers wait

Real-time AI video generation involves more than the model's generation speed. For an audience suggestion that reaches the show, measure the time between submission and its first visible effect.

For a system that performs these stages in sequence, a planning estimate is:

        Response delay ≈ selection wait + generation and processing
               + output review + playback wait + delivery
      

A larger buffer can reduce playback interruptions, but it also puts more finished video ahead of a newly selected idea. Viewers then wait longer to see their influence. A smaller buffer shortens that wait and leaves less room for generation delays.

The H3 Max API defines its reported inference time as GPU denoising time. That measurement excludes other parts of the request. Prompt-expansion settings also affect processing time.

Record the median response time and the slowest responses during a test session. Count playback stalls, rejected generations, and the share of audience suggestions that reach the screen. A model can produce a fast clip while the complete show still leaves viewers waiting.

Share one generated show

For a public channel, generate one show and distribute its output to the audience. Opening a separate generation session for every viewer would change both the product and its costs.

A shared broadcast still has delivery costs that can grow with the audience. Track generation and distribution separately so you can see which part of the system becomes more expensive as viewers arrive.

Individual sessions make sense when each viewer needs their own story. In that case, set per-user spending and session limits before opening access.

Put operating controls in the application

The application should moderate incoming suggestions, limit request rates, and enforce a spending ceiling. Viewer text must not be able to change billing settings or override the show's operating rules.

Add a stop control and a fallback screen. Review generated material before it reaches viewers where the workflow allows it, and label the show as AI-generated.

Keep API credentials on the server. fal's Director documentation uses an authenticated server proxy so the browser can connect without exposing the API key. Protect access to that proxy as well.

Test one short show

Start with one channel and a clear premise. Run a short session with a few audience suggestions, then check whether the selected ideas appear, the story remains recognisable, and playback keeps up.

Use the recorded delays and billed usage to decide what to change next. A buffer problem needs a different fix from a confusing voting rule or a model that repeatedly loses the character's appearance.