I would suggest, by the way, that the original file be conserved on the server side, in part to allow for potential better re-encodes in the future (as well as release of the original, once the codecs are free).

Encoding speed may be a factor for video, but for now we just need to work out the workflow in the MediaWiki internals.

For reference, recent IGPs can transcode video with negligible power consumption very quickly. Closed source drivers not required. For example:

ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device /dev/dri/renderD128 -i testinput.mkv -c:v hevc_vaapi -vf scale_vaapi=1920:1080 -b:v 2M -b:a 256k -c:a libvorbis testoutput.mp4

This converts 3840x2160 30fps HEVC video to 1920x1080 30fps HEVC at almost twice the playback speed on my four-year old puny AMD Lucienne chip using the hardware for both decoding and encoding. With 4K HEVC output the speed is halved. (so roughly realtime) This chip is too old to support AV1. As newer chips are designed to handle 8K, they should be very fast with 4K material.

Image quality, compatibility and other factors would have to be researched if this is pursued, obviously.

Beware of https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/423 before buying AMD though. As you mentioned, this is a headache for a later time. Just making notes for whom might find them useful.