madVR - high quality video renderer (GPU assisted)

[Klaus_1250]

Win XP SP3, MPC-HC b1070, P4 3.2HT, 2GB, HD3850AGP, Reclock 1.8.4.2, PowerStrip 3.8x:

Display estimate 1 is always too high (about 2.5 Hz), Display estimate 2 seems ok though it jumps a bit up and down, Display estimate 3 is roughly the same as 2, but more stable. Unfortunately it occassionally displays weird values (0.00000Hz) when maximizing/minimizing MPC-HC.

On a side note, Reclock 1.8.4.2 doesn't work with MadVR. It is unable to detect the proper refresh rate after Powerstrip changes it and the System Clock correction no longer works.

PS: When going to Filters --> Madshi Video Renderer in MPC-HC, I cannot see any text after the check-boxes (only see black bars). Might be because I use WindowBlinds.

PS2: After Playback, MPC-HC seems to go haywired, using 50% CPU. Trying to quit MPC-HC result in the same and needs an "End Task" through the task manager.

[Egh]

I disagree with KoD as we have numbers as well, so measuring is not subjective. It is hard to measure of course, as we don't have a log of CPU or GPU usage so we cannot directly compare. But the difference is substantial enough here to be taken note of.

Tested with a different 720p AVC file and still figures are pretty much same. Even average time is higher for version40 here, by a factor of roughly 1.5. That makes is almost as long as max time for v31 for instance


I tried to dig deeper and found out that for average time (which is 10 for v3x/v41 and 16 for v40) is divided more or less equally between resampling time and rendering time. So it is about 5ms each for 3x and 8ms each for 40.
As for maximum time it is divided by 2/3 to resampling and 1/3 to render. And this ratio is pretty much same both for v3x and v40.

So, I wonder, why max(resamping)=2*avg(resampling) ? Thing is that original and target sizes for the texture should be always same...
Also, render time greatly depends on the target resolution, if I make a window very small (just to fit half of the OSD there) mVR can achieve less than 1ms render times. BUT! Then resample time takes about 10ms and thus average time is still about same

[Brazil2]

Originally Posted by nijiko

What's the diff between bicubic and softcubic?
And between such as 50, 60, 70...?

I'm sorry but I've read again this whole thread and I couldn't find such detailed info.
Please could you point me to the post containing this information ?

[cyberbeing]

Shader 41, 39, 36, 34, 31, and 24 Avg 4-5ms, Max 8-12ms
Shader 40, Avg 7-8ms, Max 10-13ms (the oddball, worse then the others)

CPU usage is virtually identical between all versions. Personally, I would just choose Shader 41, since it is the newest. Shader 40 is completely a no-go.

[madshi]

Originally Posted by KoD

madshi, average GPU rendering time is irrelevant.

Are you trying to tell me that you know better than I do?

Originally Posted by KoD

On my test files, it stays in the range 30-35ms, but when you look at the picture and see the stutter fest, it's obvious the max GPU rendering time is the indicator for how smooth the video is, not the average GPU rendering time.

It is true that with madVR 0.8, if max rendering time is too big, there will be stutter. I wonder how many times I have to repeat that madVR is not yet optimized for smooth playback? A "final" madVR version will probably be able to even out max/min rendering times more or less. Yes, max rendering times have a meaning, too, that's why I'm listing them in the OSD. But the more important number is the average number, as I've already stated several times in this thread. It may not show with madVR 0.8 that the average rendering times are more important than the max rendering times, but that's just because madVR 0.8 is not optimized for smooth playback yet.

Originally Posted by KoD

Also, what we're doing here, reporting numbers we see on the screen, is a waste of time. If you really want accurate results, implement a logger and then you'll have them.

Or not. The reason why I asked for feedback about how shader versions compare is that several people complained about noticeably higher GPU load numbers with madVR 0.6 compared to v0.4. Based on these reports I thought that at least those people complaining should be able to give me clear results. With my graphics card all the shader compiler versions behave rather similar. But that doesn't seem to be the case for everyone. So it's still useful to find out which shader compiler version produces the best results for the majority of people...

Originally Posted by KoD

When comparing to other renderers, Microsoft's renderers (including VMR9) can be used on files where Haali or madVR can't. This is easily seen in those resampling from 1920x1080 resolution cases. Both Haali and madVR don't manage that in my case.

Looking at it in terms of quality madVR is a very good choice when you manage to have low max gpu rendering times. One can try to achieve that by using Lanczos3, or one of the SoftCubic/Bicubic resampling filters. I saw madshi saying bilinear is what the graphic card uses - I have to disagree here, choosing bilinear in madVR gives a worse result than what one gets using VMR9, so if you have to go that low to achieve smooth playback with madVR, give up on it and use VMR9 or some other Microsoft renderer - quality will be better.

The smoothest playback with lowest CPU/GPU load for H264 video is achievable only by using MPC-HC with VMR9 renderless as renderer (for the internal subtitler filter to work when using DXVA for h264 files) + using DXVA when available for H264.

Some comments:

(1) All current performance comparisons between madVR and other renderers are still preliminary, because madVR is still in early beta.

(2) When using e.g. MPC HC with VMR9, you do not get bilinear scaling, but MPC HC does bicubic scaling via shaders. That's why you get better results with VMR9 compared to madVR bilinear scaling. Still you can't say that madVR loses all advantages if you activate bilinear scaling. For one: If you have 1:1 display (which is the best option for image quality, anyway!) you don't have to scale (luma) at all. Furthermore there is much more to madVR than just scaling quality.

(3) Obviously some CPU/GPU combinations will not be able to handle high bitrate h264 movies without hardware accelerated decoding. But that doesn't mean that VMR9 is the only option. E.g. EVR is also an option. Or you could use madVR with CUDA accelerated decoding (only with NVidia GPU).

Originally Posted by Grmpf

But i got another question, if i use the Custom AR Tab in Zoomplayer and choose a selfmade preset to adjust the AR (i need to use 1.33:1 for my ISCO for 2.35:1 content and 1.78:1 for content i watch without the ISCO) madVR does the scaling right (using 1080p as input and output, just the AR changes) ? If i do this your status infos are mostly gone ( can only read the last line) because now they are of the screen you renderer - i guess you write the status info first and then adjust the AR ?

Theoretically madVR tries to place the OSD info in the top left corner of the visible screen, no matter how much you zoom. There may be a bug somewhere or maybe Zoom Player is doing some funny stuff. Don't know. Can you give me a step by step explanation on how to reproduce this problem?

Originally Posted by Klaus_1250

PS: When going to Filters --> Madshi Video Renderer in MPC-HC, I cannot see any text after the check-boxes (only see black bars). Might be because I use WindowBlinds.

Argh... This stupid settings dialog causes me more trouble than I'd like. Being used to how nice Delphi is, I'm cursing at MSVC++'s form designer all the time. Sooner or later I'll redesign the whole settings dialog to solve all these problems, but that will not happen too soon.

Originally Posted by Klaus_1250

After Playback, MPC-HC seems to go haywired, using 50% CPU. Trying to quit MPC-HC result in the same and needs an "End Task" through the task manager.

Doesn't seem to happen for me!

Originally Posted by Egh

Also, render time greatly depends on the target resolution, if I make a window very small (just to fit half of the OSD there) mVR can achieve less than 1ms render times. BUT! Then resample time takes about 10ms and thus average time is still about same

When doing extreme downscaling, all the rescaling work is no longer done in the final rendering step, but it's done before in the "texture resampling" step. That is by design.

Originally Posted by Brazil2

I'm sorry but I've read again this whole thread and I couldn't find such detailed info.
Please could you point me to the post containing this information ?

Search this thread for "Mitchell". The first hit is what you're looking for.

[madshi]

Originally Posted by cyberbeing

Shader 41, 39, 36, 34, 31, and 24 Avg 4-5ms, Max 8-12ms
Shader 40, Avg 7-8ms, Max 10-13ms (the oddball, worse then the others)

CPU usage is virtually identical between all versions.

Thanks. You're the 2nd (or 3rd?) person who comments on Shader 40 being worst. Strange enough for nijiko Shader 40 seems to work best, but my suspicion is that for nijiko the VSync timing fits better when the GPU has a slightly higher load. That's quite possible with the current (not fully optimized) madVR versions.

Anyway, nobody reported major problems or much lower GPU loads with the latest shader compiler version 41, while several people reported 41 to work at least as well as (or even better than) any older version, so I guess I'll keep using 41 as the default compiler version.

[Grmpf]

Originally Posted by madshi

Theoretically madVR tries to place the OSD info in the top left corner of the visible screen, no matter how much you zoom. There may be a bug somewhere or maybe Zoom Player is doing some funny stuff. Don't know. Can you give me a step by step explanation on how to reproduce this problem?

Sure.

Start Zoomplayer (V6.00), load a file that has black bars encoded and is 2.35:1 (i use a "Ratatouille" Blu-Ray Rip as mkv, but basicly every 2.35:1 file will do) go to Options -> Playback -> Video & Subtitles -> Presets -> Custom AR. Change one to Width 1.33333 and Height 1, click "fetch". Now the picture fills the 16:9 panel fully (need this for my ISCO to do the horizontal stretch) and your OSD is gone ;-)

Its new for me too, till before madVR i did this in ffdshow, just because of the lanczos resizing, but now madVR should handle this, to keep ffdshow out of the filter chain. Thanks for your help !

[nijiko]

Bug report:

Crash with playing FLV files which contain Flash Video 1.
(Decoder ffdshow 2913.)

[madshi]

Any developers with experience in video render programming reading here?

I'd like to make decoders (which connect to madVR) output images in a nice resolution instead of using odd resolutions (like e.g. 777x333) to avoid problems with pitchs/offsets. I see that VMR9 somehow requests a width of 2048 pixels for 1920x1080 movies. How can I do something like this? Thanks!

[nijiko]

Originally Posted by madshi

Thanks. You're the 2nd (or 3rd?) person who comments on Shader 40 being worst. Strange enough for nijiko Shader 40 seems to work best, but my suspicion is that for nijiko the VSync timing fits better when the GPU has a slightly higher load. That's quite possible with the current (not fully optimized) madVR versions.

Anyway, nobody reported major problems or much lower GPU loads with the latest shader compiler version 41, while several people reported 41 to work at least as well as (or even better than) any older version, so I guess I'll keep using 41 as the default compiler version.

What's the diff. of 40 and 41?
I think weather it's because of my CPU.
My CPU is 3.0G.
If some program not working fully supported on multi-threading, single core is better than dual core.

[nijiko]

According to so many people above.
But according to many times and repeated testings on my computer. 40 is much more better than any others.
So I also wonder to know why...

Here is my setting:

[scaling settings]
luma resampler=SoftCubic50
chroma resampler=Bilinear
[trade quality for performance]
don't resample chroma=1
don't use dithering=1
use 10bit luma buffer=0
use 10bit chroma buffer=0
disable anti-tearing fix=1
[output settings]
video levels=0
use 3dlut=1

[Brazil2]

Originally Posted by madshi

Search this thread for "Mitchell". The first hit is what you're looking for.

Yes found it, thanks for the tip

BTW it's now the second hit

[Egh]

Originally Posted by Madshi

When doing extreme downscaling, all the rescaling work is no longer done in the final rendering step, but it's done before in the "texture resampling" step. That is by design.

Can you explain the meaning of various terms? I mean more details what is done during the resampling and what during the rendering step?

[nijiko]

With worth mentioning, I'm using Haali splitter to play videos. (Because it's the best on my computer.)
And my video driver is 185.42.

And prefetch to video RAM is better for playing, tetsuo55 does agree with me.

[madshi]

Originally Posted by nijiko

According to so many people above.
But according to many times and repeated testings on my computer. 40 is much more better than any others.
So I also wonder to know why...

Well, as far as I understand you, you judge by comparing how smooth playback "feels" to you. That is a fair way of judging from a consumer point of view. However, whether playback is smooth or not does not mean a lot right now with the current madVR betas. The only halfway reliable way to check whether 40 is really better than the others is to compare average GPU load numbers (Ctrl+J). Playback may feel smoother with a higher average GPU load under specific circumstances, but still when looking at future potential that would be worse than getting stuttering playback with a lower average GPU load with madVR 0.8. The "final" madVR version will probably give the best results when average GPU load is lowest. So that's why I'm asking for average GPU load numbers above all else...

Originally Posted by Egh

Can you explain the meaning of various terms? I mean more details what is done during the resampling and what during the rendering step?

Sure.

Resample textures:
This is a first processing step which uploads the YCbCr 4:2:0 data (coming from the decoder) to GPU RAM, then usually resamples chroma in X direction and (only if X luma scaling is needed) scales luma in X direction. Under certain circumstances there is a 2nd processing step added, which still falls in the "Resample textures" category, which resamples chroma in Y direction and (only if Y luma scaling is needed) scales luma in Y direction. So this stage consists of at least 1 and at most 4 shader passes. Each shader pass stores the resulting data in 16bit (per channel) buffers.

Clear:
Simply clears the "backbuffer". madVR skips this step if it's safely possible to do so. However, if the final rendering process only covers a part of the backbuffer, clearing is necessary to avoid garbage pixels at the borders of the backbuffer.

Init Samplers:
This is just some setup work, telling Direct3D which textures we want to use for the final rendering pass. Usually this step should not consume any noticeable resources.

Render:
This is the final rendering step, which eventually upsamples chroma in Y direction and eventually scales luma in Y direction (only if not already done in the "Resample textures" stage). Furthermore, still in the same shader pass, the fully scaled YCbCr 4:4:4 data is converted to RGB, either by using the 3dlut file or by using shader math (depending on the settings). Finally, dithering noise is added. The "Render" stage is always executed in exactly one shader pass.

[nijiko]

Originally Posted by madshi

Well, as far as I understand you, you judge by comparing how smooth playback "feels" to you. That is a fair way of judging from a consumer point of view. However, whether playback is smooth or not does not mean a lot right now with the current madVR betas. The only halfway reliable way to check whether 40 is really better than the others is to compare average GPU load numbers (Ctrl+J). Playback may feel smoother with a higher average GPU load under specific circumstances, but still when looking at future potential that would be worse than getting stuttering playback with a lower average GPU load with madVR 0.8. The "final" madVR version will probably give the best results when average GPU load is lowest. So that's why I'm asking for average GPU load numbers above all else...

Thank you for your long reply!!!
Are the info. you wanted like those below?
The snapshot I got it randomly.

[Hypernova]

Short report on shaders: I get the same number for 39-41. ~15ms for 720p video with my setting.

[scaling settings]
luma resampler=Bilinear
chroma resampler=Nearest Neighbor
[output settings]
video levels=0
use 3dlut=0
[trade quality for performance]
don't use dithering=0
use 10bit luma buffer=0
use 10bit chroma buffer=0
disable anti-tearing fix=1

[ericgur]

Originally Posted by madshi

Any developers with experience in video render programming reading here?

I'd like to make decoders (which connect to madVR) output images in a nice resolution instead of using odd resolutions (like e.g. 777x333) to avoid problems with pitchs/offsets. I see that VMR9 somehow requests a width of 2048 pixels for 1920x1080 movies. How can I do something like this? Thanks!

You should (probably) override CRendererInputPin::SetMediaType, there you can change the media type (resolution) and inform the pin's allocator.
http://msdn.microsoft.com/en-us/libr...68(VS.85).aspx.
You can also derive an allocator that allocates memory directly on the GPU (like VMR) if you're at it

[Egh]

@Madshi:

interesting algorithm indeed. Does it perform X and Y scaling in the first step if target resolution is less than 50% on each dimension?

Does it also mean that Y scaling is essentially "free" as it is done with the RGB conversion?

There is one other technical issue I wonder: Haali doesn't accept YV12, only YUY2 (or RGB). I was under impression this is done for performance reasons.

[madshi]

Originally Posted by ericgur

You should (probably) override CRendererInputPin::SetMediaType, there you can change the media type (resolution) and inform the pin's allocator.
http://msdn.microsoft.com/en-us/libr...68(VS.85).aspx.

Thanks - you know your stuff!

I've now overwritten "CRendererInputPin::SetMediaType" and the changed resolution does show in MPC HC's pin info dialog. However, the decoder still sends the old resolution. How can I notify the decoder about the mediatype change?

Originally Posted by ericgur

You can also derive an allocator that allocates memory directly on the GPU (like VMR) if you're at it

Hmmmm... That would be an option. But I'm not sure if that won't interfere with my VSync/anti tearing fix. Right now I'm flushing the GPU and wait until it's idle before I call "Present". That's the only way to get rid of tearing in windowed mode for me. But if I upload incoming frames directly to GPU RAM, I fear that the "is GPU idle?" check will stop working reliably...