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

[Mark Thompson]

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).  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.

I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other KMS drivers, though if the output is tiled or not-CPU-mappable it can be hard to get the output somewhere where it can actually be used.  (The ARM ones are fine and allow hwdownload directly.  Intels I've tried are mappable but tiled so hwdownload is messed up, but they interoperate cleanly with VAAPI.  The AMD I have makes the objects completely unmappable from the CPU, but they can be imported to other GPU things with Mesa.)

> I find the comments in the header file very misleading:
> What is "little-endian 8:8:8:8 ARGB"?

It is just A-R-G-B in memory in that order as you might expect without the comment.  Not sure why it says little-endian - maybe to emphasise that it doesn't change based on the host architecture?

Thanks,

- Mark