I've tried using JMF on a 64 bit environment and 64 bit JDK but to no avail. There isn't a 64 bit jmvfw DLL available for JMF.
My question is: Is there any alternative Media Framework out there that is fully 64 bit or a Java Media Framework 64 bit?
I need it to do camera capturing and video streaming and it has to run on 64 bit environment and JDK.
Thanks
http://www.xuggle.com/downloads
http://build.xuggle.com/view/Stable/job/xuggler_jdk5_stable/
http://build.xuggle.com/ (source)
They used to supply an installer .exe, now you have to read the documentation on their website to build the 64 bit windows version yourself, if you want a 64-bit linux build, you can get it at the second URL. Xuggle will let you convert/stream video or audio, I believe it uses a 64-bit compile of ffmpeg with Java as a wrapper around it so that you don't have to think about the ffmpeg command line options.
you can have both 32-bit jre/jdk and 64-bit on the same machine. JMF IS 32-bit. But the java application can still be 64-bit, check out JMStudio code for it and use the 64-bit for the java.awt.Image for example and the 32-bit to bring in the images.
JNI code written in c++ and assembler would be a possible solution if you need it, create custom jar ( java libraries ) and link in .d or .dll files as needed.
Related
I am working on an application in which I am using Tesseract for OCR.
My code is working absolutely fine in windows 32 bit system.
But when I try to run the same code in 64 bit machine using the 32 bit .dll files, the code is running but then the code is not giving the accurate results.
So I am running it in 64 bit machine using the 64 bit .dll files.
Now when I tried to run the same program, I got the following error in Console(Eclipse Kepler).
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: %1 is not a
valid Win32 application.
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.Native.open(Native.java:1759)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:260)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.sun.jna.Native.loadLibrary(Native.java:412)
at com.sun.jna.Native.loadLibrary(Native.java:391)
at net.sourceforge.tess4j.TessAPI.<clinit>(TessAPI.java:38)
at net.sourceforge.tess4j.Tesseract.init(Tesseract.java:293)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:227)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:176)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:159)
I have downloaded the 64 bit .dll files (https://github.com/charlesw/tesseract/tree/master/src/lib/TesseractOcr/x64) compatible with 64 bit system but still i am getting the same error.
I am using GhostScript v-8.71 on 64 bit machine. I have installed this in both Program Files and Program Files(x86). I have also set the environment variables accordingly.But still not working.
Please please provide me with some solution!
Tess4J only currently supports 32-bit JVM
This is the creator, nguyenq, responding to a similar issue on a sourceforge forum.
Similarly, in the tutorial it points out that only 32-bit DLL's are included in the distro.
To run with a JVM 64-bit, you'll need to use Tesseract and Leptonica 64-bit DLLs.
One solution: Tell your IDEto use a 32-bit JVM instead.
-- downside is that you may be mixing 32 bit and 64 bit environments, in a complicated app or env this could be odd... (I don't think it's too bad, but might be a pain in your IDE)
In an update found here, it seems you can find DLL's for 64-bit Java here, as part of the Tesseract wrapper for .NET (oddly enough). However, I haven't tried out those 64-bit DDL's yet and in the sourceforge link, it says they depend on the Visual C++ Redistributable for VS2012 or Visual C++ Redistributable for VS2013 ... which sucks....
I'll update this post if I figure out a cleaner solution.
UPDATE
Note that I did this working with Amazon Web Services instances.
I was able to get Tess4J to work on a 64-bit Ubuntu 14.04. It was actually very simple once I gave up on my Red Hat distro and went to Ubuntu.
sudo apt-get install tesseract-ocr will get tesseract set up completely. You can check by typing tesseract -v. I also needed GhostScript because I was working with PDF's. sudo apt-get install ghostscript again got everything set up. Verify with gs -v.
Now in your Java app, all you need to include are the JAR's from Tess4J's download in your path -- jna-4.1.0j.ar, jai_imageio.jar, tess4j.jar, and ghost4j-0.5.1.jar if you are working with PDF.
In your Java app, you need to set the data path so your Tesseract instance knows where tesseract is installed. Even while I had the environment variable set, it never worked for me. I needed to explicitly set the data path like so:
Tesseract tessInstance = Tesseract.getInstance();
tessInstance.setDatapath(System.getenv("TESSDATA_PREFIX"));
ImageIO.scanForPlugins(); // make sure it knows about GhostScript, to work with PDFs
String result = tessInstance.doOCR(myFile);
Be sure that setDatapath() sets to the parent folder of the tessdata folder of your tesseract installation (on my Ubuntu this was /usr/share/tesseract-ocr/`).
That was all I needed. No worrying about DLL's in class path.
tl;dr:
Use up-to-date Ubuntu
sudo apt-get tesseract-ocr
sudo apt-get ghostscript if working with PDF
include proper Tess4J JAR's (jna-4.1.0j.ar, jai_imageio.jar, tess4j.jar, and ghost4j-0.5.1.jar if you are working with PDF)
call tess.setDataPath() to point to your tesseract installation (/usr/share/tesseract-ocr/ for my Ubuntu 14.04)
ImageIO.scanForPlugins() if using GhostScript
That's it. You are good to go call tess.doOCR(MyFile) happily
Earlier this year I code Java GUI to work in Matlab environment for image acquisition purposes. I was able to call Java_Gui.jar inside the matlab, as well as to use some of the classes from the .jar file. The GUI was tested on WinXP 32bit, and Matlab2006b and Matlab 2008a. Matlab code for calling Java classes:
clc,clear all,close all
javaaddpath('C:\Users\...\JavaGUI.jar');
JavaGUI.main([]);
pause(1)
JavaGUI.main2();
However, when tried same program with Win7 on 64bit and Matlab2011a the familiar problem occurred:
??? Java exception occurred:
java.lang.UnsatisfiedLinkError: no sserial in java.library.path
Any idea why is this happening? Maybe I should compile my jar file on 64bit version?
The code is still working on 32bit Win, just checked it.
ANSWER: Works with 32-bit version of Matlab on 64-bit Windows 7!
Probably your JAR uses JNI.
JNI won't be able to load into a process of a different bitness than the DLL containing the native portions. You'd need a 64-bit version of the library (the Java code is no different, the native DLLs are) in that case.
The problem is that you are using a library in java that makes calls to a native library for which you need the 64-bit version in order to run it in the 64 bit JRE. You need to either switch to a 32 bit version of Matlab, or track down the library that makes native calls to sserial and update to the 64 bit version for 64 bit systems.
I am new to JOGL. I use Eclipse and I imported JOGL jar and dll (yes, Windows OS). But, when I was searching for JOGL libraries, I downloaded 32 bit version. I have 64 bit OS, but since I can run 32 bit apps I thought it will still be more suitable. But compiler is complaining: Can't load IA 32-bit .dll on a AMD 64-bit platform
Well, first, I thought Java itself is NOT separated by architecture. Yes, I know I am using native libraries to link into Windows OpenGL interface (API), but I just want to include these code snippets into java bytecode, so why compiler cant let me use 32 bit ones? Thanks.
Since you have a 64-bit OS, you installed the 64-bit JVM. The 64-bit JVM cannot use the 32-bit DLLs, so you'll need to either download the 64-bit ones, or alternatively, install the 32-bit JVM on your system and set Eclipse to use that JVM instead.
64bit JVM cannot load 32bit libraries. You need to start 32b JVM to make it work (or get 64b dlls).
I export try.jar file using 32 bit java libraries. On the client site, I have 64 bit java libraries. Can try.jar behave 64 bit executable?
For example, I have
Runtime rt = Runtime.getRuntime();
s = rt.exec("someExecutable");
the someExecutable binary is in 64 bit and using this code with 32 bit java libraries seems to be not working.
My soln' to this problem is to export try.jar using 32 bit java libraries (because my enviroment is in 32 bit) and run try.jar using 64 bit libraries in the client site.
Is this approach correct or any other suggestions?
when I run someExecutable directly (no java involved) which is 64 bit on the client site It works fine (client site is also 64 bit.).
But when I use s = rt.exec("someExecutable"); It doesnt work. the java libraries (jre executables downloaded over java.sun.com) are now 32 bit at both client and development sites.
Do my problem resolve if I install 64 bit libs to client site but not on development site??
Java librairies aren't the problem here. If you want to exec someExecutable, this program must be in 32 bits for a 32bit environment.
Java libraries aren't 32 or 64 bit, they are in Java ByteCode. So they can be executed on any JVM 64 or 32 the exact same way.
You will need a someExecutable binary available on the operating system architecture you wish to run your program on.
This isn't actually anything to do with Java - all Java is doing is going to the underlying operating system and trying to run the command in the String you pass to Runtime.exec().
What's the problem you get when do that?, if you're using 100% java code, JRE should transparents all other things.
I have installed 64 bits RHEL. I have following questions regarding ant.jar for the system.
I was not able to find ant.jar build with 64 bit JVM from the apache website. Do I have to build it form the source code, if I intend to run the jar on 64 bit JVM?
Would it speed up the build process if I use ant.jar build with 64 bit JVM and run it on 64 bit JVM?
You do not need a special 64 bit build of a pure Java application such as Ant. The ant.jar will run equally on a 32 bit or 64 bit JVM.
The only cases where you would definitely need to run a 64 bit version of a Java application are:
when the application includes native code libraries; i.e. the application is not pure Java, or
when the Java application has been compiled directly to native code; e.g. using gcj.
(It is possible that a poorly written application will be operating system dependent. For example, someone could hard code an application to use OS-specific line separators or pathnames, or to rely on specific OS-specific external commands. But the chances are that even this won't make the application dependent on the OS memory model.)
No, java bytecode is java bytecode, it doesn't matter whether it was built with a 32-bit or 64-bit JDK.
For the same reason, it doesn't matter which operating system it was built on either. For example: a jar built with a 32-bit JDK on 32-bit Microsoft Windows should run just fine on a 64-bit JRE on 64-bit RHEL.