Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • brucethemoose
    replied
    Originally posted by uid313 View Post

    Firefox and Chrome use FFmpeg too, and any website I visit can load some invisible video that I might not even see.
    Like: <video src="evil.mp4" height="0" width="0" autoplay muted />

    Even a trusted website can be hacked and changed into do this. Especially with all these third-party JavaScript dependencies, libraries and CDNs.
    Codecs, decoders and related systems are indeed an interesting vector for exploitation, but I think rewriting them in Rust (especially the vendor specific hardware decoders and the labor intensive software decoders) is not very practical or even necessarily useful.

    Leave a comment:


  • uid313
    replied
    Originally posted by schmidtbag View Post
    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.
    Firefox and Chrome use FFmpeg too, and any website I visit can load some invisible video that I might not even see.
    Like: <video src="evil.mp4" height="0" width="0" autoplay muted />

    Even a trusted website can be hacked and changed into do this. Especially with all these third-party JavaScript dependencies, libraries and CDNs.
    Last edited by uid313; 08 February 2023, 05:09 PM.

    Leave a comment:


  • bug77
    replied
    Originally posted by Gusar View Post
    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.

    Leave a comment:


  • Gusar
    replied
    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by uid313 View Post
    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.

    Leave a comment:


  • MrCooper
    replied
    Originally posted by Danny3 View Post
    On Debian the firefox package doesn't depends on it, it just recommends it with the libavcodec59 or libavcodec-extra59 packages:

    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.

    Leave a comment:


  • quikee
    replied
    Originally posted by topolinik View Post
    Wait, wait, wait!
    H.274 ???
    Yeah, there are many ITU identifiers for different things:
    ITU-T Recommendations,ITU-T,recommendation, ITU

    Leave a comment:


  • discordian
    replied
    Originally posted by uid313 View Post
    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!

    Leave a comment:


  • topolinik
    replied
    API breaks for deprecations, numerous YUV pix_fmt changes, AVFrame,
    opacification, channel layouts, H.274
    Wait, wait, wait!
    H.274 ???

    Leave a comment:


  • brad0
    replied
    Originally posted by Espionage724
    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.

    Leave a comment:

Working...
X