En marzo de 2002 se llevó a cabo una demostración [64] de HDTV sin comprimir sobre una red IP y en el marco del proyecto Ultragrid [65] el cual trata sobre colaboración a distancia en un ambiente de alta definición en imagen.
Esta demostración se basó en una red IP comercial con “best-effort”. Vale decir que no hay garantía que la red descarte, duplique, retrase o desordene paquetes de datos de un mismo flujo.
El esquema de protocolos usados fue el siguiente: • IPv4
• UDP: no tiene control de congestión y por lo tanto la entrega de paquetes se aproxima más al tiempo real si las pérdidas de paquetes son muy bajas
• RTP: provee el framing del video, identifica el origen y tipo del payload, y permite “timing-recovery” y detección de pérdida de paquetes. Típicamente corre sobre redes IP/UDP con sus limitaciones inherentes: entrega no confiable (no posee control de congestión) y con “best-effort”. Los receptores usan la información en los headers RTP para corregir la pérdida de paquetes y reconstruir el “media timing”.
• Nivel de aplicación: la salida del CODEC de video se paquetiza y fragmenta en forma inteligente, de acuerdo al formato del payload, y así cada paquete RTP puede ser decodificado en forma independiente. Por lo tanto se debe hacer con cuidado el diseño de los receptores dado que tienen la responsabilidad primaria de corregir la reproducción del video descompaginado por las características de una red IP con best-effort.
Un área crítica para este sistema fue que RTP no provee control de congestión, por lo cual hubo que elegir entre desarrollar un mecanismo de control de congestión o bien correr la aplicación en una red con el suficiente ancho de banda. Se optó por elegir una red que tenga la suficiente capacidad para transportar el flujo de HDTV, transmitiendo sólo video. Hay redes que demostraron suficiente capacidad para estos experimentos, como Abilene y DARPA SuperNET [66].
El test inicial fue hecho sobre la red Supernet entre ISI East (Arlington, VA), y CMU (Pittsburg, PA). El path incluye 9 hops en cada dirección y
tiene un RTT de 10 mseg aproximadamente. Se usaron enlaces OC-48 compartidos con tráfico IP, sin calidad de servicio ni control de congestión. Tanto el transmisor como el receptor usaron placas de red Gigabit Ethernet conectadas a una estructura switcheada con tecnología Gigabit Ethernet también. La red Gigabit Ethernet se conectó a un router de borde Juniper o Cisco, según sea el extremo, los cuales se conectaron a la WAN vía una intreface OC-48 POS (2.5 Gbps Packet over SONET). Esta WAN está formada por una mezcla de routers Juniper y Cisco con interfaces OC-48 y OC-192 POS.
Para conocer la capacidad de la red, primero se realizaron mediciones de tráfico TCP y UDP con la herramienta Iperf [39]. La performance fue dependiente de la carga de la red pero se llegó a velocidades de transmisión satisfactorias.
El sistema para transportar HDTV sobre IP se diseñó con RTP/RTCP como transporte, pero se debió desarrollar un formato de payload RTP específico para tal fin.
El sistema acepta señales digitales de video SMPTE-292M y las encapsula dentro de RTP para transmitirlas sobre IP. Se eligió el mecanismo de empaquetameinto nativo (en lugar de emulación de circuito) para llevar a cabo la experiencia dado que no se quería regenerar la señal SMPTE-292M en el extremo receptor, sino mostrarla en un monitor de una workstation. La opción para el transporte local de HDTV fue SMPTE-292M.
Aclaro que el empaquetamiento nativo define un formato de payload RTP para transportar el video en forma directa. El empaquetamiento nativo mira el contenido del stream SMPTE-292M y actúa sobre los datos de video dentro de él. Por lo tanto, se debe definir un formato nativo para cada resolución de video.
Por otro lado, la emulación de circuito provee el envío transparente del stream HDTV, adecuado para ingresarlo en otros dispositivos.
Se usó una versión actualizada de la biblioteca RTP del proyecto UCL Robust-Audio Tool [67] para proveer el núcleo de las funciones de red del sistema. Es una implementación RTP completa, que soporta IPv4, IPv6 y Multicast.
Los requerimientos del sistema fueron que se transmita y se reciba en máquinas separadas.
En el diseño e implementación del sistema se usaron componentes de hardware comerciales disponibles en el mercado. El núcleo del sistema fue una PC de gran performance, con una placa capturadora de HDTV y otra placa Gigabit Ethernet.
A continuación se detalla alguna información relevante sobre la tecnología usada y algunos resultados logrados:
• Unicast
• Se transmitió el video stream a una velocidad de 615 Mbps • Se envió información de HDTV de 1280x720 pixels a 45 fps • Se usaron 8 bits por componente de color (subsampling a 24 bits) • Se midió la pérdida de paquetes y la misma fue de aproximadamente
0.3 %, con la mayoría de las pérdidas ocurridas en paquetes aislados (no consecutivos)
• Se usó la red suavemente cargada, por lo que no hubo en forma significativa un jitter como para impactar el timing de los paquetes • Se produjo un pequeño grado de reordenamiento de paquetes en el
path, que fue aproximadamente del orden de 0.05 %, y con la mayoría de los eventos ocurridos en paquetes adyacentes. En raras ocasiones se observaron paquetes que fueron entregados con 2 o 3 lugares fuera de secuencia
• Para mejorar la calidad de HDTV sin comprimir, hubiera hecho falta un throughput de 850 Mbps y 60 fps, y 1.03 Gbps para color completo (full color) con 10 bits por componente de color