Detect virtual cameras

[mprib]

The module DetectPossibleCameras was revised to implement the method I'd been using with calicam. One note here is that this did now work when directly connecting via DSHOW on windows, so I revised the capture object to connect using the default cv2.CAP_ANY.

For some reason, when the capture is connected to in this way (ANY), the capture does not need to have the resolution set exactly in order to change it. It will find the closest available resolution that it can, and this behavior is the critical part of it.

Virtual cameras that I've seen only present with one available resolution, and this can be used to identify them.

I've successfully tested this out on my windows machine while running OBS. I had hoped to test on my beater linux laptop, but have been having issues getting an environment up and running on it so decided to stop wasting time on that and push this out. Happy to discuss any questions or problems getting this working on your end.

[mprib]

I wanted to add:

• The FoundCameraCache now includes a dictionary of possible resolutions

  • On one brand of cameras that I have there is a very low resolution option that OpenCV appears to show as viable but it is not in reality

• if this method appears to work well on your end, then I can do an additional PR to do the camera detection as seperate threads for each possible camera_id, which should speed things up and won't take much longer (if at all) as the number of cameras grows.

[mprib]

The threaded implementation has been merged in now. The non-threaded solution for 3 cameras took an average of 14 seconds to complete and the threaded solution took 6.5 seconds. Apologies for the confusion with the multiple merges...I wasn't sure how to make this two discrete steps with github.

On to GUI stuff....

[jonmatthis]

The non-threaded solution for 3 cameras took an average of 14 seconds to complete and the threaded solution took 6.5 seconds.

Oh yeah, that's a huge speed up! Definitely worth it

[jonmatthis]

. Apologies for the confusion with the multiple merges...I wasn't sure how to make this two discrete steps with github.

You did this correctly!

A pull-request is a "request to merge your branch on to my branch" - When I request changes, you just keep adding new commits to that branch (like you did) and when its ready we merge the branches

If we wanted to put the changes into two discrete steps (e.g. if it had wound up being more work than expected), we could have just merged the branch as-is, and then you could submit a new PR with the new changes

[jonmatthis]

Could you please allow me to make edits? I want to make a few stylistic changes and it'd be easier to do that myself vs requesting you to do it :)

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork#enabling-repository-maintainer-permissions-on-existing-pull-requests

[mprib]

Sounds good. Hopefully should be editable now:

[jonmatthis]

Oh shoot, I didn't mean to push those commits to your branch 😅

[jonmatthis]

Looks good! I made a few changes to your variable names and added _ to the front of your private methods (i.e. the ones that aren't meant to be accessed from the outside)

Happy to merge it in now, thanks for the work on this!!

[mprib]

Awesome! My first accepted PR!