As noted in the issue (and creator of both cc'ed). There are third party solutions currently for some platforms.
https://github.com/CatxFish/obs-virtual-cam for windows
https://github.com/CatxFish/obs-v4l2sink for linux
Im not currently aware of a workable solution for mac.

Both of these require drivers though it appears the windows version comes with drivers. I assume the bounty is for both the OBS output and the virtual drivers to be managed by OBS, but you should probably specify.

I think offering a bounty for this is fine, but this would probably be better suited as an RFC with a bounty attached to it, rather than an issue post. Our RFC process is still in very early stages, and it is not well documented, but you can follow the examples here: https://github.com/obsproject/rfcs/pulls

I will spend some time tonight to get the very high-level basic process listed, as I think this would be better suited for discussion/documentation as an RFC. EDIT: I was able to get the very high level process, and a simple template added. I would still look to the PRs for guidance on how/what to write in your RFC for now until we iron out the details.

Setting up an official bounty program for OBS is something I plan to work on over the next couple weeks. Good to know there are people out there willing to help out with funding them!

To expand more on what Fenrir said regarding RFCs:

The most important thing to understand about bounties is that they shouldn't be considered complete until they are merged into the OBS master branch, but the only way that is going to happen is if the pull request (when it happens) is considered mergeable. What we don't want to happen is for someone to come along and do a bunch of work on a bounty, submit a PR, and have it denied due to egregious design issues. Thus, the only way I think we as OBS would be comfortable offering a bounty is if we have set concrete requirements for the PR ahead of time. That concrete set of requirements is defined and ironed out in the RFC process. An RFC is essentially a draft spec for a feature that people can discuss ahead of time. Once a spec is considered complete, it should be treated as essentially a design document for the feature. The feature should be programmed according to the new spec, and only PRs that follow the spec will be accepted. This is intended to increase the likelihood that a PR will be mergeable and increase the likelihood that the developer will be successfully paid the bounty.

I love that Tobi is willing to offer up some funds for this feature! Just keep in mind that the OBS team (especially Jim) is ultimately the arbiter of what will make it into the repo.

Regarding camera output, we've internally discussed the possibility of making this a core OBS feature in the past, but haven't put much energy into it yet. I would be happy to see an RFC for this, even if it's as simple as going over @CatxFish's plugins and see what needs to change in them in order to make them mergeable.

@tobi : I think this is a great idea.

Could you please describe the User Story once more, in clear sentences describing what is the issue, what is the user experience when this is not available on your platform, what pain point will this solve. (Focus on why, not how). When I read your post, I was not immediately understanding when you/a user group needs this, and for whom is this a problem.

@tobi As @kkartaltepe has already noted there is already some workarounds for windows and linux platforms. Wouldn't it make sense to just create a plugin for OSX first ? Then try to get this as part of the mainstream OBS builld ?

@dodgepong Where is this RFC process documented or is this something that is still not defined yet ?

My Mac solution looks like this. You need OBS Studio and CamTwist and an external monitor. CamTwist will provide the virtual camera. Put OBS in fullscreen on 1. monitor. Use in CamTwist Desktop as source an select your 1. monitor. Add a zoom effect to hide the menu bar. Start your Meet/Skype/Zoom meeting and use the CamTwist camera.

@totallyunknown that really is cumbersome. Definitively need a better solution.\

Definitively. I used this just once for teasing my co-workers with a custom background (chroma keying).

@lsamayoa The documentation for the RFC process needs improvement (which is also something I want to work on), but as @Fenrirthviti said, you basically just open a PR to the obsproject/rfcs repository containing the text of the RFC. I recommend following the format of this RFC PR: obsproject/rfcs#1

@dodgepong thank you for the details. Of course nothing should be done without Jim signing off on it.

Again this isn't really about me. I'm technical enough to setup whatever. The motivator was that since my townhall to 6k people last week, I've been fielding a ton of questions about my setup. I've been trying to help people get this setup but going through CamTwist, VLC loopbacks, and plugin installation but its really really difficult for most. So this bounty is really about removing this friction and getting a consistent cross platform story going. I could see the core feature set of OBS to be behind these three buttons: Start Streaming ✅ , Start Recording ✅ , Start Virtual Webcam ❎ .

It's a changed world out there right now and OBS can play a much bigger role in work communications. That's what motivated me to post this. Yes it's already possible, but only for a tiny percent of a basis point of working population.

BTW, my support isn't conditional on this feature but on top. I'm happy to donate directly to the project outside of this proposal. I love supporting open source and OBS is incredible.

Why don’t you just ask for an RTSP input module for ingesting an RTSP feed? Would be a lot more universal.

Heh, you've somehow managed to poke at two of the biggest looming projects/issues with OBS in a single post.

I've been trying to help people get this setup but going through CamTwist, VLC loopbacks, and plugin installation but its really really difficult for most.

Plugin installation is a big problem. OBS needs a plugin manager/browser to make the process of finding, installing, updating, and uninstalling plugins easier. That could be one solution to this issue, because if the virtualcam plugins were listed in a plugin library somewhere, and were installable with one click from inside OBS itself, then it would eliminate a big hurdle.

I could see the core feature set of OBS to be behind these three buttons: Start Streaming ✅ , Start Recording ✅ , Start Virtual Webcam ❎ .

At the risk of discussing this here instead of on an RFC: I'm not sure that I like this, as it is ultimately related to a larger UI design issue with OBS regarding how we handle multiple outputs, and multiple types of outputs. The current OBS UI is currently hard-coded for a single livestream output and a single recording output, but then we also have replay buffer and Decklink outputs too. Replay buffer has its own button, but Decklink is in the Tools menu. Then there are plugins like virtualcam and NDI that also add outputs, also in the Tools menu. Should each of these have their own button on the main menu? What about when we finally add UI support for multiple stream outputs, so people can stream to several destinations? What if we want to allow people to record different scenes/sources individually, as in ISO recording? Honestly, that whole main menu needs to be replaced with something that is both more comprehensive yet still easy to understand.

You can see why there needs to be a lot of design discussion around this. If the goal is expediency, then maybe an additional button to the existing menu would be acceptable, but seeing another band-aid solution here feels a bit painful.

If the goal is expediency, then maybe an additional button to the existing menu would be acceptable, but seeing another band-aid solution here feels a bit painful.

If the goal is expediency (considering the current situation with covid19), it might be best to temporarily create a forked version that is specifically tailored to WFH use, with stuff like RTMP streaming ripped out and a simplified UI.

That would be more work than shipping a build of OBS bundled with Catxfish's plugin(s).

I would contribute money to a bounty for an equivalent Virtual Cam plugin for OBS that works on Mac, fwiw. I would also contribute time.

(OBS is really an incredible piece of work by the way, I wasn't familiar with it before the COVID wfh situation)

It isn't cross platform but v4loopback does allow obs to output to a v4l device. v4l means literally video 4 linux afterall shrug.

Is there a reason you need device access for this or wouldn't something like webrtc work especially if you're using it for conferencing or something. Might want to look at OBS Ninja

Is there a reason you need device access for this or wouldn't something like webrtc work especially if you're using it for conferencing or something. Might want to look at OBS Ninja

That is more intended for ingesting other people's webcams into your video. OP is asking for a way to output from OBS into another program that is looking for a webcam.

Is there a reason you need device access for this or wouldn't something like webrtc work especially if you're using it for conferencing or something. Might want to look at OBS Ninja

That is more intended for ingesting other people's webcams into your video. OP is asking for a way to output from OBS into another program that is looking for a webcam.

Coming back to why it seems like consuming an RTSP feed is probably the most universal and portable method.

Coming back to why it seems like consuming an RTSP feed is probably the most universal and portable method.

I think you are making the same mistake. Again, this is not related to taking remote webcams and putting them into OBS. This is about taking OBS and putting it into another program, such as Skype or Zoom.

Also, I believe you can ingest RTSP into an OBS source via the media source. But again, that is solving an entirely different problem than the one that OP is referring to.

I'd like to try to direct this conversation in a more productive way, or else it will turn into a back-and-forth of vague ideas and +1's. Typically we have people funnel feature requests through our Ideas page rather than through Github, but I suspect people will get the wrong idea if I close this right now.

If you are interested in taking a crack at implementing this, or at least have a reasonably thought-out design for this feature, please submit an RFC with your design here. If an RFC is opened, I will close this issue and direct this conversation to that RFC to discuss design concerns.

If you are generally a fan of this idea and want to show your support, you can upvote the idea on our ideas page here: https://ideas.obsproject.com/posts/8/allow-obs-to-send-video-output-to-other-applications

Nah I'd deal with OP directly. Less BS. Cheers though.

Coming back to why it seems like consuming an RTSP feed is probably the most universal and portable method.

I think you are making the same mistake. Again, this is not related to taking remote webcams and putting them into OBS. This is about taking OBS and putting it into another program, such as Skype or Zoom.

Also, I believe you can ingest RTSP into an OBS source via the media source. But again, that is solving an entirely different problem than the one that OP is referring to.

So what OP really needs is some software that can consume RTMP and exposed it as a UVC Camera.

Nah I'd deal with OP directly. Less BS. Cheers though.

OP doesn't manage OBS. If you want to collect a bounty, your feature has to be merged into OBS. Following my recommendation gives you the best chance of having it merged into OBS. If you ignore that, then there's a nonzero chance that you may end up doing a lot of extra work for nothing, and then you'll get mad at us for denying your PR.

So what OP really needs is some software that can consume RTMP and exposed it as a UVC Camera.

No, OP really wants software that can composite arbitrary video and expose that composited video as a UVC camera. OBS can composite video, but by default, it doesn't expose that video as a UVC camera.

Nah I'd deal with OP directly. Less BS. Cheers though.

OP doesn't manage OBS. If you want to collect a bounty, your feature has to be merged into OBS. Following my recommendation gives you the best chance of having it merged into OBS. If you ignore that, then there's a nonzero chance that you may end up doing a lot of extra work for nothing, and then you'll get mad at us for denying your PR.

So what OP really needs is some software that can consume RTMP and exposed it as a UVC Camera.

No, OP really wants software that can composite arbitrary video and expose that composited video as a UVC camera. OBS can composite video, but by default, it doesn't expose that video as a UVC camera.

Presumably another piece of software is going to consume and encode that UVC. Seems like a lot of stuff going on in one computer. I'm just thinking about portability/interoperability.

Presumably another piece of software is going to consume and encode that UVC. Seems like a lot of stuff going on in one computer. I'm just thinking about portability/interoperability.

Okay, but that means what you're discussing is entirely replacing programs like Zoom and Skype, which is outside the scope of what this is asking for. This is asking for a feature that would allow for integration with existing video conferencing software, rather than replacing video conferencing software.

@jon-valliere I think OP basically supplied a spec:

I personally use obs-virtual-cam on windows but most of my company and most of the tech world lives on mac for work.

"Make it work like obs-virtual-cam but on mac" sounds to me like it solves OP's problem?

Presumably another piece of software is going to consume and encode that UVC.

There will always be another piece of software, even if you mandated a whole company to use Zoom, there's always an "external vendor" that will start a conference call with the CEO on their preferred platform instead.

yes @jebjeb: Make it work like obs-virtual-cam, make the audio output work, ship it as native part of OBS across major platforms.

exactly @Gavitron, In any given day I'm in Google Meet, Skype, Teams, and Zoom. Getting all of those to offer RTSP ingress is unlikely.

I'll have to play dumb moneybags here. I think this ticket exists upstream of a proper RFP. Hopefully I can help someone put a proper RFP together but my time is reaaaly limited right now.

But of course I want everyone to defer to the OBS leadership team for decisions about what's best for the project, NOT TO ME.

I see a huge opportunity for OBS here. It can be an integral parts of many large companies communication systems. But if that doesn't fit into the vision that's OK.

But if that doesn't fit into the vision that's OK.

Wouldn't read entirely too much into the back and forth that goes on you're fine as is the request. There are conflicting interests for various reasons, one being there are commercial products that do it. As far as OBS goes it's long overdue though can be done indirectly. Looking at the code itself in Linux, it's not entirely that difficult just takes some time. The crossplatform part will be the bigger pita. I have no idea about creating a virtual device in windows.

Indeed. A major component of whether a PR will be merged is consideration for how maintainable the code is. A submitter may leave a drive-by PR and disappear from the project after the PR is merged, in which case we're left with maintaining the code on our own in case issues come up in the future. This includes using sensible naming conventions, logical code structure, and good documentation.

A submitter may leave a drive-by PR and disappear from the project after the PR is merged

This is all very true and a high risk, I still see it as follows (a different approach):
Why not doing a spike effort by the core maintainers to finally resolve this feature request. The money could be either split between them (since they do an extra mile and might have some disadantages of this) or going to the project itself to pay for hosting, stickers, infrastructure...

I did some looking into this for macOS today. Looks like CoreMediaIO's Device Abstraction Layer is the way that Snapchat's Snap Camera creates a virtual camera device. I briefly tried to get this example code running during lunch but didn't quite get there (though my QuickTime now crashes when I try to open it so I know I changed something! :D)

I'll try to poke at this some more tomorrow and will report back if I get a proof-of-concept macOS virtual camera running.

Does someone knows a good tool to start collecting money in an escrow service? Almost at the same time like @tobi posted here there was an other conversation at obs-virtual-cam. And there are more people willing to pay for it. It would be good to collect the money so dev's can feel save getting the money.

I believe BountySource is traditional.

@signalwerk @tobi you can post and fund bounties directly from Github issues using https://gitcoin.co/

The money sits in an Ethereum smart contract, no need to trust any 3rd party or escrow service

My Mac solution looks like this. You need OBS Studio and CamTwist and an external monitor.
CamTwist no longer works on Mac OS X Catalina due to signed driver requirements.

The only solution I've found to make it work is to connect a USB-C-> HDMI adapter, then plug the HDMI into a video capture device like a CamLink 4K (which costs over $100 btw) and have OBS output to the secondary monitor (the HDMI port).

This would be an excellent feature, and I applaud you for putting up this bounty.

Why not doing a spike effort by the core maintainers to finally resolve this feature request

To be quite honest, the team doesn't have a lot of Mac expertise on it right now, and the Mac side of this specific project is going to be the hard one. We've had several contributors who are experienced with Mac development from time to time, but most of their availability right now is rather inconsistent. The only reliable person on the team who has any appreciable experience with Mac development is Jim, and it's admittedly his weakest of the three major platforms. Jim did recently (Monday) get a new Mac development machine, but right now his focus is on getting v25 out for Mac, which still isn't done yet due to an issue with browser sources.

So the only person really capable of contributing to a "spike effort" is busy fixing an issue that needs to be fixed before we could even release a theoretical camera output on the Mac platform, which was the impetus for this whole submission in the first place. Furthermore, it's difficult to drive an organized development effort when Jim is the only one who works on OBS full time, whereas almost every other developer has a full time job doing something else.

I believe BountySource is traditional.

Since everybody's jumping the gun, let's go ahead and make a couple things clear, and let me get some of my bounty thoughts out of my head. I wanted to wait until I had more time to plan this, but apparently everyone loses their goddamn minds at the concept of $10k.

My original plan for bounties is more ideally based on the OBS Open Collective page. The flow would be:

1. Create RFC
2. Once the RFC is accepted, the OBS maintainers set a bounty on the project based on the project's estimated difficulty and importance
3. One or more people post that they would like to work on the project
   • This is to avoid having a race to implement a bounty, which could lead to conflict if two or more people post competing PRs for the same feature at roughly the same time
4. The bounty hunter(s) are given an appropriate amount of time to implement the feature
   • Regular check-ins are done to monitor the progress of the project, and adjust target deliverable date accordingly
   • If a bounty hunter abandons work on the project, the bounty is opened again for somebody else to work on it
5. A pull request for the bounty is created
6. The PR is reviewed to ensure it complies with the spec, and any necessary changes are made
7. The PR is merged
8. The bounty hunter(s) submit an invoice for the bounty amount to the Open Collective page, and the OBS maintainers approve it

This has some distinct advantages over services like BountySource and IssueHunt:

• With Open Collective, we (the OBS team) already have a built-in seed fund to fund these sorts of endeavors, especially large ones, without having to let another platform dip into the fund. This allows us to fund large bounties ourselves without having to rely on large individual donors.
• Open Collective payouts are paid in full to the bounty hunters, thus avoiding the 10% withdrawl fees of BountySource and IssueHunt. Instead, those fees are absorbed by the Open Collective platform fees.

The primary shortcoming of this system is that it doesn't explicitly allow direct public contribution to increase the size of a bounty. Users can obviously make donations to the Open Collective page in a general sense, but there's no explicit way to earmark a donation for a specific bounty. I have a couple ideas for workarounds for this, but it could get funky.

gitcoin

I have an inherent distrust in crypto-based solutions to these problems. I'd really rather not have to deal with it, personally.

@johnboiles I assume it requires a kernel extension right? That's the real problem.

I've said this elsewhere, but our biggest problem with macOS right now is we don't have any serious macOS expertise on the project. macOS is unfortunately only lightly maintained because of that fact. Even right now I'm forced to look in to all the project's macOS issues personally for every patch; thus the macOS patches are always delayed significantly. Otherwise version 25 would be out right now for macOS instead of just Windows and Linux.

Right now, we don't even have a .pkg installer for macOS. Right now it's just a .dmg where you move OBS.app over to the Applcations folder. If a kernel extension is needed, we would need an installer and with that, installer signing for .pkg files so users can actually install them without macOS preventing them from even opening it. That doesn't even account for potential kernel extension/driver signing which is probably another separate level of signing and requirements to distribute. On macOS, we just have basic digital signing for the program's binaries. It's difficult enough to deploy as it is and I basically have to look around for people who are willing to look in to macOS issues every time they arise because I just don't have the time/energy to deal with it all the time when it's such a small portion of our userbase normally.

I don't really know what to do about the macOS situation. It'll likely be the most difficult aspect of this problem to overcome and require effort from all parties. I am not a macOS expert by any means, my expertise is primarily Windows.

@jp9000 using the DAL apis you don't need a kernel extension, but you do need at very least a plugin installed to /Library/CoreMediaIO/Plug-Ins/DAL -- so either there'd need to be a menu item in OBS that can install this at runtime (with the system permissions dialog), or there'd need to be a separate .pkg distribution for this plugin.

You might also need a background process to connect the plugin with the host software -- but i'm still trying to figure out if that's necessary.

@johnboiles I appreciate you sharing your knowledge, if we don't need a kernel extension then that's pretty good news, if we need to switch to .pkg that might be fine as long as we can get installer signing. It would probably be a lot of work to get .pkg going again properly, but there's so much where I just feel like I need help every step of the way due to my lack of macOS experience. I just don't want to have to personally deal with that if I can avoid it. The person who takes the bounty would likely have to deal with that. We can also implement a popup or something when they attempt to use it as well, although that leaves the potential for dangling files when removing the program, which is annoying, unsure what to do in that case.

@dodgepong

I have an inherent distrust in crypto-based solutions to these problems. I'd really rather not have to deal with it, personally.

That's the beauty of open-source and blockchain-based smart contracts - code is law, you can read it yourself, trust is not required.

That said, the UX/UI needs to come a long way, and maybe that's what you don't want to deal with, which is fair. But I think an inherent distrust is misguided :)

In the absence of an RFC for now, let's keep this conversation on-topic.

Please no more discussion on how/when/where the bounty will be collected. Come talk to us in Discord or IRC if you have concerns, or reach out to us via email.

OK I started a skeleton of an RFC here: obsproject/rfcs#15. I tried to collect some references for comparison, explain the motivation, and add some UX thoughts, but I don't know anything about how OBS works so I'm not able to flesh out design section. Please improve!

I've said this elsewhere, but our biggest problem with macOS right now is we don't have any serious macOS expertise on the project. macOS is unfortunately only lightly maintained because of that fact. Even right now I'm forced to look in to all the project's macOS issues personally for every patch; thus the macOS patches are always delayed significantly. Otherwise version 25 would be out right now for macOS instead of just Windows and Linux.

As someone running multiple meetups where we all record using OBS, and the developers all use Mac, I never even realized how much work must go into supporting OBS on that platform. Thanks for what you do @jp9000!

https://about.riot.im/
https://jami.net/
https://alternativeto.net

OBS upgrades are cool but so is using a better conferencing app

Edit: So many thumbs down. LOL I guess just keep using bad software and use OBS as a bandaid.

While I do not have experience with Mac-specific APIs, I do have both C and C++ programming experience. I also use OBS to teach remotely (with the Virtual-Cam plugin). I would love to see this feature added as my main workstation is a Mac. I am not here for the bounty, but I am willing to help implement, test, or otherwise contribute work to this particular feature.

I will be keeping a close eye on the conversation. I have also begun browsing and learning the source code and its design.

My understanding that this will be implemented as a webcam/mic driver accepting RTMP stream. If so, it would be nice if it's done in a generic, non-OBS specific way, so that the driver could accept a RTMP stream from any application, not just OBS, and could be set to listen on the network, not just localhost.

This would allow for more flexibility. For example, one could setup local re-streaming: OBS sends RTMP stream to a local Nginx server, which then re-sends it to Twitch and the webcam+mic driver for Skype. Or you could make the webcam+mic driver listen for RTMP streams on LAN and stream to it from a different PC. For example, the latter could be useful when you run Skype isolated in a VM because you don't trust it enough to run on your Linux system, but you want to share the screen of your Linux host with whoever you are having a Skype video call. These are just a few examples. there is a lot you can do with this flexibility.

My understanding that this will be implemented as a webcam/mic driver accepting RTMP stream.

Incorrect. This would be outputting directly from OBS's renderer to a webcam device.

Since @jebjeb has kindly gotten the ball rolling on an RFC, I'm going to close this issue and direct all further design discussion to that thread so that we can keep this Github issue page clean.

Please continue this discussion here.

I encourage you to read the spec and make suggestions based on what is stated in there.

@tobi Just following up here in case you missed it, but it looks like cross platform virtual cam support landed in 26.1: https://github.com/obsproject/obs-studio/releases/tag/26.1.0 -- if your bounty is still up for grabs, you may want to talk with @johnboiles @PatTheMav @CatxFish and @cg2121 (who were all credited in the release notes for the feature) 🙂

@cweagans I just payed my bounty 20min before your message and also reported it here