Hacker News Reader

Comment by IntelMiner | Hacker News Reader

I'm told that GPU-based encoding (Nvenc etc) can't possibly match a "brute force' CPU encode if you want truly tiny filesizes. Nvenc's encoder is also miserable in terms of quality

Does this "Vulkan based encoding" mean we'll be able to get the best of both worlds? A 'pure' software encoder, but with the massive parallelism of a GPU?

If so I'd be extremely excited. Getting to shrink my DVD and Blu Ray rip collection down by moving it all to AV1 at rest would massively reduce my storage cost

View on HN

> Does this "Vulkan based encoding" mean we'll be able to get the best of both worlds?

Unlikely. This is just a generic API to the same GPU backends; so you will not see more quality than nvenc.

What's the point of using Vulkan as an encoding API if the work is still being done on the CPU then? I'm not sure I understand

No, no, it's done on GPU.

Isn't Nvenc (and its equivalents) based on using a specific ASIC on the GPU, rather than Vulkan which (as I understand it?) is just "regular" GPU compute?

No, Vulkan has released a standard API for video encoding/decoding[1]. So you can use that to access the hardware rather than the proprietary APIs like nvenc.

[1]: https://www.khronos.org/assets/uploads/apis/Vulkan-Video-Dee...

Most GPU encoders are part ASIC, part regular GPGPU compute. That's what allowed AMD to increase the quality of their encoders via a driver update, but also why you can't add easily add entirely new codecs.

That said, outside of GPUs there are both FPGA-based and pure-ASIC hardware encoders that beat not just NVENC but even software encoding in terms of quality AND performance, such as AMD's Alveo lineup. https://www.amd.com/en/products/accelerators/alveo/ma35d.htm...

The Vulkan APi calls out to the same hardware. The benefit of using it via Vulkan is that you (in theory) don’t need to have multiple APIs for different GPU vendors.

It's also meant to make it (somewhat) easier to apply various GPGPU filters and scalers before encode or after decode, like HDR tonemapping. The OS usually has some method to do this while keeping the data in the GPU VRAM by passing a handle from one API subsystem to another but if it never leaves Vulkan you don't have to worry about getting that right.

The Vulkan API is just a common way to access NVENC and its AMD and Intel alternatives.

Which is very nifty. Part of the reason for me still being on Windows is that it gives you a common API to hardware encoders.

For your Bluray collection HEVC is still advisable at reasonable bit rates. AV1 really only beats it in fairly low bitrate scenarios. Plus the HDR story is much better with HEVC.

Ditto. Hell, the improvement of HEVC over H264 isn't even too significant at high bitrate (say, >10Mbps).

I'm a big fan of the film grain modelling in HEVC over h264 at almost any bit rate. It just makes everything look way less 'compressed' to me.

> Getting to shrink my DVD and Blu Ray rip collection down by moving it all to AV1 at rest would massively reduce my storage cost

SVT-AV1 is pretty fast these days, Almost every minor release added last year added an additional 10-50% speedup. So if you haven't checked it out for a year or so, you'll be amazed by how much quicker it has gotten. Just saying.

For best quality you absolutely need a two-pass encoding, where in the first pass you collect "statistics" which are used to allocate bitrate in the second pass where you do the actual encoding.

I don't think NVENC supports this workflow, which is a big reason it's not suitable for quality encoding.

That's only if you're targeting a given filesize, with a target quality you only need 1 pass

I was so hyped getting my hands on my 4070 to encode some Blu-ray. And I was massively disappointed how bad the quality of Nvenc is. I still think it's great for some use-cases like live streaming. But for encoding film - no!

Reply on news.ycombinator.com