Control de flujo

Vamos a añadir algún tipo de control de flujo a la librería de nuestro proyecto. Actualmente el control de flujo que implementamos es muy primitivo.

He estado leyendo sobre RTP y RTCP en las últimas semanas. Su objetivo es transportar datos de tiempo real (como audio y vídeo) en un entorno como internet. RTP se dedica a mandar datos por un puerto UDP y RTCP se encarga del control de los datos (ver si han llegado correctamente, cuantos datos se han perdido, etc)

Podemos implementar un control de flujo similar al que tiene RTP. Utilizaremos canales de eventos de ZeroC ICE para transmitir por un lado los datos (tal y como hacíamos hasta ahora), y por otro lado la información de control. De esta manera podremos reenviar los datos que no hayan llegado a los receptores.

Tenéis más información en los links que os dejo.

Referencias

RFC 3550 (RTP y RTCP)

RTP Working Group

RTP Easy Tutorial

Parámetros RTP definidos por la IANA

RTP en la Wikipedia

RTCP en la Wikipedia

Avances en el proyecto

En estas últimas 2 semanas hemos hecho muchos avances en el proyecto. Actualmente tenemos una versión totalmente funcional que seguimos refinando. Los streams se transmiten correctamente a través de la red utilizando el transporte IceStorm.

Hemos eliminado la dependencia que teníamos de los ficheros de configuración de ICE y actualmente estamos planeando una estructuración de los directorios para poder importar directamente GstIce como un módulo python, de forma transparente al usuario. Estos días estamos usando el repositorio de forma bastante activa.

Además hemos hecho importantes cambios en la lista de cosas por hacer, quedan todavía bastantes tareas, más y menos importantes:

Objetivos principales

• Probar el funcionamiento con micrófono
• Permitir múltiples envíos (consecutivos) de streams diferentes. Actualmente recibe uno solo, el resto los ignora.
• Si hay una pausa en el flujo, se deja de recibir datos.
• Interfaz gráfica que utilice la librería

Características secundarias

• Implementar algún control de flujo para evitar enviar todos los datos directamente (contando con la información de buffers del subscriber).
• Corregir los fixme de ambos módulos.
• Crear documentación del proyecto.
• La estructura de datos debe ser una cola circular. Evidentemente, se han de eliminar los datos que ya han sido leídos.
• Utilizar algún mecanismo que evite hacer una espera activa en el do_create del src.
• Implementar todo el trabajo como un único modulo, de forma transparente al usuario.
• Soporte de Festival y Sphinx en caso de que no haya ancho de banda disponible

Usemos IceStorm

He estado mirando la documentación de ZeroC-ICE y creo que para nuestros propósitos, lo mejor es usar un servidor de distribución de eventos. ICE tiene un servicio que se llama ICEStorm que se encarga de esto.

Evidentemente tenemos dos roles: el envío del flujo de datos y la recepción. Para ello, y en términos de ICEStorm, tendremos que crear un ‘publisher’ y un ’subscriber’. Gracias al servicio de difusión, varios puntos de recepción se pueden añadir a una misma transmisión. Se pueden crear temas o ‘topics’ a los cuales suscribirse para recibir el flujo de datos. E incluso, podemos asociar varios ‘topics’ a una misma transmisión, con el objetivo de controlar el flujo de datos de forma adecuada.

Creo que todo esto se puede integrar fácilmente en un módulo para Gstreamer, de forma que los usuarios no tengan que preocuparse de ICE para las labores más cotidianas.

Bueno, ¡manos a la obra!