Re: Client/server (non-p2p) video

On Mar 31, 2013, at 2:56 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> 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.
> 
> 
Hi, Silvia!

Again, I may be missing something, but at the moment it appears that you could only have the browser send an *uncompressed* byte stream over XHR. Or if you did want to compress it, you were doing so in javascript. This doesn't work as a replacement for Flash, the bandwidth requirements are way too high, and we'd basically be reinventing the wheel for what WebRTC is providing for p2p users.

If we can get the compressed stream to a server somehow, we could decompress it and serve it using HTTP Live Streaming (m3u8 playlists), but browser support for live streams inside HLS currently isn't that great.

It would be really beneficial if there was a documentation within WebRTC's scope that elaborated/endorsed some kind of server in the middle as a one-to-many redistributor of Peerconnection style connections to multiple peers. I think this is probably the only way that this will be truly viable as a replacement for Flash in these scenarios. The issues I see happening if this isn't explicitly allowed are extensions some day down the road that allow two peers to negotiate settings that affect the video stream - if the clients are actually talking to a server which is talking to thousands of other clients, it may be impossible to produce a stream that all peers are happy with.