MPC-HC tester builds for internal renderer fixes

[Dstruct]

The look-up quality for the color management is based for the main part on the size of the 3-Dimensional Look-Up Table (3DLUT). It contains the color correction data generated by the the color correction engine's output using the calibration profiles (.ICM files) with calibrated display devices.

What about ICC files? NEC SpectraView software creates ICC files.


My default Windows XP system profile is called "NEC MultiSync LCD2490WUXi.icc" (hardware calibrated).


Build mpc-hc tester dfr3153.7z has problems here. Little CMS not working properly. Most of the time the picture just goes black. Sometimes I get it working by switching the lookup quality mode. But basically I have to disable it completely in this build.

Lookup table files "lCMS,vds=PAL,abl=bright,rit=per,trc=ppw,wpa=none,lqt=high,bpc=no,qfm=ui16.LUT3D" for example) are also empty (0 bytes)!


What is "Black point compensation"? Sounds like it should be enabled by default? What's "White point adabt state" for?

[Dstruct]

Enabling lcms produces a 0-byte LUT3D file. Once MPC-HC is closed, all subsequent videos produce a black screen. Deletion of the 0-byte LUT3D fixes it, but it get automatically recreated next time you play a video.

There is a 50% chance that at video playback start, MPC-HC hang indefinitely at 100% CPU usage when lcms is enabled.


Confirmed.

[suanm]

Hi,JanWillem32
why is your homepage download (Direct link for the x86 build: http://www.mediafire.com/?ytxw3hkxu41fxk9 ) unreliable?,I can't connect to this redirection anyway,whether you have blocked up the connection from other countries by firewall or not? expecting you can keep connection

[G_M_C]

Hi,JanWillem32
why is your homepage download (Direct link for the x86 build: http://www.mediafire.com/?ytxw3hkxu41fxk9 ) unreliable?,I can't connect to this redirection anyway,whether you have blocked up the connection from other countries by firewall or not? expecting you can keep connection

Just press the link to his mediafire page, and browse from there. The link is in his signature.


development folder, containing MPC-HC experimental tester builds, pixel shaders and more: http://www.mediafire.com/?r367kbp7p9but

[suanm]

Hi,G_M_C
according to your above mention,I open mediafire page,I don't find JanWillem32 's signature.can't find download address,too

[JanWillem32]

@Dstruct: Do earlier versions work? I really didn't change a lot for the final pass section this time.
.ICC and .ICM files are the same: http://www.color.org/faqs.xalter#p9
Also, the error message box I've made should show up top-left of the active monitor with the error message inside, if something goes wrong with the final pass in the latest 2 revisions (unless in exclusive mode). Maybe I should convert that thing to an exception item, so it can close the renderer if something goes wrong.
I'm planning to break the automatic renderer switching on failure function anyway. EVR-CP and VMR-9 r. will switch to VMR-7 r. on failure, for example. It happens without any notification.
A nice article on black point compensation (it should not be enabled in all situations): http://www.gamutvision.com/docs/blackpoint.html
I still have to completely figure out white point adapt state. In my case, I can only see differences between none (the same as with medium) and full with the absolute colorimetric rendering intent. The only logical white point adapt state with an absolute colorimetric intent is of course none, else it wouldn't be absolute anymore.
I also wonder if the saturation intent is even valid as an option in a video player, but that's another topic.

@suanm: As far as I know, the services by MediaFire are not blocked by ISP firewalls in general. I've seen that there are quite a few downloads, too. When downloading, I get about 170 kB/s.
Did you have any issues with the download links I posted in the past?

[cca]

I just downloaded rev3153, any hints as to which resizer does what? Or least what is the difference. Not familiar with the spline ones.

[JanWillem32]

I generally ordered them from least to most processing intensive.
For a nice pictured example, without the math in my "~interpolation methods, cubic B-spline" and "~interpolation methods, Catmull-Rom spline" files, see:
http://pixinsight.com/forum/index.php?topic=556.0
http://entropymine.com/imageworsener/demos/demos2.html
Too bad it's just pixel art, I would love a bigger comparison including windowed sinc filters. To make my order complete: on high-end, lossless photographic content, with transformations done in a proper colorspace, please.

[cca]

By the way, this build doesn't work with DVDs right, the Aspect Ratio is messed up. PAL DVDs, interlaced content.

[JanWillem32]

I can confirm this, but it's also the case with the reference r3158 I just downloaded. Someone also broke the "reset deinterlacing after seeking" function again.

[cca]

Ah, they broke it in the SVN? I use your builds for quite some time now and didn't notice :)

Also, I often get a blank screen and the program freezes when I try to open a video.

[JanWillem32]

:rolleyes:There's still some bits here and there to fix.
Anyway, I added timestamp support for the color management section, so that multi-monitor setups and updating profiles are no longer a problem. The timestamps are just a hexadecimal representation of the last modified time of the active .ICM/.ICC files.
For the other part, I've made some very big improvements in CPU and GPU performance during rendering. There might also be some benefits to memory usage. The only downside is the executable size, my builds are bloated for some reason, compared to the standard ones. I'll investigate why.

[CruNcher]

is dithering by default enabled in your test builds ? i see only values and the test mode but no (disable) ?

[ForceX]

I think 0 (Rounded) disables it. BTW, it shows Little CMS Enabled whether or not I turn it on or off.

[CruNcher]

Ahh thx :)
Btw their seems to be a issue with the Resize Pixel Shader in RGB24/RGB32 input/output) @ least they seem to fail after some seconds, strange bold color planes appearing depending on the color tones of the previous frame it seems over here :( they work fine @ least for YUY2 and YV12 input/output and also the normal pixel shader from the current mpc-hc tree don't seem to fail (tested emboss) with the combination of billinear resizer (no PS 2.0) and RGB24/RG32 Input output (so only the resize pixel shader seem to be affected by this).

System: Nvidia G92 (9800GT) XP SP3 VMR9 Renderless Forceware 275.27
Tested Revision: 3160

[JanWillem32]

@ForceX: That's a problem in the trunk, too. It's easy to fix, though. I just changed the wrong ON to OFF in MainFrm.cpp. Thanks for reporting. Quashing new bugs is pretty important.

@CruNcher: 0 is indeed off for the dithering. 0 is default, 1 (static ordered) is is set by the "Optimal" profile.
The behavior of both EVR and VMR mixers is unpredictable when it's fed a converted RGB input from Y'CbCr. My simple advice for the last few months is to not use converted RGB input, unless you have an early DirectX 9.0 GPU or older Intel IGP that really can't use NV12 or YV12 in VMR-9. I also know a lot of other problems with converted RGB input to the mixer. I simply regard those as completely unfixable.
Note that converting to just 8-bit RGB also limits the quantization in the case with 10-, 16-, or 32-bit surfaces. To be more exact:
10-bit surfaces can quantize 4 times as much,
16-bit surfaces can quantize at least 4 times as much, but might go up to at least 8 times as much, depending on hardware and software implementation,
32-bit surfaces can quantize at least 65536 times as much in theory, but since the calculation format is the same, the actual precision will be completely determined by the compounded rounding errors in the programming math.

I looked up what the white point adapt state is for, and it's indeed just a switch for usage with the absolute colorimetric rendering intent.

[CruNcher]

Oh didn't knew that it was just strange that they work on the current tree but fail with yours with RGB Input/output
I tried to see a difference between bicubic 1.0 PS2.0 and the other new ones by the best will i couldn't see it either upscaling/downscaling (double size)/(half size) i only recognized that the cubic seem to blur a little more but the catmulls look identical (on my display) in both cases to bicubic 1.0 as if nothing would change tried different input sizes (still have to look @ GPU utilization).

Bicubic 1.0 PS2.0 = 2%
Catmull-Rom Spline6 PS 2.0a = 4%

[JanWillem32]

I used plenty of parts from the old renderer. There were also lot of things re-written, so I really don't expect all parts to have the same behavior.
As I'm on this subject, does anyone still use the "Regular offscreen plain surface" or "2D surfaces" options with VMR-9 r. (the two options are actually the same thing in the current implementation)? These are legacy options from VMR-7 r. to give VMR-9 r. very basic subtitle, OSD and stats screen support, without any of the more advanced rendering options (scalers, shaders, vsync options, et cetera). It's very dated and inefficient by now, as the unused items from the regular rendering path are still completely loaded. There hasn't been any maintenance on this rendering path anymore for years now. I'll ask the same thing in the regular thread.
For the comparison of the scalers, I can make some pictures of difficult pictures to scale. The still image filter that is installed with Windows can open 8-bit .BMP and .JPG/.JPEG. If I convert some 8-bit .PNG pictures to .BMP, I can skip chroma interpolation, linearize the gamma, scale it up and down by a complex fractional amount, and just let people decide what to use. I know in what ways the different scalers manipulate pictures, but I think it's better to use pictures than words for that. Also, using whole, or even half factors to scale up or down will not fully represent the quality of a certain scaler.
GPU utilization for these very simple pixel shaders is a laugh if I compare it to some of my regular work. Even the processing load of the color management and dithering part with medium settings is a few times heavier than the spline6 scalers.

[suanm]

[QUOTE=JanWillem32;1504073@suanm: As far as I know, the services by MediaFire are not blocked by ISP firewalls in general. I've seen that there are quite a few downloads, too. When downloading, I get about 170 kB/s.
Did you have any issues with the download links I posted in the past?[/QUOTE]

yes,I have issues with downloading 3153 version(From http://www.mediafire.com/?ytxw3hkxu41fxk9) ,I don't open the MediaFire HomePage ,don't also open MediaFire page link you gave above.Now I don't know where I should connect to download your build 3153 and 3160 version

[JanWillem32]

That's odd. It worked for you a few weeks ago. Does anyone else have connection problems? If so, which file hosts do work for you?
Maybe we should wait a little while longer, maybe it will work again after a while. In the mean time, I can try to just e-mail the file. For spambot reasons, please handle requests with e-mail addresses by PM.

[ForceX]

Mediafire IMHO is one of the best ones out there since it allows you to download many files simultaneously without cooldown, and has resume support and its folder system is great. However, some people seem to have problems accessing that site. If you want to provide additional download support for them, you can use something like http://www.mirrorcreator.com/ which will upload a file to a bunch of file sharing sites for people to grab from. However, I suggest you keep the mediafire folder. Only thing that comes close to MF in terms of folder support is http://www.4shared.com/

[CruNcher]

I used plenty of parts from the old renderer. There were also lot of things re-written, so I really don't expect all parts to have the same behavior.
As I'm on this subject, does anyone still use the "Regular offscreen plain surface" or "2D surfaces" options with VMR-9 r. (the two options are actually the same thing in the current implementation)? These are legacy options from VMR-7 r. to give VMR-9 r. very basic subtitle, OSD and stats screen support, without any of the more advanced rendering options (scalers, shaders, vsync options, et cetera). It's very dated and inefficient by now, as the unused items from the regular rendering path are still completely loaded. There hasn't been any maintenance on this rendering path anymore for years now. I'll ask the same thing in the regular thread.
For the comparison of the scalers, I can make some pictures of difficult pictures to scale. The still image filter that is installed with Windows can open 8-bit .BMP and .JPG/.JPEG. If I convert some 8-bit .PNG pictures to .BMP, I can skip chroma interpolation, linearize the gamma, scale it up and down by a complex fractional amount, and just let people decide what to use. I know in what ways the different scalers manipulate pictures, but I think it's better to use pictures than words for that. Also, using whole, or even half factors to scale up or down will not fully represent the quality of a certain scaler.
GPU utilization for these very simple pixel shaders is a laugh if I compare it to some of my regular work. Even the processing load of the color management and dithering part with medium settings is a few times heavier than the spline6 scalers.

Fully Agree :) and yeah the GPU usage difference is marginal i mean 2% more if their can be a difference with some sources or in some situations doesn't hurt visualizing the difference would be ideal, i also zoomed in upclose into regions but couldn't see a difference, though obviously you lose overview over the whole frame that way.

[CruNcher]

@Jan
http://www.assassinationscience.com/johncostella/magic/

Did anyone tried yet to implement it as a Shader ?

[JanWillem32]

An easy one to write. This code might not be completely optimal, but I believe I interpreted the main function correctly. It's mostly a noise-resistant version of a bilinear kernel, with support in a third pixel. Note that it will blur in a 1:1 pixel mapping situation. For down-sampling, it can probably be compared to a cubic B-spline.
The problem with a windowed sinc function mentioned in that text is probably just Runge's phenomenon: http://en.wikipedia.org/wiki/Runge%27s_phenomenon. I'm quite familiar with it. The bicubic filter used in the example image is a pretty harsh one, but the A=-0.8 and A=-1.0 types in MPC-HC are that too.// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype width resizer
// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float c0;
float c1;
#define sp(a, b) float4 a = tex2D(s0, float2(coord+b*fx*c1, tex.y));

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.x/Magnify+.5-.5/Magnify)*c0;// assign the output position, normalized to texture width in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
// adjust sampling matrix to put the ouput pixel in the interval [Q2, Q2+.5]
int fx;
if(t > .5) {coord = (coord-t+1.5)*c1; t = 1.-t; fx = -1;}
else {coord = (coord-t+.5)*c1; fx = 1;}

sp(Q0, -1) sp(Q1, 0) sp(Q2, 1)// original pixels
return (pow(.5-t, 2)*Q0+pow(-.5-t, 2)*Q2)*.5+.75-pow(t, 2)*Q1;
}// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype height resizer
// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float2 c0;
float2 c1;
#define sp(a, b) float4 a = tex2D(s0, float2(tex.x, coord+b*fy*c1.y));

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.y/Magnify+.5-.5/Magnify)*c0.y;// assign the output position, normalized to texture width in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
// adjust sampling matrix to put the ouput pixel in the interval [Q2, Q2+.5]
int fy;
if(t > .5) {coord = (coord-t+1.5)*c1.y; t = 1.-t; fy = -1;}
else {coord = (coord-t+.5)*c1.y; fy = 1;}

sp(Q0, -1) sp(Q1, 0) sp(Q2, 1)// original pixels
return (pow(.5-t, 2)*Q0+pow(-.5-t, 2)*Q2)*.5+.75-pow(t, 2)*Q1;
}

[suanm]

thank you,JanWillem32,I have received the new version for mpc-hc tester building file you sent.I do tests,I have still questions that I get only black screen[not video image] with EVP C/P renderer mode,After I cancel "Enable little CMS" chosen button,I get video image,But I click "Enable little CMS" chosen button again,video image keeps playback.I don't know whether at the time mpc-hc tester building player keeps in "enable little CMS" mode or not? Because I don't see video image quality improved (or changed)

[janos666]

Do you have an idea why can't I use the overlay mixer anymore?


MPC Video Decoder::Output
Overlay Mixer::Output

Media Type 0:
--------------------------
Video: 320x240

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_Overlay {E436EB7F-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 0
cbFormat: 1124

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

BITMAPINFOHEADER:
biSize: 40
biWidth: 320
biHeight: 240
biPlanes: 1
biBitCount: 8
biCompression: 0
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 28 00 00 00 40 01 00 00 f0 00 00 00 01 00 08 00 (...@...đ.......
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00|00 00 00 00 00 00 00 00 ................
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0460: 00 00 00 00 ....


I am just wondering around the possibilities since I use a TV (a Samsung plasma) with my PC.
I think somebody somewhere said (it's far like an old dream...) that may be it's possible to output YCC 4:2:2 through the overlay surface if you also set the output to YCC 4:2:2 in CCC and you feed the overlay renderer with YCC.
Was it a false speculation?


What do you think about this whole question:

May be you already know that many of the HDTVs convert the RGB signal back to YCC 4:2:2 for image processing and those few TVs which has a real RGB mode ("PC mode" or whatever the manufacturer calls it in the user ODS...) usually switches to this mode with 1080p60 signal only. This mode may have other disadvantages too but it can not be used together with 1080p23 materials if you want smooth Blu-Ray playback. So you can choose between 2:3 FRC and proper 4:4:4 processing (probably true RGB in my case but may be YCC 4:4:4, I am not sure, it can wary between models...) or smooth playback.

My PDP has high bit depth image processing (and also has a PC mode but only for 1080p60 and that mode also reduces precision to lower the input lag, so I only use it for games...), so it is virtually transparent in my case. The reduced chroma resolution is visible on some test patterns but not that bad and there are no other conversion losses. On some other TVs however it can look really bad. (I almost give up on picking up a plasma TV when I tested some Panasonic models with RGB signals which has lower bit depth image processing and doesn't have an RGB or YCC 4:4:4 mode at all, like some Samsung models do.)

And here is this thing in the AMD drivers: YCC 4:2:2 output.
I know it is "fake" but I am wondering about what madshi said earlier about 16-bit output.
Do you know where this RGB->YCC conversion happens?
If it happens after the calibration LUT where the VGA dithers the output anyway, than may be it would worth a try to send out 16-bit RGB for the LUT, let the VGA to convert it to YCC and dither the output back to [whatever=8/10/12bit?]. May be it could slightly improve my setup too but it would definitely worth for Panasonic PDP owners.

And depending on how this built-in RGB->YCC conversion works, it may help if you resize the chroma map in only one direction before you output the RGB data.

God, those 8-bit gradient test patterns look awful on those expensive Panasonic PDPs if you feed them with RGB signal and many people doesn't even know how much better could it be if they feed them with YCC 4:2:2 signals to spare the content from a lossy conversion step...

----

Another concern could be that some HDTVs have built-in noise reduction algorithm which simply can not be turned off, plus PDPs use heavy dithering alone. So, I also fear about dithering noise (more than ever), and that's why I use EVR-CP now with simply rounded 10-bit output.
However I am not really sure if my VGA really outputs 10-bit through HDMI. It was sure with DisplayPort but the HDMI port is may be a DVI port and these VGAs dithers the 8-bit output of DVI.

[JanWillem32]

@suanm: I can replicate this problem with the color management if I temporarily remove my monitor's .ICM profile from the Windows color control panel. The color management freezes the player in that case. The error message the player should give in a message box isn't working properly yet. I'll find out how to get those working, as other problems and renderer crashes are also not properly reported because of this.
In the mean time, check if your color profile is installed and working properly, as that's the most likely culprit.

@janos666: A lot of text to work with this time. I'll try to answer your post in a somewhat logical order, and some more.

The two overlay variants work for me on analog D-SUB connection to my CRT, from an AMD HD4890 and on a single-link DVI connection to an old office LCD screen, from an Intel IGP. I can't get it to work with a HDMI device.

It's possible to set Y'CbCr 4:2:2 in the video card's control panel, but it's a double fake, as the backbuffer is strictly RGB 4:4:4. If an application would manage to disable driver/API interference and output data in a Y'CbCr encoded color model on the backbuffer, it would be a proper 4:4:4 Y'CbCr backbuffer.
I know three presentation options that maybe could do that. I haven't gotten to test any of these yet, though. The problems with the limited and full ranges also pose a problem. Limited ranges are mandatory to eliminate once you start processing in a floating point color format.

Slightly off-topic, but I really don't support the decision made to only implement 4:4:4 and 4:2:2 for HDMI, DP and the (legacy) HD-SDI. They should have either properly implement both common sub-sampled formats (4:2:2 and 4:2:0) or none (4:4:4 only).
There should be only one software or hardware entity that handles all chroma up-sampling.
Implicitly allowing two devices to do chroma up-sampling is just wrong. From the perspective of process engineering: you can never apply multiple differently built devices to handle a process of multiple vectors in multiple vectors and expect the same quality of output from each device.
In a more common perspective: one of the first things I did to MPC-HC's EVR CP mixer was disabling the forced conversions through libswscale to RGB32, and later the conversion to YUY2. Forcing pre-mixer conversions to something the mixer should take care of (converting to progressive 4:4:4 RGB) is simply destructive, seen that the mixers can do a lot better job at that usually (like I noted a few days ago). Although I did allow bit-compatible conversions between YV12, NV12 and I240/IYUV and I kept RGB32 conversions as a last resort option for if all bit-compatible formats failed (as some older Intel IGPs don't support any 4:2:0 formats in the EVR mixer at all). The original configuration of this item allowed conversion to YUY2 from 4:2:0 sources, so I removed that option. The "up-sampling" (I still refuse to call it up-sampling normally, as it's just a bilinear blur) used in that method involves 16-bit unsigned integer math on the CPU and dithering to 8-bit unsigned integers for writing to a YUY2 surface. That means that something else has to pick up that surface in another rendering stage to make the 4:2:2-based YUY2 4:4:4. Whatever method is used in that conversion, it won't be able to use all the data generated in the first conversion, it will interpolate in a different way and it will dither/round the output values in a different way. I consider that a bug in the workflow, and like the many other bugs in the file-to-user playback workflow I will try to eliminate it and make sure that new bugs don't occur.
For true 4:2:2 source images, it's a bit different matter, those get chroma up-sampling only once anyway.
Also, with a video player you have scaling in the process. The chroma sub-sampling grid of an input image will never match the one of an output image if the complete image is scaled.

The RGB to Y'CbCr conversion for HDMI and DP happens in the driver level interaction of the backbuffer. The backbuffer is locked after presentation (backbuffer interactions are slow, expect quite a few milliseconds of video delay) and converted to Y'CbCr by a matrix multiplication.

Many displays don't enumerate anything but 60 Hz in RGB mode (or something else, less than the display is really capable of processing). However, I've had good experiences in adding custom frame rates (although the NTSC 24/1.001, 30/1.001 and 60/1.001 fps modes can be a bit of effort to add). Nowadays the video card's control panels can even add a lot of modes, but I used to write monitor driver .INI files myself to get the same effect for nearly a decade (usually to get higher refresh rates).
I've also tamed a lot of misbehaving display devices though the (factory) service menu. Nearly all devices will not show all options through the regular menus, but once in the service menus, you can do a lot more. Some TVs only allow you to disable overscan for example in the service menus. With most TVs it's nothing more than using a combination of holding a button on the TV with the on/off button and typing in a 4-digit key-code with the remote. (No screwdriver required like in the 80's.)

Some quotes from the HDMI 1.0 specification about the three base color formats:
"If an HDMI Sink supports either YCBCR 4:2:2 or YCBCR 4:4:4 then both shall be supported."
"All HDMI Sinks shall be capable of supporting both YCBCR 4:4:4 and YCBCR 4:2:2 pixel encoding when that device is capable of supporting a color-difference color space from any other component analog or digital video input."
"All HDMI Sinks shall be capable of supporting RGB 4:4:4 pixel encoding."
I must note that there isn't much implied about 8-bit compared to higher bit depths in that part of the text.
A device that doesn't meet these criteria can't apply HDMI ports, HDMI logos, claim any HDMI interoperability, et cetera.

It's indeed possible to have a 16-bit output. To be more specific: it's possible to set quite a few DXGI color formats with DirectX 10 or 11 in this list for output: http://msdn.microsoft.com/en-us/library/bb173059%28v=vs.85%29.aspx . In DirectX 10 or 11 the display driver is fully responsible to convert the presented backbuffer by rounding or dithering the color data on it to a compatible output format. (With of course the limitation that windowed mode can only be 8-bit.) Dithering by a video card is at best a temporally changing 4×4 ordered dither of up to 8 states of the same pattern, but 4×4 static ordered dither is more common. This is done in simple programming math, no sampled dithermap is involved.
For RGB color data these are typically used:
DXGI_FORMAT_R32G32B32A32_FLOAT = 2,
DXGI_FORMAT_R32G32B32_FLOAT = 6,
DXGI_FORMAT_R16G16B16A16_FLOAT = 10,
DXGI_FORMAT_R16G16B16A16_UNORM = 11,
DXGI_FORMAT_R10G10B10A2_UNORM = 24,
DXGI_FORMAT_R8G8B8A8_UNORM = 28,
DXGI_FORMAT_B8G8R8A8_UNORM = 87,
DXGI_FORMAT_B8G8R8X8_UNORM = 88,
There are 32-bit integer types, but since pixel shaders (the typical units carrying out the colorizing parts) output 32-bit float, I think it's useless to work with color data in 32-bit integer formats, both for input and output.

CCC can perfectly well indicate if a device is connected using a HDMI or only legacy DVI. I don't know if there's a valid test for the actual bit depth other than a raw data capture of the sent video in TMDS signals and analysis of that. The program MonInfo can at least display the information the video card is receiving from the display device, you might get to know more from that.
In my case it was pretty easy to confirm: the 8-bit mode without dithering on the gradient shader has terrible banding, the 10-bit mode is a lot better. Both my display devices can't dither/make video noise on their own.
There was no advantage for using the 10-bit mode on the old office LCD screen I tested. It showed the same banding in 8- and 10-bit mode.

Now that you're here, I'd like to add XvYCC input support to the color management section. http://en.wikipedia.org/wiki/XvYCC http://msdn.microsoft.com/en-us/library/ff563113%28v=vs.85%29.aspx
There is material available, and it's quite compatible with the current rendering chain.
I've verified that the mixers are capable of outputting non-clipping color data (RGB values lower than 0, and higher than 1), with adequate accuracy in the quantization for both floating point surface types. (I suspect that the matrices have some minor truncation rounding errors, though.) I can alter the working surface format to change the normal working R'G'B' and RGB surface data to have normal intervals, instead of extended floating-point ones. That means intervals of [0, 1] for R'G'B' and RGB, intervals of [0, 1], [-1, 1] and [-1, 1] for Y'CbCr. The other interval variant of [0, 1], [-.5, .5] and [-.5, .5] Y'CbCr isn't very useful when working with floating point surfaces.
I'm wondering how to set up proper color management and rendering chain for such material. As far as I know, with all larger source gamuts, the absolute colorimetric rendering intent becomes more important. That's because when mapping a relatively large input gamut to a smaller output gamut for the display, compressing the ranges of the gamut will distort far to much visually, compared to clipping the source out-of-gamut colors.
Also, I've been thinking of matrixing all source materials to a linear full XYZ color space as working RGB surface. I'm very familiar with this format, and having a color space that can contain all possible other color spaces for video and images is a rather big advantage in terms of designing a rendering chain. It would eliminate separate 3DLUTs for each input format at the color management section. I can easily adapt color controls and several other filters that will handle each input color format in exactly the same way. For example: at the moment, the output of the color control shaders can't produce out-of-gamut colors, and the shifts in luminance, chrominance, composition and gamma are different for PAL, NTSC and HD formats. All other filters (shaders) that depend on color blending are affected in the same way.
One downside is that I'll have to split off a slim, basic 8-bit renderer with a limited feature set for older hardware, but I'm okay with that. (I wish I could have a peek at the Haali renderer source code for this.)
Another problem is the quantization limitation of the 16-bit floating point format. I don't know if it will cause visible artifacts on even a cheap TN LCD screen, let alone a high-end OLED screen.
What are your views on these subjects? (Input from other visitors of this thread is of course very welcome, too.)

[mindbomb]

is the dithering options only supposed to be used with the floating point processing options?

[janos666]

I know the service menu of my TV, there is nothing interesting in there except the ADC/WB calibration settings which I already reconfigured.

Custom monitor INF wouldn't help either, I can set my resolution to almost anything (the EDID is already "bloated" with many formats and some others work too if I "force" them with a D3DFS application).
The problem is that only 1080p60 triggers a real RGB (or possibly YCC 4:4:4?) processing inside the TV. But I obviously want to output 1080p24 when I watch Blu-Ray movies to achieve smooth motion (the PDP can run at 96Hz while fed with 24Hz) and this resolution triggers a different kind of internal processing which always converts everything back to YCC 4:2:2. And some TVs doesn't have an RGB or YCC 4:4:4 processing mode at all.

It's not the HDMI decoder chip, the TV usually accepts everything (YCC 4:2:2, 4:4:4 and RGB too) but it usually converts it back to YCC 4:2:2 for processing (scaling, gamut and gamma correction, white balance and all those "mighty magic muthef@ker features" in the user-OSD starting from thousands of virtual/digital noise/contras/black reducer/increaser tricks, etc)

That's why I think it could be a good idea to feed them with true 4:2:2 signals. I think it could make a noticeable improvement. Because unless this [ANY but YCC 4:2:2] -> YCC 4:2:2 conversion is done by a high precision internal processor, it's not a good idea to feed them with RGB (as I said, it is virtually transparent with my TV but I saw some expensive Panasonic plasmas which looks really bad with RGB input).

----

No, Absolute and Relative handle the gamut in the same way. The only difference between them is the white point handling (the Absolute intent corrects the WP too).
The Perceptual and Saturation intents are the tricky ones, but Perceptual is probably what you want with xvYCC. It compresses the gamut with less banding than Rel/Abs. (And I don't really know what Saturation exactly does in lcms.)

Yah, the XYZ space could be way big for usual video materials with float16 encoding. It's very big (many possible values will never appear) and the Y is linear. And you face the problem that you have to decide about how to linearize the gamma weighted RGB input.
But yes, it could make the CMS tasks more easy and may be more effective, so it may worth a try with float32.


---------

@mindbomb
The 10-bit integer surface mode can benefit from it as well if the output is 8-bit.

[CruNcher]

Yeah TV manufactures as well some Monitor ones should implement plain non post-processing modes, but they unfortunately like to brag with the advanced Post Pro they have either developed in house licensed or done in collaborative Research MSU(Yuvsoft) and Samsung are the best example here :( Hard to understand that their is no (turn everything off feature)

[JanWillem32]

@CruNcher: I totally agree. I wouldn't have bought my current (and a few past) display devices if I wouldn't be able to control a lot. With my CRT it's easy: all input, processing and output is analog. That does produce visible analog artifacts, but the digital parts of the processing chain are done on the video card, which is pretty easy to control in an almost absolute way. My projector has pretty decent default settings, and all filters are quite properly configurable, but there are no real 1:1 analog controls in the menu.
I once played with an LVDS (a digital interface, similar to DVI-D) driving unit for a laptop LCD screen. It had simple analog voltage input pins to create the digital to analog transfer function for the RGB matrices in the display, and was void of any digital processing. The backlight used a separate controller. Modern versions of such a driving unit can probably use programmable RGB transfer curves and a better frame buffer system.
I would most certainly like displays to give control over the analog driving parts, while the digital image processing controls are disabled. That shouldn't be too hard to implement. I wonder what professional equipment offers, as I can't think of a more demanding calibration task than the one for DCI certification.

@janos666: There are no chroma sub-sampled backbuffers possible. Any compatibility with 4:2:2 will have to be hard-coded into or next to the ramdac as a convertor for the 4:4:4 backbuffer. I'm not even sure that part will activate properly if an Y'CbCr 4:4:4 direct overlay-or-something is used. I can only set a few of the DXGI_FORMAT RGB items as backbuffer, all are 4:4:4.
I'll have a go with testing a larger processing gamut. I'll try to implement similar sliders for color controls as the VMR-9 items (Options, Miscellaneous tab), with a default gamma set to a basic 2.4.

@mindbomb: Single-level dithering is intended only for 10-, 16- and 32-bit surfaces with a relatively clean image in the processing pipeline for 8-bit output. The 10-bit display output mode doesn't gain much with single-level dithering from 16-bit surfaces, and nothing from 10-bit surfaces. The random dither can work with just about anything, but it will add several levels of random colored surface noise on gradients and single-colored parts (it features contour detection to dither less or do nothing on already noisy parts).

[suanm]

"@suanm: I can replicate this problem with the color management if I temporarily remove my monitor's .ICM profile from the Windows color control panel. The color management freezes the player in that case. The error message the player should give in a message box isn't working properly yet. I'll find out how to get those working, as other problems and renderer crashes are also not properly reported because of this.
In the mean time, check if your color profile is installed and working properly, as that's the most likely culprit."

Hi JanWillem32
I don't really know where and how to check my color profile you said above? tell me clearly where and how to check it,please.

[JanWillem32]

Copied from a link I posted a while ago:
All actions will be done at Color Management tab, which is accessible by right click on Desktop, and select Personalize on the contextual menu. Click on Display Settings link in the Personalization menu. In the Display Settings window, click on Advanced Settings… button. Then click on Color Management tab, and finally click on Color Management… button. You will need to select (tick) Use my settings for this device to be able to remove, change or set new color profiles.

If you use the classic view for the Windows control panel, the Color Management item is in plain view as a regular icon there.
Both Vista and 7 feature an extremely basic color wizard that can produce working profiles. You can't compare it to an actual hardware calibration device, but it's a nice tool for those that want to give display calibration a try. (However, it calibrates toward an sRGB profile. I'm personally not too fond of the 2.2 gamma setting.)

[JanWillem32]

I've had to bend over backwards for some of the fixes I made this time, but the results make up a lot. I do need to clean up and optimize the new code I wrote, and fix the new set of error messages, as some won't show up.
-I corrected some of EVR Sync's shader handling code, so that scalers and screenspace shaders should work better
-Pixel shader menus will now work even without a video renderer active
-VMR-9 r. can now use screenspace shaders
-I added a fix for a rare problem with a hanging still image when switching files in exclusive mode
-Not sure how and why, but aspect ratio correction seems to work again and exclusive mode is less oversensitive to keyboard commands (but not perfect yet).
-I added some optimizations for a shorter initialization time

[cca]

I wish someone would fix the DVD playback issues too, for now I have to use plain EVR :/ .But since it's an upstream issue, who knows when.

[JanWillem32]

I don't have much experience with DVD playback problems. As far as I know, DVD subtitles work, and playlists for .VOB files work fine. I'm only not too sure about menus, but that's something I really don't know how to work with. If I were better with GUI items I'd sooner add a few buttons for a toolbar in exclusive mode, anyway.

[cca]

I don't have much experience with DVD playback problems. As far as I know, DVD subtitles work, and playlists for .VOB files work fine. I'm only not too sure about menus, but that's something I really don't know how to work with. If I were better with GUI items I'd sooner add a few buttons for a toolbar in exclusive mode, anyway.

I was just referring to the specific renderer problem mentioned before, i.e. it doesn produce the right aspect ratio and the image is distorted.

EDIT: just tried your latest build, the issues I used to have with the AR seem to have gone!

[suanm]

Hi JanWillem32
Today is so lucky,I happen upon opening mediafire page ,download build dfr3204 immediately .my system is windows xp sp3,I don't find any of profile in the Color Management item on the Windows control panel, but sRGB Color Space profile. when I choose 'Enable Little CMS' function,Playing video becomes black screen(no video image). After Canceling 'Enable Little CMS' function,video image comes back(appears).So seems that there are some of little bugs on build dfr3204 software

[TheElix]

An easy one to write. This code might not be completely optimal, but I believe I interpreted the main function correctly. It's mostly a noise-resistant version of a bilinear kernel, with support in a third pixel.
Does it mean you can implement this Magic Kernel in the player? :eek: Because that example with vegetables was very impressive!
Got your latest build, gonna test everything now, including new scalers! This is like a revolution to me.
Can't say anything about complex things you and janos666 discussed but I have to say that there're more and more HDTV users who will be able to take advantage of these things. I also have Panasonic PDP (TX-PR42GT20).
A quick question: which is better to set as pixel format for me? Obviously not Full RGB because then I get crushed picture.

EDIT: Hmmm, I see virtually no difference between Bilinear (PS 2.0) and Cubic B-spline6 (PS 2.0a). Do you?
Bilinear (PS 2.0): http://rghost.ru/10315281/image.png
Cubic B-spline6 (PS 2.0a): http://rghost.ru/10315361/image.png

Bicubic gives sharpest picture but a lot of artifacts. Catmull-Rom spline6 is almost as sharp and gives a little less artifacts so I'll be using it for now.
What about Lancoz, any plans to implement it?

[Hera]

Does FullFP setting work? I am not getting any frame dropping with FullFP with these builds.

[Qaq]

Does FullFP setting work?
It does. Check OSD stats and jitter values for FFP and HFP.

[Hera]

It does. Check OSD stats and jitter values for FFP and HFP.

FullFP does not drop frames now per OSD stats.

Video visually is smoother with D3DFS still though.

[JanWillem32]

@suanm: Good to hear that you can access the site again. I know that the renderer will refuse to work if color management is enabled while there's no active color profile installed. That's the correct behavior. The problem is that the error message I wrote for it just doesn't show up. It should say: "color management failed to find the active display device profile (.ICM file)".

Does it mean you can implement this Magic Kernel in the player? :eek: Because that example with vegetables was very impressive!I still have to mess around a bit with the scalers. There's no absolute perfect one, so the best I can do is to implement a few good ones. I still have to analyze about 8 scalers of which I do have the code, but haven't seen how well it performs in a rendering engine. I've actually written only a small number of scalers myself yet. I have to analyze the filters carefully to uncover characteristics such as ringing, haloing, aliasing, noise resistance and posterization. I must admit, that's not easy for me. The two documents on the higher-order spline types took me hours to write, let alone analyze and implement.
Also, you've probably seen the names I give to my pixel shaders. If I would implement "Magic Kernel", It's going to need to be renamed to something at least 2 times as long.:pCan't say anything about complex things you and janos666 discussed but I have to say that there're more and more HDTV users who will be able to take advantage of these things. I also have Panasonic PDP (TX-PR42GT20).It's already difficult for software developers to get along with the internal hardware of PCs (drivers, interaction with other software, CPU/GPU performance and so on). External hardware is at a whole other level. I believe that the CRT TV my parents bought in 1994 behaved a lot better then most of the current TVs in the same price class today. Although it was limited to D-SUB and lesser analog connections, it behaved quite similar to a monitor after geometry adjustment.
A quick question: which is better to set as pixel format for me? Obviously not Full RGB because then I get crushed picture.The rendering engine can't deal with anything else than full range formats. The output is always full range RGB, too. If another color format is set in the video card's control panel, both quality and performance degrade because of the extra conversion step. I've never serviced a display device that really couldn't deal with full range RGB input. All TVs I've worked with in the last few years have options in the regular menus for using full range or are even hard-coded to use full ranges. (Getting overscanning disabled is a bigger problem.)EDIT: Hmmm, I see virtually no difference between Bilinear (PS 2.0) and Cubic B-spline6 (PS 2.0a). Do you?Cubic B-spline6 is the most noise and aliasing resistant of the current internal scalers. On the other hand, on very sharp contours, it's more blurry than a standard bilinear.Bicubic gives sharpest picture but a lot of artifacts. Catmull-Rom spline6 is almost as sharp and gives a little less artifacts so I'll be using it for now.
What about Lancoz, any plans to implement it?The internal bicubic forms are well-written and sharp, but indeed have the awful tendency to have a lot of aliasing and haloing.
In order of perceived sharpness (nearest neighbor omitted): bicubic A=-1.0, bicubic A=-0.8, Catmull-Rom spline4, Catmull-Rom spline6, bicubic A=-0.6, cubic B-spline6, bilinear, cubic B-spline4.
That doesn't say what scaling artifacts each creates. The 3 Bicubic forms are very sharp in general on rectangles, but score badly on interpolating diagonals or curves. For example, with the gray-on-gray text test, the bicubic A=-1.0 and bicubic A=-0.8 have so many artifacts, it's bad for readability. Catmull-Rom spline6 is a bit less sharp than bicubic A=-0.6 when scaling a grid of single-pixel rows and columns, that's just inherent to its nature.
I'll add some windowed sync filters later on. I'm already quite happy I could add 4 scalers in a short time. Developing these takes time, as there's hardly any code I can just copy directly into a pixel shader. (On top of that, the fold-down menu of the scalers is just very annoying to write. None of the translators have touched it either.)

@Hera: There are problems with memory management for textures in the renderer. I've solved a lot of them, so getting less frame drops is to be expected. Exclusive mode will always perform better than windowed mode, as there's simply a rendering obstacle less.
By the way, seeing your hardware (nVidia ION, ATi Radeon HD 4250M and nVidia GeForce 6600), can you really get a regular 1080p24 blu-ray video to render with FFPP? It's a bit demanding on memory bandwidth, which is often limited with low-end or older mid-end hardware.

[Hera]

4250M still crashes and burns; the whole system becomes unresponsive / quite laggy.
NV ION seems fine with D3DFS mode, not without it.


Also,
Overlay + no D3D + subtitles = black background of the graph.
Overlay text is all tiny for some reason.

[Qaq]

FullFP does not drop frames now per OSD stats.
I meant you can see 'FFP' in OSD. Also, you can see that FFP produces a bit bigger jitter value than HFP. At least I see (under XP), and that proves for me FFP is working. But I'm not sure someone is really see a visible difference in PQ between FFP and HFP. Anyone?

[JanWillem32]

When dealing with 10-bit output or better, a half can't really deliver enough precision for an accurate single-level dither. Next, there are a few rendering stages in the mixer, there are scalers, the final pass and I set a few pixel shaders. With every rendering stage, you have to write out to the next surface. If you set any other format than the calculation format, the output of each stage is rounded. Some of that rounding in a few stages can be quite degrading on the quality in the end.

[Qaq]

No doubts in math, I only wonder if thats visible or not. YUV>RGB, scaling are lossy convertions anyway. Personally, I love to use as mach precision as I can with my equipment. But sometimes I have to find an compromise to keep it working and watch some 'heavy' videos. With my ATI 5450 I have no problem with 1080p24, but those HDTV 1080i29 just drive me nuts sometimes. And here comes a problem that I just don't know a really good tool to measure the GPU loads. I tried GPU-Z, it showed ~57% GPU load while video playback was stuttering. Also, GPU-z doesn't show me VRAM load under win7. I don't even say about Bus load. It's hard to find the bottleneck without complete measurements.

[TheElix]

I ran sharpness & overscan test (http://narod.ru/disk/15684583001/5-Sharpness%20%26%20Overscan.rar.html) and got some disturbing results: http://screenshotcomparison.com/comparison/58782
EVR is the only renderer to pass the test. I don't know, maybe it's just my system. I would ask somebody else to run this test too.
BTW, JanWillem32, is there a possibility to include internal subtitle support in MPC-HC for EVR?

[JanWillem32]

@Qaq: I've also seen problems with interlaced content that features 3:2 pulldown. The current presenter threads try to predict frame times, but pulldown causes prediction to fail. Even when not using any Vsync options, that's still an obstacle. Trying to skip pulldown makes playback very jerky (understandable, since 1/3 of all fields is fake or duplicate). Any additional filters/options that make playback heavier than the minimum also seems to have a disproportionally big impact on the inaccuracy of the presenter.
With progressive video, I don't see these problems, even if my GPU peaks up to 95% load. I wish there was a way to implement a better version of the pulldown filter in the renderer, one that informs the presenter. It's probably okay too if the decoder performs pulldown without deinterlacing and reports 2/3 of the field rate to the mixer (with the correct flags for top and bottom fields).
A small side-note: the NTSC slowdown framerates of 24/1.001, 30/1.001 and such, will always be a bit tedious to work with. Setting 24 or 30 exact frames per second are a lot easier to time, and using 1.001 speedup or 1‰ frame duplication has a positive impact on performance.
I still have to find ways to get the subtitle renderer less jerky. Someone posted a simple SD video a while ago with some animated text subtitles (not even extremely fancy ones) that would just choke the renderer just before presenting each new line. I think it will take some time before that improves. It's a difficult item to work on.

@TheElix: I can't replicate the results in those pictures. The renderer will correctly use nearest neighbor filtering when performing 1:1 mapping. It looks like something is offsetting the picture in your case. It's been a while since I've seen this type of problem. You're sure that even the basic (older) renderers have the same problem?
I haven't worked with vanilla EVR yet, but it supports the OSD already, so subtitles should be possible.

[TheElix]

JanWillem32
I've asked at other places, and apparently, this is my pc-exclusive problem. I have the same blurry text as in the top right corner of the picture when I run other applications which use hardware acceleration (Firefox, java apps). For example: http://rghost.ru/10403441/image.png
If only I could determine the root of the problem and know where to ask. Sorry for a major offtop.
BTW, I have OSD enabled and I can't get subtitles to show in MPC-HC (without using external filters, of course).