Media Player Classic Home Cinema (MPC-HC) - DXVA! [Archive] - Page 316

tetsuo55

16th January 2011, 19:34

I do not believe in hacks to keep old driver versions in use. Having driver manufacturers correct their mistakes and users updating is the best solution.

I'm aware that sometimes updating the driver causes a regression in some other application, thus forcing the user to stick with an older driver. This situation will only last forever and keep getting worse if the user does not open support tickets for those issues.

As i said work on the renderer is still in full progress, we might just find a non-hack way to make the problem go away at some point.
Right now though, all the things you see are by design, thus not bugs.

Casshern

16th January 2011, 23:49

You are in error here. The black screen issue has nothing to do with D3D Fullscreen mode. It affects both normal modes and D3D Fullscreen mode of MPC HCs custom presenter. A revert or bugfix is needed - also i know of no case where the upgrade to cat 10.12 fixed this. You are talking about other issues. Please also note Peekstras comment. He tried cat 10.12a (not even "official") and that did not work with DXVA enabled. It also did not work with other renderer settings enabled. Clearly something was broken. This is a bug and not a problem of the cat driver!

This is the information i have.

issue one: Black screen on Exit when D3D fullscreen is used: This is not a regression, the renderer does not refresh the display on exit, it never has.

issue two: Crushed image (like the screenshot shown above), this has to do with the fact that some driver and codec combinations do not like "forced 10bit", again this is not a regression and will probably have to be fixed in the driver.

issue three: Black screen during playback with D3D and 10bit modes disabled, as far as i can see this is another driver bug, fixed in cat 10.12.

Conclusions:
-Ati has to fix its drivers, users need to have at least 10.12(which fixes many other bugs as well like SD dxva) (intel and nvidia seem completely unaffected).
-We need to add code to refresh the display on exit to D3D fullscreen mode.

Based on the above its easy to see that we are again running into driver bugs with ATI, and a revert is not required.

finally, nightly/unstable builds are exactly that, not meant for daily use. We would not release a stable build in this state.

cca

16th January 2011, 23:58

Also using Catalyst 10.12 here, cards are 2 x ATi Radeon 4850 in crossfire, no black screens observed with or without 10bit input. I do not use 10bit output, and never use D3DFullscreen either. All the decoders I use are forced to a NV12 output, which is what the DXVA decoders also use. Aero is always on too, without it I get tearing sometimes. FP32 processing is enabled in the renderer options.

edigee

17th January 2011, 00:00

My issue regarding D3D fullscreen mode exit is not a black screen one but the whole desktop goes very dark as if the brightness is set to minimal. However if I play the video in D3d fullscreen mode it plays fine with normal brightness. Disableing the D3D fullscreen mode the video plays in windowed or full screen mode with the same minimal brightness.
MPC-HC v1.4.1.2845, Ati HD 3650, W 7 Ultimate 32bit, EVR-Cp, driver 10.5, 10bit RGB output, force 10bit RGB input.

tetsuo55

17th January 2011, 00:00

You are in error here. The black screen issue has nothing to do with D3D Fullscreen mode. It affects both normal modes and D3D Fullscreen mode of MPC HCs custom presenter. A revert or bugfix is needed - also i know of no case where the upgrade to cat 10.12 fixed this. You are talking about other issues. Please also note Peekstras comment. He tried cat 10.12a (not even "official") and that did not work with DXVA enabled. It also did not work with other renderer settings enabled. Clearly something was broken. This is a bug and not a problem of the cat driver!What you are talking about is issue 3 in my quote, i cannot find the post you are referring to, but i understand you are saying that for some people the problem occurs even with 10.12.

We need more information in that case:
-Details of test file
-Exact renderer related settings (CTRL+J might still work)
-Video Codec
-Do subtitles and OSD work?
-Os, videocard type and driver version

EDIT: breaking news: After days of research we think we have found the trigger in the code for the black screen problems. There is a limitation or bug in the mixer that prevents certain surface types to be mixed, resulting in just black for the blocked ones. There are several ways to work around this problem, the devs are testing several solutions to find the best one. It wont fix the driver bugs but hopefully prevent triggering them.

Casshern

17th January 2011, 00:28

Here is the post by peekstra: http://forum.doom9.org/showthread.php?p=1471760#post1471760

Judging from the other posts the black screen issue seems to affect only newer cards in the 5xxx and 6xxx series to different degrees but independent of driver version (tested 10.9, 10.10 and Peekstra tested 10.12a and also has problems).

Here is the information you requested about the problem:

Files = ALL (tested with mkv, avi, m2ts, ts -> black screen)
Renderer = EVR CP with vsync, accurate vsync and alternate vsync ON (all other off)
Video Codec = ALL WITH NV12 OUTPUT (tested internal DXVA H264, internal software H264, ffdshow software H264, ffdshow divx, dscaler itcv mod mp2)
OSD = Works Fine (also CTRL-J)
OS = Windows 7 x64 Professional
Card = AMD Radeon 5970
Driver = Cat 10.9 (others have tried 10.10 and 10.12)

And now the kicker: changing output format of the decoder from NV12 to YUY2 brings back the picture. So basically NV12 input to the renderer is broken with certain configurations of the EVR CP renderer and newer radeon cards. Probably not so hard to fix.

What you are talking about is issue 3 in my quote, i cannot find the post you are referring to, but i understand you are saying that for some people the problem occurs even with 10.12.

We need more information in that case:
-Details of test file
-Exact renderer related settings (CTRL+J might still work)
-Video Codec
-Do subtitles and OSD work?
-Os, videocard type and driver version

sansnom05

17th January 2011, 00:28

Casshern

17th January 2011, 00:45

Here's updated test build patched against r2860, added mixer surface to stats output. http://www.mediafire.com/?d53hawr1yxobkhg

For EVR/CP black screen problems, first test with all "10bit/full/half float point processing" options disable, see if it still happens, then add it back one by one. I now found out mixer surface format A8R8G8B8/ARGB32 definitely not working with Full FP, testing other combinations now.

Same result (all renderer settings off, except for alternate vsync, accurate vsync, vsync). Decoder output NV12 results in black screen:
Mixer output RGB32
Mixer surface X8R8G8B8
Formats: Surface A8R8G8B8 Backbuffer X8R8G8B8, Display X8R8G8B8.

Decoder set to output YUY2 works:
Mixer output (!): ARGB32
Mixer surface (!): A8R8G8B8
Formats: surface A8R8G8B8 backbuffer X8R8G8B8 Display X8R8G8B8

It seems like NV12 input triggers different mixer formats -> black screen

cca

17th January 2011, 00:59

Very interesting, tried the debug build, in my case is the exact opposite!

YUY2 results in black screen, mixer stats as metioned in Casshern's post for YUY2
NV12 displays properly, stats again as above for NV12.

BUT! It only happens if I force 10bit Input in my case. If that is disabled, YUY2 gives same output as NV12.

A bit of warning, when testing the renderer options you must completely stop playback and reopen the file, when I disabled 10bit input the video remained black until I reopened it.

EDIT: to be more precise, black screen if floating point processing is enabled also. If only 10bit RGB is on, it gives strange colors, video is unwatchable.

cca

17th January 2011, 01:06

I now found out mixer surface format A8R8G8B8/ARGB32 definitely not working with Full FP, testing other combinations now.

Seems to work in my ATI though. Too many bugs in those damned drivers, it's different for each ATI card.

Superb

17th January 2011, 07:10

Just wanted to say I really enjoy all the small features you guys added to MPC-HC.
IMO, this (http://sourceforge.net/apps/trac/mpc-hc/attachment/wiki/Toolbar_images/mpc_toolbar_simple_gradient_16.png) toolbar image should be the default. Small change, yet it makes the GUI look much better.

JanWillem32

17th January 2011, 12:02

cca

17th January 2011, 13:15

Thanks for all the input. We have some priority in choosing the compiler, so any input for that item is very much appreciated.
http://forum.doom9.org/showthread.php?p=1471401#post1471401

The following test builds are not very optimized (I compiled them), but have a broader range of acceptable mixer formats, except for the RGB types: only X8R8G8B8 (RGB32) is allowed. It's only enabled when (the always-been-fake) "Force 10-bit RGB Input" is selected. Keep in mind that there's no chroma up-sampling and no limited ranges for Y'CbCr if the mixer is forced to render in RGB mode.
I'm quite interested if this solves the problems with black screens on the beginning of rendering, and the bit-ordering problem (red/black screen) of the A8R8G8B8 surface. I'd also like to know what the the X8R8G8B8 and Y'CbCr mixer surface formats do with the rendering color accuracy on different setups.

http://www.mediafire.com/?sk5fzr5t7sxqup8

Just tried it, one time with NV12 and one with YUY2.

NV12 was working for me already, that has not changed. Only difference, if "10 bit input" is not checked in "presentation" the mixer outputs NV12, if it is checked it outputs RGB32, in both cases the chroma upsampling shaders are needed for proper output.

YUY2 now also works, but with some differences. If "10 bit input" is not checked in "presentation" the mixer outputs YUY2 now and the chroma is upsampled properly without the shaders, if "10bit input" is checked then the mixer switches to RGB32 again and the shaders are required.

In both cases I no longer get black screens or weird coloring, but testing by more people is required.

Also, the floating point processing has no effect for me regarding the black screen issues. It just works when it's checked.

tetsuo55

17th January 2011, 13:19

cca, can you also test the other builds for GUI and seeking responciveness?

cca

17th January 2011, 13:22

cca, can you also test the other builds for GUI and seeking responciveness?

I'll try, the build that JanWillem32 did already seems fast in seeking, let me find the other builds then.

tetsuo55

17th January 2011, 13:25

http://www.mediafire.com/?p5rlta1x6zkxv

cca

17th January 2011, 13:32

http://www.mediafire.com/?p5rlta1x6zkxv

Thanks, already found it. From a very quick testing I think the second build (as they appear in mediafire) is a little faster, but the difference is not really noticeable for me, someone with a slower PC must test it for a more proper conclusion. Perhaps I will also attempt testing it on my netbook, the Atom at 1.66Ghz is slow enough for differences to show up. But I can't do it atm, in a few hours from now I will try.

bobdynlan

17th January 2011, 13:34

It's only enabled when (the always-been-fake) "Force 10-bit RGB Input" is selected.
I'm quite interested if this solves the problems with black screens on the beginning of rendering, and the bit-ordering problem (red/black screen) of the A8R8G8B8 surface.
http://www.mediafire.com/?sk5fzr5t7sxqup8
How to test with ffdshow:
First, launch the test mpc-hc executable. Go to Options-External Filters. Add ffdshow Video Decoder and check Prefer.
Second, navigate to Menu-View-Renderer Settings-Presentation and check only "Force 10-bit RGB Input" and "Full Floating Point Processing".
Now open a video, navigate to "Menu-Play-Filters-ffdshow Video Decoder-Properties.."
On the output tab, only check one colorspace at a time then close mpc-hc and relaunch the video. No need to test other RGB formats than RGB32, as those are unsupported.
http://img827.imageshack.us/img827/8521/properties2011011714043.png
On nVidia 8800, the above two packed YUV formats, YUY2 and YVYU were generating a black screen(OSD + subtitles working) in older builds [and weird red colors at least on 2741 build like on intel gpu]. With the test build, issue is fixed.
cca, "Force 10-bit RGB Input" is mandatory for testing issues because that very option exposes them, did you not read the post?

cca

17th January 2011, 13:36

But I did try with that option on and off, I did not made it clear?

Mercury_22

17th January 2011, 21:20

I bump into this today so I just want to remind those that use D3D to disable "Enable Adaptive Anti-Aliasing" in CCC's "3D Application Settings" otherwise they will get those burn colors / "weird coloring" I Hope this helps

Superb

18th January 2011, 00:54

http://software.intel.com/en-us/articles/media/
Just note... Intel released Media SDK 2.0.

mindbomb

18th January 2011, 06:57

question about mpc audio decoder:
im using a 24 bit sound card.
so, for me, 24 bit pcm, 32 bit pcm, and ieee float will provide equivalent sound?
if i understand things right, windows will just convert the other two to 24 bit pcm anyway, right?

namaiki

18th January 2011, 07:20

What bit is your music? For instance 16-bit, 24-bit? Also, are you doing any processing to your music or playing bit exact?

Qaq

18th January 2011, 08:53

question about mpc audio decoder:For PCM output I prefer this chain: ffdshow audio decoder with all output types selected -> ReClock as audio renderer with 24 padded to 32 KS\WASAPI output. Ffdshow outputs native 32fp from DD, DTS (32int from libmad), and ReClock AFAIR processes it with 53fp precision and rings to 24 padded to 32int.

cca

18th January 2011, 12:56

The internal software filters were incorrectly stuck to YUY2, so that type has been disabled until that's fixed (those mix in RGB now). "Force 10-bit RGB Input" has been deactivated. Alternative vSync and D3D Fullscreen GUI Support were not working in D3D Full Screen Mode, so those have been disabled for that mode.
The Y'CbCr levels are selectable even if the output type is RGB. There's no internal support for chroma up-sampling at all without shaders.
I can advise to use my "16-235 to 0-256 for SD&HD video input" shader to expand the levels to full range with surfaces better than 8-bit. If the expansion is left to the mixer, it will use 8-bit integer rounding in the 0-255 range.

Feel free to experiment with different rendering modes and shaders, even older GPUs can process a lot if they are set to their 3D clockspeeds, or somewhere in between the 2D and 3D clockspeeds (like I do).
Renderer settings I use:
16-235 Output Range, D3D Full Screen Mode, 10-bit RGB Output, Full Floating Point Processing, Disable desktop composition (Aero), VSync, Accurate VSync, Flush GPU before VSync, Flush GPU after Present

Shader chain: (available at: http://forum.doom9.org/showthread.php?p=1467856#post1467856)
4÷2÷0 to 4÷2÷2 intermediate Catmull-Rom spline5 chroma up-sampling for SD&HD video input
4÷2÷2 Catmull-Rom spline5 chroma up-sampling for SD&HD video input
16-235 to 0-256 for SD&HD video input
gamma conversion of HD&SD video RGB to linear RGB

Screenspace shaders:
Catmull-Rom spline6 height resizer (with correct scaling preset)
Catmull-Rom spline6 width resizer (with correct scaling preset)
sharpen complex v3 + deband + medium denoise
gamma conversion of linear RGB to wide gamut RGB
finalpass: color management with an ICC profile and dithering

Tester builds: compiled with MSVS 2010, both x86 and x64 included.
http://www.mediafire.com/?zl90cp98242so0r

What is the reason 10bit RGB was disabled in this build? Just curious to know.

WonderCsabo

18th January 2011, 13:02

Hi guys!

Me and others are experiencing a very annoying bug with MPC-HC's screen refreshing frequency changer feature.
If i choose the exact multiple frequency for the fps (for example 59.97Hz for 59.97fps, or 50Hz for 25fps) and change to full screen with automatic frequency changing the playing stutters.
The stuttering are not always present, for a time it's ok, and stuttering again, then ok, then stuttering, etc.
But not just the video stutters, the refreshing of the Ctrl+J statistics, too.
Toggling DXVA does not make a difference.

If i change the appropriate frequency with Windows, this issue does not exist.
If i change a not exactly appropriate frequency with MPC-HC (eg: 75Hz for 30fps) this issue does not exist.

namaiki

18th January 2011, 13:25

When there is stuttering, if you open the "Options" dialog box, does the stuttering go away?

tetsuo55

18th January 2011, 13:27

What is the reason 10bit RGB was disabled in this build? Just curious to know.All the disabled options where either fake or buggy.

WonderCsabo

18th January 2011, 13:36

When there is stuttering, if you open the "Options" dialog box, does the stuttering go away?

Yes! I forgot to mention this.

Mercury_22

18th January 2011, 13:36

Using internal H264 filter with MPC-HC's (VS 2010 SP1) default settings I have black screen using an external decoder (e.g. M$ DTV-DVD Video Decoder) => no black screen so I think the problem is in MPC's decoder not in renderer

cca

18th January 2011, 14:22

All the disabled options where either fake or buggy.

I see. For the time being I use shaders as described in JanWillem32's post to upsample chroma and convert to 0-255 levels. 10 bit RGB would be nice, if it worked properly. If not, no point to keep the option indeed.

bobdynlan

18th January 2011, 15:35

The before "Force 10-bit Input" GUI option enabled dithering, making 0-255 Output Range smoother. It did improve things, but it was not a 10-bit thing, just proper dithered 8-bit.
The now "Half/Full Floating Point Processing" includes the same dithering, resulting in the same output as before, making the former option redundant.
Just to clear things out.

cca

18th January 2011, 16:18

cca

18th January 2011, 16:38

janos666

18th January 2011, 17:09

I have one question: My primary video watching display is my LCD TV, connected via VGA D-15 sub. Obviously doesn't support 10bit RGB. Will I benefit from checking the "10bit RGB output" or I should leave it unchecked?

- D-sub theoretically supports infinite bit depth, as it carries analog signal. The "effective bit depth" depends on your DAC (digital-to-analog converter) quality which usually 10+ bit on modern VGA cards.
- The Radeon cards always apply dithering after the 16-bit VGA LUT and they can theoretically do it with any RGB input formats. [For example: 12-bit goes on, it becomes 16-bit after the 16-bit lookup (it always happens, even with linear LUT) and then it becomes dithered back to the display output bit depth. According to my experiences, it results in 10-bit effective precision with 8-bit digital output.)

I think you should use it if it seems to work. (If it doesn't cause any problems.)

chros

18th January 2011, 18:07

I can't register file extensions with standard user (not admin) in Win 7 (x86, UAC is disabled):
only the Modify button is available, if i clkick on it the SAME window apears again with the Modify button and so on ... (no Video, Audio,All button)

Is it a bug?

Can someone post a regisrty tweak for all the video extensions for the current user?
Or where can I find it in the registry?

Thanks

I have tried in command line too:
mpc-hc /regvid
but the result is the same ... :( (with UAC disabled or UAC enabled)

There would be a good thing, if there will be an checkbox for "All users" in formats (like in Irfanview installer), which will create a HKLM association (of course, just in admin user mode).

Meanwhile I tried Winamp in standard user mode: it doesn't working too ... :)

Any Help? (I know I can manually click all the preferred types, but it's so painful ...)
Thanks

janos666

18th January 2011, 18:16

@JanWillem32

Yes, the mixer can output NV12 again. (I just wanted to ask why it is limited to RGB anyway.)
But it doesn't accept YV12. Is EVR incompatible with this popular format or is it some kind of MPC-HC related limitation?

How lcms works now? Would it be possible to let lcms do the YCC->RGB conversion too? (It can accept YCC ; I am not sure if it can also do the level conversion because it's mainly developed for still image processing where YCC is encoded in full range too.)
What about the idea to move the color correction step before the level conversion happens (the level expansion shader applied)?

Did you consider to use bigger matrices for the color correction shader? 64x64x64 sounds small for 10-bit output (at least for me). It should be 8-bit, I think.

Good to hear that "Force 10-bit input" is disabled now. It was always a confusing thing for me. (How does it really help with level expansion...)
I will check how your level expansion shader works.

gamma conversion of HD&SD video RGB to linear RGB
gamma conversion of linear RGB to wide gamut RGB
finalpass: color management with an ICC profile and dithering

This is a very bad idea! It breaks the CMS processing and changes the final gamma curve and also affects the precision of the gamut emulation (if it's necessary). lcms converts between source and device profiles and assumes a pure-power curve with an exponent between 2.2 and 2.4 as a source gamma but you change that. (Or do you use a custom source profile? But it's a bad idea to do things like this...)

mindbomb

18th January 2011, 20:23

What bit is your music? For instance 16-bit, 24-bit? Also, are you doing any processing to your music or playing bit exact?

some is 24 bit, some is 16 bit. I'm not using wasapi, so im assuming windows will convert it to 24/48, since that was what was specified for shared mode.

my question is: 24 bit PCM and above are basically all going to be equal for me in this case?

WonderCsabo

18th January 2011, 20:54

Polcius

18th January 2011, 22:59

I have a huge problem with .mkv's.

I recently bought a Nvidia GT 430, and the x264 qualitys is awful. I get dropped frames now and then. Using EVR-CP, default renderer settings, DXVA with the internal MPC splitter.

I tried the recommended renderer settings but I hat a little bit of tearing.

Thanks in advance.

clsid

19th January 2011, 00:56

I have tried in command line too:
mpc-hc /regvid
but the result is the same ... :( (with UAC disabled or UAC enabled)

There would be a good thing, if there will be an checkbox for "All users" in formats (like in Irfanview installer), which will create a HKLM association (of course, just in admin user mode).

Meanwhile I tried Winamp in standard user mode: it doesn't working too ... :)

Any Help? (I know I can manually click all the preferred types, but it's so painful ...)
Thanks
The file association code in MPC is very buggy.

What MPC should do is:
1) Create private file association GUIDs (HKCR\mplayerc.extension) for each file extension. Preferably also a different one for the x64 build.
2) Register player capabilities (HKLM\Software\Clients\Media\Media Player Classic\Capabilities\FileAssociations). This allows creating file associations through the "Default Programs" functionality of Windows Vista/7. Those apply to individual user accounts and it works for limited accounts as well. It creates references in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\
3) Optionally create a global file association (HKCR\extension, pointing to the private GUID), with backup of previous association.

These things are best handled in the installer, since that allows proper cleanup during uninstall. Doing it through command line should be fine as well, since then there also is a command for undoing.
If the above is done, then removing the file association stuff from the GUI is a good idea imho. Selecting of the playback framework (DS, QT, RM) could be moved to a new page, where those options are also less likely to be overlooked.

Maybe one day if I am really bored I will work on implementing the above.

If you are looking for an installer that works properly now, then I can suggest the K-Lite pack. It allows installing only MPC-HC if that is all you need.

JanWillem32

19th January 2011, 01:45

@JanWillem32

Yes, the mixer can output NV12 again. (I just wanted to ask why it is limited to RGB anyway.)
But it doesn't accept YV12. Is EVR incompatible with this popular format or is it some kind of MPC-HC related limitation?
The mixer annoys me, too. I can only force-enable X8R8G8B8, A8R8G8B8 (broken), NV12 and YUY2. I still don't know why it's so limited. I hope we can make it work, as writing a custom mixer would probably require recruiting a few new programmers.

How lcms works now? Would it be possible to let lcms do the YCC->RGB conversion too? (It can accept YCC ; I am not sure if it can also do the level conversion because it's mainly developed for still image processing where YCC is encoded in full range too.)
What about the idea to move the color correction step before the level conversion happens (the level expansion shader applied)?
The color correction should be in the final pass (just before dithering), as it adapts for the screen characteristics, the processing format should be as uniform and linear as possible.

Did you consider to use bigger matrices for the color correction shader? 64x64x64 sounds small for 10-bit output (at least for me). It should be 8-bit, I think.
I would have to ask an expert if it's usable, and then test the memory consumption.

Good to hear that "Force 10-bit input" is disabled now. It was always a confusing thing for me. (How does it really help with level expansion...)
I will check how your level expansion shader works.
In theory, we should be able to grab the entire fp32 output from the mixer, but it's stuck to 8-bit rounding.

This is a very bad idea! It breaks the CMS processing and changes the final gamma curve and also affects the precision of the gamut emulation (if it's necessary). lcms converts between source and device profiles and assumes a pure-power curve with an exponent between 2.2 and 2.4 as a source gamma but you change that. (Or do you use a custom source profile? But it's a bad idea to do things like this...)
That shader just bends the linear gamma to almost 2.2 (256/563). I could also have used "brightness, contrast and gamma control" to set a gamma value. Another option could be to adapt the lcms input gamma to .9, 1.0, 1.1, et cetera.

cyberbeing

19th January 2011, 02:34

Another option could be to adapt the lcms input gamma to .9, 1.0, 1.1, et cetera.
This may be preferable, if setting to 1.0 would result in color correction only with untouched gamma (same gamma as without using lcms).

JanWillem32

19th January 2011, 02:36

This may be preferable, if setting to 1.0 would result in color correction only with untouched gamma (same gamma as without using lcms).

1 would simply convert the linear gamma to your display's native gamma.

namaiki

19th January 2011, 02:42

some is 24 bit, some is 16 bit. I'm not using wasapi, so im assuming windows does some processing.

Yes, at least Windows will resample everything to what is set in Playback/Multimedia/Sound options in the Windows Control Panel. For my integrated sound card, it is default to 16 bit, 44100 Hz. However, MPC Audio Decoder is by default set to use WASAPI. Have you disabled that?

Devs: are you aware of this isse? I forgot to mention that opening Options dialog stops the stutterings.

I'm not a dev, but yes. There was a hopeful fix which attempted to automatically open and close the options dialog box, but it did not have the same effect as intended as it didn't help the bug. I'm not sure where that issue is at, at the moment. (You're not that guy who came onto MPC-HC IRC channel, are you?)

I have a huge problem with .mkv's.

I recently bought a Nvidia GT 430, and the x264 qualitys is awful. I get dropped frames now and then. Using EVR-CP, default renderer settings, DXVA with the internal MPC splitter.

I tried the recommended renderer settings but I hat a little bit of tearing.

Thanks in advance.
What version of Windows? If on Windows Vista or newer, is Aero enabled or disabled? How many monitors and if there is more than one, what is the resolution and refresh rate of each? Which build of MPC-HC? Also, open an affected video in MPC-HC and tell me all that is listed in the menu: Play-> Filters.

Stephen R. Savage

19th January 2011, 03:00

The mixer annoys me, too. I can only force-enable X8R8G8B8, A8R8G8B8 (broken), NV12 and YUY2. I still don't know why it's so limited. I hope we can make it work, as writing a custom mixer would probably require recruiting a few new programmers.

Speaking of the mixer, I've noticed that the EVR OSD always reports "Mixer output: YUY2" on my system, while most screenshots show "Mixer output: RGB32". Can you explain what the "mixer" is and whether or not my videos are being converted to YUY2 somewhere? If this is the case, then it obviously makes no sense to do RGB conversion in ffdshow as a I currently do.

mindbomb

19th January 2011, 04:18

Yes, at least Windows will resample everything to what is set in Playback/Multimedia/Sound options in the Windows Control Panel. For my integrated sound card, it is default to 16 bit, 44100 Hz. However, MPC Audio Decoder is by default set to use WASAPI. Have you disabled that?

i dont believe mpc audio decoder uses wasapi by default, cause volume controls work by default, and that shouldn't work with wasapi on.

JanWillem32

19th January 2011, 04:19

Speaking of the mixer, I've noticed that the EVR OSD always reports "Mixer output: YUY2" on my system, while most screenshots show "Mixer output: RGB32". Can you explain what the "mixer" is and whether or not my videos are being converted to YUY2 somewhere? If this is the case, then it obviously makes no sense to do RGB conversion in ffdshow as a I currently do.

Video layout:
video bitstream -> decoder -> mixer -> renderer -> presenter -> video card output
video bitstream: contains binary data
decoder: Converts to the native 4:4:4, 4:2:2, 4:2:0 structures and with 8 to 16 bits per component per pixel, then lines that data up into a suitable surface format, such as NV12, YUY2 or AYUV.
mixer: Convert one format to another format that the renderer can use. Ideally it should provide deinterlacing, chroma up-sampling, level expansion, color conversion to RGB, and output bit depths of up to fp32 per component.
renderer: Take the raw image from the mixer, scale and position it relative to the screenspace, adapt other image characteristics to the display output and possibly do some special effects.
presenter: Stacks the layers from the different renderers (main video, subtitle, OSD) on top of each other, times the images to the presentation time and exports the image to the correctly initiated video card to output.

The main renderer and presenter have been improved far beyond the previous 8-bit limitations.
The decoders should simply be ready to write images on a surface format that matches the layout in the video bitstream.
The mixer handling is very weak at the moment. It's completely stuck in 8-bit, that causes big rounding errors when doing deinterlacing, chroma up-sampling, level expansion or color conversion to RGB. The deinterlacing and chroma up-sampling functions don't even work properly at all.
On top of those problems, the internal software codecs will always select YUY2, even on input of 4:2:0 or 4:4:4 format video. That's just wrong, so I disabled YUY2 as a mixer format in favor of RGB32/X8R8G8B8 (slightly less wrong, as it still has bad rounding issues).
At this moment I can only advise to use limited range (Y' at <16,235>, Cb and Cr at <16,240>) NV12 as a format for 4:2:0, 8-bit encoded video, and let three pixel shaders handle chroma up-sampling and level expansion in the renderer stage.
The DXVA decoders will already correctly select NV12 as far as I know.
Try one of my builds to test it.

namaiki

19th January 2011, 04:23

i dont believe mpc audio decoder uses wasapi by default, cause volume controls work by default, and that shouldn't work with wasapi on.

What version of Windows and what sound card? The volume controls don't work as such on my PC.
I'm on Windows 7 with one of those integrated Intel High Definition Audio things.

Does MPC Audio Renderer appear in the menu: Play-> Filters? If you click that, there is an option to enable/disable WASAPI in newer builds of MPC-HC.