VP9 Support in VoukoderPro

  • Hey!

    Firstly, let me thank you for this great piece of software, it's very helpful and brings much-needed functionality to NLEs that they should have natively in the first place.

    I was looking for a codec to use as both intermediary and for delivery and VP9 seems to be the most well-rounded for that purpose as far as I was able to see up till now. I've tried AV1, but it's very slow in scrubbing/reverse playback, so I don't really wanna use it. Unfortunately, VP9 is missing in VoukoderPro and I'm having a few issues with the regular version, so I wanted to ask whether you could add VP9 to Pro?

    The regular Voukoder is starting up very slowly in Resolve (I'm on 18.5 right now, on Windows 11, RTX3060, Intel 13th Gen CPU) and also a few features don't seem to be working. If I select the QSV version of VP9 that seems to be a lot less CPU intensive and faster, I always get unusably small file sizes and no matter what settings I change, the size always stays the same. Also, I very much prefer the node interface in Pro and the possibility to manage presets.

    Thanks for your attention and best regards!

  • Vouk 6. September 2023 um 05:05

    Hat das Thema freigeschaltet.
  • Thanks so much for implementing this so swiftly! I've been trying around for a couple hours and I still have the issues I was having with VP9 in the Non-Pro version. Let me try to elaborate:

    When I use the QSV version of VP9, it encodes very quickly (about the speed I get with NVENC HEVC on my RTX 3060), but the bitrate is locked to 1.000 kb/s and doesn't change when adjusting parameters if I use either Constant Quantizer or Intelligent Constant Quality. If I switch to average VBR or CBR, the bitrate and file size change according to the parameters, but the footage is flawed in different ways, sometimes it plays kind of fine until I scrub after which it then gets blocky, falls completely apart or is a blotchy mess from the get-go. In the cases the encoding is quick as described above, I have high utilization of both the RTX and the iGPU of the 13th Gen Intel. If I use libvpx, it takes very, very long (about 10 times as much), the iGPU isn't used at all, the RTX utilization is rather low and the GPU is scorching, but the footage is actually fine. Also, libvpx does 10-bit without a problem, while the QSV mode sometimes doesn't even start if I choose YUV 10-bit with Resolve throwing a codec error when trying to fire the render.

    I would just use NVENC HEVC, but I frequently get glitches with complex animations when rendering directly to h264 or 265, possibly because of my limited 12 gig VRAM. Using VP9 seems to use a lot less VRAM and doesn't exhibit the glitches (if it works). I could also try and disable the iGPU, but I do appreciate it for faster timeline scrubbing in Resolve and it seems to help in some encoding processes as well, but I wouldn't be surprised if it was the main culprit due to the added complexity and less refinement in this unusual/less-explored setup.

    I am aware that my 3060 doesn't do AV1 encoding natively and my CPU doesn't, either, but they should both support VP9 even with 10-bit, so I'd really love to pull this off without having to encode to a space-intensive codec like ProRes or DNXHR first. But I really have no insight into whether it is my setup or the VP9 implementation in Voukoder. Let me know if I can help to figure this out.


    Gee-whiz, I had no idea how complicated the hardware encoding situation for these codecs is. The only thing that sounded half-promising that I could find is this fairly recent entry, but apparently it needs WSL, I have no idea how difficult this would be to utilize:

    Video acceleration API (VA-API) now available on Windows! - DirectX Developer Blog
    Introduction What’s VA-API? Originally developed by Intel, VAAPI (Video Acceleration API) is an open-source library and API specification, which provides…
    devblogs.microsoft.com

    Einmal editiert, zuletzt von Vouk (8. September 2023 um 16:32) aus folgendem Grund: Ein Beitrag von ambrals mit diesem Beitrag zusammengefügt.

  • I found the issue (or one of them, I wouldn't be surprised if it was multiple), it's in the Intel drivers and/or ffmpeg. vp9_qsv ffmpeg encodes have issues with GoP/I-frames and seeking breaks the playback amongst other things.

    [Bug]: Quick Sync/FFmpeg produces files with only one single I-Frame at the beginning Arc A380 DG2 · Issue #1576 · intel/media-driver
    Which component impacted? Decode probably Is it regression? Good in old configuration? None What happened? Wenn trying to transcode a h264 or hevc file via…
    github.com

    I really hope this gets fixed at some point, the hardware acceleration on the new Intel CPUs/iGPUs is excellent, you should look into it if you haven't already. But most of the scene seems to have lost interest in it long ago, because it wasn't working properly. Lavfilters have all but dropped the QSV support. If you read up on the Emby forums e. g. you can see people talking about the latest gen Intel iGPUs easily beating dGPUs in terms of speed and efficiency in transcodes.

    Intel UHD Graphics 770 vs RTX 3050 for Transcoding if.....
    I have a server PC with an Intel i7-13700k (UHD 770). I'm currently using it for very intense NZB downloads, respective ARR services, a VM (Home Assistant),…
    emby.media

    So, when this gets fixed in the drivers, there's also gonna be requirements for the parameters that are needed, I'll look into that when the time comes.

    Einmal editiert, zuletzt von ambrals (9. September 2023 um 15:11)