Mpv: vdpau: Requested hardware decoder not compiled. Using software decoding.

Created on 12 Oct 2016  Â·  36Comments  Â·  Source: mpv-player/mpv

I'm using mpv-build to pull newest mpv and ffmpeg from github and install.

While trying to play with --vo=vdpau --hwdec=vdpau I get

[vd] Opening video decoder lavc:h264
[vd] Probing 'vdpau'...
[vd] Requested hardware decoder not compiled.
[vd] Using software decoding.

mpv -V:

mpv git-b5357e8 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Wed Oct 12 07:20:35 CEST 2016
ffmpeg library versions:
   libavutil       55.32.100
   libavcodec      57.61.102
   libavformat     57.51.106
   libswscale      4.1.100
   libavfilter     6.63.100
   libswresample   2.2.100
ffmpeg version: N-81972-g8063978

Full verbose mpv play log:
mpv log2.txt

ffmpeg_options:

--enable-vda

mpv/build/config.log:
config .txt

Notice these lines:

Checking for libavcodec VAAPI hwaccel                                : yes 
Checking for libavcodec videotoolbox hwaccel                         : no 
Checking for Videotoolbox with OpenGL                                : videotoolbox-hwaccel, gl-cocoa not found 
Checking for libavcodec VDPAU hwaccel                                : no 

vdpauinfo:
vdpauinfo.txt

Most helpful comment

Use ffmpeg release.

All 36 comments

Build FFmpeg with VDPAU support.

As you can see I added --enable-vdpau to ffmpeg_options, do I need to do anything else?
Also, it _is_ built with VDPAU, but not with libavcodec VDPAU accel whatever that is.

Checking for VDPAU acceleration                                   : yes 
Checking for VDPAU with OpenGL/X11                                : yes 
Checking for libavcodec VDPAU hwaccel                                : no

Use ffmpeg release.

Incredible! ./use-ffmpeg-release did the trick. Thanks!

likely what's seen in issue #3664

I have the same issue when using ffmpeg release, too. Is it possible the ffmpeg bug now has been released as stable? ffmpeg people see this as an mpv bug (https://ffmpeg.org/pipermail/ffmpeg-user/2016-October/033939.html) so I guess it will not go away automagically. Either we need an experienced developer convincing ffmpeg devs that this is their issue, or mpv needs a workaround...

What's the contents of build_libs/lib/pkgconfig/libavutil.pc?

Here for static linking it's,

prefix=/home/doug/Desktop/mpv-stat/new71/mpv/build_libs
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include

Name: libavutil
Description: FFmpeg utility library
Version: 55.46.100
Requires:
Requires.private:
Conflicts:
Libs: -L${libdir} -lavutil -lm
Libs.private:
Cflags: -I${includedir}

For comparison the system shared .pc

(using shared for build always configures vdpau-hwaccel to yes

prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib/x86_64-linux-gnu
includedir=/usr/include/x86_64-linux-gnu

Name: libavutil
Description: FFmpeg utility library
Version: 55.43.100
Requires:
Requires.private:
Conflicts:
Libs: -L${libdir} -lavutil
Libs.private: -lm
Cflags: -I${includedir}

On 02/14/2017 03:25 AM, V. Lang wrote:
>

What's the contents of |build_libs/lib/pkgconfig/libavutil.pc|?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-279638731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WRN0MrDYJRnahgkd4I5c4ypP3ijBks5rcWUCgaJpZM4KUY2V.

So if this is with static linking, this is definitely a ffmpeg issue. It should link the hw decoding related libs in there. It doesn't, so linking of course fails.

The thing that fails is the check_statement for vdpau-hwaccel. The .pc
has never linked "hw decoding related libs" in the past yet before those
2 ffmpeg commits the current check_statement would work.

Is there any particular reason to have it (the check_statement) as
currently done?

On 02/14/2017 07:10 AM, V. Lang wrote:
>

So if this is with static linking, this is definitely a ffmpeg issue.
It should link the hw decoding related libs in there. It doesn't, so
linking of course fails.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-279691346,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WdvzFpN3BD3ErbXaXNMrAfX6d-KPks5rcZnIgaJpZM4KUY2V.

I just tried mpv-build, and even though the .pc files are not correct either, it worked for me for some reason. There must be something different about linking that on my system it probably eliminates unused functions completely, so there's nothing that can fail.

Which 2 ffmpeg commits?

Mentioned back in Oct., (they were your commits.

The actual 'breaking' commit was
git-8f6f2322285fc14f8f16377db50355864019a757, i.e. ffmpeg: use new
decode API

On 02/14/2017 07:41 AM, V. Lang wrote:
>

I just tried mpv-build, and even though the .pc files are not correct
either, it worked for me for some reason. There must be something
different about linking that on my system it probably eliminates
unused functions completely, so there's nothing that can fail.

Which 2 ffmpeg commits?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-279697150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WU4c-pJS_gXqGV3eJf1UJZ_DrGCvks5rcaDkgaJpZM4KUY2V.

Just in case this would be the ffmpeg-config script in use here
http://sprunge.us/bKjb

No, the builds before that must have been broken too. You just didn't notice it.

Damn, your right, not sure how I screwed up checking back then.

Looking at my changelogs see that
b791d0e4e0d148e399a21b3521d4b4a9ed5e8ae1 was ok so issue arose between
then & 8f6f232...

If worth bisecting to find shouldn't take too long, could do here
tonight if need be.

On 02/14/2017 08:16 AM, V. Lang wrote:
>

No, the builds before that must have been broken too. You just didn't
notice it.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-279704179,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WfVraTPXEGVd8uJC5-0IduvuZHiKks5rcak3gaJpZM4KUY2V.

Can you try this patch: http://sprunge.us/HjTF

Probably won't help.

No change

The 1st. occurrence of the libavcodec VDPAU hwaccel check failing comes
from this small Merge commit,

http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commit;h=32c25f06b79f9edcda726f6e043325d40036cdce

Merge commit 'e85f6f7f8d037c0af0f294000718d9ba22753baa'

  • commit 'e85f6f7f8d037c0af0f294000718d9ba22753baa':
    lavc: allow using AVCodecContext.hw_frames_ctx for decoding

    From config.log of that checkout with mpv-0.22 source

http://sprunge.us/cLdB

On 02/14/2017 11:14 AM, V. Lang wrote:
>

Can you try this patch: http://sprunge.us/HjTF

Probably won't help.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-279753730,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WXFREhogF-keyk5Dech20SUUbVT2ks5rcdMAgaJpZM4KUY2V.

I am sorry I didn't respond in a timely fashion. Although I am subscribed, I didn't get email notifications, maybe because this issue is closed already. Could you perhaps reopen it or should I create a new issue? I am willing to help, tho I am no developer, but I can apply patches and rebuild and provide info if that helps.

The only mystery is why it works for me but not for some others.

I suspect that my system has an implicit -Wl,--as-needed, which hides the error.

Adding -Wl,--as-needed does not change anything for me. config.log proves that this flag is being added for this check compilation, but the result is the same.

Might depend on its position on the command line.

hmmm yes... setting it in LDFLAGS variable causes it to be appended to the very end

Works on Fedora, Debian, and I think Arch too.
Seems like only Ubuntu based distros affected by this issue.

_Grumpage alert level raised from "meh" to "hmph!"_

I set up a jessie vm and can confirm it works there... :-/

At the time of that merge commit it caused 4 checks that had previously passed to fail & fail in exact same manner, the 3 other ones were (desc)
Checking for libavcodec avcodec_enum_to_chroma_pos API
Checking for libavcodec avcodec_profile_name()
Checking for libavcodec decode/encode API
Since then those 3 have been removed from wscript due to min. required ffmpeg version. So what's the reason this current check is still there?

I _think_ the availability of the vdpau FFmpeg API functions changes depending on whether it's compiled against vdpau or not. Normally this shouldn't happen, of course.

It would seem to be a gcc linking order issue. If I were to force the static ffmpeg/mpv build to use gcc-4.4 which wasn't so strict about this then the check statement compiles/passes.
log snippet http://sprunge.us/hSTa
In any event only really concerned if using current ffmpeg statically linked is it ok to bypass this failing check_statement & allow support? (personally have seen no issue..

From a sysadmin perspective this sounds not related. If I compile mpv with vdpau hwaccel (using my debian VM) and run it on affected Ubuntu machine, it works just fine. Whereas the linked issue causes problems when using such an (assumingly correct) compiled-in hwaccel vdpau support.

This minor issue is only concerning a configuration check & no one has
offered that the check failure represents or exposes anything more than
that.

It appears to be from either gcc >= 4.8 or Ubuntu builds of gcc >= 4.8

(- if someone wanted to bother they could try Debian with gcc >=4.8,
5.x, or 6.x

If affected just set the configure check to something that will pass,
with a recent ffmpeg & vdpau it should all be fine. (unless someone can
prove otherwise..

The configure check could be set to several other methods, here I just
look for libavcodec/vdpau.h with check_headers, likely just a
check_true would be sufficient

On 02/17/2017 01:27 AM, Jj0YzL5nvJ wrote:
>

check_trueMaybe this is related...
https://bugs.freedesktop.org/show_bug.cgi?id=99542

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-280565508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WSQRB7w0RxeVMUH-hX0kXfB3UdBXks5rdT3ngaJpZM4KUY2V.

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4):
http://sprunge.us/UNTM

clang version 5.0.0-svn295460-0~x~padoka0 (trunk):
http://sprunge.us/feQP

Doesn't detect libavcodec VDPAU hwaccel with gcc...

Edit:
Surprise!
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) without 'mpv-build':
http://sprunge.us/YWAZ

ffmpeg:

ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
  configuration: --prefix=/usr/local --arch=amd64 --cpu=amd64 --enable-gpl --enable-version3 --enable-nonfree --enable-shared --enable-libfdk-aac --enable-libmp3lame --enable-librtmp --enable-openssl --enable-opengl --enable-libpulse --enable-libass --enable-libbluray --enable-libcaca --enable-libvpx --enable-libvorbis --enable-libtheora --enable-libopus --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg --disable-debug
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

No comments

From your ffmpeg build "--enable-shared"

This has never been about the use of shared ffmpeg libs.

Much ado about nothing, just a configure check that appears to have
limited value

On 02/19/2017 07:44 AM, Jj0YzL5nvJ wrote:
>

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4):
http://sprunge.us/UNTM

clang version 5.0.0-svn295460-0xpadoka0 (trunk):
http://sprunge.us/feQP

Doesn't detect libavcodec VDPAU hwaccel with gcc...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mpv-player/mpv/issues/3657#issuecomment-280916733,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFr3WdvJvbCLpuBBTjboZLgA9K6kFSihks5reDk6gaJpZM4KUY2V.

Oops!, sorry =P

ffmpeg:

ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
  configuration: --extra-cflags=-fPIC --prefix=/usr/local --arch=amd64 --cpu=amd64 --enable-gpl --enable-version3 --enable-nonfree --enable-libfdk-aac --enable-libmp3lame --enable-librtmp --enable-openssl --enable-opengl --enable-libpulse --enable-libass --enable-libbluray --enable-libcaca --enable-libvpx --enable-libvorbis --enable-libtheora --enable-libopus --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg --disable-debug
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

gcc:
http://sprunge.us/KfQb

clang:
http://sprunge.us/GISU

Only gcc doesn't detect the static libavcodec VDPAU hwaccel.

Note: I had to use "-fPIC" because without it I could not compile libmpv ...I don't know if that justify do a more formal report.
Whatever:

/usr/bin/ld: /usr/local/lib/libavfilter.a(allfilters.o): no se puede usar la reubicación R_X86_64_32 contra `ff_af_abench' cuando se hace un objeto compartido; recompile con -fPIC
/usr/local/lib/libavfilter.a: error adding symbols: Valor erróneo
collect2: error: ld returned 1 exit status

Just ran into this issue again and using ffmpeg release did not fix it this time. What's the status on this?

On 02/20/2017 02:09 PM, tsoernes wrote:
>

Just ran into this issue again and using ffmpeg release did not fix it
this time. What's the status?

There is no 'status', just take care of yourself.
You can -
Use an older version of gcc, likely not worth the hassle on 16.04
Use clang, 5.0 & 4.0 work fine here, 3.9.x & 3.8/3.7 would also probably
be ok, they're in 16.04 repo
(- whether you should use clang on both ffmpeg & mpv or just mpv didn't
bother to check, did both here with clang.
Edit wscript to use either a check that works or just use a check_true

Ubuntu 17.04 shipping gcc 6.3.0 works fine again

Was this page helpful?
0 / 5 - 0 ratings