Formatos de video en WordPress: MOV, MP4 o WebM (Adobe Effects y web)

Problema común para diseñadores de motion graphics y editores de video que empiezan con sitios web: “Hice una animación preciosa en Adobe After Effects, la renderice a .mov (en la mejor calidad), la subí a WordPress… y nada. Pantalla negra, error, o el archivo pesa 500 MB y tarda una hora en cargar.”

El archivo no está roto. Está hecho para una sala de montaje, y un navegador no es una sala de montaje.

#Por qué WordPress no reproduce archivos MOV

El formato .mov (contenedor QuickTime) es estándar en el trabajo creativo, sobre todo en Mac. .mov es un contenedor, no un codec: lo que lo vuelve inservible en la web es casi siempre lo que lleva dentro, ProRes o fotogramas sin comprimir.

Los tamaños no son cuestión de opinión, los publica Apple. A 1920x1080 y 29,97 fps, el documento técnico de ProRes da tasas objetivo de 45 Mbps para 422 Proxy, 102 Mbps para 422 LT, 147 Mbps para 422, 220 Mbps para 422 HQ, 330 Mbps para 4444 y 495 Mbps para 4444 XQ. El apéndice del mismo documento las repite en gigabytes por hora: 422 HQ son 99 GB por hora, alrededor de 1,65 GB por un solo minuto de metraje. Un bucle de veinte segundos para una sección hero, recién salido de After Effects, puede pesar más que todo el resto del sitio.

A partir de ahí fallan dos cosas dentro de WordPress, en este orden.

La subida puede no terminar siquiera. wp_max_upload_size() lee upload_max_filesize y post_max_size de PHP y devuelve el menor de los dos. En alojamiento compartido esos valores suelen quedarse en un valor por defecto modesto, y un POST de varios cientos de megabytes muere antes de que la biblioteca de medios lo vea.

Si termina, aun así no se reproduce. WordPress acepta el archivo porque wp_get_mime_types() contiene 'mov|qt' => 'video/quicktime'. Pero wp_get_video_extensions(), la función que decide qué considera el núcleo una fuente de video reproducible, devuelve solo mp4, m4v, webm, ogv y flv. MOV no está en esa lista. El adjunto se queda en la biblioteca con aspecto de video y comportamiento de descarga.

Escribir la etiqueta a mano tampoco salva la situación. La guía de contenedores de MDN limita el soporte de QuickTime a versiones antiguas de Safari y a navegadores que usaban el plugin QuickTime de Apple, marca como no soportados en Firefox todos los codecs de su tabla de QuickTime y recuerda que el framework QuickTime ya no existe en macOS desde 10.15 Catalina. ProRes no figura entre los codecs que la guía de codecs de video de MDN documenta para navegadores.

#Por qué ProRes no es para la web

ProRes se diseñó para la edición profesional, donde la prioridad es conservar la máxima calidad entre rondas de etalonaje y composición. Cada fotograma se guarda con compresión ligera e intrafotograma, lo que produce archivos enormes pero cómodos de recorrer y cortar en postproducción.

La web tiene otras prioridades. Los visitantes esperan que el video arranque en segundos. Las conexiones móviles tienen ancho de banda limitado. Los navegadores necesitan codecs pensados para decodificar con eficiencia, y MDN lo dice en su guía de codecs: en los navegadores no hay ningún codec sin pérdida, ni casi sin pérdida, disponible de forma general, porque un 1080p sin comprimir con submuestreo 4:2:0 ya necesita al menos 1,5 Gbps.

#Exportar en máxima calidad mejora el video web

Muchos diseñadores dan por hecho que más calidad significa mejor experiencia. Un archivo máster que tarda minutos en llegar ofrece una experiencia peor que una copia comprimida que empieza a reproducirse al instante y que el espectador casual no distingue del máster en la pantalla de un portátil.

#Qué formato de video admite WordPress

Dos formatos cubren toda la web, y la elección entre ellos es hoy menos dramática que cuando se escribió este artículo por primera vez.

#1. MP4 con H.264 (AVC)

La opción segura por defecto. caniuse da a H.264 en MP4 un 97,26 por ciento de soporte global (datos consultados el 12 de octubre de 2026), desde Chrome 4 y Safari 3.2. Si solo va a publicar un archivo, publique este.

Dos ajustes deciden si su exportación funciona de verdad, y ninguno de los dos se ve en un reproductor de previsualización.

Submuestreo de croma. ProRes 422 es, como dice su nombre, 4:2:2, y la familia 422 es de 10 bits. Si entrega eso a libx264 sin instrucciones, codificará un flujo con perfil High 4:2:2 que los navegadores no decodifican. Lo comprobamos con un archivo de prueba ProRes 422 HQ: sin indicar formato de pixel, ffprobe informó la salida como High 4:2:2 con yuv422p10le. Fuerce 8 bits y 4:2:0 con -pix_fmt yuv420p.

Dónde vive el índice. La documentación de muxers de FFmpeg describe -movflags +faststart como una segunda pasada que mueve el índice (el átomo moov) al principio del archivo, y advierte que no está activado por defecto. Sin él, el navegador no puede empezar a reproducir hasta que ha llegado el archivo entero, que es exactamente el síntoma de “tarda una hora en cargar”.

Si exporta desde Adobe Media Encoder en lugar de la línea de comandos, elija H.264 como formato, no QuickTime, y después compruebe esos dos ajustes sobre el resultado. La lista de formatos es lo único que importa; los nombres de los ajustes preestablecidos cambian entre versiones.

#Configuración recomendada de exportación H.264

Para obtener resultados predecibles al exportar para WordPress:

• Resolución: 1920x1080 para videos de contenido, 1280x720 para clips secundarios.
• Calidad: CRF entre 23 y 28 en libx264, en lugar de perseguir una tasa de bits fija.
• Fotogramas por segundo: mantenga los de la fuente (normalmente 24, 25 o 30 fps).
• Audio: AAC a 128-192 kbps estéreo, o sin pista de audio si el clip es decorativo.
• Formato de pixel: yuv420p, verificado con ffprobe sobre el archivo exportado.
• Perfil y nivel: fíjelos con -profile:v high -level:v 4.0 para 1080p, de modo que el archivo coincida con la cadena codecs que declara en el marcado (más detalles abajo).

#2. WebM con VP9

Formato abierto desarrollado por Google. La página de VP9 de Google afirma que el codec puede reducir la tasa de bits hasta un 50 por ciento frente a otros codecs conocidos. Tómelo como un techo que se alcanza con material difícil, no como una cifra que vaya a repetirse en cada clip, aunque el ahorro en un motion graphic plano es real.

El consejo obsoleto sobre este tema es que WebM es un formato de Chrome y Firefox. Hace años que dejó de serlo. caniuse registra soporte completo de WebM en Safari de macOS desde la versión 16 y en Safari de iOS desde 17.4, y Safari 14.1 a 15.6 ya lo reproducía en macOS 11.3 Big Sur o posterior. Eso deja el soporte completo en un 96,05 por ciento global, algo más de un punto por detrás de H.264 en MP4.

#Soporte del codec AV1 en navegadores

AV1 es la generación siguiente y comprime mejor que VP9, pero su despliegue va por detrás. caniuse le da un 80,39 por ciento de soporte completo, que sube al 95,02 por ciento solo si se cuenta el soporte parcial. Safari es precisamente el caso parcial: en macOS e iOS decodifica AV1 solo en dispositivos con decodificador por hardware, como el iPhone 15 Pro o un MacBook Pro con M3.

La guía de codecs de video de MDN recomienda hoy WebM con AV1 y Opus como primera opción para un sitio web típico, y MP4 con AVC y AAC como segunda opción de máxima compatibilidad. Eso convierte a AV1 en una primera <source>, nunca en la única. Además, codificar AV1 es mucho más lento que H.264 o VP9, así que compensa en contenido que se codifica una vez y se reproduce muchas.

#Etiqueta video HTML5 con fuentes WebM y MP4

Si tienes que alojar el video tú mismo, por ejemplo como fondo de una sección hero, liste las fuentes de mejor a peor. El navegador toma la primera que puede decodificar y no vuelve a mirar el resto.

<video autoplay loop muted playsinline preload="none"
       poster="/media/hero-poster.avif"
       width="1920" height="1080">
  <source src="/media/hero.webm" type='video/webm; codecs="vp9, opus"'>
  <source src="/media/hero.mp4" type='video/mp4; codecs="avc1.640028, mp4a.40.2"'>
  Su navegador no soporta video.
</video>

Cada atributo hace un trabajo concreto:

• muted junto con playsinline: los navegadores móviles rechazan la reproducción automática sin ambos. Sin playsinline, iOS abre el video a pantalla completa en cuanto empieza, lo que arruina un bucle de fondo.
• preload="none": no se descarga nada hasta que se pide la reproducción, así que el poster carga el primer pintado. Use metadata si necesita la duración por adelantado, y auto casi nunca.
• poster: una imagen fija en AVIF o WebP pesa una fracción del video y es lo que el visitante ve de verdad en los primeros segundos.
• la parte codecs= de la cadena type: permite al navegador descartar una fuente sin descargar un solo byte.
• width y height: defínalos siempre para reservar el espacio antes de que cargue el video, lo que evita el Cumulative Layout Shift, una de las Core Web Vitals.

#Cómo escribir la cadena codecs para MP4 y WebM

Versiones anteriores de este artículo declaraban avc1.42E01E para la fuente MP4. Esa cadena declara perfil Baseline (42) en nivel 3.0, mientras que el comando de FFmpeg que aparece más abajo produce un archivo de perfil High. Una cadena codecs que describe un flujo distinto del que se publica es una afirmación falsa ante el navegador.

La guía de MDN sobre el parámetro codecs define la forma AVC como avc1.PPCCLL: dos dígitos hexadecimales para el perfil, dos para los indicadores de restricción y dos para el nivel. El perfil High es 64 con restricciones 00, y el nivel 4.0 es 40 en decimal, 28 en hexadecimal. Así, High en nivel 4.0 es avc1.640028. El audio AAC-LC en MP4 es mp4a.40.2. Para WebM, MDN recoge las formas cortas vp9, vp8, opus y vorbis.

Lea los valores reales del archivo exportado en lugar de suponerlos:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,level,pix_fmt -of csv=p=0 web.mp4

En nuestra prueba, una codificación 1080p con -preset slow y sin indicar nivel devolvió High,50, nivel 5.0, porque el preset lento usa más fotogramas de referencia de los que permite el nivel 4.0 a esa resolución. Con -profile:v high -level:v 4.0 devolvió High,40, que es exactamente lo que declara avc1.640028.

#Atributos del bloque Video en el editor de bloques

En el editor de bloques no hace falta escribir la etiqueta a mano. El block.json del bloque Video del núcleo declara como atributos autoplay, controls, loop, muted, playsInline, poster, preload, src y tracks, con preload en metadata por defecto, y playsInline tiene su propio interruptor en la barra lateral. El bloque Cover no tiene ese atributo: su block.json no declara ninguna clave playsInline y su salida fija autoPlay, muted, loop y playsInline en el video de fondo, de modo que un fondo de video en Cover siempre es inline y no hay interruptor que revisar. Ninguno de los dos bloques escribe un parámetro codecs en el marcado.

#Cómo elige las fuentes el shortcode de video

El contenido clásico y muchos maquetadores siguen pasando por el shortcode [video], que el núcleo genera con wp_video_shortcode(). Su código, en wp-includes/media.php, explica varias cosas que la gente reporta como errores.

• Un MOV se convierte en enlace. Cuando src apunta a un archivo cuya extensión no está en wp_get_video_extensions(), la función devuelve un simple enlace <a class="wp-embedded-video"> al archivo en lugar de un reproductor.
• El orden de las fuentes es fijo. Se puede pasar un atributo por extensión (mp4, m4v, webm, ogv, flv), y la función emite los elementos <source> en el orden de esa lista. Por eso [video webm="a.webm" mp4="a.mp4"] coloca primero el MP4, y cualquier navegador que decodifique H.264 lo elige.
• El tipo no lleva codecs. Cada <source> recibe un tipo MIME sin más de wp_check_filetype(), por ejemplo video/mp4.
• Valores por defecto. preload es metadata, muted es falso y el reproductor mide 640x360 si no se pasan width y height; un ancho mayor se reduce al $content_width del tema.
• Biblioteca del reproductor. La salida se prepara para MediaElement.js por defecto; el filtro wp_video_shortcode_library lo cambia.

Añadir mov mediante el filtro wp_video_extensions hace que el shortcode muestre un reproductor para ese archivo, pero no le da a Chrome ni a Firefox un decodificador, así que la solución sigue siendo recodificar.

#Tipos MIME del servidor para MP4 y WebM

Un archivo puede estar perfectamente codificado y aun así servirse con un Content-Type incorrecto. Compruebe la cabecera de respuesta en la pestaña Red del navegador. El archivo mime.types por defecto de nginx ya asocia mp4 con video/mp4, webm con video/webm y mov con video/quicktime. En Apache, si la cabecera llega como text/plain o application/octet-stream, añada la asociación en .htaccess:

AddType video/mp4 .mp4
AddType video/webm .webm

#Optimización del tamaño del archivo de video

El tamaño del archivo importa para la experiencia del usuario y para el SEO. Un video que tarda demasiado en cargar aumenta la tasa de rebote y empeora las Core Web Vitals.

No hay una tabla universal de pesos objetivo: el mismo segundo de imagen pesa muy distinto en un plano estático y en una panorámica con grano. Fije la calidad con CRF, mida el archivo resultante y decida sobre ese número.

#Herramientas de compresión gratuitas

1. HandBrake: aplicación gratuita y de código abierto. Su lista de características nombra AV1, H.265, H.264, MPEG-4, MPEG-2, VP8 y VP9 como codificadores de video, con MP4, MKV y WebM como contenedores.
2. FFmpeg: la herramienta de línea de comandos que hay detrás de casi todas las demás, y la que usan todos los ejemplos de este artículo.
3. Shutter Encoder: interfaz gráfica para FFmpeg, más sencilla para empezar.

#Cómo comprimir video con FFmpeg

# MOV a MP4 para web (H.264, perfil High, nivel 4.0)
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 23 \
  -profile:v high -level:v 4.0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

# MOV a WebM con VP9 y Opus
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 \
  -pix_fmt yuv420p -c:a libopus -b:a 96k output.webm

# Versión 720p para móvil
ffmpeg -i input.mov -vf scale=1280:720 -c:v libx264 -preset slow -crf 23 \
  -pix_fmt yuv420p -movflags +faststart output-mobile.mp4

El valor -crf controla la calidad: valores más bajos significan más calidad y un archivo mayor. Para la web, un CRF de 23 a 28 en H.264 o de 30 a 35 en VP9 es un rango sensato desde el que empezar a medir.

Verifique la exportación en lugar de darla por buena, porque la ausencia de +faststart es silenciosa:

grep -abo -m2 -e moov -e mdat output.mp4

Eso imprime el desplazamiento en bytes del primer moov y del primer mdat. El de moov tiene que ser el menor. En nuestro archivo de prueba sin el flag, mdat aparecía primero en el byte 44 y moov estaba al final del archivo; con el flag, moov estaba en el byte 36.

#Cómo publicar video con transparencia (canal alfa)

VP9 en WebM transporta canal alfa si se codifica a yuva420p. La guía de codecs de MDN recoge VP9 en todas las versiones de Chrome, Edge, Firefox, Opera y Safari, con la salvedad de que Safari no admite la transparencia alfa en este formato; caniuse incluye la misma nota para WebM en Safari. La vía de Apple es HEVC con alfa, documentada en su HEVC Video with Alpha Interoperability Profile. Si una composición de After Effects necesita alfa real en la web, va a publicar dos archivos y un color de fondo como reserva.

#Subir video a WordPress o usar YouTube y Vimeo

Alojar el video tú mismo significa un único archivo con una única tasa de bits, entregado por descarga HTTP progresiva. No hay escalera de calidades. WordPress genera versiones redimensionadas de las imágenes al subirlas y nada equivalente para el video, porque el núcleo no incluye transcodificador. Un visitante con una conexión móvil débil recibe su archivo 1080p o nada, y se queda esperando a que cargue el búfer.

Así que la regla depende de qué es el video, no de cuánto pesa.

#Cuándo alojar video en su propio servidor

• Videos de fondo: animaciones cortas y sin sonido detrás del titular de una sección hero.
• Videos privados: contenido que no debe estar en una plataforma pública.
• Requisitos de marca: cuando el reproductor tiene que ser completamente suyo, sin logotipos de terceros.
• Peso de carga: para clips muy cortos, una incrustación de YouTube arrastra un reproductor de terceros y sus cookies para algo que se parece más a una imagen de fondo en movimiento.

#Cuándo usar YouTube o Vimeo

• Cualquier video con sonido de más de unos 30 segundos que el visitante viene a ver: una entrevista, un tutorial, el recorrido por un caso práctico.
• Contenido educativo o de marketing que se beneficia de la búsqueda de YouTube.
• Videos que desea que se compartan en redes sociales.
• Sitios con ancho de banda limitado, donde el streaming adaptativo importa.

El ancho de banda es la otra mitad de esa decisión. Un bucle de 10 MB en una página con cincuenta mil visitas al mes son medio terabyte de tráfico de salida, y en alojamiento de entrada eso acaba en una conversación con su proveedor.

#Cómo indexa Google el video autoalojado

Las buenas prácticas de SEO para video de Google añaden un tercer ángulo a la cuestión del formato, y no coincide con el de los navegadores.

Google puede procesar MOV, los navegadores no pueden reproducirlo. La lista de tipos de archivo de video que Google admite incluye MOV, MP4, M4V, WebM, OGV y otros. Eso hace que un MOV sea indexable en teoría y siga siendo inútil para el visitante, así que no es un argumento para publicarlo.

Solo una página de visualización obtiene todas las funciones de video. Google define la página de visualización como aquella cuyo propósito principal es mostrar un único video. Una entrada de blog que comenta un video incrustado, o una página de producto con un video 360, no es una página de visualización según Google; esas páginas aún pueden aparecer como resultado de texto y en Google Imágenes con una insignia de video. Un bucle decorativo de una sección hero nunca será un resultado de video, ni lo necesita.

El poster hace de miniatura. Si usa el elemento <video>, Google lee el atributo poster como miniatura preferida. Los formatos de miniatura admitidos son BMP, GIF, JPEG, PNG, WebP, SVG y AVIF, con un mínimo de 60x30 píxeles, en una URL estable que Googlebot pueda descargar.

No esconda el video detrás de una interacción. Google pide que los videos no dependan de deslizar, hacer clic o escribir para cargarse, y que un video insertado por JavaScript aparezca en el HTML renderizado que muestra la herramienta de inspección de URLs. Eso afecta al patrón de carga diferida de más abajo: correcto para un bucle decorativo, arriesgado para un video que quiera indexar.

Datos estructurados. La documentación de VideoObject exige tres propiedades: name, thumbnailUrl y uploadDate (ISO 8601, con zona horaria). contentUrl debe apuntar al propio archivo de video y es la opción preferida; embedUrl apunta a un reproductor y es la alternativa cuando no hay URL del archivo. Para un MP4 autoalojado, contentUrl es simplemente la URL del archivo en wp-content/uploads.

#Cómo hacer un video responsive en WordPress

WordPress no adapta por sí solo el video autoalojado a los tamaños de pantalla, así que esa parte la escribes tú.

#CSS para video responsive

/* Contenedor responsive para video */
.video-container {
    position: relative;
    width: 100%;
    padding-bottom: 56.25%; /* Ratio 16:9 */
    height: 0;
    overflow: hidden;
}

.video-container video,
.video-container iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

#Servir diferentes resoluciones según el dispositivo

<video autoplay loop muted playsinline>
  <!-- Móvil: 720p -->
  <source
    src="video-720p.webm"
    type="video/webm"
    media="(max-width: 768px)"
  >
  <!-- Escritorio: 1080p -->
  <source src="video-1080p.webm" type="video/webm">
  <source src="video-1080p.mp4" type="video/mp4">
</video>

El atributo media en un <source> de video es una función antigua con un hueco en medio: según los datos de compatibilidad de MDN, Firefox 53 a 119 solo lo respetaba dentro de <picture>, y el soporte para <audio> y <video> volvió en Firefox 120.

#Cómo hacer accesible un video en WordPress

El video accesible es obligatorio en el sector público europeo por la directiva de accesibilidad de sitios web y aplicaciones móviles, y fuera de él hace que el contenido se entienda para más personas. Los criterios de WCAG 2.2 que aplican son breves y concretos:

• 1.2.2 Subtítulos (grabados), nivel A: subtítulos para todo el audio grabado en medios sincronizados.
• 1.2.5 Audiodescripción (grabada), nivel AA: audiodescripción para el contenido de video grabado.
• 1.4.2 Control del audio, nivel A: cualquier audio que suene automáticamente más de 3 segundos necesita una forma de pausarlo o detenerlo, o un control de volumen independiente del volumen del sistema.
• 2.2.2 Pausar, detener, ocultar, nivel A: el contenido en movimiento que empieza solo, dura más de cinco segundos y se muestra junto a otro contenido necesita una forma de pausarlo, detenerlo u ocultarlo.

Este último es el que incumplen los bucles de las secciones hero. Un video de fondo silenciado con loop y sin controles se repite para siempre, así que necesita un botón de pausa visible o debe detenerse a los pocos segundos.

#Cómo añadir subtítulos con el elemento track

Los subtítulos de un video autoalojado son un archivo WebVTT referenciado por un elemento <track>. caniuse sitúa el soporte de WebVTT en un 97,26 por ciento, igual que el del propio elemento <video>.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="subtitulos.vtt" srclang="es" label="Español" default>
  <track kind="descriptions" src="descripciones.vtt" srclang="es" label="Audiodescripción">
</video>

Un archivo WebVTT mínimo tiene este aspecto:

WEBVTT

00:00:00.000 --> 00:00:04.000
Bienvenido a este video.

00:00:04.000 --> 00:00:08.000
[Música suave de fondo]

El bloque Video del núcleo guarda lo mismo en su atributo tracks, así que los subtítulos añadidos en el editor acaban como elementos <track> en el marcado guardado.

#Requisitos mínimos de accesibilidad para video

1. Subtítulos: para usuarios sordos o con dificultades auditivas, como archivo WebVTT en un elemento <track>.
2. Audiodescripción: para usuarios ciegos, describiendo lo que solo se ve.
3. Controles de teclado: el reproductor debe poder usarse sin ratón.
4. Alternativa textual: el poster o la miniatura necesitan una descripción útil cuando transmiten información.
5. Sin reproducción automática con sonido: un video con sonido nunca debe arrancar solo.

#Cómo diferir la carga de un video autoalojado

El tratamiento de loading="lazy" del núcleo de WordPress se aplica a imágenes e iframes, no al elemento <video>, que no admite ese atributo. Para un video autoalojado, lo que difiere la descarga es preload="none" junto con un poster. Si hace falta más, cargue la fuente por JavaScript con un IntersectionObserver cuando el elemento entre en el viewport, teniendo en cuenta la advertencia de Google de más arriba para cualquier video que quiera indexar.

#Cómo convertir MOV a MP4 para WordPress

1. Edite y masterice en After Effects o Premiere con .mov y ProRes. Esa parte nunca estuvo mal.
2. Exporte para web como H.264 en MP4, forzando -pix_fmt yuv420p, -movflags +faststart y un perfil y nivel que después declare en codecs.
3. Confirme la exportación: moov con un desplazamiento menor que mdat, y ffprobe informando yuv420p y High,40, no yuv422p10le.
4. Añada una copia WebM con VP9 y colóquela antes del MP4 en el elemento <video>. AV1 por encima de ambos solo si persigue los últimos cientos de kilobytes.
5. Dé al elemento una imagen poster y preload="none", mantenga muted y playsinline en cualquier bucle con reproducción automática y añada un control de pausa si dura más de cinco segundos.
6. Especifique siempre width y height para evitar desplazamientos del diseño.
7. Si el clip tiene sonido y alguien debe sentarse a verlo, súbalo a YouTube o Vimeo e incrústelo.

Si esto vive dentro de un proyecto que mantenemos, dejamos el paso de codificación configurado una sola vez en el pipeline de despliegue para que nadie tenga que recordar los flags. Forma parte de nuestros servicios de desarrollo WordPress.