builtin.conf: remove debanding from high-quality profile

[kasper93]

[Obegg]

Is there a specific reason?

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-13-intel
• mpv-macos-12-intel
• mpv-macos-14-arm

[kasper93]

Is there a specific reason?

Read commit message.

[Akemi]

äwe had this discussion a few times before and i always thought and said; debanding should not be the default for a high quality preset, since the assumption should be the usage of a 'perfect'/best source.

the problem with debanding:

• debanding is inherently destructive
• there is no one default to 'fix' them all
• only useful for bad sources (or everything that is streamed lol)

filter that possibly increase the quality only in certain cases (and decrease it in others) should be opt-in instead of opt-out.

i personally also deactivated it and put a toggle on the 'd' key, as proposed here, to only activate it if visually needed.

though in the end i am fine with either.

[edit] the assumption for activating it for the high quality profile was that the majority of all sources are bad. if we stay with that assumption it should probably stay.

[Obegg]

I have a few questions. In the past I have discussed this very option (to disable deband for high-quality profile) in this issue and there were a few replies that says otherwise, here are the replies:

mpv's deband algorithm is very lightweight and significantly increases quality on the vast majority of content (i.e. content that isn't already debanded). If you watch content that is primarily debanded in advance (e.g. through f3kdb) then you should disable it on your own system. These are intended to be sane defaults, not the best for your personal computer and your personal setup.

mpv's default debanding settings are tuned to be universal for both good and bad sources. Theoretically, it could result in detail loss for a source that has already been filtered for banding, but mpv's defaults don't seem aggressive enough to actually be a net-negative in this scenario. Disabling deband is only for peace-of-mind.

This is why I made the caveat that turning deband off could be a net-positive if you are 100% certain your source has been filtered for banding artifacts and other forms of quantization noise. But even then, people who do this filtering during encoding do it under the assumption that your TV or media player already has its own associated debanding filters that will be doubling on top of the pre-filtering.

So... what's the verdict?

[Jules-A]

What about reducing grain/strength rather than disabling completely? Not as a default for debanding but for GPU-HQ defaults.

[Akemi]

the last two comments are imo wrong (the ones quoted by @Obegg ).

1. i have had various sources where the defaults killed details especially in background details
2. i never encoded anything with the assumption that a TV or a media player does debanding, i filter and encode in a way that the outcome is the best without any more (intrusive) filtering (ignoring needed filter like dithering, scaling, etc). i don't know anyone who encodes/filter by that assumption.

[Jules-A]

i don't know anyone who encodes/filter by that assumption.

I don't have enough experience to comment on non-anime sources but Crunchyroll/Funimation/Hidive all have a large amount of (mostly older) content that has banding.

[kasper93]

mpv's deband algorithm is very lightweight and significantly increases quality on the vast majority of content

I don't agree with that. I can say the opposite. That it does not increase quality with the vast majority of content. Debanding is needed for some content, but I argue not the vast majority of it. YMMV depending what you watch and where you source your movies, but in the end of the day mpv cannot know it and shouldn't by default enable debanding. It is useful, but it should be opt-in.

mpv's default debanding settings are tuned to be universal for both good and bad sources.

After recent increase of strength? Overall if the source does not need debanding it should not be applied, not only because of real detail loss, but also because dbanding itself is heavy on gpu processing.

What about reducing grain/strength rather than disabling completely? Not as a default for debanding but for GPU-HQ defaults.

default debanding settings should be tuned for best results, but also not applied if not needed. No point in adding pointless filtering which can only reduce quality if there is no banding in the first place.

i have had various sources where the defaults killed details especially in background details

+1

i never encoded anything with the assumption that a TV or a media player does debanding, i filter and encode in a way that the outcome is the best without any more (intrusive) filtering (ignoring needed filter like dithering, scaling, etc). i don't know anyone who encodes/filter by that assumption.

That's the main point, there are

1. high-quality sources that doesn't need debanding
2. already debanded sources that doesn't need further processing
3. low-quality banded sources that needs debanding

Only in case if 3) debanding should be enabled and it is user choice.

I don't have enough experience to comment on non-anime sources but Crunchyroll/Funimation/Hidive all have a large amount of (mostly older) content that has banding.

That's the problem, if we tune mpv only for anime content, sure debadning likely is needed, but for live-action movies it is not always needed.

Maybe it is true that most live streams and anime content need debanding, but in the same time there is probably equally large number of sources that doesn't need it and I argue it should be opt-in feature.

But I won't push it so hard, if community decides that debanding is good by default, I'm fine with that.

[Obegg]

Fine, I'm convinced deband should be disabled on high-quality profile.

[Akemi]

i don't know anyone who encodes/filter by that assumption.

I don't have enough experience to comment on non-anime sources but Crunchyroll/Funimation/Hidive all have a large amount of (mostly older) content that has banding.

i don't disagree. i agree that most sources are shit. though they don't encode by the assumption that anything else does the debanding. they just do dumb transcodes of various sizes and resolutions and mostly care about their bandwidth (or rather their profit in this case). it's just 'low effort' encoding without the goal to have the best/good 'quality'.

[Hrxn]

I agree with this commit as well..

Explanations have already been given. It doesn't really make sense for FHD material (unless the encode is already fucked up), let alone 4K - and then it gets computationally costly enough.

debanding should be thought of as a method to fix bad source material, and as Akemi and others have pointed out, it should be opt-in.

It can also easily be used with an auto profile, here's what I currently have in my config:

[LQ]
profile-cond=get('video-params/average-bpp') and get('video-params/average-bpp') < 24
profile-restore=copy
deband=yes
deband-range=8
deband-grain=24
deband-threshold=48
deband-iterations=4

Disclaimer: I've found this via web search, don't ask me I have no fucking clue (tm). While it works (theoretically), I've found that this condition gets triggered by source material that is already "good enough", so I end up manually toggling off the debanding. I'm all ears for suggestions on how to improve this.

[ghost]

in this issue

Keep in mind that my comments on this issue were before deband-threshold was increased in https://github.com/mpv-player/mpv/pull/12441. In reality (but at the time, I didn't realize it), deband was basically doing nothing by default for banded sources, which I don't consume a lot of. It's kind of insane how no one has noticed this for years, but oh well.

[Dudemanguy]

I'm totally OK with removing debanding. It's trivial to just make an autoprofile that turns on debanding for a Subsplease file or whatever you're watching.

[paulguy]

Would it be worthwhile to make the default parameters for debanding maybe more aggressive/fit for especially low quality content since the consideration for default parameters no longer has the constraint that it's intended to be on as part of a high quality profile? That is, effective for cases where one would notice it's especially needed?

[llyyr]

Would it be worthwhile to make the default parameters for debanding maybe more aggressive/fit for especially low quality content since the consideration for default parameters no longer has the constraint that it's intended to be on as part of a high quality profile? That is, effective for cases where one would notice it's especially needed?

Yes, I will open a PR for this later after testing out how aggressive it can be with a variety of content

[LightArrowsEXE]

Rather than tying debanding to D, I think it'd be better to set it to h (which I believe is currently unused?). This makes it even just a tiny bit easier to quickly enable/disable debanding on the fly for the user, as it requires one less key stroke. This also keeps D unused in the event anyone implements a real-time IVTC filter one day (pretty please?), which would be more intuitive to share a key with deinterlacing.

If h is out, I think swapping around the hotkeys for deinterlacing and debanding would be better, seeing as debanding is going to generally be more relevant than deinterlacing for most current-day sources.

[haasn]

LGTM

Bitrates and codec quality have gone up, even on YouTube, and the recent bump in deband strength invalidates much of the preexisting arguments.

[raptordaking]

I agree this is a good change and would also suggest the default bind for debanding be set to h, that is where I've had it for a few years now as it was not used for anything else at the time and that still seems to be the case? As Light said this would leave D for a possible bind for IVTC or related and debanding could be activated with a single key press instead of Shift+d which is very unintuitive imo when a seemingly free key is available.

[sfan5]

My opinion: Banding is everywhere, in YouTube videos, in Anime, in the movie releases that average users download.

I think having debanding as a default in the high-quality profile is reasonable. After all high quality doesn't mean "my source is high quality" (or we wouldn't need scalers) but "play this back in high quality".

If the recent changes to debanding defaults invalidate the one-size-fits-all idea, then I'd rather see them adjusted again. (see https://github.com/mpv-player/mpv/pull/12441#issuecomment-1728234133 for a comparison)

[guidocella]

I think b would be better than h since it's also unused and banding starts with b.

[LightArrowsEXE]

I think b would be better than h since it's also unused and banding starts with b.

Personally, I'm fine with either. I just think it's better to not remap d if possible since that is a pre-established key, but also using a lowercase letter is a bit nicer on the user since this key is more likely to be pressed frequently.

That said, an argument could also be made for swapping around the deinterlacing key itself and assigning deband to d, assuming that's more intuitive for the end user and easier to remember. Deinterlacing could then be moved to h since it's not as relevant for most modern sources. It's difficult to find a way to make everyone happy with something like this lol.

[kasper93]

Changed keybind to h as it is more accessible than D and d is already taken.

My opinion: Banding is everywhere, in YouTube videos, in Anime, in the movie releases that average users download.

Agreed. But the main issue is the amount of banding. Insignificant amount of banding is not that problematic and for the heavy banded sources like older youtube or twitch you have to use at least deband-threshold=64 to make a difference, which already is proven to destroy detail too much on high quality source.

If the recent changes to debanding defaults invalidate the one-size-fits-all idea, then I'd rather see them adjusted again.

I'd like that too, but at this point I think we cannot agree on the one-size-fits-all config. For heavily banded source material, that needs debanding we need stronger processing, for everything less stronger processing has adverse effect and removes image details.

We changed from 64 to 32, which arguably didn't remove much banding, making this option useless. Than we increased to 48 (current) and it is middle ground that still is not best. And above that, debanding itself is heavy on gpu, which we cannot mitigate with any settings. I think it should be enabled when it is necessary. I personally just toggle it when I start noticing banding and it bothers me.

---

My opinion about keybind:

• d should stay for deinterlacing, just for the sake of not changing established key
• D is not convince to use, lower case letter is better
• h is ok
• b is maybe better for banding, but it is at the middle of spacebar, wouldn't it be easy to hit it accidentally? When pausing?

But honestly either b or h is fine for me.

Feel free to vote with reactions to this post: 🚀 b ❤️ h

[sfan5]

I'd like that too, but at this point I think we cannot agree on the one-size-fits-all config.

I did some quick (admittedly not exhaustive) testing and maybe the current defaults are good enough™? threshold=32 indeed does just about nothing while threshold=64 might risk destroying too much detail.

for completeness: the commits that changed deband options are 12ffce0f224056f91a20c9f0b197f4973931efbe & 2fd5b9b4dda14c858f24548801da587dea747cac

And above that, debanding itself is heavy on gpu, which we cannot mitigate with any settings.

Now I think this is really not an argument. high-quality is already heavy by using the most demanding scalers we have, despite only minor visual differences.

but it is at the middle of spacebar, wouldn't it be easy to hit it accidentally?

does this happen to people? it doesn't to me You're out of luck here anyway because there's a bunch of keys you can hit to make mpv misbehave with no way to fix it unless you know what you did.

[llyyr]

h or b for debanding makes no intuitive sense, D is free and pressing shift isn't a huge inconvenience. I'm in favor of using D for debanding over the others, or possibly swapping d and D

[na-na-hi]

Note that the wiki has been suggesting using b for debanding since 2016: https://github.com/mpv-player/mpv/wiki/Fixing-Simulcasts/3cd5a677b66982ebd0ff63692f62b600d95fc52b Looks like a reasonable precedence for me.

[ghost]

Good change, don't mind the keybind aslong as its a key that only requires a single keystroke. No D please, we have several unused keys to bind to instead.

[ghost]

I don't think there's any previous precedent on keybinds being "intuitive". I mean, cycling through audio and subtitle tracks (probably one of the most common operations while using a media player) is bound to Shift+3 and j respectively.

[llyyr]

I don't think there's any previous precedent on keybinds being "intuitive".

That doesn't mean we can't start now...

Either way, if pressing Shift is so hard then my vote is for b

[aufkrawall]

I did some quick (admittedly not exhaustive) testing and maybe the current defaults are good enough™? threshold=32 indeed does just about nothing while threshold=64 might risk destroying too much detail.

Ack, 32 does hardly do anything more than processing inherent 8 bit banding, which is pretty much unnoticeable vs. real world content/compression-banding.