Jaya & Jonathan, my developers tell me they don’t see those particular calls in 5142. Has the safari workaround been removed? Or is the safari workaround hiding some other place in the code?
Jonathan — we have your PR working with 5142 and it’s already in the hands of my testers. In addition we see no sign yet of the freezing problems that initiated this recent burst of activity! Without further issues, we should have your vp9 PR in the hands of live users by next week!
Hi @Jonathan_Lennox – Just a quick update: Our 5142 build with your PR passed our testing round and is now in the hands of live users! So glad you did this PR and the recent update. VP9 is truly stunning. Thank you again!
It doesn’t reproduce very often… and when it does, it seems to be because one of the participants dips below 3mbps estimated bandwidth. But 3mbps should be enough for two simultaneous video feeds, unless the bitrate controller code is incorrectly using the highest quality VP9 level for calculation instead of a medium level – something like that.
Any ideas? Anything you might want from us? Not sure the logs would help in this case.
If we add “org.jitsi.videobridge.TRUST_BWE=false” in /etc/jitsi/videobridge/sip-communicator.properties then the VP9 freezing problem in gallery view (tile view) goes away.
I believe that confirms my suspicion posted above that the VP9 adaptivity logic is computing the required bandwidth incorrectly, causing it to only forward frames for the dominant speaker in gallery view, even when there is low-but-still-sufficient bandwidth. In low-but-still-sufficient bandwidth conditions, the tile-view adaptivity logic should be forwarding the lower-quality layers and it should be using the lower-quality layers’ bandwidth in the calculation.
That either ruins the bandwidth savings for the active video sources or breaks with encryption of the streams later because no transcoding of video is possible. Doesn’t sound like a good idea doing it this way.
Yes this is the plan. we are in the process of implementing this in the client. When a participant that doesn’t support VP9 joins a VP9 call, all the participants will switch to VP8 automatically and switch back to VP9 when that participant leaves.
Oops! @jallamsetty I assumed that because you were making an exception for Safari to work in a VP9 environment that meant any client that didn’t support VP9 would just stay on VP8 while others ran in VP9. With this clarification now, I have to ask: will we have the option to enforce only VP9 connections in our environment (beyond merely banning Safari or the like)?
This means that clients that do not support VP9 will not be able to decode video from the clients sending VP9 if everyone doesn’t fallback to VP8. You would see only black screens on the VP8 only client which doesn’t make sense. I haven’t thought about the option for enforcing VP9 only connections, the plan was to make the codec selection logic generic so that we can do the same for any future codecs like AV1.
I definitely see your point here and I agree with you. However, for most of us who are early adopters of VP9, it’s often for the outweighing benefits that it offers; benefits we won’t want to lose just because one client can’t connect on VP9. It’s easier for us to demand that users connect using VP9-capable clients (for instance, I already enforce a ‘ban’ on Firefox because of its many vagaries and I nudge my users to use the Electron app). Although enforcing VP9 means ios clients can’t connect (for now), that’s a price I’m willing to pay. Having everyone ‘downscaled’ to VP8 on the other hand, no buenos! So yes, the flag enforcePreferredCodec would be very useful.
UPDATE: We fixed our VP9 video-freezing-in-tile-view problem by updating CLIENT-SIDE settings. Namely, simulcast needs to be enabled even though VP9 uses SVC instead of simulcast. If Simulcast is disabled, VP9-encoded video is still sent, but it’s sent in such a way that the server doesn’t decode the available layers, giving it no choice but to forward full resolution of all videos, even in tile view. In low/moderate bandwidth conditions, that results in only the active speaker’s video being forwarded sometimes.