Potential CPU oversubscription when capture and software H.264 encoding overlap #7458

Describe the bug

Summary

Concurrent capture and software H.264 encoding appear to size their CPU demand independently. The overlap eligibility check requires fewer capture workers than detected CPUs, but the encoder requests threads based on available CPU parallelism without subtracting the active capture workers.

This could create CPU contention during exports. This report is based on code inspection; it does not establish a measured performance regression or the cause of a machine hang.

Code examined

References are pinned to commit 0ca2b1ae9e72a9b9cae88e18e526a5fb129c880f.

1. Overlap eligibility — encodeStage.ts, lines 295–313

   canEncodeWhileCapturing() permits eligible H.264 exports to overlap capture and encoding when workerCount > 1 && workerCount < cpuCount. The condition counts capture workers, but does not account for the encoder’s requested thread count.

2. Encoder launch — encodeStage.ts, lines 363–368

   This path starts the streaming encoder while captured frames become available.

3. Software encoder arguments — streamingEncoder.ts, lines 364–369

   The software encoding branch calls appendSoftwareEncoderThreadsArg(args, encoderName) without providing a thread budget adjusted for capture.

4. Thread-count calculation — softwareEncoderThreads.ts, lines 6–12

   The helper defaults to availableParallelism(). For H.264, it applies no additional upper cap.

For an illustrative configuration with eight detected CPUs and available parallelism of eight, six capture workers would satisfy the overlap condition, while software H.264 encoding would request eight threads. This is not a measurement of fourteen busy cores: Chrome workers are not equivalent to single CPU threads, and encoding may wait for frames. It does show that the overlap check does not establish a combined CPU budget.

Potential effects worth measuring include reduced desktop responsiveness, slower capture, and longer overall exports under contention.

Temporary Solution

Since this causes the entire Windows machine to hang even though it's not at a 100% CPU to get back responsiveness reduce priority of WmiPrvSE.exe and ffmpeg.exe in Windows to "below normal", this will release the computer and even speed up the export rendering

** Also this conditions can be triggered in other flows in the code, but with this one Claude will probably find it easy to find the rest.

Minimal reproduction

This happens when you move between projects when another project is working on something

Steps to reproduce

I've added the relevant code areas above

Expected behavior

subtract CPUs that are active from available CPUs until they become available again

Actual behavior

encoder requests threads based on available CPU parallelism without subtracting the active capture workers.

Environment

studio installation on Windows 11

Additional context

No response