TL;DR: When the user selects a video for upload, if the file has a size greater than what is accepted by the remote server, Tusky could offer to compress (i.e. re-encode) the video on behalf of the user so that the uploaded file size is acceptable to the remote server.
Video captured on (at least Android) smartphones tends to be stored in very big files, with very little compression. One example I came across recently was a 24-second video (1088x1440 pixel, H.264) that took 88 MiB of storage, which got reduced to 9.4 MiB when recompressed with ffmpeg[^1].
[^1]: $ ffmpeg -i input.mp4 -preset veryfast -crf 18 output.mp4, took about 15s on my OnePlus Nord phone, running on Termux.
Ideally such a task would be completed server-side, but for Mastodon this seems to avoided since it's a resource-intensive process (source), which is fair enough.
This means that the task of compressing big video files is delegated to the user: for tech-savvy users knowing what to do might not be so much an issue, but for other users this creates a barrier; in both cases, it's an extra step that takes time and effort.
As such, having the client (Tusky in this case) take up this task during media upload would vastly improve user experience for every user uploading a video file that's larger than the instance file size limit.
Ideally, the user would be informed and asked if this task was acceptable before compression was done (maybe they don't want to have the uploaded file modified, or they're low on battery, etc...).
A major downside of this is adding a fair bit of complexity to the client, likely by including an extra dependency to handle video re-encoding.
As a weak point of comparison, other social media apps allow for upload of big video files, which get compressed at some point, with the upload being seamless for the user. Of course, this isn't a fair comparison, as the resources behind corporate-owned social media are orders of magnitude larger than even the larger Fediverse instance or any of the client apps.
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
Tusky could offer maybe 3 kind of resize based on file size: 1/4 1/3 or 1/2 the size of the original video.
Details about original video can be discovered with ffprobe.
TL;DR: When the user selects a video for upload, if the file has a size greater than what is accepted by the remote server, Tusky could offer to compress (i.e. re-encode) the video on behalf of the user so that the uploaded file size is acceptable to the remote server.
Video captured on (at least Android) smartphones tends to be stored in very big files, with very little compression. One example I came across recently was a 24-second video (1088x1440 pixel, H.264) that took 88 MiB of storage, which got reduced to 9.4 MiB when recompressed with ffmpeg[^1]. [^1]:
$ ffmpeg -i input.mp4 -preset veryfast -crf 18 output.mp4
, took about 15s on my OnePlus Nord phone, running on Termux.Ideally such a task would be completed server-side, but for Mastodon this seems to avoided since it's a resource-intensive process (source), which is fair enough. This means that the task of compressing big video files is delegated to the user: for tech-savvy users knowing what to do might not be so much an issue, but for other users this creates a barrier; in both cases, it's an extra step that takes time and effort. As such, having the client (Tusky in this case) take up this task during media upload would vastly improve user experience for every user uploading a video file that's larger than the instance file size limit.
Ideally, the user would be informed and asked if this task was acceptable before compression was done (maybe they don't want to have the uploaded file modified, or they're low on battery, etc...).
A major downside of this is adding a fair bit of complexity to the client, likely by including an extra dependency to handle video re-encoding.
As a weak point of comparison, other social media apps allow for upload of big video files, which get compressed at some point, with the upload being seamless for the user. Of course, this isn't a fair comparison, as the resources behind corporate-owned social media are orders of magnitude larger than even the larger Fediverse instance or any of the client apps.