Random black flicker with hwdec=vaapi #1765
Comments
sjug
changed the title
|
Well, I don't know. We've had a lot of problem with vaapi's GLX interop. Try |
|
Are there any other logs or configs I can provide that would be useful in debugging? |
|
Does it also happen with --vo=vaapi? This would show if the problem is vaapi itself or if it's the GLX interop. Perhaps mpv should consider moving from VA/GLX to texture_from_pixmap. By that I mean instead of using va*SurfaceGLX(), you do vaPutSurface() to a pixmap and then bind this pixmap to a texture with glXBindTexImageEXT(). XBMC/Kodi moved to that, as did libvdpau-va-gl, gstreamer-vaapi uses this method too. It seems to be more robust and it's also more efficient, because the point of texture_from_pixmap is zero-copy. The libvdpau-va-gl commit is here, mplayer-vaapi implemented tfp in this commit. |
|
That API is way more complex. Oh what am I expecting from Intel shit. |
ghost
added
the
Use texture-from-pixmap instead of vaapi's "native" GLX support. Apparently the latter is unused by other projects. Possibly it's broken due that, and Intel's inability to provide anything non-broken in relation to video. The new code basically uses the X11 output method on a in-memory pixmap, and maps this pixmap as texture using standard GLX mechanisms. This requires a lot of X11 and GLX boilerplate, so the code grows. (I don't know why libva's GLX interop doesn't just do the same under the hood, instead of bothering the world with their broken/unmaintained "old" method, whatever it did. I suspect that Intel programmers are just genuine sadists.) This change was suggested in issue #1765. The old GLX support is removed, as it's redundant and broken anyway. One remaining issue is that the first vaPutSurface() call fails with an unknown error. It returns -1, which is pretty strange, because vaapi error codes are normally positive. It happened with the old GLX code too, but does not happen with vo_vaapi. I couldn't find out why.
|
I implemented it. Now tell me if it's less broken, more broken, or equally broken. |
|
PS: to clarify, in git master |
|
I did not have problems before, but I don't have Broadwell like sjug does. Currently I can test Ironlake and Baytrail. And what I can report is, it still works. The turbostat output on Baytrail is interesting. Before: Now: This does hint at TFP being more efficient, especially the PkgWatt number. For comparison, the vaapi vo: And without hardware decoding - as expected, significant difference in CPU utilization: Running turbostat on Haswell should be interesting, there it also reports GfxWatt. I expect a big difference between vaapi and opengl, as opengl stresses the GPU, while vaapi uses fixed function hardware. |
|
@wm4 you are awesome man, I'm working on testing this. I need to buy you a beer or something. |
|
@Gusar321 how do you run turbostat against mpv playback? |
|
Well this issue looks to be fixed, but I do see some other issues.
Should we close this ticket and open a new one? |
|
Intel has released a new version of its libva-intel-driver: 1.5.1 (http://www.freedesktop.org/software/vaapi/releases/libva-intel-driver/) On Archlinux, we are still using the 1.5.0 though (the new version should be ready soon). It may be worth checking if this bug has been fixed upstream as well, even if the updates seems to be mostly focused on the Gen8 graphics. |
Quite simple: Once mpv finishes, turbostat will print the report. Use a file that isn't too long :). Or you limit the test to, say, one minute by adding --end=60. Repeat the process with different values for hwdec and vo. Also, Jiehong's advice is good, you might want to switch libva and libva-intel-driver to 1.5.1. Broadwell is very new, so it's good to have the latest components of everything. Might even want to try the 4.0-rc6 kernel. |
|
@Gusar321 Thanks for that, I guess because it's the root user forking the process that it doesn't read my user config file. As without the explicit hwdec and vo flags it doesn't use vaapi? It's entirely possible it's a "new drivers" issue. |
|
While never broken on Haswell the new changes haven't caused any new issue. |
|
After moving to libva-intel-driver 1.5.1 and using the latest git-master build most of my issues are now resolved. |
|
Good to hear. I'll close this, then. I'm also wondering if I should switch |
|
I'd advocate switching. On SD video, vaapi-copy does no better than software decoding. Turbostat on my Haswell machine decoding 720x404: http://pastebin.ca/2969778 Things are a bit different with HD, turbostat when decoding 720p: http://pastebin.ca/2969780 BTW, what about making --hwdec=auto the default? Is Intel the reason this isn't done? Texture_from_pixmap has made a big difference, perhaps hardware decoding by default is now feasible. |
Intel was/is a big reason, and VDA probably too, but it's possible that both are fixed now. I still don't see much value with hw decoding on desktop though, and it also prevents some of the high quality filters in vo_opengl to work properly (because most hw decoding methods give us RGB instead of YUV). |
|
I don't own a desktop and haven't for years, and on laptops power consumption is always a major concern. |
I am running a brand new arch system and with mpv 0.8.3 I'm seeing random black video flicker (whole frame goes black) as the video plays. The flickers are not consistenent at the timestamps but they continue to occur. I have recently updated from mplayer-vaapi as it is now orphaned in arch, and I never had any of these issues prior.
The files are on the local disk, and I've tried adjusting the cache-size, but it made no difference.
While this file has subtitles, even files without them also flicker.
I've also tried every vo (opengl, opengl-hq, and vaapi) and the flicker still occurs regardless.
Please advise.
Here is mpv -v with software decoding
mpv -v with vaapi
The text was updated successfully, but these errors were encountered: