What Is JMF?
| Java Media Framework (JMF) is an API for playing, processing, and capturing media (audio and video). Furthermore, this API can be used to transmit or receive live media broadcasts, and conduct videoconferences. To accomplish these latter two tasks , JMF uses RTP ”Real-time Transport Protocol. (RTP is not discussed in this chapter. If you want to learn about RTP, consult JMF's API guide, which is part of a JMF download's documentation.) JMF Version 1.0 came into existence a few years ago as the result of a partnership between Sun Microsystems Inc., Silicon Graphics Inc., and Intel Corp. This version was soon followed by JMF Version 1.1, which made minor improvements to the framework. However, JMF 1.0 and 1.1 were limited to media playback. They did not support media processing or media capture. (Conducting videoconferences and transmitting/receiving live media broadcasts were definitely out of the question.) These limitations led Sun, in partnership with IBM Corp., to develop JMF Version 2.0. Although quite successful, JMF 2.0's architecture needed to be improved. Earlier in 2000, Sun completed these improvements, and JMF Version 2.1 arrived. (In spite of changes, Version 2.1 could still benefit from additional improvements.) Downloading and Installing JMFContrary to what you might think, JMF is not bundled with version 1.3 of the Java 2 Platform Standard Edition. Instead, it's a standard extension that is downloaded separately from the Javasoft Web site (http://www.javasoft.com/jmf). You have two options when downloading JMF. You can choose cross-platform JMF (which runs on all Java-supported platforms), or you can download a performance pack for either Solaris or Windows. (As this book is being written, a performance pack for Linux has been promised for release in the near future.) The performance pack includes JMF and extensions (that are operating system-specific) for improving the playback quality of media. The way JMF is installed depends on whether cross-platform JMF or a performance pack was downloaded. If you downloaded cross-platform JMF, you will need to extract all files from an archive. For example, if you chose to download a ZIP file, you would end up unzipping jmf-2_1-alljava.zip . However, if you downloaded a performance pack, you must run a program to take care of installation. For example, if you chose the performance pack for Windows, you would end up running jmf-2_1-win.exe to install the Windows version of JMF. The APIJMF's API consists of 11 packages. The main package is known as javax.media , and contains the following subpackages:
After you start to create JMF programs, you might want to know how to obtain this API's version number for those times when your program must run correctly under multiple versions of JMF. The Manager class (located in the javax.media package) contains a getVersion method that returns this version number, as a String object. To demonstrate this method, Listing 20.1 presents source code to the JMFVersion application. Listing 20.1 The JMFVersion Application Source Code // JMFVersion.java import javax.media.*; class JMFVersion { public static void main (String [] args) { System.out.println ("Version = " + Manager.getVersion ()); } } A Layered ArchitectureJMF presents a layered architecture comprised of a high-level presentation (player) and processing API and a low-level plug-in API. Software developers create applications, applets, or beans ( components developed with the JavaBeans framework) that interact with this high-level API. In turn , this API interacts with a low-level plug-in API. The plug-in API offers extensibility to JMF's architecture, by way of plug-ins (separate code modules, such as demultiplexers, codecs, effect filters, renderers, and multiplexers) that can be integrated into this architecture. JMF's layered architecture is illustrated in Figure 20.1. Figure 20.1. JMF's layered architecture is divided into high-level and low-level APIs. Media StreamsJMF has been designed to play, process, and capture media streams (media flowing from a source to a destination). Each media stream is identified by its content type (format). This content type describes the data format of the media stream. For example, MPEG represents the content type of a video stream. A media stream consists of one or more tracks (data channels). Each track represents a separate kind of media to describe an overall experience. For example, QuickTime media might contain an audio track in addition to a video track. Multiple tracks are combined into a single track (for storage or transmission), through a process known as multiplexing and individual tracks are recovered (for playback) through demultiplexing . Furthermore, the actual structure of a track's media is known as its format . For example, Cinepak is a format used by the QuickTime content type. A media stream is identified by location and access protocol. Either uniform resource locators (URLs) or media locators (URLs without URL stream handlers) are used for this task. (A URL stream handler is an object created from a subclass of the abstract URLStreamHandler class. This object can make a connection to a remote computer using a specific access protocol such as HTTP.) A media stream can be categorized as either a pull stream or a push stream. A pull stream is initiated and controlled from the client side. An example of a pull stream is an HTTP media stream originating from a Web server, and initiated and controlled by a Web browser. In contrast, a push stream is initiated and controlled from the server side. A media stream originating from a microphone is an example of a push stream. Time Bases and ClocksTime-based media must be played , processed , or captured at a precise rate of time. Otherwise, pauses or jittery behavior will occur. To handle time-based media, JMF uses time bases and clocks. (In most cases, you will never work with these entities. However, to understand JMF, you need to have some comprehension of time bases and clocks.) A time base is an object (created from a class that implements the TimeBase interface) that represents a constant ticking source of time (like a crystal oscillator). It is based either on the native system clock or on another hardware clock (such as the hardware clock on an audio card). In any case, a time base can never be stopped or reset. The current time can be returned from this object, either by calling getNanoseconds (to return the number of nanoseconds that have elapsed since the system clock was started), or by calling getTime (to return an object created from the Time class that contains the same time information). A Time object represents a point in time. Its getNanoseconds method returns this time in nanoseconds, whereas its getSeconds method returns this time in seconds. Finally, its secondsToNanoseconds method converts from seconds to nanoseconds. Objects that decode and render media streams are created from classes that implement the Clock interface. Each clock contains a time base that tracks the passage of time as a media stream is presented. This passage is known as media time . A clock's media time represents the current position in a media stream. The beginning of this stream is referred to as media time zero and the end of this stream is the maximum media time for the stream. The duration of this stream is the elapsed time from start to finish. In other words, the duration is the length of time taken to present the media stream. To keep track of the current media time, a clock uses the time base start-time (the time that its time base reports when the presentation begins), the media start-time (the position in the media stream where presentation begins), and the playback rate (how fast the clock is running in relation to its time base). The rate is a scale factor applied to the time base. For example, 1.0 represents a normal playback rate, whereas 2.0 represents a playback rate that is twice as fast. A negative rate implies that the clock runs in the reverse direction, and can be used to play a media stream in reverse. When presentation begins, media time is mapped to the time base time. The advancement of the time base time is then used to measure the passage of time. During presentation, the current media time is calculated with the following formula: media time = media start time + (time base time - time base start time) * rate When the presentation stops, media time stops, but the time base time continues to advance. If the presentation is restarted, media time is remapped to the current time base time. ManagersJMF's interfaces define the behavior and interaction of objects used to play, process, and capture time-based media. Implementations of these interfaces operate within the structure of this framework. By using managers (intermediary objects that control key JMF activities), JMF makes it easy to integrate new implementations of key interfaces with existing classes. Managers can be divided into four categories: media managers, package managers, plug-in managers, and capture device managers. A media manager is created from the Manager class. It handles the construction of players, processors, data sources (media protocol-handlers that manage the life-cycle of media sources, by providing simple connection protocols), and data sinks (objects that read media content delivered by a data source and render the media to some destination). Media managers allow new players, processors, data sources, and data sinks to be seamlessly integrated with JMF. From the client perspective, these objects are always created the same way, whether the requested object is constructed from a default or custom class. The package manager is created from the PackageManager class. It maintains a registry of packages that contain classes for custom players, processors, data sources, and data sinks. When you extend JMF's capabilities with new players, processors, data sources, or data sinks, you must register new package prefixes for these classes with the package manager, so JMF will find them at runtime. The plug-in manager is created from the PlugInManager class. It maintains a registry of available JMF plug-in processing components (such as multiplexers, demultiplexers, codecs, effect filters, and renderers). When you extend JMF's capabilities with new plug-ins, you must register these plug-ins with the plug-in manager to make them available to processors that support the plug-in API. Tip You don't have to register a plug-in with the plug-in manager during development. Instead, you can set the CLASSPATH environment variable to the location of your plug-in's class (or classes). Finally, the capture device manager is created from the CaptureDeviceManager class. It maintains a registry of available capture devices. If you are writing a program that captures media, this program must query the capture device manager to make sure that an appropriate capture device is present. |
EAN: 2147483647
Pages: 353