Conformance
Validated against 125 real-world encode cases, continuously.
Every claim on this page is generated from Transcodely's validation catalog — a suite that submits real jobs to real workers and asserts on the produced media, manifests, DRM and HDR signalling, and pricing. Of the 125 cases, 84 drive an encode to completion; the rest verify validation boundaries, pricing, and job lifecycle.
125
validation cases
84
real encodes to completion
28 / 38
capabilities validated
19
coverage categories
What every case actually checks
A green case is not "the API returned 200". It means a job ran end to end and the output held up under inspection.
Real jobs, real workers
Each case provisions real object storage (Cloudflare R2), submits through the public API exactly as documented, and runs on real Hetzner worker VMs. No mocks, no stubs.
Media, probed
Produced files are downloaded and inspected with ffprobe — codec, profile, pixel format, resolution, framerate, and colour signalling are checked against what was requested.
Manifests, parsed
HLS and DASH manifests are fetched and parsed for variant count, audio and subtitle renditions, and encryption signalling — proving a stream was produced, not merely priced.
Pricing, recomputed
The locked pricing snapshot returned on each output is recomputed from its components (codec, resolution, framerate, quality, feature) and checked for internal consistency.
Artifacts, counted
Thumbnails, sprite WebVTT tracks, and subtitle sidecars are listed from storage and counted against what the job asked for.
Honest about gaps
When the worker cannot yet produce a feature, the case keeps its true assertion and is tracked as a gap — reported, never quietly passed. Those gaps are listed in full below.
Coverage by category
Cases are grouped by what they exercise. "Validated" counts the cases the suite expects to pass today; anything in progress is called out separately.
Input validation (rejections)
31/31Codec × container
11/11Codec settings
8/91 tracked, in progress
HDR
8/8Input formats
7/7Quality (VMAF)
7/7Streaming (HLS / DASH)
7/7Adaptive bitrate
6/6Presets
6/6Subtitles
5/61 tracked, in progress
Audio
5/5Pricing
5/5Thumbnails
4/4DRM
2/31 tracked, in progress
Job lifecycle
3/3Path templates
3/3Resolution
2/2Multi-output jobs
1/1Encode-failure handling
1/1Capabilities exercised
Each value below is exactly what the API accepts on the wire. A value is validated only when a real job produces it and the harness asserts on the output. Values still in progress are not yet validated end to end — some are accepted-but-unproduced, others are gated at create.
Video codecs
Containers & packaging
DRM systems
Encryption schemes
HDR formats
HDR modes
Subtitle operations
Subtitle formats
Thumbnail modes
Content-aware encoding
In progress — tracked, not yet validated
These features are accepted and priced by the API, but the encoder does not yet produce them end to end. Each still has a validation case that asserts the true intended behaviour — it stays here, counted honestly, until it passes.
DRM HLS cbcs (FairPlay, BYOK) should encrypt and signal via #EXT-X-KEY
worker produces no HLS encryption signaling (#EXT-X-KEY absent) for DRM HLS outputs — DASH DRM works, HLS DRM is unwired
H.265 main10 profile should produce a 10-bit HEVC stream
worker emits 8-bit Main for a main10 profile request — it does not force a 10-bit pixel format
Convert embedded SRT→WebVTT as a DASH text AdaptationSet
worker DASH packaging fails (packaging_failed) when a converted subtitle rendition is attached — convert→HLS works
Why you can trust these numbers
This page is not hand-written. It is generated from the API's validation catalog and synced into the site as a snapshot; the same catalog is the production-readiness gate for the encoding pipeline. When a capability's coverage changes, the number here changes with it — and a drift check fails the build if the page and the catalog ever disagree.