Modern Apple devices like to h265 encoding when sending video, which makes sense as it's modern and space efficient while retaining high quality.
Unfortunately, h265 has a ton of licensing red-tape around it, and the result is basically no devices nor browsers, other than Apple's, have any support for it.
This is pretty annoying if you use a web-based Matrix client (e.g. Element) as you end up needing to use an external video player like VLC to view videos, rather than in app.
This PR adds the ability to automatically re-encode video attachments into whatever ffmpeg on the bridge host machine supports.
The functionality is disabled by default in the example-config.yaml and I included example args for x264 re-encoding that runs pretty quick on my Monterey VM. I expect that it would work significantly better on real hardware with physical codec support. I was originally going to do webm, since it's "truly open", but it was a bit unreasonably slow no matter how I configured it.
Modern Apple devices like to h265 encoding when sending video, which makes sense as it's modern and space efficient while retaining high quality.
Unfortunately, h265 has a ton of licensing red-tape around it, and the result is basically no devices nor browsers, other than Apple's, have any support for it.
This is pretty annoying if you use a web-based Matrix client (e.g. Element) as you end up needing to use an external video player like VLC to view videos, rather than in app.
This PR adds the ability to automatically re-encode video attachments into whatever
ffmpegon the bridge host machine supports.The functionality is disabled by default in the
example-config.yamland I included example args forx264re-encoding that runs pretty quick on my Monterey VM. I expect that it would work significantly better on real hardware with physical codec support. I was originally going to dowebm, since it's "truly open", but it was a bit unreasonably slow no matter how I configured it.