Hmm… The effect will probably vary depending on the downstream model, but separating these concerns still seems useful:
I think the shot table is useful even if it turns out not to be the best format to send directly to a particular video model.
The distinction I would make is:
shot specification / review rubric
↓
model-specific prompt
+ native controls where available
↓
generation
↓
evaluate against the original shot specification
That keeps the useful part of the structure — narrative purpose, framing, camera behavior, subject action, background behavior, lighting, transition, timing — without assuming that every model should receive those fields in the same textual form.
Different current systems already seem to make that trade-off differently.
| Model / workflow |
How the shot structure maps to generation |
Cut / boundary control |
Timing control |
Practical implication for this table |
| LTX-2.5 |
Multi-shot can be generated in one prompt, but the official guide recommends chronological prose with explicit cuts rather than a numbered shot list |
Cuts are named in natural language |
Overall duration can be set/predicted; this is not the same as hard per-shot scheduling |
Keep the table as the specification, then translate it into LTX-style prose |
| HunyuanVideo-1.5 |
Its prompt guide explicitly separates subject, motion, scene, shot type, camera movement, lighting, style, atmosphere, etc. |
Mostly expressed through the prompt in the material I found |
The runtime exposes total video length in frames, but that is different from assigning exact intervals to individual events |
The table maps well to semantic prompt planning, especially action/camera/lighting |
| MultiShotMaster |
Uses a global caption plus per-shot captions |
Shot ranges are explicitly represented by shot_groups |
Per-shot frame ranges can be specified |
The table can map fairly directly into per-shot captions plus explicit ranges |
| StoryMem |
Uses a story script with per-shot descriptions and generates shot by shot |
cut is separate metadata; continuation can reuse information from the preceding shot |
Timing is organized at the shot/workflow level |
The table works naturally as a shot script, while continuity is kept separate |
| ShotDirector |
Uses hierarchical shot descriptions together with dedicated camera/transition mechanisms |
Shot-aware mechanism |
Not primarily a natural-language timing mechanism |
Some cinematic constraints are better treated as model controls than as prompt wording |
So I would not read the differences between those approaches as evidence against the structured version. They suggest something slightly different: the table may be most reusable as the canonical brief, while the final representation is compiled for the model being used.
For this train example, a small comparison could therefore be:
A. Original prompt
B. Same semantic requirements,
but resolve the shot/camera ambiguity and translate them
into the target model's preferred prompt style
C. If the model exposes native controls,
move things such as shot boundaries, timing, or camera
out of prose and into those controls
I would keep the review criteria identical across A/B/C. That makes the comparison about where the instructions are represented, rather than silently changing what the requested scene contains.
One important control would be to avoid making B simply “more detailed” than A. If B adds new visual information, an improvement could come from the extra information rather than from the cleaner structure.
Why I would keep the shot specification separate from the final prompt
There are a few fairly different design patterns in current video systems.
1. Structured internally, prose externally
LTX-2.5’s current prompting guide is a useful example because it explicitly supports multi-shot generation, but its recommended user-facing representation is still prose.
For multi-shot scenes it recommends:
- keeping the sequence chronological,
- explicitly naming transitions such as a hard cut or match cut,
- re-establishing the framing after a cut,
- re-identifying recurring subjects,
- stating what remains continuous across the edit.
It also specifically warns against treating an arbitrary shot-list format as automatically optimal for LTX.
That makes a representation like your table useful upstream:
Shot 1:
purpose
framing
camera
action
background
lighting
transition
timing
Shot 2:
...
and then an LTX-specific conversion can turn that into something closer to:
Wide shot ... [action].
A hard cut transitions to a close-up ...
[re-establish subject, framing, lighting, action].
The view cuts to ...
The information has not disappeared; only its final encoding has changed.
2. Structured semantics inside the prompt
HunyuanVideo-1.5’s prompt handbook takes another useful approach.
Its basic T2V formulation is roughly:
Subject + Motion + Scene
+ Shot Type
+ Camera Movement
+ Lighting
+ Style
+ Atmosphere
It also uses temporal connective language such as “initially”, “then”, “next”, and “finally” in more complicated examples.
That is quite close to the kinds of concerns you separated in the train-scene table. The difference is that the model guide ultimately recombines them into a prompt.
So this seems like a good example where decomposition helps prompt construction, even if the decomposition syntax itself is not the API.
3. Shot structure becomes an explicit model input
MultiShotMaster goes further.
Its inference examples separate:
- a global caption describing subjects / overall scene / style,
- captions for individual shots,
- explicit frame ranges for those shots through
shot_groups.
The implementation passes the per-shot prompts and shot groups separately into the generation pipeline.
That is a useful comparison for the timing column in your table: once the system has an explicit representation for shot ranges, the requested boundary no longer has to be inferred entirely from a phrase such as “for three seconds.”
4. Continuity can also be a separate variable
StoryMem uses per-shot story descriptions but also has a separate cut field.
Conceptually, that lets the workflow distinguish:
new shot / cut
from:
continue smoothly from the preceding shot
rather than expecting prose alone to communicate all of the continuity semantics.
I think that is particularly relevant to this train example because “camera change”, “new shot”, “continued action”, and “continued scene state” are related but not identical requirements.
A character can continue the same action across an edit; conversely, the camera can keep moving without there being a cut.
Keeping those concepts separable in the brief makes either implementation possible.
Timing, cuts, and camera control seem worth treating as separate layers
I especially agree with the caution in the original post about not assuming that a timestamp written in a prompt is a hard scheduling control.
There are at least three different things that can otherwise get mixed together:
- total generated clip length
- desired narrative pacing
- hard placement of a particular event or shot within the timeline
Those are not equivalent.
For example, setting a model to generate seven seconds only determines the available output duration. It does not necessarily mean that writing “0–3 seconds: …” forces that event to occupy exactly those frames.
There is research specifically targeting this distinction. MinT: Mind the Time starts from the observation that multi-event prompts can omit events or put them in the wrong order, and introduces explicit temporal conditioning that binds individual event captions to periods of the video.
I would therefore treat the Timing column in the table as useful even when the target model cannot enforce it:
requested timing = part of the brief
submitted duration = runtime setting
actual event timing = observation from the output
Those three values can then be compared rather than collapsed into a single “timing adherence” statement.
The same distinction appears with camera instructions.
Some models expose camera mostly through text. HunyuanVideo-1.5, for example, has a fairly rich vocabulary for pans, following shots, dolly movement, orbiting, fixed camera, and so on.
Other systems go further. ShotDirector combines high-level shot descriptions with parameter-level camera control and a shot-aware mechanism.
So if a requested camera transition fails, there are at least two plausible layers to inspect:
Was the intended camera relationship unambiguous in the brief?
↓
Does this particular model/workflow have enough control
to realize that relationship reliably?
That seems more informative than assuming either that prompt wording is always the problem or that prompt wording never matters.
A compact way to evaluate the experiment
I would probably keep your existing checklist rather than replacing it with one overall preference score.
For each attempt:
| Dimension |
Question |
| Narrative |
Were the requested story events present and in the intended order? |
| Framing |
Did each intended shot use approximately the requested composition? |
| Camera |
Did camera position/movement match the brief? |
| Editing |
Were the intended cuts/transitions present and understandable? |
| Character |
Was the main character sufficiently consistent across shots? |
| Background |
Did the seated passengers remain still/dark as requested? |
| Lighting |
Did the platform-to-carriage lighting change occur? |
| Timing |
When did each event/shot actually occur relative to the requested plan? |
This kind of factorized evaluation also has precedent in video-generation benchmarking. VBench, for example, deliberately decomposes video-generation quality into separate dimensions rather than treating it as one monolithic score.
For a forum experiment, I do not think this needs to become a large benchmark.
Even a small table such as:
A original B clarified C native controls
Narrative ✓ ✓ ✓
Shot boundaries ? ✓ ✓
Camera orientation ✗ ✓ ✓
Background constraint ✓ ✓ ✓
Lighting transition ? ? ✓
Timing ~ ~ ✓
would be much more informative than saying “B looked better.”
It also exposes trade-offs. For example, B might improve framing but accidentally reduce character consistency. That is useful information rather than a failed experiment.
If the generator is stochastic, I would also avoid drawing much from a single lucky or unlucky sample. This still does not require a huge run: keeping the model/version, seed where applicable, generation settings, submitted prompt, and a small number of attempts would already make the comparison substantially easier to interpret.
If a prompt enhancer or rewrite pass is enabled, that becomes another experimental variable. LTX-2.5, for example, has an optional prompt enhancer that can be disabled when exact prompt preservation matters.
In that case it would be useful to distinguish:
prompt authored by the user
↓
prompt after any rewrite/enhancement
↓
model input
where the tooling makes the rewritten prompt observable.
A decision tree for different downstream models
I think the same shot table can survive all of these cases:
Does the downstream system expose native shot / cut /
timing / camera controls?
│
├─ Yes
│ │
│ ├─ Keep the table as the canonical specification.
│ ├─ Put hard constraints into the native controls.
│ └─ Use text for subject/action/scene/style semantics.
│
└─ No
│
├─ Does the model officially support multi-shot prompting?
│ │
│ ├─ Yes
│ │ └─ Translate the specification into that model's
│ │ documented prompt syntax.
│ │
│ └─ No / unclear
│ └─ Treat one-pass multi-cut adherence as something
│ to test rather than assume.
│
└─ If one-pass generation struggles badly,
compare it with a per-shot workflow rather than
continuing to change wording indefinitely.
That last branch does not mean per-shot generation is universally better. It changes the problem: continuity between independently generated shots becomes a new requirement.
But it is a useful diagnostic distinction:
Can the model execute this shot structure in one generation?
vs.
Can the desired shots be generated individually and then
made sufficiently consistent to form the sequence?
Those are different experiments and can fail for different reasons.
So overall, I would keep the structured version.
The main change I would make is not to treat it as a universal final prompt format. I would treat it as the stable description of what the scene is supposed to do, then adapt that description to whatever the downstream model can actually consume.
That also gives the original-vs-structured comparison a cleaner interpretation:
- if only ambiguity resolution changes and adherence improves, that is evidence that the clearer specification helped for that model/workflow;
- if moving timing/cuts into native controls improves only those dimensions, that tells us something different;
- if neither helps, the table is still useful because it makes the failure much easier to localize.
That seems like a useful result either way, without needing to turn this one train scene into a universal prompting rule.
