Boa dia galera, tenho um aparelho de câmera de vigilância aqui onde trabalho que usa um programa que chama funções em C/C++ onde tem toda uma SDK para trabalhar em cima dessa linguagem, inclusive com alguns exemplos dos mesmos. Queria saber se é possível usar isso em Java e obter os mesmos resultados? Vi que tem o JNI que permite trabalhar com essa linguagem porém ainda não consegui implementar exemplos básicos com ele usando NetBeans, se tiver outra opções, tutoriais ou exemplos dos mesmos me passem, agradeço qualquer ajuda, flw!
Jni só funciona com linguagem c, não com c++. Para c++ você pode usar jna.
Se vai funcionar, vai sim, mas não vai ficar tão bom e prático de desenvolver se você escrever tudo em c++. A tarefa de mapear todas as bibliotecas em java será um trabalho bem maior.
juliocbq obrigado pela resposta rápida, pesquisei agora rapidamente sobre JNA e vou tentar usa-lo, até porque parece ser mais simples e mais indicado nessas situações. É claro se não for possível o jeito será aprender C/C++ mais implementar uma solução para meu caso, flw!
Também recomendo que você use C++ direto.
C/C++ não é linguagem. São 2 linguagens.
JNI / JNA é algo que dá muita dor de cabeça. No seu lugar, eu faria um executável em C++ que receba parâmetros por linha de comando e esse executável iria chamar as funções do SDK que eu quisesse usar. Em Java, iria chamar esse executável através de um ProcessBuilder e fazer os devidos tratamentos. Dá muito menos trabalho e dor de cabeça com erros bizarros.
Outra opção é comunicar duas aplicação via socket. Embora ainda acho que seja mais fácil escrever diretamente em C++.
Geralmente, o Java não é uma boa linguagem para aplicações multimídia de tempo real, como a que ele quer fazer.
E esse tipo de ponte (seja por processos ou socket) definitivamente não é uma opção.
Especialmente sistemas de segurança, onde ele terá que controlar câmeras e as vezes até outros tipos de hardware.
Outra opção é comunicar duas aplicação via socket. Embora ainda acho que seja mais fácil escrever diretamente em C++.
Geralmente, o Java não é uma boa linguagem para aplicações multimídia de tempo real, como a que ele quer fazer.
E esse tipo de ponte (seja por processos ou socket) definitivamente não é uma opção.
Especialmente sistemas de segurança, onde ele terá que controlar câmeras e as vezes até outros tipos de hardware.[/quote]
Realmente, fazer esse tipo de ponte em sistemas críticos é muito trabalhoso.
Qual seria a solução mais adequada ao problema do autor do tópico então?
Talvez no futuro eu posso usar para controlar as câmeras mais a ideia inicial é apenas receber os eventos que são gerados, como evento de alteração do sistema, alarme etc. Acredito até que possa ser usado Socket mais tenho que analisar melhor porque se não me engano Socket só usa na mesma rede e o Servidor que irá comunicar estará aqui na empresa e o aparelho que será feito a comunicação ficará no cliente.
A ideia do executável também pode ser bem viável.
[quote=matheuslmota]Realmente, fazer esse tipo de ponte em sistemas críticos é muito trabalhoso.
Qual seria a solução mais adequada ao problema do autor do tópico então?[/quote]
Como ele só quer receber eventos, aí tudo bem, pode usar uma das nossas soluções mesmo.
Mas a solução, se ele tivesse que controlar sistemas críticos, seria fazer diretamente em C++.
Hoje, com um framework como o QT, é quase tão fácil quanto fazer em Java: http://qt.nokia.com/
No caso do socket, você fará do mesmo jeito que faria com o executável, com amplas as aplicações na mesma máquina. Seria só para comunicar o C++ com o Java, não para fazer comunicação remota.
Essa câmera é IP ou você captura as imagens usando uma placa?
Se for placa de captura não tem outro jeito a não ser usar recurso nativo, mas se for câmera IP você pode escrever um decoder em java para ler o stream. Normalmente o stream é mpeg/h264 e a solução de mapear o sdk passa a ser bem viável.
+1 - estou vendo se consigo patrocínio aqui na empresa para converter para C++/Qt um visualizador de dados de cotações, que escrevi em Java só para me ajudar a debugar alguns programas, e acabou virando um monstro (muito código, feito incrementalmente, e muito pesado para carregar). É que o problema é que o programa acabou virando ferramenta de apoio à produção 
Já vi se era possível converter o programa de Swing para JavaFX, mas acho que vou ter de mudar muita coisa e não vai deixar o programa assim tão mais leve.
Essa câmera é IP ou você captura as imagens usando uma placa?
Se for placa de captura não tem outro jeito a não ser usar recurso nativo, mas se for câmera IP você pode escrever um decoder em java para ler o stream. Normalmente o stream é mpeg/h264 e a solução de mapear o sdk passa a ser bem viável.[/quote]
O que eu sei é que esse aparelho chamado DVR faz a ligação cabeada entre as cameras e usa stream h264 e ele possui os programas para acessar esse aparelho pela rede(visualizar cameras, receber eventos, alterar configurações do aparelho) ou pode conectar monitor, teclado e mouse nele e acessa-lo da mesma forma tendo os mesmos recursos. Ainda não vi se vem incluído um programa para controla-lo remotamente mas por enquanto é isso!
[quote=entanglement][quote=ViniGodoy]
Hoje, com um framework como o QT, é quase tão fácil quanto fazer em Java: http://qt.nokia.com/
[/quote]
+1 - estou vendo se consigo patrocínio aqui na empresa para converter para C++/Qt um visualizador de dados de cotações, que escrevi em Java só para me ajudar a debugar alguns programas, e acabou virando um monstro (muito código, feito incrementalmente, e muito pesado para carregar). É que o problema é que o programa acabou virando ferramenta de apoio à produção
Já vi se era possível converter o programa de Swing para JavaFX, mas acho que vou ter de mudar muita coisa e não vai deixar o programa assim tão mais leve.
[/quote]
O javafx também é uma boa pedida. Usa hardware para os gráficos(se estiver disponível) e possui uma biblioteca de charts muito boa. Em termos de desempenho é uma vantagem contra o swing. Na parte do qt acho que ficaria devendo no quesito de charts(na versão opensource). Mas você consegue widgets na qt-apps.org ou mesmo pode escrever um set deles usando o arthur paint system. Ele suporta svg além de ser simples de usar e eficiente.
Essa câmera é IP ou você captura as imagens usando uma placa?
Se for placa de captura não tem outro jeito a não ser usar recurso nativo, mas se for câmera IP você pode escrever um decoder em java para ler o stream. Normalmente o stream é mpeg/h264 e a solução de mapear o sdk passa a ser bem viável.[/quote]
O que eu sei é que esse aparelho chamado DVR faz a ligação cabeada entre as cameras e usa stream h264 e ele possui os programas para acessar esse aparelho pela rede(visualizar cameras, receber eventos, alterar configurações do aparelho) ou pode conectar monitor, teclado e mouse nele e acessa-lo da mesma forma tendo os mesmos recursos. Ainda não vi se vem incluído um programa para controla-lo remotamente mas por enquanto é isso![/quote]
Então a solução é mais simples. Usando comunicação tcp você pode ler o vídeo da rede, já que o dvr é o seu servidor. Java é uma solução boa para isso.
Dá uma olhada no sdk e se for o caso você mapeia as bibliotecas para usar com java por jna.
Sobre contrlá-lo remotamente:
Esse programa deve estar embarcado no dvr. Normalmente é uma página html com um controle activex. (http://ipdvr:porta)
[quote=juliocbq]
Então a solução é mais simples. Usando comunicação tcp você pode ler o vídeo da rede, já que o dvr é o seu servidor. Java é uma solução boa para isso.
Dá uma olhada no sdk e se for o caso você mapeia as bibliotecas para usar com java por jna.
Sobre contrlá-lo remotamente:
Esse programa deve estar embarcado no dvr. Normalmente é uma página html com um controle activex. (http://ipdvr:porta)[/quote]
Me parece que ele tem também uma página só que não sei te dizer se é esse modelo de DVR ou um outro que tem aqui, só que para acessa-lo tem que usar IE e tem que desabilitar um monte de coisas aqui pra fazer ele rodar, agora também tem os programas desktop que deve usar comunicação por socket que pro meu caso talvez iria optar pelo tablet com o Android que serviria de ponte para comunicar também com o servidor da empresa.
[quote=Ivan Alves][quote=juliocbq]
Então a solução é mais simples. Usando comunicação tcp você pode ler o vídeo da rede, já que o dvr é o seu servidor. Java é uma solução boa para isso.
Dá uma olhada no sdk e se for o caso você mapeia as bibliotecas para usar com java por jna.
Sobre contrlá-lo remotamente:
Esse programa deve estar embarcado no dvr. Normalmente é uma página html com um controle activex. (http://ipdvr:porta)[/quote]
Me parece que ele tem também uma página só que não sei te dizer se é esse modelo de DVR ou um outro que tem aqui, só que para acessa-lo tem que usar IE e tem que desabilitar um monte de coisas aqui pra fazer ele rodar, agora também tem os programas desktop que deve usar comunicação por socket que pro meu caso talvez iria optar pelo tablet com o Android que serviria de ponte para comunicar também com o servidor da empresa.[/quote]
Sim, o IE é por causa do controle activex. Normalmente se usa esse tipo de controle porque se pode escrever em c++. Em aplicações de vídeo o desempenho é mais importante até que a integridade da informação[um quadro de vídeo]. Por exemplo você precisa de 24 quadros por segundo para ter sensação de tempo real no vídeo. Isso dita também que seu programa pode capturar uma cena que ocorre em poucos segundos. Se eu perder 1 quadro desses por causa de ruído acaba sendo de pouca importância.
Se houver uma cena crítica de roubo em 2 segundos e seu dvr captura 5 quadros em 1, você pode perder muita coisa dela.
Com certeza também tentei fazer um com a câmera do Android ai passava imagens por sockets para outro Android porém tava muito lento e não tive muito sucesso já que as imagens eram grandes e caia a conexão via socket a partir de certo ponto, apesar que nessa usei uma conexão TCP mais acredito que o mais recomendado é o UDP, já que estou tratando de imagens em tempo real. Mas vou seguir as dicas e como não preciso das imagens, apenas das informações vou tentar uma solução encima dessas dicas que vocês me passaram.
sim, é baseado no udp. O rtsp
aqui tem a descrição do protocolo