3 second freezing?

[Brad Thomas]

We are doing some live streaming at 2mbps. Every now and then, we get a 3 second freeze (which I'm assuming is from packet loss). Audio continues, but video freezes. The worse the connection (i.e. wifi), the more 3 second freezes there are. I'm assuming that after 3 seconds, another key frame is requested which is why the video starts up again. Is there any documentation you could point to on how to speed up recovery of a frozen stream? From your own experience, how quickly should webrtc recover? 

The quicker a video stream can resume the happier our client will be. Thank you!

[Philipp Hancke]

are you not implementing NACK? this sounds like NACK does not work and then there is a PLI which causes a new keyframe.

2018-08-01 19:43 GMT+02:00 Brad Thomas <voc...@gmail.com>:

We are doing some live streaming at 2mbps. Every now and then, we get a 3 second freeze (which I'm assuming is from packet loss). Audio continues, but video freezes. The worse the connection (i.e. wifi), the more 3 second freezes there are. I'm assuming that after 3 seconds, another key frame is requested which is why the video starts up again. Is there any documentation you could point to on how to speed up recovery of a frozen stream? From your own experience, how quickly should webrtc recover? 

The quicker a video stream can resume the happier our client will be. Thank you!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6371fc51-5d72-444c-bf60-ea11c1057a37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Thomas]

Thanks for the reply Philipp. You are correct about the PLI and the new key frame. I need to check on the NACK question. In your experience, if NACK is implemented correctly, how quickly should it recover?

On Wednesday, August 1, 2018 at 10:45:53 AM UTC-7, Philipp Hancke wrote:

are you not implementing NACK? this sounds like NACK does not work and then there is a PLI which causes a new keyframe.

2018-08-01 19:43 GMT+02:00 Brad Thomas <voc...@gmail.com>:

We are doing some live streaming at 2mbps. Every now and then, we get a 3 second freeze (which I'm assuming is from packet loss). Audio continues, but video freezes. The worse the connection (i.e. wifi), the more 3 second freezes there are. I'm assuming that after 3 seconds, another key frame is requested which is why the video starts up again. Is there any documentation you could point to on how to speed up recovery of a frozen stream? From your own experience, how quickly should webrtc recover? 

The quicker a video stream can resume the happier our client will be. Thank you!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Philipp Hancke]

if NACK works and the round-trip time is low enough the user won't experience any glitches. If this is screwed up somehow (and there are many ways to do that) you get those unpleasant freezes.

Usually the best way to test that is to run a localhost experiment (for low rtt) with 2-3% artificial packet loss (e.g. using linux tc qdisc).

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d9b765d1-a90c-4db1-a3a9-28d3269496de%40googlegroups.com.

[br...@evercast.us]

Ah, ok. We'll investigate. Thank you for taking the time to respond. 

On Wednesday, August 1, 2018 at 11:51:31 AM UTC-7, Philipp Hancke wrote:

if NACK works and the round-trip time is low enough the user won't experience any glitches. If this is screwed up somehow (and there are many ways to do that) you get those unpleasant freezes.

Usually the best way to test that is to run a localhost experiment (for low rtt) with 2-3% artificial packet loss (e.g. using linux tc qdisc).

2018-08-01 19:49 GMT+02:00 Brad Thomas <voc...@gmail.com>:

Thanks for the reply Philipp. You are correct about the PLI and the new key frame. I need to check on the NACK question. In your experience, if NACK is implemented correctly, how quickly should it recover?

On Wednesday, August 1, 2018 at 10:45:53 AM UTC-7, Philipp Hancke wrote:

are you not implementing NACK? this sounds like NACK does not work and then there is a PLI which causes a new keyframe.

2018-08-01 19:43 GMT+02:00 Brad Thomas <voc...@gmail.com>:

We are doing some live streaming at 2mbps. Every now and then, we get a 3 second freeze (which I'm assuming is from packet loss). Audio continues, but video freezes. The worse the connection (i.e. wifi), the more 3 second freezes there are. I'm assuming that after 3 seconds, another key frame is requested which is why the video starts up again. Is there any documentation you could point to on how to speed up recovery of a frozen stream? From your own experience, how quickly should webrtc recover? 

The quicker a video stream can resume the happier our client will be. Thank you!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6371fc51-5d72-444c-bf60-ea11c1057a37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[br...@evercast.us]

We've been doing a lot testing. We still receive 3 second freezes. Around 15-20 per 90 minutes. Not sure exactly what causes them (we believe it's possibly packet loss) but each freeze is the exact same length of 3 seconds. Does anyone know if this a default number built into Chrome? We found the following links and wonder if anyone in the webrtc community can shed some light on why the freezes are exactly 3 seconds long. Your input is greatly appreciated! 

https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_stream.cc?rcl=4e5af96606b94b048132cbf61514fa2b12cb0edc&l=398

and this

https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_stream.cc?rcl=4e5af96606b94b048132cbf61514fa2b12cb0edc&l=452

[Basar Daldal]

Hi,

Is there any way other than NACK support to get rid of the 3 seconds delay? What I see is, even a single packet loss may cause this problem if remote side does not support NACK. In our case, remote side actually supports NACK PLI and this helps the recovery after 3 seconds but the 3 seconds delay in any packet loss case is creating bad user experience.

Thanks,

Basar

On Wednesday, August 1, 2018 at 9:51:31 PM UTC+3, Philipp Hancke wrote:

if NACK works and the round-trip time is low enough the user won't experience any glitches. If this is screwed up somehow (and there are many ways to do that) you get those unpleasant freezes.

Usually the best way to test that is to run a localhost experiment (for low rtt) with 2-3% artificial packet loss (e.g. using linux tc qdisc).

2018-08-01 19:49 GMT+02:00 Brad Thomas <voc...@gmail.com>:

Thanks for the reply Philipp. You are correct about the PLI and the new key frame. I need to check on the NACK question. In your experience, if NACK is implemented correctly, how quickly should it recover?

On Wednesday, August 1, 2018 at 10:45:53 AM UTC-7, Philipp Hancke wrote:

are you not implementing NACK? this sounds like NACK does not work and then there is a PLI which causes a new keyframe.

2018-08-01 19:43 GMT+02:00 Brad Thomas <voc...@gmail.com>:

We are doing some live streaming at 2mbps. Every now and then, we get a 3 second freeze (which I'm assuming is from packet loss). Audio continues, but video freezes. The worse the connection (i.e. wifi), the more 3 second freezes there are. I'm assuming that after 3 seconds, another key frame is requested which is why the video starts up again. Is there any documentation you could point to on how to speed up recovery of a frozen stream? From your own experience, how quickly should webrtc recover? 

The quicker a video stream can resume the happier our client will be. Thank you!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6371fc51-5d72-444c-bf60-ea11c1057a37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Francesco Pretto]

On Wednesday, August 1, 2018 at 7:45:53 PM UTC+2, Philipp Hancke wrote:

are you not implementing NACK? this sounds like NACK does not work and then there is a PLI which causes a new keyframe.

I am also experiencing issues as described by Brad from a single JS host connecting to a Native host. The JS host is in a network I have no control. Attached is the INFO log of the connection on the Native peer. I'm seeing many lines like this:

    

    (nack_module.cc:243): Sequence number xxxx removed from NACK list due to max retries.

I lose 5-6 seconds of frames and after the connection stabilize. The problem is that this problem is systematic with the host in this apparently faulty network. Tonight I'm trying to see if disabling reflexive candidates, allowing only relay ones, makes a difference, or disabling IPV6 candidates. In the mean time the question is: why these peers systematically choose an unreliable candidate pair? JS host is Chrome 72 while Native host is WebRTC M68 based. Any recent update may help here? Or is there any tweak I could do on JS/native sides to improve the reliability of this connection?

Thank you,

Francesco

 

[Francesco Pretto]

Ok, I tried filtering candidates from stun and ipv6, and it didn't improve reliability of the connection at all. Maybe it's actually the relay connection that is problematic.

Unfortunately this time I forgot enable logging webrtc native side, but I had other logs enabled which showed me the actual frame timestamps which I was receiving.

I attached fps over time graphs (more precisely is 1/diff(t) over t) of two sessions. I'm assuming SCTP is in act here to regulate connection parameters: in the first session it took around 11 seconds to stabilize the connection at good framerate. In the second session it took around 15 seconds to stabilize the connection at higher fps with still visible hiccups.

Question: can all of this be normal? 15 seconds is an huge time. Is there any way I can tweak connection from Native side so connection will stabilize sooner? I don't mind high fps, I just need it to reach a stable frame rate as quick as possible. I remind: I was still using M68 at the moment of the tests. I'm migrating to M72, though.

Cheers,

Francesco