done,
demo is updated to the latest 3.1.2 (with RTMPS turned off)

On Wed, Jul 13, 2016 at 3:01 AM, [email protected] <
[email protected]> wrote:

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



-- 
WBR
Maxim aka solomax

Reply via email to