madVR - high quality video renderer (GPU assisted)

[ryrynz]

Originally Posted by yesgrey

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 of 60fps video no glitch and 30fps with glitches.

Originally Posted by madshi

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]

Originally Posted by madshi

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

0.56's CPU consumption is as low as 0.49 !
Dropped frames & glitches are stable @ 2 & 0

Originally Posted by madshi

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 , 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.

Originally Posted by SamuriHL

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

Oh, nice

Originally Posted by yesgrey

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

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

oh...I <3 red

[BeNooL]

Originally Posted by madshi

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]

Originally Posted by ranpha

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.

Originally Posted by ranpha

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

Originally Posted by ranpha

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]

Originally Posted by Virtual_ManPL

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]

Originally Posted by Andy o

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.

Originally Posted by jmone

I can believe I'm that "special"!

Way to go!!!

Originally Posted by Razoola

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?

Originally Posted by ikarad

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.

Originally Posted by Virtual_ManPL

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.

Originally Posted by Virtual_ManPL

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

Originally Posted by Virtual_ManPL

I'm not programmer.

Originally Posted by Virtual_ManPL

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.

Originally Posted by Virtual_ManPL

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.

Originally Posted by Virtual_ManPL

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.

Originally Posted by 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.

Sounds good to me.

Originally Posted by 6233638

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.

Originally Posted by 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.

Not even stopping fixes it!? That's really weird...

Originally Posted by Mark_A_W

(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...

Originally Posted by Mark_A_W

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?

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by thuan

Here's the log 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.

Originally Posted by Rain1

0.56's CPU consumption is as low as 0.49 !
Dropped frames & glitches are stable @ 2 & 0

Nice! Thanks for testing!

Originally Posted by Rain1

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 , 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.

Originally Posted by BeNooL

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...

Originally Posted by DigitalLF

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]

Originally Posted by Virtual_ManPL

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 .

[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]

Originally Posted by jmone

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

Oh, 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]

Originally Posted by 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]

Originally Posted by nevcairiel

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!

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]

Originally Posted by ryrynz

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