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

nlnl

27th December 2009, 21:01

1. I believe DS output does connect at 24-bits; it's a driver restriction that only affects WASAPI, as far as I know. I'm sure nVidia will eventually enable >16-bits over an exclusive connection, but that's not to say I'd hold my breath
2. Some receivers display what PCM bit-depth they're being fed, or, on the far end of the plausibility scale, you could always grab a SPL meter and measure to see if your dynamic range exceeds 97db. Otherwise, I'm not aware of a pass/fail method to test for 24-bit output
3. 32-bit WASAPI mode simply isn't exposed in the current nVidia drivers. Reclock and the MPC renderer are the best ways to test driver functionality, because they're completely unforgiving: if your driver doesn't accept a format, these renderers just plain won't connect. foobar w/WASAPI does a lot of mysterious things under the hood, and it's difficult to tell what, exactly, it's outputting. On the other hand, foobar at least supports ASIO, so you can get full 24/192 output through that.

(Of course, if you're bitstreaming, then none of this matters.)

As an aside, decimating to 16-bits really isn't going to affect sound quality, unless you plan on blasting your sound levels at a continuous >100db (highly unrecommended!). Even big, huge IMAX theaters still playback at 16-bits, and unlike resampling, decimation doesn't cause any inherent quality degradation.

Thank you for that superb explanation and Happy New Year!

:goodpost:

Andy o

27th December 2009, 22:18

foobar w/WASAPI does a lot of mysterious things under the hood, and it's difficult to tell what, exactly, it's outputting.You can just go ask the developers, at the foobar forum at hydrogenaudio.org
As an aside, decimating to 16-bits really isn't going to affect sound quality, unless you plan on blasting your sound levels at a continuous >100db (highly unrecommended!).If you think this is true (I agree!) then you're probably already familiar with the HA forums. I've always said we never should have gone higher than 16-bit / 48kHz and we might have avoided all this HDMI HDCP PAP nonsense.

matthew_eli

27th December 2009, 23:30

In my testing I disabled VSFilter and tried using DXVA as well.. I have very fast hands.. ;)

I, personally, have not experienced any audio issues anywhere, except when trying to play back FLAC by itself + Reclock.

Just curious, but what is your 4500MHD clocked at? (mine appears to be 400 or 475MHz, differing reports from programs)

Mine is 475 MHz (GPU-Z). The very strange thing is that if I did not use DXVA with EVR custom, the video is smooth and plays perfectly; with DXVA instead I have some glitches, like the render has more effort to play the same video...

namaiki

27th December 2009, 23:34

Mine is 475 MHz (GPU-Z). The very strange thing is that if I did not use DXVA with EVR custom, the video is smooth and plays perfectly; with DXVA instead I have some glitches, like the render has more effort to play the same video...

How about if you're using the internal subtitle renderer, but no DXVA?

wOxxOm

28th December 2009, 00:07

MPCHC's FF h264 decoder seems to mistreat haali splitter's OUT-pin properties biXPelsPerMeter/biYPelsPerMeter (SAR numerator/denominator)

e.g. I have a 1440x800 mkv with 16:9 AR set in mkv header. It should play at 1440x810, but when haali splitter is used in MPCHC, it is decoded to 1536x800 with strange AR (4551:2560) then gets rescaled by renderer (any of them) to the correct AR & size, however when an internal MPCHC's matroska is used the video is decoded as source is (1440x800) and is passed to renderer with mkv-specified AR (16:9). And though the result is the same but the quality degrades due to intermediate resizing.

Seems like both MPCHC's video decoder (FF libavcodec) and CoreAVC can't handle it right, because the only vital difference between MPCHC's splitter OUT-pin and haali's is:
biXPelsPerMeter: 0 (MPC) 81 (Haali) - AR correction numerator, 81 in my case
biYPelsPerMeter: 0 (MPC) 80 (Haali) - AR correction denominator, 80 in my case
(since 1440x800 @ 16:9 = 1440x810, so AR correction is 800/810 = 80/81)

flanger216

28th December 2009, 02:56

If you think this is true (I agree!) then you're probably already familiar with the HA forums. I've always said we never should have gone higher than 16-bit / 48kHz and we might have avoided all this HDMI HDCP PAP nonsense.

Absolutely... in fact, I was just meeting with Tom Holman (the founder of THX), and he was quite adamant that anything above 16/48 for playback is overkill and entirely driven by marketing. I, personally, wish the redbook standard would've been set to 20/60 --- 20-bits to compensate for the inherent ineffeciency of DACs, and 60-kHz to encompass the range of all documented human hearing capability --- but 16/48 is certainly close enough.

Andy o

28th December 2009, 03:08

well this is probably getting too OT, but redbook has a pretty interesting story for it being 44.1 kHz. Don't remember the details, but first PCM was being stored on tapes, search for it on the HA forums, or maybe just google it.

lych_necross

28th December 2009, 07:21

I also have this bug, so MPC-HC is totally unusable for me for videos...it does close properly on audio files, though.
I'm curious, what is your video player of choice if not MPC-HC?

tetsuo55

28th December 2009, 08:06

matthew_eli

28th December 2009, 09:11

How about if you're using the internal subtitle renderer, but no DXVA?

It is what I've described previously: perfect and smooth video, even at 1080p...

wOxxOm

28th December 2009, 09:43

AR and SAR correction is virtually non-existant when using mpc-hc.yet it DOES change the way the video is decoded in FF libavcodec (assumably worse), that is the aforementioned intermediate & redundant resizing.

Anyway it seems a problem of FFmpeg/libavcodec and CoreAVC decoder...

tetsuo55

28th December 2009, 09:57

yet it DOES change the way the video is decoded in FF libavcodec (assumably worse), that is the aforementioned intermediate & redundant resizing.

Anyway it seems a problem of FFmpeg/libavcodec and CoreAVC decoder...There are various "aspect ratio" types and locations.

Depending on where the information is stored and what type it is, the splitter and/or codec might do something with this information.

here is my feature request about it:
https://sourceforge.net/apps/trac/mpc-hc/ticket/76

madshi

28th December 2009, 10:47

As an aside, decimating to 16-bits really isn't going to affect sound quality
That depends very much on how exactly the decimation is done and how much further processing will be done by the receiver/processor. If you use rounding or truncating then sound quality will be affected. If you use TPDF dithering, sound quality should stay identical, but noise levels will increase slightly. The idea of transporting more than 16bit to the receiver is that the receiver will probably add some more audio processing (room correction etc). If you do audio processing in the source *and* in the receiver, transporting more than 16bit makes sense, because otherwise you're adding multiple 16bit dithering layers on top of each other. At some point, the noise increase will be in the audible range. If you chain multiple noise shaped dithering passes, it's even worse: Audio quality will suffer in that case.

tetsuo55

28th December 2009, 11:25

I dont have links to the proof, but it has been proven that decoding audio (for example dts) using 24 bits restores more parts of the compressed signal than 16 bit.

In the end though, you should choose the highest bitdepth support by your hardware, limited to the lowest bitdepth part of the chain.

in my case, everything is 24bit so i use that, my previous hardware did everything in 32 bit internally, then dither down to 24 for the dac, so i used 32 on that one to stop the internal resampling.

krbo

28th December 2009, 13:55

In my case (780G chipset HD3200, Win7) it's even worse.

DXVA is OK only after a cold boot for a first video you watch.

DXVA breaks:

- after suspend
- after screensaver
- after any watched DXVA video

even with latest 9.12 hotfixes (no mention of any DXVA fixes just games, games, games...)

In every case MPC always shows DXVA sign but video is unwatchable (few minutes OK then few minutes of almost single photo shots again OK and so on) in latest builds.
Pre Beliyaal builds (1043) is much better but still judder can be seen from time to time.
Revert to catalyst 9.8 seems to fix at least watching one video after another - didn't tested screensaver and suspend

Well, I must correct myself.

No matter what Catalyst version, MPC HC is unusuable on my system with it's internal h.264 decoder @ Win7
Everything was OK with Vista but Win7 is a no-go. (32bit both)
Wile I watch any kind of h.264 video suddenly it stars to crawl (picture only, audio is perfect always) for a few minutes, then again few minutes OK and repeating.
I've noticed jitter times of 20 million milliseconds during such behaviour!!

Usually it is possible to watch complete video but only one after a cold boot. Any more attempts and problem is here.

So I'm now using microsoft decoder - absolutely no problem at all (except it uses 2-3 times more CPU then MPC HC decoder, 14-20% compared to 4-7%)

Writing this only for information to devs.

Sooner or later it will be fixed, M$ dec is OK for now and I have a strong impression that picture is much better with Win7 then with Vista

88keyz

28th December 2009, 15:52

Just curious what thoughts are, is the recommended Matroska splitter still Haali or is Gabest's splitter better? Haali releases an update once every ice age and the development of the Gabest splitter never seems to come up. What do people prefer out there?

tetsuo55

28th December 2009, 16:11

Andy o

28th December 2009, 16:38

I've noticed jitter times of 20 million milliseconds during such behaviour!!

So, 20 thousand seconds jitter? :eek:

Anyway, have you tried messing with renderer settings (for instance, change to 8-bit) or using other renderers (regular EVR, VMR9)?

DXVA is also coming to ffdshow, by the way, so there will be another option for you soon.

tetsuo55

28th December 2009, 16:41

Andy o

28th December 2009, 17:15

Hmm ok so then it's not really much of a big deal, seeing as you can already use the MPC-HC codecs by themselves? Does it have any advantage then?

flanger216

28th December 2009, 18:42

That depends very much on how exactly the decimation is done and how much further processing will be done by the receiver/processor. If you use rounding or truncating then sound quality will be affected. If you use TPDF dithering, sound quality should stay identical, but noise levels will increase slightly. The idea of transporting more than 16bit to the receiver is that the receiver will probably add some more audio processing (room correction etc). If you do audio processing in the source *and* in the receiver, transporting more than 16bit makes sense, because otherwise you're adding multiple 16bit dithering layers on top of each other. At some point, the noise increase will be in the audible range. If you chain multiple noise shaped dithering passes, it's even worse: Audio quality will suffer in that case.

Well, obviously I meant a dithered scenario; bit-depth truncation is rather disastrous. And sure, >16-bit is important in DAW environments where per-track additive noise-floors become a concern: in fact, on some epic mixdowns I've seen, even 64fp was ideal (!). But that was with hundreds upon hundreds of tracks, busses and effects being flattened to a 5.1 mix. For the consumer arena, I'd still like to see some hard, journaled data on the psychoacoustical efficacy of 24-bits in an HTPC environment compared to 16, even with a noise-shaped dither at the sound card and the receiver.

And to Tetsuo: sure, all E/AC3 variants and most lossy codecs (DTS, Vorbis, etc.) should be decoded to 32fp. PCM output bit-depth is a separate issue.

But really, I wasn't saying that you shouldn't use 24-bit output. If you can, then heck, why not. I was just advising the guy that, although he can't get 24-bits to work ATM, it's really not something to worry too much about. And I'd say that for anyone having similar problems. Apologies for my further OT blathering :)

madshi

28th December 2009, 19:14

For the consumer arena, I'd still like to see some hard, journaled data on the psychoacoustical efficacy of 24-bits in an HTPC environment compared to 16, even with a noise-shaped dither at the sound card and the receiver.
A while ago I tried to google what happens if multiple noise shaped dithers are applied after each other and I found only two links even talking about that. Both said that it would be bad for audio quality. One link is wikipedia, and although I know that there's much garbage information on wikipedia, I haven't found any contradicting information on the net, so here goes:

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

"If colored dither is used at these intermediate processing stages then the frequency content can "bleed" into other, more noticeable frequency ranges and become distractingly audible."

It's worth noting that some studios are using colored dither for 16bit lossless tracks (I checked that myself). So if 16bit lossless Blu-Ray tracks are processed by the source device *and* by the receiver, and the transport is done in 16bit, there may be 3 colored dithers added on top of each other.

But really, I wasn't saying that you shouldn't use 24-bit output. If you can, then heck, why not.
Sure, I did understand your point of view... ;)

I was just advising the guy that, although he can't get 24-bits to work ATM, it's really not something to worry too much about. And I'd say that for anyone having similar problems.
Well, I think you are a bit too hasty here. E.g. ffmpeg/libav for a long time rounded audio to 16bit. Not sure if they fixed that in the meanwhile. How do we know that PowerDVD etc are applying proper dithering? I'm not even sure if ffdshow applies dithering when downconverting 24bit to 16bit, but maybe it does. Anybody knows?

Generally, I guess my point of view is that studio provided 16bit Blu-Ray tracks are ok, but I prefer 24bit transport, because that should reduce chances of audio ever being truncated or rounded down to 16bit somewhere in the chain...

krbo

28th December 2009, 19:32

So, 20 thousand seconds jitter? :eek:

Anyway, have you tried messing with renderer settings (for instance, change to 8-bit) or using other renderers (regular EVR, VMR9)?

DXVA is also coming to ffdshow, by the way, so there will be another option for you soon.

VMR9 is OK (although it switches DXVA off), regular EVR on quick look is better but as I depend on subtitles it's no option.

Even EVR custom is much better without loaded subs. Subs are heavy burden for MPC.

With M$ decoder I can even use bicubic resizer (but not for 4:3 stretched to 16:9) and MPC HC works great
despite small problem with internal decoder @Win7

leeperry

28th December 2009, 19:33

dithering is nice, but it adds white noise...and post-processing white noise ain't cool...native 16 bit can be great, but going 24>16 w/ dithering in eac3to sounds ugly to me...apparently each bit decimation adds twice more white noise.
ffmpeg/libav for a long time rounded audio to 16bit. Not sure if they fixed that in the meanwhile.
I don't think they did...decoding lossy audio to anything else than 32fp doesn't make much sense(liba52 and libdts do decode to 32fp)

mikelebron

29th December 2009, 04:57

How do I get VC1 to play back smoothly with high quality (no noise)... If I enable frame time correction the quality has a ton of "noise" (all i can say..) Any help appreciated.

73ChargerFan

29th December 2009, 07:11

We need more info about your system to help. Also what kind of video?

thrawnrulz68

29th December 2009, 09:46

Does anyone know of a way to get MPC-HC to read .m3u8 playlists? The player already can read and write playlists in UTF-8 but when I attempt to open a .m3u8 file created in winamp it will not open. I was under the impression the encoding was the only thing different about these types of files in comparison to regular .m3u files but perhaps there is something in the header that MPC-HC is missing?

khagaroth

29th December 2009, 10:36

Seem like MPC can't handle the .m3u8 extension (even if it's the correct extension in this case), just rename the file to .m3u and it will work.

clsid

29th December 2009, 14:23

If renaming works, then you could add .m3u8 to the playlists entry in options->player->formats

betaking

29th December 2009, 15:28

If renaming works, then you could add .m3u8 to the playlists entry in options->player->formats

add .m3u8 to the playlists entry in options->player->formats not work!

flanger216

29th December 2009, 16:31

Well, I think you are a bit too hasty here. E.g. ffmpeg/libav for a long time rounded audio to 16bit. Not sure if they fixed that in the meanwhile. How do we know that PowerDVD etc are applying proper dithering? I'm not even sure if ffdshow applies dithering when downconverting 24bit to 16bit, but maybe it does. Anybody knows?

I can't speak for PowerDVD (shudder), but ffdshow at least has a 'sound processing' tab that lets you enable dithering, noise-shaping and set noise-shaping strength. From my testing, it seems to work as expected, though unfortunately it's turned off by default (?), so some users might overlook it.

madshi

29th December 2009, 16:47

I can't speak for PowerDVD (shudder), but ffdshow at least has a 'sound processing' tab that lets you enable dithering, noise-shaping and set noise-shaping strength. From my testing, it seems to work as expected, though unfortunately it's turned off by default (?), so some users might overlook it.
Glad to hear that ffdshow has dithering support. But now imagine what happens if you don't use kernel streaming or WASAPI exclusive mode: ffdshow applies dithering, and afterwards the OS and the audio drivers reprocess the data another time before sending it to the receiver. Not sure if the OS and audio drivers use dithering or not. Again, I think the safest solution is to keep the audio data in 24bit. To me using 16bit audio transport feels dangerous. 24bit has a nice safety net. 16bit has not. With 16bit everything needs to be done correctly to keep full audio quality. If one processing stage drops the ball, you're screwed. Even if all processing stages are correct, audio quality could eventually still suffer, if noise shaped dithering is applied multiple times. With 24bit it doesn't matter as much if there are multiple processing stages with (or even without) dithering at the end of each stage...

leeperry

29th December 2009, 16:53

ffdshow at least has a 'sound processing' tab that lets you enable dithering, noise-shaping and set noise-shaping strength. From my testing, it seems to work as expected
what "testing" procedure if I may ask? I've tried really really hard on many occasions, but I've never been able to hear any difference whatsoever...and there's no infos about what algorithms are used either.

Andy o

29th December 2009, 17:19

Glad to hear that ffdshow has dithering support. But now imagine what happens if you don't use kernel streaming or WASAPI exclusive mode: ffdshow applies dithering, and afterwards the OS and the audio drivers reprocess the data another time before sending it to the receiver. Not sure if the OS and audio drivers use dithering or not. Again, I think the safest solution is to keep the audio data in 24bit. To me using 16bit audio transport feels dangerous. 24bit has a nice safety net. 16bit has not. With 16bit everything needs to be done correctly to keep full audio quality. If one processing stage drops the ball, you're screwed. Even if all processing stages are correct, audio quality could eventually still suffer, if noise shaped dithering is applied multiple times. With 24bit it doesn't matter as much if there are multiple processing stages with (or even without) dithering at the end of each stage...
The Windows 7/Vista mixer works at 32 float, then you can output at 24-bit as set on the device properties. I don't think dithering will be applied more than once.

tetsuo55

29th December 2009, 17:22

The Windows 7/Vista mixer works at 32 float, then you can output at 24-bit as set on the device properties. I don't think dithering will be applied more than once.if windows7 works at 32bit float, its best to ouput the same thing straight from the decoder, in this case we have full control over the dithering used (if any)

nlnl

29th December 2009, 18:08

albain
Nvidia 9400 Hdmi+ Vista + MPC Audio Renderer (new)

Can not play 24/48 5.1 Flac audio stream in mkv, but can play 16/48 5.1.
Foobar can play 24/48 in WASAPI mode, so Nvidia Hdmi driver does accept 24 bits? Or Foo converts 24/48 --> 32/48?

Tested Nvidia 9400 Hdmi+ Vista + Foobar + ASIO (asio4all driver).
No problem for 24/48 5.1.

Will MPC-HC audio renderer sometime support ASIO protocol output?

mikelebron

29th December 2009, 18:16

I have tested the issue on two systems:

Software Setup
Windows 7 64 bit
32 bit ffdshow 3171
32 bit MPC-HC 1453
32 bit Gabest Splitter for all codecs applicable (no Haali)
AnyDVD (latest)
EVR Custom
Playing Bluray Movies right from disc -
Public Enemy
Superman

System 1
Core i5 - 4GB RAM
ATI 4870 x2
HDMI to Samsung 52" LCD

System 2
Core 2 Quad Q9400 - 4 GB RAM
Geforce 275]
DVI to 24" monitor

Without "Enable Frame Time Correction" it stutters and I see there is significant frame loss. With enabled plays smoothly but I see significant pixelation but is random. Depends on the scene and its not the whole image just certain parts - almost as if the bit depth of the color has decreased... I am using the default Windows codec but have tried FFDSHOW built in and WM9 codecs.. same results...

any ideas?

How do I get VC1 to play back smoothly with high quality (no noise)... If I enable frame time correction the quality has a ton of "noise" (all i can say..) Any help appreciated.

thrawnrulz68

29th December 2009, 20:36

Strangely enough, renaming the .m3u8 playlist to .m3u works for me but, similar to betaking, leaving the extension alone and just adding it to the list in options>formats does not work. BTW, I downloaded a video file the other day that was .asx but was not a stream, it was a full video file stored locally. When I used MPC-HC to open the file, it crashed. However, when I renamed the file to .asf, it worked perfectly. Whether or not "use WM ASF reader" was checked made no difference. It seems the player is either looking for something in these playlist/streaming files (.asx, .pls, .m3u, .m3u8, etc.) that its not finding or it is failing to do something correctly.

73ChargerFan

29th December 2009, 20:47

mikelebron,

Are you are using ffdshow to decode h264/vc1, I don't think we can help with ffdshow.

Try the default mpc-hc setup - enable internal filters, and output "EVR Custom Pres.", Bilinear PS2.0, EVR Buffers 5, and enable "Reinitialize when display changing." Remove ffdshow from external filters, if present.

Also, nVidia & ATI drivers behave differently, so the same settings may not work on both, and may exhibit different behavior / bugs.

73ChargerFan

29th December 2009, 20:50

It seems the player is either looking for something in these playlist/streaming files (.asx, .pls, .m3u, .m3u8, etc.) that its not finding or it is failing to do something correctly.
The player can identify some files by content alone, even with a bad extension. Rename any .mkv file to "1.001" and it will still play.

Andy o

29th December 2009, 22:27

if windows7 works at 32bit float, its best to ouput the same thing straight from the decoder, in this case we have full control over the dithering used (if any)

Yeah, but this doesn't apply when using WASAPI exclusive of course.

nightfly

29th December 2009, 22:38

I normally run v1249 with ripped BDs in ISOs on a Win7 32 Bit box. I am currently testing v1453 using external filters options and the stand-alone MPC filters @ v1453 (using mpeg splitter-gabest & mpc video decoder in dxva mode). Using Nvidia graphics v190.65. EVR custom presenter.

Since at least v1351+, If I set the Video Frame menu option to anything other than "normal Size", the video gets screwed up and all I see is a line at the top of the video frame. With the exact same settings (stored to ini file), I can get video playback as expected when running any version lower than v1249 from my tests which have not been exhaustive.

I don't think it's a filter issue as using another setup with the Arcsoft TMT2 filters has the same problem.

I also have "keep aspect ratio" but that doesn't affect my result, really nothing I've tried does. The only way for regular video is via "Video Frame->Normal Size" or to use build v1249 or earlier.

What other details could be helpful? I've been trying to eliminate this as setup specific.

Update, in v 1269 it works, but not in v1290. Changing anything under Pan&Scan (like Scale to 16:9) or in Video Frame other than "normal" causes the video to go mostly blank with a one or two pixel tall line at the top of the video frame.

nightfly

30th December 2009, 00:32

Ok, my problem began in build v1276. Everything in regards to video scaling (essentially) is working fine in my setup in build v1274.

Looking at the change log from http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log

these are the two changes from 1274:
Revision 1276 - Directory Listing
Modified Thu Sep 10 20:50:42 2009 UTC (3 months, 2 weeks ago) by Spec-Chum

Only resize when src and dest sizes don't match and some cleanup of resize code

Revision 1275 - Directory Listing
Modified Mon Sep 7 23:28:15 2009 UTC (3 months, 3 weeks ago) by aleksoid

Update : MediaInfo header(0.7.21.0);

clsid

30th December 2009, 00:42

Might be due to the changes to imgconvert.c

Disable the internal FFmpeg video decoders in MPC and see if that makes a difference.

nightfly

30th December 2009, 01:28

Might be due to the changes to imgconvert.c

Disable the internal FFmpeg video decoders in MPC and see if that makes a difference.

I pulled up the wrong changes initially.. and listed 1375,1376 instead of 1275,1276.

Change 1276 lead me to my answer (I revised my post from above to show the correct changes). The file DX9AllocatorPresenter.cpp in trunk\src\apps\mplayerc contained the problem change.

line 2537:

if(rSrcVid.Size() != rDstVid.Size())

I replaced this snipit with the below code snipit from v1221 applied to v1453 of the file:

if((iDX9Resizer == 0 || iDX9Resizer == 1 || rSrcVid.Size() == rDstVid.Size() || FAILED(hr)))
if(iDX9Resizer == 0 || iDX9Resizer == 1)

And that worked..I can now resize using Pan&Scan & Video Frame without issue and now I can use seamless BDR video playback.

How can I get this issue looked at? I've tried to submit a bug over on SF with no luck so far, but will keep trying.

XhmikosR

30th December 2009, 02:07

You can add the issue here (https://sourceforge.net/apps/trac/mpc-hc/newticket).

leeperry

30th December 2009, 02:12

if windows7 works at 32bit float, its best to ouput the same thing straight from the decoder, in this case we have full control over the dithering used (if any)
W7's mixer works in 32fp, but you can still output 100% bit-perfect 16/24int through WASAPI excl./KS/ASIO if your drivers allow it..so lossless audio shouldn't be dithered and remain untouched, and lossy audio should only be dithered *once* from 32float(if anyone could ask the libavcodec guys to decode AC3/DTS to float :o) to 16/24int(depending on the drivers capabilities) at the very last stage(after all DSP processings)...either through Reclock or your new MPC audio renderer(or W7's mixer for that matter, but relying on m$ always backfires on ya at some point :D).

mikelebron

30th December 2009, 02:41

thanks for the info.. Actually the default Windows codec was launching, I had then tried FFDSHOWs VC1 codecs.. all stuttered without enabling enabled Frame Time correction but didnt look very good. Enabling the built in MPC-HC VC1 codec worked... Did not need to enable frame time correction and the final product looked pretty good (though not as good a H264 - seems the movies I have, have a ton of noise/film grain)...

Anyway.. thanks for the help.

mikelebron,

Are you are using ffdshow to decode h264/vc1, I don't think we can help with ffdshow.

Try the default mpc-hc setup - enable internal filters, and output "EVR Custom Pres.", Bilinear PS2.0, EVR Buffers 5, and enable "Reinitialize when display changing." Remove ffdshow from external filters, if present.

Also, nVidia & ATI drivers behave differently, so the same settings may not work on both, and may exhibit different behavior / bugs.