DEV Community: Alexander Pervushen

Fit any video under the limit: meet DeepShrink, a one-command media compressor

Alexander Pervushen — Tue, 21 Jul 2026 08:40:51 +0000

You have a 300 MB screen recording. Discord wants it under 8 MB. Your email won't take more than 20. So you either google "compress video to 8mb" and land on an ad-riddled web converter that uploads your file to someone else's server and stamps a watermark on it — or you open HandBrake and start guessing at CRF values — or you hand-write an ffmpeg command, recompute the bitrate for the fifth time this month, and forget the audio track again.

None of those answer the actual question: "make this ≤ N MB, without me thinking about it."

That's the whole reason DeepShrink exists.

deepshrink gameplay.mp4 --for discord

  gameplay.mp4   1920x1080  2m14s   312.4 MB
  target         Discord (8 MB)
  plan           H.264 · 456 kbps video · 96 kbps audio · two-pass
  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100%   pass 2/2

  ✓ gameplay.shrink.mp4   7.6 MB   (−97.6%)   VMAF 91.2

One command. Local. No upload, no watermark, no guessing. And when you say --target 8MB, the result is guaranteed ≤ 8 MB — not "roughly."

What it actually is

DeepShrink is a small, open-source CLI written in Rust. It doesn't reinvent encoding — it drives ffmpeg for you and does the one thing ffmpeg makes annoying: hitting an exact output size.

Under the hood it probes the file with ffprobe, works out the bitrate budget for your target size (with a little headroom for container overhead), runs a two-pass H.264/H.265 encode for video or picks the right codec bitrate for audio (AAC / Opus / MP3), and can optionally hold a quality floor with VMAF so it never over-compresses. You don't touch any of that. You say how big, it figures out how.

The design goals, in order:

One obvious command solves 80% of cases. deepshrink video.mp4 --target 8MB.
Presets instead of flags. You shouldn't need to know what a bitrate is.
Never wreck the original. Output is a new file (video.shrink.mp4); the source is untouched unless you explicitly pass --overwrite.
Local and private. Your file never leaves your machine.

Scope today is video and audio — one engine, ffmpeg. Images, PDFs, and other formats are a deliberate future step, not a half-baked afterthought.

Installing with Homebrew (recommended on macOS)

This is the frictionless path, and it's the one I'd reach for first:

brew install deeplabua/tap/deepshrink

That's it. Because the formula declares depends_on "ffmpeg", Homebrew pulls ffmpeg in as a dependency automatically — so there are zero manual runtime steps. Install, and it works.

If you'd rather tap first and install by short name (handy if you'll install other tools from the same tap later):

brew tap deeplabua/tap
brew install deepshrink

Verify it landed:

deepshrink --version
deepshrink --help

Updating later is just brew upgrade deepshrink.

Installing with cargo (from crates.io)

If you already live in the Rust toolchain, DeepShrink is on crates.io:

cargo install deepshrink

This compiles from source, so it's slower than the prebuilt Homebrew bottle and you need a Rust toolchain installed. Worth knowing about one difference from the brew path: cargo install does not bring ffmpeg along. DeepShrink expects ffmpeg and ffprobe to be on your PATH, and if they aren't, it exits cleanly (code 3) with a hint rather than crashing.

So on a fresh machine, install ffmpeg alongside it:

# macOS
brew install ffmpeg

# Debian / Ubuntu
sudo apt install ffmpeg

# Windows (Scoop)
scoop install ffmpeg

Then the same check as before:

deepshrink --version

brew vs cargo, quickly

	`brew install deeplabua/tap/deepshrink`	`cargo install deepshrink`
Speed	Prebuilt bottle, instant	Compiles from source
Rust toolchain needed	No	Yes
ffmpeg	Pulled in automatically	You install it yourself
Best for	Most people, especially macOS	Rust devs who already have the toolchain

Prebuilt binaries for macOS, Linux, and Windows are also attached to every GitHub release if you'd rather not use a package manager at all.

Using it

The headline command — fit a file under an absolute size:

deepshrink big.mp4 --target 8MB
deepshrink talk.wav --target 500KB

Don't want to memorize platform limits? Use a destination preset and DeepShrink applies the right cap:

deepshrink clip.mp4 --for discord        # 8 MB
deepshrink clip.mp4 --for email          # 20 MB
deepshrink clip.mp4 --for telegram       # only recompresses for quality

Built-in presets today: discord, discord-nitro, email, telegram, whatsapp, and web.

Prefer a relative cut instead of a hard ceiling?

deepshrink video.mp4 --reduce 70%        # 70% smaller than the source

Audio is a first-class citizen, not an afterthought — great for podcasts, voice memos, and lectures:

deepshrink lecture.wav --target 10MB

  lecture.wav     stereo 48kHz   58m02s   638.1 MB (PCM)
  target          10 MB
  plan            Opus · ~22 kbps · mono (speech)
  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100%

  ✓ lecture.shrink.opus   9.4 MB   (−98.5%)

Got a whole folder? Batch it — DeepShrink walks the directory, skips files that are already small or unsupported, and prints a summary instead of dying on the first hiccup:

deepshrink ./recordings --recursive

A few flags worth knowing:

--dry-run — show the plan (chosen bitrate, expected size) without encoding a thing.
--vmaf <n> — hold a quality floor; it won't compress below the VMAF score you ask for.
--codec h265 — smaller files at the same quality, when you don't need maximum compatibility.
--json — machine-readable output, for scripts and CI.
--overwrite — replace the original in place (written atomically via a temp file, so an interrupted run won't corrupt your source).

Why bother, over a web converter?

Because DeepShrink is the intersection people actually want: the precision and privacy of native ffmpeg with the simplicity of a web converter — and none of the downsides of either. Your file stays on your disk. You get an exact size, not an approximation. There are no watermarks, no queues, and no "upload your file to continue." It's one static binary that works offline.

Get it

Homebrew: brew install deeplabua/tap/deepshrink
cargo: cargo install deepshrink
Source & releases: github.com/deeplabua/deepshrink

It's open source and free. If it saves you a trip to a sketchy converter even once, consider dropping a ⭐ on the repo — that's what keeps small tools like this alive.

Try it on that 300 MB file you've been avoiding. --target 8MB. Done.

How I make ffmpeg hit an exact file size (the bitrate math nobody explains)

Alexander Pervushen — Sat, 18 Jul 2026 18:18:30 +0000

Every few weeks I hit the same wall: I have a 300 MB screen recording, and something on the other end wants it under 8 MB. Discord, an email attachment, a bug tracker, a form that silently rejects anything bigger.

The usual advice is "just use HandBrake" or "run ffmpeg with a lower CRF." But CRF doesn't take a target size — it takes a quality knob. So you export, check the size, it's 11 MB, nudge the knob, export again, now it's 5 MB and looks like a potato, nudge back… It's a binary search you run by hand, one full encode per guess.

The thing is, hitting an exact size isn't a guessing game at all. It's arithmetic you can do before you encode. I ended up wrapping that arithmetic into a little Rust CLI (DeepShrink), but the math is the interesting part, and almost nobody writes it down. So here it is.

The one insight everything rests on

File size is (roughly) bitrate × duration.

A bitrate is bits per second. A duration is seconds. Multiply them and the seconds cancel, leaving bits — the size of the file. That's it. That's the whole trick.

Normally you treat bitrate as the input and size as whatever falls out. Flip it around: fix the size, measure the duration, and solve for the bitrate. You know the duration (ffprobe will tell you), and you know the size you want (the platform's limit). The only unknown is the bitrate — and now it's a single division away.

bitrate = size_in_bits / duration_in_seconds

Everything below is just this equation with the real-world messiness added back in.

Building the budget, step by step

Say I want a 60-second clip to fit Discord's 8 MB limit.

1. Turn the target size into bits. Sizes are in bytes, bitrate is in bits, so multiply by 8. (I'll use 1 MB = 1,000,000 bytes here to keep the mental math clean; if your platform means mebibytes, same method, different constant.)

target_bits = 8_000_000 bytes × 8 = 64_000_000 bits   (64 Mbit)

2. Reserve a little for container overhead. An .mp4 isn't pure video and audio — there's a container, a moov atom, stream headers, muxing slack. If you budget every last bit to the media, you'll overshoot. I hold back ~2%:

usable_bits = 64 Mbit × (1 − 0.02) = 62.72 Mbit

3. Pay for audio first. Audio is usually a fixed, modest bitrate, so I carve it out before touching video. At 96 kbps for 60 seconds:

audio_bits = 96_000 bps × 60 s = 5.76 Mbit

4. Whatever's left is the video budget. Divide it by the duration to get the video bitrate:

video_bits    = 62.72 − 5.76 = 56.96 Mbit
video_bitrate = 56.96 Mbit / 60 s ≈ 949 kbps

Done. Encode that 60-second clip at ~949 kbps of video plus 96 kbps of audio, and it lands right around 8 MB — no guessing, no re-exports.

As a pure function it's about ten lines. This is essentially the core of DeepShrink's budget module (simplified):

fn video_bitrate_bps(target_bytes: u64, duration_s: f64, audio_bps: u64) -> u64 {
    const OVERHEAD: f64 = 0.02;
    let target_bits = target_bytes as f64 * 8.0;
    let usable_bits = target_bits * (1.0 - OVERHEAD);
    let audio_bits  = audio_bps as f64 * duration_s;
    let video_bits  = (usable_bits - audio_bits).max(0.0);
    (video_bits / duration_s) as u64
}

Ten lines of arithmetic, no I/O, trivially unit-testable. That last part matters: because it's pure, I can test the budgeting logic without ever spawning ffmpeg.

Why you need two-pass to actually hit it

Knowing the target bitrate isn't enough on its own. If you hand ffmpeg a single-pass -b:v 949k, the encoder doesn't know what's coming — a calm talking-head scene and a chaotic explosion get bits allocated blindly, and the average drifts off your target.

Two-pass fixes this. The first pass analyzes the whole video and writes a stats log (it produces no output file). The second pass uses that map of "where the hard parts are" to distribute bits so the average actually lands on your number:

# Pass 1 — analyze, no output
ffmpeg -y -i input.mp4 -c:v libx264 -b:v 949k -pass 1 -an -f null /dev/null

# Pass 2 — encode for real, using the stats from pass 1
ffmpeg -i input.mp4 -c:v libx264 -b:v 949k -pass 2 -c:a aac -b:a 96k output.mp4

Two passes means roughly double the encode time, but it's the difference between "about 8 MB" and "reliably under 8 MB." When the whole point is to fit under a hard limit, reliable wins.

The guardrails that make it shippable

If I stopped at the formula, it'd work maybe 80% of the time and produce garbage the other 20%. The interesting engineering is in the edges.

Don't paint 1080p with a bitrate meant for a thumbnail. A one-hour lecture squeezed into 8 MB gives you a video budget so low that full HD turns to mush — the encoder simply doesn't have the bits to describe that many pixels. So before committing, I sanity-check the bitrate against the resolution. If it's too low to look acceptable at the source resolution, I step down a resolution ladder (1080p → 720p → 480p…) and pick the highest rung the budget can actually support. Fewer pixels, each with enough bits, beats many pixels all starved.

Verify, then correct once. Muxing overhead isn't perfectly predictable, so the output can miss the target by a hair. After encoding I check the real file size, and if it overshot, I re-run with a slightly corrected bitrate. One correction, not an infinite loop — the first pass already gets you within a couple percent.

Never make a file bigger. If the source is already under the target, there's nothing to solve. Re-encoding would just waste time and lose quality for no reason. In that case I skip straight to a remux (or leave it alone). "Shrink" should never accidentally inflate.

Fail loudly when it's impossible. Sometimes the target genuinely can't be met — a two-hour movie into 2 MB isn't happening at any watchable quality. Rather than emit a slideshow and pretend it worked, DeepShrink bails with a distinct exit code (4, "can't fit even at minimum reasonable quality"). A clear failure beats a technically-succeeded garbage file.

Audio-only is the same idea, minus a pass

Podcasts, voice memos, and lectures hit size limits too, and they're actually simpler: no resolution ladder, and no two-pass (audio codecs hit an average bitrate directly). The budget collapses to one line:

audio_bitrate = target_bits / duration_s

The wrinkle is that you can't pick any arbitrary number — codecs work in sensible steps, so I snap down to the nearest one (snapping up would blow the target). And there's a floor: below a certain bitrate speech stops being intelligible, so I clamp there and, if even that won't fit, fail rather than ship noise. For speech specifically, downmixing to mono and using Opus buys a lot of headroom — a mono Opus voice track at ~24 kbps is still perfectly clear and a fraction of the size.

$ deepshrink lecture.wav --target 10MB

  lecture.wav     stereo 48kHz   58m02s   638.1 MB (PCM)
  target          10 MB
  plan            Opus · ~22 kbps · mono (speech)
  ✓ lecture.shrink.opus   9.4 MB   (−98.5%)

The takeaway

"Compress this to 8 MB" sounds like it needs a fancy heuristic or an ML model. It doesn't. It's size = bitrate × duration rearranged, plus a handful of guardrails so the arithmetic survives contact with real files: reserve overhead, pay audio first, drop resolution before the picture falls apart, verify and correct once, and refuse the impossible instead of faking it.

The formula is ten lines. The guardrails are what make it feel like magic instead of a footgun.

If you'd rather just type one command than wire this up yourself, that's exactly what I packaged DeepShrink for — it's open source (Rust, driving ffmpeg as a subprocess), MIT-licensed, and lives here: github.com/deeplabua/deepshrink. But now you know what it's doing under the hood, and you could write the core of it in an afternoon.

What's your go-to trick for wrangling ffmpeg? I'm always looking for edges I haven't hit yet.

How I stopped fighting Oracle's "Out of host capacity" and let a script catch a free ARM server for me

Alexander Pervushen — Sun, 07 Jun 2026 19:58:49 +0000

Oracle Cloud's Always Free tier is, quietly, one of the best deals in cloud computing: 2 Arm OCPUs and 12 GB of RAM, free forever, no trial clock. That's still enough for a homelab node, a Docker stack, a VPN, or a game server - running 24/7 without paying a cent or buying hardware.

(Update, June 2026: Oracle quietly halved this from 4 OCPU / 24 GB to 2 OCPU / 12 GB on 15 June 2026, with no announcement. Pay-as-you-go accounts reportedly kept the old 4/24 for free, but Oracle hasn't confirmed that publicly.)

There's just one problem standing between you and that box, and if you've tried you already know its name:

ServiceError:
  code: InternalError
  message: Out of host capacity.

Those Arm hosts are in such heavy demand that creating an instance usually fails. US regions can be dry for hours or days. Even busy EU/APAC regions dip in and out. Capacity frees up in small, random windows — and whoever happens to be retrying at that exact second gets it.

I spent the better part of a week refreshing the OCI console like it was a concert ticket drop. Then I did the obvious thing: I wrote a script to play the lottery for me, on a timer, and walked away. It worked — it caught me a 4 OCPU / 24 GB A1 instance. So I cleaned it up and open-sourced it.

👉 github.com/alexpua/oci-arm-catcher (MIT)

[GIF: terminal showing "Out of host capacity… retrying" a few times, then "SUCCESS! Instance created"]

The idea is dumb on purpose

There's no clever exploit here. The tool just calls the official OCI CLI command — the exact same oci compute instance launch you'd run by hand — in a polite loop, and reacts to the result:

loop:
  oci compute instance launch  --shape VM.Standard.A1.Flex ...
  ├─ success            → parse the instance OCID, desktop notification, exit
  ├─ "out of capacity"  → wait, (optionally rotate AD), retry
  │   InternalError / LimitExceeded / TooManyRequests / timeout
  └─ any other error    → print it, notify, STOP

The only part that actually matters is the last two branches. A naive
while true; do launch; sleep; done loop is worse than useless: when your config has a typo — wrong subnet OCID, an x86 image, an auth problem — it will cheerfully retry that broken request forever and you'll never notice.

So the catcher splits errors into two buckets:

Transient / capacity (Out of host capacity, InternalError, TooManyRequests, timeouts) → keep trying, this is the whole point.
Everything else (NotAuthorizedOrNotFound, LimitExceeded, bad image) → stop immediately and tell the human.

That single distinction is the difference between "I left it running overnight and woke up to a server" and "I left it running overnight and woke up to 4,000 copies of the same error."

Things I added once it was more than a personal hack

Readable error output. The OCI CLI prints errors as a JSON blob to stderr.
My first version grepped for "message" and frequently printed ?: ? when the shape didn't match. Now a tiny Python helper parses the JSON properly and always falls back to something human-readable:

  -> InternalError: Out of host capacity.

Multi-AD rotation. Regions like Ashburn, Phoenix and Frankfurt have three Availability Domains, and capacity can appear in any one of them. Give the catcher all three and it cycles through on each retry, multiplying your chances:

AVAILABILITY_DOMAINS="Abcd:US-ASHBURN-1-AD-1,Abcd:US-ASHBURN-1-AD-2,Abcd:US-ASHBURN-1-AD-3"

A config-discovery helper. The genuinely annoying part of OCI isn't the API, it's finding all the OCIDs (compartment, subnet, image, availability domain). So there's a read-only get-config script that prints them, formatted to paste straight into your .env. It launches nothing — just reads metadata.

Cross-platform. Bash for macOS/Linux, plus a native PowerShell port for Windows (with toast notifications). Or run the bash version under WSL2 — your call.

Desktop notifications. Because the whole pitch is "start it and forget it," it pings you the moment it lands — osascript on macOS, notify-send on Linux, a toast on Windows.

Tests. It mocks the oci CLI and asserts the important behaviors: retries on capacity errors, stops on auth errors, parses the OCID on success, never prints ?: ?. bats for bash, Pester for PowerShell, ShellCheck — all in CI. For a 200-line shell script that's arguably overkill, but I wanted the "stop on real errors"
guarantee to be actually guaranteed.

Using it

git clone https://github.com/alexpua/oci-arm-catcher.git
cd oci-arm-catcher

cp .env.example .env
./scripts/get-config.sh     # prints your OCIDs → paste into .env
# edit .env

nohup ./oci-arm-catcher.sh > catcher.log 2>&1 &
tail -f catcher.log

Then go do something else. When capacity opens up, you get a notification and a running instance.

A note on being a good citizen

This isn't a way to "beat" Oracle or bypass anything. It does exactly what you'd do by hand, just patiently and on an interval (default: every 5 minutes — not a hammer). You still have to stay inside your free-tier allowance. It's automation of a tedious manual task, nothing more.

Try it / break it

If you've been losing the capacity lottery, give it a run:
github.com/alexpua/oci-arm-catcher

Issues and PRs welcome — I'd especially love more notification backends (Telegram, Discord, Slack), smarter backoff, and region/AD presets.

And if it caught you a free server: a ⭐ on the repo helps the next person find it, and if you feel like it, you can buy me a coffee ☕.
Both totally optional — the tool's free either way.