madVR - high quality video renderer (GPU assisted)

[HitomiKun]

Every video file I open right now causes madVR to crash. I have sent a few reports through the bug reporting screen that comes up every time madVR crashes. I am using a mpc-hc fork from JanWillem32 (http://forum.doom9.org/showthread.php?t=161047), the latest mpc-hc x86 build with SSE2 instruction set. See his development folder for the builds:
http://www.mediafire.com/?xwsoo403c53hv

Other than that, I use the latest versions of madFlac + LAV Filters + AC3 Filter to play my videos. I used to have Haali on the list, but LAV Filters got Ordered Chapters support for MKV files, so I dropped Haali and uninstalled it.

Setup looks like this:
http://puu.sh/2zgrD
all set to "prefer"

This is why I'm using JanWillem32's builds:
http://puu.sh/2zgsK

I recently switched to Windows 8 Pro 64 bit and just installed my good old madVR setup for mpc-hc and it didn't work as I started the first file. (This means I haven't got the chance to do settings for madVR, since I always started a video file to access madVR settings)

[madshi]

Well there's surely room for improvement, considering almost all of my 25p-inside-25i streams cause MadVR to activate deinterlacing - it's fortunate that my GPU handles this properly. I don't think I've ever seen MadVR activate IVTC automatically, unless I'm just misunderstanding the OSD.
What you're talking about here is:

(1) automatic detection when deinterlacing is needed
(2) film vs video mode detection

For (1) madVR simply uses the video stream flags at the moment, which is somewhat unreliable. For (2) there's no code in madVR at all yet. I plan to write new algorithms for (1) and (2) in the future to do everything automatically with hopefully near perfect reliability. Of course the new algorithms will eat additional CPU and/or GPU resources.

The ones in GPUs are rather limted, you can be lucky if it handles 3:2 properly, any other cadence will most like just not work - and not to mention that it doesn't decimate after the IVTC, so you can't get 24p out of a telecined 29.97 fps movie.
FWIW, at least my AMD GPU does detect some other cadences, too, but it's all not very reliable. E.g. it often uses video deinterlacing for PAL movie content etc...

The only thing missing is auto-detection, so i don't need to manually force it. :)
Exactly. Oh well, probably support for mixed video + film content will also need to be added which could be quite difficult. <sigh>

[madshi]

Every video file I open right now causes madVR to crash. I have sent a few reports through the bug reporting screen that comes up every time madVR crashes. I am using a mpc-hc fork from JanWillem32 (http://forum.doom9.org/showthread.php?t=161047), the latest mpc-hc x86 build with SSE2 instruction set.
Unfortunately you don't have the MPC-HC debug symbols (*.pdb) installed. Which means that the bug reports don't include information of what MPC-HC was doing exactly when the crash occurred. From what I can see the crash occurs inside of madVR always at the same place. But the place makes no sense at all. My first guess would be that MPC-HC damages something which results in madVR crashing. But that's nothing but a wild guess. Does the same problem also occur with normal MPC-HC or MPC-BE builds?

[HitomiKun]

using a normal build from
http://xhmikosr.1f0.de/mpc-hc/
does not crash.

[mark0077]

What you're talking about here is:

(1) automatic detection when deinterlacing is needed
(2) film vs video mode detection

For (1) madVR simply uses the video stream flags at the moment, which is somewhat unreliable. For (2) there's no code in madVR at all yet. I plan to write new algorithms for (1) and (2) in the future to do everything automatically with hopefully near perfect reliability. Of course the new algorithms will eat additional CPU and/or GPU resources.


madshi, quick question. Do you ever see it being possible or useful for parts of madVR like this detection algorithm to become their own product or filter, outside of a video renderer. I'm sure many like myself are very interested in some of these amazing improvements and algorithms but because I use filters like ffdshow / SVP between the decoder and renderer, I have to basically disable or not use any of these features, because the renderer is too late in the chain to do this detection / deinterlacing. If they were more modular I imagine being able to use them in whatever part of the chain would suit, like after decoding but before SVP for example? I'm just afraid that if they are all contained in one big place, ie madVR, that many of its features can't be used by others that use filters before the renderer.

[madshi]

using a normal build from
http://xhmikosr.1f0.de/mpc-hc/
does not crash.
Then I would guess that the crashing MPC-HC build is probably at fault.

madshi, quick question. Do you ever see it being possible or useful for parts of madVR like this detection algorithm to become their own product or filter, outside of a video renderer. I'm sure many like myself are very interested in some of these amazing improvements and algorithms but because I use filters like ffdshow / SVP between the decoder and renderer, I have to basically disable or not use any of these features, because the renderer is too late in the chain to do this detection / deinterlacing. If they were more modular I imagine being able to use them in whatever part of the chain would suit, like after decoding but before SVP for example? I'm just afraid that if they are all contained in one big place, ie madVR, that many of its features can't be used by others that use filters before the renderer.
Sorry, but in the long run I plan to run all those algorithms on the GPU, anyway (currently IVTC is still done on CPU, though), which means that there's no way other filters can be executed in between.

[daltonm]

For some reason, I am getting huge number of frame drops playing some trailers with smooth motion on (24fps->60). For example, this one

http://videos.hd-trailers.net/20130409_elysium_trailer1_4000.mp4

mediainfo tab


General
Complete name : S:\20130409_elysium_trailer1_4000(2).mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 63.0 MiB
Duration : 2mn 12s
Overall bit rate mode : Variable
Overall bit rate : 4 000 Kbps
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 12s
Bit rate mode : Constant
Bit rate : 3 936 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.079
Stream size : 62.0 MiB (98%)
Language : English
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2mn 12s
Bit rate mode : Variable
Bit rate : 61.6 Kbps
Maximum bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 994 KiB (2%)
Language : English
Encoded date : UTC 2013-04-09 15:15:49
Tagged date : UTC 2013-04-09 15:15:49
mdhd_Duration : 132168


Odd because my system can play much more demanding material, like bluray m2ts files, just fine with smooth motion on. I am using mpc-hc and lav splitter and lav decoder. Any idea? thanks

I have the same problem.
look
http://i.imgur.com/zixIBqG.jpg

edit
the problem does not happen with exclusive fullscreen mode.
edit2
fullscreen windowed mode with 4 backbuffer queue
Problem Solved.. LoL
http://i.imgur.com/We2Ptmi.jpg

[HitomiKun]

I'll try to compile JanWillem32's source code, though that'd take a few hours since I have to install visual studio and all that stuff. If you madshi have the right tools to compile his code I'd recommend you try it, would take less time and you'd experience it all by yourself:

his git: https://github.com/JanWillem32/mpc-hc

edit:
just read your post, if it isn't madVR then I'm sorry for the trouble ;) I'll try to use an older version from JanWillem32.

[dansrfe]

I use the ICL3 and either madVR or LAV crashes when I press Alt + F4 in exclusive or windowed mode sometimes. I'm not sure I can replicate the scenario at will but I may be able to get a crash report if I keep using the debug varsion of madVR for some time.

[hdboy]

Don't see frame drops here with my Intel HD4000 GPU. Which queues are near empty when those frame drops occur? Have you tried in fullscreen exclusive mode?

Ah, FSE fixes it. But for usability purpose, I like to avoid FSE if possible.

Sorry, how do I tell which queues are near empty?

Changing back buffer queue from 8 to 4 did not help. Reducing CPU and GPU queues all way down to 4 seems to reduce # of dropped frames, but not eliminate them. Increasing CPU and GPU queues to max causes more drooped frames.

[iSunrise]

No, actually, I stand by what I said. The calculator results are expressed in terms of absolute luminance, as well as BT.1886. However, madVR is unable to target some absolute luminance because it doesn't know what the luminance of 0% and 100% is. When you specify a pure power curve in madVR, it is applied in terms of pixel values, not luminance. So in the end, the output of madVR, after the pure power curve has been applied, is offset by the monitor's black level (madVR pixel value 0 = monitor black level). And when you offset a pure power curve with the monitor's black level, you get… a black-compensated power curve. QED.
...
The important thing here is that when configured in madVR a pure power law is applied to pixel values, but luminance ≠ pixel value. Instead, luminance = a*(pixel value)+b. The resulting luminance follows a black-compensated curve, even though the pixel values follow a pure power curve.
...
I totally agree, but considering very few calibration solutions support BT.1886 right now, most people won't have this ability. A good first step would be to have BT.1886 support in madVR, so that BT.1886 can be used even with a monitor using a different curve (e.g. black-compensated pure power law, sRGB function).


The question is how much work it would be for madshi to implement/adjust it to that. From my perspective, it would make the renderer a lot more bullet-proof, way more accurate and also, less confusing to setup and still adhere to what a renderer should do/should not need to do.

People that either want to calibrate or have already calibrated their monitors already have the values needed for madVR to work. madVR cetainly doesn´t need to offer another calibration solution, because it´s a renderer, but because of that it needs to be able to make use of the calibration results as best as possible for it to work correctly/accurately. Yes, I know that yCMS is supposed to do it, but I don´t like the workflow at all. I already have a calibration package that does it´s job, madVR should only offer something that actually has an added value rather than doing the same things again.

I for one would have had (or would have as I am still unsure of my results within madVR) an easier time if madVR allowed either sRGB or offer controls where I could input my calibration result´s 0% luminance (like 0.10cd/m²) and 100% luminance (80cd/m²) and use that as a base to let madVR calculate from.

I am right now completely unsure if my results are accurate. They certainly don´t look accurate. I suspect an error somewhere, but I`m not sure, where exactly and where to search.

If I am currently using the black bars/APL clipping test from AVS HD, I don´t have very good transitions between the lower and higher values within madVR (I gave the calibration package the LUT values to work with, which were measured with a Konica Minolta spectrophotometer at the factory to accurately correct the monitors ~2.20 native response to resemble an ideal 2.20 gamma curve), that is by using BT.709 and a 2.20 pure power curve in madVR like suggested. I have a rapid fall-off to black rather than a smooth transition. However, if I am calibrating to a Rec.709 profile with the LUT values I get a somehow brighter response in the darker areas and then going with a BT.709 curve in madVR and 2.20 gamma I am overwriting it with madVR´s gamma correction to a pure power curve between 2.20-2.60 and I suddenly have way better transitions in the 16 (reference black) and 25 values in that pattern, which I can also see in the films/content I watch. Everything just suddenly has a lot more depth to it. More shadow details that weren´t there before. Also, as an added bonus, because of the higher gamma, while I have more detail in the dark areas of the actual film, the black bars are WAY blacker then before. IPS panels have an edge-glow effect that reduce the visible contrast a bit. Even though I have a very good panel with extremely even brightness (max. deviation is like 1,5% in the corners) this offers a better experience in the end, because the corners are darker now.

I am not sure why that is. What makes this even more confusing is that outside of madVR (since I calibrated to 0-255 and not 16-235) I have perfect transitions within the dark values. I even decided to buy me a new i1 Display Pro to manually measure again, since it apparently offers more gamma precision than the DTP94B, but that should normally not be needed. But currently I don´t really have any explanation for the results I´m getting.

[therock003]

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?

[fairchild]

Can someone clear something up regarding MadVR and rendering times. When a movie is encoded at say 23.976 fps, and the display device has a refresh of 60hz, and the vsync interval is 16.67ms and the movie frame rate interval is 41.71ms....

What does my rendering times under the Average Stats need to be under? Should I maintain always under the vsync of 16.67ms or the movie frame rate of 41.71ms to not have any problems? Also should I ignore the max stats (5s) since this is usually very high for me.

I'm wondering because in order for me to get very low rendering times, I need to usually run DXVA-CB. If I run software decoding, my rendering times are usually much higher depending on the content.

[DragonQ]

Rendering time has to be below frame rate (quite a bit below ideally). Max stats can be ignored if you don't get frame drops/repeats once the video has "settled down" after a start/seek (after a second or so usually).

Obviously if you can render at ~25 ms then you're fine for 24p stuff but not for 25i/30i/50p/60p stuff.

[fairchild]

So below the frame rate interval correct? So in my example, as long as I'm below 41.71ms (this is the movie frame rate interval) then I'm fine? I don't think you meant if the movie is 24fps, then the rendering time has to be below 24ms?

Edit: thanks DragonQ, I checked some other sources and indeed the higher the file framerate (29.97, 30, etc) then the lower the movie frame rate interval is... So indeed as long as you are lower than the frame rate interval for a particular source, then you are fine. The lower the better.

[turbojet]

If composition is enabled (and it can't be disabled in win8) and if you're not using overlay or FSE, then there's no way to "ignore" composition. Direct3D is redirected to composition internally in the OS in that situation. No way around it, except by disabling composition, using overlay or FSE.

I can't find the thread anymore but on stackoverflow it sounded like composition could be disabled on a per window basis without affecting other windows but maybe it did affect other windows and that's even a windows 7 explorer option.

If EVR can handle this then it might be considered a madVR bug. So please create an entry in the bug tracker, with an attached log file and a detailed description how to reproduce it (how to setup dual monitor so that the issue occurs etc). I can't promise I'll look at this soon, though, because multi-monitor issues are really hard for me to debug cause my development PC doesn't have a dual monitor setup. Please also write into the bug tracker description whether the problem does not occur if you directly start a new media player instance on the target monitor. (Probably it will work fine then?)

Will do. It doesn't have a problem with a new player instance.

According to the log your monitor has no display modes listed to switch to. My best guess would be that the cru utility results in madVR detecting a new display. Check the device stuff in the madVR settings.

You are right, a new device according to madvr and setting a display mode changes correctly.

You'd have to ask Microsoft about that.

It's not technically called aero peek from microsoft but they refer to it as taskbar thumbnails. I wrote up a bug report at http://bugs.madshi.net/view.php?id=39
It appears that VLC, WMP, WMC use hardware overlays by default and the thumbnails work fine they also allow screenshots and multiple instances. Perhaps the problem is hardware overlays are single output and madvr is it in this case. Seems there are ways to split the output, see http://stackoverflow.com/questions/8164783/how-to-grab-video-frame-from-hardware-overlay-not-from-my-app

[Niyawa]

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?
Yes. x64 is not really in madshi priorities right now AFAIK. He already has a "to-do" list so if we're getting a x64 version, it won't be soon. I mean, madVR has been around for years and people don't even talk about x64 right? :p

[leeperry]

BTW, I did quite a few changes and the new rendering path would appear to work fine on my 8800GS/306.81/XPSP3 setup after all..I'll now upgrade to the latest WHQL's to be on the safe side.

I'm just extremely annoyed by how hiccupy 24p@24Hz looks on a 10ms(real world measured figure) LCD, when OTOH it looks butter-smooth on a 96Hz CRT(thanks to the sample/hold effect I'd guess?) or a 48Hz DLP(due to MDA's I presume?). I get to see the "naked" individual frames and that's not smooth.....IIRC the 24p cadence was chosen to be the bare minimum off a 48Hz analog projector, not a fairly responsive LCD :scared:

And sure, this Sammy TV has a 200Hz BFI but the darn thing seems to be living a life of its own and that would not appear to be a 24Hz multiple...I've read ppl complaining about that on their TOTL 800Hz TV's and apparently even their 200Hz models would suffer from the same issue.

Just to clear things up, as long as the "dropped/delayed frames" & "presentation glitches" counters remain null, are these the absolute warranty that my PC is outputting a dead-smooth video signal?

It's just that 24p judder tests tend to ever so slightly hiccup randomly apparently, and what you call a "presentation glitch" seems to occur rather often with the old rendering path.....I've only seen it once with the new one. I'm just not sure whether I'm seeing the regular 24p judder, my PC is not outputting spot-on jitter or my TV(even in low latency "game" mode) is playing tricks on me :mad:

There's a price to pay for responsive LCD's, my caveman 46" 48Hz CCFL Hitachi had a slow LCD panel and that nicely blurred 24p I think..

Yes.
OK, great! And will you also provide a way to set different scalers for SD & HD? The more I think about it, the more it seems videophool to me to splash out on a new graphic card just for 720p J3AR when it's actually the most needed for SD@1080p and that pretty much any graphic card can do that. It's just that constantly rolling scalers is a plain annoyance :o

I also presume that scaling using the CPU would be out of the question?

That should be possible, although it might be ever so slightly lower quality then if done right in the first place.
Alright, hopefully you'll manage to implement MPEG1 chroma placement soon enough coz I've got a bunch of 720*576 files I'd really like to see in their best possible shape :cool:

:thanks:

most CRTs don't behave properly when the brightness control is turned down that low. (so they don't measure 2.40 at every point and are crushing shadow detail)
Correcto Mundo!

This test pattern looks fine on my 2.4 calibrated flat screen LG F900P: http://thumbnails102.imagebam.com/24879/8b437a248789297.jpg (http://www.imagebam.com/image/8b437a248789297)

This one does not, as <8 levels are just crushed to death: http://thumbnails105.imagebam.com/24879/a70cec248789296.jpg (http://www.imagebam.com/image/a70cec248789296)

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.

[iSunrise]

This test pattern looks fine on my 2.4 calibrated flat screen LG F900P: http://thumbnails102.imagebam.com/24879/8b437a248789297.jpg (http://www.imagebam.com/image/8b437a248789297)

This one does not, as <8 levels are just crushed to death: http://thumbnails105.imagebam.com/24879/a70cec248789296.jpg (http://www.imagebam.com/image/a70cec248789296)

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.
Both look perfect on the Eizo when using the factory calibrated sRGB profile. Very smooth transitions. I can even distinguish the inner black frame from the 1% black bar in the 2nd picture. Let´s hope that madshi includes sRGB, too.

I know what you mean with black coats and it´s irritating me every time. I always think there´s something wrong.

I guess that the problem is that coats or other dark clothing behave somewhat strange, even when the surroundings are well lit. Some of them are made out of cloth that just doesn´t reflect much light at all and that looks extremely strange when a person moves. It´s like a hole in your screen that moves, because you cannot make out any details. It´s not only coats, though, in Aliens there are also various metal elements that stay almost black (dead) no matter what. It can of course also be related to really bad encodes where they´ve crushed all the blacks.

[Schwartz]

Yes. x64 is not really in madshi priorities right now AFAIK. He already has a "to-do" list so if we're getting a x64 version, it won't be soon. I mean, madVR has been around for years and people don't even talk about x64 right? :p

MadVR is so good that I'm fine with letting madshi do his thing however he wants. Good software is usually an effort of people doing exactly what they want to do.

But I'm also gonna throw my vote in for a x64 version. It may sound silly, but I don't like running software on an emulation layer by principle, even if it's an excellent one. Filters and resizers for example (used to use ffdshow) are much faster when you can use 64bit and all instruction sets.

[DragonQ]

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.

In my experience it's quite easy to beat the blacks of a CRT. All the CRTs I ever used had a "blooming" effect, like what you're describing. When the scene is brighter, blacks get lighter and shadow detail is reduced.

[ryrynz]

But I'm also gonna throw my vote in for a x64 version.

Not really any point in voting, it's going to happen.. just not anytime soon.

[Niyawa]

Filters and resizers for example (used to use ffdshow) are much faster when you can use 64bit and all instruction sets.
I'm not sure how an x64 version would improve performance in a noticeable way, but I do understand the thought of having your hardware running and using itself to it's full potential. As ryrynz mentioned though, we are going to get it just not soon.

I want to ask a question for those who knows about calibration and stuff. I'm using an LG Flatron E2260 that has some horrible colors when using the fabric calibration. The only preset that actually makes it more or less acceptable is sRGB (with white balance enabled). My question would be, is this sRGB the best option when available for all monitors or did it just happen to be the more optimal one here?

[e-t172]

Yes, assuming it really is calibrating to sRGB, it is the best setting. sRGB has the same primaries and white point as Rec. 709, which makes it very close to the ideal target for video. The only thing that's (slightly) different is the gamma. sRGB is the standard for computer monitors and in an ideal world all monitors would be calibrated that way from the start.

[leeperry]

BTW, what are the "present." average/max stats exactly? Jitter that should ideally be null? They don't reset when pressing CTRL+R so that doesn't really help if that's the case :o

[ikarad]

Can you explain why?


Other thing.
I install filter of madvrtestpattern but all smoothmotionxx.ytp file make mpc-hc crash if I use ffdshow raw filter.

Only smallramp.ytp, colors.ytp and greyramp.ytp work with ffdshow raw filter.
Can't find this in the bug tracker?

.
What bug tracker?

[QBhd]

BTW, what's the "present." average stat exactly? the average jitter that should ideally be null? It doesn't reset when pressing CTRL+R so that doesn't really help if that's the case :o

presentation times... it's the average time madVR takes to present each frame. this should be lower than the movie frame interval.

QB

[Qaq]

What bug tracker?
http://madVR.bugs.madshi.net

[leeperry]

presentation times... it's the average time madVR takes to present each frame. this should be lower than the movie frame interval.
ok, thanks for the info.......then a jitter figure would be amazing if technically doable :cool:

[madshi]

Ah, FSE fixes it. But for usability purpose, I like to avoid FSE if possible.
Have you tried Overlay mode? Maybe that helps...

Sorry, how do I tell which queues are near empty?
Display the debug OSD (Ctrl+J) and check which queues have which fill state. If you don't know what to look for, just make a screenshot in the moment when frame drops occur, with the OSD on.

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?
x64 support has been discussed before, please use search. I don't know if it will be months or years, but it'll not be soon.

It's not technically called aero peek from microsoft but they refer to it as taskbar thumbnails. I wrote up a bug report at http://bugs.madshi.net/view.php?id=39
It appears that VLC, WMP, WMC use hardware overlays by default and the thumbnails work fine they also allow screenshots and multiple instances. Perhaps the problem is hardware overlays are single output and madvr is it in this case. Seems there are ways to split the output, see http://stackoverflow.com/questions/8164783/how-to-grab-video-frame-from-hardware-overlay-not-from-my-app
On a quick check I don't see anything helpful in that stackoverflow thread. There are also different kinds of Overlay. In any case, if some OS features work with windowed mode, but not with overlay, then it's most probably not madVR's fault. Maybe it would be possible to make such features work by adding in extra code, but I'm not willing to do that at this point in time.

BTW, I did quite a few changes and the new rendering path would appear to work fine on my 8800GS/306.81/XPSP3 setup after all..I'll now upgrade to the latest WHQL's to be on the safe side.

I'm just extremely annoyed by how hiccupy 24p@24Hz looks on a 10ms(real world measured figure) LCD, when OTOH it looks butter-smooth on a 96Hz CRT(thanks to the sample/hold effect I'd guess?) or a 48Hz DLP(due to MDA's I presume?). I get to see the "naked" individual frames and that's not smooth.....IIRC the 24p cadence was chosen to be the bare minimum off a 48Hz analog projector, not a fairly responsive LCD :scared:

And sure, this Sammy TV has a 200Hz BFI but the darn thing seems to be living a life of its own and that would not appear to be a 24Hz multiple...I've read ppl complaining about that on their TOTL 800Hz TV's and apparently even their 200Hz models would suffer from the same issue.
The sample-and-hold effect just blurs the image, it doesn't result in judder. If your Sammy TV is not smooth at 24Hz, while your CRT/DLP is then I would say that your Sammy probably doesn't support a native 24Hz refresh rate. It might internally apply 3:2 pulldown to 60Hz, I don't know. Is 60fps content butter smooth, as on your CRT? If so, you could try switching madVR to 60Hz for your Sammy TV and activate smooth motion FRC. But make sure you use the new FSE path, and I'm not sure if XP can swing it...

Just to clear things up, as long as the "dropped/delayed frames" & "presentation glitches" counters remain null, are these the absolute warranty that my PC is outputting a dead-smooth video signal?
If there are also no repeated frames and if your refresh rate matches your movie framerate, then yes, that should usually mean that your GPU output should be smooth - unless there's a bug in the GPU driver/hardware.

It's just that 24p judder tests tend to ever so slightly hiccup randomly apparently
How often? Once every couple of seconds? Or all the time (micro-judder)?

OK, great! And will you also provide a way to set different scalers for SD & HD?
This has been asked and answered multiple times already.

[ikarad]

http://madVR.bugs.madshi.net

Thanks. I didn't know that madvr had a bugtracker. Is it new?

I add
http://bugs.madshi.net/view.php?id=41

[MokrySedeS]

It's dozen weeks young. (http://forum.doom9.org/showpost.php?p=1611968&postcount=17074)

[ikarad]

It's dozen weeks young. (http://forum.doom9.org/showpost.php?p=1611968&postcount=17074)

Thanks.

[leeperry]

The sample-and-hold effect just blurs the image, it doesn't result in judder. If your Sammy TV is not smooth at 24Hz, while your CRT/DLP is then I would say that your Sammy probably doesn't support a native 24Hz refresh rate. It might internally apply 3:2 pulldown to 60Hz, I don't know.
yep, my point is that S&H on CRT "naturally" blends frames and so more or less do MDA's on DLP, so 24p transitions aren't nearly as razor sharp as on a LCD. I've run more tests this afternoon and 25fps looks pretty fine in 24Hz but the motion blur of 23.976/24 movies goes haywire whatever the frame rate(24/25/29.97).....I often read that 24p was a no-go on LCD screens/projectors and I can relate :scared:

All I know is that the slow response time Hitachi 46" CCFL LCD TV I tried a few months ago appeared smooth in 48Hz(with mVR 0.84/296.10 drivers). I'll roll back to this software combination and see what happens. That OLED pro SONY monitor I mentioned a few weeks ago displays 24Hz@72Hz and 25Hz@75Hz, I'm not sure if that Hitachi TV could have somehow "blurred" frames more efficiently because it was fed 48Hz instead of 24Hz? And I presume that mVR's dithering is done on the actual frames so that shouldn't matter? Ah well :p

I also remember that I really enjoyed LSF on 48Hz DLP because it would sharpen up the motion-blur :)

I'm gonna roll drivers and see what happens.....basically I don't get any tearing and 24p doesn't appear to be internally converted by that Sammy TV, it's just that once in a while judder tests "hiccup"(for lack of a better word)...such as the video file attached to this message(remuxed to MKV with an audio file and with Reclock's judder test on top of it in 24Hz).

How often? Once every couple of seconds? Or all the time (micro-judder)?
Well once in a while(like every 30/60 secs), my judder tests in mVR tend to move ever so slightly too fast.....hence ruining smoothness. That's usually when they reach the far right side of the screen, and often when Reclock's VSYNC indicator(spying on what mVR does :sly:) isn't on the top of the screen either.

you could try switching madVR to 60Hz for your Sammy TV and activate smooth motion FRC. But make sure you use the new FSE path, and I'm not sure if XP can swing it...
Even with the new FSE path, I still cannot stand the ghosting that FRC induces.....for instance enable Reclock's judder test and you'll see the kind of ghost image I'm talking about. But I get your point and I'll stop nagging you with my caveman OS problems :D

If there are also no repeated frames and if your refresh rate matches your movie framerate, then yes, that should usually mean that your GPU output should be smooth - unless there's a bug in the GPU driver/hardware.
I don't mean to repeat myself but could you possibly add a jitter figure between the ideal presentation timecodes and the actual ones? This would look so l33t :cool:

This has been asked and answered multiple times already.
Yep, I vaguely remember your reply being that it was "planned" and that you would completely change the way the config panel is set....but I don't recall any <1.0 or >1.0 time frame being specified and I believe it to be a feature many people crave at this point :o

:thanks:

[Niyawa]

Yes, assuming it really is calibrating to sRGB, it is the best setting. sRGB has the same primaries and white point as Rec. 709, which makes it very close to the ideal target for video. The only thing that's (slightly) different is the gamma. sRGB is the standard for computer monitors and in an ideal world all monitors would be calibrated that way from the start.
I see, thanks.

[6233638]

The sample-and-hold effect just blurs the image, it doesn't result in judder. If your Sammy TV is not smooth at 24Hz, while your CRT/DLP is then I would say that your Sammy probably doesn't support a native 24Hz refresh rate. It might internally apply 3:2 pulldown to 60Hz, I don't know.That could very well be the case - a lot of the earlier 24p models, and cheaper models with 24p support accept a 24p input and then convert it to 60Hz internally.

sRGB is the standard for computer monitors and in an ideal world all monitors would be calibrated that way from the start.Very few monitors are calibrated to sRGB. The sRGB specification also defines a fixed white point and black level that results in a very low contrast image.

Typically the sRGB primaries (which are the same as the BT.709 primaries) are used with a 2.2 power curve gamma.

In my experience it's quite easy to beat the blacks of a CRT. All the CRTs I ever used had a "blooming" effect, like what you're describing. When the scene is brighter, blacks get lighter and shadow detail is reduced.CRTs can put out an extremely high contrast image. Set correctly a good CRT will have about 10,000:1 on-off contrast (dynamic range) and if you use an external LUT device to avoid crushing shadow details, you can go significantly higher than that - you can set it up so the tube actually turns off with black.
But CRT has a very low ANSI contrast ratio - about 150:1 with the best models, and 100:1 or less with typical models. This is a result of the "blooming" that you describe.

This is why it has always surprised me that people that like CRTs wouldn't give Full Array LED backlit sets a chance. While they also exhibit blooming, it is much more contained (on sets with 100-300 zones) and the zones can be turned off completely, or to an extremely low level (>80,000:1) without crushing shadow detail or requiring external LUT trickery (depends on the implementation, but Sony's is good) and they have in excess of 10,000:1 ANSI in most cases - some sets, in excess of 15,000:1. So they have both higher on-off contrast (dynamic range) and orders of magnitude higher ANSI contrast. The end result is actually a very CRT-like image on my HX900.

Traditional LCDs have essentially a fixed contrast ratio. The best sets have a contrast of about 3,000-4,000:1, but this is for both on-off and ANSI contrast.
There are other dimming techniques for these LCDs (including "local dimming" with 8-32 zones for edge LED sets) but these are ineffective in my opinion.

Plasmas usually have very little difference between their on-off contrast and their ANSI contrast values. The latest Panasonics are around 20,000:1 on-off when calibrated, and 12,500:1 ANSI. This is very good performance, but because the on-off contrast is 20,000:1 the set never truly looks black in a dark room. (Kuros were around 30,000 on-off & 15,000 ANSI)

I would much rather take the "infinite" dynamic range of a local dimming LCD and high ANSI vs the lower dynamic range and potentially slightly higher ANSI contrast of a Plasma display. (but they have a number of other issues too)

Fortunately OLED is on the way (it should be here in about two or three year, realistically) which should combine both extremely high dynamic range with extremely high ANSI contrast.

But this discussion doesn't really belong in the madVR topic.

[madshi]

yep, my point is that S&H on CRT "naturally" blends frames and so more or less do MDA's on DLP, so 24p transitions aren't nearly as razor sharp as on a LCD.
Oh man, you've got everything pretty much backwards. CRTs do not have S&H, but LCDs have (unless they have a scanning backlight). CRTs should be razor sharp during motion, not LCDs. LCDs are those which blur the most, unless they have a scanning backlight or you activate DFI/BFI or motion interpolation.

I've run more tests this afternoon and 25fps looks pretty fine in 24Hz but the motion blur of 23.976/24 movies goes haywire whatever the frame rate(24/25/29.97).....I often read that 24p was a no-go on LCD screens/projectors and I can relate :scared:
I've no idea what you're talking about. 24p works just fine with most LCD projectors.

Well once in a while(like every 30/60 secs), my judder tests in mVR tend to move ever so slightly too fast.....hence ruining smoothness. That's usually when they reach the far right side of the screen, and often when Reclock's VSYNC indicator(spying on what mVR does :sly:) isn't on the top of the screen either.
Well, maybe your Samsung TV requires the GPU output to be exactly 24.000/1.001Hz and runs into problems if its not. I don't know. Just a wild guess. Could be something totally different.

I don't mean to repeat myself but could you possibly add a jitter figure between the ideal presentation timecodes and the actual ones?
Did you miss when I said that I wouldn't accept new feature requests, anymore?

Yep, I vaguely remember [...]
Then why don't you use search. I'm really tired of discussing feature requests, or replying to questions about what is on my to do list and what isn't.

[renethx]

What's up with 1440x1080 HDTV files like this (https://hotfile.com/dl/185596632/ddef693/ayaka_MSSL12.ts.html)? With Jinc3+AR image upscaling algorithm (and Bicubic75+AR chroma upscaling), the rendering time is

- 1440x1080 --> 1920x1080: ~17.3ms
- 1440x1080 --> 1918x1079 (or any similar resolution such as 1900x1069 [1% zoom out]): ~10.4ms

I haven't seen such a drastic reduction of the rendering time by a slight change of resolution with any other file. A10-5800K+DDR3-2400+1080MHz iGPU.

[e-t172]

Oh man, you've got everything pretty much backwards. CRTs do not have S&H, but LCDs have (unless they have a scanning backlight). CRTs should be razor sharp during motion, not LCDs. LCDs are those which blur the most, unless they have a scanning backlight or you activate DFI/BFI or motion interpolation.

By the way, due to the way LCDs work (they don't flicker like CRTs or film projectors do) and the way our eyes work (persistence of vision), shouldn't madVR smooth motion on 24p/60Hz brings LCDs closer to CRTs in terms of smoothness than native refresh rate (24p/24Hz or multiple) and no smooth motion? In other words, because the blended frames generated by madVR look close to the frames our brains "invent" between refreshes when looking at a CRT, I would expect smooth motion on a 60 Hz LCD to give superior results than native refresh rate on the same LCD. Does that makes sense?

You said that when given the choice between smooth motion and native refresh rate, one should choose native refresh rate. I wouldn't be so sure about that.

Did you miss when I said that I wouldn't accept new feature requests, anymore?

Maybe a good idea would be for us to put feature requests in the bug tracker, so that they can just sit there for some (possibly long) amount of time until you decide to consider them?

[dukey]

back in the good old days, LCDs had insane motion blur, so much so you had mouse 'trails' :)

[turbojet]

On a quick check I don't see anything helpful in that stackoverflow thread. There are also different kinds of Overlay. In any case, if some OS features work with windowed mode, but not with overlay, then it's most probably not madVR's fault. Maybe it would be possible to make such features work by adding in extra code, but I'm not willing to do that at this point in time.


I think the OS is displaying what it is given, in this case, an icon. I think the real problem is hardware overlay can onl output to one thing, that being madvr currently. If instead it connected to infinite pin tee it could output to madvr and other things. As for multiple hardware overlays, if that is another limitation a workaround could be switch to windowed mode when another madvr process is found. Overlay comes with one huge advantage, it can display all frames even when the gpu is pushed to 90%. In window mode, at 60% not all frames get displayed for me, even if madvr says no drops/delays.

By the way, due to the way LCDs work (they don't flicker like CRTs or film projectors do) and the way our eyes work (persistence of vision), shouldn't madVR smooth motion on 24p/60Hz brings LCDs closer to CRTs in terms of smoothness than native refresh rate (24p/24Hz or multiple) and no smooth motion? In other words, because the blended frames generated by madVR look close to the frames our brains "invent" between refreshes when looking at a CRT, I would expect smooth motion on a 60 Hz LCD to give superior results than native refresh rate on the same LCD. Does that makes sense?

You said that when given the choice between smooth motion and native refresh rate, one should choose native refresh rate. I wouldn't be so sure about that.


All sorts of ghosting on my lcd with frc. Could be my older TN panel but 48/50/60 works great.

[iSunrise]

Very few monitors are calibrated to sRGB. The sRGB specification also defines a fixed white point and black level that results in a very low contrast image.

Typically the sRGB primaries (which are the same as the BT.709 primaries) are used with a 2.2 power curve gamma.
madVR is a PC application for Windows-based systems (right now). sRGB is a standard used for monitors, printers, and the Internet. Almost any manufacturer and certainly ones that offer higher-end monitors offer an sRGB mode. Dell, NEC, Eizo, etc. all offer sRGB modes that are either factory calibrated to sRGB already or at least offer an sRGB mode that is close. It is simply not relevant if "very few" broadcast monitors are calibrated to sRGB, since madVR is not running on broadcast monitors. It´s the largest base to target for an application like madVR, because it´s a PC application. That´s all e-t172 is trying to say and he is right.

What would our PC monitors be good for if they didn´t adhere to sRGB as close as possible. Why would I invest money if they didn´t offer me a close resemblance of standards. Certainly not because of their 850:1 contrast, which pales in comparison to dedicated TVs or insanely expensive (broadcast) monitors.

I agree that sRGB is certainly not a typical target for film or video use, but that´s not the point.

PS: I bought an iPad 3 simply because of the reason that Apple factory calibrated the first batch of iPad 3 devices to sRGB and they are almost perfectly (http://www.displaymate.com/iPad_ShootOut_1.htm) matching it (a bit too blue, ~7.000 Kelvin).

You said that when given the choice between smooth motion and native refresh rate, one should choose native refresh rate. I wouldn't be so sure about that.
I was also confused by that a bit. I also asked if there´s any reason to go for a multiple if you also had the choice of native refresh rates that don´t flicker or judder, but unfortunately I didn´t get any answers to that. I guess that madshi meant to say that "in it´s currently implementated form, smooth motion should only be considered if you don´t have a native refresh rate available". I would say that smooth motion works really well, though. There´s scenes that look simply incredible with it. It´s a shame that on very sharp content (like PC encodes) it looks awful, because there´s a mixture of sharp/unsharp frames that are mixed together.

[leeperry]

Oh man, you've got everything pretty much backwards. CRTs do not have S&H, but LCDs have (unless they have a scanning backlight). CRTs should be razor sharp during motion, not LCDs. LCDs are those which blur the most, unless they have a scanning backlight or you activate DFI/BFI or motion interpolation.
Well, if I move the mouse cursor very quickly on a 100Hz CRT, I can see a dozen of them simultaneously...this is NOT what I call "razor sharp" and that's the "natural" blending I see on 24p@96Hz.

But you are entirely right that I've got 200Hz BFI enabled on that Sammy TV and that tends to gives a very sharp picture that's as unforgiving as it gets.

I've no idea what you're talking about. 24p works just fine with most LCD projectors.
Well, I assumed that this was old news: http://www.projectorcentral.com/judder_24p.htm
we've never seen 24 fps film quite this naked even in a commercial movie theater since the double shuttering action of the movie theater's projection system reduces the experience of judder and flicker. You can see some judder in the movie theater, but it is not as pronounced as it is on a digital home theater projector
Analog projectors work at double shutter speed(48Hz), and yes "naked" 24fps is quite unbearable...especially when it comes with that nasty motion blur.

Well, maybe your Samsung TV requires the GPU output to be exactly 24.000/1.001Hz and runs into problems if its not. I don't know. Just a wild guess. Could be something totally different.
Oh you nail it! I'll RTFM, maybe they'll specify some "perfect world" timings :thanks:

Did you miss when I said that I wouldn't accept new feature requests, anymore?
Well, you said that the exception makes the rule so ya never know....and jitter is all the rage in the audiophile world so a J figure in mVR would be amazing someday :cool:

Then why don't you use search. I'm really tired of discussing feature requests, or replying to questions about what is on my to do list and what isn't.
yah when it's done, I get it :D


All sorts of ghosting on my lcd with frc. Could be my older TN panel but 48/50/60 works great.
I tried FRC on CRT/TN/S-PVA and it always ended up in a ghost images feast.

I'm using an LG Flatron E2260 that has some horrible colors when using the fabric calibration. The only preset that actually makes it more or less acceptable is sRGB
sRGB=REC.709 (http://www.homecinema-fr.com/forum/ressources/image/54227), set mVR for gamut mapping to REC.709 et voilà ))

[e-t172]

All sorts of ghosting on my lcd with frc. Could be my older TN panel but 48/50/60 works great.

Well, I get the opposite experience on my brand new Dell U3014 (H-IPS panel). I just tested it, and it confirms what I was suspecting in my previous post: smooth motion 24p@60Hz actually looks much smoother than 24p@24Hz. Maybe my monitor does not support "real" 24p but I don't think so judging from the result of some motion pattern tests. I think I'll be watching everything using smooth motion @60Hz from now on, instead of switching to 24Hz.

Regarding ghosting: maybe that's caused by the LCD pixel response time, which would be more visible when the image changes 60 times per second instead of 24. I'm not sure.

madVR is a PC application for Windows-based systems (right now). sRGB is a standard used for monitors, printers, and the Internet. Almost any manufacturer and certainly ones that offer higher-end monitors offer an sRGB mode. Dell, NEC, Eizo, etc. all offer sRGB modes that are either factory calibrated to sRGB already or at least offer an sRGB mode that is close. It is simply not relevant if "very few" broadcast monitors are calibrated to sRGB, since madVR is not running on broadcast monitors. It´s the largest base to target for an application like madVR, because it´s a PC application. That´s all e-t172 is trying to say and he is right.

I don't think 6233638 and I disagree, actually. 6233638 is just being pedantic by pointing out that strictly following sRGB would not be a good idea since it explicitly specifies black and white luminance resulting in a very poor contrast ratio. I agree with that, it's just that when I use the term "sRGB", I'm talking about the primaries, white point and gamma, not including the absurd luminance values. Nobody seem to care about these anyway (well, except 6233638).

Analog projectors work at double shutter speed(48Hz), and yes "naked" 24fps is quite unbearable...especially when it comes with that nasty motion blur.

"I don't think it means what you think it means." An analog projector at 48 Hz (which is basically the same thing as a 48 Hz CRT in this regard) will display 24p much, much better than a 24Hz (or 48Hz) LCD because the former flickers and relies on human persistence of vision to fill in the gaps, which works very well. On the other hand, LCDs do not flicker, the image stays on the screen between refreshes, which defeats persistence of vision and results in non-smooth motion. I'm starting to believe that this unfortunate property of LCDs can be counterbalanced by madVR's smooth motion feature. (but then the question becomes: why didn't the manufacturers think of it?)

[leeperry]

Well, I was using this movie (http://www.imdb.com/title/tt1595656/) for test purposes this afternoon. It's got a lot of both fast and slow outdoor panning around Olga Kurylenko and it's judderland on the Sammy TV in 24Hz and dead smooth in 96Hz on my CRT.

I do need to find a way to get blending but not as ghosty as FRC...but then again madshi blames my OS when I have a hard time believing that W7 will make FRC bearable to my eyes. Oh well, I remember needing some time before I could find 48Hz smooth on my DLP so I'll see if my brain will ever get used to 24Hz LCD :sly:

[e-t172]

Well, I was using this movie (http://www.imdb.com/title/tt1595656/) for test purposes this afternoon. It's got a lot of both fast and slow outdoor panning around Olga Kurylenko and it's judderland on the Sammy TV in 24Hz and dead smooth in 96Hz on my CRT.

Yes. That makes sense.

I do need to find a way to get blending but not as ghosty as FRC...

As I said, maybe that has to do with LCD pixel response time. That would explain why it looks good to some people but not to others. Maybe it will always look great on a gaming monitor which is optimized for fast response, and it will look bad on some TVs at the other end of the spectrum. But I'm just speculating here. Maybe what I'm saying is bollocks and it's just that some people are more sensitive to it.

[hdboy]

Have you tried Overlay mode? Maybe that helps...


Display the debug OSD (Ctrl+J) and check which queues have which fill state. If you don't know what to look for, just make a screenshot in the moment when frame drops occur, with the OSD on.



Yes I am using overlay. Looks like the backbuffer queue is empty. It alternates between 0-8/8 and 7-8/8. The other queues never go to zero. On videos with no problem, backbuffer q is steady at 7-8/8.

[iSunrise]

As I said, maybe that has to do with LCD pixel response time.
It´s probably a mix of response time and panel type. The Eizo I use also has an H-IPS with very good response and my experiences with smooth motion seem to match yours. I would say that I am fairly happy with it´s current implementation. It looks very close to the native refresh that I am able to achieve with the Eizo. For scenes where there´s only one or only a few solid objects against a more or less solid background (which aren´t that common when watching real-world content) it looks incredibly good, so good that I can´t see any differences at all to native playback.

Here´s two samples I´ve found that look perfect with smooth motion:
http://www.mediafire.com/?5xccccrs7109mjn
http://www.mediafire.com/?1zos93buokb981r

I don't think 6233638 and I disagree, actually. 6233638 is just being pedantic by pointing out that strictly following sRGB would not be a good idea since it explicitly specifies black and white luminance resulting in a very poor contrast ratio. I agree with that, it's just that when I use the term "sRGB", I'm talking about the primaries, white point and gamma, not including the absurd luminance values. Nobody seem to care about these anyway (well, except 6233638).
Yes, I guess that´s just nitpicking on a high level. We´re all only making suggestions after all and if madshi feels they both offer something of worth to the user and these changes are also worth his time, he will hopefully take them into consideration.

[Niyawa]

sRGB=REC.709 (http://www.homecinema-fr.com/forum/ressources/image/54227), set mVR for gamut mapping to REC.709 et voilà ))
Could you elaborate on that? I have no idea what you want me to do.

[iSunrise]

Could you elaborate on that? I have no idea what you want me to do.
BT.709 shares the same primaries as sRGB, which are needed for accurate color reproduction. If you don´t have the option/don´t want to calibrate your monitor and go with the sRGB mode that is implemented, you can enable "this display is already calibrated" under your monitor´s "calibration" tab setting in madVR and set "the display is calibrated to the following primaries / gamut:" to BT.709. That way, the primaries should match more closely, which should give you more accurate color reproduction. Also, choose "pure power curve" and "2.20" under the "the display is calibrated to the following transfer function / gamma:" option.

After that, you can also check with test patterns from e.x. AVS HD within madVR if your black levels are as they should be. If you need an adjustment you currently can either adjust gamma ("enable gamma processing" and set the target gamma" a bit (lower value = brighter, higher value = darker) or use the brightness slider under the "color & gamma" tab. You should stay away from the "saturation", "contrast" and "hue" slider if possible.

That´s as far as you´re able to go without actually doing any calibration yourself. Depending on the quality and native gamma of your panel and the careness of the implementation of the sRGB mode on your monitor, the results can vary though. It should however look a lot better than non-managed.

Note that you won´t see any difference when just playing with the calibration values themselves. They are however important so that madVR "knows" your settings for appropriate conversions to take place.