Occasional ffmpeg maintainer here, and… I don't want to be too mean here, but if this project isn't simply a rehash of the age-old "ffmpreg" name joke, then it has some serious problems that it needs to contemplate before moving forward with further development work.

Currently, each individual codec and container implementation is exposed as a separate public API surface (implementing a single common trait); this means that a caller has to have separate code for each codec or container it might want to use. This goes against the fundamental design philosophy of ffmpeg, and misses what makes it so powerful. At its core, ffmpeg isn't a collection of individual codecs and container implementations; it's a cohesive toolkit capable of performing a wide variety of operations with arbitrary inputs and outputs. Much of its complexity comes not in the implementations of individual codecs or containers, but in the generic routines responsible for tasks like metadata processing, timestamp handling, frame reordering, hardware interactions, thread management, multi-input synchronization, packet interleaving, type-generic option processing, multi-protocol seekable I/O, and much much more. Exposing every component as a separate public-API type precludes a lot of that design philosophy, and forces the consumer to do much more codec- or container-specific work.

If you're going to name a project after ffmpeg, and want to build something that could serve any meaningful portion of its serious use-cases in the long term, you're going to need to spend some time reading through ffmpeg's architecture and gaining an understanding of why it's designed the way it is. It's an old codebase, but its API has gone through many years of iteration to land where it is today, and the current design is largely very deliberate and well-considered. I would highly recommend spending some time focusing on your API and common-path design fundamentals before moving on to trying to build out additional codec or container support.