FFmpeg 6.0 Will Be Big With AV1 Hardware Decoding, Many Other Features

[schmidtbag]

FFmpeg is 91.5% C and 6.6% assembly. No Rust.

I wish it was written in Rust so it would be safer.

If you're really that concerned about the safety of your media transcoding, I think you need to reevaluate where you're getting it from.

[brad0]

I wish it was written in Rust so it would be safer.

Canonical packages Firefox and Chrome as Snap packages which is great.
I wish VLC media player, mpv, MPlayer, MPlayer2, SMPlayer and other media players could also be sandboxed to improve their security in case there is a vulnerability in the FFmpeg decoder.

I need stuff that is actually buildable and portable, not idiotic ideology.

[brad0]

Gotcha, let's rebuild ffmpeg in pure Java! Write once, run everywhere

It's just as much of a joke. Write once, kinda sorta run some places.

[topolinik]

API breaks for deprecations, numerous YUV pix_fmt changes, AVFrame,
opacification, channel layouts, H.274

Wait, wait, wait!
H.274 ???

[discordian]

FFmpeg is 91.5% C and 6.6% assembly. No Rust.

I wish it was written in Rust so it would be safer.

But we are still not done rewriting everything in Java!

[quikee]

Wait, wait, wait!
H.274 ???

Yeah, there are many ITU identifiers for different things:

[MrCooper]

On Debian the firefox package doesn't depends on it, it just recommends it with the libavcodec59 or libavcodec-extra59 packages:

https://packages.debian.org/sid/firefox

AFAIK recommended packages are never installed by default, just the dependencies.

That was true in the early days, recommended packages have been installed by default for a while though.

[bug77]

FFmpeg is 91.5% C and 6.6% assembly. No Rust.

I wish it was written in Rust so it would be safer.

Canonical packages Firefox and Chrome as Snap packages which is great.
I wish VLC media player, mpv, MPlayer, MPlayer2, SMPlayer and other media players could also be sandboxed to improve their security in case there is a vulnerability in the FFmpeg decoder.

Nothing is going to be rewritten in Rust, unless it has major issues in its current implementation.

I'm pretty sure Rust would have eased much of the pain of implementing multithreading for CLI in this case, but you always have to watch out for ROI.

[Gusar]

Firefox uses ffmpeg for encumbered formats (h264, mp3, aac, ...). It has built-in decoders for royalty free formats (vp9, av1, opus, ...), so youtube will work even if your linux installation does not have ffmpeg installed, but twitch for example will not. And if ffmpeg is installed, Firefox uses a runtime loader instead of linking, that's why there's no hard dependency.

And as for uid313's constant rust shilling, FFmpeg is constantly being fuzzed by google (they want to be sure nothing crazy happens with the many many uploads to youtube), so even though it's written in C, it's basically the safest library there is.

[bug77]

Firefox uses ffmpeg for encumbered formats (h264, mp3, aac, ...). It has built-in decoders for royalty free formats (vp9, av1, opus, ...), so youtube will work even if your linux installation does not have ffmpeg installed, but twitch for example will not. And if ffmpeg is installed, Firefox uses a runtime loader instead of linking, that's why there's no hard dependency.

And as for uid313's constant rust shilling, FFmpeg is constantly being fuzzed by google (they want to be sure nothing crazy happens with the many many uploads to youtube), so even though it's written in C, it's basically the safest library there is.

The thing is, if it were written in Rust, development would move at a faster rate (with all the safeguards being enforced by the compiler and everything).
But even so, it's really hard to justify the initial investment. Not for ffmpeg, but for any C (or C++) project that has a relatively clean code base.