Upload video as MP4 to WebDAV

If your video workflow ends with "now get this onto the NAS," Upload MP4 to WebDAV is the terminal node that does the encode and the upload in one shot. It takes your video_frames batch, encodes it to an H.265 (HEVC) MP4 with the av library, and PUTs it to a WebDAV server as a timestamped .mp4. It's an output node - nothing comes back out of it.

The inputs you actually set:

• video_frames - the IMAGE batch from your VAE decode. Frames are encoded in batch order, so first-to-last becomes the video.
• fps - default 24. Set this to the rate your workflow actually generated at, or the playback speed lies to you.
• crf - default 23. This is the quality/size dial: the author's tooltip says it plainly, higher CRF means lower quality and smaller file, lower CRF means higher quality and bigger file. For H.265, 23 is a reasonable default; push it down toward 18 for archival, up toward 28 when you just want it small.
• url, username, password - the WebDAV directory (filename is appended), same semantics as the image uploader.
• dufs_chunk_size_mb - default 0. Leave it at 0 unless you're uploading to a dufs server.

How it works. Frames are scaled to 0–255, encoded with the libx265 encoder in H.265/MP4 with 4:2:0 color, then uploaded. Two upload paths exist: if dufs_chunk_size_mb is 0, it's a single PUT. If it's set, the node switches to dufs's chunked-append protocol - an initial PUT followed by PATCH requests with an X-Update-Range: append header, which is how dufs builds up a large file in pieces. This is a genuinely server-specific feature: set it for dufs, and only dufs. For Nextcloud or any other WebDAV server, leaving it at 0 (plain PUT) is the correct choice - a nonzero value will likely fail against a non-dufs server.

Why H.265. Smaller files at comparable quality than H.264 - good for pushing long generations to a NAS. But H.265 has real costs: hardware support varies (many web players and browsers won't play HEVC without paying for a license), and this encode runs on the CPU via Python bindings, so a long video can take a while and peg a core. If the file is destined for the browser or a quick preview, the WebM sibling (VP9) is often the saner pick.

Gotchas:

• No GPU acceleration. The av bindings here encode on CPU. Budget the time.
• Encoding is all in memory before upload - a huge frame batch means a big buffer in RAM.
• Credentials in the workflow, same leak warning as every WebDAV node in this pack: the password ships inside the workflow metadata of anything you share. Scrub before posting.
• Filenames are timestamped; every run of the same second collides and overwrites. For batch runs, add a pause or accept the overwrite.

Install is the pack standard (Chaser's Custom Nodes, chaserhkj). ComfyUI Manager - search "Chaser's Custom Nodes" - or:

cd ComfyUI/custom_nodes
git clone https://github.com/chaserhkj/ComfyUI-Chaser-nodes

then restart. No model downloads, but this node is the reason the pack pulls in av (PyAV) - a real, sizeable dependency that ComfyUI base doesn't ship, installed automatically with the pack. The README's "use them at your own risk" framing is worth more than usual weight here, since you're handing it credentials and asking it to encode.