madVR - high quality video renderer (GPU assisted)

[cyberbeing]

What do you mean with "moving back"? As far as I remember, madVR has always used a TV levels rendering pipeline. Going PC levels would mean either losing BTB/WTW, or alternatively I'd have to use floating point textures for all rendering steps, which would make things slower rather than faster. The main reason for using a TV level rendering pipeline is that I don't have to use floating point textures to maintain BTB/WTW, to save performance!!
No, at least not from what I remember. You originally started out with 3DLUTs outputting PC range. Your decision to migrate the entire render chain to TV range + BTB/WTW and shaders came much later in madVR development, and actually hurt performance quite a bit back when I had my 7800GTX 512. On my GT440, 16bit float textures seem almost as cheap as 8bit integer, things only start to get slow with 32bit floats which by comparison are ~3x slower. Its the shader operations rather than the textures that are the main cause of slowdowns.

Sorry, but I'm pretty sure you misunderstood him completely. AFAIK, the issues he ran into had nothing to do with the 3DLUT being TV range, I believe.
I think you misunderstood him, but whatever. This problem with elevated BTB with Argyll 3DLUTs is unique to madVR, and from what I can tell is quite similar to what causes leeperry's BTB MPC-HC shader problems. He stated pretty clearly that he could only properly resolve it if madVR was using PC range output 3DLUTs, in similar fashion to madVR 0.61 or otherwise.

As to performance, as I said above, going PC range would either mean losing BTB/WTW, or using floating point textures, the latter of which would make things slower instead of faster.
In old versions of madVR, it was implemented as such that BTB/WTW was eliminated rather early in the render chain. Though as mentioned above, 16bit floats texture storage is fast at least on NVIDIA GPUs, its only the shader operations which are slow as far as I can tell. Overall I've never seen the usefulness of maintaining BTB/WTW throughout the entire processing chain if you are ultimately outputting 0-255 PC range.

Yes, it means losing a little bit of GPU performance, but it's not really a "night and day" difference, is it?

I could live with adding support for TV levels subtitles to the subtitle interface, if performance is so critical to you. I do wonder whether the added complexity is worth the small performance benefit. But I could live with it...
Let's just take a wait and see approach then. If we start getting a number of reports from people who can no longer use their normal settings in madVR+XySubFilter we can discuss adding support of TV level subtitles at that time.

Is there? What kind of GPU does that large subset of the user-base have? With bilinear scaling, most DX9 GPUs should be able to handle madVR ok, as far as I can see. I would think that with even Intel HD3000 already running madVR just fine, most users today should have GPUs that should handle madVR with bilinear filtering just fine?
Honestly I have no idea, I just see chatter occasionally on various web boards, since xy-VSFilter+madVR frequently get recommended together to the fansub crowd. This is usually the same group of people who have CPUs which can barely handle 720p 10bit H264 properly if at all. Many probably come from people using old laptops or Pentium 4 generation computers, but who knows.

Well, then let's collect some money and send it to him. A budget GPU is so cheap these days.
Yeah, I don't really know what's going on there, only that he's occasionally told me that debugging will have to wait because he doesn't have access to his madVR computer until XX date. It hasn't really caused any problems since most of the heavy coding can be done blind without constant testing, its only when there is a need for him to actively debug something in real-time.

Of course doing any processing in UHD costs more performance, but again, the simple TV -> PC -> TV conversion is so easy on any modern GPU that I don't expect any performance hit worth mentioning with mid-range or high-end GPUs in the near future, even with UHD.
I was talking about the mid-range and high-end GPUs of today which as far I as can gather really struggle with UHD scaling with any decent settings. It would be good to get some performance metrics on this once we release a XySubFilter beta.

Well, as I explained above, doing what you suggest would slow madVR down instead of speeding it up. I do know what I'm doing, you know, although you often seem to doubt that... ;)
Old versions of madVR which were texture heavy + 3DLUT instead of shader heavy + 3DLUT were faster though...

Hmmm... Just a thought: Try activating the trade quality for performance option "store custom pixel shader results in 16bit buffer instead of 32bit". That way the TV -> PC conversion for subtitle blending will use 16bit floating point textures instead of 32bit. That might help to get some performance back, on the cost of accuracy.
I already had the option enabled, and was under the impression that it was enabled by default? So all results I posted thus far were with 16bit buffers. Use of 32bit buffers seems to make things even slower.

The funny thing is that the madVR subtitle color correction practically comes for free. What costs performance is the conversion of the PC levels subs to TV levels.
Yeah, I'm actually surprised the cost is as large as it is. It's not possible to generate a hard-code 1D LUT or something to speed up these conversions, instead of doing them dynamically in shaders?

[cyberbeing]

@cyberbeing:

I've just looked through the subtitle interface. As you know, it does already contain a "TV" vs "PC" levels indicator. But currently madVR ignores what XySubFilter sets there, and madVR reports TV vs PC depending on whether the source was detected as fullrange or not. I think we do need to re-think the way we handle levels because currently it's a bit of a mess. I've taken for granted that XySubFilter always renders in PC levels, but looking at the interface, it's not clearly defined that way. Ok, "None" is defined as being fullrange. But anything else is flexible, and I think neither madVR nor XySubFilter handle the flexible part correctly right now. So I think we should restart a discussion on how to handle levels in the best way. I'm not happy with the interface right now in regards to levels because it's not clear enough how either provider or consumer should behave in all situations.

Do you agree that we should re-discuss this? If so, where should we do this discussion?

I don't know about SubRenderIntf.h, but during our discussions there was consensus that the interface was to be clearly defined as 0-255 RGB only. I don't think we really need to re-discuss this unless we were going to support TV-range 16-235 or something like AYUV.

Those level range tags are just for informative purposes, and not immediately relevant to the subtitle interface. They only define intended level range to use for YCbCr output by xy-VSFilter and similar transform filter renderers. At the time, you were quite insistent on it being included in the subtitle interface, because you wanted to mimic incorrect xy-VSFilter behavior in those cases where the subtitle and video were not using the same YCbCr level range. Issues like xy-VSFilter outputting TV-range YCbCr subtitles on a PC-range YCbCr video and vice versa.

[ajp2k11]

Thanks for the suggestion, tried it but same thing.

@Madshi,

I have 'auto-load subtitles' unchecked in MPC-HC when using the internal subtitle rendering but same thing...

EDIT: Remuxed one of the files I'm having problems with, removing the internal subtitle, after that it plays fine...

Blocking LAV splitter in MPC-HC and using Haali from CCCP instead and it works fine with subs and all...!?

[madshi]

Not 100% full, but "full enough" I'd say ;). Around 100/128 if I just play the video through a first heavy fragment. Though the 4-th test was made just by seeking into the middle of long heavy fragment, pausing to allow the CPU queue to fill up to 60-80/128, then releasing pause and observe how decoder's attempt to fill CPU queue (it fluctuates around 70-90) makes troubles sometimes for the renderer.
Well, so it seems uploading is the problem for you. I have the render and presentation threads at HIGHEST priority, and uploading at ABOVE_NORMAL priority. And the render and presentation threads should sit idle most of the time. So unless the decoder is running with ABOVE_NORMAL, too, the uploading thread should have priority over the decoding thread(s).

Have you tried different decoders? Maybe some are running at ABOVE_NORMAL and some at NORMAL?

EDIT: Remuxed one of the files I'm having problems with, removing the internal subtitle, after that it plays fine...
Well, that's interesting, but I have no explanation for that. And thus also no solution... :( You could try once again to use different subtitle renderers to see if it makes any difference...

Blocking LAV splitter in MPC-HC and using Haali from CCCP instead and it works fine with subs and all...!?
Weird. You could try talking to nevcairiel about this, but I bet he will be as confused about this as I am...

No, at least not from what I remember. You originally started out with 3DLUTs outputting PC range. Your decision to migrate the entire render chain to TV range + BTB/WTW and shaders came much later in madVR development, and actually hurt performance quite a bit back when I had my 7800GTX 512.
In old versions of madVR, it was implemented as such that BTB/WTW was eliminated rather early in the render chain.
I don't know where you pull that information from, but it's clearly wrong. I've just double checked with madVR 0.09, which is the oldest madVR build I still have on my PC, and it maintains BTB/WTW just fine. The rendering pipeline has *always* been TV levels. However, in versions prior to v0.62 madVR was using different 3dluts for PC and TV levels *output*. Since 3dlut processing and dithering are the last steps in the processing chain, that doesn't change anything, though. All the main processing was still in TV levels. The 3dlut input was also always TV levels, unless my memory is totally betraying me.

On my GT440, 16bit float textures seem almost as cheap as 8bit integer, things only start to get slow with 32bit floats which by comparison are ~3x slower. Its the shader operations rather than the textures that are the main cause of slowdowns.
I'm using 16bit integer textures by default, which have the benefit of using all their accuracy on the important 0..1 range. Yes, 16bit floats are relatively fast, too, but they stretch their accuracy over a *much* wider range, which means that in the area which counts the most (16-235) they have a much lower accuracy compared to 16bit integer. If I had to use floating point textures, I would have to go 32bit floating point by default, in order to not compromise accuracy. So the decision for me is not 16bit integer vs 16bit float, but it is 16bit integer vs 32bit float, and that's a quite big difference in performance.

Ok, if I went with floating point, people could compromise by using 16bit float instead of 32bit (trade quality for performance). They'd probably get identical performance to the current madVR logic, but with slightly faster subtitle rendering. On the negative side, they'd get less accuracy at the same speed as the current madVR logic. I think that's a bad compromise. Furthermore, if you look at the high quality option, I'd have to use float32 instead of int16, which costs twice the memory bandwidth. So the memory bandwidth cost of doing Jinc3 AR for a "no compromise" setup would double. All of that just to get a small boost in subtitle rendering performance? Sounds like a bad idea to me...

I think you misunderstood him, but whatever. This problem with elevated BTB with Argyll 3DLUTs is unique to madVR [...]. He stated pretty clearly that he could only properly resolve it if madVR was using PC range output 3DLUTs, in similar fashion to madVR 0.61 or otherwise.
If what you're saying is true then please explain to me why the eeColor box does not have this issue, although it is also using TV levels 3DLUTs (when using it for Blu-Ray/TV calibration)?

Furthermore, ArgyllCMS could make TV levels 3dluts behave identical to PC levels 3dluts by simply clipping BTB/WTW away. From a technical/scientific point of view, using a TV levels 3dlut with clipped BTB/WTW is identical to using a PC levels 3dlut.

From what I've read the recent problems with ArgyllCMS with BTB information suddenly becoming visible with weird colors was due to Graeme trying to add xvYCC support. And the same problem also occurred with the eeColor. I'm not sure if that is the problem with elevated BTB that you're talking about, though.

I was talking about the mid-range and high-end GPUs of today which as far I as can gather really struggle with UHD scaling with any decent settings.
True, but the reason they're struggling is the performance cost of high quality upscaling algorithms. Try bilinear scaling and things look quite different. Doing TV <-> PC conversions via shader math is not *that* costly with modern GPUs. Let's just do the math: Jinc3 (without AR) needs to read 36 input pixels to produce 1 output pixel. For each of those 36 input pixels Jinc also needs to access a Jinc 1dlut. Add to that a lot of shader math. For a UHD image that means 288 million source pixels need to be read, another 288 million 1dlut accesses, for 8 million output pixels. All of that per video frame. And this doesn't even include the AR filter.

Now let's compare a UHD TV <-> PC conversion to that: Such a conversion needs 8 million input pixels and 8 million output pixels, with no 1dlut access and barely any shader math to speak of. Furthermore, having each input pixel position match exactly the output pixel also means that the GPU texture caches work much more effectively compared to the upscaling shaders. Can you see how doing a TV <-> PC conversion is not even remotely in the same cost category as an upscaling algorithm?

Old versions of madVR which were texture heavy + 3DLUT instead of shader heavy + 3DLUT were faster though...
With very old GPUs, probably. The problem is that newer GPUs get more and more shader power, while the rest of the GPU properties doesn't get faster as much. So for newer generation GPUs it's a better idea to use shader math instead of textures. That does not only apply to mid-range and high-end GPUs, but also to low-end GPUs. The GPU generation makes all the difference here. I believe for madVR it is a good idea to concentrate on newer generation GPUs. I find it more important to make madVR run well on a new generation low-end GPU than on an old generation mid-range GPU. Hence my decision to use more shader math and less textures. And this decision should pay off more and more in the future.

I don't know about SubRenderIntf.h, but during our discussions there was consensus that the interface was to be clearly defined as 0-255 RGB only. I don't think we really need to re-discuss this unless we were going to support TV-range 16-235 or something like AYUV.

Those level range tags are just for informative purposes, and not immediately relevant to the subtitle interface. They only define intended level range to use for YCbCr output by xy-VSFilter and similar transform filter renderers. At the time, you were quite insistent on it being included in the subtitle interface, because you wanted to mimic incorrect xy-VSFilter behavior in those cases where the subtitle and video were not using the same YCbCr level range. Issues like xy-VSFilter outputting TV-range YCbCr subtitles on a PC-range YCbCr video and vice versa.
Wasn't our big fight back then about me wanting to get rid of levels from the interface, while you wanted it included? At least that's what I remember, but I might be wrong... :o

From where I stand right now, I'm not sure what madVR should do if XySubFilter reports TV vs PC. And I'm also not sure what XySubFilter should do if madVR reports TV vs PC. I don't think we should leave the interface like this. We at least need to clarify the intended behaviour. And while we're at it, we could consider adding support for 16-256 subtitles to avoid performance problems in the video renderer?

[madshi]

At the time, you were quite insistent on it being included in the subtitle interface
Haha, this is kind of funny. I've just double checked and it was the other way round: You were insistent, and I was doubting that the added complexity of adding TV/PC flagging to the interface was worth it. See comment #217 and following:

https://code.google.com/p/xy-vsfilter/issues/detail?id=91#c224

[Soukyuu]

Blocking LAV splitter in MPC-HC and using Haali from CCCP instead and it works fine with subs and all...!?I've had this experience as well. For some reason LAV needs a higher CPU queue than Haali for playback to not lag with madvr on same settings.

[nevcairiel]

I've had this experience as well. For some reason LAV needs a higher CPU queue than Haali for playback to not lag with madvr on same settings.

Except that his issue is something else entirely. :p

In any case, the splitter has absolutely zero interaction with D3D or the GPU, so its not really possible for it to cause any problem with madVRs vsync detection.

[cyberbeing]

Since 3dlut processing and dithering are the last steps in the processing chain, that doesn't change anything, though. All the main processing was still in TV levels. The 3dlut input was also always TV levels, unless my memory is totally betraying me.
I thought in old versions back when it was 3DLUT which did YCbCr->RGB & TV->PC, this occured as one of the first steps? I also seem to remember that madVR actually read the headers which contained parameters the 3DLUTs were created with and could handle both PC input and TV input.

So the decision for me is not 16bit integer vs 16bit float, but it is 16bit integer vs 32bit float, and that's a quite big difference in performance.
Ok, if I went with floating point, people could compromise by using 16bit float instead of 32bit (trade quality for performance). They'd probably get identical performance to the current madVR logic, but with slightly faster subtitle rendering. On the negative side, they'd get less accuracy at the same speed as the current madVR logic. I think that's a bad compromise. Furthermore, if you look at the high quality option, I'd have to use float32 instead of int16, which costs twice the memory bandwidth. So the memory bandwidth cost of doing Jinc3 AR for a "no compromise" setup would double. All of that just to get a small boost in subtitle rendering performance? Sounds like a bad idea to me...
Well the main issue I've seen with 32bit floats is it limits maximum framerate throughput on weaker GPUs. I'd expect most entry-level modern GPUs could handle >60fps display with 32bit floats though if there wasn't any heavy shader stuff going on. Doing YCbCr->RGB & TV->PC in a 3DLUT in 0.61 was ~25% faster than your change to gamut shaders + TV->TV 3DLUT + level range shaders back when I had my old 7800GTX 512 GPU. You could likely gain back some of the performance lost here by (optionally) moving some of these operations back onto a 3DLUT.


If what you're saying is true then please explain to me why the eeColor box does not have this issue, although it is also using TV levels 3DLUTs (when using it for Blu-Ray/TV calibration)?

Furthermore, ArgyllCMS could make TV levels 3dluts behave identical to PC levels 3dluts by simply clipping BTB/WTW away. From a technical/scientific point of view, using a TV levels 3dlut with clipped BTB/WTW is identical to using a PC levels 3dlut.

From what I've read the recent problems with ArgyllCMS with BTB information suddenly becoming visible with weird colors was due to Graeme trying to add xvYCC support. And the same problem also occurred with the eeColor. I'm not sure if that is the problem with elevated BTB that you're talking about, though.
The eeColor box doesn't have the issue probably because it clips BTB/WTW, while you maintain it. Honestly I'm not sure why in madVR an Argyll 3DLUT outputting an elevated 16-235 as 20-235 results in madVR displaying BTB 10-15 after expansion to PC range (random numbers used here for example).

He must be misunderstanding something then, because when I asked him he said that clipping BTB & WTW wasn't possible with a TV range in/out 3DLUT, and that it was something madVR should be doing, which you obviously aren't since it becomes visible.

The xvYCC support thing is something else, these problems were from way before then.


With very old GPUs, probably. The problem is that newer GPUs get more and more shader power, while the rest of the GPU properties doesn't get faster as much. So for newer generation GPUs it's a better idea to use shader math instead of textures. That does not only apply to mid-range and high-end GPUs, but also to low-end GPUs. The GPU generation makes all the difference here. I believe for madVR it is a good idea to concentrate on newer generation GPUs. I find it more important to make madVR run well on a new generation low-end GPU than on an old generation mid-range GPU. Hence my decision to use more shader math and less textures. And this decision should pay off more and more in the future.
I hope so, since my GT440 Fermi isn't that old, but it has rather weak shader performance but rather strong texture performance. Overall I think that texture heavy would still be a net positive over shader heavy on NVIDIA GPUs, since starting with Fermi they went overkill on texture/tessellation performance. AMD/ATI GPUs in comparison have always had somewhat overkill shader performance and weaker texture.


Wasn't our big fight back then about me wanting to get rid of levels from the interface, while you wanted it included? At least that's what I remember, but I might be wrong... :
No, more specifically you were against adding level range to the YCbCr Matrix script tags at all. You insisted that if xy-VSFilter was going to support levels range in YCbCb Matrix, then level support needed to be added to the subtitle interface as well which you were unhappy about. My stance was that level range was useless to the subtitle interface and could be ignored, but you wanted to mimic issues which could result from incorrect level tagging in a script. I was insistent on enabling PC range support in xy-VSFilter via script tagging, so as a result when those levels tag got added to YCbCr Matrix, you added them to the subtitle interface as well. You were left in charge of documenting use of the levels tags in the subtitle interface, and that was that.

From where I stand right now, I'm not sure what madVR should do if XySubFilter reports TV vs PC. And I'm also not sure what XySubFilter should do if madVR reports TV vs PC. I don't think we should leave the interface like this. We at least need to clarify the intended behaviour. And while we're at it, we could consider adding support for 16-256 subtitles to avoid performance problems in the video renderer?

Subtitle providers always output 0-255 RGB, any weird special handing with those tags is entirely in the ballpark of the subtitle consumer. Currently the reason why XySubFilter's internal subtitle correction defaults performing TV.601 on TV.709 video only and reporting the actual yuvMatrix for everything else, is because we thought you wanted to deal with cases where there were level mismatches. As mentioned above, I never wanted levels tags added to the interface in the first place, and rather they be removed if no longer desire to use them in your subtitle consumer. Otherwise, if you know what you want to use them for, I'll help you define them.

As far as actual changes, at the moment I'd rather just focus on getting the first XySubFilter beta released before we consider changing anything.

Haha, this is kind of funny. I've just double checked and it was the other way round: You were insistent, and I was doubting that the added complexity of adding TV/PC flagging to the interface was worth it. See comment #217 and following:

https://code.google.com/p/xy-vsfilter/issues/detail?id=91#c224
Nothing funny about it, you are confused. I wanted levels support added to YCbCr Matrix for xy-VSFilter (VSFilter.dll) only. As far as I can tell, the comment you link to was me basically stating that using the levels tags in the subtitle interface was pointless. You wanted to copy xy-VSFilter output exactly when it used those tags, even when what xy-VSFilter was doing was incorrect, and this is the sole reason they TV & PC exist in the subtitle interface today rather then just ignoring them. You wouldn't accept xy-VSFilter having a different result than madVR's consumer. In your mind it was an all or nothing affair. If I wanted support in xy-VSFilter, you were going to reluctantly support it as well in madVR. If you were not going to support it in madVR, you wouldn't allow me to add support to xy-VSFilter only. I was stubborn about adding levels support for xy-VSFilter so we ended up with both... I still believe YCbCr levels tags in the subtitle interface is useless though, but there it is because you gave me no other choice.

[zoyd]

0
The eeColor box doesn't have the issue probably because it clips BTB/WTW, while you maintain it. Honestly I'm not sure why in madVR an Argyll 3DLUT outputting an elevated 16-235 as 20-235 results in madVR displaying BTB 10-15 after expansion to PC range (random numbers used here for example).



The eeColor box does not clip BTB/WTW YCbCr input. It does no expansion whatsoever, video level out = LUT(video level in).

[cyberbeing]

The eeColor box does not clip BTB/WTW YCbCr input. It does no expansion whatsoever, video level out = LUT(video level in).
If the eeColor box doesn't do levels expansion or clip BTB/WTW, then I guess that the difference is that madVR doesn't clip BTB before performing TV -> PC range output or something. Most TVs clip BTB by default when performing TV range YCbCr input -> PC range. Otherwise, only madshi would know why a 3DLUT with 16-235 input/output was making BTB in the 0-15 range visible. It still doesn't make much sense to me.

[zoyd]

If the eeColor box doesn't do levels expansions, then I guess that the difference is that madVR doesn't clip BTB before performing TV -> PC range output or something. Most TVs clip BTB by default when performing TV range YCbCr input -> PC range. Otherwise, only madshi would know why a 3DLUT with 16-235 input/output was making BTB visible. It still doesn't make much sense to me.

I think it's a black point issue. ArgyllCMS 3dLUT encoded with TV in/out levels still contains 0-255 levels, it just maps the data flow with the correct 16-235 precision. If level 16 in gets elevated to say 16.5, then there will be information at level 15 as the LUT interpolation has to be smooth.

[cyberbeing]

I think it's a black point issue. ArgyllCMS 3dLUT encoded with TV in/out levels still contains 0-255 levels, it just maps the data flow with the correct 16-235 precision. If level 16 in gets elevated to say 16.5, then there will be information at level 15 as the LUT interpolation has to be smooth.
Well I guess that would explain why Graeme said madVR would need to clip this BTB information, and there was nothing he could do about it.

[madshi]

Subtitle providers always output 0-255 RGB, any weird special handing with those tags is entirely in the ballpark of the subtitle consumer.
Yes. But you're not happy with the performance hit madVR takes for this. Which is why I suggested to reconsider the whole levels stuff in the subtitle interface, because that would be the cleanest way to avoid the performance hit.

As far as actual changes, at the moment I'd rather just focus on getting the first XySubFilter beta released before we consider changing anything.
Ok, that's fine with me.

Nothing funny about it, you are confused.
No, I'm not, we were just talking past each other (once again).

I think it's a black point issue. ArgyllCMS 3dLUT encoded with TV in/out levels still contains 0-255 levels, it just maps the data flow with the correct 16-235 precision. If level 16 in gets elevated to say 16.5, then there will be information at level 15 as the LUT interpolation has to be smooth.
Yeah, maybe it's something like that. I have a Display 3 on order now. Once it's here, I'll start playing with ArgyllCMS + madVR. The latest ArgyllCMS build now supports an "-r256" switch which will overwrite the ICC cLUT resolution to 256^3, identical to the madVR 3dlut size. If the raised BTB issue is caused by LUT interpolation problems, using "-r256" should fix it because this way the ICC cLUT will have identical dimensions and black/white points as the final madVR 3dlut.

[cyberbeing]

Yeah, maybe it's something like that. I have a Display 3 on order now. Once it's here, I'll start playing with ArgyllCMS + madVR. The latest ArgyllCMS build now supports an "-r256" switch which will overwrite the ICC cLUT resolution to 256^3, identical to the madVR 3dlut size. If the raised BTB issue is caused by LUT interpolation problems, using "-r256" should fix it because this way the ICC cLUT will have identical dimensions and black/white points as the final madVR 3dlut.

Thanks for the head-up about the new build features, as I didn't see it mentioned anywhere about fixing -r255 to be -r256. Though main problem with using high resolution like that is they take forever to generate with -G. Like 2% progress per hour or something.

[Edit: The 6-7-2013 collink build still only supports -r255 , not -r256, did he provide you with a special build?]

[ryrynz]

Madshi, the black frame flash bug with Smooth Motion enabled is still there with 0.86.3

[flashmozzg]

I have a problem with atleast all madVR versions above 0.84 . If i update to a newer one this happens: http://s018.radikal.ru/i510/1303/8b/77e82d4924ef.jpg
Here is Ctrl+J:
http://img15.imageshack.us/img15/2088/67045988.png
(http://img15.imageshack.us/img15/2088/67045988.png)
If I downgrade to my previous version (84.7) it all comes back to normal.
Is there any way to fix it?

[madshi]

Thanks for the head-up about the new build features, as I didn't see it mentioned anywhere about fixing -r255 to be -r256. Though main problem with using high resolution like that is they take forever to generate with -G. Like 2% progress per hour or something.

[Edit: The 6-7-2013 collink build still only supports -r255 , not -r256, did he provide you with a special build?]
No, it's the normal download link for the 3dlut collink. He did update it to support -r256, though. He did not make -r255 behave like -r256, btw, those are two different options. Maybe he didn't update the documentation.

Yes, creating a 3dlut like that will take a loooooong time. You could try whether maybe -r128 or -r64 will make an acceptable compromise and still fix the BTB elevation problem. I've not yet had a chance to play with all this myself, so I'm only throwing wild guesses around here...

Madshi, the black frame flash bug with Smooth Motion enabled is still there with 0.86.3
Oh noooooooo... :( How often does it occur? Can you create a log where you abort playback directly after the problem occured? Not sure if that's doable, if the problem only occurs every couple of hours...

I have a problem with atleast all madVR versions above 0.84 . If i update to a newer one this happens [...]
If I downgrade to my previous version (84.7) it all comes back to normal.
Does this happen with all videos? Or only with some? Maybe only with one specific codec (e.g. h264 or MPEG2)? Which decoder are you using? Can you try using a different decoder?

[ryrynz]

Oh noooooooo... :( How often does it occur? Can you create a log where you abort playback directly after the problem occured? Not sure if that's doable, if the problem only occurs every couple of hours...


Yeah for me it's every couple of hours, I played about an hour tonight and it happened after about 20 minutes. Where as the night before same amount of viewing and no black screen.

[cyberbeing]

No, it's the normal download link for the 3dlut collink. He did update it to support -r256, though. He did not make -r255 behave like -r256, btw, those are two different options. Maybe he didn't update the documentation.
Don't know, because I just downloaded it again but it still rejects -r256 here.
collink -v -3m -et -Et -IB -r256 -G -ila Rec709.icm TV.icm HD.icm
Diagnostic: Resolution flag (-r) argument out of range (256)

[madshi]

This is a direct quote from his email:

So this <http://www.argyllcms.com/Win32_collink_3dlut.zip> now supports -r256.

[cyberbeing]

This wouldn't be the first time he posted an incorrect build on his server, I'll give him a heads-up on AvsForum.

[madshi]

Hmmmm... Just wondering: Shouldn't colprof already support -r256? It doesn't seem to support "-r" for cLUT resolution switching at all?

[cyberbeing]

You would need to request that -r override feature if you wanted support in colprof. Currently colprof maxes out at 45x45x45 ICC cLUT size when using -qu, while using -qh is 33x33x33 ICC cLUT. This seems to match up with what collink reports for these quality presets for "Gamut map resolution". The collink -r flag just overrides the output device link cLUT size used for 3DLUT creation, rather than the actual gamut mapping resolution.

[flashmozzg]

Does this happen with all videos? Or only with some? Maybe only with one specific codec (e.g. h264 or MPEG2)? Which decoder are you using? Can you try using a different decoder?

It happens in all videos I've tried (H.264/AVC ot h.263/Divx5).
I'm using MPC-HC with LAV filters (audio/video decoder). I tried to use MPC built-in decoder (based on FFmpeg) - nothing changed.

[ajp2k11]

Except that his issue is something else entirely. :p

In any case, the splitter has absolutely zero interaction with D3D or the GPU, so its not really possible for it to cause any problem with madVRs vsync detection.

I'm certainly not saying it's LAV's fault, just which workaround worked for me. It's probably got nothing to do with vsync, it just never gets to the detection or whatever? That's my theory anyway...;)

Maybe I have managed to check some odd option in LAV splitter or something? Any suggestions?

[Soukyuu]

Except that his issue is something else entirely. :p

In any case, the splitter has absolutely zero interaction with D3D or the GPU, so its not really possible for it to cause any problem with madVRs vsync detection.I must have mixed up something, since he was talking about files working fine either without subs or with subs but with haali instead of lav... :p

[Danat]

I have the render and presentation threads at HIGHEST priority, and uploading at ABOVE_NORMAL priority.
Hm, so that's probably the unidentified thread with Base Priority = 11 that I've been noticing. It doesnt appear if I use some other renderer instead of madVR. That makes more sense now, as it is the most CPU consuming thread after LAV decoder threads.

So unless the decoder is running with ABOVE_NORMAL, too, the uploading thread should have priority over the decoding thread(s).

Have you tried different decoders? Maybe some are running at ABOVE_NORMAL and some at NORMAL?Well, I've already shared my observations that LAV threads seem to be running at NORMAL priority (for ABOVE_NORMAL process which is mpc-hc.exe). I've tried ffdshow decoder, madVR internal decoder, tried using dummy audio renderer to make sure audio threads dont interfere and got more or less same results regarding frame drops. So currently I assume (dont have much options anyway :)) this is not a thread priority issue, but an inaccurate thread handling by OS task scheduler when CPU usage is 100%.

However I did manage to find an acceptable workaround: I've increased LAV decoder's number of threads up to 16 (max) :). And as I later realized after noticing playback improvement - since the OS needs to switch more frequently between decoder threads each of which consumes less CPU now (compared to default settings), it manages to be more precise in distributing CPU resources between decoder threads and renderer threads according to their priorities when CPU usage is maxed. Now sometimes I don't have framedrops at all even in windowed mode, and when I do ... well it's mostly bearable.

Though if you'll excuse me for being maybe too persistent in trying to completely solve this :), I'd like to share my thoughts on an idea based on an assumption that you have some control over how decoder buffer is filled, since you can control buffer size:
- If upload queue is not full (80% full / 60% full / idk) and decoder queue has more than enough frames (> upload queue size x 2), then temporarily stop filling decoder queue, releasing CPU for upload queue to fill.
- If upload queue is full then make sure decoder queue is being filled again.
I guess on 100% CPU usage this would probably trigger more than once per second. Now, wouldnt' that solve all problems if such an option existed ?
I understand that ideally it shouldnt be madVR's task to fix broken thread management, just trying to express my thoughts on the ways that seem a possible solution to me, given what madVR has a control over (in my assumption). I suspect you would probably not like to add this stuff in the code for valid reasons :), but would that at least work as described ? ;)

By the way, thank you for taking your time to reply to my posts up until now. Looking at how many detailed answers you provide to users in this thread I must admit you sure have a lot of patience.

[dansrfe]

Ok, after testing for the repeating frame bug in windowed/exclusive mode on a LOT of different types of videos I've come to the (hopefully final) conclusion that the bug is indeed gone.

[karamancho]

madVR v0.86.3 has a problem with MPC-HCs internal subtitle renderer.

whenever the subs are shown the queues are getting all messed up and the dropped and delayed frames appear. when there are no subs on the screen (no one speaks in the video) the queues go back to normal and the dropped/delayed frames stop only to come back again when the subs appear again. decoder queue is the least affected one while the backbuffer queue goes strait to 0.

no such behavior with DirectVobSub or with subs disabled

[MistahBonzai]

I would guess that this is expected behavior however you may be interested in how the addition of of DCI-P3 and BT.2020 'primaries and gamuts affects the display when mixing "4K" videos with ones utilizing 'standard' primaries and gamuts. On my non-4K calibrated display (BT.709). when utilizing the "this display is already calibrated" setting (doesn't apply when using "disable calibration controls for this display") I need to select the proper choice in the 'primaries/gamuts' selection. In this case most of my 4K videos are of the DCI-P3 variety so I select DCI-P3. Otherwise 4K videos will appear as if the red channel was locked into 255. When switching back to 'standard' video you'll need to manually reselect the proper curve.

[Plutotype]

madVR v0.86.3 has a problem with MPC-HCs internal subtitle renderer.

whenever the subs are shown the queues are getting all messed up and the dropped and delayed frames appear. when there are no subs on the screen (no one speaks in the video) the queues go back to normal and the dropped/delayed frames stop only to come back again when the subs appear again. decoder queue is the least affected one while the backbuffer queue goes strait to 0.

no such behavior with DirectVobSub or with subs disabled

tested, but cant confirm this on my setup

[ryrynz]

If there's anyone with an HD 4600 Haswell, could you tell me how it does with Jinc 3 taps and AR with 720P content? I know the HD 4000 isn't fast enough in this area.

[nevcairiel]

If there's anyone with an HD 4600 Haswell, could you tell me how it does with Jinc 3 taps and AR with 720P content? I know the HD 4000 isn't fast enough in this area.

On 720p24, scaling to 1080p:

Luma Jinc3+AR / Chroma Jinc3+AR => too slow
Luma Jinc3+AR and Chroma Bicubic75+AR => works

Adding smooth motion overloads it again.

[Plutotype]

On 720p24, scaling to 1080p:

Luma Jinc3+AR / Chroma Jinc3+AR => too slow
Luma Jinc3+AR and Chroma Bicubic75+AR => works

Adding smooth motion overloads it again.

HD4600 seems not to bring added value, but the HD5000 - HD5200 could make the notebook madVR HTPC users happy. Again, it needs to be specifically tested as the low TDP in ultrabook CPUs can limit the iGPU performance.

http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested/2

[aufkrawall]

On 720p24, scaling to 1080p:

Luma Jinc3+AR / Chroma Jinc3+AR => too slow
Luma Jinc3+AR and Chroma Bicubic75+AR => works

Adding smooth motion overloads it again.
Could you try out overclocking the IGP?

[ryrynz]

Could you try out overclocking the IGP?

This is exactly what I asked him, I'm thinking a 10-15% overclock and it'd be sweet.

[aufkrawall]

This is exactly what I asked him, I'm thinking a 10-15% overclock and it'd be sweet.
I can OC the IGP of my 2500k by 100% (2200Mhz) with maxed out voltage. Of course it was limited by bandwidth, so I can't say if it was totally stable. But no game crashed and it gave me some nice room for better image quality with madVR.
I wonder how well HSW IGP can be clocked, e.g. if it suffers the same heat problem like the CPU part.

[khanmein]

"mpc matroska splitter (low merit)" happened during i play .mkv

it disappeared if i tick source filters for matroska.

can anyone help me to solve this issue? very grateful!

[kiccolsd]

Does the issue occur with all scaling algorithms? Does it occur in all presentation modes (windowed, overlay, fullscreen exclusive)?

The strange thing is that if I try with a 720p mkv on a 1080p screen (scaling algorithms enabled) i cannot experience any issue, otherwise with 1080p mkvs on 1080p lcd, a situation in wich I expect scaling algorithms are not working the artifacts came out. Usually I set fullscreen exclusive mode, If you need I can try to check with Overlay and Windowed. Tell me what checks you need and I'll try and report back to you.

[callannn]

Can someone explain the advantages of increasing/decreasing the CPU and GPU queues? I've kept mine at default (12 and 8 respectively) and experience no playback issues apart from delayed frames sometimes (no dropped frames).

[Buckster]

I've a similar question but on Render/Presentation queues

I thought my 5670 wasn't coping as I was getting dropped frames, but checked GPU-Z and my GPU usage is only at 60% - although memory maxed out (512)

for some content, my render queue drops from the normal 12-14 down to 2 and below occasionaly - and I get dropped frames

if I disable the presentation in advance, so I get "backbuffers" instead - my render queue hardly ever drops below 12, but I'm getting loads of dropped frames due to the backbuffers running out

any ideas please ? I'm very confused

<update> - ah - I think I may have had my present and gpu queues too high, I've dropped both to 8, , and now I'm getting much much less dropped frames, but now I'm getting the odd "presentation glitches" ??

[6ari8]

Thanks for the update!

I'm having a problem after updating from 86.1 to 86.3. I play my videos on an LCD and didn't have this problem ever with madVR, it only just appeared right after the update. Same settings as before. I think it has to do with the scaling algorithm (Image Upscaling: Lanczos 8 taps, Anti-Ringing, Linear Light). It goes away when I drop it to lower than 8 taps or disable the Anit-ringing filter. I'm not sure why though since these are the same settings I used before with no problems.


(Image too big for thread)
http://img197.imageshack.us/img197/7114/madvr.png

[DragonQ]

Is it possible to overclock mobile Intel IGPs? If so, what is the best software for this? I've done plenty of CPU overclocking but never GPU/IGP.

[huhn]

try the bios/uefi

[raul31]

Asmodian replied well, so I didn't see a need to write the same reply in other words. But maybe I can expand a little:


Deinterlacing inside of LAV might make sense if you plan to use this all for reencoding or stuff like that. As long as we're talking about straight and simple video playback with LAV -> madVR, the default LAV settings are usually the best.

That said, some people prefer yadif deinterlacing quality over DXVA deinterlacing quality (the latter of which is used by madVR at the moment). So for sports and music concerts you could try whether you like LAV's yadif implementation better, if you feel like playing around with the options...


As Asmodian said, set LAV to "None" for hardware acceleration. Otherwise just use the LAV default configuration.


They are disabled by default.


thanks madshi. appreciate the reply!

however, i am STILL unable to get madVR to utilize the nvidia card.

this is what i've done thus far:
i went into nvidia control panel, --> then clicked: display GPU activity icon in notification area.

i went to manage 3D settings --> Program settings --> clicked Add --> clicked Browse --> then selected Madhcctrl --> & then chose "High performance nvidia processor" as the preferred graphics processor.

when i played back a video in MPC-HC, the "nvidia GPU Activity icon" near the bottom right did not LIGHT up to show that there was any activity. so madvr wasn't using the nvidia card. :confused:

i am still mind-boggled with this: what else can i do so that madvr uses the nvidia card?


thanks madshi! :thanks:

[QBhd]

For me I rarely see GPU usage as well. I have a 5770 and Chroma/Luma at Jinc 3 w/ AR I ususally watch 720p and upscale to my Plasma's native resolution of 1360x768. They only time I see Usage is while playing back 1080i30. When I do these will push usage up to around 70% and with Smooth Motion is goes as high as 95-97%.... Now for the normal 720p stuff I do see temps rise on the GPU, so it is being used, it's just that the Usage % shows nothing. So maybe the same thing is happening with you

QB

[vivan]

raul31,
rename "mpc-hc.exe" to something else (e.g. "game.exe"). And you have to force mpc-hc to use dGPU, not Madhcctrl.

[ryrynz]

Can someone explain the advantages of increasing/decreasing the CPU and GPU queues? I've kept mine at default (12 and 8 respectively) and experience no playback issues apart from delayed frames sometimes (no dropped frames).

Higher queues = less likelihood of dropped frames. Defaults are fine, personally I drop mine to 4/4 and playback start and after seeking delayed until the render queue is full. That way I get smooth starts and quick seeks.

[chros]

Have somebody experienced huge dropping frames when the Antiringing is on with Jinc3 ? (current madvr, nvidia 320.xx, geforce GT 650m, win8 laptop, fullhd screen)
If I switch off antiringing, everything is fine. (and it happens with chroma (1080p) and luma upscaling (720p) as well !)

[madshi]

Yeah for me it's every couple of hours, I played about an hour tonight and it happened after about 20 minutes. Where as the night before same amount of viewing and no black screen.
That's too bad, really. I fear without a log (which ends very near to the black screen) this might be hard to fix.

It happens in all videos I've tried (H.264/AVC ot h.263/Divx5).
I'm using MPC-HC with LAV filters (audio/video decoder). I tried to use MPC built-in decoder (based on FFmpeg) - nothing changed.
Which OS are you using? Could you try different madVR builds to see if this was introduced in a recent build? You'll find download links for older madVR builds on the first post in this thread.

I'm certainly not saying it's LAV's fault, just which workaround worked for me. It's probably got nothing to do with vsync, it just never gets to the detection or whatever? That's my theory anyway...;)

Maybe I have managed to check some odd option in LAV splitter or something? Any suggestions?
I've no idea.

- If upload queue is not full (80% full / 60% full / idk) and decoder queue has more than enough frames (> upload queue size x 2), then temporarily stop filling decoder queue, releasing CPU for upload queue to fill.
- If upload queue is full then make sure decoder queue is being filled again.
I guess on 100% CPU usage this would probably trigger more than once per second. Now, wouldnt' that solve all problems if such an option existed ?
In theory the OS should take care of this automatically through the thread scheduler. Yes, I could probably try to "help" the OS thread scheduler by applying some tricks like you suggest. But really, I've SO MANY workarounds for other people's bugs in madVR already, it's not funny. Sometimes it feels to me like 70% of my development time is spent by working around other people's bugs. Sometimes I think "just leave me alone". I want to do real development, not constantly trying to fix other people's bugs.

That said, yes, maybe slowing decoding down a notch if the upload queue is empty and the decoder queue is full might be a good idea. I'll put it on my list of things to do. But I'm not sure when I'll get around to that.

Ok, after testing for the repeating frame bug in windowed/exclusive mode on a LOT of different types of videos I've come to the (hopefully final) conclusion that the bug is indeed gone.
That's good to hear. Now I wish the black frame bug were gone, too.

madVR v0.86.3 has a problem with MPC-HCs internal subtitle renderer.

whenever the subs are shown the queues are getting all messed up and the dropped and delayed frames appear. when there are no subs on the screen (no one speaks in the video) the queues go back to normal and the dropped/delayed frames stop only to come back again when the subs appear again. decoder queue is the least affected one while the backbuffer queue goes strait to 0.

no such behavior with DirectVobSub or with subs disabled
Is this a new problem with v0.86.3? Or do you have this problem with all older madVR builds, too?

I would guess that this is expected behavior however you may be interested in how the addition of of DCI-P3 and BT.2020 'primaries and gamuts affects the display when mixing "4K" videos with ones utilizing 'standard' primaries and gamuts. On my non-4K calibrated display (BT.709). when utilizing the "this display is already calibrated" setting (doesn't apply when using "disable calibration controls for this display") I need to select the proper choice in the 'primaries/gamuts' selection. In this case most of my 4K videos are of the DCI-P3 variety so I select DCI-P3. Otherwise 4K videos will appear as if the red channel was locked into 255. When switching back to 'standard' video you'll need to manually reselect the proper curve.
Hmmmm... I'm not sure if there's a question hidden somewhere in your post you want me to reply to? Or something you want changed in madVR? Or did you just want to post your experiences?

"mpc matroska splitter (low merit)" happened during i play .mkv

it disappeared if i tick source filters for matroska.

can anyone help me to solve this issue? very grateful!
I'm not sure what you mean exactly. You can explain in more detail?

The strange thing is that if I try with a 720p mkv on a 1080p screen (scaling algorithms enabled) i cannot experience any issue, otherwise with 1080p mkvs on 1080p lcd, a situation in wich I expect scaling algorithms are not working the artifacts came out. Usually I set fullscreen exclusive mode, If you need I can try to check with Overlay and Windowed. Tell me what checks you need and I'll try and report back to you.
Try doing a very small zoom with 1080p mkvs, like 1% smaller or bigger. Does that make the problem go away? And yes, please also try windowed mode, just to make sure. Do you happen to have a digicam which might be able to capture the artifact you're talking about? It would be easier for me to help if I knew exactly how the artifact looks like.

Can someone explain the advantages of increasing/decreasing the CPU and GPU queues? I've kept mine at default (12 and 8 respectively) and experience no playback issues apart from delayed frames sometimes (no dropped frames).
See ryrynz's answer. Bigger queues are usually good, but make sure you don't run out of GPU RAM, or else performance might go down a lot. Also, longer queues mean slower fullscreen exclusive -> windowed switching time and slower OSD in fullscreen exclusive mode etc.

I've a similar question but on Render/Presentation queues

I thought my 5670 wasn't coping as I was getting dropped frames, but checked GPU-Z and my GPU usage is only at 60% - although memory maxed out (512)

for some content, my render queue drops from the normal 12-14 down to 2 and below occasionaly - and I get dropped frames

if I disable the presentation in advance, so I get "backbuffers" instead - my render queue hardly ever drops below 12, but I'm getting loads of dropped frames due to the backbuffers running out

any ideas please ? I'm very confused

<update> - ah - I think I may have had my present and gpu queues too high, I've dropped both to 8, , and now I'm getting much much less dropped frames, but now I'm getting the odd "presentation glitches" ??
Not sure what to say. Do you get presentation glitches only during playback start and when pausing/resuming? Or also in the middle of playback. The latter is not so good. Maybe using longer queues again might help, but you do need to make sure you don't run out of GPU RAM.

Thanks for the update!

I'm having a problem after updating from 86.1 to 86.3. I play my videos on an LCD and didn't have this problem ever with madVR, it only just appeared right after the update. Same settings as before. I think it has to do with the scaling algorithm (Image Upscaling: Lanczos 8 taps, Anti-Ringing, Linear Light). It goes away when I drop it to lower than 8 taps or disable the Anit-ringing filter. I'm not sure why though since these are the same settings I used before with no problems.
Weird! Can you please go back to v0.86.2 and v0.86.1 to check which version exactly introduced this issue? Also please double check that the problem *really* doesn't occur with v0.86.1, just to be safe that we're not chasing ghosts here...

i went to manage 3D settings --> Program settings --> clicked Add --> clicked Browse --> then selected Madhcctrl --> & then chose "High performance nvidia processor" as the preferred graphics processor.
See vivan's reply.

Have somebody experienced huge dropping frames when the Antiringing is on with Jinc3 ? (current madvr, nvidia 320.xx, geforce GT 650m, win8 laptop, fullhd screen)
If I switch off antiringing, everything is fine. (and it happens with chroma (1080p) and luma upscaling (720p) as well !)
Of course Anti-ringing costs extra performance. Maybe your GPU is too slow for that?