JMF API 中文指导（1）JavaTM Media Framework API Guide NO.2
High-Level Architecture
Media Data Storage and Transmission
Storage Controls
Implementing Plug-Ins
Implementing MediaHandlers and DataSources
Time Model
關於TIME，可實作二個相關的interface：
Clock Interface：定義了basic timing和同步時所需的資料，clock是使用TimeBase作為track行進的時間(而time-base提供的資訊只有目前的時間，以system clock為主)
Duration Interface：影片的開始到結束的時間(片長時間)
為了維持track目前時間，Clock使用：
以time來記錄
以position來記錄
以play back rate：rate=張數 / 秒數 * 時間
公式：MediaTime=MediaStartTime+Rate(TimeBaseTime-TimeBaseStartTime)
位置 絕對時間
JMF time model
Managers
對於媒體的擷取、處理和播放時間性的媒體，JMF都有提供相關的API。
JMF所使用的 4 個managers：
1. Manager--包含Players, Processors, DataSources和DataSink四種classes，object都是用此四種去建構成的。
2. PackageManager--可自定classes,如：自定的Players、 Processors、 DataSources、DataSinks
3. CaptureDeviceManager--當我們要從input device去capturing媒體資料的話，就需使用CaptureDeviceManager去尋找可以使用、存取的devices。
4. PlugInManager--當我們要處理資料的performance時(如：編碼)，可以使用 plug-in的處理元件，如Multiplexers,Demultiplexers, Codecs, Effects、Renderers.
在JMF的程式中，我們將使用到這些Manager去create methods去建構Players、 Processors、 DataSources、DataSinks。
Event Model
MediaEvent 是定義許多JMF事件的子集合。如：我們要implement一個 listener的interface，我們就需呼叫事件：addListener；我們要去controller objects(像Players和Processors)和creatain Control objects就需呼叫事件：GainControl。
Data Model
JMFmedia players通常使〞DataSources〞管理媒體的傳輸、連結。
DataSource包含了媒體位置、protocol、和使用何種軟體來傳送媒體。
DataSource不是透過MediaLocator就是透過URL來定義，MediaLocator很類似URL而且可以從URL中去建構，即使系統上沒有安裝符合的protocol handler仍可被create。（但在Java中，只有在系統上安裝符合的protocol handler時才可被create）
DataSource管理一或多個SourceStream objects。一個標準的data source是使用byte為傳送單位；一個buffer data source是使用buffer為傳送單位。JMF定義了幾種DataSource objects的型態：
根據資料傳送方式分類：
- PullDataSource：client端開始傳送資料，並控制pull data-sources的資料流，使用的protocols型態為HTTP、FILE。JMF定義二種pull data sources型態：PullDataSource、PullBufferDataSouce。
- PushDataSource：server端開始傳送資料，並控制push data-sources的資料流。使用的protocols型態包括RTP、multicast media、VOD。JMF定義二種push data sources型態：PushDataSource、PushBufferDataSouce
client端程式可依使用者自訂，並將其以dataSource型態播出。例如：MPEG：使用者可自行改變播放位置、重播。相對的，廣播則是由server端控制，則無法改變播放位置，有些VOD支援使用者控制─例如：client端程式允許使用者能尋找到新的位置，但無法快轉或倒帶。
Specialty DataSources
JMF定義了二個特殊的Data Sources型態：Cloneable data Sources、Merging data Source
必須注意的是合併時DataSource須都皆為同一型態，例如：PullDataSource與PushDataSource不可合併。而合併後的Content Type為application/mixed-media。
Data Formats
描述媒體編碼格式名稱，資料格式型態的需求。
JMF繼承Format去定義audio和video的格式：
AudioFormat：記載audio格式的屬性，例如：頻率、bits數、和channel數量
VideoFormat：包含video相關的資料訊息。VideoFormate包含以下數個共同的格式: IndexedColorFormat 、RGBFormat 、YUVFormat 、JPEGFormat 、H261Format 、H263Format
Controls
提供設定、查詢物件屬性，通常提供存取符合的使用者介面元件，可讓使用者控制物件的屬性。許多JMF objects有接觸到Controls，包括：Controller objects、DataSource objects、DataSink objects、JMF plut-ins。
上圖為JMF controls
JMF定義的Standard Controls：
- CachingControl：監控下載進度和播放，假如，Player或Processor可以記載download progress，CachingControl就可以implements interface，讓progress bar可以display出來。
- GainControl：能夠調整audio音量，例如：對於player或processor輸出的聲音做調整或消音，它同時支援音量改變的mechanism。
上圖為Gain control
l StreamWriterControl：可使用DataSink或Multiplexer等objects從Data Source讀入媒體，並寫至目的地（如：file），可實作StreamWriterControl介面，且這個Control可限制stream產生的大小。
l FramePositioningControl：可在Player或Processor物件的media stream中正確地取得Frame的位置。
l FrameGrabbingControl：可以從video stream中攫取video frame，且此Control也支援Render。
l FromatControl：提供查詢與設定格式的method。
l TrackControl：是屬於FormatControl的一種型態，用在個別的tracks處理processor object performs上(如：Effect、Codec、Render plug-ins)
l PortControl、MonitorControl：可以用來控制capture process。PortControl定義了用來控制屬於capture輸出設備的method。MonitorControl可以預覽capture完、encode完後的media data。
l BufferControl：在特別的objects上控制 buffer的處理。
l Codec control：可以控制軟、硬體的編、解碼器
Ø BitRateControl
Ø FrameProcessingControl
Ø FrameRateControl
Ø H261Control
Ø H263Control
Ø KeyFrameControl
Ø MpegAudioControl
Ø QualityControl
Ø SilenceSuppressionControl
Ueser Interface Components
Control提供可以存取user interface Component(讓使用者可以看得到媒體撥放的狀態)
Ø getControlComponent：這個method是繼承AWT Component下來的，可以讓我們增加applet’s presentation space或application window。
Ø getVisualComponent、getControlPanelComponent：這二個方法可以得到player執行的畫面和控制狀態畫面。
當然，如果你不使用這些內定的control component時，也可以自定自己的component
Extensibility
可透過二種方式繼承JMF的功能
１、經由實作自訂的處理元件（plug-ins）
２、透過實作the Controller, Player, Processor, DataSource, 或 DataSink
介面
這部分屬於plug-in部分，講到p.85時會重新提到
Presentation
在JMF中，播放的處理都是由Controller interface來完成。
Controller定義了物件的控制、播放或擷取時間性媒體的控制機制。
〞Controller〞：為一介面，繼承自Clock，提供來源配置的狀態訊息，事件的產生，並且於獲得物件的機制提供控制。
JMF API 定義二種型態的Controllers: Players and Processors。 Player or Processor 產生於特定資料來源時，且不再被重複使用去播放其他的媒體
上圖為JMF controllers
Players
Player：繼承自Controller interface，用於傳送和控制時間性的媒體資料，對於AWT元件的取得、媒體的處理控制，Player都有提供methods 處理傳入的媒體流，並精確地傳送出去。
DataSource： 通常傳入的media-stream 傳送給Player，至輸出裝置再依其型態將之播出
上圖為JMF player model
Player在處理上不提供任何的控制機制，但支援標準化的使用者控制，透過Clock 和 Controller的操作達成。
Player可分成六個狀態，Clock 介面定義二種基本的的狀態： Stopped 和 Started。為了易於資料來源的管理，Controller再將其中的Stopped階段細分成五個狀態： Unrealized、Realizing、 Realized、 Prefetching和 Prefetched.
上圖為player states
一般情況下，Player，必須經過每一階段直到Started的狀態下：
Ø Unrealized：當media Player被產生，但仍未知媒體資料時，稱之。
Ø Realizing ：player決定資料來源需求時，稱之。Realizing通常用於從網路上下載媒體資料。
Ø Realized ：當player完成Realizing後，即進入Realized狀態。至此階段已知媒體的需求及媒體播放型態的資訊。它也提供視覺化的元件 和控制，可以連接到系統的相關物件，但仍沒擁有任何資源，以預防其它的Player啟動。
Ø Prefetching ：準備開始播放媒體，player若播放位置被改變，則重新配置
Ø Prefetched：進入播放狀態
Ø Started：呼叫start，將Player放 至Started state。當Player物件的time-base time和媒體時間mapping後，開始播出。
Player提供TransitionEvents，可以從這個狀態移至另一個狀態中。ControllerListener 介面也提供可決定player位在哪個狀態下和適時地提出respond，例如：在Player或Process中呼叫asynchronous 的method，就需ControllerListener提供event來決定operation何時被完成。
Methods Available in Each Player State
為了防止race(猛轉，急速)的狀態產生，在Player的每個狀態中並非所有method都可以呼叫，下表為在Player的每個階段中，JMF定義的method使用限制說明，如果是不合法的method，player就會丟出exception。
| Method | Unrealized Player | Realized Player | Prefetched Player | Started Player |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 2-1: Method restrictions for players.
Processors
Processors也可以用來撥放media data。除了提供媒體撥放的設備外，Processor也可以透過DataSource輸出media data，以便讓其他的Player和Processor來呈現，更進一步地透過其他Processor來操作或傳送到其他的目的地，如檔案中。
Presentation Controls
參見Controls
Controller Events
ControllerEvents提供三種類的events：
Ø change notifications --- 像RateChangeEvent、DurationUpdateEvent、FormatChangeEvent表示可以改變Controller的一些屬性，例如：Player提供RateChangeEvent，當rate被改變時就呼叫setRate。
Ø transition events --- TransitionEvents允許我們的程式在Controller objects’s state下改變時得到respond，不論是從那個狀態到哪個狀態，player都提供transition events。
Ø closed events --- ControllerClosedEvents由ControllerEvent繼承下來，提供shutsdown功能；ControllerErrorEvent由ControllerClosedEvents繼承下來，當程式發生錯誤時，可以respond Controller發生的錯誤及將錯誤造成的影響減到最低。
上圖為JMF events
Processing
Processor：是一個從DataSource輸入，執行一些使用者自定的媒體資料處理，再將其媒體資料輸出的Player。 可傳送輸出資料至播放設備或DataSource（DataSource可如同再輸入至另一個Player或Processor，或輸入至DataSink）
上圖為JMF processors
媒體資料的處理可分割成幾個階段：
上圖為 Processor stages.
1. Demultiplexing：剖析input stream，若stream包含了多個tracks,則將之分離，例如：QuickTime 檔案分成audio and video tracks。無論是否有包含多樣的資料，皆會自動執行 Demultiplexing。
2. Pre-Processing： 對input stream中的tracks做特效(effect)的演算處理。
3. Transcoding ：轉碼；壓縮 ＝ ﹥解壓縮。
4. Post-Processing：對decoded tracks做特效(effect)的演算處理
5. Multiplexing：將由多個tracks的合併成單一data stream。例：將分離的audio and video tracks合併成單一個MPEG-1 data stream，可藉由setOutputContentDescriptor的 method定義輸出流的資料型態。
6. Rendering ：將播放媒體出來。
Processing執行的每個階段，由不同的processing component所構成，而這些processing component就是JMF plug-ins。假如Processor支援TrackControls的話，你可以選擇用何種plug-ins來處理track。JMF plug-ins分為五種types：
1. Demultiplexer—剖析媒體資料，例如：WAV, MPEG or QuickTime。若媒體流為多樣複合時，則分開個別處理
。
2. Effect—對媒體資料進行特效
3. Codec—進行編／解碼
4. Multiplexer—合併多個tracks 為單一個輸出流並傳送結果至輸出的DataSource
5. Renderer—處理track的媒體資料，並傳送至螢幕或喇叭
Processor States
介於Realizing state和Realized state之間，Processor提供二個額外備用的階段：Configuring和Configured。
Ø 當Configure被呼叫時，Processor進入Configuring 階段， 已連結DataSource、可對input stream做demultiplexes、讀取有關input data的格式資訊。
Ø 當Processor進入Configured階段時，已連結DataSource和決定出data format。此時ConfigureCompleteEvent 將可使用 。
Ø 當Realize被呼叫時，Processor將轉換到Realized狀態下，而Processor已被完全建構出來。
當Processor在Configured狀態下，getTrackControl將被呼叫進而從media stream中的track得到TrackControl objects。這些TrackControl objects可以使我們對media做一些特別的處理。
當立刻呼叫Realize時，會從 Unrealized Processor透過Configuring和Configured階段自動地轉換到Realized階段，當我們使用時，我們不可以透過TrackControls去configuring這個processing options，因為Processor設定是被使用的。
Methods Available in Each Processor State
下表為下表為在Processor的每個階段中，JMF定義的method使用限制說明
| Method | Unrealized Processor | Configuring Processor | Configured Processor | Realized Processor |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Processing Controls
透過TrackControl我們可以很明確地選擇Effect、Codec、Renderer pling-ins在我們所使用的track中，我們可以查詢PlugInManager找尋有哪些plug-ins可以使用。
Data Output
GetDataOutput可以傳回Processor object輸出的DataSource
Capture
於p.77會詳細提到
Media Data Storage and Transmission
DataSink通常從DataSource讀取媒體資料，並且傳送至目前的設備，而一些特殊的DataSink，可能透過網路寫至檔案或是RTP broadcaster來傳送。像Players, DataSink 物件則是透過manager使用DataSource去建構。DataSink可以使用StreamWriterControl來提供額外的控制來處理寫入檔案(詳細資料在p.74)。
Storage Controls
DataSink提供DataSinkEvent來記載每個狀態，DataSinkEvent將由reason code提供，或由DataSink提供幾個DataSinkEvent的subtypes：
Ø DataSinkErrorEvent：
Ø EndOfStreamEvent：
DataSink必須產一個DataSinkEvent
二個DataSinkEvent subtypes:
DataSinkErrorEvent：用於顯示當 DataSink 寫入資料時所發生的錯誤。
EndOfStreamEvent：顯示已成功被寫入的stream
為了 提供DataSink events，我們須實作DataSinkListener interface。
Extensibility
我們可以使用延伸的JMF來實作自訂的plug-ins，media handlers和data sources
Implementing Plug-Ins
若實作 Plug-Ins 介面，可直接存取或操作與媒體資料有關的Processor：
Ø Implementing Demultiplexer interface：能夠控制由multiplexed媒體流中分離出各個track。
Ø Implementing Codec interface：能夠轉換媒體資料，將未經處理過的媒體資料編碼成一個壓縮格式。
Ø Implementing Effect：能夠對媒體資料做自訂的處理
Ø Implementing Multiplexer interface：能夠指定個別的track組合成 single interleaved output stream。
Ø Implementing Renderer interface ：能夠控制資料的處理和傳送至輸出設備中展示。
透過TrackControl介面，可自定Codec, Effect, and Renderer plug-ins於Processor或產生一個具有ProcessorModel的Processor。必須註冊一個PlugInManager。一旦已註冊plug-in，則便會包含於plug-in的清單中，經由getPlugInList method傳回，且當Processor物件建立時可經由Manager存取
352
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
