Histórico de versões

versão 2.0.0.206 Beta

25.07.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, 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 de perdas e o veredito de estado.

• 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.

• 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 separada, com 0-RTT opcional; o cliente solicita a mudança para QUIC pelo parâmetro ?h3. As rotas administrativas permanecem apenas 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 é reproduzido através de qualquer número de trocas de chave. Em detalhes — Proteção de conteúdo (DRM).

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• Outras melhorias e correções de erros.