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. |
11th April 2009, 16:55 | #122 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
show me a DVI display that does >8bit and doesn't cost an arm and a leg there's some graphic adapters that support 10bit HDMI 1.3(nvidia IGP's), but not too many ppl talk about them...let alone post benchmarks. |
|
11th April 2009, 17:50 | #123 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
well, it works just fine w/ CoreAVC CUDA on XP SP3 here(latest DX9/nvidia drivers updates) w/ ffdshow video(LSF/GrainF3 in the avisynth filter) in YV12 on a GF9600GSO(96SP) + ffdshow audio(volume/mixer/Ozone4 winamp plugin)/AC3filter in 32float on an o/c Q6600.
it sucks a helluvalot of CPU cycles when paused, but that's about it....also, it looks very smooth w/ Reclock in 25@48.000Hz will try it on the big screen this evening if you could set one LUT for SD, and one for HD I'd be sold...and faking HR's GUID so it'd work in KMPlayer would be the icing on the cake. PS1: from what I understand CUDA doesn't use the GPU itself, only the VP2 routines. in the past I was using the gamut conversion PS script(from yesgrey) in HR w/ Avishader() w/o any problem. PS2: sending a 720p video in 1280*768 is VERY sharp! is it 1:1? or is that to say that HR indeed has a "soft" picture? this point has been thoroughly debated on HCFR Last edited by leeperry; 11th April 2009 at 18:43. |
11th April 2009, 20:35 | #124 | Link | ||||||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Thanks for the report. I've investigated that and it's a clear bug in the MPC Video decoder. It only shows with madVR because if you use a different renderer, the MPC Video decoder usually outputs YUY2. madVR forces it to use YV12 and it seems that the MPC Video decoder bug only shows this way. I've already reported the bug to the MPC HC guys... Quote:
Quote:
Quote:
Quote:
Quote:
No, it doesn't. At least not on my PC. How did you get it to accept YUY2? Doesn't work for me in GraphEdit... Quote:
Quote:
Quote:
Quote:
That's because it seems to be rocket science to ask Windows which background color a themed window has... I still haven't found out how to do this properly! Quote:
Quote:
ATI HD3850. Seems just about fast enough for 1080p24 playback with resizing activated. Planning to upgrade to an ATI HD4770 when it's released (early May). Quote:
Quote:
Quote:
Quote:
With which decoder? With the MPC Video decoder? Try the MS one (see above). Not for me!! I think with a 1:1 match between display refresh rate and source frame rate even the current simple logic implemented in madVR can produce very smooth results. However, as soon as you don't have 1:1, things can quickly get very ugly. Quote:
I'm not sure if Haali is inherently soft. I was hoping that you guys would test that and report back! What I noticed is that Haali's scaling solution sometimes produces artifacts (ghost lines). That indicates that maybe there's something wrong. Also I'm not sure if Haali is deactivating scaling if no scaling is needed. Of course madVR only scales if necessary. Scaling is even "half" deactivated by madVR if scaling is only needed into one dimension... |
||||||||||||||||||
11th April 2009, 20:46 | #125 | Link | |
Registered User
Join Date: Aug 2007
Posts: 59
|
Quote:
With the 9500GT I see no difference in CPU usage. Doesn't the 9500GT support CUDA? I thought the entire 9 series did that. I don't mind, my processor doesn't have a problem with highbitrate AVC decoding. |
|
11th April 2009, 20:49 | #126 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
but I mean is it a true 1:1 mapping, no lanczos sharpening or anything if the scaler is not enabled? like playing 720p in 1280*768 the ghost lines of HR's internal scaler are due to a bad sum in the PS code(Haali wrote the PS scaler code in MPC, and when Casimir666 set it to 0.98 instead of 1.0...it fixed the glitch : http://mpc-hc.svn.sourceforge.net/vi...79&pathrev=380 ) this problem also occurs on nvidia if you set the zoom too high, but it's much worse on ATi's. well there's always been 2 schools on HCFR, one that swears by HR's smoothness and the other one that finds HR too "soft" compared to EVR/VMR9...which the other side finds "oversharpened" I believe your renderer's sharper than HR(in native res of course), but I'll wait for Kazuya's feedback on this...BTW, when HR says "NN" in its OSD, it's supposed to keep all scaling disabled. I understand you got a huge TODO list, but adding one LUT for SD/one for HD, and giving the opportunity to fake the GUID would be really awesome(sorry to repeat myself)...would love to have it working in KMP w/ proper 601/709 decoding PS: I ran more tests, w/ perfectly matching refresh rates(23.976/24/25@48.000)+Reclock it's just perfectly smooth ....and it doesn't look oversharpened, so I guess HR is indeed "soft" but until it allows 2 different LUT's for SD/HD, it's not quite usable yet..or maybe w/ a null LUT in madVR and 2x LUT's in tritical's plugin. lemme ask yesgrey also, while seeking sometimes it missed the VSYNC fliptime...but that's quite rare. Last edited by leeperry; 11th April 2009 at 21:41. |
|
11th April 2009, 21:03 | #127 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
I just thought I'd mention that with my 7800GTX 512 (faster memory, but slower core then 7900GTX with overall comparable performance), I'm not seeing any of the CPU usage issues that Egh is on 1080p video. CPU usage for madVR seems identical to (and possibly even slightly less then) Haali on my system. CPU usage is 0% when paused, so I'm not having that issue either.
As I mentioned in my previous post I use WinXP SP3, so if Egh doesn't, maybe that is the problem rather then his graphics card. Also of note is madVR uses ~200MB more RAM then Haali, so if you have high latency or not enough RAM, maybe that could contribute to the problem, but for some reason that seems to be an unlikely cause. Last edited by cyberbeing; 11th April 2009 at 21:15. |
11th April 2009, 21:40 | #128 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Well then I'll open you a secret -- most displays are only 6bit native. The other 2bits per channel are achieved by dithering (therefore some color artifacts may be observed). Even for 8 bit proper colour you need to look only for displays with S-IPS or S-PVA matrices, and that is not used in anything below 22" nowadays, and only few models.
|
11th April 2009, 22:08 | #129 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
and I'm well aware than most(TN?) panels don't actually show 8bit...I'm not sure what you're trying to prove here, but you just made it to my ignore list OK I'm gonna try to play a 2H movie in MPC w/ mVR, hopefully it won't drop like crazy after 1H(like non-D3D VMR9/EVR always do in MPC w/ Reclock) Last edited by leeperry; 12th April 2009 at 00:43. |
|
11th April 2009, 22:19 | #130 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
Just by scratching my head though I was able to find the cause. Madshi: bug report #1 here! Crazily enough, it maxes one of the cores always independent of the actual video (can be even paused) if it is rendered onto non-primary display I have two monitors, if I move the window from one to another then madVR consumes CPU if the monitor being rendered on is not the current primary. I switched the primary monitors in Nvidia Contol Panel and observed the same behaviour but on the other monitor. Madshi: bug report #2 here! If MPC AVC internal is used (no DXVA per definition here), 1920x1080 videos are rendered incorrectly, colors are weird, a yellow bar all the way in the bottom of the frame etc. No such problem if ffdshow avc decoder is used (and fed to YV12). No such problem if 720p video is decoded by internal MPC codec. Last edited by Egh; 11th April 2009 at 22:28. |
|
11th April 2009, 22:27 | #131 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Then you ask me if you get 1:1 mapping when playing 720p in 1280x768? How am I supposed to know how your media player is configured? madVR does what the media player asks it to do in terms of scaling. Of course if the media player asks for playback in 1280x720 with a 1280x720 source then madVR does simple 1:1 with no scaling and no sharpening. If the media player asks madVR to scale a 1280x720 source to 1280x768 then madVR does scale, but only in Y direction. Sharpening is currently not applied by madVR at all. There are just softer and sharper scaling algorithms available for selection, which of course are only used if scaling is asked for by the media player... |
|
11th April 2009, 22:31 | #132 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
I already replied to this somewhere in my last "monster" reply post. |
|
11th April 2009, 22:55 | #133 | Link | ||
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
In my case colours are totally distorted, not just wrong levels or so. Probably some colour planes problem. Quote:
|
||
11th April 2009, 23:16 | #134 | Link |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
I've narrowed the tearing down on my system (2600XT) to when Zoom Player is on the SECONDARY monitor.
If I switch the primary monitor to the video playback one, it doesn't tear. But it's not smooth, it has little jerks and jumps (yes, I know this will be ignored for now, but just reporting what I found). Can somebody else with a multi-monitor system try it on the secondary monitor? Preferably at 23.976hz or a multiple thereof. Someone with a beefy videocard would be helpful, to narrrow this down to a secondary monitor issue. Thanks Mark |
12th April 2009, 00:06 | #135 | Link | |
Registered User
Join Date: Jul 2008
Posts: 532
|
Quote:
Does this also mean that I should create one file per format / resolution ? For instance one for Xvid 512*288, one for H264 1280*720, one for VC-1 1920*1080, etc. I admit I'm a bit lost about how it works... |
|
12th April 2009, 00:08 | #136 | Link | |
Registered User
Join Date: Jan 2007
Posts: 530
|
Quote:
XPSP3, MPC-HC, CCC9.4 |
|
12th April 2009, 00:13 | #137 | Link |
Registered User
Join Date: Jul 2008
Posts: 532
|
Here you go:
http://www.zshare.net/download/58510577a2d908e4/ Cut with DGSplit so I believe it still has the original header. Yesgrey3 gave me some infos, however I'm afraid I'm still a bit lost about these 3dlut files. It would be nice to have this process automated to avoid confusion and possible mistakes. Last edited by Brazil2; 12th April 2009 at 00:17. |
12th April 2009, 00:34 | #139 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
anyway my 2H movie went just fine in MPC+Reclock at 25@48.000Hz, so that's cool! if you could find a way to never miss the VSYNC fliptime(triple buffering?), that'd be the final solution for a foolproof Reclock HTPC until you add a LUT management for SD, I will keep madVR for HD movies only...very impressed so far, keep it up PS: just to be clear(english not being my native tongue), if I play 720p stuff in 1280*768 in HR, its OSD will show "NN" meaning it simply added horizontal black bars w/o rescaling..but I guess madVR does the same Last edited by leeperry; 12th April 2009 at 02:02. |
|
12th April 2009, 00:49 | #140 | Link | |||
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
Quote:
Quote:
No. Only by video format, and not for all, because some of them use the same file. |
|||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|