Silver H3 Video Editor (edit a section from a video reference)

This is the sibling of the pack's Segment Editor and it solves the opposite problem. The Segment Editor does pixel-exact surgery - you pick a stretch, it regenerates that stretch and the frames before and after are the originals. SilverH3VideoEditor does not splice at all: it hands H3 your clip as a reference video and asks it to re-render the whole section as something new.

So the use case is "same scene, same motion, same timing - different jacket," or "same shot, but make it night." You are not preserving frames; you're preserving the content of a shot while changing one thing about it, and the model's reference conditioning is what keeps the rest recognisable.

How it works

The section between source_start and source_end - capped at 15 seconds, H3's limit - is fed to the model as a single reference video, <Video 1>, with its soundtrack, which the tokenizer presents as a paired <Audio 1> right before it. The node prepends a fixed alignment line naming <Video 1> as the source clip so the edit instruction has something unambiguous to hang off. Then H3 regenerates the section from scratch, guided by the reference, and the output is exactly that regenerated section - no splicing, no before-and-after frames attached.

Because it's reference-driven, there are no first/last keyframes here at all. Keyframes and refs share the same conditioning slot and references win, so a ref2va-style checkpoint is required and an fl2v model will simply ignore your reference. The audio comes from the model, natively guided by the reference soundtrack - which is why there's no audio-lock machinery on this node.

Phases are the pack's usual two-swap pattern: text encoder plus both VAEs in the encode phase, one sampling pass with the DiT hot, one decode pass. source_end is snapped down to H3's 5+17k grid and the reference and output always share that exact length - ask for 15 seconds and you get 345 frames, the largest on-grid value at or below it.

The inputs

Nine inputs are required, but four of those are just the model, the CLIP and the two VAEs you'd wire anyway. The ones you think about: source_video comes from ComfyUI's input folder - the preview panel gives you a play button, an Open video upload button, and EDIT WINDOW handles to drag the section, which beats typing seconds.

video_prompt is the edit instruction. The tooltip is worth following almost literally: state what to change (subject, clothing, scene, style) and what to keep (motion, camera, timing, environment, lighting). Vague prompts here don't degrade gracefully - the model will happily re-plan whatever you didn't claim.

source_start and source_end (0 = to the end), then megapixels (default 1) for the output resolution: the whole section is resized to that total pixel count, aspect preserved as closely as the 32-pixel grid allows, resampled to 24 fps.

Optional: seed, steps, sampler_name (res_multistep), scheduler - note the default here is beta, not simple - plus filename_prefix, format and frame_compression, the H.264 CRF knob where 0 is lossless and 23 is the sane default. Output is one saved_video string, a brand-new 24 fps clip at the megapixel size with the model's generated audio.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/SilverAndJade/comfyui-silver-nodes

Restart. The H3 nodes lean on ComfyUI's PyAV and the newer comfy_api.latest video types, so keep ComfyUI reasonably current; the pack's requirements.txt covers the older loader nodes in the same pack. You need a ref2va-capable H3 checkpoint plus the H3 video and audio VAEs - and the weights themselves, roughly 42.5GB under the MiniMax H3 Community License, which excludes the US, EU, UK and South Korea from its applicable territory. There's no example workflow for this one in the repo, so expect to build the graph yourself.

The honest caveat

The author's own commit note on this node says the video embed takes precedence over the text prompt, which means the edit doesn't work as well as you'd hope - the reference is strong enough that instructing it to change things is fighting the conditioning. That's consistent with how reference-to-video models behave generally: they're better at "same thing, new angle" than at "same shot, new contents." Don't expect a Photoshop-grade retouch; expect a strong stylistic re-render that mostly respects the source.

The practical consequences: short windows work better than the 15-second maximum, one clear change beats a paragraph of edits, and it's worth comparing against the Segment Editor for the same job. If your goal is a clean, invisible patch in otherwise-good footage, keyframe regeneration with a locked audio spine is the more reliable tool. Reach for this node when you want the model to genuinely re-imagine the shot.