电视接收器

JAVA TV
编辑
锁定
讨论
上传视频
特型编辑
电视接收器
同义词
电视接收器一般指JAVA TV
本词条缺少概述图，补充相关内容使词条更完整，还能快速升级，赶紧来编辑吧！
相关视频查看全部
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管道抽象调谐。