xy-VSFilter Project (High Performance VSFilter Compatible Subtitle Filters) [Archive] - Page 7

cyberbeing

23rd February 2014, 16:40

yep settting the cache to 2048 worked half way , meaning it doesnt immediately freeze but a couple seconds more and it still does go into a freeze state but atleast i can exit potplayer normaly now without having to go into taskmanager , so somethings still wrong with xysubfilter, guess im gona have to wait till the next official build gets released since these issues have been fixed apparently, ive tried 3.1.0.546 also , and that ones the same , freezes in fullscreen or maximized with ass subs
Strange, does this occur with all ASS subtitles or just certain ones? If only certain ones, I'll need a sample. If it occurs with all subtitle samples, it could be a madVR issue. Have you tried lowering madVR's CPU queue setting? This is the only report we've had on such a problem in the 7 months since we released XySubFilter Beta, so it seems likely whatever the issue is, it's not widespread and may be something specific about your setup. What are your system specifications? CPU, RAM, GPU, OS?

Please try to get us a madVR freeze report, since without a way to reproduce this, I have little hope it will just get resolved on its own.

Since it occurs with 3.1.0.546 Beta as well, I'll troubleshoot this with you. Download the PDB symbols from here (http://code.google.com/p/xy-vsfilter/downloads/detail?name=XySubFilter_3.1.0.546_Debug_Symbols.7z), place them in the same directory as XySubFilter.dll 3.1.0.546, and generate a madVR freeze report CTRL+ALT+SHIFT+BREAK when this occurs with PotPlayer.

Also see if you can reproduce it in MPC-HC as well. Download MPC-HC 1.7.3 (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC_v1.7.3_x86/MPC-HC.1.7.3.x86.7z/download), MPC-HC 1.7.3 PDB symbols (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC_v1.7.3_x86/MPC-HC.1.7.3.x86.pdb.7z/download), uncheck Playback -> Autoload subtitles, disable all MPC-HC internal filters, copy over the your Lav Filters installed by that megapack with the Official 0.60.1 release (http://files.1f0.de/lavf/LAVFilters-0.60.1.zip) (run install_all.bat) & 0.60.1 PDB debug symbols (http://files.1f0.de/lavf/LAVFilters-0.60.1-symbols.zip). Test both XySubFilter with madVR, as well as EVR-CP. If you have the same freeze in maximized/fullscreen with madVR using MPC-HC, generated another freeze report. If the problem doesn't occur with XySubFilter + EVR-CP, it could be a madVR issue. In which case, activate madVR debug mode, and give madshi a zipped debug log.

cyberbeing

23rd February 2014, 19:37

@[ReX]

I've now pushed a new xy_sub_filter_rc3 (https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc3) branch to GitHub which includes your pull requests.

Thank you for all your hard work on this much need project cleanup and repository maintenance. And I have to apologize for likely making this back and forth all more time consuming than you most likely originally imagined. Feel free to take a break, but if you have any luck adapting these changes to the vsfilter_rc branch, put up a new pull request on GitHub.

sexus

23rd February 2014, 20:39

Strange, does this occur with all ASS subtitles or just certain ones? If only certain ones, I'll need a sample. If it occurs with all subtitle samples, it could be a madVR issue. Have you tried lowering madVR's CPU queue setting? This is the only report we've had on such a problem in the 7 months since we released XySubFilter Beta, so it seems likely whatever the issue is, it's not widespread and may be something specific about your setup. What are your system specifications? CPU, RAM, GPU, OS?

Please try to get us a madVR freeze report, since without a way to reproduce this, I have little hope it will just get resolved on its own.

Since it occurs with 3.1.0.546 Beta as well, I'll troubleshoot this with you. Download the PDB symbols from here (http://code.google.com/p/xy-vsfilter/downloads/detail?name=XySubFilter_3.1.0.546_Debug_Symbols.7z), place them in the same directory as XySubFilter.dll 3.1.0.546, and generate a madVR freeze report CTRL+ALT+SHIFT+BREAK when this occurs with PotPlayer.

Also see if you can reproduce it in MPC-HC as well. Download MPC-HC 1.7.3 (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC_v1.7.3_x86/MPC-HC.1.7.3.x86.7z/download), MPC-HC 1.7.3 PDB symbols (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC_v1.7.3_x86/MPC-HC.1.7.3.x86.pdb.7z/download), uncheck Playback -> Autoload subtitles, disable all MPC-HC internal filters, copy over the your Lav Filters installed by that megapack with the Official 0.60.1 release (http://files.1f0.de/lavf/LAVFilters-0.60.1.zip) (run install_all.bat) & 0.60.1 PDB debug symbols (http://files.1f0.de/lavf/LAVFilters-0.60.1-symbols.zip). Test both XySubFilter with madVR, as well as EVR-CP. If you have the same freeze in maximized/fullscreen with madVR using MPC-HC, generated another freeze report. If the problem doesn't occur with XySubFilter + EVR-CP, it could be a madVR issue. In which case, activate madVR debug mode, and give madshi a zipped debug log.

well actually yes this happens for all animes with ass subs , and no the version does not matter if 3.1.0.546 or 3.1.0.640, happens with both, cpu is a 980x i7 4.13ghz , OS is w7 x64 sp1 with all updates , gpu is titan gtx with vbios mod, ram is 24gb dominators running 1600 at 9x9x9x24 t2

madvrs gpu queue is set to max as well as cpu queue

update> it was the cpu queue had it set too high apparently or have i? , after lowering it retesting no more freeze and when setting it back to max thou the issue is still gone , odd :scared:

cyberbeing

23rd February 2014, 21:11

Using of XySubFilter with madVR adds a Subtitle queue in addition to the CPU queue which caches entire frames. Essentially it doubles madVR RAM usage. From my tests, setting any CPU queue over 64 is extremely dangerous and runs the risk of exceeding the 32bit virtual memory process limit. If your monitor is higher resolution than 2560x1440, you may need to set it even lower. Reducing memory usage in XySubFilter itself is something on our to-do list, but memory allocated by madVR for its subtitle queue is outside our control.

Personally, I see setting madVR's CPU queue to anything over 48 as rather excessive. For normal everyday usage on my i5-3570K @4.4Ghz + GTX 770 2GB, I use CPU queue 24 and GPU queue 16 respectively.

when setting it back to max thou the issue is still gone , odd :scared:
*shrug* maybe madVR had a setting bug caused by recent updates which borked the subtitle queue.
mark0077 a couple pages back also reported a performance regression with 0.87.4, so maybe it's all related.

sexus

23rd February 2014, 21:40

i see so i guess ill keep the cpu queue at 48 then and gpu queue at max aka 24 , makes you wonder for what theres higher than 48 cpu queue available thou hmmm...., just thought the higher the better , my bad i guess

fagoatse

23rd February 2014, 22:07

Is there any reason why xysubfilter isn't provided in 64bit?

cyberbeing

23rd February 2014, 22:10

makes you wonder for what theres higher than 48 cpu queue available thou hmmm...., just thought the higher the better , my bad i guess
Only when not using XySubFilter, is madVR's max CPU queue size of 128 viable. During early development, I actually tried to convince madshi to not make such a large CPU size available in madVR v0.86.2 as it would pose risk out out-of-memory crashes with XySubFilter, but people with old slow CPUs were requesting it just so they could software decode video reliably without subtitles. Before we released XySubFilter Beta, I once again requested that the CPU queue be limited to to 64, create a separate Subtitle queue setting in the madVR gui, or at least warn people about the danger of setting such a high CPU queue size, but he wasn't interested in doing so.

End result is the CPU queue in madVR requires some basic user-responsibility to not set it so high that it causes crashes or other issues. madshi's general mindset on the queues, is to set them as low as you possibly can while still avoiding dropped frames or other performance/reliability issues. Bigger isn't always better. Even with XySubFilter's own LV1/LV2/LV3/LV4 caches, setting them higher than the defaults will often just increase memory usage and hurt overall performance.

Is there any reason why xysubfilter isn't provided in 64bit?

At the time we released XySubFilter 3.1.0.546 Beta, madVR was the only subtitle consumer, and madVR is 32bit only. Since then, MPC-HC has added support for a subtitle consumer in EVR-CP & VMR9 as well, so for our next release we will consider releasing a 64bit version.

[ReX]

23rd February 2014, 22:39

cyberbeing

23rd February 2014, 22:50

;1670234']Seems like you missed the last three commits in xy_sub_filter_rc2 when creating the new branch, though.

Four actually, and that was on purpose. Those partial rasterize and partial scan-line convert commits had some stability bugs. Our developer has a tendency to rollback and force-push fixes (which hilariously actually broke GitHub's backend updates on our repository for many months awhile back), so I figured I better back out the problem commits now so he'll have an easier time commiting fixed versions. ;)

madshi

23rd February 2014, 23:04

memory allocated by madVR for its subtitle queue is outside our control.
From what I remember right now, I think madVR does not consume any RAM for storing subtitles in the queue at all. The madVR subtitle queue only contains a reference to the ISubRenderFrame object delivered by XySubFilter for every video frame in the queue. So basically the RAM consumption depends on nothing else but how much RAM XySubFilter needs to keep all the queued ISubRenderFrame objects working.

cyberbeing

23rd February 2014, 23:36

Assuming that accurate, it's only a technicality and my point still stands. As long as madVR has ISubRenderFrame objects referenced for the entire Subtitle queue, XySubFilter is not allowed to release the bitmaps, lest they be requested again. In practice, it mimics the RAM usage of madVR's CPU queue in size, and higher when upscaling. madVR could just as easily store bitmaps in the subtitle queue and allow XySubFilter to release the references, with memory usage staying the same either way. That wasn't the point.

What I meant, was that XySubFilter as a subtitle provider honors all requests of subtitle consumers, per requirements of the subtitle interface we specified. Excessive requests for subtitle frames by the subtitle provider, via madVR's user-set subtitle queue setting, are outside our control. That said, madVR requesting more than 64 subtitles frames at any given time is risky @2560x1440, and I've mentioned this to you before by email. Since you didn't want to increase complexity (understandable) by allowing madVR's Subtitle queue to have different limits than the CPU queue, and desired to offer a CPU queue size of 128 to the user who required it (also understandable), it is how it is and requires user restraint and responsibility to not have madVR settings crash their media player when XySubFilter is used.

Soukyuu

23rd February 2014, 23:52

From my tests, setting any CPU queue over 64 is extremely dangerous and runs the risk of exceeding the 32bit virtual memory process limit. If your monitor is higher resolution than 2560x1440, you may need to set it even lower. Reducing memory usage in XySubFilter itself is something on our to-do list, but memory allocated by madVR for its subtitle queue is outside our control.I can't say I had any issues with a queue of 128 so far. Going below that made the playback stutter on some insane typesets, though.

Personally, I see setting madVR's CPU queue to anything over 48 as rather excessive. For normal everyday usage on my i5-3570K @4.4Ghz + GTX 770 2GB, I use CPU queue 24 and GPU queue 16 respectively.Not if you're stuck with and AMD CPU/APU, the single-threaded bottleneck really shows there.

cyberbeing

24th February 2014, 00:03

@Soukyuu

All I can say, is beware of the type of insane subtitle samples which require a lot of memory to render. If you experience a crash, you'll know why.

When I was stuck on an old AMD X2 4800+ system until mid-2012, I still thought that a CPU queue of over 48 was excessive. Not because my old CPU could handle everything, but rather since there are limits to how much madVR's queues can used as a crutch for a slow system. If you cannot handle a script with a CPU queue of 48, either the script itself needs to be toned down, or CPU upgraded. In most such cases, toning down the script (or requesting such) is the correct answer.

We are working on memory usage improvements for the next XySubFilter release, but even then I stand by my statement that setting madVR's CPU queue size over 64 puts you at risk of out-of-memory errors when combined with 2560x1440 monitor. Before we released Beta, I had samples which brought me within 100MB of the 32bit process limit when using a madVR CPU queue of 64 @2560x1440.

madshi

24th February 2014, 00:22

Assuming that accurate, it's only a technicality and my point still stands.
I was just commenting on you saying:

> memory allocated by madVR for its subtitle
> queue is outside our control.

My comment to that was that there is no memory allocated by madVR for its subtitle queue. That's not a technicality, but relevant information.

Of course XySubFilter is forced to spend large amounts of RAM on storage, if madVR keeps a reference to many subtitle frame objects. That is a separate issue/topic and nothing XySubFilter can do anything about.

FWIW, one thing you could optimize is the following: I've noticed that XySubFilter often sends subtitles in the whole size of the video frame instead of sending only bitmaps in the size of the small subtitle line. The latter would cut memory storage costs to a fraction. Not sure if XySubFilter does this for all subtitle formats, though, might be specific to some formats.

cyberbeing

24th February 2014, 00:37

Wasn't there a combine bitmap setting somewhere which the subtitle consumer sets? Aside from that, there is a certain logic to when we send text subtitle lines in larger chunks rather than smaller. Though I don't believe we should ever send entire video frames unless we are talking about PGS? Maybe I'm mistaken. Which subtitle formats were you seeing this behavior with? My memory about this is sketchy, since I thought that either we or you did something before we released Beta to optimize display of PGS subtitle lines?

madshi

24th February 2014, 08:02

Yes, there's a "combineBitmaps" option, which allows the subtitle consumer to ask for a combined bitmap. I'm not setting it, though, and according to the header it should default to "false".

It could very well have been PGS. Is there no position/size information for PGS at all? I guess if all else fails, you could do a very simple PGS pixel search. Should be very fast using SSE2. You could do the pixel search while copying the data to your internal buffers. That's how madVR does its fade detection: when copying the video frames. This nicely hides the cost of the fade detection.

sneaker_ger

24th February 2014, 08:40

Is there no position/size information for PGS at all?
Are you talking about the PGS format itself or the way XySubFilter sends it? The format itself does know smaller images and positioning information and can even split the big picture up into multiple smaller ones IIRC. It can be necessary to help work around the small PGS buffer Blu-Ray allows.

madshi

24th February 2014, 08:52

Are you talking about the PGS format itself or the way XySubFilter sends it? The format itself does know smaller images and positioning information and can even split the big picture up into multiple smaller ones IIRC. It can be necessary to help work around the small PGS buffer Blu-Ray allows.
I meant the PGS format itself. Thanks for the information, didn't know that.

sneaker_ger

24th February 2014, 09:29

Anyways, it does not necessarily mean that the picture actually was cropped by the author so I guess it doesn't make any difference.

kasper93

24th February 2014, 13:47

It could very well have been PGS. Is there no position/size information for PGS at all?

There is, but current pgs/dvb renderer sends always full subtitle frames. At least in mpc-hc but IIRC it is exactly the same code. I want to change this one day. But honestly there are more important bugs in rendering path than this performance issue :)

Tapatalk 4 @ GT-I9300

cyberbeing

24th February 2014, 14:46

I looked back and figured out what I was thinking of:

XySubFilter fixed this for DVB subtitles and only when there was a single line, not PGS/HDMV.

madVR optimized performance for this by "only uploading every bitmap ID once" to the GPU instead of "uploading every subtitle frame".

@madshi for reference, we discussed exactly this problem with PGS by email around 6/24/2013

Reino

25th February 2014, 20:22

I haven't read through this entire thread, but I have used search, which came up with nothing, so excuse me if this has been asked before.Input/Output support for AYUV 4:4:4 YUV formatI've tried to use TextSub("subtitles.ass") on top of a yuv 4:4:4 (yv24) video-stream in Avisynth, but the subtitles don't show up at all. yx-VSFilter doesn't through an error either. When I convert the video-stream to yuv 4:2:0 (yv12), the subtitles do show up? Am I doing something wrong?

cyberbeing

25th February 2014, 20:56

We only support AYUV (packed 4:4:4 YUV) at this time, not YV24 (planar 4:4:4 YUV), and VSFilter in general only supports the Avisynth 2.5 plugin interface, not 2.6.

Supporting DirectShow YV24 input/output is something on our to-do list for a future release, but I don't see there being any Avisynth 2.6 support (which added support for additional color formats like YV24) for TextSub unless MPC-HC/MPC-BE add such support themselves, or someone provides us a patch. Same goes for something like VapourSynth support, patches welcome.

cyberbeing

5th March 2014, 19:49

XySubFilter Beta2 has been released (https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.1.0.682)
GoogleCode no longer allows adding downloads, so all future releases will be made on GitHub

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

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

Note: XySubFilter requires a compatible subtitle consumer. We recommend madVR 0.87.5+ (http://madshi.net/madVR.zip).
MPC-HC 1.7.2+ 64-bit (EVR-CP) or other 64-bit Subtitle Consumer is required to use the 64-bit build.

Features & Changes

Static Unrar support
Maximum cache size limiter (defaults to 512MB on 32bit, 1/4 Physical RAM on 64bit)
Autoload Helper for external subtitles
Style Editor: Support floating point Border & Shadow values
Initial implementation for rendering subtitles outside the video frame (requires Consumer support)
SourceFilter/Splitter whitelist moved to registry key
Removed legacy PAR compensation function (superseded by 'Use AR Adjusted Video Size')
Removed connected YCbCr Matrix from filter name
Removed legacy function for changing playback speed
Support for building with Visual Studio 2013

Bug Fix

Subpixel gaps visible between the main glyph and the border (certain limitations)
Crash when resizing to certain window sizes
Unexpected slowdown 30 seconds after intense subtitles
Improve handling of empty VobSub frames
Double-clicking the tray icon doesn't open properties page on the same monitor it is called from
Subtitle were rendered at FPS value reported by Consumer, even when incorrect
Corruption with extremely large border sizes
CPU loop after external subtitle modification
Improve style override logic
Allow connection to Consumer even if values provided are invalid
Various stability fixes

Complete Changelog (http://code.google.com/p/xy-vsfilter/wiki/ReleaseNotes?tm=6)

__________

Primarily a bug-fix release, to sync with the bug-fixes and changes made in madVR 0.87.5. Installer will be added at a later date. madVR no longer loads XySubFilter itself.

You must ensure to run the 'Install' bat (not only replace) or else XySubFilter's autoload helper required for entering the DirectShow graph with external subtitles will not be installed.

sneaker_ger

5th March 2014, 19:54

Which git branch was 682 built from? I kinda lost track.

cyberbeing

5th March 2014, 20:01

xy_sub_filter_rc3 branch (https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc3)

GitHub requires tagging to make releases, so the exact 3.1.0.682 tree can be found here (https://github.com/Cyberbeing/xy-VSFilter/tree/3.1.0.682), or from links on the GitHub release (https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.1.0.682) page.

Most of the interesting (unstable) stuff we've been working recently has been backed out and delayed till a Beta3 release.

sneaker_ger

5th March 2014, 20:08

Thx...

mandarinka

5th March 2014, 21:18

Ah, great! Thanks for the update & continued work.

dansrfe

5th March 2014, 21:19

The position override isn't working properly in the XYSubFilter beta 2 build for me.

Is there a way to get the subtitles rendered with respect to the window size and its aspect rather than the video's size/aspect? This might also solve the bitmap subtitles from bluray discs from getting truncated when the position is overided beyond the border of the video's resolution.

cyberbeing

5th March 2014, 21:32

The position override isn't working in the XYSubFilter beta 2 build for me.
If you mean "Override Placement", that was changed in XySubFilter Beta1 to only apply to VobSub.

dansrfe

5th March 2014, 21:34

If you mean "Override Placement", that was changed in XySubFilter Beta1 to only apply to VobSub.

Ah, that's why it only works for bitmap subtitles. I set the vertical position to 99 and in a typical video A/R of 2.4 (black borders removed in encode) the subtitles get cut off beyond the video's border. Is it possible to position the bitmap subtitles with respect to the screen in this case?

Also, I'm curious, why was positioning removed for text subtitles?

Also, when I drag another file into MPC-HC (nightly) using madVR (latest), the player crashes. When XYSubFilter is not loaded, the player doesn't crash.

cyberbeing

5th March 2014, 21:45

Is there a way to get the subtitles rendered with respect to the window size and its aspect rather than the video's size/aspect? This might also solve the bitmap subtitles from bluray discs from getting truncated when the position is overided beyond the border of the video's resolution.
Is it possible to position the bitmap subtitles with respect to the screen in this case?

I do not believe any Subtitle Consumer has added support for rendering outside the video frame yet, if that's what you're asking. It should work with XySubFilter Beta2 for text-based subtitles if such support is added though. For bitmap subtitles like Blu-ray PGS, the rasterizer always outputs at frame size (usually 1920x1080) so repositioning may not be as easily possible.

Also, I'm curious, why was positioning removed for text subtitles?

Redundant. Positioning can be performed via the Style Editor.

Also, when I drag another file into MPC-HC (nightly) using madVR (latest), the player crashes. When XYSubFilter is not loaded, the player doesn't crash.

I do not believe MPC-HC has implemented drag-n-drop subtitle support for XySubFilter. If a crash occurs because of that, it's not our bug, or at least shouldn't be. Only MPC-BE has such support.

When you say 'drag another file' did you mean something else?

dansrfe

6th March 2014, 04:48

When I drag and drop another container file (mkv/mp4) then it crashes the player.

cyberbeing

6th March 2014, 05:11

No idea. Can anyone else reproduce this? If you have a crash dump, please upload it somewhere. If madVR is generating crash reports, download the PDB debug symbols for MPC-HC and XySubFilter and upload the next crash report.

Do you have any external subtitles in the directories you drag and drop files from? If so, which formats?

Is there anything special about your playback setup?

Installed Video Decoders & Splitters?

Any post-processing filters or MPC-HC shaders active?

Any subtitle filters other than XySubFilter.dll installed or active? VSFilter.dll? FFDShow? MPC-HC ISR?

Any filters you've added to MPC-HC External Filters?

Does it occur with both madVR and EVR-CP using XySubFilter in MPC-HC?

Does it occur with madVR using XySubFilter in MPC-BE?

Which OS?

Shii

6th March 2014, 11:32

After updating xySubFilter to latest 3.1.0.682 Beta2 and madVR to 0.87.5 subtitles no longer loads in Zoom Player 8.6.1 (Smart Play enabled). MadVR 0.87.4 and 3.1.0.682 works fine. Is any way to force loading subtitle filter without rolling back to 0.87.4?
VSFilter and ffdshow not installed, only registered new XySubFilter.dll. Using latest LavFilters for decoding and splitting.
I think it happens because latest change in madVR: * removed XySubFilter auto-loading functionality, it's now XySubFilter's job

cyberbeing

6th March 2014, 11:54

madshi

6th March 2014, 13:17

@cyber, can you write a small summary of what ZoomPlayer could/should do to support XySubFilter optimally? I'll then send it directly to the ZoomPlayer dev.

cyberbeing

6th March 2014, 13:48

Blight only needs to support XySubFilter with SmartPlay, the way he currently supports xy-VSFilter. They share the same API, so that part should be simple enough. The only time consuming part is likely rewriting the GUI, settings dialog, and subtitle filter loading logic, since XySubFilter could only be used with madVR. ZoomPlayer's SmartPlay is already fully manual graph building which manages detection/loading of external subtitles into xy-VSFilter itself. In that regard, the only other change is XySubFilter supports external Blu-ray PGS files (.sup). He likely just hasn't gotten around to adding XySubFilter SmartPlay support yet, probably since we haven't released a stable version. Not to mention that he usually likes to distribute all filters himself through the ZoomPlayer Download Center.

Kado

6th March 2014, 23:39

@cyberbeing

I'm having some issues with the new build (XySubFilter 3.1.0.682).
Basicaly MPC-HC (v1.7.3) crashes after opening a video using either EVR CP or madvr (v0.87.6). Such issues don't occur with the previous release (XySubFilter v3.1.0.546). Not all videos generate this issue but also happens if reopening some videos during playback.
I've downloaded the pdb files for mpc and xy-subfilter, set them in place and triggered the issue to generate dump files.

Dumps are here (http://www.mediafire.com/download/sq2s296gc8acarg/dump_1st_open.rar) (for both evr cp and madvr)
Video that triggers the crash here (http://www.mediafire.com/download/bxk1vwrs1jb8b84/[Asenshi]_Onee-chan_ga_Kita!_-_09_[B17FE372].mkv).
System specs here (http://firegoon.com/u/tc88wn.png).

If you require additional information or more testing let me know!

Thanks!

Kado

madshi

7th March 2014, 00:32

FWIW, the madVR crash report looks "good" to me. It should be helpful to the XySubFilter developer. Doesn't look like an "out of memory" problem.

cyberbeing

7th March 2014, 00:37

I'm having some issues with the new build (XySubFilter 3.1.0.682).
Cannot seem to reproduce this, so I may need to provide you a few builds with changes rolled back based on your dump & crash report to track down the cause. If luck has it, this will be the same issue dansrfe reported. Before I do that, could you use this logging build (https://www.mediafire.com/?bxixb7x9gbo7v4n) and upload the log it generates up until the crash occurs. The shorter the log the better, so try to delete it between attempts. If you could upload logs for a couple variations of triggering the crash, that could also be useful. You can edit the target in the .properties file, but currently I have it set to write to C:\

Edit: I've sent you a PM with some builds to test. Some of those may actually be less stable, but see if any resolve this particular crash.

EndlessD

7th March 2014, 06:51

The AutoLoader doesn't seem to work for me. The only way to load external subtitles with XySubFilter is to name them exactly the same as the videofile. Subtitles muxed with the video load fine.

I use MPC-HC 1.7.3 + LAV Filters 0.61.0 + madVR 0.87.6 + XySubFilter 3.1.0.682 BETA2.
XySubFilterAutoLoader & XySubFilter are set to Prefer in the External Filters settings (set merit doesn't work either).

Kado

7th March 2014, 09:15

@cyberbeing

Thanks, will do when I get back from work!

Sent from my SGS3 with Temasek 's CM11 & Tapatalk Pro!

cyberbeing

7th March 2014, 19:49

The only way to load external subtitles with XySubFilter is to name them exactly the same as the videofile.

This is expected behavior. Only subtitles found within the search paths, with identical file names will be loaded. 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

EndlessD

7th March 2014, 20:58

This is expected behavior. Only subtitles found with the search paths, with identical file names will be loaded. 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

Thanks for the fast answer!
I already thought that it was ment to be like that...
Isn't there a way to work around this? So XySubFilter gets always loaded, like it was before? I would have to rename 200+ files to get all my subtitles working.
Switching back to an older version of madVR fixes this, but I don't want to loose the new features of madVR.

cyberbeing

7th March 2014, 21:07

Kado

7th March 2014, 21:17

@cyberbeing

After testing with the files you have provided here's the results (file was always registered before testing):

additiondraw = crash
autoload = ok
bugfix = ok
merge = crash
vs2010 = crash
vs2013 = crash

Maybe the autoload code and the bugfixes are "incompatible" (well at least in my system).

Also here's the log (http://www.mediafire.com/view/513kovc01t6v5kw/XySubFilter.log) generated by the logging build you provided.

Hope this helps!

Thanks

Kado

cyberbeing

7th March 2014, 21:30

Thanks. The "bugfix" reverted our bug fixes, but not the auto loader or addition draw. So it would seems one of our bug fixes is causing a new crash on your system.

I'll PM you so more builds in awhile, to see if we can track down the specific commit.

Edit: PM sent
Edit2: I notice from your log you are using "ffdshow Audio Processor". If you uninstall ffdshow, does it resolve your crash with Beta2?
Edit3: You also appear to have set "Cache Size" to a very low 32MB. If you change this back to the default of -1 does it resolve your crash? (And yes, I realize text input for that Cache setting box behaves strangely, if it takes the -1 correctly, it should show "Auto" the next time used)

EndlessD

8th March 2014, 00:48

I'm not sure what you mean exactly, since even if XySubFilter is present in the graph in prior versions of madVR, those external subtitles still wouldn't be auto-loaded? Were you manually opening your subtitle files in prior versions? If you want XySubFilter Beta2 to always be present in the graph even when no subtitles are detected, open the configuration dialog and set 'Main -> Loading' to "Always Load".

Yes I was opening them manually all the time, no autoloading. I thought the AutoLoader was a autoloader for XySubFilter not for subtitles (dumb me).
The "Always Load" works fine! I messed around with settings yesterday and checked that too, but it didn't work maybe something interfered with it.
Thank You for your help!