Strange issue with blue-tinted bright gray colors turning arbitrarily pink

[forthrin]

When re-coding BT.2020 videos with bright gray colors with a blue tint (skies, white walls, etc.), the blue tint seems to be replaced by a pink tint in an arbitrary selection of (macro?)-blocks, while the rest of the video has negligible compression artifacts.

Only by reducing the quality parameter to low values like 13, 10 or 7 (depending on the video) does the phenomenon disappear, but then the video file gets unnecessarily large, since all other colors/areas of the video does not much require this.

This happens for a lot of, if not all, BT.2020 videos that contain the aforementioned colors.

What is it about this particular color tint and why is the blue mixed up with the red? What is going on?

PS! On a side note, the converted videos do not seem to preserve HDR information, so if that is somehow related, please do comment how to preserve that, but the main question is the tint issue.

ffmpeg -i 1-original.mkv -crf 1 2-maximum-quality.mkv
ffmpeg -i 1-original.mkv 3-default-quality.mkv
mpv --pause *.mkv # Use < and > to go between videos

Download 1-original.mkv (zipped) -- Missing in OP

Original screenshot:

Screenshot of converted video with clearly visible pink blocks:

$ mpv --version
mpv 0.34.1 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
 built on Sat Jan  8 16:50:23 CET 2022
FFmpeg version: 4.4.1
$ sw_vers 
ProductName:	macOS
ProductVersion:	12.4

[NSQY]

I don't think this has anything to do with mpv, your video has extraordinarily bad blocking on the chroma channels. Use a better codec or increase the bitrate.

[forthrin]

Those screenshots are SDR. Use lossless avif tagged as pq/bt.2020/bt.2020nc. Chrome will correctly show those in PQ on HDR display and AVIF is more effecient than JPEG XL since there will be no R'G'B' convertion and thus no dither and no rounding stuff.

ffmpeg.exe -i gsrfsw.264 -cpu-used 0 -aom-params lossless=1 -frames:v 1 stuff.avif

For example this screenshot is indeed HDR, i.e. it is tagged as PQ and is lossless with the video's YCbCr 420 samples (use Chrome, not buggy garbage that Firefox is). (It is also tagged as 2020 primaries and 2020 non contant luminance matrix.)

This happens because you did no tag the output stream.

ffmpeg -i 1-original.mkv -color_primaries bt2020 -colorspace bt2020nc -color_trc smpte2084 -color_range tv 3-default-quality.mkv

Thanks for getting back to me.

Sorry the original mkv file was missing from the OP, added now, so you can run the conversion locally on your computer.

Let me point out that the core issue is that the pink blocks appear on screen when playing the converted video with mpv. The screenshots (SDR indeed) were included to show the problem as seen when playing the video.

I still get pink blocks when adding the colors space parameters you suggested, and the output from FFmpeg is completely identical when leaving them out, so it seems FFmpeg does this by default, at least on my system.

Were you able to convert the video at default quality without getting the pink blocks? If so, please share a screenshot, and whatever command line you used to achieve this.

[forthrin]

I don't think this has anything to do with mpv, your video has extraordinarily bad blocking on the chroma channels. Use a better codec or increase the bitrate.

Interesting. Are you saying the original video has some low quality problems to begin with (albeit not initially visible to my eyes, at least), that is amplified when re-converting the video?

How are you able to point this out in the original material? Is there any FFmpeg line one can run to reveal these "extraordinarily bad blocking on the chroma channels"? To my eyes the original looks just fine.

And if this is the case, is there anything one can do about it but lowering the CRF value unnecessarily low?

PS! The original video was missing in the OP. Added now. Sorry about that.

[forthrin]

The video or the screenshots? Yes, the source is H.265, but I am unsure if the problem is related to the codec. I think I've seen it happen for H.264 too. Anyway, it seems no-one has the necessary knowledge to pinpoint the problem, so the pragmatic solutions seems to just avoid all HDR content. Me and a friend did some side-by-side comparison tests between 2k/4k, 8/10 bit, Blu-rays and encoded files, and the difference was surprisingly small for regular content (movies and TV-series). Until regular content looks like those slow motion frogs and water drops in the stores, there isn't much of an upside.

In one particular case of an original UHD Blu-Ray of "Arrival" (2016), dark-lit scenes with Amy Adams in an office early in the movie looked worse than a file copy of the same movie, and even had the pink blocks too. So this problem goes deep.