Closed semmel closed 1 year ago
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?
@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.
When creating a
Publisher
with a self-provided MediaStreamTrack from a screen share stream, no"streamPropertyChanged"
events withreason
"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
In the custom stream case,
"streamPropertyChanged"
withparams: {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 thePublisher
constructor thestream
member is created for whichthis.stream.isSendScreen()
isfalse
. Thus the publisher's screen share resize loop is not executed, and thus no"screenResized"
event emitted.Solution
isSendScreen()
which should also returntrue
if["monitor", "window", "browser"].includes(videoSource.getSettings().displaySurface)
or,PublisherProperties
by a flagisScreenSurface
– this is more involved I guess (documentation and stuff)Note that,
.typeOfVideo
property ofStream
in the outbound caseWhich solution should be attempted?
OpenVidu deployment info
Client device info (if applicable) latest FF, Safari, Chrome