Differentiate between screen share track and camera track in a normal webrtc

Question

Is there any way to differentiate between screen share track and camera track in a webrtc video call?

I am able to add both video tracks(camera as well as screen share track) using proper negotiation event.But,I cannot differentiate these 2 tracks (Since they both have property of kind video and their id seems to be randomly generated and is different to the id of actual owner of the track )

I also went through couples of few similar questions that suggested the following things:

1.Differentiating using their ID.

This solution did not work for me because as soon as i will re-share my screen(after stop sharing and then sharing again),a new id will be assigned to the track coming from resharing.

2.Differentiating using transceiver.mid property

This too did not seem to work because while turning off the camera,camera track is removed from the peer instance(to save the bandwidth) and is added back when turning on the camera.This calls ontrack event on the remote side in which track has different transceiver.mid property(not same as what mid property previous camera track had)

In addition,I cannot assign any extra property to the stream obtained from getUserMedia api.track object seems to be immutable.

Please suggest a method which i can use to differentiate these 2 tracks.

Thanks

Answer 1

Based on my Observation, I think you have the following options to make it possible:

• The most simple solution is to disable the video track whenever user wants to turn off the camera.
• The second solution is to generate a new peer instance for adding the screen track.This approach is widely used in most of the production app.

Answer 2

As far as I know, mid and rid are the only properties of a track that are preserved end-to-end (the id is not preserved). Thus, your approach of using the mid is probably the correct one.

As you justly note, mids might be recomputed whenever a track is removed from the peer connection. You have two solutions to the issue:

• maintain a mapping between ids and mids, and recompute the mapping whenever you renegotiate;
• never remove a track, and use the enabled property of the track to stop sending video data.

The latter solution is simpler, and avoids the need to perform a round of signalling when the camera is disabled. (When one side sets enabled, the other side should notice and set muted on the corresponding remote track.)