Conformance
Validated against 164 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 164 cases, 106 drive an encode to completion; the rest verify validation boundaries, pricing, and job lifecycle.
164
validation cases
106
real encodes to completion
34 / 40
capabilities validated
23
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, minimum) 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)
42/42Codec × container
11/11Codec settings
10/10HDR
8/91 tracked, in progress
Input formats
8/8Pricing
8/8Thumbnails
8/8Quality (VMAF)
7/7Streaming (HLS / DASH)
7/7Adaptive bitrate
6/6Presets
6/6Subtitles
6/6Audio
5/5Path templates
5/5Watermark / overlay
5/5Captions
3/41 tracked, in progress
DRM
4/4Job lifecycle
4/4Clip
3/3Encode-failure handling
2/2Resolution
2/2Encoding pipeline
1/1Multi-output jobs
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.
HDR10+ force on H.265 — output must carry PQ/BT.2020 10-bit AND dynamic HDR10+ metadata
HDR10+ dynamic metadata (SMPTE ST 2094-40) is unimplemented: the worker encodes hdr10_plus through the same static-HDR10 branch as hdr10, so the output carries no per-scene metadata
Retro-caption a hosted video — sidecar under the video prefix, attached with in_manifest=false
retro-caption input: worker cannot read an HLS manifest input, and hosted videos keep no single-file source
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.