Mkcast – GIF terminal screencasts with key presses overlaid | Hacker News Reader

Mkcast – GIF terminal screencasts with key presses overlaid

github.com

304 pointsgnocchi40 comments

This is great...now I'll have to find a spare laptop to load Ubuntu on. I'm on OS X and have been attempting to write Unix tutorials...I don't like doing videos, so I use Quicktime to do a window recording, save it, and then send the file to the "gifify" utility (https://github.com/vvo/gifify), which besides wrapping around ffmpeg to do the conversion, uses the giflossy fork of gifsicle to optimize the image:

       gifify screen.mov -o screen.gif --resize 800:-1

example GIF:

http://www.compciv.org/files/images/cli/echo-redirect.gif

It's better than embedding video clips for such short snippets, but being able to show keystrokes would be even better (Quicktime does record mouse button presses)

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 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.

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, sorry if that's frowned upon here or such but I couldn't think of a better way to respond to both of you.)

I would like to learn more about "Vim Stack Exchange site". Would you care to share any more info on it?

http://area51.stackexchange.com/proposals/80441/vi-and-vim

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%!

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.

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

Red text in particular will suffer a lot from compression algorithms designed for video.

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.

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.

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.

Honestly, if I'm reading terminal text like that example, I'd want it fullscreen on a small screen.

That iPhone allows us to see the video only is a good feature actually.

I don't know... wouldn't it make more sense to parse a script(1)-log with javascript? There's some code to do that already:

  https://github.com/josch/scriptreplayjs
  https://blog.mister-muffin.de/2011/07/05/scriptreplay-in-javascript/

And another project that uses a similar approach (but as far as I can tell, doesn't use plain script files):

  https://asciinema.org/

One benefit with scriptreplayjs is that you could just download the script-file and play it pack with script/scriptreplay (the former under BSD (and Linux?), the latter (only) under Linux, if I read the man-pages right).

And the fact that the script is (mostly) text -- so it should be easy to make it copy-pasteable...

I suppose it should be possible to patch either project to overlay key presses...

https://www.freebsd.org/cgi/man.cgi?query=script(1)&sektion= http://man7.org/linux/man-pages/man1/scriptreplay.1.html

https://packages.debian.org/wheezy/bsdutils

[edit: Might be cool to hack this tool to work with regular script logs -- so it could generate gifs, or other tools could be used for js "playback"? ]

Unfortunately, script is probably not usable here:

From the github page:

  specifically, I wrote this with the forthcoming Vim Stack Exchange site in mind

From the script docu:

  Certain  interactive  commands,  such  as  vi(1), create garbage in the typescript file.
  script works best with commands that do not manipulate the screen, the results are meant
  to emulate a hardcopy terminal.

Ah, I missed that. Apparently the answer to script's limitations, is ttyrec:

http://0xcc.net/ttyrec/index.html.en

There appear to be many players, eg:

https://github.com/oliy/ttyplay

See also:

https://github.com/jedi4ever/ttyrec.js

Apparently vim-sessions should work:

https://github.com/jedi4ever/ttyrec.js/issues/1

There's a site devoted to tutorials based off of ttyrec:

http://playterm.org/

Or, for just vim, Replay.vim: http://www.vim.org/scripts/script.php?script_id=3216

Other than that, I'm inclined to have a look at op's code to see if one might break out the gif-encoding to a sepearate bit -- and "encode" for js/html playback (as well, or in place of) video/gif.

Years ago I rewrote rxvt in javascript. https://github.com/paddymul/rxvt-js my aim was to create a terminalcast recording site. my rxvt implementation doesn't work with color, but it can succesfully redisplay an emacs session with split windows.

Please, hack on the code, this is something that should exist.

Another option for recording gifs is LICEcap (http://www.cockos.com/licecap/). It supports OSX and Windows. No support for overlaid keystrokes, though.

Oh, and http://showterm.io/ and https://asciinema.org/

You can also use vlc to record your desktop. That way you can also control the output video codec and pass additional parameters to control the quality/size. Also, you can stream your desktop live to a streaming server (like rtmp).

It is mostly a bash script wrapper around Byzanz, the later existing since at least 2008:

http://linuxpoison.blogspot.co.at/2008/11/desktop-recording-...

Still, interesting.

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

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.

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.

Looks nice. I was going to perform a shameless plug by mentioning my simple Linux OSD nanoproject (for those wanting to use some other recording matters, but still see the keystrokes on the screen):

https://github.com/przemoc/kaos/

but I just remembered that I still haven't fixed a bug I noticed on my computer at work, where I had Gnome back then. Nowadays I have awesome there too (just like on my laptop), so I'll possibly won't reproduce it, but notes I left should be enough to do the fix one day. ;)

The Sublime Text dev has an interesting take on this idea, using a single packed PNG and canvas rendering to avoid GIFs 256-colour limitation while remaining lossless:

http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...

I'm hoping someone takes the ball and maintains that project, I think it's pretty awesome. Whenever I think of great landing page animations for software tools, I think of ST.

Similar available on Windows - http://carnackeys.com/ with source available at https://github.com/Code52/carnac

This is awesome! I'll definitely try to use it and make some Vim tutorials.

For Windows, use the Open Source http://www.carnackeys.com and either CamStudio or Camtasia. Works great.

windows also comes with the well-hidden "Problem Steps Recorder" that takes a sequence of screen shots whenever you click something. Doesn't do the text overlay but it's already installed with Windows which makes some things easier.

Smart and useful! And if there are issues with the GIF format, surely others could easily be added. Nice work.

Reply on news.ycombinator.com