惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
腾讯CDC
M
MIT News - Artificial intelligence
Y
Y Combinator Blog
L
LangChain Blog
Vercel News
Vercel News
云风的 BLOG
云风的 BLOG
GbyAI
GbyAI
Stack Overflow Blog
Stack Overflow Blog
Microsoft Azure Blog
Microsoft Azure Blog
B
Blog RSS Feed
The GitHub Blog
The GitHub Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
B
Blog
P
Proofpoint News Feed
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园_首页
Google DeepMind News
Google DeepMind News
WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
小众软件
小众软件
IT之家
IT之家
A
About on SuperTechFans
H
Help Net Security

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
How to Encode Video with H.264 (libx264) Using FFmpeg
Javid Jamae · 2026-06-17 · via DEV Community

Javid Jamae

Originally published at ffmpeg-micro.com

H.264 is still the default video codec on the internet. YouTube, Vimeo, Zoom, most browsers, every phone made since 2010. If you're encoding video with FFmpeg and need maximum compatibility, libx264 is the encoder you want.

The trick is picking the right CRF and preset values. Get them wrong and you'll either waste storage on an oversized file or ship a blocky mess your users will notice.

TL;DR

For most web video: -c:v libx264 -crf 23 -preset medium. That's the default for a reason. If you need smaller files, bump CRF to 26-28. If you need higher quality, drop it to 18-20. Slower presets produce smaller files at the same quality but take longer.

What CRF and Preset Do

CRF (Constant Rate Factor) controls quality. It tells FFmpeg "make every frame look this good" and lets the bitrate float to hit that target. Low CRF means high quality and big files. High CRF means lower quality and smaller files.

The libx264 CRF scale runs from 0 (lossless) to 51 (worst). The default is 23.

Preset controls encoding speed. A slower preset spends more CPU time finding better compression, which produces a smaller file at the same quality level. It doesn't improve visual quality. It improves efficiency.

These two settings work independently. CRF picks the quality. Preset picks how efficiently the encoder reaches that quality.

The Basic libx264 Command

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

What each flag does:

  • -c:v libx264 selects the H.264 encoder
  • -crf 23 sets quality (lower = better, default 23)
  • -preset medium balances encode speed and compression (default)
  • -c:a aac -b:a 128k re-encodes audio to AAC at 128kbps

If your input already has AAC audio and you don't want to re-encode it, use -c:a copy instead.

CRF Values by Use Case

Use Case CRF Range File Size vs Default When to Use
Lossless archival 0 10-50x larger Source preservation. Not for delivery.
Visually lossless 17-18 ~2x larger Master copies, professional editing, archival with compression.
High quality delivery 20-22 ~1.3x larger Streaming to large screens, paid video content.
General purpose 23 (default) baseline Web video, social media, most applications.
Smaller files 26-28 ~50% smaller Bandwidth-constrained delivery, batch processing.
Preview / thumbnails 30-35 ~70-80% smaller Quick previews, quality doesn't matter much.

A useful rule: every +6 CRF roughly halves the file size. CRF 23 to CRF 29 cuts your file roughly in half. CRF 23 to CRF 17 roughly doubles it.

Don't go above CRF 30 for anything users will actually watch. Compression artifacts become obvious fast.

Preset Speed vs Compression

Preset Encode Speed File Size (same CRF) Best For
ultrafast ~15x faster ~40-50% larger Testing, live previews, CI pipelines
veryfast ~8x faster ~25% larger Real-time or near-real-time use cases
faster ~5x faster ~15% larger Batch jobs where speed matters
fast ~3x faster ~10% larger Good balance for high-volume pipelines
medium 1x (baseline) baseline General use (default)
slow ~0.5x ~5% smaller Final renders, content you'll serve repeatedly
slower ~0.25x ~8-10% smaller High-value content worth the wait
veryslow ~0.1x ~10-15% smaller Archival. Rarely worth it in practice.

For automation pipelines, medium or fast is usually the right call. Going from medium to veryslow saves maybe 10-15% on file size but takes 10x longer. That math only works if you're encoding once and serving millions of times.

H.264 Profile and Level

libx264 supports three profiles that control which encoding features are used:

  • Baseline - no B-frames, no CABAC. Maximum device compatibility (older phones, embedded players). Worst compression.
  • Main - adds B-frames and CABAC. Good compression, broad compatibility. Still plays on most hardware from 2012+.
  • High - full feature set. Best compression. Default for libx264 and what you should use unless you have a specific device constraint.
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -profile:v high -level 4.1 output.mp4

Level 4.1 supports up to 1080p at 30fps or 720p at 60fps. For 4K, use level 5.1. Most developers don't need to set these manually. libx264 picks sensible defaults based on resolution.

Encoding H.264 via API

If you don't want to install FFmpeg locally or manage encoding infrastructure, you can run the same libx264 command through the FFmpeg Micro API. Same flags, same output. No server to maintain.

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{"url": "https://storage.example.com/input.mp4"}],
    "outputFormat": "mp4",
    "options": [
      {"option": "-c:v", "argument": "libx264"},
      {"option": "-crf", "argument": "23"},
      {"option": "-preset", "argument": "medium"}
    ]
  }'

The API returns a job ID immediately:

{
  "id": "trc_abc123",
  "status": "queued",
  "outputFormat": "mp4",
  "createdAt": "2026-06-17T10:00:00.000Z"
}

Poll GET /v1/transcodes/trc_abc123 until the status is completed, then download the output. FFmpeg Micro handles the infrastructure, codec dependencies, and scaling. You get the same libx264 output without compiling FFmpeg or provisioning servers.

Free tier includes 100 processing minutes. No credit card required.

Common Pitfalls

Using CRF with -b:v at the same time. These are conflicting rate control modes. CRF targets constant quality (variable bitrate). -b:v targets constant bitrate. Pick one. If you set both, -b:v wins and CRF gets ignored.

Forgetting the audio codec. If your input has audio in a format incompatible with MP4 (like Vorbis or PCM), FFmpeg will fail or produce a broken file. Always specify -c:a aac or -c:a copy.

Using GPU encoder flags with libx264. NVENC and VideoToolbox are different encoders with different flag sets. -crf doesn't work with NVENC (use -qp instead). If you see "Option crf not found," you're probably using h264_nvenc instead of libx264.

Assuming CRF values are the same across codecs. CRF 23 in libx264 produces different quality than CRF 23 in libx265 or libvpx-vp9. Each codec has its own scale. For H.264, the default is 23. For H.265, it's 28. They produce roughly equivalent quality at those defaults.

FAQ

What CRF value should I use for YouTube uploads?
CRF 18-20. YouTube re-encodes everything, so uploading a higher quality source gives the re-encoder more to work with. Uploading at CRF 28 means YouTube is compressing already-compressed video, which makes the final result worse.

Is libx264 the same as H.264?
H.264 is the codec standard (also called AVC). libx264 is the open-source software encoder that implements that standard. When you run -c:v libx264 in FFmpeg, you're encoding H.264 video using the x264 encoder.

Should I use H.264 or H.265 for web video?
H.264 if you need maximum compatibility (older browsers, older devices, email players). H.265 if your audience is on modern devices and you want 30-50% smaller files. For a detailed H.265 guide, see our libx265 CRF and preset guide.

Can I use two-pass encoding instead of CRF?
Yes. Two-pass targets a specific file size (constant bitrate). CRF targets constant quality (variable file size). Use CRF when quality matters more than file size. Use two-pass when you have a strict size budget.

What's the difference between -c:v libx264 and -c:v h264_nvenc?
libx264 is CPU-based and produces the best compression at any given quality level. h264_nvenc uses NVIDIA GPU hardware and is much faster but produces larger files at the same perceived quality. For batch pipelines where speed matters more than file size, NVENC wins. For quality-sensitive encoding, libx264 wins.

Last verified: 2026-06-17 against FFmpeg 7.x and FFmpeg Micro API v1