[FFmpeg-user] Archlinux update breaks kmsgrab: Failed to get plane resources: Permission denied

[Mark Thompson]

On 06/02/2020 06:11, Kai Hendry wrote:
> Hi there,
> 
> For sometime I've been happily using kmsgrab to make screencasts on my Archlinux Xorg desktop.
> 
> https://github.com/kaihendry/recordmydesktop2.0/blob/9825a44d886318d78463c0a602681c0c7931cf83/x11capture#L71
> 
> But then it broke after a reboot as described here:
> https://www.reddit.com/r/ffmpeg/comments/ez4u5z/failed_to_get_plane_resources_permission_denied/
> 
> Downgrading ffmpeg or linux didn't appear to solve the problem. Perhaps it was some Intel driver update? I'm not sure what package to try downgrade or to bisect this breaking dist-upgrade and reboot, since there has been so many updates...

That sounds like it could be some sort of security feature.  kmsgrab is definitely kindof naughty and low-level in the way it captures the screen (which is how it works independently of the window system), so I wouldn't be surprised if something tries to stop it.

> After some frustration I revisited the ffmpeg wiki to find the "Capture the screen from the first active KMS plane" (using -device /dev/dri/card0 instead of -vaapi_device /dev/dri/renderD128) which does work... for a few *minutes* and then bombs out:
> 
> [AVHWFramesContext @ 0x559c5137c400] Failed to create surface from DRM object: 2 (resource allocation failed).
> [Parsed_hwmap_0 @ 0x559c513653c0] Failed to map frame: -5.

This looks like some sort of memory problem.  Two ideas:

* Memory leak.  Does any memory use increase while running the program?  (Might be some sort of GPU memory rather than program memory; not sure where you'd look for that but hopefully it gets noted somewhere...)

* The buffer no longer existing on the expected device.  Do you have multiple GPUs with PRIME offload?  If so, I guess the behaviour around moving the buffers between devices might have changed in a way which breaks somehow (and I've no clue how this might be fixed if so, but it would be interesting to know about).

> Error while filtering: Input/output error
> Failed to inject frame into filter network: Input/output error
> Error while processing the decoded data for stream #1:0
> [AVIOContext @ 0x559c51361500] Statistics: 0 seeks, 15 writeouts
> [h264_vaapi @ 0x559c513492c0] Freed output buffer 0
> [aac @ 0x559c51360580] Qavg: 227.062
> [aac @ 0x559c51360580] 2 frames left in the queue on closing
> Conversion failed!
> 
> Full log is here:
> https://s.natalian.org/2020-02-06/1580968072.mp4.log
> 
> The output file appears unrecoverable: "moov atom not found" :( 

Orthogonal to the real problem, but if you write to a streamable container (MPEG-TS, say) then you should at least have a usable stream up to that point.

> So any tips to get kmsgrab working on my system again? 
> Btw I found kmsgrab *much better* than x11grab since with VAAPI it doesn't appear to make my T480s overheat. So I really want to restore the gloriously efficient kmsgrab UX I was using until some package update broke it.

You're using the iHD driver for the VAAPI part there - assuming you aren't using an Ice Lake, is it any better with i965 (the older VAAPI driver) instead?

- Mark