Change media upload limits and remove client-side resizing#23726
Change media upload limits and remove client-side resizing#23726
Conversation
163acaf to
d25b6b5
Compare
|
If this goes through, you can also remove the |
|
Can the media resizing process forks be niced to keep them from swamping the system as heavily? Larger media sounds great, but I already see occasional media cause massive CPU spikes on my personal instance. Communicating the low priority of conversion to the cpu scheduler would help a lot. |
|
This will cause an increase in RAM, CPU, and storage usage on all servers, so we really need to be careful about such changes. |
True, although we could use |
|
Storage is cheap, so I'm fine with the increased image/movie size, but the effect Client-side resizing being removed will have on smaller instances needs to be considered. I'd rather you set a standard and transcode on the iOS app for example to a known universal standard... Our CPUs are going to cry... but making 8 accounts and uploading a large 4K video will most than likely result in a DOS. |
|
This is a welcome change for art instances such as mine. However, I noticed that this upcoming change increases the max video resolution to 4K, but image resolution is increasing to only 2K for some reason. Is there a reason for this? Why would video media get to have more pixels when previously both video and images had the same FHD limit image format? Ideally the image size should be bumped up to at least 4K, just like video. Having more pixels is important for artists since it is more common for images to be entirely graphical (eg illustrations, comics) than it is with videos which is usually captured. Also, since there is no more client-side resizing, a higher pixel limit will keep the server's CPU/RAM usage down since the server won't have to do resizing of images as often. |
|
Bumping the image pixel count limit is very RAM-costly due to the tools we use. Until we ditch ImageMagick, I don't think it's wise to increase the allowed input image pixel count at all. #23322 touches on this and actually allows larger output images than the current PR (that means a potential storage cost increase, but not a RAM or CPU one unlike the current PR) |
|
I think that the max size should only be 100MB, as that’s the upload limit on some CDNs. |
d25b6b5 to
f5112bf
Compare
|
Changed video size limit to 99 MB, target dimensions for images to 4K (same as videos). The changed image matrix limit means the max. ImageMagick memory usage will be about 847 MB. |
13bbdf9 to
e9ede10
Compare
There was a problem hiding this comment.
Can I suggest we include slightly higher vertical resolution to include DSLR images Aspect Ratios
app/models/concerns/attachmentable.rb
MAX_MATRIX_LIMIT = 33_177_600 # 7680x4913px or approx. 847MB in RAM
app/models/media_attachment.rb
original: {
pixels: 9_434_880, # 3840x2457px
file_geometry_parser: FastGeometryParser,
}.freeze,
For media attachments, the limits become: - Images: - Upload size: 10 MB to 16 MB - Target dimensions: Full HD to 4K - Processing limit: 4K to 8K - Videos: - Upload size: 40 MB to 99 MB - FPS limit: 60 FPS to 120 FPS - Processing limit: Full HD to 4K For link preview cards, the limits become: - Upload size: 1 MB to 2 MB Client-side resizing is removed to avoid low-quality output
e9ede10 to
8bcc337
Compare
…client-side resizing)
…astodon#23726)" This reverts commit 9bda933.
|
I get occasional complaints from users about not being able to upload something because its resolution is too big. I understand javascript based image resizes are not as efficient nor as high quality but surely it's preferable over just showing the user an error? No other platform (Twitter or bsky) seems to have issues with the image a user complained about today (which is 5849x5944) which downgrades their experience using Mastodon |
参照：mastodon#23726 (cherry picked from commit 70fb440)
参照：mastodon#23726 (cherry picked from commit 9817d2a)
参照：mastodon#23726 (cherry picked from commit 9817d2a) (cherry picked from commit e69c3a9)
参照：mastodon#23726 (cherry picked from commit 9817d2a) (cherry picked from commit e69c3a9) (cherry picked from commit 41df02b)
参照：mastodon#23726 (cherry picked from commit 9817d2a) (cherry picked from commit e69c3a9) (cherry picked from commit 41df02b) (cherry picked from commit eaed58e)
For media attachments, the limits become:
For link preview cards, the limits become:
Client-side resizing is removed to avoid low-quality output. The max. RAM usage of ImageMagick becomes 847 MB.
Fixes MAS-47