Ability to change content share

[asc0910]

How to change content share?

I want to replace the current screen share like zoom.

When I call startContentShareFromScreenCapture it show the warning no transition found from connected with connect in DefaultSessionStateController.ts

[p-foucht]

When you say replace, do you mean replace an existing content share?

Is this the scenario you're trying to build?

• User A starts content sharing
• User B wants to take over content sharing. They start content sharing
• User A's content share stops because user B took over

[ltrung]

Unfortunately, we currently do not support changing the current screenshare. For now, you can either call stopContentShare and call startContentShareFromScreenCapture; or re-implement the ContentShareController interface and in startContentShare, skip audioVideo.start if it is already started and call replaceLocalVideo in that case.

[asc0910]

Ok, I got it

[asc0910]

When you say replace, do you mean replace an existing content share?

Is this the scenario you're trying to build?

• User A starts content sharing
• User B wants to take over content sharing. They start content sharing
• User A's content share stops because user B took over

That is the senario

• User A starts content share
• User B join the meeting and see the screenshare
• User A want to change the screenshare and he don't want to stop screenshare (so the stream to be continuous)

Now I stop the screenshare first and then start contentshare again. So on the side of user B, the contentshare stoped for a sec and can see the new screenshare. I want this to be continuous.

[YauheniBH-EF]

i'm looking for the same behaviour @asc0910 has described

@ltrung , from your description it doesn't seem to be a hard task to do, so there are a couple of options

1. this could be done by aws chime team
2. this could be done by community, i'm completely okay to take a look into that

besides of replaceLocalVideo as well local audio should be replaced with replaceLocalAudio

please, let me know which option would be better

P.S. by the way i tested locally usage of replaceLocalVideo & replaceLocalAudio and it seems to work fine

[ltrung]

@YauheniBH-EF If you implement it as another API, feel free to raise a PR and we could leave comment. Thanks for your contribution

[YauheniBH-EF]

@ltrung this is a draft of one of the ideas i'm thinking about right now (please, let me know if it's better to discuss in private messages)

https://github.com/aws/amazon-chime-sdk-js/compare/main...YauheniBH-EF:amazon-chime-sdk-js:content_share_hot_replacement?expand=1

i realised that the same mechanism is used behind the scene for Microphone & Camera hot replacement; basically, DefaultDeviceController implements MediaStreamBroker interface and plays a broker role for DefaultAudioVideo; so basically just by implementing this observer the necessary behaviour could be achieved - looks pretty elegant imho.

please, let me know, if it worth continuing implementation in that direction

P.S. besides of that code in ContentShareMediaStreamBroker is very confusing... e.g. this null assignment; how it could be even possible, if set mediaStream signature doesn't accept nulls... (so in my PR you may find fixes as well for such issues, but they are not mandatory).

https://github.com/aws/amazon-chime-sdk-js/blob/7283401c6c00166a7ffaf22a4de1bd4ddd6ffeff/src/contentsharecontroller/ContentShareMediaStreamBroker.ts#L12

https://github.com/aws/amazon-chime-sdk-js/blob/7283401c6c00166a7ffaf22a4de1bd4ddd6ffeff/src/contentsharecontroller/ContentShareMediaStreamBroker.ts#L20

https://github.com/aws/amazon-chime-sdk-js/blob/7283401c6c00166a7ffaf22a4de1bd4ddd6ffeff/src/contentsharecontroller/ContentShareMediaStreamBroker.ts#L108

a this null check, why it's even needed to perform that if typescript doesn't allow having nulls in mediaStream

https://github.com/aws/amazon-chime-sdk-js/blob/7283401c6c00166a7ffaf22a4de1bd4ddd6ffeff/src/contentsharecontroller/ContentShareMediaStreamBroker.ts#L90

[ltrung]

Thanks for continuing working on this and sorry I missed your update. Just curious, in your use case do you plan to call getDisplayMedia again to get the new screenshare stream from browser. Won't that end the the previous screenshare stream anyway and user B will see the black screen anyway? Although the latency to switch screenshare would be faster as we don't have to rejoin. Other than that I think you are on the right track.

[YauheniBH-EF]

Well, in case of getDisplayMedia it might work as you guessed, but speed of resolving a new stream is out of our control, so it is how it is, In my case i already have 5-10 media streams i need to switch between in real time. I will continue working on that feature, but i don't know how much time it would take, since i have pretty high load due to the project release. Will keep you posted :)