Time—A Central Concept

Not surprisingly, after all it is called time-based media, time is a key concept in the JMF. Thus it is important that programmers who employ the API have a good understanding of the model of time that JMF uses.

JMF provides a layered model of time. At the bottom-most layer exists an exact representation of an instant in time at the nanosecond level. The next layers support the concept of a constantly ticking source of time: a clock. The highest layers support abstractions of time as being started or stopped and being in one of a number of potential states. These layers allow a programmer to exercise timing control (for example, alter play rate) as well as keep track of time-based processes at the level appropriate for the task. In particular, the abstracted higher-level models of time, as being one of a number of states, are particularly important for most JMF programs.

This section broadly discusses the high-level, abstract models of time because these are the most important in gaining a conceptual understanding of the functioning of a JMF program. The next chapter contains a far more detailed discussion of the time model of the JMF and the classes that support that model.

Controlling the processing (for example, playing or transcoding) of time-based media might, at first glance, appear to be either a process that is started (ongoing or happening) or stopped (yet to begin or finished). Certainly that division between started and stopped is true. However, initiating control is generally not instantaneous; indeed, it can be quite time-consuming. Resources generally need to be gathered. For instance, a file might need to be read, a socket opened, or a buffer filled. For this reason, the JMF divides stopped time into five exclusive states. In that way, JMF programs are better capable of managing the asynchronous and perhaps lengthy preparation tasks involved in handling time-based media. Figure 7.15 shows those five states and their relationships to one another.

These five states represent the life cycle of a media Controller (for example, Player) from creation to being ready to start. Transitions that forward toward a Prefetched (ready to start) state are under program control, whereas errors or other events might lead to a transition in the other direction. Programs (objects) might be informed of state changes by adding themselves as listeners for such events. In that manner, a program can initiate operations as well as respond timely and appropriately as those operations move through their various stages.

The five controller states that subdivide stopped time are

Unrealized— The controller has been created but hasn't even begun to perform its task by gathering any resources. All controllers start in this state.

Realizing— The controller is acquiring information about the resources it needs to function. This transition state should result in the controller becoming Realized, although the time taken is unknown.

Realized— The controller has gathered information about all the resources it needs to perform its task. Indeed it is likely to have acquired all those resources necessary, which would not entail tying up an exclusive system resource (for example, grabbing a hardware device). Realized is a steady state; it is moved past when the controller has prefetching initiated.

Prefetching— The processor is performing start-up processing such as filling buffers or acquiring hardware resources. This is a transition state that should result in the controller becoming Prefetched, although the time taken is unknown.

Prefetched— The controller has acquired all necessary resources, performed all prestartup processing, and is ready to be started.