FFmpeg + OpenH264/x264/SVT-AV1/x265 on WASM, on DCP
Drop a video. Watch a real DCP worker fleet transcode it, live, into a real 1080p/720p/480p/240p ABR ladder. Real AV1 and HEVC renditions ride alongside H.264, so you can watch each cost more compute per encode and land noticeably smaller. Optional real-decode passes along the way: EBU R128 loudness normalization, multi-audio-track passthrough, and HDR10 color-metadata passthrough. When it's done, download every rendition straight to disk.
Concrete constraints of this demo build: single video track only (no multi-angle, no subtitles/captions); containers limited to MP4/MOV, MKV, MPEG-TS, and WAV; video decodable as H.264, HEVC, or AV1, audio as AAC or PCM only; up to 8 audio tracks; HDR10 passthrough only (no Dolby Vision - needs a licensed SDK this project doesn't have); and libopenh264 itself hard-caps at 4096×2304 (DCI 4K, 9,437,184px) - this demo's own renditions top out at 1920×1080 (2,073,600px), well under that, but it would matter at true 4K+ output. Documented scope, not a bug list.
Both persist in this browser's local storage across reloads (clear). Get your own API key from your DCP portal. Not specifying a compute group deploys the job to the Global (public) group.
Drag a video file here, or click to choose one.
H.264/AAC MP4 works best (matches this project's tested decode path).
Click, or drop another file, to replace it.
Loudness normalization runs a real decode → avfilter (loudnorm) → re-encode pass on the audio track. A real upload's own multiple audio tracks or HDR10 metadata already pass through automatically, no toggle needed.
Higher renditions cost real extra dispatch/compute - uncheck any to skip it for this run. Uncheck all of them and there's nothing for section 5 to play back.
Each is real extra dispatch/compute cost on top of the ABR ladder - uncheck any to skip it entirely for this run (no job units, no cost). Doesn't affect the ABR ladder or the job itself.
Checked: more, smaller slices, so more workers can grab pieces at once - each chunk re-transmits once per slice instead of once per chunk (480p/240p/h264-240p-quality share one slice to cut some of that; every other rendition gets its own). Unchecked: one slice per chunk, looping every rendition inside the sandbox - less data transmitted, less parallelism.
Unchecked: this tab also transcodes every chunk×rendition itself, sequentially, in its own wasm module - so you can watch the fleet visibly beat single-threaded local encoding.
Scan to turn your phone or laptop into a worker for the compute group this job is running on. More workers join mid-job, and the DCP bar visibly speeds up.
Not derived from running anything on AWS, or from this demo's own encode time. AWS bills MediaConvert per minute of output video duration (a 45-second output bills as 0.75 minutes), not processing time - so this multiplies each chunk's real duration by AWS's published rate, the same quantity AWS itself bills on, regardless of the hardware underneath. That hardware is undisclosed - an intentionally opaque managed service - which is exactly why a duration-based rate card is a fair comparison: whatever it costs AWS is already priced into the rate. Rates from aws.amazon.com/mediaconvert/pricing/ (SD <720p, HD 720-1080p): H.264 uses the Basic tier; AV1 and HEVC (bake-off comparison only, always 240p/SD) use the Professional tier at 3.5x and 2x its base rate, respectively.
DCP prices compute at 1.000 ⊇ (one DCP credit) = $0.0003171 USD per 100 reference vCPU-seconds - a normalized unit, not raw wall-clock time, so a slice's price is fixed regardless of hardware: slower hardware just takes longer to earn it, faster hardware earns it sooner. "Raw DCP cost" totals that price across this run's slices; of it, the scheduler takes a 20% commission and the worker that ran the compute earns the other 80%.
Three extra 426×240 renditions - matching the ladder's bottom rung - ride along in every job: libopenh264, libsvtav1, and libx265, each in its own quality mode rather than a bitrate cap, which would erase their efficiency differences. AV1 and HEVC cost meaningfully more compute per encode than H.264. None play back below - comparison only: AV1 hits a real MPEG-TS muxer warning ("muxed as a private data stream"); HEVC muxes cleanly but is skipped anyway since browser HEVC decode support (via MSE) still varies by platform.
This plays the real ABR ladder from section 1's job (1080p/720p/480p/240p, H.264) as one adaptive stream - not a single fixed output. The AV1/HEVC/quality-mode renditions from section 4 are comparison-only and aren't part of this ladder (see that section's note on why).
One file per rendition, saved to a folder you pick. Needs Chrome or Edge.