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

[flanger216]

Originally Posted by madshi

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]

Originally Posted by flanger216

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.

Originally Posted by flanger216

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...

Originally Posted by flanger216

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]

Originally Posted by Andy o

So, 20 thousand seconds jitter?

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]

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.

Originally Posted by madshi

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]

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]

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

[thrawnrulz68]

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]

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]

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

[betaking]

Originally Posted by clsid

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]

Originally Posted by madshi

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]

Originally Posted by flanger216

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]

Originally Posted by flanger216

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]

Originally Posted by madshi

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]

Originally Posted by Andy o

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]

Originally Posted by nlnl

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]

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?

Originally Posted by mikelebron

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]

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]

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]

Originally Posted by thrawnrulz68

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.