Re: [MPlayer-dev-eng] VAAPI/X11 video output driver
- Date: Wed, 25 Nov 2015 00:04:19 +0100
- From: Roberto Togni <rxt@xxxxxxxxx>
- Subject: Re: [MPlayer-dev-eng] VAAPI/X11 video output driver
On Sun, 22 Nov 2015 17:04:17 +0000
Mark Thompson <sw@xxxxxxxxx> wrote:
> 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).
> * 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,
> * 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
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.
MPlayer-dev-eng mailing list