|
|
|
|
|
|
by lminiero
2209 days ago
|
|
|
Not sure what you were expecting: at the very foundation of WebRTC is SDP, which implies negotiation, and with endpoints supporting potentially different codecs, negotiation is very much important whether you like it or not. That's why the VideoRoom plugin does need to take that into account. I won't get into the discussion of how complex a fork is to maintain: I always hope people contribute back what they add (assuming it's generic enough to fit the project and not customer-specific), rather than keeping it to themselves. That said, the vast majority of people don't really need to write their own plugin, or even customizing existing ones. What we foster a lot is leveraging existing plugins as much as possible, maybe combining them at an application level, and not reinvent the wheel, and it seems to work for most (it certainly does for us, for our own applications). On the Lua demo, it is indeed a bit more limited than the C counterpart (we clearly didn't invest as much time on it), but I'd disagree on the "incomplete" part. All the relevant parts are there, and most importantly, it's supposed to be much easier to extend and modify than the C version. There's at least one big company we're aware of that's using it in production and is very happy with it. |
|
|
I would expect the logic for negotiating streams to be an unrelated layer of abstraction to the concept of room management? That the code and work 100% of video apps want--SVC, end to end encryption, negotiation complexity--is mixed up in the same giant C file as a monolithic plugin with the code for JSON configuration files of a "rooms" abstraction that is a hardcoded notion of a single narrow vision of a multiparty video chat server is really awkward, and means that at best every single application ends up either as a messy fork or with a thick middleware adapter that attempts to translate between these concepts.
It is like wanting a pub-sub solution to build your own chat system but being handed a full IRC server as your building block, where you either need to fork the system to rework the notion of "channel" and the various user mode flags to match how you want to do chat--and then hope you can easily still rebase your work to the latest codebase, as the implementation of basic things like "send a message and have other people receive it" is mixed together with the notion of "a half-operator is someone who can kick users but not change the list of operators"--or build some thick middleware adapter layer that is simulating a simpler pub-sub system on top of degenerate channels.
If the code for "rooms" was a different layer of abstraction from the code for "WebRTC VP9 SVC signaling", it would allow me to just build the parts I want on top--so I can get the semantics of a public government hearing, which is different from a business meeting or a webinar or a "house party" without figuring out how I am going to translate my concept onto the existing meeting semantics of the VideoRoom plugin--or at least if the code for this was cleanly placed into a separate C file then I would be much happier with this idea that I am supposed to "extend and modify" the codebase to implement my own semantics, as I wouldn't be so worried that one day I am going to get a merge conflict on this 8k line file full of C code I am hacking on :(.