Comprime y Codifica Vídeo con fqmpeg: Todos los Códecs

El cluster C1 de fqmpeg reúne siete verbos que cubren todo el flujo de compresión y codificación: compress para el H.264 del día a día, encode-h265 / encode-av1 / encode-vp9 para los códecs modernos, encode-prores y encode-dnxhd para los intermedios de edición, y bitrate para controlar el tamaño final por bitrate. Todos los comandos tienen valores por defecto verificados en el código, imprimen la invocación de FFmpeg subyacente con --dry-run y rechazan entradas inválidas antes de que FFmpeg arranque.

Esta guía recorre cada comando — qué hace, qué flags de FFmpeg genera, sus defaults y la regla de nombre de salida — y luego muestra recetas reales que combinan varios verbos en flujos de entrega de extremo a extremo. Todo lo de abajo está verificado contra el código de src/commands/ en fqmpeg 3.0.1.

Lo que vas a obtener de esta guía

• Qué verbo elegir para qué trabajo (matriz de decisión)
• Defaults, rangos y nombres de salida de cada comando
• El comando exacto de FFmpeg que cada verbo genera (salida --dry-run verificada)
• Cuatro recetas end-to-end que encadenan compresión con otros clusters

Selección de Códec: Qué Verbo Para Qué Trabajo

La elección de códec es primero una decisión de entrega, luego de calidad y por último de tiempo de CPU. La tabla rápida:

Para profundizar en los trade-offs entre AV1, H.265 y H.264 — velocidad de codificación, soporte de hardware, licencias — mira la comparación AV1 vs H.265 vs H.264 y la guía de compresión de vídeo.

Los dos cortes prácticos importantes:

1. Códecs de entrega vs. códecs de edición. Los de entrega (H.264, H.265, AV1, VP9) maximizan compresión — archivos pequeños, scrubbing pesado, decodificación cara. Los de edición (ProRes, DNxHR) hacen lo contrario — archivos grandes, scrubbing por fotograma, calidad casi sin pérdida. No eliges "el mejor códec." Eliges el códec correcto para el siguiente paso del pipeline.
2. CRF vs. bitrate. Los cuatro encoders de entrega usan CRF (calidad constante) por defecto, lo que permite al encoder gastar más bits en escenas duras. Usa bitrate solo cuando tienes un presupuesto fijo real — el límite de 25 MB de Discord, un embed con tope de tamaño, un objetivo de ancho de banda fijo en streaming.

Códecs de Entrega: H.264, H.265, AV1, VP9

compress — H.264 / x264 (entrega por defecto)

El verbo del día a día. H.264 es el códec que cualquier dispositivo de la última década puede reproducir, incluido el iPhone de 2012 y la Smart TV que no recibe firmware desde hace seis años.

• Código: src/commands/compress.js
• Encoder de FFmpeg: libx264
• Audio: re-codificado a AAC (recomendado para contenedor .mp4)
• Flag de contenedor: -movflags +faststart (mueve el átomo moov al inicio del archivo para que se pueda transmitir sin esperar al final)

Opciones:

¹ Presets permitidos: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo.

Nombre de salida por defecto: input-compressed.mp4 (extensión heredada del input).

$ npx fqmpeg compress input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -movflags +faststart input-compressed.mp4

Ejemplos con override:

# Más calidad, encode más lento
npx fqmpeg compress input.mp4 --crf 18 --preset slow

# Borrador rápido para revisión
npx fqmpeg compress input.mp4 --crf 28 --preset veryfast

encode-h265 — H.265 / HEVC

La misma familia x264/x265 que libx264, pero produce archivos aproximadamente un 30–50 % más pequeños a la misma calidad. El precio es la velocidad de codificación (bastante más lenta que x264 a presets equivalentes) y las licencias — las patentes de H.265 siguen vigentes, motivo por el que los navegadores no lo decodifican nativamente. Úsalo para archivo, backup de 4K del móvil y distribución dentro del ecosistema Apple, donde HEVC se reproduce nativamente.

• Código: src/commands/encode-h265.js
• Encoder de FFmpeg: libx265
• Audio: copiado (-c:a copy) — mantiene el stream de audio original
• Contenedor: Matroska (.mkv) — soporta HEVC sin fricción a nivel de contenedor

Nombre de salida por defecto: input-h265.mkv.

$ npx fqmpeg encode-h265 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a copy input-h265.mkv

encode-av1 — AV1 (libaom)

AV1 es el códec moderno libre de royalties impulsado por Google, Netflix, Apple y el resto de la Alliance for Open Media. A igual calidad es ~30 % más pequeño que H.265 y ~50 % más pequeño que H.264. La pega: libaom-av1 es muy lento. Un clip 1080p de 10 minutos puede tardar una hora en un portátil normal. Para producción, el encoder SVT-AV1 es más rápido — mira la guía de ajustes óptimos de SVT-AV1 en FFmpeg 8 para esa ruta.

• Código: src/commands/encode-av1.js
• Encoder de FFmpeg: libaom-av1
• Audio: copiado (-c:a copy)
• Contenedor: Matroska (.mkv)

El encoder también recibe -b:v 0 automáticamente — esto le indica a libaom-av1 que respete el CRF en lugar de tratarlo como tope sobre un bitrate implícito.

Nombre de salida por defecto: input-av1.mkv.

$ npx fqmpeg encode-av1 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 -cpu-used 6 -c:a copy input-av1.mkv

Para un encode largo lo normal es bajar --speed a 4 o 5 y dejarlo correr. La velocidad 6 es el default de fqmpeg porque equilibra tiempo de pared en clips cortos.

encode-vp9 — VP9 / WebM

VP9 es el códec de Google previo a AV1. AV1 lo está reemplazando en pipelines nuevos, pero VP9 sigue siendo útil en dos casos: (1) navegadores antiguos y embeds donde la decodificación AV1 por hardware aún no llegó, y (2) contenedores WebM, que la mayoría de navegadores prefieren para etiquetas <video> cuando MP4 no es opción.

• Código: src/commands/encode-vp9.js
• Encoder de FFmpeg: libvpx-vp9
• Audio: re-codificado a Opus (-c:a libopus) — Opus es el emparejamiento canónico para VP9 en WebM
• Contenedor: WebM (.webm)

Como AV1, el comando añade -b:v 0 para que CRF sea la única perilla de calidad.

Nombre de salida por defecto: input-vp9.webm.

$ npx fqmpeg encode-vp9 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 31 -b:v 0 -cpu-used 1 -c:a libopus input-vp9.webm

Codificación por Bitrate Objetivo

bitrate — H.264 con bitrate objetivo (control de tamaño)

Cuando tienes un tope de tamaño duro — el límite de 25 MB del plan gratuito de Discord, un CMS que rechaza archivos por encima de cierto tamaño, un SLA sobre ancho de banda — CRF no ayuda, porque CRF no sabe nada de tu tope. bitrate te deja fijar las tasas de vídeo y audio explícitamente, en la notación de bitrate normal de FFmpeg.

• Código: src/commands/bitrate.js
• Encoder de FFmpeg: libx264 (igual que compress, solo que en modo bitrate en lugar de modo CRF)
• Audio: re-codificado a AAC al bitrate de audio especificado
• Flag de contenedor: -movflags +faststart

El validador rechaza tasas mal formadas con un mensaje claro: Error: video bitrate must be a number with optional k/K/m/M suffix (e.g. 1M, 2500k, 500000), got "...".

Nombre de salida por defecto: usa la tasa como sufijo: input-2M.mp4 para 2M, input-2500k.mp4 para 2500k.

$ npx fqmpeg bitrate input.mp4 2M --dry-run

  ffmpeg -i input.mp4 -c:v libx264 -b:v 2M -c:a aac -b:a 128k -movflags +faststart input-2M.mp4

Para calcular la tasa correcta a partir de un tope de tamaño: tamaño_bits / duración_segundos = bitrate_total. Resta tu bitrate de audio y eso es tu <rate> de vídeo. La receta 2 más abajo lo muestra en práctica.

Códecs de Edición: ProRes y DNxHR

Estos dos son distintos a todo lo de arriba. Son códecs intermedios — pensados para editar en una línea de tiempo, no para entregar al espectador. Los archivos pesan 5–10× más que H.264 a calidad visual equivalente, pero el encoder está optimizado para scrubbing exacto por fotograma y re-codificación casi sin pérdida a través de varias pasadas de edición. Si alguna vez intentaste editar H.264 directamente en Premiere y viste cómo la timeline tartamudea, esta es la solución.

encode-prores — Apple ProRes (Final Cut, Premiere, Resolve)

ProRes es el códec intermedio de Apple y el estándar de facto para los flujos de Final Cut Pro y DaVinci Resolve. Premiere y Avid también lo manejan bien.

• Código: src/commands/encode-prores.js
• Encoder de FFmpeg: prores_ks (la variante kostya-sampler, que produce los archivos más compatibles)
• Audio: PCM 16-bit (-c:a pcm_s16le) — sin comprimir, convención de los códecs de edición
• Contenedor: QuickTime (.mov)

Tabla rápida de perfiles:

• proxy (~45 Mbps a 1080p) — pequeño, rápido, solo edición borrador
• lt (~102 Mbps) — "light," bueno para edición offline
• standard (~147 Mbps) — calidad broadcast
• hq (~220 Mbps) — el default de fqmpeg, master de finishing típico
• 4444 (~330 Mbps) — añade canal alpha, usado para compositing de VFX

Nombre de salida por defecto: input-prores.mov.

$ npx fqmpeg encode-prores input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v prores_ks -profile:v 3 -c:a pcm_s16le input-prores.mov

encode-dnxhd — Avid DNxHR (flujos de Avid Media Composer)

DNxHR es el códec intermedio de Avid — el equivalente a ProRes en su ecosistema. Ojo: el verbo se llama dnxhd pero el códec que se produce es DNxHR (el sucesor independiente de resolución del antiguo DNxHD). El sufijo del nombre de salida es dnxhr para reflejarlo.

• Código: src/commands/encode-dnxhd.js
• Encoder de FFmpeg: dnxhd (escribe perfil dnxhr_* vía -profile:v)
• Audio: PCM 16-bit a 48 kHz obligatorio (-c:a pcm_s16le -ar 48000) — la spec DNxHR/MXF no acepta audio a 44.1 kHz
• Contenedor: MXF (.mxf) — el contenedor profesional de broadcast

Tabla rápida de perfiles:

• lb (low bandwidth) — proxy / edición offline
• sq (standard quality) — edición online broadcast
• hq (high quality) — default de fqmpeg, master de finishing en 8-bit 4:2:2
• hqx (high quality extended) — 10-bit 4:2:2, master apto para grading
• 444 (4:4:4) — añade alpha para compositing, similar a ProRes 4444

Nombre de salida por defecto: input-dnxhr.mxf.

$ npx fqmpeg encode-dnxhd input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le -ar 48000 input-dnxhr.mxf

Recetas Reales

Cada receta encadena varios verbos de fqmpeg (cruzando clusters) en un flujo de entrega real.

Receta 1: Entrega multi-plataforma desde un solo master

Tienes un master 4K terminado y necesitas tres formatos de distribución: H.264 para compatibilidad (embed web, email, paste en Discord), AV1 para YouTube (subida más pequeña, mejor escalera ABR del lado de YouTube) y VP9/WebM para una etiqueta <video> autoalojada en un sitio estático.

# Entrega de compatibilidad (H.264 .mp4)
npx fqmpeg compress master-4k.mp4 --crf 22 --preset slow

# Candidato de subida a YouTube (AV1 .mkv) — lento pero merece la pena
npx fqmpeg encode-av1 master-4k.mp4 --crf 28 --speed 4

# Embed web autoalojado (VP9 .webm)
npx fqmpeg encode-vp9 master-4k.mp4 --crf 31

Ejecuta los tres desde el mismo master y obtienes master-4k-compressed.mp4, master-4k-av1.mkv y master-4k-vp9.webm lado a lado. El encode lento de AV1 va en background mientras haces el resto.

Receta 2: Cumplir el tope de 25 MB de Discord

Discord rechaza archivos de más de 25 MB en el plan gratuito. Objetivo: codificar un clip de 90 segundos para caber bajo el tope, con audio a 128 kbps.

# Paso 1: probar el origen para conocer la duración
npx fqmpeg duration input.mp4
# 0:01:30.000000  → 90 segundos

# Paso 2: cuentas
# Presupuesto: 25 MB = 200,000,000 bits = 200,000 kbits
# Reserva audio: 128 kbps × 90 s = 11,520 kbits
# Presupuesto vídeo: 200,000 - 11,520 = 188,480 kbits ÷ 90 s ≈ 2090 kbps
# Redondea a la baja con margen → 1900k

# Paso 3: codificar
npx fqmpeg bitrate input.mp4 1900k

El comando duration es del set Inspection (también disponible en el artículo hub). El patrón es general: probar → calcular → codificar. Para batches largos, envuelve la cuenta en un script de shell.

Receta 3: Pipeline edita-y-entrega

Tienes 4K en bruto del móvil. Quieres editarlo en Final Cut y entregar un H.264 .mp4 para YouTube. Ir directo H.264 → editor → re-codificar pierde calidad en cada pasada; meter ProRes intermedio lo arregla.

# Paso 1: convertir el bruto a ProRes para edición
npx fqmpeg encode-prores raw-phone.mp4 --profile lt
# → raw-phone-prores.mov  (edita esto en Final Cut)

# (Edita en Final Cut, exporta la timeline ProRes como final-edit.mov)

# Paso 2: comprimir el export editado a H.264 para YouTube
npx fqmpeg compress final-edit.mov --crf 20 --preset slow
# → final-edit-compressed.mp4

--profile lt para el proxy mantiene los archivos en un tamaño manejable. Si tienes material 4444 con alpha (p. ej. tomas con chroma key), usa --profile 4444.

Receta 4: Archivo HDR → entrega SDR

El origen es HDR (HLG o HDR10) pero necesitas una entrega SDR para espectadores generales. Mapea tonos primero, luego codifica con H.265 para el archivo más pequeño.

# Paso 1: tone-map HDR → SDR (cluster C6, verbo aparte)
npx fqmpeg hdr-to-sdr hdr-source.mp4
# → hdr-source-sdr.mp4

# Paso 2: codificar a H.265 para archivo
npx fqmpeg encode-h265 hdr-source-sdr.mp4 --crf 26 --preset slow
# → hdr-source-sdr-h265.mkv

hdr-to-sdr vive en el cluster de color C6. Para la matemática del tone mapping subyacente, mira tone mapping HDR a SDR con FFmpeg.

Nota Sobre Aceleración por Hardware

Los siete verbos usan por defecto encoders de software (libx264, libx265, libaom-av1, libvpx-vp9, prores_ks, dnxhd). Los equivalentes acelerados por hardware (NVENC para NVIDIA, QSV para Intel, VideoToolbox para macOS) son drásticamente más rápidos pero no están en el camino por defecto porque:

1. Producen salida diferente (a menudo peor) a igual bitrate que los encoders de software
2. Requieren combinación específica de GPU + driver
3. Las perillas de calidad no son 1:1 — NVENC tiene su propia escala de preset/calidad

Si necesitas NVENC/QSV, ejecuta --dry-run en el verbo que quieras, copia el comando impreso y sustituye el nombre del encoder por el de hardware (h264_nvenc, hevc_nvenc, h264_qsv, etc.). La guía de codificación por GPU cubre qué añadir para cada vendor.

Preguntas Frecuentes

¿Qué códec elijo para YouTube?

YouTube re-codifica todo lo que subes, así que el objetivo es darle el origen más limpio posible. AV1 (encode-av1) es ahora mismo el mejor formato de subida si tienes el tiempo de CPU — YouTube preserva más calidad en los ingestos AV1 que en H.264. H.264 con CRF 18 y --preset slow es el fallback práctico cuando AV1 tarda demasiado. Evita subir archivos limitados por bitrate; el encoder de YouTube agrava la pérdida.

¿Por qué fqmpeg usa CRF por defecto en lugar de bitrate?

CRF deja al encoder asignar bits donde hacen falta (más a las escenas de acción, menos a las estáticas), lo que produce mejor calidad visual a un tamaño promedio menor que bitrate fijo para el mismo contenido. Solo quieres modo bitrate cuando hay una restricción externa — tope de tamaño, ancho de banda en streaming — que CRF no puede tener en cuenta. Para eso está bitrate.

¿Estos comandos están acelerados por hardware?

No, usan encoders de software por defecto. Mira "Nota Sobre Aceleración por Hardware" arriba para sustituir manualmente con NVENC/QSV usando --dry-run.

¿Por qué encode-h265 por defecto es CRF 28 pero compress es CRF 23?

x264 y x265 usan escalas perceptuales distintas — no son el mismo número. Como regla aproximada, CRF 23 en x264 ≈ CRF 28 en x265 para calidad visual similar. Los defaults de fqmpeg coinciden con la recomendación de "good quality" documentada de cada encoder, no un número uniforme entre encoders.

¿Necesito ProRes y DNxHR a la vez?

Elige uno según el editor: ProRes si estás en Final Cut, Premiere o DaVinci Resolve; DNxHR si estás en Avid Media Composer. Son funcionalmente equivalentes como códecs intermedios; la elección la marca el ecosistema, no la técnica.

¿Puedo codificar a dos pasadas con bitrate?

bitrate en sí es de una pasada. Para dos pasadas, usa --dry-run para imprimir el comando y luego ejecuta dos pasadas a mano: ffmpeg ... -pass 1 -f null /dev/null y luego el mismo comando con -pass 2 output.mp4. Para la mayoría de casos de tope de tamaño, una pasada es lo bastante cercana como para que los 30–60 segundos extra de dos pasadas no compensen.

¿Por qué encode-av1 es tan lento? ¿Hay un camino más rápido?

libaom-av1 es el encoder de referencia — correcto pero lento. La ruta de producción más rápida es SVT-AV1, que es 5–10× más rápido a calidad comparable. SVT-AV1 todavía no es un verbo de fqmpeg; para los flags subyacentes mira ajustes óptimos de SVT-AV1 en FFmpeg 8.

¿Puedo procesar una carpeta entera por lotes?

Sí — fqmpeg es shell-friendly. El patrón estándar es un bucle for en bash:

for f in *.mp4; do npx fqmpeg compress "$f" --crf 22; done

O find -exec para directorios anidados. Cada invocación sale con el código de salida de FFmpeg, así que puedes encadenar con && o pasar a xargs -P para encoding en paralelo. Para un pipeline más estructurado (manifests, retries, subidas a S3), la guía de FFmpeg + Python para automatización por lotes cubre el enfoque desde Python.

Conclusión

Los siete verbos de C1 cubren las decisiones realistas de compresión y codificación que vas a tomar:

• compress para "comprime esto y ya" — H.264 por defecto
• encode-h265 / encode-av1 / encode-vp9 para entrega específica por códec
• encode-prores / encode-dnxhd para intermedios de edición
• bitrate para topes de tamaño fijos

Cada verbo imprime el comando FFmpeg subyacente con --dry-run, así que puedes copiarlo para aprender la sintaxis, meterlo en un paso de CI o modificarlo (por ejemplo, cambiar a NVENC) sin re-derivar todo desde cero. Para volver al mapa general de fqmpeg, ve al hub guía completa de fqmpeg.