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

91–100 of 110 posts

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

#91

Post by tagrun »

Dylan16807 wrote: post #59
tagrun wrote: post #48

Earlier quoted context omitted.

What is "incorrect"? The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads > Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only on Linux , which is not supported by NVIDIA. (emphasis added) You further wrote: > Firefox uses Windows Media Foundation, whic…

> The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads What are you talking about? They didn't quote that sentence at all, and didn't cut in the middle of the sentence they quoted. > And? None of those APIs are cross-platform. Your original objection, the thing that got quoted, was about wheth…

My original statement above about what the point of Vulkan Video is

> The idea behind Vulkan Video Extensions is to have a vendor independent and cross-platform video API.

(emphasis added)

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

#92

Post by jorvi »

tadfisher wrote: post #52
jorvi wrote: post #27

Earlier quoted context omitted.

Huh, I stand corrected. I always figured they stuffed it in its own little bit of silicon. Thanks for clearing it up!

Intel does do this, they call it Quick Sync Video. There's support for it in vaapi. AV1 is only if you have a Gen12 iGPU or newer, or Arc.

I might just be bad at Google-fu, but my understanding is that -F processors don’t have Quick Sync, which seems to imply that the iGPU is required in some capacity.

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

#93

Post by bonton89 »

dishsoap wrote: post #18

So to clarify, this still leverages the fixed function hardware video encoders present alongside many GPUs from eg. Intel/NVIDIA/AMD, and would not (for example) be possible to use on just a GPU itself (without said encoding hardware)?

During the video card shortage I was kind of lamenting that straight encoder cards just don't exist anymore. To get the best encoder acceleration you were stuff fighting with gamers and crytominers over the same video cards even if you didn't need the majority of the hardware for your task.

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

#94

Post by shmerl »

pjmlp wrote: post #67
shmerl wrote: post #58

Earlier quoted context omitted.

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.

Stop wasting everyone's time.

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

#95

Post by shmerl »

luthMan wrote: post #77
shmerl wrote: post #2

> In addition, given the high industry demand for AV1 codec support, an AV1 decode extension release is imminent, with an AV1 encode extension development also underway. That's good. By the way, mpv already supports Vulkan video decoding: https://github.com/mpv-player/mpv/issues/11739 Now we need OBS and Firefox supporting Vulkan video too.

What about systems where there is now hardware support for AV1? How would Vulkan implement that? Also, maybe someone knows more about this, but I thought that most software like Firefox, MPV and VLC are using dav1d for AV1 decoding as it seems to be the most performant AV1 decoder (in Software) out there at the moment.

> How would Vulkan implement that?

See the post. They are working on AV1 extensions.

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

#96

Post by philsnow »

_flux wrote: post #73
pjc50 wrote: post #72

Earlier quoted context omitted.

What does that mean? A video is inherently a series of frames. And using that sequential nature is critical to achieving good compression. However, most formats allow for some parallelism at the "macroblock" level - you can usually decode all 16x16 pixels simultaneously. To some extent you can decode macroblocks separately, but "intra prediction" requires you to have the ones above and to the left available.

It means that e.g. in H265 you can split the frame into tiles that are much larger than macroblocks: it's like the video is a set of n videos that are then composed to build a complete frame. This allows both encoding and decoding to work in parallel even inside a single frame. In addition, in VR 360 context, it allows decoding only frames the viewer can see. It reduces the compression efficiency, but only a little,…

> 6 tiles per frame (but can be more for 360 video applications)

Seems like for VR video, if it’s split up longitudinally you would only have to decode the tiles that are in the direction the user is looking at any given time, and just let the other bits pass by undecoded.

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

#97

Post by Dylan16807 »

tagrun wrote: post #91
Dylan16807 wrote: post #59

Earlier quoted context omitted.

> The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads What are you talking about? They didn't quote that sentence at all, and didn't cut in the middle of the sentence they quoted. > And? None of those APIs are cross-platform. Your original objection, the thing that got quoted, was about wheth…

My original statement above about what the point of Vulkan Video is > The idea behind Vulkan Video Extensions is to have a vendor independent and cross-platform video API. (emphasis added)

You did say that, but it's not the part of your post they were responding to.

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

#98

Post by slimsag »

my123 wrote: post #90
slimsag wrote: post #86

Earlier quoted context omitted.

In Windows 10 and above, windows update provides a default graphics driver for each IHV, which comes from the manufacturer, has DirectX support, but doesn't have Vulkan. Often nvidia users will try to debug it, and discover 'the vulkan checkbox is off but I have the latest driver version!' in gpuZ[0][1] - but it happens across all IHVs, AMD, Intel, etc. I was told by someone in the industry the default Microsoft driv…

> has DirectX support, but doesn't have Vulkan The Vulkan implementation is still there. You just have to install the redistributable. (see https://vulkan.lunarg.com/sdk/home - Runtime) There's no separate Vulkan-less version of the drivers AFAIK - it's just that the installation program of the manufacturer doesn't run so that there's no opportunity to install the Vulkan runtime.

Thanks for the info, cool to know you can install that separately.

My original point remains: out of the box, many Windows users find they have the 'latest drivers' for their graphics card, find that DirectX 12 is working fine on their system, while simultaneously finding Vulkan does not.

For games, it's fine to require users to fix their Vulkan drivers. But if you're making a video player and want to leverage hardware decoding.. I think this is an aspect you should be concerned about and aware of.

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

#99

Post by tagrun »

Dylan16807 wrote: post #59
tagrun wrote: post #48

Earlier quoted context omitted.

What is "incorrect"? The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads > Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only on Linux , which is not supported by NVIDIA. (emphasis added) You further wrote: > Firefox uses Windows Media Foundation, whic…

> The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads What are you talking about? They didn't quote that sentence at all, and didn't cut in the middle of the sentence they quoted. > And? None of those APIs are cross-platform. Your original objection, the thing that got quoted, was about wheth…

> What are you talking about? They didn't quote that sentence at all, and didn't cut in the middle of the sentence they quoted.

Obviously, I meant to say statement, not sentence, but I can't edit it anymore.

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

#100

Post by tagrun »

Dylan16807 wrote: post #97
tagrun wrote: post #91

Earlier quoted context omitted.

My original statement above about what the point of Vulkan Video is > The idea behind Vulkan Video Extensions is to have a vendor independent and cross-platform video API. (emphasis added)

You did say that, but it's not the part of your post they were responding to.

> You did say that, but it's not the part of your post they were responding to.

So if someone criticizes a portion of your statement which is already countered by your original full statement, you're not allowed to remind your full statement. What kind of logic is that?

My original post says the point of Vulkan Video is it will be cross-platform and cross-vendor. And gives one example of cross-vendor side of things on Linux.

Someone criticizes me by essentially saying "you are incorrect, that's only on Linux. Windows, Android and iOS have their own video APIs...". This "correction" is incorrect because I already said on Linux, and it goes on to actually reinforce the post that he is responding to by highlighting cross-platform side, which also is in the post he is responding to.

So, if you look at the full conversation, the criticism is self-contradictory. This is what I'm pointing out, but you are implying I'm not allowed to do that.

I disagree. When you fragment a statement in a way that changes its meaning and make a straw man out of it, people are justified in responding to it.

Post reply on HN