openvidu-browser: 'screenResized' is never emitted for custom screen share tracks

[semmel]

When creating a Publisher with a self-provided MediaStreamTrack from a screen share stream, no "streamPropertyChanged" events with reason "screenResize" are emitted when the shared window/app/browser-tab is resized.

Expected behavior When resizing the display source of a screensharing stream such "streamPropertyChanged" should be emitted from the publisher.

Wrong current behavior

const
    OV = new OpenVidu(),
    session = OV.initSession(),
    // <<< Case: custom stream
    stream = await navigator.getDisplayMedia(),
    publisher = await openVidu.initPublisherAsync(
        undefined, 
        {
            audioSource: false, 
            videoSource: stream.getVideoTracks()[0]
        }
    ),
    // <<<
    // >>> Case: stream acquired by OV
    publisher = await OV.initPublisherAsync(
        ovTargetEl, 
        {
            audioSource: false, 
            videoSource: "screen"
        }
    ),
    // >>>
    token = await getAccessToken();
await session.connect(token);
session.publish(publisher);

In the custom stream case, "streamPropertyChanged" with params: {reason: "screenResized"} is never emitted over the websocket connection.

Analysis

The publisher does not know that he's given a screen sharing video track.

Giving a MediaStreamTrack for videoSource, in the Publisher constructor the stream member is created for which this.stream.isSendScreen() is false. Thus the publisher's screen share resize loop is not executed, and thus no "screenResized" event emitted.

Solution

1. Quickly "fix" isSendScreen() which should also return true if ["monitor", "window", "browser"].includes(videoSource.getSettings().displaySurface) or,
2. extend PublisherProperties by a flag isScreenSurface – this is more involved I guess (documentation and stuff)

Note that,

• Solution 1.) is currently not supported by Firefox – I would not care though.
• it should also affect the .typeOfVideo property of Stream in the outbound case

Which solution should be attempted?

OpenVidu deployment info

• OpenVidu CE v2.27
• openvidu-node-client v2.27

Client device info (if applicable) latest FF, Safari, Chrome

[cruizba]

I would go with solution 1. You are free to do a PR, I think this should not affect anything.

Even if it is not working in Firefox, applying solution 1) would result in isSendScreen() returning false, right?

[semmel]

@cruizba

I would go with solution 1. You are free to do a PR, I think this should not affect anything.

Great, also my favourite solution.

Even if it is not working in Firefox, applying solution 1) would result in isSendScreen() returning false, right?

Yes, that's the plan.