¡Hola Negros! Programanon aquí.
Hace unos días, luego de más de un año con el mismo problema, por fin arreglamos los fallos con la reproducción de archivos webm. Al final solo bastó con cambiar una línea en la configuración del servidor, pero el problema fue difícil de identificar.
En el hilo donde hice el anuncio, hice un post explicando resumidamente la historia detrás del bug. Esta es una versión un poco más detallada de la historia, en caso de que se la hayan perdido. Lo dividiré en capítulos para hacerlo menos aburrido.
El problema de los webm y su relación con CloudFlare
Ya no recuerdo exactamente como empezó todo, pero el asunto se tocó por primera vez una noche de marzo de 2015, aproximadamente.
Para entonces se sabía que los navegadores simplemente no obedecían cuando se intentaba cambiar la posición de un video webm a menos que estuviesen cargados completamente.
Esto era un poco confuso, ya que en el chan de pruebas, los webm se reproducían con normalidad. Luego de investigar un poco notamos que al desactivar CloudFlare, los webm volvían a cargar con normalidad. Sin embargo, no podíamos simplemente dejar CF desactivado, ya que el servidor quedaría expuesto (además de que los tiempos de carga serían mucho mayores).
Los headers de los archivos webm dieron una pista de lo que podría estar sucediendo:
![r1]()
Normalmente, un archivo webm regresaría un código de respuesta 206 (Contenido Parcial), e incluiría metadatos adicionales, como la longitud del mismo. Estos metadatos eran requeridos por los navegadores para poder establecer la posición de reproducción. Sin saber la longitud de los videos, el navegador solo puede cargar el video ciegamente sin saber en que momento terminará, o siquiera si hay mas datos adelante, por eso era muy común ver la barra de reproducción siempre al final (hasta que los videos cargaban en su totalidad).
Debido a que el problema ocurría sólo con CloudFlare activado, Zeta envió un mensaje al soporte de CF, y en respuesta le enviaron este link, por lo que concluimos momentáneamente que sería imposible resolver el bug sin desactivar CloudFlare. Dejamos el asunto en paz por al menos 4 meses.
El misterio revive
Luego de un tiempo, intentamos nuevamente arreglar el asunto.
Esta vez, analizamos datos de 4chan y 8chan, ambos dependientes de CloudFlare al igual que nosotros. Al principio pensé que el dominio que 4chan usaba para los videos (i.4cdn.org) no tenía CloudFlare activado, pero al final resultó que también usaba CloudFlare.
Eso significaba que de alguna manera, era posible reproducir webms sin problemas a través de CloudFlare. Pero no sabíamos cómo. El misterio seguía sin resolver.
Probamos con distintas configuraciones, pero nuevamente no tuvimos éxito. El asunto volvió a descansar en paz por otros meses.
La solución temporal
Pasaron al menos 5 meses desde que se tocó el asunto por última vez. No quedaban tareas pendientes, así que, como de costumbre, volvimos a revivirlo.
Sin embargo, nuestros planes eran distintos esta vez. Pretendíamos crear un subdominio que no pasase por CloudFlare, y alojar en él todos los archivos webm.
Hicimos los cambios necesarios en el código y ya estábamos casi listos para la migración, pero aún había un bug con la versión Android del navegador Chrome, cuando se intentaban reproducir videos webm y estos alcanzaban el final, el reproductor empezaba a comportarse extraño y no dejaba hacer nada. Esto pasaba tanto con CloudFlare activo como desactivado, por lo que al principio no relacionamos un problema con el otro.
Al igual que el problema original, solo ocurría en Hispachan. Los webm seguían reproduciéndose con normalidad en otros sitios.
Fue entonces cuando ÉL entró en acción…
El archivo mp4 de la epifanía
Zeta había subido un mp4 de prueba al dominio sin CloudFlare, para demostrar que el bug en Android era específico a los archivos webm (y no de cualquier formato de video).
Por curiosidad cargué el mismo archivo mp4 desde el dominio principal, y mágicamente, no había problema alguno con CloudFlare, los archivos .mp4 cargaban tal y como deberían cargarse los archivos webm en condiciones normales.
Nuevamente hice la comparación que había hecho un año atrás, esta vez tomando en cuenta todos los detalles y considerando que ambos videos estaban siendo cargados desde el mismo servidor, con CF activo.
![r2]()
El verdadero culpable
Gzip. Gzip estuvo activado para los archivos en formato webm todo este tiempo. Por eso CloudFlare no podía obtener los metadatos y reenviarlos a los navegadores. No podía accesar correctamente a ellos porque estaban comprimidos.
Dando una explicación rápida, gzip sirve para comprimir los datos de la página antes de enviarlos, de manera que esta cargue un poco mas rápido. Esto funciona perfectamente en archivos de texto, como los HTMLs, JavaScripts y CSS, pero causa problemas en archivos que no lo son, como imágenes y videos.
Por defecto, gzip viene desactivado para formatos multimedia, pero por alguna razón webm no estaba en la lista. Sólo fue cuestión de añadirlo a la lista, reiniciar el servidor y boom, automáticamente todo empezó a andar de maravilla. Incluso el bug con android había dejado de ocurrir.
En resumen, casi 1 año de estrés intentando resolver un problema que al final resultó arreglarse con una sola línea adicional en el archivo de configuración del servidor. Adoro la programación.
En fin, ya cambiando de tema y antes de despedirme, hemos añadido una forma mas fácil de ver la hora local en la que fue hecho un post (en la versión de escritorio). Sólo ponen el cursor encima de la fecha y les indicará a qué hora fue hecho ese post en sus horarios locales.
![hora]()
>inb4 la hora no es correcta, arregla tu mierda
Funciona con la hora que tengas configurada en tu PC, incluso si es incorrecta. Arregla tu mierda.
Bueno, eso es todo de momento, me despido. Los quiero mucho negritos (no homo).
