obsproject
UI: Resize Output to Source Size using rounded up values
Description
Round resolution up to closest multiple of 4 for width, and 2 for height
Motivation and Context
Fixes #11201
Prevents odd numbered resolutions, and conforms to https://github.com/obsproject/obs-studio/commit/21ec81ebcc43e465160fcc880e4088c64d407a23
How Has This Been Tested?
Win 10 22H2. Created a color source with 1111x1133 resolution, and rescaled. Observed resolution being set to 1112x1134.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
This is inconsitent with the other resolution restrictions in OBS, which are:
- Width must be a multiple of 4
- Height must be a multiple of 2
See https://github.com/obsproject/obs-studio/commit/21ec81ebcc43e465160fcc880e4088c64d407a23
This is inconsitent with the other resolution restrictions in OBS, which are:
- Width must be a multiple of 4
- Height must be a multiple of 2
See 21ec81e
Thank you :) Alright, I can do that, or are we happy with just doing a check for multiples of 2? EDIT: Made a decision, let me know if multiples of two is preffered.
This doesn't actually fix the underlying problem of #11201. That issue is in regards to the Rescale Output in Output settings.
The underlying problem is that when you set an invalid value in Video settings, we sanitize it internally before it makes it to the encoder. Even if you input 1920x1079 as your Canvas or Output resolution, it will end up sending 1920x1080 to the encoder.
Rescale Output setting needs this sanitization as a proper fix.
This PR is still valuable because we still want Resize Output to Source Size to use rounded up values, but the title should be amended.
As an aside, we should also fix the UI to properly display the corrected values it's going to use, rather than the invalid ones the user input that get magically adjusted.
This doesn't actually fix the underlying problem of #11201. That issue is in regards to the Rescale Output in Output settings.
Oh, my apologies, I must have misunderstood.
As an aside, we should also fix the UI to properly display the corrected values it's going to use, rather than the invalid ones the user input that get magically adjusted.
Sounds good, but I am unfortunately not capable enough in the QT arts to manage, so I'll leave that to someone else.
Rescale Output setting needs this sanitization as a proper fix.
Makes sense. Might have a look to see if its something I'm capable of PR'ing.
Rescale Output setting needs this sanitization as a proper fix.
Unfortunately, I was not capable of doing so. I tried following the setup, but it goes too deep into scary systems I don't feel comfortable messing around in, because I don't understand the implications. If this PR does not make sense as it stands, then I suggest we close/drop it, and leave the issues open for others to fix down the line. I personally think that this "bandaid" will remove a footgun, and it might be a while til the output res workflow is redone, so I find it worthwhile to merge.
whew, that was a bit of a rebase, since the original commit changes a file that no longer exist, but I found the right spot to re-apply the code.
Tested again, very briefly, color source 1111x1133 -> rescale, and still the expected outcome of 1112x1134, so should be good (and it didnt crash or do anything else weird).