https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# cloud
s
This message was deleted.
f
@polite-kilobyte-67570 this seems to be screen share layer stopping/restarting (in the eyes of stream tracker on server side). Guessing there is some combination where things get stuck in some inactive layer. In the meanwhile, @bright-tiger-35509 said “For displaying the remote track on the screen. I am using this 
remoteTrack.track.mediaStream
Should I keep using this or create a new stream and add 
remoteTrack.track.mediaStreamTrack
to it.” Is that okay to use like that?
b
Just to give some more context, auto subscribe is off and adaptiveStream is also off.
p
is there a specific reason you are not using the 
track.attach(mediaElement)
function? that’s our recommended way of displaying the track
b
Yeah, the app is such we dont use that
p
generally using the 
track.mediaStream
should be fine
is there a reason why you decided against 
track.attach
? just curious to know your use case
b
We also observed that right after
Copy code
remoteTrack.setSubscribed(true);
remoteTrack.track.mediaStream
is sometimes undefined
Yeah, we just replaced our old sfu in the product and migrated to make it work with livekit.
p
ah, ok, that makes sense. when calling remoteTrack.setSubscribed(true) it will take a while until the track arrives. in the callback of 
RoomEvent.TrackSubscribed
the 
mediastream
should be available
f
@polite-kilobyte-67570 Would the direct access be an issue when a track is re-published. @bright-tiger-35509 has a user report where the second publish of a track was not seen by the remotes. The sequence is • Publish • Subscriber starts streaming • A few seconds later unpublish • A few second later re-publish • Server says it is locking to new layers. • But, user is reporting black screen forever. Could this be due to using previous mediastream (i. e. from first publish)?
b
Just to add more info, every time someone screen-shares
Copy code
const screenPubOptions = {
      simulcast: true,
      screenShareSimulcastLayers: [
        new VideoPreset(Math.min(1920, trackWidth), Math.min(1080, trackHeight), 600_000, 5),
        new VideoPreset(Math.min(1280, trackWidth), Math.min(720, trackHeight), 400_000, 5),
      ],
      source: Track.Source.ScreenShare,
    };
await room.localParticipant.publishTrack(track, screenPubOptions);
and when they stop sharing screen I do
Copy code
await room.localParticipant.setScreenShareEnabled(false);
Here is a case I found which I am able to repro. Already discussed with Raja: @polite-kilobyte-67570 1. I simulate bad network on publisher side, and I publish a new screenshare track on top of an already published screenshare track 2. I get this log 
Error: publication of local track timed out, no response from server
3. The publisher gains back best network and is no longer publishing screenshare, I get this log on publisher side 
TypeError: Cannot destructure property 'resolve' of 'this.pendingTrackResolvers[e.cid]' as it is undefined.
4. On the subscriber side even if I refresh on good network, I get the old stale screenshare track which is black, in fact every subscriber gets this stale screenshare track. 5. Now even if the publisher publishes new screenshare track and unpublishes it, the stale old track always stays.
Another case @fancy-wire-61616 @polite-kilobyte-67570 I observe that in some cases when repeating above steps, I have 2 video tracks in my screenshare mediaStream, 
remoteTrack.track.mediaStream.getVideoTracks()
1. MediaStreamTrack {kind: 'video', id: 'TR_VSNUn9AqW8XzTv', label: 'TR_VSNUn9AqW8XzTv', enabled: false, muted: false, …} 2. MediaStreamTrack {kind: 'video', id: 'TR_VCJigkSkb2ziU3', label: 'TR_VCJigkSkb2ziU3', enabled: true, muted: false, …}
p
yeah, the mediastream might change with/after a republish. you will have to make sure to use the correct mediastream after every 
TrackSubscribed
event. There’s a difference in how screen share and camera/microphone are handled. A screen share will actually be unpublished when calling 
setScreenShareDisabled
so the mediastream might change. microphone and camera “only” get muted when calling 
setCamera/MicrophoneEnabled
so you’re less likely to see a problem there I understand that there might be bigger things involved on the implementation change, but I guess you’ll run into less issues if you adapt a workflow that’s based on what our examples do (e.g. using track.attach).
🙏🏽 1
b
Thanks @polite-kilobyte-67570, what is your opinion on the case above ,
this is still reproducible, even if the subscriber refreshes and joins back , he can see the muted screenshare stream
p
that sounds like a bug! 2 is expected, 3 and 4 are not, do you want to open a GH issue about it on the client-sdk repo?
3 Views
Open in Slack
PreviousNext
Powered by