madVR - high quality video renderer (GPU assisted)

[gaseosx]

Is madvr really mostly run through the gpu now? With dxva? This sounds too good to be true. Last time I checked this was more than 6 months ago.

[huhn]

copyback allways works or not?

[jkauff]

copyback allways works or not?
Related question. Does madVR prefer native or copyback, or doesn't it care?

[konakona]

Is madvr really mostly run through the gpu now? With dxva? This sounds too good to be true. Last time I checked this was more than 6 months ago.

madvr uses dxva aka internal video processor only when you tell it to do so,otherwise everything is done as custom pixel shader code i think. (so all gpu)

[huhn]

Related question. Does madVR prefer native or copyback, or doesn't it care?

madish said "don't use dxva or use dxva native" but that was about amd native should be fast but xy vobsub does not work.

>i< don't see a difference in native or cp

[Niyawa]

copyback allways works or not?
You need a SSE 4.1 compatible CPU and Windows 7 SP1 or ahead to be able to use it.

Related question. Does madVR prefer native or copyback, or doesn't it care?
I would say copyback is the ideal if your hardware is up to it. Apparently it removed a lot of limitations from the renderer's work since it works in "stealth" - for the lack of term. Turn on OSD in madVR and you'll see how it doesn't show up when it's being used. I can't really explain properly but nev did tell me the advantages of using it in a reply in the LAV Filters thread, you could always search.

[NicolasRobidoux]

...
I tried taking some photographs to illustrate the differences between various scaling algorithms when displayed at 4:2:2 and 4:4:4, but unfortunately they don't show it as clearly as I had hoped. What I did find though, was that with my TV operating at 4:2:2 - at least with the sample that I tried - there is zero difference between Jinc 3 AR and Lanczos 3 AR Chroma. They're not just "very close" or "similar" - I can layer the images on top of each other in Photoshop and use the "difference" layer blending tool, and nothing shows up.
...This is really interesting. Thank you.
It actually suggests to me that I may have given the right advice to Mathias when I suggested that, with his anti-ring filter, he use the plain vanilla EWA LanczosSharp deblur as opposed to the very very slightly milder one I now recommend.
This is weak evidence. But evidence nonetheless.
Again, thank you for this.

[Qaq]

I gave up on "copy back". Sometimes playback is not smooth with CB even if OSD stats are good (my card is 7750). Go figure. So I use DXVA n for 1080p/i video and SW for 720p, 1080 HDTV IVTC.

[madshi]

I have multiple computers with diverse specifications which I all use to watch media. They all have madVR on board. In order to get the most out of each, I've tuned their settings (mainly the upscaling algorithms) to appropriate levels for each computer, which guarantees a comfortable viewing experience for every kind of content—except it doesn't. Most video files have the same processing footprint on the renderer, regardless of their resolution, bitrate, or other properties. There is, however, one property that guarantees to substantially increase the load and that is frame rate. I can throw any 0-30fps file at any of my computers and it'll play without stuttering, but even the most gently encoded 60fps video is bound to have stuttering every few seconds. The obvious choice is to ease up the settings for high fps files but doing this every time is an incredible drag and using lower settings permanently is frankly a compromise of quality for 95% of the content I play, which is something that doesn't seem to stroke with madVR's aims.

I, and possibly/probably others, would like a solution that isn't necessarily simple to set up, but is effortless in use. Personally I would recommend dividing each scaling algorithm page (chroma up, image up, image down) into two or more tabs indicating the frame rate range at which they're to be used. This way I could for example use Jinc-3 at 0-30fps and SoftCubic-50 at 31-60fps, which would ameliorate this minor inconvenience with sacrificing a minimum of quality.
is already on the "to do" list.
^^

Could you clarify this? Which upload method(s) from madNV12Test are still in use, and/or most relevant to current versions of madVR?
When using DXVA deinterlacing and/or scaling, madVR uploads to DXVA NV12 surfaces. Otherwise madVR uploads to dynamic A8R8G8B8 textures (for 8bit content). Or to dynamic 16bit RGB textures (for 16bit content). So those are the 2 upload measurements that are most important.

what was the motivation for including decoding into already complex project?
When I implemented the madVR video decoders there was no other decoder available with 10bit or 4:2:2 / 4:4:4 decoding support. LAV Video Decoder development only really started after I released the first madVR version with integrated decoders, IIRC. In their current state the internal decoders in madVR might be somewhat superfluous, but then: Why removing something that works?

I'm somewhat sick of people questioning the existence/purpose of the madVR decoders. If you don't like them, don't use them. It's really as simple as that.

Is madvr really mostly run through the gpu now? With dxva? This sounds too good to be true. Last time I checked this was more than 6 months ago.
madVR has always run through the GPU, only (except for the IVTC algorithm). However, for a long time DXVA decoding was not supported, so people had to use software decoding (or "copyback" via LAV Video Decoder). Recently I added support for DXVA decoding to madVR. So basically there are almost no limitations left in madVR compared to VMR/EVR now.

Related question. Does madVR prefer native or copyback, or doesn't it care?
madVR itself doesn't really care. But what makes sense for you depends on the GPU you're using. E.g. older generation AMD cards are pretty bad at copyback, so you should better use software decoding or native DXVA with them. The situation is very different with NVidia GPUs. There copyback works very well and is a good alternative to software or native DXVA decoding.

This is really interesting. Thank you.
It actually suggests to me that I may have given the right advice to Mathias when I suggested that, with his anti-ring filter, he use the plain vanilla EWA LanczosSharp deblur as opposed to the very very slightly milder one I now recommend.
This is weak evidence. But evidence nonetheless.
FWIW, those of 6233638's comments you're refering to only apply to TVs which internally downconvert RGB input to YCbCr 4:2:2. The situation is different for TVs which don't use such shortcuts. It's clear that when TVs downconvert RGB to 4:2:2 YCbCr internally, some of the advantages of high-quality chroma upsampling get lost.

[dansrfe]

How do I know if my output device (TV or monitor) downconverts the RGB signal from the graphics card to 4:2:2 YCbCr internally or if it displays RGB untouched?

[Asmodian]

I use this image, there should be no gray squares:
http://i1222.photobucket.com/albums/dd496/asmodian3/multicolor2.png

[secvensor]

Whether there will be a support:
http://www.h265.net/

[QQ]

I'm somewhat sick of people questioning the existence/purpose of the madVR decoders. If you don't like them, don't use them. It's really as simple as that.

I'm really sorry if I made it sound like that!

I was mainly interested if there are any differences/advantages in using madVR ones instead of other available ones. And now I've got the answer!

[madshi]

Whether there will be a support:
http://www.h265.net/
When libav/ffmpeg add support for h265 decoding, then so will LAV Video Decoder and madVR. Currently libav/ffmpeg don't support h265 yet.

I'm really sorry if I made it sound like that!
No worries. Probably I misinterpreted your comment.

[secvensor]

madshi
You wrote, that I have reminded of one thing when madvr will reach version 1.00
But when it will be, nobody knows.
Therefore I remind now:
"Originally Posted by secvensor
For displaying the frame number.
To be able to pinpoint the frame exactly even in the player mode, without going to the editor.
To be sure which frame you're on.
0:06:04/0:06:04
>>>
8734 (0:06:04.281) [ ]/Frame 8743 (0:06:04.656) [K]

I see. Could you please keep this wish in mind and repost it when madVR has reached v1.0?"

[dansrfe]

I use this image, there should be no gray squares:
http://i1222.photobucket.com/albums/dd496/asmodian3/multicolor2.png

Thanks Asmodian! No grey squares on any of my displays! :)

[DragonQ]

I use this image, there should be no gray squares:
http://i1222.photobucket.com/albums/dd496/asmodian3/multicolor2.png
At that resolution?

[Skankee]

How do I know if my output device (TV or monitor) downconverts the RGB signal from the graphics card to 4:2:2 YCbCr internally or if it displays RGB untouched?

you can use this image:

http://s14.directupload.net/images/130123/ka7w3bap.png

It´s easy to use, all lines are exact 1 pixel wide (You have to look at it verry close).
If not, the display can not show 4:4:4.

4:4:4
horizontal+vertical lines are 1 pixel wide

4:2:2
horizontal 1 pixel , vertical ~3 pixel wide (colors looks washed-out)

4:2:0
horizontal+vertical lines are ~3 pixel wide (colors looks washed-out)

My TV (from 2009) is per default 4:2:0, regardless im choosing YCbCr 4:2:2, YCbCr 4:4:4, or RGB 4:4:4 in my catalyst control center.
(when i use "custom resolution utility" and exclude extension block, it is 4:2:2)

I also noticed something strange.I store this image as: bmp, jpg(100quality, no subsampling) and png.

When i put this png-image into MPC HC (+madVR+LAV) on my RGB 4:4:4 -monitor, it is shown as an "4:2:2 like" image with 2 pixel wide vertical lines ( not washed-out).
The same with jpg-Images. But bmp-images are shown correctly 1 pixel wide.
It looks like there is some down-conversion with jpg and png, or do this only apply to me ?

( GPU: Radeon 4870, Win 7 pro 32bit, MPC HC 1.6.6.6391, madVR v0.85.8, LAV 0.55.1 PC-monitor: LG Flatron IPS 225 TV: LG 37 LH3000)

[vivan]

I also noticed something strange.I store this image as: bmp, jpg(100quality, no subsampling) and png.

When i put this png-image into MPC HC (+madVR+LAV) on my RGB 4:4:4 -monitor, it is shown as an "4:2:2 like" image with 2 pixel wide vertical lines ( not washed-out).
The same with jpg-Images. But bmp-images are shown correctly 1 pixel wide.
It looks like there is some down-conversion with jpg and png, or do this only apply to me ?Looks like madVR bug... With Alt+I image saves as it should. Also with NN image upscaling it's also works as it should...

[truexfan81]

gtx650 with gddr5 can't handle jinc at 59.94 fps?
very disappointed, thats what i bought the thing to do

[dansrfe]

gtx650 with gddr5 can't handle jinc at 59.94 fps?
very disappointed, thats what i bought the thing to do

I don't think anything less than a GTX 690 would be able to handle 1080p 59.94 fps with Jinc.

[nevcairiel]

Jinc3 works fine on my GTX660 even with 60p content, scaling for example 1440x1080i60 to 1920x1080p60. And my GTX680 can scale 1080p material to 2560x1600 with Jinc3... :p (didn't test the last one on the 660, because the TV it runs is only 1080p)

[truexfan81]

I don't think anything less than a GTX 690 would be able to handle 1080p 59.94 fps with Jinc.

i don't have any 1080p 60 vids
i tested with 720p60 failed
also with 400p60 was just as bad :/

[QBhd]

It´s easy to use, all lines are exact 1 pixel wide (You have to look at it verry close).
If not, the display can not show 4:4:4.

4:4:4
horizontal+vertical lines are 1 pixel wide

4:2:2
horizontal 1 pixel , vertical ~3 pixel wide (colors looks washed-out)

4:2:0
horizontal+vertical lines are ~3 pixel wide (colors looks washed-out)



So my question now is... if the TV is downconverting the 4:4:4 RGB... should I still be using 4:4:4 RGB in my Catalyst settings? I am thinking yes, since we want to send the device as much info as possible, but it's always good to hear from the experts first before jumping to conclusions. :)

QB

[madshi]

madshi
You wrote, that I have reminded of one thing when madvr will reach version 1.00
Yes, I did.

When i put this png-image into MPC HC (+madVR+LAV) on my RGB 4:4:4 -monitor, it is shown as an "4:2:2 like" image with 2 pixel wide vertical lines ( not washed-out).
The same with jpg-Images. But bmp-images are shown correctly 1 pixel wide.
It looks like there is some down-conversion with jpg and png, or do this only apply to me ?

( GPU: Radeon 4870, Win 7 pro 32bit, MPC HC 1.6.6.6391, madVR v0.85.8, LAV 0.55.1 PC-monitor: LG Flatron IPS 225 TV: LG 37 LH3000)
Looks like madVR bug... With Alt+I image saves as it should. Also with NN image upscaling it's also works as it should...
The Alt+I output is wrong on my PC, too. The cause of the problem is that the image is 395 pixels wide. madVR cuts that down to 394 pixels (but still displays it as 395 pixels, so scaling is activated) because YCbCr 4:2:0 formats don't work well with odd widths. I guess I should allow that for RGB sources, though.

It's generally a bad idea to create test images with odd widths/heights.

gtx650 with gddr5 can't handle jinc at 59.94 fps?
very disappointed, thats what i bought the thing to do
i don't have any 1080p 60 vids
i tested with 720p60 failed
also with 400p60 was just as bad :/
Which GPU is needed to handle Jinc3 AR upscaling to 1080p60 was discussed in this thread multiple times and the general consensus was that a 660 is needed for that. Jinc is *really* demanding on the GPU. Well, maybe a 650 Ti would also do the job, I'm not sure if anybody tested that yet. But a 650 is definitely too slow. It should be able to handle 24p stuff, but not 60p. After all 60p requires 2.5x the power of 24p.

So my question now is... if the TV is downconverting the 4:4:4 RGB... should I still be using 4:4:4 RGB in my Catalyst settings?
Yes.

[NicolasRobidoux]

...
FWIW, those of 6233638's comments you're refering to only apply to TVs which internally downconvert RGB input to YCbCr 4:2:2. The situation is different for TVs which don't use such shortcuts. It's clear that when TVs downconvert RGB to 4:2:2 YCbCr internally, some of the advantages of high-quality chroma upsampling get lost.Yes indeed. The reason I found this interesting is that it suggests that (with AR and at low bit depth and ...) that the low pass component of Jinc 3 is really close to Lanczos 3, and that it's only w.r.t. high frequencies that they differ. See, e.g., http://www.wizards-toolkit.org/discourse-server/viewtopic.php?f=22&t=19636&sid=255ea511f1a32d84da56de45abd5ab3c&start=225#p95281.

[dansrfe]

All queues should be as small as possible till it starts dropping/delaying frames right? Just got my 3770k and GTX 670 and I can max out all the queues but obviously that's not needed so I'm trying minimize it as much as possible but I'm not sure if that's the right approach either.

[madshi]

Yes indeed. The reason I found this interesting is that it suggests that (with AR and at low bit depth and ...) that the low pass component of Jinc 3 is really close to Lanczos 3, and that it's only w.r.t. high frequencies that they differ. See, e.g., http://www.wizards-toolkit.org/discourse-server/viewtopic.php?f=22&t=19636&sid=255ea511f1a32d84da56de45abd5ab3c&start=225#p95281.
That may be true. But to be honest, I prefer to optimize the madVR algorithms for displays which do things correctly. If I modify the algorithms to work better for bad displays then that might harm image quality with good displays. E.g. if I use less blur (= sharper image) with Jinc then comes at the cost of increased aliasing which takes away from the organic look of Jinc, IMHO.

All queues should be as small as possible till it starts dropping/delaying frames right? Just got my 3770k and GTX 670 and I can max out all the queues but obviously that's not needed so I'm trying minimize it as much as possible but I'm not sure if that's the right approach either.
If you have no problems then I would not go lower than the default queue sizes. Well, the advantage of going lower is maybe improved windowed <-> fullscreen exclusive mode switching times. And faster startup if you use the "delay playback start until render queue is full". And you'll save some CPU and GPU RAM. But I don't consider any of that very important for video playback. Higher queues mean more margin for errors. But the things mentioned above will get a bit slower.

[Nekomata]

new version? when
thx

[huhn]

new version? when
thx

is there a major problem with the current one?

[NicolasRobidoux]

E.g. if I use less blur (= sharper image) with Jinc then comes at the cost of increased aliasing which takes away from the organic look of Jinc, IMHO.I was not suggesting you change anything: Although a small voice in me says that a blur around .95-.96 may be better, it does seem like .97-.99 is the sweet spot for "naturalness", and that the value I suggested you use (the "plain vanilla LanczosSharp (de)blur) is a good match with AR. The fact that I don't state this in http://www.imagemagick.org/Usage/filter/nicolas/ gives you an idea of how small the voice is. (BTW, the recommended sigmoidal contrast values will go down in the next iteration of this document, to something stritcly between 6 and 7.5 for EWA LanczosSharp. But this does not concern you.)

[madshi]

new version? when
thx
When it's ready! ;)

-------

Ok, normally I don't reply to such questions. But since the one and only major new feature of v0.86 is already half working, I'll make an exception this once: The next build might already come a day from now. But if I run into trouble, it could also take a week. I just don't know for sure yet.

I was not suggesting you change anything: Although a small voice in me says that a blur around .95-.96 may be better, it does seem like .97-.99 is the sweet spot for "naturalness", and that the value I suggested you use (the "plain vanilla LanczosSharp (de)blur) is a good match with AR. The fact that I don't state this in http://www.imagemagick.org/Usage/filter/nicolas/ gives you an idea of how small the voice is. (BTW, the recommended sigmoidal contrast values will go down in the next iteration of this document, to something stritcly between 6 and 7.5 for EWA LanczosSharp. But this does not concern you.)
Ah I see, thanks. I'll stay with the current value for max "naturalness"... :)

[Dodgexander]

you can use this image:

http://s14.directupload.net/images/130123/ka7w3bap.png

It´s easy to use, all lines are exact 1 pixel wide (You have to look at it verry close).
If not, the display can not show 4:4:4.

4:4:4
horizontal+vertical lines are 1 pixel wide

4:2:2
horizontal 1 pixel , vertical ~3 pixel wide (colors looks washed-out)

4:2:0
horizontal+vertical lines are ~3 pixel wide (colors looks washed-out)

My TV (from 2009) is per default 4:2:0, regardless im choosing YCbCr 4:2:2, YCbCr 4:4:4, or RGB 4:4:4 in my catalyst control center.
(when i use "custom resolution utility" and exclude extension block, it is 4:2:2)

I also noticed something strange.I store this image as: bmp, jpg(100quality, no subsampling) and png.

When i put this png-image into MPC HC (+madVR+LAV) on my RGB 4:4:4 -monitor, it is shown as an "4:2:2 like" image with 2 pixel wide vertical lines ( not washed-out).
The same with jpg-Images. But bmp-images are shown correctly 1 pixel wide.
It looks like there is some down-conversion with jpg and png, or do this only apply to me ?

( GPU: Radeon 4870, Win 7 pro 32bit, MPC HC 1.6.6.6391, madVR v0.85.8, LAV 0.55.1 PC-monitor: LG Flatron IPS 225 TV: LG 37 LH3000)

So because this image is .png we cannot use this to test?

What image can we use to test?

Edit, seems best way is to use the images listed here (http://www.avsforum.com/t/1381724/official-4-4-4-chroma-subsampling-thread#post_21386797)

Does anyone know about testing if your display supports YCbCr rather than RGB without conversion?

[6233638]

So because this image is .png we cannot use this to test?

What image can we use to test?It's because of the image's dimensions. This image (http://www.abload.de/img/fixedh5u4w.png) should work. (just added a black border to make it 400x400)

This is really interesting. Thank you.No problem, I'm glad that you found it interesting. I should point out that even when displaying 4:2:2, many displays address their subpixels differently, so up-close images like that may look different depending on the panel type. And I'm sure that other displays probably downsample to 4:2:2 differently as well.

[turbojet]

Failed to connect to D3D device on an extended monitor, tried mpc-be and mpc-hc. EVR works fine, logs at http://www.sendspace.com/file/ke5wq8

Option to disable vsync was mentioned earlier, is this possible? Would it lower cpu/gpu usage when it's disabled as much as it does with EVR? When aero is enabled vsync doesn't help in evr, actually it drops some frames when it's enabled.

[madshi]

I think if you "disable VSync" in EVR that probably just means that EVR *itself* doesn't care about VSync, anymore, but leaves that stuff to Aero. But that's a really bad solution because it can introduce heavy motion judder in certain situations. Because of that I consider it a poor choice and there won't ever be a option like that in madVR.

For your D3D extended problem, if you think this is a bug in madVR, please create a bug entry in the madVR bug tracker. And please include details such as: Does the problem occur in fullscreen or windowed mode or in both? Does the problem only occur if you start playback on the primary monitor and then move the media player to the extended monitor? Or does it also occur if you move the media player to the secondary monitor before loading the video? Or does it occur with software or DXVA decoding or both? Or does it occur only with some decoders or with all? Details like this are very important.

[chuuey]

Interesting, i checked the images you guys posted, and it seems this monitor displays 4:4:4, however Madvr reports 4:2:0 to 4:2:0 conversion in the stats. Why this inconsistency?

[madshi]

What madVR reports in the OSD is what the *decoder* is doing. madVR always produces dithered 8bit RGB 4:4:4 output.

[iSunrise]

When it's ready! ;)

-------

Ok, normally I don't reply to such questions. But since the one and only major new feature of v0.86 is already half working, I'll make an exception this once: The next build might already come a day from now. But if I run into trouble, it could also take a week. I just don't know for sure yet.
I´m curious, is it going to work for 23.976fps and 24fps sources only or all sources that are not an exact multiple of the 60Hz (59.940Hz) composition rate? (e.x. 25fps, 50fps and 30fps). I am so anxious to try it out with all my samples.

EDIT: Hm, I think I found the answer, so only for 24fps? That´s a pity. Wouldn´t that mean that we absolutely need Reclock in this case to speed up 23.976fps to 24fps before madVR can fill in the gaps with the right frames?

[madshi]

You might be pleasently surprised.

[chuuey]

What madVR reports in the OSD is what the *decoder* is doing. madVR always produces dithered 8bit RGB 4:4:4 output.

Right, thanks :)

[digitech]

You might be pleasently surprised.

:D* J i g g l e s*:D

[Skankee]

So because this image is .png we cannot use this to test?

What image can we use to test?

The problem with png and jpg i mentioned in the last part of my post is about viewing this image in MPC HC+madVR.
That has no influence on the test itself when you look at the test image in your browser/in any other image viewer at 100% size (as it was intended).

Maybe that was a little bit confusing.

[secvensor]

http://i51.fastpic.ru/big/2013/0216/71/e8df32999ba8c2ac7a38bd5bc2e1f671.png

[aufkrawall]

According to him, it's on madshi's to-do list but other feature have more priority.

[turbojet]

The D3D error was a windows update driver issue. Clean install of the latest nvidia drivers fixed it.

I trust your judgment on motion judder, I may just not notice it. The only reason for such an option would be maybe to allow IGP/budget gpu's to use a wider variety of resizers.

[psishock]

Once i drag the render window to the second monitor, madvr freezes on the last frame (the audio continues to play in the background). If i drag back the MPC to the primary monitor, the video continues to play. If i leave madvr on the second screen frozen for a while, MPC crashes down.

I'm on Win8 64bit (using 32bit player).

Any ideas why is this bug happening or how could i prevent it? It doesnt shows up on other renderers, they are working fine, only madvr is glitching in this case. I've tried several different madvr versions, i am on latest 0.85.8 now. Tried also a number of different MPC versions, its definitely a madvr bug, not a player issue.

[huhn]

Once i drag the render window to the second monitor, madvr freezes on the last frame (the audio continues to play in the background). If i drag back the MPC to the primary monitor, the video continues to play. If i leave madvr on the second screen frozen for a while, MPC crashes down.

I'm on Win8 64bit (using 32bit player).

Any ideas why is this bug happening or how could i prevent it? It doesnt shows up on other renderers, they are working fine, only madvr is glitching in this case. I've tried several different madvr versions, i am on latest 0.85.8 now. Tried also a number of different MPC versions, its definitely a madvr bug, not a player issue.

use the bug tracker: http://bugs.madshi.net/my_view_page.php

you are using dxva right? are the monitors at different grafikcards like first monitor is connect to the onboard and second one is connected with different one or something like that?

[psishock]

use the bug tracker: http://bugs.madshi.net/my_view_page.php

you are using dxva right? are the monitors at different grafikcards like first monitor is connect to the onboard and second one is connected with different one or something like that?

No, dxva(2) scaling is turned off (turning it on doesnt make any difference on the problem). Both of the monitors are hooked on the same card, nvidia670. The only difference that one is aligned vertically, while i kept the other one horizontally, so there is a resolution difference between two... i dont really think that should cause any trouble.

I dont have an onchip video card on my intel 3930k.

Anyway, i will file a bug on the tracker site for this issue, hope madshi can work this one out.

[nevcairiel]

Rotated screens are not supported by madVR at this time.
Its on madshis list to support it, but not a high priority, iirc.