MediaSelectControl and service selection
I thought that only Service Selection APIs can invoke service selection. More precisely, only ServiceContext.select() causes service selection, but MediaSelectControl confuses me.
An xlet can get a MediaSelectControl of current service content handler via ServiceContext.getServiceContextHandler(), and the array returned contains actually a set of JMF players, one can call Controller.getControl("javax.tv.media.MediaSelectControl") to get a MediaSelectControl instance.
MHP spec 1.0.3 does not say that MediaSelectControl.select() cannot accept locators which belong to other service. If an application gets a MediaSelectControl instance and selects a set of locators belonging to other service, does this imply a service selection?
In MHP spec 1.0.3 it says that JMF implementation shouldn't cause tuning, so I think that MediaSelectControl can cause service selection but is limited to services within current TS?
I traced JavaTV 1.1 RI, and I found that MediaSelectControlImpl.select() calls ServiceContext.select(). Is this MHP compliant? What is the scenario and purpose of MediaSelectControl (also DVBMediaSelectControl) in MHP?
Please help me clarify this. Thank you for your kindly reply.
[1237 byte] By [
woodheada] at [2007-10-3 5:22:18]
There is a subtle but important difference between service selection and playing content from another service. This applies to JMF players in general, and not just MediaSelectControl.
Playing new content involves the following steps
1) Read the SI that is needed to decode and play the new content, and start playing it.
Service selection involves the following steps:
1) Tune to the TS containing the new service (if necessary).
2) Read the SI that is needed to decode and play the default streams from the new service, and start playing them.
3) Begin monitoring the AIT, and kill/start applications as instructed.
I bolded the last step because that is the important one, and is the one that differentiates playing a new stream from service selection. A service consists of both video/audio and the applications, and so selecting a new service involves changing both of those elements.
Simply playing a different video stream, no matter what the source, doesn't change the set of apps that will run. Event tuning to a new TS doesn't change this (although it may affect the ability to load them).
Because of this, MediaSelectControl never causes a service selection operation, and neither does creating a Player for a different service. In both cases, the MHP implementation will still monitor the AIT on the original service. As you've alreadsy noted, mediaSelectControl will not cause the box to tune (neither will creating a new Player), but this is simply to prevent apps inconveniencing other apps unless they explicitly choose to do so.
To answer your last question, it looks like the JavaTV RI is not MHP compliant.
Hopefully this will clarify things a little, but if not let me know where is still confusing and I'll try to answer.
Steve
> MHP spec 1.0.3 does not say that
> MediaSelectControl.select() cannot accept locators
> which belong to other service.
Actually it does - the following throws clause;
InvalidServiceComponentException - If the specified service component is not part of the Service to which the MediaSelectControl is restricted, or if it cannot be presented alone.
JMF players which are ServiceMediaHandlers (i.e. are obtained from the service selection API) are restricted in this way.
> If an application gets
> a MediaSelectControl instance and selects a set of
> locators belonging to other service, does this imply
> a service selection?
You can only do this with a Player created via Manager.createPlayer but if you did, it would still not be service selection as explained by Steve.
> I traced JavaTV 1.1 RI, and I found that
> MediaSelectControlImpl.select() calls
> ServiceContext.select(). Is this MHP compliant?
Depends if it throws InvalidServiceComponentException and if it starts MHP applications when it should not.
> What
> is the scenario and purpose of MediaSelectControl
> (also DVBMediaSelectControl) in MHP?
>
If you have a channel with multi-lingual audio, MediaSelectControl would be used to choose a non-default audio stream. The same is conceptually true with video however getting 2 video streams in the same service is hard in practice.
Thank you Steve and desperado.
I checked JavaTV 1.1 RI's codes, and I found that definition of MediaSelecControl.select() does throw InvalidServiceComponentException, but this exception is actually thrown in ServiceContext.select(). So maybe for MHP compliant, MediaSelectControl.select() shall do some locator checking.
As Steve and desperado mentioned:
MediaSelectControl can never cause a service selection, but it does allow to select different media components to be presented.
One thing just come into to my head, I have a guess:
I guess that some implementation uses MediaSelectControl.select(Locator[]) to implement ServiceContext.select(Locator[]).
Tuning and notification to application manager are done in ServiceContext.select(), but selecting MediaContent is done by MediaSelectControl. Is it correct?
MediaHandlers which xlets can get are JMF players in started state. So for xlets, Controls like MediaSelectControl can only be acquired after the Player starts.
Is it possible that Xlets can get Controls of a player before it starts?
If no, neither does middleware implementation?
Please kindly clarify my doubts.
Info you two provided always helps me a lot.
Thank you.
To answer your first question, This will vary from implementation to implementation, and so it's difficult ot say. In the implementaitons I worked on, service selection created a new Player object and simply stopped/deallocated any existing ServiceMediaHandlers. In this case, selection of components was handled by the Player.
Regarding your second question, Xlets can create a JMF Player and then get controls on it without having started it but exactly what will get returned is implementation-dependent.
In a desktop JMF implementation where the content type is not known until you actually start reading the clip, you may not be able to get many useful controls until you actually start playing the clip. In an MHP or OCAP implementation where some of this can be pre-determined, then it is possible to get some controls without actually having started the player. Not every implementaiton needs to support this, and Xlets certainly shouldn't rely on it.
The other thing to be aware of, of course, is that some operations can change the set of controls that are available on a player. Anything that generates a PresentationChangedEvent may cause a change in the set of available controls, as may component selection.
Steve.
