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.
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.
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).
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
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?
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.
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.
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.
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.
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.
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.
77 comments
[ 2.8 ms ] story [ 110 ms ] threadso fuck gif, really. ive been annoyed by this for a while. even saw sites that find it smart to replace flash videos with gif.
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.
I was certainly using it in the early 90s.
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.
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).
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..."
http://www.html5rocks.com/en/tutorials/speed/animated-gifs/
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.
Six different videos?? Anyone knows more about html5 video fragmentation and why six videos are required?
If I had to guess, they're probably encoding MP4/H.264, WebM/VP8, and Ogg/Theora.
> Note that there are 6 separate encodings -- mp4, webm, and reduced mp4, for forward and reverse
[1] http://beta.caniuse.com/#search=video
other than that: awesome
It can confuse users that save files to not actually have a gif, though.
It can confuse users that save files to not actually have a gif, though.
I guess the pg question here would be: What happens, if imgur decides they want in on the action?
https://www.reddit.com/r/gfycat/comments/1s0fip/extension_fo...
https://chrome.google.com/webstore/detail/autogfy/aleldfepmn...
Enjoy!
https://github.com/Imdsm/AutoGfy
Feature request: I would like to be able to use some kind of wildcard/regex system to select which websites or domains it works on.
[1] http://www.businessinsider.com/imgur-is-officially-bigger-th...
"Imgur is also profitable thanks to its paid Pro subscriptions and deals with advertisers."
http://mr-andersen.no/div/send-to-gfycat.xpi
Edit: If you want to inspect the source, download the file and rename the extension to zip.
Edit2: You may have to download the file and drag it into Firefox in order to install.
https://addons.mozilla.org/en-US/firefox/addon/gfycat-firefo...
Added similar functionality as imdsm's Chrome version, https://news.ycombinator.com/item?id=6976059
https://addons.mozilla.org/en-US/firefox/addon/gfycat-compan...
https://github.com/honestbleeps/Reddit-Enhancement-Suite/pul...
Source here: https://github.com/engstrom/GfyFetcher
[1] https://chrome.google.com/webstore/detail/imgur-to-gfycat/id... [2] https://github.com/STRML/Imgur-to-Gfycat
There is no other reason not to use video.
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/
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.
[1] http://www.lcdf.org/gifsicle/
Edit: It uses ffmpeg
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
[1] http://www.qwikgif.com/