madVR - high quality video renderer (GPU assisted)

[Thunderbolt8]

hm would it be possible to add a 'reset defaults' button to all those filter & resize options, in case ones trying around a bit, but then want to go back to the best choices (assuming the default ones always is the best choice)? but perhaps not needed if unistalling & reinstalling resets everything.

[nlnl]

madshi
1) Could you please add the folowing feature to your madvr renderer.
If the input video is 480 (720, 1080) Progressive @59/29 Hz sourced from film (3:2 pulldown inside) could you output 23P to video card doing "inverse telecine" or decimation? Eac3to can do something like that for HDDVD:).
And no need for auto detection of film sourced video. Only the flag - ON/OFF.
That would be a great gift for cinemaphiles. And we would keep video card power - 23p is easier to render then 29/59p? All trash is decimated?

2) Can decoder output interlaced YV12 video to madvr renderer? I guess, that madvr accepts only progressive video and we can not use video card hardware deinterlacing? Stupid question? :)

[Egh]

Hmmmmm.

Totally lost with shaders now :) I've tried all the version and all before 40 seems to be same on 7800GTX.
Version 40 is indeed heavier. The previous versions are approximately 16-17ms max wait (average about 10) and version 40 is about 22-24ms.
But there is even more weirdness: seems that version 41 is on same level of performance as 3x versions :P

In terms of CPU seems that version40 consumes roughly 10% more CPU power. I.e. for 720p AVC being slightly rescaled by lanczos4&softcubic50, version 40 typically consumes 40+ CPU% (dual core total, which is pretty heavy for 2x3.1GHz). Version 3x or 41 consumes 30+ CPU% instead.

Not even a clue why it does that...

[tetsuo55]

madVR 0.7 released

http://madshi.net/madVR.zip

* fixed: video size/position was incorrect with Zoom Player & CoreAVC
* precompiled shaders are now loaded from "shaders.dat" (for testing)
* various shaders files are shipped created with different compiler versions
* OSD now shows 4 different display refresh rate estimates (for testing)
* fixed: with bilinear chroma resampling luma was always resampled, too
This is more of an interim release. Many of the changes (or "new" features) are mainly targeted at locating the cause of these 2 problems:

(1) display refresh rate calculation fails to work correctly
(2) GPU load is noticeable higher compared to madVR 0.4 on older hardware

If you have one of the above 2 problems, please help me by providing the following feedback:

(1) If display refresh rate calculation doesn't work properly for you (open OSD by pressing "Ctrl+J"), please post the first 4 lines of the OSD. There are now 3 display refresh rate estimates and one final refresh rate calculation. The first estimate is supposed to oscillate a lot and be about 3% too high. The 2nd estimate is also supposed to oscillate a lot, but should oscillate around the correct value. The 3rd estimate should be roughly accurate and not oscillate that much. The final number basically is the same as the 3rd estimate, but it accumulates calculations over time to improve accurateness.

(2) If you experienced a higher GPU load with madVR 0.6 compared to madVR 0.4 (if you did, you probably have older hardware), please try out the different Direct3D shader compiler versions. You can do so by replacing the "shaders.dat" file in the madVR root directly with one of the various "shadersXX.dat" files in the "madVR\shaders" subdirectory. The replacement file must be copied to the madVR root folder and renamed to "shaders.dat". The "shaders.dat" file contains all pixel shaders madVR uses. The "XX" number of the "shadersXX.dat" files in the "shaders" subdirectory specifies which compiler version was used for creating the "shaders.dat" file. madVR 0.4 had been using version "35" (which is identical to version "36"), while madVR 0.6 and 0.7 are using compiler version "41" by default. I *hope* that by replacing "shaders.dat" with an older version you can get back the lower GPU load of madVR 0.4. If you have newer hardware, there's probably not much of a difference between the various shader versions. On my ATI HD3850 36 and 41 produce roughly identical GPU loads. However, some other compiler versions produce slightly higher loads. So those of you with GPU load problems please try the various shader versions and let me know which works best for you. Thanks!

Behind my own system now.(HD2400pro Cat 9.5 BETA), tested with 0.8

(1)
Line 2 is the only one that works, the others are way off.
(2)
Gpu usage seems to be equal with all of them, CPU usage is about 10% lower with 36 compared to the default 41.
EVR-CP seems to be between the 2, with higher peaks than 41

[Mark_A_W]

display estimate 1 103.27xxxx hz
display estimate 2 95.9xxx hz (correct)
display estimate 2 135.3xxxhz (completely mental..sometimes hits 142hz)
display 135.3xxx hz (1s)


My display is running 95.904hz interlaced on an ATi HD2600XT, testing in Zoomplayer (CTRL-J is annoying as it is used in ZP).


Watching a 23.976fps MKV file (BD source) it is smooth with Reclock fully active. Not sure about Reclock set to slave....testing still (harder to see without reclock tearing test).

CPU usage is fine, max GPU rendering time is about 17ms.

Thanks Madshi

Cheers

Mark

Madshi, I tried v0.8.

No difference on the refresh rate detection, it's still way too high for estimate 3, and 1 second for display.

However I did notice that if I change from Fullscreen to a smaller window, estimate 3 drops to ~105 to 115hz. Detection time is still 1s.

One more thing to add, I'm running multimonitors, video is played on the secondary monitor.

[nijiko]

hm would it be possible to add a 'reset defaults' button to all those filter & resize options, in case ones trying around a bit, but then want to go back to the best choices (assuming the default ones always is the best choice)? but perhaps not needed if unistalling & reinstalling resets everything.

I think you can just delete the settings.ini.

[Hypernova]

Feedback on refrash rate detection. 2 is definitely the best (always correct). 3 is accurate if and only if I can make the playback smooth. In my case, I can either:

1. Watch the video at original size.
2. Use Bilinear for both scaling method. This make me able to get smooth playback on fullscreen.
3. Change my monitor refresh rate to match the video.

[lobothefoots]

Hi,
I use ZP6 and I set one of the controls like that :
double click = exit fullscreen

I noticed a bug with v0.4 and v0.6, I can only double click when there is black bars, I can't double click in the picture anymore. Can you fix that please?

Bug fixed in v0.8, thanks Madshi
:thanks:

[Jaja1]

Yes, it seems that 2nd estimate is the most reliable. Too bad, in theory the 3rd estimate should be a lot more exact than the 2nd estimate. Practically, it doesn't quite seem to work... <sighNot with me, here the 3rd estimate is more exact than the 2nd. They don't differ much, but the 3rd is more reliable.

Two questions.

With lower bitrate movies playback is reasonably smooth, however higher bitrate blu-rays (both VC1 and AVC and no DXVA or CUDA)are unwatchable because of the stuttering. Your renderer uses GPU not CPU so I don't understand this. This happens using an Nvidia 7600GT. However on a Nvidia 9500GT playback remains smooth with higher bitrate movies.

What are your plans with real 24hz movies and there are quite a few of them. Slow them down to 24/1.001? I wouldn't like to have another refreshrate besides 24/1.001 and 50hz.

[dann23]

installed version 0.8 and now I can double click on to image to go out from full screen, but it doesn't work when I try to do the opposite. and with wmp11 I get every time I close the movie the memory could not be read.

[madshi]

Faster to slower:
40, ... ,31, 34, 24, 41=36, 39.
Version 40 is indeed heavier. The previous versions are approximately 16-17ms max wait (average about 10) and version 40 is about 22-24ms.
But there is even more weirdness: seems that version 41 is on same level of performance as 3x versions :P

In terms of CPU seems that version40 consumes roughly 10% more CPU power.
Gpu usage seems to be equal with all of them, CPU usage is about 10% lower with 36 compared to the default 41.
EVR-CP seems to be between the 2, with higher peaks than 41
Weird. nijiko likes 40 best. For Egh 40 is the worst for both GPU and CPU load. For tetsuo55 36 has lowest CPU usage.

I suggest to leave those diff. versions in the package.
Then everyone can choose the best for him to use.
Not sure if I will really do that. It's extra work for me cause I'd have to recreate all those shader files every time I change the shader code. I'd prefer to use only one compiler version, ideally the newest...

hm would it be possible to add a 'reset defaults' button
Just delete "settings.ini".

1) Could you please add the folowing feature to your madvr renderer.
If the input video is 480 (720, 1080) Progressive @59/29 Hz sourced from film (3:2 pulldown inside) could you output 23P to video card doing "inverse telecine" or decimation? Eac3to can do something like that for HDDVD:).
And no need for auto detection of film sourced video. Only the flag - ON/OFF.
That would be a great gift for cinemaphiles. And we would keep video card power - 23p is easier to render then 29/59p? All trash is decimated?

2) Can decoder output interlaced YV12 video to madvr renderer? I guess, that madvr accepts only progressive video and we can not use video card hardware deinterlacing? Stupid question? :)
I don't have plans to do stuff like that, at least not anytime soon. Deinterlacing can easily be done before madVR.

With lower bitrate movies playback is reasonably smooth, however higher bitrate blu-rays (both VC1 and AVC and no DXVA or CUDA)are unwatchable because of the stuttering. Your renderer uses GPU not CPU so I don't understand this. This happens using an Nvidia 7600GT. However on a Nvidia 9500GT playback remains smooth with higher bitrate movies.
See first few posts of this thread. madVR is not optimized for smooth playback yet.

What are your plans with real 24hz movies and there are quite a few of them. Slow them down to 24/1.001? I wouldn't like to have another refreshrate besides 24/1.001 and 50hz.
madVR is just a video renderer. If you want to watch 24.000 movies in 24.000/1.001 the main thing you need to do is change audio FPS, e.g. by using ReClock or eac3to.

with wmp11 I get every time I close the movie the memory could not be read.
That is a bug in wmp11, it doesn't properly close/free madVR. Neverthelss the problem might go away with a future madVR version - or not...

[Jaja1]

See first few posts of this thread. madVR is not optimized for smooth playback yet.I know that. But I'm talking about the lack of smoothness, only when bitrates are high with a specific vidcard. AVG GPU Rendering Time increases up to 100ms for high bitrates, while with low bitrates rendering time is more like 20ms or something like that. That is what I don't understand.

EDIT:
After some more testing, high avg GPU rendering times seem to be title specific. I found a title with bitrates up to 40mbs with low rendering time and I found a title with low bitrates (below 10mbs) with very high rendering times. On average blu-rays are problematic while lower bitrate HDTV broadcasts are mostly problemfree. This is for a 7600 GT. Is anyone else experiencing this?

[tetsuo55]

Weird. nijiko likes 40 best. For Egh 40 is the worst for both GPU and CPU load. For tetsuo55 36 has lowest CPU usage.

It might be a good idea to create an actual benchmark.
That would remove all variables.

all it would have to do is render a stream to a null surface of a fixed size, while doing so measure everything you care about, like GPU time and CPU time.

The result should be a simple batch of numbers.
You can use the same test to benchmark different implementations of code too.

This way we could find the cause of the differences very quickly(apart from the added coding time)

[vucloutr]

tried all shader**.dat files with a GeForce 7050 PV (weak onboard graphics) on 720p material and 1280x1024 screen (so no resize).
chroma resampling "Bilinear" anymore isn't possible, no other quality tradeoffs.
10bit luma/chroma has no effect, this is correct for GeForce 7 ?
if 10bit isn't possible for GeForce 7 maybe you can grey out the fields, so it would be perfectly clear.

24-39: average rendering time: ~15ms / max render. time: ~19ms spikes up to 22ms
40&41: average rendering time: ~14ms / max render. time: ~17-18ms spikes under 20ms

40 and 41 are best for me.

[nlnl]

Nvidia IGP 9400 +512m, Intel 8300 2.83, Vista 32, AERO, ffdshow mt, MPC-НС 1065
madVR 0.7 reports:
AERO ON
3dlut off

luma - lancsoz3
chroma - softcubic100

1) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - NO RESIZE, monitor resolution - 1920x1080

madVR 0.7 OSD says
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable:)
avrg GPU rendering time - 25 (stable)
max GPU rendering time - 32 (stable :), but when AERO OFF max GPU rendering time is not stable and floating 32-62 and I can not get smooth playback )

2) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - RESIZE 1920x1080 --> 132,0,1766,919

madVR 0.7 OSD says:

display estimate - the same
avrg GPU rendering time - 45
max GPU rendering time - 55-80

CPU load
OSD ON - 90-95%
OSD OFF - 65-72% :confused:

EVR CP 10bit, bicubic A=-1
RESIZE 1920x1080 --> 132,0,1766,919
CPU load - 45-55%


And now I tested Cuda-accelerated H-264 codec CoreAVC.
1) NO RESIZE
avrg GPU rendering time - 32
max GPU rendering time - 40-55 (not stable !)

2) RESIZE DOWN
avrg GPU rendering time - 56
max GPU rendering time - 63-73

CPU - 30-35% (OSD OFF) :)
madshi
Is it possible partly shift computing to CPU (an option)? And so CPU and video IGP will be equally loaded.

3) EVR CP 10bit, bicubic A=-1
RESIZE 1920x1080 --> 132,0,1766,919
CPU load - 10-20%

[Brazil2]

- regarding the mpg file: using the Microsoft MPEG1 decoder (from WinXP), there will be no playback. Using ffdshow for MPEG1 video decoding, playback will work. So this issue is still standing, as there seems to be an incompatibility between the Microsoft MPEG1 decoder and madVR.
For the info, I have no problems with the XP MPEG1 decoder, it's working fine for me with MadVR using MPC-HC 1059 internal splitter.

[KoD]

Addition, then:

- regarding the mpg file: using the Microsoft MPEG1 decoder (from WinXP) and the Microsoft MPEG-I Stream splitter, there will be no playback. Using ffdshow for MPEG1 video decoding and the Microsoft MPEG-I Stream splitter, playback will work. Using the Microsoft MPEG1 decoder (from WinXP) and MPCHC's internal MPEG PS/TS/PVA splitter, playback will work. So this issue is still standing, as there seems to be an incompatibility between the Microsoft MPEG-I Stream splitter, Microsoft MPEG1 decoder and madVR.

[KoD]

madshi, average GPU rendering time is irrelevant. 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.

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. I'm convinced that what people are reporting right now is more likely what they're trying to convince themselves they're seeing, rather than how things really are. It's how the human mind works, we're biased to look for what confirms whatever our random expectation is at the moment rather than be machine-like objective, and there's nothing we can do about it.

I've spent a bit too much time this weekend testing renderers and video players, I'm going to take a break now.

As it stands, guessing how things are from my limited sample of one :), the renderer is usable by laptop owners when upscaling to something like 1440x900 from 720p, 480p or lower resolutions, and playback will be smooth with a medium or top of the range mobile GPU, although a small stutter here and there will still happen. Downsampling from 1920x1080 to common laptop screen resolutions is going to be troublesome, but it still can be achieved as long as one uses a resampling filter lower than Lanczos3 in my case, with the occasional stutter here and there.

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. Unfortunately, MPC - HC is still bug ridden, and today's test proved me that an older version is better than the latest version. Also, DXVA is not working with all types of H264 files, so have CoreAVC or the DivX H264 decoder installed on your system for those cases (MPC's internal software h264 decoder is slower than those two). And also, MPC HC's internal subtitle filter causes a slight jitter spike each time a line is displayed, when you're not using subpictures buffering with it (and you should not be using subpicture buffering, or you'll not get animated text effects working in ASS files).

[Grmpf]

Hi madshi,

thank you for this new project - getting 3dluts to work on a htpc is a major step ahead for showing the correct colors - if we get a "1 Click" solution in hcfr to output a 8x8x8 (or even 16x16x16) correction lut for our displays/projectors and use this lut (instead of only the primaries) in cr3dlut we are at one level with the professionell equipment.

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 ? Anyways keep up the good work, i will provide some numbers later, was just a very fast tryout atm.

[leeperry]

if we get a "1 Click" solution in hcfr to output a 8x8x8 (or even 16x16x16) correction lut for our displays/projectors and use this lut (instead of only the primaries) in cr3dlut we are at one level with the professional equipment.
not really, because their spectrophotometers(Minolta CS200 and so) are far more accurate than consumer colorimeters(i1d2/spyder3) mostly because they're recalibrated every few months and use higher grade components....but it's still great to have :cool:

anyone w/ displays that have gamut smaller than SMPTE-C getting *identical* results to the PS script/ddcc in realtime? :(

oh well, I've sent screenshots to yesgrey, I'm sure he'll find a solution http://forum-images.hardware.fr/images/perso/otakonleboss.gif

[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 :confused:

[Brazil2]

What's the diff between bicubic and softcubic?
And between such as 50, 60, 70...?
II've already explained that before in this thread.
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]

madshi, average GPU rendering time is irrelevant.
Are you trying to tell me that you know better than I do? ;)

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.

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...

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).

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?

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.

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!

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 :confused:
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.

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]

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]

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]

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]

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 :p ;)

[Egh]

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]

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...

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]

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]

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/library/dd375168(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]

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/library/dd375168(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?

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...

[madshi]

Does it perform X and Y scaling in the first step if target resolution is less than 50% on each dimension?
No, it does that if the chroma resampling filter needs to work with more than 4 input samples per pixel.

Does it also mean that Y scaling is essentially "free" as it is done with the RGB conversion?
No, not at all. There might be a small benefit doing it in the same pass as RGB conversion, because every saved pass helps. But then the overhead per extra pass seems to be surprisingly low. So I don't think there's much difference between doing Y scaling as an extra pass or doing it in the RGB conversion pass. A pass doesn't have a fixed "runtime". It can run through fast or slow, depending on how much work the shaders have to do.

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.
I don't know why he's done it that way. Of course if YUY2 or even RGB is sent to the renderer, the renderer has to do less work - but then the CPU has to do more work. The purpose of madVR is to do everything in best possible quality. So madVR does not let decoders do YV12 -> YUY2 upsampling, because all decoders I know are doing this is inferior quality compared to madVR.

[nijiko]

>>madshi

I wonder to know if use 41 for less h/w usage, that, can it be smoothly like 40?

[Mike5]

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.

Interesting. I thought that a chroma resampling algorithm would always resample in Y direction first, to give 4:2:2 and to X direction after that, to give 4:4:4.

[nijiko]

>>madshi

Because I think, end-users always do not care about how much usage and what method to enable effect, but finally what presentation just is the fact.
And it's also what you finally want to do, isn't it?

[nijiko]

Important BUG!!!

Can't step the video and get snapshots...

[tetsuo55]

Important BUG!!!

Can't step the video and get snapshots...

Use the "print screen" button on your keyboard and paste in paint.exe

[mark0077]

Hi, Ran a Test DVD today to check some recent changes to ffdshow, but noticed some badish banding on the gradient test (probably my TV causing alot of this) but wanted to try madVR.

Surprised the "macrovision failed" error still occurs in the latest version. :( this stopped me using haali for playing back all of my ripped DVD's also... did you get a chance to look into this error madshi? When i ripped these DVD's I removed all protection's and using AnyDVD doesn't have any effect on it..

[nlnl]

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.

I have read somewhere that the best way to do resizing is to resize in RGB colorspace (and maybe in "linear light").
And MadVR resizes in YCbCr colorspace if I get your algorithm correctly.
Performance is the problem? What do you think about that?
Thanks!

[nijiko]

Use the "print screen" button on your keyboard and paste in paint.exe

I know this way, but it's a bug ,isn't it?

[cyberbeing]

I know this way, but it's a bug ,isn't it?
I would consider it an unsupported feature, rather then a bug.