-
-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GIF: 250 frames gifs exceed 30s processing limit enforced by CDN #1230
Comments
Hi @swistaczek! Oh, GIFs are a painful subject... There are multiple problems:
Considering all these points, the best way to optimize GIF processing is to not touch GIFs at all unless you resize them to a much smaller size. I know that some of our users just set As an alternative, I could recommend to convert animations to MP4. This produces much smaller files, and encoding to MP4 is much faster. However, this requires a special treatment of animations as you can't put video in the Also, though we host our demo instances of imgproxy on GCP ourselves, Google Cloud Run's performance is far from being the best on the market. It's enough for processing static images, but large GIFs may be a problem as you noticed. I tested processing of pretty large GIFs on Amazon's c7g instances, and it was able to chew GIFs that GCR chokes with. Sorry for not bringing any good news here, but GIF is a real headache 😓 |
Thank you for your comprehensive explanation and for presenting the available solutions! |
We also ran into gif performance issues and took the "just skip it" path. In our case, it was a fairly large (2k x 2k) 100 frame animation. We wanted to resize it to something more reasonable. At the time (and it's been ~1 year), it seemed like it was the memory pressure and that libvips was decompressing the whole thing into a very large filmstrip before resizing and re-encoding. In our use case, we typically want to resize them fairly small, so I'd expect the encoding time to be less of an issue. Also, we'd happily consider some monetary sponsorship to help move this along! |
Memory shouldn't be an issue since libvips doesn't decode the whole "filmstrip" into memory. Libvips stores only a single frame in the memory. I guess, the issue in your case is the resizing itself since imgproxy has to resize 100 2K images. However, things changed a lot in the last year: resizing was optimized with SIMD intrinsics and became much faster. |
BTW: can confirm that 3.21.0 is ~2x faster than 3.10.0 based on some fairly crude benchmarks. I also can confirm that, yes, the gif encoding speed is a major factor. Thanks @DarthSim ! |
Hey,
We are users of the pro version, and we noticed that resizing gifs that include 250 frames results in an extended processing time (based on longs, I assume it's above 60 seconds). Everything that ends up being processed above 30s will be terminated by GCP CDN.
Do you consider it a bug, or do you have any recommendations on how we could speed up the process to make it in the 30s CDN window?
testing image: https://cdn.fourthwall.com/offer/sh_8314a8a6-9ebd-4c7c-aca4-d20ab8eef781/8b8b7fc1-cb4e-4f7b-bc06-20d64326de5c.gif
The text was updated successfully, but these errors were encountered: