make janus better on side client

[hassine...@gmail.com]

Hello ,
today , I deployed Janus on a local server and I tested it for 8 participants in a room . 
further than 6 participant  , video and audio was getting worse. and it is was remarkable that janus was not consuming a lot of resources while the browser ( Firefox ) was consuming a lot of resources . It is so obvious since Janus is an SFU . so the server just forwards flows and the browser does all the work ( decoding , displaying .... )
Is there a solution to make this better thus we can go with more participants with a nice QoS
Thank you very much

[Lorenzo Miniero]

That depends on a lot of factors. If you're forcing a too high bandwidth for publishers, viewers may not have enough bandwidth to receive all those streams, and so you should reduce that. The simulcast PR (https://github.com/meetecho/janus-gateway/pull/944/) may also help with that, although you should beware that it's still WIP. If the bandwidth is already low enough and it's simply a matter of CPU on the client, you can try reducing the number of subscriptions, and dynamically switching the source of each of those (see "switch" command), e.g., basing on who's speaking and stuff like that.

L.

[Firas Abd Alrahman]

if you are using audiobridge plugin then you will not face client side issue, as janus do the mixing operation and provide 1 stream, client encode one stream even for any number of room users.

VideoRoom plugin does not provide mixing feature like audiobridge so you can not depend on it for more than 6 users ( it is commented here https://janus.conf.meetecho.com/videoroomtest.html)

[Lorenzo Miniero]

The limit of 6 is just in the demo to make it easier. Nowhere we say that beyond 6 users bad things happen.

L.

Il 10 lug 2017 9:36 PM, "Firas Abd Alrahman" <doo...@gmail.com> ha scritto:

if you are using audiobridge plugin then you will not face client side issue, as janus do the mixing operation and provide 1 stream, client encode one stream even for any number of room users.

VideoRoom plugin does not provide mixing feature like audiobridge so you can not depend on it for more than 6 users ( it is commented here https://janus.conf.meetecho.com/videoroomtest.html)

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

[Firas Abd Alrahman]

I already tried when you reach 5 streams, browser consume the cpu and things become slower (it is about end user hardware)

This can be useful:

http://blog.mgechev.com/2014/12/26/multi-user-video-conference-webrtc-angularjs-yeoman/ 

find ==> Full-mesh limitations

[hassine...@gmail.com]

On Monday, July 10, 2017 at 7:23:52 PM UTC+2, Lorenzo Miniero wrote:

That depends on a lot of factors. If you're forcing a too high bandwidth for publishers, viewers may not have enough bandwidth to receive all those streams, and so you should reduce that. The simulcast PR (https://github.com/meetecho/janus-gateway/pull/944/) may also help with that, although you should beware that it's still WIP. If the bandwidth is already low enough and it's simply a matter of CPU on the client, you can try reducing the number of subscriptions, and dynamically switching the source of each of those (see "switch" command), e.g., basing on who's speaking and stuff like that.

L.

 I had not change anything about bandwith ( i used the default one ) . 
Exactly as Firas said : "browser consume the cpu and things become slower (it is about end user hardware)" . I don't think reducing number of subscriptions is a fundamental and good solution in my case ( i want to keep all subscriptions and go with the maximum number of publishers .
In fact can I do the encodind and decoding in the janus server rather than in the user browser ?!
Thank you very much

[Firas Abd Alrahman]

Yes Hussaine, Please read the link I provided, you are creating a mesh network every user has n-1 peer, it means browser do n-1 encoding/decoding for video, browser get very bad after 6, maybe less maybe more, it is about end-user hardware. but more than 6 is not recommended.

so if you want to use janus with exist solutions/plugins you need to make some limitation for video chat (per my information), but audio limitation will be about server as heavy operations happen there.

Janus does not do anything with video, janus just relay "No mixing is involved: all media are just relayed in a publisher/subscriber approach"

What should happens here, all video streams go to server, server mix all video together with one video, end-user encode/decode one stream, you need something here I do not know if it is exists in Janus gateway, someone will provide you more information but

it should not be as easy as audio.

[Chad Phillips]

For you folks that are advising to not use more than 6 streams, I have to disagree with you.

I've run many, many group videoconferences through Janus with 8 people, and it works completely fine. I believe I could probably push that to 10 with further tweaking.

On occasion, there will be a client joined whose hardware struggles to keep up, in which case they have an option to switch to a 'low quality' option where they receive QQVGA quality streams (not ideal, but fine in a pinch). My regular users have QVGA streams, which sounds like too low a resolution, but actually looks fine when you consider that, if all feeds are the same size, when you get to 8 they are already a bit on the small side.

If you want to send HD feeds, do something more like Google Hangouts, with the one large video and the filmstrip. You can use the switch command to ensure the person in the large feed is HD, and the thumbnail users are QQGVA.

Of course to pull off switching subscriber resolutions, you'll need to send multiple resolutions from each publisher, this is fairly trivial to do.

[Ancor Gonzalez Sosa]

We use a janus-based web-app called Jangouts[1] and we hold meetings with up to 20 participants every day with no hassle (even several big meetings concurrently in the same server).

Of course, the bitrate of the room is quite low, which helps not only with the bandwidth but also saving CPU when rendering the videos in the browser. 64Kbps is enough to have a conversation (take into account that most Firefox browsers would ignore that limit by default and transmit to 200Kbps unless configured otherwise).

Anyways, Jangouts have a mode to "disable video thumbnails" that saves a lot of CPU because it only renders the video of the person who is speaking (silent participants are visualized as a constant stream of pictures, enough to know if they are still alive).

So definitely it's not a Janus limit, it's just a matter of balancing the bitrate of the videos, the number of videos and the CPU power of the clients.

Cheers

[1] https://github.com/jangouts/jangouts/

[Lorenzo Miniero]

The simulcast branch will make that even easier, as the multiple contributions will be bundled, and changes will also happen automatically.

L.

[Firas Abd Alrahman]

Thank you for information, my test was limited to some labtops in office and I used default settings.

It is very good to reach 10-20, it should be enough in most cases.