View Single Post
Old 10th April 2009, 22:30   #89  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
Laptop with a Merom Core 2 Duo T5800 (800 Mhz FSB), 2GHz and Nvidia GeForce 9600M GT with 512MB DDR3 dedicated memory graphics.

Media files are played with ZoomPlayer. No ReClock or other similar filters. Using latest "official" notebook drivers from Nvidia's website, no "modded" ones (so no CUDA for video, either).

Good things:
- playback is good, colors seem to be appropriate, no tearing that I was aware of
- loading time is low enough, but it's true it causes a litle desync at the beginning of playback, with sound going on and video playing catch up. However, catching up happens very fast, even with 1080p files. In comparison, Haali's renderer, once it loses sync, it keeps on widening it as playback goes, and never catches it up (well, unless you pause the video and let the buffer fill in, then resuming playback and pausing it again, to allow the buffer to fill in some more, and so on untill you get to around 4 ms, after which Haali's renderer seems to be able to keep sync). madVr catches up sync very fast and keeps it, so this is a great improvement over Haali's behavior. This is most noticeably on laptops, where power management might keep the CPU running at a lower frequency when starting playback, until it figures out the load went sky high and it needs to increase the clock speed.
- subtitles work perfectly with VSFilter. The issues people are reporting are either related to filter management issues on their system, or MPC random bugs (if they're using MPC).
- CPU load is light, however the GPU load is not. I notice that when I look at the temperatures monitor: CPU temps stay low, but GPU ones rise.
- regarding playback smoothness, there are issues, but I don't know if they're ZoomPlayer related or madVR related. Let's explain:

I start a file in ZoomPlayer and playback seems smooth. I stop playback, without closing the player. I start another file, and now playback might be smooth, or it might be jerky (visible on long pans). No matter what I do, like opening another file (but still not having closed ZoomPlayer), I can't seem to get rid of the jerkiness. Now, I close ZoomPlayer. I open ZoomPlayer again and start playing the file I got jerkiness. However, this time playback is smooth...

I should say playback of one file after another in ZoomPlayer is always smooth with Haali's renderer, it doesn't randomly start to get jerky like with madVR.

Features requests:
- having the renderer remember the settings is a must. Each time playback starts, it forgets what the settings were.
- remembering the position of the settings panel on the screen, is also a good thing to have.

Questions:
- how does the filter know whjat .3dlut file to use. What if I have many .3dlut files in the folder where madvideorenderer.ax is, will it load one at random, or will it load only the out16.3dlut one ?

Issues:
- madVR accepts YUY2 input, however it can't handle it and shows a black screen. The proper behavior in this case would be to reject a connection with YUY2 input, not to accept it.
- sometimes, after changing the resizing algorithm in the settings panel, the renderer doesn't show a picture anymore, but only a black screen. This seems to happen randomly. Remember, I'm using ZoomPlayer, so it might be an issue between the two, as well.
- yes, switching from fullscreen to windowed is not very visually pleasing, but we can live with that.
- wrong AR on some anamorphic video mkv files, in conjunction with the "Derived" aspect ratio option in ZoomPlayer. Haali's renderer shows proper behavior.

This is related to the issue haruhiko mentioned: the renderer should accept a change of the aspect ratio during playback and adapt accordingly. Why ? Well, on anamorphic video files (like the one I'm mentioning), during intial graph connection and before playback starts, the advertised biWidth and biHeight in BITMAPINFOHEADER are those of the source size (like, let's say, 688x448), and only as soon as playback starts the desired display size gets entered into biWidth and biHeight (like 768, -448). madVR doesn't catch this change, and ends up displaying the image at an aspect ratio of 688/448 (=1.53571) instead of 768/448 (=1.776785).

One more note: dwPictAspectRatioX and dwPictAspectRatoY members in the VIDEOINFOHEADER2 structure are initialized to a value that almost reflects the correct display AR even before playback, but the value is in fact not very correct (it's rounded up). In the case above, they were dwPictAspectRatioX = 0x000031bf and dwPictAspectRatoY = 0x00001c00, which gives display AR = 1.776646. This might be considered a good enough approximation or not.


Great job with this renderer, by the way. Way to go, madshi !



Finally: login management on Doom9 Forum needs some improvement. Save goodness I had the inspiration to copy to clipboard all this text before pressing the submit button, or I would have lost everything when the forum suddenly decided I was no longer logged in. I learned this behavior from previous experiences, that's why I copied everything to clipboard before trying to submit. It happens if one doesn't enable the "Remember me" option at login.


Final edit: to all the people reporting issues with madVR: try using another player than MPC. You may not like to hear this, but you might be encountering bugs in MPC instead of bugs in madVR.

Last edited by KoD; 10th April 2009 at 22:55.
KoD is offline   Reply With Quote