View Single Post
Old 14th April 2009, 08:07   #261  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Brazil2 View Post
I'm still having aspect ratio troubles with the two samples I've posted here.

The first sample (VC-1 in MKV) gives me the correct aspect ratio with the MPC-HC built-in decoder. I always got a wrong aspect ratio when the Microsoft decoder is used and it doesn't matter which splitter is used.
The VC-1 aspect ratio problem will be fixed in the next build.

Quote:
Originally Posted by Brazil2 View Post
Now I got different results with the Beyonce TS sample depending on which combination of splitter + decoder is used. So I've done more tests:

Splitter + Decoder = aspect ratio result

MPC-HC + MPC-HC = wrong
MPC-HC + Arcsoft = wrong
MPC-HC + CoreAVC = OK
MPC-HC + Divx7 = wrong
Hmmmmm, it seems that with e.g. divx7 the correct aspect ratio is only available after playback already started. Will have to look into this.

Quote:
Originally Posted by Egh View Post
It seems now there's no difference between primary and secondary monitor in terms of CPU consumption, only thing matters is what monitor the video has been initialized in!!! The following scenario is now valid: open an empty window on primary, move to secondary, drop a video into it -- no core maximisation ;P move the window back to primary -- maximisation is present again If I revert the order of monitors in this scenario and do it again, same thing happens.

To sum up, it is possible to use a workaround now, which is to force madVR to reinitialize on a different monitor. That apparently fixes now both refresh issue and CPU consumption. Only thing now is to make it work automatically )
Yeah, madVR does currently not detect when you move the media player window to another monitor. Will need to add that.

Quote:
Originally Posted by tetsuo55 View Post
Nope,it just flashes on the screen for a second and is gone.
Manually running the command from a admin command prompt works fine
Could you please try starting the batch from a command prompt, so that you can see (and report) the error message?

Thanks!

Quote:
Originally Posted by tetsuo55 View Post
I did some more tests.
High CPU consumption is caused by the OSD stats(ctrl-J)
That makes sense. It's not 100% for me, but with OSD active I'm doing some things differently to be able to output reliable statistics. This different way of doing things costs a lot more CPU.

Quote:
Originally Posted by tetsuo55 View Post
With everything disabled i get +/- 50ms
Well, you could still switch scaling to "Bilinear", that is done by the graphics card "for free". Doing that might push you under 40ms. But of course then you have lost many advantages of madVR. So I'd say with your graphics card using madVR does not really make that much sense, unless you want to use madVR for gamut&gamma correction...

Quote:
Originally Posted by ericgur View Post
When pressing CTRL+ALT+DEL (going into the screen where you can lock your computer or start task manager) and coming back to the desktop, the player crashes.
Thanks, will look at that.

Quote:
Originally Posted by ericgur View Post
The other issue is minor, when MadVR is first launched, no setting are set in the DS property page. Maybe the default scaling algorithm should be set.
Works for me!

Quote:
Originally Posted by vucloutr View Post
Well for the 720p files I checked already "max gpu rendering time" -> "resample textures" (which was "update textures" before?)
has gone up to ~4ms from ~2ms before but "average gpu rendering time" is practically as good as with madVR 0.3.
With v0.3 there were 2 separate lines "update textures" and "resample textures". Now with v0.4 "update textures" is gone, because I'm not doing that myself, anymore. Instead I leave that to Direct3D. Probably "resample textures" takes more time because of that now. The "average gpu rendering time" is unchanged for me, too.

Quote:
Originally Posted by yesgrey3 View Post
There is no problem with madVR nor with cr3dlut. leeperry was just using a custom output gamma curve different from the input gamma curve.
But why does he get different results from t3dlut and madVR?

Quote:
Originally Posted by leeperry View Post
OTOH some BD's seem very hard to stabilize w/ CoreAVC+all my PP, but as soon as I turn CUDA on...hell breaks loose, I get tearing at the third quarter bottom of the screen(and reseeking does not help).

do any of the stats look alarming? it plays fine in HR(RGB32).
Stats look beautiful.

Quote:
Originally Posted by Malow View Post
an 9800GT Pci-E 2.0 @ 16x is not capable of output 60fps video at 1920x1200 screen?

wen using BOB on interlaced material, the playback is jerky. but if not viewing in fullscreen (resizing the window to 75% of display) the playback is smooth.

this happens with madVR and haali renderer... only crappy overlay can play full-hd video at 60fps...
Please post madVR statistics (Ctr+J).

Quote:
Originally Posted by Shinigami-Sama View Post
was working last time I played it
The MPC Video decoder bug occurs only when the decoder is forced to output YV12.
madshi is offline   Reply With Quote