Open ruihe774 opened 1 month ago
Download the artifacts for this pull request:
@KonoVitoDa plz test it.
Works perfectly, thank you very much!
close https://github.com/mpv-player/mpv/issues/10464 instead
Can we also switch to tight by default?
Can we also switch to tight by default?
What's the point to make a breaking change? IMO this option is only related to personal preference. Users can easily set this option by themselves.
How do I get the updated version with the new feature implemented?
How do I get the updated version with the new feature implemented?
Before this is merged, you can get the build artifacts from https://github.com/mpv-player/mpv/actions/workflows/build.yml. Keep in mind you need to find build artifacts of correct PR.
After this is merged, you can get it from unofficial nightly builds https://mpv.io/installation/
What's the point to make a breaking change? IMO this option is only related to personal preference. Users can easily set this option by themselves.
Users can change many options by themselves, but there's still value in the default value being something that doesn't need to be changed for most users. I'd argue the current bounding box is not wanted by anyone.
I'd argue the current bounding box is not wanted by anyone.
Patches welcome. Please contain default changes and associated bikeshedding to a separate PR.
What's the point to make a breaking change? IMO this option is only related to personal preference. Users can easily set this option by themselves.
Users can change many options by themselves, but there's still value in the default value being something that doesn't need to be changed for most users. I'd argue the current bounding box is not wanted by anyone.
Worth noting that BorderStyle=3 has suboptimal behavior for non-opaque colors. e.g.:
I guess it was the reason mpv chose 4 as the default.
Will this update also change the way --sub-back-color
is selected? Because on my mpv.config it's set to #000000
(black), but in this specific part it seems to be using the sub's original border color:
Will this update also change the way
--sub-back-color
is selected? Because on my mpv.config it's set to#000000
(black), but in this specific part it seems to be using the sub's original border color:
The behavior did not change. It only applies to SRT subtitles. If you want to override ASS subtitles that select a BackColor itself , you may use --sub-ass-style-overrides
.
ASS subtitles that select a BackColor itself
But this same subtitle is shown with the black back color in the old version, so it seems to be something related to the new feature:
ASS subtitles that select a BackColor itself
But this same subtitle is shown with the black back color in the old version, so it seems to be something related to the new feature:
Please attach your log file and subtitle files (you can extract it using ffmpeg) so that I can look into it.
Please attach your log file and subtitle files (you can extract it using ffmpeg) so that I can look into it.
output-new.txt output-old.txt [Erai-raws] Sousou no Frieren - 01 [1080p][81106F0B]_Subtitles02.POR.zip
The video file is the 01 from here: https:// nyaa . si/view/1752250
I cannot reproduce it. With the same commit of mpv and same set of subtitle related options in your output-old.txt
, the BackColor and BorderStyle are also selected by ASS subtitle file itself.
Screenshot:
My log: mpv.log
My options:
[ 0.001][v][cplayer] Setting option 'config' = 'no' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-files-append' = 'Erai-raws.Sousou.no.Frieren.-.01.1080p.81106F0B._Subtitles02.POR/[Erai-raws] Sousou no Frieren - 01 [1080p][81106F0B]_Subtitles02.POR.ass' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-back-color' = '#000000' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-border-color' = '#000000' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-ass-vsfilter-aspect-compat' = 'yes' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-scale-with-window' = 'no' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-ass-scale-with-window' = 'yes' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-font-size' = '53' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-pos' = '100' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-margin-x' = '25' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-margin-y' = '22' (flags = 8)
[ 0.001][v][cplayer] Setting option 'sub-use-margins' = '' (flags = 8)
[ 0.001][v][cplayer] Setting option 'osd-font-size' = '25' (flags = 8)
[ 0.001][v][cplayer] Setting option 'osd-color' = '#FFFFFFFF' (flags = 8)
[ 0.001][v][cplayer] Setting option 'osd-back-color' = '#000000' (flags = 8)
[ 0.001][v][cplayer] Setting option 'log-file' = '/var/data/mpv.log' (flags = 8)
Really weird. Is not it related to the used FFmpeg version?
Btw, I don't know why the FFmpeg version on my output-old.txt is shown as N-115357-g0c1304ae1
while I have ffmpeg version 2024-05-20-git-127ded5078-full_build-www.gyan.dev
on my PATH.
mpv's updater also says FFmpeg doesn't exist (I downloaded my build from here).
Btw, I don't know why the FFmpeg version on my output-old.txt is shown as N-115357-g0c1304ae1 while I have ffmpeg version 2024-05-20-git-127ded5078-full_build-www.gyan.dev on my PATH.
mpv's CI statically links with ffmpeg. It's not overridable. Many unofficial builds also do that.
Really weird. Is not it related to the used FFmpeg version?
I don't think it is related to ffmpeg version. I think it is related to your scripts. You may try --no-config
to disable them and have a check.
Anyway, imo --sub-back-color
is intended to work with only SRT (and other plain text) subtitles that does not define styles. @na-na-hi I wonder whether I have a correct understanding.
It's documented that most subtitle options don't affect ASS subtitles. --sub-ass-*
options exist for that purpose.
Oh, I was sleepy and forgot to mention that I use this keybind to switch between sub's original style and my own style:
d cycle-values sub-ass-override "force" "no"
Both of the screenshots I shared before were with sub-ass-override
set to force
, but I don't understand why on _mpv-x8664-20240522-git-0dd6321 it made the back color black while on the artifact version _mpv-x86_64-w64-mingw32_ it used original sub's border color.
Oh, I was sleepy and forgot to mention that I use this keybind to switch between sub's original style and my own style:
d cycle-values sub-ass-override "force" "no"
Both of the screenshots I shared before were with
sub-ass-override
set toforce
, but I don't understand why on _mpv-x8664-20240522-git-0dd6321 it made the back color black while on the artifact version _mpv-x86_64-w64-mingw32_ it used original sub's border color.
Reproduced with --sub-ass-override=force
.
Well, if this only occurs with specific subtitle lines (this one is a typesetting), so I think it's not a big problem. Actually it makes sense to have a totally grey sub-back-color
instead of a black sub-back-color
with a grey sub-border
over it.
Actually it makes sense to have a totally grey
sub-back-color
than a blacksub-back-color
with a greysub-border
over it.
But it would be great if this behavior could also be customized by user.
It is related to the selection of different colors in ASS. BorderStyle=3 will use OutlineColor and BorderStyle=4 will use BackColor. You can use --sub-border-color
to customize OutlineColor. I'm still refactoring related options to make it more consistent (e.g. renaming --sub-border-color
to --sub-outline-color
to match the upstream ASS spec.)
The problem is actually with how BorderStyle = 4
is implemented in libass
. Normally, subtitle rendering works like this:
BackColour
if the shadow is drawn (has non-zero offset). It respects the BorderStyle
setting, so if it's set to 3, the rectangles are drawn. OutlineColour
if the border is drawn (has non-zero size). It respects the BorderStyle
setting, so if it's set to 3, the rectangles are drawn. When BorderStyle = 4
was bolted on libass
in https://github.com/libass/libass/commit/4648a02281ff0860cb06e3f56df9095b8a114294, step 1 is replaced as the following if BorderStyle = 4
:
BackColour
. Note that it disrespects the shadow offset, so if the offset is zero, the background is still drawn.
For the sample file, when the text border is drawn, it respects the BorderStyle
setting and draws the background with the OutlineColour
. Even if the text has a non-zero shadow offset, its color is overwritten by the later drawn border color. AFAIK this is expected ASS behavior, while the nonstandard BorderStyle = 4
disregards that. See https://github.com/libass/libass/pull/105#issuecomment-44789530.
BorderStyle=3 will use OutlineColor and BorderStyle=4 will use BackColor.
This is not true, see above. BorderStyle = 3
uses both colors. It's just the shadow color isn't visible when the shadow offset is zero and thus not drawn.
For the sample file, when the text border is drawn, it respects the BorderStyle setting and draws the background with the OutlineColour. Even if the text has a non-zero shadow offset, its color is overwritten by the later drawn border color. AFAIK this is expected ASS behavior, while the nonstandard BorderStyle = 4 disregards that. See https://github.com/libass/libass/pull/105#issuecomment-44789530.
BorderStyle=3 will use OutlineColor and BorderStyle=4 will use BackColor.
This is not true, see above. BorderStyle = 3 uses both colors. It's just the shadow color isn't visible when the shadow offset is zero and thus not drawn.
Yeah. OutlineColor, BackColor, and BorderStyle are orthogonal options.
I've made some breaking changes to option naming to match ASS spec. Some option "dispatching" logic has been removed. IMO now it's more simple and intuitive.
There is no benefit of the border -> outline
renaming change. Just add some clarification in the documentation instead. Please revert.
There is no benefit of the
border -> outline
renaming change. Just add some clarification in the documentation instead. Please revert.
I do not agree.
BorderStyle=4
does not use --sub-border-color
, which leads to confusion.OPT_REPLACED
. Existing usages are not broken.--(sub/osd)-shadow-color
is removed. It is already a breaking change. No meaning to continue using the old names for compatibility reasons.
- It matches the naming in specs.
border
is a better name for 99% of the cases.
BorderStyle=4
does not use--sub-border-color
, which leads to confusion.
There is no confusion: it's libass
-specific and not part of the ASS spec. It's not supported by xy-VSFilter
.
--(sub/osd)-shadow-color
is removed. It is already a breaking change. No meaning to continue using the old names for compatibility reasons.
This breaking is not needed when you can alias it to --sub-back-color
.
- It matches the naming in specs.
border
is a better name for 99% of the cases.
BorderStyle=4
does not use--sub-border-color
, which leads to confusion.There is no confusion: it's
libass
-specific and not part of the ASS spec. It's not supported byxy-VSFilter
.
--(sub/osd)-shadow-color
is removed. It is already a breaking change. No meaning to continue using the old names for compatibility reasons.This breaking is not needed when you can alias it to
--sub-back-color
.
OK. I keep them as aliases. No interface breaking change now.
Hi. Any news?
Hi. Any news?
My work is finished. Please be patient. People need time to review and test the PR.
I think the 2 commits can be squashed, and
local has_shadow = mp.get_property('osd-back-color'):sub(2, 3) == '00'
in console.lua should become
local has_shadow = mp.get_property('osd-back-color'):find('box$') == nil
Rebased. I think it's time to merge it. @na-na-hi @kasper93
Rebased. I think it's time to merge it. @na-na-hi @kasper93
I don't follow all the sub/osd styles, ask someone else to review those.
Also --(sub/osd)-border-style=none
doesn't work. It behaves the same as outline-and-shadow
.
@Dudemanguy
These new option names stick to whatever names the ASS format uses, but as pointed out, the meanings of these names can be completely different depending on the border style. Is it a good idea, for example, to require the user to set --sub-shadow-offset
to control the margin of the background box?
I just want to make sure that these names aren't confusing so that they won't be unnecessarily renamed/removed after the fact.
These new option names stick to whatever names the ASS format uses, but as pointed out, the meanings of these names can be completely different depending on the border style.
If what happens changes completely depending on the border style, I think we're just doomed, no? I don't have any good name ideas anyway.
If what happens changes completely depending on the border style, I think we're just doomed, no?
The alternative is that we add separate options that make sense, like one for each background color, shadow color, border color, margin size etc., and apply the appropriate ones based on the border style selected. I think it makes no sense that if I want to change the border style from opaque box to background box I need to change the values of both border size and shadow offset just to keep the margin size, for example. Instead it can be a single margin size option which depending on the border style set, sets the corresponding underlying ASS properties.
IMO 1:1 mappings from CLI options to upstream's options are intuitive. Despite historical reasons, ASS spec and libass are designed to be in that shape, and users can consult the spec of ASS and the doc of libass by themselves if in doubt. Using a complex option handling and mapping logic will make things complicated and hard to understand, unless we thoroughly describe our logic in the documentation, which is a maintain burden and a reinvention of existing spec.
What should be done with --(sub/osd)-border-style=none
? It still doesn't work as documented. This needs to be fixed or dropped as a choice.
What should be done with
--(sub/osd)-border-style=none
? It still doesn't work as documented. This needs to be fixed or dropped as a choice.
Sorry, I forgot it.
It turns out 0
is not a valid value for BorderStyle
in ASS. Now I just remove it.
that draw background that tightly wraps each line of text.
Fixes #14194