移動(dòng)媒體api外文翻譯

1、<p><b>　　外文：</b></p><p>　　Embedding multimedia capabilities in aMIDlet is the next step in the evolution of MIDlets.Sun recognized early that audio and video are the future and introduced th

2、e Mobile Media API(MMAPI) via Java Specification Requests (JSR) 135(http://www.jcp.org/en/jsr/detail?id=135).The biggest requirement of the MMAPI specification was to ensure compatibility with small footprint devices wh

3、ile creating a specification that would be scalable for future—possiblymore capable—devices. To this end, MMAPI has </p><p>　　What Is Mobile Media API (MMAPI)?</p><p>　　MMAPI is the optional API

4、 that developers use to embed advanced multimedia capabilities in any Java-enabled device. If you’ve been using the audio capabilities in MIDP 2.0, you’ve already been using a subset of MMAPI. This subset is a forward co

5、mpatible version of MMAPI created for limited-capability devices.</p><p>　　MMAPI allows you to create applications for Java-enabled devices that can discover and use the multimedia capabilities of the device

6、 that they are running on. You can play different formats of audio and video files from the network, a record store, or a Java Archive (JAR) file; have advanced control over the playback of these files; capture audio and

7、 video and take snapshots; play MIDI files; generate and play back tones; stream radio over the network; and do a whole lot more. </p><p>　　To encourage device manufactures to use this API in their Java-enab

8、led devices, MMAPI was designed specifically to be protocol and format agnostic. In other words, this API does not come with assumptions about the supported protocol for accessing multimedia content, nor does it makes as

9、sumptions about the formats that it would be able to play. Thus, different device manufactures implement this API in their own way and make it available with the protocols and formats that their devices can suppor</p&

10、gt;<p>　　Most devices, however, support some basic protocols and formats; for example, most allow you to access media over HTTP and play the WAV file format for audio and MP3 for video. </p><p>　　If a

11、 device supports a particular media format, MMAPI may mandate some control over the functionality of that format to create control uniformity across different devices. Other formats may require entirely different control

12、s that may or may not be mandatory. Chapter 2 provides more information about mandatory controls for different formats in the “Feature Sets Implementations” section.</p><p>　　MMAPI Features and Requirements&

13、lt;/p><p>　　MMAPI was designed for Java-enabled mobile devices, but the design is intentionally general enough that any Java-enabled device can benefit from it. This forced a set of rules on the API designers t

14、hat they had to adhere to:</p><p>　　? Low footprint API: Because the main target of this API is Java-enabled mobile phones, which are severely constrained for available memory, the API must be able to suppor

15、t media playback in the available memory. Typically, because the Java-enabled mobile phones run on the Connected Limited Device Configuration (CLDC), the memory available ranges between 128KB and 512KB. This is the memor

16、y available for the virtual machine, the core libraries, your MIDlets, and MMAPI. MMAPI’s place with MIDP is </p><p>　　? Ability to support multiple media types: By defining the core API as a set of interfac

17、es, MMAPI is protocol and format agnostic. Device manufactures supply their own implementation of MMAPI and implement interfaces that support the multimedia capabilities of their devices. This allows a wide range of prot

18、ocols and formats to be supported based on the device, without any hard wiring of protocols and formats built-in the API itself. This makes MMAPI immensely scalable as new formats are discover</p><p>　　? Sup

19、port for basic controls: Although the previous requirement states that MMAPI is protocol and format agnostic, some support for basic controls is guaranteed to be present. This creates uniform procedures for managing medi

20、a, whatever format or protocol it may take. For example, all media can be played, started, or stopped.</p><p>　　? Support for device capabilities discovery: Similar to the previous requirement, all devices c

21、an be queried to discover their capabilities. This allows you to find out which protocols or formats the device supports.</p><p>　　? Support for basic audio and tone generation: Because MMAPI uses CLDC as th

22、e base</p><p>　　minimum supported configuration, it requires some support for audio playback and tone generation. Note that the API mandates support for audio playback but doesn’t restrict it to any particul

23、ar format or protocol, in keeping with the ability to support multiple media types requirement. Device manufacturers are free to choose which format or playback they will support. Tone generation is important in Java-ena

24、bled mobile phones, and therefore, the API provides simple ways to play tones as well. Th</p><p>　　How Do I Get MMAPI?</p><p>　　If you have used the Java Wireless Toolkit (http://java.sun.com/pr

25、oducts/sjwtoolkit/download-2_3.html ) to develop your MIDlets, you already have MMAPI installed. The Toolkit</p><p>　　comes with a reference implementation (RI) of this API installed as an optional package.

26、Of course, MIDP 2.0 contains a subset of this API, so if you are only going to use a limited subset of MMAPI, you don’t need this RI.</p><p>　　Most development environments (such as Netbeans and Eclipse) tha

27、t support mobile application development include a version of this Toolkit, so MMAPI is included as an optional package.</p><p>　　Of course, the RI supplied with the Toolkit may not be your target platform (

28、in all likelihood, it won’t be your target platform because it contains only virtual devices). For example, you may be developing applications for the mobile devices supplied by Nokia. In which case, you need to download

29、 the implementation of MMAPI supplied by Nokia for its devices. This implementation will come bundled with the Toolkit supplied by Nokia (http://forum.nokia.com/main/0,,034-2,00.html ). Similarly, differ</p><p

30、>　　In short, to start developing multimedia applications for Java-enabled devices using MMAPI, you need the Java Wireless Toolkit supplied by the device manufacturers. The last section in this chapter points you to so

31、me popular Toolkits. In this book, I will develop multimedia MIDlets using the Sun supplied Java Wireless Toolkit 2.3 and the Motorola SDK V5.2</p><p>　　(http://www.motocoder.com). In Chapters 8 and 9, I wil

32、l also use the BenQ (formerly Siemens) CX 75 emulator (http://www.benqmobile.com/developer). The Sun Wireless Toolkit will be integrated in the Netbeans Integrated Development Environment (IDE) (http://www.netbeans.org),

33、which will be the main development environment for the examples in this book. The Motorola device emulators will be used to test the MIDlets before deploying them on an actual Motorola device (the Motorola C975), and Cha

34、pters </p><p>　　How Does MMAPI Fit with MIDP 2.0?</p><p>　　MMAPI is an optional package for the Java Micro Edition (ME) platform. MIDP 2.0 is a profile for the development of MIDlets, or applica

35、tions for Java-enabled mobile devices, such as mobile phones and PDAs. MMAPI can be used with not just MIDP 2.0, but with any Java ME profile and configuration, provided an implementation is available for the device you

36、are developing for. Refer to Beginning J2ME: From Novice to Professional, Third Edition, by Jonathan Knudsen and Sing Li (Apress, 2005) for a rev</p><p>　　As you may already know, MMAPI is not the only optio

37、nal package available for developing applications for the Java ME platform. Other prominent packages include the Web Services API (JSR 172), the Mobile 3D Graphics API (JSR 184), and the Location API (JSR 179). All of th

38、ese optional packages, like the MMAPI package, are applicable to all available configurations, such as CLDC and Connected Device Configuration (CDC). On the other hand, an optional package such as the Wireless Messaging

39、API (JSR</p><p>　　MMAPI differs from the other optional packages because a scaled down version of it is present in MIDP 2.0 under the javax.microedition.media and javax.microedition.media.control packages. N

40、o other optional package makes an appearance in MIDP 2.0. So if you are developing applications that only require basic audio control, you don’t need the full MMAPI installed or available. You would still be using MMAPI,

41、 just not the optional and bigger part of it. Yourapplication will run on all devices that </p><p>　　Who Supports MMAPI?</p><p>　　The specification for MMAPI was developed using the Java Communi

42、ty Process (JCP)(http://www.jcp.org) by a consortium of organizations, including device manufacturers,network operators, and multimedia companies, besides Sun Microsystems. This specification is numbered 135 and can be a

43、ccessed at http://www.jcp.org/en/jsr/detail?id=135. The initial expert group for the development of this specification was composed of Sun, Nokia, and Beatnik.</p><p>　　Afterwards, several other organization

44、s chipped in and lent their support for the development of this specification. A final release with a version number of 1.0 occurred on June 27th, 2002. A maintenance release (version 1.1) incorporating security enhancem

45、ents and minor modifications was released a year later on June 26th, 2003, and is the version used for the examples in this book. Recently, JSR 234 has been released that identifies advanced supplements for this MMAPI.&l

46、t;/p><p>　　As part of the development of this specification, Sun released a reference implementation of this API and a technology compatibility kit (TCK) that can be used to certify that an implementation of t

47、his API is compatible with the specification. This is par for any specification</p><p>　　developed using the JCP. As stated earlier, this RI is bundled with the Java ME Wireless Toolkit supplied by Sun. Diff

48、erent device manufacturers supply their own implementations compatible with the TCK.</p><p>　　All devices that support MIDP 2.0 automatically support the scaled-down version of MMAPI. Many devices support th

49、e full version as an optional package. Table 1-1 gives a comprehensive list of devices that support MMAPI as an optional package.</p><p><b>　　Summary</b></p><p>　　This chapter introd

50、uced MMAPI, an optional package for the development of MIDlets that have embedded audio/video capabilities.</p><p>　　MMAPI provides these capabilities by defining a specification that is protocol and format

51、agnostic, thereby increasing general acceptance and uptake. This has made MMAPI very popular and more and more devices support it.</p><p>　　With this introduction to MMAPI’s features and requirements complet

52、e, the next chapter addresses the MMAPI architecture, which is key to understanding and using MMAPI.</p><p>　　The MMAPI specification was created to cater to the widest range of multimedia options, and this

53、is reflected in its architecture. It supports the most basic audio functions in a constrained device and at the same time provides ways to handle advanced multimedia data on more capable devices. MMAPI supports data from

54、 various sources and in various formats. MMAPI’s protocol and format agnostic characteristic is achieved by a well-designed, high-level interface.</p><p>　　This chapter explains how the MMAPI specification a

55、chieves this aim of platform and format neutrality. You’ll become familiar with the details of its architecture and the high-level objects that make it a successful specification. You’ll see how the subset of MMAPI prese

56、nt in MIDP 2.0</p><p>　　differs from the overall specification. Finally, the chapter covers several small details of the MMAPI architecture, such as feature sets and security scenarios, to help you better un

57、derstand and use MMAPI.</p><p>　　Understanding Players and DataSources</p><p>　　MIDlets can receive multimedia data from a variety of sources: located in aMIDlet’s JAR file; come over the networ

58、k via several different protocols (HTTP, RTP); sourced from the device’s record store on which the MIDlet is running; and even come from user input via an audio or</p><p>　　video capture device. In short, no

59、t only can this data be sourced from different locations, but also these locations can be accessed using any number of present or future protocols. At a conceptual level, MMAPI can handle all such locations and protocols

60、 without getting tied down to a specific protocol or location.</p><p>　　After data has been sourced, MMAPI should be able to process this data and make it available for rendering on the device. Processing mu

61、ltimedia data is inherently complex and requires the API to not only understand the data but decode it as well. Rendering the data and providing</p><p>　　controls to manipulate it further complicates the pro

62、cess. Because MMAPI is a high-level interface,it doesn’t mandate any specific data-processing functionality, besides a very low level of audio handling.</p><p>　　To achieve this neutrality with regard to sou

63、rces of multimedia data and processing, MMAPI encapsulates these concepts into two high-level objects: Player and DataSource. Whereas Player is an interface that deals with processing and playing multimedia data, DataSou

64、rce is an abstract</p><p>　　class that encapsulates the task of data location and retrieval while maintaining protocol independence. The Player interface is defined in the javax.microedition.media package, a

65、nd DataSource is defined in the javax.microedition.media.protocol package.</p><p>　　Player and DataSource work together to provide multimedia capability in a device. A Player instance parses data supplied to

66、 it from a DataSource instance. The Player may then render this data on the device and provide controls to manipulate it. For example, an audio Player can provide volume controls to increase or decrease the playback volu

67、me.</p><p>　　DataSource Basics</p><p>　　The DataSource class provides access to multimedia files by locating and opening a connection to them. You may not need to use this class directly, unless

68、 you are going to create a DataSource for a custom protocol or location. The MMAPI implementation provided by the device that you are targeting your MIDlet to will provide enough DataSource instances to satisfy most requ

69、irements.</p><p>　　Each DataSource is composed of one or more streams, known as a SourceStream (an interface in the javax.microedition.media.protocol package). A SourceStream is used to abstract a single str

70、eam of media data. Conceptually, multimedia data may be composed of several streams. For example, video files may be broken down into separate streams, one for audio and one for video. Thus, each individual stream can be

71、 acted on, independently of the other stream, thereby giving greater control than is possibl</p><p>　　A SourceStream also has the advantage of being randomly seekable, because it provides the seek(long where

72、) method. This is an important consideration for multimedia data because it allows you to render this data from an arbitrary position. Of course, a particular stream may</p><p>　　not support random seek oper

73、ations, and this is reflected by the getSeekType() method. This method returns one of three integer constants, shown in Table 2-1.</p><p>　　A SourceStream has one more advantage. For multimedia data that sup

74、ports it, a SourceStream can be used to read the logical transfer size of the data. For example, video data is normally composed of individual frames, so the logical transfer size of the data would be the size of one suc

75、h frame. This allows you to create an in-memory buffer of the right size, equivalent to or greater than the size of the frame, to read data, thereby creating an efficient data read process. SourceStream instances </p&

76、gt;<p>　　Player Basics</p><p>　　The Player interface is your handle to playing and managing your multimedia data. It provides methods to render, control, and synchronize the data with other players, a

77、nd listen to player events such as starting, stopping, and pausing the data.</p><p>　　All media types, except for simple tones, require a Player instance for playback and control. A media type is mapped to a

78、 Player instance that can handle its playback by evaluating the extension of the file that contains the multimedia data and mapping it to a MIME type. For example, if you wanted to play an audio file with the wav extensi

79、on, a Player instance that can handle the MIME type audio/x-wav is created. Similarly, a file with an mp4 extension results in the creation of a Player instanc</p><p>　　Player instances are independent of th

80、e media type that they are playing and only depend on the implementation provided by the device manufacturer. This allows you to use generic methods to manipulate this data. So to start the playback of any multimedia dat

81、a, you use the start() method, which starts playback as soon as possible. To pause, you use the stop() method,</p><p>　　which pauses the playback. To close the data and release any resources associated with

82、it, you use the close() method, and so on. Chapter 4 will introduce you to all the methods that you can use to control media playback.</p><p>　　If you are creating a multimedia MIDlet that is responsible for

83、 simultaneously playing multiple Player instances, you will run into synchronization issues, for example, making sure that video playback starts simultaneously with a separate audio track. In such cases, synchronizing di

84、fferent Player instances can be a problem without a timing reference. Each Player instance has a way to measure time using the TimeBase interface. This interface provides a constantly ticking source of time, and each <

85、;/p><p>　　player2.setTimeBase(player1.getTimeBase()) code. To reset a Player instance’s TimeBase, you can pass a null value to the setTimeBase(TimeBase base) method.</p><p>　　Player instances gener

86、ate events during different stages of their working. By implementing the PlayerListener interface, you can receive notifications of these asynchronous events. This interface defines several common events, but you can cre

87、ate your own proprietary events as</p><p>　　well. Chapter 4 discusses the event management of Player instances in detail.</p><p><b>　　外文譯文：</b></p><p>　　嵌入一個(gè)MIDlet多媒體功能，

88、是MIDlets改革的下一步。Sun很早就認(rèn)識(shí)到，音頻和視頻是祖國(guó)的未來(lái)，并介紹了移動(dòng)媒體API（MMAPI）的通過(guò)Java規(guī)范請(qǐng)求（JSR），最大的MMAPI的要求，135（http://www.jcp.org/en/jsr/detail?id=135）。為規(guī)范，以確保小體積設(shè)備的兼容性，同時(shí)創(chuàng)造一個(gè)規(guī)范，將是未來(lái)可能更強(qiáng)大的設(shè)備可擴(kuò)展。為此，MMAPI已經(jīng)非常成功。這章向您介紹MMAPI和解釋一些使它成為成功典范的因素。你將學(xué)習(xí)到這

89、個(gè)API如何和移動(dòng)信息設(shè)備配置適合MIDIET創(chuàng)建的總體方案。本章涵蓋了關(guān)于支持該API的設(shè)備清單的信息。</p><p>　　什么是移動(dòng)媒體API（MMAPI）？</p><p>　　MMAPI是可選的API，開(kāi)發(fā)人員可以使用嵌入在任何支持Java設(shè)備的先進(jìn)的多媒體功能。如果你已經(jīng)在MIDP2.0中使用了音頻功能，你就已經(jīng)正在使用了MMAPI的子集。這個(gè)子集是一個(gè)MMAPI的能力有限設(shè)備

90、的兼容版本。</p><p>　　MMAPI允許你創(chuàng)建支持Java的設(shè)備，可以發(fā)現(xiàn)和使用的設(shè)備，他們正在運(yùn)行的多媒體功能的應(yīng)用?？梢云鸬讲煌母袷剑瑥木W(wǎng)絡(luò)視頻和音頻文件，記錄存儲(chǔ)，或一個(gè)Java Archive（JAR）文件;有先進(jìn)的控制，在播放這些文件;捕獲音頻和視頻，并采取快照，播放MIDI文件生成和播放回鈴音;流在網(wǎng)絡(luò)上廣播;做一大堆。</p><p>　　鼓勵(lì)設(shè)備制造商在他們的支持

91、Java的設(shè)備使用此API，MMAPI的專門協(xié)議和格式無(wú)關(guān)。換句話說(shuō)，這個(gè)API不支持的協(xié)議訪問(wèn)多媒體內(nèi)容與假設(shè)，也不是有關(guān)格式的假設(shè)，這將是能夠發(fā)揮。因此，不同的設(shè)備制造商在他們自己的方式實(shí)施這個(gè)API，并使其與他們的設(shè)備可以支持的協(xié)議和格式。這種特性使得MMAPI的一個(gè)高層次的接口，使得它能夠兼容任何Java配置。</p><p>　　然而，大多數(shù)設(shè)備，支持一些基本的協(xié)議和格式，例如，最讓你通過(guò)HTTP訪問(wèn)的

92、媒體和音頻和視頻MP3播放WAV文件格式。</p><p>　　如果設(shè)備支持一個(gè)特定的媒體格式，MMAPI的可能委托一些控制了該格式的功能，創(chuàng)造跨越不同設(shè)備的控制均勻。其他格式可能需要完全不同的控制，可能會(huì)或可能不會(huì)是強(qiáng)制性的。第2章提供了更多的有關(guān)強(qiáng)制性控制“功能實(shí)現(xiàn)”一節(jié)中的不同格式的信息。</p><p>　　MMAPI的特點(diǎn)和要求</p><p>　　MMA

93、PI的設(shè)計(jì)啟用了Java的移動(dòng)設(shè)備，但設(shè)計(jì)是一般，以至于任何支持Java的設(shè)備都可以從中受益。這迫使一套API的設(shè)計(jì)者們，他們不得不堅(jiān)持的規(guī)則：</p><p>　　?低足跡的API：因?yàn)檫@個(gè)API的主要目標(biāo)是支持Java的手機(jī)，這是嚴(yán)重的可用內(nèi)存的限制，必須能夠支持媒體播放，可用內(nèi)存的API。通常情況下，有限連接設(shè)備配置（CLDC）上運(yùn)行，因?yàn)樵贘ava功能的手機(jī)，內(nèi)存128KB和512KB之間的可用范圍。這是

94、虛擬機(jī)，核心庫(kù)，你的MIDlet，MMAPI的可用內(nèi)存。覆蓋在“怎樣的MMAPI與MIDP 2.0適配？”一節(jié)，在本章稍后的MMAPI與MIDP中的地位。</p><p>　　?支持多種媒體類型的能力：通過(guò)定義一組接口的核心API，MMAPI的協(xié)議和格式無(wú)關(guān)。設(shè)備制造商提供他們自己的MMAPI實(shí)現(xiàn)和實(shí)現(xiàn)接口，支持他們的設(shè)備的多媒體功能。這允許的協(xié)議和格式的廣泛支持基礎(chǔ)設(shè)備上，沒(méi)有任何的協(xié)議和格式，內(nèi)置的API本身

95、的硬接線。發(fā)現(xiàn)新格式和設(shè)備制造商的支持，這使得MMAPI的極大的可擴(kuò)展性。</p><p>　　?支持基本控制：雖然以前的要求陳述了MMAPI的協(xié)議和格式無(wú)關(guān)，支持一些基本控制，保證到場(chǎng)。這將創(chuàng)建統(tǒng)一管理媒體，它可能會(huì)采取任何格式或協(xié)議的程序。例如，可以播放所有的媒體，啟動(dòng)或停止。</p><p>　　?支持設(shè)備功能的發(fā)現(xiàn)：類似以前的要求，所有設(shè)備都可以進(jìn)行查詢，發(fā)現(xiàn)自己的能力。這允許你找

96、出該設(shè)備支持的協(xié)議或格式。</p><p>　　?支持基本的音頻和音調(diào)產(chǎn)生：由于MMAPI的使用作為基礎(chǔ)支持的最低配置CLDC的，它需要一些支持音頻播放和音代。請(qǐng)注意API的任務(wù)，支持音頻播放，但不限制任何特定的格式或協(xié)議，在保持與能力，以支持多種媒體類型的要求，。設(shè)備制造商可以自由選擇他們會(huì)支持的格式或播放。音產(chǎn)生重要的是在支持Java的手機(jī)，因此，API提供簡(jiǎn)單的方法，以及發(fā)揮的色調(diào)。這些要求導(dǎo)致的API接口

97、，是真正的可擴(kuò)展性，能夠支持陣列設(shè)備上的多媒體格式和協(xié)議的范圍。</p><p>　　我如何獲取MMAPI？</p><p>　　如果你已經(jīng)使用Java無(wú)線工具包（http://java.sun.com/products/sjwtoolkit/download-2_3.html）來(lái)發(fā)展你的MIDlet，你已經(jīng)安裝了MMAPI。該工具包的API作為一個(gè)可選包安裝一個(gè)參數(shù)工具（RI）的配備。當(dāng)