Batch Video Metadata

Video metadata is the stuff you actually need at runtime - fps, frame count, whether the thing has an audio track - and normally it's buried in a dict you can't route anywhere. Batch Video Metadata takes the BUCKET_MANIFEST output from any video bucket node and unpacks it into fourteen typed outputs. One input, no S3 calls, pure unwrapping.

What you get

The video-specific fields are the stars here:

• fps (FLOAT) - the frame rate. Wire it into your own math or into a downstream encoder so you don't have to hard-code 24 or 30.
• frame_count (INT) - total frames. Combined with fps, that's your duration and your "is this long enough" check.
• duration_seconds (FLOAT) - self-explanatory, and handy for API responses.
• has_audio (BOOLEAN) - a real trap-avoider. Knowing whether the source carries sound before you decide to mux anything saves you a class of "why is my video silent" confusion.

Then the shared fields: key (STRING), media_type, file_format, created_at, width, height, description, tags (comma-separated), source, and derived (BOOLEAN - true if the manifest was reconstructed at load time because no stored <key>.json existed).

Why it's worth a node

A common real pattern: load a video from the bucket with Load Video From Bucket (Advanced), read fps here, and pass it straight into an Output Video Bucket (Advanced) encode so you're not guessing the source rate. Or use frame_count and has_audio to gate a branch before you spend a GPU on processing. If you're running ComfyUI as an API, this is how your caller learns what it received.

Honest take: in a one-off interactive workflow you'll rarely touch it. It earns its keep the moment you build something that decides based on the video's properties, or that reports them to an external system.

Install and gotchas

Install the pack once - ComfyUI Manager (search In-N-Out Bucket), or git clone https://github.com/littleowl/ComfyUI_In-N-Out_Bucket into custom_nodes plus pip install -r requirements.txt - then restart. It shows up under buckets/video.

Watch for the derived flag. If an asset predates manifests or its <key>.json is missing, the load node infers metadata from the file on the fly: created_at will be empty and derived true. That's expected behavior, not corruption. And remember this node only reads the manifest you hand it - if S3 was unreachable at load time, the manifest defaults and you'll see empty outputs, so verify the endpoint before blaming the unpacker.