OmniCam Monitor

Here's the whole problem OmniCam exists for: video models fundamentally disagree about how to be told about motion. Wan 2.2's camera control wants a camera embedding built from real extrinsics. LTX wants 2D screen-space motion tracks fed to a control path. MiniMax H3 and half the closed APIs want a reference video and a prompt. Ask any one of them in the wrong dialect and you get a camera that drifts, ignores you, or moves nothing.

The OmniCam Monitor is the translator - the single exit point where an authored MotionScene (from the Director or Extractor) gets compiled into whatever representation your downstream model speaks. Pick a target_profile, and Monitor resamples the timeline to that model's frame grid, builds the artifact, runs a preflight, and hands you the right socket.

The outputs that matter - and the table you'll re-read

Monitor exposes a lot of outputs, but here's the thing that trips everyone: only the selected profile's output is computed - the rest are None. Wire the output the profile table names, or you get nothing and blame the wrong node.

| Profile | What Monitor emits | Wire it into | |---|---|---| | external_reference_video (default) | reference_video + final_prompt | any model's own reference-video input | | wan_camera_native | camera_embedding | WanCameraImageToVideo.camera_conditions | | wan_move_native | native_tracks | WanMoveTrackToVideo.tracks | | wan_track_native / wanvideo_ati | tracks_json | WanTrackToVideo.tracks / WanVideoATITracks.tracks | | ltx25_motion_track | tracks_json | LTXVDrawTracks.tracks | | h3_native | reference_frames + final_prompt | MiniMaxH3ReferenceToVideo.ref_videos | | h3_api | reference_video + final_prompt | MinimaxHailuo03ReferenceNode.reference_video |

Switching profiles never changes the MotionScene - it only changes which output carries the result.

The inputs you set

• motion_scene - the scene to compile, from the Director or Extractor (or any third-party node emitting OMNICAM_MOTION_SCENE; Monitor watches the socket type, not the node).
• playblast_video - the shot's proxy. Reference-video profiles require it, and every profile uses it for the preview. If it's stale you'll see PLAYBLAST OUTDATED - re-record it upstream rather than shipping old footage.
• base_prompt - your actual intent (subject, style), kept at the head of final_prompt. Don't describe camera moves here; that's what the scene is for.
• target_profile - defaults to external_reference_video, the permissive catch-all for any model OmniCam has no named profile for (Seedance, Kling, Veo, a private API). It imposes no frame grid, no fps conversion, never blocks. The named profiles are strict by design.
• duration_seconds / target_fps - set to 0 (default) they inherit the shot you authored upstream, so you don't re-type the Director's numbers. target_width/target_height are the target frame size.

Preflight isn't decorative - it's the feature

Before compiling, Monitor checks that the payload can actually reach its destination, and it blocks the queue when it can't. A multi-shot edit (a cut to a second camera) is rejected for single-camera profiles like wan_camera_native - one embedding can't describe an edit. Reference-video profiles accept cuts because the playblast carries them. Trajectory formats that can't express "layer hidden at frame 1" get those layers dropped, with their names reported. And if the node your chosen profile targets isn't installed (say, LTX for ltx25_motion_track), it stops with a clear reason instead of producing a payload with nowhere to go. Annoying at first, genuinely useful once you've had a silent-broken-output afternoon.

Install

Same pack as the Director and Extractor: ComfyUI-Majoor-OmniCam, needs ComfyUI 0.31+, no extra Python deps. Manager → search Majoor OmniCam, or:

cd ComfyUI/custom_nodes
git clone https://github.com/MajoorWaldi/ComfyUI-Majoor-OmniCam.git

Restart, and it sits under Majoor › OmniCam. The profile set is experimental - the pack explicitly says no profile is real-model-certified yet, so pin versions if you build a production workflow on it. Ready-made graphs per model family live in the repo's examples/workflows/, each one the official template for that model with the motion source swapped for OmniCam. That's the fastest way to see a profile correctly wired end to end.