madVR - high quality video renderer (GPU assisted)

[madshi]

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

Originally Posted by dansrfe

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]

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]

Originally Posted by madshi

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

Originally Posted by italospain

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)

Originally Posted by italospain

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]

Originally Posted by 6233638

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]

Originally Posted by madshi

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

Well, there's still quite a bunch of ppl on XP: http://www.netmarketshare.com/operat...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.

Originally Posted by madshi

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

[DragonQ]

Originally Posted by leeperry

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

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]

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]

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?

Originally Posted by madshi

@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² after calibration is still respectable for an IPS).

[ryrynz]

Originally Posted by madshi

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.

Originally Posted by madshi

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]

Originally Posted by DragonQ

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 works, I wouldn't expect it to be a concern for most people.

[6233638]

Originally Posted by italospain

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)

Originally Posted by italospain

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)

Originally Posted by iSunrise

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]

Originally Posted by italospain

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.

Originally Posted by italospain

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.

Originally Posted by 6233638

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

Originally Posted by 6233638

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.

Originally Posted by 6233638

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

Originally Posted by 6233638

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

Originally Posted by 6233638

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.

Originally Posted by 6233638

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.

Originally Posted by ryrynz

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.

Originally Posted by iSunrise

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.

Originally Posted by iSunrise

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.

Originally Posted by 6233638

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]

Originally Posted by 6233638

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]

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

Originally Posted by e-t172

Well, considering that's how traditional cinema projection 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]

Originally Posted by madshi

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.

Originally Posted by madshi

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)


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:


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.

Originally Posted by madshi

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)

Originally Posted by madshi

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.

Originally Posted by madshi

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)

Originally Posted by turbojet

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]

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]

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]

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.