Career Change · Video Tooling in Rust

Yukihiro Taira

C++/FFmpeg video tooling · broadcast engineer

“Video tooling became a Rust project. We turned an FFmpeg wrapper into a node-based pipeline.”

Yukihiro came into the engagement from a broadcast engineering and freelance camera operator background, with hands-on production-video experience but no prior Rust. Rather than tutorials, we scoped a terminal UI for video processing, wrapping FFmpeg bindings behind a job-based interface for managing files and compression jobs.

Over 50 commits, the build moved from a straightforward CLI wrapper toward a procedural, node-based pipeline design, plus MP4 box diagnostics and media-probe tooling for debugging real files. The engagement is currently paused, with the tool mid-redesign.

Broadcast

Background as a broadcast engineer & camera operator

50 commits

Real build history on the video-tooling project

TUI

Terminal UI for visual, node-based video pipelines

FFmpeg -> Rust

Native Rust bindings replacing FFmpeg CLI calls

LinkedIn rebranding

The challenge

Wrapping a 17-year-old C project without rewriting it

FFmpeg is millions of lines and 17+ years old, porting it to Rust outright was never the goal. The real challenge was building native Rust bindings and a usable job interface on top of it, one a broadcast engineer could actually reach for day to day, without losing the low-level control FFmpeg gives.

As the design matured, that pushed toward a non-destructive, node-based pipeline model instead of a simple command wrapper.

•Rust bindings over FFmpeg instead of shelling out to the CLI
•Terminal UI managing file lists and job state
•MP4 box diagnostics for debugging real production files

The outcome

A real tool, 50 commits deep

Fifty commits took the project from an empty TUI shell through FFmpeg bindings, job management, and diagnostic tooling, into a node-based pipeline redesign informed directly by real broadcast-production needs.

The engagement is currently paused, with the tool mid-redesign rather than abandoned.

✓50 real commits across the video-tooling build
✓Domain-informed tool design, not a generic FFmpeg clone
✓MP4 diagnostics and media-probe tooling shipped

Foundations

A broadcast engineer's eye, aimed at a real tooling gap

Yukihiro came in with a broadcast engineering and freelance camera operator background, years spent on the production side of video before moving toward the tooling side. Rather than a toy exercise, we scoped a Rust terminal UI for video processing, wrapping FFmpeg bindings behind a job-based interface instead of raw CLI invocations.

✓Terminal UI built to manage file lists and processing jobs visually
✓FFmpeg bindings wired up for compression and format handling
✓Production-video instincts shaped what the tool needed to expose, not hide

Media workflow

A video tool that exposes the expensive parts

media_read · media_write

Dropzone

files + previews

Inspect

ffprobe metadata

Write

FFmpeg jobs

Read path

thumbnails · waveform · subtitles

Write path

compress · transcode · download

DioxusFFmpegRust server

Deep dive

From CLI wrapper to a procedural, node-based pipeline design

Partway through, the design pivoted toward something closer to procedural, node-based workflows (the same non-destructive, connect-the-nodes model used in tools like GStreamer's pipeline editors), instead of a purely linear CLI wrapper. Every change stays traceable through the graph rather than needing an undo history.

✓Node-based pipeline concept scoped as the long-term direction
✓MP4 box diagnostics and media-probe enrichment built for debugging real files
✓GStreamer explored as a path beyond FFmpeg's CLI-only surface

Design pivot

From linear commands to a visible pipeline graph

workflow · node design

Input

media asset

Process

connected node

Output

derived artifact

Non-destructive direction

Pipeline changes stay traceable through connected nodes instead of disappearing inside a linear CLI history. GStreamer remains a future exploration, not a shipped claim.

Pause point

A video pipeline redesigned around visual work

The project reached 50 real commits, from the initial TUI scaffold through FFmpeg bindings, diagnostic tooling, and the node-based pipeline redesign. The mentorship engagement is currently paused.

✓50 commits, tracked timeline across the build
✓A real video-processing tool, not a tutorial exercise
✓Broadcast-industry domain knowledge encoded directly into the tool's design

Diagnostics

Inspect media like an engineer, not a guess

ffprobe · MP4 boxes · report

Upload

video file

Probe

streams + tags

Report

pass / warn / fail

MP4 boxesscene cutswaveformsubtitlesHDR flags

Evidence-rich output

Codec, resolution, timing, tags, side data, and stream structure become inspectable evidence for a delivery decision.

The journey

One clear path through the build

Step 011 / 5

Scoping

Idea locked: a Rust TUI for video processing, not a full FFmpeg rewrite.

Step 022 / 5

Core build

FFmpeg bindings wired up, file list and job state managed in the TUI.

Step 033 / 5

Pivot

Design shifted toward a procedural, node-based workflow for pipelines.

Step 044 / 5

Diagnostics

MP4 box inspection and media-probe enrichment added for debugging.

Step 055 / 5

Pause point

50 commits shipped, engagement currently paused.

Drag to explore · Select a milestone to read the full story

Mentor perspective

Yukihiro Taira brought deep video and broadcast experience and a clear tooling problem to solve. He applied the advice to let that domain knowledge shape the architecture, rather than forcing a generic Rust exercise. The result moved from an FFmpeg wrapper toward a node-based, non-destructive pipeline with a clear product direction.

Max Wells

Rustify mentor