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

SecurityBunny

6th February 2014, 08:28

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-VSFilter/blob/xy_sub_filter_rc2/docs/HowToCompile.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

6th February 2014, 11:15

kasper93

6th February 2014, 12:15

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

6th February 2014, 13:33

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

6th February 2014, 22:30

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 (http://yasm.tortall.net/Download.html) 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. (http://i.imgur.com/XZloMDo.png)

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

cyberbeing

7th February 2014, 01:23

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

7th February 2014, 02:47

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

xy_sub_filter.log (paste.ubuntu.com/6888719)
vsfilter_2010.log (paste.ubuntu.com/6888806)

Any other suggestions to fix compiling?

cyberbeing

7th February 2014, 04:21

That error is probably because you haven't installed VS2010 Service Pack 1 (http://www.microsoft.com/en-us/download/details.aspx?id=23691).

SecurityBunny

7th February 2014, 07:45

Ah! Silly me, that definitely was it. Thanks for all your help, cyberbeing. Finally able to compile the source into a functional build for testing. :)

mark0077

17th February 2014, 20:28

Hi guys, I know xySubFilter is still beta and is a wip but I have one question. I have an issue and I see very similar if not identical issues mentioned in both madVR and in xySubFilter bug reports. Its basically when using xySubFilter, when I reach the first frame that has some subtitles I get a block of frame drops reported in madVR. Rewinding and playing back over that portion shows 0 more drops. cpu usage spikes massively on that initial few frames where the subtitles appear.

Does anyone else have this or is it a known issue? I'm usually running about 60% cpu load with SVP interpolating to 60fps, but when testing with things like "Avatar" / "This Is It" that have subtitles, I get a big bunch of drops and cpu spike to 100% for a second or so at the first occurrence of subtitles. After that it seems fine and I don't get any more drops so looks to be only when the first subtitles appear.

Thanks in advance and I look forward to future versions of xysubfilter.

[ReX]

18th February 2014, 15:53

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.

Sorry, I didn't know they broke VS2010. :(
I wonder if I can install VS2010 after VS2013, probably not.

I will take a look into the VS2013 errors.

Edit: VS2013 compilation was fixed.
Edit 2: Fixed VS2010 compilation, turns out the problem was an WINVER define from the debug configurations, which I mistakenly assumed was correct and applied to all configurations.

cyberbeing

19th February 2014, 11:05

I have an issue and I see very similar if not identical issues mentioned in both madVR and in xySubFilter bug reports.
Which similar bug reports are you referring to?

Its basically when using xySubFilter, when I reach the first frame that has some subtitles I get a block of frame drops reported in madVR.
Rewinding and playing back over that portion shows 0 more drops. cpu usage spikes massively on that initial few frames where the subtitles appear.

What type of subtitles are we talking about? If you could provide a sample that may be helpful.

Which queue(s) drop first in madVR's CTRL+J stats right before the dropped frames occur?

Have you ensured to disable the MPC-HC ISR (http://forum.doom9.org/showpost.php?p=1637437&postcount=2), so they are not both rendering subtitles at the same time?

Check to make sure you don't have "Flush & Wait (Loop)" enabled under any madVR's Windowed or Exclusive Mode settings.

Does this same issue also occur when using XySubFilter with EVR-CP in recent MPC-HC versions?

Does this same issue also occur when using xy-VSFilter, MPC-HC VSFilter, or the MPC-HC ISR instead?

I'm usually running about 60% cpu load with SVP interpolating to 60fps

Do you also have dropped frames like this when not using SVP?

;1669107']Edit: VS2013 compilation was fixed.
Edit 2: Fixed VS2010 compilation, turns out the problem was an WINVER define from the debug configurations, which I mistakenly assumed was correct and applied to all configurations.

Next thing to look into, would be finding the compiler variable MPC-HC uses to eliminate the MFC bloat with VS2012 & VS2013, and only using the .../thirdparty/mfc/ directory when compiling with VS2010.

Another few comments:

The shell script should not be building xy_sub_filter_consumer.dll & unittest.exe by default, only VSFilter & XySubFilter + dependencies. Only occurs with VS2012 & VS2013.
-action clean causes the project to build when -compiler VS2012 or -compiler VS2013 is specified.
Your lib_update branch still has compile errors, but your other branch seems fine.
You should be using the WinXP compatible toolsets Visual Studio 2012 (v110_xp) & Visual Studio 2013 (v120_xp) and settings in those compilers.

JEEB

19th February 2014, 11:30

Next thing to look into, would be finding the compiler variable MPC-HC uses to eliminate the MFC bloat with VS2012 & VS2013, and only using the .../thirdparty/mfc/ directory when compiling with VS2010.
_AFX_NO_MFC_CONTROLS_IN_DIALOGS ? As noted in acad0a8 (https://github.com/mpc-hc/mpc-hc/commit/acad0a8).

BTW, I also recommend that at some point the project files move to being minimalistic themselves, and using a common properties file to set most of the settings that most probably are common between all of the projects :) . It's a boring thing in a solution that has many projects, but often leads to nice results since you do not have to care as much regarding if all projects do the same thing.

cyberbeing

19th February 2014, 13:09

_AFX_NO_MFC_CONTROLS_IN_DIALOGS ? As noted in acad0a8 (https://github.com/mpc-hc/mpc-hc/commit/acad0a8).
Thanks, that's hopefully the one.

BTW, I also recommend that at some point the project files move to being minimalistic themselves, and using a common properties file to set most of the settings that most probably are common between all of the projects :) . It's a boring thing in a solution that has many projects, but often leads to nice results since you do not have to care as much regarding if all projects do the same thing.

A couple weeks ago, fooled around with seeing if I could adapt MPC-HC's exact diirectory and project/solution structure to xy-VSFilter in order to make updating of dependencies a bit simpler. My first attempt at this didn't go so well though, as I took the brash approach of importing xy-VSFilter files wholesale on top of MPC-HC and then fixing things. Eventually I got stuck, as fixing all the includes, dependency differences, project/solution files was way outside my comfort zone. The more sane approach of adding such common properties files and updating the project/solution files only, I would expect go more smoothly. Maybe that's something else [ReX] would consider looking into.

JEEB, do you have any idea why MPC-HC removed libssf from VSFilter awhile back?

JEEB

19th February 2014, 13:33

JEEB, do you have any idea why MPC-HC removed libssf from VSFilter awhile back?
Given the fact of what SSF was (http://devel.aegisub.org/wiki/SubtitleFormats/SSF) (unfinished child of Gabest's ideas that was generally unused), I would guess its removal was mostly based on the fact that no-one actually used it for anything. And that its code added extra complexity to maintain.

Of course, it is possible that someone actually used that unfinished implementation, but nothing of the sort ever came up on the issue tracker, either.

mark0077

19th February 2014, 20:05

Hi cyberbeing

This is the bug report I'm referring to
https://code.google.com/p/xy-vsfilter/issues/detail?id=159

I have taken a screenshot from Avatar (see below), I'm not an expert on subtitles so am not sure what type of subtitle it is. Its the internal subtitles embedded into the blu-ray.

In madVR, I have set all queues as high as they will go, and the queues to drop at the first instance of the subtitles are backbuffer queue, and then render queue. The others don't seem to move. Because subtitle queue doesn't move does this mean its nothing to do with xysubfilter?

Heres the screenshot where after I seek to a few seconds before the subtitles, the frame drops start occuring as soon as the subtitle appear.
Screenshot (http://i58.tinypic.com/ztf21h.jpg)

mpc-be auto load subtitles is disabled.
"Flush & Wait (Loop)" isn't in any of my windowed or exclusive mode settings, only default flushing settings.
Using EVR-CP no subtitles appear at all with xySubFilter + mpc-be. Is this supposed to work? I was half expecting to see a similar frame drop / blip in EVR-CP's Ctrl-J Stats but not a budge.
With EVR-CP and xyVSFilter, I see no drops or blips in the CTRL-J graph.
With madVR and xyVSFilter, I again see no frame drops, none of the queues drop either. Its perfect.
With madVR and xyVSFilter but without SVP I get no frame drops, the render queue still drops slightly the first time the subtitle appears from 23-24 to 22-24

I assume its the combination of madVR / SVP and xySubFilter, the cpu / gpu usage just spikes so high during that very first subtitle. Why theres no problems the second time around I have no idea but heres my findings.

In terms of gpu usage, with madVR and xySubFilter and without SVP, heres how the gpu stats look according to gpu-z before the first subtitle appears. With SVP they are all that little bit higher.

Memory Used: 420MB
GPU Load: 23%
Memory Controller Load: 8%
Video Engine Load: 0%

The moment the first subtitle appears heres how the stats look.

Memory Used: 476MB
GPU Load: 27%
Memory Controller Load: 12%
Video Engine Load: 0%

For the remainder of the playback, the above stats remaing constant. Even rewinding to before the subtitle, resetting madVR's stats and letting it play back over it again I get 0 drops. Its only on the very very first subtitle, whatever happens at that time is causing the drops.

It doesn't matter how high or low I set my queues, the same pattern emerges. This was with 128 decoder / subtitle queue, with lower queues memory also takes a jump at the initial subtitle and the frame drops occur. Its like whatever is allocating that extra memory is causing the first spike which causes the drops, but after that, the memory already seems to be allocated so I get 0 frame drops until the next time I restart mpc / recreate the graph.

If a sample is needed I can upload one. Any idea what causes this?

Thanks

clsid

19th February 2014, 20:14

;1669107']Edit 2: Fixed VS2010 compilation, turns out the problem was an WINVER define from the debug configurations, which I mistakenly assumed was correct and applied to all configurations.
For XP compatibility you should use in all VS configs:
WINVER=0x501;PSAPI_VERSION=1

[ReX]

19th February 2014, 21:04

Next thing to look into, would be finding the compiler variable MPC-HC uses to eliminate the MFC bloat with VS2012 & VS2013, and only using the .../thirdparty/mfc/ directory when compiling with VS2010. Fixed

Another few comments:

The shell script should not be building xy_sub_filter_consumer.dll & unittest.exe by default, only VSFilter & XySubFilter + dependencies. Only occurs with VS2012 & VS2013. Fixed
-action clean causes the project to build when -compiler VS2012 or -compiler VS2013 is specified. Fixed
Your lib_update branch still has compile errors, but your other branch seems fine. (I force-push this one a lot so I'll have to test again)
You should be using the WinXP compatible toolsets Visual Studio 2012 (v110_xp) & Visual Studio 2013 (v120_xp) and settings in those compilers. Fixed (and also moved PlatformToolset to an external file)

_AFX_NO_MFC_CONTROLS_IN_DIALOGS ? As noted in acad0a8 (https://github.com/mpc-hc/mpc-hc/commit/acad0a8).

BTW, I also recommend that at some point the project files move to being minimalistic themselves, and using a common properties file to set most of the settings that most probably are common between all of the projects :) . It's a boring thing in a solution that has many projects, but often leads to nice results since you do not have to care as much regarding if all projects do the same thing.

Thanks, that's hopefully the one.
[...]
Maybe that's something else [ReX] would consider looking into.

I'll look into it.

For XP compatibility you should use in all VS configs:
WINVER=0x501;PSAPI_VERSION=1

It's not possible to compile the MFC hack with that WINVER define, even with VS2010, any ideas?

Compilation error:
10>..\..\..\thirdparty\mfc\afxglobals.cpp(2599): error C2039: 'ShellCreateItemFromParsingName' : is not a member of 'AFX_GLOBAL_DATA'
10> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxglobals.h(119) : see declaration of 'AFX_GLOBAL_DATA'

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxglobals.h:
#if (WINVER >= 0x0600)
[...]
HRESULT ShellCreateItemFromParsingName(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv);
#endif

cyberbeing

19th February 2014, 21:13

This is the bug report I'm referring to...
That is something else related to cache bug with text subtitles, which has been resolved in GIT. Your issue sounds like it's with PGS subtitles.

In madVR, I have set all queues as high as they will go, and the queues to drop at the first instance of the subtitles are backbuffer queue, and then render queue. The others don't seem to move. Because subtitle queue doesn't move does this mean its nothing to do with xysubfilter?

Heres the screenshot where after I seek to a few seconds before the subtitles, the frame drops start occuring as soon as the subtitle appear.
Screenshot (http://i58.tinypic.com/ztf21h.jpg)
...
If a sample is needed I can upload one. Any idea what causes this?

Yes, please provide a sample.

If only the render queue drops, this could be another issue with madVR requesting information but XySubFilter blocking the thread until the PGS subtitle finishes rendering. The odd part is you say this only occurs with the first subtitle line though, and not additional lines? In that case, it could just be a madVR performance issue when initializing display of PGS subtitles.

mpc-be auto load subtitles is disabled.
Using EVR-CP no subtitles appear at all with xySubFilter + mpc-be. Is this supposed to work?

Only MPC-HC supports the XySubFilter consumer in EVR-CP, please retest this there. Also re-test madVR in MPC-HC as well to ensure there are no differences.

Lastly check to see if you can reproduce this in madVR 0.86.9 [ madVR0869.zip ] (http://www.videohelp.com/tools/madVR/old-versions#download) to make sure this wasn't a madVR regression.

cyberbeing

19th February 2014, 22:05

;1669356']It's not possible to compile the MFC hack with that WINVER define, even with VS2010, any ideas?
You'll need to wait for clsid to respond on that, since he was the one who originally committed the MFC hack to MPC-HC along with WINVER=0x0601;PSAPI_VERSION=1. Though obviously 0x0601 is Win7, and "ShellCreateItemFromParsingName" in afxglobals.cpp does not exist on WinXP. It certainly hasn't caused any WinXP bug reports, so maybe VSFilter doesn't use that MFC function? If this is an issue, I have no idea how to fix the MFC hack properly.

[ReX]

19th February 2014, 22:46

You'll need to wait for clsid to respond on that, since he was the one who originally committed the MFC hack to MPC-HC along with WINVER=0x0601;PSAPI_VERSION=1. Though obviously 0x0601 is Vista, and "ShellCreateItemFromParsingName" in afxglobals.cpp does not exist on WinXP. It certainly hasn't caused any WinXP bug reports, so maybe VSFilter doesn't use that MFC function? If this is an issue, I have no idea how to fix the MFC hack properly.

Do you guys even support XP currently?
The file common.props already "WINVER=0x0601" in there.

clsid

19th February 2014, 23:00

The important part is PSAPI_VERSION=1, which you should use in all configs. You can use WINVER=0x0600 for the VS2010 config to fix the compilation. Should run fine on XP as long as no Vista+ functions are used. The MFC stuff should only be included in the 2010 solution.

For 2012/2013 you could probably drop the WINVER define. Instead use <PlatformToolset>v110_xp</PlatformToolset> and <PlatformToolset>v120_xp</PlatformToolset>.

mark0077

19th February 2014, 23:15

cyberbeing cheers for the replies.

I installed mpc-hc and disabled autoload subtitles etc, and hooked up to ffdshow raw to get SVP working. Heres my findings.

mpc-hc + madVR = same frame drops the first time the subtitle appears, rewinding and playing back over it theres 0 drops.
mpc-hc + evrcp = Although the dropped count in mpc statistics window doesn't increase, the CTRL-J graph visibly makes a huge jerk, and the image does look to drop some frames, but then both graph and smoothness immediately returns to normal. Rewinding and playing back over the same part shows a very similar jerk in the graph but the dropped count doesn't increase again, its hard to visually tell whether its any better the second time around with evrcp. (Can mpc statistics dropped count be trusted for mpc-hc?)

I have also now just tried reverting to madVR 0.69 and wow, 0 frame drops :O Actually all versions are fine except from 0.87.4 and onwards. 0.87.3 has 0 frame drops. I guess its something that I need to bring to madshi on the madVR thread. In the meantime I'll prepare a sample.

EDIT: Sample uploaded here https://www.mediafire.com/?0x4jr0ho6seup3z and madVR bug created http://bugs.madshi.net/view.php?id=153

cyberbeing

19th February 2014, 23:41

;1669377']Do you guys even support XP currently?
The file common.props already "WINVER=0x0601" in there.

That what I was saying, but xy-VSFilter has always functioned just fine on WinXP. For the longest time, I both built and tested xy-VSFilter on WinXP only.

The important part is PSAPI_VERSION=1, which you should use in all configs. You can use WINVER=0x0600 for the VS2010 config to fix the compilation. Should run fine on XP as long as no Vista+ functions are used. The MFC stuff should only be included in the 2010 solution.

Would the MFC hack still be valid if I just added "#if (WINVER >= 0x0600)" around those "ShellCreateItemFromParsingName" entries in .../mfc/afxglobals.cpp and used "WINVER=0x501;PSAPI_VERSION=1" as you originally stated? It seems to compile fine if I then replace MAXINT32 with INT32_MAX in GFN.cpp.

#if (WINVER >= 0x0600)
HRESULT AFX_GLOBAL_DATA::ShellCreateItemFromParsingName(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv)
{
return SHCreateItemFromParsingName(pszPath, pbc, riid, ppv);
}
#endif

#if (WINVER >= 0x0600)
HRESULT AFX_GLOBAL_DATA::ShellCreateItemFromParsingName(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv)
{
static HMODULE hShellDll = AfxCtxLoadLibrary(_T("Shell32.dll"));
ENSURE(hShellDll != NULL);

typedef HRESULT (__stdcall *PFNSHCREATEITEMFROMPARSINGNAME)(
PCWSTR,
IBindCtx*,
REFIID,
void**
);

PFNSHCREATEITEMFROMPARSINGNAME pSHCreateItemFromParsingName =
(PFNSHCREATEITEMFROMPARSINGNAME)GetProcAddress(hShellDll, "SHCreateItemFromParsingName");
if (pSHCreateItemFromParsingName == NULL)
{
return E_FAIL;
}

return (*pSHCreateItemFromParsingName)(pszPath, pbc, riid, ppv);
}
#endif

GFN.cpp
while(wtf.ReadString(fn) && fn.Find(_T("://")) >= 0)
{
SubFile f;
f.full_file_name = fn;
f.extra_name = fn.Mid(fn.ReverseFind('/')+1);
f.ext_order = INT32_MAX;
f.path_order = INT32_MAX;
ret.Add(f);
}

common.props
<PreprocessorDefinitions>WINVER=0x0501;PSAPI_VERSION=1;_WINDOWS;WINDOWS;_USE_MATH_DEFINES;%(PreprocessorDefinitions)</PreprocessorDefinitions>

sneaker_ger

20th February 2014, 00:53

In that case, it could just be a madVR performance issue when initializing display of PGS subtitles.

Does madVR even know or care about the subtitle format?

clsid

20th February 2014, 01:04

@cyberbeing
Completely removing the function should be fine since it isn't used anyway. If it compiles and runs then I would say go for it.

cyberbeing

20th February 2014, 01:36

Does madVR even know or care about the subtitle format?

Yes and no. No it doesn't know the subtitle format specifically, but yes it does care and treat such formats differently. Bitmap subtitles formats need to be scaled by madVR from native subtitle resolution to output resolution. Normally with text subtitles, XySubFilter renders directly to output resolution without madVR scaling anything. Though if you enabled "Render to Original Video Size", even text subtitles will be scaled by madVR.

@cyberbeing
Completely removing the function should be fine since it isn't used anyway. If it compiles and runs then I would say go for it.

Okay, thanks.

[ReX]

20th February 2014, 03:17

Tested "_AFX_NO_MFC_CONTROLS_IN_DIALOGS" with VS2013:
VSFilter.dll:
Before 2.96MB
After: 1.55MB
VS2010+MFC bloat fix: 1.54MB

XySubFilter.dll:
Before 2.72MB
After: 1.32MB
VS2010+MFC bloat fix: 1.31MB

Edit: the "lib_update" branch seems to be compiling fine, let me know if there's any problem (weirdly enough, the DLLs are even smaller with the updated libraries).

cyberbeing

20th February 2014, 10:43

;1669429']Tested "_AFX_NO_MFC_CONTROLS_IN_DIALOGS" with VS2013:
VSFilter.dll:
Before 2.96MB
After: 1.55MB
VS2010+MFC bloat fix: 1.54MB

XySubFilter.dll:
Before 2.72MB
After: 1.32MB
VS2010+MFC bloat fix: 1.31MB
Looks good. I wonder why the VS2012 builds come out 0.10MB larger then VS2010 & VS2013. Not worth worrying about though.

;1669429']Edit: the "lib_update" branch seems to be compiling fine, let me know if there's any problem (weirdly enough, the DLLs are even smaller with the updated libraries).

Logging builds (see vsfilter_config.h) are broken in the "lib_update" branch by the new log4cplus version, and even normal builds are throwing out log4cplus warnings during compile. I'd just say revert "Log4cplus library updated from v1.0.4 to v1.1.2", and not worry about it. Our developer will update his custom logging function utilizing newer Log4cplus releases in due time, if he thinks it necessary.

Also it seems you copied over the entire ~91MB Boost library, instead of just the ~12MB of what we needed. Take a look at Update boost to boost 1.55.0 [PART.1] (https://github.com/Cyberbeing/xy-VSFilter/commit/cfa10edbd2b9bd3d2e030ef3b5d8cc1c9f2dc9a9) & Update boost to boost 1.55.0 [PART.2] (https://github.com/Cyberbeing/xy-VSFilter/commit/c6759325bbb39a06ac5a031a393b23353dd69e4c) as a reference for which files can be removed.

If your new VSFilter.sln could be moved to the repository root directory as well, that would make it more convenient. May as well remove those mpc_vs2008 & mpc_vs2005 solution files while your at it.

I see, "warning MSB8030: The linker switch "Minimum Required Version" requires "SubSystem" to be set" when building. Simple fix.

Aegisub has a couple changes which may be worthwhile as well:
Convert MFC-using stuff to Unicode (https://github.com/tgoyne/xy-vsfilter/commit/76ebd510b4385f071d7122d3ff7352d779074b52)
Build with /Gw (https://github.com/tgoyne/xy-vsfilter/commit/9cfda339482ea539304a67846ed42bf3fffa6436) (VS2013 only)

Clean up common.props to remove unused configurations like "Release Filter" and "Release Lite" which only exist in MPC-HC.

-action clean causes the project to build when -compiler VS2012 or -compiler VS2013 is specified.
When you look into resolving this, it would also be worthwhile for VS2010, VS2012, VS2013 to have all their compiled libraries and objects output in separate directories for each project and compiler. Keep each compiler's build outputs and cleaning operations partitioned from each other, so they don't build over or clean a different compiler's outputs.

[ReX]

20th February 2014, 19:29

I didn't see there were new commits to the repo, I'll be easier to sync the branch and cherry-pick the changes on top of it.

If your new VSFilter.sln could be moved to the repository root directory as well, that would make it more convenient. May as well remove those mpc_vs2008 & mpc_vs2005 solution files while your at it.

See: https://github.com/Cyberbeing/xy-VSFilter/pull/4
Or is that not good enough?

Also, I fixed some stuff already, see here (http://forum.doom9.org/showpost.php?p=1669356&postcount=270).

cyberbeing

20th February 2014, 23:24

Ah, I remember seeing that pull but forgot it wasn't already merged in your other branches. Took another look and the removed files seem fine.

Which reminds me, I should probably create a .gitattributes file and normalize newlines. I think there may still be a few files with mixed eol return methods on the repository. Came up with this (https://www.mediafire.com/?cac7tuk14jiy94l) very quickly, but that operation is probably best done last after any pulls are merged.

Thanks for all your work on this [ReX].

[ReX]

20th February 2014, 23:29

I did some pulls to both branches, let me know if we need to change something before you can merge them.

After the merge we can get started on using the common.props file, there are some options (not mutually exclusive):
a) cleanup redundant properties from the project files that use it currently
b) create a *.props file just for the 3 VSFilter projects (maybe just temporarily) since they are pretty much the same project
c) fix common.props to play nice with the VSFilter projects

cyberbeing

21st February 2014, 11:16

Debug builds are failing. It seems there are a few more lines beyond Aegisub's commit which need to be changed in VirtualDub's debug.cpp to be compatible with the MFC change.

MessageBox -> MessageBoxA
wsprintf -> wsprintfA

64bit builds are also failing, but that seems to be our fault. A previous manual merge from MPC-HC missed a line in plugins.cpp. May as well go ahead and fix that on your branch [ReX].

Change plugins.cpp (line 668) from:
dst.bits = (LPVOID)fa->src.data;
to
dst.bits = (BYTE*)fa->src.data;

For the shell build script, it should be modified to either accept both "vs2010|vs2012|vs2013" & "VS2010|VS2012|VS2013" or just abort with invalid argument instead of allowing the following to occur:

-action clean causes the project to always clean with VS2013 when -compiler vs2012 or -compiler vs2010 is specified.

-plat x64 -compiler vs2012 & -plat x64 -compiler vs2010 calls %VS120COMNTOOLS% and compiles with VS2013.

Essentially, I think it's a bad idea to fallback to %VS120COMNTOOLS% and succeed, when an invalid argument is passed via -compiler.

[ReX]

21st February 2014, 19:32

Done, the build script will now abort if the compiler flag is not recognized.

Also, any reason the installer script is not included in the repository?

cyberbeing

21st February 2014, 21:58

;1669759']Also, any reason the installer script is not included in the repository?
A combination of forgetfulness, and not thinking it necessary. I probably should though, since it seems shortly after making a release I always accidentally delete it a few weeks later, wiping out all changes, when cleaning up untracked files from the Git repository... I guess you could add a 'distrib' folder to root as a placeholder for an installer script, but at this time I have nothing up to date to place in it. When the time comes for another release, I'll need to re-adapt it from MPC-HC's VSFilter installer script again.

That reminds me of something else which you could help out with. Could you add the static unrar support from MPC-HC to our repository and changes required to XySubFilter & xy-VSFilter? I made an attempt at this at one point, but was having trouble figuring out how to integrate it into the project files and enable it to link properly. The related commits can be found, here (https://github.com/mpc-hc/mpc-hc/commits/master/src/thirdparty/unrar), here (https://github.com/mpc-hc/mpc-hc/commit/cf2e54265644a24c91671331a566b2c6f2651333), here (https://github.com/mpc-hc/mpc-hc/commit/0c9afa6dca90811c8cadb5da517c9abb9457c16b), and here (https://github.com/mpc-hc/mpc-hc/commit/b18faab4208d8368d28c7b51afe5a73bbc90b05e). This would remove the need for a separate unrar.dll to be installed on the system for VOBSUB in rar support.

[ReX]

21st February 2014, 23:19

I'm gonna try to get static UnRAR into lib_update, so if you wanna merge the other branch, you can go ahead.

cyberbeing

22nd February 2014, 00:04

I wasn't really planning on doing any merge until at least Monday away, so you have time. This weekend, I'll likely re-verify everything once again and do some tests to ensure builds from each compiler are functioning as expected. If everything looks good, I'll push it as a new xy_sub_filter_rc3 branch.

Afterwords, if you could create separate pull requests for your changes which are adapted to the vsfilter_rc branch, that would also be useful.

[ReX]

22nd February 2014, 01:30

I pushed static UnRAR to the lib_update branch, seemed like the right place for it.
I will see what can be backported to the vsfilter_rc branch.

cyberbeing

22nd February 2014, 03:11

x64 Debug is failing to build with all compilers:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(714,5): error MSB3191: Unable to create directory "C:\Users\Alex\Documents\xy_vsfilter\src\thirdparty\log4cplus\msvc\.\C:\Users\Alex\Documents\xy_vsfilter\bin\obj10\Debug_Unicode_x64\log4cplus_static". The given path's format is not supported.
...
LINK : fatal error LNK1104: cannot open file 'log4cplus_staticD.lib'

[ReX]

22nd February 2014, 04:16

That's caused by some properties in the log4cplus.props file, I will do a commit correcting them and actually merging the common properties there.

cyberbeing

22nd February 2014, 06:25

Another few things noticed:

Add '#define USE_UNRAR_STATIC' as a togglable variable somewhere, possibly vsfilter_config.h, instead of always being forced.

Rename 'UNRAR.H' & 'UNRARDLL.TXT' to 'unrar.h' & 'unrardll.txt'

Change 'EnableEnhancedInstructionSet' from 'StreamingSIMDExtensions' to 'NotSet' in common.props. This was a mistake on our part during a previous merge. Ever since we added sse2 runtime detection, minimum requirement was supposed to be MMX.

Enable Whole Program Optimization (LTCG) for all projects

Add "Release Unicode" & "Debug Unicode" as 'Or' conditions to common.props

Set libssf & unrar projects as \Ob1 \Os to cut down on binary size a bit, since these are rarely used and not particularly performance critical.

[ReX]

22nd February 2014, 09:03

Done. That goes to show even projects already using common.props have a lot of redundant properties.

cyberbeing

22nd February 2014, 15:34

For some reason 'Configuration Properties -> General' shows 'No Whole Program Optimization' for all projects, while 'C++ -> Optimization' is set to 'Yes (/GL)' & 'Linker -> Optimization' is set to '(/LTCG)'. As far as I'm aware, 'Whole Program Optimization' under 'Configuration Properties -> General' is the toggle for the default state of both /GL & /LTCG, and if set properly there should be no need for additional overrides. Even though this is cosmetic only, it would be nice to have the 'General' setting show 'Use Link Time Code Generation' to avoid confusion when building from the solution file.

[ReX]

22nd February 2014, 20:08

We need a file like platform.props for that, meaning, it needs to be loaded outside of "PropertySheets".
I think the best way to handle this is to rename platform.props to something like "configuration.props", so it can be also used for other things in the "Configuration" PropertyGroup.

Edit: I should have done that to begin with, it was way easier.

sexus

22nd February 2014, 22:45

got a issue to report guys

xysubfilter and xysubfilter autoloader are currently broken so it would seem, ive used a january build of ranphas lav megamix and ive noticed with ass subs that if i run them in anything but a regular window aka maximized or fullscreen , the screen freezes

after a couple secs while playing , the audio continues thou , so i have to end potplayer over taskmanager , now with the new lav megamix build i dont have the issue no more since theyre currently disabled by ranphas new potplayer config, is xysubfilter currently broken or wtf

heres a link to ranphas lav megamix build page

http://imouto.my/configuring-potplayer-for-gpu-accelerated-video-playback-with-dxva-or-cuda-and-also-high-performance-software-decoding/comment-page-89/#comments

btw ive noticed the issue is still there as soon as you set both filters to prefer again in the latest lav build so its not the builds its xysubfilter , freezes on maximized or fullscreen with ass subs after a few secs, help

cyberbeing

23rd February 2014, 01:38

cyberbeing

23rd February 2014, 05:17

@[ReX]

unit_test project:

Build dependencies are not set correctly in the solution file.

_WIN32_WINNT not defined

sexus

23rd February 2014, 12:13

The GIT builds of XySubFilter do not have any specific freezing issue with Potplayer + LAV Filters + madVR that we are aware of.

That said, we do not offer support of unofficial builds at all. From what I remember, the memory limiter "More -> Cache Size (MB)" was broken in that 3.1.0.640 version they are distributing, and would cause occasional crashes at the default value. You could try setting "Cache Size (MB)" to 2048 and see if the issue goes away, as that's how I personally was working around the issue when development got stalled. A couple bugs related to memory limiter crashes were fixed a few weeks ago, but there are other issues you may run into with the latest GIT. If XySubFilter Beta 3.1.0.546 works for you, I recommend you just use that for now until we make another official release.

Otherwise, if the issue still occurs, you could ask ranphas for a full set of PDB debug symbols for all components and generate a madVR crash report with CTRL+SHIFT+ALT+BREAK the next time the freeze occurs. madVR's freeze/crash logs can be quite useful for pointing out offending code when the necessary PDB debug symbols are present.

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