Just rebuilt my short film previs pipeline with Seedance 2.0 — what used to take four people is now a single script.

Last week I spent three afternoons rebuilding a short film’s pre-vis pipeline around a single API endpoint. The script, director’s notes, and shot list didn’t change at all. But what used to require a four-person storyboard team, a junior 3D artist for rough blocking, plus a week of revisions, collapsed into one Python script.

Seedance 2.0 is ByteDance’s multimodal video model from this February. It does 4 to 15 seconds, 480p to 1080p, supports seven aspect ratios, and even outputs native audio. They added this omni-reference thing: you can feed it the first frame, last frame, character/style/motion reference images, even reference audio. I tested it and the character and scene consistency is way more solid than any open-source model I’ve used. One API call gives you a clip with sound you can actually watch, not a silent video that needs music slapped on.

What hit me hardest is the pre-vis part. That “90% of the workload” claim? Totally real here. Before, rough blocking a single shot meant a junior artist spending two or three days in the engine, then another round or two of revisions. Now it’s minutes per version, good enough for the director, DP, and producer to argue over whether the shot is worth shooting—and that meeting is what the studio is actually paying for. For the batch short video stuff, I queued it up: Monday I wrote a bunch of prompts into a CSV, let the script run overnight, and picked the final clips on Wednesday. Two gotchas to note: duration is a fixed enum (4/5/6/8/10/12/15), so don’t promise 7 or 9 seconds in your copy. And keep audio descriptions abstract—“background ambient music” type stuff, not precise foley like “tick-tock of a watch,” because it won’t deliver. Also, first frame and reference images can’t have real human faces. Illustrations, landscapes, product shots, or AI-generated images without people are fine.

I buy that for pre-vis. Rough layout is the most draining part and gets the least credit—if you can crank out a version in a few minutes that’s good enough for a meeting, you’ve already won.

Sitting here waiting for someone to actually test it out.

That fixed enumeration time thing is such a trap. Last time I promised 7 seconds and got totally roasted for it.

Replying to the guy above, yeah it’s this one — the enum is hardcoded in the docs, so don’t go inventing some in-between values on the client side.