Nodes/msch-a2v/MschA2V Shot Assembler
ComfyUI Node

MschA2V Shot Assembler

Where your sampled shots stop being latents and become the actual video

By mariobilly·Created a day ago·Updated a day ago· 0
MschA2V Shot Assembler
  • latents
  • vae
  • images

By the time you reach MschA2V Shot Assembler you've done the hard parts: sequenced prompts to a beat, planned shots, and burned GPU time sampling each one. But what MschA2V Beat KSampler hands you is still a pile of latent tensors, each one a padded render window of a single shot - not a video. This node is the seam where that pile becomes an IMAGE sequence you can actually encode and watch. It decodes each shot with the video VAE, trims the padding away, applies the fades and crossfades your plan calls for, and concatenates everything into one frame-perfect batch.

What it does under the hood

Two inputs, no visible knobs - latents (the MSCHA2V_LATENTS output from the Beat KSampler) and vae (the H3 video VAE). That's the whole interface, and it's the right call: everything that could be tuned - timings, fades, overlaps - was already decided back in the sequencer and baked into the plan.

Per shot it:

  • decodes the video branch only. No audio VAE needed here, and that's a deliberate design decision you should understand because it explains the audio wiring below.
  • trims the model's padded render window down to the shot's exact real frame count (block_len_frames).
  • applies fade-in and fade-out ramps where the plan says a shot should dissolve.
  • hard-concatenates blocks that belong to the same visual group - continuity there comes from shared conditioning built at planning time, not from frame-by-frame image-to-image chaining.
  • alpha-blends a crossfade across shot boundaries, where one shot ends and a new one begins.

Then it checks its work: if the assembled frame count doesn't match the total the plan promised, it raises a ValueError telling you so. The message is worth reading - it usually means width, height or fps changed between planning and assembly, or you hand-edited schedule_json after the shot plan was compiled. Both of those silently break timing, and this node is the one that catches it.

The part people find confusing: where's the audio?

You might expect this node to output audio too. It doesn't - just images. The final soundtrack for the rendered video is always the original song, wired directly from MschA2V Beat Prompt Sequencer's audio output (or MschA2V Load Audio Path) into your video encoder. The author deliberately chose this over decoding per-shot generated audio and reassembling it, because round-tripping through H3's audio VAE tends to leave seams and artifacts between shots. So the mental model is: msch-a2v is a music video orchestrator, and in a music video the music is the one thing you don't regenerate.

That means the correct wiring at the end of the chain is:

  • this node's images → your Video Combine / Save Video node's image input,
  • the sequencer's audio → that same encoder's audio input,
  • encode, done.

If you ran the pixel-upscale second pass, you run this same node again on the upscaled latents - no different assembler needed.

Installing and troubleshooting

Installation is the pack standard: it's an orchestration layer over comfyui-minimax-h3-audio-T8, so that H3 pack plus its model and VAEs must be installed first; this repo's own requirements are only numpy, librosa and soundfile.

cd ComfyUI/custom_nodes
git clone https://github.com/mariobilly/msch-a2v.git
cd msch-a2v
python -m pip install -r requirements.txt   # same Python as ComfyUI

Restart ComfyUI. Worth knowing up front: the standalone msch-a2v repo is superseded by the unified MSCH Nodes pack - follow its migration guide if you switch, so you don't register the same nodes twice.

The failure mode you're most likely to hit is the frame-count ValueError above, and it's almost always self-inflicted: re-run the Shot Planner if you change resolution or fps, and treat schedule_json as plan data, not a scratchpad. The assembler only decodes video, so if something looks like it's stalling on "audio," that's not this node - it's whatever you've got hanging off the audio wire further downstream. And because every shot gets decoded and blended here, this is also where memory spikes: a long multi-shot render at high resolution is the point where VRAM habits from image work stop applying.

CategoryMschA2V

Inputs (2)

NameTypeDefaultDescription
latentsMSCHA2V_LATENTS
vaeVAE

Outputs (1)

NameTypeDescription
imagesIMAGE