Bug Report Stream kb/s randomly tanks and stream fails.

So I've noticed an issue wherein seemingly at random, my bitrate will go down to single digits and eventually 0. If I refresh my twitich it will show that my stream configuration is incompatible. Somtimes it will say that my keyframe interval is some number other than 2 (like 8) or it will tell me that I need to be using h.264 video codec. I was thinking it was an OBS issue because switching from Quicksync H.264 to x264 will seem to provide a stable bitrate for the longest amount of time but eventually it will tank as well.

There doesn't seem to be any rhyme or reason to it either. I was able to steam for hours yesterday with seemingly no issue, but today I tried to stream from on location and I could not get a working stream up for more than a few minutes. I came home and tried to recreate the issue but everything seemed to work fine for like 13 and 45 minutes then the same issue occurred again. I'm including a log file, but a cursory glance through it didn't seem to reveal anything to me.

https://gist.github.com/anonymous/95f82f180950e7de4743dd4e647bc440

I'll add more if the issue happens again.

Edit: Happened again after an hour and 4 minutes or so
https://gist.github.com/5fd14f0111fb2d4c20857020b4f90777

Edit 2: and again after 28 minutes
https://gist.github.com/anonymous/ae5ea5ed92138cdeaefce8d8e9b505fb

Is this part of the Anniversary Edition update problems?
 
Last edited:
Hi,

Your logs are showing "Number of dropped frames due to insufficient bandwidth/connection stalls: " the first lost has it at around 16% therefore can you do the following,

1. Run a speed test and post the results for your internet connection both Down and Upload
2. Run the twitch bandwidth tool with 30sec, region you are in ticked and tcp set to 64
 

RytoEX

Forum Admin
Forum Moderator
Developer
There are reported but unconfirmed issues with Quick Sync streaming (but not recording) in 0.16.2 and up. None of your logs show a streaming attempt with x264, but you say that also has issues. Could you please provide us with a log streaming with x264 where you have this issue?

Please also work through the steps that @Beardedbob has listed.

I don't believe that this is related to the Windows 10 Anniversary Update.
 
Hi,

Your logs are showing "Number of dropped frames due to insufficient bandwidth/connection stalls: " the first lost has it at around 16% therefore can you do the following,

1. Run a speed test and post the results for your internet connection both Down and Upload
2. Run the twitch bandwidth tool with 30sec, region you are in ticked and tcp set to 64

1. http://speedof.me/show.php?img=161108000102-6492.png
2. http://i.imgur.com/VqPvVd1.png

I'll be working on generating more logs.
 

RytoEX

Forum Admin
Forum Moderator
Developer
A quality level of 80 is the minimum acceptable level for streaming, and issues can start occurring below about 95, if I recall correctly. Could just be a connection quality issue. =/
 
A quality level of 80 is the minimum acceptable level for streaming, and issues can start occurring below about 95, if I recall correctly. Could just be a connection quality issue. =/
That might explain issue I had streaming on location, at the shopm but I typically stream from there every week more or less without issue as long as I lower my bitrate.

I pretty much never run into issue streaming from home though.

I've been trying to see if I can recreate the issue again using x264 right now, but I've been streaming for over 2 hours and haven't encountered it yet. (twitch.tv/Ragnorok64)

I wish just switching to x264 was the answer, but it didn't work yesterday. Unless there was some sort of general internet issue in our area or something.
 
Well I've been streaming for 4+ hours with x264 and no issues. Had I not tried the exact same thing yesterday I'd say that fixed the problem but this just makes everything more confusing. I'm going to go ahead and switch over to quick synch again and see what happens.

Edit: Stream on quicksynck tanked after about an hour.
https://gist.github.com/fb16109a060d54be4d7848bf80b784f5

switching to x264 to see if the same thing happens again.
 
Last edited:
Sounds like ISP then, have fun and glad its working.
Not sure it's that cut and dry unfortunately. After the stream tanked with quicksynch after an hour, I switched to x264 again and managed to stream for like 3.5 hours straight. It's weird that x264 avoids the stream grinding to single digit kbps issue the best but it still had he issues yesterday. Additionally, qucksync typically works just fine and is kind of essential if I'm going to stream stuff like Overwatch.

I'm considering trying to roll back to a previous version of OBS Studio.
 

RytoEX

Forum Admin
Forum Moderator
Developer
As I said in an earlier post:
There are reported but unconfirmed issues with Quick Sync streaming (but not recording) in 0.16.2 and up.

You could try NVENC, but I can't promise it'll look good with Twitch's streaming bitrates.
 
Did an uninstalled and reinstalled 0.15.4. I've been up streaming with quicksync for 2 hours 40 minutes without incident thus far.
 

Andy-BDE

New Member
This totally explains the issues we have been having. Have tried every iteration of 0.16.x and have encountered the same issues OP experienced. Consistency between them is each comp uses QuickSync encoding method for streaming due to hardware shortcomings (x.264 for recordings). I guess we will just have to stick with 0.15.4 until this issue is remedied by the Devs, but I suggest a big BUMP for this.
 

RytoEX

Forum Admin
Forum Moderator
Developer
This totally explains the issues we have been having. Have tried every iteration of 0.16.x and have encountered the same issues OP experienced. Consistency between them is each comp uses QuickSync encoding method for streaming due to hardware shortcomings (x.264 for recordings). I guess we will just have to stick with 0.15.4 until this issue is remedied by the Devs, but I suggest a big BUMP for this.
As I've replied before to others in many other threads, none of the Quick Sync code has changed since 0.14.2, so this whole thing is perplexing. I have reached out to users who are reliably reproducing the issue they're describing to try to do in-depth debugging on this, but those efforts have stalled.
 
Top