[TomSwirly]

> But what are the odds that obscure formats like this will be implemented (and maintained) without security holes?

Extremely high?

I wrote a stand-alone commercial DSP app which seems to still be sold ten years later. There might be security issues, there probably are since it hasn't been recompiled in years as far as I know, but I'm certain they aren't in the DSP parts.

DSP code involves large blocks of numbers which you translate into other numbers. If you're writing a format or facility within ffmpeg, you aren't directly reading or writing to files, or connecting to the Internet. It's probably that the whole API you write to is just blocks of numbers and some sort of data description.

ffmpeg as a whole might have security violations in it but adding new plug-ins or format won't necessarily increase those chances.

[stefan_]

The problem is that when you use ffmpeg, you generally delegate the task of figuring out "what the hell is this data" to it - you don't want to figure out yourself if something is MP3, MP3 in an AVI container, VP9 in MKV, ...

So when ffmpeg adds obscure formats that no one ever uses and are mostly toy implementations, the risk is always that someone at the top (say, your Electron app) feeds in user-supplied data, the 10 layers in between pass it along, until ffmpeg at the bottom goes "oh I know this one, it's a Digital Pictures SGA game"!

Now Chromium wisely disables most of this trap code in its copy of ffmpeg from even being compiled in the first place, but that's probably not the case for the ffmpeg copy on your operating system that you might use for some server-side processing task.