5 ms·
The Digital Materiality of GIFs
- LukeLambert 11y agoOver 60 MB of GIFs on that page according to DevTools. The Fight Club GIF alone is 9 MB. It's a terribly inefficient format, but I think a lack of free and open video formats (and editing software) is partly to blame for its meteoric rise. Also: video is harder to share and is typically recompressed on every upload, reducing quality.
- pessimism 11y agoGIFs are so stupidly easy to use and distribute that I sometimes can’t wrap my head around how convenient the format is. A while ago, I tried to be a good nerd and convert some GIFs to HTML5 video, and I crashed and burned pretty hard: https://ndarville.com/asides/webvideo/ https://ndarville.com/asides/webvideo/. I gained a new appreciation of GIFs that day. That said, it would be great if we got a compromise where browsers can load only the first frame of the GIF and play the reminder on click or touch to save all the loading and data—on both sides, really.
- pimlottc 11y agoIn the linked page, FOIT = "Flash of invisible text", when the user briefly sees empty space while the webfont is loading. I had to look that up. https://css-tricks.com/fout-foit-foft/ https://css-tricks.com/fout-foit-foft/
- pessimism 11y agoOh yeah, that’s just quoted text from the original article, which deals with the phenomenon: https://ndarville.com/blog/2015/12/04/web-fonts/ https://ndarville.com/blog/2015/12/04/web-fonts/. It’s not directly relevant to the aforementioned article. :)
- arthurfm 11y ago> That said, it would be great if we got a compromise Wouldn't a better compromise be to support MP4/WebM videos in the IMG tag? Videos embedded this way could play without audio by default (just like GIFs).
- Grue3 11y ago>Also: video is harder to share and is typically recompressed on every upload, reducing quality. Yeah, gifs being lossless is incredibly important for remixing. This is why we must get APNG going to really improve on GIF, instead of lossy video bullshit.
- AndrewUnmuted 11y ago> Also: video is harder to share and is typically recompressed on every upload, reducing quality. This is such a terrible standard. Using FFprobe, one should be able to determine a video's fitness for universal playback on HTML5 streaming technologies. Automating this process is easy. I've built several high-volume media processing automation platforms for video, and never has this been a challenge for me. Could you (or others) shed some light on why devs don't do this?
- g8oz 11y agoMaybe people like you should do some evangelizing of these techniques.
- AndrewUnmuted 11y agoI would love to! But I cannot imagine what I can say that would be unique. If people wanted to determine if a video were able to run universally on HTML5 streaming software, wouldn't they just use FFprobe and check the necessary stream metadata for compatibility upon output? Surely, these sites are using FFprobe already to determine other metadata within the video container files they receive from users? I have always run under the assumption that sites like YouTube want to further compress all video uploads so that they can implement proprietary functionality dealing with the video content and its other important business services (ad sales, user agent scraping, data collection, etc.)
- g8oz 11y ago>> But I cannot imagine what I can say that would be unique. It doesn't have to be unique - when evangelizing anything redundant repetition in a myriad of different ways is most important. You never know what will produce the light bulb moment in people. A video, a talk, a Github gist, a blog entry, a Stackoverflow answer, a Slideshare, a Hacker News comment that sparks curiosity..
- cbhl 11y ago> I think a lack of free and open video formats (and editing software) is partly to blame for its meteoric rise. GIF isn't a free and open video format either. The LZW algorithm used to compress them was patented in the 80s and didn't expire in most jurisdictions until 2003-2004. If we want to see more efficient unencumbered video coding methods used online, the answer is most likely is going to have to come from patent reform (making patent lifetimes shorter). The situation with H.264 isn't ideal if you're looking for purity, but licensed decoders are pretty readily available (most phones have at least one hardware decoder for it; Google/Microsoft/Apple pay to license the patents for Chrome/Windows (IE)/OS X (Safari); Cisco pays the license the patents for its binaries too).
- ardf 11y ago>57 requests, 28,189.09 KB I don't believe any new animated gifs should be made, except for animations such as pixel art. They are inferior in every way to html video. The success of webm on sites like 4chan are evidence that gifs offer no advantage in terms of portability, ease of sharing, or features.
- theseatoms 11y agoExcept videos carry along with them the presumption of audio content.
- detaro 11y agoBy whom? If you look at typical "image" hosters, you can't really tell outside of loading times if it is showing you a gif or a video. Are there browsers that do "clever" things with videos because they think there is audio?
- manmal 11y agoAlso, no auto-play (or at least, no inline display) on iOS.
- mercer 11y agoThat's a really big one for me. When I'm in 'silly consumption mode' I tend to just avoid anything that opens up as a video. I really wish there was an alternative to GIF for this use case though...
- arthurfm 11y agoInstagram's Android app plays (MP4) videos [1] without audio by default. You just tap it to turn the audio on. I don't see why others couldn't do this? [1] https://www.instagram.com/p/BA10BpWrbz9/ https://www.instagram.com/p/BA10BpWrbz9/
- chillingeffect 11y agoHehh heh: Did you only read the stats on loading the page :) Seriously, the whole entire point of the page is that, yes, GIF is technologically inferior and therefore wanted by no one, and therefore, allows incredible freedom of expression! That's information we can use to make better startups! Instead of trying to own everything and start from scratch with the most efficient artifacts like file formats, try to leverage from "inferior" techniques in order to allow the user-generated content to flourish!!!! I'm glad someone posted this!
- tbirdz 11y ago>GIFS are a dumb, limited file format, and in the end this is why they are important: >They do not belong to anyone. This may be true now, but for the majority of its lifetime GIF did not belong to everyone, due to Unisys's patent on LZW.
- eric_h 11y agothank goodness for expiring patents.
- derefr 11y agoI've saved the .webm of a converted "gifv" video on Imgur before, then reposted it to Tumblr. Works just fine—but the result doesn't quite get the same controls a Tumblr-converted gif does. Really, sites just need to have a way to differentiate these types of video uploads and treat them with looping-animation UX, rather than video UX. An easy solution would be to come up with an alternate extension for saving these videos, that other sites can recognize. This would be similar to, for example, the way iTunes knows to treat an MP4 container as an audiobook if it's an .m4b, or as a ringtone if it's an .m4r. Another solution (and better, in my opinion) would be an extra wrapper/container document format around a video file, prepending at least a new extra magic number to allow mime-type differentiation via libmagic. I'm honestly surprised that "gifv" isn't already such a container-wrapper document format. Note that such a format doesn't need to be recognizable as a video on your computer (although support probably would be added soon enough); it just needs to be able to be reuploaded to other websites. (You could also add an extra chunk to e.g. an MKV container that, when present, would change its detected mime type—but this would restrict gifvs to only ever being MKVs. Might not be a bad thing to standardize on a video container format.) Of course, the solution that requires no community buy-in is to just come up with a way to heuristically detect "silent short video file" on upload, and treat anything that fits those criteria as an animation rather than a video.
- sushisource 11y agoThis site was most certainly not designed with a fullscreened browser on a 30" monitor in mind