search

eduramiba / webcam-capture-driver-native

Native driver for Webcam Capture API
26 stars 8 forks source link

Issue with non-unique camera names for multiple webcams on macOS with M1 #20

Closed s-predybailo closed 9 months ago

s-predybailo commented 9 months ago

Hello,

I am currently facing a challenge with the webcam-capture-driver-native library in my project where I have connected 3 identical webcams (Hikvision DS-U02) to my computer. These webcams are identified by non-unique names by the library. This issue prevents me from distinguishing between these cameras and working with them individually to capture video streams simultaneously.

Here is an example of how the camera names are detected by the library:

The three "1080P USB Camera" entries correspond to the Hikvision DS-U02 webcams. Their identical names make it impossible to select and use each webcam independently, which is crucial for my application.

This issue arises from the use of the library with the com.github.sarxos.webcam package, specifically when trying to lock a webcam for exclusive access (WebcamLock.class) The non-unique names cause conflicts in the locking mechanism, preventing simultaneous use of the cameras.

Suggested Feature / Fix: It would be highly beneficial if the library could provide a way to generate unique identifiers for each webcam, possibly incorporating attributes such as connection port or an internal index. This would allow applications to distinguish between multiple webcams with otherwise identical names.

Environment:

eduramiba commented 9 months ago

With this driver you can actually cast the webcam device instance to an interface that includes the unique id provided by the OS.

I think the readme has an example of the cast you need to do (I am not at the computer right now)

eduramiba commented 9 months ago

Cast it to this https://github.com/eduramiba/webcam-capture-driver-native/blob/master/src/main/java/com/github/eduramiba/webcamcapture/drivers/WebcamDeviceExtended.java for example

s-predybailo commented 9 months ago

With this driver you can actually cast the webcam device instance to an interface that includes the unique id provided by the OS.

I think the readme has an example of the cast you need to do (I am not at the computer right now)

Thank you for your quick response and suggestion to use WebcamDeviceExtended to access the unique ID provided by the OS. I understand how this could allow me to retrieve the unique identifiers for each webcam, which indeed helps in distinguishing between them at a certain level.

However, my primary challenge is related to how the webcams are managed and locked within the webcam-capture framework, specifically with the WebcamLock feature in the sarxos.webcam package. This mechanism seems to rely solely on the webcam names for identifying and locking webcams, which does not incorporate the unique IDs into its process. Given that the names of the webcams are not unique in my scenario (as they are all identified simply as "1080P USB Camera"), I'm facing difficulties in ensuring that each webcam can be locked and accessed independently for simultaneous use.

I was considering overriding the getName method to include the unique ID in the webcam name, thus ensuring uniqueness. However, I'm unsure if this is the best approach or if I misunderstood the capabilities of the WebcamDeviceExtended interface in addressing this issue.

Could you please clarify how I might leverage the unique ID to effectively work around the WebcamLock limitation? Is there a recommended way to integrate the unique ID into the webcam identification process within the webcam-capture framework, or perhaps a different approach I should consider?

Thank you for your assistance and patience.

eduramiba commented 9 months ago

That might work but I also suggest to just disable the lock mechanism of the library. Does that work for you?

El lun, 26 feb 2024 19:12, s-predybailo @.***> escribió:

With this driver you can actually cast the webcam device instance to an interface that includes the unique id provided by the OS.

I think the readme has an example of the cast you need to do (I am not at the computer right now)

Thank you for your quick response and suggestion to use WebcamDeviceExtended to access the unique ID provided by the OS. I understand how this could allow me to retrieve the unique identifiers for each webcam, which indeed helps in distinguishing between them at a certain level.

However, my primary challenge is related to how the webcams are managed and locked within the webcam-capture framework, specifically with the WebcamLock feature in the sarxos.webcam package. This mechanism seems to rely solely on the webcam names for identifying and locking webcams, which does not incorporate the unique IDs into its process. Given that the names of the webcams are not unique in my scenario (as they are all identified simply as "1080P USB Camera"), I'm facing difficulties in ensuring that each webcam can be locked and accessed independently for simultaneous use.

I was considering overriding the getName method to include the unique ID in the webcam name, thus ensuring uniqueness. However, I'm unsure if this is the best approach or if I misunderstood the capabilities of the WebcamDeviceExtended interface in addressing this issue.

Could you please clarify how I might leverage the unique ID to effectively work around the WebcamLock limitation? Is there a recommended way to integrate the unique ID into the webcam identification process within the webcam-capture framework, or perhaps a different approach I should consider?

Thank you for your assistance and patience.

— Reply to this email directly, view it on GitHub https://github.com/eduramiba/webcam-capture-driver-native/issues/20#issuecomment-1964815851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQFJLSYROTP3MRP52RLJTYVTGAPAVCNFSM6AAAAABD2PALA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUHAYTKOBVGE . You are receiving this because you commented.Message ID: @.***>

s-predybailo commented 9 months ago

I don't have the opportunity to try this right now, but I'll try different options and let you know what conclusion I've come to. Thanks! UPD: I like disabling the blocking mechanism less, since the sarxos library uses different drivers and works with them the same way (just accepts getName), so it seemed more logical to me to open the issue in the driver repository, rather than in the library

s-predybailo commented 9 months ago

I have disabled the blocking mechanism and it helps in my case. However, I am still not sure if this is a clean move or potentially unsafe. So I have made changes to the getName method.