TOC Prev Next
Synchronizing Players manually using syncStart requires that you carefully
manage the states of all of the synchronized Players. You must control each one
individually, listening for events and calling control methods on them as appropriate.
Even with only a few Players, this quickly becomes a difficult task. Through
the Player interface, JMF provides a simpler solution: a Player can be used to
manage the operation of any Controller.
When you interact with a managing Player, your instructions are automatically
passed along to the managed Controllers as appropriate. The managing Player
takes care of the state management and synchronization for all of the other Controllers
.
This mechanism is implemented through the addController and removeController
methods. When you call addController on a Player, the Controller
you specify is added to the list of Controllers managed by the Player. Conversely,
when you call removeController, the specified Controller is removed
from the list of managed Controllers.
Typically, when you need to synchronize Players or other Controllers, you
should use this addController mechanism. It is simpler, faster, and less error-
prone than attempting to manage synchronized Players individually.
When a Player assumes control of a Controller:
- The
Controller assumes the Player's time-base.
- The
Player's duration becomes the longer of the Controller's duration
and its own. If multiple Controllers are placed under a Player's control,
the Player's duration is the longest of all of their durations.
- The
Player's start latency becomes the longer of the Controller's start
latency and its own. If multiple Controllers are placed under a Player's
control, the Player's start latency is the longest of all of their latencies.
A managing Player only posts completion events for asynchronous methods after
every added Controller has posted the event. The managing Player reposts
other events generated by the managed Controllers as appropriate.
8.1 Adding a Controller
You use the addController method to add a Controller to the list of Controllers
managed by a particular Player. To be added, a Controller must be in the
Realized state; otherwise, a NotRealizedError is thrown. Two Players cannot
be placed under control of each other. For example, if player1 is placed under the
control of player2, player2 cannot be placed under the control of player1
without first removing player1 from player2's control.
Once a Controller has been added to a Player, do not call methods directly on
the added Controller. To control an added Controller, you interact with the
managing Player.
To have player2 assume control of player1, call:
player2.addController(player1);
8.2 Managing the Operation of Added Controllers
To control the operation of a group of Controllers managed by a particular
Player, you interact directly with the managing Player. Do not call control methods
on the managed Controllers directly.
For example, to prepare all of the managed Controllers to start, call prefetch
on the managing Player. Similarly, when you want to start them, call start on
the managing Player. The managing Player makes sure that all of the Controllers
are Prefetched, determines the maximum start latency among the Controllers
, and calls syncStart to start them, specifying a time that takes the
maximum start latency into account.
When you call a Controller method on the managing Player, the Player propagates
the method call to the managed Controllers as appropriate. Before calling
a Controller method on a managed Controller, the Player ensures that the
Controller is in the proper state. The following table describes what happens to
the managed Controllers when you call control methods on the managing
Player.
|
Function
|
Stopped Player
|
Started Player
|
setMediaTime
|
Invokes setMediaTime on all managed Controllers.
|
Stops all managed Controllers, invokes setMediaTime, and restarts Controllers.
|
setRate
|
Invokes setRate on all managed Controllers. Returns the actual rate that was supported by all Controllers and set.
|
Stops all managed Controllers, invokes setRate, and restarts Controllers. Returns the actual rate that was supported by all Controllers and set.
|
start
|
Ensures all managed Controllers are Prefetched and invokes syncStart on each of them, taking into account their start latencies.
|
Depends on the Player implementation. Player might immediately post a StartEvent.
|
realize
|
The managing Player immediately posts a RealizeCompleteEvent. To be added, a Controller must already be realized.
|
The managing Player immediately posts a RealizeCompleteEvent. To be added, a Controller must already be realized.
|
prefetch
|
Invokes prefetch on all managed Controllers.
|
The managing Player immediately posts a PrefetchCompleteEvent, indicating that all managed Controllers are Prefetched.
|
stop
|
No effect.
|
Invokes stop on all managed Controllers.
|
deallocate
|
Invokes deallocate on all managed Controllers.
|
It is illegal to call deallocate on a Started Player.
|
setStopTime
|
Invokes setStopTime on all managed Controllers. (Player must be Realized.)
|
Invokes setStopTime on all managed Controllers. (Can only be set once on a Started Player.)
|
syncStart
|
Invokes syncStart on all managed Controllers.
|
It is illegal to call syncStart on a Started Player.
|
close
|
Invokes close on all managed Controllers.
|
It is illegal to call close on a Started Player.
|
8.3 Removing a Controller
You use the removeController method to remove a Controller from the list of
controllers managed by a particular Player.
To have player2 release control of player1, call:
player2.removeController(player1);
TOC Prev Next
|
Print-friendly Version
