Publish application-provided screensharing video tracks

Request for enhancement
1

Currently publishing screensharing is supported just by specifying {videoSource: "screen"} in OV.initPublisher(). And thus letting OpenVidu create and manage the screensharing media stream.

This is unlike publishing webcam media streams, where {videoSource: MediaStreamTrack} is supported for application-provided streams.

It would be great if the application could manage the screensharing (i.e. by calling navigator.mediaDevices.getDisplayMedia()) and sometime later feed that media stream track to OV.initPublisher() for publishing.

Note, that if you do that in OpenVidu v 2.17.0, such an application-managed screensharing track gets published fine but it is treated like a webcam track without emitting any "streamPropertyChanged" events with {property:"videoDimension", reason: "screenResize"}. This is due to Stream.isSendScreen() computing false for any {videoSource: MediaStreamTrack} publishers.

This would also allow the application to provide another kind of resizable video track: canvas.captureStream(frameRate).

Perhaps it’s just a matter of tweaking the implementation of Stream.isSendScreen().

2

Yes, you are right. Using custom MediaStreamTracks doesn’t allow flagging the Publisher object as a screen-sharing one. We can think of allowing to manually set the Publsiher as srcreen sharing after it has been initialized.

3

We can think of allowing to manually set the Publsiher as srcreen sharing after it has been initialized.

Perhaps that is a good idea. But let’s briefly consider another way: Letting the application detect video resizing for custom MediaStreamTracks.

  1. Since the application already manages navigator.mediaDevices.getDisplayMedia() with all errors and stuff, it should be straight forward to poll the video dimensions every 650 msec in the same way as OpenVidu.Publisher does it.
  2. An additional burden would be to call the (undocumented) OpenVidu.sendRequest('streamPropertyChanged',{streamId: publisher.stream.streamId, property: 'videoDimensions', newValue: JSON.stringify(size), reason: "screenResize"}

What other benefit is there in OpenVidu knowing that the provided MediaStreamTrack is a shared screen/window?

On the subscribing end I guess nothing would change, since screensharing streams all require a separate Connection anyway. So the receiver has to sort incoming streams anyway by different means than a possible screensharing flag.

Perhaps that just my attitude, but I would like for openvidu-browser to just deliver the various MediaStreams my application manages for the user. I don’t like openvidu-browser to depend on <video> elements in the DOM. That’s why I prefer custom MediaStreamTracks also for webcams.

Anyway - I like the project very much. Thanks for all the work.