RTCMultiConnection
RTCMultiConnection copied to clipboard
muaz-khan
Scalable Broadcasting.
So with the boadcaster using Chrome, it seems all combinations of viewers using either Firefox or Chrome browser works for me.
However, if the broadcaster uses Firefox, there are issues with Chrome in the mix of viewers. Like if the broadcaster uses Firefox and all viewers are using Chrome, the third viewer to join has a black screen for video?
Has anyone else seen this? Is there a fix?
So I've been testing and fixing stuff as I go along to see if we can get this working good enough for smaller stream groups. From testing there are a few features that need to be addressed: Adding connection quality metrics and super noding.
Super noding would allow a healthy client in the chain to server up more than one additional client (making it into more of a tree structure).
The metrics for connection quality would be used to push people with poor connections towards the end of chain, or closer towards being leaf's in the stream tree so you don't have them uploading/resharing choppy video.
I have fixed/added some features to my current version I've been working on. Like higher quality audio, the audio doubling issue (there is another background media element with no controls that plays by default in the demo)
@rayj00 have you still been looking at using/playing with this?
So I've been testing and fixing stuff as I go along to see if we can get this working good enough for smaller stream groups. From testing there are a few features that need to be addressed: Adding connection quality metrics and super noding.
Super noding would allow a healthy client in the chain to server up more than one additional client (making it into more of a tree structure).
The metrics for connection quality would be used to push people with poor connections towards the end of chain, or closer towards being leaf's in the stream tree so you don't have them uploading/resharing choppy video.
I have fixed/added some features to my current version I've been working on. Like higher quality audio, the audio doubling issue (there is another background media element with no controls that plays by default in the demo)
@rayj00 have you still been looking at using/playing with this?
First, I am not a Javascript programmer. My "expertise" is in an ancient assembly language used on telephone switches. :) That said, I have been "playing" around with RTCMulticonnection/Scalable Broadcasting code on and off, mostly off, for a couple years. I still don't have a good idea of how it all works. But I got it working to some extent. I have added a simple authentication. One for broadcaster and one for viewers. My issue is testing with many viewers. Right now I use multiple tabs in the browser, but that slows connections down considerably if I get to 10 or so tabs (viewers). What has been your experience with it?
Also incorporated a database to store roomID rather than using the local storage. I also got recording the broadcast working.
All that said, I'm now playing with conferencing. Trying to get switch camera to work.
Good to know there are some people around with some technical chops like Assembler. I've a bit of a different background, lots of C/++/# python, js and I've dabbled in Assembler to debug things.
So I've been testing with a very small group of people I know. I've noticed that there seems to be some logic bugs in how the room management works. You can easily get into a situation where the room is hung open and you cannot start a stream until everyone has cleared that room. I've been looking at stringing this together with some more socket.io stuff to make a bare bones federated streaming site/system that can be ran with almost no infrastructure. But I've also done a similar mod to it, that allows authenticated streaming, so a user can start a stream, then other's can watch it.
If I had to guess you are probably hitting your machine limits when testing 10 streams locally, that is about where another system I had played with died, because the video processing side of things will chew up a bunch of cpu after you created a bunch of peer connections to new users.
I've been toying with this idea for almost two years and came back to this library after I was able to set it up and getting it working.
From talking to some of the people I know that want to use this, they would like to be able to record or clip things from their stream, they might also want to do something similar to conferencing.
Also to give you and idea, I've built some functional parts of what Mauz has done by hand, it's taken about 3 months of pouring over the client side to get a good idea of what is going on. The way that Webrtc works is just complicated enough to make it complicated to manage all of the moving parts, you could probably get all of this down to 2-4k lines of code from the almost 10k that it is counting the server side.
So are you trying to change from desktop capture, to camera, to tab while still broadcasting/sharing? Technically you can use a page element for a media source if I recall correctly from when I started playing with idea originally.
For conferencing, I'm considering the mobile user and his ability to change cameras. I do have two USB cameras connected to my PC to emulate a cell phone...kinda. :) I think I have the stream swapped, but it's showing no video. No errors in the console log either. I truck on....
If you want to take a look at the monstrosity I published it as fedwave in my repo's. There is also a public instance of it running for testing.
Have you looked at trying to set up a server on something like Linode with DNS pointing at it with SSL certs? It's easier to test how well it works in practice if you get it off of your local computer.
Yes. Actually I have a Linode VPS. I am using LXD to containerize and letsencrypt for SSL. I have multiple containers, like one for scalable broadcast, one for conference calling, one for a plain website, etc. I still would like to have maybe 50 viewers for my scalable broadcasting testing.
Nice, I'm in the process of getting a hold of people to do more testing, the big weakness I've see is getting slow users in the viewer chain. I'll probably be able to wrangle about 30 people to do testing.