Per-job overrides
Deliver one job at a different resolution or into a different wrapper without editing the preset everyone else relies on.
Most jobs should use a preset unchanged; presets exist to make output repeatable. Occasionally a single delivery requires different settings, and editing the shared preset to produce it degrades the reliability of the library for every other user.
Overrides are output settings that apply to a single submission and leave the preset itself untouched. They live on the submit flow's Advancedstep, grouped into collapsible sections, and each control reads "preset default" until a value is set.
Overridable settings#
| Setting | Notes |
|---|---|
| Container | MP4, MOV, MKV or MXF. |
| Codec | Only codecs valid inside the container in effect. Changing the container narrows the codec list rather than leaving an invalid pair selected. |
| Resolution | A fixed output frame size. |
| Frame rate | A fixed output rate. See the chunking section below before setting this value. |
| Quality mode | The rate-control strategy: constant quality (CRF) or a target bitrate. The mode determines whether the bitrate control below applies. |
| Bitrate | A target video bitrate, applied in bitrate mode. Changing resolution populates a suggested bitrate scaled by pixel count; the suggestion is a starting point and remains editable. |
| Audio codec | Only audio codecs the container in effect can carry. |
| Audio bitrate | A target audio bitrate. |
| Audio sample rate | A fixed output sample rate. |
| Audio channels | The output channel count. |
In constant-quality mode the encoder holds visual quality constant and file size varies with the content; in bitrate mode the target bitrate governs and size is predictable. The two strategies are exclusive on a job: selecting constant quality makes the video bitrate target inapplicable.
Every value is re-checked on the server at submit. A combination that cannot be honoured is refused before the job is accepted, rather than encoded into something other than what was requested.
Effective specification#
An override is not a second set of instructions layered on top of the preset. At submit, the preset is rewritten into an effective spec for that one job — the same structure with different values — and every downstream stage consumes that structure exactly as it always did. All other override behaviour follows from this design.
This design removes an entire failure class: no parallel code path exists that could disagree with the normal one.
Frame-rate overrides and chunking#
The fastest chunk-splitting path bounds each chunk by a frame count derived from the source's rate. That is correct only while the output plays back at the same rate; a different output rate invalidates the assumption.
A frame-rate override therefore moves the job onto time-based chunking automatically. The output is equally correct under either strategy, and only the internal placement of chunk boundaries differs. Note that setting this one control changes the planning strategy for the job.
Codec overrides and encoder settings#
A preset's encoder settings form a single unit, not a list of independent switches. Profile, pixel format, vendor tag and rate-control flags are all specific to the encoder that wrote them.
Replacing only the codec name while leaving the previous encoder's flags in place produces a command the new encoder rejects outright. A codec override therefore replaces the whole block in one step, validated against the real encoder; a partial rewrite is never applied.
Refused combinations#
A refusal is the intended outcome. Accepting the request and letting the encode produce something different would yield a deliverable that completes, appears correct, and does not match what the job record claims. A clear error that can be acted on at submit is preferable to a wrong file discovered at review.
| Refused combination | Reason |
|---|---|
| Resolution or bitrate on a classic DNxHD preset | DNxHD is profile-locked to specific combinations of size, rate and bitrate. No single configuration is valid across an arbitrary override. Use DNxHR, which is resolution-agnostic. |
| Bitrate on a DNxHR-profiled encode | The profile determines its own data rate. The encoder accepts a bitrate and then ignores it, so the job record would claim a rate the file does not carry. |
| Resolution on letterbox, pad or crop presets | Those filter chains have their dimensions pinned. Rewriting the scale around them produces a filter graph that cannot run. |
| Any override on an image-sequence preset | EXR, DPX and other sequence presets do not run through the video encoder path at all, so codec and resolution have no meaning there. The override is refused rather than silently ignored. |
| A container change that strands the audio codec in effect | Some containers cannot carry some audio codecs — MXF is PCM only. The combination is refused rather than producing a file that fails to mux. |
| Resolution alongside a crop adjustment on the same job | The two computed frame sizes collide. Set one or the other. |
Identifying overridden values#
The chosen overrides are shown back on the job-detail page's Spec panel, where every overridden value carries an explicit tag. Anyone inspecting a finished or in-flight job can distinguish the settings that came from the preset from those set for that job alone.
This record establishes, at any later date, why two deliveries from the same preset are not identical.