DMXAPI MiniMax 多模態參考生影片

Generating a video of a specific subject is normally a prompt problem that you lose. This node makes it a reference problem instead: hand MiniMax H3 a picture of the person, a clip of the motion, an audio file of the voice, and let it copy what it needs. The node is DMXAPI MiniMax 多模態參考生影片 - "multimodal reference-to-video" - and it's the same hosted H3 model as its sibling in this pack, pointed at a different upstream interface.

It's H3's answer to character consistency at a fraction of the setup cost of a local identity pipeline - with the usual API-node price: per-call billing, your reference material leaving the machine, and someone else's content filter.

The one rule that shapes the whole node

Reference material and first/last frames are mutually exclusive. Upstream says so explicitly: if the request contains any reference_* item, it cannot contain a first_frame or last_frame. That's why this node has no frame inputs at all - not an oversight. If your shot needs a specific opening frame, use DMXAPI MiniMax 影片生成 instead; if it needs a specific face and a specific voice, you're in the right place.

The other hard rule: reference audio can't stand alone. One or more images, or one or more videos, must be in the mix. Images alone are perfectly legal.

The inputs

prompt (required, up to 7000 characters) is where you point at your material. You can name items directly - say "音色參考音頻 1" (voice reference audio 1) - and H3 will use the matching reference. Send no references at all and the node errors out and tells you to use the video-generation node instead.

The reference inputs come in pairs, local socket first, URLs second:

• reference_images (IMAGE, batch) plus reference_image_urls - 9 images total, embedded locally first. Each frame is JPEG-encoded with the long side capped at 2048 and inlined as a data URI.
• reference_video_1…_3 (VIDEO, works straight off a Load Video node) plus reference_video_urls - 3 clips total. MP4 and MOV pass through untouched; other containers get transcoded to MP4/H.264 and the source audio track comes along.
• reference_audio_1…_3 (AUDIO, from Load Audio) plus reference_audio_urls - 3 clips total. First item of the batch, converted to PCM16 WAV.

resolution is 768P or 2K, duration is 4–15 seconds, and noise_seed is a cache key rather than a seed (H3 isn't reproducible; the author tested it). prompt_optimizer rewrites and expands your prompt first - nice for a one-liner, actively unhelpful when your prompt is a careful list of which reference does what, so turn it off for this node. download_video, max_frames, save_dir, poll_interval and max_wait behave exactly as they do on the sibling video node: keep max_frames at 0 unless you're post-processing frames, and raise max_wait well above its 900-second default for 2K output, because timing out means the job is still running and still billed.

ratio is the one input that differs from the sibling video node: here it defaults to adaptive - the upstream picks the aspect from your reference material - and it's actually sent. Force 16:9 or another value if you want to.

Six outputs, same contract as every video node in the pack: VIDEO, IMAGE_FRAMES, LAST_FRAME, VIDEO_PATH, VIDEO_URL, TASK_ID.

Limits you'll meet in practice

These come from the upstream contract, and the node enforces or warns about them locally:

• Reference images must be 256–5760 px on a side with an aspect ratio between 0.4 and 2.5; out of range gets a console warning, and the real rejection happens upstream.
• Local video and audio clips must each be 2–15 seconds, with video and audio each totalling no more than 15 seconds. A single local video caps at 50 MB, a single audio at 15 MB.
• The whole JSON body - post-base64 - caps at 64 MB. This is the real ceiling. Four images, three video clips and three audio files inlined will blow through it long before the per-item limits. When you're close, move the big items to public URLs and let the provider fetch them.
• When local sockets fill their quota, extra URLs get truncated with a console warning rather than silently ignored - check the log if a reference doesn't seem to be having any effect.

Installing

Manager → search DMXAPI, or the usual clone:

cd ComfyUI/custom_nodes
git clone https://github.com/mch000534/ComfyUI-DMXAPI
/path/to/ComfyUI/.venv/bin/python -m pip install -r ComfyUI-DMXAPI/requirements.txt

Restart afterward. Nothing to download - no H3 weights, no VAE, no text encoder. That's the whole point of the API route: H3 is a 33B omni-modal model whose weights are additionally licence-restricted out of the US, EU, UK and South Korea, and none of that applies when you're calling someone else's endpoint.

Key resolution: node api_key field, then DMXAPI_KEY, then MINIMAX_API_KEY from your .env. Note the order - a value typed into the node beats everything, so a stale key there will keep shadowing your environment.

Where people get burned

"Only a reference audio" errors. Expected. Add an image or a video.

Frames plus references in one workflow. You can't use both, and you can't even wire a first_frame into this node - the input doesn't exist. The usual mistake is building the wrong node and then wondering why the reference material was ignored.

Blowing the 64 MB body. Local media is base64-inlined, so it grows by roughly a third on the way out, and big reference clips are the usual culprit. URL inputs dodge it entirely.

A first run that takes longer than you expect. More references means more for the upstream to chew on, so raise max_wait before you retry - there's no way to retrieve a timed-out task later, and a timeout is money spent for nothing.