xy-VSFilter Project (High Performance VSFilter Compatible Subtitle Filters)

[mindbomb]

Someone told me he was having this problem, and then I tried it and also had the same issue. I was using mpc hc 1.7.2, with evr cp, xy subfilter 682. He was using madvr, and said it happened with every version newer than 87.4. I tried mpc hc 1.7.3 and also ran into this issue.

So the problem was any video file, an external srt file in the same directory with the same name, and with the audio switcher enabled, xy subfilter doesn't load, but with it disabled, xy subfilter loads. I assume this has something to do with the mechanism the audio switcher uses to detect external audio files clashing with xy subfilter's autoloader's mechanism to detect external subtitles.

[vivan]

I can confirm this issue. Happens with both madVR and EVR, with any external subtitle file (.ass too).
Happens only with internal LAV Audio Decoder...

[cyberbeing]

I am still unable to reproduce this. Did any of you have FFDShow installed, or otherwise overriding merits in MPC-HC External Filters?

http://i.imgbox.com/uNLKklDT.png http://i.imgbox.com/xGMG7JTZ.png
2 internal audio tracks + 1 external audio track + 2 external subtitle tracks


Please try the following:


Uninstall XySubFilter Beta2 with the bat (DllUnregister Server in xysubfilter.dll succeeded)
Run the XySubFilter_Restore_Defaults.reg from here (http://code.google.com/p/xy-vsfilter/issues/detail?id=26#c3)
Install XySubFilter Beta2 with the bat (DllRegister Server in xysubfilter.dll succeeded)
Download and extract/install MPC-HC x86 nightly (http://nightly.mpc-hc.org/)
Open MPC-HC options and run -> Miscellaneous -> Setting Management -> Reset
Open MPC-HC options and disable -> Playback -> Use built-in subtitle renderer
Do not change any other settings.
Create a new folder
Copy your problem video/subtitles/audio to this new folder
Rename to simple names like test.mkv test.ass test.srt test.flac
Open your renamed test.mkv which has external subtitles
Does the problem still exist?


If still having issues:
Please upload a log from the logging build (https://www.mediafire.com/?bxixb7x9gbo7v4n).
The log is written to C:\XySubFilter.log by default.

[mindbomb]

The problem still exists. Here is the log with audio switcher enabled http://pastebin.com/m6eWKW9X
Here with it disabled http://pastebin.com/mGcTTBy4

[cyberbeing]

mindbomb, does this only occur when using Internal LAV Audio like vivan?

In the log you posted it appears the MPC-HC audio switcher appears too early, and DirectShow ends up kicking XySubFilterAutoLoader out of the graph. In my log, XySubFilterAutoLoader connects to LAV Audio, loads XySubFilter, leaves the graph, and only then does the MPC-HC audio switcher appear.

vivan, if you could post a log as well, that would be useful for comparison.

Does the same thing occur with the MPC-BE 1.4.2 (http://sourceforge.net/projects/mpcbe/files/MPC-BE/MPC-BE%20Win32/MPC-BE%20Win32%201.4.2/) audio switcher? Or what about this specific MPC-HC 1.7.3.23 Nightly (http://nightly.mpc-hc.org/old/1.7.3.23/) or an old build like MPC-HC 1.6.8 stable (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC_v1.6.8_x86/)?


I'm curious as to why this only occurs for certain people. For reference, could you download Graph Studio Next (https://code.google.com/p/graph-studio-next/downloads/detail?name=graphstudionext_0_6_1_265.zip) drag your test video into it, and then:
1) Take a screenshot of the connected filters
2) Save and upload the Graph Construction Report (View Menu)
3) Upload a XySubFilter log for this operation

In mean-time, I suspect setting XySubFilter "Loading -> Always Load" will workaround any such audio switcher issues, since that setting does not require a connectable audio pin.

[vivan]

Logs:
With enabled audio switcher and internal audio decoder enabled - http://pastebin.com/QzpcBKzj (I have no idea what I'm doing wrong, but it's that short. And it doesn't like look mindbomb's log).
With enabled audio switcher and internal audio decoder disabled - http://pastebin.com/pBd4Uy0w (first 100 lines)
With disabled audio switcher - http://pastebin.com/hLzv1EBy (first 100 lines)
Btw, I have registed LAV Filters in MPC-HC folder, so when I'm disabling internal filters - MPC-HC is still using the same exact filters, just loads them in a different way.

I've checked MPC-BE - same behavior.
If built-in audio switcher is disabled - xysubfilter loads.
If built-in audio switcher is enabled and internal audio decoder is disabled - xysubfilter loads.
If built-in audio switcher is enabled and internal audio decoder is enabled - xysubfilter doesn't load.

With MPC-HC 1.7.3.23 and MPC-HC 1.6.8 stable - same behavior.

GSN:
graph - http://i.imgur.com/vnjo1xi.png
report - http://pastebin.com/bthB07nV
log - http://pastebin.com/zx4a8qFE

In mean-time, I suspect setting XySubFilter "Loading -> Always Load" will workaround any such audio switcher issues, since that setting does not require a connectable audio pin.Yes, it does help. That was the first thing I did when encountered this issue after updating xysubfilter (and re-registering it). And then I completely forgot about this issue.

P.s. is it possible to write log to a different place? It requires admin rights, and when I launch application with admin rights I can't use drag-n-drop to open files in it.

[cyberbeing]

Something is strange with all of your XySubFilter logs vivan, to the point of being useless as they are missing all the logging prior to subtitle rendering. You are using the logging build I linked, correct? Ensure that you've actually installed XySubFilter successfully and you extracted the XySubFilter.dll.properties file to the same directory. Try resetting settings to defaults with that registry file (http://code.google.com/p/xy-vsfilter/issues/detail?id=26#c3) as well. Maybe your custom path settings broke the logger or something.

Also, what OS are you running?

The Graph Construction Report seems normal, with XySubFilterAutoLoader present, and without DirectShow loading any unneeded filters.

P.s. is it possible to write log to a different place? It requires admin rights, and when I launch application with admin rights I can't use drag-n-drop to open files in it.

Edit the "log4cplus.appender.OUTFILE.File" line in the .properties file.

[vivan]

Maybe your custom path settings broke the logger or something.

Also, what OS are you running?

Edit the "log4cplus.appender.OUTFILE.File" line in the .properties file.Exactly. I had path "Субтитры", I've removed it and now my log is similar to mindbomb's.

W7 HP x64.

Thanks, I'll redo everything soon.

[cyberbeing]

Happens only with internal LAV Audio Decoder...

I've checked MPC-BE - same behavior.

Could you clarify this. MPC-BE doesn't use LAV Filters internally, so when you say 'same behavior' do you also mean only with MPC-BE's internal audio decoder?

[vivan]

Could you clarify this. MPC-BE doesn't use LAV Filters internally, so when you say 'same behavior' do you also mean only with MPC-BE's internal audio decoder?Yes. Same with MPC-HC 1.6.8 (LAV replaced internal filters in 1.7.0).
So it doesn't matter what that decoder is - only the fact that it's internal matters.

[cyberbeing]

kasper93 if you are still around, do you have any insight on the timing of the Audio Switcher entering the graph, and connection logic?

[vivan]

http://pastebin.com/2cQvAwpq switcher enabled, internal audio enabled (failed to load)
http://pastebin.com/2XRqQ4HG switcher disabled, internal audio enabled (loaded)
http://pastebin.com/YEuFNLum switcher enabled, internal audio disabled (loaded)
http://pastebin.com/hqYWScd8 switcher enabled, internal audio disabled, added LAV audio decoder in external filters and set it to "prefer" (failed to load)

http://pastebin.com/ipfVP7NB - GSN log

[mindbomb]

mindbomb, does this only occur when using Internal LAV Audio like vivan?

yes, that is the case.

[cyberbeing]

mindbomb & vivan, could you test both of these builds (www.mediafire.com/?cqzlf711cb1l0zq) and see if it makes any difference? Make sure you uninstall/install each time, and that you remove XySubFilterAutoLoader from External Filters if previously present. Both builds make some pin changes, and will be broken unless you re-register the filter. I'm not particularly hopeful these builds will make any difference, but worth a shot.

[mindbomb]

yea, they didn't work. Btw, we were both using windows 7, so many it is an OS specific thing?

[cyberbeing]

I don't think that's it, since I am also running Win7 SP1 x64 and I don't have this issue. At this point I can only assume that there must be some strange timing issue which either causes a delay in Directshow adding the AutoLoader to the graph, or otherwise the graph entering the running state too early. One last test build to try here (https://www.mediafire.com/?3ad7m6i6rfdawir). If this doesn't work, there is nothing more I need from you at the moment. I just hope our developer can reproduce this.

Also out of curiosity, what happens if you have xy-VSFilter 3.0.0.211 installed in addition to XySubFilter Beta2?

[mindbomb]

That build didn't work.

With xyvsfilter and xysubfilter installed, when the audio switcher is enabled, xyvsfilter is used, when it is disabled, xysubfilter is used. Only one of them is enabled in any given scenario.

[cyberbeing]

Okay, thanks.

[madshi]

Maybe the auto loader should register for video tracks instead of audio tracks? Or maybe both, just to be safe? Just a thought...

[cyberbeing]

Were you also able to reproduce this issue being reported madshi? MPC-HC Audio Switcher + MPC-HC Internal Audio Decoder = XySubFilter not loaded with external subtitles only?

Maybe the auto loader should register for video tracks instead of audio tracks? Or maybe both, just to be safe? Just a thought...

The AutoLoader is already registered for Video/Audio/Subtitle tracks as it has an GUID_NULL (Any Type) input pin with maximum merit. Entering the graph isn't an issue, something is just preventing DirectShow from attempting to connect the AutoLoader to an Audio pin after entering the graph. Normally the AutoLoader seems to connect directly to the Splitter pin, though in the case of mindbomb/vivan, the Internal Audio Decoder + Audio Switcher are able to make their connection first, and for some reason this causes things to fail. I would not be surprised if this was actually a bug in MPC-HC, which breaks raw audio filters for mindbomb/vivan as well.

If XySubFilterAutoLoader utilizes a video track for loading XySubFilter, it has the side-effect of preventing VSFilter.dll from being used globally. This is why by default, video track connections are rejected unless the user has sets XySubFilter to "Always Load". Not using a video track also goes hand-in-hand with the limited Consumer detection which the XySubFilterAutoLoader preforms, to improve co-existence with VSFilter.

[vivan]

Regarding all 3 builds and xyvsfilter - everything is the same as with mindbomb.
Also it happens on my another PC, with a similar setup...

I would not be surprised if this was actually a bug in MPC-HC, which breaks raw audio filters for mindbomb/vivan as well.I'm not sure if I understood this right - but I have no problems playing pcm audio
http://i.imgur.com/kyGGtjC.png

[madshi]

Were you also able to reproduce this issue being reported madshi? MPC-HC Audio Switcher + MPC-HC Internal Audio Decoder = XySubFilter not loaded with external subtitles only?
Haven't tried yet.

The AutoLoader is already registered for Video/Audio/Subtitle tracks as it has an GUID_NULL (Any Type) input pin with maximum merit. Entering the graph isn't an issue, something is just preventing DirectShow from attempting to connect the AutoLoader to an Audio pin after entering the graph.
I don't remember the nasty details, but do you really have to accept a connection at all in the auto loader? I thought the trick would be to refuse any connections, but to take the opportunity to look for external tracks, anyway. And if external tracks are found, manually add XySubFilter to the graph. Shouldn't that work without you having to accept any connections? But I guess you guys have probably thought that through, so it might not make sense for me to question the inner workings of the auto loader now.

[nevcairiel]

It should be enough to enter the graph, as thats all you really need to get access to the graph object and then force load another filter into the graph if needed.

[cyberbeing]

Also it happens on my another PC, with a similar setup...
Yeah... I don't have an explanation for that. There seems to be some unknown factor involved.

I'm not sure if I understood this right - but I have no problems playing pcm audio

What I meant was something like FFDShow's Raw Audio Processor. If you install only the FFDShow Raw Audio Processor, open Graph Studio Next -> Insert Filter -> find FFDShow Audio Processor -> and set Change Merit 0xFFFFFFFF, is the FFDShow's Raw Audio Processor then able to connect to MPC-HC's Audio Switcher automatically without having an entry in MPC-HC External Filters?

It should be enough to enter the graph, as thats all you really need to get access to the graph object and then force load another filter into the graph if needed.
Okay, I'll pass that along.

[cyberbeing]

Yeah... I don't have an explanation for that. There seems to be some unknown factor involved.

I was able to reproduce this on another computer and figured out the cause. That pesky RDPRedirectionFilter is to blame. The same which prevented VSFilter from auto-loading in MPC-HC for many years in the past. I thought MPC-HC blacklisted it entirely, but it seems not. If any MPC-HC devs are around, could you look into why RDPRedirectionFilter is not being completely blocked?

The reason this issue didn't occur on my primary dev computer, is I had taken ownership of that filter from Trusted Installer and disabled it with a merit of Do Not Use a long time ago. When I do the same on my other household computer, it fixes this issue as well.

Alternatively, if you set XySubFilterAutoLoader to Prefer in MPC-HC External Filters, it also seems to resolve it (the same workaround as when VSFilter was affected by this RDPRedirectionFilter issue in MPC). In any case, like before, I would classify this as a bug in the MPC graph manager.

[nevcairiel]

Not blacklisting a broken filter seems hardly to qualify as a bug, you should ideally design a system that even works when the default non-customized graph builder is used. It makes it several times easier for other players to adopt it.

[cyberbeing]

Looking at the commit in question (https://github.com/mpc-hc/mpc-hc/commit/ad11b629af15eb81414ad1b211f7c4f3f068cacd), it seems MPC-HC was only blocking RDPRedirectionFilter for Video, but not Audio.

Not blacklisting a broken filter seems hardly to qualify as a bug, you should ideally design a system that even works when the default non-customized graph builder is used. It makes it several times easier for other players to adopt it.
This RDPRedirectionFilter issue is unique to MPC's graph manager. Other media players do not have this issue.

This remained broken for years in MPC-HC, since nobody could figure out how to fix it on the VSFilter.dll side (we've looked into this before). Hence, it was fixed in MPC-HC instead. I'd assume if someone figured out how to fix VSFilter.dll with the commit I linked above reverted, the same fix would apply to XySubFilter as well. I'm unconvinced it is even possible to fix this on our end though, as it seems MPC's graph manager is causing unintended behavior.

[nevcairiel]

Oh, I see, MPC-HC bumps the merits of its renderers higher to avoid issues with this filter. Thats indeed a bug, and not the usual filter blacklisting that happens in several other places (ie. preventing broken filters from entering the graph)

[cyberbeing]

Applying that same fix for Audio in MPC-HC FGManager.cpp resolves the issue:
GUID guidsAudio[] = {MEDIATYPE_Audio, MEDIASUBTYPE_NULL};

if (SUCCEEDED(m_pFM->EnumMatchingFilters(&pEM, 0, FALSE, MERIT_DO_NOT_USE + 1,
TRUE, 1, guidsAudio, nullptr, nullptr, TRUE, FALSE, 0, nullptr, nullptr, nullptr))) {
for (CComPtr<IMoniker> pMoniker; S_OK == pEM->Next(1, &pMoniker, nullptr); pMoniker = nullptr) {
CFGFilterRegistry f(pMoniker);
if (f.GetCLSID() != CLSID_RDPDShowRedirectionFilter) {
m_armerit = std::max(m_armerit, f.GetMerit());
}
}
}

Here is a MPC-HC build (https://www.mediafire.com/?23lnv93vfyr1a4x) with that change.

[cyberbeing]

I don't remember the nasty details, but do you really have to accept a connection at all in the auto loader? I thought the trick would be to refuse any connections, but to take the opportunity to look for external tracks, anyway. And if external tracks are found, manually add XySubFilter to the graph. Shouldn't that work without you having to accept any connections? But I guess you guys have probably thought that through, so it might not make sense for me to question the inner workings of the auto loader now.

I would naively think this was done to ensure:

A) DirectShow gives up on connecting the AutoLoader to the video pin and is able to fallback to a filter with a lower merit (i.e. VSFilter)

B) AutoLoader can then decide whether or not remove VSFilter from the graph (load XySubFilter), perform Consumer detection, and perform External Subtitle detection

C) AutoLoader is not kicked out of the graph too early.

...but I'm not positive over the exact reasoning for the implementation either. The current 'Load when needed' AutoLoader implementation only attempts to load XySubFilter once DirectShow no longer is attempting to connect it to the video pin. Maybe some operations could be moved earlier as Nev stated, but a quick test removing the input pin MEDIATYPE checks ends up preventing DirectShow from attempting to load VSFilter into the graph system-wide. Assuming it is possible, it would likely require re-factoring the entire AutoLoader. I'm not sure it's worth it unless an actual bug is found, since currently it is working-as-intended from what I can tell.

[madshi]

Now that you found the cause of the recently reported problem (RDPRedirectionFilter), there's probably no reason to change anything.

[vivan]

Applying that same fix for Audio in MPC-HC FGManager.cpp resolves the issue:
...
Here is a MPC-HC build (https://www.mediafire.com/?23lnv93vfyr1a4x) with that change.Yeap, I can confirm that it fixed that issue for me.

[cyberbeing]

Yes, and thanks vivan & mindbomb for putting through with all my requests for logs and testing.

[ikarad]

When can we hope a new version of xy-vsfilter beta or stable version?

[Soukyuu]

Is it possible to configure xy-subfilter (or mpc-hc) to load the subtitles, but not display them until user presses the subtitle key? Normally, the first track is auto-loaded, pressing the subtitle key cycles between other tracks and empty.

[michkrol]

Is it possible to configure xy-subfilter (or mpc-hc) to load the subtitles, but not display them until user presses the subtitle key? Normally, the first track is auto-loaded, pressing the subtitle key cycles between other tracks and empty.

I understand you mean internal subs (in *.mkv, etc.)? They are selected by either splitter or media player.
If you're using LAVFilters (LAV Splitter) go to the splitter settings and for Subtitle Selection Mode select No subtitles, instead of Default.
For it to work you might need to disable Allow overriding external splitter choice under Default track selection in Playback settings in MPC-HC.

[Soukyuu]

Works, thanks! I guess I assumed "no subtitles" would not load subtitles at all, meaning disabling xy-subfilter.

[cyberbeing]

When can we hope a new version of xy-vsfilter beta or stable version?
No later than the time when we release XySubFilter Beta3.

If it looks like XySubFilter Beta3 is going to be delayed, I may end up releasing a xy-VSFilter build based on CCCP's branch as the next stable as a temporary measure.

Works, thanks! I guess I assumed "no subtitles" would not load subtitles at all, meaning disabling xy-subfilter.

The 'Hide Subtitles' setting under the 'More' tab is also remembered. If you use MPC-BE you can then show subtitles on demand with the 'W' hotkey.

MPC-HC does not yet support such VSFilter API hotkeys, but there is currently a feature request ticket you can track here (https://trac.mpc-hc.org/ticket/4122).

[ryrynz]

If it looks like XySubFilter Beta3 is going to be delayed, I may end up releasing a xy-VSFilter build based on CCCP's branch as the next stable as a temporary measure.


It might be worth using this as the ongoing stable branch considering how often it's tweaked and prodded.

[cyberbeing]

It might be worth using this as the ongoing stable branch considering how often it's tweaked and prodded.

The CCCP branch is rarely tweaked and prodded, as it is made up almost entirely of various fixes which were backported from old commits in our latest branches to ensure stability. I've been working with them to that extent for quite awhile now as a stop-gap measure for keeping xy-VSFilter somewhat up-to-date, while we were focused on XySubFilter. It was never intended to be a long-term solution. There are a lot of features, functionality, and other changes from our latest branches, which are just not practical to backport. If I go this route, it would only be temporary until we resolve the issues which recently broke VSFilter in our lastest branches.

[minaust]

Hi everybody!

I've come here from the MPC-HC thread, as cyberbeing and I were about to wander off-topic. I've been using Media Player Classic since Gabest was maintaining it, and I've always used the ISR. Never saw a need to change. But in the last couple of days, I've had to more or less "get up to speed", and xysubfilter seems to fill the bill.

I had two gripes with it, and one has been fixed. The other is this: The subtitle file must be named identically to the video file. Meanwhile, I have movies with 2 and even 3 different sets of English subs. Xysubfilter is only seeing the one set named identically to the movie. The ISR would see them all.

I realize there are problems when you have multiple subs, but anybody with multiple subs using the ISR has most likely solved that by now.

Any fix in the works for this? Or is there a naming convention or configuration switch I've missed?

[cyberbeing]

Currently, the naming convention required for subtitle loading multiple subtitles in xy-VSFilter/XySubFilter matches Gabest's original MPC and VSFilter projects exactly.

Unique identifiers for each subtitle file can be added after the identical segment, following a period, like the following:

VideoTitle.mkv
VideoTitle.en.srt
VideoTitle.jp.srt
VideoTitle.fr.srt
VideoTitle.styled.ass
VideoTitle.bluray.sup
These subtitles would then respectively show up with the names, "en", "jp", "fr", "styled", and "bluray" from the xy-VSFilter/XySubFilter context menu.

It does appears that MPC-HC has changed this slightly. They still require that the exact video title exist at the very beginning of the subtitle filename, but remove the requirement for a period before the unique section? The change in question appears to be this commit (https://github.com/mpc-hc/mpc-hc/commit/82bbcaf00ff0f8bdd8f797d04467c3076cc7fa0c), which was introduced a few months ago in MPC-HC 1.7.2


VideoTitle.mkv
VideoTitle.en.srt
VideoTitle en.srt
VideoTitle_en.srt
VideoTitleRandomString.srt

MPC-HC then shows the entire subtitle name, including video title. minaust, was this type of autoload naming which you were thinking of?

Enhancing the external subtitle autoload and path behavior along with support for language matching has been something on our to-do list for awhile now.

I'd recommend creating a new issue on our bugtracker (http://code.google.com/p/xy-vsfilter/issues/list) listing the specific behavior you'd like to see supported, so we do not forget about it.

[minaust]

Currently, the naming convention required for subtitle loading multiple subtitles in xy-VSFilter/XySubFilter matches Gabest's original MPC and VSFilter projects exactly.
I never knew any naming conversion existed at all.

These subtitles would then respectively show up with the names, "en", "jp", "fr", "styled", and "bluray" from the xy-VSFilter/XySubFilter context menu.
I like this naming convention. I like it a lot.

It does appears that MPC-HC has changed this slightly. They still require that the exact video title exist at the very beginning of the subtitle filename, but remove the requirement for a period before the unique section? The change in question appears to be this commit (https://github.com/mpc-hc/mpc-hc/commit/82bbcaf00ff0f8bdd8f797d04467c3076cc7fa0c), which was introduced a few months ago in MPC-HC 1.7.2
I now view that as a bug. You see, I keep my subs in a common pool - C:\Subtitles. But when the aforementioned change occurred I encountered a problem: Say I played "Movie.Mkv". MPC-HC would show me the subs:
Movie.Ass
Movie - The Sequel.Ass
Movie - Another Sequel.Ass
Movie - Yet Another Sequel.Ass
Movie - Yes, We're Milking the Franchise.Ass

You get the idea. I compensated for that. Now that I know the convention (which works), I'm delighted with it the way things are.

MPC-HC then shows the entire subtitle name, including video title. minaust, was this type of autoload naming which you were thinking of?
It WAS. Not any more.
Enhancing the external subtitle autoload and path behavior along with support for language matching has been something on our to-do list for awhile now.
For my purposes the existing pathing works. I haven't experimented with it, but it appears I can change it as needed. Or can I?

I'd recommend creating a new issue on our bugtracker (http://code.google.com/p/xy-vsfilter/issues/list) listing the specific behavior you'd like to see supported, so we do not forget about it.
Heh. as if you can't tell, this "issue" gives me a damned good reason to abandon the ISR forever. No bugfix needed.

If anything, the posts on this page alone illustrates just how rapidly this particular software field is evolving.

It ranges from projects that were abandoned 'way back when, to projects that see daily releases.

In that world, documentation is scarce. Either nobody cares any more, or everybody is too busy. Oh, well.

By the way, thanks for the heads up.

[real.finder]

hi

I have a script get problems in xy-vsfilter, Whether in mpc or aegi

the problems is shades inaccurate and crash

Although this problems does not appear in the last aegisub (3.1.3) with xy-vsfilter in it

sub and font (http://www.mediafire.com/?baxhxtsq57tce0t)

thanks

last cccp fix shades inaccurate, but the crash still existing in some case like in the sample above

I would be grateful if this issue and http://code.google.com/p/xy-vsfilter/issues/detail?id=168 solved

with both 32 and 64 builds to use it in avs64/avs+ 64

thanks

[kasper93]

I now view that as a bug. You see, I keep my subs in a common pool - C:\Subtitles. But when the aforementioned change occurred I encountered a problem: Say I played "Movie.Mkv". MPC-HC would show me the subs:
Movie.Ass
Movie - The Sequel.Ass
Movie - Another Sequel.Ass
Movie - Yet Another Sequel.Ass
Movie - Yes, We're Milking the Franchise.Ass

You get the idea. I compensated for that. Now that I know the convention (which works), I'm delighted with it the way things are.

I think it's better to load more than skip valid subtitles in the process.

Heh. as if you can't tell, this "issue" gives me a damned good reason to abandon the ISR forever. No bugfix needed.

You referring to "XY" bugtracker yet talking about ISR... Anyway bugtrackers exist for the reason to discuss with developers how you expect software to work. We can't know what do you want unless you told us. I find this rude to bitch about other software in random threads behind original developers back and don't bother to even notify them about problems you encountered. How do you expect software to meet your expectations if you don't tell what do you want? Developers are not magicians who know what user-base think. It's very important to give feedback for their work...

[cyberbeing]

I like this naming convention. I like it a lot.

Happy to hear that works out well for you.

For my purposes the existing pathing works. I haven't experimented with it, but it appears I can change it as needed. Or can I?
The default entries are fixed (legacy limitation), but you can add new ones if desired. At some point we'll probably add support for either Wildcards, RegEx, or Mask support to allow more flexibility in directory naming with Path searches. Issue #105 (http://code.google.com/p/xy-vsfilter/issues/detail?id=105) is currently tracking any Path related feature requests.

I think it's better to load more than skip valid subtitles in the process.

I think it's better to add a GUI option which allows the user to decide how strict they desire subtitle loading to be. That's how mplayer-based players have always handled it, with options for "exact movie name", "contains movie name", and "load all subtitles". Defaulting to VSFilter-style exact matching, while having GUI options to enable looser matching, is probably how we would implement it if we go this route.

last cccp fix shades inaccurate, but the crash still existing in some case like in the sample above

Yes, the latest CCCP only contains 'Part 1' of the fix, that fixes a math overflow in the border code.

'Part 2' is the "Insane Border Support" commits, which uses a border rendering method more suitable in terms of performance and memory footprint for rendering border sizes beyond a certain threshold. Unfortunately, the "Insane Border Support" commits introduce a crash bug which we've yet to resolve.

'Part 3' fixes memory allocation in 64bit builds only to support extremely large border sizes.

I would be grateful if this issue and http://code.google.com/p/xy-vsfilter/issues/detail?id=168 solved
That's the plan when we make our next official release. The fix for Issue #168 is rather simple, it was essentially a typo in the parser which caused this feature to be disabled in legacy Gabest VSFilter (guliverkli (http://sourceforge.net/projects/guliverkli/) & guliverkli2 (http://sourceforge.net/projects/guliverkli2/) projects) which xy-VSFilter is based on. It wasn't fixed until early 2010 in VSFilterMod (http://code.google.com/p/vsfiltermod/source/detail?r=20), which was the project that MPC-HC eventually used as the base for their VSFilter (with most Mod-only features disabled/removed for compatibility).

CCCP usually doesn't merge random things such as this unless someone specifically requests it on their forums (http://www.cccp-project.net/forums/index.php?topic=6604.0) or IRC (irc://irc.rizon.net/cccp).

Edit: Issue #168 has now been fixed on Github in the xy_sub_filter_rc3 (https://github.com/Cyberbeing/xy-VSFilter/commit/30bcebb715a248b8051c3aeae4a5ff506695de42) & vsfilter_rc (https://github.com/Cyberbeing/xy-VSFilter/commit/fc60306c242720eede1c983444850e3568b5a39f) branches

[minaust]

I think it's better to load more than skip valid subtitles in the process.
Agreed - to a point.

You referring to "XY" bugtracker yet talking about ISR... Anyway bugtrackers exist for the reason to discuss with developers how you expect software to work. We can't know what do you want unless you told us. I find this rude to bitch about other software in random threads behind original developers back and don't bother to even notify them about problems you encountered. How do you expect software to meet your expectations if you don't tell what do you want? Developers are not magicians who know what user-base think. It's very important to give feedback for their work...
Constructive feedback is coming in the appropriate thread. You've kinda beaten me to the punch here.

EDIT: See ticker #4281 (https://trac.mpc-hc.org/ticket/4281)

[clsid]

@cyberbeing

The common.props config file is currently not included in the project files, as it should be.

You should also add this to common.props<ItemDefinitionGroup Condition="'$(Configuration)'=='Release' Or '$(Configuration)'=='Release Unicode' Or '$(Configuration)'=='Release log'">
<ClCompile>
<EnableEnhancedInstructionSet Condition="'$(Platform)'=='Win32'">StreamingSIMDExtensions</EnableEnhancedInstructionSet>
</CLCompile>
</ItemDefinitionGroup>
And remove
<EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>from the individual project files. Because since VS2013 "NotSet" means that SSE2 will be used.

[cyberbeing]

The common.props config file is currently not included in the project files, as it should be.
Are you talking about something different than the changes in this pull request (https://github.com/Cyberbeing/xy-VSFilter/pull/7)?

You should also add this to common.props<ItemDefinitionGroup Condition="'$(Configuration)'=='Release' Or '$(Configuration)'=='Release Unicode' Or '$(Configuration)'=='Release log'">
<ClCompile>
<EnableEnhancedInstructionSet Condition="'$(Platform)'=='Win32'">StreamingSIMDExtensions</EnableEnhancedInstructionSet>
</CLCompile>
</ItemDefinitionGroup>

Minimum requirement of xy-VSFilter/XySubFilter was supposed to be MMX, with CPU runtime detection used to activate our hand-written SSE2 optimizations.



And remove
<EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>from the individual project files. Because since VS2013 "NotSet" means that SSE2 will be used.
Thanks for pointing that out, I didn't realize this had changed in VS2012/VS2013. So to get the same effect, it seems we need to set:
<EnableEnhancedInstructionSet>NoExtensions</EnableEnhancedInstructionSet>

[cyberbeing]

XySubFilter 3.1.0.697 Beta2 has been released (https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.1.0.697)

XySubFilter Beta2 .zip Archive (32-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.697/XySubFilter_3.1.0.697_x86_BETA2.zip) | XySubFilter Beta2 .zip Archive (64-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.697/XySubFilter_3.1.0.697_x64_BETA2.zip)

Debug Symbols for XySubFilter 3.1.0.697 (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.697/XySubFilter_3.1.0.697_Debug_Symbols.7z)

Features & Changes

Update Cache defaults (LV1 256->2048, LV4 512->768)
Disable /arch:SSE2 in VS2012/VS2013 builds


Bug Fix

Unable to load subtitle files with uppercase file extension
Correct a parser check which broke loading of script embedded UUE fonts
Revert Insane Border Support (temporary crash fix)


This release is a minor update of XySubFilter 3.1.0.682 Beta2 (http://forum.doom9.org/showpost.php?p=1672047&postcount=324).