madVR - high quality video renderer (GPU assisted)

[Hypernova]

Hi, there. It is always good to have alternative renderers. The new renderer is able to outperform any other renderer I worked with in the past in respect to image quality.

It would realy be great if the supported colorspaces could be extended to at least YUY2 and NV12 (although I know that planar colorspaces are easier to handle).
Also the support of the IBasicVideo::GetCurrentImage interface to create a snapshot would be desirable.

If you look at the first page, I believe madshi already explain why he intentionally made madVR support only one colorspace. Also, he already said that screenshot is middle priority feature. Use search for more info.

[VHT]

Hi! I'm using currently EVR CP and BT709 in shaders.With your madvr I get better PQ but how can I get BT709 color mode on in your video renderer? with LUT? If so, then how?

[honai]

madVR choses the correct coefficients (601 or 709) automatically. depending on the width/height of the source.

[racerxnet]

madVR choses the correct coefficients (601 or 709) automatically. depending on the width/height of the source.

What happens when you scale SD content to HD? I would assume you are now using the wrong color space and need to calibrate accordingly.. Hence the suggestion to allow the user to select the correct LUT within the GUI.

MAK

[noee]

Why would you scale your SD material before sending it to madVR? That's really one of the main reasons to use madVR, unless I'm missing something completely?

[racerxnet]

Why would you scale your SD material before sending it to madVR? That's really one of the main reasons to use madVR, unless I'm missing something completely?

Unless I have an external scaler, I need to scale to the native panel resolution of the LCD for 1:1 pixel mapping. That is the whole point of using the PC; as a scaler for the output. Some of the HD LED tv's have a 1366 x 768 native resolution such as mine, and I need to scale to this for clear readable text. There are other reasons as well, but in my case this is the need/reason.


Thanks,

MAK

[Grmpf]

Unless I have an external scaler, I need to scale to the native panel resolution of the LCD for 1:1 pixel mapping. That is the whole point of using the PC; as a scaler for the output. Some of the HD LED tv's have a 1366 x 768 native resolution such as mine, and I need to scale to this for clear readable text.

You did read the first page - did you ? One of the key elements madVR is doing is scaling and madVR does this far better than any (or most) other solutions on your pc. So if you are scaling before you feed your video into madVR you are doing something wrong (imho), the best case is it to leave your video they way it is and let madVR handle the proper change from 4:2:0 to 4:4:4, the scaling and the colormatrix (601 or 709).

[Steveo08]

i have a question to madVR at present i am using mpc-hc with dxva and for a better picture the pixel-shader "sharpen complex 2".

now i would like to know how do i get the same (and perhaps better???) results with madVR?

i am using vista 32 with a geforce 8600 gt hdmi.

so and an other question is, does anyone get coreavc 1.95 working with cuda and madVR?

[noee]

With all due respect MAK, you are, quite simply, missing one of the main points of using madVR. I suggest you do as Grmpf recommends and go back and read the first page.

[Steveo08]

With all due respect MAK, you are, quite simply, missing one of the main points of using madVR. I suggest you do as Grmpf recommends and go back and read the first page.



you mean me?

[73ChargerFan]

you mean me?
noee was talking to racerxnet, from a few posts above.

Unless I have an external scaler...

Thanks,

MAK

[KoD]

Ok, since this gets repeated:
- CoreAVC using CUDA and madVR works. If you get issues, it simply means you need to use a less demanding algorithm for resampling (max gpu rendering times may seem to be below frame duration, but in reality you have spikes in max gpu rendering times which go above frame duration and that's why you get jerky playback).
- subtitles with madVR work. I'm using ZoomPlayer and vsfilter.dll (the subtitle renderer). MPCHC might not work since it has code that deliberately skips vsfilter from loading (I'm not very sure about this though, I'm not using MPCHC). The most recent version of vsfilter.dll is usually the one packaged in Aegisub, since jfs is the one that did most vsfilter patches in recent times. jfs, I hope you don't mind if I post a direct link to your latest version: vsfilter-2.39e (http://www.animereactor.dk/aegisub/vsfilter-2.39e.rar). Download it, unrar it, and register it with your favorite filter manager or on the command line.

[racerxnet]

You did read the first page - did you ? One of the key elements madVR is doing is scaling and madVR does this far better than any (or most) other solutions on your pc. So if you are scaling before you feed your video into madVR you are doing something wrong (imho), the best case is it to leave your video they way it is and let madVR handle the proper change from 4:2:0 to 4:4:4, the scaling and the colormatrix (601 or 709).

I have been on this thread from the beginning, so yes I read all pages. I am not concerned about the color space from 4:2:2 to 4:4:4 as I am aware of this. If you read my thread correctly I am concerned whether MadVr uses the correct Lut when scaling to the NATIVE resolution of my panel. If it does, GREAT. If not it would be nice to have a selection within the GUI for 601 or 709.

The reason I ask this is: Is MadVR is using the scaling values from powerstrip to identify 601 or 709, or is it using a flag within the stream to identify SD or HD. If using the first situation we will have the wrong lut in use. The use of the PC to scale has been done by many as you are aware, and to give control over custom porch values on a CRT as well.

MadVr has no capabilities to change resolution, it is the job of the graphics card; ie from (SD)720 x 480 to (HD)1920 x 1080p. Please correct me if I am mistaken as to how MadVr determines LUT usage.


Thanks,

MAK

[mark0077]

I have been on this thread from the beginning, so yes I read all pages. I am not concerned about the color space from 4:2:2 to 4:4:4 as I am aware of this. If you read my thread correctly I am concerned whether MadVr uses the correct Lut when scaling to the NATIVE resolution of my panel. If it does, GREAT. If not it would be nice to have a selection within the GUI for 601 or 709.

The reason I ask this is: Is MadVR is using the scaling values from powerstrip to identify 601 or 709, or is it using a flag within the stream to identify SD or HD. If using the first situation we will have the wrong lut in use. The use of the PC to scale has been done by many as you are aware, and to give control over custom porch values on a CRT as well.

MadVr has no capabilities to change resolution, it is the job of the graphics card; ie from (SD)720 x 480 to (HD)1920 x 1080p. Please correct me if I am mistaken as to how MadVr determines LUT usage.


Thanks,

MAK

No madVR does the changing of the resolution for you and output that to your display, using a variaty of techniques that you can choose from within the madVR options.

[Grmpf]

I have been on this thread from the beginning, so yes I read all pages. I am not concerned about the color space from 4:2:2 to 4:4:4 as I am aware of this. If you read my thread correctly I am concerned whether MadVr uses the correct Lut when scaling to the NATIVE resolution of my panel. If it does, GREAT. If not it would be nice to have a selection within the GUI for 601 or 709.

The reason I ask this is: Is MadVR is using the scaling values from powerstrip to identify 601 or 709, or is it using a flag within the stream to identify SD or HD. If using the first situation we will have the wrong lut in use. The use of the PC to scale has been done by many as you are aware, and to give control over custom porch values on a CRT as well.

MadVr has no capabilities to change resolution, it is the job of the graphics card; ie from (SD)720 x 480 to (HD)1920 x 1080p. Please correct me if I am mistaken as to how MadVr determines LUT usage.


Thanks,

MAK

Hello Mak,

i didn't wanted to be rude in my last post, but i think you still have some misunderstanding about madVR and how it works. Powerstrip changes the resolution of your PC/Desktop and Player software (if its fullscreen), but the scaling is done by the renderer (if you do not use ffdshow or similar and you should *not* use it if you use madVR instead), common renderers doesn't allow you to choose how they scale and they scale bad compared to madVR (or ffdshow, thats why everyone uses ffdshow to scale before madVR was around), but madVR gives you the full control over it, you can even choose differend scalingmethods for luma and chroma ! This has nothing to do with the LUT btw. the LUT is for changing the colorspace and for correcting the primaries/etc. of your display.

So now to your "problem", madVR looks at the input resolution (if you feed SD it uses 601, if you feed HD it uses 709) and not at the output resolution to determine which colormatrix/LUT to use. It does not use the output resolution for the determination or some flag or so, just the input resolution you feed into madVR (thats one reason why it is bad to scale before madVR).

[mark0077]

madshi, you can download a TestDVD here http://merifon.altervista.org/TestDVD.html

This also gives the macrovision failed error with madVR and Haali renderers so you might be able to get around that issue :D

Best of luck!

[racerxnet]

So now to your "problem", madVR looks at the input resolution (if you feed SD it uses 601, if you feed HD it uses 709) and not at the output resolution to determine which colormatrix/LUT to use. It does not use the output resolution for the determination or some flag or so, just the input resolution you feed into madVR (thats one reason why it is bad to scale before madVR).

Thanks for the heads up. All I needed to know is how it is determining the Lut usage and you explained it quite clear. I do not use FFdshow. MPC-hc uses Nvidia audio-video decoder and Madvr for external filters. That's all. I've checked the output levels with a test disk but wanted to make sure how the lut was being used.


Thanks,

MAK

[TinTime]

So now to your "problem", madVR looks at the input resolution (if you feed SD it uses 601, if you feed HD it uses 709) and not at the output resolution to determine which colormatrix/LUT to use. It does not use the output resolution for the determination or some flag or so, just the input resolution you feed into madVR (thats one reason why it is bad to scale before madVR).

Just to add, the SD/HD decision is made with these boundaries:
HD = wider than 1024 or higher than 576

[racerxnet]

Just to add, the SD/HD decision is made with these boundaries:

Originally Posted by madshi View Post
Originally Posted by madshi View Post
HD = wider than 1024 or higher than 576

Which does not explain my desire to know specifically how LUT use is determined. Input HD = wider than 1024 or higher than 576 or, output of the stream??? Madshi, would you please clarify this. I know there have been requests to select the Lut profile from the GUI in previous posts, so I am not the only one concerned about this situation.

Thanks,

MAK :o

[madshi]

It would realy be great if the supported colorspaces could be extended to at least YUY2 and NV12
YUY2 support is not planned. Simple reason: Some decoders prefer to output YUY2 and always do that if the renderer accepts it, but they are willing to output YV12 if YUY2 is not accepted. YV12 is better for quality. So madVR does not accept YUY2 to force decoders to output the better quality format.

NV12 could eventually be added later, but you can also use ffdshow to convert YV12 to NV12 right now. So it's not high priority for me.

i have a question to madVR at present i am using mpc-hc with dxva and for a better picture the pixel-shader "sharpen complex 2".

now i would like to know how do i get the same (and perhaps better???) results with madVR?
Custom post processing pixel-shaders are currently not supported by madVR. That will come later...

madshi, you can download a TestDVD here http://merifon.altervista.org/TestDVD.html

This also gives the macrovision failed error with madVR and Haali renderers so you might be able to get around that issue :D
Thanks!

Which does not explain my desire to know specifically how LUT use is determined.
Grmpf already explained that perfectly well.

[Egh]

Regarding these 601/709 colormatrices, I have already suggested an option to override the matrix chosen over automatic detection. The reason is that the resolution-based condition is not always correct (I think one such sample from Apple has been posted here already, and there are some other cases as well, let's say there are plenty of encoders in the world and not all of them adjust colourmatrix as required :P)

[pie1394]

The stream demuxer or the video decoder often knows the video output's color space. (Of course, only if appropriately encoded)

To make it more accurate to handle the decoded video frame's "color space", there are two methods:

1. If there is such MetaData embedded in the decoded video frame, the video post-processor / renderer can handle this by itself.

2. If it is not embedded in the decoded video frame, this relies on the player program to grab video stream's color space info from stream demuxer or video decoder, and instruct the video post-processor/renderer to do the right conversion. Of course the video processor needs to provide an API for the player to adjust the setting dynamically.

[AJ73]

I invested a lot of time to undderstand pros and contras of all the colorapaces (in the PC area not in the TV area).
I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?

MPEG-4 and H.264 (not the studio and high quality profiles) use 4:2:0 internally so the information in the source (file, RTP stream) is already lost. But there are also formats like MJPEG that use higher quality color subsampling internally (4:2:2) and some formats also use 4:4:4 color subsampling. My attemt was alwas to avoid any color conversion if possible. That is the reason why YUY2 would have been nice.

You are right that FFDSHOW raw filter can be used for conversion (that is in most cases lossy). But in a multiinstance application the use of an additional filter is bad for the performance.

[FoLLgoTT]

I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?

There is no more information. The source (DVD/Blu-ray) is subsampled in 4:2:0. When outputting YUY2 the decoder itself does the upsampling to 4:2:2 which is usually much worse than the upsampling madVR does. YV12 ensures that the decoder outputs the data as decoded. This is the reason why YV12 is better in this case.

[madshi]

The stream demuxer or the video decoder often knows the video output's color space. (Of course, only if appropriately encoded)

To make it more accurate to handle the decoded video frame's "color space", there are two methods:

1. If there is such MetaData embedded in the decoded video frame, the video post-processor / renderer can handle this by itself.
True.

I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?
Yes, but only if the source actually contains that much information. And that is exactly the key point. By far most sources do not contain more than 4:2:0.

MPEG-4 and H.264 (not the studio and high quality profiles) use 4:2:0 internally so the information in the source (file, RTP stream) is already lost.
It's not only MPEG4 and h264. MPEG1, MPEG2, MPEG4, h264, DviX, Xvid, VC-1 all usually use 4:2:0. There are some rare exceptions where 4:2:2 or 4:4:4 is encoded, but 4:2:0 is by far the most common used format for encoding. Still, many decoders insist on outputting YUY2, if you let them, even for 4:2:0 sources. Which means that the decoder is internally doing chroma upsampling in inferior quality. And that is what I want to avoid.

Edit: Seems I was too slow in replying... ;)

[Thunderbolt8]

got my new HD 4770 (only have a PCIe 1.0 slot though), this is for the US sin city BD:

display 1 estimate: 62.XXXXXHz
display 2 estimate: 60.0XXXXHz
display 3 estimate: 60.0XXXXHz
display 60.03804Hz
movie 23.976 fps
frame queue 16/16
movie res 1920, 1080
target rectangle 0, 152, 1280, 872
movie frame interval 41.71ms
avrg gpu rendering time 6-14ms (depending on scene)
max gpu rendering time 8-20 I'd say
arg present wait 'till 14ms


seems like the HD 4770 is not yet listed under the cards to choose new drivers for at ati/amd.com?

btw. is installing that avivo video thing good for anything?

[Mark_A_W]

In my experience, interlaced output doesn't work well with HTPCs, though, so my plans do not include interlaced output or interlaced graphics modes...



:scared:

As someone who uses an Interlaced resolution, very successfully (1080i 95.904hz, which is 47.952hz in Powerstrip with the interlaced box ticked)...

I'm obviously freaking out at that statement.

Does it really make that much difference to the renderer? How does it know if the 96hz it is detecting is 96 progressive or 48 interlaced?

I assure you, interlaced resolutions work very, very well. Currently I have very smooth playback with Haali + Reclock, or MPC EVR custom.

All I'm asking is that interlaced resolutions are not precluded from smooth playback. I, at least, can live without fancy refresh rate changes.

[madshi]

All I'm asking is that interlaced resolutions are not precluded from smooth playback.
I don't have any code that specifically excludes interlaced output modes from working - and I don't have any plans to add any such code.

[pie1394]

Although madshi does not plan to support "deinterlace" capability, I still would like to explain some rules to deal with the interlaced contents here.

For interlaced contents to be "vertically" scaled, it needs to be deinterlaced first no matter the output device is progressive-scan (most LCD, regular PDP) or interlaced-scan one (regular CRT, Hitachi ALIS PDP, special LCD monitor for broadcasting 1080i content inspection).

For interlaced-scan output device, it can be chosen to do the separate vertical field-scaling on interlaced contents to avoid the deinterlacing process. But the good motion-adaptive deinterlacing + frame scaling mode still produce better video quality, especially in the static scenes.

For progressive-scan output device, there is no choice. "deinterlacing" process must be done for interlaced contents before the horizontal + "required" vertical scaling processes.

[73ChargerFan]

In my experience, interlaced output doesn't work well with HTPCs, though, so my plans do not include interlaced output or interlaced graphics modes...
The first two or three generations of DLP rear projection TVs were 1080i only. That's a lot of early adopters.

I'm lucky, in that I purchased the first 1080p DLP produced. My set works equally well with 1080i/1080p output from my HD-DVD players.

[Wilbert]

@madshi


Originally Posted by Wilbert
In a few days i will post a story about those splines! Stay tuned

Looking forward to it...
Please have a look at: http://forum.doom9.org/showthread.php?p=1286008#post1286008

[Mark_A_W]

I don't have any code that specifically excludes interlaced output modes from working - and I don't have any plans to add any such code.

Thank you. That's all I ask.


Did you get my uploaded vysnc.dat file? I think I'm the only one who did it - and it was pages and pages ago now.

[Hypernova]

Thank you. That's all I ask.


Did you get my uploaded vysnc.dat file? I think I'm the only one who did it - and it was pages and pages ago now.

I did too, and a couple others, so you're not the only one :)

[madshi]

Did you get my uploaded vysnc.dat file?
Those vsync.dat files I got indicated that sometimes your graphics cards report flat out incorrect scanline information. That confused madVR's display refresh rate calculation formulas. That should be worked around in the next madVR build.

[madshi]

madVR 0.10 released

http://madshi.net/madVR.zip

* added first (buggy) version of smooth motion rendering
* added uploading queue (up to 8 frames)
* added rendering queue (up to 8 frames)
* added information about dropped and delayed frames to OSD
* removed GPU rendering times from OSD
* added (buggy) frame stepping support
* modified DVD / macrovision handling slightly
* display refresh rate detection should no longer produce incorrect results
* added separate controls for luma upscaling and downscaling
* fixed: image was sometimes offset in 1:1 mode in ZoomPlayer
Hurray, first smooth motion version out!

Unfortunately I've found that it's next to impossible to get things *perfectly* smooth in windowed mode (at least on my PC). So perfection will have to wait until madVR is able to do fullscreen exclusive mode. However, my current development PC is not the fastest/best, so maybe you can get good enough results with madVR even in windowed mode, if your PC works better than mine. At least madVR 0.10 should be a lot smoother than older versions (I hope).

Technically the problem is that whenever you tell the GPU to display a rendered frame during the next vsync blank, the GPU stalls and stops doing anything else until the next vsync blank finally occurs. That means that if madVR asks the GPU very early to display a rendered frame during the next vblank, there's not enough GPU time left to do the actual rendering, cause the GPU is stalled most of the time waiting for the next vblank. On the other hand, if madVR tries to display the rendered frame as late as possible (in order to gain more GPU processing time), the danger of missing the target vblank period grows. A missed target vblank means judder or tearing or both. Argh, isn't that fun? AFAIK, these problems should go away in fullscreen exclusive mode, fortunately.

madVR 0.10 now uploads the video data to the GPU in a separate thread. Also rendering and displaying the images is also done in separate threads. That all means that retrieving correct and meaningful GPU rendering times is more difficult. So I've simply removed GPU rendering time information from the OSD now. However, I've added information about uploading and rendering queues. Generally, if the upload and rendering queues stay over at least 4/8, your GPU seems to be fast enough to handle the madVR settings you've activated.

Also I've added information about dropped and delayed frames to the OSD. During startup of movie playback it's acceptable to get a few dropped or delayed frames. But 3-5 seconds after the movie starts the number of dropped/delayed frames should not increase, anymore. Every time you see motion judder on screen, probably either the dropped or delayed frame count increases. If the number of dropped/delayed frames does not increase for you after 3-5 seconds of runtime, you should get perfect playback quality. Well, I mean: As perfect as the ratio of display refresh rate and movie frame rate permits, of course.

Display refresh rate calculation should work correctly now. If it doesn't, you will probably not get smooth motion playback. So make sure you double check (especially those of you for which display refresh rate calculation failed to work with older madVR versions).

I've also slightly worked on DVD playback ("macrovision failure"). For me it works. However, I've noticed that the DScaler decoder doesn't always work with madVR when playing back DVDs while the Cyberlink MPEG2 decoder always works.

Frame stepping is now implemented, but buggy. Generally madVR has gone a bit buggy/unstable due to the many deep changes. As long as you don't pause/stop/resize etc, things should be stable. If you do anything madVR has to react to you might get funny results, or maybe it will work just fine. If you run into problem that is reliably reproducable please let me know.

[wayland]

how do you open the detailed osd in 0.10? ctrl+j twice doesnt seem to do it any more.

also going a bit off topic but how should the dynamic range be set on nvidia hardware full(0-255) or limited (16-235)? either seems to result in a differant image with madvr and HR compared to evr custom

[honai]

madshi, awesome work, thanks! Tested it again on the Iron Man BD w/ the 4770, refresh rate was correctly detected at 60.00071 Hz (and stayed there for the whole 250s I tested), decoder queue 16/16 fixed, upload queue 4/8 fixed, render queue 8/8 fixed, 10 dropped frames, 2 delayed, all during first few seconds. Playback "feels" almost perfectly smooth, the very tiny stuttering could also be the effect of 23.976@60Hz playback. Feels definitely as smooth as the best iteration of Beliyaal's EVR CP.

One tiny request: Could you make the OSD position toggle between the top and bottom? Might come in handy for us plasma users. ;)

[Mark_A_W]

Madshi, this new version, well...


YEA HAR!!


display 95.90368Hz (397s) perfect, time just keeps growing
movie fps 23.976fps (says source filter)
decoder queue 16/16
upload queue 4/8
render queue 8/8
movie res 1920,1080
target rectangle 0,0,1920,1080
v sync interval 10.43ms
movie frame interval 41.71ms
dropped frames 3 Just from startup, stable after that
delayed frames 3 Just from startup, stable after that



Playback is smooth, so far. I need to watch a whole movie to be certain.

I am using Reclock, but disabled (original speed locked, slaved).

The HD2600XT seems capable for watching 1080p material at 1080i 96hz.

Was it the interlaced res that causes the scanline reporting issue? Because an interlaced res has a half scanline at the bottom, or somesuch, to form the offset between fields (it has an early V-sync once per frame).


A small feature request: A tearing/smoothness test. Using Zoomplayer, with Reclock "bypassed", I have no tearing bar test, which is very handy for checking issues.

And that raises the Reclock issue...are you using Reclock? If so, what settings? Active or bypassed? If not, will Reclock bypassed, just a WASAPI renderer, cause any issues? It doesn't seem to.


I'm slightly concerned about the need for Fullscreen Exclusive for "perfect" playback. I understand why (I think), but it's a bit clunky - and there goes the UI on Zoomplayer. Oh well, smooth playback and gamma are my number one priorities.


Once this renderer has subtitles, it will replace Haali Renderer on my system for all material.

The GPU rendering stats in the OSD are missed.

Thank you very much Madshi, honai is right, it "feels" smooth. With Haali Renderer it always "feels" like it is about to throw a little stutter party. Beliyaal EVR custom has this smooth feel too, but I get a glitch after an hour.

I will test a full movie tonight.

[Thunderbolt8]

just to nitpick, does it have to be 0.10 or 1.0? 10 comes after 9, yes, but just from the looks after 0.9 I'd expect to get 1.0. I'd rather say that 0.10 follows after 0.09 :P

for the same movie as a bit above, with 0.10 & HD 4770:

display estimate: 60.037XXHz
movie 23.976 fps
decoder queue 16/16
upload queue 4-5/16
renderer queue 8/8
movie res 1920, 1080
target rectangle 0, 152, 1280, 872
vsync intervall 16.66ms
movie frame interval: 41.71ms
dropped frames: usually none, ~3 when skipping through
delay frames: usually none, 1-2 when skipping through

whats a bit anyong is that flicker when you hover over the playback bar with the mouse in fullscreen mode, then there is a flickering each time. but I guess thats still part of the buggy phase.

[Mark_A_W]

whats a bit anyong is that flicker when you hover over the playback bar with the mouse in fullscreen mode, then there is a flickering each time. but I guess thats still part of the buggy phase.

What player Thunderbolt?

[wayland]

mpc-hc does that.

about the nvidia question i asked changing from rgb to YCbCr444 fixes it

[Hypernova]

Refresh rate is correct. Upload queue is ~4-5/8. Render queue is ~7-8/8. But I can't get any smooth playback if my setting is anything beyond Bilinear/Bilinear when go fullscreen (2560x1600). Drop and delayed frame also keep on incresing. Maybe I did something wrong?

[cyberbeing]

It seems much smoother now, which is good, but it's unstable. I've had at least 10 random lockups of the renderer in the last hour, when doing things like pausing, seeking, and going from fullscreen <-> windowed. If you don't mess with it, it seems fine though.

Pausing the video and going to fullscreen seems to lockup the renderer every time. It goes to fullscreen with the screen black, displays what I assume was in the frame cache, the screen goes black again, and the renderer locks-up.

There is a randomly occurring issue when it get the end of the file. Sometimes it will exit fullscreen, display a black frame, and then playback the last half-second (emptying the frame cache?).

Moving the video window around with MPC-HC results in massive flickering and tearing.

Considerable dropped/delayed frames when first opening the file and when switching from fullscreen <-> windowed.

For some reason I occasionally get delayed frames (the render queue fluxuates between 7/8 and 8/8) when I downscale a 1920x1080 video to 1600x900 (1600x1200 display res). When upscaling, I don't have this problem.

It's also not remembering luma scaling settings:
http://img32.imageshack.us/img32/4861/lumascale.png

The good news is that the sample I uploaded a 3 weeks ago, as well as pretty much everything else I tried, now seems to playback nice and smooth with 0.10.

[Egh]

Epically superior build!!!!


Believe it or nuts, but you [almost] solved the secondary monitor problem! Now it doesn't max one of the cores, keeps it at half (i.e. tends to be around 50%) on one of the cores! That said, however, there's still substantial increase when moving MPCHC window to a different monitor. Increase happens on one core only so there's still something lurking in the code. But generally for 720p here I can even move the window and still have good CPU rates.


That is still pales in comparison to the CPU usage. What did you do?!!! It now runs on primary monitor with just half of the previous CPU load!!!
Using lanczos4&softcubic50 I can achieve just less than 20% cpu typical usage. That is on 720p avc content slightly downscaled (so shader math still works).
It is indeed too early to compare HR and mVR directly, as mVR doesnt' do subs yet, but I expect it to be on par regarding CPU usage. So unsubbed 720p content seems to take about same CPU amount. And that with HR using bicubic and mVR using lanc4 & softcubic.

Now of course the bugs :)))

a. Chroma upscaling setting is not remembered.
b. Ugly when moving window around, video is flickering ( blank black area clearly seen and then video).
c. Even more annoying -- in fullscreen mode it flickers (again showing blank black frame and then back to video) when moving cursor to the control bar below.
It flickers twice -- first when opening the bar and when closing it.
d. Each change of upscale method leads to quite serious amount of dropped frames. Chroma and the other luma upscaling methods typically cause 3-5 frames loss, whilst active method change may, seemingly randomly, cause a loss between 10 and (record value) 40 frames. These values are from same video (i.e. even on same video the number of dropped frames is unpredictable). And yes, you got it right -- even if luma downscaling is used, when I change chroma upscale method it still drops several frames.

Other than that, still wonderful achievement! Personally, only feature that prevents me to switch over to mVR from HR is the subs ;)

[cyberbeing]

It is indeed too early to compare HR and mVR directly, as mVR doesnt' do subs yet, but I expect it to be on par regarding CPU usage.

Which subtitle renderer(s) aren't working with madVR?

Why don't you use VSFilter? It works perfectly with every madVR revision.

[Egh]

Which subtitle renderer(s) aren't working with madVR?

Why don't you use VSFilter? It works perfectly with every madVR revision.

MPC sub renderer is the best :) Especially if you upscale video on playback.

As for internal subtitle mechanics, I'm not sure. Renderers (such as Haali's one) have a subtitle pin. As MPC renders in some user selected resolution (I personally use 1280x1024), I guess it is renderer's job to up/down scale the subtitle texture and blend it with the video. Using some filter in-between is a flexible but not optimal approach, imo.

[Mark_A_W]

I think I have found a bug.

I'm using Zoomplayer and when running MadVR my monitors turn off (screensaver settings). When running any other renderer all is well.


Can anyone else verify this?

[Thunderbolt8]

What player Thunderbolt?mpc-hc

[madshi]

how do you open the detailed osd in 0.10? ctrl+j twice doesnt seem to do it any more.
There is only one OSD in 0.10.

also going a bit off topic but how should the dynamic range be set on nvidia hardware full(0-255) or limited (16-235)? either seems to result in a differant image with madvr and HR compared to evr custom
about the nvidia question i asked changing from rgb to YCbCr444 fixes it
If you do that, the graphics card will apply processing on madVR's output, which is what we usually don't want. Furthermore, if the image looks different that way, your GPU is probably doing something wrong. Cause madVR's output is how it's supposed to look. I'd guess that your EVR Custom image quality is all wrong. However, there's a chance, albeit very low, that your display doesn't handle RGB input correctly and needs YCbCr input. But I really doubt that's the case...

Tested it again on the Iron Man BD w/ the 4770, refresh rate was correctly detected at 60.00071 Hz (and stayed there for the whole 250s I tested), decoder queue 16/16 fixed, upload queue 4/8 fixed, render queue 8/8 fixed, 10 dropped frames, 2 delayed, all during first few seconds. Playback "feels" almost perfectly smooth, the very tiny stuttering could also be the effect of 23.976@60Hz playback. Feels definitely as smooth as the best iteration of Beliyaal's EVR CP.
Good to hear. For me EVR CP is not perfectly smooth, either. I guess my PC is just not up to the task in windowed mode. But the good thing is that on my PC madVR seems to be as smooth as EVR CP now, too, just like on your PC.

One tiny request: Could you make the OSD position toggle between the top and bottom? Might come in handy for us plasma users. ;)
Maybe later. There are so many very important things that still need to be done. So I don't really want to spend time on doing things like moveable OSD right now when more important things are still on the to do list...

Madshi, this new version, well...


YEA HAR!!


display 95.90368Hz (397s) perfect, time just keeps growing
movie fps 23.976fps (says source filter)
decoder queue 16/16
upload queue 4/8
render queue 8/8
movie res 1920,1080
target rectangle 0,0,1920,1080
v sync interval 10.43ms
movie frame interval 41.71ms
dropped frames 3 Just from startup, stable after that
delayed frames 3 Just from startup, stable after that

Playback is smooth, so far.
:)

Was it the interlaced res that causes the scanline reporting issue?
I don't think so. madVR asks the GPU about which scanline is currently being drawn. The allowed numbers (according to Microsoft documentation) are between 0 and the height of the graphics mode you're using. So if your GPU is set to 1080p, your GPU may return scanline numbers between 0 and 1080. However, I got scanlines reported like 1116. That confused my display refresh rate calculation formulas. This looks like a simple bug in the graphics driver to me.

A small feature request: A tearing/smoothness test. Using Zoomplayer, with Reclock "bypassed", I have no tearing bar test, which is very handy for checking issues.
Yeah, would make sense. But just as the moveable OSD position I have to say that there are simply more important things that need to be done first.

And that raises the Reclock issue...are you using Reclock? If so, what settings? Active or bypassed? If not, will Reclock bypassed, just a WASAPI renderer, cause any issues? It doesn't seem to.
Currently I'm not using ReClock, but I might use it soon due to WASAPI rendering.

I'm slightly concerned about the need for Fullscreen Exclusive for "perfect" playback. I understand why (I think), but it's a bit clunky - and there goes the UI on Zoomplayer.
Well, if you have perfectly smooth playback in windowed mode then just use that. Maybe faster PCs can do that.

just to nitpick, does it have to be 0.10 or 1.0? 10 comes after 9, yes, but just from the looks after 0.9 I'd expect to get 1.0. I'd rather say that 0.10 follows after 0.09 :P
I thought about going 1.0. After all smooth playback is a BIG thing. But 1.0 is supposed to be a stable build where all important features are implemented - and madVR is not there yet. So I decided to go 0.10. Yeah, so I should have started with 0.01. Well, there are more important things than version numbers... ;)

Refresh rate is correct. Upload queue is ~4-5/8. Render queue is ~7-8/8. But I can't get any smooth playback if my setting is anything beyond Bilinear/Bilinear when go fullscreen (2560x1600). Drop and delayed frame also keep on incresing. Maybe I did something wrong?
I don't think you did anything wrong. I'm not totally sure why some PCs seemingly can do smooth playback without any hiccups in windowed mode while other PCs can't. On my PC my logs are telling me that sometimes the PC is busy doing "something" (I don't know what) and so madVR is not getting any processing time for sometimes 30ms at a time. In such a situation there's no way to avoid a delayed or even dropped frame. Probably it's the same cause for you. You could try minimizing the amount of processes and services running on your PC that might interfere. Maybe that helps. You could also try reducing that output resolution a bit. 2560x1600 is quite taxing on the hardware, of course. Although your upload and render queues do look fine, so your GPU seems to be up to the task... I can only hope that fullscreen exclusive mode will fix the remaining non-smooth problems on your PC - and mine. Although I'll get a new HTPC early next week. So maybe my problems will be gone by then...

It seems much smoother now, which is good, but it's unstable. I've had at least 10 random lockups of the renderer in the last hour, when doing things like pausing, seeking, and going from fullscreen <-> windowed. If you don't mess with it, it seems fine though.
Yeah, exactly what I wrote in the release notes... ;)

Of course I could have waited with releasing madVR 0.10 until it's completely stable. But that would have meant that you guys would have had to wait another 1-2 weeks.

Pausing the video and going to fullscreen seems to lockup the renderer every time. It goes to fullscreen with the screen black, displays what I assume was in the frame cache, the screen goes black again, and the renderer locks-up.

There is a randomly occurring issue when it get the end of the file. Sometimes it will exit fullscreen, display a black frame, and then playback the last half-second (emptying the frame cache?).

Moving the video window around with MPC-HC results in massive flickering and tearing.
Ok, thanks, will look into that (next week).

For some reason I occasionally get delayed frames (the render queue fluxuates between 7/8 and 8/8) when I downscale a 1920x1080 video to 1600x900 (1600x1200 display res). When upscaling, I don't have this problem.
The render queue fluctuating between 7/8 and 8/8 is perfectly fine. It may go down to 4/8 without having to worry. Lower values than 4/8 might be dangerous for smooth motion, though. And of course the "delayed frames" number in the OSD increasing throughout the whole movie is bad.

It's also not remembering luma scaling settings
Ouch, true.

Epically superior build!!!!
:)

Believe it or nuts, but you [almost] solved the secondary monitor problem! Now it doesn't max one of the cores, keeps it at half (i.e. tends to be around 50%) on one of the cores! That said, however, there's still substantial increase when moving MPCHC window to a different monitor. Increase happens on one core only so there's still something lurking in the code. But generally for 720p here I can even move the window and still have good CPU rates.
Moving the window to another monitor while the playback is already running is not supported yet. Currently in order to get the best results you have to move MPC HC to the right monitor first and only then load the movie file and start playback.

That is still pales in comparison to the CPU usage. What did you do?!!! It now runs on primary monitor with just half of the previous CPU load!!!
Using lanczos4&softcubic50 I can achieve just less than 20% cpu typical usage. That is on 720p avc content slightly downscaled (so shader math still works).
It is indeed too early to compare HR and mVR directly, as mVR doesnt' do subs yet, but I expect it to be on par regarding CPU usage.
Yeah. Seems like redoing the presentation logic did the trick with CPU usage. I always said that madVR was not supposed to consume (much) more CPU than the other renderers. For me madVR 0.10 consumes slightly more than EVR-CP, but really only slightly more. CPU consumption got down quite a bit compared to 0.9. Maybe I should have added that to the changelog... :)

a. Chroma upscaling setting is not remembered.
b. Ugly when moving window around, video is flickering ( blank black area clearly seen and then video).
c. Even more annoying -- in fullscreen mode it flickers (again showing blank black frame and then back to video) when moving cursor to the control bar below.
It flickers twice -- first when opening the bar and when closing it.
Yeah, that are all things I need to work on.

d. Each change of upscale method leads to quite serious amount of dropped frames.
Not nice. But I don't really know if I will spend much time to improve that. After all you usually won't change these settings in the middle of watching a movie. One of the reasons for the dropped/delayed frames when changing settings is that madVR clears the rendering queue to make sure that the changed settings show effect immediately.

I'm using Zoomplayer and when running MadVR my monitors turn off (screensaver settings). When running any other renderer all is well.
So basically I need to stop screensavers from appearing, right?

[Hypernova]

After more observation. It looks like nothing can be done except getting a new card :(. If I restrict the video size to 1080p, then I can get smooth playback up to SoftCubic, but not Lanczos/Spline. Upload/render quite always looks ok (5/8 8/8) even if I use Lanczos/Spline on fullscreen(2560x1600), but it skip like crazy. This sounds like a useless report (even to me) but I do want to let you know that it does not show any improvement over other revision. The upside of this revision is that I can't distinguish the result of each scaling method (except nearest neighbor) for some reasons.

Anyway, I can live with Bilinear for now. Great job Madshi :D. I'm looking forward to subtitle support too.

EDIT: I was typing when you post. I'll definitely try what you suggest and report back on any improvement.