This message was deleted.
# announcements
s
This message was deleted.
d
you can probe by sending larger padding packets. we do it here.
f
We have seen it grow a little faster than that. Going from mid layer which is around 600 kbps to high layer at 1.7 Mbps happens in about 15 - 18 seconds the last I measured. I was attributing the slowness to the REMB algorithm too and the delay based BWE that is used with TWCC could be faster. That is a speculation on my part and unconfirmed. With temporal layer filtering with VP8 (H.264 does not have temporal layers), we can actually move to high spatial layer sooner at lower fps and then catch up with further probing. David, padding packets will be limited to 255 bytes because of RTP limitation, but we send a bunch at a time.
👍 2
d
sorry I misread the question. thanks Raja for the clarification!
a
Going from mid layer which is around 600 kbps to high layer at 1.7 Mbps happens in about 15 - 18 seconds the last I measured.
And you achieve this probing with padding packets only? In our case it's impossible to achieve such results. We spend at least 2 minutes to get into 1,5Mb/s. We must be doing something wrong
f
Yeah that is using padding packets only. I am sure you have done this, but just wanted to check if you ensure sending padding only at frame boundaries. Also this measurement is using Chrome. I don’t remember the details for Safari/Firefox. But they are in the same range.
a
Yeah, we are probing at frame boundaries. Anyway, thank you very much! That's really helpful 🙂
Just wanted to say that we finally debugged the problem and it turned out that we had a bug in our GCC implementation. We were calculating exp moving avg over all r_hats while we should use only r_hats from the decrease state. Because of that we were starting in multiplicative mode but pretty fastly going into additive mode and the whole estimation was slowing down. Thanks a lot for the help!
f
Great to hear that you found the issue Michal!!!