Screensharing Issue

[zdfs]

So here's the scenario. I'm hoping you could help shed some light on what's happening.

This seems to work.

1. Computer A starts a session. Video and audio start normally.
2. Computer A starts screensharing. Video is replaced with screensharing.
3. Computer B joins the session.
4. Data still works.

This doesn't work.

1. Computer A starts a session. Video and audio start normally.
2. Computer B joins the session. Video and audio start normally.
3. Computer A starts screensharing. Video is replaced with screensharing.
4. Computer B receives a bug: Uncaught Multi-capturing of screen is not allowed. Capturing process is denied. Are you enabled flag: "Enable screen capture support in getUserMedia"?
5. Data doesn't work.

Right now, I'm just trying to test this with two windows in Google Chrome, and I'm not sure if that's contributing to the issue. Maybe I need two separate machines to really work on this scenario.

Thoughts?

[zdfs]

I think I need to have a webrtc connection for every stream type. Data, audio, video, and screen each get their own connection. Does that approach have merit, in your opinion?

[muaz-khan]

I think I need to have a webrtc connection for every stream type. Data, audio, video, and screen each get their own connection. Does that approach have merit, in your opinion?

It is useful only if you want to share screen along with audio and video. One peer can be negotiated for audio/video and one for screen.

It is true that multiple streams attachment is supported since long time; however video along with screen in a single peer connection still fails (out of duplicate video m-lines or overriding old m-line). Though, it is expected to be fixed in near future; where one m-line will have multiple streams.

Possible Scenarios

1. If you're sharing audio-only stream; you can renegotiate any other stream except a duplicate audio stream.
2. If you're sharing audio/video streams; you can renegotiate any other stream except a duplicate audio or video stream; screen capturing is also listed in video m-line; that's why renegotiation process fails.
3. If you're sharing data-only stream; you can renegotiate any other stream.

In last case; old data m-line can be overridden.

Sometimes overriding process works without any failure; however old streams will be stopped flowing.

...right now, I'm just trying to test this with two windows in Google Chrome, and I'm not sure if that's contributing to the issue...

Chrome doesn't allow multiple screen capturing requests per system; even if you're using two unique tabs or windows. That's why you should try oneway:true.