2012-02-23 18 views
7

Desafortunadamente, todavía estoy atascado con una pequeña implementación de una comunicación RTP/RTCP para acceder a mi cámara IP correctamente.Problema de comunicación RTCP/RTP

¿qué es lo que quiero hacer

La cámara tiene una memoria intermedia interna que quiero leer. Así que me comunico con la cámara a través de RTSP y le digo que transmita los datos. Cuando la cámara pasó por todo el búfer, la transmisión se detendrá.

¿Qué tengo hasta ahora

  1. Una conexión TCP que se comunica a través de RTSP para el DESCRIBE/SETUP/PLAY Solicitud (RTSP) para obtener la corriente comenzó. Esta conexión debe permanecer abierta mientras la cámara transmite sus datos.

  2. Un puerto en el que recibo los datos enviados a través de RTP (basado en UDP) - manejar esto no es de mi incumbencia, incluso no tengo absolutamente ningún acceso, solo quería mencionarlo en aras de la integridad .

  3. Un socket UDP que recibe el RTCP Sender Reports/Source Descriptions. Esto es importante ya que no sé cuándo se detiene la transmisión (como se menciona en el punto 2, no puedo mirar cuando se detiene la transmisión). En este zócalo leo hasta que llega el RTCP Sender Report Goodbye, lo que significa que la transmisión ha finalizado. Luego puedo cerrar el Socket TCP (desde la comunicación RTSP ).

lo que va mal

Se está trabajando para los pequeños tamaños de memoria intermedia como 2MB o 4MB. Recibo algunas descripciones de fuentes y luego un Goodbye. Pero en mi caso particular de prueba quería usar 16MB (que todavía es menos de la mitad de lo que la cámara es capaz de hacer). Recibo los informes del remitente pero en algún momento (siempre alrededor de 8MB +/- 300KB) la cámara simplemente deja de enviar.

Cabe destacar que puedo acceder al buffer vía VLC sin problemas. Incluso miré la comunicación (RTSP y RTCP) que es casi totalmente igual que en mi solicitud ... la única cosa que falta voy a mencionar a continuación:

Posibles razones

Este es la parte donde necesito tu consejo.

Posibilidad: La falta de receptor Informes

Cuando streaming a través de VLC me di cuenta que había algunos RTCP Receiver Reports enviado desde VLC a la cámara (cíclico como el Sender Reports). Entonces, ¿podría ser que la camere espera al menos un Receiver Report en un tiempo específico (o después de una cantidad particular de bytes enviados)? Por el momento no puedo pensar en ninguna otra razón.

¿Solución?

  • Si asumimos que la cámara deja a raudales porque no hay Receiver Reports Me gustaría saber si hay una manera de ponerlas en práctica sin necesidad de llevar a mucha información. Ya leí algunos de los RFC 3550 y creo que todavía hay un montón de lógica detrás de esos mensajes de Informe. Ahora realmente no necesita y tampoco quiero para implementar aquí un protocolo RTCP completo. ¿Sería suficiente enviar algunos marcos falsos Receiver Report para que la cámara siga transmitiendo? Si es así, ¿cómo se ven?

  • Si no está relacionado con la falta de Receiver Reports y simplemente no los necesito, ¿cuál podría ser el motivo para que la cámara detenga la transmisión? ¿Alguna sugerencia?

Editar:

bien acabo conseguido crear una especie de maniquí Receiver Report y parece que funciona (tan sólo pudiera recibir 12MB luego me la Adiós desea)

acabo llena un buffer 28Byte y acaba de utilizar algunos valores en los campos de cabecera, lo que significa:

buffer[0] = 0x80; // Version 2 , Padding = false, Reception Count = 0 
buffer[1] = 0xC9; // Packet Type 201 Receiver Report 
buffer[2] = 0x00; // Higher byte for total length 
buffer[3] = 0x06; // Lower byte for total length (in 32 Bit words -> 28 Byte) 

el resto de la memoria intermedia acabo lleno de ceros Sí, sé que es solo un truco y no deberías decirle a tus hijos que programen así.

Ahora mi pregunta cambia un poco: ¿Está bien con este truco? Parece que funciona, pero todavía estoy un poco preocupado de que mi cámara use esos datos ficticios y cambie la configuración porque interfiere con cosas extrañas.

+0

¿Ha considerado utilizar una biblioteca RTP existente que se ocuparía de esto? – nos

+0

@nos Por supuesto, esta sería una alternativa, pero en realidad quería evitar el uso de cualquier biblioteca porque solo quiero que la transmisión se mantenga activa. No hay necesidad de analizar nada desde el RTCP (esperar si es un Adiós) Mensaje por supuesto). En segundo lugar, toda la aplicación debe ser completamente asíncrona, por lo que me gustaría gestionar todos los sockets, etc. Afaik most libs controlará sus propios enchufes y conexiones. Pero si realmente necesito llenar los Informes Receptor correctamente (con algunos datos "complejos") tal vez realmente considere una lib – Toby

+0

¿Has hecho una captura de paquete wireshark mientras la aplicación está ejecutándose? Esto le dirá exactamente lo que está sucediendo o no con sus datos. –

Respuesta

1

Debe leer los datos del flujo usted mismo. De esta forma, puede proporcionar informes reales del receptor en lugar de informes ficticios.

Si necesita reenviarlo a otro puerto para otra aplicación o biblioteca, simplemente puede hacerlo.

+0

De hecho, quiero ahorrar todos los recursos que tengo (dispositivo incorporado), por lo que quiero evitar leer todos estos datos. Sería bastante innecesario ya que no lo necesito (excepto para RTCP) de todos modos. Entonces realmente preferiría hacerlo con algunos valores ficticios. – Toby

+0

Si bien es posible que no lo "necesite", el servidor lo hace para que pueda ajustar/acelerar los datos para evitar que se inunde la red y la pérdida de paquetes. – Deanna

1

El informe del receptor (RR) puede ser utilizado por algunas cámaras como mensaje "keep alive". Puede intentar enviar a su cámara GET_PARAMETER cada minuto como mensaje de mantener activo, si GET_PARAMETER es aceptado por la cámara. Vea lo que le dice en respuesta a DESCRIBE.

Algunas cámaras IP no pueden analizar RR correctamente. En realidad, estoy tratando de evitar que la biblioteca live555 que uso en mi cliente envíe mensajes RR porque algunos modelos de cámaras Samsung dejan de conectarse (de acuerdo con su soporte técnico).