jmf开发指南3

jmf开发指南

	 
JMF开发指南-1
2008-05-17 22:10
bigbigant翻译自
http://java.sun.com/javase/technologies/desktop/media/jmf/1.0/guide/JavaMediaFrame.fm1.html
以前常常鄙视别人翻译的文档，这次自己翻译，刚做完第一章，读了觉得和金山快译半斤八两，所以强烈自我鄙视一下.
1.0概览

JMF提供了一个平台无关的框架来呈现时基媒体(time-based media)。JavaMediaPlayerAPI的设计目标是支持多种标准的媒体格式，包括MPEG-1,MPEG-2,QuickTime,AVI,WAV,AU和MIDI.使用JMF,可以同步呈现不同来源的时基媒体。

现有的一些媒体播放器都严重依赖原生码来执行解压缩、渲染 等 计算密集型任务。而JMF API则隐藏了具体实现，只提供抽象的编程接口。

举例来说，一个用JMF制作的播放器，具体运行的过程中可能会调用到操作系统的本地方法，但开发者写代码时可以无视本地方法的存在。


JMF Player API :

    *

      接入不同的协议和分发（传输）机制
    *

      接入不同的媒体数据类型
    *

      定义事件模型，用于Player和应用程序间的异步通信


1.1 数据源（Data Source）

一个DataSource 封装了媒体的地址、协议和分发的软件。一个JavaMediaPlayer包含一个DataSource。一旦创建，这个DataSource不能被用于其他媒体的传输。 一个Player的数据源可以用MediaLocator或URL来标示。

MdiaLocator(媒体定位器)是一个JMF类，用来描述Player播放的媒体。MediaLocator与URL类似，并且可以从URL来创建。他们的区别在于，在Java中，URL只有其协议是已知协议时才能被创建，而MediaLocator则没有这个限制。

Java 媒体播放器可以播放来自多种数据源的媒体数据，包括本地、网络文件和实时广播等。

JMF支持两种不同的数据源。

    *

      Pull Data-Source （数据源被动的被获取）－由客户端发起数据传输并控制数据流，已知的协议包括HTTP(超文本传输协议)和本地文件。
    *

      Push Data-Source （数据源主动推送）－由服务器发起数据传输并控制推送数据流。此类数据源包括广播媒体，多点传送的媒体和VOD(视频点播)。

客户端程序所能够控制的度量，取决于媒体源的类型。举个例子说，MPEG文件可以被重定位（reposition）,那么播放MPEG的客户端程序就可以允许用户重播或者跳进至一个新时间点；而由服务器段控制的广播媒体则不能被重定位；另外VOD协议则支持有限的用户操作，比如一个VOD客户端程序可以允许用户跳进至新位置，但不能快进和快倒。

1.2 Players

一个Java Media Player是一个对象。她基于时间来处理数据流，从DataSource读取数据并在确切的时间点渲染媒体。一个Java Media Player必须实现Player interface.

    *

      Clock定义了基本的计时和同步操作， 她被Player 用来控制媒体的呈现。
    *

      Controller继承Clock对外提供提供如下方法：

   1.

      管理系统资源
   2.

      预载数据
   3.

      提供监听机制（Observable）,对外发送媒体事件通知

    *

      Duration提供了检测媒体时长的途径。
    *

      Player支持标准的用户控制，并放宽了来自于Clock的一些操作限制。

多个Player共享一个公共的计时和同步模型。一个Player的媒体时间表示了媒体流的当前位置。每一个Player有一个TimeBase。TimeBase定义了Player的时间流逝。当一个Player 被执行start，他的媒体时间会被映射到time-base时间。如多个媒体要同步，那么他们必须使用同一个TimeBase.

一个Player的用户界面可以包含一个可视组件和一个控制面板组件（control- panel component）。我们用的时候可以选择实现一个自定义的用户界面，或者使用Player的默认的控制面板组件。

一般来说，一个Player在能够呈现媒体之前，必须先执行一序列的操作。而这些操作有可能会耗费一定的时间，所以JMF定义了一些操作状态，并且提供了状态转换的操作机制。

1.3 Media Events

JMF事件报告机制允许我们的程序响应媒体驱动的错误，比如数据丢失或资源不可用。事件系统同时也提供了重要的通知协议；当我们的程序调用一个Player的异步方法时，只有当收到响应的事件消息时，才能确认操作是否完成。

有两种JMF对象会抛出事件，他们是： GainControl对象 和 Controller 对象。 对于事件, GainControl和 Controller 遵循Java Beans 形式。

GainControl对象只抛出一种类型的事件－ GainChangeEvent。我们通过实现 GainChangeListener interface来响应gain(增益？)的变化。

Controller则会抛出多种派生自 ControllerEvent的事件。我们通过实现 ControllerListener interface 来接收诸如Player的Controller抛出的事件消息。

下图显示了Controller抛出的各种事件类型：

ControllerEvents 可分为三类：改变通知、关闭事件和转换事件

    *

      变化通知(Change notification events)诸如 RateChangeEvent 和 DurationUpdateEvent。他们表示Player的一些属性数值发生了变化。这类事件通常是对一些方法调用的回馈。例如， 一个Player的setRate方法被调用，他会抛出一个 RateChangeEvent.
    *

      转换事件(TransitionEvents) 让我们的程序能够响应Player的状态变化。 当Player从一个状态转换到另一个状态时，就会抛出一个转换事件。 (在1.4中，我们会提供更多的关于Player状态的信息)
    *

      当player关闭时，则会抛出关闭事件(ControllerClosedEvents)。当一个Player不再可用时，抛出 ControllerClosedEvent. ControllerErrorEvent(控制器错误事件)则是关闭事件的一个特例。我们写程序时，通过监听控制器错误事件，可以对Player故障作出响应，从而增进用户体验。

1.4 Player States

JavaMediaPlayer有6种状态。Clock 接口定义了两种主要的状态：Stopped和Started。


在普通操作中，Plyaer在到达Started状态前，会逐个通过上图中的每一个状态。

    *

      Unrealized（未实现） 状态表示Player已经被实例化，但还不知道媒体的任何信息。当Player第一次被创建，他的状态就是Urealized。
    *

      Player的realize方法被调用后，会从Unrealized转入Realizing（实现中）状态。这时的Player应该正在检测资源需求。在relization过程中，Player会获取只需加在一次的资源。这些资源包括非独享的渲染资源。（独享资源指的受限的资源。例如只能被一个播放器使用的个别硬件资源，此类资源会在预取（Prefetching）的过程中加载。） Realizing中的Player常常通过网络下载东西。
    *

      Player结束Realizing状态后，会转入 Realized（已实现）状态。这个状态下，Player会知道他需要哪些资源，还知道媒体的类型信息。因为Realized Player知道怎样渲染数据，所以他能够提供可视组件和控件。此时 ,Player与其他系统对象的连接已经就位，但此时还不会占用任何会阻止其他Player启动的资源。
    *

      Prefetch被调用后，Player会从Realized状态转入Prefetching（预取中）状态。此时播放器在为呈现媒体作准备，包括调用媒体数据、获取独享资源 和其他一些准备工作。在媒体呈现过程中，一些操作可能会导致 Prefetching状态 重现，例如重新定位播放位置、播放器请求额外的缓冲区等。
    *

      当Player结束预取，将转入Prefetched(预取完成)状态。此时Player已经准备开始播放但尚为实际开始。
    *

      调用start方法将使Player转入Started状态。此时，Player的媒体时间被映射到time-base时间，并且clock开始运行。此时播放器有可能会等待一个恰当的时间来呈现媒体数据。

当player从一个状态转入另一个状态时，会抛出 TransitionEvents(转换事件),我们可以通过实现 ControllerListener接口来监听这些时间并作出恰当的响应。

当播放器开始Realizing和Prefetching的时候，我们可以使用事件报告机制对Player进行管理，在调用Player方法之前，我们可以先检查Player状态，在作出恰当的操作。
1.4.1 Methods Available in Each Player State
Player在各个状态下可用的方法

Method
	

Unrealized

Player
	

Realized

Player
	

Prefetched Player
	

Started

Player

getStartLatency
	

NotRealizedError
	

legal
	

legal
	

legal

getTimeBase
	

NotRealizedError
	

legal
	

legal
	

legal

setMediaTime
	

NotRealizedError
	

legal
	

legal
	

legal

setRate
	

NotRealizedError
	

legal
	

legal
	

legal

getVisualComponent
	

NotRealizedError
	

legal
	

legal
	

legal

getControlPanelComponent
	

NotRealizedError
	

legal
	

legal
	

legal

getGainControl
	

NotRealizedError
	

legal
	

legal
	

legal

setStopTime
	

NotRealizedError
	

legal
	

legal
	

StopTimeSetError
if previously set

syncStart
	

NotPrefetchedError
	

NotPrefetchedError
	

legal
	

ClockStartedError

setTimeBase
	

NotRealizedError
	

legal
	

legal
	

ClockStartedError

deallocate
	

legal
	

legal
	

legal
	

ClockStartedError

addController
	

NotRealizedError
	

legal
	

legal
	

ClockStartedError

removeController
	

NotRealizedError
	

legal
	

legal
	

ClockStartedError

mapToTimeBase
	

ClockStoppedException
	

ClockStoppedException
	

ClockStoppedException
	

legal

1.5 Calling JMF Methods 调用JMF方法时的一些约定

JMF对于errors(错误)和exceptions(异常)作如下约定。

    *

      Java Media Errors 是当程序调用了一个当前状态下非法的方法时抛出的。Errors是在外部程序有控制权的状态下执行了非法的请求而抛出的。举例来说，调用一个处于Started的Player的方法时抛出的就是error。开发者有责任在调用方法前确认Player已被停止。JMF error是可以通过优化代码来避免的，应用程序不应该捕获JMF errors, 好的应用程序不会碰到这些错误。
    *

      Java Media Exceptions是当程序调用了不能完成的方法或在当前状态下不适用的方法。Exceptions是在外部程序没有控制权的状态下抛出的。例如当我们试图同步两个time-base不匹配的Player时，就会抛出异常。之所以是异常而不是错误，是因为我们无从检测time-base是否匹配，是无法预期的。

有时，JMF的一些方法会返回非预期的结果，通过检查返回直，我们可以检测实际发生的事情：

    *

      我们可以通过返回直检查实际被设置的数值，例如：并不是所有的播放器都可以每周期5次的速率呈现媒体数据，如果我们调了setRate(5.0)，播放器将会设置一个合法的近似直，这个数值可能是5.0也可能是1.0,我们需要检查返回数据来确认被设置的数据。
    *

      有时，我们请求的信息是不可用的。例如：Player在播完一个媒体之前，可能不知道媒体的时长，这时如果我们调了getDuration()，getDuration会返回 DURATION_UNKNOWN.当媒体被播放完一次，再调getDuration时，则会返回正确的时长。