UV Transcode Video

You don't always need to generate anything. Sometimes you have a finished video file and you just want it in a different shape - a different codec, a different container, a different size. UV_TranscodeVideo is the pack's utility node for exactly that: point it at an input file, pick a target codec, and it runs ffmpeg to produce the output. No frame tensors, no latent space, no generation. Just file surgery.

The inputs are minimal: input_path, output_path (default transcoded_output.mp4), video_codec, audio_codec, and overwrite. The codec choices are the interesting part:

• video_codec: copy, libx264, libx265, libvpx-vp9, libsvtav1
• audio_codec: copy, aac, libopus

The word to understand first is copy. That's ffmpeg's stream-copy mode - the video (or audio) data is written through untouched, no re-encoding at all. It's effectively instant and completely lossless, and it's the right answer for a container swap: moving an h264 file from .mp4 to .mkv, say, or stripping an unwanted audio stream. The catch is that copy only works when the target container accepts the source codec as-is. Copy an h264 stream into an .mov? Usually fine. Copy h264 and ask for a ProRes "transcode"? That's not what copy means - pick a real encoder instead.

The actual encoders are where you make size/quality trade-offs. libx264 is the boring, universal, always-right default for delivery. libx265 halves the size at comparable quality but encodes slowly. libsvtav1 gets you smaller still, and it's AV1, but it's the slowest of the bunch and some players still choke on it - and it's the codec most likely to be missing from a given ffmpeg build. libvpx-vp9 is the WebM option. This is the node you reach for when a master is ready and you need a delivery copy, or when something you generated is too big to upload anywhere.

Honest limitations, because this node is thin on purpose. There's no bitrate or CRF control - you get the codec's default quality, and if you need finer control, that's a job for UV_SaveVideo's advanced_quality_args on a re-render or a plain ffmpeg command. It also won't rescale or change framerate; it's a codec swap, not a re-encode of the picture's properties. For the 90% case - "I need this in a smaller, friendlier format" - it's exactly right, and the output_path it returns is handy for logging.

The usual ffmpeg caveats apply: the binary comes from your system PATH first and falls back to the imageio-ffmpeg bundle, and if your build lacks libsvtav1 or libx265, you'll find out at run time with a clear error. And keep overwrite in mind - it defaults to true, so a mistyped output_path can clobber an existing file without asking.

Install

Installs with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/GeekatplayStudio/ComfyUI-UniversalVideoIO
cd ComfyUI-UniversalVideoIO
pip install -r requirements.txt

Restart ComfyUI and it's under UniversalVideoIO. No models, no downloads - the entire dependency surface is ffmpeg plus the pack's light Python deps.