A storyboard preview should not need a render farm.
That sounds obvious until you try to turn a single keyframe into motion. The creator wants to know whether the shot should orbit the actor, push into the face, or stretch time around a fall. The system sends the frame to a cloud video model. Then everyone waits.
For final pixels, waiting can be acceptable. For directing, it is poison. Camera motion is a decision loop. You try a version, watch it, change the shot, try again.
That is why we read CineMobile (Huang et al., 2026) closely. The paper does not claim to put a full Sora-class model on a phone. It does something narrower and more useful for storyboard work: it compresses a Wan 2.1 image-to-video stack into a small 4-step generator for three cinematic motion effects: bullet time, dolly zoom, and slow motion.
The headline numbers are blunt. CineMobile uses a 1.2B parameter student model, runs in 4 denoising steps, and reports a 40.11x DiT denoising speedup over the Wan2.1-I2V-14B teacher while keeping VBench total scores within about one point on the three tested effects. On a MediaTek Dimensity 8400 Ultimate 5G platform, the paper reports 20.02 seconds per denoising step and about 1.8 GB extra peak runtime memory over the idle phone baseline.
So no, it is not real-time. But it is close enough to change how we think about draft motion inside a storyboard product.
Why the paper narrows the problem
General video generation is too wide for mobile hardware. A model has to understand arbitrary prompts, new objects, complex physics, camera motion, editing language, style, and temporal consistency. That is a lot to compress.
CineMobile dodges part of the trap by targeting structured camera effects.
| Effect | What the model has to preserve |
|---|---|
| Bullet time | Subject identity while the camera appears to orbit or sweep around the subject |
| Dolly zoom | A stable foreground subject while the background perspective expands or contracts |
| Slow motion | Smooth intermediate motion without flicker or object interpenetration |
That scope matters. A camera movement note in a storyboard is usually not an open-ended film. It is an instruction: circle the actor, push the space away, hold the expression longer, make the background breathe. Those are structured tasks.
CineMobile is built around that structure. It starts from a Wan2.1 image-to-video teacher and trains effect-specific teacher variants with LoRA adapters. The student does not need to be good at every video task. It needs to be good enough at a few camera-motion tasks that creators can preview a shot without paying the full cloud-model cost every time.
The compression path
The method is a stack of three moves: prune the video DiT, distill it into four steps, then quantize it for mobile memory.
The first choice is the one we care about most: the authors prune depth, not width.
Width pruning changes the hidden dimensionality inside the video transformer. That saves compute, but the paper's appendix shows the price: identity deviation and detail deformation. For camera effects, that is a bad trade. A bullet-time shot with a faster model is useless if the actor's face drifts halfway around the orbit.
Instead, CineMobile looks for redundant contiguous blocks and replaces each selected span with a trainable surrogate transformer block. The surrogate keeps the same hidden width as the original backbone. It is trained to reproduce the hidden state at the output of the removed span.
Plain English: the model cuts out some depth, but it does not change the shape of the feature space that carries subject identity and temporal information.
That is a good lesson for any storyboard system. We should be suspicious of optimizations that make the model cheaper by throwing away the exact signals a director notices first: face identity, camera path, foreground-background geometry.
Why the warm-up stage exists
After pruning, the student is smaller but fragile. The paper does not jump straight into 4-step generation.
It first runs a supervised fine-tuning warm-up:
- Restore general image-to-video behavior using videos generated by the dense base model.
- Adapt the student to bullet time, dolly zoom, and slow motion using teacher-generated effect videos.
Only then does the paper do 4-step distillation.
That order is boring in the best way. It admits that compression creates damage, and that the model needs to relearn the baseline behavior before it can be pushed into a tiny sampling budget. In product terms, this is the difference between a fast preview model and a broken preview model.
The 4-step generator uses a reward loop
CineMobile adapts an adversarial DMD-style distillation setup to image-to-video DiTs. The paper uses a frozen real score estimator from the teacher, an online fake score estimator that tracks the student distribution, and a lightweight discriminator attached to the fake model.
The generator is trained with three signals:
| Signal | Job |
|---|---|
| DMD loss | Pull the 4-step student distribution toward the teacher distribution |
| Adversarial loss | Make generated videos look reference-like |
| GRPO reward | Use discriminator scores to refine the few-step trajectory |
The GRPO part is small but measurable. On bullet time, the paper reports a total-score gain of +0.47 for CineMobile with GRPO. The gain mostly comes from aesthetic and imaging quality, while subject and background consistency stay roughly in the same range.
That is the right place for a reward method in this setup. It is not inventing the camera language. The teacher and effect data already do that. It is cleaning up the perceptual damage caused by forcing the model into four denoising steps.
Quantization is where mobile becomes real
The final model uses hybrid post-training quantization:
| Part | Precision |
|---|---|
| Activations | 16-bit |
| Attention, text, and time linear weights | FP8 |
| Feed-forward network weights | 4-bit |
This is not uniform quantization. The feed-forward layers hold a large fraction of the DiT parameters, so the paper pushes them to 4-bit. Other pieces stay less aggressive. The result is a model footprint under 1 GB, with reported peak mobile runtime memory about 1.8 GB above the idle phone baseline.
For Story2Board, the memory number matters as much as the model size. A creator does not care that the checkpoint is small if the app kills other processes or fails on mid-range hardware. Mobile preview models need a memory budget, not just a parameter count.
The numbers that matter
CineMobile is compared with the Wan2.1-I2V-14B teacher on the three target effects. The final model has 1.2B parameters and 4 denoising steps; the teacher has 14B parameters and 20 steps.
| Scenario | Teacher total score | CineMobile total score | Gap |
|---|---|---|---|
| Bullet time | 89.27 | 88.35 | -0.92 |
| Dolly zoom | 89.96 | 89.30 | -0.66 |
| Slow motion | 88.51 | 88.05 | -0.46 |
The efficiency result is larger than the quality drop:
| Metric | Teacher | CineMobile |
|---|---|---|
| Parameters | 14B | 1.2B |
| Denoising steps | 20 | 4 |
| H200 DiT denoising time | 97.06s | 2.45s |
| DiT-FLOPs | 3.35e16 | 4.66e14 |
| Speedup | baseline | 40.11x |
| FLOPs reduction | baseline | 71.89x |
The paper also compares slow motion against FILM under a 20x setting where only the first and last frames are provided:
| Metric | FILM | CineMobile |
|---|---|---|
| PSNR | 30.57 dB | 35.68 dB |
| SSIM | 0.713 | 0.858 |
That result is interesting for keyframe-based workflows. Storyboard tools already have keyframes. It is tempting to think interpolation is the natural bridge from keyframes to preview video. CineMobile argues that a learned image-to-video model can synthesize the missing motion more cleanly when the time gap is large.
Why this is relevant to Story2Board
Our pipeline starts with story structure and ends with pixels:
The part CineMobile touches is small: keyframe -> draft motion preview.
But small does not mean minor. A storyboard panel says what the frame looks like. A preview clip tells the director whether the shot moves correctly. That is a different creative decision.
For a dolly zoom, the user needs to see whether the subject stays visually anchored while the background changes perspective. For bullet time, they need to see whether the orbit feels spatially coherent. For slow motion, they need to see if a gesture stretches cleanly or turns mushy.
Those checks do not need final render quality. They need fast, cheap, repeatable drafts.
What we would borrow
First, camera effects should be structured fields in the shot schema, not just prose inside the prompt.
{
"camera_effect": {
"type": "dolly_zoom",
"direction": "push_in",
"subject_lock": true,
"background_perspective_change": "strong",
"preview_priority": "camera_control"
}
}
That gives the video layer a clean contract. The Gemini co-director can still write human-readable shot notes, but the renderer gets a machine-readable instruction.
Second, video generation should probably split into two tiers:
| Tier | Purpose | Model choice |
|---|---|---|
| Draft preview | Test motion intent, timing, and camera path | Cheap few-step model, possibly on-device or edge |
| Final render | Produce publishable clip | Sora, Veo, Kling, Wan, or whatever frontier model wins that week |
We already think this way for story planning. Draft first. Lock decisions. Spend quality budget later. Motion should follow the same pattern.
Third, evaluation should be effect-specific. The CineMobile paper explicitly avoids treating every VBench dimension as equally meaningful for these effects. A high dynamic-degree score, for example, does not necessarily mean a better dolly zoom. More motion can be worse if the subject stops feeling anchored.
For Story2Board review, that suggests separate video checks:
| Effect | Review questions |
|---|---|
| Bullet time | Does the camera path feel orbital or sweeping? Does the subject identity hold? Does the background geometry stay coherent? |
| Dolly zoom | Does the subject remain stable in frame? Does the background perspective change enough? Does the effect read as intentional? |
| Slow motion | Are intermediate frames smooth? Do hands, props, or clothing pass through each other? Does the moment still feel timed to the beat? |
This connects to the lesson from CANVAS: consistency has to be scored against the story state and shot intent, not against a generic image-quality number.
Where CineMobile does not solve our problem
We would not train our own CineMobile clone right now.
The paper's experiments use 8 NVIDIA H200 GPUs. The training depends on teacher models, effect-specific LoRA adapters, curated portrait data, and mobile deployment work. That is a real model-engineering project, not a small product feature.
There are also scope limits:
- The paper tests three effects, not the full grammar of camera movement.
- The data is portrait-centric. Crowds, creatures, vehicles, and complex production design are not the main target.
- The mobile result is still slow. Twenty seconds per denoising step means this is a draft workflow, not live camera control.
- Multi-character interaction is not the point of the paper. For that, SCAIL-2 is a closer reference.
- The model handles camera-effect video. It does not replace semantic state tracking, character anchors, prop state timelines, or the pixel-level consistency work discussed in Story2Board.
That last point is easy to miss. A fast I2V model can animate a keyframe, but it does not know why a prop should be missing, why a room should look colder after a betrayal, or why a costume change is intentional. The application layer still has to carry that.
The product bet
CineMobile makes one bet we agree with: the first local video models that matter for creators will not be general-purpose film generators. They will be narrow preview engines.
For storyboard work, that is fine. Maybe ideal.
Most directors do not need the final 4K clip while they are deciding whether shot 17 should be a lateral track or a push-in. They need a quick answer to a smaller question: does this motion serve the beat?
If a model can answer that on-device or near-device, even at 480p and even with visible draft artifacts, it changes the cadence of previsualization. The creator can test more camera choices before spending cloud credits on the final render.
That is the useful takeaway from CineMobile. Not "video generation has moved to phones." It has not. The useful takeaway is that camera-motion preview may be separable from final video generation, and separable systems are easier to make cheap.
All diagrams were created by the Story2Board team for this analysis.
References
Huang, X., Deng, Z., Wang, X., Xiao, X., & Deng, Z. (2026). CineMobile: On-Device Image-to-Video Diffusion for Cinematic Camera Motion Generation. arXiv preprint arXiv:2607.03803. https://arxiv.org/abs/2607.03803
Yan, W., Guo, F., Yang, Z., & Tang, J. (2026). SCAIL-2: Unifying Controlled Character Animation with End-to-end In-Context Conditioning. arXiv preprint. https://arxiv.org/abs/2606.10804
Wan Team. (2025). Wan: Open and Advanced Large-Scale Video Generative Models. arXiv preprint. https://arxiv.org/abs/2503.20314