Broadcast engineer · camera operator · video delivery
Yukihiro comes from broadcast engineering and camera work, where a file that looks fine in the editor can still be rejected at delivery for a wrong field order, a missing language tag or loudness out of spec. He built a Rust video debugger that answers that question before the file leaves the building.
The app runs on Dioxus fullstack and Axum. It orchestrates ffprobe, MediaInfo and ffmpeg filters in parallel, maps everything into one typed report, and scores it against Web, Broadcast or Mobile delivery profiles, with a side-by-side compare for two exports of the same edit.
Broadcast
Background as a broadcast engineer
Camera op
Freelance camera operator on productions
FFmpeg
Video tooling background in C++ and FFmpeg
NLE
DaVinci, Premiere and Final Cut Pro delivery workflows
LinkedIn rebranding
The challenge
Delivery specs are strict, and the tools are scattered
Checking a master today means juggling MediaInfo, a player and raw ffprobe output, then knowing by heart which values a broadcaster or a platform will reject. Exports from DaVinci, Premiere and Final Cut Pro with the same settings do not even carry the same metadata.
Yukihiro set the priority himself: every reported value must be correct and complete before adding deeper features like MP4 box parsing. A diagnostic tool that is confidently wrong is worse than none.
•Severity depends on where the file is going
•External tools crash or hang on malformed files
•Large masters take long enough to need live progress
The outcome
A delivery check a broadcaster would trust
Drop a file and get a pass, warn or fail report scored for its destination, covering video, audio, subtitles, tags, timecode, A/V sync and R128 loudness.
Process timeouts, isolated failures and background inspection with progress polling keep it usable on real production masters, not just sample clips.
✓Rules scored per Web, Broadcast or Mobile profile
✓Parallel ffprobe, MediaInfo and loudness analysis
✓Side-by-side compare of two exports
[ Product ]
One tool instead of MediaInfo, VLC and the ffprobe CLI
The project started as a terminal UI for encode jobs, then pivoted to the problem Yukihiro actually hits in production: why a file gets rejected at delivery. Drop a video, get playback plus a structured diagnostic report, built with Dioxus fullstack on Axum.
Under the hood the server orchestrates ffprobe, MediaInfo and ffmpeg filters, then maps their output into one typed MediaProbeReport. The raw ffprobe dump stays available, but every field that matters is parsed into a checkable struct instead of a text blob.
[ Rules ]
Checks scored against a delivery target, not in a vacuum
A PlatformProfile enum (Web, Broadcast, Mobile) changes the severity of each rule. The same file can pass for YouTube and fail for TV, because broadcast expects PCM 16-bit at 48 kHz and mobile caps at 1080p, 8-bit and H.264 Main.
Each check returns Pass, Warn or Fail with a human-readable detail: variable frame rate from avg vs r_frame_rate, A/V start offset, audio and video duration mismatch, HDR side data, field order, forced subtitles, language tags and timecode. Missing data is a Warn, never a silent Pass.
[ Pipeline ]
Parallel analysis where one failing tool cannot sink the report
ffprobe runs first under kill_on_drop and a configurable timeout. Thumbnails, subtitles, waveform, scene cuts, MediaInfo and EBU R128 loudness then run concurrently with tokio::join!.
Every secondary analysis returns its own Result, so a MediaInfo crash fills mediainfo_error and the rest of the report still renders. Loudness comes from ffmpeg's ebur128 filter with true-peak enabled, parsed from stderr into a typed LoudnessReport.
[ Progress ]
Long inspections that report where they are
Uploading a large master returns a trace id immediately, and the inspection continues in a background task. The client polls a progress endpoint that exposes the current stage, elapsed time and partial results.
Progress lives in an Arc<RwLock<HashMap>> keyed by trace id, with a tagged ProgressStage enum serialized for the frontend. Failures are logged with the trace id, persisted as bug reports, and the temp file is removed on every exit path.
The journey
One clear path through the build
Step 011 / 5
TUI prototype
ffmrust: a terminal UI for FFmpeg encode jobs with drag-and-drop input.
Step 022 / 5
Pivot
From encoder to debugger: drop a file, get a pass, warn or fail report.
Step 033 / 5
Probe enrichment
SAR, HDR side data, B-frames, chroma location and tags surfaced first.
Step 044 / 5
Delivery profiles
The same rules scored against Web, Broadcast and Mobile targets.
Step 055 / 5
Compare
Field-by-field diff of two exports of the same edit.
Drag to explore · Select a milestone to read the full story
