You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the estimated bandwidth is close to the lowest SVC layer, the allocated layer fluctuates between 0:0 and -1:-1. Concurrently, we observed large packet loss spikes at receiver side (80-100%) that didn't happen when using VP8/Simulcast in the same conditions. Analyzing the captured RTP packets, there are large seqno jumps that could explain the packet loss:
The issue can be reproduced consuming 1 VP9 stream and calling transport.setMaxOutgoingBitrate(80000) (set a number close to the lowest encoded SVC layer).
The text was updated successfully, but these errors were encountered:
It's been very complicate taking the time to check this lately. I can't say when I'm going to be able to check this.
Meson option ms_rtc_logger_rtp will print a log line for each RTP packet sent or dropped by mediasoup indicating the cause in case of drop, which would be a good way to troubleshot this. In case anyone is willing to dig further.
cd worker && MESON_ARGS="-Dms_rtc_logger_rtp=true" make
Bug Report
When the estimated bandwidth is close to the lowest SVC layer, the allocated layer fluctuates between 0:0 and -1:-1. Concurrently, we observed large packet loss spikes at receiver side (80-100%) that didn't happen when using VP8/Simulcast in the same conditions. Analyzing the captured RTP packets, there are large seqno jumps that could explain the packet loss:
nopatch.pcapng.gz
The issue can be reproduced consuming 1 VP9 stream and calling
transport.setMaxOutgoingBitrate(80000)
(set a number close to the lowest encoded SVC layer).The text was updated successfully, but these errors were encountered: