Is it possible to send LocalMediaStream to a websocket server without usin PeerConnection?

[Sergio Puertas Ortiz]

Hi all, I'm trying to generate a video conference One To Many in one way direction.
The idea is to recover the LocalMediaStream from the emiiter via getUserMedia and then send to a websocket server which then will distribuite the stream to the rest of the participants.

Is that possible?

Regards

[Lorenzo Miniero]

The only way I can think about this would be to attach the local MediaStream to a <video> element, put a canvas there, save the canvas as an image on a regular basis and shoot it on the websocket. Highly inefficient for several reasons. I frankly see no reason why one should avoid the PeerConnection in the first place, as it's conceived for that exact purpose.

Lorenzo

Il giorno venerdì 17 maggio 2013 09:08:57 UTC+2, Martin Sandford ha scritto:

Did you get this working?

[Arnaud Morin]

because the peer connection is currently design to be used on a peer to peer basis.
If I want to push a video stream to a server instead of an other peer, I don't need all the suff that come with peerconnection (candidates, codecs negociation, stun server, etc.).

On my side, I did try the solution you are talking about (capturing canvas images and send it over websocket), and as expected, it's not really efficient.

Arnaud

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Justin Uberti]

Many users on this list are using RTCPeerConnection in a peer-to-server situation.

[Ket]

It is possible. But the sound quality is a pain.

[Dennis E. Dowhy]

Trying to audio/video conference over TCP will usually, if not always, result in a poor quality media experience. This is due to the nature of the TCP protocol itself, which both buffers packets on the sender (TCP window size) as well as delays packets during network congestion (TCP congestion control). Both of which result in immediate delays of the transmission of media packets and thus decoders on the receiving side will run out of packets to play back in real time. By the time packets arrived their playback window will have expired and the packets are immediately dropped and not played back (its completely useless to play back audio from 5 seconds ago during a real time conference). 

While the window size can be reduced (disabling nagles algorithm) you have no control over the TCP congestion algorithms and you will always be subject to those delays. While TCP is suitable for non-real time media (playing back stored content and using buffers on the receiver), you should never expect to get a decent real time audio video conference by sending media packets over TCP. I'm not saying that its not possible, because on a private network that you are in 100% control of, you can design to guarantee no network congestion issues will ever occur. However, once you hit the Internet you're basically screwed. 

So I can't fathom why anyone would attempt to so real time audio video conferencing using Websockets (which hijacks HTTP over TCP) over the Internet. While I understand this will solve some traversal issues when UDP is completely blocked, it's just going to end up resulting in a poor user experience. 

However... If DCCP was used instead of TCP, which is unique in that it is a "connected" socket that sends datagram based messages and exposes congestion control up the user space...IMO this could really solve a lot of problems and present some new interesting possibilities, e.g. "Supplying your own congestion control algorithm to do automatic 'downsampling in real time without delays' without transcoding  by using simulcasting (VP8) or H.264 SVC layers and packet forwarding algorithms".....  

That being said, any plans to support DCCP in Webrtc? Curious if any discussion has occurred within the working groups regarding this.  I think the big issue there is not really having a native DCCP stack on windows though :( but at least that has good Linux support. The other downside is that some firewalls/nats may not be familiar with this protocol yet and it's possible you could just be stuck with the same issues as UDP with all your attempts to "connect" and transmit media end up getting blocked :(

Sent from my iPhone

--

[Harald Alvestrand]

Speaking for the standards discussions in the rtc...@ietf.org group:

DCCP was discussed as a candidate for data channel, but was rejected because

a) it doesn't have a reliable mode

b) it had at the time no readily available working open-source userspace implementation

The WG went for SCTP over DTLS over UDP for the data channel, which also offers an unreliable mode (as well as "time-limited retransmission" mode). Since it's over DTLS over UDP, which may in turn be layered over all the tricks we use with ICE, TURN and STUN to get by unfriendly firewalls, we expect to see no more issues with that than we have with media.

Sending media over the data channel isn't supported by the APIs. It will be trivial to do once someone implements the recording spec, but of course with a far from real-time experience.