Closed Yamakuzure closed 2 years ago
Fenrirthviti
commented
2 years ago Are you able to provide a sample log of the same kind of output from 27.1.3, and from 27.2?
Since you are using custom video color formats and ranges, you are falling back on the ffmpeg implementation of NVENC and not our native. Can you run a test using the default options with our native NVENC to see if the issue still persists as well? This might be an ffmpeg problem, which was updated a few versions in 27.2
Fenrirthviti
commented
2 years ago As for the audio issues, we're aware of an increase in those error messages, but aren't 100% sure what is causing them as (same as you reported) they are still working properly. I don't think they are related to the encoding lag, that indicates that the GPU itself can't keep up with the encoding, so it's something with the encoder itself causing issues.
4aiman
commented
2 years ago I have similar issues, all tied to VSync in Windows 11.
Usually I get screen tearing on preview windows and smooth 60 fps with no drops in recordings/streams. However, when I force enable VSYNC in NVidia control panel OBS's "time to render a frame" skyrockets to 16.6 and it drops frames due to rendering lag. 15-20% if x264 is used, 25%-50% if NVENC is used.
Hope my info is relevant and helps
Yamakuzure
commented
2 years ago Are you able to provide a sample log of the same kind of output from 27.1.3, and from 27.2?
The sample logs above are from 27.1.3 and from 27.2.2
Since you are using custom video color formats and ranges, you are falling back on the ffmpeg implementation of NVENC and not our native. Can you run a test using the default options with our native NVENC to see if the issue still persists as well? This might be an ffmpeg problem, which was updated a few versions in 27.2
I can do a test tonight, yes. Maybe it'll provide some clues.
I have similar issues, all tied to VSync in Windows 11.
Usually I get screen tearing on preview windows and smooth 60 fps with no drops in recordings/streams. However, when I force enable VSYNC in NVidia control panel OBS's "time to render a frame" skyrockets to 16.6 and it drops frames due to rendering lag. 15-20% if x264 is used, 25%-50% if NVENC is used.
Hope my info is relevant and helps
I have VSYNC disabled everywhere, as I have an AdaptiveSync Monitor that emulates G-Sync well enough for the nvidia drivers to be happy with them. No tearing with up to 145 FPS, and I record using 120 FPS.
But before I had that monitor, I was VSYNCing on 60FPS and never had those kind of troubles with OBS...
Fenrirthviti
commented
2 years ago Sorry if I wasn't clear on the ask there, I would need a full log file (not just sections of it) from 27.1.3, and from 27.2.2 (or 27.2.3 as that's the current now, with a minor virtualcam fix that won't have any impact here).
I also notice that you have three displays, all with different refresh rates, and one appears to be connected to the motherboard and not the dedicated GPU. Windows in general doesn't like mismatched display framerates, and doing cross-GPU displays can cause even more issues. Could be another useful test to try connecting all displays to the primary GPU (or if there is no connection available, disconnecting the GPU currently connected to the motherboard).
Yamakuzure
commented
2 years ago One thing first:
I deactivated HAGS as advised at https://obsproject.com/wiki/How-to-disable-Windows-10-Hardware-GPU-Scheduler to make sure that this was not the culprit. But it seems that that advice, at least for nvidia Quadro powered laptops, is a very bad advice, because it resulted in:
06:32:42.081: Output 'adv_file_output': stopping
06:32:42.081: Output 'adv_file_output': Total frames output: 2652
06:32:42.081: Output 'adv_file_output': Total drawn frames: 1153 (2668 attempted)
06:32:42.081: Output 'adv_file_output': Number of lagged frames due to rendering lag/stalls: 1515 (56.8%)The output on the stats window also showed droped FPS between 45 and 60 (set up was 120, and my T2000 renders ME3 in 145 FPS)
I reactivated HAGS (Variable refresh rate turned OFF) and everything went back to normal. It seems that, at least with nvidia Quadro in a Laptop, deactivating HAGS is a very bad idea.
Another thing second:
I had the same encoding lag issue yesterday on Gentoo Linux with OBS-27.2.3, although not as severe. The dropped frames were between 25% and 40%. I assume that on Linux the system-ffmpeg is used? That would be ffmpeg-4.4.1 in my case.
Sorry if I wasn't clear on the ask there, I would need a full log file (not just sections of it) from 27.1.3, and from 27.2.2 (or 27.2.3 as that's the current now, with a minor virtualcam fix that won't have any impact here).
Here you are: OBS-27.1.3 with default settings: https://obsproject.com/logs/1BT-qakyP8Km8Kg- OBS-27.1.3 with optimized settings: https://obsproject.com/logs/0csgkrIkLs1PHxpF OBS-27.2.3 with default settings: https://obsproject.com/logs/O9yA7Kvxf2y_yk5u OBS-27.2.3 with optimized settings: https://obsproject.com/logs/IIjXyIUSQe5DiRvJ
The first three are fine. The last shows:
Video stopped, number of skipped frames due to encoding lag: 3696/3879 (95.3%)
I also notice that you have three displays, all with different refresh rates, and one appears to be connected to the motherboard and not the dedicated GPU. Windows in general doesn't like mismatched display framerates, and doing cross-GPU displays can cause even more issues.
This is a Laptop with with two external monitors. My Game runs on an Acer Predator, connected via DP. OBS runs on an LG Flatron, connected via HDMI. Both are directly connected to the nvidia Quadro T2000 in that Laptop. The panel only show notes via notepad++.
I never had any issues with this setup. Neither Windows nor Linux had any problems ever with this setup either.
Could be another useful test to try connecting all displays to the primary GPU (or if there is no connection available, disconnecting the GPU currently connected to the motherboard).
Nope, that is not an option, sorry. There have not been any problems with this setup and OBS until I used optimized output settings with OBS-27.2.x.
Yamakuzure
commented
2 years ago Nope, that is not an option, sorry.
To make this clear: I simply can not connect all three displays to the Intel HD or nvidia Quadro. All I could do would be to deactivate the Quadro, and then test with 10-15 FPS the Intel HD manages to render. ;-)
boussyboo
commented
2 years ago hi,
we had an issue with the video being pixellated and unusable.
so after much frustration i've finally corrected the issue of totally unusable video when recording, with the latest OBS patch - 27.2.3. it was, indeed, an OBS issue, and not a droidcam issue (as was suggested as a possibility over on the obs forum).
through a bunch of desperate messing about (because I really wanted to keep OBS up to date) we've got OBS working again, and our solution is below. we can record at 60fps if so choose, as well as 30 (which is how we normally record: 30 fps, 1920 x 1080).
The solution we've used (or perhaps it is more of a work around) is as follows:
and all good here
Andy B
Yamakuzure
commented
2 years ago Hmm... I do not think it has anything to do with the encoding lag issue. I neither have "rescale output" nor "look ahead" activated, and max b-frames are set to 2 anyway, because I upload to Youtube and they insist on max b-frames to be 2.
boussyboo
commented
2 years ago Hmm... I do not think it has anything to do with the encoding lag issue. I neither have "rescale output" nor "look ahead" activated, and max b-frames are set to 2 anyway, because I upload to Youtube and they insist on max b-frames to be 2.
Ok. Just thought I'd share my solution. Maybe it will help somebody else?
Cheers
Andy B
energizerfellow
commented
2 years ago Hmm... I do not think it has anything to do with the encoding lag issue. I neither have "rescale output" nor "look ahead" activated
06:53:37.144: Starting recording due to hotkey 06:53:37.146: [jim-nvenc] nv12 not active, falling back to ffmpeg06:52:32.044: video settings reset: 06:52:32.044: base resolution: 2560x1440 06:52:32.044: output resolution: 2560x1440 06:52:32.044: downscale filter: Lanczos 06:52:32.044: fps: 120/1 06:52:32.044: format: I444 06:52:32.044: YUV mode: 709/FullDoing 1440p120 @ yuv444p a very big performance killer, along with full-range breaking the color handling in basically all video tools and video services. The 4:4:4 also forces the video data to do a round-trip through the system RAM instead of on-GPU, which is going to be really painful on a laptop, which likely only has a single DIMM channel soldered to the motherboard.
The 500-series Nvidia GPU drivers also have some quirks affecting OBS. Rolling back to the last pre-500 driver, e.g. R470 U8 (472.98), would be a good idea. This is what you're looking for: https://www.nvidia.com/download/driverResults.aspx/185533/en-us
Yamakuzure
commented
2 years ago Edit : I wrote the original comment while sitting on public transport. Now I am in the office and will amend the information to be more on point.
06:52:32.044: video settings reset: 06:52:32.044: base resolution: 2560x1440 06:52:32.044: output resolution: 2560x1440 06:52:32.044: downscale filter: Lanczos 06:52:32.044: fps: 120/1 06:52:32.044: format: I444 06:52:32.044: YUV mode: 709/FullDoing 1440p120 @ yuv444p a very big performance killer, along with full-range breaking the color handling in basically all video tools and video services. The 4:4:4 also forces the video data to do a round-trip through the system RAM instead of on-GPU, which is going to be really painful on a laptop, which likely only has a single DIMM channel soldered to the motherboard.
How does not reducing the color range and not re-scaling the color format impact performance? To be honest, I do not see any difference between the default and my settings in OBS CPU consumption. So the term "big performance killer" might be a bit exaggerating, at least on my hardware.
But to provide some further information. My Laptop is a Dell Precision 7550 with custom upgrades. CPU: Intel(R) Core(TM) i7-10875H RAM: 2x 32GB Dual Channel 3GHz (Plus 2 empty slots. Nothing soldered or single channel) GFX: Quadro T2000, 4GB RAM Storage: 2x 1TB Class 50 NVME
The Hardware is not a problem.
The 500-series Nvidia GPU drivers also have some quirks affecting OBS. Rolling back to the last pre-500 driver, e.g. R470 U8 (472.98), would be a good idea. This is what you're looking for: https://www.nvidia.com/download/driverResults.aspx/185533/en-us
I have absolutely no problems with OBS 27.1 3 with these exact settings on this laptop. Neither with pre- nor post-500-series Nvidia GPU drivers.
Further, with OBS 27.1.3, I can record without any issues and with even higher settings. Questioning my settings and/or hardware does not help, I am afraid...
This is an issue introduced in OBS 27.2, prior to that version I have recorded over 3,000 clips without any problems and with these settings on this exact hardware.
Just yesterday I recorded some clips from "Mass Effect 2 Legendary Edition" and "Mass Effect 3" (OT), and the final stats showed 0,0% encoding lag. From about 30,000 Frames recorded, about 50 were lost by rendering lag. Just a reminder: With OBS 27.2.x I have 95%+ (!!) loss through encoding lag.
Yamakuzure
commented
2 years ago The 500-series Nvidia GPU drivers also have some quirks affecting OBS. Rolling back to the last pre-500 driver, e.g. R470 U8 (472.98), would be a good idea. This is what you're looking for: https://www.nvidia.com/download/driverResults.aspx/185533/en-us
To make sure the driver is not an issue, I downgraded to NVIDIA RTX / Quadro Desktop and Notebook Driver Release 470 (Version 472.98) today, and updated OBS Studio to V27.2.4
Unfortunately I had an encoding lag of ~80% with this constellation.
A Downgrade to OBS Studio 27.1.3 reduced the encoding lag to 0% again.
So the driver version is also not the problem here, I am afraid. :-(
Edith wanted to say: I also had the idea to do a git bisect between 27.1.3 and 27.2.2, but the build system on windows has changed so dramatically (literally 100%) between 27.1 and 27.2, that this would be too much for someone who isn't familiar with either build system. At least on windows.
But : As I noted above, I have seen the same rendering lag, just not that extreme, on Linux, too. As I am using Gentoo, I hope I can use the ebuilds for 27.1.3 and 27.2.2 as build guides, so I can bisect this...
Edith has another one:
(...)removed(...) It seems like OBS does not heed any encoder settings from the "Video Encoder Settings" field. It said it was recording with 120Mbps, but the result looked more like the default 2500Kbps. Makes "Custom Output (FFmpeg)" rather useless until I understand how I can get parameters to it that are then heeded.
lucasmarotta
commented
2 years ago I also having fps drops/lag, to be precise encoder lag. After days trying I figure it out my cause. The new nvenc encoder option when recording and streaming a application/game (game capture fullscreen) with higher fps target then the game I have the issue. Does not matter the quality.
This is a problem, if by any reason the fps go from 60 to 30 due to a cutscene for example, I have huge encoder lag. This does not happen on shadowplay, streamlabs using old nvenc and going back to the latest v26 also does not happens. All 27.x.x versions happens.
I am using windows 11, Nvidia Studio driver 512. 59 and tried settings like hags on/off, game mode on/off and many others. The game bar is disabled. Not running rtss or any osd also does not work. And like said I can put the recording on the lowest quality but if the application have less fps the the obs target I got huge lag.
This isn't a fps stutter in the game, for example using The Witcher 3, every time the load screen shows the fps goes to 28 but there's no sutter in screen, but recording becomes very choppy,. You can record 60 fps and lock the at 30 that the issue appears on v27, but not on v26. My gpu could be 40% usage that this happens, so is something else, since v26 record just fine.
Since v26 can't stream to twitch, I guess I have to record with v26 and stream with latest but limiting the obs 1 frame lower than the game. Hope it help with my experience. I can put some logs later.
PC Specs RTX 2080s Ryzen 5900x 64gb Ram
RytoEX
commented
2 years ago We've looked into this, and I wrote (and rewrote) an initial reply, and then wrote a new reply, and then discovered new information, so I've had to rewrite again. I apologize if the reply is a little disjointed as a result.
tl;dr: This is due to the FFmpeg upgrade that we did and how FFmpeg maps the old NVENC presets to new NVENC presets. With the settings you're using, NVIDIA recommends P5, while FFmpeg uses P7 (which is more intensive). The old preset that FFmpeg would map to P5 is BD, which we don't list in the UI.
If you want to keep using I444, you are able to edit the "recordEncoder.json" file in the folder for this OBS profile (%AppData%\obs-studio\basic\profiles\<ProfileName>\recordEncoder.json) to manually change the "preset" value to either "bd" or "p5" and achieve similar results as you did in OBS 27.1.3. You will lose 2-pass, but that's unavoidable at the moment.
If you use NV12, the issue will go away, as a different encoder implementation is used.
This is, essentially, a duplicate of #4631.
For those interested in details, here they are.
Examining the Profiler Results from the full logs for the "optimized" settings... OBS 27.1.3:
06:46:35.760: video_thread(video): min=0.001 ms, median=3.063 ms, max=24.264 ms, 99th percentile=5.764 ms
06:46:35.760: ┗receive_video: min=0 ms, median=3.061 ms, max=24.263 ms, 99th percentile=5.762 ms
06:46:35.760: ┗do_encode: min=2.404 ms, median=3.061 ms, max=24.262 ms, 99th percentile=5.761 ms
06:46:35.760: ┣encode(recording_h264): min=2.384 ms, median=2.999 ms, max=18.305 ms, 99th percentile=4.28 ms
06:46:35.760: ┗send_packet: min=0.005 ms, median=0.05 ms, max=20.355 ms, 99th percentile=1.285 msOBS 27.2.3:
06:54:20.582: video_thread(video): min=0.001 ms, median=34.882 ms, max=2091.9 ms, 99th percentile=1783.09 ms
06:54:20.582: ┗receive_video: min=0 ms, median=9.712 ms, max=61.374 ms, 99th percentile=13.676 ms, 20.633 calls per parent call
06:54:20.582: ┗do_encode: min=2.499 ms, median=9.712 ms, max=61.373 ms, 99th percentile=13.676 ms
06:54:20.582: ┣encode(recording_h264): min=2.499 ms, median=9.691 ms, max=61.358 ms, 99th percentile=13.661 ms
06:54:20.582: ┗send_packet: min=0.005 ms, median=0.013 ms, max=1.581 ms, 99th percentile=0.108 msYou can see that the median and 99th percentile values are nowhere near the same here, despite the same settings. So there is something different between 27.1.x and 27.2.x for FFmpeg NVENC.
I've done some testing on my system. On my system (i7-7700HQ with GTX 1060 6GB), with Game Mode On, HAGS off, and recording with the same OBS settings as you (except in 1080p120 instead of 1440p120), these are my results. OBS 27.1.3:
16:13:31.645: video_thread(video): min=1.978 ms, median=2.451 ms, max=9.92 ms, 99th percentile=4.055 ms
16:13:31.645: ┗receive_video: min=1.666 ms, median=2.447 ms, max=9.917 ms, 99th percentile=4.048 ms
16:13:31.645: ┗do_encode: min=1.666 ms, median=2.447 ms, max=9.915 ms, 99th percentile=4.046 ms
16:13:31.645: ┣encode(recording_h264): min=1.656 ms, median=2.355 ms, max=5.105 ms, 99th percentile=3.702 ms
16:13:31.645: ┗send_packet: min=0.006 ms, median=0.039 ms, max=7.684 ms, 99th percentile=0.404 msOBS 27.2.4:
16:18:37.063: video_thread(video): min=1.969 ms, median=2.838 ms, max=14.146 ms, 99th percentile=4.624 ms
16:18:37.063: ┗receive_video: min=1.966 ms, median=2.836 ms, max=11.309 ms, 99th percentile=4.619 ms
16:18:37.063: ┗do_encode: min=1.966 ms, median=2.835 ms, max=11.308 ms, 99th percentile=4.619 ms
16:18:37.063: ┣encode(recording_h264): min=1.965 ms, median=2.745 ms, max=4.799 ms, 99th percentile=4.26 ms
16:18:37.063: ┗send_packet: min=0.006 ms, median=0.071 ms, max=8.463 ms, 99th percentile=0.709 msThere's only a slight difference here.
Testing the same settings, but at 1440p... OBS 27.1.3:
16:50:07.038: video_thread(video): min=0.002 ms, median=4.119 ms, max=13.576 ms, 99th percentile=7.853 ms
16:50:07.038: ┗receive_video: min=0 ms, median=4.111 ms, max=13.573 ms, 99th percentile=7.843 ms
16:50:07.038: ┗do_encode: min=3.032 ms, median=4.108 ms, max=13.571 ms, 99th percentile=7.843 ms
16:50:07.038: ┣encode(recording_h264): min=3.021 ms, median=4.018 ms, max=9.697 ms, 99th percentile=6.99 ms
16:50:07.038: ┗send_packet: min=0.007 ms, median=0.086 ms, max=9.456 ms, 99th percentile=1.332 msOBS 27.2.4:
16:52:27.501: video_thread(video): min=0.004 ms, median=47.234 ms, max=812.275 ms, 99th percentile=716.095 ms
16:52:27.501: ┗receive_video: min=3.534 ms, median=9.259 ms, max=16.471 ms, 99th percentile=12.948 ms, 13.5644 calls per parent call
16:52:27.501: ┗do_encode: min=3.533 ms, median=9.256 ms, max=16.471 ms, 99th percentile=12.948 ms
16:52:27.501: ┣encode(recording_h264): min=3.533 ms, median=9.221 ms, max=16.217 ms, 99th percentile=12.882 ms
16:52:27.501: ┗send_packet: min=0.006 ms, median=0.016 ms, max=4.501 ms, 99th percentile=0.27 msHowever, if I build OBS 27.2.4 with the dependencies used with OBS 27.1.3:
16:58:14.060: video_thread(video): min=3.262 ms, median=4.366 ms, max=17.886 ms, 99th percentile=7.922 ms
16:58:14.060: ┗receive_video: min=3.261 ms, median=4.361 ms, max=17.884 ms, 99th percentile=7.862 ms
16:58:14.060: ┗do_encode: min=3.261 ms, median=4.36 ms, max=17.883 ms, 99th percentile=7.86 ms
16:58:14.060: ┣encode(recording_h264): min=3.211 ms, median=4.264 ms, max=17.829 ms, 99th percentile=6.575 ms
16:58:14.060: ┗send_packet: min=0.001 ms, median=0.061 ms, max=11.302 ms, 99th percentile=2.267 msYou can see here that the values are more or less the same as 27.1.3. This indicates that the problem is most likely related to the change in our dependencies between 27.1.3 and 27.2.4.
After further internal discussion, we determined that the cause is the new NVENC presets in FFmpeg and the mappings between the old and new presets provided by FFmpeg. For more details, see these links:
I also had the idea to do a git bisect between 27.1.3 and 27.2.2, but the build system on windows has changed so dramatically (literally 100%) between 27.1 and 27.2, that this would be too much for someone who isn't familiar with either build system. At least on windows.
The build system changed after 27.2 was branched off. The 27.1.x and the 27.2.x build systems/processes are the same. Bisecting between them should not require anything out of the ordinary. The old build instructions still live in the wiki history here. That said, in this case it will not reveal anything because this is not related to a code change we made but a dependency change.
Yamakuzure
commented
2 years ago tl;dr: This is due to the FFmpeg upgrade that we did and how FFmpeg maps the old NVENC presets to new NVENC presets. With the settings you're using, NVIDIA recommends P5, while FFmpeg uses P7 (which is more intensive). The old preset that FFmpeg would map to P5 is BD, which we don't list in the UI. If you want to keep using I444, you are able to edit the "recordEncoder.json" file in the folder for this OBS profile (
%AppData%\obs-studio\basic\profiles\<ProfileName>\recordEncoder.json) to manually change the "preset" value to either "bd" or "p5" and achieve similar results as you did in OBS 27.1.3. You will lose 2-pass, but that's unavoidable at the moment.
That's incredible! I had no idea I could manually edit the preset settings.
Thank you very much, I will try that tomorrow.
And thanks a lot for all the research you did!
Yamakuzure
commented
2 years ago I just looked into my recordEncoder.json and it consists of this: (formatting by me)
{
"bf": 0,
"bitrate": 96000,
"cqp": 12,
"lookahead": false,
"max_bitrate": 256000,
"preset": "mq",
"psycho_aq": false,
"rate_control": "CQP"
}Interestingly ffmpeg -help encoder=h264_nvenc does not know a preset called "mq". Neither does the Nvidia API documentation. So what does OBS Map "mq" to?
It seems to mean "max quality", as a setting of "High" in the UI sets preset to "hq". What does OBS set -tune to?
However, I switched to p5 as suggested. And the only thing I have left is an encoding lag when starting the recording. This seems to vary between 60 and 380 frames. After those 0.5 to 3 seconds "lag", the recording is smooth and no frames get added to the encoding lag counter.
I'll try with bf: 2 and lookahead: true next.
Yes, now the recording start is also fixed. I guess the lookahead keeps back just enough frames for its work that the encoder doesn't overload any more. Hopefully the ffmpeg upgrade also upgraded the pixel format from the (deprecated) yuvj444p to yuv444p. That would speed up the recoding later. (h264_nvenc doesn't support writing yuvj444p any more, so I guess it came from the old ffmepg version used?)
Thank you very much for your help!
And for anyone having similar issues, here is my final setting that works for me:
%AppData%\obs-studio\basic\profiles\<ProfileName>\recordEncoder.json
{
"bf": 2,
"bitrate": 96000,
"cqp": 12,
"lookahead": true,
"max_bitrate": 256000,
"preset": "p5",
"psycho_aq": false,
"rate_control": "CQP"
}( I do not close this issue, as the wrong preset/tune mapping is still a thing. )
RytoEX
commented
2 years ago "mq" is "Max Quality", which is just "High Quality with 2-pass" ("hq"). This is why if you select "Max Quality" in OBS, you'll see "hq" the in the log instead:
[NVENC encoder: 'recording_h264'] settings:
rate_control: CQP
bitrate: 0
cqp: 14
keyint: 250
preset: hq
profile: high
width: 1920
height: 1080
2-pass: true
b-frames: 2
psycho-aq: 0
GPU: 02-pass is not controlled via the ini file, only in code, and it's only set if the preset is "mq". This is why I said that you would lose 2-pass. See the code for how "mq" becomes "hq".
We don't set tune internally, as we don't currently handle the new presets directly.
I'm in favor of closing this as it's a duplicate of #4631, as I previously stated. I'd rather not have two separate issues tracking the same thing.
Fenrirthviti
commented
2 years ago Going to mark as a duplicate.
Please move all further discussion there. Keep in mind that now that we understand the cause, we do not need any further reports of performance issues. We can now focus on what the correct solution is. Thanks!
Fenrirthviti
commented
2 years ago Duplicate of #4631
(Update) As RytoEX reported below ( https://github.com/obsproject/obs-studio/issues/6062#issuecomment-1116224885 ), the cause is a change in the preset mapping of the updated ffmpeg component.
A hotfix is to manually alter the profile settings like described in and after the mentioned comment. A regular fix is to adapt the obs->ffmpeg preet/tune mapping.
Operating System Info
Windows 10
Other OS
No response
OBS Studio Version
Other
OBS Studio Version (Other)
27.2.2
OBS Studio Log URL
https://obsproject.com/logs/cwSzBHoCp7-xonLn
OBS Studio Crash Log URL
No response
Expected Behavior
Smooth recording like with OBS Studio 27.1.3, looking like this in the log:
Current Behavior
I have an extreme drop rate due to encoding lag. Nothing changed, only the OBS Studio Version was updated via OBS Updater. Now the log looks like this:
Steps to Reproduce
(Actually I am not sure this has anything to do with the card, and may more likely to be linked to the audio hardware not being initialized - despite it works and records fine)
Anything else we should know?
If you analyze the log, it will tell you that I use the wrong color format, wrong color range and wrong framerate. All of these are intended, as I process the videos further. And OBS hadn't had any problems with my settings for over a year and ~2000 recording sessions with Mass Effect 1, 2, 3 (OT) and Mass Effect 1, 2, 3 (LE)
Hotfix: Downgrade by Installing OBS Studio 27.1.3 - Everything works normal again, then.
Note: The devices that "Fail to start" are:
The source is deactivated and locked anyway.
and
Despite the message, audio works fine and is recorded correctly.