AssRender: inappropriately named libass-based subtitles renderer

[TheFluff]

One fine day a friend of mine wanted to encode something with Avisynth under Wine, on Linux. It went fairly well until he wanted to render subtitles, because Ye Olde VSFilter doesn't work under Wine (too GDI-ish or something, idk).

This gave me an idea and after some false starts I succeeded in cross-compiling libass and its dependencies, and the result is this filter. It renders .asses, the end.

EDIT: I do not maintain this plugin anymore; lachs0r has taken over development and convered it to a C plugin. See his posts at the bottom of this page and the new homepage at http://srsfckn.biz/assrender.

The old OP follows below.





Download
AssRender 0.11 (http://www.mod16.org/assrender/assrender_0.11.7z)
NOTE: the included fontconfig directory MUST be in the same folder as the .dll, or it'll crash!
Note 2: loading something the first time can be pretty slow, especially if you have a lot of fonts installed, because fontconfig needs to cache all your system fonts.

Source code (under MIT license, binaries are under GPL for obvious reasons): assrender_0.11-src.7z (http://www.mod16.org/assrender/assrender_0.11-src.7z)


Syntax:
assrender(clip c, string file, int "hinting"=2, float "scale"=1.0, string "charset"="UTF-8", int "loglevel"=-1, string "logfile"="")
Parameter explanations (all parameters except the clip and the input file are optional):

file: The .ass file to render; no other subtitle format is currently supported.
hinting: What kind of font hinting to use. Valid values are 0-3; see below for further explanations of this.
scale: How much to scale the rendered text. Default is 1.0, i.e. 100% scaling (no change).
charset: The character set of the .ass file, in the standard GNU iconv format (i.e. ISO-8859-1, UTF-16, CP1252, etc are all recognized).
loglevel: How much diagnostics libass should output to the logfile. Valid values are from -1 to 7, where -1 means nothing, 0 means fatal errors only and 7 means output several hundred kB of internal data structures. 5 is probably sane if you want warnings about things that have gone wrong.
logfile: Where to write the log. If you set loglevel >= 0, you must specify this too.


Regarding hinting:

0 means disable hinting completely. Might be useful with problematic fonts.
1 means light autohinting. This is what libass recommends for compatibility.
2 means normal hinting.
3 means use FreeType's native hinting, which may or may not be buggy.

Normally you'd use 2 or 1, unless things look odd.


Advantages and disadvantages
This filter should mainly have two advantages over VSFilter, namely:
a) it works under wine, and
b) it's probably a lot faster.

On the other hand it has a few limitations, most notably it only supports RGB32 input so far. If someone is sitting on a fast (preferably assembly optimized) routine that can overlay RGBA on YV12/YUY2, feel free to speak up.

Furthermore, libass isn't really bug-for-bug compatible with VSFilter, so it might render stuff a bit differently compared to what you're used to.


Todo

Expose more libass parameters (aspect ratio compensation and default font comes to mind)
Make overlaying faster (assembly optimize it?)
Use Haali's matroska parser to support things like assrender("file.mks", track=2)
Get rid of the fontconfig configuration directory
Implement VFR compensation
Implement an equivalent of VSFilter's MaskSub()
Steal some subtitles parser code for various formats from Aegisub, convert things to ASS internally and support more subtitle formats than just .ass



Other stuff
It's compiled against a fairly recent libass, this one (http://repo.or.cz/w/libass.git?a=commit;h=7c19ed7321a7e233e53a79d448a2a06cb0ec855c) unless I misremember. I know that technically I'm probably not GPL-compliant because I'm not distributing the source code of the exact versions of freetype/fontconfig/expat/zlib it's linked against (Debian Squeeze's versions including their patches as of three days ago, apt-get source if you want them), but you know, I really don't give a darn.

If you want to compile the source code you need a working mingw32 environment. If you don't want to compile libass and its deps yourself (afaik it's incredibly hard to get libass to build on msys-mingw32 because of the permanent state of autotools hell it is in; personally I didn't bother and just crosscompiled on linux), you can get my compiles (http://www.mod16.org/assrender/libass-static-mingw32.tar.bz2). Oh, and you need stdint.h for Visual Studio (http://code.google.com/p/msinttypes/) too just to make it even more annoying to compile.

[Gavino]

In the meantime if someone knows how to easily convert a PVideoFrame to RGB32 without implementing the conversion myself, tell me and I'll support all input colorspaces and just convert to rgb32 and back again internally.
In your constructor, just env->Invoke("ConvertToRGB32") on the input clip, and similarly to convert back.

[TheFluff]

Nice try (I already attempted that) but I don't have a clip to convert back, I have a PVideoFrame, and I'm not going to change colorspace randomly without telling the user.

[Myrsloik]

In your constructor, just env->Invoke("ConvertToRGB32") on the input clip, and similarly to convert back.

No, noticed how no other filter does implicit colorspace conversions? Same thing applies here. Also converting back implicitly is even worse because then you just lose even more precision instead of letting the filter after implicitly convert to its own preferred format. Just say NO.

If you for some reason want to implement it anyway do something like this in AvisynthPluginInit2:
return new MyFilter(Env->Invoke("ConvertToRGB32", Args[0]), all other filter args go here));

I meant the create function, do never trust coding advice on internet forums

[Gavino]

Instead of constructor, I should have said the 'create' function that calls the constructor. In outline,
static AVSValue Create(AVSValue args, ...) {
PClip child = args[0];
child = env->Invoke("ConvertToRGB32", child);
PClip result = new MyFilter(child, ...);
return env->Invoke("ConvertToXXX", result);
}
Of course, you need to add error handling and check the original colorspace to know what to convert back to, but this shows the basic approach.

Whether you should do it or not is a separate issue.

[TheFluff]

Posted 0.11; forgot that I had the charset hardcoded to UTF-8, now it has a charset parameter instead. Also flushes the logfile after each write.

[sneaker_ger]

How's the progress going? I'm especially interested in the mkv parsing. (Or someone willing to add such a feature to vsfilter...)

[TheFluff]

There wasn't much interest in this filter so I was like :effort: and never did anything with it. The MKV parsing should be fairly easy to implement actually, but it's of limited use as long as the filter can only be used on RGB32.

[sneaker_ger]

I guess there wasn't much interest without your to do list implemented. Vicious Cirlce ... :devil:

[TheFluff]

Fix the RGB32 limitation and I'll get right on that todo list.

[Keiyakusha]

Is it possible to make libass-based directshow filter? I'm surprised that libass wasn't ported to windows yet (in some more or less usable way), especially if it claims to be 50% faster than vsfilter.

[TheFluff]

Certainly, if you assume it's possible to write a VSFilter-like directshow filter. (For most people, including me, it isn't.)

[SledgeHammer_999]

@Keiyakusha why don't you enable sub rendering in ffdshow-tryouts? (or does it contain the same code as vsfilter?) Is it slower?

[Keiyakusha]

Certainly, if you assume it's possible to write a VSFilter-like directshow filter. (For most people, including me, it isn't.)
I see, thanks. It wasn't actually request for you so no problems. I just wondering why there is no attempts to port it.

@Keiyakusha why don't you enable sub rendering in ffdshow-tryouts? (or does it contain the same code as vsfilter?) Is it slower?
Well, I don't know where ffdshow's code came from and actually ffdshow seems to be faster. I do use it sometimes but unfortunately it still gives me some errors like text shown in wrong direction (already reported/confirmed), total corruption in some cases (reported/confirmed) or some characters misplaced a bit so they overlapping with other ones (not reported by me yet, but probably known)

[Mug Funky]

heya, i'm not getting any subs rendered at all?

i'm using an ssa file.

[TheFluff]

I see, thanks. It wasn't actually request for you so no problems. I just wondering why there is no attempts to port it.
I think the two main reasons are that VSFilter is "good enough", and that writing directshow filters in general and intermediate video filters that connect to anything in particular is fucking rocket science that requires a directshow guru.

Well, I don't know where ffdshow's code came from and actually ffdshow seems to be faster. I do use it sometimes but unfortunately it still gives me some errors like text shown in wrong direction (already reported/confirmed), total corruption in some cases (reported/confirmed) or some characters misplaced a bit so they overlapping with other ones (not reported by me yet, but probably known)
ffdshow has its own render implementation. Last time I looked at it, it only supported a rather small subset of the features available in .ass and was very buggy. That was a long while ago though.

heya, i'm not getting any subs rendered at all?

i'm using an ssa file.
If you by SSA mean old SSA v4 (not v4+) I'm not sure if libass supports that. Try converting it to ASS, and if that doesn't work either post the script and I'll take a look. I'm not going to put a lot of effort into debugging it though since this filter is in limbo until I get around to it again and fix the rgb32 limitation.

[lachs0r]

So, a lot of things happened in the past few days.

Within two days, I had learned a bit of C and reimplemented AssRender as an Avisynth C Plugin, so it no longer required building with MSVC.
Then, with my limited knowledge, I started working on Fluff’s TODO-list:


Support more than RGB32 - Almost done. Subsampling still needs work but should be somewhat usable.
Expose more libass parameters (aspect ratio compensation and default font comes to mind) - Done. Default font doesn’t seem to work because of Fontconfig’s retardedness.
Make overlaying faster (assembly optimize it?) - How much faster are we going to make it? It already tends to beat VSFilter tenfold…
Use Haali's matroska parser to support things like assrender("file.mks", track=2) - Maybe sometime in the future.
Get rid of the fontconfig configuration directory - Done (patched Fontconfig). Also added a parameter for specifying an additional font directory.
Implement VFR compensation - Done, timecodes v1 and v2 supported.
Implement an equivalent of VSFilter's MaskSub() - Partially works. Just use AssRender with a BlankClip.
Steal some subtitles parser code for various formats from Aegisub, convert things to ASS internally and support more subtitle formats than just .ass - SRT support is working, but I forgot stealing from Aegisub :P


See the ChangeLog for further details.

It’s available here: http://luck3r.phicode.de/assrender/

I’ll continue working on it, and maybe we’re also gonna see a working DirectShow transform filter this year so VSFilter can finally rest in peace.

[Mug Funky]

nice one.

it might be worth adding on your site that you need to call it with "load_stdcall_plugin"... if it's there and i missed it, i apologise.

it's working with ssa now. i'm happy :)

[rapier]

assrender is very, very fast. I'm impressed. With assrender now I can see softsubbed karaoke and typesetting on 720p videos without lagging on a C2D E2160 using GMA950 onboard video. I have some complex karaoke scripts with two thousand lines of code that now runs almost on realtime.

Questions:

1) Is it possible to make assrender even faster?

2) Is it possible to make Aegisub use assrender? Aegisub 2.18 only recognizes VSFilter and VSFilterMod.

3) I can't use assrender on Windows 7 64bit. Says "unable to load C plugin". Other C plugins, like Yadif, works. Is there a way to fix that?

PS.: Sorry for my bad English.

[lachs0r]

1) Is it possible to make assrender even faster?

Yes.

2) Is it possible to make Aegisub use assrender? Aegisub 2.18 only recognizes VSFilter and VSFilterMod.

No, but that’s fine, since Aegisub supports libass directly (if you find someone to build it with the libass subtitle provider enabled).

3) I can't use assrender on Windows 7 64bit. Says "unable to load C plugin". Other C plugins, like Yadif, works. Is there a way to fix that?

Never bothered with 64-bit AviSynth, and at the moment I neither have a mingw-w64 toolchain nor a 64-bit Windows testing environment ready, and this won’t change until I have a better internet connection (this should only take a few weeks).

[rapier]

Never bothered with 64-bit AviSynth, and at the moment I neither have a mingw-w64 toolchain nor a 64-bit Windows testing environment ready, and this won’t change until I have a better internet connection (this should only take a few weeks).

I use Avisynth 32bit, with 32bit filters and codecs, on Windows 7 64bit, on other PC. All filters work except assrender. Even Yadif C works.

Edit: I uninstalled and reinstalled Avisynth and now assrender works on W7 64bit.

[lachs0r]

Some news:

Version 0.20 fixed RGB32 support (it’s actually usable with BlankClip(pixel_type="RGB32") now).
Version 0.21 fixed YV12 subsampling so it no longer looks horrible, which should be rather good news for most users.

Then there were some fixes to my fontconfig patchset. It should behave a bit more friendly now (and actually use the right directory for saving its cache files).

Also, the site has moved to http://srsfckn.biz/assrender/.

[sneaker_ger]

Thx. Already feared you'd gone missing, as your other homepage went down.

[lachs0r]

Almost forgot to post here.
0.22 fixed that annoying hang on vector clips


I feel stupid for not noticing this when I copied over some code from TheFluff’s C++ implementation back then:

if (img->w == 0 || img->h == 0)
continue;
Obviously, this caused an infinite loop if libass returned a glyph with zero width or height at some point.

It should have been this:
if (img->w == 0 || img->h == 0) {
img = img->next;
continue;
}

[lachs0r]

* Version 0.23:
- disabled font hinting by default
binary:
- updated libass to current git HEAD and included Harfbuzz:
- added support for bidirectional text, Arabic shaping etc.
- added proper support for @fonts (vertical writing)
- slight performance regression
(glyph cache not hooked up with Harfbuzz yet)
- updated FreeType to current git HEAD:
- fixed outline stroker for some broken fonts

Edit: 0.24 released, fixing the performance regression.

Download (http://srsfckn.biz/assrender/assrender-0.24.7z)

[tateu]

lachs0r,

I don't know if you'd be interested but I am working on making an AssRenderSubtitle function that can be used as a very close drop in replacement for the default AviSynth Subtitle function.

Subtitle has the following parameters:
Subtitle (clip, string "text", int "x", int "y", int "first_frame", int "last_frame", string "font", float "size", int "text_color", int "halo_color", int "align", int "spc", int "lsp", float "font_width", float "font_angle", bool "interlaced")

and my replacement has:
AssRenderSubtitle (clip, string "text", int "x", int "y", int "first_frame", int "last_frame", string "font", float "size", int "text_color", int "halo_color", int "align", int "spc", int "lsp", float "font_width", float "font_angle", bool "interlaced", float "rot_x", float "rot_y", float "scale_y", int "origin_x", int "origin_y", int "hinting", float "scale", string "charset", int "debuglevel", string "fileout", int "wrap_style", bool "bold", bool "italic", bool "underline", bool "strikeout", int "shadow_color", bool "opaque_box", int "border_size", int "shadow_x", int "shadow_y", float "gaussian_blur", float "gaussian_blur_shadow", int "blur_edges", int "blur_edges_shadow", bool "base_align", float "shear_x", float "shear_y", float "dar", float "sar", int "top", int "bottom", int "left", int "right", string "fontdir", bool "as_mask")

The first set of parameters (clip through interlaced) match Subtitle pretty closely and have the same variable names. The kerning and hinting of Subtitle seems to be a little different from what is produced by libass/freetype/fontconfig, so AssRenderSubtitle doesn't produce a 100% pixel match to the output from Subtitle, but it's pretty close. Also, I haven't been able to get the spc (character spacing), lsp (line spacing) or font_wdith parameters of AssRenderSubtitle to match Subtitle. They can be pretty far off. I'd like to figure that out but it is not super high on my list. And the interlaced parameter of my function just adds some gaussian blur which works differently than the AviSynth parameter which "effectively applies a mild vertical blur."

A second set of parameters (rot_x through shear_y) mostly handle libass features such as xyz rotation, shadow color/transparency/offset, etc. I also modified libass (I worked from libass-0.9.13, I had trouble compiling the git head) so that the font and it's shadow can be blurred independently from each other. This allows a soft shadow with a crisp font, whereas the default libass can only produce a blurred shadow if the font is also blurred. Another modification I made to libass was to allow a font to be aligned on the baseline (like Subtitle's alignment = 4, 5 or 6). The default libass can only align to the vertical center or top or bottom bounding box.

The last set of parameters (dar through fontdir) match your default AssRender parameters. Oh, and I added one last parameter (bool "as_mask") because I didn't like the way AssRender handled creating transparency on a 32 bit clip. The as_mask=true behaves the way AssRender currently does where the transparency is added to the alpha channel. With as_mask=false, the transparency is composited directly into the rgb channels.

I also plan to add AssRenderSmpte, AssRenderTime and AssRenderFrameNumber.

[lachs0r]

I also modified libass (I worked from libass-0.9.13, I had trouble compiling the git head) so that the font and it's shadow can be blurred independently from each other. This allows a soft shadow with a crisp font, whereas the default libass can only produce a blurred shadow if the font is also blurred.

Just add an invisible border. That does the same without code modification.

[tateu]

Well, of course, but I am actually using the border.

[twazerty]

Nice renderer. I am going to use it via wine since VSFilter doesn't work properly.

I have a question. On Windows I use VSFilter with srt files and a srt.style file to style the rendered text. Your filter doesn't take this file:

sub.srt.style:
[Script Info]
; This is a Sub Station Alpha v4 script.
; generated by AVCHDCoder
ScriptType: v4.00
Collisions: Normal
PlayResX: 1920
PlayResY: 1080
Timer: 100.0000
Style: Default,Verdana,52,&Hffffff,&Hffff00,&H000000,&H000000, 0,0,1,3, 2,2, 0,0,36,0,1

An ass file with similar contents is loaded fine. How can I achieve the same thing with srt files? because I don't like the default srt rendering of your plugin (no styling).

Thanx

[TheFluff]

Nice renderer. I am going to use it via wine since VSFilter doesn't work properly.

I have a question. On Windows I use VSFilter with srt files and a srt.style file to style the rendered text. Your filter doesn't take this file:

sub.srt.style:
[Script Info]
; This is a Sub Station Alpha v4 script.
; generated by AVCHDCoder
ScriptType: v4.00
Collisions: Normal
PlayResX: 1920
PlayResY: 1080
Timer: 100.0000
Style: Default,Verdana,52,&Hffffff,&Hffff00,&H000000,&H000000, 0,0,1,3, 2,2, 0,0,36,0,1

An ass file with similar contents is loaded fine. How can I achieve the same thing with srt files? because I don't like the default srt rendering of your plugin (no styling).

Thanx

That is not a valid ASS file, nor a valid SRT file, nor a valid SSA file. It might work in VSFilter because VSFilter is retarded and internally treats everything like ASS (you can even use ASS override codes in SRT or whatever you please when using VSFilter). You will have to convert your SRT file to ASS (which is trivial, using Aegisub or some other tool). External style files for SRT is not supported by AssRender.

[ganymede]

Nice renderer. I am going to use it via wine since VSFilter doesn't work properly.On my system VSFilter works very well under wine (at least wine 1.3.x).

[twazerty]

On my system VSFilter works very well under wine (at least wine 1.3.x).

I see 1.3 is Beta. Under 1.0 it doesn't run properly (only first word of each line is shown). I'll try 1.3 beta soon.

@TheFluff

Already was looking for a tool to do the job. But it isn't easy to find any srt to ass tools because I need a command line interface so I can build it into AVCHDCoder.

[TheFluff]

I see 1.3 is Beta. Under 1.0 it doesn't run properly (only first word of each line is shown). I'll try 1.3 beta soon.

@TheFluff

Already was looking for a tool to do the job. But it isn't easy to find any srt to ass tools because I need a command line interface so I can build it into AVCHDCoder.

Writing your own converter should be like a hundred lines of code, tops. Less if you're using a language in which text processing is simple, like Perl. Actually, I think I could do it in like three or four lines of Perl by abusing regexes.

[twazerty]

Writing your own converter should be like a hundred lines of code, tops. Less if you're using a language in which text processing is simple, like Perl. Actually, I think I could do it in like three or four lines of Perl by abusing regexes.

You are right, but I am a litte lazy :D. For linux I found the tool subcli which does the job fine for now. Later on I'll write my own Java version of srt to ass.

[TheFluff]

You are right, but I am a litte lazy :D. For linux I found the tool subcli which does the job fine for now. Later on I'll write my own Java version of srt to ass.


#!/usr/bin/perl

$_ = shift or die("file plz");
open(H, "<", $_) or die ("I ain't seein' it");
local $/ = undef;
$_ = <H>;
close(H);
s/0?(\d+:\d{2}:\d{2}),(\d+) --> 0?(\d+:\d{2}:\d{2}),(\d+).*?^(.*?)(\n\d+\n(?=\d{2}:\d{2})|.\z)/format_line($1,$2,$3,$4,$5)/msge;
sub format_line {
my ($s, $sm, $e, $em, $t) = @_;
$t =~ s/\s*\n\s*/\\N/mg;
$t =~ s/[\s\\N]+$//g;
return sprintf("Dialogue: 0,%s.%03d,%s.%03d,Default,,0000,0000,0000,,%s\n", $s, $sm, $e, $em, $t);
}
print;

[nautilus7]

Can anyone tell me how to use this plug in? which is the correct syntax? what are valid arguments for each parameter? Very poor readme file...

[sneaker_ger]

For most people it would just be something like:
DirectShowSource("fileyouwanttoputsubtitleson.mkv")
loadCplugin("c:\assrender.dll")
assrender("subtitle_file.ass")

The readme lists all parameters. Be more specific as to what you looking for.

[TheRyuu]

ffvideosource("fileyouwanttoputsubtitleson.mkv")
loadCplugin("c:\assrender.dll")
assrender("subtitle_file.ass")

ftfy.

[sneaker_ger]

Funny, I actually started entering "ffvideosou", but then used dss instead, because I didn't feel like answering any follow up questions about "ffvideosource" being an unknown plug-in etc.

[nautilus7]

I made it work, now. Thanks.

[lachs0r]

* Version 0.24.1:
binary:
- updated libass to current git HEAD
- switched Harfbuzz to libass’ compatibility branch
- compiled Harfbuzz without Uniscribe backend
fixes lots of crashes and misbehavior
Just a quick update. Most of the bugs that appeared after 0.22 should be fixed by that.

Download (http://srsfckn.biz/assrender/assrender-0.24.1.7z)

[lachs0r]

* Version 0.25:
- code restructured
- added support for the BT.709 color space and the “Video Colorspace”
property that has been introduced with recent versions of Aegisub.
binary:
- updated everything, switched to MinGW-w64
(same toolchain as mplayer2 now)

It's also on GitHub now, in case anyone wants to improve my crappy code.

Download (http://srsfckn.biz/assrender/assrender-0.25.7z)

[sneaker_ger]

Thx, but has a final agreement been reached on how to add "Video Colorspace"/color correction info to ASS scripts? I think ASS renderers should hold on implementing these until a final decision has been made. From the discussions on the xy-vsfilter google code site (issue 40), it seems that this may be subject to change until Aegisub 3.0.0 stable is released.

[lachs0r]

Well, this is just used for convenience in an attempt to automatically choose the correct color space for the video, and it’s trivial to change too. AssRender will just follow whatever Aegisub is doing.

It’s is much more important for playback software, but there the right way to go is to stop rendering the subtitles onto the video surface and instead handle the subtitles separately, without requiring color space conversion or scaling (like what mplayer2 is doing in its EOSD code with renderers that support it, e.g. gl, gl3, direct3d and vdpau), which eliminates the issue entirely.

[sneaker_ger]

Well, this is just used for convenience in an attempt to automatically choose the correct color space for the video, and it’s trivial to change too. AssRender will just follow whatever Aegisub is doing.

It's just that this tag may be removed or changed until the Aegisub stable release (ETA 1-2 months), so we don't want anyone to actually adopt it at this point in time.

It’s is much more important for playback software, but there the right way to go is to stop rendering the subtitles onto the video surface and instead handle the subtitles separately, without requiring color space conversion or scaling (like what mplayer2 is doing in its EOSD code with renderers that support it, e.g. gl, gl3, direct3d and vdpau), which eliminates the issue entirely.

Yes, rendering directly in RGB would be best. I don't know if you have read the google page I mentioned, but the majority of those involved in the discussion (basically everyone but me), thinks that we should stay compatible with current vsfilter standalone, which always does RGB->YUV using BT.601. People worked around that limitation by skewing colors away from RGB to make vsfilter display the desired colors correctly even on e.g. BT.709 video. I don't know if you have any contact to the Aegisub devs, but if that discussion is publicly (IRC logs?) available I'd ask you to point me to it, as I'm very interested in the outcome and the arguments.


Anyways, assrender 0.25 does not work correctly at this point. To emulate vsfilter behavior (and the definition of the current "Video Colorspace" tag) one would have to set "Video Colorspace" to "BT.601", but this results in totally wrong colors at the moment. It would be better to revoke that feature for the time being.

[natt]

Well, this is just used for convenience in an attempt to automatically choose the correct color space for the video, and it’s trivial to change too. AssRender will just follow whatever Aegisub is doing.

It’s is much more important for playback software, but there the right way to go is to stop rendering the subtitles onto the video surface and instead handle the subtitles separately, without requiring color space conversion or scaling (like what mplayer2 is doing in its EOSD code with renderers that support it, e.g. gl, gl3, direct3d and vdpau), which eliminates the issue entirely.

It would eliminate the issue entirely if there were no legacy subtitles out there; but there are oodles of ass/ssa scripts that choose subtitle colors to match the video and assume vsfilter behaviour when doing so.

[lachs0r]

To emulate vsfilter behavior…
…is not the point of this feature. The point is to use the *correct* color matrix (i.e. the one used by Aegisub) for overlaying the subtitles.

It would eliminate the issue entirely if there were no legacy subtitles out there; but there are oodles of ass/ssa scripts that choose subtitle colors to match the video and assume vsfilter behaviour when doing so.
Easy solution: Forget legacy subtitles and move along. There’s no reason to give ourselves more trouble than necessary over old subtitle files.
The problem with those files is just that they always assume BT.601 colorspace, since Aegisub made the same mistake for a very long time.
Playback software that gives a shit would just have to convert the colors for files which do not have the Video Colorspace property.

[sneaker_ger]

…is not the point of this feature. The point is to use the *correct* color matrix (i.e. the one used by Aegisub) for overlaying the subtitles.

Did you test a video with "Video Colorspace: BT.601"? In my test the colors came out totally wrong, i.e. assrender 0.25 is broken. And I'm not talking about a small BT.601 vs BT.709 difference, but the colors are totally screwed.


Easy solution: Forget legacy subtitles and move along. There’s no reason to give ourselves more trouble than necessary over old subtitle files.

The Aegisub devs don't want to do that. As it currently stands, Aegisub 3.0.0 will always emulate "legacy" behavior (though it will add info to tell you that, but probably not in the way the current trunk does, so reading "Video Colorspace" right now will produce wrong results with final Aegisub 3.0.0).

[lachs0r]

I did test that. Worked fine here.

[lachs0r]

Ha ha, I see what you mean now. Nothing good comes from changing code at work and only testing that on a blankclip.
Fixed. That’s unrelated to the new property though.

[real.finder]

thank you for this plugin

I wonder how can I compile lachs0r c-plugin one and what I need for that

I didn't do any plugin compile before so I need your help

I plan to play with libass and I think AssRender is a good choice for that and to releasing AssRender with last libass

[TheFluff]

If you've never compiled a plugin before, AssRender is probably the single worst example to start with. You can't actually build the plugin itself until you've compiled libass with MinGW, and that's a gigantic pain since it has a billion annoying dependencies, many of which are very tricky to get to compile on Windows. Start with something else.

[real.finder]

If you've never compiled a plugin before, AssRender is probably the single worst example to start with. You can't actually build the plugin itself until you've compiled libass with MinGW, and that's a gigantic pain since it has a billion annoying dependencies, many of which are very tricky to get to compile on Windows. Start with something else.

any suggestion?

I chose AssRender because it's just a plugin, as I can see the full program like vlc or mpv which using libass will be harder

and AssRender easy to view the subtitle file with it every time in just avspmod

[Reel.Deel]

Sorry to revive this thread, but has anyone come across binaries for the updated AssRender (v0.28): https://github.com/pingplug/assrender

I've searched and came up empty handed, most I found was a fork of the v0.28 version here: https://github.com/vadosnaprimer/assrender

But still no binaries :(

[real.finder]

Sorry to revive this thread, but has anyone come across binaries for the updated AssRender (v0.28): https://github.com/pingplug/assrender

I've searched and came up empty handed, most I found was a fork of the v0.28 version here: https://github.com/vadosnaprimer/assrender

But still no binaries :(

I tried and seems I did build x86 one https://github.com/realfinder/assrender

the x64 give me some errors in Visual Studio 2019, also the x86 I did seems only work in avs+! is the avs+ c header not work with avs 2.6 unlike the c++ one?

[pinterf]

also the x86 I did seems only work in avs+! is the avs+ c header not work with avs 2.6 unlike the c++ one?
I'd need some more hints. Does not work = crash?

On the other hand, based on https://github.com/vadosnaprimer/assrender I have successfully built both x86 and x64 (after some path fixes).

[real.finder]

I'd need some more hints. Does not work = crash?

On the other hand, based on https://github.com/vadosnaprimer/assrender I have successfully built both x86 and x64 (after some path fixes).

I got this
https://i.postimg.cc/XqnMKmvm/Untitled.png (https://postimages.org/)

and can you share your edit of the code? with the x64 built :)

anyway, at least in the built I did libass in not uptodate in the code, and maybe the others too, I didn't try to update it yet

[pinterf]

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for
avisynth_c_plugin_init@4 or avisynth_c_plugin_init
Avisynth+ is looking for
_avisynth_c_plugin_init@4 or avisynth_c_plugin_init@4
When Visual Studio is compiling, it always decorates names with leading _ because of stdcall
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-160

So it won't be found by Avisynth 2.6 loader.

I remember a similar case (I hope I find it soon; C plugins are rare on my git). I'll be back.

As for the code edit: I've just cloned and not forked, it's only my local disk; but practically I didn't change the code.

[pinterf]

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for
avisynth_c_plugin_init@4 or avisynth_c_plugin_init
Avisynth+ is looking for
_avisynth_c_plugin_init@4 or avisynth_c_plugin_init@4
When Visual Studio is compiling, it always decorates names with leading _ because of stdcall
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-160

So it won't be found by Avisynth 2.6 loader.

I remember a similar case (I hope I find it soon; C plugins are rare on my git). I'll be back.
EDIT:
Yes, it was AvsInPaint. A definition file "assrender.def" must be created with the following content:
LIBRARY assrender
EXPORTS
avisynth_c_plugin_init@4 = _avisynth_c_plugin_init@4

Only for x86-32!

As for the code edit: I've just cloned and not forked, it's only my local disk; but practically I didn't change the code.

[pinterf]

Do you wish to do that or I can arrange it on my git?
I wonder if it can be ported to Linux as well?

[real.finder]

Do you wish to do that or I can arrange it on my git?
I wonder if it can be ported to Linux as well?

if you have a time then indeed you can do it better than me :) I am not a programmer in first place

it should work in Linux and any non windows os, libass and others are not made for windows in first place

[qyot27]

I had had some intention to get builds running on this at some point, but other stuff just kept getting in the way.

RE: Linux, etc., I mean, the CMakeLists.txt is right there and it shouldn't be *too* difficult, but I can't remember the exact details. One piece of it is that that other branch with all the *.vcxproj cruft and submodules and a local avisynth.lib is totally unnecessary; I'd argue it's even unnecessary on/for Windows (especially since "C plugin" is supposed to mean GCC is probably the preferred compiler, not MSVC), but it's 1000% unnecessary on non-Windows.

[pinterf]

I had had some intention to get builds running on this at some point, but other stuff just kept getting in the way.

RE: Linux, etc., I mean, the CMakeLists.txt is right there and it shouldn't be *too* difficult, but I can't remember the exact details. One piece of it is that that other branch with all the *.vcxproj cruft and submodules and a local avisynth.lib is totally unnecessary; I'd argue it's even unnecessary on/for Windows (especially since "C plugin" is supposed to mean GCC is probably the preferred compiler, not MSVC), but it's 1000% unnecessary on non-Windows.
I've got completely zero knowledge on libass and its history.
So, qyot27, what you call the 'other branch' (vadosnaprimer) is the one dealing with submodules and introduced msvc (2015 at that time) support. The older one (pingplus) is just telling CMake to find libass and use.
https://github.com/pingplug/assrender/blob/master/src/CMakeLists.txt
Do you mean tha on Linux the old one is preferred, while on windows/msvc the vadosnaprimer one?

[qyot27]

No. I mean that the proper course of action is to correctly use CMake for all platforms. There aren't any code changes on the Blitzker/vadosnaprimer repo at all (save for one that seems pretty hacky (https://github.com/vadosnaprimer/assrender/commit/5635baa08a6bdad4291f2f6791643572ab6d0b0d); you can see this by just running git whatchanged -15 and looking at what files got touched) - it's all just the addition of MSVC project files, and changes to the README. Basically, if it's necessary, cherry-pick that one header change into the pingplug repo, ignore everything else, and flesh out the CMakeLists.txt instead.

As far as libass and its dependency chain goes, I've been dealing with that for 7 or 8 years as a prerequisite for mpv builds. As TheFluff mentioned way back on page 1, it's largely assumed you're compiling those with MinGW-w64 anyway, which is exactly what the mpv build guide (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) has covered*. Most of the other commonly-used tool build systems on Windows (media autobuild suite or possibly just regular MSys2) would essentially be doing the same things and users wouldn't need submodules for anything.

*lines 412-1516 (for the zlib...fontconfig stuff) and then lines 4543-4605 for libass itself.

[pinterf]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???

[pinterf]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???
EDIT: linux, windows+msys2-mingw, windows msvc works. Cleanup is needed now after the experiments and check again if my build instructions really work.

EDIT: this is where I got finally. https://github.com/pinterf/assrender
Check README.md and feel free to correct it.
EDIT: new build 0.29 (https://api.github.com/repos/pinterf/assrender/releases)

[real.finder]

EDIT: new build 0.29 (https://github.com/pinterf/assrender/releases)

thanks, it seems work no problem now

[qyot27]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???
You can use pkg-config to detect AviSynth+ as well, since the .pc file gets generated and installed too¹.

The thing I wonder about is if linking a C-plugin to a MinGW-built libavisynth.dll.a import library will cause problems with a MSVC-built AviSynth+ host. My gut reaction says that it would be a problem, but I also wouldn't be surprised if it's okay on 64-bit but not 32-bit. The FFMS2 C-plugin is no use here; it uses LoadLibrary to communicate with the host AviSynth, so it doesn't link to anything except the FFmpeg libraries and extra libraries therein (zlib, bz2, etc.).

¹in WSL:
qyot27@cappuccino:/mnt/c/Windows/system32$ pkg-config --cflags --libs avisynth
-I/usr/local/include/avisynth -L/usr/local/lib -lavisynth

[qyot27]

While it built on Linux, I hit a roadblock when trying to actually use it. Turns out it's not linking to libavisynth, so it can't find the right API calls.

Very rough sketch (I didn't try to do any OS guarding, and requiring 3.7.0 is probably excessive):
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 7a4569f..6ad2d63 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -38,10 +38,12 @@ IF (NOT WIN32 OR MINGW)
FIND_PACKAGE(PkgConfig REQUIRED)
PKG_CHECK_MODULES(LIBASS REQUIRED libass>=0.12.0)
target_include_directories(${PluginName} PRIVATE ${LIBASS_INCLUDE_DIR})
+ PKG_CHECK_MODULES(AVISYNTH REQUIRED avisynth>=3.7.0)
+ target_include_directories(${PluginName} PRIVATE ${AVISYNTH_INCLUDE_DIR})
ENDIF()

#dedicated include dir for avisynth.h
-target_include_directories(${ProjectName} PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
+#target_include_directories(${ProjectName} PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)

if (WIN32)
# avisynth.lib for C API
@@ -57,7 +59,7 @@ if (WIN32)
TARGET_LINK_LIBRARIES(${ProjectName} ${AVS_LIBDIR}/avisynth.lib)
endif()
else()
- TARGET_LINK_LIBRARIES(${ProjectName} ${LIBASS_LDFLAGS} )
+ TARGET_LINK_LIBRARIES(${ProjectName} ${AVISYNTH_LDFLAGS} ${LIBASS_LDFLAGS} )
endif()

include(GNUInstallDirs)
diff --git a/src/assrender.h b/src/assrender.h
index 23c154e..f63bf94 100644
--- a/src/assrender.h
+++ b/src/assrender.h
@@ -6,7 +6,7 @@
#include <math.h>
#include <string.h>
#include <ass/ass.h>
-#include "avisynth_c.h"
+#include <avisynth/avisynth_c.h>

#if defined(_MSC_VER)
#define __NO_ISOCEXT


With the above, it also works on Linux as well, with the obvious caveat that AssRender hasn't yet been updated to support high bit depth, so the 10-bit test file I had lying around needed ConvertBits(8) before handing it over to AssRender. But it was certainly able to load the styled karaoke subtitles and even load the font used by specifying the fontdir= parameter (although since the font was Ubuntu Regular and I was testing under Ubuntu, that was a pointless test).

[real.finder]

and even load the font used by specifying the fontdir= parameter (although since the font was Ubuntu Regular and I was testing under Ubuntu, that was a pointless test).

speaking of fonts, the "testing sub file" here https://github.com/libass/libass/issues/148#issuecomment-780239346 has font (Attached) inside the .ass file, vsfilter load it ok as it should, but assrender didn't load it unless using fontdir= to folder has the font (didn't try to install the font in the system), is it problem in assrender or libass itself?

[qyot27]

I wouldn't know; the prevailing norm is typically not to embed fonts directly in the subtitle file, as issues with that come up sometimes on mpv's bug tracker. So I assume it's probably in libass itself.

[real.finder]

seems colorspace in assrender is wrong

using ctest.avi https://www.solidfiles.com/v/nDrqzLnrLAmrz and https://www.solidfiles.com/v/7GnWRwwrXyYkY

vsfilter:- (also same as no using anything)
https://i.postimg.cc/hJNRRtVX/vs.png (https://postimg.cc/hJNRRtVX)
work as it should it's not, its same as the 3rd image, vsfilter not work with yv24 and will do nothing if it used with yv24

assrender:-
https://i.postimg.cc/Vd4yLRjQ/la.png (https://postimg.cc/Vd4yLRjQ)
all wrong

assrender with setting colorspace = "Rec601":-
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)
almost ok, still not as perfect as vsfilter, maybe this libass problem not assrender
it's not libass one as Kainote (aegisub don't like libass and crash on me in many cases) with libass work ok edit: vsfilter show similar output

For historical reasons, if .ass file not has "YCbCr Matrix:" info then it should be treated as it "Rec601" to maintain compatibility, and seems assrender use Rec709 in this case

[real.finder]

I wouldn't know; the prevailing norm is typically not to embed fonts directly in the subtitle file, as issues with that come up sometimes on mpv's bug tracker. So I assume it's probably in libass itself.

I did try it and it seems work ok in mpv!

https://i.postimg.cc/QKVr2YMq/Annotation-2021-02-17-083749.png (https://postimg.cc/QKVr2YMq)

[pinterf]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.

[real.finder]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.

it's not the best choice even for Windows now (there are some win10 update added new fonts folder per user)

[qyot27]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.
Typically I believe it tends to be /usr/share/fonts. But fontconfig means that it probably should just be reading the result of fc-cache.

[pinterf]

Meanwhile you can try 0.30.
All colorspaces are supported up to 16 bits.
Incl. YV411, RGB48/64 and planar RGB.

[FranceBB]

0.30 works fine on Windows XP in 16bit and the best part is that I can finally hardsub at high bit depth without doing this:

s16 = last
DitherPost (mode=-1)
TextSub("subs.ass")

#Overlay 8bit subs to 16bit video
Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

#Output 16bit interleaved to avs4x265.exe -> x265.
Dither_Out()

as I can just do this:

AssRender("subs.ass")

in 16bit planar. :D
I don't know why AssRender works just fine on XP and VSFilter doesn't, but this way I can finally work in regular planar high bit depth and I'm thrilled! :D

[StainlessS]

Some versions of VSFilter are a bit dodgy, not sure if particularly error laden on XP or not.

[pinterf]

And a semi-final (there is no such word as 'final') bugfix release.
Planar RGB colors were khhm.. not really perfect*.

v0.31:
https://github.com/pinterf/assrender/releases/

*channels mixed. Could not recognized on FF FF FF full black text color.

Important note: by introducing high bit depth, Avisynth 2.6 classic is not supported anymore. This is a C plugin, we cannot be smart.
For this reason release pack contains v0.29 which is happily running with old avs 2.6.0.5.

[DTL]

What glyph render engine do it uses ? It looks do not take any care about conditioning for video systems and its output cause awful alising and ringing. May be usable only at final digital display resolution without scaling.

If it can output xxxA format with alpha channel for blending the immediate processing may be applied like GaussResize(width/2,height/2, p=20) (to the double sized rendered text). But it is better to make processing internally in the filter. Like applying FSAA by shrinking with appropriate core Avisynth resamplers with a given 'AA-quality' ratio. 2x already do a good work.

My test script:

LoadPlugin("assrender.dll")
BlankClip(1000,2000,1000, pixel_type="YV12", color=color_gray30)

assrender(last, "srt01.srt", srt_font="Wolfgang Amadeus Mozart", scale=2, bottom=-500)

GaussResize(width/2,height/2, p=20)

SincResize(width*2, height*2,taps=8)

srt.txt listing
1
00:00:00,498 --> 00:00:02,827
- Sample text for testing


If remove GaussResize(width/2,height/2, p=20) the output looks significally distorted.

[qyot27]

FreeType.

https://mrandri19.github.io/2019/07/24/modern-text-rendering-linux-overview.html

Although all the video players I know of that use libass always overlay the subs as the final step in the chain.

And there's also the part where the filter is designed for a subtitle format that's far more configurable than SRT.

[DTL]

FreeType looks typical PC-screen glyph rendering engine.

Avisynth typically used for processing from file to file with unknown target digital display pixel count (really for moving pictures non-pixel based displays at all). So it is good at text render sources at least to have an option for creating more compatible with 'moving pictures' video systems images data.

Same applied to core Avisynth text renders like 'Subtitle' filter, but I think it mostly used for tech debugging purposes not for real high quality production.

If the text string of glyphs is rendered inside external to plugin library so the only option is post-process the whole subtitle text image. But it must be done before blending to output.

May be at least add option for output non-blended with alpha subtitle render result for external post-processing inside scripting like:

LoadPlugin("assrender.dll")
src=BlankClip(1000,2000,1000, pixel_type="YV12", color=color_gray30)

dummy_x2=PointResize(src, src.width*2, src.height*2)

srt_layer=assrender(dummy_x2, "srt01.srt")

srt_layer=GaussResize(srt_layer,width/2,height/2, p=20) # or any other MyLovelyFSAADownscaler(...)

Overlay(src, srt_layer)


It will be a bit less performance because downscaler will process whole 2x frame buf insead of only subitle area, but full working workaround.

[Reel.Deel]

And a semi-final (there is no such word as 'final') bugfix release.
Planar RGB colors were khhm.. not really perfect*.

v0.31:
https://github.com/pinterf/assrender/releases/


:thanks: Thank you for all that you do pinterf! I updated the wiki already, I see that every now and then you beat me to it, shame on me :)

[real.finder]

seems colorspace in assrender is wrong

using ctest.avi https://www.solidfiles.com/v/nDrqzLnrLAmrz and https://www.solidfiles.com/v/7GnWRwwrXyYkY

vsfilter:- (also same as no using anything)
https://i.postimg.cc/hJNRRtVX/vs.png (https://postimg.cc/hJNRRtVX)
work as it should

assrender:-
https://i.postimg.cc/Vd4yLRjQ/la.png (https://postimg.cc/Vd4yLRjQ)
all wrong

assrender with setting colorspace = "Rec601":-
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)
almost ok, still not as perfect as vsfilter, maybe this libass problem not assrender
it's not libass one as Kainote (aegisub don't like libass and crash on me in many cases) with libass work ok

For historical reasons, if .ass file not has "YCbCr Matrix:" info then it should be treated as it "Rec601" to maintain compatibility, and seems assrender use Rec709 in this case

another test file but it has YCbCr Matrix info in it https://github.com/pinterf/assrender/files/6056802/ctest2.zip

it show similar output to
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)

again no problem in vsfiler family (TextSub)

edit: I did a test for SD (Rec601)

https://github.com/pinterf/assrender/files/6056968/ctest.SD.avi.zip

https://github.com/pinterf/assrender/files/6056969/ctest.SD.sub.zip

https://github.com/pinterf/assrender/files/6056971/ctest.SD.sub.with.info.zip

and it seems work fine! so the problem happen when the video is HD

[pinterf]

Manually recalculated the applied rgb2yuv (709) matrix coefficients and there really is a miscalculation.
edit: please check this one: https://github.com/pinterf/assrender/releases/tag/0.33

[real.finder]

Manually recalculated the applied rgb2yuv (709) matrix coefficients and there really is a miscalculation.
edit: please check this one: https://github.com/pinterf/assrender/releases/tag/0.33

it's kinda better but still not fixed, I think it should copy how vsfilter do it

[pinterf]

Apart from this 709 matrix coefficient typo, have you read the readme that the default color space is governed by video dimensions?

`string colorspace`

The color space of your (YUV) video. Possible values:
- Rec2020, BT.2020
- Rec709, BT.709
- Rec601, BT.601

Default is to use the ASS script’s “Video Colorspace” property, else guess based on video resolution (width > 1920 or height > 1080 → BT.2020, then width > 1280 or height > 576 → BT.709).


This script is o.k.
AviSource("ctest.avi").Info()
ConvertToRGB("rec601")
ConvertToYV12(matrix="rec709")
AssRender("ctest.ass") # treats HD (>=1280x720) as BT.709

[pinterf]

My latest fix for coeff was not valid. Either I have found a wrong source for coeffs on the Internet or had bad eyes when I was copying. Anyway I have reverted that change back and now wait a bit.

[Reel.Deel]

Apart from this 709 matrix coefficient typo, have you read the readme that the default color space is governed by video dimensions?

I think what real.finder is trying to say is that ASSFilter should behave like VSFilter. Long ago before HD, Aesgisub and VSfilter treated everything as BT.601. This issue has been discussed in this thread already and was concluded that ASSFilter should move away from legacy crap and keep doing things as they are.... I agree. If someone cares so much about legacy things they should use legacy VSFilter. Also, until now, there weren't any x64 binaries available so I don't think this filter was used much by people, just my guess.


To emulate vsfilter behavior...
…is not the point of this feature. The point is to use the *correct* color matrix (i.e. the one used by Aegisub) for overlaying the subtitles.

It would eliminate the issue entirely if there were no legacy subtitles out there; but there are oodles of ass/ssa scripts that choose subtitle colors to match the video and assume vsfilter behaviour when doing so.
Easy solution: Forget legacy subtitles and move along. There’s no reason to give ourselves more trouble than necessary over old subtitle files.
The problem with those files is just that they always assume BT.601 colorspace, since Aegisub made the same mistake for a very long time.
Playback software that gives a shit would just have to convert the colors for files which do not have the Video Colorspace property.

Some history on this issue:

https://github.com/dreamer2908/Aegisub_automation_scripts#ass-color-matrix-converter

https://guideencodemoe-mkdocs.readthedocs.io/typesetting/aegisub/#the-subtitles-provider


Edit:
Tool to change color matrix on ASS subtitles: ASSColorMatrixConverter (https://www.dropbox.com/s/n02xbdo904h1cw7/ASSColorMatrixConverter_beta9.7z)

[real.finder]

I think what real.finder is trying to say is that ASSFilter should behave like VSFilter. Long ago before HD, Aesgisub and VSfilter treated everything as BT.601

yes, even mpv and libass try keep VSFilter compatibility (mpv play those sample as they should), I still don't use libass things myself cuz there are some "not fixed yet" issues in libass since 2014!

anyway, VSfilter should work with other than BT.601 too if it set in the .ass file but still ASSFilter not behave like VSFilter

have you read the readme that the default color space is governed by video dimensions?

yes I know, but ctest2.ass (https://github.com/pinterf/assrender/files/6056802/ctest2.zip) should work as it since it BT.709 but it's give similar output to

https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)

AviSource("ctest.avi").Info()
ConvertToRGB("rec601")
ConvertToYV12(matrix="rec709")
AssRender("ctest.ass") # treats HD (>=1280x720) as BT.709

yes that ok :) but it do unnecessary conversion for colors, but I think it's ok for debugging purposes

[pinterf]

assrender seeks for
Video Colorspace:
but the .ass file is using
YCbCr Matrix:

e.g.
YCbCr Matrix: tv.709

Since the .ass file does not contain "Video Colorspace:" section, it does nothing.

I suppose assrender filter should detect "YCbCr Matrix:" isn't it?

[pinterf]

Next iteration v0.34:
https://github.com/pinterf/assrender/releases/tag/0.34

[real.finder]

assrender seeks for
Video Colorspace:
but the .ass file is using
YCbCr Matrix:

e.g.
YCbCr Matrix: tv.709

Since the .ass file does not contain "Video Colorspace:" section, it does nothing.

I suppose assrender filter should detect "YCbCr Matrix:" isn't it?

yes, that what I fix here https://github.com/pinterf/assrender/pull/2

but still the HD Video colors problem not fixed (but it get better as I said back then https://forum.doom9.org/showthread.php?p=1936112#post1936112 3rd image)

[pinterf]

Oh, I didn't recognized that PR, no notification received.

[pinterf]

I still cannot see any difference between the 1st and 3rd image.

[pinterf]

Does anyone use less-than-HD in 2021? Why should it behave in tv.601 by default?

[real.finder]

I still cannot see any difference between the 1st and 3rd image.

it's kinda hard to note yes, the yellow and green bar has no difference, you can let Histogram("luma") help you for luma but there are difference in chroma too

[real.finder]

Does anyone use less-than-HD in 2021? Why should it behave in tv.601 by default?

in case of old subtitles (2012 and down), they were with no YCbCr Matrix: info, new ones should already has YCbCr Matrix with tv.709

[pinterf]

So in the past 8 years subtitles are directly specifying the matrix. And if it's not specified directly, it is safe to say that they are 601?

[real.finder]

So in the past 8 years subtitles are directly specifying the matrix. And if it's not specified directly, it is safe to say that they are 601?

yes, and still there are some use 601 or no info at all (They still use old versions of aegisub or something)

[pinterf]

I think what real.finder is trying to say is that ASSFilter should behave like VSFilter. Long ago before HD, Aesgisub and VSfilter treated everything as BT.601. This issue has been discussed in this thread already and was concluded that ASSFilter should move away from legacy crap and keep doing things as they are.... I agree. If someone cares so much about legacy things they should use legacy VSFilter. Also, until now, there weren't any x64 binaries available so I don't think this filter was used much by people, just my guess.



Some history on this issue:

https://github.com/dreamer2908/Aegisub_automation_scripts#ass-color-matrix-converter

https://guideencodemoe-mkdocs.readthedocs.io/typesetting/aegisub/#the-subtitles-provider


Edit:
Tool to change color matrix on ASS subtitles: ASSColorMatrixConverter (https://www.dropbox.com/s/n02xbdo904h1cw7/ASSColorMatrixConverter_beta9.7z)
And in the source code as well:
https://github.com/ShiftMediaProject/libass/blob/master/libass/ass_types.h#L106

[pinterf]

vsFilter TextSub is exactly doing nothing
BlankClip(ColorbarsHD(), color = $123456)
TextSub("ctest2.ass")

No hint of color rectangles.
No wonder it perfectly fit the rectangles into colorbars samples because it left the Colorbars image untouched.
Or what did I do wrong?

[real.finder]

vsFilter TextSub is exactly doing nothing
BlankClip(ColorbarsHD(), color = $123456)
TextSub("ctest2.ass")

No hint of color rectangles.
No wonder it perfectly fit the rectangles into colorbars samples because it left the Colorbars image untouched.
Or what did I do wrong?

seems it not work with yv24
putting converttoyv12 before TextSub will make it work

edit: ok, seems AssRender and TextSub now are similar with ctest2

here are ctest3 https://www.solidfiles.com/v/Gv3mRXMyre3e5 done by corrects colors manually, it seems work fine in both, the ctest2 was done using old ctest (which also give similar output in TextSub) with aegisub resample resolution

The lesson: no one should use BT.601 with HD in last aegisub, and never trust or wait error report of what color formats filter can work with (vsfilter case with yv24) :D

[pinterf]

New release: ASSRender 0.35 (https://github.com/pinterf/assrender/releases)
This version seemed for me significantly quicker than the previous one.
### 0.35 (20210304)
* Windows MSVC: Update to libass v0.15
(git submodule update --init --recursive --remote)
For changes since v0.14 see https://github.com/libass/libass/blob/master/Changelog
* don't guess base on video resolution (realfinder)
if .ass file has no Matrix info then it should be treated as it "Rec601" to maintain compatibility
* Parameter 'colorspace' default value is no longer "guess"
* Add more color options: PC.709, PC.601, TV.fcc, PC.fcc, TV.240m, PC.240m, none.
"none" and "guess" implies "guess-by-resolution".
* Fix: possible crash on initializing phase (buffer overread, linux crashed, Windows was just lucky)

[real.finder]

thanks, I did update the wiki http://avisynth.nl/index.php/AssRender

[real.finder]

I did post this I did try to make this https://github.com/realfinder/AvsP-macros/blob/master/Bookmarks%20from%20Subtitle.py

it work but sometimes it not accurate, I already try random fix but I think there are something missing, maybe peoples who has knowledge in vsfilter or libass can explain how to correctly convert subtitle time to frames

in https://forum.doom9.org/showthread.php?t=163653

then after I did not get an answer I asked in irc.libera.chat/#libass in IRC and I get this answer "libass simply doesn't. it's given a time, and subtitles are time-based"

so I think the peoples who work on AssRender have the answer

edit: I get an answer, ceil(start timestamp in seconds * frames per second)

[tormento]

Is there a way to render ASS to a format suitable to create PGS?

I saw this (https://github.com/subelf/Spp2Pgs) project but there are no builds.

[kedautinh12]

Is there a way to render ASS to a format suitable to create PGS?

I saw this (https://github.com/subelf/Spp2Pgs) project but there are no builds.

I seen author was builds:
https://github.com/subelf/Spp2Pgs/releases

Btw, it's already support avs??

[cubicibo]

PunkGraphicStream and easySUP will do direct .ass to .sup.
avs2bdnxml will as well if you're fine using an avisynth script that renders your ASS file.
SubtitleEdit has an option to export to SUP, should work from ASS.

Anything else will need to be converted to BDNXML or other formats first then to SUP.

[mp3dom]

How these projects are really "BD compliant"? For example, the 4 MB decoding buffer limitation... is it even checked?
Normally, "official" SUP subtitles (created by Scenarist BD), cannot require more than 4 MB of buffer to be decoded but I think these "SUP" could be out of standard.
Avs2bdnxml have the advantage to export PNG+XML subtitles, and these are imported into Scenarist who check that everything is compliant and then encode to SUP. Exporting directly to SUP in this case could be a bit risky.

[cubicibo]

The 4 MB buffer only applies to displayed objects or the ones that will be displayed next frames. In fact it is not the bottleneck of the hardware SUP decoders. What I find to be the limits are the coded bandwidth (16 Mbps) and decoded bandwith (128 Mbps).

For example, your FSN release has fading staff credits aside of subtitles lines. When the fades happen, all objects are redrawn every frame. The instantaneous PGS bitrate is then 10~11 Mbps (~70% of capacity) at most. During the heaviest epoch you write 7.23 MiB of decoded object data to the buffer in ~13s. Decoded bandwidth is used between 10%~50%. Buffer is never full because on every acquisition, it is flushed.

The 4 MiB buffer is not the issue at all unless you attempt to draw 1920x1080 objects via PGS very often (128 Mbps -> can theoretically draw 1920x1080 images every 120 ms -> ~3 frames, or >6 frames on epoch start as the screen has to be "cleared"). What blows up is the coded buffer bandwidth.

/Salesman person: SUPer has a more advanced bandwidth and buffer checker function than avs2bdnxml. You can easily call it

from SUPer.render import is_compliant
from SUPer import SupStream
FILE = ...
FPS = ...
sup = SupStream(FILE)
epochs = [epoch for epoch in sup.epochs()]
print(is_compliant(epochs, FPS))

If the stream is not compliant (buffer overflow, bandwidth overflow), it will prints many warnings and "False". If compliant, it will just say "True". There is just one formula I am not certain about: the one linked to message "Data rate above decode rate". If you get this warning, you can proceed with caution and test on hardware first.

[mohamedh]

a slightly naive question but, since this plugin uses libass and not VSfilter. If all I need is to hard-code subtitles (and not using other filters), what would be the advantage of writing a script to hard-code subtitles with AssRender, instead of hard-coding the subs with ffmpeg directly with something like

ffmpeg -i video.mp4 -vf "ass=subtitle.ass" out.mp4

?

[Reel.Deel]

a slightly naive question but, since this plugin uses libass and not VSfilter. If all I need is to hard-code subtitles (and not using other filters), what would be the advantage of writing a script to hard-code subtitles with AssRender, instead of hard-coding the subs with ffmpeg directly with something like

ffmpeg -i video.mp4 -vf "ass=subtitle.ass" out.mp4

?

I don't think there is any advantage. Both use libass to render the subtitles. If you're not doing anything else to the video, use ffmpeg.

[Jamaika]

function LibavSource2(string path, int "atrack",
\ int "fpsnum", int "fpsden",
\ string "format", bool "cache")
{
atrack = Default(atrack, -1)
fpsnum = Default(fpsnum, 0)
fpsden = Default(fpsden, 1)
cache = Default(cache, true)

format = Default(format, "")

video = LWLibavVideoSource(path,
\ fpsnum=fpsnum, fpsden=fpsden, format=format,
\ cache=cache)
return (atrack==-2) ? video: AudioDub(video,
\ LWLibavAudioSource(path, stream_index=atrack, cache=cache))
}

LibavSource2("yuv420p.mp4",fpsnum=30000,fpsden=1001)
assrender("111.srt",colorspace="BT.709")

I don't know what I'm doing wrong.
FT_Stream_EnterFrame: invalid i/o; pos = 0x0, count = 148, size = 0x41
FT_Stream_ReadAt: invalid read; expected 128 bytes, got 65
get_win_string: Character 0x20 invalid in PS name string

https://github.com/pinterf/assrender/pull/47/files
https://www.sendspace.com/file/r8p5wb

[Seiya]

I made new test version: 0.36.0-dev.4 (https://github.com/seiya-dev/assrender/releases/latest)
### 0.36.0-dev.4 (20251205)
* Switch submodule build system to meson
* Update avisynth(plus) headers to v12
* Update libass to 0.17.4
* Unicode-safe file reading
* Add frame size parameters
* Add set_default_storage_size boolean
* Use frame properties if they available for "YCbCr Matrix: None"

[pinterf]

New release: assrender 0.36 (https://github.com/pinterf/assrender/releases/tag/0.36).

Big thanks to Seiya.

### 0.36.0 (20260122) (seiya-git)
* Binaries using AviSynth 3.7.5's lib, VS2022 MSVC 14.38 toolset
* Update build instructions
* Fix hinting
* Fix ass_set_storage_size not be called
* Switch submodule build system to meson
* Update avisynth(plus) headers to v12
* Update libass to 0.17.4
* Unicode-safe file reading
* Add frame size parameters
* Add set_default_storage_size boolean
* Use frame properties if they available for "YCbCr Matrix: None"
* Work with frame copy instead of just modifying it

[FranceBB]

Hi Ferenc, thanks for the new release.
Works just fine on Windows 11 Enterprise x64 :)
(unfortunately XP is out of the game and I'm using an older version there).

By the way, I can see from the changelog


use frame properties if they available


so I tested to see if it was also preserving them but it wasn't.


LWLibavVideoSource("830001.mp4")


https://images2.imgbox.com/6d/96/pSyHpy07_o.png



LWLibavVideoSource("830001.mp4")

AssRender("830001.eng.ass")


https://images2.imgbox.com/82/76/C17Gfnm9_o.png

are you planning to add support to copy frame properties over?

[pinterf]

Hi! Thanks for the test, did the previous release preserve them?
I guess, it did. Probably "Work with frame copy instead of just modifying it" make them disappear.
Reported the issue here: https://github.com/pinterf/assrender/issues/52

[pinterf]

New release: assrender 0.37.
https://github.com/pinterf/assrender/releases/tag/0.37

## Change log

### 0.37.0 (20260203)
* add MSBUILD hint to build_msvc helper
* fix #52: regression: frame properties were not passed
(Revert "Work with frame copy instead of just modifying it")

### 0.36.0 (20260122) (seiya-git)
* Binaries using AviSynth 3.7.5's lib, VS2022 MSVC 14.38 toolset
* Update build instructions
* Fix hinting
* Fix ass_set_storage_size not be called
* Switch submodule build system to meson
* Update avisynth(plus) headers to v12
* Update libass to 0.17.4
* Unicode-safe file reading
* Add frame size parameters
* Add set_default_storage_size boolean
* Use frame properties if they available for "YCbCr Matrix: None"
* Work with frame copy instead of just modifying it

[FranceBB]

New release: assrender 0.37.
https://github.com/pinterf/assrender/releases/tag/0.37


Thanks for the new version, Master Ferenc. It works like a charm and frame properties are now correctly preserved. :)

https://images2.imgbox.com/46/f2/WRv49nKz_o.png