CineTimeline Plan

This is the heart of the CineTimeline pack. Everything else is plumbing around it. Where a normal ComfyUI workflow is one prompt, one generation, CineTimelinePlan gives you a graphical timeline - shots, per-shot prompts, image references, a background-music track - and compiles, for whatever shot is currently selected, a single neutral render request. It doesn't load models and it doesn't sample. It's the editor; the renderer is elsewhere.

The pack is aimed at MiniMax H3 (the ~30B open-weight video model that generates picture and native stereo sound, day-0 ComfyUI support since summer 2026) plus LTX 2.3. The whole pitch is: the timeline only describes film structure, and a "model adapter" absorbs the differences between video models. You author the movie once and swap engines under it. This node is where that authoring happens.

What it does, mechanically

It takes a MODEL passthrough and one of two timeline sources: timeline_json (a serialized timeline - what the pack's AI planner outputs) or timeline_state (the editor panel's live JSON, which is what wins when you're targeting a specific shot). It validates the structure, selects the target shot (render_target_shot_id, or the first shot if empty), and emits:

• model - the input model, passed straight through to your segment renderer.
• segment_prompt - the global prompt merged with the selected shot's local prompt.
• frame_count - the shot's frame range, adjusted to H3's 17k+5 grid when motion-context continuation is active (that's why a "10 second" shot is rarely a round 240 frames).
• reference_plan_json - which image references intersect this shot, remapped onto consecutive <Picture N> slots for H3.
• video_extension_plan - continuation metadata for a motion-context shot: the previous segment's exact latent path and SHA-256, 22 frames of video context, 24 of audio.
• single_pass and hq_refinement - flags for the pack's experimental second-pass / single-pass routing.

If the current shot is set to "motion context" continuation, the node refuses to build until the previous shot's active rendered version is registered with a verified latent SHA-256. That check is deliberate: it's the guard that stops you from splicing a stale continuation onto a regenerated shot and silently corrupting the timeline.

The inputs a beginner actually touches

• model - required, but only a passthrough. It exists so the plan node sits in the model's data path and the graph stays consistent.
• timeline_state - the big editable JSON. You normally don't type this by hand; the node's own panel writes it as you drag shots around. But it's there, and a paste of a valid timeline is a legitimate way to bootstrap a workflow.
• render_target_shot_id - the "render this one shot" switch. The panel sets it when you press 生成当前片段 (generate current segment); leave it empty and the node plans the first shot.
• render_run_id - a run identifier that gets baked into latent filenames and manifests, so regenerating a shot appends a new version instead of clobbering the old one.

Installing and using it

cd ComfyUI/custom_nodes
git clone https://github.com/bo341805sg/ComfyUI-CineTimeline
# restart ComfyUI, or install via ComfyUI Manager ("CineTimeline")

Then note that the plan node alone is not a working workflow. Its outputs are only meaningful when wired to the rest of the chain: reference_plan_json → the pack's CineTimelineH3ReferenceConditioning, video_extension_plan → CineTimelineVideoExtensionPlan, and segment_prompt/model → a segment renderer that calls MiniMaxH3DualClockSamplerT8 per shot. The pack's production example is examples/production/CineTimeline-H3.json - start there rather than assembling by hand.

Real talk

This pack is new, niche, and Chinese-language-first - there's essentially zero English Reddit discussion of it, so you're on the README and the examples. The good news: the README is unusually detailed, and the node is strict in a helpful way. It will refuse invalid timelines with specific errors rather than silently doing something wrong. The bad news: "strict" means a workflow that doesn't feed it a properly-shaped timeline will just error at you. Clone the example, modify it, don't build from scratch until you've watched the default timeline_state shape work.

Also be honest about the hardware. This pack's production baseline is an INT8 ConvRot H3 model with a 32B Qwen3-VL text encoder, LightX2V LoRA, and a dual-GPU ComfyUI instance (--disable-dynamic-vram is mandatory for INT8). That is not a 4060 hobby setup. If you're here for the timeline idea but don't have the VRAM, the LTX 2.3 branch of the pack is the lighter path - the timeline works the same either way.