Dentro de «vão funcionar juntos» escondem-se duas perguntas. A primeira é se o gravador aceita a câmara de todo — descoberta, um fluxo, uma imagem no ecrã. A segunda, que decide se o sistema é agradável de possuir, é se tudo o que a câmara faz sobrevive à viagem: eventos, controlo PTZ, o fluxo secundário que a grelha usa, o plano de gravação. As normas abertas respondem à primeira pergunta com fiabilidade e à segunda apenas em parte, e saber qual é qual é o que impede um sistema misto de se tornar um problema de manutenção.
As razões para misturar são banais e não exóticas. Um edifício é ampliado e a nova ala recebe câmaras modernas; um gravador chega ao fim de vida mas as câmaras nas paredes têm três anos e funcionam; um cliente quer mudar de marca sem recablar cinco pisos. Em cada caso a pergunta é a mesma: quanto do sistema existente fica, e o que tem de ser aceite como diferente.
O que é o ONVIF — e o que não é?
O ONVIF é uma norma de interoperabilidade: define como um dispositivo se descreve na rede e como outro dispositivo lhe pede um fluxo, move uma cabeça PTZ ou subscreve eventos. Um dispositivo com a marca de conformidade passou um teste para o perfil que reivindica. É uma garantia com significado — significa que dois dispositivos de fabricantes diferentes partilham uma linguagem comum e um conjunto comum de comandos.
O que não garante é paridade de funções. A norma define interfaces, não implementações: uma câmara pode expor PTZ através do ONVIF e um gravador pode aceitá-lo, enquanto a analítica na câmara ou as funções próprias do fabricante na aplicação nunca aparecem no gravador de terceiros. A conformidade diz respeito à conversa, não a todas as frases que cada lado consegue dizer.
Que perfis ONVIF importam num sistema de edifício?
| Perfil | O que abrange | Onde se encontra |
|---|---|---|
| Profile S | Streaming: configuração, descoberta, vídeo e áudio em direto | A base para uma câmara aparecer no gravador de outra marca |
| Profile T | Streaming avançado: H.265, multi-fluxo e metadados | Câmaras modernas que oferecem um fluxo principal e um secundário a um gravador de terceiros |
| Profile G | Controlo de gravação e armazenamento do lado do dispositivo | Onde as gravações e a sua recuperação são geridas na câmara ou no seu próprio armazenamento |
Para um sistema de edifício, o pressuposto de trabalho é simples: assuma o Profile S, verifique o T se pretende gravar o codec moderno através de um gravador de terceiros, e trate o G como uma questão sobre armazenamento na periferia e não sobre o gravador no armário.
Porque é que o RTSP é a porta que costuma estar aberta?
Onde o ONVIF é uma linguagem, o RTSP é muitas vezes a via direta: um URL que pede um fluxo à câmara, na forma de um endereço, uma porta e um caminho. A porta é convencionalmente a 554; o caminho é específico do firmware de cada fabricante e vem publicado na documentação da própria câmara. Daí decorrem duas consequências para um sistema misto. Primeira, o RTSP funciona onde a integração mais rica não funciona, o que o torna a alternativa que mantém um sistema misto vivo. Segunda, como o caminho é específico do fabricante, documenta-se por câmara em vez de se presumir.
As câmaras do tipo que construímos expõem um fluxo principal e um fluxo secundário através dessa interface. O fluxo principal é o que vale a pena gravar a 5 MP; o fluxo secundário é o que a grelha em direto e o cliente móvel devem usar, porque uma parede de janelas miniatura não precisa de resolução total nem deve pagá-la em largura de banda. Um sistema misto com o fluxo secundário desligado é um sistema misto que parece lento por razões que nada têm a ver com as marcas.
O que sobrevive num sistema misto, e o que não sobrevive?
| Capacidade | Através de interfaces abertas | A ressalva honesta |
|---|---|---|
| Visualização em direto e gravação | Sim | O caso comum, e aquele para que a norma foi escrita |
| Controlo PTZ | Sim, onde a câmara o expõe | As predefinições e os percursos podem comportar-se de forma diferente entre clientes |
| Eventos de movimento | Movimento básico, habitualmente | O cruzamento de linha, a intrusão e analíticas semelhantes ficam muitas vezes dentro do cliente do próprio fabricante |
| Áudio bidirecional | Por vezes | Depende de ambos os extremos suportarem o mesmo percurso de áudio |
| Aplicação móvel e cliente | Não | A aplicação de cada fabricante vê o seu próprio hardware; um sistema misto significa habitualmente duas aplicações, ou um gravador que publica uma |
| Firmware e atualizações | Não | Sempre separados, sempre por marca |
Quais são as três formas de gerir um sistema misto?
- Manter as câmaras, trocar o gravador. A migração mais comum, e a mais barata de planear: os gravadores da nossa gama falam ONVIF, RTSP, GB28181 e P2P, por isso as câmaras existentes que exponham qualquer dessas interfaces podem ser registadas e gravadas. Substitua o gravador, mantenha o plano de câmaras, e a cablagem não muda.
- Manter o gravador, trocar as câmaras. Registe as câmaras novas no gravador existente por ONVIF ou RTSP, um canal de cada vez. As câmaras antigas ficam em serviço até cada posição estar pronta, o que significa que o edifício nunca fica cego durante a mudança.
- Manter os dois durante a transição. Gravador antigo e gravador novo na mesma rede durante um período, para que nada se perca enquanto a mudança é verificada. Exige endereçamento disponível e alguém que compreenda qual sistema grava o quê — vale a pena onde uma reclamação possa surgir na janela de transição.
Onde falham os sistemas mistos na prática?
As falhas raramente têm a ver com marcas e quase sempre com configuração. Um fluxo secundário desligado, pelo que o gravador puxa o fluxo principal em todos os canais e o teto de largura de banda chega cedo — nos nossos gravadores maiores, a largura de banda de entrada é de 64 Mbps, o que é confortável para um edifício e é algo com que se depara por volta do trigésimo canal de 5 MP se tudo for gravado a débito total. Incompatibilidades de codec, quando um extremo oferece H.265 e o outro espera H.264. Endereçamento duplicado, quando dois servidores DHCP partilham uma rede durante uma migração e uma câmara responde a um endereço que outra pessoa reivindicou. Desvio de relógio, que torna discretamente a linha temporal pouco fiável até alguém ativar o NTP em todo o lado. Credenciais e limites de sessão, quando um gravador pede a uma câmara mais fluxos simultâneos do que o firmware dela permite.
O que incluir numa lista de verificação para a migração?
- Liste o que fica e o que muda, e escreva qual dos cinco elos — câmara, switch, cabo, gravador, cliente — a mudança toca.
- Confirme as interfaces dos dois lados: perfil ONVIF, disponibilidade de RTSP e o codec que cada lado grava.
- Verifique a largura de banda de entrada do gravador contra o número de canais e a resolução gravada, e não apenas contra o número de câmaras.
- Ative o NTP em todos os dispositivos antes da entrada em serviço, para que a linha temporal seja fidedigna desde o primeiro dia.
- Mude primeiro um canal e observe-o ao longo de uma noite antes de comprometer os restantes.
- Mantenha o acesso ao sistema antigo disponível até o teste de aceitação ser assinado.
A compatibilidade não é uma propriedade de sim ou não de uma marca; é uma lista de interfaces e definições que alinham ou não alinham. Percorra-a canal a canal e um sistema misto torna-se banal — que é precisamente o objetivo.
