Si creas vídeos, conviertes archivos existentes o preparas contenido audiovisual para un sitio web, una de las decisiones más importantes es elegir el formato y la configuración de compresión adecuados. El archivo más pequeño posible no es necesariamente el mejor. También debe reproducirse de forma fiable en los navegadores, funcionar en teléfonos inteligentes, decodificarse con eficiencia y conservar una calidad visual suficiente para su finalidad.
Investigué MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, los ajustes preestablecidos del codificador x264, la compatibilidad con navegadores, la decodificación por hardware en dispositivos móviles y la medición de la calidad de vídeo. También realicé experimentos prácticos de compresión: codifiqué el mismo vídeo de origen con distintos valores de CRF y comparé los resultados visualmente y mediante mediciones objetivas.
Finalmente, decidí dar prioridad a MP4 con H.264 cuando un único archivo de vídeo debe funcionar en la mayor variedad práctica de navegadores, teléfonos y aplicaciones externas.
Para los vídeos cortos destinados principalmente a dispositivos móviles, en los que la carga rápida y el tamaño reducido importan más que conservar hasta el último detalle, elegí x264 con CRF 30 después de comprobar que, durante una reproducción normal, no percibía diferencias visuales importantes entre CRF 22 y 30, ni siquiera en un monitor de escritorio grande.
Sin embargo, esta decisión requiere una aclaración fundamental: CRF 30 no es una recomendación para películas, producciones de vídeo de alta calidad ni material en el que sea esencial conservar la máxima fidelidad visual. Para esos usos, un valor bastante más conservador, a menudo cercano a CRF 20, puede ser un mejor punto de partida. No realicé un estudio comparable con largometrajes ni con material cinematográfico de alta calidad, por lo que esos valores deben considerarse puntos de partida para efectuar pruebas por separado.
En este artículo explico los fundamentos técnicos, los resultados reales de compresión, las limitaciones de esos resultados y cómo elegir un formato de vídeo y un nivel de calidad adecuados para tu proyecto.
1. Los contenedores y los códecs de vídeo son cosas diferentes
Antes de comparar MP4 y WebM, es imprescindible entender la diferencia entre un contenedor y un códec.
Un contenedor reúne vídeo, audio, marcas de tiempo y metadatos en un mismo archivo. Un códec de vídeo determina cómo se comprimen y decodifican los fotogramas.
Por ejemplo, un archivo MP4 puede contener vídeo H.264, HEVC o AV1. Aunque compartan la misma extensión, estas combinaciones presentan distintas características de compresión y requisitos de dispositivo.
| Componente | Ejemplos | Función |
|---|---|---|
| Contenedor de vídeo | MP4, WebM, MOV, MKV | Agrupa el vídeo, el audio y los datos de sincronización |
| Códec de vídeo | H.264, HEVC, VP9, AV1 | Comprime y descomprime los fotogramas de vídeo |
| Códec de audio | AAC, Opus, MP3 | Comprime y descomprime el audio |
| Codificador de vídeo | x264, x265, SVT-AV1, libvpx-vp9 | Implementa la compresión de vídeo |
Cambiar la extensión de un archivo de .webm a .mp4 no convierte su códec de vídeo. Del mismo modo, guardar AV1 dentro de MP4 no hace que el vídeo pueda reproducirse en dispositivos que carezcan de soporte para decodificar AV1.
Al hablar de compatibilidad de vídeo, siempre hay que considerar la combinación completa: contenedor, códec de vídeo, códec de audio, perfil del códec, profundidad de bits y entorno de reproducción.
2. MP4 frente a WebM: ¿cuál es mejor para el vídeo web?
Tanto MP4 como WebM son contenedores de vídeo modernos y válidos. Ninguno es superior en todos los casos, porque sus características prácticas dependen de los códecs que contienen.
MP4 con H.264: máxima compatibilidad práctica
Los archivos MP4 con vídeo H.264 y audio AAC cuentan con una trayectoria de compatibilidad excepcionalmente amplia. Son compatibles con los principales navegadores de escritorio y móviles, los reproductores de vídeo de los sistemas operativos y numerosas aplicaciones de terceros.
También suelen ser compatibles con los decodificadores de vídeo por hardware de teléfonos inteligentes y computadoras. Frente a la decodificación por software, la decodificación por hardware puede reducir el uso de CPU, mejorar la eficiencia de reproducción y disminuir el consumo de energía.
Su principal desventaja es la eficiencia de compresión. Los códecs más recientes a menudo pueden conseguir una calidad visual percibida similar con tasas de bits menores.
Sin embargo, H.264 sigue siendo una excelente opción cuando la reproducción fiable importa más que conseguir el archivo más pequeño posible.
WebM con VP9: eficiencia y buena compatibilidad con navegadores
WebM suele contener vídeo VP8, VP9 o AV1, mientras que el audio normalmente se codifica con Opus o Vorbis.
VP9 suele ofrecer una compresión más eficiente que H.264 con una calidad visual comparable. Tiene una amplia compatibilidad con los navegadores actuales, incluidas las versiones modernas de Safari.
Sería incorrecto afirmar que Safari no admite WebM o VP9 en absoluto. La compatibilidad entre navegadores ha mejorado considerablemente con el tiempo.
La limitación más importante se encuentra fuera del navegador. Las aplicaciones nativas de los sistemas operativos, los dispositivos antiguos y el software de terceros pueden gestionar WebM con menos consistencia que un MP4 convencional con H.264.
WebM es una opción sólida para aplicaciones que funcionan únicamente en el navegador y permiten controlar las capacidades de reproducción. Si los visitantes pueden descargar un vídeo y abrirlo con programas muy diversos, MP4/H.264 sigue ofreciendo un comportamiento más predecible.
La diferencia práctica
| Requisito | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Reproducción en navegadores modernos | Excelente | Muy buena |
| Compatibilidad con navegadores y dispositivos antiguos | Generalmente mayor | Depende más del entorno |
| Compatibilidad de los archivos descargados | Generalmente mayor | Menos predecible en aplicaciones nativas |
| Eficiencia de compresión | Buena | A menudo mejor |
| Decodificación por hardware | Muy extendida | Habitual, pero depende del dispositivo |
| Uso más adecuado | Un único archivo ampliamente compatible | Distribución web eficiente con clientes conocidos |
La cuestión principal no es si WebM es un buen formato, sino si sus ventajas de compresión compensan las concesiones en compatibilidad dentro de tu entorno concreto.
3. H.264 frente a H.265, VP9 y AV1: ¿qué códec elegir?
Cada uno de los principales códecs de vídeo presenta un equilibrio distinto entre eficiencia de compresión, coste de codificación, soporte de hardware, compatibilidad de software y licencias.
| Códec | Eficiencia de compresión | Compatibilidad práctica | Uso habitual |
|---|---|---|---|
| H.264 / AVC | Buena | Excelente | Vídeo web general, reproducción móvil y descargas |
| H.265 / HEVC | Generalmente mejor que H.264 | Depende del entorno | Dispositivos Apple compatibles, entornos controlados y vídeo de alta resolución |
| VP9 | Generalmente mejor que H.264 | Muy buena en navegadores modernos | Distribución de vídeo mediante navegador |
| AV1 | Potencial de eficiencia excelente | Cada vez mayor, con limitaciones en dispositivos antiguos | Streaming moderno y dispositivos compatibles |
Estas comparaciones son cualitativas, no una clasificación universal por tasa de bits. La eficiencia real depende del contenido, la implementación del codificador, la calidad buscada, el ajuste preestablecido de codificación y el método de medición.
H.264: maduro, rápido de decodificar y ampliamente compatible
H.264 está muy optimizado y es compatible con una enorme variedad de hardware y software. Su madurez es una ventaja cuando un vídeo debe reproducirse de forma fiable sin necesitar una aplicación especial.
Su punto débil es que los códecs más recientes suelen comprimir el vídeo con mayor eficiencia. H.264 también plantea consideraciones sobre patentes y licencias que conviene revisar en los escenarios de distribución comercial pertinentes.
H.265 / HEVC: mejor compresión con concesiones en compatibilidad
HEVC puede reducir considerablemente la tasa de bits frente a H.264 con una calidad similar. Resulta especialmente atractivo para contenido de alta resolución y entornos en los que se controla la compatibilidad de los dispositivos.
Muchos dispositivos Apple ofrecen muy buen soporte para HEVC. No obstante, la compatibilidad en navegadores y aplicaciones externas varía según el sistema operativo y los componentes de decodificación instalados. Las licencias son otra cuestión que debe tenerse en cuenta.
HEVC puede ser una opción excelente, pero no lo elegiría automáticamente como único formato descargable de un sitio web de uso general.
VP9: una alternativa abierta y práctica
VP9 proporciona una buena compresión y una amplia compatibilidad con los navegadores modernos. Es una opción convincente cuando los vídeos se reproducen dentro del navegador y el entorno es predecible.
Su principal inconveniente en mi caso era la incertidumbre que surge cuando los usuarios descargan los vídeos o los abren en aplicaciones nativas que quizá no admitan WebM o VP9 de manera uniforme.
AV1: eficiencia excelente, pero sin soporte universal por hardware
AV1 es uno de los códecs modernos más prometedores. Puede ofrecer ahorros considerables en tasa de bits respecto a códecs anteriores, y el soporte de decodificación por hardware sigue extendiéndose.
Sin embargo, los dispositivos antiguos pueden carecer de un decodificador AV1 o necesitar decodificación por software. Decodificar vídeo de alta resolución por software puede consumir más CPU y batería, además de provocar problemas de reproducción en dispositivos menos potentes.
Si controlas el entorno de reproducción, merece la pena considerar AV1 seriamente. Si un único archivo debe funcionar tanto en dispositivos nuevos como antiguos y en reproductores externos convencionales, H.264 sigue siendo la opción predeterminada más segura.
La guía de códecs de vídeo de MDN ofrece información útil sobre estos códecs y sus requisitos de compatibilidad con navegadores.
4. ¿Un solo formato de vídeo o varias versiones?
Esta es una de las decisiones de arquitectura más importantes en la distribución de vídeo.
Cuando es posible ofrecer varias versiones, un sitio web puede proporcionar AV1 o VP9 a los dispositivos compatibles y utilizar H.264 como alternativa para otros entornos. Esto puede mejorar la eficiencia de compresión y conservar una amplia cobertura de reproducción.
Sin embargo, mantener varias versiones aumenta la complejidad de la codificación, el almacenamiento, la caché, la validación y la selección del formato de reproducción.
Si necesitas exactamente un archivo de vídeo terminado por cada fuente, suele ser preferible una estrategia que priorice la compatibilidad.
Elegí MP4/H.264 porque quería un solo archivo que funcionara en los principales navegadores, en teléfonos inteligentes y en los flujos habituales de descarga y reproducción, sin depender de formatos alternativos.
Esto no significa que MP4/H.264 ofrezca la mejor compresión, sino que decidí valorar una reproducción predecible por encima de la posible ventaja de tamaño de un códec más reciente.
5. Por qué los vídeos para móviles tienen otras prioridades
La compresión del vídeo debe ajustarse a la forma en que realmente se va a consumir el contenido.
Un vídeo corto que se ve principalmente en un teléfono inteligente tiene requisitos distintos a los de un largometraje que se disfruta en un televisor grande. En el primer caso, puede ser más valioso que cargue rápido y consuma menos datos móviles que conservar los detalles visuales más sutiles. En el segundo, la calidad de imagen puede ser el objetivo principal.
Para los vídeos cortos orientados a móviles, los archivos más pequeños pueden ofrecer varias ventajas:
- Hay que transferir menos datos antes de empezar la reproducción.
- Las descargas pueden terminar antes en conexiones limitadas.
- Se necesita menos espacio de almacenamiento en el dispositivo.
- Los usuarios consumen menos datos móviles.
- La reproducción puede resistir mejor un ancho de banda limitado cuando la tasa de bits del vídeo codificado es menor.
No obstante, un archivo más pequeño no garantiza que el vídeo nunca se detenga para cargar ni se congele. También influyen las variaciones de la red, los picos de tasa de bits, el comportamiento del servidor, el almacenamiento temporal durante la reproducción y el rendimiento de decodificación del dispositivo.
La compatibilidad móvil depende de mucho más que la extensión: importan la decodificación por hardware, el perfil y el nivel del códec, la profundidad de bits, el submuestreo de crominancia, la resolución, la frecuencia de fotogramas y los picos de tasa de bits. Un vídeo que ocupa 390 píxeles CSS de ancho puede abarcar bastantes más píxeles físicos en una pantalla móvil de alta densidad. Por tanto, examinar un fotograma reducido a 390 píxeles de ancho no equivale necesariamente a ver el vídeo original en ese teléfono. Hay que probarlo en dispositivos reales y en condiciones reales de reproducción.
CRF controla la calidad, pero no impone una tasa de bits máxima exacta. Un vídeo complejo puede presentar picos de tasa de bits exigentes aunque su tamaño total sea relativamente pequeño. Si es imprescindible una reproducción fiable en conexiones especialmente lentas, considera límites explícitos de tasa de bits o VBV, restricciones de resolución adecuadas y pruebas con condiciones de red realistas.
El principio fundamental es sencillo: optimiza para la experiencia de visualización prevista, no para un objetivo abstracto de calidad máxima.
6. Cómo funciona CRF en x264: un valor menor da más calidad y uno mayor reduce el tamaño
Después de elegir H.264, el siguiente desafío es decidir cuánto comprimir el vídeo.
En x264, el factor de tasa constante (Constant Rate Factor), o CRF, regula el equilibrio entre la conservación del detalle visual y el tamaño del archivo.
Un CRF menor suele generar archivos más grandes y de mayor calidad. Un CRF mayor suele generar archivos más pequeños, pero con más pérdida por compresión.
CRF no establece una tasa de bits ni un tamaño de salida exactos. El codificador asigna bits según el material de origen, de modo que una escena sencilla y otra llena de detalles pueden producir archivos de tamaños muy diferentes con el mismo CRF.
CRF tampoco determina la compatibilidad básica del decodificador. Dos vídeos H.264 correctamente codificados, uno con CRF 22 y otro con CRF 30, pueden tener el mismo códec, perfil, nivel, formato de píxel, dimensiones y frecuencia de fotogramas.
La diferencia está principalmente en la calidad de compresión y las características de la tasa de bits.
Es importante recordar que los valores de CRF no son directamente comparables entre distintas implementaciones de códecs. Un CRF de 30 en x264 no corresponde a la misma calidad visual que un CRF de 30 en un codificador AV1.
7. Mi experimento real de compresión: de CRF 22 a 32
Quería averiguar hasta qué punto podía comprimir el vídeo antes de que la diferencia empezara a importar durante una reproducción normal.
Utilicé un único vídeo corto, ya comprimido previamente, y generé archivos H.264 de comparación con CRF 22, 24, 26, 28, 29, 30, 31 y 32.
Se conservaron las propiedades principales del vídeo, incluidas la resolución, la frecuencia de fotogramas, la duración y el número de fotogramas. También se mantuvieron constantes los ajustes del codificador para poder evaluar el efecto de cambiar el CRF.
Los resultados mostraron diferencias considerables en el tamaño de los archivos.
| CRF | Tamaño aproximado respecto al original | Qué significa |
|---|---|---|
| 22 | 63% | Compresión más conservadora y mayor conservación del detalle |
| 24 | 49% | Archivo más pequeño, con una pérdida de calidad adicional moderada |
| 26 | 38% | Ahorro adicional que conserva una cantidad considerable de detalle |
| 28 | 30% | Archivo compacto con una similitud relativamente alta respecto al origen |
| 29 | 26% | Compresión más agresiva |
| 30 | 23% | Mi equilibrio preferido para el contenido probado |
| 31 | 21% | Ahorro adicional a costa de una menor fidelidad al original |
| 32 | 19% | El archivo más pequeño de los probados y la mayor pérdida de calidad medida |
Estos porcentajes corresponden al archivo de origen probado y no deben interpretarse como ahorros típicos para cualquier vídeo. Los porcentajes de la tabla se redondearon de forma independiente; para calcular los ahorros relativos con precisión, hay que utilizar los tamaños reales de archivo en lugar de dividir los valores redondeados.
Lo más sorprendente fue que no pude percibir una diferencia visual significativa entre CRF 22 y CRF 30 durante una reproducción normal, ni siquiera en un monitor de escritorio grande.
También examiné versiones con una compresión aún más agresiva, incluida la de CRF 32, sin detectar diferencias importantes durante la reproducción habitual de ese vídeo concreto.
Esta observación era relevante porque los mismos vídeos estaban destinados principalmente a pantallas móviles más pequeñas. Si la pérdida de calidad no resultaba molesta en mi monitor de escritorio, tenía pocos motivos para aceptar una penalización considerable en tamaño por conservar detalles que no mejoraban la experiencia de visualización prevista.
Sin embargo, se trataba de una apreciación subjetiva sobre un tipo concreto de material de origen. No demuestra que todos los usuarios, teléfonos o vídeos se comporten del mismo modo. Las pantallas móviles de alta densidad y las distancias de visualización cortas todavía pueden revelar defectos, especialmente en los detalles finos y los degradados.
8. Las mediciones objetivas confirmaron una pérdida real de calidad
No apreciar diferencias durante la reproducción no significa que dos vídeos sean matemáticamente idénticos.
También comparé los archivos codificados mediante mediciones objetivas de calidad de imagen. Al aumentar el CRF, disminuía la similitud con el original.
En una comparación con reducción uniforme de resolución, destinada a aproximar las condiciones de una pantalla móvil de alta densidad, los valores representativos de SSIM fueron:
| CRF | SSIM aproximado | Tamaño de salida respecto a CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
La tendencia es clara: una compresión más intensa reducía la fidelidad medida del vídeo codificado. Una inspección minuciosa también reveló diferencias sutiles en las líneas finas y las texturas.
Aun así, la experiencia de visualización habitual seguía siendo muy parecida para el material probado. Precisamente por eso deben combinarse las mediciones objetivas con la evaluación subjetiva.
SSIM mide la similitud de las imágenes, no la experiencia visual humana en su conjunto. No puede reflejar por completo los defectos temporales, la nitidez percibida, el comportamiento del movimiento ni la importancia subjetiva de cada detalle visual.
VMAF es otra métrica útil de calidad perceptual. Netflix publicó los modelos VMAF v1 en junio de 2026, incluido uno diseñado para las condiciones de visualización en teléfonos. Estos modelos reconocen explícitamente que la calidad percibida depende, en parte, del tamaño de la pantalla y de la distancia relativa de visualización.
Una muestra codificada de manera conservadora obtuvo, según los datos del estudio, un VMAF medio de aproximadamente 95, pero no se disponía de una serie coherente de valores VMAF para todos los ajustes de CRF agresivos. Por tanto, no utilicé VMAF para afirmar que CRF 30 o 32 alcanzaran un umbral universal de calidad.
La conclusión práctica fue más limitada: el vídeo corto probado soportó extraordinariamente bien una compresión H.264 agresiva durante la reproducción normal.
9. Por qué elegí CRF 30 para vídeos cortos en dispositivos móviles
Tras comparar los archivos, decidí utilizar CRF 30 para vídeos cortos similares, destinados principalmente a dispositivos móviles.
El razonamiento fue sencillo:
- Los vídeos eran cortos y no estaban destinados a ofrecer calidad cinematográfica.
- La carga rápida y las descargas más pequeñas eran importantes.
- No pude apreciar una diferencia significativa entre CRF 22 y 30 en un monitor de escritorio grande.
- CRF 30 generó archivos mucho más pequeños que los ajustes conservadores.
- CRF 32 también ofrecía una calidad visual aceptable en la muestra probada, pero inspiraba menos confianza para materiales más complejos.
Frente a CRF 28, CRF 30 redujo el tamaño del archivo probado aproximadamente un 21%. Frente a CRF 22, la reducción superó el 60%.
Para los vídeos cortos destinados a móviles, cuando se busca una imagen agradable, una carga rápida y un consumo razonable de ancho de banda, era una compensación que merecía la pena.
Pero hay una condición esencial: elegí 30 por el uso real previsto y los resultados del material probado, no porque 30 sea, por naturaleza, el mejor CRF para teléfonos inteligentes.
Un dispositivo móvil no necesita CRF 30. Puede mostrar perfectamente un vídeo codificado con una fidelidad mucho mayor. Utilizar CRF 30 es una decisión consciente de sacrificar algo de fidelidad al original a cambio de archivos más pequeños, cuando esa compensación resulta aceptable.
Antes de aplicarlo a una colección con contenidos muy diferentes, probaría varios vídeos representativos, incluidos los que contienen movimientos difíciles de codificar, escenas oscuras, degradados, texto y texturas finas.
10. Por qué no recomiendo CRF 30 para películas ni vídeos de alta calidad
Esta es la limitación más importante del experimento.
No tomes mi resultado con CRF 30 y lo apliques sin más a largometrajes, vídeos de calidad superior, material profesional o vídeos destinados a pantallas grandes.
Ese contenido puede incluir degradados sutiles, grano cinematográfico, escenas con poca luz, movimientos complejos, superficies con texturas finas y colores cuidadosamente ajustados. Conservar esos detalles puede importar más que ahorrar una cantidad relativamente pequeña de ancho de banda.
Para un vídeo convencional de alta calidad a 1080p, empezaría con un ajuste de x264 mucho más conservador, alrededor de CRF 20, y probaría valores tanto superiores como inferiores según el material.
Un intervalo inicial práctico podría ser CRF 18–22 cuando la fidelidad visual es importante, aunque el valor adecuado puede quedar fuera de ese intervalo en función de la resolución, el contenido y los requisitos.
Esta sugerencia coincide con las recomendaciones de codificación publicadas habitualmente. Por ejemplo, la documentación de HandBrake sobre calidad recomienda aproximadamente RF 20–24 para muchos casos de uso de x264 a 1080p.
No realicé el mismo estudio controlado con largometrajes ni con material cinematográfico de calidad superior. Por tanto, no puedo afirmar que CRF 20 sea óptimo para todos los casos, que CRF 22 siempre resulte suficiente o que una película determinada se vea necesariamente mal con CRF 30.
El método correcto consiste en seleccionar escenas representativas, codificarlas con varios niveles de calidad, compararlas en la pantalla prevista y determinar a partir de qué punto una compresión adicional empieza a perjudicar visiblemente la imagen.
Si el vídeo va a archivarse, editarse de nuevo o utilizarse como fuente para futuras codificaciones, conviene conservar un archivo maestro de alta calidad separado de la versión comprimida destinada a la distribución.
11. Por qué utilicé el ajuste preestablecido veryslow de x264
CRF controla un aspecto de la calidad de compresión, mientras que el ajuste preestablecido de x264 determina cuánto esfuerzo dedica el codificador a buscar decisiones de codificación eficientes.
x264 ofrece ajustes preestablecidos desde los muy rápidos hasta los muy lentos. En general, los más lentos consumen más tiempo de CPU y pueden ofrecer una compresión más eficiente con una calidad visual comparable.
Comparé los ajustes medium y veryslow con el mismo archivo de origen. En el nivel de calidad probado, veryslow generó un archivo más pequeño.
Cuando el vídeo se codifica sin necesidad de hacerlo en tiempo real, una sola vez, y después se reutiliza muchas veces, el tiempo de procesamiento adicional puede merecer la pena.
Por eso elegí -preset veryslow.
Sin embargo, no es la mejor opción para todos los casos. Si es necesario procesar los vídeos de inmediato, los recursos de CPU son costosos o hay una cola enorme de archivos pendientes, slow o medium pueden ofrecer un equilibrio operativo más adecuado.
El ajuste preestablecido modifica principalmente la complejidad de codificación y la eficiencia de compresión. No convierte H.264 en otro códec ni hace que el archivo resultante sea intrínsecamente incompatible con dispositivos móviles.
12. Para vídeos de anime, utilizo el ajuste de animación de x264
Cuando el material de origen contiene animación dibujada o imágenes de estilo anime, utilizo -tune animation con x264.
Es un ajuste distinto de CRF. Los parámetros de optimización específicos modifican determinadas decisiones del codificador para adaptarlas a características visuales concretas. El ajuste de animación está pensado para materiales con contornos dibujados, zonas de color uniforme y movimiento estilizado.
Por tanto, mi preferencia es la siguiente:
- Anime o animación dibujada:
-preset veryslow -tune animation. - Vídeo convencional de acción real: no activar automáticamente el ajuste de animación; empezar con los valores predeterminados del codificador o evaluar por separado un ajuste adecuado.
Conviene entender correctamente lo que hace este ajuste. -tune animation no garantiza una calidad visiblemente mejor ni archivos más pequeños. Modifica el comportamiento del codificador y el resultado depende del material.
Realicé otra comparación con un CRF fijo utilizando el ajuste de animación. En ese caso particular, activarlo aumentó el tamaño del archivo resultante aproximadamente un 6% y mejoró ligeramente la similitud de imagen medida. La diferencia visual fue pequeña.
La comparación principal de tamaños entre CRF 22 y 32 se hizo sin el ajuste de animación. Por eso, no debe suponerse que los tamaños y las relaciones de compresión exactos de aquel experimento se mantengan al activar -tune animation.
Aun así, para contenido de anime prefiero utilizar el ajuste específico de animación y evaluar el tamaño y la calidad resultantes como parte del perfil de codificación de ese contenido.
Los ajustes de optimización del codificador deben considerarse adaptaciones dependientes del contenido, no mejoras universales de calidad.
13. Mi configuración recomendada de FFmpeg para vídeos cortos de anime destinados a móviles
Para un vídeo de anime SDR convencional que realmente necesite transcodificación, este comando representa el perfil que utilizaría como punto de partida:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Este comando deja claras las decisiones principales:
-c:v libx264utiliza el codificador H.264 por software.-preset veryslowprioriza la eficiencia de compresión frente a la velocidad de codificación.-tune animationactiva ajustes adaptados a la animación.-crf 30aplica el objetivo agresivo de calidad constante elegido para este tipo de vídeo corto.-profile:v highselecciona un perfil H.264 ampliamente compatible con dispositivos modernos.-pix_fmt yuv420pgenera vídeo de 8 bits con submuestreo 4:2:0.-map 0:v:0selecciona la primera pista de vídeo.-map '0:a:0?'selecciona opcionalmente la primera pista de audio.-c:a aac -b:a 128kcodifica audio AAC convencional cuando existe audio.-movflags +faststartsitúa los metadatos de inicialización MP4 cerca del inicio del archivo.
Este es un ejemplo, no un comando universal para cualquier archivo de entrada. Las características de tu vídeo de origen pueden exigir un tratamiento adicional.
En particular, no debe convertirse a ciegas material HDR o de 10 bits a SDR de 8 bits sin una gestión de color apropiada: pueden aparecer colores incorrectos, pérdida de detalles en las zonas iluminadas o bandas visibles en los degradados. También requieren atención los metadatos de rotación, las frecuencias de fotogramas variables, las relaciones de aspecto de píxel, las fuentes entrelazadas, las disposiciones de audio inusuales y los límites de resolución incompatibles.
Cuando la frecuencia de fotogramas y las dimensiones del original ya son adecuadas, conservarlas suele facilitar las comparaciones y evitar cambios innecesarios de escala o movimiento. Evita imponer una frecuencia de fotogramas constante a fuentes con frecuencia variable, salvo que sea necesario: la conversión puede duplicar o descartar fotogramas. Si cambias el tamaño, conserva la relación de aspecto de presentación y asegúrate de que las dimensiones sean compatibles con el formato de píxel 4:2:0 elegido. Las resoluciones, frecuencias de fotogramas o niveles H.264 muy altos pueden superar los límites de decodificación de dispositivos antiguos, por lo que, en ocasiones, garantizar la compatibilidad exige reducir deliberadamente la resolución o la frecuencia de fotogramas.
14. Un punto de partida más conservador en FFmpeg para vídeo de alta calidad
Si la fidelidad del vídeo importa considerablemente más que el tamaño del archivo, comienza con un CRF menor y evalúa el resultado.
Por ejemplo, la siguiente configuración es un punto de partida experimental razonable para vídeo SDR convencional de acción real:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4En este ejemplo, el ajuste slow es un punto de partida práctico y general, no una afirmación de que supere a veryslow. Utilizar veryslow también sería razonable cuando se dispone de más tiempo para codificar.
Este perfil de alta calidad es una recomendación para realizar pruebas, no una configuración demostrada por mi experimento con vídeos cortos.
Para vídeos de calidad superior, prueba valores de CRF cercanos a 18, 20 y 22, y después elige según los resultados visibles. El grano o los movimientos difíciles de comprimir pueden requerir otros ajustes, y los archivos maestros de archivo pueden necesitar una compresión mucho menos agresiva.
15. No vuelvas a codificar un vídeo sin motivo
La compresión de vídeo con pérdida tiene un coste en calidad. Volver a codificar un archivo que ya ha sido comprimido puede introducir defectos adicionales, aunque el resultado nuevo parezca similar al original.
Antes de transcodificar, pregúntate si el archivo original ya cumple tus requisitos de compatibilidad, tamaño y calidad.
Si el archivo ya contiene vídeo H.264 y audio AAC compatibles, y no hace falta ninguna transformación visual, copiar los flujos puede ser mejor que realizar otra codificación con pérdida.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Esta operación copia los flujos comprimidos sin volver a codificarlos. Puede cambiar la organización del contenedor y evitar una nueva generación de pérdidas por compresión de vídeo.
Normalmente no conseguirá las mismas reducciones de tamaño que una nueva codificación con un nivel de calidad inferior.
Si el vídeo existente ya es compacto, compatible y visualmente aceptable, conservarlo puede ser la mejor optimización de todas.
16. Valida los vídeos codificados en lugar de fiarte solo del tamaño del archivo
Que FFmpeg termine correctamente no demuestra automáticamente que el vídeo cumpla todos los requisitos.
Empieza examinando los flujos de salida con FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Comprueba el códec, el formato de píxel, las dimensiones, la frecuencia de fotogramas, la duración y los flujos de audio.
A continuación, decodifica todo el archivo de salida para detectar determinados daños o errores de decodificación:
ffmpeg -v error -xerror -i output.mp4 -f null -En los experimentos de compresión, compara archivos generados a partir de la misma fuente. Mantén constantes las variables importantes y cambia un solo ajuste principal cada vez.
Observa el vídeo en movimiento, examina los detalles finos y presta atención a los degradados, las zonas oscuras, los objetos en movimiento y el texto.
Si es posible, utiliza métricas objetivas como SSIM, PSNR o VMAF para complementar las comparaciones visuales. No interpretes una sola puntuación elevada como prueba de que todos los defectos resultan invisibles.
Por último, prueba el vídeo en dispositivos representativos y en los procesos habituales de descarga y reproducción de archivos. La información sobre compatibilidad de navegadores es útil, pero las pruebas reales de reproducción son especialmente importantes cuando la compatibilidad es un objetivo prioritario.
17. Asegúrate de distribuir correctamente los archivos MP4
Una buena configuración de codificación no puede compensar una distribución web deficiente.
Para la reproducción progresiva habitual de MP4, configura correctamente la cabecera Content-Type: video/mp4 y admite solicitudes HTTP por intervalos de bytes cuando sea necesario recuperar partes del archivo o desplazarse por el vídeo.
La opción +faststart de FFmpeg mueve la información de inicialización MP4 hacia el comienzo de un archivo convencional. Esto facilita la carga progresiva, pero no mejora la calidad visual ni reduce la tasa de bits.
Un elemento HTML de vídeo básico puede reproducir un MP4 con H.264:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>El atributo preload es una indicación para el navegador, no un límite estricto de descarga. Las políticas de reproducción automática también pueden exigir que el vídeo esté silenciado o no tenga sonido.
Si una página contiene varios vídeos, evita descargarlos todos inmediatamente. Cargar los vídeos solo cuando hacen falta puede reducir el consumo de datos móviles y mejorar la velocidad percibida de respuesta.
Para vídeos cortos en móviles, optimizar el momento en que se inician las descargas puede ser tan importante como reducir el tamaño de los archivos codificados.
18. ¿Qué formato y calidad de vídeo debes elegir?
La respuesta correcta depende de lo que quieras optimizar.
| Tu objetivo | Punto de partida recomendado |
|---|---|
| Un solo vídeo para web y descarga con amplia compatibilidad | MP4 + H.264 + AAC cuando haya audio |
| Distribución en navegadores modernos con varias opciones de formato | AV1 o VP9, con H.264 como alternativa |
| Máxima compresión en dispositivos compatibles | Evaluar AV1 |
| Entorno de reproducción controlado y compatible con HEVC | Considerar MP4 + HEVC |
| Vídeos cortos para móviles donde prima reducir el tamaño | Considerar x264 CRF 30 después de pruebas representativas |
| Anime o vídeo de animación dibujada | Evaluar x264 con -tune animation |
| Películas de alta calidad o vídeos de calidad superior | Empezar con un CRF más conservador, cercano a 20, y hacer pruebas |
| Codificación sin conexión en la que el tiempo de CPU importa menos | Considerar x264 slow o veryslow |
| Procesamiento rápido y recursos de CPU limitados | Considerar x264 medium o slow |
| El vídeo existente ya cumple los requisitos | Conservarlo o cambiar el contenedor sin volver a codificar |
| Archivo o edición futura | Conservar un archivo maestro de alta calidad separado de las versiones de distribución |
19. Mi decisión final y lo que realmente demostró el experimento
Después de estudiar los formatos de vídeo, la compatibilidad, la eficiencia de codificación y los resultados reales de compresión, elegí un perfil práctico de distribución para vídeos cortos destinados a móviles.
El formato elegido fue MP4 con H.264, porque la compatibilidad predecible con navegadores, teléfonos, descargas y aplicaciones externas importaba más que obtener el archivo más pequeño posible mediante un códec más reciente.
El codificador elegido fue libx264 con el ajuste veryslow, porque podía codificar el vídeo sin necesidad de hacerlo en tiempo real y el tiempo adicional de procesamiento era aceptable.
Para vídeos de anime, utilizo el ajuste de animación, sabiendo que modifica el comportamiento del codificador y no garantiza archivos más pequeños ni mejores resultados visuales en todos los casos.
Para vídeos cortos destinados a móviles, elegí CRF 30, porque mi comparación mostró una reducción considerable del tamaño sin diferencias visuales significativas durante la reproducción normal, incluso al compararlos en un monitor de escritorio grande.
Esto no significa que CRF 30 sea el ajuste ideal para películas o material de alta calidad. Cuando los detalles finos, los degradados, el grano y la fidelidad general importan más, empezaría las pruebas alrededor de CRF 20 o con otro valor suficientemente conservador. No realicé un estudio controlado equivalente con material cinematográfico, así que no presento ese número como un valor óptimo demostrado experimentalmente.
La conclusión más importante es que no existe un único códec, formato o valor de CRF que sea el mejor para todos los vídeos.
Si priorizas la máxima compatibilidad y solo quieres un archivo, MP4/H.264 es una opción predeterminada sólida. Si puedes ofrecer formatos alternativos y buscas una mejor compresión, investiga VP9 y AV1. Si codificas vídeos cortos destinados principalmente a teléfonos, comprueba si un CRF mayor produce archivos suficientemente pequeños sin perjudicar la experiencia prevista. Si codificas películas o material de calidad superior, utiliza ajustes de calidad más conservadores y compruébalos cuidadosamente.
Elige primero los requisitos de reproducción, después el códec y, por último, la calidad de compresión. Luego prueba el resultado en los dispositivos y las condiciones que realmente importan. Este método es más fiable que adoptar un códec o un valor de CRF a ciegas por el simple hecho de que sea más reciente, eficiente o recomendado habitualmente.