Log in

View Full Version : xy-VSFilter Project (High Performance VSFilter Compatible Subtitle Filters)


Pages : [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

cyberbeing
19th July 2013, 17:15
Our project was first publicly released in 2011, with the goal of bringing VSFilter performance closer to that of Libass. We succeeded.
xy-VSFilter has been included in most well known codec packs (CCCP, K-Lite, Shark, KCP), as well as distributed with players like Zoom Player.

Now in 2013, we bring XySubFilter, a collaboration with madshi (developer of madVR) using a brand-new subtitle interface for high quality rendering.
__________

Stable Release
The current xy-VSFilter stable version is: 3.0.0.306 (git 9a21450)
The current XySubFilter stable version is: 3.1.0.752 (git 7cdd471)

xy-VSFilter .zip Archive (32-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.0.0.306/xy-VSFilter_3.0.0.306_x86.zip) | xy-VSFilter .zip Archive (64-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.0.0.306/xy-VSFilter_3.0.0.306_x64.zip)

Debug Symbols for XySubFilter 3.0.0.306 (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.0.0.306/xy-VSFilter_3.0.0.306_Debug_Symbols.7z)

Installation Instructions (http://code.google.com/p/xy-vsfilter/#Install)

Troubleshooting Q&A (http://code.google.com/p/xy-vsfilter/#Troubleshooting_Q&A)


XySubFilter .zip Archive (32-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.752/XySubFilter_3.1.0.752_x86.zip) | XySubFilter .zip Archive (64-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.752/XySubFilter_3.1.0.752_x64.zip)

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

Note: XySubFilter requires a compatible subtitle consumer. We recommend madVR 0.87.5+ (http://madshi.net/madVR.zip) or MPC-HC 1.7.2+ (EVR-CP) (http://mpc-hc.org/)

After downloading XySubFilter, 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.
__________

Preview Release

The current xy-VSFilter beta version is: None
The current XySubFilter beta version is: None
__________

What Is Different

Recent Changelog (https://github.com/Cyberbeing/xy-VSFilter/releases)
Old Changelog (http://code.google.com/p/xy-vsfilter/wiki/ReleaseNotes?tm=6)

Significantly faster overall compared to Libass.
Up to multiple orders of magnitude faster than VSFilter 2.41

High resolution subtitle rendering (XySubFilter only)
External support for PGS/HDMV subtitles (XySubFilter only)
New Style Override Dialog (XySubFilter only)
Force Default Style (XySubFilter only)
Support U+10000-U+10FFFF UTF-8 encoded character (XySubFilter only)
Subpics are now drawn directly in YUV/RGB as needed to improve performance
Official VSFilter always rendered subtitles in RGB and did a RGB -> YUV conversion when outputting YUV formats
Floating-point Gaussian Blur implementation (higher quality + significantly faster with large blur values)
More efficient Border code (higher quality + up to 12x faster with large border sizes)
More efficient Clip code (significantly faster + up to 1.8GB reduction in RAM usage when rendering gradients)
More efficient Color Conversion, Chroma Placement, Alpha Blending, and Rasterization code (SSE2 optimized)
Alpha blending on dirty areas of the frame only
Alpha-blending with sub-sampled/interlaced chroma where applicable
Addition of numerous caches to speed up animated effects
Proper implementation of animation detection to speed up static typesetting
New script parser to speed up loading of very large subtitle scripts
75% reduction in CPU load overhead when idle


__________

Create New Bug Report (http://code.google.com/p/xy-vsfilter/issues/entry)

Reported Issues List (http://code.google.com/p/xy-vsfilter/issues/list)

cyberbeing
19th July 2013, 17:16
MPC-HC & MPC-BE Users:
http://i.imgbox.com/te6UYrFS.png

Failure to do so with xy-VSFilter (VSFilter.dll) will result in it being blocked and not used.

Failure to do so with XySubFilter will in result in horrible performance since the ISR will be rendering subtitles with madVR at the same time as XySubFilter.
If you are not achieving near-identical performance with XySubFilter+madVR compared to xy-VSFilter+madVR, this is the most likely reason why.

cyberbeing
19th July 2013, 17:16
Reserved

madshi
19th July 2013, 17:21
From what I can see, XySubFilter should combine all advantages of the MPC-HC internal subtitle renderer (high-resolution rendering, DXVA decoding compatability) with all advantages of VSFilter (correct colors, correct drawing of all ASS effects) and all advantages of xy-VSFilter (less CPU consumption etc). So for madVR users it should be the ultimate subtitle rendering solution. Of course rendering subtitles at a higher resolution does come with a cost (slightly higher CPU and GPU consumption), but it shouldn't be too much, I hope...

There's one limitation: The combination of XySubFilter + madVR only works properly if your GPU is able to perform alpha blending in more than 8bit. Some older GPUs (e.g. NVidia 9xxx series up to 2xx or maybe 3xx) can only perform alpha blending up to 10bit. For these GPUs you have to enable the madVR option "use 10bit image buffer instead of 16bit". Newer generation GPUs have no problem performing alpha blending at 16bit. Very very old GPUs might not even be able to do alpha blending at 10bit. If you have such a GPU you may have to stick with xy-VSFilter or the internal MPC-HC subtitle renderer.

wanezhiling
19th July 2013, 18:03
@madshi, can you post an standard ass/ssa sample file and screenshots between 16bit and 10bit/8bit? Then we can be sure if our GPUs is capable of "XySubFilter + madVR". :)

zero9999
19th July 2013, 18:04
There's one limitation: The combination of XySubFilter + madVR only works properly if your GPU is able to perform alpha blending in more than 8bit. Some older GPUs (e.g. NVidia 9xxx series up to 2xx or maybe 3xx) can only perform alpha blending up to 10bit. For these GPUs you have to enable the madVR option "use 10bit image buffer instead of 16bit". Newer generation GPUs have no problem performing alpha blending at 16bit. Very very old GPUs might not even be able to do alpha blending at 10bit. If you have such a GPU you may have to stick with xy-VSFilter or the internal MPC-HC subtitle renderer.


<__ar> tp7, with that alpha blending issue, uh i managed to trigger it by changing rgb levels from pc -> auto in the most recent one i built. when i changed it back to pc it worked fine.
...
<__ar> tp7, yeah so changing RGB Level from Auto->PC in xy_sub_filter settings fixes the black box problem.
<__ar> leaving it on tv or auto
<__ar> causes the alpha blending to fail


any idea why this would fix the issue?

pirlouy
19th July 2013, 18:13
I don't manage to get *.srt subtitles to work.

Windows 7 x64
MadVR 0.86.9
Lav Filters 0.58.1
XySubFilter 3.1.0.546
MPC-BE dev 3073 (http://dev.mpc-next.ru/index.php/topic,1648.0.html) 32bits

I don't have the green arrow in systray. Which filter is responsible to detect .srt file (with the same name as the video file) ?

Embed subtitles are working though. FYI, I have uninstalled xy-VSFilter in order to have only XySubFilter.

Soukyuu
19th July 2013, 18:25
I can confirm setting RGB output level to PC fixes the opaque box problem for me (260GTX) without having to switch to 10bit image buffer.

edit: how well threaded is XySubFilter? I'm still having dropped frames on some overstyled subtitles, without my CPU hitting 50% usage. Shouldn't be an I/O problem since I also tested playing back the same video from a RAM disk and it stuttered just as bad. madvr's OSD shows subtitle queue dropping to 0 so XySubFilter should be the one causing it. My CPU is an AMD Phenom II X4 970BE@4GHz.

nevcairiel
19th July 2013, 18:47
@madshi, can you post an standard ass/ssa sample file and screenshots between 16bit and 10bit/8bit? Then we can be sure if our GPUs is capable of "XySubFilter + madVR". :)

There is no big difference visible that you can easily screenshot between 16 or 10-bit, you would notice if your GPU is not compatible when the subtitles have a black opaque box around them.

wanezhiling
19th July 2013, 19:10
You would notice if your GPU is not compatible when the subtitles have a black opaque box around them.
Thx, got it.


http://forum.doom9.org/showpost.php?p=1637413&postcount=1398
@cyberbeing, why XySubFilter is still in filter chains under such situations?

Overdrive80
19th July 2013, 19:19
Great, is big new. Thanks for your effort.

Keiyakusha
19th July 2013, 19:41
Is it possible to make an option for XySubFilter to apply blur to the subtitles before they are rendered on the screen? Possibly with selectable strength.
For example I'd like to have some equivalent to gaussing blur with radius 0.1-0.5 (edit: well, this is for 1080p screen, for bigger screens I probably want more)
Or this is should be request for the consumer?

Nevilne
19th July 2013, 20:06
^
Use 8x8 bilinear Subpixel Position

Keiyakusha
19th July 2013, 20:32
^
Use 8x8 bilinear Subpixel Position

I don't see how it helps.
8x8 (https://dl.dropboxusercontent.com/u/110558786/Comparison/XySubFilter/8x8.png) 8x8bilinear (https://dl.dropboxusercontent.com/u/110558786/Comparison/XySubFilter/8x8b.png)
0.5gauss (https://dl.dropboxusercontent.com/u/110558786/Comparison/XySubFilter/0.5g.png) <- I want this and possibility to set it stronger or weaker.

Edit: and yes I tried setting layout res to something like 576p and checking "render at video res", this is what I'll use probably, but it adds aliasing.

Warlock
19th July 2013, 20:34
From what I can see, XySubFilter should combine all advantages of the MPC-HC internal subtitle renderer (high-resolution rendering, DXVA decoding compatability) with all advantages of VSFilter (correct colors, correct drawing of all ASS effects) and all advantages of xy-VSFilter (less CPU consumption etc). So for madVR users it should be the ultimate subtitle rendering solution. Of course rendering subtitles at a higher resolution does come with a cost (slightly higher CPU and GPU consumption), but it shouldn't be too much, I hope...

There's one limitation: The combination of XySubFilter + madVR only works properly if your GPU is able to perform alpha blending in more than 8bit. Some older GPUs (e.g. NVidia 9xxx series up to 2xx or maybe 3xx) can only perform alpha blending up to 10bit. For these GPUs you have to enable the madVR option "use 10bit image buffer instead of 16bit". Newer generation GPUs have no problem performing alpha blending at 16bit. Very very old GPUs might not even be able to do alpha blending at 10bit. If you have such a GPU you may have to stick with xy-VSFilter or the internal MPC-HC subtitle renderer.

The GeForce 8600GT has alpha blending?
This here is another question I have. When the XySubFilter is installed, looks like this:

http://i.imgur.com/Qr8zLGo.jpg

When the xy-VSFilter looks like this:

http://i.imgur.com/q3XaV74.jpg

It's supposed to be so even with the XySubFilter installed? Another thing I noticed was regarding the pin info generated by lav. When the xy-VSFilter is installed, the pin info output equals pin info input, in the case of the video image is 720p. Already in XySubFilter, Pin out information generated is 2048x720. Is that correct?

TheShadowRunner
19th July 2013, 20:38
Thank you for this beta of xySubFilter, I just tested and have a couple of questions / bugs to report:
My setup: WinXP SP3, Zoom Player Max, xySubFilter beta 3.1.0.546 (removed all traces of previous XYVSfilter/VSFilter), madVR 0.86.9, newest Haali 1.13.138.14.

Bugs:
1. The subtitles never display when they are embedded!? (for exemple all the matroska files I tested).
madVR does report "subtitle queue 7-8/8" so I know the filter is connected.
On the property page of xySubFilter, Language is empty and grayed out, like if it wasn't able to load the subtitle track at all.
"Loading when needed" with "External" and "Embedded" checked.
Please see: xysubfilterbug.png (http://videoff7.free.fr/xysubfilterbug.png)
External subtitles are picked up and work correctly.

2. The "PAR compensation" setting doesn't stick. I chose "Accurate Size", restart playback, and it's reset to "Disabled". (even tried to force automatic_par_compensation to reg_dword value 3, no go)

Questions:
3. What is the purpose (if any) of the option "Render To Original Video Size" when "Use Original Video Size" is selected in the dropdown menu?

4. What is the difference between "Auto" and "Guess" settings for the YCbCr matrix ?
Please let me know!

huhn
19th July 2013, 20:53
at 1: try lavfilter haali is so old the page is even down.

TheShadowRunner
19th July 2013, 20:55
at 1: try lavfilter haali is so old the page is even down.

This very Haali was released a month ago. And it works perfectly fine with XY-VSFilter/VSFilter, that's not it.
(edit: as you can see on the picture i linked, the subtitle track was auto-selected correctly in XYSubFilter context menu)

DarkSpace
19th July 2013, 21:08
PAR compensation
PAR Compensation broke, use Layout Resolution instead (set it to anamorphic-corrected video size).
What is the purpose (if any) of the option "Render To Original Video Size" when "Use Original Video Size" is selected in the dropdown menu?
Those two are totally separate things.
Render To Original Video Size makes XySubFilter output subtitles at video resolution instead of using the scaled output resolution.
Use Original Video Size sets the Layout Resolution to use the original video size.
What is the difference between "Auto" and "Guess" settings for the YCbCr matrix ?
Auto uses the ASS script's YCbCr Matrix flag if it's present and otherwise defaults to using TV.601 (or, for PC-range content, PC.601) YUV values.
Guess chooses the YUV values to use by resolution, although I don't know if it attempts to read the YCbCr Matrix field first.

huhn
19th July 2013, 21:13
that's "normal" that xysubfilter is loaded with every file at least for me. it's maybe a bug.

when i start a file without subtitle i get the same filter like you with "(xySubFilter connected with madvr, none)".

i just tryed haali and it works after i block xyvobsub.

vivan
19th July 2013, 21:22
Those two are totally separate things.
Render To Original Video Size makes XySubFilter output subtitles at video resolution instead of using the scaled output resolution.
Use Original Video Size sets the Layout Resolution to use the original video size."Render To Original Video Size" just switches from rendering at renderer resolution to selected resolution (video or AR adjusted or custom). At least that's how it works for me.
I think it's better to remove that checkbox and add option "Use Renderer resolution" or something like that to the list instead.

Also looks like I found small bug: if you choose custom resolution, but "Render to original video size" option is disabled then subtitles are stretched to compensate AR of entered resolution.
http://2.firepic.org/2/thumbs/2013-07/19/of18sr5c96au.png (http://2.firepic.org/2/images/2013-07/19/of18sr5c96au.png)

Soukyuu
19th July 2013, 21:48
I can confirm setting RGB output level to PC fixes the opaque box problem for me (260GTX) without having to switch to 10bit image buffer.As a follow up to that, if I set the RGB output to "auto", then turn off the "optimize subtitle quality for performance instead of quality", the opaque box goes away as well!

@madshi: You should think about renaming that one btw, it is confusing to read, maybe something like "optimize subtitles rendering for performance instead of quality"

detmek
19th July 2013, 22:13
Is there any way to set xySubFilter to render subtitles over black borders added by render? Now, it renders subtitles over image, no matter what size of black borders is. MPC-HC ISR renders subtitles after black borders are added by render.

kasper93
19th July 2013, 22:15
@cyberbeing: I thought you will make different threads for xy-vsfilter and XySubFilter. For me those are different things and you should make this clear for end user to avoid confusion. Anyway it doesn't matter as far as you will be able to keep this thread clean and separate problems with xy-vsfilter and XySubFilter.

TheShadowRunner
19th July 2013, 22:22
PAR Compensation broke, use Layout Resolution instead (set it to anamorphic-corrected video size).
I don't have any "Layout Resolution" setting anywhere in XYSubFilter 3.1.0.546.
I only see "Renderer Layout Options" with 3 possibilities:
-Use Original Video Size
-Use AR adjusted video size
-Customize..

So...??

Those two are totally separate things.
Render To Original Video Size makes XySubFilter output subtitles at video resolution instead of using the scaled output resolution.
Use Original Video Size sets the Layout Resolution to use the original video size.
I understand the theory, I think. Will have to try in real world. ^^;

Auto uses the ASS script's YCbCr Matrix flag if it's present and otherwise defaults to using TV.601 (or, for PC-range content, PC.601) YUV values.
Guess chooses the YUV values to use by resolution, although I don't know if it attempts to read the YCbCr Matrix field first.
Alright, thanks for this precision.

sneaker_ger
19th July 2013, 22:25
Is there any way to set xySubFilter to render subtitles over black borders added by render? Now, it renders subtitles over image, no matter what size of black borders is. MPC-HC ISR renders subtitles after black borders are added by render.

Quoting from the madVR thread:
i`ve just installed xysub but i dont know where is the option to put subtitles in the botton black bar on 2.35 movies :(

To-do list. The subtitle interface was explicitly designed to support this, but madVR doesn't yet expose this functionality to users.

detmek
19th July 2013, 22:31
Thanks. I didn't read madVR tread.

cyberbeing
19th July 2013, 23:28
I don't manage to get *.srt subtitles to work.
...
MPC-BE
http://code.google.com/p/xy-vsfilter/issues/detail?id=156

FYI, I have uninstalled xy-VSFilter in order to have only XySubFilter.
https://github.com/mpc-hc/mpc-hc/pull/97
We are awaiting both MPC-HC & MPC-BE to merge the above.

edit: how well threaded is XySubFilter? I'm still having dropped frames on some overstyled subtitles, without my CPU hitting 50% usage. Shouldn't be an I/O problem since I also tested playing back the same video from a RAM disk and it stuttered just as bad. madvr's OSD shows subtitle queue dropping to 0 so XySubFilter should be the one causing it. My CPU is an AMD Phenom II X4 970BE@4GHz.
Did you remember to disable the MPC-HC ISR? Uncheck Playback -> Auto-load subtitles
When right-clicking the MPC-HC window "Subtitles" should be grayed out & inaccessible.

If the high CPU usage persists, uninstall XySubFilter, and install xy-VSFilter 3.0.0.211 (http://xy-vsfilter.googlecode.com/files/xy-VSFilter_3.0.0.211_Installer.exe).
Is performance the same?

@cyberbeing, why XySubFilter is still in filter chains under such situations?
The graph starts before we know if a Subtitle Consumer like madVR exists or not.

Is it possible to make an option for XySubFilter to apply blur to the subtitles before they are rendered on the screen? Possibly with selectable strength.
For example I'd like to have some equivalent to gaussing blur with radius 0.1-0.5 (edit: well, this is for 1080p screen, for bigger screens I probably want more)
Or this is should be request for the consumer?
We were already considering the idea of simulating upscaling blur awhile back. Possibility for the future. This is something which would need to be implemented in the XySubFilter (provider).

F.Y.I. Because of how Blur was originally implemented in VSFilter 2.39, \blur must have a value greater than 0.3 to have an effect.

Zoom Player Max
Bugs:
1. The subtitles never display when they are embedded!? (for exemple all the matroska files I tested).
madVR does report "subtitle queue 7-8/8" so I know the filter is connected.
On the property page of xySubFilter, Language is empty and grayed out, like if it wasn't able to load the subtitle track at all.
"Loading when needed" with "External" and "Embedded" checked.
Please see: xysubfilterbug.png (http://videoff7.free.fr/xysubfilterbug.png)
External subtitles are picked up and work correctly.

Zoom Player does not yet support use of XySubFilter with SmartPlay. Disable SmartPlay and embedded subtitles should display properly.

2. The "PAR compensation" setting doesn't stick. I chose "Accurate Size", restart playback, and it's reset to "Disabled". (even tried to force automatic_par_compensation to reg_dword value 3, no go)
http://code.google.com/p/xy-vsfilter/issues/detail?id=155

3. What is the purpose (if any) of the option "Render To Original Video Size" when "Use Original Video Size" is selected in the dropdown menu?
VSFilter.dll performs both Layout & Rendering @ Original Video Size
(lower quality, subtitles alpha-blended before resizing)

XySubFilter by default performs Layout @ Original Video Size but and our scale function is used for Rendering @ Output Window Size
(higher quality, subtitles alpha-blended after resizing)

Enabling "Render To Original Video Size" disables our scale function, and enables lower quality VSFilter-like behavior in XySubFilter. There are some people who prefer the appearance of VSFilter-like rendering, since typesetting will usually blend more transparently when subtitle resolution and video resolution matches. If you one of those people who dislike high resolution subtitles on lower resolution video, this option is for you. Otherwise leave it in its default disabled state.

4. What is the difference between "Auto" and "Guess" settings for the YCbCr matrix ?
Setting to anything but "Auto" will break scripts, don't touch it. It exists as an override for script debugging purposes only.

As DarkSpace already mentioned, by default "Auto" will use the YCbCr Matrix value in a ASS script, else if YCbCr Matrix is missing from script TV.601 is used for legacy VSFilter.dll compatibility. This is the behavior you want.

"Guess" is essentially "Guess Matrix by Resolution", which will result in incorrect colors on most scripts.

F.Y.I. For future reference, treat any "Auto" setting in XySubFilter & xy-VSFilter as defaults which should not be changed. Most of the "Auto" settings have adaptive behavior to ensure intended behavior in various different scenarios.


"Render To Original Video Size" just switches from rendering at renderer resolution to selected resolution (video or AR adjusted or custom). At least that's how it works for me.
No, setting "Render To Original Video Size" will *always* render to original video size.

The Layout Options *never* affect rendering resolution, only how subtitle scripts are scaled to output resolution.

Setting Layout to "Customize" is another debugging setting, which is normally useless. If you have a script authored with advanced typesetting for a 1280x720 video, yet you are using it on a 1920x1080 video, you would set "Customize" to 1280x720 to achieve proper scaling.


Also looks like I found small bug: if you choose custom resolution, but "Render to original video size" option is disabled then subtitles are stretched to compensate AR of entered resolution.
http://2.firepic.org/2/thumbs/2013-07/19/of18sr5c96au.png (http://2.firepic.org/2/images/2013-07/19/of18sr5c96au.png)
You are misunderstanding and misusing these settings. This isn't a bug, it's working exactly as intended.

XySubFilter does not contain a custom resolution setting, only a custom layout setting. The *only* correct setting for Layout is the original authored video resolution of a script. Setting anything else will result in incorrect scaling behavior.

As a follow up to that, if I set the RGB output to "auto", then turn off the "optimize subtitle quality for performance instead of quality", the opaque box goes away as well!
Please open a bug on madshi bug tracker (http://bugs.madshi.net/my_view_page.php) about this. This would be a madVR bug.

Is there any way to set xySubFilter to render subtitles over black borders added by render? Now, it renders subtitles over image, no matter what size of black borders is. MPC-HC ISR renders subtitles after black borders are added by render.

To-do list. You'll need to wait for madVR to implement this, as the Subtitle Consumer needs to initiate requests for such black border rendering.

cyberbeing
19th July 2013, 23:33
And just a reminder to everyone. If you have an actual bug report, please create a new issue (http://code.google.com/p/xy-vsfilter/issues/entry) on our GoogleCode Issue tracker.

turbojet
19th July 2013, 23:39
Styles aren't working for me, are they working for anyone?

Is there a way to block xysubfilter in mpc without setting it to not load subs?

cyberbeing
19th July 2013, 23:47
Styles aren't working for me, are they working for anyone?
XySubFilter style overrides are working just fine here. What exactly wasn't working for you? You need to edit each style individually, else set "Force Default" to override all styles with the "Global Default".

xy-VSFilter (VSFilter.dll) intentionally does not support style overrides on ASS scripts. This is not a bug. Eventually it will gain a style editor dialog similar to XySubFilter and we'll re-enable this functionally.

Is there a way to block xysubfilter in mpc without setting it to not load subs?
Not currently.

sneaker_ger
20th July 2013, 00:13
Auto uses the ASS script's YCbCr Matrix flag if it's present and otherwise defaults to using TV.601 (or, for PC-range content, PC.601) YUV values.
Guess chooses the YUV values to use by resolution, although I don't know if it attempts to read the YCbCr Matrix field first.

cyberbeing has already posted the correct description, but just to make sure: if the "YCbCr Matrix" field of an ASS file is missing, it will always report "TV.601", even on PC content. This is to ensure compatibility to "legacy" vsfilter, which always assumes TV.601, too. XySubFilter has no way to discern between full and limited range videos in the first place, because it lacks the ability to read those info from the video stream/splitter and as long as all conversions are done by the consumer it does not even need this feature.

Soukyuu
20th July 2013, 00:14
Did you remember to disable the MPC-HC ISR? Uncheck Playback -> Auto-load subtitles
When right-clicking the MPC-HC window "Subtitles" should be grayed out & inaccessible.Yes, it's off.

If the high CPU usage persists, uninstall XySubFilter, and install xy-VSFilter 3.0.0.211 (http://xy-vsfilter.googlecode.com/files/xy-VSFilter_3.0.0.211_Installer.exe).
Is performance the same?No, no, the CPU usage is not high enough! I have over 50% of my CPU resources free, yet both Xy-VSFilter and XySubFilter choke on those subs instead of making use of those free resources. That's my problem. In other words, yes, the bad performance is the same with either of them.

cyberbeing
20th July 2013, 00:29
The GeForce 8600GT has alpha blending?
This here is another question I have. When the XySubFilter is installed, looks like this:

http://i.imgur.com/Qr8zLGo.jpg

When the xy-VSFilter looks like this:

http://i.imgur.com/q3XaV74.jpg

It's supposed to be so even with the XySubFilter installed?
What was the problem in these images? Those screenshots seem to be of karaoke effects hardsubbed into the video during encoding.

If the issue is xy-VSFilter loading instead of XySubFilter with madVR, we are awaiting MPC-HC to apply a fix for this.

Another thing I noticed was regarding the pin info generated by lav.
...
Pin out information generated is 2048x720. Is that correct?

madVR always requests frame size padded to common texture widths from the video decoder, this is normal.

TheShadowRunner
20th July 2013, 00:37
Zoom Player does not yet support use of XySubFilter with SmartPlay. Disable SmartPlay and embedded subtitles should display properly.
Oh damn, so that was it! Didn't occur to me SmartPlay could interfere :S
VSFilter.dll performs both Layout & Rendering @ Original Video Size
(lower quality, subtitles alpha-blended before resizing)

XySubFilter by default performs Layout @ Original Video Size but and our scale function is used for Rendering @ Output Window Size
(higher quality, subtitles alpha-blended after resizing)

Enabling "Render To Original Video Size" disables our scale function, and enables lower quality VSFilter-like behavior in XySubFilter. There are some people who prefer the appearance of VSFilter-like rendering, since typesetting will usually blend more transparently when subtitle resolution and video resolution matches. If you one of those people who dislike high resolution subtitles on lower resolution video, this option is for you. Otherwise leave it in its default disabled state.
Great explanation, thank you very much.
Makes me wonder if what I've always wanted in VSFilter is now available by default in xySubFilter?
You say xySub (with "Render To Original Video Size" disabled) now uses an internal scale function for Rendering @ Output Window Size. Would it, as a consequence, also keep subtitles size constant regardless of output window size?
I explain: I use my display for scaling, every media content below 720p, the resolution sent is 1280x720. Anything above 720p, the resolution sent is 1920x1080.
With good old VSFilter, I had to sometimes adjust the font size because of the different media resolution / window size (1280x720 versus 1920x1080).
Could it be that now I only need to set the font size once and it'll work for every scenario?

Setting to anything but "Auto" will break scripts, don't touch it. It exists as an override for script debugging purposes only.
As DarkSpace already mentioned, by default "Auto" will use the YCbCr Matrix value in a ASS script, else if YCbCr Matrix is missing from script TV.601 is used for legacy VSFilter.dll compatibility. This is the behavior you want.
Indeed, thanks for confirming ;)

F.Y.I. For future reference, treat any "Auto" setting in XySubFilter & xy-VSFilter as defaults which should not be changed. Most of the "Auto" settings have adaptive behavior to ensure intended behavior in various different scenarios.
Understood.

cyberbeing
20th July 2013, 00:51
No, no, the CPU usage is not high enough! I have over 50% of my CPU resources free, yet both Xy-VSFilter and XySubFilter choke on those subs instead of making use of those free resources. That's my problem. In other words, yes, the bad performance is the same with either of them.
Oh, that what you meant, lol.

Unfortunately, VSFilter, xy-VSFilter, XySubFilter, and even Libass are all essentially single-threaded subtitle renderers. They will never utilize more than a single CPU core. If you provide a sample script(s) which bottleneck your CPU, we could look into possible optimizations. Otherwise my only recommendation to is to buy Intel the next time you upgrade you PC. When it comes to subtitle rendering, single-thread IPC is king.

I'd also recommend to try setting the madVR CPU queue to much higher value like 64 or even the maximum 128, and see if its enough to get you through these difficult subtitle sections.

Soukyuu
20th July 2013, 01:14
Unfortunately, VSFilter, xy-VSFilter, XySubFilter, and even Libass are all essentially single-threaded subtitle renderers. They will never utilize more than a single CPU core. If you provide a sample script(s) which bottleneck your CPU, we could look into possible optimizations.Hmm that's too bad, I was under the impression xy-version was multithreaded. I sent you a PM with the sample(s)

Otherwise my only recommendation to is to buy Intel the next time you upgrade you PC. When it comes to subtitle rendering, single-thread IPC is king.Yes, I'm aware of the massive differences between Intel and AMD single-thread performance, what I didn't know is that it was that bad. If a 4GHz core is struggling with those subs, how can lower end CPUs cope with that @_@

I'd also recommend to try setting the madVR CPU queue to much higher value like 64 or even the maximum 128, and see if its enough to get you through these difficult subtitle sections.64 is quite enough for that sample, I even have 5-11/64 left in my queue after that fragment. Most of other subs only need a queue of 12, so it's really an extreme example.

cyberbeing
20th July 2013, 02:06
You say xySub (with "Render To Original Video Size" disabled) now uses an internal scale function for Rendering @ Output Window Size. Would it, as a consequence, also keep subtitles size constant regardless of output window size?

I explain: I use my display for scaling, every media content below 720p, the resolution sent is 1280x720. Anything above 720p, the resolution sent is 1920x1080.
With good old VSFilter, I had to sometimes adjust the font size because of the different media resolution / window size (1280x720 versus 1920x1080).
Could it be that now I only need to set the font size once and it'll work for every scenario?

Hmm... I'm a bit unclear about your exact situation relates to setting font size?

In order for XySubFilter to scale properly, it needs to know the original authored video resolution of the script. Normally this would be the resolution of video with embedded subtitles, and this is what is used by default. If you upscale the video before madVR, scaling of *.ass scripts will no longer function correctly.

All font sizes, effects, blurs, typesetting, and so on, are scaled to always maintain relative appearance in relationship to the original video resolution. Essentially near-perfect scaling of xy-VSFilter output. The best way to see this effect is to toggle the "Render to Original Video Size" on & off in the middle of playback. Both should look near-identical with the exception of rendering resolution.


Hmm that's too bad, I was under the impression xy-version was multithreaded.
You're not the first person to think that, so I don't blame you.

Eventually we may look to see if there is anything from the dead Threaded-VSFilter (http://code.google.com/p/threaded-vsfilter/) project worth salvaging (the developer was optimizing for an AMD Quad-Core CPU nearly identical to yours). Overall, xy-VSFilter surpassed the performance of Threaded-VSFilter a long time ago, even though we are single threaded, but there still may be certain types of bottlenecks where it is faster. Multi-threading is difficult to execute well on ass subtitle scripts, especially since we value maintaining identical output to VSFilter 2.39 for compatibility reasons.

Yes, I'm aware of the massive differences between Intel and AMD single-thread performance, what I didn't know is that it was that bad. If a 4GHz core is struggling with those subs, how can lower end CPUs cope with that @_@
The difference can be pretty huge nowadays, especially for owners of older AMD CPUs like yours. Unfortunately xy-VSFilter has made some fansubbers a bit more bold and sometimes sloppy about releasing extremely computationally heavy scripts.

[Edit: A quick test shows me that a Intel Ivy Bridge Dual-Core @2.1Ghz offers around the same performance as your AMD PhenomII Quad @4Ghz with XySubFilter/xy-VSFilter]

64 is quite enough for that sample, I even have 5-11/64 left in my queue after that fragment. Most of other subs only need a queue of 12, so it's really an extreme example.

Well that's at least somewhat good news.

Which reminds me, anybody on a 32-bit OS using XySubFilter, do not set madVR's CPU Queue higher than 64.

cyberbeing
20th July 2013, 03:02
As a workaround for users of MPC-BE, if you rename "mpc-be.exe" to "mpc-hc.exe" it will allow XySubFilter to load external subtitles.

This goes for anybody else who renames their MPC-HC executables as well. Currently our workaround in Beta searches explicitly for an application name containing "mpc-hc".

TheShadowRunner
20th July 2013, 03:44
Hmm... I'm a bit unclear about your exact situation relates to setting font size?

In order for XySubFilter to scale properly, it needs to know the original authored video resolution of the script. Normally this would be the resolution of video with embedded subtitles, and this is what is used by default. If you upscale the video before madVR, scaling of *.ass scripts will no longer function correctly.

All font sizes, effects, blurs, typesetting, and so on, are scaled to always maintain relative appearance in relationship to the original video resolution. Essentially near-perfect scaling of xy-VSFilter output. The best way to see this effect is to toggle the "Render to Original Video Size" on & off in the middle of playback. Both should look near-identical with the exception of rendering resolution.
Oh sure, sorry, I meant for unstyled subtitles (srt), definitely should have mentionned it. ^^;
I'm looking for good samples, it'll be easier to explain. Will get back to you on this.

andybkma
20th July 2013, 04:04
Zoom Player does not yet support use of XySubFilter with SmartPlay. Disable SmartPlay and embedded subtitles should display properly.




Is this something that Zoom Player has to fix or is it the fault of xySubFilter? Thanks...

cyberbeing
20th July 2013, 05:24
Zoom Player would need to fix it. They have special handling of subtitles and manually load and connect VSFilter to the graph in Smart Play mode. So they would actually need to add an option to use XySubFilter instead of xy-VSFilter. In a future version of the subtitle interface, we'll likely offer a way for players to disable madVR auto-loading XySubFilter, to make support for manual graph building such as SmartPlay easier.

thewebchat
20th July 2013, 06:05
The performance scalability of scripts in XySubFilter confuses me. I have two essentially equivalent scripts:

http://pastebin.ws/1f27q4
http://pastebin.ws/787m8p

The first script executes with nearly zero overhead as measured by CPU load. The second one uses 100% CPU on fullscreen (2560x1600) and causes massive stuttering. Looking at the tags, I can't see any obvious reason one would be slower than the other. If anything, the first one should be slower since it uses a wider blur and has a secondary layer.

cyberbeing
20th July 2013, 08:32
Which queue in madVR drops first?

Do you have any Flush & Wait settings enabled? If so, try setting all to "Don't Flush".

What CPU, GPU, OS?


I'm not seeing anything particularly abnormal as far as CPU usage on the second sample on my System.
704x480->853x480 = 1% CPU Usage by XySubFilter
704x480->2560x1440 = 3% CPU Usage by XySubFilter

The first sample likely just caches well by chance.
Just to make sure, I'll have our dev double check that nothing strange is going on with second sample.

wanezhiling
20th July 2013, 09:41
Now xysub is always loaded when using madVR even you play a file without any sub... madVR should just let the player decide everything.

cyberbeing
20th July 2013, 10:02
Now xysub is always loaded when using madVR even you play a file without any sub... madVR should just let the player decide everything.

It's still currently under debate, but it seems likely the next update of the new subtitle interface will allow players to disable auto-loading of Subtitle Providers (i.e XySubFilter) by the Subtitle Consumer (i.e. madVR) in some fashion. Beyond that we need feedback from developers, particularly media player developers, about any specific changes they desire from the current revision of the subtitle interface. Currently we've heard from MPC-HC only. Any developer is welcome to contribute to the ongoing discussion here (http://code.google.com/p/xy-vsfilter/issues/detail?id=152) about the future of the subtitle interface. We are open to ideas and suggestions, and would like to resolve any major issues or roadblocks to adoption within the next month.

Moragg
20th July 2013, 12:52
Here's some feedback from me:

My "benchmark" for subtitles was Commie's Shingeki no Kyojin ep1v2 - roughly 100K line of typesetting in 7 seconds.

With xyvsfilter and a queue of 128 I got a second of playback (at best) before the whole thing froze and skipped 10secs.

With xysubfilter and a queue of 128 I get 0 dropped/delayed frames (not optimising for performance) at original res (720p)
If I also playback at fullscreen (1440p) then some dropped frames do happen - with optimising for performance I get 10 dropped, without I get 17 dropped.

So a massive performance boost. Certainly much more than I was expecting. Thanks!

Soukyuu
20th July 2013, 13:41
Moragg, curious, which CPU do you have? That's the same sample my CPU can pass with a queue of 64.

edit: xy-VSFilter vs xySubFilter: 5/64 and 11/64 for subtitle queue respectively, so not that much of a difference.

Also, about multithreading, wouldn't it be possible to say, split the screen in 4 subpictures and let each thread render one of them? I know multithreading isn't that easy from my tries to implement it for a much smaller project, but it would really be a huge benefit to have it. Especially for AMD users, since multithreading is where their CPUs excel at.

madshi
20th July 2013, 13:41
@Everyone: The "opaque black box" problem should be fixed in the next madVR build for 99.9% of all DX9 GPUs (I hope).

Here's some feedback from me:

My "benchmark" for subtitles was Commie's Shingeki no Kyojin ep1v2 - roughly 100K line of typesetting in 7 seconds.

With xyvsfilter and a queue of 128 I got a second of playback (at best) before the whole thing froze and skipped 10secs.

With xysubfilter and a queue of 128 I get 0 dropped/delayed frames (not optimising for performance) at original res (720p)
If I also playback at fullscreen (1440p) then some dropped frames do happen - with optimising for performance I get 10 dropped, without I get 17 dropped.

So a massive performance boost. Certainly much more than I was expecting. Thanks!
That sounds very good, actually I'm surprised that it performs this well.

How about you other users? How does XySubFilter + madVR compare on your PCs in terms of performance and quality to other solutions like VSFilter, xy-VSFilter and the internal MPC-HC ISR?

clsid
20th July 2013, 14:16
There does not seem to be an elegant solution for the auto-loading problems, and most suggested workarounds involve assistance from the player. So I suggest to keep things as simple as possible: give the player complete control of loading a subtitle provider (when needed) and limit the interface to the communication between providers and consumers.

In other words:
* A consumer does not do anything related to loading. It only communicates with providers.
* A provider should not attempt to auto-load itself unless it is able to load itself for external subs (which implies it connects to the video pin). This means that a filter like XySubFilter should have a merit equal to MERIT_DO_NOT_USE.
* The player is responsible for loading (non-video handling) subtitle providers such as XySubFilter. All players that are capable of using a non-standard video renderer are already customizing the graph building, so it should be rather trivial to add for player developers.


It is theoretically possible that multiple providers are in the graph. In case of external subs, this means a sub file could be loaded twice. This could be prevented by letting the (first) provider setting a mutex, signaling to other providers that a file is already loaded (and thus should be skipped). The mutex could be for example "MadSubInterface" + HashOf(subtitle_filename). The reason for mutexing individual files, is because providers might only support a subset of all formats, or use different auto-loading rules and source locations.


I suggest adding a function to XySubFilter (or maybe all non-video handling providers) that allows the player to instruct it to add an external subtitle file. This could be used by for example MPC-HC to load a downloaded subtitle file, or a file that is added through drag&drop. Such a direct function would not require any dynamic DirectShow graph handling (and the complexities that implies). Then XySubFilter could be used as a full ISR replacement in the case where madVR is used as video renderer.