- Thread starter Exeldro
- Start date
Are you recording the window capture source directly? 'Cause I don't see another way for this plugin to see a resize at all.
If so, then the obvious workaround is to record something that doesn't resize. Like a scene that you put that source on, instead of the source itself.
Yeah I'm trying to record a direct source but I could try using a nested scene instead. I want to be able to record and stream at the same time so I didn't want it to capture any overlays or things like that.
This seems to be working better!
sajgon338
New Member
so what's next steps? should I create bug or feat at github?
That's funny. I happened to have it working ok, with audio recording ok. No 'different audio' options. Then I tried to get it to work with microphone track added and couldn't figure that out, so switched everything back to default, with no 'different audio' options and now there is no audio at all.
Kinda stumped here. I've tried a bunch of different approaches including setting 'different audio' to all tracks, and leaving the source blank, along with every other source I have, but I still get nothing. Also tried to uninstall and reinstall.
Kinda stumped here. I've tried a bunch of different approaches including setting 'different audio' to all tracks, and leaving the source blank, along with every other source I have, but I still get nothing. Also tried to uninstall and reinstall.
Tallicia
Member
The latest OBS 32.2.1 deb package installed for Ubuntu 26.04 x86_64 from the official OBS github repo ( https://github.com/obsproject/obs-studio/releases/tag/32.2.1) is no longer loading source-record
BEPO Media
New Member
OBS Version: 32.2.1
Source Record: 0.4.8
Aitum Stream Suite: 1.2.1
GPU: RTX 2080 Ti (Studio Driver 610.88)
I'm trying to determine whether this is a Source Record issue, an interaction with Aitum Stream Suite, or an OBS rendering limitation.
My setup is:
Results are 100% reproducible:
Has anyone else experienced this interaction between Source Record and Aitum Stream Suite's Vertical Canvas? If needed, I can provide a complete OBS log and scene collection for testing.
Source Record: 0.4.8
Aitum Stream Suite: 1.2.1
GPU: RTX 2080 Ti (Studio Driver 610.88)
I'm trying to determine whether this is a Source Record issue, an interaction with Aitum Stream Suite, or an OBS rendering limitation.
Reproduction
My setup is:
- Twitch (NVENC)
- YouTube (NVENC)
- Kick (NVENC)
- TikTok Vertical (Aitum Stream Suite using x264)
- Source Record (Camera Scene - x264)
- Source Record (Game Scene - x264)
Results are 100% reproducible:
- ✅ Twitch + YouTube + Kick + BOTH Source Record filters = No issues
- ✅ Twitch + YouTube + Kick + TikTok (no Source Record) = No issues
- ❌ Twitch + YouTube + Kick + TikTok + BOTH Source Record filters = Rendering lag and encoder overload
- ⚠️ Twitch + YouTube + Kick + TikTok + Game Source Record only = Intermittent rendering/encoder lag
Additional Information
- Both Source Record filters are attached to scenes (not sources) because I need the recorded output to include nested scenes, chroma key, color correction, etc.
- CPU usage stays around 50%.
- GPU usage stays around 70%.
- VRAM usage is low (~2 GB of 11 GB).
- Network is stable with 0 dropped network frames.
- Changing my Elgato capture from 1080p120 to 1080p60 reduced render time significantly (from ~17–21 ms down to ~14–15 ms), but the issue still occurs.
- The OBS log reports nearly identical rendering lag percentages across all outputs, suggesting the render thread is falling behind rather than any individual encoder.
Has anyone else experienced this interaction between Source Record and Aitum Stream Suite's Vertical Canvas? If needed, I can provide a complete OBS log and scene collection for testing.
So the three hardware encodes always work regardless of anything, while you can only really support one software encode, even though all three software encodes are still less than 50% load. Correct?
If so, then I suspect you might be running into a single-core limit rather than an entire-chip limit. For example, if you hypothetically have four CPU cores, and one is maxed out with obvious performance issues while the other three are idling, you might see 25%. Of course, your situation is more complex than that, but it might boil down to something similar.
The solution to that is almost entirely with the architecture of the app itself, and not really anything you can do as a user, unfortunately. Unless you had multiple machines to ship some things off to, to essentially force them to run in parallel, which brings its own set of challenges but might also create something that is entirely solvable without rewriting OBS.
For example, if you had a second machine that can do at least one hardware encode, then you could use the NDI plugin (or equivalent) on both to ship the program output over there to encode twice (one hardware and one software) with hardly any interaction, while the main one does everything else including the remaining four encodes: three hardware and one software.
Or depending on the capabilities of your "encode farm", you might arrange things differently. Looks to me like if the "encode farm" can also do three in hardware, then you can do all six in hardware just by sending the program out to the farm. That'll free up some CPU to do other things...
Pretty sure it's not Source Record or Aitum.
Last edited:
BEPO Media
New Member
Thank you Aaron for taking the time to look at this. The single-core explanation definitely makes sense, and I'll check the logical processor view in Task Manager during my next test that theory. I overlooked that possibility.So the three hardware encodes always work regardless of anything, while you can only really support one software encode, even though all three software encodes are still less than 50% load. Correct?
If so, then I suspect you might be running into a single-core limit rather than an entire-chip limit. For example, if you hypothetically have four CPU cores, and one is maxed out with obvious performance issues while the other three are idling, you might see 25%. Of course, your situation is more complex than that, but it might boil down to something similar.
The solution to that is almost entirely with the architecture of the app itself, and not really anything you can do as a user, unfortunately. Unless you had multiple machines to ship some things off to, to essentially force them to run in parallel, which brings its own set of challenges but might also create something that is entirely solvable without rewriting OBS.
For example, if you had a second machine that can do at least one hardware encode, then you could use the NDI plugin (or equivalent) on both to ship the program output over there to encode twice (one hardware and one software) with hardly any interaction, while the main one does everything else including the remaining four encodes: three hardware and one software.
Or depending on the capabilities of your "encode farm", you might arrange things differently. Looks to me like if the "encode farm" can also do three in hardware, then you can do all six in hardware just by sending the program out to the farm. That'll free up some CPU to do other things...
Pretty sure it's not Source Record or Aitum.
The one thing that makes me hesitate is that I've been able to isolate the issue pretty consistently:
- Twitch + YouTube + Kick + both Source Record recordings = stable.
- Twitch + YouTube + Kick + TikTok (no Source Record) = stable.
- The problem only appears when TikTok Vertical and Source Record are both active.
I also reduced my Elgato capture from 1080p120 to 1080p60, and my average render time dropped from around 17–21 ms to about 14–15 ms, so there definitely seems to be a render-thread component as well.
I agree it could still be a single-thread limitation inside OBS, but I'm not convinced yet that the interaction between Source Record and the additional vertical canvas can be ruled out. My goal is just to narrow down where the bottleneck actually is.
My current hypothesis is that this is an interaction between Source Record and Aitum Stream Suite rather than an issue with either plugin individually. Both work reliably on their own, but the problem consistently appears only when they're used together in this specific workflow. It makes me wonder whether this particular use case hasn't been optimized or extensively tested across both plugins.
Tallicia
Member
One thing to consider if the outputs/destinations are all of the exact same output, is why do you have multiple encodings? If they are all the same output, you can share an encoding and send it to the different destinations using one "source".
If your CPU and GPU are not bottle necked, you may want to ID what is. Is some of this being recorded and your storage is the bottleneck? I had to record to 3 different NVME SSDs to spread the load for a 6 camera/source recording situation. Same can apply for networking, especially on windows mcroslp surveillance and constant antivirus network scanning and monitoring.
If your CPU and GPU are not bottle necked, you may want to ID what is. Is some of this being recorded and your storage is the bottleneck? I had to record to 3 different NVME SSDs to spread the load for a 6 camera/source recording situation. Same can apply for networking, especially on windows mcroslp surveillance and constant antivirus network scanning and monitoring.
BEPO Media
New Member
Tallicia
Member
@Exeldro I think I have encountered a bug/regression, The frame rate divisor is not being utilized. When selecting the /2 to get 60fps from the 120fps canvas, the recording is still at 120fps. I have shutdown and restarted to confirm the setting is "staying", but it appears to be ignored. - Sidenote, could the rate control VB w/TQ be missing this as a passthrough? This is on Ubuntu 26.04 with the latest 0.4.8 plugin
