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. |
12th April 2009, 23:33 | #201 | Link | |
Registered User
Join Date: Jun 2005
Posts: 630
|
Quote:
fix reports a) overall CPU consumption is reduced on primary and I think for SD content at least the difference between HR and madVR is negligible. b). madVR properly reports that 10bit buffers are not available and engages 8bit buffers, and weirdly enough, no crashes or silent quits after than, video plays as normal bug confirmation reports 1. although the CPU consumption is down in total, still secondary monitor maxes one of the cores. Interesting enough, now with OSD I can tell that avrg present wait is actually about 3 times lower on the secondary monitor Still one of the cores is on maximum. As for the rest of parameters, I cannot see any substantial difference in times for any of the other parameters on two monitors. I even used ctrl+j twice, but all the numbers are nearly same whilst CPU usage is dramatically different. 2. Monitor refresh rate is not updated if you move to a different monitor. I think btw Beliyaal fixed that issue with EVRCP at some point, but that code is not in SVN yet (may be mistaken) important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate). Note that your code is the best so far when moving the window to a different monitor, as other renderers may have a small pause or blank screen displayed for a while when you move a window. Moving window with madVR is same as moving any normal application. Last edited by Egh; 12th April 2009 at 23:35. |
|
12th April 2009, 23:45 | #202 | Link | |
Registered User
Join Date: Jan 2007
Posts: 530
|
Quote:
|
|
13th April 2009, 00:07 | #204 | Link |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
I've tryed to overclock my card to see the benefits.
Clock description: Core / Shader / Memory Standard clocks 540 / 1188 / 700 Overclock Core and Shader 595 / 1404 / 700 Overclock All 595 / 1404 / 918 Overclocking only the Core and Shader clocks gives a ~4% performance increase, if I also overclock the memory it gives a ~9% performance increase. So, with madVR, the performance increase with my card was directly proportional to the clocks increase. |
13th April 2009, 00:52 | #205 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Nope here. Although it seems you have TV screen? I just run dualview with two monitors. It seems it always picks the refresh rate of the monitor it starts on. And i don't mean madVR per se, what I mean is the main MPCHC window. I.E. even if I start an empty window on one monitor, then move to another and drop a video into it, it detects the refresh rate of the original monitor.
|
13th April 2009, 00:54 | #206 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard
|
13th April 2009, 01:02 | #207 | Link | |
Registered User
Join Date: Jun 2006
Posts: 133
|
Quote:
Anyway, I don't mind keeping CTRLJ as long as there is another way to display the stats. |
|
13th April 2009, 01:27 | #208 | Link |
Registered User
Join Date: Nov 2008
Posts: 64
|
Hi, here some feedback.
System: WinServer2008 x64 - MPC HC special build - latest Nvidia drivers - latest DirectX drivers 8800GTS512 (G92) - 19" LCD 1280x1024 @72Hz over DVI 720p,h264,23.976fps,3Mbit/s encodes displayed at fullscreen (no stretch) CoreAVC w/o CUDA / MPC HC's internal decoder / DivX H.264 Decoder : display 72.0xxxxHz movie 23.976 fps frame queue pretty much always 16/16 movie resolution 1280,720 target rectangle 0,152,1280,872 vsync interval 13.90ms movie frame interval 41.71ms avrg gpu rendering time ~3ms max rendering time is ~4ms avrg present wait ~11ms those times are pretty stable and don't vary much from decoder to decoder. CoreAVC w/ CUDA same as above but: max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then. with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws. - framerate sometimes doesn't oszillate at all - time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes - I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems. - display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround - avrg present wait shows large negativ values immediately after pressing CTRL+J then it normalizes I'm afraid I can't tell something more distinct because it all seems so random. Last edited by vucloutr; 13th April 2009 at 01:43. |
13th April 2009, 02:21 | #209 | Link |
Registered User
Join Date: Mar 2008
Posts: 2,021
|
Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level. Avi/wav File Source > MadVR What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption???? Last edited by rica; 13th April 2009 at 02:43. |
13th April 2009, 04:16 | #211 | Link |
stuff and things
Join Date: Apr 2009
Location: Lee's Summit, MO USA
Posts: 1
|
Great renderer, it will be even better when you can make it output 0-255 and output smoother video. But those are pretty trivial, as other things can handle that sort of thing. You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI. My TV has all kinds of controls to handle and enhance colors and black levels to the room lighting (Philips 42pfl7422d/37), so it doesn't matter much.
I do have one request though, can you compile this for 64-bit windows? I'm going to be installing a newer build soon and Microsoft is really pushing the 64-bit thing, especially after Apple started with the whole Snow Leopard 64-bit schtick. It's seeming more and more that 64-bit will be the norm and I'm not sure of its capabilities in handling 32-bit programs; it's not like I can just do an 'apt-get install ia32-libs' or anything, that would make too much sense. Keep up the great work! |
13th April 2009, 04:22 | #212 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Well x64 version will be required in the future, as only x64 codecs may work with x64 mpchc and x64 decoders. Though here I haven't found any particular video yet which would consume substantially different amount of CPU% on x64 compared to x86. Maybe when lots of additional post-processing is involved, decoding itself doesn't load CPU differently.
Though recalling how much time required to persuade Haali to do x64 version )) He resisted for more than a year before finally surrendering :P |
13th April 2009, 08:14 | #214 | Link |
And so it begins...
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
|
Excellent renderer! For such fine piece of software I was waiting for!
I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing. I will be really happy when DVD works with madVR. Last edited by FoLLgoTT; 13th April 2009 at 08:16. |
13th April 2009, 09:49 | #215 | Link |
And so it begins...
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
|
@madshi
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing. If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs. ffdshow: madVR with resampling: madVR without resampling: The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz. ffdshow: madVR with resampling: Is this a bug or just a side effect of your upsampling algorithm? Last edited by FoLLgoTT; 13th April 2009 at 09:51. |
13th April 2009, 11:11 | #216 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
I wonder if anyone tried to create LUT's w/ custom primaries coordinates, coz I'm getting strange results...even the stock LUT's are way too dark, but yesgrey is on the case
Last edited by leeperry; 13th April 2009 at 11:26. |
13th April 2009, 11:23 | #217 | Link |
Registered User
Join Date: Dec 2008
Posts: 29
|
Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
|
13th April 2009, 11:58 | #218 | Link | |||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters. |
|||||||||||||
13th April 2009, 12:06 | #219 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots? I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible... But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful? Can you see the "missing" frequency response in any real life pictures? |
|||
13th April 2009, 12:19 | #220 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
that's my RGB32HQ picture : http://www.image-load.eu/out.php/i157521_rgb32hq.png now w/ ddcc doing the gamut conversion(8bit LUT created in ddcc) in HR : http://www.image-load.eu/out.php/i157519_ddcc.png and that's w/ a 16bit LUT from yesgrey's app in t3dlut() : http://www.image-load.eu/out.php/i157520_lut.png so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees. and I'm getting opposite results when I put this LUT in madVR that's w/ ddcc(8bit LUT created in ddcc) in HR : http://www.image-load.eu/out.php/i157518_hr.png this is the stock HD LUT in madVR : http://www.imagebam.com/image/43c8ae32526309 and this is my custom 16bit LUT : http://www.imagebam.com/image/c716bb32526310 I know ddcc "works" coz it matches what the PS script outputs(slightly better of course)... I think you may wanna give the option to the user to choose untouched levels or TV>PC conversion, and then make 2 LUT's : SD: REC.601 (untouched levels OR levels expansion from TV to PC) HD: REC.709 (untouched levels OR levels expansion from TV to PC) but anyway, the CMS is pretty broken right now I think, waiting for yesgrey's feedback Last edited by leeperry; 13th April 2009 at 12:27. |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|