Niklas Haas

> Is there any way to solve this problem temporarily？ It could probably be worked around by forcing all resizes to be synchronous. I guess I could add a debug...

Oh, that commit just fixes it for screenshots, not during playback with `display-resample`. You're right that this is a separate issue.

I think this is technically intended behavior. The justifications behind the change of the default output black point still apply, no? On an OLED display, the un-altered image would look...

> In this case the content supposedly has a 0.0050 nits black point, but in reality it is probably lower. So remapping it causes some crush. This is interesting, if...

> I'm not sure if any display would remap the black point at all, it would have to be tested. No displays map the black point *down*, which is exactly...

> I guess that tone mapping step was/is invisible because the nits are so low? I think this was the case, yeah. I played around with the change for this...

In `--vo=gpu-next`, it defaults to 1000:1 contrast. No way to change it, currently. (Patches welcome to add an option)

It's worth noting that I'm currently (once again) rewriting this code, to work differently in the presence of ICC profiles

> A contrast of 1000:1 I'm not sure how to calculate the black level from it. There needs to be a lowest level of black that mpv sends to the...

Can't reproduce, it works for me. Can you try running mpv from the command line to see if it prints any error before crashing?