madVR - high quality video renderer (GPU assisted)

[nand chan]

Correct, and I agree, the dithering improves the results considerably... but I would still like to be able to tweak the pre-dither (or no-dither) results to perfection, and look forward to when I can get 10-bit sent to the display.

That's like saying you want to master audio in the next room. Simply silly/stupid, no offense intended. You *NEVER* want to tweak the no-dither results, since those results will be wrong. Tweaking those until they're right will end up with a LUT that's completely off. You're shooting yourself in the foot. And if you calibrate against these faulty procedures, of course madVR is going to give you undesirable results.

This is one of the reasons I got rid of the VideoEQ though—that and the completely broken CMS.

I've also had a Lumagen Radiance XE (overpriced junk) and iScan Duo, neither of which has stayed in my system too long either. I think the iScan lasted the longest, as it had some unique features that were quite useful back when I was still using stand-alone devices for media playback.

You had 10-bit control for greyscale/gamma (three 1024-point 1D LUTs) and matrix controls for the CMS from what I remember.

No, his gamma controls don't use a LUT - that would be absurdly silly. It's a simple exponent calculation..

I'm not trying to compare it to what madVR is doing though, just explain why it was much easier to get the results I wanted with it, and why I look forward to 10-bit output.

Your reasoning is “I did it wrong, therefore I'm waiting for methods to make it less possible for me to do it wrong”? Can you prove that with proper dithering, 10 bit vs 8 bit makes a noticeable difference? If not, it's your personal problem - not a problem of 8 bit.

I'd probably work with 10, 20 or 100 points, time permitting, or possibly 10 points plus touch-ups where necessary. (fix any obvious errors) I realise it sounds like this goes against "hand-tuning" the LUT if you are letting the rest of the points be interpolated, but I'd prefer some sort of control rather than tell madVR what my display currently measures and hope it all turns out OK in the end.

10, 20 points? ArgyllCMS which you've previously denounced can calibrate using up to 2400 points. And yes, these are better calibrated than your rounded “hand-crafted” LUT.

It's not just greyscale though, I'd love to be able to hand-tune 25/50/75/100% saturation for RGBCMY to make sure that the response is linear—I'm not sure that my display is when put into the "wide gamut" mode. (necessary to cover BT.709 gamut as it's a white LED display) Haven't had a chance to actually measure it and check for linearity yet.

Why RGBCMY? It's not related to video playback. And you don't need to hand-tune a LUT for this.

Right, but then I feel like I'm basically guessing—yCMS only accepts XYZ or xyY data, right?

As opposed to what? XYZ and Yxy are raw measurement data. What else do you want?

I suppose the simplest way to put it, is I just want to give it:
100%: 254,234,245
90%: 230,225,240
etc. and have it fill in the rest. (ideally this would be 10-bit though...)

No, this is the reason they didn't stay, and why madVR has replaced all stand-alone devices connected to my TV.

The main part of the problem isn't even madVR itself. (though I'm still not entirely convinced about 8>16>8 avoiding possible colour shifts near black when making gamma changes)

The problem is that you cannot disable a modern display's own internal LUTs/Processing, and have it display exactly what you send it. To get the best results, you're basically fighting against the display.

I feel that if you had used one of these external LUT boxes, you would immediately understand the problem, and I'm really not doing a good job of explaining it.

There's no difference between an external LUT box and an internal LUT box. Unless your video card is not outputting faithful signals. If so, that's a fault of your video card and should be easy to fix.

When tweaking with the VideoEQ, it was not uncommon to see things such as this:Pass|Output Value|Relative R| G | B
1 | 64, 64, 64 | 105% | 100% | 98%
2 | 62, 64, 66 | 104% | 100% | 99%
3 | 60, 64, 67 | 103% | 100% | 99.2%
4 | 58, 64, 68 | 103% | 100% | 99.4%
5 | 56, 64, 70 | 101% | 100% | 102%
6 | 55, 64, 69 | 099% | 100% | 101%10-bit precision helped dial in the results better, and the reason you have things jumping several steps at once sometimes is because you're essentially fighting against the display's internal processing to get the result you want from it.

You shouldn't need to fight against the display's internal processing. The challenge is not to calibrate your display to make it perfect, the challenge is to characterize your display the way it is, then simply use that knowledge to display the correct signal. This is how ICC profiles work. You aren't supposed to modify the way your display behaves at all.

Sometimes changing one of the output values from the LUT box would not make a change on the display, and sometimes making a single digit change would have it jump 2-3%.

That's why you dither. As has been mentioned often enough, with proper dithering, 8 bit output vs 10 bit output becomes far less of an issue.

[Nicola]

subtitles have blackness instead of transparency in mpc-hc too.

[Skwelcha]

When i switch to another videofile during playback MPC-HC crashes without any warnings, it just closes.

[XRyche]

subtitles have blackness instead of transparency in mpc-hc too.

confirmed

[gbates]

When i switch to another videofile during playback MPC-HC crashes without any warnings, it just closes.

subtitles have blackness instead of transparency in mpc-hc too.

Unfortunately +1

[madshi]

(1) Missing seek bar and OSD: Problem found and fixed.

(2) No transparency with subtitles: Can I have a screenshot that shows this problem, please? Does activating the "use 10bit luma texture" in the "trade quality for performance" make a difference?

(3) Crash on exit: I can't reproduce that here. Can anybody help me reproducing this crash, please?

[Skwelcha]

(4) crashes when switching to another videofile during playback

for me it's with every h.264 videofile, on the other hand it doenst crash on exit.

[6233638]

For anyone wondering about the benefits of linear light scaling, here's an example from Tron Legacy when downscaling.

Original/Normal
http://img829.imageshack.us/img829/4197/originalor.th.jpg (http://img829.imageshack.us/img829/4197/originalor.jpg) http://img405.imageshack.us/img405/8065/normalzc.th.jpg (http://img405.imageshack.us/img405/8065/normalzc.jpg)
Original/Linear
http://img829.imageshack.us/img829/4197/originalor.th.jpg (http://img829.imageshack.us/img829/4197/originalor.jpg) http://img33.imageshack.us/img33/9095/linearl.th.jpg (http://img33.imageshack.us/img33/9095/linearl.jpg)

These need to be viewed at 100% in the browser, and it's best to open them in separate tabs/windows and switch back/forth.


What you should notice is that the linear version maintains the original brightness of the source image, whereas the normal image is darker than intended.


Depending on the image being displayed, and the scaling algorithm used, the results may be more or less dramatic.

It definitely seems to introduce ringing with some of the scaling algorithms though, so look out for that.

Haven't done much testing with upscaling yet to produce some example shots, but I'm sure the results are similar.

[noee]

(3) Crash on exit: I can't reproduce that here. Can anybody help me reproducing this crash, please?

It's happening on file/close too. Using a later version of MPC-HC, start a video, then exit the app or choose file/close (Ctrl+c). MPC-HC will then crash.

I get with LAVVideo and madVR video decoding. Any MKV with h.264 video.

[nand chan]

Depending on the image being displayed, and the scaling algorithm used, the results may be more or less dramatic.

Yeah, this is pretty much the best case scenario for linear light scaling: Lots of fine bright/dark patterns with very high contrast. I have (more or less unsurprisingly) not managed to see any worthwhile differences when viewing anime samples, but I do generally prefer linear light scaling myself.

It definitely seems to introduce ringing with some of the scaling algorithms though, so look out for that.

Would you mind testing multiple scaling algorithms to see how much each of them ring when in linear light? I'm guessing Lanczos might be too extreme in this mode. What about Catmull-Rom and friends?

[gbates]

(2) No transparency with subtitles: Can I have a screenshot that shows this problem, please? Does activating the "use 10bit luma texture" in the "trade quality for performance" make a difference?


http://img405.imageshack.us/img405/1661/notrans.png

Changing to 10bit luma buffer doesn't help.

EDIT: Changing to 10bit chroma buffer does help, but only in window mode.

EDIT2: Changing to 10bit luma buffer does help, but only in fullscreen mode.

[THX-UltraII]

Do linear lightscaling only affects he pa hen you downscale or upscale? Do this would mean no affect when running 1080p content a a 1080p display?

[6233638]

Do linear lightscaling only affects he pa hen you downscale or upscale? Do this would mean no affect when running 1080p content a a 1080p display?Looks like that is the case for now, I'm not sure why there's no linear light scaling option for chroma.

[nlnl]

madshi
If deinterlacing is the only reason to go NVidia, then I would suggest to wait a bit. Deinterlacing is quite on the top of my to do list. Maybe I'll find a good solution for ATI. Or maybe not. At least I'm going to try...

Do you have plans fo IVTC deinterlacing for NTSC films (soft? hard?)?
Now we do not have any stable decoder\rendere for that.

[pie1394]

(2) No transparency with subtitles: Can I have a screenshot that shows this problem, please? Does activating the "use 10bit luma texture" in the "trade quality for performance" make a difference?

In my case, it looks like this:

madVR 0.75
http://img265.imageshack.us/img265/2903/madvr075osdbug.th.png (http://imageshack.us/photo/my-images/265/madvr075osdbug.png)

madVR 0.74
http://img51.imageshack.us/img51/364/madvr074osdok.th.png (http://imageshack.us/photo/my-images/51/madvr074osdok.png/)

It looks like the Alpha value is mis-interpreted at the OSD background part?


(3) Crash on exit: I can't reproduce that here. Can anybody help me reproducing this crash, please?

It happens to me on all materials with MPC-HC v.1.5.3.3755 under Win7.
LAVFilter 0.37 + LAVCUVID 0.13 for MPEG-2 / madVR 0.75 H.264 decoder.

[madshi]

I'd probably work with 10, 20 or 100 points, time permitting, or possibly 10 points plus touch-ups where necessary. (fix any obvious errors) I realise it sounds like this goes against "hand-tuning" the LUT if you are letting the rest of the points be interpolated, but I'd prefer some sort of control rather than tell madVR what my display currently measures and hope it all turns out OK in the end.
Maybe at some point in time you'll be able to model a specific gamma response you want to get. But I don't think hand-tuning will work with the yCMS concept.

Right, but then I feel like I'm basically guessing—yCMS only accepts XYZ or xyY data, right?

I suppose the simplest way to put it, is I just want to give it:
100%: 254,234,245
90%: 230,225,240
etc. and have it fill in the rest. (ideally this would be 10-bit though...)
For yCMS you'd have to define 16bit values. Of course you can feel free to ask yesgrey for such a feature, but I don't think he'll implement it any time soon. He's currently taking a break for personal reasons. Later he's planning on finally starting work on yCMS v2, which will have a different logic compared to yCMS v1.

:D Is there a reason why this is only for Luma?
Yes. You can't convert Y'CbCr to linear light directly. You first have to convert Y'CbCr to R'G'B', then R'G'B' to RGB. Then you could convert back to linear light YCbCr. But you already have to upsample chroma in the first step, still in gamma corrected light.

Do you have plans fo IVTC deinterlacing for NTSC films (soft? hard?)?
I have plans to eventually look into that.

[madshi]

@Guys, I've tried to reproduce the crashes, but I've not managed to do so. I've tried h264 videos with CoreAVC, LAV Video Decoder and madVR's internal decoder. I've tried to exit MPC-HC, to close the file and to load another file. No crashes at all here with MPC-HC 1.5.3.3760.

It would be great if you could help me reproduce the crash somehow.

[fastplayer]

Did you try on Win7, too? You've mentioned that you develop on XP. Maybe it crashes only on Win7.
Windows reports "ntdll.dll" as faulting module, so it's not madVR.ax per se...

[Fadeout]

It crashed every time for me. You load a file, close the player, and *after* it closes it shows the window saying there was a crash. Probably something not released properly.

[RyaNJ]

@Guys, I've tried to reproduce the crashes, but I've not managed to do so. I've tried h264 videos with CoreAVC, LAV Video Decoder and madVR's internal decoder. I've tried to exit MPC-HC, to close the file and to load another file. No crashes at all here with MPC-HC 1.5.3.3760.

It would be great if you could help me reproduce the crash somehow.

I followed the guide here to setup my MPC HC http://imouto.my/watching-h264-videos-using-compute-unified-device-architecture-cuda/

Using Windows 7 64-bit (with 32-bit MPC HC of course).

I'm using version 1.5.3.3785 from: http://xhmikosr.1f0.de/mpc-hc/MPC-HomeCinema.1.5.3.3785.x86.exe

I'm using this version of ffdshow: http://www.xvidvideo.ru/component/docman/doc_download/7581-ffdshow-tryouts-project-svn-3995-x86-msvc2010.html

I've also noticed that if you have the video set to loop it DOES NOT crash. Only when the video is closed or if you're attempting to load a new one.

[Thunderbolt8]

crashes for me with mpc 1.5.3.3757 lavsplitter & coreavc and setup in sig

[SamuriHL]

I haven't had a chance to put it into my MC environment yet. Others were saying it crashed in other players, too, or just MPC-HC?

[NoirNL]

I'm getting the exact same crashes whenever i try to close mpc.

I'm using mpc-hc 1.5.3.3751 with madvr, lav video/audio and reclock on Windows 7.
In the event viewer i can see this after the app crash:

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: mpc-hc.exe
P2: 1.5.3.3751
P3: 4e860f5d
P4: StackHash_6c74
P5: 6.1.7601.17514
P6: 4ce7ba58
P7: c0000374
P8: 000ce653
P9:
P10:

Attached files:

These files may be available here:
C:\Users\BLANKED OUT\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_mpc-hc.exe_b27e9943d3c3824a5db9715e14b157deae241e_1643b37f

Analysis symbol:
Rechecking for solution: 0
Report Id: 5bd54dc2-fb4e-11e0-a367-bcaec5570b58
Report Status: 0


I don't know if it will help but i hope it will.

Edit: i can send you the .wer file it mentions if you want Madshi

[leeperry]

:thanks: for the new build, always highly appreciated http://forum.slysoft.com/images/smilies/agreed.gif

I agree that linear light scaling looks too edgy, I already worked hard to get the perfect soft/sharp compromise, this is simply too much on my setup...and I guess that's got to be a good sign, but the windowed/exclusive OSD isn't see through anymore http://forum-images.hardware.fr/images/perso/3/nekromanttik.gif

0.74: http://thumbnails37.imagebam.com/15494/055297154932172.jpg (http://www.imagebam.com/image/055297154932172) 0.75: http://thumbnails48.imagebam.com/15494/bd9716154932180.jpg (http://www.imagebam.com/image/bd9716154932180)

apart from this, no crashes on exit here.

[nevcairiel]

It would be great if you could help me reproduce the crash somehow.

First-chance exception at 0x771ee653 (ntdll.dll) in mpc-hc.exe: 0xC0000374: A heap has been corrupted.
HEAP[mpc-hc.exe]: Invalid address specified to RtlFreeHeap( 028D0000, 4A4A0FA8 )

I can clearly see madVR.ax in the stack trace of that exception, but since i can't look into it, i don't know anymore
Looks like a double-free to me, or trying to free a block of memory where your pointer does not point to the start of the block anymore.

[noee]

No issues at all with jRiver on XP or Win7 with .75.

[Mercury_22]

It crashes here too but using exit it's not (so) visible (MPC-HC 1.5.3.3785) Best way to see the crash use Ctrl+c (Close)

P.S. Like Nev said something with ntdll.dll!7795055c():confused:

[THX-UltraII]

:ttp://www.avsforum.com/avs-vb/showpost.php?p=21105087&postcount=65

interesting. The person who claim this is not just a regular guy, he s the author of SVP>

Is his statement true?

[nevcairiel]

:ttp://www.avsforum.com/avs-vb/showpost.php?p=21105087&postcount=65

interesting. The person who claim this is not just a regular guy, he s the author of SVP>

Is his statement true?

No its not.
You always need to upscale Chroma from 4:2:0 to 4:4:4

[nand chan]

:ttp://www.avsforum.com/avs-vb/showpost.php?p=21105087&postcount=65

interesting. The person who claim this is not just a regular guy, he s the author of SVP>

Is his statement true?

Could not be further from the truth.

[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]

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]

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.

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]

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]

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]

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.

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.

or make the option opt-in so only those with modern GPUs can enable it.
Yeah, something like that is probably the best workaround.

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.

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

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]

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]

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.

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]

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.

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.

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

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]

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]

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]

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]

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]

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]

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]

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.