Could you please also disable RTMPs on that server for the meeting this
Friday ?

Thanks,
Sebastian

2016-07-12 17:35 GMT+12:00 Maxim Solodovnik <[email protected]>:

> 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
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
[email protected]

Reply via email to