View Single Post
Old 16th May 2009, 22:49   #1035  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR 0.10 released

http://madshi.net/madVR.zip

Code:
* added first (buggy) version of smooth motion rendering
* added uploading queue (up to 8 frames)
* added rendering queue (up to 8 frames)
* added information about dropped and delayed frames to OSD
* removed GPU rendering times from OSD
* added (buggy) frame stepping support
* modified DVD / macrovision handling slightly
* display refresh rate detection should no longer produce incorrect results
* added separate controls for luma upscaling and downscaling
* fixed: image was sometimes offset in 1:1 mode in ZoomPlayer
Hurray, first smooth motion version out!

Unfortunately I've found that it's next to impossible to get things *perfectly* smooth in windowed mode (at least on my PC). So perfection will have to wait until madVR is able to do fullscreen exclusive mode. However, my current development PC is not the fastest/best, so maybe you can get good enough results with madVR even in windowed mode, if your PC works better than mine. At least madVR 0.10 should be a lot smoother than older versions (I hope).

Technically the problem is that whenever you tell the GPU to display a rendered frame during the next vsync blank, the GPU stalls and stops doing anything else until the next vsync blank finally occurs. That means that if madVR asks the GPU very early to display a rendered frame during the next vblank, there's not enough GPU time left to do the actual rendering, cause the GPU is stalled most of the time waiting for the next vblank. On the other hand, if madVR tries to display the rendered frame as late as possible (in order to gain more GPU processing time), the danger of missing the target vblank period grows. A missed target vblank means judder or tearing or both. Argh, isn't that fun? AFAIK, these problems should go away in fullscreen exclusive mode, fortunately.

madVR 0.10 now uploads the video data to the GPU in a separate thread. Also rendering and displaying the images is also done in separate threads. That all means that retrieving correct and meaningful GPU rendering times is more difficult. So I've simply removed GPU rendering time information from the OSD now. However, I've added information about uploading and rendering queues. Generally, if the upload and rendering queues stay over at least 4/8, your GPU seems to be fast enough to handle the madVR settings you've activated.

Also I've added information about dropped and delayed frames to the OSD. During startup of movie playback it's acceptable to get a few dropped or delayed frames. But 3-5 seconds after the movie starts the number of dropped/delayed frames should not increase, anymore. Every time you see motion judder on screen, probably either the dropped or delayed frame count increases. If the number of dropped/delayed frames does not increase for you after 3-5 seconds of runtime, you should get perfect playback quality. Well, I mean: As perfect as the ratio of display refresh rate and movie frame rate permits, of course.

Display refresh rate calculation should work correctly now. If it doesn't, you will probably not get smooth motion playback. So make sure you double check (especially those of you for which display refresh rate calculation failed to work with older madVR versions).

I've also slightly worked on DVD playback ("macrovision failure"). For me it works. However, I've noticed that the DScaler decoder doesn't always work with madVR when playing back DVDs while the Cyberlink MPEG2 decoder always works.

Frame stepping is now implemented, but buggy. Generally madVR has gone a bit buggy/unstable due to the many deep changes. As long as you don't pause/stop/resize etc, things should be stable. If you do anything madVR has to react to you might get funny results, or maybe it will work just fine. If you run into problem that is reliably reproducable please let me know.
madshi is offline   Reply With Quote