I'll set up demo on om.alteametasoft.com as soon as it will be ready and we can check
On Tue, Jul 12, 2016 at 5:30 AM, [email protected] < [email protected]> wrote: > 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] > -- WBR Maxim aka solomax
