6 ms·

Eh... Admittedly, this is one scenario where GIFs might be acceptable if kept to small little (not long) screencasts for the terminal (simple, solid colors). S

by glitch 12y ago

Eh... Admittedly, this is one scenario where GIFs might be acceptable if kept to small little (not long) screencasts for the terminal (simple, solid colors). Still, movies win out in (1) smaller file size and (2) control for easy pausing, reversing, and skipping forward. I hate it when I can't pause, go back, or go forward on instructional examples. Often I want to skip ahead to the relevant part, or pause so I can examine and play around more. I want to be able to pause it easily so I can type on the computer keyboard I'm working on. I want to be able to scrub the timeline back and forth to easily replay something I might have missed instead of having to watch the whole thing over again. All too often a part might go by too fast, and with the GIF you need to wait for the whole thing to cycle again in order to catch that spot in the instruction that went too quickly. And then that spot goes by too quickly again, and you just want to pause the bloody thing, but you can't because it's a GIF. And so someone tacks on a bunch of extra JavaScript to create a player for the GIF in order to add that control. At this point in the story, file size and simplicity have both been thrown out the window. But, I digress... The GIFs only serve a very limited purpose for VERY short screencasts so that it isn't an annoyance replay the whole thing again and again to catch something that was missed, etc. Even with that example as small as it is, https://gfycat.com/AcidicTangibleChupacabra https://gfycat.com/AcidicTangibleChupacabra reduced it: GIF: 408,744 bytes. WebM: 344,978 bytes. MP4: 151,047 bytes. That's a 2.7 to 1 compression ratio from the GIF to the MP4. And if you were specifically targeting "terminal recording" as a targeted scenario, you might be able to tailor the video compression settings for better quality and frame usage than GyfCat does. I'd rather get the 147.5 kibibyte MP4 over the 399.2 kibibyte GIF on my mobile. Especially when I'm looking up something on my phone in concrete and metal building with poor signal and non-accessible Wi-Fi. Using the HTML5 video tag, it serves WebM and MP4, so everybody should be happy. There seems to be an abuse of GIFs when most people's browsers support MP4 or WebM just fine nowadays. If your browser doesn't support that, then you probably want to stick to simple text instructions for the terminal instructional example anyway.

jsheard 12y ago
GIF has the advantage of (usually) being lossless though, your WebM example has a lot of colour bleeding and noise going on and not much of a filesize advantage to make up for it. https://i.imgur.com/O7E2WDq.png https://i.imgur.com/O7E2WDq.png Red text in particular will suffer a lot from compression algorithms designed for video.
- glitch 12y ago
  To me it doesn't seem that bad in this particular use case. Text is still perfectly readable and acceptable to me for its purpose in this context. Heck, you enlarged that image just to emphasize the visual artifacts around the characters. And at that, compression settings more tailored to this purpose could improve upon that. GyfCat uses "well-rounded" settings for their more general use case of converting any/all GIFs to video. Since this is for a very specific use case -- terminal screencasts -- you could probably improve on visual quality while maintaining improved (smaller) file size by tweaking the compression settings.
  - jsheard 12y ago
    Yeah there's certainly cases where video could be better, I was just being pedantic since you didn't mention you were comparing lossless and lossy methods. I thought your example looked very blurry at first glance but maybe it's just because I'm used to ClearType-style font rendering.
eknkc 12y ago
One advantage on mobile is that iPhone does not play inline video. So, if you want to have a small tutorial snippet you can play it within the page. Videos will go fullscreen.
- glitch 12y ago
  Honestly, if I'm reading terminal text like that example, I'd want it fullscreen on a small screen.
- acqq 12y ago
  That iPhone allows us to see the video only is a good feature actually.
KeyboardFire 12y ago
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. (This is just a copy/paste of my comment here: https://news.ycombinator.com/item?id=8982525 https://news.ycombinator.com/item?id=8982525, sorry if that's frowned upon here or such but I couldn't think of a better way to respond to both of you.)
- stephenmm 12y ago
  I would like to learn more about "Vim Stack Exchange site". Would you care to share any more info on it?
  - dugmartin 12y ago
    http://area51.stackexchange.com/proposals/80441/vi-and-vim http://area51.stackexchange.com/proposals/80441/vi-and-vim
godzilla82 12y ago
Dont mean to be rude, but comparison of file sizes of different video containers is pointless. You need to see what audio or video format each of the container files store. Then there could be changes in framerate (fps), frame size (like 640x480), compression quality (or inversely video bit rate), audio bit rate, image encoding (rgb for gif vs yuv420 ). Just changing the audio bit rate from 128kbps to 32kbps for a voice only video (i mean no music, like they have for tutorials) can reduce file size by 50%!
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- glitch 12y ago
  Yes, I agree with you in essence. I don't agree that it's pointless, though; I believe there exists some merit to it. The point of the comparison was more about a quick and dirty quick example with the compression implementation and settings used by GyfCat, which was a quick way to convert the GIF. There are obvious flaws in this approach. Many flaws, in fact. However, even with those flaws, it demonstrated my point (that the GIF sucks) as far as I'm concerned. More optimal settings and all sorts of possibilities for alternatives should be explored. But, I will leave that to someone else because that is outside of the intended scope of my intent for this comment.

by glitch 12y ago

jsheard 12y ago

GIF has the advantage of (usually) being lossless though, your WebM example has a lot of colour bleeding and noise going on and not much of a filesize advantage to make up for it. https://i.imgur.com/O7E2WDq.png https://i.imgur.com/O7E2WDq.png Red text in particular will suffer a lot from compression algorithms designed for video.

glitch 12y ago
To me it doesn't seem that bad in this particular use case. Text is still perfectly readable and acceptable to me for its purpose in this context. Heck, you enlarged that image just to emphasize the visual artifacts around the characters. And at that, compression settings more tailored to this purpose could improve upon that. GyfCat uses "well-rounded" settings for their more general use case of converting any/all GIFs to video. Since this is for a very specific use case -- terminal screencasts -- you could probably improve on visual quality while maintaining improved (smaller) file size by tweaking the compression settings.
- jsheard 12y ago
  Yeah there's certainly cases where video could be better, I was just being pedantic since you didn't mention you were comparing lossless and lossy methods. I thought your example looked very blurry at first glance but maybe it's just because I'm used to ClearType-style font rendering.

eknkc 12y ago

One advantage on mobile is that iPhone does not play inline video. So, if you want to have a small tutorial snippet you can play it within the page. Videos will go fullscreen.

glitch 12y ago
Honestly, if I'm reading terminal text like that example, I'd want it fullscreen on a small screen.
acqq 12y ago
That iPhone allows us to see the video only is a good feature actually.

KeyboardFire 12y ago

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. (This is just a copy/paste of my comment here: https://news.ycombinator.com/item?id=8982525 https://news.ycombinator.com/item?id=8982525, sorry if that's frowned upon here or such but I couldn't think of a better way to respond to both of you.)

stephenmm 12y ago
I would like to learn more about "Vim Stack Exchange site". Would you care to share any more info on it?
- dugmartin 12y ago
  http://area51.stackexchange.com/proposals/80441/vi-and-vim http://area51.stackexchange.com/proposals/80441/vi-and-vim

godzilla82 12y ago

Dont mean to be rude, but comparison of file sizes of different video containers is pointless. You need to see what audio or video format each of the container files store. Then there could be changes in framerate (fps), frame size (like 640x480), compression quality (or inversely video bit rate), audio bit rate, image encoding (rgb for gif vs yuv420 ). Just changing the audio bit rate from 128kbps to 32kbps for a voice only video (i mean no music, like they have for tutorials) can reduce file size by 50%!

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
glitch 12y ago
Yes, I agree with you in essence. I don't agree that it's pointless, though; I believe there exists some merit to it. The point of the comparison was more about a quick and dirty quick example with the compression implementation and settings used by GyfCat, which was a quick way to convert the GIF. There are obvious flaws in this approach. Many flaws, in fact. However, even with those flaws, it demonstrated my point (that the GIF sucks) as far as I'm concerned. More optimal settings and all sorts of possibilities for alternatives should be explored. But, I will leave that to someone else because that is outside of the intended scope of my intent for this comment.