Analizando diversas capturas de streaming de vídeos en formato
MPEG4, y siguiendo recomendaciones especificadas en el
RFC 3640, el vídeo debe cumplir las siguientes reglas para ser
encapsulado en el payload de RTP:
- Cada unidad de acceso (AU) ha de encapsularse en un
Número entero de paquetes RTP, no pudiéndose encapsular varias
AU en un mismo paquete información. Una AU es la unidad de
información en vídeo encargada de realizar funciones de
sincronismo, fragmentación y suele corresponder con un “slice” de
vídeo que suele coincidir con la información de una línea.
- Si un paquete contiene una sola AU o el último fragmento de
Una AU repartida en varios paquetes, se activará el “Marker bit ” de
La cabecera RTP, teniendo el mismo valor en el campo “Time
Stamp” para los paquetes que transporten una misma AU
fraccionada.
- Analizando los puntos anteriores y realizando diversas
capturas de sesiones de streaming donde se transmiten diversos
contenidos en formato MPEG4 y se encuentran unas peculiaridades
que nos ayudaran a implementar el filtro.
La unidad de acceso transportada el paquete RTP en formato MPEG4
Empieza con una sentencia conocida, que en hexadecimal toma el
valor de “000001B6”, seguida de dos bits que indican el tipo de
frame codificado que transporta. Esta información viene especificada
en el estándar de MPEG4, concretamente en la parte que detalla la
sintaxis del bitstream [2] .Utilizando estos dos bits es posible
determinar el tipo de imagen y de esta forma poder procesar los
paquetes de forma diferente en función del tipo de imagen que
contenga.
Remarcar que si no se encuentra la sentencia 000001B6 al principio
Del paquete deberemos corroborar que el paquete anterior haya
tenido el marker bit activado. Por el contrario si estuviese
desactivado nos encontraremos con una AU empaquetada en varios
paquetes RTP, perteneciendo el contenido analizado a una
continuación del paquete anterior teniendo que clasificar el paquete
en la misma clase que la anterior. De igual forma el campo “Time
Stamp” ha de contener el mismo valor en los paquetes que forman
una única AU.
El esquema gráfico montado para realizar el filtraje de los paquetes
es el siguiente, donde se verifican los siguientes pasos:
1. Se clasifica el paquete IP según el tipo de protocolo que se
transporte en la capa superior a IP.
2. En el caso que sea UDP se procederá a verificar si se transporta
paquetes RTP o RTCP en el campo de datos. De lo contrario se
añadirá en la cola de paquetes desconocidos “UNK”
3. Si el puerto destino es menor a 1024 consideramos que no es un
aplicación que transmite RTP o RTCP, por lo que procederemos a
encaminar el paquete hacia la cola de desconocidos.
4. Si el puerto destino es par, consideramos que corresponde a
RTP. Si por el contrario es un puerto impar se verifica que el valor
corresponde al puerto superior del flujo RTP anterior, tratando
este como un paquete RTCP.
5. En caso que el paquete sea RTP nos fijaremos en los primeros
bytes del payload. En el caso que los 4 primeros bytes sean la
secuencia de inicio de una AU de vídeo (000001B6),
procederemos a la clasificación del frame mediante los 2 bits
siguiente como se indica en la siguiente figura.
6. Si no se encuentra la sentencia de inicio de AU en los primeros
bytes se comprueba la existencia de la secuencia delimitadora de
audio, en cuyo caso se tratará de un paquete de audio.
7. En caso que el paquete se haya clasificado como RTP pero no se
haya podido verificar su tipo se realiza la verificación
anteriormente explicada para comprobar si se trata de una AU
fragmentada.
Fig. 4.10 Esquema de la implementación del filtro clasificador.
Una vez clasificado el paquete el programa implementa un algoritmo
de control de tasa y pérdidas donde son cargadas las
configuraciones independientes para cada tipo de cola.
Los parámetros son obtenidos de un fichero llamado “config.txt”
residente en el mismo directorio de ejecución desde donde llama al
programa. El algoritmo de control de tasa esta implementado
mediante una aproximación al algoritmo de tocken bucket. Remarcar
que en la implementación del filtro no ordena paquetes ni realiza el
reensamblado de los paquetes en caso de que se produzca
fragmentación de paquetes en la capa IP.
Fig. 4.11 Esquema general del programa.
La implementación del filtro no tendría sentido si no se verificará el
Correcto funcionamiento del mismo, por lo que a continuación se
resumen algunos de los procedimientos que se han realizado para
comprobar el correcto funcionamiento del programa.
No hay comentarios:
Publicar un comentario