Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VAAPI support #129

Closed
roberth1990 opened this issue Jul 7, 2013 · 24 comments

Comments

@roberth1990
Copy link

commented Jul 7, 2013

Hello, is it possible to please add vaapi support?

A branche for mplaye2 is here: https://github.com/koct9i/mplayer2

And for mplayer here: http://gitorious.org/vaapi/mplayer

@wm4

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2013

Just some comments:

  • vdpau is the winner, even AMD GPUs are now getting vdpau support, so Intel GPUs are the odd ones with vaapi only support
  • the reason this was never merged in mplayer/mplayer2 was because the original patches were dirty and intrusive and also buggy
  • GPU decoding has virtually no advantages on desktop PCs
  • it's not a priority for us, and there are more important things that have to be done
@ValdikSS

This comment has been minimized.

Copy link

commented Jul 12, 2013

Now it seems possible to use VDPAU on intel GPUs with:
https://github.com/i-rinat/libvdpau-va-gl/
"Briefly, this is the VDPAU driver with VA-API/OpenGL backend."

So nobody needs mplayer-vaapi anymore :)

@wm4

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2013

Keep in mind that this is an imperfect implementation of the vdpau API, which is a problem for mpv's playback core: i-rinat/libvdpau-va-gl#3

(Everything about mplayer2 said there applies to mpv too.)

@Civil

This comment has been minimized.

Copy link

commented Aug 6, 2013

GPU decoding have one important advantage on notebooks (especialy low end and ultrabooks) - lower power consumption (and low end notebooks may not be able to decode video at full speed at all).

Also there is another technology - OpenMAX that is supported on Embedded devices (mostly ARM based). AFAIK there are no players that supports OpenMAX at all.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2013

OpenMAX

This stuff AFAIK has the problem that it provides some sort of video player API, not a decoding API.

@Civil

This comment has been minimized.

Copy link

commented Aug 8, 2013

It have 3 different Layers with different type of abstraction. From low-level API for decoding (implemented on some ARM Linux) to high level API to build media players around it (implemented in Android).
For example, broadcom implemented 2-nd (Integration) level of API, and it seems that it's more like libvdpau.

It's said that using OpenMAX is not an easy task, but anyway it may be useful.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2013

So I thought why not, and ported the vaapi patch: https://github.com/mpv-player/mpv/tree/vaapi

(I realized "why not".)

@aktau

This comment has been minimized.

Copy link

commented Aug 11, 2013

So I thought why not, and ported the vaapi patch: https://github.com/mpv-player/mpv/tree/vaapi
(I realized "why not".)

It may very well be horrible code-wise, but VA-API does perform quite well in conjunction with intel hardware on UNIX. With a HD 4000 I can get 16 simultaneous 1080p videos (apple movie trailers) playing like it's nothing. About 50% CPU usage. The celeron processor on the same unit has some serious load with even one HD video. Which is why I decided to go with mplayer-vaapi for a project of mine. Haven't noticed the buggyness either, it runs on HD 3000 and HD 4000 for days (weeks) on end without crashing.

That said, thanks for porting the code, I must admit I like the atmosphere and philosophy of the mpv project quite a bit.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2013

Well, did you test the mpv branch? Does it work?

I'm actually most concerned about OSD/subtitle issues, because that's a problem area of the API - they also behaved completely differently on the vaapi vdpau emulation driver and native vaapi.

@aktau

This comment has been minimized.

Copy link

commented Aug 11, 2013

No I haven't (yet). I just looked at mpv again because of hacker news. I'd looked at it before but when I started my project it wasn't yet in a state where I was confident it was going to forge ahead. Also the lack of supported* VA-API made me dismiss it (and mplayer2). At the moment I got precious little time for testing things I can't use because we're already in the rollout phase. The thing is also that I have absolutely no need for subtitles at the moment. Just hardware accelerated display on intel units with video that can scale. The units I use are really not powerful enough for the content this project must broadcast, I had to make do. So in that aspect VA-API is not "useless", at least not in the same league as teletext.

I just want to mentally support you guys and tell you you're doing a great job. I'm a big fan of mplayer and it's derivatives, for me they're the best video player.

If I get a weekend free, I'll compile mpv and compare!

For v2 I'll definitely look at mpv again though, as I said, I like the idea behind it: cut the cruft, clean code.

  • I realize(d) VA-API is not supported for regular mplayer either, but it's more vanilla, and Gwenole (the original developer) is about as close to VA-API as you can get since he works on libva and the intel driver for it as well, so I took the leap.
@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2013

Actually I merged it to master. The code is almost completely separate to the rest of mpv, so there are no downsides to it. I deleted the vaapi branch to reduce possible confusion.

@Civil

This comment has been minimized.

Copy link

commented Aug 12, 2013

I've tried to build mpv with --enable-vaapi flag. It seems to work, at least CPU usage 10 times lower on my Notebook with --vo=vaapi --hwdec=auto

I've got some video with sutbtitles, I can try to check bugs you've mentioned earlier. Where should I look for them?

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2013

with --enable-vaapi flag

Should be unnecessary. It should pick up libva automatically. In fact, you have to link to libva manually if you use that flag.

I've got some video with sutbtitles, I can try to check bugs you've mentioned earlier. Where should I look for them?

Look whether they're correctly placed, and whether they stick to the video when going fullscreen and using the panscan controls (w/e keys), assuming the video aspect ratio is different from your screen's.

@Civil

This comment has been minimized.

Copy link

commented Aug 13, 2013

I've tested video with subtitles.
In first look - without using panscan everything is quite correct. Panscan works different with vo=vaapi and vo=xv.

With vaapi subtitles changes it's size, but doesn't change position.
Screenshot with vo=vaapi: http://yadi.sk/d/GClqC6vX7rfdU
Screenshot with vo=xv: http://yadi.sk/d/k2RUEMYZ7rfcS
Both screenshots are rather heavy (1.1MB png). It's 720p video, fullscreen on 3 monitors

@aktau

This comment has been minimized.

Copy link

commented Aug 13, 2013

Both screenshots are rather heavy (1.1MB png). It's 720p video, fullscreen on 3 monitors

Excuse me for budging in like that, but are you displaying the same video stretched over 3 monitors? May I ask how you're doing that? Xinerama? Do you need any special switches (for mpv) or config (for X11)? Do you have 3 video-out ports or are you using some special piece of hardware to make it look like one big screen? It would be really cool if I could do that on my setup too :)

@Civil

This comment has been minimized.

Copy link

commented Aug 13, 2013

It is notebook with intel hd 4000. One internal screen (1600x900) + 2x external (1920x1080, one connected via D-Sub, one via HDMI). And xrandr setups this configuration to behave as one big 5440x1080 screen:
xrandr --output "HDMI1" --mode 1920x1080 --refresh 60 --pos 0x0
xrandr --output "VGA1" --mode 1920x1080 --refresh 60 --pos 1920x0
xrandr --output "eDP1" --mode 1600x900 --refresh 60.1145782470703 --pos 3840x0
(in fact now it's managed by kde's kscreen, but this script does same thing)
No switches for mpv (xinerama is even not enabled at compile time) and no special config for X11 (because it's notebookand I have 2 additional monitors only at work, so static config is not suitable for me)

I think it's an offtopic here, so if you still have questions about my setup, contact me via e-mail or any other communications

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2013

Thanks for testing. These screenshots are not so useful; where are the subtitles even on the other screenshot? (Also, one of then screnshots has ugly green lines on the top and bottom - probably a bug, possibly ours.)

Subtitle placement can be very weird. For vo=xv, it's pretty much static, but some other VOs try to keep subtitle inside the screen (consider the case where the screen borders would cut off subtitles). However, both vo=xv and vo=opengl (and even vo=x11) should produce acceptable behavior. Can you test whether vaapi matches any of them on your system?

When I tested vaapi using its vdpau backend, the subtitle placement was pretty wrong, and they were shifted to the left (or was it the right) when using panscan controls.

@Civil

This comment has been minimized.

Copy link

commented Aug 13, 2013

Subtitles were on both screenshots, but with panscan increased they just went offscreen with -vo=xv, while with vaapi - only size was increased. So it's different behavior.

I've got only simple subtitles, they are placed correctly(http://yadi.sk/d/IWJqxYlz7rl12 - vaapi, http://yadi.sk/d/aX1XK6dg7rkxI - xv, I can't see any difference between them). I'll do more testing soon and I'll try to find video with aspect ratio other then 16:9.

@aktau

This comment has been minimized.

Copy link

commented Aug 13, 2013

It is notebook with intel hd 4000. One internal screen (1600x900) + 2x external (1920x1080, one connected via D-Sub, one via HDMI). And xrandr setups this configuration to behave as one big 5440x1080 screen:

@Civil Thanks for that, I've been dying to try out something like that, didn't know it was that easy!

@wm4 I just compiled and tested mpv vs mplayer-svn with vaapi patch and a 1080p video from apple movie trailers (star trek 2 trailer):

mplayer-svn: ~50% CPU, playback sometimes choppy
mplayer-svn -vo vaapi: ~5% CPU, playback smooth as butter
mpv-git: ~50% CPU, playback quite smooth
mpv-git --vo=vaapi --hwdec=auto: 5% CPU, playback very smooth

So, it seems you did a great job porting the patch to mpv and it brings a lot of battery and playback advantages. I haven't really stress-tested it, so I don't know if it's as stable as the mplayer-vaapi code (which is rock-solid here, btw, runs for weeks).

The one difference I noticed is that without flags, mpv will seemingly try to scale the video to fit within the desktop, while mplayer will display a full-size window even if it doesn't fit in the deskop.

So, what for the mpv team is something low-priority could end up being very cool for some people, thanks! (this will make me much more likely to consider moving to mpv in a later iteration of my project). Especially because now its mainline mpv. I always felt a tad bit uncomfortable that I had to patch mplayer to get vaapi support in, but there you have it.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2013

mpv will seemingly try to scale the video to fit within the desktop, while mplayer will display a full-size window even if it doesn't fit in the deskop.

Unless you're using certain options, the window size should be the same as the video on X11. Unless your window manager is doing something special. This behavior should be the same with -vo vaapi and -vo xv.

@aktau

This comment has been minimized.

Copy link

commented Aug 14, 2013

Unless you're using certain options, the window size should be the same as the video on X11. Unless your window manager is doing something special. This behavior should be the same with -vo vaapi and -vo xv.

The options are exactly what I put in the post. For both mplayer and mpv, once forcing vaapi, once without. It was the size of the window that was diffferent for mplayer and mpv. Mplayer seems to display a full 1920x1080 window which goes beyond the screen (my resolution is 1440x900) while mpv creates a properly maximized window with black bars (it maintains aspect ratio). This is, seemingly, a difference in behaviour between mpv and mplayer. It did not seem to affect playback speed.

EDIT: My window manager is xfce 4.8's xfwm btw.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2013

I tried it myself (xfce 4.10, I think), and there was no difference between MPlayer and mpv. Maybe you have a geometry config option somewhere or a window manager rule that treats MPlayer differently (if xfce has that)?

@aktau

This comment has been minimized.

Copy link

commented Aug 14, 2013

I tried it myself (xfce 4.10, I think), and there was no difference between MPlayer and mpv. Maybe you have a geometry config option somewhere or a window manager rule that treats MPlayer differently (if xfce has that)?

It's really bog-standard xfce 4.8, didn't change anything (don't have to, it's a base debian wheezy unit, not my workstation, it installs xfce through puppet and I'm done). The only thing I can think of is that the resolution of the video > the resolution of my desktop, which might not be the case for you. Otherwise maybe we're using different versions of mplayer. I have a recent vaapi-mplayer. Gwenole Beauchesne rebased his vaapi patch on top of a recent mplayer about a month ago, I have that one.

So yea, maybe it's 4.8 default, but I don't consider it to be a big problem in any case. Porbably the mpv behaviour is a bit nicer as it doesn't try to create a window that's partly invisible.

Anyway, the important part in this issue is the vaapi, which seems to work wonderfully in both mplayer and mpv, which is good. For me, that's a huge advantage mpv now has over mplayer2 (and vanilla mplayer). If possible, it should be advertised more :) (but perhaps first tested by more people).

EDIT: it's also a big advantage over VLC, which doesn't have good hardware playback on linux. Its vdpau support is barely better than software acceleration (high CPU usage), and vaapi has to be done through a vdpau emulation layer which sucks even more.

@wm4

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2013

OK, I consider this finished.

If anyone wants to try, keep in mind it's not in the stable release, only git master.

@wm4 wm4 closed this Sep 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.