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. |
20th April 2009, 00:01 | #462 | Link |
Registered User
Join Date: Feb 2006
Posts: 293
|
Just a short feedback (since the conversation reach the point where I can't really catch up), madVR 0.6 seem to detect my monitor refresh rate wrong when watching full screen. It reports ~68-75 Hz instead of ~60 Hz, which is the correct one. My guess is that it may have something to do with the fact that playback is not smooth because when I change scaling method to Nearest Neighbor, which make it play smoothly, the refresh rate is correct again.
|
20th April 2009, 00:42 | #464 | Link | |
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
Here´s a shot: I´ve tried a lot of different combinations to narrow it down and I think I actually found the cause of this. To reproduce this, please e.x. play any .wmv file with ffdshow as audio/video decoder (works as it should) and after that use the supplied MS DMO decoders (doesn´t work). It seems to be decoder dependent, as the same error happens if you decode .mov or .mp4 with coreavc, but it doesn´t happen if you use ffdshow only. Apart from that (0.4 vs. 0.6): +faster startup (confirmed) +window/fullscreen switching has improved a lot +subjectively it looks a bit smoother on my CRT (running @100Hz) +max. rendering time shows less spikes Since now you can select luma/chroma independent of one another, avg rendering time is a lot higher if you go crazy e.x. with the luma, but that´s to be expected. I´ve tested this on a very powerful GTX260-216 (@GTX285 speeds). Other testers should take that into account when comparing between 0.4 and 0.6. wolverine-tlra_h1080p.mov (first official trailer): movie frame interval: 41.71ms avg gpu rendering times (luma/chroma): Bilinear/Bilinear - 2.7ms SoftCubic50/SoftCubic50 - 3.8ms SoftCubic50/Spline36 - 4.5ms Spline36/Spline36 - 6.5ms Lanczos8/Spline36 - 8.9ms Lanczos8/Lanczos8 - 9.8ms max. gpu rendering time was always higher by about ~1.7ms Last edited by iSunrise; 20th April 2009 at 00:49. |
|
20th April 2009, 01:17 | #465 | Link |
Guest
Posts: n/a
|
Here are some performance numbers from two different machines. Configuration is the same (Vista SP1, MPC-HC 1059 SVN, ReClock 1.8.4.2 no resampling no vsync, madVR 0.6, CoreAVC 1.9.5.0), playing Iron Man (US) AVC BD from HDD.
(1) MacBook Pro 2008, 2.4GHz C2D, nVidia 8600M GT 128MB (G84M), 1920x1080 resized to 1440x900 display: avg gpu rendering time: 42.69ms 25.75ms resample textures 2.27ms clear 0.16ms init samplers 14.55ms render max gpu rendering time 46.14ms 31.25ms resample textures 2.28ms clear 0.22ms init samplers 14.62ms render avrg present wait 2.04ms (1) Desktop PC, 2.6GHz A64 AM2, nVidia 9600 GT 1024MB (G94), 1920x1080 resized to 1680x1050 display: avg gpu rendering time: 14.44ms 8.96ms resample textures 0.19ms clear 0.25ms init samplers 3.64ms render max gpu rendering time 18.22ms 13.63ms resample textures 0.82ms clear 0.23ms init samplers 3.66ms render avrg present wait 1.90ms Last edited by honai; 20th April 2009 at 01:36. |
20th April 2009, 01:19 | #466 | Link | |
Registered User
Join Date: Jan 2009
Location: UK
Posts: 403
|
Quote:
|
|
20th April 2009, 01:30 | #468 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
I just gave madVR a first try. I noticed that madVR is rendering at 60 fps (measured with FRAPS), although the movie is only 24 fps. It plays at correct "speed" though, the audio is in sync too. However when I watch the same video with EVR then it renders at 24 fps (again measured with FRAPS). The difference is that the EVR version plays 100% smooth, while the madVR version plays slightly jerky. This is quite surprising, as my GTX 260 should have enough power for madVR, I guess. If not, what monstrosity of a GPU do I need to use that renderer? Also I noticed that the framerate drops from 60 fps to ~50-40 when I go fullscreen and/or use a more "heavy" scaling method (e.g. Spline64). I'm using CoreAVC as my decoder. Tried both, with and without CUDA enabled, but no noteworthy difference...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 20th April 2009 at 01:44. |
20th April 2009, 03:11 | #470 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
But why? If the movie framerate is significant lower than the monitor refresh rare (like 24 fps -vs- 60 Hz) this will cause the same frame to be rendered several times. That's a huge waste of processing power, isn't it? Also I guess that this is the reason why madVR doesn't play 100% smooth. As can be checked easily, the rendering rate will often drop below the screen refresh rate - especially in fullscreen mode and when one of the more "heavy" scaling methods is used. EVR as well as Haali Renderer will render at the movie framerate and I get perfectly smooth playback with these renderers. With madVR the video plays slightly jerky. It's not that much jerky, but enough to be annoying and to prefer another renderer for the time being. Nobody else experiencing that?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
20th April 2009, 04:22 | #473 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Well, madVR 0.6 is definitely a step to the right direction. Start-up time is greatly improved!
As for using or not using 3DLUTs, I cannot spot any difference really during playback (in terms of CPU consumption). Do they really work now? Comparing to Haali renderer, for SD content (dvd rezo) cpu usage is practially same, and interestingly enough, that seems to be irrelevant of the actual upscale method used. For 720p content here (avc), madVR uses more cpu power, but not much so. For the same file CPU usage is typically under 20% with HR and typically under 30% with mVR. Of course that is not constant, so sometimes HR may use 15%, mVR may use around 22% at the same scene. However 1080p content (I use downscaling to 720p) takes more CPU than 0.4 version, in my opinion. mVR is not as smooth though as Haali, I can spot the difference on panning scenes. Not really troublesome, but somewhat annoying during such scenes. However that was measured @ CRT monitor @ 100Hz, where mVR fails to keep the rate for long, I think the record was 6 or 7 seconds. On my LCD display (60Hz) though it is very accurate and keeps 4 digits precision for minutes. A choice of PC/TV levels is superb, however still second my request for future choice between 601/709 (i.e. it should be automatic based on resolution but with an option to change it from the mVR dialog). |
20th April 2009, 04:47 | #474 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
I always create my luts (using custom primaries) manually so I don't really want my luts created automatically. They didn't get created automatically because I didn't feel the need to copy over the cr3dlut directory included with madVR 0.6. Basically it was missing the new template files. Automatic creation did work when I overwrote the madVR 0.4 cr3dlut directory with the madVR 0.6 cr3dlut directory. In any case, please include this change and any future changes like this to the changelog. It also may not be a bad idea to add an option to disable automatic lut creation as well. ___________________ Bug Edit: In madVR 0.6 the resampling isn't working properly when video resolution = display resolution. By that I mean it is for some reason resampling textures when no resize is needed. The resampling textures latency when changing between resize algorithms will change drastically even in this no resize situation. Since this causes latency (resample + render time) to go above frame interval on 1920x1080 video it's a major problem. It seems 0.4 has a similar, but much less noticeable problem, since it only resamples the chroma (~5ms avg | ~14ms max) when source resolution = display resolution, while 0.6 resizes both luma and chroma (~20ms avg | ~30ms max) with the specified settings when source resolution = display resolution. This is not the desired behavior. A workaround is manually changing the resize algorithm to bilinear. Edit 2: Something else really odd is going on when video resolution = display resolution (likely related to the bug above). If I choose Spline64 for luma and Catmull-rom for chroma, resample latency is ~5ms avg. If I choose Catmull-rom for both luma and chroma, resample latency is still ~5ms. If I choose Spline64 for luma and Bilinear for chroma, resample latency is ~9ms. If I choose Bilinear for luma and Spline64 for chroma, resample latency is ~14ms. If I choose Bilinear for both luma and chroma, resample latency is ~0.02ms. This suggests there may be a more significant problem in the resize code. Last edited by cyberbeing; 20th April 2009 at 08:20. Reason: Added a bug |
|
20th April 2009, 08:01 | #475 | Link | |
Registered User
Join Date: Apr 2007
Posts: 220
|
I think he has a point here. If picture content does not change it makes no sense to render again for the next screen refresh. If one plays back 23.976 material with 47.952 it's twice the unneccessary load and with higher refresh rates its even worse. Subtitles and OSD could still be superimposed every screen refresh. It would probably solve a lot of GPU speed issues for most.
Quote:
|
|
20th April 2009, 08:28 | #476 | Link | |
Registered User
Join Date: Feb 2007
Location: Palermo (Italy)
Posts: 67
|
Quote:
I use a monitor at a time (single monitor), so it's not a dual monitor problem. I didn't tried 60Hz and didn't tried in XP, so it could be a Win7 problem. Unfortunately I can't try at work, because I get the "card only supports power of 2 textures" error. So I'll try tonight. BTW, I tried to overcome the power of 2 limitation resizing the video to a power of 2 (1024x1024) with ffdshow, but it didn't work. |
|
20th April 2009, 09:01 | #477 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Speaking of the refresh rate detection, it still isn't working perfectly over here with 0.6 even after your improvements. Very often at times between 1s and 12s it always seems to reset back to 1s, yet rarely it seems to go on forever without issue. Whether it works well or not seems completely random with no correlation with resolution or refresh rate. On the positive side, the values reported do seem accurate and don't fluctuate much (+/- 0.00010Hz) even when it resets itself back to 1s. Would you consider this acceptable enough or are you expecting it to never reset itself?
Last edited by cyberbeing; 20th April 2009 at 09:06. |
20th April 2009, 09:05 | #478 | Link |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
Just tried v0.6, and it's smooth. Very, very smooth. Wow.
I'm trying it with Reclock set to "bypass" now, jsut to see. What did you do Madshi? I need to compare it to Beliyaal's MPC builds, to see which is smoother for primetime use Umm....what happen to the OSD tick box? How do I turn the OSD on? I like the PC/TV levels buttons. Except they're backwards. Well...actually they are the right way round if you ask me, but everyone else does it backwards, so there is a defacto standard. If you are going to label them differently, can you do it in a similar fashion to ffdshow, which is very clear, no confusion. Oh, I still have the issue where Zoom Player exits when I play the second file. Vista32, HD2600XT, ZP 6. Thanks Mark |
20th April 2009, 09:06 | #479 | Link | |
Matroska find' ich toll
Join Date: Apr 2008
Posts: 1,370
|
Quote:
ATI or NVIDIA what is better? hubble |
|
20th April 2009, 09:28 | #480 | Link | |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
Quote:
Ok, a bit more experimenting... It's smooth with Reclock running as per normal. No tearing. It's not smooth with Reclock "bypassed" (Slave and Original speed set). Still no tearing/ And I'm going bananas over the OSD thing. Others are posting their data and I can see a way to turn the darn thing on. Am I going round the twist? |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|