Live data from Hacker News

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

khronos.org

101–110 of 110 posts

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

#101

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

C needs an extension for import without namespaces purely based on names:

  import vkGetPhysicalDeviceVideoEncode;

  QualityLevelPropertiesKHR(...);
Or even better:

  import vk*PhysicalDeviceVideoEncode;
  
  Get_QualityLevelPropertiesKHR(...);

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

#102
post #99

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…

> 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.

[deleted]

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

#103
post #100

Earlier quoted context omitted.

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 o…

> 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?

The other stuff in your comment did not "counter" what they said. You made statements about cross-vendor and cross-platform. They chose to only respond to one of those statements. That's not incorrect.

> This "correction" is incorrect because I already said on Linux

The first part of your comment specifically said "not "various OS' native APIs"". That goes beyond Linux. The later part of your comment was about Linux in particular, but your introduction was an overall statement that wasn't true.

> When you fragment a statement in a way that changes its meaning

They didn't. You misspoke and they didn't know what you actually meant.

And from your other post: > Obviously, I meant to say statement, not sentence, but I can't edit it anymore.

That was not obvious. They quoted an entire paragraph, and the subsequent paragraph does not change its meaning the way you're claiming it does.

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

#104
post #87

Earlier quoted context omitted.

Android hasn't displaced Linux on phones, there wasn't any. ChromeOS hasn't displaced Linux on school laptops, there wasn't any. LG WebOS hasn't displaced "Linux", it competes with Google TV (formerly Android TV)

Oh boy, another Linux advocate on the lose. So here goes a children explanation. > Unfortunely I still have to, from time to time. I, pjmlp, still have to use GNU/Linux desktop from time to time. > Luckly Android, ChromeOS and WebOS as proper Linux distributions have replaced most of it. Android, ChromeOS and WebOS, have replaced most of my needs, pjmlp, for GNU/Linux in the desktop and similar devices.

> Android, ChromeOS and WebOS, have replaced most of my needs

Great! I really hope you're happy with that setup! It's your personal computer and by all means, do what works well for you. In the end that's always a personal thing that's different for everyone. Who am I to judge how you use your computer?

But maybe ... stop complaining about Linux desktop then? If you don't like it? This must be like the 3rd time I've seen these types of single-line dismissive "Linux will never win the desktop"-comment from you in the last few days. Just one line, little or no context, or explanation, and IMHO also zero value, and an entire discussion derailed.

This is just becoming disruptive. You don't need to say anything you know. Personally, I rather dislike a number of things, but you don't see me complaining about it with one-liners every chance I get – and when I do say something, at least I make sure it's something of some substance, when I feel it actually contributes. And I sure as hell don't go around complaining people are "children" for disagreeing.

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

#105
post #44

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…

And when someone installs some obscure or outdated and vulnerable codec on these systems, it's then automatically exposed to all sorts of applications to exploit. Maybe Windows sandboxes that these days(?) It was definitely a problem in the past.

No perfect solutions here; both "system-wide codecs" and "every application brings their own codecs" have their own up- and downsides.

Besides, with ffmpeg and gstreamer the system-wide codecs paradigm also works on Linux.

This is one of those "it's different but it doesn't really matter much" type of things. Most people "just" install vlc or mpv or whatnot and things will "just work" for them, not really different from Windows. That it's technically slightly different is almost entirely transparent to the user.

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

#106
post #94
post #67

Earlier quoted context omitted.

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.

Likewise, go do some kernel contributions.

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

#107
post #104
post #87

Earlier quoted context omitted.

Oh boy, another Linux advocate on the lose. So here goes a children explanation. > Unfortunely I still have to, from time to time. I, pjmlp, still have to use GNU/Linux desktop from time to time. > Luckly Android, ChromeOS and WebOS as proper Linux distributions have replaced most of it. Android, ChromeOS and WebOS, have replaced most of my needs, pjmlp, for GNU/Linux in the desktop and similar devices.

> Android, ChromeOS and WebOS, have replaced most of my needs Great! I really hope you're happy with that setup! It's your personal computer and by all means, do what works well for you. In the end that's always a personal thing that's different for everyone. Who am I to judge how you use your computer? But maybe ... stop complaining about Linux desktop then? If you don't like it? This must be like the 3rd time I've…

You can ignore my comments you know.

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

#108

Earlier quoted context omitted.

seems rather obvious and i would imagine most encoding algos act accordingly

The point was rather that it makes parallel encoding more difficult. With a fixed interval it is trivial, you just split the incoming stream based on the fixed rate, and let each thread work on separate intervals. With adaptive key frame placement you don't know the intervals up front, and they might have wildly different lengths. Some might be hundreds of frames, some might be just a few.

good point

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

#109

Earlier quoted context omitted.

seems rather obvious and i would imagine most encoding algos act accordingly

Not always.DivX, XviD, etc. preferred constant interval key framing to battle with corruption and other transfer hazards.

interesting, thanks

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

#110
post #88

Earlier quoted context omitted.

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

They are, H.265 have "slices" and "tiles" that allow parallel decoding.

AV1 also has "tiles". This is basically slicing each frame into N separate frames and encoding each mostly separately. You lose a little efficiency (as you can't exploit cross-tile redundancy very well or at all) but unlock a lot of parallelism on both encode and decode.
Post reply on HN