Possible color/brightness bug in MPC-HC

[nji]

Recently I noticed a slightly different presentation of videos
compared to VirtualDub2 (VD2), Avidemux (ADM) and ffmpeg.

I tried to trace it down systematically, starting with simple notes.
Doing that, realisation slowly dawns that it is complex - the tools
for examination themselves can't be relied on.
Second I built a table... and finally ended with a graph with arbitrary
transitions between codec formats etc.

It turns out that
ADM and ffmpeg nearly always do identical.
MPC-HC was always too bright (viewing and screenshot, with all renderers):
about the same value (2,2,2).
VD2 (4 y/o) was inbetween.

MPC-HC 2.1.5 @ Win7-64 SP1

[clsid]

The bug isn't in the player.

I can not help you and I do not care.

[Sunspark]

You can say this in a different way, "I can not help you because it's upstream".

[nji]

@Sunspark: Thank you for translating.

May I ask you then, how this is meant, "not in the player but upstream"?

I understand it this way:
There are inputs to a program.
These inputs are done all about the same with other programs,
but not with the first one.

In this situation there is an indication the first program does something wrong, I might think. (?)

So I really don't understand why "not in the program, but upstream".
Now I'm really curious.

[huhn]

because it doesn't do anything of this.
decoding is done by ffmpeg and video renderer is done by the video renderer.

all video renderer are supposed to be to bright what does that even mean?

[Emulgator]

nji: Video Renderer -> Ausgabebereich 0-255

[nji]

Woops - beats me!

Some times ago I had a single brainwave on that (vanished instantely).
But (of course) I tested on several movies.
Is this only on "restricted type"...

But what does it mean concrete?

In practise MPC-HC shows the videos systematically brighter than all other tested apps.
This won't be just for me I might think...?

Can you drop some more thoughts on that please,
so I know where to look at?

And: Thank you!

EDIT:
It can't be just an (inconsistent) using of linear mapping unrestricted [0,255] to restricted [16,255],
as this wouldn't cause average +2, but +8...

[huhn]

it's 16-235 or 0-255.
this is 36 level and the max deference in this case is 20 with a minimum of 0.

now you want other to compare that to "all other tested apps" what ever that means? so let have a look:
VirtualDub2 (VD2), Avidemux (ADM) and ffmpeg.

none of these is a video player...

so i got vurtualdub2 load a file and no i doesn't care about colorspace HDR or what ever. so i got a different image...
bt 709 and still got a different image.
so i took bt 601 source and the result was the "same" ~90%...
knowing that 50% of all data is upscaled with a different chroma scaler i take that as the same.

so my current conclusion here is that virtualdub2 just uses one ycbcr to RGB formula for everything. and my best guess is 601 to RGB 709 full range.

there is nothing to look at anymore with the case of virtualdub2 it is not made to show something correctly because it is not a video player.

[nji]

Thank you very much for your valuable information.

As I'm not too deep into the media material, I wasn't aware about the details
(Exact values of restricted interval and bt-types...).

What I am aware of course is that ADM, VD2 are video editors in first place.
And ffmpeg... is about everything
But it shouldn't make any difference if you're watching or "watching by editing"
a video, when it is about different colors, don't you agree?

All should be (about) the same, when working correctly.
And a difference of about (2,2,2) is well perceivable, when you have a close look.
It matters.

I cannot assess the insides, but maybe VD2 isn't the best example to compare against.
Sadly it isn't developed anymore, since 4 years. To my experience with VD2 it is
well possible that it doesn't do right. ADM is more reliable, to my experience.

ADM and ffmpeg produce both about the same results (viewing, playing, screenshot,
you name it). Moreover the difference to MPC-HC is the largest - see my first post.
And ffmpeg might be about the reference.
It seems very unlikely it shouldn't handle video types correct.

I'm grateful for your help on that.
But I can't agree with your conclusion.
"There is something wrotten in the state of Denmark",
and the more complex situation because of bt-types and restricted intervals
by no means can justify the differences.

I don't want to blame anything/ anyone.
I'm just about to try generating correct results.
All is meant constructive.

[clsid]

VD2 and ADM both use FFmpeg...
And FFmpeg swscale is well known for its crappy quality colorspace conversion...

So you are actually comparing ONE against multiple renderers made by different people...

[nji]

Originally Posted by clsid

VD2 and ADM both use FFmpeg...
And FFmpeg swscale is well known for its crappy quality colorspace conversion...

This is all new to me.

If this should be true... we have a horrible situation:

Many videos are treated by VD2, ADM and ffmpeg.
A source of worsening movies.

It's hard to believe that everybody accepts that.

[huhn]

Originally Posted by nji

What I am aware of course is that ADM, VD2 are video editors in first place.
And ffmpeg... is about everything
But it shouldn't make any difference if you're watching or "watching by editing"
a video, when it is about different colors, don't you agree?

no there is farm ore to this then this and for a video editor this doesn't have to be an issue it. it can be an issue.

All should be (about) the same, when working correctly.
And a difference of about (2,2,2) is well perceivable, when you have a close look.
It matters.

if you have an option to define the state of your display and the source has proper information yes else no impossible.

I cannot assess the insides, but maybe VD2 isn't the best example to compare against.
Sadly it isn't developed anymore, since 4 years. To my experience with VD2 it is
well possible that it doesn't do right. ADM is more reliable, to my experience.

because the preview is wrong doesn't mean the encode is.
if you use a bad conversation but at the end use the same inverse conversation you still have the "same" image.

ADM and ffmpeg produce both about the same results (viewing, playing, screenshot,
you name it). Moreover the difference to MPC-HC is the largest - see my first post.
And ffmpeg might be about the reference.
It seems very unlikely it shouldn't handle video types correct.

that's not even funny.

I'm grateful for your help on that.
But I can't agree with your conclusion.
"There is something wrotten in the state of Denmark",
and the more complex situation because of bt-types and restricted intervals
by no means can justify the differences.

madVR has been verified by calibrator and by people that write calibrator software. so yes that's pretty accurate.

I don't want to blame anything/ anyone.
I'm just about to try generating correct results.
All is meant constructive.

then why are you comparing a video editor with a video player?

the fat that multiply renderer according to you have the same output should tell you a lot.

[poisondeathray]

How do you know which one is "correct" ?

Use a known reference video, such as SMPTE bars . You have known YCbCr and their expected RGB values , so you can diagnose which of your software are not setup correctly .

MPCHC produces correct values for me. If you're not getting the correct expected values, there is something wrong with your setup - hardware, or configuration settings .

VDub2 uses Rec601 for the RGB conversion by default, unless input video colorimetry matrix is flagged => therefore it can be wrong .

Avidemux always produces the incorrect values. I've never seen it produce correct values.

ffmpeg can be correct if you use the correct flags . SWScale has improved and is fine for most standard conversions, with a few exceptions. But ZScale (zimg) is usually the better choice . If you don't use correct flags, obviously you get the wrong results .

[huhn]

it's called a colorimeter. that how you know.

You have known YCbCr and their expected RGB values

that's not a given sadly too.
you need to know the corresponding RGB values (which are dithered BTW. so good luck with that) for your target display colorspace.

madVR has an error of 0.3 level or something in relative % between limited and full range this ignores errors from linear light dithering stuff that's to high for me

[poisondeathray]

Originally Posted by huhn

you need to know the corresponding RGB values (which are dithered BTW. so good luck with that) for your target display colorspace.

If you are using madVR, you can set the dithering options to none in the settings

[huhn]

which would be even more inaccurate.

[poisondeathray]

Originally Posted by huhn

which would be even more inaccurate.

Dithering is less accurate for diagnostic tests on patterns such as color bars

[huhn]

and how do you put a combination of 219(220) level of luma on 255(256) level and how do you put 224(225) level of chroma on 255(256) levels at the same time without dithering?

as an example a bad IRE 30 file is a mix of 75 and 76 or 75.68 if it isn't dithered it is just 76 which is a massively bigger error.

[Alexkral]

Maybe just using integer values in the test patterns that with the conversion formulas should produce integer values (or very close to integer)?

[huhn]

that's why we dither they will not produce integer and not close to it too.