JR MiniMax H3 Director PIPE Unpack

The JR MiniMax H3 Director PIPE is an immutable bus: one custom wire carries your prompt stages, timeline metadata, media descriptors and registry JSON from the Builder (or Director Desk) all the way down to Directed Video Conditioning. It's tidy - and it's also a black box. JR_H3_DirectorPipeUnpack is the inspection hatch. It passes the pipe through unchanged and spills out everything that's inside it as plain sockets you can read, log, or feed into standard ComfyUI nodes.

The one thing to understand: it never mutates

The first output is the identical PIPE object you put in. Same object, same contents, no copy. The Unpack node is a window, not a fork - whatever it hands you on the side is a view of the bus, and the bus keeps flowing downstream untouched. If you're used to unpack nodes that let you edit-and-repack, unlearn that here: this one is deliberately read-only, and that's the entire point. The debug tax on pipe-based workflows is not being able to see what's inside; this node exists to fix exactly that.

What comes out

Seventeen outputs, which is a lot of sockets, but they cluster into four groups:

• Prompt stages - director_prompt, optimized_prompt, reviewed_prompt, plus the final prompt which resolves them with the pack's fixed priority: reviewed > optimized > director. That's the exact text that'll drive conditioning, so this is where you confirm what actually made it through.
• Timeline metadata - duration_seconds, fps, width, height.
• Media by index - first_frame, last_frame, then reference_image, reference_video, reference_audio, driving_audio, each selected by a 1-based index widget. If an index doesn't exist, that media output is None - intentional, not a bug.
• Inspection - registry_json (labels, family, role, timing, direction and notes, no binary) and a status string.

The index trick worth knowing

The index widgets are how you pull individual standard media out of the bus: reference_image_index (1–9), reference_video_index (1–3), reference_audio_index (1–3), driving_audio_index (1–3). Need two reference images as separate IMAGE sockets? Don't fight the node - just add a second Unpack with a different index. The pipe carries everything losslessly, so one Unpack per thing you want to pull is the intended usage.

JR_H3_DirectorPipeBuilder -> JR_H3_DirectorPipeUnpack
  pip  (passthrough) --------------------------------> Prompt Optimizer
  prompt / optimized_prompt --------------------------> text display or logger
  reference_image (index 1) --------------------------> standard IMAGE consumers

Where this earns its keep: debugging. When the Prompt Optimizer produced something you didn't expect, or Review replaced the text, the Unpack node shows you each stage side by side. It's also the bridge that lets standard ComfyUI nodes consume media that lives inside a PIPE, without abandoning the bus.

Installing it

Same pack as everything else here - JR MiniMax H3 (Goldlionren/ComfyUI_JR_MiniMaxH3Node). ComfyUI Manager → search "JR MiniMax H3", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node.git
<ComfyUI-Python> -m pip install -r .\ComfyUI_JR_MiniMaxH3Node\requirements.txt

That pip line is the one that actually matters - use the exact Python your ComfyUI runs on, or the nodes load and the pack's imports silently miss. Dependency footprint is light (imageio-ffmpeg>=0.5), and neither Builder nor Unpack touches models, CUDA, network or FFmpeg at import time, so installing the pack for this node alone is safe. Restart ComfyUI after.

Troubleshooting

The None outputs are the thing that trips people up: an index of 2 with only one reference image gives you None, not an error - check status to see the selection summary. File-backed audio decodes during execution, but file-backed VIDEO stays lazy until a downstream node actually asks for components, so don't expect a thumbnail on the socket. And if a downstream node insists the PIPE is the wrong shape, you've probably wired a Director Desk pipe and a Builder pipe into the same chain - they're the same type but different timelines, so keep each chain on one origin.