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

[ikarad]

This project is dead?

[cyberbeing]

The project is still alive, it's just been stalled the past few months when we failed to find an easy & stable solution for preventing out-of-memory crashes. Our latest XySubFilter GIT build from a few months ago added a mechanism for limiting RAM usage, but while most of the time this functioned as expected, with certain memory intensive scripts the limiting mechanism would cause crashes. There is an inherent problem with memory management in all versions of VSFilter which needs be resolved. Ultimately what needs to be done is figuring out a way to reduce memory usage and improve performance with massive objects similar to Libass (which rarely uses more than 50-100MB RAM on such scripts), rather than just limit it and/or prevent crashes.

With XySubFilter scaling these memory issues are exacerbated compared to VSFilter.dll. We decided to hold off releasing a XySubFilter stable build until we figured out of a proper solution to the issue. We'd like to see scaling of heavy scripts in XySubFilter remain viable up to at least 4K UHD without running into memory and/or performance issues. Since this will likely require a major re-factor or re-write of the VSFilter core, the project got stalled since the developer was too busy for it at that time.

Work on xy-VSFilter project may slowly start back up soon, as the developer mentioned he wouldn't be as busy starting next month.

[Soukyuu]

Originally Posted by cyberbeing

Ultimately what needs to be done is figuring out a way to reduce memory usage and improve performance with massive objects similar to Libass (which rarely uses more than 50-100MB RAM on such scripts), rather than just limit it and/or prevent crashes.

Might be a silly question, but what stops you from ...copying the way libass does it?

[cyberbeing]

Things are rarely that simple.

[Soukyuu]

Well it's true that your algorithm is probably different, but shouldn't the concept at least be partially transferable?
The main reason I was asking though was in case it's a license issue or something along those lines.

[cyberbeing]

At this point, I'm more curious to see if Libass starts running into the same memory issues once they stop using glyph-by-glyph bitmap rendering along with astiob's 8x8 VSFilter-like supersampling commit added on top. The question is still up in the air as to what exactly causes the occasional large discrepancies between VSFilter and Libass memory consumption.

[mandarinka]

Could you perhaps make another testing/alpha "release" of XySubFilter (even if just provisional) from current codebase, if it is not too much trouble?

The last available binary (unless I missed something) has that bug with non-functioning reloading of subtitle files that were changed. It can be surprisingly annoying bug when you quality check/edit scripts for fansubs Otherwise the Subfilter flavour is pretty nice, it has befriended me quickly.

[SecurityBunny]

Originally Posted by mandarinka

Could you perhaps make another testing/alpha "release" of XySubFilter (even if just provisional) from current codebase, if it is not too much trouble?

I'd also like to see a new test build if time permits to compile one. Been following the github repo diligently. Many of the changes and fixes very much interest me, including the blur_be_fixes branch. I'd very much like to be able to test and use a newer build.

[cyberbeing]

The developer only became active a couple days ago, and there is a bit of a backlog at the moment. New builds of both xy-VSFilter (VSFilter.dll) and XySubFilter are planned. Code maintenance and some bugfixes will likely come first. Then we need to once and for all finalize the external subtitle autoloading behavior for XySubFilter. xy-VSFilter on the other hand is rather bugged in XySubFilter branches at the moment, so we need to figure out what to do about that.

That blur_be_fixes branch was spurred by recent conversions our dev had with astiob @Libass about differences between our \blur & \be implementation behaves compared to how the one in VSFilter 2.39 behaved. I wouldn't recommend touching that branch at the moment, since it has at least one confirmed subtitle corruption bug.

[JEEB]

I hope that after the VSFilter part has become possible to build on the current code base (the XySubFilter-related branch), you will look at some of the changes that me and Lord have brewed up on the CCCP side, such as the colormatrix reading .

[SecurityBunny]

Thanks for the update, Cyberbeing. I guess I'm just getting ahead of myself, becoming anxious looking at all the newer source commits. I tried to compile the source myself, but ran into issues. So the only way I'll be able to satisfy my craving to be 'up to date' is hoping a newer experimental build will be out sooner than later.

[cyberbeing]

Originally Posted by SecurityBunny

I tried to compile the source myself, but ran into issues.

What type of issues?

Did you remember to download and place "yasm.exe" in Visual Studio's ..\VC\bin directory?

Did you install GIT and use it to clone our source code?

If so, it should build cleanly with Visual Studio 2010 by just running build_vsfilter.sh in the root directory.

[SecurityBunny]

Originally Posted by cyberbeing

What type of issues?

Did you remember to download and place "yasm.exe" in Visual Studio's ..\VC\bin directory?

Did you install GIT and use it to clone our source code?

If so, it should build cleanly with Visual Studio 2010 by just running build_vsfilter.sh in the root directory.

I was using Visual Studio 2013 (2012) on Windows 8.1, downloaded the source manually off the github repository branch, as well as downloaded the windows SDK for 8.1 which includes the DirectX SDK I believe.

There were errors when it tried to convert everything over to the newer visual studio and when building the files. Then again, I may have become a little bit confused reading the 'HowToCompile.txt' from two years ago. I did however see recent commits regarding fixing compilation with Visual Studio 2012, which is why I used the latest IDE release.

https://github.com/Cyberbeing/xy-VSF...wToCompile.txt

Being unable to build the source myself isn't a big deal. Just means I'll have to wait for a new build to become available for testing. I'm hoping I'll be able to test the latest and greatest changes sooner rather than later considering the last release was back in July, 2013. I have also been using the latest test builds of MadVR, so I am eager to jump right into anything recent.

Perhaps I'll try compiling again later in the week.

[cyberbeing]

Currently we only officially support building with Visual Studio 2010.

Our Visual Studio 2012 project files were never fully optimized, and still produce bloated DLLs with slightly lower performance than our VS2010 builds the last time I tested it.

When I spoke of a need to do some code maintenance earlier, fixing conflicts and improving support for Visual Studio 2012 & 2013 in our project files was one of the things on our to-do list.

[kasper93]

Well you could just merge PRs https://github.com/Cyberbeing/xy-VSFilter/pulls this guy cleaned up repo pretty nice and remove a lot of garbage.

[cyberbeing]

Originally Posted by kasper93

Well you could just merge PRs https://github.com/Cyberbeing/xy-VSFilter/pulls this guy cleaned up repo pretty nice and remove a lot of garbage.

I was hopeful early last month when I tested them, but merging those pulls in their current state is likely not going to happen. They completely broke building with Visual Studio 2010, and didn't fix Visual Studio 2013 support. Unfortunately the submitter only tested his changes against Visual Studio 2012, and that's all they work with. They may still be used for inspiration though.

[SecurityBunny]

Originally Posted by cyberbeing

Currently we only officially support building with Visual Studio 2010.

Our Visual Studio 2012 project files were never fully optimized, and still produce bloated DLLs with slightly lower performance than our VS2010 builds the last time I tested it.

When I spoke of a need to do some code maintenance earlier, fixing conflicts and improving support for Visual Studio 2012 & 2013 in our project files was one of the things on our to-do list.

Apologies for going off topic again. I wiped my laptop completely to try and compile again, but still running into issues.

- Installed Visual Studio C++ 2010 Express.
- Installed GIT.
- Downloaded Win32 VS2010 yasm.exe from here and placed 'vsyasm.exe' & a copy renamed as 'yasm.exe' in '/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin'.

Launched Git Bash and ran the following commands.

- mkdir xy_sub_filter_rc2
- cd xy_sub_filter_rc2
- git init
- git remote add -t xy_sub_filter_rc2 -f origin https://github.com/Cyberbeing/xy-VSFilter.git
- git checkout xy_sub_filter_rc2

Navigated to 'C:\Users\Computer\xy_sub_filter_rc2' and ran the 'build_vsfilter.sh' file. The script console window kept closing immediately, so I ran it in command prompt. Here is the output. I assume this is the next issue stopping me from compiling.

Link to console output.

Any advice in how to properly compile would be much appreciated.

[cyberbeing]

It would seem Express versions do not contain devenv, but instead have a uniquely name file which serves a similar purpose.

Try changing:

devenv "'$solution'" /'$action' "'$configuration'" /project "'$project'"

to

vcexpress "'$solution'" /'$action' "'$configuration'" /project "'$project'"

near the end of the script and see if it functions.

[SecurityBunny]

Reverting back to devenv and updated to full Visual Studio 2010, build still seems to be failing.

xy_sub_filter.log
vsfilter_2010.log

Any other suggestions to fix compiling?

[cyberbeing]

That error is probably because you haven't installed VS2010 Service Pack 1.