Inconsistency of Sending Bitate with Available Outgoing Bitrate #989
Comments
|
Even if mic is muted it's still generating bitrate. Can this be repeated after closing the micProducer? CC.disableMic() in console in sender. |
|
More things to be asked by us:
|
|
I've tried several times and didn't reproduce it. @sarumjanuch, could you please create a webrtc-internals dump so we can have eyes on the same data, by for example, importing it here https://fippo.github.io/webrtc-dump-importer/ ? |
|
It takes some time for this to happen. https://drive.google.com/file/d/1nvciwm9SW3KAUjAPHCQtMbQN9fs2YKar/view?usp=sharing |
Yes, those RTX packets that where nacked are considered. https://github.com/versatica/mediasoup/blob/v3/worker/src/RTC/RtpStreamRecv.cpp#L392
No, it's added to rtxSendBitrate. https://github.com/versatica/mediasoup/blob/v3/worker/src/RTC/Transport.cpp#L2680 |
Per stats dump we don't see any audio bitrate at the moment when this issue happens, that could explain this gap. All is from video bitrate. |
|
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 2Mbps). The others 10 don't. It looks like we are increasing the layer for those 10 consumers. |
|
@jmillan The one that i provided must include data for 3 peer connections 2 from sender 1 from receiver. BTW I thought that it may have something to do with my branch, so just in case, i just compiled latest v3 branch and was able to reproduce that, for me it usually takes 10-12 minutes for issue to appear. |
|
Attaching V3 dump just in case. |
|
Attaching another one with only 2 PC on v3 branch. This time it took way much longer for issue to appear. So be patient when importing webrtc-dump. |
… SVC consumers.
|
Not really related but anyway: #992 |
|
Attaching webrtc-internals with mediasoup debug log. webrtc_internals_dump_with_debug_log_1.txt |
|
As per logs of mediasoup in 12:45:17 we should receive only one 2:1 layer: But per webrt-internals dump 19 of 20 consumers are already receiving highest bitrate layer at that time. |
|
@ibc, I guess you closed this one by accident. |
|
Wow didn't notice |
Fixes versatica#989 * An old payload cannot upgrade the current temporal layer. * Update current temporal layer to the target one.
Fixes versatica#989 * An old payload cannot upgrade the current temporal layer. * Update current temporal layer to the target one.
Fixes versatica#989 * An old payload cannot upgrade the current temporal layer. * Update current temporal layer to the target one.
|
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 tests is VP8. Basically we are forwarding every old packet. Old being a lower This is a brave attempt to fix it, by no forwarding any packet which temporal layer is greater than the current one. I've tested locally and found no problems. But longer time tests will be conducted in order to see if this issue is fixed. This is the only concern I
NOTE: Once confirmed other codecs will be changed. |
I understand that the requested RTP packet MUST be forwarded right?
Here you say that the packet is drop.
Here you say that "above point" won't happen. Do you mean that packet won't be drop but correctly forwarded? In the other side, I don't understand the first change in the diff referenced in your message. Why checking == target temporal layer instead of original check? |
|
The requested RTP packet will be anyways forwarded. We won't call So the only concern
Why would we switch to whatever layer as long as it's greater than current? We should always change to the target layer specifically. Am I wrong? |
I'd lie if I said that I really understand how the whole logic in |
In any case, if we want to upgrade to a specific higher layer it will be to the target layer. The layer selection is done in the corresponding Consumer (Simulcast or SVC) implementation where we set the target layer based on available bandwidth. |
That's my understanding. We check, verify and so on layer changes in the Consumer and, once done, we tell it to the packet context via |
Correct. Some tests have been added |
During my work on BWE backport branch, I have noticed that mediasoup sometimes sends at higher bitrate than that which is reported by BWE algorithm. I tried to make this reproducible as much as possible so the setup is next: mediasoup-demo consumerReplicas branch running on the localhost, with two browser tabs opened on the same machine. Tab1: produce=false&consumerReplicas=19. Tab2: consumer=false&consumerReplicas=19. So we have single producer that produces simulcast stream, and 20 consumers replicas on the other side. Inside Trasnport.cpp I have hardcoded available bitrate to be 60 Mbps, it is never changing. Despite that this is what can be seen on graphs:
It seems that it correlates with packet loss:
In the same time RTX bitrate is relatively small to explain such a big gap:
webrtc-internals send side:
webrtc-internals receive side:
Distribution of available bitrate seems to be fine per logs: https://pastebin.com/inTDYp2Q, but actual sending bitrate is not.
chrome://webrtc-intenals for one of this cases: https://drive.google.com/file/d/1nvciwm9SW3KAUjAPHCQtMbQN9fs2YKar/view?usp=sharing
The text was updated successfully, but these errors were encountered: