On 12/03/18 00:03, Rostislav Pehlivanov wrote: > On 11 March 2018 at 22:41, Mark Thompson <s...@jkqxz.net> wrote: > >> --- >> doc/indevs.texi | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/doc/indevs.texi b/doc/indevs.texi >> index 6951940a93..02d1cb3d86 100644 >> --- a/doc/indevs.texi >> +++ b/doc/indevs.texi >> @@ -462,6 +462,14 @@ Capture from CRTC ID 42 at 60fps, map the result to >> VAAPI, convert to NV12 and e >> ffmpeg -crtc_id 42 -framerate 60 -f kmsgrab -i - -vf >> 'hwmap=derive_device=vaapi,scale_vaapi=w=1920:h=1080:format=nv12' -c:v >> h264_vaapi output.mp4 >> @end example >> >> +@item >> +To capture only part of a plane the output can be cropped - this can be >> used to capture >> +a single window, as long as it has a known absolute position. For >> example, to capture >> +and encode the middle quarter of a 1920x1080 plane: >> +@example >> +ffmpeg -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi, >> crop=960:540:480:270,scale_vaapi=format=nv12' -c:v h264_vaapi output.mp4 >> +@end example >> + >> @end itemize >> >> @section libndi_newtek >> -- >> 2.16.1 >> > > On a related note, deriving a vaapi device from kms has never worked for me: > libva: va_getDriverName() failed with operation failed,driver_name=i965 libva doesn't like being created with a non-render fd which isn't the DRM master, which is what you're doing in this case when you are using CAP_SYS_ADMIN to subvert the security model trying to stop processes from capturing screens they don't own. It does work if you are the DRM master (e.g. you are capturing from a VT framebuffer without any display server running). Relevant code: <https://github.com/intel/libva/blob/master/va/drm/va_drm.c#L72-L80>.
Not sure what, if anything, should be done about that. As you've observed it's easy to work around by making a separate render device and mapping to that instead. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
