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.