Camaras IP para streaming, RTSP

Camaras IP para streaming, Protocolo RTSP

 

Dejamos acá un modelo de cámara, que si bien diseñada para video seguridad, se utilizó con éxito para la realización de streaming de video y audio de alta calidad.

En este caso el colegio San Judas Tadeo de Ituzaingó. Utilizan el protocolo RTSP, es un modelo de cámara IP de 4Mpx, con zoom motorizado y visión nocturna por Led Array que ofrece tanto en modo día como en infrarrojo una calidad de imagen adecuada para la transmisión de eventos.

Video modo día y modo noche, visión nocturna, con aplicación de zoom. Se redujo para subir a Youtube la resolución a 480p

Video en el sitio de la entidad, clic en la imagen para ir al video.

Segmento de video, disponible para descarga en el propio sitio.

 

Otro modelo viable, sin zoom motirado y 2Mpx de resolución es este, igual constructivamente al anterior.

o algo mas basico, cuando el audio no es requerido

Para la teoria, RTSP es  un protocolo no orientado a conexión, en lugar de esto el servidor mantiene una sesión asociada a un identificador, en la mayoría de los casos RTSP usa TCP para datos de control del reproductor y UDP para los datos de audio y vídeo aunque también puede usar TCP en caso de que sea necesario.

 

Dejamos acá información sobre este protocolo y su implementación

Fuente:

http://profesores.elo.utfsm.cl/~agv/elo323/2s10/projects/ApablazaBustamante/desc.html

 

RTSP es un protocolo de capa de aplicación, no orientado a la conexión. En lugar de esto el servidor RTSP mantiene una sesión asociada a un identificador (Session ID).
En la mayoría de los casos RTSP usa TCP para el envío de datos de control del reproductor (mensajes “out of band”) y UDP para los datos de audio y vídeo (mensajes “in band”), aunque también puede usar TCP en caso de que se necesitara confiabilidad en el envío de paquetes, lo cual no es provisto por UDP.
El concepto de “in band” y “out of band” se refiere a que el protocolo es capaz de enviar distintos tipos de información por distintos puertos.
De forma intencionada, el protocolo es similar en sintaxis y operación a HTTP, por lo que los mecanismos de expansión añadidos a HTTP pueden, en muchos casos, añadirse a RTSP. Sin embargo, RTSP difiere de HTTPen un número significativo de aspectos:
– RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente.
– Un servidor RTSP necesita mantener el estado de la conexión.
– Tanto el servidor como el cliente pueden hacer solicitudes.
– Los datos son transportados por un protocolo diferente.
El protocolo soporta las siguientes operaciones:
Recuperar contenidos multimedia del servidor: El cliente puede solicitar la descripción de una presentación por HTTP o cualquier otro método. Si la presentación es multicast, la descripción contiene los puertos y las direcciones que serán usados. Si la presentación es unicast el cliente es el que proporciona el destino, por motivos de seguridad.
Invitación de un servidor multimedia a una conferencia: Un servidor puede ser invitado a unirse a una conferencia existente en lugar de reproducir la presentación o grabar todo o una parte del contenido. Este modo es útil para aplicaciones de enseñanza distribuida donde diferentes partes de la conferencia van tomando parte en la discusión.
Adición multimedia a una presentación existente: Particularmente para presentaciones en vivo, útil si el servidor puede avisar al cliente sobre los nuevos contenidos disponibles.
En la siguiente figura se ilustra el esquema de comunicación entre un cliente (Web Browser) y el servidor RTSP (Web Server). 

Interchange

1. Web Browser solicita Presentation Description File a Web Server.
2. Web Server encapsula Presentation Description File en un mensaje HTTP de respuesta y envía el mensaje al Web Browser.
3. Cuando el Web browser recibe mensaje HTTP de respuesta, invoca a un Media Player (eg. Quicktime) basándose en el campo Payload Type (PT) del mensaje.
4. Media Player envía una petición RTSP SETUP y Media Server responde RTSP OK.
5. Media Player envía una petición RTSP PLAY y Media Server responde RTSP OK.
6. Media Server inicia el streaming de video hacia Media player.
7. Si usuario desea pausar la transmisión, envía RTSP PAUSE a Media Server y éste responderá RTSP OK.
8. Cuando el usuario ha terminado, Media player envía RTSP TEARDOWN, a lo que Media server responde RTSP OK.
A continuación se muestra un ejemplo de intercambio RTSP, entre un cliente (C) y un servidor (S).
C: SETUP movie.Mjpeg RTSP/1.0
C: CSeq: 1
C: Transport: RTP/UDP; client_port= 25000

S: RTSP/1.0 200 OK
S: CSeq: 1
S: Session: 123456

C: PLAY movie.Mjpeg RTSP/1.0
C: CSeq: 2
C: Session: 123456

S: RTSP/1.0 200 OK
S: CSeq: 2
S: Session: 123456

C: PAUSE movie.Mjpeg RTSP/1.0
C: CSeq: 3
C: Session: 123456
S: RTSP/1.0 200 OK
S: CSeq: 3
S: Session: 123456

C: PLAY movie.Mjpeg RTSP/1.0
C: CSeq: 4
C: Session: 123456

S: RTSP/1.0 200 OK
S: CSeq: 4
S: Session: 123456

C: TEARDOWN movie.Mjpeg RTSP/1.0
C: CSeq: 5
C: Session: 123456

S: RTSP/1.0 200 OK
S: CSeq: 5
S: Session: 123456

 

El parámetro Cseq corresponde al Sequence Number, número que aumenta en una unidad por cada petición enviada por el cliente. Session es un número que está fijo durante toda la sesión, y es usado por el servidor para reconocer al cliente. Esto es útil en caso de servidores con múltiples clientes. CSeq y Session permiten al servidor hacer un seguimiento de estado de sesión.
El Presentation Description File, que fue mencionado anteriormente, es un archivo que contiene los tipos de compresión y la manera en que se transmite el archivo. En el caso de RTSP, el Presentation Description File contiene la URL que identifica al streaming RTSP, mediante la sintaxis “rtsp://”.
Un ejemplo de este arhivo se presenta a continuación:
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio e=”PCMU/8000/1″ src =
rtsp://audio.example.com/twister/audio.en/lofi”>
<track type=audio e=”DVI4/16000/2″ pt=”90 DVI4/8000/1″
src=”rtsp://audio.example.com/twister/audio.en/hifi”>
</switch>
<track type=”video/jpeg” src=”rtsp://video.example.com/twister/video”>
</group>
</session>
En este ejemplo, el usuario puede elegir entre dos calidades de transmisión de audio (lofi: PCMU/8000/1 o hifi: DVI4/16000/2 para estéreo y 90 DVI4/8000/1 para mono.
Finalmente se hace una breve descripción del significado de las solicitudes RTSP
SETUP
Especifica cómo debe transportarse un tipo específico de audio o video. La solicitud debe hacerse antes de que se envíe una petición PLAY. El mensaje contiene la dirección URL y un especificador de transporte. La respuesta del servidor usualmente confirma los parámetros elegidos y determina los campos incompletos, como por ejemplo los puertos elegidos por el servidor.
PLAY
Permite el envío de un stream multimedia (audio o video). Las solicitudes PLAY pueden acumularse enviando múltiples solicitudes PLAY. La dirección URL puede estar asociada a 1 sólo flujo multimedia o a varios. Debe especificarse un rango de reproducción, en caso contrario el flujo es reproducido de principio a fin. Y en caso de ser pausado, seguirá desde el mismo punto, cuando el cliente reanude la reproducción.
PAUSE
Detiene temporalmente la reproducción de 1 o más flujos multimedia. Posteriormente se puede reanudar la reproducción mediante la solicitud PLAY. Puede especificarse un rango en la pausa, en caso contrario la pausa será inmediata.
TEARDOWN
Se utiliza para terminar la sesión. Cuando el cliente envía esta solicitud, el servidor detiene todos los flujos asociados a la sesión, y libera los recursos para su posterior uso.