Previously, vaapi_recorder_frame() would wait until the encoded
contents for a frame is written to the output file descriptor. This
delayed the repainting of the next frame, and affected frame rate
when capturing with high resolutions. Instead, wait only if there is
and attempted to encode two frames at the same time.
Increases framerate from 30 to 60 fps when capturing at 1920x1200 on
my SandryBridge system, although there are periodic slowdowns due to
disk writes.
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.
Kristian Høgsberg
Ander Conselvan de Oliveira