madVR - high quality video renderer (GPU assisted)

[dansrfe]

Crash on close here as well with v0.75

[TheShadowRunner]

It seems pretty clear that the exit crash only occurs on 7.

[madshi]

I hate stupid C++. In Delphi accessing a two dimensional array can be done by writing "arr[0, 0]" or "arr[0][0]". In C++ the compiler also allows both, but I only get correct results when using "arr[0][0]". When using "arr[0,0]" in C++ I get very weird results. What a stupid compiler. This was causing the crash.

[madshi]

madVR v0.76 released

http://madshi.net/madVR.zip

* fixed: crash on MPC-HC exit / close file
* fixed: OSD didn't show properly or didn't show at all
* fixed: subtitles showed with a black background
* fixed: trade quality -> use 10bit chroma option was used for luma sometimes
* unfortunately subtitles are not running through 3dlut, anymore

It seems that older GPUs are not capable of performing alpha blending on 16bit (per component) textures. My ATI 6850 has no problem doing that, but my NVidia 9400 can't. As a consequence this means that subtitles drawn by the internal MPC-HC subtitle renderer can not run through the 3dlut. At least not when using 16bit textures and older GPUs. So we're back to square one on that one...

[HeadlessCow]

Originally Posted by madshi

I hate stupid C++. In Delphi accessing a two dimensional array can be done by writing "arr[0, 0]" or "arr[0][0]". In C++ the compiler also allows both, but I only get correct results when using "arr[0][0]". When using "arr[0,0]" in C++ I get very weird results. What a stupid compiler. This was causing the crash.

The comma operator in C++ just ignores the value on the left and returns the value on the right. arr[0,0] is the same as just writing arr[0].

[nand chan]

Originally Posted by madshi

madVR v0.76 released

http://madshi.net/madVR.zip

* fixed: crash on MPC-HC exit / close file
* fixed: OSD didn't show properly or didn't show at all
* fixed: subtitles showed with a black background
* fixed: trade quality -> use 10bit chroma option was used for luma sometimes
* unfortunately subtitles are not running through 3dlut, anymore

It seems that older GPUs are not capable of performing alpha blending on 16bit (per component) textures. My ATI 6850 has no problem doing that, but my NVidia 9400 can't. As a consequence this means that subtitles drawn by the internal MPC-HC subtitle renderer can not run through the 3dlut. At least not when using 16bit textures and older GPUs. So we're back to square one on that one...

Run them through the .3dlut separately on an 8-bit texture (round the .3dlut output down since dithering isn't enabled, doesn't matter as much for subtitles) and/or make the option opt-in so only those with modern GPUs can enable it. I doubt many users would care about color accurate subtitles other than me and a few other specialists, those may as well be forced to use a modern GPU.

Originally Posted by madshi

I hate stupid C++. In Delphi accessing a two dimensional array can be done by writing "arr[0, 0]" or "arr[0][0]". In C++ the compiler also allows both, but I only get correct results when using "arr[0][0]". When using "arr[0,0]" in C++ I get very weird results. What a stupid compiler. This was causing the crash.

(I've never had this problem in C#. What a silly language you are using)

[ikarad]

Originally Posted by madshi

madVR v0.76 released

http://madshi.net/madVR.zip

* fixed: crash on MPC-HC exit / close file
* fixed: OSD didn't show properly or didn't show at all
* fixed: subtitles showed with a black background
* fixed: trade quality -> use 10bit chroma option was used for luma sometimes
* unfortunately subtitles are not running through 3dlut, anymore

It seems that older GPUs are not capable of performing alpha blending on 16bit (per component) textures. My ATI 6850 has no problem doing that, but my NVidia 9400 can't. As a consequence this means that subtitles drawn by the internal MPC-HC subtitle renderer can not run through the 3dlut. At least not when using 16bit textures and older GPUs. So we're back to square one on that one...

Madshi Can we expect to add a deband filter and a TIVTC filter (like telecide filter) in madvr?

[nand chan]

Originally Posted by ikarad

Madshi Can we expect to add a deband filter and a TIVTC filter (like telecide filter) in madvr?

General support for HLSL (or assembly) pixel shaders would be much nicer imo, then we can add our own deband and deinterlacing filters without needing madshi to do so, and if they're good enough he can just seamlessly integrate them.

[madshi]

Originally Posted by HeadlessCow

The comma operator in C++ just ignores the value on the left and returns the value on the right. arr[0,0] is the same as just writing arr[0].

Ouch. How can a compiler treat arr[0,0] as arr[0]? That doesn't make *any* sense to me whatsoever.

Originally Posted by nand chan

Run them through the .3dlut separately

Can't. I don't even draw the subtitles myself. I just tell MPC-HC to draw them. I have to let MPC-HC draw them directly onto the video image, that's the only way it works with the ISR.

Originally Posted by nand chan

or make the option opt-in so only those with modern GPUs can enable it.

Yeah, something like that is probably the best workaround.

Originally Posted by nand chan

I've never had this problem in C#. What a silly language you are using

There's no such problem in Delphi, either. I don't like C++ at all. But it was the "best" choice for writing a video renderer.

Originally Posted by ikarad

Madshi Can we expect to add a deband filter and a TIVTC filter (like telecide filter) in madvr?

Maybe.

Originally Posted by nand chan

General support for HLSL (or assembly) pixel shaders would be much nicer imo, then we can add our own deband and deinterlacing filters without needing madshi to do so, and if they're good enough he can just seamlessly integrate them.

Yeah, support for external pixel shaders is on my to do list. Like so many other things.

[mr.duck]

Originally Posted by nand chan

General support for HLSL (or assembly) pixel shaders would be much nicer imo, then we can add our own deband and deinterlacing filters without needing madshi to do so, and if they're good enough he can just seamlessly integrate them.

Are there any 1/2 decent pixel shader based deinterlacers? The one in MPC HC, "Deinterlace (blend)", is junk.

[nand chan]

Originally Posted by madshi

Ouch. How can a compiler treat arr[0,0] as arr[0]? That doesn't make *any* sense to me whatsoever.

C++ doesn't make *any* sense whatsoever.

Can't. I don't even draw the subtitles myself. I just tell MPC-HC to draw them. I have to let MPC-HC draw them directly onto the video image, that's the only way it works with the ISR.

Allocate a new 8-bit texture then and have MPC-HC draw on it instead?

There's no such problem in Delphi, either. I don't like C++ at all. But it was the "best" choice for writing a video renderer.

Only because DirectShow is so horribly tied to C++. There are a number of projects attempting to port the headers + interop to other languages (eg. D, Go, C#) that don't require selling your soul to use. There's still hope for the future.

Have you considered just writing a wrapper to X back-end library written in Y language of choice, using C++?

Yeah, support for external pixel shaders is on my to do list. Like so many other things.

Well, it should be rather high priority - as it would replace a great deal of others. In fact, most of the gamma correction / color management can be done through pixel shaders. You can even do linear light rescaling and such using pixel shaders. Writing a decent pixel shader API just enables you to do so much, reducing the importance of all other feature requests afterwards. You can probably even deinterlace through pixel shaders.

Originally Posted by mr.duck

Are there any 1/2 decent pixel shader based deinterlacers? The one in MPC HC, "Deinterlace (blend)", is junk.

Write one according to your requirements. All you need is access to the current and previous frames. I don't think MPC-HC lets you have the previous frame but madVR certainly could if designed that way.

[madshi]

Originally Posted by nand chan

Allocate a new 8-bit texture then and have MPC-HC draw on it instead?

The ISR does not fill the target texture's alpha channel. So if I did as you suggest, after the subtitles are drawn, I would have no alpha channel I could use to blend the subtitles onto the real video image.

Originally Posted by nand chan

Only because DirectShow is so horribly tied to C++. There are a number of projects attempting to port the headers + interop to other languages (eg. D, Go, C#) that don't require selling your soul to use. There's still hope for the future.

madFlac is written in Delphi. However, writing a video renderer goes a lot deeper than writing a "simple" decoder. That's why I (reluctantly) chose C++ for the video renderer.

Originally Posted by nand chan

Have you considered just writing a wrapper to X back-end library written in Y language of choice, using C++?

There's a reason why madVR ships with many dlls and a madHcCtrl.exe. They're all written in Delphi. Only madVR.ax itself is written in C++.

Originally Posted by nand chan

Well, it should be rather high priority - as it would replace a great deal of others. In fact, most of the gamma correction / color management can be done through pixel shaders. You can even do linear light rescaling and such using pixel shaders. Writing a decent pixel shader API just enables you to do so much, reducing the importance of all other feature requests afterwards. You can probably even deinterlace through pixel shaders.

It's not as simple as it sounds. If you deinterlace video content properly, the video framerate doubles. If I allow external shaders to add new video frames to madVR's internal frame queues, things can become ugly fast. E.g. would such frames get into the "decoder queue"? Or would I have to add a new "deinterlacer queue"? (These are rhetorical questions). Supporting external scaling would be somewhat easier. Supporting simple processing with no framerate and resolution change would be rather easy in comparison.

Anyway, everybody has his own idea about which of the many things on my to do list should have which priority. In the end I will do things in the order that I consider best. Shader support is not at the very top of my priority list, but it's not too far down, either.

[nand chan]

Originally Posted by madshi

The ISR does not fill the target texture's alpha channel. So if I did as you suggest, after the subtitles are drawn, I would have no alpha channel I could use to blend the subtitles onto the real video image.

Oh, okay. That sucks. The only contrived work-around I can think of at this point is to have the ISR render it twice, once on a black background and once on a white background then use various image techniques to recreate the missing alpha channel. But that would require twice as much rendering time.

I think a simpler solution may just be to have one of the MPC-HC devs go through the ISR code and make it fill the alpha channel (optionally, of course) as well.
Have you considered forking VSFilter and rendering subtitles yourself (well, of course you've considered it, but how immediate/easy would it be?)

madFlac is written in Delphi. However, writing a video renderer goes a lot deeper than writing a "simple" decoder. That's why I (reluctantly) chose C++ for the video renderer. There's a reason why madVR ships with many dlls and a madHcCtrl.exe. They're all written in Delphi. Only madVR.ax itself is written in C++.

Makes sense, yeah.

It's not as simple as it sounds. If you deinterlace video content properly, the video framerate doubles. If I allow external shaders to add new video frames to madVR's internal frame queues, things can become ugly fast. E.g. would such frames get into the "decoder queue"? Or would I have to add a new "deinterlacer queue"? (These are rhetorical questions). Supporting external scaling would be somewhat easier. Supporting simple processing with no framerate and resolution change would be rather easy in comparison.

I suppose you're right about this one, I didn't think of changing framerates. I agree at this point that external processing filters (eg. ffdshow) should be used here.

[iSunrise]

Originally Posted by nevcairiel

I actually get glitches if i use 16 buffers, 12 seems to be the sweet spot for me right now.
Combined with "use a separate device for presentation" (but not DX11), flushing: dont/flush/flush/dont and "limit rendering times to avoid glitches", its pretty much perfect now.

Default settings used to glitch on non-matched refresh rates, be it 25p at 50Hz, or even 24p at 60Hz, but these are perfect.

The only problem i have right now is that after playing some files consecutively without closign the player, exclusive mode fails. Restarting the player fixes it ...

This is on a GTS450

These settings must´ve taken you quite some time to figure out, but they are just perfect, Nevcariel, thanks a lot for sharing them. I just went through a lot files and these are rock-solid even when playing back 23.976/24fps content at 24Hz. 12 buffers indeed seems to be the sweet spot, everything else keeps on glitching.

[madshi]

Originally Posted by nand chan

I think a simpler solution may just be to have one of the MPC-HC devs go through the ISR code and make it fill the alpha channel (optionally, of course) as well.
Have you considered forking VSFilter and rendering subtitles yourself (well, of course you've considered it, but how immediate/easy would it be?)

Forking VSFilter myself would probably be problematic in terms of GPL etc. After all madVR is closed source. I'd rather have a look at libAss instead. But that's all future talk. It's really too bad that the alpha blending doesn't work on 16bit textures with older GPUs. That's a problem a didn't anticipate. It would have been so easy/nice.

[nand chan]

Originally Posted by madshi

Forking VSFilter myself would probably be problematic in terms of GPL etc. After all madVR is closed source. I'd rather have a look at libAss instead. But that's all future talk. It's really too bad that the alpha blending doesn't work on 16bit textures with older GPUs. That's a problem a didn't anticipate. It would have been so easy/nice.

Possible work-around: Dither down to 8 bit, then render subtitles, then color correct back into 16-bit. Sure, you dither twice, but I've tested previously whether this actually results in a noticeable difference (I have not been able to find a test case for which it does).

As an optional setting in the tweaks section this could work for now, for those who want color accurate subtitles *and* have an older GPU.

[nevcairiel]

If there is work going into a new subtitle filter, it should imho be designed in such a way that its not locked into one renderer (iow. defining a new/better interface to a sub rendering filter, and using that instead of hard-wiring it)
If one day the time comes, i would be available to also work on that, the existing subtitle solutions have really been annoying me lately.

[madshi]

Originally Posted by nand chan

Possible work-around: Dither down to 8 bit, then render subtitles, then color correct back into 16-bit. Sure, you dither twice, but I've tested previously whether this actually results in a noticeable difference (I have not been able to find a test case for which it does).

As an optional setting in the tweaks section this could work for now, for those who want color accurate subtitles *and* have an older GPU.

I'd rather suggest using 10bit textures then. That has already been reported as a working solution.

[nand chan]

Originally Posted by madshi

I'd rather suggest using 10bit textures then. That has already been reported as a working solution.

10 bit would in fact even be perfect since at that level the dithering is basically going to have no visible difference to 16 bit. Either way, can I go ahead and assume this is how you're going to implement it for the time being? Would be a great compromise solution, ie:

Default: No color management on subs, same as now
Optional 1: Color management for subs
Optional 2: (Only available when previous selected) Dither to 10 bit before rendering subtitles

[madshi]

Originally Posted by nevcairiel

If there is work going into a new subtitle filter, it should imho be designed in such a way that its not locked into one renderer (iow. defining a new/better interface to a sub rendering filter, and using that instead of hard-wiring it)
If one day the time comes, i would be available to also work on that, the existing subtitle solutions have really been annoying me lately.

Well, I would be happy if there was a new external subtitle renderer available. That would save me from writing my own. I have to say, though, if I do feel the need to write my own subtitle renderer, at some point in the future (due to lack of available alternatives), then I will definitely make it a fixed part of madVR.