Source Record

Source Record 0.4.8

Download
Overview Updates (27) Reviews (137) History Discussion
sajgon338 said:
Or maybe you have some advice on how to make it work with a fixed length? Maybe I should report a bug?
Click to expand...
I don't, beyond what I said previously, which sounds like it doesn't fit your workflow very well.

I'm leaning towards a bug. If my suspicion is right that it has a roughly 2-second buffer (possibly to give the encoder some temporal space to work with?) with some variance in its actual length, and it discards that buffer when it stops instead of finishing it, then that might explain both of our quirks. The solution in that case would be to finish encoding the buffer instead of discarding it.

Regardless of what the mechanism is though, the requirement stays the same: Whatever happens in the real world before I click the stop button (or whatever it is that ends the recording) should appear in the file, and whatever happens in the real world after I click the button should not appear in the file. The tolerance is human imperceptibility (likely a small handful of frames). Whatever it takes to meet that requirement, do that.

Depending on how the startup works, it might require a special case to not create a short glitch-recording then, while otherwise keeping the above. For example, if everything starts enabled, and then some get disabled later according to the saved settings.

sajgon338 said:
I understand now that I need to stop the filter, change the settings, and then enable it again. Otherwise, the new settings are ignored until the filter restarts. It makes sense, but it would be helpful to have some kind of warning and a button to restart it instantly.
Click to expand...
That would explain why I didn't see that problem. I'm set to always record, and use the enable to start and stop, and so I'm particular about not having it enabled unless I really do want to record. So it's naturally disabled when I'm changing stuff, and that works.

I completely agree on the usability though: a user action that does nothing with no explanation, is a problem.
 
Been having an issue where the plugin causes OBS to crash any time I minimize or resize the window/source its capturing. Is there any known fix for this?
 
Cazzix said:
Been having an issue where the plugin causes OBS to crash any time I minimize or resize the window/source its capturing. Is there any known fix for this?
Click to expand...
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.
 
AaronD said:
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.
Click to expand...
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.
 
AaronD said:
I don't, beyond what I said previously, which sounds like it doesn't fit your workflow very well.

I'm leaning towards a bug. If my suspicion is right that it has a roughly 2-second buffer (possibly to give the encoder some temporal space to work with?) with some variance in its actual length, and it discards that buffer when it stops instead of finishing it, then that might explain both of our quirks. The solution in that case would be to finish encoding the buffer instead of discarding it.

Regardless of what the mechanism is though, the requirement stays the same: Whatever happens in the real world before I click the stop button (or whatever it is that ends the recording) should appear in the file, and whatever happens in the real world after I click the button should not appear in the file. The tolerance is human imperceptibility (likely a small handful of frames). Whatever it takes to meet that requirement, do that.

Depending on how the startup works, it might require a special case to not create a short glitch-recording then, while otherwise keeping the above. For example, if everything starts enabled, and then some get disabled later according to the saved settings.


That would explain why I didn't see that problem. I'm set to always record, and use the enable to start and stop, and so I'm particular about not having it enabled unless I really do want to record. So it's naturally disabled when I'm changing stuff, and that works.

I completely agree on the usability though: a user action that does nothing with no explanation, is a problem.
Click to expand...
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.
 
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

1785190113916.png
 
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.


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.
 
BEPO Media said:
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.


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.
Click to expand...
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.
DistroAV - Network Audio/Video in OBS-Studio using NDI® technology DistroAV

DistroAV - Network Audio/Video in OBS-Studio using NDI® technology

Network Audio/Video in OBS-Studio using NDI technology
Beam YorVeX

Beam

Transmit lossless (raw or compressed) video and audio feeds between OBS instances. NDI alternative.
Teleport Tuna

Teleport

An OBS Studio plugin for an open NDI-like replacement
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 said:
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.


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.
Click to expand...
AaronD said:
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.
DistroAV - Network Audio/Video in OBS-Studio using NDI® technology DistroAV

DistroAV - Network Audio/Video in OBS-Studio using NDI® technology

Network Audio/Video in OBS-Studio using NDI technology
Beam YorVeX

Beam

Transmit lossless (raw or compressed) video and audio feeds between OBS instances. NDI alternative.
Teleport Tuna

Teleport

An OBS Studio plugin for an open NDI-like replacement
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.
Click to expand...
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.

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.
 
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.
 
You must log in or register to reply here.
Back
Top