[jitsi-dev] simulcast effect and video quality issue


#1

Hello, experts:
My recent study on the simulcast found that there are two effect after enabling simulcast:
1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
2). The video quality on all browsers are worse than when simulcast was disabled.
I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot of nload on my hosted jitsi-meet server:Turn on simulcast:
    adaptiveSimulcast: true, enableSimulcast: true
Turn off simulcast: enableSimulcast: false
Also please see attachment for bandwidth cost snapshot from server.Please kindly let me know if this is as expected and what I've missed from configuration perspective.

Thanks and Best RegardsYanchong Wang


#2

Hello WangYanchong,

The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:

- an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.

With adaptive simulcast the 2nd rule is enhanced like this:

- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.

The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:

adaptiveSimulcast: false,
enableSimulcast: true

Hope this helps.

Best regards,
George

···

On 04 Dec 2014, at 09:49, WangYanchong <wangyanchong@hotmail.com> wrote:

Hello, experts:

My recent study on the simulcast found that there are two effect after enabling simulcast:

1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.

2). The video quality on all browsers are worse than when simulcast was disabled.

I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot of nloadon my hosted jitsi-meet server:
Turn on simulcast:

    adaptiveSimulcast: true,
    enableSimulcast: true

Turn off simulcast:
   enableSimulcast: false

Also please see attachment for bandwidth cost snapshot from server.
Please kindly let me know if this is as expected and what I've missed from configuration perspective.

Thanks and Best Regards
Yanchong Wang
<no_simulcast.jpg><simulcast.jpg>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Thanks for your answer, George.I've just followed your advice to only turn on basic simulcast as such in config.js:"adaptiveSimulcast: false,
enableSimulcast: true"Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.Please my two snapshot pictures for bandwith monitor.
Best Regardsyanchong

···

---------------------------------
Hello WangYanchong,

The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:

- an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.

With adaptive simulcast the 2nd rule is enhanced like this:

- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.

The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:

adaptiveSimulcast: false,
enableSimulcast: true

Hope this helps.

Best regards,
George
Thanks and Best RegardsYanchong Wang

From: wangyanchong@hotmail.com
To: dev@jitsi.org
Subject: simulcast effect and video quality issue
Date: Thu, 4 Dec 2014 08:49:14 +0000

Hello, experts:
My recent study on the simulcast found that there are two effect after enabling simulcast:
1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
2). The video quality on all browsers are worse than when simulcast was disabled.
I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot of nload on my hosted jitsi-meet server:Turn on simulcast:
    adaptiveSimulcast: true, enableSimulcast: true
Turn off simulcast: enableSimulcast: false
Also please see attachment for bandwidth cost snapshot from server.Please kindly let me know if this is as expected and what I've missed from configuration perspective.

Thanks and Best RegardsYanchong Wang


#4

Hello Yanchong,

Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:

Best regards,
George

···

On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:

Thanks for your answer, George.
I've just followed your advice to only turn on basic simulcast as such in config.js:
"adaptiveSimulcast: false,
enableSimulcast: true"

Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.

Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
Please my two snapshot pictures for bandwith monitor.

Best Regards
yanchong

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

Hello WangYanchong,

The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:

- an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.

With adaptive simulcast the 2nd rule is enhanced like this:

- an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.

The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:

adaptiveSimulcast: false,
enableSimulcast: true

Hope this helps.

Best regards,
George

Thanks and Best Regards
Yanchong Wang

From: wangyanchong@hotmail.com
To: dev@jitsi.org
Subject: simulcast effect and video quality issue
Date: Thu, 4 Dec 2014 08:49:14 +0000

Hello, experts:

My recent study on the simulcast found that there are two effect after enabling simulcast:

1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.

2). The video quality on all browsers are worse than when simulcast was disabled.

I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
Turn on simulcast:

    adaptiveSimulcast: true,
    enableSimulcast: true

Turn off simulcast:
   enableSimulcast: false

Also please see attachment for bandwidth cost snapshot from server.
Please kindly let me know if this is as expected and what I've missed from configuration perspective.

Thanks and Best Regards
Yanchong Wang
<simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

George:
Thanks for your kindly explanation!Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)

Thanks and Best RegardsYanchong Wang

-----------------------------------From: gp@jitsi.orgDate: Fri, 5 Dec 2014 10:45:14 +0100To: dev@jitsi.orgSubject: Re: [jitsi-dev] simulcast effect and video quality issue
Hello Yanchong,
Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
Best regards,George

···

On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:

Thanks for your answer, George.> I've just followed your advice to only turn on basic simulcast as such in config.js:> "adaptiveSimulcast: false,> enableSimulcast: true"> > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.> > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.> Please my two snapshot pictures for bandwith monitor.> > Best Regards> yanchong> > > > ---------------------------------> > Hello WangYanchong,> > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:> > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.> - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.> > With adaptive simulcast the 2nd rule is enhanced like this:> > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.> > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:> > adaptiveSimulcast: false,> enableSimulcast: true> > Hope this helps.> > Best regards,> George> > > Thanks and Best Regards> Yanchong Wang> > > From: wangyanchong@hotmail.com> To: dev@jitsi.org> Subject: simulcast effect and video quality issue> Date: Thu, 4 Dec 2014 08:49:14 +0000> > Hello, experts:> > My recent study on the simulcast found that there are two effect after enabling simulcast:> > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.> > 2). The video quality on all browsers are worse than when simulcast was disabled.> > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:> Turn on simulcast:> > adaptiveSimulcast: true,> enableSimulcast: true> > Turn off simulcast:> enableSimulcast: false> > Also please see attachment for bandwidth cost snapshot from server.> Please kindly let me know if this is as expected and what I've missed from configuration perspective.> > > > Thanks and Best Regards> Yanchong Wang> <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________> dev mailing list> dev@jitsi.org> Unsubscribe instructions and other list options:> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________dev mailing listdev@jitsi.orgUnsubscribe instructions and other list options:http://lists.jitsi.org/mailman/listinfo/dev


#6

Hello Yanchong,

With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.

You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.

Best regards,
George

···

On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:

George:

Thanks for your kindly explanation!
Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.

I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)

Thanks and Best Regards
Yanchong Wang

-----------------------------------
From: gp@jitsi.org
Date: Fri, 5 Dec 2014 10:45:14 +0100
To: dev@jitsi.org
Subject: Re: [jitsi-dev] simulcast effect and video quality issue

Hello Yanchong,

Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:

Best regards,
George

On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:

> Thanks for your answer, George.
> I've just followed your advice to only turn on basic simulcast as such in config.js:
> "adaptiveSimulcast: false,
> enableSimulcast: true"
>
> Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
>
> Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> Please my two snapshot pictures for bandwith monitor.
>
> Best Regards
> yanchong
>
>
>
> ---------------------------------
>
> Hello WangYanchong,
>
> The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
>
> - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
>
> With adaptive simulcast the 2nd rule is enhanced like this:
>
> - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
>
> The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
>
> adaptiveSimulcast: false,
> enableSimulcast: true
>
> Hope this helps.
>
> Best regards,
> George
>
>
> Thanks and Best Regards
> Yanchong Wang
>
>
> From: wangyanchong@hotmail.com
> To: dev@jitsi.org
> Subject: simulcast effect and video quality issue
> Date: Thu, 4 Dec 2014 08:49:14 +0000
>
> Hello, experts:
>
> My recent study on the simulcast found that there are two effect after enabling simulcast:
>
> 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
>
> 2). The video quality on all browsers are worse than when simulcast was disabled.
>
> I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> Turn on simulcast:
>
> adaptiveSimulcast: true,
> enableSimulcast: true
>
> Turn off simulcast:
> enableSimulcast: false
>
> Also please see attachment for bandwidth cost snapshot from server.
> Please kindly let me know if this is as expected and what I've missed from configuration perspective.
>
>
>
> Thanks and Best Regards
> Yanchong Wang
> <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

George:
Thanks for your answer! From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.
For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.

Thanks and Best RegardsYanchong Wang

···

From: gp@jitsi.org
Date: Thu, 11 Dec 2014 09:52:39 +0100
To: dev@jitsi.org
Subject: Re: [jitsi-dev] simulcast effect and video quality issue

Hello Yanchong,

With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.

You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.

Best regards,
George

On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:

> George:
>
> Thanks for your kindly explanation!
> Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
>
> I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
>
>
> Thanks and Best Regards
> Yanchong Wang
>
>
>
> -----------------------------------
> From: gp@jitsi.org
> Date: Fri, 5 Dec 2014 10:45:14 +0100
> To: dev@jitsi.org
> Subject: Re: [jitsi-dev] simulcast effect and video quality issue
>
> Hello Yanchong,
>
> Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
>
> Best regards,
> George
>
> On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
>
> > Thanks for your answer, George.
> > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > "adaptiveSimulcast: false,
> > enableSimulcast: true"
> >
> > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> >
> > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > Please my two snapshot pictures for bandwith monitor.
> >
> > Best Regards
> > yanchong
> >
> >
> >
> > ---------------------------------
> >
> > Hello WangYanchong,
> >
> > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> >
> > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> >
> > With adaptive simulcast the 2nd rule is enhanced like this:
> >
> > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> >
> > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> >
> > adaptiveSimulcast: false,
> > enableSimulcast: true
> >
> > Hope this helps.
> >
> > Best regards,
> > George
> >
> >
> > Thanks and Best Regards
> > Yanchong Wang
> >
> >
> > From: wangyanchong@hotmail.com
> > To: dev@jitsi.org
> > Subject: simulcast effect and video quality issue
> > Date: Thu, 4 Dec 2014 08:49:14 +0000
> >
> > Hello, experts:
> >
> > My recent study on the simulcast found that there are two effect after enabling simulcast:
> >
> > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> >
> > 2). The video quality on all browsers are worse than when simulcast was disabled.
> >
> > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > Turn on simulcast:
> >
> > adaptiveSimulcast: true,
> > enableSimulcast: true
> >
> > Turn off simulcast:
> > enableSimulcast: false
> >
> > Also please see attachment for bandwidth cost snapshot from server.
> > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> >
> >
> >
> > Thanks and Best Regards
> > Yanchong Wang
> > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hello Yanchong,

In webrtc-internals page, as a sender, you’ll *always* see only *one* outgoing video stream. If the available send bandwidth (as reported in your stats for bweforvideo) is above 250-300 Kbps, then you should be streaming 2 video streams, the always-on low quality one targeting 180p, and a high quality one targeting 360p (you can check that with Wireshark).

Best regards,
George

···

On 11 Dec 2014, at 14:16, WangYanchong <wangyanchong@hotmail.com> wrote:

George:

Thanks for your answer!
From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.

For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.

Thanks and Best Regards
Yanchong Wang

> From: gp@jitsi.org
> Date: Thu, 11 Dec 2014 09:52:39 +0100
> To: dev@jitsi.org
> Subject: Re: [jitsi-dev] simulcast effect and video quality issue
>
> Hello Yanchong,
>
> With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.
>
> You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.
>
> Best regards,
> George
>
> On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:
>
> > George:
> >
> > Thanks for your kindly explanation!
> > Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> > However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
> >
> > I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
> >
> >
> > Thanks and Best Regards
> > Yanchong Wang
> >
> >
> >
> > -----------------------------------
> > From: gp@jitsi.org
> > Date: Fri, 5 Dec 2014 10:45:14 +0100
> > To: dev@jitsi.org
> > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> >
> > Hello Yanchong,
> >
> > Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
> >
> > Best regards,
> > George
> >
> > On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
> >
> > > Thanks for your answer, George.
> > > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > > "adaptiveSimulcast: false,
> > > enableSimulcast: true"
> > >
> > > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> > >
> > > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > > Please my two snapshot pictures for bandwith monitor.
> > >
> > > Best Regards
> > > yanchong
> > >
> > >
> > >
> > > ---------------------------------
> > >
> > > Hello WangYanchong,
> > >
> > > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> > >
> > > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> > >
> > > With adaptive simulcast the 2nd rule is enhanced like this:
> > >
> > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> > >
> > > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> > >
> > > adaptiveSimulcast: false,
> > > enableSimulcast: true
> > >
> > > Hope this helps.
> > >
> > > Best regards,
> > > George
> > >
> > >
> > > Thanks and Best Regards
> > > Yanchong Wang
> > >
> > >
> > > From: wangyanchong@hotmail.com
> > > To: dev@jitsi.org
> > > Subject: simulcast effect and video quality issue
> > > Date: Thu, 4 Dec 2014 08:49:14 +0000
> > >
> > > Hello, experts:
> > >
> > > My recent study on the simulcast found that there are two effect after enabling simulcast:
> > >
> > > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> > >
> > > 2). The video quality on all browsers are worse than when simulcast was disabled.
> > >
> > > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > > Turn on simulcast:
> > >
> > > adaptiveSimulcast: true,
> > > enableSimulcast: true
> > >
> > > Turn off simulcast:
> > > enableSimulcast: false
> > >
> > > Also please see attachment for bandwidth cost snapshot from server.
> > > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> > >
> > >
> > >
> > > Thanks and Best Regards
> > > Yanchong Wang
> > > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

George:
I'am running a virtualbox VM hosting one jitsi-meet server, so I assume the bandwidth from my laptop to it will be at least 10Mbps, but the "bweforvideo" in webrtc-internals show only a statistic graph of 300k bps. Not sure how it is calculated. See my attachment for snapshot.
For download perspective: Is there another bandwidth reference similiar to "bweforvideo" that can guide the resolution of high quality stream, plus the number of low quality streams to download? I am not sure if it has relation with the server side focus discussion.

Thanks and Best RegardsYanchong Wang

···

From: gp@jitsi.org
Date: Thu, 11 Dec 2014 14:24:30 +0100
To: dev@jitsi.org
Subject: Re: [jitsi-dev] simulcast effect and video quality issue

Hello Yanchong,

In webrtc-internals page, as a sender, you’ll *always* see only *one* outgoing video stream. If the available send bandwidth (as reported in your stats for bweforvideo) is above 250-300 Kbps, then you should be streaming 2 video streams, the always-on low quality one targeting 180p, and a high quality one targeting 360p (you can check that with Wireshark).

Best regards,
George

On 11 Dec 2014, at 14:16, WangYanchong <wangyanchong@hotmail.com> wrote:

> George:
>
> Thanks for your answer!
> From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.
>
> For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.
>
>
> Thanks and Best Regards
> Yanchong Wang
>
>
> > From: gp@jitsi.org
> > Date: Thu, 11 Dec 2014 09:52:39 +0100
> > To: dev@jitsi.org
> > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> >
> > Hello Yanchong,
> >
> > With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.
> >
> > You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.
> >
> > Best regards,
> > George
> >
> > On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:
> >
> > > George:
> > >
> > > Thanks for your kindly explanation!
> > > Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> > > However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
> > >
> > > I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
> > >
> > >
> > > Thanks and Best Regards
> > > Yanchong Wang
> > >
> > >
> > >
> > > -----------------------------------
> > > From: gp@jitsi.org
> > > Date: Fri, 5 Dec 2014 10:45:14 +0100
> > > To: dev@jitsi.org
> > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > >
> > > Hello Yanchong,
> > >
> > > Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
> > >
> > > Best regards,
> > > George
> > >
> > > On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
> > >
> > > > Thanks for your answer, George.
> > > > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > > > "adaptiveSimulcast: false,
> > > > enableSimulcast: true"
> > > >
> > > > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> > > >
> > > > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > > > Please my two snapshot pictures for bandwith monitor.
> > > >
> > > > Best Regards
> > > > yanchong
> > > >
> > > >
> > > >
> > > > ---------------------------------
> > > >
> > > > Hello WangYanchong,
> > > >
> > > > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> > > >
> > > > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> > > >
> > > > With adaptive simulcast the 2nd rule is enhanced like this:
> > > >
> > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> > > >
> > > > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> > > >
> > > > adaptiveSimulcast: false,
> > > > enableSimulcast: true
> > > >
> > > > Hope this helps.
> > > >
> > > > Best regards,
> > > > George
> > > >
> > > >
> > > > Thanks and Best Regards
> > > > Yanchong Wang
> > > >
> > > >
> > > > From: wangyanchong@hotmail.com
> > > > To: dev@jitsi.org
> > > > Subject: simulcast effect and video quality issue
> > > > Date: Thu, 4 Dec 2014 08:49:14 +0000
> > > >
> > > > Hello, experts:
> > > >
> > > > My recent study on the simulcast found that there are two effect after enabling simulcast:
> > > >
> > > > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> > > >
> > > > 2). The video quality on all browsers are worse than when simulcast was disabled.
> > > >
> > > > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > > > Turn on simulcast:
> > > >
> > > > adaptiveSimulcast: true,
> > > > enableSimulcast: true
> > > >
> > > > Turn off simulcast:
> > > > enableSimulcast: false
> > > >
> > > > Also please see attachment for bandwidth cost snapshot from server.
> > > > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> > > >
> > > >
> > > >
> > > > Thanks and Best Regards
> > > > Yanchong Wang
> > > > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hello Yanchong,

George:

I'am running a virtualbox VM hosting one jitsi-meet server, so I assume the bandwidth from my laptop to it will be at least 10Mbps, but the "bweforvideo" in webrtc-internals show only a statistic graph of 300k bps. Not sure how it is calculated. See my attachment for snapshot.

That looks very wrong, something must be broken here.. Under normal operating conditions you shouldn’t get a flat (red) line.

Have you configured any RTCP termination strategy?
Can you share with us your sip-communicator.properties file?

Can you share with us your config.js file?

What’s your jisti-videobridge/jitsi-meet version?

Can you take a session dump and share it with us?

For download perspective: Is there another bandwidth reference similiar to "bweforvideo" that can guide the resolution of high quality stream, plus the number of low quality streams to download? I am not sure if it has relation with the server side focus discussion.

If the sender has streamed its high quality stream at some point, then at the receiver, in the webrtc-internals page you should actually see 3 receive streams, 1 for audio, 1 for high quality video and 1 for low quality video.

If the sender has never streamed its high quality stream, then at the receiver, in the webrtc-internals page, you’ll only see 2 receive streams, 1 for audio and 1 for low quality video.

Best regards,
George

···

On 11 Dec 2014, at 15:32, WangYanchong <wangyanchong@hotmail.com> wrote:

Thanks and Best Regards
Yanchong Wang

> From: gp@jitsi.org
> Date: Thu, 11 Dec 2014 14:24:30 +0100
> To: dev@jitsi.org
> Subject: Re: [jitsi-dev] simulcast effect and video quality issue
>
> Hello Yanchong,
>
> In webrtc-internals page, as a sender, you’ll *always* see only *one* outgoing video stream. If the available send bandwidth (as reported in your stats for bweforvideo) is above 250-300 Kbps, then you should be streaming 2 video streams, the always-on low quality one targeting 180p, and a high quality one targeting 360p (you can check that with Wireshark).
>
> Best regards,
> George
>
> On 11 Dec 2014, at 14:16, WangYanchong <wangyanchong@hotmail.com> wrote:
>
> > George:
> >
> > Thanks for your answer!
> > From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.
> >
> > For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.
> >
> >
> > Thanks and Best Regards
> > Yanchong Wang
> >
> >
> > > From: gp@jitsi.org
> > > Date: Thu, 11 Dec 2014 09:52:39 +0100
> > > To: dev@jitsi.org
> > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > >
> > > Hello Yanchong,
> > >
> > > With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.
> > >
> > > You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.
> > >
> > > Best regards,
> > > George
> > >
> > > On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:
> > >
> > > > George:
> > > >
> > > > Thanks for your kindly explanation!
> > > > Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> > > > However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
> > > >
> > > > I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
> > > >
> > > >
> > > > Thanks and Best Regards
> > > > Yanchong Wang
> > > >
> > > >
> > > >
> > > > -----------------------------------
> > > > From: gp@jitsi.org
> > > > Date: Fri, 5 Dec 2014 10:45:14 +0100
> > > > To: dev@jitsi.org
> > > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > > >
> > > > Hello Yanchong,
> > > >
> > > > Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
> > > >
> > > > Best regards,
> > > > George
> > > >
> > > > On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
> > > >
> > > > > Thanks for your answer, George.
> > > > > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > > > > "adaptiveSimulcast: false,
> > > > > enableSimulcast: true"
> > > > >
> > > > > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> > > > >
> > > > > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > > > > Please my two snapshot pictures for bandwith monitor.
> > > > >
> > > > > Best Regards
> > > > > yanchong
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------
> > > > >
> > > > > Hello WangYanchong,
> > > > >
> > > > > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> > > > >
> > > > > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> > > > >
> > > > > With adaptive simulcast the 2nd rule is enhanced like this:
> > > > >
> > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> > > > >
> > > > > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> > > > >
> > > > > adaptiveSimulcast: false,
> > > > > enableSimulcast: true
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > Best regards,
> > > > > George
> > > > >
> > > > >
> > > > > Thanks and Best Regards
> > > > > Yanchong Wang
> > > > >
> > > > >
> > > > > From: wangyanchong@hotmail.com
> > > > > To: dev@jitsi.org
> > > > > Subject: simulcast effect and video quality issue
> > > > > Date: Thu, 4 Dec 2014 08:49:14 +0000
> > > > >
> > > > > Hello, experts:
> > > > >
> > > > > My recent study on the simulcast found that there are two effect after enabling simulcast:
> > > > >
> > > > > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> > > > >
> > > > > 2). The video quality on all browsers are worse than when simulcast was disabled.
> > > > >
> > > > > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > > > > Turn on simulcast:
> > > > >
> > > > > adaptiveSimulcast: true,
> > > > > enableSimulcast: true
> > > > >
> > > > > Turn off simulcast:
> > > > > enableSimulcast: false
> > > > >
> > > > > Also please see attachment for bandwidth cost snapshot from server.
> > > > > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> > > > >
> > > > >
> > > > >
> > > > > Thanks and Best Regards
> > > > > Yanchong Wang
> > > > > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > > > > dev mailing list
> > > > > dev@jitsi.org
> > > > > Unsubscribe instructions and other list options:
> > > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > >
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
<bweCompound.jpg>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hello Yanchong,

George:

I'am running a virtualbox VM hosting one jitsi-meet server, so I assume the bandwidth from my laptop to it will be at least 10Mbps, but the "bweforvideo" in webrtc-internals show only a statistic graph of 300k bps. Not sure how it is calculated. See my attachment for snapshot.

That looks very wrong, something must be broken here.. Under normal operating conditions you shouldn’t get a flat (red) line.

Have you configured any RTCP termination strategy?
Can you share with us your sip-communicator.properties file?

Can you share with us your config.js file?

What’s your jisti-videobridge/jitsi-meet version?

Can you take a session dump and share it with us?

For download perspective: Is there another bandwidth reference similiar to "bweforvideo" that can guide the resolution of high quality stream, plus the number of low quality streams to download? I am not sure if it has relation with the server side focus discussion.

If the sender has streamed its high quality stream at some point, then at the receiver, in the webrtc-internals page you should actually see 3 receive streams, 1 for audio, 1 for high quality video and 1 for low quality video.

If the sender has never streamed its high quality stream, then at the receiver, in the webrtc-internals page, you’ll only see 2 receive streams, 1 for audio and 1 for low quality video.

Best regards,
George

···

On 11 Dec 2014, at 15:32, WangYanchong <wangyanchong@hotmail.com> wrote:

Thanks and Best Regards
Yanchong Wang

> From: gp@jitsi.org
> Date: Thu, 11 Dec 2014 14:24:30 +0100
> To: dev@jitsi.org
> Subject: Re: [jitsi-dev] simulcast effect and video quality issue
>
> Hello Yanchong,
>
> In webrtc-internals page, as a sender, you’ll *always* see only *one* outgoing video stream. If the available send bandwidth (as reported in your stats for bweforvideo) is above 250-300 Kbps, then you should be streaming 2 video streams, the always-on low quality one targeting 180p, and a high quality one targeting 360p (you can check that with Wireshark).
>
> Best regards,
> George
>
> On 11 Dec 2014, at 14:16, WangYanchong <wangyanchong@hotmail.com> wrote:
>
> > George:
> >
> > Thanks for your answer!
> > From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.
> >
> > For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.
> >
> >
> > Thanks and Best Regards
> > Yanchong Wang
> >
> >
> > > From: gp@jitsi.org
> > > Date: Thu, 11 Dec 2014 09:52:39 +0100
> > > To: dev@jitsi.org
> > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > >
> > > Hello Yanchong,
> > >
> > > With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.
> > >
> > > You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.
> > >
> > > Best regards,
> > > George
> > >
> > > On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:
> > >
> > > > George:
> > > >
> > > > Thanks for your kindly explanation!
> > > > Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> > > > However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
> > > >
> > > > I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
> > > >
> > > >
> > > > Thanks and Best Regards
> > > > Yanchong Wang
> > > >
> > > >
> > > >
> > > > -----------------------------------
> > > > From: gp@jitsi.org
> > > > Date: Fri, 5 Dec 2014 10:45:14 +0100
> > > > To: dev@jitsi.org
> > > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > > >
> > > > Hello Yanchong,
> > > >
> > > > Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
> > > >
> > > > Best regards,
> > > > George
> > > >
> > > > On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
> > > >
> > > > > Thanks for your answer, George.
> > > > > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > > > > "adaptiveSimulcast: false,
> > > > > enableSimulcast: true"
> > > > >
> > > > > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> > > > >
> > > > > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > > > > Please my two snapshot pictures for bandwith monitor.
> > > > >
> > > > > Best Regards
> > > > > yanchong
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------
> > > > >
> > > > > Hello WangYanchong,
> > > > >
> > > > > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> > > > >
> > > > > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> > > > >
> > > > > With adaptive simulcast the 2nd rule is enhanced like this:
> > > > >
> > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> > > > >
> > > > > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> > > > >
> > > > > adaptiveSimulcast: false,
> > > > > enableSimulcast: true
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > Best regards,
> > > > > George
> > > > >
> > > > >
> > > > > Thanks and Best Regards
> > > > > Yanchong Wang
> > > > >
> > > > >
> > > > > From: wangyanchong@hotmail.com
> > > > > To: dev@jitsi.org
> > > > > Subject: simulcast effect and video quality issue
> > > > > Date: Thu, 4 Dec 2014 08:49:14 +0000
> > > > >
> > > > > Hello, experts:
> > > > >
> > > > > My recent study on the simulcast found that there are two effect after enabling simulcast:
> > > > >
> > > > > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> > > > >
> > > > > 2). The video quality on all browsers are worse than when simulcast was disabled.
> > > > >
> > > > > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > > > > Turn on simulcast:
> > > > >
> > > > > adaptiveSimulcast: true,
> > > > > enableSimulcast: true
> > > > >
> > > > > Turn off simulcast:
> > > > > enableSimulcast: false
> > > > >
> > > > > Also please see attachment for bandwidth cost snapshot from server.
> > > > > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> > > > >
> > > > >
> > > > >
> > > > > Thanks and Best Regards
> > > > > Yanchong Wang
> > > > > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > > > > dev mailing list
> > > > > dev@jitsi.org
> > > > > Unsubscribe instructions and other list options:
> > > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > >
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
> > >
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
<bweCompound.jpg>_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

George:
Thanks for your kindly help!
Here I just tested the very same configuration again in lab, the "bweforvideo" in webrtc-internals looks much better than in my home, they were both above 1.0 Mbps.
I've still bear some confusions in mind, however:
1). Compared two snapshot in attached pictures, the "bweforvideo" value is quite different by just turn off/on the "basic simulcast" feature. Ony turn on the basic simulcast, browser will show a much lower "bweforvideo".
2). The webrtc-internal page show 3 received stream as you mentioned. The graph change instantly when my browser choose to show local or remote video. When show local video, the received stream is about 100kbps, and when show remote video, the other stream is about 800kbps. It's so nice!
Have you configured any RTCP termination strategy?--NoCan you share with us your sip-communicator.properties file?.--I've all configuration file by default except the jitsi-meet config.js
var config = { hosts: { domain: 'meet.test.net', //anonymousdomain: 'guest.example.com', muc: 'conference.meet.test.net', // FIXME: use XEP-0030 bridge: 'jitsi-videobridge.meet.test.net', // FIXME: use XEP-0030 //call_control: 'callcontrol.meet.test.net' },// getroomnode: function (path) { return 'someprefixpossiblybasedonpath'; },// useStunTurn: true, // use XEP-0215 to fetch STUN and TURN server// useIPv6: true, // ipv6 support. use at your own risk useNicks: false, bosh: '//meet.test.net/http-bind', // FIXME: use xep-0156 for that clientNode: 'http://jitsi.org/jitsimeet', // The name of client node advertised in XEP-0115 'c' stanza //defaultSipNumber: '', // Default SIP number desktopSharing: 'ext', // Desktop sharing method. Can be set to 'ext', 'webrtc' or false to disable. chromeExtensionId: 'mpaflpoeogiolfhnoahmhfbkfjahodda', // Id of desktop streamer Chrome extension desktopSharingSources: ['screen', 'window'], minChromeExtVersion: '0.1', // Required version of Chrome extension enableRtpStats: true, // Enables RTP stats processing openSctp: true, // Toggle to enable/disable SCTP channels channelLastN: -1, // The default value of the channel attribute last-n. adaptiveLastN: false, adaptiveSimulcast: false, useRtcpMux: true, useBundle: true, enableRecording: false, enableWelcomePage: false, enableSimulcast: false, disablePrezi: true};

version informations:dpkg -l | grep jitsiii jitsi-meet 1.0.260-1 all WebRTC JavaScript video conferencesii jitsi-meet-prosody 1.0.260-1 all Prosody configuration for Jitsi Meetii jitsi-videobridge 353-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)

Thanks and Best RegardsYanchong Wang

···

From: gp@jitsi.org
Date: Thu, 11 Dec 2014 16:19:20 +0100
To: dev@jitsi.org
Subject: Re: [jitsi-dev] simulcast effect and video quality issue

Hello Yanchong,

On 11 Dec 2014, at 15:32, WangYanchong <wangyanchong@hotmail.com> wrote:

> George:
>
> I'am running a virtualbox VM hosting one jitsi-meet server, so I assume the bandwidth from my laptop to it will be at least 10Mbps, but the "bweforvideo" in webrtc-internals show only a statistic graph of 300k bps. Not sure how it is calculated. See my attachment for snapshot.

That looks very wrong, something must be broken here.. Under normal operating conditions you shouldn’t get a flat (red) line.

Have you configured any RTCP termination strategy?
Can you share with us your sip-communicator.properties file?

Can you share with us your config.js file?

What’s your jisti-videobridge/jitsi-meet version?

Can you take a session dump and share it with us?

> For download perspective: Is there another bandwidth reference similiar to "bweforvideo" that can guide the resolution of high quality stream, plus the number of low quality streams to download? I am not sure if it has relation with the server side focus discussion.

If the sender has streamed its high quality stream at some point, then at the receiver, in the webrtc-internals page you should actually see 3 receive streams, 1 for audio, 1 for high quality video and 1 for low quality video.

If the sender has never streamed its high quality stream, then at the receiver, in the webrtc-internals page, you’ll only see 2 receive streams, 1 for audio and 1 for low quality video.

Best regards,
George

>
>
>
>
> Thanks and Best Regards
> Yanchong Wang
>
>
> > From: gp@jitsi.org
> > Date: Thu, 11 Dec 2014 14:24:30 +0100
> > To: dev@jitsi.org
> > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> >
> > Hello Yanchong,
> >
> > In webrtc-internals page, as a sender, you’ll *always* see only *one* outgoing video stream. If the available send bandwidth (as reported in your stats for bweforvideo) is above 250-300 Kbps, then you should be streaming 2 video streams, the always-on low quality one targeting 180p, and a high quality one targeting 360p (you can check that with Wireshark).
> >
> > Best regards,
> > George
> >
> > On 11 Dec 2014, at 14:16, WangYanchong <wangyanchong@hotmail.com> wrote:
> >
> > > George:
> > >
> > > Thanks for your answer!
> > > From video sender perspective, fully utilization of the sender's bandwidth should be fine enough. I'm interested to test it tomorrow.
> > >
> > > For the "chrome://webrtc-internals page", how can I identify sender's pair of upload videos(high/low quality stream)? So that I can check it against "bweforvideo" in my test LAN.
> > >
> > >
> > > Thanks and Best Regards
> > > Yanchong Wang
> > >
> > >
> > > > From: gp@jitsi.org
> > > > Date: Thu, 11 Dec 2014 09:52:39 +0100
> > > > To: dev@jitsi.org
> > > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > > >
> > > > Hello Yanchong,
> > > >
> > > > With basic simulcast, if a sender has (and successfully detects) enough send bandwidth, then the video quality shouldn’t degrade because the said endpoint is supposed to stream both a low quality stream and a high quality stream.
> > > >
> > > > You can check the available send bandwidth in the chrome://webrtc-internals page in the stats graphs for bweforvideo.
> > > >
> > > > Best regards,
> > > > George
> > > >
> > > > On 11 Dec 2014, at 03:34, WangYanchong <wangyanchong@hotmail.com> wrote:
> > > >
> > > > > George:
> > > > >
> > > > > Thanks for your kindly explanation!
> > > > > Simulcast can definitly save much network bandwidth for conference with more than 3 participants. Thus improve the meeting system scalability.
> > > > > However, the video quality is at least as same important for conference, with simulcast, I can not see any mechanism to maintain the video stream quality of any selected participant. For purposed held meetings, keep several participants sharing high quality video/desktop streaming is key to its success.
> > > > >
> > > > > I've also seen some new discussions about current client side focus vz server side focus (not sure if jicofo is invested for this purpose https://github.com/jitsi/jicofo)
> > > > >
> > > > >
> > > > > Thanks and Best Regards
> > > > > Yanchong Wang
> > > > >
> > > > >
> > > > >
> > > > > -----------------------------------
> > > > > From: gp@jitsi.org
> > > > > Date: Fri, 5 Dec 2014 10:45:14 +0100
> > > > > To: dev@jitsi.org
> > > > > Subject: Re: [jitsi-dev] simulcast effect and video quality issue
> > > > >
> > > > > Hello Yanchong,
> > > > >
> > > > > Simulcast is a feature that optimises bandwidth utilisation so, this is exactly what should happen and your results show that simulcast is working correctly :slight_smile:
> > > > >
> > > > > Best regards,
> > > > > George
> > > > >
> > > > > On 05 Dec 2014, at 10:38, WangYanchong <wangyanchong@hotmail.com> wrote:
> > > > >
> > > > > > Thanks for your answer, George.
> > > > > > I've just followed your advice to only turn on basic simulcast as such in config.js:
> > > > > > "adaptiveSimulcast: false,
> > > > > > enableSimulcast: true"
> > > > > >
> > > > > > Now each user select a remote video, however, by contrast to simulcast disabled configurations, the upload/download bandwith for each browser still drop significantly.
> > > > > >
> > > > > > Btw, I also host all three labtop and the server into a standalone router to avoid possible network disruptions.
> > > > > > Please my two snapshot pictures for bandwith monitor.
> > > > > >
> > > > > > Best Regards
> > > > > > yanchong
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------
> > > > > >
> > > > > > Hello WangYanchong,
> > > > > >
> > > > > > The way “basic” simulcast works in jitsi-meet/jitsi-videobridge is based on the following two rules:
> > > > > >
> > > > > > - an endpoint sends 1 low quality stream and, if it has enough outgoing bandwidth, 1 high quality stream.
> > > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality, otherwise it will receive low quality for that endpoint too.
> > > > > >
> > > > > > With adaptive simulcast the 2nd rule is enhanced like this:
> > > > > >
> > > > > > - an endpoint receives low quality video except for the selected endpoint for which it receives high quality IF the selected endpoint is actually streaming high quality AND if the receiver has enough incoming bandwidth, otherwise it will receive low quality for that endpoint too.
> > > > > >
> > > > > > The additional condition can be a little aggressive so your receivers might actually always receive low quality videos, if the algorithm doesn’t detect enough incoming bandwidth. That’s why I’d suggest that you include another case in your experiments:
> > > > > >
> > > > > > adaptiveSimulcast: false,
> > > > > > enableSimulcast: true
> > > > > >
> > > > > > Hope this helps.
> > > > > >
> > > > > > Best regards,
> > > > > > George
> > > > > >
> > > > > >
> > > > > > Thanks and Best Regards
> > > > > > Yanchong Wang
> > > > > >
> > > > > >
> > > > > > From: wangyanchong@hotmail.com
> > > > > > To: dev@jitsi.org
> > > > > > Subject: simulcast effect and video quality issue
> > > > > > Date: Thu, 4 Dec 2014 08:49:14 +0000
> > > > > >
> > > > > > Hello, experts:
> > > > > >
> > > > > > My recent study on the simulcast found that there are two effect after enabling simulcast:
> > > > > >
> > > > > > 1). The total incoming/outgoing network statistics from server viewpoint show that simulcast can save clients' total download bandwidth.
> > > > > >
> > > > > > 2). The video quality on all browsers are worse than when simulcast was disabled.
> > > > > >
> > > > > > I've used three chrome browsers during the test and here are my tunes on the config.js and snapshot ofnload on my hosted jitsi-meet server:
> > > > > > Turn on simulcast:
> > > > > >
> > > > > > adaptiveSimulcast: true,
> > > > > > enableSimulcast: true
> > > > > >
> > > > > > Turn off simulcast:
> > > > > > enableSimulcast: false
> > > > > >
> > > > > > Also please see attachment for bandwidth cost snapshot from server.
> > > > > > Please kindly let me know if this is as expected and what I've missed from configuration perspective.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks and Best Regards
> > > > > > Yanchong Wang
> > > > > > <simulcast_disabled.jpg><simulcast_enabled.jpg>_______________________________________________
> > > > > > dev mailing list
> > > > > > dev@jitsi.org
> > > > > > Unsubscribe instructions and other list options:
> > > > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > dev mailing list
> > > > > dev@jitsi.org
> > > > > Unsubscribe instructions and other list options:
> > > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > dev mailing list
> > > > > dev@jitsi.org
> > > > > Unsubscribe instructions and other list options:
> > > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > >
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > dev@jitsi.org
> > > > Unsubscribe instructions and other list options:
> > > > http://lists.jitsi.org/mailman/listinfo/dev
> > > _______________________________________________
> > > dev mailing list
> > > dev@jitsi.org
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> <bweCompound.jpg>_______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev