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.
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.
I documented the following application-crashing workflow in iTerm2:
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 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.
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:
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.
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.<video src="" controls></video>
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.