OOM when playing back large video

Nextcloud version: 23.0.0
Operating system and version: Debian 11 "Bullseye"
Apache or nginx version: 2.4.51-1~deb11u1
PHP version: 8.0.14 (FPM)

The issue you are facing:
When I click on a specific video to play it back, it endlessly loads while the servers cpu is pinned at 100% on all cores and apache starts to slowly use more and more memory. Eventually it gets killed by the oom_killer (3.75GiB of RAM on the VM, apache2 got up to 3.4GB before OOM).
The video is rather large (775MB, Bitrate of ~200Mbit/s), but I still don’t understand why it is forcing Apache to use so much memory. When I close the preview while its still loading and refresh pages, navigate the ui it still continues to suck more and more memory until the oom finally happens.
Is there a way to maybe limit the playback of videos to a certain size?

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Click on the video to open the Playback

The output of your Nextcloud log in Admin > Logging:

no output

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'passwordsalt' => 'something',
  'secret' => 'something else',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'mydomain.com',
  ),
  'datadirectory' => '/mnt/storagebox_sshfs/nextcloud/',
  'dbtype' => 'mysql',
  'version' => '23.0.0.10',
  'overwrite.cli.url' => 'http://mydomain.com',
  'htaccess.RewriteBase' => '/',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'something different',
  'installed' => true,
  'instanceid' => 'something',
  'activity_expire_days' => 14,
  'auth.bruteforce.protection.enabled' => true,
  'blacklisted_files' =>
  array (
    0 => '.htaccess',
    1 => 'Thumbs.db',
    2 => 'thumbs.db',
  ),
  'cron_log' => true,
  'default_phone_region' => 'DE',
  'filelocking.enabled' => 'true',
  'logtimezone' => 'Europe/Berlin',
  'log_rotate_size' => 104857600,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'overwriteprotocol' => 'https',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis-server.sock',
    'port' => 0,
    'dbindex' => 0,
    'timeout' => 1.5,
  ),
  'quota_include_external_storage' => false,
  'skeletondirectory' => '',
  'trashbin_retention_obligation' => 'auto, 14',
  'app_install_overwrite' =>
  array (
    0 => 'documentserver_community',
  ),
);

The output of your Apache/nginx/system log in /var/log/____:

Jan 03 22:56:40 nc-test systemd[1]: apache2.service: A process of this unit has been killed by the OOM killer.
Jan 03 22:56:40 nc-test apachectl[28676]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to sup>
Jan 03 22:56:40 nc-test systemd[1]: apache2.service: Failed with result 'oom-kill'.
Jan 03 22:56:40 nc-test systemd[1]: apache2.service: Consumed 4min 20.268s CPU time.

I know it is probably not wise to play back this video, but I’m not the only person using this instance and others may not know about it. This can result in them accidentially killing the webserver.