[01:35] *** BrianG61UK has joined #linux-media
[01:40] *** BrianG61UK_ has joined #linux-media
[01:50] *** camus1 has quit IRC (Remote host closed the connection)
[01:51] *** camus has joined #linux-media
[03:03] *** eelstrebor has quit IRC (Quit: Ex-Chat)
[05:50] *** jm_h has joined #linux-media
[06:34] *** NiksDev has quit IRC (Ping timeout: 480 seconds)
[06:34] *** NiksDev has joined #linux-media
[06:59] *** wwilly has joined #linux-media
[07:14] *** camus has quit IRC (Read error: Connection reset by peer)
[07:14] *** camus has joined #linux-media
[07:34] *** GBenji has joined #linux-media
[08:00] *** svarbanov has joined #linux-media
[08:01] *** ao2 has joined #linux-media
[08:17] *** camus has quit IRC (Read error: Connection reset by peer)
[08:33] *** camus has joined #linux-media
[08:40] <Lightsword> how is one supposed to autotune v4l2 uvc camera settings?
[08:43] <kbingham> Lightsword, what autotuning are you expecting to occur?
[08:43] <Lightsword> kbingham brightness and stuff
[08:43] <kbingham> Lightsword, Does your UVC camera not give you good results by default?
[08:44] <Lightsword> nope
[08:44] <Lightsword> way too dark
[08:44] <kbingham> The brightness and exposure are usually expected to be operated by the camera itself.
[08:44] <kbingham> You can manually control the settings by using the v4l2 controls on the UVC device.
[08:44] <kbingham> But it won't be 'autotuned', it will be 'manually' tuned (by you)
[08:44] *** camus has quit IRC ()
[08:45] *** camus has joined #linux-media
[08:45] <Lightsword> yeah...trying to figure out how to do this automatically...since there are hundreds of cameras...
[08:45] <kbingham> Lightsword, I think a bit more context of what  you are trying to do might help. 
[08:45] <kbingham> Do you have hundreds of cameras to configure?
[08:45] <kbingham> or are you refering to the fact hat there are hundreds of different types of UVC camera?
[08:45] <Lightsword> yeah, security cameras for ATMs/kiosks
[08:46] <Lightsword> there's a few different models...but they will be in different locations
[08:46] <kbingham> Lightsword, So normally, you would rely on the camera itself to handle the brightness, exposure and contrast.
[08:46] <Lightsword> defaults seem pretty bad for all the models we've been using
[08:47] <kbingham> Lightsword, The ... first question would be, can you cahnge the model you intend to use?
[08:47] <kbingham> Or is it already fixed in hardware?
[08:47] <Lightsword> some are fixed...some are not
[08:47] <Lightsword> we can change in future production batches
[08:47] <Lightsword> but have to support existing deployments indefinitely
[08:49] <kbingham> Lightsword, You have quite a complex requirement then. I presume given the context that these machines are going to be in environments with changing lighting, so you can not 'tune once' and fix the brightness/exposures to a given value, becuase it won't adapt to work at night, or day or dusk ...
[08:49] <kbingham> unless you expect to have full control over the lighting of the subject.
[08:49] <Lightsword> correct
[08:49] <Lightsword> yeah, many different environments
[08:49] <Lightsword> so not feasible to control manually
[08:50] <kbingham> Lightsword, So you would like to implement a mechanism to replace the 3a algorithms, (well, the whitebalance might be sufficient on the device) to 'automatically-on-the-host' control the brightness (exposure, and gains)
[08:50] <paulk> Lightsword: then you probably need some ISP to do 3A
[08:51] *** camus1 has joined #linux-media
[08:52] <Lightsword> what are 3a algos?
[08:52] *** camus has quit IRC (Read error: Connection reset by peer)
[08:52] <kbingham> 3a means "Auto-whitebalance, Auto-exposure/gain, Auto-focus"
[08:52] <kbingham> Those are the algorithms which are running on your UVC devices, and you are stating that they are not suitable for your needs.
[08:52] <paulk> probably you mostly want auto-exposure/gain
[08:53] <kbingham> You should probably also contact your UVC camera vendor to determine /why/ the devices you ahve are not functioning the way you expect.
[08:54] <kbingham> But to replace those algorithms, UVC can set the controls manually, and you would have to impleement your own algorithms on the host. To do that, you need to process every image, and decide what the 'next best' setting should be, that's usually where an ISP comes in to help with the image processing, but  you also need the algorithm implementation on top.
[08:55] <kbingham> That's quite a big task though
[08:55] <Lightsword> is there not some tool that already is designed to handle that?
[08:55] <kbingham> Lightsword, Yes, your UVC camera ;-)
[08:55] <Lightsword> I mean software tool I guess
[08:56] <kbingham> So ... I could imagine somethign could be developed on top of libcamera ...
[08:56] <kbingham> But it's not something that has been developed already for this use case...
[08:56] <Lightsword> oh, what's the proper way to reset all camera settings to the defaults btw?
[08:57] <kbingham> Lightsword, I think v4l2-ctl has an option to reset to defaults.
[08:57] <kbingham> Lightsword, Have you checked that your UVC cameras are correctly enabled to run auto-exposure, auto-gain etc themselves?
[08:57] <kbingham> Or have they been 'fixed' to a specific value by some other setting?
[08:58] <Lightsword> well I was messing with settings but it's very difficult to do manually
[08:58] *** djrscally has joined #linux-media
[08:58] <kbingham> Lightsword, qv4l2 is a good app for playing with the settings
[08:58] <Lightsword> I haven't been able to figure out which v4l2-ctl sets defaults
[08:59] <Lightsword> I only have remote command line access to a lot of these systems.
[09:10] <kbingham> Lightsword, Hrm, it looks like I used "yavta --no-query --reset-controls" in the past rather than v4l2-ctl.
[09:10] <Lightsword> https://github.com/manfer33/v4l2-default-controls seemed to work with v4l2-ctl I think
[09:11] <kbingham> I suspect it could be a good feature for you to add to v4l2-ctl if you like 
[09:12] <kbingham> Otherwise, it would do the same as the shell script I expect.
[09:12] <Lightsword> kbingham, yeah, I noticed a lot of v4l2 related tools seem to be missing random features
[09:12] <kbingham> Lightsword, Why are they missing 'random' features?
[09:12] <kbingham> Lightsword, Features are only added when they have a requirement.
[09:12] <Lightsword> kbingham, well like the default flag :P
[09:12] <Lightsword> idk, just stuff like that which you would expect to be around I guess
[09:13] <Lightsword> kbingham, so does libcamera already have anything for uvc tuning?
[09:13] <kbingham> Lightsword, No, not for UVC tuning, that's why I said it is not something that is currently developed,
[09:14] <kbingham> We have algorithms for IPU3, and Raspberry Pi.
[09:14] <kbingham> But algorithsm are usually quite specific to the ISP involved.
[09:14] <kbingham> We had an intern working on a software-isp based on the GPU, so in the 'future' I could imagine that it could process images from a UVC camera as well as a raw bayer sensor.
[09:15] <kbingham> But ... that's very much a corner case that would not be developed without a real usecase/requirement.
[09:15] <kbingham> As ... most peopel would expect their UVC camera algorithms to be functional.
[09:15] <kbingham> What you are asking to do is override functionalty on your UVC devices, and re-implement that functionality on the host
[09:16] <pinchartl> kbingham: sounds like a rabbit hole big enough for a few cows
[09:16] <Lightsword> does windows do stuff like that?
[09:16] <kbingham> You might need 3 years of R+D to perfect your algorithms for all of your use-cases
[09:16] <pinchartl> Lightsword: no it doesn't
[09:16] <pinchartl> UVC devices are supposed to be used in auto mode
[09:16] <pinchartl> and if they don't provide good results, that's the fault of the device
[09:16] <kbingham> ^
[09:17] <pinchartl> it doesn't mean they're all good
[09:17] <kbingham> Precisely, which is why I have already suggested contacting your UVC device provider (or changing your UVC devices)
[09:17] <pinchartl> the webcam integrated in my laptop is a UVC camera
[09:17] <pinchartl> and it doesn't handle scenes with backlight properly
[09:20] <kbingham> pinchartl, And you do give your UVC camera a hard time with your backlight ;-)
[09:20] <Lightsword> kbingham, for new manufacturing...the vendors available don't seem to be very responsive...random chinese vendors...we've been playing around with different models
[09:20] <Lightsword> kind of just trial end error though
[09:21] <pinchartl> UVC is usually a low-cost market, so they're indeed not very responsive
[09:21] <Lightsword> but we have a lot of existing hardware we're replacing software for as well that we need to get somewhat functional
[09:24] <Lightsword> yeah...took a while to even find one with h264 encoding capability since we want to be able to do somewhat efficient security camera streams with them
[09:32] <Lightsword> apparently...the brightness tuning issue I'm seeing does not reproduce on windows...I must be missing something here...
[10:08] <kbingham> Lightsword, How are you capturing and processing the images from the camera?
[10:08] <Lightsword> fswebcam -r 1920x1080 -d /dev/video0 output.jpg --verbose
[10:09] <kbingham> Lightsword, Is that capturing the 'first' image, that it can get?
[10:09] <kbingham> Or does it let the camera run for a second so that the algorithms can settle.
[10:09] <Lightsword> um...not sure
[10:09] <kbingham> try adding --skip 30
[10:10] <kbingham> or according to http://manpages.ubuntu.com/manpages/bionic/man1/fswebcam.1.html  --delay might be something to experiment with too.
[10:11] <Lightsword> oh...that fixed the issue
[10:12] <kbingham> There we go ;)
[10:13] <kbingham> So - the algorithms are working on your cameras, but you need to give them some time to run.
[10:14] <paulk> it's actually quite common to discard the first few frames for this reason
[10:14] <paulk> especially when taking stills
[10:14] <Lightsword> yeah...I wonder why fswebcam doesn't wait for it to stabilize by default
[10:14] <paulk> because the number of frames is highly hardware specific 
[10:14] <kbingham> Lightsword, It doesn't know how long it needs to stabilise.
[10:15] <paulk> and fswebcam doesn't know what is a "good frame"
[10:15] <Lightsword> can't it like...diff the frames to determine if it stabilized or something?
[10:16] <paulk> that might be a way (there could be cons depending on the environment too)
[10:16] <kbingham> wouldn't work with a moving scene though ;-)
[10:17] <kbingham> The camera would know if the algorithms have converged, but I do'nt think they report that information.
[10:17] <paulk> a more viable option would be to look at the histogram
[10:17] <paulk> but generally speaking this gets close to how auto-exposure is implemented I guess
[10:21] <Lightsword> ah
[10:24] <Lightsword> btw what's the best way to send a video stream from a camera to multiple applications? say for a RTSP server at the same time as something like zbarcam?
[10:55] <pinchartl> Lightsword: pipewire is the way to share a video stream from a device between multiple applications
[11:01] <Lightsword> pinchartl, oh, so applications expecting to read from a v4l2 uvc camera can attach to pipewire somehow? is there a good example of how to set this sort of thing up?
[11:01] *** Ampera has quit IRC (Quit: Like a fart in an elevator, my transgressions are soon forgotten)
[11:02] *** Ampera has joined #linux-media
[11:02] <pinchartl> the applications will have to be ported to pipewire I suppose. I haven't had a chance to look at it yet
[11:03] <Lightsword> I've currently been using https://github.com/umlaeute/v4l2loopback but it's...less than ideal.
[11:33] <dv_> if I use the mem2mem decoder API, can I get informed about the sample rate when using a stateful decoder?
[11:34] <dv_> IIRC, the frame rate can be stored in some bitstreams
[11:49] <hverkuil> dafna2[m]: ping
[12:23] *** johancb has joined #linux-media
[14:00] <ndufresne> Lightsword: secucirty cams should be kept streaming at all time, and then you no longer have to consider rampup to pick a still
[14:01] <ndufresne> and then have a static configuration for the inital startup, or when you suspend/resume it (for battery driven cams)
[14:01] <ndufresne> that config will be per model
[14:17] <dv_> oh, and does anybody know if the hantro drivers finally landed in the stable kernel?
[14:18] <dv_> the adaptation for imx8m SoCs I mean
[14:21] <dafna2[m]> hverkuil: pong
[14:22] <hverkuil> dv_: yes , that's merged.
[14:22] <hverkuil> dafna2[m]: https://patchwork.linuxtv.org/bundle/hverkuil/b5/?series=6047
[14:23] <hverkuil> What is the status of that series? 1-3 seem OK, but there were comments for the last two patches.
[14:23] <dafna2[m]> the link shows nothing
[14:23] <hverkuil> Sorry, wrong link. This is the correct one: https://patchwork.linuxtv.org/user/todo/linux-media/?series=6047
[14:24] <dv_> hmm needs a login
[14:25] <dv_> but is it now part of 5.14?
[14:26] <dafna2[m]> indeed, it asked me to login
[14:26] <hverkuil> dv_: yes (drivers/staging/media/hantro/imx8m_vpu_hw.c)
[14:26] <hverkuil> dafna2[m]: the first or the second link?
[14:26] <pinchartl> https://patchwork.linuxtv.org/project/linux-media/list/?series=6047
[14:27] <dv_> hverkuil: second link
[14:27] <hverkuil> Yes, this third link is the really correct one. Not sure how patchwork generated the second link, weird.
[14:28] <dv_> "media: mtk-vcodec: venc: variouse bug fixes" ?
[14:28] <hverkuil> y
[14:28] <dv_> so ... this is the hantro encoder
[14:28] <dv_> the hantro decoder is also included?
[14:29] <dv_> ah wait - I can just look at github.com/torvalds/linux :)
[14:29] <hverkuil> dv_: Huh? That series has nothing to do with your question. It's an unrelated discussion with dafna2[m]
[14:29] <dv_> hverkuil: oh ok, my bad
[14:35] <dafna2[m]> I can either send another version to address the comments of last two patches
[14:38] <hverkuil> dafna2[m]: Yes, that would be good. I'll just change the status of the series to 'Changes Requested' in patchwork.
[14:38] <dafna2[m]> ok
[14:39] *** eelstrebor has joined #linux-media
[14:45] *** johancb has quit IRC (Quit: Konversation terminated!)
[15:31] *** BrianG61UK has quit IRC (Read error: Connection reset by peer)
[16:21] *** camus has joined #linux-media
[16:24] *** camus1 has quit IRC (Ping timeout: 480 seconds)
[16:33] *** GBenji has quit IRC (Quit: Leaving.)
[16:43] <ezequielg> dv_: imx8mq g1 support is in mainline and support mpeg2, vp8 and h264 decoding. gstreamer support is merged too, but we don't have a release date for it.
[17:28] *** BrianG61UK has joined #linux-media
[17:30] *** Moarc has joined #linux-media
[17:30] <Moarc> hi!
[17:31] <Moarc> what utilities can I utilize for capturing analog video from an input card?
[17:31] <Moarc> I recently got a saa7134-based card, and it works great with tvtime, but I couldn't find anything decent for recording the input
[18:13] <b-rad> vlc? ffmpeg?
[18:21] <Moarc> what bugs me is that all the tools say the card provides 25 FPS
[18:21] <Moarc> and it's supposed to capture each field of an interlaced signal
[19:30] <Svenska> Hi. pinchartl: You said UVC devices are supposed to be used in auto mode. How wide-spread is support for other modes (in software using UVC)?
[20:04] <Svenska> Just wondering if implementing decent UVC support is worth doing or if most applications will just ignore it.
[20:26] *** gouchi has joined #linux-media
[20:43] *** jm_h has quit IRC (Remote host closed the connection)
[21:01] *** ao2 has quit IRC (Quit: Leaving)
[21:39] *** dwlsalmeida has quit IRC (Quit: Ping timeout (120 seconds))
[21:39] *** eballetbo has quit IRC (Quit: Ping timeout (120 seconds))
[21:39] *** ndufresne has quit IRC (Quit: Ping timeout (120 seconds))
[21:45] *** ndufresne has joined #linux-media
[21:46] *** ndufresne is now known as Guest6009
[21:46] *** dwlsalmeida has joined #linux-media
[21:46] *** eballetbo has joined #linux-media
[21:57] <mmind00> hverkuil: for my confused mind and the not understanding how the media-process works, do you have an idea why my px30-support for the rkisp was not included in Mauro's pull request? These patches are sitting the media_stage tree since 2021-08-05 which I guess should've been early enough?
[22:19] <djrscally> I know this is a weird question but; any one know how to get an FPS counter on the Windows camera program?
[22:19] <djrscally> Or a Windows camera program*
[22:21] <pinchartl> I don't know how to get a windows camera program :-)
[22:30] *** gouchi has quit IRC (Remote host closed the connection)
[22:31] <djrscally> Recent experience suggests step one probably involves some sort of Azure subscription
[22:33] <pinchartl> -_-'
[22:34] <pinchartl> I haven't used windows for so long, if I had to get back to it, I wouldn't recognize it. the UI changes wouldn't be an issue, but everything that goes around it and that tightens microsoft's control on the device or the market space...
[22:35] <djrscally> Using both it's actually really noticeable the shortcomings
[22:36] <djrscally> Like to get to talk to the sensor with i2ctransfer equivalent you have to patch ACPI with a dummy device for some microsoft published driver to bind to, that forwards the i2c messages to the chip
[22:36] <djrscally> It's pretty blah
[22:36] <djrscally> I mean day to day it's fine but doing anything more complicated is annoynig
[22:41] <Svenska> in the past, people used fraps for fps counting...
[22:41] <Svenska> don't know if it's acceptable for what you want to use it for
[22:52] <djrscally> Thanks; in the end I found an alternative method :)
[22:56] <pinchartl> out of curiosity, how did you do it ?
[23:02] <djrscally> Realised I didn't need a counter, I just needed a change big enough to be noticeable
[23:03] <djrscally> I was toying with the HTS / VTS values on the Go2 running linux; still trying to figure out what's going on with the weird output size X > HTS value thing
[23:08] <pinchartl> ah yes, that's an annoying one
[23:10] <djrscally> Yep definitely weird. HTS behaves as you'd expect. VTS resets back to whatever value the mode sets a frame or two after you change it so sorta hard to see any impact. Presumably whatever the windows equivalent of libcamera is is controlling it
[23:12] <pinchartl> yes that's a possibility
[23:12] <pinchartl> you can check in Linux to see if it causes a change
[23:13] *** b-rad has quit IRC (Ping timeout: 480 seconds)
[23:18] <djrscally> Yeah - I'll give it a go in the morning. Bedtime for now - goodnight!
[23:23] <pinchartl> hyvää yötä
[23:29] *** djrscally has quit IRC (Ping timeout: 480 seconds)
[23:46] *** b-rad has joined #linux-media