Protocolos de transmissão¶

Como levar um fluxo de um nó para outro ou para equipamentos de terceiros. Aqui: qual protocolo escolher, quanto ele custa em largura de banda e latência, quais portas ocupa e como é criptografado.

Se falha não o canal, mas a fonte, a rede ou o nó — Redundância: o que protege contra o quê.

Protocolos Peer de transmissão confiável¶

Para a transmissão entre o emissor e o receptor estão disponíveis quatro protocolos Peer. Eles se dividem em duas classes segundo o princípio de compensação de perdas:

ARQ (Automatic Repeat reQuest) — os pacotes perdidos são retransmitidos por solicitação do receptor. Requer um canal de retorno e um buffer no receptor; a profundidade de recuperação é configurável. A esta classe pertencem PS1, SRT e RIST.
FEC (Forward Error Correction) — ao fluxo são adicionados continuamente dados redundantes que permitem recuperar as perdas sem canal de retorno. A esta classe pertence o Pro-MPEG COP3/RTP+FEC (SMPTE 2022-1/2).

PS1 (Perfect Stream)¶

Um protocolo próprio, baseado em UDP. Funciona segundo o princípio ARQ com retransmissão seletiva. Distingue-se pelo baixo consumo de recursos e transporta fluxos de alta taxa de bits, incluindo um MPTS completo.

Conexão. O receptor inicia a conexão, por isso o NAT do lado dele não é obstáculo e não é necessário encaminhar portas no receptor. O emissor admite o receptor como Peer — por login e senha ou por IP.
Latência — o buffer do receptor: a janela de eliminação de jitter e de retransmissão. O buffer do emissor deve ser maior que os buffers dos receptores (latência).
A troca de fonte no emissor não interrompe a conexão: a lacuna é coberta pela retransmissão normal.

O PS1 é um protocolo proprietário e funciona apenas entre nós Perfect Streamer. É mais adequado para uma configuração ponto-multiponto: um emissor e muitos receptores.

SRT¶

Um protocolo aberto baseado em UDP (derivado do protocolo UDT). É amplamente difundido e compensa bem a perda de pacotes. Suporta os modos listener e caller, o que proporciona compatibilidade com equipamentos SRT de terceiros e serviços em nuvem.

No modo listener no emissor, vários receptores se conectam a um mesmo fluxo; para a autorização, os receptores são registrados como Peer, e está disponível a autorização por IP. A parte iniciadora (caller) pode estar tanto no receptor quanto no emissor. A margem de largura de banda para a retransmissão é definida em porcentagem acima da taxa de bits do fluxo.

Em um nó de recepção com um grande número de entradas SRT em modo caller, é possível desativar o buffer do receptor SRT (TSBPD, entrega pelas marcas de tempo do emissor): a sincronização passa para o buffer de jitter do nó (Sincronização), e a carga de CPU cai sensivelmente.

RIST¶

Um protocolo aberto baseado em RTP/RTCP. Funciona segundo o princípio ARQ por NACK: o receptor informa apenas as perdas. Utiliza unicast e multicast.

São implementados os perfis Simple e Main: Simple ocupa duas portas UDP consecutivas (a porta base deve ser par), Main multiplexa os dados em uma única porta. São suportados vários caminhos (peers) com balanceamento ponderado — para redundância e agregação. Em multicast pode haver muitos receptores, com autorização por IP.

Pro-MPEG FEC¶

Entrega de MPEG-TS sobre RTP com correção antecipada de erros (FEC), sem canal de retorno. No Perfect Streamer está implementada uma matriz FEC bidimensional (linhas e colunas, SMPTE 2022-2).

O fluxo de pacotes RTP é agrupado em uma matriz de tamanho definido, e os pacotes FEC são formados pelas suas linhas e colunas. Quanto menor a matriz, melhor a recuperação, mas maior a sobrecarga constante. Os canais FEC ocupam duas portas adicionais (port+2 e port+4), o que deve ser considerado ao colocar vários fluxos em um mesmo host ou em um mesmo grupo multicast.

As vantagens são a baixa latência fixa e a compatibilidade com equipamentos de radiodifusão profissionais. As desvantagens são o tráfego adicional constante e a fraca recuperação em grandes perdas (acima de ~0,2 %), por isso o protocolo é destinado a canais gerenciados com baixas perdas e não à internet pública «pesada».

Importante

Versão beta 2.1. O que está descrito aqui existe apenas na versão beta 2.1: ela é instalada a partir do repositório beta e somente com uma licença; a versão estável 2.0.2 e a versão de demonstração não têm isso. A versão beta é fornecida sem garantias, e o suporte é prestado na medida do possível (Programa de testes beta).

Na versão 2.1, o FEC de entrada e de saída segue o SMPTE ST 2022-1:

os receptores padrão recuperam as perdas por ele;
a entrada aceita FEC só por colunas (1D) e por colunas e linhas (2D), com uma matriz de qualquer tamanho;
a saída pode enviar apenas FEC por colunas: com uma matriz 5 × 10, a sobrecarga é de 10 % em vez de 30 %, mas a recuperação é mais fraca;
O Pro-MPEG pode ser combinado com o segundo caminho SMPTE ST 2022-7 e com a reserva a quente das saídas (Redundância: o que protege contra o quê).

Latência da espera pelo FEC — Planejamento da largura de banda, da latência e das portas.

Escolha do protocolo de transmissão¶

Em resumo.

um canal entre nós Perfect Streamer, alta taxa de bits ou MPTS completo, distribuição ponto-multiponto — PS1;
compatibilidade com equipamentos de terceiros ou a nuvem, margem de retransmissão em porcentagem acima da taxa de bits — SRT;
um transporte aberto baseado em RTP, multicast, balanceamento por vários caminhos — RIST;
um canal gerenciado com baixas perdas, latência mínima sem canal de retorno, equipamentos de radiodifusão profissionais — Pro-MPEG FEC.

Em detalhes:

Protocolo	Princípio	Canal de retorno	Latência	Compatibilidade
PS1	ARQ sobre UDP	necessário	configurável	apenas entre nós Perfect Streamer
SRT	ARQ sobre UDP (UDT)	necessário	configurável	aberto; equipamentos SRT de terceiros e nuvem
RIST	ARQ (NACK) sobre RTP/RTCP	necessário	configurável	aberto; equipamentos RIST de terceiros; unicast e multicast
Pro-MPEG FEC	FEC sobre RTP	não necessário	baixa, fixa	aberto (SMPTE 2022-1/2); equipamentos de radiodifusão profissionais

Planejamento da largura de banda, da latência e das portas¶

Protocolos ARQ (PS1, SRT, RIST). As perdas são compensadas por retransmissão, por isso é preciso prever:

um canal de retorno do receptor ao emissor;
uma margem de largura de banda acima da taxa de bits nominal — picos de perdas causam picos de tráfego de retransmissão;
um buffer no receptor para a latência do canal. Quanto maior o buffer, mais profunda a recuperação de perdas, mas maior a latência de ponta a ponta; como referência, vários valores de RTT. Fluxos de baixa taxa de bits exigem um buffer maior em tempo, para que caibam pacotes suficientes na janela de recuperação.

Protocolo FEC (Pro-MPEG). Os pacotes redundantes são transmitidos continuamente, independentemente das perdas reais, por isso a sobrecarga é fixa e depende do tamanho da matriz FEC. Não é necessário canal de retorno, a latência é baixa e fixa, mas a recuperação é limitada, por isso este transporte é indicado para canais com baixas perdas. A recuperação por FEC acrescenta latência na recepção: enquanto um pacote perdido espera o FEC da sua matriz, a entrada atrasa a saída dos dados. Quanto maior a matriz e menor a taxa de bits, mais longa é a espera — com uma matriz grande e uma taxa de bits baixa, são segundos, e o buffer de jitter da entrada deve cobri-los (limite de espera FEC).

Portas. Cada ponto de escuta precisa de uma porta UDP única dentro do host ou do grupo. Além disso, leve em conta que o perfil RIST Simple ocupa duas portas consecutivas (a porta base par e a seguinte), e o Pro-MPEG ocupa a porta base mais duas portas FEC (port+2 e port+4). Em uma rede Meshwork, um catálogo comum de endereços e portas ocupados ajuda a evitar colisões (ver Meshwork).

Criptografia de fluxos¶

A criptografia AES é ativada por uma frase-senha comum, definida em ambos os lados da conexão; as frases devem coincidir. Uma frase vazia significa funcionamento sem criptografia. A criptografia não altera o bitrate do fluxo.

O suporte e o comprimento permitido da frase variam conforme o protocolo:

Protocolo	Comprimento da frase-senha	Particularidades
PS1	10–64 bytes	—
SRT	10–79 bytes	Além disso, escolhe-se o comprimento da chave: 128, 192 ou 256 bits. Uma frase fora do comprimento permitido interrompe a entrada ou a saída com uma mensagem de erro explícita.
RIST	não é verificado; são usados os primeiros 127 bytes	Somente no perfil Main. No perfil Simple a frase-senha não tem efeito.
Pro-MPEG	10–64 bytes	Extensão não padronizada: quando ativada, a compatibilidade com software e equipamentos de terceiros não é garantida.

O comprimento da frase é contado em bytes, não em caracteres: uma letra cirílica ocupa dois bytes.

Outras entradas e saídas¶

Além dos protocolos Peer, estão disponíveis transportes padrão para recepção e transmissão:

Protocolo	Entrada	Saída	Observação
UDP	sim	sim	unicast/multicast, SSM, seleção de interface; até 7 pacotes TS por datagrama
RTP	sim	sim	restabelecimento da ordem dos pacotes desordenados
TCP	sim	—	modo cliente; recepção onde o UDP está bloqueado
HLS / HTTP	sim	sim	entrada apenas para SPTS; da lista de reprodução adaptativa é tomada a variante pelo número (a primeira, por padrão)
RTSP	sim	—	câmeras IP e servidores RTSP; auto-remux para MPEG-TS; apenas para SPTS
RTMP / RTMPS	sim	sim	publicação em receptores RTMP de terceiros; H.264 e HEVC; apenas para SPTS
file / device	sim	sim	gravação em arquivo TS e saída MPEG-TS para um dispositivo (por exemplo, ASI); reprodução em loop a partir de um arquivo
pipe (FIFO)	sim	sim	ponte para um processo externo através de um canal nomeado
std (aplicação externa)	sim	sim	ponte para protocolos não padronizados através de uma aplicação de console

A publicação e a recepção de RTMP são descritas em Publicação e recepção RTMP; RTSP, entrada HLS/HTTP, arquivos e dispositivos, canais nomeados e aplicações externas estão em Outras entradas e saídas. As configurações detalhadas de cada transporte estão na seção Interface web. A distribuição OTT (HLS, LL-HLS, DASH) é descrita separadamente em OTT e DVR.

Requisitos do fluxo de entrada¶

Conformidade com ISO/IEC 13818-1, Single Program (SPTS) ou Multi Program Transport Stream (MPTS).
A composição das faixas depende do tipo de conteúdo selecionado do fluxo SPTS, ver Fluxos SPTS.
Fluxos embaralhados são suportados, ver Fluxos SPTS.
Para a sincronização, o fluxo deve conter marcas PCR válidas.

A filtragem, a modificação e os modos de taxa de bits do fluxo de entrada são descritos em Fluxos SPTS, e as particularidades da multiplexação em Fluxos MPTS.