mirrors
/
weston
mirror of https://gitlab.freedesktop.org/wayland/weston.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
weston/libweston/backend-drm/vaapi-recorder.h

39 lines
1.5 KiB
C
Raw Normal View History

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.
2013-08-23 18:15:48 +04:00
/*
* Copyright © 2013 Intel Corporation
*
src: Update boilerplate from MIT X11 license to MIT Expat license
2015-06-12 01:35:43 +03:00
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
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.
2013-08-23 18:15:48 +04:00
*
src: Update boilerplate from MIT X11 license to MIT Expat license
2015-06-12 01:35:43 +03:00
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
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.
2013-08-23 18:15:48 +04:00
*/
#ifndef _VAAPI_RECORDER_H_
#define _VAAPI_RECORDER_H_
struct vaapi_recorder;
struct vaapi_recorder *
vaapi_recorder_create(int drm_fd, int width, int height, const char *filename);
void
vaapi_recorder_destroy(struct vaapi_recorder *r);
vaapi-recorder: Don't loop trying to write on out of space condition The error handling for the function that writes the encoded frame on the disk was bogus, always assuming the buffer supplied to the encoder was too small. That would cause a bigger buffer to be allocated and another attempt to encode the frame was done. In the case of a failure to write to disk (due to ENOSPC, for instance) that would cause an endless loop. Possibly-related-to: https://bugs.freedesktop.org/show_bug.cgi?id=69330
2014-05-09 16:57:38 +04:00
int
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.
2013-08-23 18:15:48 +04:00
vaapi_recorder_frame(struct vaapi_recorder *r, int fd, int stride);
#endif /* _VAAPI_RECORDER_H_ */