View Full Version : madVR - high quality video renderer (GPU assisted)
6233638
8th April 2013, 07:49
There's a difference in the 16xSSAA pic you posted, also difference with avisynth subtract. (http://oi49.tinypic.com/j10k87.jpg)The only difference there is noise from madVR's dithering. (it is not static) If you were to disable dithering and take those screenshots again, they would be identical. If it was actually showing a difference, it would be as obvious as it is in the anti-ringing screenshot.
turbojet
8th April 2013, 07:53
FXAA and SSAA diff's look pretty similar, can see an outline of the car, frame count and bbca logo pretty well.
I stand corrected, after disabling dither the screenshots are bit identical and subtract shows nothing but a gray screen. Nevermind the antialiasing stuff it doesn't make a difference. Thanks 6233638 for informing of this so I don't waste more hours of messing with those settings to find out it's only placebo and madvr never shows the same image identical twice when dithering.
madshi
8th April 2013, 08:32
Here's a sample (http://www.sendspace.com/file/bhwper) that looks not so great without frc but looks worse with frc at 60hz, look at the left side of the face of the guy on the left.
Hmmmm... First of all I've remuxed your sample by doing (1) "eac3to blending.mkv 1: test.h264" and (2) "eac3to test.h264 test.mkv". The resulting MKV played better for me than the original. Then I've switched back and forth between FRC on/off. The face of the guy on the left moves with visible judder in both cases, because the scene was filmed too sharp for 24fps to be fluid. But to my eyes FRC on still looks overall smoother, and I can't see the left side of the face looking worse that way. I've tried but it looks better or equal than with FRC off to my eyes, at least when using the remuxed version of the sample.
Another thing mentioned (http://forum.doom9.org/showthread.php?p=1622580#post1622580)in the nvidia control panel is AA which is more effective for me than AR probably because of the postresize LumaSharpen which results in a sharper image then preresize but introduces an occasional problem with high contrast edges. Which AA deals with afterwards but AR doesn't have a chance too. AA is also very cheap performance wise while AR can't be used on some things I watch without dropping frames. FXAA is shader based that's very aggressive but also blurs image quite a bit. I prefer 4x SuperSampling (SSAA) which doesn't blur anymore than AR and still pretty effective AA. Could be an AR alternative if you have an nvidia and postsharpening or gpu is too weak to run AR. Intel doesn't have these options, unsure about ATI.
Can you please retest with dithering turned off, just to be safe? The reason I'm asking is that I have a hard time understanding how AA could have much of an impact. Multisampling AA depends on knowing which lines have which direction, and this information isn't available with madVR. I'm not sure if supersampling can make a visible difference with madVR, but if it does, the effect should be similar to up- and downscaling with Bilinear. Supersampling makes sense for 3D rendering because it lets the GPU render everything in higher resolution. But that's not what madVR is doing. madVR is rendering the video frames in internal buffers which are not being AA'ed. I think only the final frame presentation could be AA'ed, and for that madVR just feeds the GPU one big 2D texture, in the exact size of the output window. So that means that all supersampling could do is scale madVR's output up to higher resolution and then scale it down again. And I somehow doubt it even does that, but I guess it's possible, not sure. Anyway, even if it does, it's IMHO not a good thing to do, especially not with Bilinear algorithm which the GPU is likely to use for this.
I can imagine shader post processing AA (FXAA?) to have an effect. It might be useful if you have very strongly aliased content. But it might also blur things, so I have my doubts whether it's really useful for the majority of content.
None of these can possibly be a replacement for the AR filter because the AR filter does something completely different to any AA algorithm. E.g. look at the frame counter. In all images except the AR image there's a very clear blue outline around the green frame counter. No AA algorithm reduces this. Only AR does.
leeperry
8th April 2013, 08:39
That sounds weird. You're not supposed to see any ghosting - especially not at such a high refresh rate, where each blended frame should only be visible for ~11ms! Did you test this in FSE mode? Did the OSD mention any repeated, dropped or delayed frames? I can only imagine that something went wrong somewhere which must have resulted in the blended frames being shown longer than they should have...
Did you try FRC with a 89.91/120Hz display? Maybe it boils down to the way CRT's internally work but I do see very noticeable ghosting as previously reported. To be perfectly clear, I see those blended frames that don't follow the original camera shutter speed whatsoever, so things look blurry(even worse with linear light enabled) and pretty darn hiccupy/unnatural to me :o
I just tried a 24fps movie in 89.91Hz and there was no dropped/delayed frames reported(using the old rendering path on XPSP3).
Either way, I believe you implemented this feature as a "last resort" solution to the poor souls using 60Hz-only displays and I would presume that this feature fits the job nicely. You even said that a 24Hz multiple refresh rate would be preferable, so be it.
madVR can do (1) and (2), but not (3). Doing (3) well is extremely difficult. Doing (2) is like eating cake in comparison. I've said many times in the past that I have no plans to do (3), at least not any time soon. And that has not changed. I don't know what that Sammy does, and to be honest, I don't really care. I don't think you can do (2) better than madVR. So if the Sammy looks better to your eyes compared to what madVR does then the Sammy is likely doing some sort of (3). Or maybe it's (2) and madVR's FRC doesn't work correctly in your setup, for some funny reason...
It would appear that Sammy's FI in "crisp" mode works nicely on 29.97fps@60Hz but rather poorly on 24p@24Hz, boiling down to a matter of hiccupy camera shutter speed I presume...anyway, they also provide a 200Hz BFI that looks great and doesn't come with any visible drawback AFAICS :)
I owned a Panasonic Plasma many years ago
Don't mean to get OT, but I tried really hard to follow your recommandation on plasma....I found the current offerings of LG/Sammy to really lack native CR(2K:1'ish) and seriously considered ordering a 50ST60.......but then I saw a 50VT30 in a pitch black room and that looked just as flickery as those two other brands :confused:
Apparently, plasma's use a lot of dirty tricks and as much as I'm barely sensitive to RBE's, plasma's look like a 25Hz CRT to my brain =/
http://www.avsforum.com/t/945089/
Unlike LCD TVs, Plasma TVs flicker. This is the end-product of a design choice to create shading of colors. To do this Plasma panels use a method of strobing the pixels on and off to create the perception of shading of colors to the view.
http://www.avsforum.com/t/1119016/
Now I'm considering a return due to this
http://www.tested.com/forums/home-theater/13335-plasma-flicker/
I looked around the store when I returned the set, and could see flicker on all their plasmas, all brands and models
Ditto! They all flicker like hell to me.....I now can imagine the kind of trouble people who cannot stand DLP have to go through.
All this said, I finally found an affordable LED LCD from Sammy that comes with 200Hz BFI, 24p support, full-fledged colorimetry settings and not the usual clouding-prone edge led backlit...so all is well http://forum.slysoft.com/images/smilies/agreed.gif
I don't see any bright green RBE's(or anything else nasty for that matter), it's only channel logos that look a tad flickery due to the 200Hz BFI.....but I mostly bought it for mVR Jinc3AR goodness, so no biggy =)
And I rest my case that DNIE (http://forum.doom9.org/showpost.php?p=1600258&postcount=15433) looks amazing, especially on a 46" in combo with 200Hz BFI. Many ppl claim that Sammy are the market leaders for flat TV's and that apart from Panasonic the competition lags behind.....that would be my experience as well, providing outrageous bang/bucks value IME.
Yes, DFI would be something interesting to play with. However, I'd first need to have a display which supports 120Hz+ and I currently don't. Unfortunately it's usually only ugly TN displays which can handle such high refresh rates. And I hate TN. [..] good displays seem to use even higher refresh rates for BFI/DFI than 120Hz, and they do this internally. So I wonder if this even makes sense to build into madVR.
Well, apparently some/most of those 120Hz LCD's would only add a BF between each 60Hz source frame et voilā...but that would indeed seem low, so maybe they actually run at 240Hz after all.
Anyway, I agree that FRC was meant as a dirty fix but that BFI should be done within the display itself.
Both... Jinc needs more memory bandwidth, AR needs more shader power.
Ah! Alright, I'll wait for the 1GB 650Ti-Boost to show up then as I'd love to be able to process 59.94fps content in Jinc3AR as well.
Anyone running a regular 650Ti around here please? What kind of load on SD/720p@1080p with Jinc3AR chroma/luma?
Support for MPEG1 chroma placement is on my to do list.
Oh, that'd be sweet! Especially as nev did his part of the magic, your turn now :)
:thanks:
6233638
8th April 2013, 08:51
I stand corrected, after disabling dither the screenshots are bit identical and subtract shows nothing but a gray screen. Nevermind the antialiasing stuff it doesn't make a difference. Thanks 6233638 for informing of this so I don't waste more hours of messing with those settings to find out it's only placebo and madvr never shows the same image identical when dithering.Well as I said, FXAA might be making a difference, but depending on what you are using to take the screenshots, it might not be getting captured. MSAA or SSAA shouldn't be able to have any impact on videos though.
---
Changing the subject, is there a list of what tags are supported?
In the change log, these are mentioned - is this the full list?
"matrix=709|601|NTSC|PAL|YCgCo|240M"
"primaries=709|SmpteC|EBU|sRGB|NTSC|PAL|470M|240M|170M"
"levels=PC|TV|fullrange|limited|doubleExp|tripleExp"
"deint=On|Off|Video|Film"
"blacklevel=%value%", value range [-50, +50]
"whitelevel=%value%", value range [-50, +50]
"contrast=%value%", value range [-100, +100]
"brightness=%value%", value range [-100, +100]
"saturation=%value%", value range [-100, +100]
"hue=%value%", value range [-180, +180]
"frameRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
"refreshRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
If it is, I would like to request a gamma tag as well. Normally I leave madVR at 2.40 gamma for films, but I've just ripped some discs from a TV series, and it's clearly mastered to be viewed at 2.20 (this is also what has had me using tags in the first place, as I needed to force Video deinterlacing)
I think brightness ended up being some kind of gamma correction, but I would like to actually be able to specify 2.20 rather than +20 brightness etc.
I haven't used tags before - is the only way to use them to put them in the filename rather than some kind of metadata?
Not that it really matters I suppose. Now that I'm using JRiver Media Center, I don't have to look at the filename anyway.
madshi
8th April 2013, 08:52
Did you try FRC with a 89.91/120Hz display? Maybe it boils down to the way CRT's internally work but I do see very noticeable ghosting as previously reported. To be perfectly clear, I see those blended frames that don't follow the original camera shutter speed whatsoever, so things look blurry(even worse with linear light enabled) and pretty darn hiccupy/unnatural to me :o
I've not tried it, I don't have a CRT. But cyberbeing has tried it on his CRT and he reports that he doesn't see *any* FRC artifacts whatsoever at ~90Hz or something like that.
I just tried a 24fps movie in 89.91Hz and there was no dropped/delayed frames reported(using the old rendering path on XPSP3).
So you're using the old rendering path on XPSP3? That might be an explanation. FRC with high refresh rates really needs perfect presentation precision and XPSP3 doesn't allow more than 3 frames to be pre-presented at any time. The old FSE mode even only pre-presents 1 frame in advance. I would strongly suggest that your FRC experience is so bad because the old FSE mode in XPSP3 is just not exact/reliable enough. Try with the new FSE mode in win7 with rendering queues of at least 8 and with also at least 8 pre-presented frames. Really, XP needs to be retired, IMHO. win7 is the better XP now. At least that's my opinion/experience...
Don't meant to get OT, but I tried really hard to follow your recommandation on plasma....I found the current offerings of LG/Sammy to really lack native CR(2K:1'ish) and seriously considered ordering a 50ST60.......but then I saw a 50VT30 in a pitch black room and that looked just as flickery as those two other brands
From what I remember, my plasma flickered when being fed with 24Hz, too. But IIRC (not 100% sure, though) the better Panasonic plasmas accept 72Hz and don't flicker at that refresh rate?
Anyway, please let's not dive into another plasma vs LCD vs OLED discussion. The last one already took several pages and was totally OT. If some Panasonic plasma owner can confirm/deny that 72Hz is possible and doesn't flicker, that would be nice. Other than that please no further discussion on plasma, LCD, whatever. I appreciate it, thanks!
turbojet
8th April 2013, 08:54
Hmmmm... First of all I've remuxed your sample by doing (1) "eac3to blending.mkv 1: test.h264" and (2) "eac3to test.h264 test.mkv". The resulting MKV played better for me than the original. Then I've switched back and forth between FRC on/off. The face of the guy on the left moves with visible judder in both cases, because the scene was filmed too sharp for 24fps to be fluid. But to my eyes FRC on still looks overall smoother, and I can't see the left side of the face looking worse that way. I've tried but it looks better or equal than with FRC off to my eyes, at least when using the remuxed version of the sample.
I don't have haali instead so can't mux with eac3to but I do notice seeking is slow on the original that was cut with latest mkvmerge. I see problems at 47.952hz as well but it's emphasized with frc, on crt frc improves it quite a bit Could it be my cheap TN panel (with unlocked refresh rates) that's causing the problem?
Once frc disables at 48 or 72 hz this won't be an issue because it'll be disabled on lcd where it looks worse and enabled on crt where it looks better. I also think lcd's are a premature technology and waiting for oled's before replacing the crt's I still have (if possible). Plasma looks better to my eyes but they have a very short life for the price you pay for them.
Can you please retest with dithering turned off, just to be safe? The reason I'm asking is that I have a hard time understanding how AA could have much of an impact. Multisampling AA depends on knowing which lines have which direction, and this information isn't available with madVR. I'm not sure if supersampling can make a visible difference with madVR, but if it does, the effect should be similar to up- and downscaling with Bilinear. Supersampling makes sense for 3D rendering because it lets the GPU render everything in higher resolution. But that's not what madVR is doing. madVR is rendering the video frames in internal buffers which are not being AA'ed. I think only the final frame presentation could be AA'ed, and for that madVR just feeds the GPU one big 2D texture, in the exact size of the output window. So that means that all supersampling could do is scale madVR's output up to higher resolution and then scale it down again. And I somehow doubt it even does that, but I guess it's possible, not sure. Anyway, even if it does, it's IMHO not a good thing to do, especially not with Bilinear algorithm which the GPU is likely to use for this.
I can imagine shader post processing AA (FXAA?) to have an effect. It might be useful if you have very strongly aliased content. But it might also blur things, so I have my doubts whether it's really useful for the majority of content.
None of these can possibly be a replacement for the AR filter because the AR filter does something completely different to any AA algorithm. E.g. look at the frame counter. In all images except the AR image there's a very clear blue outline around the green frame counter. No AA algorithm reduces this. Only AR does.
I was testing this while you were typing, edited my previous post.
I've encountered madvr trying to change refresh rates for a 23.976 source from 47.952 to 47.952 twice but didn't have logging on and C: only has 5GB free and the log grows fast when playing video c: would run out of space. Is there any way to log to a different drive or only log for a few seconds? Couldn't think of a way to do it with batch scripts.
madshi
8th April 2013, 09:05
Changing the subject, is there a list of what tags are supported?
In the change log, these are mentioned - is this the full list?
Yes, that's the full list.
If it is, I would like to request a gamma tag as well. Normally I leave madVR at 2.40 gamma for films, but I've just ripped some discs from a TV series, and it's clearly mastered to be viewed at 2.20 (this is also what has had me using tags in the first place, as I needed to force Video deinterlacing)
I think brightness ended up being some kind of gamma correction, but I would like to actually be able to specify 2.20 rather than +20 brightness etc.
Adding a gamma tag might not be totally clear: Do you want to specify the gamma curve the video file was encoded with? Or do you want to specify the gamma curve you would the video to be modified to, respectively displayed at? Setting the first to 2.40 would make the image "brighter", setting the second to 2.40 would make it darker. Also, ideally the display gamma curve should have a higher value when ambient light levels are low and a lower value when there are high ambient light levels. So does it make sense to choose a fixed display gamma value for a specific video file? I think modifying the brightness is the better approach. It would allow you to adjust the display gamma curve to the ambient light level and still see both this special video file and all other files with the right gamma curve without having to change anything manually...
I haven't used tags before - is the only way to use them to put them in the filename rather than some kind of metadata?
Yes, tags are currently only supported in the filename.
I see problems at 47.952hz as well but it's emphasized with frc, on crt frc improves it quite a bit Could it be my cheap TN panel (with unlocked refresh rates) that's causing the problem?
I'm not sure. I wouldn't expect much differences between different display technologies, but what do I know...
I've encountered madvr trying to change refresh rates for a 23.976 source from 47.952 to 47.952 twice but didn't have logging on and C: only has 5GB free and the log grows fast when playing video c: would run out of space. Is there any way to log to a different drive or only log for a few seconds? Couldn't think of a way to do it with batch scripts.
You can start the video and stop it almost immediately. That should keep the log file size down and the refresh rate switching should still be in the log. There's no easy way to move the log file to a different place atm...
6233638
8th April 2013, 09:21
Adding a gamma tag might not be totally clear: Do you want to specify the gamma curve the video file was encoded with? Or do you want to specify the gamma curve you would the video to be modified to, respectively displayed at? Setting the first to 2.40 would make the image "brighter", setting the second to 2.40 would make it darker. Also, ideally the display gamma curve should have a higher value when ambient light levels are low and a lower value when there are high ambient light levels. So does it make sense to choose a fixed display gamma value for a specific video file? I think modifying the brightness is the better approach. It would allow you to adjust the display gamma curve to the ambient light level and still see both this special video file and all other files with the right gamma curve without having to change anything manually...I was wanting to override the value for gamma correction, which seemed to make the most sense if you are tagging files with a number:
http://www.abload.de/img/gammarykzn.png
I have my display calibrated so that whatever value is set there, is what you will get when you measure it.
It is normally left at 2.40 because my viewing conditions rarely change (mostly films in a dark room, and display reference gamma is 2.40 (http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf)) and if they do, I switch between presets on my display rather than changing settings on the PC.
Those presets account for various levels of ambient light by adjusting the backlight and gamma on the display, so they aren't really suited to fix content that has been mastered too dark. (otherwise you have a really bright display in a dark room)
In this case, the show is obviously mastered differently from typical films, and is too dark when displayed at 2.40 gamma. I can change it to 2.20 manually, but was hoping that I could batch rename all my files to set that via tags, rather than changing it every time I watch an episode. (just like I added deint=video to them all, so I wouldn't have to change from my default of forcing film type deinterlacing)
turbojet
8th April 2013, 09:24
You can start the video and stop it almost immediately. That should keep the log file size down and the refresh rate switching should still be in the log. There's no easy way to move the log file to a different place atm...
Moved it to another hard drive with a symbolic link hopefully it happens again before it grows to 348 GB. Would you be able to find refresh rate change in that big of a log?
madshi
8th April 2013, 09:27
@6233638: Yeah, but it's still ambiguous. If you add a tag like "[gamma=2.40]" then how should madVR know whether you mean the source gamma and the desired display gamma? What's so bad about using the brightness tag instead? I don't really understand why you don't like that...
@turbojet: Finding might be hard if there are multiple video starts in that log file. If it's just video start then it's less of a problem. However, zipping, uploading, downloading, unzipping, editing such a large file is all very painful, of course.
italospain
8th April 2013, 09:30
The only issue with IVTC'ing atm is that ReClock has to be manually set to 23.976 input fps.
This is the only reason i am still
using dscaler mod.
It would be great if madVR would do the same as dscaler mod does.
My second wish where detection or at least a file tag to crop non anamorphic DVDs. (doing this with the zoom option of the TV degrades Quality).
turbojet
8th April 2013, 09:32
It sounds like a hassle but it happens randomly so logging needs to be on all the time. I'll try to delete the log regularly or maybe script it to be deleted when the video is closed.
It doesn't happen if monitor is set to 48hz but also get the occasional repeated frame then.
6233638
8th April 2013, 09:39
@6233638: Yeah, but it's still ambiguous. If you add a tag like "[gamma=2.40]" then how should madVR know whether you mean the source gamma and the desired display gamma? What's so bad about using the brightness tag instead? I don't really understand why you don't like that...Well typically content is either going to be mastered on a display that is running 2.40 gamma, or 2.20 gamma. (it should be 2.40 but until recently there was no published standard for it)
I prefer to get things correct, rather than what "looks good" so I would rather be able to set 2.20 exactly.
And I think that you use 2.20 as the "reference" gamma in madVR, so setting it to 2.20 is equivalent to having gamma correction disabled.
Do brightness adjustments correspond to gamma at all?
Would +10 brightness be equivalent to -0.10 gamma? (or some other fixed amount)
As long as it's explained that you are setting the gamma correction value, I'm not sure why tagging it with [gamma=2.20] or some other value would be confusing. (having a gamma tag mean anything else would be)
This is the only reason i am still
using dscaler mod.
It would be great if madVR would do the same as dscaler mod does.I've never had to set the framerate in ReClock manually for IVTC to work correctly. (and DScaler Mod never worked right for me)
My second wish where detection or at least a file tag to crop non anamorphic DVDs. (doing this with the zoom option of the TV degrades Quality).You should be able to do this in your player.
italospain
8th April 2013, 09:57
I've never had to set the framerate in ReClock manually for IVTC to work correctly. (and DScaler Mod never worked right for me)
You should be able to do this in your player.
For me ReClocks Icon has to be green to do his magic.
How ? I am using Zoom Player. Would it work without manually switching the aspect ratio ?
leeperry
8th April 2013, 11:52
So you're using the old rendering path on XPSP3? That might be an explanation. FRC with high refresh rates really needs perfect presentation precision and XPSP3 doesn't allow more than 3 frames to be pre-presented at any time. The old FSE mode even only pre-presents 1 frame in advance. I would strongly suggest that your FRC experience is so bad because the old FSE mode in XPSP3 is just not exact/reliable enough. Try with the new FSE mode in win7 with rendering queues of at least 8 and with also at least 8 pre-presented frames. Really, XP needs to be retired, IMHO. win7 is the better XP now.
Well, the old rendering path is dead smooth in my experience with Reclock.....I mean über-low jitter, butter smooth slow 24p pans, no random dropped frame whatsoever(even w/ 59.94fps content).....I've always been thoroughly impressed by how butter-smooth mVR looks on my set-ups.
You said yourself that FRC wasn't preferable to a plain 24Hz multiple refresh rate, and 24p@24/48/96Hz with Reclock is like an unstoppable train on my rig :cool:
Well, there's still quite a bunch of ppl on XP: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
It mostly boils down to laziness to upgrade when everything works just fine as is...as soon as Windows moved to the NT core, upgrades settled down and even after giving away W8 upgrades barely anyone(3% in that previous link) bothered making the (big) jump.
From what I remember, my plasma flickered when being fed with 24Hz, too.
I saw all the aforementioned plasma's fed with 1080/50i DVB-T...black level on the 50VT30 was very impressive, though! It's good to read that Pana has moved its R&D to OLED now :devil:
DragonQ
8th April 2013, 12:10
View Post
From what I remember, my plasma flickered when being fed with 24Hz, too.
I saw all the aforementioned plasma's in 50Hz...black level on the 50VT30 was very impressive, though! It's good to read that Pana has moved its R&D to OLED now :devil:
I don't know if this is true of all Panasonic plasmas but the model I have (P50ST50) has different ways of showing 24 Hz content depending on where you buy it. The NA model shows it at either 48 Hz (too much flicker) or 60 Hz (less flicker but uses frame blending to avoid judder). The EU model shows it at 96 Hz, which results in no flicker or judder. Showing each frame more than once can result in "stop start" artefacts though (where the brain expects motion upon every refresh but only gets it every 4 refreshes, so the image appears to stop-start all the time). Fortunately most people aren't susceptible to this - after all, it's done on practically every TV and monitor when showing 24p/25p/30p content.
Similarly, the EU models also show 25p/25i/50p video at 100 Hz because 50 Hz flicker is way too noticeable (like the 48 Hz flicker mentioned above). This produces the same "double image" effect if you know how to spot it, but it's still very preferable to flicker. If I understand correctly, LCDs refresh the image differently and don't have any issues showing 50 Hz natively without flicker.
SamuriHL
8th April 2013, 12:33
Yea my Panasonic tcp65vt50 has 48/60/96 for 24 and I agree with the above assessment.
Sent from my Xoom using Tapatalk HD
iSunrise
8th April 2013, 12:52
madshi, I have a question:
When madVR plays a film on Blu-Ray and it shows "(best guess)" after the matrix and primaries value, does that always mean that madVRīs internal guessing logic (resolution, etc.) comes into play rather than getting that info directly from the stream? Or do you use (best guess) for both cases where you assume the film to be correctly tagged and if it isnīt you would show (best guess) anyway?
@6233638: Yeah, but it's still ambiguous. If you add a tag like "[gamma=2.40]" then how should madVR know whether you mean the source gamma and the desired display gamma? What's so bad about using the brightness tag instead? I don't really understand why you don't like that...
Since you need to parse the tags anyway, wouldnīt it make sense in this case to insert a separator of some kind so we have control over both source and desired? So we could define both?
I also donīt like the brightness adjustment. Itīs confusing for people that are accustomed to calibrating/adjusting their displays, who work with gamma values. I would never use a brightness slider to adjust gamma values, not if I donīt have to. I consider the brightness adjustment to be some kind of last resort rather than "how it should be done". The brightness adjustment is more like a "it looks better that way" rather than a "it should look like this by definition" option.
If we have content with a native gamma of 2.20 (e.x. that was recorded on a PC or a tv series or camera footage, etc.) that needs to be shown at 2.20, we would have to change the madVR settings every time and this is definately not a good solution.
The issue with films, tv series and other content right now is that thereīs just too much stuff around where we need fine control over the provided options, or rather profiles where we could set our desired values taking into account the settings of our calibrated display(s).
The good thing about madVR currently is that you have most of these needed options for all our content.
I donīt want to go into too much detail, but the most annoying thing about Blu-Rays is that on most of my Blu-Ray collection, the provided parameters (matrix, primaries, etc.) are wrong.
A typical example of watching a film that was mastered on Blu-Ray:
Yesterday I watched the US Blu-Ray of Conan The Destroyer where madVR assumed BT.709 for everything (it shows best guess). About 15 minutes into the movie I was taken out of it entirely, because Arnold and other actors had sunburn-like fleshtones. After looking closely and comparing between BT.709 and SMPTE-C, the film looks entirely natural with SMPTE-C while it looks totally wrong with BT.709. And thatīs a case that is not rare, I have a lot of such Blu-Rays where BT.709 just was blindly encoded with but the actual content was mastered on SMPTE-C. Even with newer content, this seems to be the case. Itīs freaking me out.
Having a brand-new Eizo CG243W with a fresh CCFL and a new panel from 2013 is a good thing (I donīt need to waste too much time for calibration anymore, along with native support of various used frame rates), but itīs painfully revealing (apart from the black levels of course, while 0,08cd/mē (http://www.abload.de/img/smptec_80cdgfaaf.png) after calibration is still respectable for an IPS).
ryrynz
8th April 2013, 14:07
I owned a Panasonic Plasma many years ago. I've converted to front projection since then. Does the same artifacts occur again if you replay the same movie scene? That's the first key question you have to find an answer for.
If I skipped the video back I could not get the sticky artifact to show again, it just occurs somewhat randomly.
Weird, that shouldn't happen. Do you see a new dropped, repeated or delayed frame in the OSD when this happens? How often does this problem occur?
For me I usually see the black frame at least once every hour or so (once every few episodes) but I did not see it tonight. I will check the OSD when it occurs again.
e-t172
8th April 2013, 18:17
Showing each frame more than once can result in "stop start" artefacts though (where the brain expects motion upon every refresh but only gets it every 4 refreshes, so the image appears to stop-start all the time). Fortunately most people aren't susceptible to this - after all, it's done on practically every TV and monitor when showing 24p/25p/30p content.
Well, considering that's how traditional cinema projection (http://en.wikipedia.org/wiki/Movie_projector#Shutter) works, I wouldn't expect it to be a concern for most people.
6233638
8th April 2013, 20:33
For me ReClocks Icon has to be green to do his magic.I have never looked at ReClock's icon - I disable tray icons for any application where possible. All I can say is that I have never had to manually set the framerate for files, madVR does not report any dropped frames, and playback is smooth. (I would definitely notice if something was going wrong)
How ? I am using Zoom Player. Would it work without manually switching the aspect ratio ?I don't use Zoom Player. What I meant was that you can do the scaling on your computer (with madVR) rather than having to fix the aspect ratio with your TV. (losing quality)
JRiver Media Center will let you tag files to override their aspect ratio. (though the tags could be more user-friendly - it's easiest to manually set one file, and then copy the tags to any others)
Since you need to parse the tags anyway, wouldnīt it make sense in this case to insert a separator of some kind so we have control over both source and desired? So we could define both?I just don't understand why you would ever define a "source gamma" for a file - if it's HD content then it is encoded to BT.709 for example (or potentially SMPTE-C) and you should not deviate from it.
Gamma adjustments are a "calibration" feature, not a "source" feature.
An argument could be made for [gamma+0.20] rather than [gamma=2.40] but then that introduces some ambiguity.
Is [gamma+0.20] equal to 2.40 gamma always, or would it increase the gamma setting to 2.60 because I have madVR set to 2.40?
[gamma=2.40] is less ambiguous, because you are setting the gamma correction in madVR to a specific value.
Edit: and on the subject of tags, even more controversially: would it be possible to have a cadence tag?
I have just encountered some 1080i content that is initially detected as 4:2:2:2, then after about 10s of playback changes to 2:2, and finally at 25s it properly detects a 3:2 cadence - but there are cadence breaks throughout.
While I understand that there is content with mixed cadences and forcing one is potentially a recipe for disaster, I think there are some cases where it is justified.
madshi
8th April 2013, 21:43
This is the only reason i am still
using dscaler mod.
It would be great if madVR would do the same as dscaler mod does.
I don't think it works that way. Reclock detects what dscaler is doing because Reclock probably checks how many frames per second dscaler is sending upstream. IVTC is done inside of madVR so Reclock has no chance to count the frames. I don't think there's anything I can do about it. The only solution would be for madVR and Reclock to talk to each other. But the last time I suggested something like that to James (Slysoft) he wasn't very enthusiastic about the idea at all.
My second wish where detection or at least a file tag to crop non anamorphic DVDs. (doing this with the zoom option of the TV degrades Quality).
Zoom related settings belong into the media player GUI. Well, maybe in the long run I'll add something like this to madVR, but not any time soon.
Normally I leave madVR at 2.40 gamma for films, but I've just ripped some discs from a TV series, and it's clearly mastered to be viewed at 2.20
I just don't understand why you would ever define a "source gamma" for a file - if it's HD content then it is encoded to BT.709 for example (or potentially SMPTE-C) and you should not deviate from it.
First you say you have ripped a TV series which needs to be viewed with a different gamma than other content, then you say that you should not deviate from the encoding. Only one of those 2 things can be true.
Well typically content is either going to be mastered on a display that is running 2.40 gamma, or 2.20 gamma. (it should be 2.40 but until recently there was no published standard for it)
I don't think it's as easy as that. E.g. I've read some months/years ago that Pixar has their displays set to 2.50 for mastering. Who knows if it's true, maybe not. But in any case, there's no way to know for sure which exact gamma curve mastering monitors were set to. We can only guess. It could be anything between 2.00 and 2.70, for all we know...
I prefer to get things correct, rather than what "looks good" so I would rather be able to set 2.20 exactly.
Doing things "correct"ly requires knowledge of the exactly needed value, but we don't know that. Either we trust the source encoding, or we don't. If we don't, then we can only guess what other value is "correct". Could be anything...
Do brightness adjustments correspond to gamma at all?
Would +10 brightness be equivalent to -0.10 gamma? (or some other fixed amount)
No, brightness changes are actually converted into gamma value changes by multiplying the factors with a power curve with the exponent 1.5. I had experimented with how to make the brightness adjustment "feel" good and ended up with a relatively complicated formula. Brightness does only change the gamma value (nothing else), but not in a simple linear way.
As long as it's explained that you are setting the gamma correction value
Where would it be explained? Tags are not documented anywhere. They have to be self-explaining.
If I skipped the video back I could not get the sticky artifact to show again, it just occurs somewhat randomly.
Well, that's good news, sort of. If means that the artifacts you're seeing are probably not a fundamental fault in the smooth motion FRC, but rather a simple bug that I might be able to fix.
When madVR plays a film on Blu-Ray and it shows "(best guess)" after the matrix and primaries value, does that always mean that madVRīs internal guessing logic (resolution, etc.) comes into play rather than getting that info directly from the stream?
Yes. Otherwise it would say "(says bitstream)" or "(says upstream)", depending on where madVR got the information from.
If we have content with a native gamma of 2.20 (e.x. that was recorded on a PC or a tv series or camera footage, etc.) that needs to be shown at 2.20, we would have to change the madVR settings every time and this is definately not a good solution.
There is no such thing as content that "needs to be shown at x.xx". The proper gamma value to watch any content with changes with the ambient light levels in your room. There *is* content which is encoded with an incorrect transfer function. Such content might need a gamma tweak to repair the bad encoding. But that gamma tweak is a relative gamma change to the gamma curve your display needs with the current ambient light levels.
An argument could be made for [gamma+0.20] rather than [gamma=2.40] but then that introduces some ambiguity.
Is [gamma+0.20] equal to 2.40 gamma always, or would it increase the gamma setting to 2.60 because I have madVR set to 2.40?
[gamma=2.40] is less ambiguous, because you are setting the gamma correction in madVR to a specific value.
Why would [gamma+0.20] always equal to 2.40? I don't see the reasoning behind that. As mentioned multiple times, the needed gamma value depends on the ambient light level. And madVR just has a default value, but it's not fixed, it can be changed. So a [gamma+0.20] would clearly be relative to the currently selected value. However, the ambiguity I see is that [gamma+0.20] could either apply to the source transfer function or to the display transfer function.
-------
In any case, I've just decided that I'm spending too much time discussing feature requests/suggestions here in the forum. This one post alone took about an hour to write (rewrote several replies etc). Furthermore I've also decided that my to do list is already more than long enough right now. So from now on I'll generally not accept any new feature requests, anymore (the exception proves the rule). That will be my new stance until madVR has reached v1.0. Sorry about that, but I gotta set some priorities if I want to get anywhere. So, for now, no new tags. Feel free to ask again after v1.0.
madshi
8th April 2013, 21:45
I have just encountered some 1080i content that is initially detected as 4:2:2:2, then after about 10s of playback changes to 2:2, and finally at 25s it properly detects a 3:2 cadence - but there are cadence breaks throughout.
A sample would be nice, from the start until maybe the first one or two 3:2 cadence breaks. And sorry, but no to the cadence tag feature request for now.
turbojet
8th April 2013, 22:18
6233638: missed your reply yesterday about aa. Print screen was used, that's wysiwyg right?
madshi: I don't know if this is a limitation or a bug so I'm posting it here instead of the bug tracker. There's a lot of dropped frames when moving between 2 screens with different refresh rates without restarting the player. MadVR status shows the correct display rate but the composition rate is static. A log (http://www.sendspace.com/file/8zh24i) that starts a video at 48hz, switches to 60hz single display, switch to 48hz primary and 60hz secondary, move to 60hz secondary. Also I've given up on the logging 47.952 changing to 47.952, too much hassle.
DragonQ
8th April 2013, 22:40
Well, considering that's how traditional cinema projection (http://en.wikipedia.org/wiki/Movie_projector#Shutter) works, I wouldn't expect it to be a concern for most people.
It's a different technology though. As I said, it isn't a problem with LCDs but apparently can be for plasmas. I don't know much more than that.
6233638
8th April 2013, 23:12
First you say you have ripped a TV series which needs to be viewed with a different gamma than other content, then you say that you should not deviate from the encoding. Only one of those 2 things can be true.The source is always encoded to the specification (e.g. BT.709) so it should be left alone.
BT.709 does not specify a display gamma however. CRT broadcast monitors have a native gamma of approximately 2.40, but some LCD broadcast monitors were set to 2.20 gamma. We now have a spec for display gamma (BT.1886) which uses 2.40 as the reference gamma. (but it also includes compensation for lower contrast displays)
So if the content was mastered on an LCD monitor rather than a CRT, OLED, or BT.1886 calibrated display, it can look too dark when displayed at 2.40 gamma. (which this content does)
So to match the original intent, you have to change your display to 2.20 gamma. Now there is nothing that specifies "this content was made for 2.20 gamma" - it's just that from working with display calibration for a long time and watching a lot of content, I can see when the content is being displayed wrongly. (rather than it being intent)
The reality of the situation is that we're talking semantics. Whether you are changing the "source" gamma or the "display" gamma, as long as it is actually being changed by equal amounts, the resulting image should be the same.
But when that gamma correction setting already exists inside madVR, it seems to make a lot more sense to have direct control over it, by being able to override it for certain videos.
I don't think it's as easy as that. E.g. I've read some months/years ago that Pixar has their displays set to 2.50 for mastering. Who knows if it's true, maybe not. But in any case, there's no way to know for sure which exact gamma curve mastering monitors were set to. We can only guess. It could be anything between 2.00 and 2.70, for all we know...I believe they were calibrated to 2.40 gamma. There's always been some debate over gamma, but it typically falls between 2.20, 2.35 (old EBU recommendation) and 2.40 (BT.1886 spec)
If we assume that the display connected up to the PC has been properly calibrated (monitors should use 2.20 gamma) it is likely going to be set up this way, or using a 3DLUT. (which tries to calibrate the display to 2.20 gamma based on the values you give yCMS)
http://www.abload.de/img/calibratedmgrng.png
This is all fine so far. But video content is typically designed to be viewed at (or around) 2.40 gamma - based on what a broadcast CRT measures, and the BT.1886 specification.
So with my display calibrated to 2.20 gamma, and madVR set up accordingly, I then need to use gamma correction to achieve the correct 2.40 gamma for watching film content:
http://www.abload.de/img/gamma3sqbt.png
So far, so good. PC content is displayed at 2.20 on the desktop, and video content is displayed at 2.40 - as intended.
Note: I am not trying to recommend this setting as a default in madVR (I think someone else did recently) because it will make videos appear darker than other players, and I wouldn't recommend it if the display is not calibrated to actually measure 2.20 first.
But there is some content out there which has clearly been mastered on those Broadcast LCDs that were set to 2.20 gamma, so the video looks too dark at the 2.40 setting, and you would either have to disable gamma correction, or set it to 2.20 (in this example, either should give you the same result, but I would prefer to specify 2.20)
Even though there are many ways you could go about doing it, I don't think it makes sense to change gamma "at the source", or by changing the display value (the devices > display > calibration value) and it only makes sense to change the "color & gamma" processing value via tags. Anything else is potentially messing with your calibration.
I would suggest setting it to an absolute value (e.g. 2.20, 2.35, or 2.40) rather than a relative value (e.g. +0.10, -0.15 etc.) to avoid any confusion.
There is no such thing as content that "needs to be shown at x.xx". The proper gamma value to watch any content with changes with the ambient light levels in your room. There *is* content which is encoded with an incorrect transfer function. Such content might need a gamma tweak to repair the bad encoding. But that gamma tweak is a relative gamma change to the gamma curve your display needs with the current ambient light levels.The BT.1886 specification would beg to differ. 2.40 gamma is the reference that all displays should be targeting - in a controlled environment. In an uncontrolled environment, anything goes - what's the point of 2.4 gamma if you can't see anything because the room is too bright? Though you could probably measure the in-room contrast and apply the BT.1886 curve to arrive at the "correct" gamma value for those viewing conditions. (below 10,000:1 contrast, it deviates from 2.40 gamma)
In any case, I've just decided that I'm spending too much time discussing feature requests/suggestions here in the forum. This one post alone took about an hour to write (rewrote several replies etc). Furthermore I've also decided that my to do list is already more than long enough right now. So from now on I'll generally not accept any new feature requests, anymore (the exception proves the rule). That will be my new stance until madVR has reached v1.0. Sorry about that, but I gotta set some priorities if I want to get anywhere. So, for now, no new tags. Feel free to ask again after v1.0.:(
A sample would be nice, from the start until maybe the first one or two 3:2 cadence breaks. And sorry, but no to the cadence tag feature request for now.I'll send you a PM. I wasn't really expecting anything to happen about a cadence tag. It's just that it is very annoying when there's content you know has a specific cadence, and there's no way to lock it. (this is rare, however)
6233638: missed your reply yesterday about aa. Print screen was used, that's wysiwyg right?I think so. I'm not really sure though, I haven't tried to take screenshots of things with FXAA running. I just know that when FXAA was first implemented in the drivers, there were a lot of people on gaming forums complaining that their favorite screenshot tool took the screenshot before the FXAA processing had been applied.
turbojet
8th April 2013, 23:40
Those who have 72hz displays what does madvr status say for 1 frame repeat/drop every?
For me, it says 1 drop every 4-6 minutes, which doesn't sound right. At 48/60/50/75hz it says 1 repeat every 2-6 days. Trying to figure out if there's anything wrong and if so is it the display or madvr.
cyberbeing
9th April 2013, 04:15
madVR repeat/drop every is a function of your refresh rate and clock deviation.
By default, my untweaked 72.05Hz refresh rate which my NVIDIA card defaulted to, had madVR reporting a repeat every 42 seconds. This is of course normal, because it was too far off the mark.
I did a test just now with a 71.928Hz refresh rate tweaked for my clock deviation, and madVR now overflows the maximum of 6.07 days and reports "Repeat every 1.#J days". And this is without using Reclock.
Don't underestimate that extreme floating-point accuracy you need in your refresh rate matched to your clock deviation, in order to avoid any drops/repeats without Reclock.
turbojet
9th April 2013, 05:57
Closest to 71.928 I can get is 71.916 or 71.955. The same sort of hole around 47.952, both give drop\repeat <5 minutes. 48.0002 works fine with reclock but there's a little flicker. 72.0001 drop <1 minute and according to reclock its 60hz. Guess I'll stay with 48hz+reclock. The native 60hz is a bit off at 59.86906 and it drops frames about every minute. Changing it to 60.0001 with CRU works great but after CRU is used madvr's display changer doesn't work anymore. Reclock runevent.vbs can change it with nircmd after CRU but then there's an issue with display and composition no longer matching in madvr, same as multiple display issue I mentioned earlier.
madshi
9th April 2013, 07:25
madshi: I don't know if this is a limitation or a bug so I'm posting it here instead of the bug tracker. There's a lot of dropped frames when moving between 2 screens with different refresh rates without restarting the player. MadVR status shows the correct display rate but the composition rate is static. A log (http://www.sendspace.com/file/8zh24i) that starts a video at 48hz, switches to 60hz single display, switch to 48hz primary and 60hz secondary, move to 60hz secondary. Also I've given up on the logging 47.952 changing to 47.952, too much hassle.
The cause of the problem will be the static composition rate. I suppose it's always the refresh rate of the primary monitor? Unfortunately the composition rate is totally out of madVR's control, so there's nothing I can do about it. The same problem should occur with any other renderer, too.
fallengt
9th April 2013, 07:42
I'm not sure why but when I switch to exclusive fullscreen, it changes color profile and gamma, doesn't happen on my laptop nor windows fullscreen mode.
madshi
9th April 2013, 08:07
Edit: and on the subject of tags, even more controversially: would it be possible to have a cadence tag?
I have just encountered some 1080i content that is initially detected as 4:2:2:2, then after about 10s of playback changes to 2:2, and finally at 25s it properly detects a 3:2 cadence - but there are cadence breaks throughout.
While I understand that there is content with mixed cadences and forcing one is potentially a recipe for disaster, I think there are some cases where it is justified.
In this case madVR is mostly correct about the detected cadences. The cadence at the start really is 4:2:2:2, then the TV station added an 2:2 overlay over the 4:2:2:2 movie. Then it switches to 3:2. madVR gets all this perfectly. The only thing that goes wrong is the cadence break after roughly 1 minute of playback. The cause of the cadence break is that the video is encoded very badly. It's encoded with hard-telecine at that runtime, meaning some frames are weaved-together fields of two different original frames. That's ok, but the problem is that the bitrate is so low that the encoder screwed up and somewhat melted those two interlaced fields from different frames together. I can see with my eyes that the cadence wasn't really broken, however there are some truely funky fields/frames there and it's nearly impossible for the IVTC algorithm to see through those encoding problems.
Anyway, do you see any combing artifacts? Everything looks just fine to me. So from what I can see, the IVTC algorithm does a very fine job with this sample. I bet most other IVTC algorithms would have a hard time with this sample. And btw, if you forced a 3:2 cadence on this one, you'd probably see combing artifacts in the first 20 seconds of this sample.
I'm not sure why but when I switch to exclusive fullscreen, it changes color profile and gamma, doesn't happen on my laptop nor windows fullscreen mode.
Have you checked the option "disable GPU gamma ramps" in your madVR display setup? Try unchecking this one. Does that help? If it does then the question is whether you have GPU gamma ramps setup intentionally or accidently?
italospain
9th April 2013, 08:59
I don't think it works that way. Reclock detects what dscaler is doing because Reclock probably checks how many frames per second dscaler is sending upstream. IVTC is done inside of madVR so Reclock has no chance to count the frames. I don't think there's anything I can do about it. The only solution would be for madVR and Reclock to talk to each other. But the last time I suggested something like that to James (Slysoft) he wasn't very enthusiastic about the idea at all.
Thanks for the explanation.
But wouldn't it possible to "talk" with LAV Filters ?
italospain
9th April 2013, 09:05
6233638: missed your reply yesterday about aa. Print screen was used, that's wysiwyg right?
madshi: I don't know if this is a limitation or a bug so I'm posting it here instead of the bug tracker. There's a lot of dropped frames when moving between 2 screens with different refresh rates without restarting the player. MadVR status shows the correct display rate but the composition rate is static. A log (http://www.sendspace.com/file/8zh24i) that starts a video at 48hz, switches to 60hz single display, switch to 48hz primary and 60hz secondary, move to 60hz secondary. Also I've given up on the logging 47.952 changing to 47.952, too much hassle.
Have you tried ReClock ?
There you can force detection of the secondary Display.
fallengt
9th April 2013, 12:02
Have you checked the option "disable GPU gamma ramps" in your madVR display setup? Try unchecking this one. Does that help? If it does then the question is whether you have GPU gamma ramps setup intentionally or accidently?
It's always unchecked, doesn't change anything. Also whenever I switch to fullscreen exclusive mode, my GPU(ATI HD6850) load skyrocket to 80%.
I think I messed up somewhere, not sure what it is though.
MokrySedeS
9th April 2013, 12:16
Anyone running a regular 650Ti around here please? What kind of load on SD/720p@1080p with Jinc3AR chroma/luma?
On my MSI N650TI PE:
720p @ 23.976fps - 30%
720p @ 59.94fps - 74%
720x576 (16:9) @ 25fps - 25%
I could't find any interlaced stuff in my archive, so send me samples if you want it tested.
leeperry
9th April 2013, 13:45
On my MSI N650TI PE:
720p @ 23.976fps - 30%
720p @ 59.94fps - 74%
720x576 (16:9) @ 25fps - 25%
goodie goodie, TYVM!
I'm quite surprised because IIRC the first test also gave 30% on a 660...will have to look it up. You tested this with Jinc3 AR for both chroma & luma to 1920*1080p?
How about 1440*1080@29.97 please? This seems to really push the limits IME.
I'm spending too much time discussing [..] here in the forum.
I entirely agree that we're wasting your time, but please allow me to ask whether the AR filename tag is on your current todo list ? That'd be darn sweet to be able to tag AR's once and for all :devil:
DragonQ
9th April 2013, 14:12
I could't find any interlaced stuff in my archive, so send me samples if you want it tested.
How about 1440*1080@29.97 please? This seems to really push the limits IME.
I don't have that but I do have a 1440x1080i/25 sample (http://www.aotplaza.com/Files/HTPC/Samples/1440x1080i25%20Sample.mkv) you can use.
MokrySedeS
9th April 2013, 15:08
Thanks DragonQ, I get 73% load with your sample.
I've also found a sample here (http://forum.doom9.org/showpost.php?p=1608554&postcount=16714) - 91% load.
You tested this with Jinc3 AR for both chroma & luma to 1920*1080p?
Yes, Jinc3 AR for both on my 1080p monitor @ 60Hz.
Tests were performed with smooth motion disabled.
truexfan81
9th April 2013, 21:02
Thanks DragonQ, I get 73% load with your sample.
I've also found a sample here (http://forum.doom9.org/showpost.php?p=1608554&postcount=16714) - 91% load.
Yes, Jinc3 AR for both on my 1080p monitor @ 60Hz.
Tests were performed with smooth motion disabled.
yeah 60fps is tough, if i use jinc3 luma, i get 91%gpu usage with my gtx 650 which means lots of dropped frames, so when i watch 60 fps video i just change it to lanczos 3 AR
iSunrise
9th April 2013, 21:54
Yes. Otherwise it would say "(says bitstream)" or "(says upstream)", depending on where madVR got the information from.
Ok, thanks for the confirmation. I just couldnīt believe it, but it seems that some retail Blu-Rays (even from major studios) are just not flagged for some reason (lazyness?), then.
Another question regarding madVR smoothness and the internal frame rate/display mode switcher:
If I have the option to choose an extremely close approx. refresh with very small deviations on my monitor to the native frame rates like 23.976fps, 25fps or 29.970fps AND also a multiple for all of them, what would I go for? Iīm asking because it seems my Eizo LCD replacement to my surprise seems to have an updated firmware with extremely good sync over DVI to a lot of common frame rates that donīt show any juddering or flickering at all and some that are not even listed in the manual/spec sheet.
These are listed (1080p):
60p, 59,9p, 50p, 48p, 47,8p and 24p
I have successfully tested (1080p):
60p, 59.94p, 50p, 48p, 47.95p, 30p, 29.97p, 25p, 24p and 23.976p
As I understand it, madVR should have a harder time to achieve smooth playback with multiples rather than native frame rates, because it needs to show some frames more often. On the other hand, if that multiple is a very close match, does that give me any additional benefits if I donīt see any flickering or juddering at all already? Like a better perception to the naked eye? On older CRT-like tubes, I wouldīve went with multiples, because of the nasty flickering.
turbojet
9th April 2013, 23:00
The cause of the problem will be the static composition rate. I suppose it's always the refresh rate of the primary monitor? Unfortunately the composition rate is totally out of madVR's control, so there's nothing I can do about it. The same problem should occur with any other renderer, too.
With extended displays EVR has the same problem and it uses the primary displays composition rate. Disabling composition fixes this, is there a way to ignore composition in this type of situation with madvr? If not, overlay and FSE doesn't have the issue. Could options be added to overlay and FSE to enable when using extended displays with different refresh rate?
However switching from one display to another with different refresh rates, evr handles fine, madvr doesn't and it uses the first displays composition rate. This is the first change in the log from yesterday. Maybe this could be resolved by adding a check when refresh rate changes?
edit: DwmSetWindowAttribute (http://msdn.microsoft.com/en-us/library/aa969524%28v=vs.85%29.aspx) can apparently disable aero only on specific windows.
Here's a log (http://www.sendspace.com/file/x8no4e) for display changer not working after using cru. nvidia CP and nircmd works fine.
edit2: OTOH if aero peek worked with overlay I'd use it most of the time. Is this possible?
Have you tried ReClock ?
There you can force detection of the secondary Display.
I just tried automatic(default), force primary and force secondary, it didn't have any effect.
Dodgexander
10th April 2013, 05:25
I always find it amazing madshi that you take days off, yet when back quote EVERY SINGLE post people have made. Impressive stuff.
I, like others would really love a way to donate.
ryrynz
10th April 2013, 05:30
I, like others would really love a way to donate.
He's mentioned quite a few times that this is a possibility after 1.0, or that there may even be paid version that offers additional functionality.
1.0 could still be a year or so away based upon previous release times.
Niyawa
10th April 2013, 06:30
He's mentioned quite a few times that this is a possibility after 1.0, or that there may even be paid version that offers additional functionality.
1.0 could still be a year or so away based upon previous release times.
Unless madshi speeds up the development, I would say we can wait for a 1.0 in late of 2014. He also takes a 2-3 months break from madVR from time to time.
dansrfe
10th April 2013, 06:35
Unless madshi speeds up the development, I would say we can wait for a 1.0 in late of 2014. He also takes a 2-3 months break from madVR from time to time.
Do you really expect him to work continuously, without break, on madVR? He has other priorities you know.
ryrynz
10th April 2013, 07:56
Do you really expect him to work continuously, without break, on madVR? He has other priorities you know.
I didn't want that comment to turn into a guessing game, it's really not worth discussing, it's done when it's done :p
RamGuy
10th April 2013, 12:24
Does anyone have any idea how a Intel i5-4570R, i5-4670R or a i7-4770R with the new Haswell HD 5200 (GT3e) will perform with MadVR? Might consider a Mini-ITX Media Center running Media Browser + MPC-HC if the performance is good enough.
leeperry
10th April 2013, 13:15
Thanks DragonQ, I get 73% load with your sample.
I've also found a sample here (http://forum.doom9.org/showpost.php?p=1608554&postcount=16714) - 91% load.
Yes, Jinc3 AR for both on my 1080p monitor @ 60Hz.
Tests were performed with smooth motion disabled.
OK, thanks again for the testing! so does that 91% load stutter?
I'm a little surprised as a 660 also gave 30% on 720p@1080p when Xaurus tried it (http://forum.doom9.org/showpost.php?p=1598453&postcount=15165)(and 48% on interlaced PAL DVD (http://forum.doom9.org/showpost.php?p=1598462&postcount=15168)).
Hopefully you both tested a 16/9 720p movie and not 2.40, and I know madshi also added optimized code for fixed ratios...
And you were using CUVID decoding in LAV, right?
Anyway if your 91% load on that 1440*1080@29.97fps "worst case scenario" sample doesn't stutter then I guess I might just snag one of those <100€ 650Ti's after all :p
yeah 60fps is tough, if i use jinc3 luma, i get 91%gpu usage with my gtx 650 which means lots of dropped frames, so when i watch 60 fps video i just change it to lanczos 3 AR
non-Ti 650? Yes, I guess this board must really suffer on J3AR :o
I'm getting tired of constantly switching scalers, I just wanna leave them both on J3AR permanently.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.