EmbeddingPipelineCapture

The one-line pitch

Every HunyuanVideo run starts the same way: your prompt goes into the text encoder, comes out as a bundle of tensors, and vanishes into the sampler. Nobody ever looks at that bundle. EmbeddingPipelineCapture is a wiretap for it - it saves the HYVIDEMBEDS output (plus whatever metadata you attach) to disk, then hands the exact same data back so your graph keeps flowing. It's the recording half of the fblissjr/ComfyUI-EmbeddingPipelineAnalytics pack, and it's the only way to get data into the pack's analyzer node.

Why you'd reach for it

Prompt engineering on HunyuanVideo is a black box. You tweak a phrase, get a different video, and have no idea what in the prompt caused it. This node builds a structured dataset of the actual text-encoder embeddings next to the prompt, CFG, and sampler settings that produced them - which is exactly the raw material you need to compare prompt variants, evaluate how well a LoRA's training captions map to real prompts, or feed into your own analysis. The pack's author is upfront that this is early days (it's a fresh repo, "first time building one"), but the capture side already does its one job cleanly.

How it works

Drop it inline between HunyuanVideoTextEncode and the sampler. On each execution it checks what arrived: a dict with a prompt_embeds key is treated as HYVIDEMBEDS and each tensor is torch.saved to data/embeddings/ as <run_id>_<stage>_<name>.pt; a latent dict gets saved under outputs; anything else lands in outputs as JSON. If you leave run_id blank it generates one from a timestamp plus a hash of your metadata - leave it and every capture is a fresh run, or reuse the ID across multiple capture nodes to group stages of one generation. It also writes a _metadata.json beside the tensors and returns the data untouched.

The inputs that matter

• data - the HYVIDEMBEDS output from HunyuanVideoTextEncode. Required, and Hunyuan-specific; don't expect it to accept other model types.
• stage_name - name the capture point (e.g. text_encode). Shows up in the saved filenames and, later, as a row in the analyzer's plots.
• run_id - leave empty for auto-generate, or wire the run_id output from a previous capture to group multiple stages under one run.
• metadata - a JSON string (default {}). Stick your prompt, CFG, sampler, whatever you want to correlate later. If it's not valid JSON the node just saves it as a raw string instead of crashing.
• config_path - mostly cosmetic; the node resolves the pack's own config.json internally.

Outputs: data (the same HYVIDEMBEDS, wire it onward to the sampler/conditioning) and run_id (STRING - feed this into EmbeddingAnalyzer).

Installing it

Via ComfyUI Manager (search "ComfyUI-EmbeddingPipelineAnalytics") or:

cd ComfyUI/custom_nodes
git clone https://github.com/fblissjr/ComfyUI-EmbeddingPipelineAnalytics

then restart ComfyUI. No model downloads - it never touches weights, only tensors already in memory. The one heavy thing is requirements.txt: umap-learn drags in numba and llvmlite, so the first install takes a while.

Gotchas

• Where does the data go? The config's data_base_path is relative, so you get a data/ folder in ComfyUI's working directory (usually the ComfyUI root, not the node folder). Look in data/embeddings/.
• The README advertises storing to parquet/jsonl - the shipped code actually writes .pt and JSON. Fine for now, just don't go hunting for a parquet file.
• It's noisy by design: the node prints a debug block with run ID and stage to the console on every capture. Harmless, mildly annoying.
• The display name mapping in the source is keyed wrong, so the node shows its raw class name in the menu. Cosmetic, but don't be confused.
• Use the same run_id across all your capture nodes in one workflow, or you'll end up with a pile of single-stage runs you can't compare.