options: add secondary-sub-scale

[idontwannagoo]

Adds --secondary-sub-scale to allow scaling secondary subtitles independently from primary subtitles.

By default the option is default, which preserves the existing behavior by inheriting --sub-scale. Setting a numeric value overrides the scale for secondary subtitles only.

Fixes #14989.

Tested with:

• uvx meson test -C build --print-errorlogs

AI disclosure:
This contribution was developed with AI assistance. I have reviewed the changes, understand what was changed and why, and take responsibility for the code and review responses.

[verygoodlee]

By default the option is default, which preserves the existing behavior by inheriting --sub-scale.

I don't think this is necessary, as the --secondary-sub-delay/--secondary-sub-pos option never inherits --sub-delay/--sub-pos.

does this default value support the add/multiply command? If it does, run add secondary-sub-scale 1 first and then run add secondary-sub-scale -1, what value (default or numeric value) will it restore? this is unclear to users.

[idontwannagoo]

By default the option is default, which preserves the existing behavior by inheriting --sub-scale.

I don't think this is necessary, as the --secondary-sub-delay/--secondary-sub-pos option never inherits --sub-delay/--sub-pos.

does this default value support the add/multiply command? If it does, run add secondary-sub-scale 1 first and then run add secondary-sub-scale -1, what value (default or numeric value) will it restore? this is unclear to users.

To clarify before I change this: the current patch uses default to preserve the existing behavior where --sub-scale affects both primary and secondary subtitles.

However, this does make the command behavior less clear because default is represented as NaN, so the generic add/multiply commands do not meaningfully operate on it while the option is still at default: add secondary-sub-scale 1 keeps it at default, and adding -1 afterwards also keeps it at default. The commands only start behaving numerically after the option has first been set to an explicit value, for example with set secondary-sub-scale 1.

If we instead make --secondary-sub-scale default to numeric 1, the option would be consistent with --secondary-sub-delay/--secondary-sub-pos and command behavior would be clearer, but users who currently rely on --sub-scale affecting both subtitle tracks would need to set both options.

Another compatibility concern is that frontends, scripts, or existing user configurations may currently expose or set only --sub-scale. If --secondary-sub-scale defaults to 1, those setups would no longer scale secondary subtitles unless they are updated to set the new option as well.

Which behavior would be preferred for mpv? I can adjust the patch accordingly.

[idontwannagoo]

Would another option be to keep default for compatibility, but make add/multiply operate on the inherited effective value?

For example, if secondary-sub-scale is still default, add secondary-sub-scale 0.1 would first use the current --sub-scale value as the base, then store the result as an explicit secondary-sub-scale value.

This would preserve the existing behavior for users/frontends that only set --sub-scale, while still making the command behavior clearer.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-aarch64-pc-windows-msvc
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-aarch64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-i686-w64-mingw32
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-x86_64-pc-windows-msvc
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-x86_64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-x86_64-w64-mingw32

macOS

• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-macos-14-arm
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-macos-15-arm
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-macos-15-intel
• mpv-v0.41.0-dev-g88541b256-pr18166-27898187005-macos-26-arm

[idontwannagoo]

I pushed an implementation of this approach: default still preserves the existing --sub-scale behavior, while add/multiply now operate on the inherited effective value and store the result as an explicit value. I also added tests for both secondary-sub-scale and options/secondary-sub-scale.

With the follow-up commit, add/multiply on default use the inherited effective value as the starting point and then store the result as an explicit numeric value.

So add secondary-sub-scale 1 followed by add secondary-sub-scale -1 restores it to numeric 1, not default. To return to inherited behavior, the user would still set secondary-sub-scale back to default.

I think this is still less surprising than having add/multiply leave the option unchanged while it is at default.

[Dudemanguy]

Sorry for the late response after you did all this extra work but I agree with verygoodlee. I don't think a default value is needed. Several other secondary-sub-* options were added after the fact and they all control things totally separately. As long as it's marked as an interface change, I think it is much cleaner just to handle it like the other options.