REFERENCE / VERSION 1.0
Clear patterns.
Readable by design.
Small job examples, a downloadable schema, and a review-first workflow. A practical starting point for your own encoding implementation.
01. Describe the intended job
Keep the source identity, operation, profile revision, and review requirement together. These examples use an illustrative approved asset identifier. Your application must resolve that identifier through its own authorized asset store.
{
"schema_version": "1.0",
"source_asset": "approved-demo-asset",
"operation": "video",
"profile": "web-review-v1",
"require_review": true
}{
"schema_version": "1.0",
"source_asset": "approved-demo-asset",
"operation": "audio",
"profile": "speech-review-v1",
"require_review": true
}{
"schema_version": "1.0",
"source_asset": "approved-demo-asset",
"operation": "clip",
"profile": "vertical-clip-v1",
"interval": {
"start_seconds": 12.5,
"duration_seconds": 18
},
"require_review": true
}02. Define each field
| Field | Meaning in this pattern |
|---|---|
schema_version | The reference contract revision, fixed at 1.0. |
source_asset | An application-owned identifier, not an arbitrary public URL. |
operation | One of video, audio, or clip. |
profile | An approved named profile matching the chosen operation. |
interval | Required for a clip; a nonnegative start and positive duration, in seconds. |
require_review | Always true in this review-first example. |
03. Validate structure and meaning
The downloadable JSON Schema rejects unknown properties, mismatched operation/profile pairs, and missing clip intervals. It cannot establish source ownership, permissions, actual duration, or destination compatibility. Your application must independently check those conditions.
A clip whose start and duration are individually valid can still extend beyond its approved source. A correctly formed asset identifier can still refer to unavailable material. Keep structural validation and those semantic checks separate.
Background: the JSON Schema object reference explains object properties and additional-property rules.
04. Give profiles a real definition
The example names communicate intent; they are not encoder presets. Before execution, map each name to reviewed settings in your implementation. Record the exact codec, container, dimensions, channel policy, and any caption handling relevant to that destination.
| Example profile | Intended purpose |
|---|---|
web-review-v1 | A reviewed video playback candidate. |
speech-review-v1 | A reviewed spoken-word listening candidate. |
vertical-clip-v1 | A reviewed short excerpt with an explicit framing policy. |
05. Inspect actual media
With FFmpeg tools installed locally, the following read-only command asks ffprobe for container and stream information about your own input.mp4. The site does not execute it. Use a non-sensitive test file that you are authorized to inspect.
ffprobe -v error -show_format -show_streams -of json input.mp4The official ffprobe documentation describes this inspection tool and its machine-readable outputs. Check observed properties against your acceptance brief, then review picture, sound, and playback where required.
06. Keep job states honest
A possible application state model is queued → processing → validating → completed, with explicit failed and canceled outcomes. Treat publication approval as a separate decision. Define transition ownership, retry policy, duplicate-request behavior, and stale-attempt handling before production use.
Read the media pipeline reliability guide for the full design discussion. An accepted request is not evidence of a completed transformation or a publishable result.
07. Download the examples
All files below are local, readable reference assets. Review the schema and adapt the examples to your own infrastructure before use.
MAKE THE NEXT STEP A CLEAR ONE
A better workflow starts here.
Bring a question, share a correction, or talk about an encoding idea.