Hello extensive FFMPEG development team, May I kindly request we further the discussion of this topic? There is also a message from me in the #ffmpeg-by-example Discord channel from May 2025, which happens to be nearly the latest post of any kind in that channel. As I understand, the other mailing lists here are near-daily active, and I would be happy to repost this discussion to those, if you advise which. As I understand, FFMPEG is a video backbone of the entire Internet. This project discussion seems so very simply to be imperative. And, once again, I am offering to contribute my services to the existing extensive FFMPEG software consultant teams that help companies implement FFMPEG.
Please email. What further information would you ask that I provide? Warm regards, David David Bernat, Ph. D. Property of Starlight LLC. On Sat, Jan 3, 2026 at 4:05 PM David Bernat <[email protected]> wrote: > Is that a question to me, or an ask for clarification? > > The pace of algorithms, acceleration, and user interfaces are > themselves accelerating. More than enough for FFMPEG to engage with my > emails stretching back two years. Think about how challenging writing good > filter command lines are using FFMPEG, compared to what is achievable when > optimization-aware LLMs can generate surface engagement with the FFMPEG > stack. One would expect a totally new pipeline of prioritization of FFMPEG > core could develop, as new use cases and case frequencies arise. Not to > mention the improvements of underlying algorithm engineering itself. > Nothing FFMPEG lifers don’t already know, but as a chief scientist sort > these are part of my ten year thinking too. I remember when FFMPEG > originally dropped in the early days of the web. There is no doubt a new > “vision roadmap” for FFMPEG with these accelerations in solvers arriving. I > presume the FFMPEG lifers have a sense for what 2033 goals already feel > like— why wouldn’t they? [shrug] > > I’m just a guy with a degree and non-expertise in their craft. But I can > tell that with support from FFMPEG my tiny shop could have been making far > greater utilization of FFMPEG and I am not alone, that is ostensibly a > metric that drives them. People want fast, easily accessible video. > > I hope something comes of this that turns my tiny system into something > that others see as useful. > > I wouldn’t be able to speak smartly beyond this without toe stepping but > seems obvious to me. Just think about the nightmares of filter creation— > and how many different answers different forums provide— a standard MCP > would be big. > > Warm regards, > Bernat > > David Bernat, Ph. D. > Property of Starlight LLC. > > > On Sat, Jan 3, 2026 at 3:21 PM Michael Ivanov <[email protected]> wrote: > >> What should happen by 2033? >> >> On Sat, Jan 3, 2026, 18:07 David Bernat via Libav-user < >> [email protected]> wrote: >> >>> Hey esteem captains of FFMPEG, >>> >>> It is that awful topic every AI wanker (me) wings on about (AI coding). >>> I am a former chief scientist at AI companies, and have tried reaching out >>> through many channels over the last two years for mentors to better >>> understand exactly how FFMPEG wants to take itself into 2033 and beyond. I >>> am a non-power user audiophile with a background in physics and signal >>> processing. >>> >>> So, I just downloaded OpenCode this week to explore vibe-coding, and >>> ordered a V100 for $900 to set up an offline on-prem server. I spent a few >>> hundred hours in 2022 and 2023 building my own FFMPEG wrappers for Python >>> to produce various podcasts and videos for a YouTube channel. I am probably >>> your typical non-power user who wants to go that next level. >>> >>> An FFMPEG MCP is a unique challenge. Data processing is time consuming, >>> so any MCP would need to be equipped with extra protections of "explaining >>> AI" to walk through each and every filter suggested, and "sample AI" to run >>> these filters on small test clips to confirm each compiles (or video >>> inspection matches expectation) to run in a typical closed loop creation. >>> >>> That is the part that really excites me about joining any project. The >>> intricate systems of interacting filters is, of course, a defining asset of >>> FFMPEG and a critical headache for new users. And for power developers on >>> the FFMPEG team, this kind of critical un-black-box-ify is precisely what >>> in my experience is powerful to preserve. To learn this over the upcoming >>> year is to open the door to users (and me) learning to be power developers >>> nearer to you on the FFMPEG team. It also templates for a large swatch of >>> other types of code that need MCPs. >>> >>> I hope that you will take me under your wing with whatever working group >>> you know exists. >>> If this is better suited for a different email discussion list then my >>> apologies, and if any of you have received emails from me before asking for >>> contract opportunities you can reach out too. >>> >>> It would be *wonderful* to achieve sophisticated designs on par with >>> TikTok using fast, easy, and efficient LLM interactions with FFMPEG, for >>> the entire broader developer community. It would unbox FFMPEG for being the >>> drivers of these platforms themselves, and I am almost certain there are >>> cognate kids and developers to you all that would love to build that suite >>> over an upcoming year for their portfolios, job applications, own startups, >>> and more, starting here. >>> >>> Warm regards, >>> Bernat >>> >>> David Bernat, Ph. D. >>> Property of Starlight LLC. >>> >> _______________________________________________ >>> Libav-user mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ Libav-user mailing list -- [email protected] To unsubscribe send an email to [email protected]
