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

[Roberto Togni]

On Wed, 25 Nov 2015 00:04:19 +0100
Roberto Togni <rxt at rtogni.it> wrote:

> 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.
> 
> 
Oops, I sent this before reading your answer to Compn.

Ciao,
 Roberto