libass rendering is problematic when {\p\bord}

[op200]

Aegisub's built-in libass
This bug does not exist in VSFilter

This image was rendered by MPC-HC's libass

[arch1t3cht]

It's hard to see what exactly you're referring to here without seeing the full subtitle file, but this is probably because libass applies stroking to shapes while vsfilter applies it to the bitmaps. The rendering differentials arising from this are a known issue in libass (see e.g. libass/libass#302, libass/libass#123, libass/libass#582), but it seems quite possible that this won't ever be fixed. Either way, this is something that should be reported at libass (but doesn't need to be, since it's known already), not here, since Aegisub has no control over this.

[op200]

(Reply to 0tkl) it need {\1aFF}

[Script Info]
; Script generated by Aegisub 9706-cibuilds-20caaabc0
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None
PlayResX: 1920
PlayResY: 1080

[Aegisub Project Garbage]
Video File: ?dummy:23.976:38000:1920:1080:47:163:254:c
Video AR Value: 1.777778
Video Zoom Percent: 0.875000

[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,Arial,48,&HFFFFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,2,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:05.00,Default,,0,0,0,,{\bord1}{\p1}m 0 0 l 800 0 l 800 800 l 0 800 {\p0}

[0tkl]

Now it can be confirmed. I don't know why, but on my Aegisub, the inconsistent width appears on some random sizes, although not the same as the size you provided.

Also you mentioned MPC-HC, so i tried it on my local mpv. The rendering problem doesn't appear on mpv either.

PS C:\Users\username\AppData\Local\mpv> .\mpv --version
mpv v0.38.0-580-g00f43e09 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Jul  7 2024 00:04:00
libplacebo version: v7.349.0 (v7.349.0-dirty)
FFmpeg version: N-116159-gecd3a9783
FFmpeg library versions:
   libavcodec      61.9.100
   libavdevice     61.2.100
   libavfilter     10.2.102
   libavformat     61.4.100
   libavutil       59.28.100
   libswresample   5.2.100
   libswscale      8.2.100

[op200]

(Reply to 0tkl)
So I guess this is due to Aeigsub, or due to the version of libass

[arch1t3cht]

I see what you mean now, very interesting. For what it's worth, this also happens on my version of mpv (on Windows):

mpv v0.37.0-522-ga56d8ff1 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
built on Mar 9 2024 10:22:56
libplacebo version: v7.347.0 (v6.338.0-102-g0d3542d-dirty)
FFmpeg version: N-114081-g64634e809
FFmpeg library versions:
libavutil 59.1.100
libavcodec 61.1.100
libavformat 61.0.100
libswscale 8.0.100
libavfilter 10.0.100
libswresample 5.0.100

[op200]

Now it is confirmed that the bug is caused by libass scaling
Thank you for your answers