Media Player Classic Home Cinema (MPC-HC) - DXVA!

[Polcius]

@Polcius The setup I described is valid for Vista and 7 only. For windows XP the color control is quite a bit different:
http://articles.techrepublic.com.com/5100-22_11-5965505.html

For screenshots, that will be a problem, unless you can read Dutch.

I'm using Win7.

Actually, I can read a bit of dutch XD

[JanWillem32]

Very well, here they are in correct order:

To disable the service, just run "services.msc" .
It should be easy enough to choose "disabled" there.

[hayan]

Full Stats OSD messages(ctrl+J) need 1420x790+ display space, unfriendly on the small Mon (800x600 & 1024x768) or video (SD video).

Feature request:

Limit the Stats OSD messages proportion on video display range

Adaptive resize the Stats OSD messages range
or
Use small(50%) font size on little display range.

[renq]

Perhaps a noobish question, but is it possible to rotate videos?

[Polcius]

Very well, here they are in correct order:
User advanced
http://www.mediafire.com/?056dc48f0fdu711
System device
http://www.mediafire.com/?rqodz1a4zblq2ko
System advanced
http://www.mediafire.com/?nckf0gxsd3p5bb9
User device
http://www.mediafire.com/?t2vr868dpj2areb

To disable the service, just run "services.msc" .
It should be easy enough to choose "disabled" there.

Thanks

[JanWillem32]

@renq Yes, but currently only by using the video card's rotation option in the control panel.
@Polcius You're welcome. Good luck on the setup, and try to avoid the "absolute" settings, many profiles don't support absolute rendering intents.

[hissatsu]

Fix: playback seamless BD;
Add: PGS subtitles name and language;
Patch by Sebastiii;


Unfortunately, I don't think it could be called "fixed". Specifically, for me at least it's broken seeking for single m2ts files. The seeking appears to work fine, but it doesn't. The timer is sometimes way off. You can jump to a point where it's says 3:45 on the timer, yet it actually playing back something several second earlier/later. If you're playing an external subtitle file, it's very obvious. It will be synced as long as you don't seek, then you seek and it's way off. If I go back to any version before 2804, it's OK.

[Polcius]

@renq Yes, but currently only by using the video card's rotation option in the control panel.
@Polcius You're welcome. Good luck on the setup, and try to avoid the "absolute" settings, many profiles don't support absolute rendering intents.

No, I'm using perceptual all the time.

Ok, I ran some fresh tests (attached) in wich you can see that MPC's color management is "broken"; it totally messes up the gamma, and doesn't seem to do much with the primaries.

[niksus]

@renq Yes, but currently only by using the video card's rotation option in the control panel. You are wrong here. Try Alt+NumPad keys.

[XebelBit]

Hello!
I have problems with many .flv files and DXVA. Either MPC-HC crashes, doesn't play the video or produces visual errors at the bottom of the picture. I have a GeForce 8400 GS, WinXP SP3, MPC-HC 1.4.2499.0. I have tried different renderers. It seems to work fine if DXVA is not used. What is my problem with DXVA? Can I fix it?

[betaking]

Hello!
I have problems with many .flv files and DXVA. Either MPC-HC crashes, doesn't play the video or produces visual errors at the bottom of the picture. I have a GeForce 8400 GS, WinXP SP3, MPC-HC 1.4.2499.0. I have tried different renderers. It seems to work fine if DXVA is not used. What is my problem with DXVA? Can I fix it?

http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-4-2808.html
download svn build form here!

[pbmtp]

Hi,

here is a little bug:

When "toggle screen space shader" shortcut or menu is used an empty OSD is displayed

[tetsuo55]

Here (http://vbm.omertabeyond.com/stuff/patches/mpc-hc.r2808.VS2010.SSE2.10-bit.out.samplers.D65.and.surfaces.7z) is a test-build with the following changes:


-disable overfiltering for all pixel shaders (the code that allows changeable types of sampler states have yet to be found )
-generating mipmaps for textures is only useful for rendering in 3D, in pure 2D, it just wastes memory and processing.
-extend the precision to the CIE D65 standard values
-detection of the floating point surface format
-allow 10-bit RGB output, without allowing the D3DDISPLAYMODE to override the display color format settings set with D3DDISPLAYMODEEX.

So in short: This build should lower the overhead on GPU slightly for EVR-CP/VMR9-R, but also OSD and subtitles. Fix the 10bit RGB not working problems and make shader scalers more accurate.

Once we have some confirmation that there are not regressions these changes will be committed.
I would especially like to hear from yesgrey and leeperry

EDIT: please note that "bilinear" in the output settings does not work in this build, the image will be scaled using nearest neighbour, the PS2.0 scalers all do work now though and better than before.

[XebelBit]

http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-4-2808.html
download svn build form here!

Thank you for your answer.
I've tried it. The problems remain with this svn build.

[janos666]

Fix the 10bit RGB not working problems and make shader scalers more accurate.

Once we have some confirmation that there are not regressions these changes will be committed.


GPU: HD5850
Driver: 10.12 WHQL
OS: Win7 x64 (with every OS, DX, .NET, C++Redist updates)
Display: Dell U2410 with DP connection (tested with FirePro V5700 and PhotoShop CS5 -> 10 bit/color WORKS)

MPC-HC build1824: 10-bit works (according to the OSD, at least, but looks good, so may be dithering only, I am not sure...)

Output range: 0-255 (I think this limited->full range conversation causes the visible banding because 16-235 is always smooth)

Windowed mode, Aero enabled, 10-bit in, 10-bit out, FFPP enabled ---> BANDING ------------- OSD -> Surface Unknown ;;;;;;;; Backbuffer A2R10G10B10 ł Display Unknown
Windowed mode, Aero disabled, 10-bit in, 10-bit out, FFPP enabled ---> BANDING ------------- OSD -> Surface Unknown ;;;;;;;; Backbuffer A2R10G10B10 ł Display Unknown
D3DFS mode, Aero disabled, 10-bit in, 10-bit out, FFPP enabled ------> SMOOTH GRADIET --- OSD -> Surface A16B16G16R16F ; Backbuffer A2R10G10B10 ł Display A2R10G10B10

/// I never saw this A16B16G16R16F format before. Does the F stands for Float (16-bit floating point)?

Drawbacks: I have to hit Ctrl+Alt+Del after I stop the playback to get back my desktop (black screen after the playback stops).

The gray gradient test pattern looks very nice in third case. I think you should definitely include these changes!
May be the D3DFS warning message should contain the notice about this Ctrl+Alt+Del thing or you should find another fix/workaround.

Edit: OSD picture (http://prohardver.hu/dl/upc/2011-01/35956_222.png) (PrintSreen won't work here...)

Now, the only remaining issue that CMS doesn't apply (proper or any) black point compensation. :rolleyes: (Adobe CMS and yCMS works better for me with relatively low contrast LCDs, like 950:1)

[JanWillem32]

Thanks for your reply. What settings do you further use that may cause "Unknown" format on the Surface and Display items?
A16B16G16R16F is indeed a format of 16-bit floating points. In DirectX 9 it's only allowed on surfaces, not for the backbuffer and display.
The black screen on exit problem is currently being worked on, at the moment I can only advise you to map a hotkey to "reload display driver" in the video card's control panel.

[janos666]

Thanks for your reply. What settings do you further use that may cause "Unknown" format on the Surface and Display items?


I have no idea and I don't want to investigate it too much further because I would use the FS mode anyway.


A16B16G16R16F is indeed a format of 16-bit floating points. In DirectX 9 it's only allowed on surfaces, not for the backbuffer and display.
looks like it can cause problems during exit.


Is it theoretically possible to push EVR further (16-bit buffers) on DX11 cards? (Not a request, only curiosity.)


The black screen on exit problem is currently being worked on, at the moment I can only advise you to map a hotkey to "reload display driver" in the video card's control panel.
looks like it can cause problems during exit.


I think the "Disable Desktop composition (Aero)" caused this. I don't need to hit ct+al+del anymore since I disabled it.
I think it wouldn't make any difference in D3DFS mode but it looks like it can cause problems during exit (may be Aero would reinitialize before the display mode changes...?).

[janos666]

Bad news, but I am not sure if we really achieved a proper 10-bit output yet. :(

Before this patch, "10-bit input" without "10-bit output" produced a relatively smooth gradient without visible banding (via dithering ; Note that am talking about 0-255 output here... 16-235 is always smooth...).

Now, "10-bit output" without "10-bit input" produces banding while the OSD still shows the same stats: 16-bit surface, 10-bit buffers, 10-bit display.

May be the OSD shows false stats. But why do I have banding (caused by the 16-235 --> 0-255 conversion) without the "10-bit input" option?
It theoretically receives undithered 8-bit data (native source bit depth), processes in 16-bit FP, and outputs 10-bit. Dithered or not..., but undithered 10-bit should always look significantly smoother than undithered 8-bit, and I should see a relatively smooth gradient even with dithered 8 bit while undithered 10-bit should be (at least) as smooth as the dithered 8-bit (when dithered from 10-bit), right?.?

This let me think that the combination of the "10-bit input" and "10-bit output" produces the same dithered 8-bit output as the "10-bit input" without the "10-bit output".

Or did I misunderstand something?

10-bit output = send 10 bit/color to the device (not padded, not dithered, but real 0-1024 range per components?)
10-bit input = ??? - Somebody said, it asks 10-bit from the decoder. Why...? Source is 8-bit any I don't want any image manipulation on the decoder side. I want to output 10-bit after the image manipulations on the renderer side (like level conversion, CMS, etc.)

Is this "trick" (10-bit input) required to force EVR to work with 10-bit data? Or what...?
Do I still need to live with the software dithering, even I get real 10 bit/color output?

But do I really get it...?
In this situations when "10-bit input" produces smooth gradient alone (with both 8 and 10 bit output) and "10-bit output" doesn't make any noticeable difference alone (there is no improvement without "10-bit input" but "10-bit input" helps without "10-bit output"...) I can't really tell if 10-bit really works or not.

Does anybody have a 10-bit test image, encoded with the "10-bit x264 coded"?
I should make it clear:
- If it's smooth, then 10-bit output works.
- If it looks like a 8-bit image, it doesn't.

Or somebody else may be able to check it. My display doesn't tell me anything about it, but I know that some displays indicate the input bit depth in their OSDs (of couse, it can be false and effectively 8 bit, but good to start the "debug"...)

[JanWillem32]

Thanks for the input. It's true that getting the mostly fixed-to-8-bit rendering engine to do other formats, requires some tinkering. Your computer is probably powerful enough to run heavy test builds, so if you're interested, you can try them.
I compiled two 64-bit versions, one with dither, one without. I also added a separate debanding shader (that doesn't use dithering), use it to smooth out the input video before the display step. The video is slightly unstable at the start with these two versions, it should improve in a matter of seconds. It might need 3D clocks on on some GPUs to run smoothly.
The 4×32-bit floating point surface format is just experimental, not for implementation in the near future, to make that clear.
The 10-bit input item is a bit tricky. In my case it fails at chroma up-sampling, so I use a separate shader to do that. 10-bit input can help to maintain more data when the video Y'CbCr data is converted to RGB. If the conversion is done in 8-bit, a lot of data from in-between values is lost. The result of that is banding.

By the way, more changes are underway from the entire development team, of course. This build is just my attempt to help improve the handling of the DirectX 9 video processing chain.

[janos666]

I compiled two 64-bit versions, one with dither, one without.


The one with the dithering enabled doesn't seem to work as intended: "10-bit input" without "10-bit output" doesn't produce a smooth gradient as older versions did. I got 32-bit surface with 8-bit backbuffers and 8-bit display, and banding with 0-255 output range.

But the experiment was successful: If you really disabled the dithering in the corresponding build, then I really got a 10 bit/color display mode. I got 32-bit surface, 10-bit backbuffers and 10-bit display, and a smooth gradient.

It would be nice to have a GUI option (in later release versions) to enable/disable dithering.


And I think I found the problem which caused the Unknown format reports.
I have to start the playback by dragging and dropping the file on the mpc-hc.exe itself. I also got some D3D allocation errors with various settings when I tried to drag and drop the files to an MPC-HC window (even if it was a "clean" instance which didn't do anything after I launched it...).


I also added a separate debanding shader (that doesn't use dithering), use it to smooth out the input video before the display step.


I didn't try it yet. I watched a 8-bit gray gradient test image and there were no any banding with 10-bit input and output.


The 4×32-bit floating point surface format is just experimental, not for implementation in the near future, to make that clear.


It's up to your decision but it works fine here.
May be you should make it available by the renderer settings menu if it can make any difference (at least theoretically, because I think it won't help with 10-bit buffers).


The 10-bit input item is a bit tricky. In my case it fails at chroma up-sampling, so I use a separate shader to do that.


Yes, I noticed it. I tried to use your chroma upsample shader but the overall result is still far from madVR's quality.


10-bit input can help to maintain more data when the video Y'CbCr data is converted to RGB.


It starts to make sense if it stands for the bit depth of the RGB values after the YCC->RGB conversion.

Silly me... I thought this YCC->RGB conversion (when I feed the renderer with NV12 -> Why doesn't it accept YV12, by the way?) is part of the "Full Floating Point Processing" and such, it's always processed with 16-bit FP precision and saved as 10-bit RGB with 10-bit backbuffer settings. And yes, "10-bit output" alone doesn't trigger the 10-bit backbuffers with these versions, so...

But wait... The gradient is always smooth with 16-235 RGB settings. How does it possible?
I can understand that 8-bit YCC -> 10-bit RGB is better than 8-bit YCC -> 8-bit RGB. But why 8-bit YCC -> 8-bit RGB Limited is better than 8-bit YCC -> 8-bit RGB Full? (And no just better but "perfect"?)
YCC and RGB are different color spaces and the ranges are different anyway (different chroma and luma range in YCC - or am I wrong and do they match?), so it doesn't make sense that the gradient is perfectly smooth with limited RGB but shows heavy banding with full RGB.

But newer mind, it seems to works now (the gradient is smooth with 0-255 too). But there is a lot to do until you get close to madVR, if it's even possible with the predestines EVR limitations.


This build is just my attempt to help improve the handling of the DirectX 9 video processing chain.


I think it's good.
There are no D3D allocation or Unknown format errors with usual launch.
But may be you should check the dithering with 10-bit in, 8-bit out. I can't remember if it worked with the previous version or not.

[joe42]

An excerpt from Anand's Sandy Bridge review,

http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-2100-tested/7

The limitation is entirely in hardware, particularly in what’s supported by the 5-series PCH (remember that display output is routed from the processor’s GPU to the video outputs via the PCH). One side effect of trying to maintain Intel’s aggressive tick-tock release cadence is there’s a lot of design reuse. While Sandy Bridge was a significant architectural redesign, the risk was mitigated by reusing much of the 5-series PCH design. As a result, the hardware limitation that prevented a 23.976Hz refresh rate made its way into the 6-series PCH before Intel discovered the root cause.

....

Intel has committed to addressing the problem in the next major platform revision, which unfortunately seems to be Ivy Bridge in 2012. There is a short-term solution for HTPC users absolutely set on Sandy Bridge. Intel has a software workaround that enables 23.97Hz output. There’s still a frame rate mismatch at 23.97Hz, but it would be significantly reduced compared to the current 24.000Hz-only situation.

MPC-HC Compatibility Problems

Just a heads up. Media Player Classic Home Cinema doesn't currently play well with Sandy Bridge. Enabling DXVA acceleration in MPC-HC will cause stuttering and image quality issues during playback. It's an issue with MPC-HC and not properly detecting SNB as far as I know. Intel has reached out to the developer for a fix.


Hmm, so now there is a software kludge for Intel HD Graphics to output at 23.97 Hz instead of 23.976 Hz. If my calculations are correct, that changes it from a repeated frame every 42sec to a skipped frame every 167 seconds. I wonder how much better that will look.

That part about Intel reaching out to "the developer" of MPC-HC is odd. Who did they talk to? Is Intel contributing code for MPC-HC?

[bobdynlan]

joe42, there is no spoon. In other words, I'll bet D3DFS fooled you into thinking you've got 10bit smooth output, but instead what happened was that D3DFS switched 16-235 on. And there is the display itself that does on-the-fly adjustments even if you set it at certain figures. Did you notice a slight drop in brightness level? Because that's what happens when 16-235 goes on. And please note that windowed tests are irrelevant, this whole 10-bit thing works only on full-screen mode. After ~2h of staring at a solar eclipse, my conclusion might be wrong :cool:

Anyway, this whole FP thing does little thing for 8-bit displays at the moment, and that is where the resources should be spent, not for the 0.05% 10-bit capable (not advertised) hardware, users have. Maybe it's time for a dither implementation, now that direct processing sort of works, JanWillem32? :thanks:

[joe42]

joe42, there is no spoon.

There is no joe42 in the rest of that conversation, either.

[janos666]

joe42, there is no spoon.


I think I will answare these on behalf of joe42. :p


In other words, I'll bet D3DFS fooled you into thinking you've got 10bit smooth output, but instead what happened was that D3DFS switched 16-235 on. And there is the display itself that does on-the-fly adjustments even if you set it at certain figures. Did you notice a slight drop in brightness level? Because that's what happens when 16-235 goes on.


I don't think so.
Almost everything can happen when I connect my display to my Radeon HD5850 with a HDMI cable: PC-TV level mismatch (ignored pixel format settings and chaotic PC->TV conversions with HDTV resolutions), double-corrected (desaturated) colors with the xvYCC mode, and other random things (like a small flickering in every ~20 minutes).
But it's absolutely stable and reasonable with DisplayPort connection. The driver doesn't think that it has to be a smartass and deal with a broken player software and HDTV combo, and the display doesn't think that it fights against a broken media player which thinks that it has a dirty business with a broken HDTV; or God knows why the hell they do these chaotic things. http://prohardver.hu/dl/s/n2.gif

On the other hand... The display works with a 12-bit controller, so I guess it would do a nice job with a TV-PC level conversion.
But the possibility that EVR could tell the display to do this expansion and it really did it... almost zero... (May be with HDMI connection and the help of this solar eclipse but only once in a lifetime...)

It's an LCD with ~950:1 contrast ratio. It's far from perfect but only "acceptable" for me. So, it's easy to tell if 0-16 values are cut or not. Dark tones would be really bright grays then.


And please note that windowed tests are irrelevant, this whole 10-bit thing works only on full-screen mode. After ~2h of staring at a solar eclipse, my conclusion might be wrong :cool:

Anyway, this whole FP thing does little thing for 8-bit displays at the moment, and that is where the resources should be spent, not for the 0.05% 10-bit capable (not advertised) hardware, users have. Maybe it's time for a dither implementation, now that direct processing sort of works, JanWillem32? :thanks:


If you would read everything I wrote on that post you may know that...
The "10-bit input" without the "10-bit output" used 10-bit RGB and dithered it back to 8-bit display output (older builds, not these test versions) and caused a smooth gradient.

And it also worked with windowed mode! You need the D3DFS mode for real 10-bit display mode but it isn't necessary for 10-bit processing and dithering until the display mode is the usual 8-bit. (At least as I can remember. I used to watch movies with madVR, I am just here to do some experiment with 10-bit and XYZ-LUT based CMS.)

Why do you think that it wasn't 10-bit?
The hardwares are capable, the software is theoretically capable and it looks like it works. Why can't you believe if it worked? Didn't it work for you with a TN display or an expensive but unfortunately incompatible HDTV, or what?

[bobdynlan]

Sry joe42 It's easy to get disoriented with all these clone-type names :) janos666, you are right. After all those panel lotteries going on, I did not expect any change in the business model to favour the customer. So it's an 8-bit panel with dither advertised as 10-bit, but it still works better in Photoshop than in MPC-HC?! It's hard to find a professional display here, I will search some more.

[JanWillem32]

The higher than 8-bit processing formats are quite useful if you have to: extend Y'CbCr values to full range, up-scale chroma resolutions, convert Y'CbCr formats to RGB formats, convert input gamma functions, scale video resolutions, apply display output gamma functions(+color corrections), and any other kinds of filtering applied besides that. Each of those steps can change the color values enormously of an original pixel. Using a limited processing format of 8-bit will truncate the original output of each step to 8-bit, causing inaccurate rounding.
Another thing is dithering. If the ditherer receives an input format with the same accuracy as the output format, it shouldn't activate at all. Dithering should be done by selectively rounding in-between values up or down from the input format to the output format. If the the processing format doesn't deliver those bits, there's nothing to round up or down anymore.
I also don't like the current type of dithering. The color resolutions it can use are okay, even for 10-bit output, but the method suits still image dithering the most. I tried to write a ditherer that uses a different method in a pixel shader, but it's very hard to get it just right, also considering the temporal dithering issues. I agree that the usage and type of dithering should be user-selectable (maybe even with the GPU/CPU processing costs indicated in the menu).
I worked quite a bit on making it possible to render with only 4×fp32 surfaces (the maximum allowed surface format in DirectX 9). Later on, it will be important to choose what formats are sane for 10-bit output, 8-bit output and 8-bit output on slower machines.
I'm already satisfied with the current handling of the 10-bit backbuffer and display formats. The only big problem is that exiting video from D3DFS with 10-bit output can cause black or darkened screens, but I think that can be solved in a while. (Build 1824 had the same problem.)

[Ingram]

MPC-HC has started doing some weird stuff with going into fullscreen mode on my Windows 7 HTPC with v1.4.2499. I've never seen it before until I switched to W7. Basically I go into fullscreen mode, but the left edges and bottom edges are still displaying the windows desktop in the background. If I exit and go back into fullscreen 2-3 times it eventually fixes itself.

Any solutions?

Edit: It seems it doesn't do it when you go from a non-maximised window to fullscren. But if the window is maximised and you enter fullscreen mode the problem is there.

This is occurring while watching a 720P MKV with DXVA. Not sure if it does it with Avi or non-DXVA yet.

[namaiki]

What is your system font set at? Also, are you using the 32-bit or 64-bit build of MPC-HC? How many monitors are being used? Which video renderer is being used?

[JanWillem32]

Ingram, what display driver are you using? It sounds like the backbuffer isn't cleared automatically. Try the VMR-9 (renderless), EVR-CP and EVR Sync. renderers. Of those I'm sure they clean up of the buffers quite properly.

[mark0077]

MPC-HC has started doing some weird stuff with going into fullscreen mode on my Windows 7 HTPC with v1.4.2499. I've never seen it before until I switched to W7. Basically I go into fullscreen mode, but the left edges and bottom edges are still displaying the windows desktop in the background. If I exit and go back into fullscreen 2-3 times it eventually fixes itself.

Any solutions?

Edit: It seems it doesn't do it when you go from a non-maximised window to fullscren. But if the window is maximised and you enter fullscreen mode the problem is there.

This is occurring while watching a 720P MKV with DXVA. Not sure if it does it with Avi or non-DXVA yet.

Yes I reported this ages ago, only happens with the evr renderers. Doesn't occur with madVR, and yes it doesn't happen from a non maximized window. I have 1 monitor, windows 7 64bit, nvidia gtx295 in my case.

[Mercury_22]

Revision 2809 - Directory Listing
Modified Tue Jan 4 12:41:20 2011 UTC (75 minutes, 48 seconds ago) by aleksoid

Add : MPC Audio Renderer - select audio device;
@aleksoid can you please also correct the default "Speaker configuration for 8 input channels" in the custom matrix ?

Because when "Enable custom channel mapping" it's enable the default mapping for 8 channels it's wrong = channel 7 it's mapped to "Front Left of Center" instead of "Back Left" and channel 8 it's mapped to "Front Right of Center" instead of "Back Right"

When "Enable custom channel mapping" it's not enable the mapping it's correct !

[Ingram]

Yes I reported this ages ago, only happens with the evr renderers. Doesn't occur with madVR, and yes it doesn't happen from a non maximized window. I have 1 monitor, windows 7 64bit, nvidia gtx295 in my case.

I'm using EVR Sync with Reclock controlling VSync, Win 7 64Bit and Ati 10.12 drivers. Also just the one monitor.

As for system font, default? I've not touched it.

[janos666]

Sry joe42So it's an 8-bit panel with dither advertised as 10-bit, but it still works better in Photoshop than in MPC-HC?!

Yes, the LCD panel receives 10-bit values and it visualizes them via A-FRC (some kind of dithering). But it's very hard to notice from usual viewing distance, it's not as noisy as madVR but I think it's enough for me (according to my experiments with PhotoShop CS5 and HQ XYZ-LUT profiles).

But take a look at some 6+2 bit TN panels. They are significantly better than simple 6-bit TN panels. When you do 8+2 bit, the side-effect is much weaker.
And there is internal processing. It's better to feed the display with 10-bit before it starts to send it though the 12-bit internal LUT and correct the WP according the R,G,B Gains.

And may be I will get a real 10-bit panel in the "not too distant future". The current dithering is enough to test the possibilities (software side) and judge if it's worth some money or not (visible or not).

[nevcairiel]

B
10-bit input = ??? - Somebody said, it asks 10-bit from the decoder. Why...? Source is 8-bit any I don't want any image manipulation on the decoder side. I want to output 10-bit after the image manipulations on the renderer side (like level conversion, CMS, etc.)

The EVR consists of two components, the EVR Mixer and the EVR Presenter. The Mixer talks to the decoder, and can mix multiple video streams onto each other, before passing them on to the Presenter. The Mixer is also responsible for color space conversion. The Presenter is then responsible for showing the samples at the correct time.

MPC-HC uses the default Microsoft EVR Mixer.

The MPC-HC EVR Presenter only accepts RGB input, so it lets the Mixer do the YUV->RGB conversion. By Forcing 10-bit Input, it trys to get the Mixer to output 10bit data of this conversion, and hopefully also process it internally at this level (it might do float processing internally anyway, or use the output format, i don't think MS ever exposed those details). It does not affect the output from the decoder.

[Fadeout]

Is there a list of ATI cards and what H264 decoding is supported on them?

For example I know that my 4850 can deal even with 1080p at L5.1 and I want to know economic models on sale now that supports all kinds of formats.

[nevcairiel]

http://en.wikipedia.org/wiki/Unified_Video_Decoder

All versions of UVD should support H264 decoding. Best results you'll get with all UVD 2.2 or UVD 3 models, of course.
Also don't forget that you might need performance to do rescaling and deinterlacing on the GPU, however the 5450 appears to handle that just fine already (lowest card in the 5xxx series)

[Fadeout]

Yes, I was more worried about the specifics. For example it seems some cards can't handle 1080p L5.1, or can't handle more than 8 ref frames.

It seemed that it didn't depend entirely on just the chip. Mine has just UVD 2 and can read everything (beside LQ, which is a driver thing). Some other cards seem to work fine only up to L4.1.

So could a 5450 do 1080p with L5.1 and 16 ref frames like mine?

[hoborg]

Yes, I was more worried about the specifics. For example it seems some cards can't handle 1080p L5.1, or can't handle more than 8 ref frames.

It seemed that it didn't depend entirely on just the chip. Mine has just UVD 2 and can read everything (beside LQ, which is a driver thing). Some other cards seem to work fine only up to L4.1.

So could a 5450 do 1080p with L5.1 and 16 ref frames like mine?

Yes. Just remember you will need DxVA 2.0 OS (Vista/Win7).

[G_M_C]

Just saw this (SDK documentation for AMD/Ati Open Video Decode API) (http://developer.amd.com/gpu/ATIStreamSDK/assets/OpenVideo_Decode_API.PDF) and wondered if this is interesting to you guys.

JanWillem: Ik volg je vorderingen met grote interesse. Ben benieuwd hoe eea uit zal gaan komen in MPC-HT !

[mariner]

Yes, I was more worried about the specifics. For example it seems some cards can't handle 1080p L5.1, or can't handle more than 8 ref frames.

It seemed that it didn't depend entirely on just the chip. Mine has just UVD 2 and can read everything (beside LQ, which is a driver thing). Some other cards seem to work fine only up to L4.1.

So could a 5450 do 1080p with L5.1 and 16 ref frames like mine?

Greetings Fadeout.

micksh is doing some UVD3 testing which may be of interest to you.

http://www.avsforum.com/avs-vb/showpost.php?p=19768867&postcount=120

[a_afra]

@Polcius The general Windows color system has to be configured so that the profile is installed and marked as default system-wide, but without directly applying it.

No, you have to enable "Windows display calibration"! If you disable it, the calibration LUT from the ICC profile will not be applied, and you will get incorrect colors. This feature is a simple LUT loader. If you don't want to use it, you have to use a third party LUT loader program (your calibration software should have one). It's really simple.

Also, you can't apply a correction twice. Even if you have two active LUT loaders, both will replace the current LUT of the GPU with the one inside the ICC profile.

[a_afra]

I worked quite a bit on making it possible to render with only 4×fp32 surfaces (the maximum allowed surface format in DirectX 9). Later on, it will be important to choose what formats are sane for 10-bit output, 8-bit output and 8-bit output on slower machines.


I think fp32 surfaces are a complete waste of resources. It's overkill even for real 10-bit displays. There is no discernable difference in image quality compared to fp16.

[hekoheko]

Hi!

I have following problem.
When outputting 1080p24 to my TV, video jumps/drops one frame. This is with 23,976fps x264 mkv files and 24hz refresh rate.
It's something to do with "sync offset", the green line jumps and corrects (?) audio and video synchronization...?
When outputting 1080p60 everything is fine except the awful pulldown judder.

Here is a small video demonstration:

http://www.youtube.com/watch?v=lYZ3UoTTxXg

TV obviously supports 1080p24 and shows it when info button is pressed on tv remote. x264 MKV's converted into AVCHD format work just fine with ps3 @ 24 hz.

Win7 x64 Ultimate
Radeon 4890
AMD Phenom II x4 940 BE

BTW, same frame drop/skip happens with VLC also, but no graphic show that like MPC-HC.

[namaiki]

Basically it means that your screen isn't running at the exact same rate as the video. I believe that you'll have to use EVR Sync or Reclock to change that.

[JanWillem32]

@a_afra We've been working quite a bit on the 2D engine. Once the problems with the major changes have been tested, it can be added to the next build. I completely agree that 4×FP32 is memory intensive, not all parts will benefit from it. Do remember that for dithering you need more integer bits than the display format. If you want to output dithered 10-bit color, you can't use a 4×FP16 format for the main image, as it contains only 10 usable integer bits between .5 and 1. Only 4×I16 or 4×FP32 are then useful formats. Do remember that all internal math is done in FP32 or FP24 already, depending on the age of the video card.

@hekoheko Are you using the fullscreen autochange options?

[hekoheko]

@a_afra We've been working quite a bit on the 2D engine. Once the problems with the major changes have been tested, it can be added to the next build. I completely agree that 4×FP32 is memory intensive, not all parts will benefit from it. Do remember that for dithering you need more integer bits than the display format. If you want to output dithered 10-bit color, you can't use a 4×FP16 format for the main image, as it contains only 10 usable integer bits between .5 and 1. Only 4×I16 or 4×FP32 are then useful formats. Do remember that all internal math is done in FP32 or FP24 already, depending on the age of the video card.

@hekoheko Are you using the fullscreen autochange options?

Nope.
I tried those, playback was horrible.

[JanWillem32]

Well, can you then try the D3D fullscreen with and without Aero enabled?

[hekoheko]

Well, can you then try the D3D fullscreen with and without Aero enabled?

I believe I tried those also, but not sure though. I'll try those when I get back home. There's so many options that might affect playback that i'm going nuts. :)

[a_afra]

Do remember that for dithering you need more integer bits than the display format. If you want to output dithered 10-bit color, you can't use a 4×FP16 format for the main image, as it contains only 10 usable integer bits between .5 and 1.

But fp16 does have more precision than 10-bit integer. It stores 10 mantissa bits, which means that you have 11 bits of precision. I think that's perceptually enough even for 10-bit displays.

Anyway, 10-bit should be pretty good even without any dithering. The most important benefit of 10-bit displays is that you can render smooth gradients without adding noise. In some cases (like medical imaging) this is critical.

[tetsuo55]

Hey a_afra, can you come on IRC so we can discuss this?