---
title: Planejamento e protocolos de transmissão de dados
url: https://doc2.pstreamer.tv/pt/manual/planning/index.html
lang: pt-BR
product: Perfect Streamer
version: 2.0.2.362
---

# 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](../webui/index.md#webui)), e o processamento do fluxo em um nó na seção [Streamer: detalhes de implementação](../streamer/index.md#streamer).

## 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](../streamer/spts.md#streamer-spts-sync)), 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](../meshwork/index.md#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](../streamer/rtmp.md#streamer-rtmp); RTSP, entrada HLS/HTTP, arquivos e dispositivos, canais nomeados e aplicações externas estão em [Outras entradas e saídas](../streamer/other_io.md#streamer-other-io). As configurações detalhadas de cada transporte estão na seção [Interface web](../webui/index.md#webui). A distribuição OTT (HLS, LL-HLS, DASH) é descrita separadamente em [OTT e DVR](../streamer/ott_dvr.md#streamer-ott-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](../streamer/spts.md#streamer-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](../streamer/spts.md#streamer-spts).
- Fluxos embaralhados (codificados) são suportados, ver [Fluxos SPTS](../streamer/spts.md#streamer-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](../streamer/spts.md#streamer-spts), e as particularidades da multiplexação em [Fluxos MPTS](../streamer/mpts.md#streamer-mpts).