All consumer videos freezes at the same time at random intervals

mediasoup libraries
1

I have mediasoup v3 deployed on a $10 DigialOcean VPS. I’m using it to steaming 1080p desktop video and audio at a max bitrate of 6000kbps (for watching video games). The SFU is working great but I’m encountering a few issues. I’m not using 100% of anything. I’ve only reached 20% CPU and 30% RAM usage.

1.) Anyone watching the stream will have the video freezes and unfreezes for a second every once in a while. Could it be my mediasoup config or the networking?

2.) If the producers video lowers the bitrate (because of less changes to the video), the bitrate will either slowly increase when more thing happen on screen (resulting in temporary lag / low quality) or the video bitrate wont increase and I have to restart the producers video to fix it.

Based on these issues do you think are from my hosting network or my configuration with mediasoup?

2

First of all, are your Producers sending VP8/H264 simulcast or VP9 SVC?

1 Like
3

I believe the codec type is defined in the server-side router config correct? If so, I’m using VP8:

router = await worker.createRouter({
        mediaCodecs: [
          {
            kind        : "audio",
            mimeType    : "audio/opus",
            clockRate   : 48000,
            channels    : 2
          },
          {
            kind       : "video",
            mimeType   : "video/VP8",
            clockRate  : 90000,
            parameters :
            {
              "packetization-mode"      : 1,
              "profile-level-id"        : "42e01f",
              "level-asymmetry-allowed" : 1
            }
          }
        ]
      })

On the front-end I’m not using simulcast I believe.

this.producer = await this.transport.produce({
        track: this.track,
        codecOptions: {
          videoGoogleStartBitrate: 1000,
          videoGoogleMaxBitrate: 6000
        }
      })
4

Assuming you are using latest Chrome stable, there is a bug in libwebrtc that’s being fixed (but not yet) and makes Chrome to not send RTP retransmission packets when the receiver (mediasoup in this case) requests them via RTCP NACK:

https://github.com/versatica/mediasoup/issues/335 (please take a look to it)

A workaround has been added to mediasoup “devel” branch, but it’s not yet merged in “v3” branch (so no NPM release yet). A different workaround would be:

Avoid the RTP MID header (see the issue above). but for that you must make your senders use the mediasoup-client “Chrome67” handler (instead of the auto-detected “Chrome70” or “Chrome74”:

BTW if you are sending a 6000kbps without simulcast, it means that all receivers will receive 6000kbps (no matter then cannot due to limited downlink). I recommend you using simulcast so mediasoup will adapt the best layer (up to the “preferred layers” set via API in each Consumer) for each receiver.

In addition to that, the “devel” branch uses transport-cc bandwidth estimation for receiving and sending, which is MUCH better than current mechanism in mediasoup v3 (based on old REMB).

“devel” branch is not yet merged into v3, but if you add simulcast I encourage you to give it a try.

1 Like
5

Awesome, thanks so much! I’ll check out the devel branch and add simulcast. When it comes to simulcast though, does that mean that the producer will send multiple streams to the server, which will use more bandwidth? That’s what I thought it meant.

6

Yes. The thing is that, if you just send a 6000kbps RTP stream and a receiver cannot handle 6000kbps, the Internet connection of that receiver will just break. With simulcast, mediasoup will be able to send a lower bitrate stream to that poor receiver.

1 Like
7

I have run into the same issue, and i have tried the devel branch, the probability of video freeze is lower, and the time interval is longer than v3, but it still freezes random.

8

I don’t know your scenario, so hard to help. However, there are Producer and Consumer stats that provide pliCount and nackCount values. We can not do magic.

9

sorry for the missleading. It happens randomly, i am still collecting relevant status,
and just saw this post, want to share this information.

1 Like
10

Maybe something with your setup? Because switching to the devel branch fixed it completely for me. I’m not too savy on the in’s and out’s of this problem though.

11

thanks，i’m collecting information to see if there are any pattern.

12

So it appears that switching to the devel branch has fixed the freezing issues I talked about, but I still get quality drops. Sometimes if nothing happens on screen for a while, when something does happen, it either takes forever (more than 10 seconds) to increase the bitrate, or it never increases and I have to re-create the producers and consumers all over again.

13

The bitrate of who?

1 Like
14

Sorry, I’m having bitrate issues with the producer. I never have any issues with consumers.

15

Unless you are using transport.setMaxIncomingBitrate() in server side or special encoding (with maxBitrate field) in client side Producer, I’m afraid mediasoup cannot tell the browser how much bitrate It must send.

18

Sorry, reopening. This and other topics were closed in the past by error.

Please let me know current status:

  • Does the issue happen by just producing? (Without any consumer)
  • mediasoup version (important: try the very latest, two bug fixes in there).
  • paste await producer.dump() in server side.
19

Thanks for reopening this.

  • Yes, I just tested it on the latest version
  • 3.5.12
  • I looked around the documentation and recent commits and couldn’t find info on producer.dump() anywhere, so I’m not sure where to put it.
20

It’s not documented:

await producer.dump() => returns an Object