Encoder probing performance improvements #2111
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Encoder reprobing takes a significant portion of the total time to connect, especially when streaming the desktop. This PR addresses this by avoiding reprobing in cases where we know the GPU hasn't change and improving the performance of reprobing when we do need to do it.
To skip reprobing, we can use
IDXGIFactory1::IsCurrent()
which will tell us if GPUs or outputs changed state since the factory object was created. This check does catch a bit more than is needed, since some output changes will trigger a reenumeration. However, for desktop streaming and for games where the user just wants to adjust some Moonlight settings and get right back in, this is a major improvement. We can probably do better once #2032 is in.For reprobing optimizations, we now avoid testing an encoder again with QP rate control when we know that the encoder always supports CBR/VBR. Trying again with QP just wastes time because we already know the encoder isn't present.
Likewise, we now don't bother trying again with an undefined reference frame count if we already found this encoder accepted a specific number of reference frames for H.264. I don't think there are any encoders in the real world that would accept reference frame count for H.264 but not HEVC or AV1.
Screenshot
Issues Fixed or Closed
Type of Change
.github/...
)Checklist
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.