por Tenemos un vídeo que queremos enviar y ocupa demasiado. Lo comprimimos, esperamos a que termine y descubrimos que pesa casi lo mismo o que el texto de la pantalla ya no se puede leer. El problema no suele ser que falte un comando, sino que estamos cambiando opciones sin saber qué queremos conservar.
Con FFmpeg podemos preparar una copia más pequeña desde la terminal. Vamos a separar tres cosas: cambiar el formato del archivo, volver a comprimir el vídeo y reducir su resolución. Cada una tiene un efecto distinto y no necesitamos hacerlas todas.
El original se queda donde está. Antes de convertir una grabación larga, prepararemos una prueba corta y comprobaremos imagen, sonido y tamaño.
Icono de GNOME Project, bajo CC BY-SA 3.0.
Instalar FFmpeg y comprobar el archivo
En Ubuntu y Linux Mint lo tenemos en los repositorios:
sudo apt update
sudo apt install ffmpeg
ffmpeg -version
El paquete también incluye ffprobe, que permite consultar el archivo sin convertirlo. La documentación de ffprobe describe las opciones de inspección. Para ver los datos que nos interesan:
ffprobe -v error \
-show_entries format=duration,size:stream=index,codec_type,codec_name,width,height \
-of json "video-original.mp4"
Sustituimos el nombre por nuestro archivo. En la salida buscamos la duración, el tamaño en bytes, la resolución de la pista de vídeo y el códec. Puede haber varias pistas de sonido o subtítulos, así que conviene identificarlas antes de crear una copia que no las conserve todas.
Si el original ya tiene una compresión fuerte y una resolución pequeña, no esperaría una reducción enorme sin perder información. Un vídeo de una cámara y una grabación de escritorio tampoco necesitan el mismo tratamiento: en la segunda, las letras pequeñas pueden ser lo más importante.
Esta guía utiliza una conversión habitual de vídeo SDR a H.264 y sonido AAC. No es una receta para conservar HDR, vídeo profesional de diez bits o pistas especiales de un proyecto de edición.
MP4 y H.264 no son lo mismo
MP4 es el contenedor, el archivo que agrupa las pistas. H.264 es una forma de codificar el vídeo que puede ir dentro de él. Cambiar la extensión de MKV a MP4 no vuelve a comprimir automáticamente la imagen.
La opción de copia de pistas de FFmpeg permite cambiar de contenedor sin volver a codificar. Por ejemplo, si las pistas de origen son compatibles con MP4:
ffmpeg -n -i "video-original.mkv" \
-map 0:v:0 -map '0:a:0?' \
-c copy "video-en-mp4.mp4"
Seleccionamos el primer vídeo y el primer audio, si existe. -n impide sobrescribir un archivo de salida que ya tengamos. No borra el original ni genera una compresión nueva.
Esta operación puede resolver un problema de formato, pero el tamaño normalmente seguirá siendo parecido. Si el códec no encaja en el contenedor de destino, veremos un error y habrá que decidir si recodificamos esa pista.
Hacer una copia con H.264 y AAC
Para reducir tamaño mediante recodificación, empezamos con una configuración que podamos entender:
ffmpeg -n -i "video-original.mp4" \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 -crf 23 -preset medium -threads 2 \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart "video-reducido.mp4"
libx264 codifica la imagen como H.264. -crf 23 es el punto de partida para decidir la calidad de esta prueba, no una cifra que garantice el mismo resultado en todos los vídeos. medium elige un ajuste de velocidad del codificador.
El sonido se vuelve a codificar en AAC a 128 kbit/s. No significa que ese valor sea suficiente para cualquier material de audio. Aquí buscamos una copia práctica para compartir, no sustituir un máster musical.
yuv420p prepara una salida de ocho bits con una representación de color habitual en reproducción. La opción faststart reorganiza información del MP4 para facilitar que empiece a reproducirse antes de descargarlo entero. No mejora la calidad ni es un método de compresión adicional.
El límite de dos hilos evita utilizar toda la CPU en la primera prueba. Podemos adaptarlo a nuestro equipo, sin suponer que el programa acelerará de forma proporcional al número elegido.
Ajustar el CRF mirando el resultado
Con este codificador, un CRF más bajo busca conservar más calidad y normalmente necesita más espacio. Un valor más alto admite mayor pérdida para reducir el tamaño. Podemos probar 23 y después 28 sobre el mismo fragmento, manteniendo las demás opciones.
No presentaría ninguno como «sin perder calidad». La recodificación con estos valores es con pérdida, aunque la diferencia pueda no molestar en el uso previsto. La documentación de libx264 en FFmpeg permite consultar sus opciones.
Para comparar, mantendría el original como entrada de cada prueba. Si comprimimos una copia ya reducida y después otra, acumulamos conversiones y dejamos de comparar el mismo punto de partida.
Revisamos una escena con movimiento, otra con detalles y, si es una grabación de escritorio, una con texto. Que una imagen quieta se vea bien no demuestra cómo se comportará todo el archivo.
Si sólo subimos el CRF hasta que el vídeo cabe en el correo, podemos conseguir el tamaño deseado a costa de hacerlo poco útil. En ese caso quizá compense reducir resolución, recortar una parte que sobra o utilizar otro medio de envío.
Reducir la resolución cuando tenga sentido
Si el original tiene 1920 píxeles de ancho y no necesitamos conservar esa resolución, podemos probar una copia de 1280:
ffmpeg -n -i "video-original.mp4" \
-map 0:v:0 -map '0:a:0?' \
-vf "scale=1280:-2" \
-c:v libx264 -crf 23 -preset medium -threads 2 \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart "video-1280.mp4"
El filtro scale ajusta el ancho. -2 calcula una altura proporcional y divisible por dos. En una entrada de 1920 × 1080 obtenemos 1280 × 720. Las opciones de escala explican ese comportamiento.
No usaría esta orden sin mirar la entrada: si nuestro vídeo ya es más pequeño, estaríamos ampliándolo. Y en un vídeo vertical, esos números no representan la misma decisión que en uno horizontal.
Reducir resolución puede ahorrar bastante tamaño, pero también elimina detalle. Para enseñar una ventana de código, quizá prefiramos conservar los píxeles y aceptar un archivo mayor. Para un clip que sólo se verá en una pantalla pequeña, puede ser una elección razonable.
Probar un fragmento antes de convertirlo entero
Si la grabación dura varios minutos, podemos tomar treinta segundos desde una zona representativa:
ffmpeg -n -ss 00:00:10 -i "video-original.mp4" -t 30 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 -crf 23 -preset medium -threads 2 \
-pix_fmt yuv420p \
-c:a aac -b:a 128k "prueba-crf23.mp4"
El punto de inicio y la duración deben caber en nuestro archivo. Después repetimos con otro nombre y el ajuste que queramos comparar. Usamos el mismo fragmento, no una parte sencilla para una configuración y otra difícil para la siguiente.
En una prueba con un patrón sintético propio de ocho segundos y sonido se generaron tres salidas: H.264 con CRF 23, CRF 28 y una copia de 1280 × 720. Las tres conservaron vídeo, audio y duración. El archivo con CRF 28 ocupó menos que el de 23, y la copia de menor resolución volvió a reducir el tamaño.
Eso comprueba el procedimiento. No convierte la reducción de ese patrón en un porcentaje aplicable a nuestras películas, ni demuestra que una persona no perciba diferencias.
Comprobar imagen, sonido y pistas
Podemos comparar tamaños en bytes con:
stat -c '%n: %s bytes' \
"video-original.mp4" "video-reducido.mp4"
Después abrimos la copia con un reproductor multimedia para Linux y escuchamos varias partes. Comprobamos que no falta sonido, que se mantiene la duración esperada y que la imagen sirve para lo que necesitamos.
Las órdenes de esta guía conservan el primer vídeo y el primer audio. No incluyen automáticamente el resto de idiomas, subtítulos o adjuntos. Si necesitamos más pistas, debemos elegirlas con -map y revisar qué formatos admite la salida.
Tampoco daría por terminado el trabajo porque el reproductor del ordenador lo abra. Si la copia va a una televisión, una web o un móvil concreto, probamos ese destino antes de descartar el original.
Si el archivo sigue ocupando demasiado
CRF no fija un tamaño exacto. Dos vídeos con la misma duración y el mismo valor pueden necesitar cantidades distintas de datos. Si una plataforma impone un límite estricto, conviene preparar una configuración de bitrate y comprobar la salida, no buscar un CRF que prometa un número de megabytes.
Si FFmpeg dice que no conoce libx264, revisamos con ffmpeg -encoders qué incluye nuestra instalación. No cambiaremos el nombre por cualquier codificador esperando un resultado equivalente.
Si falta el audio, miramos las pistas originales y su selección. Si el resultado apenas reduce espacio, quizá la entrada ya estuviera muy comprimida. Y si hay cambios de color en un archivo HDR, esta conversión básica no es el flujo adecuado para conservarlo.
Lo práctico es quedarnos con una copia que cumpla su objetivo y guardar el original para otros usos. Una compresión que ahorra espacio pero hace ilegible la explicación no nos ha resuelto el problema.
