Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bugfix for lost x265 parameters #64

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Kleinrotti
Copy link
Contributor

No description provided.

when you select a parameter in x265 with a no- beginning, it was lost after opening the config window again
Core/wxOptionEditor.cpp Outdated Show resolved Hide resolved
@@ -123,7 +124,8 @@ void wxOptionEditor::Configure(EncoderInfo encoderInfo, OptionContainer options)

// Import stored settings
//EncoderOptionInfo optionInfo = optionProperty->GetOptionInfo();
if (options.find(optionInfo.parameter) != options.end())
if (options.find(optionInfo.parameter) != options.end()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice finding!

  1. Make sure the combination "no-" + option name is actually a valid and supported option name. i.e. "no-preset" or "no-crf" is not supported
  2. This would match both "aq-motion" and "no-aq-motion". First one should set "Yes", second one "No". The latter case does work but only as part uncontrolled behaviour. "no-aq-motion" is not found in options[optionInfo.parameter]
  3. The whole "no-" thing should only be allowed for boolean option types

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my tests this change worked fine so far without any bugs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did another commit with an additional check if the prefix is valid. Only options where prependNoIfFalse is set to true in the json file are valid now.

One more check if the prependNoIfFalse boolean value is set to true, only if this is the case, is's a valid condition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants