Documentação do usuário¶
Planejamento e protocolos de transmissão de dados¶
O programa Perfect Streamer destina-se à transmissão de fluxos MPEG-TS pela Internet pública com perdas de pacotes e latência, sobre UDP.
Para cada fluxo MPEG-TS (Stream) configura-se um servidor transmissor (Sender) e um ou mais receptores (Receiver); este emparelhamento é doravante designado por Peer.
A configuração do transmissor e receptor resume-se à entrada de uma lista de fluxos (Stream) e às configurações para cada Stream da lista de input e output. Vários input na lista garantem redundância de fontes. Vários output na lista permitem transmitir os fluxos para diferentes destinatários ao mesmo tempo.
No transmissor, input designa as fontes dos fluxos MPEG-TS e output a entrega dos fluxos aos receptores. Nos receptores, input designa a recepção dos fluxos dos transmissores.
Arquitetura geral do fluxo SPTS: entradas, processamento a nível de stream (comutador de entrada, filtro TS, analisador, sincronizador), OTT / DVR e saídas. Os detalhes de cada bloco encontram-se nas secções seguintes.¶
Estão disponíveis quatro protocolos Peer para o transporte de fluxos entre o transmissor e o receptor:
Protocolo Perfect Stream (PS1).
SRT.
Pro-MPEG / RTP+FEC.
RIST.
Protocolo PS1¶
O protocolo PS1 funciona pelo princípio Automatic Repeat reQuest (ARQ). É leve em recursos e permite transmitir fluxos com alta taxa de bits.
No transmissor — configurado em output. Apenas uma instância está disponível para um stream. É necessário registrar em Peer os logins dos receptores. Define-se a UDP listen port, que deve ser única para cada stream.
No receptor — configura-se no input. Especifica-se o host e a porta do transmissor, além de login e senha.
Há criptografia de fluxos disponível (Crypto protection) usando AES-128. Para ativar em ambos os lados, informe Crypt Passphrase como chave compartilhada.
Em funcionamento, o receptor (cliente) envia suas estatísticas ao transmissor (servidor). É possível consultá-las na seção Peers ao selecionar o cliente.
A latência do fluxo e a capacidade de corrigir perdas dependem das configurações do receptor (cliente):
Round Trip Time — RTT em ms, padrão 300. Latência estimada (ping) do canal. Após iniciar o fluxo, o RTT real aparece nas estatísticas (PS1 recovery delay).
Client Latency (RTT multiplexor) — multiplicador do RTT (padrão 10) que define a latência do fluxo no buffer do emissor; no padrão dá 3000 ms.
No lado do emissor há o ajuste de latência (tamanho do buffer) Latency (ms). Ele deve ser maior do que as latências configuradas nos clientes.
A capacidade do protocolo de compensar perdas é determinada pelo número de solicitações de retransmissão e depende de Client Latency (RTT multiplexor). Grandes perdas geram tráfego adicional na rede. Para reduzir a latência convém ajustar esses parâmetros com mais detalhe.
Para conferir o funcionamento correto do protocolo, veja as estatísticas do cliente. PS1 recovery: Not found → aumentar o buffer do emissor; Duplicates → aumentar o RTT.
Ao comutar a entrada do fluxo (troca de fonte) no transmissor, a fila de envio pode crescer brevemente. O PS1 lida com isso de forma suave: os pacotes mais antigos são descartados silenciosamente, enquanto a numeração (seqID) e as marcas de tempo nos receptores permanecem contínuas — os receptores recuperam as perdas pelo mecanismo regular de retransmissão (retr), sem reinicializar a conexão. O número de pacotes descartados dessa forma é visível nas estatísticas estendidas da saída PS1.
Since the connection is initiated from the side of the receiver, the transmitter requires authentication, the receivers are registered in the peers section. Login and password required.
Protocolo SRT¶
Protocolo aberto desenvolvido pela Haivision. Baseado no UDT; é amplamente difundido e oferece boas características de compensação de perdas de pacotes.
Casos de uso:
Peer entre instâncias do Perfect Streamer. No transmissor — é configurado no output, modo listen (padrão). Para um stream, só pode ser definido um output desse tipo. Nesse modo podem ser conectados vários receptores. Para a autorização, devem ser registrados em Peer os logins dos receptores. No receptor — é configurado no input. São indicados o host e a porta do transmissor, bem como login e senha. Para transmitir login e senha, o streamer SRT usa o streamid no formato
login|password.Peer entre o Perfect Streamer e quaisquer streamers SRT de terceiros. No transmissor é possível configurar o modo cliente SRT desativando o listen. O streamid SRT, se necessário, é inserido no campo login. Para o modo listen está disponível a autorização por endereço IP — inserida no campo login em Peer. No receptor é possível ativar o modo listen, definir o streamid SRT no campo login e também indicar o host a partir do qual a recepção é permitida.
Trabalho no modo Listener: recepção e transmissão do fluxo do canal com indicação da porta de recepção.
As portas em modo listen devem ser únicas.
Há criptografia de fluxos disponível (Crypto protection) usando AES-128. Para ativar em ambos os lados, informe Crypt Passphrase como chave compartilhada.
Se o transmissor usa o modo listen (padrão), a iniciação da conexão acontece do lado do receptor, o transmissor exige autenticação e os receptores são registrados em peer. Login e senha são obrigatórios.
As opções do protocolo SRT seguem a descrição em API-socket-options.md
Reorder (SRTO_LOSSMAXTTL) — Valor até o qual a tolerância de reordenamento pode aumentar. A tolerância de reordenamento é o número de pacotes que devem seguir uma «lacuna» detectada nos números de sequência dos pacotes recebidos antes que um relatório de perda seja enviado (na esperança de que a lacuna seja causada por reordenamento de pacotes e não por perda). O valor da tolerância de reordenamento começa em 0 e aumenta quando o reordenamento de pacotes é detectado. Isso ocorre quando um pacote «atrasado» é recebido com um número de sequência maior que o do último recebido, mas sem o sinalizador de retransmissão. Diante de tal detecção, a tolerância de reordenamento é definida como o valor do intervalo entre o último número e o número de sequência desse pacote, mas não superior ao valor definido pelo parâmetro SRTO_LOSSMAXTTL. Por padrão, esse valor é 0, o que significa que esse mecanismo está desativado. SRTO_LOSSMAXTTL
Overhead (SRTO_OHEADBW, %) — Sobrecarga para recuperação de banda além da taxa de entrada (ver SRTO_INPUTBW), em percentual da taxa de entrada. Atua somente se SRTO_MAXBW estiver definido como 0. Remetente: configurável pelo usuário; padrão: 25%.
Recomendações: a sobrecarga destina-se a fornecer banda adicional para o caso de um pacote ter ocupado parte da banda mas ter sido perdido e precisar ser retransmitido. Portanto, a banda máxima efetiva deve ser suficientemente maior do que o bitrate do fluxo para deixar espaço para retransmissões, mas limitada para que os pacotes retransmitidos não levem a um aumento abrupto no uso da banda quando grandes grupos de pacotes forem perdidos. Não defina um valor muito baixo e evite 0 caso o parâmetro SRTO_INPUTBW esteja definido como 0 (automático). Caso contrário, seu fluxo será rapidamente interrompido em qualquer aumento de perda de pacotes. SRTO_OHEADBW
Max Band (SRTO_MAXBW, bps) — Esta opção é efetiva apenas quando SRTO_MAXBW é igual a 0 (relativo). Ela controla a banda máxima em conjunto com o parâmetro SRTO_OHEADBW pela fórmula: MAXBW = INPUTBW * (100 + OHEADBW) / 100. Se esta opção for definida como 0 (automático), o valor real de INPUTBW será estimado com base na taxa do fluxo de entrada (casos em que a aplicação chama a função srt_send*) durante a transmissão. O valor mínimo admissível da estimativa é limitado pelo parâmetro SRTO_MININPUTBW, ou seja, INPUTBW = MAX(INPUTBW_ESTIMATE; MININPUTBW).
Recomendações: defina nesse parâmetro o bitrate esperado da sua transmissão e mantenha o valor padrão de 25% para SRTO_OHEADBW. SRTO_INPUTBW
Timeout (SRTO_CONNTIMEO, ms) — Valor do timeout de conexão em milissegundos. É o tempo durante o qual o objeto que está se conectando tentará estabelecer conexão e aguardará resposta do endpoint remoto antes de encerrar a conexão com código de erro. SRTO_CONNTIMEO
Protocolo Pro-MPEG / RTP+FEC (COP3 / SMPTE 2022-1/2)¶
Entrega de MPEG-TS sobre RTP com correção antecipada de erros (FEC, Forward Error Correction). O mesmo protocolo aparece na literatura e nos equipamentos sob diferentes nomes:
Pro-MPEG / Pro-MPEG COP3 — Code of Practice #3 do fórum Pro-MPEG, descrito no padrão IEEE (https://ieeexplore.ieee.org/document/6738329);
RTP + FEC — nome funcional (fluxo RTP mais canais FEC);
SMPTE 2022-1 — Column FEC (mesmo esquema, publicado como padrão SMPTE);
SMPTE 2022-2 — Row + Column FEC (matriz bidimensional, implementada em PSS).
Vantagem: baixa latência. Sua desvantagem é o alto tráfego adicional (overhead), e funciona mal com perdas de pacotes elevadas (acima de 0,2 %).
Este protocolo é baseado em RTP com a adição de 2 canais para FEC (código de correção de erros). Os dois canais FEC usam as portas port+2 e port+4, o que deve ser levado em conta ao adicionar vários fluxos em um mesmo host ou grupo multicast.
No emissor, o fluxo de pacotes RTP é agrupado em uma matriz com Cols colunas e Rows linhas. Exemplo para cols=8 e rows=4 (padrão):
RTP01 |
RTP02 |
RTP03 |
RTP04 |
RTP05 |
RTP06 |
RTP07 |
RTP08 |
R1 |
RTP11 |
RTP12 |
RTP13 |
RTP14 |
RTP15 |
RTP16 |
RTP17 |
RTP18 |
R2 |
RTP21 |
RTP22 |
RTP23 |
RTP24 |
RTP25 |
RTP26 |
RTP27 |
RTP28 |
R3 |
RTP31 |
RTP32 |
RTP33 |
RTP34 |
RTP35 |
RTP36 |
RTP37 |
RTP38 |
R4 |
C1 |
C2 |
C3 |
C4 |
C5 |
C6 |
C7 |
C8 |
Os pacotes Rx e Cx formam os dados para FEC por linhas e colunas. Quanto menor o tamanho da matriz, melhor a capacidade de corrigir perdas, mas maior o tráfego adicional. Neste exemplo, há 12 pacotes FEC para cada 32 pacotes RTP do fluxo.
Há criptografia de fluxos disponível (Crypto protection) com AES-128, mas não consta do padrão, portanto a compatibilidade com software ou hardware de terceiros não é garantida.
Existem extensões não padronizadas do protocolo:
Multiplexing — multiplexação de canais RTP por meio de uma única porta UDP. Pode simplificar a configuração da rede.
Protocolo RIST¶
Novo protocolo aberto baseado em RTP/RTCP. Funciona pelo princípio Automatic Repeat reQuest (ARQ) sem ACK, apenas NACK, o que garante alta eficiência.
Usa unicast e multicast.
Estão implementados os perfis Simple e Main. Simple usa duas portas UDP consecutivas — a porta configurada deve ser par. Main usa uma única porta RTP com multiplexação de dados.
On transmitter — configura-se em output. Para unicast são configurados o endereço e a porta do receptor. Para multicast é necessário indicar a interface de rede pela qual os dados serão transmitidos. Para multicast também é possível configurar a autorização dos receptores por endereço IP registrando os logins em Peer.
No receptor — configura-se no input. Para unicast define-se a porta de recepção (listen) e obrigatoriamente a interface de rede. Para multicast indica-se apenas o grupo multicast e a porta.
O RIST suporta vários peers (endereços) separados. Com peso maior que 1 ativa-se o balanceamento de carga entre peers conforme o peso.
Se o transmissor usa multicast, pode haver muitos receptores. Nesse caso, é possível autenticar os receptores por endereço IP. Para isso, ative a autenticação nas configurações do transmissor (desativada por padrão) e adicione o cliente à lista de peers; no campo login, informe o endereço IP.
Outros protocolos¶
Além dos protocolos peer, existem outros para receber e transmitir fluxos:
Protocol |
Input |
Output |
|---|---|---|
UDP |
Yes |
Yes |
RTP |
Yes |
Yes |
TCP |
Yes |
No |
HLS |
Yes |
Yes |
RTSP |
Yes |
No |
pipe |
Yes |
Yes |
UDP (unicast ou multicast) — recepção e envio de MPEG-TS em pacote UDP, até 7 pacotes TS por UDP.
RTP (unicast ou multicast) — protocolo padrão baseado em RFC. Suportada a recuperação de pacotes reordenados.
TCP — recepção de MPEG-TS em conexão TCP, modo cliente TCP.
HLS — recepção e entrega de MPEG-TS sobre HTTP ou o protocolo HLS padrão da Apple. Na recepção, é selecionada a variante de maior taxa de bits da playlist adaptativa. HLS input só está disponível para fluxos SPTS; para MPTS utilize UDP / RTP / TCP / file ou um adaptador DVB.
RTSP — recepção de fluxo de vídeo a partir de fontes RTSP (câmaras IP, servidores RTSP) baseada no FFmpeg avformat. O PSS abre uma sessão RTSP (DESCRIBE → SETUP → PLAY), lê os pacotes ES, faz o remux para um MPEG-TS interno e injeta no pipeline do fluxo. O BSF Annex B (h264_mp4toannexb / hevc_mp4toannexb) é ativado automaticamente. Se a fonte não contiver faixas de áudio, é adicionada uma faixa MPEG-1 Layer 2 silenciosa (48 kHz, estéreo, 128 kbps) com PTS sincronizado ao vídeo — isto é necessário para a compatibilidade com o pipeline do fluxo, que exige pelo menos uma faixa de áudio.
Definições da entrada RTSP:
URI — o URL completo da sessão RTSP, por exemplo
rtsp://cam.local/play1.sdp.Login, Password — credenciais RTSP, caso seja necessária autenticação basic / digest.
User-Agent — User-Agent personalizado (opcional).
Cookies — cabeçalho
Cookie(opcional, para servidores com autenticação baseada em cookies).Transport — transporte RTP dentro do RTSP:
UDP— RTP sobre UDP (baixa latência, sensível a perdas);TCP(por omissão) — RTP intercalado na sessão TCP do RTSP; atravessa NAT e firewalls;HTTP— túnel RTSP-over-HTTP, para travessia de proxies apenas HTTP.
Timeout — tempo-limite de abertura e leitura em segundos. Valor por omissão: 10.
Trace — registo detalhado para diagnóstico.
A entrada RTSP é executada no mesmo processo do PSS e não requer binário externo. A alternativa via std + ffmpeg / gstreamer (ver FAQ) permanece disponível e é útil para protocolos que o RTSP integrado não cobre (por exemplo, RTMP).
A entrada RTSP é uma fonte single-program e, por isso, está disponível apenas para fluxos SPTS.
pipe — leitura de e escrita para um named pipe (FIFO) existente. Ao contrário do std, o PSS não cria um processo filho — o produtor / consumidor externo deve ser iniciado de forma independente e manter o pipe aberto do seu lado. Nas definições, File Path indica o caminho para um FIFO já existente (criado, por exemplo, pelo comando mkfifo). O PSS abre o FIFO em modo leitura (para input) ou escrita (para output). Disponível para SPTS e MPTS.
Fluxos com arquivos e dispositivos¶
Para input e output está disponível o protocolo file/device para arquivos e dispositivos.
output file/device — gravação em arquivo ou saída para dispositivo. A gravação em arquivo pode ser necessária para registrar em ts-file e posterior diagnóstico por outros analisadores. Saída para dispositivo — qualquer dispositivo (incluindo SDI) registrado em /dev.
input file/device — reprodução cíclica do vídeo de um arquivo TS.
- Ao trabalhar com arquivos, indique o caminho completo do arquivo no campo File Path:
/catalog/stream.ts.
Ao trabalhar com dispositivos, ative também o indicador Is Device.
Lista de fluxos permitidos e restrição do peer¶
Para possibilitar a restrição de acesso aos fluxos de canais de TV no lado do cliente (Peer) nos modos SRT Listen, PS1, HLS e HTTP, o programa implementa a funcionalidade de lista de fluxos permitidos. Nas configurações do Peer no transmissor define-se a lista de canais disponíveis. Para isso, no campo Stream Access devem ser adicionados, da lista geral de canais do servidor, apenas aqueles destinados a este Peer. Por padrão, com lista vazia, todos os canais ficam disponíveis.
Para um Peer estão disponíveis limites de tempo e número de conexões por protocolo de transporte.
Anonymous peer
Por padrão, o login do peer é anonymous. O peer anônimo permite distribuir fluxos sem vínculo a IP ou login/senha. Aplicam-se restrições quanto ao número de fluxos entregues por protocolos de transporte, por data limite e pela lista de fluxos permitidos.
É possível criar um peer individual por login (nome) e senha.
Para autorizar um peer por IP, ative a opção «Login Is IP».
Opções de autorização:
Por IP único
Por faixa de IP, por exemplo: «192.168.1.10-192.168.1.20»
Variante combinada, sintaxe de listas IP: ip[-ip2][,…]
Integração de aplicações de terceiros¶
Para suportar outros protocolos não cobertos pelos recursos integrados, é possível receber e transmitir o fluxo através de aplicações de console externas. Para isso há um protocolo std separado para input e output. O fluxo MPEG-TS é recebido e transmitido através do fluxo de entrada/saída do sistema operacional.
Na configuração indica-se a aplicação console (caminho absoluto) e a linha de comando; é possível também definir variáveis de ambiente.
Para um input com aplicação externa, evite mensagens no stdout — apenas no stderr.
Para o output é possível definir o empacotamento de até 7 pacotes MPEG-TS.
Requisitos do fluxo de entrada¶
Conformidade com ISO 13818-1, Single Program (SPTS) ou Multi Program Transport Stream (MPTS). As particularidades do MPTS são descritas adiante; as configurações a seguir são para SPTS.
É necessária pelo menos uma trilha de áudio.
Fluxos sem vídeo são suportados, ativados pelo modo Radio.
Fluxos codificados são suportados; para isso é necessário ativar Scrambled Stream.
Para a sincronização o fluxo deve conter marcas de PCR válidas.
Configurações do Stream¶
Defina um nome único para o stream em letras latinas, dígitos e «_»/«-». Também é possível atribuir um nome de exibição que aceita russo e outros idiomas.
Stream Timeout — tempo limite global do stream. Se não chegar fluxo de entrada válido nesse intervalo, ocorre reinício completo.
Pause — coloca o stream e todos os input e output em estado inativo. Por padrão, novos stream, input e output ficam em pausa e inativos.
O programa verifica a validade do fluxo de entrada no input. Se a verificação falhar, o input é considerado defeituoso.
Check Interval — intervalo de re-verificação do fluxo.
Configurações de filtragem MPEG-TS:
Remove All Unnecessary Data — remove todos os dados desnecessários, exceto PAT/PMT, vídeo e áudio, e o que estiver nos filtros separados (veja abaixo)
Remove SDT — remover dados SDT (nome do canal, provedor etc.).
Remove EIT/EPG — remover os dados de EPG.
Remove Teletext — remover o teletexto.
Remove Subtitles — remover as legendas.
Controle de bitrate do fluxo:
Bitrate mode — modo de controle de bitrate.
Origin (default) — o fluxo é transmitido sem alterações.
VBR — remove pacotes NULL para minimizar o bitrate. Ative se os fluxos forem usados apenas para distribuição OTT.
CBR auto — ativa o alinhamento de bitrate pela inserção de pacotes NULL (stuffing). O bitrate resultante é ajustado ao bitrate máximo do fluxo de entrada.
CBR set stuffing bitrate — definir explicitamente o bitrate desejado. Se for menor que o fluxo de entrada, é nivelado como em CBR Auto.
Com o modo CBR ativado, a PCR Accuracy obedece à TR 101 290; o intervalo do PCR permanece como no fluxo original.
Correção de fluxos:
Fix PAT/PMT interval — corrige o intervalo para conformidade com TR 101 290 inserindo PAT/PMT adicionais.
Redundância de fontes¶
Pode-se listar vários input, mas apenas um fica ativo. Se um input falhar, é tentado o próximo da lista, e assim ciclicamente.
Se em stream for ativado Fallback Check, durante o funcionamento do input de reserva (não o primeiro da lista) será realizada uma reverificação dos itens superiores da lista no intervalo Check Interval. Se na reverificação o fluxo estiver válido, o stream alterna para ele.
Como a ordem dos input importa, ela pode ser alterada. Um input em pausa não é considerado em funcionamento.
Filtragem e modificação de MPEG-TS¶
Por padrão, o fluxo MPEG-TS é transmitido como está.
Para cada input estão disponíveis as seguintes opções de filtragem MPEG-TS:
PID Accept — lista de PIDs permitidos. Se vazia, tudo é permitido exceto PID Reject.
PID Reject — lista de PIDs proibidos. Tem prioridade sobre PID Accept.
É possível alterar PIDs. Para isso preencha as listas PID Old e PID New.
Mapping PID and Languages — reatribuição do idioma das trilhas de áudio.
Default Language — definir o idioma padrão quando a trilha de áudio não tiver idioma.
Para o stream é possível atribuir novos dados MPEG-TS (tabela SDT):
MPEG-TS Network ID
Service Name
Provider Name
Language
Fluxos MPTS¶
Fluxo MPTS — fluxo MPEG-TS que transporta vários serviços, cada um com um número de programa único (PNR). Utilizado para a radiodifusão DVB.
Para fluxos MPTS as opções de filtragem não estão disponíveis. Os fluxos são transmitidos como estão.
O RTSP não pode ser fonte de um fluxo MPTS — é um protocolo single-program, aplicável apenas como fonte SPTS.
A função mosaic está desativada por padrão. Não é recomendado ativá-la em CPUs fracas — pode introduzir jitter.
Na diagnose do fluxo são exibidos os dados de cada programa separadamente e uma estatística global.
Arquitetura do fluxo MPTS: trânsito sem filtragem por serviço; para o processamento por serviço (OTT, DVR, filtragem) utiliza-se a entrada demultiplexer de um fluxo SPTS.¶
Demultiplexador¶
Extrai fluxos individuais de um fluxo MPTS. Para isso, adicionar no fluxo SPTS uma entrada do tipo demux, selecionar a fonte e o serviço pelo PNR. Se o MPTS de origem estiver ativo, ao selecionar o PNR estará disponível uma lista; caso contrário, o PNR deve ser introduzido manualmente.
Multiplexador¶
Monta um fluxo MPTS a partir de fluxos SPTS individuais. Para configurar esse fluxo:
Criar um stream MPTS.
- Adicionar um input do tipo muxer. Definir o bitrate para alinhar o fluxo CBR (stuffing, conformidade TR 101 290 e T-STD).
Se for definido 0 (padrão), não haverá alinhamento — o bitrate corresponderá aos fluxos de entrada. Ali também é possível introduzir alguns parâmetros do fluxo MPEG-TS; para a maioria das aplicações os parâmetros padrão são adequados.
No Stream de origem adicione um output do tipo muxer. Informe o nome do serviço e, se necessário, o do provedor. Se usar caracteres não latinos, selecione o idioma nas configurações MPEG-TS do stream.
Repetir para todas as fontes.
O multiplexador gera para o fluxo SDT, NIT e TDT/TOT (marcas de tempo). O EIT (EPG) é obtido dos fluxos de origem. Novos PIDs são atribuídos.
Fluxos de teste¶
Test Stream generator - test stream (test card). It allows to create generated video streams as plugs for broadcasting or failures on main streams. It is possible to set the type of image, sound, overlay text and time.
Configura-se ativando o tipo de input correspondente no stream. É possível definir tipo de formato de vídeo, resolução, bitrate, volume e frequência de áudio, etc.
A lista de Test Streams disponíveis está no menu lateral esquerdo do programa.
Serviço OTT¶
Entrega fluxos por protocolos baseados em HTTP — HLS (sobre MPEG-TS), MPEG-DASH e Low-Latency HLS (sobre CMAF — MP4 fragmentado, desde a versão 1.13), bem como MPEG-TS over HTTP. São suportados HTTPS (SSL) e HTTP/3 (QUIC). A entrega é ativada na aba OTT das configurações de Stream.
As URLs de conexão têm o formato:
http://host:port/http/stream/login/password — autorização por login e senha
http://host:port/http/stream/login — autorização por login (token)
http://host:port/http/stream/ — autorização por IP
host e port são definidos nas configurações do http server.
stream — ID do stream. Não confundir com o número de ordem na lista de streams. O ID é exibido no topo da página de estatísticas do stream e na coluna ID da lista de streams; é definido na criação do stream e nunca muda.
De forma análoga para HLS, DASH e Low-Latency HLS (os dois últimos — apenas em OTT/HLS/LL-HLS/LL-Dash, veja abaixo):
Na página de estatísticas do stream são exibidas as URLs dos protocolos conectados (como template) e seu status atual. O acesso não autorizado é proibido; os clientes devem estar registrados em Peers.
Para HLS e DASH estão disponíveis parâmetros adicionais na URL (opcionais):
[URL]?a=1&s=40&m=40&v=5&h3=1
a: 1 — caminho absoluto na playlist, 0 — caminho relativo (padrão).
s: duração da playlist dinâmica (s), 40 s por padrão.
m: duração mínima da playlist dinâmica (s), 40 s por padrão. Tamanho máximo da playlist dinâmica 60 s. Se o tamanho atual do buffer de chunks for menor que o tamanho mínimo solicitado na requisição, é retornado um erro 404. Assim, o HLS arranca com um buffer de chunks cheio no servidor.
v: a versão do protocolo HLS emitida na playlist. Por padrão, o valor depende do modo HLS (veja abaixo): OTT/HLS e OTT/HLS/LL-HLS/LL-Dash — 6, Peering/HLS — 3. Um valor explícito na URL substitui o padrão. Trocar a versão pode ser necessário para compatibilidade com um cliente HLS específico.
h3: opt-in para HTTP/3 (QUIC) nesta sessão OTT. Faz com que o servidor emita um cabeçalho
Alt-Svcna resposta, após o que um leitor / browser compatível passa para QUIC. Ver a secção HTTP/3 (QUIC) abaixo.
Para compatibilidade com alguns clientes HLS é possível adicionar o nome de arquivo index.m3u8 à URL, ex.: http://host:port/hls/stream/login/password/index.m3u8.
O modo de entrega é definido pela configuração de stream OTT HLS (aba OTT): Peering/HLS, OTT/HLS ou OTT/HLS/LL-HLS/LL-Dash.
Peering/HLS — um modo com divisão simples em segmentos (chunks). Recomendado para o peering (distribuição) de fluxos. É entregue apenas HLS sobre MPEG-TS (/hls). Por padrão, a playlist é servida como EXT-X-VERSION:3 para compatibilidade com clientes peer.
OTT/HLS — um modo com divisão de segmentos otimizada para um início rápido dos players na transmissão OTT. Nesse modo, a carga de CPU é maior; é recomendado para transmissão. É entregue HLS sobre MPEG-TS (/hls). Por padrão, a playlist é servida como EXT-X-VERSION:6 com EXT-X-INDEPENDENT-SEGMENTS e o atributo CHARACTERISTICS em EXT-X-MEDIA TYPE=SUBTITLES (Apple HLS, hls.js, Safari, dash.js/Shaka). Se um cliente específico precisar de um valor anterior, defina-o pelo parâmetro de consulta ?v= (veja a lista de parâmetros acima).
OTT/HLS/LL-HLS/LL-Dash — um modo de entrega sobre CMAF (MP4 fragmentado, fMP4; desde a versão 1.13). O stream gera segmentos fMP4 (.m4s + um init.mp4 comum, mimeType="video/mp4"), sobre os quais são entregues:
MPEG-DASH em
/dash— agora sobre CMAF, e não sobre MPEG-TS;Low-Latency HLS em
/llhls(veja Low-Latency HLS abaixo);com a configuração de stream Enable TS Chunk ativada (padrão true) — adicionalmente HLS legacy sobre MPEG-TS (
/hls), como no OTT/HLS; com false, são entregues apenas segmentos fMP4, o que economiza disco e CPU.
A playlist HLS no OTT/HLS/LL-HLS/LL-Dash também é EXT-X-VERSION:6 por padrão.
Nota
MPEG-DASH e Low-Latency HLS estão disponíveis apenas no OTT/HLS/LL-HLS/LL-Dash. No OTT/HLS e no Peering/HLS, é entregue exclusivamente HLS sobre MPEG-TS.
É possível habilitar SSL (HTTPS) no servidor HTTP nas configurações do servidor.
Chunk Min Interval e Chunk Max Interval
No modo OTT, o fluxo é analisado para PAT/PMT/SPS/PPS/IFrame e os chunks são fatiados segundo o critério de arranque rápido dos reprodutores. A análise começa em min interval e, se por algum motivo os dados não forem encontrados, o chunk é fatiado à força em max interval.
GOP-aligned segments
No OTT/HLS, o segmentador alinha as fronteiras dos chunks aos pontos de acesso aleatório e distingue entre IDR e um I-frame comum. Se a fonte transmite com closed-GOP (com IDR), cada segmento TS .ts começa garantidamente com SPS / PPS / IDR (para HEVC — também VPS) — um verdadeiro ponto de entrada a partir do qual o player abre o fluxo. Se a fonte for open-GOP / sem IDR, a fronteira é o I-frame mais próximo (o comportamento anterior). O segmentador remove a «cauda» do GOP anterior — os slices P / B — da janela entre o PAT inicial e o primeiro SPS do chunk. Isso:
elimina o quadro preto inicial no começo da sessão VOD (
?t=/?epg=) em hls.js, Safari e VLC: o decodificador MSE recebe o conjunto correto de unidades NAL de cabeçalho já no primeiro segmento e inicia imediatamente;alinha a saída com HLS RFC 8216 §3 («Each Media Segment MUST contain a SPS and a PPS that decode its first Access Unit»);
torna correta a declaração EXT-X-INDEPENDENT-SEGMENTS em uma playlist EXT-X-VERSION:6.
Controlado pela configuração por stream gop-aligned-segment (padrão true). Aplica-se apenas quando HLS = OTT/HLS: em Peering/HLS e para streams MPTS o comportamento não muda. O PSI (PAT / PMT) e o áudio são preservados integralmente; o único efeito colateral é um salto de um quadro do continuity_counter na PID de vídeo na fronteira entre dois chunks vizinhos, o que constitui um decode boundary legítimo para HLS / DASH MSE.
Ao alinhar aos pontos de entrada, a duração real do chunk pode ser arredondada para cima além de Chunk Min Interval. Por isso, na playlist live o valor EXT-X-TARGETDURATION reflete a duração de segmento real máxima (seção 4.3.3.1 de RFC 8216) em vez do mínimo configurado. Isso mantém o manifesto dentro do padrão: hls.js e os players compatíveis não reduzem o intervalo de atualização da playlist nem emitem bufferStalledError falsos.
Low-Latency HLS (/llhls)
No OTT/HLS/LL-HLS/LL-Dash, além de /dash há um endpoint Low-Latency HLS separado — entrega de baixa latência sobre os mesmos segmentos fMP4 de CMAF:
A playlist de mídia é dividida em segmentos parciais (parts, diretivas #EXT-X-PART): o player inicia a reprodução sem esperar o segmento completo ficar pronto. São aplicados o recarregamento bloqueante da playlist (o servidor retém a requisição até o próximo part ficar pronto) e a dica de pré-carregamento #EXT-X-PRELOAD-HINT.
A duração-alvo de um part é definida pela configuração de stream Part Target Duration (ms; padrão 500, faixa 100–5000). O valor é aplicado em tempo real, sem reiniciar o fluxo, e deve ser menor que Chunk Min Interval.
HLS / DASH / LL-HLS Adaptive Multistream
HLS Adaptive Multistream é suportado desde a versão 1.10, DASH Adaptive Multistream desde a versão 1.12 (desde a versão 1.13 — sobre CMAF), e Low-Latency HLS Adaptive desde a versão 1.13.
Para os fluxos adaptativos, configura-se uma playlist separada. Para isso:
Ativar a entrega OTT nos fluxos que farão parte da playlist adaptativa: OTT/HLS — para HLS adaptativo sobre MPEG-TS; OTT/HLS/LL-HLS/LL-Dash — para DASH / Low-Latency HLS adaptativos sobre CMAF.
No menu principal aparecerá uma seção de fluxos adaptativos. Nela é preciso adicionar um fluxo e indicar todos os fluxos que devem entrar nesta playlist.
Os fluxos podem ter um parâmetro de bitrate definido. Por padrão, é 0 — o bitrate é obtido do valor medido; caso contrário, pode ser definido explicitamente.
Para playlists adaptativas a URL é diferente:
Aos peers (clientes) pode-se impor restrições de acesso aos fluxos adaptativos, assim como aos comuns. A permissão para um fluxo adaptativo inclui a permissão para todos os fluxos que o compõem.
HTTP/3 (QUIC)¶
Desde a versão 1.13.1.438, o Perfect Streamer inclui um servidor HTTP/3 integrado para a entrega OTT de HLS, MPEG-DASH e Low-Latency HLS sobre QUIC (RFC 9000 + RFC 9114). A pilha é ngtcp2 (QUIC v1) + nghttp3 (HTTP/3 frame layer); a infraestrutura TLS reutiliza o mesmo certificado que o listener HTTPS.
O QUIC serve apenas rotas OTT:
/— redirecionamento raiz,/hls/...,/dash/...e/llhls/...— master playlists / MPD,/h<sessID>/...— URL por sessão (media playlists, segmentos, VTT),/http/<stream>/...— MPEG-TS bruto sobre HTTP.
Low-Latency HLS e DASH são entregues sobre QUIC de forma incremental (chunked): as parts são enviadas ao cliente à medida que ficam prontas, sem esperar o segmento completo.
Os caminhos administrativos (/data, /config, /xmltv, /db/, /login, /logout, /restart) devolvem 404 sobre QUIC — a API de administração permanece em HTTPS / HTTP-TCP. Trata-se de uma restrição deliberada para reduzir a superfície de ataque do listener QUIC.
Ativação¶
As definições de QUIC encontram-se na secção Configuration / HTTP server (nó /config/http-server):
HTTP/3 Enable (
http3-enable) — indicador global que ativa o listener QUIC. Valor por omissão: off. A ativação abre um socket UDP emhttp3-port; a desativação fecha-o.HTTP/3 Port (
http3-port) — porta UDP do listener QUIC. Valor por omissão: 43984. O QUIC opera sobre UDP e o HTTPS sobre TCP; as portas podem coincidir ou diferir, sem conflito entre si.HTTP/3 0-RTT Enable (
http3-zero-rtt-enable) — permite o handshake 0-RTT (RFC 9001 §4.6.1) em ligações retomadas do mesmo cliente. Reduz a latência de arranque; o risco de reprodução deve ser considerado para pedidos não idempotentes (é seguro para cargas OTT de apenas leitura). Valor por omissão: on.
As alterações de configuração são aplicadas a quente, sem reiniciar o serviço.
O certificado e a chave são obtidos do listener HTTPS — não existe configuração de certificado separada para HTTP/3. Se o HTTPS não estiver configurado (ssl-enable=false), a ativação do HTTP/3 não produz efeito — o handshake não será concluído.
O parâmetro ?h3 — opt-in por sessão¶
Um browser não liga diretamente a um endpoint HTTP/3 — acede primeiro via HTTPS/TCP, recebe na resposta o cabeçalho Alt-Svc: h3=":<port>"; ma=86400 (RFC 7838) e só os pedidos seguintes a esse origin são comutados para QUIC.
No Perfect Streamer, a emissão de Alt-Svc é opt-in por sessão OTT. O servidor não anuncia QUIC a todos os clientes indistintamente: o cliente deve solicitar HTTP/3 explicitamente através do parâmetro de consulta ?h3 no URL master HLS / DASH.
Valor no URL |
Valor opt-in |
|
|---|---|---|
parâmetro ausente |
off (default) |
não |
|
on |
sim |
|
on |
sim |
|
explicit off |
não (como se ausente) |
Depois de o cliente obter o URL de sessão /h<sess>/..., o indicador wantH3 fica armazenado na sessão — todas as atualizações posteriores de media playlist, GET de segmentos e GET de chunks VTT sob esse URL de sessão recebem também Alt-Svc, mesmo que ?h3 esteja ausente do pedido em si. Sem opt-in no master, não se estabelece comportamento sticky.
Filtragem de Alt-Svc:
O listener QUIC está globalmente ativado (
http3-enable=true); caso contrário o anúncio é suprimido mesmo com?h3definido.O pedido não chegou por QUIC — em pedidos já servidos sobre H3,
Alt-Svcnão faz sentido e não é emitido.Por sessão ou por URL
wantH3=true(ver a tabela acima).Os servidores de administração e EPG nunca emitem
Alt-Svc— não possuem listener QUIC.
Este comportamento está em conformidade com a RFC 7838 §3 — o próprio servidor decide em que respostas emite Alt-Svc.
Cenário de comutação para QUIC no browser¶
Fluxo típico (Chrome / Firefox / Safari):
O leitor abre o URL master com opt-in explícito:
https://stream.example.com:41982/hls/test1/login/password/index.m3u8?h3=1
O primeiro pedido vai por HTTPS/TCP. Na resposta o servidor emite
Alt-Svc: h3=":43984"; ma=86400.O browser memoriza o mapeamento
stream.example.com:41982 → h3=":43984". No Chrome pode ser visto na páginachrome://net-internals/#alt-svc; no Firefox —about:networking#http3.Nos pedidos seguintes ao mesmo origin (atualização da playlist, GET de segmentos, VTT) o browser abre uma ligação QUIC em
udp/43984e prossegue sobre HTTP/3. Em DevTools → Network a coluna Protocol desses pedidos passa ah3.
Se a ligação QUIC não puder ser estabelecida (porta UDP bloqueada pela firewall, certificado não confiável no sistema), o browser permanece de forma transparente em HTTPS/TCP — funcionalmente o fluxo continua a reproduzir sem interrupção.
Contabilização de clientes e monitorização¶
O endereço IP real de um cliente QUIC na contabilização de pares ativos (/data/http-clients, limites de ligações concorrentes, ACL por IP) é o endereço de peer real da ligação QUIC, não o loopback da ponte de backend interna.
O atributo ott-type em /data/http-clients é composto, com o formato <PROTO>/<scheme>:
PROTO— protocolo OTT:HLS,DASHouHTTP.scheme— o transporte de rede efetivo:http,httpsouquic.
Exemplos: HLS/quic, DASH/https, HTTP/http. A interface de administração mostra tanto o protocolo OTT como o transporte de rede de cada cliente numa única coluna.
O tempo-limite de uma sessão OTT é de 60 segundos, independentemente do transporte. Quando o cliente alterna entre transportes, o esquema apenas é atualizado para cima segundo a cadeia de prioridade http → https → quic. Um retorno paralelo a uma ligação menos segura não sobrescreve o tipo atual — na contabilização permanece o transporte mais seguro observado.
Compatibilidade dos leitores¶
O HTTP/3 para OTT é suportado por:
iOS AVPlayer / Safari — nativamente, através de
Alt-Svc; com 0-RTT.Chrome, Firefox, Edge, Brave — através de
Alt-Svc; o HLS é reproduzido com hls.js e o DASH com dash.js / Shaka; o tráfego do leitor herda o HTTP/3 da fetch API do browser.Android ExoPlayer — através do motor QUIC Cronet (não é o transporte predefinido; requer configuração no cliente).
VLC (libVLC) não suporta HTTP/3 — nestes clientes o fluxo continua a funcionar sobre HTTPS/TCP, sem o benefício do QUIC.
O benefício real do QUIC face ao HTTPS/TCP é mais notório em redes móveis / Wi-Fi / redes com perdas:
ausência de head-of-line blocking ao nível do TCP — uma perda num fluxo HTTP não atrasa os restantes;
handshake 0-RTT em ligações retomadas do mesmo cliente;
taxa de bits ABR mais estável com perdas de pacotes de 1 a 5 %.
Em redes geridas / Wi-Fi corporativo, o ganho costuma ser modesto — de 5 a 10 % na latência de arranque e praticamente nulo em regime estacionário. A carga de CPU no servidor é maior com QUIC do que com o TCP do kernel — é o preço de uma pilha TLS + transporte em user space.
Modelo de cache para OTT HLS e DASH¶
O servidor produz respostas em três categorias, distintas pelo tempo de vida do conteúdo e pela adequação ao cache em nós intermediários (reverse proxy, CDN, cache do cliente).
1. Modelo de cache¶
1.1. Recursos e cabeçalhos HTTP¶
Recurso |
URL |
Content-Type |
Cache-Control |
|---|---|---|---|
Segmento TS (HLS) |
|
|
|
Segmento fMP4 (DASH / LL-HLS) |
|
|
|
DASH MPD |
|
|
|
HLS master |
|
|
|
HLS media |
|
|
|
302 Redirect |
|
— |
|
Raw TS |
|
|
não definido; não é cacheado |
1.2. Características dos segmentos¶
O identificador hexadecimal do segmento na URL (<keyHex> nos caminhos /h<sess>/<keyHex>.ts) é calculado como um CRC64 sobre o tempo de início do segmento e o ID do stream, e é globalmente único. A URL do segmento endereça conteúdo imutável — em requisições repetidas para a mesma URL é devolvido um fluxo de bytes idêntico (enquanto o segmento permanecer dentro da janela deslizante).
A diretiva immutable suprime a revalidação condicional pelo cliente (If-None-Match, If-Modified-Since). O valor max-age=60 é compatível com o típico timeShiftBufferDepth=40s.
Os segmentos fMP4 de CMAF (.m4s) e o init.mp4 comum para DASH / Low-Latency HLS são endereçados de forma análoga e armazenados em cache pelo mesmo modelo (immutable, max-age=60). Os segmentos parciais (parts) do LL-HLS são requisições byte-range dentro do mesmo .m4s, portanto não formam uma entrada de cache separada.
1.3. Características dos manifestos¶
max-age=1 limita o limite superior de obsolescência do conteúdo no cache em um segundo. Em conjunto com proxy_cache_lock on (nginx), picos de requisições ao manifesto coalescem em uma única requisição ao origin por segundo.
1.4. Variabilidade do conteúdo¶
Com absPath=0 (valor padrão; sem o parâmetro de URL a) os manifestos HLS media e DASH MPD não incluem identificador de sessão no corpo. O conteúdo do manifesto é idêntico entre sessões que pertencem à mesma combinação (stream, param). Isso permite que o cache do reverse-proxy reutilize uma única entrada entre sessões quando a chave de cache está normalizada.
Com absPath=1 (parâmetro de URL a=1) o corpo do manifesto contém URLs absolutas que incluem o esquema, o host e o identificador de sessão. O conteúdo torna-se específico da sessão; a reutilização de cache entre sessões não está disponível.
2. Comportamento dos clientes¶
Cliente |
URL de atualização do manifesto |
Impacto no número de sessões |
|---|---|---|
VLC 3.x HLS |
|
Uma sessão por reprodução |
VLC 3.x DASH |
|
Tratado por session reuse (ver 3.3) |
ffmpeg 5.x HLS |
|
Uma sessão por reprodução |
ffmpeg 5.x DASH |
|
Tratado por session reuse (ver 3.3) |
dash.js, hls.js |
|
Uma sessão por reprodução |
3. Mecanismos especiais¶
3.1. HTTP 302 Redirect para DASH¶
Uma requisição da forma /dash/<stream>/<login>/<pass>/index.mpd retorna a resposta 302 Found com o cabeçalho Location: /h<sess>/index.mpd. O corpo da resposta é vazio. A autenticação e a alocação da sessão acontecem na fase de processamento do redirecionamento.
Clientes que suportam cache de redirecionamento acessam diretamente a URL da sessão nas requisições subsequentes. Clientes que não suportam repetem a requisição de redirecionamento. O custo do reprocessamento do redirecionamento limita-se à verificação de autenticação e às operações de session reuse.
3.2. Session reuse para DASH¶
Ao processar uma requisição /dash/.../index.mpd do mesmo login para o mesmo stream (com o mesmo indicador adaptive), o servidor encontra uma sessão DASH já existente e devolve novamente o identificador dela. Nenhuma nova sessão é criada; nenhum slot do limite de conexões simultâneas é consumido.
Aplica-se apenas ao DASH. Para HLS não é necessário um mecanismo de reuse separado: os clientes HLS atualizam a media playlist via URL de sessão e não criam uma nova sessão a cada refresh.
3.3. Reutilização de segmentos entre sessões¶
O caminho /h<sess>/<keyHex>.ts não depende de <sess> ao resolver <keyHex> em conteúdo: <keyHex> identifica de forma globalmente única um segmento TS dentro de um stream. Nginx com uma chave de cache normalizada (que remove o prefixo /h<sess>/) atende cada requisição para o mesmo <keyHex> a partir de uma única entrada de cache, independentemente de quais clientes a emitiram.
O mesmo vale para os segmentos fMP4 de CMAF (.m4s) e init.mp4: seu conteúdo é imutável e endereçado dentro do stream, de modo que a normalização da cache key produz a mesma deduplicação entre sessões no cache.
4. Parâmetros de requisição¶
Parâmetro |
Valor padrão |
Impacto |
|---|---|---|
|
|
|
|
|
|
|
|
Comprimento mínimo da janela para emitir o manifesto |
|
|
|
|
ausente (off) |
opt-in para HTTP/3 (QUIC) — faz com que o servidor emita |
A alteração de um parâmetro via query string atualiza os valores armazenados na sessão na sua próxima reabertura.
5. Características de carga¶
A carga no origin escala com o número de streams distintos assistidos simultaneamente. O aumento do número de clientes assistindo o mesmo stream não aumenta o número de requisições ao origin quando há reverse-proxy cache com chave de cache normalizada.
Cenário |
Taxa de requisições ao origin (ref.) |
|---|---|
1 cliente por fluxo X |
MPD: 0.4 req/s, segment: 0.2 req/s |
N clientes em um mesmo fluxo X (cache ativo) |
MPD: 1 req/s, segment: 0.2 req/s |
N clientes ffmpeg em modo replay no mesmo fluxo |
MPD: 1 req/s (com |
N clientes em N fluxos distintos |
MPD: 0.4·N req/s, segment: 0.2·N req/s |
6. Nginx como reverse proxy com cache¶
6.1. Configuração básica¶
proxy_cache_path /var/cache/nginx/pss_segments
levels=1:2 keys_zone=pss_segments:100m
max_size=20g inactive=30m use_temp_path=off;
proxy_cache_path /var/cache/nginx/pss_manifests
levels=1:2 keys_zone=pss_manifests:10m
max_size=256m inactive=5m use_temp_path=off;
upstream pss_backend {
server 127.0.0.1:41972;
keepalive 64;
}
map $uri $pss_cache_key {
~^/h[0-9a-f]{16}(?<tail>/.+\.(ts|m3u8))$ "stream:$tail";
default $uri;
}
server {
listen 80;
server_name stream.example.com;
location ~* "^/h[0-9a-f]{16}(/[0-9]+)?/([0-9a-f]+\.(ts|m4s)|init\.mp4)$" {
proxy_cache pss_segments;
proxy_cache_key $pss_cache_key;
proxy_cache_valid 200 60s;
proxy_cache_valid 404 403 0s;
proxy_cache_lock on;
proxy_cache_use_stale updating error timeout;
proxy_cache_revalidate on;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://pss_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering on;
}
location ~* "(^/h[0-9a-f]{16}(/[0-9]+)?/index\.(m3u8|mpd)$|^/(hls|dash)/.*\.(m3u8|mpd)$)" {
proxy_cache pss_manifests;
proxy_cache_key $pss_cache_key;
proxy_cache_valid 200 1s;
proxy_cache_valid 404 403 0s;
proxy_cache_lock on;
proxy_cache_lock_timeout 2s;
proxy_cache_use_stale updating;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://pss_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
location / {
proxy_pass http://pss_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_buffering off;
proxy_read_timeout 3600s;
}
}
6.2. Finalidade das diretivas¶
Diretiva |
Finalidade |
|---|---|
|
Serializa as requisições upstream em cache misses simultâneos para a mesma chave |
|
Devolve a cópia obsoleta às requisições paralelas durante a atualização do cache |
|
Usa |
|
Proíbe o cache de erros de autorização e 404 |
|
Mantém um pool de conexões persistentes ao origin |
|
Para segmentos; ativa o bufferização da resposta no nginx |
|
Para a seção |
6.3. Cálculo de max_size do cache de segmentos¶
Valor de referência: bitrate × timeShiftBufferDepth × distinct_streams × 2
Exemplo: 10 fluxos × 8 Mbps × 40 s × 2 ≈ 800 MB. Recomenda-se uma margem de 10× para absorver a variabilidade do bitrate.
6.4. Terminação TLS¶
O servidor do Perfect Streamer aceita conexões nas portas HTTP e HTTPS. Com terminação TLS no nginx, o upstream usa a porta HTTP. O encaminhamento dos cabeçalhos X-Forwarded-Proto e X-Forwarded-Host é obrigatório para a composição correta de URLs absolutas quando absPath=1.
server {
listen 443 ssl http2;
server_name stream.example.com;
ssl_certificate /etc/letsencrypt/live/stream.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/stream.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location ... {
proxy_pass http://pss_backend;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host;
# + caching directives from 6.1
}
}
server {
listen 80;
server_name stream.example.com;
return 301 https://$host$request_uri;
}
Para HTTPS entre nginx e origin aplicam-se proxy_ssl_verify e proxy_ssl_trusted_certificate. Em conexões loopback a criptografia é redundante.
6.5. Multi-host¶
Quando um único processo nginx atende vários server_name, $host é adicionado à cache key para isolar o conteúdo:
map $uri $pss_cache_key {
~^/h[0-9a-f]{16}(?<tail>/.+\.(ts|m3u8))$ "$host:stream:$tail";
default "$host:$uri";
}
O tamanho de keys_zone é dimensionado em 8000 chaves/MB. Para instalações multi-host com milhares de fluxos, recomenda-se keys_zone=...:300m ou mais.
7. Cache no cliente¶
Cache-Control: immutable é processado pelos navegadores Chrome/Firefox/Safari. O cache do cliente devolve o segmento sem requisição condicional em acessos repetidos (incluindo seek para trás dentro do buffer do player).
Service Workers podem aplicar a estratégia cache-first baseada no conteúdo de Cache-Control. Os players DASH (dash.js, Shaka) usam MSE através de SourceBuffer; o segmento colocado no buffer permanece disponível sem nova requisição HTTP até sair da janela deslizante.
Para requisições cross-domain, o cabeçalho Access-Control-Allow-Origin: * permite o cache em shared caches sem Vary: Origin. Ao trocar o valor ACAO para um Origin específico passa a ser necessário Vary: Origin, o que reduz a eficiência do shared cache.
8. Implantação via CDN¶
Perfect Streamer é compatível com CDNs em modo pull-from-origin (Cloudflare, Akamai, Fastly, BunnyCDN, Amazon CloudFront).
Origin shield. Recomenda-se colocar um ou mais nós shield entre o edge do CDN e o origin para reduzir a taxa de requisições ao origin quando os clientes estão distribuídos globalmente.
Purge. Segmentos content-addressed não precisam de purge. Quando os metadados do stream mudam (codec, resolução), os manifestos atualizam dentro de max-age=1 sem purge explícito.
Cache warming. Em caso de pico esperado em um stream específico, é admissível pré-aquecer a CDN a partir de vários pontos geográficos antes do início da transmissão.
Geodistribuição. Os segmentos (max-age=60) são bem adequados para cache geograficamente distribuído. Os manifestos (max-age=1) toleram atraso de entrega de até um segundo — aceitável para live non-low-latency.
9. Monitoramento¶
9.1. X-Cache-Status¶
Adicionar add_header X-Cache-Status $upstream_cache_status; em cada location com cache. Valores:
Valor |
Descrição |
|---|---|
|
Resposta do cache |
|
Não estava em cache; obtido do origin e armazenado |
|
Expirado, atualizado |
|
Cópia stale entregue à requisição paralela durante a atualização |
|
|
|
Origin retornou 304 Not Modified |
|
|
9.2. Formato do access-log¶
log_format pss_cache '$remote_addr $status $request_method "$request" '
'$body_bytes_sent rt=$request_time ut=$upstream_response_time '
'cache=$upstream_cache_status key=$pss_cache_key';
server {
access_log /var/log/nginx/pss.log pss_cache;
}
9.3. Métricas¶
O módulo nginx-vts exporta métricas por zona no formato Prometheus:
GET /status/format/prometheus
Limites recomendados para alertas:
Métrica |
Limite |
Causa possível |
|---|---|---|
Segment HIT rate |
< 90 % em 5 minutos |
Normalização de cache key quebrada; |
Manifest MISS rate |
> 50 % em 1 minuto |
|
Upstream response time p95 |
> 500 ms em 1 minuto |
Sobrecarga do origin |
Cache zone fill |
> 90 % em 10 minutos |
Aproximação de |
10. Diagnóstico¶
Sintoma |
Causa provável |
Solução |
|---|---|---|
Taxa HIT de segmento baixa |
|
Verificar cabeçalhos e regex na diretiva |
404 em segmentos após sair da janela |
404 em cache para segmento que saiu da janela deslizante |
Adicionar |
Atraso do início da reprodução 2–5 s |
|
Reduzir para 1–2 s; ativar |
O manifesto não atualiza |
|
Definir explicitamente |
Crescimento de TIME_WAIT no upstream |
Falta |
Adicionar |
403 em |
O cliente resolve URLs relativas a partir da URL pré-redirect |
O servidor emite |
Lags, rebuffering frequente em clientes remotos |
Throughput TCP efetivo baixo devido a slow start e idle restart com RTTs grandes (300 ms e superiores) |
Ajuste da pilha de rede do Linux no origin: ver 10.1 |
10.1. Ajuste TCP do origin para clientes high-RTT¶
O problema se manifesta em clientes com RTT grande até o origin (por exemplo 300 ms ou mais) quando o bitrate do stream está próximo da capacidade do canal. Sintomas no reprodutor (VLC, ffmpeg, dash.js) — rebuffering frequente, warnings do tipo ES_OUT_SET_PCR called too late (aumento de pts_delay), buffer deadlock prevented, interrupções do stream. No servidor, enquanto isso, o cliente parece normal, não há erros, e o throughput em /data/stream/... corresponde ao stream de entrada.
Causa:
TCP slow start. Cada nova conexão TCP começa com um congestion window de cerca de 14 KB e o aumenta ao longo de vários RTT. Com um RTT de 300 ms, atingir a janela completa leva 2-3 segundos. Durante esse tempo, um segmento HLS/DASH com duração de 5 s (4-6 MB) é baixado visivelmente mais devagar do que em tempo real.
TCP idle restart. Entre solicitações de segmentos, um cliente HLS em pull-model faz uma pausa de 4-5 s. Por padrão, após tal pausa o kernel do Linux redefine o congestion window da conexão para o initial cwnd (comportamento
net.ipv4.tcp_slow_start_after_idle=1). Como resultado, no próximo GET a conexão keep-alive retoma a transmissão a partir do slow start — mesmo em uma sessão já aquecida.
Um agravante adicional — o congestion control CUBIC padrão lida mal com RTTs longos e perdas de pacotes em trechos intermediários da rede.
Solução — dois parâmetros sysctl no origin:
# Keep congestion window across idle pauses inside keep-alive sessions.
sysctl -w net.ipv4.tcp_slow_start_after_idle=0
# Use BBR instead of CUBIC: better behaviour on long-RTT paths
# with mild packet loss; paces sending instead of bursting.
modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
Para aplicação persistente:
cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl --system
O principal efeito vem do primeiro parâmetro (tcp_slow_start_after_idle=0). Ele elimina diretamente o slow start repetido entre solicitações de segmentos dentro de uma mesma conexão keep-alive. O segundo (BBR) oferece robustez adicional e aplica-se a todas as novas conexões.
O ajuste não requer reinicialização do Perfect Streamer e aplica-se a todas as novas conexões TCP imediatamente após sysctl -w. As conexões existentes conservam o congestion control com o qual foram estabelecidas.
11. Segurança¶
11.1. Session URL¶
A URL no formato /h<sess>/... cumpre a função de token de sessão — não exige reautenticação. O tempo de vida é limitado pelo idle timeout (valor 30 s). Em caso de inatividade, a sessão é removida pela tarefa cleaner.
Requisitos:
HTTPS em todos os caminhos OTT (
/hls/,/dash/,/h<sess>/) em produçãoO Session ID no cabeçalho
Locationdo 302 não é cacheado (no-cache, no-store)
11.2. Rate limiting¶
limit_req_zone $binary_remote_addr zone=dash_top:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=hls_top:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=llhls_top:10m rate=5r/s;
server {
location /dash/ {
limit_req zone=dash_top burst=20 nodelay;
proxy_pass http://pss_backend;
}
location /hls/ {
limit_req zone=hls_top burst=20 nodelay;
proxy_pass http://pss_backend;
}
location /llhls/ {
limit_req zone=llhls_top burst=20 nodelay;
proxy_pass http://pss_backend;
}
}
URLs de sessão (/h<sess>/) não exigem rate limiting — o processamento é barato e as respostas são cacheadas.
11.3. Cache de respostas de erro¶
proxy_cache_valid 200 60s;
proxy_cache_valid 301 302 0s;
proxy_cache_valid 404 403 0s;
proxy_cache_valid any 1s;
Proíbe o cache de redirecionamentos (sess único em Location) e de respostas de erro de autorização ou recurso ausente.
11.4. Restrição do acesso de rede ao origin¶
A porta 41972 (41982 para HTTPS) deve estar fechada ao tráfego externo. Configurações aceitáveis:
Bind do Perfect Streamer em
127.0.0.1(com nginx local)Regra de firewall:
iptables -A INPUT -p tcp --dport 41972 ! -s 10.0.0.0/8 -j DROP
12. Integração com middleware¶
12.1. Modelo prefix-login¶
O Perfect Streamer permite delegar a identificação de usuário a middleware/sistema de billing via o mecanismo prefix-login. Um conector externo ao sistema de billing não está incluído nesta versão.
Configuração do usuário embedded:
{
"id": 9,
"login": "sub",
"password": "xxx",
"is-prefix": true,
"max-conn-http-hls": 1,
"accept-stream": [ ... ]
}
Com is-prefix: true o servidor aceita URLs cujo login segue <prefix><billing_user_id>:
/dash/test1/sub42/xxx/index.mpd
/hls/test1/sub43/xxx/index.m3u8
12.2. Formato das estatísticas¶
<clients>
<client login-id="-1974387287" login="sub" match-login="sub42"
sess-id="11331..." ott-type="dash" stream-id="10000" .../>
<client login-id="-2147031294" login="sub" match-login="sub43"
sess-id="11132..." ott-type="dash" stream-id="10000" .../>
</clients>
O campo login-id contém o hash do login URL. login é o valor configurado. match-login é o login URL usado pelo cliente.
12.3. Limitações do prefix-login¶
Senha compartilhada. Todos os assinantes do pool prefix usam um único valor de senha. O comprometimento da senha concede acesso a qualquer
<prefix><string>.Granularidade de ACL.
accept-streamaplica-se a todo o pool prefix; não há ACL por assinante sem billing externo.Rotação da senha. A alteração da senha desconecta todos os assinantes ativos. Uma substituição gradual requer o uso temporário de dois prefix-logins.
13. Legendas WebVTT¶
A fonte das legendas é DVB Teletext / DVB Subtitling do MPEG-TS de entrada. As faixas de legendas Teletext devem estar presentes nas seções Media Information ou Original Media Information. A seção Analyzer também permite verificar se os pacotes dos PIDs correspondentes estão ativos.
Para OTT HLS/DASH o modo OTT deve estar ativado (em Peering/HLS as legendas WebVTT não estão disponíveis). Na seção Output # OTT o contador de chunks OTT WebVTT buffer chunk count deve ficar diferente de zero.
Para diagnosticar as legendas, ativar Analyze e Trace no stream. Ao iniciar o fluxo, o log do stream deve exibir:
Start Teletext subtitle decoder
[ttxsubdec] ttx: pid=331 magazine=8 page=0x88 lang=***
Em seguida, o log registra o texto decodificado das legendas.
13.1. URL dos segmentos VTT¶
Esquema |
URL |
Conteúdo |
|---|---|---|
HLS master |
|
|
HLS subtitle playlist |
|
lista |
Segmento VTT HLS |
|
VTT com X-TIMESTAMP-MAP estilo HLS |
DASH MPD AdaptationSet |
em |
|
Segmento VTT DASH |
|
VTT com X-TIMESTAMP-MAP estilo DASH |
<keyHex> é um CRC64 hex de 16 caracteres calculado a partir do tempo de início do segmento, do ID do stream e do PID da faixa de legendas. <seq> é o número decimal sequencial de um chunk do stream de legendas (a numeração das legendas não está relacionada com a dos chunks TS).
DVR / Arquivo¶
Desde a versão 1.13, Perfect Streamer inclui um DVR integrado — um arquivo de fluxo persistente em disco, paralelo à saída OTT normal (HLS / DASH). O arquivo é gravado automaticamente, sem processo separado, e reproduzido pelas mesmas URLs OTT que o live — única diferença: o parâmetro query.
Recursos:
Gravação de cada fluxo OTT ao arquivo no armazenamento escolhido.
Reprodução HLS, DASH e Low-Latency HLS do arquivo (VOD) nas mesmas URLs que o live (DASH e LL-HLS — em CMAF, no OTT/HLS/LL-HLS/LL-Dash).
Legendas (WebVTT) — gravadas junto com chunks TS.
Vários armazenamentos — um fluxo é vinculado a um; fluxos distintos podem gravar em discos distintos.
Limpeza automática por tempo de retenção e uso do disco.
EPG-aligned VOD — arquivo conforme evento EPG referenciado.
VOD adaptativo — suportado para grupos adaptativos.
O DVR não requer licença separada. Ativado por fluxo adicionando vinculação ao armazenamento.
O DVR não substitui a transmissão ao vivo. Se um fluxo possui arquivo, o cliente recebe uma playlist ao vivo com o mesmo comportamento de quando não há DVR. O arquivo só começa a reproduzir quando o cliente solicita explicitamente o modo VOD por meio de um parâmetro de consulta da URL (ver abaixo).
Configuração do armazenamento¶
Um armazenamento é um registro na seção Configuration / DVR Storage. Cada registro descreve um diretório em disco onde PSS grava arquivos. Um fluxo usa um armazenamento.
Ao adicionar um armazenamento, configura-se:
Name — nome exibido.
Dir Path — caminho do diretório em disco. Após criar o registro, o caminho não pode ser alterado — para mover o arquivo, apagar o registro e criar um novo. Os arquivos existentes não são tocados em disco ao apagar o registro.
Max Usage, % — limiar de uso do disco (padrão 90 %). Ao exceder, inicia limpeza size-based (ver abaixo). Mín 1 %, máx 100 %.
Cleanup Interval, seg — período da tarefa de limpeza (padrão 10 seg). A cada tick corta-se primeiro o mais antigo que a profundidade de retenção; depois, se exceder Max Usage, chunks antigos.
Disk Pressure Grace, seg — segundos que Used % deve exceder Max Usage continuamente antes do Size-based cleanup (padrão 60 seg). Filtra picos curtos.
Disk Pressure Cut, seg — limite superior por tick de limpeza: segundos de vídeo por fluxo apagáveis de uma vez (padrão 300 seg). O resto passa ao próximo tick.
Disk Emergency Bytes — limiar de espaço livre abaixo do qual o armazenamento entra em Error e a gravação para (padrão 2 GiB). Recuperação auto se espaço livre ≥ 2 × este valor.
Alarm Disk-Full Hysteresis, % — a margem abaixo de Max Usage até à qual a limpeza baseada em tamanho reduz o preenchimento, para que Used % não oscile mesmo junto ao limiar (2 % por padrão).
A maioria dos valores padrão serve para instalações típicas; geralmente basta ajustar Max Usage e Dir Path.
Faz sentido criar um armazenamento por disco. Se no mesmo disco forem indicados vários registros com subdiretórios distintos, eles competirão pelo espaço livre — o disco é compartilhado, mas a limpeza é própria de cada armazenamento.
Vinculação de um fluxo ao armazenamento¶
Nos ajustes Stream / OTT aparece uma seção DVR:
Storage — lista suspensa de armazenamentos; 0 significa «arquivo desativado para este fluxo».
Storage Hours — profundidade do arquivo para este fluxo, em horas, de 1 a 2160 (até 90 dias). Os chunks mais antigos que esse valor são apagados a cada tick da tarefa de limpeza (Rolling cleanup).
Storage Min Hour — limiar de proteção inferior (horas). A limpeza nunca apaga chunks mais novos, mesmo sob pressão Max Usage. Útil se a lógica de negócio exige gravação recente garantida, ex. «as últimas 2 horas sempre presentes».
Alteração de Storage em tempo real:
definir 0 — desativa o arquivo; os chunks em disco são mantidos, novos não são gravados. As sessões VOD passam a responder 404;
escolher outro armazenamento — o fluxo se desvincula do antigo e passa a gravar no novo. Os arquivos do antigo não são migrados.
Mudanças em Storage Hours e Storage Min Hour se aplicam de imediato — a limpeza usa o novo valor no próximo tick.
Após configuração, o fluxo grava o arquivo automaticamente ao entrar em Running.
VOD: reprodução do arquivo¶
O arquivo é reproduzido pelas mesmas URLs que o live HLS / DASH (ver seção OTT service) — só muda o parâmetro query.
URLs e parâmetros¶
URLs para HLS, DASH e Low-Latency HLS (DASH e LL-HLS — em CMAF, requerem o modo OTT/HLS/LL-HLS/LL-Dash):
Sem parâmetros query — live normal com janela deslizante. Com o parâmetro t — modo VOD.
Parâmetro |
Finalidade |
|---|---|
|
Hora de início VOD (Unix epoch, seg). t=0 — desde o início do arquivo. A presença de t (mesmo t=0) ativa o modo VOD. |
|
Duração da janela VOD, seg. d=0 ou ausente — «até o momento atual». Só faz sentido com t. |
|
EPG-aligned VOD: o servidor localiza o evento EPG ativo no momento dado e usa seus start e duration como bordas da janela. Incompatível com t e d (substituição server-side). Ver abaixo. |
|
Parâmetros live padrão (ver OTT service); |
Comportamento conforme t e d:
t |
d |
Janela |
Condição 404 |
|---|---|---|---|
não |
— |
live (janela deslizante) |
— |
0 |
nenhum / 0 |
[início arquivo, agora] |
DVR não vinculado |
0 |
> 0 |
[início arquivo, +d] |
DVR não vinculado |
> 0 |
nenhum / 0 |
[t, agora] |
DVR não vinculado |
> 0 |
> 0 |
[t, t+d] |
DVR não vinculado |
Normalização das bordas:
t anterior ao início do arquivo — start é alinhado automaticamente ao primeiro chunk disponível (a limpeza pode ter cortado). Não é 404 — entrega-se o que resta.
t no futuro ou janela toda antes do arquivo — playlist vazia mas válida (HLS: só header +
EXT-X-ENDLIST; DASH:@type="static",mediaPresentationDuration="PT0S").Os chunks são selecionados estritamente pelo instante de início do chunk que cai no intervalo semiaberto [t, t+d) — não há segmentos parciais.
VOD em um fluxo sem arquivo (ou cujo armazenamento está em Error) — 404 imediato em master playlist / MPD. Nenhuma sessão é criada.
Texto de erro no corpo 404 (visível em logs do servidor e HTTP body):
VOD: stream not running— o fluxo está na config mas não em Running.VOD: no DVR archive— o fluxo não tem armazenamento ou está em Error.VOD: DVR detached— o fluxo se desvinculou do armazenamento entre requisições.VOD: EPG event not found— sem evento para?epg=.
Playlist HLS VOD — fechada (o player vê a duração e pode buscar):
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:5.000,
...
#EXT-X-ENDLIST
Esses marcadores não estão na playlist live — essa é a única diferença.
MPD DASH VOD — estático: @type="static", mediaPresentationDuration fixo, <SegmentURL> explícitos. O DASH live permanece @type="dynamic".
Se o intervalo escolhido tem lacunas no arquivo (p. ex. reinício de gravação ou limpeza no meio), o MPD DASH é dividido em vários <Period> — um por trecho contíguo. Os players (VLC, dashjs, Shaka) cruzam os limites de período sem configuração especial.
EPG-aligned VOD¶
Se o fluxo está vinculado a uma fonte EPG (campos EPG Source e EPG Channel nos ajustes), o cliente pode solicitar o arquivo por um instante contido em um evento EPG:
http://host:port/hls/stream/login/password/index.m3u8?epg=1778500000
http://host:port/dash/stream/login/password/index.mpd?epg=1778500000
O servidor localiza o evento EPG ativo no epoch dado e usa seus start e duration como bordas da janela VOD. Útil para catálogos: a UI sabe a hora do evento mas não precisa calcular bordas exatas.
Se o fluxo não está vinculado a EPG ou não há evento ativo — 404 ``VOD: EPG event not found``. t e d são ignorados se há epg.
Fluxos adaptativos¶
Os grupos adaptativos (ver HLS Adaptive Multistream) aceitam os mesmos parâmetros VOD:
http://host:port/hls/adaptive/group/login/password/index.m3u8?t=0
http://host:port/dash/adaptive/group/login/password/index.mpd?t=0
Na master playlist (HLS) só entram variantes com armazenamento DVR configurado. As sem DVR são puladas (no log aparece VOD: variant N has no DVR); a montagem segue com as demais.
Na variante DASH, cada qualidade vira um <Representation> distinto em <Period> comuns; o player troca de qualidade sem reabrir o manifesto.
Comportamento do player¶
O VOD HLS / DASH do arquivo toca em players padrão: VLC, hls.js, dashjs, Shaka, ffmpeg. A busca na timeline funciona.
Se o player pede um segmento já apagado pela limpeza, o servidor retorna 404 para esse segmento (não 500). VLC, hls.js, dashjs pulam o segmento e seguem no próximo.
Recursos adicionais:
Proteção de sessões ativas: enquanto há sessão VOD aberta, a limpeza não apaga chunks na sua janela (ver abaixo).
Live-edge bridge: se um cliente em sessão VOD solicitar um segmento além do limite direito da janela VOD — por exemplo, avança na timeline ao atingir o fim do arquivo — o servidor entrega automaticamente o segmento da memória live. Sem redirecionamentos e sem reautenticação.
Cache de playlist: em requisições repetidas do mesmo VOD
index.m3u8/index.mpd, o servidor retorna resposta idêntica byte a byte — sem reconstruir. Adequado para CDN à frente do PSS.
Legendas no arquivo¶
Se o fluxo traz legendas (DVB Subtitling, Teletext ou WebVTT) e a opção OTT WebVTT está ativa, as legendas são arquivadas em paralelo aos chunks TS — em arquivos .vtt ao lado de .ts.
Em modo live, a master playlist contém EXT-X-MEDIA:TYPE=SUBTITLES; em modo VOD, o servidor retorna uma playlist VOD de legendas (com ENDLIST) e segmentos .vtt nas mesmas URLs.
Particularidades:
HLS: o cabeçalho
X-TIMESTAMP-MAPé preservado no início de cada.vtt(exigido pela spec HLS).DASH: o cabeçalho
X-TIMESTAMP-MAPé removido em tempo real (ligado ao PCR absoluto, conflita com a âncora DASH; senão, VLC mostra legendas vazias).Em grupo adaptativo: se o sub-stream ativo não grava legendas, os segmentos VTT retornam 404. Na próxima variante, o player pode receber legendas de novo.
As legendas se desativam via OTT WebVTT no fluxo, ou não ativando HLS em modo OTT/HLS.
Limpeza e retenção¶
PSS usa duas estratégias de limpeza, executadas a cada tick (padrão a cada 10 seg):
Rolling cleanup (por fluxo): por fluxo, apagam-se chunks mais antigos que Storage Hours. Roda sempre, mesmo com disco semivazio.
Size-based cleanup (por armazenamento): quando Used % excede Max Usage continuamente por Disk Pressure Grace seg, os chunks mais antigos são cortados proporcionalmente entre fluxos vinculados. Por tick: Disk Pressure Cut seg de vídeo por fluxo. Nunca chunks mais novos que Storage Min Hour.
Emergency disk-full cut: se o espaço livre cai abaixo de Disk Emergency Bytes, a limpeza age agressivamente e pode apagar até chunks protegidos por sessão. A gravação para até o espaço livre voltar com histerese × 2.
Orphan scan: no disco podem permanecer arquivos não contabilizados no índice (após uma parada abrupta do PSS). O coletor percorre os subdiretórios dos fluxos e remove esses arquivos “esquecidos” — a primeira passagem pouco após o início do serviço, depois uma vez por hora e sempre que a pressão de disco for acionada. Como proteção contra uma corrida com a escrita, arquivos com menos de 60 s são ignorados.
Nota. As tarefas de limpeza rodam em segundo plano; o usuário normalmente não age. Se o arquivo cresce mais rápido do que é cortado, reduzir Storage Hours nos fluxos ou aumentar Disk Pressure Cut.
Proteção de sessões VOD ativas¶
Ao abrir uma sessão VOD, em cada armazenamento envolvido registra-se um «slot de proteção» com a hora de início da janela. As limpezas Rolling e size-based não tocam chunks na janela da sessão aberta. O slot é liberado automaticamente ao fechar (FIN, timeout).
Isso significa:
Se o cliente mantém a sessão VOD por muito tempo, pode buscar a qualquer instante na sua janela — os chunks não «somem sob ele».
A limpeza por Max Usage pode não levar Used % ao limiar enquanto a sessão estiver ativa; ao cliente sair, a limpeza alcança.
Emergency disk-full cut e Storage Min Hour contornam a proteção: se o disco está quase sem livre, os chunks são apagados e o cliente recebe 404 nos segmentos afetados (o player os pula).
Após reiniciar o PSS, os slots de proteção somem — a limpeza retoma de imediato.
Vários armazenamentos¶
Pode-se criar qualquer número de registros DVR Storage — um por diretório / disco. Os fluxos se vinculam a armazenamentos distintos de forma independente. A limpeza e limiares (Max Usage, Disk Pressure) operam por armazenamento.
Casos de uso:
Tiering por valor: armazenamento SSD rápido para canais premium com grande profundidade, HDD capacitivo para o resto.
Disco dedicado ao arquivo: para que a gravação DVR não concorra com o disco do sistema ou arquivos temporários.
Separação por projeto: um disco para o lote nº 1, outro para o nº 2 — simplifica migração e auditoria.
Trocar a vinculação do fluxo (campo Storage em Stream / OTT) comuta a gravação em tempo real. Os arquivos antigos ficam intactos no disco anterior — podem ser apagados manualmente ou retomar a gravação revertendo o fluxo.
Estado do armazenamento e monitoramento¶
A seção Data / DVR Storage List (e a API GET /data/dvr-storage-list) mostra por armazenamento:
State — Ready / Error (mais o estado intermediário Not Ready em um armazenamento recém-adicionado).
Total / Free / Used Bytes — espaço livre e ocupado no disco.
Used % — porcentagem atual de uso.
Archived Bytes — tamanho total dos chunks indexados de todos fluxos vinculados (sem orphans).
Pressure Since Sec — momento (epoch) em que Used % primeiro excedeu Max Usage neste episódio; 0 significa «sem pressão».
Active Task — a operação de manutenção em segundo plano em execução neste momento: gc-orphans (remoção de arquivos órfãos), disk-pressure-trim (corte sob pressão de disco) ou none, e há quantos segundos ela já está em execução. Operações de curta duração (< 2 s) não piscam na interface.
Last cleanup — um resumo das últimas execuções de limpeza: há quanto tempo ocorreu a anterior recolha de ficheiros órfãos (e quantos foram eliminados) e o último corte sob pressão de disco (quanto espaço foi libertado).
Attached streams — a lista dos fluxos associados; para cada um são exibidos o nome, o indicador de gravação em curso (active), a profundidade de arquivo configurada (retention-hours) e o preenchimento real (archived-sec e archived-bytes). A soma de archived-bytes de todos os fluxos é igual a Archived Bytes de todo o armazenamento.
Estados:
Ready — o diretório está disponível, a gravação e a limpeza ocorrem normalmente.
Error — o diretório de armazenamento está indisponível (desmontado, sem permissões, erro do sistema de arquivos) ou há espaço livre criticamente baixo no disco; a gravação é interrompida. A recuperação é automática — assim que o diretório fica novamente disponível e surge espaço livre suficiente.
Se o armazenamento entrou em Error, verifique se o diretório do arquivo está montado e se há espaço livre no disco — o PSS não sai sozinho desse estado até que o problema seja resolvido fisicamente.
Preenchimento do arquivo ao longo do tempo:
No nível do stream (Data / Stream) está disponível a métrica storage-gap-percent — a proporção de lacunas de tempo no arquivo acumulado: 0 % significa gravação contínua, valores mais altos significam que há descontinuidades no arquivo (reinícios da fonte, trechos cortados pela limpeza).
O endpoint
GET /data/dvrstatretorna um histograma do preenchimento do arquivo por intervalos de tempo, com a marcação de eventos de gravação (início/parada da fonte, mudança de PMT, comutações de embaralhamento, reconstrução do índice, execução de limpeza) e de atividade de legendas — para desenhar a linha do tempo do arquivo DVR na interface de administração.
Proteção contra perda acidental¶
Várias operações do admin causam perda do arquivo ou cessação da entrega VOD. Antes de executá-las, a UI mostra confirmação modal:
Excluir DVR Storage — todos os fluxos vinculados perdem acesso VOD; os arquivos ficam no disco mas são inacessíveis via PSS sem o registro.
Trocar o fluxo para outro armazenamento — o VOD sobre o arquivo antigo deixa de funcionar.
Desvincular o fluxo do armazenamento (Storage = 0) — mesmo efeito.
Reduzir Max Usage — pode disparar a limpeza size-based e apagar chunks antigos.
Reduzir Storage Hours / Storage Min Hour — pode tirar parte do arquivo do rolling-window.
Decisão deliberada do produto: a operação é possível mas com confirmação, e os arquivos apagados ficam no disco (restauráveis de backup). Colocar o arquivo em servidor de arquivos / RAID separado reduz muito o risco de perda irreversível.
Limitações da versão atual¶
Uma sessão VOD aberta pelo cliente não acompanha o live edge — se vieram chunks durante a sessão, o cliente deve repedir a playlist (comportamento padrão HLS / DASH).
Atribuir um armazenamento por disco é o recomendado — vários registros com subdiretórios distintos disputam o espaço.
Os segmentos são endereçados por hash (HLS sobre MPEG-TS) ou pelo modelo
$Number$.m4scom uminit.mp4comum (live DASH sobre CMAF) / por<SegmentURL>explícitas para.m4s(VOD DASH). Alterar o tamanho do chunk entre live e VOD não exige reabrir a URL.O orphan scanner roda por hora; para acelerar, reiniciar PSS.
Operações com fluxos¶
Remoção. Para remover um fluxo, abra suas configurações e clique em Delete stream.
Clonagem. Para clonar um fluxo, abra suas configurações e clique em Clone stream.
Ordenação. Para configurar a ordenação dos fluxos clique no botão Sort na janela da lista de fluxos. Em seguida indique a ordem desejada arrastando os fluxos para cima e para baixo na lista. Para salvar a ordem definida clique em Save order, ou em Cancel para descartar as alterações.
Filtragem da lista. Para filtrar a lista de fluxos clique no ícone de busca e digite a string de filtro. Para cancelar, clique na seta voltar.
Operações em grupo. No modo de filtragem da lista de fluxos é possível selecionar vários fluxos marcando as caixas na coluna esquerda. Se houver fluxos selecionados, ficam disponíveis os botões Excluir e Clonar para os fluxos selecionados.
Exportação e importação de fluxos por meio de um script em Python¶
A exportação e importação de configuração é feita por uma playlist .m3u via um script em Python.
É necessário Python 3 no caminho /usr/bin/python3.
Exportação e importação de fluxos pela interface web¶
Na lista de fluxos, ao clicar no botão Playlist, abre-se o diálogo de exportação dos fluxos para uma playlist no formato m3u8. São exportados apenas os fluxos atualmente exibidos, considerando os filtros aplicados na lista.
Configurações:
Host / IP — nome ou endereço do servidor usado para formar as URLs dos fluxos.
Protocols — tipos de protocolos para exportação.
Login — selecionar a conta que será usada para formar as URLs dos fluxos.
Use Display Names — usar o Display name do fluxo em vez do Stream name no arquivo m3u8.
A playlist é baixada como arquivo m3u8 ao clicar no botão Download.
Ao clicar no botão Import Playlist, o diálogo muda para o modo de importação de fluxos a partir de uma playlist no formato m3u8. Durante a importação, os fluxos existentes não são removidos. Em todos os fluxos importados o horário da importação é registrado no campo Note.
Configurações:
Playlist — seleção do arquivo de playlist para importação.
Create Outputs — escolha do protocolo para gerar automaticamente saídas para os fluxos importados.
Output Ports From — número de porta inicial para gerar as saídas.
Output IP — seleção da interface à qual os fluxos de saída são vinculados.
Tags — tags com que os fluxos importados são marcados. Úteis para operações em grupo, por exemplo, remover todos os fluxos importados.
Se no campo Playlist estiver indicado um arquivo a importar, o botão Load Playlist torna-se ativo. Ao clicar em Load Playlist ocorre o pré-carregamento da playlist, e o resultado do parsing é exibido na tabela. Após o parsing da playlist torna-se ativo o botão Import Streams: ao clicá-lo são importados os fluxos e gerados outputs para eles.
Relatórios e diagnóstico¶
A seção Streams exibe os dados de todos os stream em forma de tabela. Pausa está disponível para os papéis admin e restricted admin.
Para cada stream estão disponíveis estatísticas detalhadas e relatórios.
Peers — lista de receptores ativos (clientes). Para cada um há estatísticas separadas.
Análise de fluxos¶
O analisador de fluxos do streamer mede e analisa diversos parâmetros do fluxo MPEG-TS, permitindo avaliar a qualidade.
Input speed — taxa (bitrate) do fluxo em kbps. Muda após o filtro por marcas de PCR. Exibida como gráfico que também mostra o bitrate de saída após o sincronizador.
Raw data speed — a taxa de receção de dados pelo protocolo escolhido. Overhead — a percentagem acrescentada correspondente à sobrecarga do protocolo.
CC errors — perdas de pacotes (CC, discontinuity). São apresentados contadores por intervalo e um contador acumulado durante o stream uptime. É também apresentado um gráfico de histórico.
Scrambled — contadores de pacotes MPEG-TS ES criptografados. Se for ≠ 0, há falhas na decodificação de canais criptografados.
Sync by — fonte de sincronização — PCR.
PCR interval — intervalo entre as marcas de PCR. Recomendado: até 50 ms.
PCR jitter — caracteriza a precisão de sincronização do fluxo de saída; medido como a diferença entre o PCR e o tempo real.
Analyze PCR PMT Gap — é ativado através de uma definição específica. É analisada a dispersão entre PCR e PTS/DTS para cada ES. O histórico é apresentado em forma de gráfico. Uma dispersão excessiva pode causar problemas em leitores com buffer de sincronização reduzido. A análise é ativada pela definição Analyze PAT/PMT/KF.
PAT interval e PMT interval — alteram o intervalo entre tabelas PAT (PMT). Recomendado: até 500 ms. A análise é ativada por Analyze PAT/PMT/KF.
Key Frame interval (intervalo GOP) — o intervalo entre fotogramas-chave (inícios de GOP). Para leitores que se ligam ao fluxo em pontos aleatórios, recomenda-se um valor máximo de 1 s. A análise é ativada pela definição Analyze PAT/PMT/KF.
IDR interval — o intervalo entre quadros IDR, que são verdadeiros pontos de acesso aleatório (SPS / PPS / IDR). É exibido apenas se a fonte transmitir com IDR. Se IDR interval coincidir aproximadamente com Key Frame interval, o fluxo tem closed-GOP: cada GOP abre com um ponto de entrada completo e o reprodutor pode iniciar a partir de qualquer segmento. Se a métrica estiver ausente, o fluxo é open-GOP sem IDR — há quadros-chave, mas eles não são pontos de entrada completos. Essa relação torna imediatamente visível o tipo de estrutura GOP da fonte. A análise é ativada pela configuração Analyze PAT/PMT/KF.
PAT/KF interval — mede o intervalo médio entre o início e o fim da sequência PAT/PMT/SPS/PPS/KF. Dele depende o tempo de arranque da reprodução para leitores que se ligam ao fluxo em pontos aleatórios. A medição é feita no início do KF no fluxo, pelo que o tempo de arranque real do leitor será maior. A análise é ativada pela definição Analyze PAT/PMT/KF.
Ativar Analyze PAT/PMT/KF coloca o analisador do fluxo em modo permanente, aumentando a carga de CPU.
Controle do jitter¶
Para gerenciar o jitter existem várias configurações no stream:
Jitter Compensation Delay (ms) — função de compensação do jitter de rede; define o tamanho do buffer. Descrição detalhada: https://forum.pstreamer.tv/viewtopic.php?t=25
Jitter Auto sync — ativa 2000 ms para protocolos baseados em TCP (HTTP, HLS); para os protocolos UDP o valor permanece em 500 ms.
Limit PCR gap (ms) — verifica o quanto o PCR pode saltar; se ultrapassar, ocorre resincronização.
Se após o transcodificador surgirem erros PCR Accuracy, é necessário definir um bitrate uniforme por meio do stuffing para o fluxo codificado pelo caminho: «input — transcoder — Align Total Bitrate». A velocidade deve ser definida garantidamente acima do bitrate de vídeo e áudio.
PCR drift¶
A métrica PCR drift mede o desvio sistemático da frequência de relógio da fonte em relação ao tempo real e é expressa em ppm (parts-per-million). Ao contrário do PCR jitter instantâneo, que captura a oscilação de marcas individuais, PCR drift caracteriza precisamente a deriva do cristal do codificador a longo prazo — um desvio estável que se acumula ao longo de minutos e horas.
A medição é realizada por regressão linear sobre pares (tempo PCR acumulado em segundos, tempo de recepção em segundos). O ruído de medição decai como 1/T^1.5 com o crescimento da janela, de modo que um veredito confiável só é possível em intervalos longos. A janela se expande automaticamente até 300 s (TR 101 297), após o que é aplicado um reancoramento deslizante com um limite de 6 horas — isso elimina a perda de precisão por estouro da mantissa float64.
As estatísticas XML do stream exportam:
pcr-drift-ppm— veredito atual da regressão;pcr-drift-window-s— comprimento da janela sobre a qual o veredito foi calculado;pcr-drift-samples— número de pontos na regressão.
A tolerância definida por ISO/IEC 13818-1 §2.4.2.1 é de ±30 ppm. Em caso de excesso sustentado (consulte a seção de alertas abaixo), um atributo dedicado pcr-drift-alert é definido, e após 300 s de violação contínua — pcr-drift-alert-acceptance (nível de aceitação TR 101 297).
Expor PCR drift como atributo autônomo (em vez de incluí-lo no tr101290-alert comum) é intencional: a deriva do cristal é um problema do codificador a montante, não do receptor, e o operador deve vê-la separadamente, sem misturá-la com erros de integridade do transporte.
PCR accuracy¶
A métrica PCR accuracy (seção P2.3 em TR 101 290) mede a precisão da inserção das marcas PCR no fluxo de transporte. Conforme a especificação, o valor de cada PCR deve coincidir com o momento efetivo de sua passagem pelo multiplexador com um erro não pior que ±500 ns.
A medição é feita como sinal residual (residual) de uma regressão linear em uma janela deslizante de 30 s. O tamanho da janela é escolhido para capturar todo o ciclo de repetição do PCR (≤40 ms segundo a especificação) com ampla margem, mas mantendo uma resposta rápida à deterioração da qualidade de inserção.
As estatísticas XML do stream exportam pcr-accuracy-max-ns — o valor de pico do residual na janela. Ao exceder ±500 ns, o token pcr-acc é adicionado ao atributo comum tr101290-alert.
A medição só faz sentido para multiplex CBR: em VBR, os intervalos entre PCR podem divergir da tendência linear estimada sem violar o padrão. O analisador desativa automaticamente o token pcr-acc para fluxos classificados como vbr (consulte a seção sobre o detector de modo).
Compensador de desvio de PCR¶
Se o PCR drift da fonte estiver dentro da tolerância da ISO/IEC 13818-1 mas ainda for diferente de zero, o fluxo de saída «se afasta» lentamente em relação ao tempo de rede do receptor. Em um player com buffer pequeno, isso se manifesta como perda acumulada de sincronização ou solavancos periódicos na reprodução.
O compensador elimina o desvio sem ressincronização rígida: os pacotes de saída recebem um microdeslocamento de ~11.1 µs (duração de um pacote TS de 188 bytes a 100 Mbps), e a decisão «se o deslocamento é necessário» é tomada com base na diferença efetiva entre o tempo de rede e o ritmo do PCR. O resync rígido (Limit PCR gap) permanece como recurso de contingência para rupturas de fluxo — o compensador opera em uma escala mais fina e preserva a continuidade.
Configurações em stream:
Sync Drift Compensation — ativa/desativa o compensador. Ativado por padrão.
Sync Drift Soft Window — janela suave dentro da qual as correções são aplicadas uma a uma (1–60000 ms, padrão 500). O limite superior é restrito por
8 × Sync Disc Window, a partir do qual considera-se necessário um resync rígido.
As estatísticas XML exportam slew-adjust-count — o contador de correções desde reset-stat. Um crescimento abrupto desse contador significa que a fonte saiu de sua tolerância ou possui um cristal instável.
Analisador de buffer de vídeo T-STD¶
O modelo T-STD (Target Decoder) está descrito em ISO/IEC 13818-1 §2.4.2. É o modelo de referência do buffer do receptor: se ele for respeitado, garante-se que o fluxo será reproduzido por qualquer decodificador de hardware conforme.
O analisador modela o buffer MBn (multiplex buffer para vídeo) e verifica que:
o buffer não estoura (overflow → o codificador é obrigado a descartar quadros);
o buffer não esvazia (underflow → o decodificador mostra uma pausa ou artefatos).
Ativado pela configuração Analyze T-STD video (desativado por padrão — adiciona carga de CPU no caminho de processamento crítico).
Tipos de ES de vídeo suportados (stream_type):
0x01/0x02— MPEG-2 video, capacidade 750 KB;0x10— MPEG-4 part 2, capacidade 750 KB;0x1B— H.264 / AVC, capacidade 3 MB;0x24/0x25— HEVC, capacidade 3.75 MB.
A taxa de drenagem (drain rate) é ajustada adaptativamente à taxa de bits real do vídeo: utiliza-se uma média móvel exponencialmente ponderada (EMA) com α=0.2 em uma janela de 5 s. Sem adaptação, o modelo produz rapidamente falsos underflows em qualquer vídeo VBR.
O buffer é drenado pelos pulsos de PCR (90 kHz) e não pelo tempo do sistema do host — isso torna a análise robusta frente a pausas do SO e flutuações de carga de CPU. O tempo real do host é utilizado apenas para verificar o funcionamento do compensador de desvio, nunca para T-STD.
As estatísticas XML exportam:
tstd-video-cap— capacidade do modelo em bytes;tstd-video-drain-bps— taxa de drenagem adaptada atual, bytes/s;tstd-video-overflows— contador de overflows desdereset-stat;tstd-video-underflows— contador de underflows;tstd-video-max-fill— ocupação de pico em bytes.
Diante de qualquer contador diferente de zero (overflows > 0 ou underflows > 0), o token tstd-video é adicionado ao tr101290-alert comum. Assim como pcr-acc, o token aplica-se apenas a fluxos CBR — em um multiplex VBR quedas transitórias do buffer são admissíveis.
Detector de modo de taxa de bits do multiplex¶
Parte dos testes de TR 101 290 só faz sentido no modo CBR (taxa de bits do multiplex constante). Para não emitir alertas falsos em canais VBR, o analisador determina automaticamente o modo da fonte e exporta o veredito no atributo bitrate-mode-detected.
Algoritmo: comparação das taxas de bits médias em duas janelas — 5 s e 60 s. Se a divergência exceder 20 %, o fluxo é marcado como vbr; se ficar dentro, cbr. Até que a estatística se acumule (~70 s desde o início ou desde reset-stat), o veredito é unknown e os testes exclusivos de CBR (pcr-acc, tstd-video) ficam temporariamente suprimidos.
Valores do atributo:
cbr— taxa de bits constante, todos os testes ativos;vbr— taxa de bits variável,pcr-accetstd-videoestão desativados;unknown— dados insuficientes, os testes exclusivos de CBR estão suspensos.
Alertas TR 101 290¶
O atributo agregado tr101290-alert combina vários detectores de conformidade com TR 101 290. Se ao menos um estiver ativo no momento atual, o atributo contém uma lista de tokens separados por espaços; caso contrário, o atributo está ausente do XML.
Tokens possíveis e seu significado:
pcr-int— intervalo entre PCR excedido (seção 5.2.4 de TR 101 290, limite 40 ms, recomendação ≤25 ms);pcr-acc— precisão de inserção de PCR excedida (seção 5.2.5, ±500 ns, CBR-only);pcr-disc— foi detectado um resync rígido por PCR (seção 5.2.4,PCR_discontinuity_indicator_error);pat-int— intervalo de PAT excedido (seção 5.1.3, limite 500 ms, requer Analyze PAT/PMT/KF);pmt-int— intervalo de PMT excedido (seção 5.1.5, limite 500 ms, requer Analyze PAT/PMT/KF);tstd-video— foi detectado um overflow ou underflow do modelo T-STD (seção 5.3.16, requer Analyze T-STD video, CBR-only).
Para evitar a cintilação do indicador em rajadas curtas, é aplicada uma lógica de debounce: um token entra em tr101290-alert apenas se tiver sido acionado por pelo menos 30 dos últimos 60 segundos. Isso se aplica uniformemente a todos os tokens.
Adicionalmente é exportado tr101290-alert-acceptance — uma cópia do atributo na qual um token só aparece após 300 s de violação contínua (nível de aceitação de TR 101 297). É a métrica agregada «final» para a aceitação técnica do canal.
O indicador pcr-drift é deliberadamente separado em seu próprio pcr-drift-alert (+ pcr-drift-alert-acceptance). A deriva do cristal é um problema do codificador a montante, é independente da integridade do transporte e deve ser classificada separadamente.
Assistente de IA para reclamações¶
Se em um canal forem disparados alertas TR 101 290 ou PCR drift, o operador pode obter em uma única solicitação um prompt em inglês pronto para um chat de IA que redigirá uma carta formal de reclamação ao provedor a montante do fluxo.
Endpoint: GET /data/stream/<id>/ai-complaint-prompt. Disponível com o papel Viewer (assim como todas as requisições GET sob /data/*). Retorna text/plain; charset=utf-8. Para MPTS é retornado 404 — as métricas T-STD / PCR drift só se aplicam a SPTS.
O prompt é compatível com qualquer chat de IA moderno: «ChatGPT», «Claude», «DeepSeek», «Qwen», «Doubao». O tom da carta é profissional, sem acusações; ao final do prompt é adicionada a escolha do idioma do documento resultante: inglês, russo, chinês simplificado ou qualquer outro à escolha do operador.
Conteúdo do prompt:
nome e parâmetros medidos do stream;
a lista de todos os tokens ativos de TR 101 290 e PCR drift com a referência ao padrão;
valores numéricos e limiares;
o impacto de cada erro no lado do decodificador.
O que não entra no prompt: nome do stream, ID, URI da fonte. Esses campos são substituídos pelo marcador <Stream Designation> — o operador os preenche antes do envio, para que não vazem para um serviço de IA de terceiros.
System Monitor¶
Controle dos principais parâmetros do sistema operacional.
Mosaic¶
Função de captura de tela do fluxo de entrada. Ativada individualmente para cada stream.
Se não for necessária, pode ser totalmente desativada em Settings/Server Settings para economizar recursos.
Administração¶
Em Configuration/Administration/Administrators List são adicionados os usuários para acessar a interface web — servidor HTTP embutido.
Aos usuários são atribuídos papéis:
admin — acesso total.
restricted admin — as configurações não estão acessíveis; apenas o valor pause pode ser alterado.
viewer — acesso apenas em modo de visualização.
Backup das configurações¶
Para fazer backup das configurações, salve o conteúdo da pasta /opt/pss/config.
Para restaurar as configurações, pare o serviço e substitua o conteúdo da pasta /opt/pss/config.
Comportamento na inicialização e erros de configuração¶
Na inicialização, o serviço tenta carregar sucessivamente os arquivos de configurações do diretório /opt/pss/config:
pss.json — arquivo principal de configurações.
pss_back.json — cópia de segurança da configuração de trabalho anterior.
pss_default.json — configurações padrão, entregues com o pacote.
É usado o primeiro arquivo carregado com sucesso. Se os três arquivos estiverem ausentes ou corrompidos, o serviço inicia com configurações vazias; nesse caso é necessária a edição manual da senha do administrador e a reinicialização.
Arquivo de configurações estruturalmente corrompido. Se pss.json contém um erro de sintaxe JSON, chaves desconhecidas, um tipo de valor incorreto ou uma violação de unicidade (por exemplo, dois fluxos com o mesmo id), o serviço move o arquivo corrompido para o diretório /opt/pss/config/bad/ com um nome do tipo pss_YYYYMMDD_HHMMSS.json (data e hora da inicialização). Em seguida, o serviço continua as tentativas de carregamento na ordem habitual e regrava a configuração de trabalho em pss.json a partir de pss_back.json ou pss_default.json. Detalhes (nome da chave, descrição do erro, nome do arquivo no arquivo) são registrados no log do serviço.
Apenas o pss.json principal vai para o arquivo. Os arquivos pss_back.json e pss_default.json não são arquivados quando corrompidos — as entradas do log são suficientes para diagnóstico, e os próprios arquivos permanecem no lugar e podem ser corrigidos manualmente.
Se no momento do próximo carregamento já existir em /opt/pss/config/bad/ um arquivo com o mesmo carimbo de data/hora (por exemplo, em reinicializações rápidas dentro do mesmo segundo), ele é sobrescrito.
Valores numéricos fora do intervalo permitido. Se o arquivo de configurações contiver um valor numérico inferior ao mínimo ou superior ao máximo permitido para esse parâmetro, o serviço não descarta o arquivo por completo. Em vez disso, um aviso é registrado no log indicando o nome do parâmetro, o valor lido e o limite aplicado; o próprio valor é ajustado ao limite mais próximo do intervalo permitido (mínimo ou máximo). Após a conclusão do carregamento, o serviço regrava pss.json automaticamente com os valores corrigidos, de modo que em uma reinicialização posterior esses avisos não aparecem mais.
Esse comportamento aplica-se apenas ao carregamento inicial do arquivo de configurações. Ao alterar as configurações pela interface web ou por uma API externa, os valores fora do intervalo permitido continuam sendo rejeitados com erro, sem correção automática.
Integração de sistemas externos de monitoramento¶
pss-metrics — exportador universal de métricas para Perfect Streamer
Um único script CLI em Python 3 que obtém estatísticas da API HTTP do servidor web do PSS e gera saída para os sistemas de monitoramento mais comuns:
Zabbix (UserParameter, Low-Level Discovery, zabbix_sender trapper)
Prometheus (formato de exposição de texto para o textfile collector)
InfluxDB / Telegraf (line protocol ou JSON para o input exec)
JSON universal para scripts arbitrários e verificações de estado no estilo Nagios
O exportador é um arquivo único e autocontido, sem dependências de terceiros, e usa apenas a biblioteca padrão do Python 3.6+ (urllib, xml.etree, json, argparse).
Arquivos¶
pss-metrics.py main CLI (executable)
userparameter_pss.conf.example UserParameter template for Zabbix
Instalação¶
O exportador é entregue em /opt/pss/monitoring/pss-metrics.py. Verifique se o Python 3.6 ou posterior está instalado:
# RHEL / Rocky / AlmaLinux
yum install -y python3
# Debian / Ubuntu
apt-get install -y python3
Nenhum pacote adicional é necessário.
Configuração¶
Por padrão, pss-metrics conecta-se a http://127.0.0.1:43971 e detecta automaticamente a porta a partir de /opt/pss/config/pss.json (ou /opt/pss/config/pss_default.json). Os parâmetros podem ser sobrepostos por variáveis de ambiente, pelo arquivo /etc/pss-metrics.conf (formato chave=valor) ou por flags de linha de comando. Prioridade: CLI > env > arquivo > valores padrão.
Variáveis suportadas:
PSS_URL full URL, e.g. http://10.0.0.1:43971 (auto by default)
PSS_USER web server login (if authorization is enabled)
PSS_PASS web server password
PSS_TIMEOUT HTTP timeout, in seconds (default 5)
PSS_CACHE_DIR cache directory (default /run/pss-metrics)
PSS_CACHE_TTL cache TTL, in seconds (default 10)
PSS_CA_BUNDLE path to CA bundle for HTTPS
PSS_INSECURE 1 — disable TLS certificate verification
PSS_VERBOSE 1 — log requests to stderr
Cache: cada execução faz no máximo um HTTP GET por endpoint dentro da janela de TTL. Com TTL=10 s, mesmo centenas de verificações de UserParameter por minuto resultam em ~6 requisições HTTP por minuto ao PSS.
Início rápido¶
Verificação de estado (códigos de saída no estilo Nagios):
pss-metrics.py health
# OK: total=42 running=15 stopped=27 unhealthy=0 version=1.12.2.430d
Descoberta LLD do Zabbix:
pss-metrics.py discover streams
pss-metrics.py discover inputs --running-only
pss-metrics.py discover outputs
Obtenção de uma única métrica (para uso em UserParameter do Zabbix):
pss-metrics.py get summary.running
pss-metrics.py get stream.10031.bitrate
pss-metrics.py get input.10031.1.speed1
pss-metrics.py get output.10031.1.speed
pss-metrics.py get sysmon.cpu.self-usage
pss-metrics.py get server.server-version
Exportação completa:
pss-metrics.py dump --format=json
pss-metrics.py dump --format=prometheus
pss-metrics.py dump --format=influx
pss-metrics.py dump --format=zabbix-trapper --zabbix-host=streamer-01
Caminhos das métricas¶
pss-metrics get aceita um caminho separado por pontos. Saída vazia significa «valor ausente» (por exemplo, a métrica só existe para fluxos em execução).
server.<attr> e.g. server.server-version, server.uptime
summary.<key> total | running | stopped | unhealthy |
input_bitrate_kbps | output_bitrate_kbps
sysmon.cpu.<attr> self-usage | total-usage | cores
sysmon.memory.<attr> self-usage-kb | available-kb | total-kb
sysmon.netbw.<iface>.<attr> rx-bw | tx-bw (interface name as in XML)
stream.<id>.<attr> any <stream> attribute
input.<sid>.<iid>.<attr> any <input> attribute
output.<sid>.<oid>.<attr> any <output> attribute
Atributos úteis por fluxo (de /data/stream/detail):
stream: state, state-str, bitrate, thread-usage, mpts
input: speed1, recv-bytes, recv-packets, recv-err,
stat-disc, stat-disc1, stat-scrambled, stat-scrambled1,
health-state-good, health-status, check-status
output: speed, sent-bytes, sent-packets, sent-err, uri, type
Integração com Zabbix¶
Dois cenários são suportados — escolha o que se adequa ao seu ambiente.
UserParameter estático + LLD (agente Zabbix v1 / v2)
Copie userparameter_pss.conf.example para /etc/zabbix/zabbix_agentd.d/pss.conf, reinicie o zabbix-agent e importe no servidor um template com protótipos LLD que utilizem as chaves pss.discover. Exemplos de associações:
UserParameter=pss.discover[*],/opt/pss/monitoring/pss-metrics.py discover $1 UserParameter=pss.get[*],/opt/pss/monitoring/pss-metrics.py get $1 UserParameter=pss.health,/opt/pss/monitoring/pss-metrics.py health
No servidor Zabbix:
Discovery rule key: pss.discover[streams] Item prototype keys: pss.get[input.{#STREAM_ID}.1.speed1] pss.get[stream.{#STREAM_ID}.bitrate] pss.get[summary.unhealthy]Trapper (push) por zabbix_sender
Execute por temporizador (cron / systemd) e direcione a saída para um pipe:
/opt/pss/monitoring/pss-metrics.py dump --format=zabbix-trapper \ --zabbix-host="$(hostname)" \ | zabbix_sender -z zabbix.example.com -i -
Integração com Prometheus¶
Duas opções.
Textfile collector (recomendado para ambientes one-shot).
Execute uma exportação periódica via systemd-timer ou cron:
*/1 * * * * /opt/pss/monitoring/pss-metrics.py dump --format=prometheus \ > /var/lib/node_exporter/textfile_collector/pss.prom.$$ \ && mv /var/lib/node_exporter/textfile_collector/pss.prom.$$ \ /var/lib/node_exporter/textfile_collector/pss.promO node_exporter disponibiliza o arquivo via –collector.textfile.directory.
Scrape direto por meio de um pequeno wrapper (por exemplo socat + pss-metrics dump) ou qualquer proxy HTTP de terceiros à sua escolha.
Integração com Telegraf / InfluxDB¶
Telegraf inputs.exec:
[[inputs.exec]]
commands = ["/opt/pss/monitoring/pss-metrics.py dump --format=influx"]
interval = "10s"
timeout = "5s"
data_format = "influx"
Para o parser JSON, use –format=json e configure data_format = «json» com os caminhos dos campos.
HTTPS e autenticação¶
Se o servidor web do PSS opera atrás de HTTPS ou é protegido por senha:
PSS_URL=https://streamer.example.com:8443 \
PSS_USER=monitor PSS_PASS=secret \
pss-metrics.py health
Certificados autoassinados: defina PSS_INSECURE=1 (não recomendado) ou informe PSS_CA_BUNDLE=/path/to/ca.pem.
Códigos de saída¶
pss-metrics segue a convenção do Nagios:
0 OK
1 WARNING (e.g. running streams report unhealthy)
2 CRITICAL (PSS is unreachable)
3 UNKNOWN (invalid arguments / internal error)
get e dump produzem uma linha vazia e encerram com código 0 quando a entidade solicitada está ausente — isso corresponde à expectativa do Zabbix de que um valor vazio seja tratado como «NOT_SUPPORTED» e não como falha do agente.
Diagnóstico¶
pss-metrics.py -v health # log every HTTP request to stderr
pss-metrics.py --cache-ttl=0 … # bypass cache while debugging
rm -rf /run/pss-metrics # purge cache
Let’s Encrypt e certbot para HTTPS¶
A partir da versão 1.9.2.340, o Perfect Streamer suporta renovação automática de certificados Let’s Encrypt para HTTPS no Web Server, HTTP Server e EPG Server.
Configuração do certbot para RHEL.¶
Limitação:
A porta TCP/80 deve estar livre e deve ser atribuído um IP público com nome de domínio público.
Todos os servidores HTTPS usam o mesmo nome de host (web server, http server, epg server).
Instalação do certbot (https://certbot.eff.org/instructions?ws=other&os=snap):
sudo yum install snapd
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install certbot --classic
Configuração do certbot:
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot certonly --standalone
Verificação do certbot:
sudo certbot renew --dry-run
Verificação do timer do certbot:
systemctl list-timers | grep certbot
No painel admin do Perfect Streamer, ative o HTTPS nos servidores (Web Server, HTTP Server, EPG Server).
Crie o script de hook (https://pstreamer.tv/distrib/scripts/cert_update.zip) e coloque-o no caminho:
/opt/pss/scripts/cert_update.sh
Ali, se necessário, indique o nome de domínio do host; por padrão é lido de /etc/hostname.
Tornar o arquivo executável.
chmod +x /opt/pss/scripts/cert_update.sh
Verificar a execução do script, não deve haver erros:
/opt/pss/scripts/cert_update.sh
As configurações HTTPS devem ser aplicadas; a mudança de status aparecerá nos logs.
Adicionar arquivo de hook ao certbot:
certbot renew --deploy-hook "/opt/pss/scripts/cert_update.sh"
Verificar o certbot novamente:
sudo certbot renew --dry-run
Configuração do certbot para Debian/Ubuntu.¶
A configuração no Debian é análoga ao RHEL; descrição breve no exemplo de Ubuntu 24.04.2 LTS.
Instalação do certbot:
apt install certbot
certbot certonly
Tornando o script executável:
chmod +x /opt/pss/scripts/cert_update.sh
Executando o script:
/opt/pss/scripts/cert_update.sh
Emite:
Select domain name (your domain name)
Verificar se os certificados foram renovados:
ls -lat /opt/pss/config/cert/
total 44
-rw------- 1 root root 241 May 26 07:52 epgserver.key
-rw------- 1 root root 241 May 26 07:52 httpserver.key
-rw------- 1 root root 241 May 26 07:52 webserver.key
-rw-r--r-- 1 root root 1338 May 26 07:52 epgserver.crt
-rw-r--r-- 1 root root 1338 May 26 07:52 httpserver.crt
-rw-r--r-- 1 root root 1338 May 26 07:52 webserver.crt
A data deve ser atual.
Adaptadores DVB¶
Perfect Streamer suporta qualquer adaptador DVB instalado no sistema. Padrões suportados: DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C, ATSC. Adicionalmente implementados: desencapsulamento T2-MI (ETSI TS 102 773) e descodificação BISS-1 / BISS-E.
A condição principal é um controlador de adaptador corretamente instalado e em funcionamento no sistema.
A secção DVB aparece apenas se o sistema possuir adaptadores DVB válidos. A reconfiguração em tempo de execução não é suportada; é necessário reiniciar o streamer.
Ligação do adaptador¶
Para adicionar um novo adaptador DVB, aceda à secção correspondente e adicione o adaptador:
Definir o nome do adaptador.
Selecionar um adaptador da lista dos disponíveis no sistema.
Selecionar o modo Stream.
Especificar o tipo de sistema de transmissão: DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C.
Especificar os parâmetros de receção: Frequência da portadora, Polarização, Taxa de símbolo, FEC, Modulação, ID do fluxo DVB, Frequência do oscilador, Oscilador da banda alta, Limite da banda alta, Modo DiSEqC 1.0 e outros parâmetros consoante o tipo.
Opcionalmente pode ativar-se o registo de EIT na base de dados EPG (Registar EIT na BD EPG).
Repetir a adição para cada adaptador presente no sistema.
Varredura DVB¶
Para evitar introduzir manualmente os parâmetros de receção (frequência, polarização, taxa de símbolo, FEC, modulação), o Perfect Streamer integra um scanner de transponders. O scanner percorre os transponders do satélite selecionado (DVB-S/S2) ou da banda regional (DVB-C, DVB-T/T2), efetua a sintonização e a captura de cada um, recolhe as tabelas PSI/SI (PAT, PMT, SDT) e constitui a lista final de multiplex com os respetivos programas. Qualquer multiplex encontrado pode ser adicionado à lista de adaptadores DVB com um único botão.
O scanner utiliza o adaptador físico na sua totalidade; para o iniciar é necessário um adaptador que não esteja a ser utilizado pelo kernel do sistema operativo nem por qualquer entrada de adaptador DVB ativa no Perfect Streamer.
Adaptadores disponíveis¶
Ao abrir o ecrã de varredura no painel de administração, é apresentada uma lista dos adaptadores DVB físicos do sistema com o respetivo estado de ocupação:
free — o adaptador está disponível para varredura.
kernel — o dispositivo está retido por outro processo do sistema operativo.
pss-id-N — o adaptador já está a ser utilizado por uma entrada de adaptador DVB no Perfect Streamer com o identificador indicado. Não é possível iniciar o scanner nele enquanto essa entrada estiver ativa. Para libertar o adaptador temporariamente, a entrada de adaptador DVB existente deve ser colocada em pausa (o indicador Pause nas suas definições).
Listas de transponders¶
O scanner baseia-se em listas de referência no formato Enigma2: a lista de satélites satellites.xml e as listas regionais cables.xml / terrestrial.xml. Cada ficheiro contém um conjunto de transponders para uma posição orbital conhecida ou para uma banda regional DVB-T/C (para mais detalhes, consulte o site do projeto oe-alliance-tuxbox-common).
Os ficheiros encontram-se no diretório sat/ relativo a pss.json (por predefinição /etc/pss/sat/). São fornecidos com a distribuição do Perfect Streamer e são carregados ao abrir o ecrã de varredura. Quando necessário, podem ser atualizados substituindo o ficheiro XML correspondente.
No painel de administração, as listas de referência são apresentadas em três listas:
Satélite — posições orbitais (por exemplo, Hot Bird 13.0°E, Astra 19.2°E).
Região cabo — país ou fornecedor DVB-C.
Região terrestre — região DVB-T/T2.
Se o satélite ou a região pretendidos não estiverem presentes nas listas de referência, é possível atualizar o XML ou utilizar em alternativa a varredura cega (ver abaixo).
Início¶
Na caixa de diálogo de varredura, definem-se sequencialmente os seguintes elementos:
Um adaptador físico livre.
Tipo de delivery system: DVB-S, DVB-S2, DVB-T, DVB-T2 ou DVB-C.
Fonte:
para DVB-S/S2 — uma posição orbital da lista de satélites e os parâmetros LNB (frequências do oscilador local LO1 e LO2, limite da banda superior, porta DiSEqC);
para DVB-C — uma região cabo;
para DVB-T/T2 — uma região terrestre.
Após premir Iniciar, a varredura é executada em segundo plano. O progresso é apresentado no painel de administração:
a percentagem de progresso baseada no número de transponders processados;
a frequência e a polarização atuais;
os contadores Multiplex encontrados e Programas encontrados;
uma árvore dos multiplex já encontrados, expansível até aos programas.
O scanner é um recurso partilhado em todo o streamer: executa-se no máximo uma varredura de cada vez. Se for iniciada uma nova varredura enquanto outra está em curso, a anterior é automaticamente cancelada. O botão Cancelar interrompe a varredura e limpa a lista acumulada.
A duração da varredura depende do número de transponders na lista de referência selecionada (tipicamente até 5 segundos por transponder: até 2 segundos para o bloqueio do sinal e até 5 segundos para a recolha das PSI). Valores típicos:
DVB-S Hot Bird 13.0°E — cerca de 2 minutos (44 transponders).
DVB-S Astra 19.2°E — cerca de 1,5 minutos.
DVB-T região europeia — menos de um minuto.
Resultado¶
O resultado da varredura é apresentado como uma árvore multiplex → programas.
Parâmetros do multiplex:
frequência, polarização, taxa de símbolo;
FEC, modulação, delivery system;
identificador do fluxo de transporte (TSID);
as leituras do frontend no momento em que termina a recolha das PSI — SNR, Signal, BER;
os contadores pmt-total / pmt-recv — quantas tabelas PMT foram anunciadas pela PAT e quantas foram efetivamente recolhidas dentro do tempo limite.
Parâmetros do serviço:
PNR (program_number) — o identificador do serviço dentro do multiplex;
Nome e Fornecedor — obtidos da tabela SDT, em UTF-8;
scrambled — o indicador de codificação. A sua origem é determinada pela seguinte ordem: o bit
free_CA_modeda SDT (declaração do broadcaster) → os indicadores de codificação de transporte da PMT. Se nem a SDT nem a PMT chegarem dentro do tempo limite, o valor predefinido é 0 («não codificado»); o estado real é apurado quando se tenta a receção;video-pid, audio-pid, pcr-pid — os principais fluxos elementares do serviço.
Aplicação do resultado¶
O multiplex selecionado na árvore é adicionado à lista de adaptadores DVB com um único botão. É criada uma nova entrada com os parâmetros do resultado da varredura (frequência, polarização, taxa de símbolo, FEC, modulação, delivery system) juntamente com os parâmetros LNB e o par adapter/device especificados no arranque da varredura. O nome do adaptador é definido pelo utilizador; os parâmetros adicionais (chaves BISS para canais codificados, T2-MI, LNB partilhado, etc.) são preenchidos após a criação da entrada, nas suas definições.
Os programas dos multiplex encontrados são aplicados em separado — criando um fluxo (Stream) com uma fonte de entrada demuxer endereçada pelo PNR (ver a secção Ligação de um fluxo SPTS a um serviço de multiplex DVB).
Varredura cega¶
O modo cego é utilizado quando:
o satélite pretendido não consta das listas de referência (posição orbital não normalizada, uplink local);
as listas de referência regionais DVB-T/C são insuficientes ou estão desatualizadas para uma localização específica;
é necessário reverificar um troço da banda independentemente da lista de transponders conhecidos.
Neste modo, o scanner não consulta as listas de referência; sintetiza uma lista de transponders a partir de uma grelha de frequências. Por predefinição, são utilizadas as seguintes gamas típicas:
DVB-S/S2 Ku — 10700..12750 MHz, passo de 4 MHz, ambas as polarizações (H e V), taxas de símbolo típicas 22000 / 27500 / 30000 ksym/s.
DVB-C — 47000..862000 kHz, passo de 8000 kHz, QAM-64 e QAM-256, taxas de símbolo típicas 6875 / 6900 / 6952 ksym/s.
DVB-T/T2 — 174000..862000 kHz, passo de 8000 kHz.
Uma varredura cega completa da banda Ku demora cerca de 100 minutos (vários milhares de pontos de sintonização). Na prática, o intervalo é restringido manualmente no painel de administração — frequência mínima/máxima e passo da grelha. Por exemplo, uma varredura de 11700..11800 MHz com passo de 4 MHz para uma única banda LNB demora cerca de 5 minutos.
O formato do resultado de uma varredura cega é idêntico ao de uma varredura normal. Particularidades:
os campos FEC e Modulação dos multiplex encontrados ficam fixados no valor AUTO — o scanner não determina os seus valores exatos;
o delivery system é igual ao solicitado (DVB-S, DVB-S2, …). Para redes mistas, recomenda-se efetuar duas passagens — DVB-S e DVB-S2 em separado.
A aplicação de um multiplex proveniente de uma varredura cega é efetuada da mesma forma que num caso normal — através do botão que o adiciona à lista de adaptadores DVB. Os campos FEC e Modulação são geralmente deixados em AUTO e, se necessário, afinados após um bloqueio estável do sinal no transponder em causa.
Tamanho do buffer de receção do kernel¶
O parâmetro buffer-size (inteiro, valor predefinido 512) define o tamanho do buffer circular DVB demux do kernel em blocos de 65536 bytes.
512(32 MB) — valor predefinido recomendado. Cobre cenários DVB-S/S2 de transponder completo (>= 33 Mbit/s) com um ou vários consumidores MPTS. Selecionado com base em testes de bancada com um adaptador TBS sob carga total do transponder.8...64(512 KB … 4 MB) — aceitável para sistemas embarcados com RAM limitada ou para adaptadores nos modos Scanner / Femon onde o tráfego é baixo.0— manter o valor predefinido do controlador (normalmente 8…32 KB). Adequado apenas para cenários com muito pouca carga. Acima de 10 Mbit/s haverá perdas.
Quando uma mensagem da seguinte forma aparecer no registo:
DVB adapter X/Y dvr buffer overflow (NN so far, KK pids);
raise 'buffer-size' or reduce pid filter
aumentar buffer-size ou reduzir o número de PIDs que passam pelo filtro (por exemplo, eliminar a saída MPTS se não for necessária).
Custo de memória: o valor N consome N × 64 KB de memória do kernel por adaptador. Com muitos adaptadores (8 ou mais) convém tê-lo em conta (8 × 32 MB = 256 MB).
Ligação de um fluxo SPTS a um serviço de multiplex DVB¶
Ao adicionar um novo canal SPTS ao input do fluxo, selecionar:
Tipo: demuxer.
Fonte: adaptador DVB.
Multiplex criado no adaptador DVB, por nome do adaptador.
PNR — selecionado a partir da lista emergente de serviços detetados no multiplex ou introduzido manualmente.
Permissões de acesso aos dispositivos DVB¶
Se os adaptadores DVB não forem apresentados no Perfect Streamer, executar as seguintes ações:
sudo nano /etc/udev/rules.d/99-dvb-permissions.rules
SUBSYSTEM=="dvb", GROUP="video", MODE="0660"
sudo usermod -aG video pss
sudo chown -R root:video /dev/dvb/*
sudo reboot
Desencapsulamento T2-MI¶
T2-MI (T2-Modulator Interface, ETSI TS 102 773) é um formato para transportar fluxos DVB-T2 sobre DVB-S2 multistream. O transponder externo DVB-S/S2 transporta um ou mais T2-MI carrier-PIDs, cada um encapsulando BBFRAMEs com um ou mais PLPs (Physical Layer Pipe). Após o desencapsulamento, extrai-se do BBFRAME o MPEG-TS interno contendo os programas e as tabelas PSI/SI.
A implementação Perfect Streamer funciona no modo multi-carrier: um único adaptador físico entrega simultaneamente o multiplex DVB-S/S2 externo e todos os carriers T2-MI desencapsulados (um por cada carrier-PID encontrado no PMT do fluxo externo).
Parâmetros de configuração¶
t2mi-mode (Int, 0..2, valor predefinido 0) — modo de desencapsulamento:
0— Desativado. O MPEG-TS externo é transmitido sem processamento. Se for detetado um descritor T2-MI (tag 0x51) no PMT, é registada uma dica única.1— Manual. O desencapsulamento está sempre ativo. Set2mi-pidnão for 0, é pré-criado um carrier nesse PID no arranque. Os carriers adicionais continuam a ser detetados automaticamente a partir do PMT.2— Auto. Os carriers são detetados automaticamente a partir do PMT do multiplex externo para todos os ES que pareçam T2-MI (descritor 0x51 ou único ES com stream_type=0x06 num serviço sem outros ES A/V). Se não forem encontrados carriers, o adaptador funciona como um multiplex DVB normal.
t2mi-pid (Int, 0..8191, valor predefinido 0) — PID para pré-criar um carrier no arranque, antes da chegada do PMT:
0— sem pré-criação. Os carriers são detetados a partir do PMT (recomendado para o modo auto2).1..8191— pré-criar um carrier neste PID. Os T2-MI ES adicionais encontrados no PMT obtêm igualmente os seus próprios carriers.
No modo multi-carrier o parâmetro t2mi-pid não é um seletor de um único carrier — cada ES T2-MI detetado obtém o seu próprio carrier com o seu próprio desencapsulador. O parâmetro disponibiliza inicialização antecipada para um PID conhecido.
t2mi-plp (Int, 0..255, valor predefinido 0) — identificador do PLP extraído de cada carrier T2-MI no adaptador. Aplica-se a todos os carriers — a substituição por carrier não é suportada na versão atual. Se em produção diferentes carriers transportarem diferentes PLPs, convém:
especificar um PLP comum a todos os carriers, ou
configurar adaptadores separados para diferentes PLPs através de
lnb-sharing.
Este é o identificador do campo plp_id do BBFRAME, não o ISI multistream DVB-S2 (definido pelo parâmetro dvb-stream-id). São identificadores diferentes em camadas diferentes.
Diagnóstico de seleção PLP:
Cinco segundos depois do arranque de um carrier, se não tiver sido recebida nenhuma BBFrame para o PLP configurado mas se observarem outros PLPs, é registado um aviso com a lista dos
plp_idobservados.
t2mi-tsid (Int, -1..255, valor predefinido -1) — reservado para uso futuro. Seletor do identificador de fluxo T2-MI quando vários fluxos T2-MI partilham um mesmo carrier-PID. Ignorado na versão atual.
PNR composto — ligação SPTS a partir de T2-MI¶
Um adaptador pode expor vários multiplex lógicos:
carrier-id = 0— multiplex DVB-S/S2 externo (serviços A/V normais).carrier-id = 1..N— carriers T2-MI desencapsulados (um por cada ES T2-MI externo).
Descodificação BISS¶
É suportada a descodificação de fluxos DVB cifrados com BISS-1 (modo E1) e BISS-E (modo E2). Aplicável aos sistemas de transmissão DVB-S, DVB-S2, DVB-T, DVB-T2.
A implementação permite manter vários descodificadores ativos em simultâneo num mesmo adaptador:
Por PNR no multiplex externo (serviço normal).
Por
plp_idpara decifrar o carrier-PID T2-MI antes do desencapsulamento (necessário para fluxosmultistreamcifrados — caso contrário o desencapsulador descarta cada pacote cifrado, ver contador<t2mi scrambledDropped>).
EPG¶
Importação EPG/XMLTV¶
Os dados de EPG são coletados na EPG Database a partir de várias fontes:
EIT dos fluxos recebidos (SPTS e MPTS). Ativado pela configuração Stream: Extract EIT to EPG Database.
Import in XMLTV format from different external sources. Set in Configuration/EPG/EPG Sources. Supported sources EPG in the form of a link to a web resource and a local file, with the full path specified.
O tempo de armazenamento dos eventos do EPG é definido pelo parâmetro EPG storage period (days).
Auto-clean database — programas sem eventos são removidos.
Na seção EPG são exibidas as fontes de EPG e dados associados. Para cada canal (EPG Channels List) pode-se definir:
Channel Name — nome usado na exportação para o servidor XMLTV.
Time Zone — é possível ajustar o fuso horário se na importação ele não foi vinculado ao UTC.
EPG Channel Sets — vincular o canal a um Channel Set (veja abaixo).
Icon — URL do ícone do canal (http://example.com/mychannel/myicon.png).
Gerador de EIT¶
Os dados EIT da EPG Database podem ser gerados num SPTS Stream. Para isso, na configuração do Stream é necessário definir EPG Source ID e selecionar EPG Channel ID. Nesse caso, a SDT será obrigatoriamente gerada, mesmo que não esteja presente na fonte. Configure corretamente SDT Data.
Se este Stream for usado em um multiplexador, o Service Name pode ser redefinido separadamente no ajuste output/muxer.
Servidor EPG (XMLTV)¶
Um servidor HTTP integrado separado do Perfect Streamer entrega o XMLTV completo para um dado conjunto de canais. O endpoint é destinado a middleware e players que mantêm o guia localmente e o atualizam com pouca frequência, como arquivo inteiro — normalmente uma ou duas vezes por dia.
O servidor e seus clientes são configurados em Configuration/EPG/EPG Server.
URL e autenticação¶
O serviço é atendido por um servidor HTTP separado epg-server (não o de /data/*). Por padrão, ele escuta nas portas 10444 (HTTP) e 10445 (HTTPS); portas e SSL são configurados em /config/epg-server.
Rotas:
URL |
Content-Type |
Comportamento |
|---|---|---|
|
|
Com |
|
|
Sempre retorna um fluxo gzip com |
São suportados três métodos de autenticação:
HTTP Digest (preferencial) — conta em
/config/epg-server/login.Parâmetros na URL —
?l=<login>&p=<password>(sinônimos:login=…,password=…).Loopback — uma solicitação de
127.0.0.1é tratada anonimamente. Útil para scripts implantados na mesma máquina.
Aviso
Um login e senha na URL acabam nos access-logs do reverse-proxy e no histórico do navegador. Para distribuição pública do XMLTV, use HTTP Digest ou aceite solicitações apenas de endereços privados.
Acesso por channel-set¶
Cada conta epg-server/login está vinculada a um único channel-set em /config/epg-channel-set. O EPG retornado contém apenas os canais desse grupo. Isso permite que uma mesma instalação do PSS forneça XMLTV distintos para diferentes operadoras/middleware.
Configuração básica na IU:
Em Configuration/EPG/EPG Channel Sets, crie um grupo de canais e atribua os canais desejados nas fontes EPG.
Em Configuration/EPG/EPG Server Clients, crie uma conta e vincule o grupo criado a ela. Sem vínculo de channel-set, o cliente recebe um XMLTV vazio.
Restrições adicionais para um login:
ip-addr— se definido e não for curinga, uma solicitação de outro IP recebe403 Forbidden.limit-day— Unix epoch em s, após o qual a conta deixa de ser atendida (403 Forbidden). Útil para um modelo de assinatura.pause— desativar temporariamente um login sem excluí-lo.
Formato da resposta¶
O corpo da resposta é um documento XMLTV com raiz <tv>. A estrutura segue o esquema XMLTV DTD habitual:
<?xml version="1.0" encoding="utf-8"?>
<tv source-info-name="..." source-info-url="...">
<channel id="channel.one">
<display-name lang="en">Channel One</display-name>
<icon src="https://.../channel-one.png"/>
</channel>
...
<programme start="20260504060000 +0300"
stop ="20260504070000 +0300"
channel="channel.one">
<title lang="en">Morning News</title>
<desc lang="en">Overview of the day's events</desc>
<rating system="MPAA"><value>PG</value></rating>
</programme>
...
</tv>
Notas sobre os campos:
Os atributos
source-info-nameesource-info-urlda raiz<tv>são preenchidos a partir dos campos EPG Source Name e EPG Source URL em Configuration/EPG/EPG Server.Os atributos
startestopseguem o formatoYYYYMMDDhhmmss ±zone(o fuso horário é obtido do campotime_zonedo canal).Um
<programme>pode conter vários<title>/<desc>para idiomas diferentes. O atributolangfica vazio quando o identificador de idioma dos dados EPG de origem não pôde ser mapeado no dicionário (a entrada ainda aparece na saída).Canais com
channel_idem conflito (quando o mesmo id chega de várias fontes) aparecem uma vez; as fontes restantes são ignoradas com um aviso no log do servidor.Somente eventos com
stop_time >= nowentram na saída.
Cabeçalhos HTTP¶
O servidor sempre envia:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Connection: close
Para /xmltv, adicionalmente — Content-Encoding: gzip quando Accept-Encoding: gzip está presente na solicitação. Para /xmltv.gz — Content-Disposition: inline; filename="xmltv.xml.gz".
A proibição do cache do lado do cliente é intencional: o XMLTV muda a cada importação EIT ou refresh de fontes XMLTV externas, e o player não deve manter dados desatualizados indefinidamente. Um cache edge (nginx), porém, é perfeitamente aceitável — veja a seção sobre desempenho abaixo.
Cache do servidor e sua limpeza¶
O XMLTV pronto é armazenado em cache na memória do processo PSS:
Uma entrada por
channel-set; ambas as variantes do corpo (raw e gzip) são guardadas — solicitações repetidas comAccept-Encoding: gzipou/xmltv.gznão recomprimem os dados.Cada entrada é marcada com um contador
update-time. Qualquer atualização de EPG (importação EIT, refresh de fonte XMLTV) incrementa o contador, e o cache é reconstruído na próxima solicitação.
Limpeza forçada do cache:
POST /xmltv/reset-cache
A rota é atendida pelo servidor admin (porta 43971/43981), não pelo epg-server. Corpo vazio; a resposta é 200 OK com um envelope JSON.
Códigos de resposta HTTP¶
Código |
Condição |
|---|---|
|
Solicitação processada. O corpo é um documento XMLTV (possivelmente um |
|
Nem Digest nem os parâmetros |
|
O login existe, mas a solicitação não vem de um IP permitido, ou |
|
Qualquer URL além de |
|
Método diferente de GET. |
O corpo do erro é um envelope JSON de formato fixo:
{"status": 401, "message": "Unauthorized"}
Desempenho e escalabilidade¶
Cache do servidor¶
O cache do servidor atende solicitações repetidas a um mesmo channel-set sem acessar o SQLite — copiando o corpo já pronto.
Construir o XMLTV «do zero» (cache miss) é mais caro: para cada canal é feito um SELECT separado em channel_name e, para cada evento, em event_text e event_rating. Tempos de construção aproximados:
Tamanho da saída |
Cache hit |
Cache miss (build) |
|---|---|---|
100 canais / dia |
dezenas de ms |
~0,5–1 s |
500 canais / dia |
~50 ms |
2–5 s |
1000+ canais / semana |
~100–300 ms |
5–15 s |
Para a maioria dos middleware é aceitável buscar o XMLTV a cada algumas horas ou uma vez por dia.
Quando é preciso um reverse-proxy externo (nginx)¶
Ao contrário de /data/epg/channel (respostas JSON curtas), o XMLTV é um único documento grande por channel-set, ideal para um cache edge:
Dezenas a centenas de clientes por channel-set — o cache interno do PSS costuma ser suficiente se eles consultam o XMLTV de hora em hora ou uma vez por dia.
Milhares de clientes simultâneos — recomenda-se um reverse-proxy com cache. Servir um arquivo XMLTV a centenas/milhares de solicitações é, antes de tudo, uma carga de rede (centenas de KB a alguns MB por resposta) que é melhor retirar do PSS.
Entrega geograficamente distribuída — um CDN/cache edge é indispensável independentemente do número de clientes.
O PSS devolve Cache-Control: no-cache, portanto é preciso dizer explicitamente ao nginx para ignorar o cabeçalho do upstream e manter o próprio TTL.
Exemplo de configuração nginx¶
# /etc/nginx/conf.d/pss-xmltv.conf
proxy_cache_path /var/cache/nginx/pss-xmltv
levels=1:2
keys_zone=pss_xmltv:8m
max_size=4g
inactive=2h
use_temp_path=off;
upstream pss_epg {
server 127.0.0.1:10444;
keepalive 16;
}
server {
listen 80;
# listen 443 ssl http2; # SSL termination makes sense here
server_name epg-files.example.com;
# Do not enable gzip on: /xmltv.gz is already compressed, and /xmltv
# arrives gzip-encoded from PSS — re-compressing is pointless.
location ~ ^/xmltv(\.gz)?$ {
proxy_pass http://pss_epg;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# PSS returns no-cache; force-cache it at the edge.
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_hide_header Cache-Control;
proxy_hide_header Pragma;
proxy_hide_header Expires;
# Cache key = full URL including query (login/password in /xmltv?l=...&p=...)
# produce distinct keys for different accounts with different channel-sets.
proxy_cache_key "$scheme$host$request_uri";
proxy_cache pss_xmltv;
proxy_cache_valid 200 30m; # XMLTV changes infrequently
proxy_cache_valid 401 403 1m;
proxy_cache_lock on; # coalesce cache misses
proxy_cache_lock_timeout 60s; # XMLTV build may take seconds
proxy_cache_use_stale error timeout updating
http_500 http_502 http_503;
# Large buffer: XMLTV for a big channel-set can reach
# several megabytes.
proxy_buffering on;
proxy_buffers 16 256k;
proxy_buffer_size 256k;
proxy_busy_buffers_size 1m;
# Let the client cache for a short period.
add_header Cache-Control "public, max-age=600";
add_header X-Cache-Status $upstream_cache_status always;
}
}
Explicações e recomendações¶
TTL ``proxy_cache_valid 200 30m`` — o XMLTV raramente muda com frequência maior que a cada meia hora. Se a sincronização com as fontes ocorre uma vez por hora ou menos, dá para elevar para 1 hora ou mais; se a frescura após
POST /xmltv/reset-cacheimporta, reduza.``proxy_cache_lock_timeout 60s`` — aumentado em relação a
/data/epg/channel(onde 5 segundos é o usual), porque construir o XMLTV de um channel-set grande leva mais tempo.Uma ``keys_zone`` dedicada — mesmo em uma instalação grande, as chaves XMLTV únicas são poucas (número de contas ×
channel-set); 8 MB são suficientes.max_sizeé dimensionado pelo volume de XMLTV, não pela quantidade de chaves.gzip do lado do nginx é desnecessário: para
/xmltv.gza resposta já vem comprimida, e para/xmltvo próprio PSS responde com gzip-encoded quandoAccept-Encoding: gzipestá presente.Terminação HTTPS no nginx oferece melhor desempenho com muitos handshakes TLS simultâneos.
EPG para middleware OTT¶
O servidor fornece os dados do guia de programação (EPG) para o dia selecionado e para um único canal no formato JSON. O endpoint é destinado aos back-ends de middleware OTT que agregam a programação do Perfect Streamer para montar o guia no cliente final.
URL e autenticação¶
O endpoint é servido pelo servidor admin integrado. Por padrão está disponível nas portas 43971 (HTTP) e 43981 (HTTPS); as portas são configuradas em Settings/Server Settings.
GET /data/epg/channel?src=<src_id>&ch=<channel_id>&lang=<lang>&t=<time>
A autenticação é HTTP Digest, como para o restante de /data/*. Para o middleware, basta uma conta com o papel viewer (somente leitura).
Nota
Solicitações do endereço loopback (127.0.0.1) são executadas sem verificação HTTP Digest — o servidor as trata como anônimas. É conveniente para scripts locais e health-checks de middleware implantado na mesma máquina que o Perfect Streamer; para acessos remotos as credenciais são obrigatórias.
Parâmetros da solicitação¶
Parâmetro |
Tipo |
Obrigatório |
Padrão |
Descrição |
|---|---|---|---|---|
|
inteiro sem sinal |
não |
|
Fonte EPG. |
|
cadeia |
sim |
— |
Identificador do canal na base EPG: valor do campo |
|
inteiro ou ISO 639 |
não |
idioma padrão do sistema |
|
|
inteiro sem sinal (Unix epoch, s) |
não |
hora atual do servidor |
Qualquer ponto dentro do dia de interesse. O servidor retorna eventos do dia UTC ao qual |
Nota
O dia é tomado em UTC, não no fuso local. Se o middleware monta a programação pelo dia calendário local, o limite do dia UTC pode não coincidir com a meia-noite local; nesse caso é preciso fazer duas solicitações (para dias UTC adjacentes) e juntar os resultados pelo campo start.
Formato da resposta¶
Content-Type:application/json.Os cabeçalhos HTTP proíbem o cache no lado do cliente e em proxies intermediários:
Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0
O corpo da resposta é um JSON com a lista de eventos do dia:
{
"event": [
{"start": 1715000000, "end": 1715003400, "title": "Morning News", "desc": "Overview of the day's events"},
{"start": 1715003400, "end": 1715007000, "title": "Weather Forecast", "desc": ""}
]
}
Campos do evento:
start,end— início e fim do programa em Unix epoch (s), UTC.title— título do programa no idioma escolhido. Se o título no idioma solicitado não existir para o evento, o servidor recorre à entrada no idioma padrão do sistema e, depois, em qualquer outro disponível.desc— descrição estendida. Pode ser uma cadeia vazia se a base não tiver descrição separada para o evento.
Particularidades da saída:
Eventos com título vazio e sem descrição, assim como aqueles com timestamps inválidos, são excluídos da saída.
Os duplicados por
startsão descartados: para o mesmo momento de início é retornada uma única entrada com a melhor prioridade de idioma (solicitado → padrão do sistema → demais).A ordem dos eventos no array não é garantida — se necessário, o middleware ordena a lista pelo campo
startpor conta própria.Se o canal não for encontrado, se a fonte não existir ou se não houver eventos para o dia escolhido, o servidor retorna
200 OKcom o array vazio{"event":[]}ou, no caso raro de fonte ausente, com corpo vazio. O middleware deve tratar corretamente as duas variantes.
Cache no servidor¶
O JSON pronto é armazenado em cache pelo servidor sob a chave (channel_id, data UTC, idioma), de modo que solicitações repetidas para o mesmo dia e canal são atendidas sem acessar o banco de dados. O middleware não precisa gerenciar o cache.
O cache é limpo automaticamente:
quando chegam novos eventos do EIT MPEG-TS dos fluxos de entrada (
src=0);ao atualizar com sucesso uma fonte XMLTV externa (
src > 0— agendada ou forçada viaPOST /data/epg/update?s=<src_id>);quando um dia sai da janela de retenção do EPG.
Um endpoint dedicado para a limpeza forçada do cache não está previsto nem é necessário.
Códigos de resposta HTTP¶
Código |
Condição |
|---|---|
|
Solicitação processada. O corpo é um JSON com a lista de eventos (possivelmente vazia). |
|
O parâmetro |
|
A autenticação HTTP Digest está ausente ou incorreta (para solicitações que não vêm de um endereço loopback). |
Outras situações (src desconhecido, canal ausente, sem eventos no dia) não geram 4xx — o middleware recebe 200 OK com o array vazio {"event":[]}.
Em caso de erro, o corpo da resposta é um envelope JSON de formato fixo:
{"status": 400, "message": "Bad Request"}
O campo status duplica o código HTTP; o campo message traz a causa refinada do erro em inglês (ou o texto padrão do status HTTP, se não houver informação adicional). O Content-Type da resposta de erro é application/json.
Exemplo¶
curl -u middleware:secret --digest \
'http://pss.example.com:43971/data/epg/channel?src=0&ch=12.0.1&lang=rus&t=1715000000'
Exemplo de resposta:
{
"event": [
{"start": 1715000000, "end": 1715003400, "title": "Morning News", "desc": "Overview of the day's events"},
{"start": 1715003400, "end": 1715007000, "title": "Weather Forecast", "desc": ""}
]
}
Desempenho e escalabilidade¶
Cache do servidor Perfect Streamer¶
Dentro do processo PSS há um cache LRU de respostas em memória com chave (channel_id, data UTC, idioma) e teto rígido de 1024 entradas por fonte EPG. Sob carga típica (dezenas a centenas de canais × 1–3 idiomas × keep-day dias) todas as entradas atuais cabem inteiras no cache; solicitações repetidas são atendidas sem acessar o SQLite.
Ordem de grandeza (build de depuração, loopback local, sem HTTPS):
Cenário |
Latência (solicitação única) |
Vazão (P=8) |
|---|---|---|
Cache hit |
~0,3 ms |
~1100 solicitações/s |
Cache miss (SQL + JSON) |
~1,0–1,5 ms |
~1000 solicitações/s |
Em um build de release e sem logging de depuração, os números ficam cerca de 2–3× melhores. Bandwidth — cerca de 14 KB por resposta para um canal-dia típico.
Quando é preciso um reverse-proxy externo (nginx)¶
O cache do servidor acelera solicitações repetidas para o mesmo (canal, dia, idioma), mas cada solicitação ainda passa pelo servidor HTTP integrado do PSS e consome um thread do seu pool. Com muitos clientes faz sentido mover o cache para o edge:
até ~1.000 clientes online — o cache interno costuma ser suficiente, reverse-proxy não é obrigatório.
dezenas de milhares ou mais — recomenda-se um reverse-proxy com cache (por exemplo, nginx). Um cache edge atende 99 % das solicitações sem o PSS, amortiza picos (start do middleware, refresh em massa do player) e permite mover a terminação SSL para um nó separado.
entrega geograficamente distribuída — um CDN/proxy externo é necessário antes mesmo de contar os clientes.
O PSS envia o próprio cabeçalho Cache-Control: no-cache, no-store, must-revalidate para que os clientes finais não armazenem o EPG por muito tempo. Já o reverse-proxy pode (e deve) cachear a resposta sozinho — abaixo mostra-se como informar explicitamente ao nginx que ignore o Cache-Control do upstream e mantenha o próprio TTL.
Exemplo de configuração nginx¶
Configuração mínima para um cache edge de EPG dimensionada para dezenas de milhares de clientes com intervalo de polling de 1–5 minutos:
# /etc/nginx/conf.d/pss-epg.conf
proxy_cache_path /var/cache/nginx/pss-epg
levels=1:2
keys_zone=pss_epg:32m
max_size=2g
inactive=30m
use_temp_path=off;
upstream pss_admin {
server 127.0.0.1:43971;
keepalive 64;
}
server {
listen 80;
# listen 443 ssl http2; # recommended: SSL termination here
server_name epg.example.com;
# gzip helps: typical EPG JSON compresses ~5–8x.
gzip on;
gzip_types application/json;
gzip_min_length 512;
gzip_proxied any;
location = /data/epg/channel {
proxy_pass http://pss_admin;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# PSS returns no-cache; force-cache it at the edge.
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_hide_header Cache-Control;
proxy_hide_header Pragma;
proxy_hide_header Expires;
# Cache key = full URL with query string. The src/ch/lang/t
# parameters already determine response uniqueness.
proxy_cache_key "$scheme$host$request_uri";
proxy_cache pss_epg;
proxy_cache_valid 200 60s; # staleness TTL
proxy_cache_valid 400 404 10s;
proxy_cache_lock on; # coalesce cache misses
proxy_cache_lock_timeout 5s;
proxy_cache_use_stale error timeout updating
http_500 http_502 http_503;
# Serve the JSON to the client with its own TTL
# (the player won't recheck EPG before that).
add_header Cache-Control "public, max-age=60";
add_header X-Cache-Status $upstream_cache_status always;
}
}
Explicações e recomendações¶
TTL ``proxy_cache_valid 200 60s`` — compromisso entre frescura do EPG e carga no upstream. A programação não muda em tempo real, então 30–300 segundos são razoáveis. Após importar novos eventos, o PSS limpa o próprio cache imediatamente, e o cache edge alcança no próximo TTL.
``proxy_cache_lock on`` é obrigatório com muitos clientes: em um cache miss, ele coalesce solicitações paralelas para a mesma chave em uma única solicitação upstream, protegendo o SQLite de picos de
BUSYsob carga.``keys_zone`` e ``max_size`` são dimensionados pelo número de
(canal × dia × idioma): 32 MB dekeys_zonecobrem centenas de milhares de chaves; 2 GB demax_sizecobrem um mês de histórico para centenas de canais com folga.gzip reduz significativamente o tráfego: as respostas comprimem bem (chaves JSON repetidas, cirílico em UTF-8).
``X-Cache-Status`` na resposta permite que o middleware veja
HIT/MISS/EXPIREDe avalie a eficácia do cache.Se nginx e PSS coabitam na mesma máquina, o servidor admin não exige HTTP Digest para loopback, portanto o bloco upstream pode ficar sem
proxy_set_header Authorization …. Para distribuir por redes diferentes, crie uma contaviewerdedicada e adicione autenticação Digest emproxy_pass.HTTPS é melhor terminado no nginx: o PSS suporta HTTPS diretamente, mas um servidor edge costuma ser mais eficiente para lidar com handshakes TLS de milhares de clientes simultâneos.
Otimização do programa¶
Se com muitos stream houver problemas de alta carga de CPU ou falta de memória, é possível otimizar as configurações.
You can disable the MPEG-TS filtering and processing features if you don’t need to.By default, the stream has the Clean All Unnecessary Data function enabled, disable it if there is no unwanted data in the stream. Disabling these features completely will remove the Original Media Information section of the Report.
Desativar completamente ou alterar as configurações de Mosaic. A desativação completa pode ser feita nas configurações do servidor. É possível desativá-lo individualmente para cada stream ou alterar o intervalo de atualização pela configuração Check Interval.
Aumento do consumo de memória com um grande número de fluxos. O PSS devolve periodicamente a memória não utilizada ao sistema operacional, e a unidade systemd fornecida limita por padrão o número de pools paralelos de alocação de memória (variável de ambiente MALLOC_ARENA_MAX). Isso contém o crescimento gradual do RSS ao operar com dezenas de fluxos e não é consequência de um vazamento. Geralmente não é necessário alterar o valor manualmente.
Erros de queue overload para as bases DBStat e DBEPG¶
Ocorrem quando o desempenho dos bancos de dados é insuficiente — disco lento ou sistema sobrecarregado.
O local dos bancos de dados é definido pelo parâmetro data-dir no arquivo de configuração pss.properties
Possíveis soluções:
Mover os arquivos de banco de dados para /tmp. Será utilizada a memória do sistema, o que requer estimativa de memória livre disponível e ajuste do tempo de armazenamento das estatísticas (ver configurações do servidor). Ao reiniciar o sistema, os dados serão perdidos.
Reduzir o detalhamento das estatísticas — ver o parâmetro dbstat-detail. Por padrão 5 s; pode ser aumentado até 20.
Colocar o banco de EPG em memória — definir dbepg-memory=true.
Transcodificadores¶
Os transcodificadores são implementados como binários executáveis separados, iniciados pelo pstreamer como processos independentes.
Suporta configurações 1toN: a partir de um decoder é possível gerar vários fluxos com configurações diferentes de encoder.
O fluxo de origem deve conter vídeo e áudio; variantes sem vídeo ou sem som não são suportadas.
Arquitetura do transcodificador: um único decoder partilhado → N ramos VPP + encoder independentes (1 para N); o áudio é multifaixa com transcodificação opcional por saída; as legendas e o teletexto são passthrough.¶
Codecs implementados:
Video SW decoder: mpeg2, h.264, hevc (h.265)
Video NW decoder: mpeg2, h.264, hevc (h.265)
Video SW encoder: mpeg2, h.264, hevc (h.265)
Video NW encoder: h.264, hevc (h.265)
Fluxos entrelaçados são suportados na entrada e na saída.
Para os decoders H.264 e HEVC, há suporte ao interlace alternate (dois campos separados no fluxo); é convertido em interlace interleaved.
O decoder HEVC suporta o perfil Main10 com bt.709 (SDR) e bt.2020 (HDR). O encoder HEVC sempre usa o perfil Main com bt.709.
Para os decoders H.264 e HEVC há suporte ao VBR (Variable Frame Rate); ele é convertido para frame rate constante.
Audio decoder — mpeg (layer 1,2,3), aac, ac3
Audio encoder — mpeg (layer 2), aac
Existe o modo de transcodificação Video Passthrough — o vídeo não é transcodificado, apenas o áudio; é usado o transcodificador SW.
Nota
Para a transcodificação configure dois ou mais streams, com output (decoder) e input (encoder).
Para configurar uma instância do transcodificador é necessário:
Fonte — adicionar no stream output transcoder (decoder). Nas configurações escolha o tipo: SW, NV ou Video Passthrough.
Fluxo de saída — adicionar no stream input transcoder (encoder); nas configurações selecionar a fonte-decoder.
Repita se forem necessários vários fluxos de saída para um mesmo decoder.
Configurações do transcodificador de saída (decoder)¶
Convert colors to BT.709 — conversão dos formatos SD BT.470-2 (PAL) e SMPTE 170M (NTSC) para BT.709
Trace — ativar para diagnóstico o log detalhado do transcodificador.
Para o funcionamento correto do transcodificador, o fluxo de origem deve atender a determinados requisitos; em alguns casos isso pode ser corrigido. Estas configurações não convertem o fluxo — atuam como dicas para o funcionamento correto do transcodificador.
Para corrigir os dados do fluxo de entrada existem as configurações:
Fix PAR — corrigir o Pixel Aspect Ratio. É indicado como fração N/D; por exemplo, 16/9 para Wide SD.
Fix Framerate — especificar explicitamente o framerate. Em alguns fluxos o framerate pode estar ausente no SPS e o log do transcodificador apresentará o erro correspondente. Nesses casos é necessário indicar o framerate manualmente. É indicado como fração N/D.
Exemplos de valores de framerate:
PAL — 25/1
NTSC — 30/1 ou 30000/1001
Cinema — 24/1 ou 24000/1001
Configurações do transcodificador de entrada (encoder)¶
Encoder Type — codec de vídeo.
Align Total Bitrate — taxa de bits do stuffing do fluxo (preenchimento com pacotes null). É importante defini-la se o fluxo for usado para transmissão DVB. A taxa de bits deve ser garantidamente maior que a do vídeo e a de todas as trilhas de áudio.
Video Profile — para H.264 é possível escolher o perfil de codificação.
Video Bitrate — taxa de bits do fluxo de vídeo em kbps. A codificação é sempre CBR; a taxa total será maior por causa das trilhas de áudio.
Speed Preset — predefinições de codificação, valores de 1 a 7. Menor valor = maior qualidade e mais recursos. Padrão 4.
GOP Interval — intervalo em frames para o GOP (equivale ao Key Frame Interval). Padrão 25 (1 segundo a 25p); recomendado quando os players iniciam aleatoriamente.
BFrame — ativar para melhorar a qualidade. Valor recomendado: 3.
Lookahead — ativar para melhorar a qualidade. Valor recomendado: 20–50 frames.
Resize — redimensionamento da imagem.
Deinterlace — converte interlace em progressivo.
A inserção de crop (bordas vazias na imagem) não é suportada. Tamanhos de imagem arbitrários não são permitidos para não distorcer proporções.
Para resize estão disponíveis as opções:
Reduzir proporcionalmente o tamanho em 2 e 4.
Definir o formato Wide SD 16:9, será aplicada a Aspect Ratio adequada.
Upscale SD→HD. Aplica-se a fontes SD PAL/NTSC. O interlace não é suportado; aplique deinterlace antes se necessário.
Definir a largura. A altura será recalculada proporcionalmente.
Definir a altura. A largura será recalculada proporcionalmente.
Alguns parâmetros podem ser incompatíveis com o transcodificador escolhido; os erros aparecem nos logs dele.
Processamento de áudio¶
Por padrão todas as trilhas de áudio passam do input para o output sem processamento. Trilhas desnecessárias podem ser removidas com os filtros de PID do stream.
Para transcodificar áudio, configure regras separadas por codec. A opção skip — remover a trilha de áudio com esse codec.
Se no fluxo de saída não houver trilhas de áudio, ocorrerá um erro — consulte os logs do transcodificador.
Geração de PCR e TR 101 290.¶
O multiplexador MPEG-TS gera um novo PCR. Com Align Total Bitrate correto (maior que a soma dos bitrates de vídeo e áudio), o PCR deve passar na conformidade TR 101 290.
Status dos transcodificadores¶
Em caso de problemas no funcionamento do transcodificador (não há fluxo do encoder), consulte os logs na seção Transcoders — é exibida a lista de instâncias (cada linha é uma instância separada, decoder + N encoders); ao clicar na instância desejada, abre-se a janela de status dos logs. São exibidos o log atual e o log da execução anterior. Para log detalhado, ative trace nas configurações do output (decoder).
