madVR - high quality video renderer (GPU assisted)

[yesgrey]

Originally Posted by 6233638

Good to hear. I wonder if there's something wrong with my software setup then, as it seems to be underperforming.

I have a similar cpu, mine is a E2160, a little slower than yours. Mine is overclocked to 2.7GHz. I can play AVC pretty fine. I use CoreAVC or ffdshow-mt, and it performs well. Which decoder are you using?

[6233638]

Originally Posted by yesgrey3

I have a similar cpu, mine is a E2160, a little slower than yours. Mine is overclocked to 2.7GHz. I can play AVC pretty fine. I use CoreAVC or ffdshow-mt, and it performs well. Which decoder are you using?

I had run the CoreAVC trial (with or without CUDA) ffdshow and the ArcSoft 2.2 decoder and couldn't get smooth playback at all with Apocalypto last week (even without madVR) and I think that's AVC.

Playing in PowerDVD7 with DXVA was the only thing I could get smooth playback from.

When you're running at 2.7GHz, are you just getting smooth playback? E.g. you're running at 90,95% CPU usage? I'm starting to think that the E5200 at its stock 2.5GHz was maybe just too slow, as I've seen people saying they're getting smooth playback on 2.7, 2.8GHz Dual-Core machines.



I've just tested Apocalypto again now that I'm running at 3.7GHz though. (296×12.5) I let it run for about 5/6 minutes to get a decent graph of CPU usage. (set to fastest update speed)

http://img72.imageshack.us/img72/4629/apoc.png

This is just running the m2ts file straight off the disc in MPC-HC with CoreAVC (software) and madVR enabled with no 3DLUT and Bilinear resampling. No subtitles or anything else running. (though you would need them for this film…)

As you can see, there are peaks there which are around 85, 90% which means a 3.2, 3.3GHz machine would be required to play it back smoothly?


I hope I'm not taking things too far off topic here.

[Mark_A_W]

I have a Q6600 Quadcore overclocked from 2.4 to 3.0ghz, and I can play all AVC material, including Apoc, with about 35% CPU usage (using CoreAVC). One core will be a bit higher than the others however...balancing is the tricky part.


I have enough CPU left over I can apply sharpening filters, resample the audio to 96khz with libsamplerate, run Digital Room Correction on 6 channels.....ok, depending on the sharpening filter that starts to push it too far...but just "playing a Bluray" in software is a trivial task.

Aim high as you can (and stick the PC in the next room to the HT!!).

[yesgrey]

Originally Posted by 6233638

couldn't get smooth playback at all with Apocalypto

I will also try Apocalypto and will let you know...

[6233638]

Originally Posted by yesgrey3

I will also try Apocalypto and will let you know...

Ok, thanks. I should point out that it's the UK disc I played, but I don't think that will make any difference. (the main m2ts file is 32.2GB on the disc)

This has been running stable at 3.7GHz for a good few hours now, so I think I'm ok to leave it running at that, and it seems to have fixed things as far as CPU usage is concerned. (Apocalypto has been the most demanding disc I've found so far)

I'm not getting perfectly smooth playback yet, but that's probably a madVR issue as CPU usage isn't going over 90% even at the most stressful bits. (with it typically being in the 60-80% range)

[cyberbeing]

I can confirm that madVR doesn't work with the NVIDIA MPEG2 decoder when I tried playing some 1920x1080 and 1440x1080 transport streams (black screen, no stats or anything). DVDs on the other hand play fine with madVR and the NVIDIA decoder.

[Egh]

Originally Posted by 6233638

Thanks for the info. Everything I had read suggested that there was almost no difference between a Pentium Dual-Core and a Core2Duo of equivalent clockspeed for the majority of tasks. (Dual-Core not Pentium D, which is much slower)

I have no idea what you call Pentium Dual-Core. Can you tell the model index at least?

As for comparison v. 3.1GHz c2d (E8500) here. I've just tried mVR playing native 1080p avc content from bluray. I don't have 40mbps, however it is still quite good, 25mbps stream AVC High Profile. No DXVA/CUDA anything as my gfx doesn't support it yet.

50-60% CPU usage with mVR and 30-40% with Haali (so roughly 20% CPU consumption difference).

[Chumbo]

Originally Posted by madshi

madVR is not optimized for smooth playback yet.

No problem, thanks.

Originally Posted by madshi

Have you tried VMR or EVR fullscreen exclusive mode? That always got rid of any tearing for me. Unfortunately madVR does not support fullscreen exclusive mode yet.

Yes, VMR and EVR CP both play fine in D3D mode. The only problem I have is I can never have any UI elements, but that's another thread. I'll keep hammering on it as new versions come out.

[TinTime]

Originally Posted by cyberbeing

I can confirm that madVR doesn't work with the NVIDIA MPEG2 decoder when I tried playing some 1920x1080 and 1440x1080 transport streams (black screen, no stats or anything). DVDs on the other hand play fine with madVR and the NVIDIA decoder.

This decoder doesn't work here either. But with further testing it's not only madVR that it doesn't play nicely with. I also tried AviSynth DirectshowSource / VDub using this decoder and got nothing. Well, I got 1920x1080 grey pixels . SD material works ok with AviSynth DirectshowSource / Vdub though, as well as normal playback in Zoom Player.

Nvidia -> ffdshow -> madVR in Zoom Player results in a corrupt picture (luma and chroma don't match up or something like that) with HD material. However Nvidia -> ffdshow -> any other renderer results in no picture at all. Again there were no problems with SD.

I think the Nvidia decoder is fussy in some way when it comes to HD, but this is either a decoder oddity or a problem with my pc. Presumably the former as others have had issues with this decoder. Certainly the problems I've found with it aren't exclusive to madVR, and everything works fine with madVR when using DScaler5, ffdshow or PowerDVD filters to decode instead.

[cyberbeing]

The thing is, madVR is the only renderer that has issues with the NVIDIA decoder playing high-def content (VMR9, Overlay, EVR, & Haali are all fine). Since that is the case, you would assume madVR is at fault. On my machine NVIDIA -> ffdshow -> any other renderer (VMR9, Overlay, EVR, & Haali) and I get a perfect picture. NVIDIA -> ffdshow -> madVR gets misaligned luma and chroma, as you mentioned.

[TinTime]

With all other renderers (and software decoding) it connects using YUY2. Perhaps it's a HD YV12 connection that causes the problem? Mind you, connecting the Nvidia decoder with YUY2 instead of YV12 to ffdshow and AviSynth doesn't make any difference for me so perhaps not.

Originally Posted by cyberbeing

On my machine NVIDIA -> ffdshow -> any other renderer (VMR9, Overlay, EVR, & Haali) and I get a perfect picture.

I wonder why I don't then? Might be my ffdshow version (revision 2527). To be honest I don't ever use the Nvidia decoder except for odd occasions like now. Interestingly I remember that I stopped using it when I first came across an HD MPEG-2 stream because I ran into some problem. Unfortunately I can't remember what the problem was...

[racerxnet]

The thing is, madVR is the only renderer that has issues with the NVIDIA decoder playing high-def content

I have had the Nvidia decoder working with the Arcsoft filters in the past for DXVA acceleration on BR content, so it is possible. This is with MadVr for final output. I don't bother with HD content as I have about 600 SD DVD's which I scale to 1366 x 768. It is the panels native resolution, so I am stuck with this for now. The new 09 renderer works quit well as long as I do not push the resampling to hard. With resampling at default values I can turn off the anti tearing option. If I resample with lancoz 8 and tearing off I then get tearing on the top of the screen.

Just my .02


MAK

[nlnl]

Originally Posted by madshi

I
I'm sorry, I should have been more clear.

madVR 0.8 did not measure the time needed to upload the textures to the GPU. madVR 0.9 does measure this time and includes it in the GPU rendering statistics. Which means that if you compare madVR 0.8 statistics to madVR 0.9, you have to substract the madVR 0.9 "uploading textures" time from the average GPU rendering time. I'm aware that this is not really intuitive. The problem is that madVR 0.8 simply did not show the complete numbers. However, strange enough, madVR 0.9 shows lower GPU rendering times for me even without doing this math...

Does uploading textures mean updating textures?

So for MadVR 0.7 and 0.9:
avr gpu 0.9 - upd text 0.9 <> (?) avr gpu 0.7 ?

[fuzz!]

Originally Posted by cyberbeing

The thing is, madVR is the only renderer that has issues with the NVIDIA decoder playing high-def content (VMR9, Overlay, EVR, & Haali are all fine). Since that is the case, you would assume madVR is at fault. On my machine NVIDIA -> ffdshow -> any other renderer (VMR9, Overlay, EVR, & Haali) and I get a perfect picture. NVIDIA -> ffdshow -> madVR gets misaligned luma and chroma, as you mentioned.

whoa that brings back memories.. when i used to have an nvidia card i had that chroma offset problem pop its head up every now and again.. sorry i never figured out what the cause is.. i just got an ati..

[tetsuo55]

@Everyone discussing CPU for AVC decoding.

The samples mentioned are relatively easy to decode and do not require a C2D @ 3ghz.

For smooth playback you need a peak cpu usage of no higher than 75%, above this value dropped frames and/or jitter (might) become a problem.

Really difficult movies (of which very few exist) will only meet this limit on a 3ghz+ C2D or any Quadcore CPU worth its salt.

I must admit that some pretty cool updates have been made to both ffdshow and coreavc since i saw the last benchmarks and i can image the required CPU power having come down a bit since then.

I know of 2 really difficult samples that drop frames even on cheaper standalone players.

1. The "killa" or "killer" sample (have never been able to find it myself though)
2. A scene from i believe BBC's planet earth. This scene involves a pan over a heavily forested mountain range, a large group of birds fly by. The changes from one frame to the next are so large that almost none of the optimisations help out here and each and every frame needs to be completely decoded, the AVC also maxes out all the legal bluray specs.


But like i said, most AVC files don't even come close to this level of complexity/difficulty to decode and it's these scene's that require the 3ghz CPU.

[tetsuo55]

@Madshi:

Bugreport: Settings are not saved when madVR is run from a protected directory.

I reported earlier that the .bat install method does not get the required admin rights needed to install madVR.
I found a new problem related to installing madVR to a protected directory like "program files"

Because the filter is not run with admin rights i am unable to save the settings (because obviously "program files" is read only to any non-admin application)
madVR does not show an error that saving settings failed (i think it just assumes it will always work)

To work better in the future madVR should be limited user aware, and should ask for admin rights when saving settings.

I can also confirm the DVD decoding problem.
I will try to make a small (couple of MB) fake dvd and see if that produces the error.(which i can then upload for you to test with)

P.S.
If anyone else want's to make a small dvd sample, please go ahead, it will take a while before i will be able to do so.
any dvdmastering software could be used for this with a small free-to-distribute sample, like big buck bunny

[Mark_A_W]

Originally Posted by madshi

madVR 0.9 released


Those of you for which the final refresh rate estimate is off big time, could you please reproduce the problem, and then look into the madVR folder? There should be a file named "VSync.dat" there with detailed VSync data, which will hopefully help me find out what's going wrong on your PCs. Could you please zip and upload the file? Thanks! The file is only created if madVR detects that the final estimate is probably wrong.

File attached Madshi.

It should read ~95.904hz (it's interlaced, but that's irrelevant).

Display 2 is right.

Display 3 reads 130+hz fullscreen, and 105+hz in a window.


Not sure if you are worried yet, but v0.9 is not smooth like v0.8 was.

Thanks

Mark

[Egh]

Originally Posted by tetsuo55

@Everyone discussing CPU for AVC decoding.

The samples mentioned are relatively easy to decode and do not require a C2D @ 3ghz.

For smooth playback you need a peak cpu usage of no higher than 75%, above this value dropped frames and/or jitter (might) become a problem.

Really difficult movies (of which very few exist) will only meet this limit on a 3ghz+ C2D or any Quadcore CPU worth its salt.

Not so sure about that. Depends on multi-threading optimisation as well, most codecs have difficulties exploiting more than just two cores efficiently. Besides wolfdale even though just dual is faster in some specific tests than quad, due to the wonderful cache size

As for the 75% CPU consumption, that is the reason for my worries, as with mVR 1080p bluray video is just a bit below that threshold, 60% CPU on the OP scene. With Haali it is typically around 40% so if I watched blurays I'd choose Haali over current version of mVR due to less CPU power.

As for the different CPU-only codecs, you must be wrong.
I even rechecked it again with that 1080p video and as expected there's little to none difference in CPU amongst MPC internal, ffdshow or CoreAVC. They use different cpu% on different scenes so hard to say, but as a stab most of the times cpu load difference is within 5%.

As for the absolute values, 1080p AVC high-profile rendered and downscaled to 720p by mVR (shader math only) takes about 30-45% CPU. Which is substantially less than rendering same video without any rescale that takes about 50-60%. Very roughly, the codecs may be ranged as follows: CoreAVC, MPC internal, ffdshow in the order of CPU load but again the difference is so small that can be discarded (for instance I don't even use CoreAVC nowadays since no CUDA gain for me anyway).

[littleD]

I can confirm that cpu usage when using madvr is much reduced. I tested 720p h.264 as its the only source resolution i can play on my system. And its playable now! I get similar result with evr actually. Tested with MPC HC 1093 on ati 3450.
Softcubic is very smooth but at least cause no ringing and jaggies. Another nice scene to test is very begining of "Flushed away" with dreamworks title appearing from balloons.
Edit:
Ok i was too enthusiastic madvr still takes about 20% more cpu than evr. But is better compared to constant 100% in previous versions.

[tetsuo55]

Originally Posted by Egh

Not so sure about that. Depends on multi-threading optimisation as well, most codecs have difficulties exploiting more than just two cores efficiently. Besides wolfdale even though just dual is faster in some specific tests than quad, due to the wonderful cache size

As for the 75% CPU consumption, that is the reason for my worries, as with mVR 1080p bluray video is just a bit below that threshold, 60% CPU on the OP scene. With Haali it is typically around 40% so if I watched blurays I'd choose Haali over current version of mVR due to less CPU power.

As for the different CPU-only codecs, you must be wrong.
I even rechecked it again with that 1080p video and as expected there's little to none difference in CPU amongst MPC internal, ffdshow or CoreAVC. They use different cpu% on different scenes so hard to say, but as a stab most of the times cpu load difference is within 5%.

As for the absolute values, 1080p AVC high-profile rendered and downscaled to 720p by mVR (shader math only) takes about 30-45% CPU. Which is substantially less than rendering same video without any rescale that takes about 50-60%. Very roughly, the codecs may be ranged as follows: CoreAVC, MPC internal, ffdshow in the order of CPU load but again the difference is so small that can be discarded (for instance I don't even use CoreAVC nowadays since no CUDA gain for me anyway).

The problem is, that you can really only compare benchmarks if they are run with the killa sample and the difficult scene from bcc's planet earth(which would require the original bluray).

I have yet to actually encouter a problematic movie in real life, so far everything has worked just fine on a c2d mobile 2,6 ghz(although i have seen cases go over 75% for a second)