madVR - high quality video renderer (GPU assisted)

[dansrfe]

madshi,

Basically the problem is that

1) I have a 25 fps music video that was shot at 25 fps (true 25p)

2) This means that ReClock is useless for clocking the audio down from 25 fps to 24 fps because stretching it would make it sound too slow and changing the pitch would make it sound too deep. Basically I "correct" nothing by using ReClock in the above manner.

For this reason having madVR look for 24p refresh rate multiples is counterproductive and instead, in this particular case, I need madVR to switch to a 25p multiple refresh rate which in my case would be 50 Hz.

That effectively means that the "treat 25p movies as 24p (requires Reclock)" option needs to be disabled for these types of true 25p files. The file I'm talking about in this case is progressive so it doesn't really have anything to do with deinterlacing being on/off.

[madshi]

madVR v0.85.4 released

http://madshi.net/madVR.zip

* fixed: crash in certain situations when using native DXVA decoding
* fixed: native DXVA decoding sometimes produced wrong colors
* fixed: DXVA scaling sometimes produced wrong colors (old FSE mode)
* fixed: deinterlacing was always turned off with internal decoders
* fixed: frame stepping didn't work well with internal decoders
* added experimental option to "use a separate device for DXVA processing"
* added "trade quality" option "use half frame rate for DXVA deinterlacing"
* added "trade quality" option "store custom pixel shaders in 16bit buffer..."
* added "trade quality" option "run custom pixel shaders in video levels..."
* removed old tagging solution
* added tag "matrix=709|601|NTSC|PAL|YCgCo|240M"
* added tag "primaries=709|SmpteC|EBU|sRGB|NTSC|PAL|470M|240M|170M"
* added tag "levels=PC|TV|fullrange|limited|doubleExp|tripleExp"
* added tag "deint=On|Off|Video|Film"
* added tag "blacklevel=%value%", value range [-50, +50]
* added tag "whitelevel=%value%", value range [-50, +50]
* added tag "contrast=%value%", value range [-100, +100]
* added tag "brightness=%value%", value range [-100, +100]
* added tag "saturation=%value%", value range [-100, +100]
* added tag "hue=%value%", value range [-180, +180]
* added tag "frameRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
* added tag "refreshRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
* not-yet DXVA-deinterlaced frames are now never dropped, anymore
* video must now be >1050 wide or >576 high to be guessed as HD (ITU)
* changed order of "source levels" toggle
I hope that DXVA decoding, DXVA scaling and DXVA deinterlacing are now finally stable and working well with correct colors on all GPUs and all OSs. If not, please let me know.

This is probably the final v0.85.x build. At least there are not going to be any changes/improvements, anymore. Only bugfixes now. The next version with more than bugfixes (v0.86.0) will probably not come before 2013.

I've added an experimental option named "use a separate device for DXVA processing". On my PCs activating this option doesn't seem to make much of a difference. But since I spent the time implementing it I thought I'd give you guys the chance to play with it before I remove it again. If anybody finds this option to help significantly, please let me know. Otherwise I'm going to remove it again in the next bigger version update.

I've been asked to write up the current state of DXVA2. So here you go:

-------

DXVA2 Scaling:

When activated, madVR asks DXVA2 to take the original YCbCr 4:2:0 video frames and convert them to RGB and scale them to the target resolution. Chroma upsampling and scaling is performed by the GPU (and thus quality depends on the GPU, the driver version and the OS). YCbCr -> RGB color conversion is still performed by madVR.

Intel offers a nice DXVA2 upscaling algorithm, which is somewhat comparable to madVR's Lanczos AR. Furthermore, the scaling seems to be performed by hardwired circuits, so using DXVA2 scaling doesn't consume shader power. However, Intel DXVA2 scaling is (with the current driver version) limited to 8bit RGB output, so some banding might be introduced. The Intel downscaling algorithm does not seem to have Anti-Ringing capability, so it's not as good as madVR's downscaling can be.

AMD seems to have some sort of Lanczos AR algorithm for upscaling, too, but the AR algorithm seems to be overzealous, which means that it looks great on test patterns, but not as good as madVR's algorithms on real life content. NVidia seems to use some sort of Bilinear upscaling, followed by a sharpening algorithm (this is just a guess, though). Both AMD and NVidia algorithms seem to run on pixel shader hardware.

DXVA2 Decoding + Deinterlacing:

This section only applies when DXVA2 Scaling is *off*.

madVR tries to get "lossless" access to the DXVA2 Decoder/Deinterlacer output. This is actually quite difficult, as weird as it sounds. For AMD GPUs madVR manages to do that by running some funny conversions on the GPU. Unfortunately that doesn't work for NVidia and Intel.

For NVidia and Intel GPUs madVR uses "copyback". Basically the DXVA2 output is read from GPU RAM by the CPU, and then immediately written back to GPU RAM by the CPU in a different format. This approach costs some performance, but it allows lossless access to the DXVA2 output. This "copyback" approach is only used if your CPU supports SSE 4.1, though, because without SSE 4.1 the whole approach would be very inefficient/slow. So for older CPUs, madVR runs some conversion routines on the GPU. Unfortunately, for NVidia and Intel GPUs, this conversion is not totally lossless: The chroma channels get slightly blurred.

In a future version I might find better ways for NVidia and Intel GPUs to get lossless access to the DXVA2 output. E.g. for NVidia maybe CUDA could help. But the current CUDA version doesn't support the features I would need for that. For Intel OpenCL could help. But if that works out, it will be limited to Ivy Bridge (and newer) and to Windows 7 (and newer).

[Superb]

You're missing the .4 in the comment above me...
Thanks for the new release.

EDIT: also, the changelog in the first post should be updated...

EDIT 2: I've noticed that H.264 decoding gives preference to LAV Video. Is this intended? It wasn't like this pre 0.85.x. I always had to go to the "decoding" tab in madVR and turn off H.264 decoding.

[madshi]

Basically the problem is that

1) I have a 25 fps music video that was shot at 25 fps (true 25p)

2) This means that ReClock is useless for clocking the audio down from 25 fps to 24 fps because stretching it would make it sound too slow and changing the pitch would make it sound too deep. Basically I "correct" nothing by using ReClock in the above manner.

For this reason having madVR look for 24p refresh rate multiples is counterproductive and instead, in this particular case, I need madVR to switch to a 25p multiple refresh rate which in my case would be 50 Hz.

That effectively means that the "treat 25p movies as 24p (requires Reclock)" option needs to be disabled for these types of true 25p files. The file I'm talking about in this case is progressive so it doesn't really have anything to do with deinterlacing being on/off.
Well, how is madVR supposed to know for which files you want it to "treat 25p movies as 24p" and for which you don't? I don't think there's any way for madVR to know. It might be a music concert, but to madVR it looks like a movie.

You could try adding a "refreshRate=50" tag. Maybe that helps? Not sure, depends on in which order the tags and the "treat 25p movies as 24p" option are evaluated. Don't know from the top of my head...

You're missing the .4 in the comment above me...
Fixed.

EDIT: also, the changelog in the first post should be updated...
That list is supposed to show the most important changes of all v0.85.x versions combined.

EDIT 2: I've noticed that H.264 decoding gives preference to LAV Video. Is this intended? It wasn't like this pre 0.85.x. I always had to go to the "decoding" tab in madVR and turn off H.264 decoding.
I haven't really changed anything about that. Maybe LAV (or your media player) has changed something? I don't know...

[nevcairiel]

Did you ever test if using LAV in CUVID mode for DI also introduces the chroma blur you talk about?

[Prinz]

I've added an experimental option named "use a separate device for DXVA processing". On my PCs activating this option doesn't seem to make much of a difference.

BIG difference here. The playback is now perfect with this option activated. Without it the I have still frames for up to 4 seconds at the beginning and dropped frames later if I downscale 1080p. So please don't remove the option.

[madshi]

Did you ever test if using LAV in CUVID mode for DI also introduces the chroma blur you talk about?
No, I didn't test that. But the chroma blur I'm talking about only occurs when letting the GPU convert the frames to RGB. I don't think CUVID in DI mode does that? So I don't think it should show chroma blur.

BIG difference here. The playback is now perfect with this option activated. Without it the I have still frames for up to 4 seconds at the beginning and dropped frames later if I downscale 1080p. So please don't remove the option.
That's interesting. I suppose you don't have the problems like still frames and dropped frames with EVR?

So does the experimental option work fine for you? No negative side effects?

[nevcairiel]

But the chroma blur I'm talking about only occurs when letting the GPU convert the frames to RGB.

CUVID doesn't do that, but it still happens when you DI in madVR? Where is the RGB conversion there?

[Prinz]

That's interesting. I suppose you don't have the problems like still frames and dropped frames with EVR?

EVR worked always without the problems that madVR had before this option.

So does the experimental option would fine for you? No negative side effects?

Only positive. Now it works just like EVR always did.

[madshi]

CUVID doesn't do that, but it still happens when you DI in madVR? Where is the RGB conversion there?
The Direct3D rendering pipeline can't handle NV12 surfaces. There's no "IDirect3DDevice::SetSurface()" for rendering, there's only an "IDirect3DDevice::SetTexture()". And none of today's GPUs supports NV12 textures. So the only way to make DXVA NV12 surfaces available to the D3D rendering pipeline is to convert them to RGB textures first. And that conversion is only possible on the GPU by using GPU conversion algorithms (StretchRect or VideoProcessBlt). Ouch.

[aufkrawall]

No apparent problems for me with 0.85.4 on Intel HD 3000.
DXVA works nicely, both in windowed and FSE mode, also scaling.
Very well.

Btw: With 9.17.10.2897 driver I can now use Jinc3 AR chroma upscaling without any dropped frames etc., even at 4k.
Isn't this quite remarkable?
Edit: Opps, there's something in my mind regarding DXVA chroma scaling if luma scaling is chosen.
Will need to read your explanation again.


Also crashes with FSE and display mode change seem to be gone. :)

Will test it later on an AMD Fusion. Previous madVR version was unusable with it due to problems with DXVA.

[madshi]

EVR worked always without the problems that madVR had before this option.
Hmmmm... I've just had an idea. I could probably add a different new "flush & wait" option which could eventually help reducing the DXVA problems. What happens if you change the "flush & wait" to just "flush"? Does that fix the DXVA problems without having to use the new experimental option? There might be different problems without "flush & wait", though, not sure. Sometimes the "wait" seems to be necessary. But the current "wait" might be in some conflict with DXVA, I could imagine...

No apparent problems for me with 0.85.4 on Intel HD 3000.
DXVA works nicely, both in windowed and FSE mode, also scaling.

[...]

Also crashes with FSE and display mode change seem to be gone.
Good to hear.

[leeperry]

OMG, :thanks: for the new build that supports matrix/levels(even 2X/3X) filename tags :eek:

why no tag for AR if you don't mind me asking? so we could finally nail down the ITU matter and I could force my non-ITU compliant 720x576 SD files to 4:3 :devil:

It would also appear that I might have a question about how you process post-scaling PS scripts, but I'll come back with numerous screenshots to make my point ^^

[Prinz]

Hmmmm... I've just had an idea. I could probably add a different new "flush & wait" option which could eventually help reducing the DXVA problems. What happens if you change the "flush & wait" to just "flush"? Does that fix the DXVA problems without having to use the new experimental option? There might be different problems without "flush & wait", though, not sure. Sometimes the "wait" seems to be necessary. But the current "wait" might be in some conflict with DXVA, I could imagine...

I don't have anything set to flush & wait.

don't flush
flush
flush
don't flush

for both windowed and exclusive mode.

[Motenai Yoda]

what's meaning of the display value?
it seems to show display frequency, but if it is, then is wrong, cause showed the value is display frequency * ~ 0.894 (~89.45% of effective frequency)...

edit:: my bad, updating mpc-hc to the lastest stable it shows correctly.

[aufkrawall]

Funny: DXVA CB works better for me with 4k on my GTX 670 than native: With the latter one I get lots of dropped frames, with CB not.
I think this was different with earlier madVR DXVA builds.

[nevcairiel]

Funny: DXVA CB works better for me with 4k on my GTX 670 than native: With the latter one I get lots of dropped frames, with CB not.
I think this was different with earlier madVR DXVA builds.

I always had this issue, DXVA Native with madVR always seemed to have performance issues on 4K content on my NVIDIA system.

[aufkrawall]

I always had this issue, DXVA Native with madVR always seemed to have performance issues on 4K content on my NVIDIA system.
GK104 is too slow. :(
I suppose a Radeon 7970 @1.2Ghz should perform much better.

[madshi]

why no tag for AR if you don't mind me asking?
Because that is more difficult to implement, due to internal timing issues. It's on my to do list for a future version, but I don't know when it will come.

I don't have anything set to flush & wait.

don't flush
flush
flush
don't flush

for both windowed and exclusive mode.
Interesting. But I suppose you're using the "use a separate device for presentation"? In that case madVR *has* to do a "flush & wait" after the last render step, no way around it, so it's done automatically, even if your flush settings disagree. So what happens if you disable "use a separate device for presentation" with your current flush settings? Is the new experimental DXVA option still necessary then?

Funny: DXVA CB works better for me with 4k on my GTX 670 than native: With the latter one I get lots of dropped frames, with CB not.
I think this was different with earlier madVR DXVA builds.
I always had this issue, DXVA Native with madVR always seemed to have performance issues on 4K content on my NVIDIA system.
Do you guys have SSE 4.1 capable CPUs? Unfortunately my current NVidia GPU can't decode 4K, so I can't test that here... :(

[dansrfe]

Would it be possible to add an enable/disable the "treat 25p as 24p" option in the user interface menu? That would solve the problem for me :)

Thanks for the new version!

[nevcairiel]

Do you guys have SSE 4.1 capable CPUs? Unfortunately my current NVidia GPU can't decode 4K, so I can't test that here... :(

Of course, but i did the initial tests before you had that copy-back hackery. Native was performing horrible on 4K, i believe i also mentioned that in a PM once. :p

[aufkrawall]

Do you guys have SSE 4.1 capable CPUs? Unfortunately my current NVidia GPU can't decode 4K, so I can't test that here... :(
Yup, CPU shouldn't be the problem.
Unfortunately, the GPU load is a little too high, partially almost hits the 100% (at least with downscaling to 720p :D ).
With less demanding scaling it works well for me.

But somehow native DXVA has a bigger impact than CB.

[madshi]

Would it be possible to add an enable/disable the "treat 25p as 24p" option in the user interface menu?
What user interface menu do you mean?

Of course, but i did the initial tests before you had that copy-back hackery. Native was performing horrible on 4K, i believe i also mentioned that in a PM once. :p
Hmmmm... This is really confusing to me. If both my "old" and my "copyback" solutions are not working, but LAV Copyback runs smoothly, then I simply don't understand what's going on. Guess I'll have to get a 4K capable NVidia GPU. Which 4K video are you testing this with?

[aufkrawall]

Just some light stuff from Youtube, e.g.:
http://www.youtube.com/watch?v=DD_YOvNUVc4

[madshi]

P.S: Can you two "4K guys" :) please double check with the new option "use a separate device for DXVA processing" turned on? Does that make native 4K DXVA work fluidly with madVR?

[Prinz]

Interesting. But I suppose you're using the "use a separate device for presentation"?

yes.

So what happens if you disable "use a separate device for presentation" with your current flush settings? Is the new experimental DXVA option still necessary then?

With that combination (both options disabled) it works also.

But one strange thing is happing in both cases, if I decode a 1080p file it drops frames (1 per second) if not scaled, if I downscale it it doesn't drop frames.

I will still use software decode, that works without any problems for years now.

[aufkrawall]

P.S: Can you two "4K guys" :) please double check with the new option "use a separate device for DXVA processing" turned on? Does that make native 4K DXVA work fluidly with madVR?
This reduces the dropped frames a lot, but there are still some.
With CB in LAV there aren't any.

[madshi]

With that combination (both options disabled) it works also.
That's good to know. It means that the "wait" in "flush & wait" is probably responsible for the DXVA problems, at least in your case...

But one strange thing is happing in both cases, if I decode a 1080p file it drops frames (1 per second) if not scaled, if I downscale it it doesn't drop frames.
Interesting. What do the queues say? Are they full when the frame drops occur? Or are they filled? Are they filled when downscaling?

I will still use software decode, that works without any problems for years now.
I'll also continue to use software decoding, but of course I need to make hardware decoding work as well as possible for those that need/want to use it.

[madshi]

This reduces the dropped frames a lot, but there are still some.
With CB in LAV there aren't any.
Quite interesting... Which queue is empty when the frame drops appear?

[aufkrawall]

Quite interesting... Which queue is empty when the frame drops appear?
Present queue, e.g. 0-3 / 16

[Prinz]

Interesting. What do the queues say? Are they full when the frame drops occur? Or are they filled?

not filled.

exclusive mode:
render query 1-5/8 and present query 0-7/12

windowed mode:
render query 1-4/8 and backbuffer query 0-3/8

and worse. Something is too slow to fill them without downscaling.

Are they filled when downscaling?

When downscaled they are filled.


And I have plans to upgrade to a Geforce gtx 660 in next few months... The problem should be gone after the upgrade.

[nevcairiel]

Doesn't look like i can reproduce the issues anymore with 4K, i can even run Jinc3+AR Chroma and Lanczos 8-tap+AR+Linear Light (for perf testing only) downscaling on my 680 (admittedly, thats a strong card) - although rendering times are up to nearly 40ms. Moving to Jinc4 for chroma does move it over the edge though and drops a lot of frames (unless i dial image downscaling back to say Catmull-Rom)
A quick look at GPU load and CPU load also has the two at around the same levels.

[madshi]

Present queue, e.g. 0-3 / 16
But the render queue is filled?

Something is too slow to fill them without downscaling.
You don't have DXVA2 scaling selected for downscaling, have you?

Doesn't look like i can reproduce the issues anymore with 4K, i can even run Jinc3+AR Chroma and Lanczos 8-tap+AR+Linear Light (for perf testing only) downscaling on my 680 (admittedly, thats a strong card) - although rendering times are up to nearly 40ms. Moving to Jinc4 for chroma does move it over the edge though and drops a lot of frames (unless i dial image downscaling back to say Catmull-Rom)
A quick look at GPU load and CPU load also has the two at around the same levels.
Interesting. Can you notice any differences between using native DXVA2 decoding and LAV copyback DXVA2 decoding?

[Prinz]

You don't have DXVA2 scaling selected for downscaling, have you?

No. All Bilinear.

[aufkrawall]

But the render queue is filled?

Yep, mostly something like 1-3 / 8. Never 0.

[madshi]

@Prinz, just to make sure: What happens if you use LAV Copyback DXVA2? Do you then get fluid playback without downscaling?

Also, could you please test this special test build:

http://madshi.net/madVR854b.rar

Please enable "use separate device for presentation" again (so you get back to your original settings). Then please check whether with this special test build activating the experimental option "use separate device for DXVA processing" is still necessary. I hope that it's no longer necessary to achieve similar results to EVR now, with the test build. But I'm not sure...

Yep, mostly something like 1-3 / 8. Never 0.
1-3/8 is pretty much empty, too. Could you please list all your queue numbers when the frame drops occur? And please also list the queue numbers when you get smooth playback with LAV copyback. Would be great if you could double check with the new madVR test build (link see above).

[dansrfe]

Sorry, should have clarified. :o The user interface keyboard shortcuts menu. Just an entry to enable/disable the treat 25p as 24p option via a custom keyboard shortcut would be awesome.

[Prinz]

@Prinz, just to make sure: What happens if you use LAV Copyback DXVA2? Do you then get fluid playback without downscaling?

CB is unusable on my ATI 2600. I get maybe 1 frame per 2-3 seconds with 1080p. :scared:

Also, could you please test this special test build:

http://madshi.net/madVR854b.rar

Please enable "use separate device for presentation" again (so you get back to your original settings). Then please check whether with this special test build activating the experimental option "use separate device for DXVA processing" is still necessary. I hope that it's no longer necessary to achieve similar results to EVR now, with the test build. But I'm not sure...

Much worse. If I activate the "use separate device for presentation" with that version I get at least 5-10 framedrops per second even when downscaled.

[pankov]

madshi,
can you give a couple of examples for using tags in the file name just to use them as guidelines?
What separators are allowed between the tags? (especially having in mind that you support both 23 and 23.976)
Should/Could these tags be put in brackets (MyMovieName [deint=On].mts)?

[aufkrawall]

1-3/8 is pretty much empty, too. Could you please list all your queue numbers when the frame drops occur? And please also list the queue numbers when you get smooth playback with LAV copyback. Would be great if you could double check with the new madVR test build (link see above).
With the new build and separate device for DXVA, the recorded dropped frames are gone.
But unfortunately the video doesn't play right then, some weird kind of extreme stuttering/flickering occurs (looks like it always repeats some previous frames).

Now, framedrops with non test build, DXVA device enabled, native DXVA:
http://www.abload.de/thumb/mpc-hc2012-12-1722-06x6ufd.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-06x6ufd.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-06ufue3.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-06ufue3.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-068mux5.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-068mux5.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-04aqu7l.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-04aqu7l.jpg)

DXVA2CB:
http://www.abload.de/thumb/mpc-hc2012-12-1722-08bhufe.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-08bhufe.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-081hut8.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-081hut8.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-07hnu17.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-07hnu17.jpg) http://www.abload.de/thumb/mpc-hc2012-12-1722-08svulg.jpg (http://www.abload.de/image.php?img=mpc-hc2012-12-1722-08svulg.jpg)

[madshi]

Sorry, should have clarified. :o The user interface keyboard shortcuts menu. Just an entry to enable/disable the treat 25p as 24p option via a custom keyboard shortcut would be awesome.
Ah, I see. Sorry, please ask again when madVR v1.0 is released. Maybe then. For now I don't consider this important enough to make my to do list. The demand for this feature seems to be pretty low (you're the only one who's ever asked for that).

CB is unusable on my ATI 2600. I get maybe 1 frame per 2-3 seconds with 1080p. :scared:
Ok. Now I wonder: Do you get fluid playback with EVR without downscaling?

Much worse. If I activate the "use separate device for presentation" with that version I get at least 5-10 framedrops per second even when downscaled.
Ok, too bad.

can you give a couple of examples for using tags in the file name just to use them as guidelines?
What separators are allowed between the tags? (especially having in mind that you support both 23 and 23.976)
Should/Could these tags be put in brackets (MyMovieName [deint=On].mts)?
Brackets are allowed, but not necessary. I've tried to make it as flexible as reasonably possible. So just give it a try. Enter the tags in the way you find intuitive and if it doesn't work that way, complain.

With the new build and separate device for DXVA, the recorded dropped frames are gone.
But unfortunately the video doesn't play right then, some weird kind of extreme stuttering/flickering occurs (looks like it always repeats some previous frames).
Ok. So I guess we should forget about the test build... :(

Now, framedrops with non test build, DXVA device enabled, native DXVA

DXVA2CB
Thanks!!

So it seems the key problem is that the render queue isn't filled when using native DXVA decoding - although the render times look just fine. I'm not sure why that happens. Could you create a debug log, which shows the frame drops (let it run maybe 30 seconds or so)? Thanks!

[secvensor]

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

OK
I repost it :)

[Prinz]

Ok. Now I wonder: Do you get fluid playback with EVR without downscaling?

Yes. With the same files 1080p in Full-Screen (without scaling) I get no frame drops with SyncRenderer in MPC-HC. I only get frame drops directly after seeking which is probably normal.

[aufkrawall]

So it seems the key problem is that the render queue isn't filled when using native DXVA decoding - although the render times look just fine. I'm not sure why that happens. Could you create a debug log, which shows the frame drops (let it run maybe 30 seconds or so)? Thanks!
External DXVA device enabled:
http://www.mediafire.com/?54skt8lruuijmr3

Disabled:
http://www.mediafire.com/?wooaar2u30w1978

Hope it helps. :)

[leeperry]

Because that is more difficult to implement, due to internal timing issues. It's on my to do list for a future version, but I don't know when it will come.
OK, no worries! I'll create an automatic PotP profile that will force a 4:3 DAR on those pesky files for the time being http://forum.slysoft.com/images/smilies/agreed.gif

BTW, build 34821 of PotP was processing post-scaling PS scripts with EVR as pre-scaling, as shown here (http://forum.doom9.org/showpost.php?p=1605134&postcount=16198).

Build 34860 fixes this problem with EVR, but the "DisplayLessThan16" script(written by Seb.26) that turns every <16 pixel to green shows that as much as EVR applies it onto the black bars, mVR does not:

http://thumbnails108.imagebam.com/22645/362a4d226449457.jpg (http://www.imagebam.com/image/362a4d226449457) http://thumbnails105.imagebam.com/22645/866dfc226449459.jpg (http://www.imagebam.com/image/866dfc226449459)

Here's the script:
// DisplayLessThan16 v1.1=ps_3_0
// http://www.homecinema-fr.com/forum/viewtopic.php?t=29814317

sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

#define width (p0[0])
#define height (p0[1])
#define counter (p0[2])
#define clock (p0[3])
#define one_over_width (p1[0])
#define one_over_height (p1[1])

#define PI acos(-1)
#define Value_16 (16.0/255.0)

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);

if( c0[0]<Value_16 )
c0 = float4( 0, 1, 0, 0 );
else if( c0[1]<Value_16 )
c0 = float4( 0, 1, 0, 0 );
else if( c0[2]<Value_16 )
c0 = float4( 0, 1, 0, 0 );

return c0;
}
Is there any good reason why you wouldn't process post-scaling PS scripts onto the final full frame including letterboxing? IIRC, sharpening scripts can sometimes go haywire if you do but OTOH it's always been done like this with EVR in MPC-HC and that was a foolproof way to ensure that scripts are indeed processed after scaling. It might also come in handy for levels conversions, 3D effets, and what-not I think...possibly colorimetry as well if you have a really funky display with tinted blacks, or those psychedelic chroma effects JanWillem seems to enjoy so much http://forum-images.hardware.fr/images/perso/smoking.gif

http://thumbnails104.imagebam.com/22646/af9c39226450382.jpg (http://www.imagebam.com/image/af9c39226450382) http://thumbnails101.imagebam.com/22646/84e52e226450383.jpg (http://www.imagebam.com/image/84e52e226450383)

I'm very new to PS scripts but it would kinda make sense to me to apply post-scaling PS scripts onto the final full frame size(WYSIWYG)....but if for some reason I'm overlooking this would be a no-go, would you be so kind as to confirm that PotP 1.5.34860 really does apply post- and pre-scaling scripts as advertized? There doesn't seem to be any way for an end-user to check for this AFAICS :o

:thanks:

[crotecun]

I hope that DXVA decoding, DXVA scaling and DXVA deinterlacing are now finally stable and working well with correct colors on all GPUs and all OSs. If not, please let me know.



Starting from 0.85.2 until the current release of 0.85.4, image upscaling doesn't work for me when it is set to DXVA. The on-screen display says

madVR reports:
- dxva processing failed

I'm on Windows 7 64-bit and a Radeon HD 5670 video card.

Playback works fine as long as the window is smaller than the video's resolution. If I make it larger by expanding the window or going fullscreen, the video stops displaying but the audio is still playing in the background. The video resumes its animation as soon as I make the window smaller again.

Here's the log:

http://bayfiles.com/file/wrCD/vGiZJx/madVR_-_log_2012-12-18_mpc-hc.zip

I didn't notice it until now since I was using Jinc 3AR for upscaling, I only got to check DXVA again recently. >_<;;

[TheShadowRunner]

6233638 & madshi, a follow up on my color range issue, and a HUGE thanks to both of you.

First I just tried to crank up the TV brightness/contrast and even at max it barely allowed to see anything between 0-16 (the picture was so effed up it wouldn't have been usable anyway).

It seems, as you both hinted at, that the TV is set to receive 16-235 via HDMI and the problem was the nvidia driver somehow sending 0-255.

While for movies the issue was transparent (with madVR set to 16-235), indeed my destop was color-fucked (I thought it was normal behavior when connecting a PC to HDTV!)

So I decided to start from scratch with the new driver released today (WHQL 310.70); removed the old driver, deleted nvidia corp registry entries from HKCU/HKLM, removed old installation traces (HKLM\SYSTEM\CCSet\Control\Video\GUID) as well as old monitor traces (HKLM\SYSTEM\CCSet\Enum\Display) and thought I might as well try the new installation both _with_ and _without_ the spdif from my mobo connected to the videocard to see if it would make any difference. (my videocard has HDMI plug built-in and an input for spdif passthrough).

THAT'S WHEN I SAW IT.

When I got this card, it came with a DVI-to-VGA adapter and since I don't keep peripheral boxes, I hooked it up to the DVI output on the videocard not to lose it. It seems that was the source of the problem!
After I removed it and installed the new driver, indeed the card started sending what it was meant to (16-235) via HDMI, I could hardly believe it!
I immediately verified it, now on the destop I do see different shades of black between 0-16, and of course I do have to set madVR to 0-255 to have proper levels for video playback as well.
In other words, the issue is solved! [the driver is correctly compressing 0-255 to 16-235 my TV expects]

It's crazy that what I thought to be a screenshot issue with madVR turned out to be a totally different one in fact my system had.
So thank you very much to both of you for helping me understand there was something wrong and how it was meant to work!
While it doesn't change anything for movies, it sure does for everything else :D

madshi, I would have never wanted you to alter madVR only for me of course (force screenshots at 16-235) :P
It's just that being "screen grabs" of video sources, it made more sense to me the same color range as the source was used for them.
Sorry for this semi off-topic btw!

[asubert]

I just did the cms calibration using madvr ycms as my pj (jvc rs15) has no cms control. I have to say cie diagram is just perfect after that. It is just awsome how easy it is to get this done. Thanks for your work.
My only complain is that i have nothing else to tweak with this perfect picture. I just have to watch movie and enjoy. :-D

Envoyé depuis mon ASUS Transformer Pad TF300T avec Tapatalk

[ryrynz]

DXVA2 *up*scaling on Intel GPUs uses a pretty good algorithm which is somewhat similar to madVR's Lanczos AR. However, it's not as good as madVR's Jinc AR.

I compared it to Lanczos 3 AR some time ago and and it's not as good as that either, lines are jagged and a little broken up in comparison on my anime content so I couldn't recommend it for anyone concerned with quality.
It would be nice if Intel had options for it so the reins could be pulled back a bit.

There's still a slight pixel shift with DXVA enabled, is that okay/expected?

[turbojet]

Same pause issue with 85.4 log at http://www.sendspace.com/file/oo390s

I tried uninstalling then installing with no change but had to change first line of the batch files to get them to work
@cd /d "%~dp0"

Thanks for adding the file tags, esp matrix but this will require me to change 100's of file names. In a future version could there be 2 text field's in settings that users can set to use for 601 and 709 when the bitstream doesn't have the info? I've lived with wrong color matrix for years and it never bugged me until I found out how much of a difference there is and can tell most of the time when it's wrong.