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

[cyberbeing]

Originally Posted by kasper93

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]

Originally Posted by 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.

http://www.filefactory.com/file/fhzu...DA8E31F%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]

Originally Posted by kasper93

"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][2]

Originally Posted by kasper93

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, 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. 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][2].

[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]

Originally Posted by kasper93

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.

Originally Posted by kasper93

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.

Originally Posted by kasper93

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.

Originally Posted by kasper93

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

[kasper93]

@cyberbeing: You might want to backport this https://github.com/kasper93/mpc-hc/c...325b748496b7ae

[cyberbeing]

Originally Posted by kasper93

@cyberbeing: You might want to backport this https://github.com/kasper93/mpc-hc/c...325b748496b7ae

Hmm, I believe those TV-range RGB to/from YCbCr conversion functions were purposefully left unfinished as placeholders only, since only PC-range RGB should ever be used in the current code. It may be wiser to just comment those lines out. Thanks for pointing that out though, since leaving it that way certainly appears rather suspect. And speaking of that color_conv_table, one thing we never got around to doing was backporting our CompactRGBCorrection from XySubFilter to VSFilter. That may be one thing which MPC-HC may want to look into doing, if you intend to push forward in supporting the 'YCbCr Matrix' tagging solution.

[kasper93]

Yeah, that's how I found those bugs, because in our work flow we needed those functions. ISR is after renderer so we need to output TV range to match renderer output. I got ISR working, still need to figure out VSFilter. But as I presume in most cases I will need to guess matrix based on resolution. Anyway I'm quite busy now and messing with this only in free time

[cyberbeing]

Originally Posted by kasper93

Yeah, that's how I found those bugs, because in our work flow we needed those functions. ISR is after renderer so we need to output TV range to match renderer output.

Ah okay, in XySubFilter we always just use ColorConvTable::RGB_PC_TO_TV as the last step (see: xy_bitmap.cpp) when TV range output is requested by the Consumer.

Originally Posted by kasper93

But as I presume in most cases I will need to guess matrix based on resolution.

Well for ASS scripts, the default is TV.601 unless the 'YCbCr Matrix' header specifying which matrix to use is present. You can take a look at how MPV implemented support for this, to get an idea of how these 'YCbCr Matrix' conversions are expected to function with RGB output. With XySubFilter much of this logic is hidden in madVR code (we only do TV.601->TV709 corrections internally by default), so it may not be as immediately apparent looking at our code. Guessing matrix-by-resolution mainly occurs with all subtitle formats except ASS, like SRT etc. Just keep in mind that xy-VSFilter actually uses a AYUV workflow when outputting YCbCr, which could lead to some differences in implementation method compared to MPC-HC VSFilter which always uses a RGB workflow.

So I feel like a total newb posting this.

In a nutshell: xysubfilter will not render SOME subs in full screen exclusive mode with MADVR. Windowed? No problem? 720p content fullscreen exclusive? Works! 1920 wide content full screen? No subs rendered. IE: 1920x800 == no subs. 1920x1080 == no subs. 1280x720? SUBS up the wazzoooo! The internal MPC-HC render works and that is what I'm using now.

Anway, any hints as to where to look? I'm running the current MPC-HC, latest XYsub and latest MADVR. I have no other 3rd party codecs on the system and rely on the LAV bits bundled with MPC-HC.

-Ian

[cyberbeing]

@ianken

There is a bug in the current version of madVR which can cause issues like you discribe, but that only occurs with MOD2 height video (at least as far as we are aware). Either way, my first suggestion would be to try the madVR setting workarounds listed there:

• Disable "optimize subtitle quality for performance instead of quality"
  OR
• Enable "reduce banding artifacts"

If the above does not resolve the issue, please test XySubFilter with EVR-CP and see if you can still reproduce the same issue. If it does not occur with the EVR-CP consumer, you should open a new bug with madVR with details about your GPU and such.

Originally Posted by ianken

In a nutshell: xysubfilter will not render SOME subs in full screen exclusive mode with MADVR. Windowed? No problem? 720p content fullscreen exclusive? Works! 1920 wide content full screen? No subs rendered.

You should probably clarify this as well if you end up opening a madVR bug. When you say no problem with 'Windowed', does that include Fullscreen Windowed (automatic fullscreen exclusive disabled) both with and without 'present several frames in advance', as well as Fullscreen Windowed Overlay?

[Sm3n]

Hi,

I'm using "XySubFilter_Relative_Output_Size_Test".
I've accidently switched the "Always load" option to "Never load" (something like that). Is there a way to revert it?
Tried to uninstall & install again but nothing changed. I guess I have to delete something from registry, right?

Thanks

Edit: OK, I found the Restore_Defaults file https://code.google.com/p/xy-vsfilte...s/detail?id=26

[cyberbeing]

There are a few other option if you just need change XySubFilter configuration settings.

With MPC-HC this can be easily done by just adding to External Filters, and then double-clicking on the entry.
With GraphStudioNext and similar graph builders, the same thing is possible from the Insert Filters dialog.

The manual way, is to cd to the directory with XySubFilter and then use:

rundll32 XySubFilter.dll,XySubFilterConfiguration

With a slight modification, you could also use the above operation via a shortcut.

[Sm3n]

Originally Posted by cyberbeing

With MPC-HC this can be easily done by just adding to External Filters, and then double-clicking on the entry.

Wow the thing I needed.

Thx for the tips!

[Zachs]

There's a bug in XySubFilter that prevents proper usage of ISubRenderFrame.

A simple fail first / fail fast check of QueryInterface for itself fails.

e.g.

PHP Code:

STDMETHODIMP CMpdnRenderer::DeliverFrame(REFERENCE_TIME start, REFERENCE_TIME stop, LPVOID context, ISubRenderFrame *subtitleFrame)
{
//    if (subtitleFrame->QueryInterface(IID_ISubRenderFrame, (void**)&subtitleFrame) != S_OK)
//        return E_FAIL; // <-- this happens
   ...
} 


This might be a good read (The Old New Thing: The ways people mess up IUnknown::QueryInterface).

Cheers.

EDIT: It is indeed an oversight. XySubFilter's source code NonDelegatingQueryInterface does indeed left out ISubRenderFrame but has ISubRenderProvider in there.