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

[cyberbeing]

Originally Posted by vivan

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.

Originally Posted by vivan

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

Originally Posted by vivan

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]

Originally Posted by cyberbeing

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, video

BlankClip (500, 1920, 1080, color=$222222)

With 1080p script resolution font size is small

PlayResX: 1920
PlayResY: 1080

With 360p script resolution font size is huge

PlayResX: 640
PlayResY: 360

(the rest of the script is default)

[cyberbeing]

Originally Posted by vivan

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]

Originally Posted by cyberbeing

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]

Originally Posted by Tornado15550

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]

Originally Posted by kasper93

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]

Originally Posted by kasper93

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.

Originally Posted by clsid

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]

Originally Posted by James Freeman

...

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.

Originally Posted by ryrynz

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]

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.

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