Announcement

Collapse
No announcement yet.

FFmpeg 4.3 Released With AMD AMF Encoding, Vulkan Support, AV1 Encode

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

  • #11
    Originally posted by frank007
    There is no reasons for not using ffmpeg+vdpau in all the famous browsers.
    Here's a reason: Copying the whole video stream(s) into GPU memory for decoding, then back into CPU memory for compositing together with the rest of the website (including things like CSS transformations and transparency effects on the/all video element(s)) and back again into the GPU for rendering kills any hardware decoding benefits.

    It took years of groundwork, but there is VAAPI hardware decoding available in Firefox Nightly Wayland now. It looks like X11 will follow these next few days/weeks. Maybe someone will pick up VDPAU once both of those are finished and pref'ed on by default.
    Last edited by johnp117; 16 June 2020, 06:08 PM.

    Comment


    • #12
      Originally posted by johnp117 View Post
      Here's a reason: Copying the whole video stream(s) into GPU memory for decoding, then back into CPU memory for compositing together with the rest of the website (including things like CSS transformations and transparency effects on the/all video element(s)) and back again into the GPU for rendering kills any hardware decoding benefits.

      It took years of groundwork, but there is VAAPI hardware decoding available in Firefox Nightly Wayland now. It looks like X11 will follow these next few days/weeks. Maybe someone will pick up VDPAU once both of those are finished and pref'ed on by default.
      VDPAU should be relatively easy now - AFAIK the main problem here is what you cited first, which is missing DMABUF support in the NVidia driver (or something similar). The only alternative (and only on X11) is using pixmaps, but there seem to be reasons to not want that either (bugs). So without any solution at hand to avoid the readback - there's probably no point in implementing VDPAU support.

      Comment


      • #13
        Originally posted by sdack View Post
        Maybe yours does this and because you're a drama queen. Mine however doesn't and stays at the lowest frequency.
        I honestly doubt me being a drama queen would have an impact of how my card changes clocks.

        Comment


        • #14
          Originally posted by aufkrawall View Post
          I honestly doubt me being a drama queen would have an impact of how my card changes clocks.
          Focusing on the problem might though. Look towards the software. Something other than FFmpeg's nvdec decoder will be driving your clocks up.

          Comment


          • #15
            Originally posted by sdack View Post
            Focusing on the problem might though. Look towards the software. Something other than FFmpeg's nvdec decoder will be driving your clocks up.
            Pascal can't even utilize its video decoder in its lowest pstate. If you got a Pascal card too, your numbers are rubbish. No idea about Turing. But I'll test it.

            Comment


            • #16
              Originally posted by johnp117 View Post
              Here's a reason: Copying the whole video stream(s) into GPU memory for decoding, then back into CPU memory for compositing together with the rest of the website (including things like CSS transformations and transparency effects on the/all video element(s)) and back again into the GPU for rendering kills any hardware decoding benefits.

              It took years of groundwork, but there is VAAPI hardware decoding available in Firefox Nightly Wayland now. It looks like X11 will follow these next few days/weeks. Maybe someone will pick up VDPAU once both of those are finished and pref'ed on by default.
              Technically it works on stock Firefox 77. But FF77 "is missing some important stability/performance VA-API fixes which hit Firefox 78.0 and are backported to Fedora Firefox package." per https://mastransky.wordpress.com/202...pi-on-wayland/. Not sure what fixes FF77 is missing but it's been working for me. He almost mentions that FF78 is available in the Developer/Beta versions. FF78 should be released to stable in 2 weeks.

              Comment


              • #17
                Originally posted by johnp117 View Post
                It took years of groundwork, but there is VAAPI hardware decoding available in Firefox Nightly Wayland now. It looks like X11 will follow these next few days/weeks. Maybe someone will pick up VDPAU once both of those are finished and pref'ed on by default.
                i think vdpau is abandoned by novideo and unavailable on wayland, so nobody can pick it up

                Comment


                • #18
                  Originally posted by pal666 View Post
                  i think vdpau is abandoned
                  Yeah, it's been a whole... 2 months since their last stable release. Obviously abandoned.

                  novideo
                  Take your stupid "novideo" meme and shove it up your ass.

                  Comment


                  • #19
                    Still no built-in Intel SVT support.

                    Also, there is something I do not understand with rav1e. People say being written in Rust makes it safer than C code and still fast but when I look at their Git, I see 62.1% of the code is Assembly. So, how is it safe if it is mostly written in the most unsafe (and performant) language ever? And how does that prove Rust's performance if this thing is written mostly in Assembly?
                    Maybe there is some deep difference I do not know with SVT-AV1 that justify this but when I look at SVT-AV1's Git, I see 91.8% C, 6.7% C++ and only 0.9% Assembly (SVT-AV1 is 5x bigger than rav1e, but that's still much less Assembly (~12x less), even in absolute numbers). So massive Assembly usage is definitely not required to get a performant encoder, at least when this encoder is written in C. This makes me think that rav1e people wanted to write their thing in Rust to prove that Rust could do what C can safer and still performant but then had to face reality; Rust is not as performant as C, and they had to use Assembly to get acceptable performance without having to rely on C, still loosing Rust's safety in the process.

                    Comment


                    • #20
                      Originally posted by frank007
                      I'm not interested in wayland and its compositors.
                      I might be wrong, but I think they really just want to watch 240p videos at 30fps in their browsers and somehow believe their expensive Nvidia cards should do this in hardware. They don't understand what hardware they really have and what it's capable of, because they only got it for playing games. They're like kids trying to find a parking spot at the local super market with an 18-wheel truck and then get upset when faced with reality. You don't see Chrome or Firefox using the hardware decoder by default, nor does MPV or VLC recommend it either. Any CPU these days has enough power to decode a simple video. The hardware decoders in these cards aren't meant for just watching videos any more. They're used to decode up to several thousands of frames per second, meaning, they're used to decode H.264/H.265 video streams from multiple cameras and stored files, process these with tools such as FFmpeg and encode them again. So now they're thinking that their expensive card should decode their cartoons in hardware at the lowest power state or else drama. Best is to ignore them.

                      Comment

                      Working...
                      X