Question / Help Dropping frames since last update

[Toffees]

Hi guys,

Been using OBS for a while and have had no issues. Recently I had to re-install Windows therefore I reinstalled OBS using the latest version. As far as I can tell I'm using the same encoding/broadcasting configuration but I'm finding that I'm getting a lot of dropped frames especially in WoW when raiding. This could be something to do with the fact that my CPU is having to work extra hard, but its a 2700k running at 4Ghz with 16Gb RAM and it used to work no problem in the past. Has something changed or have I missed something in the config? Logs attached but for reference I'm streaming at 720p at 2300kbits (had to reduce it to 1900kbits mid raid to try and fix the problem).

I can't work out if this is a network latency issue (I'm running on a 10Mb upload connection) or CPU related.

 

[dodgepong]

Dropped frames are a network issue. Lower your bit rate or try a different Twitch server.

 

[Toffees]

I've lowered my bit rate from an already paltry 2300 to 1900. The London server is the lowest latency server that I can see according to JTVPing (13ms with 1.2ms Jitter). As I said, I've not had these problems in the past and the issue only seems to occur when I'm running a game and theres an intense period of activity like a boss fight in Warcraft. If it was a network related fault, then I would expect to see the issue occuring no matter what I was doing in-game, but if I'm just walking around doing nothing, no dropped frames.

 

[R1CH]

You aren't using CBR, so your bitrate is increasing past what your connection can handle during the high action boss fights.

 

[Toffees]

I have 10Mb upload and OBS is set to VBR and max cap at 2300 which is a quarter of my capacity. CBR is only necessary to smooth things with Twitch but isn't necessary with a good connection like mine. I use VBR to minimise the total amount uploaded.

 

[Boildown]

I have 10Mb upload and OBS is set to VBR and max cap at 2300 which is a quarter of my capacity. CBR is only necessary to smooth things with Twitch but isn't necessary with a good connection like mine. I use VBR to limit my minimise the total amount uploaded.

Sounds nice, but Twitch wants CBR now, they changed things. They could be rejecting your stream even if you have enough upload. Try CBR, do it for five minutes or so, then post a log file from that attempt.

If the problem remains, and it really is from the new version, you can prove it by downloading the old version where it worked better from here: http://sourceforge.net/projects/obsproject/files. When it asks you to update, decline. Use the exact same settings, stream for five minutes, then post that log file too. You might be right, but you'll have to prove it, and this is how you can do that.

 

[Toffees]

I'll give that a try. I'm not saying that it is OBS thats at fault. In trying to work out what the problem could be, you have to start by asking yourself what has changed? As you can see in the first post, I re-installed Windows and OBS but am using (as far as I can see) the same settings in OBS as before with the same network connection. Whereas it worked perfectly fine then, it isnt now so I was hoping the logs may point to either a) configuration issue or b) a driver or encoder mis-match.

I'll pop it into CBR when we're next online in a raid and see what happens.

 

[Toffees]

Problem solved, and as expected, it was nothing to do with VBR vs CBR or network latency. I downgraded all the way to 581 and still had the same problems as the original post to the point I was still getting dropped frames just standing still (same errors logged ie .

RTMPPublisher::SocketLoop: Stalled for 2054 ms to write 307614 bytes (buffer: 0 / 310272), unstable connection?

I then upgraded my intel HD3000 driver and installed Virtu. I'm not sure which item fixed it, but now I'm running a solid 2300bits VBR connection with 0 frame loss. Have just done a couple of raids and had no stuttering in Twitch at all. The moral of the story; read between the lines when reading logs as it may be something 'up stream' that is causing the delay, not downstream.