An MCU using actual WebRTC libs

[Binary Chopper]

Hi, 

Does anyone know of an MCU which uses the WebRTC libraries for handling the connections and therefore things like 

NACK, FEC, SVC, Bandwidth Control etc would be 100% fully supported and match the quality seen in a p2p call?

The only MCU I can find seem to implement their own versions of the above and therefore never quite get it right.

BC

[Iñaki Baz Castillo]

So if something does not use the "WebRTC libraries" that is not good.
BTW: what is the "WebRTC libraries"?


--
Iñaki Baz Castillo
<i...@aliax.net>

[Jeremy Noring]

On Monday, November 24, 2014 7:39:21 PM UTC-7, Binary Chopper wrote:

Hi, 

Does anyone know of an MCU which uses the WebRTC libraries for handling the connections and therefore things like 

NACK, FEC, SVC, Bandwidth Control etc would be 100% fully supported and match the quality seen in a p2p call?

No, I don't know of any MCU that does this, and I've often wondered why.  Partly because making a full-featured WebRTC stack is not for the faint of heart.  We've been using licode (https://github.com/ging/licode) and it's marginal at best.  

I don't know of any MCU out there for WebRTC that I'd call "good" at this point.  There are only bad and worse.

[Jeremy Noring]

On Tuesday, November 25, 2014 2:55:57 AM UTC-7, Iñaki Baz Castillo wrote:

So if something does not use the "WebRTC libraries" that is not good.
BTW: what is the "WebRTC libraries"?

Go to webrtc.googlecode.com, download, build.  Voila.  WebRTC library that does not suck and actually has tests. 

[Lorenzo Miniero]

Let me act as "Cicero pro domo sua", but have you checked Janus? http://janus.conf.meetecho.com

There's an MCU plugin which may be what you're interested in. Not all of the RTCP stuff you're looking for is handled ATM, though.

Lorenzo

[Sergio Garcia Murillo]

I also would recomend janus if you want a video switching MCU and obviously mine if you want a mixer MCU ;)

http://www.medooze.com/products/mcu.aspx

Until we get SVC (either VP9 or H265) or simulcast in all browsers, which model is best for you will depend greatly on your use case (and resources available).

Best regards
Sergio

--

---
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/d/optout.

[Philipp Hancke]

MCUs... http://www.voipusersconference.org/2014/vuc484-the-future-of-video/ discusses that. Hint: the "MCU" is not the new type of server mentioned, it's a thing from the late 80s.

http://www.slideshare.net/Dialogic/beyond-the-mcu is quite a good presentation, too.

[James Body]

Have you not seen Jitsi Video Bridge (JVB)?  https://jitsi.org/Projects/JitsiVideobridge

We have been using this for a number of months now as our primary WebRTC MCU and have been impressed by it's innovative design (somewhat different to the 'conventional' MCU which results in a much smaller footprint and server load than anything comparable.  Also, we have found the Jitsi team to be incredibly helpful and responsive to change requests ad other feature enhancements.

We have found JVB to be stable enough for us to switch to it from Google Hangout for the weekly VoIP User Conference [ http://vuc.me ].

If you would like to try our bridge out for yourself, drop me a line and I'll give you a tour!

James

[Iñaki Baz Castillo]

2014-11-25 18:44 GMT+01:00 Philipp Hancke <fi...@andyet.net>:
> Hint: the "MCU" is not the new type of server mentioned, it's a thing from
> the late 80s.

Tell me that when browsers do not behave as telephones from the late
80s (specially Firefox which currently just supports one audio track
and one video track, and Chrome implements multiple tracks using the
non standardized Plan-B).

[Sergio Garcia Murillo]

An you will get even more fun when MS/Apple only implement H264.. ;)

BR
Sergio

[LuLop]

Hi,

We have tried to integrate the Chrome WebRTC stack into a media server when it acts in RTP/RTCP terminating mode and our initial conclusions show that it cannot be done in a simple way. The reason is  quite straightforward. The PeerConnection stack embeds encoding and decoding. This means that using directly their API causes every single stream received to be decoded and every single stream sent to be re-encoded. Hence, the number of required transcodings grows linearly with the number of users in the session, which makes impossible any kind of reasonable use case due to scalability issues. It is possible, at least in theory, to make the appropriate plumbing for eliminating the encoding/decoding and linking to your own code so that the stack can send/receive the unencoded media following a traditional SFU or MCU approach, but this requires "cutting" the code at non-standarized interfaces that people at Google can modify at any time (and seem to be modifying frequently) Hence, the maintenance of that code can become a real nightmare and requires additional testing, which makes you loose more of the advantages of using the code. In any case, there are parts of that code that provide a lot of value for an RTP termination and which are not trivial to implement (for example, the bandwidth estimator based on a Kalman filter). For this reason, we are still working on figuring out how this "cutting" could be implemented at least in some parts, but I'm afraid we won't have an answer for tomorrow.

Best

L.

[Iñaki Baz Castillo]

2014-11-25 16:03 GMT+01:00 Jeremy Noring <jeremy...@gmail.com>:
> Go to webrtc.googlecode.com, download, build. Voila. WebRTC library that
> does not suck and actually has tests.

Sorry, I don't like the "mono-culture". Standards are done to allow
multiple implementations. If all the world promotes a "unique" and
"single" code/library then something is going wrong.

And I hope Google WebRTC code do not become "the WebRTC libraries".

[Iñaki Baz Castillo]

2014-11-25 22:15 GMT+01:00 LuLop <lu...@kurento.com>:
> We have tried to integrate the Chrome WebRTC stack into a media server when
> it acts in RTP/RTCP terminating mode and our initial conclusions show that
> it cannot be done in a simple way. The reason is quite straightforward. The
> PeerConnection stack embeds encoding and decoding. This means that using
> directly their API causes every single stream received to be decoded and
> every single stream sent to be re-encoded. Hence, the number of required
> transcodings grows linearly with the number of users in the session, which
> makes impossible any kind of reasonable use case due to scalability issues.
> It is possible, at least in theory, to make the appropriate plumbing for
> eliminating the encoding/decoding and linking to your own code so that the
> stack can send/receive the unencoded media following a traditional SFU or
> MCU approach, but this requires "cutting" the code at non-standarized
> interfaces that people at Google can modify at any time (and seem to be
> modifying frequently) Hence, the maintenance of that code can become a real
> nightmare and requires additional testing, which makes you loose more of the
> advantages of using the code. In any case, there are parts of that code that
> provide a lot of value for an RTP termination and which are not trivial to
> implement (for example, the bandwidth estimator based on a Kalman filter).
> For this reason, we are still working on figuring out how this "cutting"
> could be implemented at least in some parts, but I'm afraid we won't have an
> answer for tomorrow.

I don't think coding an entire WebRTC stack is so hard (assuming we
can use existing SRTP and DTLS libraries). Specific algorithms and
utilities can be taken from other projects, but relying all our
project on a library designed for clients/browsers does not seem a
good approach IMHO.

[Ben Weekes]

If you want the best possible interoperability including SVC and FEC then using WebRTC libs does make sense. Janus NACK/FEC is not sufficient. Try Screen Sharing a high density textual page and experience the freezes which regularly won't recover. Same problem on Jitsi. Chrome P2P can handle it.

I wouldn't recommend the Chrome/Chromium stack but the lower level WebRTC Code base which runs on Linux and Windows.

If you want to avoid transcoding in a peer connection you could implement your own VP8/Opus encode/decode methods which just return the data they are given. 

[Jeremy Noring]

There is nothing about my statement that is promoting a "mono culture"; you are free to use any library you like, and there are multiple options.  I'm merely pointing out that if you want a robust, full-featured library that has significant testing and a chance of surviving in a production environment, I have yet to see anything better than Google's webrtc implementation.  I welcome alternatives.

This is not to say you can't go download erickson's implementation, write your own using libnice/libsrtp/libvpx/openH264/glue code, or rip code out of some other project like Licode.  But none of this implies I'm advocating a "mono culture"

 

[Faraz Khan]

Screenhero does do exactly this - Our group sharing server utilizes webrtc libraries to give you the group 'sharing' experience. Though I can't share the actual code I'll be willing to help out anybody who is planning on going down this path. Using webrtc let us get an awesome group sharing experience VERY quickly (since they've done a lot of the low level work!).  High level highlights:

1. Uses peerconnection to establish n connections out to hosts

2. For audio conferencing, we use webrtcvoiceengine directly (not through peerconnection audio track) and send data over RTP Data channel. The server simply broadcasts these opus rtp packets out and we are able to decode them on the other side and manually pass them to webrtcvoiceengine. This works beautifully as webrtc mixes the different streams itself.

3. For video conferencing, we simply use the video track API. As someone state, this is technically wasteful (you transcode n times) but in our case its a very small hit since we HAVE to transcode for our screensharing component anyways

4. For screen 'conferencing' we use a custom system involving x264 which goes over the RTPDatachannels

Do note that this solution is incompatible with the browser since we do custom stuff so it might not be that useful to you guys- but webrtc has saved us thousands of manhours with their superior implementations of things like the bitrate estimator, audio mixing, Peerconnection NAT traversal, SCTP etc.

[Ivaylo Tsankov]

It is not so hard to use WebRTC to build a server app. The interface of PeerConenction allows you to add custom encoder/decoder factory which allows you to create your own encoder/decoder to control video stream. It is the same for audio connections. You can create your own Audio device module and control audio stream (process, proxify, etc...).

[Matthew Fredrickson]

Response inline.

On Wednesday, November 26, 2014 4:17:14 AM UTC-6, Iñaki Baz Castillo wrote:

I don't think coding an entire WebRTC stack is so hard (assuming we
can use existing SRTP and DTLS libraries). Specific algorithms and
utilities can be taken from other projects, but relying all our
project on a library designed for clients/browsers does not seem a
good approach IMHO.  

The standards defined portions of it are not TOO bad but anything involving media processing, encoding, or decoding is not easy.  So echo cancellation, A/V synchronization, other audio and video processing - those are the challenging portions.  I have worked on echo cancellers for a number of years, and most of the time it's a black art getting them working well in general use cases.

Matthew Fredrickson

respoke.io

[Henry Stewart]

Has anyone tried the MCU offered by Intel: https://software.intel.com/sites/landingpage/webrtc/

I've tried using tools like Kurento & Jitsi. While they appear to have rich feature sets, in practice I've found them to be unreliable or poorly documented (esp. the Jitsi videobridge). 

Has anyone had any experience with MCU in production using paid services or open source services?

[Alexandre GOUAILLARD]

our experience with the jitsi video bridge started like yours, however, when we contacted them, they graciously offered to help us setting it up, for us to then benchmark it. Their lack of documentation is more than compensated by the contact experience, at least in our case.

--

---
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/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Luis Lopez]

Hi,

In the case of Kurento, there are many customers using successfully Kurento in production, but probably you should refer better to the Kurento public mailing list for issuing such question. 

In addition, Kurento has a very aggressive release plan for the next few months. This week v5.1.0 has been issued with lots of bug fixes and congestion control support. Trickle ICE and transcoding supported simulcast (which is what you need for your use case) is on the way for next month.

Luis Lopez
Kurento.org Project Coordinator
+34 914 888 713 • lu...@kurento.com • prof.luis.lopez • • • •

---

Best WoW Factor Award at WebRTC Conference & Expo 2014 (California)

Audience Choice Award at WebRTC Conference & Expo 2014 (California)

Best of Show Award at WebRTC conference expo 2014 (Paris)

[Emil Ivov]

Hey Henry,

You are welcome to share your experience on our mailing lists ( https://jitsi.org/lists ). They certainly differ from those of the majority of our users so maybe there is a problem woth tour setup.

Hope this helps,

Emil

--

---
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/d/optout.

--
--sent from my mobile

[Paul Kon]

Is it feasible to have a simple SFU like setup with 500+ simultaneous connections using Jitsi or Kurento? I'd like to work on something like this however the open source servers seem to be in an alpha state whereas the PaaS services aren't in budget at moderate scale and beyond.

The Intel MCU seems to be a repackaged licode server from the source.

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

For more options, visit https://groups.google.com/d/optout.

[Emil Ivov]

Hey Paul,

On Thu, Feb 26, 2015 at 11:23 AM, Paul Kon <paul...@gmail.com> wrote:
> Is it feasible to have a simple SFU like setup with 500+ simultaneous
> connections using Jitsi or Kurento?

As far as Jitsi is concerned:

https://jitsi.org/videobridge/performance

> I'd like to work on something like this
> however the open source servers seem to be in an alpha state

I wouldn't claim that we are perfect but Jitsi Videobridge is running
in production on quite a few services and alpha is certainly not it's
state. Of course, if you are having difficulties, you are very welcome
to get in touch with us on our mailing lists:

https://jitsi.org/lists

Cheers,
Emil

>>> email to discuss-webrt...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> --sent from my mobile
>

> --
>
> ---
> 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/d/optout.



--

https://jitsi.org

[Alexandre GOUAILLARD]

From our experience, the jitsi bridge seems more stable than the kurento server at this point, if we were to compare only those two. For the simplest use case janus, meedoze, licode, and other would do, for more specific use case, only one would stand out. It s mainly about defining what you want first, than comparing solutions in a vacuum though.

You mentioned that PaaS are not in your budget, could you give example so we can document that for users who would ask the same question in the future?

- which PaaS are you referring to (can refers to any in tsahi list for example)?

- what is your use case (how many calls with how many people each, audio only or video, resolution, ...) ?

- what would be the cost with the PaaS?

- what is the cost with say a jitsi computer (with a max of 1000 connections, and the numbers provided by emil in the performance url) (including bandwidth cost and hosting costs).

From our experience, even without including the maintenance and dev cost, the total cost being related to bandwidth, the cost end up not being significantly different. I would be happy to be given a counter example and proven wrong. The rabbit guys recently mentioned that moving from one host to another, with different bandwidth cost made a big difference for them (they have a in house developed webrtc SFU).

Alex.

[Tom Sheffler]

I'd take a look at Kurento

http://www.kurento.org/

On Monday, November 24, 2014 at 6:39:21 PM UTC-8, Binary Chopper wrote: