This doesn't work with multicast, does it? I surmise that the bandwidth requirements of the initiator increase linearly with the number of participants, but it would good to put that in the README.
Would also be good to say a word about latency. Will the host (or as they might be known in the project: projector) be 3-5 seconds ahead of the guests?
This works by creating a p2p RTCPeerConnection between the host (or projectionist) and each member of the audience. So the p2p aspect is a hub and spoke model. The video is captured either from a local video element if you're sharing a local file, or from some part of the projectionist's screen using `getDisplayMedia`, then streamed over that connection. There is a server that's responsible for the signaling required to create those p2p connections, but it's responsibilities end there.
The only requirements are a reasonably new browser and something you want to watch. I suspect that you're right about bandwidth requirements, however I haven't done the experiments to prove it. In terms of latency I haven't noticed anything significant, but I'm sure that's dependent on the bandwidth of the two parties.
If you're at all interested and willing to help improve the README or any part of the project, a pull request would be very welcome!
The basic idea is, one person can open a theater and share their screen or load a video file. Then anyone with the audience link can watch along with them.
I hope it lets some people enjoy some movies together!
I'd love any and all feedback / contributions to the code https://github.com/whytheplatypus/shareable.theater!
We are working on a internal project at work using WebRTC for some non traditional use cases and came across some limitations with large resolution, high bitrate H264 video.
