Media Player Classic - BE Win32/x64

[mkver]

I think there are some bugs regarding Matroska's cropping feature. This zip archive (https://www.dropbox.com/s/kbg7tnfzn04ri92/Crop.Test.zip?dl=0) contains some samples for the issues I am talking about.

1. I think you implemented the default value of the DisplayWidth and DisplayHeight elements incorrectly: It is PixelWidth - PixelCropLeft - PixelCropRight for DisplayWidth and similar for the height if DisplayUnit has the value 0 (which is its default value; DisplayWidth and DisplayHeight have no default value when DisplayUnit has a different value).
a) The files "Crop.Test.Explicit.Container.Aspect.Ratio.mkv" and "Crop.Test.No.Explicit.Container.Aspect.Ratio.mkv" both contain an H.264 track with pixel dimensions 1280x720 with black bars at the top and bottom of 80 pixels height each; they also contain a white square at the center so that one can easily test whether the player uses the proper aspect ratio. Both files have cropping parameters indicating that the black bars of 80 pixels should be cropped away. "Crop.Test.Explicit.Container.Aspect.Ratio.mkv" explicitly contains DisplayWidth (set to 1280) and DisplayHeight (set to 560), indicating that quadratic pixels should be used. "Crop.Test.No.Explicit.Container.Aspect.Ratio.mkv" differs from aforementioned file in that it doesn't contain explicit DisplayWidth and DisplayHeight values; therefore the default value just described must be used and this results in the same values derived for DisplayWidth and DisplayHeight.
But that's not how MPC-BE does it: "Crop.Test.Explicit.Container.Aspect.Ratio.mkv" is displayed correctly, but "Crop.Test.No.Explicit.Container.Aspect.Ratio.mkv" isn't. The bars are cropped, but what is left after cropping is displayed as 16:9 and not as 16:7 as it should be. (In the VIDEOINFOHEADER2, dwPictAspectRatioX is 16 and dwPictAspectRatioY is 9; for the first file, dwPictAspectRatioY is 7.)

b) If you now think that I do this just to save a few bytes from the DisplayWidth and DisplayHeight elements: No, that is not my rationale. It is actually different. It is part of an effort to make these files compatible with players that honour the Matroska cropping parameters and players like MPC-HC (and others that use LAV) that don't ("compatible" means that the the players will play the movie with the right pixel aspect ratio although the latter players will include the black bars). If one plays "Crop.Test.Explicit.Container.Aspect.Ratio.mkv" with MPC-HC, the black bars aren't cropped away and the display aspect ratio is 16:7 (i.e. the pixels are too wide and there is no square in the middle). But "Crop.Test.No.Explicit.Container.Aspect.Ratio.mkv" is played with the correct unanamorphic square pixels (LAV does not only not crop, but it also doesn't use the cropping values for the calculation of the inferred values of DisplayWidth and DisplayHeight. By leaving out these two values one can crop non-anamorphic content and it will work on both kinds of players. Given that players that don't honour the cropping flags seem to be the majority, it is important to create files that work for both. (This would be much easier if Matroska would allowed the usage of pixel aspect ratio to determine the aspect ratio.)

c) Should the video track be anamorphic, one can't directly use the strategy above. But a slightly altered one can still be employed if one only wants to crop either vertically or horizontally, but not both:
"Crop.Test.Anamorphic.Explicit.Container.Aspect.Ratio.mkv" and "Crop.Test.Anamorphic.DisplayHeight.missing.mkv" both contain a video with 640x720 encoded pixels. In the middle is a white rectangle with dimensions 60x120. If viewed with a pixel aspect ratio of 2:1 this becomes a movie with a white square in the middle. At the top and bottom there are black bars of 80 pixels height each; accordingly, both files contain PixelCropTop and PixelCropBottom elements indicating that 80 pixels should be cropped from the top resp. the bottom each. "Crop.Test.Anamorphic.Explicit.Container.Aspect.Ratio.mkv" furthermore contains a DisplayWidth element of 1280 and a DisplayHeight element of 560 (so that the pixel aspect ratio is 2:1 and the white rectangle should be a square). "Crop.Test.Anamorphic.DisplayHeight.missing.mkv" meanwhile contains only a DisplayWidth element of 1280; it's DisplayHeight element is therefore inferred to be 720-80-80=560 according to the specs and for a player that does not honour the crop parameters, it is simply 720. For both kinds of players, the pixel aspect ratio should be 2:1 and the white rectangle a square.
But not for MPC-BE. This seems to be the same underlying bug: The wrong default value of DisplayHeight is inferred. This sample is only here to show that there are situations in which it makes sense to leave only one of the two Display* values out.

2. And there is another bug. All files above have their pixel aspect ratio explictly set in the SPS (i.e. the anamorphic files have a 2:1 ratio there, the ones with the square pixels have 1:1 set). If I set the internal video decoders to use the aspect ratio from the stream and play any of these files, the aspect ratio is always 16:9 (as it should be according to the stream layer), but the black bars on top and bottom are still being cropped away so that the non-black-bar area that should have an aspect ratio of 16:7 is stretched to 16:9.

PS: Thanks to all developers for this great player!

[Aleksoid1978]

My English is not good, for me is difficult to understand so many letters :)

About cropping in Matroska everything is simple:

RECT rect = {VideoPixelCropLeft,
VideoPixelCropTop,
PixelWidth - VideoPixelCropRight),
PixelHeight - VideoPixelCropBottom)};

VIDEOINFOHEADER *vih = (VIDEOINFOHEADER*)item.Format();
vih->rcSource = vih->rcTarget = rect;

VideoPixelCropLeft - 0x54CC
VideoPixelCropTop - 0x54BB
VideoPixelCropRight - 0x54DD
VideoPixelCropBottom - 0x54AA

PixelWidth - 0xB0
PixelHeight - 0xBA

[mkver]

This is the correct rectangle to keep (the rest should be ignored/cropped away) and this part is correct. What is not correct is the aspect ratio of the output in case that one of the DisplayWidth/DisplayHeight elements is missing. In this case its default value applies but it seems that MPC-BE uses DisplayWidth=PixelWidth instead of DisplayWidth=PixelWidth - VideoPixelCropLeft -VideoPixelCropRight for the default value (the same goes for height, of course).

And thanks for answering so fast. MPC-BE's support is really impressive.

[Aleksoid1978]

mkver
Try test build - https://yadi.sk/d/b7MbRxAbxVCTqQ

[mkver]

I think I have found where the problem lies. I searched in the code for MPC-BE 1.5.0, but I don't think that file has changed. It is MatroskaFile.cpp:

case 0xB0:
PixelWidth.Parse(pMN);
if (!DisplayWidth) {
DisplayWidth.Set(PixelWidth);
}
break;
case 0xBA:
PixelHeight.Parse(pMN);
if (!DisplayHeight) {
DisplayHeight.Set(PixelHeight);
}
break;
case 0x54B0:
DisplayWidth.Parse(pMN);
break;
case 0x54BA:
DisplayHeight.Parse(pMN);
break;
case 0x54B2:
DisplayUnit.Parse(pMN);
break;
case 0x54B3:
AspectRatioType.Parse(pMN);
break;
case 0x54AA:
VideoPixelCropBottom.Parse(pMN);
if ((INT64)VideoPixelCropBottom < 0) VideoPixelCropBottom.Set(0); // fix bad value
break;
case 0x54BB:
VideoPixelCropTop.Parse(pMN);
if ((INT64)VideoPixelCropTop < 0) VideoPixelCropTop.Set(0); // fix bad value
break;
case 0x54CC:
VideoPixelCropLeft.Parse(pMN);
if ((INT64)VideoPixelCropLeft < 0) VideoPixelCropLeft.Set(0); // fix bad value
break;
case 0x54DD:
VideoPixelCropRight.Parse(pMN);
if ((INT64)VideoPixelCropRight < 0) VideoPixelCropRight.Set(0); // fix bad value
break;

As one can see, during parsing of the PixelWidth/PixelHeight elements the corresponding DisplayWidth/DisplayHeight values get set if they have not already been set. And the default value that they are set to does not include the VideoPixelCrop* values. Now one might think that one should simply correct the default value to e.g. DisplayHeight.Set(PixelHeight - VideoPixelCropBottom - VideoPixelCropTop). While this would improve matters for those files for which the Crop values are parsed before the PixelWidth/PixelHeight values, the other files are not fixed by this. A real solution is possible by deferring the decision whether to use the default value or not until later. I don't know if this is valid C++ (I hope so), but this is what I have in mind:

HRESULT Video::Parse(CMatroskaNode* pMN0)
{
BeginChunk
case 0x9A:
FlagInterlaced.Parse(pMN);
break;
case 0x53B8:
StereoMode.Parse(pMN);
break;
case 0xB0:
PixelWidth.Parse(pMN);
break;
case 0xBA:
PixelHeight.Parse(pMN);
break;
case 0x54B0:
DisplayWidth.Parse(pMN);
break;
case 0x54BA:
DisplayHeight.Parse(pMN);
break;
case 0x54B2:
DisplayUnit.Parse(pMN);
break;
case 0x54B3:
AspectRatioType.Parse(pMN);
break;
case 0x54AA:
VideoPixelCropBottom.Parse(pMN);
if ((INT64)VideoPixelCropBottom < 0) VideoPixelCropBottom.Set(0); // fix bad value
break;
case 0x54BB:
VideoPixelCropTop.Parse(pMN);
if ((INT64)VideoPixelCropTop < 0) VideoPixelCropTop.Set(0); // fix bad value
break;
case 0x54CC:
VideoPixelCropLeft.Parse(pMN);
if ((INT64)VideoPixelCropLeft < 0) VideoPixelCropLeft.Set(0); // fix bad value
break;
case 0x54DD:
VideoPixelCropRight.Parse(pMN);
if ((INT64)VideoPixelCropRight < 0) VideoPixelCropRight.Set(0); // fix bad value
break;
case 0x2EB524:
ColourSpace.Parse(pMN);
break;
case 0x2FB523:
GammaValue.Parse(pMN);
break;
case 0x2383E3:
FramePerSec.Parse(pMN);
break;
case 0x55B0:
VideoColorInformation.Parse(pMN);
break;
}
}
while (pMN->Next());

if (VideoPixelCropLeft + VideoPixelCropRight >= PixelWidth) {
VideoPixelCropLeft.Set(0);
VideoPixelCropRight.Set(0);
}

if (VideoPixelCropTop + VideoPixelCropBottom >= PixelHeight) {
VideoPixelCropTop.Set(0);
VideoPixelCropBottom.Set(0);
}

if (DisplayUnit && !(DisplayWidth && DisplayHeight)) {
DisplayWidth.Set(0);
DisplayHeight.Set(0);
DisplayUnit.Set(0);
}

if (!DisplayWidth) {
DisplayWidth.Set(PixelWidth - VideoPixelCropLeft - VideoPixelCropRight);
}

if (!DisplayHeight) {
DisplayHeight.Set(PixelHeight - VideoPixelCropTop - VideoPixelCropBottom);
}

return S_OK;
}

[mkver]

Thanks for your efforts. I just tested your build and the non-anamorphic videos look right; but the anamorphic videos (all anamorphic Matroska videos, not just the two samples I have uploaded) are now presented as if the pixels were quadratic.

PS: What I posted is only intended as a fix for the first bug I reported, not the second one.

[Aleksoid1978]

mkver
Second test build - https://yadi.sk/d/ZFQwkJCj__kdpw

[mkver]

Now ordinary anamorphic Matroska videos (those that explicitly contain the display dimension elements) are presented correctly, but if one of the two display dimensions is missing, it's back to square pixels again.
Could you check whether my suggestion does compile? If so, I'd like to test it.

[Aleksoid1978]

If one of the two display dimensions is missing - i use:

DisplayWidth.Set(PixelWidth - VideoPixelCropLeft - VideoPixelCropRight);
DisplayHeight.Set(PixelHeight - VideoPixelCropTop - VideoPixelCropBottom);

for both display dimensions.

I think - if width or height is missing - both display dimensions is invalid and rewrite from Pixel + Crop dimension.

[mkver]

If a parent/master element B can contain an element A that has a default value, then if B (or rather: an instance of B) exists and doesn't contain (an instance of) A, then it is assumed that a child element A that has the default value exists as a child of B. If DisplayUnit is 0, then DisplayWidth and DisplayHeight have default values, so that this applies. So in this case, DisplayWidth and DisplayHeight is always set -- either explicitly because the element is written in the file or implicitly because of the default value. It doesn't matter which of these elements is choosen. If DisplayUnit is 0, then actually DisplayWidth and DisplayHeight can never be missing because they are assumed (they are assumed to have their default value). In particular, if one of these two values doesn't explicitly exist in the file, it doesn't mean that the display dimensions are invalid. The value that really exists in the file mustn't be discarded and overwritten just because the other one doesn't explicitly exist in the file. The value that doesn't explicitly exists must of course be set to its default value.

The situation changes if DisplayUnit is not 0. Then there is no default value, so that the display dimensions are only valid if both components are >0. If one of them is =0 or missing, both are invalid and a sensible choice is to act as if both DisplayUnit as well as DisplayWidth and DisplayHeight were set to their default values. My code above does this:

if (DisplayUnit && !(DisplayWidth && DisplayHeight)) {
DisplayWidth.Set(0);
DisplayHeight.Set(0);
DisplayUnit.Set(0);
}

if (!DisplayWidth) {
DisplayWidth.Set(PixelWidth - VideoPixelCropLeft - VideoPixelCropRight);
}

if (!DisplayHeight) {
DisplayHeight.Set(PixelHeight - VideoPixelCropTop - VideoPixelCropBottom);
}


Thanks for investing so much time in this.

[Aleksoid1978]

mkver
New test build - https://yadi.sk/d/aLkiOjvFW7UuxQ
I individually check display dimensions.

[mkver]

Very good! Works as expected. You also added safeguards against the case VideoPixelCropLeft + VideoPixelCropRight >= PixelWidth, but you didn't really seem to care about DisplayUnit. Am I right?

Thanks a lot.

[Aleksoid1978]

I check DisplayUnit.

[mkver]

Really? Here (https://www.dropbox.com/s/fpqny6jnvo6gfuz/Anamorphic.DisplayHeight.missing.DisplayUnit.2.mkv?dl=0) is a file with pixel dimensions 640x720 with 80 pixels black bars on top and bottom. Of course there are corresponding VideoCrop* elements. The DisplayWidth is 1280 and the DisplayUnit is 2; DisplayHeight does not explicitly exist. Because DisplayUnit 2, no default value for DisplayHeight exists and hence no value at all exists for DisplayHeights. In other words, the display dimensions are invalid. What I would have expected (and what my code would have done) is act as if DisplayUnit was 0 and as if the display dimensions coincided with the default display dimensions (for DisplayUnit) which would have resulted in 640x560 output. But the new build instead crops the video as usual and uses an display aspect ratio of 16:7 just as if DisplayUnit were 0.

[Klaus1189]

I updated to Win10 1809 x64 (fresh install) and MPC-BE is working just fine :)

[Aleksoid1978]

I updated to Win10 1809 x64 (fresh install) and MPC-BE is working just fine :)

I know :)

[Grimsdyke]

@ Klaus1189 - one cosmetic thing.
When you have the time can you check the German text under 'Audio Processing' ? The 'Surround level' is shifted to the right by two letters - so the end bracket and the asterisk is cut off by the slider.
When displayed in Englisch it is just the other way around !! The 'Center Level' is shifted to the right so that both lines end vertically at the same point before the sliders.

[Klaus1189]

Thank you for the info Grimsdyke. I never adjusted the sliders. In latest translation file revs of german and english, I copied the strings:
"Center level (%+.1f dB)"
"Center Pegel (%+.1f dB)"
"Surround level (%+.1f dB)"
"Surround Pegel (%+.1f dB)"

But the jump to the right of Sourround Pegel which causes the cut off, is very strange.
I use 200% scaling of my desktop and used r4017 Nightly when I made the video with my Camcorder. Here you can see the jump:
1.) german translation jump to the right: https://drive.google.com/file/d/1OhUXkgfCGYof1DlToPg_Za7oKF7hHnBr/view?usp=sharing
2.) english translation looks fine to me with 200%: https://drive.google.com/file/d/14L0iRCQ-okPKzedsnx3XsiEFzyc1V-YM/view?usp=sharing

@devs please help me, since the german string is "longer" depends on font which is not a Monospaced font, I think the sliders must be moved a bit to the right, is it?

[steakhutzeee]

Hello, i have three questions:

1- Before i used to download the nightly builds and in mpc the release resulted as Beta. I asked here and it was ok this way. I was on the .3968 that's the latest on yandex. Now i downloaded the beta .3973 from videohelp.
Now, something changed in the nomenclature? I mean, i did it right going from the nightly .3968 to the beta .3973, or i have screwed up my installation? As i can see latest nightly now is the .4016, but maybe as said is the nomenclature that's changed. Or maybe i'm having big confusion.

2- As stated before, as i can see if i change 'styles' on the fly for subs, this works correctly.

If i tweak the 'predefined style' and then select it so i use it for all the videos, i see that the subs is not loaded correctly, i mean, the tags are ignored, like italic etc.

Why this? can i solve?

3- Could be possible to have more information on how the Audio Boost works? Level i think is the "volume" i want, but what is Release time?

Hope it's clear, my first question is a little complex, tried to be much clear as possible.

Thanks for your time! :)

[ryrynz]

Beta is just a label put on a particular build. Personally I'd recommend using the nightlies if you're okay with the odd bug but then some bugs are fixed over the beta anyway.

[steakhutzeee]

Beta is just a label put on a particular build. Personally I'd recommend using the nightlies if you're okay with the odd bug but then some bugs are fixed over the beta anyway.

Good! Updated just now to the lates nightly, the .4018, that appear as Beta in the info inside mpc-be.
Hope this is the right way to do it, simply install over my previous installation, stable or beta.

Any idea about the other two questions?

Thanks!

[Klaus1189]

2- As stated before, as i can see if i change 'styles' on the fly for subs, this works correctly.

If i tweak the 'predefined style' and then select it so i use it for all the videos, i see that the subs is not loaded correctly, i mean, the tags are ignored, like italic etc.

Why this? can i solve?

Seems like it is fixed in r3986 according to commit browser:
Menu Subtitles->Advanced->Styles.. doesn't work. I use build 3984. Regards.

Confirm - thank you.

P.S. Fixed.

Try again with installed nightly build r4018 ;)

[steakhutzeee]

Seems like it is fixed in r3986 according to commit browser:




Try again with installed nightly build r4018 ;)

Tried just now, it does not work. I use Subtitles>Advanced>predefined style.

The subs are normal, and don't look if a string is italic etc.

If i change on the fly the setting and don't use the predefined but just the style options, italic works fine.

This can be easly reproduced if u want to try.

[Klaus1189]

Hmm, for me it works, upload a sample so I can test that also.

[steakhutzeee]

Hmm, for me it works, upload a sample so I can test that also.

Here is my settings, if i uncheck the predefined style, it works.
This way it does not.

https://i.postimg.cc/yWykvSnw/subs.jpg (https://postimg.cc/yWykvSnw)

Uploaded sample sub as .txt, just need to rename it back to .srt.

Here is my configuration for the predefined style. Maybe mpc just read the Normal and output all the subs that way?

https://i.postimg.cc/V0JsfdQF/subs2.jpg (https://postimg.cc/V0JsfdQF)

[Klaus1189]

"Attachments Pending Approval" I can not download it. Upload it on Google drive or similar. I also tested a video with six external srt sub files. working fine here. Try to reset to default settings and configure it new. Perhaps this helps.

[steakhutzeee]

"Attachments Pending Approval" I can not download it. Upload it on Google drive or similar. I also tested a video with six external srt sub files. working fine here. Try to reset to default settings and configure it new. Perhaps this helps.

This is strange, here is: https://www12.zippyshare.com/v/uO8nmJIi/file.html

EDIT: Tried the Reset in the subs section, tried to load the subtitle with default settings. Same issue :(

[Klaus1189]

I meant the complete reset of MPC-BE on last page in options.

[Klaus1189]

If I select "italic" in options, the subtitle is displayed correctly, and similar, working fine here, so I think the reset of settings will help ;)

[steakhutzeee]

I meant the complete reset of MPC-BE on last page in options.

Did this too just now. Does not work.
I have to simply to use Styles to see italic, bold, etc.
If i check default style, i only see an unformatted text.

[Klaus1189]

To be sure, this is what it looks like here if I use italic:
https://drive.google.com/file/d/1aIrAvs1ByUyF9LKWhbp8Ri_lA59tiuTw/view?usp=sharing

[steakhutzeee]

To be sure, this is what it looks like here if I use italic:
https://drive.google.com/file/d/1aIrAvs1ByUyF9LKWhbp8Ri_lA59tiuTw/view?usp=sharing

To this point i don't know what's happening :confused:

Could you please make the same screenshots i made?

[Klaus1189]

the first is already in #5733
the second is here:
https://drive.google.com/file/d/1zyzWg6DJdcxj_x6XB_T13iVwszXQ2dJt/view?usp=sharing
As already stated I selected italic for testing purposes.

[steakhutzeee]

the first is already in #5733
the second is here:
https://drive.google.com/file/d/1zyzWg6DJdcxj_x6XB_T13iVwszXQ2dJt/view?usp=sharing
As already stated I selected italic for testing purposes.

So the fact you selected italic is not important to this test?
What happens if you select Standard?

[Klaus1189]

Already in #5733 I was asking myself if I did get it right. Sorry my bad.
The srt file you uploaded, contains an italic sequence, which should be displayed italic while there is "Standard"/"Default" selected in options.
But if you select "Default Style" in advanced subtitle right click menu, the italic formatting in srt file is ignored which should be right, because if you use englisch or german language the selected feature states that it uses Default style which overrides any formatting like italic in srt file.

[steakhutzeee]

Already in #5733 I was asking myself if I did get it right. Sorry my bad.
The srt file you uploaded, contains an italic sequence, which should be displayed italic while there is "Standard"/"Default" selected in options.
But if you select "Default Style" in advanced subtitle right click menu, the italic formatting in srt file is ignored which should be right, because if you use englisch or german language the selected feature states that it uses Default style which overrides any formatting like italic in srt file.

Exactly, so the only thing possible is to not use "Predefinied Style". Am i right?

[Klaus1189]

IMHO yes, I never used that feature before today.

@devs: correct me if, I am wrong.


I tested today @100% scaling same issue like in 200%:
https://forum.doom9.org/showpost.php?p=1854024&postcount=5720
https://drive.google.com/file/d/1OhUXkgfCGYof1DlToPg_Za7oKF7hHnBr/view?usp=sharing
https://drive.google.com/file/d/14L0iRCQ-okPKzedsnx3XsiEFzyc1V-YM/view?usp=sharing

Can you reproduce that issue?

[v0lt]

Klaus1189
I think there is not enough space for it and therefore the last characters are removed to a space.
Perhaps after r4024 this problem will not be.

[Grimsdyke]

Seem to have been fixed in 4024 and 4025. Thx !!
Now if it also could get fixed that MPC-BE automatically assumes that the content with the longest duration is also the main feature then I would be a happy camper.

All the best

[Klaus1189]

Yes, I can confirm, it is fixed.
Thank you v0lt :)

[steakhutzeee]

IMHO yes, I never used that feature before today.

@devs: correct me if, I am wrong.

Thank you :D

[steakhutzeee]

Asked this question in the past. Try again now bacause maybe something changed :D

There is chance to reproduce a bluray with mpc-be? Files with structure: BDMV/CERTIFICATE/etc.?

Thanks!

[Aleksoid1978]

Open BD support, but without menu.

[steakhutzeee]

Open BD support, but without menu.Thanks! So if I have a BluRay with all those folders, what the file I have to start?

I can select audio and subs track the usual way I think right?

And how to access the extras?

Thanks for your time :)

[ryrynz]

File -> Open DVD/Blu-ray
Navigate to BDMV directory, 'select folder' button.

[BetA13]

hy,

just a quick question:

https://i.imgur.com/tif7FFP.png

second Line from Bottom, "Dither", is this a new option? it wasnt there before i updated.. Where can i control it?

THX and greetings...

[v0lt]

@BetA13
This is not an option; it is processing the image while reducing the bit depth. It was always (in MPC-HC is also the same).

[Klaus1189]

You selected 16-bit Floating Point here (https://drive.google.com/file/d/1gDdtKB1ll2pHhxPyuckhPG1w9XyXoCh0/view?usp=sharing), at 8-bit Integer or 10-bit Integer it's disabled.

[BetA13]

@BetA13
This is not an option; it is processing the image while reducing the bit depth. It was always (in MPC-HC is also the same).

You selected 16-bit Floating Point here (https://drive.google.com/file/d/1gDdtKB1ll2pHhxPyuckhPG1w9XyXoCh0/view?usp=sharing), at 8-bit Integer or 10-bit Integer it's disabled.


:thanks:

now i understand, Danke Klaus :)
So teh OSD now shows this info, didnt do it before, and i know its a dummy question but, isnt a higher floating point better?
Or should i set it to 10? Lets say for best quality..?

Thanks a lot guys..:D

[v0lt]

@BetA13
If you do not see positive differences, then it will be better not to change anything in the settings.