vdpau: Requested hardware decoder not compiled. Using software decoding. #3657
Comments
|
Build FFmpeg with VDPAU support. |
|
As you can see I added |
|
Use ffmpeg release. |
|
Incredible! |
|
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 |
|
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
<#3657 (comment)>,
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
<#3657 (comment)>,
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
<#3657 (comment)>,
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 |
|
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
<#3657 (comment)>,
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
<#3657 (comment)>,
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 |
|
Adding |
|
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. |
|
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) |
|
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. |
|
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
<#3657 (comment)>,
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): clang version 5.0.0-svn295460-0 Doesn't detect libavcodec VDPAU hwaccel with gcc... Edit: ffmpeg: 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
<#3657 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFr3WdvJvbCLpuBBTjboZLgA9K6kFSihks5reDk6gaJpZM4KUY2V>.
|
|
Oops!, sorry =P ffmpeg: clang: 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. |
|
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 |
I'm using mpv-build to pull newest mpv and ffmpeg from github and install.
While trying to play with
--vo=vdpau --hwdec=vdpauI getmpv -V:
Full verbose mpv play log:
mpv log2.txt
ffmpeg_options:
mpv/build/config.log:
config .txt
Notice these lines:
vdpauinfo:
vdpauinfo.txt
The text was updated successfully, but these errors were encountered: