First of all, is it a nice and successfull idea to use peer 2 peer to broadcast realtime video ? I know that it will make the application scallable and will allow more users to get the real time video without affecting the server much, but are there drawbacks performance-wise and video quality-wise ?
Now the specefic question, my intention is to share realtime video, and then use peer2peer in the webclient level using websockets, are there any libraries that are used for this purpose?
I know that streaming should be better using UDP but the follwing post says that even using websockets (TCP) at 30fps is fast ennough (Video streaming over websockets using JavaScript)
XSockets.NET provides a WebRTC API.
This will provide you a JavaScript API for P2P communication. You can actually have a video chat with 2 or more participants really easy.
If you are a .NET dev you can install the sample from nuget. That sample contains a example of a multivideo chat.
The video will be of high quality, but you can set parameters to get lower resolution if you have low bandwith.
WebRTC works in Chrome and Firefox today (as well as chrome 29 on android). You can try this site with Chrome (not updated for Firefox or mobile) http://browsermeeting.com/
Nuget Package
You can check out IceLink (disclaimer: I work # FM), it'll help you do this.
I've actually built something along these lines for a client of ours, where each successive client becomes a potential "distribution" node. So X clients connect to the main server, and from there, other clients can connect to those clients (provided they have appropriate bandwidth/CPU/etc) for a re-broadcast version. It's sort of a supernode/mesh concept, and it works reasonably well.
Related
I want to build a real time online multiplayer game. After researching WebSockets and WebRTC, I've come to the conclusion that WebRTC is exactly what I need if I was building a p2p game. However, WebRTC seems like its not meant for handling group conferencing. This is because if there are "n" users, there will be "n-1" streams of data. This is obviously not scalable. There are smart ways to circumvent this, like using https://github.com/jitsi/jitsi-videobridge and other solutions. But essentially it seems that WebRTC is meant for one-to-one communication. Most of the tutorials out there serve that purpose, not group conferencing.
Questions -
I've read that Google Hangouts and Facebook Messenger use WebRTC for their group video chats but how exactly have they solved this problem?
Are server based Websocket implementations like uws viable for real time communications? (due to added latency)
Is there any plan to address group conferencing from the WebRTC or is WebRTC just not meant for this use case.
Thanks in advance.
I'm using WebRTC in Firefox and trying to get the following to work: take a remote MediaStream from a peer (given through PeerConnection), filter it through web audio, and then send the resulting stream to another peer (again through PeerConnection). I hear this is possible in Chrome (or at least the latter 2 parts), but I can't seem to get this to work in Firefox. Does anyone know if it's even possible at the moment?
It's not yet quite possible, at least not in Chrome. We're working on it.
I want to create a webrtc broadcasting demo
https://webrtc-experiment.appspot.com/socket.io/
here i have a one problem broadcaster have huge bandwidth when connect 10+ user because it use peer to peer connection so it use upload bandwidth like this
Total upload bandwith = number of user * ( 30 kb approximate to upload 1 video)
so i want to develop like this
http://bloggeek.me/webrtc-multipoint-small-groups
how to i develop multipoint webrtc using minimum bandwidth ?
While your thought of using WebRTC in a small group multipoint manner, this comes with a lot of complexity and reliability issues. Most WebRTC apps that relay through peers tend to be not so reliable in my experience. In concept it's a great idea, but I haven't seen any solid practical applications. The most reliable implementations of scalable WebRTC broadcasts tends to use a server in the middle. You can use something like Janus, but I prefer Kurento which is open source. There is also a platform called OpenVidu that sits on top of Kurento if you don't want to have to get into the nuts and bolts of how things works, but is less customize-able. You can even record, transcode and process the video in real time.
We are currently working on an app that uses pusher.com to maintain a list of available people on our chat application.
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work. Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
So far, here is what I'm considering:
XMPP/BOSH
socket.io (self-hosted)
pubnub
As for the scale, we will probably have to handle 100+ messages per second and 10000 concurrent users. Nobody here has ever played with socket.io (or bosh), and we do not wish to have too much maintenance work (ie deal with many servers and such). So 2 or 3 self-hosted servers is ok, 10+ isn't.
Any thoughts?
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work.
This is incorrect. Pusher (who I work for) provide fallback for older browsers. HTTP-based fallback has started to be released to go alongside the existing Flash socket fallback. So, older versions of IE were already handled with the Flash socket fallback but the HTTP-based fallback will give near 100% browser coverage.
The November 2012 issues of the Pusher newsletter has the following:
We've always loved WebSockets, and since the beginning they have been our primary transport mechanism. While they are still the best way of sending data between applications, we do sometime have to resort to various trickery to negotiate troublesome proxies. By popular demand we are soon going to be bolstering our legacy support by adding HTTP based transport to our existing fallback options.
We have already deployed some provisional endpoints which apply in a set of limited conditions, and we'll be continuing the expansion of this feature over the next few months. If you want to have early access to this as a beta user, please get in touch with support#pusher.com.
In terms of cost:
Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
Have you contacted Pusher support explaining your use case? Discounts may be available.
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
There's a realtime web tech guide which has a good list of realtime web technology solutions (it's on my site and I maintain it). If you want to support IE then a solution which offers HTTP-based fallback is the safest bet.
I would personaly go with socket.io. It supports Internet Explorer 5.5+.
It supports various transports and uses the most-appropriate one to ensure browser compatibility without having special code to work with each browser. Here is the list of transports from the website:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
You can see the full list of browser support here.
As for BOSH, here is a discussion on BOSH vs Websockets. If you go ahead with BOSH, you will be missing out on Websockets functionality that modern browsers support.
You should check out ScaleDrone as an affordable alternative to Pusher.
I bet WebSockets are much faster.
So if I want to use lots of ajax continuously, WebSockets are recommended as an alternative?
It's two different technology things.
With AJAX client just send request to server and wait to response.
Websocket is HTML5 implementation for Comet technology, the idea is push information from server to client.
Ajax is slower because the overhead.
But Ajax is more compatible, Websocket is currently a bit experimental and it is not widely supported by most browser.
I think is not a issue of speed, is a issue of comunication and real time process
If you're in regular need of asynchronous data transmission I'd say you should try out websockets, it's really easy to use. One problem is - because of the early stage - the websocket interface might change (which has happended already) and render your web application unusable until you update your code.
Definitely WebSockets!. During my last internship, we used WebSockets together with Erlang to build a chat app for feature phones. Not only was it resource-efficient, it was also faster,
and really realtime - connections are always open, until either end closes.
And oh, they are experimental but works well on Chrome, Firefox, Android and iOS.
The only problem was with parsing data with BB which was because of the library we were using, so we rewrote the library's data parsing algorithm and it worked.
We tested on only these platforms.
You can checkout Socket.IO which improves upon the raw implementation of WebSockets.
Visit this link for some quick demos: http://socket.io/#how-to-use