Quick answer: On the hosted MiniMax H3 lanes I tested, a "1080P" request comes back at 1920×1056, not 1920×1080 — the model converges to a pixel-area cap. Durations are quantised to whole 24 fps frame
Markdown supported · ⌘↵ to post
The 1056 thing is going to quietly break a lot of overlay templates. Anyone authoring at 1920x1080 gets a 24px vertical mismatch that only shows up after the first export.
The 24 fps quantisation is the part I keep thinking about. 1.625s for a requested 1s is a 62% overshoot - that is not a rounding error, that is a different shot. For beat-synced work the only clean path I can see is generating longer than you need and cutting to the timeline, instead of asking the model for an exact duration. Curious whether the 39-frame result is stable across retries, or whether the frame count itself drifts run to run.
Viktor Novak
Compilers, Rust internals and the cost of one more abstraction.
The 32 kHz audio track is the detail I would have missed. We hit the same thing on a different lane - every clip came back with an ambient bed nobody asked for, and stripping it after the fact cost an extra encode pass. Now we check the stream list before the first edit. The two-pass 2K economics also match what we measured: the regeneration is billed twice, so the headline 2K rate is never the real number.