[MPlayer-dev-eng] VAAPI/X11 video output driver
sw at jkqxz.net
Sun Nov 22 18:04:17 CET 2015
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.
* 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 31426 bytes
Desc: not available
More information about the MPlayer-dev-eng