madVR - high quality video renderer (GPU assisted)

[KoD]

A feature request, if possible: some keyboard shortcut to switch the display refresh rate. I have files badly tagged as 23.976 fps, but when played at 23.976 the number of dropped frames increases continuously. However, when played at 60fps, everything is smooth, no dropped frames.

Another question is, what happens when the file has VFR? The file is tagged as 23.976fps, but in fact the duration of the frames varies continuously. How does madVR handle this?

And a bug report: when using the "switch to matching display mode", the switch does not really happen if the "list all display modes madVR may switch to" list is empty. Settings used:

switch to matching display mode = enabled
switch to matching display mode = when media player goes fullscreen
restore original display mode = enabled
restore original display mode = when media player is closed
general settings - delay playback start until render queue is full = on
general settings - delay playback start after seeking, too = on
general settings - enable windowed overlay = off
general settings - enable automatic fullscreen exclusive mode = off
general settings - disable desktop composition = off
general settings - use Direct3D 11 for presentation (Windows 7 and newer) = on
general settings - present a frame for every VSync = on
general settings - use a separate device for presentation = off
general settings - use a separate device for DXVA processing = off

Happens for any file fps (23.976p, 29.970p, etc).

In nvidia control panel, this is the list of available display modes (and they all work when switched to manually, or specifically including them in the "list all display modes madVR may switch to" list):
23Hz, 24Hz, 29Hz, 30Hz, 50Hz, 59Hz, 60Hz

PS: my 500th post! yay! :)

[huhn]

in most cases "display modes" will choice the wrong refreshrate because it is usually selected by the AVG FPS. but smoothmotion at 60 hz can handle VFR perfectly.

theoretically there are ways to add informations like min FPS, max FPS and AVG FPS. but this is rarely used in practice and AFAIK madVR can't make use of it.

[MokrySedeS]

A feature request, if possible: some keyboard shortcut to switch the display refresh rate. I have files badly tagged as 23.976 fps, but when played at 23.976 the number of dropped frames increases continuously. However, when played at 60fps, everything is smooth, no dropped frames.

You should probably fix the affected files, but if you insist then you can use madVR's file tagging system, which is even better than suggested shorcuts in your case.
* added tag "frameRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
* added tag "refreshRate=%value%", e.g. 23.976, 24.000, 23, 24, ...



And a bug report: when using the "switch to matching display mode", the switch does not really happen if the "list all display modes madVR may switch to" list is empty.It's not a bug, it's a feature! :P
But seriously, madVR by design will switch only to the modes listed it this field.

[Ver Greeneyes]

Is there a keyboard shortcut to toggle black bar detection or cropping? I don't need black bar detection that often, and there will probably always be videos on which it doesn't quite work, but I'd like to be able to enable it easily when the black bars are obvious and consistent.

[KoD]

in most cases "display modes" will choice the wrong refreshrate because it is usually selected by the AVG FPS. but smoothmotion at 60 hz can handle VFR perfectly.

theoretically there are ways to add informations like min FPS, max FPS and AVG FPS. but this is rarely used in practice and AFAIK madVR can't make use of it.
Hmm, I don't know. Does madVR really know the duration of each frame in order for its smooth motion algorithm to transition from one frame to the next at the right time, and not at multiples of, let's say, 23.976fps if the file is tagged with 23.976fps? And if a frame has a long duration, will it show a blend of frames only close to the transition points, or will it show blended frames for most of the duration of that single long frame? It's not min and max fps that would be required for proper VFR handling, but knowing the duration of the frame, I think. After all, a container such as mkv lets you specify that avg fps (like 23.976fps), but the actual duration of each frame is in no way linked to the value of this field. The frame timecodes can be anything - this is how VFR is actually implemented. One can make a 5 minutes video file which contains only one frame. I don't know if and how this info gets sent through the playback chain, maybe it would require a new API on the renderer for the player to send this info from the splitter? And you are right, it's not possible to properly see VFR content at a display refresh rate of 23.976Hz. One would need to set the display rate as high as possible (60Hz for most TVs), so that frames in the VFR file with durations smaller than 41.71ms would be properly displayed at the right moment.

You should probably fix the affected files, but if you insist then you can use madVR's file tagging system, which is even better than suggested shorcuts in your case.

I was going through a folder of anime music videos. It's quite a big list of files collected over a large period of time, many of them are fan made (so, no chance of getting them redone), and in all media container formats used over years: mpg, avi, ogm, mp4, mkv. :)

Renaming them would involve opening each one several times, each time at a different display rate selected before starting playback, finding the one that does not cause jitter, and then remuxing them. It would be too time consuming to manually do this for every one to add a tag to its filename, and I don't see any automated way of doing this.

[SweetLow]

What purpose would you use that for?

Enable or disable madVR dithering (right now). Intel well dither in hardware when out 10 bit on 10 bit device (HDMI TV in my case), but when out 10 bit on 6 bit (internal eDP panel of notebook in my case) it not dither properly (only dither from 8 bit to 6 bit, AFAIK by my tests).


Intel/NVidia: DXVA2 image + Bilinear chroma upscaling -> DXVA chroma up

Thanks. Very fast reaction :)

P.S. To Intel users - as i see in my tests, dxva deinterlacing + dx11 rendering path don't work well with "frames present in advace" set to more then 2 (easy visible jumps in motion parts of image). dx9 work well with 4 frames. But lower value slightly increase GPU and power consumtion.

[JohnLai]

Question, is it possible to use madvr's smooth motion together with SVP? (gtx 980 and core i7 for instance)

[huhn]

AFAIK SVP provides proper timestamps. so yes.

[huhn]

Hmm, I don't know. Does madVR really know the duration of each frame in order for its smooth motion algorithm to transition from one frame to the next at the right time, and not at multiples of, let's say, 23.976fps if the file is tagged with 23.976fps? And if a frame has a long duration, will it show a blend of frames only close to the transition points, or will it show blended frames for most of the duration of that single long frame? It's not min and max fps that would be required for proper VFR handling, but knowing the duration of the frame, I think. After all, a container such as mkv lets you specify that avg fps (like 23.976fps), but the actual duration of each frame is in no way linked to the value of this field. The frame timecodes can be anything - this is how VFR is actually implemented. One can make a 5 minutes video file which contains only one frame. I don't know if and how this info gets sent through the playback chain, maybe it would require a new API on the renderer for the player to send this info from the splitter? And you are right, it's not possible to properly see VFR content at a display refresh rate of 23.976Hz. One would need to set the display rate as high as possible (60Hz for most TVs), so that frames in the VFR file with durations smaller than 41.71ms would be properly displayed at the right moment.

mkv doesn't use FPS it only uses timestamps for each individual frame. so VFR in mkv is a no problem for madVR. a VFR file without timestamps(or something similar) would ran async so they all have "timestamps" or they are broken. and this information is provided.

max FPS is a good way to choice a good refreshrate by simply using that value. for SM the highest value is by far the best but not everyone wants to use SM.

madVR SM blending is very simple (in theory at least...) for example it has to display a frame for 20 ms and the time stamps of the frames show frame 1 should get the first 5 ms of these 20 ms and frame 2 the other 15 ms than they are blending.

so a "long" frame isn't blended most of the time only maybe at the end or the start if other frames share some time of that display interval.

[KoD]

mkv doesn't use FPS it only uses timestamps for each individual frame. so VFR in mkv is a no problem for madVR. a VFR file without timestamps(or something similar) would ran async so they all have "timestamps" or they are broken. and this information is provided.

max FPS is a good way to choice a good refreshrate by simply using that value. for SM the highest value is by far the best but not everyone wants to use SM.

madVR SM blending is very simple (in theory at least...) for example it has to display a frame for 20 ms and the time stamps of the frames show frame 1 should get the first 5 ms of these 20 ms and frame 2 the other 15 ms than they are blending.

so a "long" frame isn't blended most of the time only maybe at the end or the start if other frames share some time of that display interval.
There is no explicit avg frame rate field in mkv files, indeed. But that purpose is fulfilled by a tag called "DefaultDuration". This is why you can have mkv files which madVR says they have 23.976fps, but when you set the display rate at 23.976Hz and try to play the file, it's a stuttering mess, and the dropped frame counter increases continuously. Perhaps this is the reason for the frame rate in filename tag functionality, to explicitly tell madVR what the framerate actually is, instead of trusting the one the splitter reads from the file and passes it up the chain. This only works for constant frame rate content, however.

The issue, I imagine, is that madVR does not honor frame durations, but instead bases its computations on the average frame rate. Which works fine most of the times, for straight to mkv remuxes or encodes of BluRay or DVD content (well, some DVDs), and that's why most people are not affected.

Or maybe the implementation is fine, it honors the proper individual frame duration, and works ok if I keep watching everything at 60Hz (with smooth motion on, and smooth motion only affecting the one or two frames around each transition point)? In that case it would just be my fault for drinking the videofile kool-aid and insisting on switching the display refresh rate to what the file is supposed to be at.

To be honest, I would welcome a proper implementation of frame duration display more than the constantly increasing number of resizing algorithms. The available algorithms have reached a level where the difference in quality is indistinguishable (and I mean here during actual movie viewing, and not doing comparisons of zoomed in screenshots). The stuttering during the playback of some files is so much more visible than whether there is any benefit when using anything above Jinc3.

[SweetLow]

* added new profile rule script variables "display"

Umm... If this is my wish realization - it's work not as expected. In my case this variable always equal to the name of first device in devices list, not actual device of player window :confused:

[nevcairiel]

To be honest, I would welcome a proper implementation of frame duration display

madVR implements frame timings quite well, however the entire system is quite limited by hardware.

The "problem" is of course that you can only present a new frame in every VSYNC, so if your display is set to 23.976, then you can present exactly 23.976 frames per second (and exactly at pre-defined times as well, a new frame every 41.7ms). If your file happens to have more frames per second, then madVR has to do the best it can, which means dropping a lot of frames. This can easily result in rather stuttery playback - but its not madVRs fault really, since it just can't show you anymore frames. Of course you could blame it for picking the wrong refresh rate, but it can only act on the information provided to it - scanning the entire file for the greatest common denominator of frame rates is hardly viable.

Assuming your file has both 23.976 and 29.970 parts, then you could set it to 29.970 Hz instead (or 59.94, which is more common), but then you couldn't show the 23.976 parts properly, because the frame timings of a 23.976 stream don't match a 59.94Hz VSYNC interval, and some frames would fall in-between VSYNCs.

If you want all possible videos to look properly, you need an infinite refresh rate monitor (or variable refresh rate for that matter). You can usually get pretty close by running at say 120Hz, as that is a clear multiple of 24 and 30, which are rates many "vfr" files use internally (some animes seem to like to switch between 24 and 30 for some reason). But if your video is real variable frame rate, then that won't save you either - although the short individual frame times at 120Hz (just 8.3ms) make any judder from a mis-matching framerate far less obvious.

One solution to that is Smooth Motion, which simulates an infinite refresh rate display, and then uses blending to map the frames as good as it can to your display refresh rate.

[chros]

Enable or disable madVR dithering (right now). Intel well dither in hardware when out 10 bit on 10 bit device (HDMI TV in my case), but when out 10 bit on 6 bit (internal eDP panel of notebook in my case) it not dither properly (only dither from 8 bit to 6 bit, AFAIK by my tests).
Which CPU , chipset, driver, OS do you have?
I don't see any 10bit option in my driver settings (see my signature for details).
Thanks

[SweetLow]

Which CPU , chipset, driver, OS do you have?
I don't see any 10bit option in my driver settings (see my signature for details).
Thanks
It's not the driver setting, it's settings of madVR - use of DX 11 presentation + set more then 8 bitdepth in device properties+use of exclusive FS.

[Ruben0]

I'm using the highest quality algo the GPU offers. What performance hit do you mean? GPU power? YADIF is done by LAV via CPU, so the GPU doesn't suffer. DXVA deinterlacing is done by the GPU. So it's clear that the GPU has more work to do when doing DXVA deinterlacing. It depends on the GPU model, though, because some have dedicated hard wired circuits to do deinterlacing, while others use pixel shader power for that. When using YADIF, make sure you use 50p/60p (Video) output, because that's what DXVA does (by default), too.


thanks for your answer.
I was mistaken the rendering and deinterlace stats, the big performance hit is in rendering while using nnedi3-32 in chroma upscaling and image doubling for dvd playing. The deinterlace stats are always low. I have an nvidia gtx 770 4GB.

keep up your excellent work!

[chros]

It's not the driver setting, it's settings of madVR - use of DX 11 presentation + set more then 8 bitdepth in device properties+use of exclusive FS.
Yes, I know. Maybe my TV and/or my receiver doesn't support it.

[SweetLow]

Maybe, but it's easy to see actual state by moninfo or any other EDID info viewer. And, more important, the 10 bit device is not necessary to get 10 bit rendering.

[pankov]

madshi,
is it intentional that the hidden option to show the black bar detection using the ShowBlackBars empty file doesn't actually work if the "crop black bars" option is not enabled?
I want to debug a few situations with some TV stations with weird aspect ratios and hard coded black bars and it will be very useful if I can see what madVR detects and would crop but without actually cropping it so I can verify it visually.

I'd like also to ask a question about the new rotation feature.
Is it intentional that the subtitles (both external and internal ones) are rotated together with the picture ... and moved almost to the center of the image? While the centering seems like a bug I'm not exactly sure about the rotation ... I can see merit in both behaviors - showing the subtitles normally/horizontally while rotating only the video (because for example it was shot in "portrait" and not "landscape" mode) ... or rotating everything because the display that's used for presentation is rotated and the user wants everything rotated ... so it seems it might need to be optional.

[AngelGraves13]

Those threads you linked to don't look like simple deblocking at all. They seem to be targetted at low quality Anime content, and they do all sorts of things, like removing noise, tighten up edges etc etc. You could use AviSynth via ffdshow raw video processor to do *exactly* what those 2 threads suggest in real time video playback (if your CPU is fast enough).

Fair enough. I'd settle a simple deblocker that has 3 settings like the debanding. Low, Medium, High. I'd likely just leave it on High just like the debanding filter.

Does deblocking just work on 4x4, 8x8, and 16x16 blocks? MPEG-2 was 8x8 only? I hardly notice any blocks in MPEG-4 unless it's a low bitrate file. MPEG-2 needs deblocking regardless of bitrate or resolution. Even the early blu-rays with MPEG-2 can look quite bad.

If it was to be implemented, would the deblocking be done before or after image and chroma upscaling?

[nevcairiel]

If it was to be implemented, would the deblocking be done before or after image and chroma upscaling?

Before image upscaling would be best, not sure about chroma though.
Image upscaling could otherwise create new artifacts around the block edges (or smooth them, depending on the scaler) which makes a deblock filters job ever so much harder.

[AngelGraves13]

Before image upscaling would be best, not sure about chroma though.
Image upscaling could otherwise create new artifacts around the block edges (or smooth them, depending on the scaler) which makes a deblock filters job ever so much harder.

That's what I was thinking too.

I wonder if the debanding is done before as well.

[huhn]

That's what I was thinking too.

I wonder if the debanding is done before as well.

it is.

[Danne S]

Is there any current issues between madvr and nvidia?
It was some time since I updated the drivers... :)

Skickat från min GT-N7000 via Tapatalk

[aufkrawall]

afaik, the only issue should be the flawed DX11 windowed fullscreen mode on Windows 10 (most likely driver bug since 352 series).
But there can be different results with different GPU families or Optimus etc.

[Finnish Flash]

afaik, the only issue should be the flawed DX11 windowed fullscreen mode on Windows 10 (most likely driver bug since 352 series).
But there can be different results with different GPU families or Optimus etc.I feel it got much better in the latest release, but then again it can be a placebo effect. At least DXVA deinterlacing performance is now what it's supposed to be in DX11 windowed mode. I'm running the latest WHQL drivers. Great work, madshi! Maximum rendering times seem to be through the roof in some cases (24 @ 60fps with smooth motion), but I don't see that affecting playback.

[kolak]

I see banding problems in Blu-Rays quite often, and not limited to Anime. My impression is that authoring studios using dithering is rather the exception than the rule. I often see banding problems in dark scenes, or it's especially noticable in fade-to-blacks. Fade-to-blacks in 8bit without dithering almost always looks ugly and non-smooth.

Sometimes I'm wondering why dithering is often not used by authoring studios. Either they're just dumb. Or maybe they don't want to spend the additional video bitrate needed to encode dithering without getting compression artifacts.


Thanks to the totally different HDR transfer function, I think banding will be less a problem with HDR than it is with current 8bit Blu-Rays, because the transfer function moves the majority of the 10bits to SDR pixels. Still, I'd have loved to get 12bits to get totally rid of any banding once and forever.

Unfortunately you are correct- many authoring studios don't use dithering at all have no clue what to do with it :)
Been in few big places and it was very disappointing.

I use to always do dithering with avisynth- Floyd+bit of noise and this really helps with banding, specially on fades (as you mentioned).

[fedpul]

Hi, I want to ask something offtopic, related with video cards, anyone with a GTX 970 can answer me. I have recently changed my video card from: Sapphire HD 7870 GHz Edition OC to MSI GTX 970 Gaming. Everything works fine, games doesn't exhibit artifacts nor slowdowns. But I saw something really strange in whit colour images, i see like a vibrance in the form of bars, so I decided to see the Chroma Test and for my surprise i see anoying vibrations everywhere and 4:2:2 can be seen. I test with other test like the colour bars one and nothing seem to be wrong. Maybe it is a defective DVI output, beacuse everything is OK when I use HDMI output to my TV. I am using the provided DVI to VGA adapter. I will aprecciate a lot any answer from GTX 970 owners. Thanks in advance, and sorry for the offtopic question, it is not my intention to deviate the topic.

[markanini]

Bug report: Once the interlaced flag is activated midstream MadVR sees it as interlaced for the remainder of the duration even if the stream switches back to reporting progressive.

[mcn]

Can you show a screenshot from one typical situation where subtitles are where you think they should be, and another situation where subs are *not* where they're supposed to be? Please use videos with SRT subtitles for those screenshots. Thanks!


I'm attaching some screenshots regarding the "issue" with subtitles positioning.
The first screenshot is of the original video, 1916x1076, without black bars.
The other two screenshots are taken with the video shown in full screen at 1920x1200, where black bars are added.

Embedded subtitles are partially shown in the bottom black bar, while external ones aren't.
Both should be definitely rendered by XySubFilter since modifying the timing through its properties window affects both subs.

[bozokaydin]

MadVR Option High End PC DXVA2 Alternative Configuration
chroma upscaling NNEDI3 128 Neurons
Image Doubling Always use NNEDI3 to Double Luma and Chroma Resolution using 128 neurons
Image Upscaling DXVA2
Image Downscaling DXVA2
smooth motion Enable Smooth Motion only if judder without
dithering Error Diffusion Option 1
Video Codec CUVID with hardware deinterlacing

I found this suggestion on a forum. In this senario, by using dxva for upscaling and downscaling does image doubling work for example for 720p content? ı am not sure it will work while using dxva.

[huhn]

bilinear is used in this case.

do your self a favour and don't sue DXVA scaling with image doubling and forget chroma doubling.

DXVa scaling should only be used if the GPU can't handle anything else.

[aufkrawall]

Sorry to say, but these settings are simply bizarre (wth invent people stuff like that?).

NNEDI3 128 neurons for chroma are a huge waste of performance, even 32 are quite luxury (with filmed content, NNEDI3 will hardly ever look noticeably better than Jinc AR for chroma).

Always using NNEDI3 for image doubling is also pure nonsense in 99% of cases. Linear scaling algorithms like Jinc introduce more artifacts the higher the scaling factor is. With <1.5x scaling, there usually hardly is an advantage of NNEDI3 over Jinc AR.
And 128 neurons are an insane count and most content doesn't profit much by the additional neurons, compared to 64.

DXVA scaling is simply bad quality wise. Don't do it if you aren't forced by badly slow hardware.
Use Jinc AR and Catmull-Rom AR for downscaling instead.

Don't use Error Diffusion if you can't see a difference for yourself. Instead, stick to normal ordered dithering of madVR.

Don't use CUVID, as it's a blackbox to developers (Nvidia doesn't grant nevcairiel or any other dev any control over it). Instead, use DXVA2 Copyback. It achieves the same quality and speed, but it doesn't have any drawbacks (instead of worse compatibility compared to software decoding, which almost never is an issue).

[iSeries]

Looking at either a R7 260x or an R7 360 to replace my R7 250. They're pretty much the same price. Is either one preferred over the other for MadVR?

[Warner306]

MadVR Option High End PC DXVA2 Alternative Configuration
chroma upscaling NNEDI3 128 Neurons
Image Doubling Always use NNEDI3 to Double Luma and Chroma Resolution using 128 neurons
Image Upscaling DXVA2
Image Downscaling DXVA2
smooth motion Enable Smooth Motion only if judder without
dithering Error Diffusion Option 1
Video Codec CUVID with hardware deinterlacing

I found this suggestion on a forum. In this senario, by using dxva for upscaling and downscaling does image doubling work for example for 720p content? ı am not sure it will work while using dxva.

You would be better off using these settings:

Chroma: super-xbr125 + AR
Image: Lanczos3 + AR
Double Luma: 1.5x or greater - NNEDI3 64 Neurons
Double Chroma: Off
Downscaling: Catmull-Rom + AR + LL
Upscaling Refinement: SuperRes (strength: 1, sharpness: 2)
Artifact Removal - Debanding: Medium/High
Image Enhancements: Off
Dithering: Ordered

Image doubling for 720p content can have an advantage when used with SuperRes. I find SuperRes makes fewer errors when used with sharp, artifact-free image scaling such as super-xbr or NNEDI3. The overall image appears sharper.

If you aren't using SuperRes, image doubling won't make much a difference at a 1.5x scaling factor.

[wanezhiling]

No, R7 series are all weak

[huhn]

Looking at either a R7 260x or an R7 360 to replace my R7 250. They're pretty much the same price. Is either one preferred over the other for MadVR?

the r7 360 is usually a bit faster thanks to the higher core clock of 50-100 mhz.

looks like they are both the same chip with a different name.

both have about double the speed of the r7 250

[XRyche]

No, R7 series are all weak

My MSI R7 265 is not bad either especially for it's price point. It's like having a R9 270. I know it is by no means top of the line but it does a decent job with madVR and NNEDI3 Image doubling.

[iSeries]

Seems I can get an R7 265 for the same price as ether an R7 260x or R7 360. It has more shaders, twice as many ROPs and greater memory bandwidth but a lower clock speed. What's more important for MadVR?

[aufkrawall]

In practice, the R7 265 is quite faster than the other mentioned graphics cards.
It's usually always better to go with the bigger GPU if they are more or less the same generation as the smaller ones.

[AngelGraves13]

You would be better off using these settings:

Chroma: super-xbr125 + AR
Image: Lanczos3 + AR
Double Luma: 1.5x or greater - NNEDI3 64 Neurons
Double Chroma: Off
Downscaling: Catmull-Rom + AR + LL
Upscaling Refinement: SuperRes (strength: 1, sharpness: 2)
Artifact Removal - Debanding: Medium/High
Image Enhancements: Off
Dithering: Ordered

Image doubling for 720p content can have an advantage when used with SuperRes. I find SuperRes makes fewer errors when used with sharp, artifact-free image scaling such as super-xbr or NNEDI3. The overall image appears sharper.

If you aren't using SuperRes, image doubling won't make much a difference at a 1.5x scaling factor.

I prefer Jinc AR for Chroma, and Image Upscaling. SuperXBR can be too sharp and I don't have enough time in my life to test out the optimal sharpness.

SupeRes is pointless as well, as it likely just sharpens the image and I literally can't tell what it does after a good hour of viewing with/without it.

[Luv]

My MSI R7 265 is not bad either especially for it's price point. It's like having a R9 270. I know it is by no means top of the line but it does a decent job with madVR and NNEDI3 Image doubling.

HD7790 (= + or - 260x),with Omega driver:
- D3D11
- chroma up:super-xbr (100)
- image down: Spline (4)
- image doubling: none
- image upscaling: Jinc
- dithering: ED 2
- No quality trade

The results are plain smashing (Even with interlaced samples).Big thanks,Madshi!
For me,89.12 is almost perfect (Almost because the codec in use isn't indicated in the OSD anymore and what does "Touch window from inside" mean?).

[aufkrawall]

I prefer Jinc AR for Chroma, and Image Upscaling. SuperXBR can be too sharp and I don't have enough time in my life to test out the optimal sharpness.

super-xbr has very big problems with ringing, you have to sacrifice a lot of sharpness to get to an acceptable ringing level if the source isn't optimal.


SupeRes is pointless as well, as it likely just sharpens the image and I literally can't tell what it does after a good hour of viewing with/without it.
madshi gave us some more SuperRes options with the latest builds, you could try a sharpness of 3 (and maybe 2 passes instead + linear light).
It should be very visible in most cases, but of course additional sharpness gets harder to notice with increasing viewing distance.

[huhn]

For me,89.12 is almost perfect (Almost because the codec in use isn't indicated in the OSD anymore
works fine with h264, vc-1 and mpeg2 like it always did.
and what does "Touch window from inside" mean?).

that's how scaling is done it kind of means scale the image but don't crop it.

[Warner306]

super-xbr has very big problems with ringing, you have to sacrifice a lot of sharpness to get to an acceptable ringing level if the source isn't optimal.


madshi gave us some more SuperRes options with the latest builds, you could try a sharpness of 3 (and maybe 2 passes instead + linear light).
It should be very visible in most cases, but of course additional sharpness gets harder to notice with increasing viewing distance.

super-xbr has about as much ringing as Jinc in the test images I've seen. According to the chart in madVR, it is one of the best algorithms with regards to ringing. It is not that bad at all. I use it all the time.

These comparison shots show super-xbr is superior:

Image Comparison – Clown:
Jinc (http://madvr.com/doom9/clown/clownJinc.png)
super-xbr100 (http://madvr.com/doom9/clown/clownSuperXBR.png)
NNEDI3 256 neurons (http://madvr.com/doom9/clown/clownNNEDI3_256.png)

Image Comparison – Lighthouse:
Jinc (http://madvr.com/doom9/lighthouse/lighthouseJinc.png)
super-xbr100 (http://madvr.com/doom9/lighthouse/lighthouseSuperXBR.png)
NNEDI3 256 neurons (http://madvr.com/doom9/lighthouse/lighthouseNNEDI3_256.png)

Image Comparison – Lighthouse Top:
Jinc (http://madvr.com/doom9/lighthouseTop/lighthouseTopJinc.png)
super-xbr100 (http://madvr.com/doom9/lighthouseTop/lighthouseTopSuperXBR.png)
NNEDI3 256 neurons (http://madvr.com/doom9/lighthouseTop/lighthouseTopNNEDI3_256.png)

[aufkrawall]

With the lighthouse top example, you can see that with a sharpness of 100, the ringing with super-xbr is clearly more distinct than with Jinc AR.
And the top needle (and dark line structures in general) gets very fat, which is another disadvantage.

[Luv]

works fine with h264, vc-1 and mpeg2 like it always did.


that's how scaling is done it kind of means scale the image but don't crop it.

Thanks for the explanations,Huhn.I just rebooted and everything is back to normal.

[Warner306]

With the lighthouse top example, you can see that with a sharpness of 100, the ringing with super-xbr is clearly more distinct than with Jinc AR.
And the top needle (and dark line structures in general) gets very fat, which is another disadvantage.

Sure the ringing is more distinct, but not larger. This is due to the detail brought-out by super-xbr, which gives it an overall advantage. With real world content, super-xbr is not nearly as distracting as Bicubic100 or Lanczos4, with regards to ringing. It is actually pretty good at avoiding excessive ringing.

I have heard a couple of people say super-xbr rings too much. But I don't think this is true.

[aufkrawall]

Sure the ringing is more distinct, but not larger. This is due to the detail brought-out by super-xbr, which gives it an overall advantage.

I'm afraid it's not just details what super-xbr brings out.
More intensive haloing and very fat lines are not to be found in the source.

If you watch cartoons with ringing right along black contoure lines, it is very annoying (and lines also get too fat).
It gets even uglier if you put SuperRes on top and super-xbr 100 tends also more to aliasing than NNEDI3 64.

With bacondither's new Adaptive Sharpen experimental build (not yet included in madVR), you can get more sharpness with NNEDI3 as well, without ugly haloing. The same goes for NNEDI3 + SuperRes.

Of course Jinc isn't magic, yes. It's a limited linear scaler. But with super-xbr, you get a very soft image if you don't want ringing or dark lines boosted.
Probably less of an issue for many BDs, but there's always a first time when some artifacts become annoying.

[Warner306]

I'm afraid it's not just details what super-xbr brings out.
More intensive haloing and very fat lines are not to be found in the source.

If you watch cartoons with ringing right along black contoure lines, it is very annoying (and lines also get too fat).
It gets even uglier if you put SuperRes on top and super-xbr 100 tends also more to aliasing than NNEDI3 64.

With bacondither's new Adaptive Sharpen experimental build (not yet included in madVR), you can get more sharpness with NNEDI3 as well, without ugly haloing. The same goes for NNEDI3 + SuperRes.

Of course Jinc isn't magic, yes. It's a limited linear scaler. But with super-xbr, you get a very soft image if you don't want ringing or dark lines boosted.
Probably less of an issue for many BDs, but there's always a first time when some artifacts become annoying.

I've read madshi prefers super-xbr to Jinc. And past posts have found NNEDI3 and super-xbr are the best algorithms to use with SuperRes because they are sharper. SuperRes + Jinc leads to an image that appears bloated compared to SuperRes + super-xbr.

It is all subjective. The haloing is not noticeable with real-world content, to me, and the extra detail is very apparent.

I'm just standing up for super-xbr as a great algorithm as has been said about Jinc and NNEDI3. Other's mileage will vary.

This a quote from madshi:

I've decided to make a big screenshot Based on that, here's another comparison, comparing different upscaling algorithms, followed by SuperRes:

Bilinear+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleBilinearHqSuperRes.png) -|- Jinc+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleJincHqSuperRes.png) -|- super-xbr+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleSuperXbrHqSuperRes.png) -|- NNEDI3+SuperRes (http://madVR.com/doom9/castle/ScalingAlgosHqSuperRes/CastleNNEDI3HqSuperRes.png) -|- GroundTruth (http://madVR.com/doom9/castle/CastleBig.png)

What we can see here is that SuperRes works well even when using Bilinear upscaling. However, SuperRes does *not* remove aliasing artifacts caused by the upscaling algorithm. E.g. look at the roof edges of the left two towers. Both Bilinear and Jinc have aliasing problems there. super-xbr and NNEDI3 have not. Because of this reason, my recommendation would be to use either super-xbr or NNEDI3, followed by SuperRes, for best image quality. The difference between super-xbr and NNEDI3 is pretty small, if you follow it up with SuperRes with high strength. So using super-xbr should save some precious GPU performance. Using Jinc+SuperRes might be an option, too, but you'll likely get more aliasing problems compared to super-xbr+SuperRes.

[aufkrawall]

Well, as I said, super-xbr may look mostly fine with most BD content, so it's absolutely legitimate to like it. ;)

I'm aware that super-xbr reconstructs lines much better than Jinc with increasing scaling factor.
However, sharpness values over 75 can introduce a lot of artifacts. This doesn't have to be an issue for a specific picture, but there are definitely cases where it can look far from good.

For instance, you can hardly use SuperRes in linear light with super-xbr 100, as lines will get extremely fat. And you may not use gamma light either, since super-xbr 100 already noticeably highers many areas of the picture.
In fact, I even find super-xbr 100 alone with your Lighthouse example unconvenient to the eyes. It looks like a very artificial contrast to me. The line boosting of SuperRes LL is almost harmless, compared to super-xbr 100.

In the end, it's a matter of taste. However, I think it's a fact that super-xbr can't be combined well with most postprocessing, unlike NNEDI3.