Planejamento e protocolos de transmissão de dados¶

O núcleo do Perfect Streamer é a entrega confiável de fluxos MPEG-TS entre nós através de uma rede pública com perda de pacotes e atrasos. Esta seção descreve o modelo de transmissão, os protocolos de transporte e como planejar um canal: escolher um protocolo e calcular a largura de banda, a latência e as portas. As configurações detalhadas de cada campo são tratadas na descrição contextual da interface web (Interface web), e o processamento do fluxo em um nó na seção Streamer: detalhes de implementação.

Modelo de transmissão: Stream, Sender, Receiver, Peer¶

A unidade de trabalho é um fluxo (Stream), um único canal MPEG-TS. Para cada fluxo configura-se um servidor emissor (Sender) e um ou mais receptores (Receiver); a associação emissor-receptor é designada por Peer.

A configuração se resume a listas de entradas (input) e saídas (output) para cada fluxo:

no emissor, input são as fontes MPEG-TS, output é a transmissão para os receptores;
no receptor, input é a recepção do fluxo do emissor.

Várias entradas na lista fornecem redundância de fontes, várias saídas fornecem a distribuição simultânea de um mesmo canal a muitos destinatários e por diferentes protocolos.

Para os protocolos em que o receptor inicia a conexão, um receptor atrás de NAT conecta-se sozinho ao emissor — não é necessário o encaminhamento de portas de entrada do seu lado.

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 a pedido do receptor. Requer um canal de retorno e um búfer 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 Pro-MPEG / RTP+FEC.

PS1 (Perfect Stream)¶

Um protocolo de desenvolvimento 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.

O receptor inicia a conexão, por isso o emissor exige autenticação: os receptores são registrados como Peer com login e senha ou são autorizados por IP. A latência é determinada pelo búfer do receptor (janela de eliminação de jitter e de retransmissão); o búfer do emissor deve ser maior que o dos receptores. Ao trocar a fonte ativa no emissor, os receptores não se reconectam — a interrupção é recuperada por retransmissão normal, sem reconexão visível.

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

SRT¶

Um protocolo aberto baseado em UDP (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 nós de recepção densos, com um grande número de entradas SRT em modo caller, é possível desativar a bufferização interna do receptor SRT (TSBPD): a sincronização passa a ser assumida pelo búfer de jitter do nó (Sincronização), o que reduz sensivelmente a carga de CPU.

RIST¶

Um protocolo aberto baseado em RTP/RTCP. Funciona segundo o princípio ARQ sem ACK, apenas por NACK, o que garante alta eficiência. 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. Suportam-se 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 / RTP+FEC (SMPTE 2022-1/2)¶

Entrega de MPEG-TS sobre RTP com correção antecipada de erros (FEC), sem canal de retorno. O protocolo é conhecido também como Pro-MPEG COP3. No PSS está implementada uma matriz FEC bidimensional (linhas e colunas, SMPTE 2022-2).

O fluxo de pacotes RTP é agrupado em uma matriz de tamanho definido, ao longo de cujas linhas e colunas são formados os pacotes FEC. 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».

Escolha do protocolo de transmissão¶

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 / RTP+FEC	FEC sobre RTP	não necessário	baixa, fixa	aberto (SMPTE 2022-1/2); equipamentos de radiodifusão profissionais

Referências de escolha:

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, configuração flexível da margem de retransmissão — 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 / RTP+FEC.

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 búfer no receptor para a latência do canal. Quanto maior o búfer, 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 búfer maior em tempo, para que caibam pacotes suficientes na janela de recuperação.

Protocolo FEC (Pro-MPEG / RTP+FEC). 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 — este transporte é para canais com baixas perdas.

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¶

Todos os protocolos Peer suportam criptografia AES usando uma frase-senha comum inserida em ambos os lados. Para SRT seleciona-se adicionalmente o comprimento da chave (128, 192 ou 256 bits). A criptografia não altera a taxa de bits do fluxo.

Para Pro-MPEG, a criptografia é uma extensão não padronizada, por isso, quando ativada, a compatibilidade com software e equipamentos de terceiros não é garantida.

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	na recepção, a variante da lista de reprodução adaptativa é selecionada por um número configurável (a primeira, por padrão); entrada apenas para SPTS
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 para um dispositivo (incluindo SDI); 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.

Redundância de fontes e distribuição¶

Redundância. Para um fluxo é possível definir várias entradas; apenas uma fica ativa de cada vez. Em caso de falha da entrada ativa, o fluxo alterna automaticamente para a próxima da lista e, ao ser restabelecida, pode voltar à fonte prioritária. Isso permite planejar antecipadamente as fontes principal e de reserva de um canal; as configurações detalhadas da comutação de entradas são descritas em Fluxos SPTS.

Distribuição. Várias saídas em um mesmo fluxo permitem distribuir um mesmo canal a muitos destinatários de uma só vez e por diferentes protocolos simultaneamente.

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 (codificados) 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.