Created attachment 143863 [details]
picture from screen
I want to decode a H264 1280x720 video with v4l2 decoder and present this on DRM with a dumb buffer.
On screen the Y plane is correct but UV plane have the doubled height. Pitch is correct. But looks like a line from uv plane is used for 4 lines on y plane instead of 2. Attached are a picture from the screen. I use the format describtion from: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-nv12mt.html.
For dumb buffer configuration the height must aligned to 64 instead of to 32. If align height to 32 EINVAL is returned from AddFB2. OK, the UV plane have the half height from Y plane and must aligned to 32.
The size from DRM_IOCTL_CREATE_DUMB_BUFFER is to big. IOCTL returned a dumb buffer size from 1966080.
width = 1280 => aligned to 128 width = 1280
height = 720 => aligned to 64 height = 768
Y plane 1280 * 768 = 983040
UV plane 1280 * 768 / 2 = 491520
Dumb buffer size should be 1474560. Looks like the UV plane have doubled size as it should be.
The device is a Odroid-U3 with Exynos4412.
Kernel version is 5.0.5.
Could you post exact steps to reproduce it? Code/command line, plus kernel logs with drm.debug=31.
Created attachment 143878 [details]
complete dmesg out
The added dmesg out is complete from boot. The warning during boot is new. I never see it before. v4l2-drm-test runs like before.
My code is on github. It's ugly code. Much things are hardcoded. It's only for testing.
Looking at the code apparently you are setting V4L2_PIX_FMT_NV12MT_16X16 in MFC, but MIXER requires V4L2_PIX_FMT_NV12MT.
No, the ioctl there
looks what format MFC can use. This I set in line 155. The output from fprintf line 174:
FMT CAPTURE: width 1280 height 736 4cc TM12 num_planes 2
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/yuv-formats.html say that TM12 is V4L2_PIX_FMT_NV12MT not V4L2_PIX_FMT_NV12MT_16X16. I think the right format is set.
OK, it seems that the format is correct. HW registers also seems to be programmed correctly. Documentation is not helpful at all, at least for me . The only guess I have is that tile format produced by MFC is different than format accepted by MIXER in regard of chroma. Unfortunately I am too busy now to investigate it deeper. Maybe next week I will be able to consult it with sbd more competent in the subject.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/misc/issues/4.