Djz Datamosh V4 (Style Transfer)
Transplant motion vectors between two clips
- target_images
- source_images
- IMAGE
This is the node that actually datamoshes. Not "make it look glitchy" - the real deal: it takes the motion vectors from one sequence of frames and shoves them into another, the same trick the classic glitch-art videos of the 2010s used by mangling MPEG compression. If you've seen footage where a face melts into a smear that keeps the movement of a completely different shot, that's this effect. It lives in the DJZ-Nodes pack as V4, styled "Style Transfer," and it's the one version of the datamosh family that demands the most of you in return.
How it works
The node treats your two image batches as video. It encodes the source clip to MPEG-2, extracts the per-frame motion vectors (the compressed "where did this block move" data), and then re-encodes the target clip while a generated JavaScript filter adds or replaces the target's own motion vectors with the source's. MPEG decoders only care about vectors, not where they came from, so the target's pixels get dragged around as if they were following the source's movement. Result: the glitch-smeared style transfer you were after.
That's also where the trap is. DjzDatamoshV4 does this by shelling out to ffgac and ffedit - two external binaries that are not pip packages and are not mentioned in the pack's README. They come from the ffedit/ffgac fork of ffmpeg used for motion-vector work. Install the pack and the node will quietly not have these tools until you grab them and put them on your PATH. Regular ffmpeg is needed too, for converting the result back to frames - ComfyUI's portable build ships one.
The inputs that matter
- target_images and source_images - the batch that receives the effect and the batch the motion comes from. Frame counts should roughly match; vectors are per-frame.
- mode -
extract_and_transferdoes everything in one go;extract_onlyjust saves vectors for later;transfer_onlyloads a saved vector file and applies it to new targets. The middle option is how you reuse one cool motion from a good clip on many different targets without re-encoding. - vector_file - filename for saved vectors, stored under
ComfyUI/custom_nodes/motion_vectors/in the repo'svectors.jsonformat (default name). - method -
addmixes the source motion into the target's own motion;replacewipes the target's motion entirely. Replace is the more aggressive, more melted look. - gop_period - group-of-pictures length in frames. The default 1000 basically means one long group, so errors persist and smear for the whole clip. Lower it (say 12–30) for more frequent keyframe resets, which cuts the corruption into shorter bursts.
Output is a single IMAGE batch of the glitched frames.
Troubleshooting
The failure mode is silent: if extraction or the ffgac/ffedit step fails, the node prints something like Failed to extract motion vectors to the console and returns your target unchanged. If transfer_only can't find the vector file, same deal - you get the original frames back. So the first thing to check when "nothing happened" is the console, and the second is whether ffgac and ffedit are actually on your PATH. Everything else - the motion vectors, the JS filter - is handled for you, but those two binaries are the difference between melted video and a confused no-op.
For everyone else in the pack, V5, V6 and V7 do the look of glitch without leaving your Python environment. This one is the genuine article, and it's worth the setup if you want the real thing.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| target_images | IMAGE | — | |
| source_images | IMAGE | — | |
| mode | COMBO | 3 options: extract_and_transfer, extract_only, transfer_only | |
| vector_file | STRING | vectors.json | — |
| method | COMBO | 2 options: add, replace | |
| gop_period | INT | 10001–10000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |