Allow case where parity shard count is greater than data shard count #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NVIDIA GameStream can request a minimum number of parity shards and this can sometimes exceed the number of data shards. This case is already handled properly, so there is no need to fail reed_solomon_new() if ps > ds.
11 tasks
|
Thank you for the PR! One of the optimizations I made was to keep allocations to a minimum, so Thank you for patching it up along with the tests. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I'm working on replacing the Reed-Solomon implementation in Sunshine, an NVIDIA GameStream host, with nanors (with great performance results). For the most part it was a drop-in replacement, however there is one case which nanors doesn't currently support:
ps > dsThere is a configurable attribute in the SDP used by GameStream that allows the client to specify a minimum parity shard count per frame. NVIDIA's official clients and Moonlight both set this to 2, which means we can sometimes encounter a case where we have a small frame with only 1 data shard that will be generating 2 parity shards, which fails the check here.
This check appears to be superfluous, so I've removed it and updated the tests and benchmark to exercise that case. The tests required a bit more work than would be otherwise necessarily since it had assumptions that
2 * K >= K + Nin various places that needed to be adjusted. I also updated them to ensure that a failure ofreed_solomon_new()would result in aFAILEDoutput, rather than just outputting nothing.I locally ran
make checkandmake ubsanto verify this change.