Detección automática o rechazo de subidas de video VP9 incompatibles con iOS Safari

Contribuir Característica
1

Recientemente descubrí que varios videos en mi foro de Discourse autoalojado no se reproducían silenciosamente en iPhone y iPad. Tras investigar, la causa raíz fue que los videos habían sido codificados con el códec VP9 dentro de un contenedor MP4, una combinación que iOS Safari no puede reproducir.

Cómo ocurre

Facebook (y posiblemente otras plataformas) a veces entrega videos codificados en VP9 cuando los usuarios descargan su contenido. Cuando esos archivos se suben a Discourse, se aceptan sin problemas: la extensión .mp4 no indica el códec interno. En los navegadores de escritorio y en Android los videos se reproducen sin inconvenientes, por lo que el problema pasa desapercibido. En iOS Safari, el video muestra una miniatura y un botón de reproducción, pero al tocarlo solo aparece un indicador giratorio. Los usuarios suelen asumir que es un problema de red y continúan sin reportarlo.

Por qué es difícil de detectar

  • La extensión del archivo (.mp4) es idéntica a la de un archivo H.264 funcional.
  • Los navegadores de escritorio soportan VP9, por lo que los administradores que prueban en escritorio no ven ningún problema.
  • Los usuarios de iOS a menudo no reportan fallos individuales de medios, especialmente cuando otro contenido en la misma publicación es visible y reproducible.
  • No hay ninguna advertencia o error visible para el administrador.

Solución sugerida

Al subir un video, Discourse podría inspeccionar el códec del video (ffprobe ya está disponible en el contenedor Docker) y:

  1. Rechazar la subida con un mensaje claro que explique que VP9 no es compatible con iOS, pidiendo al usuario que vuelva a codificar el video a H.264, o
  2. Transcodificar automáticamente el video a H.264 durante la subida (de forma similar a como algunas plataformas normalizan las subidas).

La opción 1 es menos compleja y ya supondría una mejora significativa. La opción 2 sería ideal para una experiencia de usuario fluida.

Entorno

  • Discourse autoalojado en Docker, almacenamiento local (sin S3)
  • Versión de Discourse: 2026.4.0-latest
  • Proxy inverso Apache frente al nginx de Discourse

Solución alternativa

Para los administradores que se encuentren con esto, la corrección implica:

  1. Identificar archivos VP9 con ffprobe
  2. Volver a codificarlos a H.264 con ffmpeg -c:v libx264 -profile:v main -level 3.1 -r 30 -movflags +faststart
  3. Actualizar sha1, url y filesize en la tabla uploads
  4. Actualizar los tokens de URL corta upload:// en el markdown crudo de las publicaciones afectadas
  5. Rehornear las publicaciones afectadas

Este es un proceso manual no trivial del que la mayoría de los administradores de foros no estarían equipados para llevarlo a cabo.

1 me gusta
2

Para la transcodificación automática, puedes consultar Discourse Video Stream :movie_camera:.

La transcodificación local automática funciona, pero el principal problema es ofrecerla de una manera segura para la mayoría de las configuraciones.

2 Me gusta
3

Gracias por la referencia al plugin Video Stream, @Falco. Para un foro pequeño de entusiastas como el mío, añadir una dependencia de un servicio de terceros de pago parece excesivo para el problema que se plantea, aunque entiendo su atractivo para sitios con alto tráfico y un uso intensivo de video.

Tu comentario sobre la transcodificación local es interesante. Durante el proceso de solución, ejecuté manualmente ffmpeg en los 9 archivos afectados en mi VPS y el servidor lo procesó sin problemas. Entiendo la preocupación de hacerlo de forma síncrona durante la subida: los picos de CPU, los tiempos de espera y la presión en el disco son riesgos reales. ¿Pero no abordaría un enfoque de trabajo asíncrono en segundo plano la mayoría de esas preocupaciones? La subida se completaría con normalidad y la transcodificación se realizaría en un trabajo en cola después, de manera similar a como Discourse ya gestiona la creación de miniaturas de imágenes. El video simplemente no sería reproducible en iOS hasta que el trabajo se complete, lo que parece un compromiso aceptable.

Incluso sin llegar a una transcodificación completa, una opción más ligera —detectar VP9 durante la subida y rechazarlo con un mensaje de error claro o marcarlo en el panel de administración— sería de gran ayuda para los administradores de sitios autoalojados que quizás no tengan los conocimientos técnicos para diagnosticar fallos silenciosos en la reproducción en iOS.

1 me gusta
4

El video es un poco más complicado, ya que hay muchas formas en que un usuario podría subir algo maliciosamente para consumir la CPU, especialmente en las muchas instancias autoalojadas con 1 vCPU.

Puedo intentar explorar un plugin aquí, para que se convierta en una opción a la que el administrador pueda acceder solo si está satisfecho con las compensaciones.

3 Me gusta