some videos show only green screen with vaapi #2123
Comments
|
Yep, I can confirm. All software decoded videos, no matter the codec, show only green with the vaapi vo. Could be an Ironlake thing, this is what I'm testing with: I just finished a git bisect, d660e67 - vaapi: remove vaDeriveImage() code path - is the offending commit. So it seems Ironlake doesn't like vaGetImage, while vaDeriveImage works properly. Edit: I did some digging. The intel driver code contains a has_accelerated_getimage property which is not defined for g45 and Ironlake. Which means even if GetImage worked, it'd use a slow unaccelerated codepath. So perhaps vaDeriveImage should be added back for the sake of g45 and Ironlake. |
|
I don't have time or effort to test this fucked up shit on hardware I don't even have access to, all while the same shit API doesn't work on any other intel hardware I happen to have. Why don't you complain to Intel to fix their fucked up dumb nonsense shit? |
|
"I don't have time or effort to test this fucked up shit on hardware I don't even have access to, all while the same shit API doesn't work on any other intel hardware I happen to have." Well we have just tested it for you. :) Please, Intel is not going to do anything with older graphic cards just because a new open source media player doesn't work properly. It wants to sell new hardware. Gusar321 has pin pointed the problem. Please fix it for your users. mpv is the best movie player (better than mplayer, mplayer2 and vlc) but many (most?) of us don't have state of the art hardware. Thanks for the great software and the time. |
I don't either. Intel's drivers randomly change behavior, even in completely unreasonable ways (e.g. things that obviously should work just don't), so mpv gets broken. If you don't like this driver behavior, get Intel to fix their drivers, or just don't buy Intel hardware. I've spent so much effort into completely Intel GPU specific issues, and it still doesn't work, so that's it. |
Oh, and that means I have no way to test this. |
|
But before removing vaDeriveImage() code path it was working according to Gusar321's bisect. Can you just reinstate it? |
|
I opened a bug at freedesktop bugzilla, but as Ironlake is old, I don't really expect anything to happen: https://bugs.freedesktop.org/show_bug.cgi?id=91309 And I have to correct my previous post - video display uses _Put_Image, not GetImage. And Ironlake does have an accelerated PutImage path. Doesn't mean much if it doesn't work though. vaDeriveImage does work. |
|
What's the point of using vaapi with software decoding? Doesn't opengl get the job done? |
|
If you use command line then no, but if you use a .config file then you have to fix vo to vaapi if you use vaapi at all, and it is useful for hardware decoding. |
|
Well on this machine i use Intel & never use vo=vaapi, rather hwdec=vaapi vo=opengl (actually vo=opengl-hq |
|
On this machine with vaapi hd 1080 drops from 130% cpu to 12% :) |
|
Does mpv print errors when showing green? |
|
Hi, here are two sample outputs with mpv master (green screen) |
|
Now the same two movies with mpv-0.9.2 (works, with no green screen) |
|
So, none? Then there's no way of detecting this situation. I don't want to risk using vaDeriveImage on new drivers, because who knows when it will suddenly start working again and with different syntax. (I'm not confident that the old usage was good or correct, even if it happened to work on Ironlake.) |
|
No errors printed by mpv. The bug is highly likely in libva-intel-driver. BTW, what issues exactly did you see with vaDeriveImage? I never saw anything weird, not just on Ironlake, but also on Haswell. |
|
Hi, based only on the comments on this thread and the commit I have troubles understanding the decision to remove vaDeriveImage. If as you say Intel's next move is kind of unpredictable it seems odd to try to pre-empt it by removing a feature that may cause "weird things" in the future, while its removal at the present is causing troubles for users with older (but perfectly working) cards. Just my two cents and thank you for your patience. |
|
Still think you should just use opengl with hwdec of vaapi, may be slightly less efficient but vo vaapi sucks in other areas ex. |
|
wmv aren't the only files that can't be hardware decoded. I have a bunch of avi files that contain mpeg4 asp, I even have some mkv files which contain that, then there's 10bit h264 files and the list probably doesn't end here. Care to elaborate where exactly vo_vaapi sucks? With scaling=hq you get hq scaling for free, without the resource usage opengl-hq brings with it. |
|
Except that scaling is anything but HQ. Seems to be just something like tensor
lanczos, and it doesn’t even use the correct chroma location(?)
|
|
I posted some example pictures here: #2109 (comment) Yeah, there's an offset, but you only notice that when comparing single pictures of different output methods, not when actually watching the video. Beyond that I can't see any difference, I don't doubt they're there when doing a close inspection, but in practice it's imperceptible. |
|
Yeah, there's an offset, but you only notice that when comparing single
pictures of different output methods, not when actually watching the video.
If all you watch is overly blurry, low-quality TV rips maybe. And even in that
sample, it’s quite obvious that something is wrong with the chroma and that
there’s excessive ringing, which is partially due to the bad source, but made
worse by the scaler.
It’s not a HQ scaler by any definition; it fails in basic disciplines like
“do not cause image shift,” which any scaler worth a damn manages just fine.
Beyond that I can't see any difference, I don't doubt they're there when
doing a close inspection, but in practice it's imperceptible.
I don’t even need to stare at this to be able to tell that it’s a terrible
scaler. But if you watch sources like the one you’ve posted in the other
issue, it doesn’t even matter if you use that or plain old bicubic_fast; there
is no detail to begin with. For proper sources, this scaler will definitely
cause more aliasing and ringing than spline36, and it will most definitely
look worse than ewa_lanczos (which is an actual HQ scaler).
|
ghost
closed this as
|
vaDeriveImage actually works on modern hardware. Commit 50bd280 enables it for newer hw (see commit message for explanation). This actually changes behavior with vaapi-copy, and of course it's possible that my worries about the memory type etc. will actually come true now, but at least we'll know. |
This has regressed vaapi-copy+xv, due to the need to insert swscale for nv12->yuv420 conversion. But why would anyone use that combination is beyond me. The important thing is, displaying software decoded video with the vaapi vo works much better now. Or, works at all when it comes to Ironlake :) |
|
It is working again. A BIG THANKS!! |
Hi,
With mpv master some videos show only green screen with audio with vaapi. These are some wmv and avi files. This only happens recently. With mpv stable (0.9.2 ) they play fine. For examples, test files from here https://archive.org/details/WorkToFishtestwmv
OS is Ubuntu 15.04 64 bits
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.0.pre1)
vainfo: Driver version: Intel i965 driver for Intel(R) Ironlake Mobile - 1.6.0.pre1 (1.6.0.pre1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
mpv --version
mpv git-8e82a64 (C) 2000-2015 mpv/MPlayer/mplayer2 projects
built on Sat Jul 11 00:52:52 EDT 2015
ffmpeg library versions:
libavutil 54.27.100
libavcodec 56.41.100
libavformat 56.36.100
libswscale 3.1.101
libavfilter 5.16.101
libswresample 1.2.100
My mpv config file
[default]
vo=vaapi,xv,
vo=xv
[vo.vaapi]
hwdec=vaapi
softvol=yes
softvol-max=400
ao=pulse
The text was updated successfully, but these errors were encountered: