Try MediaCrush. It's been on HN a couple times, and it also does the GIF->HTML5 thing, but it's open-source and has a lot of other benefits, like browser extensions and a nice API.
This post inspired me to make Imgur-to-gfycat[1][2], which uses the gfycat api to change <img> tags to embedded gfycat objects using gfycat's embed js, and changes anchors to /fetch urls. It's smart enough to change other anchors on a page if it's managed to resolve a gfycat url, and has a few hacks to work well with Reddit Enhancement Suite.
Been using this on reddit for the past couple of weeks, and it works wonders. It's especially handy on mobile, where bandwidth can be scarce.
But what has really struck me about the mobile experience is that using HTML5 video significantly improves the performance. This is important for GIFs/videos with a high resolution, which as GIFs would not render in real time on my phone (which has an S800, so I can only imagine what the experience must be like on other phones).
No, every mobile can process a 80ties picture format in tiny resolutions. 90ies computers could do that without a problem without any allocation an needed only a fraction of their cpu. Now we have quadcore cpus clocked at >1 GHz in our mobiles. It's just the saved bandwidth. And, btw, hardware allocation is a way overrated. There is a HEVC software implementation for the iphone. Just compare the complexity of HEVC to GIF.
The problem isn't the peak capability of the hardware: it's the strategy used to handle the content. In most web browsers animated GIFs are treated as images, which depending on the browser causes a whole host of potential side-effects (kept around or animating when offscreen, all frames kept in memory, etc.)
Video is video and is in general more properly streamed, evicted from memory, and halted when offscreen.
"... But in the worst case all your elements might be grouped into a single layer and the browser has to repaint every single element. And, when it’s done, it still needs to upload everything to the GPU. All of this is work occurs for every GIF frame..."
> No, every mobile can process a 80ties picture format in tiny resolutions. 90ies computers could do that without a problem without any allocation an needed only a fraction of their cpu
GIF's are really a nineties format (90ties??), the animation and alpha components weren't added to the standard until 1989, and adoption wasn't widespread until after then.
You're also overlooking the fact that you simply didn't get 4.5MB+ GIFs in the nineties like the example given because it would take ten minutes to download that on a 56K modem. I must resign myself to the fact some people never grew up with dial-up!
Animated gifs in 1995 were rather different to animated gifs now.
Imgur should do something like this when people are viewing gifs at the Imgur site itself (as opposed to viewing a hotlinked gif file), automatically replacing the embedded GIF file with a video. I imagine they could save a lot in bandwidth costs
GIF is a terrible format for video, but OTOH it's fairly lightweight for the browser for simple animation. Historically, playing video in the browser has required loading plugins, increasing the attack surface of the browser quite a bit, as well as inflating memory usage, increasing fragility, etc.
HTML5 video is also blocked by my flash blocker. Up until the latest version of Firefox, animated gifs were blocked by my use of image.animation_mode:once in about:config. Providing the element is clickable, the flash blocker makes it easier to play back the desired video on demand.
> but OTOH it's fairly lightweight for the browser for simple animation.
Historically, this hasn't been the case. Certain browsers used to process the entire gif up to the current frame when rendering a new frame, causing long gif animations to slow down progressively.
That idea originated from https://mediacru.sh/ - I read that article and considered doing my own "gfycat" site, it looks like someone had the motivation to go through with it after all :)
That makes sense - looks like WebM/VP8 support in browsers is a superset of Ogg/Theora support [1]. It would be silly to serve up Ogg/Theora unless it yielded better quality/bitrate (and I'm not up-to-date on how those two compare in quality at the same bitrate).
I love the naming scheme (AdjectiveAdjectiveAnimal) you have used, and wonder whether or not it could hilariously backfire (e.g. the Scunthorpe/Buttbuttinate problem)
This is like the old ImageShack and PhotoBucket days. The most important thing in deciding between all these competing services is figuring out whose links will still work five years from now.
I guess the pg question here would be: What happens, if imgur decides they want in on the action?
I cobbled together a similar service [1] a while back, but lost interest since I figured it wouldn't be profitable. FWIW the tech behind doing something like this is pretty simple, in my case a small shell script that uses imagemagick to dump the frames of the GIF as well as its framerate and then pipes into ffmpeg compiled with x264 and libvpx support.
This is excellent. I've been dealing with weather radar images lately, and they're all terrible animated gifs. This sizes them down nicely.
A service like this really needs to support oEmbed. The oEmbed spec is pretty simple and it would make this more widely usable by popular blogging platforms, and make it easier to use on responsive websites. http://oembed.com/
> I've been dealing with weather radar images lately, and they're all terrible animated gifs
actually, weather radar is an ideal use-case for GIFs. they have limited colors, only a few dozen frames which may need to be delayed for a few hundred ms.
you should really try compressing the gifs using something like gifsicle [1], you'll be astounded by the resulting size (use lzw compression), quality and performance (use a global color palette). it will surpass any video you can make.
what GIFs are terrible at is photographs and video. for the majority of graphics and animations they're awesome sauce.
You're correct: Radar is pretty well suited for a gif. But, it can still lead to 400kb images that are 150kb when h.264 video. For a mobile connection, that's worth caring about.
As someone who's messed around with gifs a fair amount, I recommend using Imagrmagik over gifscicle since Imagemagik offers far more features and can do a much wider variety of compression on gifs.
https://mediacru.sh
Prior discussions: https://news.ycombinator.com/item?id=6773039 and https://news.ycombinator.com/item?id=6189397
Open source: https://github.com/MediaCrush/MediaCrush
Browser extensions: https://mediacru.sh/apps
API: https://mediacru.sh/docs