José Luis Millán

> Are we considering the RTX traffic sent from sender to mediasoup when we count the Producer bitrate? Yes, those RTX packets that where nacked are considered. https://github.com/versatica/mediasoup/blob/v3/worker/src/RTC/RtpStreamRecv.cpp#L392 > Does...

Looking at the provided webrtc-internals dump it can be seen that in the time the bitrate increases that much (around 20Mbps), there are 10 consumers which received bitrate increases (around...

@ibc, I guess you closed this one by accident.

As far as we have seen, the spatial layer selection done in SimulcastConsumer is correct. This moves the target to the codec implementation, which in the case of this exact...

> Will take a deeper look on Monday. Question: doesn't this affect H264 or VP9? I presume so, yes. I'm looking for side effects for this changes before applying them...

The requested RTP packet will be anyways forwarded. We won't call `VP8::PayloadDescriptorHandler::Process()` for it, which is totally correct. So the only concern `I had` (in past tense), about retransmissions being...

This is the only delicate scenario that I can think of. Ie: We are forwarding temporal layer 1 and the following payloads arrive: 1. [PID: 1, TID: 0] -> It's...

> I don't understand the first change in the diff referenced in your message. Why checking == target temporal layer instead of original check? In any case, if we want...

> At this point if the app decides to set the temporal layer to 1 again: [PID: 5, TID: 0] -> the current temporal layer is not updated, so it...

> so the packet context should honor what we already decided and never choose different things, right? Correct. [Some tests](https://github.com/versatica/mediasoup/compare/v3...jmillan:mediasoup:issue_989?expand=1) have been added