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

hmp_goose

15th July 2013, 02:55

Pardon me, but is there a guide, or set of test results, somewhere, to help one pick a new graphics card for use with madVR?

I currently have a GT 545 DDR3 ( https://en.wikipedia.org/wiki/GeForce_500_Series#GeForce_500_.285xx.29_series ), and I suspect I should upgrade to a GT 650 Ti BOOST ( https://en.wikipedia.org/wiki/GeForce_600_Series#GeForce_600_.286xx.29_series ), but I don't know or understand what madVR (or LAV, for that matter) looks for in a video card. Pixel Fill-rate? Texture, instead? I've read a GT 640 is enough ( http://www.anandtech.com/show/5969/zotac-geforce-gt-640-review-/7 ), but that seems to assume not much scaling is going on.

I do know my GT 545 DDR3 will choke on the madTestPatternSource that's at 1920x1080x60Hz, using Jinc3AR for both chroma and luma, dropping 12~16 fps.

I was originally going to just ask "does madVR care about ROPs," that being the chief difference between GT 650 Ti, and a GT 650 Ti BOOST, but that seems to be assuming way too much, ergo I ask the more complex question.

Thank you for your time.

Graeme Gill

15th July 2013, 08:03

Letting Argyll create one 3dlut for each source format should provide slightly better results, or at least that's what Graeme tells me.

It should avoid any unnecessary gamut clipping from the video source colorspace to your device colorspace, by not going through an intermediate source colorspace.

webs0r

15th July 2013, 12:22

That is how it's supposed to work. If you provide both a BT.709 and an SMPTE C 3dlut then madVR should automatically use the one that matches the source primaries. Now sure why that didn't work for me. It did work on my PC when I tested it. If you can reproduce that it doesn't work, please create a new bug issue in the madVR bug tracker, and if the problem only occurs with some files but not with all, maybe attach a small video sample (has to be zip).

Sorry my bad :o, I should have been more thorough. It does indeed work as intended. I have created 3 LUTs to cover the 3 main colourspaces.

FYI ran a 4000 patch set with ultra settings. (Performance tuning settings really helped!)

Collink -ir produced (to my eyes on a grey/colour steps patten - I haven't spent time to objectively check the result) a better result than -iaw. Particularly in the lighter greys. Hope I did everything right, but -iaw seemed to introduce a red tinge noticeable in the lighter greys on my setup.
The LUT produced by -ir was neutral.

I recently had to replace a slightly broken 4-5 year old 55" sammy and I went for a 70" sharp panel that wasn't as good quality but was half of what I paid for the sammy a long time ago. Colour accuracy was not as good. Until now - it's actually better - :thanks: madshi & Graeme

madshi

15th July 2013, 19:52

Is it considered strange for FRC with 59Hz to appear smoother than without FRC on 48Hz?
No, not necessarily. It all depends on what your display does with 48Hz input. If it internally converts those 48Hz to 60Hz by repeating some frames then obviously madVR's FRC will be smoother. However, please note that 50Hz to 60Hz currently has some wobbling artifacts sometimes, which will probably also apply to 48Hz. Still, if it looks better to your eyes, then use it.

I have an hypothesis that in some cases FRC could appear smoother than using the correct refresh rate. madshi disagrees.
I disagree, but only if the display "properly" supports the correct refresh rate natively. If you think the FRC could make things smoother even then, then what is your scientific explanation for that effect?

Pardon me, but is there a guide, or set of test results, somewhere, to help one pick a new graphics card for use with madVR?
Yes, try to find earlier recommendations in this thread. People continue to ask every couple of pages. Generally, pick one with GDDR5 memory. Users are saying that the 660 can do every scaling algorithm at any refresh rate. Lesser GPUs may work just as well for you, depending on your specific circumstances and wishes. madVR also works "fine" with rather slow GPUs, as long as you're willing to compromise on scaling algorithms etc...

madshi

15th July 2013, 19:53

madVR v0.86.9 released

http://madshi.net/madVR.zip

* fixed: madHcCtrl.exe had the wrong exe icon
* using linear light is now default for smooth motion FRC
* added new trade quality option "optimize subtitle quality for performance"
* modified the time when display mode is restored when media player closes
* win8 FSE refresh rate fix is now also applied without display mode changer
* added API to allow more control over test pattern progress bar
* cleaned up 3dlut and VideoLUT disable/define priorities
* improved support for combined 3dlut/VideoLUT file format ("collink -H")
Just some rather small changes...

hmp_goose

15th July 2013, 21:06

Yes, try to find earlier recommendations in this thread. People continue to ask every couple of pages. Generally, pick one with GDDR5 memory. Users are saying that the 660 can do every scaling algorithm at any refresh rate. Lesser GPUs may work just as well for you, depending on your specific circumstances and wishes. madVR also works "fine" with rather slow GPUs, as long as you're willing to compromise on scaling algorithms etc...
"GTX 660 is good" is a nice start … But it illustrates why I changed the question from "name a model, please" to "do I look for pixel fill-rate?" Reporting at tech web sites strongly imply memory bandwidth is a non-issue, and in fact I don't think I've ever seen the memory control unit on my card ever go above ~25%, thus the thing about "get GDDR5" isn't really true.

But, a GTX 660, having 960 shaders, 80 texture units, and 24 raster operations pipeline units, does make it sound like I could safely drop down to a GT 650 Ti (768, 64, 16) as long as Jinc is set up at 8 taps or thereabouts.

(You gentlemen will forgive me if I find a nigh-one-thousand page thread intimidating.)

sneaker_ger

15th July 2013, 21:32

madshi

15th July 2013, 21:50

But, a GTX 660, having 960 shaders, 80 texture units, and 24 raster operations pipeline units, does make it sound like I could safely drop down to a GT 650 Ti (768, 64, 16) as long as Jinc is set up at 8 taps or thereabouts.
I neither have the money nor the time to test multiple different GPUs to try to find out which technical aspects may limit the performance with madVR most. Anything I say will be a guess, and my guess might not be any better than yours.

(You gentlemen will forgive me if I find a nigh-one-thousand page thread intimidating.)
And you will hopefully forgive me that I don't want to discuss the same topic again and again every 10 pages...

What does the subtitle quality trade option do?
It's for the new subtitle interface (XySubFilter). Beta testing should start soon.

hmp_goose

15th July 2013, 22:17

And you will hopefully forgive me that I don't want to discuss the same topic again and again every 10 pages...
Done and done.

Thank you for you hard work on this wonderful product! http://i1222.photobucket.com/albums/dd484/hmp_goose/Too%20Many%20Smilies/wave.gif (http://s1222.photobucket.com/user/hmp_goose/media/Too%20Many%20Smilies/wave.gif.html)

cyberbeing

16th July 2013, 01:31

What does the subtitle quality trade option do?
When set to Performance, XySubFilter beta will always pass madVR TV range subtitles, potentially avoiding an extra shader pass and PC<->TV level conversion on the subtitles by madVR. Common YCbCr Matrix color corrections would be handled internally by XySubFilter prior to bitmap rasterization.

When set to Quality, XySubFilter beta will always pass madVR the native level range of the subtitles, which if PC range will potentially force an extra shader pass and PC<->TV level conversion on the subtitles by madVR. All YCbCr Matrix color corrections are handled by madVR on rasterized bitmaps.

Last time I tested this, the difference in colors between the two was less than 0.1%, but setting to Quality on lower powered GPUs like my GT440 DDR5 increased absolute GPU load by ~10%. There are a few if/and/buts here though. If you use MPC-HC shaders, madVR Color & Gamma controls, or are using a 3DLUT which doesn't match the gamut of your video, an extra shader pass would get forced anyway and cause the GPU load difference to shrink quite a bit.

dansrfe

16th July 2013, 05:51

How can I check if the monitor is internally repeating frames when set to 48Hz?

ryrynz

16th July 2013, 05:57

XySubFilter beta

Any ETA on it? Hopefully somebody will post here when the beta is released.

sneaker_ger

16th July 2013, 07:13

It's for the new subtitle interface (XySubFilter). Beta testing should start soon.

When set to Performance, XySubFilter beta will always pass madVR TV range subtitles, potentially avoiding an extra shader pass and PC<->TV level conversion on the subtitles by madVR. Common YCbCr Matrix color corrections would be handled internally by XySubFilter prior to bitmap rasterization.

When set to Quality, XySubFilter beta will always pass madVR the native level range of the subtitles, which if PC range will potentially force an extra shader pass and PC<->TV level conversion on the subtitles by madVR. All YCbCr Matrix color corrections are handled by madVR on rasterized bitmaps.

Last time I tested this, the difference in colors between the two was less than 0.1%, but setting to Quality on lower powered GPUs like my GT440 DDR5 increased absolute GPU load by ~10%. There are a few if/and/buts here though. If you use MPC-HC shaders, madVR Color & Gamma controls, or are using a 3DLUT which doesn't match the gamut of your video, an extra shader pass would get forced anyway and cause the GPU load difference to shrink quite a bit.

Thx. 10% GPU load does indeed seem an awful lot for that return.

madshi

16th July 2013, 07:45

How can I check if the monitor is internally repeating frames when set to 48Hz?
By running the madVR smooth motion test patterns. There's no test pattern for 48Hz, but the 24Hz test pattern should do fine.

Thx. 10% GPU load does indeed seem an awful lot for that return.
It's 10% with a rather slow GPU. Much less with a reasonably fast GPU. From my point of view, choosing the higher quality subtitle option might help avoiding banding artifacts if you have subtitles which contain a smooth gradiant. Or smoother motion if you have subtitles which smoothly blend from one color to another. In these cases letting madVR do the work means less rounding errors, because XySubFilter does all this in 8bit without dithering. In most cases you would probably never notice the difference, though, because of which I've enabled this "trade quality" option by default. Also I'm just talking theory here, haven't done any related tests yet...

ryrynz

16th July 2013, 07:53

Thx. 10% GPU load does indeed seem an awful lot for that return.

Did you notice the content and output resolution he was viewing for it to achieve that load? General load increase is negligible for most content hence why Madshi enabled it by default.
You just picked one result and used it as a blanket statement.

*edit* Thought it was regarding the Smoothmotion linear light setting, NVM.

cyberbeing

16th July 2013, 08:45

Did you notice the content and output resolution he was viewing for it to achieve that load? General load increase is negligible for most content hence why Madshi enabled it by default.
You just picked one result and used it as a blanket statement.
I surely didn't notice, since I've never stated my test conditions. :confused:

In any case, it's the opposite of what you've stated. My test was very common 1280x720 23.976fps video to 1920x1080 with 3DLUT enabled, and Smooth Motion FRC disabled. This constitutes the majority of my viewing with subtitles. Even watching 1280x720 23.976fps without any scaling at all, results in a non-insignificant increase in GPU load with the Trade Quality for Performance option for XySubFilter disabled on my GT440 DDR5 OC.

As madshi stated, with faster mid-range and higher GPUs, I'd expect this difference in GPU load to quickly turn non-existent. My GT440 DDR5 for whatever reason has a high overhead from any extra PC<->TV level range conversion shader passes madVR needs to perform with the Quality option. In any case, the trade quality for performance option for XySubFilter currently seems to be enabled by default in madVR 0.86.9 (subject to change).

From my point of view, choosing the higher quality subtitle option might help avoiding banding artifacts if you have subtitles which contain a smooth gradiant. Or smoother motion if you have subtitles which smoothly blend from one color to another.
For various reasons, I'd actually expect the opposite to usually be true, at least for ASS subtitles rendered by XySubFilter.

madshi

16th July 2013, 08:57

For various reasons, I'd actually expect the opposite to usually be true, at least for ASS subtitles rendered by XySubFilter.
Which reasons?

ryrynz

16th July 2013, 09:10

I surely didn't notice, since I've never stated my test conditions. :confused:

Increases GPU load by ~10% if I upscale from 1280x720 23.976fps to 2048x1152 @85Hz.

I don't think most would upscale beyond 1920x1080 not that there's a great difference here, but doesn't the refresh rate play a part also?

I don't think many people at all are upscaling to beyond 1920x1080 or running 60fps content or displays higher than 60hz either
so that 10% GPU usage really is in the more extreme situations.

It is indeed

So are you now disagreeing?

In any case, it's the opposite of what you've stated.

Not really, because different GPUs will take different hits as Madshi said.

Enabling Linear light with smooth motion for me on 1280 x 720 content upscaled to 1920 x 1200 looks to burden my Intel HD 3000 with 1-2% extra GPU useage although it's debateable if it's even that much.

cyberbeing

16th July 2013, 09:19

ryrynz, why are you quoting an old post about Smooth Motion FRC from last week :confused:

I am talking about the brand-new Trade Quality for Performance option added for XySubFilter in madVR 0.86.9, which didn't exist at all until yesterday.

Which reasons?

Effective Bitdepth VS Level Range reasons.

madshi

16th July 2013, 09:49

Effective Bitdepth VS Level Range reasons.
I don't understand. ASS colors are stored in fullrange RGB colors, correct? If XySubFilter performs color correction and then levels conversion on the subtitles, outputting color corrected TV levels RGB in 8bit, obviously XySubFilter will have to *round* its floating point results down to 8bit, and to my best knowledge it currently does so without dithering. madVR does all the same processing steps as XySubFilter, but in higher bitdepth. So why do you think that XySubFilter doing all the processing would result in higher image quality? Makes no sense to me...

andybkma

16th July 2013, 11:21

Greets madshi, just a quick question. Are you possibly planning to allow different FSE settings for different devices (monitors)? For example, I like to use FSE when using my Panasonic projector playing cinema. But when I am at my desk and using my Dell monitor I don't want FSE enabled. I see that under the "Device" settings each has its own display mode so I was just wondering if in the future you plan to instead of having a "global" FSE and Scaling Algorithm setting we could also make them device (monitor) specific.

Cheers and thanks for new version 86.9 and all you do :-)

madshi

16th July 2013, 11:25

At some point I do plan to offer profiles and what not, which should also allow to use different settings for different GPUs or displays. But that feature is still some time away, and right now I don't want to move too many options into the device setup.

cyberbeing

16th July 2013, 11:26

madshi

16th July 2013, 11:48

madVR's result would be more accurate to the source, but wouldn't that mean that banding from a low bitdepth gradient in the source bitmaps would be preserved?

My theory is that the compressing a low bitdepth gradient to TV range in combination with upscaling, may occasionally increase the subjective quality of a gradient by reducing the distance between colors, even though its no longer as true to the source.
I'm not sure I can follow. Whether we let XySubFilter or madVR convert the levels and colors doesn't have any impact on whether gradients are compressed or not. E.g. if you have a subtitle with a black-to-white gradiant, both XySubFilter and madVR will produce a rather similar looking gradiant, but XySubFilter's output will be rounded for every gradiant step, while madVR's output will be dithered for every step. That doesn't mean the gradiant gets compressed or expanded. Every step of the gradiant will be nearly the same between madVR and XySubFilter, with just a value difference of 0-2. The only question is whether the steps are smoother with rounding or with dithering. No compression or expansion is going on in either case, as far as I can see...

cyberbeing

16th July 2013, 12:47

The only question is whether the steps are smoother with rounding or with dithering.
That sounds sensible enough. How expensive is performing error diffusion dithering via CPU? Is that something we should look into supporting for TV range output?

ryrynz

16th July 2013, 13:11

ryrynz, why are you quoting an old post about Smooth Motion FRC from last week :confused:

Oh right, different option, duh.. NVM, carry on.

nevcairiel

16th July 2013, 13:12

That sounds sensible enough. How expensive is performing error diffusion dithering via CPU? Is that something we should look into supporting for TV range output?

Error Diffusion is quite expensive because its hard to SIMD, simple random/TPDF dithering like madVR or LAV use is simple and easy to SIMD, though.

madshi

16th July 2013, 13:39

That sounds sensible enough. How expensive is performing error diffusion dithering via CPU? Is that something we should look into supporting for TV range output?
FWIW, if you do add support for that, you might want to enable it for PC range output, too, if you do color correction, because after color correction you'll have floating point values, too.

But generally, I'm not sure if you should invest the work for this, though. madVR can do the processing in high quality, so XySubFilter doesn't really need to be able to apply dithering, IMHO. At least I would put it very very low on your priority list.

Error Diffusion is quite expensive because its hard to SIMD, simple random/TPDF dithering like madVR or LAV use is simple and easy to SIMD, though.
Agreed.

Pat357

16th July 2013, 15:06

That sounds sensible enough. How expensive is performing error diffusion dithering via CPU? Is that something we should look into supporting for TV range output?

Just FYI : LAV-video uses dithering via CPU; maybe you can relative easy take it from LAV sources.
It offers 2 variations : ordered or random. IIRC, random dithering uses more resources than ordered dithering.
In the current versions, you can't just disable the dithering to quickly test the influence on CPU utilization.

On my i7 CPU's (i7-970 and i7-4770) I didn't noticed any difference between before and after Nev implemented this.
Probably he did a good optimization of his code. :)

Take in mind that a full Floyd Steinberg Error Diffusion is much heavier on CPU than what LAV currently does : FSED is not worth it IMHO for subs.

madshi

16th July 2013, 15:12

On my i7 CPU's (i7-970 and i7-4770) I didn't noticed any difference between before and after Nev implemented this.
Probably he did a good optimization of his code. :)
It's not as simple as that, though. nev always had to implement some sort of 10bit -> 8bit conversion, for video renderers which don't support 10bit. Adding dithering on top of the conversion doesn't slow things down too much. Basically nev could just replace the simple 10->8bit conversion routine with an extended version which also dithers. However, XySubFilter internally works in 8bit. If you wanted to implement dithering in XySubFilter, you can't simply replace one conversion routine with a different one. I suspect there'd be changes needed in the depth of the XySubFilter rendering code, which could be quite complex/difficult to do. Furthermore in order to use dithering, first of all you need to process some things in a higher bitdepth. So XySubFilter would have to change at least some part of the code from 8bit to a higher bitdepth. And such changes could very well affect performance quite noticeably.

dansrfe

16th July 2013, 15:12

I tried the test patterns and all of them, including the smoothmotion ones, show a frame rate of 23.976. How can I correct this? Also, in the smoothmotion tests, what exactly am I looking for to confirm that the monitor isn't repeating frames?

madshi

16th July 2013, 15:18

There are various smooth motion test patterns, one each for 23.976, 24.000, 25.000, 59.940 and 60.000 fps. What you should be looking for is whether motion is smooth. Your eyes are the best meter for detecting smoothness. There doesn't exist any other meter I'm aware of that can measure that. So simply compare and then trust your eyes.

Pat357

16th July 2013, 15:19

Error Diffusion is quite expensive because its hard to SIMD, simple random/TPDF dithering like madVR or LAV use is simple and easy to SIMD, though.

TPDF dithering = ?

nevcairiel

16th July 2013, 15:23

nev always had to implement some sort of 10bit -> 8bit conversion, for video renderers which don't support 10bit.

madshi is right, dithering in this case was basically just one additional operation (an addition), and since all these conversions are already SSE2 in LAV, the overhead is very very small (which is why there also is no option to turn it off)
Random and ordered should have similar performance, since only the source of the dithering coefficients is different, not the actual dithering.

dansrfe

16th July 2013, 15:29

clsid

16th July 2013, 15:36

I think you guys should be really conservative with attempting to achieve perfect colors for subtitles. For the most common formats (SRT/VobSub/PGS) there is no need for *perfect* color correctness, since miniscule differences will not be noticeable. So any feature that brings just a minimal theoretical quality benefit should be disabled by default unless it has almost zero performance cost. Performance is better spend on things that have greater quality impact.
XySubFilter could also probably be made smart enough to detect situations where it might matter. So mainly SSA/ASS with for example gradients and effects that are meant to blend with the background video.

madshi

16th July 2013, 15:50

TPDF dithering = ?
TPDF dithering (http://lmgtfy.com/?q=TPDF+dithering) :p

The problem I'm having atm though is that all of the test patterns show a frame rate of 23.976 in madVR's OSD.
Doesn't happen for me.

I think you guys should be really conservative with attempting to achieve perfect colors for subtitles. For the most common formats (SRT/VobSub/PGS) there is no need for *perfect* color correctness, since miniscule differences will not be noticeable. So any feature that brings just a minimal theoretical quality benefit should be disabled by default unless it has almost zero performance cost. Performance is better spend on things that have greater quality impact.
Agreed. That's why the default behaviour of madVR + XySubFilter is to go for max subtitle performance. Users have the option to alternatively go for max subtitle quality if they so desire, by changing the madVR "trade quality for performance settings".

dansrfe

16th July 2013, 16:01

nvm, I was using the SmoothMotion test files with the madTestPatternSource included in the madVR folder that I had previously registered to for checking the colors and grayramp. Once I registered the version included in the separate madTestPatternSource zip it worked.

EDIT: so if the black bars on the bottom are noticeably flickering them I should conclude that the monitor is repeating frames, correct? The monitor's native frame rate is 59.94Hz.

@24fps, 48Hz, FRC off -> black bars flicker minimally
@24fps, 59.94Hz, FRC on -> black bars flicker more

@25fps, 50Hz, FRC off -> black bars flicker minimally
@25fps, 59.94Hz, FRC on -> black bars flicker more

@50fps, 50Hz, FRC off -> black bars barely flicker, images smooth
@50fps, 59.94Hz, FRC on -> black bars + images flicker noticeably more

@59.94fps, FRC off -> black bars don't flicker

kokotas

16th July 2013, 16:59

It's not that big an issue but I wonder if potplayer's consecutive capture feature will ever work with madvr?

madshi

16th July 2013, 17:19

EDIT: so if the black bars on the bottom are noticeably flickering them I should conclude that the monitor is repeating frames, correct?
NO. Where did I say anything about flickering? Here's what I told you a couple posts earlier:

> What you should be looking for is whether motion
> is smooth. Your eyes are the best meter for
> detecting smoothness. There doesn't exist any
> other meter I'm aware of that can measure that.
> So simply compare and then trust your eyes.

It's not that big an issue but I wonder if potplayer's consecutive capture feature will ever work with madvr?
I don't even know what that feature is or does. You'd have to ask the PotPlayer developer about it.

kokotas

16th July 2013, 17:56

I don't even know what that feature is or does. You'd have to ask the PotPlayer developer about it.

Oh, it's a feature which lets you capture the video consecutively (by frames or ms). Haali renderer works fine but madvr refuses to capture. But it's alright madhsi, thanks for answering.

dansrfe

16th July 2013, 18:20

@madshi

After staring at the test patterns on both of my identical monitors long enough (primary at 59.94Hz, FRC on) and (secondary at 50Hz, FRC off) with the 25fps test pattern I can see a "smoothness" difference. Looks like the monitor is doing repeating frames since the the primary with FRC on is smoother.

madshi

16th July 2013, 18:50

Oh, it's a feature which lets you capture the video consecutively (by frames or ms). Haali renderer works fine but madvr refuses to capture.
But Fraps works with madVR. So I'm not sure why PotPlayer's feature doesn't. Anyway, the PotPlayer dev is the one you need to talk to. If he needs my help, he can always contact me.

After staring at the test patterns on both of my identical monitors long enough (primary at 59.94Hz, FRC on) and (secondary at 50Hz, FRC off) with the 25fps test pattern I can see a "smoothness" difference. Looks like the monitor is doing repeating frames since the the primary with FRC on is smoother.
That sounds like a legit test. Now you could also test 23.976fps and 24.000fps.

Moragg

16th July 2013, 19:50

Okay, stupid question:

how do I use xy-subfilter instead of xy-vsfilter? I can't see the option anywhere.

sneaker_ger

16th July 2013, 20:42

It's a separate package that's not included in xy-vsfilter. There have been some (not up-to-date) compiles (https://www.dropbox.com/s/kzxrzz49nhop0n4/xySubFilter_TEST_v3.0.0.470-260613.7z) floating around. Basically you only have to register the dll using regsvr32 (in an cmd with admin rights). A public (not outdated) beta will probably be released soon, so you might want to wait a bit although I have to say it seems to be working quite well already.

If more XySubFilter questions come up they might be better suited in a separate thread, because they are off-topic in here as long as they aren't directly related to the madVR subtitle interface.

Moragg

16th July 2013, 21:20

Thanks, I was just confused as there's been a fair bit of discussion on it and an option for has been added in madvr so thought I was missing something obvious.

I'll wait for the public beta, and I only posted here as it's the only place where I've seen xy-subfilter mentioned on the interwebs.

wanezhiling

17th July 2013, 09:49

It's not that big an issue but I wonder if potplayer's consecutive capture feature will ever work with madvr?
I reported to PotPlayer devs, they fixed in today's 38814 version.

Changelog:
- 특정 상황에서 madVR 사용시 캡처가 않되던 문제 수정
- Fixed that capture function doesn't work with madVR under certain situations

:)

kokotas

17th July 2013, 11:20

Thanks wanezhiling :D It works as intended now.

xabregas

17th July 2013, 14:45

Hi!

Before i start let me just say how awesome is madvr!! :)

That said i was using an old version of madvr in windows 7 without Smooth Motion and finally after needed to install new OS (windows 8 x64 now) due to HDD overheating, i give it a go and tested it several times with both 23,976 and 25 fps material and i must say smooth motion is awesome in action scenes,now i can see what happens in many fight scenes, but i was watching ugly flickering and ghosting in moving objects like faces and people moving.

So i got panic and blamed CCC (I have HD7770 btw), so unninstalled CCC crap and installed WDM drivers only, but the flickering and ghosting wasnt solved. However i noticed better colors and less ringing :sly:

Then i went here and found this thread with some people having the same problem. So i did what madshi said in the thread (uncheck first option of trading quality for performance) and guess what, flickering disappeared. Now i just spot from time to time some minor ghosting in slow movement scenes like face movement when talking, nothing harmfull.

Now my problem is i have 60HZ screen with no 24p option and i have 23,976 and 25 FPS material. Do i need to use reclock pal speed down when watching 25 FPS with madvr smooth motion on??

I tested both and it gave me flickering with reclock and without reclock minor ghosting, but more than i have with 23,976 material :(

TIA

huhn

17th July 2013, 16:57

use smooth motion when you play 23p or 25p on an display with 60 hz.

smooth motion looks better when the display is set to the highest possible refresh rate.

when using smooth motion is used on 23 p displays with 23p material it stops frame drop/repeats but makes the picture a little bit more unsharp.

just read this:

http://forum.doom9.org/showthread.php?p=1616520#post1616520