In the latest Version (3.0.18) some ASS Subtitle tracks are shown incorrectly. On the Subtitle Files that i want to play, there should be white text surrunded by a thick border in black or sometimes other colours. But this Border is missing or at least it is only a very small border, not like it should be. With the last Version (3.0.17.4) it still worked.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
All four samples are missing a ScaledBorderAndShadow: yes header to achieve the desired result.
Their info headers also indicate they were directly copied from crunchyroll.com. Crunchyroll subs are authored not for standard ASS renderers, but for crunchyroll.com’s custom player (based on outdated libass and using non-standard, VSF-incompatible settings) and are not supposed to be distributed outside of Crunchyroll.
To port such subs to (mostly) standard ASS, you need to set ScaledBorderAndShadow: yes(, maybe also YCbCr Matrix: None) and set LayoutResX and LayoutResY to the same values as PlayResX and PlayResY.
LED2000 seems to be using a 1080p video, which will result in the reported thin borders. You probably tested with a lower resolution video.
Without ScaledBorderAndShadow: yes (a header introduced with ASS, SSA always worked like : no), borders and shadows are in video resolution pixels. 5px of a 360p video will (after upscaling) appear thicker than 5px of a 1080p video.
(Yes, some ASS releases intentionally don't use or set thte header to : no, most set : yes though and common editors default to setting : yes. Crunchyroll doesn't set the header and uses its player implementation to facilitate : yes-like behaviour.)
With ScaledBorderAndShadows: yes border and shadow sizes are relative to PlayRes{X,Y}.
ok can reproduce
"mock://video_track_count=1;length=100000000;video_width=1920;video_height=1080" --sub-file=/tmp/f34125dd85edf4e65f7e39a4ad1cf285_329391a353.txt --start-time=13 --no-osd
I have also issues with the latest version with ASS Subtitles.
For me, the subtitles are misplaced / misaligned, when tags like \frx \fry or \frz is used (could be even more).
Example picture with VLC v.3.0.17.4
Example picture with VLC v.3.0.18
Example ass file:
example.ass
You can see the subtitles from the picture's above at 21:11 (min:sec).
While info headers with direct Crunchyroll references are not present (anymore) in this file, based on the remaining (partly non-sensical) headers and the style names and settings being typical for Crunchyroll, I’m assuming this too originates from crunchyroll.com. The same applies as in the other comment, with the specific discrepancy from this thread being rectified by LayoutRes* headers.
If you render the subtitles with the original and authoritative ASS implementation, (xy-)VSFilter, you'll notice the rendering matches the one from VLC 3.0.18. In prior VLC version, not setting storage size, some subs actually authored for standard renderers and public distribution were broken instead.
Sorry for the late reply, I didn't get or missed the notification for the ping.
As written above, the uploaded subs were authored for a specific non-standard renderer and are not supposed to be (able to be) extracted from the service. Given this, requiring people who extract CR subs from their proprietary environment anyway to also fix them up themselves, seems already fair enough to me.
But if you want to invest the extra effort, you could offer a setting for “Crunchyroll-like ASS rendering” or even try to autodetect raw CR rips. The latter might struggle with post-processed CR subs and likely require custom parsing. (E.g.: Original Script usually points to some Crunchyroll user, representing either the local CR subbing team or the publisher CR took the subs over from).
If you do implement such a mode, it might be good to first check if the relevant headers and only act if they aren't set (or set to the default). I’m relatively certain CR’s webplayer acts as if YCbCr Matrix: None were set, but I don't know if that also applies to their apps and the renderer used during authoring.
For reference, in mpv this could already be achieved with a conditional profile. Below is an otoh example which for simplicity assumes such files can be identified by having [CR] in their name.
I just noticed your contrib builds are still using libass 0.16.0. This version doesn't support LayoutRes* yet, since we only recent'ish managed to get a consensus across all active ASS renderers on how to implement such a feature. Furthermore 0.16.0 and 0.17.0 suffered from a memory bug, which was fixed in 0.17.1, so I’d advise to upgrade to 0.17.1. (See 0.17.0 and 0.17.1release notes for details.) (Also instead of disabling assembly on x86-Android due to PIC, you should be able to just pass --with-pic to configure. With HarfBuzz being unconditionally required since 0.15.0, all WITH_HARFBUZZ bits can be dropped as well.)