Video Freezing in Chrome #156
Comments
|
Just before 7:55 nacks and plis increase and received frame rate drops to On Tue, Mar 1, 2016 at 2:59 PM, Marcus Stong notifications@github.com
|
|
We aren't using simulcast, it's true. I'm glad you actually bring up RTCP termination. The documentation is outdated, and we aren't sure how to make it work. We'd like to enable what was Maybe setting it correctly might fix the issue? |
|
HQRTS no longer exists, I would suggest to either enable org.jitsi.videobridge.rtcp.strategy=org.jitsi.impl.neomedia.rtcp.termination.strategies.BasicRTCPTerminationStrategy On Tue, Mar 1, 2016 at 3:15 PM, Marcus Stong notifications@github.com
|
|
We tried with BasicRTCPTermination, but it was throwing an index out of bounds exception. |
|
Video is still freezing. It's pretty easy to reproduce right now on https://talky.io with 3+ callers as I haven't rolled back yet. |
|
Hi Marcus, in order to help us understand the situation we need logs from Best, On Thu, Mar 3, 2016 at 10:34 AM, Marcus Stong notifications@github.com
|
|
P.S. before you get any logs from the bridge, it would be helpful to set On Thu, Mar 3, 2016 at 10:40 AM, George Politis gp@jitsi.org wrote:
|
|
George, thanks for the help! I think the graph above should suffice then. Here's a sampling of the logs https://ghostbin.com/paste/adfg9 |
|
george: http://fippo.github.io/webrtc-dump-importer/ gives you nice graphs in a matter of seconds. Zoomable even. |
|
Hey @fippo is there a way to make those dumps from js code, I'm asking whether it is possible to do the dumps while selenium testing? Thanks. |
|
@damencho do you know your own code? :-p |
|
Thanks @fippo! @marcus The log snapshot that you shared is filled with XMPP ping timeouts You can add the following 2 lines to the sip-communicator.properties file org.jitsi.service.neomedia.VideoMediaStream.REQUEST_RETRANSMISSIONS=false Try that and let us know how it goes. Best, On Thu, Mar 3, 2016 at 10:53 AM, Marcus Stong notifications@github.com
|
This could well indicate a problem with packet retransmissions, which could explain the freeze. We don't run into it, because we haven't yet enabled RTX. One reason for the bridge not finding the SSRC could be that it wasn't signaled to it. Can you include more of the logs? Specifically the RECV/SENT lines. Also make sure you are using a recent bridge version (which includes Lance's fix). |
|
Just found a little bug, preparing a fix. You may want to delay your testing a bit. |
|
okay great. I'll test on our stage site as soon as you let me know. |
|
Videobridge 672 includes the fix. |
|
Deployed 672 with and without suggested NACK settings, and unfortunately it doesn't work at all now Going to rollback one version and test with NACK settings as well. |
|
670 with suggested NACK settings passes staging tests. |
|
Not sure what the problem with 672 is, possibly just the package was not properly built. In any case, if you get a chance to test this on 672+ without disabling NACK termination, please let us know. |
|
Still freezing in production on 670 with NACK changes. Will give a release > 672 a try |
|
Hi Marcus, did you have any better luck with jvb > 672? I've had a On Fri, Mar 4, 2016 at 12:39 PM, Marcus Stong notifications@github.com
|
|
Still freezing in 681 |
|
Disabling RTX seems like a promising fix. Wasn't able to reproduce freezing on stage. Will confirm for sure with production deploy Monday. |
|
Been running 681 for most of the week with RTX disabled in production. |
|
Thanks for the feedback, @stongo! We should be looking into enabling RTX in jitsi-meet in the next couple of weeks, will let you know if we find any issues. |
|
@stongo how did you disable RTX as you mentioned above? |
|
An update on this: we've been working on RTX in the last couple of weeks. We fixed multiple issues, and as far as we know current videobridge versions work correctly with RTX. So, I think this is ready for testing. We are not yet enabling it in jitsi-meet, because we are running into some problems managing SDP when muting/unmuting (these are jitsi-meet specific issues). |
|
@bgrozev awesome, I'll give it a try on staging again and let you know @davidertel are you using Jitsi Meet or something else? |
|
We've been looking at retransmission in general (not necessarily Just a heads up on something we've seen...we want to gather some more data On Thu, Apr 14, 2016 at 12:39 PM, Marcus Stong notifications@github.com
|
|
@stongo We (Dave and I and company) are using a web client with jingle.js via a focus controller a la talky (but it's our own node.js focus controller). |
|
You need to remove the "a=rtpmap:XXX RTX/90000" lines from the SDP you pass to your clients. |
|
I've found that more often than not, filing the bug early leads to quicker results. The Chrome team is helpful in identifying workarounds and fixes. We can nudge them for feedback. If you have a dump showing that behavior, let's get it filed with all the info we have. I'll try to get one as well. |
|
no chrome bug here... |
|
We're getting freezing without including rtx in the sdp. |
|
We just repro'd freezes on apprtc by limiting uplink bandwidth on one sender to 1.5mbps. We see it with h264 and vp8...it detects the available send bandwidth correctly, but with rtx regularly goes over it which causes more loss and freezes (chrome will also refuse to send rtx if it's bandwidth is too high, so I think there's a bad cycle here that causes problems). We just got some screenshots from webrtc-internals and are going to file something today. |
|
Filed against chrome here https://bugs.chromium.org/p/webrtc/issues/detail?id=5797 |
|
Where do we stand on this issue? The linked issue to chrome appears closed without anything resolved? We are running into this issue constantly making jitsi unusable for any production type use. This is happening with our own installs, regardless of patch level, as well as the demo at http://meet.jit.si. A symptom is extremely high packet loss once an endpoint has less than 1.5mbps available. The video will intermittently freeze for upwards of 5 to 15 (or more) seconds. |
|
Any update on this? We are considering a switch to jitsi-videobridge -- however, random freezing on Chrome could be a non-starter. |
|
In regards to my previous comment about the chrome issue ("brianh5" above), we found that the way we were simulating low bandwidth links was inaccurate (network simulator on mac, for example, will do loss to simulate a lower-bandwidth link, but not add any delay--chrome keys quite a bit on the delay to lower the bandwidth estimation), once we properly simulated things we no longer saw that issue so told them they could close that bug. I also found a bug a couple months ago in the porting of the webrtc bandwidth estimation logic on the bridge that was failing to take delay into account (jitsi/libjitsi#212). Fixing that resulted in much better performance on links with high delay (common for poor links that also have low bw). Other than those 2 scenarios, I wasn't aware of any other freezing issues with chrome. |
* add ability to parse bandwidth from a string * allow space between amount and unit * tweak test * change units string to lower case * add case test
* add ability to parse bandwidth from a string * allow space between amount and unit * tweak test * change units string to lower case * add case test
* add ability to parse bandwidth from a string * allow space between amount and unit * tweak test * change units string to lower case * add case test
Using new versions of the bridge, have been experiencing random freezing of the video channel. Doesn't occur for every participant.
I've included a webrtc-internals graph showing it happening just before 7:55pm. Nothing abnormal in bridge logs or our clients log (not using jitsi meet). We ended up rolling back to version 564 where this does not happen.
The text was updated successfully, but these errors were encountered: