O que é RTSP e por que ele é necessário?

Correios robóticos, drones, carros não tripulados e outras conquistas da ciência e tecnologia modernas já não parecem ser algo fora do mundo da fantasia. Eles se tornaram um fenômeno comum (ou quase) para nós. As câmeras IP embutidas lhes permitem “ver” o que está acontecendo e nós podemos ver o mundo através de seus “olhos”. Mas e se lhe dissermos que a visão (câmeras IP) dessas criaturas de alta tecnologia é baseada em tecnologia que tem mais de 20 anos?

Você pode acreditar nisso? Então, sente-se e prepare-se para ser surpreendido.

Nós lhe diremos como a tecnologia dos anos 90 ainda está sendo usada com sucesso hoje, por que não há nada melhor e por que você deve saber sobre ela.

Spoiler: o nome deste veterano é RTSP.

Neste artigo vamos tentar falar sobre RTSP, RTP, RTCP, como eles existem nas câmeras IP de hoje suportando HEVC (H.265), com tecnologia de análise e visão computadorizada, e como eles têm sobrevivido até hoje. Então, o que é bom e bem-sucedido em RTSP e por que não é usado na televisão?

Índice:

1. O que é RTSP e por que ele é necessário?
2. A relação entre RTSP e HTTP RTP (RTCP)
3. Relação entre RTSP, RTP, RTCP e SDP
4. Os métodos básicos do protocolo RTSP. SIP e RTSP
5. RTSP. Foi/é
6. RTSP e RTMP
7. Flussonic e RTSP

O que é RTSP e por que ele é necessário?

RTSP (Real Time Streaming Protocol) é um protocolo de camada de aplicação projetado para sistemas de telecomunicações e entretenimento para controlar a entrega de dados multimídia. O RTSP é um protocolo de sinalização, ele controla a sessão de transmissão de dados.

O RTSP foi originalmente projetado para ser usado para a entrega de televisão de entretenimento. E foi realmente por enquanto. Então, um diabo do destino decidiu o contrário: O RTSP foi apagado da face da televisão e agora só pode ser encontrado em câmeras IP.

Os princípios estabelecidos no RTSP que podemos observar no padrão moderno WebRTC.

O RTSP pode ser comparado a um controle remoto de TV. Ele pode ser usado para iniciar, pausar, parar, etc. o vídeo na TV, o servidor de mídia. E o controle não é via infravermelho, mas via Internet. A humanidade ainda não aprendeu como transmitir o conteúdo em si usando o controle remoto da TV (embora sejam nossos anos), mas é mais do que suficiente para controlá-lo.

Espere, então RTSP só gerencia o conteúdo, mas como o próprio conteúdo é transmitido?

Na camada de transporte, a RTP (Real-Time Protocol) é utilizada para transmitir o fluxo em tempo real. O papel do RTSP é equivalente ao controle remoto de um servidor de mídia streaming. Câmeras IP podem usar tanto TCP quanto UDP para transmitir o conteúdo do streaming. Entretanto, deve-se observar que a UDP não faz sentido prático para esta tarefa.

Por que não a UDP?

Por causa da falta de mecanismos modernos de compensação de perdas. Portanto, os dados são simplesmente perdidos em algum lugar ao longo do caminho. Em nossa prática, nos restringimos ao TCP, onde dados e gerenciamento de dados coexistem em um único fluxo em simbiose. Deve-se notar que tudo funciona bem.

Temos o conceito, temos o propósito em um sentido geral, também. Mas e quanto à prática?

Vamos dar um exemplo: suponha que você tenha instalado vigilância por vídeo em sua propriedade e tenha medo de que seu gravador de vídeo e todos os dados que ele contém sejam roubados, e você nunca verá as caras dos bandidos. O que fazer neste caso, não guardá-lo em um cofre? Você pode montar uma gravação de vídeo diretamente para a nuvem. Usando o protocolo RTSP, você pode enviar as informações para um serviço remoto na nuvem. Além disso, se você quiser visualizar o arquivo remotamente a partir do DVR, a comunicação com ele também será via RTSP, mas somente se o equipamento tiver suporte ao protocolo RTSP. RTSP não é mais usado para webcasting como tal (embora quais sejam seus anos, certo?), ele foi eclipsado e substituído por representantes mais jovens da tecnologia de streaming - HLS e DASH, não nos deixando nem uma sombra de chance de resistir e lutar com ele em troca.

A relação entre RTSP e HTTP RTP (RTCP)

Similitudes:

• Ambos usam texto simples para enviar mensagens, e a sintaxe do protocolo RTSP é similar à do HTTP.
• O RTSP foi originalmente projetado para ser compatível com o código de análise do protocolo HTTP previamente escrito.

Diferenças:

• RTSP salva estado. Os comandos RTSP precisam saber em que estado ĸaĸ eles se encontram no momento. Em outras palavras, os comandos RTSP são sempre enviados em ordem, cada comando seguinte vindo depois do anterior. RTSP não quebrará a conexão, não importa em que estado ela se encontre. O HTTP, por outro lado, não salva o estado. Após ĸaĸ o protocolo envia um comando, a conexão é quebrada, e não há dependência entre os comandos.
• O RTSP usa a porta 554, enquanto o HTTP usa a porta 80.
• Em comparação ao RTSP, os pedidos HTTP são enviados pelo cliente e o servidor responde. Com RTSP, tanto o cliente quanto o servidor podem enviar pedidos, o que significa que RTSP pode ser bidirecional.

Relação entre RTSP, RTP, RTCP e SDP

Vamos consolidar como RTSP, RTP, RTCP e SDP estão relacionados:

• RTP (Protocolo de Tempo Real).

Um protocolo de transmissão em tempo real. O RTP fornece carimbos de tempo, números de série e outros métodos para garantir o tempo de processamento durante as transmissões de dados em tempo real.

• RTCP (Protocolo de Controle de Transporte em Tempo Real)

Um protocolo para garantir ĸquality de serviço e controle dos participantes. RTP e RTCP são utilizados em conjunto.

• RTSP (Protocolo de Transmissão em Tempo Real).

Um protocolo para controlar a entrega de dados.

• SDP (Protocolo de Descrição de Sessão).

Um protocolo para descrever uma sessão de streaming de dados.

Os métodos básicos do protocolo RTSP. SIP e RTSP

Aqui também gostaríamos de mencionar o SIP (Session Initiation Protocol) a fim de destacar as características do RTSP e contrastá-lo com o SIP.

O SIP (Session Initiation Protocol) é semelhante ao RTSP puramente visual, mas sua lógica é muito diferente. Por exemplo, o RTSP é freqüentemente caracterizado por uma única sessão TCP, enquanto o SIP é um padrão anti-padrão.

Vamos fazer uma comparação com base no SDP. Em RTSP hoje o SDP é usado exclusivamente para descrever o conteúdo. No SIP, assim como no WebRTC (que é uma extensão do SIP), o SDP é usado para configurar portas e comunicação em rede.

Os principais métodos do RTSP estão listados abaixo:

RTSP. Foi/é

Vamos começar com um pouco de história.

A RTP juntamente com a RTCP foram desenvolvidas em 1996 e fixadas na norma [RFC 1889] (https://datatracker.ietf.org/doc/html/rfc1889). A SDP viu a luz do dia em abril de 1998 em RFC 2327. O RTSP também foi desenvolvido em abril de 1998 pela Internet Engineering Task Force (IETF) e se reflete na norma RFC 2326. Tornou-se muito popular imediatamente porque tornou possível reproduzir vídeo e áudio diretamente pela Internet sem ter que baixar o conteúdo para um dispositivo cliente. As pessoas ficaram encantadas com a quantidade de tempo e recursos que isso poderia economizar!

RTSP vem de redes onde os atrasos e perdas de entrega são pequenos em número e estáveis, ou seja, redes de área local. É também de onde vêm muitas outras soluções.

RTSP foi concebido e desenvolvido quando a tarefa de controlar a entrega ao cliente queria ser confiada ao servidor. Assim, o servidor era responsável por toda a lógica: o quê, quando e para quem enviar. Podemos dizer que o servidor tinha que ser o mais complexo possível, e o cliente - o mais simples e descomplicado possível. Quando mudamos para os protocolos HLS e DASH, a situação era exatamente a oposta. O cliente agora é mais ornamentado e o servidor é mais primitivo. Acontece que as funções de controle inteligente sobre a entrega do servidor RTSP não sobreviveram até hoje e caíram no esquecimento.

Os servidores RTSP de hoje são, em sua maioria, câmeras IP que desconhecem todas as capacidades RTSP que foram concebidas décadas atrás. Isto significa que não importa realmente se há algum feedback do cliente. Se o cliente recebe os dados - ótimo, se não recebe - bem, isso acontece, seus problemas.

Note que o RTSP foi criado junto com a telefonia. Ele foi baseado em soluções de muito sucesso já existentes no mercado, mas nós as mudamos um pouco: RTP para entrega de dados, RTCP para sinalização da qualidade da entrega de dados (QoS) e SDP para transferência de informações de conteúdo. Para dar uma idéia do sucesso dessas soluções, a mesma RTP e RTCP desenvolvidas há cerca de 25 anos são agora utilizadas da mesma forma no padrão WeRTC, que é o padrão de fato para comunicação em tempo real! Assim, mesmo naquela época, eles tinham tudo o que precisavam para se manterem à tona até agora!

Em tempos, RTSP foi o líder entre as tecnologias de streaming de vídeo e áudio. Mas com o tempo, as tecnologias baseadas em HTTP usando algoritmo de bitrate adaptativo eclipsaram RTSP e RTMP. Apesar disso, o RTSP ainda hoje é usado ativamente na vigilância por vídeo para capturar o fluxo a partir de câmeras IP.

É importante observar que RTSP para câmeras IP e para televisão são dois protocolos completamente diferentes. O mesmo RTSP para televisão só pode ser encontrado em sistemas legados que simplesmente ficam de pé e funcionam.

Desde que começamos a falar sobre RTSP, é preciso mencionar RTMP.

RTSP vs RTMP

O RTMP (Real Time Messaging Protocol) foi criado como um protocolo para transferência de funções, gerenciamento de código remoto, uma espécie de protocolo RPC, como CORBA era antes ou agora gRPC. O RTMP era bastante complexo por direito próprio. Na verdade, por mais rude que pareça, o RTMP só está vivo porque os CDNs começaram a apoiá-lo com o tempo. Hoje em dia, quase todos os CDNs dão a capacidade de transmitir vídeo sobre RTMP, mas não de reproduzi-lo. Hoje, o RTMP é apenas um protocolo de publicação, mas não um protocolo de reprodução, porque não tem vantagens sobre os atuais HLS, CMAF, etc. Antigamente, as câmeras IP viviam basicamente no codec MPEG-4 Parte 2 e a televisão tinha todas as vantagens do MPEG-2. E então todos se mudaram para MPEG-4 Parte 10, também conhecido como H.264, ou AVC. Isso mesmo, não há necessidade de ficar parado, é hora de evoluir.

Ok, os codecs foram mudados, mas e quanto ao RTSP e RTMP? Que se lixem? Bem, não há como contornar isso.

Lembre-se que o RTSP foi feito a partir de soluções já bem sucedidas: RTP, RTCP, SDP? Bem, as câmeras IP, graças à flexibilidade do SDP, sem nenhum problema ou mudança, mudaram para H.264. Da mesma forma, as câmeras IP mudaram para H.265, ou HEVC. RTMP, por outro lado, não tem sido capaz de fazer transições similares como se fossem suaves. Porque a RTMP não tem aquela superpotência de poder adicionar novos codecs, ou seja, expandir.

Como eles dizem, sobrevivência do mais apto.

Flussonic e RTSP

Os produtos de TI, que foram escritos com pressa e não da melhor maneira, a transição do UDP para o TCP foi difícil. Eles não conseguiram dominar qualitativamente o modelo de programação assíncrona. Na prática, ele é expresso na tradução do TCP-socket para o modo “non-blocking”, no qual os dados podem ser perdidos, ou seja, tentativas de software para escrever dados no socket parecem ser em vão, porque o socket está bloqueado. Como resultado, o próprio sistema operacional não aceita os dados. Acontece que o software da câmera apenas “joga fora” os dados e, como resultado, ficamos apenas uma bagunça.

Há alguma maneira de resolver este problema? Claro, como conectar a câmera IP diretamente ao servidor com um fio. Apesar de esta ser uma forma oficial de instalar câmeras (elas não foram realmente projetadas para transmitir dados pela Internet), na realidade de hoje esta parece ser uma solução ridícula e frívola.

Em Flussonic existem modos para restaurar a sincronização. Por exemplo, se a câmera chinesa perder sincronização e dados, então em Flussonic existem mecanismos especiais para recuperar bytes de informação perdidos, que permitem assim ressuscitar o fluxo de dados. Quão legal é isso? Legal!

O que você precisa para começar a obter vídeo da câmera IP em Flussonic?

Primeiro, o endereço IP da câmera. Segundo, apenas o endereço IP da câmera não é suficiente para obter vídeo da mesma. Você sempre precisa especificar outro caminho. Isto nem sempre é dado na documentação, então você pode ter que entrar em contato com o fornecedor ou com o fabricante da câmera.

Como são os links RTSP:

• rtsp://hostname/path - sintaxe;
• rtsp://user:password@ip/path - URL de autorização;
• rtsp2://hostname/path - permite a transcodificação de áudio no AAC.
• rtsp://192.168.0.100/h264 - exemplo de um link real.

Em Flussonic, entre outras coisas, você pode utilizar a opção tracks=1 para capturar apenas a pista de vídeo. O seguinte é um exemplo da configuração:

stream fake { 
    input fake://fake; 
} 
stream input_rtsp { 
    input rtsp://localhost/fake tracks=1; 
}