MPC-HC tester builds for internal renderer fixes

[clsid]

MPC Audio renderer is buggy and incomplete. It should not be used.

[JanWillem32]

I've been experimenting with that one for a bit. The original code didn't allow changing WASAPI mode, mine does (it was easy to fix). The MPC Audio Renderer is hopelessly dated compared to other versions of this project. The reason you're probably not getting audio is because WASAPI was activated on 32-bit float or 24-bit integer audio (it chokes on that). The trunk version just silently reverts to the default audio renderer. No errors are displayed, it's only visible in the filters menu.

[JohnLai]

OK.....so...any chance of fixing the error of stackhash when exiting D3D mode? I reported it on the other thread, but still isnt fixed as build 3733.

[Hera]

Yep MPC still crashes...

[JanWillem32]

Does that crash on exit still only occur when using something else than the regular commands for "close" and "exit"?
I think the exit command by a regular Alt+F4 isn't intercepted properly. My version of the renderer does have a lot stricter exit sequence that could indeed crash if interrupted.
About nasty crashes, the main deadlock by the DVD Navigator was solved. I think I should patch the trunk build for this one.
I'm very glad this one was found, as all custom internal renderers are vulnerable to this risk. The aspect ratio problem was only a very minor side-effect.

[Hera]

ALT-F4 is common
Possibly once (just once) coming out of sleep
Opening a second file on XP (noticed when testing 16f performance)

[cca]

Maybe a matter of habit but I always try to close MPC-HC with the Alt+X combination and not Alt+F4.

[JohnLai]

I paste what I wrote much more earlier in past.
First, for 'exit' command, set 'modifier' to none and 'key' to nothing. Set the 'mouse' to 'Left double click'.
Second, make sure mouse setting for 'fullscreen' command is set to 'none'.
Now, play any video file with D3D mode enabled and left double click to exit. The crash will happen.

One of the developer said he cant diagnose the issue because stackhash error didnt occur with debug build.

[JanWillem32]

The default MPC-HC compiler settings for debug builds are very different from release builds. Not even regular SSE is set for x86 builds and many optimization options that are common for even debug builds are not set as well. I use very different settings for debug builds, with one profile for optimization and one for bug checking.
I can replicate the problem with these very specific settings, so I'll have a go with this issue. Debugging for the DVD playback and the frame interpolator worked out very well, I hope it turns out well for this case, too.

edit: I solved it, now just some more testing...

[JanWillem32]

It does seem I did a lot today, but I was actually sick most of the time. :( The changes to the code just worked out well, with only little effort. :)

-the Output tab of the Options screen has been cleaned up, so check your settings before opening any videos
-improved (mostly simplified) the aspect ratio to video size detection
-fixed several problems with handling window paint calls, DVD menus were most affected
-fixed window exit sequences, the exclusive mode was most affected
-revised OSD bitmap loading for better efficiency and better support of window resizing
-added limited color ranges conversion to the color management menu
-revised the safety release and timing system for the constant frame interpolator (please report if it works or fails)
-edited the timing for the VMR-9 r. subtitle scheduler part (please report if it ever needs any more adjustments)
-tried to edit the VSync code again, messed up the monitor refresh rate detection, but it works better anyway

todo:
-make the menu stills for the DVD navigator update twice per second (like the paused mode) to refresh the first background-colored screen, and keep up at least a bit with WM_PAINT messages from the system
-try Reclock

[cca]

It does seem I did a lot today, but I was actually sick most of the time. :( The changes to the code just worked out well, with only little effort. :)

-the Output tab of the Options screen has been cleaned up, so check your settings before opening any videos
-improved (mostly simplified) the aspect ratio to video size detection
-fixed several problems with handling window paint calls, DVD menus were most affected
-fixed window exit sequences, the exclusive mode was most affected
-revised OSD bitmap loading for better efficiency and better support of window resizing
-added limited color ranges conversion to the color management menu
-revised the safety release and timing system for the constant frame interpolator (please report if it works or fails)
-edited the timing for the VMR-9 r. subtitle scheduler part (please report if it ever needs any more adjustments)
-tried to edit the VSync code again, messed up the monitor refresh rate detection, but it works better anyway

todo:
-make the menu stills for the DVD navigator update twice per second (like the paused mode) to refresh the first background-colored screen, and keep up at least a bit with WM_PAINT messages from the system
-try Reclock

Actually it's dfr 3734. Anyway, much improved but the DVD menus need some work, you already know that anyway. The frame interpolator doesn't crash now, good.
Get well soon!

[nand chan]

Do you know how the builds at http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj are compiled? SSE/2? Any optimizations?

Also, if you're not using any internal renderers other than the subtitle renderer (LAV Video + ffdshow + madVR + ReClock are being used otherwise), would it make a big performance difference?

More importantly, will it make a big performance difference for the subtitle renderer?

[nevcairiel]

Changing the compile settings in MSVC does not influence the performance much. Any time critical algorithms needs to be written in assembler if you want to take advantage of SSE, the optimizations the compiler does are usually not all that great.

I suppose they are compiled with the default settings, which is SSE1, but no SSE2. Like i said, this does not affect manually written ASM code.

[nand chan]

Changing the compile settings in MSVC does not influence the performance much. Any time critical algorithms needs to be written in assembler if you want to take advantage of SSE, the optimizations the compiler does are usually not all that great.

I suppose they are compiled with the default settings, which is SSE1, but no SSE2. Like i said, this does not affect manually written ASM code.

Is the sub renderer written as assembly?

Isn't it compiled using MinGW?

[nevcairiel]

The subrenderer is compiled with MSVC, afaik. I think it contains some parts in ASM, but overall its rather inefficient and bad code. :)
The only thing really compiled with MinGW is avcodec.

[JanWillem32]

There are also intrinsic functions that can be used to write packed SSE code (and generally have the same readability as assembly). I do check the assembly generated, but I'll let the compiler handle the rest, such as inserting pre-load operations. I don't write assembly directly. A little sample of this from the VSync code (both code paths do the same thing):#if _M_IX86_FP != 1// SSE2 code, don't use on SSE builds, works correctly for x64 and AVX
__m128d x0 = {m_dMonitorHeight, m_dMonitorHeight*m_dDetectedRefreshRate};
static const __m128d x1 = {1.0/3.0, 0.003};
__m128d xa = _mm_mul_pd(x0, x1);// output is: low (a) 1.8 ms, high (b) 33% of Time
__m128d xb = _mm_shuffle_pd(xa, xa, _MM_SHUFFLE2(0, 1));// swap high and low doubles
__m128d xc = _mm_min_sd(xa, xb);
static const double px2 = 5.0;
static const __m128d x2 = _mm_load_sd(&px2);// note: high register set to zero uses MOVSD, instead of MOVAPD
__m128d x3 = _mm_max_sd(xc, x2);
#ifdef _M_X64
__int64 MinRange = _mm_cvtsd_si64(x3);// rounding cast value to __int64
#else
int MinRange = _mm_cvtsd_si32(x3);// rounding cast value to int
#endif
#else
double a = 0.003*m_dMonitorHeight*m_dRefreshRate;// 1.8 ms
double b = m_dMonitorHeight/3.0;// 33% of Time
double c = (a < b)? a : b;
ptrdiff_t MinRange = static_cast<ptrdiff_t>((c > 5.0)? c : 5.0);// 1.8 ms or max 33% of Time
#endifI might have to revise it sometime. I'm not entirely happy with the VSync code. This is just converted original code, I personally don't like to use "1.8 ms or max 33% of Time". It's too rigid for varying connection types, refresh rates, refresh rate stability and screen sizes.

[nevcairiel]

Intrinsics mostly convert 1:1 to ASM operations, its just easier to interface with the C parts.

I wrote all custom algorithms in intrinsics in LAV Video, mostly because inline assembly doesn't work in x64 compiles. The code is exactly the same as inline assembly, except that you do loops and variable handling in C, instead of assembly.

[nand chan]

Do you think you could use/add a mirror that supports hotlinking, eg. omploader.org (or others)?

I want to download the tester builds from within a program, but downloading from mediafire would require me to implement some extremely cumbersome virtualization logic to bypass the silly download page.

[JanWillem32]

I actually find MediaFire quite convenient with bulk multi-uploading to multiple folders. The host doesn't seem to be blocked by national firewalls and such as well. How much of my folder are you actually trying to download that would need a controller program? The standard packages are less than 5 MB. With download speeds of 230 kilobyte per second over here, items of that size should be done within a minute. With slightly more than 100 downloads for dfr3734 alone, it seems to work well for most people. I don't mind switching hosts, but I prefer to have a good reason for it. I've had the current set of folders for a while, too.

[golagoda]

Dropbox is easy to use and supports hotlinking. Especially with Windows explorer (and nautilus, for linux) integration.

You need to install the program to upload things to it though.

[nand chan]

I actually find MediaFire quite convenient with bulk multi-uploading to multiple folders. The host doesn't seem to be blocked by national firewalls and such as well. How much of my folder are you actually trying to download that would need a controller program? The standard packages are less than 5 MB. With download speeds of 230 kilobyte per second over here, items of that size should be done within a minute. With slightly more than 100 downloads for dfr3734 alone, it seems to work well for most people. I don't mind switching hosts, but I prefer to have a good reason for it. I've had the current set of folders for a while, too.

I'm just trying to download the “mpc hc SSE2 tester dfr3734.7z” file (or whatever the latest version is).

If you have your reasons for not providing a mirror then I will respect that, it'll just take a day of reverse engineering to hack through the mediafire download page.

[JanWillem32]

What exactly isn't working? Is it because of security settings that the download link doesn't show up, or doesn't the link itself seem to work?

On another note, the frame interpolator has been broken the last few revisions, the render target is messed up, reducing the output quality. I'm currently fixing it, along with doing some performance optimization.

[JanWillem32]

I've just fixed the frame interpolator. It's a lot better-looking, smoother (see the tearing test) and mostly, more efficient. I added a big amount of code for it, and it was well worth it.
I'm thinking that an intermediate form in between the basic and adaptive types might be useful (the code from the basic type with the bare minimum for artifact removal from the adaptive type). Could people here show some GPU performance data to compare the required processing power of the two current types? I'm still experimenting with various forms. The case of a frame exactly in between two other frames is still difficult to get reasonable results for. I've been looking at deinterlacing techniques (those also have to do this, but for another reason and line-based), but all I seem to get are the typical artifacts.
I've also fixed a nasty subtitle invalidation bug and improved some geometry code.

[cca]

I've just fixed the frame interpolator. It's a lot better-looking, smoother (see the tearing test) and mostly, more efficient. I added a big amount of code for it, and it was well worth it.
I'm thinking that an intermediate form in between the basic and adaptive types might be useful (the code from the basic type with the bare minimum for artifact removal from the adaptive type). Could people here show some GPU performance data to compare the required processing power of the two current types? I'm still experimenting with various forms. The case of a frame exactly in between two other frames is still difficult to get reasonable results for. I've been looking at deinterlacing techniques (those also have to do this, but for another reason and line-based), but all I seem to get are the typical artifacts.
I've also fixed a nasty subtitle invalidation bug and improved some geometry code.

Will try the build latter today. In the mean time, my observations with the previous build are not so good, it seems EVR-CP is unable to produce smooth video in any windowed mode, in Aero is just jerky, without Aero it's smoother but has tearing problems, VSync is no go, completely broken slows the video to a crawl. Only mode with decent flow is the exclusive D3D fullscreen (vsync off, still broken).

[ForceX]

Unfortunately the typesetting appearing before time issue in VMR9r isn't fixed yet; moreover in dfr3740 subtitles don't even show up in VMR9r and EVR CP unless you disable and enable it within the player.

And the lut3d profiles created by dfr3734 and 3740 creates garbage images. Using the tester dfr3733-generated files works ok.

What exactly isn't working? Is it because of security settings that the download link doesn't show up, or doesn't the link itself seem to work?

I think he wants to automatically download the latest file from within a program, and because mediafire doesn't have direct linking to files, he can't.

[janos666]

I am not sure but I think the frame interpolation is still broken. At leas my test videos are much smoother with 24fps@96Hz (4:4 FRC by the TV, no interpolation) than 24fps+interpolation@60Hz (according to CCC, my GPU load is <5% with the precise method). Frame interpolation usually creates "soup opera effect" which I hate just as much as the artifacts (interpolation errors) but your method seems nothing like that. I see some minor artifacts but the motion isn't smooth, sometimes even worse than 24fps@60Hz.

[G_M_C]

I am not sure but I think the frame interpolation is still broken. At leas my test videos are much smoother with 24fps@96Hz (4:4 FRC by the TV, no interpolation) than 24fps+interpolation@60Hz (according to CCC, my GPU load is <5% with the precise method). Frame interpolation usually creates "soup opera effect" which I hate just as much as the artifacts (interpolation errors) but your method seems nothing like that. I see some minor artifacts but the motion isn't smooth, sometimes even worse than 24fps@60Hz.

Can you really output 96fps to the TV; i.e. is 1080p (or whatever resolution) @ 96 Hz an option / mode available through CCC ?

[janos666]

Can you really output 96fps to the TV; i.e. is 1080p (or whatever resolution) @ 96 Hz an option / mode available through CCC ?

No, the output is 1920x1080p24. It's just the TV which applies 4:4 FRC and runs the plasma panel at 96Hz (full-field) refresh rate (Samsung calls it CinemaSmooth). The frames are repeated four times, the 2011 models doesn't even offer any frame interpolation modes. (But I don't miss it. The only drawback of 96Hz is the higher MLL - compared to 60Hz 0.045vs0.060 cd/m^2).

I can't go above 60Hz with the input frequency, except the 720p60 3D mode which is 2x720p60. I don't know if anybody made a hack to trigger this mode but use it without the shutter glasses in 2D to get real 120Hz. It wouldn't worth it anyway.

The limiting factor here is the HDMI 1.4 standard, 1080p60 is practically the best you can get. Too bad because it would be so cool to play some PC games in FullHD3D and 60Hz for both eyes (on this plasma, not on those TN LCDs...). 720p 3D is too blurry for me and 1080p30 makes every games unplayable.

[JanWillem32]

@cca: Timing frames is rather new to me. It was a nasty suprise that the original Vsync and scheduling code broke. I've had to patch it everywhere to get it to even work at this level. I wish we had developers for helping with this part of the code.

@ForceX: I can't replicate the problem with default disabled subtitles at the moment. I'll try some more. Is there something in your setup that might cause this to happen?
I can replicate the timing issue in VMR-9. The timer has a few rounding issues and VMR-9 doesn't have the best scheduler. Does a constant subtitle delay help in your case for VMR-9? It might just need a dirty patch for a few frames delay.
The LUT3D problem has been solved in this release. It was mostly a data alignment issue that was easily solved.

@janos666: The "soap opera effect" should be really visible. It's indeed likely that the interpolator fails in your case. Less than 5% GPU usage with the past releases seems unlikely with such a heavy filter. It features a few safety features to avoid choking the renderer, so one of those is probably deactivating the feature.
As for refresh rates; http://en.wikipedia.org/wiki/Hdmi .
For 1920×1080 on HDMI 1.3 and 1.4, overhead removed:
(24-bit) 8160000000/1920/1080/24 = 163.966 Hz
(30-bit) 8160000000/1920/1080/30 = 131.173 Hz
(36-bit) 8160000000/1920/1080/36 = 109.311 Hz
(48-bit) 8160000000/1920/1080/48 = 81.983 Hz
Not all receivers can handle the full capacity, though. But it's not a limitation in the standard.

For the new builds, I've lost the change log... I've at least worked on fixing the 3DLUT generator, on a major changes in the frame rate detection and the frame interpolator. All three parts need some performance optimization, but integrating the final pass shader into the frame interpolation shaders was a good start. I didn't test everything very thoroughly this time, so please keep a previous version ready as a backup (and report what's wrong, please).

[janos666]

As for refresh rates; http://en.wikipedia.org/wiki/Hdmi .
For 1920×1080 on HDMI 1.3 and 1.4, overhead removed:
(24-bit) 8160000000/1920/1080/24 = 163.966 Hz
(30-bit) 8160000000/1920/1080/30 = 131.173 Hz
(36-bit) 8160000000/1920/1080/36 = 109.311 Hz
(48-bit) 8160000000/1920/1080/48 = 81.983 Hz
Not all receivers can handle the full capacity, though. But it's not a limitation in the standard.

Oh, now that you say... I didn't consider they doubled the maximum TDMS clock with the 1.3 revision. I just compared it with DVI which needs dual-link to offer 1920x1080p120.

According to Moninfo, the maximum allowed TMDS clock is 225Mh on my device.
8160000000/1920/1080/24/(340/225) = 108.5 Hz
It means 50fps for both eyes should be possible and I think it would be enough to play RPG games (and may be FPS games as well if you are only looking for occasional fun and not "sport"...).

And 120Hz would also be possible with YCC 4:2:2 output format (the TV doesn't offer 4:4:4 mode in 3D anyway).

[cca]

dfr 3751 has a serious problem here when paying windowed with Aero on, this happens:
http://img137.imageshack.us/img137/5658/tempy.th.png (http://imageshack.us/photo/my-images/137/tempy.png/)

Actually the same with aero off, still windowed.

[JanWillem32]

@janos666: Good luck with trying out custom profiles. I do advise to keep a second monitor next to it, for in case you get a black screen. That happens often when trying custom refresh rates. Don't take 225 Mhz as an absolute maximum. Many devices can handle a bit more than they actually report. I've made a few profiles for monitors, and the maximum is rarely a multitude of 5, like often reported.

@cca: That bug has been there for months already. It's caused by the destructor of the subtitle allocator. It doesn't take it well when resizing a window when a subtitle is being pre-loaded.

[cca]

@janos666: Good luck with trying out custom profiles. I do advise to keep a second monitor next to it, for in case you get a black screen. That happens often when trying custom refresh rates. Don't take 225 Mhz as an absolute maximum. Many devices can handle a bit more than they actually report. I've made a few profiles for monitors, and the maximum is rarely a multitude of 5, like often reported.

@cca: That bug has been there for months already. It's caused by the destructor of the subtitle allocator. It doesn't take it well when resizing a window when a subtitle is being pre-loaded.

well in this build happens consistently *every* time, it's unusable. Testing a bit, even on files where it doesn't crash the subtitle *do not show*. This build is rather broken...

[ForceX]

I actually mistook the lack of subtitle issue for something else. The subtitles disappear if you resize the player. Because my MPC setup always resizes the window while opening a file, it seemed the subtitles did not work. Setting it to maximized and opening files afterwards made me realize my mistake.

What does the Subtitle option Delay Interval do? -_- I thought it was for delaying subtitles but it doesn't seem to do anything and it doesn't even accept negative values so it can't be that.

[CruNcher]

@jan
maybe you know whats going on http://forum.doom9.org/showpost.php?p=1529716&postcount=128 ?

[Hera]

Subtitles need to be reloaded to be displayed when not using D3DFS

[upyzl]

Subtitles need to be reloaded to be displayed when not using D3DFS

same problem

but previous 3733 doesn't...

[cca]

Subtitles need to be reloaded to be displayed when not using D3DFS

99% of the subtitles in the anime I watch are embedded in a .mkv file, they are not external to be reloaded.

[ForceX]

99% of the subtitles in the anime I watch are embedded in a .mkv file, they are not external to be reloaded.
I think he is referring to this:... in dfr3740 subtitles don't even show up in VMR9r and EVR CP unless you disable and enable it within the player.


I've found out that the subtitles disappear if you resize the window during playback, and only way to bring it back is disabling and enabling subtitles in the player.

[CruNcher]

@Jan
do you have also a idea why it shows YUY2 the input should be NV12 according to ffdshow-quicksync
http://forum.doom9.org/showpost.php?p=1529823&postcount=137

[VenomousNinja]

Yes, external subtitles doesn't work for me too.

[CruNcher]

@Jan
another one http://forum.doom9.org/showpost.php?p=1529877&postcount=139 ;)

[JanWillem32]

I've just solved the subtitle issue (superficially, as what the subtitle renderer does is still very wrong). I'll have a go at helping to debug ffdshow-quicksync, thank you for the reference CruNcher.

[nand chan]

Do you think you could attempt to tackle the subtitle position bug (http://img690.imageshack.us/img690/2899/subpos.png)? To recap some of the information:


Only happens using the MPC-HC internal renderer
Only happens on a 16:10 (or other non-16:9) monitor
The image is exactly 60 pixels too high, equivalent to half of the extra height 1920×1200 offers
Only happens for bitmaps, regular subtitles are all correct
Only happens in fullscreen mode, windowed modes are fine
Happens with all renderers that support the ISR, including madVR, EVR CP, EVR Sync, Haali and VMR-9
Happens regardless of texture resolution settings (here's what happens (http://img810.imageshack.us/img810/148/subposlo.png) if I lower it from “Desktop” to some low-res 16:9 format)
Happens regardless of buffer/animation settings
Happens regardless of the screen alignment & margins settings
Only happens if “Position subtitles relative to the video frame” is turned on (but if I turn it off, all other subs are misaligned and the bitmap is too large
Happens regardless of “correct monitor/desktop AR difference” setting
Changing the “override aspect ratio” settings changes the offset as well (in windowed mode)
If I change the video frame mode to “half size” or “double size”, it's aligned perfectly (even in fullscreen mode)
If I change the video frame mode to “touch window from outside”, its aligned vertically (with the stretched image), but offset to the right (in fullscreen mode)
If I change the video frame mode to “stretch to window”, it's too far down


Confirmed episodes for which it happens: Very beginning of [CoalGirls] and THORA releases of Bakemonogatari episode 1, as well as some scenes in the [CoalGirls] release of Katanagatari (in the last episode)

[CruNcher]

I've just solved the subtitle issue (superficially, as what the subtitle renderer does is still very wrong). I'll have a go at helping to debug ffdshow-quicksync, thank you for the reference CruNcher.

in this matter i experience something rather strange not sure but the jitter behavior of the test builds EVR-CP is definitely different from the main builds with ffdshow-quicksync in a window with the OSD on it shows the low normal jitter of .4xx ms (same as with mpc-hc main) but as soon as i maximize the window it goes up to 2 ms and then very slowly recovers the same for Fullscreen (Aero On). It also looks like the Test builds do some kind of internal Mode change as the aspect ratio changes for a second if this jitter spike occurs.


Here is it visually in the 3 steps:


Windowed:

http://img689.imageshack.us/img689/4669/windowed.png

Maximized:

http://img88.imageshack.us/img88/1875/maximized.png

Maximized: after some time time into playback (changes proportional over time)

http://img189.imageshack.us/img189/1368/maximizedaftersometime.png


PS: It seems if i stop playback i can force the Jitter to lower instantly without waiting, also i only get a output @ all @ 8 bit integer the other modes 10,16,32 cause a black screen of the video content sound plays.

Other render modes then 8 bit integer result:

http://img696.imageshack.us/img696/7491/blackscreen.png

[CruNcher]

This is also one of the craziest things i experienced so far :D

http://img710.imageshack.us/img710/842/wtvfunny.png

The Microsoft WTV continues to playback though it's closed, the chain this opens up is crazy full of filters too (Microsoft ones) :D

[JanWillem32]

@nand chan: I looked into this problem, and it was surprisingly simple to fix.
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/Subtitles/RTS.cpp
The incompletely implemented functions were "clip" and "iclip". It was marked in the source as incomplete (main reason I could fix it so easily). I wonder why previous developers left it in that state.
We'll have to evaluate if the patch I created is problem-free, so it can go into the trunk build.

@CruNcher: The trunk build creates textures at screen resolution size. I changed that to active window size. Whenever the active window size changes, all active window-sized textures, geometry data and subtitle renderer parts are released and re-created. That simply takes moment.
The problem seen in the third picture is indeed a very annoying one. The video card can handle A2R10G10B10 surfaces, but a filter in the video processor chain can't. This isn't a renderer problem (else you wouldn't even get to see the stats screen at all). Many filters implemented by a video card's driver are known to cause black screen output. With older drivers of my video card, I had black screen output as well when enabling some "quality options" (normal filters like the deinterlacers and color conversion never had this problem in my case). The renderer never receives an error if the video processor fails, by the way.
The issue in the fourth picture should only come up rarely. When the graph receives a quit command, it doesn't force the loaded filters to unload immediately, it only sends messages to the filters to quit and unload. When a filter continues to feed a renderer, it won't stop.
I get it often when I'm working with a debug build and break execution of the program with the debugger to inspect the running process. Breaking causes a timer gap, so the renderer tries to catch up with the "lost" time. It's indeed annoying, but if exiting the program proceeds normally, it's harmless.

[nand chan]

@nand chan: I looked into this problem, and it was surprisingly simple to fix.
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/Subtitles/RTS.cpp
The incompletely implemented functions were "clip" and "iclip". It was marked in the source as incomplete (main reason I could fix it so easily). I wonder why previous developers left it in that state.
We'll have to evaluate if the patch I created is problem-free, so it can go into the trunk build.

This is actually great news, it means the age old problem that has been plaguing the ISR is now a non-issue!

I tested the updated build and it seems to work fine, that is, I was able to go through a heavily typeset episode (the same bakemonogatari ep) without noticing any positioning problems, and it fixed the bug I reported.

The reason why the previous developers left it like that is probably because nobody gives half a damn about MPC-HC's subtitle renderer, that's the sad state of things.

The only issue that remains to be fixed now is the fact that madVR doesn't color correct subtitles, but that's his problem.

[JanWillem32]

There's not a lot to color correct, actually... The subtitle renderer could write 8-bit RGBA in its current color format (already a nasty limitation), but the renderer calculates in 6-bit, and to make it worse, the primary font drawing is only 4-bit. I would simply have used SSE code for writing rectangular 32-bit float textures for each element, and let the GPU blend each part (or even just use the standard DirectX 10/11 rasterizer instead, but that won't work for people with an old GPU or on Windows XP).
There are two other issues with the output in general. When importing non-RGB subtitles, the color format is converted by the subtitle renderer. Any sort of color conversion is a video renderer task for the blending stage.
The subtitle renderer multiplies all of its color output by 1-alpha. This seems to work reasonably well for VSfilter and 8-bit surfaces, but lowers color and blending quality of semi-translucent pixels. When the video renderer tries to blend it with sensible settings, darkening artifacts appear where these pixels are blended in.

What I've patched today was the formatted text parser. Its code is sub-optimal, but it at least doesn't require a lot of processing compared to the rasterizer and other pixel rendering parts.

[nand chan]

There's not a lot to color correct, actually... The subtitle renderer could write 8-bit RGBA in its current color format (already a nasty limitation), but the renderer calculates in 6-bit, and to make it worse, the primary font drawing is only 4-bit. I would simply have used SSE code for writing rectangular 32-bit float textures for each element, and let the GPU blend each part (or even just use the standard DirectX 10/11 rasterizer instead, but that won't work for people with an old GPU or on Windows XP).
There are two other issues with the output in general. When importing non-RGB subtitles, the color format is converted by the subtitle renderer. Any sort of color conversion is a video renderer task for the blending stage.
The subtitle renderer multiplies all of its color output by 1-alpha. This seems to work reasonably well for VSfilter and 8-bit surfaces, but lowers color and blending quality of semi-translucent pixels. When the video renderer tries to blend it with sensible settings, darkening artifacts appear where these pixels are blended in.

What I've patched today was the formatted text parser. Its code is sub-optimal, but it at least doesn't require a lot of processing compared to the rasterizer and other pixel rendering parts.

Interesting information, but that's not really related to the issue I'm experiencing. (Of course, if you can improve the quality of the subtitle renderer, I'm all for it!)

The problem is that when you use color management to apply significant changes to the color, for example converting something from BT.709 color space into something like Adobe RGB, or applying gamma correction (I correct mine to 2.5), the result is something like this (http://img839.imageshack.us/img839/2249/colorsubs.png).

There's also a problem, in yet the *same* bakemonogatari episode, where the entire frame is covered with a red subtitle - if you're doing something like translating from BT.709 to a wide gamut color space, the red will appear far, far too red than it should be for sRGB, which means that the frame will not only fit into the video but also be annoying on the eye. It's even worse for green, which will look like plastic.