a good media server doesn't need to transcode in any case, it just pass a single stream (even it has a lot of layers) to the public. But there are 2 criterias: do it instantly (no delay) ... do it reliable (no packet loss). so we need good methods for that... some kind of FEC (forward error correction), packet loss compensation (like done in haivision SRT) and a scaleable format (like done in AV1 or H265). Don't let the media server do all the work, do it yourself, but the media server has to support it.... and for sure needs to be able to cluster (origin/edges)

Transmission reliability is a protocol feature and is implemented in all protocols supported by MediaMTX:

• RTMP is TCP-based, therefore there are ackowledges and retries
• RTSP has packet reordering
• WebRTC has packet reordering, negative acknowledges and retransmission
• HLS is HTTP-based, therefore clients can retry requests indefinitely

SRT is a good protocol that will be added to the server in the near future, but it has no major advantages over WebRTC in terms of reliability (on the server side).

The server can achieve both no delay and no packet loss since it is not a player, it doesn't need to respect timing since it doesn't the decode stream, it just routes packets to players. Therefore, as soon as a packet is received correctly, it is sent out. If there are missing packets, packets are put in a queue until gaps are filled or the queue is full.

It's the client / player that has to perform the choice that you mention (no delay vs no packet loss), and this is usually achieved by setting the buffer size.

Mostly, but sometimes we do video as well to stream to Youtube or Facebook. EDIT: But this is on a different PC that handles the video.

Currently we use Ovenmediaengine for video and audio (MPEG-4 AVC ABR 1080p, 720p, 360p and AAC audio, also transcoded live to Opus for use in WebRTC), because we can ingest SRT via FFMPEG, gstreamer or OBS and also push RTMP to youtube or facebook.

In parallel, for audio we use the good old icecast2 servers (FLAC, MP3, AAC+V2 formats). Configured well, they can also achieve latencies of about 4-6 seconds and can be played on every custom webradio hardware (that was the major issue. It must be playable out of the box on custom hardware). The other issue was, that we didn't find any audio streaming server, that can handle FLAC format (24Bit/96KHz Hi-Res lossless audio streaming).

Relatively new we currently test mediamtx for use with AV1 video on webrtc, but my other post shows that the audio quality for ingesting webrtc is not configurable, which results in pretty good video, but very poor audio quality. Some improvements need to be done on the webrtc ingester. Currently mediamtx is the only open source server i know, which provides AV1 streaming in webrtc.
If you like to use mediamtx, you can ingest RTSP via FFMPEG, gstreamer or vlc. OBS and various other applications only seem to work properly with RTMP protocol, even they use FFMPEG libs. On listener (client) side you can use browser with video-tag or javascript players for ll-hls. I also tested RTMP streaming on a enigma2 satellite receiver without problems. Webrtc is also working fine, but you have to transcode aac to opus (can be done with FFMPEG on mediamtx server by calling ffmpeg in config file). What mediamtx cannot do directly, is transcode H264 for example (ABR video streaming).

I was considering using liquidsoap (which has ffmpeg support) or just plain FFMPEG. But liquidsoap has some nice fallback features for if the streaming breaks down.
EDIT: The 2 things I need are streaming and recording to have a backup of the stream.

I was considering using liquidsoap (which has ffmpeg support) or just plain FFMPEG. But liquidsoap has some nice fallback features for if the streaming breaks down. EDIT: The 2 things I need are streaming and recording to have a backup of the stream.

Well then you should really have a look at icecast2 and butt as encoder (https://danielnoethen.de/butt/).
Encoding with FFMPEG is very nice too, but butt can also update metadata dynamically, which might be an issue too. Icecast also supports fallback mounts and clustering. Most webradios use it as primary streaming server.

We currently use icecast and butt on Windows, but I'm testing out a Linux server and butt has some compatibility issues with Jack2.

We currently use icecast and butt on Windows, but I'm testing out a Linux server and butt has some compatibility issues with Jack2.

You can use butt with pulseaudio and create a virtual pulseaudio device for jack2. Just configure pulseaudio to use maximum capability of sample rate.
For creating a virtual device, you can use this command: pactl load-module module-jack-source client_name=playout connect=no
Then you can connect butt to the "playout" device.