Tecnologías multimedia e interacción/Streaming
En este apartado se va a hablar sobre el streaming, centrándose en los protocolos de distribución más conocidos y utilizados.
El concepto Streaming se refiere a consumir contenido a través de la red de manera que se pueda procesar como un flujo constante y continuo, sin que sea necesario descargar el contenido para verlo.
Historia
[editar]El primer vídeo de streaming apareció en 1993. Fue un concierto en directo del grupo musical Severe Tire Damage que estaban tocando en el exterior de Xerox PARC, cuando unos ingenieros se encontraban probando su nueva tecnología para transmitir en Internet, lo que se conoce como la red virtual MBone, en una habitación cercana y decidieron transmitir al grupo para probarla.
Más tarde en 1995 la compañía Real Networks fundada por un ex-empleado de Microsoft, fue la primera en transmitir un partido de béisbol entre los New York Yankees y los Seattle Mariners. Dos años después la compañía lanzó RealPlayer, el primer sistema de reproducción de vídeo en streaming.
En 2005 surge YouTube siendo una de las plataformas que, sin duda, revolucionó el consumo de contenido audiovisual.
¿Cómo funciona?
[editar]El funcionamiento consta de 4 pasos:
- Un usuario accede a una página en Internet con contenido en streaming. Esta página se encuentra en un servidor, que sabe el archivo que tiene el contenido para realizar el streaming.
- Este servidor web le envía una solicitud a un servidor multimedia, el cual aloja físicamente los archivos de audio y vídeo.
- El servidor multimedia hace uso de un protocolo de transporte para enviar el contenido solicitado, dividiéndolo en pequeños paquetes.
- El ordenador del usuario recibe el contenido solicitado y posteriormente lo reproduce.
Protocolos
[editar]Hay distintos protocolos de streaming, siendo estos seis los más importantes.
RTP (Real Time Transport Protocol)
[editar]La primera versión fue publicada en 1996 en el RFC# 1889 . Este protocolo se ejecuta sobre UDP, pero ¿por qué UDP y no TCP? hay dos motivos principalmente, en primer lugar aunque TCP va a asegurar una comunicación duradera y fiable, es muy lento a la hora de establecer la comunicación entre cliente y servidor y por otro lado TCP detecta la pérdida de paquetes y los vuelve a retransmitir. Pero para qué se quiere un paquete que se ha perdido y que cuando llegue ya no servirá, es por ello que utiliza UDP ya que interesa más la rapidez que la pérdida de algunos paquetes.
La estructura del paquete está compuesta por la cabecera IP, la cabecera UDP, la cabecera RTP y los datos.
Dentro de la cabecera RTP se encuentran tres campos importantes:
- Tipo de carga útil (Payload Type): describe el formato de la información que lleva el paquete, permitiendo al receptor realizar correctamente la decodificación.
- Número de secuencia (Sequence number): utilizado por el emisor para numerar los paquetes enviados. Es una forma de detectar los paquetes perdidos.
- Registro de tiempo (Timestamp): utilizado para que el receptor pueda reproducir las muestras que le llegan a intervalos apropiados.
Estos dos últimos son dos mecanismos para asegurar la transmisión de voz.
Este protocolo fue reemplazado unos años más tarde por el RFC# 3550, el cual define un protocolo adicional para el envío de datos de control y datos de mediciones realizadas durante la transmisión. Se conoce como RTCP.
RTCP (RTP Control Protocol)
[editar]Complementa a RTP y se basa en la transmisión periódica a todos los participantes de una sesión, enviándoles información sobre la calidad del servicio. Transmite información como: la cuenta de paquetes, el recuento de paquetes perdidos y la variación del retardo de paquetes. Esto puede permitir a una aplicación limitar el flujo de datos o utilizar un codec diferente. Además, el intervalo RTCP mínimo recomendado por estación es de 5 segundos.
Los tipos de paquetes de este protocolo son los siguientes:
- SR (Sender Report) contiene las estadísticas de transmisión y de recepción para los participantes que son emisores activos.
- RR (Receiver Report) contiene estadísticas de recepción para los participantes que no son emisores activos pero sí receptores de una sesión.
- SDES (Source Description) se utiliza para proporcionar información adicional de la fuente: nombre, email, teléfono, etc.
- BYE se utiliza para confirmar a los receptores de que un silencio prolongado se debe a la salida de una o más fuentes.
- APP es un paquete de señalización específico a una aplicación.
Estos dos protocolos se utilizan principalmente para videoconferencia.
RTMP (Real Time Messaging Protocol)
[editar]Protocolo de mensajería en tiempo real, para el streaming de audio, vídeo y datos a través de Internet, entre un flash player y un servidor. Este protocolo es propiedad de Adobe, originalmente fue desarrollado por Macromedia que a finales de 2005 adquirió Adobe Systems, tiene más de 12 años.
RTMP se basa en TCP y la comunicación se establece entre el Adobe Flash Media Server y el reproductor Flash cliente. RTMP es versátil y puede entregar vídeo y audio en numerosos formatos.
La ventaja de RTMP es que todos los archivos de vídeo y audio se envían a un archivo SWF que se puede reproducir en un reproductor de Flash, el cual a su vez puede ser embebido en una página web o incluso en dispositivos móviles.
RTSP (Real Time Streaming Protocol)
[editar]Este protocolo utiliza RTP como protocolo de entrega de datos y ofrece un control VCR al usuario, es como un mando a distancia que tiene las opciones de play, record y pause.
Es un protocolo no orientado a conexión y mayoritariamente usa TCP para el envío de datos de control del reproductor y UDP para los datos de audio y vídeo.
Con el siguiente ejemplo vamos a ver cómo funciona:
- El cliente establece una conexión TCP a los servidores.
- El cliente entonces comienza la emisión de una serie de comandos de cabecera RTSP que tienen un formato similar al de HTTP , cada uno de los cuales es reconocido por el servidor. Dentro de estos comandos RTSP, el cliente va a describir los detalles de los requisitos de sesión, como la versión de RTSP que da soporte, el transporte que se utilizará para el flujo de datos, y cualquier información de puerto UDP o TCP. Esta información se transmite utilizando las cabeceras de DESCRIBE y de SETUP y se establece un identificador de sesión SESSION ID.
- Una vez que la negociación de parámetros de transporte se ha completado, el cliente deberá emitir un comando PLAY para indicar al servidor que inicie la entrega del flujo de datos RTP. El cual podrá pausar mediante el comando PAUSE si lo desea.
- Una vez que el cliente decide cerrar la conexión, utiliza el comando TEARDOWN junto con el SESSION ID para que cese la entrega RTP asociada a ese identificador.
HLS (HTTP Live Stream)
[editar]Es un protocolo desarrollado por Apple para dispositivos iOS y su reproductor QuickTime.
El funcionamiento es el siguiente: HLS divide el vídeo en fragmentos cortos, por lo general entre 2-10 segundos de duración, los cuales se cargan en un servidor HTTP junto con un archivo de manifiesto M3U8, es un índice que permite al cliente saber qué secuencias y segmentos están disponibles en un momento dado. Este archivo contiene a su vez otros archivos M3U8 o segmentos de video(.ts). El dispositivo selecciona automáticamente la secuencia más adecuada desde el archivo (principal) teniendo en cuenta las limitaciones de ancho de banda y de CPU, siendo una de sus características principales la Adaptabilidad.
Como dato de interés la tienda del appStore de Apple ha establecido unos requisitos que exigen la utilización de la retransmisión en directo para todo contenido de vídeo cuya duración supere los 10 minutos o 5 MB de datos en un periodo de 5 minutos (133 kbps).
Además una de las razones por las que HLS ha tenido tanto éxito es que Apple ha creado varios documentos que tratan ampliamente sobre la creación y despliegue de archivos HLS. Creando una página principal con enlaces a todos los recursos disponibles: https://developer.apple.com/streaming/
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
[editar]Es un estándar introducido por MPEG, para solucionar la dificultad de la distribución de contenido a múltiples dispositivos mediante un estándar común.
Utiliza TCP y el funcionamiento es muy parecido a HLS, también divide el archivo multimedia en pequeños fragmentos.
- Se comienza obteniendo el MPD (documento XML que representa las diferentes calidades del contenido) mediante HTTP.
- Después se parsea con el fin de conseguir la información necesaria para la reproducción.
- Tras obtener la información, selecciona las características adecuadas y empieza a realizar el streaming obteniendo los segmentos mediante peticiones HTTP.
- Durante la petición de segmentos, monitoriza los cambios en el ancho de banda de la red y decide si es necesario realizar algún cambio.
HDS (HTTP Dynamic Streaming)
[editar]Es muy parecido a HLS, pero este fue desarrollado por Adobe. Al igual que HLS funciona mediante la detección de la capacidad de ancho de banda de un cliente y ajusta la calidad del flujo de vídeo en tiempo real.
HDS utiliza archivos MP4 fragmentados y tiene la ventaja de que los archivos de metadatos, audio y vídeo se pueden almacenar por separado, pudiendo almacenar flujos de audio y vídeo en cualquier lugar, de forma independiente. Mientras que HLS en este caso multiplexa los archivos de metadatos y los archivos multimedia.
En HDS, también hay un archivo de manifiesto basado en XML que contiene la información sobre la ubicación de los archivos de vídeo y audio junto con los segmentos. Una vez que un archivo de manifiesto se descarga se puede llamar a los segmentos relevantes, dependiendo de las demandas del cliente, al igual que la calidad de vídeo, pistas de idioma y los subtítulos.
Ejemplos servicios que utilizan streaming
[editar]A continuación, brevemente vamos a ver los protocolos que utilizan algunos servicios que nos permiten disfrutar de todo este contenido en streaming, junto con el impacto que tienen actualmente como son: netflix y YouTube.
Netflix
[editar]La empresa fue fundada en el año 1997 y tiene su sede en Los Gatos, California.
El protocolo que hay debajo de Netflix es MPEG DASH y funciona con un reproductor basado en Microsoft Silverlight para evitar que el contenido audiovisual sea descargado, aunque también cuenta con la opción de usar un reproductor creado con HTML5. Bajo Linux se puede ver Netflix usando el navegador Google Chrome, versión 38 o más reciente.13
Netflix rozó a final de marzo los 100 millones de abonados al sumar cinco millones de nuevos suscriptores en todo el mundo durante el primer trimestre del 2017.
YouTube
[editar]Es una empresa fundada por tres ex-empleados de PayPal en 2005. Todo empezó con una fiesta, donde dos de sus fundadores hicieron un video pero vieron que era demasiado largo para enviarlo por correo electrónico a sus amigos, y fue de esta frustración de donde les surgió la idea de hacer una plataforma que permitiese a cualquiera visualizar o enviar un vídeo.
YouTube utiliza el protocolo de streaming adaptativo (DASH). De hecho lo podemos ver si pulsamos en un video de YouTube y pulsamos el botón derecho dándole a estadísticas para nerd.
Cuenta a día de hoy con más de mil millones de usuarios, es decir, un tercio de los usuarios de Internet, y cada día se ven cientos de millones de horas de vídeos y se generan miles de millones de reproducciones, de las cuales más de la mitad proceden de dispositivos móviles.
Conclusiones
[editar]Como hemos visto hay muchos tipos de protocolos de streaming que podemos utilizar cada uno con sus respectivas características. MPEG-DASH al estar basado en HTTP, y por decirlo de alguna forma unificar al resto de protocolos siendo un estándar, está adquiriendo mucha fuerza y varias de las principales empresas tecnológicas lo están apoyando con el fin de conseguir tener un estándar único y universal. De hecho muchas de estas compañías que ofrecen servicio en streaming lo están utilizando. Aunque el futuro es muy incierto y habrá que ver que nuevos protocolos surgen, mejorando la latencia y la compatibilidad.