Show HN: ttystudio – a terminal-to-gif recorder without the headaches | Hacker News Reader

Show HN: ttystudio – a terminal-to-gif recorder without the headaches

github.com

118 pointschjj29 comments

Every time I see posts about recording GIFs, I'm always surprised Byzanz (https://github.com/GNOME/byzanz) isn't more well known. Here's a GIF I just recorded with it: http://i.imgur.com/kQl7qHp.gif.

The colors aren't perfect, but the file sizes are always surprisingly small. The one linked is 10 seconds long and about 500kB.

It's kind of janky, but here's the script I've been using for the past year or so without fault for recording: https://github.com/zachlatta/dotfiles/blob/master/local/bin/....

Byzanz uses the gstreamer framework, which is massive. It does a video capture which is encoded on the fly to gif (or other formats).

But I upvoted you anyway, because byzanz IMHO is the easiest/fastest screen recorder to use for this kind of task (far better than the more popular recordmydesktop).

I successfully use byzanz with screenkey (from AUR) to record terminal sessions very effectively.

byzanz records desktop, while ttystudio records merely terminals.

The former not only requires Xorg running, but also gnome. The latter runs on any WM, or even via SSH. Quite different goals.

Ah – didn't think about the dependency on Xorg.

I don't think Byzanz requires GNOME though. I've been happily using it with i3.

It uses libglib, etc, from the GNOME project, even if it doesn't require the GNOME desktop environment.

As someone who grew up in the 90s where GIFs became popular for their use in looping animations, I don't understand why these files became popular for this kind of use case of step-wise instructional material (or even worse, as general-purpose video containers). Sure they may be more lightweight than videos, but isn't it frustrating to miss a step and have to wait for the entire GIF to loop all over again? This can happen especially with tutorials that use GIFs sprinkled throughout. By the time you scroll to them you end up halfway through the animation or aren't sure what step you're at and how long you need to wait for the repeat.

Maybe this is more of a browser-issue and if we're going to embrace abusing GIFs as video containers perhaps browser vendors should give the user video player-style controls?

At least one image hosting site[1] is going in the opposite direction, converting GIFs to H.264 videos to save bandwidth and CPU time. They don't show playback controls - although (in Chrome, at least) you can right-click and enable controls.

1: https://imgur.com/blog/2014/10/09/introducing-gifv/

I like that there is no required GUI, but needing to install the node.js dependency sounds like a "headache" to me.

I'm sorry you feel that way. This project came out of my own need I guess. I had too much trouble with ttyrec+ttygif: glitchy/corrupt gif frames (bad dispose ops maybe?), clunky interface, requires terminal playback on a GUI, concatenation of gifs, etc. It really drove me nuts.

Typing one command to record and output a gif/apng works better for me. If you can get over the node.js part, I'd wager it's likely to be less of a headache.

I agree, I tend to prefer when utilities like this are single statically compiled program like Go produces.

Indeed, this is a excelent example of what golang could be great at!

Can it properly record zsh's completion dialogs? I recently spent two hours trying to record a 5 seconds terminal sequence [0] and all terminal recording tools I tried failed. I ended up using a screen recording tool.

[0] http://imgur.com/BxGppbA

I use LICEcap: http://www.cockos.com/licecap/

I love LICEcap, so simple, and Cockos are awesome. LICEcap is Windows/OSX only though. There's no Linux build, and I have no idea if you could compile it on Linux.

This seems like it'll run on any environment that supports node.

Yeah, so simple and useful, can't live without it.

Really nice feature for the cli. The generated images could get a lot of more optimized though. The example.gif file ~2.5 MiB large, uses 100 ms frames and each frame updates the whole area. Some optimization suggestions:

* Use variable length frames * Only update areas that change between frames

For apng: * Use a palette, it can even handle 4 bits per channel palettes which could be enough for terminals.

Maybe these are all not necessary, a naive "gifsicle --optimize" reduced example.gif's size to ~150 KiB. It didn't remove frames though.

I agree with the gif optimization. It's on the todo list. The most important part is actually the x and y offsets for each frame, like you said: the damage to the image. It should be possible since ttystudio uses a blessed terminal cell buffer, which already has some code that could be borrowed for damage checks between frames.

The APNGs already use a palette (3). RGBA (6) is opt-in only. Although, it should probably just be RGB if people want to use it since the alpha is useless for terminal recordings anyway.

The only reason the --rgba option exists is because I ended up OOMing the process once or twice when compiling palettes for huge animations (1000s of frames) - this is before palette generation was optimized more.

What are people's experiences with asciinema? It's always seemed mindblowing to me to be able to search a screencast, and to be able to pause and scroll around.

It does not work on IPv6 due to some upstream issue (IIRC, the issue was that it was written in golang). I could not use it on most of the hosts I usually work on, so quickly discarded it.

I remember trying it out a few months back and it simply didn't work for what I was trying to record. It looked like everything was fine for normal shell operations, but it certainly didn't seem to like recording full ncurses UIs.

I love it. I use it to record and share work demos on a very regular basis. Works great for vim and more.

There are a few sites that let you stream terminals directly via telnet.

For example telnet://termcast.develz.org/ for the Dungeon Crawl Stone Soup community or telnet://termcast.org/ for general content.

From time to time people do live-coding on this, too.

I see the note about rendering with a custom font. Will that screw up recording for those with special fonts being used (powerline for example)? How does it play with ncurses displays, or even tmux? I assume vim session recording is fine?

The default font (terminus) supports 891 glyphs. However, ttystudio can support any font you find in .bdf format. The readme explains how to use them.

Terminus works fine with tmux, vim, ncmpcpp, mutt, irssi, cmatrix, hundreds of pieces of ansi art, and everything I've tried it with.

As far as powerline goes: I think powerline changes some unicode glyphs for its own purposes, so you would need to grab the powerline .bdf if there is one and compile it to ttystudio's bdf .json format.

Font formats other than .bdf may be supported in the future. This was a weekend project for me and .bdf happened to be the most convenient (and I use terminus in my own terminal so I'm biased).

> without the headaches

> nodejs

I'm intrigued that this uses a built-in terminal emulation library instead of doing screen recording, which makes this different from most (all?) other solutions I've seen. Nifty!

What's the average size per minute with ttystudio? I'd think that x264 or mp4 compression would be more efficient, but I am not sure if that would be more practical and doable for terminal sessions.

So it says that there are no external dependencies yet the package has third party dependencies, what's the deal?

Not to mention that it requires node.js, which is quite a massive dependency.

Reply on news.ycombinator.com