No, the Unicam and TC358743 drivers have never supported VIDIOC_CROPCAP.It looks strange to me v4l2src lost the ability for VIDIOC_CROPCAP with the newer version
The tc358743 driver gives no information about aspect ratio. The HDMI AVI infoframe does have an enum for picture aspect (4:3, 16:9, 64:27, or 256:135), but that again would be dictated by the source and not your caps.
Trixie's version of GStreamer is now trying to set the pixel aspect ratio on the source device (valid on some source devices such as webcams) and "corrects" the caps to match what has actually been applied. That would be part of https://gitlab.freedesktop.org/gstreame ... uests/6242
Taking your log and breaking up the very long GStreamer log lines
Code:
0:00:03.461379622 1342 0x7fff30000b70 INFO v4l2 gstv4l2object.c:5426:gst_v4l2_object_probe_caps:<v4l2src0:src> probed caps: video/x-raw(memory:DMABuf),format=(string)DMA_DRM, drm-format=(string){ YUYV, UYVY, BX24, RG24, BG24, XR15, RG16_BE, RG16, "R8\ \ ", "R16\ ", VYUY, YVYU },width=(int)[ 16, 16384, 2 ],height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ];video/x-bayer, format=(string){ rggb16le, grbg16le, gbrg16le, bggr16le, rggb, grbg, gbrg, bggr },width=(int)[ 16, 16384, 2 ],height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ];video/x-raw, format=(string){ YUY2, UYVY, xRGB, BGR, RGB, BGR15, RGB15, RGB16, GRAY8, GRAY16_LE, YVYU },width=(int)[ 16, 16384, 2 ]height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ]0:00:03.461442327 1342 0x7fff30000b70 DEBUG v4l2src gstv4l2src.c:789:gst_v4l2src_negotiate:<v4l2src0> caps of src:video/x-raw(memory:DMABuf),format=(string)DMA_DRM,drm-format=(string){ YUYV, UYVY, BX24, RG24, BG24, XR15, RG16_BE, RG16, "R8\ \ ", "R16\ ", VYUY, YVYU },width=(int)[ 16, 16384, 2 ],height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ];video/x-bayer,format=(string){ rggb16le, grbg16le, gbrg16le, bggr16le, rggb, grbg, gbrg, bggr },width=(int)[ 16, 16384, 2 ],height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ];video/x-raw,format=(string){ YUY2, UYVY, xRGB, BGR, RGB, BGR15, RGB15, RGB16, GRAY8, GRAY16_LE, YVYU },width=(int)[ 16, 16384, 2 ],height=(int)[ 16, 16384 ],pixel-aspect-ratio=(fraction)1/1,framerate=(fraction)[ 0/1, 2147483647/1 ]0:00:03.463268133 1342 0x7fff30000b70 DEBUG v4l2src gstv4l2src.c:797:gst_v4l2src_negotiate:<v4l2src0> caps of peer:video/x-raw,width=(int)1920,height=(int)1080,pixel-aspect-ratio=(fraction)16/9,format=(string)BGR,framerate=(fraction)[ 0/1, 2147483647/1 ]0:00:03.463296022 1342 0x7fff30000b70 DEBUG v4l2src gstv4l2src.c:803:gst_v4l2src_negotiate:<v4l2src0> intersect: EMPTYHowever whilst you can't change the pixel aspect ratio of the source, you can use capssetter to change the caps advertised to the rest of the pipeline.
I'm not clear why you're needing videoconvert and videoscale as you're not actually specifying the sizes or formats that you want either to produce. What does it autonegotiate to?
I was expecting that setting a render-rectangle on kmssink would allow stretching of the image, but it appears not - it retains the aspect ratio.
Having pixel-aspect-ratio set in the caps is also giving me other weird cropping in kmssink. Size of 1024x768 with pixel aspect ratio of 16/9 or 9/16 crops the source buffer (either 1024x432 or 576x768 expanded to 3840x1620 or 1620x2160) instead of changing the destination rectangle. To my mind that is a bug in kmssink.
Adding can_scale=1 seems to help, but that still crops to retain a 1:1 PAR.
All of that is quite frustrating as the vc4 DRM driver will scale your plane any which way you like with almost zero performance penalty, you just have to convince GStreamer to tell it the values you want.
Statistics: Posted by 6by9 — Tue Dec 16, 2025 12:45 pm