madVR - high quality video renderer (GPU assisted)

[ikarad]

Do you actually *see* the glitches? I mean is motion non-smooth? v0.50 did not even know if there were glitches, even if there were some.


No really (Like counter increase slowly I can't see really if there is a problem with naked eyes) but if the counter increase, it means that there are glitches.
If one day movies that I see are not smoothing, I prefer to know that madvr is not the culprit because I hate make tests during many hours to know where is the culprit.

I think I find where is the problem.

With madvr0.54 there is the problem all the time.

With madvr 0.55, the problem appears only when ctrl+J function are displayed (enven thing with 0.56). If I don't display ctrl+J function, there is no problem anymore. )

(I will test tomorrow with many videos to verify if it's right all the time

[yesgrey]

IMHO, 64-bit is only really useful if you need to handle alot of data, and the 32-bit address space might run out on you.
You're getting pretty close... ;)

I made the argument for 64 bit before, too, but, there's another issue. What decoder to use?
Well, CUDA 4.0 seems to support 64bit, so, maybe nevcariel would also create a LAV CUVID 64bit... ;)

I suggest rotating between three colors (joking of course).
Please don't. I'm sensitive to rainbow effect. :cool:

[underzone]

Oh dear... v0.55 has broken mine too. Black screens on either monitor (or amp), or an MPC-HC hang. latest everything (MPC 3033, ffdshow, etc)


update... installed 0.54 again, everything spot on again. Wierd!

FIXED .... by 0.56

Thanks :)

[Virtual_ManPL]

Better performance? Nope. Current HTPC software is not any faster in 64bit, often it's slower.

Wrong, without any benchmarks I can clearly see that for example Xvid 64bit Jawor's builds are superior in speed terms compared to 32bit.
In 64bit I can see that decoder don't use that much CPU like in 32bit and it don't drop frames or drop only a few when all postprocessing is enabled and I play HQ movie with 60fps.

Also for well written code, the source code is agnostic to the underlying platform, and can compile to x86-32, x86-64, IA-64 without modification, so in speed terms should be the same or better (due to more registers on 64bit side).
Exception to this is if you hand code certain algorithms using assembly or if you implement a compiler/interpreter.



No commercial decoders are going to work in 64 bit.

There're plenty of H.264/AVC 64bit decoders like ffdshow, CoreAVC, MainConcept ,CyberLink or internal MPC-HC.
In near future also LAV CUVID.
Moar are not needed ;)

[nevcairiel]

Well, CUDA 4.0 seems to support 64bit, so, maybe nevcariel would also create a LAV CUVID 64bit... ;)

Older versions of CUDA do too, there was just some specific reason that 3.2 does not - something about APIs being in flux and the new ones couldn't handle 64-bit memory pointers yet, or something.



Also for well written code, the source code is agnostic to the underlying platform, and can compile to x86-32, x86-64, IA-64 without modification, so in speed terms should be the same or better (due to more registers on 64bit side).
Exception to this is if you hand code certain algorithms using assembly or if you implement a compiler/interpreter.

Sorry, but this comment just shows that you have no idea what you're talking about.
Its never as simple as flipping a switch and compiling for 64-bit, if you didn't intend for this from the beginning - and that has nothing to do with "well written".

Also like i tried to explain earlier, if you just compile something optimized for 32-bit as 64-bit, in many cases it will actually be *slower* and consume more memory.
You can make it faster in 64-bit, but thats alot of extra work, for a very minor gain.

[6233638]

Madshi, I think you've (mostly) cracked it. I reset all my settings (something I usually do when there's been a big change, but hadn't since you moved things to the registry) and then chose my preferred scaling options. I was surprised to see that this leaves dekstop composition enabled. Personally I prefer that as it means a smoother transition in and out of fullscreen/exclusive mode and I never had any issues with it.

Playing back Blu-ray at 24Hz seems to be flawless now after 15 minutes or so of testing in 0.56

The buffers never deviated from:Decoder Queue: 7-8/8
Upload Queue: 7-8/8
Render Queue: 7-8/8
Backbuffer Queue: 6-7/16
Present Queue: 6-7/16
And there were no dropped/delayed frames or presentation glitches. Not only that, but there were zero dropped frames when pausing and resuming video, which was instantaneous and perfectly smooth - a first for me.

With 30fps content at 60Hz I am still getting a lot of presentation glitches, though I didn't have anything to hand that was a good test for whether playback was actually smooth or not. (most of the 30fps content I watch is downloaded video)

1080/50p
1) madVR's OSD is still happily tearing etc on fast pans. What I find odd on this one is why would a fast pan in the movie cause tearing in the OSD (unless the whole presentation is also tearing in the renderer - which is kind of hard to tell as similar issues could have been in the original encoding from the Cam, decoding by ffdshow etc The OSD however is added after all is decoded)That sounds like your display is using interpolation and doing a bad job of it. I can't think of anything else that would cause that problem with the OSD. (the OSD is not moving)


People arguing for a 64-bit build... eh, I couldn't care less unless you can convince James over at Slysoft to resume ReClock development and work on a 64-bit build first. If not, it's just wasted development time on Madshi's part.

[Virtual_ManPL]

but this comment just shows that you have no idea what you're talking about.
Its never as simple as flipping a switch and compiling for 64-bit, if you didn't intend for this from the beginning - and that has nothing to do with "well written".

Can be true, I'm not programmer.
I only based on opinions I heard that for well written code there shouldn't be any differences in 32 or 64bit compiling.


EDIT:
Browsers are also faster in 64bit mode (http://arewefastyet.com/) compared to 32bit (http://arewefastyet.com/?a=b&machine=8)

[Mangix]

Can be true, I'm not programmer.
I only based on opinions I heard that for well written code there shouldn't be any differences in 32 or 64bit compiling.


EDIT:
Browsers are also faster in 64bit mode (http://arewefastyet.com/) compared to 32bit (http://arewefastyet.com/?a=b&machine=8)

i've heard that the internal decoders used in mpc-hc are slower in 64-bit since like nevcairiel said, they are not optimized for 64-bit. doesn't bother me unless i had a really weak processor though.

also, that test was done on mac. mac is not windows.

[ranpha]

EDIT:
Browsers are also faster in 64bit mode (http://arewefastyet.com/) compared to 32bit (http://arewefastyet.com/?a=b&machine=8)

Not for IE9. IE9 64-bit is slower than the 32-bit version.

Oh BTW, I will also want to request that the OSD text to be available in red too. Green OSD text are utterly useless in bright scenes.

[SamuriHL]

Well, CUDA 4.0 seems to support 64bit, so, maybe nevcariel would also create a LAV CUVID 64bit... ;)


Well, I can already hear what Nev is going to say to that one... :D Don't get me wrong, I also wanted the 64 bit path to work, but, they're right...it's a lot of trouble for something that quite frankly has zero benefit. And right now, for all the devs, focusing on the current problems is far better use for their time. Consider that madshi doesn't even have time to implement "simple" things like a reset to defaults or color picker for the CTRL-J screen. Adding a 64 bit path opens up a big can of worms that would take a lot of time away from other more useful things. Same goes for Nev, although, I suspect 64 bit for CUVID wouldn't be all that difficult. :)

[pankov]

madVR v0.56 released

http://madshi.net/madVR.zip

* fixed: going directly to fullscreen mode made madVR freeze

madshi,
this version fixes all problems I had with v0.5x

Now the CPU usage is equal on both monitors and the same with v0.4x and there are no problems using madVR in ZoomPlayer on second monitor.

:thanks:

P.S.
I've just noticed something interesting - if I start playback of 23.976 file at ~23.974 and change the monitor refresh rate to 50Hz afterwards the screen flashes a lot but after it settles it's still playing at 23.974 (reported by madVR and seeming smooth to my eyes so I guess it's still 23.976) until I go to windowed mode - then it goes to 50.000xx (both in OSD and in my eyes - little stuttering).
Am I sensing the possibility of automatic refreshrate switching or am I dreaming?

[SamuriHL]

There're plenty of H.264/AVC 64bit decoders like ffdshow, CoreAVC, MainConcept ,CyberLink or internal MPC-HC.
In near future also LAV CUVID.
Moar are not needed ;)

AVC is not the whole world. ;) I have plenty of VC-1 content that requires a GOOD commercial decoder to play properly. (Don't get me started on that issue)

Cyberlink 64 bit decoders? From where?. ffdshow yes, which I already said. CoreAVC I've not tried in 64 bit land. Wasn't sure they did 64 bit but it makes sense. I know nothing about mainconcept's 64 bit stuff so I can't speak to that. In any case, for AVC, sure, you can probably hobble something together to get it to work for quite a bit of content. But, in the video world, 32 bit has far more support behind it. I would love for everyone to move to 64 bit but ONLY if there's an actual gain behind it. Just because it SOUNDS better doesn't make it so in the programming world. :)

[pouyoux]

I've a bug which is recurent with all madvr versions (including 0.56) when I do a ctrl-alt-sup to open the windows task manager mpc-hc begins to drop frames like crazy. Whatever I try (stopping/pausing video, resizing it) I can't stop it. I need to close mpc-hc and start it again to stop this.

Moreover as there are lots of new versions out there it could be usefull to have the madvr version used in the OSD (in whatever color you want :p ) to be sure that we're using the latest one.

[Virtual_ManPL]

also, that test was done on mac. mac is not windows.

If I have time I can do the same tests on Windows on JaegerMonkey Firefox trunk, but there will be probably the same

Not for IE9. IE9 64-bit is slower than the 32-bit version.

Because IE is exception like in every thing. M$ simply didn't optimize it from testing nightly times in any way as I heard.


Cyberlink 64 bit decoders? From where?.
PowerDirector 9 Ultra64 contains it.


I know nothing about mainconcept's 64 bit stuff so I can't speak to that.
MainConcept (Full version Windows 64-bit) (http://downloads.mainconcept.com/mdl/mdl.php?downloads.mainconcept.com+DecoderPack_H264Broadcast)

[SamuriHL]

PowerDirector 9 Ultra64 contains it.


Hmm, and they use it where it makes sense...video editing. 64 bit TRULY makes sense for encoding because of the ability to use a greater amount of memory. For decoding, however, I don't think there's much of a benefit to 64 bit. Nonetheless I'm curious as to what the trial brings for 64 bit land. I guess I should compile myself 64 bit ffdshow and mpc-hc and see if it makes any difference in memory or cpu usage compared to 32 bit.


MainConcept (Full version Windows 64-bit) (http://downloads.mainconcept.com/mdl/mdl.php?downloads.mainconcept.com+DecoderPack_H264Broadcast)

Not bad. MainConcept has decent encoders as evidenced by Video ReDo. No idea about their decoders, but, they're a solid company so I'm sure they'd be just fine. I've just never used them.

[ranpha]

Because IE is exception like in every thing. M$ simply didn't optimize it from testing nightly times in any way as I heard.



So you indeed need to optimize a 64-bit build, and there is no such thing like 'write one code-path, and compile to 32-bit and 64-bit builds'. I think madshi should just continue improving the FSE mode instead of porting it to 64-bit.

Oh BTW, Chrome 32-bit is faster than Chrome 64-bit too. Must be some dorky engineers Google have there at Mountain View.

[Mark_A_W]

Well, there's some sense to that. Let me explain:

Let's say you play a 24fps movie on a 120Hz display. What madVR now does (new exclusive path) is this:

(1) render frame 1
(2) copy frame 1 to backbuffer and present
(3) copy frame 1 to backbuffer and present
(4) copy frame 1 to backbuffer and present
(5) copy frame 1 to backbuffer and present
(6) copy frame 1 to backbuffer and present
(7) render frame 2
(8) copy frame 2 to backbuffer and present
(9) [...]

Basically every frame is rendered once and then copied to backbuffer (and presented) 5 times, since 120Hz / 24fps = 5x. Now the first two flush settings only apply to the rendering, but not to the backbuffer copy and presentation. So I guess with high refresh rates, if your GPU/driver needs flushes, you need to flush after the backbuffer copy or after the presentation. Otherwise you'll have a flush only every fifth VSync event. Two questions for my interest:

- does flushing after present instead of after backbuffer work just as well?
- does the new rendering path now work better for you than the old (and than windowed mode)?

Those of you with glitches when doing 24fps -> 60Hz playback, please also try flushing after either the backbuffer copy or after the present!

(Running 23.976p video at 95.906hz interlaced, secondary monitor.)

There's DEFINITELY something going on with the bottom two Flush options.

With some sort of flush set for BOTH (hard to find consistency here), my "new method" exclusive mode playback is greatly improved.

However it's not perfect, and nowhere near as good as windowed. The reclock tearing test does not lie, and there is a little jerk backwards/delay every second or so. It's not *that* noticeable when watching video (kinda like 3:2 pulldown), but when I drop back to windowed you sure notice the difference.

When playback is in this "better" exclusive state, the presentation glitch counter is no longer incrementing - all the counters are rock solid.

However my queues are odd:

- decoder queue 7-8/8 (good)

- upload queue 7-8/8 (good)

- render queue 1-3/8 (bad)

- backbuffer queue 0-2/4 (bad)

- present queue 0-2/4 (bad)


CPU usage appears ok, and fiddling with the 0-16 pre-present frames doesn't seem to help.


Some progress at least - I have a hope now that exclusive mode is a possibility for me, as I am now getting the same results as the others with high refresh rates.


Mark

Edit: A clarification: When the buffers are at default, and I'm getting the constant hiking of presentation glitches in exclusive mode, there is a very obvious glitch in playback at that time - it's not a cosmetic reporting issues, something is broken.

[cyberbeing]

Somehow your PC is always different to everybody else's... :p

Bad: With no Flushing, my Render Queue is 3/8 and my Backbuffer & Present Queues are 0/2

Good: When I set 'After Last Render Step' to Flush & Wait, my Render Queue is 7/8, but my Backbuffer & Present Queues never exceed 1/2.

Best: When I set 'After Intermediate Render Steps' to Flush & Wait, my Render Queue is 7/8, but my Backbuffer Queue is 2/2 most of the time and my Present Queue fluctuates between 1/2 & 2/2.

At this point I'm not even taking smoothness into account since Present/Backbuffer Queues still cause me occasional instability with the new path, even with Nearest Neighbor and Disabled 3DLUT.

Ok, v0.55 allows you to choose a present queue of 1.
I'm unable to set Present Queue to 1 in either 0.55 or 0.56. Setting to 1 in the settings results in a Present Queue of 3 as reported by CTRL+J stats...

Hopefully you can fix it in the next version, and this doesn't mean setting it to 1 is impossible.

A general question: Does windowed mode still work better for you than the new exclusive mode?
Since I'm having some sort of present performance bottleneck with the new exclusive mode, windowed mode is better.

Windowed Mode > Old Exclusive Mode (1 backbuffer) > New Render Mode (2 pre-presented frames)

I'd like to get the new Exclusive Mode working, but until you get it to a point where my Render Queue never drops below 6/8 and my Backbuffer/Present Queues never drop to 0, I'll need to stick with Windowed mode. With the introduction of flush settings it's gotten things ~80% stable, but that's still not good enough for set & forget. Windowed mode was always nearly perfectly smooth for me with my special flush settings, so I don't want to judge the New Render Mode smoothness until it's 98-100% stable as far was Queues go.

The logging is still in there. You can use v0.54 or v0.55.
If you say so. When I did some test logs, the madVRcpu2 logs were always bigger with more logging than the madVR 0.54 official. I'll try to get you a hang log with the latest official debug build soon.

[Andy o]

btw, I guess I get why you took out that 3 second wait madshi, when going from window to full screen, but if I change refresh rates when on windowed mode, and then switch to exclusive, it works fine. If I change while on exclusive, it doesn't work. I think the 3 second wait might make MPC-HC's auto refresh switch work for some of us, if not most.

HEh, never mind. Actually what works is when I switch refresh rate manually in windowed mode, but with MPC-HC's auto refresh rate, it doesn't work in windowed mode. So moot point.

[jmone]

That sounds like your display is using interpolation and doing a bad job of it. I can't think of anything else that would cause that problem with the OSD. (the OSD is not moving)

You are correct! I have a Pio LX608 and it supports internal processing (as distinct from the input signal freq) of
Drive Mode 1 = 75hz
Drive Mode 2 = 100hz
Drive Mode 3 = 72hz

I had it on Drive Mode 3 for the best display of Blu-ray. The result was my 50fps stuff had interpolation errors in the fast pans as you suggested when the TV's internal processing was set to 72hz.

Digging some more...The Pio also has a "pure cinema" mode that rumor has it when set to "advanced" will change the processing rate (none of this is well document if at all)....Anyway Using my test patters here: -- http://www.avsforum.com/avs-vb/showthread.php?t=1276064 I can now see (when in Drive Mode 2 and "pure cinema = advanced):
- 24fps material @ 24hz refresh rate = TV Displays 3 overlapping images on the screen (eg looks like 3 frames per 72hz)
- 25fps material @ 50hz refresh rate = TV Displays 4 overlapping images on the screen (eg looks like 4 frames per 100hz)
- 30fps material @ 60hz refresh rate = TV Displays 2 overlapping images on the screen (eg looks like 2 frames per 60hz)

The result for me are:
1) the interpolation corruption is gone
2) the motion on different frame rates is smooth (eg constant number of frames being displayed - eg no alternative 3:2 style pulldown pattern)
3) the various "blur" (if that is the correct term) created by the overlapping interpolated frames for each of these patterns seem fine to my eyes so far.

Thanks
Nathan

EDIT: FYI - These multiple overlapping interpolated frames is defiantly the TV doing stuff as with a std PC monitor you just see the one red square

[ryrynz]

Any possibility of making it... blue?

I'm all for the blue ;-) but seriously selecting the color would be nice, I realize it wouldn't be a priority.

[jmone]

FYI - These 24 / 25 / 30 fps sample files are good visual to test the "smoothness" of your setup: more at http://www.avsforum.com/avs-vb/showthread.php?t=1276064

[thuan]

Here's the log (http://www.mediafire.com/?bnzcxw2o5ihxu6o) of 60fps video no glitch and 30fps with glitches.

Weird. Can anybody reproduce that?
Whatever you did in 0.56 that fixed this bug I have with 0.55.

EDIT: About presentation glitches, although the count does increase with unmatched video fps and monitor refresh rate, I do not notice judder. So in case you have no idea, it's fine, too.

[Rain1]

Nice! :) Did you double check if the high CPU consumption is really fixed? Just to be sure...

http://i6.photobucket.com/albums/y244/rain1/test056.jpg
0.56's CPU consumption is as low as 0.49 (http://forum.doom9.org/showthread.php?p=1491809#post1491809) ! :eek:
Dropped frames & glitches are stable @ 2 & 0

Do you get any different results with madVR if you switch the NVidia control panel back to default (Maximum Pre-Rendered Frames -> 3)? Thanks.

Yeah...after i change that value in nVidia control panel to 3 (default):

* Dropped frames: 2 2 2 2 2
* Presentation glitches: 0 0 0 1 0

...since that 1 glitch bugs me :p, I replayed the clip 5 times more:

* Dropped frames: 2 2 2 2 2
* Presentation glitches: 0 1 0 1 0

...then I change that value back to 8 & replay 10 times, the result is solid 2 & 0 for dropped frames & glitches.

The settings rain1 posted are EXACTLY what I've been using on my laptop and give me the best results.

Oh, nice :)

When we start thinking that madVR cannot improve anymore, you come and surprise us. :)

This !
madshi is in afterburner mode or something... :cool:

oh...I <3 red :p

[BeNooL]

Which refresh rate and movie frame rate are we talking about here?
A fairly simple 1440x1080@25 (IPTV capture) to 1920x1080@60.

With old rendering in 0.48 with all scaling settings identical, such files play totally fine with GPU usage in the 70-75% range.

[DigitalLF]

MadShi: can i haz OSD in tze pinkz? ;)

[Virtual_ManPL]

So you indeed need to optimize a 64-bit build, and there is no such thing like 'write one code-path, and compile to 32-bit and 64-bit builds'.
You just need to compile it with proper options.
Just look on PaleMoon and Firefox in the past, PM was faster over 25% than Fx.

x86-64 have double time more registers so why it should be slower ?
It's just like saying that 2GB is faster than 4GB, because chipset and CPU have less job to do.

I think madshi should just continue improving the FSE mode instead of porting it to 64-bit.

I completely agree!
But if we will see improvements in compiled 64bit builds, not based on myths, why not start also supporting it?
Don't forget that next Windows after 8, will be probably only 64bit and the will introduce there 128bit with new kernel


Oh BTW, Chrome 32-bit is faster than Chrome 64-bit too. Must be some dorky engineers Google have there at Mountain View.

I see that Chrome is faster in kraken, nearly the same in sunspider and only slower in v8bench

[Mr Alpha]

You just need to compile it with proper options.
Just look on PaleMoon and Firefox in the past, PM was faster over 25% than Fx.

x86-64 have double time more registers so why it should be slower ?Many of the fastest decoders rely on hand optimized assembly, which doesn't work in 64-bit mode. Converting it is not a matter of flipping a bunch of compiler switches, but rewriting it by hand for 64 bit.

[madshi]

oops, not when I do that. When I go from windowed (small window) to full screen. I used to get the 3 second wait before...
That was changed ages ago.

I can believe I'm that "special"!
Way to go!!! :p

Yes to both. In fact flushing after present gives me one presentation glitch less (I get 2 when flushing after copy to backbuffer)

update, dang, I just got a D3D error when flushing on presentation. So the answer is no to the first one.
What kind D3D errors are these exactly? Maybe you already explained earlier, don't remember.

What happens if you activate *both* bottom flushes at the same time? Better/same/worse?

I think I find where is the problem.

With madvr0.54 there is the problem all the time.

With madvr 0.55, the problem appears only when ctrl+J function are displayed (enven thing with 0.56). If I don't display ctrl+J function, there is no problem anymore. )

(I will test tomorrow with many videos to verify if it's right all the time
Hmmmm... You had one glitch per second, right? That would make some sense because the Ctrl+J OSD is updated exactly once per second.

Wrong, without any benchmarks I can clearly see that for example Xvid 64bit Jawor's builds are superior in speed terms compared to 32bit.
Great! You found one decoder that appears to be faster in 64bit. However, most others are not, some are slower.

Also for well written code, the source code is agnostic to the underlying platform, and can compile to x86-32, x86-64, IA-64 without modification
I'm not programmer.
:rolleyes:

Exception to this is if you hand code certain algorithms using assembly or if you implement a compiler/interpreter.
It just so happens that many decoders have hand coded assembler in them. Also I'm using Delphi for all the helper DLLs used by madVR.

There're plenty of H.264/AVC 64bit decoders like ffdshow, CoreAVC, MainConcept ,CyberLink or internal MPC-HC.
In near future also LAV CUVID.
None of them are faster in 64bit compared to 32bit, AFAIK. IIRC, e.g. CoreAVC is even slower in 64bit compared to 32bit.

I completely agree!
But if we will see improvements in compiled 64bit builds, not based on myths, why not start also supporting it?
Because my time is limited. And I'm trying to spend the time in such a way that everyone get's the biggest "bang for the buck". It would cost me several days, maybe even weeks to create a 64bit madVR version. And that is such a big amount of time that I could instead spend on improving things that really make a noticeable improvement.

Madshi, I think you've (mostly) cracked it. I reset all my settings (something I usually do when there's been a big change, but hadn't since you moved things to the registry) and then chose my preferred scaling options. I was surprised to see that this leaves dekstop composition enabled. Personally I prefer that as it means a smoother transition in and out of fullscreen/exclusive mode and I never had any issues with it.

Playing back Blu-ray at 24Hz seems to be flawless now after 15 minutes or so of testing in 0.56

The buffers never deviated from:Decoder Queue: 7-8/8
Upload Queue: 7-8/8
Render Queue: 7-8/8
Backbuffer Queue: 6-7/16
Present Queue: 6-7/16
And there were no dropped/delayed frames or presentation glitches. Not only that, but there were zero dropped frames when pausing and resuming video, which was instantaneous and perfectly smooth - a first for me.
Sounds good to me.

With 30fps content at 60Hz I am still getting a lot of presentation glitches, though I didn't have anything to hand that was a good test for whether playback was actually smooth or not. (most of the 30fps content I watch is downloaded video)
Ok.

I've a bug which is recurent with all madvr versions (including 0.56) when I do a ctrl-alt-sup to open the windows task manager mpc-hc begins to drop frames like crazy. Whatever I try (stopping/pausing video, resizing it) I can't stop it. I need to close mpc-hc and start it again to stop this.
Not even stopping fixes it!? That's really weird...

(Running 23.976p video at 95.906hz interlaced, secondary monitor.)

There's DEFINITELY something going on with the bottom two Flush options.

With some sort of flush set for BOTH (hard to find consistency here), my "new method" exclusive mode playback is greatly improved.

However it's not perfect, and nowhere near as good as windowed. The reclock tearing test does not lie, and there is a little jerk backwards/delay every second or so. It's not *that* noticeable when watching video (kinda like 3:2 pulldown), but when I drop back to windowed you sure notice the difference.

When playback is in this "better" exclusive state, the presentation glitch counter is no longer incrementing - all the counters are rock solid.
So playback is not perfect but still no counter is incrementing? That's not good... :(

However my queues are odd:

- decoder queue 7-8/8 (good)
- upload queue 7-8/8 (good)
- render queue 1-3/8 (bad)
- backbuffer queue 0-2/4 (bad)
- present queue 0-2/4 (bad)
Do you have a "flush & wait" somewhere? Try changing it to "flush". Maybe that helps the queues?

I'm unable to set Present Queue to 1 in either 0.55 or 0.56. Setting to 1 in the settings results in a Present Queue of 3 as reported by CTRL+J stats...
Oh, must be a bug, will fix that in the next build.

If you say so. When I did some test logs, the madVRcpu2 logs were always bigger with more logging than the madVR 0.54 official.
That's because the madVRcpu2 logs contain a *LOT* of logging for finding the cause of the high CPU consumption. These log outputs are removed in the full release builds.

Here's the log (http://www.mediafire.com/?bnzcxw2o5ihxu6o) of 60fps video no glitch and 30fps with glitches.

EDIT: About presentation glitches, although the count does increase with unmatched video fps and monitor refresh rate, I do not notice judder. So in case you have no idea, it's fine, too.
Thx.

0.56's CPU consumption is as low as 0.49 (http://forum.doom9.org/showthread.php?p=1491809#post1491809) ! :eek:
Dropped frames & glitches are stable @ 2 & 0
Nice! :) Thanks for testing!

Yeah...after i change that value in nVidia control panel to 3 (default):

* Dropped frames: 2 2 2 2 2
* Presentation glitches: 0 0 0 1 0

...since that 1 glitch bugs me :p, I replayed the clip 5 times more:

* Dropped frames: 2 2 2 2 2
* Presentation glitches: 0 1 0 1 0

...then I change that value back to 8 & replay 10 times, the result is solid 2 & 0 for dropped frames & glitches.
Weird. Not sure what to say about this.

A fairly simple 1440x1080@25 (IPTV capture) to 1920x1080@60.

With old rendering in 0.48 with all scaling settings identical, such files play totally fine with GPU usage in the 70-75% range.
Due to the way the new exclusive mode rendering path works, it does consume a bit more resources when refresh rate and movie framerate are not matched. With D3D9 there seems to be no way around that. With D3D11 there might, but I'll not look into D3D11 anytime soon. So you'll have to make do with the old exclusive path or with windowed mode for the time being...

MadShi: can i haz OSD in tze pinkz? ;)
Sure! Just use your TV remote to screw up the color balance accordingly!

[madshi]

Those of you who favor a red Ctrl+J OSD: I'd suggest that you start a new thread with a vote. I personally do not care which color the OSD has. So whatever the majority wants, I'm fine with it. I do not want to add an option for that, though, since the OSD will be redesigned sooner or later, anyway...

[Dogway]

In near future also LAV CUVID

64 bits enviroments has unofficialy settled for professional systems only, those where you make money with. If you want complete compatibility system go to x86 windows as no brainer.

edit: I like green OSD

[thuan]

Typically 64bit binary is only needed if you need to calculate a ridiculous amount of data and/or you want better precision without sacrificing speed by creating your own structure to store number (for example) with higher precision than normally supported in programming language. For smaller set of data with normal precision need, 32bit performs similar to 64bit performance wise without the overhead to store bigger variable/structure of the latter if you simply recompile them.

Obviously, 64bit has its use like in scientific computing such as simulation and stuffs (my work), video encoding/editing, game. For video decoding and madVR which only needs couple of hundred of MB and normal precision (for higher precision FP calculation you can use CPU SIMD unit in 32bit) I don't see many points in compiling a 64bit version. MS won't be taking out the Win32 emulation layer in Windows anytime soon, that is shooting their user base.

@Virtual_ManPL:
PaleMoon is not a simple Firefox recompile and you won't see 128bit CPU anytime soon (how much RAM do you need, dude? and we'll need a 128bit OS to manage that amount of RAM). For Chrome once upon a time it was slower, you need to optimize the thing for that. FWIW, 64bit OS memory manager does have a higher overhead than 32bit, but it is so small, the benefits it bring are more. So "It's just like saying that 2GB is faster than 4GB, because chipset and CPU have less job to do." is true to some degree but it's silly to say so :D.

[ryrynz]

64 bit development has been discussed before, I can't see it necessary to discuss it in depth when someone with little to no programming experience jumps in and asks "can I haz 64 bit madVR plz?"

[6233638]

You are correct! I have a Pio LX608 and it supports internal processing (as distinct from the input signal freq) of
Drive Mode 1 = 75hz
Drive Mode 2 = 100hz
Drive Mode 3 = 72hz

I had it on Drive Mode 3 for the best display of Blu-ray. The result was my 50fps stuff had interpolation errors in the fast pans as you suggested when the TV's internal processing was set to 72hz.

Digging some more...The Pio also has a "pure cinema" mode that rumor has it when set to "advanced" will change the processing rate (none of this is well document if at all)....Anyway Using my test patters here: -- http://www.avsforum.com/avs-vb/showthread.php?t=1276064 I can now see (when in Drive Mode 2 and "pure cinema = advanced):
- 24fps material @ 24hz refresh rate = TV Displays 3 overlapping images on the screen (eg looks like 3 frames per 72hz)
- 25fps material @ 50hz refresh rate = TV Displays 4 overlapping images on the screen (eg looks like 4 frames per 100hz)
- 30fps material @ 60hz refresh rate = TV Displays 2 overlapping images on the screen (eg looks like 2 frames per 60hz)

The result for me are:
1) the interpolation corruption is gone
2) the motion on different frame rates is smooth (eg constant number of frames being displayed - eg no alternative 3:2 style pulldown pattern)
3) the various "blur" (if that is the correct term) created by the overlapping interpolated frames for each of these patterns seem fine to my eyes so far.

Thanks
Nathan

EDIT: FYI - These multiple overlapping interpolated frames is defiantly the TV doing stuff as with a std PC monitor you just see the one red squareOh, what you have posted there is not correct, and the Pioneers don't do interpolation unless you are using them in the "smooth" mode. (which is anything but)

Drive Mode 1 = 75Hz
Drive Mode 2 = 100Hz
Drive Mode 3 = 60Hz

The drive modes only apply to a 50Hz input signal. They have no effect on a 24p or 60Hz input.
The only thing that has an effect on 24p is setting purecinema to advanced which causes the set to use 3:3 and display a 24p input at 72Hz.

With a 50Hz input for film content you should use DM1, if you will be using that input for a mixture of video/film use DM2. Never use DM3. DM3 is only there because, being a plasma, the picture quality gets worse as refresh rate increases. However 50Hz content played back at 60Hz is never smooth.


This is part of the reason I got rid of my Kuros, anything over 60Hz was unwatchable to me and the majority of my viewing was 24p film (72hz)

[nevcairiel]

Hey madshi,

i think i broke something. I cannot get my Dev PC to go into Exclusive mode anymore, not even .49 works.

Here is a log of 0.56, starting MPC-HC, going full screen -- waiting a bit, and exiting.

http://files.1f0.de/madVR-no-fse.zip

Anything obvious stand out to you?

[nevcairiel]

Hey madshi,

i think i broke something. I cannot get my Dev PC to go into Exclusive mode anymore, not even .49 works.

Here is a log of 0.56, starting MPC-HC, going full screen -- waiting a bit, and exiting.

http://files.1f0.de/madVR-no-fse.zip

Anything obvious stand out to you?

Actually, i figured it out.
"Actual Multiple Monitors" caused it, and i just started to like having it around for the second task bar. :(

/me kills it with fire.

[madshi]

Actually, i figured it out.
"Actual Multiple Monitors" caused it, and i just started to like having it around for the second task bar. :(

/me kills it with fire.
According to your log:

00007139 Render fullscreen windowed mode, covered by some windows
00007139 Render madVR window [madVR] "madVR" {0,0,1920,1200}
00007139 Render covered by window [CaptionButton_Floating_Window] {1767,-7,1913,45}
If you can rid of that CaptionButton_Floating_Window the problem should go away.

[watchman]

With the latest version everything is fine for me and playback is smooth again. Very good work indeed! :thanks:

There are sometimes few glitches when source video isn't perfectly matched with display refresh rate, but i can't notice any stuttering and thanks to lower CPU loads I can now play samsung oceanic life demo and also 1080p@60fps source without any dropped frames and that is super awesome :)

I also played with settings little more and these are working best for me:
16 pre-presented frames
don't flush
flush
don't flush
flush

[sneaker_ger]

Any tweaking gone into 0.55 and 0.56? I'll just skip testing those then.

[Virtual_ManPL]

jumps in and asks "can I haz 64 bit madVR plz?"
I'm not that person if you care to read my first post about 64bit version of madVR. I only asked nicely what's the plans for future.


@ madshi - Thank you for detailed answer. As you write you're using Delphi and it didn't have stable 64bit version yet, so I know what's the problem beside time spending on 64bit which can eat time and give nothing in return.
All this my info about well-written code and hand coded assembler was based on guys which code cross platform on x86-32, x86-64, ARM,IA-64, SPARC, PPC etc, not on real experiences so I can be wrong of course, because I'm not programmer like I said before. I only based on what I heard.

EDIT:
About other 64bit versions of decoders I will test it to see if they're faster than 32bit
/EDIT

@ Dogway - said that for ppl with >4GB of RAM, which is standard in these days :p

[Peekstra]

Zoomplayer is now working fine for me on the second screen :thanks:

[suanm]

I've downloaded both 0.54 version and 0.56. But MPC-HC dassent play any video so smoothly with 0.54,0.56 version in fullscreeen exclusive mode,drops frames too much to watch any video smoothly.
After replacing 0.54,0.56 with 0.48 or 0.49 version,MPC-HC works so smoothly in fullscreen exclusive mode. I wonder why this is ?

[yesgrey]

When I try madVR on a 1920x1080 @ 60Hz resolution the switching from windowed mode to exclusive fullscreen mode fails (old path). The new path switches fine. On lower resolutions both work fine.
Here (http://www.megaupload.com/?d=27C2R2RR) is the log.

[6233638]

As an update: just watching some 1080p25 content at 50Hz. After approximately 50 minutes of playback I'm at almost 1000 presentation glitches and while it may not be all of them causing stuttering, there has been a LOT of it throughout.

No dropped or delayed frames though. Looks like I only get smooth playback when the source framerate and refresh rate are at 1:1.

[madshi]

Any tweaking gone into 0.55 and 0.56? I'll just skip testing those then.
Mainly just bug fixes and settings dialog reordering.

I've downloaded both 0.54 version and 0.56. But MPC-HC dassent play any video so smoothly with 0.54,0.56 version in fullscreeen exclusive mode,drops frames too much to watch any video smoothly.
After replacing 0.54,0.56 with 0.48 or 0.49 version,MPC-HC works so smoothly in fullscreen exclusive mode. I wonder why this is ?
What is your display refresh rate and your movie framerate? Versions newer than v0.49 have a new rendering path for exclusive mode, which works better for some people and worse for others. You can switch v0.56 to the same method v0.49 used by activating the option "present only one frame at a time" in the madVR settings dialog.

When I try madVR on a 1920x1080 @ 60Hz resolution the switching from windowed mode to exclusive fullscreen mode fails (old path). The new path switches fine. On lower resolutions both work fine.
Here (http://www.megaupload.com/?d=27C2R2RR) is the log.
Hmmmm... I can see that it fails, I don't see why, though. Did this happen with older madVR builds, too?

As an update: just watching some 1080p25 content at 50Hz. After approximately 50 minutes of playback I'm at almost 1000 presentation glitches and while it may not be all of them causing stuttering, there has been a LOT of it throughout.

No dropped or delayed frames though. Looks like I only get smooth playback when the source framerate and refresh rate are at 1:1.
Hmmmmm... I've not watched a full movie with 25fps @ 50Hz yet, but on a quick check my integrated NVidia 9400 seems to be able to playback 25fps @ 50Hz with zero glitches (chroma: bilinear; luma: lanczos3). If my 9400 can do that, your 570 should be able to do it, too. Have you tried playing with the flush settings?

[yesgrey]

Hmmmm... I can see that it fails, I don't see why, though. Did this happen with older madVR builds, too?
Yes. Tried with 0.49 and the same happened.
I haven't noticed it earlier because I never use 1920x1080. This time I tried it to see LAV CUVID performance without any image downscaling.

[mindbomb]

madshi, your able to use lanczos on your 9400?

my laptop has a 9400m and a 720p screen, and for perfect playback, the best it could muster was chroma- mitchell, luma- bilinear.
tested with 1080p bluray videos and lav cuvid .3.

[madshi]

Yes. Tried with 0.49 and the same happened.
I haven't noticed it earlier because I never use 1920x1080. This time I tried it to see LAV CUVID performance without any image downscaling.
My best guess is then that your GPU driver doesn't handle madVR's request to use a refresh rate of "0" (which means "same as desktop") properly. The new exclusive mode doesn't use "0", but the real refresh rate of the desktop. This problem should be fixed once I add automatic refresh rate changing.

madshi, your able to use lanczos on your 9400?
Yes, but only with certain zoom factors (e.g. scaling a 1080p image just a little bit doesn't work, but scaling it down quite a bit does work). Also I have to set chroma to bilinear.

[yesgrey]

My best guess is then that your GPU driver doesn't handle madVR's request to use a refresh rate of "0" (which means "same as desktop") properly.
OK. It's not a big problem, because I never use it (unfortunately). I reported it in case it was some nasty bug, but it should be what you referred.

[Gleb Egorych]

0.54 is better than 0.51 & 0.52 and a way better than 0.53. It requires only 10+ pre-rendered frames to get smooth playback instead of 14+ with 0.51 and 0.52. Unfortunately windowed mode tweaks do not allow to lower the number though with tweaks and 8 pre-rendered frames presentation glitches appear significantly rarely than without tweaks and with the same 8 frames.
For me 0.56 is better than 0.54. Smooth playback with 8+ pre-rendered frames using CoreAVC in soft and CUDA modes. Thanks, madshi!
My system is Win7 x64, Q6600, 8800GT, FW270.51.