Poor quality of ffmpeg aac encoder

### Describe the current behavior

Hello.
I understand you can not give up ffmpeg aac in favor of fdk (-vbr 5) or at least faac for licensing reasons, but at least change the CBR mode to VBR, according to my tests this will greatly improve quality. The bitrate will be about 200 kbps:

`-c:a aac -b:a 256k`

V

`-c:a aac -q:a 2.3 -cutoff 18000`

One more thing:
Right now the peertube encoder does not touch (does not transcode) the aac stream provided by user, only in the mp4 container. So the user can provide his own quality aac (encoded by fdk or commercial qaac).
But if the aac is in an mkv container, peertube always re-encodes the audio (because it can't detect the bitrate of aac from the mkv container?). You could also make aac sound not re-encode in big cases.

You would have to change something. ffmpeg aac 256k CBR used now is terrible.
Just listen with headphones where there is a lot of high frequencies.
Actually, not only VBR mode improves quality (it reduces encoder bugs), but also the -cutoff frequency filter.
YouTube has always cut off AAC at 16000 Hz.

### Steps to reproduce

-

### Describe the expected behavior

-

### Additional information

* PeerTube instance:
* URL: https://peervideo.ru/
* Version: 5.0.1-nightly-2023-02-24

Start by tracing PeerTube's audio transcoding path and the ffmpeg invocation, comparing how AAC streams are handled in MP4 and MKV containers. Done means the project has an agreed AAC quality policy, avoids unnecessary re-encoding where appropriate, and verifies the behavior with regression coverage.

Written by the indexing model from the issue text.