A Polymer element for flexible GIF playback
geelen.github.io
geelen.github.io
People don't really want GIFs; what people want are filesize-limited, auto-playing-but-only-while-visible, auto-looping, and silent-by-default videos. Let's call these "animated images."
The problem is thus: you're designing a piece of forum software, and you're considering whether to allow people to embed various elements in their posts.
There's problems with allowing people to embed arbitrary videos: they can steal bandwidth, slow the browser to a crawl, make sudden noises, play to completion while the tab is in the background, etc.
But if you allow people to embed static images, then there's no additional consideration required in allowing them to embed animated images. Wherever a static image works, an animated one works.
Right now, there are two ways to allow people to embed animated images: either you allow .gif as an image upload format, and then display it without processing--or you allow videos, but do quite a bit of server-side processing (of the kind Vine and Facebook do) to make the result into an animated image.
If there was an adapter format -- some simple file format that:
1. referred to a video by URL (maybe it could be an HTML5 document whose root is a <video> element?), which would then be embedded in place of the metafile;
2. whose media type fell under the image/* hierarchy;
3. and for which the browser would automatically enforce "animated image" semantics,
then that format would be a perfect replacement for GIFs.
I don't buy the argument about stealing bandwidth. A 50MB GIF is just as much of a bandwidth leech as a 50MB MP4.
These are all things that are true of GIFs, and aren't true of any other video format. (And this doesn't even address the fact that many people use GIFs for the combination of animation and transparency, which <video> doesn't currently offer.)
The image-hosting ecosystem also naturally deals with the bandwidth-drain issue: image-hosts don't want their bandwidth stolen either, so they have a cap on upload sizes. By allowing just <img src=""> embedding, you naturally lean on the image-hosting ecosystem's bandwidth economics to protect your users.
By allowing arbitrary <video> embedding, though, you invite the nascent video-hosting ecosystem, which has achieved a different balance: far looser bandwidth limits, but far stricter caps on concurrent requests (e.g. the Dropbox-Public-folder model.)
Memory, maybe. But CPU?
I keep this snippet[1] at hand at all times, because pages with multiple animated GIFs peg my CPU and make my fan spin up for as long as they're open (even when they're in hidden tabs! even when the GIFs are scrolled off the screen!) This doesn't happen with <video> elements.
I think the problem is that web browsers never bothered to move GIF decoding/rendering/compositing to the GPU. It's especially bad if a GIF is animating while it has CSS image-scaling applied to it, which leads me to believe that--since the GIF "codec" must be re-applied on each frame--the browser doesn't cache the decoded frames, and thus can't cache the scaled decoded frames.
And those with bandwidth caps are doubly grateful for that. Once for not being opted into wasting bandwidth, and again for the smaller file size if they choose to use it.
Side note: autoplaying html5 would be a massive annoyance, because html5 video can have audio.
NB: the hardware controls only set the ringtone volume, unless you're too late and the phone is already playing media†.
†hopefully - sometimes the hardware volume buttons still don't control media volume even when media is playing.
(You can get widgets to control the various volumes, but I've not found one I really liked).
This could be browser configurable. "Allow videos with audio to autoplay". Won't be worse than the flash ads with audio I run across regulary which autoplay audio.
Gif is easily copy-pastable, both by content and raw file URL. Thus help its viral spreading
...other than software vendors and patents :/
No, youtube or vine don't cut it, I want to be able to give people a link to a raw file that they will automatically know to be small and silent.
It also seems that there is a discrepancy in permissible length with them. They will allow you to upload gifs that are longer than 15 seconds, but not videos that are longer than 15 seconds.
I made this website, use it instead: https://mediacru.sh
It also does HTML5 GIFs and has a fallback for phones and such. BUT it's also open source, much higher quality, more featureful, and supports more than just GIFs.
Even though MediaCrush and gfycat started around the same time and MediaCrush is much better, I can't seem to get people to use it more. I guess our users are less evangelical.
Other than that, great work. You can do it.
Lying about "bandwidth saved" doesn't sit well with me.
The beta tag is a big red marketing thing that makes it feel like a Google service and makes people feel like they are using something cutting edge. It looks good. People like certifications and symbols and affiliations and logos, it makes things feel official and valuable. You can always be in beta as you are always adding features. You could put a bunch of Github and Open Source and EFF logos then if you want to play up the open source aspect, most average Reddit users won't care but it will look cool.
The "bandwidth saved" thing is a gimmick and nobody will even think about what it means, it is just a big moving number on the homepage, like the storage space thing on GMail. It makes it feel alive and valuable. So don't focus on the fact that it's useless, you'll get frustrated. Try to learn from the marketing significance of it.
I think the theme switcher isn't too important. Just make it more stylish and keep pushing, add account management, and you will surely continue gaining momentum. You have something great!
For the record, I disagree with the BETA tag and the "bandwidth saved" thing. The real issue is that it's easier to upload to gfycat.
I don't know what your service speed is like, but you break that second rule which seems really important to Reddit. Redditors don't actually seem to want "more featureful" in a n image host. Gfycat has an unquestionably clear sole purpose: to be a faster "GIF" host (by providing an HTML5 video option).
1. Start off muted. 2. If the user views a video that has sound and is muted, put some small verbiage under the video saying it's muted.
How about a little balloon thingy on the volume UI that tells you it'll be remembered?
Or just require videos with sound to click to play. It's the combination of sound and autoplay that is annoying.
Your site requires some nits & bits of polishing here and there. Make it more fancy.It looks like any other github project. The page of gfycat is very minimalistic,only fetch url and upload file no fancy drag an drop or documentation or api stuff. Talk to some 4chan & reddit users for some pointers ,they will gladly(I have done my part ;)) Sorry for the harsh word.Nothing but suggestions.
1) Their scrubber handle is REALLY slick and easy to use.
2) I never have to worry that gfycat will make noise if I blindly open a link in a new tab.
If you could give me a cookie so that mediacrush links will ALWAYS start muted for ME, no matter what the author or URL say, I'd be much happier.
And something neither one of you get right (I think):
If I open five animated GIFs each in their own tab, the images don't start playing until I switch to that tab. So once I make a given tab active, I get to see the animation starting from the beginning. Both gfycat and MediaCrush start playing the animation right away, so when I eventually make that tab active, I have to rewind to see from the start. (Or, in your case, click play if autoplay is off. Which isn't as bad but still less convenient than "play on focus" that I get with animated GIFs.)
Anyway, my $0.02. I care about quality and open source, but the average Redditor/4chan'r cares not about such things.
Flash keeps on working. Well mostly, as well as it ever has worked.
Even better are pages that see that I have FF and just assume they can feed me video, not allowing me to fall back to Flash if I have bothered to go to about:config and disable all relevant HTML5 settings.
For example; Github README files, we can insert a GIF of a screencast, but obviously we can't run our own JS, CSS, or embed video. There is where GIFs are the only option, unless of course you want to redirect to an external site, but for small repos it's overkill.
The other issue, is saving and sharing. How many people have a folder full of GIFs? Has anyone tried saving a GIF from the polymer element? As you can imagine, it saves a frame, which makes it useless. Sure, you can add a button to Download a compiled version or the original, but why should we add custom controls when everyone knows Right Click Save As?
For me, cross platform compatibility without requiring an extra file (HTML to actually play) per GIF if more important than filesize and bandwidth. Bandwidth is obviously costly, but maybe the issue is knowing when to create a GIF and when to create a video instead, why is the issue with the playback why not emphasise on the creation size?
For example loading a 3mb gif would be something like 330+ frame elements that are being looped.
But I like the idea though :)
@kogir
This thread demonstrates a small HN bug: I think the title is being encoded to HTML entities two times.
I really like the pingpong effect, the speed and the music sync seems more gimmicky.