51–60 of 65 posts
Why use C over Rust or Golang? It sounds like a security disaster waiting to happen?
Earlier quoted context omitted.
It sounds like you have a use-case that you should just write your own plugin for. The out-of-the-box video room plugins aren't suitable. > the vast majority of the VideoRoom functionality is written in C It's still just a plugin that hooks the same callbacks and implements the same interfaces as any of the rest of them. Feel free to implement your own.
At that point why wouldn't I just use libwebrtc? The reason to get an off-the-shelf SFU is because all the hard work is in handling all the codec-specific workarounds, being able to handle keyframe request sharing, responding to RTCP bandwidth feedback to do SVC layer switching, and now doing all of this while most of the state is encrypted due to insertable streams... this is all hard stuff that people keep learning…
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.
Earlier quoted context omitted.
We write our own services to coordinate janus rooms over multiple instances. That service takes care of translating from our own domain specific entities to janus room. It's also responsible for sharding rooms to healthy and available Janus instances. Instead of treating janus rooms as thick/permanent, we prefer to treat them like "just-in-time", rooms get destroyed when not used and get provisioned when requesetd, m…
I recommend NOT implementing plugins in JavaScript with the Ducktape JS layer. I strongly recommend writing plugins in Lua for maximal compatibility and performance.
I checked out the project on github, and I was a little surprised to see no mention of jsmpeg.com as over on that project the number one question and issue is the lack of a quality web socket server. Long story short, anyone try this or think it would fit with jsmpeg?
Earlier quoted context omitted.
I do WebRTC on Edge/IoT devices (mostly MIPS/ARM devices running Linux). Customers are mostly teleoperations (robotics) and security cameras. Most customers run an MCU/SFU on a server, but then just a WebRTC client on the device. We do simulcast on the device to an SFU, and then distribute from there. Happy to answer questions here or directly. I don't want to be disrespectful and sell other stuff on this thread thou…
I'm concerned in targeting things like Janus etc to the MIPS architecture for streaming over WebRTC because typically I only see MIPS on legacy devices in my world. How does MIPS handle this stuff? PS: I know that Amazon has a product in the space and we're vetting AWS as our cloud provider due to it's diverse product offering. I've been looking at opensource solutions due to vendor lock-in but would love to hear if…
Earlier quoted context omitted.
What turn servers do you use?
Answering for myself, not for bbeausej. We are currently using coturn. It is quite easy to setup, you have to dig a little into the configuration parameter and that's it - I would recommend it. Oh well, you probably should use the rest api for generating credentials on the fly and think about scaling (depending on your needs).
Earlier quoted context omitted.
It sounds like you have a use-case that you should just write your own plugin for. The out-of-the-box video room plugins aren't suitable. > the vast majority of the VideoRoom functionality is written in C It's still just a plugin that hooks the same callbacks and implements the same interfaces as any of the rest of them. Feel free to implement your own.
At that point why wouldn't I just use libwebrtc? The reason to get an off-the-shelf SFU is because all the hard work is in handling all the codec-specific workarounds, being able to handle keyframe request sharing, responding to RTCP bandwidth feedback to do SVC layer switching, and now doing all of this while most of the state is encrypted due to insertable streams... this is all hard stuff that people keep learning…
However our WebRTC stack has the minimum of congestion control features (plain REMB, no simulcast), and it doesn't implement SVC or newer toys like insertable streams, nor does it completely abstract you from the grunt work that WebRTC leaves up to the user (like signaling, setting up a TURN server, or having a minimum of understanding about ICE in order to troubleshoot when problems arise).
Why use C over Rust or Golang? It sounds like a security disaster waiting to happen?
Earlier quoted context omitted.
I'm concerned in targeting things like Janus etc to the MIPS architecture for streaming over WebRTC because typically I only see MIPS on legacy devices in my world. How does MIPS handle this stuff? PS: I know that Amazon has a product in the space and we're vetting AWS as our cloud provider due to it's diverse product offering. I've been looking at opensource solutions due to vendor lock-in but would love to hear if…
MIPS is still alive in the IP camera world. There exist very cheap SoC's (e.g. the Ingenic T20 - http://www.ingenic.com.cn/en/?product/id/14.html ), tailored towards making cheap network camera's (~ €20 retail price for the full camera). I guess at that price point, the ARM license fee does become visible in the bill of materials.
I've long been curious about MIPS from a hobbyist/tinkerer/maker perspective and would be very interested to know what silicon I might select at a similar price point.
Earlier quoted context omitted.
At that point why wouldn't I just use libwebrtc? The reason to get an off-the-shelf SFU is because all the hard work is in handling all the codec-specific workarounds, being able to handle keyframe request sharing, responding to RTCP bandwidth feedback to do SVC layer switching, and now doing all of this while most of the state is encrypted due to insertable streams... this is all hard stuff that people keep learning…
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 (assu…
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 :(.