Well, I've retested and I get ugly chroma upsampling with ATI when using NV12, too. However, Beliyaal has sent me a screenshot of his ATI card which looks a lot nicer. We're not sure yet why he gets different results than I do. Might be due to different OS, driver version or graphics card...

Try with other renderers, in Vista if you use NV12 and EVR Custom, you get bad chroma upsampling. However if you use plain EVR instead you get good chroma upsampling. Weird.

I got the same but only when the MPC-HC internal VC-1 decoder is used. It's Ok with the Microsoft VC-1 decoder (wvc1dmod.dll).

However I have a 1920*1080 VC-1 video in a MKV container (demuxed from the M2TS with TsMuxer and muxed in a MKV with MKVToolNix) that doesn't want to be displayed with the correct aspect ratio with MadVR and only with MadVR. Aspect ratio is correct with other renderers (VMR and EVR).

madVR is really interesting and if you succeed to improve its smoothiness at the level of HR or EVR CP customized by Beliyaal, it will be the best renderer on Windows.

Oh, someone really started doing the right job! HR is the best, let's see if this renderer can match it

16bit per channel per design is the way to go!!!! I just love it!

As for Beliyaal's or even not customized EVRCP, I love your sarcasm. Just in case you didn't know, both Beliyaal's and SVN versions output junk instead of video on EVRCP on my system. If not Haali or now madVR I'd be stuck with VMR9 on a system with pulls Crysis in medium settings easily....

As for DXVA with modern systems it is not a priority for mainstream PCs, only for nettops and stuff, and even that realistically is a bit too early as first nettop with integrated GeForce 9400M has just been announced.

I will choose CPU&Quality over "Fast, unreliable and limited in functionality" DXVA anytime...

Besides, due to GPU usage on HR and on madVR, much of the quality improvement is achieved on GPU anyway.

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.

I get the same thing that Xorp does except with H.264 content as well. MPC Video Decoder (YUV2) -> ffdshow video decoder (YV12) -> madVR. (Edit: Nevermind, guess it's an MPC Video Decoder issue. Blocking that filter so that only ffdshow does the decoding shows the videlo correctly.)

Also, on a laptop of mine (GM45), MPC-HC freezes and maxes out a single core while its frozen. RAM usage keeps climbing but nothing else happens.

Also, when you go to fullscreen in MPC-HC, it takes up to half a second for the video's AR to adjust to the correct AR.

However some issues already: massive CPU load (independent of the videocodec or original resolution), typically uses here in between 60% and 90% CPU, that is on 7900GTX (fastest 7xxx GForce) and E8500 stock freq (3.1GHzX2) Funny enough even when I pause the video it still uses around 50% so I sense a bug here as well

For the same content but with Haali renderer overall CPU usage is typically around 10-15% for 720p AVC content.

So, does it really support older than 8xxx series of GForce of GPUs? If so, why so much CPU%? In order to be really usable here needs to be probably around half of the current load and definitely as minimal as possible whilst paused.

perhaps it might be optimized more for ATI card, as madshi has no nvidia card (provided that optimization has to be done into that direction and cannot be generally be done for all cards/manufactors by generally optimizing direct3d stuff or something similar). so it could make sense here to have another programmer with nvidia card trying to optimze nvidia playback then?

I fixed my VSFilter issue - I had to block several filters: Arcsoft Video Decoder, Cyberlink PDVD8 h264 Decoder, CoreAVC (it has trouble with AR on some videos), etc. and chose FFDShow as the decoder for the target videos (x264). Now it can connect! Naturally, VSFilter is limited by the resolution output by ffdshow - if I leave the resolution untouched and let madVR do the scaling, the video looks quite good, but of course the subtitles are soft and/or jaggy!

Dithering is the best indeed. Color from madVR still looks different (and looks wrong) for me, though. I still don't have time to learn about 3dlut file either. But now a lot of people already giving their feedback, I'll just sit back and wait, I think.

Edit: Now I'm spoiled by madVR dithering, could anyone suggest me the setting that give me the closest to what madVR have? I'm using Beliyaal's MPC-HC build with EVR CP right now. Sometimes I use Kovensky's mplayer build with software upscaling to my desktop resolution as well.

Any Media Portal users in there?
now I'm using Media Portal under Vista with Evr and Aero with an Asus Ati HD 3850 graphic card. I use Slysoft Reclock.
My monitor is a plasma Panasonic 37PV60 it hasn't 24p support only 50 and 60 HZ. so reclock speedup play to Pal mode. No meaningful problem.
the minor problems with this configuration are:

1) with Ati card the secondary monitor in extended desktop mode do not work very well. so when start Media Portal I switch the two monitor and plasma became the primary one.

2) with reclock the evr vsynch does'nt work. I have to use the embedded reclock vsynch correction to get the perfect smooth play (24p to Pal and Pal/25 fps either).
And only with Aero on because without Aero reclock and evr do not work fine. I got stuttering for vysnch problems.

Could be important a combined developer with Slysoft to obtain the ultimate renderer for the perfect and troubleless htpc (very optimistic )

So the "video elite" want's to run madVR in such old graphics cards?
Please remember that madVR needs lot of shader processing power, and the old cards have very few shader processing units... My GF 8600GT only has 16, and it barelly keeps up with it. So, if we really want to use madVR, we should start thinking in upgrading... of course madshi could be able to optimize the code, but in the end it will always be a question of shading power. You have it or not.
It would be great if people with more recent cards would test it and post the results, so we could be able to see if it's just our cards that cannot handle it.

Quote:

Originally Posted by Hypernova

Dithering is the best indeed. Color from madVR still looks different (and looks wrong) for me, though. I still don't have time to learn about 3dlut file either.

I can help you with the 3dlut files creation, but you have to be more specific with your problems... Which source, which other renderers are you comparing? video levels or PC levels?

madshi,
are you ok with using this thread for 3dlut discussions, or will you prefer that we discuss 3dlut stuff in another thread?