yt‐dlp, mpv & ffmpeg

One unexpected part of this project was rediscovering tools I had used years before I even considered studying computer science.

Long before I thought seriously about software engineering, I used tools like yt-dlp and ffmpeg for something much simpler: downloading and converting mashup tracks into MP3s I could listen to offline. Back then they felt like mysterious internet tools that “just worked.” I didn’t understand the internals — I only knew the right command could turn a YouTube link into a music file.

Coming back to those same tools while building Vaux felt full-circle.

At first, yt-dlp wasn’t even part of my CLI architecture plan. I assumed I’d use Electron or fully embedded web playback to avoid local media complexity. But as I went deeper into terminal app design, I wanted the CLI to feel native and self-contained, not like a browser wrapper.

That decision opened a rabbit hole.

I started experimenting with local playback through mpv, which introduced distribution and dependency problems across systems. I spent a lot of time figuring out how users could pip install vaux-cli without manual mpv setup.

I thought this would be easy — download a binary, extract it, done. It turned into a systems problem involving portable builds, archive formats, architecture detection, and cross-platform handling.

I ended up building an installer pipeline inside Vaux. On first run, the CLI creates vendor/staging directories under ~/.vaux, queries GitHub Releases, picks the right portable mpv asset by architecture, downloads it, extracts it, and caches the resolved mpv path for future launches.

Extraction itself was trickier than expected.

The official mpv builds are shipped as .7z archives, and standard Python extraction paths were unreliable for those archives (BCJ2-related filters). The practical fix was to rely on an actual 7-Zip binary for extraction.

That changed the implementation approach.

Instead of depending on Python archive libraries, Vaux now prefers system 7z; if unavailable, it downloads and installs a local 7-Zip executable under ~/.vaux/7z, then invokes it via subprocess for extraction. What started as “include a media player” became a full dependency pipeline: discovery, staging, downloading, extraction, caching, and recovery paths.

Claude and Cursor were useful during this phase as planning partners. I used them to compare tradeoffs (Electron vs native playback vs embedded web approaches), evaluate edge cases, and structure implementation steps. That helped me move from scattered experiments to deliberate system design.

I eventually landed on a portable mpv bootstrap flow that is reproducible at the process level (deterministic asset selection and install path), though it still depends on upstream GitHub release availability. It’s still evolving, and automating update/pinning strategy is future work.

Ironically, that frustration made the project more interesting.

For the first time, I wasn’t just consuming tools — I was integrating them into a system. yt-dlp stopped being “just a downloader” and became part of a media pipeline. ffmpeg stopped being a magic command and became infrastructure thinking: process control, error paths, buffering, and playback synchronization.

That shift — from passive tool usage to system-level integration — was one of the most meaningful parts of this project.

It also reinforced something I keep noticing while learning computer science: many things that first drew me to tech were already forms of engineering curiosity. I just didn’t recognize them that way at the time.

Even downloading mashup tracks years ago connects directly to the same curiosity that later led me to build a real-time collaborative music platform.