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

  • yump
    replied
    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.
    Sure, you can crop it with ffmpeg, but then you have to reencode it with something, obviously not VCN because that'd just put the padding back. And in that case why not just use that alternate encoder (presumably SVT-AV1) to begin with?

    The only way a workaround would be possible is if the target container format has some way to specify a crop in the metadata. I don't know which ones (if any) do.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Jumbotron View Post
    Where would you begin such a software fix ?
    Seems like it would probably be possible to do something inside VAAPI in the driver? Maybe not, though, since they haven't.

    Leave a comment:


  • RealNC
    replied
    Pipewire video capture is a Wayland-only thing, right?

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • justinkb
    replied
    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?

    Leave a comment:

Working...
X