If you’re working on open source, stream straight to YouTube or Twitch. Can be private or not.

I do this sometimes. the accountability hack works even better if someone could be watching.

Bonus points is that it feels way more natural to narrate aka rubber duck problems when you are streaming.

x264/veryfast, 1080p 10fps at 2000kbps, is more than enough for plain text recordings and it won’t take that much space.

You can go even lower with other encoders (x265) + if you don't record audio at all

2000 kbps = 0.25 MiB/s = 900 MiB/h?

That's only 1.14 TiB per year doing it 5 h/week * 5 days/week * 52 weeks.

You only need 40kbps for acceptable audio, so I wouldn't worry about that at all in this ballpark of video bitrate.

If you record mono speech, opus can produce great results at 15kbps.

If you just want speech, yes. For cheap generic audio I don't think I'd push it below 32 unless I really needed to shave bits.

A while ago I tried to see what compression I could get out of screen recording losslessly to a scratch disk and encoding afterwards as slowly as I could wait. I didn't write any numbers down, but the difference in efficiency was significant. Some observations:

- Of the lossless encoders in OBS/libav, utvideo was the best in both CPU usage and efficiency, followed by lossless ultrafast x264.

- An SSD can handle even uncompressed 24bpp 1080p60, which is 375 MB/s. Typical screen content compresses well below the ~100 MB/s write speed of an HDD. Fullscreen video does not, instead gradually filling the write cache until either OOM or thrashing.

- For onscreen content, I prefer the bitrate tradeoff of keeping PC color range and not chroma subsampling.

This technique isn't as effective for this use case of recording several hours daily, since reencoding must be fast enough on average to keep up. Best to already have a home server (any spare desktop). Otherwise, use AOM codecs, known for poor multithreading, to encode at full speed without hogging CPU.

ps, temporal compression means that dropping framerate makes surprisingly little difference with modern codecs. But I really should be writing down the results of my ad hoc tests...

(3 days later): Necroing with a link to this serendipitous related submission about building a NAS for professional video editing from 40 TB of SSDs: https://news.ycombinator.com/item?id=32235158

Yea, on second thought, long term screen recording like this would be a terrible waste of silicon. At 150 MB/s, 46 days of nonstop recording would exhaust the entire 600 TBW of a 1 TB consumer SSD. And for fun: a high-end 500 GB SSD writing at 3500 MB/s could burn its 300 TBW in a single day, not counting the EoL slowdown.

Curiously, RAID 0 hard disks are perfect for such workloads, yet the blogger has still chosen to use consumer grade SSDs.

This is a phenomenal way to wear out an SSD for no real reason at all.

> An SSD can handle even uncompressed 24bpp 1080p60, which is 375 MB/s.

Well, it can for an hour.

You're using 4:4:4 (disabled chroma subsampling) to keep text readable?

If you have an old machine you can use as a NAS and run raidz2, disks are $7.50/TB or less: https://diskprices.com/

Screen captures also compress much better than live action since most frames are duplicates of their predecessor. So a cheap NAS can run for years before you start thinking of deleting VODs.

No need to record 4k 120fps videos if you're doing web development, something like 1080p in 10fps might be enough and it won't take ridiculous amount of space.

Parent comment specifically mentions recording for game development so 1080p at 10fps probably isn't going to cut it.

Update it to be 20~25 fps then, still won't take ridiculous amount of space.

Unlike movies, the content on screen recordings usually remains roughly the same for minutes before switching scene. So it can achieve significantly higher compression ratio even at high fps

I wrote more about it here: https://news.ycombinator.com/item?id=32223240

But the TLDR, ffmpeg can remove duplicate frames:

    ffmpeg -i in.mkv -map 0:v -vf mpdecimate,setpts=N/FRAME_RATE/TB out.mp4

1080p may easily mean that the code is unreadable if you have a decent size screen.