Integración de Sistemas Multimedia y de Comunicaciones de Red UT2 PDF

INTEGRACIÓN DE SISTEMAS MULTIMEDIA Y DE COMUNICACIONES DE RED STI SISTEMAS INTEGRADOS Y HOGAR DIGITAL 1 DEFINICIÓN DE STREAMING El streaming es la distribución de multimedia a través de una red de computadoras de manera que el usuario consume el producto,...

INTEGRACIÓN DE SISTEMAS MULTIMEDIA Y DE COMUNICACIONES DE RED STI SISTEMAS INTEGRADOS Y HOGAR DIGITAL 1 DEFINICIÓN DE STREAMING El streaming es la distribución de multimedia a través de una red de computadoras de manera que el usuario consume el producto, generalmente archivo de video o audio, en paralelo mientras se descarga. La palabra streaming se refiere a: una corriente continua (que fluye sin interrupción). (definición de Wikipedia) Streaming es una transmisión mediante un flujo de datos que normalmente se refiere a video y/o audio, la característica que tiene conceptualmente es que permita comenzar su procesamiento antes de ser terminado. El streaming se realiza a través de una red de datos, bien sea una red privada, pública o internet. (Definición de Telefónica) RECEPCIÓN DE INFORMACIÓN MULTIMEDIA  Descarga tradicional: transferencia clásica, que realiza una descarga completa en local del fichero a reproducir.  Descarga progresiva (pseudo-streaming): Sin terminar de descargar un fichero de video permite comenzar la reproducción. Se requiere utilizar en local un búfer de datos que va almacenando el material descargado.  Streaming: El cliente reproduce la información según le llega segmentada a través de la red y luego la descarta (servicios de calidad) CARACTERÍSTICAS  Tecnología de transmisión a través de redes de medios continuos (principalmente audio y vídeo).  No existe descarga de información a un disco local  Se envía la información a través de la red y el cliente la reproduce en tiempo real al recibirla Audio Video RED SERVIDOR CLIENTE  CARACTERÍSTICAS El cliente acumula parte del vídeo en buffer antes de comenzar Permite absorber variaciones en el retardo en la red (jitter) Si el buffer se vacía el reproductor se detiene PAQUETIZACIÓN  Objetos de medios de A/V divididos en segmentos  Envío en paquetes de red con varios segmentos  Recepción de segmentos y reproducción  No hay equivalencia entre cuadros de vídeo, paquetes y segmentos STREAMING FRENTE A DESCARGA 2  TIPOS DE STREAMING En directo (Video on-Live) VOL. Similar a un canal de televisión  Bajo demanda (Video on-Demand) VOD. Similar a un reproductor de vídeo MODOS DE DIFUSIÓN  UniCast  MultiCast  BroadCast  SimulCast  STREAMING EN DIRECTO (ON-LIVE)  Está orientado a la multidifusión.  El servidor comienza a transmitir en un instante dado.  Los usuarios ven la información que se está emitiendo.  En este tipo de servicio no existe interactividad.  Únicamente está permitido realizar pausas, cuando el usuario recupere la reproducción podrá ver la información que se está transmitiendo en ese instante.  STREAMING BAJO DEMANDA (ON-DEMAND)  Los usuarios solicitan el envío de información en cualquier instante  Envío de un flujo a cada usuario  Existen diversos tipos de interacciones  Pausas  Saltos hacia delante  Saltos hacia atrás  DIFUSIÓN UNICAST  El video sobre IP se transmite desde un punto, como un servidor web, a un único punto final, cliente.  Cada cliente inicia su propio stream, de forma que se inician muchas conexiones uno-a-uno (entre el servidor y el cliente).  Esta técnica causa que el servidor requiera de un ancho de banda mucho mayor que los clientes y aumenta el tráfico en la red.  DIFUSIÓN MULTICAST  Un único stream se comparte entre diferentes clientes, de forma que el servidor envía la información una única vez, y ésta llega a todos los clientes que han demandado el servicio.  La transmisión es de “una fuente a muchos destinos”, solo los destinos que apuntan a la fuente específica pueden recibir el flujo de tráfico.  En una red IP, los clientes no se comunican directamente con los servidores. Los routers replican los paquetes recibidos en una interfaz de entrada y envían las réplicas a varias interfaces de salida.  Esta técnica es ideal para la difusión de medios en vivo (por ejemplo, radio en Internet) ya que los clientes están dispuestos a recibir el mismo flujo de datos.  DIFUSIÓN BROADCAST  Broadcast significa difusión, el tráfico fluye desde un único punto a todos los puntos finales posibles dentro del alcance de la red. Ésta es la técnica más sencilla para garantizar que el tráfico llegue a sus destinos.  Se utiliza ampliamente en las redes de televisión para la distribución de vídeo y audio.  La transmisión no es factible en Internet debido a la enorme cantidad de datos innecesarios que llegarían continuamente al dispositivo de cada usuario, las complicaciones y el impacto de la codificación y los problemas de privacidad relacionados.  DIFUSIÓN SIMULCAST  La transmisión simultánea o simulcast (simultaneous broadcast) se refiere a una emisión de la misma información a través de más de un medio o de más de un servicio en el mismo medio.  Esto permite llegar a una audiencia más amplia, sin importar qué plataforma o servicio se utilice. Habitualmente se trata de transmisiones de radio o televisión.  Envío de un mismo evento a múltiples plataformas: radio, televisión terrestre, televisión satelital e internet. Otro caso de uso, la emisión en TDT de varios canales de audio, en versión original y doblada al idioma local. Esto es simulcast de audios por un mismo medio. 3 ARQUITECTURA Los sistemas de Streaming están compuestos por 3 tres componentes básicos:  El servidor.  La red. Proxy  Clientes  ARQUITECTURA. VIDEO DIGITAL Dibujar una imagen detrás de otra da sensación de movimiento Del orden de al menos 25 imágenes por segundo Cada fotograma (frame) es una imagen digital a transmitir Su calidad depende de o Resolución (pixels) o Colores (cuántos bits para representar el color, RGB o luminancia/crominancia) Ejemplo: o Vídeo analógico en PAL o 625 líneas (576 visibles) aspecto 4:3 25 fps o Usamos 768x576 pixels, en cada pixel representamos 16 millones de colores con 8:8:8 bits para RGB o Serían 1300 KB cada frame o sea 265Mbps para enviar un solo canal de TV Es muy importante usar técnicas de compresión en los formatos de vídeo digital ARQUITECTURA. FORMATOS Audio CD: 1.411 Mbps (sin procesar ni comprimir archivos.wav) MPEG-1 Part 3 Layer 3 (MP3): 96, 128, 160 kbps Internet telephony: 5.3-13 kbps Video (+audio): MPEG 1 – Entornos libres de errores (CD-ROM, VCD) – 1.2 Mbps el vídeo, 256 Kbps el audio – Busca la mejor calidad dado un bitrate – Permite acceso aleatorio a un frame – Basado en H.261, imagen en macrobloques y DCT de los bloques MPEG 2 – Broadcast TV, DVD – 2-15 Mbps (vídeo+audio) – Basado en DCT pero con compresion basada en correlacion temporal – MPEG-2 part 7 advanced audio codec AAC – Define encapsulado (transport stream TS) para enviar el vídeo sobre la red  ARQUITECTURA. NORMATIVA ITU-T H.261 “Video codec for audiovisual services at px64 kbits” – CIF (352x288), QCIF (176x144) (resoluciones de luminancia) – El resultado es un bit stream – Videoconferencia sobre ISDN ITU-T H.263 “Video coding for low bit rate communication” – Basado en H.261 – sub-QCIF (128x96) , QCIF, CIF, 4CIF (704x576) and 16CIF (1408x1152) – Videconferencia sobre POTS – Basado en H.261, MPEG-1 y MPEG-2 ARQUITECTURA. NECESIDADES BW (ancho de banda) Retardo (velocidad de interacción) Jitter (frecuencia de cortes o tamaño del buffer) Pérdidas (frecuencia de cortes) Situación actual – Vídeo sobre internet. Sobredimensionar BW y esperar que los otros tres no sean demasiado elevados, sin garantías – Vídeo en entornos controlados por un operador IPTV VoD Mezclas, batching ARQUITECTURA. DIFUSIÓN DE TV Multicast Escalabilidad para un alto número de canales y un número ilimitado de usuarios Uso óptimo del ancho de banda Replicación multicast Distribución TV Red de transporte Red de acceso Red de acceso Red de acceso Nodo de acceso  ARQUITECTURA. VOD CENTRALIZADO VoD equivale a Unicast 1M usuarios → 200K/día @ 2Mb/s & 20% concurrencia = 80Gb/s Arquitectura centralizada: proporciona escalabilidad limitada Red de transporte Red de acceso Red de acceso Red de acceso Nodo de acceso  ARQUITECTURA. VOD DISTRIBUIDO Arquitectura distribuida de VoD 20k usuarios @ 2Mb/s & 20% concurrencia = 8Gb/s Arquitectura distribuida proporciona escalabilidad También es posible una arquitectura mixta(centralizada/distribuida) Video server Servidor Red de transporte Red de VoD acceso Red de Servidor acceso VoD Red de acceso Nodo de acceso  TIPOLOGÍA DE ARQUITECTURA  Con servidor y cliente. Arquitectura típica  Sin servidor (server-less). No hay servidor de a/v. Se sirve mediante un servidor web.  Sin cliente (client-less). No hay programa cliente. Se utiliza para visualizar un applet Java o un plugin (p.e. Flash).  EL SERVIDOR  Almacena los contenidos que pueden ser solicitados por los usuarios.  Encargado de gestionar el servicio a los clientes, garantizando una cierta calidad de servicio a lo largo del camino que tiene que seguir la información desde el disco hasta los usuarios.  El servidor almacena y transmite copias del vídeo codificadas a diferentes velocidades  Está compuesto por tres subsistemas: producción y almacenamiento, control y comunicación. 1.5 Mbps encoding 28.8 Kbps encoding  PRODUCCIÓN Y ALMACENAMIENTO  Genera los flujos de audio/vídeo que se van a transmitir  Tipos de producción:  Para almacenar  Para emitir en directo  Hardware:  Elementos de adquisición: cámaras, micrófonos, capturadoras.  Software:  De edición  De producción para transmisión mediante streaming.  CODECS  Códec: Codificador-Decodificador.  Desarrollados en software, hardware o una combinación.  Pueden codificar un flujo de datos (stream) o una señal y posteriormente recuperarlo.  Los códecs son usados a menudo en videoconferencias y emisiones de medios de comunicación.  Suelen provocar pérdidas de información para conseguir un tamaño reducido del archivo destino (lossy). Hay también códecs sin pérdidas (lossless).  CONTENEDORES  Los archivos multimedia contienen audio y vídeo, y datos de sincronización. Estos flujos puede ser manejado con programas, procesos, o hardware diferentes; pero para que sean útiles para almacenarlos o transmitirlos, deben ser encapsulados juntos. Esta función es realizada por un formato de archivo de vídeo (contenedor), como.mpg,.avi,.mov,.mp4,.rm,.ogg,.mkv o.tta.  Algunos de estos formatos están limitados a contener streams que se reducen a un pequeño juego de códecs, mientras que otros se usan para objetivos más generales. CODECS DE AUDIO CODECS DE VIDEO  FORMATOS PRINCIPALES  RealNetworks: RM (Real Media), RV (Real Video), RA (Real Audio)  Microsoft: WMV (Windows Media Video), ASF (Advanced Streaming Format)  Apple: MOV (MOVie), QT (QuickTime)  Adobe: SWF (ShockWaveFlash), FLV (FLashVideo)  Estándares: MPG, MP4  COMUNICACIONES  Canal para el control de los flujos multimedia  Canal bidireccional:  Recibe las interacciones del cliente y transmite las respuestas·  Canales para el envío de los datos multimedia  Unidireccionales  Transmiten la información cuando las interacciones lo requieren  COMUNICACIONES. INTERACCIONES  Recibe las interacciones del cliente (play, stop, pause, etc.) y actúa sobre el flujo de información multimedia.  TRANSMISIÓN DE STREAM  Fracciona la información y la envía de forma temporizada MULTIPLEXACIÓN  En esta etapa se conforman cada uno de los canales con los datos a transmitir: Video, Audio y datos del programa.  El multiplexor recibe varias entradas y genera una sola trama de salida SPTS (Single Program Transport Stream)  Posteriormente otros multiplexores reciben como entradas los SPTS de cada programa y proporcionan una sola trama de salida MPTS (Multiple program Transport Stream) multiplexando todos los programas.  Las tramas MPTS son las que se transmiten al usuario. ADAPTACIÓN A LAS CONDICIONES DE LA RED  Se modifica la calidad del vídeo en tiempo real en función de las condiciones de la red PROXY  Funcionalidades según el tipo de servicio:  A/V bajo demanda: almacena temporalmente la información más recientemente utilizada y la transmite a los clientes en caso de ser nuevamente solicitada  A/V en directo: reduce el número de flujos que salen del servidor CLIENTE DE STREAMING  Componentes:  Recepción: recibe la información solicitada por el usuario  Presentación: reproduce la información recibida de forma temporizada  Interface: proporciona un interfaz para que el usuario interaccione  Buffer: se utiliza para controlar la calidad del servicio 4 PROTOCOLOS ¿Qué es un protocolo de streaming? 3 El protocolo de streaming es el conjunto de reglas y capas que permiten hacer una transmisión de video y audio desde un punto de difusión a un punto de recepción, siempre a través de una cada de red de datos, publica como internet o privada. Existen varios protocolos para poder hacer llegar el vídeo y audio a los clientes de un servidor. ICMP (capa 3 o capa de Red) RTP y RTCP (capa 4 o capa de Transporte) RTSP (capa 7 o capa de Aplicación) TIPOS DE PROTOCOLOS  Sistemas sin control: HTTP, no hay control sobre la transmisión  Sistemas con control sobre la transmisión  Control (nivel de aplicación)  Estándar: RTSP (Real Time Streaming Protocol)  Otros: MMS de Microsoft o RTMP y RTMFP de Adobe  Transporte de datos (nivel de transporte)  Estándar RTP (Real-Time Transport Protocol)  RTCP (Real-Time Control Protocol)  UDP (User Datagram Protocol) PROTOCOLOS CAPA DE RED: ICMP ICMP se utiliza para intercambiar información acerca del estado de pertenencia entre routers multicast conectados a redes locales y miembros de grupos multicast. Los hosts miembros individuales informan acerca de la pertenencia del hosts al grupo multicast y los routers multicast sondean periódicamente el estado de la pertenencia. PROTOCOLOS CAPA DE TRANSPORTE  TCP (Transmission Control Protocol) Se trata de una arquitectura de comunicación para el intercambio de mensajes entre dispositivos informáticos en una red. Es el protocolo más común en redes que utilizan el Protocolo IP de internet; se denomina comúnmente TCP/IP. Garantiza la entrega e integridad de los datos de un extremo a otro. TCP requiere una conversación entre servidor y cliente, de forma que establece una comunicación bidireccional de envío y recepción con acuse de recibo. Es un protocolo más lento, pero también más seguro que otros, se utiliza para transmisión unicast. Muy utilizado para la transferencia de ficheros de video, acceso a páginas web o el envío y recepción de correos electrónicos. PROTOCOLOS CAPA DE TRANSPORTE  UDP (User Datagram Protocol) El Protocolo de datagramas de usuario, es un protocolo de comunicación utilizado en Internet para envíos de información especialmente sensibles al tiempo. Es más rápido que otros ya que no establece formalmente una conexión previa, antes de que se transfieran los datos. Esta ventaja de velocidad es una fragilidad del protocolo frente a pérdida de paquetes. Es una alternativa al protocolo de control de transmisión (TCP). En una red que utiliza el Protocolo de Internet (IP), a veces se denomina UDP / IP. Es un protocolo ágil y rápido pero inseguro respecto a la garantía de entrega de todos los paquetes así como su vulnerabilidad frente a posibles ataques. Puede utilizarse en una transmisión unicast, multicast o broadcast. Principalmente utilizado para la transmisión de vídeo en directo, audio IP juegos online, videoconferencia Ip o voz sobre ip. PROTOCOLOS CAPA DE TRANSPORTE  RTP (REAL TIME PROTOCOL) RTP es un protocolo de Internet para la transmisión en tiempo real de datos multimedia en modo unicast o multicast. Trabaja sobre protocolo UDP, tiene una serie de características especiales de tiempo real, como código de tiempo sobre el vídeo y número de secuencias. No incluye recuperación de pérdida de paquetes, no garantizar el envío, ni garantizar que los paquetes lleguen ordenados, tampoco que los paquetes lleguen a tiempo ni la calidad de servicio. Requiere el uso de un buffer que se carga antes de comenzar la reproducción para asegurar la calidad del servicio. Implica la transmisión periódica de paquetes de control a todos los participantes en una sesión.  RTCP (REAL TIME CONTROL PROTOCOL) RTCP se usa para monitorear las estadísticas de transmisión y proporcionar retroalimentación de calidad de servicio (QoS). RTCP ayuda a la sincronización de múltiples flujos de media del RTP. PROTOCOLOS CAPA DE APLICACIÓN  HTTP (HYPERTEXT TRANSFER PROTOCOL El Protocolo de transferencia de hipertexto basado en TCP/IP , permite transferencias de información, se realiza una petición de datos entre cliente que inicia la conversación y un servidor, no existe control sobre la transmisión dado que no guarda ningún dato entre dos peticiones en la misma sesión. Cuando TCP y HTTP sufren un error de transmisión, se vuelve a intentar la entrega de los paquetes perdidos hasta conseguir una confirmación de que la información llegó en su totalidad.  E protocolo HTTP normalmente usa el puerto 80 o 8080. PROTOCOLOS CAPA DE APLICACIÓN  RTSP (REAL TIME STREAMING PROTOCOL)  Desarrollado por la IETF y publicado en 1998 como RFC 2326, es un protocolo para el uso en sistemas de streaming de medios que permite a un cliente para controlar remotamente un servidor de streaming de medios de comunicación, la emisión de comandos VCR-como por ejemplo " obra "y" pausa ", y permitir el acceso basado en el tiempo a los archivos en un servidor.  Protocolo de transmisión en tiempo real con baja latencia, utiliza TCP (RTSPT) o UDP (RTSPU) como protocolo de transporte y permite la recepción desde servidores, el cliente establece y controla uno o varios flujos sincronizados de audio y vídeo, está específicamente diseñado para ser usado en transmisiones de vídeo. El puerto por defecto para RTSP es de 554  Permite controlar los servidores para streaming, establece una sesión de control entre el cliente y el emisor y actúa como un control remoto de los servidores multimedia. Se utiliza para el control de las funciones de Play, Pause, REW… de un sistema de video bajo demanda (VOD). RTSP es similar en algunos aspectos al protocolo HTTP Live Streaming (HLS).  Los servidores RTSP a menudo funcionan junto con el Protocolo de transporte en tiempo real (RTP) y el Protocolo de control en tiempo real (RTCP) para entregar flujos de medios. Es una excelente opción para sistemas de vigilancia, dispositivos IoT y SDK móviles. RTSP fue utilizado principalmente por RealNetworks RealPlayer. RTSP requiere un servidor dedicado para la transmisión y no admite el cifrado de contenido o la retransmisión de paquetes perdidos, ya que se basa en el protocolo RTP junto con RTCP para la entrega de transmisión de medios. PROTOCOLOS CAPA DE APLICACIÓN  HLS (HTTP LIVE STREAMING) Es un protocolo robusto y eficaz, utilizado en la transmisión en vivo. Está basado en HTTP y desarrollado por Apple. Es un protocolo muy extendido y compatible. Su principal característica, la tasa de bits adaptativa, permite que la calidad se adapte al ancho de banda del Player. Se usa tanto para transmisión bajo demanda (VOD) como para transmisión en vivo. La codificación del video se realiza por segmentos (chunks de video). Tras el envío mínimo inicial se puede reproducir el vídeo. Para ello existe un archivo índice que referencia cada segmento y permite al player ubicar y reproducir cada fragmento recibido. El contenido permite la encriptación para proteger el contenido y sus derechos de autor. Además permite atravesar un firewall de protección o un servidor proxy. El HLS permite la transmisión mediante protocolo seguro HTTPS. HLS es el protocolo de transmisión más utilizado. Es perfecto para transmitir video en vivo a bases de espectadores masivos. La única desventaja notable del protocolo HLS es la elevada latencia cuando se transmite en vivo.  LL- HLS (LOW-LATENCY) HLS de baja latencia (LL-HLS) es un avance del HLS. Ofrece latencias inferiores a 2 segundos o menos y es compatible con versiones anteriores. Está en fase de despliegue e implementación entre los distintos fabricantes de dispositivos. PROTOCOLOS CAPA DE APLICACIÓN  PROTOCOLOS DE CÓDIGO ABIERTO  MPEG-DASH (MOVING PICTURE EXPERT GROUP DYNAMIC ADAPTIVE STREAMING OVER HTTP) MPEG desarrolla un protocolo de código abierto Dynamic Adaptive Streaming sobre HTTP (DASH) como alternativa a HLS de Apple. Es uno de los protocolos de tasa de bits adaptativa de transmisión más modernos y se considera uno de los mejores en la industria. Es independiente del códec, es compatible con API basadas en estándares para la gestión de derechos digitales (DRM). La gran desventaja es que no es compatible con Safari e iOS. Latencia: 6-30 segundos  SRT (SECURE RELIABLE TRANSPORT) Está orientado al transporte de señal de vídeo y audio con ultra baja latencia bajo UDP. Es un protocolo de transporte puro, independiente del códec, garantiza que lo enviado y recibido en el decodificador es idéntico y sin pérdida. Ofrece seguridad de la transmisión a nivel de enlace bajo encriptación. Permite atravesar el firewall en todo el flujo de trabajo al admitir los modos de envío y recepción. Posee la capacidad de detectar el rendimiento de la red con respecto a la latencia, la pérdida de paquetes, la fluctuación y el ancho de banda disponible.  MPEG-TS (MOVING PICTURES EXPERT GROUP (MPEG) TRANSPORT STREAM) El flujo de transporte MPEG (MPEG-TS, MTS) o simplemente de transport Stream (TS) es un formato contenedor de vídeo, estándar MPEG utilizado para la transmisión y almacenamiento de audio, video y datos de información del sistema y del programa (PSIP). Se utiliza en sistemas de transmisión como DVB, ATSC e IPTV. TS es rápido porque comienza de inmediato la transmisión de flujo de vídeo, normalmente MPEG-2. PROTOCOLOS CAPA DE APLICACIÓN  PROTOCOLOS DE CÓDIGO ABIERTO  RSP (RESILIENT STREAMING PROTOCOL) El protocolo de transmisión resiliente, es la primera tecnología de transmisión en vivo que protege completamente la pérdida de calidad de audio y video durante una transmisión, independientemente de las interrupciones de la red. RSP garantiza la entrega de video y audio completos sin errores, además permite atravesar el firewall de una conexión HTTP. Tiene latencia baja y predefinida para garantizar no almacenar nada en el búfer o tener pérdida de paquetes por inestabilidad de la red en el sitio de transmisión.  RIST (RELIABLE INTERNET STREAM PROTOCOL) RIST, que significa protocolo de flujo de Internet confiable, es un protocolo de baja latencia y alta disponibilidad adecuado para aplicaciones de larga distancia. Es un protocolo de transporte de código abierto y especificación abierta diseñado para la transmisión confiable de video a través de redes con pérdidas (incluido Internet) con baja latencia y alta calidad. Actualmente se encuentra en desarrollo en el marco del “Grupo de actividades RIST” del Foro de servicios de vídeo.  WebRTC (WEB REAL-TIME COMMUNICATIONS) Protocolo con API de JavaScript para compartir videos entre navegadores. Ofrece transmisión de voz y video casi con muy baja latencia, casi instantánea desde y hacia cualquier navegador. Su diseño está basado en aplicaciones de chat que se está utilizando en otros ámbitos más de vídeo y audio.El mayor hándicap es su escalabilidad (Latencia: entrega de menos de 500 milisegundos) PROTOCOLOS CAPA DE APLICACIÓN  PROTOCOLOS PROPIETARIOS  RTMP (REAL-TIME MESSAGING PROTOCOL) El protocolo de mensajería en tiempo real fue desarrollado por Macromedia (propiedad de Adobe), para la transmisión en tiempo real de video, audio y datos entre un servidor y un reproductor Flash. Basado en TCP, RTMP (su latencia puede ser muy elevada) es una tecnología de transmisión continua y existe una comunicación entre el cliente y el servidor. Aunque fue uno de los pioneros, actualmente es un protocolo en desuso.  FLV Flash Video es un formato de Adobe utilizado mucho en el pasado. FLV corría sobre HTTP realizando un pseudo streaming. Es rápido en su carga. Se ha dejado de usar paulatinamente.  HDS (HTTP DYNAMIC STREAMING) HTTP Dynamic Streaming es la evolución de RTMP por parte de Adobe. Es un protocolo de transmisión basado en flash que está en proceso de desuso. Permite la transmisión adaptativa y posee una alta calidad. HDS posee baja latencia, si bien es mayor que el RTMP debido al proceso de fragmentación y encriptación. Códecs de video: H.264, VP6. Códecs de audio: AAC, MP3. Latencia: 6-30 segundos PROTOCOLOS CAPA DE APLICACIÓN  PROTOCOLOS PROPIETARIOS  MSS (MICROSOFT SMOOTH STREAMING) MSS es el protocolo de transmisión de video con tasa de bits adaptable de Microsoft, diseñado con medidas de seguridad adicionales, DRM, para proteger el contenido de la piratería. Es un método de entrega de medios híbridos que funciona como transmisión, pero se basa en la descarga progresiva HTTP. Permite la entrega adaptable a todos los dispositivos de Microsoft. El protocolo no puede competir con otros formatos basados en HTTP. Códecs de video: H.264, VC-1 Códecs de audio: AAC, MP3, WMA Latencia: 6-30s  CMAF (COMMON MEDIA APPLICATION FORMAT) Apple y Microsoft propusieron un nuevo estándar llamado Common Media Application Format (CMAF). Se trata de un novedoso protocolo, que posee flujos de trabajo optimizados y latencia reducida. Este protocolo es un contenedor de ficheros. CMAF en sí mismo es un formato multimedia. Un flujo optimizado es dividir el video en trozos pequeños de una duración determinada, que luego se pueden publicar inmediatamente después de la codificación. De esa manera, la entrega es casi en tiempo real, mientras los fragmentos posteriores aún se están procesando.  CMAF (COMMON MEDIA APPLICATION FORMAT) LOW LATENCY Es una tecnología emergente para acelerar la entrega de video basada en HTTP. Ofrece videos ultrarrápidos a escala mediante el uso de segmentos de datos más cortos. Puede utilizarse con cualquier reproductor. Si no está optimizado para CMAF de baja latencia para DASH puede recurrir al comportamiento DASH estándar (latencia más alta). Latencia: 3 segundos o menos PROTOCOLOS CAPA DE APLICACIÓN  PROTOCOLOS PROPIETARIOS  RTMP (REAL-TIME MESSAGING PROTOCOL) El protocolo de mensajería en tiempo real fue desarrollado por Macromedia (propiedad de Adobe), para la transmisión en tiempo real de video, audio y datos entre un servidor y un reproductor Flash. Basado en TCP, RTMP (su latencia puede ser muy elevada) es una tecnología de transmisión continua y existe una comunicación entre el cliente y el servidor. Aunque fue uno de los pioneros, actualmente es un protocolo en desuso.  ZIXI ( ) Posee como característica que es un sistema de transmisión muy seguro ya que utiliza encriptación AES. Zixi encapsula los contenidos con tecnología propietaria basada en FEC y ARQ. Está basado en UDP, se ajusta dinámicamente a las diferentes condiciones de la red y emplea técnicas propias de corrección de errores para la entrega de video en directo sin errores y con latencia ultrabaja (menos de 300 ms).  SHOUTCAST ( ) Se trata de un sistema de audio para radio propietario basado en HTTP, SHOUTcast DNAS es un software multiplataforma para la transmisión de medios a través de Internet. El audio digital, normalmente MP3 o codificación de audio avanzada de alta eficiencia, se transmita hacia y desde el software del reproductor multimedia, lo que permite la creación de “estaciones” de radio por Internet. El uso más común de SHOUTcast es para crear o escuchar transmisiones de audio por Internet; sin embargo, también hay transmisiones de video. Su mayor limitación es la compatibilidad, especialmente en dispositivos móviles. PROTOCOLOS CAPA DE APLICACIÓN  PERO, ¿EN PRODUCCIÓN SE UTILIZAN ESTOS PROTOCOLOS O HAY OTROS ESPECÍFICOS? Para los sistemas de producción audiovisual el protocolo normalmente no es el mismo de transmisión, ya que la calidad, profundidad de bits, inmediatez y latencia es distinta. En las fases de producción, tanto si es para una grabación como para una emisión en directo las necesidades son tener la mayor calidad de imagen y sonido posibles. Y aquí es donde llega la revolución del Video IP Con protocolos como NDI, SMPTE 2110 o SMPTE 2022  ¿Y QUIÉN SE ESTÁ IMPONIENDO ENTRE TANTO PROTOCOLO DE TRANSMISIÓN? En proporciones de uso generalizado HLS está en torno al 45% frente a un 33% del RTMP, MPEG DASH escala posiciones con un 7%, el resto aún está muy lejos de las posiciones del top 2. Podemos decir que el HLS es el más recomendable dado que soporta HTML5 frente al RTMP que requiere flash ya obsoleto, HLS es más seguro para el uso masivo de espectadores. RTMP y SRT son las grandes apuestas para la contribución de la primera milla, mientras que tanto DASH como HLS lideran el camino cuando se trata de reproducción. En el mundo broadcast, los protocolos Zixi, SRT y RIST son los más empleados, en función del uso y el equipamiento utilizado. Estos tres protocolos son los más profesionales en el mundo audiovisual Broadcast. SISTEMAS DE CONTROL EN LA TRANSMISIÓN  Dos canales de comunicación entre los clientes y el servidor de streaming:  Un canal para el control de la sesión (RTSP)  Un canal para la transmisión de la información (RTP/UDP/RTCP) PROTOCOLO RTSP (REAL TIME STREAMING PROTOCOL)  Establece y controla la sesión de streaming. Actúa como un mando a distancia de la sesión (play, pause, rew, etc.).  Se emplea en conjunto con SDP (Session Description Protocol), que proporciona información sobre la sesión: número de flujos, tipo de contenido, duración, ancho de banda, etc. PROTOCOLO RTSP (REAL TIME STREAMING PROTOCOL)  Protocolo de nivel de aplicación.  Independiente de la capa de transporte (TCP o UDP).  No es el encargado de transportar los contenidos.  Un servidor RTSP necesita mantener el estado de la conexión.  Compatible tanto con unicast como con multicast.  Capacidad multi-servidor: Cada flujo multimedia dentro de una presentación puede residir en servidores diferentes. PROTOCOLO RTSP (REAL TIME STREAMING PROTOCOL)  Similitudes con HTTP:  Formato de las peticiones/respuestas  Formato de las URL  Sintaxis  Negociación de los contenidos  Diferencias importantes con HTTP:  RTSP es un protocolo con estado a diferencia de HTTP  Tanto servidores como clientes RTSP pueden realizar peticiones  Los datos son transportados mediante un protocolo diferente  Cada flujo transportado puede residir en un servidor distinto PROTOCOLO RTP (REAL TIME PROTOCOL)  En video-streaming (y la mayoría de las aplicaciones) se emplea RTP sobre UDP, al ser menos pesado que TCP. ¿Por qué UDP?:  Necesidad propia del video-streaming de recibir la información en el momento adecuado (entrega rápida por encima de la fiabilidad en el transporte).  RTP no ofrece garantías sobre la calidad del servicio ni sobre el retraso de la entrega de datos, estos deben ser proporcionados por la red subyacente.  RTP ofrece entrega de datos multicast.  Secuenciación. Debido a la necesidad de entregar los paquetes en orden (UDP no provee esta característica) RTP incorpora un número de secuencia que – además – sirve para la detección de paquetes perdidos. PROTOCOLO RTP (REAL TIME CONTROL PROTOCOL) Por tanto, RTSP y RTP poseen cometidos diferentes. Mientras que RTPS está encargado del establecimiento y control de la conexión, RTP se emplea para transportar los contenidos en tiempo real (A/V) PROTOCOLO RTCP (REAL TIME CONTROL PROTOCOL) ¿Es suficiente con ambos protocolos (además de SDP) para garantizar una sesión de video-streaming?, o ¿ hay añadir alguna otra función?  La respuesta a estas preguntas es el empleo conjunto de RTP con RTCP (protocolo de control del transporte en tiempo real).  RTCP proporciona información de control asociada con un flujo de datos para una aplicación multimedia (flujo RTP).  Características principales de RTCP.  Trabaja junto con RTP en el transporte y empaquetado de datos A/V  No transporta ningún dato por sí mismo.  Se encapsula sobre UDP.  Se emplea para monitorizar la calidad de servicio. PROTOCOLO RTCP (REAL TIME CONTROL PROTOCOL) ¿Es suficiente con ambos protocolos (además de SDP) para garantizar una sesión de video-streaming?, o ¿ hay añadir alguna otra función?  La respuesta a estas preguntas es el empleo conjunto de RTP con RTCP (protocolo de control del transporte en tiempo real).  RTCP proporciona información de control asociada con un flujo de datos para una aplicación multimedia (flujo RTP).  Características principales de RTCP.  Trabaja junto con RTP en el transporte y empaquetado de datos A/V  No transporta ningún dato por sí mismo.  Se encapsula sobre UDP.  Se emplea para monitorizar la calidad de servicio. SESIÓN DE VIDEO-STREAMING SESIÓN DE VIDEO-STREAMING 5 TECNOLOGÍAS STREAMING Tecnologías clásicas Tecnologías Emergentes TECNOLOGÍAS CLÁSICAS  Real Media (www.realnetworks.com)  Compañía RealNetworks  Multiplataforma  Código abierto y protocolos estándar  QuickTime(www.quicktime.com)  Compañía Apple  Multiplataforma  Código abierto y protocolos estándar  Windows Media (www.windowsmedia.com)  Compañía Microsoft  Plataforma Windows  Código propietario y protocolos estándar TECNOLOGÍAS EMERGENTES  Red 5: Open SourceFlash Server (www.osflash.org/red5)  Proyecto OSFlashde software libre  Multiplataforma  Código abierto y protocolos no estándar (de momento)  Ya utilizado de forma profesional por algunas empresas  VLC Media Player(www.videolan.org)  Proyecto VideoLANde software libre  Multiplataforma  Código abierto y protocolos estándar REAL MEDIA REAL SERVER REAL PRODUCER REAL PLAYER WINDOWS MEDIA QUICKTIME QUICKTIME PLAYER QUICKTIME SERVER VLC MEDIA 6 TELEVISIÓN IPTV Internet Protocol Television (IPTV) se ha convertido en la 3 denominación más común para los sistemas de distribución de señales de televisión y/o video usando conexiones de banda ancha sobre protocolo IP. Es decir, IPTV no es un protocolo en si mismo, sino una denominación que engloba algo mucho más amplio. DIFERENCIAS CON LA TV CONVENCIONAL  El proveedor no transmitirá sus contenidos esperando que el espectador se conecte, sino que los contenidos llegarán sólo cuando el cliente los solicite.  Esto permite el desarrollo del pago por visión o el video bajo demanda.  El usuario dispone de un dispositivo (Set To Box) cuya función es agregar una "capa de computación" a su televisor.  A través de una guía podrá seleccionar los contenidos que desea ver o acceder a otros contenidos (redes sociales, etc.).  El Set To Box tiene capacidad para almacenar contenido y de esta manera poder visualizarlos sin conexión. CARACTERÍSTICAS  Programación personalizada  Servicios interactivos. Canal físico dedicado.  Diferencias entre Web-TV e IPTV Web-TV IPTV Es de alcance mundial. Restringido a una zona. No garantiza QoS. Calidad De Servicio (QoS). El servicio es orientado al PC. Orientado al televisor, requiere Modelo abierto a cualquier un decodificador (Sep Top Box). interesado en subir contenido. Sistema cerrado controlado por Navegación por Internet para el operador. obtener contenido de audio y Infraestructura de red cerrada. video. Ancho de banda. Ancho de banda compartido. Congestión REQUISITOS DE IPTV  Gran ancho de banda (cambio de ADSL a ADSL2)  Las conexiones hoy en día son DSL, Banda Ancha y Satelital.  Se debe otorgar al menos12MB por hogar.  SEÑAL-RUIDO: mayor de 13 dB para garantizar la estabilidad del servicio  ATENUACIÓN: menor de 40dB, ya que si es demasiado alta el servicio puede tener constantes caídas. TIPOS DE CANALES PARA IPTV En el uso de video-streaming en IPTV, se pueden diferenciar dos tipos de canales.  Canal de definición estándar (SDTV). Es necesario tener una conexión de 1.5 Mbps, A este ancho de banda hay que sumarle la conexión a Internet, por lo tanto, se necesitan 4.5 Mbps.  Canal de alta definición (HDTV) es necesario tener una conexión de 8 Mbps. HDTV (HIGH DEFINITION TELEVISION)  Formato 16:9  Las imágenes contienen hasta cinco veces más de información.  Sistema de audio con varios canales.  Codificación MPEG-4  Soporta resoluciones 480i, 576i, 720p, 1080i y 1080p, 50/60Hz, y canalizaciones 6, 7 y 8 MHz, PAL y NTSC  ATSC – Estados Unidos  DVB-T/S/C – Europa y Asia  ISDB-T - Japón ARQUITECTURA  ARQUITECTURA  Adquisición: Transmisión en vivo o producción de programas y Codificación del flujo de video. Codecs. Determina la calidad del video final, la tasa de bits con la que se enviará, la robustez ante las pérdidas de datos y errores, el retraso por transmisión, etc.  Servidores: Plataforma IPTV (DBMS, Servidor Web, Servidor Streaming, Servidor Broadcaster, entre otros), los contenidos guardados a ser emitidos, y la información necesaria para la gestión del sistema.  Distribución: Necesidad de anchos de banda altos para una adecuada prestación de la plataforma, tanto para la conexión de los clientes (un mínimo de 2 Mbps), como para la conexión que permita el acceso a la plataforma (en el orden de varios Mbps, o incluso Gbps).  Red de Acceso: Punto donde termina la red del proveedor y comienza el equipo del usuario. En esta interfaz puede haber una computadora, o un dispositivo STB, encargado de decodificar la información para poder verla en un televisor convencional.  El Software.- Se encarga de proporcionar al usuario los servicios a través de un sistema de menús en la pantalla de su televisor con STB o computadora. Permite la interacción entre el cliente y el sistema. BLOQUES DE LA TRANSMISIÓN IPTV SISTEMAS DE IPTV  Servidores de contenido: Encargados de codificar la señal y fragmentarla. Debe garantizar niveles de QoS elevados.  Características técnicas:  Utiliza redes de acceso de alta velocidad.  Funciones multicast de red y QoS garantizada.  Se implementa fibra óptica en la red troncal y se utiliza como núcleo de la red para realizar multicast.  Decodificación Sep Top Box (usuario).  Entre 6 Mbps a l5 Mbps GENERACIÓN DEL AUDIO Y VIDEO DIGITAL  Detección de errores  Eliminar la interferencia  Disminuir los efectos de ruido en los canales de comunicación  Codificación optima  Encriptación de los datos. FORMATOS DE VIDEO  MPEG-1: calidad similar a VHS compatible con los PC y DVD.  MPEG-2: DVD y permite imagen a pantalla completa con buena calidad.  H.263: Permite bajas tasas con una calidad aceptable. Usado en especial para videoconferencia y videotelefonía.  MPEG-4 parte 2: Calidad mejorada respecto a MPEG-2  MPEG-4 parte 10 (H264): También llamado H264. Es el más usado actualmente por una gran variedad de aplicaciones.  WMV: formato de compresión propietario de Microsoft. DVB (DIGITAL VIDEO BROADCAST)  El DVB es un organismo encargado de regular y proponer los procedimientos para la transmisión de televisión digital compatibles.  Está constituido por más de 220 instituciones y empresas de todo el mundo y los estándares propuestos han sido ampliamente aceptados en Europa y casi todos los continentes, con la excepción de Estados Unidos y Japón donde existen con otros sistemas propietarios.  Este estándar esta basado en MPEG-2 el cual especifica todos los procedimientos de codificación de las fuentes de video y audio. DVB (DIGITAL VIDEO BROADCAST)  El DVB es un organismo encargado de regular y proponer los procedimientos para la transmisión de televisión digital compatibles.  Está constituido por más de 220 instituciones y empresas de todo el mundo y los estándares propuestos han sido ampliamente aceptados en Europa y casi todos los continentes, con la excepción de Estados Unidos y Japón donde existen con otros sistemas propietarios.  Este estándar esta basado en MPEG-2 el cual especifica todos los procedimientos de codificación de las fuentes de video y audio. SERVICIOS DE IPTV  Triple Play: Servicio de telefonía, televisión e internet en la misma infraestructura de red y conexión de banda ancha.  Pago por visión: Pay Per View (PPV) también conocido como televisión a la carta o pago por evento.  Televisión móvil: El STB (Set To Box) debe poder descargar y decodificar A/V en reproductores portátiles.  Switched Digital Broadcast (SDB):Su misión es difundir sólo la programación que el usuario quiere ver. Libera Ancho de Banda  Electronic Program Guide (EPG): Búsqueda y organización de canales.  Time Shifting: almacenamiento en un lapso corto de tiempo de la programación transmitida recientemente  E-learning: Cursos que fomentan el aprendizaje en diferentes grupos de usuario