Advanced Vision
Gateway

1.1O pipeline

Para cada câmera, dois processos FFmpeg e um estágio .NET no meio. Ingestão: FFmpeg conecta via RTSP/TCP com -fflags nobuffer -flags low_delay e emite vídeo cru yuv420p no stdout. Producer thread: uma thread dedicada (LongRunning, fora do thread pool) lê os quadros com leitura zero-copy — os bytes vão direto para a memória não gerenciada de um Mat do OpenCV alugado de um pool. Desenho: os boxes são pintados diretamente nos planos YUV. Saída: um segundo FFmpeg recodifica com libx264 -preset ultrafast -tune zerolatency e publica a nova stream RTSP — o VMS aponta para essa URL como se fosse a câmera.

1.2O desafio central: a caixa chega depois do quadro

A analítica leva um tempo Δ para processar um quadro e emitir o alerta — de centenas de milissegundos a alguns segundos, variando com modelo, carga e rede. Pintar o box assim que ele chega é pintá-lo sobre um quadro do futuro: o operador vê um retângulo vermelho pairando sobre asfalto vazio. Pior que não ter overlay — porque destrói a confiança no sistema.

A solução: dois buffers e uma linha do tempo negociável. Uma fila de vídeo e uma fila de metadados, cada entrada carimbada com seu instante de chegada, e três parâmetros ajustáveis. Um quadro só é liberado quando envelheceu o suficiente; se o TTL expira, ele sai limpo — é preferível vídeo sem box do que box errado. Se o buffer se aproxima da capacidade, o atraso é abandonado e os quadros são forçados para fora.

1.3Desenho direto em YUV — a otimização que viabilizou a fase

A abordagem ingênua converte YUV → BGR, desenha, e converte de volta: em quinze câmeras a 12 fps, são 180 pares de conversão por segundo sobre quadros de quase um megapixel. Optamos por desenhar direto no formato nativo: o plano Y é extraído com RowRange (view sem cópia), os planos U e V são reinterpretados com Reshape, as coordenadas são forçadas a fronteiras pares (exigência da subamostragem 4:2:0) e a cor hexadecimal é convertida para Y/U/V uma única vez, na ingestão do alerta. No caminho quente não existe aritmética de cor — apenas três Rectangle com escalares pré-calculados. Resultado: zero conversões de espaço de cor, e o overlay deixa de ser o gargalo.

1.4Gestão de memória e contrapressão

• MatPool. Pool thread-safe de Mat com dimensões fixas. Em regime permanente, nenhum quadro é alocado — os objetos circulam entre producer e consumer, com fallback seguro se o pool estourar.
• Ler-e-descartar sob contrapressão. Com a fila cheia, o producer continua lendo o stdout do FFmpeg e descarta os bytes. Contraintuitivo mas essencial: parar de ler enche o pipe do SO, o FFmpeg bloqueia e o processo trava em cascata. Perde-se quadro, não se perde a câmera.
• Escrita síncrona bloqueante na saída. Um quadro fragmentado corrompe o encoder; a escrita usa ReadOnlySpan<byte> direto da memória do OpenCV para o pipe, sem cópia intermediária.

1.5Resiliência 24/7

• Watchdog por pipeline a cada 2 s; sessão parada é cancelada e reconstruída do zero.
• Backoff exponencial 5 → 60 s, com reset do contador após 10 s de conexão estável.
• Detecção automática de resolução e FPS reais da fonte, persistidos no banco.
• Auto-recuperação do publicador de cópia, sem loops órfãos após remoção da câmera.

1.6Ingestão de alertas

O endpoint REST recebe alertas polimórficos — onze tipos, cada um com seu esquema (TripWire, Entering, Exiting, LeftObject, Congestion, Speed, DeFence, Directional, UnusualBehaviour, Trex, Generic) — resolvidos por um conversor JSON customizado. Coordenadas chegam em percentual e são convertidas com a resolução real detectada, o que torna o sistema imune a divergências de resolução. E o endpoint responde imediatamente: a decisão de relé é enfileirada fora do ciclo de requisição — a IA nunca espera o gateway.

2.1O stack de relé completo

Driver do módulo de relé de rede sobre a API do fabricante — não só o comando de acionar, mas o ciclo completo: consulta de capabilities, descoberta e enumeração de portas, configuração como saída (OpenCollectorOutput, sem a qual o acionamento não tem efeito), nice names gravados no próprio hardware, leitura de estado, acionamento individual e em lote, autenticação Digest.

2.2O motor de regras

Entre “chegou um alerta” e “aciona a porta 3” existe uma esteira determinística, projetada para falhar em segurança: validação da câmera (UUID desconhecido é descartado e auditado), normalização do nome de regra (trim, underscores, maiúsculas, remoção do prefixo AskAurora_ — absorvendo divergências de digitação entre sistemas) e arbitragem explícita de colisão:

Um mapeamento curinga por câmera (uuid_*) cobre regras não catalogadas. E as regras condicionais de IA avaliam respostas em linguagem natural com operadores configuráveis (Contains, Exactly matches, Starts with…) em AND estrito: uma resposta fora do esperado derruba a regra inteira. É onde o cliente calibra a taxa de falso acionamento.

2.3Semântica de acionamento

• Pulse — fecha o contato por N ms e solta sozinho, com desligamento em background.
• Latch — mantém fechado, com desligamento automático opcional.
• Anti-redundância — lê o estado real da porta antes de acionar; porta já ativa é ignorada e auditada, evitando o chaveamento errático de sirenes e cancelas.
• TriggerOnDismiss — aciona justamente quando o alerta é rejeitado, para sinalizar “verificado e liberado” a sistemas externos.

2.4Resiliência de hardware

• Retry com backoff sobre falhas 5xx, exceções de rede e timeouts.
• Circuit breaker — após N falhas consecutivas o circuito abre, poupando rede, threads e log; a recuperação é testada em half-open.
• Isolamento total — falha de relé nunca derruba o pipeline de vídeo. Domínios de falha separados.

2.5Segurança operacional

• Dry-run — todo o caminho de decisão executa, os payloads do relé são montados e auditados, mas nenhum comando chega ao hardware. É como se valida um mapeamento de dezenas de regras num site em produção sem abrir uma cancela por engano.
• Desligamento seguro — ao encerrar, o gateway força todas as portas para OFF. Um serviço que morre com sirene em latch é um incidente; um que morre limpo, não.
• Feedback em tempo real — estado real de cada porta via SignalR, incluindo o desligamento automático ao fim de um pulso. O operador vê o hardware, não uma suposição.

2.6Auditoria: o requisito que virou argumento de venda

Não é log de aplicação — é um registro tipado e polimórfico, com esquema próprio por categoria: PROVISIONING, CAMERA_LIFECYCLE, CAMERA_RUNTIME, ALERT_DECISION e RELAY_ACTION. A pergunta que responde é “o que aconteceu com aquele alerta das 03h14?” — e a resposta é uma cadeia completa: chegou, casou com esta regra, decisão de acionar, porta 3 fechada por 5.000 ms, hardware respondeu 200, reabriu às 03h14:05. Em segurança eletrônica, isso é prova pericial, defesa de SLA, sintonia de falso positivo e conformidade.

3.1A mudança de paradigma

Na fase 1 o gateway reescreve o vídeo; na fase 3 ele não toca no vídeo. O H.264 que sai é bit a bit idêntico ao da câmera; os metadados viajam numa trilha RTSP dedicada em tt:MetadataStream. Isso muda três coisas: qualidade (some a perda de geração), custo (somem decode e encode, ~95% do trabalho) e utilidade — o box deixa de ser pixel e vira informação: o VMS liga e desliga a exibição, busca por classe, indexa, aplica as próprias regras.

3.2O caminho do vídeo

• Cliente RTSP em TCP interleaved, reconexão 5 → 60 s e reset completo de estado a cada reconexão: filas esvaziadas, timeline reancorada, espera por novo IDR.
• Sincronismo de GOP — o proxy espera o primeiro IDR antes de emitir (entregar quadros P sem referência produz o clássico artefato verde) e extrai SPS/PPS varrendo os NALs tipo 7 e 8 para o SDP.
• Parser de NAL — varredura byte a byte por start codes de 3 e 4 bytes. Leitura de estrutura, não decodificação: nenhum coeficiente de transformada é tocado.
• Packetização RTP — NALs maiores que o MTU fragmentados em FU-A, payload de até 1200 bytes, cabeçalhos montados manualmente, flags de início e fim corretas.

3.3O caminho dos metadados

ONVIF define o espaço de bounding box em [-1, +1], origem no centro e eixo Y invertido. O percentual da analítica é convertido:

left   = (x₁ × 2) − 1
right  = (x₂ × 2) − 1
top    = 1 − (y₁ × 2)
bottom = 1 − (y₂ × 2)

O XML tt:MetadataStream é montado por substituição em template externo, não por serializador — deliberadamente: o template fica editável em campo, acomodando excentricidades de VMS específicos sem recompilar, e a substituição de texto é ordens de magnitude mais barata no caminho quente.

3.4O timeline scheduler — a peça do sincronismo

Cada câmera tem sua linha do tempo com âncora dupla: no primeiro quadro registram-se o relógio local e o relógio da câmera. O momento de emissão de cada quadro projeta o ritmo da câmera sobre o relógio local — em vez de assumir que os dois batem, o que nunca acontece:

alvo = base_local
     + (tempo_da_câmera − base_da_câmera)
     + VideoDelayMs

• Cedo demais → espera em passos de até 5 ms, sem busy-wait.
• Atrasado > 1 s → descarta o quadro e recupera o ritmo, em vez de acumular dívida temporal.
• Rede congestionada → segura, para não empurrar dados num socket cheio.
• Delay alterado em runtime → filas esvaziadas, âncora resetada, timeline reconstruída.

3.5O plano de controle

Um VMS moderno não recebe uma stream — ele descobre um dispositivo, autentica, consulta capacidades, escolhe um perfil e assina eventos. O stack de controle inteiro roda sobre CoreWCF:

Do ponto de vista do VMS, o gateway é indistinguível de uma câmera inteligente de primeira linha. Não há passo de integração — há um passo de descoberta.

6.1O custo do overlay

Âncora medida: 15 câmeras 720p a 12 fps saturam o servidor de referência.

1280 × 720 px × 1,5 B (YUV420p) = 1,38 MB/quadro
1,38 MB × 12 fps               = 16,6 MB/s por câmera

Agregado · 15 câmeras:
  vídeo cru manipulado     ~249 MB/s
  tráfego de pipe (×2)     ~498 MB/s
  trabalho de codec        ~332 Mpx/s
  processos FFmpeg          45

332 Mpx/s equivale a decodificar e recodificar ~5,3 streams 1080p30 simultaneamente. O gargalo é aritmética de pixel — a CPU satura muito antes de a rede sentir qualquer coisa.

6.2O custo do Profile M

Sem decode e sem encode, o trabalho por quadro vira: varrer bytes já comprimidos por start codes e copiá-los para pacotes RTP. Uma câmera 720p a ~2 Mbps são ~250 KB/s. Redução no volume de bytes tocados por câmera: ~66× a 12 fps, ~138× a 25 fps. Aplicando margem deliberadamente conservadora de 20× (há custos fixos que não escalam com bytes: syscalls, RTSP interleaved, threads), a projeção é ~300 câmeras por servidor — e o gargalo migra de CPU para rede (1 GbE ≈ 200 canais; 10 GbE ≈ 300–500).

08Engenharia contínua

Buffer ciente de GOP. Câmeras com GOP longo (5–10 s entre quadros-chave) expõem uma premissa sutil: um buffer dimensionado só pela taxa de quadros pode ser menor que um GOP — e, ao aparar o excesso, descartar o IDR. O cliente conecta, não recebe referência, e o timeout parece problema de rede. Três frentes: encurtar o GOP na origem, tornar o buffer ciente de fronteira de GOP, e cache de IDR por câmera para entrega imediata a cada novo cliente. A lição: buffer de vídeo se dimensiona pelo intervalo de GOP, não só pela taxa de quadros.

Empacotamento Windows. Distribuído como serviço Windows via WiX, com MajorUpgrade, registro idempotente, rollback e verificação estrita de retorno. A lição é de arquitetura: portas e caminhos precisam de uma fonte única de verdade — centralizar configuração é barato no dia um e caro no dia mil.

09Observabilidade e validação

Teste de carga embarcado. O produto traz o próprio arnês: sobe N câmeras com rampa configurável, zera contadores após estabilizar, amostra CPU, memória, threads, handles e processos FFmpeg — e, por câmera, FPS de entrada, saída e descartes — persistindo a série temporal para comparação entre execuções. É o que permite responder “cabe quantas câmeras nesse servidor?” com um dado, não uma impressão.

Console de operação em React: dashboard em tempo real, cadastro e diagnóstico de câmeras, sliders de sincronismo com efeito imediato, grade ao vivo, mapeamento de relés com teste individual, usuários, streams e testes de carga. Provisionamento automático: câmeras e regras sincronizam sozinhas com a plataforma de analítica, cada mudança auditada — instalações com centenas de câmeras não dependem de cadastro manual nem divergem da fonte de verdade.