MPC-HC tester builds for internal renderer fixes

[janos666]

I think it's easy to believe.

I guess we can assume the TV is optimized for limited range (EU/US-SD/HDTV and DVD/Blu-Ray sources all have limited range YCC content - except some nonstandard Asian BDs with weird levels - if the rumor is true, but that's their problem...) but I think a PDP doesn't really mind because it has very limited linear graduation and heavy dithering anyway (not like an LCD screen with 256 -or may be 64, or even 1024- physical analog states).

The original Y range is limited, the RGB expansion is only required for PC displays which are optimized for full range content.

Of course, the limited range RGB is not perfect either because the chroma range is different in YCC and the YCC->RGB conversion isn't cheap either, but the 10-bit output grants us some extra precision (without additional dithering noise on the source side).


Try to disable the dithering with 8-bit output. The limited range RGB will be reasonable but the expanded RGB output will look awful with gradient test patterns.
Next time do it with 10-bit output: the expanded level RGB won't be as smooth as it could be with dithered 8-bit (but it will be much better).
But if you skip the level expansion (well, undo it -but in high precision- in this case ; at least until we have a custom mixer...) then 10-bit RGB should be enough to get reasonable result (the TV alone isn't perfect anyway...).


May be it's only placebo, but I prefer the undithered limited range 10-bit RGB output over madVR's dithered 8-bit RGB (but it's only reasonable with limited range output because the expansion needs more precision than 10-bit).

[JanWillem32]

-I've solved some fundamental problems in the subtitle texture management
-there should be less crashes by the subtitle renderer when resizing a window (typically error no. 6025, needs some more work)
-the subtitle renderer should have better geometry reinitialization after resizing a window.
-I've revised the renderer exit sequence, it should be able to properly switch from 10- and 8-bit exclusive modes to windowed mode and properly switch between files
-I've changed the presentation layout of the windowed mode to an additional swap chain, this allows somewhat faster resizing in windowed mode (it still resets only up to 2 times per second, and it will still resist resizing when a video is playing, but I'm working on fixing that)
-I've started to do on some repair work on the VSync functions (again), mostly to get multi-threading more efficient

Did you talk with the team about asking that nonstandard YCC driver mode from AMD?I've only heard about the D3D Ex overlays the last time, and that's not what I'm looking for. I'll try to find out more from the hardware manufacturers and other parties for information in a while, when I have the time and a testbed to actually test and debug code for such a function.

[Stephen R. Savage]

JanWillem32, this probably doesn't have to do with any code you've written, but could you look into this:

On my Intel X3100 GMA, which has ridiculously bad drivers (most things D3D-related cause crashes/BSOD), when I use EVR-CP with D3D Fullscreen, the graphics drivers crash on exiting fullscreen, but EVR-Sync and MadVR can be used in exclusive mode without problems. This happens in both trunk and your tester builds.

Do you have any ideas what EVR-CP could be doing differently to trigger this?

Edit: Also, would it be possible to implement a seamless switch between exclusive fullscreen and shared windowed mode like MadVR does? D3DFS GUI support has never worked, making it hard to seek in exclusive mode.

[Hera]

Noticed that bringing up the seek bar (non D3D, but fullscreen mode) resizes the video.
This, now, produces a pause and squishes the video. Neither of the two are wanted. GUI should be drawn on top of video.

[JanWillem32]

@Stephen R. Savage: If the exit method of EVR Sync works, I can simply copy-paste it. The code of the shared renderer is pretty much the same as EVR Sync, except for the mixer parts and the Sync clock. I'll test if it works on a debug build for me. If it does, I'll upload a quick build.
I've been wanting to edit the switch to exclusive mode for a while, too. I'll ask if that's okay while the exclusive mode still can't be closed by an on-screen close button. Last time, people thought it was too risky for new users.

@Hera: I've asked how to make the seek bar and menu bars in the fullscreen windowed mode behave like the right-click menu. I also think it's wrong that those currently shrink the drawing area, instead of overlapping it.

[CruNcher]

-I've solved some fundamental problems in the subtitle texture management
-there should be less crashes by the subtitle renderer when resizing a window (typically error no. 6025, needs some more work)
-the subtitle renderer should have better geometry reinitialization after resizing a window.
-I've revised the renderer exit sequence, it should be able to properly switch from 10- and 8-bit exclusive modes to windowed mode and properly switch between files
-I've changed the presentation layout of the windowed mode to an additional swap chain, this allows somewhat faster resizing in windowed mode (it still resets only up to 2 times per second, and it will still resist resizing when a video is playing, but I'm working on fixing that)
-I've started to do on some repair work on the VSync functions (again), mostly to get multi-threading more efficient

x86 SSE: http://www.mediafire.com/?nzdzn958ghnhz5z
x86 SSE2: http://www.mediafire.com/?piw9pcb278dccnn
x64: http://www.mediafire.com/?8a819jj1b46imit

I've only heard about the D3D Ex overlays the last time, and that's not what I'm looking for. I'll try to find out more from the hardware manufacturers and other parties for information in a while, when I have the time and a testbed to actually test and debug code for such a function.

Puhh stable again doesn't crash and output is correct no zooming no Desktop mirroring :)

[CiNcH]

I just had a look at the old scaler pixel shader (e.g. the old Bicubic) integration into the D3D renderer code. Vertex texture coordinates are not normalized when using those. Why is that? I thought that texture coordinates in D3D always had to be normalized!?

[JanWillem32]

@CruNcher: That's good to hear.
I've verified that my PC still throws the memory reference at 0 error when switching files, so that problem isn't completely solved. It's about 1 in 8 times. I'm still working on that.

@CiNcH: The vertices only have to be normalized to the interval [0, 1] if neither vertex or pixel shaders adapt it. In the case of the resizers, the texture coordinates are changed inside of the pixel shader before sampling the texture (which indeed uses the interval [0, 1]).

[CruNcher]

Though it now beahaves crazy anyways it now doesn't crash or shows odd behaviour when using Software Rendering but as soon as i try to get it Display (VMR9 Renderless + YUV Mixing) via either a DXVA or Nvcuvid based Decoder it crashes on load of that file Software Decoder like Lav Video, ffdshow or others work :(

[JanWillem32]

VMR-9 mixer mode gave me some problems in the past. Have you tried to disable it?

[CruNcher]

VMR-9 mixer mode gave me some problems in the past. Have you tried to disable it?

Nope crashes as soon i try to render something Hardware accelerated no matter if Mixer mode on or off or Yuv Mixing :(
The Beahaviour is really crazy it plays 1 time Software rendered and then even Hardware but in the next try it crashes severall times and then it works again, really weired it's really like a lottery Game :D

Hehe the probability that something Software Decoded plays without a crash though is higher then Hardware accelerated and if something played Software Decoded the probability that right after playback playing something Hardware accelerated works without a crash is quiet High , though after that it becomes random again :D

Also it seems only VMR9 Renderless is affected VMR9 windowed and VMR7 Renderless doesn't crash either way Software/Hardware Playback (absolute stable)

Ahhh i tried something i unchecked "10 Bit RGB output" it was checked and after that even Software playback always crashed checking it again started the Randomness again :)

Thoug i cant be even sure that this was a real experience or Random as it now crashes again even with Software playback all the time on load with "10 Bit RGB output" checked, just to crazy :D

PS: Wow now the MPC-HC window just closed no crash the application just terminated itself :D

[JanWillem32]

VMR-9 windowed is an almost completely external object in a system DLL. VMR-9 renderless is only using the mixer part of it, the rest is completely internal. I'd love to get rid of the mess of external mixers for EVR Sync, EVR CP and VMR-9 r.. (There are also external parts for the RealMedia and Quicktime components, but I haven't even completely tested those in my builds.) A custom mixer component would save me a lot of trouble with debugging this kind of thing, and make all the resources of the mixer controlled in the player itself.

Have you tried to delete the entire registry key and/or remove the .INI file to reset all settings? (Make a backup first.)
Some settings from the trunk build or older versions might conflict.

[CruNcher]

Reinitialization doesn't help its just luck if it plays something without crashing on load with VMR9 Renderless in the current test build :(
3 times ok (even used closed) 4th time crash

[JanWillem32]

Let's try a debug build.
These builds are really slow, usually fail at rendering subtitles, and usually don't have the same bug characteristics of a regular build, but they might indicate what's going wrong in some cases.
You can capture system traces with DebugView (no setup required at all): http://technet.microsoft.com/en-us/sysinternals/bb896647 .
Other status indications are recorded in the system log. Run "eventvwr.msc" to view those.

[Stephen R. Savage]

@Stephen R. Savage: If the exit method of EVR Sync works, I can simply copy-paste it. The code of the shared renderer is pretty much the same as EVR Sync, except for the mixer parts and the Sync clock. I'll test if it works on a debug build for me. If it does, I'll upload a quick build.
I've been wanting to edit the switch to exclusive mode for a while, too. I'll ask if that's okay while the exclusive mode still can't be closed by an on-screen close button. Last time, people thought it was too risky for new users.

@Hera: I've asked how to make the seek bar and menu bars in the fullscreen windowed mode behave like the right-click menu. I also think it's wrong that those currently shrink the drawing area, instead of overlapping it.

Thanks. I look forward to a test build, as this has been bothering me for a while (though, of course, all blame originates at Intel).

Couldn't you make videos still start windowed even when D3DFS is turned on? Just have it switch to exclusive on fullscreen when the option is toggled and to normal fullscreen otherwise.

[Jtacdf]

@JanWillem32
After testing 3652r, here are some feedback.

Switching between files in D3DFS 10-bit does not crash anymore, but after sometime opening/closing several files, I experience the old black screen issue upon closing.
I will still experience very random crash once in a while when switching files.

[tetsuo55]

Thanks. I look forward to a test build, as this has been bothering me for a while (though, of course, all blame originates at Intel).

Couldn't you make videos still start windowed even when D3DFS is turned on? Just have it switch to exclusive on fullscreen when the option is toggled and to normal fullscreen otherwise.Please also open a support ticket over at Intel and your motherboard manufacturer's brand.
Intel puts high priority on fixing issues with mpc-hc in their drivers, but they cannot fix what they don't know about.

[JanWillem32]

@Stephen R. Savage: I'll try to work on a function to simply switch the exclusive mode on a user command first. It's unfortunately buried deep in some menu structure. Like the four other functions I want to add to the menus, it will take some time. Editing those is pretty new to me, and I can't always get them to work.
@Jtacdf: That sounds like a good chance to try the debug build. Maybe you can find anything useful from the system traces and logs with it.

[Jtacdf]

@JanWillem32
I've narrowed down the source of my issues. Seems to be the mpc-hc internal sub renderer thats causing it.
From this post,http://forum.doom9.org/showthread.php?p=1519639#post1519639, I thought I might as well disable the internal subtitles renderer.
After opening/closing more than 10 files, I could not replicate my issue at all until I enable the sub renderer and just like magic, black screen after 2-4 files.
Tested on debug sse2 3652r and 3652r sse2 normal build. Both responded in the same manner to this issue.

[Stephen R. Savage]

Please also open a support ticket over at Intel and your motherboard manufacturer's brand.
Intel puts high priority on fixing issues with mpc-hc in their drivers, but they cannot fix what they don't know about.

The X3100 has been out of support for a long time -- there hasn't been a driver update since Windows 7 originally released. Same with my laptop model that came with it.

[CruNcher]

Let's try a debug build (x86 SSE2): http://www.mediafire.com/?zqsdshhep64564p .
These builds are really slow, usually fail at rendering subtitles, and usually don't have the same bug characteristics of a regular build, but they might indicate what's going wrong in some cases.
You can capture system traces with DebugView (no setup required at all): http://technet.microsoft.com/en-us/sysinternals/bb896647 .
Other status indications are recorded in the system log. Run "eventvwr.msc" to view those.

Nothing unusual just the whole Graph search dshow finding the right Splitter/Decoder and then after VMR initialization the crash no info about that as it crashed their :(

[tetsuo55]

The X3100 has been out of support for a long time -- there hasn't been a driver update since Windows 7 originally released. Same with my laptop model that came with it.You can always try, intel even has support through a chat-client on their website. Once enough people contact them about an issue they will act.

[tetsuo55]

And your laptop is probably out of warranty?

If it came with Win7 then you might still have a chance depending on the manufacturer. Like in the case of my company (we dont make computers), we are forced to provide firmware updates for the hardware we sell regardless of actual warranty of said hardware. Even if its 10 years old.

Some other manufactures might follow the same guidelines.

[CruNcher]

@JanWillem32
could you upstream your VMR9 OSD changes (current Decoder Display) to MPC-HC trunk and would it be possible to add Splitter and Audio Decoder ? :(

[JanWillem32]

I can add any function that doesn't change a renderer stage to the trunk build. The current decoder information is imported from the mixer pin, that only has video information. To import information from other pins I'd have to add completely new code to read information from the filter graph parts. I'm not too keen on editing that just yet.

[JanWillem32]

A full set this time, with only small changes from the previous version.
I've made some minor optimizations to the render queue, VSync functions and resource management.
Because of the changes to the renderer queue, I can now add temporal functions. Ideas and information for improving or making new temporal functions are very welcome.
The first I've added is the "Constant Frame Interpolator". It's a heavy filter that interpolates frames to match the screen refresh rate, using a windowed function on 4 (nearly finished) frames. I'm still looking at optimizations for reducing artifacts and to improve its speed.
This function has some special properties:
-Linear input from a custom pixel shader is required. The subtitles are automatically adjusted with a gamma 2.4. The output from the interpolator is adjusted by 1/2.4 to match.
-"VSync", "Accurate VSync" and the "GPU Control" settings are incompatible with this filter, as these (currently) interrupt the rendering queue.
-As usual, exclusive mode will have a much better control over timing all frames.
-Because of heavy color blending operations, enabling "Half Floating Point Processing" or "Full Floating Point Processing" is advised.
-Color management and dithering is applied after the interpolation step when enabled.
-The custom pixel shaders, subtitles, stats screen and OSD are not updated for every output frame.
-The tearing test can be used to see if frames are presented at every screen refresh.
-When the display frame rate is close to the video frame rate (a factor of 1.5 or less), artifacts will be severe.
-One of the most visible artifacts is the fade-in&out effect in paused mode.
-Another type of artifact can be seen as a faint trail, following moving objects on screen.

[JanWillem32]

I found several memory/other resource leaks inside the renderer core, I've been trying to solve those. The EVR and VMR-9 mixer parts will probably need a similar inspection. I didn't find anything special inside of EVR Sync's code for creating or destroying devices in fullscreen mode, that would explain the lack of crashes on exit. The exit sequences for the mixer and renderer parts are almost the same, only the sequences of the VSync functions are very different.

[Hera]

Will these "temporal functions" delay the merging your fixes with trunk?

[JanWillem32]

I've written a few basic deinterlacers and two types of frame interpolators ages ago. Integration and writing menu functions did take some time, but it should work properly now.
I can start merging changed renderer stages, settings and other items that are sensitive to problems, once I've repaired the on-line version of the branch I'm working on, verified that my builds are at least at or below the general problem level of the version in the trunk and I can convince the development team that my code is ready to go into the trunk. Non-critical functions that are not yet 100% optimal are okay to add, as long as these don't break the critical ones.

[Jtacdf]

@JanWillem32
Here are some feedbacks on 3682r

3682r AVX seems to fix the black screen on closing files and the random crash. Thanks!
Congrats for taking the first step in adding a dedicated hardware/gpu constant frame interpolation.
Just a suggestion, but you might want to have a few presets for different types of video unless you can get it perfect in a single preset. Trailing Artifacts is of course very obvious with fast action scenes.

[nevcairiel]

While i understand the fun in implementing new and exciting features, if you don't finish the fixes and cleanups first, and produce a new version *without any regressions*, your changes will *never* be merged into the trunk.

Just saying.

[Hera]

Crashes on exit on netbook.

[JanWillem32]

@Jtacdf: Good to hear that. It was quite a lot of work to edit the subtitle renderer's exit sequence. It had a problem with properly deleting items in video memory.
Are the AVX instructions any good with floating-point heavy math in MPC-HC? I can't test it, but maybe you can test if the CM is any faster when generating a 256³ LUT.
I can add presets easily, once I've found some more information about different implementations and the math/code used for those. I didn't find much yet, and it was all pretty obscure.

@nevcairiel: It's been about a month since I could actually reproduce a reported problem myself. The only fixes I've made lately are by guessing what was causing the problems. The only thing I've really broken is EVR Sync, and that's only because the code merge is incomplete. I was so bored that I've even started to work on the ISubPic parts and the actual subtitle engine. I also have several other extra functions lined up: a background color selector, an extension for the frequency changer for the exclusive mode, 15 color controls, a new function for saving fully-rendered images from the renderer and some video mixer parts. Except for the mixer parts, the only implementation issue I have is that I don't really know how to add them to the menus.

@Hera: Which version do you use? Is it in exclusive mode only? Are there any errors reported (also look in the system log)? Is this a new problem?

[Jtacdf]

@Jtacdf: Good to hear that. It was quite a lot of work to edit the subtitle renderer's exit sequence. It had a problem with properly deleting items in video memory.
Are the AVX instructions any good with floating-point heavy math in MPC-HC? I can't test it, but maybe you can test if the CM is any faster when generating a 256³ LUT.
I can add presets easily, once I've found some more information about different implementations and the math/code used for those. I didn't find much yet, and it was all pretty obscure.

There isn't any visible difference I could see in speed between the AVX and SSE2 version. I just thought that AVX might run quicker. Guess I assume wrong.
Both took about 7 seconds to generate a 256³ LUT. At any rate, 7 seconds is a big step up from the 'feels like forever' generating when CMS LUT was first introduced in your build.
FYI, 128³ LUT generated immediately when I open a file.

[JanWillem32]

Well, I guess you wouldn't notice any speed gains at 7 seconds. It's probably the writing of the file that's producing by far the most delay. The CM is set up to specifically prefer output of continuous files. It takes a while to find and allocate a continuous 128 MB with the operating system and the file system, and then write the file at that location.
For other people using the CM and still think it's a little bit slow, I'll try to make it multi-threaded in the future.

[G_M_C]

While i understand the fun in implementing new and exciting features, if you don't finish the fixes and cleanups first, and produce a new version *without any regressions*, your changes will *never* be merged into the trunk.

Just saying.

QFT

Inderdaad, één ding tegelijk.

Renderer improvements + shader work first, maybe combined with subtitles. These tings are useful for most people. Other things like CMS affect progressively less and less people. Adding features can be done later.

[CiNcH]

@JanWillem32,

did you ever profile compiling a shader? I am just curious because the renderer code still performs string replacement and shader compiling each and every frame cycle.

[Hera]

Crash on exit STR,

1. D3DFS
2. Open File
3. ALT-F4


Problem signature:
Problem Event Name: BEX64
Application Name: mpc-hc64.exe
Application Version: 1.5.3.3682
Application Timestamp: 4e51a488
Fault Module Name: mpc-hc64.exe
Fault Module Version: 1.5.3.3682
Fault Module Timestamp: 4e51a488
Exception Offset: 00000000009dd3a8
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 415d
Additional Information 2: 415d47caa1eae30530a1465331992e7f
Additional Information 3: de4a
Additional Information 4: de4a8cb134c5e1df28e33fa8c2c8c7d1

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

[JanWillem32]

@G_M_C: Actually, I also have 2 other projects I'm working on, and I also have hobbies (including actually using MPC-HC for media, of course). Generally, the added features simply work fine. The biggest issue reported at the moment was reported by Hera. And even with that problem, I consider the flaws in the trunk build somewhat worse.

@CiNcH: The pointers to the pixel shaders are regularly evaluated to check if compiling is necessary. I actually wanted to improve the compiling system to use more string replacements. The current system uses registers to pass the size of the texture to the shader:
float4 c0 contains width, height, frame counter, clock in seconds
float4 c1 contains 1/width, 1/height, 0, 0
A more efficient model would be to use string replacement for the static width and height, as those can be integrated into the shader assembly itself:
float4 c0 contains frame counter, 0, 0, 0
float4 c1 contains clock in milliseconds, 0, 0, 0
#define width _WIDTH_
#define height _HEIGHT_
For the resizers and the final pass section this is already in use. (With some extras.) The problem for custom pixel shaders is that it would break compatibility with other players.

@Hera: Thanks for the error report. I can't replicate the problem, but BEX errors are usually related to memory buffer overflow problems, so I'll search for those first. Is this issue new? Does the same happen with the internal key commands for exit (default Alt+X) and close (default Ctrl+C)?

[Hera]

Can't reproduce without D3DFS using ALT-F4.
Can't reproduce with ALT-X or CTRL-C.

Not sure if new.
EDIT: Exists in 3652
EDIT: Exists in 3600

[JanWillem32]

Thank you. So it seems the player tries some sort of unsafe quick exit when using Alt+F4, but uses a normal exit with the key commands. I wonder how I could debug this. I'll first take a look at what the player does differently with Alt+F4 compared to Alt+X. I hope it doesn't take too much work on the main framework or the graph builder to solve it this time. If the method is really unsafe, I think the trunk build has to be patched as well, as I didn't edit these parts of the code at all.

[nand chan]

Does this build of MPC-HC contain any changes to the internal subtitle renderer?

There seems to be a bug with the official version when fullscreening on a 1920x1200 display, where bitmap subs are displayed 60 pixels too high (as if the video was top-bound).

[JanWillem32]

I've fixed quite a few things indeed on the highest level of the subtitle parts (and broken many parts in the process, as you can read in this thread). Currently, I've been able to reproduce two problems specific to the geometry of bitmapped subtitles:
-If I use WinKey+left or WinKey+right to position the player half-left or half-right on the screen with Windows 7, the bitmapped subtitle is compressed and shifted in a wrong way on screen (similar problem as you describe). This is a low-level geometry issue. I haven't changed those parts of the code yet.
-If two instances of bitmapped subtitles should be displayed (blu-ray has this capability), only one is presented. That's probably a problem on a somewhat higher level.

I've been trying to separate the parts responsible for bitmapped and vectorized input. Both need very different approaches to rendering. It's unfortunate that the two are currently mixed. The subtitle renderer really needs a team of developers again.
An issue with vectorized subtitles can be seen with my version of EVR Sync (I know it doesn't render correctly). The vectorized renderer tries to make a rectangle that will fit all subtitle parts of one frame in a single picture, using the CPU to perform the blending with 4-bit, 6-bit and 8-bit RGB samples (horrible color quality indeed). Sending each element and let the GPU do it's work on layering them onto the destination picture would be a lot better. It avoids using the big, empty texture parts. Using the vector renderer of DirectX 10/11 would also be nice.

[nand chan]

I've fixed quite a few things indeed on the highest level of the subtitle parts (and broken many parts in the process, as you can read in this thread). Currently, I've been able to reproduce two problems specific to the geometry of bitmapped subtitles:
-If I use WinKey+left or WinKey+right to position the player half-left or half-right on the screen with Windows 7, the bitmapped subtitle is compressed and shifted in a wrong way on screen (similar problem as you describe). This is a low-level geometry issue. I haven't changed those parts of the code yet.
-If two instances of bitmapped subtitles should be displayed (blu-ray has this capability), only one is presented. That's probably a problem on a somewhat higher level.

I've been trying to separate the parts responsible for bitmapped and vectorized input. Both need very different approaches to rendering. It's unfortunate that the two are currently mixed. The subtitle renderer really needs a team of developers again.
An issue with vectorized subtitles can be seen with my version of EVR Sync (I know it doesn't render correctly). The vectorized renderer tries to make a rectangle that will fit all subtitle parts of one frame in a single picture, using the CPU to perform the blending with 4-bit, 6-bit and 8-bit RGB samples (horrible color quality indeed). Sending each element and let the GPU do it's work on layering them onto the destination picture would be a lot better. It avoids using the big, empty texture parts. Using the vector renderer of DirectX 10/11 would also be nice.

Just tested it using your latest build,

Now, bitmaps are aligned /vertically/ but they're 60 pixels too far to the right, heh.

Edit: I spoke to soon, it was set to “touch window from outside” instead of “touch window from inside”. The same problem occurs, 60 pixels too high, when it's set correctly.

Also, some interesting observations:
- If setting the frame to “half size” or “double size”, it lines up perfectly, but at “normal size” it doesn't.

[JanWillem32]

Is the behavior the same with the shared renderer (VMR-9 r., EVR CP, DirectX 9 QT, DirectX 9 RM) and the other renderers? (The geometry parts are different.)

[nand chan]

Is the behavior the same with the shared renderer (VMR-9 r., EVR CP, DirectX 9 QT, DirectX 9 RM) and the other renderers? (The geometry parts are different.)

The behavior is the same (60 pixels too high) using VMR-9, EVR CP, EVR Sync, Haali Renderer as well as madVR using both your build 3682 and the vanilla 3696.

[Jtacdf]

Hmm. I don't have any problem on screen aligment with bitmap based pgs subtitles.

@nand chan
Have you check the aligment and margins setting in mpc-hc? Mine are a value of 20 for all setting and the position subtitle relative is a tick.

[nand chan]

Hmm. I don't have any problem on screen aligment with bitmap based pgs subtitles.

@nand chan
Have you check the aligment and margins setting in mpc-hc? Mine are a value of 20 for all setting and the position subtitle relative is a tick.

Changing the number seemingly has no effect, changing the screen alignment also seemingly has no effect (I'm guessing these are overridden by positioned ASS subs).

If “position subtitles relative to the video frame” is fully checked, subs appear 60 pixels too high.

If it is half-checked (filled out) or not checked, then subtitles appear too tall, but otherwise in the right position (they get stretched to the full 1920x1200 surface)

[Jtacdf]

What about the max texture resolution for subtitles? As far as I know, it will resize the subtitles to whatever chosen resolution on vanilla build.
Setting it to desktop on my monitor possess no problem for me, it has a aspect ratio of 16:9.
You have a monitor that has a aspect ratio of 16:10, might that be the issue here?

[nand chan]

What about the max texture resolution for subtitles? As far as I know, it will resize the subtitles to whatever chosen resolution on vanilla build.
Setting it to desktop on my monitor possess no problem for me, it has a aspect ratio of 16:9.
You have a monitor that has a aspect ratio of 16:10, might that be the issue here?

Same thing happens when rendering to 1920x1080, with or without round up to powers of two.

If I set the subtitle resolution to 1920x1080 and choose not to position subs relative to the video frame, I get a vertically stretched subtitle again, in all renderers.

I've mentioned in my first post that I'm using a 1920x1200 monitor, which has an aspect ratio of 8:5.