Video Sync Concatenate (Side by Side)

This puts two clips next to each other into one frame - but the interesting part isn't the layout, it's the sync. If you concatenate two frame batches at different native frame rates without accounting for that, one clip visibly speeds up or lags relative to the other. This node resamples both to a common rate first, so the side-by-side stays aligned for the whole clip.

Why frame rate mismatch matters here

Say your source is 24fps and a generated clip sitting next to it is 16fps. Naively pairing frame-for-frame, the 16fps side will appear to move in slow motion relative to the 24fps side by the end of the clip - worse the longer it runs. This node takes each source's own fps alongside its frames and conforms both to a shared output_fps before joining them, so that drift doesn't happen.

Inputs and outputs

• images_a, images_b (IMAGE, required) - the two frame batches.
• fps_a, fps_b (FLOAT, 1–240, step 0.01, default 30) - each source's actual native frame rate.
• output_fps (FLOAT, 1–240, step 0.01, default 30) - the target rate both get conformed to.
• Outputs: image (IMAGE, the combined side-by-side batch), frame_count (INT), fps (FLOAT, the actual output rate), and info (STRING) - a summary worth wiring into a text-display node the first time you use this, to confirm the resampling did what you expected.

Installing it

No models or extra dependencies mentioned in the README. Search ComfyUI Manager for the repo name first; a small personal pack like this may not be indexed there, so the manual clone is the fallback:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist.git

Restart ComfyUI afterward.

Common issues and troubleshooting

Get fps_a/fps_b right, or the whole point of this node is defeated. If you leave either at the default 30 while the actual source is a different rate, the sync math is built on a false premise - the two halves will drift apart exactly the way this node exists to prevent. Check your source clips' real frame rates before trusting the defaults.

Uneven source lengths will show up once conformed to output_fps. The schema doesn't expose a padding, looping, or freeze-last-frame option, so if your two clips end up different lengths after resampling, expect the shorter one to simply run out first. Check frame_count and info against what you expected rather than assuming both halves stay populated to the end.

This is side-by-side, not a composite or overlay. If what you actually want is picture-in-picture or a blended overlay of the two clips rather than two frames glued edge to edge, this isn't that node - it only does the one layout its name describes.