Description:
This particular reproduction was performed with an x86-64-v3 Arch repo but this was never an issue at all before and is even seen in other distros, apparently, as seen in the cited upstream bug report.

In that instance, the same issue happened in an average x86-64 Fedora instance; given that it doesn't necessarily seem to be Arch-specific,
I had provided my findings upstream but was denied on the grounds of:
- (Essentially) running a non-Ubuntu Linux distribution
- Using a distro-source Qt build
- And because the upstream Gitlab isn't for user issues (which I frankly find ridiculous because their own wiki says to report user issues to them, which is why I went there to begin with:
https://wiki.videolan.org/Report_bugs

Additional info:
* package version: 3.0.18 (revision 3.0.13-8-g41878ff4)
* config and/or log files, etc:
- (Backtrace Log) https://code.videolan.org/videolan/vlc/uploads/8edc33091212ff75e567a3c42478f0cc/VLC-backtrace.txt
- (Terminal Output Log) https://code.videolan.org/videolan/vlc/uploads/b2c77174b8c0c68ddfe137b991b87e79/VLC-terminal-output.log
* link to upstream bug report, if any: https://code.videolan.org/videolan/vlc/-/issues/27660#note_359783

Steps to reproduce:
- Either double click a .mkv file with VLC being the default video player or manually open VLC and load a .mkv file via a file-picker program.