12:29 <memeka> anyone awake?

12:37 <javier__> memeka: eaec420f530 [media] v4l2-ioctl/exynos: fix G/S_SELECTION's type handling

12:37 <javier__> it seems that hans made a subsystem wide changed and added a regression

12:38 <javier__> memeka: so I think you should change ctx_get_frame() to not use the _MPLANE versions

12:40 <memeka> javier__: THANK F*

12:40 <memeka> I WAS GOING CRAZY

12:40 <memeka> why my code was not working

12:40 <memeka> after 3 days of debugging I noticed:

12:40 <memeka> gsc v4l2 driver on capture has 1 plane only!!!

12:50 <memeka> javier__: can you please take a look at this: https://pastebin.com/WQciRhar

12:51 <memeka> i am having this issue where GScaler outputs only 1 plane instead of 3

12:52 <memeka> capture is set to YU12

12:52 <memeka> [ 94.483158] video21: VIDIOC_S_FMT: type=vid-out-mplane, width=1920, height=1088, format=NM21, field=none, colorspace=0, num_planes=2, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0

12:52 <memeka> [ 94.483200] video21: VIDIOC_S_FMT: type=vid-cap-mplane, width=1920, height=1088, format=YU12, field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0

13:00 <memeka> javier__: does it matter that input is USERPTR?

13:01 <memeka> i mean output is USERPTR?

13:02 <javier__> memeka: I don't think it should

13:02 <javier__> I always get confused that M2M input and output are backwards

13:02 <memeka> javier__: yes me too :)

13:03 <memeka> javier__: so I am trying to do MFC -> GScaler with USERPTR

13:03 <memeka> MFC output is MMAP

13:03 <memeka> MFC capture is MMAP

13:03 <memeka> GScaler output is USERPTR

13:03 <memeka> GScaler capture is MMAP

13:04 <memeka> after I get the 2-plane buffer from MFC, I update the userptr to point to their mmap addresses:

13:05 <memeka> for (ret = 0; ret < avbuf->num_planes; ret++)

13:05 <memeka> outbuf->planes[ret].m.userptr = (unsigned long)avbuf->plane_info[ret].mm_addr;

13:09 <javier__> memeka: did you try with gst? something like: gst-launch-1.0 filesrc location=test.mov ! qtdemux ! h264parse ! v4l2video1dec output-io-mode=mmap ! v4l2video6convert capture-io-mode=userptr ! kmssink

13:09 <memeka> javier__: GST works :|

13:09 <memeka> ah wait

13:09 <memeka> not with userptr

13:10 <javier__> memeka: hmm, do you have the same error there?

13:10 <memeka> javier__: checkng now

13:10 <javier__> memeka: I really haven't done anything for years with exynos v4l2 drivers so my memory is fuzzy :/

13:11 <javier__> memeka: but if I were you I would first attempt to have a gst pipeline working for your use case and once you are sure that the driver works, then code your v4l2 app

13:12 <memeka> javier__: it works for MMAP all the way

13:12 <javier__> since IME there were some code paths in the driver that weren't too well tested, so it may be a problem with the MFC or GSC drivers

13:12 <javier__> memeka: yes, I tested with mmap and dma-buf all the way and it worked

13:12 <javier__> mfc -> gsc -> exynos drm driver that is

13:13 <memeka> yes

13:13 <javier__> but that was 2 years ago :)

13:13 <memeka> mmap and dmabuf

13:13 <memeka> not userptr :)

13:13 <javier__> yeah, so I would start there

13:14 <javier__> memeka: if you have any issues with gst v4l2 elements, you can ping ndufresne (in #v4l) who's the maintainer

13:15 <javier__> have to leave now, good luck!

13:19 <memeka> javier__: VIDIOC_CREATE_BUFS: error -25

13:33 <javier__> memeka: right, that ioctl isn't implemented by the driver

13:33 <memeka> javier__: that's the USERPTR in gstreamer :)

13:37 <javier__> I see

13:37 <javier__> anyway, leaving for real now

13:37 <javier__> bye!

13:42 <memeka> thx javier__