Network Quality Monitoring in Content Share

Hello guys,

We’re currently working in a proctoring application using this SDK (v2.30.0) and the idea is to create a meeting where we’ll only have a single user streaming both his webcam and screen. Both of these will get recorded using media capture pipelines and be stored inside an S3 bucket. Now, besides recording the meeting, we also want to be able to monitor the user’s connection and be able to identify whenever there are issues on his side that could affect the upload of the data. Since the main purpose of the app is to record the user’s media (webcam + screen capture) and since there will always be only a single user in the meeting, we are solely focusing in monitoring the user’s uplink bandwidth. We’re doing this by listening to the metricsDidReceive event and reading the videoUpstreamBitrate.

According to the QualityBandwidth_Connectivity documentation, there are different webcam resolutions supported by Chime along with their corresponding Min and Max bitrate. For a 720p resolution you can only have a max of 2500 kbps and a min of 1400kbps.

Taking that into account, I’ve been doing some tests under a 720p resolution where I throttle the connection, through a third party app, in order to watch the bitrate fall from 2500 kbps (the max for this resolution) to a mere 500 kbps (way below the minimum). This to simulate a real life scenario where a user might end up having connection issues that might affect the recording of the meeting. The recorded webcam video, although a bit blurry, still looked decent and any person would still be able to distinguish whatever is going in the video. I would guess that this is because there’s not much going on in the user’s recording zone. He will kind of remain static while being recorded in the meeting.

Now, my question comes with the recording of the screen capture. I know that there’s no way to change the resolution under which the screen is being recorded. This one will be locked at whatever resolution the user has in the screen at the moment of joining the meeting. With that into account, as I was doing the previous throttling tests, I noticed that the screen capture recording looked exactly the same both at the 2500 kbps as well as at the 500 kbps.

The only difference here is that whenever the bitrate remained unstable (too much fluctuation) in the 500 kbps range, the screen capture would end up getting stuck. However, the moments where the connection stabilized itself (always at the 500 kbps range) the screen capture would end up looking the same as at the 2500 kbps, both in quality and smoothness. So, my question is, is it safe to assume that the screen capture will always look the same once recorded regardless of the videoUpstreamBitrate being reported so long as this one remains stable enough?

Once again, whenever I’m hitting the max of 2500 kbps the screen capture recording looks great. Once I start throttling the connection, this one will start getting stuck. However, if the bitrate stabilizes itself, lets say at ~800 kbps, then the recorded screen capture will start looking smooth again, always at the same resolution it was currently at when initiating the meeting.

[devalevenkatesh]

Hi @AleKiller21 ,

I currently do not think that we have knobs specifically to control the content share stream like the one you mentioned for the video stream so that would be a feature request in my opinion. With that said, we have simulcast for content share which should have the bandwidth where you could scale down the content stream’s resolution.

Could you please check below guide and see whether that is applicable to your use case? https://github.com/aws/amazon-chime-sdk-js/blob/main/guides/05_Simulcast.md#enable-simulcast-for-content-share

I believe for that you have to migrate to JS SDK v3 though, but the migration should be fairly straightforward.

[AleKiller21]

Hi @ltrung !

Have you had a chance to take a look a the above ?