You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If you have two or more cameras with the same product and vendor id plugged into the USB host/bus, changing the slider values after choosing a camera may instead change the value for the other camera with the same vendor/product id.
To Reproduce
Steps to reproduce the behavior:
Plug in multiple cameras with the same USB product and vendor ids2.
See them in the dropdown picker of the app
Select one
Change a slider value in the basic settings
You might see an update in the preview window, this means that the value is changed for the currently selected camera6.
Select the other camera from the drop down
Change the same setting. You might not see any change in the preview window, but if you look back at the other camera, you will see that it has changed instead
Expected behavior
Changing the slider values for a selected camera should update the values for that camera (and not another one)
Desktop (please complete the following information):
Version 1.3.1
Camera: n/a .. just as long as multiple have the same product/vendor id
Additional context
the usbDevice() extension method on AVCaptureDevice doesn't use enough information to disambiguate the interfaceRef returned by the dictionary passed into IOServiceGetMatchingService (in AVCaptureDevice+USB.swift), so the usb interface that is returned for each different AVCaptureDevice is actually pointing at the same end device (which causes settings changes in the UI to be routed to the same end camera).
I am actively looking into a solution for this issue by using more keys in the lookup dictionary for IOServiceGetMatchingService
The text was updated successfully, but these errors were encountered:
Fix issue where `AVCaptureDevice.usbDevice()` would return a USBDevice
pointing to the wrong camera if multiple cameras with the same product
id and vendor id are attached to the computer.
The new approach is to use an iterator to lookup the cameras with the
given vendor and product ids, and then loop through the results and
match against their property dictionaries against the
avDevice.localizedName since that seems to be the only reliable way to
disambiguate between different cameras with otherwise similar
properties.
jazzychad
added a commit
to jazzychad/CameraController
that referenced
this issue
May 4, 2022
Fix issue where `AVCaptureDevice.usbDevice()` would return a USBDevice
pointing to the wrong camera if multiple cameras with the same product
id and vendor id are attached to the computer.
The new approach is to use an iterator to lookup the cameras with the
given vendor and product ids, and then loop through the results and
match against their property dictionaries against the
avDevice.localizedName since that seems to be the only reliable way to
disambiguate between different cameras with otherwise similar
properties.
Describe the bug
If you have two or more cameras with the same product and vendor id plugged into the USB host/bus, changing the slider values after choosing a camera may instead change the value for the other camera with the same vendor/product id.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Changing the slider values for a selected camera should update the values for that camera (and not another one)
Desktop (please complete the following information):
Additional context
the
usbDevice()
extension method onAVCaptureDevice
doesn't use enough information to disambiguate theinterfaceRef
returned by the dictionary passed intoIOServiceGetMatchingService
(in AVCaptureDevice+USB.swift), so the usb interface that is returned for each different AVCaptureDevice is actually pointing at the same end device (which causes settings changes in the UI to be routed to the same end camera).I am actively looking into a solution for this issue by using more keys in the lookup dictionary for
IOServiceGetMatchingService
The text was updated successfully, but these errors were encountered: