Cloud Video Upload Issues...

[spiritform]

Comfy Cloud: LoadVideo widget enum can't see files uploaded via /upload/image (or comfy upload CLI)

Summary

Third-party apps that submit workflows to Comfy Cloud can upload images for LoadImage-referenced widgets using the documented POST /api/upload/image endpoint (or comfy upload --where cloud), and everything works — the uploaded filename shows up as a valid enum option for LoadImage widgets and the workflow runs.

The same endpoint accepts video files (per the docs and comfyanonymous/ComfyUI server.py:image_upload()), returns a {name, subfolder, type} envelope, but the uploaded filename never appears in LoadVideo's enum — so any workflow that references a user-uploaded video via LoadVideo fails validation with:

{"code": "workflow_unknown_nodes",
 "message": "Workflow has 1 validation error(s) against cloud",
 "hint": "node <id>: '<subfolder>/<hash>.mp4' not in 1 known options for file
          (did you mean: bedroom.mp4?)"}

bedroom.mp4 is a video previously uploaded via the Cloud web UI's LoadVideo "choose file to upload" button, which registers the file with a different (proprietary) asset service. That service's contents populate the enum.

This makes any video-conditioned partner workflow (Seedance 2.0 Reference-to-Video, Depth Anything 3 Video, Kling motion-control, etc.) unreachable from third-party clients using the public CLI/HTTP surface.

Repro

1. Fetch canonical R2V template: templates/api_seedance2_0_r2v.json from Comfy-Org/workflow_templates
2. Inject a LoadVideo node wired to ByteDance2ReferenceNode.video_1 (input slot 2, socket type VIDEO)
3. Upload a .mp4 (any valid one — 720p, mp4/h264, 5s, 30fps) via comfy upload <path> --where cloud
4. Patch the injected LoadVideo's file widget with the returned cloud_name
5. Submit via comfy run --where cloud --workflow <patched.json>

Expected: workflow runs, uses uploaded video as video_1 reference.
Actual: validation fails with unknown_enum_value for the file field.

Same repro with the direct multipart POST /api/upload/image (all four form fields: image, type=input, overwrite=true, and subfolder=video) fails identically.

What was tried

Attempt	Result
comfy upload --where cloud (returns cloud_name)	file uploads, LoadVideo enum unchanged
Direct POST /api/upload/image with subfolder="video"	file lands at video/<hash>.mp4, LoadVideo enum unchanged
Widget value with subfolder prefix (video/<hash>.mp4)	same enum error
Any of the other _KNOWN_SUBFOLDER_TAGS from app/assets/services/path_utils.py:9 (3d, pasted, painter, threed, webcam)	none tag files as video
type="video" on the upload form	server coerces to input (per server.py:get_dir_by_type)

Root cause (as best I can tell from OSS source)

Cloud's LoadVideo.file widget enum is not populated from ComfyUI's own folder_paths scan of input/. It's populated from a proprietary asset catalog that only receives entries via:

1. The Cloud web UI's per-widget "choose file to upload" button (unknown endpoint)
2. Explicit partner-nodes like ByteDanceCreateVideoAsset (which internally calls upload_video_to_comfyapi → POST /customers/storage → an SDK-scoped signed-URL PUT → then POST /proxy/seedance/assets)

Neither path is reachable from comfy CLI or POST /api/upload/image.

Suggested fixes

Any one of these would unblock third-party integrations:

1. comfy upload --kind video (or --type=video) flag — take a hint from the client, tag the asset appropriately in Cloud's catalog so LoadVideo's enum picks it up.
2. Expose the Cloud web UI's per-widget upload endpoint publicly (whatever it is), and document it alongside POST /api/upload/image. Point third-party clients at it.
3. A LoadVideoFromUrl core node analogous to LoadImage but that fetches a signed URL at runtime — combined with the already-public POST /customers/storage this would give clients a full upload path without needing enum registration.
4. Automatic mime-type-based tagging in the ingest pipeline (app/assets/services/ingest.py): if the uploaded file's mime_type starts with video/, add a video tag so the LoadVideo enum picks it up. This would make the existing POST /api/upload/image work uniformly across media types.

Workarounds attempted

• Extract first frame → use as image_1. Works, loses motion signal but Seedance runs.
• Full CreateVideo chain (extract N frames → N LoadImage nodes → batch → CreateVideo → ByteDanceCreateVideoAsset → asset_1): mechanically possible but requires ~150 injected LoadImage nodes for 5s@30fps and a first-time H5 verification step for CreateVideoAsset's group_id. Not viable as a background/programmatic path.

Environment

• comfy-cli (whatever ships in a recent Comfy Desktop bundle)
• Cloud ByteDance2ReferenceNode (comfy_api_nodes/nodes_bytedance.py:2098)
• Third-party app in Python, POSTing multipart form to <cloud_base>/api/upload/image

Impact

Blocks any third-party editor / pipeline that wants to feed user-recorded or programmatically-generated video into a video-conditioned Cloud partner node. Currently the only way for our users to run Seedance 2.0 R2V with their own footage is to drag-drop it into the Cloud web UI manually, which defeats the purpose of an app-driven workflow.

[dosubot]

This is a well-documented issue. The comfy-cli codebase confirms the gap you've identified — the comfy upload command treats all files identically via the /upload/image endpoint with no media-type distinction [1], and there is no --kind or --type flag to tag uploads as video.

Internal documentation also explicitly notes this limitation:

"pushed images appear in LoadImage's choices, pushed videos are not yet catalogued for LoadVideo on cloud, so the cross-job video handoff requires local assembly today" [2]

So this is a known gap in the cloud asset catalog — video files uploaded via the public CLI/HTTP surface are not registered with the proprietary asset service that populates LoadVideo's enum.

There are actually two separate upload systems in comfy-cli [3]:

1. Transfer upload (comfy upload) — uses POST /upload/image, lands files on the server filesystem
2. Generate upload — uses POST /customers/storage with signed URLs, used for the generate API's reference assets

Neither currently bridges into the video asset catalog that LoadVideo reads from.

Your suggested fix #1 (a --kind video flag + catalog tagging) and #4 (automatic mime-type-based tagging) both align well with how the code is structured — mimetypes.guess_type() is already called during upload [4], so the mime information is available; it's just not used to route the asset into the right catalog.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mattmillerai]

Thanks for this — the repro, the "what was tried" matrix, and the root-cause section made triage genuinely fast. Confirming the gap is real, and that you've diagnosed it correctly.

What I verified on the comfy-cli side (at 8f0967b):

• comfy upload posts to upload/image and has no media-type concept — there's no --kind or --type flag anywhere on the command.
• mimetypes.guess_type() is already called in transfer.py, but only to set the multipart part's Content-Type. Nothing downstream reads it to route or tag the asset. So the information you'd need for your suggestion Implement boilerplate code for tracking events with Mixpanel #4 is already in hand at the client, just unused.
• comfy_cli/command/generate/upload.py is a genuinely separate upload path from comfy upload, as the earlier comment noted. Neither one registers into the catalog that populates the LoadVideo enum.

Your read on _KNOWN_SUBFOLDER_TAGS is also correct — it's in core ComfyUI's assets layer and it carries no video tag (nor image), so none of the subfolder values you tried could have worked.

One correction to set expectations, because it changes what a fix looks like: a comfy upload --kind video flag on its own would be inert. The enum isn't populated from the CLI's view of the world, so a client-supplied hint does nothing until the server side honours it. That makes the CLI flag the last step of a fix rather than the first, and it's why this isn't something we can land purely in this repo.

Where it's going. I've filed this internally with your four options captured as-is. The two we're weighing:

• Mime-type-based tagging at ingest (your Implement boilerplate code for tracking events with Mixpanel #4) — the cleanest outcome, since POST /api/upload/image would then behave uniformly across media types and no client changes are needed at all.
• Documenting a supported programmatic upload path for video (your Unable to install #2, in spirit) — less elegant, but a much shorter road to unblocking you.

I'm leaving this issue open to track it, and I'll report back here.

One question, since it affects which we do first: if a documented HTTP upload path landed that registered the video correctly but required a second call (upload, then register), would that unblock your pipeline? Or is a single-call comfy upload-shaped path important to how your app is structured?

In the meantime your first-frame workaround is the pragmatic one. The full CreateVideo chain is technically the supported programmatic route today, but I agree ~150 injected nodes for a 5-second clip isn't a real answer.

[spiritform]

Thanks Matt! You may have seen the popular workflow examples that show a blockout style animation from Blender being used to control a seedance video with a first frame... https://x.com/reidhannaford/status/2070507963429671062?s=20

Image to video works, but does not give you that extra level of control you have with a video reference.

This open source app that I'm developing (ComfyBlockout) integrates the new Comfy MCP/CLI to connect to cloud and run various workflows. I ran into this wall trying the seedance partner node, which is really what this entire app is based on.

Here's a short video that just shows the ComfyBlockout UI and basic UX... making a simple camera path / viewport blockout to be used as a video reference. https://drive.google.com/file/d/1vI9psBIgVg_NwkdnuwGZXrpsA1w5TBi6/view?usp=drive_link

I have been posting about ComfyBlockout on X if interested... https://x.com/spiritform/status/2072384622424711460?s=20

Let me know if you have any questions or want to discuss in person... thanks for looking into this!!

B

[spiritform]

That didn't really answer your question, but I just wanted to sort of give you more context to what I'm trying to do. I'm not sure how it should be handled on the Comfy end of things. I just want to be able to send a video reference in seedance through cloud like I would an image.... the inputs are on the node, so it seems like it should work the same way. Open to all suggestions.