JMF Video Chat

[UPDATE] New version available http://blog.boehme.me/2010/10/jmf-video-chat-version-11.html

I developed my own video chat using JMF as base for transmitting and receiving RTP data over a network.

At the moment the program can:

• display all available and capable video/ audio devices
• capture live images from your webcam
• initiate a video chat with the same opened instance on another computer

You don't need to install the JMF as the Jar comes as full package including all dependent librarys.

Here are some pictures:


All found devices are displayed in this screen.


Local capture mode.


Network mode on the host side. Right picture is the local and left is the remote one.


Network mode on the Vm Client side. Same as above.


Test environment: Windows 7 64 Bit --> Windows Xp 32 Bit VM LAN

Requirements:

Java Runtime Environment : at least 1.6

Known Bugs:

Error: Sometimes the camera won't be detected
Solution: Try a few times to "Query Devices"

Error: Some temporary .dll files aren't deleted
Solution: Delete them by hand


Download:
Video Chat 1.0

JAR Wrapper for executable JAR Files

You all know .exe wrapper for jar files (like JSmooth). They are used to execute jar files and makes it more comfortable for end users to work with, because they are used to .exe files.

The problem is that you only can execute these generated files on Windows systems. For instance I started to implement a streaming video server with the Java Media Framework. Then I wanted to ship my application to another system, but the application didn't run because of dependency issues.

I had two options:

1. Tell the user to install the JMF to execute my application
2. To make a fully usable jar file which contains all dependencies (in this case .dll files)
   

I chose number 2 to be more platform independent and to free the user from installing unnecessary software.

Now the problem was that I had to build a jar which dynamically extracts and loads these librarys into the library path. Unfortunately Java does not support setting the java.library.path dynamically at runtime, that's why you have to set it when starting the JVM.

This looks something like this: java -jar -Djava.library.path= dlls/
With this argument we tell the Runtime to look into the dlls directory for some librarys we might need.
Then we can call System.load("mydependency.dll"); to make it available for access.

Summing all these issues up and having in mind not to use an .exe file I developed my own executable jar generator.

Following demands led to the decision:

• I have a jar which has system specific dependencies
• I need to set the java.library.path to a custom path where to find these dependencies
• I still want to be platform independent and use a jar

So here is the final result:



The Executable Jar Name is the resulting Jar file containing the system specific jar.
The Executable Jar Location is where you want to save the generated Jar file to.
Then you can specify the including jar file. And at last in which folder the dependent librarys can be found.

If you click on generate the executable Jar File will be generated.

####################################################################
Please keep in mind that the developer of the including jar has currently to take care of the dependent library extraction and loading into the library path. This may be integrated in an upcoming version...
####################################################################

Download: JRun4J