Guía de mejores prácticas para comprimir video con FFmpeg (CRF, códecs y más)

La compresión de video con FFmpeg se reduce a equilibrar tres parámetros: CRF (calidad), preset (velocidad) y códec (eficiencia). Esta guía técnica detallada cubre desde la matemática del CRF hasta la codificación en dos pasadas, benchmarks de H.264 vs H.265 vs AV1, y escenarios reales (web, redes sociales, archivo, HLS). Cada comando de esta guía está listo para copiar y pegar.

Entendiendo el CRF (Factor de Tasa Constante)

El CRF es el ajuste más importante para la compresión de video basada en calidad. Le indica al codificador que apunte a un nivel de calidad visual constante, dejando que la tasa de bits varíe según sea necesario. CRF más bajo = mayor calidad = archivo más grande. CRF más alto = menor calidad = archivo más pequeño.

Valores de CRF para H.264 (libx264)

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

La escala CRF para H.264 va de 0 (sin pérdida) a 51 (peor calidad). Esto es lo que producen diferentes valores:

CRF	Nivel de calidad	Caso de uso típico	Tamaño de archivo (relativo al CRF 23)
0	Sin pérdida	Archivo, masters de edición	10-50x más grande
14	Casi sin pérdida	Postproducción profesional	4-6x más grande
18	Visualmente sin pérdida	Entrega de alta calidad, streaming premium	2-3x más grande
20	Excelente	Video web de alta calidad	1.5-2x más grande
23	Buena (predeterminado)	Uso general, entrega web	1x (línea base)
26	Aceptable	Redes sociales, entrega móvil	0.5-0.7x
28	Moderada	Entrega con ancho de banda limitado	0.3-0.5x
32	Baja	Vistas previas, miniaturas	0.15-0.25x
40	Muy baja	Compresión extrema (apenas visible)	0.05-0.1x
51	Peor	No lo uses nunca	Mínimo

El punto óptimo para la mayoría de los casos es CRF 18-28. Por debajo de 18, estás gastando bits en diferencias de calidad que la mayoría de los espectadores no puede percibir. Por encima de 28, los artefactos se vuelven claramente visibles.

Valores de CRF para H.265 (libx265)

H.265 logra la misma calidad visual con aproximadamente un 40-50% menos de tasa de bits que H.264. Sin embargo, la escala CRF varía: CRF 28 en H.265 es aproximadamente equivalente a CRF 23 en H.264.

ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4

CRF (H.265)	CRF equivalente H.264	Nivel de calidad
18	~14	Casi sin pérdida
22	~18	Visualmente sin pérdida
24	~20	Excelente
28	~23	Buena (predeterminado)
32	~26	Aceptable
36	~30	Baja

Cómo elegir el CRF correcto

Un enfoque práctico:

1. Comienza con el predeterminado (23 para H.264, 28 para H.265)
2. Observa la salida — ¿es aceptable la calidad?
3. Ajusta en 2-4 puntos en cualquier dirección
4. Prueba A/B — codifica la misma escena compleja con dos valores de CRF y compara

Las escenas que revelan más los artefactos de compresión son: movimiento rápido, texturas finas (pasto, tela), degradados (cielo, niebla) y escenas oscuras con detalles sutiles. Para una introducción amigable para principiantes, consulta nuestra guía para comprimir video con FFmpeg.

Presets de codificación: velocidad vs calidad

El parámetro preset de FFmpeg controla cuánto tiempo de CPU invierte el codificador en optimizar la compresión. Los presets más lentos logran mejor compresión (archivos más pequeños con la misma calidad) a costa de tiempos de codificación más largos.

Benchmark de presets H.264

Todas las pruebas a continuación usan CRF 23 con un video fuente 1080p a 60 fps (2 minutos):

Preset	Tiempo de codificación	Tamaño del archivo	Calidad (VMAF)
ultrafast	15s	85 MB	92.1
superfast	22s	62 MB	93.8
veryfast	30s	48 MB	94.5
faster	40s	42 MB	95.0
fast	52s	38 MB	95.3
medium	70s	35 MB	95.5
slow	120s	33 MB	95.7
slower	210s	31 MB	95.8
veryslow	450s	30 MB	95.9
placebo	1800s	29.5 MB	95.9

Observaciones clave:

• medium es el predeterminado y el punto óptimo para la mayoría de los flujos de trabajo
• Pasar de medium a slow ahorra ~6% en tamaño de archivo, pero tarda un 70% más
• Pasar de medium a veryslow ahorra ~14%, pero tarda 6.4 veces más
• placebo prácticamente no mejora sobre veryslow — nunca lo uses
• ultrafast produce archivos 2.4 veces más grandes que medium — evítalo para la entrega final

# Buen predeterminado para la mayoría de los casos
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4

# Cuando el tiempo de codificación importa más que el tamaño del archivo
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset fast output.mp4

# Cuando el tamaño del archivo importa más que el tiempo de codificación
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset slow output.mp4

Comportamiento de los presets H.265

Los presets de H.265 siguen la misma nomenclatura, pero la codificación es significativamente más lenta en cada nivel:

Preset	Tiempo H.264	Tiempo H.265	Tamaño archivo H.265
fast	52s	180s	25 MB
medium	70s	300s	22 MB
slow	120s	600s	20 MB

La codificación H.265 tarda aproximadamente 3-5 veces más que H.264 con el mismo preset, pero produce archivos un 30-40% más pequeños con calidad equivalente.

Codificación en dos pasadas

La codificación en dos pasadas te da control preciso sobre la tasa de bits de salida, lo cual es fundamental cuando necesitas alcanzar un tamaño de archivo específico (p. ej., "este video debe pesar menos de 50 MB").

Cómo funciona

• Pasada 1: FFmpeg analiza el video y crea un archivo de log con datos de complejidad
• Pasada 2: FFmpeg usa el log para distribuir los bits de forma óptima — más bits para escenas complejas, menos para las simples

Comando básico de dos pasadas

# Pasada 1 — analizar (la salida se descarta)
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 1 -f null /dev/null

# Pasada 2 — codificar usando los datos del análisis
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 2 output.mp4

Calcular la tasa de bits objetivo

Para que un video quepa en un tamaño de archivo objetivo:

Tasa de bits de video = (Tamaño objetivo en bits - Tamaño de audio en bits) / Duración en segundos

Ejemplo: video de 10 minutos, objetivo de 100 MB, audio a 128 kbps:

Tamaño de audio = 128.000 bps × 600s = 76.800.000 bits = 9.6 MB
Tasa de bits de video = (100 MB - 9.6 MB) × 8.000.000 / 600 = 1.205.333 bps ≈ 1.2 Mbps

ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 1 -c:a aac -b:a 128k -f null /dev/null
ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 2 -c:a aac -b:a 128k output.mp4

CRF vs dos pasadas: ¿cuándo usar cada uno?

Aproximación	Mejor para	Control
CRF	Calidad consistente, tamaño de archivo desconocido	Enfocado en calidad
Dos pasadas	Tamaño de archivo o tasa de bits objetivo	Enfocado en tamaño
CRF + maxrate	Calidad con techo de tasa de bits	Streaming

Para streaming con techo de tasa de bits:

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M output.mp4

Esto apunta a la calidad de CRF 23, pero limita la tasa de bits a 4 Mbps: útil para streaming donde el ancho de banda es limitado.

Comparativa de códecs: H.264 vs H.265 vs VP9 vs AV1

Elegir el códec adecuado implica un equilibrio entre eficiencia de compresión, velocidad de codificación y compatibilidad de reproducción.

Eficiencia de compresión

Con calidad visual equivalente (VMAF 95), tamaños relativos de archivo:

Códec	Tamaño relativo del archivo	Compresión vs H.264
H.264 (libx264)	100%	Línea base
H.265 (libx265)	55-65%	35-45% más pequeño
VP9 (libvpx-vp9)	55-65%	35-45% más pequeño
AV1 (libaom-av1)	40-50%	50-60% más pequeño

Velocidad de codificación

Tiempo relativo de codificación para una fuente 1080p a 60 fps con calidad equivalente:

Códec	Tiempo de codificación (relativo)	Notas
H.264	1x	Rápido, bien optimizado
H.265	3-5x	Significativamente más lento
VP9	5-10x	Muy lento (single-threaded por defecto)
AV1 (libaom)	20-50x	Extremadamente lento
AV1 (SVT-AV1)	3-8x	Implementación AV1 mucho más rápida

Compatibilidad de reproducción (2026)

Códec	Navegadores	Móvil	Smart TVs	Decodificación por hardware
H.264	99%+	99%+	99%+	Universal
H.265	Safari, Edge (parcial)	iOS, Android 5+	Mayoría modernos	Común
VP9	Chrome, Firefox, Edge	Android 5+	Limitado	En crecimiento
AV1	Chrome, Firefox, Edge, Safari 17+	Teléfonos insignia	Limitado	Emergente

Comandos prácticos

# H.264 — máxima compatibilidad
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

# H.265 — 40% más pequeño, buen soporte móvil
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# VP9 — libre de regalías, bueno para web
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -row-mt 1 -c:a libopus -b:a 128k output.webm

# AV1 (SVT-AV1) — mejor compresión, dispositivos modernos
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

Qué códec elegir

Escenario	Códec recomendado	Por qué
Máxima compatibilidad	H.264	Funciona en todos lados
Ahorro de ancho de banda, ecosistema Apple	H.265	Buena compresión, nativo en iOS/macOS
Web primero, libre de regalías	VP9	Soporte Chrome/Firefox, sin licencias
A prueba de futuro, mejor compresión	AV1 (SVT-AV1)	Ahorro del 50%+, soporte en crecimiento
Audiencia mixta	H.264 con fallback H.265/AV1	Sirve el mejor códec por dispositivo

Para más detalles sobre cambiar entre formatos de contenedor, consulta nuestra guía de conversión de formatos de video.

Mejores prácticas para escalar la resolución

Reducir la escala de video correctamente implica más que solo cambiar la resolución.

Resoluciones objetivo comunes

Nombre	Resolución	Tasa de bits típica (H.264)	Tasa de bits típica (H.265)
4K UHD	3840x2160	15-30 Mbps	8-15 Mbps
1440p	2560x1440	8-15 Mbps	4-8 Mbps
1080p Full HD	1920x1080	4-8 Mbps	2-4 Mbps
720p HD	1280x720	2-4 Mbps	1-2 Mbps
480p SD	854x480	1-2 Mbps	0.5-1 Mbps
360p	640x360	0.5-1 Mbps	0.3-0.5 Mbps

Escalado con preservación de relación de aspecto

Usa siempre -1 para una dimensión para mantener la relación de aspecto, y -2 para asegurarte de que el valor sea divisible por 2 (requerido por la mayoría de los códecs):

# Escalar a ancho 720p, calcular alto automáticamente (divisible por 2)
ffmpeg -i input.mp4 -vf "scale=1280:-2" -c:v libx264 -crf 23 output.mp4

# Escalar a alto 1080, calcular ancho automáticamente
ffmpeg -i input.mp4 -vf "scale=-2:1080" -c:v libx264 -crf 23 output.mp4

Calidad del filtro de escalado

FFmpeg ofrece múltiples algoritmos de escalado. El predeterminado (bilinear) es adecuado para la mayoría de los casos, pero para la mejor calidad al reducir escala, usa Lanczos:

# Reducción de escala de alta calidad con Lanczos
ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos" -c:v libx264 -crf 23 output.mp4

Algoritmo	Velocidad	Calidad de reducción	Mejor para
fast_bilinear	Más rápido	Baja	Procesamiento en tiempo real
bilinear	Rápido	Moderada	Predeterminado, uso general
bicubic	Medio	Buena	Necesidades de calidad moderada
lanczos	Más lento	Óptima	Entrega final, calidad crítica
spline	Más lento	Excelente	Alternativa a Lanczos

No aumentes la escala

Como regla general, nunca aumentes la escala de un video. Codificar una fuente de 720p como 1080p desperdicia ancho de banda sin agregar detalle real. Si debes aumentar la escala, mantenla mínima y usa Lanczos:

# Si debes aumentar la escala (evítalo cuando sea posible)
ffmpeg -i input_720p.mp4 -vf "scale=1920:1080:flags=lanczos" -c:v libx264 -crf 20 output.mp4

Compresión de audio

El audio a menudo se pasa por alto en los flujos de trabajo de compresión de video, pero optimizarlo puede ahorrar un ancho de banda significativo.

Ajustes de audio recomendados

Caso de uso	Códec	Tasa de bits	Comando
Video web general	AAC	128 kbps	-c:a aac -b:a 128k
Video de alta calidad	AAC	192 kbps	-c:a aac -b:a 192k
Contenido musical	AAC	256 kbps	-c:a aac -b:a 256k
Video WebM/VP9	Opus	128 kbps	-c:a libopus -b:a 128k
Podcast/voz	AAC	64 kbps	-c:a aac -b:a 64k
Podcast/voz (Opus)	Opus	48 kbps	-c:a libopus -b:a 48k

Normalizar el volumen del audio

Los niveles de audio inconsistentes entre videos es un problema común. El filtro loudnorm de FFmpeg normaliza según los estándares de transmisión:

# Normalizar a -16 LUFS (estándar para streaming)
ffmpeg -i input.mp4 -c:v copy -af "loudnorm=I=-16:TP=-1.5:LRA=11" -c:a aac -b:a 128k output.mp4

Eliminar el audio

Si no necesitas audio en absoluto:

ffmpeg -i input.mp4 -an -c:v libx264 -crf 23 output.mp4

Copiar el audio sin re-codificar

Si el audio ya está en un formato adecuado:

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a copy output.mp4

Escenarios reales de compresión

Entrega web (uso general)

El escenario más común: comprimir video para incrustarlo en sitios web:

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -vf "scale=1920:1080:flags=lanczos" \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

Detalles clave:

• -movflags +faststart mueve los metadatos al inicio del archivo, habilitando la reproducción progresiva (esencial para web)
• CRF 23 proporciona un buen equilibrio entre calidad y tamaño
• AAC 128k es suficiente para la mayoría del contenido web

Optimización para redes sociales

Plataformas como Twitter/X, Instagram y TikTok tienen requisitos específicos:

# Optimizado para plataformas sociales (H.264, AAC, fast start)
ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level:v 4.0 \
  -pix_fmt yuv420p \
  -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" \
  -c:a aac -b:a 128k -ar 44100 \
  -movflags +faststart \
  output.mp4

• -profile:v high -level:v 4.0 garantiza amplia compatibilidad
• -pix_fmt yuv420p garantiza la reproducción en todos los dispositivos
• El filtro scale + pad crea un video vertical 9:16 con letterboxing

Archivo (máxima calidad, mínima pérdida)

Para almacenamiento a largo plazo donde el tamaño del archivo es menos importante:

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 16 -preset slow \
  -c:a flac \
  output.mkv

• CRF 16 preserva virtualmente todo el detalle visual
• El audio FLAC es sin pérdida
• El contenedor MKV soporta más códecs que MP4

Streaming (tasa de bits adaptativa con HLS)

Generando múltiples niveles de calidad para streaming adaptativo:

ffmpeg -i input.mp4 \
  -map 0:v -map 0:a -map 0:v -map 0:a -map 0:v -map 0:a \
  -c:v libx264 -crf 22 \
  -c:a aac -b:a 128k \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" \
  -b:v:0 5M -maxrate:v:0 5.5M -bufsize:v:0 10M -s:v:0 1920x1080 \
  -b:v:1 2.5M -maxrate:v:1 2.75M -bufsize:v:1 5M -s:v:1 1280x720 \
  -b:v:2 1M -maxrate:v:2 1.1M -bufsize:v:2 2M -s:v:2 854x480 \
  -f hls -hls_time 6 -hls_list_size 0 \
  -master_pl_name master.m3u8 \
  stream_%v/playlist.m3u8

Script de compresión en lotes

Para procesar un directorio completo de videos:

#!/bin/bash
# 批量压缩目录下所有视频
for f in *.mp4; do
  ffmpeg -i "$f" \
    -c:v libx264 -crf 23 -preset medium \
    -c:a aac -b:a 128k \
    -movflags +faststart \
    "compressed_${f}"
done

Compresión en la nube con FFHub

Todos los comandos de esta guía funcionan directamente con FFHub.io — solo envíalos vía API:

# Comprimir un video en la nube (sin FFmpeg local necesario)
curl -X POST https://api.ffhub.io/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "command": "ffmpeg -i https://example.com/input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart output.mp4"
  }'

Esto descarga el trabajo de codificación intensivo en CPU a la nube, manteniendo libre tu máquina local o servidor. Especialmente útil para transcodificación de video en lotes o cuando ejecutar FFmpeg en tu servidor de aplicaciones afectaría el rendimiento.

Hoja de referencia rápida

Comandos en una línea

# Compresión predeterminada adecuada
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac -b:a 128k -movflags +faststart output.mp4

# Compresión agresiva (archivo más pequeño)
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset fast -c:a aac -b:a 96k output.mp4

# Compresión de alta calidad (archivo más grande)
ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 192k output.mp4

# Compresión máxima con H.265
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# A prueba de futuro con AV1
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

Árbol de decisión

1. ¿Necesitas máxima compatibilidad? Usa H.264
2. ¿Necesitas archivos más pequeños? Usa H.265 (Apple/móvil) o VP9 (web)
3. ¿Necesitas los archivos más pequeños y tienes tiempo? Usa AV1
4. ¿Necesitas un tamaño de archivo específico? Usa codificación en dos pasadas
5. ¿Necesitas calidad consistente? Usa CRF
6. ¿Procesando muchos archivos? Usa preset fast o veryfast
7. ¿Procesando un archivo importante? Usa preset slow

Conclusión

La compresión de video efectiva se reduce a entender y equilibrar tres factores: calidad (CRF), velocidad (preset) y tamaño de archivo (elección del códec). Comienza con los valores predeterminados — CRF 23, preset medium, H.264 — y ajusta según tus requisitos específicos. Prueba con tu contenido real, porque el comportamiento de compresión varía drásticamente entre videos de conversación y secuencias de acción.

Los comandos de esta guía son FFmpeg estándar: funcionarán en tu máquina local, en cualquier servidor o a través de un servicio en la nube como FFHub. Domina estos fundamentos y podrás manejar cualquier desafío de compresión de video que se te presente.

Preguntas frecuentes

¿Qué CRF debo usar para streaming de video?

Para streaming adaptativo HLS / DASH, CRF 21-23 con topes de -maxrate y -bufsize es el estándar. El CRF mantiene la calidad consistente entre cambios de complejidad, mientras el techo de tasa de bits protege contra picos de ancho de banda de los espectadores. Usa CRF 23 para la variante de mayor calidad, CRF 24-25 para calidad media, CRF 26-28 para la variante de menor calidad.

Codificación en dos pasadas vs CRF: ¿cuándo usar cada uno?

Usa CRF cuando te importe la calidad consistente (cualquier flujo web o de archivo). Usa dos pasadas cuando debas alcanzar un tamaño de archivo específico (p. ej., límite de 25 MB de Discord, especificación de tasa de bits de transmisión). Las dos pasadas tardan ~2 veces más que CRF, pero dan control preciso del tamaño. Para streaming con techo de tasa de bits pero comportamiento de calidad primero, combina CRF con -maxrate y -bufsize.

¿Por qué H.265 tarda tanto más que H.264?

H.265 evalúa muchos más tamaños de bloque, modos de predicción y vectores de movimiento por fotograma para lograr su ventaja de compresión del 30-40%. La especificación HEVC es intencionalmente más compleja que H.264 a cambio de esa eficiencia. En la práctica: H.265 con libx265 -preset medium es aproximadamente 3-5 veces más lento que H.264 con libx264 -preset medium para la misma calidad de salida.

¿Está AV1 listo para uso en producción en 2026?

Sí para entrega, con advertencias. Los decodificadores AV1 por hardware ya son comunes en teléfonos insignia, consolas de generación actual y Apple Silicon, pero los dispositivos más antiguos aún necesitan un fallback a H.264. Para la codificación, SVT-AV1 (libsvtav1) es la elección práctica: 3-8 veces más lento que H.264 con calidad equivalente, frente a 20-50 veces más lento para libaom-av1. Netflix, YouTube y Vimeo ya sirven AV1 a clientes compatibles.

¿Cómo comprimo en lotes videos con calidad consistente entre distintas fuentes?

Usa modo CRF, no modo tasa de bits — el CRF se adapta a la complejidad de cada fuente. Un bucle de shell simple con -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart produce calidad percibida uniforme con entradas mixtas. Si también necesitas un techo de tamaño de archivo, agrega -maxrate y -bufsize (p. ej., -maxrate 4M -bufsize 8M).

¿El preset -preset slow realmente hace los archivos más pequeños?

Sí, pero con rendimientos decrecientes. De medium → slow ahorras ~6% en tamaño de archivo con la misma calidad, pero la codificación tarda un 70% más. De medium → veryslow ahorras ~14% para 6.4 veces el tiempo de codificación. placebo es virtualmente idéntico a veryslow — no uses placebo. Los puntos óptimos prácticos son medium (predeterminado), slow (lotes nocturnos, entrega final) y fast (flujos de trabajo en tiempo real o proxy).

Artículos relacionados

• Cómo comprimir video con FFmpeg — Guía amigable para principiantes sobre cómo reducir el tamaño de archivos de video con FFmpeg
• Cómo convertir formatos de video con FFmpeg — Cambia entre MP4, MKV, WebM y otros contenedores con control de códec
• API de transcodificación de video en lotes — Automatiza la compresión de video a gran escala a través de una API en la nube