srt
v1.5.4
Sobre a SRT | Recursos | Primeiros passos | Instruções de construção | Exemplos de aplicativos e ferramentas | Contribua | Licença | Lançamentos
Secure Reliable Transport (SRT) é um protocolo de transporte para streaming de vídeo e áudio ao vivo com latência ultrabaixa (menos de um segundo), bem como para transferência genérica de dados em massa 1 . SRT está disponível como uma tecnologia de código aberto com o código no GitHub, um rascunho publicado na Internet e uma comunidade crescente de usuários de SRT.
O SRT é aplicado a endpoints de contribuição e distribuição como parte de um fluxo de trabalho de streaming de vídeo para fornecer vídeo de melhor qualidade e menor latência em todos os momentos.
| Seguro | Criptografa fluxos de vídeo |
| Confiável | Recupera-se de perda severa de pacotes |
| Transporte | Adapta-se dinamicamente às mudanças nas condições da rede |
Em configurações de transmissão ao vivo, o protocolo SRT mantém uma latência constante de ponta a ponta. Isto permite que as características do sinal da transmissão ao vivo sejam recriadas no lado do receptor, reduzindo a necessidade de buffer. À medida que os pacotes são transmitidos da origem ao destino, o SRT detecta e se adapta às condições da rede em tempo real entre os dois terminais. Ajuda a compensar flutuações de instabilidade e largura de banda devido ao congestionamento em redes barulhentas.
SRT implementa criptografia AES para proteger a carga útil dos fluxos de mídia e oferece vários mecanismos de recuperação de erros para minimizar a perda de pacotes típica de conexões de Internet, das quais a solicitação de repetição automática (ARQ) é o método principal. Com o ARQ, quando um receptor detecta que um pacote está faltando ele envia um alerta ao remetente solicitando a retransmissão desse pacote perdido. Forward Error Correction (FEC) e Connection Bonding, que adicionam proteção de fluxo contínua e failover sem ocorrências, também são suportados pelo protocolo.
Para saber mais sobre o protocolo assine o Blog do Innovation Labs em
Para fazer uma pergunta, participe da conversa no canal #development em 
? Clique no botão ► para expandir uma descrição de recurso.
Não importa quão pouco confiável seja sua rede, o SRT pode se recuperar de graves perdas de pacotes e instabilidade, garantindo a integridade e a qualidade de seus streams de vídeo.
A correção de erros de fluxo do SRT é configurável para acomodar as condições de implantação do usuário. Aproveitando o desenvolvimento de comunicações IP em tempo real para ampliar as práticas tradicionais de recuperação de erros de rede, o SRT fornece mídia com latência significativamente menor que o TCP/IP, ao mesmo tempo que oferece a velocidade de transmissão UDP com confiabilidade bastante aprimorada.
Ao contrário de alguns outros protocolos de streaming que suportam apenas formatos específicos de vídeo e áudio, o SRT é independente de carga útil. Como o SRT opera no nível de transporte de rede, agindo como um wrapper em torno do seu conteúdo, ele pode transportar qualquer tipo de formato de vídeo, codec, resolução ou taxa de quadros.
O processo de handshaking usado pelo SRT suporta conexões de saída sem os riscos e perigos potenciais de portas externas permanentes serem abertas em um firewall, mantendo assim as políticas corporativas de segurança da LAN e minimizando a necessidade de intervenção de TI.
Usando criptografia AES de 128/192/256 bits, confiável para governos e organizações em todo o mundo, o SRT garante que conteúdo valioso seja protegido de ponta a ponta, desde a contribuição até a distribuição, para que nenhuma parte não autorizada possa ouvir.
SRT 1.4 vê a introdução da API de filtro de pacotes . Este mecanismo permite que o processamento personalizado seja executado em pacotes de rede no lado do remetente, antes de serem enviados, e no lado do destinatário, uma vez recebidos da rede. A API permite que os usuários escrevam seu próprio plugin, ampliando ainda mais os recursos do protocolo SRT com todos os tipos de filtragem de pacotes diferentes. Os usuários podem manipular os dados resultantes do filtro de pacotes de qualquer maneira, como para criptografia personalizada, inspeção de pacotes ou acesso aos dados antes de serem enviados.
O primeiro plugin criado como exemplo do que pode ser alcançado com a API de filtro de pacotes é para Forward Error Correction (FEC) que, em certos casos de uso, pode oferecer latência um pouco menor do que Automatic Repeat reQuest (ARQ). Este plugin permite três modos diferentes:
Somente ARQ – retransmite pacotes perdidos,
Somente FEC – fornece a sobrecarga necessária para recuperação de FEC no lado do receptor,
FEC e ARQ – retransmite pacotes perdidos que o FEC não consegue recuperar.
Semelhante ao SMPTE-2022-7 em redes gerenciadas, o Connection Bonding adiciona proteção de fluxo contínua e failover sem ocorrências ao protocolo SRT. Esta tecnologia depende de mais de um caminho de rede IP para evitar interrupções nas transmissões de vídeo ao vivo em caso de congestionamento ou interrupções na rede, mantendo a continuidade do serviço.
Isso é feito usando os grupos de soquetes introduzidos no SRT v1.5. O conceito geral de grupos de soquetes significa ter um grupo que contém vários soquetes, onde uma operação para enviar um sinal de dados é aplicada ao grupo. Soquetes únicos dentro do grupo assumirão esta operação e farão o que for necessário para entregar o sinal ao receptor.
Dois modos são suportados:
Broadcast - No modo Broadcast , os dados são enviados de forma redundante por todos os links de membros de um grupo. Se um dos links falhar ou sofrer instabilidade na rede e/ou perda de pacotes, os dados ausentes serão recebidos por outro link do grupo. Pacotes redundantes são simplesmente descartados no lado do receptor.
Principal/Backup - No modo Principal/Backup , apenas um link (principal) por vez é usado para transmissão de dados, enquanto outras conexões (backup) ficam em espera para garantir que a transmissão continuará se o link principal falhar. O objetivo do modo Principal/Backup é identificar uma possível quebra de link antes que ela aconteça, fornecendo assim uma janela de tempo dentro da qual é possível alternar perfeitamente para um dos links de backup.
O Controle de Acesso permite que o aplicativo upstream atribua um Stream ID a fluxos SRT individuais. Ao usar um Stream ID exclusivo, gerado automaticamente ou personalizado, o aplicativo upstream pode enviar vários fluxos SRT para um único endereço IP e porta UDP. Os Stream IDs podem então ser usados por um receptor para identificar e diferenciar entre streams de ingestão, aplicar métodos de acesso por senha de usuário e, em alguns casos, até mesmo aplicar automação com base na nomenclatura do Stream ID. Por exemplo, a contribuição poderia ser enviada para um fluxo de trabalho de produção de vídeo e o monitoramento para um serviço de monitoramento.
Para emissoras, o Stream ID é fundamental para substituir o RTMP na ingestão de streams de vídeo, especialmente conteúdo HEVC/H.265, em serviços de nuvem ou CDNs que possuem um único soquete IP (endereço + porta) aberto para entrada de vídeo.
| A API SRT | Rascunho da Internet da IETF | Exemplos de aplicativos |
| Documentação de referência para a API da biblioteca SRT | O rascunho da Internet do protocolo SRT | Instruções para usar aplicativos de teste ( srt-live-transmit , srt-file-transmit , etc.) |
| Visão geral técnica do SRT | Guia de implantação SRT | Livro de receitas SRT |
| Visão geral técnica do rascunho inicial (precursor do rascunho da Internet) | Uma visão geral abrangente do protocolo com diretrizes de implantação | Notas de desenvolvimento no protocolo SRT |
| Blog dos Laboratórios de Inovação | Canal SRTLab no YouTube | Folga |
| O blog no Medium com artigos técnicos relacionados ao SRT | Canal técnico no YouTube com vídeos úteis | Canais do Slack para obter as atualizações mais recentes e fazer perguntas Junte-se à SRT Alliance no Slack |
Por que SRT? - Uma breve história e justificativa para SRT por Marc Cymontkowski.
RTMP vs. SRT: White Paper comparando latência e largura de banda máxima.
Documentação no GitHub com documentos da API SRT, descrições de recursos, etc.
O rascunho do protocolo SRT na Internet: Datatracker | Versão mais recente | Última cópia de trabalho | Repositório GitHub
Linux (Ubuntu/CentOS) | Janelas | macOS | iOS | Android | Gerenciadores de pacotes
Compilador compatível com C++ 03 ou superior.
CMake 2.8.12 ou superior como sistema de compilação.
OpenSSL 1.1 para ativar a criptografia, caso contrário, construa com -DENABLE_ENCRYPTION=OFF .
Multithreading é fornecido por um dos seguintes:
C++ 11: biblioteca padrão ( std by -DENABLE_STDCXX_SYNC=ON opção CMake),
C++03: Pthreads (para sistemas POSIX está integrado, para Windows existe uma biblioteca portada).
Tcl 8.5 é opcional e é usado pelo script ./configure . Caso contrário, use o CMake diretamente.
Para descrições detalhadas do sistema de compilação e opções, leia o documento SRT Build Options.
O repositório atual fornece exemplos de aplicativos e códigos que demonstram o uso da API da biblioteca SRT. Entre eles estão srt-live-transmit , srt-file-transmit e outros aplicativos. A respectiva documentação pode ser encontrada aqui. Observe que todos os exemplos são fornecidos para fins instrucionais e não devem ser usados em um ambiente de produção.
O utilitário srt-xtransmit é usado ativamente para testes internos e avaliação de desempenho. Entre outros recursos, ele suporta geração de carga útil fictícia, roteamento de tráfego e ligação de conexão. Detalhes adicionais estão disponíveis no próprio repositório srt-xtransmit .
As ferramentas Python que podem ser úteis durante o desenvolvimento são:
srt-stats-plotting - Um script projetado para traçar gráficos com base em estatísticas SRT .csv .
lib-tcpdump-processing - Uma biblioteca projetada para processar arquivos de rastreamento .pcap(ng) tcpdump ou Wireshark e extrair pacotes SRT de interesse para análise posterior.
lib-srt-utils – Uma biblioteca Python contendo código de suporte para execução de testes SRT com base em uma configuração experimental.
Qualquer pessoa é bem-vinda para contribuir. Se você decidir se envolver, reserve um momento para revisar as diretrizes:
Guia do desenvolvedor SRT
Contribuindo
Relatando problemas
Para obter informações sobre como contribuir para o Internet Draft ou para enviar problemas, acesse o repositório a seguir. O repositório para contribuir no SRT CookBook pode ser encontrado aqui.
Ao contribuir com código para o projeto SRT, você concorda em licenciar sua contribuição sob a Licença MPLv2.0.
Notas de lançamento
Controle de versão SRT
O termo “streaming ao vivo” refere-se à transmissão contínua de dados (MPEG-TS ou equivalente) com gerenciamento de latência. A transmissão ao vivo baseada na segmentação e transmissão de arquivos como no protocolo HTTP Live Streaming (HLS) (conforme descrito em RFC8216) não faz parte deste caso de uso. A transmissão de arquivos em modo mensagem ou buffer deve ser considerada neste caso. Consulte a Seção 7. Melhores práticas e dicas de configuração para transmissão de dados via SRT do Internet Draft para obter detalhes. Observe que o SRT é independente de conteúdo, o que significa que qualquer tipo de dado pode ser transmitido por meio de sua carga útil. ↩
