Poner un vídeo por debajo del límite de subida sin adivinar

El tamaño es bitrate por duración, y casi nada más

Un archivo de vídeo es un flujo de bits reproducido a cierto ritmo. Multiplica ese ritmo por lo que dura la reproducción y tienes el archivo, salvo la contabilidad propia del contenedor, que en un MP4 normal es una fracción de por ciento. Por eso el tamaño no es realmente una propiedad que se fije. Es un resultado. Las dos cosas que de verdad controlas son cuántos bits pasan cada segundo y cuántos segundos hay, y todo lo que hace un compresor es una forma de empujar la primera.

Vale la pena memorizar la conversión, porque es todo el método. Un megabyte son ocho millones de bits, así que un megabyte son 8 000 kilobits. Multiplica el límite en megabytes por 8 000, divide entre el número de segundos, y el resultado es el bitrate total en kilobits por segundo que cabe. Un límite de 25 MB en un clip de 60 segundos permite 3 333 kbit/s. El mismo límite en un clip de 10 minutos permite 333 kbit/s. El mismo límite, veinte veces menos sitio, y toda la diferencia es la duración.

Una trampa de ese cálculo es el megabyte mismo. Unos sistemas entienden 1 000 000 de bytes y otros 1 048 576, una diferencia del 4,9 %, y un servicio rara vez dice cuál usa. Calcular con la cifra decimal —8 000 kilobits por megabyte— es el lado correcto por el que equivocarse: si el servicio se refería al megabyte grande, tu archivo simplemente entra bajo el límite con margen.

El CRF pide una calidad, no un tamaño

El deslizador de calidad de esta herramienta fija un factor de calidad constante. La escala va de 0 a 51 en el codificador; el deslizador expone de 18 a 34, que es la parte que usa cualquiera con sentido común, y arranca en 28. Un número más bajo significa mejor calidad y más bits. La guía de FFmpeg llama a 17 o 18 visualmente sin pérdida o casi, y describe de 17 a 28 como el rango subjetivamente razonable. La propiedad decisiva es lo que significa el número: es una instrucción sobre cuánta degradación tolerar en cada fotograma, no sobre cuántos bits producir.

Por eso el mismo CRF da tamaños muy distintos en clips distintos. Dos minutos de una entrevista estática con CRF 23 pueden acabar en unos pocos megabytes; dos minutos de lluvia sobre el agua, confeti o un paseo con cámara en mano por un mercado, con el mismo CRF, pueden pesar diez veces más, porque mantener la misma calidad visual a través de todo ese movimiento cuesta de verdad más bits. El codificador hace lo que le pediste. Pediste un aspecto, no un peso. La documentación de FFmpeg lo dice con todas las letras: en este modo no se le puede exigir un tamaño concreto ni un tope de bitrate.

Hay una regularidad en la que apoyarse, y es la razón de que un par de intentos converjan tan rápido. La escala CRF es exponencial: subirla seis puntos reduce el bitrate más o menos a la mitad, bajarla seis lo dobla más o menos. Esa sola regla convierte un deslizador ciego en un instrumento de puntería. En el rango que expone esta herramienta, de 18 a 34, eso supone un factor de unas 6,3 veces entre el archivo mayor y el menor que un mismo clip puede producir.

Ir hacia atrás desde el límite, con un ejemplo real

Toma un clip de tres minutos que quieras enviar por correo. Gmail declara un límite de adjunto de 25 MB en cuentas personales, así que: 25 × 8 000 = 200 000 kilobits, divididos entre 180 segundos, son 1 111 kbit/s en total. Resta los 128 kbit/s que esta herramienta dedica al audio y quedan 983 kbit/s para la imagen. La recomendación publicada por YouTube para 1080p a cadencia estándar es de 8 000 kbit/s. Te están pidiendo hacerlo con un octavo. El clip se codificará, y parecerá grabado a través de una ventana bajo la lluvia.

Cambia entonces la pregunta. En 720p la recomendación de YouTube es de 5 000 kbit/s y tú tienes 983: aún un quinto. En 480p es de 2 500 y tienes 983, un 39 %: agresivo, visiblemente más blando, pero mirable para un plano de habla o una grabación de pantalla. Esa comparación es la decisión de verdad, y se llegó a ella con una división. Si el clip tiene que quedarse en 1080p, la única palanca que queda es la duración: córtalo a 45 segundos y los mismos 25 MB te dan 4 444 kbit/s en total y 4 316 para la imagen: cerca de la recomendación de 720p y algo más de la mitad de la de 1080p, que es el punto en el que subir el CRF deja de ser una crueldad.

Cuando la aritmética dice que no

Haz la división en una grabación de treinta minutos contra un límite de 25 MB y obtienes 111 kbit/s en total: menos de lo que necesita el audio solo. El presupuesto de imagen es negativo. Ningún ajuste de compresión resuelve eso, y ninguna paciencia lo arreglará, porque la petición es aritméticamente imposible antes incluso de que intervenga el codificador. Es el resultado más útil que da el método, y conviene llegar a él antes de pasar veinte minutos codificando.

Las respuestas honestas a esas alturas tienen que ver con la duración o con el destino. Recorta la grabación a la parte que importa: la herramienta de recorte lo hará en segundos sin recodificar nada, a cambio de aterrizar en un fotograma clave y no exactamente donde pediste. Divídela en partes. O cambia de canal: las páginas de ayuda de WhatsApp declaran un límite de vídeo por defecto de 100 MB y 720p en conexión rápida, y de 64 MB y 480p en conexión lenta, mientras que los documentos enviados por la misma aplicación llegan a 2 GB, así que mandar un vídeo como documento rodea a la vez el límite de tamaño y la recompresión de la app.

La opción que mueve el índice al principio

Cada MP4 que produce esta herramienta se escribe con +faststart, y merece un párrafo, porque es la diferencia entre un archivo que se reproduce y uno que parece roto. Un MP4 guarda sus datos de medios en una caja y su índice —la tabla que dice dónde vive cada fotograma, llamada átomo moov— en otra. Por defecto el codificador escribe el índice al final, porque no puede conocer la disposición definitiva hasta el último fotograma. Un reproductor que lea ese archivo desde un servidor web tiene que llegar al final de la descarga antes de poder empezar.

La opción faststart hace que el codificador dé una segunda pasada sobre el archivo terminado y mueva ese índice al principio. La documentación de FFmpeg la describe exactamente así, y señala que no está activa por defecto porque esa pasada extra lleva tiempo. YouTube pide lo mismo en sus recomendaciones de subida: el átomo moov al principio del archivo, lo que llama Fast Start. El efecto práctico es que tu vídeo empieza a reproducirse mientras todavía está llegando, en vez de mostrar un rectángulo negro hasta el último byte, que es lo que harán una previsualización de subida, un cliente de mensajería o una página web con un archivo que no lo tenga.

Qué ejecuta realmente la herramienta, y dónde

No hay misterio en la cadena, así que aquí está entera. El compresor codifica la imagen con libx264 en el preajuste veryfast y el CRF que elegiste, codifica el sonido en AAC a 128 kbit/s, y escribe el resultado como MP4 con la opción faststart. Esa es toda la orden. El preajuste es un dial de velocidad frente a eficiencia, no de calidad: un preajuste más lento daría un archivo algo menor con el mismo CRF, y veryfast es el compromiso que evita que una codificación en el navegador se lleve la tarde.

Ese codificador es FFmpeg compilado a WebAssembly y se ejecuta dentro de la página, en tu máquina. El motor pesa unos 32 MB y se sirve desde la propia dirección de este sitio y no desde una red ajena, así que lo único que viaja es el motor viniendo hacia ti: el vídeo no va a ninguna parte. La compilación es de un solo hilo, y por eso es más lenta que un codificador de escritorio que reparte el trabajo entre todos tus núcleos, y por eso un clip largo es de verdad una espera larga. Mantén la pestaña en primer plano mientras trabaja: la tarea vive en la página y ningún servidor te guarda el sitio.

Preguntas frecuentes

¿Por qué no puedo escribir sin más el tamaño que quiero?

Porque acertar un tamaño exacto exige que el codificador vea el clip entero antes de decidir cómo gastar sus bits, es decir, codificarlo dos veces. Eso hace el modo de dos pasadas: la primera mide dónde están los momentos difíciles, la segunda reparte el presupuesto en consecuencia. Es la respuesta correcta cuando el tamaño es un requisito duro, y cuesta más o menos el doble de tiempo. Esta herramienta hace una sola pasada a calidad constante, que es el intercambio adecuado para un codificador en el navegador, donde la segunda pasada doblaría una espera ya larga. La aritmética de este artículo sirve para que el CRF de una pasada aterrice donde aterrizarían dos.

Mi archivo comprimido salió más grande que el original. ¿Cómo?

Porque el CRF que pediste era más generoso que la calidad que el archivo ya tenía. La compresión no es un trinquete: el codificador ni sabe ni le importa cuánto pesaba la entrada, simplemente produce lo que cuesta un nivel de calidad dado. Un clip ya muy exprimido, una descarga de una app de mensajería o una grabación de pantalla de contenido casi estático puede necesitar más bits con CRF 23 de los que ocupa ahora. Sube el CRF. La otra causa habitual es una pista de audio originalmente menor de 128 kbit/s, ya que esta herramienta siempre la recodifica a ese ritmo.

¿Bajar la resolución o subir el CRF?

Compara tu presupuesto con lo que pide la resolución y deja que decida la diferencia. Si el presupuesto está a un factor de dos de la recomendación, sube el CRF: la imagen se ablandará pero conservará bordes nítidos. Si es una quinta parte o menos, baja la resolución: un codificador tan hambriento produce bloques y arrastres mucho más feos que ese mismo material representado honestamente a menor tamaño. La regla es que una imagen con pocos píxeles parece pequeña, y una imagen con pocos bits parece rota, y el espectador perdona mucho antes la primera.

¿Importa algo el ajuste de audio?

Importa exactamente cuando el clip es largo y el límite pequeño. A 128 kbit/s el sonido cuesta unos 0,96 MB por minuto, así que un clip de dos minutos gasta menos de 2 MB en audio y a nadie le importa, mientras que una grabación de veinte minutos gasta más de 19 MB solo en audio, y por eso la fila de treinta minutos de la tabla es imposible con 25 MB. Esta herramienta no expone un control de audio, así que cuando el sonido es el problema la respuesta es acortar la grabación, o aceptar que una charla larga pide otro formato distinto y extraer la pista de audio por su cuenta.

La subida falló aunque mi archivo está bajo el límite indicado.

Tres cosas lo provocan a menudo. El límite indicado puede aplicarse al mensaje entero y no a cada adjunto, así que tus otros archivos también cuentan. El servicio puede medir la subida codificada en vez del archivo en disco, lo que añade alrededor de un tercio en un adjunto de correo. Y las cifras publicadas envejecen: la página de ayuda de Discord sobre adjuntos, consultada el 13 de agosto de 2026, dice que el límite gratuito es ahora de 20 MB, subido desde 10 MB en agosto de 2026, con 50 MB en Nitro Basic y hasta 500 MB en Nitro, mientras que un párrafo más antiguo de esa misma página sigue diciendo 10 MB. Cuando una página se contradice, apunta por debajo de la cifra menor.