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

[Mark Thompson]

On 15/09/17 17:19, Mark Thompson wrote:
> On 15/09/17 16:11, Carl Eugen Hoyos wrote:
>> 2017-09-15 16:37 GMT+02:00 Mark Thompson <sw at jkqxz.net>:
>>> On 15/09/17 13:09, Carl Eugen Hoyos wrote:
>>>> 2017-09-15 0:37 GMT+02:00 Mark Thompson <sw at jkqxz.net>:
>>>>> On 14/09/17 22:30, Carl Eugen Hoyos wrote:
>>>>>> 2017-09-07 23:56 GMT+02:00 Mark Thompson <sw at jkqxz.net>:
>>>>>>
>>>>>>> +static const struct {
>>>>>>> +    enum AVPixelFormat pixfmt;
>>>>>>> +    uint32_t drm_format;
>>>>>>> +} kmsgrab_formats[] = {
>>>>>>> +    { AV_PIX_FMT_GRAY8,    DRM_FORMAT_R8       },
>>>>>>> +    { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16      },
>>>>>>> +    { AV_PIX_FMT_RGB24,    DRM_FORMAT_RGB888   },
>>>>>>> +    { AV_PIX_FMT_BGR24,    DRM_FORMAT_BGR888   },
>>>>>>> +    { AV_PIX_FMT_0RGB,     DRM_FORMAT_XRGB8888 },
>>>>>>> +    { AV_PIX_FMT_0BGR,     DRM_FORMAT_XBGR8888 },
>>>>>>> +    { AV_PIX_FMT_RGB0,     DRM_FORMAT_RGBX8888 },
>>>>>>> +    { AV_PIX_FMT_BGR0,     DRM_FORMAT_BGRX8888 },
>>>>>>> +    { AV_PIX_FMT_ARGB,     DRM_FORMAT_ARGB8888 },
>>>>>>> +    { AV_PIX_FMT_ABGR,     DRM_FORMAT_ABGR8888 },
>>>>>>> +    { AV_PIX_FMT_RGBA,     DRM_FORMAT_RGBA8888 },
>>>>>>> +    { AV_PIX_FMT_BGRA,     DRM_FORMAT_BGRA8888 },
>>>>>>> +    { AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV     },
>>>>>>> +    { AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU     },
>>>>>>> +    { AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY     },
>>>>>>> +    { AV_PIX_FMT_NV12,     DRM_FORMAT_NV12     },
>>>>>>> +    { AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
>>>>>>> +    { AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
>>>>>>> +    { AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
>>>>>>
>>>>>> Which of those were you able to test?
>>>>>
>>>>> Only the 32-bit RGB0-type ones (all of them are testable because you just get the colours in a different order).
>>>>
>>>> So RGB0, BGR0, 0RGB and 0BGR all work fine?
>>>
>>> Yes.
>>>
>>> I've verified YUYV/UYVY directly on Intel as well now.
>>>
>>>>> Intel at least should work with others in near-future versions (e.g. <https://lists.freedesktop.org/archives/intel-gfx/2017-July/132642.html>), though I haven't actually tested this.  It seemed sensible to include all core DRM formats which map to ffmpeg pixfmts to account for other drivers (possibly future) which I can't test now.
>>
>>>> Good idea, twelve more are attached.
>>>
>>> Looks sensible.
>>
>> May I commit?
> 
> Are you able to test at all?  I believe I should be able to test at least 565 properly a bit later today (and settle the ordering question - I do think now that my interpretation is wrong and that it was working because the same method was used in both directions).

Ok, I've done a lot more format testing now, with explicitly created framebuffers on Rockchip:

* The four-element RGB formats are indeed in the order stated in the file, not the order in the name.  This means they are reversed wrt everything else in ffmpeg, so I'm fixing that.
* RGB24 and BGR24 /are/ correct already, the endianness comments in drm_fourcc are misleading for them.
* The multiple-plane formats are not usable, because the planes need not be contiguous (you get garbage in the chroma plane), so I'm going to remove support for them.  There is currently no way to query the offsets of later planes, but if that were added then they could be supported.
* RGB565 and BGR565 work correctly, the rest of formats in your patch are untested.

Patches follow, including yours.

Thanks,

- Mark