How to Use FFmpeg in the Age of AI Vibe Coding

AI has changed how many developers meet FFmpeg for the first time.

Instead of reading docs, searching Stack Overflow, and trying flags one by one, the workflow often starts with:

Write me an FFmpeg command to make this video smaller.

That is not a bad starting point. In many cases, it works surprisingly well.

The problem is that FFmpeg is not a "compress video" button. It is a full video processing toolbox. AI can hand you a command quickly, but you still need to know what job you are asking the command to do.

This article is a practical way to think about FFmpeg in the age of AI-assisted coding: when to let AI generate commands, what constraints to give it, how to check the result, and when a browser tool like VideoCompress is simply the faster path.

The short version

Use FFmpeg when the workflow needs to be repeatable:

• batch compression
• automated video processing
• server-side transcoding
• CI-generated assets
• scripts you will run again next week

Use a browser-based compressor when the task is mostly about delivery:

• one or two files
• a meeting recording you need to send
• a product demo that is slightly too large
• a video that must fit under an upload limit
• a quick MP4 for a client, teammate, or friend

AI is most useful when it turns your intent into testable FFmpeg parameters. It is less useful when you ask it to guess what "make it smaller" means.

Do not ask for "smaller"

Most bad FFmpeg commands start with a vague goal.

"Make this video smaller" can mean at least four different things:

• The file must be under 25MB for email.
• The quality should look almost unchanged.
• The video is only for mobile preview, so 720p is fine.
• It is just for a chat message, and audio quality does not matter much.

Those are different compression jobs.

Before asking AI for a command, define the constraints:

• What is the input format?
• Where will the output be uploaded?
• What is the target file size?
• What matters most: quality, resolution, audio, or compatibility?

A better prompt looks like this:

Write an FFmpeg command to convert input.mov to output.mp4.
The goal is to upload it to a chat app.
The file should be around 25MB or smaller.
It is a screen recording, so small text must remain readable.
It can be scaled down to 1280px wide.
The output should play in common browsers and phones.
Explain each parameter and give me one conservative version and one smaller-file version.

The point is not prompt engineering for its own sake. The point is to turn compression into constraints. Once the constraints are clear, the AI has much less room to produce a command that technically runs but solves the wrong problem.

A solid starter FFmpeg command

If you just want a compatible MP4, this is a reasonable first attempt:

ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart output.mp4

What the key options mean:

• -c:v libx264 uses H.264 video encoding, which is broadly compatible.
• -crf 23 controls visual quality. Higher values make smaller files with lower quality.
• -preset medium controls encoding speed versus compression efficiency.
• -c:a aac -b:a 128k encodes audio as AAC at 128 kbps.
• -movflags +faststart makes the MP4 friendlier for web playback.

This is not the perfect command. It is a stable baseline. That makes it useful for AI-assisted iteration.

For example, after the first run, you can give the result back to the AI:

The output file is 82MB. I need it closer to 40MB.
The video is a screen recording, and text readability matters more than motion smoothness.
Suggest two versions: one that keeps more quality and one that prioritizes size.

That is a much better loop than repeatedly saying "smaller."

When you have a target file size, estimate bitrate

If the output must stay under a specific size, CRF can feel unpredictable. A bitrate-based approach is easier to reason about.

A rough formula:

target total bitrate in kbps = target size in MB * 8192 / duration in seconds
video bitrate in kbps = target total bitrate - audio bitrate

Example: a 120-second video, target size 25MB, audio at 96 kbps:

target total bitrate = 25 * 8192 / 120 ≈ 1707 kbps
video bitrate ≈ 1707 - 96 = 1611 kbps

Then you can run:

ffmpeg -i input.mov -c:v libx264 -b:v 1600k -c:a aac -b:a 96k -movflags +faststart output.mp4

For more predictable file size, use two-pass encoding:

ffmpeg -y -i input.mov -c:v libx264 -b:v 1600k -pass 1 -an -f null NUL
ffmpeg -i input.mov -c:v libx264 -b:v 1600k -pass 2 -c:a aac -b:a 96k -movflags +faststart output.mp4

On Windows, NUL is the null output target. On macOS and Linux, use /dev/null.

Screen recordings need different tradeoffs

Meeting recordings, tutorials, code demos, and product walkthroughs are not the same as camera footage.

With camera footage, a little softness may be acceptable. With screen recordings, if small text, menus, code, or tables become blurry, the video may become useless.

For screen recordings, I usually think about compression in this order:

• Cut unnecessary waiting time at the start and end.
• Reduce frame rate from 60fps to 30fps if motion is not important.
• Keep resolution high enough for text.
• Increase CRF carefully.

Scale the video while preserving aspect ratio:

ffmpeg -i input.mov -vf scale=1280:-2 -c:v libx264 -crf 24 -preset medium -c:a aac -b:a 96k -movflags +faststart output.mp4

For mostly static UI walkthroughs, 30fps is often enough:

ffmpeg -i input.mov -r 30 -vf scale=1280:-2 -c:v libx264 -crf 24 -preset medium -c:a aac -b:a 96k -movflags +faststart output.mp4

This is where AI can help, as long as you tell it that text readability matters.

Ask AI for check commands too

One habit I recommend: do not ask AI only for the conversion command. Ask it for the inspection commands as well.

Before compression:

ffprobe -hide_banner input.mov

After compression:

ffprobe -hide_banner output.mp4

You do not need to understand every line of output. Start with the basics:

• Is the video codec what you expected?
• Is the audio codec what you expected?
• Did the resolution change correctly?
• Is the duration correct?
• Is the file size close to the target?

This matters because video commands can fail quietly. The command may run, but the audio is missing. The file may be smaller, but the text is unreadable. The output may play locally, but fail in a browser.

AI makes command generation fast. Verification keeps it honest.

When I skip FFmpeg

FFmpeg is powerful. That does not mean I want to open a terminal for every video.

I skip FFmpeg when:

• I only have one or two files.
• I just need to send a video somewhere.
• I do not want to explain a command to someone else.
• I am on a machine without FFmpeg installed.
• The target is simply "make this uploadable."
• I want to set a target size and download the result.

That is where I use VideoCompress as a practical shortcut.

The workflow is simple: upload a video, choose the compression target or settings, wait for the result, and download the compressed file. For a one-off delivery task, that can be faster than installing FFmpeg, asking AI for a command, testing parameters, and repeating the loop.

This is especially useful for meeting recordings, course clips, product demos, social drafts, and quick review videos. In those cases, the real goal is often not "build a perfect encoding pipeline." The goal is "send a video that opens and looks good enough."

Of course, if the file contains customer data, internal meetings, unreleased product screens, or anything sensitive, follow your team's security rules before uploading it to any online tool. If the job needs fully local processing, audit logs, or backend automation, use FFmpeg.

My rule of thumb

Scenario	Better fit
One-off video compression	VideoCompress
Chat, email, Discord, or form upload	VideoCompress
Fixed target size	VideoCompress or FFmpeg two-pass
Dozens of videos	FFmpeg
Server-side transcoding	FFmpeg
Repeatable parameters and logs	FFmpeg
Scripted or CI workflow	FFmpeg

This is not about which tool is more "serious." It is about the shape of the task.

AI vibe coding makes FFmpeg easier to use, but it also makes it easier to skip the thinking. The real time-saver is deciding whether the task deserves engineering.

If you just need to deliver a shareable video, a browser tool may be enough.

If you will repeat the same workflow 50 times, ask AI to help you turn the FFmpeg command into a script.

A better AI + FFmpeg workflow

Here is the workflow I try to use:

1. Describe the goal: who will watch it, where it will be uploaded, target size, and whether text must stay readable.
2. Ask AI for 2-3 candidate commands, not just one.
3. Use ffprobe to inspect input and output.
4. Test on a 10-30 second sample first.
5. Process the full video only after the sample looks right.

Create a 30-second sample:

ffmpeg -ss 00:01:00 -i input.mov -t 30 -c copy sample.mov

Then test compression settings on the sample. It is much faster than re-encoding the full video every time.

Final thought

FFmpeg is not becoming obsolete because of AI coding. It is becoming more accessible.

But the job is still the job: understand the constraint, choose the right tradeoff, verify the output.

Use FFmpeg for engineering problems.

Use the fastest reliable tool for delivery problems.

For me, VideoCompress fits neatly into that second category. When I do not need a long-term video pipeline and only need to compress a video to a shareable size, it is often the lighter option.