JMF allows you to work with media – audio and video. Working with here means input (reading in from file/device), processing (encoding/decoding/multiplexing) and output (to file/network/screen).

Nitty-gritty details are mostly shielded from the programmer, yielding a clean interface for use. In fact once we completed our audio streaming, converting it to video streaming was almost a one-liner change for the Format class. However since we need to separate the components clearly (content vs transport), we had to try tear JMF apart. In fact JMF handled so much of RTP that we just need to give it a ip/port and off it goes.

The flexibility of the framework theoratically allows all forms of media to be processed, however it is currently limited to certain codecs and formats, maybe due to the need to interact with native hardware/OS, or licensing issues. We had some problems interacting with webcams, likely issue to be the webcam drivers are application specific, only their own apps know how to access the webcam. Hopefully more webcam providers make their cams OS-generic, such that it can be recognized by Windows. This way it is more likely JMF will be able to detect it.

Another issue we bumped into is that JMF binds to AWT. For displayable components like Video visual and Video controls, it is returned as an AWT component. Since we use SWT it could be a chore to code bridges.

Because of performance, JMF comes in certain performance packs, which probably have certain algorithms in native code so it runs faster/better by making use of the OS/hardware. (accelerator? processor opcodes?)

Leave a Reply