Nodes/H3 Relay/H3RelayInternalLTXRollingCrop
ComfyUI Node

H3RelayInternalLTXRollingCrop

The node that cuts the fake padding off your LTX enhancement

By akatz-ai·Created 28 days ago·Updated 8 days ago· 15
H3RelayInternalLTXRollingCrop
  • images
  • rolling_context
  • images
  • context_frames
  • delivered_frames
  • status

When LTX enhances an H3 shot, the decoded video is longer than the delivered segment. That's not a bug - it's the padding that made the rolling context work. The enhancement window carries a tail of context frames from the previous shot plus alignment padding, and all of it has to come off after decode so you're left with exactly the frames this shot was supposed to deliver. Rolling Crop is the node that does that trimming.

The description is terse: Remove terminal LTX alignment padding after decode. It takes the decoded images and the rolling_context token that describes the window, and returns the cropped images plus three bookkeeping values: context_frames, delivered_frames, and status.

How it knows what to cut

The rolling_context is the key. It's an H3_RELAY_LTX_ROLLING_CONTEXT object created by H3RelayInternalLTXRollingInput at the start of the enhancement, and it records three numbers: how many context frames were padded in, how many original frames the H3 segment had, and how many the window will actually deliver. Rolling Crop reads those and slices images[:original] - everything after the original segment length is padding, gone.

That's the division of labor across the rolling family:

  • RollingInput builds the window and records what went in.
  • RollingInject + RollingCheckpoint handle the latent tail continuity.
  • RollingCrop handles the pixel-side cleanup on the way out.

If the decoded frame count is shorter than the original segment, the node raises a clear error rather than silently returning a truncated clip - a fail-fast behavior that keeps a misconfigured window from quietly destroying a shot.

What the outputs are for

images is the clean delivered clip. context_frames and delivered_frames are the two counts that matter downstream - in the expanded graph, delivered_frames is what the accept step records so the enhanced stream knows how much real footage this shot contributed. status summarizes the crop, e.g. how many frames came in and how many survived.

You'll never place this node by hand; it's built by H3 Relay · LTX 2× Enhance when the graph expands. If you're debugging, the useful habit is knowing it exists: when an enhanced shot looks a few frames short or long, the explanation is usually in the status string of this node or the numbers recorded in RollingInput. If the crop error fires, check the context_frames value you're feeding - it has to match what the window actually carried.

The rolling-enhancement path only earns its keep on multi-shot sequences where inter-shot LTX consistency matters. Single-shot jobs still run through it (the graph is built uniformly) but the crop is near-trivial there. Install the pack via ComfyUI Manager (H3 Relay) or clone the repo into custom_nodes; needs ComfyUI 0.32.0+, FFmpeg, and the LTX 2.5 files from MODELS.md.

Categoryconditioning/minimax/contex_loop/enhance

Inputs (2)

NameTypeDefaultDescription
imagesIMAGE
rolling_contextH3_RELAY_LTX_ROLLING_CONTEXT

Outputs (4)

NameTypeDescription
imagesIMAGE
context_framesINT
delivered_framesINT
statusSTRING