Re: Client/server (non-p2p) video

     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 
> <mailto:kevinday@gmail.com>> wrote:
>
>
>     On Mar 30, 2013, at 10:48 PM, cowwoc <cowwoc@bbs.darktech.org
>     <mailto: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
>
>