Announcement

Collapse
No announcement yet.

OBS Studio 30.1 Released With AV1 Support For VA-API & PipeWire Video Capture

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

  • OBS Studio 30.1 Released With AV1 Support For VA-API & PipeWire Video Capture

    Phoronix: OBS Studio 30.1 Released With AV1 Support For VA-API & PipeWire Video Capture

    Building off last November's release of the big OBS Studio 30.0 release, OBS Studio 30.1 debuted today as the newest feature release...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Congrats!

    How does it work in conjunction with this bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9185

    Did ffmpeg provide some workaround?

    Comment


    • #3
      Originally posted by shmerl View Post
      Congrats!

      How does it work in conjunction with this bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9185

      Did ffmpeg provide some workaround?
      Now you've got me interested. What's the actual impact of this bug? Is it not possible to postprocess this data after the encode to crop it to the right dimensions? Or does that incur a severe cost of some kind?

      Comment


      • #4
        Originally posted by justinkb View Post

        Now you've got me interested. What's the actual impact of this bug? Is it not possible to postprocess this data after the encode to crop it to the right dimensions? Or does that incur a severe cost of some kind?
        I'm not sure 100% but it sounds like there must be some software workaround, since hardware has a defect.

        Comment


        • #5
          There's no fix. Someone on the thread named Ruijing Dong, seemingly from AMD, stated that after talking with "our HW/FW team"...(which makes me think he works for AMD) there will be no fix until VCN 5 is released on even newer hardware. This workaround by them is that AMD VCN 4 enabled hardware will go to the lowest wrong number of pixels possible to downplay the black padding. example, for a standard HD frame with 1080 height the frame will be 1082 instead.

          Comment


          • #6
            Originally posted by Jumbotron View Post
            There's no fix. Someone on the thread named Ruijing Dong, seemingly from AMD, stated that after talking with "our HW/FW team"...(which makes me think he works for AMD) there will be no fix until VCN 5 is released on even newer hardware. This workaround by them is that AMD VCN 4 enabled hardware will go to the lowest wrong number of pixels possible to downplay the black padding. example, for a standard HD frame with 1080 height the frame will be 1082 instead.
            There is no way to fix hardware, but why can't that be worked around with software? I.e. render with extra bands, then clip it (in ffmpeg), no?

            It would be weird if hardware starts decreasing dimension values, becasue that's super confusing but increasing is OK, because as above it can be clipped.
            Last edited by shmerl; 13 March 2024, 03:37 PM.

            Comment


            • #7
              I also wonder why this can't be worked around in software, even in the driver itself. Cutting 2 pixel rows off of a video is extremely quick, afaik.

              Comment


              • #8
                Originally posted by shmerl View Post

                There is no way to fix hardware, but why can't that be worked around with software? I.e. render with extra bands, then clip it (in ffmpeg), no?

                It would be weird if hardware starts decreasing dimension values, becasue that's super confusing but increasing is OK, because as above it can be clipped.
                Where would you begin such a software fix ? Would you expect everyone down the software stack from AMD apply a software fix ? Would this be ffmpeg’s responsibility now that AMD dropped the hardware ball …if this is confirmed further ? If not ffmpeg then what encoding software maintainer now must shoulder the burden multiplied by x number of encoding solutions out there ?

                If VCN 4 is indeed broken then AMD needs to cop to it and at least provide a hardware fix on relevant AMD CPUs that have another processor core like a DSP or FPGA or Xlinx IP that can run FPGA like ops on the CPU or GPU that can override the rendering before final output. Just stating too bad wait for VCN 5 hardware is a complete FU to loyal AMD fans and clients. Better yet, a recall and replacement program is in order .

                Comment


                • #9
                  Originally posted by Jumbotron View Post

                  Where would you begin such a software fix ? Would you expect everyone down the software stack from AMD apply a software fix ? Would this be ffmpeg’s responsibility now that AMD dropped the hardware ball …if this is confirmed further ? If not ffmpeg then what encoding software maintainer now must shoulder the burden multiplied by x number of encoding solutions out there ?
                  There is no way to fix existing hardware, how do you expect that to work? The chip is already out in many devices. They could make a revision with a fix if they wanted to (expensive but not impossible) but that still not going to help already defective ones that are out, only newly produced ones.

                  So yeah. I expect software fix being the only way to mitigate that for existing defective hardware. ffmpeg can have some quirks support for that. Not sure who else might care.

                  Comment


                  • #10
                    Pipewire video capture is a Wayland-only thing, right?

                    Comment

                    Working...
                    X