Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 27th December 2009, 21:01   #11001  |  Link
nlnl
Registered User
 
Join Date: Aug 2008
Posts: 176
Quote:
Originally Posted by flanger216 View Post
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!

nlnl is offline  
Old 27th December 2009, 22:18   #11002  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 962
Quote:
Originally Posted by flanger216 View Post
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
Quote:
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.
Andy o is offline  
Old 27th December 2009, 23:30   #11003  |  Link
matthew_eli
Registered User
 
Join Date: Aug 2009
Posts: 50
Quote:
Originally Posted by namaiki View Post
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...
matthew_eli is offline  
Old 27th December 2009, 23:34   #11004  |  Link
namaiki
Registered User
 
Join Date: Sep 2009
Location: Sydney, Australia
Posts: 1,073
Quote:
Originally Posted by matthew_eli View Post
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?
namaiki is offline  
Old 28th December 2009, 00:07   #11005  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
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)
wOxxOm is offline  
Old 28th December 2009, 02:56   #11006  |  Link
flanger216
Registered User
 
Join Date: Mar 2004
Posts: 140
Quote:
Originally Posted by Andy o View Post
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.
flanger216 is offline  
Old 28th December 2009, 03:08   #11007  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 962
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.
Andy o is offline  
Old 28th December 2009, 07:21   #11008  |  Link
lych_necross
ZZZzzzz...
 
lych_necross's Avatar
 
Join Date: Jan 2007
Location: USA
Posts: 303
Quote:
Originally Posted by leeperry View Post
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?
lych_necross is offline  
Old 28th December 2009, 08:06   #11009  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by wOxxOm View Post
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)
AR and SAR correction is virtually non-existant when using mpc-hc.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline  
Old 28th December 2009, 09:11   #11010  |  Link
matthew_eli
Registered User
 
Join Date: Aug 2009
Posts: 50
Quote:
Originally Posted by namaiki View Post
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...

Last edited by matthew_eli; 28th December 2009 at 09:13.
matthew_eli is offline  
Old 28th December 2009, 09:43   #11011  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
Quote:
Originally Posted by tetsuo55 View Post
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...
wOxxOm is offline  
Old 28th December 2009, 09:57   #11012  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by wOxxOm View Post
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
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline  
Old 28th December 2009, 10:47   #11013  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by flanger216 View Post
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.
madshi is offline  
Old 28th December 2009, 11:25   #11014  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
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.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline  
Old 28th December 2009, 13:55   #11015  |  Link
krbo
Registered User
 
Join Date: Nov 2003
Posts: 63
Quote:
Originally Posted by krbo View Post
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
krbo is offline  
Old 28th December 2009, 15:52   #11016  |  Link
88keyz
Registered User
 
Join Date: Jun 2005
Location: Canada
Posts: 29
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?
88keyz is offline  
Old 28th December 2009, 16:11   #11017  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by 88keyz View Post
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?
both areequally broken but in different area's. Use the one that works correctly for your files.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline  
Old 28th December 2009, 16:38   #11018  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 962
Quote:
Originally Posted by krbo View Post
I've noticed jitter times of 20 million milliseconds during such behaviour!!
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.
Andy o is offline  
Old 28th December 2009, 16:41   #11019  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by Andy o View Post
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.
ffdshow one is the same as mpc-hc one.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline  
Old 28th December 2009, 17:15   #11020  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 962
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?
Andy o is offline  
Closed Thread

Tags
dxva, h264, home cinema, media player classic, mpc-hc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.