Re: Client/server (non-p2p) video

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