C.W.K.
Stream
Lesson 01 of 05 · published

Playback Is the Product (So Don't Rebuild It)

~13 min · embed-engine, reuse, libmpv, ffmpeg

Level 0Reel Novice
0 XP0/39 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Reuse libmpv and FFmpeg for codec and renderer depth; don't spend CWK time rebuilding a media engine."

The Most Seductive Rabbit Hole in Media

Writing a decoder is fascinating. Bitstream parsing, motion vectors, color spaces, hardware acceleration — it's a bottomless, gorgeous well of engineering. It is also, for a bounded player, a trap with no floor. FFmpeg is thirty years of that work by hundreds of people. You will not catch up on a weekend, and every hour you spend on it is an hour not spent on the one thing that makes your player yours.

So Ashen Reel doesn't. It embeds libmpv — an FFmpeg-based engine with a clean embedding API — and inherits the entire codec and renderer depth for free. The engine decodes; Ashen Reel decides.

Own the Join, Borrow the Depth

The reuse decision draws a clean map of what you build versus what you take:

Reuse the deepest commodity; build only the join that no one else can. Codecs are a commodity — libmpv has them. A player that opens Recall's remembered second is not a commodity — nobody has that. Spend your scarce hours there.

This is the first of the four coding pillars — Reuse before Extend before Scale — applied at the highest level of the app. The moment you catch yourself about to reimplement something a mature library already does well, stop and ask whether that reimplementation is your product or your procrastination. For a media engine, it's almost always procrastination in a lab coat.

Reuse Is Not Free — It's a Trade

Borrowing an engine isn't zero-cost; it's a different cost. You take on a dependency you must pin, license, bundle, and sign (all of Track 6). You accept the engine's model of the world and have to translate it into yours. But that cost is bounded and one-time, whereas rebuilding a decoder is unbounded and forever. The trade is almost always worth it — as long as you keep the borrowed engine on the far side of a boundary, which is exactly what the next lesson builds.

The test for 'should I reuse this?': is the thing you'd be building a differentiator, or a commodity? If a mature, maintained library does it and it isn't your product's reason to exist, reuse it and put your name on the part that is.
Early on I sketched a little AVFoundation-only player and it felt so clean — all Apple, no C, no bundling headache. Then I ran Dad's real archive through it and watched it shrug at an old MKV with an ASS subtitle track and a codec from 2011. That's the moment reuse stopped being a preference and became the plan. The clean version only looked clean because it hadn't met the real media yet.

Code

What Ashen Reel builds vs what it borrows·text
  OWN     AshenReelApp    window, menus, shortcuts, Recall client, composition
  OWN     AshenReelCore   handoff parsing, seek rules, state -- pure, testable
  SEAM    CLibMPV         narrow C module: Swift <-> libmpv, no product logic
  BORROW  libmpv          decode, render, seek, tracks, subtitles
  BORROW  FFmpeg          decades of codec work, reached through libmpv

// The value you add lives in the OWN rows.
// The depth you'd never finish lives in the BORROW rows.
// The SEAM is the only new code the reuse decision forces on you.

External links

Exercise

Look at something you're planning to build from scratch. Split it into two lists: the parts that are a commodity (a mature library already does them well) and the parts that are your actual differentiator (nobody else has your exact join). Be honest about how much of your excitement is pointed at the commodity list. What would change if you reused every commodity part and spent all your effort on the differentiator?
Hint
The commodity list is where reuse belongs; the differentiator list is where your hours belong. If almost everything you're excited to build is on the commodity list, that's the rabbit hole talking — the interesting engineering is rarely the same thing as the valuable engineering.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.