Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mediasoup – WebRTC Video Conferencing

mediasoup.org

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Mediasoup – WebRTC Video Conferencing

#51

Post by manthideaal »

supermatt wrote: post #40
manthideaal wrote: post #35

To understand the terms: webrtc, stun, turn, mesh, sfu, mcu, ice and trickle ice, there is (1). 15 minutes to understand what is all this about. What about IPv6 stun and turn?, it seems other people asked the same idea I thought: (2) bout all of this, one is the answer is: As IPv6 takes over the complexity of new networks, STUN and ICE will become irrelevant. I think that with the surge in video conferences and rtc,…

addressable !== routeable !== reachable. IPv6 will certainly REDUCE the need for STUN, but there are still (many) cases where you don't want to be "reachable by default", in which case you need a stable reference for negotiating routing and reachability (e.g. STUN).

IPv6 could have and address for "reachable by default", I find that very useful, also IPv6 allow many addresses so that is not wasteful.

Re: Mediasoup – WebRTC Video Conferencing

#52

Post by sandGorgon »

ibc wrote: post #31
sandGorgon wrote: post #6

any comparisons with jitsi ? really would like to understand how these technologies stack against each other. jitsi has been production tested far longer i suppose, through its freely available videoconferencing service https://meet.jit.si/

mediasoup co-author here. Comparing Jitsi with mediasoup is like comparing Netflix (backend + apps) with Express.js + libcurl. Jitsi developers may replace their RTC core internals (including the SFU) with mediasoup + mediasoup-client and you wouldn't even realize of it. Hope this helps.

Thanks for this. Do you plan to go higher in the stack and release components to get-started-quickly ?

Re: Mediasoup – WebRTC Video Conferencing

#53

Post by ibc »

manthideaal wrote: post #50
ibc wrote: post #47

Earlier quoted context omitted.

Thanks for the SPAM. Let's talk about whatever you wish to say.

In order to send a datagram to multiple IP the first, and naive idea, one can think of is to change the datagram protocol to allow for multiple destination. Today, 2020, is the right time. I am thinking about platforms that have hundred or thousand of simultaneous receiving ends, so that the branching point occurs near the destination. Again, googling this proposal is not new (1) RFC 1770, category informational. Edi…

Again, thanks for the SPAM.

And you are wrong. RTP video cannot be sent that way because each receiver must also send back feedback to the sender. RTP protocol is more complex than just sending UDP packets everywhere.

Re: Mediasoup – WebRTC Video Conferencing

#54

Post by ibc »

sandGorgon wrote: post #52
ibc wrote: post #31

Earlier quoted context omitted.

mediasoup co-author here. Comparing Jitsi with mediasoup is like comparing Netflix (backend + apps) with Express.js + libcurl. Jitsi developers may replace their RTC core internals (including the SFU) with mediasoup + mediasoup-client and you wouldn't even realize of it. Hope this helps.

Thanks for this. Do you plan to go higher in the stack and release components to get-started-quickly ?

Not at all.

Re: Mediasoup – WebRTC Video Conferencing

#55

Post by manthideaal »

ibc wrote: post #53
manthideaal wrote: post #50

Earlier quoted context omitted.

In order to send a datagram to multiple IP the first, and naive idea, one can think of is to change the datagram protocol to allow for multiple destination. Today, 2020, is the right time. I am thinking about platforms that have hundred or thousand of simultaneous receiving ends, so that the branching point occurs near the destination. Again, googling this proposal is not new (1) RFC 1770, category informational. Edi…

Again, thanks for the SPAM. And you are wrong. RTP video cannot be sent that way because each receiver must also send back feedback to the sender. RTP protocol is more complex than just sending UDP packets everywhere.

Each receiver sending feedback does not prevent the server for using datagrams with multiple destinations. I can see that each peer use a different resolution and bitrate but that is another layer, is like sending information at several resolutions and each peer selecting the best one.

Edited: I must learn something about multicast in IPv6, the idea seems interesting.

Re: Mediasoup – WebRTC Video Conferencing

#56

Post by ibc »

manthideaal wrote: post #55
ibc wrote: post #53

Earlier quoted context omitted.

Again, thanks for the SPAM. And you are wrong. RTP video cannot be sent that way because each receiver must also send back feedback to the sender. RTP protocol is more complex than just sending UDP packets everywhere.

Each receiver sending feedback does not prevent the server for using datagrams with multiple destinations. I can see that each peer use a different resolution and bitrate but that is another layer, is like sending information at several resolutions and each peer selecting the best one. Edited: I must learn something about multicast in IPv6, the idea seems interesting.

> is like sending information at several resolutions and each peer selecting the best one.

Well, no. This is not about sending all video layers to all receivers and let them choose which one to render. Not al all.

The purpose of video simulcast/SVC is the opposite: make the SFU decide (based on estimated per receiver bandwidth or whatever) which video layers to deliver to each receiver, so a HQ video of 8 mbps does not break your Internet downlink (you just receive the lowest video layer which is 1 mbps, for example).

And more important: no, the server can not send the same UDP datagram (the same RTP packet) to all receivers. The server needs a different RTP sequence number count and a different SRTP encryption keys with each receiver.

I'm afraid this is not so easy as you say, not at all.

BTW: Do you want to say something about mediasoup? or just about your stuff?

Re: Mediasoup – WebRTC Video Conferencing

#57

Post by supermatt »

ibc wrote: post #49
supermatt wrote: post #48

Earlier quoted context omitted.

Maybe I could allocate a port to use for an additional low priority tcp candidate via configuration, or would I need to dive into the code for this? For example, I could supply the generated udp and tcp candidates in addition to a tcp:443? What are your thoughts?

You cannot select a specific listening port for a specific transport, because each WebRTC transport requires, at least, a different listening port in the server: https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc... YouIf you want to listen in TLS 443 for all clients, add a TURN server into your backend. Just that.

Is there a reason for the restriction of one connection per port? I would have thought you would be able to use the same port for each peer source ip/port tuple?

Not doubting you - but I never experienced this limitation with other client/server applications. I have an http server serving over 200k concurrent websockets on port 443, for example.

I'm happy to help out with this if I can.

Re: Mediasoup – WebRTC Video Conferencing

#58

Post by ibc »

supermatt wrote: post #57
ibc wrote: post #49

Earlier quoted context omitted.

You cannot select a specific listening port for a specific transport, because each WebRTC transport requires, at least, a different listening port in the server: https://mediasoup.org/documentation/v3/mediasoup/api/#WebRtc... YouIf you want to listen in TLS 443 for all clients, add a TURN server into your backend. Just that.

Is there a reason for the restriction of one connection per port? I would have thought you would be able to use the same port for each peer source ip/port tuple? Not doubting you - but I never experienced this limitation with other client/server applications. I have an http server serving over 200k concurrent websockets on port 443, for example. I'm happy to help out with this if I can.

Majority of RTP media server listen into a separate port for each connection. That's how RTP typically works. This is not TCP connections.

Re: Mediasoup – WebRTC Video Conferencing

#59

Post by manthideaal »

ibc wrote: post #56
manthideaal wrote: post #55

Earlier quoted context omitted.

Each receiver sending feedback does not prevent the server for using datagrams with multiple destinations. I can see that each peer use a different resolution and bitrate but that is another layer, is like sending information at several resolutions and each peer selecting the best one. Edited: I must learn something about multicast in IPv6, the idea seems interesting.

> is like sending information at several resolutions and each peer selecting the best one. Well, no. This is not about sending all video layers to all receivers and let them choose which one to render. Not al all. The purpose of video simulcast/SVC is the opposite: make the SFU decide (based on estimated per receiver bandwidth or whatever) which video layers to deliver to each receiver, so a HQ video of 8 mbps does n…

Thanks for all the info. I think that mediasoup is a very good SFU. I wish you the best and I hope mediasoup SFU to become a crucial tool for rtc.

Edited: In a recent article (1) it seems that multicast is better than SFU in webrtc. In the PhD. Thesis (2) a hybrid model is used: Hybrid multicast-unicast video streaming over heterogenous cellular networks.

(1)https://ieeexplore.ieee.org/document/8811590 (2) https://summit.sfu.ca/item/16802

Re: Mediasoup – WebRTC Video Conferencing

#60

Post by supermatt »

ibc wrote: post #58
supermatt wrote: post #57

Earlier quoted context omitted.

Is there a reason for the restriction of one connection per port? I would have thought you would be able to use the same port for each peer source ip/port tuple? Not doubting you - but I never experienced this limitation with other client/server applications. I have an http server serving over 200k concurrent websockets on port 443, for example. I'm happy to help out with this if I can.

Majority of RTP media server listen into a separate port for each connection. That's how RTP typically works. This is not TCP connections.

rfc3550 states that it is per destination ip/port tuple. So you should be able to support multiple connections per local port. Is it possible this is an oversight in the current implementation? I appreciate this isn’t TCP, which is why I have just read through all relevant RFCs.
Post reply on HN