Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th April 2024, 02:56   #41  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,416
Quote:
Originally Posted by huhn View Post
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

Quote:
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

Last edited by poisondeathray; 15th April 2024 at 03:08.
poisondeathray is offline   Reply With Quote
Old 15th April 2024, 11:42   #42  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 219
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.
nji is offline   Reply With Quote
Old 15th April 2024, 12:05   #43  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,032
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.
huhn is offline   Reply With Quote
Old 15th April 2024, 12:52   #44  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,416
Quote:
Originally Posted by nji View Post

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

Last edited by poisondeathray; 15th April 2024 at 12:55.
poisondeathray is offline   Reply With Quote
Old 15th April 2024, 13:41   #45  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 219
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.

Last edited by nji; 15th April 2024 at 13:52.
nji is offline   Reply With Quote
Old 15th April 2024, 15:36   #46  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,416
Quote:
Originally Posted by nji View Post
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.

Quote:
... then it's a built-in source of wrong color changes.
To be fair, that statement is true for any type of "auto" behaviour


Quote:
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

Code:
-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
poisondeathray is offline   Reply With Quote
Old 15th April 2024, 16:39   #47  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 219
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
nji is offline   Reply With Quote
Old 15th April 2024, 23:10   #48  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,630
Good thread, many thanks for getting into that detail, poisondeathray, and the others.
I might have stumbled into that one (ffmpeg) too one day.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."
Emulgator is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:57.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.