webcamoid/akvcam

Example akvcam configuration file

Closed this issue ยท 12 comments

The example akvcam configuration file (https://github.com/webcamoid/akvcam/blob/master/share/config_example.ini) is not very capable, the one generated by webcamoid 8.5.0 (the one that's in my repository) supports way more format. So I think example config_example.ini should be replaced by the one that's generated by webcamoid.

The file is working fine, the file is not supposed to be fully configured with all possible options because the user will get lost with the options and will not understand what are the most basic lines required to work. Webcamoid instead just throw every option possible at it, and good luck if you can read it ๐Ÿ˜†

I literally have the config file generated by Webcamoid, in case the users want to use my akvcam without installing webcamoid. ๐Ÿ˜‘

But you are right, it is quite hard to read... ๐Ÿ˜‚

I literally have the config file generated by Webcamoid, in case the users want to use my akvcam without installing webcamoid. ๐Ÿ˜‘

And they can, but putting one of those as an example is not a good idea.

Well, I for one, don't understand why these modes are not enabled by default. Is there a downside for enabling those extra modes?

Yes, if you enable rw, it will disable the camera controls, flipping, scaling etc in output, and brightness, contrast, etc in the capture.

But what if you don't enable the rw? Why not enable all those other output modes by default?

And they are, Webcamoid only enables mmap and usrptr in both sides, because I need the controls in both side, later you can add rw to the output if you need it, or a lot much better, just add support for mmap and usrptr in the program sending the frames.

Sorry, I meant why doesn't the capture device support all sorts of output format out of box. The documentation (https://github.com/webcamoid/akvcam/wiki/Configure-the-cameras) seems to suggest that I have to manually add all those output formats to the capture device's config, before I can use them.

What if in the future I add support for more formats? then the client will need to iterate every format * resolution * fps combination. For me it's ok as it is, just declare the formats you need and that is, I prefer flexibility and let the user decide what he wants.

Oh okay, I just want to check my understanding. If you add more formats into the webcam, then when you ask the webcam which format it supports, it will end up iterating everything, is that right? To avoid this situation, you prefer the users to set which format the webcam should support, right?

Correct, and I've tried in the past and it can really slow down client's GUI since you are basically running a O(n^3) algorithm, maybe not that much but it does.

Ah ok, closing the issue. :)