Cool, let me try to clone that and see if there is any way I can contribute to that.
There was some other discussion last week with Maxim and me around the 1:1 versus 1:100 conference calls. My point is that if 1 user streams to 100 participants, he will 100 times the upload the stream. There is no magic that will make 1 stream go to multiple participants. Maxim said that you and him believe this can be done. I don't think so. There was some talk around multicast. I don't think that this is that simple. There are many different ways for xyz casting, like uni/any/multi cast. See for instance: http://serverfault.com/questions/279482/what-is-the-difference-between-unicast-anycast-broadcast-and-multicast-traffic But there is no way of doing those modes in webRTC and save upload bandwidth. See for instance those answers here: http://stackoverflow.com/questions/20056683/webrtc-multicast-one-to-many Which also outlines one possible solution:"A simple solution can be peer-to-server model (peer-to-media server-to-all other peers)." Which is pretty much the same we do right now. And the work you are doing now on the native client will be necessary for this. Anyhow, I think you guys still want to demo that and I think you still think that there is a P2P mode that will not require a server-to-client stream. I think this server to client streaming has a lot of advantages. One is also the later potential of re-encoding streams in different qualities. One of the modern features of streaming is called "adaptive streaming", which will switch the stream depending on the clients bandwidth between different quality. This will only be possible with a server side processing of streams as you need to be able to provide streams in different quality. And also the ability to stream 1 conference to let's say 1000, or 5000++ people has been one of the biggest and longest discussed challenges of OpenMeetings. Since pretty much the beginning of the project. So heaving a scalable solution that works in 1:1 but also is possible to scale in 1:1000 scenarios should be a major cornerstone of the future roadmap. So obviously: - We are still keen on verifying my above thesis around bandwidth consumption - This is a long road to go and we have to go one step at a time So I would be keen on trying some demo verifications around running the previous prototype with more then one viewer and monitor the bandwidth. And then, in case my theory is right we quickly advance in to how we can utilise the work you are doing to come to a server-to-client streaming where 1 client runs on the server acting as a kind of proxy to balance the bandwidth. Thanks, Sebastian 2016-07-12 7:14 GMT+12:00 Dmitriy - <[email protected]>: > Hi Sebastian, > > You can find it here - https://github.com/Dima00782/OMStreamSaver. > I upload the webrtc library part and the client. I've found the client in > the Internet, but It has a Apache Licence 2. I think that this client is > more close to our finished version of native API. > > I'm starting to remove unnecessary parts of the client - qt, gui and > others but only locally. I think I can demonstrate something soon. > > Sorry for the long reply. > > On Fri, Jul 8, 2016 at 7:49 AM, [email protected] < > [email protected]> wrote: > >> Hi Dima, >> >> as for the native webRTC code investigation: Is there any code to look at >> yet? >> Can you put it somewhere on Github or so? >> >> Thanks, >> Sebastian >> >> 2016-07-08 3:34 GMT+12:00 Dmitriy - <[email protected]>: >> >>> Changes for this week: >>> - add rooms concepts >>> - move clients code to separate entity >>> >>> Also I continue investigate to webRTC natives. >>> Future plans are the same. >>> >>> -- >>> Regards, >>> Dmitry Bezheckov. >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> [email protected] >> > > > > -- > Regards, > Dmitry Bezheckov. > -- Sebastian Wagner https://twitter.com/#!/dead_lock [email protected]
