libass/libass

libass is a portable subtitle renderer for the ASS/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format.

libass

libass is a portable subtitle renderer for the ASS/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format. It is mostly compatible with VSFilter.

Get it

See GitHub releases for the latest release 0.17.1 (released 2023-02-26). See the changelog for a detailed list of changes.

Source code is available from our GitHub repository.

Contact

Please use the issue tracker to report bugs or feature requests.

We have an IRC channel, too. Talk to us on irc.libera.chat/#libass. Note that we cannot be online all the time and we cannot answer IRC questions if you leave the channel. Even if you do not get an immediate response, keep your IRC client open, and we will eventually get back to you.

Building

libass offers two build systems to choose from: Autotools and Meson.

Autotools is preferred for development since it integrates with our testing infrastructure and is feature-complete on all platforms supported by Autotools.
If you are packaging libass for distribution, Autotools is recommended; when packaging for Windows Meson should work equally well.

Meson lacks integration with testing infrastructure, but works otherwise well on Windows. It is suited for static-only builds on any platform well supported by Meson and as a Meson subproject. Notably, Meson supports MSVC and generation of VS project files.

Related Links

The following projects/companies use libass:

• MPlayer
• mplayer2
• mpv
• VLC
• GStreamer (assrender plugin)
• FFmpeg
  • Libav (unmaintained)
• Aegisub
• Kodi (XBMC)
• avidemux
• PunkGraphicsStream (BD subtitle encoder)
• HandBrake
• MX Player
• QMPlay2
• SubtitlesOctopus (JavaScript ASS via wasm libass)
  • Crunchyroll uses SubtitlesOctopus
• AssRender for Avisynth(+)

Information about the ASS format:

• ASS format overview
• ASS override tags (Aegisub manual)
• VSFilter source code (Guliverkli2)

Other ASS/SSA implementations:

• VSFilter:
  • xy-VSFilter/XySubFilter
    • pfmod
  • VSFilter in MPC-HC
  • VSFilterMod (with custom format extensions)
    • sorayuki fork with some bugfixes
  • Threaded VSFilter (defunct)
  • VSFilter in Guliverkli2 (defunct, subsumed by all of the above)
  • VSFilter in guliverkli (defunct, forked as Guliverkli2)
• ffdshow (defunct)
• Perian (defunct)
• asa (defunct)
• libjass (defunct)
• ASS.js

libass's Issues

Return ASS_Image list with all shadows below all borders and fills

Should be a pretty simple fix; I'll handle it.

Parser blows up with {\p1<x>}{<y>} as opposed to {\p1<x><y>}

And we completely fail to parse the drawing.
Demo file here: https://gist.github.com/10546097
s/}{// gives a working file.

cache grows too large

This eats memory at the rate of 1 or 2 MB per second: mpv /dev/zero --demuxer=rawvideo --osd-fractions --osd-level=3

It didn't happen with the previous libass release.

One line vanishes when another shows up

http://tny.cz/2925aa29

Dialogue: 5,0:02:37.99,0:02:38.09,OP-rom,OP,0,0,0,fx,{\clip(m 163 32 l 47 32 47 36 163 36 163 40 l 47 40 47 44 163 44 163 48 l 47 48 47 52 163 52 163 56 l 47 56 47 60 163 60 163 64 l 47 64 47 68 163 68 163 72 l 47 72 47 76 163 76 163 80 )\move(47,32,47,74)\bord5\shad2\4c&H000000&}all right
Dialogue: 6,0:02:37.99,0:02:38.09,OP-rom,OP,0,0,0,fx,{\clip(m 163 32 l 47 32 47 36 163 36 163 40 l 47 40 47 44 163 44 163 48 l 47 48 47 52 163 52 163 56 l 47 56 47 60 163 60 163 64 l 47 64 47 68 163 68 163 72 l 47 72 47 76 163 76 163 80 )\move(47,32,47,74)\bord1.5\shad2\3c&H858585&}all right
Dialogue: 5,0:02:37.99,0:02:38.09,OP-eng,OP,0,0,0,fx,{\clip(m 170 646 l 47 646 47 650 170 650 170 654 l 47 654 47 658 170 658 170 662 l 47 662 47 666 170 666 170 670 l 47 670 47 674 170 674 170 678 l 47 678 47 682 170 682 170 686 l 47 686 47 690 170 690 170 694 )\move(47,688,47,730)\bord5\shad2\4c&H000000&}All right!
Dialogue: 6,0:02:37.99,0:02:38.09,OP-eng,OP,0,0,0,fx,{\clip(m 170 646 l 47 646 47 650 170 650 170 654 l 47 654 47 658 170 658 170 662 l 47 662 47 666 170 666 170 670 l 47 670 47 674 170 674 170 678 l 47 678 47 682 170 682 170 686 l 47 686 47 690 170 690 170 694 )\move(47,688,47,730)\bord1.5\shad2\3c&H858585&}All right!
Dialogue: 5,0:02:37.99,0:02:38.09,OP-rom,OP,0,0,0,fx,{\clip(m 47 32 )\move(47,32,47,32)\c&H858585&}
Dialogue: 5,0:02:39.99,0:02:40.09,OP-rom,OP,0,0,0,fx,{\clip(m 47 32 )\move(47,32,47,32)\bord5\shad2\4c&H000000&}
Dialogue: 6,0:02:39.99,0:02:40.09,OP-rom,OP,0,0,0,fx,{\clip(m 47 32 )\move(47,32,47,32)\bord1.5\shad2\3c&H858585&}

When the above is up (nothing renders because the lines are all derp), the mask lines vanish (unanimated reports the OP-rom line shouldn't be there, but it has no effect in VSFilter). The mask is on layer 0 and should not be affected.

Positioning/sizing issue?

libass:
http://puu.sh/6raM4.png
VSFilter:
http://puu.sh/6raBH.png

http://privatepaste.com/31e594e8b6
http://puu.sh/6rb74.ttf

Font not rendered properly

the font linowrite (http://www.dafont.com/linowrite.font) is not rendered correctly, more precisely the texture on the font is omitted. i tested this with xy-vsfilter, aegisub (with libass, build r7477 from http://plorkyeran.com/aegisub/) and VLC 2.0.8, where it worked. whereas an up-to-date mpv with up-to-date libass, aegisub (r7993) and VLC (2.1.4) has this problem.

following two example screens of the issue. please ignore the colour difference.

how it should look like (VLC 2.0.8)

how it looks like on mpv (git master) with libass (git master), aegisub (r7993) and VLC (2.1.4)

a test file can be found here https://dl.dropboxusercontent.com/u/68772824/font/test.mkv

Render lines to bitmap all at once, instead of per-character

It seems that this is a well-known improvement that could be made to libass, and that it will help fix some issues and improve performance, but that it'll require a fair bit of work.
This issue thread can track progress on implementing this change.

negative \fsp+rotation bug

Style: Signs,Arial,40,&H00FFFFFF,&H000019FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1


Dialogue: 1,0:09:32.63,0:09:35.63,Signs,,0,0,0,,{\pos(640,106)\blur0.5\fnDFGKKaiSho-W9\fs58.5\shad3\b1\c&HF5FFFD&\shad3.7\4c&H732F13&\org(640,860)\frz27.172\fsp-35.35}D{\frz24.485\fsp-24.04}o{\frz22.657\fsp-31.75} {\frz20.243\fsp-36.35}Y{\frz17.480\fsp-30.24}o{\frz15.181\fsp-25.64}u{\frz13.232\fsp-31.72} {\frz10.820\fsp-35.69}R{\frz8.107\fsp-38.00}e{\frz5.218\fsp-38.00}m{\frz2.329\fsp-38.00}e{\frz359.441\fsp-41.43}m{\frz356.291\fsp-30.80}b{\frz353.949\fsp-26.52}e{\frz351.933\fsp-22.55}r{\frz350.218\fsp-20.41} {\frz348.667\fsp-28.23}t{\frz346.520\fsp-31.23}h{\frz344.146\fsp-23.41}e{\frz342.366\fsp-28.49} {\frz340.200\fsp-26.80}F{\frz338.162\fsp-20.87}i{\frz336.576\fsp-25.73}r{\frz334.620\fsp-23.58}s{\frz332.828\fsp0.00}t
Dialogue: 1,0:09:32.63,0:09:35.63,Signs,,0,0,0,,{\pos(640,167)\blur0.5\fnDFGKKaiSho-W9\fs58.5\shad3\b1\c&HF5FFFD&\shad3.7\4c&H732F13&\org(640,860)\frz28.588\fsp-29.72}T{\frz26.129\fsp-32.34}i{\frz23.454\fsp-38.00}m{\frz20.311\fsp-23.41}e{\frz18.375\fsp-20.41} {\frz16.687\fsp-28.23}t{\frz14.351\fsp-31.23}h{\frz11.768\fsp-23.41}e{\frz9.831\fsp-33.70} {\c&H57FFFF&\fs66.69\frz7.044\fsp-35.52\alpha&HFF&}D{\fs52.65\frz4.106\fsp-20.06}r{\fs62.01\frz2.446\fsp-22.63}i{\fs49.14\frz0.575\fsp-34.48}n{\fs70.2\frz357.723\fsp-32.02}k{\frz355.074\fsp-33.34} {\alpha&H00&\c&HF5FFFD&\fs58.5\frz352.316\fsp-36.01}T{\frz349.338\fsp-28.64}o{\frz346.968\fsp-31.30}o{\frz344.380\fsp-26.70}k{\frz342.171\fsp-31.75} {\frz339.545\fsp-36.35}Y{\frz336.538\fsp-30.24}o{\frz334.037\fsp-31.73}u{\frz331.412\fsp0.00}?

Add Windows GDI or DirectWrite fontselect

After the general internal fontselect changes and CoreText provider are ready, we should look into a Windows provider. @grigorig's fonts branch has at least some amount of work done on a GDI provider (not sure how far along it is?), but we might want to look at DirectWrite instead, since WinXP is out of support anyway.

Corruption since bitmap combining

Script:
http://sprunge.us/fLPc

Current libass:
http://i.imgur.com/77GepoC.png

Libass before 5dd56af:
http://i.imgur.com/LkhIkpc.jpg

xysubfilter:
http://i.imgur.com/osZQDtZ.png

"CombiNumerals" font not shown properly

Tested in VLC and mpv on OSX and VLC on Windows.
Style: c-numbers,CombiNumerals,45,&H00000000,&H000000FF,&H00000000,&H00F5F5F5,0,0,0,0,100,100,0,0,1,0,0,4,10,10,10,1

Dialogue: 3,0:10:40.07,0:10:40.57,c-numbers,b,0,0,0,eptitle-out,{\bord3\blur0.8\xshad1\yshad-1\fscx165\fscy165\3c&HA65029&\c&HA65029&\pos(114,110)}q
Dialogue: 4,0:10:40.07,0:10:40.57,c-numbers,b,0,0,0,eptitle-out,{\bord0\blur0.8\c&HFFFFFF&\fscx165\fscy165\3c&HA65029&\pos(114,110)}q

Dialogue: 3,0:10:40.07,0:10:40.57,c-numbers,p,0,0,0,eptitle-out,{\bord3\blur0.8\xshad1\yshad-1\4c&H3C3C3C&\fscx165\fscy165\pos(114,631)\3c&H3E1034&\c&H3E1034&}w
Dialogue: 4,0:10:40.07,0:10:40.57,c-numbers,p,0,0,0,eptitle-out,{\bord0\blur0.8\c&H4F4345&\4c&H3C3C3C&\fscx165\fscy165\pos(114,631)\3c&H3E1034&}w

fontselect TODO

This meta bug tracks current issues of the libass/fonts branch.

• Handle duplicate fonts with match API
• Improve fallback with a separate API
• Handle platform-specific font aliases, if applicable
• Choose sensible faces for generic families (sans-serif, serif, monospace, ...)
• Don't sort the font list directly (unneeded memcpy)
• Check compatibility with VSFilter in unusual cases
• Test coretext backend (bugs and compatibility)
• Think about priority of embedded fonts vs other/default providers

Fix hinting

Github is too dumb to allow me to create a pull request from a repo not marked as "fork", so here's a manual pull request:

https://github.com/wm4/libass/commit/05eb520f431e73c2ad19a8e0261f35d396545cf9

I didn't test it too much (especially I didn't confirm it hints correctly), but tests look promising. Normalizing the scale to font size seems to help a lot with idiotic scripts that used to break libass rendering before hinting was broken.

Positioning/sizing issue… hell if I know

Dialogue: 1,0:00:00.00,0:01:09.04,omelette_01:07,,0,0,0,,{\fsp4\blur1\bord0\fnGoodDog Plain\frz349.2\c&H6370F3&\4c&H6571F9&\fscx192\fscy211\pos(623,557)}C{*\frz352.297}u{*\frz354.594}r{*\frz356.89}s{*\frz359.187}e{\s1\frz1.484}
Dialogue: 0,0:00:00.00,0:01:09.04,omelette_01:07,,0,0,0,,{\blur0.6\bord0\fnGoodDog Plain\frz349.2\fscx253\fscy255\pos(620,548)\c&H1C22C7&\4c&H6571F9&}C{*\frz352.297}u{*\frz354.594}r{*\frz356.89}s{*\frz359.187}e{\s1\frz1.484}

libass:

xy-vsfilter:

\h fallback messes up positioning

libass:

xy-vs:

File is 9AD4509C

Dialogue: 0,0:03:58.53,0:04:02.02,Sign-SaberWork,,0,0,0,,{\fad(0,745)\frz2.5\fax0.05\fscx81\fscy80\1a&H00&\4c&HFFFEFF\3a&H00&\bord4\fsp15\b1\blur1\c&HEFB94C&\pos(325,767)\3c&HEFB94C&}Saber
Dialogue: 1,0:03:58.53,0:04:02.32,Sign-SaberWork2,,0,0,0,,{\fad(0,745)\frz2.5\fax0.05\fscx96\fscy92\1a&H00&\b1\blur0.5\bord6\pos(444,835)\c&HFFFFFF&\3c&HEFB94C&}Saber{\alpha&HFF&}\h\h\h\h\h\h\h\N{\alpha&H00&}at Work
Dialogue: 2,0:03:58.53,0:04:02.32,Sign-SaberWork2,,0,0,0,,{\fad(0,745)\frz2.5\fax0.025\fscx94\fscy91\1a&HFF&\b1\blur1\bord2\pos(444,835)\c&HFFFFFF&\3c&HFDE882&}Sa{\alpha&H2F&\1a&HFF&}be{\alpha&H50&\1a&HFF&}r{\alpha&HFF&}\h\h\h\h\h\h\h\N{\alpha&H00&\1a&HFF&}at {\alpha&H1F&\1a&HFF&}Wo{\alpha&H40&\1a&HFF&\bord0.5\3c&HFEF7C2&}rk

Positioning issue

xy-vs:

libass:
(EDIT: Screenshot inactivity-pruned)

DDBECA76

Dialogue: 0,0:17:10.75,0:17:16.76,tcn - signs - database,,0,0,0,,{\blur0.6\an9\fs18\fscx95\fscy95\pos(1194.667,147.889)\alpha&H10&}\NJapan Server \NLeague of Freedom Cities\NEastal: Maihama
Dialogue: 0,0:17:10.75,0:17:16.76,tcn - signs - database,,0,0,0,,{\blur0.6\an9\fs18\fscx95\fscy95\pos(1194.777,221.999)\alpha&H10&}No Monsters, No PVP \NSkill Use Permitted
Dialogue: 0,0:17:10.75,0:17:16.76,tcn - signs - database,,0,0,0,,{\blur0.6\an9\fs18\fscx95\fscy95\pos(1194.777,322.999)\alpha&H10&}No Entry Restrictions
Dialogue: 0,0:17:10.75,0:17:16.76,tcn - signs - database,,0,0,0,,{\blur0.6\an5\fs18\pos(1106.777,373.999)\fscx95\fscy95\alpha&H10&}Events: \NThe Goblin King's Return
Dialogue: 1,0:17:10.75,0:17:16.76,tcn - signs - database,,0,0,0,,{\blur0.6\an5\fscx55\fscy55\pos(1066.778,49.333)\alpha&H15&}Cinderella Castle

The line starting with "Japan Server" is too low.

Superfluous linebreaks in 90-degree oriented text

(This is essentially a repost of Issue 116 on the Google Code tracker)

What steps will reproduce the problem?

1. View any video file using the attached .ass file (preferably one in 16:9, to match the shape of original video)
2. Pay close attention to the kanji on the left-hand-side

What is the expected output? What do you see instead?

• Expected: each vertical line to be one line only (see this screenshot, from MPC-HC)
• Instead: some lines spill strangely onto multiple lines, and clip offscreen (see this screenshot, from mpv)

What version of the product are you using? On what operating system?

• libass 0.10.2 (and git)
• mpv 0.3.4 (and git)
• Arch Linux x86_64

Please provide any additional information below. If relevant, please attach
the ASS/SSA script file and any fonts used in it.
I've uploaded the .ass file and the full video file to my Dropbox account.

Implement fast floating-point(?) Gaussian blur using SIMD

Use xy-vsfilter's SSE2 implementation and Intel's AVX implementation when applicable. Write a NEON implementation for ARM, and possibly an SSE4-or-such implementation (but probably not :|). Probably can wait until after #5 is done.

Cacheing thing, maybe?

[D84BC791]
http://puu.sh/8p61R.ttf

Style: Mr. T(ea),Painted,60,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1

Dialogue: 2,0:08:39.70,0:08:41.33,Mr. T(ea),,0,0,0,,{\alpha&HFF&\shad1.2\blur1\fnbrushtipTravis_tcn'd\b1\c&H1B3052&\4c&H7EB7F6&\fscx101\fscy101\pos(1115.17,-5.74)\4a&H00&}Amau{\fsp-2.8}f{\fsp\c&H3F505F&}a{*\c&H3F4F5D&\fnPainted}-{*\alpha&H00&\fnbrushtipTravis_tcn'd\c&H192F53&}a{\c&H192F53&}n
Dialogue: 1,0:08:39.70,0:08:41.33,Mr. T(ea),,0,0,0,,{\alpha&HFF&\shad1.2\blur1\fnbrushtipTravis_tcn'd\b1\c&H1B3052&\4c&H7EB7F6&\fscx101\fscy101\pos(1120.97,-1.74)\4a&H00&}Amau{\fsp-2.8}f{\fsp\c&H3F505F&}a{*\c&H1B3052&\fnPainted\alpha&H00&}-{*\alpha&HFF&\fnbrushtipTravis_tcn'd\c&H404F5B&}a{\c&H414F59&}n
Dialogue: 1,0:08:39.70,0:08:41.33,Mr. T(ea),,0,0,0,,{\shad1.2\blur1\fnbrushtipTravis_tcn'd\b1\c&H192F53&\4c&H7EB7F6&\fscx101\fscy101\pos(1117.97,-5.74)}Amau{\fsp-2.8}f{\fsp\c&H192F53&}a{*\c&H3F4F5D&\fnPainted\alpha&HFF&}-{*\fnbrushtipTravis_tcn'd\c&H192F53&}a{\c&H414F59&}n

Support float values in drawings

 <reanimated> rcombs \clip(m 479.34 427.13 l 514.34 375.13 558.34 435.13)
 <reanimated> seems like libass rounds the numbers
 <reanimated> while xy-vsfilter doesn't
 <reanimated> sadly, regular vsfilter just makes the whole text disappear
 <reanimated> so i'm not sure if we should aim to have this as "standard"
 <reanimated> but it seems like a fairly simple thing

Weird positioning/corruption with Haswell

From mpv-player/mpv#530. Some subtitles are rendered incorrectly on my Haswell laptop:

We figured it's probably a libass bug, since there are issues with all the video renderers and it even occurs when the output is written to a file with --vo=image. Only subs with this styling are affected. The other subs in the show work perfectly.

This issue only occurs on my Haswell laptop (i5-4200U) with a recent x86_64 build of libass. I can't reproduce the issue on my Ivy Bridge desktop (i5-3570K) or with i686 builds of mpv. All testing has been done on Windows 8.1. 31bc8ba looks like the first broken commit. 5dd56af doesn't seem affected. Git master with --disable-asm doesn't seem affected either.

@11rcombs suggested I replace int avx2 = has_avx2(); with int avx2 = 0; in ass_renderer_init, but the issue still appears.

Baseline issue with tall drawings?

https://www.dropbox.com/s/76sribbafuogdhe/Screenshot%202014-01-02%2002.23.54.png
Dialogue: 0,0:05:39.28,0:05:39.32,EpTitle,Sign 0540,0,0,0,,{\pos(280,420)\blur2}The Masters of the Shipping
https://www.dropbox.com/s/dr64u43zz8s2hd9/Screenshot%202014-01-02%2002.24.12.png
Dialogue: 0,0:05:39.32,0:05:39.36,EpTitle,Sign 0540,0,0,0,,{\pos(280,420)\blur2}The Masters of the Shipping {\p1\pbo10\alpha&H00&}m 2 0 l 2 42 142.5625 42 142.5625 0{\p0}
The text baseline drops in the second image, apparently in response to the drawing and the baseline offset it has. I'm told this doesn't happen in xy-vsfilter. Should drawing segments be completely ignored when calculating baseline position?

Incorrect placement in drawings (No Game No Life)

Dialogue: 0,0:22:49.75,0:22:55.45,ngnlop1-1r,,0,0,0,,{\fad(0,250)\clip(607,5,634,95)\3c&HFFFFFF&\t(25,349,\3c&HC645E7&\clip(280,5,1008,103))}{\blur3}umarenaoshita inochi de tanoshimu sa
Dialogue: 0,0:22:49.75,0:22:55.45,ngnlop1-1t,,0,0,0,,{\fad(250,250)}{\blur3}I'm enjoying my new life to the fullest
Dialogue: 2,0:22:49.76,0:22:50.05,ngnlop1-1r,,0,0,0,,{\fad(250,0)\move(594,25,294,25,25,317)}{\blur3\p1\fscx320\fscy370}m 0 0.1 l 5 0.1 5 0.7 0.7 0.7 0.7 7 0.1 7{\p0}
Dialogue: 2,0:22:49.76,0:22:50.05,ngnlop1-1r,,0,0,0,,{\fad(250,0)\move(650,25,984,25,25,317)}{\blur3\p1\pbo14\fscx265\fscy340}m -0.7 7 l -0.7 6.3 4.5 6.3 4.5 0 5.3 0 5.3 7{\p0}
Dialogue: 2,0:22:50.05,0:22:50.64,ngnlop1-1r,,0,0,0,,{\fad(0,300)\move(294,25,200,25,28,700)}{\blur3\p1\fscx320\fscy370}m 0 0.1 l 5 0.1 5 0.7 0.7 0.7 0.7 7 0.1 7{\p0}
Dialogue: 2,0:22:50.05,0:22:50.64,ngnlop1-1r,,0,0,0,,{\fad(0,300)\move(984,25,1084,25,28,700)}{\blur3\p1\pbo14\fscx265\fscy340}m -0.7 7 l -0.7 6.3 4.5 6.3 4.5 0 5.3 0 5.3 7{\p0}

This is meant to display two Japanese-style quote brackets around some text, which expand outwards. The right bracket is positioned correctly, but the left one ends up too low. Screenshots below (different frames, but you get the gist):

Seams visible in blocks

Styles for backgrounds are variations on:
Style: c-blue-light-up,Noucome,56,&H64E8BD8D,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0,0,5,15,15,15,1
Style: c-blue-light-down,Noucome,56,&H74AD6632,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0,0,5,15,15,15,1
(only colors and name change)

Lines include:
Dialogue: 1,0:10:40.07,0:10:40.57,c-blue-light-down,b,0,0,0,eptitle-out,{\blur0.8\pos(640,103)\fscx150\fscy150}QGGGGGFFDDDO
Dialogue: 1,0:10:40.07,0:10:40.57,c-blue-light-down,b,0,0,0,eptitle-out,{\yshad-2.8\blur0.8\c&HF7C150&\1a&H00&\pos(640,103)\fscx150\fscy150\4c&HC6663C&}qtttettttttteeep
Dialogue: 1,0:10:40.07,0:10:40.57,c-blue-light-down,b,0,0,0,eptitle-out,{\yshad2.8\blur0.8\c&HF7C150&\1a&H00&\pos(640,103)\fscx150\fscy150\4c&HD2793B&}qtttettttttteeep

Provide a way to render ahead-of-time

Allow the consumer to pass in times and render subtitles ahead-of-time, then retrieve the rendered bitmaps. This could be done by either modifying the library to have the consumer always need to free/dereference already-shown bitmaps manually (complex), or by forcing the consumer to duplicate the bitmaps (slow), or by simply letting the consumer instruct libass to cache an event's bitmaps ahead-of-time without actually returning them (you can almost do this already, but it's unoptimized and messy and this wouldn't be optimal for performance).

Keeping this thread-safe will be a bundle of laughs.

Carnival Phantasm font matching issue

https://gist.github.com/8893203
Wrong font (too light) variant shows up in dialogue; I'm told it's a GDI bug we're not reproducing.
9AD4509C

Style: Default,Profile,68,&H00FFFFFF,&HC059280A,&H0059280A,&H803B1B07,0,0,0,0,95,100,0,0,1,3,1.5,2,120,120,45,1

Dialogue: 5,0:00:04.15,0:00:05.56,Default,,0,0,0,,What? Did you buy that?

ar was TS on this show:

 <__ar> so that font selection issue
 <__ar> might be just something stupid.
 <__ar> profile-medium and profile-regular
 <__ar> both have weights set to 500
 <__ar> and gdi selects Profile-Medium
 <__ar> but only exposes Profile (family name)
 <__ar> freetype or fontconfig or w/e
 <__ar> selects Profile-Regular
 <__ar> now i believe Regular should be the correct one to choose
 <__ar> but if i had to take a wild guess
 <__ar> GDI selects Medium because M < R
 <__ar> lol

Corrected version of script (uses PostScript name); works in both renderers:
https://www.dropbox.com/s/2trznfyzvfmag05/cp08-1080.ass

\h rendered as "character not found" box in certain fonts without HarfBuzz

Looks like a missing nbsp character to me, but it should probably be replaced with a regular space.
Latest git master. Harfbuzz is disabled. No shaping hints set.

Proposal for new RGBA output API

There are a few reasons why we'd want this:

1. Downstreams often to this manually, e.g. grouping ASS_Images in order to upload them at once in one step, and similar.
2. We might switch to RGBA compositing internally, and the current API can't output that.
3. We might need it for similar reasons if we want to add fancy features like real gradients.

It might make a nice simplification too, because ASS_Image is really a bit obscure.

Here's a suggestion what the API could look like. It would (for now) exist in parallel to ass_render_frame().

typedef enum {
    /**
     * Each pixel is an uint32_t. Each color component takes 8 bits.
     * Bits 0-7: blue
     * Bits 8-15: green
     * Bits 16-23: red
     * Bits 24-31: alpha (0 means transparent, 255 opaque)
     * The alpha is premultiplied, which means the RGB values have already
     * been multiplied with the alpha. This means the condition
     * r <= alpha && g <= alpha && b <= alpha holds true.
     */
    ASS_RGBA_PREMULTIPLIED = 1,
} ASS_FrameFormat;

typedef struct ASS_Rect {
    int x, y, w, h;
};

typedef struct ASS_Frame {
    ASS_FrameFormat format;     // Format of the pixels referenced by bitmap
    void *bitmap;               // Points to the top/left pixel
    size_t stride;              // Line size in bytes (xxx: maybe explain better)
    int w, h;                   // same as ass_set_frame_size()
    int change_detect;          // same as ass_render_frame() change flag
    // A list of rectangles on the bitmap that contain non-transparent
    // pixel data. The rectangles never overlap, which means you can use this
    // to accelerate rendering or texture upload. The number of rectangles
    // is limited by ass_set_max_dirty_rects(). If the number is too small,
    // some rectangles will be coalesced to reach the limit.
    ASS_Rect *dirty_rects;
    int num_dirty_rects;
} ASS_Frame;

/**
 * Set the format of the frame that should be rendered with ass_render_frame2().
 */
int ass_set_frame_format(ASS_Renderer *priv, ASS_FrameFormat format);

/**
 * Set the maximum number of dirty rectangles ASS_Frame should have set.
 */
int ass_set_max_dirty_rects(ASS_Renderer *priv, int max);

/**
 * Set whether regions not covered by dirty rects in ASS_Frame should be cleared.
 * (You can switch it off as a minor possible optimization.)
 */
void ass_set_clear_dirty(ASS_Renderer *priv, int clear);

ASS_Frame *ass_render_frame2(ASS_Renderer *priv, ASS_Track *track,
                             long long now);

Note that I chose to make the rendering result one big bitmap (ASS_Frame does not form a list like ASS_Image). In order to avoid rendering transparent areas, a list of non-transparent regions (dirty rects) is returned.

another shaper issues in arabic

hi

using last mpv in windows (with HarfBuzz)

libass

libass with the Pointing

vsfilter

---

libass

vsfilter

wrong word order because of underline code

---

video sample http://www.solidfiles.com/d/9287427ae4/[Devil-Fansub]_Hyouka_-_11.mkv

sub + font http://www.solidfiles.com/d/1c8cb1aace/sub_%2B_font.rar

thanks

Handle malloc errors properly

libass is full of malloc and calloc calls without checks for NULL being returned. We should have a designated behavior for that kind of error, such as aborting rendering the frame and logging the OOM, rather than crashing a few lines later on dereferencing a NULL pointer.

Add limits.h to ass_utils.c

I just cross compiled this package for Android and had to work around
a little issue about 'SIZE_MAX' not being declared in ass_utils.c

adding <limits.h> as an include solved the problem for me.

ass_library_version is not exported

http://code.google.com/p/libass/issues/detail?id=117

Match VSFilter behavior by introducing rounding error for position at glyph run boundaries

VSFilter rounds off position values to either pixels or ⅛-pixels (not sure which?) at glyph run boundaries. We don't, which creates some incompatibilities when scripts try to make up for the difference by adding \fscx or similar to other layers. In some cases (like heavy kara), it can result in a shift by multiple px due to the (lack of) accumulated error. We may be able to replicate this behavior by detecting glyph runs slightly earlier, then converting positions to storage pixels, simulating the rounding, then converting back.

Font sizing issue (Not sure of details?)

[Script Info]
; Script generated by Aegisub r7900
; http://www.aegisub.org/
Title: Monogatari Series Second Season 22
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: TV.709
PlayResX: 1280
PlayResY: 720
Last Style Storage: Default
Aegisub Scroll Position: 222
Aegisub Active Line: 227
Aegisub Video Zoom Percent: 1.000000
Audio URI: monogatari22_premux.mkv
Keyframes File: monogatari22_premux_keyframes.log
Video File: monogatari22_premux.mkv
Aegisub Video Aspect Ratio: c1.777778
Aegisub Video Position: 31279

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Montara  Gothic,54,&H00FFFFFF,&H000019FF,&H1E000000,&H96000000,0,0,0,0,100,100,0,0,1,2.4,0,2,90,90,30,1
Style: op,Arial,44,&H0000EFE7,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,3.2,0,2,10,10,30,1
Style: op-modern,Arial,44,&H00F8FBFA,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0,0,2,10,10,30,1
Style: ED3,NewBaskerville,50,&H00FFFFFF,&H000019FF,&H00643BB6,&H00000000,0,0,0,0,100,100,0,0,1,2,0,3,25,25,10,1
Style: Monotitle,Reswysokr,60,&H00FFFFFF,&H000019FF,&H00000000,&H00000000,0,0,0,0,100,110,0,0,1,0,0,5,10,10,10,1
Style: Blogemonogatari,Iwata Mincho Pro-Madoka L,40,&H00FFFFFF,&H000019FF,&H00000000,&H96000000,0,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1
Style: centugatari,CenturyOldStyle-Light,36,&H00000000,&H000019FF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1
Style: Black and Red,Iwata Mincho Old Pro-Fate B,40,&H00FFFFFF,&H000019FF,&H00000000,&H96000000,0,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1
Style: Naoetsu,LHF Scriptana,45,&H00467A96,&H000019FF,&H00000000,&H52192225,-1,0,0,0,100,100,0,0,1,0,1.2,5,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:20:32.54,Naoetsu,,0,0,0,,{\blur2\shad0\c&H29748C&\fscx128\fscy166\pos(571,198)\alpha&HC0&}Shrine\N{\c&H3E8CA1&}of\N{\c&H489DB8&}the\N{\c&H51A9C3&}Polar\N{\c&H40ACC3&}Snake
Dialogue: 1,0:00:00.00,0:20:32.54,Naoetsu,,0,0,0,,{\blur0.8\shad0\c&H29748C&\fscx128\fscy166\pos(571,198)}Shrine\N{\c&H3E8CA1&}of\N{\c&H489DB8&}the\N{\c&H51A9C3&}Polar\N{\c&H40ACC3&}Snake

vs
Font: https://dl.dropboxusercontent.com/u/46348978/LHF_Scriptana.ttf
I can't figure out what's going on here :/

Alpha tag parsing: \1aH&

Dialogue: 0,0:02:33.00,0:02:37.92,Signs,,0,0,0,,{\bord7\blur8\fs73\shad0\fsp-0.6\fscx175\an1\c&HEBF4F7&\fnFaraco Hand\p1\3c&HEBF4F7&\pos(602.6,319.067)}m -130 374 b -151 386 -151 415 -130 427 b -26 427 80 427 183 426 b 204 415 204 386 183 374
Dialogue: 1,0:02:33.00,0:02:37.92,Signs,,0,0,0,,{\bord0\blur1\fs73\shad0\fsp-0.6\fscx175\an1\c&HEBF4F7&\fnFaraco Hand\p1\3c&HEBF4F7&\pos(602.6,319.067)\1aH&14&}m -130 374 b -151 386 -151 415 -130 427 b -26 427 80 427 183 426 b 204 415 204 386 183 374
Dialogue: 2,0:02:33.00,0:02:37.92,Signs,,0,0,0,,{\bord0\fs73\blur0.6\1aH&20&\shad0\fsp-0.6\fad(0,0)\an1\c&H535B5E&\fnFaraco Hand\pos(375.182,699.537)}#2 - how to spend time with friends

Apparently the typesetter was broken and typed \1aH&20& instead of \1a&H20&; VSFilter is fine with this, but apparently we respond by rendering nothing at all. Joy.

Don't memset bitmaps to 0 when making a copy

Because it takes a while and is completely pointless!

SSA AlphaLevel support

According to http://docs.aegisub.org/3.1/ASS_Tags/
\alpha should be able to be injected in each line during rendering (I'd think).
I saw some ssa/ass specs that showed there is (or at least was) an AlphaLevel tag in the style properties.
Ideally, I want to use this in mpv's --ass-force-style

Forgetting to antialias

From B7D6B506

Style: ed-eng,Raspoutine DemiBold,46,&HFFFFFFFF,&H000000FF,&H00000000,&H7C000000,-1,0,0,0,105,100,0,0,1,1.7,0,3,110,110,30,1
Style: ed-eng2,Raspoutine DemiBold,46,&H00FFFFFF,&H000000FF,&H00FFFFFF,&H7C000000,-1,0,0,0,105,100,0,0,1,3.2,0,3,110,110,30,1
Style: ed-eng3,Raspoutine DemiBold,46,&HFFFFFFFF,&H000000FF,&H00C863BE,&H7C000000,-1,0,0,0,105,100,0,0,1,7,0,3,110,110,30,1

Dialogue: 2,0:21:19.38,0:21:22.09,ed-eng,,0000,0000,0000,,{\fad(150,350)\blur0.4}The cherry blossoms fill the air
Dialogue: 1,0:21:19.38,0:21:22.09,ed-eng2,,0000,0000,0000,,{\fad(150,350)\blur1.2}The cherry blossoms fill the air
Dialogue: 0,0:21:19.38,0:21:22.09,ed-eng3,,0000,0000,0000,,{\fad(150,350)\blur5.2}The cherry blossoms fill the air

shudder; probably a FreeType thing? Happens in both their rasterizer and the new one by MrSmile.

Multi-threading!

Multi-threaded rendering would almost certainly be a performance boost for libass, but we need to answer a lot of questions before we start work, including:

• At what stage(s?) do we use threads? Per-event? Per-glyph?
• Which thread library do we use? We need cross-platform support.
• How will this affect cacheing? What do we need to do to efficiently use mutexes, avoid deadlocks, etc…
• Will this have any impact on multithreaded video decoding? If so, how can it be mitigated?
• How should we determine how many threads to use, especially when considering video decoders, already-multithreaded players, and potential render-in-advance scenarios?
• How will this interact with #55 in general?

API Addition: "Strict Mode"

After some discussion in itw, I've realized that the most useful way to implement a "strict mode" would be at the libass API, not within the format itself. For instance, if the consumer called ass_set_strict(library, 1); (or track or renderer or wherever it makes most sense with any upcoming other API changes), we could disable behaviors meant for compatibility with semi-broken scripts, such as font and character substitutions. Authoring tools (Aegisub) would be expected call this, but players wouldn't. Thoughts?

change detection bug with vector clips

The second event doesn't have the change flag set:

Dialogue: 0,0:00:00.00,0:00:02.00,,,0,0,0,,{\fs50\pos(250,250)\iclip(m 0 0 l 400 0 l 400 220 l0 220)}Hello
Dialogue: 0,0:00:02.00,0:10:00.00,,,0,0,0,,{\fs50\pos(250,250)\iclip(m 0 0 l 400 0 l 400 230 l0 230)}Hello

(Complete test script: http://sprunge.us/jRWb)

The output ass_detect_change sees is the same. The vector clip merely makes the existing pixels transparent. Thus the change detection fails. This causes problems with applications which use this flag, such as mplayer and mpv.

The hard solution to this would be caching vector clips.

Large drawings fail with "Failed to render glyph: 1"

I'm not sure exactly when this started happening, or whether it's a problem within Freetype or at libass; either way, it needs investigating.

yasm version check required

It seems the configure script does not check for the yasm version. Compilation fails with old yasm versions (e.g. 1.1.0.2352 on Ubuntu 12.04). It seems the AVX instructions were added only later.

Slow downs due to too large bounding boxes in corner cases

In some corner cases, apparently if there are spaces and line breaks involved, the bounding boxes of some lines become too large.

Test:

[Script Info]
; Script generated by Aegisub 2.1.8
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
PlayResX: 848
PlayResY: 480
ScaledBorderAndShadow: yes

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Sans,46,&H80FF0000,&H800000FF,&H8000FF00,&H80ff00ff,0,0,0,0,100,100,0,0,1,3.75,2,2,100,100,250,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text

Dialogue: 0,0:00:00.00,0:10:00.00,Default,,0000,0000,0000,,a\Nb\Nc\N d

http://sprunge.us/EJMQ

Keep in mind that it renders correctly. The issue is more visible when rendered with making all images non-transparent by adding an alpha offset:

The bounding box of the last character somehow spans the previous 2 lines in Y direction, and a seemingly random amount in X direction. Adding more text to other lines makes the bounding box even larger, which leads to actual performance problems in real-world cases.

VSFilter does not require section headers

http://privatepaste.com/0443b79802
This script renders at a pathological font size with libass, apparently due to the missing opening [. VSFilter ignores the issue. Yes, this was actually released (>herkz)

Banner effect breaks newlines

The banner effect should not break \N. Multiple lines are still allowed, whitespace on each line is still trimmed, and lines are still aligned. Wrapping style always defaults to 2 (no automatic wrapping), but it can still be overridden with {\q}.

shaper issues in arabic

hi

vs filter:-
http://i.imgur.com/W7r2Hml.png

http://i.imgur.com/QF2yavR.png

libass:-
http://i.imgur.com/hNH1UZu.png

font and sub:-
http://www.solidfiles.com/d/0f4a1900f0/font_and_sub.rar

thanks

ass_process_chunk is too slow

Apparently this is mostly because of Format: lines, but we should be able to aggressively optimize for the format Aegisub generates by default and fall back to the slower parsing behavior in other cases.

Mask not showing up

[D84BC791]

Dialogue: 0,0:08:18.68,0:08:18.72,Signs,,0,0,0,,{\an7\pos(0,0)\blur1\c&H201E1F&\fscx100\fscy100\p1\clip()}m 964 166 l 964 361 1235 361 1235 195 1145 195 1114 165

Empty \clip statement stands out here

Tags don't apply to drawings unless there's at least one character between the override and the drawing

They should. I checked against VSFilter.
Broken:
{\blur0.4\c&HDDDDDD&}– Space Center Missile Defense Sy{\alpha&H9A&\c&H90837E&}{\p1\pbo10}m 2 0 l 2 42 19.61 42 19.61 0{\p0}
https://www.dropbox.com/s/y1hn3zy7hyhnr49/Screenshot%202014-01-02%2003.06.45.png
Renders the way I'd expect the above to (ugly workaround)
{\blur0.4\c&HDDDDDD&}– Space Center Missile Defense Sy{\fs0\alpha&H9A&\c&H90837E&} {\p1\pbo10}m 2 0 l 2 42 19.61 42 19.61 0{\p0}
https://www.dropbox.com/s/klkagzg95wuo9yi/Screenshot%202014-01-02%2003.08.09.png