Saltar al contenido principal
🇬🇧 English 🇧🇷 Português 🇩🇪 Deutsch
Convertidor de imágenes Convertidor de vídeo Convertidor de audio Convertidor de documentos
Herramientas Guías Formatos Precios API
Iniciar sesión
Guía

Formato WebM: Contenedor de Vídeo Web Abierto — VP8, VP9, AV1 y Opus

PC Por Pablo Cirre

Conversiones relacionadas

Pon en práctica lo que acabas de aprender — convierte tus archivos ahora en segundos, gratis y sin registro.

Preguntas frecuentes

Sí. Chrome, Firefox y Edge (todos disponibles en Windows) reproducen WebM de forma nativa. VLC también reproduce WebM. Windows Media Player y el reproductor de vídeo integrado de Windows no soportan WebM de forma nativa — instala VLC o abre archivos WebM en un navegador compatible.

AV1 es el más eficiente (libre de royalties, ~30% menor que H.265) pero la codificación es lenta. H.265 (HEVC) ahorra ~30–50% sobre H.264 y lo soportan todos los móviles y ordenadores modernos. H.264 sigue siendo el más compatible con dispositivos antiguos. Regla práctica: archivado → AV1, uso diario → H.265, máxima compatibilidad → H.264.

Para eficiencia de ancho de banda, sí: VP9 WebM es típicamente un 35% más pequeño que H.264 MP4 a calidad equivalente, y AV1 WebM es un 50% más pequeño. Sin embargo, MP4 tiene soporte casi universal en todos los dispositivos y apps. Mejor práctica para web: servir ambos formatos, dejando que el navegador seleccione VP9/AV1 WebM con H.264 MP4 como alternativa.

CRF (Constant Rate Factor) es el mejor por defecto para archivos offline: ffmpeg ajusta el bitrate frame a frame manteniendo la calidad percibida. Two-pass solo es mejor cuando debes acertar un tamaño final exacto (DVD). Bitrate constante es para streaming con canal fijo. Para "más pequeño a calidad X" usa siempre CRF.

Convertir MP4 (H.264) a WebM (VP9 o AV1) siempre implica recodificación, introduciendo alguna concesión de calidad. A ajustes de calidad y bitrate equivalentes (p. ej., modo CRF), la diferencia es típicamente imperceptible. El archivo WebM resultante será más pequeño que el MP4 a la misma calidad perceptual.

Causas comunes: (1) framerate variable renderizado como constante (usa <code>-vsync vfr</code> para preservar VFR); (2) sample rates de audio distintos sin resamplear (añade <code>-ar 48000</code>); (3) limitaciones del contenedor (MP4 con VFR da problemas — usa MKV durante edición, codifica a MP4 solo al final). Compara tiempos con <code>ffprobe</code> en origen y destino.

Apple históricamente prefirió H.264 y AAC (a los que contribuyeron) sobre los códecs VP8/VP9 de Google. Apple se unió a la Alliance for Open Media y añadió soporte AV1 en Safari 14. El soporte VP9 se añadió en Safari 12.1 en macOS pero sigue siendo limitado en iOS/iPadOS. El soporte completo de WebM en todas las plataformas Apple sigue siendo incompleto a partir de 2025.

Sí, si solo cambias el contenedor: <code>ffmpeg -i in.mkv -c copy out.mp4</code>. Esto remuxea el stream sin recodificar, tarda segundos incluso con horas de material. Limitación: el códec debe ser compatible con el contenedor destino (no puedes poner H.264 en WebM, solo VP8/VP9/AV1). Para reducir tamaño hay que re-codificar.

Usamos cookies y tecnologías similares para personalizar contenido y anuncios, y para analizar el tráfico. Más información sobre cookies.