SAFR from RealNetworks — Reconhecimento Facial para Segurança e Acesso

SAFR from RealNetworks é uma plataforma de reconhecimento facial para vídeo, controle de acesso e aplicações corporativas. A arquitetura atual pode operar com câmeras IP de terceiros, dispositivos SAFR dedicados, processamento on-premises ou em nuvem e integrações com VMS, PACS e aplicações por APIs.

O ponto central da plataforma é separar captura, detecção e tracking do processo de reconhecimento e gestão de identidades. Em vez de tratar reconhecimento facial como uma função isolada da câmera, SAFR organiza vídeo, identidade, eventos, ações e integrações como uma arquitetura distribuída.

Na engenharia da solução, isso exige definir onde o vídeo será processado, onde as identidades serão armazenadas, quais câmeras possuem qualidade suficiente, como eventos serão enviados ao VMS ou ao sistema de acesso e quais políticas de privacidade, retenção e auditoria serão aplicadas.

Condição observada	Risco ou limitação	Resposta de engenharia
Câmeras existentes sem estudo de imagem facial	Faces pequenas, desfocadas ou mal expostas reduzem reconhecimento	Validar resolução útil, distância, ângulo e iluminação
Processamento centralizado sem análise de rede	Vídeo consome banda excessiva entre sites	Distribuir nós de detecção/processing próximos às fontes
Threshold definido apenas por valor padrão	False match e false non-match fora do risco aceitável	Calibrar threshold com população, cenário e procedimento operacional
Watchlists sem governança	Alertas inconsistentes, identidades duplicadas e retenção inadequada	Definir ownership, cadastro, sincronização e exclusão
Integração com acesso sem modo degradado	Falha de servidor ou rede pode bloquear ou liberar acesso incorretamente	Definir arquitetura local, fallback, multi-factor e testes de contingência

Arquitetura da plataforma SAFR

O whitepaper da plataforma descreve uma arquitetura híbrida em que detecção e tracking podem ocorrer próximos à câmera enquanto matching, identidade e gestão de eventos são centralizados em SAFR Server. Essa separação reduz a necessidade de transportar vídeo integral até o ponto de reconhecimento e permite distribuir capacidade conforme a topologia.

O SAFR Server reúne serviços de reconhecimento, identity database, event server, event archive, administração de video feeds e object/image services. Clientes e aplicações usam esses serviços para cadastrar pessoas, consultar identidades, monitorar eventos e executar ações.

A plataforma atual também suporta implantação on-premises, em infraestrutura de nuvem administrada pelo cliente ou em SAFR Cloud. A escolha deve considerar soberania e localização dos dados, conectividade, latência, modelo de suporte, disponibilidade e responsabilidade operacional.

VIRGO e processamento contínuo de vídeo

O Video Recognition Gateway (VIRGO) executa processamento contínuo de feeds. Ele recebe streams de uma ou mais câmeras, detecta e rastreia faces, produz eventos e os envia à camada de eventos da plataforma. Os feeds continuam processando em background mesmo sem o Desktop Client aberto.

VIRGO pode utilizar CPU e GPU e possui mecanismos de monitoramento para condições como feed sem resposta, erro de processamento, baixa memória, pouco disco, baixa capacidade de CPU e pressão sobre GPU. Isso permite tratar o reconhecimento como serviço operacional monitorável, e não apenas como aplicação de desktop.

Em arquiteturas maiores, nós podem ser distribuídos por site ou por grupo de câmeras. O próprio suporte atual da SAFR descreve separação entre detection e recognition e topologias com sincronização de identidades entre servidores, inclusive modelos hub-and-spoke e relays de eventos.

Câmeras, resolução facial e qualidade da captura

A documentação atual da SAFR indica suporte a câmeras IP com RTSP H.264 ou H.265 e recomenda, para reconhecimento facial, imagem suficientemente nítida e bem exposta. Como referência de projeto, o fabricante utiliza cerca de 50 pixels de largura de face para reconhecimento de boa qualidade em sua ferramenta de cálculo.

Isso significa que megapixels, isoladamente, não resolvem o problema. Ângulo horizontal de visão, distância, lente e posição da pessoa determinam quantos pixels efetivamente representam o rosto. Uma câmera 4K muito aberta pode fornecer menos detalhe facial que uma câmera de menor resolução com enquadramento corretamente dimensionado.

Movimento, motion blur, luz de fundo, oclusões, máscaras, bonés e variações de pose também afetam o resultado. O projeto deve tratar o ponto de captura como subsistema biométrico, com requisitos de iluminação e geometria próprios.

Detecção, template e matching

O pipeline começa pela detecção da face e pelo tracking ao longo dos frames. Em seguida, uma representação biométrica é extraída e comparada com templates cadastrados. A decisão de match depende de similaridade e threshold configurado.

Threshold mais permissivo pode aumentar identificação de pessoas conhecidas e simultaneamente elevar false matches; threshold mais restritivo reduz esse risco, mas pode aumentar false non-matches. O valor adequado depende do caso de uso e da consequência de cada erro.

Em vigilância, um alerta pode passar por validação humana. Em controle de acesso, um falso aceite pode acionar uma porta. Por isso, o mesmo threshold não deve ser automaticamente replicado entre segurança investigativa, attendance, watchlists e autenticação física.

Watchlists, identidade e sincronização

Identidades precisam ser organizadas com atributos, imagens de referência, grupos e políticas de acesso. A plataforma suporta sincronização e segmentação de identidades entre servidores, o que permite separar populações por site, zona ou aplicação.

Essa flexibilidade exige governança. Cadastros duplicados, fotografias inadequadas, usuários inativos e regras de watchlist sem responsável degradam a qualidade operacional mesmo quando o algoritmo funciona corretamente.

O ciclo de identidade deve definir cadastro, atualização, expiração, exclusão e sincronização. Em ambientes integrados ao PACS ou RH, é necessário estabelecer qual sistema é a fonte autoritativa e como divergências serão tratadas.

Secure Access e integração com controle de acesso

SAFR pode ser utilizado em acesso físico por software ou por dispositivos como SAFR SCAN. Na arquitetura de integração, credenciais e pessoas podem ser sincronizadas do sistema de controle de acesso para a plataforma SAFR, que distribui os dados para os terminais conforme zonas e regras.

O terminal pode então autenticar o usuário e retornar a decisão ao painel por interfaces como Wiegand ou OSDP, conforme o desenho do sistema. Em aplicações mais críticas, reconhecimento facial pode ser combinado com cartão, PIN ou outra credencial para autenticação multifator.

A arquitetura precisa definir comportamento offline, atualização de credenciais, revogação e logs. Um sistema facial não deve depender de conectividade central se o requisito de acesso exige continuidade local durante indisponibilidade de rede.

Integração com VMS e eventos

SAFR possui integrações com sistemas de vídeo e pode produzir eventos de reconhecimento associados à câmera, horário e identidade. Esses eventos podem ser usados para abrir vídeo correspondente, gerar alarmes, preencher metadata e iniciar investigação.

A integração deve manter sincronismo temporal e correlação entre reconhecimento e gravação. Um evento biométrico que não conduz ao frame e ao trecho de vídeo correspondente reduz a capacidade de auditoria.

Em ambientes com Milestone XProtect e outros VMS suportados, metadata e eventos precisam ser testados após upgrades dos dois lados. Plugin, API, versão do VMS e versão do SAFR devem compor a baseline.

APIs, SDKs e automação

A plataforma disponibiliza REST APIs e SDKs para integração. A documentação atual cita APIs para computer vision, eventos, video feeds e object storage, além de SDKs para Windows, Linux, Android, iOS, macOS e Jetson.

Essas interfaces permitem criar aplicações de cadastro, consulta de pessoas, eventos, watchlists e automações. O SAFR Actions historicamente também permite associar eventos de reconhecimento a ações como relés, notificações e chamadas de serviços externos.

Em produção, APIs precisam de autenticação, TLS, rate limiting, logging e tratamento de retry. Uma automação de segurança baseada em reconhecimento deve prever timeout, indisponibilidade e idempotência para evitar ações duplicadas.

Privacidade, armazenamento e proteção de dados

Reconhecimento facial trabalha com dados biométricos e imagens de pessoas. O desenho precisa definir quais imagens são armazenadas, quais templates permanecem no sistema, por quanto tempo eventos são mantidos e quem pode consultar ou exportar dados.

Em implantação fechada on-premises, a documentação histórica da plataforma destaca a possibilidade de manter face data e imagens dentro da infraestrutura local. Em cloud ou topologias híbridas, os fluxos de dados precisam ser mapeados explicitamente.

Privacidade também influencia a operação. Watchlists, attendance, visitor recognition e analytics de público possuem finalidades diferentes e não devem compartilhar indiscriminadamente cadastros ou retenções.

Capacidade, licenciamento e expansão

SAFR Software para câmeras de terceiros é atualmente licenciado conforme a quantidade de câmeras utilizadas simultaneamente. Isso precisa ser distinguido da quantidade total de câmeras cadastradas, nós de processamento, servidores e usuários.

A expansão deve considerar simultaneamente licenças, GPU/CPU, quantidade de feeds, número de faces por cena, população de templates e armazenamento de eventos. Adicionar câmeras sem ampliar processing nodes pode aumentar latência e reduzir a capacidade de trabalhar em tempo real.

Em ambientes distribuídos, crescimento por site pode ser preferível a concentrar todos os streams em um datacenter. A decisão deve comparar custo de processamento local, largura de banda e necessidade de operação centralizada.

Ciclo de vida, monitoramento e atualização

A plataforma recebe atualizações de software, integrações e dispositivos. O portal atual da SAFR mantém documentação, downloads e suporte para software, SAFR SCAN, câmeras e integrações. Alterações de versão precisam ser avaliadas contra VMS, PACS, APIs e servidores em produção.

VIRGO e outros serviços precisam ser monitorados como componentes de infraestrutura. CPU, GPU, memória, disco, estado do feed e erro de processamento devem possuir alerta e procedimento de resposta.

Antes de upgrade, a baseline deve registrar versão, licenças, feeds, thresholds, watchlists, integrações, APIs e topologia. Depois da mudança, testes de regressão devem cobrir captura, reconhecimento, eventos e ações críticas.

Verificação, comissionamento e critérios de aceite

O comissionamento deve usar pessoas cadastradas e não cadastradas, variações de distância, iluminação, direção de movimento e oclusão. O objetivo não é demonstrar apenas matches corretos, mas observar false match e false non-match no cenário real.

Para acesso, o teste deve abranger autenticação positiva, negativa, usuário revogado, perda de conectividade, multi-factor quando aplicável e registro do evento no PACS. Para vídeo, precisa confirmar correlação com a gravação e o comportamento do VMS.

Também devem ser testados failover ou indisponibilidade de processing node, atraso de rede, perda de feed e recuperação. O aceite precisa registrar threshold, câmera, distância, iluminação, versão e condições observadas.

Documentação e rastreabilidade

O as built deve registrar servidores, processing nodes, VIRGO feeds, câmeras, GPUs, banco de identidades, integrações, endpoints, certificados, regras, thresholds, watchlists, retenção e políticas de acesso aos dados.

Casos de uso e critérios de aceite devem permanecer vinculados às configurações que os sustentam. Mudanças de câmera, threshold, algoritmo ou versão podem exigir novo teste e precisam ser rastreáveis.

Considerações de Engenharia

Precisão algorítmica não substitui qualidade de captura

Mesmo um algoritmo de alta precisão perde desempenho quando o rosto ocupa poucos pixels, está desfocado ou mal exposto. O ponto de captura faz parte do sistema biométrico.

Threshold é uma decisão de risco

O valor adequado depende da consequência de false match e false non-match. Vigilância, attendance e acesso físico não devem herdar automaticamente o mesmo limite.

Distribuir processing nodes reduz tráfego, mas aumenta governança

Topologias distribuídas melhoram escalabilidade e resiliência, porém exigem inventário de versões, recursos, feeds e sincronização entre sites.

Serviços que materializam a solução

O Projeto de CFTV IP e Videomonitoramento define câmera, lente, rede, VMS e gravação. Quando o reconhecimento participa do acesso físico, o Projeto de Segurança Eletrônica Integrada estrutura PACS, biometria, eventos e resposta.

Ensaios e Testes Técnicos e Comissionamento de Equipamentos validam captura, threshold, reconhecimento e integrações. O As-Built de Engenharia consolida a baseline final.