[HN Gopher] Vulkan Video Decoding
       ___________________________________________________________________
        
       Vulkan Video Decoding
        
       Author : zdw
       Score  : 82 points
       Date   : 2023-01-09 20:40 UTC (2 days ago)
        
 (HTM) web link (lynne.ee)
 (TXT) w3m dump (lynne.ee)
        
       | Vt71fcAqt7 wrote:
       | This was a great read and finally explained why Vulkan Video is
       | good being "just" a layer ontop of existing HW decode/encode.
       | What's interesting, then, is that Nvidia and others are
       | supporting it. As opposed to rendering where Intel, AMD and
       | Nvidia have their own rendering backend in eg. blender. Nvidia
       | has Optix and CUDA, AMD has HIP, Intel has oneAPI (ironic given
       | this discussion) and Apple has Metal.[0] I guess there isn't much
       | value in being unique for something that's anyways implementing
       | an existing standard (in this case the codecs themselves like
       | h.265).
       | 
       | [0]https://docs.blender.org/manual/en/latest/render/cycles/gpu_..
       | .
        
         | Scaevolus wrote:
         | Video decoding is a _massively_ simpler API surface than a GPU
         | programming framework like CUDA or HIP. Exposing the APIs in
         | Vulkan is not that much extra work.
        
       | jacooper wrote:
       | Do anything, just please get Video decoding working on Linux, it
       | kills battery life immediately on laptops.
        
         | [deleted]
        
         | vetinari wrote:
         | VAAPI does work; but some browsers are lagging their feet, so
         | use Firefox instead.
        
           | jacooper wrote:
           | Apps such zoom also desperately need hardware acceleration, I
           | am not sure if zoom works on Firefox, I prefer Brave.
        
         | nicolaslem wrote:
         | This is what I thought initially, but in my testing with a
         | modern laptop I saw almost no difference with and without
         | hardware decoding.
         | 
         | It is possible that my testing was flawed so I would be curious
         | if anyone has investigated power consumption more thoroughly.
        
           | londons_explore wrote:
           | Low resolution videos (eg. 24 fps non-hd content) are very
           | easy for a modern CPU to decode, so typically other parts of
           | the laptop - ie. the screen, will dominate.
           | 
           | I foresee in the future, as CPU's get even faster, this kind
           | of stuff being decoded by javascript, simply so that 'we can
           | guarantee each platform decodes the video the same'.
        
             | photonbeam wrote:
             | Perhaps by wasm?
        
           | cb22 wrote:
           | I just did some quick testing on my XPS 7390 2-in-1 (i7
           | 1065G7) with Wayland:                 * Idle @ 50%
           | brightness, WiFI on: 3.5W       * mpv + hardware
           | acceleration: 15W       * Firefox + hardware acceleration:
           | 19W       * Firefox software decoding: 29W
           | 
           | The test video was
           | https://www.youtube.com/watch?v=LXb3EKWsInQ - which is 4k 60
           | FPS and got scaled to 1920x1080 for display.
        
             | doubled112 wrote:
             | Huh, that's the video I use to test hardware acceleration
             | too.
             | 
             | Good taste.
        
             | btdmaster wrote:
             | The difference is much more pronounced at lower
             | resolutions. 4K60 is not handled efficiently by any
             | hardware.
        
               | FpUser wrote:
               | I have desktop product that among other things decodes
               | 4K60P using MMF. The decoding part either decodes
               | straight into DirectX texture if hardware based video
               | decoding is supported or does it in software otherwise.
               | 
               | Software based path causes significant CPU load. Using
               | hardware path keeps CPU at about 0%. Since hardware video
               | decoding supported nearly on any modern Laptop, Desktop I
               | would say 4K60 is handled very efficiently.
        
               | cornstalks wrote:
               | That's the opposite of my experience. Depending on the
               | decoder, lower resolutions may be more efficiently
               | handled by the CPU instead of the hardware decoder (which
               | is a decent chunk of silicon and takes extra power to
               | use). But once you hit a certain resolution, the hardware
               | decoder is pretty much always _way_ more efficient than a
               | software CPU decoder. Some well-implemented hardware
               | decoders even handle low resolutions more efficiently.
               | 
               | My experience is largely focused on battery-powered
               | mobile devices (Android/iOS), though.
        
               | btdmaster wrote:
               | To give a concrete example, VAAPI Haswell integrated
               | graphics, peak CPU usage:                 mpv hardware
               | H.264 1080p60: 3% CPU usage       mpv software H.264
               | 1080p60: 20% CPU usage            mpv hardware H.264
               | 4K60: 96% CPU usage       mpv software H.264 4K60: 80%
               | CPU usage
               | 
               | There comes a point of diminishing (or in this case,
               | negative) returns. A bit more subjectively, the H.264
               | software rendering at 4K60 also felt smoother.
               | 
               | I'm using H.264 as it is hardware accelerated on this
               | platform.
        
               | zamadatix wrote:
               | "Offloaded decoding takes more CPU than non-offloaded
               | decoding" doesn't make any sense - clearly something else
               | is going awry here.
        
               | cornstalks wrote:
               | I don't think all Haswell chips support 4k H.264. That's
               | one downside of hardware decoders: they have limits on
               | what they support. I suspect the decoder is actually
               | falling back to a software implementation to handle the
               | bitstream since the hardware can't.
               | 
               | For example: https://www.avsforum.com/threads/no-
               | hardware-4k-h264-decode-...
        
       ___________________________________________________________________
       (page generated 2023-01-11 23:02 UTC)