A Reverse-Engineered Tegra Video Decode Driver Steps Closer To Mainline

[phoronix]

Phoronix: A Reverse-Engineered Tegra Video Decode Driver Steps Closer To Mainline

A video decoder driver for the NVIDIA Tegra is closer to the mainline kernel, but is focused on the (older) Tegra 2 chips...

http://www.phoronix.com/scan.php?page=news_item&px=Tegra-2-Video-Decode-Driver-V3

[FireBurn]

They've basically dropped VDPAU

[Hibbelharry]

Because VDPAU doesn't work with Wayland, and Wayland is the future of the Linux Desktop.

[starshipeleven]

Because VDPAU doesn't work with Wayland, and Wayland is the future of the Linux Desktop.

That's tangential.

[timofonic]

That's tangential.

Was that sarcasm?

What about this mess?
- VDPAU...
- VA-API: libva + libyami + MediaSDK (qsv, mfx..)....
- XvBA...

What's the solution instead? Another shitty API like cuvid/nvdecode? What about killing all video encode/decode APIs with fire and use the Khronos Group's OpenMax instead?

Developers: Please support OpenMax and destroy the current video API Babel Tower!

[starshipeleven]

Was that sarcasm?

No, it was supposed to mean that NVIDIA didn't drop VDPAU because it does not work on wayland, so the "NVIDIA dropped VDPAU" thing is tangential to Wayland.

does nvdecode aka "the Next Big Thing" (tm) run with Wayland? I never saw anything stating it does.

What's the solution instead? Another shitty API like cuvid/nvdecode?

It seems nvdecode is the same stuff they use on Windows. So for them it makes sense, as this way they have one API for all platforms, and they can just re-wrap their whole Windows driver to work everywhere more or less the same.

[timofonic]

No, it was supposed to mean that NVIDIA didn't drop VDPAU because it does not work on wayland, so the "NVIDIA dropped VDPAU" thing is tangential to Wayland.

does nvdecode aka "the Next Big Thing" (tm) run with Wayland? I never saw anything stating it does.

I just see it as proprietary crap instead a common abstraction for all hardware doing video encoding/decoding. Why is it permitted?

It's even worse than VDPAU vs VAAPI and complicates developers even more by using it if they want offer hardware video encoding/decoding support to users with Nvidia hardware.

Instead supporting an API for all video encoding/decoding, they'll have to use a bunch of them for video decoding depending on the hardware to use. What an evolution!

It seems nvdecode is the same stuff they use on Windows. So for them it makes sense, as this way they have one API for all platforms, and they can just re-wrap their whole Windows driver to work everywhere more or less the same.

They still want to force a Nvidia GPU monoculture by throwing their crap at other Operating Systems too, what a surprise. I consider this makes a lot more important to deploy OpenMax universally as soon as possible.

[starshipeleven]

I just see it as proprietary crap instead a common abstraction for all hardware doing video encoding/decoding. Why is it permitted?

Who has the right to policy what NVIDIA does with their own property (their blob driver)?

They still want to force a Nvidia GPU monoculture by throwing their crap at other Operating Systems too, what a surprise.

Well, it's NVIDIA after all, and on Windows this is perfectly normal, everyone does it.

I consider this makes a lot more important to deploy OpenMax universally as soon as possible.

Considering that only AMD seems to care about OpenMax outside of Android/embedded, I don't see that happening.

Currently, the only way forward is using some framework that abstracts all that bs. Like ffmpeg or Gstreamer.

[Gusar]

What about killing all video encode/decode APIs with fire and use the Khronos Group's OpenMax instead?

OpenMax is a bigger mess than all those other APIs *combined*. That's why developers stay away from it. Every vendor does things differently, so you need separate code for each vendor you wish to support.

Even on Android, *no one* uses OpenMax. They all use Mediacodec, a high level abstraction (which then does use OpenMax somewhere underneath all its layers of indirection). Trying to use OpenMax would lead to madness. Or the particular OMX-using player would only work on select devices.

[nanonyme]

OpenMax is a bigger mess than all those other APIs *combined*. That's why developers stay away from it. Every vendor does things differently, so you need separate code for each vendor you wish to support.

Even on Android, *no one* uses OpenMax. They all use Mediacodec, a high level abstraction (which then does use OpenMax somewhere underneath all its layers of indirection). Trying to use OpenMax would lead to madness. Or the particular OMX-using player would only work on select devices.

Actually makes me wonder if that GSoC project on making Mesa OpenMAX implementation more maintainable improved the situation any