compositor-drm: Add hardware accelerated capture of screen using libva
authorAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Fri, 23 Aug 2013 14:15:48 +0000 (17:15 +0300)
committerKristian Høgsberg <krh@bitplanet.net>
Fri, 30 Aug 2013 20:44:40 +0000 (13:44 -0700)
commit6aae4d39d510ed4d30c029b15d01166380f63e47
tree24e384ff74c30fa12a4f98272dd91f78e535ab39
parent9f43cb48aac9d27aa49fe955104f5cfd204703ed
compositor-drm: Add hardware accelerated capture of screen using libva

This patch adds a feature to the DRM backend that uses libva for
encoding the screen contents in H.264. Screen recording can be
activated by pressing mod-shift-space q. A file named capture.h264
will be created in the current directory, which can be muxed into
an MP4 file with gstreamer using

gst-launch filesrc location=capture.h264 ! h264parse ! mp4mux ! \
           filesink location=file.mp4

This is limitted to the DRM compositor in order to avoid a copy when
submitting the front buffer to libva. The code in vaapi-recorder.c
takes a dma_buf fd referencing it, does a colorspace conversion using
the video post processing pipeline and then uses that as input to the
encoder.

I'm sending this now so I get comments, but this is not ready for
prime time yet. I have a somewhat consistent GPU hang when using
i915 with SandyBridge. Sometimes a page flip never completes. If you
want to try this anyway and your system get stuck, you might need to
run the following:

  # echo 1 > /sys/kernel/debug/dri/0/i915_wedged

After that, alt-sysrq [rv] should work.

Once that's fixed it would also be good to make the parameters used by
the encoder more flexible. For now the QP parameter is hardcoded to 0
and we have only I and P frames (no B frames), which causes the
resulting files to be very large.
configure.ac
src/Makefile.am
src/compositor-drm.c
src/vaapi-recorder.c [new file with mode: 0644]
src/vaapi-recorder.h [new file with mode: 0644]