<!-- 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 joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> bingbu has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> darkapex2 has joined #linux-media
<br> darkapex1 has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has joined #linux-media
<br> eelstrebor has quit IRC (Ping timeout: 480 seconds)
<br> eelstrebor has joined #linux-media
<br> eelstrebor has quit IRC ()
<br> jm_h has joined #linux-media
<br> GBenji has joined #linux-media
<br> ao2 has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)
<br> wallacer has quit IRC (Read error: Connection reset by peer)
<br> hiroh has joined #linux-media
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Remote host closed the connection)
<br> hiroh has quit IRC (Remote host closed the connection)
mriesch: <u>pinchartl</u>: ndufresne: may i draw your attention to the series https://lore.kernel.org/linux-usb/20220105115527.3592860-1-m.grzeschik@pengutronix.de/ ? it is related to the implementation of the uvcsink element in gstreamer and could use a bit of review in order to enable this feature.
<br> surely you are quite busy, but the series is in v6 and has experienced only little acknowledgment so far. if you had some time to review it would be great.
pinchartl: <u>mriesch</u>: I saw v6 in my inbox indeed. 'm very busy this week and the next, I'll try to get to it after that
mriesch: <u>pinchartl</u>: that'd be great, thanks!
pinchartl: I haven't been very responsive when it comes to uvcgagdet, I'm sorry about that. it has become a spare time project unfortunately, I'd love to be able to spend more time on it, there's so many cool things that could be done
<br> uvcsink is an interesting project
<br> I also have lots of ideas for improvement of the uvcgadget userspace application, although I'm wondering if it shouldn't be deprecated to focus on uvcsink instead
<br> <u>kbingham</u>: ^^
mriesch: <u>pinchartl</u>: sure. just wanted to advertise the series a bit as linux-media has not been included explicitly
kbingham: interesting indeed, I started playing with uvc-gadget lately too, looking to integrate/incoprporate libcamera
<br> but if theres' a uvcsink, that could be a very good way of handling it as well (especially as there's alerady a libcamera gst element for instance)
<br> mriesch, please feel free to put me on cc on those patches too.
-: kbingham must get that lore/lei system set up
pinchartl: <u>kbingham</u>: b4 am 20220105115527.3592860-1-m.grzeschik@pengutronix.de
mriesch: <u>kbingham</u>: this is a use case we might look into one day (connecting libcamera and uvcsink with gstreamer)
kbingham: pinchartl, I want them in my email - not git ;-)
<br> mriesch, You already can if you have a uvcsink... gst-launch libcamerasrc ! v4l2uvcsink ;-)
mriesch: <u>kbingham</u>: yep, that'd be awesome. and this is why we need reviews on the series ;-)
pinchartl: <u>mriesch</u>: how does uvcsink handle format changes ? does it support reacting to the UVC commands sent by the host, and reconfiguring the format on the gst pipeline accordingly ?
kbingham: But I think it would be good if the uvc-gadget could interogate the system/sources to be able to expose the correct configurations on the gadget, so the host can for instance, switch streams, change resolutions ...
<br> etc etc ...
<br> I assume that would require some interaction with / or preconfiguring of the configfs
mriesch: should the linux-media list be included btw?
kbingham: they'd be in my inbox already if it was ;-)
pinchartl: I think it doesn't hurt to CC linux-media too
<br> lunch time
mriesch: <u>pinchartl</u>: yes, and this reconfiguration is what caused the most headache. i am a bit shaky on the technical details though
kbingham: mriesch, I had envisioned that 'uvc-gadget' would handle creating the configfs and map it to the UDC, but using gt, it has to be 'known in advance' what source will be used...
mriesch: <u>pinchartl</u>: long story short is (if i understand correctly) that format changes are always uvc stream off - negotiatate new uvc format - stream on) and the gstreamer pipeline follows to renegotiate. but i am really on thin ice here
<br> <u>kbingham</u>: it is very specific to determine which of the available sources should be connected for a given resolution. we envisage that there is a custom application that performs the selection.
<br> one could think of multiple v4l2 input sources with a single fixed format each, of one input source with multiple formats, or a jpeg encoder in between if mjpg is selected as uvc format
kbingham: Indeed, in fact I'm already thinking my expected app that I was building could now be built around gstreamer already ;-) But I'd probably be just making what you're already making.
mriesch: it is hard to make a general statement, so the goal is to build on top of gstreamer and provide the required tools in the kernel and gstreamer
kbingham: count me in as an interested party for sure ;-)
mriesch: <u>kbingham</u>: i'll ask michael to include you in cc
kbingham: thanks
mriesch: <u>kbingham</u>: to be precise using gt the source does not have to be known, but which formats are offered via uvc.
<br> <u>pinchartl</u>: lunch time indeed. enjoy, y'all!
***: xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
kbingham: mriesch, Yes, but I'd like the 'system' to be able to configure the UVC based on the source....
<br> I.e. from libcamera perspective - set up the UVC device to expose the capabilities of the camera, and then the host can chose configurations that are supported by the camera.
<br> so of course that means interogating the source before setting up the gadget/configfs (I assume we can't modify the configfs once it's bound to the udc)
***: dikshita has quit IRC (Quit: The Lounge - https://thelounge.chat)
ndufresne: <u>mriesch</u>: I can give a look at the GStreamer side, I was still not fan of the new properties, something I'll look deeper into, which SoC do you know works if I want to test this ?
***: camus1 has joined #linux-media
<br> camus has quit IRC (Ping timeout: 480 seconds)
<br> camus has joined #linux-media
<br> camus1 has quit IRC (Ping timeout: 480 seconds)
mriesch: <u>kbingham</u>: interesting point. so far we always assumed that the formats offered via uvc are static (whatever the product specs define) and there is e.g. one gt scheme per product.
<br> <u>ndufresne</u>: actually, these kernel changes should not be soc-specific AFAIK. even qemu-setups are possible.
kbingham: mriesch, with a libcamera source, that could be more dynamic (for me). I could for instance plug in another UVC camera into the RPi - and expect that to be forwarded across the connection. Or maybe I want to set up a source from a decoded media file - so the only config is the size of that decoded file. I guess it depends how flexible the system is allowed to be overall.
<br> I wonder if I could expose different 'input's for each camera available in the system ... including the virtual ones ...
<br> I suspect hotplugging UVC cameras at runtime when the host is already connected is ... oprobably quite out of scope ;-)
<br> mriesch, Do you have a qemu-setup for connecting the gadget of qemu to the host?
<br> I'd be interested in trying that locally.
<br> otherwise I'll just work on an RPi4 I think.
mriesch: <u>kbingham</u>: if e.g. the rpi should act as uvc gadget with a single, yet varying format the situation is pretty tricky IMHO
kbingham: mriesch, but we can expose multiple supported formats right?
mriesch: the uvc gadget can offer one or multiple formats when the descriptor is loaded, and the host is free to select one of them. but what happens if the host selects a format which is not currently available at the input?
kbingham: I wnoder in that case if we would expose each camera as a separate gadget instance.
mriesch: i think usually the host selects something and the gadget has to scale the image appropriately
<br> (or maybe encode in the case of mjpeg)
kbingham: mriesch, I'm envisioning that the 'camera' might expose multiple modes, a full resoltion and some smaller ones, and I'd expect the host to see the modes exposed by the sensor, which the gadget can just forward on.
mriesch: possible, but only if the usb/uvc descriptor is read again -> i guess the host has to select the (updated) usb configuration again
kbingham: that's why I expected the gadget application to interogate the libcamera cameras and identify the possible configurations, and set those up in the configfs before binding to the UDC ;-)
ndufresne: <u>mriesch</u>: noted, didn't thought of qemu, would take a bit of time to setup of course ...
mriesch: <u>kbingham</u>: ah ok.. well i guess in the end there has to be some top level logic that defines what the product should do. there are quite some possibilities :-)
<br> as to the qemu setup: no i am not using it myself. but i heard that it is possible :-)
***: b-rad has joined #linux-media
kilobyte_ch: Someone here maybe already played around with getting a TVIN/CVBS Signal into the Raspberry Pi (Custom HW)? I'm currently trying with a ADV7282 Video Decoder which outputs CSI2 to the Raspberry Pi. But as the Deinterlacing in the ADV7282 Chip is pretty bad and the Raspberry Pi doesn't support Hardware deinterlacing/intetrlaced CSI2 this seems not the best solution.
***: mugnierb3 is now known as mugnierb
ndufresne: <u>mriesch</u>: I've learn that what isn't tested, is most likely not working, hence why I'm asking what SoC or system you are testing on
mriesch: <u>ndufresne</u>: for all i know michael has tested it using his qemu setup and on a custom xilinx zynqmp board. personally i haven't done any testing of v6 since technically i am on vacations
ndufresne: ok, if one of you feels like documenting a bit, I can test on qemu, but also on zynqmp (got zcu 102 and 106, I bet Micheal is using 104)
<br> just like everything else, if we can produce, its a bit pointless ot upstrea, ;-P
<br> upstream
mriesch: <u>ndufresne</u>: that'd be great. let me ask michael about the qemu setup and get back to you. i think the 104 does not have a usb otg port, but we do have a 106 lying around.
***: darkapex3 has joined #linux-media
<br> darkapex2 has quit IRC (Ping timeout: 480 seconds)
<br> GBenji has left
<br> jarthur has joined #linux-media
<br> eelstrebor has joined #linux-media
<br> gouchi has joined #linux-media
<br> NiksDev has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
<br> bluzee has joined #linux-media
<br> bluzee has quit IRC ()
<br> jm_h has quit IRC (Remote host closed the connection)
<br> mugnierb1 has joined #linux-media
<br> mugnierb has quit IRC (Ping timeout: 480 seconds)
<br> mugnierb1 has quit IRC (Read error: Connection reset by peer)
<br> mugnierb1 has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
<br> gouchi has quit IRC (Remote host closed the connection)
<br> Bugies has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has quit IRC (Quit: Konversation terminated!)
<br> djrscally has joined #linux-media
<br> camus1 has joined #linux-media
<br> camus has quit IRC (Read error: Connection reset by peer)