The suggestion I've made to the team is to provide an accessor for the IOKit object, which would then let you use whatever criteria you wanted to invent. Unfortunately, the real difficulty here is scheduling and prioritization, not necessarily the API work itself. Sounds like a good solution, I hope to see it implemented one day. The Elgato 4K X enumerates differently depending on the bus speed it is enumerated at. Its PID is different on USB 2, USB 3 Gen 1 (5Gbps) and USB 3 Gen 2 (10Gbps). I see, that would make perfect sense, I'll try and replicate the issue and check the negotiated speed. I'm using 3 Anker USB 3.2 Gen 2x2 cables, but maybe one of the three is faulty. This won't fix your original problem, but why do you care? You can synthesize your own persistent device identifiers. Undoubtedly, it would be convenient to have a uniqueID which is persistent and stable across topology changes, but you can create your own property and tack it onto your abstraction. You're right. However, it's troublesome to convince maintainers of other applications like FFmpeg & OBS to accept a PR/fix. If there was an ID provided by AVCaptureDevice that persisted with reboots it requires little justification.

That's literally the "Product ID", so having it change directly implies that something is an entirely "different" device. Yeah, I thought I may just be seeing things that aren't there, or that maybe I somehow modified the character while taking notes. But there more I thought about it the less likely it seemed possible that I could've modified a character in the middle of the terminal output while copying and pasting the text. After enough testing I was able to replicate it multiple times, the PID is definitely changing on some of these capture cards between reboots. It's possible that a driver (KEXT/DEXT) is modifying the PID at load. There's no Kernel Extension involved here though, right? I don't even have that capability enabled on the machine in question via recovery mode, unless I'm misunderstanding what you're saying and we're referring to totally different mechanisms. UVC devices are "driverless", right? Nevertheless, uniqueID does seem like a difficult issue to solve given the context. I'm aware that serial isn't always reliable depending on the situation... but I bet it would work 90%+ of the time (much like UID). I submitted a PR on the FFmpeg repository, which is now merged into Master, that allows users to select video/audio capture devices by UID or serial. Previously you could only select them by name & index which had many issues. For the grand majority of users UID should be stable. If you're in a situation where USB bus number is changing (physically changing USB ports or Thunderbolt race conditions) serial is likely to be stable. If you're in a situation where you have multiple cheap UVC devices that share a serial number, and bus location is shifting... you'd have to fall back to using UID and verifying it after each boot. I suppose you could automate start up of Thunderbolt hubs/docks with smart plugs to guarantee the startup order, but I digress. I imagine the user base who falls into the category where both UID & serial is unreliable is likely to be exceedingly small. Would there be any possibility of adding an alternativeID? Or something along those lines.