Hey, so my topology is like this: https://p.mort.coffee/PO4 (graph: https://p.mort.coffee/yWK.png). Everything which is connected to /dev/video3 and has a resolution is set to 1280x960. Specifically, both "ov5645 4-003b" and "msm_vfe0_pix" is 1280x960.
However, vidioc_g_fmt returns 1920x1080; https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/camss/camss-video.c#L678 - active_fmt.fmt.pix_mp.width/height is 1920 and 1080
any clue why that might be?
have you called VIDIOC_S_FMT(1280x960) on the video node ?
No. But wouldn't it default to its configured format?
And where's the 1080p coming from in the first place?
fwiw, `v4l2-compliance -d /dev/video3 --streaming` doesn't VIDIOC_S_FMT either and hence it fails
welp, if I `v4l2-ctl --set-fmt-video width=blah,height=blah` first, v4l2-compliance works. I can always make that run at boot right after the media-ctl command. But I feel like this is a symptom of a misconfiguration on my end which should be fixed. I may be wrong though, maybe setting the format with v4l2-ctl is the correct way to do it
1080p is the driver's default. you need to set a format if you want to override it
ok, so I've looked into it a bit more
there's one application which does VIDIOC_S_FMT to 540x351 and then starts streaming with that format; that used to work in an older version of the driver, but now it doesn't because, for whatever reason, the VIDIOC_S_FMT doesn't affect the resolution returned by video_get_subdev_format, even though it affects the active_fmt
formats on subdevs and video nodes are set independently
quite possible that the code was always wrong and the new driver just checks more stuff, but it's weird that active_fmt changes in apparently illegal ways
they need to match, but it's userspace's responsibility to set them
interesting
so the VIDIOC_S_FMT should actually be accompanied by some media-ctl command?
(or whatever ioctl media-ctl does under the hood)
VIDIOC_SUBDEV_S_FMT on the subdev nodes, yes
sounds like the safest approach might be to just set the format of the device and the subdev once at the same time during boot, and then write code which andles whichever resolution VIDIOC_G_FMT gives
I'd recommend writing an application that will set all formats, to achieve the desired output resolution
or, better, using libcamera :-)
libcamera would probably be a good idea
there's support for the camss driver, but I haven't tested it personally
we end up using the raw video4linux says all API a lot anyways though due to using hardware encoders/decoders which are exposed as v4l devices
(IIRC ffmpeg supports hardware decoders exposed as v4l devices, but doesn't support hardware encoders, and the decoder was buggy and produced green frames; otherwise we would've used ffmpeg)
mort_: msm venus driver was buggy yes (racy in many ways), hence why it failed sometimes with gst and ffmpeg, I haven't rested recently
but it should be way better
we support both encoder and decoders in gst, ffmpeg v4l2 encoder support shouldn't be hard to add really, it's just a very small amount of v4l2 code there btw