Sun Java Solaris Communities My SDN Account Join SDN

1.0 Programmers Guide

1.0 Overview

 
TOC  Prev  Next  
To synchronize the playback of multiple media streams, you can synchronize the Players by associating them with the same TimeBase. To do this, you use the getTimeBase and setTimeBase methods defined by the Clock interface. For example, you could synchronize player1 with player2 by setting player1 to use player2's time base:

player1.setTimeBase(player2.getTimeBase());
When you synchronize Players by associating them with the sameTimeBase, you must still manage the control of each Player individually. Because managing synchronized Players in this way can be complicated, JMF provides a mechanism that allows a Player to assume control over any Controller. The Player manages the states of the controllers automatically, allowing you to interact with the entire group through a single point of control. For more information, see "Using a Player to Manage and Synchronize other Controllers" on page 29.

In a few situations, you might want to manage the synchronization of multiple Players yourself so that you can control the rates or media times independently. If you do this, you must:

  • Register as a listener for each synchronized Player.

  • Determine which Player's time base is going to be used to drive the other Players and set the time base for the synchronized Players. Not all Players can assume a new time base. For example, if one of the Players you want to synchronize has a push data-source, that Player's time base must be used to drive the other Players.

  • Set the rate for all of the Players. If a Player cannot support the rate you specify, it returns the rate that was used. (There is no mechanism for querying the rates that a Player supports.)

  • Synchronize the Players' states. (For example, stop all of the Players.)

  • Synchronize the operation of the Players:

    • Set the media time for each Player.
    • Prefetch all of the Players.
    • Determine the maximum start latency among the synchronized Players.
    • Start the Players by calling syncStart with a time that takes into account the maximum latency.
You must listen for transition events for all of the Players and keep track of which ones have posted events. For example, when you prefetch the Players, you need to keep track of which ones have posted PrefetchComplete events so that you can be sure all of the Players are Prefetched before calling syncStart. Similarly, when you request that the synchronized Players stop at a particular time, you need to listen for the stop event posted by each Player to determine when all of the Players have actually stopped.

In some situations, you need to be careful about responding to events posted by the synchronized Players. To be sure of the Players' states, you might need to wait at certain stages for all of the synchronized Players to reach the same state before continuing.

For example, assume that you are using one Player to drive a group of synchronized Players. A user interacting with that Player sets the media time to 10, starts the Player, and then changes the media time to 20. You then:

  • Pass along the first setMediaTime call to all of the synchronized Players.

  • Call prefetch on the Players to prepare them to start.

  • Call stop on the Players when the second set media time request is received.

  • Call setMediaTime on the Players with the new time.

  • Restart the prefetching operation.

  • When all of the Players have been prefetched, start them by calling syncStart, taking into account their start latencies.

In this case, simply listening for PrefetchComplete events from all of the Players before calling syncStart isn't sufficient. You can't tell whether those events were posted in response to the first or second prefetch operation. To avoid this problem, you can block when you call stop and wait for all of the Players to post stop events before continuing. This guarantees that the next PrefetchComplete events you receive are the ones that you are really interested in.

TOC  Prev  Next