Replay buffer does not respect maximum time setting, saves files much longer/larger than intended

[b02860de585071a2]

Operating System Info

Other

Other OS

Arch Linux

OBS Studio Version

30.0.0

OBS Studio Version (Other)

30.0.0

OBS Studio Log URL

https://obsproject.com/logs/b3YBDkUJ7gyoovOa

OBS Studio Crash Log URL

No response

Expected Behavior

When my replay buffer is set to a maximum of 120 seconds and 8192MB memory usage, I expect it to output files with a length of ≤120 seconds (± a few seconds due to keyframes and other variables).

For context, given my other recording settings, this typically works out to around ~2.5GB file sizes for saved replay buffer segments.

Current Behavior

Saving the replay buffer creates a file that instead goes back to the moment OBS was launched, rather than respecting the maximum length setting.

As an example: I currently have a recording from replay buffer that is over 26 minutes long, and approximately 9GB. As you might expect, the quality is severely degraded (to say the least), and it takes much longer than normal to actually save + write to disk.

Steps to Reproduce

1. Launch OBS
2. Wait for an amount of time greater than specified in the "Maximum Replay Time" setting
3. Save the replay buffer and observe the file produced

Anything else we should know?

• Rolling back to the previous version in the Arch repositories (28.x.x) resolves the issue
• Manually stopping/starting the replay buffer seems to reset it, however the next saved segment will begin at the moment the buffer was restarted (ie, still not respecting the maximum time value).
• Changing the "Maximum Replay Time" value does not work
• Whether or not you are actively recording has no effect
• Disabling plugins or changing other video settings does not appear to have an effect

[RytoEX]

Duplicate of #8100 ?

[b02860de585071a2]

EDIT: it does actually seem to be a duplicate. I'm now experiencing this on all versions from 29.0.0 to 30.0.0, both on native and Flatpak packages (28.x.x is not functional on Arch anymore due to broken deps).

Any workaround would be appreciated, as this quite literally makes the program unusable for my use case.

[b02860de585071a2]

I figured it out!

Using "low latency" or "ultra low latency" tuning with either NVENC encoder (H.264 -or- HEVC) causes the issue. All other settings seem to be irrelevant - I isolated each parameter individually in my testing to be sure.

Unsure if this is specific to Linux or Mac though, as I don't have a Winows machine to test on.

For the time being, I am switching to "high quality" tuning as a temporary workaround.

Here is a gist with basic system and package info in case it's useful for debugging.

[SuslikV]

Because

preset >=p3 internally enables B frames when tuningInfo = ::NV_ENC_TUNING_INFO_HIGH_QUALITY or ::NV_ENC_TUNING_INFO_LOSSLESS

can you also experiment with different preset settings (above/below p3) and "low latency" enabled?

[b02860de585071a2]

can you also experiment with different preset settings (above/below p3) and "low latency" enabled?

This was actually one of the final things I tested earlier. The behavior was consistent across all presets (ie, low latency/ultra low latency trigger the bug, high quality is unaffected).

I left b-frames at the default value of 2 when first trying to isolate the root cause, then experimented with a couple different values (0, 2) at P1 and P7 to confirm my results.

[MadByteDE]

I got the same issue on Fedora 40 (shipping OBS 30.1.1 rn).

Nvidia RTX 4070, Driver Version: 555.58.02, Wayland, KDE 6.1.3.

Thanks for the workaround OP :).