<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   ***: camus has quit IRC (Read error: Connection reset by peer)
   <br> camus has joined #linux-media
   <br> camus1 has quit IRC (Ping timeout: 480 seconds)
   <br> camus1 has joined #linux-media
   <br> camus has quit IRC (Remote host closed the connection)
   <br> NiksDev has quit IRC (Ping timeout: 480 seconds)
   <br> uajain_ is now known as uajain
   <br> camus1 has quit IRC (Remote host closed the connection)
   <br> camus has joined #linux-media
   <br> miqztee has joined #linux-media
   <br> camus has quit IRC (Remote host closed the connection)
   <br> camus has joined #linux-media
   <br> ao2 has joined #linux-media
   <br> camus1 has joined #linux-media
   <br> camus has quit IRC (Ping timeout: 480 seconds)
   <br> ao2 has quit IRC (Quit: Leaving)
   <br> miqztee has quit IRC (Ping timeout: 480 seconds)
   <br> djrscally has joined #linux-media
   <br> BrianG61UK_ has quit IRC (Read error: Connection reset by peer)
   <br> BrianG61UK_ has joined #linux-media
   <br> camus has joined #linux-media
   <br> camus1 has quit IRC (Ping timeout: 480 seconds)
   mort_: 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.
   <br> 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
   <br> any clue why that might be?
   pinchartl: have you called VIDIOC_S_FMT(1280x960) on the video node ?
   mort_: No. But wouldn't it default to its configured format?
   <br> And where's the 1080p coming from in the first place?
   <br> fwiw, `v4l2-compliance -d /dev/video3 --streaming` doesn't VIDIOC_S_FMT either and hence it fails
   <br> 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
   pinchartl: 1080p is the driver's default. you need to set a format if you want to override it
   mort_: ok, so I've looked into it a bit more
   <br> 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
   pinchartl: formats on subdevs and video nodes are set independently
   mort_: 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
   pinchartl: they need to match, but it's userspace's responsibility to set them
   mort_: interesting
   <br> so the VIDIOC_S_FMT should actually be accompanied by some media-ctl command?
   <br> (or whatever ioctl media-ctl does under the hood)
   pinchartl: VIDIOC_SUBDEV_S_FMT on the subdev nodes, yes
   mort_: 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
   pinchartl: I'd recommend writing an application that will set all formats, to achieve the desired output resolution
   <br> or, better, using libcamera :-)
   mort_: libcamera would probably be a good idea
   pinchartl: there's support for the camss driver, but I haven't tested it personally
   mort_: 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
   <br> (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)
   ***: miqztee has joined #linux-media
   <br> miqztee has quit IRC ()
   <br> camus1 has joined #linux-media
   <br> camus has quit IRC (Ping timeout: 480 seconds)
   <br> camus1 has quit IRC ()
   <br> gouchi has joined #linux-media
   ndufresne: <u>mort_</u>: msm venus driver was buggy yes (racy in many ways), hence why it failed sometimes with gst and ffmpeg, I haven't rested recently
   <br> but it should be way better
   <br> 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
   ***: ao2 has joined #linux-media
   <br> gouchi has quit IRC (Remote host closed the connection)
   <br> ao2 has quit IRC (Remote host closed the connection)
   <br> djrscally has quit IRC (Ping timeout: 480 seconds)