AssRender: inappropriately named libass-based subtitles renderer

[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