Video Resize + Pad
Resize and pad to an exact canvas — the aspect-ratio fixer
- video
- video
- output_path
- summary
MKRVideoResizePad resizes a clip to an exact canvas size and, when the source aspect ratio doesn't match, pads or crops to fit - the "my video is the wrong shape for the deliverable" fix. Nine times out of ten you reach for this because a platform, a client, or a composite needs exactly 1920×1080 (or 9:16, or whatever) and your footage isn't that shape. It writes a re-encoded file at the exact dimensions you asked for.
The mechanism is the standard resize/letterbox dance, per frame. fit_mode is the decision that matters:
contain(default) - scale to fit inside the target canvas and fill the leftover bars withbackground_color. This is the letterbox/pillarbox mode. The safe default.cover- scale to fill the canvas completely, cropping off the overflow. You lose edges, but no bars. Best when the target aspect is close and you can afford to crop.stretch- scale to the exact dimensions, distorting if aspects mismatch. Only for when you genuinely don't care about the distortion (or the mismatch is tiny).
Then anchor picks where the image sits inside the canvas when it doesn't fill it - 9 positions from center (default) through top_left, bottom_right, etc. The remaining inputs are the usual suspects: background_color (hex, default #000000), resample (bicubic default, bilinear, lanczos, nearest), plus video, fallback_fps, output_format, filename_prefix, subfolder, overwrite.
Outputs: video (MKR_VIDEO payload), output_path, summary.
Install
Part of MKRShift Nodes - install the pack:
cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes
or ComfyUI Manager → search MKRShift_Nodes → restart. mp4/mov/webm needs system ffmpeg on PATH; gif/webp work without it. No pip dependencies.
Where people get burned
The most common mistake is using stretch to "just make it fit" and then wondering why everyone looks squished - that mode distorts by design. contain with a background color is the default for a reason. Second: background_color is a hex string like #000000 or #FFFFFF - a plain color name or an RGB tuple will not parse and can fall back in ways you don't want. And remember the resize is applied to every frame and re-encoded, so this is a render pass, not a preview - on a long 4K clip, budget the time. Also the usual: no audio carried through.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| video | * | — | |
| target_width | INT | 128016–8192 | — |
| target_height | INT | 72016–8192 | — |
| fit_mode | COMBO | contain | 3 options: contain, cover, stretch |
| anchor | COMBO | center | 9 options: center, top, bottom, left, right, top_left, +3 |
| background_color | STRING | #000000 | — |
| resample | COMBO | bicubic | 4 options: bicubic, bilinear, lanczos, nearest |
| fallback_fps | FLOAT | 24.01–240 | — |
| output_format | COMBO | auto | 6 options: auto, gif, webp, mp4, mov, webm |
| filename_prefix | STRING | MKR_resize_pad | — |
| subfolder | STRING | — | |
| overwrite | BOOLEAN | false | — |
| filename_labelopt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| video | MKR_VIDEO | — |
| output_path | STRING | — |
| summary | STRING | — |