My thoughts exactly. When I used OBS there was no equalizer. Later I decided to try making one and found they had a new 3-band which was useful for learning how to make audio tools and I was happy to bring my 8-band idea to life. I submitted a PR and one of the devs shepherded me through a few cleanups to make it acceptable. Then they rejected it as somehow non wanted in the project. As an OSS maintainer myself I get it - even though I don't understand the reasons they seemed divided on it since one of them helped with the PR. I try not to speculate on the why, so I have just kept my fork there with the 1 commit to add the 8-band. It's probably way out of date so I should rebase it on latest release. Sounds like there might be some naming convention changes too but I need to find time to look into it.

> In its simplest form, VDO.Ninja brings live video from a smartphone, tablet, or remote computer, directly into OBS Studio or other browser-enabled software.

I really hope I'm processing what they're saying incorrectly but this sure sounds like they are doing a video encode for each peer, which is madness & obviously bad.

VDO.Ninja is a peer-to-peer system. This means for each new person viewing your feed, a new encode is processed. It also is CPU bound since encoding usually takes place on the CPU. Take care not to overload your system. Keep an eye on your CPU usage.

The intro video also emphasizes that each person has to send video to all peers, that in fact it's not about sending to OBS, it's about having people in a room. And warns that room size of 10 is about as good as you'll get. Seemingly because of these limits.

But if it does what the original purpose states, of streaming to OBS (a single consumer), it doesn't really matter. I am piqued to see how it handles maybe sending multiple people's streams to OBS: if that's what the room is for that's very rad (even if weird anti-efficient at it?)!

I really like the idea of web based tools for video capture. And for some video production. It's cool that vdo.ninja is here. But what the heck; this sounds not good.

Also I find it a weird claim that anyone would have heard of vdo.ninja but not webrtc. 3 results for https://hn.algolia.com/?q=vdo.ninja , about a thousand for webrtc. Always an interesting world, interesting people.

I am mostly broadcasting the desktop view of a second or third computer on my desk, plus slide decks, graphics, etc. I hate Zoom's clunky screen picker UI and never want to accidentally share plaintext secrets or PII to the attendees by choosing the wrong window or absentmindedly moving a window to a shared monitor or something, so I got around that by just using OBS as a switchboard, and never having production data on my test computers. One is hooked up to an Elgato Neo capture device over HDMI, the other when required over a BMD Intensity 4K on an eGPU dock. Slide decks are the only data from my presenter computer ever shared, but via a 'macOS Screen Capture' source. I have a few scenes with text only too for info/time stuff. It's great being able to slap some text over a scene, or have two computers up at once in a half-and-half arrangement. Plus plugin support (used to capture from the BMD from a PC tower and send the video to my presenter computer over NDI when an older elgarbo capture card shit the bed), audio and video filters/effects, goddamn shaders, sky's the limit since OBS is so extensible. I've done in person presenting and still used OBS to generate a fullscreen projector of the program output.

I also personally have always found the "presenter awkwardly clicking around through an un-played Powerpoint" to be really unprofessional. I can hide all of that messy stuff and not just a bunch of dead air.

Right now I'm working on getting an Adafruit Macropad to talk to an ESP32 over UART so I can build a wireless streamdeck that doesn't require any shitty bloated control software. The ESP32 would then send commands/get statuses from the Websockets server and send em back to the Macropad so it can update the screen. This would be impossible to do with Zoom since the app isn't scriptable (on macOS most AppKit UI can be automated with AppleScript) and they only engineer for the lowest-common-denominator use cases.

they probably think about money, though. and whether there's a significant difference in features or not.