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