MPC-HC tester builds for internal renderer fixes

[Hera]

D3DFS works now again.

[JanWillem32]

With which one of the two edited versions do you mean?

[Hera]

I think that ones in post #200 & #196 work.

[JanWillem32]

Did enabling the 10-bit output in exclusive mode crash the player?

[Hera]

Did enabling the 10-bit output in exclusive mode crash the player?

Well I don't use that setting but yes, yes it did.

[JanWillem32]

Thank you, although that means that I still have to fix that problem. I've used several methods to detect 10-bit display output capability already, and none of them work.

[TheElix]

What's up with subtitle renderer? On same settings in MPC-HC:
EVR CP: http://rghost.ru/15318001/image.png
madVR: http://rghost.ru/15318061/image.png
(don't mind Russian, haha)

[JanWillem32]

Can I have a sample of the .ASS, .SSA or ,SRT embedded item?
I haven't seen distortions like that yet, and as far as I know, the same sampling and alpha blending render states are used.

[TheElix]

These are external .srt, nothing irregular.
1
00:00:11,596 --> 00:00:14,098
Как веснушки эти ненавижу я

2
00:00:14,223 --> 00:00:17,059
И вздыхаю, только новую завижу я.

3
00:00:17,393 --> 00:00:19,729
Любовь на плечи тяжким грузом давит,
Basically, your version has no shadows and a very thin outline for some reason.

[JanWillem32]

The .SRT text subtitle works for me (saved as UTF-8). The text looks as it should.
What settings do you have in the "Default Style" tab of the options menu? What do you see during playback in the "Play", "Subtitles", "Styles" menu? Does editing the style or using "Reload" under "Play", "Subtitles" work?

[TheElix]

Here're my settings (http://rghost.ru/15422941). I've always used them and have never experienced this before.

[JanWillem32]

Does the same layout for the default font appear during playback in the styles menu?
The next question would probably be about how does it fare with styled .SSA or .ASS subtitles, but I'll probably have to look for a suitable sample for that...

[Sievert]

Hi JW

Would chroma interpolation shaders work as efficient on interlaced sources?
If using NV12 output in the decoder, either dxva or software, is it correct to use "optimized for floating point surfaces" in the case you're using Full Floating Point Processing? Can you elaborate on the use of the 3 chroma shaders available, depending on the Presentation settings?

Thank you for your work so far.

[TheElix]

Here're embedded styled subtitles.
EVR CP: http://rghost.ru/15469531/image.png
madVR: http://rghost.ru/15469571/image.png

[JanWillem32]

@Sievert: Chroma up-sampling is normally done as one of the first things in a mixer (sometimes several stages before deinterlacing). Only the weave and bob deinterlacing types don't interpolate in a way that it distorts chroma. That means that the chroma up-sampling "trick" I made can be used to up-sample original 4:2:2 sources with weave and bob deinterlacing types. For the vertical stage of 4:2:0, the sampling distance has to change from 2 to 4 pixels to make that one work, too. The problem is that bob deinterlacing exists only as a last resort for if a previous deinterlacer failed. Weave is normally only activated on sources that are progressive-inside-interlaced. There are 3 common types of this (ignoring NTSC 1/1.001 rates at the moment): 24p or 30p content inside 60i, or 25p inside 50i. Many TV streams feature actual "hard" interlacing, generated by converting 60p to 60i and 50p to 50i. Those can't be weaved without heavy artifacts, so most deinterlacers do an adaptive form of frame interpolation.
The chroma interpolation shaders I wrote are an imperfect solution to the problem. I have plenty of filters ready to make all mixer stages work without those of EVR or VMR-9. I just never managed to get either of both output a completely unprocessed sample for me to work on. It would be very nice to be able to choose the resizers for chroma up-sampling, video image and bitmap-based subtitles. (That last one is in a testing phase.) The same thing for other filters, such as color controls, too.
For when it matters, I've made special shaders for when FFPP and HFPP are enabled. Those make more efficient use of the format. For the new line of chroma interpolation shaders, I'm only keeping the optimized forms, and the single-pass bilinear filter.

@TheElix: The blending stage looks okay to me. The only thing I can think of is that something is overwriting the styles. Can you check the "Styles" menu? You can also reset all settings temporarily by using :
REG EXPORT "HKCU\Software\Gabest\Media Player Classic" "%USERPROFILE%\Desktop\settings.reg"
REG DELETE "HKCU\Software\Gabest\Media Player Classic"

That way, full settings are saved as settings.reg on the desktop, and the registry is cleared. You can always run the settings.reg to set up the old settings again.

[kostik]

Hey!
When playing a movie with CMS enabled I get strange "color artifacts" specially on white . Tried disabling and changing settings in CMS and nothing helps but disabling the CMS. Tried disabling 10 BIT, playing in FS mode, nothing works.
see please the pics .
Thanks

[JanWillem32]

Some time ago, janos666 sent his profile so I could see it too. I believe it's the gamma + matrix type profile that's giving problems. I use a XYZ LUT + matrix profile and had never seen the problem of that type of color artifacts before. We are already assessing whether it's a problem in the implementation, or if there's something wrong in the profiles themselves. I'm not very sure yet what it is, unfortunately.

[kostik]

Some time ago, janos666 sent his profile so I could see it too. I believe it's the gamma + matrix type profile that's giving problems. I use a XYZ LUT + matrix profile and had never seen the problem of that type of color artifacts before. We are already assessing whether it's a problem in the implementation, or if there's something wrong in the profiles themselves. I'm not very sure yet what it is, unfortunately.

Where can I find a good profile with d65 and 2.2 gamma?
Can some1 upload pls.

[JarrettH]

I haven't tried these builds, but do you know when the new resizers will be incorporated? Right now there's just bilinear and bicubic right?

[Hera]

IMO, when this work will be incorporated, I think a new major release is justified (post-testing on main branch).
Any work on fixing the pixelated upscaled video when opening a file the 1st time?

Been testing subtitles with animation turned on,
- Only one file I know caused the EVR to stutter
- When there are supposed to be animated subs on top while at the same time on the bottom stationary subs, stationary subs blink when top subs animate karaoke style (need to test against VLC or something... eww, but will do it... for science!)
- When subs are on the screen (not animated, not even changing) - the graph is a bit more bumpy

[JanWillem32]

@kostik: Device color profiles are unique for each device. They normally don't last much longer than a month, too. The people that don't have a hardware tristimulus colorimeter or spectrophotometer can still use applications to generate a basic profile.
Windows 7 has one integrated: http://windows.microsoft.com/en-US/windows7/Calibrate-your-display . There are plenty of other applications that can help set up a display device, too. I must note that many are set up for a video gamma of 2.2, while video is encoded in studios at gamma 2.4. (It's a bit of a user preference, though. I've had pretty impressive results on even my gamma 2.6 monitor.)

@JarrettH: The list of resizers is to be expanded even a bit more. The resizers I made will never work with the version of the rendering engine that's in the trunk build. Integration of these new resizers will be simultaneous with this version of the renderer.

@Hera: The "pixelated upscaled video" problem is actually pretty old. The trunk build does it too, but that one doesn't re-use it's vertex data for every frame cycle. The problem is that the first frame is generated with a completely wrong rectangle. Was I correct in my assumption that the exclusive mode does initialize correctly?
I've made performance optimizations again for the subtitle blending part and VSync, so those things might help smoothing out the rendering speed. I'll do some quality checking later, when I'm free today.
A few months ago, a video in the main MPC-HC thread was posted that caused that blinking issue with my PC, too.
I unfortunately don't have it anymore. (It was a video with Latin LTR letters on the top and bottom sides and Kanji TTB ideographs on the side. It was only a SD video, but had karaoke animation that dropped about one in four subtitle frames for me. It featured some Halloween theme made out of animated computer-drawn cutsheets. I think the name referenced an apple.) Samples like that are very welcome.

[ForceX]

A few months ago, a video in the main MPC-HC thread was posted that caused that blinking issue with my PC, too.
I unfortunately don't have it anymore. (It was a video with Latin LTR letters on the top and bottom sides and Kanji TTB ideographs on the side. It was only a SD video, but had karaoke animation that dropped about one in four subtitle frames for me. It featured some Halloween theme made out of animated computer-drawn cutsheets. I think the name referenced an apple.) Samples like that are very welcome.
lol xD Not Halloween theme, it's a fanmade Touhou video. I just happen to have that video. I do believe you mean this: http://www.megaupload.com/?d=SB6Y47LD

There are two animated subtitle tracks, the Complex karaoke one is the killer. I use it for my sub rendering stress test.

[JanWillem32]

Thank you, it's indeed still really heavy, but it only causes jitter of less than half a frame time on the latest development alpha. As there are 3 backbuffers, I have have more than 1 buffer to spare at any time.
The load on the subpicture buffer is great, too. This is the only video I have that can use up the 4 buffers I usually set. I don't have blinking animation anymore.

[Hera]

That one works just fine.

Here is a sample,
http://www.megaupload.com/?d=2MHYM170

exclusive mode does initialize correctly

[CiNcH]

Hi Jan,

I am just fooling around with your test builds a little bit. Where is one supposed to find your scaler shaders in the SVN? I just recognized that you have your own branch but can't find the scalers in there..

I also recognized that you have put a lot of your shaders under GPL lately. Guess that this does not mean that an application that can make use of those shaders also has to be under GPL, right? The way I understand a shader is that it is a self-contained program without a binary link to the application. Would you agree?

[JanWillem32]

The branch broke after a failed update. It did contain the set of resizers at one point. http://pastebin.com/Gn7Rq2ap
The GPL license is simply to exclude the information I generated from being taken by commercial works. This can by applied to any text, it doesn't really have to be application code. The license allows usage of the information for personal use and with other projects under compatible licenses.

[JanWillem32]

A lot of changes this time.
The Vsync functions are fixed. I'd still only use them in windowed mode without desktop composition, though. The automatic ones for the exclusive mode and windowed mode with desktop composition are pretty fine when used on their own.
I optimized allocation for the subtitle renderer, so that it can compensate for changes in frame rate even further. For example, when 3:2 pulldown is active.
I've tried to fix the issues with the video window size not initializing correctly. That might need more work in specific cases. (If someone knows a trick for this, please tell me.)
As there were a few bugs specific for x64, I've addressed those.
I've started the code merging with EVR Sync (still broken resizers, except for nearest neighbor). The few EVR mixer updates should provide some more reliability and maybe some faster code.
I'm in discussion of revising the image saving functions, color controls, a display rate changer for the exclusive mode, internal pixel shaders and hopefully a fix for the problem with the color management.
(Extra developers for some C++ code are very welcome, indeed.)

[Hera]

The pixelated upscaled gardbage video issue is not fixed.
Resizing doesn't always fix this issue either,
aside from the fact that resizing is slow.

Now it is *worse* - video fully stuck, fully stuck stretched (sometimes like someone set vertical resolution to 32k or something), fully stuck purple (purple happens before the video starts with your builds).
I managed to fix the purple and sound issue by skipping around.
Oh and subs play fine post-resize, when video is stuck.

D3D fullscreen stopped working now as well. Video is vertically stretched beyond belief - I see subtitles and vertical lines dancing.
Cannot be fixed by seeking around.

Haali is still broken. :/
All external codecs work with Haali though.
EDIT: No... my bad. No new issues with Haali, just internal filters.

EDIT:
This may be an issue with bilinear, switching to bicubic results in normal D3DFS. Will edit post further with additional details.
EDIT: It may help. I noticed opening the same file twice sometimes opens it fine the second time (non-D3D FS). On the other hand I had it open the second time with purple borders to each size and chugging at 10Hz
I managed to get D3D FS to work: either it has something to with resizer, turning off desktop composition, or pure random.

EDIT: I reset all the settings to default. Ran file - upscaled, pixelated, etc.
Then I turned on HFPP and the video fixed itself.
So toggling the Floating Point Options in Windowed mode seems to fix the video.
Toggling V-Sync in D3DFS does not do much.

EDIT: Purple borders, they were black before! Ugly.

Using bicubic + D3DFS seems to avoid the issue, without D3DFS - there is still an issue. Nearest Neighbor also works.

[cca]

Completely fails to open DVDs with the PS2.0a resizers, hangs or crashes.

[clsid]

Why are you merging code with EVR Sync? I thought the plan was to replace the existing custom renderers with a new one?

I think you are complicating things for yourself by trying to fix things with all features enabled. Implementing the renderers from scratch, one feature at a time, would probably be more structured and give a better end result.

Something like this:
1) Rip out the current custom EVR/VMR-9 renderers.
2) Implement a basic custom mixer (no shaders, d3d fullscreen, vsync, 10bit, or other fancy stuff yet). One renderer based on EVR, one on VMR-9. Code can of course be shared.
3) Implement subtitle support
4) Implement shader support. First for resizing. Then custom shaders.
5) Extend mixer with 10bit stuff.
6) Implement VSync algorithms.
7) make things work with refreshrate changing
8) Implement D3D fullscreen. But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?

[TheElix]

But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?Gimme DXVA and hardware deinterlacing with AMD cards then I'll think.

[JanWillem32]

@Hera: Thanks for testing so many things. I only wish I could open the debugger on every problem you face, to look inside the program. Sadly I can't reproduce all of the problems reported.
For the issue with Haali in combination with the internal codecs, I can't do much. I'm waiting for the branch for the internal codec fixes to finish. That one should have a better set of conversion options. Since the Haali renderer doesn't accept any 4:2:0 input natively, it usually depends on those converters.
I wonder why the initialization for the video and window rectangles fails in in some cases. I never changed any of the code for those parts. Maybe I should.
I can take a look at the one-pass resizers, I might have made an error specific for those two.
That switching HFPP fixes some things makes sense, as it triggers a full renderer reset (including even the mixer).

@cca: The VOB files I tested worked fine, can I have a sample? I might need to add an extra check for this case.
The resizers are automatically compiled to the maximum available target (PS 2.0, 2.0a, 2.0b or 3.0) in all cases. All two-pass resizers should have similar rendering properties.

@clsid: When janos666 suggested to make color the color management compatible with MadVR, I dismissed the idea. I don't intend to either use MadVR or re-create the rendering path of MadVR. I do have plans to change the working color spaces for the internal working surfaces, but that will have to wait after splitting up the renderers. (Working with an XYZ color space will require HFPP or FFPP to be enabled at all times, 8- or 10-bit integer surfaces just won't work. A lighter renderer can be added to fill the gap for the low-power or older systems.)
When a custom mixer is made, I automatically won't need VMR-9 anymore. EVR might still be useful for if Media Foundation interfaces are to be used. Otherwise, I won't need EVR, too. A custom mixer is on my wish list, but any earlier attempts to create one failed completely.
The internal renderer is in a pretty good condition. (EVR CP and VMR-9 r. share it, only the mixer is different). Once EVR Sync receives a similar rendering path as EVR CP, I can take a look at creating the VSync functions as switchable items, so I can merge them to one EVR custom renderer (and share them with VMR-9 r.). That should save a lot of trouble when working on the renderer.

[cca]

Nah, turns out if I try a couple of times it will start, but the video is messed up, regardless of the resizer selected. It's like it displays only the upper half of the frame zoomed. I think the problems with interlaced videos (which my DVDs are, PAL interlaced ones) persist. Still all versions since 3329, which works fine, are having these "hang" issues and are useless for DVD playback with the new renderer patches since they cannot display the video properly. Seems ok with simple 720p videos though.

[janos666]

Something like this:
1) Rip out the current custom EVR/VMR-9 renderers.
2) Implement a basic custom mixer (no shaders, d3d fullscreen, vsync, 10bit, or other fancy stuff yet). One renderer based on EVR, one on VMR-9. Code can of course be shared.
3) Implement subtitle support
4) Implement shader support. First for resizing. Then custom shaders.
5) Extend mixer with 10bit stuff.
6) Implement VSync algorithms.
7) make things work with refreshrate changing
8) Implement D3D fullscreen. But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?

Well, interesting to see the different opinions. My suggestions would be:

0: Leave the current renderers as is (well, finish the last few patches but don't start anything new based on them).
1: Start to write a new basic mixer: Nothing fancy, just something what can connect to the decoders, receive the YV12 data and pass through the unmodified 8-bit YCC 4:2:0 data to the renderer.
2: Once you got rid of the EVR mixer, start to build up a new DX11 renderer from scratch: quality and simplicity over anything else.

And yes, make it FP-only with intermediate XYZ step, like:
8-bit decoded YCC 4:2:0 -> FP16/32 linearized YCC 4:2:0 -> YCC 4:4:4 -> FP16/32 XYZ and do the additional resize and any custom filtering here -> FP16/32 RGB -> 8/10-bit dithered RGB output.

People with old hardwares already have the stock EVR mixer and renderer and here is this EVR mixer based custom renderer with many tweak-able functions.
But I think you need to to get rid of the EVR stuff if you want to target the "absolute high quality" grade. And I think it could be much more simple if you don't resist to support the old hardwares with the new renderer. (People with old hardwares already have many options but supporting the wide range of hardwares makes things much more complicated...)

Yes, it would be basically something like "recreating madVR" but with open source code. (+ 10-bit output and de-interlace functions ; if madVR won't have those function already when it will be usable...)

* De-interlacing should be done before the chroma resize.

--

And if there is any chance to do it then a separated renderer with real YCC 4:2:2 output (without anything else but a chroma resize step) would be nice too. But I know it probably won't happen any time soon (lack of hardware and driver support...) But what if we ask AMD about the possibilities with their current hardwares which support "fake" YCC 4:2:2 output already? I think there should be a way to fill the RGB buffers with the YCC data and tell the driver to output it as YCC 4:2:2 -> just like now but without the internal matrix conversion... (maybe by telling the driver to use our custom matrix or another hard-coded one for this task...)

[Hera]

Is the fonts supposed to be more blurry (less crisp) with the Haali Renderer?

[JanWillem32]

I'd love to write for a DirectX 11 renderer, and indeed the VMR-9 and EVR mixers are a bit of a problem with that (they won't synchronize with anything but DirectX 9). I would love direct write access to the RAMDAC (analog), TMDS (HDMI and DVI) and Mini-packet (DisplayPort) controllers. Unfortunately, neither DirectX or the display driver currently allow handles to those directly. The only thing I can output is a full-range 4:4:4 RGB surface back buffer. The back buffer is either directly signaled to the RAMDAC, TMDS, and Mini-packet controller as full-range RGB in 8-, 10-, 12-, or 16-bit depth, else it's converted by the display driver before sending. (I've only seen some 14-bit standards for cinema, broadcasting and studio interfaces, like the SDI links. The higher bit depths than 10-bit are available for DirectX 10 and newer.)

@Hera: The Haali renderer should use the texture resolution given by the subtitle menu option. The EVR CP and VMR-9 r. renderers in my build disregard the texture size options in the menu to prevent resizing in software mode by nearest neighbor. (There's still an alternative path for bitmap-based subtitles that includes resizing by the video card. I've added pixel shaders to this step in an experimental alpha build.) That could explain the difference.

[CiNcH]

I have yet another question, something that I do not fully understand...

I get some proposed media types from the EVR mixer. A DXVA connection provides X8R8G8B8 and NV12. But is there really a difference whether I set either of those as the mixer's effective output type? I mean I am handing the mixer a DX surface which is being filled with video data. Such a surface can't be NV12, can it? So what I am getting from the mixer is always RGB, isn't it?

[JanWillem32]

The list for the EVR mixer proposals are all input types, the output type and mixer working surface are bound to the D3D surface you set as output. It's indeed true that I've only seen RGB as output from the EVR mixer.

[CiNcH]

The list for the EVR mixer proposals are all input types
Hmm, you mean input for the mixer? So the output of the decoder?

I think you ask the mixer to get its output types via IMFTransform::GetOutputAvailableType (http://msdn.microsoft.com/en-us/library/ms703812(v=vs.85).aspx), so what you can get from the mixer as input for the presenter and then you set one of them. But it does not make sense to ask the mixer for NV12 due to DX surface limitations..

[JanWillem32]

It's the MediaFoundation or DirectShow stream output, so it's an input to the mixer (indeed from a decoder). NV12 is a valid surface type, hardware support for it is pretty good, too.
I recently edited this section, it starts at the moment at "CEVRAllocatorPresenter::GetMediaTypeMerit" :
https://sourceforge.net/apps/trac/mpc-hc/browser/branches/renderer_fixes/src/filters/renderer/VideoRenderers/EVRAllocatorPresenter.cpp

[CiNcH]

So when the presenter calls IMFTransform::SetOutputType (http://msdn.microsoft.com/en-us/library/ms702016(v=vs.85).aspx), it actually sets the decoder's output? And what the presenter gets from the mixer is always RGB?

From the code:
: (guidSubType == MFVideoFormat_RGB32)? 600// always rank RGB types lower than the rest of the types to avoid the many problems with RGB conversions before the mixer
Do you remember the chroma upsampling error with my HD 3650 we once discussed? I think that this is the discrepancy to the MS Standard EVR. MS Standard EVR gave me interpolated chroma while the MPC-HC custom presenter did not. I think it is a matter of what you set there and who performs the chroma upsampling (at least with ancient GPU's).

I may dust my HD 3650 off and try it out.

[janos666]

I would love direct write access to the RAMDAC (analog), TMDS (HDMI and DVI) and Mini-packet (DisplayPort) controllers.

Unfortunately, neither DirectX or the display driver currently allow handles to those directly.The only thing I can output is a full-range 4:4:4 RGB surface back buffer.

The back buffer is either directly signaled [...] else it's converted by the display driver before sending.

I am thinking about a relatively simple nonstandard solution.

The current AMD driver can convert the RGB backbuffer data to YCC and output it through the HDMI output.
They currently offer YCC 4:4:4 and YCC 4:2:2 modes.

What I say is that we may request a third driver mode: either an "YCC 4:2:2 passthrough" (which takes the significant values from the RGB 4:4:4 framebuffers and outputs them as YCC 4:2:2 without any addition conversion, like the current RGB->YCC matrix...) or a "Custom" mode which could be specified by the software (this way we could output both YCC 4:4:4 and 4:2:2 but I don't see the point in outputting YCC 4:4:4 because my concern is that many HDTVs convert everything back to YCC 4:2:2, so YCC 4:4:4 isn't better than RGB 4:4:4, and it would be more complicated...)

Do you think it makes sense to ask AMD about it? (I think their "driver team manager" is reachable with a mail - not a real tech guy but more like a "customer<->programmer relations guy", but he can ask the programmers...)

[JanWillem32]

@CiNcH: Nearest neighbor chroma fitering is a mixer output type problem. It happens when you set any other working surface for the mixer than X8R8G8B8 on ATi hardware. The issue is still present with the 10-, 16-, and 32-bit surfaces. (Not that I really care about it, I have better filters than the bilinear filter used by the hardware.) A custom mixer should eventually solve that. In the mean time, four types of custom pixel-shaded resizers should fill in the gap.

@janos666: I'd indeed like that.
I'll have to a close look at the functionality detection part, of course. Alternative output modes are also only going to work with exclusive mode, too. Careful attention must be used to re-initialize the desktop afterwards (remember the black screen issue after exiting 10-bit mode in the past).
The development team already has a few connections with hardware manufacturers. Quite a few fixes have been made because of code recommendations in the past. I'll see what I can dig up in due time.

[CiNcH]

So also when you try to set NV12?

[JanWillem32]

Sure, if the input format is chroma down-sampled and the working surface is X8R8G8B8, it's upsampled by a bilinear filter before RGB conversion in the mixer. With other working surface types, it's not.
The same thing goes for example with YUY2.

edit: I released a new build version.
It should at least fix an issue with the color management not initializing properly and make the single-pass resizers work again.
I added some checks for testing window sizes and detecting monitor changes.

[CiNcH]

Sure, if the input format is chroma down-sampled and the working surface is X8R8G8B8, it's upsampled by a bilinear filter before RGB conversion in the mixer. With other working surface types, it's not.
I even had the problem of skipped bilinear interpolation with X8R8G8B8 surface type with a HD 3650, see here (http://forum.doom9.org/showthread.php?p=1463132#post1463132).
With Standard EVR, chroma is interpolated. The point is that I think that Standard EVR sets the output type to RGB and not NV12, which solves the missing chroma interpolation for ancient GPU's.

[ForceX]

Subtitle positioning breaks when using internal subtitle renderer with VMR-7 renderless/Haali/madVR when resizing window. :/

With EVR CP/VMR9 Renderless, on my machine there's a definite gap when changing the window size while it seems to switch to nearest neighbour for a moment before it seems to reinitialize and resize. This is rather disruptive, and I believe this lack of reinitializing with Haali/whatever is the cause of the subtitle error. Can you fix it?

Edit: Actually the subtitle positioning error doesn't happen with your dfr3557 build, and since I don't have a vanilla MPC-HC build higher than 3557, I can't say if it is due to changes in the trunk going from 3557 to 3571. :(

[Hera]

Anyone experiencing an issue where most subtitles disappear?
For example someone posted Tohou Bad Apple MKV a few pages pack and with 3571 SSE2 I only get only the subtitles on the right of the screen.
Going back to default formatting seems to show the bottom subtitles.

Will update post if issue is on my side.
EDIT: Resetting settings doesn't work. Some subtitles simply do not show up, you can force them to with default formatting option.
Oh and opening the same file twice and changing subtitle options when playing can result in player crashing / not responding.

EDIT: Oh and might add that D3D + Bilinear PS 2.0 works. For Windowed, no luck. Opening the file twice fixes the issue though.

EDIT:
EDIT: Windowed more is much worse in performance, it is kinda crazy.

Oh yeah and Subs for Haali are bleeping HUGE and thus do not even fit on screen.

[ForceX]

Anyone experiencing an issue where most subtitles disappear?
Subtitle issues only happens with renderers not being worked on by JanWillem.

For example someone posted Tohou Bad Apple MKV a few pages pack and with 3571 SSE2 I only get only the subtitles on the right of the screen.
Going back to default formatting seems to show the bottom subtitles.
EDIT: Resetting settings doesn't work. Some subtitles simply do not show up, you can force them to with default formatting option.
Oh yeah and Subs for Haali are bleeping HUGE and thus do not even fit on screen.

Happens if you resize the window. Should be fine on the first opening size.

EDIT: Oh and might add that D3D + Bilinear PS 2.0 works. For Windowed, no luck. Opening the file twice fixes the issue though.
Works fine here in Windowed mode. Amusingly, trying to use Exclusive mode simply results in a crash for me.

[liquidsmoke]

Jan, with regard to ticket:1629, I just tried to extract one of your builds posted on mediafire with winrar:

! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in Authors.txt
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in COPYING.txt
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpc-hc64.exe
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpciconlib.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.br.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.by.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ca.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.cz.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.de.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.es.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.fr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.he.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.hu.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.hy.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.it.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ja.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.kr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.nl.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.pl.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ru.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sc.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sk.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sv.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.tc.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.tr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ua.dll