XySubFilter with libass: an ASS and SSA subtitle renderer for DirectShow players

A fork whose only job is to change the rendering backend

The readme opens with what this is: a subtitle render filter for DirectShow video players such as mpc-hc and mpc-be, and potplayer with madVR, which use libass to render ASS and SSA format subtitles.

The ancestry is specific. It originates from a pull request on Cyberbeing's xy-VSFilter, and the result is named XySubFilter with libass. The repository is Masaiki's fork of that project, on a branch called xysubfilter_libass, with the default branch set to it.

That is the whole scope, and being clear about it is the point. This is not a media player, not a subtitle editor, and not a general filter framework. It is one DirectShow filter, XySubFilter.dll, whose job is to take a subtitle stream from a host player and draw the text on the video. The only thing this fork changes is which library does the drawing.

Why that matters is about ASS. The ASS format carries far more than a subtitle string: positioning, colours, gradients, outlines, karaoke effects, animation tags and per-character styling. A renderer that implements only the basics of the format will show a technically correct but visually wrong subtitle. libass is the reference-grade ASS renderer, and pointing the filter at it is a small change with a large visible result for people who care about styled subtitles.

The audience is therefore specific and identifiable: a Windows user watching anime or fansubbed video with a DirectShow-based player, who finds the built-in or default subtitle rendering flat or broken.

Installing it: a batch file as administrator, or Scoop

There are two install routes, and both are Windows-only, as you would expect for a DirectShow filter.

The first is the batch file. Run Install_XySubFilter.bat as administrator, and the instruction that follows is worth heeding: do not move or delete the XySubFilter.dll. A DirectShow filter is registered by its DLL path with the system, so relocating the file after registration leaves the registration pointing at nothing and the player silently stops offering it as an option.

The second route is Scoop, and the readme points at the xysubfilter-libass-np manifest in the nonportable bucket:

scoop bucket add nonportable
scoop install xysubfilter-libass-np -g

The global flag installs it system-wide rather than into a per-user Scoop directory, which is what you want for a DirectShow filter that a media player will look up.

After installation, the filter has to be selected inside the player, and the readme gives the exact menu paths for the two players it names. In MPC-BE it is under Options, Subtitle, Subtitle renderer. In MPC-HC it is under Options, Playback, Output, Subtitle Renderer. Potplayer with madVR is listed as supported in the opening description, but the readme does not give a menu path for it, so for that player you are on your own with the settings dialog.

One more thing is worth knowing before you install anything: the alternative library approach. The original XySubFilter is a separate project with its own releases, and for formats other than SSA and ASS, such as srt and sup, this fork is essentially unchanged from the original, so you inherit the original's behaviour there.

The compatibility caveat the project states about itself

The Note section at the end of the readme is the most useful paragraph in the repository, because it is where the author says what the fork does not fix.

The first point is that this project may have some compatibility issues with XySubFilter when rendering SSA and ASS, and that this is largely dependent on libass. The author then adds a line that is refreshingly honest: issues are welcome, and if you do not know whether a problem comes from libass or from the fork itself, say so.

Read that as a debugging note as much as a caveat. When a subtitle renders differently under this filter than under the original, the first question is which component changed the behaviour, and the answer is not always knowable from the outside because libass and the filter's own code paths both touch text layout. For a user, the practical consequence is that bug reports about rendering differences need to say which renderer and which player were used, or the report is hard to act on.

The second point is about everything that is not SSA or ASS. For the rest of the project, such as srt, sup and other basic parts, the author says he basically left it unchanged, so it inherits all the strengths and weaknesses of the original project. That is the honest description of a targeted fork: one backend swapped, everything else frozen in the state it was in when the fork was taken.

The same applies to the surrounding structure. The repository root holds VSFilter.sln, a src/ tree, an include/ directory, a lib/ directory, a test/ directory, an SMP/ directory, scripts/, docs/, a Directory.Build.targets file and a .gitmodules file. A filter of this kind has always been a Visual Studio project with a solution file, and that is still how it is built.

Building it from source, and the runtime library step people miss

The compile instructions are four steps, and step three is the one that catches people out.

First, get the assembler toolchain. The readme says to clone or download the release from ShiftMediaProject's VSYASM and VSNASM repositories and run install_script.bat as administrator. Those are the x64 and x86 assembler builds that libass is built on.

Second, clone the repository and run the submodule update command in the folder:

git submodule update --init --recursive --remote

Third, and this is the one that trips people up, in Visual Studio you must manually set the Runtime library of libass and its dependencies to /MT for Release and /MTd for Debug. The readme links the Microsoft documentation for the runtime library options. The reason is that libass is normally built as a shared library with a DLL runtime, and a DirectShow filter is loaded in-process by the player, so the static runtime has to match across libass and its dependencies or the host process will load two copies of the C runtime and crash in ways that are hard to diagnose.

Fourth, build the project named xy_sub_filter.

The presence of the --remote flag on the submodule update is also a deliberate choice, and worth noting: it tracks the upstream submodules rather than pinning them to the commit recorded in the repository, which is convenient when you want the current libass but means your build is not reproducible from the clone alone unless you record what you pulled.

The project is licensed GPL-2.0, with the licence text in License.txt at the repository root, and the source tree includes an include/ directory, so the libass headers and the filter's own public interface are both visible.

State of the fork: dated releases on an active branch

The release history is unusual in a way worth understanding, because the version numbers are dates.

The recent releases are named 20260721, described as xy-VSFilter/XySubFilter with libass version 20260721 and dated 2026-07-20, then 20260510 from 2026-05-10, then 20251008 from 2025-10-07. So the release identifier is a build date rather than a semver number, which tells you the author treats each release as a snapshot of a moving libass rather than as an API version of the filter itself. That is a reasonable convention for a filter whose behaviour depends heavily on the version of the library doing the rendering, and it makes it obvious from the file name which libass you are running.

The repository is not archived, and the last push was on 2026-09-10, which is a little under two months before the releases listed above. So the branch is being worked on.

The primary language is C++, the description in the repository metadata calls it an xy-VSFilter variant with libass backend, and the topics include the DirectShow and subtitle territory.

What the repository does not contain is worth naming too. There is no user guide beyond the four-step how-to, no discussion of the DirectShow filter registration beyond the do-not-move-the-dll warning, and no test documentation despite a test/ directory in the tree. For a filter that most people will install rather than build, that is a reasonable amount of documentation, but anyone planning to debug or fork the rendering path will be reading the libass source and the upstream XySubFilter code alongside it.

Editorial conclusion

This fork fits a Windows user on MPC-HC, MPC-BE or a madVR setup who needs libass quality on styled ASS subtitles and is willing to run an installer as administrator. It does not fit a Linux or macOS user, a player that is not DirectShow based, or anyone who needs a fully supported subtitle stack. Before installing, check that the player you use can select a DirectShow subtitle renderer at all, and expect to fall back to the original XySubFilter if libass-specific styling behaves differently than you expect.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Masaiki/xy-VSFilter on GitHub
3. Project website
4. README
5. Releases