AssRender: inappropriately named libass-based subtitles renderer - Page 3

lachs0r · 22nd September 2011, 19:12

Code:

    * 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

lachs0r · 20th April 2012, 08:51

Code:

* 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

sneaker_ger · 20th April 2012, 15:08

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 · 20th April 2012, 17:47

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 · 20th April 2012, 17:59

Quote:

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

Quote:

Originally Posted by lachs0r

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 · 20th April 2012, 23:13

Quote:

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

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 · 21st April 2012, 21:05

Quote:

Originally Posted by sneaker_ger

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.

Quote:

Originally Posted by natt

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 · 22nd April 2012, 11:14

Quote:

Originally Posted by lachs0r

…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.

Quote:

Originally Posted by lachs0r

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 · 23rd April 2012, 12:04

I did test that. Worked fine here.

lachs0r · 24th April 2012, 01:17

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 · 13th October 2014, 16:15

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 · 13th October 2014, 16:56

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 · 13th October 2014, 19:43

Quote:

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

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 · 27th April 2020, 21:02

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 · 15th February 2021, 10:22

Quote:

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

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 · 15th February 2021, 13:54

Quote:

Originally Posted by real.finder

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 · 15th February 2021, 19:45

Quote:

Originally Posted by pinterf

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

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 · 15th February 2021, 20:38

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for

Code:

avisynth_c_plugin_init@4 or avisynth_c_plugin_init

Avisynth+ is looking for

Code:

_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...?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 · 15th February 2021, 20:41

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for

Code:

avisynth_c_plugin_init@4 or avisynth_c_plugin_init

Avisynth+ is looking for

Code:

_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...?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:

Code:

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 · 15th February 2021, 20:44

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?

22nd September 2011, 19:12	#41 \| Link
lachs0r eccentric Join Date: Jan 2011 Posts: 24	Code: * 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

13th October 2014, 16:15	#51 \| Link
real.finder Registered User Join Date: Jan 2012 Location: Mesopotamia Posts: 2,587	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 __________________ See My Avisynth Stuff

15th February 2021, 20:38	#58 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,314	It must be because of 32 bit 'decorated' names: Avisynth 2.6 is looking for Code: avisynth_c_plugin_init@4 or avisynth_c_plugin_init Avisynth+ is looking for Code: _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...?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. __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

15th February 2021, 20:41	#59 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,314	It must be because of 32 bit 'decorated' names: Avisynth 2.6 is looking for Code: avisynth_c_plugin_init@4 or avisynth_c_plugin_init Avisynth+ is looking for Code: _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...?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: Code: 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. __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

15th February 2021, 20:44	#60 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,314	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? __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

20th April 2012, 15:08	#43 \| Link
sneaker_ger Registered User Join Date: Dec 2002 Posts: 5,565	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.

20th April 2012, 17:47	#44 \| Link
lachs0r eccentric Join Date: Jan 2011 Posts: 24	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.

23rd April 2012, 12:04	#49 \| Link
lachs0r eccentric Join Date: Jan 2011 Posts: 24	I did test that. Worked fine here.

24th April 2012, 01:17	#50 \| Link
lachs0r eccentric Join Date: Jan 2011 Posts: 24	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.

13th October 2014, 16:56	#52 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	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.

27th April 2020, 21:02	#54 \| Link
Reel.Deel Registered User Join Date: Mar 2012 Location: Texas Posts: 1,664	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

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode