Re: Client/server (non-p2p) video

Indeed, #2 is a different use case, but the question that Kevin asked in
the email that started this thread seems to be focused on solving #1.
Silvia.

On Mon, Apr 1, 2013 at 5:23 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>
>     It sounds like we're talking about two separate use-cases:
>
>
>    1. Broadcasting a one-way video stream to many clients
>    2. Using gateway as an intermediary for N-party video chat
>
>
>     I am interested in #2 which isn't addressed by your suggestion.
>
> Gili
>
> On 31/03/2013 3:56 AM, Silvia Pfeiffer wrote:
>
> The way I understand it, one-to-many doesn't need peer 2 peer. What you
> need is a way to record video and put it on a web server as an ever-growing
> file - then, the video element takes care of distributing the video to many.
>
> If you wanted to use a browser for recording, you would use getUserMedia
> and then send the recorded bytestream to a server using xhr from where it
> gets distributed again. To scale that, use a CDN.
>
> I've not actually tried this, but that was my impression for how to do it.
>
> Silvia.
> On 31 Mar 2013 15:44, "Kevin Day" <kevinday@gmail.com> wrote:
>
>>
>> On Mar 30, 2013, at 10:48 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>> >
>> >    I second Kevin's motion. We need a more thorough discussion of how
>> to model a client-server chat, especially in light of the fact that this is
>> needed for multi-party chat (ideally you one the server to act as a gateway
>> for the conversation, otherwise you end up with N-N links).
>> >
>> >    Node.js is great and all, but I don't plan on using it to run in
>> production. I'm looking for a solution that will allow me to run a single
>> server that will handle both normal web content, and WebRTC streams.
>> Running two separate servers is not ideal. Are there plans to offer better
>> integration for Java-based web servers who wish to act as WebRTC peers?
>> >
>> > Thanks,
>> > Gili
>>
>>
>> Thanks for making my point more clear.
>>
>> Node.js is great, but won't scale to the levels we need. We have
>> applications using Flash right now where one broadcaster can have tens of
>> thousands viewers using a hierarchy of servers. I'm not suggesting that a
>> server be part of WebRTC's goals, but before anyone starts writing a server
>> it probably needs to be discussed.
>>
>> There was talk early on that peer-to-peer and client-server were going to
>> use two different protocols. I haven't seen this mentioned since though.
>> Looking at the protocol for how peer-to-peer works, this is probably usable
>> as a client-server protocol, but if that's the case then it probably should
>> be stated somewhere that this is the path for server communications.
>>
>> There's probably a level of due diligence that needs to be done to make
>> sure that this is currently and remains possible too - ideally the server
>> won't have to transcode anything to make sure that different versions of
>> encoders and decoders remain compatible with each other, so the same stream
>> can just be replicated to all clients. Clients need to be able to jump into
>> the middle of a stream with minimal work on the server's part, etc.
>>
>>
>> -- Kevin
>>
>>
>>
>