6 ms·

Video Encoding and Decoding with Vulkan Compute Shaders in FFmpeg

166 points by y1n0 7mo ago

sylware 7mo ago
Well, the problem with hardware decoding is it cannot handle all the variations in data corruption which results in hardware crash, sometimes not recoverable with a soft reset of the hardware block. It is usually more reasonable to work with software decoders for really complex formats, or only to accelerate some heavy parts of the decoding where data corruption is really easy to deal with or benign, or aim for the middle ground: _SIMPLE_ and _VERY CONSERVATIVE_ compute shaders. Sometimes, the software cannot even tell the hardware is actually 'crashed' and spitting non-sense data. It goes even worse, some hardware block hot reset actually do not work and require a power cycle... Then a 'media players' able to use hardware decoding must always provide a clear and visible 'user button' in order to let this very user switch to full software decoding. Then, there is the next step of "corruption": some streams out there are "wrong", but this "wrong" will be decoded ok on only some specific decoders and not other ones even though the format is following the same specs. What a mess. I hope those compute shaders are not using that abomination of glsl(or the dx one) namely are SPIR-V shaders generated with plain and simple C code.
- pandaforce 7mo ago
  These are all gripes you might have with Vulkan Video. Unlike with Vulkan Video, in Compute, bounds checking is the norm. Overreading a regular buffer will not result in a GPU hang or crash. If you use pointers, it will, but if you use pointers, its up to you to check if overreads can happen. The bitstream reader in FFmpeg for Vulkan Compute codecs is copied from the C code, along with bounds checking. The code which validates whether a block is corrupt or decodable is also taken from the C version. To date, I've never got a GPU hang while using the Compute codecs.
  - averne_ 7mo ago
    I wrote the Vulkan ProRes backend. The bitstream decoder was implemented from scratch, for a number of reasons. First, the original code was reverse-engineered, before Apple published an SMPTE document describing the bitstream syntax. Second, I tried my best at optimizing the code for GPU hardware. And finally, I wanted take the learning opportunity :) And to answer the parent's question, the shaders are written in pure GLSL. For instance, this is the ProRes bitstream decoder in question: https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/master/libavcodec/vulkan/prores_vld.comp.glsl https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/master/liba...
    - sylware 7mo ago
      glsl: this is the really bad part, as this is a definitive nono. Should have been a plaind and simple C coded generator of SPIR-V byte code.
positron26 7mo ago
> Most popular codecs were designed decades ago, when video resolutions were far smaller. As resolutions have exploded, those fixed-size minimum units now represent a much smaller fraction of a frame — which means far more of them can be processed in parallel. Modern GPUs have also gained features enabling cross-invocation communication, opening up further optimization opportunities. One only needs to look at GPU driven rendering and ray tracing in shaders to deduce that shader cores and memory subsystems these days have become flexible enough to do work besides lock-step uniform parallelism where the only difference was the thread ID. Nobody strives for random access memory read patterns, but the universal popularity of buffer device address and descriptor arrays can be taken somewhat as proof that these indirections are no longer the friction for GPU architectures that they were ten years ago. At the same time, the languages are no longer as restrictive as they once were. People are recording commands on the GPU. This kind of fiddly serial work is an indication that the ergonomics of CPU programming have less of a relative advantage, and that cuts deeply into the tradeoff costs.
- pandaforce 7mo ago
  Yeah, Vulkan is shedding most of the abstractions off. Buffers are no longer needed - just device addresses. Shaders don't need to be baked into a pipeline - you can use shader objects. Even images rarely provide any speedup advantages over buffers, since texel cache is no longer separate from memory cache. GPUs these days have massive cache often hundreds of megabytes large, on top of an already absurd amount of registers. A random read will often load a full cacheline into a register and keep it there, reusing it as needed between invocations.
- mort96 7mo ago
  These GPUs are still big SIMD devices at their core though, no?
  - pandaforce 7mo ago
    Yes, but no. No, in that these days, GPUs are entirely scalar from the point of view of invocations. Using vectors in shaders is pointless - it will be as fast as scalar variables (double instruction dispatch on AMD GPUs is an exception). But yes from the point of view that a collection of invocations all progressing in lockstep get arithmetic done by vector units. GPUs have just gotten really good at hiding what happens with branching paths between invocations.
doctorpangloss 7mo ago
What is the use case? Okay, ultra low latency streaming. That is good. But. If you are sending the frames via some protocol over the network, like WebRTC, it will be touching the CPU anyway. Software encoding of 4K h264 is real time on a single thread on 65w, decade old CPUs, with low latency. The CPU encoders are much better quality and more flexible. So it's very difficult to justify the level of complexity needed for hardware video encoding. Absolutely no need for it for TV streaming for example. But people keep being obsessed with it who have no need for it. IMO vendors should stop reinventing hardware video encoding and instead assign the programmer time to making libwebrtc and libvpx better suit their particular use case.
- eptcyka 7mo ago
  It will be more energy efficient. And the CPU is free to jit half a gig of javascript in the mean time.
  - temp0826 7mo ago
    It's hugely more efficient, if you're on a battery powered device it could mean hours more of play time. It's pretty insane just how much better it is (I go through a bit of extra effort to make sure it's working for me, hw decoding isn't includes in some distros).
- xattt 7mo ago
  It’s a leftover mindset from the mid-2000s when GPGPU became possible, and additional performance was “unlocked” from an otherwise under-utilized silicon.
- jpc0 7mo ago
  I'm not entirely sure that this is true. I haven't actually looked into this but it might not be the realm of possibility. But you are generating a frame on GPU, if you can also encode it there, either with nvenc or vulkan doesn't matter. Then DMA the to the nic while just using the CPU to process the packet headers, assuming that cannot also be handled in the GPU/nic
hirako2000 7mo ago
Vulkan Compute shaders make GPU acceleration practical for intensive codecs like FFv1, ProRes RAW, and DPX. Previous hybrid GPU + CPU suffered the round-trip latency. These are fully GPU hands offs. A big deal for editing workflows.
pandaforce 7mo ago
The main target for this are NLEs like Blender. Performance is a large part of the issue. Most users still just create TIFF files per frame before importing them into a "real editor" like Resolve. Apple may have ASICs for ProRes decoding, and Resolve may be the standard editor that everyone uses. But this goes beyond what even Apple has, by making it possible to work directly with compressed lossless video on consumer GPUs. You can get hundreds of FPS encoding or decoding 4k 16-bit FFv1 on a 4080, while only reading a few gigabits of video per second, rather than tens and even hundreds of gigabits that SSDs can't keep up. No need to have image degradation when passing intermediate copies between CG programs and editing either.
- dagmx 7mo ago
  I don’t understand the spread of thoughts in your post. The reason to create image sequences is not because you need to send it to other apps, it’s because you preserve quality and safeguard from crashes. A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame. People aren’t going to stop using image sequences even if they stayed in the same app. And I’m not sure why this applies: “this goes beyond” what Apple has, because they do have hardware support for decoding several compressed codecs (also I’ll note that ProRes is also compressed). Other than streaming, when are you going to need that kind of encode performance? Or what other codecs are you expecting will suddenly pop up by not requiring ASICs? Also how does this remove degradation when going between apps? Are you envisioning this enables Blender to stream to an NLE without first writing a file to disk?
  - pandaforce 7mo ago
    > A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame. You wouldn't contain FFv1 in MP4, the only format incompetent enough for such corruption. Apple has an interest against people using codecs that they get no fees from. And Apple don't have a lossless codec. So they don't offer lossless compressed video acceleration. The idea is that when working as a part of a team, and you get handed a CG render, you can avoid sending a huge .tar or .zip file full of TIFF which you then decompress, or ProRes which loses quality, particularly when in a linear colorspace like ACEScg.
null-phnix 7mo ago
A lot of the confusion in this thread feels like it comes from thinking in terms of web streaming rather than the workloads this post is targeting. The article is pretty explicit that this is not about "make Twitch more efficient" or squeezing a bit more perf out of H.264. It is about mezzanine and archival formats that are already way beyond what a single CPU, even a decade old workstation CPU, handles comfortably in real time: 4K/6K/8K+ 16‑bit, FFv1-style lossless, ProRes RAW, huge DPX sequences, etc. People cutting multi‑camera timelines of that kind of material are already on the wrong side of the perf cliff and are often forced into very specific hardware or vendors. What Vulkan compute buys you here is not "GPUs good, CPUs bad", it is the ability to keep the entire codec pipeline resident on the GPU once the bitstream is there, using the same device that is already doing color, compositing and FX, and to do it in a portable way. FFmpeg’s model is also important: all the hairy parts stay in software (parsing, threading, error handling), and only the hot pixel crunching is offloaded. That makes this much more maintainable than the usual fragile vendor API route and keeps a clean fallback path when hardware is not available. From a practical angle, this is less about winning a benchmark over a good CPU encoder for 4K H.264, and more about changing what is feasible on commodity hardware: e.g., scrubbing multiple streams of 6K/8K ProRes or FFv1 on a consumer GPU instead of needing a fat workstation or dailies transcoded to lighter proxies. For people doing archival work or high end finishing on a budget, that is a real qualitative change, not just an incremental efficiency tweak.
- Teknoman117 7mo ago
  To add to what you said, it’s also nice to be able to keep it within one API that’s platform agnostic when possible. Sure we’ve had the ability to keep the pipeline on GPU for awhile, but it usually required platform specific API bindings to convert to a platform specific descriptor (handles on windows, IOSurface on macOS, dmabuf on Linux), which you then had to pull into a platform specific decoder/encoder API (DXGI, WMF, AVFoundation, VAAPI, etc.), and then all of that again but in reverse to get the surface back into your 3D API. This whole thing just makes life easier for everyone.
  - null-phnix 7mo ago
    Exactly. The cross-platform descriptor dance is one of those things that's invisible to people outside the pipeline but eats an absurd amount of dev time. You end up writing the same conversion logic three times for three platforms, each with its own failure modes and version quirks, and none of it has anything to do with the actual codec work. Having Vulkan as the single surface for both the compute and the rendering side means one memory model, one synchronization story, one set of bugs to chase. That alone is worth the effort even before you get to the performance wins.
fhn 7mo ago
This article assumes all GPUs are on a PCIe bus but some are part of the CPU so the distance problem is minimal and offloading to GPU might still be net +. Might because I haven't tested this
kvbev 7mo ago
could this have an AV1 decoder for low power hardware that are without AV1 gpu accelerated decoding? for my N4020 laptop. maybe a raspberry pi 4 too.
jokoon 7mo ago
I once asked on #ffmpeg@libera if the GPU could be used to encode h264, and apparently yes, but it's not really worth it compared to CPU. I don't know much about video compression, does that mean that a codec like h264 is not parallelizable?
- marci 7mo ago
  I think it's mostly because most cpus that can run a gpu already have parts dedicated as h264 encoder, way more efficient energy wise and speed wise.
- ablob 7mo ago
  Common video codecs are often hardware accelerated. This should be on the CPU side quite often, as there are a lot of systems without dedicated GPUs that still play video, like Notebooks and smart phones. So in the end it's less about being parallelizable, but if it beats dedicated hardware, to which the answer should almost always be no. P.S.: In video decoding speed is only relevant up to a certain point. That being: "Can I decode the next frame(s) in time to show it/them without stuttering". Once that has been achieved other factors such as power drainage become more important.
  - craftkiller 7mo ago
    It is my understanding that hardware accelerated video encoders (as in the fixed-function ones built into consumer GPUs) produce a lower quality output than software-based encoders. They're really only there for on-the-fly encoding like streaming to twitch or recording security camera footage. But if you're encoding your precious family memories or backing up your DVD collection, you want to use software encoders. Therefore, if a hypothetical software h264 encoder could be faster on the GPU, it would have value for anyone doing not-on-the-fly encoding of video where they care about the quality. One source for the software encoder quality claim is the "transcoding" section of this article: https://chipsandcheese.com/i/138977355/transcoding https://chipsandcheese.com/i/138977355/transcoding
  - asmosoinio 7mo ago
    > ... That being: "Can I decode the next frame(s) in time to show it/them without stuttering". Except when you are editing video, or rendering output. When you have multiple streams of very high definition input, you definitely need much more than realtime speed decoding of a single video. And you would want to scrub around the video(s), jumping to any timecode, and get the target frame preferably showing as soon as your monitor refreshes.
returnorthrow 7mo ago
I was just reading about this topic last night on Maister’s Graphics Adventures: https://themaister.net/blog/2025/06 https://themaister.net/blog/2025/06. They created PyroWave, a GPU-accelerated DWT codec in Vulkan compute shaders for performing very low latency game streaming. Very fascinating read, and builds on similar work from their master’s thesis too.
- pandaforce 7mo ago
  That's basically what VC-2 is, as well as JPEG2000-HT. Wavelets are nice in that they have no need for deblocking since each slice complements one another, and they're simple to calculate. But this localization means they're horrible for compression since they have bad frequency decomposition properties. JPEG2000 showed that.
reactordev 7mo ago
This makes vision models go “Oooooo”. /s Honestly, everything now is just math. It’s all about how much you can do at once. Vulkan being Vulkan, that ceiling is your hardware. Go ham.
- pandaforce 7mo ago
  Most vision models are trained on images or conventional video codecs. There's a good reason why H200's have 7 JPEG + 7 nvdec ASICS.

166 points by y1n0 7mo ago

Well, the problem with hardware decoding is it cannot handle all the variations in data corruption which results in hardware crash, sometimes not recoverable with a soft reset of the hardware block. It is usually more reasonable to work with software decoders for really complex formats, or only to accelerate some heavy parts of the decoding where data corruption is really easy to deal with or benign, or aim for the middle ground: _SIMPLE_ and _VERY CONSERVATIVE_ compute shaders. Sometimes, the software cannot even tell the hardware is actually 'crashed' and spitting non-sense data. It goes even worse, some hardware block hot reset actually do not work and require a power cycle... Then a 'media players' able to use hardware decoding must always provide a clear and visible 'user button' in order to let this very user switch to full software decoding. Then, there is the next step of "corruption": some streams out there are "wrong", but this "wrong" will be decoded ok on only some specific decoders and not other ones even though the format is following the same specs. What a mess. I hope those compute shaders are not using that abomination of glsl(or the dx one) namely are SPIR-V shaders generated with plain and simple C code.

pandaforce 7mo ago
These are all gripes you might have with Vulkan Video. Unlike with Vulkan Video, in Compute, bounds checking is the norm. Overreading a regular buffer will not result in a GPU hang or crash. If you use pointers, it will, but if you use pointers, its up to you to check if overreads can happen. The bitstream reader in FFmpeg for Vulkan Compute codecs is copied from the C code, along with bounds checking. The code which validates whether a block is corrupt or decodable is also taken from the C version. To date, I've never got a GPU hang while using the Compute codecs.
- averne_ 7mo ago
  I wrote the Vulkan ProRes backend. The bitstream decoder was implemented from scratch, for a number of reasons. First, the original code was reverse-engineered, before Apple published an SMPTE document describing the bitstream syntax. Second, I tried my best at optimizing the code for GPU hardware. And finally, I wanted take the learning opportunity :) And to answer the parent's question, the shaders are written in pure GLSL. For instance, this is the ProRes bitstream decoder in question: https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/master/libavcodec/vulkan/prores_vld.comp.glsl https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/master/liba...
  - sylware 7mo ago
    glsl: this is the really bad part, as this is a definitive nono. Should have been a plaind and simple C coded generator of SPIR-V byte code.

positron26 7mo ago

> Most popular codecs were designed decades ago, when video resolutions were far smaller. As resolutions have exploded, those fixed-size minimum units now represent a much smaller fraction of a frame — which means far more of them can be processed in parallel. Modern GPUs have also gained features enabling cross-invocation communication, opening up further optimization opportunities. One only needs to look at GPU driven rendering and ray tracing in shaders to deduce that shader cores and memory subsystems these days have become flexible enough to do work besides lock-step uniform parallelism where the only difference was the thread ID. Nobody strives for random access memory read patterns, but the universal popularity of buffer device address and descriptor arrays can be taken somewhat as proof that these indirections are no longer the friction for GPU architectures that they were ten years ago. At the same time, the languages are no longer as restrictive as they once were. People are recording commands on the GPU. This kind of fiddly serial work is an indication that the ergonomics of CPU programming have less of a relative advantage, and that cuts deeply into the tradeoff costs.

pandaforce 7mo ago
Yeah, Vulkan is shedding most of the abstractions off. Buffers are no longer needed - just device addresses. Shaders don't need to be baked into a pipeline - you can use shader objects. Even images rarely provide any speedup advantages over buffers, since texel cache is no longer separate from memory cache. GPUs these days have massive cache often hundreds of megabytes large, on top of an already absurd amount of registers. A random read will often load a full cacheline into a register and keep it there, reusing it as needed between invocations.
mort96 7mo ago
These GPUs are still big SIMD devices at their core though, no?
- pandaforce 7mo ago
  Yes, but no. No, in that these days, GPUs are entirely scalar from the point of view of invocations. Using vectors in shaders is pointless - it will be as fast as scalar variables (double instruction dispatch on AMD GPUs is an exception). But yes from the point of view that a collection of invocations all progressing in lockstep get arithmetic done by vector units. GPUs have just gotten really good at hiding what happens with branching paths between invocations.

doctorpangloss 7mo ago

What is the use case? Okay, ultra low latency streaming. That is good. But. If you are sending the frames via some protocol over the network, like WebRTC, it will be touching the CPU anyway. Software encoding of 4K h264 is real time on a single thread on 65w, decade old CPUs, with low latency. The CPU encoders are much better quality and more flexible. So it's very difficult to justify the level of complexity needed for hardware video encoding. Absolutely no need for it for TV streaming for example. But people keep being obsessed with it who have no need for it. IMO vendors should stop reinventing hardware video encoding and instead assign the programmer time to making libwebrtc and libvpx better suit their particular use case.

eptcyka 7mo ago
It will be more energy efficient. And the CPU is free to jit half a gig of javascript in the mean time.
- temp0826 7mo ago
  It's hugely more efficient, if you're on a battery powered device it could mean hours more of play time. It's pretty insane just how much better it is (I go through a bit of extra effort to make sure it's working for me, hw decoding isn't includes in some distros).
xattt 7mo ago
It’s a leftover mindset from the mid-2000s when GPGPU became possible, and additional performance was “unlocked” from an otherwise under-utilized silicon.
jpc0 7mo ago
I'm not entirely sure that this is true. I haven't actually looked into this but it might not be the realm of possibility. But you are generating a frame on GPU, if you can also encode it there, either with nvenc or vulkan doesn't matter. Then DMA the to the nic while just using the CPU to process the packet headers, assuming that cannot also be handled in the GPU/nic

hirako2000 7mo ago

Vulkan Compute shaders make GPU acceleration practical for intensive codecs like FFv1, ProRes RAW, and DPX. Previous hybrid GPU + CPU suffered the round-trip latency. These are fully GPU hands offs. A big deal for editing workflows.

pandaforce 7mo ago

The main target for this are NLEs like Blender. Performance is a large part of the issue. Most users still just create TIFF files per frame before importing them into a "real editor" like Resolve. Apple may have ASICs for ProRes decoding, and Resolve may be the standard editor that everyone uses. But this goes beyond what even Apple has, by making it possible to work directly with compressed lossless video on consumer GPUs. You can get hundreds of FPS encoding or decoding 4k 16-bit FFv1 on a 4080, while only reading a few gigabits of video per second, rather than tens and even hundreds of gigabits that SSDs can't keep up. No need to have image degradation when passing intermediate copies between CG programs and editing either.

dagmx 7mo ago
I don’t understand the spread of thoughts in your post. The reason to create image sequences is not because you need to send it to other apps, it’s because you preserve quality and safeguard from crashes. A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame. People aren’t going to stop using image sequences even if they stayed in the same app. And I’m not sure why this applies: “this goes beyond” what Apple has, because they do have hardware support for decoding several compressed codecs (also I’ll note that ProRes is also compressed). Other than streaming, when are you going to need that kind of encode performance? Or what other codecs are you expecting will suddenly pop up by not requiring ASICs? Also how does this remove degradation when going between apps? Are you envisioning this enables Blender to stream to an NLE without first writing a file to disk?
- pandaforce 7mo ago
  > A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame. You wouldn't contain FFv1 in MP4, the only format incompetent enough for such corruption. Apple has an interest against people using codecs that they get no fees from. And Apple don't have a lossless codec. So they don't offer lossless compressed video acceleration. The idea is that when working as a part of a team, and you get handed a CG render, you can avoid sending a huge .tar or .zip file full of TIFF which you then decompress, or ProRes which loses quality, particularly when in a linear colorspace like ACEScg.

null-phnix 7mo ago

A lot of the confusion in this thread feels like it comes from thinking in terms of web streaming rather than the workloads this post is targeting. The article is pretty explicit that this is not about "make Twitch more efficient" or squeezing a bit more perf out of H.264. It is about mezzanine and archival formats that are already way beyond what a single CPU, even a decade old workstation CPU, handles comfortably in real time: 4K/6K/8K+ 16‑bit, FFv1-style lossless, ProRes RAW, huge DPX sequences, etc. People cutting multi‑camera timelines of that kind of material are already on the wrong side of the perf cliff and are often forced into very specific hardware or vendors. What Vulkan compute buys you here is not "GPUs good, CPUs bad", it is the ability to keep the entire codec pipeline resident on the GPU once the bitstream is there, using the same device that is already doing color, compositing and FX, and to do it in a portable way. FFmpeg’s model is also important: all the hairy parts stay in software (parsing, threading, error handling), and only the hot pixel crunching is offloaded. That makes this much more maintainable than the usual fragile vendor API route and keeps a clean fallback path when hardware is not available. From a practical angle, this is less about winning a benchmark over a good CPU encoder for 4K H.264, and more about changing what is feasible on commodity hardware: e.g., scrubbing multiple streams of 6K/8K ProRes or FFv1 on a consumer GPU instead of needing a fat workstation or dailies transcoded to lighter proxies. For people doing archival work or high end finishing on a budget, that is a real qualitative change, not just an incremental efficiency tweak.

Teknoman117 7mo ago
To add to what you said, it’s also nice to be able to keep it within one API that’s platform agnostic when possible. Sure we’ve had the ability to keep the pipeline on GPU for awhile, but it usually required platform specific API bindings to convert to a platform specific descriptor (handles on windows, IOSurface on macOS, dmabuf on Linux), which you then had to pull into a platform specific decoder/encoder API (DXGI, WMF, AVFoundation, VAAPI, etc.), and then all of that again but in reverse to get the surface back into your 3D API. This whole thing just makes life easier for everyone.
- null-phnix 7mo ago
  Exactly. The cross-platform descriptor dance is one of those things that's invisible to people outside the pipeline but eats an absurd amount of dev time. You end up writing the same conversion logic three times for three platforms, each with its own failure modes and version quirks, and none of it has anything to do with the actual codec work. Having Vulkan as the single surface for both the compute and the rendering side means one memory model, one synchronization story, one set of bugs to chase. That alone is worth the effort even before you get to the performance wins.

fhn 7mo ago

This article assumes all GPUs are on a PCIe bus but some are part of the CPU so the distance problem is minimal and offloading to GPU might still be net +. Might because I haven't tested this

kvbev 7mo ago

could this have an AV1 decoder for low power hardware that are without AV1 gpu accelerated decoding? for my N4020 laptop. maybe a raspberry pi 4 too.

jokoon 7mo ago

I once asked on #ffmpeg@libera if the GPU could be used to encode h264, and apparently yes, but it's not really worth it compared to CPU. I don't know much about video compression, does that mean that a codec like h264 is not parallelizable?

marci 7mo ago
I think it's mostly because most cpus that can run a gpu already have parts dedicated as h264 encoder, way more efficient energy wise and speed wise.
ablob 7mo ago
Common video codecs are often hardware accelerated. This should be on the CPU side quite often, as there are a lot of systems without dedicated GPUs that still play video, like Notebooks and smart phones. So in the end it's less about being parallelizable, but if it beats dedicated hardware, to which the answer should almost always be no. P.S.: In video decoding speed is only relevant up to a certain point. That being: "Can I decode the next frame(s) in time to show it/them without stuttering". Once that has been achieved other factors such as power drainage become more important.
- craftkiller 7mo ago
  It is my understanding that hardware accelerated video encoders (as in the fixed-function ones built into consumer GPUs) produce a lower quality output than software-based encoders. They're really only there for on-the-fly encoding like streaming to twitch or recording security camera footage. But if you're encoding your precious family memories or backing up your DVD collection, you want to use software encoders. Therefore, if a hypothetical software h264 encoder could be faster on the GPU, it would have value for anyone doing not-on-the-fly encoding of video where they care about the quality. One source for the software encoder quality claim is the "transcoding" section of this article: https://chipsandcheese.com/i/138977355/transcoding https://chipsandcheese.com/i/138977355/transcoding
- asmosoinio 7mo ago
  > ... That being: "Can I decode the next frame(s) in time to show it/them without stuttering". Except when you are editing video, or rendering output. When you have multiple streams of very high definition input, you definitely need much more than realtime speed decoding of a single video. And you would want to scrub around the video(s), jumping to any timecode, and get the target frame preferably showing as soon as your monitor refreshes.

returnorthrow 7mo ago

I was just reading about this topic last night on Maister’s Graphics Adventures: https://themaister.net/blog/2025/06 https://themaister.net/blog/2025/06. They created PyroWave, a GPU-accelerated DWT codec in Vulkan compute shaders for performing very low latency game streaming. Very fascinating read, and builds on similar work from their master’s thesis too.

pandaforce 7mo ago
That's basically what VC-2 is, as well as JPEG2000-HT. Wavelets are nice in that they have no need for deblocking since each slice complements one another, and they're simple to calculate. But this localization means they're horrible for compression since they have bad frequency decomposition properties. JPEG2000 showed that.

reactordev 7mo ago

This makes vision models go “Oooooo”. /s Honestly, everything now is just math. It’s all about how much you can do at once. Vulkan being Vulkan, that ceiling is your hardware. Go ham.

pandaforce 7mo ago
Most vision models are trained on images or conventional video codecs. There's a good reason why H200's have 7 JPEG + 7 nvdec ASICS.