madVR - high quality video renderer (GPU assisted)

[Demonik]

Yes, 0.86.3 behaves like 0.85.4, i've assigned a key to source color control reset and .. it works, i get a normal picture on the "bad" versions. I haven't made any other settings, all were default. weird.
Ok. tested the filename and path thingie. the files were in a folder named "Men in Black 1997" turns out that if i change the 1997 to some other value it changes the source .. black level?

[madshi]

OMG, yes, "Black 1997" gets treated as a valid tag, changing the black level of the video to 1997. Obviously that doesn't make much sense. But any "someTag someValue" combination is accepted as a file name tag. And "black" is a supported tag name. If you put the 1997 in brackets like "Men in Black (1997)", the problem should go away. That's also how IMDB names movies and how I'm storing movies on my server. Well, I'm glad we got this mystery solved.

Now the question is: Should I require a "tag=value" syntax? Currently I support "tag=value", "tag:value" and "tag value". And "black" is a supported tag.

[Demonik]

Well that is not up to me :D but i'm also glad we solved this one.
It's not hard for me (now) to reset source color controls if i'm forced to play a file from such a folder.
Thank you so much!

[Qotscha]

Now the question is: Should I require a "tag=value" syntax? Currently I support "tag=value", "tag:value" and "tag value". And "black" is a supported tag.

I think it would be good to require "tag=value" syntax to avoid confusions. For example, I use file names like "Program name 2013.11.11 21.00" for TV recordings, so requiring "tag=value" syntax would decrease the probability of encountering problems with accidental tags quite much.

[DragonQ]

OMG, yes, "Black 1997" gets treated as a valid tag, changing the black level of the video to 1997. Obviously that doesn't make much sense. But any "someTag someValue" combination is accepted as a file name tag. And "black" is a supported tag name. If you put the 1997 in brackets like "Men in Black (1997)", the problem should go away. That's also how IMDB names movies and how I'm storing movies on my server. Well, I'm glad we got this mystery solved.

Now the question is: Should I require a "tag=value" syntax? Currently I support "tag=value", "tag:value" and "tag value". And "black" is a supported tag.
Hahaha.

Would it not be more sensible to only scan for tags inside square brackets? For example:

Men In Black [1997, 1080p24, 5.1]

[XeoneR]

Have you tried the different rendering modes (windowed, overlay, fullscreen exclusive mode)?
Is the CPU consumption equally high in all of them?
Overlay isn't available to me. But in general yes.

It's getting better though.
I've overclocked my stuff and checked drivers.
Also i've completely solved the previous issues.

Thank you for the best renderer and your kind support.

[turbojet]

Found a video that crashes with deint=ivtc and potplayer but 'send bug report' opens a blank browser window with mailto: but nothing happens. Is it reporting?

Concerning name tags, : isn't allowed in windows filenames afaik. = is such an uncommon tag that it makes sense. [] are fairly common for year.

Would it make sense to deband after downsizing to lower gpu load?

[Werewolfy]

It's a pretty mean example, but I can see what you mean. When frame stepping through the fade in, the first few frames are quite washed out with the "high" setting. The remaining frames of the fade in show little difference between "low" and "high", though. And in motion I'm not sure I see much of a difference, either. There's probably always a sample which works bad with a different setting. I could probably find a sample which with "medium" setting would still show banding during a fade in/out while it wouldn't show banding with "high". With such a sample "high" would look better. So which is the better overall setting? I'm not really sure.

Opinions from other users welcome, as well.

In motion I can see the difference between medium and high. The face appears without any details and is very smooth with high.

But I have a very weird issue with this new feature. When I'm watching a movie in 24hz, I get frames dropped when I activate a different strength for fade in/out. It happens only in exclusive mode. It doesn't happen in windowed mode or in 60hz mode.

[Boltron]

Hahaha.

Would it not be more sensible to only scan for tags inside square brackets? For example:

Men In Black [1997, 1080p24, 5.1]

Noooo, I use [] in my naming convention.

[MistahBonzai]

I can reproduce the problem. However, playback still seems perfectly smooth on my PC. It's possible that this is a false alarm in the debug OSD. I'll investigate.

Yup..I don't have visual indication of actual dropped frames. CPU useage dosen't increase and it's limmited to FSE mode.

[agustin9]

OMG, yes, "Black 1997" gets treated as a valid tag, changing the black level of the video to 1997. Obviously that doesn't make much sense. But any "someTag someValue" combination is accepted as a file name tag. And "black" is a supported tag name. If you put the 1997 in brackets like "Men in Black (1997)", the problem should go away. That's also how IMDB names movies and how I'm storing movies on my server. Well, I'm glad we got this mystery solved.

Now the question is: Should I require a "tag=value" syntax? Currently I support "tag=value", "tag:value" and "tag value". And "black" is a supported tag.
tag=value to avoid confussions i think

[zero9999]

Now the question is: Should I require a "tag=value" syntax? Currently I support "tag=value", "tag:value" and "tag value". And "black" is a supported tag.

Storing this kind of information in file names at all is not only error prone, but also very ugly. How about using NTFS alternate data streams instead?

The user would then simply run Add-Content V:\myvideo.mkv -Stream madVr "deint: ivtc" to add tags while the filename is kept clean.

[Razoola]

Personally I think it needs something like this in the filename so there can be no mistakes....

'Men in Black madVR[tags here]'

Basically the need for 'madVR' to be written in the file name.

[romulous]

Storing this kind of information in file names at all is not only error prone, but also very ugly. How about using NTFS alternate data streams instead?


ADS are NTFS only, say goodbye to using tags on non-NTFS drives if madshi implements that. For me, ADS is just an added complication, and shouldn't be done - needing to use another command to enter the tags when a simple rename of the file is all that is required as currently (and with renaming, you can see the tags without having to check the ADS as an added side benefit).

As I too use [ ] in my filenames, I would vote for '='

[madshi]

Ok, tags will require "=" in the next build.

Found a video that crashes with deint=ivtc and potplayer but 'send bug report' opens a blank browser window with mailto: but nothing happens. Is it reporting?
No. For some reason uploading the bug report seems to fail in your case, and mailto seems to fail, too. Your best bet is to not even try sending, but just close the bug report window. You should then get a crash report file on your desktop which you can PM to me.

IVTC currently only officially supports 8bit 4:2:0. Maybe the video you tested with had a different format?

Would it make sense to deband after downsizing to lower gpu load?
Hmmmmm... Good question. I believe all "artifact removal" algorithms should ideally be run on the unscaled source. But then, running debanding after downscaling might work fine, too.

In motion I can see the difference between medium and high. The face appears without any details and is very smooth with high.
Ok. Would still like to get feedback from other users, as well?

But I have a very weird issue with this new feature. When I'm watching a movie in 24hz, I get frames dropped when I activate a different strength for fade in/out. It happens only in exclusive mode. It doesn't happen in windowed mode or in 60hz mode.
Already been reported. Will be fixed in the next build.

How about using NTFS alternate data streams instead?
Wouldn't work for me. I'm storing my movies on a Linux based server, using ReiserFS. Maybe I'll think of an alternative tagging solution in some future version, but not now.

[DragonQ]

Storing this kind of information in file names at all is not only error prone, but also very ugly. How about using NTFS alternate data streams instead?

The user would then simply run Add-Content V:\myvideo.mkv -Stream madVr "deint: ivtc" to add tags while the filename is kept clean.

Oh yes people will love having to edit videos via the command line. :rolleyes:

This is a Windows application, not a Linux one.

[DragonQ]

Noooo, I use [] in my naming convention.

As I too use [ ] in my filenames, I would vote for '='

I'm curious as to why you'd use square brackets in file names for anything other than metadata? I don't know of any TV or film titles using square brackets, only normal ones.

Requiring = between tag name and tag value seems sensible.

[romulous]

I'm curious as to why you'd use square brackets in file names for anything other than metadata? I don't know of any TV or film titles using square brackets, only normal ones.


I often change the filenames of files so that they make more sense to me - when I do, if I want to keep the original filename for some reason (the original filename can be important, so sometimes I do want to keep it, sometimes I don't), I put the original filename in square brackets at the end. I've used this same system for years, so I have built up a large number of files named in this way.

So, the file "foo.bar" (which tells me nothing about what the file actually is) would become "More descriptive name [foo].bar" for example.

[HeadlessCow]

Ok, tags will require "=" in the next build.
Wouldn't work for me. I'm storing my movies on a Linux based server, using ReiserFS. Maybe I'll think of an alternative tagging solution in some future version, but not now.

While not every video format supports arbitrary tags, MKV does for sure and MP4 and AVI, I believe, do as well and those formats probably comprise 90% of the media that madvr users have. It would perhaps be useful to define a set of tags and read them directly out of the file rather than the filename.

[madshi]

As I said, I might look into alternative tagging solution in the future, but not now.

[6233638]

I believe all "artifact removal" algorithms should ideally be run on the unscaled source. But then, running debanding after downscaling might work fine, too.I actually did some testing on this, and with low resolution videos, and high strength debanding, it was actually beneficial as far as artifacts are concerned, to upscale externally and then have madVR process the image. That way you have pixel-sized "dither/noise" rather than giant upscaled noise. (I know you said you don't dither, but it's done something like dithering to smooth out those gradients)

However, debanding was considerably less effective after doing this - it needed much higher settings to work, and some things just weren't seen as gradients.

[Boltron]

I'm curious as to why you'd use square brackets in file names for anything other than metadata? I don't know of any TV or film titles using square brackets, only normal ones.

Requiring = between tag name and tag value seems sensible.

I do use them for metadata. I use it to identify the video and audio streams for my own purposes. For example [BlurayRip - DTSMA 7.1] or [1080p@12.3 - DTS].

[DarkSpace]

I actually did some testing on this, and with low resolution videos, and high strength debanding, it was actually beneficial as far as artifacts are concerned, to upscale externally and then have madVR process the image. That way you have pixel-sized "dither/noise" rather than giant upscaled noise. (I know you said you don't dither, but it's done something like dithering to smooth out those gradients)

However, debanding was considerably less effective after doing this - it needed much higher settings to work, and some things just weren't seen as gradients.
How about just "scaling" the debanding values from video size to output size and applying debanding after scaling?
Can the debanding range (what pixels are looked at) be scaled for x and y dimensions separately? Can the AngleBoost algorithm be adapted to this? How about the banding/detail decision?

Does it perhaps even make sense to specify the debanding options for a fixed size and always scale from that size to the video (or output) size? (I know, that idea might just as well be incredibly bad.)

[turbojet]

No. For some reason uploading the bug report seems to fail in your case, and mailto seems to fail, too. Your best bet is to not even try sending, but just close the bug report window. You should then get a crash report file on your desktop which you can PM to me.

IVTC currently only officially supports 8bit 4:2:0. Maybe the video you tested with had a different format?

I updated the bug tracker with the crash report. Switching madvr to debug was the only way to get the log. http://bugs.madshi.net/view.php?id=125

Hmmmmm... Good question. I believe all "artifact removal" algorithms should ideally be run on the unscaled source. But then, running debanding after downscaling might work fine, too.

I remember when I messing with avisynth resizing and f3kdb there wasn't a noticeable difference whether it was pre or post resize. Maybe worth checking out to lessen load?

Ok. Would still like to get feedback from other users, as well?

It doesn't appear noticeably faster for me.

[Megalith]

This might be a silly question, but does adding a 3D LUT to madVR override your Windows color profile completely, or are its settings combined with the color profile that you have set in Windows color management?

[dansrfe]

This might be a silly question, but does adding a 3D LUT to madVR override your Windows color profile completely, or are its settings combined with the color profile that you have set in Windows color management?

Ticking "disable GPU gamma ramps" under 'Calibration' means that Windows color profile will be disabled. If you've selected a 3DLUT then that will be applied after the Windows color profile if not disabled. It's better to calibrate without the Windows color profile in the middle and disable it upon playback if you're using a 3DLUT.

[Gagorian]

@madshi

Nice work on the debanding algorithm. The only issue I've found (like someone else already mentioned) is that subtitles blink occasionally, I normally use xysubfilter but if I download subtitles through the MPC-HC subtitle download interface it's always loaded into the ISR :( Could the backrender feature be activated/deactivated based on subtitle renderer?

Also unfortunately my iGPU on the HTPC (A10-5700) isn't powerful enough to run Jinc3-AR combined debanding in some scenes (without debanding it was fine). I'm considering getting the R9 270 GPU, does anyone have any other suggestions?

P.S.
Awaiting the convergence adjustment feature like a kid for christmas ;)

[Ver Greeneyes]

This might be a silly question, but does adding a 3D LUT to madVR override your Windows color profile completely, or are its settings combined with the color profile that you have set in Windows color management?
Windows does not automatically apply installed color profiles to applications (though GDI can opt into this I think) - so the only thing that affects madVR is the videoLUT that tends to get loaded along with the profile.

madshi: How does "disable GPU gamma ramps" interact with the -a and -H options of collink?
1) For a 3DLUT created with -a, does madVR load the appended linear gamma ramp if "disable GPU gamma ramps" is not checked?
2) For a 3DLUT created with -H, does madVR load the appended gamma ramps if "disable GPU gamma ramps" is checked?

In other words: is "disable GPU gamma ramps" an accurate description of what the setting does (in the light of -a and -H), or would it be better named "override GPU gamma ramps" or something else?

(personally I don't run into this problem because I don't use -a or -H for my 3DLUT, since I want the videoLUT active while I'm multitasking, but it seems confusing)

[kasper93]

Nice work on the debanding algorithm. The only issue I've found (like someone else already mentioned) is that subtitles blink occasionally, I normally use xysubfilter but if I download subtitles through the MPC-HC subtitle download interface it's always loaded into the ISR :( Could the backrender feature be activated/deactivated based on subtitle renderer?

It's know issue, and its ISR bug. Moreover I can say that one day it will be fixed on MPC-HC side. For now if you want to use ISR you have two options either disable subtitle queue in MPC-HC settings or disable madVR "fading" feature by setting both debanding options to the same preset.

If you want to use other subtitle renderer, you need to download subs and load them by XySubFilter there is no other option at the time.

[huhn]

Windows does not automatically apply installed color profiles to applications (though GDI can opt into this I think) - so the only thing that affects madVR is the videoLUT that tends to get loaded along with the profile.

madvr outrput is changed by colorprofiles and disable gpu ramps disabled this. in window mode the hole desktop is srgb then.

and nearly all games are affected too

[flashmozzg]

It's know issue, and its ISR bug. Moreover I can say that one day it will be fixed on MPC-HC side. For now if you want to use ISR you have two options either disable subtitle queue in MPC-HC settings or disable madVR "fading" feature by setting both debanding options to the same preset.


I heard that MPC-HC is switching to XySubFilter in the next release.

[sneaker_ger]

It's know issue, and its ISR bug. Moreover I can say that one day it will be fixed on MPC-HC side. For now if you want to use ISR you have two options either disable subtitle queue in MPC-HC settings or disable madVR "fading" feature by setting both debanding options to the same preset.

If you want to use other subtitle renderer, you need to download subs and load them by XySubFilter there is no other option at the time.
Not denying that there's a bug in ISR but why should it affect madVR? Why would madVR's fade debanding feature affect the way it ask for ISR's subs?

[Asmodian]

madvr outrput is changed by colorprofiles and disable gpu ramps disabled this. in window mode the hole desktop is srgb then.

and nearly all games are affected too

madvr output is changed by color profiles only so far as everything in Windows is; gamut correction does not apply. Windows assumes you have a display with an sRGB gamut but it can load part of an ICC profile into the video card for a calibrated gamma curve for red, green, and blue (the videoLUT). All this does is correct the white point and grey scale. This is why a wide gamut display is a bad thing unless you are on a Mac or using an application which supports color correction on its own (like MadVR :D).

Games are only not affected when they load their own LUT into the video card. I have no idea why some games do this and I hate them. :p

[Ver Greeneyes]

madvr outrput is changed by colorprofiles and disable gpu ramps disabled this. in window mode the hole desktop is srgb then.

and nearly all games are affected too
They are affected by the videoLUT calibration, but not by the rest of the profile. It's pretty easy to test this with a profile that simply inverts all the colors - you'll see that madVR doesn't care, but EVR with color management enabled does. For proper color management in madVR you need a 3DLUT.

Games are only not affected when they load their own LUT into the video card. I have no idea why some games do this and I hate them. :p
Yeah, it's annoying. I use Monitor Calibration Wizard to keep my LUT loaded (games that do reset the LUT generally do it only once, or only when you alt-tab into them), but what I really want is an overlay that loads a madVR 3DLUT for all applications :) They all assume something like sRGB anyway, so why not?

[madshi]

I actually did some testing on this, and with low resolution videos, and high strength debanding, it was actually beneficial as far as artifacts are concerned, to upscale externally and then have madVR process the image. That way you have pixel-sized "dither/noise" rather than giant upscaled noise. (I know you said you don't dither, but it's done something like dithering to smooth out those gradients)
Oh well, the algorithm doesn't really use anything like dithering. It basically just takes the average of 4 surrounding pixels of a random distance. But I guess if the debanding correction amount is high enough, it could actually end up looking like dithering.

However, debanding was considerably less effective after doing this - it needed much higher settings to work, and some things just weren't seen as gradients.
Well, I guess that's got to be expected, but I guess some adjustments to the algorithm to take the zoom factor into account should be possible without negatively impacting detail loss.

Do you have a couple of low resolution samples where debanding in the source resolution is noticeably worse than debanding after external scaling? Maybe that could convince me to look into this.

How about just "scaling" the debanding values from video size to output size and applying debanding after scaling?
Can the debanding range (what pixels are looked at) be scaled for x and y dimensions separately? Can the AngleBoost algorithm be adapted to this? How about the banding/detail decision?
AngleBoost should not be affected, nor any of the other thresholds. However, after upscaling, the max random distance of the 4 surrounding pixels should be increased.

I updated the bug tracker with the crash report. Switching madvr to debug was the only way to get the log.
No crash report from madVR? So the crash is in potplayer and not in madVR? That might be hard to figure out, but I'll have a look when I find some time.

It doesn't appear noticeably faster for me.
What does speed have to do with anything? The topic at hand was totally unrelated to that.

I'm considering getting the R9 270 GPU, does anyone have any other suggestions?
This question is asked every couple of pages.

Awaiting the convergence adjustment feature like a kid for christmas ;)
Haha. Yes, I'm looking forward to that myself. And to some other features I'm planning which should benefit my CIH setup.

Not denying that there's a bug in ISR but why should it affect madVR? Why would madVR's fade debanding feature affect the way it ask for ISR's subs?
The same reason why I have to hide the MPC-HC "pause" OSD message: If I ask the ISR to rerender an older frame again, the ISR misbehaves. And the "fade in/out" detection of the debanding algorithm does require the first few frames of the fade in/out to be rerendered. There are different workarounds for this problem available, see the other posts.

[sneaker_ger]

So you don't do fade detection before the rendering?

[leeperry]

Awaiting the convergence adjustment feature
FWIW This PS script (http://www.homecinema-fr.com/forum/post172727110.html#p172727110) can do it, using 6 different zones at that.

[turbojet]

I updated the bug tracker with the crash report. Switching madvr to debug was the only way to get the log.

No crash report from madVR? So the crash is in potplayer and not in madVR? That might be hard to figure out, but I'll have a look when I find some time.


It's a madvr crash but it doesn't create a crash report on desktop when I press 'close application' check your pm for screens of the crash.



It doesn't appear noticeably faster for me.

What does speed have to do with anything? The topic at hand was totally unrelated to that.

It would be really nice if this forum nested previous msg's without a bunch of work but I thought it was asking for opinions on the last part of http://forum.doom9.org/showthread.php?p=1652721#post1652721

[e-t172]

Yeah, it's annoying. I use Monitor Calibration Wizard to keep my LUT loaded (games that do reset the LUT generally do it only once, or only when you alt-tab into them)

Personally, I use a scheduled task that runs xcalib (http://xcalib.sourceforge.net/) every minute. That does the trick. There are games (e.g. Crysis) that reset the LUTs at every level change, in which case my scheduled task resets it back to the real calibration less than a minute later.

but what I really want is an overlay that loads a madVR 3DLUT for all applications :) They all assume something like sRGB anyway, so why not?

Yes. Yes please. Unfortunately we all know that's not gonna happen; it could be implemented in the driver but I don't think NVidia/ATI care. Theoretically it's not that hard for application developers to Do The Right Thing themselves; there are lots of libraries available to do ICC transformations (such as the easy-to-use LittleCMS), and even a Windows API. It would be great if the developers of the main game engines (e.g. Unreal Engine, Cryengine, Source, Frostbite...) could generate a transformation using these libraries and then store the 3DLUT on the GPU for real-time correction of the game colors (like madVR), but could luck convincing them to spend time to implement that.

[mzso]

I'm not aware of such a problem. The Potplayer developer didn't talk to me about this.

He actually talks to anyone without being asked? :)
Anyway he wasn't particularly helpful. He just told me to "Use old player~~"

[andybkma]

Does reducing the number of windowed mode backbuffers and/or the number of exclusive mode prepresented frames help in any way?

madshi, I have since narrowed down the culprit to the Avisynth+ dll file which I started using for realtime script sharpening right around the time I started using the new deband mVR. Replacing the avisynth+ dll file with the original 2.6 Alpha 5 dll and the problem hasn't reoccurred in two days. Guess I will let the avisynth+ thread know about this problem. Cheers

[DarkSpace]

How about just "scaling" the debanding values from video size to output size and applying debanding after scaling?
Can the debanding range (what pixels are looked at) be scaled for x and y dimensions separately? Can the AngleBoost algorithm be adapted to this? How about the banding/detail decision?AngleBoost should not be affected, nor any of the other thresholds. However, after upscaling, the max random distance of the 4 surrounding pixels should be increased
I see. My main concern was content with non-1:1 scaling (e.g. DVDs). I must admit, though, that after reading your answer, I realized that the boost itself should indeed remain unchanged, as only the angles themselves are changing in that case.

[Ver Greeneyes]

Yes. Yes please. Unfortunately we all know that's not gonna happen; it could be implemented in the driver but I don't think NVidia/ATI care. Theoretically it's not that hard for application developers to Do The Right Thing themselves; there are lots of libraries available to do ICC transformations (such as the easy-to-use LittleCMS), and even a Windows API. It would be great if the developers of the main game engines (e.g. Unreal Engine, Cryengine, Source, Frostbite...) could generate a transformation using these libraries and then store the 3DLUT on the GPU for real-time correction of the game colors (like madVR), but could luck convincing them to spend time to implement that.
I was thinking of something like a d3d9.dll hook for (Direct3D 9) games and maybe a DWM hack for windowed applications. Theoretically it shouldn't even be that hard! I haven't gotten around to trying it myself though, so I shouldn't talk.

[madshi]

So you don't do fade detection before the rendering?
I do, but I only consider a fade a fade when it lasts at least 5 frames. So it's only after the 5th frame of a fade that I know that this really is a fade. So in that moment when that 5th frame runs through the fade detection algorithm, the previous 4 frames are usually already rendered. madVR is heavily multi-threaded. Everything works in parallel. The fade detection can't introduce a 5 frame delay. So it lets every frame pass until a fade is detected. At that point in time it has to go back and rerender the last 4 frames.

Of course it's not ideal to have to go back to rerender past frames. But it's the best solution I came up with. Every other solution had worse disadvantages than this one.

FWIW This PS script (http://www.homecinema-fr.com/forum/post172727110.html#p172727110) can do it, using 6 different zones at that.
Yes, but with a rather bad quality. On a quick check I think if the 6 zones noticeably differ with that PS script, you might actually see the zone boundaries. Furthermore that script doesn't work in linear light, so you'll get discoloration in pixel on/off test patterns. Finally, the convergence correction seems to be done with bilinear filtering which will soften up the image. madVR's convergence correction should not have any of these problems (I hope).

It would be really nice if this forum nested previous msg's without a bunch of work but I thought it was asking for opinions on the last part of http://forum.doom9.org/showthread.php?p=1652721#post1652721
So when you say "It doesn't appear noticeably faster for me" what do you mean exactly? That the face doesn't appear faster for you with Werewolfy's video sample, when using "medium" instead of "high" debanding for fade in/outs? Or are you talking about the madVR rendering times? Or what?

The feedback I was hoping to get is whether I should use "medium" or "high" as a default option for debanding during fade ins/outs.

He actually talks to anyone without being asked? :)
He did contact me in the past, at least one time, maybe twice. Don't remember.

[sneaker_ger]

The fade detection can't introduce a 5 frame delay.
Why not? Or is this because of OSD messages or similar yet again? Personally I think fluid playback should have the highest priority.

[ryrynz]

Why not?


Me thinks it would be because of the heavily threaded nature madshi mentioned.


Personally I think fluid playback should have the highest priority.

From the sounds of it, this core MadVR feature (fluid playback) is not compromised by having to rerender four frames.

[sneaker_ger]

Me thinks it would be because of the heavily threaded nature madshi mentioned.
Another buffer does not hurt multi-threading. On the contrary the current solution hurts performance as evidenced by user reports and the nature of the solution. It will only hurt multi-threading under additional requirements I'm currently unaware of. Madshi says he "can't" have another delay but the multi-treading answer does not explain that.

From the sounds of it, this core MadVR feature (fluid playback) is not compromised by having to rerender four frames.
It's not compromised if your system is fast enough.

[madshi]

Why not? Or is this because of OSD messages or similar yet again?
Has nothing to do with OSD. Adding a 5 frame delay would mean that the rendering queue would never reach its max. E.g. with a rendering queue of 16 frames, if you have a 5 frame delay, the rendering queue would never fill more than 11/16. I think we both agree this would be a bad solution?

What I could do is introduce a separate queue just for fade detection. So the fade queue would then be 5 frames longer than the rendering queue. E.g. the fade queue would then be 21 frames long and the render queue would be 16 frames long. In that case the 5 frame delay would still allow the render queue to fill completely. But this design would require the upload queue (and the decoder queue) to be 5 frames longer, too, which would (together with the new fade queue) increase the GPU RAM consumption.

With the current solution the render queue is always nicely filled, except in the very moment when the fifth frame of a fade is detected. In that moment the render queue temporarily goes down to 11/16, but fills up quickly again. All this without any increased GPU RAM consumption.

I'm not sure if it makes sense to discuss this in detail. Trust me, I've thought all possibilities through and chosen the best possible implementation. The one and only problem with this implementation is that it makes problems with the ISR. But that's really a bug in the ISR, and I'm not willing to use an inferior render design just to work around an ISR bug. If you insist on using the ISR, either disable the fade detection, or disable the ISR queue, or ask the MPC-HC/BE devs to fix the ISR bug. Or make the switch to XySubFilter. Many options for you.

Personally I think fluid playback should have the highest priority.
I've chosen the solution which would give the highest queue saturation with the lowest GPU RAM consumption. Which in the end aims at the most reliable/fluid playback.

On the contrary the current solution hurts performance as evidenced by user reports
Huh!? Where did you get *that* impression from? If you're talking about the reported frame drops, that's not a performance problem, but a simple logic bug in the current build, which is already fixed in my sources, and which btw never introduced any visible stuttering. The simple bug was that a smooth motion blended frame which should have been deleted by the fade detection wasn't deleted. So there suddenly were two blended frames for the same situation. So one was dropped, without causing a visual problem. So the only real "problem" was that the OSD reported a dropped frame. But the dropped frame was superfluous, anyway.

It's not compromised if your system is fast enough.
The speed of the system got nothing to do with it.

[sneaker_ger]

I was indeed thinking about just adding an additional queue for the fade and in turn increase its length. I didn't think about the RAM and thought you just didn't feel like adding yet another queue or didn't want to make it too long. I wasn't affected, just wondering.

Huh!? Where did you get *that* impression from? If you're talking about the reported frame drops, that's not a performance problem, but a simple logic bug in the current build, which is already fixed in my sources, and which btw never introduced any visible stuttering. The simple bug was that a smooth motion blended frame which should have been deleted by the fade detection wasn't deleted. So there suddenly were two blended frames for the same situation. So one was dropped, without causing a visual problem. So the only real "problem" was that the OSD reported a dropped frame. But the dropped frame was superfluous, anyway.
Yes, I mixed that up.

I've chosen the solution which would give the highest queue saturation with the lowest GPU RAM consumption. Which in the end aims at the most reliable/fluid playback.
Well, I thought queues are there to ensure fluid playback, i.e. having some security net/buffer for avoiding dropped frames. Resetting a queue fully or partly/reprocessing frames means decreasing that security and results in more dropouts on average even if most users aren't affected and it can be worked-around/turned off easily. Maybe I'm missing something.

[Vyral]

Hi everyone,
I currently use the sRGB profile on my monitor and the default settings in Windows Color management (No ICC profile). I've set "this display is already calibrated" (while it's not) with BT.709 and pure power curve 2.20 in the calibration tab. However, some guides about calibration advice to set pure power curve to 2.40 with sRGB. Is it true or not ?
Another question : should I keep my actual settings or change for "disable calibration controls for this display" in the calibration tab and enable gamma processing in the color & gamma tab ?
Thanks for your help.