[FR]: Improvements regarding transcoding flexibility and performance roadmap

Description

Hey @phanan, once again, love this project. I have a few ideas for additional features I'd like to contribute and I'd like to get your feedback/blessing first :)

My entire library is in AIFF for syncing with DJ software. On-the-fly transcoding has become a pain point for uncached tracks, and converting my entire library ahead of time isn't a super practical option. The "fast" mode that just landed helped, but I often skip around in my library (next, next, next) and waiting for the transcode to complete, sitting in silence, is still not the best experience.

Proposed features (ordered by priority):

1. Eager preload/transcode the next X tracks in the queue (configurable).

Look ahead in the play queue and queue a transcode for each one, that way next track is seamless after the transcodes have completed, and it will still be seamless if I skip a track or two. My thought is another env variable to not change behavior for existing users:

TRANSCODE_PRELOAD_DEPTH=0 - between 0 and 10, 0 is disable, current behavior.

I believe the code currently does this for the next track in the last 30s of playback, which doesn't help if you are using the "next" button before that point (as I often am).

1. Web UI for adjusting transcoding settings.

Currently everything is adjusted via env vars (including the fast mode which just landed), which is quickly going to get messy, especially if we add support for different codecs later on.

Under Manage > Settings - add a new section for transcoding configuration to configure in the web UI.

We'd need to consider whether to still support the env vars, and if so, which takes priority (env vars or web UI).

1. Support different codecs

Opus has some advantages in file size/quality department. Allegedly the coders in ffmpeg for it are better too (I have not benchmarked this, just gathered from random internet discourse so take with a grain of salt). It would also be nice to re-introduce mp3 support as it will help with the next feature (segmented outputs).

We'd wire this up as an option in the admin settings too along with the other transcoder settings. Would need to think through mobile interactions. Willing to dust off my Flutter skillz from college and benchmark a few things on iOS... Though probably v1 would be to keep the mobile path the same, and bake in support for different codecs later.

1. Segmented Streaming/Transcoding

Enable streaming while transcoding, instead of having to wait for the transcode to finish before starting the stream. AFAIK, WebM + Opus is able to handle this well. I believe you can also do this with HLS and MP3 or AAC but I'm less familiar with this technique.

1. Automatically prepare/transcode newly added music

May be unnecessary depending on the performance of 4 if implemented, but would solve the performance issues pretty well.

1. Configurable concurrency for transcoding

AFAIK ffmpeg does most audio encoding in a single-thread. We could rethink the queue to transcode multiple tracks at a time to parallelize/speed up the effort. We would do this while dynamically being aware of system resource utilization, to not freeze up or slow down the app.

1. Create "playback profiles" for different scenarios

Scope includes mobile. e.g. lower bitrate on cellular, or remote network, high bitrate/lossless on local network...

1. Transcode cache limits and least-recently-used evicition

2. Additional transcode web UX for debugging and visibility

I believe Plex does something similar? Maybe under the management area, we can display a log of recent transcodes, failures, total cache utilization, free space, etc.

Additional information

No response