Subtitles not displaying correctly in MPC-HC

[Xirix]

I'm currently using MPC-HC with the CCCP. I'm using Haali as my Directshow output since my new graphics card is causing problems with the default.

Everything seems to work, however with .mkv files that have subtitles, I'm watching fansubs as an example, have some problems.

The subtitles show up fine when windowed, but as soon as I fullscreen they change and go out of place, and any other added translations, for instance writing positioned above Kanji, will also not be in the correct position in fullscreen, but will be fine when not in fullscreen.

I'm not sure what program I should be playing around with to get the settings correct, could someone help me?

[ikarad]

It's a bug with mpc-hc but Don't hope any correction of this bug because sub renderer is give up since many months (years) or you can give a patch to solve this bug.

Also, I have many bugs with mpc-hc sub renderer but these bugs are not corrected since two years for some bugs that I refer in the bug tracker. Tetsuo555 told me that nobody works and will work on these bugs.

Use ffdshow that works very well. It's the only good solution for subs that I find. It works very well for this moment with all subs in mkv and bluray subs

[Hypernova]

Wait, can you give an specific example (like file name; don't upload)? I've been using madVR lately but when I use EVR-CP with MPC-HC internal sub renderer everything's fine. Actually, it is ffdshow subtitle renderer that doesn't work well on effects.

[Xirix]

Hi, in regards to the first reply, I am using FFDShow, it's part of the CCCP.

I can give a specific example, but it's happening on all the .mkvs I've tested. SGKK's Bleach episodes.

I'm open to suggestions, Haali as I said has been working fine as my output directshow otherwise. Oddly enough the Default Renderer works fine with .mkvs, but I really don't want to have to switch constantly whenever I play different filetypes.

If there isn't an apparent fix, is madVR easy enough to set up?, I know you need to download it seperately, and I've heard it's the best thing to use with MPC-HC.

[sneaker_ger]

Look here:
http://www.abload.de/img/subds9e.png

[namaiki]

Might you happen to have the following option ticked?
View-> Options-> Playback-> "Auto-load subtitles"

If yes, then please untick that and/or do a reset of all settings by ticking the reset and re-register options on the second page of the CCCP Settings application.

Make sure that DirectVobSub is being loaded in the Play-> Filters menu in MPC-HC.
If it is not, then untick the following:
View-> Options-> Playback-> "Auto-load subtitles"
Add DirectVobSub(auto-loading version) to the View> Options> External Filters list in MPC-HC as Prefer.

That is, if the above (http://h-4.abload.de/img/subds9e.png) doesn't have the same effect.

[sneaker_ger]

That is, if the above (http://h-4.abload.de/img/subds9e.png) doesn't have the same effect.

Yes, both things should work. In my proposal the internal renderer will be used and in namaiki's DirectVobSub will be used, like it is the already the case when using the default renderer. (MPC will only use its internal subtitle engine for renderers with two asterisks behind the name (" ** "))

[ikarad]

Wait, can you give an specific example (like file name; don't upload)? I've been using madVR lately but when I use EVR-CP with MPC-HC internal sub renderer everything's fine. Actually, it is ffdshow subtitle renderer that doesn't work well on effects.

here (this bug exist since two years and the start of support of pgs subs)
http://sourceforge.net/apps/trac/mpc-hc/ticket/48

And here is others problems like subs not rendered very well with some ass sub files. With ffdshow I never had problem until now.

Do you have an example of subs that doesn't work with ffdshow?

[Xirix]

Ah, thanks for all the input guys, unticking Auto-load subtitles fixed it. :) Now I can enjoy my new computer install a lot more.

[V!roX]

Hi, I also have a problem with the internal Sub Renderer of MPC-HC. Just like OP, some sub effects won't work in fullscreen mode. I attached a picture to show my problem.

ffdshow tryouts doesn't render the subtitles either, so I am using DirectVobSub now, but this eats my CPU alive.

I would really like to use the Sub Renderer of MPC-HC, is there a patch I can get to fix it?

This is how it looks like with Sub Renderer of MPC
It works fine on windowed mode...

http://img6.imagebanana.com/img/w7gnpcnp/thumb/aasd.jpg (http://www.imagebanana.com/view/w7gnpcnp/aasd.jpg)

Here is what it looks like with ffdshow btw:
http://img6.imagebanana.com/img/siq34xmb/thumb/4.jpg (http://www.imagebanana.com/view/siq34xmb/4.jpg)

I'm using MPC-HC v1.5.0.2827

[sneaker_ger]

Good luck, I don't think anyone's working on the renderer anymore. It is known to be buggy.

[namaiki]

V!roX, do you really find MPC-HC's internal subtitle renderer to be less CPU intensive than DirectVobSub?

[V!roX]

V!roX, do you really find MPC-HC's internal subtitle renderer to be less CPU intensive than DirectVobSub?

Well, yes. I read some guides recommending this over VobSub because the subtitle performance is much smoother and less CPU utilizing. I also tried both methods with various Karaoke subs on 720p H.264 and the MPC renderer was able to replay the video without lagging, while it stopped every few seconds when using VobSub.

[ranpha]

V!roX, do you really find MPC-HC's internal subtitle renderer to be less CPU intensive than DirectVobSub?

Yes, this can really be proven. DirectVobSub newer than 2.33 takes plenty of CPU resources than MPC-HC internal subtitle engine. Not to mention the lower quality in SD videos or even 720p ones.

[namaiki]

Just curious since I thought it was the same thing.

Why is the CPU usage higher in DirectVobSub newer than 2.33? What are the improvements in the newer versions? What about the older versions?

[ranpha]

Just curious since I thought it was the same thing.

Why is the CPU usage higher in DirectVobSub newer than 2.33? What are the improvements in the newer versions? What about the older versions?

It was at that point where then Beliyaal's multithreading improvements was incorporated into DirectVobSub. But while MPC-HC internal subtitle filter can use the GPU for compositing (and probably scaling too), DirectVobSub has to use CPU for everything.

[V!roX]

For those interested, I uploaded a short clip of this scene. Maybe the bug doesn't occur in your build of MPC-HC.
Remember, the bug only occurs when the player is in fullscreen mode and when using the MPC-HC sub renderer.

http://www.mediafire.com/?9aa88gho6zbs7o7

[sneaker_ger]

I can reproduce the problem, but I already stated it above: no one is working on the renderer. This will probably never get fixed.

[ranpha]

Below is how it looks like in MPC-HC 2993 x86 + madVR in fullscreen mode + MPC-HC internal subtitle engine + 'Position subtitle relative to video frame' fully enabled.

http://thumbnails29.imagebam.com/12554/8da923125534682.jpg (http://www.imagebam.com/image/8da923125534682)

In othe words, I cannot replicate the problem. I didn't see the problem even with EVR custom presenter.

That should be how the subtitle should be rendered right?

[namaiki]

ranpha, try set the window to a different resolution. It doesn't occur when the window is the same aspect ratio as the video.

[ranpha]

ranpha, try set the window to a different resolution

That screenshot is taken at full-screen playback (on 1080p which is my display native resolution). It looks fine in windowed mode too.

[namaiki]

It doesn't occur when the window is the same aspect ratio as the video.

Like I said. 1280x720 and 1920x1080 are of the same aspect ratio.

[ranpha]

Like I said. 1280x720 and 1920x1080 are of the same aspect ratio.

So you want to ask me to use non-native resolutions for my monitor?

[namaiki]

So you want to ask me to use non-native resolutions for my monitor?

You can do what you want. It's not that you can't reproduce the issue. It's just that the issue doesn't apply to you.

For the clip in question which is 16:9, people playing the video in fullscreen with a 16:10 monitor will be able to reproduce it.

p.s. If you look in my sig, you can see that my main screen is 1152x864 (4:3). Indeed if I set my monitor to 1920x1080 or any other 16:9 resolution, the issue can not be seen but that doesn't mean that the issue does not exist.

p.p.s. I may be misreading the intent of your previous post. If so, feel free to correct me.

[ranpha]

You can do what you want. It's not that you can't reproduce the issue. It's just that the issue doesn't apply to you.

For the clip in question which is 16:9, people playing the video in fullscreen with a 16:10 monitor will be able to reproduce it.

So in other words, that bug doesn't affect everyone, and can be mitigated by doing 'Stretch to window' right?

Below is how it looks like at 16:10 1680x1050 full screen.

http://thumbnails35.imagebam.com/12554/a48ef3125539702.jpg (http://www.imagebam.com/image/a48ef3125539702)

[namaiki]

Pretty much. The option isn't respecting the boundaries of the video frame.

[V!roX]

So in other words, that bug doesn't affect everyone, and can be mitigated by doing 'Stretch to window' right?

Below is how it looks like at 16:10 1680x1050 full screen.

http://thumbnails35.imagebam.com/12554/a48ef3125539702.jpg (http://www.imagebam.com/image/a48ef3125539702)

I'm using a 1440x900 Laptop screen right now, and in Fullscreen mode, the bug applies. I'mtalking about fullscreen, aka "Touch window from the inside". 16:9 is still maintained, even though the screen is 16:10. I have small black bars at the top and the bottom. When I check "Stretch to window", the bug doesn't apply. But since it's not the correct aspect ratio for this series, I won't be using it.

If you want to reproduce the bug, you can chose "touch window from the inside" and then randomly resize the window. You will probably notice the error then.

[ranpha]

I'm using a 1440x900 Laptop screen right now, and in Fullscreen mode, the bug applies. I'mtalking about fullscreen, aka "Touch window from the inside". 16:9 is still maintained, even though the screen is 16:10. I have small black bars at the top and the bottom. When I check "Stretch to window", the bug doesn't apply. But since it's not the correct aspect ratio for this series, I won't be using it.

http://thumbnails30.imagebam.com/12555/a092c1125541429.jpg (http://www.imagebam.com/image/a092c1125541429)

That's on fullscreen 16:10 1680x1050.

Keeping the aspect ratio can be done, but you have to ditch DXVA though.

[namaiki]

http://thumbnails30.imagebam.com/12555/a092c1125541429.jpg (http://www.imagebam.com/image/a092c1125541429)
That's on fullscreen 16:10 1680x1050.

Exactly, that image demonstrates the issue

Keeping the aspect ratio can be done, but you have to ditch DXVA though.

You mean use the external DirectVobSub?

[ranpha]

Exactly, that image demonstrates the issue



You mean use the external DirectVobSub?

No, I am using MPC-HC internal subtitle engine.

[V!roX]

http://thumbnails30.imagebam.com/12555/a092c1125541429.jpg (http://www.imagebam.com/image/a092c1125541429)

That's on fullscreen 16:10 1680x1050.

Keeping the aspect ratio can be done, but you have to ditch DXVA though.

Have you noticed that this subtitle is still out of place? It looks just the same as when I disable "Position subtitles relative to video frame".
I'm using CoreAVC by the way.

[namaiki]

No, I am using MPC-HC internal subtitle engine.

Then what exactly do you mean by "you have to ditch DXVA"?

[ranpha]

Then what exactly do you mean by "you have to ditch DXVA"?

Because you have to load ffdshow raw video filter and use its resize filter, before passing it to madVR/EVR custom presenter.

DXVA cannot be used, but CUDA acceleration can.

[namaiki]

Because you have to load ffdshow raw video filter and use its resize filter, before passing it to madVR/EVR custom presenter.

DXVA cannot be used, but CUDA acceleration can.

That doesn't even apply to MPC-HC's internal subtitle renderer. You have already demonstrated the issue above.

[ranpha]

That doesn't even apply to MPC-HC's internal subtitle renderer. You have already demonstrated the issue above.

Yet with my other test files (just tested them now), I do not have any positioning problems even when running with mismatched ratio between monitors and videos.