JMF: getting player for current service question
On interactivetvweb.org I found something like this:
// Get a reference to the JavaTV ServiceContextFactory
ServiceContextFactory factory;
factory = ServiceContextFactory.getInstance();
// From this, we can get a reference to the parent
// service context of our Xlet. To do this, we need a
// reference to our Xlet context. It's times like this
// that show why your application should always keep a
// reference to its Xlet context
ServiceContext myContext;
myContext = factory.getServiceContext(myXletContext);
// ServiceContentHandler objects are responsible for
// presenting the different parts of the service. This
// includes the media components
ServiceContentHandler[] handlers;
handlers = myContext.getServiceContentHandlers();
for(int i=0; i < handlers.length ; i++){
if (handlers[i]instanceof ServiceMediaHandler){
// This is a Player for part of the service, since
// ServiceMediaHandler objects are instances of JMF
// Player objects
//so I guess here i can do something like:
Player p = (Player) handlers[i];
p.start();
break;
}
}
But do I have to do something like
myContext.select(s);
before getting service content handlers (where s is an instance of Service)? Because I don't quite understand idea of getting player from context.
[2112 byte] By [
el_chea] at [2007-10-2 7:48:49]
Well...I have questions about this, too.
If in this case, we don't need to call servicecontext.select(s);
When do we need to do this?
And in the book"interactive TV standards", it said that the number of servicecontexts may limited in the number of tuners. So, the number of player is the same like servicecontext? or in a servicecontext, there may be two or more players in it ?
Thanks for any apply ^^
You needto do this if you want to control the player for the current service (e.g. you want to scale the currently playing video so that you can view a thumbnail of it in your application).
The number of service contexts that are available will depend on the receiver. A receiver will support a service context for its main tuner, and may optionally support a service context for any other tuners in the box (but not always - for a tuner used only for picture-in-picture, this may not make any sense). The receiver may also be able to support one or more service contexts for built-in applications, but this is optional and may depend on the available memory. It's always safest to assume that you only have the same number of service contexts as you have tuners.
For players, you may have more than one player per service context. You may have one player presenting broadcast video and another player presenting MPEG audio, for instance. While there is no limit to this within MHP, in practice you soon run into resource management issues with MPEG decoding. Since you typically need one MPEG decoder for every player that is actually playing media, this restricts the number of active players that you can have.
Steve.
