Linux 6.0 Promotes Its H.265/HEVC User-Space API To Stable

[Danny3]

Am I literally the only one who read the GIT?
https://lore.kernel.org/lkml/[email protected]/
Search that for vp9. (Case insensitive)

And sorry that I am a bit irritable today. It is not you guys. It is me.

Yes, there's something like:

"mediatek: vcodec: add vp9 decoder driver for mt8186"

But I don't understand what is this mt8186.

Don't feel sorry, you're right I haven't read the GIT first. You're not irritable.

Thank you very much for the response!

[M@GOid]

Hardware decoding in VLC is dependent on a Radeon or Nvidia GPU. None of the intel GPUs work with it.

VLC's hardware decoding works fine in Intel on my laptop.

[MorrisS.]

What are the effects of this progress?

[Linuxxx]

He is speaking of CPU decoding. I was speaking of GPU decoding. There is a part of this that is plainly unknowable.

I think you should work on your reading comprehension skills.

Big time...

[polarathene]

"mediatek: vcodec: add vp9 decoder driver for mt8186"

But I don't understand what is this mt8186.

It's a MediaTek SoC. If your device uses that, then you get VP9 decode support in the vcodec driver it uses.

What are the effects of this progress?

It's beneficial for embedded / SBCs, not so much for desktops AFAIK.

I don't recall specifics, but usually HW decode drivers would handle all of it managing it's own state internally. Whereas other hardware has a stateless approach, where user-space app like MPV or VLC would do more work by providing state to the decoding HW.

Main benefit is simpler drivers AFAIK by offloading a bunch of logic into user-space (GStreamer provides an interface to such, for most other apps to leverage). Sort of like why Vulkan is more preferable than OpenGL I guess? More involved client-side to use directly, but better quality drivers equates to less problems in the long run?

There's some articles you can read for more info, like this one.

[arQon]

I don't recall specifics, but usually HW decode drivers would handle all of it managing it's own state internally. Whereas other hardware has a stateless approach, where user-space app like MPV or VLC would do more work by providing state to the decoding HW.

That's a pretty accurate summary for "don't recall specifics"!

To be a bit clearer, the "usually" there means "PCs".

> Main benefit is simpler drivers AFAIK (snip)

It kinda depends, but mostly "not really". It's far more of a mess to have the state and the stream separated like this, and as a result it requires a lot more screwing around, and now you have *two* pieces of code that both have to understand the codec instead of one.

The people who benefit are the *hardware* manufacturers, because it means they can skip a huge chunk of the silicon needed to handle the stream. To oversimplify a bit, you can basically think of it as the difference between designing a block to handle video and just designing a block that can only handle JPEG instead. That difference in complexity means a LOT fewer gates, which means less die space, less cost, etc.

The only potential benefit that anyone at the user level might see is that this removes the last "real" excuse for ffmpeg still not having h265 support on the Pi4. Whether that actually translates into any action or not is another story. (I doubt it, but we'll see).

[mos87]

Hardware decoding in VLC is dependent on a Radeon or Nvidia GPU. None of the intel GPUs work with it.

Unless VLC had its decoding interface(s) completely reimplemented in a pretty insane and crippling way very recently, the quoted has to be audaciously incorrect.

[mos87]

If I had to guess, then I believe your Fedora distro is the culprit here.

Try it on an Ubuntu-based distro to see whether that makes a difference.

Ugh this thread has some real bad advice/guessing

I thought advicing to change the whole of OS before even triaging the problem had gone out of fashion somewhat.. *guess* I was wrong)
And yeah the problem might be in software and yeah there's always (some) chance that the best solution would be changing the OS, but...

[mos87]

On my Ice Lake i5 1034G4 (so Gen10), I noticed I don't have H/A in VLC when running H.265/HEVC videos and I don't understand why.

I have the latest Intel-media drivers installed, latest VA-API, latest GStreamer plugins. On Fedora 36.

4K H.264 works fine.

4K H.265 is doing CPU decoding.

Ice Lake should have 4K60 encode and decode.

Any ideas anyone?

No idea what's this intel-media is (some package in fedora? Edit: it is and apparently needed), va-api - that has to be libva, and the specific player mentioned (VLC) has nothing to do with gstreamer.

start investigating the layers that players (vlc, mpv, gstreamer-based) all use - the first idea I see already mentioned, run vainfo and see if the codec in question is even mentioned. If libva (which vainfo prods obviously) doesn't report it then I'd start checking if your HW supports it and if it defo does - here's the distro specific stuff - if the support was fairly recently added to libva, maybe ffmpeg or even mesa.

Probably nothing arcane in finding the culprit

PS another good starting point might be the archwiki article on intel_graphics

[Serafean]

Considering this exists: https://github.com/bootlin/libva-v4l2-request , this too might be supportable by vaapi.
The question is if embedded can handle the overhead vaapi will bring in.

On my Ice Lake i5 1034G4 (so Gen10), I noticed I don't have H/A in VLC when running H.265/HEVC videos and I don't understand why.

I have the latest Intel-media drivers installed, latest VA-API, latest GStreamer plugins. On Fedora 36.

4K H.264 works fine.

4K H.265 is doing CPU decoding.

Ice Lake should have 4K60 encode and decode.

Any ideas anyone?

run vainfo, look at the output. If 4K h265 is listed there, work your way up the stack, if not, down...