Is VDPAU supported in HandBrake?

[zimon]

I noticed VDPAU support has appeared to my Fedora Linux machine.

I wonder, if VDPAU is used in HandBrake either in decoding or even in encoding, and if, should I configure it somehow to use VDPAU?

And if not, consider this as a Feature Request. And if yes, consider this as a feature documentation request.

Code: Select all

$ vdpauinfo 
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  304.125  Mon Dec  1 20:26:10 PST 2014

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12 
422     4096  4096  UYVY YUYV 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                           0  8192  2048  2048
MPEG2_SIMPLE                    3  8192  2048  2048
MPEG2_MAIN                      3  8192  2048  2048
H264_BASELINE                  --- not supported ---
H264_MAIN                      41  8192  2048  2048
H264_HIGH                      41  8192  2048  2048
VC1_SIMPLE                      1  8190  2048  2048
VC1_MAIN                        2  8190  2048  2048
VC1_ADVANCED                    4  8190  2048  2048
MPEG4_PART2_SP                  3  8192  2048  2048
MPEG4_PART2_ASP                 5  8192  2048  2048
DIVX4_QMOBILE                   0  8192  2048  2048
DIVX4_MOBILE                    0  8192  2048  2048
DIVX4_HOME_THEATER              0  8192  2048  2048
DIVX4_HD_1080P                  0  8192  2048  2048
DIVX5_QMOBILE                   0  8192  2048  2048
DIVX5_MOBILE                    0  8192  2048  2048
DIVX5_HOME_THEATER              0  8192  2048  2048
DIVX5_HD_1080P                  0  8192  2048  2048
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y  

$ ldd /usr/bin/ghb | grep nvidia
	libGL.so.1 => /usr/lib64/nvidia-304xx/libGL.so.1 (0x00000034dc400000)
	libnvidia-tls.so.304.125 => /usr/lib64/nvidia-304xx/tls/libnvidia-tls.so.304.125 (0x00000034dcc00000)
	libnvidia-glcore.so.304.125 => /usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.125 (0x00000034dd000000)

$  ldd `which ffmpeg`|grep libOpenCL
libOpenCL.so.1 => /usr/lib64/nvidia-304xx/libOpenCL.so.1 (0x00007f56ee789000)

$ rpm -qf /usr/lib64/nvidia-304xx/libOpenCL.so.1
xorg-x11-drv-nvidia-304xx-libs-304.125-1.fc21.x86_64

$ rpm -qf /usr/lib64/vdpau/libvdpau_nvidia.so.304.125
xorg-x11-drv-nvidia-304xx-libs-304.125-1.fc21.x86_64

Code: Select all

$ ldd `which ffmpeg`|grep vdpau
	libvdpau.so.1 => /lib64/libvdpau.so.1 (0x00000034d0200000)

http://en.wikipedia.org/wiki/VDPAU
http://en.wikipedia.org/wiki/OpenCL

Seems like VLC, ffmpeg and xine does support VDPAU.

[Deleted User 11865]

No, it's not supported.

[s55]

Nor is it particularly suitable for HandBrake either.

Given our bad experience with these decoders (which btw, are designed for "Decode for playback" not "Decode for encode") I wouldn't wish anyone to waste their time looking into it. On the current generation of GPU's, the decode hardware is only of real benefit to slower CPU's. Otherwise it's a massive bottleneck.

[Deleted User 11865]

On the current generation of GPU's, the decode hardware is only of real benefit to slower CPU's. Otherwise it's a massive bottleneck.

It's an API and/or implementation problem though. My experiments with QSV decode (via the Media SDK API, not DXVA) and software encode were quite positive even on quad-core CPUs.

[Djfe]

I hope I'm not wrong, but isn't this like DVXA (Win), which Handbrake supports already?

[mduell]

Same thing, except completely different.

[zimon]

Ok, I get it. So VDPAU may not be usefull, because it is mainly for decoding and encoding part is the "bottleneck" of HandBrake really.

How about OpenCL then (mentioned in the start)?
Or is it up to for example x265-encoder libraries to support it?

I noticed it is mentioned OpenCL (BiCubic scaling) is supported in Windows already? Not for Linux?

In Fedora 21, libOpenCL is linked with libavcodec (comes from ffmpeg-libs), but not for example requirement for x264 nor x265:

Code: Select all

$ rpm -qf /usr/lib64/libavcodec.so.56
ffmpeg-libs-2.4.6-2.fc21.x86_64

$ ldd /usr/lib64/libavcodec.so.56 | grep OpenCL
	libOpenCL.so.1 => /usr/lib64/nvidia-304xx/libOpenCL.so.1 (0x00007f951f048000)
	
$ ldd /usr/lib64/libx264.so.142 | grep OpenCL
(none)

$ ldd /usr/lib64/libx265.so.25 | grep OpenCL
(none)

$ rpm -qf /usr/lib64/libOpenCL.so  # There is also OSS OpenCL.
ocl-icd-devel-2.0.4-3.git20131001.4ee231e.fc21.x86_64

[Djfe]

I have no clue whether the bicubic scaler is available on Linux

but what I know is that you cannot use OpenCL for everything because encoding is too complex

one thing that you can do for example are scalers

but first: it only changes something if you scale your movie
second: the lanczos scaler (which only works on cpus) is superior to the opencl one: in quality and on faster cpus also in speed

so like vdpau/dvax this is only useful for slower pcs (if you want to save time)

one feature might be useful though:
intel quicksync
because on one of the faster settings it often has a better(quality-wise) and faster throughput than the cpu based encoder iirc

[moneymatt4life]

x264 has opencl lookahead or something... think you just put opencl in the extra options box? i dunno... not sure of how big of a speedboost that'd be though, i have no way of testing it...

QSV decode sounds interesting though... if it'd still be possible to *use handbrake filters with it that is

*edit

[Djfe]

totally forgot about the lookahead because I think I never used (so I cannot say either if it works well or not)

[Deleted User 11865]

QSV decode sounds interesting though... if it'd still be possible to handbrake filters with it that is

Yes. We're not there yet though.