Mochi Resampler

This is the node that actually does the editing. Where its sibling Mochi Unsampler walks a video backward into noise, Mochi Resampler takes that noise, the original video's latents, and a target prompt, and walks forward - but with the original video holding a leash. Depending on how hard you pull that leash, you get a faithful restyle, a careful in-place change like adding a hat, or a full reinterpretation that barely resembles the source.

It outputs a SAMPLER, just like the Unsampler, and you feed it to SamplerCustom (Mochi Wrapper) for the actual generation pass. The whole pack (logtd/ComfyUI-MochiEdit) implements the RF-Inversion method - invert, then resample with guidance toward the original - and this node is the "resample under guidance" half.

The inputs that matter

Five inputs, and four of them are doing real work:

• latents - the latents of the original video. This is your reference; the generation keeps trying to come back to it.
• eta - the strength of that pull toward the original video. Higher = closer to the source. Default 0.9.
• start_step / end_step - the window of the sampling run where guidance is active. Start at 0 and the output follows the original very closely, but you won't get new objects like a hat to appear. Start later (say, 6) and the model gets room to add things - but it may drift from the video, and high values tend to blur. end_step low means more freedom/difference; high means the leash stays on longer.
• eta_trend - how guidance strength changes across that window: constant, linear_increase, or linear_decrease. The author recommends linear_decrease for most edits: strong alignment early to lock in composition and motion, loosening as the model adds your prompt's content.

That eta_trend knob is the part people skip and then wonder why their edit looks nothing like the video. Constant eta either overconstrains the whole run or flies off the rails; a decreasing ramp gives you both the source's structure and the new content.

How it works

In the source, the node calls get_rf_reverse_sample_fn with your latents, eta, window, and trend. The sampling function builds an eta_values array (zeros outside your window, then your trend shape inside it) and at each step blends two vector fields: the model's unconditional field from the target prompt, and a conditional field pointing straight at the original video's latents. It's a controlled reverse ODE - literally following the paper's Algorithm 2. Because Mochi is a flow-matching model, that blend is a well-behaved straight-line interpolation rather than the kind of hacky latent-blending people used on SD 1.5.

Wiring it up

The workflow (see example_workflows/wrapper_inversion_example.json) looks like:

1. Load video → VAE encode → Mochi Unsampler pass to get noise.
2. Mochi Prepare Sigmas → feed the result unflipped into a second SamplerCustom (Mochi Wrapper) along with your Mochi Resampler.
3. On that second pass: positive is your target prompt (this is where the edit lives), cfg can be whatever works for normal Mochi (about 4.5 is the sane default), and latents in the sampler is the unsampled noise, not the original video.

The most common failure here is skipping the flip step or flipping in the wrong pass. Unsampling needs flipped sigmas; resampling needs them not flipped. Get that backwards and the whole thing comes out as mush.

Install and caveats

Install this pack after kijai's ComfyUI-MochiWrapper (it has no Mochi support of its own and no requirements.txt):

cd ComfyUI/custom_nodes
git clone https://github.com/logtd/ComfyUI-MochiEdit

Restart, then update the wrapper if anything errors - the two repos were literally merged together by the author, so version drift between them is the classic breakage. And set expectations: Mochi is an early, VRAM-hungry video model, and this pack (November 2024) predates the Wan/LTX wave that most people moved to. It's niche, but if you specifically want to edit Mochi clips, there's nothing else quite like it.