Versão 26.08

Flussonic 26.08: o Catena migra sozinho do Flussonic v3 e o Watcher deixa de calar sobre o arquivo que sumiu

Por que o Catena não é «Flussonic com cluster»

O Flussonic Media Server foi escrito como software para um servidor. Tudo nele gira em torno da máquina: a configuração fica ali, o stream pertence a ela, o arquivo é gravado nos discos dela. Os recursos de cluster vieram depois e continuaram limitados — no fundo são um conjunto de acordos entre servidores separados, cada um dos quais continua vivendo a própria vida. Uma instalação assim cresce mal: cada máquina nova é mais uma configuração para lembrar e mais um servidor no qual entrar para saber o que está acontecendo.

O Catena é construído sobre o Sapsan — o novo núcleo de streaming da Flussonic escrito em Rust — e foi projetado cluster first. Aqui a unidade de gestão é o cluster, não o servidor, e isso aparece em cada função:

A segunda coisa que distingue o Catena é a introspecção do estado num nível que nossos produtos nunca tiveram. Não «entre em cada servidor e olhe os logs», mas uma única interface que responde pela instalação inteira: um painel de controle com gráficos de espectadores e tráfego e um mapa de calor de erros; as sessões uma a uma — quem exatamente está assistindo agora e quem assistiu ontem; o histórico de decisões do layouter com os motivos; o diagnóstico da fonte e o diagnóstico do streamer.

Um exemplo revelador é o monitoramento ao vivo das fontes de backup. Pergunte-se: como você descobre hoje que a entrada de backup de um canal está de fato morta? A resposta habitual é que não descobre — enquanto a fonte principal está no ar ninguém toca no backup, e a integridade dele é questão de fé até o exato momento em que ele é necessário. O Catena testa o backup enquanto ele espera: o cartão da entrada mostra «Pronto» — testado e capaz de assumir a carga — ou «Não testado», e isso se vê na aba de fontes na hora, e não durante a falha. Ali mesmo se vê mais do que «tem quadros ou não»: erros de continuidade MPEG-TS, queda de bitrate, áudio sumido, qualidade da linha do tempo.

E o plano de controle nunca fica no caminho da mídia: a queda do central é uma falha de gestão, não do ar — os streams continuam transmitindo.

E nós ajudamos na mudança. O assistente de importação pega a configuração de um Flussonic Media Server em funcionamento, mostra um plano antes de aplicar e um relatório depois. Mas a ferramenta é só uma parte: conte-nos como é a sua instalação e planejaremos a migração juntos — o que vai primeiro, como se verifica o ar e em que momento os espectadores mudam de lado.

Foi isto que fizemos para o Catena

A saída do Flussonic v3 com assistente, e não na mão. Um cliente com um Flussonic Media Server em funcionamento não tinha nem procedimento de migração nem ferramenta: transferir a configuração significava redigitar centenas de streams, com o risco de perder em silêncio um ajuste cuja perda se descobre já no ar. Agora o console do Catena tem um assistente de importação: ele lê a configuração de origem pela API e a transforma em streams, seções de modelo e backends de autorização no novo formato. Primeiro aparece um plano — o que exatamente vai migrar e o que se perde — e só depois a aplicação; após a importação você recebe um relatório por categorias com o motivo de cada campo não migrado e a contagem dos streams que realmente subiram. A importação foi verificada com a configuração de um roteador em produção. Todo o procedimento, incluindo a mudança dos espectadores e a volta atrás, está em Migração do Flussonic Media Server.

Uma instalação depois da qual o produto funciona. Antes, entre apt install catena e um serviço funcionando havia um muro de trabalho manual: o pacote não criava a role nem o banco PostgreSQL, não escrevia a string de conexão, não criava a conta de operador e nem sequer iniciava o serviço numa instalação limpa. Agora o pacote faz tudo isso — o início rápido leva uma máquina limpa até um stream tocando, e a instalação em produção detalha o que é entregue, onde ficam os segredos, como ligar um PostgreSQL externo e quais portas abrem. O nó do cluster é instalado com o pacote catena-streamer, que pergunta o endereço do central durante a instalação; se o endereço for digitado sem esquema, você vê um erro claro em vez de um nó que silenciosamente não sobe — veja adicionar um streamer. E a caixa passou a se chamar pelo próprio nome: systemctl status catena. Para quem implanta em docker há imagens de produto construídas em camadas: uma atualização não baixa a distribuição inteira de novo.

HTTPS sem distribuir certificados na mão. O produto ganhou um cliente ACME embutido: o streamer pede e renova o próprio certificado Let's Encrypt, inclusive o do próprio central. Não é mais preciso distribuir certificados manualmente por 10–100 nós, e o central não guarda chaves privadas alheias. De quebra, a porta e o TLS do nó local agora são editados pelo console, e não editando YAML na máquina. Os pré-requisitos de emissão, a verificação TLS-ALPN-01 e os motivos pelos quais um certificado não sai estão em Certificado HTTPS.

Modelos de stream. «No terceiro stream eu já estava cansado de ficar clicando pelos ajustes» — é uma citação literal do ticket. O Catena traz de volta a noção de padrão reutilizável: transcodificador, arquivo, miniaturas e timeouts das fontes são configurados uma vez num modelo, e os canais iguais são criados a partir dele. A regra de resolução é simples e sem surpresas: a seção própria do stream vence a do modelo por inteiro.

Autorização de reprodução: como no Flussonic, só que mais rápida. Backends escritos para o Flussonic funcionam com o Catena sem uma única alteração — a mesma requisição, os mesmos cabeçalhos, veja como ligar. Não é preciso reescrever a sua vitrine para migrar. E para quem se importa com a velocidade de início existe um segundo esquema: a vitrine cria a sessão antes da reprodução e entrega ao espectador um bilhete que o streamer valida localmente, sem chamar ninguém. O seu backend deixa de estar no caminho crítico: nem a velocidade de troca de canal nem a confiabilidade do início dependem mais dele. O alcance do bilhete é expresso por uma etiqueta de conteúdo, então um bilhete «para 300 canais» não carrega uma lista de 300 nomes nem é reemitido quando a composição do pacote muda. Uma visão geral das duas formas está em Proteção da reprodução.

Recepção de MPTS: seleção de programa e uma captura por multiplex. Antes o MPEG-TS por UDP era lido apenas como SPTS: o número do programa era descartado e os quadros de todos os programas do multiplex se misturavam numa papa só — tela preta no HLS. Agora a fonte tem o campo «Programa (PNR)», e vários streams podem capturar o mesmo multicast: o tronco chega ao servidor uma vez, e não uma vez por canal. Num multiplex típico isso economiza centenas de megabits de tráfego de entrada. Como se conecta uma fonte multicast tem página própria. Além disso, foi implementada a análise do fluxo elementar MPEG-2: sem ela, os troncos de radiodifusão e de satélite simplesmente não eram aceitos.

MoQ: entrega pelo protocolo para o qual a indústria está migrando. Media over QUIC é o que o consórcio em torno do IETF coloca no lugar da divisão «HLS para escala, WebRTC para latência». A ideia é ter as duas coisas de uma vez: latência abaixo de um segundo e, ao mesmo tempo, entrega comum e cacheável pela rede, em vez de um caminho peer-to-peer separado para cada espectador. O Catena entrega ao vivo por MOQT (draft-19, CMAF/CMSF): o streamer levanta um listener QUIC, o navegador chega por WebTransport e reproduz — sem plugins e sem gateways. Por dentro, o fluxo é cortado não em fragmentos inteiros, mas nas mesmas partes do LL-HLS, então a baixa latência vem do desenho e não do ajuste de buffers. Esta é uma primeira implementação e por enquanto só entrega: recepção por MoQ e distribuição relay pelo cluster são os próximos passos. Mas dá para experimentar no seu canal hoje: ativa-se com um listener na configuração do streamer.

Push RTP e entrega do arquivo por RTSP. O push de MPEG-TS agora fala RTP, e não só UDP puro: os receptores de hardware comuns aceitam justamente isso, e redes com perdas também pedem isso. Separadamente, surgiu a entrega do arquivo por RTSP com Range: clock=: a única forma padronizada pela qual sistemas municipais de videovigilância de terceiros leem um arquivo alheio. Até agora essa integração era impossível por princípio.

Legendas de radiodifusão como uma faixa comum. As legendas ocultas CEA-608/708 que viajam dentro da imagem agora viram uma faixa WebVTT que todos os players OTT entendem. O assinante vê no seu aplicativo as mesmas legendas que o espectador do mesmo canal pelo cabo — e os requisitos de acessibilidade (CVAA nos EUA, European Accessibility Act na Europa) são cumpridos sem uma segunda entrada e sem trabalho manual. O multilinguismo sai de graça: a emissora costuma colocar dois ou três serviços de idioma num canal, e cada um vira um item do menu de legendas. Em detalhe: Legendas ocultas de um canal de radiodifusão.

No ar as legendas chegam de várias maneiras, e nós as reduzimos a uma forma única. Os closed captions CEA-608/708 dentro dos quadros de vídeo funcionam hoje. As legendas DVB chegam como imagens, então o texto precisa ser reconhecido — o DVB OCR sai na próxima versão. O sentido de todo esse trabalho é que na saída a forma é uma só: venham de onde vierem as legendas, o espectador recebe uma faixa WebVTT comum, e você não precisa nem de uma segunda entrada nem de uma esteira separada para cada formato de radiodifusão.

O transcodificador: mais denso e sem emendas. Com MBR, um quadro de entrada era decodificado tantas vezes quantas fossem as qualidades de saída: num conjunto FHD/HD/SD o worker rodava a 0,7–0,8× do tempo real, a borda ao vivo atrasava e os players faziam buffer. Agora a entrada é decodificada uma vez e o quadro decodificado é distribuído a todos os codificadores. Surgiu a codificação na placa de vídeo: com NVIDIA toda a cadeia de vídeo — decodificação, escala e codificação — vai para a placa, e a placa é escolhida explicitamente ou automaticamente, a menos carregada. E a reconfiguração deixou de ser destrutiva: o transcodificador não se reconstrói mais por ruído como o bitrate medido, e quando é realmente preciso reconfigurar — por exemplo, a fonte mudou de resolução ao vivo — isso acontece sem quadros perdidos, sem IDR forçado e sem quebra de DTS. A escada de qualidades, as regras de áudio e os presets estão em Transcodificação e MBR.

Menos artefatos para o espectador. O DASH ao vivo desmoronava segundos depois de ligar o transcodificador: as faixas de um mesmo stream eram cortadas em grades que não combinavam, o erro de arredondamento se acumulava e a borda do ar oscilava dentro de um segundo — agora as grades estão alinhadas. No LL-HLS as descontinuidades são numeradas uma vez e não são renumeradas depois, então o hls.js não morre mais com discontinuity sequence mismatch; a faixa de miniaturas parou de gerar descontinuidades falsas que deixavam o player com o buffer vazio. Um fluxo cujo codificador inseria IDRs não previstos não se desfaz mais em segmentos de 32–64 ms. Uma troca de descrição de programa na PAT não derruba mais um quadro montado pela metade — antes isso dava um segmento aparentemente saudável com um buraco no GOP, a reprodução travada no Chromium e um buraco no arquivo para sempre. E os congelamentos de áudio de vários segundos após cada troca de entrada também sumiram.

Dá para ver o que acontece. O painel de controle responde à pergunta «está tudo bem?» com blocos, gráficos de espectadores e tráfego e um mapa de calor de erros. As sessões aparecem uma a uma: não «tantos espectadores», mas quem exatamente assiste a este stream agora e quem assistiu há pouco — o histórico não se perde mais. O diagnóstico da fonte mostra mais do que «tem quadros ou não»: erros de continuidade MPEG-TS, quedas de bitrate, áudio sumido; o backup agora volta para a fonte prioritária apenas após uma janela limpa, e não no primeiro quadro. Se um disco de DVR está desmontado ou há um erro de digitação no caminho, isso se vê na interface, e não numa linha WARN de log. E se um streamer não aplicou os ajustes salvos, o motivo chega ao console — veja Diagnóstico do streamer.

Trinta mil espectadores a partir de um único nó. É, provavelmente, o número desta versão. Em protocolos de baixa latência — HTTP MPEG-TS, RTSP — o Flussonic esbarrava em cerca de mil a dois mil clientes simultâneos por servidor: dali em diante começavam as quedas. O Catena 26.08 sustenta 30 000 espectadores simultâneos num nó pelos mesmos protocolos.

A causa estava na contabilidade das sessões. Todas as sessões do nó viviam numa tabela sob um cadeado comum, e por ele passavam os dois caminhos quentes ao mesmo tempo: as sessões de socket — que são justamente os protocolos de baixa latência — reportam os bytes transferidos uma vez por segundo cada, enquanto os espectadores HTTP procuram o próprio registro a cada requisição de segmento. Com trinta mil sessões isso dava mais de vinte e seis mil tomadas do cadeado por segundo. E o cadeado estava fazendo trabalho útil cerca de 13% do tempo: o sistema não parava por falta de força, mas por fila atrás de si mesmo — a espera chegava a um segundo em média e a quase doze segundos no pico.

Quem pagava pela fila não era o monitoramento, era o espectador. Enquanto uma sessão espera o cadeado, ela não esvazia o anel de quadros, e um anel num stream ao vivo dura segundos: o assinante preso na fila caía por completo. Na recepção isso aparecia como cortes de 700 ms, e uma fonte que devia puxar quinze gigabits puxava três. Agora as sessões mudaram para um armazenamento colunar com partições separadas, a contabilidade de bytes foi coberta por testes antes da alteração, e a fila sumiu junto com o teto de mil e quinhentos clientes.

As conquistas não são só na entrega, mas também na gravação. A outra metade do mesmo trabalho é a gravação sustentada de 20 gigabits por segundo por servidor. Traduzido em câmeras, são 10 000 câmeras de resolução média numa única máquina gravando continuamente — não um valor de pico para demonstração, mas o regime em que o servidor vive. Para um operador isso muda a aritmética do projeto: onde antes o arquivo somava um rack, agora bastam algumas máquinas, e o estado dos discos e o que ocupa o espaço se vê no cluster inteiro de uma vez.

O arquivo no cluster. Um stream numa borda agora tem cache de arquivo — uma chave separada que não exige gravação: o origin escreve o arquivo, e as bordas mais próximas dos espectadores guardam o que realmente é assistido, de modo que as leituras quase param de chegar aos discos do origin. Quanto o cache ocupou e qual é a taxa de acerto está na seção DVR do cluster, que também responde «para onde foi o espaço?» numa instalação com dezenas de discos. Os espectadores são distribuídos por geografia pelas zonas CDN.

O VOD passou a ser de cluster. Antes o VOD de arquivos vivia no nível de um único nó: para entregar um ativo era preciso saber em qual máquina e em qual diretório ele estava. Agora o central mantém o catálogo VOD de todo o cluster, e os arquivos podem ser enviados direto do navegador, sem escolher nó nem disco: o ativo vai para o armazenamento com mais espaço livre, e os bytes seguem direto para o streamer, sem passar pelo plano de controle. Portais que fazem os próprios uploads recebem tokens de envio. E as duas coisas pelas quais os clientes que migravam reempacotavam o conteúdo agora funcionam como estão: o MBR é montado a partir de arquivos vizinhos, e as legendas externas são pegas do arquivo ao lado — movie.mp4 e movie.srt tocam sem conversão.

O Watcher está migrando para a tecnologia do Catena

O principal sobre o Watcher nesta versão não é uma função, e sim uma direção. O Watcher começou a migrar para o mesmo núcleo sobre o qual o Catena é construído: a camada de mídia deixa de ser Flussonic Media Server e passa a ser Sapsan. No 26.08 foi dado o primeiro passo visível — a camada de mídia ganhou nome próprio: o pacote e a imagem docker watcher-streamer, atrás dos quais o motor pode ser trocado sem mexer em comandos de instalação, documentação e nos seus playbooks.

Para que isso serve a você. O Sapsan é escrito em Rust e foi pensado para densidades de outra ordem: uma gravação sustentada de 20 gigabits por segundo por servidor são 10 000 câmeras de resolução média numa máquina. À medida que a migração avança, esperamos uma redução de recursos de várias vezes para a mesma instalação: menos máquinas para o mesmo número de câmeras, menos rack, menos conta de energia e manutenção. Além de tudo o que foi descrito acima na seção do Catena — a introspecção do estado e o modelo de cluster que a camada de mídia atual não tem.

A migração será gradual e sem surpresas para instalações em funcionamento. Mas se você quiser um produto de outro patamar antes, convidamos você para o programa de adoção antecipada: olharemos juntos a sua instalação, planejaremos a migração e a conduziremos com a nossa participação.

Foi isto que fizemos para o Watcher

O gravador não cala mais quando o arquivo não está sendo escrito. É o cenário mais desagradável de todos: no aplicativo as câmeras estão verdes, há vídeo ao vivo, e o arquivo há dias não é escrito — o disco, o DVR ou a gravação pararam. O cliente descobre no momento em que o arquivo faz falta: depois de um roubo, de uma discussão ou de um «quem passou por aqui». A diferença para «o gravador está offline» é fundamental: o offline pelo menos se vê, enquanto «online, mas sem gravar» é uma falsa sensação de segurança. Agora o Watcher acompanha isso e avisa.

Avisos de falha do gravador — e da recuperação. Antes o usuário descobria que o gravador havia quebrado só ao entrar na lista de gravadores. Agora os administradores da organização recebem um push com o motivo — a rede entre a nuvem e o gravador está indisponível, o gravador parou de responder pela API — e, quando ele volta, chega uma notificação de recuperação. A mecânica de entrega de push no backend foi unificada para todos os tipos de notificação: a entrega é repetida em caso de falha e as assinaturas expiradas não entopem mais a fila.

Dá para ver para onde vai o arquivo e quão íntegro ele está. De cada câmera do gravador agora se vê quanto espaço o arquivo dela ocupa: dá para ajustar a retenção em vez de comprar discos. E, principalmente, se vê o estado do arquivo: «guardamos 30 dias» e «nesses 30 dias o arquivo somou 25 com buracos» são coisas diferentes, e agora a diferença não se esconde. Surgiu a indicação de integridade do arquivo, e a profundidade é contada por stream separadamente.

A camada de mídia do Watcher ganhou nome próprio. Surgiram o pacote watcher-streamer e a imagem docker flussonic/watcher-streamer. Isso fecha duas coisas. Primeira: nos nós de mídia do cluster, instalados com apt install flussonic, a interface de administração do media server ficava exposta — agora está fechada tanto na entrega por pacote quanto na de docker. Segunda: para um sistema de videovigilância o motor é um detalhe de implementação, e não há por que pronunciá-lo em voz alta nos comandos de instalação e nos playbooks. Agora a camada de mídia tem um nome permanente, atrás do qual o motor pode mudar.

A primeira instalação parou de falhar, e a atualização ficou verificável. A instalação all-in-one falhava logo no primeiro apt install e exigia rodar a instalação uma segunda vez — reproduzido de forma consistente em Ubuntu 22.04 e 24.04 limpos. A causa foi encontrada e corrigida. Separadamente, cuidamos das migrações do banco: a cadeia havia crescido para 193 revisões, uma primeira instalação gastava mais de quarenta segundos nelas e — o pior — uma atualização com dados reais a partir de versões antigas não era verificada por absolutamente nada. Agora a instalação limpa vem de um snapshot do esquema, e as próprias migrações estão cobertas por testes.

Os recursos não vazam mais, e as listas não se arrastam. O método que devolve a lista de streams deixava transações não fechadas no PostgreSQL: as conexões ficavam presas em idle in transaction, a memória vazava, a carga de CPU subia e o serviço caía — corrigido. Separadamente, cuidamos da velocidade da interface em instalações grandes: um cliente com mais de 1100 câmeras não conseguia percorrer a lista para conferir o estado das câmeras pelas miniaturas — a página parava de responder. Foram acelerados a lista de câmeras, a abertura de pastas, a rolagem e a busca por pastas.

Permissões e contas. Aos usuários de organização se podia conceder menos permissões do que aos usuários comuns; agora os dois lugares funcionam igual. Dá para deixar uma nota num usuário de organização, e a troca de proprietário de uma organização e a listagem de organizações conforme as permissões sobre câmeras foram corrigidas.

O novo player com painel de depuração. O novo player ganhou um painel de depuração com gráficos e uma linha do tempo de eventos. Quando chega a queixa «está travando», não é mais preciso acreditar na palavra: dá para ver o que de fato aconteceu com a reprodução.

26.08 é a última versão com suporte à API v2. É, provavelmente, o ponto mais importante para quem tem integrações próprias: na versão seguinte a v2 é desligada. O aviso agora é mostrado direto na interface — envios por e-mail não funcionam para isso, e para nós importa saber que o administrador o viu.

A boa notícia é que há para onde migrar agora mesmo: tudo o que existia na v2 já está na API v3 — não há o que esperar nem endpoints faltantes para negociar. Se você tem uma integração própria, um faturamento ou um aplicativo móvel sobre a v2, escreva para nós: olharemos as suas chamadas e ajudaremos a movê-las para a v3 antes de o suporte terminar.

Flussonic Media Server

Esta versão traz ao Media Server uma única alteração, mas útil para quem tem muitas câmeras: debounce dos disparos repetidos do detector de movimento. Uma câmera mal configurada — com sensibilidade alta demais ou uma zona sobre galhos que balançam — consegue emitir uma torrente de eventos «movimento iniciado» sem parar, e numa instalação grande essas câmeras juntas enterravam o servidor de gestão sob milhares de eventos e o travavam em CPU. Agora os disparos repetidos são agrupados, e dá para resolver a configuração de cada câmera com calma, e não no modo apagar incêndio.

E algo que vale dizer com clareza: a fase de desenvolvimento ativo do Flussonic Media Server terminou. O produto continua em suporte e seguiremos publicando atualizações mínimas de segurança, mas não haverá novos recursos nele — todo o desenvolvimento vai para os produtos sobre o núcleo novo.

Por isso convidamos você a planejar a mudança. Se você faz videovigilância, o caminho é o Watcher, que nesta mesma versão começou a migrar para esse núcleo; se você faz televisão e OTT, o caminho é o Catena, que já tem um assistente de importação de configuração com plano antes e relatório depois. Uma migração é mais do que uma ferramenta, então participamos dela nós mesmos: conte-nos como é a sua instalação e decidiremos juntos o que migra primeiro e como o ar é verificado pelo caminho.