madVR - high quality video renderer (GPU assisted)

[ikarad]

Originally Posted by madshi

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.

Originally Posted by ikarad

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]

Originally Posted by nevcairiel

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

Originally Posted by SamuriHL

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

Originally Posted by Hypernova

I suggest rotating between three colors (joking of course).

Please don't. I'm sensitive to rainbow effect.

[underzone]

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

Originally Posted by madshi

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.

Originally Posted by SamuriHL

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]

Originally Posted by yesgrey

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.

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

Originally Posted by jmone

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]

Originally Posted by nevcairiel

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 compared to 32bit

[Mangix]

Originally Posted by Virtual_ManPL

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 compared to 32bit

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]

Originally Posted by Virtual_ManPL

EDIT:
Browsers are also faster in 64bit mode compared to 32bit

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]

Originally Posted by yesgrey

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

Originally Posted by madshi

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.



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]

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.
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 ) to be sure that we're using the latest one.

[Virtual_ManPL]

Originally Posted by Mangix

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

Originally Posted by ranpha

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.

Originally Posted by SamuriHL

Cyberlink 64 bit decoders? From where?.

PowerDirector 9 Ultra64 contains it.

Originally Posted by SamuriHL

I know nothing about mainconcept's 64 bit stuff so I can't speak to that.

MainConcept (Full version Windows 64-bit)

[SamuriHL]

Originally Posted by Virtual_ManPL

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.

Originally Posted by Virtual_ManPL

MainConcept (Full version Windows 64-bit)

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]

Originally Posted by Virtual_ManPL

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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]

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

Originally Posted by 6233638

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