Versão 26.09

Flussonic 26.09: DRM e vitrine própria na Catena, SDI, ST 2110 e RIST no Mcaster, e o NVR do Watcher migra para o novo núcleo com um botão

Quatro produtos, um núcleo

Catena, Mcaster, Agora e Watcher são quatro produtos diferentes com quatro clientes diferentes: um operador de OTT, um engenheiro de cabeceira, um radiodifusor corporativo e um integrador de segurança. Por dentro, compartilham o mesmo motor: o Sapsan, nosso núcleo de streaming escrito em Rust.

Por isso estas notas começam pelo núcleo. Tudo o que está na primeira seção chegou aos quatro produtos de uma vez — e é também por isso que uma descoberta feita num gravador de nove mil câmeras acaba fazendo um canal de televisão iniciar mais rápido.

Veja o que fizemos para o núcleo de streaming Sapsan

Sessenta vezes mais espectadores WebRTC. O WebRTC era o nosso caminho de entrega mais fraco. Um nó aguentava 200–300 sessões WHEP simultâneas e cerca de 0,9 Gbit/s, e depois simplesmente parava de aceitar espectadores: com quinhentas sessões, 448 de 500 caíam por tempo esgotado enquanto o processo usava 330% dos 7200% que a máquina tinha. Não faltava potência: todo o subsistema WebRTC era uma única tarefa que percorria todas as sessões sob um único bloqueio, de modo que criar uma sessão entrava na fila atrás da entrega a todas as outras.

Agora as sessões vivem em fragmentos com seus próprios ciclos, e os números mudaram de ordem de grandeza. Um nó sustenta 18 000 espectadores simultâneos a 32 Gbit/s, ou 16 000 mais pesados a 42,9 Gbit/s, em regime estável e sem quedas. A memória por espectador caiu de 3,8 MB para 0,6–0,7 MB, e a fila passou a ter um limite rígido: antes, seis mil espectadores ocupavam 53 GB e levavam a máquina para o swap.

Uma nota prática caso vá medir a sua própria máquina: a disciplina de fila fq que o Linux traz por padrão consome cerca de 8 Gbit/s desse número, e trocá-la por pfifo_fast os devolve.

À parte: sessões WHEP abandonadas viviam para sempre. Um espectador que fechava a aba deixava uma sessão que continuava queimando CPU e crescendo em memória a 80 MB/s até o processo ser morto. Agora essas sessões são recolhidas sozinhas.

Mais de 100 Gbit/s de HLS de uma máquina. Queríamos puxar 100 Gbit/s pela placa de rede e conseguimos, e a partir daí o limite passou a ser o slot PCIe 3.0 da bancada, não o software. Por loopback, sem o cabo no caminho, o mesmo servidor entregou 376 Gbit/s de HTTP aberto e 242 Gbit/s sobre TLS. A leitura prática não é o número em si: é que, em hardware comum, o caminho de entrega não será o primeiro a acabar.

Leitura de fMP4. O chamado #5350 — «captura de fontes MPEG-DASH / HLS fMP4» — foi aberto em março de 2018 e acumulou cerca de cinquenta pedidos de clientes, a lista mais longa do nosso sistema. Ele pede uma coisa, não duas: uma fonte moderna entregue por playlist coloca em seus segmentos MP4 fragmentado, e não MPEG-TS, e era exatamente fMP4 que não sabíamos ler. Todo agregador, toda CDN de terceiros e todo contribuidor a quem não abrem uma porta UDP ou SRT publica CMAF, e até agora não tínhamos o que responder.

Uma única regra governa o início, e vale conhecê-la. A captura começa pelo primeiro segmento que aparece depois da conexão: tudo o que já estava na janela da playlist é história. Caso contrário, uma fonte com janela de um minuto despejaria um minuto de mídia passada no seu canal em poucos segundos, e repetiria isso a cada reconexão. A mesma regra cobre uma fonte morta: uma playlist deixada por uma transmissão que já acabou nunca produz um segmento novo, então a captura simplesmente não começa, em vez de o fluxo ficar ali parecendo saudável sobre uma janela vencida.

As legendas, concluídas. Na 26.08 entregamos as legendas ocultas CEA-608/708 como WebVTT e prometemos o reconhecimento de legendas DVB para a versão seguinte. Aqui está — e com ele o teletexto, a segunda forma de legenda da radiodifusão europeia e a única em que o texto chega já como texto.

Tudo isso segue agora um único desenho: cada produtor de texto — o decodificador de teletexto, o OCR de DVB, as legendas ocultas, o reconhecimento de fala — escreve numa única camada canônica, e o espectador sempre recebe uma faixa WebVTT comum. Venha como vier no canal, o assinante do seu aplicativo vê o mesmo menu de legendas que um espectador de cabo, e os requisitos de acessibilidade são atendidos sem uma segunda entrada nem uma cadeia separada por formato. No caminho, o decodificador de teletexto foi corrigido em dois pontos que o inutilizavam: um erro na ordem dos bits do código de Hamming (a página 888 era lida como 811) e a ausência de conjuntos de caracteres nacionais, que transformava tremas e cirílico em lixo.

Transcodificação por hardware em NVIDIA. Todo o caminho de vídeo — decodificar, redimensionar, codificar — passa para a placa, escolhida explicitamente ou de forma automática, de modo que quantos canais um servidor carrega deixa de ser uma questão de quantos núcleos de CPU você comprou.

No caminho, chegamos enfim ao fundo de um bug que nos incomodava desde os tempos do Flussonic. Ele acabou não sendo nosso: é um defeito do próprio driver da NVIDIA, e a NVIDIA o registrou como Bug 6610402. Enquanto não for corrigido na origem, entregamos um contorno — então ele deixa de chegar à sua instalação.

Um distribuidor que faz o trabalho que, do contrário, você faz à mão. Decidir qual nó executa qual fluxo é uma tarefa que alguém tem de fazer — e refazer toda vez que uma máquina é acrescentada, esvaziada, sobrecarregada ou perdida. Com poucos servidores isso cabe na cabeça. Com cem já não cabe, e o preço do erro é um canal fora do ar. Agora o distribuidor da Catena decide isso por 129 regras, escritas num documento de política antes de virarem código, e os testes são conferidos contra esse mesmo documento.

O que ele cobre, em termos do operador. Exigências que uma alocação não pode violar: espaço de nomes, etiquetas obrigatórias, um fluxo que precisa de placa gráfica só num nó que a tenha, um fluxo com arquivo só num nó com armazenamento de arquivo, um limite de fluxos por nó. Preferências que desempatam. Realocação quando um nó cai, é esvaziado ou sai do cluster — enquanto um nó congelado de propósito mantém exatamente o que carrega. Sobrecarga com uma ordem de alívio definida: processador acima de 90%, rede acima de 95% do limite do nó, arquivo acima do seu limiar; primeiro alivia-se a rede, as cópias de arquivo saem antes da captura, o fluxo mais pesado vai primeiro. E os papéis além da captura: cópias de arquivo, restos de arquivo em máquinas que já não executam o fluxo, entrega ao vivo nas bordas, fluxos defasados colocados perto do arquivo que reproduzem.

Um número merece ser dito com todas as letras: no último ano, 96% dos chamados de clientes que recebemos sobre o distribuidor eram um erro de configuração do lado do cliente, e não um defeito do distribuidor. O motor raramente era o problema — o que faltava era poder ver por que ele decidiu o que decidiu. É essa metade que esta versão fecha: cada atribuição carrega agora o motivo pelo qual foi tomada, e o console tem uma página com as execuções, as atribuições e as restrições que não puderam ser satisfeitas.

Administradores, papéis e uma revogação que revoga. Até agora o acesso de gestão era uma senha compartilhada e uma chave estática: não dava para acrescentar um segundo administrador, limitá-lo, nem cortar o acesso de uma pessoa sem trocar o segredo de todo mundo. Agora existe um registro de verdade de contas de administrador com papéis. E desativar uma conta interrompe o trabalho imediatamente — antes, só o login era revogado, enquanto um token já emitido continuava criando fluxos e editando nós por até quinze minutos.

Dá para ver mais do que acontece. O gráfico de erros do fluxo se abriu em linhas por tipo de erro, e falhas de nível de conexão — uma sessão SRT caindo, uma requisição HTTP recusada por uma fonte HLS — passaram a ser contadas pela primeira vez, então uma queda completa da fonte finalmente aparece no gráfico e não só no log. Ao Retroview chegam agora a telemetria de qualidade das fontes, as estatísticas do servidor, o inventário e a carga das GPUs e os contadores do transcodificador. Quando um nó se recusa a aplicar a configuração que você salvou, o motivo chega ao console em vez de ficar no log local da máquina. E em instalações com dezenas de discos, o espaço ocupado é dividido em arquivo vigente, gravações órfãs e o restante, de modo que «para onde foi o espaço» tem resposta.

Veja o que fizemos para a Catena

DRM e, portanto, transmissão paga. É a maior lacuna que mantinha operadores no Flussonic Media Server. A Catena sabia descriptografar uma entrada protegida, mas não proteger o que entregava, então não substituía o Flussonic em nenhum canal pago. Agora substitui. Os fluxos são criptografados com CMAF cbcs, e uma única cópia criptografada serve HLS/fMP4 para FairPlay e DASH para Widevine e PlayReady: não é preciso empacotar duas vezes. As chaves vêm do seu próprio servidor de chaves por SPEKE v1 ou v2, ou da configuração, para testes.

O desenho de cluster importa aqui tanto quanto a criptografia. A criptografia acontece na saída do nó que capturou a fonte, e não na gravação: o arquivo fica em claro, então rebobinamento, miniaturas, transcodificação e analítica continuam funcionando. As bordas recebem apenas texto cifrado — a chave e as credenciais do servidor de chaves nunca saem do nó de captura nem aparecem na configuração de uma borda. E ao importar uma configuração do Flussonic v3, um fluxo com seção drm chega desativado, para que uma migração em massa não comece a transmitir em aberto, silenciosamente, um canal premium.

Uma vitrine com guia de programação de verdade. O aplicativo de espectador da Catena — aquele que seus assinantes abrem na TV ou no navegador — migrou para o novo núcleo junto com o backend de que precisa. O assinante entra com o próprio token, recebe a lista de canais a que tem direito com endereços prontos para reproduzir, e junto com a lista vem um bilhete de reprodução: assim funcionam o limite de dispositivos simultâneos e a revogação, sem que a vitrine saiba nada de chaves internas.

Atrás dela há um guia de programação que antes não existia em forma alguma. O central agora é dono das fontes XMLTV, baixa-as conforme uma agenda, guarda a grade e a entrega tanto à vitrine quanto à saída MPEG-TS na forma de EIT. Duas notas práticas: a importação filtra os programas para os canais que você realmente vinculou — o arquivo real de um provedor com que testamos tinha um milhão e meio de programas em 4054 canais, dos quais ninguém jamais leria 95% — e o arquivo baixado é preservado, então vincular um canal novo reimporta na hora.

Se você já tem um middleware. Muitos dos nossos clientes vendem o seu, e a Catena não concorre com eles. Nesse arranjo, a Catena é aquilo para onde o seu middleware aponta: um único endereço de reprodução, com o balanceamento redundante dentro do cluster, de modo que não há à frente um balanceador de hardware separado para comprar, montar em rack e manter vivo. A vitrine acima é para operadores que ainda não têm middleware e preferem não começar construindo um.

Canais com defasagem de horário. «Canal +2» como canal de pleno direito. O rebobinamento já existia, mas rebobinamento é um parâmetro na URL do player: a versão defasada não tinha nome próprio, nem linha na lista de canais, nem sessões ou estatísticas, e não podia ser enviada, protegida ou atribuída a uma zona de CDN. Agora um canal defasado é um fluxo comum com uma fonte incomum, então herda de graça suas URLs de espectador, suas sessões, seu DRM e seus envios. Uma captura e um arquivo profundo cobrem seus fusos horários, em vez de receber um sinal regional por fuso.

As duas últimas lacunas de formato. A Catena captura fontes DASH — é a outra metade do mesmo chamado, rodando sobre o mesmo leitor de fMP4 descrito acima. Entre HLS e DASH ficam cobertas as origens CMAF, os gateways DVB-I e os empacotadores em nuvem que publicam apenas um dos dois. O DASH difere em uma coisa, e ela é honesta: um manifesto não enumera o que existe, e sim dá um horário de início e um modelo, então qual segmento já está disponível é calculado a partir do relógio de parede em vez de lido de uma lista. E na saída, o HLS é servido também em contêiner MPEG-TS, no seu próprio endereço, para players e decodificadores antigos que não aceitam outra coisa. Juntos, eliminam as duas últimas respostas do tipo «o Flussonic fazia e a Catena não», na entrada e na saída.

O VOD deixou de ser trabalho manual. Um catálogo VOD de cluster sabia aceitar um arquivo e reproduzi-lo, mas tudo o que transforma um arquivo enviado em serviço — a escada de qualidades para MBR, o descritor SMIL, o destino do original — era feito à mão em cada nó. Agora um modelo de transcodificação fica associado ao ativo, a tarefa nasce quando o envio é confirmado, o central escolhe o nó que a executa, e o resultado volta ao catálogo como um arquivo comum. Modelos, tarefas e seu progresso ficam no console, e não no curl. E o MBR montado a partir de arquivos vizinhos, mais legendas externas recolhidas ao lado do vídeo, fazem com que um cliente em migração não precise reempacotar sua biblioteca.

As bordas viraram bordas de verdade. Um nó de borda antes só entregava arquivo: ao vivo e rebobinamento eram mantidos longe dele, porque um fluxo numa borda puxaria da origem para sempre, houvesse ou não alguém assistindo. Ambas as razões acabaram. Os fluxos numa borda sobem sob demanda quando um espectador chega e caem por ociosidade, e os nós trocam o ao vivo pelo nosso próprio protocolo interno, sem degradar para RTMP ou SRT com uma remultiplexação a mais. Assim toda a carga de espectadores, ao vivo incluído, sai do nó de captura para as bordas.

O que você ganha ao migrar do Flussonic Media Server para a Catena

A Catena é construída como cluster desde o começo: você adiciona um fluxo em vez de escolher uma máquina para ele, o arquivo e o catálogo VOD são de todo o cluster, e a instalação inteira é vista de um só lugar. Esse argumento fizemos na 26.08 e ele não mudou. O que mudou na 26.09 é que a lista de coisas que o Flussonic fazia e a Catena não ficou praticamente vazia:

Veja o que fizemos para o Mcaster

As entradas de radiodifusão, todas elas. O Mcaster é a cabeceira: o sinal chega de um receptor de satélite, de uma rede vizinha, de um parceiro ou da sua própria exibição. Esta versão fecha as entradas que só o Flussonic em Erlang tinha.

O SDI de placas DekTec roda como um processo separado por porta de placa, falando com o streamer por memória compartilhada: uma falha de driver derruba uma captura, e não o servidor de mídia inteiro — o que, dado o histórico de quedas do DTAPI, não é preocupação teórica. Ele desincorpora áudio multicanal, extrai VANC e calcula por conta própria marcas de tempo alinhadas. O console agora mostra quais placas estão realmente na máquina, quantas portas cada uma tem, em que variante de firmware estão e quais fluxos já as tomaram. Não é enfeite: numa DTA-2178 cada canal é designado por firmware como entrada ou saída, e uma porta que no momento é saída responde a uma tentativa de captura com «ocupada», depois do que o engenheiro sai procurando um processo alheio que não existe.

SMPTE ST 2110 é recebido por inteiro: vídeo 2110-20, áudio 2110-30 e dados auxiliares 2110-40, mais um nó NMOS que publica os receptores por IS-04 e IS-05 para que um controlador de terceiros possa comutá-los. A recepção roda numa thread de sistema dedicada lendo pacotes em lotes: HD entrelaçado a 10 bits são 130 MB/s e cerca de 90 mil pacotes por segundo numa única faixa, e isso não é trabalho para um escalonador de tarefas de propósito geral. O MXL, a camada de troca por memória compartilhada da EBU, também é lido, para instalações em que as funções vizinhas da cadeia entregam o sinal assim.

RIST chega como implementação própria: recepção e envio, unicast e multicast, com retransmissão e os contadores necessários para provar que o enlace se comporta. O valor é mais comercial que técnico: o RIST é o único protocolo de entrega confiável publicado por um órgão do setor, e não por um fabricante, então aparece nos editais como linha de requisito — e até agora não podíamos responder a um edital desses de forma alguma.

Um transporte que dá para entregar por contrato. O MPEG-TS de saída era antes «é isso ou nada»: número de programa fixo em 1, PIDs atribuídos automaticamente e nenhuma SDT. Agora dá para definir o mapa de PIDs, o número do programa e o nome do serviço por destino. O caso imediato foi um cliente que recebe um canal nosso e de um provedor reserva, cujo comutador de redundância exige que os PIDs dos dois fluxos coincidam. Mas esse mesmo controle é o que pedem um multiplex, um IRD, o monitoramento de um NOC ou a especificação técnica de um contrato de contribuição.

Acesso condicional. Embaralhamento Simulcrypt na saída SPTS: sem cartão não há imagem, com cartão há. Isso só era configurável editando um documento à mão, onde um campo hexadecimal errado significa «o cartão ignora os EMM em silêncio» e custa dias de bancada. Agora tem um formulário decente.

Clientes, e o que cada um comprou. É o que os operadores de Mcaster pediram de forma mais direta. Você não vende um fluxo, vende um serviço: este canal, entregue assim, para esta empresa. Configuração e monitoramento só conheciam fluxos, então quando um cliente ligava não havia para onde olhar: o que ele comprou, que parte está fora e de quem é essa parada.

Agora a venda fica registrada onde a entrega vive. Um envio unicast ou uma porta SRT de reprodução carregam o identificador do cliente a que pertencem, e um token estático por fluxo permite dar ao comprador um link uma vez só e atribuir a ele o consumo. Envios multicast, deliberadamente, não carregam dono: os receptores do grupo são vários, a comutação é de rede e um único campo não descreve isso com honestidade. Em cima disso vai a estatística de entrega por destino: estado com motivo de falha nomeado, taxa, bytes, reconexões, retransmissões. De quebra, algo pior foi corrigido: um envio que falhava às vezes se declarava em execução, com erro vazio e contador de reconexões subindo, então o console garantia ao operador que a entrega estava viva enquanto não saía um byte.

Quem mudou o quê. O central guarda o estado desejado da instalação — configuração de fluxos e nós, zonas de CDN, contas de administrador, ciclo de vida dos nós — e até agora não registrava quem o alterava. Com mais de um operador de plantão, isso deixa um incidente sem apuração: perguntas como «quem apagou este fluxo» e «quando e por quem este nó foi revogado» não tinham resposta alguma. Agora têm: ator, ação, momento.

Um pacote próprio, e um cluster que continua sendo um produto. Já existe um pacote mcaster-streamer. Antes dele, o único pacote de nó era o da Catena, e o console do Mcaster mostrava um comando de ingresso com os caminhos da Catena — de modo que o operador que o seguia instalava um nó do produto errado, sem que nada reclamasse no caminho. Um cluster com máquinas de dois produtos não é exótico: é uma pane silenciosa da qual se descobre bem depois. Agora o ingresso de um nó de outro produto é recusado com um motivo claro.

O que você ganha ao migrar do Flussonic Media Server para o Mcaster

Uma cabeceira é julgada pelo que consegue receber e pelo que consegue provar sobre o que entregou. É exatamente aí que a 26.09 aterrissa:

Veja o que fizemos para a Agora

A Agora é televisão corporativa: seus próprios canais internos, sinais de estúdio preparados para transmissão, reuniões gerais e webinars entregues aos funcionários pela rede corporativa. Na 26.09 ela ganha rosto próprio sobre a plataforma comum — seu console, seu conjunto de seções, sua identidade de produto —, enquanto os recursos de domínio migram para o novo núcleo nas versões seguintes.

Duas peças do trabalho de núcleo caem em cheio no caso de uso dela.

Entrega de baixa latência que escala. O trabalho de WebRTC descrito acima é exatamente o que a transmissão corporativa precisa: uma reunião geral são alguns milhares de pessoas assistindo à mesma coisa ao mesmo tempo, com latência abaixo de um segundo, dentro de uma rede. Passar de 200–300 sessões simultâneas por nó para 18 000 muda o custo, em hardware, de uma transmissão para toda a empresa — de um rack para uma máquina.

Publicação por SRT. Um estúdio, uma sala de reunião ou um notebook com OBS podem agora publicar no cluster por SRT, com recepção no nó que discaram, com criptografia e recuperação de perdas na entrada. É a forma comum de um evento interno chegar à plataforma.

Veja o que fizemos para o Watcher

O gravador migra para o novo núcleo, e não é preciso um engenheiro. Na 26.08 a camada de mídia ganhou nome próprio, o pacote watcher-streamer, atrás do qual o motor podia ser substituído. Esta versão faz a substituição, e a faz pelo único canal que um gravador em campo realmente tem: o botão de atualização na nuvem.

Até agora, trocar o servidor de mídia de um gravador significava um engenheiro por SSH rodando um script de migração que lia o arranjo dos discos, gerava uma configuração e refazia a pilha de contêineres na mão. Isso nunca chega à caixa de um cliente. Agora o novo servidor de mídia viaja como tudo o mais: aperta-se atualizar, o gravador puxa a pilha nova, e uma falha em qualquer passo reverte automaticamente para a anterior. Os valores próprios de cada caixa que tornavam isso difícil — chave de cluster, credenciais de administração, nome do streamer, arranjo de discos — passam a ser montados na própria caixa, em vez de assados num arquivo servido a toda a frota por um endereço público.

O que você ganha em troca é densidade. O novo núcleo é o que grava vinte gigabits por segundo por servidor, e conforme a migração avançar esperamos uma redução de várias vezes nos recursos para a mesma instalação: menos máquinas para as mesmas câmeras, menos espaço em rack, conta de energia menor.

A captura de câmeras ficou muito mais confiável, e descobrimos isso por acaso. Perseguindo perdas de gravação num gravador de dez mil fluxos, notamos que alguns produziam fragmentos dez vezes menores que os demais, fomos olhar a câmera e a câmera estava boa. O problema estava em como montávamos pacotes RTP fragmentados em quadros no caminho RTSP.

As medições são contundentes. Com a mesma câmera e a mesma bancada, a compilação de julho produzia 438 453 quadros quebrados em 4 600 555 — 9,55%. Depois da correção: 6 erros em 272 591 quadros, 0,002%. No gravador receptor, com 10 000 fluxos por uma hora, a perda mediana de arquivo caiu de 15 236 para 2 fragmentos por segundo, e o número de fluxos que perdiam alguma coisa caiu de 2815 para 2.

Se você tem câmeras por RTSP — ou seja, se você tem câmeras —, esta é a linha mais valiosa da versão.

A gravação parou de jogar dados fora com memória sobrando. Um fragmento fechado vivia num único lugar, e a janela de entrega despejava fragmentos por contagem. Se o escritor de disco atrasasse alguns poucos, o dado se perdia para sempre. Num gravador de nove mil câmeras eram 898 501 fragmentos perdidos em dez minutos, com 42 GB dos 125 da máquina sem uso. Agora entrega e durabilidade têm orçamentos separados, a fila de escrita guarda suas próprias referências e é limitada em bytes, e um fragmento só pode se perder quando a memória realmente acaba. No caminho, alinhar as gravações a limites de bloco de 4 KB reduziu sozinho as perdas de 5524 para 8.

O gravador é dono de suas câmeras. A configuração sincronizava em duas direções assimétricas, e ambas machucavam usuários reais: uma câmera criada no gravador não aparecia na nuvem até alguém achar o botão «sincronizar», e uma leitura de fundo vinda da nuvem a cada sessenta segundos sobrescrevia em silêncio as edições locais. A arquitetura agora está dita com clareza: o gravador é a única fonte da verdade sobre a configuração de suas câmeras, e a nuvem é um espelho não destrutivo. Com o enlace de pé, dá para editar da nuvem; sem enlace, não — em vez de fazer edições que depois somem em silêncio.

A API v2 está desligada. Dissemos na 26.08 que estaria, e está: os endpoints da v2 respondem com um aviso. Como sabemos que alguns sistemas de faturamento ainda estão nela, ficou uma chave de configuração para religá-la durante a transição. Encare isso como um prazo, não como um perdão.

Tudo o que a v2 oferecia já está na v3. O que aprendemos com quem tentou migrar é que o problema não é um endpoint faltando, e sim uma sequência: criar um usuário, uma organização e uma pasta é uma cadeia de chamadas em que cada identificador vem da resposta anterior, e um passo pulado dá ou um 403 ou um assinante com direitos de administrador. Por isso estamos escrevendo esse guia de «como passar para a v3» para integrações de faturamento. Se você tem uma integração própria na v2, escreva para nós e revisamos suas chamadas junto com você.

O novo player, e o resto. O player ganhou calendário, troca de qualidade, seleção na linha do tempo com exportação do intervalo escolhido, suporte a mosaicos e um painel de depuração separado do próprio player; nos gravadores ele já é o padrão. Ao lado disso: a lista completa de organizações de um usuário é mostrada inteira e não cortada, a caixa de informações do arquivo traz números reais, na página de mosaicos foram corrigidos a paginação e o botão de exclusão, uma previsão de uso de disco que o central na verdade não consegue calcular foi removida em vez de deixada induzindo ao erro, e um agendador que parava em silêncio de executar toda a rotina periódica após um reinício do Redis agora percebe e se restaura sozinho.

Villapass. O produto de controle de acesso para condomínios construído sobre o Watcher amadureceu nesta versão. Os moradores passam a ser agrupados por lote em vez de existirem soltos, então uma restrição — este lote não pode emitir passes de visitante — fica onde deve ficar. O morador entra com o número de telefone e um código por SMS, e não com um e-mail e uma senha que ninguém lhe deu. O sistema da cancela responde de volta: qual carro passou, quando, em que sentido e com qual passe — o que torna possível um registro de passagens, e agora existe uma tela que o mostra, com busca por placa e por passe. O síndico pode alternar entre os próprios passes e os de todo o condomínio, em vez de ver sempre os de todo mundo. E o painel do operador finalmente mostra como vai cada condomínio — moradores, lotes, passes emitidos na semana e há quanto tempo foi a última troca com a cancela — em vez de uma lista pelada de nomes.

Flussonic Media Server

Nada de novo, e isso é deliberado. Como dissemos na 26.08, a fase de desenvolvimento ativo do Flussonic Media Server terminou: o produto continua suportado e publicamos atualizações mínimas de segurança, mas todo o desenvolvimento vai para os produtos sobre o novo núcleo.

Esta versão é um bom momento para começar a planejar a mudança, porque os motivos para esperar praticamente acabaram. Se você faz televisão e OTT, isso é a Catena — que desde a 26.09 tem DRM, guia de programação, um middleware próprio se você quiser, canais defasados, captura de fMP4 por HLS e DASH, saída MPEG-TS para decodificadores antigos e uma ferramenta que lê o seu arquivo atual no lugar. Se você tem uma cabeceira, isso é o Mcaster: SDI, ST 2110, MXL, RIST, controle completo de PSI/SI e acesso condicional. Se você faz videomonitoramento, isso é o Watcher, cujos gravadores começaram a migrar para o novo núcleo nesta mesma versão.

Uma migração é mais que uma ferramenta, então participamos dela nós mesmos: conte-nos como é a sua instalação e decidiremos juntos o que se move primeiro e como o ar é verificado pelo caminho.