RopeWrapper_SwapNode

This is the workhorse. RopeWrapper_SwapNode takes a video's frames, a source face (or several), and the detection map produced by DetectNode, then runs Rope's inswapper_128 pipeline over every frame and hands you the result - as frames, or as a finished mp4 with optional audio.

The inputs that matter

• models and vm - the two outputs from LoadModels. Both go here.
• input_image - your video as an IMAGE batch, typically from VHS_LoadVideo plus an ImageBatch node.
• source_face - one or more face crops, as an IMAGE batch. This is the identity getting swapped in. Crop the face tight with a LoadImage node.
• detectResult - from DetectNode or LoadSwapInfo. The swap uses this map to know where every face is and which detected identity each one is; it doesn't detect anything itself.
• combineVideo - the big one. When True, the node streams frames straight into an ffmpeg process and writes an h264 mp4 (crf 19) with the filenamePrefix. Leave it False and you get swapped frames back in SwappedImage to combine yourself.
• frame_rate, filenamePrefix, saveOutput (output vs temp folder), and outputFrameIndex (which frame comes back as a preview image when combining).
• audio (optional) - an AUDIO tensor that gets muxed into the mp4.
• ROPE_Options (optional) - the settings blob from OptionNode.
• source_target_matching (optional) - how source faces map onto detected targets. This is the one that trips people up.

The source/target matching syntax

By default it's one-to-one: your first source face replaces the first detected identity, the second source replaces the second, and so on. When you have a specific assignment in mind, use the README's notation - semicolons separate each target face, commas separate the source indices each target should replace. 0,7;2 means "target 0 takes source faces 0 and 7, target 1 takes source face 2." The numbers refer to the identity indices DetectNode assigned in order of appearance. Left empty or as a single space, you get the simple one-to-one.

Why it combines video itself

This is the pack's one genuine quirk, and the README is refreshingly honest about it. The original plan was to reuse VideoHelperSuite's Combine Video node, but keeping every frame in memory for that path ate 20GB+ of VRAM/RAM. So the author vendored the combine logic into this node and streams frames to ffmpeg incrementally, keeping memory low. The side effect: when combineVideo is on, the finished video doesn't preview under the node - the code can't make that work, and the author says so. You find the result in ComfyUI's History list or grab the file from the output/temp directory (fileNameAndPath output tells you exactly where). Set saveOutput to True to keep it out of the temp folder.

Outputs and gotchas

Three outputs: SwappedImage (the frames - the single outputFrameIndex frame if combining), fileName, and fileNameAndPath. When combining, the node returns preview metadata rather than a big frame stack, which is another reason memory stays low.

Where people get burned: feeding a detectResult that doesn't match the current frames (changed resolution, re-extracted frames - re-detect), or expecting a preview under the node when combining. Both are features of this design, not bugs. If the swap comes out soft or wrong on Linux, the cause is usually the inswap_type choice in LoadModels, not this node.