FFmpeg Lands CLI Multi-Threading As Its "Most Complex Refactoring" In Decades

[caligula]

I wonder if this makes tools like openshot, kdenlive any faster?

[Quackdoc]

I wonder if this makes tools like openshot, kdenlive any faster?

Why would it? this explicitly says cli multithreading

[slalomsk8er]

It's not just Windows. Plenty of Linux distributions don't ship with FFmpeg by default or ship versions that don't have the same feature set, ABI etc that that the bundled version has. As I already noted before, you can't rely on an external version even it exists because among other things distributions change the defaults or patch out codecs since FFmpeg doesn't support plugins. There is zero platform stability that any browser can rely on for multimedia on Linux, Windows or anywhere else really.

If the browser vendor provide a deb or rpm on the website for sure bundle it but if the browser is packaged by the maintainers of the distribution repository then there is supposed to be a compatible version of FFmpeg packaged and modeled as a dependency. Guess why Flatpaks and Snaps are so useful for distribution of fast changing software like a browser

[marlock]

it would be a plus if distros start updating ffmpeg more frequently as a byproduct of firefox updates... but then again it would be more likely they don't and firefox breaks (some video features or entirely) because distros often package updates without thoroughly testing stuff...

[spicfoo]

If the browser vendor provide a deb or rpm on the website for sure bundle it but if the browser is packaged by the maintainers of the distribution repository then there is supposed to be a compatible version of FFmpeg packaged and modeled as a dependency. Guess why Flatpaks and Snaps are so useful for distribution of fast changing software like a browser

If a distribution ships with a version of FFmpeg that has an API different from the one that Firefox ships with, then they have to patch Firefox. Once you patch Firefox, you must rename it and can't call it Firefox anymore c.f. Debian and Iceweasel. As usual things are more complicated than one might think.

[marlock]

are FFmpeg APIs that unstable, or is this a hipothetical that could be handled easily in the few cases it actually happens?

i get that historically linux had several deeply breaking changes in many APIs, and some lib dev teams still do this (out of real need or out of culturally not prioritizing API stability), but it's something that seems to be improving significantly over the years, and I wonder where ffmpeg fits this spectrum nowadays...

eg: is the CLI multithreading change introducing new APIs? are the old APIs preserved or modified? are these breaking changes or backwards compatible?

on the other end of the rope, is Firefox reallygonna have such a hard time querying the available ffmpeg version and deciding on how to call it from a couple codepaths that work for some lib version ranges? does ffmpeg offer capability querying or API version querying so firefox can pick codepaths like games choose graphics API codepaths according to vulkan or opengl capabilities and API versions?

[caligula]

Why would it? this explicitly says cli multithreading

I didn't realize this was only for the CLI. It sounds like that kind of refactoring would also help when using ffmpeg as a library (like those video editors do, perhaps).

[Quackdoc]

I didn't realize this was only for the CLI. It sounds like that kind of refactoring would also help when using ffmpeg as a library (like those video editors do, perhaps).

It could be possible some this work could help some tooling, but I didnt dive to deep. the library can already be implemented in a multi threaded way applications side.

are FFmpeg APIs that unstable, or is this a hipothetical that could be handled easily in the few cases it actually happens?

i get that historically linux had several deeply breaking changes in many APIs, and some lib dev teams still do this (out of real need or out of culturally not prioritizing API stability), but it's something that seems to be improving significantly over the years, and I wonder where ffmpeg fits this spectrum nowadays...

eg: is the CLI multithreading change introducing new APIs? are the old APIs preserved or modified? are these breaking changes or backwards compatible?

on the other end of the rope, is Firefox reallygonna have such a hard time querying the available ffmpeg version and deciding on how to call it from a couple codepaths that work for some lib version ranges? does ffmpeg offer capability querying or API version querying so firefox can pick codepaths like games choose graphics API codepaths according to vulkan or opengl capabilities and API versions?

they really aren't THAT bad, it DOES have a lot of API breakage, but it's also a pretty sizeable library, but man, if you use those features... Lets just say there is a reason some apps still target 4.4

[AlanTuring69]

are FFmpeg APIs that unstable, or is this a hipothetical that could be handled easily in the few cases it actually happens?

i get that historically linux had several deeply breaking changes in many APIs, and some lib dev teams still do this (out of real need or out of culturally not prioritizing API stability), but it's something that seems to be improving significantly over the years, and I wonder where ffmpeg fits this spectrum nowadays...

eg: is the CLI multithreading change introducing new APIs? are the old APIs preserved or modified? are these breaking changes or backwards compatible?

on the other end of the rope, is Firefox reallygonna have such a hard time querying the available ffmpeg version and deciding on how to call it from a couple codepaths that work for some lib version ranges? does ffmpeg offer capability querying or API version querying so firefox can pick codepaths like games choose graphics API codepaths according to vulkan or opengl capabilities and API versions?

You're vastly over-simplifying video playback in the browser. You're not the first person to think of using ffmpeg, a widely available piece of software which has existed for decades, and the fact nobody is using it should speak for itself. There's all sorts of things to think about now like how you're going to efficiently display the frames because copying 1920x1080 pixels (or even 3840x2160) 60 times a second is not trivial and so you have to integrate the decoder basically directly integrated with the GPU to where it does not copy. Making ffmpeg do that is very finicky.

[marlock]

i'm not an expert on any of it, and I'm really asking, not rethorically

also about that specific example, isn't that true to windowed video players as well, ergo something that a video decoding lib like ffmpeg should handle anyway? what's different about doing it to an html canvas target instead of the video player window target?