Support for re-encoding media attachments

[PoneyClairDeLune]

Since Discord disallowed media access without HMAC which expires after several days, reuploading media attachments (and only media attachments) became pretty much required. To reduce disk usage on the homeserver, adding support for re-encoding non-WebP, JPEG XL and AVIF images into one of the three would be quite nice.

Re-encoding videos would take too much computational resources, those would be better re-uploaded as-is with size limits.

    media_patterns:
        enabled: true|attachments|false
        image_format: webp|jxl|avif
        image_lossless: false|true # setting to true will disable following quality settings
        webp_psnr: 56 # signal noise-based adaptive quality encoding
        jxl_distance: 1.5 # perception-based adaptive quality encoding
        jxl_progressive: false|true
        avif_quality: 95
        audio_format: aac|vorbis|opus # Use libfdk_aac instead of the built-in FFmpeg AAC encoder, the built-in one is horrible
        audio_bitrate: 160 # CVBR maximum bitrate, see https://kb.ltgc.cc/ltgc/encode.html#lossy-1 for details
        fallback_max_size: 26214400 # The non-Nitro file size limit, 25 MiB

[tulir]

Currently no plans to do unnecessary re-encoding, but I might consider in the future if it can be written in a sufficiently generic way (i.e. same code shared across all bridges, likely requires lots of bridge refactoring to share existing code first)

Reuploading attachments is not required, you can still use direct media access https://docs.mau.fi/bridges/go/discord/direct-media.html

[PoneyClairDeLune]

Is there a way to update older configs to include the newer keys? Cannot find the specified keys anywhere.

[tulir]

Configs are automatically updated when the bridge is updated (unless you prevented the bridge from writing to the config, then just need to manually update the config)

[PoneyClairDeLune]

Also, only media attachments require HMAC. Avatars, stickers, emojis and the likes don't, so a simple reverse proxy (the legacy approach) can still work, offloading the stress from the bridge whenever possible. Is it possible to bring media_patterns back for those purposes?

[tulir]

No, there's no point in having two methods when the new one works for everything

[PoneyClairDeLune]

But the new method will put additional stress on the bridge (which I'm still not sure where to point the reverse proxy to), with the legacy method able to offload the stress of non-attachment files to somewhere else entirely. That would be useful with a multi-server setup.

I'll see what I can do myself.

[tulir]

Parsing the mxc uri and then redirecting or proxying is hardly any stress. If you really want to, you could make a separate process that parses the media ID, handles any non-authed media itself and passes message media to the actual bridge, but that's likely some extremely premature optimization and won't have any benefits.

[PoneyClairDeLune]

Parsing the mxc uri and then redirecting or proxying is hardly any stress.

Well it is for non-redirecting media proxies, like dmr.ltgc.cc. dmr.ltgc.cc works for all homeservers that don't support MSC3860 by essentially fully proxy and cache the media files, which will introduce load on the network. That's where the legacy approach shines, as it allows to offload non-redirecting requests to an entirely seperate server.

e.g. mxc://dmr.ltgc.cc/avatars|385119943575863296|2b16816b990c330197a1502b840f1378.webp