Análise de protocolo RTSP e detecção de tela desfocada

uma breve introdução

RTSP(Real Time Streamin Protocol), é um protocolo de camada de aplicaçãoTCP/IP no sistema de protocolo , um padrão apresentado pela Columbia University, Netscape e a empresa . Esse protocolo define como aplicativos um-para-muitos podem transmitir com eficiência dados multimídia pela rede. Arquitetonicamente localizado sobre RTP e RTCP , use TCP ou UDP para completar a transmissão de dados . , publicado pelo Local Multimedia Transmission Working Group em 1996 . O protocolo especifica o formato de pacote padrão para entrega de áudio e vídeo pela rede . Ele é criado no protocolo. , é um protocolo de controle que funciona com , e sua principal função é fornecer feedback de qualidade de serviço para transmissão de dados . De acordo com a introdução acima, pode-se saber que os três protocolos de RTSP, RTP e RTCP são respectivamente responsáveis ​​pelo conteúdo conforme mostrado na figura a seguir:RealNetworksIETF RFCIPRTSP



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

Protocolo de transporte em tempo real RTP

**RTP**Forneça serviços de transmissão em tempo real de ponta a ponta para voz, imagem, fax e outros dados de mídia de streaming que exijam transmissão em tempo real , mas a qualidade do serviço não é garantida e a qualidade do serviço é fornecida pela fonte. Streaming media refere-se a mídia baseada em tempo usando tecnologia de streaming na Internet. Diferente dos métodos de download comuns, o recurso de transmissão de streaming é assistir durante o download , sem esperar que todos os dados de áudio ou vídeo sejam baixados antes de reproduzir.RTCP

Como funciona o protocolo RTP

RTPe RTCPestão localizados na camada de transporte, rodando sobre UDPo protocolo. UDPO protocolo possui as características de bom desempenho em tempo real, baixo atraso na transmissão de dados e UDPmultiplexação, soma de verificação e serviços que podem ser usados.

análise de pacotes RTP

RTPO protocolo de dados é responsável por empacotar dados de streaming de mídia e realizar a transmissão em tempo real de dados de streaming de mídia. Cada RTPdado packeté composto headerde payloadduas partes e o significado do headerprimeiro 12byte é fixo, mas payloadpode ser dados de áudio ou vídeo. As definições e significados



deles são os seguintes:RTP packetheader

pacotes RTP

Quando um aplicativo estabelece uma RTPsessão, o aplicativo determina um par de endereços de transporte de destino. O endereço de transmissão de destino é composto por um endereço de rede e um par de portas. RTPOs dados são enviados para a porta de número par UDPe os dados do sinal de controle correspondente são enviados para a porta RTCPde número ímpar adjacente , formando assim um par de portas. O protocolo recebe fluxo de código de informações de mídia de fluxo da camada superior, encapsula-o em um pacote de dados e, em seguida, envia-o para a porta de número par no par de portas. O exemplo a seguir usa os dados de vídeo H264 para apresentar como o RTP encapsula os dados H264. H264 tem três métodos de embalagem da seguinte forma:UDPUDP
RTPRTPUDP

• Embalagem NALU única: um pacote RTP contém uma NALU completa;
• Agregação e empacotamento: correspondendo a NALUs menores, um pacote RTP pode conter várias NALUs completas;
• Embalagem de fragmentação: Para NALUs maiores, uma NALU pode ser dividida em vários pacotes RTP e enviada;

Cada pacote RTP contém um cabeçalho RTP e carga útil, mas em diferentes métodos de empacotamento, além do cabeçalho e da carga útil, também contém algumas outras coisas.

• Embalagem única de NALU

O chamado empacotamento NALU único é colocar os dados de um NALU inteiro na carga útil do pacote RTP, que é a maneira mais simples.

• embalagem de fragmentos

Cada pacote RTP tem um limite de tamanho, pois o RTP geralmente é enviado usando UDP, e o UDP não tem controle de fluxo, então o tamanho de cada envio deve ser limitado, então se um NALU for muito grande, ele precisa ser dividido em vários pacotes RTP enviar.
No empacotamento de fragmentação, além do cabeçalho e do payload, existem dois bytes de informação no RTP antes do início do payload, conforme mostrado a seguir:

O primeiro byte, denominado FU Indicator, tem o seguinte formato:



os três bits superiores são iguais aos três bits superiores do cabeçalho NAL, os últimos cinco bits são Type, e o valor é 28, indicando o tipo de fragmentação do RTP pacote.

  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  

O segundo byte é chamado de Cabeçalho FU, e seu formato é o seguinte:



Dentre eles, o primeiro bit: S, indicando que o pacote RTP é o primeiro pacote do fragmento NALU, e o segundo bit: E, indicando que o pacote RTP é o segmento NALU O último pacote da fatia, o terceiro bit: bit reservado, deve ser definido como 0, os últimos cinco bits: Digite as informações de NALU.
Portanto, para dados de streaming H264 encapsulados em RTP, o conteúdo do pacote de dados RTP é mostrado na figura a seguir em diferentes métodos de empacotamento:

RTP desempacotando

RTPDesempacotar, para H264dados, refere-se a receber um RTP packet.Primeiro, você precisa julgar se RTPo método de empacotamento é um empacotamento NALU único ou um empacotamento de fragmentos e, em seguida, obtenha packet payloados dados obtidos em e grave-os no arquivo junto com o byte inicial É isso.H264NAL0x00000001

pipeline RTSP

Gstreamer tem bom suporte para RTP e RTSP. Em tarefas de visão real, é necessário obter dados em tempo real por meio do RTSP e, em seguida, usar um modelo de aprendizado profundo para analisá-los. A estrutura de raciocínio de aprendizado profundo Deepstream é construída com base no Gstreamer, portanto, é necessário analisar o pipeline RTSP.

gasoduto

No Deepstreamambiente, os comandos a seguir podem ser usados ​​para extrair o RTSPfluxo, usar o modelo para analisar os dados e salvar os resultados do reconhecimento como dados de imagem contínua.

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

visualização de pipeline

Para o pipeline acima, o diagrama de estrutura do pipeline pode ser exportado por meio das seguintes etapas:

1. instalar ponto

 sudo apt-get install graphviz

2. Definir variáveis ​​de ambiente de saída de arquivo

export GST_DEBUG_DUMP_DOT_DIR=/tmp/

3. correrpipeline

Crie um novo terminal, copie o comando acima, modifique o endereço RTSP real e execute o comando. No caminho especificado acima, muitos dotarquivos serão gerados neste momento, conforme a figura a seguir:

$  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. Gerar pipelinediagrama de estrutura

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

Introdução aos elementos relacionados

pipelineA estrutura do comando é mostrada na figura abaixo.Como a estrutura do comando acima é relativamente complicada, a parte pipelineenvolvida é proposta principalmente aqui .RTSPelements

rtpjitterbuffer

Este elemento reordena e remove pacotes RTP duplicados à medida que são recebidos de uma fonte de rede
Este elemento reordena e remove pacotes RTP duplicados recebidos de uma fonte de rede .
Este elemento requer as informações de taxa de clock da carga RTP para avaliar o atraso de atraso.
Se o pacote for recebido com atraso, um evento GstRTPPacketLost será acionado. Por meio desse evento, o depayloader ou outros elementos podem criar dados de ocultação ou alguma outra lógica para lidar com pacotes de dados ausentes.
O jitterbuffer combina o atributo DTS do buffer de entrada e o atributo rtptime no pacote PTP para inicializar o atributo PTS do buffer de saída.
O jitterbuffer calcula inicialmente quando um pacote chega e, se um pacote chegar tarde demais, ele pode enviar um evento GstRTPRetransmissionRequest (retransmissão) upstream.
Este elemento será usado automaticamente dentro do rtpbin. (RtpBuffer)

rtph264depay

Extrai vídeo H264 de pacotes RTP extrai vídeo
de RTPpacotes de dados , que é o processo de descompactação H264que apresentamos acima . RTPNesta elementimplementação, a descompactação dos pacotes de dados gst_rtp_h264_depay_processé implementada na função .RTP

simulação de perda de pacotes

Os dados de streaming de mídia são transmitidos por meio do protocolo RTSP. Em cenários reais, devido à rede, largura de banda e outros motivos, ocorre perda de pacote (pacote RTP) durante a transmissão de dados, resultando em telas desfocadas em dados de imagem decodificados. Para algoritmos visuais, telas desfocadas causará detecção falsa e reduzirá o desempenho da detecção, por isso é necessário evitar o aparecimento de tela desfocada tanto quanto possível.
Nesta seção, primeiro apresentamos como criar artificialmente dados de artefatos para testes subsequentes de detecção de artefatos. Na plataforma Linux, é fornecida uma ferramenta de controle de tráfego TC, que pode simular algumas condições anormais de rede, como longo atraso de rede, perda de pacotes, falha de conexão de endereço de rede, etc.
O uso principal da ferramenta TC é o seguinte:
Retardo de transmissão

• Defina a transmissão da placa de rede eth0 do dispositivo para atrasar o envio em 100 milissegundos

tc qdisc add dev eth0 root netem delay 100ms

• Defina a transferência para atrasar 100ms ± 10ms

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

Simule a perda de pacotes de rede

• Elimine aleatoriamente 1% dos pacotes

tc qdisc add dev eth0 root netem loss 1%

• Elimine aleatoriamente 1% dos pacotes de dados, a taxa de sucesso é de 30%

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

Simule a duplicação de pacotes

• Gera aleatoriamente 1% de pacotes duplicados

tc qdisc add dev eth0 root netem duplicate 1%

Corrupção do pacote de simulação

• 0,2% de pacotes corrompidos gerados aleatoriamente

tc qdisc add dev eth0 root netem corrupt 0.2%

Simular pacote fora de ordem

• 25% dos pacotes (50% relevantes) são enviados imediatamente, outros são atrasados ​​por 10 segundos

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

excluir regra

sudo tc qdisc del dev eth0 root

regras de exibição

sudo tc -s qdisc ls dev eth0

Usando TC para realizar Huaping

No processo de transmissão de dados RTSP, a principal causa da tela borrada é a perda de dados internos no pacote RTP, portanto, os dados da tela borrada podem ser obtidos através do comando de perda de pacote simulado da ferramenta TC.

1. Perda de pacote de modelo

Primeiro, conclua o raciocínio RTSP nos dados de vídeo em uma máquina e, em seguida, insira o seguinte comando para simular a perda de pacotes:

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

2. Execute o comando para extrair o fluxo RTSP

Digite o seguinte comando para extrair o fluxo RTSP para obter os dados de imagem de cada quadro

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. Verifique os dados de desfoque
   

Detecção de tela desfocada

A causa essencial da tela embaçada é RTPa perda de pacotes durante a transmissão de dados, ou seja, a descontinuidade no processo de transmissão de dados, então a ideia da detecção da tela embaçada é a seguinte: RTP packet1. Receba , compare com o anterior header, e julgue se é contínuo; 2. Se não for contínuo, julgue se foi recebido Sim , julgue se é um quadro-chave; 3. Se não for um quadro-chave, descarte os dados; 4. Continue descartando o dados até o próximo quadro-chave e reinicie o processamento de dados; a lógica de negócios da detecção de tela embaçada acima pode ser encontrada em Implementado no código-fonte, há um problema no processo acima, porque alguns dados serão descartados devido ao tela borrada, resultando em quadros de tela descontínuos ~~~seqnum



RTP packetpacketseqnumseqnum
seqnumRTP packetNAL Type
RTP packet

**rtph264depay element**

link de referência

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