CineTimeline｜导入视频续接缓存

For when the clip you want to continue from wasn't made in this session

Video continuation normally works the tidy way: the renderer saves the sampler's AV latent alongside the segment, the next segment reads that exact file, and everything lines up. But a real project doesn't stay that tidy. You've got a clip from three weeks ago, or from a different model, or one you trimmed in a video editor, and you want the timeline's motion-context continuation to pick up from that.

CineImportAVCache builds a continuation cache out of a finished video. It is, honestly, a reconstruction: it decodes the tail of an existing file, re-encodes it through the H3 VAEs, and saves it as a motion-context latent the next segment can load. The author says so plainly in the release notes - these caches reconstruct the visible tail; they are not the original sampler latent. Knowing that is the difference between using this node well and expecting magic from it.

What it does, step by step

You give it video_vae, audio_vae, asset_id, version_id, width, height and duration. That's the whole interface.

It checks the file is genuinely 24 fps (container average rate within 0.01, and it fails with 续接缓存要求24fps视频 if not - no silent resampling), then decodes frames while keeping a rolling window of the last 39. Frame count is verified by decoded frames, not by the container's claimed duration, and up to six surplus frames (0.25 s) are accepted and trimmed into a normalized copy while the original is left alone. It resizes every tail frame to the width and height you supplied, which is why changing resolution means rebuilding the cache - a latent can't be implicitly resized.

Audio comes from ffmpeg: the matching 39/24 seconds of the tail, converted to stereo float32 at the audio VAE's own sample rate (32 kHz on the pack's H3 baseline). If the clip is short on audio it pads rather than errors, though a file with no audio track at all fails outright - you can't build an AV cache from a silent video. The 39 video frames must encode to exactly 12 latent frames, so a mismatched VAE errors instead of producing a plausible-looking cache.

The result is saved through MiniMaxH3MotionContextSaveLatent into CineTimeline/Latents/imported/<uuid>, and the node returns a small JSON blob as ui.text: the asset_id, version_id, width, height, the relative latent_path and a latent_sha256. That hash is what the timeline uses to keep a cache tied to the asset and version that requested it, instead of whatever shot happens to be selected when it finishes.

No outputs, on purpose

There is nothing to wire. This is an output node with an empty return tuple, so it appears in the graph as a terminal, run-it-and-read-the-panel node. That trips people up - you queue it, see nothing on screen, and assume it failed. The JSON is in the node's UI text output.

One more behaviour worth planning around: its IS_CHANGED returns NaN, meaning it re-executes on every queue no matter what. For a node that decodes a file and does two VAE encodes, that's real work. Don't leave it parked in the middle of a working graph.

Installing it

Manager: search CineTimeline. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/bo341805sg/ComfyUI-CineTimeline
# restart ComfyUI, hard-refresh the browser

This is the most dependency-hungry node in the pack, and none of it comes from the pack's own metadata. You need PyAV and imageio-ffmpeg (a working ffmpeg binary), the H3 video and audio VAEs, and the separate GPL-3.0 ComfyUI-H3-Motion-Context plugin for the latent save. Missing any of them, you find out at execution.

Errors, translated

• 续接缓存要求24fps视频 - the file isn't 24 fps. Re-encode it first; the node will not guess.
• 导入片段有效范围不足，未建立缓存 - fewer decoded frames than duration implies, or fewer than 39 frames of tail. duration's minimum of 1.625 s is exactly 39 frames at 24 fps, which is the floor.
• 无法读取尾部音轨；没有音轨的视频不能自动建立音视频续接缓存 - silent source.
• 视频VAE尾部帧网格不匹配 - the video VAE didn't produce 12 latent frames for a 39-frame window. Wrong VAE.

And the honest framing on quality: continuing from an imported clip gets you motion continuity, not sample continuity. If the seam still reads slightly off compared to continuing from a real first-pass latent, that's expected - keep the native latent when the clip is yours.