Do I need to update sender parameters when removing a track?”

[Olivier Anguenot]

Hi all,
I have a small question for the following scenario:

- Bob calls Alice in audio and video

- Bob removes the video

There are several ways to do this scenario with the JavaScript APis:

- (1) Using peer.removeTrack(sender)

- (2) Using sender.replaceTrack(null)

- (3) Using transceiver.direction = "recvOnly" 

- (4) Setting the parameters encoding[0].active = false and then calling sender.setParameters(parameters)

- Other ways...

In scenarios (1), (2), (3), or a combination of (2) and (3), the active property in the outbound-rtp report from getStats() still shows true. 

These scenarios appear correct—no packets are being sent to the remote side. But is it normal that the active property remains true ? What does it mean ?

Should I explicitly set it to false to indicate that the media is intentionally not being sent? 

Thanks for any clarification

Olivier

[Harald Alvestrand]

1) 2) and 4) don't involve renegotiating the parameters of the peerconnection. 3) does.

setting direction doesn't affect whether the encoding is active - it puts a plug into the sending of packets, but if you renegotiate it to sendonly or sendecv again, the packets will start flowing without you touching the "active" parameter of the encoding.

At least that's my understanding...

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/d2b52ac3-bac7-4e95-8b17-7b4ff06f6839n%40googlegroups.com.

[Olivier Anguenot]

Thanks Harald for your quick answer,

In my scenario, peer.removeTrack() triggers a "negotiationneeded" at least in Chrome too.

To be more concrete, the specification says:

Dictionary RTCRtpEncodingParameters Members

active of type boolean, defaulting to true

Indicates that this encoding is actively being sent. Setting it to false causes this encoding to no longer be sent. Setting it to true causes this encoding to be sent. Since setting the value to false does not cause the SSRC to be removed, an RTCP BYE is not sent.

“My concern is that this property doesn’t accurately reflect the actual behavior. In scenarios (1), (2), or (3), the encoding is no longer being sent:

• In (1) and (2), the track has been removed, so encoding is no longer possible.

• In (3), the track is still present and encoding could occur, but frames are not being sent.”

And from the getStats side, there is the property "active" in the outbound-rtp report.

From the spec:

active of type boolean

Indicates whether this RTP stream is configured to be sent or disabled

Here I don't understand what is the meaning behind "disabled" and if this statistic is the exact translation of the encodings[0].active property.

To be complete, my core issue is that when computing statistics on a stream, I need to reliably detect when a stream transitions from active to inactive, so I don’t mistakenly flag intentional behavior (like disabling video) as a problem.

Is there a way to do this using only the WebRTC statistics API—without relying on application-level events (like clicking a ‘remove video’ button) or parsing the SDP? In other words, are the statistics sufficient on their own?”

--> For Outbound stream, I'm relying on the outbound-rtp.active statistic. 

--> For Inbound stream, I don't have an equivalent. So I take the statistic lastpacketreceivedtimestamp as an equivalent. But it can reflect something else...

Hope this clarifies what's unclear on my side :-)

Thanks

[Philipp Hancke]

there is a fifth way: stop the track (quite common actually since that turns off the camera light) without replaceTrack(null)

`active` in stats is literally the `active` from setParameters. Solves a particular use case (simulcast but you noticed you only need one layer) but does not go beyond that.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/d9142bf1-b3c6-4f0a-9d50-980a06101193n%40googlegroups.com.

[Olivier Anguenot]

Thanks Philipp, I forgot to add it in the list but I tested it too :-) 

As you said as it allows to turn off the camera light, I associate it to the other scenarios. But alone it does the job too.

For the test, I reused some CSS you should be familiar too :-)

[Olivier Anguenot]

Here is a recap of the tests done (using Chrome stable channel) 

My conclusion: 

- The methods where there is a (re) negotiation is needed, seems the most interesting from a statistics point of view because even by indirect properties, I think we can differentiate the cases both sides.

- For other methods, on the remote side, it seems to be difficult to differentiate both cases. At least it needs to have a look on the media event (mute event triggered on the video event).

- I don't know if there is another ways to have this information.

Note: One thing looks strange in all tests done: The qualityLimitationDuration still continues to compute time for a bandwidth limitation if it was the case before removing the video media.

[Philipp Hancke]

Interesting! And yes, those buttons do look familiar ;-)

Sounds like one should call SetReason with kNone more often in those cases, currently only done here:

  https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/send_statistics_proxy.cc;l=1190-1191;drc=7dd69f82df5dca9dd9fb76e315ccfbe7d3ab4a66;bpv=1;bpt=1

That would not explain why it only happens for bandwidth though. Do you have a fiddle?

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/b23a6e38-d02b-4f85-ad68-9688f992125dn%40googlegroups.com.

[Olivier Anguenot]

Hi Philipp,

I don't have the habit to use JSFiddle or equivalent.

Here is a link: https://jsfiddle.net/b0fy8hmd/2/
I hope it will work on your own. I needed to open an other fiddle to allow access to the microphone and camera for this domain

[Philipp Hancke]

this looks like it might be reasonable to fix by being more careful about incrementing those counters (any of them)

when the stats returned by

  https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/send_statistics_proxy.cc;l=749;drc=7dd69f82df5dca9dd9fb76e315ccfbe7d3ab4a66

are in "suspended_" state

Can you file a bug please?

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/878ae677-e8b6-4c59-aa02-4ca76899e4f9n%40googlegroups.com.