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. |
27th December 2009, 21:01 | #11001 | Link | |
Registered User
Join Date: Aug 2008
Posts: 176
|
Quote:
|
|
27th December 2009, 22:18 | #11002 | Link | ||
Registered User
Join Date: Mar 2009
Posts: 962
|
Quote:
Quote:
|
||
27th December 2009, 23:30 | #11003 | Link | |
Registered User
Join Date: Aug 2009
Posts: 50
|
Quote:
|
|
28th December 2009, 00:07 | #11005 | Link |
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) |
28th December 2009, 02:56 | #11006 | Link |
Registered User
Join Date: Mar 2004
Posts: 140
|
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.
|
28th December 2009, 03:08 | #11007 | Link |
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.
|
28th December 2009, 08:06 | #11009 | Link | |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
Quote:
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC |
|
28th December 2009, 09:43 | #11011 | Link | |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
Quote:
Anyway it seems a problem of FFmpeg/libavcodec and CoreAVC decoder... |
|
28th December 2009, 09:57 | #11012 | Link | |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
Quote:
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 |
|
28th December 2009, 10:47 | #11013 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
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.
|
28th December 2009, 11:25 | #11014 | Link |
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 |
28th December 2009, 13:55 | #11015 | Link | |
Registered User
Join Date: Nov 2003
Posts: 63
|
Quote:
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 |
|
28th December 2009, 15:52 | #11016 | Link |
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?
|
28th December 2009, 16:11 | #11017 | Link |
MPC-HC Project Manager
Join Date: Mar 2007
Posts: 2,317
|
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 |
28th December 2009, 16:38 | #11018 | Link | |
Registered User
Join Date: Mar 2009
Posts: 962
|
Quote:
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. |
|
Tags |
dxva, h264, home cinema, media player classic, mpc-hc |
Thread Tools | Search this Thread |
Display Modes | |
|
|