How to estimate video processing work before accepting a job

Estimate work by probing the stored object itself, extracting actual stream properties, and mapping them to cost and risk classes before general processing workers accept the job.

Treat that step as admission control. The backend should classify a job only after the uploaded object is durably stored and addressable, then probe that exact object, turn the probe into execution classes, and persist a worker hint. That lets you reject obviously bad inputs early, send unusual media to a safer queue, and keep downstream workers from rediscovering avoidable failures.

Where is the real admission boundary?

The important boundary is not simply “before enqueue.” It is: after the bytes are stored and immutable for this job, before general processing workers accept it. That ordering matters because the ffprobe documentation says ffprobe gathers information from multimedia streams, can open and probe a URL, reports stream and container details in machine-readable form, and returns a failure if the URL cannot be opened or recognized as multimedia. Build admission decisions from that stored object, not from client claims.

Why are filename, MIME type, and declared duration insufficient?

A container tells you less than teams often assume. MDN’s media container guide explains that a media container can encapsulate one or more media streams plus metadata, and that codec choices are separate from the container itself. So .mp4 or video/mp4 is only a hint. Your estimator needs actual stream facts: video codec, width, height, timing signals, pixel format, duration estimate, and counts of audio, subtitle, and attachment streams.

This is also where you bound effort. Enforce a validator-side timeout, and if your chosen probing command does not resolve ambiguity within that budget, route the file to quarantine or manual review instead of pretending the file is normal. The ffprobe documentation says its output is designed to be easily parsed by downstream textual processing. That makes it a good fit for an admission step that relies on metadata and stream descriptors, rather than immediately running a full decode.

How should probe results become execution classes?

Use explicit rules. Start with a coarse work score from resolution × estimated frame-rate signal × duration. Then raise risk or cost when the probe shows 10-bit or unusual pixel formats, multiple audio tracks, subtitle streams, missing essential stream fields, or a stream layout that your pipeline only partially supports.

The ffprobe documentation also distinguishes usable stream configuration from incomplete stream information, noting that usable configuration requires a defined codec and essential information such as video dimensions or audio sample rate. That is a good line for routing: files that do not expose essential fields reliably should not enter your normal worker pool.

A practical outcome model is:

• normal: supported container and usable stream configuration
• heavyweight: high resolution, high frame-rate signal, long duration, or many side streams
• partial-feature: core video/audio path is supported, but some side streams will be ignored
• quarantine: probe timeout, conflicting metadata, unreadable timestamps, or uncertain stream usability
• reject: object is unreadable, not recognized as media, or has no supported end-to-end path

Do not classify by codec label alone. The ITU H.264 recommendation history shows a long sequence of revisions and additions, including added colour-space support and profiles for professional applications. In practice, stream properties are safer routing inputs than the bare string h264.

What does a worked decision look like?

Assume the stored object probes as: MP4 container; one H.264 video stream; 3840×2160; about 60 fps by the best available probed timing signal; pixel format yuv420p10le; duration 42 minutes; two audio streams; one subtitle stream.

Decision: accept the job and route it to heavyweight. If the target output format and subtitle codec are supported by your pipeline, preserve subtitles; otherwise mark subtitle handling as optional or ignored with a clear user-facing warning. The reasons are straightforward: 4K resolution, elevated frame-rate signal, 10-bit video, long duration, and extra streams all increase decode, filter, and mux work.

Persist a hint object such as:

validation_version=3; queue=heavyweight; video_profile=4k60_10bit; audio_tracks=2; subtitle_mode=optional; reasons=high_pixels,high_fps_signal,ten_bit,long_duration,multi_stream

That hint should be understood as a routing estimate, not a guarantee of exact cadence or final runtime cost. Downstream workers should consume it as the contract for this job version, rather than reprobe and drift into different decisions.

What follow-up questions matter in production?

Should the classifier decode sample frames?
Only for risky classes or when metadata-only probes routinely miss corruption in your workload.

Should unsupported subtitle or attachment streams force rejection?
No. Reject only when the core requested output has no supported path. Otherwise admit on a partial-feature path with a clear user-facing warning.

Next step: write a versioned rule table from probe fields to queue, risk, and user error codes, then make every worker trust that persisted admission result.

Reviewed: 2026-09-06.