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

Os copio y pego la receta que hizo Oscar y que colgó en CrySoL el otro día.

Introducción

Cuando trabajas con Gstreamer, lo que utilizas son básicamente elementos (de hecho, GstElement es una clase abstracta muy alta en la jerarquía). Existen elementos para casi cualquier cosa: sink de audio pasa alsa, esd, oss; sinks de vídeo para xv, ASCII-text, Coloured-ASCII-text… para muchas cosas, pero no para todas. Puede surgir la necesidad de utilizar como fuente un dispositivo muy especial, o quizá sea necesario enviar el audio a un hardware “poco común” conectado al puerto serie.

Para solucionar esto, tenemos la posibilidad de crear nuestros propios elementos de Gstreamer. La API provee diferentes clases abstractas para que no sea necesario empezar desde cero. Estas clases se encargan de hacer cosas como la gestión de estados, el ‘prerolling’, etc., que de otra forma tendrías que currártelo tú mismo. Para más información, consulta el Plugin Writer’s Guide y, especialmente, la sección Pre-mase base class.

Claro, el usar estas clases conlleva cierto precio (que en muchos casos está de sobra amortizado). Por ejemplo, suelen disponer sólo de un pad (para la función que quieras especificar). Las clases que te interesan son:

• gst.BaseSink para crear un elemento de tipo ’sink’
• gst.BaseSrc (y derivados) para crear un elemento de tipo ’source’

Ingredientes

Lo típico: Gstreamer (0.10), Python y una GNU-box :-p

Partes comunes

Si estás leyendo esto doy por hecho que sabes cómo funciona Gstreamer, así que vamos al tema directamente. Los nuevos elementos heredarán de una de las clases base, que les provee una interfaz sencilla para manipularlos. Principalmente, lo que tendrás que hacer es sobreescribir algunos métodos. Además será necesario que especifiques los PAD’s que vas a hacer disponibles. Para esto último, se utiliza una atributo de la clase, __gsttemplates__ (que en una tupla).

Si quieres un pad en el nuevo elemento, lo debes añadir en __gsttemplates__. Para crear un pad, existe una función que nos ayuda, gst.PadTemplate. Los parámetros que esta función acepta son:

• nombre, nombre del pad en concreto
• type, tipo de pad (gst.PAD_SINK, gst.PAD_SRC)
• presence, cuándo está presente el pad (gst.PAD_ALWAYS, gst.PAD_SOMETIMES, gst.PAD_REQUEST)
• caps, las ‘capacidades’ del pad, es decir, el tipo de flujo que manejará. Se debe pasar un objeto de tipo GstCaps, que podemos crearlo con gst.caps_new_any() o gst.caps_from_string(). El primer método crea un objeto con todas las ‘capacidades’ disponibles y el segundo lo crea en función de una cadena de texto (más sobre caps en Capabilities of a Pad)

También, ya que el elemento que estás creando hereda en última instancia de GOject, en el constructor tienes que llamar a __goject_init__(). Además, es bueno que establezcas el nombre del elemento.

Por último, algo imprescindible es registrar nuestra clase como un tipo de Gobject, con gobject.type_register(nombre_clase).

Escribiendo un sink

Los elementos sink (sumidero) son aquellos que permiten recibir un flujo de datos y representan el final de una tubería. Un elemento sink es aquel que sólo tiene pads de tipo sink (en nuestro caso además, sólo tiene uno). Así pues, lo que hagamos con el flujo de datos no le importa al resto de la tubería porque somos el punto final de esta. Es nuestra labor determinar qué hacer con los datos que nos llegan, por ejemplo, mandarlos a nuestro hardware “poco común”, escribirlos en un fichero, etc.

Existen diferentes métodos que se pueden sobreescribir. De todos ellos, el más importante en este caso es el do_render(). Cuando la tubería entra en el estado PLAYING, el flujo de datos circula hacia nuestro elemento, y esto se traduce en una llamada al método do_render(). Por tanto, en ese método es donde debes hacer lo que necesites con los datos. Se recibe un buffer (un gst.Buffer). Cuando retorne, debe devolver un estado determinado para avisar al resto de la tubería si todo fue bien (FLOW_OK), o si los datos no eran los adecuados (FLOW_NOT_SUPPORTED), o si no quieres datos (FLOW_UNEXPECTED), o si ha habido algún error (FLOW_ERROR), etc.

Otro par de métodos útiles que puedes sobreescribir son los conocidos get_property(key) y set_property(key, value), que evidentemente sirven para leer/modificar las propiedades del elemento.

Veamos un ejemplo sencillo:

class HelloSink(gst.BaseSink):    __gsttemplates__ = (

        gst.PadTemplate("sink",

                        gst.PAD_SINK,

                        gst.PAD_ALWAYS,

                        gst.caps_new_any()),

        )

def __init__(self, name):

        self.__gobject_init__()

        self.set_name(name)

self.count = 0

def do_render(self, buffer):

        while (self.count < 10):

            print buffer.data

            self.count += 1

            return gst.FLOW_OK

return gst.FLOW_UNEXPECTED

def set_property(self, key, value):

        if key == "name":

            self.set_name(name)

        else:

            print "no existe la propiedad %s" % key

def get_property(self, key):

        if key == "name":

            return self.get_name()

        else:

            print "no existe la propiedad %s" % key

gobject.type_register(HelloSink)

Este ejemplo simplemente imprime los datos que han sido recibidos. Retornamos gst.FLOW_OK si estamos listos para recibir más datos. Si no queremos más datos, podemos retornar gst.FLOW_UNEXPECTED.

Escribiendo un source

Los elementos source son el extremo opuesto en la tubería a los sink. Son la fuente principal (generalmente) de datos para la tubería. Son análogos en muchos aspectos a los sink. Sólo tiene pads de tipo src (en este caso, sólo uno). También es posible sobreescribir varios métodos de los cuales el más importante, en este caso, es do_create(). De nuevo, es la tubería quien llama a este método, con dos parámetros: offset, que representa la posición del primer byte que espera recibir y size, especificando la cantidad de bytes que necesita. Esta función debe retornar dos parámetros: uno indicando cómo ha ido todo (como en el anterior caso, gst.FLOW_OK, gst.FLOW_ERROR, etc.) y otro con los datos pedidos (dentro de un gst.Buffer).

Veamos otro ejemplo sencillo para un src:

class HelloSrc(gst.BaseSrc):    __gsttemplates__ = (

        gst.PadTemplate("src",

                        gst.PAD_SRC,

                        gst.PAD_ALWAYS,

                        gst.caps_new_any()),

        )

def __init__(self, name):

        self.__gobject_init__()

        self.set_name(name)

def do_create(self, offset, size):

        ret = gst.Buffer("¡Hola mundo!")

        return gst.FLOW_OK, ret

def set_property(self, key, value):

        if key == "name":

            self.set_name(name)

        else:

            print "no existe la propiedad %s" % key

def get_property(self, key):

        if key == "name":

            return self.get_name()

        else:

            print "no existe la propiedad %s" % key

gobject.type_register(HelloSrc)

Este ejemplo simplemente envía la cadena “¡Hola mundo!” por la tubería.

Algo que me gustaría comentar es que existen clases especiales para trabajar con fuentes de datos ’secuenciales’ (es decir, que no se puede acceder a posiciones determinadas del flujo, como fuentes de live audio o cámaras). Para estos casos, quizá te sea más útil emplear gst.PushSrc

Probando nuestros elementos

Para testear nuestros nuevos elementos tenemos que crearlos a mano, ya que no los hemos registrado todavía en la factoría de Gstreamer. No podemos usar gst.element_factory_make() y mucho menos gst.parse_launch() (el registrar los componentes lo dejo para otro escrito )

Así que nuestro programa de prueba quedaría más o menos de la siguiente forma:

pipe = gst.Pipeline("helloPipe")

src = HelloSrc("source")

sink = HelloSink("sink")pipe.add(src, sink)

gst.element_link_many(src, sink)

pipe.set_state(gst.STATE_PLAYING)

def bus_event(bus, message):

    t = message.type

    if t == gst.MESSAGE_EOS:

        loop.quit()

return True

pipe.get_bus().add_watch(bus_event)

loop = gobject.MainLoop()

try:

    loop.run()

except:

    pass

Y la salida debería ser la esperada:

$ python hello.py

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

¡Hola mundo!

Referencias

Ejemplos de gstreamer

En los últimos días hemos hecho una re-estructuración bastante grande del proyecto. Actualmente las especificaciones slice de ZeroC Ice para GstIce se instalan en /usr/share/gstice. Se ha añadido soporte para crear un módulo python para que nuestra librería pueda ser usada de forma transparente por el usuario y hemos re-escrito parte del código, para resolver algunos de los FIXME pendientes en ambos módulos (gstIceSrc y gstIceSink).

También hemos creado algo de documentación explicando como crear elementos Gstreamer en Python para poder añadirlos posteriormente a una tubería GStreamer, que os pondremos por aquí en el blog en breve.

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

Os traigo un reproductor de ficheros Ogg que hicimos hace unos meses. Utiliza Gstreamer para leer los datos de un fichero ogg. La tubería que utiliza es bastante sencilla: lee el fichero Ogg y se lo envía a la tarjeta de sonido, decodificandolo primero con oggdemux y vorbisdec.

import pygst
pygst.require("0.10")
import sys, gst, gobject
gobject.threads_init()  

def main(args):

    if len(args) != 2:
        print "Uso:", args[0], " "
        return -1

    pipestr = 'filesrc location=' + args[1] + ' ! n' + 'oggdemux ! vorbisdec ! audioconvert ! alsasink n'

    try:
        pipeline = gst.parse_launch(pipestr)
    except gobject.GError, e:
        print "No es posible crear la tubería,", str(e)
        return -1

    def eventos(bus, msg):
        t = msg.type
        if t == gst.MESSAGE_EOS:
            loop.quit()

        elif t == gst.MESSAGE_ERROR:
            e, d = msg.parse_error()
            print "ERROR:", e
            loop.quit()

        return True    

    pipeline.get_bus().add_watch(eventos)

    pipeline.set_state(gst.STATE_PLAYING)

    loop = gobject.MainLoop()
    try:
        print "Reproduciendo..."
        loop.run()
    except KeyboardInterrupt: # Por si se pulsa Ctrl+C
         pass

    print "Parando...n!Adios!"

    pipeline.set_state(gst.STATE_NULL)
    return 0

if __name__ == "__main__":
    sys.exit(main(sys.argv))

Este ejemplo demuestra la potencia que tiene GStreamer + Python. En pocas líneas de código tenemos toda la funcionalidad para reproducir ficheros Ogg, y con la flexibilidad que nos ofrece Gstreamer.

Con gstLaunch podemos probar las tuberías que vayamos a usar sin necesidad de programar nada. GstEditor podemos utilizarlo para diseñar las tuberías, conectando unos elementos a otros a través de sus “pads” o enchufes. Estas dos utilidades gstreamer nos serán útiles en varias situaciones para “jugar” con las tuberías Gstreamer.

Por fin hemos terminado de exámenes y vamos a tener más tiempo para dedicarle al proyecto. En las próximas semanas tendréis bastantes avances en el proyecto, puesto que tenemos más tiempo.

Aunque aún no hayamos utilizado el repositorio subversion que nos da la organización, hemos ido haciendo el trabajo en un repositorio externo. Tenemos 2 elementos GStreamer, un Source y un Sink, utilizados para construir la tubería Gstreamer y enviar y recibir el flujo multimedia a través de la red.

Ya hemos probado IceStorm. Funciona muy bien y nos viene al pelo para el propósito de nuestra librería.

Volvemos con aires renovados.

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!

Arrancamos motores. El concurso está en marcha, y nuestro proyecto también.

Nuestro objetivo es crear una librería que permita el envío y la recepción de audio y/o vídeo a través de una red, utilizando GStreamer para manejar los flujos multimedia y usando ZeroC Ice como transporte.Para comprobar la validez y potencia del sistema, implementaremos una aplicación que use nuestra librería y que permita la transmisión de voz entre dos puntos de una red, siendo posible la multidifusión y la creación de salas de conversación.

Debido a la flexibilidad del sistema, también se pueden crear sistemas cerrados de TV o aulas virtuales.

Muchas gracias a la organización por los recursos disponibles y mucha suerte a todos los participantes

¡Vamos allá!