madVR - high quality video renderer (GPU assisted)

[leeperry]

BTW, an option to mirror the picture horizontally with a hotkey would be fantastic if any possible. I used to do it in ffdshow, but 8bit yadayada and noise comes back with a vengeance :(

It would also be useful to the RPTV/DIY projector ppl :)

[Xaurus]

Well, local dimming doesn't come for free apparently and for instance a fast white object on a black background would end up with ghosting artifacts due to the fact that there isn't that many zones really. And if you don't enable it, then there doesn't seem to be any real world advantage over CCFL except for the lower power consumption.
I guess you are referring to halos. Yes, that could be an issue but fortunately I have managed to keep them cloze to non-visible, even with white text on a black background (typically at the start or end of a movie). The TV I use have 105 zones.

I agree on the "if you don't enable it" part. I would never buy such a set if I wasn't going to use that feature.


lesnumeriques.com keep claiming that pretty much all LED backlit screens suffer from clouding but that it's extremely rare with CCFL thanks to the much better backlight homogeneity. They also said that the Sharp LED panels they tried had zero clouding, being pretty much the only manufacturer that fixed this problem for good.
After working over 10 years as a sales person for electronics I can tell you that all brands suffer from clouding, including Sharp. However, some sets can be "fixed" by calibrating it correctly.


This said, it's notorious that all manufacturers but Sharp contract several panel makers and that they often send golden samples for reviews but actually sell cheaper CMI/AUO panels IRL: http://news.cens.com/cens/html/en/news/news_inner_40642.html

Yes, that's why you should never buy a set simply from a review on the net or any printed article. Use your own eyes. :)

In any case, this is off-topic for this thread so I'll leave it at that.

[madshi]

the image was shoot while the playback was still running this is maybe 1 of the frist frames.

like mention before stopping the playback fix the issue
Ok, thanks, I managed to reproduce the issue, but it's not happening every time. I'll see if I can fix it.

I noticed the mpc hc seekbar now shows the starting point of mkv chapters.
I love this feature, i was wondering if the full screen exclusive mode seekbar will have it too?
Maybe some day, but not too soon.

There is research that supports the "(first) haloing -> artificial acutance -> perceptual sharpness even if the data is actually not high res" thesis here:
http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP092.pdf. See the top of p. 5 and the shape of the two filterss at the top left of p. 2.
(User hjulenissen on http://www.dpreview.com and also on the ImageMagick Forums pointed the existence of this paper to me.)
I've had a look at that paper, but it's all chinese to me. Anyway, there are people which like a bit of haloing. Personally, I hate it.

Well, there are many DVD rips without black borders and as much as you consider any 23.976 SD file to be SMPTE-C, you may also want to consider them as EBU if they're 25fps [...]
Which dimensions (width, height) do such files usually have?

[...] and HDTV if they're 24fps. Many ppl encode bluray's to SD and they have no clue whatsoever about the 601/709 decoding matrix story so you may also wanna enforce that SD/HD 24fps=709 matrix and SD 29.97=SMPTE-C.
I won't do SD 24fps -> 709. That wouldn't be a good idea, because NTSC movie DVDs are often IVTCed and reencoded to 24fps. You can also convert 25fps PAL movies to 24fps. I actually do that myself sometimes. So doing 24fps -> 709 would produce wrong results in many cases. Changing movie FPS is so simple, you can do that with eac3to without even reencoding, that's why I prefer to base auto guessing on resolution instead of framerate, because that's a quite reliable way to detect the true source gamut. E.g. if you have a file with 576 height, it's extremely likely it's PAL/EBU. But I guess only few people would be changing 24fps movies to 25fps, so maybe auto guessing 25fps SD files to be PAL/EBU, too, might be safe, as an additional detection step.

SD 24fps could be everything, SMPTE-C, EBU/PAL or BT.709. The proper way to encode SD 24fps would be to use SMPTE-C, so that's what I'm using as default - unless the height is 576 pixels, then I'm auto guessing EBU/PAL.

I fail to understand why you went through the trouble of supporting 3DLUT files when a simple PS script can do it all without the need to wait for a 96MB file to be loaded.
Because 3dlut files have the potential to do so much more than what that simple PS script does. E.g. that script can't do gamma corrections. And that's only one of many things that 3dlut could potentially do. Ultimately 3dlut files could do virtually "everything". The only limitation is the software which creates 3dlut files.

But let's not go there again, we had a heated discussion about this in the past already, if you remember. I don't feel like going there again. So this will be my last post on why I'm supporting 3dluts.

Also, did you use JohnAd's script verbatim?
Not sure what you mean, I'm not using his script at all.

I don't really see how custom PS support would help me exactly? Because I'd need to be able to set up automatic rules, but maybe you also plan on supporting rules depending on resolution and frame rate?
If you tell madVR that your display is already (externally) calibrated to e.g. BT.709, madVR will convert every input gamut to BT.709. So you could make a custom pixel shader which simply converts BT.709 gamut to your custom display primaries.

Automatic rules to make madVR choose the correct *source* gamut is a totally separate issue, which has nothing to do whatsoever with which gamut your display has. Source gamut is one thing. Display gamut is a totally separate thing. Of course both must be correct to reproduce correct results.

BTW, an option to mirror the picture horizontally with a hotkey would be fantastic if any possible.
It's on my to do list, but not coming too soon.

[leeperry]

Which dimensions (width, height) do such files usually have?
Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.

In the same way, any 29.97 SD file will be SMPTE-C but I presume you already did that(I didn't check).

I won't do SD 24fps -> 709. That wouldn't be a good idea, because NTSC movie DVDs are often IVTCed and reencoded to 24fps. You can also convert 25fps PAL movies to 24fps. I actually do that myself sometimes. So doing 24fps -> 709 would produce wrong results in many cases. Changing movie FPS is so simple, you can do that with eac3to without even reencoding, that's why I prefer to base auto guessing on resolution instead of framerate, because that's a quite reliable way to detect the true source gamut.
Well, going 29.97 telecine NTSC to IVTC'ed 23.976 and then accelerated to 24fps will require an audio reencoding in order to be pitchshifted at least AFAIK.

Anyway, OK I wasn't aware that some ppl would accelerate NTSC DVD movies to 24fps.

Because 3dlut files have the potential to do so much more than what that simple PS script does.
You're entirely right, but at this point they really only do the same as your PS script(which didn't exist when we previously discussed this matter) and yRGB is not a finalized standard so no one else can really work on it....but fair enough! I will stop questioning your technical choices and I sincerely thank your for your patience and your kindness sharing your stunning work with us http://forum-images.hardware.fr/images/perso/mzarella.gif

that script can't do gamma corrections.
I tried to change the gamma value of your script from 1.80 to 2.60 when set as "pure power curve" with my display set as REC.709, but I didn't see much change in the PQ...that might explain, but I will try test patterns.

Not sure what you mean, I'm not using his script at all.
But you're not using the math from his Excel sheet either? I guess you thoroughly proof-tested the gamut mapping results anyway? with those pesky out-of-gamut colors and all :o

If you tell madVR that your display is already (externally) calibrated to e.g. BT.709, madVR will convert every input gamut to BT.709. So you could make a custom pixel shader which simply converts BT.709 gamut to your custom display primaries.
Oh, that's pushing it :D

Automatic rules to make madVR choose the correct *source* gamut is a totally separate issue
Well, automatic rules for PS scripts based on resolution and frame rate could come in handy IMHO...for instance to do hardcore deinterlacing on (partially) broken encodes or to upscale SD with some additional processing. But then we would also need an option like in MPC so you can either set the script to be applied before or after scaling.

It's on my to do list, but not coming too soon.
OK, sweet! TBH, I'm quite floored by how noisy PQ gets when I enable mirroring in ffdshow :(

I guess toying around in those 8bit ffdshow/avisynth apps is out of the question for me now, so indeed PS scripts inside mVR applied in 32fp would be full of win! I might even be able to find a script that would do that mirroring thingie for me without raising a stormload of noise gremlins http://forum-images.hardware.fr/images/perso/3/lothiek.gif

[DragonQ]

Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.
Agreed, if you do a rip from a DVD there's no guarantee it'll have a height of 576 pixels (especially if it's been cropped). A frame rate of 25 or 50 fps seems a much more sensible indicator of a file having an EBU/PAL colour space.

[6233638]

Well, the idea of 16bit 96MB 3DLUT's originally came up because tritical's gamut mapping Avisynth plugins were too CPU hungry, then madshi decided to support them because he wanted to delegate all the CMS work to someone else.

The thing is that gamut mapping is a trivial job for a PS script: http://www.avsforum.com/t/912720/

These days, 96MB 3DLUT's only really make sense if you wanna convert YUY2 to RGB for instance IMHO. They are way overkill for something as simple as gamut mapping and madshi finally took the bull by the horns and added PS-based gamut mapping in mVR. The only problem is that it doesn't allow custom RGBW coordinates and as you can see my 46" LCD is only a few ΔE's away from the REC.709 gamutMost people have only been evaluating gamut with 100% measurements for the longest time now. You really need to look at, at the very least, saturation in 25% increments.

I suspect these scripts probably don't do a great job of it. You really need LUT capabilities for proper calibration. Unfortunately the tools don't currently exist to do this with yCMS files. You can convert ArgyllCMS files to yCMS 3DLUTs, but ArgyllCMS does not do a very good job of creating LUTs in my opinion.

I've tried linear light scaling and while AR takes care of the biggest problems, it still doesn't look so good to my eyes. I still prefer resampling in gamma corrected light.Downsampling in linear light using Catmull-Rom and anti-ringing seemed to have good results in my limited testing, but I don't really use downsampling much.

With upsampling, linear light scaling seems much more difficult to get good results. (but sometimes it is useful)

Have tried that, but I can't see any difference. FWIW, I'm using linear interpolation when reading the LUT. That probably helps.I realise that this was actually related to scaling algorithms, but it actually got me thinking about the yCMS LUT creation, with all this other calibration talk recently.

Am I correct to assume that if you give it say inputs for 20-100% in 10% increments, you will use linear interpolation for the LUT? In my experience building LUTs, this is optimal.

However, how you handle going to black is also very important and most LUT devices/creation tools do not do a good job of it. Because I am no longer using a CRT, I have not run into these specific issues with madVR, but that doesn't mean that they don't exist.

The problem is that a lot of LUT creation tools try to end up with the LUT reading 0,0,0 at black by changing the curve significantly from the lowest data point you give it.

For example, here is a LUT which has three data points set at 10% (38) 100% (235) and 109%? (255) with a hard clip at black (16) to 0,0,0 RGB.

http://i.imgur.com/UD0Lw.png

A hard clip to black sounds really bad, but in practice is generally what actually looks best on a display that requires a LUT with raised shadow detail like this. (if you don't hard clip to black, you raise the black level on the display)

Most LUT tools, when given data for 10% and 100%, will try to converge RGB to 0,0,0 rather than clip it, which results in significant greyscale errors and posterization near black. What should be done, is that linear interpolation should be used to follow the line down from the two smallest measurements down (e.g. 100-10 in this example, linearly down to 1% then clipped at 0%, or 20-10% linearly down to 1% then clipped at 0% if that's what the smallest measurements were)

I don't know if this is something you handle yourself in madVR, or if you're simply passing the input data onto yCMS to let it handle LUT creation though, so it may be a discussion better suited in that topic. (though development seems to have been put on hold indefinitely?)

What do you mean with "calibrate through mpc/madVR"? Do you mean you want to use yCMS to calibrate your display? Or what? Or do you want to use mpc/madVR just to show test patterns and calibrate your display by using the options in your display's setup menu?Right now, all we can do in madVR is input current measurements from the display, have it generate a LUT based on that, and then hope that the results look good... often they do not, in my experience.

What I end up doing is manually tweaking the LUT input values so that the values measured from my display when showing test patterns actually measure 2.4 gamma at all points, when that's what I have set in madVR. (my display is calibrated to 2.2 gamma for computer use, and I want madVR using 2.4 for video) This is a very laborious process though, as you are setting input Yxy values for the LUTs. I could do it in 1/10th the time if I could set RGB output values for the LUT at specific points.


I don't think madVR switches the *output* levels. Press Ctrl+Alt+Shift+Y to double check. It probably switches *input* levels. Some h264/AVC files claim they are encoded as fullrange and madVR honors that. If you don't want madVR to do that, just press Ctrl+Alt+Shift+I multiple times to force madVR to "TV" input levels, then press F2 to store that. Afterwards madVR will ignore the "fullrange" flag in h264 files.It would actually be really useful for me if you could implement some kind of level clipping option in madVR. Right now we have the option to toggle output levels between PC (0-255) and Video (16-235) and for that, I have it set to PC.

We can also set whether an input source is using Video levels (16-235) or PC levels. (0-255) I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR to offer a "compressed levels" option to fix it. (30-218 if I have done the math correctly - or even a custom option that let you hit a shortcut for +/- on the range, adjusting black & white simultaneously)

But I like Jinc AR much better with these images. Look here:

Jinc3 AR (http://madshi.net/jinc-subtitle.png)

Ok, there's a tiny bit of ringing left in the image, but it's really not much, and the image is oh so much sharper than EWA quadratic and VSQBS and also less aliased than EWQ quadatric.I know it doesn't seem like much at all, but I find even that amount of ringing distracting when it's on the subtitles layered over a moving image. Because the subtitles are fixed, and the background is moving, the ringing is far more apparent than it is in stills.

I think using de-haloing and de-banding before resizing, then using something like Jinc AR for resizing, should be a better solution. Using a filter which is strongly smoothing would probably remove some detail which you might never fully get back. Also post-sharpen will likely bring halos back which were only weakened through smoothing. The halos must be totally eliminated for sharpening to not bring them back, I believe. I haven't really actually tested any of this, though. This is just what I "think" at the moment. It might be wrong...I strongly agree with this. I have experimented with sharpening a number of images scaled in madVR, using different techniques in Photoshop, and it seemed futile. Any benefits from using softer, low-ringing, low-aliasing scaling were immediately lost when sharpening the image. (but maybe there are better ways to do it)

I agree on 8-tap. However, I do think that Lanczos4 does bring a nice improvement in sharpness and aliasing. Yes, it some situations Lanczos4 has a bit more ringing than Lanczos3, despite the AR filter. But that's just in some situations. I believe it's a matter of taste whether you prefer Lanczos4 AR (sharper, less aliasing, more ringing) or Lanczos3 AR. The differences aren't that big, from my point of view, except maybe in some special situations.The issue I have is that while the anti-ringing filter manages to eliminate the obvious effects of ringing, there are still "ripple" effects on the image that are caused by the ringing.

I think I have posted this example before, it's much easier to illustrate with 3-tap vs 8-tap, but still affects 4-tap:
http://www.abload.de/img/rippleezlw1.jpg

Lanczos 3, Lanczos 8
Lanczos 3AR, Lanczos 8AR.

As you can see, the right of the red (B) is still distorted by the ringing in Lanczos 8, even though the anti-ringing filter has removed most of the visible haloing.

Same story for Philips that sends "Sharp UV²A (http://translate.google.com/translate?hl=en&ie=UTF8&oe=UTF8&twu=1&u=http://www.lesnumeriques.com/tv-televiseur/philips-40pfl5507h-p12906/test.html)" panels for reviews but actually puts crappy panels for sale :(For what it's worth, back when I was reviewing HDTVs for one of the bigger sites out there, and helped set the standards for what hardware measurements should be taken, and what tests needed to be performed on the displays (didn't win the battle for uv charts rather than xy, unfortunately) we would never accept displays from the manufacturer. They were either purchased, or on loan from shops that would sponsor the site. (these were not selected at all, just shipped to us as anyone would get when purchasing a set, and then used as a display model)

I was about to wait for OLED but their blue LED's lose 50% of brightness after 2 years, huh: http://www.displaymate.com/OLED_Galaxy_S123_ShootOut_1.htm20,000 hours of use, at 8 hours a day is almost seven years to 50% brightness. Even at 12 hours use a day, that's just under five years - much longer than most people buying the first batch of OLED displays are likely to keep them.

Mine uses CCFL and its only drawbacks are that its PSU regulation emits a fairly annoying buzzing noise when its backlight is dimmedPersonally I experience green "RBE"-like effects when watching modern CCFL LCDs that use PWM to dim the backlight.

It also provides an option to quickly measure the CR, so I found out that my TV at 75% contrast gives a 2K:1 CR with a 2.4 gamma and 3200:1 at 100% with a 1.75 gamma....so I made a 2.5 LUT at 100% et voilà: best of both worlds :cool:Spec is 2.4 gamma for displays with sufficient contrast (off the top of my head, I think it's 10,000:1 at reference levels) else you should be using the BT.1886 curve.

I fail to understand why you went through the trouble of supporting 3DLUT files when a simple PS script can do it all without the need to wait for a 96MB file to be loaded. yRGB 3DLUT files can't embed 3x1DLUT calibration data either.I think you over-estimate what this PS script can do, and under-estimate the value of LUT calibration.

There is research that supports the "(first) haloing -> artificial acutance -> perceptual sharpness even if the data is actually not high res" thesis here:
http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP092.pdf. See the top of p. 5 and the shape of the two filterss at the top left of p. 2.
(User hjulenissen on http://www.dpreview.com and also on the ImageMagick Forums pointed the existence of this paper to me.)In my experience, these kinds of tests are performed at "typical viewing distances" which are generally much further from the display (and using smaller displays) than HT enthusiasts will use. They are often done by testing groups of people from the general public, rather than trained observers, and don't have any eyesight requirements. (it's shocking how many people actually need vision correction, but believe their eyesight to be good)

Personally I like to sit up close, or have a big screen as anything less than about 45-50 degrees viewing angle is not immersive at all to me. At those sizes, it's purely about pixel-level image quality, and ringing like that is very obvious.

Well, local dimming doesn't come for free apparently and for instance a fast white object on a black background would end up with ghosting artifacts due to the fact that there isn't that many zones really. And if you don't enable it, then there doesn't seem to be any real world advantage over CCFL except for the lower power consumption.The disadvantages of local dimming are overstated by people who were never in the market for buying one of those sets in the first place. Local-dimming LED backlit displays are the closest thing we have to reference-class displays available for consumers today in my opinion. (Plasma has far too many image quality compromises to be considered "reference" in my opinion, even if the Kuros had good contrast and colour accuracy)

It is rare that haloing appears on my Sony HX900, and when it does, it is still a far better image than a non-local-dimming set puts out. (CRTs suffered far worse effects and no-one seemed to complain then)

I tried to change the gamma value of your script from 1.80 to 2.60 when set as "pure power curve" with my display set as REC.709, but I didn't see much change in the PQ...that might explain, but I will try test patterns.Use Yxy values in the greyscale/gamma measurements box, and use 0.312713, 0.329016 as your xy values.

Set Y values at various IRE points to adjust gamma in the 3DLUT. It takes a bit of going back-and-forth when displaying test patterns and updating the LUT, but you should be able to achieve a flat 2.40 gamma (or the correct BT.1886 values for your display) with a bit of patience. (note: raise Y values to lower Y on the display, and vice-versa)


And I only just noticed this but "measured IRE" should be chanced to something like "%stim".

IRE is a term for analogue voltages, and does not apply to digital video. (it is often used incorrectly, however, as people think the term is interchangeable)

[madshi]

Which dimensions (width, height) do such files usually have?
Well, any 25fps SD file has 99.99% chances of being PAL, hence EBU...so I still believe that 25fps SD files should be automatically recognized as EBU, and if you have a funky file you can always override it by pushing a hotkey if need be.
For some reason I already anticipated that you were going to ignore my question.

Am I correct to assume that if you give it say inputs for 20-100% in 10% increments, you will use linear interpolation for the LUT?
For *creating* the LUT, you mean? You'd have to ask yesgrey about that, I have not developed yCMS. From what I remember, he's actually using a better algorithm than linear interpolation. Similar to how Bilinear isn't the best algorithm for image upsampling.

Most LUT tools, when given data for 10% and 100%, will try to converge RGB to 0,0,0 rather than clip it, which results in significant greyscale errors and posterization near black. What should be done, is that linear interpolation should be used to follow the line down from the two smallest measurements down (e.g. 100-10 in this example, linearly down to 1% then clipped at 0%, or 20-10% linearly down to 1% then clipped at 0% if that's what the smallest measurements were)
I remember that yesgrey did a lot of extra work to try to avoid these problems. But I don't really know the details.

though development seems to have been put on hold indefinitely?
No, there's going to be a yCMS update with a bugfix "soon". I could say more, but this is really yesgrey's area, not mine.

It would actually be really useful for me if you could implement some kind of level clipping option in madVR. Right now we have the option to toggle output levels between PC (0-255) and Video (16-235) and for that, I have it set to PC.

We can also set whether an input source is using Video levels (16-235) or PC levels. (0-255) I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR to offer a "compressed levels" option to fix it. (30-218 if I have done the math correctly - or even a custom option that let you hit a shortcut for +/- on the range, adjusting black & white simultaneously)
Maybe sooner or later.

The issue I have is that while the anti-ringing filter manages to eliminate the obvious effects of ringing, there are still "ripple" effects on the image that are caused by the ringing.

I think I have posted this example before, it's much easier to illustrate with 3-tap vs 8-tap, but still affects 4-tap

As you can see, the right of the red (B) is still distorted by the ringing in Lanczos 8, even though the anti-ringing filter has removed most of the visible haloing.
Yes, but this is 3-tap vs 8-tap, and the difference is *much* smaller with 4-tap. Still, I agree that 4-tap has more ringing artifacts than 3-tap, even with AR on. However, Lanczos 4-tap also has more sharpness and less aliasing. So I still say that it's a matter of taste which to use. I don't think anybody should use Lanczos 8-tap, though, except maybe for extremely soft content where ringing isn't ever a problem at all.

[leeperry]

For some reason I already anticipated that you were going to ignore my question.
Hah, sorry for that! Well, you're the math genius and I'm the whiner :p

I would guess that sloppy PAL DVD encodes are anything between 860 and 500 pixels wide and proper ones are indeed 1024 pixels wide, height will depend on the AR really. But 25fps is PAL in essence, so I still believe that 99.99% of all 25fps SD files are PAL...be it advertisements, demos, home made stuff or whatever else involving undressed ppl.

If some chipmunk voices lovers like to encode NTSC DVD's to 25fps, their files are technically out of specs anyway.

I have some videos which have not been encoded correctly, and have compressed PC levels into a Video-levels file resulting in a raised black level. The only way I have been able to fix that so far, is to change my decoder to ffdshow for those specific videos, and use its levels feature to fix the black/white points. It seems like it would be a really easy fix for madVR
I would definitely also need some adjustable input levels in mVR in order to keep ffdshow out of the loop....two hotkeys would be great, otherwise we could always work it out with a simple PS script :)

Most people have only been evaluating gamut with 100% measurements for the longest time now. You really need to look at, at the very least, saturation in 25% increments.
Indeed, I've been repeatedly told that HCFR only shows a 2D view of a 3D gamut so WYS is definitely not WYG.

I've always been using this kind of test pattern if that makes any difference: http://thumbnails106.imagebam.com/21613/831a6c216128657.jpg (http://www.imagebam.com/image/831a6c216128657)

I suspect these scripts probably don't do a great job of it. You really need LUT capabilities for proper calibration. Unfortunately the tools don't currently exist to do this with yCMS files.
The gamut mapping math was worked out by yesgrey in matlab and proof-tested by several other colorimetry experts AFAIK. This said, I don't run a mastering house and we're all essentially looking for non-oversaturated truer-to-the-source colors. Besides, if you don't recalibrate your displays on a weekly basis using a freshly recalibrated Minolta professional spectrophotometer, you might very well soon be wasting your time IMHO.

ArgyllCMS does not do a very good job of creating LUTs in my opinion.
Well, why not taking actions and dropping an email to Graeme Gill? He's always happy to discuss about improvements to his software and he's very fast at releasing them too.

Personally I experience green "RBE"-like effects when watching modern CCFL LCDs that use PWM to dim the backlight.
Ah, you nail it! I thought I was imagining things but I definitely see very faint rainbows on the Windows desktop with a black background....this said, I don't see them in movies and I've survived 48Hz 4X DLP for years so I'm not afraid :p

[6233638]

For *creating* the LUT, you mean? You'd have to ask yesgrey about that, I have not developed yCMS. From what I remember, he's actually using a better algorithm than linear interpolation. Similar to how Bilinear isn't the best algorithm for image upsampling.Yes, I have found that using anything other than linear interpolation leads to errors/posterization when working with LUTs. I wasn't sure whether you were just passing the values onto yCMS rather than creating your own LUTs for madVR, so this discussion really belongs in the yCMS topic, sorry for that.

Yes, but this is 3-tap vs 8-tap, and the difference is *much* smaller with 4-tap. Still, I agree that 4-tap has more ringing artifacts than 3-tap, even with AR on. However, Lanczos 4-tap also has more sharpness and less aliasing. So I still say that it's a matter of taste which to use. I don't think anybody should use Lanczos 8-tap, though, except maybe for extremely soft content where ringing isn't ever a problem at all.That's true, and I agree that Lanczos 4 is better for aliasing and sharpness without a huge increase in ringing. (with AR on) But it's becoming a moot point now with the introduction of Jinc anyway, and I think I prefer Spline 3 over Lanczos these days. (I always go back and forth between the two, as they're very similar)

Indeed, I've been repeatedly told that HCFR only shows a 2D view of a 3D gamut so WYS is definitely not WYG.HCFR has the ability to take luminance and saturation measurements and graph them as well. In fact up until fairly recently, HCFR was the only software that implemented this until ChromaPure came along, and now CalMAN v5. (I had been bugging the CalMAN team about this for years)

The gamut mapping math was worked out by yesgrey in matlab and proof-tested by several other colorimetry experts AFAIK. This said, I don't run a mastering house and we're all essentially looking for non-oversaturated truer-to-the-source colors. Besides, if you don't recalibrate your displays on a weekly basis using a freshly recalibrated Minolta professional spectrophotometer, you might very well soon be wasting your time IMHO.My point is that you are only looking at 100% saturation there. You can easily correct 100% saturation, but what tends to happen is that everything below 100% saturation, ends up rather under-saturated. With most displays that have a gamut exceeding spec, it's often best to only reduce it slightly, for the sake of overall color reproduction vs only looking at 6 specific points that rarely actually show up in real-world content.

This is why I am hoping that at some point, yCMS will be updated so that you can create a LUT with corrections for 25/50/75% saturation in addition to just 100% saturation.


As for your comment regarding meters and calibration, I think you overstate the issue. Generally, display gamut/saturation tends not to drift much. You should only have to calibrate it once and you're usually good for the life of the display. At most I'd be checking it every few months or perhaps once a year with a high-end meter depending on the environment in which the display is being used. (shouldn't matter for home theater) An EyeOne Pro or even the ColorMunki Spectro are more than sufficient for calibrating gamut on consumer-grade displays. (and unless you have a grade-1 monitor you probably don't even need anything more than an EyeOne Pro at all)

Daily/weekly calibration is usually unnecessary with higher-end displays, and it's really only brightness and greyscale that drifts, so a colorimeter is suitable for that task.

For what it's worth, I use an EyeOne Pro in conjunction with a colorimeter (upgrading that to the latest "SpectraCal C6" now) and my Sony HX900 has barely drifted at all in the two years that I've had it, from probably at least 12 hours of use a day. It's impressive how stable high-end LED backlit displays can be. I've only made ±1-2pt adjustments to greyscale and contrast over the life of the display, and now only bother to update its calibration every couple of months. (which generally just involves changing contrast a notch or two, to bring the different backlight scanning modes to a uniform brightness)

If you have a projector though, that's another matter entirely. I would be wanting to calibrate that on at least a monthly basis, if not biweekly, as they tend to drift a lot as the bulb ages.

Well, why not taking actions and dropping an email to Graeme Gill? He's always happy to discuss about improvements to his software and he's very fast at releasing them too.I don't know that it's necessarily a problem with the software, but rather, that I am used to commercial tools, and disagree with the method used. With ArgyllCMS, the focus seems to be on taking as many measurements and making as many adjustments as you can to each individual point on a display.

In my experience, having too much data is a bad thing when working with LUTs, and you are actually best off to use as few points of adjustment as you can (but with repeated readings to ensure total accuracy of those points) while still being within a reasonable tolerance. That is to say, it's pointless to make a LUT that has adjustments in 1% brightness increases (or even at each individual RGB point) because meter accuracy/repeatability and drift over the length of time it takes to make these measurements, means that this LUT is going to be a complete mess and suffer from noticeable posterization/discoloration throughout the greyscale.

You are much better off with adjustments at 10% (or maybe 5% if your display is particularly bad) and using interpolation between those points for smooth results, even if it means the display is technically somewhat less accurate according to your meter.

For example, here is what I ended up with, after letting ArgyllCMS create a LUT for my display, rather than simply entering 10pt values into madVR and letting it create a LUT:

http://forum.doom9.org/showpost.php?p=1540847&postcount=230


P.S. 10-bit out from madVR would still be really nice when using LUTs to avoid posterization on the display...
Ah, you nail it! I thought I was imagining things but I definitely see very faint rainbows on the Windows desktop with a black background....this said I don't see them in movies and I've survived 48Hz 4X DLP for years so I'm not afraid :pAt lower brightnesses (48 nits reference for projectors) I personally have not been too troubled by RBE with single-chip DLP projectors. Plasma particularly and the CCFL LCDs I owned that used PWM to dim the backlight gave me headaches to watch though.

It seems to vary by person though. I know someone that is perfectly happy with their plasma, but can't watch DLP.

[MSL_DK]

What do you mean with "calibrate through mpc/madVR"? Do you mean you want to use yCMS to calibrate your display? Or what? Or do you want to use mpc/madVR just to show test patterns and calibrate your display by using the options in your display's setup menu?

By showing test patterns and calibrate my display by using the options in my display's setup menu.

[secvensor]

chroma upsampling comparison:

http://madshi.net/madVR/chroma upscampling comparison 1.png

A picture says more than 1000 words. I don't think I have to comment this, do I? :)

http://madshi.net/madVR/chroma upscampling comparison 2.png

These pictures are 400% enlarged. If you want to see the original 100% images, I've uploaded them here:

ATI - VMR9 - red fonts.png (http://madshi.net/madVR/ATI - VMR9 - red fonts.png)
ffdshow 2867 - red fonts.png (http://madshi.net/madVR/ffdshow 2867 - red fonts.png)
MPC HC YV12 Shader - red fonts.png (http://madshi.net/madVR/MPC HC YV12 Shader - red fonts.png)
Haali Renderer - red fonts.png (http://madshi.net/madVR/Haali Renderer - red fonts.png)
madVR 0.5 - red fonts.png (http://madshi.net/madVR/madVR 0.5 - red fonts.png)

extreme downscaling comparison:

http://madshi.net/madVR/extreme downscaling comparison.png

I'm aware that you usually don't downscale that much. But I still thought that the differences were interesting, so I'm posting them here.

The ffdshow gray background is *not* caused by incorrect settings (like output levels), I've double checked that. The gray background must originate from calculation errors in the scaling algorithm (lanczos, default settings). The ATI VMR9 and Haali Renderer downscaling results might not look that bad on a quick check, but you need to see it in motion! It sparkles like crazy, totally unwatchable. ffdshow's and madVR's downscaling don't sparkle, they're both stable and smooth.

visible benefits of more than 8bit processing:

I've some screenshots to demonstrate that higher than 8bit processing does help in specific situations, but the screenshots are too big to include them in this post, so I'll just post links instead. Please open the 3 links in different tabs of your browser and then switch between them. Please make sure that your browser does not rescale the images, so that there are no additional artifacts added by the browser scaling.

The following screenshots were made with images produced by the "madTestPatternSource" YCbCr test pattern generator. More details about that in this thread:

http://forum.doom9.org/showthread.php?t=146203

Now the comparison images:

ATI - VMR9 - colors.png (http://madshi.net/madVR/ATI - VMR9 - colors.png)
ffdshow 2867 - colors.png (http://madshi.net/madVR/ffdshow 2867 - colors.png)
Haali Renderer - colors.png (http://madshi.net/madVR/Haali Renderer - colors.png)
madVR 0.1 - colors.png (http://madshi.net/madVR/madVR 0.1 - colors.png)

This test pattern consists of colored rectangles which form a smooth full screen color gradiant. Properly displayed you should be able to see the rectangle borders, but you shouldn't see any visible patterns in the color gradiants.

Now if you look at the ATI VMR9 and Haali Renderer result, you do see some kind of pattern. It doesn't look that bad on the screenshot, but in motion it's really ugly, because the pattern changes with every frame. The ffdshow result is even worse. The madVR result is exactly how the test pattern is supposed to look. It also stays stable in motion. The patterns in the color gradiants are caused either by too low processing bitdepth or by rounding or truncating the final processing result down to 8bit. The madVR output is only that smooth because it uses proper dithering.

If you like these kind of comparisons, I'd suggest to try "madTestPatternSource" yourself. It's contained in the madVR archive. Use it to compare image quality yourself with the renderer you're usually using.

ATI - VMR9 - smallramp.png (http://madshi.net/madVR/ATI - VMR9 - smallramp.png)
ffdshow 2867 - smallramp.png (http://madshi.net/madVR/ffdshow 2867 - smallramp.png)
Haali Renderer - smallramp.png (http://madshi.net/madVR/Haali Renderer - smallramp.png)
madVR 0.4 - smallramp.png (http://madshi.net/madVR/madVR 0.4 - smallramp.png)

On a first check these 3 images might not look all that different. But if you look closer you should see two things: (1) The gradiants in the ATI VMR, Haali Renderer and madVR screenshots are smooth from left to right, while there are some unexpected bright bars standing out in the ffdshow gradiant. (2) In the ATI VMR, Haali Renderer and ffdshow screenshots the whole gradiant is covered by very small and faint vertical bars. In contrast the madVR screenshot doesn't show any such bars.

This test pattern works very well to test whether the processing queue beginning with upscaling and ending with final output somewhere somewhen ends up in rounded or truncated 8bit. If it does, you will see those faint vertical bars. The only way to produce a really smooth output with this test pattern is to do scaling and all the processing steps afterwards with more than 8bit. Also the final result must not be rounded or truncated down to 8bit. Instead only proper dithering preserves the smoothness.

Time to Upgrade the IMGs!
Jinc+anti-ringing filter

[madshi]

I would guess that sloppy PAL DVD encodes are anything between 860 and 500 pixels wide and proper ones are indeed 1024 pixels wide, height will depend on the AR really.
You know, it would have been nice if you had put a bit of effort into answering my question. Like actually investing 5 minutes to look at your PAL movies and give me a list of typical resolutions...

By showing test patterns and calibrate my display by using the options in my display's setup menu.
In that case I'd recommend to tell madVR that your display is not calibrated yet. You can do this by telling madVR to disable the calibration controls. Then after you've calibrated your display by using your display's setup menu, you can tell madVR that your display is already calibrated and how you calibrated it. That will allow you to change gamma curves/values through the madVR controls, without damaging your calibration. As the first step of the calibration you should make sure that GPU and madVR RGB output levels are set correctly, by checking black and white levels with a test pattern.

[njfoses]

Did you ever run LatencyMon (http://www.resplendence.com/latencymon) to find out which driver was causing the DPC spikes? I suspect it's your AMD drivers, as it doesn't seem to be an issue with Nvidia.


With pretty much all the scaling algorithms in madVR, going above 3-tap is detrimental to image quality. Jinc is the only possible exception, with 4-tap being slightly sharper than 3-tap without introducing that much more ringing. I am still leaning towards 3-tap Jinc now after spending more time with it, however.

8-tap Jinc (or Lanczos) are completely unusable no matter whether the GPU can handle them or not - they look terrible! More ≠ better.


With all the new versions out in the last few weeks i have not really been keeping up. Im in the same boat as you as i cant stand ringing. I have a dlp and prefer the film look. What would you recommend at this point for chroma, image up and image down on the latest madvr?

[pankov]

madshi,
thank you very much for the new and improved version of madVR with Jinc and the user asignable keyboard shortcuts.
I have a small complaint though - I'm no more able to control madVR's OSD via Girder (the old v3.3.9 to be precise). I guess you've changes something in the way you hook the keyboard events and it prevents other keyboard "emulators" including Microsoft's own "On-Screen Keyboard" to fake the input.
I've tried changing the "use only if media player has keyboard focus" checkbox but sadly this doesn't fix the issue.
So is there any chance you can change back to old keyboard hooking method?

[madshi]

I have a small complaint though - I'm no more able to control madVR's OSD via Girder (the old v3.3.9 to be precise). I guess you've changes something in the way you hook the keyboard events and it prevents other keyboard "emulators" including Microsoft's own "On-Screen Keyboard" to fake the input.
I've tried changing the "use only if media player has keyboard focus" checkbox but sadly this doesn't fix the issue.
So is there any chance you can change back to old keyboard hooking method?
I haven't really changed the hooking method. Can you please try to identify the exact version with which the problem started?

[madshi]

the image was shoot while the playback was still running this is maybe 1 of the frist frames.

like mention before stopping the playback fix the issue this is no serious error at all not "easy" to reproduce and there r workarounds it just happens to me alot resize it while the video is running or and stop it then is not to hard for me.

in windows mode it's fixable with move the point to the bottom and the mpc navi pops up (didn't ever notice this before...) it's still an issue in fse so yeah...

this bug is 1 year or even older so i report it.
i don't have xp 64 installed right now but i will test it at this weekend.

and xp64 is based on server 2003 x64 so not sure if is that easy to compare this os with xp sp3.



this is wrong be the way sorry

windows 7 screen with aero and proper osd:
http://s3.imgimg.de/uploads/retangle22528cc01png.png

windows 7 screen without aero:
http://s3.imgimg.de/uploads/retangle3a44f3b7apng.png
the present time is sky rocketing and it's tearing like hell
I've checked. This appears to be a bug in MPC-HC. The media player is responsible for telling the renderer where to render the video. MPC-HC tells madVR the correct size and position when starting in windowed playback. Then when pausing and stopping playback, then maximizing the player, then restarting playback, MPC-HC never tells madVR to change the playback size/position. So madVR continues to render at the (relative) pos/size which MPC-HC used in windowed playback. Nothing I can do about it. Would have to be fixed by the MPC-HC developers.

[pankov]

OK
I guess I've made a mistake
The MS one does work - it's only the Girder App that I'm using that is failing to work.
:(
I've just tried all 0.84.x versions and the problem is present since 0.84.0. v0.83.7 works fine - so it's the first version that introduced the configuration window for the shortcuts.

Are you familiar with Girder, the old version that was very popular a few years ago?
If you are not and have the will and time to try it I can send you a copy and a configuration file that you can use to test it.

[leeperry]

You know, it would have been nice if you had put a bit of effort into answering my question. Like actually investing 5 minutes to look at your PAL movies and give me a list of typical resolutions.
Well, I'm afraid we're really misunderstanding each other here as I've got a lot of 25fps SD files, some are DVD encodes, some aren't, some are 16:9, others 4:3, some are 640 pixels wide, others plain 1024....encodes aren't standardized you know.

I can assure you that my posts in this thread today took me more than 5 mins to write up and the only answer there really is is the good ole' "x<1025 + y<577", which IIRC is the usual SD automatic detection spec. 25fps and 50fps mean PAL, hence EBU. The same way anything SD and 23.976, 29.97 or 59.94fps is SMPTE-C. I did check the resolution of my files ;)

I also believe that a proper untouched PAL DVD remux should be done in 720x576 MKV with a DAR of either 4/3 or 16/9, because encoding upscaled pixels is a terrible idea to begin with.

I've watched a few SD PAL files today and I was forced to manually roll their gamuts because they were all recognized as SMPTE-C(none of them was 1024x576). You seem to currently treat all SD files as SMPTE-C apart from 1024x576=EBU...that'd be great if this could be worked out if any possible. :thanks:

Daily/weekly calibration is usually unnecessary with higher-end displays, and it's really only brightness and greyscale that drifts, so a colorimeter is suitable for that task.
All I know is that mastering houses usually have their CRT/CCFL LCD screens recalibrated on a weekly basis and that most consumer grade colorimeters might not be accurate enough(especially in dark areas) to warrant an extremist approach to colorimetry. But good to know that LED backlights are very stable colorimetry-wise :)

For example, here is what I ended up with, after letting ArgyllCMS create a LUT for my display, rather than simply entering 10pt values into madVR and letting it create a LUT:

http://forum.doom9.org/showpost.php?p=1540847&postcount=230
This could be an import problem in that .ti3 parser, isn't it? I've got a hard time believing that this nasty posterization problem would come from Argyll's LUT. I call on a misbehaving middle-man here. Argyll spends a lot of time smoothing its curves AFAIK.

As you know, Argyll has an accuracy level switch that goes from "low" to "very high"(which is undocumented for a good reason) and "medium" seems to be the right balance between too little measurements and too many of them that could temper with the results(especially with a spectrophotometer).

The "medium" 3x1DLUT graphic card's CLUT I personally build with Argyll make HCFR plenty happy: http://thumbnails105.imagebam.com/21623/6b8140216221991.jpg (http://www.imagebam.com/image/6b8140216221991)

So a detailed bug report might be in good order if your posterized picture is really what a vanilla Argyll LUT gave you.

[pankov]

I've watched a few SD PAL files today and I was forced to manually roll their gamuts because they were all showing up as SMPTE-C(none of them was 1024x576), so that'd be great if this could be worked out if any possible. :thanks:
leeperry,
I don't want to offend you by any means but why is it so hard for you to answer the simple question madshi is asking? Instead of saying what the resolutions of these files were not just say what they were. Even provide a sample or two. I'm sure this will help him better understand your issue and probably provide a better solution. I'm not saying that I disagree with your logic about 25/50fps being PAL but from my experience madshi asks his questions for a reason so, please, be kind enough to provide him an exact answer.

Again, I'm posting this only to help you both clear everything up and avoid the conflict that seems to be building up.

[Gser]

Bobbed deinterlacing doesn't seem to work. Running on madvr v0.84.3, win7 b4bit, AMD 5870 driver 12.8. I'm not exactly sure how long its been broken.

[suanm]

The download dassent work correctly from the doom9,thus,I download madvr v0.84.3 from original address,but i find another new version madvr v0.9 I downloaded,i want to know what difference the madvr v0.9 and madvr v0.84.3 is? madvr v0.9 file size is quite small,why so ?

[cyberbeing]

madVR 0.9 is madVR's 9th revision and extremely old.

madVR 0.84.3 is madVR's 99th revision and the newest available.

[Xaurus]

madshi,

For 720p material upscaled to 1080p, when using heavy algorithms like Jinc 8-tap the render time goes from ~3ms to ~30ms. Now, this is fine, the gtx 660 can do it.
But. Is it only me or does this heavily increased render time also affect audio/video sync? I seem to find myself adjusting the sync more often when going back and forth between 1080p material and 720p material.

[jmone]

I'm also surprised that the 550ti can't handle it. Are we talking Jinc3 AR for Luma and maybe some SoftCubic or Bicubic variant for Chroma? And the 550ti can't handle it when deinterlacing is activated? That would mean that deinterlacing must eat a lot of performance, I would say, more than I thought it would. Have you tried disabling IVTC/pulldown detection in the NVidia drivers? That's probably not a good solution, but it would be interesting to see whether that brings the 550ti up to speed. (Not even sure if NVidia has such a setting, AMD does.)

OK, did some more testing and it is the Deinterlacing on 1080/60i (either VC-1 or h264) material (reported in madVR as 29.97) that pushed the GPU Clock to 96% using Jinc3 AR for Chroma (Image settings makes no difference).

The 1080/60i test clips played fine if I:
- Turned off AR (80% GPU)
- Used M-N (37%)
- Turned off Deinterlacing (50% GPU) (note: turning off NVidia pull down did not impact GPU at all).

In the way of comparison Jinc3 AR played the following test clips fine:
- h264 1080/50p (83% GPU)
- h264 or VC-1 1080/50i (92% GPU)
- h264 or VC-1 10880/23.976 (40% GPU)

From what I can tell, the limit on the 550ti with Jinc3 AR is 1080/50i with 1080/60i just a little too much.

[ryrynz]

@Xaurus It will be affecting sync, Madshi is it possible to have MadVR communicating to LAV a delay value based upon the render time so this isn't a problem?

[leeperry]

I wasn't paying attention at the time and I can't find much infos either in the OP, the changelog or when running an "internal decoders" search in this thread, but is there any point in using them instead of the external LAV decoder? YV12 is YV12, right? Can they also use CUDA? They don't show up in PotP(I have enabled them in mVR's config), I even tried to manually register avcodec-mvr-53.dll & avutil-mvr-51.dll :o

[madshi]

The MS one does work - it's only the Girder App that I'm using that is failing to work.
:(
I've just tried all 0.84.x versions and the problem is present since 0.84.0. v0.83.7 works fine - so it's the first version that introduced the configuration window for the shortcuts.
Hmmmmm... Can you try whether pressing F2 works? You know, F2 is available if you toggle some of the settings. F2 is handled identically in v0.84.0 vs. v0.83.7, so I'm wondering if that still works. Also, can you try changing the settings to use some very simple keyboard shortcuts? E.g. just "Ctrl+Something"? Does that also not work?

I've watched a few SD PAL files today and I was forced to manually roll their gamuts because they were all recognized as SMPTE-C(none of them was 1024x576).
So, which exact resolution did these files have? Give me a list of maybe the first 15 SD PAL files you find that are recognized as SMPTE-C.

For 720p material upscaled to 1080p, when using heavy algorithms like Jinc 8-tap the render time goes from ~3ms to ~30ms. Now, this is fine, the gtx 660 can do it.
But. Is it only me or does this heavily increased render time also affect audio/video sync?
Render times do *not* affect audio/video sync. If render times are too high, you will get frame drops. As long as you don't have frame drops, sync should always be the same, regardless of how long rendering times are.

OK, did some more testing and it is the Deinterlacing on 1080/60i (either VC-1 or h264) material (reported in madVR as 29.97) that pushed the GPU Clock to 96% using Jinc3 AR for Chroma (Image settings makes no difference).

The 1080/60i test clips played fine if I:
- Turned off AR (80% GPU)
- Used M-N (37%)
- Turned off Deinterlacing (50% GPU) (note: turning off NVidia pull down did not impact GPU at all).

In the way of comparison Jinc3 AR played the following test clips fine:
- h264 1080/50p (83% GPU)
- h264 or VC-1 1080/50i (92% GPU)
- h264 or VC-1 10880/23.976 (40% GPU)

From what I can tell, the limit on the 550ti with Jinc3 AR is 1080/50i with 1080/60i just a little too much.
Ok. So I guess the main problem is not the deinterlacing itself, but the 50p/60p framerate. Probably if you played true 1080p50/60 content, you would have the same problem. Can you double check that?

[jmone]

Ok. So I guess the main problem is not the deinterlacing itself, but the 50p/60p framerate. Probably if you played true 1080p50/60 content, you would have the same problem. Can you double check that?

Nope - as reported in my post I did test true h264 1080/50p (no 60p) material and it uses 83% of the GPU.

[madshi]

Ok, so 1080i50 deinterlacing takes about 10% GPU. The real trouble maker is 1080p60/60p Jinc3 AR scaling, though. Obviously, for 1080p24 GPU consumption would be only about half as much. Meaning, the 550Ti is probably fine for everything up to 1080i50/p50, when using Jinc3 AR. 1080p60 might be borderline. 1080i60 slightly too much. It's very tight, though, so I think the 560 should be able to handle it?

[jmone]

That is my conclusion as well (it is probably even higher than an additional 10% as I think the GPU is maxed at 96% and dropped frames badly). The 550Ti is fine up to and including 1080/50i / 50p (and I guess 60p) but is really pushing this GPU to the max so the the extra overhead of deinterlacing 60i is just a bit too much. For a HTPC friendly GPU the 550Ti does not cut it at these high GPU usage as the temp and fan speed spikes anyway. I'm hoping the 660 has much more head room or Jinc3 AR will be too taxing for any current HTPC friendly GPU :(

[madshi]

If you compare the data, the 660 is clearly on another level:

550Ti: 28.8 GT/s, 98.5 GB/s, 691 GFLOPS
660: 78.5 GT/s, 144.2 GB/s, 1881 GFLOPS

[leeperry]

Give me a list of maybe the first 15 SD PAL files you find that are recognized as SMPTE-C.
Your wish is my command:

Width : 640 pixels
Height : 480 pixels
Aspect ratio : 4/3
Frame rate : 25.000 fps

Width : 624 pixels
Height : 336 pixels
Aspect ratio : 1.857
Frame rate : 25.000 fps

Width : 608 pixels
Height : 320 pixels
Aspect ratio : 1.900
Frame rate : 25.000 fps

Width : 960 pixels
Height : 540 pixels
Aspect ratio : 16/9
Frame rate : 25.000 fps

Width : 720 pixels
Height : 412 pixels
Aspect ratio : 16/9
Frame rate : 25.000 fps

Width : 720 pixels
Height : 528 pixels
Aspect ratio : 4/3
Frame rate : 25.000 fps

Many of them were 640x480 or 720x528, I also have some PAL DVD encodes that are 800 pixels wide burned on DVD-R somewhere and I just saw that 720x576 is indeed recognized as EBU.

I rest my case that 25/50fps SD is PAL in essence and will never ever use the NTSC colorspace, apart from funky way-out-of-specs accelerated IVTC'ed NTSC DVD encodes.

[madshi]

I wasn't paying attention at the time and I can't find much infos either in the OP, the changelog or when running an "internal decoders" search in this thread, but is there any point in using them instead of the external LAV decoder? YV12 is YV12, right? Can they also use CUDA? They don't show up in PotP
There's no real benefit over LAV at the moment. A while ago I had artifacts with LAV when playing back MPEG2 content, but that problem appears to be fixed in newer LAV builds. Currently madVR's internal decoders are software, only. I think in order to use them in PotP, you have to manually add them. But really, if you have LAV installed, there's currently no reason to use the madVR internal decoders.

[Gser]

Bobbed deinterlacing doesn't seem to work. Running on madvr v0.84.3, win7 b4bit, AMD 5870 driver 12.8. I'm not exactly sure how long its been broken.

It seems bobbed deinterlacing is broken an all older versions of MadVR for me now as well. Must be a driver problem. Will continue testing.

[MasterMeNL]

Now I found something interesting.
Both upscaling algorithms to Jinc8 with AR enabled.
10-bit h264, 32 decoder queue, 24 upload & render queue, 16 present queue.
720p 23,976fps movie to 2560x1440 = 96% usage of a GTX 680 lightning.
Since I don't want a heater in my room I decided to change it to Jinc3 with AR enabled, I don't see any difference anyway.
I never expected that playing back stuff would be heavier than really demanding games.

[druneau]

Since you had large render queues, did you wait for them to fill up to measure stable gpu usage?

[NicolasRobidoux]

Don't use Jinc8.

[Gser]

Bobbed deinterlacing doesn't seem to work. Running on madvr v0.84.3, win7 b4bit, AMD 5870 driver 12.8. I'm not exactly sure how long its been broken.It seems bobbed deinterlacing is broken an all older versions of MadVR for me now as well. Must be a driver problem. Will continue testing.

BUG FOUND!

It seems that deinterlacing fails on Bottom Field First Scan order even when it is forced in the decoder and MadVR. I think it deinterlaces in Top field first mode.

[madshi]

Both upscaling algorithms to Jinc8 with AR enabled.
10-bit h264, 32 decoder queue, 24 upload & render queue, 16 present queue.
720p 23,976fps movie to 2560x1440 = 96% usage of a GTX 680 lightning.
Ouch. But Jinc3 AR is better, anyway. How much usage does your 680 have with Jinc3 AR?

BUG FOUND!

It seems that deinterlacing fails on Bottom Field First Scan order even when it is forced in the decoder and MadVR. I think it deinterlaces in Top field first mode.
Sample? GPU? OS?

[Gser]

Sample? GPU? OS?
win7 64bit, AMD 5870 driver 12.8

Sample 1 (http://dl.dropbox.com/u/59988358/cut.m2v)
Sample 2 (http://dl.dropbox.com/u/59988358/cut1.ts)

[MasterMeNL]

Ouch. But Jinc3 AR is better, anyway. How much usage does your 680 have with Jinc3 AR?
Around 45-55%. Note that both upscaling algorithms are Jinc3 AR.
This is on the default clock (1111Mhz) on the default BIOS. I don't use the LN2 bios right now since it always has all power stages on = more power usage (no problem) = more heat (problem).
This card has a lot of OC potential but I don't need it yet.

I think the main reason that it uses so much is my 2560x1440 resolution. It's ~80% more than the average 1080p.

BTW: It uses 1750-1850 MiB VRAM, and I have desktop composition in full screen disabled. I want maxium quality for my videos.

Off-topic question: I use MPC-HC with the default subtitle renderer. However, it's slow so I set it to buffer 60 frames and disabled 'round power of two'. This sometimes causes flickering with certain complex animated subtitles.
But when I set it to render real time, it does lag the video when there is some really complex animation going on. Is there any way to fix this? CPU is an i7 3820, 24GB ram and it's around 5-10% when playing stuff. I refuse to use xy-VSFilter because it renders the subs at video resolution which is only 720p and I want sharp, crisp subs (a big difference between 720p subs and 1440p subs).
Is there any way to let it use more of my CPU so that it doesn't lag? I tried some multi-threaded version but results are the same.

[mzso]

Are you talking about custom pixel shader support, similar to what MPC-HC supports for EVR? Or are you talking about a dedicated sharpening algorithm implemented in madVR, with comparable quality to good AviSynth sharpening scripts? Both might come some day, but custom pixel shader support will likely come first.
What is you stance on framerate multiplication? Or will it be possible with custom shaders?


No, I'm not planning to create a 64bit version soon. Maybe some day, but not anytime soon. The reason? Because the possible benefit is not big enough compared to the development time it would cost me.
What is the source of the complexity? As I understand madVR works for the most part with the GPU which is separate from the AMD64 cpu architecture. (Just curious)

[madshi]

win7 64bit, AMD 5870 driver 12.8

Sample 1 (http://dl.dropbox.com/u/59988358/cut.m2v)
Sample 2 (http://dl.dropbox.com/u/59988358/cut1.ts)
On a quick check EVR seems to behave identical? These files are not really native interlaced video content. Probably they were originally 50i, then converted to 60i by using field blending. With true native interlaced content, every interlaced field is from a different time, so there's motion between every field. With both of your samples, there are always 2 fields which are from the same time. So it's almost progressive. However, one of those fields has another field blended it. Basically the content is terrible. Please double check whether you get better results with EVR, but I don't think so.

Off-topic question: I use MPC-HC with the default subtitle renderer. However, it's slow so I set it to buffer 60 frames and disabled 'round power of two'. This sometimes causes flickering with certain complex animated subtitles.
But when I set it to render real time, it does lag the video when there is some really complex animation going on. Is there any way to fix this? CPU is an i7 3820, 24GB ram and it's around 5-10% when playing stuff. I refuse to use xy-VSFilter because it renders the subs at video resolution which is only 720p and I want sharp, crisp subs (a big difference between 720p subs and 1440p subs).
Is there any way to let it use more of my CPU so that it doesn't lag? I tried some multi-threaded version but results are the same.
The xy-vsfilter developer, nevcairiel and I have worked on a new subtitle interface which will allow xy-vsfilter and madVR to work together in a similar way to the internal MPC-HC subtitle renderer - but with all media players. I think the new interface should avoid such problems as you're reporting, but we'll have to wait and see. Not sure when there will be an xy-vsfilter version available with support for the new interface. That depends on the xy-vsfilter developer.

[madshi]

What is you stance on framerate multiplication? Or will it be possible with custom shaders?
It will not be possible with custom shaders. Not sure what you mean with "my stance". I don't plan that for madVR anytime soon, if that's what you mean.

What is the source of the complexity? As I understand madVR works for the most part with the GPU which is separate from the AMD64 cpu architecture. (Just curious)
Pixel shaders are only a small part of madVR, unfortunately. I wish I could write pixel shaders all day instead of fighting with DirectShow, Direct3D, MSVC++ and all sorts of other things.

[6233638]

Around 45-55%. Note that both upscaling algorithms are Jinc3 AR.
This is on the default clock (1111Mhz) on the default BIOS. I don't use the LN2 bios right now since it always has all power stages on = more power usage (no problem) = more heat (problem).
This card has a lot of OC potential but I don't need it yet.

I think the main reason that it uses so much is my 2560x1440 resolution. It's ~80% more than the average 1080p.

BTW: It uses 1750-1850 MiB VRAM, and I have desktop composition in full screen disabled. I want maxium quality for my videos.Actually, I think the reason your numbers are so high, is because you turned the queues up as high as they could go. Reset to the defaults and you should see more reasonable numbers.

[Gser]

On a quick check EVR seems to behave identical? These files are not really native interlaced video content. Probably they were originally 50i, then converted to 60i by using field blending. With true native interlaced content, every interlaced field is from a different time, so there's motion between every field. With both of your samples, there are always 2 fields which are from the same time. So it's almost progressive. However, one of those fields has another field blended it. Basically the content is terrible. Please double check whether you get better results with EVR, but I don't think so.
Yeah seems your right, it is completely unbelievable that a broadcast station would air and shoot their material like this.

[madshi]

High queues should *not* increase average GPU consumption. GPU consumption will be higher only while the queues are filling up. Once they're filled, GPU consumption should be identical to smaller queues.

[MasterMeNL]

The xy-vsfilter developer, nevcairiel and I have worked on a new subtitle interface which will allow xy-vsfilter and madVR to work together in a similar way to the internal MPC-HC subtitle renderer - but with all media players. I think the new interface should avoid such problems as you're reporting, but we'll have to wait and see. Not sure when there will be an xy-vsfilter version available with support for the new interface. That depends on the xy-vsfilter developer.
This is great news, if that gets implemented that my setup is perfect!
Actually, I think the reason your numbers are so high, is because you turned the queues up as high as they could go. Reset to the defaults and you should see more reasonable numbers.
High queues should *not* increase average GPU consumption. GPU consumption will be higher only while the queues are filling up. Once they're filled, GPU consumption should be identical to smaller queues.
Queues only increase the use of VRAM and RAM if I'm correct, so if something happens there are plenty of frames before it'll actually drop stuff so it has plenty of time to catch up.

Update: GPU usage is anywhere between 20%-60% on a 720p video with Jinc3 AR. I guess it depends on the video's complexity.

Off-topic question again: Is there any way for ReClock to just read the media speed instead of interrupting the audio when it's measuring stuff and applying it.

[6233638]

For what it's worth, I've just checked by downloading Kill Bill off iPlayer, opening it in madVR, and comparing that to the Blu-ray, and those files are also being wrongly detected as SMPTE-C. (colour is obviously wrong) It's an 832x468 25fps FLV.

I'd be surprised if there's anything below 720p at 25/50fps that is not supposed to be EBU/PAL. (or possibly BT.709)


High queues should *not* increase average GPU consumption. GPU consumption will be higher only while the queues are filling up. Once they're filled, GPU consumption should be identical to smaller queues.Sorry I wasn't clear with my post, I had meant that the reason VRAM usage was so high, was the high number of queues. (and usage definitely spikes until they are full)

Off-topic question again: Is there any way for ReClock to just read the media speed instead of interrupting the audio when it's measuring stuff and applying it.Can you clarify this? ReClock should not be "interrupting the audio".

[SamKook]

Can you clarify this? ReClock should not be "interrupting the audio".

When the framerate of the video get detected, reclock reinitialize or something similar and the audio cut for a fraction of a second.

I deactivated the portion of reclock that change the fps since it bothered me too much and only kept it for the WASAPI audio.

As far as I know, it's not possible to avoid this little interruption but it would be great if there was a way.