Simulcast Layer Events Are Not Transmitted As Soon As A Layer Becomes Unavailable

[EmersonGGS]

Version affected
0.1.26

Describe the bug
Scenario:

1. Client A Broadcasts with simulcast ENABLED
2. Client B Subscribes to Client A
3. Client A stops publishing the video layer Client B is subscribed to
4. Client B sees Client A's video stop
5. After a while (~10 seconds), Client B get a viewer layer event

Layer events are not triggered directly after a layer change occurs, if A client is subscribed to a certain video layer, and that layer becomes unavailable, the clients video stops until the next layer event where the application can select a layer that is still active.

To Reproduce
Steps to reproduce the behavior:

1. Open one publisher with simulcast enabled
2. Subscribe to the publisher
3. Observe video stops/stalls intermittently (more frequent with unstable or slow internet)

Expected behavior

1. Client A Broadcasts with simulcast ENABLED
2. Client B Subscribes to Client A
3. Client A stops publishing the video layer Client B is subscribed to
4. Client B receives a "layer" event and selects a new layer to display

Screenshots
In the screenshot the two viewer streams are frozen because both publisher layers went inactive, and the viewers had not received a new "layers" event.

Environment (please complete the following information):

• OS: Windows 11
• Browser: Chrome
• Version: 100.0.4896.12
  

[murillo128]

Detecting layer change is far from obvious in webrtc.

The current behavior is to trigger the layer events once each 5s so what you are describing is the expected behavior, so that's why I have removed the bug tag and replaced by the enhancement one.

By default webrtc disables simulcast layer in descending order based on the bitrate estimation, and I think it only disables the top one at most.

Note that you don't need to specify the LayerInfo when doing projection, and in that case the server will automatically switch between the available simulcast layers based on the bandwidth estimation.

Typically, what you would do is to use the LayerInfo to select the non top-most simulcast layer so the bandwidth is not allocated to this projection but to other more important ones.

[EmersonGGS]

Thanks, would you say the best way for a client to detect this (in current state) would be to listen for video track mute state?