Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulkan video extensions for accelerated H.264 and H.265 encode

khronos.org

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#61

Post by padenot »

cesarb wrote: post #21
mattst88 wrote: post #19

Earlier quoted context omitted.

> Firefox still has no support for hardware video decode on Linux. That's not true at all. See: https://www.omgubuntu.co.uk/2023/07/firefox-115-intel-gpu-vi... https://www.phoronix.com/news/Mozilla-Firefox-115 https://www.omglinux.com/firefox-hardware-acceleration-raspb...

How can I confirm whether Firefox is actually using hardware decode for videos on my machine for a given codec? Is there a magic keyword I should search for within the about:support page, or is it recorded somewhere else? Mine shows for instance "VP9_HW_DECODE default available", does this means it's using hardware decode for VP9, or merely that it might be possible for my Firefox version?

We've put a dedicated section called Media in about:support, it has decoding capabilities and other things such as audio IO informations.

If you find that it is not accurate, e.g. by cross-checking via other means, please open a ticket at https://bugzilla.mozilla.org/enter_bug.cgi, component "Audio/Video".

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#62

Post by dataking »

0x1ceb00da wrote: post #33
monocasa wrote: post #31

Earlier quoted context omitted.

Interestingly, quite a bit of video decode isn't as parallelizable as you might think and isn't a great fit for GPUs. For instance the initial Huffman decoding of the stream is essentially an intrinsically sequential process.

Is there a reason we don't have parallelizable video formats?

AV1 is parallelizable at the thread and SIMD level. Other formats too I’m sure but I’ve only looked at AV1.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#63

Post by anvuong »

0x1ceb00da wrote: post #33
monocasa wrote: post #31

Earlier quoted context omitted.

Interestingly, quite a bit of video decode isn't as parallelizable as you might think and isn't a great fit for GPUs. For instance the initial Huffman decoding of the stream is essentially an intrinsically sequential process.

Is there a reason we don't have parallelizable video formats?

I guess because information of pixels in a video are not independent in either time or space, while parallelization relies on the independence of either temporal or spatial axis.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#64

Post by IPTN »

dlojudice wrote: post #40

> vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR how to exceed the character limit on your super wide screen with just one function name

Huh, It only takes up 2/3 of my phone screen width in portrait mode and reads fine at full arms length.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#65

Post by mratsim »

anvuong wrote: post #63
0x1ceb00da wrote: post #33

Earlier quoted context omitted.

Is there a reason we don't have parallelizable video formats?

I guess because information of pixels in a video are not independent in either time or space, while parallelization relies on the independence of either temporal or spatial axis.

Convolutions and Discrete Cosine Transforms and many matrix operations (rotations, shifts) depends on operations around and ARE parallelizable.

It's the non-linear-algebra stuff that is usually problematic.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#66

Post by account42 »

mikepavone wrote: post #29
tagrun wrote: post #28

Earlier quoted context omitted.

> They have perfectly great existing hardware decoder offloading APIs via the various OS' native APIs for videos One vendor specific API, not "various OS' native APIs". Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only on Linux, which is not supported by NVIDIA. (A third-party VA-API to NVDEC translation layer for Linux does exist on GitHub, nvidia-vaapi-driver, but it's not…

> No, Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only, which is not supported by NVIDIA. Intel is behind VA-API originally, but I don't think it's fair to say it's a vendor specific API anymore. It's supported by the open source drivers for GPUs from all 3 vendors. It's just that the open source drivers for Nvidia cards are not very practical and the proprietary drivers onl…

Right, this is yet another instance of Nvidia not wanting to play nice with the other kids.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#67

Post by pjmlp »

shmerl wrote: post #58
pjmlp wrote: post #57

Earlier quoted context omitted.

Those 2% will appreciate their efforts.

Those who use it appreciate their efforts. You aren't using it, why are you even complaining especially with complete nonsense comments. Anti Linux shilling should be getting old.

Unfortunely I still have to, from time to time.

Luckly Android, ChromeOS and WebOS as proper Linux distributions have replaced most of it.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#68

Post by account42 »

Dalewyn wrote: post #44
kllrnohj wrote: post #42

Earlier quoted context omitted.

> One vendor specific API, not "various OS' native APIs". Incorrect. Firefox uses Windows Media Foundation, which is cross-vendor, on Windows. It uses MediaCodec on Android which is again cross-vendor. Presumably it uses whatever iOS' equivalent is as well. It only uses VA-API on a single OS, Linux, and that's probably more a reflection on the media qualities (or lack thereof) of Linux as a whole. Maybe Vulkan video…

I'm always annoyed how any Linux media player or encoder needs to bring its own entire media operating system, down to each individual nut and bolt. On Windows there's Windows Media Foundation and DirectShow that centrally manage everything and also support the "individual nut and bolt" approach. Android has its own central thing (MediaCodec?) that must be used. MacOS and iOS presumably have their own central manager…

Install ffmpeg and you have all the codec support you need. How is this a real problem?

Yeah, binary software will have to ship its own copy of ffmpeg... This isn't unique to media codecs though.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#69

Post by account42 »

pjmlp wrote: post #55
shmerl wrote: post #45

Earlier quoted context omitted.

You don't need to implement every nut and bolt in the application. Lot's of useful things can do the heavy lifting (Pipewire, ffmpeg, libplacebo, Mesa and so on). Linux isn't after calling it all using some uniform "DirectFoo" naming scheme, but tools are there. Comparison is also invalid. Linux as a whole (not the kernel but OS experience) isn't controlled by some Big Brother who decides what and how it's done singl…

Hence why it will never be embraced by desktop application developers, and Electron it is.

Considering how user hostile most app developers are, I don't miss them.

Re: Vulkan video extensions for accelerated H.264 and H.265 encode

#70

Post by geraldhh »

magicalhippo wrote: post #50
throwup238 wrote: post #37

Earlier quoted context omitted.

Modern video codecs use motion prediction algorithms to encode the information between key frames which depends on the entire frame and the ones immediately preceding it. You can encode the independent groups of pictures (the key frame and all the subsequent predictive frames until the next key frame) in parallel but at least with 4k video you hit memory bandwidth limitations quite quickly.

Also, to get best compression you don't want to do key frames at even intervals, but rather when it pays off (ie large changes between two frames, like a scene change).

seems rather obvious and i would imagine most encoding algos act accordingly
Post reply on HN