Question / Help High Encoding after 9 hours live

8

8ull

New Member
I have been continuously troubleshooting "High Encoding" and have narrowed it down to 2 major issues from the OBS Logs. The first being "Slow sources detected" and the second being "Hook conflict detected". The hardest part is recreating the issue since it takes 9 hours to present itself. If I restart the stream by ending and starting again the problem is gone until I get to the 9 hour mark. I have no idea how to read the log beyond the analyzer so I am basically looking for the cause (program or setting) from anyone who can. If you need more info please ask, thank you for helping!

Here is the most recent log with slow sources detected
https://gist.github.com/242adc13a41e339d79ec

Here is the one before it with the hook conflict detected
https://gist.github.com/c6102e02f349de43f294
 
8ull said:
I have been continuously troubleshooting "High Encoding" and have narrowed it down to 2 major issues from the OBS Logs. The first being "Slow sources detected" and the second being "Hook conflict detected". The hardest part is recreating the issue since it takes 9 hours to present itself. If I restart the stream by ending and starting again the problem is gone until I get to the 9 hour mark. I have no idea how to read the log beyond the analyzer so I am basically looking for the cause (program or setting) from anyone who can. If you need more info please ask, thank you for helping!

Here is the most recent log with slow sources detected
https://gist.github.com/242adc13a41e339d79ec

Here is the one before it with the hook conflict detected
https://gist.github.com/c6102e02f349de43f294
Click to expand...
Well I will post exactly what is out of standard from normal streams so if what you have works for you, then take it with a grain of salt:

scene buffertin to 700ms. this is sort of the new standard. there should be little to no negative drawback with raising this.
use window or game capture with windows 7 aero enabled. this will cause high encoding often with high screen movement. this is because windows 7 is not optimal with monitor capture. please use another method.

things like webcams, text, or pictures/overlays that you use in each scene need to be global sources. this will make it so its available at an instant instead of having to load up the scene when you press the button.
 
I have changed the buffering to 700ms but can you explain what that does exactly? Almost all guides and tutorials I have read for Twitch say 400ms is the correct buffer. I use windows 8.1 and therefore no aero. I have moved a monitor capture source to a global monitor capture source. Should all my text and notifiers be global sources as well?

I will see if these changes affect anything on my long cast on Wednesday.
 
8ull said:
I have changed the buffering to 700ms but can you explain what that does exactly? Almost all guides and tutorials I have read for Twitch say 400ms is the correct buffer. I use windows 8.1 and therefore no aero. I have moved a monitor capture source to a global monitor capture source. Should all my text and notifiers be global sources as well?

I will see if these changes affect anything on my long cast on Wednesday.
Click to expand...
oops got two log files mixed up. Yeah Windows 8.1 does use aero but it shouldn't be as bad as with windows 7. If you can avoide monitor capture, delete the global source and use game or window capture. I usually add text and images (especially gifs) to global sources. I dont typically add in things like monitor capture to global sources but test it and see, again, if you have to use monitor capture.
 
Here is the recent Log from my last cast of 10.5 hours. High Encoding started right on the mark at 9 hours again even after changes. The Analyzer shows a new hook program from the new game I just installed, I have now disabled that hook. Even after the program that had the new hook was closed and regular game was played the conflict still showed up on the log. It seems the High Encoding is still related to a slow source. Would window capture cause a slow source or is it still monitor capture that is the culprit? Both of those were moved to global sources prior to starting this cast. I will now move every source to a global source in an attempt to find a solution. Do you have any other suggestions?

Recent Log
https://gist.github.com/966968d2955582106309
 
8ull said:
Here is the recent Log from my last cast of 10.5 hours. High Encoding started right on the mark at 9 hours again even after changes. The Analyzer shows a new hook program from the new game I just installed, I have now disabled that hook. Even after the program that had the new hook was closed and regular game was played the conflict still showed up on the log. It seems the High Encoding is still related to a slow source. Would window capture cause a slow source or is it still monitor capture that is the culprit? Both of those were moved to global sources prior to starting this cast. I will now move every source to a global source in an attempt to find a solution. Do you have any other suggestions?

Recent Log
https://gist.github.com/966968d2955582106309
Click to expand...
Monitor capture would be my guess. I would remove it from the scene and global sources and use another source instead. typically, you'll have a scene with a game/window capture with overlays and a scene to itself with a monitor capture.

I see in one of your scenes, you are using 7 monitor capture sources? why? are you using regions? can you replace those with window captures? Other scenes should not share a scene with monitor capture, even if its unchecked.

Other than that, I see after your 9hr and 15 minute cast you had 3% duplicate frames. could it be that after all that time, your CPU is throttling?
 
Last edited:
Here is the latest log file from a yesterdays long cast. I have removed a lot of sources and there is no scene with 7 monitor captures. Practically all sources are now global, less some text sources and each game capture. All window capture and monitor captures are global now. I cannot window capture the one monitor capture since it is my visualizer, its a desktop widget from rainmeter which does not create a window I can capture. I still get the slow sources detected which my guess is the main problem. Also for some reason that other hook showed up as active even though I did not run the program yesterday. Going to fix that hook now by removing it. I have gone through the BIOS and verified all power save features and throttling is turned off.

6/24-6/25
https://gist.github.com/21c4250dcedbd9e9d303
 
8ull said:
Here is the latest log file from a yesterdays long cast. I have removed a lot of sources and there is no scene with 7 monitor captures. Practically all sources are now global, less some text sources and each game capture. All window capture and monitor captures are global now. I cannot window capture the one monitor capture since it is my visualizer, its a desktop widget from rainmeter which does not create a window I can capture. I still get the slow sources detected which my guess is the main problem. Also for some reason that other hook showed up as active even though I did not run the program yesterday. Going to fix that hook now by removing it. I have gone through the BIOS and verified all power save features and throttling is turned off.

6/24-6/25
https://gist.github.com/21c4250dcedbd9e9d303
Click to expand...
your duplicate frames are much better but seems that when you change to a scene with your webcam, you get the "PERFORMANCE WARNING" message. double check that as a global source.

Question; is there an alternative to using monitor capture in any/all of your scenes? also, I did see one scene with, pretty much one scene of each type, monitor capture doesn't mix well with other capture methods.

Example of one of your scenes:
Code: 
16:45:55: Using directshow input (webcam)
16:45:55: Using text output
16:45:55: Using Monitor Capture
16:45:55: Using graphics capture (game capture)
16:45:55: Using Window Capture
 
Ok after some digging it seems the slow source is the webcam and not the window capture. Therefore I have changed some settings, turned off (right light) and forced custom resolution to 720p (1280x720) in OBS with 30 FPS. Since the C920 is USB2.0 I moved the webcam from a USB 3.0 plug to a 2.0 USB plug on a USB controller where it is the only device on the chain. I will be testing these setting this week and report back, hope it works and thanks for your help.
 
Sorry I'm a bit late to the thread, but I've been having a similar problem on and off since I upgraded to a C920, but hadn't made the link until very recently.
I have used a C920 for a couple of months now, and have started to have some serious sound drop/stutter issues since adding an external soundcard to my setup.

Assuming it was the new stuff I'd added, I forked out for replacement parts and spent lots of time messing about with drivers. However, I've now realised it's the C920 causing very high DPC latency times.
I worked this out using the guides on http://www.sysnative.com/forums/win...c-latency-issues-wpa-windows-vista-7-8-a.html where there's an explanation of what high DPC latency can cause, and how to spot it. I found the DPC Latency Checker very useful in troubleshooting my setup.

High DPC latency times can have knock on effects to general responsiveness of your system, and therefore would probably be affecting your encoding times too.
I would wager the C920 is possibly one of your culprits.

Some people recommend dropping the webcam resolution to help out, but I was pretty reluctant to drop my 1080p capable webcam back down to 720p or lower, as I'd only recently upgraded from a 720p webcam. Even when dropping to 720p, it still ended up with Medium/High DPC latency, and therefore still have the occasional sound drop/stutter.
However, I found that keeping it at 1080p and forcing the C920 to use "MJPG" Output format in the webcam settings of OBS drops the DPC latency back down to barely causing a blip on the DPC monitor.
I'm aware this is a way more compressed format, but it doesn't seem to lose as much quality as it would when compared to lowering the overall resolution, and uses a fraction of the encoding time.

Hope this helps. :)
 
M0nk3yUK said:
Sorry I'm a bit late to the thread, but I've been having a similar problem on and off since I upgraded to a C920, but hadn't made the link until very recently.
I have used a C920 for a couple of months now, and have started to have some serious sound drop/stutter issues since adding an external soundcard to my setup.

Assuming it was the new stuff I'd added, I forked out for replacement parts and spent lots of time messing about with drivers. However, I've now realised it's the C920 causing very high DPC latency times.
I worked this out using the guides on http://www.sysnative.com/forums/win...c-latency-issues-wpa-windows-vista-7-8-a.html where there's an explanation of what high DPC latency can cause, and how to spot it. I found the DPC Latency Checker very useful in troubleshooting my setup.

High DPC latency times can have knock on effects to general responsiveness of your system, and therefore would probably be affecting your encoding times too.
I would wager the C920 is possibly one of your culprits.

Some people recommend dropping the webcam resolution to help out, but I was pretty reluctant to drop my 1080p capable webcam back down to 720p or lower, as I'd only recently upgraded from a 720p webcam. Even when dropping to 720p, it still ended up with Medium/High DPC latency, and therefore still have the occasional sound drop/stutter.
However, I found that keeping it at 1080p and forcing the C920 to use "MJPG" Output format in the webcam settings of OBS drops the DPC latency back down to barely causing a blip on the DPC monitor.
I'm aware this is a way more compressed format, but it doesn't seem to lose as much quality as it would when compared to lowering the overall resolution, and uses a fraction of the encoding time.

Hope this helps. :)
Click to expand...

Thanks for this I will try this for my next longer stream. As for my previous setting changes they did not resolve the issue as I still get "slow sources detected" at 9 hours mark.

Here is the log from my recent test:
https://gist.github.com/ee223b10d84fddbd9341
 
So after these changes I can now go about 10-11 hours before high encoding. I did a 24 stream this weekend and had to restart each time I hit 11 hours, the first time at 11 hours OBS completely froze up video but audio was still broadcasting. Now one of my viewers suggested changing the audio encoding from AAC to MP3, is this a good idea? and how would this affect my stream audio quality?

Recent Log File:
https://gist.github.com/bb3f49faae71b91e14ad
 
Nothing has helped to solve this problem on OBS v0.652b. I have moved over to OBS-MP 0.11.1 and have not had any issues on very long streams (over 12 hours). This might have something to do with the way OBS v0.652b is hooking captures or the fact every source is global in OBS-MP 0.11.1. Either way I have given up on OBS v0.652b for my long streams.
 
8ull said:
Nothing has helped to solve this problem on OBS v0.652b. I have moved over to OBS-MP 0.11.1 and have not had any issues on very long streams (over 12 hours). This might have something to do with the way OBS v0.652b is hooking captures or the fact every source is global in OBS-MP 0.11.1. Either way I have given up on OBS v0.652b for my long streams.
Click to expand...
Glad OBS MP is working for you. MP is the new standard once more of the plugins get implemented. As for your issue, I did notice that you are running the 64bit version in OBS1, if you get a chance, could you test with the 32bit (x86) of OBS? I know its asking a lot, but I maybe has. and no AAC should be pretty standard for use. I would make your monitor capture a global source or anything else that you will use in multiple scenes or switch between often.

Another thing to check is your audio format of your line in and speakers in windows, check the audio format under the advanced tab in playback devices and recording devices. What is the audio format? whatever it is, make sure OBS is set to what you are using. ex. Audio Format: 44100 Hz or 48000Hz
 
You must log in or register to reply here.
Back
Top