madVR - high quality video renderer (GPU assisted) [Archive] - Page 17

madshi

3rd May 2009, 11:38

Oh right, I thought it was just rendering in 10-bit and always ended up as 8-bit for output from a PC no matter what.
I'm not sure what EVR 10bit really does inside. I think it's supposed to actually deliver 10bits to the DAC (when using analog output) or to HDMI (when using HDMI 1.3 DeepColor). But I've no idea if it actually works that way, or if the GPU dumbs it down to 8bit internally somewhere...

Do you think that using more bits for processing (32/64-bit FP) and/or linear processing would improve things at all, or is madVR currently as good as it'll get as far as posterisation is concerned?
As long as you don't scale, there won't be any improvement, as far as posterisation is concerned, because madVR is already as good as it gets in that area. It shows exactly that amount of posterisation which is in the source. Not more and not less. The only chance for further improvements would be to either add more dither than you technically need (which would mask posterisation somewhat) or to run a preprocessing algorithm which detecs and removes posterisation from the source.

Would enabling the 10-bit output have any effect on the image at the display when madVR is used?
You mean adding 10bit output to madVR? Technically, if it actually worked (which I'm not sure about) it would decrease dithering noise level. I doubt that the difference would be visible. Maybe the image could feel ever so slightly more calm.

madshi

3rd May 2009, 11:40

Will this renderer work in x64?
The renderer should already work in x64 OSs, but currently only in 32bit media players. Support for x64 media players may come in a later version, but it's really low priority for me right now...

Hypernova

3rd May 2009, 12:03

nuhi

3rd May 2009, 13:29

Ok, here goes

http://img54.imageshack.us/img54/7114/madvr.th.png (http://img54.imageshack.us/my.php?image=madvr.png)
http://img54.imageshack.us/img54/2433/evrcp.th.png (http://img54.imageshack.us/my.php?image=evrcp.png)

The file name will say which is which. I won't say it here since it might serve as blind test for some :cool: I think it's so obvious though.

The effect is stll there. Personally I would say that it's not due to the scaling. At least not much. From the screenshot, I also notice that EVR CP give a slightly "green"-ish color. Is that one of the thing that madVR fixed? Or my eyes just deceiving me?

Edit: Just notice that it is still not the same frame. It's 4:20 in the morning so I'm going to sleep, if you still want the exact same frame I could do that tomorrow.

LOL on the pic choice, it shows it was late when you picked it ;)

Btw if you toggle evr 10bit you'll notice the color difference, 10bit off is similar/same to madvr and with 10bit enabled on the evr looks more red, less green/yellowish. But which one is more correct I do not know, it would be interesting to know but the red color gets highlighted on evr 10bit so I doubt that's correct.

racerxnet

3rd May 2009, 14:59

Yada, Yada, Yada, Yada..... When is the next update going to be ???????????

Have a wonderful weekend,

MAK

madshi

3rd May 2009, 17:00

From the screenshot, I also notice that EVR CP give a slightly "green"-ish color. Is that one of the thing that madVR fixed? Or my eyes just deceiving me?
The difference is almost too big to be explained by just calculation "exactness". That looks to me as if EVR CP just uses a different color conversion matrix. Maybe you still have some color controls active in your ATI/NVidia control panel?

Edit: Just notice that it is still not the same frame. It's 4:20 in the morning so I'm going to sleep, if you still want the exact same frame I could do that tomorrow.
Exact same frame would be nice. And I think I liked the scaled ones more cause the difference was more obvious on a quick check... :) But you should try to find out why EVR shows such different colors. That looks like wrong settings to me somehow...

madshi

3rd May 2009, 17:09

madVR 0.9 released

http://madshi.net/madVR.zip

* bigger part of initialization is done before playback is allowed to start
* if Direct3D device is lost and can't be recovered, playback is paused
* if paused playback is restarted, madVR tries to recover lost device again
* decoders are now forced to deliver video width which is devidable by 16
* reduced CPU consumption a bit
* changed video -> GPU uploading method -> lower GPU rendering times (?)
* OSD lists texture uploading times again
* OSD now only increases CPU consumption in detailed mode (2x Ctrl+J)
* external shader*.dat files are gone, compiler 41 is now always used
* when final VSync estimate if off a lot, a file "vsync.dat" is created
* fixed: 3dlut colors were ever so slightly incorrect
* fixed: shader math colors were slightly incorrect
Both CPU consumption and GPU rendering times should be down (= better). Could you guys please confirm?

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.

nijiko

3rd May 2009, 17:40

0.9 works smoothly very well.
But there is a problem.
When first time to load a very large file.
It will be black screen for a while. (several seconds)
Stop and restart playing again will fine.

nijiko

3rd May 2009, 17:48

I just think there is a preload action when starting to load.
But because of no pause, so will skip some seconds.
These seconds will have no pictures so that shows a black screen.
Is it?
Because stop and restart playing (not exit MPC) it will not reload again, it works fine now.
Is it?

madshi

3rd May 2009, 17:49

When first time to load a very large file.
It will be black screen for a while. (several seconds)
Stop and restart playing again will fine.
Hmmmm... Is that with 3dlut activated or deactivated? Try switching 3dlut on/off to see whether that makes any difference?

nijiko

3rd May 2009, 17:59

Hmmmm... Is that with 3dlut activated or deactivated? Try switching 3dlut on/off to see whether that makes any difference?

With 3dlut activated.
I suggest pause a while waiting for ready to render.Is it OK?

nijiko

3rd May 2009, 18:07

Newly report:
No this problem with 3dlut deactivated.
And without 3dlut, both CPU consumption and GPU rendering times should be down a bit more!!
Does it mean that being better to not use 3dlut???

yesgrey

3rd May 2009, 18:22

madVR 0.9 released
Both CPU consumption and GPU rendering times should be down (= better). Could you guys please confirm?
For me, GF8600GT 256MB, the rendering times increased by 3 ms. I've tryed with several resamplers and the result is always the same (more 3ms), so I presume that it should be due to the new video uploading method that is taking more 3 ms.
With the CPU consumption, I only see a significative difference with the statistics displayed; if disabled I get the same CPU consumption.
3dlut was disabled; if enabled I get more 1ms of gpu rendering time.

Thanks for the new release.:)

Peuj

3rd May 2009, 18:25

@madshi, Could you edit the first page with information like:
* "Ctrl+J" to toggle OSD
* Information about the different settings

Most of these information are already in the thread but it's easier to regroup them at the same place.

Thanks

noee

3rd May 2009, 18:34

Interesting... for my SD playback (upscaled to 1080), I'm seeing much better CPU usage (3-5% less than .08) but AVG GPU Rendering is up from ~18ms to ~21ms. Playback is on my secondary monitor @ 24Hz. 3dlut is turned off.

I don't see an appreciable perf. difference with my AVCHD material.

XPSP3, HD2600XT, CCC9.4, AMD X2 3.0Ghz, Reclock, MPC-HC, CoreAVC 1.9.5
Dual-Monitors: (Prim) Samsung 60Hz (1280x1024) - (Sec) LG 37 24/60Hz (1080P-TV Levels)
Source material: SD = 23.976@24Hz AVC in MKV, HD = 29.970@60Hz AVCHD in M2TS (1080P)

madVR: PC Levels, 3DLut=OFF, Lanczos4, SoftCubic100

madshi

3rd May 2009, 18:43

With 3dlut activated.
I suggest pause a while waiting for ready to render.Is it OK?
I'm already pausing until the 3dlut is loaded and madVR is ready to go. So I don't understand why audio playback seems to start before video playback for you.

Can anybody else confirm that problem?

And without 3dlut, both CPU consumption and GPU rendering times should be down a bit more!!
Does it mean that being better to not use 3dlut???
What do you mean with "should be down"? Do you mean they are lower? Or do you mean that you think they should be lower than they actually are? I'm not sure...

Using the 3dlut currently only has benefits if you actually use custom 3dlut settings. That may change in the future, or not. I don't know...

Could you edit the first page with information like:
* "Ctrl+J" to toggle OSD
* Information about the different settings
That would make sense.

For me, GF8600GT 256MB, the rendering times increased by 3 ms.
for my SD playback (upscaled to 1080), I'm seeing much better CPU usage (3-5% less than .08) but AVG GPU Rendering is up from ~18ms to ~21ms.
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...

Chumbo

3rd May 2009, 18:47

Well, I just finally jumped to try this thing out. :) I wanted to report a few items. Tested using HTPC built on:
Intel Core 2 Quad 9400
Sapphire HD 4830 PCIe 512MB DDR3 (CCC 9.4)
2G RAM

OS: Windows XP Pro with Sp3 and latest patches/fixes via Windows Update with March 2009 DirectX.

Player: MPC HC - SVN 1079, Decoder: MPC VC-1 no DXVA, Renderer: madVR 0.9 with default settings

- 1280x720 @ 60Hz - tearing exists and playback is very slightly jerky. Material is 1080, so this is a downscale and may not be relevant?

1920x1080 resolution
--- @30Hz - smoothest playback and no tearing, however, not completely smooth. It's still a bit jerky where VMR and EVR CP in D3D is seemlessly smooth. Some good examples to use are: The opening sequence of Babylon A.D. that zooms in from space to street level, the jerkiness is noticeable on the periphery. It's ever so slight, but noticeable. Another good example of the jerkiness of horizontal and vertical pan shots are in I Am Legend. Between approximately 2:25 to 3:17, especially the overhead of the city for vertical. After that the horizontal (left-to-right pan) of the street level in the Mustang.

--- @60Hz - Smooth like 30Hz but tearing exists

--- @24Hz - Not smooth and tearing. It's pretty much a mess, but that goes for all renderers. I don't know much about this stuff, but it doesn't seem to be a renderer issue?

Please let me know if there's anything specific you want me to test or look for like settings or whatever. Thank you and nice job madshi! :)

nijiko

3rd May 2009, 19:05

I'm already pausing until the 3dlut is loaded and madVR is ready to go. So I don't understand why audio playback seems to start before video playback for you.

Can anybody else confirm that problem?

Not audio playback before video playback.
Just lost some first seconds of video.
Only in first time to play.
With no exiting MPC, stop and restart to play again will be fine.

What do you mean with "should be down"? Do you mean they are lower? Or do you mean that you think they should be lower than they actually are? I'm not sure...

Using the 3dlut currently only has benefits if you actually use custom 3dlut settings. That may change in the future, or not. I don't know...

Yes. I mean lower. That fact is lower usage.

nijiko

3rd May 2009, 19:20

And another thing. I forgot to say.
madVR can not work with NVidia video decoder (MPEG2).
I confirm it's in YV12 mode.

yesgrey

3rd May 2009, 19:53

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.
The uploading textures time is ~4.6ms. The Increase in total time is around 2-3ms, so, subtracting, with v0.9 I get less 2ms in the total rendering time. Good work.;)

However, strange enough, madVR 0.9 shows lower GPU rendering times for me even without doing this math...
What's you memory bandwidth?

I've performed some tests with overclocking and increasing the memory clock gives very little improvement, around 1% decreasing of gpu times with a 30% memory clock increase. The core and shader clock increase gives me a real gain, less 10% times for a 10% clock increase. It seems my gpu is shader limited.

madshi

3rd May 2009, 20:24

1920x1080 resolution
--- @30Hz - smoothest playback and no tearing, however, not completely smooth.
madVR is not optimized for smooth playback yet.

--- @60Hz - Smooth like 30Hz but tearing exists

--- @24Hz - Not smooth and tearing. It's pretty much a mess, but that goes for all renderers. I don't know much about this stuff, but it doesn't seem to be a renderer issue?
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.

madVR can not work with NVidia video decoder (MPEG2).
Can anybody confirm this problem?

What's you memory bandwidth?
10.7 GPixels/s. 10.7 GTexels/s. 427 GFLOPS.

I've performed some tests with overclocking and increasing the memory clock gives very little improvement, around 1% decreasing of gpu times with a 30% memory clock increase. The core and shader clock increase gives me a real gain, less 10% times for a 10% clock increase. It seems my gpu is shader limited.
I guess it's time for you to stop using Nearest Neighbor scaling then... :p

Seriously, are these numbers with 1:1 display or with scaling active? I guess with 1:1 display memory bandwidth is not that much of a problem. But IIRC you had a 8600? That one really has low shader power. That may explain why you're shader limited...

Egh

3rd May 2009, 20:28

6233638

3rd May 2009, 20:37

0.9 seems to be running significantly smoother here on my 9400 with 1080p content.

Previously, I was seeing rendering times in the 60-70ms region. Now, I can get that down to an average of 22ms if I use bilinear and no 3D LUT. (I realise that this removes a lot of the advantages of madVR, but I get almost smooth playback with this)

Max GPU times are still around 45ms at times though. (which is more than a frame at 23.976)

If I use madVR's chroma upsampling (I find softcubic 50 to look best) average rendering times are around 38ms with max GPU times around 60,65ms.

Frame queue is generally at 16/16, though it has dropped as low as 13. With 0.8 it was hovering around 1/2. (the higher the better, right?)

I'm a bit confused about the max GPU rendering time though. It seems to jump around a lot, whereas I thought the max would simply update for higher numbers and not lower ones, giving you the true peak value for a film.

LoRd_MuldeR

3rd May 2009, 20:41

I agree that v0.9 runs significant smoother for HD content :)

Still it renders at 60 fps, although the video only has a framerate of 24 fps. My question: Isn't that a huge wast of processing power? And can it be avoided, like other renders obviously do?

(Sorry if this was answered already. This is a really huge thread, so I may have missed something)

madshi

3rd May 2009, 20:53

Not bad. SD content now (upscaled to 720p on playback) is really low in CPU consumption. 704x400avc upscaled to fit on 1280x1024 screen typically uses less than 10% CPU.

As for 720p avc content, difference is less impressive. Compared with Haali over the same file, mVR uses approx. 10%CPU extra for each scene (i.e. if scene is 12% with Haali then it is about 20-25% with mVR, if Haali uses 20% CPU then mVR uses 30%).
I think/hope that CPU consumption will go further down once I redesign the display logic for smooth playback.

As for the absolute values, roughly 1.5ms rendering no rescale and 5ms rendering with rescale (720p). Update texture time is pretty much same in both cases. Resample is roughly three times larger with rescaling as well.
Sounds pretty good to me.

0.9 seems to be running significantly smoother here on my 9400 with 1080p content.

Previously, I was seeing rendering times in the 60-70ms region. Now, I can get that down to an average of 22ms if I use bilinear and no 3D LUT. (I realise that this removes a lot of the advantages of madVR, but I get almost smooth playback with this)

Max GPU times are still around 45ms at times though. (which is more than a frame at 23.976)

If I use madVR's chroma upsampling (I find softcubic 50 to look best) average rendering times are around 38ms with max GPU times around 60,65ms.

Frame queue is generally at 16/16, though it has dropped as low as 13. With 0.8 it was hovering around 1/2. (the higher the better, right?)
The higher the better. You getting higher numbers is probably a consequence of the lowered CPU usage.

I'm a bit confused about the max GPU rendering time though. It seems to jump around a lot, whereas I thought the max would simply update for higher numbers and not lower ones, giving you the true peak value for a film.
Statistics are currently always done for 1s and then reset. The purpose of resetting the max numbers is to allow testing the effect of different settings on max numbers.

I agree that v0.9 runs significant smoother for HD content :)
Happy to hear that many of you guys notice smoother results with v0.9!

However, smooth playback is still not really implemented yet. That's still due for a future version. So you can expect further improvements. v0.9 just lowered CPU and GPU consumption a bit...

Still it renders at 60 fps, although the video only has a framerate of 24 fps. My question: Isn't that a huge wast of processing power?
It's a waste of processing power, yes. I think it's at least partially responsible for the higher CPU usage compared to other renderers. The render logic will change once I implement smooth motion playback (should be soon now).

Egh

3rd May 2009, 20:59

Still it renders at 60 fps, although the video only has a framerate of 24 fps. My question: Isn't that a huge wast of processing power? And can be avoided, like other renders obviously do?

(Sorry if this was answered already. This is a really huge thread, so I may have missed something)

Madshi typically replies in jumbo monster posts, so it is possible to miss it :) I think your question has been answered.

As well, I wonder about paused gpu timings.

Even if 720p video is paused, it still takes roughly same average time. Why update and resample textures times are any different from zero? :confused: I'd say only rendering time needs to be used in such a case. What is even more confusing, even the window is staying still here, max rendering times are still higher than average by same roughly 50%. Why would some shader passes take considerably more time than average for the same frame? (i.e. resample texture passes take roughly double the average time).
If no rescaling is used, then things are even more shocking :rolleyes: 720p no rescale when paused uses <1ms for average resampling time and about 5-6 for max resampling time :confused:

6233638

3rd May 2009, 21:01

The higher the better. You getting higher numbers is probably a consequence of the lowered CPU usage.
Hmm, that's disappointing. I had been told a 2.5GHz Pentium Dual Core (which is almost the same performance as a Core2Duo) should have been plenty for even the highest bitrate VC1/AVC blu-ray content. I guess that's not the case. (from looking at cpu load, it seems like that was the problem)

I wish I had found out about madVR before building this HTPC a few weeks ago. What sort of CPU should I need to decode 40mbps AVC/VC1 content and run madVR smoothly? (I realise that you've not fully optimised it and have smooth playback features implemented yet)

Is there a chance of madVR ever working with DXVA (I assume that's something the MPC-HC guys have to fix, rather than it being a madVR problem) or would the additional GPU load then end up being too much?

LoRd_MuldeR

3rd May 2009, 21:02

It's a waste of processing power, yes. I think it's at least partially responsible for the higher CPU usage compared to other renderers. The render logic will change once I implement smooth motion playback (should be soon now).

That sounds like good news :cool:

racerxnet

3rd May 2009, 21:07

And another thing. I forgot to say.
madVR can not work with NVidia video decoder (MPEG2).
I confirm it's in YV12 mode.

Works fine for me using the Nvidia audio and video decoders with YV12.. Hope to see the smooth playback efforts soon as stated.

MAK

yesgrey

3rd May 2009, 21:10

I guess it's time for you to stop using Nearest Neighbor scaling then... :p

Seriously, are these numbers with 1:1 display or with scaling active? I guess with 1:1 display memory bandwidth is not that much of a problem. But IIRC you had a 8600? That one really has low shader power. That may explain why you're shader limited...
I'm scaling BR for 1280x960, using Lanczos8 for Luma and SoftCubic100 for chroma. I only used Lanczos8 for testing purposes, because it's the most gpu intensive of all. I know that for downsampling using Lanczos8 is a bad idea, because with bicubic I should get the same image quality... Even bilinear would be pretty close...

madshi

3rd May 2009, 21:20

As well, I wonder about paused gpu timings.

Even if 720p video is paused, it still takes roughly same average time. Why update and resample textures times are any different from zero? :confused: I'd say only rendering time needs to be used in such a case. What is even more confusing, even the window is staying still here, max rendering times are still higher than average by same roughly 50%. Why would some shader passes take considerably more time than average for the same frame?
The stats may be wrong in paused state, I'm not sure about that.

Hmm, that's disappointing. I had been told a 2.5GHz Pentium Dual Core (which is almost the same performance as a Core2Duo) should have been plenty for even the highest bitrate VC1/AVC blu-ray content. I guess that's not the case. (from looking at cpu load, it seems like that was the problem)
Well, madVR did use (and still uses) more CPU than most other renderers. Hopefully I'll be able to get that down to "normal" levels sooner or later. Then maybe you'll be fine with VC1/AVC content. I can't tell you what kind of CPU you need for decoding. Maybe your HTPC was built to make use of DXVA? In that case obviously with madVR you're out of luck, because madVR does not support DXVA and never will.

What sort of CPU should I need to decode 40mbps AVC/VC1 content and run madVR smoothly?
I've no idea. Generally my target is to make madVR run smoothly when VMR/EVR are smooth *without DXVA*, too. Provided that the GPU is fast enough to keep up with the rendering work...

Is there a chance of madVR ever working with DXVA
No chance. CUDA works, though.

Works fine for me using the Nvidia audio and video decoders with YV12.
Thanks. It seems that nijiko has more problems with madVR than anybody else. And, I don't know why, but it seems that most of his problems seem to not be reproducible by other people.

@nijiko, at least that one weird 700x218 clip you sent me should work properly with v0.9 now. That was the one clip where I was able to reproduce a problem.

I'm scaling BR for 1280x960, using Lanczos8 for Luma and SoftCubic100 for chroma. I only used Lanczos8 for testing purposes, because it's the most gpu intensive of all.
And you are still shader limited when using Lanczos8? Well, then I think you really do need a new GPU... :eek: Lanczos8 is rather heavy on memory, while shader math for scaling is relatively low.

I know that for downsampling using Lanczos8 is a bad idea, because with bicubic I should get the same image quality... Even bilinear would be pretty close...
While downscaling differences may be smaller compared to upscaling differences, I still think that Lanczos downscaling is not a bad idea at all. I once tried upscaling+downscaling an image. And using Lanczos+Lanczos produced the best results. Noticeably better than Lanczos+Bicubic. With Lanczos+Lanczos the scaled image was very near to the original. Using Lanczos+Bicubic the scaled image was noticeably softer compared to the original.

Hypernova

3rd May 2009, 21:38

Here are the same frame (from 0.8, will install 0.9 right after). Could you or anyone point out to me where I could make mistake for EVR CP (or put me to a place that does)? In Catalyst Avivo all setting is either "use application settings" or not enable. I didn't do anything on Color page as well. I can try include mplayer's OpenGL renderer, is that gonna help? (setting: vo=gl:yuv=0:rectangle=2:lscale=5:cscale=5)

http://img300.imageshack.us/img300/2433/evrcp.th.png (http://img300.imageshack.us/img300/2433/evrcp.png)
http://img300.imageshack.us/img300/7114/madvr.th.png (http://img300.imageshack.us/img300/7114/madvr.png)
http://img300.imageshack.us/img300/9576/shot0001p.th.png (http://img300.imageshack.us/img300/9576/shot0001p.png)
http://img522.imageshack.us/img522/9471/haali.th.png (http://img522.imageshack.us/img522/9471/haali.png)

Add Haali renderer shots. Now it's hard to see the difference, but it's still there. Again, I would be happy if anyone can help me improve EVR CP result. I have to live with that until madVR got subtitle, which is still some time in the future. :)

6233638

3rd May 2009, 21:41

Well, madVR did use (and still uses) more CPU than most other renderers. Hopefully I'll be able to get that down to "normal" levels sooner or later. Then maybe you'll be fine with VC1/AVC content. I can't tell you what kind of CPU you need for decoding. Maybe your HTPC was built to make use of DXVA? In that case obviously with madVR you're out of luck, because madVR does not support DXVA and never will.
Unfortunately, I think the 2.5GHz recommendation was based on the fact that I was getting a motherboard that has a 9400 and therefore would do all the processing on-board.

I've never been one for overclocking really (I'd rather run at the rated speeds without risk) but rather than go out and replace most of the components in this computer two weeks after buying it, I'm now running at 3GHz with a 10% overclock on the GPU and it's eliminated almost all spikes to 100% on the CPU graph when playing back video. (though I need to test and see what the highest bitrate/most demanding film I have is)

I've just noticed now though that, even though the GPU times are ok, CPU is at 100% usage if I enable the 3D LUT.

Perhaps once CPU usage is lowered by rendering at 24/30fps rather than 60, it'll be able to cope properly.

I'll have to see just how much I can push this system and have it still run reliably.

Hypernova

3rd May 2009, 21:45

Quick report on 0.9: The reduce in GPU render time is about 5ms I think. (Bilinear/Bilinear, upscaling from 848x480 to 2560x1600) (I didn't take note on CPU's before, sorry). I also attach VSync.dat here

tetsuo55

3rd May 2009, 22:13

What sort of CPU should I need to decode 40mbps AVC/VC1 content and run madVR smoothly

The 40mbps AVC requires a 3ghz C2D for the toughest scenes.
Add madVR to the mix and we would currently need a 3.3ghz C2D

Your pentium dualcore doesn't even come close, you would need to OC it to between 3,8 and 4,2 ghz to get a similar performance.

Most AVC's don't have tough scene's and will work fine on a slower cpu, i'm personally not going to take any changes and have ordered a e8400 (3ghz)

nijiko

3rd May 2009, 22:24

No output with NVidia.
See snap in pic named no_op.jpg.
This Video clip is HD!

But works fine in SD.
See snap in pic named tmp_op.jpg.

honai

3rd May 2009, 22:34

6233638

3rd May 2009, 22:58

The 40mbps AVC requires a 3ghz C2D for the toughest scenes.
Add madVR to the mix and we would currently need a 3.3ghz C2D

Your pentium dualcore doesn't even come close, you would need to OC it to between 3,8 and 4,2 ghz to get a similar performance.

Most AVC's don't have tough scene's and will work fine on a slower cpu, i'm personally not going to take any changes and have ordered a e8400 (3ghz)
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)

Due to the 12.5x multiplier on this, it means I'm not having to push the fsb so hard to get fairly substantial overclocks.

I don't want to speak too soon, but it seems to be running stable at 3.7GHz, and not even that hot. (15℃ below operating limits under load with the stock HSF—which I'll upgrade if I decided to keep running it like this, or faster if it'll do it)

Not true. I had an Pentium Dual-Core (E5200) in my rig and swapped it for an E8400 - but only to get additional headroom in post-processing (LSF etc). The E5200 played all content just fine, even Pirates of the Caribbean AVC at 40mbps, and never hit 100%.

I'm not saying that more CPU power is unnecessary, though. ;)
Good to hear. I wonder if there's something wrong with my software setup then, as it seems to be underperforming.

yesgrey

3rd May 2009, 23:18

And you are still shader limited when using Lanczos8? Well, then I think you really do need a new GPU... :eek:
Well, my rendering times without L8 are <20ms, so I think I will keep it a little more, until madVR is a little more mature and then I will see if I need to change it or not...;) The 4770 is very tempting, but my last experience with an ATI card (radeon 9500) was not very good... analog vga output with low quality and the drivers were not also very good handling two displays, so I'm a bit affraid of spending money in an ATI again...

I once tried upscaling+downscaling an image...
But that's different than just downscaling. I've performed some tests with Avisynth, because I'm backing up a BR movie to a lower resolution, and I have tryed the opposite: downscaling+upscaling. In the Avisynth user's guide they say that for downscaling bilinear should give the same results (or better) than bicubic, but it's not true; the image is softer. Between Bicubic, Spline64 and Lanczos, there was no visible difference.
This is only true for downsampling; upsampling is a different story, then, Lanczos shows all its quality...

yesgrey

3rd May 2009, 23:21

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

3rd May 2009, 23:45

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

4th May 2009, 00:06

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

4th May 2009, 00:30

couldn't get smooth playback at all with Apocalypto
I will also try Apocalypto and will let you know...

6233638

4th May 2009, 00:44

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

4th May 2009, 00:45

Egh

4th May 2009, 01:18

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

4th May 2009, 02:07

madVR is not optimized for smooth playback yet.

No problem, thanks.

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

4th May 2009, 02:24

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.