Question / Help PLEASE HELP MONITOR CAPTURE TROUBLES
- Thread starter Dyllon
- Start date
FerretBomb
Active Member
Check the BIOS/UEFI. Many motherboards come in 'automatic' mode, which may split channels. You may have to go in and set the PCIe mode to x16/x1, if it defaulted to x8/x8 (splitting).
Also, as the Xbone app is a Metro app, the only way to capture it at present is with a Monitor Capture. This kind of thing is also why recording the app is a workaround, and NOT a replacement for a capture card.
As an aside, disabling Aero was a workaround for Windows 7 monitor capture ONLY due to MS not allowing access to certain parts of the architecture. It was fixed in Win8 and up. Also, a workaround was found for Win7. There are only a very few reasons to disable Aero under 7 any more, and they're very uncommon scenarios.
Xsplit's screen grab is just a monitor capture with a built-in crop.
I'd be MUCH more concerned that you're trying to stream/record at 1080p@30 on 2500kbps, on an AMD FX6300 on the Veryfast preset. That ain't gonna work.
If you're trying to record locally only, follow the HQ Local Recordings guide:
https://obsproject.com/forum/resources/how-to-make-high-quality-local-recordings.16/
If that's the case, it's entirely unsurprising that you're getting framerate issues as you're DRASTICALLY overworking your CPU. It just can't handle the settings you're trying to use. My guess is that your framerate is going to crap because the FX6300 can't handle real-time 1080@30 video encoding on that preset alone, much less also decoding the video coming from the Xbone then reencoding it into the video file.
Follow the HQ Recording guide, all the steps. It should reduce your CPU usage significantly, and if overloading is the issue (along with the PCIe bandwidth correction in the UEFI/BIOS) it should record smoothly. Won't help with streaming though, but it will show the next step to take in troubleshooting.
Also, as the Xbone app is a Metro app, the only way to capture it at present is with a Monitor Capture. This kind of thing is also why recording the app is a workaround, and NOT a replacement for a capture card.
As an aside, disabling Aero was a workaround for Windows 7 monitor capture ONLY due to MS not allowing access to certain parts of the architecture. It was fixed in Win8 and up. Also, a workaround was found for Win7. There are only a very few reasons to disable Aero under 7 any more, and they're very uncommon scenarios.
Xsplit's screen grab is just a monitor capture with a built-in crop.
I'd be MUCH more concerned that you're trying to stream/record at 1080p@30 on 2500kbps, on an AMD FX6300 on the Veryfast preset. That ain't gonna work.
If you're trying to record locally only, follow the HQ Local Recordings guide:
https://obsproject.com/forum/resources/how-to-make-high-quality-local-recordings.16/
If that's the case, it's entirely unsurprising that you're getting framerate issues as you're DRASTICALLY overworking your CPU. It just can't handle the settings you're trying to use. My guess is that your framerate is going to crap because the FX6300 can't handle real-time 1080@30 video encoding on that preset alone, much less also decoding the video coming from the Xbone then reencoding it into the video file.
Follow the HQ Recording guide, all the steps. It should reduce your CPU usage significantly, and if overloading is the issue (along with the PCIe bandwidth correction in the UEFI/BIOS) it should record smoothly. Won't help with streaming though, but it will show the next step to take in troubleshooting.
FerretBomb
Active Member
The logfile you posted was from a RECORDING session, leading to the assumption despite seeing the mentions of livestreaming. If you stream on those settings, especially to Twitch, you're going to have MAJOR problems.
Nope, IRQs are different (Interrupt Request flags) and aren't related to bus speed. Leave that alone.
So.
DOWNSCALE to 720p or lower... a six-core AMD CPU probably will need to go down to 480p, or even 360p. AMD are bad at real-time video encoding to begin with.
With the assumption you're streaming to Twitch, I'd also recommend dropping to 2000kbps bitrate to reduce the likelihood of viewer buffering, and 2500 isn't needed at 480 and lower anyway. You also need to set your Keyframe Interval under Advanced to 2, if streaming to Twitch.
I'd also recommend running your webcam at 720p mode or lower. The c920 is known for causing overhead load issues at 1080p, and you don't have the overhead to spare with that CPU. It'd also be a very good idea to set it up as a Global Source, which will make OBS run better on transitions and give you a nice quickfade transition instead of the hard jump-cut you get now (due to OBS having to wait for the cam to shut down, then start up again when it loads in for the next scene).
Nope, IRQs are different (Interrupt Request flags) and aren't related to bus speed. Leave that alone.
So.
DOWNSCALE to 720p or lower... a six-core AMD CPU probably will need to go down to 480p, or even 360p. AMD are bad at real-time video encoding to begin with.
With the assumption you're streaming to Twitch, I'd also recommend dropping to 2000kbps bitrate to reduce the likelihood of viewer buffering, and 2500 isn't needed at 480 and lower anyway. You also need to set your Keyframe Interval under Advanced to 2, if streaming to Twitch.
I'd also recommend running your webcam at 720p mode or lower. The c920 is known for causing overhead load issues at 1080p, and you don't have the overhead to spare with that CPU. It'd also be a very good idea to set it up as a Global Source, which will make OBS run better on transitions and give you a nice quickfade transition instead of the hard jump-cut you get now (due to OBS having to wait for the cam to shut down, then start up again when it loads in for the next scene).