Question / Help Rendering lag with OBS Studio 23.1.0

Celebrian

New Member
Greetings,

I've been recording FFXIV since December, and Stardew Valley since March; Stardew Valley has always given me some trouble with encoding overload issues (or it may have been encoding lag, I'm not sure as I never properly checked...), but works perfectly fine in SLOBS (with the same settings I use in OBS) [this is just extra information, not really relevant to my problem with OBS Studio]. When I first started recording FFXIV I would get encoding lag, but after capping my FPS in the game that fixed the issue. Until the last few months...

My main problem is trying to record FFXIV. At the end of December I got a new PC (specs will be in the log from OBS), to improve my recording/video quality, etc. It was fine with recording until sometime in the last couple of months (around mid-April), I've been getting encoding overload warnings, which have baffled me since.

Only in the last few weeks has it become a major issue, as I "ran out of" already-recorded material, and am in need of recording again.

Things that I've tried: lowering the bitrate, lowering the game settings, lowering other settings in OBS. I tried going back to simple mode (not preferable because I like being able to record with 3 different channels, as it makes editing a lot easier), which works to some degree but there is still encoding lag. I opted to try this for testing to see if this would work, and I'd just figure out some sort of other method for recording my audio. Alas... I also tried uninstalling and installing OBS again. I turned off Game Mode, etc.

Given how it worked fine between January and mid- to late-March, I'm not really understanding why all of a sudden I am having difficulties.

As my GPU was updated to the newest driver I decided to roll back to a driver that was listed for my device on the GPU provider (Gigabyte in this case). This seems to have no effect either.

So, I am at a loss as to what is the issue. Any help is greatly appreciated!

Attached is, as mentioned before, the log - of today's testing. Unfortunately I don't have any logs farther back than May 31st...

Edit: I forgot to mention that my CPU/GPU/RAM utilization is not at 100% after switching to the "simple mode" [and having used the configuration wizard], but the encoding overload message still appears [due to the rendering lag].
 

Attachments

  • 2019-06-04 19-40-04.txt
    23.7 KB · Views: 10

Narcogen

Active Member
19:40:56.379: rate_control: CBR
19:40:56.379: bitrate: 42000
19:41:14.955: Video stopped, number of skipped frames due to encoding lag: 650/1094 (59.4%)


You should probably be using CRF/CQP rate control for NVENC while recording. I am not sure if that is contributing to encoder lag but telling the encoder it needs to keep a constant bitrate when the content doesn't demand it isn't necessary.

19:44:51.400: YUV mode: 709/Full

Are you using 709/Full for a specific reason?

Also, you actually have very little rendering lag, and rendering lag and encoding lag are not related.
 

Celebrian

New Member
19:40:56.379: rate_control: CBR
19:40:56.379: bitrate: 42000
19:41:14.955: Video stopped, number of skipped frames due to encoding lag: 650/1094 (59.4%)


You should probably be using CRF/CQP rate control for NVENC while recording. I am not sure if that is contributing to encoder lag but telling the encoder it needs to keep a constant bitrate when the content doesn't demand it isn't necessary.

I had thought to change to either of those two, but my lack of understanding (and losing track of where my sources were that helped explain the difference went poof); I honestly didn't know a whole lot about them except through some YT videos, and from one or two guides on the forums here. It hadn't given me a problem before, however, until recently -- I can test to see if this does help though (once I re-learn the difference, etc. haha.... This is why I was also contemplating just to stick with the simple mode, and readjust the "advanced" portion to default settings as long as it worked, because of my lack of knowledge until such a time where I learned better).

19:44:51.400: YUV mode: 709/Full

Are you using 709/Full for a specific reason?

Also, you actually have very little rendering lag, and rendering lag and encoding lag are not related.

Honestly the only reason why I was because of a YT video, which may or may not have inaccurately described that by doing so you'd get a much larger range of colors and would produce better quality; I honestly don't think I tested the difference between those settings before.

The video lengths were 5-10 minutes for the testing in the log (sometimes shorter); I generally have much longer videos (anywhere from 30-120 minutes). I didn't want to test longer videos, because if they weren't going to work on a short-scale it didn't make sense to waste my time for a longer one. Prior to March I had no rendering lag at all (which is why I'm confused as to why I am now).

I agree that the rendering lag for those shorter videos are not so bad, but when you go from none to quite a bit, and if you're in the middle of talking and trying to show something and you get rendering lag.... well, that's not a good thing in my opinion. In some of the longer videos there would be rendering lag every 30 seconds at some points (this was especially true for Stardew Valley of all things.... which is why it's surprising that using SLOBS works perfectly fine... for Stardew anyways). At those points I would usually stop recording wait for OBS to do it's thing (it would take a few minutes to stop sometimes, because it's trying to, I'm assuming, encode things... I then would try starting up the recording again, but sometimes would immediately get "encoding overload" (which is likely the encoding lag).

If it is recommended to record a longer video for testing purposes I am willing to do that; I just don't see the need for it as if there's rendering lag in a shorter video there certainly would be a great deal more rendering lag in a longer video?

Side note: The error message that pops up in OBS while recording references "encoding overload" but when looking in the log it says "rendering lag," this is the only reason why I mention "encoding overload."
 

Narcogen

Active Member
They are two different things. It's possible to have either or both. It's possible to see the "encoding overload" error pop up in the status bar, even if you actually have more rendering lag in the logfile.

Rendering lag is content-dependent. (So is encoder lag, but you get the idea.) It entirely depends upon what is on the screen, frame size, frame rate, amount of motion. All of that happens before the encoder gets anything. And if the renderer lags, the encoder probably won't-- even if it *would have* had everything been rendered. Because what happens when rendering lags, is that you get repeated frames. This displays to the user as a frozen screen while audio continues.

The encoder doesn't lag out because encoding a duplicate frame is practically no load. Even if you've specified CBR meaning your computer is sending the same amount of data (more or less) the encoder had to work less hard to compress that frame because it's identical to the one before it: no work.

SLOBS is generally less efficient than OBS at the same tasks, so I would make a guess that something between the two setups is not the same, but it just isn't immediately obvious to you while looking at those settings.

You definitely do not need to be on 709/Full. The vast majorities of displays are not able to display the larger color space, and even if your monitor could, lots of people watching on YouTube or other platforms cannot, and to them, the video in the Full color space will look faded and washed out.

There is a lot of bad advice on YouTube. There are a lot of good guides in the Forum section labeled "Resources" in the forum named "Guides", as well as on the wiki:

https://obsproject.com/wiki/

Here is the particular guide on color space settings:

https://obsproject.com/forum/resour...t-color-range-settings-guide-test-charts.442/
 
Top