feat(video): libx265: thread slicing support

[psyke83]

Implement thread slicing support for libx265.

Description

• Thread slicing eliminates the minimum frame latency that corresponds to the value of min_threads when frame threading mode is enabled.
• Add option to UI that allows users to revert to frame threading if desired, as slicing has some drawbacks (lower quality and worse performance, especially when min_threads is set to a low value).
• Sliced threads are already used in libx264, but the libx265 wrapper does not expose thread slicing via the standard avctx->thread_type encoder tunable, hence the need to set slicing via passthrough x265-params.
• Rename CPU cores -> threads elsewhere in code; min_threads operates on thread count which will differ to physical core count on a hyperthreading enabled CPU.

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[codecov]

Codecov Report

Attention: Patch coverage is 28.57143% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 6.10%. Comparing base (bb7c2d5) to head (3ed62a2).

Additional details and impacted files

@@            Coverage Diff             @@
##           nightly   #2350      +/-   ##
==========================================
- Coverage     6.10%   6.10%   -0.01%     
==========================================
  Files           85      85              
  Lines        18303   18308       +5     
  Branches      8319    8323       +4     
==========================================
  Hits          1118    1118              
- Misses       15376   16078     +702     
+ Partials      1809    1112     -697     

Flag	Coverage Δ
Linux	4.10% <0.00%> (-0.02%)	⬇️
Windows	1.51% <0.00%> (-0.01%)	⬇️
macOS-12	8.12% <28.57%> (+<0.01%)	⬆️
macOS-13	7.44% <28.57%> (-0.02%)	⬇️
macOS-14	7.72% <28.57%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/video.h	52.77% <ø> (ø)
src/config.cpp	5.07% <0.00%> (-0.29%)	⬇️
src/video.cpp	24.10% <33.33%> (+0.05%)	⬆️

... and 23 files with indirect coverage changes

[psyke83]

This would also need a bump in ctx->rc_buffer_size. The existing libx265 1.5x increase still produces a lot of underruns in sliced mode that appear as intermittent horizontal slices of an image being rendered out of sync. Increasing the buffer size resolves the images, but I haven't tested whether it causes overruns/failure to meet the correct bitrate limit.

Is there any interest in adding this feature? Honestly, I'm not too enthusiastic about it... Sliced mode is definitely better in terms of latency, but at least on my R5700X, it's still not a viable alternative to libx264 due to the CPU overhead even with the (maximum possible) 13 threads.

Sliced mode is just about good enough to capture 60fps @ 1080P, but that rate plummets when the CPU is loaded (in a game, for example).