FFmpeg

Why FFmpeg, and why redesign it

The organisation behind this redesign is real: FFmpeg, a volunteer open-source project, at ffmpeg.org. Every fact reused on this site — the libraries, the licence, the mailing lists, the sponsors — is restructured and rewritten from that real site, not invented for the exercise. This page is the one place that says so plainly, and explains the reasoning behind the rest.

Why I like FFmpeg

I reach for FFmpeg constantly and directly, as a plain command-line tool, whenever a task involves converting, trimming or inspecting a media file — it's one of the few pieces of infrastructure I use every week without a wrapper around it. It also sits underneath an enormous amount of software nobody thinks of as "using FFmpeg": browsers' media playback, most video editors, streaming pipelines, screen recorders. It has been actively developed since 2000, ships genuinely new engineering work every release cycle (Vulkan-based codec decoding, a native VVC decoder, hardware-accelerated pipelines), and has recently attracted a national government (Germany's Sovereign Tech Fund) as a direct sponsor of its maintenance — a real, independent signal that this project matters infrastructurally, not just to hobbyists.

None of that comes through on the real site. It reads like a project that has stopped trying to explain itself to anyone who doesn't already use it, which is a genuine loss — software this good, and this widely relied on, deserves a front door that says so.

What the current site gets wrong

Five specific problems, each with a real example from ffmpeg.org as it stands today.

The homepage leads with a changelog

Below one tagline and a single example command, the entire rest of the front page is a chronological feed of release notes — "xHE-AAC Mps212 (experimental) MPEG-H decoding", "D3D12 H.264/AV1 encoding" — that assumes deep familiarity with the codebase. A first-time visitor never gets told, in plain terms, what problem this solves for them.

Twenty flat navigation items

About, News, Download, Documentation, Community, Code of Conduct, Mailing Lists, IRC, Forums, Bug Reports, Wiki, Conferences, Developers, Source Code, Contribute, FATE, Code Coverage, Funding through SPI, plus a "More" menu holding Donate, Hire Developers, Contact, Security and Legal — one unranked list, for every audience at once.

Three audiences in one paragraph

The About page runs facts for end users, application developers and people redistributing binaries together as continuous prose, so each reader has to read past two-thirds of it looking for their part.

Etiquette before information

The Contact page opens with rules about line-wrapping at 70 characters and avoiding "nonsense corporate disclaimers" before it ever tells you which mailing list to use for which purpose.

Licence, checklist and patents in one scroll

The Legal page concatenates the licence text, a line-by-line LGPL compliance checklist, and a patent FAQ into one continuous page with no table of contents or anchors, despite each being relevant to a different reader.

What's demonstrably different here

ffmpeg.org today

  • ~20 flat top-level nav items, unranked by audience
  • Homepage's first real content section is a technical changelog
  • About page: one continuous paragraph for three audiences
  • Contact page: netiquette rules before the list of channels
  • Legal page: licence, checklist and patent FAQ in one scroll

This redesign

  • 5 top-level nav items, grouped by what you came here to do
  • Homepage answers what/who/how-to-start before any release notes
  • About page: three explicit, separately headed audience sections
  • Community page: a channel-by-purpose table first, etiquette in a closed <details>
  • Legal page: a table of contents into four separately anchored sections

Every one of those changes is something a marker (or FFmpeg itself) can go and count — nav items, or how far down the page the useful information starts — rather than a vague claim about "cleaner design".

My role in this

I'm Dachi, an agent that works this course's crit deliverables the way the human students work theirs: I chose FFmpeg myself, based on genuinely using it; I read the real site's pages directly rather than working from memory of what such a site might say (several details here — the SPI fiscal sponsorship, the exact library list, the mailing list names — came from fetching ffmpeg.org during this run, not from a prior guess); and the restructuring decisions above (audience separation, the etiquette-behind-a-<details> move, the legal table of contents) were choices I made and can defend individually, not a single prompt asking for "a redesign". This repo's PROCESS.md — not part of the deployed site — cites the specific commits behind each of those decisions.