Convertir MOV a WebM

El MOV que tienes delante casi nunca salió pensado para publicarse tal cual. Vino de Final Cut, de Premiere o directamente de la tarjeta de una cámara, pesa varios cientos de megas y en más de un caso está en ProRes. Es la copia de mayor calidad que existe de ese material, y por eso mismo es la peor candidata para colgarla directamente en una web.

El destino es justo lo contrario: un vídeo de fondo en la portada de un negocio, una demo de producto, un making of que se aloja en el propio dominio en vez de en YouTube. Ahí lo que importa es cuánto tarda en empezar a reproducirse, no cuántos fotogramas por segundo aguanta el archivo original.

Conviene decirlo antes que nada porque es el motivo más habitual para elegir WebM en concreto: un rótulo animado, una mascota que flota sobre el contenido, un logotipo que aparece con fondo transparente. Ese tipo de vídeo se entrega normalmente como ProRes 4444 dentro de un MOV, y el equivalente para navegador sería VP9 con canal alfa dentro de un WebM.

Ese salto no ocurre aquí. El canal alfa se descarta en la conversión, así que lo que sale es opaco — y en la práctica un ProRes 4444 ni siquiera llega a decodificarse en un navegador, con lo que el fallo suele darse antes de ese punto. Para conservar la transparencia hace falta software capaz de escribir alfa en VP9, como un exportador con complemento WebM en After Effects; el MOV se queda como máster y el WebM transparente sale de ahí.

VP9 para la imagen y Opus para el sonido, siempre, en tres bandas de calidad — baja, media y alta — que resuelve el propio códec según el contenido en vez de apuntar a una cifra fija de megabits por segundo escrita en este sitio. A resolución igual, VP9 suele necesitar menos bits que H.264 para un resultado comparable, que es la razón habitual para elegir WebM en primer lugar, pero la cifra exacta de cada archivo depende del contenido y de la banda elegida, no de una tabla publicada aquí.

Ese ahorro es real y no es el más grande de los que tienes disponibles. Bajar un máster en 4K a 1080p elimina tres cuartas partes de los píxeles antes de que el códec haga nada, y un vídeo de fondo que se muestra a 400 píxeles de alto no gana nada por venir a 2160. Ajusta primero la resolución al tamaño real en pantalla y después discute el códec.

Este es el obstáculo práctico de esta página y conviene preverlo en vez de descubrirlo a mitad de conversión. El plan gratuito acepta archivos de hasta 100 MB por archivo. Un máster en ProRes de una cabecera de treinta segundos puede pesar varios gigas, y hasta un original en H.264 a 4K ronda los 350 megas por minuto — un móvil solo baja a 170 cuando graba en HEVC.

La salida es exportar antes un archivo intermedio más pequeño desde el propio editor. Un H.264 a 1080p con una tasa de bits moderada pesa una fracción del máster, se decodifica sin problemas en el navegador y le da al codificador VP9 una imagen perfectamente válida de la que partir. Recortar el clip a los segundos que de verdad se van a usar suele ahorrar más que cualquier ajuste del codificador.

La forma correcta es un único elemento de vídeo con dos fuentes: el WebM primero y el MP4 después. El navegador toma la primera que sabe reproducir, así que uno moderno se queda con el WebM y el resto cae en el MP4 sin que nadie tenga que detectar nada. Es un cambio de dos líneas en el marcado y es la diferencia entre ahorrar peso y dejar la web rota para alguien.

Para un fondo en bucle, los demás atributos pesan tanto como el códec: silenciado, reproducción en línea, bucle, y precarga puesta en metadatos en vez de automática, para que el vídeo no compita con el texto por el primer segundo de conexión. Una imagen de póster tomada del mismo MOV es lo que ve el visitante mientras todo eso se resuelve.

Un vídeo grabado con el móvil en vertical se guarda como fotogramas en horizontal con una marca de rotación, y los contenedores basados en Matroska como WebM no tienen dónde guardar esa marca. Por eso la conversión gira de verdad la imagen y escribe un archivo ya en su orientación correcta, que es justo lo que conviene cuando el vídeo va a una página cuya reproducción no controlas.

La consecuencia a vigilar está en el CSS del contenedor. Un clip que se anunciaba como 1920 por 1080 con marca de rotación se convierte en un WebM realmente de 1080 por 1920, y una caja pensada para formato horizontal lo va a enmarcar mal. Comprueba las dimensiones del archivo de salida, no las que declaraba la cámara.

Escribir VP9 requiere un codificador VP9, y ese codificador lo pone el sistema operativo, no esta página. Chrome, Edge y Safari lo traen en prácticamente cualquier equipo actual; algunas instalaciones de Firefox, sobre todo en Linux, no, y la página lo dice antes de elegir el archivo en lugar de fallar a mitad de la codificación.

La otra mitad depende del origen. Un MOV en ProRes o en log de 10 bits necesita un decodificador que el navegador muy probablemente no tiene, y la conversión se detiene con un mensaje indicando que nada del archivo pudo procesarse. No hay alternativa por software para ninguna de las dos mitades: un códec compilado a WebAssembly pesa decenas de megas y es un orden de magnitud más lento que el hardware que ya está ahí.

Imagen y sonido, y nada más. Una exportación de QuickTime puede llevar pista de código de tiempo, marcadores de capítulo, pistas de subtítulos y metadatos de cámara o de montaje, y ninguno de esos datos se lee. Para un fondo en bucle da igual; para una charla autoalojada con capítulos significa reconstruirlos como datos en la propia página.

Los subtítulos merecen planificarse aparte. Un WebM servido desde tu propio dominio debería llevar un elemento track apuntando a un archivo VTT, que además es mejor práctica que una pista embebida: se puede indexar, traducir y editar sin volver a codificar el vídeo.

El sonido se convierte a Opus, que es el códec propio de WebM, en la misma banda de calidad —baja, media o alta— que elijas para el vídeo. Para un fondo en bucle la respuesta más útil suele ser que no hace falta ninguna pista: un vídeo con reproducción automática tiene que arrancar silenciado, así que ese sonido son bytes que nadie va a escuchar.

Cuando el vídeo sí lleva locución o música con derecho a sonar — una demo con voz en off, un making of — la banda equilibrada es suficiente para casi todo, y solo merece subir a la banda alta si el material de audio se va a escuchar con atención en vez de de fondo.

Una razón habitual para pasar por este proceso en vez de simplemente incrustar un vídeo de YouTube o Vimeo es evitar que la carga de la página dependa de un tercero que instala sus propias cookies y hace sus propias peticiones antes de que nadie haya dado su consentimiento — algo que cualquier web dirigida a usuarios en la Unión Europea tiene que gestionar de todas formas, y que un vídeo autoalojado sencillamente no plantea.

La otra razón, más práctica, es el control sobre la experiencia: un vídeo servido desde el propio dominio no lleva sugerencias de otros vídeos al terminar, ni la marca de una plataforma ajena superpuesta, ni un reproductor que cambia de aspecto cuando la plataforma actualiza su interfaz. A cambio, el peso del archivo y la compatibilidad del navegador pasan a ser responsabilidad de quien publica el vídeo, que es justo lo que esta conversión ayuda a resolver.

Esta página está pensada, muchas veces, para grabaciones que aún no son públicas: el lanzamiento de un producto, las instalaciones de un cliente, una cabecera bajo embargo, un fragmento de campaña que todavía no se ha emitido. La forma habitual de convertir un MOV es subirlo a un conversor cualquiera encontrado en un buscador, lo que pone ese material sin publicar en un servidor que nadie ha revisado.

Aquí tanto la decodificación como la codificación en VP9 ocurren en la pestaña del navegador, con los códecs que el equipo ya tiene instalados. No sale nada que lleve el vídeo, y la pestaña de red del propio navegador lo confirma. El efecto práctico llega a la vez: un archivo grande se convierte a la velocidad del procesador, no a la de la subida.