Plataformas de publicación y distribución de audio y vídeo

  • Alex Ribelles García

    Consultor y tutor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC desde sus inicios. Ingeniero de Telecomunicación por la UPC y máster en Telecomunicación en la Empresa por la UPF. En la actualidad, técnico de sistemas en el Departamento de Emisión de Televisión de Cataluña en proyectos de cadenas y continuidades digitales, emisiones IP y digital signage.

PID_00265535
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya), no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Introducción

Por medio de los módulos anteriores, se han presentado y seleccionado los parámetros de codificación del vídeo y audio de la manera más adecuada al contenido que, originalmente, debían representar. Así, en este módulo, se aborda, desde un punto de vista práctico, el modo de entregar estos flujos de datos a un público amplio.
La primera parte del módulo se centra en lo siguiente: en las plataformas de publicación de contenidos; en las soluciones de software dedicadas a la codificación y publicación de los flujos en función de la calidad deseada; y en el tipo de material a transmitir. En su descripción, quedarán patentes algunas limitaciones que reclamarán la necesidad de mecanismos adicionales para asegurar la distribución de tales flujos por la red. Se ilustrará con ejemplos de software propietario que posibilitan dar servicio de vídeo, bajo demanda, a pequeñas y medianas empresas.
Las plataformas de distribución de contenidos fundamentarán la segunda parte del módulo, describiéndose sus características y funciones; asimismo, se realizará una visión del mercado de plataformas de distribución actual para Internet. Se ilustrará con ejemplos de empresas que ofrecen soluciones de distribución de vídeo en todo el mundo. Finalmente, se describirán las líneas de investigación en el futuro de las plataformas de distribución.

Objetivos

Los objetivos que el estudiante alcanzará tras el estudio de este módulo son:

  1. Identificar y diferenciar las tecnologías de publicación de audio y vídeo.

  2. Describir los requerimientos de un contenedor de vídeo compatible con streaming e identificar los existentes actualmente.

  3. Enumerar y describir las soluciones comerciales más relevantes de publicación de streaming audio/vídeo.

  4. Definir una plataforma de distribución de contenidos, su estructura y su funcionamiento.

  5. Identificar las aplicaciones de una plataforma de distribución de contenidos.

  6. Valorar el coste de su uso.

  7. Conocer las principales PDC más importantes actualmente en funcionamiento.

1.Plataformas de publicación

Llegado el momento en que debe seleccionarse la manera mediante la cual publicar el material audivisual por red, hay que plantearse qué tecnología utilizar y el tipo de formato del material que cabe transmitir.
A lo largo de los años, en paralelo, han ido mejorando tanto las tecnologías de publicación en la red como los formatos contenedores de vídeo que agilicen tal publicación. Ambas líneas de desarrollo están íntimamente relacionadas.

1.1.Las tecnologías de publicación

Podemos definir cuatro tecnologías de publicación audiovisual en Internet, que se presentan en orden cronológico (coincidente con una mayor complejidad):
1) Primera técnica: vídeo incrustado
Este modelo de plataforma de publicación básica fue la primera aproximación a la integración de audio y vídeo en la web. Requería de un servidor web, por lo que hacía uso del protocolo HTTP clásico, sencillo y con mecanismo de confirmación por el cliente de los datos enviados, pensado para la transmisión de pequeños ficheros a un conjunto simultáneo de clientes. El fichero de vídeo se incrustaba o integraba en una página web en HTML, como cualquier otro fichero, mediante las instrucciones HREF, EMBED, BGSOUND, etc.
El cliente solicitaba el fichero de vídeo y este se descargaba temporalmente en la caché del programa navegador utilizado, exactamente igual a la de cualquier otro tipo de fichero que pueda publicarse en una página web (imágenes, pdf, doc, etc.).
La mayoría de formatos de archivo solo permiten abrir el contenido cuando se ha descargado completamente: por ejemplo, cualquier documento de Office, los antiguos Adobe PDF (versión 5 o anterior), etc. Sin embargo, otros sí posibilitan iniciar su visualización tras comenzar la descarga y acceder a un mínimo de su contenido; es el caso de las imágenes JPEG grabadas en formato progresivo, los documentos PDF modernos, etc.
En aquellos tiempos, los formatos contenedores de vídeo no estaban preparados para poder ser reproducidos de forma progresiva, por lo que se generaba una espera directamente proporcional a la duración del material. Peor consecuencia que este retardo es que el equipo cliente debía poseer suficientes recursos para poder cargar el fichero en memoria y así abrirlo: sin duda, no era válido para dispositivos móviles. A pesar de todos estos hándicaps, este sistema de vídeo incrustado es actualmente utilizado para la publicación de pequeños vídeos de duración breve.
Ejemplo: Macromedia Flash SWF (1998)
m1910_m3_02.gif
El formato SWF es más antiguo y fue el primero que posibilitó incrustar audio y vídeo en una animación Flash. Al publicar el SWF en una página de un servidor web tradicional, el plug-in o complemento Flash del navegador utilizado para visualizarla necesitaba descargar el fichero por completo para reproducirlo, de modo que este sistema solamente era interesante para vídeos de duración de unos pocos segundos.
Otras limitaciones claras eran que, para cambiar una sola secuencia de ese vídeo, se debía rehacer el fichero SWF por completo y volverlo a publicar. Más todavía: la carga en memoria de vídeos de larga duración generaba desincronizaciones con el audio tras la reproducción de dos o tres minutos de la película.
2) Segunda técnica: descarga progresiva
Estas limitaciones y la creciente demanda por contenido multimedia en la web llevaron al desarrollo de un mecanismo de distribución de descarga progresiva, por el que la reproducción es posible al recibir una parte suficiente de datos.
La descarga progresiva, además de reducir la espera del cliente, elude los problemas de sincronía audio-vídeo y, sobre todo, simplifica los requerimientos técnicos del reproductor en términos de memoria, abriendo la puerta a los dispositivos móviles.
Figura 2. Esquema de la descarga progresiva de un fichero de vídeo
Figura 2. Esquema de la descarga progresiva de un fichero de vídeo
No todos los formatos son compatibles con este sistema de descarga; el fichero de vídeo ha de tener un formato contenedor que sea capaz de soportarlo. Su estructura debe poseer, al menos, una cabecera que prepare al programa reproductor indicándole los datos básicos del tipo de codificación y duración para preveer las necesidades de memoria que requerirá; además, los datos de vídeo y audio tienen que estar debidamente combinados, pues si el audio se encuentra después de todos los datos de vídeo (o viceversa) no será posible reproducir nada en condiciones hasta no recibir todo el fichero. Tal como se puede ver en la tabla resumen de tipos de contenedores, que se presentó en el módulo 2, en el caso de archivos de vídeo algunos tipos de formatos contenedores están preparados para streaming, es decir, para poder ser visualizados sin esperar a su descarga completa.
Sin embargo, la técnica de descarga progresiva sigue básandose en el uso de un servidor web genérico, diseñado principalmente para almacenar webs. Cuando un cliente hace una petición, todo el ancho de banda disponible es usado para descargar los datos al cliente de la forma más rápida posible.
En condiciones normales, un servidor web envía numerosos ficheros pequeños a un número limitado de usuarios simultáneos, lo que divide el ancho de banda entre los envíos simultáneos, aunque, al ser de pequeño tamaño, es suficiente. No obstante, en el momento en que ha de enviar ficheros de audio y vídeo a un número creciente de clientes simultáneos, el ancho de banda siempre será un recurso escaso.
No hay una distribución inteligente del ancho de banda entre los diferentes clientes: aquellos que están descargando un vídeo codificado a 256 Kbps lo recibirán a la misma velocidad que quienes descargan otro vídeo a 2 Mbps, ya que el servidor web no analiza previamente las características del fichero a enviar.
Por otro lado, el tradicional protocolo web HTTP opera utilizando protocolo de transporte TCP, el cual asegura la recepción de los datos (tras los envíos, debe recibir las confirmaciones de recepción del cliente; si no las recibe, reenvía los datos). Esta seguridad en la transmisión no es eficiente para audio y vídeo, no por el volumen de datos, sino porque la pérdida de alguno no afecta sensiblemente a ojos y oídos del cliente, y porque si reenvía datos que se han perdido previamente no puede asegurarse que lleguen a tiempo para ser reproducidos.
Ejemplo: descarga progresiva y el formato contenedor FV de Macromedia Flash (2003)
Macromedia incorpora la descarga progresiva al introducir el nuevo formato contenedor FLV (Flash Video) preparado para este. Aparte de las mejoras incorporadas en la codificación de audio y vídeo (ved la tabla de contenedores del módulo 2), el fichero SWF podía asociarse a un fichero externo FLV de vídeo, independizando el proyecto del contenido audiovisual.
Para preveer pausas involuntarias de la reproducción del audio y vídeo por falta de datos en conexiones lentas, posteriormente Flash redefinió la suficiencia de datos como lo imprescindible para asegurar la reproducción completa del fichero FLV, haciendo una previsión conservadora según la velocidad de descarga estimada, el peso total del fichero y la duración del vídeo.
3) Tercera técnica: streaming de vídeo
Por estas razones se definió un tercer mecanismo de distribución, el streaming, mediante la adición de un servidor adicional al servidor web (o servicio adicional en el mismo servidor web) cuyas características superan las limitaciones indicadas.
El servidor de streaming analiza la cabecera del contenedor del material previamente a su transmisión, con lo que conoce la velocidad de codificación (bit rate) necesaria para su correcta reproducción, reservando un ancho de banda idéntico para su streaming.
Esta gestión inteligente y personalizada optimiza los recursos mejor que cualquiera de los otros mecanismos de transmisión vistos.
Es más: a diferencia de la descarga progresiva, es posible comenzar la reproducción del streaming desde cualquier punto del fichero. La estructura del contenedor de los ficheros preparados para streaming se divide en pequeñas unidades, cada una con información relativa a su porción de material audiovisual y con una marca de tiempo que indica su posición en el conjunto del fichero.
Ya que el servidor de streaming analiza las características del material a transmitir, se condicionan los formatos contenedores que pueden utilizarse en cada tipo de servidor de streaming: un servidor Windows Media Server no puede transmitir ficheros en Real Video o Real Audio, pero sí Windows Media Video o Windows Media Audio.
Siempre hay un retraso entre la llegada de los datos al cliente y el inicio de la reproducción al llenar un buffer que previene de las variaciones en el tiempo de llegada de los paquetes por cambios de congestión de la red.
El streaming previene además la descarga de los ficheros de audio y vídeo por parte del cliente, reduciendo las posibilidades de copiado (pirateo), al enviar los paquetes de datos directamente a la aplicación cliente y descartándolos una vez reproducidos.
Así, hace uso del protocolo UDP, que no hace retransmisión de datos perdidos en aras de un mejor rendimiento en transmisiones de datos en tiempo real, tolerantes a la pérdida de datos. Por su naturaleza, UDP tiene mayor prioridad que TCP en los routers de tráfico, incluso en redes congestionadas, asegurando su servicio. Algunos fabricantes utilizan incluso UDP Resend, un esquema de retransmisión de datos perdidos que solo reenvía esos datos al cliente si hay tiempo para su reproducción (por ejemplo, Microsoft en sus antiguos Windows Media Server).
Entre el cliente y el servidor de streaming se crea una conexión paralela a la UDP, pero en protocolo TCP para transmitir las órdenes de control del reproductor cliente (PLAY, PAUSE, etc.) al servidor o viceversa, para controlar cámaras IP remotamente, para enviar un código de tiempo cuadro a cuadro, etc. Este sistema de uso de UDP para datos y TCP para control se denomina RTSP (real time streaming protocol).
Figura 3. Conexión RTSP
Figura 3. Conexión RTSP
En aquellas situaciones en las que el protocolo RTSP no está permitido, algunos fabricantes implementan soluciones compatibles con HTTP y su puerto 80, por ejemplo, en las redes privadas. Estas soluciones se basan en HTTP Streaming, una versión modificada de HTTP. Y en redes de muy alta velocidad y de alta calidad (de bajas pérdidas de datos) como las redes ópticas, se está volviendo hacia atrás, utilizando TCP como protocolo de todo el sistema para asegurar la máxima calidad de reproducción del material transmitido.
Ejemplo: Adobe Flash Media Server (2005)
m1910_m3_05.gif
Adobe da un paso más y plantea una solución más robusta y consistente, a la hora de distribuir audio y vídeo, que utilizar descarga progresiva en un servidor web tradicional, ofreciendo un servidor dedicado (Adobe Flash Media Server) que gestiona, de manera inteligente, la capacidad de conexión de cada cliente y optimiza el uso de sus recursos. Nos referimos al streaming, gracias al cual el vídeo comienza antes que con la descarga progresiva, consume menos recursos del servidor y del cliente, y facilita el seguimiento de incidencias y la facturación del servicio.
No apuesta por RTSP, sino por un protocolo de streaming propietario RTMP o, desde la versión 10.1 de Flash Player, por HTTP Streaming. En este último caso, ligado al uso del contenedor FLV con códec MPEG-4.
4) Cuarta técnica: P2P
Esta nueva línea en pleno desarrollo rompe con el modelo cliente-servidor utilizado hasta ahora y apuesta por un modelo descentralizado basado en las redes peer-to-peer (P2P), en las que cada cliente puede ser consumidor y, a la vez, publica y distribuye. Se apoya en alguno de los protocolos de streaming explicados.
Un ejemplo ilustrativo: Adobe Flash Player 10 (2010)
m1910_m3_06.gif
Desde esta versión se capacita a los clientes Flash Player a compartir audio, vídeo y datos a través de una conexión directa a otros clientes sin pasar por ningún servidor. Utiliza un protocolo propietario de Adobe, RTMFP, basado en UDF.

1.2.Los contenedores de vídeo para streaming

No todos los formatos contenedores son compatibles con streaming, tal como se vio en el módulo 2. Por ejemplo, el antiguo formato AVI 1.0 (que posteriormente se modificó para aceptar streaming) se estructura en bloques de datos numerados denominados chuncks. Asimismo, posee una única cabecera al inicio del archivo donde indica las características del contenido: duración total del vídeo, máxima velocidad de transferencia para su descarga progresiva, número de flujos de audio, vídeo y datos (subtítulos) que contiene, espacio recomendado a reservar en el buffer del receptor para almacenar chuncks, ancho y alto del vídeo en píxeles, frecuencia de cuadro, profundidad de color, códec de vídeo utilizado, códec de audio utilizado, etc.
Así las cosas, parece tener toda la información necesaria para ser reproducido, pero solo desde el principio. No es posible reproducir a partir de cierto punto si no se ha descargado previamente el fichero hasta, al menos, ese punto. Es válido, pues, para descarga progresiva pero no para streaming: un contenedor de vídeo compatible con streaming ha de posibilitar la reproducción desde cualquier punto del fichero, en particular:

  • Poseer una cabecera que indique las características principales del contenido de audio y vídeo para notificar al servidor de streaming qué recursos de red deberá reservar para su transmisión en condiciones óptimas.

  • Estructurarse en bloques independientes de audio y vídeo denominados comúnmente átomos (1) , cada uno con una cabecera que caracterice y posea marcas de sincronía para identificarlo dentro del conjunto del fichero y posibilitar el acceso directo a ese punto.

  • Cada átomo debe tener la información audiovisual suficiente para poder iniciar la reproducción en ese punto, es decir, debe abarcar un segmento sincronizado de cada flujo (2) (audio, vídeo y datos).

Figura 4. Estructura de cualquier fichero de vídeo preparado para streaming
Una cabecera con información general y una serie de átomos con contenido fragmentado de audio y vídeo. Si el fichero es muy grande, es habitual añadir algún átomo intermedio.
Una cabecera con información general y una serie de átomos con contenido fragmentado de audio y vídeo. Si el fichero es muy grande, es habitual añadir algún átomo intermedio.
La ubicación de los flujos en cada átomo ha de ser multiplexada, es decir, en su interior se deben combinan alternativamente y de manera inteligente los datos de todos los flujos. Si se almacenase primero el flujo de vídeo, después el de audio y finalmente el de datos, hasta la lectura completa del bloque de vídeo no se podría comenzar a reproducir el vídeo junto con el audio.
Un ejemplo: Flash Video y el formato base ISO
El contenedor Flash Video es el estándar de streaming más extendido actualmente, y seleccionado como el de referencia para empresas que ofrecen este servicio como YouTube, BBC Online, Hulu, Yahoo Video, etc. Este contenedor se almacena como fichero de vídeo en los formatos FLV y el mejorado F4V (2010) y puede ser integrado dentro de un fichero SWF.
El F4V, al igual que otros contenedores como MP4, 3GPP, etc., se inspira en una idea más universal, la especificación MPEG-4 Parte 12, denominada comúnmente ISO base, un modelo global consensuado y bien especificado respaldado universalmente por la organización ISO, la cual lo diseñó a partir del contenedor QuickTime para facilitar la edición, presentación, gestión e intercambio del material por cualquier medio, independientemente del protocolo utilizado.
Centrándonos en el caso F4V, su estructura es básicamente ISO, añadiendo sus propias interpretaciones:
Figura 5. Estructura de Flash F4V
Figura 5. Estructura de Flash F4V
Puede verse que es modular, descomponible en objetos muy sencillos, cada uno con una misión específica (3) . Cada objeto se denomina caja (box) y no hay nada que no forme parte de alguna, y cada caja puede contener otras subcajas. Sin duda, la idea general de átomo que se comentaba antes coincide plenamente con el uso de la caja como elemento básico de este contenedor.
1) Caja ftyp
En primer lugar, hay una caja Tipo de Fichero (ftyp) de valor 3 o 4 caracteres que informa así al programa reproductor del tipo de material que contiene.
Webs recomendadas

Una lista puede encontrarse en http://www.mp4ra.org/filetype.html. En ella se ve claramente que no aparece indicada ningún ftyp que indique Flash Video; Adobe se acogió al ISO base, pero de manera unilateral, sin registrarse. Para tener una lista de todos los ftyp (registrados o no), hay que acceder a http://www.ftyps.com, donde aparece f4v como el de Flash Video.

2) Caja MovieBox moov
La caja o átomo moov es la cabecera única del fichero f4v; puede contener otras cajas que definen en conjunto la estructura de los datos (un TrackBox o trak para el vídeo, otro TrackBox o trak para audio, MediaBox o mdia, etc.; ved el gráfico adjunto), y está presente en todos los contenedores que se acogen a ISO base. Incluye un índice de frames, trak hint, útil tanto en streaming como en descarga progresiva.
Esquema
m1910_m3_10.gif
3) Caja MediaData mdat
A continuación, y de forma multiplexada o paralela, presentamos las pistas de vídeo y de audio dentro de la gran caja mdat. Cada una de las pistas se subdivide en pequeños subbloques, cada uno marcado con un código de tiempo, y pueden estar o no protegidos bajo contraseña u otro mecanismo de protección. Todo un guiño a su uso en aplicaciones de valor añadido.
Así, no es accesible de manera instantánea cualquier punto del vídeo y audio: al desear reproducir desde un punto específico, el cual se sitúa siempre dentro de un subbloque, es imprescindible leer la cabecera de este para confirmar los derechos de acceso al material y desplazarse dentro del subbloque hasta acceder al punto exacto deseado. Eso supone siempre cierto tiempo de análisis hasta poder reproducir el material audiovisual. Sin duda, cuanto más pequeños son los subbloques menor es el tiempo de acceso, pero más grande es la sobrecarga en bits que supone el creciente número de cabeceras, por lo que es necesario un compromiso entre la eficiencia en el acceso y el tamaño del fichero.
Ejercicio: validación de ficheros FLV
Antes de colgar un fichero FLV o F4V en la red, es recomendable aplicarle la herramienta flvcheck (versión Windows o Linux), pues valida su estructura de cajas. Está limitado a ficheros menores de 4 Gbytes y pensado para FLV, pero funciona con la mayoría de F4V.
Se ejecuta en la línea de comando y su sintaxis es: 
flvcheck –f "fichero_a_analizar.f4v" -v
El resultado es la validación del fichero y, además, un volcado de los valores de cada caja ftyp y moov.
Por ejemplo: 
C:\Users\Alex>flvcheck -f "Flash10 P2P.f4v" -v

FLVCheck version 1.0 - Utility to validate flv and mp4 media files.
Copyright (C) 2008 Adobe Systems Incorporated. All rights reserved.
www.adobe.com

File: Flash10 P2P.f4v
 
ftyp/   28
moov/   648485
moov/mvhd/      108
moov/trak/      373763
moov/trak/tkhd/ 92
moov/trak/mdia/ 373663
moov/trak/mdia/mdhd/    32
moov/trak/mdia/hdlr/    44
moov/trak/mdia/minf/    373579
moov/trak/mdia/minf/vmhd/       20
moov/trak/mdia/minf/dinf/       36
moov/trak/mdia/minf/stbl/       373515
moov/trak/mdia/minf/stbl/stsd/  171
moov/trak/mdia/minf/stbl/stsd/avc1/ 155
moov/trak/mdia/minf/stbl/stsd/avc1/avcC/        69
moov/trak/mdia/minf/stbl/stts/  117560
moov/trak/mdia/minf/stbl/stsc/  12372
moov/trak/mdia/minf/stbl/stsz/  58796
moov/trak/mdia/minf/stbl/co64/  8256
moov/trak/mdia/minf/stbl/ctts/  117560
moov/trak/mdia/minf/stbl/stss/  58792
moov/trak/      274183
moov/trak/tkhd/ 92
moov/trak/mdia/ 274083
moov/trak/mdia/mdhd/    32
moov/trak/mdia/hdlr/    68
moov/trak/mdia/minf/    273975
moov/trak/mdia/minf/smhd/       16
moov/trak/mdia/minf/dinf/       36
moov/trak/mdia/minf/stbl/       273915
moov/trak/mdia/minf/stbl/stsd/  103
moov/trak/mdia/minf/stbl/stsd/mp4a/     87
moov/trak/mdia/minf/stbl/stsd/mp4a/esds/        51
moov/trak/mdia/minf/stbl/stts/  32
moov/trak/mdia/minf/stbl/stsc/  12372
moov/trak/mdia/minf/stbl/stsz/  253144
moov/trak/mdia/minf/stbl/co64/  8256
moov/trak/      423
moov/trak/tkhd/ 92
moov/trak/mdia/ 323
moov/trak/mdia/mdhd/    32
moov/trak/mdia/hdlr/    55
moov/trak/mdia/minf/    228
moov/trak/mdia/minf/nmhd/       12
moov/trak/mdia/minf/dinf/       36
moov/trak/mdia/minf/stbl/       172
moov/trak/mdia/minf/stbl/stsd/  32
moov/trak/mdia/minf/stbl/stsd/amf0/     16
moov/trak/mdia/minf/stbl/stts/  32
moov/trak/mdia/minf/stbl/stsc/  36
moov/trak/mdia/minf/stbl/stsz/  32
moov/trak/mdia/minf/stbl/co64/  32
uuid/   56013
mdat/   48922658
 
11-07-17 20:19:04       Flash10 P2P.f4v passed
Si el análisis devuelve un error, esta herramienta solo puede corregirlo si es un fichero FLV y el error está en la metadata (si está en la estructura, poco puede hacer). En este caso, se aplica: 
flvcheck -m "fichero_corrupto.flv" -v
Ejercicio: validación de fichero F4V
Hay una herramienta específica de aplicación a ficheros F4V que detecta errores y corrige problemas de estructura: Adobe F4V Post Processor.
Entre sus opciones, nos centramos en la no documentada –c que corrige estructura: 
f4vpp -c "fichero.f4v"
En la documentación asociada de la herramienta se indican los diferentes mensajes de error que puede generar en la detección de problemas.
Otro ejemplo: 3GPP2 (2007)
Desde el punto de vista informativo, el formato 3GPP2 (cuyos ficheros tienen la extensión .3g2) también se basa en el contenedor base ISO, y su estructura es representable de la siguiente manera:
Figura 6. Estructura de 3GPP2
Figura 6. Estructura de 3GPP2
Básicamente es similar a la de Flash Video al tener un origen común.

1.3.Soluciones comerciales de streaming

La mayoría de soluciones comerciales de streaming son plataformas propietarias o basadas en software de terceros, también propietario. En general, los niveles de servicio que ofrecen son similares, y tienden a mantener al cliente cautivo haciéndolo depender de un formato contenedor en particular, soportado por la plataforma de streaming.
Sin embargo, al ser un mercado en expansión y aparecer con fuerza proveedores virtuales de soluciones de streaming, se están redefiniendo para ser más abiertos, escalables y con un coste de licencias decreciente.
1) Adobe Flash Media Server y Adobe Flash Media Live Encoder
Existente para Windows y Linux, este software posibilita publicar vídeo bajo demanda o vídeo en tiempo real a usuarios con Adobe Flash Player, incluyendo dispositivos móviles como iPad, iPhone, iPod (4) y Android. Siempre emite información mediante ficheros Flash SWF y, si se activa su servidor web propio (Apache), puede proveer también las páginas web que incluyan el material.
Figura 7. Comunicación entre Flash Media Server y el cliente
Figura 7. Comunicación entre Flash Media Server y el cliente
Trabaja con el protocolo RTMP, pero si se instala el servidor web Apache junto con este puede ofrecer contenidos por HTTP clásico (aquí es donde entra la nueva compatibilidad con los dispositivos iOS de Apple, que utilizan el protocolo de Apple HTTP Live Streaming).
Si trabaja en una red local cerrada, puede realizar multicast mediante RTMFP.
En el caso que se desee transmitir vídeo en tiempo real, se necesita de un software adicional, Adobe Flash Media Live Encoder (para Windows o Mac), que gestiona la señal de vídeo de la tarjeta capturadora y la codifica en H.264 o VP6, enviando el stream al Flash Media Server o, sencillamente, creando un fichero F4V.
Figura 8. Pantalla de trabajo de Flash Media Live Encoder
Figura 8. Pantalla de trabajo de Flash Media Live Encoder
2) QuickTime Streaming Server (QTSS)
Es un servicio integrado (daemon) en el sistema operativo del servidor Mac OS X, capaz de suministrar servicio de streaming en H.264 o 3GPP tanto de vídeo en vivo como de ficheros de vídeo.
Figura 9. Pantalla de configuración de QTSS
Figura 9. Pantalla de configuración de QTSS
Su funcionamiento es sencillo: se define una carpeta (usualmente /Library/QuickTimeStreaming/Movies/) en la que se alojan los vídeos a publicar, el número máximo de conexiones simultáneas a aceptar y el máximo ancho de banda de salida (throughput) que dará servicio. Se recomienda que este valor no supere el 75% del ancho de banda de subida de la conexión del servidor a Internet (o a la red local en la que se encuentren los clientes si es que da servicio interno a, por ejemplo, una empresa).
También puede gestionar relay streams, es decir, aceptar streams de otro servidor y reenviarlo a un tercero o a varios. Esto ocurre en el caso de desear transmitir vídeo en tiempo real, pues necesita siempre de otro servicio, QuickTime Broadcaster (incluido también en el sistema operativo), instalado en el mismo servidor o en otro, que se encarga de codificar en tiempo real la fuente de audio y vídeo a transmitir.
Por defecto, trabaja con el puerto 80 y con los protocolos RTSP sobre TCP y RTP sobre UDP. Si se trabaja en una red local, puede realizar multicast.
Tiene gestión de usuarios para limitar el acceso a los contenidos a distribuir. El acceso al contenido es tan sencillo como indicar en el navegador: 
rtsp://servidor/carpeta/subcarpeta/fichero
La gestión de contenidos puede ser tan sencilla como almacenar los ficheros en la carpeta seleccionada, pero Apple ofrece una aplicación gratuita, QTSS Publisher, la cual, instalada en el mismo servidor o en otro equipo de la red, facilita la gestión.
Figura 10. Aplicación QTSS Publisher
Figura 10. Aplicación QTSS Publisher
Con esta aplicación se simplifica la subida de los ficheros al servidor, se preparan los ficheros para streaming o para descarga progresiva, se crean listas de reproducción de ficheros de audio MP3 o de vídeo en MP4 o 3GP, e incluso se generan páginas web básicas para ofrecer los contenidos.

2.Plataformas de distribución de contenidos

La aparición de la web como un medio de comunicación presente por doquier, con el que compartir contenido y servicios, ha conducido a un rápido crecimiento de Internet. Al mismo tiempo, el número de usuarios que acceden a contenidos basados en la web y a los servicios en línea está creciendo exponencialmente. Este escenario ha llevado a una gran demanda de ancho de banda de Internet y de sus sistemas de gestión y almacenamiento de contenidos y de aplicación; no obstante, la explosión del acceso a la Red mediante dispositivos móviles no ha mejorado el problema en absoluto.
Los servidores web actuales, incluyendo los servidores de streaming explicados en el apartado anterior, no pueden ofrecer un servicio de calidad cuando alcanzan conexiones de miles de usuarios concurrentes. Como resultado, muchos sitios no son capaces de gestionar esta variada demanda y ofrecer sus servicios de la manera oportuna. Hay que cambiar de planteamiento.
Las plataformas de distribución de contenidos (PDC) han surgido como mecanismo para superar estas limitaciones, ofreciendo la infraestructura necesaria y los mecanismos de presentación de contenidos y servicios de una manera escalable, mejorando así la experiencia de los usuarios web.
El uso de estas plataformas puede encontrarse en muchas comunidades: instituciones académicas, medios de publicidad y compañías publicitarias centradas en Internet, centros de datos, proveedores de servicios Internet (ISP), minoristas de música en línea, operadores móviles, fabricantes de electrónica de consumo y otras.
Junto con el nacimiento, proliferación y consolidación del paisaje de PDC, están entrando en escena nuevas formas de contenidos y servicios de Internet, mientras que la distribución y gestión de contenidos crea nuevos retos técnicos a resolver. De fondo, se plantean nuevos problemas en la arquitectura, el diseño y aplicación de PDC que se tratarán al final del módulo, centrando nuestra atención en los conceptos básicos, para identificar la tecnología subyacente, y su uso final en servicios de vídeo en vivo y bajo demanda.

2.1.La necesidad de una plataforma de distribución de contenidos

Planteemos algunos escenarios cada vez más habituales:
Escenario A: se desea publicar un vídeo publicitario en la Red para ser visualizado por miles de usuarios cada día distribuidos por todo el planeta, asegurando ancho de banda para tod@s ell@s. Y con un presupuesto limitado.
Escenario B: se desea crear una plataforma en línea internacional que dé servicio simultáneo a más de 50.000 personas en todo el planeta, que sea completamente segura, rápida e incluso ser económicamente viable.
Escenario C: una televisión y una radio plantean dar en directo por Internet su programación diaria, pero tienen un presupuesto limitado para adquirir y mantener la gran infraestructura informática y de comunicación necesaria a la hora de dar tal servicio a miles de usuarios simultáneos de manera fiable.
Escenario D: una empresa internacional, con sedes en varios países, desea compartir una serie de vídeos formativos y realizar reuniones con videoconferencia mediante una red que las intercomunique, sin necesidad de mantener ni administrar una infraestructura de comunicaciones compleja.
En las últimas décadas, los usuarios han sido testigos del crecimiento y la madurez de Internet, que ha causado un enorme aumento del tráfico de red, impulsado por la rápida implantación de accesos de banda ancha en entornos domésticos y profesionales, el creciente uso de la red mediante dispositivos móviles y las redes 3G, el aumento de la complejidad de los sistemas y la mayor riqueza audiovisual de los contenidos. La acelerada evolución de Internet genera nuevos retos en la gestión y entrega de contenidos a los usuarios: por ejemplo, los servicios más populares de Internet, a menudo, sufren congestión y se producen “cuellos de botella” por la gran demanda que plantea en sus servicios.
Este repentino aumento en la Red de las solicitudes de contenidos (como, por ejemplo, la ocurrida durante el 11-S en Estados Unidos, el 11-M en España, etc.) es un fenómeno denominado multitud de flash (flash crowds (5) ) o efecto Slashdot. Puede causar en minutos una gran carga de trabajo en uno o varios servidores web específicos y, como resultado, crearse un cuello de botella. Hacer frente a tal demanda inesperada causa una tensión significativa en el servidor web que, finalmente, queda totalmente abrumado por el aumento súbito de tráfico, de tal forma que el sitio web que contiene deja de estar disponible temporalmente.

2.2.Un sencillo caso ilustrativo

Habitualmente, cuando un navegador visita una página de un sitio web, hace una serie de peticiones HTTP al servidor web que almacena localmente los ficheros de todo el sitio, tantas como elementos posea la página web visitada en ese momento (la página HTML, las imágenes que incorpora, la hoja de estilo asociada, los scripts que incluya la página, ficheros de audio, de vídeo, etc.). Como el navegador solo puede gestionar la descarga simultánea de un número limitado de elementos en cada petición HTTP a un mismo dominio (usualmente, dos elementos), debe realizar un largo proceso de peticiones, lo cual reduce la eficiencia de la conexión.
Ilustremos este mecanismo por medio de un caso sencillo de un único cliente contra un servidor web al cual demanda una cierta página web.
Figura 1. Una conexión clásica a un servidor web
Figura 1. Una conexión clásica a un servidor web
Inicialmente (1) el navegador realiza una petición HTTP al servidor web sobre esa página específica. El servidor web (2) procesa la petición y devuelve un número limitado de elementos de la página (generalmente, dos), por ejemplo, el código HTML y una de las imágenes. Estos son transmitidos (3) al navegador, el cual comienza la composición en pantalla. Para recibir a continuación dos elementos más, como por ejemplo un script y wav, se ha de repetir todo el proceso (1)(2)(3).
Tal como puede deducirse, este mecanismo está comprometido en situaciones de alta congestión, pues el número de peticiones puede superar la capacidad de gestión del servidor web. Este hándicap se intenta minimizar con varias técnicas en el lado del servidor (añadiendo una caché (6) , servidores en paralelo, etc.) y reducir la latencia de las peticiones. La mayoría de las veces es suficiente, pero si se desea un aumento superior ha de utilizarse un mecanismo de servicio que se base en una plataforma de distribución de contenido (PDC).
(6) Una caché es, simplemente, una memoria rápida que almacena una copia de cada elemento que es pedido por primera vez por cualquier cliente. El siguiente pedido que realiza cualquier otro cliente se lee de esta memoria rápida en vez de hacerlo desde el disco.
La plataforma de distribución de contenido (PDC) no es más que una colección colaborativa de elementos de red distribuida por Internet, donde el contenido se replica en varios servidores web espejo con el fin de realizar la entrega de los contenidos a los usuarios finales de manera transparente y eficaz. Las PDC se han diseñado para superar las limitaciones inherentes de Internet, posibilitando que el usuario perciba una buena calidad de servicio (QoS) al tener acceso al contenido web en situaciones tan congestionadas. Así, proporcionan servicios que mejoran el rendimiento de la red, maximizando el ancho de banda, mejorando la accesibilidad, el mantenimiento y los cambios del contenido por medio de un mecanismo de replicación de contenido.
Figura 12. Tres clientes sobre una web apoyada en PDC
Figura 12. Tres clientes sobre una web apoyada en PDC
Siguiendo con nuestro ejemplo, el contenido HTML se mantiene en el servidor web original (lamentablemente, el código HTML no puede cachearse), pero el resto del contenido se duplica en varios servidores espejo ubicados alrededor del mundo como si fuesen una cache masiva. En algunas referencias son denominados “la nube” (the cloud).
Una vez cada cliente lee (3) la página HTML recogida (2) como respuesta a su petición (1), en la página HTML se indican las direcciones genéricas de ubicación de los elementos, y mediante un mecanismo de direccionamiento al PDC más cercano al cliente se realizan el resto de peticiones (4). Además, como cada PDC son varios servidores, el navegador puede hacer varias peticiones en paralelo sobre diferentes servidores de cada PDC.
Sin duda, se acelera dramáticamente la lectura de la página web, incluso en condiciones de alta carga, de forma totalmente transparente al cliente, pero trasladando la mayor parte del problema a los mecanismos de sincronización y redireccionamiento internos de la PDC.
Figura 13. Akamai es actualmente la PDC más extensa del planeta; ofrece sus servicios de manera transparente a las empresas más importantes.
Figura 13. Akamai es actualmente la PDC más extensa del planeta; ofrece sus servicios de manera transparente a las empresas más importantes.
A partir del ejemplo, podemos enumerar las funciones típicas de una PDC:

  • Redirección de las solicitudes y servicio de prestación de contenidos, es decir, redirige una solicitud de contenido al servidor de la PDC más cercano al solicitante que posea una copia de tal contenido (servidor caché), utilizando los mecanismos adecuados para evitar la congestión y, así, sobrellevar situaciones de sobrecarga.

  • Externalización de los contenidos y de los servicios de distribución, para replicar o hacer caché (copia) del contenido desde el servidor de origen hasta los servidores web distribuidos de la PDC.

En base a esto, la PDC necesita dos servicios adicionales igualmente importantes para su supervivencia:

  • Servicios de negociación del contenido; para satisfacer las necesidades específicas de cada usuario o grupo de usuarios (acceso bajo pago, restricciones horarias del acceso, restricciones por la ubicación geográfica del usuario, etc.).

  • Servicios de gestión; para administrar los componentes de red, llevar la contabilidad y vigilar e informar sobre el uso del contenido.

Los ámbitos de aplicación de la PDC son, principalmente, los servicios públicos de redes de contenido y las redes empresariales de tamaño medio y grande. Como la PDC es un próspero mercado en estos momentos, se ha convertido en un campo de investigación en donde se introducen constantemente nuevos avances, soluciones y servicios, a un precio en constante caída.
El ámbito de aplicación de las PDC se extiende a todo un abanico de aplicaciones, como se puede ver en el siguiente cuadro. En este curso, se trata la distribución de vídeo bajo demanda y vídeo en vivo como ejemplo de aplicación.

 

En tiempo real

No tiempo real

Multimedia

  • Vídeo en vivo

  • Videoconferencia

  • Internet audio en vivo

  • Intercoms (hoot & holler)

  • Replicación de vídeos entre servidores web

  • Distribución de contenidos

Solo datos

  • Datos de la Bolsa

  • News feeds

  • Compartición de documentos entre varios usuarios en paralelo (whiteboarding)

  • Juegos interactivos

  • Distribución de información de servidor a servidor y servidor a cliente

  • Replicación de bases de datos

  • Distribución de software

Fuente: Cisco Systems

Centremos este módulo en la información básica necesaria para comprender estas plataformas, pues para conocer su “estado del arte” (es decir, lo más novedoso) tendremos que consultar la Red.

2.3.Estructura típica de una PDC

La figura siguiente muestra el modelo básico de la PDC en donde los servidores web, replicados a lo largo del planeta, se sitúan en las redes a las que pertenecen los usuarios que se conectan habitualmente a ellos.
Figura 14. Estructura de PDC
Figura 14. Estructura de PDC
La PDC distribuye el contenido a un conjunto de servidores web esparcidos por el mundo, intentando así que la entrega de este contenido a los usuarios finales sea de una manera eficaz y segura. El contenido se replica o bien cuando los usuarios solicitan este contenido, o bien previamente a esa solicitud, mediante un mecanismo programado que distribuye el contenido nuevo a lo largo de todos los servidores web distribuidos.
Cada usuario accede de modo transparente e involuntario al contenido del servidor web “réplica” más cercano. Así, el usuario termina, sin saberlo, comunicando con un servidor cercano perteneciente a la PDC y accediendo a los archivos de ese servidor.
1) Terminologías
En el contexto de la PDC, la distribución de contenidos se refiere a dar servicio a una petición del usuario final sobre cierto contenido específico (un vídeo, una aplicación en línea, una compraventa de producto en una plataforma en línea mundial, un stream de audio y/o vídeo, etc.).
Como contenido se refiere a cualquier recurso en formato digital que se componga de dos partes fundamentales: los datos y los metadatos.
Como datos se entiende cualquier información estática (documentos, imágenes), dinámica (por ejemplo, un blog o una web) o continua (un stream de audio y vídeo), por lo que su origen puede ser pregrabado u originario de fuentes vivas, y su existencia puede ser perecedera o perenne dentro del sistema.
Como metadatos se entiende una descripción del contenido que facilita su identificación, su búsqueda, incluso su gestión si es multimedia, y sobre todo hace más sencilla su interpretación. Estos metadatos pueden estar incorporados dentro de los propios datos o ser una información separada, ligada de alguna manera a los datos correspondientes.
Respecto al sistema PDC en sí, se compone de tres elementos:

  • El proveedor de contenidos, que asigna una URL a los objetos web a distribuir; es el propietario del “servidor origen” en el que se almacenan los originales de estos objetos web. Cualquier empresa es cliente de un proveedor de contenidos, quien almacena su contenido en línea.

  • El proveedor de la PDC, la compañía que provee la infraestructura técnica a los diferentes proveedores locales o nacionales de contenidos del planeta para que puedan distribuir contenidos de una manera escalable y a escala nacional o planetaria. Por ejemplo, en el ámbito internacional están Akamai, Edgecast, Advection.net, etc.

  • El cliente final, quien accede al contenido mediante su proveedor local de contenido.

Para replicar los contenidos en sus servidores, el proveedor de la PDC utiliza o bien caching de datos (copia los datos cuando son pedidos por un usuario), o bien replica de manera programada sus servidores situados en diferentes localizaciones geográficas. A estos servidores réplica se les denomina subordinados o de frontera, y el conjunto de servidores subordinados de una PDC es el clúster web, su núcleo.
Los servidores subordinados comparten contenido y la dirección URL. Las peticiones de los clientes son redirigidas hacia el servidor subordinado más cercano y este le suministra los contenidos pedidos, sin que el usuario haga operación adicional alguna: es un mecanismo transparente. Igualmente, si el suministro de la información tiene algún coste asociado, el servidor subordinado envía la información necesaria al sistema de contabilidad de la PDC e informa del usuario que la ha demandado y el tráfico de datos cursado.
Sin duda, la idea de cercanía a la hora de seleccionar qué servidor subordinado debe dar servició a cierto usuario no está marcada exclusivamente por la distancia física, sino que se valoran diferentes parámetros (calidad de conexión hasta el usuario, capacidad del proveedor de contenidos del cliente, precio por bit según el camino, etc.) para tomar una decisión al instante.
2) Componentes de la PDC
La arquitectura básica de la PDC se ilustra en el siguiente esquema, donde se indican los cuatro componentes principales:
Figura 15. Componentes de la PDC
Figura 15. Componentes de la PDC

  • El componente de entrega de contenido, que sencillamente es el servidor origen y un conjunto de N servidores réplica que entregan las copias del contenido a los usuarios finales.

  • El componente de distribución, que se encarga de copiar el contenido del servidor original en los servidores réplica de la PDC y asegura consistencia entre ellos.

  • El componente de encaminamiento de la petición, el cual, por una parte, dirige los usuarios que han pedido el contenido a los servidores réplica adecuados, y por la otra, informa al componente de distribución para que este tenga información actualizada de la consistencia entre los servidores réplica.

  • El componente gestor de cuentas, que audita los accesos de los clientes y el uso que realizan de los servidores de la PDC. Esta información es importante tanto para facturar los servicios a los proveedores de contenidos o a terceros como para tener informes de tráfico de datos del sistema.

La tarea fundamental de la PDC es construir su infraestructura de red propia para dar los servicios de almacenamiento y gestión de contenidos de terceros, su distribución en los servidores réplica, gestión de las copias, gestión de los contenidos estáticos (páginas HTML estáticas, imágenes, documentos, software, actualizaciones, etc.), dinámicos (servicios de directorio, servicios de e-comercio, servicios de transferencia de ficheros, etc.) y de streaming (Internet TV, IPTV, audio streaming), gestión de soluciones de backup y recuperación en caso de desastres, y monitorización del rendimiento y de incidencias.
Sus clientes, los proveedores de contenidos, contratan la PDC para aprovechar tal infraestructura y los servicios comentados, teniendo así su contenido almacenado en los servidores replicados. Estos clientes van desde grandes empresas, proveedores de servicios web, empresas de publicidad y de multimedia en general, empresas de broadcast que amplían sus servicios a Internet, etc., hasta incluso proveedores virtuales de Internet, plataformas de música en línea, operadores de telefonía móvil, fabricantes de electrónica de consumo, etc. La suma de tales clientes posibilita el mantenimiento y actualización de la vasta red propia de la PDC distribuida a lo largo de varios países, o incluso de varios continentes.
Figura 16. Servicios y contenidos frecuentes proporcionados por una PDC
Figura 16. Servicios y contenidos frecuentes proporcionados por una PDC
Los usuarios finales, ajenos a la existencia de la PDC entre ellos y el contenido del proveedor, interactúan con ella especificando el contenido que desean descargar, visualizar o escuchar de los proveedores de contenidos, ya sea desde su smartphone, tableta, móvil, portátil u ordenador.
La PDC cobra a sus clientes, los proveedores de contenido, de acuerdo con el volumen de datos entregado (tráfico) desde los servidores réplica a los usuarios finales. Como ya se ha comentado, la PDC posee mecanismos para obtener esta información casi en tiempo real para, incluso, detectar incidencias en el servicio o colapsos internos. El coste de este servicio sigue siendo elevado para pequeñas y medianas empresas, así como para organizaciones sin ánimo de lucro, aunque es obvio que irá descendiendo a lo largo de los próximos años, aunque muy lentamente debido a las siguientes razones:

  • Es habitual una tarifa básica mensual mínima de uso de ancho de banda (en Mbps) de elevado coste. Con los años, este recurso seguirá creciendo, por lo que a no ser que se cambie el mecanismo de tarificación se penalizará a los pequeños proveedores de contenido que deseen utilizar la PDC.

  • Si hay una variación de la distribución de tráfico acordada (es decir, aparecen picos de tráfico no esperados en el acceso a un contenido), el proveedor debe abonar el coste adicional que supone el uso puntual de recursos extras de la PDC.

  • Si parte de la tarificación se realiza sobre el volumen de datos (Gbytes) a almacenar (que supone un esfuerzo de la PDC en la replicación), este término tiende a crecer cuanto más se apoya el proveedor en la PDC, aunque el aumento no sea lineal.

  • Si se desea una PDC que abarque más allá de las zonas geográficas rentables (es decir, las urbes del primer mundo), el coste del aumento de la infraestructura de la PDC en esas zonas repercute en el proveedor de contenidos.

  • Si se exige a la PDC seguridad en los datos y confidencialidad de los contenidos, el coste es superior (por ejemplo, una empresa global que apoye su red interna multimedia en una PDC para distribuirla por todas sus sedes en el planeta).

3) Coste de un servicio PDC
El coste de contratación de un servicio de PDC se divide en dos conceptos:

  • por una parte, el volumen de datos a almacenar en la PDC para ser replicados. Así, un coste de 10 dólares/mes por cada Gbyte de datos almacenado sería un valor habitual.

  • por la otra, el volumen de tráfico que genera la descarga a los clientes de tales datos es un segundo concepto a añadir al anterior. Un coste de 2 o 3 dólares/mes por cada Gbyte de tráfico sería una referencia.

Sin embargo, la demanda es la que define el precio. Para clientes de cierta medida, es posible negociar precios a la baja, sobre todo en tiempos de crisis: precios de algunos centavos de dólar por Gbyte almacenado o de tráfico son posibles.
Ejemplo
Existen algunas PDC de bajo coste, como la suministrada por la empresa Value (http://www.valuecdn.com) y la empresa MediaMotion (http://www.mediamotiononline.com). Si se accede a sus webs y se comparan sus precios actuales, se verá que en ellos, usualmente, se indica el volumen de datos que puede almacenarse y el volumen de transferencia de tales datos en un mes.

2.4.El origen de las PDC

Un proveedor de contenidos tiene sentimientos contrapuestos al pensar en la Red. Por un lado, constituye un medio para hacer llegar contenido a sus usuarios finales de manera directa, pero por el otro, cualquier retraso o dificultad en ese acceso al contenido pone en un brete la imagen del proveedor.
Ya que los servicios por Internet han dado, hasta el momento, beneficios económicos a corto y medio plazo a las empresas que se han expandido por este canal y han creado numerosas oportunidades nuevas de negocio, esta sensibilidad no es baladí. Las inversiones realizadas en infraestructuras de comunicaciones que facilitan la distribución de contenidos no han hecho más que comenzar, y su papel será de tal importancia en los próximos años que, en los entornos profesionales, ya se comienza a utilizar el término “red de contenidos” en vez de “red de comunicaciones”.
2.4.1.La carrera por mejorar la calidad de servicio
Bajo el término “QoS” (calidad de servicio) se engloba una serie de parámetros empíricos que, desde el punto de vista humano, se interpretan sencillamente como “rapidez de acceso, fiabilidad de la comunicación y seguridad en las transacciones”, y que han guiado la evolución desde el servidor básico hasta la PDC.
1) Antes de las PDC
Ya en los inicios de la Red apareció la necesidad de mejorar esta calidad de servicio del usuario final; debido al alto coste que suponía aumentar la capacidad de la conexión, en aquella época era frecuente realizar mejoras en el hardware en los servidores web, como aumentar su memoria y su disco duro y actualizar el procesador, incluso apostando por equipos multiprocesador. Una vez agotada la capacidad de ampliación, se sustituía todo el servidor por uno más potente en un ciclo de vida realmente breve (como máximo, uno o dos años).
Por lo que respecta al software, se extendió el uso de proxies en los proveedores de Internet, lo cual mejoraba el acceso de los clientes de banda estrecha (módem analógico o ADSL de 256 Kbps por red telefónica, etc.) a costa de recibir alguna vez información no actualizada. La experiencia global, en general, simulaba un aumento de ancho de banda al visitar los recursos web más populares, accediendo a la caché del proxy en vez de a la web pedida. Este mecanismo de caché por proxy no solo se aplicaba (y se sigue aplicando) a escala local, sino que se extendió su uso a cachés a escala nacional e internacional para reducir el tráfico entre proveedores mejorando el tiempo de acceso, técnica que se denominó caching jerárquico.
La infraestructura de los proveedores de Internet ganó en eficiencia con las granjas de servidores, una solución que facilita la escalabilidad: un servidor principal analizaba las peticiones de un mismo sitio web que llegaban a la granja y las distribuía entre sus diferentes servidores, los cuales podían responder a un gran volumen de peticiones en paralelo. Esta infraestructura originó un gran salto cualitativo en la calidad de servicio y aún se sigue utilizando.
Figura 17. Evolución del servicio suministrado por las PDC desde su nacimiento
Figura 17. Evolución del servicio suministrado por las PDC desde su nacimiento
2) Primera generación de PDC
Aunque las granjas de servidores y el caching jerárquico son técnicas muy útiles para encauzar el problema de rendimiento, tienen limitaciones. Así, al estar cercanos geográficamente los servidores de una misma granja, son vulnerables a congestiones de la conexión que comparten en la Red. En estos casos, tener además un caching puede subsanar el problema, pero como el caching se realiza de los objetos que son pedidos por los clientes, también es sensible a la congestión de la conexión.
A finales de los años noventa, la única opción del proveedor de contenido era invertir en grandes granjas de servidores con sistemas de balance de carga y, sobre todo, múltiples conexiones de alta velocidad de alto coste para hacer frente a la demanda. La investigación en sistemas de red inteligentes y distribuidos llevó, en esa época, a los primeros experimentos de estructuras PDC documentadas.
Con la introducción de las PDC, los proveedores de contenido comenzaron a trasladar sus sitios web desde las granjas, percatándose inmediatamente de su utilidad al aportar eficiencia y escalabilidad sin la necesidad de una cara infraestructura. Akamai Technologies nació de un esfuerzo de investigación del MIT, en el año 2002, dirigido a resolver el problema de la multitud de flash (flash crowd) que hasta el atentado de las Torres Gemelas no había sido valorado en su medida, desarrollando una serie de algoritmos de enrutamiento inteligente y replicación de contenidos sobre una gran red de servidores distribuidos a lo largo del planeta. En un par de años, varias empresas se especializaron como proveedores de contenido siguiendo esta pauta, y el mercado de PDC se estableció con grandes inversiones y pingües beneficios, centrándose principalmente en la distribución de sitios web de contenido estático y dinámico.
3) Segunda y tercera generación de PDC
La segunda generación de PDC (2005-2010) enfocó sus esfuerzos en el vídeo bajo demanda, así como en el audio y vídeo streaming con capacidades de interacción del usuario. Debido al auge de los móviles con capacidad multimedia, se iniciaron experiencias en este aspecto que han comenzado a dar sus frutos actualmente (2011), llegando al mercado convencional como un servicio más.
Figura 18. El mercado PDC crece, aumentando la oferta.
Número de iniciativas PDC confirmadas a escala mundial.
Número de iniciativas PDC confirmadas a escala mundial.
Actualmente, la investigación en la que se concentra la tercera generación es el establecimiento de servicios PDC basados en comunidades; en ellas, técnicas como el peer-to-peer mediante dispositivos móviles puedan ser una base suficiente para ofrecer distribución de contenidos, de manera transparente y eficiente, a muy bajo coste.
En paralelo, el mercado de PDC es suficientemente maduro como para que reclame la estandarización de tal servicio a la hora de asegurar la compatibilidad entre proveedores PDC, reduciendo costes, y un marco regulado con el que atraer mayor inversión e investigación en su desarrollo futuro. Varias organizaciones (Internet Engineering Task Force o IETF, Broadband Services Forum o BSF, el fórum ICAP, Internet Streaming Media Alliance, etc.) han tomado la iniciativa de promover estándares para la distribución de contenido en banda ancha y streaming de contenido enriquecido (audio+vídeo+datos) por Internet.

2.5.El mercado PDC en la actualidad

El entorno de crisis económica actual ha ralentizado la implantación de nuevas plataformas de distribución y aumentado la competencia entre las existentes, algunas de las cuales han cedido ante la reducción de los márgenes comerciales.
En general, aquellas empresas con grandes clientes (Akamai, EdgeCast, Limelight), las que son spin-off de empresas existosas en otro sector (Amazon Cloudfront) y las creadas como ampliación de su servicio de redes de datos (las denominadas Telco CDN: ATT, BT, NTT, Telefónica, etc.) compiten fieramente por un mercado en aumento.
Entre las PDC relevantes en el mercado, e intentando ofrecer una lista de proveedores gratuitos y de pago, se pueden destacar:
1) Akamai
Líder mundial del mercado de plataformas de distribución, gestiona el 60% del tráfico mundial de Internet mediante su vasta red EdgePlatform, de 95.000 servidores interconectados por 1.900 redes dispersas a lo largo de 71 países. Con tal infraestructura, la lista de servicios que ofrece no tiene igual:

  • Soluciones de aceleración web

  • Análisis de sitios web

  • Soluciones de seguridad

  • Soluciones para el mercado publicitario

  • Soluciones para distribución de vídeo HD

  • Soluciones de distribución de software y juegos

  • Soluciones de servicio y asistencia (soporte, educación, salud, etc.)

No solo Akamai posee una infraestructura mayúscula, sino que sus mecanismos de gestión de información y tráfico (EdgeControl) y su software elaborado por el MIT es único en su capacidad de minimizar congestiones y vulnerabilidades en Internet.
2) Amazon Cloudfront
Hasta hace pocos años se trataba de un cliente de Akamai, y actualmente ofrece servicios de distribución de contenidos. Adobe proporciona servicio virtual de Flash Media Server por medio de la red de Amazon, todo un caso de simbiosis empresarial: http://www.adobe.com/products/flashmediaserver/amazonwebservices/
3) Windows Azure
He aquí la apuesta de Microsoft por la virtualización de los servicios de su red de servidores Windows.
4) Google Page Speed Service
Este servicio fue iniciado en julio del 2011 y, a día de hoy, es gratuito; ofrece mejoras en la velocidad de carga de páginas web de un 25% a un 60% (de contenido no HTML).
5) Telefónica
El pasado 14 de septiembre del 2011, Telefónica anunció la puesta en marcha de su plataforma de distribución de contenidos, lista para España y Argentina y que se extenderá a Chile, Perú, Brasil, Alemania y Venezuela antes de finales de año.
Artículo recomendado

Ramón Muñoz (2011, 14 de septiembre). “Telefónica crea un servicio ‘vip’ de Internet para dar mayor calidad a los proveedores de contenidos”. <http://www.elpais.com/articulo/tecnologia/Telefonica/crea/servicio/vip/Internet/dar/mayor/calidad/proveedores/contenidos/elpeputec/20110914elpeputec_4/Tes>

6) Level3 Communications
m1910_m3_29.gif
7) Limelight Network
m1910_m3_30.gif
8) Streamhoster
Pequeña empresa afincada en Los Ángeles que ofrece streaming de vídeo bajo demanda y streaming en directo en Flash Video, Windows Media Video y QuickTime, tanto para equipos de sobremesa como para dispositivos móviles (iPad, iPhone, iPod y Android). También proporciona descarga progresiva o, simplemente, descargas. En función del protocolo seleccionado de streaming, el reproductor puede ser Flash Player, Windows Media Player, Silverlight o QuickTime.
En el caso de vídeo bajo demanda, el cliente puede codificar el material sin restricciones de formato o nivel de compresión, aunque Streamhoster ofrece también este servicio por 30 dólares por cada 15 minutos de material a codificar.
Sus planes van desde los 15 dólares/mes (vídeo bajo demanda) o 30 dólares/mes (streaming en directo). Ofrece siete días de prueba gratuita para un máximo de 500 Mbytes de material.
El proceso es sencillo: tras darse de alta, se procede a la carga de los vídeos en su servidor FTP; Streamhoster nos provee de una serie de direcciones http con las que acceder al material en función del tipo de streaming que se desee, por ejemplo:
Windows Media Streaming
http://wms28.streamhoster.com/aribelles/yourfilename
QuickTime Streaming
http://dss28.streamhoster.com/aribelles/yourfilename
Progressive Download (ALL FORMATS)
http://web28.streamhoster.com/aribelles/yourfilename
Download File (ALL FORMATS)
http://wdl28.streamhoster.com/aribelles/yourfilename
Real Media Streaming
http://rss28.streamhoster.com/aribelles/yourfilename
Elíjase la dirección deseada e insértese en la página web a compartir.
9) Otros proveedores
En Internet, existen listados actualizados de proveedores de PDC. Entre ellos, Adobe presenta una lista de los que utilizan tecnología Flash:
http://www.adobe.com/products/flashmediaserver/fvss/

2.6.Futuro de las PDC

Las tendencias actuales en la investigación sobre métodos más flexibles y económicos de distribución de contenidos apuntan a dos frentes. Por una parte, a la mejora de los protocolos de comunicaciones que participan en el mecanismo de multicast y de la gestión de los routers que colaboran en la distribución. Por la otra, se profundiza en la mejora de un modelo aún más distribuido basado en el peer-to-peer streaming (P2P streaming), en donde se combina el multicast con el servicio peer-to-peer (P2P), consiguiendo que todos los participantes puedan hacer de clientes y también de servidores. A este modelo de distribución se le denomina intelligent content distribution (ICD).
2.6.1.Distribución inteligente de contenido
No hay que confundir la denostada compartición de ficheros en una red P2P con este servicio: mediante P2P streaming, el ancho de banda requerido para la distribución es inteligentemente distribuido sobre la red entera de participantes, en vez de depender de la capacidad del servidor más cercano que contenga el fichero. Se aprovecha de manera natural del efecto llamada: cuantos más usuarios requieren y acceden a ese contenido, más fuentes y recursos de red se están asignando a la transmisión de este sin añadir ningún coste adicional.
Figura 19. Distribución inteligente de contenido por P2P
Figura 19. Distribución inteligente de contenido por P2P
Así, las ICD tienen como base una estructura en rejilla (grid technology) para distribuir vídeo y audio en tiempo real o en fichero, utilizando los recursos de los clientes para redistribuir el stream a otros clientes. Mediante esta técnica, cuanto más aumenta la audiencia más crecen los recursos para distribuir el contenido. El siguiente gráfico muestra un ejemplo de un servidor ICD y un PDC:
m1910_m3_33z.gif

  • En un sistema PDC clásico, el contenido a distribuir es replicado en el servidor PDC (1) desde su servidor madre y almacenado (2). Cada cliente (3) recibe el contenido pedido por un stream único (unicast).

  • En un sistema ICD, el cliente A que demanda el contenido (4) se conecta al servidor ICD, el cual pide al servidor más cercano (5) el contenido pedido. Se crea un stream único con el cliente (6). Sin embargo, cuando un segundo cliente B pide el mismo contenido (7), lo recibe desde el cliente A y desde otros clientes que puedan tenerlo también. El software de cada cliente ha de poder gestionar la recepción desde varias fuentes de un mismo contenido para reconstruirlo correctamente.

Con todo, se plantea alguna situación híbrida en que el servidor PDC pueda ayudar al servidor ICD, como que el cliente C reciba el contenido desde otros clientes sin el ancho de banda necesario para poderlo reproducir. En ese caso, el servidor ICD puede pedir al servidor PDC que envíe un stream directo unicast del contenido directamente al cliente C(8), beneficiando así también a los clientes que dependían de C.
Las iniciativas de empresas como Internap (http://www.internap.com/cdn-services-content-delivery-network/) u Octoshape marcarán la pauta para definir el futuro de las plataformas de contenidos.