1．1 電視接收機
接收機分為三種類型：增強型廣播、互動式廣播和多網（multi－network）。
1） 增強型廣播
傳統廣播電視的圖形、圖像和文本得到增強，並被作為廣播內容一部分下傳的Java程式控制。電視觀眾的互動式作用包括操縱螢幕顯示元素、多個音視頻流的選擇、動畫的控制、增強音視頻圖像的顯示切換。
增強型廣播沒有回傳通道。
2） 互動式廣播
接收機包括一個回傳通道，提供與前端或伺服器的通信。有能力提供電子商務、視頻點播服務或準點播服務。回傳通道的存在還使廣播節目得以按當地電視觀眾的喜好“量體裁衣”，並支持郵件和當地聊天通信服務。
3） 多網
提供多於一個廣播網路和回傳通道的接入，包括網際網路接入以及其它通信服務（如本地電話），這樣的接收機可以作為家庭電信中心。
1．2 電視專用應用程式
1．2．1 電子節目指南
EPG的主要功能是為電視觀眾提供現在可用的節目概觀，以及瀏覽電視節目表。通常在電視觀眾一旦發現要看的節目時，EPG也完成選擇功能。對於這類套用，實現性能和短的啟動時間對一個實際用戶的體驗是十分關鍵的。
1） 通用EPG
通用EPG一般駐留在接收機內，同等地處理所有內容。但是當節目提供者希望從某些特別節目中受益時，這些節目應該有更顯著的特徵。這樣的一個EPG需要使用廣泛的功能和接收機上所有可用的資源。這樣一個EPG的生命周期相當長，在某些情況里，一個EPG總是運行著。
2） 網路運營者的EPG
網路運營商或廣播公司可能希望為電視觀眾提供針對運營商服務特定的EPG。例如，各種運動節目或按次付費電影的提供商可以向電視觀眾提供特別描述這些服務特徵的EPG。實際上，它被服務商用作銷售和行銷的工具。這樣的EPG訪問接收機資源的能力可能受到限制，並可以被一個單獨的應用程式控制。
3） 事件專用EPG
是一種向電視觀眾提供某個特殊事件的EPG，例如體育事件。這類EPG允許相競爭的網路按特殊的事件分組提供服務，例如，一組廣播公司可能同意通過一個公共的EPG訪問為奧運會廣播提供服務。
1．2．2 節目專用應用程式
例如，隨一個遊戲配置的應用程式，或為體育事件提供互動式信息的應用程式。這些應用程式有幾個關鍵需求，例如，當電視觀眾切換頻道時，套用平台可以懸掛程式，套用平台也應支持同時運行多個節目專用程式對應用程式快速重新啟動和高速快取的支持也是十分重要的。
1．2．3 獨立應用程式
獨立應用程式獨立於正常電視節目運行。例如，一個股票自動收報應用程式從另一個網路取得數據，再在螢幕上顯示價格，用戶可能要將此應用程式鎖定在螢幕上，即使發生頻道切換也保持不變。另外，支持從任何一個用戶界面環境中分離出運行的應用程式可能是十分有用的。但是，需要指出的是這類電視觀眾模型為觀眾收視帶來許多不必要的複雜性。
1．2．4 廣告
廣告應用程式是一種非常短暫的應用程式。廣告應用程式的下載很可能提前於播放。在廣告終止時，應用程式將被停止或可能被丟棄，可能要求使用額外的應用程式快取策略。
2 Java TV API環境
Java TVAPI是Java平台的垂直擴充。Java平台由Java虛擬機和相關的API組成。垂直擴充提供了不屬於Java平台部分的，為特定市場或裝置類型而附加的APIs。典型的是PersonalJava應用程式環境，它支持JavaTV API，提供了電視接收機的Java平台。但是，Java TV API並非專門與PersonalJava綁在一塊的。
2．1 硬體環境
數位電視接收機從廣播流中獲取視頻、音頻和數據，並通過廣播媒介和數據管道處理它們。接收機以專用格式（稱為協定）從媒體中取得指令，使用專門設計的引擎解析它們。這些引擎包括：廣播協定引擎；網際網路協定引擎；視頻解碼引擎；軟體執行引擎。
數字接收機中使用的典型協定包括：具有流選擇的廣播協定棧；具有流選擇的網際網路協定棧（UDP，TCP，RTP）；遠程程式協定棧；視頻解碼協定（可能帶有解密）；圖像解碼協定；Java虛擬機，解析Java位元組碼的協定。
電視接收機相對其它計算裝置獨特的特性是接收機總是有一個廣播媒介管道的實例。廣播媒介管道的典型的組成方式包含有一組子系統，如一個數字調諧器、一個解復用器、一個條件接收模組、一組媒介解碼器和一個繪製子系統，媒介從這些系統中流過。JavaTV API並不要求所有這些子系統都存在。Java TVAPI提供了一種抽象，使程式設計師不需要考慮底層硬體環境的細節。無論如何，一個廣播接收機至少必須有一個廣播管道的實例。圖1給出了一個典型的例子,其工作過程如下：
（1） RF信號被調諧接收；
（2） 調諧的RF信號被解調成數位訊號，典型的是MPEG 2傳輸流；
（3） 傳輸流通過解復用器後分成多個流（常常是視頻、音頻和數據）；
（4） 視頻和音頻流被送入CA子系統，以確定接收授權和可能的數據解密；
（5） 解密的音頻和視頻流被送入解碼器，轉化為適合視頻和音頻輸出裝置使用的信號。
2．2 軟體環境
RTOS提供了實現Java VM和Java包所需的系統級支持。此外，RTOS和有關的設備專用庫通過一組設備驅動程式控制接收機。
2．2．1 Java TV API適用範圍
Java TVAPI被劃分成幾個主要的API組：服務信息和選擇APIs，廣播管道APIs，廣播數據APIs，應用程式生存周期APIs。
Java TVAPI使用Xlet應用程式模型定義數字廣播接收機里的應用程式的生存周期。這樣的應用程式被叫做Xlets。Xlets既可駐留在接收機里，也可被下載，它被應用程式管理器控制。每個接收機都有一個駐留應用程式管理器，能夠使每個Xlet通過一個在初始化時傳給Xlet的對象訪問它的環境。一個典型的應用程式管理器是由接收機製造商提供的系統應用程式的一個部分。
在運行時刻，Xlet取得並釋放資源，訪問顯示器，發現和選擇服務（代表一個電視節目）。每個服務的信息存儲在服務信息（SI）資料庫里，通過SI管理器訪問SI資料庫。
Java TV API由下列API組組成：
（1） 服務模型和服務信息
Java TVAPI將傳統的和互動式的電視節目表示為一組分立的圖像（presentations）或服務。服務信息APIs提供了對獲取服務信息的支持，包括用於選擇服務的服務定位器。
（2） 廣播管道模型
Java TVAPI利用Java媒體框架（JMF）規定廣播管道模型的體系架構。JMF定義了數據源和內容句處理器。在JMF概念中，一個調諧—解復用器—C/A子系統是一個數據源，而解碼器—幀緩衝器—音頻輸出是內容處理器。JMF提供了信號和處理器發現機制，而JavaTV API定義了取得可用資源的API。
（3） 控制廣播數據
廣播數據APIs提供了數據頻道訪問，傳送帶信令，選擇機制。
（4） 應用程式生存周期模型
2．2．2 Java 應用程式適用範圍
設計在廣播接收機里運行的應用程式可以利用應用程式環境包的優勢，以及內嵌的JavaVM的特性。這節說明應用程式環境包和VM提供的廣播接收機性能的較為重要的特徵。
PersonalJava應用程式環境典型地用於有限記憶體容量的裝置里，如數位電視接收機。為了達到說明的目的，使用PersonalJava應用程式環境作為Java平台，它包括幾個有用的包：
I/O：java．io包提供了通過java．io．InputStream和java．io．OutputStream以及它們的子集在位元組流層次上的數據存取。
Networking： java．net包提供了通過類java．net．URL，java．net．InetAddress和java．net．Socket訪問網路函式。
Graphics toolkit/Rendering： java．awt通過使用類java．awt．Canvas，java．awt．Font和java．awt．Scrollbar提供了再現（rendering）和圖形工具。
System functions（執行緒、安全、事件等）：類，如java．lang．Thread和java．util．EventObject。
Utilityfunctions（列表、日期/時間等）：類，如java．util．Hashtable和java．util．Calendar。
2.2.3 抽象視窗工具箱（AWT）
AWT的設計提供了建立用戶界面部件（一組基本的部件）可行的基礎。Java TVAPI要求環境支持用於創建應用程式專用的視窗小部件的基礎AWT。
1） 環境必須支持java．awt．image包，該包處理並呈現圖像。
2）環境不要求支持java．awt．datatransfer包，該包創建一個剪貼簿。
3） 環境必須支持類和接口，該類和接口管理在螢幕上部件的排列：
java．awt．LayoutManager
java．awt．LayoutManager2
java．awt．BorderLayout
java．awt．CardLayout
java．awt．FlowLayout
java．awt．GridLayout
java．awt．Toolkit
4）運行環境沒有要求提供下面的用於螢幕管理的類和接口：
java．awt．GridBagConstraints
java．awt．GridBagLayout
5 環境必須支持用於輕便部件創建的類和接口：
java．awt．Adjustable
java．awt．ItemSelectable
java．awt．MenuContainer
java．awt．Canvas
java．awt．Component
java．awt．Container
java．awt．Dialog
java．awt．Frame
java．awt．LightweightPeer
java．awt．Panel
java．awt．Window
java．awt．AWTError
java．awt．AWTException
java．awt．IllegalComponentStateException
6） 環境沒有要求支持下面的組成小配件集的接口和類，Java TV API希望大部分應用程式提供自己的小配件集：
java．awt．Button
java．awt．Checkbox
java．awt．CheckboxGroup
java．awt．Choice
java．awt．Label
java．awt．List
java．awt．MenuComponent
java．awt．MenuItem
java．awt．Panel
java．awt．ScrollPane
java．awt．TextArea
java．awt．TextComponent
java．awt．TextField
7） 環境沒有要求支持下面的接口和類，它們在PersonalJava 1．1規範中是可選的：
java．awt．PrintGraphics
java．awt．CheckboxMenuItem
java．awt．Cursor
java．awt．FileDialog
java．awt．Menu
java．awt．MenuBar
java．awt．MenuShortcut
java．awt．PopupMenu
java．awt．PrintJob
java．awt．ScrollBar
8) 環境必須支持與媒介有關的接口和類：
java．awt．Shape
java．awt．Color
java．awt．Dimension
java．awt．Font
java．awt．FontMetrics
java．awt．Graphics
java．awt．Image
java．awt．Insets
java．awt．MediaTracker
java．awt．Point
java．awt．Polygon
java．awt．Rectangle
java．awt．SystemColor
9) 環境必須支持下面定義了螢幕事件（互動式設備事件和焦點事件）的接口和類：
java．awt．AWTEvent
java．awt．AWTEventMulticaster
java．awt．EventQueue
java．awt．event．ActionEvent
java．awt．event．ActionListner
java．awt．event．AdjustmentEvent
java．awt．event．AdjustmentListner
java．awt．event．ComponentAdapter
java．awt．event．ComponentEvent
java．awt．event．ComponentListner
java．awt．event．ContainerAdapter
java．awt．event．ContainerEvent
java．awt．event．ContainerListner
java．awt．event．FocusAdaptor
java．awt．event．FocusEvent
java．awt．event．FocusListner
java．awt．event．InputEvent
java．awt．event．ItemEvent
java．awt．event．ItemListner
java．awt．event．KeyAdaptor
java．awt．event．KeyEvent
java．awt．event．KeyListner
java．awt．event．MouseAdaptor
java．awt．event．MouseEvent
java．awt．event．MouseListner
java．awt．event．MouseMotionAdaptor
java．awt．event．MouseMotionListner
java．awt．event．PaintEvent
java．awt．event．TextEvent
java．awt．event．TextListner
java．awt．event．WindowAdaptor
java．awt．event．WindowEvent
java．awt．event．WindowListner
10) 環境必須支持在PersonalJava規範中定義互動式設備優選項的接口：
com．sun．java．awt．NoInputPrefered
com．sun．java．awt．KeyboardInputPrefered
com．sun．java．awt．ActionInputPrefered
com．sun．java．awt．PositionalInputPrefered
2.2.4 圖形，用戶界面和視頻
用戶界面部件是由套用環境底層提供的小部件創建的。視頻被java．awt．Componet壓縮。這使得可以與其它小部件相同的方式操縱視頻圖像的大小和位置。
3 服務和服務信息
一個服務是用於接收機播出的內容的代表。服務可以用於播出選擇。服務特徵信息存儲在SI資料庫里。SI代表了一個視頻/音頻/數據流（如MPEG2傳輸流）的目錄。
現有許多不同的SI格式，但應用程式並不需要了解使用什麼樣的SI標準。
3．1 服務和服務信息定義
服務是由內容供應商定義在一起的一組服務部件。每個服務都有相關的服務信息（SI），每個服務必須設計接收機可用的服務信息。一個SI項定義了一個服務性質。
服務信息（SI）是關於一個服務與一個或多個服務相關的信息。包括播放服務的服務部件並將其作為一個連貫的整體顯示出來所需的基本信息。
服務部件是一種“單一媒體”元素，如一個視頻流，一個音頻流，一個Java應用程式，或不需要額外信息就可以表示的其它數據類型。一個或多個服務部件將包含在一個服務里，一個服務部件可以被多於一個的服務共享。
服務定位器是分辨一個服務所需的物理地址和表示方法的信息。
SI資料庫是電視應用程式可存取的存儲服務信息的資料庫。SI資料庫可以將服務定位器分解為與服務相關的元數據（meta data）。
SI工廠是創建SI管理器對象的類
SI管理器是報告可用對象變化的一個對象。SI管理器是主要的底層SI資料庫訪問點。在電視接收機上只有一個SI管理器對象。
SI元素是一個代表一個服務對象里的元素的對象。
SI描述是用於表示一個專用SI元素的附加信息的一個對象。
3．2 資料庫視圖
SI資料庫對象模型允許建立各種基於應用程式需要的資料庫視圖。依靠規定一個具體的視圖，應用程式可以只涉及到SI資料庫的子集。SI資料庫視圖是：Util，Nagigation，Guide和Transport。
圖2描述了SI資料庫視圖之間的關係。Util視圖代表實例化對象的工具，Navigation視圖代表用於定位現有服務的對象。Guide視圖代表用於EPG的對象，包括節目時間表、單個節目事件和節目分級。Transport視圖代表MPEG2傳輸機制。
大部分數位電視接收機不能夠快取所有的SI數據。接收機只快取SI數據的子集，由大部分有用的信息組成。當需要檢索記憶體內沒有的數據時，接收機將分析傳輸流。由於訪問傳輸流可能需要花費顯著的時間，這個模型提供了異步訪問不在快取里的信息。
SI信息通常在DVB，TDT和TOT信息里包含與系統時間相關的信息。接收機時間可以與當前調諧到的頻道的系統時間同步。
3．2．1 Util視圖
Util視圖具有幾個功能：創建SI管理器對象的SI工廠；事件通知機制，用於在傳輸流監測SI實體的變化和事件傳送的異步請求；一般的擴展機制；異常。
由於大部分SI對象是沒有構造器的接口，應用程式無法實例化一個實現規定接口的對象。為了得到一個實現SI管理器接口的對象實例，工廠類提供了取得SI管理器實例的靜態方法。假定在接收機里只有一個SI管理器，將來需要多個SI管理器時，工廠機制允許擴展。
應用程式可用下面的對象註冊為收聽者，三個傳送發生變化的具體對象細節的適當事件會通知它們。SIChangeListener對象和SIChangeEvent對象支持標準的Java事件模型。為了取得新的信息，應用程式需要再生特別的對象組，用於收聽的這類對象是：
SIManager對象，報告對SI管理器有用的對象所發生的變化。
TransportInformation對象，報告在由TransportStreamInfo對象、NetworkInformation對象、BouquetInformation對象和其它相關對象所表示的網路定義相關表里檢測到的變化。
ProgramSchedule對象，報告在任何一個時間表里的ProgramEvent對象所檢測到的變化。
注意，除非接收機對同類新舊錶做逐項的比較，實際上實現上面定義的事件是相當的困難的。接收機可以選擇僅傳送高層事件，如果需要讓應用程式更新多個對象。
Util視圖也提供了異步傳送數據的機制，這一功能是由SIRequest，SIRetrievalEvent和SIRetrievalListener提供的。如果僅是異步數據可用，將提供SIRequest對象取消請求，將請求與SIRetrievalEvent聯繫起來，它將最終傳送所請求的數據或一個失敗的指示。異步方法的調用者（命名為“retrieveXXX”）必須註冊為獲取事件的收聽者。
3．2．2 Navigation視圖
Navigation視圖代表兩種功能：有權使用每個服務對象的最小信息，也提供了請求更詳細解說的機制；一種歸類機制，按照各種歸類標準將服務對象分類。
主要的導航功能由下列對象表示：SI管理器是底層SI資料庫的主要通路。它可以根據ServiceFilter對象代表的選擇標準，產生稱為ServiceCollection服務對象的集合。集合於是可以被用作或按頻道號或按頻道名排序，在服務中導航。基礎類ServiceFilter可被用作產生預設集合（無過濾準則），代表所有接收機已知（已安裝）的服務。
服務對象自己包含的僅是導航需要的最小的信息（如定位器，頻道名和號），服務的附加信息包含在ServiceDescription對象里。ServiceDescription對象也提供了某些與C/A相關的信息（通過CAIdentification接口），傳送機制和頻道信息最近被更新的時間。
一組頻道部件與服務對象相聯繫，如果有可用的信息，也可以與專門的ProgramEvent對象聯繫。當前的ProgramEvent對象提供了與當前節目攜帶的服務對象相同的部件。
3．2．3 Guide視圖
Guide視圖代表了支持EPG的功能。這個視圖提供的EPG帶有兩個相關的信息組：每個頻道上的節目表和與頻道或具體節目事件相聯繫的分級信息。ProgramSchedule對象可被用於檢索當前播放的節目，隨後的節目，以及以後一個特別時間周期內任何其他可用的節目。每個ProgramEvent對象可用其名字、起始時間、終止時間、說明、價錢和其它有關信息查詢。
分級有關信息是按分級範圍組織（如國家、國家組或任意的地理區域），每個區域可以由多個分級尺度，如MPAA分級，FCCTV分級，DVB基於年齡的分級，針對廣播公司的分級。每個尺度包含有多個級別，每個ProgramEvent對象按照所有支持分級區域的這些級別中的一個貼上標籤。
3．2．4 Transport視圖
Transport視圖代表了物理媒介的信息，如MPEG2，傳送SI數據所描述的內容。SI管理器提供了對抽象TransportInformation對象訪問通路，在MPEG情況下，被擴展為代表MPEG2復用器的TransportStreamCollection。通用的TransportInformation對象可以被擴展為支持其他類型傳輸傳送機制，如IP。
4 服務選擇
服務選擇API的目的是使應用程式以一種簡單高級的方法達到對服務播放的控制。它的特別之處在於大量隱藏了構成服務的部件特性。一個應用程式可促使一個服務出現而不需要對其音頻、視頻或字幕分量的理解。也可以促使一個服務出現而不需要搞清該服務是否有一個相關的應用程式，也不需要自行運行這樣的應用程式。它可以被看作是將某些對調諧、服務信息、媒體重放、廣播檔案傳輸和應用程式管理器的訪問捆綁成一個單一方法的調用。
4．1 服務選擇定義
service context是一種播放服務的環境。接收機可以支持一個或多個服務環境（service context）。
service componentpresenter是接收機里的一種實體，負責表示一個或多個服務分量。一個單獨的服務分量表示器可以表示幾個共有同一時鐘的服務分量。多個服務分量表示其可以共享同一個服務分量作為輸入。服務分量表示器的生存周期不超過所表示的服務的生存周期。單個的服務分量表示器在服務的生存周期內也可以有自己的生存周期。例如，在一個服務里的應用程式可以用同一服務里的另一個應用程式取代自己。
application componentpresenter是接收機里的實體，負責表示對應一個電視應用程式的一個或多個服務分量。該類繼承了服務分量表示器類。
4．2 服務選擇API概述
ServiceContext類代表一個服務出現的環境。接收機可以嚴格地限制所支持的該類對象的數目，甚至只有一個實例。ServiceContext對象的Select（）方法促使服務環境嘗試表現一個服務。這個選擇是異步的，完成後通過一種事件收聽機制發出通知。選擇一個服務失敗，如果在select（）被調用時即確定，則通過一個異常報告，或者如果在稍後時間才確定，則通過一個事件報告。一旦一個服務環境正在表現一個服務，可以得到該服務的各種信息，包括服務分量的定位器。
當一個ServiceContext對象出現在一個服務里，方法getServiceComponentPresenters（）返回參數選擇到正在表現各種服務分量的“引擎”或“播放器”。對於實時的媒體，如音頻、視頻和字幕、JMF播放器被送回。對於共有同一時鐘的視頻，音頻和字幕分量，返回一個JMF播放器。
4．3 服務環境狀態模型
ServiceContext可以存在於四種狀態中的一個：表現，不表現，表現懸掛，破壞。初始的狀態是不表現。在任何狀態，可以調用選擇方法。假定沒有出現異常，ServiceContext進入表現懸掛狀態。在狀態轉換中不產生事件。
如果成功地完成調用select，或者產生一個NormalContentEvent或一個AlternativeContentEvent事件，並且ServiceContext移到表現狀態。如果服務選擇失敗，產生一個SelectionFailedEvent事件。如果在select調用前是不表現狀態，ServiceContext回到該狀態，產生一個PresentationTerminatedEvent。如果調用前狀態是表現，ServiceContext視圖回到先前的狀態，可能的話將產生NormalContentEvent或AlternativeContentEvent事件，若不可能ServiceContext返回一個PresentationTerminatedEvent事件。
服務表現被終止時，進入不表現狀態，並由PresentationTerminatedEvent報告。可以通過一個應用程式調用stop方法，或因為環境裡的某些變化造成無法繼續表現而開始終止服務表現。
通過調用destroy方法而進入破壞狀態。一旦進入這個狀態，ServiceContext不能再被用於任何目的。一個被破壞的ServiceContext一旦任何應用程式所有對它的引用被撤銷，將被作為碎片收集。
4．4 服務環境資源管理
一個服務環境需要scarceresources（如，MPEG視頻解碼器或調諧器），以表示服務。在服務環境裡執行的應用程式可以獲得權利訪問這些資源，以使用低級的API修改或監控服務的表示。通常，JavaTV API並不定義資源管理政策。但是，為了實現互操作性，不得不為服務制定政策規則。下面是這類規則的例子。
當select方法使用時，如果服務環境處在表示狀態，則那些可以用於表示新內容的scarce資源被重用，而不會被釋放。任何未用於表示新內容的scarce資源被釋放。
所有運行在服務環境裡的應用程式可以取得權力訪問被服務環境用於表示服務的資源。
如果在兩個服務中出現同一個應用程式，並在兩個服務間選擇了一個服務，應用程式將不會被停止和重啟動，它將繼續執行；它只在服務不出現該應用程式時才終止。
如果一個資源正被一個特別的服務環境用於表現一個服務，該服務環境將保證新選擇的服務訪問這些資源。
當一個服務的表現終止（或者因為一個新服務被選擇或因表現被終止），被終止的服務里的任何應用程式將失去一些資源。這些資源並不限於服務所要求的資源（如螢幕訪問）。
Java TVAPI故意對服務環境間的資源分配政策靜默。一個可能的政策例子是越近的select方法調用具有超過舊的調用的優先權，即使是在不同的服務環境間。
5 Java媒體框架和廣播管道
Java TV API使用JMF APIs管理廣播媒體管道。JMFAPIs通過定義一組APIs和與傳輸機制，傳輸協定及媒體內容形態無關的用於顯示時基媒體的框架，為Java TV API打下了基礎。
JMF為時基媒體數據定義了javax．media．Player，擴展了MediaHandler。一個播放器對象包裹了必須的狀態機，以獲取資源和管理繪製時基媒體流。一個播放器對象也提供了對繪製工具的各種控制（如音量和視頻畫面控制）。對用於音頻/視頻流的播放器情況，一個包含流的視頻部分的GUI部件對象可以從播放器里得到。
5．1 JMF控制
一個JMF控制是從正在運行的播放器得到的對象。對象實現了avax．media．Control接口，也將實現用於對播放器正在管理的媒體的某些方面的控制的至少一個接口。例如，許多播放器提供了支持avax．media．GainControl接口的對象，以控制播放器音頻增益。JavaTV API包括了DAVIC定義的控制。
5．2 JMF資源事件
JMF支持異步資源分配，管理和控制機制。通過使用資源分配和同步方法（realize，prefetch，start，deallocate，close）控制一個播放器。方法完成由事件指示。JavaTV API要求播放器支持由DAVIC定義的資源事件。
5．3 JMF同步
JMF承認媒體和時鐘間同步關係規範，時鐘作為表現媒體的同步主控者。同步原語的細節在JMF文檔里描述。一個JMF播放器繼承了時鐘類，提供取得當前媒體時間的方法。時鐘也提供了取得被稱為時基（time－base）的對象。時基代表時鐘同步主控者，具有規定媒體時間和時基間同步點的方法，以及控制媒體時間和時基間關係的參數。
Java TVAPI支持DAVIC定義的新機制，在特定媒體時間傳送事件。一個可以支持這樣事件傳送的播放器提供MediaTimeEventControl接口。
5．4 JMF播放器體系架構和廣播管道
JMF用javax．media．Player類的對象控制媒體數據的回放。有兩種不同的部件：協定處理器和媒體處理器。播放器是一種媒體處理器。協定處理器是一種數字源；媒體處理器是數據消費者。JMF定義了抽象類javax．media．protocol．DataSource作為協定處理器的基類，為所有內容處理器定義了接口javax．media．MediaHandler。javax．media．Player擴展了MediaHandler。
JMF的大部分實現假定，每次一個新媒體流要再現時，應該創建一個完整的解碼管道。在桌面環境，這是一個自然的想法。通常，對每個媒體流需要個別的網路連線，每個連線有獨立的管道條件，需要與連線源（如伺服器）有一個複雜的握手過程。
在一個廣播環境，就不是這種情況。廣播網路的接口可看作一個多個復用器模型。這樣一個模型結合了實際的調諧器（第一個復用器）和解復用（第二個復用器）。這樣對一個廣播網路接口的控制由調諧（初級復用器）和流選擇（二級復用器）組成。對傳統的視頻廣播，合成的管道總是相同的：二級復用器與一個音/視頻解碼器連線。這樣，頻道變化不要求獲得新的管道資源（調諧器，解復用器，編碼器，螢幕），僅僅是向網路接口發出帶調諧和流選擇參數的命令。
JMF可以用這一管道模型(圖3)，而不需要對現有的接口修改。播放器對象仍然代表整個的管道，DataSource代表對網路的連線。為了適應上述的廣播選擇機制，要求少量增加。
目標是創建管道，以有效地使用JMF管道抽象調諧。
