MPC-HC tester builds for internal renderer fixes

[JanWillem32]

I was thinking of this topic: http://forum.doom9.org/showthread.php?t=159908 .
That one doesn't seem to be exactly the same, but it does have a few hints. Take a look at the system-wide font scaling options, the overscan settings in the video card control panel and maybe some of the 3D settings there, too.
Vanilla EVR doesn't have the extra connection to the subtitle renderer (yet), only the OSD renderer (and that one outputs screen-sized images only, so the picture is usually distorted).

[TheElix]

Problem FIXED!!! I turned off Morphological Filtering... -_-
Day-saving link: http://support.mozilla.com/ru/questions/796715

[Hera]

Are you going to merge EVR and EVR:CP then?

~30Hz 1080 content requires noDC and D3DFS options.

[JanWillem32]

EVR and VMR-9 are two standard renderers installed in Windows (or come along with the .NET package). "Custom Presenter" and "(renderless)" are presenter variants that borrow the mixer part, but don't use the default presenter. (They share the same presenter code.)
EVR Sync also uses the default mixer. For further improving the renderers, a custom mixer can be added. I would like that, but it's quite a big job.
30 Hz HD video, especially with interlacing is heavy indeed. Disabling the rendering of desktop items can indeed save just enough GPU power for smooth rendering.

[CruNcher]

Problem FIXED!!! I turned off Morphological Filtering... -_-
Day-saving link: http://support.mozilla.com/ru/questions/796715

Yep Elix this is from a user perspective a problem before Vista/7 you hadn't to take it into account bit since the GUI architecture changed entirely to Direct3D/2D/Write/Warp (DWM) you have to take this into account and their is no other way by either the Application Developers or the GFX Driver makers with their Profiles to adapt to this :) And there i see a big problem with different renderer with different requirement it will become funny handling this from 1 Application as Nvidias and ATIs management only works on the Application layer (executable to be exactly to make it decisions).

[G_M_C]

One question, im shure someone asked before but i cannot find the right answer.

I have downloaded and installed moninfo. It confirms my receiver/display device combination accepts 4:4:4 / 4:2:2 / RGB at 30 and 36 bit through HDMI. It also accepts xvYCC601 or xvYCC709.

Firstly, i would be interested in a xvYCC output option in MPC-HT.

Secondly, moninfo tells me what color format connection is possible, but is there any way to find out what connection is actually made, and what kind of color format is actually send over ?

[JanWillem32]

The currently rendered display color format can be indicated by dxdiag.exe. If the current display mode indicates "(32 bit)", it's X8R8G8B8.
Y'CbCr modes can be selected in the video card's control panel. If they're not there, it means only RGB can be used.
4:2:2 and 4:4:4 modes are different from each other in handling deep color modes (anything beyond 8-bit).
HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be up to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with up to 12-bit color, but devices don't have to support it (the same behaviour as with HDMI 1.3 is allowed).
I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Matrixing xvYCC sources to a working RGB surface is easy, I've already done that. The color management can be adjusted to this type of input easily.

[Qaq]

I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Yeah, I start to think here could be a HDMI transmitter's limitation, since both AMD and Nvidia are affected according to this:
Q3) You said the xxLD450 supports 4:4:4, but I’m not seeing it, what's wrong? -OR- Why is the overall picture quality fuzzy, especially red colored text? (http://www.avsforum.com/avs-vb/showpost.php?p=19723268&postcount=647) :
After extensive research and experimentation by galneon and others, 4:4:4 sampling will not work if you use a direct HDMI->HDMI connection. For both Nvidia and ATI video cards, there appears to be something intrinsically wrong with the HDMI information exchange when HDMI video+audio is enabled, which forces 4:2:2. galneon's overall conclusion about this issue can be found here: link. If you want to read the entire chain of posts, start here: link. It is of interesting note that this problem is universal, and not just specific to the xxLD450.

Currently, there's only two workarounds. 1) Use your video card's DVI port with a DVI->HDMI adapter, or 2) Use the EDID Override fix . The EDID override disables the HDMI extensions which will force the TV to appear as a typical DVI monitor to your video card (as if you were using a DVI->HDMI adapter). However, by disabling the HDMI extensions, you no longer get audio over HDMI.
See also 5xxx/6xxx series: HDMI to HDMI connection forces 4:2:2 subsampling. DVI to HDMI connection proper 4:4:4 (http://forums.amd.com/game/messageview.cfm?catid=260&threadid=145310)

[JanWillem32]

Interesting, but a bit odd. I haven't tried a card from the 5xxx/6xxx series yet. My HD4890 and a simple HD4350 card I've worked with were both fine with HDMI output (both have active audio output). It's not like I wouldn't be able to see chroma artifacts, as I've used the grid shader as a basic test for quite some time already. I wonder what factors contribute to breaking the color formats. I must note that I always set full range RGB when it's available (all other formats are only converted from full range RGB anyway).

[Qaq]

There are also evidence that FullRGB is affected too. IMO, if both vendors have same bug, it's more likely not software but hardware (HDMI transmitter) bug.

[G_M_C]

The currently rendered display color format can be indicated by dxdiag.exe. If the current display mode indicates "(32 bit)", it's X8R8G8B8.
Y'CbCr modes can be selected in the video card's control panel. If they're not there, it means only RGB can be used.
4:2:2 and 4:4:4 modes are different from each other in handling deep color modes (anything beyond 8-bit).
HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be up to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with up to 12-bit color, but devices don't have to support it (the same behaviour as with HDMI 1.3 is allowed).
I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Matrixing xvYCC sources to a working RGB surface is easy, I've already done that. The color management can be adjusted to this type of input easily.

I'd like to go into the subject of xvYCC some more;

I'v been reading around on the interwebs', and get the idea the 10-bit/color output seems (on Ati's/AMD's) at least only possible on FireGL/FirePro cards. There is an softmod possible to recognize youe 'regular' radeon as a FireGL/Pro, but this is a bit of a hack.

In some earlier post you suggested that you could set output format to several possibillities without much trouble, including xvYCC.

Couple this with the fact that xvYCC is promoted on consumer grade appliances for a while now, and many if not all recent TV's / receivers etc. support it, and since you state that 'Matrixing xvYCC sources to a working RGB surface is easy', I come to the idea that trying to get xvYCC output (to HDMI) working in MPC-HT might be the way to go to get wide(er) gamut output of MPC-HT to a wide audience of users.

Do you think this to be a feasable idea or option ?

[Qaq]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

[janos666]

See also 5xxx/6xxx series: HDMI to HDMI connection forces 4:2:2 subsampling. DVI to HDMI connection proper 4:4:4 (http://forums.amd.com/game/messageview.cfm?catid=260&threadid=145310)

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.

Full Range RGB 4:4:4 pixel format:
Non-labeled HDMI input, Game mode OFF -> 4:2:2
Non-labeled HDMI input, Game mode ON --> 4:2:2
PC-labeled HDMI input, Game mode none -> 4:4:4 (may be still processed in YCC 4:4:4)

And I got exactly the same results after I changed pixel format to YCC 4:4:4 in CCC.

The levels are also seem to be correct in both Full RGB and [what? limited??] YCC. (There is no black crush and black isn't light gray...)


A strange thing: I have distorted colors (looks like RGB is only flagged as YCC or vice-versa but not converted) with PowerDVD 11 in HDMI 1.4 1080p24 3D mode when CCC is set to YCC output.


Despite the 4:2:2, I am using the TV with non-labeled input and I feed it with Full Range RGB because I can't do 3D CMS with PC games, and the TV doesn't offer gamut emulation in PC mode. And the gamut error is more noticeable than the 4:2:2 chroma sub-sampling (without the help of test patterns and cameras in macro mode...), plus the gamma and white balance is also more precise with calibrated hardware controls, so I don't really need a VGA LUT.

[janos666]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

Turn off the dithering in MPC-HC and you will see the difference. Well... at least on a 8-bit gradient test pattern.

Do you know what was his pixel format setting in the CCC? (I guess RGB but who knows...)

I could never test if these cards output real 10-bit RGB or that is only the same dithering which they offer for single-link DVI.

[G_M_C]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.
[...]


That can be, but the number of consumer grade devices (read this as the 'great value for money devices' that average Joe buys) and ditto graphics boards that verifiably output or accept 10-bit / color will be much lower than number of the same grade of devices that support xvYCC (assuming the xvYCC output works offcourse). Cause the latter is supported in almost everything recent (even some smartphones support it). In my opinion that makes xvYCC the shurest option to get wide(r) gamut display to the masses.

[janos666]

Ah, well...

xvYCC is only available on my TV when I feed it with YCC signal. (It's grayed out with RGB signals which I think is logical enough...) And it basically does the same thing which happens when I set the Color Space option (which is available with RGB input as well) to Auto.
I set up the Custom mode for sRGB/Rec709 primaries instead. (The Auto cuts the green back too much in the Y direction.)

So, it would obviously require a real YCC output from the VGA card which would be very tricky if not completely impossible with today's hardwares and APIs (it would be a nice thing though, xvYCC or not...)
However AMD and nVidia both claims that their latest hardwares support xvYCC and DeepColor.

I think Jan would still work with RGB output and he only wants to support the wide gamut (xvYCC encoded) materials via the CMS engine (with the available gamut mapping methods).

[TheElix]

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.
OH RLY? "Red" and "Magenta" are blurry and everything casts shadow on blue background here on HDMI-HDMI + Catalyst 11.6. Isn't this a sign of 4:2:2 chroma subsampling?
http://img.photobucket.com/albums/v293/nuker43/inputlag/TintBlueRGB.png?t=1287963155
Thanks to Qaq for pointing out the problem. I never though it could be solved.
*sigh* I spent all day on it and haven't solved it yet.

[fairchild]

OH RLY? "Red" and "Magenta" are blurry and everything casts shadow on blue background here on HDMI-HDMI + Catalyst 11.6. Isn't this a sign of 4:2:2 chroma subsampling?
http://img.photobucket.com/albums/v293/nuker43/inputlag/TintBlueRGB.png?t=1287963155

Yeah I tested this for shiz and giggles and on my plasma I can't get 4:4:4 regardless of pixel format and I even tried DVI to HDMI dongle. I always get red and magenta blurred. My plasma doesn't have a PC labeled HDMI port. Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes

[TheElix]

I even tried DVI to HDMI dongleYes, me too.
Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes
Same here.

Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes

I can't find myself giggling for some reason. But I've not given up yet until I manage to disable audio through HDMI as suggested. Any help here would be greatly appreciated!

[janos666]

Supports YCbCr 4:4:4..... Yes

I bet it "supports" it like a HD-Ready TV accepts an 1080i signal or an old monochrome analog TV displays the luminance signal and ignores the chroma information...

I tried it myself and it works for me. I could upload my photos but I don't think they are more trustworthy than my word because images could be faked as well... So believe me or not, but I think your should blame your TV instead of your VGA.

My current driver version is 8.86-110512a-119746E by the way.

[fairchild]

I bet it "supports" it like a HD-Ready TV accepts an 1080i signal or an old monochrome analog TV displays the luminance signal and ignores the chroma information...

I tried it myself and it works for me. I could upload my photos but I don't think they are more trustworthy than my word because images could be faked as well... So believe me or not, but I think your should blame your TV instead of your VGA.

If you re-read my post, I did blame the TV. I'll copy and paste again for you:

Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

[janos666]

Sorry, that post was meant for TheElix but I mistakenly quoted the "Supports YCbCr 4:4:4..... Yes" line from your post (you both wrote this after each other).

[TheElix]

I have Panasonic GT20 (2010 model). I wonder if VT20 supports 4:4:4.

[fairchild]

I'm not sure if many plasma's do proper 4:4:4. I also have a smaller Sony LCD and it does true 4:4:4 but it has to be set in graphics mode.

[JanWillem32]

I've had a closer look at the matter of setting Y'CbCr on output. I had the same problem as before: invalid call errors. I'm not so sure my video card supports the Y'CbCr overlay function.
I'll have a try with my mother's laptop in a while, as that one has a HD5450M GPU. Let's see if solve that weird 4:2:2 problem.
I don't have enough time to answer everything else right now, I'll try that later.

[TheElix]

I just realized why my PDP doesn't support 4:4:4. This line in EDID:
Supports 48bpp........... No
Because 4:4:4 is 16 bits per channel, right?
And I apologize before JanWillem32 for being off-topic.

[Qaq]

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.

Full Range RGB 4:4:4 pixel format:
Non-labeled HDMI input, Game mode OFF -> 4:2:2
Non-labeled HDMI input, Game mode ON --> 4:2:2
PC-labeled HDMI input, Game mode none -> 4:4:4 (may be still processed in YCC 4:4:4)

And I got exactly the same results after I changed pixel format to YCC 4:4:4 in CCC.
Just made a DVI-HDMI connection.
TV/RGB ('PC' input) - 'magenta' looks ok, so I suppose it's 444.
TV/YCC (all the rest) - 'magenta' is blurry.
I forgot to test 'PC' mode with HDMI-HDMI :devil: maybe you're right and this 'sub-sampling' bug occurs with YCC only, no matter of connection type. I'll test RGB input with HDMI-HDMI tomorrow.
The levels are also seem to be correct in both Full RGB and [what? limited??] YCC. (There is no black crush and black isn't light gray...)
Yeah, there is no problem here since CCC 11.2 has been realized.
Turn off the dithering in MPC-HC and you will see the difference.
Do you mean (0) rounding?
Do you know what was his pixel format setting in the CCC?
No, sorry. You better ask Andy O himself.

[janos666]

Do you mean (0) rounding?

Yes. (Only for testing...)

@TheElix
As much as I know none of the Panasonic PDPs do. The G20 is certainly not, and I read the same about the VT30.
Samsung PDDs do but only in PC mode. And it's a little problematic because PC mode doesn't support 1080p24 playback at 96Hz, like the YCC modes does.

[Qaq]

I don't have enough time to answer everything else right now.
We just discuss if we able to set properly our devices to see all of EVR CP/VMR improvments :devil: :)

[Hera]

I had D3DFS off. Right clicked on video and enabled D3DFS so the next movie will start fullscreen.
The thing is, the fullscreen mode seekbar showed up on the CURRENT video which was not fullscreen.

[janos666]

There is still some kind of clipping or overflow problem with the CMS (I guess it's your interpolation shader). Try to use this (http://www.mediafire.com/?bb37bv80g4jmzys) ICM profile. I think the problem will be obvious with the "4-Color Clipping" video from the "AVSHD 709 test disk" but it also appears on real video contents: you get primary or secondary colors instead of full white.

Otherwise it's nice to see that this latest MPC-HC test build is able to run with float32 and 123^3, static ordered settings on my laptop. It was far from possible some months ago. It has only a 8600M GT.

[kostik]

can someone plzz upload the latest version? Medifire is making me trouble downloading.
Thanks

[CruNcher]

@JanWillem32

I experienced something on Win XP and VMR9 Renderless in MPC-HC im not sure if its normal and it seems it's DXVA related (in this case Cyberlinks DXVA), i opened 2 instances of a MBAFF H.264 to compare them switching between them in Full Window Mode the 2nd instance of MPC-HC had visible Aliasing (not sure if it came from the bicubic resize or the deinterlacing failing, though read why i think it can't be the resizing further down)
I tried the same with VMR9 Renderless (same bicubic resize shader) and Lav Cuvid (directly via Nvidias Nvcuvid API + Deinterlacing directly not over the renderer and not via DXVA @ all) and the effect is not visible on VMR9 Renderless so i guess it can't be the Resizing but the Realtime Deinterlacing failing on the renderer for 2 simultaneously opened render instances ?
So is anywhere explained that the DXVA VMR renderer deinterlacing can only be used on 1 open renderer instance and will fail or can fail (Hardware dependent ?) on a 2nd one ?
Maybe it's also something in Nvidias Driver forcing it to fail (saving shader execution time, 2x 1080i 25i->50p on a old 9800 GT VP2) though i wonder why it works without issues then via their own API (practically same shader utilization + memory copy) also the complexity isn't so high @ all i tried to reduce it as much as possible and i can playback both without issues via Nvcuvid side by side.

So in the end i had to learn i can't reliable compare MBAFF results with 2 opened MPC-HC instances using DXVA (at least for now tested with Cyberlinks DXVA) though it will work without issues via Nvcuvid (Decoder) in XP and MPC-HC VMR9 Renderless, not sure either yet if Vista/7, EVR and DXVA2 would change something with this configuration here.

Though also crazy is i can't see the MBAFF failing @ playback of both 1080i 25i->50p streams simultaneously (DXVA) only if i seek in 1 instance and go directly to the same frame and compare them by switching i see the aliasing in the 2nd instance (the first instance is always correctly displayed without any aliasing) @ playback i can't see any aliasing @ all (GPU Load 31%, Video Engine Load 92%, Memory Controller Load 20%, CPU 2-4% Sandy Bridge system). If i try the same simultaneous playback with VP2 and Nvcuvid via Lav Cuvid its super slow though and both instances stutter like hell (memory copy seems to kill this for XP and 9800 GT overhead of Nvcuvid might be to high also optimization level for Lav Cuvid plays into this result most probably, Vista/7 and EVR might be more efficient here).

[JanWillem32]

@G_M_C: 10-bit output and xvYCC output are separate things.
10-bit output capable hardware has been around for some time. Indeed, the workstation cards have been capable for a much longer period, but there are plenty of regular video cards that can use it too.
http://en.wikipedia.org/wiki/Deep_Color
The two xvYCC standards are a "trick" to get more colors encoded inside 8- to 16-bit Y'CbCr: they use the same matrices as bt.709 [HD] and bt.601 [SD], but decode to [0, 255], [1, 255] and [1, 255] intervals, instead of [16, 235], [16, 240] and [16, 240]. This solution isn't as clean as the DCI and studio formats that have always been full range to begin with.
I'll have to see if I can get Y'CbCr and xvYCC encoding working for the video card output. I've only been able to correctly decode them to RGB so far.
As a basic answer: xvYCC modes can encode more colors than Y'CbCr, but it's still less than wide gamut RGB and XYZ encodes. Only the 10-bit output or better can eliminate banding, xvYCC and such can't help with that.

@Qaq: There's also little to gain by 10-bit or better input on devices with panels that are just 8-bit. Only the processor gets a better quality input in such a case, but it's inevitable that the panel will still show banding (or dithering).

@TheElix: HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be 8- to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with 8- to 12-bit color, but devices don't have to support it (the same behavior as with HDMI 1.3 is allowed).

@Hera: If it were up to me, I'd allow immediate switching of the exclusive mode (it's not that hard to do). Unfortunately, the implementation in the options screen makes that a bit hard. I'm not sure if this will be fixed anytime soon.

@janos666: The interpolation is a simple bilinear:
s1 = tex3D(LUT3D, (s1.rgb*LUT3Dsize+.5)/(LUT3Dsize+1.));
float4 s1 == output register, fn tex3D == sampling function for a 3D sampling register, sampler LUT3D == sampling register holding the LUT3D texture, float3 from float4 s1.rgb == sampled pixel from the video, LUT3Dsize can be defined as 64, 128 or 256.
The format adaptation is required, because DirectX 10/11 maps the first and last pixels to 0 and 1, but DirectX 9 maps them to [0+.5*dx, 1-.5*dx].
In the case of a 256³ pixels 3DLUT this means that the the vectors are 257 units long inside [0, 1], the first pixel is at point (.5, .5, .5), the last is at point (256.5, 256.5, 256.5).
I don't think I've made an error in my calculations, but I can still check the LCMS settings. I can look up color data directly from the generated 3DLUT table with that profile you linked. I will do so soon.
The primary reason I've been updating the renderer is primarily because the original was so very inefficient. I've been making some progress it seems.

@kostik: That again... I'll upload a new version once I've produced a build that works reasonably. We'll see if that download poses a problem then and how to solve it.

@CruNcher: http://www.anandtech.com/Show/Index/4380?cPage=2&all=False&sort=0&page=11&slug=discrete-htpc-gpus-shootout
GPU's also have a maximum to what they can process in DXVA mode. It's already very well known that some low-end GPU's lack adaptive deinterlacing modes, because they don't have enough power on the shader core. It could be that your GPU can't handle the strain of two simultaneous decoding and rendering sessions (or the driver assumes that). Next, it automatically takes a step back in deinterlacing quality.

I've re-written the vertex management for the rendering engine. It wasn't easy, but I do have lower GPU, CPU and memory usage now.
The reason I've not yet released a build with it is because of the subtitle renderer. The subtitle renderer has a very big problem that causes unwanted swapping between video and system memory. I've yet to solve that. If it takes any longer to solve the problem, I'll make an intermediate build without the subtitle renderer updates.

[CruNcher]

@CruNcher: http://www.anandtech.com/Show/Index/4380?cPage=2&all=False&sort=0&page=11&slug=discrete-htpc-gpus-shootout
GPU's also have a maximum to what they can process in DXVA mode. It's already very well known that some low-end GPU's lack adaptive deinterlacing modes, because they don't have enough power on the shader core. It could be that your GPU can't handle the strain of two simultaneous decoding and rendering sessions (or the driver assumes that). Next, it automatically takes a step back in deinterlacing quality.

I know that very well, but GPU load is only 31% for both playing back @ the same time and 20% for 1 instance (both including bicubic MPC-HC shader) so their are massive gpu cycles in theory available only the VPU is loaded @ almost the max for 2 instances 91% 1 instance 48% that's why i find it strange that Nvidias adaptive deinterlace switching should take place on the 2nd render instance because of to low gpu resources available, though i will try this with more DXVA decoder and VMR9 renderless to see if its maybe Cyberlink Decoder dependent behavior, i would rather guess it's a VMR renderless and or DXVA limitation for now though never read about it, losing overlay yes depending on how much instances (i think max Nvidia driver limit is 4 for HD) but Deinterlacing was new.
And really strange @ playback simultaneously they look identical (though i better test with some MBAFF test patterns also, to be absolute sure) the problem only occurs when seeking frame by frame in both the 2nd instance then gets visible aliasing (that indeed could be overseen in motion) the first instance is ok (switching via ALT+TAB the aliasing only becomes visible in the 2nd opened VMR9 renderless MPC-HC instance @ the same frame, and @ playback both seem ok again (that indeed could be adaptive quality switching but GPU resources are still plenty available 70% so sure it could be also Nvidias driver assuming wrong here or maybe even GPU utilization playing no role @ all for the criteria of the switching algorithm, though hard coding that if 2 HD MBAFF streams are played @ the same time they never can be both vector adaptive deinterlaced seems not really efficient then and failing based on the stream complexity).

PS:
I've re-written the vertex management for the rendering engine. It wasn't easy, but I do have lower GPU, CPU and memory usage now.
The reason I've not yet released a build with it is because of the subtitle renderer. The subtitle renderer has a very big problem that causes unwanted swapping between video and system memory. I've yet to solve that. If it takes any longer to solve the problem, I'll make an intermediate build without the subtitle renderer updates.

Really great news, though with rendering engine you mean always everything above the renderer (color engine,dither engine,sync engine,shader engine) so not the VMR/EVR render and utilization performance itself ? :)

[JanWillem32]

If both instances are fine during playback, then there's no real problem. I know that the driver sometimes discards data during seeking (even with single instances). As long as the mixing is done in hardware by EVR or VMR-9, it doesn't matter if the source is DXVA or not in this case.

[CruNcher]

If both instances are fine during playback, then there's no real problem. I know that the driver sometimes discards data during seeking (even with single instances). As long as the mixing is done in hardware by EVR or VMR-9, it doesn't matter if the source is DXVA or not in this case.

Sounds not really good though then i don't understand why it works via Lav Cuvid (Nvcuvid) on VMR9 Renderless without Aliasing on the 2nd instance @ the same frame :( (Though Playback of both @ the same time is impossible obviously with it, compared to the DXVA input). Anyway i better really check this with a interlaced test pattern @ playback :(
Also the aliasing is not complete aliasing of the whole frame like you would expect from a interlaced 2 fields weaved playback it's just conditional aliasing @ a specific part of the frame that shows up in the 2nd instance (when switching between instances) though if you say it discards data randomly it might have discarded to deinterlace exactly that edge in the 2nd instance.
jesus il make a screen to visualize the problem that says more then 1000 words i guess :)


1st Instance
http://img84.imageshack.us/img84/2615/1stinstance.png

2nd Instance
http://img814.imageshack.us/img814/9189/2ndinstance.png

Input:
http://img851.imageshack.us/img851/4922/weaved.png

This was really making me crazy when comparing things then i realized it always happens on the 2nd instance ;)

[JanWillem32]

Instance 1 is an adaptive or a weave type of deinterlacing, instance 2 is bob (only a single field is shown, with its height doubled). A bob type is normal for progressive content, so I can understand it resets to this type and then start deinterlacing again when playback restarts.

[CruNcher]

Tried now with several DXVA Decoder all behave the same 1st instance adaptive 2nd instance bob with VMR9 Renderless
so till now only Nvcuvid seems to be able to force adaptive for multiple instances

[JanWillem32]

I can't really find documentation on Nvcuvid. I wonder if it correctly forces the mixer to deinterlace or does it by itself (color blending using an 8-bit 4:2:0 down-sampled Y'CbCr target surface really isn't my idea of proper rendering at all).

[Hera]

Is there a new build coming?
There is "something else" to (non-FP) stuttering - not sure whether it was something fixed in non-tester builds or something introduced in tester builds.

[JanWillem32]

My builds are a bit modified, and the original VSync code doesn't work too well with them. In my case, I still have tearing-free video in the three main modes. I just don't activate the regular VSync options.
Exclusive mode: D3D Full Screen Mode, 10-bit RGB Output, Full Floating Point Processing, Disable desktop composition (Aero).
Windowed mode with Aero: 10-bit RGB Output, Full Floating Point Processing.
Windowed mode without Aero: 10-bit RGB Output, Full Floating Point Processing, Disable desktop composition (Aero), Flush GPU Before VSync, Wait For Flushes. (The "Wait For Flushes" option delays one or two frames constantly, but it does present at a stable frame rate in my case.)

A new build is definitely coming soon. The vertex (draws the wire-frame models to render with) code hes been revised completely, the performance and efficiency gains are quite good. I'm only held back by the subtitle renderer: it copies every small rendered item from the video memory to the system memory, and makes a full-screen copy of every fully rendered frame to the video memory again for presentation. That's really inefficient, of course.

[TheElix]

Jan, I think you're aware of this but I wanted to remind you. I have an ATI card and I have this: http://screenshotcomparison.com/comparison/62400
Your shaders fix this but not everyone knows how to use them. So I think it should be fixed some time.

Any plans on implementing more advanced resizers? With some of these (http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/sup_images/index.html) (esp. Glasner et. al. [2009] and Geniue Fractals (TM)) or others (http://www.cs.brown.edu/courses/csci1950-g/results/final/pachecoj/) properly implemented I doubt anyone watching SD video would want to switch back to other players.

[JanWillem32]

Nearest neighbor sampling is a valid way to scale images. It's not the most visually pleasing one of course, but neither is the usual bilinear filter.
When the ATi driver faces anything but the standard 8-bit surfaces for the EVR/VMR mixer output, it disables the bilinear filtering, and uses nearest neighbor instead. If I could simply force the mixer to use a custom scaler for chroma, I would have integrated chroma scaling shaders a long time ago (and I would have written a few other special scalers for it). Unfortunately, the mixer parts are rather inflexible. Any big mixer change would firstly require me to separate the VMR-9 r. and EVR CP renderers. Next, writing custom mixer items requires a good understanding of the DirectShow stages in the video mixing engine, and that's something I lack. It is possible to write, though. The two best examples: MadVR has a mixer that can handle YV12 and NV12, the Haali renderer can use YUY2 and RGB32.

New interpolation methods and porting already finished ones to the various filters that require it will take some time. I'm very busy with the subtitle renderer at the moment, and it's just horrible.
Also, new interpolation methods require a lot of documentation on the math, algorithms and programming before I can integrate something. That information is quite hard to come by.
I've seen a lot of code that feature very archaic programming for graphics processing. A lot of times I wonder if the programmer that wrote it ever heard of something basic as SSE or SIMD at all. I've even seen code that uses the slowest kind of integer math in the graphics processing code (CPU-based), like the code common for a 16-bit DOS program. When doing any graphics programming, parallelization, vector and matrix math is really important for performance, and no compiler will just magically convert code to really take advantage of these things automatically.

I'm a bit frustrated by the badly written code that I'm working on at the moment... I've been wanting to release a reasonably stable tester build for over two weeks already.

[TheElix]

Your post is very informative as usual, thanks. Don't give up on that code and Eureka will surely visit you. :)

[TheElix]

Jan, might it be possible to include a fix in the next version for being able to save Autochange fullscreen monitor mode settings? Because if you untick this option and close the player they will be reset to defaults.

[JanWillem32]

This is more a general issue of the options screen, but I can give it a go. Note that problems reported and handled on trac are generally solved and integrated faster than anything I write, though. I gave the shader menus some improved functionality some time ago, I guess this one shouldn't be too hard for me to fix.

[TheElix]

Thanks! :o I didn't know it was a general issue of MPC-HC's builds.

[TheElix]

Hey, Jan! This annoying issue has been presumably fixed: http://sourceforge.net/apps/trac/mpc-hc/ticket/1493
Be sure to include the fix in your next build!

[G_M_C]

Ahhh, that might also be the fix for what we discussed/noticed earlier;

Has someone else noticed that when you look at the CTRL-J / stats screen, it wont seem to go away anymore (pressing CTRL-J multiple times doesnt remove the stats anymore) ?

And i only get the short stats screen (the one with only framerate etc, not the one with output/the graph etc).

(Win 7 64, running MPC-HT 32 bit)

Same here, it's like if I've pressed a button two or three times, while in reality it's only once. I only get this in exclusive mode, and it can sometimes be solved after the first mouse click, but not always. I've had this problem for quite some time now (not only in the builds I modified). I wonder what part of the program it is that can make it so sensitive to keystrokes.
[...]