Histórico de versões

versão 2.0.2.423

26.10.2026

• Versão de demonstração — edição gratuita para avaliação técnica, pacote pstreamer-demo: sem chave de proteção nem ativação, sem prazo de validade, apenas para conhecer o produto (uso comercial proibido). Recursos e restrições — Versão de demonstração.

• Versão de demonstração: o campo DVR sem erro — na aba «OTT» do editor do fluxo, depois de escolher o modo «OTT / HLS», o erro «Não foi possível carregar os armazenamentos DVR» não aparece mais sob o campo «Armazenamento DVR»: o campo mostra apenas «Não disponível na demo» (Comparação das edições).

• Atualize os transcodificadores junto com o streamer — são necessários pstreamer-tcnv 1.2.0.128, pstreamer-tcsw 1.2.0.127 e pstreamer-tcivpl 1.1.0.56 ou mais recentes: um transcodificador de versão anterior pode falhar abruptamente ao parar o serviço, e o logotipo no transcodificador de software exige a nova versão do tcsw. Após atualizar os transcodificadores, reinicie o serviço (Arquivos e verificação da instalação).

• Inicialização automática do serviço ao atualizar o pacote — atualizar o pacote rpm não desativa mais a inicialização automática do serviço pss nem o interrompe: antes, depois de uma atualização assim e de uma reinicialização do servidor, o streamer não iniciava sozinho. Agora, inclusive ao atualizar a partir da 2.0.2.408, a inicialização automática continua ativada e um serviço em execução é reiniciado na nova versão; um serviço que o administrador parou ou desativou continua assim. Atualizar o pacote deb não ativa mais uma inicialização automática que o administrador desativou. O usuário de sistema pss não é mais removido e recriado na atualização. Se uma instalação rpm foi atualizada antes, verifique a inicialização automática com systemctl is-enabled pss e, se a resposta for disabled, ative-a: sudo systemctl enable pss (Instalação em sistemas da família RHEL).

• Configurações de OTT, DVR e DRM sem interromper a transmissão — salvar as configurações de OTT, DVR e DRM de um fluxo em execução reinicia apenas a distribuição OTT e a gravação do arquivo: as entradas e as saídas (UDP, SRT e outras) continuam funcionando sem interrupção, e o uptime do fluxo não é zerado. Antes, qualquer alteração desse tipo reiniciava todas as entradas e saídas do fluxo, e as saídas tinham uma breve interrupção. A profundidade do arquivo e a duração-alvo da parte LL são aplicadas na hora, sem reinício. As configurações que alteram o próprio fluxo de transporte (nome do serviço, programa, filtros de PID, correções de PAT/PMT/PCR, fonte de EPG) reiniciam as entradas e saídas, como antes (OTT e DVR).

• Clonagem de fluxos — na interface web, um fluxo ou vários fluxos selecionados são copiados junto com as entradas e saídas: a cópia é criada em pausa, com o sufixo -copy no nome, e o resultado lista as portas e os endereços que coincidem com o fluxo original (Clonagem de fluxos).

• Entrada na interface web sem a janela do navegador — ao abrir a interface web a partir de outro computador, o navegador não mostra mais sua própria janela de entrada antes do formulário da interface web. Uma solicitação da API a um caminho /data/… com o cabeçalho X-Requested-With: XMLHttpRequest recebe, ao ser recusada, 401 sem desafio Digest; scripts que entram por Digest não devem enviar esse cabeçalho (Entrada, Acesso).

• Assistente de reclamações na interface web — enquanto um fluxo SPTS tiver uma violação ativa da TR 101 290 ou deriva de PCR, o ícone «Carta IA» é exibido na linha do fluxo e na janela de estatísticas: ele abre uma solicitação pronta para um chat de IA, que redigirá uma carta de reclamação ao fornecedor. A solicitação está disponível apenas para a função Admin, a carta é sempre em inglês (a escolha de idioma foi removida) e, da fonte, entra na solicitação apenas o endereço da entrada, sem logins, senhas e chaves. Sem violação ativa, o nó não gera a solicitação (Assistente de reclamações).

• Deslocamento do quadro ampliado do mosaico — na janela do quadro original, a imagem ampliada pode ser deslocada com o mouse mantendo pressionado o botão direito e, no celular e no tablet, ampliada com o movimento de pinça e deslocada com o dedo (Quadro original).

• Nome OTT do pacote adaptativo sem espaços — o campo «Nome OTT» de um pacote adaptativo não aceita mais espaços: eles quebravam a reprodução e a exportação da playlist. O streamer também os remove — ao adicionar e alterar um pacote pela API e ao carregar as configurações (com uma entrada no registro); o nome limpo é gravado no próximo salvamento. Se, após a remoção dos espaços, os nomes de dois pacotes coincidirem, as configurações ainda assim são carregadas: o segundo nome não é distribuído e um aviso é gravado no registro (antes, essas configurações não eram carregadas) (Pacote adaptativo).

• Exportação para M3U: pacotes adaptativos e DASH — a playlist agora também recebe os pacotes adaptativos: a playlist mestre HLS e o manifesto DASH do pacote, cada um enquanto pelo menos um fluxo do pacote o servir. A opção «Todos os ativos» adiciona após os fluxos todos os pacotes em funcionamento, e o novo protocolo DASH inclui os manifestos dos pacotes e os fluxos no modo DASH. Antes, não era possível exportar os pacotes selecionados (Exportação e importação M3U).

• Logotipo no quadro do transcodificador — nas saídas do transcodificador NVIDIA e do transcodificador de software (CPU) é possível sobrepor um logotipo de um arquivo PNG: cada saída tem seu próprio arquivo, posição, opacidade e desfoque do fundo sob o logotipo. O logotipo não é redimensionado; a interface web verifica na hora se ele cabe no quadro da saída e mostra uma pré-visualização em escala. Os arquivos de logotipo são carregados na interface web e ficam armazenados no nó. O backend de um decodificador com logotipo pode ser alternado entre NVIDIA e software; com as mesmas configurações de tamanho, o quadro deles pode diferir em alguns pixels, e o logotipo deve caber no quadro do backend selecionado. A Intel não tem logotipo (Logotipo no quadro).

• Parada e reinício rápidos — os transcodificadores, os comandos externos das entradas e saídas std e o comando de alertas terminam junto com o serviço, e durante a parada o nó não reinicia mais os transcodificadores. Antes eles não reagiam ao sinal de parada, e a parada ou o reinício do serviço esperava até que o sistema os encerrasse à força — normalmente cerca de 15 segundos.

• Estatísticas do transcodificador — a fila do decodificador e a latência não congelam mais depois que o nó reinicia o transcodificador.

• Alertas por grupos — a tela «Alertas» agrupa por padrão os alertas em vigor por nó e por código, com o número de linhas e a maior gravidade no título do grupo; os grupos grandes abrem recolhidos. As etiquetas «resync persistente» e «entrada de reserva» distinguem as recomendações de ressincronização e os erros das entradas de reserva das panes atuais. A lista anterior continua disponível pelo seletor «Lista» (Alertas).

• Alertas sem oscilação — um alerta sobre os recursos do nó (CPU, memória, rede, GPU, memória de vídeo da GPU, armazenamento DVR, threads de trabalho dos adaptadores DVB) é gerado somente quando o valor permanece além do limiar por 30 segundos, e é removido após 60 segundos abaixo do limiar. O alerta de erros do contador de continuidade de um fluxo (código 15) é gerado somente quando as perdas continuam por 30 segundos e é removido após 60 segundos sem perdas; o nível de erro se mantém até que o número de erros caia abaixo da metade do limiar. Antes, uma carga que oscilava em torno do limiar e pacotes perdidos isolados produziam alertas que apareciam e desapareciam em segundos. Os tempos são definidos na tela «Alertador» (parâmetros system-alert-raise-sec, system-alert-clear-sec, stream-cc-raise-sec e stream-cc-clear-sec da seção alerter); 0 restaura o comportamento anterior (Configurações do alerter).

• Alerta de preenchimento da memória de vídeo da GPU — um novo alerta de código 64 para cada placa NVIDIA: aviso quando a memória de vídeo está 85% cheia, erro a 95% (linha «Memória de vídeo da GPU» da tela «Alertador», parâmetros gpu-mem-warning-pct e gpu-mem-error-pct; 0 desativa o nível). Uma placa com a memória de vídeo cheia não inicia um novo canal de transcodificador, embora sua carga possa parecer normal. Para GPUs Intel não existe esse alerta. Os dados do monitor do sistema (/data/sysmon) mostram para cada placa NVIDIA a memória de vídeo ocupada e total e a porcentagem de preenchimento, e o monitor do sistema da interface web mostra uma barra «Memória de vídeo»; a antiga barra «Memória» de uma placa NVIDIA agora se chama «Largura de banda da memória». Com a replicação de alertas do sistema ativada, os nós de versões anteriores no mesmo domínio mostram esse alerta sem nome até serem atualizados (Catálogo de códigos de alerta).

• Reserva com defeito em um único alerta — o novo alerta de código 65 (nível «aviso», um por fluxo) lista as entradas que estão em erro enquanto o fluxo passa por outra entrada. Essas entradas não mantêm mais as suas próprias linhas de código 1, e o código 1 agora é sempre crítico: o fluxo perdeu a fonte. Um destino externo recebe a retirada das linhas de código 1 e a abertura do código 65 em vez da antiga atualização «crítico» → «erro». É configurado no bloco «Entradas de reserva (código 65)» da tela «Alertador» (Catálogo de códigos de alerta).

• Alertas de ressincronização mais discretos — o alerta de código 61 (ruptura de PCR sem perdas) agora é informativo e fica desativado por padrão; o seu limiar é uma chave própria stream-sync-absorbed-count. Os códigos 58, 59 e 61 são retirados após duas horas abaixo do limiar em vez de seis horas sem um único evento, e a linha da entrada da qual o fluxo comutou é retirada imediatamente. Os limiares e o número de horas tranquilas são definidos no novo bloco «Ressincronização de entrada (códigos 58, 59, 61)» da tela «Alertador» (Catálogo de códigos de alerta).

• Alerta ACME resolvido sozinho — o alerta de erro de emissão do certificado causado por um problema no nó (não há servidor HTTPS com o nome do host, a porta da validação HTTP-01 está ocupada, a chave da conta) é resolvido após a primeira tentativa que passa dessa etapa; antes, ele se mantinha até a desativação da emissão automática (Catálogo de códigos de alerta).

• Alertas externos: geração e resolução em par — o limiar de severidade mínima dos canais «Processo», Telegram e e-mail se aplica ao incidente, e não a cada mensagem. Um incidente cuja severidade subiu até o limiar é informado no momento do aumento, e a resolução chega sempre que a geração foi informada. Antes, quando a severidade mudava em relação ao limiar, chegava uma resolução sem geração ou uma geração sem resolução (Quando o script é executado).

• Scripts de alerta e stderr — a saída de erro do script é lida enquanto o script é executado: uma saída abundante no stderr não leva mais ao tempo limite, e um processo deixado em segundo plano não atrasa os próximos alertas. Só um código de saída diferente de zero é considerado falha na entrega; os últimos 4 KB do stderr vão para o registro (Resultado, tempo limite e registro).

• Meshwork: proteção da troca entre nós — o nó verifica se a resposta de um vizinho está assinada com o mesmo segredo ou com a chave do domínio, ou seja, se veio de um participante legítimo da rede, e recusa uma mensagem de um vizinho gravada antes e enviada de novo, assim como uma mensagem endereçada a outro nó. A chave do domínio é transmitida criptografada: uma troca gravada e repetida mais tarde não a obtém. Antes, quem respondesse à conexão (uma conexão interceptada por HTTP ou TLS sem verificação do certificado) podia substituir os dados dos nós, as sessões de entrada e a chave do domínio. Não é preciso configurar nada (Vizinhos e segredos).

• Meshwork: os relógios dos nós devem estar sincronizados — um nó cujo relógio difere do de um vizinho em mais de 5 minutos é recusado por esse vizinho, e a conexão é mostrada como indisponível. Os dois nós registram no log um aviso com o nome do vizinho e o tamanho da diferença; o primeiro aviso aparece já na metade da tolerância. A tolerância é definida por um novo parâmetro opcional, cluster-hello-window-sec (300 segundos por padrão, 0–86400); 0 desativa a verificação dos relógios para nós cujos relógios não podem ser sincronizados, e as mensagens repetidas são recusadas mesmo assim. Antes da atualização, verifique se o NTP está funcionando em todos os nós (Requisitos e acessibilidade).

• Atualização e reversão da Meshwork — se possível, atualize todos os nós do domínio de uma vez. Se não for possível, atualize primeiro os nós aos quais os demais se conectam (nós centrais e nós com endereços públicos) e depois os nós atrás de NAT. Enquanto nós de versões diferentes funcionam no domínio, a troca de dados tem limitações, e as mensagens dos nós de versões anteriores ainda podem ser repetidas. Um nó revertido para uma versão anterior é recusado pelos vizinhos na nova versão até que eles reiniciem: reverta o domínio inteiro ou reinicie os nós da nova versão após a reversão (Atualização dos nós do domínio).

• Mais silêncio nas reinicializações planejadas de nós Meshwork — o alerta de nó indisponível (código 26) é gerado após um minuto de silêncio, e não após 15 segundos, de modo que uma reinicialização rápida de um vizinho não acorda o domínio inteiro. Um nó que é parado ou reinicializado intencionalmente avisa primeiro os vizinhos (os nós de versões anteriores não recebem o aviso), e eles não geram o alerta para ele durante 5 minutos, enquanto na tabela de nós ele consta como «Reiniciando (N s)». Os tempos são definidos pelos campos do bloco «Contato da Meshwork (avançado)» das configurações do servidor (parâmetros cluster-node-down-sec e cluster-leave-grace-sec da seção cluster, Catálogo de códigos de alerta). Corrigido: um nó podia aparecer duas vezes na rede e repetir os próprios alertas como se viessem de um vizinho.

• Alteração das configurações do Meshwork — salvar as configurações não remove mais os nós descobertos automaticamente do mapa da rede nem encerra por engano os seus alertas «um nó da rede ficou em silêncio» (Catálogo de códigos de alerta).

• Entrada automática a partir de outro nó do domínio — uma sessão de entrada automática vinda de outro nó do domínio recebe a função Viewer em um nó onde essa conta não existe. Se a conta existir no nó, vale a função dela, como antes (Servidor web e contas).

• Faturamento externo e nós vizinhos — os servidores de faturamento não recebem mais a solicitação de entrada de um nó Meshwork vizinho que o próprio nó já recusou.

• Segredos nas respostas da API e sua regravação — a resposta à adição ou alteração de um registro pela API (POST em /config/…) não repete mais senhas e outros segredos, inclusive para a função Admin: eles chegam como ********; a leitura das configurações (GET) não mudou. Um segredo ou uma linha de comando enviados numa gravação como ******** mantêm o valor armazenado, assim como um endereço oculto com o rastro <hidden>: a resposta recebida pode ser enviada de volta sem perder senhas. O próprio ******** não pode mais ser definido como senha (Gerenciamento pela API HTTP).

• Endereços nas respostas para as funções Viewer e Restricted admin — no fluxo de eventos /data/events (o endereço da entrada ativa do fluxo e os textos de erro), nos textos de eventos de /data/dbstat e no motivo reason de /data/cert/acme/status, logins, senhas e parâmetros secretos dos endereços ficam ocultos, como no XML de /data. Para a função Admin nada muda.

• Uma alteração de configurações recusada não altera nada — se o nó rejeitar a alteração de um fluxo, de uma entrada, de uma saída ou das configurações do servidor (por exemplo, um nome de nó inválido), o objeto permanece como estava. Antes, as chaves aplicadas antes da recusa continuavam valendo até a reinicialização (Como chegam os erros).

• Estatísticas do banco sem as tabelas ausentes — a requisição /data/dbstat com o parâmetro missing=skip ignora as tabelas que não existem, em vez de rejeitar a requisição inteira.

• Arquivos de configuração fechados para leitura — o pss.json e suas cópias de segurança só podem ser lidos pelo usuário do serviço. O exportador de métricas pss-metrics, executado com outro usuário, se conecta à porta 43971; se o servidor web usar outra porta, defina PSS_URL, inclusive no arquivo /etc/pss-metrics.conf. Corrigido: o exportador se conectava à porta 8808 se em pss.json não houvesse porta do servidor web definida, e não considerava PSS_URL desse arquivo (Arquivos e serviços, Configuração).

• Contas por endereço IP e clientes IPv6 — a conexão de um cliente por IPv6 não causa mais erro na verificação das contas por endereço IP: esse cliente simplesmente não corresponde aos endereços IPv4 (Usuários / Logins).

• Fluxos permitidos de um login local — um login para o qual, na inicialização do nó, não resta nenhum dos fluxos da lista «Fluxos permitidos» não recebe nenhum fluxo. Antes, esse login podia assistir a todos os fluxos (Usuários / Logins).

• Ativação e desativação do servidor EPG — «Ativar servidor EPG» agora controla as duas portas, HTTP e HTTPS, e tem efeito imediato, sem reinicialização: um servidor desativado não abre nenhuma porta. Antes, um servidor desativado ocupava as portas mesmo assim ao iniciar o serviço (as conexões travavam), desativá-lo em funcionamento reiniciava a porta HTTP, e a porta HTTPS ignorava o indicador (Fornecimento de XMLTV).

• Exportação EPG completa com dados de vinculação — o novo caminho /xmltv-src do servidor EPG (e /xmltv-src.gz) fornece os canais de todas as fontes ou das selecionadas com os dados para vincular os canais transmitidos: o número e o nome da fonte e o identificador do canal no arquivo XMLTV; é possível exportar apenas o catálogo de canais ou acrescentar dias passados. Acesso — para uma conta do servidor EPG com o indicador «Todos os canais em /xmltv-src» (all-channels) ou a partir do próprio nó (Exportação completa com dados de vinculação, Configurações EPG).

• Classificação etária no guia de programação — a programação diária do canal em JSON para OTT middleware fornece a classificação etária do programa (a idade e o sistema de classificação, por exemplo 16+), obtida do arquivo XMLTV ou da classificação parental do DVB EIT; na programação do canal na interface web, ela é exibida como um selo (Programação diária em JSON, Base de dados EPG).

• Subtítulo do programa em campo separado — o subtítulo do arquivo XMLTV (<sub-title>, por exemplo o título do episódio) no idioma do título ou sem idioma indicado é fornecido na programação diária do canal em JSON como campo sub separado e, na exportação completa /xmltv-src, como elemento <sub-title>; ali o título do programa vem sem subtítulo. O fornecimento normal /xmltv não mudou. Os subtítulos aparecem após a próxima atualização de cada fonte (Programação diária em JSON).

• Download de EPG em sequência — os arquivos XMLTV grandes são baixados e processados um de cada vez, enquanto os demais aguardam na fila, e no início do serviço os downloads são espaçados no tempo: o pico de memória ao reiniciar com vários arquivos grandes é o de um único arquivo. Um download malsucedido é repetido após 2, 5 e 15 minutos e, depois, a cada 30 minutos, em vez de após o intervalo de atualização completo. Na interface web, uma fonte na fila é marcada, e a aba «Estado das fontes» mostra os campos «Próxima tentativa» e «Downloads com falha seguidos» (Fila de downloads e novas tentativas, Base de dados EPG).

• Tempo limite de download de uma fonte EPG — o novo parâmetro da fonte «Tempo limite de download, s» (fetch-timeout) para fontes lentas que montam o arquivo sob demanda; por padrão, como antes, 30 segundos (Configuração das fontes).

• Fontes EPG — ao alterá-la, «URL / caminho da fonte» deve ser um endereço http ou https ou um caminho absoluto para um arquivo; caso contrário, a alteração é rejeitada. Os Cookies da fonte agora são de fato enviados — no cabeçalho padrão Cookie e somente ao host configurado; antes, o cabeçalho se chamava Cookies, e os servidores o ignoravam. Após a alteração de uma fonte ativada (por exemplo, do seu endereço), os dados são carregados imediatamente, e não ao fim do intervalo de atualização (Configuração das fontes).

• Exclusão de um conjunto de canais EPG — o conteúdo de um conjunto é excluído junto com o conjunto, e somente se a exclusão for concluída. Antes, o conteúdo de um conjunto sem contas permanecia no banco de dados, e uma exclusão recusada de um conjunto atribuído a uma conta podia apagar o seu conteúdo.

• EPG: programas que atravessam a meia-noite — um programa que passa pela meia-noite (UTC) é exibido nos dois dias da programação, e a sua marca na playlist OTT é encontrada também depois da meia-noite. Antes, esse programa sumia dos dois dias.

• Corrigido: na exportação /xmltv, um programa podia se repetir se duas fontes fornecessem um canal com o mesmo identificador; o guia de programação vindo da EIT dos fluxos mostra imediatamente um programa alterado, e não o texto ou a classificação antigos.

• Corrigido: a «Limpeza automática de canais órfãos» podia remover os canais de uma fonte EPG cujo arquivo XMLTV não tinha mudado; as alterações da programação nas fontes externas agora são reconhecidas de forma mais confiável, e as edições de nomes de canais feitas na interface web são preservadas (Base de dados EPG).

• EIT — o serviço não é mais encerrado de forma anormal ao gerar o EIT a partir de XMLTV quando um evento tem duas ou mais classificações etárias ou uma descrição longa em polonês, tcheco, húngaro, croata ou bósnio: um texto longo demais é dividido em vários descritores. Uma descrição longa em cirílico e em outros alfabetos não latinos não é mais dividida em fragmentos de um byte, a numeração dos descritores está correta, e um evento com descrição longa mantém a sua classificação indicativa (Gerador EIT).

• NIT — o nó acompanha a versão da NIT também após uma redefinição (antes, a lista de números lógicos de canal podia ficar vazia) e aplica apenas a NIT da sua própria rede (actual).

• Tipo de serviço automático — com Service type 0, um programa H.264 é considerado HD (tipo 0x19) a partir do nível 3.1. Antes, o limite era o nível 3.0, e o SD 576i/480i desse nível era marcado como HD; agora, como SD (0x16) (Parâmetros dos programas).

• Recepção multicast na interface de loopback — uma entrada UDP ou RTP com a interface lo ou 127.0.0.1 ingressa no grupo multicast apenas na interface de loopback e recebe o grupo enviado neste mesmo nó. Antes, a entrada ingressava no grupo na interface externa e não recebia nada. Para receber o grupo da rede, indique uma interface de rede ou deixe o campo vazio (Entrada).

• Reingresso no grupo multicast — nas entradas UDP, RTP e Pro-MPEG o período de repetição é limitado a 3600 segundos: o nó não aceita um valor maior e, na inicialização, o reduz para 3600. Antes, um valor acima de 4294 segundos fazia a entrada repetir o ingresso continuamente. Agora uma tentativa malsucedida é repetida após o período, em vez de interromper as repetições até a entrada se reconectar; uma entrada Pro-MPEG também se reinscreve nos fluxos FEC (Entrada).

• Verificação do endereço das entradas UDP e RTP — ao alterá-lo, um endereço que não é um endereço IPv4 (por exemplo, 999.999.1.1) é rejeitado com a mensagem Incorrect IPv4 address. As configurações salvas anteriormente não são verificadas novamente na inicialização (Entrada).

• Entrada RIST multicast — ingressa no grupo na interface da coluna Interface; antes, sempre era usada a rota padrão. Na saída RIST multicast, a interface continua sem efeito: o tráfego sai pela rota do sistema até o grupo (A lista de peers).

• RIST sem encerramentos abruptos — um emissor RIST cujo tamanho de bloco de dados não é múltiplo de 188 bytes não interrompe mais o serviço: esses blocos são descartados, e a mensagem no registro aparece no máximo uma vez por minuto. Substituir todas as entradas ou saídas de um fluxo em uma única alteração com uma entrada ou saída RIST em funcionamento também não provoca mais o encerramento abrupto do serviço.

• Entrada RTSP — ao trocar o endereço, pausar, passar para uma entrada de reserva ou reconectar, a entrada realmente fecha a sessão anterior. Antes, ela podia continuar recebendo o fluxo da fonte antiga.

• DVB: sem interrupções periódicas do fluxo — uma leitura incompleta de dados do dispositivo DVB não provoca mais o reinício da entrada e a nova sintonia do sintonizador, que faziam o fluxo DVB-T/S se interromper periodicamente (Receptor DVB).

• Receptor lento das saídas file, pipe e std — se o receptor ficar atrasado em relação ao fluxo por muito tempo, a saída entra no erro Output queue full e é reiniciada, como as saídas de outros tipos; os dados transmitidos chegam em ordem. Antes, nessa situação, os pacotes TS eram perdidos e reordenados silenciosamente (Aplicativos externos (std)).

• Saída std com stderr abundante — um aplicativo que escreve muito no stderr não para mais após 64 KB de saída e não é mais reiniciado em ciclo. Em caso de falha, o final do seu stderr é exibido no texto do erro (Aplicativos externos (std)).

• Tabelas corrompidas no fluxo de entrada — o nó descarta as seções PAT, PMT, CAT, NIT, EIT e TOT corrompidas e os descritores nelas; elas não conseguem mais encerrar o serviço de forma anormal.

• Marca ESCR no PES — os fluxos com a marca ESCR nos cabeçalhos PES são analisados corretamente; antes, a análise deles era interrompida por um erro.

• Adição de um fluxo com transcodificador — adicionar um fluxo cuja entrada transcoder está conectada a um decodificador já em funcionamento não provoca mais o encerramento anormal do serviço (Conexão).

• HTTP/3: respostas em streaming chegam íntegras — por HTTP/3, MPEG-TS over HTTP (/http/) e as partes de LL-DASH ao vivo são transmitidos inteiros, assim como por HTTP/1.1. Antes, o corpo dessa resposta chegava corrompido: não começava em um limite de pacote TS, fragmentos sumiam ou se repetiam, e os players perdiam a sincronização. Os segmentos HLS e DASH e outros arquivos não eram afetados pelo erro (HTTP/3 (QUIC)).

• OTT — o fornecimento de DASH e LL-HLS é retomado após a troca do PID de vídeo no fluxo (antes, só após reiniciar o OTT); a distribuição de MPEG-TS over HTTP não reinicia mais a entrada quando o disco DVR fica lento por pouco tempo.

• A exclusão de uma entrada ou saída não interrompe a gravação do DVR — após a exclusão de uma entrada ou saída do fluxo, o arquivo DVR continua sendo gravado. Antes, a gravação parava até a próxima alteração das configurações OTT do fluxo.

• DVR: registro de índice danificado — se um único registro do índice do arquivo estiver danificado (por exemplo, após uma queda de energia), o nó o ignora e carrega o restante do arquivo; perde-se apenas esse fragmento. Antes, tudo o que foi gravado depois dele sumia do arquivo a cada reinicialização, e os arquivos eram depois excluídos (Armazenamentos DVR).

• DVR: limpeza dos arquivos MP4 — quando o limite de utilização do disco é excedido, também são removidos os segmentos mais antigos dos arquivos MP4 (DASH e LL-HLS). Antes, só o arquivo TS era limpo, e um disco com apenas arquivos MP4 continuava saturado.

• DVR: legendas — o arquivo de legendas WebVTT é preservado na reinicialização; antes, ele se perdia (Legendas WebVTT).

• DVR: espaço livre de emergência — o campo «Espaço livre de emergência, GiB» dos armazenamentos DVR nunca afetou nem afeta o funcionamento: o valor é salvo, mas não há parada da gravação por espaço livre. Agora o campo é descrito como reservado; o disco é mantido dentro do limite pela limpeza por espaço, que não toca o arquivo mais recente que o mínimo protegido (Armazenamentos DVR).

• Outras melhorias e correções de erros.

versão 2.0.2.408

19.10.2026

• Um disco DVR com defeito não interrompe a distribuição ao vivo — um disco DVR cheio, somente leitura ou com falhas não interrompe mais a distribuição ao vivo de um fluxo por HLS e DASH. Antes, um erro de gravação do arquivo, sem entrada no registro, interrompia tanto a distribuição ao vivo quanto o arquivo até a reinicialização, e apagar o arquivo não adiantava. Agora o registro marca o início e o fim de uma falha de gravação, e, depois que o defeito é corrigido, o arquivo volta a ser gravado, inclusive após apagar o arquivo do fluxo (Estatísticas do fluxo). O mesmo vale para o arquivo de legendas.

• Alterar as configurações não bloqueia a API — a edição de um fluxo (um parâmetro, uma saída, a exclusão do fluxo) não pode mais travar com uma entrada com falha ou ociosa, nem sob carga. Antes, junto com ela paravam de responder todas as requisições de configuração e a lista de fluxos na interface web.

• Gravação das configurações sem perdas — uma alteração feita imediatamente antes de uma parada normal ou de uma reinicialização do serviço não se perde mais; uma gravação malsucedida do arquivo de configuração é repetida a cada 10 segundos, e o registro informa a causa; uma alteração feita antes da reinicialização automática após uma restauração a partir de um backup não sobrescreve mais a configuração restaurada.

• Reconexão de entradas e saídas — após uma nova tentativa de conexão, uma entrada ou saída não pode mais travar em uma tentativa de inicialização sem ter aberto nada, até a reinicialização do serviço ou uma alteração das configurações. Isso acontecia com mais frequência com uma entrada SRT no modo listener; PS1, RTMP/RTMPS, RTSP, a entrada HLS, TCP e o transcodificador também eram afetados.

• SRT: uma frase-senha incorreta não bloqueia a entrada — os chamadores que se conectam repetidas vezes a uma porta SRT no modo listener com uma frase-senha incorreta, ou sem ela, não ocupam mais todas as vagas de conexão: um remetente com a frase-senha correta se conecta imediatamente.

• Repositório de pacotes por HTTPS e assinado — o repositório funciona por HTTPS, e os pacotes e metadados são assinados com a chave do repositório. Os novos comandos para adicioná-lo estão em Instalação em sistemas da família RHEL e Instalação em sistemas da família Debian; um repositório adicionado antes continua funcionando.

• Criação de um fluxo com um valor inválido — uma requisição para criar um fluxo pela API HTTP com um valor de parâmetro inválido é rejeitada por inteiro, e o fluxo não é criado. Antes, o valor era descartado e o fluxo era criado (Como chegam os erros).

• A ordem da chave ``mpts`` não importa — mpts é aplicada antes das demais chaves de uma entrada de fluxo, onde quer que esteja. Os parâmetros OTT e outras configurações de um fluxo de um único programa passados ao criar um fluxo pela API HTTP sem mpts, ou gravados no arquivo de configuração acima dela, não se perdem mais (A ordem das chaves dentro de um objeto importa).

• SIGHUP é uma parada normal — o sinal SIGHUP para o serviço da mesma forma que SIGTERM: os fluxos são parados e a última alteração das configurações é salva. Antes, o processo terminava imediatamente.

• Entrada Pro-MPEG no catálogo da Meshwork — uma entrada Pro-MPEG que recebe um grupo multicast é anunciada no catálogo de recursos compartilhado do domínio da mesma forma que as entradas UDP e RTP (Catálogo comum de recursos).

• Outras melhorias e correções de erros.

versão 2.0.2.399

01.10.2026

• Buffer T-STD apenas como métrica — o modelo do buffer de vídeo gerava falsos alarmes em fluxos saudáveis; por isso o indicador dele continua nas estatísticas para diagnóstico, mas não dispara alarme (código 11) nem entra no veredito consolidado do TR 101 290 (código 49) (Catálogo de códigos de alerta).

• OTT sem preenchimento CBR — os pacotes NULL que completam a taxa de bits constante não são entregues a nenhum cliente OTT, inclusive na distribuição por HTTP sem segmentador. A taxa de bits constante é mantida apenas nas saídas de transporte — UDP, SRT, PS1, RIST.

• Partes LL-HLS por quadros-chave — cada IDR abre uma nova parte com o indicador INDEPENDENT; assim, um player que se conecta na borda ao vivo encontra um ponto de entrada dentro de um único GOP.

• Muitas entradas HLS em um nó — as entradas HLS baixam os segmentos por meio de um pool comum: uma entrada aberta não mantém mais threads de trabalho próprias e, com o pool ocupado, o download de um segmento é adiado em vez de reiniciar a entrada.

• Outras melhorias e correções de erros.

versão 2.0.2.362

06.09.2026

• Menu do módulo CI — o menu próprio do módulo é lido: estado do cartão, assinaturas, número de série, entrada do PIN e itens de serviço estão disponíveis diretamente na tela de hardware — o mesmo que o módulo mostraria na tela do televisor. Ali mesmo surgiu o passaporte do módulo — fabricante, código do produto e tipo de aplicação EN 50221 — e o nó decodifica seu nome, de modo que nomes cirílicos não chegam mais corrompidos (Menu do módulo).

• Desembaralhamento por um módulo CI separado — um módulo em um leitor de cartões autônomo atende qualquer entrada de um fluxo, e não apenas a recepção de uma placa DVB: por ele passa todo o transporte da entrada, ao passo que a lista de programas apenas indica quais deles desembaralhar. O slot é atribuído na própria entrada, e ali mesmo se vê qual entrada o ocupa (CI/CAM na entrada de um fluxo).

• Vários slots CI em uma mesma entrada — o multiplex é conduzido sucessivamente através de vários módulos, com seu próprio conjunto de programas para cada slot. A frequência de relógio do barramento CI é escolhida conforme o bitrate real da entrada, e um slot que tenha ficado ocupado é liberado mediante solicitação a partir da tela de hardware.

• Tabelas de serviço na demultiplexação — as tabelas de rede e de hora e os demais PID de serviço do multiplex de origem passam a obedecer às mesmas chaves mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary e mpegts-filter-cat que nos demais caminhos, em vez de serem descartadas incondicionalmente. Com isso o padrão mudou: um fluxo extraído de um multiplex carrega as tabelas de rede e de hora que antes não carregava — um receptor por trás desse fluxo, e um módulo CI em primeiro lugar, espera vê-las. O comportamento anterior é restabelecido por mpegts-filter-nit.

• Uma descontinuidade de PCR não esvazia mais o buffer de jitter — uma entrada que captou um salto de PCR para a frente desloca o ponto de sincronização em pleno funcionamento, sem drenar a fila, de modo que a descontinuidade custa um único tropeço em vez de um novo enchimento do buffer. A janela a partir da qual um salto conta como descontinuidade é escolhida automaticamente (Sincronização).

• Partida rápida de uma entrada HLS — uma playlist ao vivo é retomada pela cauda: entram na fila apenas os últimos segmentos necessários para o jitter configurado, e não a janela inteira, de modo que a entrada vai ao ar com um atraso de alguns segmentos em vez de uma janela inteira da playlist. Uma playlist concluída (VOD) continua sendo reproduzida desde o início.

• Supressão da oscilação de alertas — um alerta que se levanta e se resolve repetidamente é dobrado em um único incidente: o nó o mantém durante a calmaria e o fecha apenas quando a oscilação de fato cessou. Uma tempestade de repetições não se espalha nem pelo registro nem pelos canais externos. Uma fonte oscilante, uma vez reconhecida, continua reconhecida após a calmaria: a série seguinte dela é mantida desde a primeira repetição.

• Edição de um canal de EPG — ao canal são atribuídos um identificador XMLTV separado do nome exibido e denominações por idioma, e um canal desnecessário é excluído por inteiro: com ele vão suas denominações, seus eventos e sua participação em conjuntos.

• Outras melhorias e correções de erros.

versão 2.0.2.335

27.08.2026

• Meshwork (multidomínio) — vários servidores são reunidos em domínios nomeados, e o domínio serve de fronteira de isolamento: a filiação dos nós, o catálogo de recursos e os alertas propagam-se somente dentro do próprio domínio, e nada é transmitido entre domínios. Um nó pode integrar vários domínios ao mesmo tempo, sem misturar seus dados. Em detalhes — Meshwork.

• Autodescoberta de nós — basta definir o domínio e um único ponto de entrada: os nós trocam listas de vizinhos e constroem por conta própria uma malha totalmente conectada de ligações diretas. A chave comum do domínio é gerada automaticamente e é transmitida apenas por um canal protegido — TLS ou um segmento confiável da rede local.

• Biblioteca de recursos distribuída — as saídas UDP, RTP, Pro-MPEG e RIST, as entradas multicast UDP, RTP e RIST, bem como as ligações PS1 e SRT são publicadas no catálogo comum do domínio (/data/library): uma lista única de grupos multicast, portas, VLANs, fontes SSM e ligações ponto a ponto com a indicação do nó e do fluxo. Pelo catálogo vê-se quais endereços e portas já estão ocupados, e uma nova entrada é conectada diretamente a partir dele — pela escolha de um fluxo já entregue em outro nó do domínio, sem digitar o endereço manualmente.

• Visão geral dos nós do domínio — para cada nó são exibidos o status, o horário do último contato, o papel, a região, a versão da compilação, o tempo de funcionamento desde a inicialização, a carga de CPU, o tráfego por interface física e o número de fluxos no ar, e para cada ligação entre nós PS1 ou SRT — o bitrate, o RTT, a proporção de retransmissões e perdas e um veredicto sobre o seu estado. Um nó que caiu não desaparece da lista: ele permanece nela como inacessível, junto com o seu alerta, por sete dias, e um nó retirado de operação é removido da visão geral por um comando próprio.

• Operação através de NAT — um nó atrás de NAT participa plenamente do domínio e sem encaminhamento de portas de entrada: ele mesmo se conecta, o ponto de acesso público é montado a partir do endereço efetivamente observado e da porta anunciada, e os vizinhos retransmitem o seu estado por um salto — o nó é visível também para aqueles que não conseguem alcançá-lo diretamente.

• Nome do nó a partir do certificado — um nó sem nome de host configurado anuncia aos seus peers o nome coberto pelo seu próprio certificado, e somente depois que esse nome é resolvido de volta para ele; o resultado da verificação aparece nos dados do servidor como cert-host e cert-host-refused.

• Login automático das ligações dentro do domínio — para as ligações PS1 e SRT entre nós de um mesmo domínio não é necessário criar login e senha para cada ligação: no lado chamador (entrada PS1, entrada SRT, saída SRT no modo caller) basta ativar a configuração «Meshwork peer auth», e a autorização é feita pelo segredo comum do domínio. O nó parceiro confirmado e o seu fluxo ficam visíveis na biblioteca de recursos e na lista de sessões.

• Low-Latency HLS e MPEG-DASH sobre CMAF — novo modo de distribuição «OTT / LL-HLS / DASH»: o multiplexador integrado forma um MP4 fragmentado (CMAF), sobre o qual são entregues MPEG-DASH em /dash e Low-Latency HLS em /llhls; os pacotes adaptativos também são montados para esses formatos. Em detalhes — Modos de distribuição.

• Baixa latência do LL-HLS — a playlist de mídia é dividida em partes, são aplicados o recarregamento bloqueante da playlist e a dica de pré-carregamento, de modo que o player inicia a reprodução sem aguardar que o segmento completo esteja pronto. Os segmentos CMAF transportam Producer Reference Time, o manifesto DASH anuncia UTCTiming e a latência-alvo, e a configuração «Duração-alvo da parte LL (ms)» é aplicada em tempo real, sem reiniciar o fluxo.

• HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS e MPEG-TS over HTTP são entregues sobre QUIC em uma porta UDP própria, com 0-RTT opcional; o cliente solicita a mudança para QUIC pelo parâmetro ?h3. O QUIC só funciona sobre TLS: com o TLS desligado o listener não é levantado nem oferecido ao cliente, e o seu estado real aparece nos dados do servidor HTTP, e não apenas na configuração. As rotas administrativas permanecem somente em TCP.

• Alinhamento dos segmentos pelo IDR — o segmentador distingue o IDR do quadro I comum: em fontes com closed-GOP cada segmento começa por um ponto de entrada pleno, de modo que o player abre o fluxo a partir de qualquer segmento; em fontes com open-GOP o limite é o quadro I mais próximo.

• Proteção de conteúdo (DRM) — a distribuição OTT do fluxo pode ser criptografada: HLS AES-128 com uma chave do próprio servidor ou de um servidor de chaves externo e com rotação opcional por janelas de tempo, ou MPEG Common Encryption (ISO/IEC 23001-7) pelos esquemas cenc e cbcs para CMAF e DASH. A criptografia é executada uma única vez, no momento da formação do segmento, de modo que o arquivo DVR é armazenado criptografado e sobrevive a qualquer número de rotações de chave. Em detalhes — Proteção de conteúdo (DRM).

• Cada conexão MPEG-TS over HTTP é uma sessão própria — a lista de clientes do fluxo agora tem uma linha por conexão com o seu próprio sess-id, os detalhes ficam disponíveis em /data/stream/http-clients/<sess-id>, uma conexão isolada é fechada com POST /data/kick?sess-id=<id> e o limite max-conn é respeitado também com valores maiores que um.

• DVR (arquivo em rede) — cada canal OTT é gravado em disco em paralelo com a distribuição, com a mesma segmentação e sem um gravador separado; no modo de baixa latência o arquivo é mantido em duas linhas, MPEG-TS e CMAF, de modo que a gravação fica disponível no mesmo contêiner que a transmissão ao vivo. Em detalhes — DVR.

• Reprodução do arquivo (VOD) — o arquivo é entregue pelas mesmas URLs HLS, DASH e LL-HLS que a transmissão ao vivo: t=<tempo> ativa o modo VOD e define o início da janela, d=<segundos> — a sua duração. A playlist HLS é então fechada, o manifesto DASH é estático e as interrupções da gravação são apresentadas como períodos separados; os pacotes adaptativos reproduzem o arquivo com os mesmos parâmetros.

• Catch-up por EPG — em vez de t e d basta passar epg=<tempo>: o próprio servidor encontra no canal EPG vinculado o programa que está no ar naquele momento e toma o seu início e a sua duração como limites da janela de reprodução.

• Legendas no arquivo — as faixas WebVTT são gravadas em disco junto com os segmentos e são reproduzidas em VOD pelas mesmas URLs; as janelas sem falas não ocupam espaço em disco.

• Armazenamentos DVR — pode haver vários armazenamentos, cada um com o seu próprio limite de preenchimento e a sua própria ordem de limpeza. A profundidade do arquivo («Retenção (horas)», até 90 dias) e o mínimo protegido são definidos separadamente para cada fluxo, e a limpeza por espaço livre não toca nem no mínimo protegido nem nas janelas das sessões VOD abertas.

• Monitor de DVR — uma tela dedicada mostra o estado e o preenchimento dos armazenamentos, o volume e a profundidade do arquivo por fluxo e as latências de leitura e de gravação, enquanto o histograma de cobertura (/data/dvrstat) assinala não apenas as lacunas do arquivo, mas também a sua causa — perda da entrada, troca do PMT, embaralhamento, acionamento da limpeza. Da mesma tela são apagados o arquivo de um fluxo individual e os diretórios dos fluxos removidos.

• Uma falha de disco do arquivo não para mais o nó — um erro no atendimento ao arquivo DVR fica restrito ao armazenamento e à etapa em que ocorreu: os demais fluxos e as demais linhas de gravação continuam funcionando, e o arquivo afetado é marcado como necessitando de reconstrução.

• Alertador — novo serviço de alertas: cada falha torna-se um incidente que é gerado, atualizado e resolvido automaticamente, enquanto o conjunto ativo deduplicado mostra apenas o que está acontecendo agora. A gravidade é definida por uma escala única — da informativa à que exige intervenção do administrador; tal incidente é resolvido pela confirmação do operador. Em detalhes — Alertas (alerter).

• Catálogo de códigos de falhas — mais de cinquenta tipos de incidentes em uma única lista: os fluxos e as suas entradas e saídas, as violações da TR 101 290, os recursos do nó, os armazenamentos e a saúde da gravação DVR, a recepção DVB e CI/CAM, os transcodificadores, o OTT, os certificados e os nós do domínio. Os limiares de acionamento são configurados na seção de alertas.

• Entrega externa de alertas — os alertas saem para fora do console web: por e-mail via SMTP (STARTTLS, implicit TLS, AUTH), por mensagem no Telegram e pela execução de um comando arbitrário, ao qual o incidente é passado em variáveis de ambiente e como JSON completo na entrada padrão. Cada canal tem o seu próprio interruptor e o seu próprio limiar de gravidade.

• Alertas de todo o domínio — o operador de plantão vê os alertas de qualquer nó a partir de qualquer outro: o conjunto ativo propaga-se junto com o keep-alive e é resolvido assim que desaparece na origem, e cada linha indica o nó de origem. Os alertas de hardware e de sistema permanecem locais por padrão e são promovidos ao nível do domínio por uma configuração separada.

• Registro em banco de dados — as mensagens do serviço são gravadas em SQLite: registros tipados com a fonte e o nível de gravidade, agrupamento das repetições consecutivas em uma única linha com contador, retenção limitada por prazo e por volume. Ao contrário do conjunto ativo de alertas, o registro sobrevive a um reinício.

• Interruptor geral das notificações — com enable desligado nas configurações do alertador, o nó não gera alertas próprios nem envia nada para fora, inclusive os alertas recebidos dos seus peers do domínio; na lista e no fluxo de eventos permanecem apenas os alertas dos peers distribuídos pelo domínio.

• A gravidade de um alerta de entrada/saída segue as consequências — uma entrada que falha enquanto não está conduzindo o fluxo é marcada como Error, ao passo que uma entrada condutora, qualquer saída e uma falha sem transmissão são marcadas como Critical; a avaliação é recalculada enquanto o alerta está aberto e acompanha a comutação para a reserva.

• Cor nas notificações externas — ao texto da mensagem foi acrescentado um marcador de cor do nível (vermelho para erros, amarelo para avisos, verde para a baixa, azul para informativos), e o e-mail sai em duas variantes ao mesmo tempo: texto simples e HTML com uma faixa colorida.

• As notificações no Telegram sobrevivem a uma tempestade — os alertas acumulados são combinados no menor número de mensagens que o limite de 4096 caracteres permite, e diante de uma resposta de limitação de frequência o nó aguarda o tempo indicado e repete o envio em vez de descartar a notificação.

• O atraso da notificação passa a valer para a entrada de reserva — o aviso de que um fluxo está funcionando na sua entrada de reserva só é levantado se a situação durar mais que alert-delay, de modo que uma fonte que se recupera e cai de novo não produz mais uma sequência de aberturas e baixas; com alert-delay igual a zero o comportamento é o anterior.

• Monitor TR 101 290 — controle contínuo da conformidade do fluxo de entrada com a norma: um veredito único («Normal», «Problema», «Verificando…») e um relatório estruturado por prioridades 1, 2 e 3, no qual são indicados, para cada indicador, o item da norma, o valor medido e o limite. Um multiplex MPTS é avaliado por inteiro — por todos os PID, programas e tabelas SI. O fluxo é classificado automaticamente como CBR ou VBR, e as verificações que só fazem sentido com bitrate constante não são avaliadas em uma fonte VBR e não produzem acionamentos falsos. Em detalhes — Monitor TR 101 290.

• Deriva do oscilador de referência — o desvio sistemático da frequência de relógio da fonte é medido por regressão linear em ppm com a tolerância da ISO/IEC 13818-1 de ±30 ppm e é apresentado como uma métrica separada. Um desvio lento é tratado por microdeslocamentos suaves do ponto de sincronização («Compensação da deriva de sincronização», ativada por padrão), de modo que não há solavancos na saída.

• Modelo de buffer T-STD — análise do buffer de vídeo do decodificador de referência conforme a ISO/IEC 13818-1, com contadores de estouro e de esvaziamento para MPEG-2, H.264 e HEVC; a contagem é feita pelo relógio do PCR, e a velocidade de escoamento acompanha o bitrate real do vídeo. É ativado pela configuração «Analisar o buffer de vídeo T-STD».

• Análise para a inserção de publicidade — interpretação das seções SCTE-35 com eventos de emenda, pontos de emenda do nível de transporte com notificação antecipada configurável e indicadores de acesso aleatório. Os dados são exibidos nas estatísticas do fluxo quando a análise profunda está ativada.

• Assistente de reclamações — para um fluxo com violações persistentes é gerado um texto-instrução pronto para um chat de IA, a partir do qual este redige uma carta formal de reclamação ao fornecedor do fluxo: a lista das violações persistentes, os valores medidos, os itens da norma e o impacto sobre o decodificador. A instrução é entregue pela requisição GET /data/stream/<id>/ai-complaint-prompt; o nome do fluxo e o endereço da fonte não são incluídos no texto.

• CI/CAM (EN 50221) — host Common Interface integrado: detecção do módulo, leitura do seu nome e da lista de CA_system_id suportados, seleção dos programas para desembaralhamento e envio do CA_PMT para cada um deles. Um módulo combinado com o receptor DVB desembaralha inline os programas selecionados do multiplex recebido, vários ao mesmo tempo; o estado dos slots e o veredito de cada programa são visíveis na interface.

• Desembaralhador por software BISS-1 / BISS-E — aplica-se não apenas à recepção a partir de uma placa DVB, mas a qualquer entrada de fluxo: a chave é definida para todo o SPTS ou por programas do multiplex e é alterada em tempo real, sem reiniciar a entrada. Na recepção a partir de uma placa DVB o resultado é adicionalmente verificado no próprio fluxo, de modo que uma chave incorreta não parece um desembaralhamento bem-sucedido, mas gera um alerta específico.

• Limpeza do acesso condicional na recepção DVB — por uma configuração separada do adaptador, os PID ECM e EMM são removidos do multiplex recebido pela placa DVB, e os descritores CA dos programas abertos são removidos do PMT: adiante no percurso segue um fluxo FTA limpo. Em caso de perda da chave, a sinalização de acesso condicional é restaurada para que um receptor mais adiante na cadeia possa solicitar acesso novamente.

• Telemetria do transcodificador — para cada codificador são publicadas as informações de mídia da saída recodificada: o formato do quadro, o codec de vídeo, o conjunto de codecs de áudio e o bitrate atual, e para cada processo — a carga de CPU e a memória ocupada.

• RTMP e RTMPS — o canal é publicado em qualquer receptor RTMP, incluindo YouTube e Facebook: vídeo H.264 ou HEVC (HEVC — via Enhanced RTMP) e uma única faixa AAC; para rtmps:// o nó conecta-se como cliente TLS. No sentido inverso, a própria entrada busca o fluxo da fonte rtmp:// ou rtmps:// e remultiplexa FLV para MPEG-TS.

• Comutação de fonte sem interrupção — ao trocar a entrada ativa no emissor, os peers PS1 receptores não se reconectam: a numeração e as marcas de tempo permanecem contínuas, um pico da fila é absorvido pelo descarte dos pacotes mais antigos, e a lacuna é completada pela retransmissão comum.

• Retransmissão adaptativa PS1 — o receptor mede o RTT real até o emissor e ajusta a ele, por conta própria, os intervalos das requisições de repetição; o RTT medido, o intervalo atual de nova requisição e o indicador de latência insuficiente são apresentados nas estatísticas da ligação. A latência do túnel de recepção é definida diretamente em milissegundos, em vez do antigo múltiplo do RTT.

• Os estados «Reconectando» e «Ação do administrador» — uma entrada ou saída que perdeu a sua fonte é reaberta no lugar e permanece no estado «Reconectando» durante todo o tempo das tentativas, gerando um único aviso por episódio em vez de uma mensagem a cada tentativa. Uma causa que a repetição não elimina — porta ocupada, interface ausente, dados que não são MPEG-TS, recusa do SRT por criptografia — o nó transfere para o estado «Ação do administrador» com um alerta persistente, e a edição das configurações é aplicada imediatamente.

• Data do último erro — junto ao texto do último erro de uma entrada ou de uma saída é publicado o seu horário (last-error-ts, o mesmo campo existe também no fluxo de eventos), de modo que uma causa antiga que ficou em uma entrada pausada é vista separadamente da falha atual.

• Diagnóstico quando o conteúdo da entrada é inservível — a mensagem sobre a perda de sincronização MPEG-TS nomeia a causa provável: pacotes foram encontrados, mas estão deslocados por um número conhecido de bytes, ou não há estrutura MPEG-TS alguma; para as entradas PS1 e Pro-MPEG é acrescentada uma dica sobre a frase secreta da criptografia.

• Tamanho real do buffer de recepção — a entrada publica socket-buffer-actual, o tamanho concedido pelo kernel, ao passo que socket-buffer-size continua sendo apenas um pedido e é cortado pelo limite do sistema; a divergência passa a ser vista de imediato em vez de aparecer como perdas em bitrate alto.

• Multiplexador MPTS: identidade original — os programas podem manter os seus PID originais, e a ordem dos programas no PAT, no SDT e no NIT é definida manualmente, de modo que o multiplex é migrado para o Perfect Streamer sem alterar a identidade do fluxo para o equipamento receptor. Os programas com embaralhamento TS são migrados com as suas marcas de tempo originais.

• Numeração automática de PID para SPTS — o enable-autopid junto com o autopid-base move todo o programa para uma janela previsível de 64 identificadores, começando pela PMT e depois vídeo, áudio e os demais fluxos elementares na ordem da tabela original; um programa que não couber na janela mantém integralmente os seus PID originais.

• O tamanho do datagrama é definido em todas as saídas — a configuração packets agora se aplica não só ao SRT, mas também às saídas UDP, RTP, Pro-MPEG e RIST, e na saída para arquivo e para o fluxo padrão define o tamanho do bloco gravado. Os valores padrão coincidem com o comportamento anterior, portanto uma configuração em que a chave nunca foi definida não muda; um valor salvo diferente do padrão era ignorado pelas compilações anteriores e agora entra em vigor no primeiro reinício — verifique-o antes de atualizar.

• Integração com faturamento externo — cada sessão de espectador é autorizada em um sistema externo de faturamento ou CRM, é mantida por reautorização periódica e, ao terminar, é comunicada a esse mesmo sistema: ciclo de vida Start / Interim / Stop no estilo RADIUS; a revogação da assinatura encerra a sessão no meio da exibição. São abrangidos o OTT, o peering PS1 e as saídas SRT, e o próprio sistema de faturamento é conectado por modelos de requisição e de análise da resposta, sem modificação do software.

• Cliente ACME integrado (Let’s Encrypt) — emissão e renovação automática dos certificados para o servidor web, o servidor HTTP/OTT e o servidor EPG: o certificado é solicitado para cada nome de host configurado, a renovação é verificada diariamente e, em caso de insucesso, é gerado um alerta. São suportados uma autoridade certificadora arbitrária e a vinculação externa da conta, e o novo certificado é aplicado sem reiniciar o serviço.

• Parada rápida do serviço — a parada não espera mais por um cliente que deixou de ler os dados: sob a mesma carga o nó termina em 2–4 segundos em vez de cerca de um minuto, por isso um reinício leva segundos e não deixa a transmissão fora do ar.

• pss_lic 2.0 — o utilitário de console para gerenciar a licença passou aos comandos apply, c2v, fingerprint, recipient, keys, detach, rehost e cancel com opções longas: ele aplica uma atualização de licença recebida, exporta o estado da chave para o fornecedor e transfere a licença de um nó para outro, inclusive temporariamente, e aceita qualquer arquivo na entrada padrão e escreve na saída padrão. Em detalhe — pss_lic.

• Edição manual do arquivo de configuração — junto com a documentação é publicado um JSON Schema para pss.json (estrito e compatível) e um guia passo a passo para editar e transferir o arquivo: a configuração de um nó parado pode agora ser editada diretamente e transferida entre instalações e versões, depois de verificado o resultado pelo esquema, ao passo que antes a API HTTP era a única forma suportada. Em detalhe — O arquivo de configuração pss.json.

• Nova interface web — o gerenciamento do nó foi transferido para um novo console, que se abre no endereço do nó (caminho /admin): visão geral, fluxos, monitoramento do sistema, DVB, DVR, transcodificadores, clientes, registro, alertas e todas as configurações do servidor. Diagramas dedicados mostram a topologia do domínio Meshwork e o percurso do fluxo selecionado, das entradas às saídas. A interface anterior foi preservada no endereço /classic. Em detalhes — Interface web.

• Login único no domínio — uma conta pode receber permissão de login automático: após um único login com senha, o navegador abre o painel deste nó sem o formulário de login por 14 dias e sobrevive a uma reinicialização. Seguir um link desse painel passa a sessão para um nó vizinho do domínio se as condições da passagem forem atendidas (Servidor web e contas); um endereço de vizinho digitado à mão não passa a sessão. Um script ou um painel de terceiros apresenta a mesma chave no cabeçalho X-Auth-Token ou no parâmetro auth-token, e um administrador revoga o login automático em todo o domínio de uma só vez.

• CORS para a API administrativa — os nós de um mesmo domínio Meshwork são permitidos sem nenhuma configuração, as demais origens são listadas em web-server/cors-origin (o valor * permite qualquer origem, none desliga o mecanismo), de modo que a interface de um nó acessa a API de outro; uma requisição entre domínios precisa levar o token explicitamente — cookie e Digest não funcionam nela.

• Token da própria sessão — GET /data/auth-token devolve ao cliente o seu próprio token e o prazo absoluto de validade, e em /data/server foi acrescentado o campo web-login-expires, de modo que a interface mostra até quando o login é válido sem ler o próprio token.

• Encerramento de uma sessão de login automático — POST /data/auth-tokens/revoke?login=<login> fecha todas as sessões ativas de uma conta, e ?id=<hex> fecha uma pelo identificador da lista de sessões; na resposta vem o número de sessões fechadas, e a revogação se propaga por todo o domínio.

• Motivo da recusa ao passar para um nó vizinho — se a passagem não resultou em login automático, o nó devolve no endereço um parâmetro jump com o valor no-session, foreign-domain, autologin-off ou token-refused, em vez de mostrar silenciosamente o formulário de senha.

• Atualização em tempo real — o nó publica o seu estado como um fluxo de eventos em /data/events: na conexão chega um instantâneo completo, depois, uma vez por segundo, são atualizados os quadros dos fluxos, dos recursos do sistema, dos clientes e dos adaptadores DVB, enquanto os alertas e as mudanças de estado chegam como eventos. A interface e os painéis externos funcionam sem consulta periódica.

• Ajuda contextual — cada tela e cada janela importante da nova interface dispõem de uma chamada de ajuda que abre a seção da documentação correspondente exatamente ao que está aberto no momento: o botão geral de ajuda — para a tela, o botão «?» no cabeçalho da janela — para essa janela. A seção abre-se no idioma da interface.

• Idiomas, temas e layouts — a interface está traduzida para seis idiomas (russo, inglês, alemão, francês, espanhol, português), suporta os temas claro e escuro e ajusta por conta própria a densidade do layout ao telefone, ao tablet, à estação de trabalho e ao videowall.

• Acesso sem limite do número de conexões — os limites de conexões do destinatário ganharam um terceiro estado, «Sem limite», ao lado de «Protocolo proibido» e «No máximo» com um número; antes o acesso ilimitado era representado por um número deliberadamente grande. Zero continua significando a proibição do protocolo, de modo que o sentido das configurações salvas não muda após a atualização. Em detalhe — Usuário: adicionar e alterar.

• A edição do acesso aos fluxos não afeta sessões alheias — acrescentar um fluxo à lista de permitidos e voltar a uma lista vazia não rompem nenhuma sessão, e estreitar a lista fecha as sessões PS1 e SRT apenas nos fluxos que saíram dela. Antes, qualquer edição da lista desconectava a conta por inteiro em todos os protocolos.

• Ativação da licença pela interface web — a tela «Licença» ganhou uma seção «Ativação»: a exportação do estado da chave para o fornecedor — como arquivo C2V ou para a área de transferência — e a aplicação da chave V2C recebida, por arquivo ou colando o texto. A aplicação da chave reinicia o nó. Em detalhe — Licença.

• Aviso de vencimento da licença — o nó gera um alerta duas semanas antes do fim do prazo e o eleva ao nível que requer intervenção quando o prazo termina. O alerta é replicado pelo domínio, de modo que a licença vencendo de um vizinho é visível de qualquer nó (Alertas (alerter)).

• Uma licença considerada não autêntica para o nó — um nó cuja licença é considerada não autêntica levanta um alerta que requer ação do administrador, reinicia o serviço e a inicialização é recusada: o serviço permanece parado até que haja uma licença autêntica no nó. O alerta é replicado por todo o domínio (Alertas (alerter)).

• Retorno à última configuração operacional — o nó guarda uma cópia das configurações com que iniciou de forma limpa da última vez e, quando o pss.json é inaceitável, sobe com ela — com todos os seus fluxos, e não com as configurações padrão, que não contêm fluxos. O arquivo de arquivos rejeitados foi colocado em ordem: nomes em UTC, sufixo numérico em vez de sobrescrita quando duas falhas caem no mesmo segundo, as vinte cópias mais recentes; o alerta indica diretamente o caminho da cópia arquivada. Em detalhe — Comportamento na inicialização e em erros de configuração.

• A prioridade das entradas é editada com o mouse e pelo teclado — o administrador pode reordenar as entradas de um fluxo arrastando ou com Alt+↑ e Alt+↓, na aba «Entradas» do editor e na linha expandida da lista de fluxos (no telefone a ordem apenas é exibida); uma entrada adicionada fica sempre por último e nunca substitui a principal (Fluxos).

• O número de uma entrada é o seu lugar na lista de redundância — um mesmo número aparece agora na linha do fluxo, na linha expandida, no editor e no texto do alerta. As entradas com o mesmo valor de prioridade mantêm a ordem em que estão registradas, inclusive nas edições posteriores das configurações (Redundância de fontes).

• A falha de uma entrada abandonada lê-se como histórico — a entrada de que o fluxo saiu ao passar para a reserva é parada, mas mantém a sua causa: a interface a exibe como uma linha esmaecida com a idade, e não como uma falha atual, e o alerta sobre o erro dessa entrada é retirado. A causa é então a sua própria, de transporte, se a entrada chegou a informá-la (Redundância de fontes).

• Ordenação da lista de clientes — na tela «Clientes» o cabeçalho da coluna ordena a lista: as colunas numéricas abrem em ordem decrescente, as de texto de A a Z, e o terceiro clique devolve a ordem do nó. É ordenada toda a lista encontrada, e não a página exibida (Clientes).

• Ir para o fluxo a partir da tela de transcodificadores — a linha do decodificador e de cada codificador ganhou um botão que abre a lista de fluxos no fluxo em questão. Disponível em qualquer papel (Transcodificadores).

• O programa do demultiplexador é escolhido em uma lista também para um adaptador DVB — um adaptador em funcionamento publica o seu multiplex, e o campo «PNR» oferece os seus programas com os nomes, incluindo os programas internos T2-MI sob os seus números compostos (Demultiplexador (demuxer)). O adaptador de uma entrada dvb também é escolhido pelo nome, em vez de ser digitado como número de registro (Adaptador DVB (dvb)).

• A recepção DVB não depende mais da compilação — o tipo de entrada dvb e a seção de adaptadores DVB estão disponíveis em qualquer nó; a única condição é um frontend detectado e um driver que permita ao serviço abri-lo (Receptor DVB).

• O scanner DVB cede o sintonizador a um adaptador configurado — um multiplex encontrado pode ser aplicado sem esperar o fim da passagem: o adaptador toma o sintonizador e sobe em cerca de um segundo, enquanto a varredura termina como cancelada, mantendo os seus resultados na tela. Uma passagem é interrompida com o botão «Parar» e ao fechar a janela (Pesquisa).

• Os painéis do panorama do nó seguem a presença do subsistema — «Transcodificadores» e «Adaptadores DVB» aparecem no panorama onde existe o próprio equipamento ou as instâncias, ou onde há uma falha a relatar. Em um nó sem transcodificadores e sem sintonizador esses painéis não existem, e tampouco a entrada para as suas seções a partir do panorama (Visão geral do nó).

• Endereços das interfaces no monitor do sistema — o cartão «Rede» e os gráficos de histórico levam o endereço IPv4 da interface quando o nó o informa, incluindo as VLANs aninhadas (Monitor do Sistema).

• O caminho de um armazenamento DVR é escrito sem separador final — a interface e a API HTTP rejeitam esse valor: duas grafias de um mesmo diretório passariam pela verificação de unicidade como dois armazenamentos diferentes (Armazenamentos DVR).

• O pacote precisa do serviço de proteção 10.33 ou mais recente — o pstreamer fornece as bibliotecas de nova geração do sistema de proteção, e um aksusbd mais antigo não as aceita (Requisitos do sistema). O serviço está no mesmo repositório e é instalado junto com o pacote, mas a sua atualização é irreversível, qualquer que seja o tipo de chave — o procedimento e as consequências estão descritos nas páginas de instalação (Instalação em sistemas da família RHEL, Instalação em sistemas da família Debian).

• Seleção explícita do PLP em DVB-T2 — o campo «Stream id (ISI/PLP)» ganhou o valor «auto» (-1): nenhum filtro é aplicado, o sintonizador toma o fluxo padrão do driver, e um adaptador novo é criado exatamente assim. Um zero explícito passou com isso a ser uma seleção real do fluxo zero, e não «não definido», de modo que um adaptador com zero salvo nas configurações passará, após a atualização do nó, a receber apenas esse fluxo (Adaptadores).

• O scanner encontra os PLPs — o campo «Verificar PLP até» percorre os PLPs nos transponders DVB-T2 e exibe cada um encontrado em uma linha separada com a sua própria lista de programas; o número é transferido para o adaptador criado, e as estatísticas do adaptador ganharam uma linha «PLP / ISI» (Pesquisa).

• Busca nos catálogos do scanner — centenas de satélites e faixas regionais estão ordenados por nome e são filtrados por uma cadeia de busca; uma linha já selecionada não desaparece da lista, seja lá o que for digitado (Varredura DVB).

• Correção da referência ao PCR na PMT — uma nova configuração MPEG-TS para fontes cuja tabela não declara um PCR utilizável: o nó declara na PMT o PID em que o PCR é realmente transmitido (Modificação do fluxo).

• Reconstrução do buffer de jitter após uma queda da fonte — uma entrada que sobreviveu a uma parada da sua fonte já não segue com uma fila quase vazia, repassando às saídas cada nova falha: o nó reconstrói o buffer uma única vez, ao custo de um único corte (Sincronização).

• Modo de controle de bitrate do codificador de vídeo — o transcodificador ganhou a escolha entre uma taxa constante e dois modos variáveis: o número informado é lido como o bitrate médio (os picos chegam a uma vez e meia esse valor) ou como um teto rígido (a taxa média fica então em dois terços dele). O número continua sendo apenas um — o codificador deduz o segundo limite a partir de uma relação fixa entre pico e média de 1,5. Nos modos variáveis o codificador deixa de preencher o fluxo elementar, de modo que a economia de banda só ocorre onde o fluxo receptor não nivela o bitrate de volta (Configurações do codificador).

• O reinício do transcodificador é explicado no registro — cada reinício do processo filho indica a sua causa e o seu código de saída no nível «Notificação», e não em silêncio no rastreamento. Além disso, o nó deixou de reabrir indefinidamente um canal que não responde: após duas tentativas malsucedidas, ele solicita um novo processo (Controle do funcionamento).

• Um fluxo excluído aparece no editor aberto — se um fluxo for excluído do nó enquanto o seu editor ou o seu esquema de processamento está aberto, o nó informa isso em uma linha própria, e salvar deixa de estar disponível com a mesma razão indicada ao lado do botão. Antes, todas as listas desse fluxo simplesmente se esvaziavam, o que parecia um fluxo sem entradas e saídas configuradas (Configurar fluxo).

• Um salvamento recusado indica a sua causa — em vez de uma única frase geral para todos os casos, o formulário informa o que exatamente impediu: um tempo de espera de resposta esgotado, uma proibição por papel ou a própria recusa do nó, com as palavras dele.

• Rótulos e seleção de PID nas regras de filtragem — cada número é rotulado com o seu tipo e o seu codec e, em um multiplex, também com o programa a que pertence; a linha de adição ganhou a lista dos PIDs que a fonte realmente transporta. A entrada manual permanece: o transporte pode levar um PID sobre o qual nada foi decodificado (Editor de entrada e saída).

• As telas DVB mostram o número de programa endereçável — para um serviço dentro de uma portadora T2-MI, a lista de programas do adaptador e as suas estatísticas trazem o PNR composto, o mesmo pelo qual o programa é endereçado na seleção do demultiplexador, do BISS e do CAM. O número próprio dentro da portadora repete-se em cada portadora de um transponder com grupos espelhados e não aponta para nada (Estatísticas do adaptador).

• Um slot BISS é sempre oferecido como lista — os programas abertos entraram nela por último, marcados com · clear ·, de modo que em um multiplex sem um único programa codificado a lista já não fica vazia: a chave costuma ser informada com antecedência, e um feed de eventos fica aberto entre os eventos (Desembaralhamento).

• Das estatísticas do fluxo ao transcodificador e à sua fonte — se a entrada ativa de um fluxo foi criada por um transcodificador, o seu valor tornou-se um link para a tela de transcodificadores com a linha da instância correspondente expandida, e ao lado surgiu uma etiqueta com o nome do fluxo que essa instância decodifica. Ambos os links estão disponíveis em qualquer papel (Estatísticas do fluxo).

• Limites das execuções no registro — cada início do serviço é marcado no fluxo por uma linha própria com o momento do início e a compilação em que a execução subiu: a atual traz ao lado o seu tempo de atividade, as anteriores indicam quanto tempo a execução funcionou e quanto tempo o nó ficou parado até o início seguinte, e uma execução encerrada sem parada normal é assinalada à parte. O separador é colocado mesmo com o filtro por gravidade ativado (Registros).

• Limite de tamanho da base de estatísticas — a base de métricas é limitada não apenas pela janela de retenção, mas também pelo tamanho. O nó presta contas da última limpeza — quanto de histórico restou, qual é o tamanho da base e quanto durou a limpeza — e informa expressamente se o limite de tamanho se mostrou mais rígido do que a janela configurada (Configurações do servidor).

• Os valores ajustados ao limite durante a carga são anunciados de imediato — se o nó, ao ler as configurações, puxou um valor até o limite admissível, ele informa isso na tela logo após a inicialização, e não apenas com uma linha no registro (Comportamento na inicialização e em erros de configuração).

• Uma licença de geração obsoleta não é aceita — um nó com uma licença autêntica da geração anterior não inicia e levanta um alerta próprio. Não se trata de prazo vencido nem de falsificação: a geração 2 é aceita apenas como licença de avaliação temporária, por isso uma licença perpétua dessa geração é recusada de imediato, em vez de viver até a sua data (Catálogo de códigos de alerta).

• O preenchimento automático calcula o alvo pelo conteúdo — no modo automático de bitrate o nó parte da taxa real do conteúdo, e não da sua própria saída, de modo que o alvo já não sobe sem retorno e volta a descer assim que o conteúdo cabe novamente na taxa configurada (Controle de bitrate).

• A janela de compensação de deriva é proporcional ao buffer — a janela suave é limitada a um quarto do tamanho alvo do buffer de jitter, mas nunca abaixo de 100 ms: uma entrada com o buffer padrão já não trabalha sem folga, a compensação recupera a sincronização mais cedo, e a reconstrução de emergência do buffer ao esvaziar finalmente é acionada (Sincronização).

• Outras melhorias e correções de erros.