Fix #492 SimulcastConsumer cannot switch layers if initial tsReferenc…

[Lynnworld]

…eSpatialLayer disappears

We found the same issue as #492 described . If we do't get initial tsReferenceLayer SR , we can't switch latter.

Fixes #492

[ibc]

Love this PR. Thanks. Will merge next week and release.

[ibc]

@jmillan

[ibc]

Please add an entry in CHANGELOG file

[jmillan]

👍

[ibc]

There is a bug but unclear whether it's introduced by this PR or not:

If the Producer has 3 encodings (so 3 simulcast spatial layers 0,1,2) and the encoding in the middle (encoding 1) has active: false, then when the consumer calls setPreferredLayers({ spatial: 1 }) mediasoup selects layer 2 instead of 0.

Nah, confirmed that it also happens in v3 branch.

[ggarber]

With this change can it happen that we start forwarding spatial layer 2 before having a SR for that layer and then we switch to other layer when we receive a SR for that new layer?

I that case how can mediasoup maintain continuous timestamps if it doesn't have the SR of layer 2?

[ibc]

Nothing has changed regarding that. If no SR has been received for any spatial layer (simulcast stream) mediasoup selects the first available stream. If layer SR arrive for one or more layers then mediasoup could of course switch to them if there is SR for that layer and if that spatial layer is equal or lower than preferred spatial layer.

HOWEVER while testing this PR locally I've seen and reported a bug that was there since ever. Check the most recent created issue in GH.