[MPlayer-dev-eng] VAAPI/X11 video output driver

[Roberto Togni]

On Sun, 22 Nov 2015 17:04:17 +0000
Mark Thompson <sw at jkqxz.net> wrote:

> 
> Hi,
> 
> See patch attached: apply to current trunk mplayer, configure, make
> mplayer, run with -vo vaapi on anything using recent Intel graphics (or
> something else with VAAPI, maybe).
> 
> This is very much in a "works for me" state.  If it's useful to anyone
> else then they can use it as-is, and if it or some derivative is
> sensible to integrate into mplayer then that would be nice.  There are
> probably lots of edge cases I haven't considered which crash it.  It's
> also quite possible that I have broken other things with these changes
> (especially VDPAU and XvMC in the libavcodec driver).
> 
> 
> Features:
>    * Plays H.264, H.265, WMV3, VC1 and MPEG2 streams on Intel Quick Sync.
>    * Fully accelerated, with no extra redundant memcpy of image data
> (looking at you, VLC).
>    * No ffmpeg changes required - uses the hwaccel interface.
>    * Interface controls all work normally (keyboard input, resize,
> fullscreen).
> 
> 
> Deficiencies:
>    * It can only output to an X11 window (maybe it should be called
> vaapi_x11).  OpenGL output probably wouldn't be hard to add to the
> existing code; alternatively there could separately be a filter which
> comes after a decoder to convert frames to a format usable in other places.
>    * Tearing is visible.  There is probably some nice X11 way to fix this
> by drawing to multiple drawables and swapping.
>    * Choosing video formats can do strange things.  If you try to play an
> MPEG4 stream on Intel (not supported by Quick Sync), it gets stuck.
>    * It can't play in non-accelerated mode (software-decoded planes).
> This could straightforwardly be rectified (just memcpy data into a
> surface), but it doesn't have any obvious value because other outputs
> already do this properly.
>    * No OSD support.  Unclear how to do it nicely (map the surface and
> draw directly on it; do something clever with transparency?).
>    * No deinterlacing or other filter features.
>    * Cleanup on errors is incomplete (will leak memory and possibly do
> other nasty things).
> 
> 
> Tested configurations (on Debian Stretch, libva 0.38):
>    * 7th generation Intel graphics (Haswell 4500U): H.264, WMV3, VC1.
>    * 8th generation Intel graphics (Braswell N3700): as 7th, plus H.265
> (using the GPU hybrid decode, which works completely transparently).
> 
> I have no reason to believe that 9th generation (Skylake) will not work;
> similarly older versions (with correspondingly less capability).  I
> don't know about other (non-Quick Sync) VAAPI drivers.
> 
> I tried resolutions up to 4K.  The Haswell was perfectly happy playing
> eight simultaneous 30Mbps 4K25 H.264 streams with downscale to 720p,
> needing about 20% CPU to do it.
> 
> VP8 and VP9 (present in 8th and 9th generation Intel graphics
> respectively) are not supported because they are not yet implemented in
> ffmpeg.  If they were and matched the existing drivers, I imagine they
> would just work after updating a few lists.
> 
> 
> Some questions:
>    * How is the video format choice meant to work?  I feel like I am
> rejecting everything offered which isn't VAAPI hwaccel from libavcodec,
> but nasty things still happen if you try to play an unsupported stream
> (it doesn't give up).
>    * How is information meant be passed back from libavcodec to the vo
> driver?  This patch makes a nasty global to release frames allocated by
> the output once they are finished with (no longer needed for
> referencing).  Also it would be nice to know the number of reference
> frames the stream requires so that we don't waste so much memory.
>    * Same question in the other direction.  There is another nasty global
> for passing the hwaccel context into libavcodec.
>    * What libvo controls (VOCTRL_*) and related support are regarded as
> required for a new VO driver?
> 
Thanks for the patch, I will look into it in the next days.

I posted a patch some time ago, that ports the VAAPI support from the
mplayer-vaapi fork. It supports OSD, GL, filters, and some other
things. If you want to look at it you can find it here 
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2015-October/073163.html
It also uses globals to pass the hwaccel context, but only because I
was lazy; the original code used a VOCTRL for it.
It's tested only on vaapi 0.36 (version in debian stable) on a
sandybridge; I don't have any newer processor.


Ciao,
 Roberto