CODEWITHSUNDEEP
webrtc
Tobic
Tobic

Reputation: 55

How to solve a problem with duplicating tracks sent between webrtc-peers

In my webrtc client program (javascript, debugging both peers on 1 localhost) negotiationneeded event is called 2 times.
Every time, geeting that event, I call getUserMedia and then addtrack() to send audio and video track to a remote, although I always use only 1 microphone and 1 camera and does not change their parameters.
So my program send total 4 tracks = (2 negotiationneeded events) * (2 tracks on every event).
I have noticed, that all the tracks of one kind, I have sent, were with different id's.
So when I scan all sent tracks (peerConnection.getSenders().track), I discover, that there are 4 track = 2 video + 2 audio.

The questions are:

  1. Why getUserMedia() returns the track of one kind with different id's ? Does it mean that there phisycally 2 different data "streams" (see P.S. below) with video or audio ? Or it is one stream but simply with different id's ?
  2. Is it correct, that getSenders() return 4 tracks ? Does it means that the remote will get 2 times more data (2audio + 2video), than it really needed (1 + 1) ?
  3. Who is responsible for eliminating duplicate tracks: my program (sender of the track) or it should be done by browsers or other options ? For example, should the sender check - if the video track already added to the remote and if yes, then call replacetrack() instead of addtrack() to eliminate duplicating ?

PS: in my question by streams I mean not a MediaStream object, but a real data stream with video or audio, flowing between webrtc-peers.

Upvotes: 0

Views: 211

Answers (1)

Ivan
Ivan

Reputation: 778

Short answer - you don't need to add the tracks again after you got negotiationneeded event.

The negotiationneeded just indicates that peers require an SDP offer-answer exchange so they understand how to transmit new tracks. This exhange is necessary for peers to agree on the codecs parameters to use. The tracks that you've already added to the connection will remain in place.

Therefore, in onnegotiationneeded callback you would typically have a new createOffer -> setLocalDescription -> send offer sequence.

  1. Tracks not only represent a media source, but also provdie media flow control. They can be stopped, temporary disabled, etc. That's why each time you get a new object with a new ID, so you have individual control over over tracks created even if they represent the same physical source. But keep in mind that under the hood these tracks might be encoded differently for different peers. So the data flowing between peers might not be the same even if it's from the same physical source.

  2. It is a consequence of adding the same tracks twice. Yes, you are probably sending the same data twice, you might check this on chrome://webrtc-internals page.

  3. Regarding media transmission, the sender side is responsible for it. The receiving side has limited control over the media being sent; it can ignore it, but the media will still flow.

Upvotes: 1

Related Questions