[FramedropBug] mpv always framedrops with specific subtitle on?

erickyun commented 1 year ago

Important Information

Provide following Information:

mpv version mpv 0.35.0-364-gc7a8e715
Windows Version Windows 10 Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz 2.50 GHz NVIDIA GeForce GTX 1650
Source of the mpv binary https://github.com/shinchiro/mpv-winbuild-cmake/releases/download/20230421/mpv-x86_64-v3-20230421-git-c7a8e71.7z

Expected behavior

mpv plays video.mkv embed .ass subtitle without framedrop

Actual behavior

mpv always frame drops with subtitle on.

Log file

mpv --no-config vid.mkv -v -v --log-file=log0.txt log0.txt

Sample files

video-sample.zip

I noticed that with mpv-android if I use it on portrait orientation there is no framedrop but if I use landscape orientation mpv-android also start to framedrop? mpv-android-log0-portrait-mode.txt mpv-android-log1-landscape-mode.txt

Traneptora commented 1 year ago

With vo-gpu-next I get an OOM:

[vo/gpu-next/libplacebo] Allocation of size   62M failed: VK_ERROR_OUT_OF_DEVICE_MEMORY!
[vo/gpu-next/libplacebo] Memory heaps supported by device:
[vo/gpu-next/libplacebo]     0: flags 0x1 size 8192M
[vo/gpu-next/libplacebo]     1: flags 0x0 size   23G
[vo/gpu-next/libplacebo]     2: flags 0x1 size  246M
[vo/gpu-next/libplacebo] Memory pool 0:
[vo/gpu-next/libplacebo]     Compatible types: 0x82
[vo/gpu-next/libplacebo]     Optimal flags: 0x1
[vo/gpu-next/libplacebo]     Slab  0:        0 x 4320K:   13M used   16M res   16M alloc from heap 0, efficiency 77.78%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  1: fffffffffffffffc x  4096:  4096 used  8192 res  256K alloc from heap 0, efficiency 50.00%  [../src/shaders/lut.c:500]
[vo/gpu-next/libplacebo]     Slab  2:     fffe x   16K:   16K used   16K res  256K alloc from heap 0, efficiency 100.00%  [../src/shaders/lut.c:500]
[vo/gpu-next/libplacebo]     Slab  3:        0 x 4320K:   26M used   33M res   33M alloc from heap 0, efficiency 77.78%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  4:     fff4 x 4320K: 8000K used   12M res   67M alloc from heap 0, efficiency 61.73%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  5:        e x  496K:  496K used  496K res 1984K alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  6:        b x   15M:   15M used   15M res   60M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  7:        6 x   15M:   31M used   31M res   62M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  8:       fe x   15M:   15M used   15M res  124M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  9:        c x   16M:   32M used   32M res   64M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Pool summary:  141M used  157M res  430M alloc, efficiency 89.77%, utilization 36.53%
[vo/gpu-next/libplacebo] Memory pool 1:
[vo/gpu-next/libplacebo]     Compatible types: 0xffffffff
[vo/gpu-next/libplacebo]     Required flags: 0x1
[vo/gpu-next/libplacebo]     Optimal flags: 0x2
[vo/gpu-next/libplacebo]     Buffer flags: 0xc3
[vo/gpu-next/libplacebo]     Slab  0: 3fffffffffc x  6144:  6144 used   16K res  256K alloc from heap 2, efficiency 37.50%  [../src/gpu/utils.c:1093]
[vo/gpu-next/libplacebo]     Slab  1:  fffffff x  9216:     0 used  4096 res  256K alloc from heap 2, efficiency 0.00%  [../src/gpu/utils.c:1093]
[vo/gpu-next/libplacebo]     Pool summary:  6144 used   20K res  512K alloc, efficiency 30.00%, utilization 3.91%
[vo/gpu-next/libplacebo] Memory pool 2:
[vo/gpu-next/libplacebo]     Compatible types: 0xffffffff
[vo/gpu-next/libplacebo]     Optimal flags: 0x3
[vo/gpu-next/libplacebo]     Buffer flags: 0x3
[vo/gpu-next/libplacebo]     Slab  0:        f x   15M:     0 used     0 res   61M alloc from heap 2, efficiency 100.00%  [../src/gpu/utils.c:471]
[vo/gpu-next/libplacebo]     Slab  1:        f x   15M:     0 used     0 res   62M alloc from heap 2, efficiency 100.00%  [../src/gpu/utils.c:471]
[vo/gpu-next/libplacebo]     Pool summary:     0 used     0 res  123M alloc, efficiency 100.00%, utilization 0.00%
[vo/gpu-next/libplacebo] Memory summary:  141M used  157M res  554M alloc, efficiency 89.76%, utilization 28.35%, max page:  512M
[vo/gpu-next/libplacebo]   Backtrace:
[vo/gpu-next/libplacebo]     #0  0x00007f2706c98506 in slab_alloc+0x8b6 at /home/leo/.local/lib/libplacebo.so.270+0x96506
[vo/gpu-next/libplacebo]     #1  0x00007f2706c99b48 in vk_malloc_slice+0x758 at /home/leo/.local/lib/libplacebo.so.270+0x97b48
[vo/gpu-next/libplacebo]     #2  0x00007f2706c8d743 in vk_buf_create+0x2b3 at /home/leo/.local/lib/libplacebo.so.270+0x8b743
[vo/gpu-next/libplacebo]     #3  0x00007f2706c2dd6f in pl_buf_create+0x1ff at /home/leo/.local/lib/libplacebo.so.270+0x2bd6f
[vo/gpu-next/libplacebo]     #4  0x00007f2706c31a96 in pl_tex_upload_pbo+0xf6 at /home/leo/.local/lib/libplacebo.so.270+0x2fa96
[vo/gpu-next/libplacebo]     #5  0x00007f2706c2d9af in pl_tex_upload+0x7f at /home/leo/.local/lib/libplacebo.so.270+0x2b9af
[vo/gpu-next/libplacebo]     #6  0x00005567278a8111 in update_overlays+0x231 at mpv+0x185111
[vo/gpu-next/libplacebo]     #7  0x00005567278ac138 in draw_frame+0x928 at mpv+0x189138
[vo/gpu-next/libplacebo]     #8  0x000055672786462b in vo_thread+0x68b at mpv+0x14162b
[vo/gpu-next/libplacebo]     #9  0x00007f27066dfbb5 in pthread_condattr_setpshared+0x4e5 at /usr/lib/libc.so.6+0x85bb5
[vo/gpu-next/libplacebo]     #10 0x00007f2706761d90 in __clone+0x120 at /usr/lib/libc.so.6+0x107d90
[vo/gpu-next/libplacebo]   for malloc: ../src/gpu/utils.c:471
[vo/gpu-next/libplacebo] No slab to serve request for   15M bytes (with alignment 0xc00) in pool 2!
[vo/gpu-next] Failed uploading OSD texture!

erickyun commented 1 year ago

With vo-gpu-next I get an OOM:

[vo/gpu-next/libplacebo] Allocation of size   62M failed: VK_ERROR_OUT_OF_DEVICE_MEMORY!
[vo/gpu-next/libplacebo] Memory heaps supported by device:
[vo/gpu-next/libplacebo]     0: flags 0x1 size 8192M
[vo/gpu-next/libplacebo]     1: flags 0x0 size   23G
[vo/gpu-next/libplacebo]     2: flags 0x1 size  246M
[vo/gpu-next/libplacebo] Memory pool 0:
[vo/gpu-next/libplacebo]     Compatible types: 0x82
[vo/gpu-next/libplacebo]     Optimal flags: 0x1
[vo/gpu-next/libplacebo]     Slab  0:        0 x 4320K:   13M used   16M res   16M alloc from heap 0, efficiency 77.78%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  1: fffffffffffffffc x  4096:  4096 used  8192 res  256K alloc from heap 0, efficiency 50.00%  [../src/shaders/lut.c:500]
[vo/gpu-next/libplacebo]     Slab  2:     fffe x   16K:   16K used   16K res  256K alloc from heap 0, efficiency 100.00%  [../src/shaders/lut.c:500]
[vo/gpu-next/libplacebo]     Slab  3:        0 x 4320K:   26M used   33M res   33M alloc from heap 0, efficiency 77.78%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  4:     fff4 x 4320K: 8000K used   12M res   67M alloc from heap 0, efficiency 61.73%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  5:        e x  496K:  496K used  496K res 1984K alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  6:        b x   15M:   15M used   15M res   60M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  7:        6 x   15M:   31M used   31M res   62M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  8:       fe x   15M:   15M used   15M res  124M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Slab  9:        c x   16M:   32M used   32M res   64M alloc from heap 0, efficiency 100.00%  [../src/utils/upload.c:245]
[vo/gpu-next/libplacebo]     Pool summary:  141M used  157M res  430M alloc, efficiency 89.77%, utilization 36.53%
[vo/gpu-next/libplacebo] Memory pool 1:
[vo/gpu-next/libplacebo]     Compatible types: 0xffffffff
[vo/gpu-next/libplacebo]     Required flags: 0x1
[vo/gpu-next/libplacebo]     Optimal flags: 0x2
[vo/gpu-next/libplacebo]     Buffer flags: 0xc3
[vo/gpu-next/libplacebo]     Slab  0: 3fffffffffc x  6144:  6144 used   16K res  256K alloc from heap 2, efficiency 37.50%  [../src/gpu/utils.c:1093]
[vo/gpu-next/libplacebo]     Slab  1:  fffffff x  9216:     0 used  4096 res  256K alloc from heap 2, efficiency 0.00%  [../src/gpu/utils.c:1093]
[vo/gpu-next/libplacebo]     Pool summary:  6144 used   20K res  512K alloc, efficiency 30.00%, utilization 3.91%
[vo/gpu-next/libplacebo] Memory pool 2:
[vo/gpu-next/libplacebo]     Compatible types: 0xffffffff
[vo/gpu-next/libplacebo]     Optimal flags: 0x3
[vo/gpu-next/libplacebo]     Buffer flags: 0x3
[vo/gpu-next/libplacebo]     Slab  0:        f x   15M:     0 used     0 res   61M alloc from heap 2, efficiency 100.00%  [../src/gpu/utils.c:471]
[vo/gpu-next/libplacebo]     Slab  1:        f x   15M:     0 used     0 res   62M alloc from heap 2, efficiency 100.00%  [../src/gpu/utils.c:471]
[vo/gpu-next/libplacebo]     Pool summary:     0 used     0 res  123M alloc, efficiency 100.00%, utilization 0.00%
[vo/gpu-next/libplacebo] Memory summary:  141M used  157M res  554M alloc, efficiency 89.76%, utilization 28.35%, max page:  512M
[vo/gpu-next/libplacebo]   Backtrace:
[vo/gpu-next/libplacebo]     #0  0x00007f2706c98506 in slab_alloc+0x8b6 at /home/leo/.local/lib/libplacebo.so.270+0x96506
[vo/gpu-next/libplacebo]     #1  0x00007f2706c99b48 in vk_malloc_slice+0x758 at /home/leo/.local/lib/libplacebo.so.270+0x97b48
[vo/gpu-next/libplacebo]     #2  0x00007f2706c8d743 in vk_buf_create+0x2b3 at /home/leo/.local/lib/libplacebo.so.270+0x8b743
[vo/gpu-next/libplacebo]     #3  0x00007f2706c2dd6f in pl_buf_create+0x1ff at /home/leo/.local/lib/libplacebo.so.270+0x2bd6f
[vo/gpu-next/libplacebo]     #4  0x00007f2706c31a96 in pl_tex_upload_pbo+0xf6 at /home/leo/.local/lib/libplacebo.so.270+0x2fa96
[vo/gpu-next/libplacebo]     #5  0x00007f2706c2d9af in pl_tex_upload+0x7f at /home/leo/.local/lib/libplacebo.so.270+0x2b9af
[vo/gpu-next/libplacebo]     #6  0x00005567278a8111 in update_overlays+0x231 at mpv+0x185111
[vo/gpu-next/libplacebo]     #7  0x00005567278ac138 in draw_frame+0x928 at mpv+0x189138
[vo/gpu-next/libplacebo]     #8  0x000055672786462b in vo_thread+0x68b at mpv+0x14162b
[vo/gpu-next/libplacebo]     #9  0x00007f27066dfbb5 in pthread_condattr_setpshared+0x4e5 at /usr/lib/libc.so.6+0x85bb5
[vo/gpu-next/libplacebo]     #10 0x00007f2706761d90 in __clone+0x120 at /usr/lib/libc.so.6+0x107d90
[vo/gpu-next/libplacebo]   for malloc: ../src/gpu/utils.c:471
[vo/gpu-next/libplacebo] No slab to serve request for   15M bytes (with alignment 0xc00) in pool 2!
[vo/gpu-next] Failed uploading OSD texture!

Why is this happening sir? İs this a Libass or mpv error?

Traneptora commented 1 year ago

I don't know, I'm just providing more data.

Jj0YzL5nvJ commented 1 year ago

Try adding: --hwdec=auto-copy

erickyun commented 1 year ago

Try adding: --hwdec=auto-copy

I already tried sir but it still gives me framedrops! :( eventhough my pc should be strong enough to play it? I think that This error seems more like a mpv or libass error?

log.txt --hwdec=auto-copy

Jj0YzL5nvJ commented 1 year ago

I used to have similar problems with subtitles with special effects on my old PCs. The one I use now doesn't have those problems, but before switching to my current GPU, hardware acceleration was very limited (frame drops).

This error seems more like a mpv or libass error?

Sounds more like a hardware limitation to me or a limitation of the rendering API on your hardware.

Try without using hardware acceleration (--hwdec=no) and while you do it, monitor the CPU usage.

erickyun commented 1 year ago

I used to have similar problems with subtitles with special effects on my old PCs. The one I use now doesn't have those problems, but before switching to my current GPU, hardware acceleration was very limited (frame drops).

This error seems more like a mpv or libass error?

Sounds more like a hardware limitation to me or a limitation of the rendering API on your hardware.

As I have said here sir on my "Xiaomi redmi note 8 pro" android device https://github.com/mpv-player/mpv/issues/11612#issue-1679419716 when I try to play the video on portrait orientation there is no framedrop but if I use landscape orientation mpv-android also start to framedrop! And it also flickers. İs this not player or libass problem? And my pc is new I also tried on a stronger system got same problem?

Jj0YzL5nvJ commented 1 year ago

Try your sample with:

--no-config --hwdec=no --no-border --ontop --window-scale=0.97
--no-config --no-border --ontop --window-scale=0.93
--no-config --window-scale=0.9

Jj0YzL5nvJ commented 1 year ago

Important Information

mpv version: 0.35.0-375-g6d422b3edc to 0.36.0-278-ge15619e70d
Linux Distribution and Version: Xubuntu 22.04.3 LTS
Source of the mpv binary: My own build
Window Manager and version: Xfce 4.16
GPU driver and version:

glxinfo -B

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon RX 560 Series (polaris11, LLVM 15.0.7, DRM 3.42, 5.15.0-83-generic) (0x67ff)
    Version: 23.0.4
    Accelerated: yes
    Video memory: 4096MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 3747 MB, largest block: 3747 MB
    VBO free aux. memory - total: 4059 MB, largest block: 4059 MB
    Texture free memory - total: 3747 MB, largest block: 3747 MB
    Texture free aux. memory - total: 4059 MB, largest block: 4059 MB
    Renderbuffer free memory - total: 3747 MB, largest block: 3747 MB
    Renderbuffer free aux. memory - total: 4059 MB, largest block: 4059 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 4096 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 3747 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 560 Series (polaris11, LLVM 15.0.7, DRM 3.42, 5.15.0-83-generic)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.0.4-0ubuntu1~22.04.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.0.4-0ubuntu1~22.04.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.0.4-0ubuntu1~22.04.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Reproduction steps

Run the sample video at very specific "resize":

1920x1080 (--no-border --window-scale=1)
1824x1026 (--no-border --window-scale=0.95)
1670x939 (--window-scale=0.87)

Expected behavior

Not frame drops at arbitrary resolutions or full screen on videos with soft subs with posting signs

Actual behavior

Frame drops on 1920x1080 monitors in full screen and random window scales

Log file

mpv --no-config --fs --log-file=0.txt vid.mkv (Affected: 1920x1080) mpv --no-config --hwdec=no --no-border --ontop --window-scale=0.97 --log-file=1.txt vid.mkv (Unaffected: 1862x1047) mpv --no-config --hwdec=no --no-border --ontop --window-scale=0.95 --log-file=2.txt vid.mkv (Affected: 1824x1026) mpv --no-config --ontop --window-scale=0.93 --log-file=3.txt vid.mkv (Unaffected: 1785x1004) mpv --no-config --window-scale=0.9 --log-file=4.txt vid.mkv (Unaffected: 1728x972) mpv --no-config --window-scale=0.87 --log-file=5.txt vid.mkv (Affected: 1670x939)

Sample files

video-sample.zip

eXmendiC commented 1 year ago

I'm having a similar issue. Sometime when a new subtitle line is rendered, there are few frame drops. Expecially noticable when there are stuff like karaoke effects. However, this issue wasn't always present and I'm running a Ryzen 5900X with a RTX 4090, so "old hardware" shouldn't be the reason here. Interpolation is on and my screen runs with 4k@120Hz. Both "vo=gpu" and "vo=gpu-next" with vulkan have this issue, "hwdec=no" won't change anything.

Anyway, I tried to track down what version introduced the issues, here my results: mpv-x86_64-v3-20220828-git-1a32bd3 => Looks fine with subtitles on [oldest v3 build] mpv-x86_64-v3-20230430-git-6d422b3 => Heavy frame drops with subtitles on [newest v3 build] mpv-x86_64-20230430-git-6d422b3 => Heavy frame drops with subtitles on ; So "v3" isn't the issue [newest regular build]

mpv-x86_64-v3-20230205-git-e439ddc => Looks fine with subtitles on mpv-x86_64-v3-20230212-git-a40958c => Heavy frame drops with subtitles on

So, something did probably change between these two versions. For now I'm sticking with stable 0.35.1-v3 build since that seems to work fine for me as well.

Edit: Maybe my issue is also related to https://github.com/mpv-player/mpv/issues/11511 ?

TheOneric commented 1 year ago

Both the original sample and the one from Jj0YzL5nvJ are identical. They have large vector drawings with extreme blur (\blur20 and \blur30). Blur is one of the costliest things to render. I cannot reproduce the resolution behaviour reported by Jj0YzL5nvJ, instead there’s a steady increase in drops as resolution increases. As far as subtitle rendering goes, this is as expected. The subs are just really heavy.

@Jj0YzL5nvJ : if you can still reproduce this behaviour where some lower res have worse perf than higher res, please profile both cases, so we know what’s taking up resources.

eXmendiC’s regression doesn't seem to be the cache discard from #11944 since it was report several days before the relevant change landed. But there’s also no sample so nothing to look into.

Jj0YzL5nvJ commented 1 year ago

if you can still reproduce this behaviour where some lower res have worse perf than higher res, please profile both cases, so we know what’s taking up resources.

mpv --no-config --hwdec=no --no-border --ontop --window-scale=0.87 --log-file=1.txt vid.mkv

 (+) Video --vid=1 (*) (hevc 1920x1080 23.976fps)
 (+) Audio --aid=1 --alang=jpn (*) (aac 2ch 48000Hz)
 (+) Subs  --sid=1 --slang=eng (*) (ass)
     Subs  --sid=2 --slang=enm 'Honorifics' (ass)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p10
AV: 00:00:13 / 00:00:20 (67%) A-V:  0.499 Dropped: 2

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:00:18 / 00:00:20 (87%) A-V:  0.000 Dropped: 24

Exiting... (End of file)

mpv --no-config --hwdec=no --no-border --ontop --window-scale=0.9 --log-file=2.txt vid.mkv

 (+) Video --vid=1 (*) (hevc 1920x1080 23.976fps)
 (+) Audio --aid=1 --alang=jpn (*) (aac 2ch 48000Hz)
 (+) Subs  --sid=1 --slang=eng (*) (ass)
     Subs  --sid=2 --slang=enm 'Honorifics' (ass)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 yuv420p10
AV: 00:00:18 / 00:00:20 (87%) A-V:  0.000

Exiting... (End of file)

TheOneric commented 1 year ago

@Jj0YzL5nvJ these are just logs again, not a performance profile and I (still) cannot reproduce your results, so without a perf analysis by yourself, noone will be able to get any insight into what’s happening here.

However, regular mpv runs with presenting frames at the normal rate showed some quirky results for me before in other cases. Mayhaps, you are just running into a similar scheduling/boosting/chace/w.e. quirk. Try anylising the performance with a untimed bench mode for both scales. I.e. measure the total time the following command takes and additionally keep an eye on the FPS counter for both scale values:

time \
mpv --no-config --audio=no --untimed=yes --video-sync=display-desync \
  --vulkan-swap-mode=immediate --opengl-swapinterval=0 \
  --osd-msg1='FPS: ${estimated-display-fps}' \
  --vo=gpu --no-border --ontop --window-scale=0.87 \
  vid.mkv

Run each scale value multiple times to ensure the results are consistent.

(For me there’s no real difference, for both values the results are within run-to-run variance, with 0.87 seemingly a tiny bit faster, but not in any meaningful way)

Jj0YzL5nvJ commented 12 months ago

https://0x0.st/HOUO.mp4

Run each scale value multiple times to ensure the results are consistent.

The result only differs when recording the screen, without recording the results have a higher FPS, but the parts with FPS drops don't change (the signs).

P.S: Sorry, I don't notice the command time. Indeed, the times show inconsistencies

TheOneric commented 11 months ago

Sooooo, while I sill can’t reproduce anything using my build of mpv, I can perfectly recreate a ~2.5× subtitle rendering time increase with libass’ own profile tool if patched to emulate your scaling settings. I really should have tried this earlier. I guess the lesson to be learned here is that I should never trust any subtitle perf results from my mpv build, or attempt to gather/reproduce results this way — even when using the benchmark mpv configuration.

Sorry for all the trouble and thanks for your persistence. I now forwarded the report with some initial look at perf records to https://github.com/libass/libass/issues/709

TheOneric commented 11 months ago

Update: the performance difference between scale=0.87 and scale=0.9 comes down to the 0.87 case just by coincidence having luck in which of the cached bitmaps of moving blurs can be reused, while the 0.9 case is especially unlucky. Curious case to look at, but not really any bug or much that can be done. Disabling caching or tweaking settings to be more strict about subpixel movement evens out the performance to always be like scale=0.9.

In theory a build-time config settings for lower (and higher) rendering precision might help you out here, but that’d require a special build and the relevant PR https://github.com/libass/libass/pull/449 is stale (properly evaluating the impact of new settings depends on another patch which is stuck at different issues).

Apart from this scale=0.XX difference everything is as expected. As written before, the subs use unnecessarily large and many blurs, which just is inherently very costly to render.

mpv-player / mpv