Entenda metadados de vídeo, analytics, tracking, classificação, ONVIF Profile M, busca forense, interoperabilidade, desempenho, testes e critérios de projeto.
Confira!
Metadados de análise de vídeo são dados estruturados gerados por câmeras, dispositivos de borda, servidores ou plataformas de analytics para descrever objetos, eventos, atributos e condições detectadas nas imagens. Em vez de depender apenas do vídeo bruto, o sistema passa a manter informações pesquisáveis sobre o que ocorreu, onde ocorreu, quando ocorreu e quais características foram reconhecidas.
Esses metadados podem representar pessoas, veículos, placas, direção de movimento, permanência, contagem, localização, cor, classe de objeto, eventos de regra e outros atributos. O objetivo não é substituir o vídeo. Os metadados acrescentam uma camada semântica que torna o acervo mais pesquisável, automatizável e integrável.
Em sistemas de videomonitoramento modernos, metadados são essenciais para busca forense, alarmes, business intelligence, integração com VMS, PSIM, controle de acesso e plataformas IoT. O ONVIF Profile M foi criado exatamente para padronizar a comunicação de metadados e eventos de analytics entre dispositivos, serviços e clientes, incluindo VMS e aplicações em nuvem.
O que são metadados em vídeo
Metadados são “dados sobre dados”.
No contexto de videomonitoramento, o vídeo é a mídia principal; os metadados descrevem elementos extraídos ou associados a ela.
Exemplo:
- câmera: CAM-023;
- timestamp: 14:32:10;
- objeto: pessoa;
- posição: coordenadas da cena;
- direção: norte;
- evento: cruzamento de linha;
- confiança: valor calculado pelo analytics.
Essas informações podem ser consultadas sem percorrer manualmente toda a gravação.
Metadados descritivos
Descrevem atributos do conteúdo.
Exemplos:
- pessoa;
- veículo;
- cor;
- tipo;
- localização;
- velocidade;
- direção.
Metadados operacionais
Descrevem estado do sistema.
Exemplos:
- câmera offline;
- perda de vídeo;
- mudança de cena;
- tampering;
- falha de analytics.
Metadados de eventos
Representam ocorrência de uma regra ou condição.
Exemplos:
- intrusão;
- linha cruzada;
- objeto abandonado;
- contagem;
- permanência;
- placa reconhecida.
Analytics em edge e servidor
Os metadados podem ser gerados na própria câmera ou em servidor.
Analytics na câmera
A câmera processa a imagem localmente.
Vantagens:
- reduz necessidade de enviar streams adicionais;
- distribui processamento;
- pode gerar eventos com baixa latência;
- mantém parte da função mesmo se o servidor estiver distante.
Limitações dependem de capacidade do dispositivo.
Analytics no servidor
O vídeo é enviado para uma plataforma central.
Vantagens:
- maior capacidade computacional;
- modelos mais sofisticados;
- atualização centralizada;
- análise de múltiplas câmeras.
A desvantagem é maior dependência de rede e servidores.
Analytics em cloud
Serviços cloud podem processar vídeo ou metadados enviados.
Isso permite escala e integração.
Porém, latência, banda, privacidade e custo precisam ser considerados.
Detecção x classificação x reconhecimento
Esses termos não são equivalentes.
Detecção identifica que existe um objeto ou evento.
Classificação atribui uma classe, como pessoa ou veículo.
Reconhecimento busca identificar uma entidade específica ou atributo mais detalhado.
Um sistema pode detectar uma pessoa sem saber quem ela é.
Essa distinção precisa aparecer nos requisitos.
Bounding boxes e localização
Analytics frequentemente representam objetos por bounding boxes.
A caixa delimita a região da imagem.
Ela pode ser associada a:
- classe;
- confiança;
- ID;
- posição;
- trajetória.
O VMS pode desenhar essas caixas sobre a imagem.
Metadados permitem recriar a sobreposição sem gravar o vídeo já “marcado”.
Tracking
Tracking acompanha um objeto ao longo de quadros.
O sistema atribui um identificador temporário.
Isso permite medir direção, permanência e trajetória.
Tracking dentro de uma câmera é diferente de reidentificação entre câmeras.
A transição entre dispositivos exige mais contexto e pode ser tecnicamente complexa.
Confidence score
Modelos podem atribuir uma confiança à classificação.
Esse valor não deve ser interpretado como probabilidade absoluta sem conhecer o modelo.
Um threshold mais alto pode reduzir falsos positivos e aumentar falsos negativos.
A configuração precisa refletir o risco operacional.
Metadados e eventos
Nem todo metadado precisa virar alarme.
Um sistema pode gerar milhares de objetos por hora.
Regras filtram condições relevantes.
Exemplo:
- detectar pessoa;
- verificar entrada em zona;
- verificar horário;
- gerar evento apenas se regra for satisfeita.
Isso reduz alarmes desnecessários.
ONVIF Profile M
O ONVIF Profile M padroniza interfaces para metadata e analytics.
Entre os recursos descritos pelo ONVIF estão:
- consulta de configuração de analytics;
- streaming de metadata;
- classificação genérica de objetos;
- geolocalização;
- dados de veículos;
- placa;
- face;
- corpo humano;
- eventos;
- integração com MQTT.
O Profile M pode trabalhar com outros profiles ONVIF para vídeo e controle de acesso.
Interoperabilidade
O valor do Profile M é reduzir dependência de uma única combinação câmera/VMS.
Entretanto, conformidade com profile não significa que todos os analytics de todos os fabricantes serão idênticos.
Os recursos efetivamente implementados precisam ser verificados.
Metadata stream
Metadados podem ser transportados em stream associado ao vídeo.
O VMS recebe objetos e eventos estruturados.
Isso permite armazenar e pesquisar.
O fluxo precisa permanecer sincronizado com o vídeo.
ONVIF e VMS
O VMS pode consumir metadata da câmera.
Também pode gerar metadata com analytics próprios.
A arquitetura deve decidir qual camada é a fonte de verdade.
Se câmera e servidor classificam o mesmo objeto, pode haver duplicidade.
O projeto precisa definir prioridades.
Busca forense
Uma das principais aplicações é reduzir tempo de investigação.
Em vez de assistir horas de vídeo, o operador pode pesquisar:
- pessoa;
- veículo;
- cor;
- direção;
- horário;
- área;
- placa;
- evento.
O resultado retorna trechos candidatos.
A qualidade da busca depende da metadata gerada.
Pesquisa por atributos
Atributos podem variar entre fabricantes.
Uma câmera pode classificar veículo em carro, caminhão e moto.
Outra pode usar categorias diferentes.
Interoperabilidade exige normalização.
O VMS pode mapear essas classes.
Smart search
Smart search permite aplicar uma região ou condição a gravações.
Alguns sistemas geram metadata continuamente.
Outros executam análise posterior.
O custo computacional e a velocidade de resultado diferem.
O requisito deve definir expectativa.
Contagem de pessoas
Analytics podem contar entradas e saídas.
Metadados registram eventos de passagem.
Aplicações incluem:
- ocupação;
- filas;
- fluxo;
- capacidade.
A precisão depende de posição da câmera e cenário.
Uma câmera mal posicionada não será corrigida pelo software.
Contagem de veículos
A lógica é semelhante.
Pode apoiar:
- estacionamento;
- vias;
- portarias;
- logística.
Sombras, oclusões e congestionamento podem afetar desempenho.
O teste deve reproduzir condições reais.
LPR/ANPR
Leitura automática de placas gera metadata estruturada.
Pode conter:
- placa;
- país;
- confiança;
- imagem;
- veículo;
- timestamp.
Integração com controle de acesso pode acionar regras.
A governança deve considerar dados pessoais.
Reconhecimento facial
Reconhecimento facial busca associar uma face a uma identidade ou lista.
Isso é diferente de detecção de face.
A aplicação envolve riscos de privacidade e requisitos regulatórios.
Também deve considerar qualidade de imagem, viés e falso match.
Classificação de pessoas
Analytics podem detectar atributos.
O uso deve ser proporcional à finalidade.
Nem todo atributo tecnicamente extraível é necessário.
Minimização reduz risco de privacidade.
Linha virtual
Uma regra pode gerar evento quando objeto cruza uma linha.
Metadata registra:
- objeto;
- direção;
- tempo;
- posição.
Esse recurso é comum em perímetro e contagem.
A configuração deve evitar áreas com movimento irrelevante.
Zona de intrusão
Uma região da cena pode ser monitorada.
O analytics identifica entrada ou permanência.
O desempenho depende de perspectiva.
Vegetação e sombras podem gerar falsos eventos.
O projeto precisa considerar cenário.
Loitering
Loitering identifica permanência superior a um tempo.
A definição do tempo é requisito operacional.
Um valor curto gera excesso de eventos.
Um valor longo pode atrasar resposta.
Objeto abandonado
Esse analytics tenta identificar objeto deixado em uma área.
É mais complexo que simples detecção.
Cenários com oclusão e fluxo intenso podem reduzir desempenho.
A validação precisa ser específica.
Metadados e IA
Modelos de visão computacional geram metadata.
Redes neurais modernas melhoraram classificação.
Porém, desempenho não é universal.
O mesmo modelo reage de forma diferente a:
- iluminação;
- chuva;
- ângulo;
- resolução;
- densidade;
- cenário.
A IEC 62676-6:2026 introduz requisitos para testes e classificação de performance de sistemas inteligentes de análise de vídeo em tempo real.
Falsos positivos
Um falso positivo ocorre quando o sistema gera detecção incorreta.
Excesso de falsos positivos cria fadiga operacional.
O operador pode ignorar alarmes.
Por isso, a precisão precisa ser medida no contexto.
Falsos negativos
Falso negativo é uma ocorrência real não detectada.
Em segurança, pode ser mais crítico.
Reduzir falso positivo aumentando threshold pode elevar falso negativo.
O ajuste precisa refletir consequência.
Precision e recall
Métricas de machine learning ajudam a avaliar desempenho.
Precision indica proporção de detecções positivas que estavam corretas.
Recall indica proporção dos eventos reais detectados.
Uma métrica isolada pode esconder trade-offs.
O teste precisa definir dataset e cenário.
Ground truth
Avaliar analytics exige conhecer a verdade de referência.
Ground truth pode ser criado por observação ou anotação.
Depois se compara resultado do sistema.
Sem ground truth, dizer “acertou 95%” pode ser indefinido.
É necessário saber 95% de quê.
Cenário de teste
O desempenho deve ser testado no local.
Variáveis:
- iluminação;
- distância;
- movimento;
- densidade;
- clima;
- oclusão;
- ângulo.
Um benchmark de laboratório não garante resultado em campo.
Metadata x vídeo gravado
Metadados ocupam menos espaço que vídeo.
Isso permite retenção longa.
Porém, metadata depende do vídeo para evidência visual.
O sistema precisa manter associação entre ambos.
Se o vídeo foi sobrescrito, a metadata pode continuar existindo sem imagem.
O projeto deve definir retenção.
Sincronização de tempo
Timestamp é crítico.
Câmera, VMS e analytics precisam estar sincronizados.
NTP é normalmente usado.
Diferenças de segundos podem prejudicar correlação com controle de acesso.
Em investigações, precisão temporal importa.
Identificadores de objeto
Tracking atribui IDs.
Esses IDs podem ser temporários.
Não devem ser tratados como identidade permanente.
Ao perder o objeto e encontrá-lo novamente, o sistema pode gerar outro ID.
Essa característica deve ser compreendida em integrações.
Geolocalização
Profile M prevê metadata de geolocalização.
Em câmeras com posição conhecida, objetos podem ser mapeados.
Isso pode apoiar mapas e aplicações urbanas.
A precisão depende de calibração.
Metadata em PTZ
Câmeras PTZ mudam campo de visão.
Analytics precisam considerar posição.
Presets podem ter regras diferentes.
Em movimentos manuais, algumas análises podem ser suspensas.
O projeto deve testar.
Metadata e VMS federado
Grandes organizações podem ter múltiplos VMS.
Metadata precisa ser compartilhada ou consultada.
Arquiteturas federadas podem centralizar busca.
Interoperabilidade se torna importante.
Metadata e PSIM
PSIM correlaciona eventos de diferentes sistemas.
Metadata de vídeo pode enriquecer alarmes.
Exemplo:
- controle de acesso gera porta forçada;
- VMS recebe evento;
- analytics detecta pessoa;
- PSIM apresenta contexto.
O artigo Integração VMS, PSIM, SCADA e BMS em Centros de Operações aprofunda essa arquitetura.
Metadata e controle de acesso
Eventos de placa, face ou pessoa podem interagir com controle de acesso.
A automação precisa definir autoridade.
Analytics não deve abrir uma porta crítica sem critérios adequados.
Em segurança física, decisões automáticas precisam considerar risco.
Metadata e IoT
ONVIF Profile M prevê integração de eventos com MQTT.
Isso permite que analytics de vídeo alimentem plataformas IoT.
Exemplo:
- câmera detecta ocupação;
- evento é publicado;
- BMS ajusta climatização.
Esse uso amplia o vídeo além da segurança.
Metadata e business intelligence
Contagem e fluxo podem apoiar negócio.
Aplicações:
- varejo;
- transporte;
- prédios;
- filas;
- ocupação;
- logística.
O uso precisa ser compatível com finalidade e privacidade.
Metadata e cidades inteligentes
Câmeras urbanas podem gerar informações de tráfego e ocupação.
A escala exige cuidado com processamento e storage.
Também aumenta impacto de governança.
O Videomonitoramento Urbano complementa o tema.
Metadata e edge computing
Gerar metadata na borda reduz necessidade de transmitir múltiplos streams.
A câmera pode enviar vídeo apenas quando necessário e metadata continuamente.
Isso economiza banda.
Porém, o edge precisa ser gerenciado.
Firmware e modelo precisam ser versionados.
Analytics no servidor
Servidor central permite maior capacidade.
Pode processar câmeras de diversos fabricantes.
Também facilita atualização de modelo.
O custo é concentração de recursos.
GPU e storage precisam ser dimensionados.
Analytics em gravação
Busca retrospectiva pode processar vídeo já gravado.
Isso é útil quando a regra não existia no momento do evento.
A velocidade depende de capacidade.
Um requisito pode especificar tempo máximo de pesquisa.
Armazenamento de metadata
Metadata pode ser mantida em banco.
Índices aceleram busca.
A retenção pode ser maior que vídeo.
O projeto deve considerar crescimento.
Milhões de objetos por dia geram volume relevante.
Modelagem de dados
Para interoperabilidade, é necessário definir:
- tipos;
- classes;
- unidades;
- timestamps;
- IDs;
- origem;
- confiança;
- evento.
Sem padronização, cada integração cria tradução própria.
APIs
VMS e plataformas podem expor metadata por API.
Isso permite integração com:
- BI;
- SIEM;
- PSIM;
- ERP;
- BMS;
- aplicações próprias.
API precisa ter autenticação e versionamento.
Mudanças podem quebrar integrações.
Segurança dos metadados
Metadata pode ser sensível.
Uma placa ou face pode identificar pessoa.
Acesso deve ser controlado.
Logs precisam registrar pesquisa e exportação.
Metadata não deve ser tratada como “menos sensível” apenas porque não é vídeo.
Privacidade
Projetos precisam definir finalidade.
A coleta deve ser proporcional.
Retenção também.
Em ambientes públicos ou corporativos, políticas devem ser claras.
A anonimização pode ser utilizada em alguns casos.
Cibersegurança
Câmeras e analytics são sistemas computacionais.
Boas práticas incluem:
- segmentação;
- firmware;
- autenticação;
- certificados;
- logging;
- acesso mínimo;
- atualização.
O artigo Cibersegurança em Sistemas de Vídeo Monitoramento aprofunda essa dimensão.
Qualidade da imagem
Analytics depende de imagem adequada.
Fatores:
- resolução;
- foco;
- bitrate;
- iluminação;
- shutter;
- WDR;
- posição;
- lente.
A câmera deve ser projetada para a função de analytics.
Não basta aumentar megapixels.
Compressão
Compressão reduz banda.
Porém, artefatos podem afetar analytics.
Bitrate excessivamente baixo destrói detalhe.
O projeto deve equilibrar storage e qualidade.
FPS
Alguns eventos exigem maior taxa de quadros.
Objetos rápidos podem aparecer em poucos frames.
Analytics de pessoas em ambiente lento toleram menos FPS.
A configuração precisa refletir o caso.
Perspectiva
Câmera alta pode ser boa para tracking.
Câmera frontal pode ser melhor para face.
Não existe posição ideal universal.
O mesmo ponto pode exigir duas câmeras para objetivos diferentes.
Oclusão
Objetos escondidos por outros reduzem detecção.
Multidões e veículos próximos são exemplos.
A posição deve minimizar oclusões.
Analytics não “vê através” de objetos.
Iluminação
Baixa luz aumenta ruído.
Contraluz reduz detalhe.
IR muda aparência.
Modelos precisam ser validados em cada condição.
Testes devem incluir noite quando aplicável.
Ambiente
Chuva, neve, poeira e vegetação afetam analytics.
Reflexos e sombras também.
Ambientes externos são mais variáveis.
A meta de desempenho deve ser realista.
Projeto orientado ao caso de uso
O primeiro passo não é escolher analytics.
É definir o problema.
Exemplo:
- detectar invasão perimetral;
- localizar veículo;
- contar pessoas;
- investigar ocorrência.
Cada caso exige arquitetura diferente.
Requisitos mensuráveis
Um requisito pode definir:
- classe;
- área;
- velocidade;
- iluminação;
- distância;
- precisão;
- recall;
- taxa de falso alarme;
- tempo de resposta.
Quanto mais crítico, mais rigoroso o teste.
Projeto de CFTV
Analytics só entrega desempenho quando a imagem foi projetada para o caso de uso. Posição, lente, iluminação, resolução e VMS precisam ser definidos junto com os requisitos de metadata.
A câmera precisa ser dimensionada para analytics.
O Projeto de CFTV IP e Videomonitoramento pode estabelecer cobertura, imagem, VMS, storage e integração.
Isso cria base para seleção de analytics.
Design Review
Interoperabilidade, posição de câmera, analytics, metadata, storage e integração precisam ser revisados como uma única arquitetura antes da implantação.
A solução proposta deve ser revisada.
Itens:
- posição;
- lente;
- analytics;
- VMS;
- metadata;
- interoperabilidade;
- rede;
- storage;
- segurança.
O Design Review em Projetos de Engenharia verifica aderência antes da implantação.
Piloto
Analytics deve ser validado em campo.
Um piloto pode medir:
- falsos positivos;
- falsos negativos;
- iluminação;
- cenário;
- integração;
- carga.
O piloto precisa ter critérios.
“Funcionou na demonstração” não é suficiente.
Comissionamento
O aceite de analytics deve usar cenários conhecidos, ground truth e evidência reproduzível. Uma demonstração comercial não substitui comissionamento no ambiente real.
O comissionamento deve testar metadata e evento.
Uma sequência:
- criar cenário conhecido;
- executar evento;
- confirmar detecção;
- verificar metadata;
- verificar VMS;
- confirmar gravação;
- confirmar pesquisa;
- registrar evidência.
O Comissionamento de Equipamentos pode estruturar o processo.
IEC 62676-6:2026
A IEC 62676-6:2026 trata teste de desempenho e classificação de sistemas inteligentes de análise de vídeo em tempo real.
Ela considera capacidades como classificação de objetos e detecção de atividades e cenários.
A existência da norma reforça a mudança de mercado: analytics deve ser testado por desempenho.
Não basta listar recursos em datasheet.
Critérios de aceite
Critérios precisam refletir o risco.
Para contagem:
- erro máximo;
- período;
- fluxo;
- cenário.
Para perímetro:
- taxa de detecção;
- falso alarme;
- distância;
- iluminação.
Para LPR:
- leitura correta;
- velocidade;
- ângulo;
- dia/noite.
O aceite precisa ser reproduzível.
Operação
Depois da implantação, analytics precisa ser acompanhado.
Cenário muda.
Vegetação cresce.
Layout muda.
Iluminação é substituída.
Isso pode degradar performance.
Recalibração
Regras e modelos podem precisar de ajuste.
A mudança deve ser controlada.
Um threshold que reduz alarmes pode aumentar eventos perdidos.
A baseline deve ser preservada.
Monitoramento
Indicadores:
- eventos por câmera;
- falso alarme;
- disponibilidade;
- latência;
- carga;
- falha de metadata;
- câmeras sem analytics;
- versão de modelo.
Esses dados permitem detectar degradação.
Gestão de versões
Firmware e analytics evoluem.
Atualização pode alterar classificação.
O contratante precisa registrar versão.
Em aplicações críticas, uma atualização deve ser testada antes da expansão.
As-Built
Documentação precisa registrar:
- câmera;
- posição;
- analytics;
- regra;
- zona;
- threshold;
- versão;
- VMS;
- metadata;
- integração.
Sem isso, futuras mudanças perdem referência.
Integração e procurement
Ao contratar analytics, é necessário especificar interoperabilidade.
Perguntas:
- metadata é aberta?
- existe ONVIF Profile M?
- API está documentada?
- evento pode ser exportado?
- VMS suporta?
- dados pertencem ao cliente?
- existe custo por canal?
Isso evita lock-in.
Lock-in
Metadata proprietária pode ficar presa ao VMS.
Na migração, o vídeo pode ser exportado, mas pesquisa e objetos podem ser perdidos.
A estratégia de saída deve ser considerada.
Padrões ajudam.
APIs também.
TCO
Analytics gera custos de:
- licença;
- GPU;
- storage;
- suporte;
- atualização;
- operação;
- integração.
Edge pode deslocar custo para câmeras.
Servidor pode centralizar.
A comparação deve considerar ciclo de vida.
Erros recorrentes
| Erro | Consequência |
| escolher analytics antes do caso de uso | recurso sem valor |
| câmera mal posicionada | baixa performance |
| confiar em demo | expectativa irreal |
| ausência de ground truth | teste inválido |
| metadata proprietária | lock-in |
| sem sincronização | eventos descorrelacionados |
| threshold sem governança | comportamento imprevisível |
| não testar noite | falha operacional |
Arquitetura de retenção e indexação de metadados
A retenção de metadados precisa ser projetada separadamente da retenção de vídeo. Como os registros estruturados ocupam menos espaço, é possível manter históricos mais longos para busca e análise, mas isso aumenta o volume de índices e o custo de banco de dados ao longo do tempo.
O sistema deve definir quais atributos serão indexados, por quanto tempo e com qual granularidade. Indexar tudo pode aumentar custo e complexidade; indexar pouco reduz capacidade de pesquisa. A decisão deve partir dos casos de uso prioritários.
Também é importante garantir a associação entre metadata e evidência visual. Se o vídeo correspondente já foi sobrescrito, o registro pode continuar útil para estatística, mas deixa de permitir confirmação visual do evento. O projeto deve documentar essa diferença.
Escala e desempenho de busca forense
Em sistemas com centenas ou milhares de câmeras, uma busca pode consultar bilhões de objetos ao longo do histórico. O requisito de desempenho deve indicar quanto tempo o operador pode esperar por uma pesquisa e quais filtros são necessários para reduzir o universo.
A arquitetura pode distribuir índices, criar partições por tempo ou câmera e utilizar mecanismos especializados de pesquisa. Essas escolhas são invisíveis para o operador, mas determinam se o recurso continuará utilizável quando o sistema crescer.
Durante testes de aceite, é útil executar buscas sobre volume representativo, e não apenas sobre algumas horas de gravação. Um sistema rápido em laboratório pode degradar quando o banco acumula meses de metadata.
Normalização entre fabricantes e taxonomias diferentes
Fabricantes podem utilizar classes, nomes e atributos diferentes para representar objetos semelhantes. Um sistema pode classificar “truck”, outro “heavy vehicle”, outro apenas “vehicle”. Sem normalização, a pesquisa federada produz resultados inconsistentes.
O VMS ou middleware pode mapear essas taxonomias para um modelo comum. Esse trabalho deve preservar informação original quando ela for relevante e registrar claramente quais atributos foram convertidos ou descartados.
Profile M reduz parte do problema ao padronizar interfaces e estruturas, mas não elimina diferenças de capacidade analítica entre produtos. A interoperabilidade deve ser tratada como requisito testável, não presumida pelo uso de um profile.
Governança de modelos e analytics baseados em IA
Quando analytics utiliza modelos de IA atualizáveis, a versão do modelo passa a fazer parte da configuração do sistema. Uma atualização pode melhorar um cenário e piorar outro. Por isso, mudanças relevantes devem ser controladas, testadas e documentadas.
Em aplicações críticas, uma nova versão pode ser validada em grupo piloto antes da expansão. Os indicadores anteriores e posteriores permitem verificar se houve mudança em falso positivo, recall, latência ou consumo de recursos.
Esse controle evita que o comportamento operacional mude silenciosamente após atualização automática. A equipe precisa saber qual versão estava ativa quando determinado evento ocorreu.
Rastreabilidade entre requisito, regra e evidência
Cada analytics relevante deve ser associado ao requisito que justificou sua existência. A documentação pode relacionar caso de uso, câmera, regra, área de interesse, threshold, condição ambiental, versão de software e teste de aceite.
Essa rastreabilidade facilita manutenção. Se uma câmera é reposicionada, é possível identificar quais regras precisam ser recalibradas. Se um modelo é atualizado, a equipe sabe quais testes devem ser repetidos.
No comissionamento e em auditorias posteriores, a mesma matriz ajuda a demonstrar que o comportamento observado corresponde ao requisito e que mudanças foram formalmente avaliadas.
Validação estatística e tamanho da amostra
Testar analytics com poucos eventos pode produzir uma impressão enganosa. Uma taxa de acerto calculada sobre dez passagens tem pouca capacidade de representar condições variadas. O plano de teste deve definir quantidade de eventos suficiente para o risco e a variabilidade do cenário.
Também é importante distribuir a amostra por condições relevantes: dia, noite, chuva, diferentes direções, velocidades e densidades. Um resultado agregado pode esconder desempenho ruim em uma condição específica.
Quando o analytics suporta diferentes classes, cada classe crítica precisa de avaliação própria. Um sistema pode classificar carros muito bem e apresentar desempenho inferior para motocicletas ou pessoas parcialmente ocluídas.
Metadata como ativo de informação
À medida que a organização usa metadata para investigação, indicadores e automação, esses dados deixam de ser simples subproduto do vídeo e passam a constituir ativo de informação. Isso exige ownership, retenção, qualidade, segurança e regras de acesso.
O catálogo de dados deve indicar origem, significado dos campos, unidade, versão e finalidade. Sem esse contexto, integrações futuras podem interpretar atributos de forma incorreta ou comparar dados produzidos por modelos diferentes como se fossem equivalentes.
A governança também deve registrar mudanças de taxonomia ou modelo. Se uma classe é renomeada ou dividida em duas, dashboards históricos precisam saber como tratar a série antes e depois da alteração.
Como critério de encerramento, a solução deve preservar a relação entre câmera, analytics, versão, regra, metadata produzida e evidência de teste. Essa rastreabilidade é o que permite comparar desempenho ao longo do tempo, investigar mudanças e manter a interoperabilidade do sistema após atualizações.
Em sistemas críticos, a metadata deve ser tratada como informação de engenharia: versionada, documentada, testada e relacionada ao vídeo e ao analytics que a produziu. Isso preserva capacidade de auditoria e comparação quando câmeras, VMS ou modelos forem atualizados.
Considerações finais
Metadados transformam vídeo em informação estruturada.
Eles permitem busca, automação, integração e analytics em escala.
O valor depende de qualidade de imagem, modelo, interoperabilidade, sincronização, governança e critérios de teste.
ONVIF Profile M fornece uma base importante para interoperabilidade, enquanto a IEC 62676-6:2026 reforça a necessidade de avaliar analytics por desempenho.
Em sistemas profissionais, metadata deve ser tratada como parte da arquitetura de dados do videomonitoramento, com requisitos, segurança, documentação e evidências de aceite.
Referências técnicas
[1] ONVIF. Profile M — Metadata and Events for Analytics Applications. Disponível em: https://www.onvif.org/profiles/profile-m/.
[2] ONVIF. Network Interface Specifications. Disponível em: https://www.onvif.org/profiles/specifications/.
[3] IEC. IEC 62676-6:2026 — Performance testing and grading of real-time intelligent video content analysis devices and systems. Disponível em: https://webstore.iec.ch/en/publication/59704.
Perguntas frequentes
São dados estruturados que descrevem objetos, atributos, eventos e condições extraídos ou associados ao vídeo.
Não. Eles facilitam busca e automação, mas o vídeo continua sendo a evidência visual principal.
É o profile ONVIF voltado a metadata e eventos de analytics, permitindo interoperabilidade entre dispositivos, serviços e clientes.
Detecção identifica a presença de objeto ou evento; reconhecimento tenta determinar identidade ou atributo mais específico.
Com cenário representativo, ground truth, métricas adequadas e medição de falsos positivos e falsos negativos.
Sim. Deve ser validado em campo nas condições reais de iluminação, perspectiva, movimento e integração previstas no projeto.