A Polymer element for flexible GIF playback
geelen.github.ioI kind of feel like .gif's as a format need to die, and this really demonstrates why, in my opinion. this page demonstrates a way to add stop/start abilities to a gif, as well as syncronized audio, which is literally what a video is but without all the ability for compression and support for more than 256 colors.
> which is literally what a video is
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.
All of those criteria are satisfied by a <video> element with the "muted" attribute set, plus a little bit of JS if you want to be able to pause the video when it's scrolled out of view or the user is looking at a different tab.
I don't buy the argument about stealing bandwidth. A 50MB GIF is just as much of a bandwidth leech as a 50MB MP4.
It's the image-hosting ecosystem. An animated image format needs to be accepted for upload by public image-hosts; it needs to keep its animated-image semantics when hotlinked and displayed "raw" by a browser; and it needs, needs to work when hotlink-embedded inside an <img src=""> element.
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.)
There's one specific case which is close to impossible with 'video' formats: referring to animated images in CSS. This is quite important for certain sites where users can modify CSS but not HTML.
Except that with a muted video, you need to communicate to your forum users that yes, they can upload a video, but it will be played back without sound. It's a different thing.
Can it autoplay? According to others in this thread, the answer is no, and that's pretty much the whole point of a GIF.
WebP matches the criteria. It just lacks widespread adoption. https://developers.google.com/speed/webp/faq?hl=fr#why_shoul...
If there was better tooling, maybe there might be a few animated WebP images out there.
Everything that http://gfycat.com/about says about GIFs is also true of APNGs. For things that are actually video (i.e. not a pixel-precise hand-drawn three-frame 32-bit image loop), using a video codec is just better in every way.
I agree that for most uses of GIF nowadays, a video codec would be superior, but better in every way? What about decoder overhead? For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less. A modern video codec is not at all trivial, and also is optimised for filesize, not CPU load.
> For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less.
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.
Glen gave an incredible presentation at Mountain West JS about his adventures doing cool things with gifs. He ended up with bpm syncing between gifs and music. You should definitely check out the talk when the videos get posted on Confreaks.
Alternatively, ditch GIFs entirely and use bandwidth-friendly and feature-friendly HTML5 video.
Not gonna happen until html5 can be set up to autoplay on mobile, and can be copy-pasted into your messaging app and will autoplay there too. I suspect there are other requirements, but much as I love the idea of moving away from gifs (for bandwidth at LEAST) there are a set of things that only gifs can do.
Side note: autoplaying html5 would be a massive annoyance, because html5 video can have audio.
>autoplaying html5 would be a massive annoyance, because html5 video can have audio
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.
You know mobile devices have audio controls right? And many android devices have a separated audio control for the browser/content and for the critical stuff (ringtones/notifications)
I had no idea, thanks!
I would disable any auto-playing audio technology on my Android phone; accessing the media volume control is such a huge pain in the arse - multiple taps and drags to rummage into the Settings and get to it.
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).
When you click the volume control, it brings up your ringer volume. At the right-hand side of the volume control is a settings button. That button will bring up all your volumes in a little floating bubble, so you can always change any volume in one click + 2 taps, and no "rummaging".
Hmm... I see no sign of this button on Android 4.4.2.
Huh, maybe it's a side-effect of some mod I'm running. Didn't expect that.
Give me an imgur of silent filesize limited html5 videos.
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.
http://gfycat.com/ has been gaining popularity on reddit lately. Links allow you to pick gif or html5 video.
No no no no no ;_;
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.
There are two things that seem to be necessary for an image host to be successful on Reddit: 1) be extremely fast (why people hate i.minus compared to imgur), and 2) don't provide any content that can have sound.
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).
This is the problem. Take your current code, host it on a different url (gifcrush?) and remove audio support.
Or just mute by default, but allow users to click to play sound.
It remembers your preferred volume, though that feature isn't very discoverable. You could set it to zero and all videos would start muted. Ideas on making that more discoverable?
> Ideas on making that more discoverable?
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.
I don't like "start off muted". You can upload proper videos to MediaCrush, why should they be muted?
How about a little balloon thingy on the volume UI that tells you it'll be remembered?
Perhaps have a separate url for "proper" video? Or an option to turn off the mute by default (as opposed to having it turn off automatically the first time you unmute a video.)
Or just require videos with sound to click to play. It's the combination of sound and autoplay that is annoying.
Require click-to-play on video with audio is a good idea.
You need a flashier, more colorful logo and a bright red BETA tag and a cute name and silly slogan and a login link and a moving number counter on the front page. gfycat looks alive, yours looks static and cold. mediacru.sh is hard to type and not as memorable of a name. Average internet user won't care about "open source" or features they don't know are missing.
Other than that, great work. You can do it.
Suggestions on a better name? Ours was suggested by a user, we're no good at naming things. Also, we had a beta tag for a while, but then we removed it because our product was feature-complete.
Lying about "bandwidth saved" doesn't sit well with me.
Names are really hard and I cannot suggest a better name. Since you provide more than just gif conversion, it is appropriate. The URL is a bit hard to type, though it does have some novelty to it. If you already have momentum you should just stick with it. I can only say that gfycat has a cute name that is more memorable, which is why they will gain momentum on a site like Reddit.
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!
MediaCrush is a great name, IMO. But mediacru.sh is gross.
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.
From a real user who uses gfycat all the time
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.
I've been rooting for MediaCrush from the beginning, but there are two things I prefer about gfycat:
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.
Thanks for the feedback. I'll put some thought into playing autoplayed videos only after the tab gets focus.
Ohh and i forgot /fetch like feature just like in gyfcat can be nice addition. http://gfycat.com/fetch/https://mediacru.sh/static/demo.gif
You can paste a URL from your clipboard into the home page of MediaCrush, providing a similar functionality. This also allows you to make albums of a bunch of URLs.
The last time I looked they did not seem to have a way to upload videos, only gifs, making it pointless to me since either way I was uploading the same thing. It looks like they've fixed this, but their UX still needs work.
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.
Nah man GIFs are my spirit animal
Which work differently in different browsers. Currently HTML5 shows up as nothing more than a green screen in FF and will do such until I reboot my machine. (Presumably this is a video driver issue, still annoying, Video elements work for me for awhile then will suddenly just stop working.)
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.
Don't forget an important reason gifs are rampant; they aren't chased by take-downs of copyright holders, while video snippets are much more exposed...
Can you save html5 video as file as easily as gif?
Do you know why HTML5 video is not as popular as gif?
Gif is easily copy-pastable, both by content and raw file URL. Thus help its viral spreading
nothing stops mp4 files from being easily copy-pastable
...other than software vendors and patents :/
Can you even autoplay HTML5 video on a page in, say, the platform I'm posting from, iOS 7?
No.
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.
Or more likely you get a gif to avoid degradation, and you spend 10x as much bandwidth.
The browser/tab/page should ask for permission to play video/audio, just like Chrome for mobile already does for other services (i.e. location)
Nope, has to be triggered by a user action (like a tap), and can only play full screen. Also, if you loop a video, the control bars flash up then fade away each time it loops.
gftcat baby!
I can understand the need for lowered bandwidth, but the need for better cross-browser and cross-platform support is more important.
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?
A pretty good idea but having an element for each frame can make loading gifs pretty memory intense (DOM-wise) compared to just using a single gif element, no?
For example loading a 3mb gif would be something like 330+ frame elements that are being looped.
But I like the idea though :)
Can anyone point me to a good desktop tool for creating Animated GIFs. I've used LICEcap but the "quality" isn't as good as other methods I've tried that involve more work.
GifCam is my tool of choice. http://blog.bahraniapps.com/?page_id=21
Sorry for off-topic.
@kogir
This thread demonstrates a small HN bug: I think the title is being encoded to HTML entities two times.
is there a reason why these are controlled via stylesheets and not turning on/off the images (performance?)? also what happens if i have a gif with more than 100 frames?
No good reason. I'm going to experiment with toggling the element's style instead of adding a class. But because of the way GIFs are rendered, that's an O(n) task on every frame (so is the CSS style recalculation, of course, but I think the browser's CSS engine will be faster than my JS).
i'm pretty sure a `opacity = 0`, and an `opacity = 1` in the same run loop should perform fine, but nevertheless very cool!
As a developer not familiar with Polymer (until now), I don't know what I was expecting, probably something like polystyrene that would play GIFs.
For people who wonders, the scene if from ghost in the shell.
I really like the pingpong effect, the speed and the music sync seems more gimmicky.
It's amazing the creative uses of GIFs the internet comes up with. It'll be cool to see what people do with this.
Automatic server side replacement with HTML5 video would be cool. Also resizing with auto-cache.
Does not work in Opera (the normal one) at all. Uncaught exception and some css errors as well.
This is incredibly cool. I'm definitely going to have some fun playing with this.
I would have loved this when I was running gifexplode.com (now owned by a spammer).
Oh my god it's YTMND and /r/AdviceAnimals IN A TAG!!!
This is absurdly cool.
Could this be useful to make a better gifsound.com ?
this is just so cool :D
Gif is the most horrible stuff that happened to the modern web. Wants animation?use the video tag and dont autoplay your sh|t.