View Single Post
Old 13th April 2009, 11:58   #218  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by leeperry View Post
that'd be fun if you could put 3 or 4 digits after the coma for the VSYNC interval.
Not needed. The VSync interval is just calculated by doing "1000 / display refresh rate" and the display refresh rate is displayed with enough digits. So you can calculate the VSync interval yourself. But please note that the display refresh rate is not 100% perfect. So take those additional digits with a grain of salt!

Quote:
Originally Posted by buletti View Post
Could that be the cause of the high CPU load? The copy operation from RAM into VRAM is done by the CPU and is a rather slow operation AFAIR.
Well, the data has to be transported to the GPU somehow. All the other renderers must do that, too, sooner or later. Actually if you feed other renderers with RGB data or even with upscaled data, you have to send more data from RAM to GPU than madVR does! So I still don't see why madVR should consume more CPU.

Quote:
Originally Posted by Snowknight26 View Post
Can anything be done about an error that says "graphics card only supports power of 2 textures?" Happens with my GM45.
Unfortunately there's not so much I can about that. The error message means that your GM45 only supports textures which follow strict resolution patterns. Basically textures on your graphics card must have a width and height of one of the following numbers: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096. Now madVR needs textures in the resolution of the source (e.g. 720x480 for NTSC-DVD) and in the resolution of the display (e.g. 1920x1080). Your GM45 seemingly does not support textures in such "odd" resolutions. Probably it would be possible to use the next higher supported resolution like e.g. 2048x2048, but that would make texture addressing in my shaders a lot more complicated. So I'd rather not support that. I fear the GM45 would be too slow, anyway...

Quote:
Originally Posted by vucloutr View Post
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
These are extremely good numbers. Of course it helps that you have 1:1 display and don't need to scale.

Quote:
Originally Posted by vucloutr View Post
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.
Interesting!

Quote:
Originally Posted by vucloutr View Post
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
If the time counter goes up a lot that helps exactness of the display refresh rate calculation. The time counter restarts from 0s, if madVR ran into any kind of trouble interpreting the VSync data.

Quote:
Originally Posted by vucloutr View Post
- 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.
That problem should be solved in a future version of madVR. Might take a while, though...

Quote:
Originally Posted by vucloutr View Post
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
Do you really have to minimize/restore? The display refresh rate detection should be able to recover automatically. It retries measurements every second.

Quote:
Originally Posted by rica View Post
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????
Weird!!

Quote:
Originally Posted by Mutiny32 View Post
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.
Yeah, but how do you know what the driver does internally? E.g. with ATI cards even if you do select YCbCr output, BTB and WTW are clipped, which is a strong indicator that the graphics card internally does YCbCr (video) -> RGB (PC) -> YCbCr (video), which I consider bad.

Quote:
Originally Posted by Mutiny32 View Post
I do have one request though, can you compile this for 64-bit windows?
I've already replied to this question a few posts before.

Quote:
Originally Posted by FoLLgoTT View Post
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.
Ok, will add 8 tap Lanczos. But in my tests it didn't look any better than 4 tap Lanczos. Actually it looked worse to me, because it was not any sharper and only ever so slightly less aliased, but had very noticeable double ringing!

Quote:
Originally Posted by leeperry View Post
...even the stock LUT's are way too dark, but yesgrey is on the case
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?

Quote:
Originally Posted by VHT View Post
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.
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.
madshi is offline   Reply With Quote