[FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

Andy Furniss adf.lists at gmail.com
Sun Sep 24 13:08:30 EEST 2017


Mark Thompson wrote:
> On 20/09/17 17:10, Andy Furniss wrote:
>> Mark Thompson wrote:
>>> On 19/09/17 22:21, Andy Furniss wrote:
>>
>>>> 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.
>>
>> Leo has fixed the leak.
> 
> Yep, checked with the updated Mesa postproc patches + libva2 fixes and it all looks good now.  (And colours are even correct, yay!  I still need to look into why the default comes out wrong with the postproc bits for that on Intel...)

One thing that comes out in testing the patches WRT postproc is that for 
deinterlace 1080i25 -> 1080p50 there is an issue with the surface size 
being 1088.
This means the result gets scaled to 1088. It is possible to put scale 
after to get 1080, but this seems sub-optimal, costs about 8% perf and 
hypothetical quality issue (not that I could see it).

Apparently vaapi_scale does things differently and the driver is set for 
that way, so changing in the driver will break scale.

AFAICT this is orthogonal to the 1080/1088 encode issue discussed long 
ago where ffmpeg is doing the right thing, that should be fixable in the 
driver.

This case can be demonstrated with 1920x1080 nv12 hwupload -> deint -> 
hwdownload, so no chance for h26x cropping info being used.


More information about the ffmpeg-devel mailing list