Red color offset and shadow removement problems using x265 (and x264?)

[Stupido]

Hello,

I have this really annoying problem:
After converting a video the red colors moved a little bit and reduced the amount of appearing shadows or black/dark(er) colors. It looks like the whole red'ish areas moved to upper left.

Difficult to explain, so here is a GIF of a closeup (@200%):


[Attachment 52185 - Click to enlarge]

I tested a few animation movies and got the same results. Is tried encoding using x264 and x265 using Handbrake and StaxRip, but the result is always quite similar.

Can anybody explain what and why this happens? And how can I fix that??
Hope anybody can enlighten me.


-------------
MediaInfo of the source file I used for the gif:

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High@L4.1
Format settings                : CABAC / 4 Ref Frames
Format settings, CABAC         : Yes
Format settings, Reference fra : 4 frames
Codec ID                       : V_MPEG4/ISO/AVC
Duration                       : 12 s 303 ms
Bit rate mode                  : Variable
Bit rate                       : 23.6 Mb/s
Maximum bit rate               : 30.0 Mb/s
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 23.976 (24000/1001) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 8 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 0.475
Stream size                    : 34.6 MiB (98%)
Default                        : Yes
Forced                         : No
Color range                    : Limited
Color primaries                : BT.709
Transfer characteristics       : BT.709
Matrix coefficients            : BT.709

MediaInfo of a x265 encode:

Video
ID                             : 1
Format                         : HEVC
Format/Info                    : High Efficiency Video Coding
Format profile                 : Main@L4@Main
Codec ID                       : V_MPEGH/ISO/HEVC
Duration                       : 12 s 263 ms
Bit rate                       : 3 467 kb/s
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 23.976 (23976/1000) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 8 bits
Bits/(Pixel*Frame)             : 0.070
Stream size                    : 5.07 MiB (100%)
Default                        : Yes
Forced                         : No

[jagabo]

YV12 chroma subsampling? What's your source? RGB images? How much is that GIF zoomed in?

[Stupido]

I added the media infos above - hope this helps.

The closeup used for the gif is at 200%.

[poisondeathray]

It might be your method of chroma upsampling - Your method of viewing or taking the screenshot (ie. how you are converting YUV 4:2:0 to RGB)

Post a sample of the source and encode video

[Stupido]

Okay, I think that might be the reason or at least a big part of it.
I started to compare source and encoded videos directly and their screenshot as well as their extracted frame.

Give me some time to collect the informations ....

@jagabo, @poisondeathray
Thanks to give me the clues!

[Stupido]

Okay, I've tested a few things and the current state is almost the same as before.
It seems like I made a mistake or confused myself comparing over hundred of sample videos and images, because I couldn't reproduce the issue with a x264 encode. Accidentely I deleted all my x264 encodes yesterday, so I can't keep up with my statement it also affects x264.

But back to topic:
I've worked with screenshots and extracted frames, JPEG and PNG as well as side to side comparison on different players. As far as I can tell this should be an encoder setting(?) problem with x265.

I've uploaded the source sample (4s) and encode for you:
Source (14MB)
Encode [x265@10bit] (3MB)
The scene I used for the gif should be at (around) 02s.

[poisondeathray]

There is no problem;

There is the expected quality loss along the lines, but nothing like the shifting that you demonstrate in the gif

It might be a playback setup error, maybe a decoding error, or screenshot taking error, or gif making error on your end

How are you decoding, how are you playing it back, how are you taking screenshots ?


[Attachment 52186 - Click to enlarge]

[jagabo]

I see the same thing as poisondeathray, compression artifacts but no chroma shift. You have a decoding or RGB conversion problem. Keep in mind that YV12 has a luma (greyscale) channel the size of the video (1920x1080 in this case) and chroma (color) channels that are half that size (960x540). To be viewed or saved as an image the chroma channels have to be upscaled to the same size as the luma. The differences you are seeing are there -- how the chroma is upscaled and the resulting alignment with the luma.

[Stupido]

Okay, you guys are awesome and I have a lot to learn yet!

As it turned out, the image from source is the faulty one, not the encode! This can be proven by comparing the two gifs.
I compared images of unscaled video frames and also recognized the same difference. So I changed the player and compared the frames with VLC and they were (almost) identical. I upscaled them - still no difference. Then I used WMP and got same results.

In conclusion the problem had to do something with the player I use(d): MPC-HC with madVR.
I took a look at the debug OSD and recognized only one difference, that could/should be the reason:

ENCODE «» SOURCE

[Attachment 52193 - Click to enlarge]

Playing the source there seems to be a color conversion using the GPU that causes the problem.
But after changing almost every setting, I am not able to change madVR's behaviour using my graphics card (old AMD Radeon).

MPC-HC itself should not be the problem, because when I change the video renderer to "Enhanced Video Renderer" or "System Default" there is no color offset or something I would complain.

But does it really mean I can't use madVR anymore?
Do you have a solution for me or have I learn to deal with this problem?!

[jagabo]

I don't use madVR, but look to see if there is a chroma placement option. Something like MPEG1 vs. MPEG 2.

http://web.archive.org/web/20110605074555/http://msdn.microsoft.com/en-us/library/Aa904813

[poisondeathray]

Did you try updating GPU drivers ?

In the madvr settings "trade quality for performance" did you uncheck "use DXVA chroma upscaling when doing native DXVA decoding" ? You might have to close/restart for setting to take effect

In the chroma upscaling section , did you try out a different custom pixel shader code options ?

If you disable HW acceleration , so you force CPU decoding (not DXVA2) , does it change the result ? (again , you might have to close/restart for setting to take effect) . If it does not, then something else is going on

[Gravitator]

Hello!
The top link "Encode [x265 @ 10bit] (3MB)" downloads the 8bit version.
Little to improve the situation for x265-8bit: --preset slow --crf 21.00 / --crf 22.00 --aq-mode 3 --aq-strength 3 --no-cutree (deinterlace off in the settings of your program).
> Result

[Stupido]

In the madvr settings "trade quality for performance" did you uncheck "use DXVA chroma upscaling when doing native DXVA decoding" ? You might have to close/restart for setting to take effect

WTF!!
Before I started the thread of course I tried disabling every setting on that page and restarted MPC-HC, but without any visible changes.
In order to give you actual and save answers I tried it one more time and it blowed my mind. As soon as I click on Apply after changeing "use DXVA chroma upscaling when doing native DXVA decoding" the color changes immediately! Disabling this option let it look as it should be.
Now I see no differences in both screenshots - like in your gif. I'm happy you let me check it again!

...while typing this I recognized something: I've tested all settings on the encoded video!! In my last post I mentioned my fault after looking at your images, but forgot to doublecheck all my attempts one more time with the source file. Shame on me!

At this point it can only be my videocard or the driver - something I can check by myself.

Thank you @poisondeathray and @jagabo, I really appreciate your help!

[Stupido]

@Gravitator
Thanks for your advise, but your result is about 6% bigger and a lot less accurate regarding the source. Nevertheless it was just a quick encode for the sample.