Análisis de protocolo RTSP y detección de pantalla borrosa

una breve introducción

RTSP(Real Time Streamin Protocol), es un protocolo de capa de aplicaciónTCP/IP en el sistema de protocolo , un estándar presentado por la Universidad de Columbia, Netscape y la empresa . Este protocolo define cómo las aplicaciones de uno a muchos pueden transmitir eficientemente datos multimedia a través de la red. Ubicado arquitectónicamente sobre RTP y RTCP , use TCP o UDP para completar la transmisión de datos . , publicado por el Grupo de Trabajo de Transmisión Multimedia Local en 1996 . El protocolo especifica el formato de paquete estándar para entregar audio y video a través de la red . Se crea en el protocolo. , es un protocolo de control que trabaja con , y su función principal es proporcionar retroalimentación de calidad de servicio para la transmisión de datos . De acuerdo con la introducción anterior, se puede saber que los tres protocolos RTSP, RTP y RTCP son respectivamente responsables de los contenidos como se muestra en la siguiente figura:RealNetworksIETF RFCIPRTSP



RTP(Real-time Transport Protocol)IETFRFC1880RTPUDP
RTCP(Real-time ControlProtocol)RTP

Protocolo de transporte en tiempo real RTP

**RTP**Proporcione servicios de transmisión en tiempo real de extremo a extremo para voz, imagen, fax y otros datos de medios de transmisión que requieren transmisión en tiempo real , pero la calidad del servicio no está garantizada y la calidad del servicio la proporciona la fuente. La transmisión de medios se refiere a los medios basados ​​en el tiempo que utilizan tecnología de transmisión en Internet. A diferencia de los métodos de descarga comunes, la característica de la transmisión por streaming es mirar mientras se descarga , sin esperar a que se descarguen todos los datos de audio o video antes de reproducirlos.RTCP

Cómo funciona el protocolo RTP

RTPy RTCPestán ubicados en la capa de transporte, ejecutándose sobre UDPel protocolo. UDPEl protocolo tiene las características de buen rendimiento en tiempo real, baja demora en la transmisión de datos y UDPmultiplexación, suma de verificación y servicios que se pueden utilizar.

Análisis de paquetes RTP

RTPEl protocolo de datos es responsable de empaquetar la transmisión de datos multimedia y realizar la transmisión en tiempo real de la transmisión de datos multimedia.Cada RTPdato packetse compone headerde payloaddos partes, y el significado del headerprimer 12byte es fijo, pero payloadpueden ser datos de audio o video. Las definiciones y significados de



los mismos son los siguientes:RTP packetheader

paquetes RTP

Cuando una aplicación establece una RTPsesión, la aplicación determina un par de direcciones de transporte de destino. La dirección de transmisión de destino se compone de una dirección de red y un par de puertos. RTPLos datos se envían al UDPpuerto con número par y los RTCPdatos de la señal de control correspondiente se envían al UDPpuerto adyacente con número impar, formando así un UDPpar de puertos.
RTPEl protocolo recibe el flujo de código de información de transmisión de medios de la capa superior, lo encapsula en RTPun paquete de datos y luego lo envía al UDPpuerto con número par en el par de puertos.
A continuación, se toman los datos de video H264 como ejemplo para presentar cómo RTP encapsula los datos H264. H264 tiene tres métodos de embalaje de la siguiente manera:

• Paquete NALU único: un paquete RTP contiene una NALU completa;
• Agregación y empaquetado: correspondiente a NALU más pequeñas, un paquete RTP puede contener varias NALU completas;
• Empaquetado de fragmentación: para NALU más grandes, una NALU puede dividirse en múltiples paquetes RTP y enviarse;

Cada paquete RTP contiene un encabezado RTP y una carga útil, pero en diferentes métodos de empaquetado, además del encabezado y la carga útil, también contiene otras cosas.

• Embalaje individual NALU

El llamado empaquetado único de NALU consiste en colocar los datos de una NALU completa en la carga útil del paquete RTP, que es la forma más sencilla.

• Empaquetado de fragmentos

Cada paquete RTP tiene un límite de tamaño, porque RTP generalmente se envía mediante UDP y UDP no tiene control de flujo, por lo que el tamaño de cada envío debe ser limitado, por lo que si una NALU es demasiado grande, debe dividirse en varios paquetes RTP. mandar.
En el paquete de fragmentación, además del encabezado y la carga útil, hay dos bytes de información en el RTP antes de que comience la carga útil, como se muestra a continuación:

El primer byte, denominado Indicador FU, tiene el siguiente formato:



los tres bits superiores son los mismos que los tres bits superiores del encabezado NAL, los últimos cinco bits son Tipo y el valor es 28, lo que indica el tipo de fragmentación del RTP. paquete.

  Type    Packet      Type name                       
  ---------------------------------------------------------
  0       undefined                                    -
  1-23    NAL unit     Single NAL unit packet per H.264  
  24      STAP-A       Single-time aggregation packet    
  25      STAP-B       Single-time aggregation packet    
  26      MTAP16       Multi-time aggregation packet     
  27      MTAP24       Multi-time aggregation packet     
  28      FU-A         Fragmentation unit                
  29      FU-B         Fragmentation unit                 
  30-31   undefined  

El segundo byte se denomina Cabecera FU, y su formato es el siguiente:



Entre ellos, el primer bit: S, que indica que el paquete RTP es el primer paquete del fragmento NALU, y el segundo bit: E, que indica que el paquete RTP es el segmento NALU El último paquete del segmento, el tercer bit: bit reservado, debe establecerse en 0, los últimos cinco bits: información de tipo de NALU.
Por lo tanto, para los datos de transmisión H264 encapsulados en RTP, el contenido del paquete de datos RTP se muestra en la siguiente figura bajo diferentes métodos de empaquetado:

Desembalaje RTP

RTPDesempaquetar, para H264datos, se refiere a recibir uno RTP packetPrimero, debe juzgar si RTPel método de empaquetado es un paquete NALU único o un paquete de fragmentos, y luego obtener los datos packet payloadobtenidos en y escribirlos en el archivo junto con el byte inicial Eso es todo.H264NAL0x00000001

Canalización de RTSP

Gstreamer tiene un buen soporte para RTP y RTSP. En las tareas de visión real, es necesario obtener datos en tiempo real a través de RTSP y luego usar un modelo de aprendizaje profundo para analizarlos. El marco de razonamiento de aprendizaje profundo Deepstream se basa en Gstreamer, por lo que es necesario analizar la tubería RTSP.

tubería

En Deepstreamel entorno, los siguientes comandos se pueden usar para extraer la RTSPsecuencia, luego usar el modelo para analizar los datos y luego guardar los resultados del reconocimiento como datos de imagen continuos.

gst-launch-1.0 rtspsrc location=rtsp://10.9.4.133/30012 ! rtph264depay ! h264parse ! nvv4l2decoder ! m.sink_0 nvstreammux name=m batch-size=1 width=1920 height=1080 ! nvinfer config-file-path=/opt/nvidia/deepstream/deepstream-6.0/samples/configs/deepstream-app/config_infer_primary.txt batch-size=4 unique-id=1 ! nvmultistreamtiler rows=1 columns=1 width=1920 height=1080 ! nvvideoconvert ! nvdsosd display-bbox=0 display-text=0 ! nvvideoconvert ! jpegenc ! multifilesink location=test%d.jpg

visualización de tuberías

Para la tubería anterior, el diagrama de estructura de la tubería se puede exportar a través de los siguientes pasos, de la siguiente manera:

1. instalar punto

 sudo apt-get install graphviz

2. Establecer variables de entorno de salida de archivos

export GST_DEBUG_DUMP_DOT_DIR=/tmp/

3. correrpipeline

Cree una nueva terminal, copie el comando anterior, modifique la dirección RTSP real y ejecute el comando. Bajo la ruta especificada anteriormente, dotse generarán muchos archivos en este momento, como se muestra en la siguiente figura:

$  ls /tmp 
0.00.00.238129310-gst-launch.NULL_READY.dot
0.00.00.247064574-gst-launch.READY_PAUSED.dot
0.00.00.632677398-gst-launch.PAUSED_PLAYING.dot
0.00.05.464861472-gst-launch.PLAYING_PAUSED.dot
0.00.05.484623147-gst-launch.PAUSED_READY.dot

4. Generar pipelinediagrama de estructura

dot -Tpng 0.00.05.464861472-gst-launch.PLAYING_PAUSED.dot > aa.png
dot -Tpdf 0.00.05.464861472-gst-launch.PLAYING_PAUSED.dot > aa.pdf

Introducción de elementos relacionados

pipelineLa estructura del comando se muestra en la siguiente figura. Dado que la estructura del comando anterior es relativamente complicada, la parte pipelineinvolucrada se propone principalmente aquí .RTSPelements

rtpjitterbuffer

Este elemento reordena y elimina los paquetes RTP duplicados a medida que se reciben de una fuente de red.Este
elemento reordena y elimina los paquetes RTP duplicados recibidos de una fuente de red .
Este elemento requiere la información de velocidad de reloj de la cabida útil RTP para evaluar el retraso.
Si el paquete se recibe tarde, se activará un evento GstRTPPacketLost. A través de este evento, el depayloader u otros elementos pueden crear datos ocultos o alguna otra lógica para manejar los paquetes de datos perdidos.
El jitterbuffer combina el atributo DTS del búfer de entrada y el atributo rtptime en el paquete PTP para inicializar el atributo PTS del búfer de salida.
El jitterbuffer calcula inicialmente cuándo llega un paquete y, si llega demasiado tarde, puede enviar un evento GstRTPRetransmissionRequest (retransmisión) en sentido ascendente.
Este elemento se usará automáticamente dentro de rtpbin (RtpBuffer).

rtph264depay

Extrae video H264 de paquetes RTP extrae video
de RTPpaquetes de datos , que es el proceso de desempaquetado H264que presentamos anteriormente . RTPEn esta elementimplementación, el desempaquetado de paquetes de datos gst_rtp_h264_depay_processse implementa en la función .RTP

simulación de pérdida de paquetes

La transmisión de datos multimedia se transmite a través del protocolo RTSP. En escenarios reales, debido a la red, el ancho de banda y otras razones, se produce una pérdida de paquetes (paquete RTP) durante la transmisión de datos, lo que da como resultado pantallas borrosas en los datos de imagen decodificados. Para algoritmos visuales, pantallas borrosas Provocará una detección falsa y reducirá el rendimiento de la detección, por lo que es necesario evitar la aparición de una pantalla borrosa tanto como sea posible.
En esta sección, primero presentamos cómo crear artificialmente datos de artefactos para pruebas posteriores de detección de artefactos. Bajo la plataforma Linux, se proporciona una herramienta de control de tráfico TC, que puede simular algunas condiciones anormales de la red, como un largo retraso en la red, pérdida de paquetes, falla en la conexión de la dirección de la red, etc.
El uso principal de la herramienta TC es el siguiente:
Retraso de transmisión

• Configure la transmisión de la tarjeta de red eth0 del dispositivo para retrasar el envío en 100 milisegundos

tc qdisc add dev eth0 root netem delay 100ms

• Configure la transferencia para retrasar 100ms ± 10ms

tc qdisc add dev eth0 root netem delay 100ms 10ms

Simular pérdida de paquetes de red

• Soltar aleatoriamente el 1% de los paquetes

tc qdisc add dev eth0 root netem loss 1%

• Deje caer al azar el 1% de los paquetes de datos, la tasa de éxito es del 30%

tc qdisc add dev eth0 root netem loss 1% 30%

Simular la duplicación de paquetes

• Genera aleatoriamente 1% de paquetes duplicados

tc qdisc add dev eth0 root netem duplicate 1%

Corrupción del paquete de simulación

• 0.2% de paquetes corruptos generados aleatoriamente

tc qdisc add dev eth0 root netem corrupt 0.2%

Simular paquete fuera de servicio

• El 25% de los paquetes (50% relevantes) se envían inmediatamente, otros se retrasan 10 segundos

tc qdisc change dev eth0 root netem delay 10ms reorder 25% 50%

borrar regla

sudo tc qdisc del dev eth0 root

reglas de visualización

sudo tc -s qdisc ls dev eth0

Usando TC para realizar Huaping

En el proceso de transmisión de datos RTSP, la causa principal de la pantalla borrosa es la pérdida de datos internos en el paquete RTP. Por lo tanto, los datos de la pantalla borrosa se pueden obtener a través del comando de pérdida de paquete simulado de la herramienta TC.

1. Modelo de pérdida de paquetes

Primero, complete el razonamiento RTSP en los datos de video en una máquina y luego ingrese el siguiente comando para simular la pérdida de paquetes:

# 在当前设备上模拟丢包5%
tc qdisc add dev eth0 root netem loss 5%
# 查看当前设备已经运行的TC命令
sudo tc -s qdisc ls dev eth0

2. Ejecute el comando para extraer la transmisión RTSP

Ingrese el siguiente comando para extraer la transmisión RTSP para obtener los datos de imagen de cada cuadro

gst-launch-1.0 rtspsrc location=rtsp://10.9.4.133/30012 ! rtph264depay ! h264parse ! nvv4l2decoder ! m.sink_0 nvstreammux name=m batch-size=1 width=1920 height=1080 ! nvinfer config-file-path=/opt/nvidia/deepstream/deepstream-6.0/samples/configs/deepstream-app/config_infer_primary.txt batch-size=4 unique-id=1 ! nvmultistreamtiler rows=1 columns=1 width=1920 height=1080 ! nvvideoconvert ! nvdsosd display-bbox=0 display-text=0 ! nvvideoconvert ! jpegenc ! multifilesink location=test%d.jpg

3. Compruebe los datos de desenfoque
   

Detección de pantalla borrosa

La causa esencial de la pantalla borrosa es RTPla pérdida de paquetes durante la transmisión de datos, es decir, la discontinuidad en el proceso de transmisión de datos, por lo que la idea de la detección de pantalla borrosa es la siguiente: RTP packet1. Recibir , comparar con la anterior header, y juzgue si es continuo, 2. Si no es continuo, juzgue si se recibe Sí , juzgue si es un cuadro clave, 3. Si no es un cuadro clave, descarte los datos, 4. Siga descartando los datos hasta el siguiente cuadro clave, y luego reinicie el procesamiento de datos; la lógica comercial de la detección de pantalla borrosa anterior se puede encontrar en Implementado en el código fuente, hay un problema en el proceso anterior, porque algunos datos se descartarán debido a la pantalla borrosa, lo que resulta en marcos de pantalla discontinuos ~~~seqnum



RTP packetpacketseqnumseqnum
seqnumRTP packetNAL Type
RTP packet

**rtph264depay element**

Link de referencia

• https://zhuanlan.zhihu.com/p/72917813
• https://blog.csdn.net/u013554213/article/details/98078955
• https://developer.aliyun.com/article/243398