Ticket #17 (new enhancement)

Opened 3 years ago

Last modified 12 months ago

VA-API support

Reported by: mikos Owned by:
Priority: high Milestone:
Component: Video Out (vo) Version: devel
Severity: major Keywords:
Cc: nikoli@…, sre@…, nurahmadie@…, keeperofdakeys@…, darkbasic@…, mike@…, tehstarks@…, dimqua@…, cleanrock@…, simonas@…, giancarlobianchi76@…, nikoamia@…, jon@…, bwat47@…, stlifey@…, ojab@…, lichvarm@… Platform: Linux

Description

Please add support for VA API video decoding accelleration (libva). Patches for original mplayer are here:  http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/

This is last thing missing in mplayer2, which prevents me from switching to it. This is really important thing which should be supported without additional patches.

Change History

comment:1 Changed 3 years ago by Nikoli

  • Cc nikoli@… added

comment:2 Changed 3 years ago by sre

  • Cc sre@… added

comment:3 Changed 3 years ago by nexion

Totally agree. That's the only thing I really need to be implemented in mplayer2.

comment:4 Changed 3 years ago by RussianNeuroMancer

  • Cc runetmember@… added
  • Component changed from General to Video Out (vo)
  • Summary changed from VA API support to VA-API support

comment:5 Changed 3 years ago by fudanchii

  • Cc nurahmadie@… added

comment:6 Changed 3 years ago by Roman2K

  • Cc roman.lenegrate@… added

comment:7 Changed 3 years ago by Roman2K

Eagerly looking forward to this, as well!

Last edited 3 years ago by Roman2K (previous) (diff)

comment:8 Changed 3 years ago by sonny

  • Cc sonny.piers@… added

comment:9 Changed 3 years ago by keeperofdakeys

  • Cc keeperofdakeys@… added

comment:10 Changed 3 years ago by Yegorius

  • Cc yegoriys@… added

comment:11 Changed 3 years ago by darkbasic

  • Cc darkbasic@… added

comment:12 follow-up: ↓ 13 Changed 3 years ago by sirGrey

Now it's  http://code.splitted-desktop.com/git/?p=mplayer.git;a=summary

 http://code.splitted-desktop.com/git/mplayer.git

Also it's not only about video output but about decoding acceleration primarily, so probably better to speak about FFMpeg-VAAPI ?

comment:13 in reply to: ↑ 12 Changed 3 years ago by keeperofdakeys

Replying to sirGrey:
Those patches do implement video decoding, the video out system allows you to implement this (this is also how vdpau decoding is implemented). Just look at your cpu usage when you are decoding HD video.

Since I am very interested in this feature, I am planning on either porting the patches to mplayer2 or making my own (I haven't had a deep look at the patches and how mplayer2 has changed). Unfortunately I am currently in the middle of studies, so I probably won't be able to get a good start at this till mid November. This will definitely be a lot of work though, so we'll have to see if I'm up for the challenge.

comment:14 Changed 3 years ago by FireBurn

  • Cc mike@… added

comment:15 Changed 3 years ago by LLStarks

  • Cc tehstarks@… added

comment:16 Changed 3 years ago by dimqua

  • Cc dimqua@… added

comment:17 Changed 3 years ago by cleanrock

  • Cc cleanrock@… added

comment:18 Changed 2 years ago by nagisa

  • Cc simonas@… added

comment:19 Changed 2 years ago by mp2user

Any updates on this?

comment:20 Changed 2 years ago by darkbasic

+1

comment:21 Changed 2 years ago by hermes14

Looking for updates here too.
I keep using mplayer because mplayer2 doesn't support it.

comment:22 Changed 2 years ago by hermes14

  • Cc giancarlobianchi76@… added

comment:23 Changed 2 years ago by abbradar

  • Cc nikoamia@… added

comment:24 Changed 2 years ago by jonhoo

  • Cc jon@… added

comment:25 Changed 2 years ago by bwat47

I'd love to see this, lack of this feature is the only reason I haven't switched to mplayer2. There's plenty of intel users out there with card/drivers that support accelerated decoding, but mplayer2 still doesn't support it!

comment:26 Changed 2 years ago by bwat47

  • Cc bwat47@… added

comment:27 Changed 22 months ago by martin

Yeah, VA-API support would indeed be a killer...

comment:28 Changed 22 months ago by Roman2K

Sure but 20 months have gone by... Is there still hope of any development being started?

comment:29 Changed 22 months ago by RussianNeuroMancer

  • Cc runetmember@… removed

comment:30 Changed 22 months ago by Roman2K

  • Cc roman.lenegrate@… removed

comment:31 Changed 18 months ago by koct9i

I made quick-n-dirty port of vo_vaapi to mplayer2.
 https://github.com/koct9i/mplayer2/commits/vaapi

Only simple X11 backend works. Currently there is no hardware acceleration or GL/XRender.

Actually I did this only to get non-flickering video output. Both XV and GL modules often shows me nasty horizontal tears on fast motion. So, I have no strong intention to finish hwaccel part, software decoding is perfectly fine for me. Actually I tried, but seems like it's not so trivial as the part which I have done.

comment:32 Changed 18 months ago by koct9i

  • Cc koct9i@… added

comment:33 Changed 18 months ago by uau

I think the hwaccel part would be more useful for most people than the display part. If you get tearing with xv and gl, that sounds like a bug in your graphics drivers or possibly compositing manager (if you use one).

comment:34 Changed 18 months ago by uau

A brief remark about the general state of the VAAPI patches, as the bug didn't have one before:

The biggest issue is that the new vo_vaapi is a low quality VO, both in code quality and functionality. For example, it does all rendering of subtitle bitmaps (the EOSD code) in software, and does it before scaling, resulting in inferior quality (vdpau and gl/gl3 can render at screen resolution). The changes to outside code are also questionable.

The libva API looks clearly inferior compared to for example VDPAU, so making a well-working VO with it may not be simple. One possibility would be to try using the hardware acceleration functionality while handling display of the decoded video with vo_gl3 code, but AFAIK nobody has attempted to implement that so far.

comment:35 Changed 18 months ago by koct9i

Neither VDPAU nor VAAPI cannot handle 10-bit h264, this is hardware limitation.
So all this hardware acceleration is completely useless for me.

Ok EOSD rendering resolution is a good point. Probably I'll try to fix this.

VDPAU does no support Intel GPUs, and I bet it never would.

comment:36 Changed 18 months ago by harklu

Ok EOSD rendering resolution is a good point. Probably I'll try to fix this.

I put significant amounts of work into trying to get vo_vaapi work nicely, but the VA API is too bad and there are too many arbitrary restrictions (one GPU/driver doesn't support screen-space OSD sub picture placement, the other limits the number of sub-pictures to 1 or something else low...)

Have you tried making GL not tear instead? Like putting Option "GLXVBlank" "on" into xorg.conf, and whatever other magic is required to get good graphics with open source drivers.

comment:37 Changed 17 months ago by Yegorius

  • Cc yegoriys@… removed

comment:38 Changed 17 months ago by koct9i

Done. Now it renders subtitles at the screen resolution.

Hardware acceleration for h264 now works too, but quality sometimes is awful.
Probably here is a bug, or it always works in this way.

comment:39 Changed 17 months ago by harklu

OSD and subtitles not visible. Panscan support completely broken (stretches the video). Tested with vaapi vdpau emulation, so it might work better on a native vaapi driver.

comment:40 Changed 17 months ago by sonny

  • Cc sonny.piers@… removed

comment:41 Changed 17 months ago by miros

It seems to be working well with an Intel HD graphics (Sandy Bridge CPU). The OSD and subtitles are visible and so far I haven't noticed any problems with the h264 decoding.

Panscan is broken with mplayer-vaapi too, so it's not a bug introduced in the porting. If it was fixed, would be the code acceptable for inclusion? I understand there is a room for improvements and there are some hardware limitations, but perhaps it's a good start if it works with at least some hardware?

I'd be very happy if this was merged, in one form or another, as it significantly improves the battery life.

comment:42 follow-up: ↓ 43 Changed 17 months ago by harklu

as it significantly improves the battery life.

Did you actually measure this? Others who tested this reported rather discouraging numbers.

comment:43 in reply to: ↑ 42 Changed 17 months ago by miros

Replying to harklu:

as it significantly improves the battery life.

Did you actually measure this? Others who tested this reported rather discouraging numbers.

Yes, I don't recall the exact numbers and it will depend on things like brightness setting, video complexity, etc., but I think with mplayer-vaapi the difference was at least 20%. The air coming from the vent is definitely cooler and the fan is quieter.

comment:44 Changed 16 months ago by stlifey

  • Cc stlifey@… added

comment:45 Changed 15 months ago by ojab

  • Cc ojab@… added

Do want (srsly, guys).

comment:46 Changed 15 months ago by Nikoli

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 :)

comment:47 Changed 15 months ago by koct9i

  • Cc koct9i@… removed

comment:48 Changed 15 months ago by LLStarks

VAAPI backend works great including H.264 acceleration.

Here's a log of my output:  http://pastebin.com/75P3GdP8

comment:49 Changed 15 months ago by miros

  • Cc lichvarm@… added

Cool, it's nice to have more options for video playback. In a quick test with Intel HD the vdpau-va-gl backend seems to be working well, including panscan. According to top, it needs about 70% more of CPU than the VAAPI output by koct9i (which needs a bit more of CPU than mplayer-vaapi). Anyone knows if that is a limitation of the VDPAU/VAAPI+GL translation or something that could be improved in the implementation?

comment:50 Changed 12 months ago by harklu

@koct9i: so how is it that you get no tearing? I actually get tearing on an Intel laptop, even with vaapi (Intel GMA something, with Ubuntu using Unity). It seems whether you get tearing has more to do with your general setup, than with the API you're using. I suspect especially whether you use a compositing window manager can have negative but also positive influence on tearing, depending on hardware and window manager. It would be interesting to know which combinations exhibit tearing and which not.

(Btw., I've added vaapi support to mpv, my mplayer2 fork. Shameless advertising.)

In a quick test with Intel HD the vdpau-va-gl backend seems to be working well, including panscan. According to top, it needs about 70% more of CPU than the VAAPI output by koct9i (which needs a bit more of CPU than mplayer-vaapi). Anyone knows if that is a limitation of the VDPAU/VAAPI+GL translation or something that could be improved in the implementation?

A translation layer is always going to add a slow down, and the VAAPI uses a not-so-fast method of VAAPI/OpenGL interop (vaCopySurfaceGLX). But I can only speculate. But yes, going by user experiences, it's slower. Still better than nothing if the video player software supports vdpau only.

Note: See TracTickets for help on using tickets.