FILTER · DIMENSIONAMENTO PÓS-HACKATHON

Quanto custa acrescentar leitura ao que Patos já tem?

A pergunta não é mais “quanto custa montar uma central?”. Patos já capta, transmite, exibe e armazena vídeo para as finalidades atuais. O que precisamos medir é quanto processamento, integração, validação e governança são necessários para extrair indicadores de mobilidade sem criar outro acervo de imagens.

REGRA DE ARQUITETURA — o vídeo fica na fonte. Por padrão, o FILTER persiste medidas e proveniência, não uma cópia do vídeo.

O ponto de partida real em Patos

O que já existeConsequência para o produto
240 câmeras em 140 pontos, segundo publicação oficial de 2026O primeiro passo é inventariar quais delas servem ao caso de mobilidade; não comprar câmeras.
Central/estrutura de videomonitoramento já opera para segurançaNão propomos outra parede de monitores nem outro streaming para substituir o atual.
Semáforos inteligentes estão em fase experimental em pontos da cidadeHá decisões reais de mobilidade que podem ganhar baseline e antes/depois.
Na conversa com a equipe, o diretor apontou falta de capacidade para tratar a massa de dadosNosso problema é transformar vídeo existente em medida útil e auditável.

Fonte oficial das 240 câmeras / 140 pontos ↗ · Semáforos inteligentes experimentais ↗

1 · Janela que queremos analisar

2 · Capacidade medida do worker

Como ler o resultado

Não precisamos chegar a RTF ≤ 1. Se uma hora de vídeo levar duas horas para processar, isso ainda pode atender perfeitamente um relatório diário, uma medição semanal ou um estudo antes/depois. Tempo real só vira requisito quando uma decisão concreta exigir.

MétricaUso
Horas de vídeo/mêsvolume bruto que já existe na fonte e que escolhemos analisar.
Frames analisadoscarga real do detector; mudar FPS altera custo e pode alterar qualidade.
Horas de processamentoquanto tempo computacional a agenda escolhida exige.
RTFtempo de processamento ÷ duração do vídeo. É a métrica central para dimensionar hardware/SLA.
Cópia permanente de vídeo0 GB por arquitetura padrão. Se houver exceção, ela precisa de justificativa e política própria.

3 · Primeiro inventário técnico

  1. Qual VMS/NVR/DVR armazena cada grupo de câmeras?
  2. Qual é a retenção real por grupo?
  3. Há playback, RTSP, ONVIF, SDK, API ou exportação?
  4. Qual resolução, FPS e codec?
  5. Podemos rodar um worker na mesma rede/central?
  6. Existe CPU/GPU disponível sem afetar a operação?
  7. Como autenticar o worker sem ampliar a superfície da rede de câmeras?
  8. Quem autoriza a análise e quem acessa os resultados?

4 · Câmera com pouca retenção

Ela pode ser uma ótima candidata inicial. A resposta não precisa ser “vamos guardar o vídeo em outro lugar”. Pode ser:

5 · Custos que entram

6 · Custos que não presumimos

Se algum deles se mostrar necessário no inventário, vira uma decisão explícita — não uma premissa escondida.

Modelo econômico que faz sentido agora

FaseO que entregamosO que mede o custo
Diagnóstico técnicoinventário de uma fonte/central + benchmark de uma janela + mapa de barreirashoras técnicas + processamento medido
Piloto de evidênciapoucos pontos, baseline, validação humana e uma pergunta concreta de mobilidadeintegração + RTF/volume + calibração + governança
Operaçãoprocessamento recorrente e relatório/indicadores conforme SLAvolume real + recursos + suporte + licença + análise humana

Preço por câmera pode existir comercialmente depois. Mas primeiro precisamos descobrir quanto aquela câmera realmente custa para integrar, processar e validar. A unidade econômica nasce do ambiente; não o contrário.

Critério de sucesso do próximo teste

“Este vídeo já existia nesta infraestrutura. Sem criar outro armazenamento e sem criar outro streaming, processamos X minutos em Y minutos, usando Z recursos, com erro medido E, e geramos estas medidas auditáveis.”

Quando conseguimos preencher X, Y, Z e E com um ponto real de Patos, temos a primeira base confiável para engenharia e preço.