Screen share preview before start streaming

Azhar Ali

Member
Hi,

We are currently building a project using WCS and we have a requirement where we want user to see what they are going to stream. We want to allow user to stream camera or screenshare. I have looked in the forum and found a helpful link where you have advised to use getMediaAcess to get the display into the localVideo. This also works when you change the constraints to 'screen' for video.

However, we want user to start streaming with a button click after they have done the preview. You can pass the deviceId in the constraints for the camera streaming but is it possible to do the same for the screen sharing, so 'Choose Screen' dialog does not appear as user have already selected the screen they want to share.

I believe this will be very common use case where you want to see what will stream before you actually start streaming.

Any help or guidance to achieve that will be highly appreciated.

Regards
Azhar
 

Max

Administrator
Staff member
Hello.
You can use getMediaAccess to preview screen share before publishing like this:
Code:
function test_screen() {
    var constraints = {
        video: {
            width: parseInt($('#width').val()),
            height: parseInt($('#height').val()),
            frameRate: {max: parseInt($('#fps').val())}
        }
    };
    constraints.video.type = "screen";
    if (Browser.isFirefox()){
        constraints.video.mediaSource = $('#mediaSource').val();
    }
    Flashphoner.getMediaAccess(constraints, localVideo).then(function (disp) {
        testStarted = true;
    }).catch(function (error) {
        testStarted = false;
    });
}
The only issue is 'Choose screen' dialog window will be displayed for both preview and publishing operations. A browser displays this dialog because user action is needed, and we can't escape it.
 

Azhar Ali

Member
Hi Max,

Thank you the reply. This is how I have done to get the preview.
My suggestion was as user has already performed the action and getMediaAccess has successfully received the screen, would there be any scope to pass a flag in the constraints to not request the screen again as final stream is done using the local video anyway, that can potentially achieve that.

I would also like to suggest of having a start function and primary purpose of that will be to start the publishing and assume everything else has been done already. Its opposite to stop. This will be useful to have for use cases where you have to start the stream at a particular time but can get it ready in advance.
 

Max

Administrator
Staff member
Hello.
would there be any scope to pass a flag in the constraints to not request the screen again
No. Browser does not provide any flags to escape the request.
I would also like to suggest of having a start function and primary purpose of that will be to start the publishing and assume everything else has been done already
You can use Session.createStream() and Stream.publish() functions separately. The first function just create the stream and performs all the setup, the second starts publishing stream.
 

Azhar Ali

Member
Hi,

No. Browser does not provide any flags to escape the request.
I didn't mean if the browser has that flag or not. I meant to say, if its possible to a custom flag in your API to skip getScreenDeviceId step inside the publish function. That will effectively resolve this as final stream is done using localVideo object anyway.
You can use Session.createStream() and Stream.publish() functions separately. The first function just create the stream and performs all the setup, the second starts publishing stream.
You are correct but issue is createStream does not request camera or screen if that can be part of createStream which it should be i think as its part of getting ready and setup then publish function will only start streaming will also resolve it.
 

Max

Administrator
Staff member
Hello.
You ask for deep WebSDK rework.
If you really need it, you can modify WebSDK yourself. WebSDK source code is opened, you can get it from GitHub and build it as described in this doc.
 
Last edited:

Azhar Ali

Member
Hello.
You ask for deep WebSDK rework.
If you really need it, you can modify WebSDK yourself. WebSDK source code is opened, you can get it from GitHub and build it as described in this doc.
Hi Max,

I appreciate that. Thanks for looking. I was putting a suggestion forward and if that can be considered in the roadmap. I don't think what I am asking is totally unreasonable. The whole issue here is showing user what its going to stream before it streams and whatever your teams thinks best way to achieve.

I would rather not change the source because that will stop me updating the future versions.

thanks

Regards
Azhar
 

Max

Administrator
Staff member
We have registered internal ticket WCS-1816
We will inform you through this forum thread as soon as the ticket takes a priority.
 

Max

Administrator
Staff member
Hello,

Please see the attached example (screenSharingPreview.zip)
- getMediaAccess() is used for preview ('Choose Screen' dialog is displayed)
Code:
Flashphoner.getMediaAccess(getConstraints(), localVideo).then(...);
- then, when stream is published, it is captured from video element with id "-LOCAL_CACHED_VIDEO" (and 'Choose Screen' dialog is not displayed)
Code:
session.createStream({
  name: streamName,
  display: localVideo,
  cacheLocalResources: true
})}).publish();
Required constraints (e.g., microphone, resolution) should be set before starting preview.
(diff.zip contains diff files - changes in comparison to the demo Screen Sharing example.)
 

Attachments

Azhar Ali

Member
Hello,

Please see the attached example (screenSharingPreview.zip)
- getMediaAccess() is used for preview ('Choose Screen' dialog is displayed)
Code:
Flashphoner.getMediaAccess(getConstraints(), localVideo).then(...);
- then, when stream is published, it is captured from video element with id "-LOCAL_CACHED_VIDEO" (and 'Choose Screen' dialog is not displayed)
Code:
session.createStream({
  name: streamName,
  display: localVideo,
  cacheLocalResources: true
})}).publish();
Required constraints (e.g., microphone, resolution) should be set before starting preview.
(diff.zip contains diff files - changes in comparison to the demo Screen Sharing example.)
thats brilliant Max, I will test it. Wasn't expecting a solution that quick :D
 

Azhar Ali

Member
Hello,

Please see the attached example (screenSharingPreview.zip)
- getMediaAccess() is used for preview ('Choose Screen' dialog is displayed)
Code:
Flashphoner.getMediaAccess(getConstraints(), localVideo).then(...);
- then, when stream is published, it is captured from video element with id "-LOCAL_CACHED_VIDEO" (and 'Choose Screen' dialog is not displayed)
Code:
session.createStream({
  name: streamName,
  display: localVideo,
  cacheLocalResources: true
})}).publish();
Required constraints (e.g., microphone, resolution) should be set before starting preview.
(diff.zip contains diff files - changes in comparison to the demo Screen Sharing example.)
Hi Max,

Thanks for this fix. This has fixed the original issue of showing preview before the stream starts however, switching to screen does not work if you start the stream this way. You get the same error as I have described in another thread when clonedConstraints arn't the same as what was passed toat first place. Gives a javascript error max is not defined.
Test was start the stream with camera using the above method and then try and switch to screen.

https://forum.flashphoner.com/threads/problem-when-switching-to-screen-share-second-time.11913/
 

Max

Administrator
Staff member
Hello.
We raised internal ticket (WCS-1844) and let you know when investigate it.
 

Azhar Ali

Member
Hello
The investigation will take a time and there is a chance it will be fixed.
However to manage streams more efficiently you can use direct and raw Websocket API.
https://docs.flashphoner.com/display/WCS52EN/Raw WebSocket API
So you can manage streams using raw browser getUserMedia() WebRTC API.
The Websocket API ensures SDP exchange between browser and WCS server.
thanks, I will try and see if I can use getUserMedia to switch screens. A fix to the SDK would be ideal though.
 
Top