virtual camera on macOS?

So far the best method appears to be the CoreMediaIO DAL plugin. Unfortunately, as you mentioned, Apple products don't like plugins. Fortunately, Zoom and Microsoft (they are currently working on a Teams fix for virtual cameras for macOS), feel that plugins are still valuable in this day and age; especially when you have many people working from home remotely and who have various video sourcing needs.

The only way I have been able to feed my own video data into Apple software with SIP enabled was to configure a Raspberry Pi to look like a UVC device when plugging it into the Mac. Once you appear as a UVC device and use the macOS built-in UVC driver, you basically have the keys to the kingdom and no entitlements, notarization, or security policies block you from feeding your video data into any apps (Apple apps included). Obviously not a purely software solution however, but it indeed works. Unsure if it's possible to develop a purely software solution appear as a UVC device utilizing macOS's UVC driver. It's interesting that on the Windows platform, it is actually quite trivial to develop many types of virtual drivers that appear as physical devices to the host system. Apple seems adamantly against such an absurd concept :)

thank you. the UVC route is the last resort.

what is the rationale here for such restrictions? i can understand there can be security concerns when a piece of code has access to the camera feed (so it can snoop and do other bad things), but with the virtual camera the situation is the opposite - it *produces* video data... what are the possible use cases that constitute security threats?

the real world analogy would be to prosecute not just the thieves but their victims...

I'm not entirely sure of the rationale. I believe since the advent of hardened runtime, by default 3rd party plugins are blocked by the using app unless the app explicitly includes the "disable-library-validation" runtime. So you are still free to create a CMIO plugin, notarize and sign it, and it should work with apps with that entitlement. It was interesting to see back in March that Zoom had removed this entitlement which caused an uproar amongst many of their users since their daily work lives (especially with work from home) depended on virtual cameras. This pressured Zoom to include the entitlement to restore support for virtual cameras. Microsoft is repeating this same cycle right now with Teams.

Personally I don't understand all of the hate for CMIO DAL plugins. Their sole purpose is to provide your video data to other apps.
I don't see how a virtual driver would provide any further improvements. The driver portion should be for retrieving video data from a physical device, which would then stream up through the CMIO plugin to 3rd party apps. Even if you could make a virtual driver solution with DriverKit, good luck getting Apple's blessing with the driverkit.transport.usb entitlement (or whatever else is needed) if you aren't a hardware manufacturer.

I hope Apple is seeing the trend with Zoom and Teams for a return to the CMIO plugin and follow suit.

I don't understand all of the hate for CMIO DAL plugins.

The problem with CoreMedia DAL plug-ins is that they load within the host app’s process. In-process plug-ins represent an obvious security problem and Apple is moving away from that architecture entirely. You’ll note that all plug-in mechanisms that that we’ve introduced recently are based on app (or system) extensions, which avoids this problem. Additionally, many existing in-process plug-ins are now loaded by a system process that’s dedicated to that task (for example, third-party authorisation plug-ins are now loaded by authorizationhosthelper rather than the traditional authorizationhost).

The bugs mentioned in that other thread are all focused around the idea of providing this feature without requiring an in-process plug-in.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

The problem with CoreMedia DAL plug-ins is that they load within the host app’s process. In-process plug-ins represent an obvious security problem and Apple is moving away from that architecture entirely.

Quinn, i wonder, were these security problems not obvious back then when the CoreMedia DAL plug-ins infrastructure was designed, or was it a deliberate decision given the technology limitations of the time?

Normally we (developers and users) are happy when Apple provides a new better technology and only after that deprecate and unsupport existing bad technology. When the old technology is unsupported without a new one we are left in limbo..

Is situation with audio any different? These audio plugins are loaded into a separate process (core audio daemon) so shall be fine in regards to the mentioned security problems.. what's wrong with them? https://developer.apple.com/forums/thread/657619 and DTS TSI Follow-up: 744010100.