The Runtime Interaction

receptor, los cuales interactúan a través de una red IP.

En el extremo emisor, se capturan los datos multimedia sin comprimir en forma separada (audio samples y frames de video) dentro de sus respectivos buffers, desde los cuales se obtienen los frames. Los frames luego son asignados con un timestamp y un número de secuencia y así se cargan en paquetes RTP (paquetizado), estando ahora listos para ser transmitidos. Si los frames son muy grandes pueden ser fragmentados dentro de diferentes paquetes RTP. Luego que los paquetes de datos han sido enviados, los buffers de entrada son eventualmente liberados (acá no hay que dejar de tomar en cuenta la opción que el emisor no descarte los datos dado que podrían ser necesitados para llevar a cabo la corrección de errores en el caso de ser requerido, y así los almacene por un cierto tiempo dependiendo del esquema de corrección de errores usado). Además, el emisor es responsable de generar reportes de estado en forma periódica para los streams multimedia que está generando, inclusive aquellos requeridos para la “lyp-synchronization” (sincronización de audio y video). También recibe el feedback de la calidad de recepción por parte del lado receptor y usará dicha información para adaptar su transmisión (control de congestión).

Las muestras de audio en el extremo emisor son capturadas, digitalizadas y almacenadas en el buffer de audio de entrada. Generalmente el buffer de entrada se hace disponible a la aplicación luego que se han recolectado un número fijo de muestras de audio. Esto impone un cierto delay porque la primera muestra de audio no estará disponible hasta que que la última muestra haya sido almacenada.

Sampling frequency

Audio frame

Diagrama del libro “RTP: audio and video for the Internet” de Colin Perkins

En el caso del video, se empleará un dispositivo de captura que opere capturando los frames completos de la imágen de video entrelazado. Los dispositivos de captura deben ofrecer su salida en una variedad de formatos, espacios de color (por ejemplo YUV), profundidades y subsampling. En este punto es importante aclarar que la aplicación debe ser capaz de “parsear” (analizar) la cola de entrada (input queue) y determinar dónde comienza y dónde finaliza cada línea de escaneo del video (aunque también hubiese sido factible contar con un dispositivo de captura de video que capture directamente las líneas de escaneo en lugar de los campos o frames enteros). Luego las líneas de escaneo se asocian con el instante de captura (capture time) del frame correspondiente y son pasadas al módulo RTP de la aplicación para su correspondiente paquetización y transmisión.

Generación de paquetes RTP

Cada frame tiene asociado un timestamp, del cual se deriva el timestamp RTP. Si el formato de payload soporta fragmentación –tal el caso de los formatos de payload para video sin comprimir y audio AC-3 que se explicarán más adelante-, los frames de audio y las líneas de escaneo de

video se fragmentan según el MTU del path de la red. Finalmente se generan uno o más paquetes RTP para cada frame o línea de escaneo, cada uno de los cuales incluye los datos multimedia y cualquier payload header requerido. El formato del paquete multimedia y el payload header se definen de acuerdo a la especificación del formato de paylaod usado. Las partes críticas en la generación de los paquetes RTP son la asignación de timestamps a los frames, la fragmentación de largos frames y la generación del paylaod header. Luego de la transmisión de los paquetes RTP –como ya se mencionó antes-, la cola de entrada es liberada a menos que se guarden los datos un cierto tiempo para usarlos con algún tipo de algoritmo de corrección de errores.

Timestamps y el modelo de timing RTP

El timestamp RTP representa el instante de muestreo del primer octeto de datos en el frame. Comienzo con un valor inicial aleatorio y se incrementa a una velocidad dependiente de la multimedia.

Durante la captura de multimedia en vivo –tal el caso en estudio-, el instante de muestreo es simplemente el instante en el cual se captura la multimedia desde el video frame grabber (placa capturadora de HDTV de la PC) o el dispositivo de audio (placa capturadora de sonido de la PC). Como el audio y video van a ser sincronizados, se deberá tener sumo cuidado en tener en cuenta el delay en los diferentes dispositivos de captura.

En el extremo receptor, se recolectarán los paquetes RTP que provienen de la red, se recuperará el timing y se llevará a cabo la sincronización entre los flujos multimedia para luego llevar a cabo la reproducción o playback. Además enviará al emisor el feedback de calidad de recepción para permitir que éste adapte su transmisión.

El primer paso del proceso receptor es recolectar los paquetes de la red e insertarlos dentro de una cola de entrada (input queue) para cada stream (audio y video). Luego los paquetes son recolectados desde la cola de entrada y así son insertados en un jitter buffer (playout buffer). A la cola de entrada llegan los paquetes en el orden impuesto por la red y luego al ingresar al jitter buffer se ordenan según los timestamps, y así el proceso de insertar paquetes dentro del citado buffer corrige cualquier reordenamiento inducido durante el transporte. Los paquetes permanecen en el buffer hasta que se reciban los frames completos y para remover cualquier variación del timing inter-paquete causado por la red (jitter). El cálculo de la cantidad de delay a agregar es uno de los aspectos más críticos del diseño de la

implementación RTP. Luego cada paquete es marcado (tagged) con el tiempo de reproducción deseado para el frame correspondiente.

Luego de que es alcanzado el tiempo de playout, los paquetes son agrupados para formar frames completos, y eventualmente se corregirán los errores en el caso de ser requerido.

En el caso del audio, que arriba codificado, luego de ser reparados los frames son decodificados. Dependiendo del CODEC especificado, el proceso de decodificación de los frames puede ser hecho antes que el proceso de reparación de los mismos.

En este punto puede haber diferencias observables en las velocidades de clock nominales del emisor y el receptor. Tales diferencias se manifiestan como una derivación (drift) del reloj multimedia RTP relativo al reloj de playout. El receptor debe compensar esta desviación de reloj para evitar saltos en la reproducción.

Finalmente los datos multimedia son reproducidos en el receptor, audio y video en un dispositivo de salida por separado. Vale decir que los streams de audio y video no se mezclarán para obtener un solo stream para la reproducción en un único dispositivo de salida.

Como se ve, la operación del receptor es mucho más compleja que la del emisor, principalmente a causa de la recuperación del timing de los streams afectados por el jitter inducido por la red.

En el caso de la reproduccón de video, si la misma se la hace en un monitor faltaría entonces un bloque conversor de color YUV a RGB.

Como se mencionó antes, RTP usará dos puertos UDP para cada sesión: uno para datos y otro para el tráfico de control. Esto significa que la aplicación en el extremo receptor abrirá dos sockets para cada sesión. Dado que RTP corre sobre IP/UDP, los sockets usados son del tipo SOCK_DGRAM (estándar) como los provistos por los sockets API Berkeley en los sistemas Unix y los Winsock provistos por Microsoft.

Cuando un paquete arriba al receptor, lo primero que hace es ser procesado en el sistema operativo a nivel IP/UDP, que incluye un buffer de recepción del socket. Luego el paquete se dirige al stack RTP y de allí al módulo de recepción del paquete, com se ve en la siguiente figura:

Diagrama del libro “RTP: audio and video for the Internet” de Colin Perkins

Aquí hay que tomar en cuenta que como esta es una implementación con una transmisión de alta velocidad, habría que analizar la posibilidad de agrandar el tamaño del buffer del socket más allá del valor predeterminado con el objeto de no perder paquetes.

En este punto vale la pena aclarar que los formatos de paylaod RTP definen una velocidad nominal de reloj para el stream multimedia, pero no especifica requerimientos sobre la exactitud y estabilidad del reloj. El emisor y receptor corren comúnmente a velocidades mínimanmente diferentes, forzando a que el receptor lleve a cabo una compensación para dicha variación. Así los receptores deberán detectar la presencia del corrimiento del reloj, estimar su magnitud y ajustar el punto de compensación. Una manera de hacerlo es ajustar el reloj del receptor para que se corresponda al reloj del emisor.

Más adelante se explicarán los aspectos del diseño de los media buffers y la reproducción de la multimedia.

14.3.Opciones para transportar HDTV sobre IP en Internet2