webm on S Anand

Editing Workshop Videos

Sun, 14 Jun 2026 08:27:16 +0530

I sometimes use Google Meet, Teams, Zoom, etc. to record workshops and talks. These record the entire session, including before and after the actual talk, and save it as large MP4 files.

I use ffmpeg to trim the video to just the talk, and then compress it for sharing. I’m sharing the options that work for me, discovered by trial-and-error.

To trim it, I use the following command:

ffmpeg -ss 00:10:00 -to 02:10:00 \
  -i "original.mp4" \
  -map 0 \
  -c copy \
  -avoid_negative_ts make_zero \
  -movflags +faststart \
  new.mp4

Arguments:

-ss 00:10:00: Start reading from 10:00 into the source file. Placing -ss before -i makes this fast because ffmpeg seeks instead of decoding from the start.
-to 02:10:00: Stop at 02:10:00 in the source timeline. So this keeps roughly the section from 00:10:00 to 02:10:00.
-map 0: Keep all streams from the input: video, audio, subtitles, metadata streams, etc. Use -map 0:v:0 -map 0:a:0 for just the first video and audio streams.
-c copy: Do not re-encode. Just copy the existing encoded streams. This is very fast and preserves original quality, but cuts only cleanly near keyframes.
-avoid_negative_ts make_zero: Rewrite timestamps so the output starts cleanly near zero. This helps avoid weird negative timestamps and duration/reporting issues in some players.
-movflags +faststart: Move MP4 metadata to the beginning of the file. This helps playback start faster in browsers and streaming contexts.)

To compress it I use:

ffmpeg -i 'trimmed.mp4' \
  -map 0:v:0 -map 0:a:0 \
  -c:v libvpx-vp9 \
  -b:v 0 \
  -crf 42 \
  -deadline realtime \
  -cpu-used 8 \
  -row-mt 1 \
  -tile-columns 2 \
  -frame-parallel 1 \
  -threads 8 \
  -pix_fmt yuv420p \
  -vf "fps=16" \
  -c:a libopus \
  -b:a 32k \
  -ac 1 \
  -ar 48000 \
  -af "highpass=f=80,lowpass=f=12000" \
  "compressed.webm"

Arguments:

-map 0:v:0 -map 0:a:0: Use the first video stream and first audio stream from the input
-c:v libvpx-vp9: Compress video with VP9 codec
-b:v 0: Use constant-quality mode instead of targeting a fixed bitrate
-crf 42: When testing on samples, CRF 42 was small enough and clear enough for me
-deadline realtime: -deadline good is too slow for me though that’s better for production
-cpu-used 8: 8 is the maximum allowed for VP9 for now
-row-mt 1: Enable row-based multithreading for faster VP9 encoding
-tile-columns 2: Split each frame into tiles so multiple threads can encode in parallel
-frame-parallel 1: Allow frames to be decoded in parallel; useful for VP9/WebM playback
-threads 8: Use up to 8 CPU threads during encoding
-pix_fmt yuv420p: Use the most compatible pixel format for browsers and video players
-vf "fps=16": Reduce frame rate to 16 fps to shrink file size; good enough for slides/talk videos
-c:a libopus: Compress audio with Opus, the standard audio codec for WebM
-b:a 32k: Use low audio bitrate; enough for speech
-ac 1: Convert audio to mono; good for voice and halves stereo audio data
-ar 48000: Use 48 kHz, the standard sample rate for Opus
-af "highpass=f=80,lowpass=f=12000": Remove very low rumble and very high noise; keeps speech frequencies

I deploy these on CloudFlare R2 on a custom domain: media.s-anand.net. R2 costs 1.5c / GB-month. Storing 10 years’ worth of ~500 talks of ~0.5 GB each is under $4 / month - quite affordable. (If it increases, I can shift. Statis files are easy to move.)

I serve them via a <video> tag. Here is an example video:

<video preload="metadata" width="1920" height="1080" controls style="max-width: 100%; height: auto;">
  <source src="https://media.s-anand.net/2026-05-23-ai-unboxed-context-engineering.webm" type="video/webm; codecs=&quot;vp9, opus&quot;">
</video>

Recording screencasts

Wed, 11 Mar 2026 10:48:01 +0800

Since WEBM compresses videos very efficiently, I’ve started using videos more often. For example, in Prototyping the prototypes and in Using game-playing agents to teach.

I use a fish script to compress screencasts like this:

# Increase quality with lower crf= (55 is default, 45 is better/larger)
# and higher fps= (5 is default, 10 is better/larger).
screencastcompress --crf 45 --fps 10 a.webm b.webm ...

To record the screencasts, I prefer slightly automated approaches for ease and quality.

METHOD 1: Browser scrolling: To uniformly scroll to the bottom of the page at ~800 pixels / second (roughly one page per second), I frame the recording window, start recording, and quickly paste this script in the DevTools console:

scrollInterval = setInterval(() => {
  window.scrollBy(0, 16); // Scroll 16px every 20ms (approx 800px/s)
  if (window.innerHeight + window.scrollY >= document.body.scrollHeight) {
    clearInterval(scrollInterval);
    console.log("Reached bottom or no more scrolling.");
  }
}, 20);

This is what I used in Prototyping the prototypes.

METHOD 2: AI Coding Agents: I tell the coding agent to:

… screenshot each step at 1366x768, compressing into video.webm at 1.5 fps, pausing the last frame for 5 seconds.

If playwright and ffmpeg are set up, this just works.

This is what I used in Using game-playing agents to teach.

AI video compression

Sat, 28 Feb 2026 09:18:56 +0800

I recorded a short screen cast of a demo I built. It was ~900KB - way too large to publish as a thumbnail. So I asked ChatGPT:

What’s the best equivalent of squoosh.app for WEBM compression? I’m looking for a free modern high-quality online video compressor.

There are a few, and they compressed it to a third of its size, but 300KB is still too large. So I attached the original and asked:

I am compressing screenshots like this. They’re often not large. I don’t mind cropping the edges by a few pixels to make it a multiple 2, 4, or 8 if that’ll help. I certainly am OK with a lower frame rate. I’d like an image quality that a human eye can just SLIGHTLY detect as worse than the original, but only VERY SLIGHTLY.

What’s the best way of using ffmpeg or similar tools to compress such a file?

Think like an expert:

What would an expert in this field check that beginners would miss?

What patterns would an expert in this field recognize that beginners would miss?

In this context, what questions would an expert ask that a beginner would not know to?

If this goes wrong, what are the most likely reasons?

… and list the best (diverse, testing different hypotheses) compression command options.

Run them on this video and let me download the resulting videos for visual comparison. Interview me. Give me a list of questions that I can easily answer by looking at the videos and I’ll share those with you to help you decide the best compression command for me.

This leverages 3 tricks.

These are online coding agents. So they can write and run code.
The “Think like an expert” prompt is my new “Think step by step” prompt and works quite well.
The “Interview me” prompt is another powerful one that helps me apply preferences – and develop taste.

Claude did a good job of showing different versions and compressing it, but as expected, ChatGPT was the obsessive perfectionist. It gave me a huge set of variations of:

Files sizes
Compression formats (VP9: more compatible vs AV1: better compression)
Quality settings (CRF)
Frame rates (FPS)
Color formats (YUV420p vs YUV444p)
Compression effort (presets)
etc.

… and asked me to compare between them, like these:

crf: 45 fps: 15 (93K)

crf: 50 fps: 15 (69K)

crf: 55 fps: 5 (23K)

The final result is this script:

ffmpeg -hide_banner -stats -v warning -i "$input"
  -vf "crop=iw-mod(iw\,2):ih-mod(ih\,2),fps=$fps" \
  -c:v libsvtav1 -preset 8 -crf $crf -pix_fmt yuv420p \
  -an "$output"

… which does the following:

Crops the video to a multiple of 2 (which is required for some compression formats)
Sets the frame rate to a lower value (which reduces file size)
Uses the AV1 codec (which has better compression than VP9)
Sets the CRF (Constant Rate Factor) to a value that balances quality and file size
Sets the pixel format to YUV420p (which is more compatible with players)
Disables audio (which is not needed for a screencast)

I realized that for the resolution I’ll likely see this at, very low frame rates (5 fps) and poor compressions (CRF 55) are good enough.

My original video was 912KB. The smallest video that looks good enough for me is 23 KB. That’s almost a 40x compression - small enough to publish in my data story.

Things I’m taking away:

Use AI to discover the best configurations for your tool
Interview yourself to apply preferences and develop taste

Things I Learned - 22 Feb 2026

Sun, 22 Feb 2026 00:00:00 +0000

This week, I learned:

tree-sitter is a fast incremental parser generator. That means you can use it to create a parser for any language that works even if there are errors, e.g. malformed JSON, Python, etc. It’s used by most editors. For example, tree-sitter-python is a fast forgiving Python parser. There are official parsers and community parsers
- Programming Languages: All popular ones, less popular ones like Ada, Fortran, Lua, Zig, … and even niche / domain-specific languages (Gleam, TLA⁺).
- Markup & Data Formats: HTML, XML, Markdown, JSON, YAML, TOML, CSV, …
- Query, Scripting & Config: SQL, GraphQL, Bash, Dockerfile, Regex, Terraform (HCL), …
Ligature fonts are nice, but it might not be worth forming a habit out of. Claude
Cloudflare introduced Markdown for Agents. This converts websites from HTML to Markdown via Accept: text/markdown for any Cloudflare endpoint which has enabled this feature. This requires a Pro account.
Microgrants is a list of microgrants programs - where you can give small amounts of money, e.g. $50 - $1K as well as large fellowships over $100K. This includes student grants, creative & community grants, tech grants, social & policy grants, etc.
“Animated web formats are simply video codecs … stripped of their most powerful feature.” A .webm file is likely to compress much better than an animated .webp, etc. Gemini
esbuild can compile CSS files to support old browsers, e.g. nested rules, custom properties, etc. Usage: esbuild input.css --target=chrome90 --outfile=output.css. Julia Evans
New jargon I learnt: Human-On-The-Loop. Treasure In Treasure Out
VS Code’s GitHub Copilot extension supports a github.copilot.chat.commitMessageGeneration.instructions setting that lets you add a [{"text": ...}] or [{"file": "path/to/file.ext"}] prompt to the commit message generation. I’ve pointed this to my git-commit.md custom prompt.