Add support for WEBP Animated Images and Emojis
I recall hearing elsewhere that Discord's current libraries do not support animated WEBP. This is disappointing, as there's a lot of untapped potential in allowing WEBP-format emojis and images.
The GIF format is bulky and inefficient. Orthodox methods of encoding GIFs restrict one to a 256 color palette and 1-bit alpha (basically on/off transparency for every pixel, no variation). To get a reasonable file size from a gif, one must romance with frame dropping and color reduction to achieve a slim yet very ugly end result. However, WEBP images are encoded in a manner similar to YouTube videos (YouTube uses VP9 whereas WEBP is a fork of VP8). With WEBP, users won't need to sacrifice color fidelity or framerate for a tolerable product. Rather, they can simply decrease the bitrate to fill the file size maximum. WEBP also supports full alpha and RGB (even in lossy mode!).
The current upload limit is a bit of a squeeze for GIFs. WEBP compression could prove useful in overcoming that file size limit and creating beautiful high-quality animated images and emojis.
-
We sadly are not able to implement fixes upon request through the support portal. It would be best to head over to our feedback page and upvote existing posts, or create a new entry of your own. We really wish we could do more to help, but we thank you for your understanding.
Between this and having to sign in twice just so I can upvote something I agree with, Discord is truly coming off as a 🤡 lol
Upvoting threads is clearly not enough, but it's pretty much up to them at this point. We have the technology, they our nitro bucks. Yet nothing gets done. Absolute shame.
3 -
You must understand, we must implement more nitro crap instead of fixing existing issues.
5 -
LMAO, even guilded.gg supports animated WebP. Discord is absolutely pathetic.
2 -
WEBP PLEASE
0 -
Ok so I found a reddit post that suggest that it was actually possible in the past to send animated WebP images but that discord "fixed" it. https://www.reddit.com/r/discordapp/comments/7w5l1p/bring_webp_support_back/
0 -
I sent in a support ticket at the end of August with much the same info as Zipdox provided them about media.discordapp.com and img-ext-*.discordapp.com throwing HTTP 415 when requesting an animated WebP, though cdn.discordapp.com serves them just fine. Took them until today (Dec 23rd) to finally get back and tell me that this behavior is intended as "animated WEBP images are not natively supported by the app" and to come here...
Knowing how simple the container format of WebP is, there's literally nothing stopping them from rolling their own simple playback library (using libwebp to do the decompression of the actual frame data) client-side if that really is an issue. In fact, Google even provides fairly simple to follow documentation[1] on the container format or they could always use node-webpmux[2] to get the raw rgba for each frame on the desktop and use a similar approach for mobile.
For their upstream resizer... same deal, wouldn't be difficult to implement support.
[1] https://developers.google.com/speed/webp/docs/riff_container
[2] uses a webasm build of a minimal libwebp to handle image/frame decompression to rgba. Also shameless plug as the dev, hah.
0 -
Took them until today (Dec 23rd) to finally get back and tell me that this behavior is intended as "animated WEBP images are not natively supported by the app" and to come here...
They're full of crap. The app supports WebP, you can tell because when you add the file to send, it animates in the preview.
"It's not a bug, it's a feature"
1 -
The app supports WebP, you can tell because when you add the file to send, it animates in the preview.
Pretty sure the preview is just an <img> tag, so it's using Chrome/Electron's libwebp. I think their issue is that whatever library they're using for the fancy playback in the client doesn't support pausing WebP animations, so they can't do their play-on-mouse-over/pause-on-mouse-out trick that they do with GIFs. But the format is simple enough to the point that they could easily demux to an array of WebP frames and draw them on a HTML5 canvas without too much effort or processing time. Each frame has a 'dispose' flag (if set, draw background color -> draw frame, otherwise draw frame over existing canvas), a 'blend' flag (honor the frame's alpha channel, if any), a pair of x/y draw coords, width/height, and a duration (in ms). You can take that frame's image data and turn it into a "normal" WebP without too much effort.. you're just constructing a bare-bones header[1] and plopping the frame's data on the end without modification.
On the back-end, it gets trickier with supporting resizing. However, I don't think there's any large image manipulation library that wouldn't support resizing them by now. With a quick Google search, ImageMagick supports them. And that's just the first major library that came to mind.
[1] It's slightly trickier than this in practice. A frame can be either a VP8 chunk (lossy) or a VP8L chunk (lossless) and can also have an ALPH chunk (alpha channel) but only if the other chunk is VP8 since VP8L already contains the alpha channel. This gives you 3 combinations of possible headers. If there's no ALPH chunk, all you have to do is construct the 'simple' lossy/lossless header, which is all of 16 bytes of which only 4 would change (and there's only a single byte different between them besides). If there's an ALPH chunk, you have to construct the 'extended' header which is 26 bytes, of which 16 would change. After you have the header, you just concat the ALPH/VP8/VP8L chunks as-is (ALPH must come first in my experience, even though it technically shouldn't matter) and you're done.
0 -
You're way over-complicating things. All Discord does when you move your mouse away from the GIF is replace the img src tag with a link to a static image. Discord doesn't have to do any sort of demuxing or decoding themselves, that's all in the browser. They could just use existing libraries, like ImageMagick, for the resizing. Or just use libwebp. Or if they're extra lazy, just don't resize the image and pass it through.
0 -
They must be doing something special in the client with Tenor, then, as gifs from there pause/resume on mouse-out/over, but other gifs don't. I admittedly hadn't paid that much attention and never noticed it was only Tenor gifs doing it as they aren't generally obvious on the desktop app.
If all they're doing is swapping back to a static frame 0, then they have zero excuse not to support them at this point. Only other thing I can think of is some weird issue in the iOS and/or Android app preventing it for feature parity, but it's not as if they try too hard for that as-is. It's more likely purely a back-end issue with their resizer exploding when handed one for whatever reason and their inability or lack of desire to fix it, if even to only do better than throw 415 and let their client hit their servers with multiple guaranteed-to-fail requests any time one comes into view. As you suggested, simply passing the image through as-is would be better.. maybe only sending a static frame 0 if the dimensions are "too large".
0 -
Here we are, in 2022, still hoping for WebP support. The 10MB limit on animated avatars is making me suffer and Discord is just keeping on with their crappy GIF requirement that makes everything I upload at least 5 times larger than it needs to be. Please, Discord, for the sake of your own storage, let me upload WebP avatars.
0 -
There is progress
0 -
Other platforms support WebP, why doesn't this one?
0 -
I agree
0
Please sign in to leave a comment.
Comments
74 comments