madVR - high quality video renderer (GPU assisted)

[Egh]

Quote:
Originally Posted by ice25 View Post
CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.
Too bad, I had hoped that was fixed. Can't properly test it cause I don't have a secondary display at the moment. So I guess the fix will have to wait a while...


@Madshi: bit late but better than never ;)

fix reports
a) overall CPU consumption is reduced on primary and I think for SD content at least the difference between HR and madVR is negligible.
b). madVR properly reports that 10bit buffers are not available and engages 8bit buffers, and weirdly enough, no crashes or silent quits after than, video plays as normal :)

bug confirmation reports

1.
although the CPU consumption is down in total, still secondary monitor maxes one of the cores.
Interesting enough, now with OSD I can tell that avrg present wait is actually about 3 times lower on the secondary monitor ;)
Still one of the cores is on maximum.
As for the rest of parameters, I cannot see any substantial difference in times for any of the other parameters on two monitors. I even used ctrl+j twice, but all the numbers are nearly same whilst CPU usage is dramatically different.

2. Monitor refresh rate is not updated if you move to a different monitor. I think btw Beliyaal fixed that issue with EVRCP at some point, but that code is not in SVN yet (may be mistaken)
important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate). Note that your code is the best so far when moving the window to a different monitor, as other renderers may have a small pause or blank screen displayed for a while when you move a window. Moving window with madVR is same as moving any normal application.

[noee]

important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate).

fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.

[DeepBeepMeep]

Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.

Many thanks

[yesgrey]

I've tryed to overclock my card to see the benefits.
Clock description: Core / Shader / Memory

Standard clocks
540 / 1188 / 700
9759

Overclock Core and Shader
595 / 1404 / 700
9761

Overclock All
595 / 1404 / 918
9760

Overclocking only the Core and Shader clocks gives a ~4% performance increase, if I also overclock the memory it gives a ~9% performance increase.
So, with madVR, the performance increase with my card was directly proportional to the clocks increase.:)

[Egh]

fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.

Nope here. Although it seems you have TV screen? I just run dualview with two monitors. It seems it always picks the refresh rate of the monitor it starts on. And i don't mean madVR per se, what I mean is the main MPCHC window. I.E. even if I start an empty window on one monitor, then move to another and drop a video into it, it detects the refresh rate of the original monitor.

[Egh]

Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.

Many thanks

I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard ;):p

[DeepBeepMeep]

I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard ;):p

The trouble is that under Zoom Player, CTRL-J creates some navigation window...

Anyway, I don't mind keeping CTRLJ as long as there is another way to display the stats.

[vucloutr]

Hi, here some feedback.

System:
WinServer2008 x64 - MPC HC special build - latest Nvidia drivers - latest DirectX drivers
8800GTS512 (G92) - 19" LCD 1280x1024 @72Hz over DVI

720p,h264,23.976fps,3Mbit/s encodes displayed at fullscreen (no stretch)

CoreAVC w/o CUDA / MPC HC's internal decoder / DivX H.264 Decoder :
display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
avrg present wait ~11ms
those times are pretty stable and don't vary much from decoder to decoder.

CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.

- framerate sometimes doesn't oszillate at all
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
- avrg present wait shows large negativ values immediately after pressing CTRL+J then it normalizes

I'm afraid I can't tell something more distinct because it all seems so random. :confused:

[rica]

Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.

Avi/wav File Source > MadVR

What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption???? :confused:

[Adub]

I could kiss you!

Madshi you rock with all of the contributions you produce in this community! Thank you so much!

[Mutiny32]

Great renderer, it will be even better when you can make it output 0-255 and output smoother video. But those are pretty trivial, as other things can handle that sort of thing. You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI. My TV has all kinds of controls to handle and enhance colors and black levels to the room lighting (Philips 42pfl7422d/37), so it doesn't matter much.

I do have one request though, can you compile this for 64-bit windows? I'm going to be installing a newer build soon and Microsoft is really pushing the 64-bit thing, especially after Apple started with the whole Snow Leopard 64-bit schtick. It's seeming more and more that 64-bit will be the norm and I'm not sure of its capabilities in handling 32-bit programs; it's not like I can just do an 'apt-get install ia32-libs' or anything, that would make too much sense.

Keep up the great work!

[Egh]

Well x64 version will be required in the future, as only x64 codecs may work with x64 mpchc and x64 decoders. Though here I haven't found any particular video yet which would consume substantially different amount of CPU% on x64 compared to x86. Maybe when lots of additional post-processing is involved, decoding itself doesn't load CPU differently.

Though recalling how much time required to persuade Haali to do x64 version ;))) He resisted for more than a year before finally surrendering :P

[Snowknight26]

Assuming hes writing this in Delphi, it will be a while before even the possibility ofa 64-bit version of this or any other of madshi's programs.

[FoLLgoTT]

Excellent renderer! For such fine piece of software I was waiting for! :)

I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.

I will be really happy when DVD works with madVR. :)

[FoLLgoTT]

@madshi
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.


ffdshow:
http://img2.imageshack.us/img2/4061/bild3d.th.png (http://img2.imageshack.us/my.php?image=bild3d.png)

madVR with resampling:
http://img2.imageshack.us/img2/6592/bild1dpu.th.png (http://img2.imageshack.us/my.php?image=bild1dpu.png)

madVR without resampling:
http://img2.imageshack.us/img2/1946/bild4d.th.png (http://img2.imageshack.us/my.php?image=bild4d.png)


The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.

ffdshow:
http://img2.imageshack.us/img2/3711/bild5z.th.png (http://img2.imageshack.us/my.php?image=bild5z.png)

madVR with resampling:
http://img2.imageshack.us/img2/357/bild6.th.png (http://img2.imageshack.us/my.php?image=bild6.png)

Is this a bug or just a side effect of your upsampling algorithm?

[leeperry]

I wonder if anyone tried to create LUT's w/ custom primaries coordinates, coz I'm getting strange results...even the stock LUT's are way too dark, but yesgrey is on the case :)

[VHT]

Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.

[madshi]

that'd be fun if you could put 3 or 4 digits after the coma for the VSYNC interval.
Not needed. The VSync interval is just calculated by doing "1000 / display refresh rate" and the display refresh rate is displayed with enough digits. So you can calculate the VSync interval yourself. But please note that the display refresh rate is not 100% perfect. So take those additional digits with a grain of salt!

Could that be the cause of the high CPU load? The copy operation from RAM into VRAM is done by the CPU and is a rather slow operation AFAIR.
Well, the data has to be transported to the GPU somehow. All the other renderers must do that, too, sooner or later. Actually if you feed other renderers with RGB data or even with upscaled data, you have to send more data from RAM to GPU than madVR does! So I still don't see why madVR should consume more CPU.

Can anything be done about an error that says "graphics card only supports power of 2 textures?" Happens with my GM45.
Unfortunately there's not so much I can about that. The error message means that your GM45 only supports textures which follow strict resolution patterns. Basically textures on your graphics card must have a width and height of one of the following numbers: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096. Now madVR needs textures in the resolution of the source (e.g. 720x480 for NTSC-DVD) and in the resolution of the display (e.g. 1920x1080). Your GM45 seemingly does not support textures in such "odd" resolutions. Probably it would be possible to use the next higher supported resolution like e.g. 2048x2048, but that would make texture addressing in my shaders a lot more complicated. So I'd rather not support that. I fear the GM45 would be too slow, anyway... :(

display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
These are extremely good numbers. Of course it helps that you have 1:1 display and don't need to scale.

CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.
Interesting!

- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
If the time counter goes up a lot that helps exactness of the display refresh rate calculation. The time counter restarts from 0s, if madVR ran into any kind of trouble interpreting the VSync data.

- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
That problem should be solved in a future version of madVR. Might take a while, though...

- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
Do you really have to minimize/restore? The display refresh rate detection should be able to recover automatically. It retries measurements every second.

Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.

Avi/wav File Source > MadVR

What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption???? :confused:
Weird!!

You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI.
Yeah, but how do you know what the driver does internally? E.g. with ATI cards even if you do select YCbCr output, BTB and WTW are clipped, which is a strong indicator that the graphics card internally does YCbCr (video) -> RGB (PC) -> YCbCr (video), which I consider bad.

I do have one request though, can you compile this for 64-bit windows?
I've already replied to this question a few posts before.

I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.
Ok, will add 8 tap Lanczos. But in my tests it didn't look any better than 4 tap Lanczos. Actually it looked worse to me, because it was not any sharper and only ever so slightly less aliased, but had very noticeable double ringing!

...even the stock LUT's are way too dark, but yesgrey is on the case :)
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?

Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.

[madshi]

I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?

If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.
Which madVR resampling option do you mean?

The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.

Is this a bug or just a side effect of your upsampling algorithm?
I've optimized my chroma upsampling algorithm in such a way that it gets rid of all the nasty aliasing. That may result in a hit on frequency response. Of course that's not nice. But we have to set our priorities right: Do you want higher frequency response and live with ugly jaggies? Or do you want smooth jaggies and can live with a lower frequency response?

Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots? I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible... ;)

But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful?

Can you see the "missing" frequency response in any real life pictures?

[leeperry]

You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?
well..I output PC range off ffdshow and my displays all have PC range(so no levels conversion needed)

that's my RGB32HQ picture :
http://www.image-load.eu/out.php/i157521_rgb32hq.png

now w/ ddcc doing the gamut conversion(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157519_ddcc.png

and that's w/ a 16bit LUT from yesgrey's app in t3dlut() :
http://www.image-load.eu/out.php/i157520_lut.png

so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees.

and I'm getting opposite results when I put this LUT in madVR :confused:

that's w/ ddcc(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157518_hr.png

this is the stock HD LUT in madVR :
http://www.imagebam.com/image/43c8ae32526309

and this is my custom 16bit LUT :
http://www.imagebam.com/image/c716bb32526310

I know ddcc "works" coz it matches what the PS script outputs(slightly better of course)...

I think you may wanna give the option to the user to choose untouched levels or TV>PC conversion, and then make 2 LUT's :
SD: REC.601 (untouched levels OR levels expansion from TV to PC)
HD: REC.709 (untouched levels OR levels expansion from TV to PC)

but anyway, the CMS is pretty broken right now I think, waiting for yesgrey's feedback :cool:

[VHT]

There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.

Madshi.I did find the switch but didn't solve my problem.Ffdshow connects nicely with MadVR if I use ffdshow to decode my H264 movies but when I try to use CoreAVC for decoding, ffdshow doesn't want to connect anymore...(Ffdshow settings are inputting and outputting YV12, so that shouldn't be the problem).Also my Coreavc settings should be correct.

[Mike5]

@VHT

Have you set ffdshow video / Codecs / Raw video = all supported ?

If the CoreAVC output color space doesn't match ffdshow allowed input color spaces, ffdshow doesn't enter the graph (as post-processor)

[VHT]

@VHT

Have you set ffdshow video / Codecs / Raw video = all supported ?

If the CoreAVC output color space doesn't match ffdshow allowed input color spaces, ffdshow doesn't enter the graph (as post-processor)

Yes I have.

[madshi]

well..I output PC range off ffdshow and my displays all have PC range(so no levels conversion needed)

so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees.

and I'm getting opposite results when I put this LUT in madVR :confused:
So is madVR not handling the 3dlut file correctly? yesgrey3, can you confirm that?

Madshi.I did find the switch but didn't solve my problem.Ffdshow connects nicely with MadVR if I use ffdshow to decode my H264 movies but when I try to use CoreAVC for decoding, ffdshow doesn't want to connect anymore...
Can't tell you why. Please try with madVR 0.4. If that still fails, I'd need a sample or something, so that I can reproduce the problem on my PC.

[madshi]

madVR 0.4 released

http://madshi.net/madVR.zip

* modified (improved?) initialization order
* fixed: aspect ratio was incorrect with some sources
* added Lanczos8 resampling option (but I don't recommend to use it)
* changed the way the GPU textures are updated
Maybe eventually (but probably not) the multi monitor problem is already improved in this build due to the modified initialization order, but I doubt it.

Unless new show stopper bugs show up, this will probably be the last release for this weekend.

[buletti]

These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?


I'm afraid they are not. The patterns are from the Peter Finzel Test Disc (http://www.cine4home.de/software/DVD/PeterFinzelTestDisc/PFTestDisc.htm).
There are also similar, commercial calibration test disc from Bürosch, AVIA and Digital Video Essentials. Dunno about free alternatives, tho...

[FoLLgoTT]

These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?

They are from the Peter Finzel Disc, a german test pattern DVD. I find these patterns useful to exermine luma and chroma response and aliasing (beats) in just a few seconds. The raw pictures can be legally downloaded here (http://www.peterfinzel.de/tbilder.zip). :)

Which madVR resampling option do you mean?

I meant the option "don't resample chroma".

Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots?

It looks better indeed in that example. :)

I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible... ;)

Oh yes! And joe sixpack will be happy about the *sharp* picture! :D

But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful?

This is an excellent idea! I hope it is not too much work to implement this option.

Can you see the "missing" frequency response in any real life pictures?

Good point. ;)
In terms of chroma upsampling I have no real world example. Maybe some Pixar movies would have sensitive scenes, but I think I would really have problems noticing the differences.

But in terms of luma scaling I have a few movies which show a visible difference between Lanczos3 and Lanczos10. These movies have very high frequency response and suffer from quite a bit aliasing. With more taps there is very slightly more detail and much less aliasing. The german DVD of "My Fair Lady" is a good example. Maybe some Superbits with aliasing on the disc (e.g. "The 5th Element") could also benefit from more taps. And btw., additional ringing by the scaling algorithm is no problem even with such high frequency material. :)

[noee]

.4 build

* madVR is now pickup up my LG37 (HDTV) refresh of 24Hz properly.
* Reclock tearing test shows *no* tearing now with 23.976@24Hz playback on *secondary* (LG37)

Movie_frame_interval = 41.71
Avg GPU rendering = 19.67

Excellent work!

[ice25]

Yup at first glance secondary display detection is working nicely. Well done.

Any chance you could add a A/V jitter statistic to the OSD?

[madshi]

The raw pictures can be legally downloaded
Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?

This is an excellent idea!
Which scaling algorithms would you like to have? The same used for luma scaling? Or a subset?

But in terms of luma scaling I have a few movies which show a visible difference between Lanczos3 and Lanczos10. These movies have very high frequency response and suffer from quite a bit aliasing. With more taps there is very slightly more detail and much less aliasing. The german DVD of "My Fair Lady" is a good example. Maybe some Superbits with aliasing on the disc (e.g. "The 5th Element") could also benefit from more taps.
Well, madVR 0.4 now does Lanczos8. Personally, I think the difference between Lanczos3 and Lanczos4 is bigger than the difference between Lanczos8 and Lanczos4. So I think Lanczos8 should be virtually identical to Lanczos10.

And btw., additional ringing by the scaling algorithm is no problem even with such high frequency material. :)
I don't agree.

.4 build

* madVR is now pickup up my LG37 (HDTV) refresh of 24Hz properly.
* Reclock tearing test shows *no* tearing now with 23.976@24Hz playback on *secondary* (LG37)
Yup at first glance secondary display detection is working nicely. Well done.
Great news! I was hoping for that, but didn't really expect it.

So is CPU consumption on secondary display ok now, too? No more 100%?

Any chance you could add a A/V jitter statistic to the OSD?
That would fall under the "smooth playback" category which is not implemented yet. So I can't give you any comment on that...

[FoLLgoTT]

Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?

I guess you have to ask Peter Finzel. I don't know under which license the pictures are published.

Which scaling algorithms would you like to have? The same used for luma scaling? Or a subset?

For my part Lanczos would be enough as an extra option. But the algorithms are already there so maybe it could be useful to choose between all available.

Well, madVR 0.4 now does Lanczos8. Personally, I think the difference between Lanczos3 and Lanczos4 is bigger than the difference between Lanczos8 and Lanczos4. So I think Lanczos8 should be virtually identical to Lanczos10.

I agree. The difference between Lanczos8 and 10 is very little.

I don't agree.

I'm really interested, because I never saw it outside of test patterns yet. All I noticed was an amplification of the inherent EE of the disc, because of the algorithm's better frequency response.

Do you have DVD examples on which additional ringing is visible in a movie? I mean scenes inside the movie and not the fonts at the ending? If this discussion is too off topic I would be thankful for a short PM. :)

[noee]

So is CPU consumption on secondary display ok now, too? No more 100%?

FWIW, I never saw the CPU utilization issues others mentioned re: secondary monitor. My CPU util is around 12% and GPU is around 45% running X2 O/C at 3.0Ghz, this is with SD material upscaled to 1080P, Lanczos 4-tap.

For HD material (1080P-M2TS AVCHD), CPU util is around 55%, using MPC-HC internal decoders.

[leeperry]

examples on which additional ringing is visible in a movie? I mean scenes inside the movie and not the fonts at the ending?
the start credits of Shoot'em Up on BD are very good to spot dodgy chroma processing(the big SHOOT/EM/UP logos written in blood)...but apart from these extreme examples, any red object should do(there's a woman w/ a strongly saturated red coat in "Night at the Museum")

[FoLLgoTT]

the start credits of Shoot'em Up on BD are very good to spot dodgy chroma processing(the big SHOOT/EM/UP logos written in blood)...but apart from these extreme examples, any red object should do(one woman in THE NIGHT MUSEUM has a strongly saturated red coat that might help too)

Thanks for the hint. But my quote was in the context of (luma) scaling and not chroma processing. :)

[leeperry]

Thanks for the hint. But my quote was in the context of (luma) scaling and not chroma processing. :)
OK, I thought I was missing the point...and I was :rolleyes:

I'm very concerned about chroma(being colorblind and all), I let you guys take care of luma then :D

[TinTime]

Very cool! Which license do these pictures come with? Would it be legal to include them in madVR somehow?

Looks like they're copyright Peter Finzel Productions (http://www.peterfinzel.de/impres.htm) so you'd have to get his permission to distribute them.

[midiboy]

Hi madshi,

thanks for the new renderer. Just playing around with it. Currently I do get lots of heavy stutter in ZoomPlayer when using the renderer though. (on secondary display with reclock) I am on a ATI radeon 4550 with 512MB of memory. I guess that card is not powerful enough, right ? I also tried disabling all quality settings but that did not change much.

CPU utilisation is below 40% on a DualCore CPU and the Haali renderer works fine so I guess the videocard is the problem, right ? Are there any baselines what GPU is the minimum for stutterfree 1080p playback ?

Bye,
Alex

[mark0077]

Hi all,

Just a thought. Would madshi and beliyaal consider teaming up to integrate beliyaal's work on reducing judder, syncing frames etc, with the excellent levels conversion and more, work by madshi.

I am torn between which renderer I want to use but would love to see madVR with the frame sync stuff from beliyaal if possible to combine both.

It would be a terrible waste of time for madshi to spend lots of time on audio / video sync if its possible to use the existing work by beliyaal.

Cheers,

[flanger216]

As of 0.4, everything works great on my end. No CPU usage penalty, and I get smooth playback with Bicubuic -0.75 (anything higher introduces stutter in 1080p material). And all of this on a lowly Radeon HD3650. Great job.

[Keiyakusha]

madshi
Can you add support for loading subtitles anytime soon or this is too much of work for now? I really want watch some movies with MPC-HC/madVR but i prefer to watch with subtitles coz English is not my native language. "Use VobSub" is not the solution.

[TinTime]

madshi, aspect ratios are still not (quite) handled correctly. I've got a 704x576 encode with a 16/9 ar that madVR scales to 1918x1080, not 1920x1080. VMR9 and Haali both scale correctly.

Here's a sample (http://www.sendspace.com/file/7d51sd).

Thanks very much.

[pitch.fr]

Sorry My English isn't very well
Hello, very good job on the new renderer, but I find the latest version 0.4 less "smooth"

[leeperry]

yep, I agree I found beta2 smoother...it takes more reseeks w/ Reclock to catch the VSYNC in beta3 & 4, but the smooth code is not there yet ;)

[KoD]

True, I've just noticed jerky pans when playing a 480p xvid file. Frame decoding time is not an issue here, there must be something else that's causing these jerky pans.

[madshi]

I'm really interested, because I never saw it outside of test patterns yet.
Then you haven't looked properly... ;)

Since you mentioned the Germany My Fair Lady DVD, here's that DVD, enlarged to my PC display's native resolution of 1680x1050:

http://madshi.net/madVR/Audrey.png

Left side is "SoftCubic50", right size "Lanczos8". The ringing you can see in the right side is not in the source at all. It's added by the Lanczos resampling algorithm. As you can see, I didn't have to search very long to find ringing. After all this is still the movie intro... ;) Here are the full screenshots:

SoftCubic50 (http://madshi.net/madVR/AudreySoftCubic50.png)
Lanczos8 (http://madshi.net/madVR/AudreyLanczos8.png)

Looks like they're copyright Peter Finzel Productions (http://www.peterfinzel.de/impres.htm) so you'd have to get his permission to distribute them.
Thanks.

Currently I do get lots of heavy stutter in ZoomPlayer when using the renderer though. (on secondary display with reclock) I am on a ATI radeon 4550 with 512MB of memory. I guess that card is not powerful enough, right ? I also tried disabling all quality settings but that did not change much.
Press Ctrl+J, then post your stats here. That may help us figuring out whether your GPU is fast enough or not.

Would madshi and beliyaal consider teaming up to integrate beliyaal's work on reducing judder, syncing frames etc, with the excellent levels conversion and more, work by madshi.
Beliyaal has done great work to improve smoothness with the MPC HC renderers. But I haven't even started looking into this kind of stuff yet. I also don't know if his tweaks would work with my renderer. Maybe yes, maybe no. My renderer eats a lot more GPU shader resources than the MPC HC renderers do. Maybe if I run into trouble with implementing smooth playback, I will ask Beliyaal to come on board. But I'm not sure if he wanted that, after all madVR is closed source and I want to keep it that way. But this is too early, anyway. As I said a lot of times already, I DON'T really want to talk about smooth motion playback yet.

Can you add support for loading subtitles anytime soon or this is too much of work for now?
It's one of the many things still missing. I haven't decided on in which order I will tackle them. Everybody has his own priorities...

I've got a 704x576 encode with a 16/9 ar that madVR scales to 1918x1080, not 1920x1080.
Thanks, that's a simple rounding issue. Will be fixed in the next build.

Sorry My English isn't very well
Hello, very good job on the new renderer, but I find the latest version 0.4 less "smooth"
Again (and again and again) motion smoothness is not a thing I have really looked into yet. Did your GPU stats (see Ctrl+J), especially "average gpu rendering time" get worse with 0.4 compared to 0.3? That's a thing I would have to look into.

[tetsuo55]

Hi

I just tested v4 (did not try the older builds)
The bat file failed to install on my system (windows 7 32bit)

The 1:1 results for media my system can handle are okay, but as soon as any scaling is applied the video becomes a slideshow.

My specs:
AthlonXP 2600+ @ 2ghz
A7N8X Deluxe
ATI HD2400pro AGP
Windows 7
Catalyst 9.3

CPU% maxes out as soon a scaling is enabled
1:1 usage is between 30-80%
EVR-CP cpu usage is 10%

Screenshot of 1:1 stats:
http://img213.imageshack.us/img213/6663/1on1.th.png (http://img213.imageshack.us/my.php?image=1on1.png)
Screenshot of scaled to 1920x1080:
http://img208.imageshack.us/img208/892/scaledto1920x180.th.png (http://img208.imageshack.us/my.php?image=scaledto1920x180.png)

due to no DXVA support i was unable to test anything above SD resolution (With overlay renderer my cpu is just fast enough for 1280x720)

[madshi]

The bat file failed to install on my system (windows 7 32bit)
Did you get any specific error message?

The 1:1 results for media my system can handle are okay, but as soon as any scaling is applied the video becomes a slideshow.

My specs:
AthlonXP 2600+ @ 2ghz
A7N8X Deluxe
ATI HD2400pro AGP
Windows 7
Catalyst 9.3

CPU% maxes out as soon a scaling is enabled
1:1 usage is between 30-80%
EVR-CP cpu usage is 10%
Not sure why you get so much higher CPU usage when scaling is enabled. For me CPU consumption does not change much if I enable/disable scaling. Could you please try 1:1 and then just zoom in one step (MPC HC numpad [9], IIRC)? Do you get the same high CPU consumption that way?

Screenshot of 1:1 stats:
Screenshot of scaled to 1920x1080:
Wow, what a difference in gpu rendering times! Ok, the source seems to have a very small resolution. Of course that helps keeping rendering times down in 1:1 mode. "average gpu rendering time" is the most important and it's quite nice with 5ms in 1:1 mode. It needs to be smaller than the "movie frame interval" (40ms). However, in scaled mode your "average gpu rendering time" is going through the roof with almost 60ms! That's too much. It seems that your graphics card is not fast enough to do scaling to 1080p with full madVR quality options. You can turn down the quality a bit in the madVR settings dialog. Maybe that helps? Try lowering luma+chroma textures to 10bit. With a bit of luck that might already be enough to push "average gpu rendering time" down under 40ms.

[mark0077]

Using version 4, with ffdshow in the chain doing de-interlacing (if necessary) I get DVD Macrovision failed error playing backed up dvd's from hdd.

This was the reason I could never use Haali also, could never get rid of this error.

[Brazil2]

madVR 0.4 released


* fixed: aspect ratio was incorrect with some sources
I'm still having aspect ratio troubles with the two samples I've posted here (http://forum.doom9.org/showthread.php?p=1273052#post1273052).

The first sample (VC-1 in MKV) gives me the correct aspect ratio with the MPC-HC built-in decoder. I always got a wrong aspect ratio when the Microsoft decoder is used and it doesn't matter which splitter is used. The Arcsoft decoder doesn't want to connect even with the VC1tweak filter so I'm stuck to the MPC-HC decoder or the Microsoft one, but as you know the MPC-HC decoder is not working fine with your renderer for now.


Now I got different results with the Beyonce TS sample depending on which combination of splitter + decoder is used. So I've done more tests:

Splitter + Decoder = aspect ratio result

MPC-HC + MPC-HC = wrong
MPC-HC + Arcsoft = wrong
MPC-HC + CoreAVC = OK
MPC-HC + Divx7 = wrong

Arcsoft + MPC-HC = OK but lot of stuttering (+ the bug of the decoder)
Arcsoft + Arcsoft = OK
Arcsoft + CoreAVC = wrong
Arcsoft + Divx7 = doesn't connect

I don't have Haali installed and I don't plan to install it. My config is actually working fine for every use I have except some troubles with MadVR.
But I know it's a work in progress, I don't blame I only report. Good and impressive job anyway, thanks for that :)

[Egh]

@madshi: 0.4v High CPU to some extend and also still gets only the refresh rate from the original monitor.

update on the refresh rate issue:

I found a way to reset it. Funny enough if you drop a new video to mpchc window then madVR will show proper Hz after reinitialisation. However, that doesn't happen if you just stop/restart the video. Needless to say that even if I reset the video, and then move to another monitor, it doesn't pick up the rate again.

Since 0.3v the behaviour has slightly changed now.
it seems the issue with secondary monitor is almost nailed!!!

It seems now there's no difference between primary and secondary monitor in terms of CPU consumption, only thing matters is what monitor the video has been initialized in!!! The following scenario is now valid: open an empty window on primary, move to secondary, drop a video into it -- no core maximisation ;P move the window back to primary -- maximisation is present again :) If I revert the order of monitors in this scenario and do it again, same thing happens.

To sum up, it is possible to use a workaround now, which is to force madVR to reinitialize on a different monitor. That apparently fixes now both refresh issue and CPU consumption. Only thing now is to make it work automatically ;))