# Publish application-provided screensharing video tracks **URL:** \ **Category:** Request for enhancement\ **Created:** [April 22, 2021, 9:25pm UTC](https://openvidu.discourse.group/t/publish-application-provided-screensharing-video-tracks/2985 "2021-04-22T21:25:48Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Semmel](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/semmel/32/140_2.png) [@Semmel](https://openvidu.discourse.group/u/Semmel)\ **Post date:** [April 22, 2021, 9:25pm UTC](https://openvidu.discourse.group/t/publish-application-provided-screensharing-video-tracks/2985/1 "2021-04-22T21:25:48Z")
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)`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/captureStream). Perhaps it’s just a matter of tweaking the implementation of `Stream.isSendScreen()`. ---
**Author:** ![pabloFuente](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/pablofuente/32/2536_2.png) [@pabloFuente](https://openvidu.discourse.group/u/pabloFuente)\ **Post date:** [April 23, 2021, 8:44am UTC](https://openvidu.discourse.group/t/publish-application-provided-screensharing-video-tracks/2985/2 "2021-04-23T08:44:35Z")
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. ---
**Author:** ![Semmel](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/semmel/32/140_2.png) [@Semmel](https://openvidu.discourse.group/u/Semmel)\ **Post date:** [April 23, 2021, 11:15am UTC](https://openvidu.discourse.group/t/publish-application-provided-screensharing-video-tracks/2985/3 "2021-04-23T11:15:13Z")
> 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 `MediaStream`s my application manages for the user. I don’t like `openvidu-browser` to depend on `