¿Por qué la conversión de MOV a WEBM exige siempre una recodificación?

La misma operación, duraciones muy distintas

Cuando conviertes un archivo MOV a MP4, el proceso suele terminar sorprendentemente rápido. Cuando conviertes ese mismo archivo MOV a WEBM, en cambio, esperas varios minutos. El archivo es el mismo, la duración es la misma, la resolución es la misma. ¿De dónde viene la diferencia?

La respuesta está guardada en la distinción más fundamental del vídeo digital: la diferencia entre contenedor y códec. Cuando comprendes esa distinción, puedes predecir qué conversión será rápida y cuál lenta sin siquiera mirar el archivo.

Contenedor y códec: dos capas distintas

Piensa en un archivo de vídeo como algo de dos capas.

El contenedor es la capa externa, la caja del archivo. Mantiene juntos la pista de vídeo, la pista de audio, los subtítulos si los hay, los metadatos y la información de sincronía. MOV, MP4, WEBM y MKV son contenedores. El contenedor no comprime la imagen ni determina la calidad.

El códec es la capa interna: determina con qué algoritmo se han comprimido la imagen y el sonido. H.264, H.265, ProRes, VP9 y AV1 son códecs de vídeo. AAC, MP3, Opus, Vorbis y PCM son códecs de audio. Lo que determina el tamaño y la calidad visual de tu archivo es precisamente esta capa.

El punto clave: no todo contenedor puede transportar todo códec. Cada contenedor tiene una lista de códecs que acepta, y lo que determina si una conversión será rápida o lenta es si esas listas se cruzan o no.

Si hay intersección: remux

Si el códec del archivo de origen figura también en la lista que acepta el contenedor de destino, ocurre algo estupendo. No hace falta descomprimir la imagen en absoluto. Los datos de vídeo y audio se toman de la caja antigua y se ponen tal cual en la nueva. A este proceso se le llama remux.

El remux tiene dos grandes beneficios. El primero: la pérdida de calidad es cero, los datos se mantienen bit a bit idénticos y no se descarta ningún detalle. El segundo: es rápido, el algoritmo de compresión no llega a ejecutarse, solo se copian datos, así que lo que determina la duración es sobre todo la velocidad del disco y de la conexión.

Cuando conviertes a MP4 un MOV que contiene H.264, ocurre exactamente esto. Como el contenedor MP4 ya acepta H.264, los datos se trasladan y el trabajo termina. Esa es la razón de que aquella conversión sea rápida.

Si no hay intersección: recodificación

La lista de códecs que acepta WEBM es bastante estrecha, y eso es una decisión de diseño. WEBM se concibió como un formato web abierto y sin carga de patentes; por eso solo transporta códecs abiertos:

• Vídeo: VP8, VP9, AV1
• Audio: Vorbis, Opus

Veamos ahora el contenido típico de los archivos MOV:

• Vídeo: H.264 (iPhone, grabaciones de pantalla, la mayoría de cámaras) o ProRes (montaje profesional)
• Audio: AAC o PCM sin comprimir

Entre ambas listas no hay ni un solo elemento en común. H.264 no puede meterse en WEBM. ProRes no puede meterse de ninguna manera. Y AAC tampoco figura en la lista de audio de WEBM.

En esa situación solo queda un camino: transcodificar, es decir, recodificar. El proceso funciona así. Cada fotograma del vídeo de origen se pasa por el decodificador de H.264 y se convierte en píxeles en bruto. Después esos fotogramas en bruto se entregan al codificador de VP9 o AV1 y se comprimen desde cero. En el lado del audio ocurre lo mismo: el AAC se descomprime y se recodifica como Opus o Vorbis.

Tus dos consecuencias honestas

La primera: el proceso es lento. Cada fotograma del vídeo tiene que pasar por dos algoritmos distintos. Los codificadores de VP9 y AV1 hacen cálculos especialmente intensivos: la compresión eficiente nace exactamente de esos cálculos. Que el proceso dure varios minutos en un archivo largo y de alta resolución no es un defecto, sino el comportamiento esperado. Cuando eliges AV1, ese tiempo se alarga notablemente respecto a VP9.

La segunda: pierdes algo de calidad. La compresión con pérdidas reduce el archivo descartando la información que menos aprecia el ojo humano. Si el MOV de origen ya estaba comprimido con H.264, parte del detalle ya se ha descartado. Cuando descomprimes esa imagen y la vuelves a comprimir con VP9 se aplica un segundo filtrado. Es una pérdida que se superpone y no se puede revertir.

Con un buen ajuste de calidad esa pérdida no se aprecia a simple vista en la mayoría de escenas. Pero en algunos sitios se hace visible: emborronamiento en escenas de movimiento rápido, escalones de color en áreas amplias de color uniforme (como el cielo) y defectos en bloques en las escenas oscuras. Si ves eso, es que tu ajuste de calidad es demasiado tacaño.

Consecuencias prácticas

Cuando entiendes este mecanismo, tres comportamientos se vuelven correctos de forma automática.

Mantén corta la cadena. Cada recodificación añade una pérdida nueva. En lugar de pasar el vídeo primero a MP4, luego a WEBM y luego otra vez a algo, ve directamente del origen al destino. Al hacer la conversión de MOV a WEBM, que tu fuente sea el archivo original.

Termina antes la edición. Operaciones como recortar, corregir el color o incrustar subtítulos suponen una recodificación más. Hazlas antes de la conversión, mientras sigues trabajando con el archivo de origen.

No borres nunca el original. La salida WEBM es una versión que ha perdido información respecto a la fuente. Si mañana necesitas un formato distinto, debes partir del MOV original y no del WEBM.

Qué conversión es rápida y cuál lenta: un método práctico de predicción

Cuando comprendes esta lógica, puedes estimar a grandes rasgos cuánto durará una conversión antes de lanzarte a ella. Lo único que tienes que hacer es plantearte dos preguntas.

Primera pregunta: ¿qué códec hay dentro del archivo de origen? Los archivos MOV suelen llevar H.264; en las salidas de cámaras y montajes profesionales, en cambio, hay ProRes. El tamaño del archivo te da una pista: si un vídeo de unos pocos minutos ocupa varios gigabytes, dentro hay un códec poco comprimido como ProRes.

Segunda pregunta: ¿el contenedor de destino acepta ese códec? MP4 acepta H.264, así que pasar de un MOV con H.264 a MP4 es un remux y termina rápido. WEBM, en cambio, no acepta ni H.264 ni ProRes, así que todo camino que lleve hasta ahí pasa por una recodificación.

Cuando te haces esas dos preguntas, el resultado sale solo. Si hay intersección, rápido y sin pérdidas; si no la hay, lento y con cierta pérdida. La regla es así de simple y funciona igual para otros contenedores como MKV o AVI.

Una advertencia: con un MOV que contiene ProRes está en realidad algo mejor situado en cuanto a pérdida, porque ProRes aplica muy poca compresión y la cantidad de detalle descartado en el origen es pequeña. Es decir, el único filtrado que se suma es el de la codificación WEBM. A cambio, el tiempo de proceso se alarga aún más, porque la cantidad de datos que hay que leer es enorme.

En resumen

Que la conversión de MOV a WEBM sea lenta y con pérdidas no es una carencia de la herramienta ni una cuestión de ajustes equivocados; es la consecuencia directa de que las listas de códecs que aceptan ambos contenedores no coincidan en absoluto. WEBM es un contenedor estrecho construido sobre códecs abiertos, mientras que MOV transporta códecs completamente distintos, como H.264 y ProRes. Sin denominador común, la imagen se descomprime y se vuelve a comprimir obligatoriamente, y eso significa tiempo y algo de calidad. La respuesta a si merece la pena pagar ese precio depende de tu objetivo: si vas a publicar el vídeo en tu sitio web, la compatibilidad con los navegadores y la compresión eficiente de WEBM cubren ese coste. Pero si solo vas a enviarle el archivo a alguien, MP4 —donde cambiar de contenedor no cuesta nada— es un destino mucho más inteligente.