Hacker News Reader

Comment by falcolas | Hacker News Reader

Why gif, and not webm or mp4? Using gifs makes it only a bit more portable, but makes it consume significantly more bandwidth.

View on HN

I hate GIF as much as the next guy, but isn't this low color, minimal movement, animation something it can actually handle well?

you can embed them in a README and have them autoplay in a github-style service, I'm not sure you can link to a video file and have it work the same way.

afaik you can't, at least autoplay is not possible I think.

Hi, author of the Github repo here. I chose GIF because I designed this with the intent that the mini-screencasts be supplemented by text with the full list of keystrokes and an explanation of what's actually happening (specifically, I wrote this with the forthcoming Vim Stack Exchange site in mind). However, it would be trivial to replace byzanz-record with recordmydesktop and output real video files. That would defeat the original purpose of being a "mini-screencast," though, since it couldn't be ex. easily embedded in a blog post with no extra work for the reader.

It's not like we are using a dial-up modem anymore. We have plenty of bandwidth.

> We have plenty of bandwidth.

Smartphone users might not have lots of bandwidth and GIFs are incredibly inefficient compared to H.264 and WebM videos. Why waste bandwidth when you don't have to?

For example, the following GIF of a CD in a microwave is 8 MB, but when converted to a WebM by Gfycat is just 369 KB.

http://gfycat.com/GrimOpenDutchsmoushond

Off-topic: Strangely enough, it reported the same size for the MP4, but downloading it [0] shows that it's 1.1 MB. Inspecting it with `mediainfo` shows that it was encoded with the Baseline Profile, so that might explain the counterintuitively large size. (This profile is used for supporting low-powered devices, like phones, and results in a higher bitrate being used; 757 vs 252 Kbps in this case.) It seems that Gfycat just reports the WebM size either out of technical constraints, and/or for the sake of boasting higher amounts of bandwidth saved.

[0] http://fat.gfycat.com/GrimOpenDutchsmoushond.mp4

GyfCat reports the smallest file size between the both WebM and MP4. If the MP4 is smaller (or the WebM is smaller), it shows that in the textual information, regardless of video file presently playing. What's shown in the textual info is purely about the boasting in this case.

Still, that's definitely a file-size improvement over the GIF.

  GrimOpenDutchsmoushond.GIF:  8,714,192 bytes.
  GrimOpenDutchsmoushond.MP4:  1,137,305 bytes.
  GrimOpenDutchsmoushond.WebM:   378,363 bytes.

Ah, I see. Thanks for the explanation. That does make sense. And of course. I was just digressing. Your original point still stands.

Gifs like this can be pretty slow and gigantic, even with lots of bandwidth, since there's no compression. Other video formats just perform a lot better.

Also, think about viewing this on mobile networks, etc.

GIFs have LZW lossless compression which I'd expect would perform pretty decently on images of terminals, with their long runs of similar colors. Probably not nearly as well as a lossy video format but a far cry from uncompressed.

Edit: Oh, there are some actual numbers elsewhere in these comments.

Reply on news.ycombinator.com