In the Weeds

I just caught myself way off in the weeds, shaving yaks and figured I should write it down for a laugh. I need to remember a few points the next time something like this happens.

Setting the Scene

I was procrastinating a bit and reading about Colorized Man Pages. It's pretty straight-forward, setting a few variables for less to output color rather than bold or underline. I tried it out but didn't love how harsh some of the greens in iTerm2 were looking and thought I would adjust them a bit darker.

A Bug

I documented the following application-crashing workflow in iTerm2:

1. Open profiles
2. Edit profile colors, selecting a custom color
3. Click away to close the color picker
4. Without closing the preferences or profiles window, click on the main iTerm window

iTerm2 is open-source (and GPLed) so like any good end-user I wrote the above so I could submit a bug report. What I realized I really needed was a video documenting the above, to be really explicit.

I've recently learned to use Quicktime Player's built-in support for capturing screen recordings and I am entirely too enamored with it. The ease of use is great and it has rudimentary support for trimming the video file as necessary to remove extraneous bits. The one thing that isn't great is my available options for saving the videos, typically .MOV files.

I normally use gifs for this exact reason, they are supported everywhere and more or less work fine. But it's 2016 and I should really use a 21st century file format.

WebM

WebM is a pretty neat format for distributing video on the web, the quality to compression ratio is head and shoulders above my usual gifs. It is apparently not supported on iOS devices, but I only learned that from reading the Wikipedia article as I wrote this. The issue I had was transcoding the screen captured video from a .mov to a .webm, but! I have ffmpeg installed.

$ ffmpeg -i crash.mov crash.webm

Reveals I don't have the right encoders installed. So while ffmpeg supports webm files, it must be compiled with it. So I'm stuck uninstalling, installing libvpx, and re-installing from homebrew --with-libvpx. But now I can transcode the video. This takes several minutes (for a 16 second video). See below for my notes on improving this processing time.

Where Do I Submit This Anyhow?

It turns out, and I don't exactly love this, iTerm2 has a website, hosts code on GitHub and tracks issues on Gitlab. I followed that exact path to find the correct place to submit a bug report. I was slightly ameliorated when I found the issue template to be very useful. The developer(s) are really enabling bug-reporters to be their most helpful:

Thanks for filing an issue! Please answer the questions below so I can help you.

• iTerm2 version:
• OS version:
• Attach com.googlecode.iterm2.plist here (drag-drop from finder into this window)
• Attach a debug log, if possible. Instructions
• Are you reporting a performance issue or a hang? Please attach a sample. Instructions
• Are you reporting a crash? Please attach the crash log. Instructions

Detailed steps to reproduce the problem:

What happened:

What should have happened:

my bug report

Dissatisfaction in a Job Well Done

I found all the applicable files, attached the video and submitted the report. I then tried to make myself useful and searched a few existing issues for similar problems. It seemed no one had reported the exact same issue, but I had the unhappy realization that I was running version 3.0.5 and the latest was in fact 3.0.7. With some trepidation I updated and re-checked my documented steps - my issue was fixed in the latest builds already. I made a note in my newly minted issue and closed it out.

Miscellaneous Notes

• Be wary of the default screen resolutions on Quicktime Player's screen captures, transcoding a video that is over 2000 pixels wide is going to take a long time no matter what. I took a 16 second video that was over 5MB down to about 600KB without losing its intended message (it is only a bug report after all)
• ffmpeg can resize a video down to 800 pixels wide with the following: ffmpeg -i crash.mov -vf scale=800:-1 small-crash.mov. I found 800px wide to produce reasonable file sizes while maintaining legibility.
• ffmpeg can be sped up significantly with the right command line argument invocations, for example: ffmpeg -i crash.mov -c:v libvpx -crf 10 -b:v 1M -cpu-used 5 -threads 8 crash.webm takes transcoding time down to about 50% of the source video length but trades processing time for output video size.
• HTML5 video tag controls are enabled as such <video src="" controls></video>
• The HTML5 video tag can be preempted from eating up network bandwidth by setting preload="none", this doesn't get the nice video still on un-played video but eliminates an entire HTTP request.

I should really get back to work at this point.