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

[cyberbeing]

On an i7 3770K @ 4.6 GHz no cores are over ~50% during the subs, but it is easy to see them on the CPU graph.
You can't really judge load like that, since xy-VSFilter/XySubFilter are single-threaded, and Windows' thread-scheduling will bounce that single-thread around all cores rather evenly. If you had HT enabled on your i7-3770K (8-threads), then 12.5% CPU utilization by XySubFilter alone would be equivalent to 100% load. When this occurs for any significant duration, you'd expect to see madVR's Subtitle Queue start dropping.

[Soukyuu]

I must say, I find it kind of scary seeing how I am still able to use my PC for gaming on medium settings, but it's not powerful enough for madvr video playback with subtitles.
Question: would the memory optimization for 4k mentioned before also affect lower resolutions? Or is it exclusively for higher resolutions?

edit: speaking of CPU load, in my case the load is never above 38% per core, yet on complex typesets the queue runs out. Unless I increase the LV1 cache. Would that be an efficiency issue (CPU/xy-subfilter)?
I don't know how libass handles caches, but they seem to be dynamic in size. Memory usage is lower but gets to the same level as madvr+xysubfilter on the complex parts.

[cyberbeing]

First just a heads-up to everyone. The xy-VSFilter project has a bit of unknown status at moment, since the developer hasn't been responding to emails since April. Without receiving status updates that something was actively being worked these past few months, I'd consider the project on haitus until further notice.

Question: would the memory optimization for 4k mentioned before also affect lower resolutions? Or is it exclusively for higher resolutions?
I don't remember exactly what I mentioned before, but I'd expect memory optimizations to have a positive effect on all resolutions to some degree.

speaking of CPU load, in my case the load is never above 38% per core, yet on complex typesets the queue runs out. Unless I increase the LV1 cache. Would that be an efficiency issue (CPU/xy-subfilter)?
Well as mentioned above, you cannot judge load like that because the subtitle filter is single-threaded.

Single-threaded means you can never surpass the maximum CPU usage of a single core, even if Windows thread-scheduling shifts that load over multiple cores. Since you have a 4-core CPU, xy-VSFilter alone having 25% global CPU utilization is equivalent to maximum load. The obvious answer to improving efficiency on multi-core CPUs would of course be multi-threading support.


I don't know how libass handles caches, but they seem to be dynamic in size. Memory usage is lower but gets to the same level as madvr+xysubfilter on the complex parts.
Libass doesn't use 8x8 supersampling to perform anti-aliasing and sub-pixel positioning, so their objects are multiple orders of magnitude smaller = less memory & computation time. A few months back they also implemented their fast quad-tree rasterizer as well as added new caching mechanisms. Libass is currently much more suitable for rendering at 4K and beyond than XySubFilter is at the moment.

[Asmodian]

Well as mentioned above, you cannot judge load like that because the subtitle filter is single-threaded.

Single-threaded means you can never surpass the maximum CPU usage of a single core, even if Windows thread-scheduling shifts that load over multiple cores. Since you have a 4-core CPU, xy-VSFilter alone having 25% global CPU utilization is equivalent to maximum load. The obvious answer to improving efficiency on multi-core CPUs would of course be multi-threading support.


Both of us mentioned per core usage, does the thread bounce around fast enough that even watching the %usage on a per core basis wouldn't indicate that the filter was CPU bound? (e.g. I see eight cpu graphs on the 3770K, none of them above 50%)

Libass doesn't use 8x8 supersampling to perform anti-aliasing and sub-pixel positioning, so their objects are multiple orders of magnitude smaller = less memory & computation time. A few months back they also implemented their fast quad-tree rasterizer as well as added new caching mechanisms. Libass is currently much more suitable for rendering at 4K and beyond than XySubFilter is at the moment.

I did try changing this setting but even dropping it to None did not change the behavior.

[cyberbeing]

does the thread bounce around fast enough that even watching the %usage on a per core basis wouldn't indicate that the filter was CPU bound?
Yes it does. With madVR, context switching can occur nearly every 0.5 milliseconds under heavy load, which is the timer interval set with HPET. Tools which monitor CPU usage usually have a minimum update interval of 0.5 seconds, which is up to 1000x slower than these switches can occur.

The Process Explorer 'Threads' tab for your media player will allow you to visualize single-threaded CPU bound situations a bit better when you sort by CPU usage. When CPU bound, you'll see a thread with CPU usage equal to 100% / number_of_virtual_cores. (note for XySubFilter + madVR: XySubFilter's CPU usage will end up under the callstack of one of the madVR.ax threads)

I did try changing this setting but even dropping it to None did not change the behavior.
You've misunderstood the purpose of the subpixel positioning setting. It doesn't control anything but subpixel positioning accuracy used during rasterization. Scanline conversion occurs before that, and in VSFilter always requires supersampled 26.6 fixed point input. There is no way to fix that short of a major rewrite/replacement of VSFilter's scanline converter.

[Asmodian]

Ok thanks, I thought I was misunderstanding something. :)

I think CPU was ok as doubling the cache solved my issues but it is good to know watching the cpu graphs isn't enough.

[xabregas]

how can i use subtitles below videos with xysub? still no can do??

[cyberbeing]

how can i use subtitles below videos with xysub? still no can do??
Unfortunately this is still not possible, since it requires consumer support which neither madVR or MPC-HC have gotten around to adding yet. madshi still has it planned for madVR though, so it should definitely come eventually.

[xabregas]

Explain me what is consumer support? :eek:

It seems like something that came out from companies like sony when i asked why they dont have DTS support, and they said for me to check the DTS patterns website :rolleyes:

Well, guess i have to stick with MPC HC subtitle renderer, not that it bugs me and i know its not a major feature for the majority of madvr users as 2/3 of them dont use subtitles at all, but still is silly to see such a trivial option not being available.

Is it because the majority of 2.35 movies without black bars are piracy encodes and madvr wants to become legit? :sly:

[ryrynz]

Explain me what is consumer support? :eek:


He means it requires support from the renderer.


Well, guess i have to stick with MPC HC subtitle renderer, not that it bugs me and i know its not a major feature for the majority of madvr users as 2/3 of them dont use subtitles at all, but still is silly to see such a trivial option not being available.


Yes, just use another subtitle renderer for the time being.
As trivial as it might seem software authors have their own priorities, I suspect however it will be in the next major release of MadVR shortly thereafter.


Is it because the majority of 2.35 movies without black bars are piracy encodes and madvr wants to become legit? :sly:

It has nothing to do with the content at all.

[clsid]

Does anyone have any good samples where xy*filter performs much better than MPC-HC ISR / VSFilter?

[cyberbeing]

Does anyone have any good samples where xy*filter performs much better than MPC-HC ISR / VSFilter?

If your question is if xy-VSFilter is still faster than MPC-HC VSFilter, the answer is yes. Up to this point, MPC-HC has only merged in some of the most basic 'global' xy-VSFilter optimizations and caches, while ignoring the more specialized purpose stuff targeting certain tags and behaviors which can benefit heavy typesetting.

[ahaha2013]

when using xyvsfilter 3.0.0.211, dxv2 native (lav video dec) do not work...
why...

[cyberbeing]

when using xyvsfilter 3.0.0.211, dxv2 native (lav video dec) do not work...
why...
DXVA Native requires a direct connection between the video decoder and video renderer, so it cannot be used with VSFilter.dll which inserts itself between the two.

You'll need to use XySubFilter instead of xy-VSFilter if you wanted to use DXVA Native. Otherwise, you can use DXVA copy-back, CUVID, or Quicksync with xy-VSFilter.

[andyvt]

DXVA Native requires a direct connection between the video decoder and video renderer


Technically, I don't think this correct. Just something that we've come to believe based on observation.

It should be possible for a filter to sit b/w the decoder and renderer, it would need to support the interface & services (IMFGetService/ MR_VIDEO_RENDER_SERVICE/MR_VIDEO_ACCELERATION_SERVICE) a decoder uses to retrieve the Direct3D device and go get it from the renderer (using the same mechanism) to pass back when asked.

[kasper93]

And what's the point of that? Of course you can make "transparent" filter. But the idea is to modify video frame before it reaches video renderer. And to do that you need to "break" dxva pipeline. And for that purpose we have dxva "copy-back" which allow us to put another filter in between and be able to modify the frame.

Tapatalk 4 @ GT-I9300

[andyvt]

And what's the point of that? Of course you can make "transparent" filter. But the idea is to modify video frame before it reaches video renderer. And to do that you need to "break" dxva pipeline. And for that purpose we have dxva "copy-back" which allow us to put another filter in between and be able to modify the frame.

Tapatalk 4 @ GT-I9300

Putting a transform filter b/w the decoder and renderer doesn't have to "break" DXVA, we've just accepted that it does. I don't see why xy-VSFilter couldn't work with DXVA, it just doesn't.

As far as I can tell, if xy-VSFilter brokered the Direct3D device from the renderer (which is responsible for creating it) and the decoder it could work the same way it does now (albeit with DirectX surfaces instead of just frames in memory) and support DXVA. Essentially, it would be doing the work of a custom EVR Presenter (which responds to those calls to hand the Direct3D device back to the decoder and overlays subtitles on surfaces) without requiring application support.

[octal9]

what does the relative height setting in the styles section refer to? too bad to hear the programming genius behind what i believe is the best sub renderer in the business has gone awol - pray all is well......still hoping for a fix on the problem of windows freezing when i enter style settings in windows 7 64 bit, but what are you gonna do (this only happens in full screen - work-around of changing video player to windowed still works)? still love the hell out of this - makes viewing of subtitles a million times more pleasurable than any other renderer.......

[cyberbeing]

what does the relative height setting in the styles section refer to?
Unless you have a reason to use that test build, I'd recommend just sticking with Beta2. It was only something I (non-coder) hacked in myself, and I'm having doubts it was implemented properly, since it seems to be causing something like a 10% performance hit even when it shouldn't be active... Anyway, what it does is overrides/ignores the 'originalVideoSize' field reported by the consumer when the 'Global Default' (override) style is active. This way you can set your override styles just once, without worrying about the relative appearance changing when switching between videos of different resolutions.

still hoping for a fix on the problem of windows freezing when i enter style settings in windows 7 64 bit, but what are you gonna do (this only happens in full screen - work-around of changing video player to windowed still works)?

If this is the same thing I'm thinking of, this isn't really 'Windows freezing' problem, but rather madVR's Fullscreen Exclusive window claiming the "On Top" position, which can cause things like the Font selection dialog to get stuck behind the "exclusive window". You'd then become unable to exit the style editor or vsfilter properties, since it requires first closing the font selection dialog which cannot be accessed behind the exclusive window.

I'd consider this a madVR limitation/bug, since it offers no way to recover (exit FSE) via mouse input or otherwise by default. AFAIK, this same issue occurs with MPC-HC VSFilter, so I'd suggest just creating an entry on bug tracker and see if they can find a practical solution. If that fails, file a bug with madVR.

[vivan]

Unless you have a reason to use that test build, I'd recommend just sticking with Beta2. It was only something I (non-coder) hacked in myself, and I'm having doubts it was implemented properly, since it seems to be causing something like a 10% performance hit even when it shouldn't be active... Anyway, what it does is overrides/ignores the 'originalVideoSize' field reported by the consumer when the 'Global Default' (override) style is active. This way you can set your override styles just once, without worrying about the relative appearance changing when switching between videos of different resolutions.It works for borders and stuff, but not for font size. I figured that it's not ready yet... still, I want it badly :)

If this is the same thing I'm thinking of, this isn't really 'Windows freezing' problem, but rather madVR's Fullscreen Exclusive window claiming the "On Top" position, which can cause things like the Font selection dialog to get stuck behind the "exclusive window". You'd then become unable to exit the style editor or vsfilter properties, since it requires first closing the font selection dialog which cannot be accessed behind the exclusive window.Same thing happens if you just use "always on top" option.
I'm not sure if this is MPC-HC bug, because built-in subtitle renderer doesn't have this problem. However it's font selector has 1 layer/window less (Options -> Font vs Properties -> Styles -> Font). Actually I've never see any other filter with such number of windows (3). They have 2 windows at max, so it could be either MPC-HC problem (only 2 windows inherit "on top"), xy-subfilter (font selector doesn't inherit "on top") or even Windows one... I didn't really bothered me, though.

[cyberbeing]

It works for borders and stuff, but not for font size. I figured that it's not ready yet... still, I want it badly :)
Well at least to some degree, you still have the desired end result of relative font size being constant no matter the video resolution used. And that actually requires no change since this has always been VSFilter default behavior. That said, I was tempted to change this so we'd have something like 'true' pixel width/height font sizes, margins, borders, shadows, etc, with such an option. Though I couldn't for the life of me figure out what was causing the rather insane relative layout behavior VSFilter has with SRT, which did not seem to match up with the expectation for ASS layout at all. Maybe something the xy-dev would be willing to fix, if he returns.

Same thing happens if you just use "always on top" option.
I'm not sure if this is MPC-HC bug, because built-in subtitle renderer doesn't have this problem. However it's font selector has 1 layer/window less (Options -> Font vs Properties -> Styles -> Font). Actually I've never see any other filter with such number of windows (3). They have 2 windows at max, so it could be either MPC-HC problem (only 2 windows inherit "on top"), xy-subfilter (font selector doesn't inherit "on top") or even Windows one... I didn't really bothered me, though.

Well as mentioned above, AFAIK this behavior has always occurred with all forms of VSFilter.dll (Gabest/MPC-HC/MPC-BE/xy), since the code used for creating these windows is probably identical. MPC-HC ISR I would think is entirely different beast, since all windows it creates would fall under the context of the main MPC-HC GUI, with full control over the z-order and topmost behavior of child windows.

If someone else comes up for a fix for VSFilter itself, we could certainly merge it. I'm not very familiar with how the whole Windows topmost and z-order behavior is supposed to work in this case, expecially when both MPC-HC (setting) and madVR (FSE) themselves enforce such behavior on their own windows, and cause this issue with vsfilter child windows which function nominally otherwise. This being some kind of Windows bug or unintended behavior in the DWM also seems within the realm of possibility. There was even a hotfix (http://support.microsoft.com/kb/2587473) a few years ago off the LDR service branch for ontop behavior being broken on Windows 7 SP1 (RTM/GDR) out-of-box. I've always had this hotfix applied myself though, and I still run into buggy and strange on-top behavior with other applications, so who knows what it actually fixed or if it made something else worse.

[octal9]

It works for borders and stuff, but not for font size. I figured that it's not ready yet... still, I want it badly :)

Same thing happens if you just use "always on top" option.
I'm not sure if this is MPC-HC bug, because built-in subtitle renderer doesn't have this problem. However it's font selector has 1 layer/window less (Options -> Font vs Properties -> Styles -> Font). Actually I've never see any other filter with such number of windows (3). They have 2 windows at max, so it could be either MPC-HC problem (only 2 windows inherit "on top"), xy-subfilter (font selector doesn't inherit "on top") or even Windows one... I didn't really bothered me, though.

i actually found a much easier workaround for this where you don't have to switch to windowed mode to prevent freeze (works for mpc-be and mpc-hc, not sure about potplayer, zoom, etc.) - first right click, go down to "view", go down to "on top", and then switch to "while playing" - works like a charm! also, this bug occurs in both fullscreen exclusive and windowed mode in madvr.........much thanks to cyberbeing!

[vivan]

Well at least to some degree, you still have the desired end result of relative font size being constant no matter the video resolution used.Okay, I found out why I have issues. It doesn't discard script resolution (when "Force Default" option is set).

For example, videoBlankClip (500, 1920, 1080, color=$222222)

With 1080p script resolution font size is small (http://i.imgur.com/TZcCJ6W.png)
PlayResX: 1920
PlayResY: 1080


With 360p script resolution font size is huge (http://i.imgur.com/31Gyyz1.png)
PlayResX: 640
PlayResY: 360

(the rest of the script is default)

[cyberbeing]

Okay, I found out why I have issues. It doesn't discard script resolution (when "Force Default" option is set).

Yes, this is pretty much expected for ASS scripts since that size behavior is the basis of all existing typesetting. I actually looked into overriding PlayRes before I posted that other build, but I couldn't figure out a trivial way to do so in the part of the code I was modifying. When the xy-dev originally tried to implement this as well, he was scaling fontsize/border/shadow/spacing/margins directly within the script styles without touching PlayRes, and actually why I suspect this method was utterly broken on ASS scripts. I mentioned this to him before, but he never got around to fixing it before the release of Beta2, so it was reverted. I'll still keep this in mind for the future.

[minaust]

I'll still keep this in mind for the future.
Please do. I've got an icon on my desktop for a small C prog I wrote to do a little massaging to ASS scripts. One of the things it does is strip out PlayRes.

[Tornado15550]

Is anyone having any issues displaying subtitles using XySubFilter on the latest MPC-HC nightlies?

[cyberbeing]

Is anyone having any issues displaying subtitles using XySubFilter on the latest MPC-HC nightlies?

See: https://trac.mpc-hc.org/ticket/4767

MPC-HC accidentally broke the XySubFilter interface to EVR-CP while they were doing updates to the ISR backend.
madVR should still be fine, but I'd recommend just sticking with an older MPC-HC build until they get around to fixing it.

[James Freeman]

Pardon me, what are the benefits of this vs the built in MPC-HC one?

[cyberbeing]

Faster with heavy subtitle typesetting (i.e. anime fansubs), improved subtitle interface, matrix correction for BT.601->BT.709 subtitles (legacy VSFilter.dll limitation) required for correct video color matching, subtitle queue (madVR only), and gamma/gamut correction (madVR only), and various other compatibility improvements for .ass subtitles.

[kasper93]

improved subtitle interface - not really relavent for end user
subtitle queue - MPC-HC have subtitle queue for ages...

[huhn]

improved subtitle interface - not really relavent for end user
subtitle queue - MPC-HC have subtitle queue for ages...

but the ISR is not corrected by a 3D LUT and was in the past a lot slower has issue with some tags.
of cause the main benefits of this render is for styled subtitles and normal BD/dvd subs work totally fine with the ISR.

[clsid]

If you have any files that do not render correctly with the ISR, then please submit them to the bug tracker.
https://trac.mpc-hc.org/report/9

The performance of the ISR has improved a lot in the past months. Next nightly/stable is going to have several more performance improvements.

madshi could easily apply 3dluts and color corrections to the ISR ouput as well in a future version of madVR. Plus 3dluts isn't something that many people use. MPC-HC also already has some code for the new interface, so that might get used in the future if it provides any benefits.

[cyberbeing]

improved subtitle interface - not really relavent for end user
Is is relevant, since SubRenderInf allows functionality and improved integration which is not otherwise possible with the limitations of the ISubRender used by the MPC-HC ISR. I'm sure madshi could explain the specifics of this better than I can though. The new subtitle interface came into existence since he was dissatisfied with the capabilities of ISubRender. So at least as far as madVR support is concerned, native support of the new SubRenderIntf interface will always be considered an advantage.

subtitle queue - MPC-HC have subtitle queue for ages...
And MPC-HC that subtitle queue was also the source of problems for ages, whenever there were slowdowns. This is why it was one of the first things we removed from xy-VSFilter/XySubFilter. For renderers which pre-buffer video frames ahead like madVR, having a separate simple subpic pre-buffer in the subtitle renderer itself is rather redundant anyway. You'd really need to go a step further and implement an advanced lookahead+predictive caching for it really to be useful in such a situation.

The performance of the ISR has improved a lot in the past months. Next nightly/stable is going to have several more performance improvements.
I look forward to testing the upcoming round of improvements, since despite what you've said, there really hasn't been any significant improvements with heavy typesetting in the ISR since the initial round of xy inspired cache commits around a year or so ago. Either way, it's encouraging to see Underground78 continuing to work on closing the remaining gaps in performance. I hope he continues to push forward implementing the remaining low-hanging fruit / feature gaps from xy, and ultimately moves on to eventually tackling some of the performance issues vs recent Libass which we've yet to touch ourselves. The status of the xy-VSFilter developer has been rather unknown for months now, so if or when our project will continue is rather uncertain at the moment.

[clsid]

I would be really helpful if you could use your knowledge about the changes in xy*filter to compile a (short) list of the most important/beneficial fixes and improvements in the xy project. Preferably with sample files and links to the relevant commits. That could help speed up and streamline development on the MPC-HC side.

[cyberbeing]

Once the latest round of subtitle improvement commits from Underground78's personal branch are merged to MPC-HC master, I'd consider doing so once I have a chance to reassess performance. Judging from some of the commit names, he may have already discovered a couple of the most obvious ones. We'll have to wait and see what comes of it.

[James Freeman]

I see absolutely no difference between MPC-HT built-in and XY, the font style box looks the same,
the CPU usage is non existent, the rendering looks smooth with internal/external subs with both.

I'll stick with the built-in because for all I care it's exactly the same.

[ryrynz]

Would be nice to see one less program to be dependant on, if we can get that madVR interface set up in the ISR that would be great.

[cyberbeing]

...
For general use like you describe, that's pretty much to be expected. The only users who really require XySubFilter over MPC-HC ISR & Libass, are those who likely were already prior users or at the very least aware of xy-VSFilter prior to me creating this topic on Doom9 in 2013. For everyone else, there are some benefits especially for users of madVR, as well as some feature/functionality differences, but each user will need to decide for themselves if they are worthwhile it or not.

if we can get that madVR interface set up in the ISR that would be great.
I'd hope this eventually occurs as well, but at this point it seems rather doubtful. Even if MPC-HC ISR never supports it, there is a logical successor (not from us) supporting the madVR interface on the horizon in the next couple years, which will likely deem both MPC-HC ISR and XySubFilter obsolete unless a major modernization effort occurs. Such future talk is rather off-topic for this thread though.

[kasper93]

Little announcement: Latest MPC-HC nightly include recent performance changes. @cyberbeing: If you could provide samples that works "a lot" better with XySubFilter than with ISR. You can send them directly to me or open tickets on trac, thanks in advance.

[huhn]

Little announcement: Latest MPC-HC nightly include recent performance changes. @cyberbeing: If you could provide samples that works "a lot" better with XySubFilter than with ISR. You can send them directly to me or open tickets on trac, thanks in advance.

I will have a good look at it too. nice to see an very active development with an subtitle renderer.

[cyberbeing]

Latest MPC-HC nightly include recent performance changes.
Performed a few benchmarks on my i5-3570K @4.4Ghz below on a few old samples I had lying around with the new MPC-HC build. Later I'll need to take a look at some more recent releases. My general conclusion so far, is the latest MPC-HC build improves Outline & Vector Drawing performance close to xy-VSFilter, which is somewhat expected since that seemed to be the focus of this latest set of commits. Blur, BE, Clip performance, as well as general cache throughput & efficiency, still appear considerably faster with xy-VSFilter.

Other misc stuff which MPC-HC still seems to be missing:
Support for U+10000-U+10FFFF UTF-8
Support for floating point \clip and vector drawings
Floating-point BE scaling (for ISR)
Workaround to prevent subpixel gaps with \clip
Method for eliminating subpixel gaps between body & outline
Support for YCbCr Matrix tag
Support for P010 (for VSFilter)


Simple Blur6 + Bord4 (126 lines):
MPC-HC VSFilter 1.7.6.177: 32.83fps min | 94.58fps avg
MPC-HC VSFilter 1.7.6.211: 138.5fps min | 284.5fps avg
xy-VSFilter 3.0.0.305 CCCP: 148.1fps min | 317.9fps avg

Simple Blur6 + Bord4 (126 lines identical repeat x10):
MPC-HC VSFilter 1.7.6.177: 37.90fps min | 461.7fps avg
MPC-HC VSFilter 1.7.6.211: 142.0fps min | 742.6fps avg
xy-VSFilter 3.0.0.305 CCCP: 154.0fps min | 921.4fps avg

Simple Blur20 (126 lines):
MPC-HC VSFilter 1.7.6.177: 67.24fps min | 180.6fps avg
MPC-HC VSFilter 1.7.6.211: 69.46fps min| 182.7fps avg
xy-VSFilter 3.0.0.305 CCCP: 115.8fps min | 288.5fps avg

Simple Vector Block Test:
MPC-HC VSFilter 1.7.6.177: 528.0fps min | 606.6fps avg
MPC-HC VSFilter 1.7.6.211: 526.9fps min | 606.9fps avg
xy-VSFilter 3.0.0.305 CCCP: 789.4fps min | 980.4fps avg

Heavy \clip + blur sample (~17k lines):
MPC-HC VSFilter 1.7.6.177: 12.79fps min | 44.03fps avg
MPC-HC VSFilter 1.7.6.211: 14.85fps min | 48.52fps avg
xy-VSFilter 3.0.0.305 CCCP: 31.23fps min | 82.43fps avg

Fullscreen multi-line motion tracking (~1.6k lines):
MPC-HC VSFilter 1.7.6.177: 12.26fps min | 21.29fps avg
MPC-HC VSFilter 1.7.6.211: 22.55fps min | 29.85fps avg
xy-VSFilter 3.0.0.305 CCCP: 22.65fps min | 54.10fps avg

Logo clone + karaoke w/ blur & be (103 lines):
MPC-HC VSFilter 1.7.6.177: 213.5fps min | 342.9fps avg
MPC-HC VSFilter 1.7.6.211: 269.8fps min | 391.8fps avg
xy-VSFilter 3.0.0.305 CCCP: 375.7fps min | 562.6fps avg

Advanced karaoke (~2.1k lines):
MPC-HC VSFilter 1.7.6.177: 95.10fps min | 240.9fps avg
MPC-HC VSFilter 1.7.6.211: 124.1fps min | 275.0fps avg
xy-VSFilter 3.0.0.305 CCCP: 173.9fps min | 318.3fps avg

Heavy Static Positioned Typesetting (160 lines):
MPC-HC VSFilter 1.7.6.177: 144.8fps min | 279.3fps avg
MPC-HC VSFilter 1.7.6.211: 144.9fps min | 283.5fps avg
xy-VSFilter 3.0.0.305 CCCP: 185.3fps min | 311.7fps avg

Vector shape karaoke (~3.1k lines):
MPC-HC VSFilter 1.7.6.177: 79.49min fps | 148.4avg fps
MPC-HC VSFilter 1.7.6.211: 113.5min fps | 187.8avg fps
xy-VSFilter 3.0.0.305 CCCP: 113.3min fps | 199.7avg fps

Typesetting of Doom #1:
MPC-HC VSFilter 1.7.6.177: 3.94fps min | 14.09fps avg
MPC-HC VSFilter 1.7.6.211: 4.07fps min | 16.03fps avg
xy-VSFilter 3.0.0.305 CCCP: 9.82fps min | 25.76fps avg

[octal9]

i did some benches of my own, and it looks like the isr still has a ways to go performance wise, though its' nice to see them moving in the right direction - xysubfilter beat it every time for render time, plus i can edit my subs on the fly (and it looks just as good or better)..........would be nice to see in the future if resources could be pooled and the two could be merged somehow (as the developer here i still m.i.a.) and the project could move forward.

[Volfield]

Little announcement: Latest MPC-HC nightly include recent performance changes. @cyberbeing: If you could provide samples that works "a lot" better with XySubFilter than with ISR. You can send them directly to me or open tickets on trac, thanks in advance.

http://www.filefactory.com/file/fhzuidfuiap/%5BFinal8%5DServant%20x%20Service%20-%2010%20(BD%2010-bit%201280x720%20x264%20AAC)%5B4DA8E31F%5D.mkv

MPC-HC.1.7.6.211.x64 ISR 12:42 massive frame drops. XY-SubFilter on EVC-CP works fine (almost).

[kasper93]

@cyberbeing: Thanks. I know that xy-vsfilter is faster, but it is good thing that we are getting closer.

"Support for floating point \clip" this is already supported for some time now.

Workaround to prevent subpixel gaps with \clip
Method for eliminating subpixel gaps between body & outline

Do you have samples for this two issues? I've fixed some gaps issue with one sample, but it was different issue probably.

[cyberbeing]

"Support for floating point \clip" this is already supported for some time now.
I don't believe so. Testing with Aegisub, MPC-HC 1.7.6.211 still appears to be rounding floating point \p drawings to integers, and treating floating point \clip as integers without rounding. The main issue MPC-HC fixed awhile back was the crash related to floating point values. Both xy-VSFilter and Libass actually render \p and \clip script values as floating point [1] (https://github.com/libass/libass/issues/63)[2] (https://github.com/Cyberbeing/xy-VSFilter/commit/7b1e5c6e3b390ca7f0a9803786f1369878f7ae94)

I've fixed some gaps issue with one sample, but it was different issue probably.
Hmm, yeah I see that one of the \clip gradient gap issues I was thinking of is not present in 1.7.6.211, but as mentioned above, that build seems to have eliminated floating point \clip accuracy entirely. Which I guess is one solution, but doing it globally like this could potentially result in other issues. You can see how xy-VSFilter chose to handle this here (https://github.com/Cyberbeing/xy-VSFilter/commit/c897095dfb1b637083ce4bccc6eac9a78c515f37), which only triggers for \clip post-scale and ensures subpixel \clips sharing a boundary are shifted to adjacent whole pixels. We don't do this for \p drawings since always maintaining floating point accuracy rendering is more important.

The other issue with subpixel gaps between body and border, is essentially this issue (https://code.google.com/p/xy-vsfilter/issues/detail?id=145). The Libass idea for resolving this is described there. Though xy-VSFilter ended up doing something entirely different, and just implemented an Addition Draw method to replace Alpha Blending in certain cases [1] (https://github.com/Cyberbeing/xy-VSFilter/commit/d81650b88dd123cf1038d5fc4aa014bec564af40)[2] (https://github.com/Cyberbeing/xy-VSFilter/commit/50b964b90aba9108102a9e89cff797e82c18f106).

[kasper93]

Both xy-VSFilter and Libass actually render \p and \clip script values as floating point.

No you don't, you are rounding same as we do, just not in case scale == 1. Which is in my opinion inconsistent. We should render the same thing no matter if we scale or not . And hack like that to round only when you fell comfortable doesn't seem right to me. And most importantly you are adding bigger rounding error in case of scalling, because you do it twice. You handle \p the same unless I'm looking at wrong part.

Send me the sample where there is actually visual difference to motivate me to change that... I don't see any difference with my samples. And discussing code differences in not really the point here.

[cyberbeing]

No you don't, you are rounding same as we do, just not in case scale == 1. Which is in my opinion inconsistent. We should render the same thing no matter if we scale or not.
When upscaling, you have more pixels to deal with so maintaining sub-pixel boundaries on rectangle \clip doesn't matter as much compared to the artifacts it produces. When displayed at 1.0 scale, the original script author's intentions should be honored. That this is a hack is very much true, but having yet another method is just going to make things worse for script authors.

And most importantly you are adding bigger rounding error in case of scalling, because you do it twice.
Not sure where you see this, since floating point values \clip are maintained when scaling to target, and only rounded from 26.6 fixed point to whole pixel as the last step. There is no double rounding going on.


You handle \p the same unless I'm looking at wrong part.
You are looking at the wrong part, for \p rounding is always false.

Send me the sample where there is actually visual difference to motivate me to change that... I don't see any difference with my samples. And discussing code differences in not really the point here. I mean current mpc-hc code doesn't introduce significant error

Libass:
Parses \clip & \p as floating point and renders with 26.6 fixed point (8x8 subpixel) accuracy always.

xy-VSFilter:
Parses \p as floating point and renders with 26.6 fixed point (8x8 subpixel) accuracy always.
Parses \clip as floating point and renders with 26.6 fixed point (8x8 subpixel) accuracy when scale = 1.0.
Parses and scales as floating point, then rounds \clip boundaries to whole pixels in certain instances (adjacent rectangle clips only?) when rendering with scale != 1.0.

MPC-HC:
Parses and renders \p as floating point rounded to integers always.
Parses and renders \clip as integers always.

This is something MPC-HC should care about if your ultimate goal is to have users of xy-VSFilter & Libass migrate to the ISR for critical typsetting needs. For awhile now, both xy-VSFilter and Libass have been working on unifying rendering behavior as much as possible, which makes it rather counter productive if MPC-HC continues to do their own thing. For a couple years now, Fansubbers have been authoring scripts which depend on sub-pixel accuracy, at least from what they've told me. If you need a good sample, you should probably ask some fansub typesetters directly. I am not knowledgeable enough with modern typesetting methods to produce a good script samples myself. It may be true that this often isn't very noticeable, but I don't see why MPC-HC would desire harming accuracy like this. This is why xy-VSFilter went to a halfway solution, to maintain maximum accuracy except for a specific use-case which is artifacts produced by \clip created gradients post-scale.

[romulous]

@cyberbeing: Request from Blight. Can the ".\Subs" folder be added to the default search path (for both XYSubFilter and xy-vsfilter)? Blight has noted that it seems recent releases use that folder and Zoom Player isn't finding the subs because it requires users to manually add that path to their XYSubFilter/xy-vsfilter as it's not part of the default paths used by both filters.

Thanks!

[cyberbeing]

@romulous

Sure, I'll keep this in mind for whenever we make our next release. It seems like this is one of those things which would probably be useful for us to add to the API as well.

[romulous]

Great, thanks - much appreciated :)

romulous