On 19/09/17 22:21, Andy Furniss wrote: > Mark Thompson wrote: >> On 15/09/17 00:15, Andy Furniss wrote: >>> Andy Furniss wrote: >>>> Mark Thompson wrote: >>>>> --- >>>>> Now sets the trusted packet flag; otherwise unchanged. >>>>> >>>>> >>>>> configure | 1 + >>>>> libavdevice/Makefile | 1 + >>>>> libavdevice/alldevices.c | 1 + >>>>> libavdevice/kmsgrab.c | 455 >>>>> +++++++++++++++++++++++++++++++++++++++++++++++ >>>>> 4 files changed, 458 insertions(+) >>>>> create mode 100644 libavdevice/kmsgrab.c >>>>> >>>>> diff --git a/configure b/configure >>>>> index 6581c53c1a..76a7591ceb 100755 >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder" >>>>> iec61883_indev_deps="libiec61883" >>>>> jack_indev_deps="jack" >>>>> jack_indev_deps_any="sem_timedwait dispatch_dispatch_h" >>>>> +kmsgrab_indev_deps="libdrm" >>>> >>>> Doesn't get built for me = doesn't show up as indev after configure >>>> anything special needed? >>> >>> Never mind I found --enable-libdrm (had tried --enable-kmsgrab) >> >> I assume you're going to try AMD + Mesa + VAAPI. >> >> VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 >> -f kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 >> -filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v >> h264_vaapi -profile 578 -bf 0 out.mp4 >> >> Three Mesa issues I had to get around: >> >> * Device derivation doesn't work because the Mesa driver doesn't want to >> initialise on the DRM master device for some reason; making the matching >> device separately does work. >> * Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch >> and use it - if not, the colour conversion just barfs because it wants >> interlaced surfaces. >> * The postproc scaler seems to only write the luma plane when converting >> from RGB - this is also visible when uploading normal RGB images, so just a >> bug somewhere. >> >> With that, it works to record the screen in greyscale... >> >> I have some other Mesa stuff to do queued up (libva2 with VAAPI export for >> EGL import on AMD), so I'll pursue these further soonish. > > Leo just posted a patchset on the mesa list that makes vaapi work better with > this and postproc generally. > > You don't need the env with those and kmsgrab is now working for me - up to a > point ...
Yep, that works for me now too - with colour! (The export to GL for playback is still messed up by interlacing without patching it out, but that looked orthogonal anyway.) > That point being around 7k frames it will run out of something. > > [AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 > (resource allocation failed). > [Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5. > > I see that memory is reducing before this although I still have spare - is > this the same issue you explained on users WRT leaking on decode? Yeah, I also run out of ... something ... at around 7200 frames. It's not fds or memory. I don't think it's the buffer problem (which, incidentally, should finally be fixable sensibly in libva2 soon), because that ended up manifesting as leaking memory. It's also not a problem for Intel (I've already been running that for a long time to test). Maybe some other sort of handle on the Mesa side? I'll investigate further tomorrow. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
