Build1 publisher3 min readPublished
H3 Max renders five seconds of 768p video in about three seconds, soundtrack included
The speed figure comes from a single dev.to write-up and describes generation, not delivery. The design decision underneath it is that frames and stereo audio leave in one pass, so the smallest thing you can retry is the whole clip.
The Engineer · Build desk
What happened
- MiniMax H3 arrived at the end of July 2026, the open weights followed in August, and fal.ai shipped a speed-tuned build called H3 Max a few weeks after that.
- According to a dev.to post from the builders of h3max.info, H3 Max renders a 5-second 768p clip in roughly three seconds, faster than the clip plays.
- The post reports that a 15-second 1080p clip generated by H3 came back as a 124 MB file.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Because the soundtrack leaves with the frames, a bad mix cannot be repaired by a second audio call; the only fix is a fresh clip, billed at full length.
- decision Any web front end has to choose the queue-plus-webhook path, because the blocking subscribe call holds a connection open for the entire render.
- cost fal enables auto top-up by default, so an afternoon of prompt iteration draws on the card unless someone changes the billing setting first.
- capability Reference image, video and audio URLs in one call make cross-shot character consistency a request parameter, per the post, so continuity work moves out of editing.
The soundtrack is the interesting part of the design. One request takes text, an image, video or audio, and returns 5 to 15 seconds of video at 24 fps with native stereo attached [3]. The post's author writes that "You are not stitching a silent clip to a separate audio model, and you are not fixing the audio afterwards either: it comes out of the same pass, so if you do not like it, you regenerate" [4]. With a silent video model plus a separate audio model, a bad mix costs one audio call and leaves the frames alone. Here the frames go back through as well, and fal bills per second of generated video [5].
Three seconds of compute for five seconds of output works out to about 1.7 seconds of video per second of compute [20]. That ratio transfers to a product only if the request is five seconds at 768p, the queue is empty when it arrives, and the file gets to the client quickly. The post reports the figure without saying where it ran, how warm the path was, or how deep the queue was [23]. It does say people are already running live, chat-driven video streams on H3 Max, which is the closest thing in the material to evidence that generation stays ahead of playback under real use [18]. If time scales with duration, a 15-second render is about nine seconds of compute [22]. In the post's own words, a 15-second render is "still seconds of waiting you do not want to hold a connection open for" [7].
Then the bytes. A 15-second 1080p clip from H3 came back at 124 MB, according to the post [8]. A second of video at that rate is 8.3 MB, roughly 66 Mbit/s to stream as delivered [21]. That measurement is H3 at 1080p, not the H3 Max 768p path the speed figure describes. Scaled to five seconds, the same rate puts about 41 MB on the wire for a clip that took three seconds to make [25].
Endpoint choice is where cost gets decided. There are five: text, image and reference to video under minimax/h3-max/, plus text and image to video under minimax/h3-max-turbo/ [9]. Image to video swaps aspect_ratio for image_url and adds an optional end_image_url to animate towards a final frame, with resolution set to 480P or 768P and duration between 5 and 15 seconds [11]. The post's advice is to iterate prompts on Turbo at 480p before spending anything at 768p [12].
The other half of the post is a directory, and its reason is the line "The model is easy. Finding anything about it is not." [15] The official announcement, the open weights, the API docs, the fal endpoints, the license, the deployment guides and the live projects sit in half a dozen places, and search results confuse H3 with H3 Max [14]. h3max.info answers that with hand-checked links plus a studio where endpoint, length, resolution and aspect ratio are already chosen [16]. The post is by the people who built the site, which its own headline says outright [24].
What to watch
- Published per-second rates for h3-max and h3-max-turbo at 480p and 768p would make the cost of a regeneration calculable.
- A measured 768p file size would show whether generation or transfer dominates the wait a user actually experiences.
- Independent latency numbers that include queue time, from a region other than the post author's, would test whether 1.7x realtime survives contention.