1 Introduction of JMF Student : 朱浩廷 Advisor : 杭學鳴 教授

2 Introduction of MHP,JavaTV -(1) Using middleware for interactive TV development has a number of advantages. DVB developed MHP( multimedia Home Platform) as a common platform for interactive TV. The purpose of MHP is to provide a common platform for digital TV and to avoid fragmenting the market too much. This is one of the reasons why other standards bodies have taken MHP as the basis for their own standards and created a truly global 'common platform'. It makes it easier for manufacturers to hide differences in the underlying hardware, which in turn makes it easier for network operators to buy receivers from more than one vendor. It also offers a standard platform for application developers - one that provides support for those special features that are needed in the digital TV world such as low-level access to the broadcast stream, service information access, and support for the specialized graphics model of a digital TV receiver. A big market

3 Introduction of MHP,JavaTV -(2) So what does MHP do in order to establish itself as this common platform? MHP uses the application model from JavaTV as a central piece of the MHP specification, and all of the JavaTV APIs are included in MHP. 1. Anyone is free to implement the middleware. The specification can be downloaded for free, and the only costs are a small fee for compliance testing and the fees for licensing the necessary IPR from DVB. 2. Applications are written in Java or HTML, so they don't depend on any single hardware platform or operating system. The MHP specification says very little about the underlying platform and the hardware that is needed in order to give implementers as much freedom as possible. 3. MHP has defined the GEM (Globally Executable MHP) specification that allows other standards bodies to build iTV standards that are compatible with MHP while meeting the technical and commercial needs of local markets. MHP is specific to the DVB family of standards. JavaTV, on the other hand, is not. JavaTV describes a set of digital TV concepts such as accessing service information, selecting a new service, and loading files from a carousel rather than a normal filesystem, but it does so in a way that's not tied to any digital TV standard.

4 Introduction of JMF To control how audio and video content is decoded and displayed, JavaTV and MHP rely on he Java Media Framework defined by Sun Microsystems. JMF probably wasn't the ideal choice for a media control API given its strong focus on PC-based media, but it was a lot easier to use JMF than to define something new, and there are an awful lot of people who already know how to use JMF. MHP uses version 1.1 of the JMF API.

5 3 major concepts of JMF player, controls, data source By separating the object that decodes and presents the media from the object that fetches the media, we make it easier to decode and play the same type of media from more than source (and play several different media types from the same source). A Player always has an associated DataSource object - it is not possible to create a player that does not have a data source attached to it.

6 Time model-(1) JMF keeps time to nanosecond precision. A TimeBase provides a constantly ticking time source, much like a crystal oscillator in a watch. The JMF Player class is a subclasses the Clock class, so every player acts as its own clock. This media time is a time-based index into the clip, and usually it is taken as the start of the media clip. MediaTime = MediaStartTime + Rate(TimeBaseTime - TimeBaseStartTime) If the media is always being streamed, what do we mean by media time?

7 Time model-(2) Timebase getTime getNanoseconds Duration getDuration Time Time(long nanoseconds) Time(double seconds) getNanoseconds getSeconds secondsToNanoseconds Clock getMediaTime setMediaTime getRate setRate getStopTime setStopTime getTimeBase setTimeBase syncStart stop has a getTimeBase,setTimeBase can be used together to synchronize different Clocks to the same TimeBase

8 Event Model Whenever a JMF object needs to report on the current conditions, it posts a MediaEvent. MediaEvent is subclassed to identify many particular types of events. To receive notification when a MediaEvent is posted, you implement the appropriate listener interface and register your listener class with the object that posts the event by calling its addListener method. Controller addControllerListener removeControllerListener ControllerListener controllerUpdate(ControllerEvent) ControllerEvent getSourceController MediaEvent has a creates extends

9 Managers-(1) By using intermediary objects called managers, JMF makes it easy to integrate new implementations of key interfaces that can de used seamlessly with existing classes. To write programs based on JMF, you’ll need to use the Manager create methods to construct the Players, Processors, DataSources, and DataSinks for your application. If you extend JMF functionality by implementing a new plug-in, you can register it with the PlugInManager to make it available to Processors that support the plug-in API.

10 Managers-(2) Javax.media.Manager

11 Player The player creation process-(1) Given that a JMF implementation can have multiple data sources, and players to handle multiple media types. Let's consider the process of creating a player from a URL. We'll take a URL as our example, because in the end a locator also maps on to a URL. EX: Manager construct the class name of the DataSource object that it needs to create. This is calculated as..DataSource ◆ The protocol indicates the data source that is needed to access this content, where in this case, the protocol is http. ◆ The class prefix is simply a fixed string that points to the top of the class hierarchy containing the data source implementation classes. So, if our class prefix was com.stevem.media.protocol, the resulting class name would be com.stevem.media.protocol.http.DataSource 1.Create the class name of the DataSource

12 Player The player creation process-(2) 2. The DataSource is loaded and instantiated 3. The Manager uses this data source to connect to the location specified in the URL 4. The Manager uses the getContentType() method on the data source to find the MIME content type of the data that the data source is connected to and uses it to constructed the class name for the Player The MIME content type is then used to construct the class name for the Player that will be loaded. The class name takes the form...Player MIME: Multipurpose Internet Mail Extensions So, if the class prefix was com.stevem.media.players and the MIME content type was audio/mp3 (since we've connected to a URL for an MP3 file), the resulting class name for the player is com.stevem.media.players.audio.mp3.

13 Player The player creation process-(3) 6.The manager calls the Player.setSource() method to associate the data source with the player. 5. The Player is loaded and instantiated

14 Player The player state machine-(1) Unrealied StoppedStarted Prefetching prefetch deallocate, setMediaTime Transition Events: RCE:RealizeCompleteEvent PFCE:PrefetchCompleteEvent SE:StopEvent When a media Player is first created, it is Unrealized. Realized RCE A Realized Player knows what resources it needs and information about the type of media it is to present. Realizing realize deallocate A Realizing Player is in the process of determining its resource requirements. Prefetched PFCE A Prefetched Player preloads its media data, obtains exclusive-use resources, and does whatever else it needs to do to prepare itself to play. Prefetching might have to recure if a Player object’s media presentation is repositioned, or if a change in the Player object’s rate requires that additional buffers be acquired or alternate processing take place. Started stop SE start

15 Player The player state machine-(2) To prevent race conditions, not all methods can be called on a Player in every state.

16 Player There are some differences between players in DTV middleware implementations of JMF and players in the desktop PC version. The first of these differences is that some of the standard features of players in a desktop implementation are not available. These include things like the setSource() method (inherited from the MediaHandler class), since setting the data source in this way has little or no meaning in an MHP environment due to limitations imposed by the hardware. Another difference is that the selection of media may be driven more by user preferences or platform settings than would be the case in a desktop implementation. For instance, the choice of audio track or subtitles will probably be based on user preferences and the language settings in the receiver firmware, whereas a desktop implementation would typically only have to handle clips that included only one audio or subtitle language. The largest difference, however, is that players in a desktop JMF implementation will usually have a user interface or control panel attached, while in a set-top box or other consumer implementation they probably won't. The Player.getVisualComponent() and Player.getControlPanelComponent() methods will usually return a null reference in a JMF implementation for digital TV, because the media is typically played in the video layer.

17 DataSource take a closer look at the interface to the DataSource class: while a DataSource object can be constructed using a MediaLocator directly, this is not the usual way that it gets created. Instead, the Manager normally ends up calling Class.newInstance() to instantiate this object (because the middleware doesn't actually know what class it needs to load until run-time). For this reason, we have separate methods to set and get the locator as well as being able to set it using the constructor. Without an associated locator, the data source is useless. We can only set the locator once - attempting to set it a second time will generate an error.

18 Reference “Interactive TV Web”- “Java Media Framework API Guide” - media/jmf/2.1.1/guide/index.html