SSA/ASS PlayResX/PlayResY not used

[nanone]

Summary of the bug

When hardcoding SSA/ASS subtitles into video, FFmpeg does not seem to use PlayResX/PlayResY properties, but instead seems to use the video resolution, resulting in an incorrectly scaled subtitle.

To rule out that the underlying issue could be libass itself, I've tested it with VLC and hardcoding it with Handbrake, both giving the correct result (correct meaning before hardcoding as displayed in VLC/Aegisub; also see attachment mkv-ffmpeg-comparison.png where MKV is the correct one).

The hypothesis that FFmpeg is scaling subtitles based on the video resolution instead of PlayResX/Y can be further tested by importing the MKV file into Aegisub, load the subtitle file, and resample to 1920x1080. This gives the same incorrect result as FFmpeg does and therefore strenghten my beliefs that FFmpeg is scaling these subtitles without taking into account the PlayRes properties in the subtitle file.

Reproduction

Attachments include a MKV file with embedded subtitle, having PlayResX/Y set to 1280x720, with the video stream dimensions 1920x1080.

$ ffmpeg -loglevel debug -i test-video.mkv -map 0:0 -filter_complex subtitles='test.mkv':si=0 -c:v libx264 -crf 18 -movflags faststart test-video.mp4

Check output of test-video.mp4 which corresponds to "FFmpeg MP4" in the screenshot mkv-ffmpeg-comparison.png.

FFmpeg version

$ ffmpeg version n5.1.3-15-g25cd95a9dc-20230810 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 13.1.0 (crosstool-NG 1.25.0.196_227d99d)
  configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --disable-chromaprint --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libass --enable-libbluray --disable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libssh --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --disable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --disable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra-version=20230810
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100

Also tested with versions 4.4.4, 5.1.3, 6.0 giving same results (libass enabled; ​releases)

[nanone]

I've just found out that I need to explicetely supply `original_size` to the subtitles like so:

ffmpeg -loglevel debug -i test-video.mkv -map 0:0 -filter_complex subtitles='test-video.mkv':original_size=hd720:si=0 -c:v libx264 -crf 18 -movflags faststart test-video.mp4

This works and I realise, instead this "issue" could be turned into a feature request. That is, if it's possible to let ffmpeg automatically determine the original_size based onPlayResX/Y?

[nanone]

Also noticed that with libass, you can use LayoutResX and LayoutResY nowadays ​Libass PR 641, which also solves the problem (but only works starting from 5.1.3 (fails with 5.1.2).
I don't see these properties in any of the FFmpeg tests though, so maybe tests can be extended.