FFmpeg Lands NVDEC-Accelerated H.264 Decoding

[BtbN]

What about the Nvidia proprietary drivers? I think that's needed for anything using CUDA.

You obviously need the drivers to be installed to use it. But not to build it.
The wiki only links to the nvidia SDK download page because it has a reference table for what GPU generation supports which features.
It nowhere says that you have to actually download the SDK

[thelongdivider]

With gstreamer? How did you enable nvdec and with what media player?

with mpv, use the option hwdec=cuda

[coder]

The wiki only links to the nvidia SDK download page because it has a reference table for what GPU generation supports which features.
It nowhere says that you have to actually download the SDK

Actually, someone just made that change, presumably because of this thread. Check the history:

57

2 hours

oromit

There is no need to download that SDK.

And the diff:

HWAccelIntro

* {{{ffmpeg}}} configured without {{{--disable-nvenc}}}

< Download the [https://developer.nvidia.com/nvidia-video-codec-sdk NVIDIA Video Codec SDK], and check the website for more info on the supported GPUs and drivers.

> Check [https://developer.nvidia.com/nvidia-video-codec-sdk the NVIDIA website] for more info on the supported GPUs and drivers.

Usage example:

Not that I'm complaining if it's been corrected, but you make it sound like it always said that.

[starshipeleven]

FFS, how does this help ANYONE except nvidia?

Since the dawn of time, programs rely on multimedia frameworks like ffmpeg and Gstreamer, or MediaCodec (Android), or whatever is the Windows one. They don't all reinvent the wheel for each and every damn player.

This has the added benefit that whatever crap proprietary API the hardware vendor decides to implement, for the userspace programs it's irrelevant as they just call the multimedia framework.

So yeah, this helps every application using multimedia frameworks, which is the overwhelming majority.

(OpenMax anyone?)

OpenMax is total madness outside of PC, on Android each goddamn vendor has its own crap added to it so it is basically just one of the many layers of abstraction kept closed up in the basement of Android system, while the apps use MediaCodec (an userspace-facing media framework that then offloads to whatever special snowflake crap lower-level API the device actually has in its drivers)

[caligula]

I have yet to understand why we use GPUs for video encoding/decoding via special circuit. We should target GPUs via general software with OCL or OMP support, or something C_amp style.

Nobody mentioned the effects on environment due to global warming. Dedicated hardware is tiny (compared to general purpose CPUs) and very energy efficient. It really makes sense that video playback uses < 0.1W, not 100W. Also consider battery life on mobile.

[coder]

Dedicated hardware is ... very energy efficient. It really makes sense that video playback uses < 0.1W, not 100W.

Sure, but you're plain nuts if you think an ASIC block is going to deliver 1000x efficiency improvement over SW GPU, or even a reasonable CPU version.

In the perfect world, it would be a good idea for libraries like ffmpeg to have an OpenCL version in their back pocket for those times when more specialized options aren't available. Plus, some FPGAs are programmable via OpenCL, delivering much closer to the performance & efficiency of a hard-wired ASIC.

[Gusar]

In the perfect world, it would be a good idea for libraries like ffmpeg to have an OpenCL version in their back pocket for those times when more specialized options aren't available.

Makes no sense to spend time and effort on one, when it'll be slower and/or more resource intensive than the software solution. GPUs simply aren't suitable for video en/decoding. It's been tried years ago already. And then abandoned for the aforementioned reasons.

[mzs.112000]

No Rust boy to complain about C unsafe code? ...that`s a first!

We need to re-write FFmpeg, Linux kernel, Mesa, Wayland, GNOME, KDE Plasma, Xorg, and Libreoffice in Rust, too much unsafe C code in there.*

There you go, we now have the obligatory Rust comment.

*The opinions in this comment are satire and do not represent my actual line of thinking on the subject.

[timofonic]

with mpv, use the option hwdec=cuda

Yes, another mpv user. Welcome!

I love mpv, it has a lot more potential than people think. Some people think it's just a renamed mplayer/mplayer2/... Not at all!

mpv is very efficient and multiplatform. It has lots of possibilities by using scripting in Lua, JavaScript, Vapoursynth etc.

There's libmpv, that I consider it to be a saner and better alternative than stuff like GStreamer, forgotten Xine and Phonon/thatQTstuff-for-media.

[caligula]

Sure, but you're plain nuts if you think an ASIC block is going to deliver 1000x efficiency improvement over SW GPU, or even a reasonable CPU version.

In the perfect world, it would be a good idea for libraries like ffmpeg to have an OpenCL version in their back pocket for those times when more specialized options aren't available. Plus, some FPGAs are programmable via OpenCL, delivering much closer to the performance & efficiency of a hard-wired ASIC.

Not long ago high end Intel CPUs couldn't decode 1080p h.264. Now, pretty low power mobile phones decode not only h.264 but also 4k h.265. It's CPU -> ASIC and few years of development with chip manufacturing processes = 1000x.

I believe you, GPUs and CPUs could decode (and encode), but why bother - over 50% of web browsing comes from mobile users so the ASIC blocks are needed anyways. On desktop, I don't want to have two GPUs just to 1) play a game + another to 2) encode & broadcast my gameplay to web.