Which way (SFU or MCU or MESH) BBB uses to set up a video conference ?

[Roy Chan]

I think the question is for WebRTC only. For Flash video sessions, the video will be sent to server using MCU (correct?).

For WebRTC, will the video/audio be transcoded in the server? SFU or MCU or MESH?

Thanks.

[Fred Dixon]

Hi Roy,

> I think the question is for WebRTC only. For Flash video sessions, the video will be sent to server using MCU (correct?).

For Flash-based video, we use the excellent red5 server.  It's been the cornerstone of BigBlueButton since the beginning and it handles re-broadcast of the video streams.  It doesn't process the video, but rather routes the video packets to all the users.  In this sense, it acts as a selected forwarding unit (SFU).

> For WebRTC, will the video/audio be transcoded in the server? SFU or MCU or MESH?

We are using Kurento for handing incoming WebRTC video.  

FreeSWITCH, which we use for WebRTC audio, also supports WebRTC video.  However, it acts as a media control unit (MCU) and decodes the incoming videos, creates a composite video, and re-broadcasts the composite stream.  The creation of a composite video is very CPU intensive, so we decided to explore using an SFU.

We are using Kurento (https://www.kurento.org/) for rebroadcasting the video in the HTML5 client.  Similar to red5, Kurento handles WebRTC video as a SFU.

You can try it yourself at

  https://test.bigbluebutton.org/

We did a quick animated GIF showing the webcam displaying

  https://github.com/bigbluebutton/bigbluebutton/issues/4958#issuecomment-360318788

The development on the HTML5 video is ongoing.  Your millage may vary at test.bigbluebutton.org.  Red5 has been very solid for sharing Flash-based video.  We are working to achieve the same level of stability with WebRTC-based video.

Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[Roy Chan]

Thanks for your detailed answer. I'm a developer and I'm looking to contribute.

Based on your answer, everything is SFU except WebRTC audio? Then I have a question, why use FreeSwitch to composite the audio? As usually the audio should consume small bandwidth (compared to video), it doesn't save much bandwidth using FreeSwitch instead of SFU?

[Fred Dixon]

Hi Roy,

>  Then I have a question, why use FreeSwitch to composite the audio? As usually the audio should consume small bandwidth (compared to video), it doesn't save much bandwidth using FreeSwitch instead of SFU?

Because FreeSWITCH rocks :-).  It does an excellent job mixing the audio (both from the browser and SIP trunking) and we've built upon FreeSWITCH for years . It also handles WebRTC calls directly with all the support for compression and forward error correction.  If you think the audio in BigBlueButton sounds good, it's because of the browsers support for WebRTC audio and FreeSWITCH.

We've been using FreeSWITCH for over six years in the project.   We are always inclined to choose the best tool for the job, and FreeSWITCH (IMHO) is the best tool for handling audio.

Regards,... Fred

On Thu, Jan 25, 2018 at 9:22 PM, Roy Chan <ero...@gmail.com> wrote:

Thanks for your detailed answer. I'm a developer and I'm looking to contribute.

Based on your answer, everything is SFU except WebRTC audio? Then I have a question, why use FreeSwitch to composite the audio? As usually the audio should consume small bandwidth (compared to video), it doesn't save much bandwidth using FreeSwitch instead of SFU?

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[bendark]

hi fred,


why freeswicth doesnt rorck for video,?  you have chosen kurento. i prefer freeswitch for webrtc video.




regards

Am Freitag, 26. Januar 2018 13:08:59 UTC+1 schrieb Fred Dixon:

Hi Roy,

>  Then I have a question, why use FreeSwitch to composite the audio? As usually the audio should consume small bandwidth (compared to video), it doesn't save much bandwidth using FreeSwitch instead of SFU?

Because FreeSWITCH rocks :-).  It does an excellent job mixing the audio (both from the browser and SIP trunking) and we've built upon FreeSWITCH for years . It also handles WebRTC calls directly with all the support for compression and forward error correction.  If you think the audio in BigBlueButton sounds good, it's because of the browsers support for WebRTC audio and FreeSWITCH.

We've been using FreeSWITCH for over six years in the project.   We are always inclined to choose the best tool for the job, and FreeSWITCH (IMHO) is the best tool for handling audio.

Regards,... Fred

On Thu, Jan 25, 2018 at 9:22 PM, Roy Chan <ero...@gmail.com> wrote:

Thanks for your detailed answer. I'm a developer and I'm looking to contribute.

Based on your answer, everything is SFU except WebRTC audio? Then I have a question, why use FreeSwitch to composite the audio? As usually the audio should consume small bandwidth (compared to video), it doesn't save much bandwidth using FreeSwitch instead of SFU?

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[Fred Dixon]

Hi 

> why freeswicth doesnt rorck for video,?  you have chosen kurento. i prefer freeswitch for webrtc video.

What has your experience on the CPU load with FreeSWITCH when you have many webcams shared in a session?

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[Chad Pilkey]

Mixing audio isn't that expensive (low CPU) and it's quick to do (low latency). Currently the bandwidth required for an audio stream is 40-50kbps for each direction (no matter the number of users) which is very small. If we didn't mix audio and there were 50 people in a meeting you'd be looking at 2.5Mbps being sent to each user. The scaling ability for the server would be drastically impacted.

[Insightcollector]

Fred, from earlier development summit videos I was under the impression a MCU solution for HTML5 client video was (back then) your planned approach and I was a bit worried about the CPU requirements for that. Seeing you switched for a SFU solution for HTML5 video seems more realistic. My BBB servers have either 100Mbit or 1Gbit of bandwidth and I have never run into any bandwidth issues but I'm sure I would run into CPU power issues with a MCU solution.

So basically my question is, how will you bring the HTML5 video and the Flash video together, as they are on seperate paths at the moment. Will you have the Flash video also sent to Kurento or will the HTML5 video be sent to Red5? Or is there a third option on how to connect both without an MCU solution?

(Had to repost this, because of the strange fontsize in my previous post)

Am Donnerstag, 25. Januar 2018 16:36:05 UTC+1 schrieb Fred Dixon:

Hi Roy,

> I think the question is for WebRTC only. For Flash video sessions, the video will be sent to server using MCU (correct?).

For Flash-based video, we use the excellent red5 server.  It's been the cornerstone of BigBlueButton since the beginning and it handles re-broadcast of the video streams.  It doesn't process the video, but rather routes the video packets to all the users.  In this sense, it acts as a selected forwarding unit (SFU).

> For WebRTC, will the video/audio be transcoded in the server? SFU or MCU or MESH?

We are using Kurento for handing incoming WebRTC video.  

FreeSWITCH, which we use for WebRTC audio, also supports WebRTC video.  However, it acts as a media control unit (MCU) and decodes the incoming videos, creates a composite video, and re-broadcasts the composite stream.  The creation of a composite video is very CPU intensive, so we decided to explore using an SFU.

We are using Kurento (https://www.kurento.org/) for rebroadcasting the video in the HTML5 client.  Similar to red5, Kurento handles WebRTC video as a SFU.

You can try it yourself at

  https://test.bigbluebutton.org/

We did a quick animated GIF showing the webcam displaying

  https://github.com/bigbluebutton/bigbluebutton/issues/4958#issuecomment-360318788

The development on the HTML5 video is ongoing.  Your millage may vary at test.bigbluebutton.org.  Red5 has been very solid for sharing Flash-based video.  We are working to achieve the same level of stability with WebRTC-based video.

Regards,... Fred

On Thu, Jan 25, 2018 at 6:29 AM, Roy Chan <ero...@gmail.com> wrote:

I think the question is for WebRTC only. For Flash video sessions, the video will be sent to server using MCU (correct?).

For WebRTC, will the video/audio be transcoded in the server? SFU or MCU or MESH?

Thanks.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[Fred Dixon]

Hi Oliver,

> So basically my question is, how will you bring the HTML5 video and the Flash video together, as they are on seperate paths at the moment. Will you have the Flash video also sent to Kurento or will the HTML5 video be sent to Red5? Or is there a third option on how to connect both without an MCU solution?

For the first step, we're working on having Kurento send WebRTC video to red5 (using ffmpeg to bridge the streams), which is important for enabling both Flash and HTML5 client to use WebRTC for screen sharing.

Once you start screen sharing using WebRTC all clients will view it.

That gives us WebRTC -> red5 for desktop sharing.

The next step is to do the above for all webcam streams shared by the HTML5 client.  After that, the next step would be for red5 -> WebRTC.

We're going to focus on the first step.

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[bendark]

hi fred

you're right  freeswitch needs a lot of computing power. a client does not necessarily need this computing power, this only happens with server ( farm of servers) and the client does not need a fast internet connection.

sfu on the other hand needs very fast internet connection.Here we need a very fast internet connection for the server and all clients absolutely needs a fast internet connection.

these two models have their limits.that's how I understand this.


best regards

[Richard Alam]

On Fri, Jan 26, 2018 at 5:16 PM, 'bendark' via BigBlueButton-dev <bigblueb...@googlegroups.com> wrote:

hi fred

you're right  freeswitch needs a lot of computing power. a client does not necessarily need this computing power, this only happens with server ( farm of servers) and the client does not need a fast internet connection.

sfu on the other hand needs very fast internet connection.Here we need a very fast internet connection for the server and all clients absolutely needs a fast internet connection.

these two models have their limits.that's how I understand this.

With sfu, a client can pick and choose which webcam to view. That lowers the bw required by that client. 

With mcu, the server have to mix all streams to create one stream to serve the clients.

With sfu, we have more control on how to serve the streams. Maybe moderators can only view all stream and viewers can only view the presenter stream. etc.

Richard

 

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

--

-----
BigBlueButton Developer
http://www.bigbluebutton.org
https://github.com/bigbluebutton

[bendark]

thanks Richard,

now i understand very well the difference between this two models.
you took the right decision, sfu is the best solution ,its useless to view more than few or 20 webcams at the same time.

congratulations

[Fred Dixon]

Hi Bendark,

BigBlueButton has handled Flash video with red5 as a SFU.  We're going to do the same with WebRTC video and Kurento.

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[Fred Dixon]

Hi Oliver,

> So basically my question is, how will you bring the HTML5 video and the Flash video together, as they are on seperate paths at the moment. Will you have the Flash video also sent to Kurento or will the HTML5 video be sent to Red5? Or is there a third option on how to connect both without an MCU solution?

For the first step, we're working on having the WebRTC video send to red5, which is important for enabling the Flash and HTML5 client to use WebRTC for screen sharing. Once you start screen sharing (using WebRTC) all clients will view it.

That gives us WebRTC -> red5 for desktop sharing and webcams.

The next step would be for red5 -> WebRTC, but we're going to focus on the above first.

Regards,... Fred

On Fri, Jan 26, 2018 at 2:07 PM, Insightcollector <insightc...@t-online.de> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.