MPC-HC v2.2.1

[poisondeathray]

Originally Posted by nji

Maybe finally anyone does the simple test, if he can reproduce:
Take an arbitrary video, say this one:
https://c.gmx.net/@11558428876409458...T7mMtrBVWAxzXQ
Export first frame by ffmpeg and by MPC-HC.
==> MPC-HC's is brighter.

Same for me, but maybe you are not using the correct commandline

There is no material difference in terms of "brightness" (even if you apply any of the dithering algos)

ffmpeg -i color-test.mp4 -vf zscale=min=709,format=gbrp -frames:v 1 -start_number 0 ffmpeg_zscale_%04d.bmp

bmp output for color-test
https://www.mediafire.com/file/nseks...scale.zip/file

[nji]

If you have to know and specify the parameters for ffmpeg always that way...
Guarantee for generating wrong frames.

Moreover - it can't be just the command line, as ADM for example
exports/ shows the same frames as "default command line".
But maybe ffmpeg API has to be called by the hosts also in the specific way respectively?
... and isn't...

[poisondeathray]

Originally Posted by nji

If you have to know and specify the parameters for ffmpeg always that way...
Guarantee for generating wrong frames.

Not necessarily ; It also depends on the source flags and ffmpeg version...

ffmpeg is constantly evolving project - sometimes stuff gets broken, then fixed or behaviour changed

There are many "gotchas" and pitfalls with ffmpeg - it's not for beginners

The PNG gAMA and cHRM that ffmpeg exports is another common problem

Moreover - it can't be just the command line, as ADM for example
exports/ shows the same frames as "default command line".
But maybe ffmpeg API has to be called by the hosts also in the specific way respectively?
... and isn't...

Not sure about avidemux, but it doesn't use ffmpeg directly, perhaps some shared libvcodec libraries

avidemux never has the correct color for me in any of the versions going back 10 years. I couldn't figure the correct combinations twiddling in the settings / open GL / QT/ DXVA . If anyone is able to get avidemux to have correct colors, please post the setup configuration

[huhn]

Originally Posted by poisondeathray

Again, integer YCbCr => float RGB => integer YCbCr is a lossless transform when done properly

This is known fact. It's easily demonstratable for any YCbCr integer .

Even 4:2:0 chroma subsampled YCbCr is lossless for the upsample/downsample because nearest neighbor is used

Deal with it

yes just ignore the chroma location yes NN the mathematical wrong scaler.
https://en.wikipedia.org/wiki/Floati...ror_mitigation

Think before your write...

You cannot display RGB float with any current display . Nor do you display YCbCr directly with any common display

You can read off RGB float values and YCbCr values in vsedit , but the actual display pixel technology is integer RGB

yes you display 8 or 10 bit
now do that in your round trip.
someone didn't think before.
because i literally wanted you to embarrass give me that answer...

Yes , and PSNR or SSIM is not a perfect test either. If you want to test another metric say the word

you didn't test anything because you don't have a reference

SMPTE bars are used everyday in professional production for studios, TV, web . It's attached to every submission for professional content providers (Netflix, Amazon, Disney, TV stations) . It's a very common test pattern. UHD / HDR /HLG variants have a different set of bars.

sure... we have never moved on from that ohh wait we have...
and not the point.
why would you not dither them that's the point.

The test shows using real 10bit YCbCr video - which has closer approximation to the perfect test signal . Of course 10bit YCbCr is already rounded compared to the perfect float signal. If you started with perfect, you wouldn't need to round anything would you? If you added dithering noise to the perfect signal, you would still get more errors

if there is no error it can not dither... how do you dither an error of zero. and why do you need the 10 bit YCbCr? i wonder...
just like something is lossy.

You can show this in vapoursynth for either limited or full RGB, or any integer YCbCr value

you just like to ignore that they literally disagree don't you?



It has nothing to do about "wanting" . It has to do with using real video values, with real encoding[/QUOTE]
my point is they are inaccurate.
you know you can encode a dithered image.
well i can...

Originally Posted by poisondeathray

import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(width=1920, height=1080, format=vs.YUV444P10, color=[204,435,848])

clip3 = core.resize.Point(clip, format=vs.RGBS, matrix_in_s="709") #RGB [0.750367, 0.000368908, 0.000351697]
clip3 = core.resize.Point(clip3, format=vs.YUV444P10, matrix_s="709") #YCbCr [204,435,848]

clip3.set_output()

This one is an "easy" YCbCr value because there is no negative RGB produced or values >1 . ie. it's not a YCbCr value that produces out of gamut RGB. This means you don't even need float RGB for a round trip . 16Bit RGB should be "enough" for the lossless round trip.

There are millions of YCbCr values that "map" to out of gamut RGB values - those require RGB float for the lossless roundtrip

ohh 16 is enough i see i see.
well i give you 8 because most of these renderer can't render at more. i guess you simply didn't know that.
not that your round trip ever matter.
for some reasons you really care for illegal colors... a renderer obviously can't show.

and that's why it is basic knowledge that YCbCr -> RGB is lossy in the video renderer realm. why do i have to say this out loud...

Originally Posted by poisondeathray

It's not either / or - you need to perform all the tests including without dithering

Dithering adds another layer of complexity , randomness and inconsistency between programs. The discussion was about program A vs. B vs. C . If you one uses one variant of floyd-steinberg, but another uses another variant such as ordered, or perhaps a different seed, or program D does not dither - you're going to have more problems figuring out where the problem is .

You need to examine all processes in the pipeline, look for upstream problems as well, flag mishandling, wrong matrix etc... I already mentioned this for vdub2 - flag vs. no flag exact same video results in very different results because Rec601 is used by default




Yes of course, normal viewing vs. diagnosis

you are just ignoring your statement that dithering makes an image inaccurate...

Originally Posted by poisondeathray

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

so 191 0 1 is more accurate then 191.34 0.04 0.62 dithered over the entire image.
and the best part sampte say it should be 191 0 0.
what a grand and intoxicating innocents.
it's just like YCbCr -> RGB is lossy when it is actually used to look at it in you know a video renderer.

BTW. because for some reasons you really don't get it.
MPC-HC can not change any color inaccurate in renderer they are all up stream it just loads them. EVR everything is in the hand of the GPU driver and the rest is 3rd party.
this is like complaining to a post worker that the weather is bad.

[poisondeathray]

Originally Posted by huhn

yes just ignore the chroma location yes NN the mathematical wrong scaler.
https://en.wikipedia.org/wiki/Floati...ror_mitigation

Sure but, you can demonstrate the round trip 8 or 10 but integer YCbCr => RGB float =>same integer YCbCr is lossless , when done properly

yes you display 8 or 10 bit
now do that in your round trip.
someone didn't think before.
because i literally wanted you to embarrass give me that answer...

The round trip returns the original YCbCr values . You have the same video. Bit identical. It's lossless. So when you display that, it's the same as the original

To do the round trip properly you must use RGB float for the intermediate step e.g. a vapoursynth script. A regular player setup will clip values for the YCbCr => RGB intermediate step

why do you need the 10 bit YCbCr? i wonder...

The reason for choosing 10bit is you need +2 bits YCbCr to produce the perfect expected (rounded) 8bit RGB values - I was following up with nji with the colorbars

my point is they are inaccurate.

Yes, 8 or 10bit YCbCr are inaccurate compared to the perfect float signal .

ohh 16 is enough i see i see.

For that specific YCbCr value, 16bit happens to be enough. For millions of other YCbCr values, it is not

well i give you 8 because most of these renderer can't render at more. i guess you simply didn't know that.

Yes I was the one that pointed that out to you earlier

not that your round trip ever matter.
for some reasons you really care for illegal colors... a renderer obviously can't show.

=> This part of discussion with the round trip all started with your statement:

Originally Posted by huhn

a YCbCr -> RGB conversation is lossy in nature even at 32 bit per component.

YCbCr => RGB => YCbCr an be lossless, when the RGB step is done properly at 32bit float

and that's why it is basic knowledge that YCbCr -> RGB is lossy in the video renderer realm. why do i have to say this out loud...

Yes that's correct..."in the renderer realm". Because the renderer isn't working in 32 bit float RGB

I wrote integer YCbCr => float RGB => integer YCbCr is lossless when done properly. Do you see the difference ?

you are just ignoring your statement that dithering makes an image inaccurate...

Not at all - The values are mathematically less accurate when dithered on patterns such as bars - that was demonstrated that above using metrics - rounding has less error than several type of dithering when compared to the float signal

The point about disabling dithering for diagnosis/analysis is about comparing to different programs, some using different dithering algorithms or not. You need to compare "apples to apples". If you have some random seed producing different results, it's going to mess up the analysis .

You need to perform multiple tests to determine the underlying problem. Not just 1 test with dithering. There can be many reasons for an observation. eg. It looks to me here this was user error for nji

so 191 0 1 is more accurate then 191.34 0.04 0.62 dithered over the entire image.

Again it depends ...

Originally Posted by poisondeathray

The question boils down to: Is dithering more accurate than rounding ? - It depends on how you are measuring it, and how you are defining "accuracy". On standard bars dithering is worse by metrics

and the best part sampte say it should be 191 0 0.

That's the expected value rounded. And that's what you expect for all programs rounding. Consistent behaviour vs. inconsistent behaviour. You need consistency for analysis and repeatable results .

[poisondeathray]

Originally Posted by huhn

why do you need the 10 bit YCbCr? i wonder...
.
.
.

so 191 0 1 is more accurate then 191.34 0.04 0.62 dithered over the entire image.

Ahh I glossed over this and missed it - 192,0,1 , not 191,0,0 - ie. you're referring to the 8bit case. I see what you're getting at...

Same methodology comparing to float signal

8bit "75% red" YCbCr[51,109,212]
PSNR 32bit (0-100 scale)

no dither
r 50.629359
g 100
b 48.130803

ordered dither
r 54.435493
g 71.785649
b 52.805518

and the best part sampte say it should be 191 0 0.

To clarify - that is the expected rounded value for 10bit YCbCr [204,435,848] to 8bit RGB . Not 8bit YCbCr to 8bit RGB

[nji]

If I get it right, the question about dithering etc. is independent
from the one I originally raised (potentially brightening by MPC).
As my effects are much larger than the ones discussed above..

A short sum-up.

@poisondeathray confirms my observation at his configuration.
==> Either MPC or ffmpeg is wrong.

What does it mean that ffmpeg produces this overall different
and especilly green-brighter frames with unflagged videos?
Is this another bug of ffmpeg?
https://forum.doom9.org/showthread.p...26#post2000426

To my opinion it is important to come to a conclusion to
have consequences. If not, everything is blown in the wind.

For me it seems unacceptable ffmpeg has to be fed carefully
by stream information externally to produce a correct output.
Identifying the streams in detail and correctly should be
its origin ability.

The central question:

Is ffmpeg doing wrong?
If yes - there should be filed an issue.

[huhn]

without metadata you have to guess.
and a guess will never ever be 100 % correct. it is still a guess.

so it can do "better" guessing by seeing ohh 720p that not a DVD that's a bd resolution so bt 601 or the many other dvd colorpspace thingies are unlikely let's take bt 709. not worth to do to break older scripts that rely on the old guessing.

it can still be bt 601 anyway or what ever ycocg anyone?
the solution is tell it what it is.

[poisondeathray]

Originally Posted by nji

What does it mean that ffmpeg produces this overall different
and especilly green-brighter frames with unflagged videos?
Is this another bug of ffmpeg?
https://forum.doom9.org/showthread.p...26#post2000426

To my opinion it is important to come to a conclusion to
have consequences. If not, everything is blown in the wind.

For me it seems unacceptable ffmpeg has to be fed carefully
by stream information externally to produce a correct output.
Identifying the streams in detail and correctly should be
its origin ability.

The central question:

Is ffmpeg doing wrong?
If yes - there should be filed an issue.

The explanation is wrong matrix is used . It's similar to the behaviour I mentioned earlier with vdub2 with Rec601 . If no flags (or unknown), then assume Rec601.

But.... by convention, HD video uses Rec709 , SD video uses Rec601. So you can see that will be a problem in actual usage for unflagged videos... and there are many unflagged in the wild .

Some video players use an additional level of logic - if height > 576 then use Rec709 for the RGB conversion

It's not considered a bug, and this one has been reported dozens of times

The other problem is wrongly flagged videos - it happens a lot more than you think. Another can of worms

[nji]

Your explanation seems very plausible to me.

If it should be right
(with my very limited knowledge and experience I can't assess,
but as we're in a forum maybe there will be other posts on this).
... so IF that should be right..

... then it's a built-in source of wrong color changes.

It's not me having a solution for it.

Still I wonder if a wrong/ missing flagging actually explains the (2,2,2) at my movie?
It is a 720p flagged BT.709, limited range. The orig movie is from 1989.

[poisondeathray]

Originally Posted by nji

Your explanation seems very plausible to me.

If it should be right
(with my very limited knowledge and experience I can't assess,
but as we're in a forum maybe there will be other posts on this).
... so IF that should be right..

You can learn to test it - you can control each parameter of the YCbCr<=>RGB conversions in avisynth or vapoursynth for example to diagnose the issue.

... then it's a built-in source of wrong color changes.

To be fair, that statement is true for any type of "auto" behaviour

It's not me having a solution for it.

Still I wonder if a wrong/ missing flagging actually explains the (2,2,2) at my movie?
It is a 720p flagged BT.709, limited range. The orig movie is from 1989.

Were you referring to color-test.mp4 ? Using default settings ?

Your video is flagged, you can see in mediainfo for example
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

The default ffmpeg scaler responsible for the YUV=>RGB conversion is swscale. The important flags for swscale higher accuracy are

-sws_flags accurate_rnd+full_chroma_int

If the input file is not in planar pixel format - e.g. if it was interleaved such as YUY2 , then full_chroma_inp is also needed otherwise the chroma is downsampled before conversion

Why isn't this the "default" setting ? I don't know . I'm guessing probably a speed / performance tradeoff

I think most regular ffmpeg users prefer zscale these days. It's faster, more accurate, fewer problems with cases .

Why is swscale still the default ? Not sure, legacy, nostalgia - It's the one that everyone complains about and historically had many errors and problems

[nji]

I checked and... 100% approvement!

With the flags of swscale you mentioned the (2,2,2) difference is gone.

I can't tell if "most regular ffmpeg user prefer zscale" as you said.

I would have thought that most typical (occational) ffmpeg users like me
never even heard about that, and use the default config.
Trusting that ffmpeg does the right thing.
The way it is now unwanted changing spread more and more.

To my opinion worth an issue in ffmpeg.
But you said it isn't taken as bug.

Call me naive, but I'm kind of disgusted by that situation.

And grateful to you

[Emulgator]

Good thread, many thanks for getting into that detail, poisondeathray, and the others.
I might have stumbled into that one (ffmpeg) too one day.

[varekai]

Yep, I agree, a very good read, except for the arrogant and totally useless words from the developer.