MschA2V Beat Pixel Upscale KSampler

Here's the workflow pain this node exists to fix: you're cutting a three-minute music video, you need to iterate on timing and prompts, and every full-res H3 render takes an age on your GPU. So you drop the resolution for a fast pass, get the timing right, and then... you want the final thing to actually look big. The msch-a2v answer is MschA2V Beat Pixel Upscale KSampler - a local second pass that takes your cheap low-res shots, upscales them to 1024–1920px on the long side, and re-samples them against the same plan, without any closed 2K refiner or API call.

What it does, step by step

It's the familiar "generative second pass" idea from still-image upscaling, ported to per-shot video. For every block in your sampled latents, the node:

1. decodes that shot's video branch from latent space with the VAE,
2. pixel-upscales the frames toward target_long_side (rounded to a multiple of 32, which H3's latent grid demands),
3. VAE-encodes the bigger frames back into H3's latent space,
4. partially re-samples using the same per-block conditioning and seed as the low-res pass, so the second pass refines rather than reimagines.

That last point is the whole trick. Because it reuses the original conditioning and seed, the upscale keeps your beat-timed composition and continuity instead of inventing a new video at a higher resolution.

Why it needs both the plan and the latents

Most samplers take one of these. This one takes two - shot_plan and latent - and that's deliberate: the low-res latents output from MschA2V Beat KSampler deliberately doesn't carry conditioning, so re-sampling at a new resolution needs the plan (which does) matched by block_id. Feed it a plan and a latent set from different Shot Planner runs and it raises a clear error telling you exactly that.

The knobs you'll actually touch

• target_long_side (default 1024, up to 1920) - this sets your render ceiling. The source docstring suggests prototyping around 288px-ish short-side and pushing up from there; each step costs real GPU memory and runtime, so 1920 on a multi-minute video is a commitment.
• denoise (default 0.75) - the balance between "keep the first pass" and "add detail." Lower it to stay faithful to your low-res composition; the default leans toward generating detail. The KB's upscaling essay makes the same point for image second passes: too high and it rewrites your shot, too low and you've just paid for a blurry resize.
• upscale_method (default lanczos) - which pixel scaler runs before the re-encode. Lanczos is a fine default; bilinear/nearest-exact are there if you want a softer or blockier intermediate.
• steps (default 40) - note this, not 4 like the main Beat KSampler. A refinement pass with more steps is how you get clean detail instead of turbo-noise.
• model, vae - same H3 model and video VAE you sampled with.

Output and honest caveats

One output: latent - a new MSCHA2V_LATENTS at the higher resolution. Feed it into another MschA2V Shot Assembler and you get the final IMAGE sequence. Same assembler node, same plan, just bigger frames.

The caveat you should hear before you build a whole workflow around it: the pack's own README validation notes say pixel-upscale refinement remains untested by the author - the demo renders covered the direct generation path, not this pass. That doesn't mean it's broken; it means it's the newest, least-proven node in the pack, so verify a short upscaled clip before you queue up an hour-long render. It's also genuinely heavy: decode, upscale, re-encode and re-sample every shot means you effectively render twice.

Installing

Same as every msch-a2v node: it's an orchestration layer over comfyui-minimax-h3-audio-T8, so install that pack and load its H3 model/VAEs first. Then:

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. Note that the standalone msch-a2v repo has been superseded by the unified MSCH Nodes pack - the migration guide explains how to switch without duplicate node registrations. If your plan/latent mismatch error ever mentions it, you usually changed width, height or fps between planning and this pass - keep those consistent and it goes away.