Hacker News Reader

Comment by diroussel | Hacker News Reader

This should work in Zoom, as in the latest release of Zoom 5 they have re-enabled virtual webcam support.

The Zoom release notes are a bit misleading. They didn't enable all virtual cameras, but instead a very specific list of virtual cameras. Here's how you can see that list

strings /Applications/zoom.us.app/Contents/Frameworks/nydus.framework/Versions/A/nydus | grep "Developer ID Application"

A number of folks have reached out to Zoom support to request that my plugin be added. See the latest in https://github.com/johnboiles/obs-mac-virtualcam/issues/4 for details.

I wouldn't fault Zoom for being restrictive about what they include in their allow list, since every addition adds risk, but it looks like they've already included closed-source applications from individuals as of 5.0.5. At least my code is open source and auditable!

Doing that grep interestingly includes "Developer ID Application: NewTek, Inc. (W8U66ET244)", which may match the other comment thread[1] talking about NewTek's NDI Virtual Input (note: the top comment there mistyped "NewTek" as "MediaTek"). So using the NDI solution may work with Zoom without editing entitlements.

[1] https://news.ycombinator.com/item?id=23406438

I'm unfortunately not seeing it in Zoom, even after reinstalling zoom.

I see "OBS Virtual Camera" in the source list of Video Capture Device, so I know it's running.

I do see Snap Cam (from SnapChat) listed in Zoom, so it doesn't seem to be a global virtual webcam block.

Why can zoom block a virtual camera? Couldn’t the virtual camera just pretend to be like any other real camera?

Because an app can disable loading libraries/plugins signed with a different developer id certificate, and it seems Core Media IO wants to load the plugin in the actually app process, and it doesn't use an helper process.

It's seemingly a MacOS Code Signing limitation.

https://github.com/johnboiles/obs-mac-virtualcam/issues/4

optional restriction, not limitation.

The limitation is that CoreMediaIO plugins still run in-process (and not just in some daemon but in arbitrary application processes!), when Apple's direction for over a decade has been to move all plugin mechanisms towards an out-of-process model. There's nothing about video plugins in particular that would prevent them from being out-of-process; in fact, most of Apple's CoreMediaIO plugins already have the bulk of the logic in a separate "assistant" process, but the IPC layer is reimplemented by each individual plugin rather than being done generically by CoreMediaIO itself. It's clear what has to happen, but Apple hasn't done it yet.

This is the downside of a walled garden and locked down devices. Of course many will say its for security and its wonderful but how much freedom are you willing to give up for security?

Reply on news.ycombinator.com