Escribo esto porque, como diseñador web, veo el mismo problema en todas partes. La gente pone archivos de audio y video en servidores web, pero se confunden en la manera que deben presentárselo a los usuarios con la interfaz web.
Muchas veces, en un intento por hacer la visualizacióm más compatible se termina haciendo más incompatible, ya que, como se dice popularmente, desvisten a un santo para vestir a otro
. El problema es aún más grave: a veces para llegar a un pequeño porcentaje de público que es excluido con un método, se pierde mayor cantidad de público entre quienes antes podían acceder al contenido:
En el gráfico se muestra el problema: para llegar a una minoría que antes no podía acceder (en rojo) muchos más de los otros pierden acceso (que estaban en azul y ahora en rojo). Evitar esto es fácil, sólo hay que apegarse a ciertos estándares y probar el recurso en la mayor cantidad (y variedad) de sistemas posibles.
El escenario es éste: tenés un archivo de sonido MP3 de una canción tuya, y un videoclip de la misma canción en formato AVI (con compresión DivX). El archivo de audio pesa 4 Mb y el de video 20 Mb. Ambos estarán alojados en un servidor web, el mismo en el que tenés el sitio de tu banda.
Lo que vos querés lograr es que la mayor cantidad de gente posible acceda al contenido. Esto es, que puedan escuchar la canción y que puedan ver el video.
Acá van varias aclaraciones. La primera de ellas, es que no existe ningún método que funcione para el 100% de los usuarios ya que todos ellos, como la Internet misma, dependen de la configuración tanto de servidor como de cliente. Vos, al tener tu propio sitio, controlás la configuración del servidor; pero la configuración del cliente sólo la controla el usuario final. Si el usuario no tiene los conocimientos mínimos sobre cómo instalar un programa o cómo configurar su navegador, es su problema, no tuyo.
Otra aclaración es que como los archivos están en un servidor web, y no un servidor de streaming (RTSP) para poder reproducirlos se debe descargar completamente el archivo. Esto además genera una copia completa del archivo en la máquina del cliente, con lo cual ellos siempre van a poder guardar su copia (por suerte).
Por ello es que no es muy distinto la acción de "reproducir" que la de "guardar". Ambas tardarían lo mismo: lo que tarda en transferir el archivo completo. Hay ciertas excepciones, pero rara vez se aplican.
Este es el método más lógico, fácil y efectivo. En todos los casos que lo probé funcionó. OK, yo sí sé configurar un programa. Pero realmente funciona.
El método consiste en hacer un simple link al contenido. Luego lo "adornaremos" con más opciones. Básicamente es así:
<a href="cancion.mp3">Escuchá la canción</a><br> <a href="videoclip.avi">Mirá el videoclip</a>
Lo que pasará en este caso al hacer click con el botón principal del mouse, es lo que el usuario tenga configurado según su preferencia. Puede ser que le aparezca un cuadro de diálogo preguntando si quiere guardar el archivo a disco o abrirlo directamente con su reproductor multimedia favorito; o puede ser que directamente se le abra con el reproductor.
Si quiere guardar el archivo tiene dos formas: puede guardarlo con el menú "guardar" de su reproductor, o puede forzar un download con su navegador, esto se hace haciendo click sobre el link con el botón secundario del mouse y seleccionar la opción "guardar destino", "descarga rápida", etc.
Para que todo esto funcione el servidor web debe entregar el MIME type correcto. O sea, debe estar bien configurado. Para este caso, los MIME types del MP3 y el AVI son audio/mpeg y video/avi, respectivamente.
En el caso de que el servidor web sea Apache, el programa servidor web más popular, para agregar los MIME types simplemente se debe editar el archivo mime.types y agregar estas dos líneas (en realidad ya están puestas en la configuración por defecto):
audio/mpeg mp3 video/avi avi
En caso de que no se tenga acceso al archivo mime.types, como por ejemplo si el servidor no es nuestro, podemos subir un archivo .htaccess (sí, lleva un punto al principio del nombre) que contenga las líneas:
AddType audio/mpeg .mp3 AddType video/avi .avi
Ese archivo debe estar en la misma carpeta que los archivos multimedia. Puede ser necesario reiniciar el servidor luego de cambiar estos archivos.
Cuando el servidor envía los MIME types correctos para los distintos archivos, no debe de haber ningún problema. Es toda la configuración que debe tener el sitio web para que esto funcione. Los problemas que puedan aparecer son de los usuarios que tienen sus computadoras mal configuradas, por ejemplo tenían el Real Player y en lugar de desinstalarlo borraron la carpeta. No hay nada que se pueda hacer por estos usuarios.
Una de las cosas que se pueden hacer es agregar el atributo type a los links. Este atributo lleva como valor el MIME type del archivo destino. No molesta, y en ciertos casos puede ayudar. Esto no es un reemplazo del MIME type que envía el servidor.
<a href="cancion.mp3" type="audio/mpeg">Escuchá la canción</a><br> <a href="videoclip.avi" type="video/avi">Mirá el videoclip</a>
Algo más divertido es usar metadata, esto es, un pequeño archivo que referencie al archivo real. Esto sirve para hacer que el archivo de medios se reproduzca automáticamente, por ejemplo:
<a href="musica.m3u" type="audio/x-mpegurl">Escuchá las canciones</a>
Y el archivo musica.m3u es simplemente un archivo de texto plano que contiene la URL absoluta del archivo MP3:
http://mi.servidor.com/media/cancion.mp3
En el archivo M3U pueden haber varias URLs, una por línea, conformándose así un playlist. Notá que lleva un MIME type distinto al del MP3. Lo que hacen los archivos M3U es que al descargarlos el navegador de inmediato abre el reproductor multimedia (ej: WinAmp) y le pasa las URLs. Esto hace que el navegador se desentienda, ya que es el mismo reproductor multimedia el que gestiona la descarga y guarda el archivo en su caché. Esto permite cosas muy interesantes, está en vos probarlo. Da la impresión de que la canción se reproduce de inmediato, y en cierta forma es así.
Si bien para video no hay un único formato de metadata, y cada reproductor tiene el suyo, como los tres reproductores más importantes pueden abrir un DivX los tres archivos de metadata (que solo pesan algunos bytes) van a apuntar al mismo video de 20 Mb.
El formato de metadata más simple es el del Real Player, es igual que el M3U (o sea, un archivo de texto con una URL) pero se debe guardar con la extensión .ram y enviarse con el MIME type audio/x-pn-realaudio (parece audio, lo que pasa es que es lo mismo para metadata de audio y video). Ejemplo:
http://mi.servidor.com/media/videoclip.avi
Para Windows Media Player y QuickTime Player los formatos de metadata están hechos en XML, por lo que son ligeramente más complicados, pero si disponés de estos programas ellos te crean la metadata por vos.
En el caso del QuickTime, por ejemplo (yo uso QuickTime Pro) abrís el archivos desde su URL, esto es, vas a Archivo > Abrir URL y tipeás la URL: http://mi.servidor.com/media/videoclip.avi y abrirá el video. Luego, en la opción Exportar, lo guardás como "enlace de contenidos de QuickTime". Eso es un archivo de metadata XML que usa la extensión .qtl y se ve así:
<?xml version="1.0"?> <?quicktime type="application/x-quicktime-media-link"?> <embed src="http://mi.servidor.com/media/videoclip.avi" />
El archivo QTL debe llevar el MIME Type application/x-quicktimeplayer.
Con Windows Media Player es parecido, debés abrir la URL y luego crear un archivo ASX, acá hay un ejemplo:
<asx version="2.0">
<entry>
<ref href="http://mi.servidor.com/media/videoclip.avi" />
</entry>
</asx>
Su MIME type es video/x-ms-asf.
Por último vamos a hacer un ejemplo de todo junto y con una ornamentación en CSS 2. El fragmento de HTML queda así:
<a href="cancion.m3u" type="audio/x-mpegurl">Escuchá la canción</a><br> <a href="cancion.mp3" type="audio/mpeg">Bajá la canción</a><br><br> <a href="video.ram" type="audio/x-pn-realaudio">Mirá el video con Real Player</a><br> <a href="video.qtl" type="application/x-quicktimeplayer">Mirá el video con QuickTime</a><br> <a href="video.asx" type="video/x-ms-asf">Mirá el video con Windows Media Player</a><br> <a href="videoclip.avi" type="video/avi">Bajá el video</a>
Sería conveniente que en los links directos a los archivos MP3 y AVI pongas la aclaración de que clickeen con el botón secundario y usen la opción de "guardar destino como" o "descarga directa" para que los usuarios fuerzen el download.
Para adornar lo anterior con CSS 2, insertando íconos de los reproductores para los links de metadata específicos, simplemente agregamos esto a la hoja de estilos:
a[type="audio/x-pn-realaudio"]:before {content:url("real.gif"); margin-right:1ex;}
a[type="application/x-quicktimeplayer"]:before {content:url("qt.gif"); margin-right:1ex;}
a[type="video/x-ms-asf"]:before {content:url("wmp.gif"); margin-right:1ex;}
El margen derecho es para separar un poco el ícono del texto. Esto no anda en Internet Explorer, se verá sin íconos, pero en Firefox funciona perfectamente.
La única consideración, por supuesto, es que el servidor envíe los MIME types correctos.
Un método que habitualmente se ve, es el de usar la etiqueta object o la propietaria embed para mostrar el video. Esto lo hacen por muchas razones, sin embargo casi siempre lo veo en el caso de video y no de música, quizás sea porque todos tenemos bastante incorporado el concepto de "bajar música" entonces entendemos más el download de audio pero al video lo entendemos como visualización.
El método anterior, que llamo correcto
o recomendado
, hace que al clickear un link se descargue el recurso o más habitualmente se abra el reproductor multimedia por defecto y lo reproduzca. La página web simplemente contiene el link inicial y una vez que la reproducción está en curso, se puede cerrar.
Al poner videos (o música) en un object lo que se hace (y creo que es la única ventaja) es que el video se muestre en el contexto de la página.
La otra razón por la que los diseñadores web ponen videos como objects es que creen que de este modo el usuario no los puede guardar en su sistema. Error: para ver algo mediante protocolo HTTP ya debe estar guardado localmente. El video se guarda en el caché del navegador. Además, las implementaciones de los reproductores permiten guardarlos con el menú, aunque el Real Player no lo permite y el QuickTime lo permite sólo si está registrado.
A continuación, la forma correcta de poner un video como object en una página web:
<object width="240" height="180" type="video/mpeg" data="media/video.mpg">
<param name="FileName" value="media/video.mpg">
<param name="SRC" value="media/video.mpg">
<param name="Source" value="media/video.mpg">
<param name="URL" value="media/video.mpg">
</object>
Noten varias cosas: no uso los atributos classid ni codebase. Eso es porque no quiero que use ninguna implementación específica, sino que quiero que use cualquier reproductor disponible. Por eso sólo uso los atributos type para especificar el tipo de video, y data para especificar su ubicación.
Todos los parámetros que puse son para especificar la dirección del video, ya que ciertas implementaciones ActiveX no reciben el atributo data del object y necesitan que se lo pase como parámetro. Como una implementación ActiveX, Java o plugin sólo lee los parámetros que conoce e ignora el resto, puedo ponerlos todos.
Por ejemplo, Windows Media Player necesita el parámetro FileName y el QuickTime creo que necesita SRC.
No uso la etiqueta embed porque es propietaria de Netscape. Cuando uno pone un object es necesario especificar el alto y el ancho para que renderice el objeto en la página. El alto y ancho que se pongan no los usará sólo para el video sino también para los controles del reproductor multimedia, lo cual es un problema ya que los controles de los reproductores multimedia no miden todos lo mismo. Por ejemplo el de QuickTime son 16 px de alto (es una barrita que se agrega abajo, así que sólo incrementa la altura del objeto).
En cambio, este objeto sólo se ve en máquinas que usan Windows, Internet Explorer y tengan QuickTime instalado:
<object width="240" height="180" classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B">
<param name="SRC" value="media/video.mpg">
</object>
Esto es así porque los otros navegadores y sistemas ignoran ActiveX y sus códigos CLSID, y usan el atributo classid para ubicar applets Java, Python, etc. De hecho, en Linux o Mac OS no existe el registro como lo existe en Windows. Ese video sólo se podrá reproducir en circunstancias muy especiales, una lástima porque cualquier computadora puede reproducir un video en formato MPEG-1.
A continuación, un resumen con los pros y los contras de el método de "objects" o "embeds" para la multimedia en la web:
Esto lo ví en algunos sitios, como por ejemplo PureVolume lo hace compulsivamente. Lo que hacen es enviar el contenido con un MIME type genérico application/octet-stream o inexistente application/force-download para que los navegadores no tengan otra opción más que guardarlo.
Esto no siempre funciona, ya que navegadores como Internet Explorer ignoran los MIME types enviados por el servidor y toman decisiones en base a la extensión del archivo.
Los navegadores tienen sus propias funcionalidades para forzar un download, que se hace clickeando con el botón secundario del mouse sobre el link.
Para un tipo de contenido siempre hay que enviar el MIME type correspondiente.
Esto ni siquiera tiene sentido, pero mucha gente lo hace. Crean un zipeado con la música o el video para que la única acción posible sea descargarlo.
Cuando les digo que los navegadores ya incluyen funcionalidades para forzar el download de un archivo
me responden que los usuarios son demasiado estúpidos como para usar bien el navegador, por eso tenemos que hacer las cosas por ellos
. Mi respuesta es si los usuarios no saben usar el navegador, ¿qué te hace pensar que van a saber usar el WinZip?
.
La realidad es que hay usuarios que no tienen un administrador de archivos comprimidos, y no se gana en tamaño ya que los archivos de medios ya están comprimidos. Un MP3 no se comprime con una tasa mayor al 2%. Es ridículo.
OK, espero que esto le haya servido a alguien para que sepa cuál es la mejor manera de presentar contenido multimedia en la web.
