JP2000022741A - 選択可能なデパッケタイザ構成 - Google Patents

選択可能なデパッケタイザ構成

Info

Publication number
JP2000022741A
JP2000022741A JP34352498A JP34352498A JP2000022741A JP 2000022741 A JP2000022741 A JP 2000022741A JP 34352498 A JP34352498 A JP 34352498A JP 34352498 A JP34352498 A JP 34352498A JP 2000022741 A JP2000022741 A JP 2000022741A
Authority
JP
Japan
Prior art keywords
player
media
data
time
depacketizer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
JP34352498A
Other languages
English (en)
Other versions
JP2000022741A5 (ja
Inventor
Emma Patki
パトゥキ エマ
Daniel C W Wong
シー．ダブリュー．ウォン ダニエル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of JP2000022741A publication Critical patent/JP2000022741A/ja
Publication of JP2000022741A5 publication Critical patent/JP2000022741A5/ja
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

(57)【要約】 （修正有） 【課題】 選択可能なデパケット化モジュールを使用し
てデータストリームをデパケット化する。 【解決手段】 ＲＴＰセッション・マネージャ２０４は
ネットワークからＲＴＰパケットを受け取り解析／処理
しこの種のデータを用いてデパッケタイザ・モジュール
２０６を探す。特定のデパッケタイザを探すためネーミ
ング規則を守る。デパッケタイザは明確に定義されたイ
ンタフェースを用い、解析され読取り可能なデータを出
力する。インタフェースは全関連情報をデコーダに渡
し、デパケット化データストリームを解凍する。デパッ
ケタイザが、あらゆるコーデック固有の問題を扱うか
ら、セッション・マネージャはコーデックの詳細を知る
必要はない。デパッケタイザが、この定義済みフォーマ
ットでデータをハンドラ２０５へ出力する。デパッケタ
イザはデータ自体を、定義済みフォーマットで出力で
き、ハンドラへ渡しそのインテグレーションをシームレ
スとする。

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明はコンピュータネットワー
ク上でデータパケットを送受信する分野に関するもので
ある。
【０００２】本特許文書の開示の一部には著作権保護を
必要とする資料内容が記載されている。本著作権所有者
は特許商標庁の特許ファイル又は特許記録に記載されて
いる本特許文書又は本特許開示内容を誰かが現物通りに
複写することに対して何等異議を唱えるものではない
が、それ以外の点ではいかなる場合であってもすべての
著作権を保有している。
【０００３】
【従来の技術】コンピュータはビデオデータ、オーディ
オデータ、及び他のデータを処理し、再生し、表示する
ためにしばしば用いられる。このデータは記憶装置，オ
ンラインサービス，ＶＣＲ，ケーブルシステム，テレビ
放送用チューナ等のようなデータソースから得られる。
ビデオデータやオーディオデータはメモリ集約的であ
り、すなわち、このようなデータはコンピュータシステ
ムによる保存と利用のために大メモリ容量が必要であ
る。さらに、このような大量のデータをリモートデータ
ソースからクライアントコンピュータに送る作業は時間
的にも不経済であって、ともかくこのようなデータを提
供できることの限定要因となりかねない。
【０００４】データを送る時、伝送帯域幅とメモリの要
求値を減らすために様々な圧縮方式(compression schem
e)が開発されて、情報を記憶させるのに必要な記憶空間
を小さくし、かつ情報を伝送するのに必要な帯域幅を小
さくしている。従来技術のビデオ圧縮方式には、Motion
JPEG，ＭＰＥＧ−１，ＭＰＥＧ−２，Indeo，Quicktim
e，True Motion-S，CinePak等がある。同様に、オーデ
ィオデータにもいくつかの圧縮方式がある。
【０００５】インターネットや World Wide Web 等のコ
ンピュータネットワークで圧縮方式を利用してビデオデ
ータやオーディオデータを送ることがとくに重要であ
る。プロバイダはビデオデータやオーディオデータを含
むマルチメディアコンテンツを提供し、かつインターネ
ットを使ってこのようなコンテンツを送ることを望んで
いる。もしデータを圧縮しなければ伝送時間が長すぎる
ことになる。さらに、圧縮せずにビデオデータやオーデ
ィオデータをリアルタイムでストリーミングすることは
不可能である。
【０００６】ＲＴＰはインターネット等のネットワーク
上でビデオデータやオーディオデータを送るために用い
られる Real Time Transport プロトコルである。一般
に、オーディオデータ又はビデオデータは特定の圧縮技
術を用いて圧縮され、圧縮されたデータストリームは有
線で送信するためにさらに小さいパケットに分割され
る。この処理は「パケット化(packetization)」と呼ば
れ、またその逆の処理、すなわちネットワーク・パケッ
トを連続するバイトストリームに組み立てることは「逆
パケット化(depacketization)」と呼ばれる。ＲＴＰセ
ッション・ハンドラはパケット化されたデータの受取り
と逆パケット化をクライアントコンピュータでコントロ
ールする機構である。従来技術では逆パケット化方式は
ＲＴＰセッション・ハンドラのコードの一部である。こ
れは可能なあらゆるパケット化方式をＲＴＰセッション
・ハンドラがあらかじめ知っていることを要求するので
らせるように求めているから不利である。このことか
ら、新規のＲＴＰセッション・ハンドラの作成を求めず
に新規のパケット化方式を追加することが困難となる。
もしこのような逆パケット化が別のモジュールとして存
在するとすれば、効果的である。
【０００７】
【発明の概要】選択可能な逆パケット化モジュールを使
用してデータストリームを逆パケット化することができ
る方式が提供される。ＲＴＰセッション・マネージャは
ネットワークからＲＴＰパケットの受け取り、それらの
パケットの解析／処理に対応できる。ストリーム上で受
け取っるタイプのデータを用いてデパッケタイザ・モジ
ュールを探し出(locateed)す。こうして、特定のデパッ
ケタイザを入力されたデータストリームの圧縮に用いら
れるコーディング・デコーディング方式（「コーデッ
ク」）に応じて実行時に探し出す。特定のデパッケタイ
ザを探し出すために、ネーミング規則に従う。デパッケ
タイザはすでに解析された読取り可能な形式のデータを
受け取る。デパッケタイザはこのデータをフレームに組
み立て、好適な実施例のインタフェースによりフレーム
データをハンドラに出力する。このインタフェースはい
くつかのコーデックを包括するように設計されている。
このインタフェースはすべての関連情報をデコーダに渡
し、そこで逆パケット化された実際のデータストリーム
をデコンプレスする。デパッケタイザがあらゆるコーデ
ック固有の問題を扱うからセッション・マネージャはコ
ーデックの詳細についてはまったく知る必要はない。
【０００８】デパッケタイザが出力するデータについて
デフォルト・フォーマットが述べられている。デパッケ
タイザがこの定義済みフォーマットでデータを出力でき
るようにしている。しかしながら、デパッケタイザはデ
ータ自体をある定義済みフォーマットで出力できるよう
にもしている。このようなデータはこのフォーマットを
心得ているハンドラに提供されてデパッケタイザの統合
がシームレスとなっている。こうして、デパッケタイザ
はいくつかの定義済みインタフェースを実行する限りい
つでも使用可能にされる。デパッケタイザによりパケッ
ト紛失，誤り回復，及び他のデータについて専用のイン
テリジェンスを利用でき、これにより様々な専有コーデ
ックをＲＴＰセッション・マネージャの内部で使用で
き、ＲＴＰセッション・マネージャのプロトコル状態管
理コードの利用を可能にする。
【０００９】
【実施例】本発明は選択可能なデパッケタイザを提供す
る方法及び装置である。以下の説明では多数の具体的詳
細を述べて本発明の実施例をさらに徹底的に説明する。
しかしながら、本発明はこのような具体的詳細がなくて
も実施可能であることは当業者には明らかとなる。他の
例では本発明を不明瞭にしないように公知の特徴は詳述
しない。
【００１０】ＪＡＶＡ 本発明の好適な実施例は Sun Microsystems, Inc. of M
ountain View, California で開発された Java言語で実
施される。以下は Java 及びオブジェクト指向プログラ
ミング(Object Oriented Programing)のバックグラウン
ドである。
【００１１】Java はオブジェクト指向プログラミング
言語である。オブジェクト指向プログラミングはいくつ
かの基本ビルディング・ブロックを組み合わせてそれら
の基本ビルディング・ブロック間の関係を作成すること
により、コンピュータプログラムを作成する方法であ
る。オブジェクト指向プログラミング・システムにおけ
るビルディング・ブロックはオブジェクト(objects)と
呼ばれる。オブジェクトはデータ構造体（インスタンス
変数：instance variable）とこのデータを使用する
か、又はデータに影響を与えることのできる操作（メソ
ッド:method）をまとめたプログラミング単位である。
したがって、オブジェクトはデータとそのデータで行う
ことのできる１つ以上の処理又は手続きから成ってい
る。データと操作を単位ビルディング・ブロックに結合
することは「カプセル化(encapsulation)」と呼ばれ
る。
【００１２】オブジェクトはメッセージ(message)を受
け取るとそのメソッドの１つを行うように指示される。
メッセージはあるメソッドを実行するようにオブジェク
トに指示するコマンド又はインストラクションである。
メッセージはメソッド選択（ネーム）とオブジェクに送
られる複数の引数(argument)から構成される。メッセー
ジは受け取るオブジェクトにどのような操作を行うべき
か知らせる。
【００１３】オブジェクト指向プログラミングの１つの
利点はメソッドを呼び出す方法にある。メッセージがオ
ブジェクトに送られる時にはこのメッセージはあるメソ
ッドを実行する方法をオブジェクトに指示する必要はな
い。オブジェクトがメソッドを実行するように要求する
ことだけが必要である。このことから、プログラム開発
が非常に簡単になる。
【００１４】オブジェクト指向プログラミング言語はお
もにクラス(class)方式に基づいている。クラスベース
のオブジェクト指向プログラミング方式は一般に、リー
バーマン(Lieberman)の"Using Prototypical Objects t
o Implement Shared Behavior in Object-Oriented Sys
tems," OOPSLA 86 Proceedings, September 1986, pp.2
14-223 に説明されている。
【００１５】クラスは一般にそのクラスについてインス
タンス変数もメソッドも含むオブジェクトタイプを定義
している。オブジェクト・クラスはオブジェクトの特定
のインスタンスを作成するために使用される。オブジェ
クト・クラスのインスタンスはそのクラスに定められた
変数とメソッドを含む。同一クラスの複数のインスタン
スはオブジェクト・クラスから作成できる。オブジェク
ト・クラスから作成される各インスタンスは同一タイプ
又は同一クラスのものと言える。
【００１６】クラスの階層はオブジェクト・クラスの定
義がサブクラスを１つ以上有するように定義できる。サ
ブクラスはその親(parent's)（及び祖父母(grand paren
t's)等）の定義を継承(inherit)する。この階層におけ
る各サブクラスはそのペアレント・クラスで指定された
役割に追加するか又はその役割を変更することができ
る。
【００１７】例えば、従業員(employee)オブジェクト・
クラスは「名前(name)」と「給料(salary)」のインスタ
ンス変数及び set_salaryメソッドを含むことができ
る。組織内の各従業員については従業員オブジェクト・
クラスのインスタンスを作成又は実体化することができ
る。各オブジェクト・インスタンスは"employee"タイプ
のものと言える。各従業員オブジェクト・インスタンス
は「名前」と「給料」のインスタンス変数及び"set_sal
ary"メソッドを含む。各従業員オブジェクト・インスタ
ンスの「名前」と「給料」の変数に対応づけられる値に
は組織内の従業員の名前と給料が入っている。メッセー
ジを従業員の従業員オブジェクト・インスタンスに送っ
て、set_salaryメソッドを呼び出して従業員の給料（従
業員の従業員オブジェクトの"salary"変数と関連した
値）を変更することができる。
【００１８】オブジェクトはオブジェクト指向プログラ
ミング環境において用いられる総称であって、関連する
コードと変数を含むモジュールを指す。ソフトウェア・
プログラムはオブジェクト指向プログラミング言語を用
いて書くことができ、それにより、このプログラムの機
能をオブジェクトを用いて実現する。
【００１９】ソフトウェア・アプリケーションの開発は
ソフトウェア・アプリケーションのコンポーネントに対
してアプリケーション・プログラミング・インタフェー
ス（Application Programing Interface:ＡＰＩ）を設
定することにより、独立した区分的なやり方で実行する
ことができる。ＡＰＩは他のコンポーネントがアクセス
できる特定のコンポーネントのメソッド及びこれらのメ
ソッドを呼び出すフォーマットをさす。これらのメソッ
ドの特定の実現は特定のコンポーネントの設計に関して
のみ重要である。各コンポーネントはそのそれぞれのＡ
ＰＩと任意の内部機能を実装し、またそのアプリケーシ
ョンの他のコンポーネントのＡＰＩとインタフェースす
るように、個々に設計されている。一般に、これらのコ
ンポーネントはアプリケーションを形成する１つ以上の
オブジェクトを含む。
【００２０】オブジェクト指向プログラミング言語の例
としては C＋＋と Java がある。プログラムをマシン依
存の実行可能プログラム・コードにコンパイルする大部
分のプログラミング言語とは異なって、Java のクラス
はマシン依存の仮想マシンで実行されるマシン独立のバ
イトコード・クラスのファイルにコンパイルされる。こ
の仮想マシンはバイトコード・クラスのマシン独立と、
基底コンピュータハードウェアのマシン依存のインスト
ラクションセットとの間で、あるレベルの抽象化を行
う。クラス・ローダは必要に応じてバイトコード・クラ
スのファイルをロードする役割をし、またインタープリ
タ又はジャストインタイム・コンパイラはバイトコード
をマシンコードに変換できるようにしている。
【００２１】［コンピュータ実行環境の実施例（ハード
ウェア）］本発明の実施例は図１に例示されるコンピュ
ータ１００のような汎用コンピュータで実行されるコン
ピュータ読み取り可能プログラムコードの形を取るコン
ピュータ・ソフトウェアとして実施できる。キーボード
１１０とマウス１１１は双方向システムバス１１８に結
合されている。このキーボードとマウスはユーザ入力を
コンピュータシステムに導入し、そのユーザ入力を中央
処理装置（CentralProcessing Unit:ＣＰＵ）１１３に
伝えるためのものである。マウス１１１とキーボード１
１０に加えて又はそれらの代りに他の適切な入力装置を
使用できる。双方向システムバス１１８に結合されたＩ
／Ｏ（入出力）装置１１９はプリンタ，Ａ／Ｖ（オーデ
ィオ／ビデオ）Ｉ／Ｏ等のようなＩ／Ｏエレメントを表
す。
【００２２】コンピュータ１００はビデオメモリ１１
４，メインメモリ１１５，大容量保存装置１１２を含
み、それらはすべて、キーボード１１０，マウス１１
１，ＣＰＵ１１３と共に双方向システムバス１１８に結
合されている。大容量保存装置１１２は磁気式，光学
式，又は光磁気式の保存システム等の固定媒体も取外し
可能媒体又は他の任意の利用できる大容量保存技術等も
含むことができる。バス１１８は例えばビデオメモリ１
１４又はメインメモリ１１５にアドレスするために３２
本のアドレス線を収容できる。さらに、システムバス１
１８には、例えば、ＣＰＵ１１３，メインメモリ１１
５，ビデオメモリ１１４，大容量保存装置１１２等のコ
ンポーネント間でデータを転送するための３２ビットの
データバスも含まれる。もう１つの方法としては個別の
データ及びとアドレスラインの代りに多重データライン
／アドレスラインを使用できる。
【００２３】本発明の一実施例ではＣＰＵ１１３は Mot
orola(R)で製造されたマイクロプロセッサ、例えば６８
０X０プロセッサ，又は Intel(R)で製造されたマイクロ
プロセッサ、例えば８０X８６又は Pentium(R)プロセッ
サ，あるいは Sun Microsystems(R)の SPARC(R)マイク
ロプロセッサである。しかしながら、他の適切などんな
マイクロプロセッサ又はマイクロコンピュータでも利用
できる。メインメモリ１１５はダイナミック・ランダム
・アクセス・メモリ（Dynamic Randum Accessmemory:Ｄ
ＲＡＭ）から成っている。ビデオメモリ１１４はデュア
ルポート形ビデオ・ランダム・アクセス・メモリであ
る。ビデオメモリ１１４の一方のポートはビデオ増幅器
１１６に結合されている。ビデオ増幅器１１６は陰極線
管（Cathode Ray Tube:ＣＲＴ）ラスタモニタ１１７を
駆動するために用いられる。ビデオ増幅器１１６は技術
的に周知のものであって適切な装置であればどんなもの
でも実施できる。この回路はビデオメモリ１１４に保存
させた画素(pixel)データをモニタ１１７での使用に適
したラスタ信号に変換する。モニタ１１７はグラフィッ
クイメージを表示するのにふさわしいタイプのモニタの
一型式である。
【００２４】コンピュータ１００にはバス１１８に結合
された通信インタフェース１２０も含まれる。通信イン
タフェース１２０はネットワークリンク１２１を通じて
ローカルネットワーク１２２に双方向データ通信結合を
行う。例えば、通信インタフェース１２０が総合デジタ
ルサービス通信網（Integrated Services Digital Netw
ork:ＩＳＤＮ）カード又はモデムである場合には通信イ
ンタフェース１２０はネットワークリンク１２１の一部
を構成する対応するタイプの電話回線にデータ通信の接
続を行う。通信インタフェース１２０がローカル・エリ
ア・ネットワーク（Local Area Network:ＬＡＮ）カー
ドである場合には通信インタフェース１２０はネットワ
ークリンク１２１を介して互換ＬＡＮにデータ通信の接
続を行う。ワイヤレスリンクも可能である。こうした実
施形態においても通信インタフェース１２０は様々なタ
イプの情報を表すディジタルデータストリームを搬送す
る電気信号，電磁気信号又は光信号を送受信する。
【００２５】ネットワークリンク１２１は一般に１つあ
るいはそれ以上のネットワークを通じて他のデータ装置
とデータ通信を行う。例えば、ネットワークリンク１２
１はインターネット・サービス・プロバイダ（Internet
Service Provider:ＩＳＰ）１２４が操作するホストコ
ンピュータ１２３又はデータ機器にローカルネットワー
ク１２２を通じて接続を行うことができる。ＩＳＰ１２
４はまた、現在一般に"Internet"１２５と呼ばれている
世界的規模のパケットデータ通信ネットワークを通じて
データ通信サービスを提供している。ローカルネットワ
ーク１２２とインターネット１２５は双方ともディジタ
ルデータストリームを搬送する電気信号，電磁気信号又
は光信号を使用する。様々なネットワークを通じた信
号、ネットワークリンク１２１上で通信インタフェース
１２０を通じた信号はディジタルデータをコンピュータ
１００からまたコンピュータ１００へ搬送情報を転送す
る典型的な搬送波形態である。
【００２６】コンピュータ１００はネットワーク（１つ
又は複数），ネットワークリンク１２１，及び通信イン
タフェース１２０を通じてプログラム・コードを含むメ
ッセージを送り、データを受け取ることができる。イン
ターネットを例に取るとサーバ１２６はインターネット
１２５，ＩＳＰ１２４，ローカルネットワーク１２２，
及び通信インタフェース１２０を通じてアプリケーショ
ンプログラムに必要な要求コードを転送することも可能
である。
【００２７】受け取られたコードは受け取られるとＣＰ
Ｕ１１３で実行され及び／又は後で実行されるために大
容量保存装置１１２，又は他の不揮発性保存装置に保存
しておくことも可能である。このようにして、コンピュ
ータ１００は搬送波の形態でアプリケーション・コード
を得ることができる。
【００２８】上述のコンピュータ・システムは例示を目
的としたものにすぎない。本発明の実施例はどんなタイ
プのコンピュータシステムでも、またプログラミング環
境又は処理環境でも実施できる。
【００２９】［好適な実施例］本発明は選択可能なデパ
ッケタイザを使用できるシステムを提供する。本発明の
好適な実施例はＲＴＰの利用とＲＴＰセッション・マネ
ージャの用途を考えてデータ（好適な実施例ではビデオ
データ又はオーディオデータ）の受取りを扱っている。
ＲＴＰセッション・マネージャを以下に説明する。
【００３０】［ＲＴＰセッション・マネージャ］ＲＴＰ
セッション・マネージャ（RTP Session Manager:ＲＴＰ
ＳＭ）を用いればローカル・パーティシパントは単一の
ＲＴＰ"session"に参加する（データを送るか，又は受
け取る）ことができる。ＲＴＰＳＭはローカル・パーテ
ィシパントから見て当該セッションの更新された状態を
維持する。事実上ＲＴＰＳＭのインスタンスは分散エン
ティティ（ ＲＴＰセッション）のローカル表現であ
る。このことから、アプリケーションはＲＴＰセッショ
ンで、データストリームを表現，作成することができ
る。本発明の一実施例は本書の付録Ａに説明される Jav
a Media Framework（ＪＭＦ）を活用している。
【００３１】ＲＴＰセッション・マネージャの図式表示
は図２に示される。ジャバ・メディア・パッケージ・マ
ネージャ２０１はプレイヤの作成を扱って適切なプレイ
ヤを探し出す。マネージャ２０１はＪＭＦの一部であ
る。Java Media Framework（ＪＭＦ）はハイパーデキス
ト転送プロトコル（Hyper Text Transfer Protocol:Ｈ
ＴＴＰ）を使って、QuickTime Cinepakムービー等の様
々なプロトコル及びフォーマットでマルチメディアをプ
レイバックすることを目的とした１組のマルチメディア
ＡＰＩ及び実現である。Java Media Framework は"play
er"、すなわちマルチメディア・データをプレイバック
するユニットの概念を指定する。
【００３２】トランスポート・デリバリ２０２はネット
ワークからデータストリームを受け取って RTPSocket２
０３を通じてＲＴＰセッション・マネージャ２０４に提
供する。セッション・マネージャ２０４はＲＴＰパケッ
トを検査してエンコーディングの内容を判断する。エン
コーディングのタイプによりセッション・マネージャ２
０４は適切なデパッケタイザ２０６を識別して呼び出
す。セッション・マネージャ２０４はＲＴＰパケットを
デパッケタイザ２０６に送る。デパッケタイザ２０６は
それらのパケットのコーデック環境に適切なフレームに
パケットを組み立てて、それらのフレームをセッション
・マネージャ２０４を通じてハンドラ２０５に送る。ハ
ンドラ２０５はフレームをデコードして、適宜プレイバ
ックを行う。
【００３３】ＲＴＰＳＭ２０４は１セットの"participa
nts"と１セットの "streams"という動的な２組のオブジ
ェクトのセットを用いてセッションを表す。このストリ
ームはトランスポート・デリバリ２０２により提供され
る。これらのオブジェクトはＲＴＰＳＭにより作成され
コントロールされる。パーティシパントはこのセッショ
ンに参加する単一のマシン，ホスト又はユーザである
が、一方ストリームは単一のデータソースから到来又は
単一のデータソースにより送られる一連のデータパケッ
トである。パーティシパントは１つ以上のストリームを
所有することができ、それぞれのストリームはそのスト
リームのソースが利用するＳＳＲＣにより識別される。
【００３４】最上位ではＲＴＰＳＭは１セットの"parti
cipants" (RTPParticipant) を管理し、各パーティシパ
ントは RTPParticipantインタフェースを実装するクラ
スのインスタンスにより表される。ＲＴＰＳＭ実装は前
に識別されなかったリアルタイムコントロールプロトコ
ル（Real Time Control Protocol:ＲＴＣＰ）パケット
を受け取る時はいつでも RTPParticipant を作成する。
（このソースから、次のＲＴＣＰパケットが到来するた
びに RTPParticipant オブジェクトが更新される）。
【００３５】RTPParticipant オブジェクトのセットに
加えて、ＲＴＰＳＭ実装は１セットの RTPStream オブ
ジェクトセットも管理する。このような各オブジェクト
はこのセッションにおけるＲＴＰデータパケットのスト
リームを表す。このストリームがローカル・パーティシ
パント（クライアント）から起こる場合にはこのストリ
ームはRTPSendStream サブクラスのインスタンスであ
る。そうでなければ、このストリームはネット外のリモ
ート・パーティシパントのもので RTPRecvStreamサブク
ラスのインスタンスである。
【００３６】［プラガブル・デパッケタイザの構成］本
発明の好適な実施例はコーデック形式の着信データに基
づいて、適切なデパッケタイザ・モジュールを識別する
方式を提供する。このデパッケタイザ・モジュールはデ
ータをフレームに組み立て、そのフレームをハンドラに
提供してデコードとプレイバックを行う。このプロセス
のフローチャートは図４に示されている。
【００３７】ステップ４０１ではＲＴＰセッション・マ
ネージャがデータストリームを受け取る。ステップ４０
２ではＲＴＰＳＭはデータのＲＴＰヘッダを解析するこ
とにより、ペイロード形式のデータストリームを得る。
【００３８】ステップ４０３ではステップ４０２のペイ
ロード・クェリーの結果に基づいて適切なデパッケタイ
ザが呼び出される。ステップ４０４ではＲＴＰＳＭはこ
のデパッケタイザのストリーム上でＲＴＰパケットを受
け取って解析するたびにこのデパッケタイザの depacke
tize() メソッドを呼び出す。
【００３９】このデパッケタイザは depacketize() メ
ソッドに受け取ったプロトコル・データ・ユニットをア
プリケーション・データ・ユニット（フレーム）に組み
立て、ステップ４０５にてデータの１フレームの準備を
終えると、その DePacketizedDataHandler に通知する
（ＲＴＰＳＭはデパッケタイザの setTransferHandle
r()メソッドを用いて実体化されると、このデパッケタ
イザの transferHandlerをセットする。デパッケタイザ
の transferHandler は DePacketizedDataHandler 及び
デパッケタイザによりデパケタイズしたデータを渡すべ
きオブジェクトである）。ステップ４０６でその DePac
ketizedDataHandler の transferData()メソッドを呼び
出すことにより通知が行われる。つぎに、DePacketized
DataHandler はステップ４０７において逆パケット化さ
れたデータをこのストリームのハンドラにストリームす
ることを引き受ける。
【００４０】［デパッケタイザの図式表示］デパッケタ
イザの動作は図３に図式表示されている。ＲＴＰストリ
ーミング・パケットはＲＴＰセッション・マネージャ２
０４に送られる。ＲＴＰセッション・マネージャは第１
のパケットを調べ、かつＲＴＰヘッダを調べる。このパ
ケットには Extension Present，Type，拡張データのバ
イトアレイ，マーカ，ペイロード・タイプ(Payload Typ
em)，シーケンス番号(Sequence Number)，ＲＴＰタイム
スタンプ，ＣＳＲＣのＳＳＲＣ整数配列及びペイロード
（オフセット，長さ）等の情報が含まれる。つぎに、解
析されたＲＴＰパケットを DePacketizedDataHandler
３０１に提供する。
【００４１】デパッケタイザはＲＴＰパケットを Depac
ketizedUnit３０２にデパケッタイズする。Depacketize
dUnit３０２には DepacketizedUnitHeader，タイムスタ
ンプ，マーカ，ペイロードタイプ，ペイロードヘッダ，
ペイロードサイズが含まれる。DepacketizedUnit は本
質的にデータフレームであってデパッケタイザからＲＴ
ＰＳＭの一部である depacketizeddatahandler に提供
される。次に、ＲＴＰＳＭ２０４はこのフレームをハン
ドラ２０５に提供してデコーディングとプレイバックを
行う。
【００４２】［デパッケタイザ・インタフェース］Java
言語ではインタフェースは定数と抽象メソッドの集まり
である。あるクラスはそのクラスの“implements"句に
インタフェースを追加することでインタフェースを実装
できる。抽象メソッドは無視できる（すなわち取替えで
きる）。ある変数はインタフェース・タイプとして宣言
でき、このインタフェースで宣言される定数とメソッド
のすべてにこの変数からアクセスすることができる。
【００４３】本発明の好適な実施例には“RTPDepacketi
zer"と呼ばれるインタフェースが含まれる。このインタ
フェースは好適な実施例のＲＴＰＳＭのすべてのプラグ
・イン・デパッケタイザにより実装される。ＲＴＰＳＭ
からデパッケタイザへのエントリポイントはdepacketiz
e デパッケタイズメソッドを介する。アプリケーション
・データ・ユニット又はフレームは DePacketizedDataH
andlerのtransferData()メソッドを呼び出すことでデパ
ッケタイザからＲＴＰＳＭに転送される。ＲＴＰＳＭは
デパッケタイザで DePacketizedDataHandler をセット
することを引き受ける。デパッケタイザ・インタフェー
スは以下のメソッドを実装する： depacketize public abstract void depacketize(RTPPacket p)
【００４４】ＲＴＰパケットがネットワークから到来す
るか又はRTPSocketの出力データストリームに到来する
時にＲＴＰＳＭで呼び出される。 setTransferHandler public abstract void setTransferHandler(DePacketiz
edDataHandler handler)
【００４５】このデパッケタイザの transferHandler
をセットするためにＲＴＰＳＭで用いられる。このデパ
ッケタイザはアプリケーション・データ・ユニット又は
フレームの準備を終えた時に、その transferHandler
の transferData()メソッドを呼び出さなければならな
い。DePacketizedDataHandler に渡されたオブジェクト
は DepacketizedDataUnit である。 getMediaType public abstract String getMediaType()
【００４６】このストリームのメディア・タイプを検索
するためにＲＴＰＳＭで用いられる。これはオーディオ
又はビデオの１つと言え、ＲＴＰＳＭのコンテント・タ
イプ及びそれが準備するデータソース・ストリームをセ
ットする。 getCodecString public abstract String getCodecString()
【００４７】ＲＴＰＳＭがハンドラのために作成するデ
ータソース・ストリームにコーデック文字列タイプをセ
ットするためにＲＴＰＳＭにより使用される。これは使
用されるコーデックを識別する文字列をリターンする。
このマネージャは package−prefix.media.codec.media
type.[codec−string].Codec のタイプのコーデックを
探し出す。 public class DePacketizedUnitHeader
【００４８】図３に示される通り DePacketizedUnit は
DePacketizedUnitHeader を含む。DePacketizedUnitHe
ader はそれが属している DePacketizedUnit を述べ
る。これらのヘッダ・パラメータは逆パケット化された
ユニットを全体として説明することになっている。この
ヘッダにはデコーディングとレンダリングの処理に関係
のあるものと見なされるパケットのＲＴＰヘッダからの
フィールドがいくつか入っている。DePacketizedUnit
がＲＴＰパケットを１つ以上場合、このヘッダには全体
としてこのユニットを述べるデータを正確に入れなけれ
ばならない。プログラマは逆パケット化されたデータ・
ユニットについて自身の構造体を有するか，あるいはＲ
ＴＰＳＭで提供されるデフォルト・クラスを使用するこ
とができる。
【００４９】このクラスの構成体は DePacketizedUnitH
eader(long, int, int, int, byte[], int)である。
【００５０】この構成体のパラメータは以下の通りであ
る：rtptimestamp−このストリームのプロトコル・デー
タ・ユニット（ＲＴＰパケット）に入ったＲＴＰタイム
スタンプ。これらはハンドラによりタイミング情報と同
期を転送するのに用いられることになるから、ハンドラ
に渡される。markerbit−このアプリケーション・デー
タ・ユニット又はフレームのＲＴＰヘッダのマーカ・ビ
ット、すなわち、このＡＤＵにマーカ・ビットをセット
した場合には１にセットされる。 payloadtype−このdepacketizedunit中のデータのペイ
ロード・タイプ payloadhdr−このペイロード・タイプ用にＲＴＰヘッダ
の後に付けるペイロード固有のヘッダ。 payloadsize−このdepacketizedunit中のデータの長さ
【００５１】このクラスのメソッドは以下の通りであ
る：
【００５２】これはデータソース(datasources)上で受
け取られたデータのペイロード・タイプを問い合わせる
ためにあらゆるＲＴＰデータソースで実装されるインタ
フェースである。このデータソース上でＲＴＰデータが
まだ受け取られていない場合にはＲＴＰデータはフィー
ルド UNKNOWN_PAYLOAD、すなわち、このデータソース上
でデータが受け取られていない時にリターンされる定
数、をリターンする。
【００５３】このインタフェースのメソッドは以下の通
りである： setPayloadType public abstract void setPayloadType(int type)
【００５４】このデータソースのペイロードをセットす
るために使用される。ペイロードがあらかじめセットさ
れている場合にはこのペイロードをこの新規ペイロード
・タイプにリセットする。 getPayloadType public abstract int getPayloadType()
【００５５】このデータソースのペイロード・タイプを
リターンする。 setCodecString public abstract String getCodecString()
【００５６】コーデックを使用してこのデータソースか
らデータをデコードするために Codec 文字列をリター
ンする。 setCodecString public abstract void setCodecString(String codec)
【００５７】データソース／ストリームのコーデック文
字列をセットするために用いられる。コーデック文字列
があらかじめセットされている場合にはこのコーデック
文字列はこの新規コーデック文字列にリセットされる。
【００５８】［コンテント・ハンドラ］本発明はプログ
ラマがプログラマ自身のデパッケタイザをプラグインす
ることのできる設計を提供する。このような逆パケット
化したストリームを再生するためにこのデパッケタイザ
用のコンテント・ハンドラが利用できなければならな
い。好適な実施例ではデパッケタイザがプラガブル・デ
パッケタイザ・インタフェースを実装し、またハンドラ
がプラガブル・コンテント・ハンドラに関連して以下に
説明される所定フォーマットのデータとなるようにプロ
グラミングされる時にはデパッケタイザとコンテント・
ハンドラとの統合が行われる。
【００５９】好適な実施例ではＲＴＰＳＭにデフォルト
の所定のフォーマットが提供されているが、このために
プログラマは逆パケット化されたデータについてプログ
ラマ自身のフォーマットを使用できないことはない。プ
ラガブル・デパッケタイザのネーミング規則とサーチン
グ規則はＪＭＦのプレイヤ・ファクトリ・アーキテクチ
ュアにより設計され、これらの規則を用いてデパッケタ
イザをＲＴＰＳＭにインテグレートされる。例えば、新
規のデパッケタイザをＪＭＦに組み入れるには １）このデパッケタイザは以下に定められたインタフェ
ースを実装する。 ２）新規のデパッケタイザ・クラスが入っているパッケ
ージをインストールする。 ３）PackageManager でコントロールされるコンテント
・プリフィックス・リストにそのパッケージ・プレフィ
ックスを追加する。 ４）DePacketizerFactory はコンテント・パッケージ・
プリフィックスのリストについて PackageManager に問
い合わせて<package-prefix>.media.rtp.depacketizer.
avpx.DePacketizer のクラスをサーチする。ここで、x
はインストールされたデパッケタイザ用のＲＴＰペイロ
ード・タイプである。
【００６０】ＲＴＰコンテント・ハンドラはＪＭＦプレ
イヤであって、Java Media Playerのメソッドとセマン
ティクスを実装しなければならない。新規のハンドラ又
はプレイヤのインテグレーティングは付録として添付さ
れたＪＭＦ明細書に説明される通りである。このセッシ
ョン・マネージャで作成されたＲＴＰデータソースのコ
ンテント・タイプは“rtp/audio"又は“ rtp/video"の
いずれかである。したがって、マネージャは<package−
prefix>.media.content.rtp.audio.Handler，又は<pack
age-prefix>.media.content.rtp.video.Handler のタイ
プのハンドラをサーチする。
【００６１】注：あるハンドラが Manager により一度
選択され作成されると、ＪＭＦはハンドラを変更しな
い。それゆえ、ロードされたハンドラは予想されたオー
ディオ又はビデオのＲＴＰペイロード・タイプをサポー
トしてデータストリームをうまく再生できることに留意
することが重要である。
【００６２】Manager はデータソースを作成し、それを
ハンドラにセットする。このデータソースは PushDataS
ource であって、ＪＭＦ明細書において、package java
x.media.protocol で説明される通りに、PushSourceStr
eam をストリームする。ハンドラはＪＭＦ明細書で説明
される通りにこのストリームからデータを読み取ること
ができる。この Manager がデータソースを作成し、そ
のデータソースのためにハンドラを探し出す時には Man
ager はハンドラ上で setSource() を呼び出して、それ
をこのデータソースに渡す。この時、ハンドラはデータ
ソースをサーポートしない場合には IncompatibleSourc
eException をリターンする。あらゆるＲＴＰデータソ
ースは javax.media.rtp.RTPPayloadインタフェースを
実装する。getPayloadType()メソッドはそのデータソー
スのペイロード・タイプを問い合わせるために、ハンド
ラで用いられる。ハンドラがペイロード・タイプの再生
をサポートしない場合にはハンドラは IncompatibleSou
rceException をリターンすることができる。これによ
り Manager はこのデータソースをサポートするハンド
ラを引き続きサーチする。このようにして、実装はデフ
ォルトとしてこのハンドラではサポートされないあるペ
イロードをサポートするシステムでハンドラを用いるこ
とができる。
【００６３】注：ＲＴＰデータソースはデータが実際に
そこで受け取られた後でのみ、ペイロード・タイプをリ
ターンすることができる。これは getPayload() コール
が出される前に生じる保証プロセスではない。データが
データソース上で受け取られない場合にはこのデータソ
ースにより UNKNOWN_PAYLOAD がリターンされる。この
時のハンドラは自由に判断でき、また、このストリーム
で予想されるどんなペイロードでもサポートするか、あ
るいは IncompatibleSourceException をスロー(throw)
する判断を下すことができる。
【００６４】ＲＴＰ Session Manager は PushSourceSt
ream としてコンテント・ハンドラにデータをストリー
ムする。このハンドラで読み取られるバイト・ストリー
ムはバイトの１ストリームに変換された DePacketizedO
bject である。このオブジェクトの構造体はＲＴＰＳＭ
に知らせる必要はない。この構造体(structure)はイン
タフェースの toByteStream()メソッドを使用して DePa
cketizedObject からハンドラのデータソース・ストリ
ームにバイトを流す。ＲＴＰＳＭは DePacketizedObjec
tインタフェース、すなわち、DePacketizedUnit.java
のデフォルト実装を行う。プログラマは javax.media.r
tp.RTPSessionManager.dePacketizer.DePacketizedUni
t.java で説明された DePacketizedUnit を作成するデ
パッケタイザを書くことができる。toByteStream()メソ
ッドはDePacketizedUnit に実装されている。したがっ
て、ユーザは DePacketizedUnit の作成だけを行えばよ
い。
【００６５】こうして、選択可能なデパッケタイザを提
供するための方法及び装置は１つ又はそれ以上の特定の
実施例といっしょに説明されてきた。本発明は特許請求
の範囲と、その均等の範囲で定められる。
【００６６】Ｊａｖａ Ｍｅｄｉａ Ｐｌａｙｅｒｓ バージョン１.０.２ １９９７年１０月１４日 (c)1997 Sun Microsystems, Inc. 2550 Garcia Avenue,
Mountain View, California 94043-1100 U.S.A. 版権
所有。
【００６７】制限付き権利の説明：合衆国政府による使
用，複写，又は開示は DFARS252.227-7013(c)(1)(ii)と
FAR52.227-19 に述べられる制限を受ける。
【００６８】本文書に述べられ公開されたものは１つあ
るいはそれ以上の米国特許，外国特許，又は係属中の出
願により保護される場合がある。
【００６９】本書により Sun Microsystems,Inc.(SUN)
は本仕様を実施するのに不可欠な SUN の知的財産権の
もとに、完全支払い済みで、独占的でなく、譲渡でき
ず、永久に続き、かつ世界中に及ぶ限定ライセンス（サ
ブライセンスの権利はない）を読者に与える。このライ
センスの実施は(i)本仕様書の完璧な実施例であり、(i
i)SUN から入手される本仕様に関する一連のテストすべ
てに合格しており、(iii)SUN のソース・コードやバイ
ナリデータからは得られず、さらに(iv)SUN からの適切
且つ別個のライセンスのない SUN のどのようなバイナ
リ資料も含まれていない、本仕様のクリーンルームでの
実施例の作成と配布を許可し、かつそれに限定されてい
る。
【００７０】Java とJavaScript は Sun Microsystems,
Inc. の商標である。Sun, Sun Microsystems, Sun Mic
rosystems Computer Corporation, Sun のロゴ, Sun M
icrosystems Computer Corporation のロゴ, Java, 及
び HotJava は Sun Microsystems, Inc. の商標又は登
録商標である。UNIX(R) はアメリカ合衆国，及び他の諸
国の登録商標であって、X/Open Company, Ltd を通じて
独占的に認可される。本書に記載された他の製品名はす
べてそれぞれの所有者の商標である。
【００７１】この公開文書は黙示の市場性保証，特定目
的への適合性，又は無侵害を含めそれらに限定されるこ
とはなく明示であれ黙示であれいかなる保証もなく「現
状」で提供される。
【００７２】この公開文書は技術的な誤り又は誤植を含
むこともある。本書に記載の情報には定期的に変更が加
えられる。このような変更は本公開文書の新版に織り込
まれる。Sun Microsystems, Inc. はいかなる時でも本
公開文書に記述される製品（１つ又は複数）及び／又は
プログラム（１つ又は複数）の改良及び／又は変更を行
うことがある。
【００７３】［前書き］Java Media Framework（ＪＭ
Ｆ）はメディア・データ・タイプを Java アプリケーシ
ョンと Java アプレットに組み込むためのアプリケーシ
ョン・プログラミング・インタフェース（ＡＰＩ）であ
る。これはとりわけ Java プラットフォームの特徴を利
用するように設計されている。ＪＭＦの１.０バージョ
ンはメディア・プレイヤ用のＡＰＩを備えている。将来
のバージョンはメディア・キャプチュア(media captur
e)と会議(conferencing)をサポートする。本書は Java
MediaPlayer のＡＰＩと、このＡＰＩをどのような方法
で使用すればオーディオ及びビデオのようなタイムベー
スのメディアを提示できるのか述べている。
【００７４】Ｊａｖａ Ｍｅｄｉａ Ｐｌａｙｅｒｓ Java Media Player の１.０仕様はメディア・ディスプ
レイと、この分野のアプリケーション・ビルダの問題
を、他のアプリケーション分野や他の水準の開発者に目
を向けて扱っている。この公開文書は２部から成ってい
る。すなわち、「Java Media Player」という題名のユ
ーザガイドと、添付のＡＰＩ文書である。
【００７５】将来の公開文書 Javasoft とそのパートナーはＪＭＦ仕様の将来の公開
文書に記載される追加的な可能性及び特徴を開発してい
る。当社が将来の公開文書のために検討している特徴に
は以下のものがある： ・不完全なプレイヤ−ＪＭＦプレイヤは独立言語型であ
るためにそのメディア・データにアクセスすることはで
きない。メディア・データにアクセスできるようにし、
かつレンダリング・コンポーネントを選択できるように
する追加インタフェースが開発されており、将来の公開
文書に向けられている。 ・レンダリング・インタフェース−特定のオーディオ及
びビデオのフォーマット用のレンダリング・インタフェ
ースと、オーディオ及びビデオのレンダラーの追加イン
タフェースが将来の公開文書に向けて開発される。 ・キャプチャ・セマンティクス−ＪＭＦプレイヤのアー
キテクチュアはオーサリング・アプリケーション又は会
議アプリケーションに求められるメディア・キャプチュ
ア機能をサポートしていない。キャプチャ・セマンティ
クスは将来の公開文書で扱われる。 ・データ定義−ＪＭＦ１.０は総称フォーマット間での
データ操作とフォーマット折衝のための総合構造体を備
えている。将来の公開文書はオーディオデータとビデオ
データの特定のインタフェースを扱う。 ・CODECアーキテクチュア−CODEC（エンコーダ・デコー
ダ）アーキテクチュアは将来の公開文書の中で定義され
て、CODECを用いてメディア・データをコンプレス及び
デコンプレスするための共通ＡＰＩと、追加CODECを当
該システムにインストールするための機構を備える。
【００７６】連絡情報 JavaSoft Java Media Framework について情報を得るには以下の
ウェブサイトを見ること： HTTP://java.sun.com/products/java-media/jmf Silicon Graphics Silicon Graphics のハードウェア向けのJava Media Fr
amework 実装に関して情報を得るには以下にメールを送
ること： cosmo-motion-info＠sgi.com Intel Corporation Intel ハードウェア向けの Java Media Framework 実装
に関して情報を得るには以下のウェブサイトを見るこ
と： HTTP://developer.intel.com/ial/jmedia
【００７７】変更履歴 バージョン１.０.２ 第５節に blockingRealize 例示コードについての属性
付加。本書のバージョン１.０と１.０.１は誤ってこの
属性を省略した。この例示コードは Bill Day及び Java
World 誌の許可を得て使用されている。この例示コード
は Web Publishing Incのオンライン出版物である Bill
Day の記事「Java Media Framework Player API：マル
チメディアが Java にやってくる(Multimedia Comes to
Java)」で、１９９７年４月に初めて発表された。 第５節において PlayerClosedEvent and Player.close
の参照を ControllerClosedEvent and Controller.clos
e に変更。 付録Ｂでjava.mediaをjavax.media に変更。 setStopTimeとsetMediaTime のパラメータとして Time
オブジェクトを使用するために付録Ｃにおいて例の変
更。 バージョン１.０.１ ＪＭＦ１.０ＡＰＩとの不一致の固定。 バージョン１.０ 最終的なＪＭＦ１.０ＡＰＩ公開文書のための文書更
新。
【００７８】Ｊａｖａ Ｍｅｄｉａ Ｐｌａｙｅｒｓ Sun Microsystems,Inc. Silicon Graphics Inc. Intel Corporation Sun Microsystems Inc.により１９９７年版権所有
【００７９】Java Media Framework（ＪＭＦ）１.０の
仕様はタイムベースのメディアを表示するためのＡＰＩ
を定義している。本書はこのＡＰＩとこのＡＰＩをどの
ような方法で使用すればオーディオ及びビデオのような
メディアを表示できるのか、説明している。
【００８０】メディア・ディスプレイはアプリケーショ
ン又はアプレットの範囲内でマルチメディア・データを
ローカルで、またネットワークで再生することを含む。
ＪＭＦ１.０プレイヤ(Player)ＡＰＩの目標は同期メデ
ィア・データの配布をサポートし、また基礎をなすプラ
ットフォームのネーティブ環境及び Java のコア・パッ
ケージ（例えば、java.awt）と統合できるようにするこ
とにある。プレイヤＡＰＩはクライアントのプル・プロ
トコル（例えばＨＴＴＰ）と、サーバのプッシュ・プロ
トコル（例えばＲＴＰ）を両方ともサポートしている。
【００８１】ＪＭＦはより高度なアプリケーションやプ
ラットフォームをカスタマイズするため必要な柔軟性を
保ちながらクライアントのアプリケーションとアプレッ
トにメディアを容易に組み込ませるようにする： ・クライアント・プログラマはいくつかの単純なメソッ
ド・コールを用いてどんな標準メディア・タイプでも、
Java Media Player を作成し、コントロールすることが
できる。 ・技術プロバイダはＪＭＦを拡張して追加のメディア・
フォーマットをサポートできか、又は新しいタイプのメ
ディア・コントローラ、メディア・プレイヤ、メディア
・データソースを作成し統合することで、カスタム操作
を行うことができる。このような拡張は現行のＪＭＦオ
ブジェクトと並行して使用できる。
【００８２】“拡張ＪＭＦ”（９.０）には拡張ＪＭＦ
に関する情報が記載されている。しかしながら、本書は
おもにアプリケーション及びアプレットの開発者向けの
ものである。
【００８３】［１.０ 概説］ＪＭＦはタイムベースの
メディアを表示するためのプラットフォーム中立フレー
ムワークを備えている。Java Media Player ＡＰＩはＭ
ＰＥＧ−１，ＭＰＥＧ−２，QuickTime, ＡＶＩ，ＷＡ
Ｖ，ＡＵ，ＭＩＤＩを含むもっとも標準的なメディア・
コンテント・タイプをサポートするように設計されてい
る。ＪＭＦを用いれば種々のソースからタイムベースの
メディアを同期をして表現することができる。
【００８４】デスクトップ・コンピュータ用の現行メデ
ィア・プレイヤはデコンプレッション及びレンダリング
のような計算集約的タスク向けのネーティブ・コードに
強く依存している。ＪＭＦのＡＰＩは抽象化を行って開
発者からこのような実装の詳細を隠蔽する。例えば、特
定のＪＭＦプレイヤの実装はネーティブ・メソッドを用
いてオペレーティング・システムの機能に影響を与える
ようにする場合がある。しかしながら、ＪＭＦのＡＰＩ
にコーディングすることによりこのアプリケーション又
はアプレットの開発者はその実装がネーティブ・メソッ
ドを使用しているかどうか知る必要がない。
【００８５】ＪＭＦプレイヤＡＰＩは： ・異なるプロトコル及び配布機構にわたって基準化(sca
le)する。 ・異なるタイプのメディア・データにわたって基準化す
る。 ・ＪＭＦプレイヤとアプリケーション又はアプレット間
の非同期通信用のイベント・モデルを提供する。
【００８６】［１.１ DataSource（データソース）］D
ataSource はメディアの位置，及びメディアの配布に用
いられるプロトコルとソフトウェアをカプセル化する。
Java Media Player には DataSource が入っている。こ
のソースは一度得られると他のメディアの配布には再使
用できない。プレイヤのデータソースは JMF MediaLoca
tor か、ＵＲＬ（universal resourcelocator）のいず
れかで識別される。
【００８７】MediaLocator はプレイヤが表示するメデ
ィアを記載するＪＭＦクラスである。MediaLocator は
ＵＲＬに類似するものであってＵＲＬから構築すること
ができる。Java では対応するプロトコル・ハンドラが
当該システムにインストールされる場合にのみ、ＵＲＬ
を構築できる。MediaLocator はこのような制約を受け
ない。
【００８８】Java Media Player はローカルファイル又
はネットワークファイルと生放送等の様々なデータソー
スから得られたメディア・データを表現できる。ＪＭＦ
は以下の２つの異なるタイプのメディア・ソースをサポ
ートしている： ・プル・データソース−クライアントはデータ転送を開
始して、プル・データソースからのデータの流れをコン
トロールする。このタイプのデータに設定されたプロト
コルにはハイパーテキスト転送プロトコル（ＨＴＴＰ）
と FILE がある。 ・プッシュ・データソース−サーバはデータ転送を開始
してプッシュ・データソースからのデータの流れをコン
トロールする。プッシュ・データソースには放送メディ
ア，マルチキャスト・メディア，ビデオ・オン・デマン
ド（Video OnDemand:ＶＯＤ）がある。放送データでは
プロトコルとしてインタネット技術対策委員会（Intern
et Engineering Task Force:ＩＥＴＦ）で開発中の実時
間移送プロトコル（Real-Time Transport Protocol:Ｒ
ＴＰ）がある。ＳＧＩで開発された MediaBase プロト
コルはＶＯＤに用いられるプロトコルである。
【００８９】クライアント・プログラムがユーザまで拡
張できるコントロールの度合いは表示されているメディ
ア・ソースのタイプに依存している。例えば、ＭＰＥＧ
フイルは位置を動かすことができ、またクライアント・
プログラムを使えばユーザはビデオ・クリップを再生す
るかあるいはビデオにおける新たな位置にシークするこ
とができる。それに反して、放送メディアはサーバのコ
ントロール下にあって位置を動かすことはできない。い
くつかのＶＯＤプロトコルは制限付きのユーザコントロ
ールをサポートする場合もあり、例えばクライアント・
プログラムを用いればユーザは新たな位置をシークする
ことができるが、ただし早送りも巻き戻しもできなくな
る場合がある。
【００９０】［１.２ プレイヤ(Player)］図５に示す
Java Media Player は時間経過とともにデータのストリ
ームを処理し、DataSource からデータを読み取ってそ
れを的確な時に表現するオブジェクトである。Java Med
ia Player はプレイヤインタフェースを実装する。
【００９１】・クロックはメディア・データの表現をコ
ントロールするためにプレイヤが用いる基本的なタイミ
ング及び同期の動作を定める。 ・コントローラはクロックを拡張して、システム資源を
管理しデータをプレロードするための方法と、メディア
・イベントの通知を受け取ることのできるリスニング機
構のための方法を提供する。 ・Duration は再生中のメディアの持続期間を判断する
方法を提供する。 ・プレイヤは標準化されたユーザコントロールをサポー
トして、クロックで加えられる処理制限の一部を緩和す
る。
【００９２】プレイヤは計時と同期化の共通モデルを共
用する。プレイヤのメディア・タイム(media time)はメ
ディア・ストリーム中の現在位置を示す。各プレイヤは
各プレイヤの時間のフローを定める TimeBase を有す
る。プレイヤが始動すると、そのメディア・タイムはそ
のタイムベースの時間に対応づけられる。同期がとられ
るために、プレイヤは同一の TimeBase を使用しなけれ
ばならない。
【００９３】プレイヤのユーザ・インタフェースはビジ
ュアル・コンポーネントと、コントロールパネル・コン
ポーネントを共に含むことができる。プレイヤ用にカス
タム・ユーザ・インタフェースを実装するか、あるいは
プレイヤのデフォルト・コントロールパネル・コンポー
ネントを使用することができる。
【００９４】プレイヤはメディアを表現できるまでにい
くつかの操作を実行しなければならない。これらの中で
時間がかかる操作もあるので、ＪＭＦを用いればユーザ
はプレイヤの処理状態を定めてその処理状態間でプレイ
ヤを移すコントロール機構を提供することによりこのよ
うな処理をいつ行うかコントロールすることができる。
【００９５】［１.３ メディア・イベント］ＪＭＦイ
ベント・レポーティング機構により、ユーザのプログラ
ムはメディア駆動のエラー状態（例えばデータ外）又は
資源使用不能状態に対処することができる。このイベン
ト・システムは主要な通知プロトコルも提供する。した
がって、ユーザのプログラムがプレイヤ上で非同期メソ
ッドを呼び出す時にのみ、その操作は適切なイベントを
受け取ることで完結すると確信できる。
【００９６】GainControlオブジェクトと Controllerオ
ブジェクトという２つのタイプのＪＭＦオブジェクトが
イベントを通知する。コントローラと GainControl は
イベント用に設定された Java Beans パターンに従う。
【００９７】GainControlオブジェクトは GainChangeEv
ent という１つのタイプのイベントのみを通知する。利
得変化に対処するために GainChangeListener インタフ
ェースを実装する。
【００９８】コントローラは ControllerEvent から得
られる様々なイベントを通知できる。プレイヤのような
コントローラ(Controller)からイベントを受け取るた
めにControllerListener インタフェースを実装する。
図６は コントローラで通知されるイベントを示してい
る。
【００９９】ControllerEvent は変更通知，クローズド
・イベント，遷移イベントという３つの種類に分類され
る： ・RateChangeEventやDurationUpdateEvent 等の変更通
知イベントはしばしばメソッド・コールに答えて、プレ
イヤのある属性が変化したことを示す。例えば、プレイ
ヤはレートが setRate へのコールにより変更される時
には RateChangeEvent を通知する。 ・TransitionEvent により、ユーザのプログラムはプレ
イヤの状態の変化に対処することができる。プレイヤは
ある状態から別の状態に移る時はいつでも遷移イベント
を通知する。（プレイヤの状態の詳細については１.４
項を参照のこと。） ・ControllerClosedEvent はプレイヤが遮断する時にプ
レイヤで通知される。プレイヤが ControllerClosedEve
nt を通知する時にはプレイヤはもう使えない。Control
lerErrorEvent は ControllerClosedEvent の特別な場
合である。ユーザのプログラムがプレイヤの誤動作に対
処しユーザに対する影響を最小限にとどめることができ
るように、ControllerErrorEvent に注意する。
【０１００】［１.４ プレイヤの状態(states)］Java
Media Player は６つの状態のうちの１つにあると言え
る。クロックインタフェースは Stopped と Started と
いう２つの基本状態を定めている。資源管理を簡単に行
うために コントローラは Stopped 状態を図７に示す５
つの待機状態 Unrealized（未認識），Realizing（認識
中），Realized（認識済み），Prefetching（先取り
中），Prefetched（先取り済み）に分割する。
【０１０１】正規の操作ではプレイヤは Started（起動
済み）状態に達するまで各状態を経て進む： ・Unrealized 状態のプレイヤは実体化されているがそ
のメディアについてはまだ何も知らない。メディアプレ
イヤが先ず作成され、これが Unrealized である。 ・realize がコールされる時にはプレイヤは Unrealize
d 状態からRealizing状態に移る。Realizingプレイヤは
その資源要件を判断中である。実現の間にプレイヤは一
度だけ得る必要のある資源を得る。このような資源には
独占使用の資源以外のレンダリング資源が含まれる場合
がある。（独占使用の資源は一度に１つのプレイヤしか
使用できない個々のハードウェア装置等の制限付き資源
である；このような資源は Prefetching 中に得られ
る。）Realizingプレイヤはしばしばネットを通して資
産（アセット）をダウンロードする。 ・プレイヤは Realizing を終えると Realized 状態に
移る。Realizedプレイヤはどんな資源が必要であるか、
また表現すべきメディアのタイプに関する情報を知る。
Realizedプレイヤはそのデータをレンダーする方法を知
っているから、ビジュアル・コンポーネントとコントロ
ールを提供できる。Realizedプレイヤは当該システム内
の他のオブジェクトと適当な場所でコネクションされる
が、別のプレイヤの始動を妨げる資源はまったく有して
いない。 ・prefetch がコールされるとプレイヤは Realized 状
態から Prefetching 状態に移る。Prefetchingプレイヤ
はそのメディアを表現する準備をしている。この段階の
間、プレイヤはそのメディア・データをプレロードし、
専用の資源と他に必要なものを得て再生の準備を行う。
プレイヤのメディア表現の位置を動かす場合、あるいは
プレイヤのレートの変更により、追加バッファを得る
か、又は代替処理を行うことが求められる場合には Pre
fetching が繰り返されねばならない。 ・プレイヤは Prefetching を終えると Prefetched 状
態に移る。Prefetchedプレイヤはいつでも始動できる。
Prefetchedプレイヤは現に Started 中でない限り、い
つでも再生できる。 ・start をコールすると、プレイヤは Started 状態に
置かれる。Started プレイヤのタイムベースのタイムと
メディア・タイムが対応付けられておりそのクロックは
動作中であるが、プレイヤはそのメディア・データの表
現を開始する特定の時間を待っている場合がある。
【０１０２】プレイヤはある状態から他の状態へ移る時
に TransitionEvent を通知する。ユーザのプログラム
が現時点のプレイヤの状態を判断して適切に対処する方
法はControllerListener インタフェースで提供され
る。
【０１０３】このイベント・レポーティング機構を用い
れば、いつプレイヤが Realizingと Prefetching を開
始するのかコントロールすることでプレイヤ待ち時間を
管理できる。この機構により、プレイヤ上でメソッドを
呼び出す前はプレイヤが適切な状態にあることも保証で
きる。
【０１０４】［１.４.１ 各プレイヤ状態で利用できる
メソッド］競争条件を回避するために、あらゆる状態の
プレイヤ上ですべてのメソッドを呼び出せるとは限らな
い。表１の「プレイヤメソッドへの制限」はＪＭＦで加
えられる制限を示す。プレイヤの現行状態で不正である
メソッドを呼び出す場合にはプレイヤはエラー又は例外
をスローする。
【０１０５】
【表１】
【０１０６】［１.５ ＪＭＦメソッドの呼出し］ＪＭ
Ｆはエラー及び例外について以下の規則を用いる： ・プログラムがオブジェクトの現行状態で不正規である
メソッドを呼び出す時には、Java Media Error がスロ
ーされる。Error はこの現行状態をコントロールする場
合にスローされ、また要求される動作から競争条件が発
生しかねない。例えば、Startedプレイヤ上でいくつか
のメソッドを呼び出すことはエラーである。ユーザの責
任においてこれらのメソッドを使用する前にプレイヤを
確実に停止させる。アプリケーションがＪＭＦエラーを
キャッチしてはならない。申し分なく作成されたアプリ
ケーションはこのようなエラーに遭遇することはない。 ・完了できないか又はオブジェクトの現在の状態に当て
はまらないメソッドをプログラムが呼び出す時には Jav
a Media Excepion がスローされる。Excepionはこの状
態を必ずしもコントロールしない場合にスローされる。
例えば、両立しないタイムベースを用いて２つのプレイ
ヤの同期をとろうとする場合に、Exception がスローさ
れる。これはエラーではない。なぜなら、それらのタイ
ムベースが両立できないことをタイムの前に判断できな
かったからである。同様に、Startedプレイヤにのみ適
用できるメソッドをコールし、かつプレイヤが Stopped
である場合には exception がスロー(throw)される。
まさにプレイヤを始動させたとしてもプレイヤはメディ
アの終了等の他の条件に答えてすでに停止している筈で
ある。
【０１０７】一部のＪＭＦメソッドはメソッド・コール
の結果を示す値をリターンする。いくつかの例ではこれ
らの結果はそのメソッドをコールした時に予想したもの
でないかもしれない。リターン値をチェックすることに
より、現実に何が起こったのか判断することができる。
例えば、そのリターン値は以下のものを示すかもしれな
い： ・現実にセットされた値。例えば、すべてのプレイヤが
正規レートの５倍でメディア・データを表示できるとは
限らない。setRate（５.０）を呼び出す場合にはプレイ
ヤはそのレートをできる限り５.０に近づけるようにセ
ットし、現実にセットしたレートをリターンする。その
レートは５.０であったり、１.０であったりするかもし
れないがリターン値をチェックして発見する必要があ
る。 ・ユーザが要求した情報は当座は入手できない。例え
ば、プレイヤはそのメディア・ストリームを一度再生す
るまでその持続期間を知らないかもしれない。再生する
までに、そのようなプレイヤ上で getDuration をコー
ルすると getDuration は DURATION_UNKNOWN をリター
ンする。プレイヤが再生した後で、再び getDuration
を呼び出す場合にはプレイヤはメディア・ストリームの
実際の持続期間をリターンすることができる筈である。
【０１０８】［２.０ 例：アプレットを作成してメデ
ィア・ファイルを再生する］サンプル・プログラムであ
る PlayerApplet は Java Media Player を作成して、J
avaアプレット内からＭＰＥＧムービーを表現する方法
を実演する。これは一般的な例であって、他のタイプの
メディア・ストリームを表現するために容易に調整でき
ることになる。
【０１０９】プレイヤのビジュアル表現と、そのコント
ロールはブラウザのウインドウの中のアプレット表現ス
ペース内に表現される。Javaアプリケーションでプレイ
ヤを作成する場合にはユーザはウインドウを作成してプ
レイヤのコンポーネントを表現することに責任がある。
【０１１０】注：PlayerApplet は Java Media Player
の基本的な使用法を例示するが、実際のアプレット又は
アプリケーションで必要なエラー処理は行わない。テン
プレートとしての使用にふさわしい完璧なサンプルは
「付録Ａ：Ｊａｖａ Ｍｅｄｉａ Ａｐｐｌｅｔ」を参
照のこと。
【０１１１】［２.１ PlayerApplet の概説］APPLET
タグを用いてＨＴＭＬファイルに PlayerApplet を呼び
出す。ＨＴＭＬアプレットタグの WIDTH フィールドと
HEIGHT フィールドはブラウザのウインドウの中のアプ
レット表現スペースのサイズを判断する。PARAM タグは
表現されるメディア・ファイルを示す。例えば、Player
Applet は以下のプログラムを用いて呼び出されること
になる：
【０１１２】 <APPLET CODE=ExampleMedia.PlayerApplet WIDTH=320 HEIGHT=300> <PARAM NAME=FILE VALUE="Astrnmy.mpg"> </APPLET>
【０１１３】PlayerApplet が入っているウェブページ
をユーザが開く時にはこのアプレットは自動的にロード
してプレイヤのビジュアル・コンポーネントとデフォル
ト・コントロールが入っている指定された表現スペース
内で実行する。プレイヤが始動して、一度ＭＰＥＧムー
ビーをプレイする。ユーザはデフォルトのプレイヤコン
トロールを使用すればムービーを停止，再始動又はプレ
イすることができる。プレイヤがムービーをプレイして
いる時に、アプレットが入っているページを閉じる場合
にはプレイヤは自動的に停止し、使っていた資源を解放
する。
【０１１４】これを実行するために、PlayerApplet はA
pplet を拡張して ControllerListener インタフェース
を実装する。PlayerApplet は以下の５つのメソッドを
定めている： ・init - PARAM タグを通じて渡されたファイル向けの
プレイヤを作成し、コントローラ・リスナーとして Pla
yerApplet を登録してプレイヤで通知されたメディア・
イベントを注目(observe)できるようにしている。（こ
れにより、プレイヤがイベントを通知する時はいつでも
PlayerApplet の controllerUpdateメソッドが呼び出
される。） ・start - PlayerApplet が始動する時にはプレイヤを
始動させる。 ・stop - PlayerApplet が停止する時にはプレイヤを停
止させてその割り当て領域を開放(dealocate)する。 ・destroy - PlayerApplet を削除する時はプレイヤを
閉じる。 ・controllerUpdate −プレイヤイベントに応えてプレ
イヤのコンポーネントを表現する。
【０１１５】 ［２.２ PlayerApplet のコード・リスト］ PlayerApplet.java: package ExampleMedia: import Java.applet.*; import Java.awt.*; import Java.net.*; import Javax.media.*; public class PlayerApplet extends Applet implements ControllerListner { Player player = null; public void init() { setLayout(new BroaderLayout()); String MediaFile = getParameter("FILE"); try { URL mediaURL = new URL(getDocumentBase(), MediaFile); player = Manager.createPlayer(mediaURL); player.addControllerListner(this); } catch (Exception e) { System.err.println("Got exception "+e); } } public void start() { player.start(); } public void stop() { player.stop(); player.deallocate(); } public void destry() { player.close(); } public synchronized void controllerUpdate(ControllerEvent event) { if (event instanceof RealizeCompleteEvent) { Component comp; if ((comp = player.getVisualComponent()) != null) add ("Center", comp); if ((comp = player.getControlPanelComponent()) != null) add ("South", comp); validate(); } } }
【０１１６】［２.３ アプレットの初期化(initializi
ng)］Javaアプレットが始動すると、その initメソッド
が自動的に呼び出される。ユーザは init を無効(overr
ide)にしてアプレットを始動させる準備をする。Player
Applet は init において以下の４つのタスクを実行す
る： １.アプレットの FILEパラメータを取り出す。 ２. FILEパラメータを使用してメディア・ファイルを探
し出し、そのメディア・ファイルを記述するＵＲＬオブ
ジェクトを構築する。 ３. Manager.createPlayer を呼び出すことでメディア
・ファイル用のプレイヤを作成する。 ４. addControllerListener を呼び出すことで新規プレ
イヤにコントローラ・リスナーとしてアプレットを登録
する。リスナーとして登録すればプレイヤがメディア・
イベントを通知する時はいつでも PlayerApplet の con
trollerUpdateメソッドが自動的に呼び出される。プレ
イヤはその状態が変わる度にメディア・イベントを通知
する。このような機構によりプレイヤの状態間遷移をコ
ントロールでき、プレイヤがユーザの要求を処理できる
状態にあることを保証できる。（詳細な情報については
「プレイヤの状態(states)」（１.４）を参照のこ
と）。
【０１１７】 public void init() { setLayout(new BraderLayout()); // 1. Get the FILE parameter. String mediaFile = getParameter("FILE"); try { // 2. Create a URL from the FILE parameter. The URL // class is defined in java.net. URL mediaURL = new URL(getDocumentBase(), mediaFile); // 3. Create a player with the URL object. player = Manager.createPlayer(mediaURL); // 4. Add PlayerApplet as a listner on the new player. player.addControllerListner(this); } catch (Exception e) { System.err.println("Got exception "+e); } }
【０１１８】［２.４ プレイヤのコントロール］アプ
レット・クラスはアプレットが入っているページを開閉
する時に自動的に呼び出す開始メソッドと停止メソッド
を定めている。ユーザはこれらのメソッドを無効にして
アプレットが開始するたびに、また停止するたびに何が
起こるか定める。
【０１１９】PlayerApplet は start を実装して apple
t が始動する時はいつもプレイヤを始動させる：
【０１２０】
【０１２１】同様に、PlayerApplet は以下の通り stop
を無効にしてプレイヤを停止させて、その割当て領域
を解放する：
【０１２２】
【０１２３】このプレイヤの割当て領域を開放すれば別
のプレイヤの始動を妨げるどのような資源も解放され
る。例えば、このプレイヤがハードウェア装置を使用し
てそのメディアを表現する場合には、deallocate はそ
の装置を解放して他のプレイヤが当該ハードウェア装置
を使用できるようにする。
【０１２４】アプレットが終了すると、destroy をコー
ルしてアプレットで作成されたどんな資源も一掃する。
PlayerApplet は destroy を無効にしてプレイヤを閉じ
る。プレイヤを閉じると、使用している資源が全部解放
されて、プレイヤが永久に遮断(shut down)される。
【０１２５】
【０１２６】［２.５ メディア・イベントへの対応］P
layerApplet は initメソッドで ControllerListener
として登録されてプレイヤからメディア・イベントを受
け取る。このようなメディア・イベントに対応するため
に、PlayerApplet はプレイヤがイベントを通知する時
に自動的にコールされる controllerUpdateメソッドを
実装する。
【０１２７】PlayerApplet はイベントの１タイプ、す
なわち RealizeCompleteEvent に対応する。プレイヤが
RealizeCompleteEvent を通知する時には PlayerApple
t は以下のプレイヤのコンポーネントを表現する：
【０１２８】 public synchronized void controllerUpdate(ControllerEvent event) { if (event instanceof RealizeCompleteEvent) { Component comp; if ((Comp = player.getVisualComponent()) != null) add ("South", comp); validate(); }
【０１２９】プレイヤのユーザ・インタフェース・コン
ポーネントはプレイヤが Realizedとなるまで表現でき
ない。Unrealizedプレイヤはそのメディア・ストリーム
についてはそのユーザ・インタフェース・コンポーネン
トにアクセスできるほどは知ってはいない。PlayerAppl
et はプレイヤが RealizeCompleteEvent を通知するの
をってプレイヤのビジュアル・コンポーネントとデフォ
ルト・コントロールパネルをアプレット・コンテナに追
加することによりそれらを表現する。validateをコール
すると、レイアウト・マネージャがトリガされてこのよ
うな表現を更新して、新規コンポーネントを含むように
する。
【０１３０】［３.０ プレイヤの作成と表現］ユーザ
はメディアマネージャを通じて間接的にプレイヤを作成
する。プレイヤを表現するためにプレイヤのコンポーネ
ントを得て、それらをアプレット表現スペース又はアプ
リケーション・ウインドウに追加する。
【０１３１】［３.１ プレイヤの作成］新規プレイヤ
を必要とする時には createPlayer を呼び出すことで、
マネージャから、そのプレイヤを要求する。マネージャ
は適切なプレイヤを作成するためにユーザが指定したメ
ディアＵＲＬ又は MediaLocator を使用する。
【０１３２】ＵＲＬは対応する適切な URLStreamHandle
r がインストールされる場合にのみうまく構築される。
MediaLocator はこのような制限はない。
【０１３３】このようなレベルの間接的処置により新規
のプレイヤをシームレスに統合できる。クライアントの
観点からたとえ新規プレイヤが、実際に交換可能部分か
ら構築されるか、あるいは実行時にダイナミックローデ
ィングされても、このプレイヤはつねに同じ方法で作成
される。
【０１３４】［３.２ プレイヤとプレイヤコントロー
ルの表現］ＪＭＦはメディア・ストリームを表現するた
めにタイミング・レンダリングモデルを指定するが、プ
レイヤのインタフェース・コンポーネントは実際に jav
a.awt、すなわち画面表現用の Java のコア・パッケー
ジを用いて表現される。プレイヤは２つのタイプのＡＷ
Ｔコンポーネント、すなわち、そのビジュアル・コンポ
ーネントとそのコントロールコンポーネントを持つこと
ができる。
【０１３５】［３.２.１ プレイヤのビジュアル・コン
ポーネントの表現］プレイヤがメディア・データを表現
するコンポーネントはビジュアル・コンポーネントと呼
ばれる。オーディオプレイヤでもウェーブ・フォーム表
現又は動画キャラクタ等のビジュアル・コンポーネント
を持つ場合もある。
【０１３６】プレイヤのビジュアル・コンポーネントを
表現するにはユーザは以下のことを行う： １． getVisualComponent を呼び出すことによりこのビ
ジュアル・コンポーネントを得る。 ２．このビジュアル・コンポーネントをアプレット表現
スペース又はアプリケーション・ウインドウに追加す
る。
【０１３７】このビジュアル・コンポーネントを通じて
ｘ座標やｙ座標のようなプレイヤの表現プロパティを利
用できる。プレイヤコンポーネントのレイアウトはＡＷ
Ｔレイアウト・マネージャを通じてコントロールされ
る。
【０１３８】［３.２.２ プレイヤのコントロールの表
現］プレイヤはユーザがメディア表現をコントロールで
きるコントロール・パネルを備えていることが多い。例
えば、プレイヤは一組のボタンと対応づけてメディア・
ストリームを開始，停止，休止し，またスライド調節装
置と対応づけてボリュームを調節する。
【０１３９】あらゆる Java Mediaプレイヤはデフォル
トのコントロール・パネルを備えている。プレイヤのデ
フォルト・コントロール・パネルを表現するためには g
etControlPanelComponent を呼び出すことでそのコント
ロール・パネルを得て、それをアプレット表現スペース
又はアプリケーション・ウインドウに追加する。カスタ
ム・ユーザ・インタフェースを定めた方がよいと思う場
合には標準コントロール・パネルを実装するインタフェ
ースにアクセスする。
【０１４０】プレイヤのコントロール・パネルのコンポ
ーネントはしばしばプレイヤとプレイヤコントロールの
双方と対話する。例えば、プレイヤを始動，停止するか
又はそのメディア・タイムをセットするためにそのコン
トロール・パネルは直接にプレイヤを呼び出す。しか
し、多くのプレイヤはユーザが管理できる他のプロパテ
ィを持っている。例えば、ビデオプレイヤを用いれば、
ユーザはプレイヤインタフェースを通じて管理されない
輝度とコントラストを調節できることもある。これらの
タイプのコントロールを扱うためにＪＭＦは Control
インタフェースを定める。
【０１４１】メディアプレイヤはコントロール動作を定
めかつ対応するユーザ・インタフェース・コンポーネン
トを備えた Control オブジェクトをいくつでも有する
ことができる。ユーザはプレイヤ上で getControls を
呼び出すことでこのようなコントロールを得ることがで
きる。例えば、プレイヤが CachingControl インタフェ
ースをサポートするかどうか判断し、もしサポートする
のであれば CachingControl を得るために以下の通りに
getControls を呼び出すことができる。
【０１４２】 Control[] controls = player.getControls(); for (int i = 0; i < controls.length; i++) { if (controls[i] instanceof CachingControl) { cachingControl = (CachingControl) controls[i]; } }
【０１４３】どのようなコントロールが特定のプレイヤ
でサポートされるかはプレイヤの実装によって決まる。
【０１４４】［３.２.３ 利得コントロールコンポーネ
ントの表現］GainControl は Control インタフェース
を拡張して、オーディオ利得を調節するための標準ＡＰ
Ｉを提供する。このコントロールを得るために、getGai
nControl を呼び出さなければならない。getControls
はプレイヤの GainControl をリターンしない。GainCon
trol は setLevel や setMute 等のオーディオボリュー
ムを調節するための方法を提供する。他のコントロール
と同様に GainControlはアプレット表現スペース又はア
プリケーション・ウインドウに追加できるＧＵＩコンポ
ーネントと対応づけられる。
【０１４５】［３.２.４ プレイヤのダウンロード進行
(doenload progress)の表現］メディア・データのダウ
ンロードは時間のかかる処理となりかねない。データが
ダウンロードされている間ユーザが待たなければならな
い場合にはダウンロードが進行中であることをユーザに
再確認し、またその処理がどのくらいかかるか何らかの
指示を与えるために、しばしば進行バーを表現する。Ca
chingControlインタフェースはダウンロード進行を報告
できるプレイヤにサポートされる特殊なタイプのコント
ロールである。このインタフェースを用いれば、ダウン
ロード進行バーをユーザに表現することができる。
【０１４６】getControls をコールすればプレイヤが C
achingControl インタフェースをサポートするかどうか
判断できる。もしサポートするのであれば、プレイヤは
進行バーを更新する必要がある時はいつでも CachingCo
ntrolEvent を通知する。ユーザは自分の進行バー・コ
ンポーネントを実装する場合にはこのイベントに注意し
て CachingControlEvent を通知する時はいつでもダウ
ンロード進行を更新することができる。
【０１４７】CachingControl はダウンロードの進行と
ともに自動的に更新されるデフォルトの進行バー・コン
ポーネントも提供する。アプレットにおいてデフォルト
の進行バーを使用するためには以下を実行する： １．ControllerListener インタフェースを実装して co
nrollerUpdate の CachingControlEvent に注意する。 ２.初めて CachingControlEvent を受け取った時には以
下のことを行う： ａ．このイベント上で getCachingControl をコールし
てキャッシングコントロールを得る。 ｂ．CachingControl 上で getProgressBar を呼び出し
てデフォルトの進行バー・コンポーネントを得る。 ｃ．進行バー・コンポーネントをアプレット表現スペー
スに追加する。 ３．CachingControlEvent を受け取るたびにダウンロー
ドが終了したかどうか知るためにチェックする。getCon
tentProgress が getContentLength と同じ値をリター
ンする時には進行バーを削除する。
【０１４８】［４.０ メディア・プレイヤのコントロ
ール］クロックインタフェースとプレイヤインタフェー
スはプレイヤを始動、停止させるための方法を定めてい
る。
【０１４９】［４.１ プレイヤの始動］一般的に star
t を呼び出すことでプレイヤを始動させる。start メソ
ッドはプレイヤにできる限り早くメディア・データの表
現を始めるように指示する。必要に応じて start は re
alize 処理と prefetch 処理を行うことによりプレイヤ
に始動の準備をさせる。Startedプレイヤ上で start を
呼び出す場合にはその結果としてメソッド・コールに答
えて StartEvent を通知するだけである。
【０１５０】クロックは同期用に使用可能な syncStart
メソッドを定義する。詳細については「プレイヤの同
期化」（７.０）を参照のこと。メディア・ストリーム
の特定地点からプレイヤを始動させるためには以下を実
行する： １．setMediaTime を呼び出すことによりメディア・ス
トリームにおいてユーザが開始したいと思っている地点
を指定する。 ２．プレイヤ上で start を呼び出す。
【０１５１】［４.２ プレイヤの停止］以下の通りプ
レイヤが停止する状態が４つある： ・プレイヤ上で stop メソッドを呼び出す時。 ・プレイヤが指定した停止時間に達した時。 ・プレイヤがメディア・データ使い果たした(has run o
ut)時。 ・プレイヤのデータ受信速度があまりにも低速であるた
めに許容できる再生が不可能となる時。
【０１５２】非放送用プレイヤが停止する時にはそのメ
ディア・タイムは凍結される。その後、Stopped プレイ
ヤが再始動する場合にはメディア・タイムはその停止時
間から続行される。放送用プレイヤを停止させる時には
メディア・データの受信だけを停止させる。したがっ
て、このデータは引き続き放送される。放送用プレイヤ
を再始動させる時には放送が時間内にその時点にあれば
再生が再開される。
【０１５３】stop メソッドを用いて直ちにプレイヤを
停止させる。停止したプレイヤ上でstop を呼び出す場
合にはその結果としてメソッド・コールに答えて StopB
yRequestEvent を通知するだけである。
【０１５４】［４.２.１ 指定した時間でのプレイヤの
停止］setStopTime を呼び出せば、プレイヤがいつ停止
すべきか指示できる。プレイヤはそのメディア・タイム
が指定された停止時間を過ぎると停止する。プレイヤの
レートが正である場合、プレイヤはメディア・タイムが
停止時間よりも長いか又は停止時間に等しくなる時には
停止する。プレイヤのレートが負である場合、プレイヤ
はメディア・タイムが停止時間よりも短いか又は停止時
間に等しくなる時には停止する。プレイヤはその現在メ
ディア・タイムが指定された停止時間をすでに超えてい
る場合には直ちに停止する。
【０１５５】例えば、プレイヤのメディア・タイムを
５.０とし、また setStopTime を呼び出して停止時間を
６.０にセットすると仮定する。プレイヤのレートが正
である場合、メディア・タイムは長くなりメディア・タ
イムが６.０よりも長いか又は等しくなる時にはプレイ
ヤは停止する。しかしながら、プレイヤのレートが負で
ある場合、プレイヤは逆方向に再生しようとし、メディ
ア・タイムがその停止時間をすでに超えているために直
ちに停止する。（プレイヤのレートの詳細については
「プレイヤのレートのセット」（６.３）を参照のこ
と。）
【０１５６】ユーザは常に停止プレイヤ上で setStopTi
me を呼び出すことができる。しかしながら、停止時間
が現在はセットされていない場合にのみ、停止時間を S
tarted プレイヤにセットすることができる。プレイヤ
がすでに停止時間を持っている場合には setStopTime
がエラーをスローする。
【０１５７】getStopTime をコールすれば現在の予定停
止時間を得ることができる。クロックが予定停止時間を
持たない場合には getStopTime は Clock.UNSET をリタ
ーンする。停止時間を削除してプレイヤがメディアの終
了に至るまで継続するようにするために setStopTime(U
NSET)を呼び出す。
【０１５８】［５.０ プレイヤの状態の管理］状態間
の遷移は以下の５つのメソッドを用いてコントロールさ
れる： ・realize（認識） ・prefetch（先取り） ・start（始動） ・deallocate（割当て領域の解除） ・stop（停止） ・close（閉鎖）
【０１５９】以上のメソッドをいつコールするかコント
ロールすることによりプレイヤの状態を管理することが
できる。例えば、ユーザはプレイヤに始動の準備をさせ
た後で実際にプレイヤを始動させることで、始動の待ち
時間を最小限にとどめたいと思う場合がある。
【０１６０】ControllerListenerインタフェースを実装
すればプレイヤの状態の変化に答えてこれらのコントロ
ールメソッドを管理することができる。他の場合にはプ
レイヤの状態遷移を注意することも重要である。例え
ば、ユーザはプレイヤが実現状態になるまでプレイヤの
コンポーネントを得ることはできない。RealizeComplet
eEvent を注意することにより、プレイヤが実現状態に
なると直ちにそれらのコンポーネントを得ることができ
る。
【０１６１】［５.１ プレイヤ始動の準備］大部分の
メディアプレイヤは直ちに始動できない。プレイヤはい
くつかのハードウェアとソフトウェアの条件が満たされ
てはじめて始動できる。例えば、プレイヤがまだ一度も
始動したことがない場合にはメモリにバッファを割り当
てて、メディア・データを格納することが必要である場
合もある。あるいはメディア・データがネットワーク装
置上にある場合にはプレイヤはデータをダウンロードす
る前にネットワーク接続を確立する必要がある場合もあ
る。
【０１６２】たとえプレイヤが以前に始動したことがあ
っても、これらのバッファには現在のメディア位置には
有効でないデータが入っていることもある。
【０１６３】［５.１.１ プレイヤの認識と先取り］Ｊ
ＭＦはプレイヤに始動を準備させる処理を Realizing
（認識中）と Prefetching（先取り中）という２つの段
階に分ける。プレイヤを Realizingし Prefetchingして
から開始すれば、"start"をコールする時にプレイヤが
メディアを表現し出すのにかかる時間が最小限に抑えら
れ、ユーザに対して高応答のインタラクティブな体験が
もたらされることになる。ControllerListenerインタフ
ェースを実装すればこのような処理がいつ発生するのか
コントロールすることができる。
【０１６４】ユーザは Realizing をコールし、プレイ
ヤを認識状態に移して認識処理を開始する。ユーザは p
refetching をコールし、プレイヤを先取り状態に移し
て先取り処理を開始する。realizeメソッドとprefetch
メソッドは非同期であって直ちにリターンする。プレイ
ヤが要求された操作を完了した時にはプレイヤは Reali
zeCompleteEvent 又は PrefetchCompleteEvent を通知
する。図７の「プレイヤの状態」はこれらの状態のそれ
ぞれでプレイヤが行う操作を説明している。
【０１６５】先取りされた状態のプレイヤは始動を準備
し、その開始待ち時間をさらに短くできない。しかしな
がら、setMediaTime を通じてメディアタイムをセット
すれば、プレイヤは認識状態に戻されてその開始待ち時
間が長くなることもある。
【０１６６】先取りされたプレイヤはシステム資源をタ
イアップすることを念頭におくこと。サウンドカードの
ようないくつかの資源は一度に１つのプログラムでしか
使えないこともあるからこのことは他のプレイヤの始動
を妨げる可能性がある。
【０１６７】［５.１.２ プレイヤが Realized になる
までの阻止(blocking)］プレイヤ上で呼び出すことので
きるメソッドの多くはプレイヤが認識状態にあることを
求めている。ユーザがこれらのメソッドを呼び出す時に
プレイヤが認識状態であることを保証する一つの方法は
realize を呼び出してプレイヤが RealizeCompleteEve
nt を通知するまで阻止するメソッドを実装することで
ある。
【０１６８】注：realize での阻止は不十分な結果が生
む可能性があることを心得ておくこと。例えば、プレイ
ヤが実現している時にアプレットが阻止する場合、Appl
et.start と Applet.stop はその操作を中断できなくな
る。
【０１６９】プレイヤが認識状態となるまで阻止するた
めにはユーザは blockingRealizeと呼ばれるメソッドを
実装することになる。このメソッドはそのプレイヤ上で
realize を呼び出し、また、プレイヤが RealizeCompl
eteEvent を通知してユーザの controllerUpdateメソッ
ドを呼び出す時にリターンする。このためにはユーザは
ControllerListenerインタフェースを実装してプレイ
ヤにリスナーとして登録することが必要である。ユーザ
が複数のプレイヤにリスナーとして登録する場合にはユ
ーザの controllerUpdateメソッドはどのプレイヤが Re
alizeCompleteEvent を通知したのか判断する必要があ
る。（注１）
【０１７０】 boolean realized = false; public synchronized void blockingRealize() { myPlayer.realize(); while (!realized) { try { wait(); } catch (java.lang.InterruptedException e) { status.setText("Interrupted while waiting on realize...exiting."); System.exit(1); } } } public synchronized void controllerUpdate (ControllerEvent event) { if (event instanceof RealizeCompleteEvent) { realized = true; notify(); } else if (event instanceof EndOfMediaEvent) { eomReached = true; } }
【０１７１】注１.この例示コードは Bill Day 及び Ja
vaWorld 誌の許可を得て使用される。この blockingRea
lize の例示コードは Bill Day により、１９９７年４
月号の Web Publishing Inc.のオンライン出版である J
avaWorld誌の"Java Media Framework Player API：Mult
imedia comes to Java"の中で初めて発表された。この
記事全文，例示コードのリスト，実演アプレットについ
ては http://www.javaworld.com/javaworld/jw-04-1997
/jw-04-jmf.html を見てください。
【０１７２】［５.１.３ プレイヤの開始待ち時間の判
断］プレイヤを始動するのにどのくらいの時間が必要で
あるか判断するためにユーザは getStartLatency をコ
ールすることができる。種々の開始待ち時間を持つプレ
イヤでは getStartLatency のリターン値は可能な最長
の開始待ち時間を表す。いくつかのメディア・タイプで
は getStartLatency は LATENCY_UNKNOWN をリターンす
ることもある。
【０１７３】getStartLatency で報告される開始待ち時
間はプレイヤの現在の状態により様々である。例えば、
prefetch操作後 getStartLatency でリターンされる値
は一般にさらに小さい。プレイヤに追加できるコントロ
ーラはプレイヤが Prefetched になると有効な値をリタ
ーンする。（追加されたコントローラの詳細については
「プレイヤを用いて他のコントローラを管理し同期をと
る」（８.０）を参照）
【０１７４】［５.２ プレイヤの始動と停止］start
をコールすると、プレイヤは始動した状態に移る。star
t がコールされたらすぐ、停止したプレイヤにのみ正規
であるメソッドはプレイヤが停止するまでコールするこ
とはできない。
【０１７５】start がコールされ、かつプレイヤが先取
りされていない場合には start は必要に応じて realiz
e操作と prefetch操作を行ってプレイヤを先取りされた
状態に移す。プレイヤは各状態を経て移る時に遷移イベ
ントを通知する。
【０１７６】stop がプレイヤ上でコールされる時には
プレイヤは直ちに停止すると見なされる。したがって、
stop は同期的である。しかしながら、プレイヤは以下
の時には非同期に停止することもできる： ・メディア・ストリームの終わりに至る。 ・setStopTime を用いてあらかじめセットされた停止時
間に達する。 ・プレイヤがデータ欠乏となる。
【０１７７】プレイヤが停止する時にはプレイヤは Sto
pEvent を通知する。プレイヤが停止した理由を判断す
るためにユーザは DeallocateEvent，EndOfMediaEven
t，RestartingEvent，StopAtTimeEvent，StopByRequest
Event，DataStarvedEvent といった特定の停止イベント
に注意しなければならない。
【０１７８】［５.３ プレイヤ資源の解放］deallocat
e メソッドは任意の専用資源を解放し非専用資源の使用
を最小限に抑えるようにプレイヤに指示する。プレイヤ
用のバッファリングとメモリ管理要件は指定されてない
が、大部分の Java Media Player は Java オブジェク
トの標準により大きいバッファを割り当てている。申し
分なく実装されたプレイヤはdeallocated が呼び出され
る時にできる限り多くの内部メモリを解放する。
【０１７９】deallocateメソッドは停止したプレイヤ上
でのみコールすることができる。ClockStartedErrors
を避けるために、ユーザは stop をコールしてから dea
llocate をコールしなければならない。先取りされた状
態か又は先取りされた状態において、プレイヤ上で dea
llocate を呼び出すと認識された状態にリターンされ
る。プレイヤが認識されている間に deallocate が呼び
出される場合にはプレイヤは DeallocateEvent を通知
して Unrealized 状態にリターンする。（プレイヤがい
ったん認識されると、プレイヤは決して非認識状態には
リターンできない。）
【０１８０】一般に、ユーザはプレイヤが 使用されて
いない時に deallocate を呼び出す。例えば、アプレッ
トはその stop メソッドの一部として deallocate を呼
び出さなければならない。deallocate を呼び出せば、
このプログラムは当該システムで使用するために他の資
源を解放しながら、引き続きプレイヤを参照することが
できる。（ＪＭＦにより、以前先取りされた又は始動し
た状態であった認識プレイヤは将来さらに速く開始でき
るようにする情報を保つことを阻止しない）。
【０１８１】プレイヤ（又は他のコントローラ）を終了
してもうそれを使うつもりがない時には close をコー
ルしなければならない。closeメソッドはコントローラ
がもはや使用されず、それ自身が遮断され得ることをさ
す。close を呼び出すと、コントローラが使用した資源
の全部が解放されてコントローラはすべての活動を停止
する。コントローラは閉鎖される時に ControllerClose
dEvent を通知する。閉鎖されたコントローラは再度開
くことができず、閉鎖されたコントローラ上でメソッド
を呼び出すとエラーが発生することもある。
【０１８２】［５.４ ControllerListener インタフェ
ースの実装］ControllerListener はコントローラオブ
ジェクトで発生するイベントを扱うための非同期インタ
フェースである。ControllerListener インタフェース
を用いればユーザは先取りのように時間のかかる可能性
のあるプレイヤ操作のタイミングを管理することができ
る。
【０１８３】ControllerListener インタフェースを実
装するためには以下を行う必要がある： １．あるクラスに ControllerListener インタフェース
を実装する。 ２．そのクラスをユーザがイベントを受け取りたいと思
っているコントローラ上で addControllerListener を
コールすることによりリスナとして登録する。
【０１８４】コントローラがイベントを通知する時には
コントローラはそれぞれの登録済みリスナー上で contr
ollerUpdate を呼び出す。一般に、controllerUpdate
は以下の形式の一連の if−else文として実装される： if(event instanceof EventType){ ... } else if(event instanceof OtherEventType){ ... }
【０１８５】これはユーザの関心のないイベントをフィ
ルタにかける。ユーザはリスナーとして複数のコントロ
ーラに登録した場合にはどのコントローラがそのイベン
トを通知したか判断する必要もある。ControllerEvents
は getSource を呼び出すことにより、ユーザがアクセ
スできるそれらのソースの参照の「スタンプ」となる。
【０１８６】「付録Ｄ：ControllerAdapter」は特定の
イベントに対処するために容易に拡張できる Conroller
Listener の実装用のソースを提供する。
【０１８７】ユーザはコントローラからイベントを受け
取る時に、コントローラがコントロールメソッドを呼び
出す前に適正な状態にあることを保証するためにある追
加処理を行う必要がある場合もある。例えば、停止した
プレイヤに限定されたメソッドをどれかコールする前に
getTargetState をコールすることによりプレイヤの目
標状態をチェックしなければならない。start がコール
されている場合、プレイヤはプレイヤにメディア表現を
準備させるために遷移イベントを通知していることもあ
るが、始動された状態にあると見なされる。
【０１８８】いくつかのタイプの ControllerEvents に
は追加状態情報がスタンプされる。例えば、StartEvent
クラスと StopEvent クラスはそれぞれイベントが発生
したメディア・タイムを回復する(retrieve)することの
できるメソッドを定めている。
【０１８９】［６.０ タイミングの管理］多くの場
合、ユーザは終始単一のメディア・ストリームを再生す
るのではなくてそのストリームの一部を再生するか又は
複数のストリームの再生の同期をとりたいと思う。ＪＭ
Ｆの TimeBase インタフェースと クロックインタフェ
ースはメディア再生のタイミングと同期化を管理するた
めの機構を定めている。
【０１９０】TimeBase は時間のフローを表す。タイム
ベースの時間は変換もリセットもできない。Java Media
Player はその TimeBase を使用して時間を記録する
が、その方法はクォーツ時計が既知の振動数で振動する
水晶を使用して時を刻む方法と同じである。このシステ
ムは指定した基準時間（例えば、１９７０年１月１日）
からナノ秒の単位で時間を測定するマスタ TimeBase を
維持している。システムTimeBase はシステム・クロッ
クにより駆動され、Manager.getSystemTimeBaseメソッ
ドを通じてアクセスできる。
【０１９１】プレイヤのメディア・タイムはプレイヤが
表現しているストリーム中のある時点を表している。こ
のメディア・タイムはストップウォッチとほぼ同様に開
始，停止，リセットすることができる。
【０１９２】クロックは TimeBase とメディア・タイム
との対応付け(mapping)を定めている。図８にメディア
・タイムのセッティングを示す。
【０１９３】Java Media Player は表現しているメディ
ア・ソースについていくつかのタイミング問合せに答え
ることができる。もちろん、タイミング情報はメディア
・ソースとメディア・ソースを格納したネットワーク装
置の双方の物理的な特性と制限に従っている。
【０１９４】Time オブジェクトはある時間単位の量
（例えばナノ秒）を表す。ユーザはプレイヤのタイミン
グ情報を問い合わせるかあるいはセットする時に Time
オブジェクトを使用する。
【０１９５】［６.１ メディア・タイムのセット］プ
レイヤの media time（メディア・タイム）をセットす
ることはメディア・ストリーム中に読取り位置をセット
することに等しい。ファイルのようなメディア・データ
ソースではメディア・タイムが拘束される。すなわち、
最大メディア・タイムはメディア・ストリームの終わり
で定められる。
【０１９６】media time をセットするには setMediaTi
me を呼び出してセットしたいと思う時間を表す Timeオ
ブジェクトを手渡す。
【０１９７】［６.２ 現在の時間の取得］getMediaTim
e を呼び出すことでプレイヤの現在のメディア・タイム
を表す Time オブジェクトがリターンされる。プレイヤ
がメディア・データを表現していない場合にはこれはメ
ディア表現が開始する点である。media time と特定フ
レームとの１対１の対応はない。各フレームは一定期間
の間表現され、またメディア・タイムはその期間中引き
続き進む。
【０１９８】例えば、図９に示すようにユーザは５秒間
各スライドを表現するスライドショープレイヤを備えて
いると考えてみる。すなわち、このプレイヤは本質的に
フレーム・レートが０.２フレーム／秒である。
【０１９９】第１のフレームが表現されている時に時間
０.０でプレイヤを始動させる場合にはそのメディア・
タイムは０.０から５.０に進む。時間２.０でプレイヤ
を始動させる場合には第１のフレームは時間５.０に達
するまでの３秒間表現される。
【０２００】プレイヤの TimeBase を得て以下の getRe
fTime を呼び出すことにより、プレイヤの現在 time-ba
se time（タイムベース時間）を得ることができる。 myCurrentTime = player1.getTimeBase().getRefTim
e();
【０２０１】プレイヤが実行中である時に mapToTimeBa
se を呼び出すことにより、特定のメディア・タイムに
対応する time-base time を得ることができる。
【０２０２】［６.３ プレイヤのレートのセット］プ
レイヤのレートはタイムベース時間に対してメディア・
タイムがどのように変わるか判断する。すなわち、この
レートはタイムベース時間のあらゆる単位に対してプレ
イヤのメディア・タイムが何単位進むのか定めている。
プレイヤのレートは時の基準化因数(temporal scale fa
ctor)と見なすことができる。例えば、２.０のレートは
プレイヤが始動する時タイムベース時間の２倍の速さで
メディア・タイムが過ぎてゆくことをさす。
【０２０３】理論的にはプレイヤのレートは逆方向にメ
ディアを再生するものと解される負のレートを用いて任
意の実数にセットされることになる。しかしながら、い
くつかのメディア・フォーマットはフレーム間で依存関
係があり、したがって、逆方向にあるいは非標準のレー
トでそれらのフォーマットを再生することは不可能ある
いは非実用的となる。
【０２０４】プレイヤ上で setRate を呼び出す時には
そのメソッドはたとえ変わっていなくとも実際にセット
されているレートをリターンする。プレイヤは１.０の
レートをサポートすることだけが保証されている。
【０２０５】［６.４ プレイヤの持続期間の取得］ユ
ーザのプログラムは所定のメディア・ストリームが実行
する長さを判断するのに必要なこともあるから、すべて
のコントローラは Durationインタフェースを実装して
いる。このインタフェースには単一のメソッドである g
etDurationが含まれる。持続期間は１.０のデフォルト
・レートで再生される場合メディア・オブジェクトが実
行する時間の長さを表す。メディア・ストリームの持続
期間はプレイヤを通じてのみアクセスできる。
【０２０６】getDuration が呼び出される時に持続期間
を判断できない場合には DURATION_UNKNOWN がリターン
される。これはプレイヤがメディア・ソースの持続期間
を利用できるような状態にまだきていない場合に起こり
かねない。後でこの持続期間が利用できる場合があり、
getDuration への呼出しで持続期間の値がリターンされ
ることになる。メディア・ソースが生放送の場合のよう
に定められた持続期間を持たない場合には getDuration
は DURATION_UNBOUNDED をリターンする。
【０２０７】［７.０ プレイヤの同期化］複数メディ
ア・ストリームの再生の同期をとるためにプレイヤを同
一の TimeBase と対応づけることにより、プレイヤの同
期をとることができる。こうするためにユーザは クロ
ックインタフェースで定められた getTimeBase メソッ
ドと setTimeBase メソッドを使用する。例えば、以下
のようにプレイヤ２のタイム・ベースを使用するように
プレイヤ１をセットすれば、プレイヤ１をプレイヤ２と
同期させることができる。 player1.setTimeBase(player2.getTimeBase());
【０２０８】プレイヤを同一の TimeBase と対応づける
ことによりプレイヤの同期をとる時にはなお個別に各プ
レイヤのコントロールを管理しなければならない。同期
のとられたプレイヤをこのようなやり方で管理すること
が複雑であるために、ＪＭＦはプレイヤがどんなコント
ローラでもコントロールできる機構を提供する。プレイ
ヤはこれらのコントローラの状態を自動的に管理して単
一のコントロール点を通じてグループ全体と対話できる
ようにしている。詳細については「プレイヤを使用し
て、他のコントローラを管理し、同期をとる」（８.
０）を参照のこと。
【０２０９】ある場合にユーザは複数のプレイヤの同期
を自分自身で管理して他と関係なくレート又はメディア
・タイムをコントロールできるようにしたいと思う場合
がある。
【０２１０】こうする場合、ユーザは以下を行わなけれ
ばならない： ・同期したプレイヤそれぞれについてリスナーとして登
録する。 ・他のプレイヤを駆動するためにどのプレイヤのタイム
・ベースを使用するつもりであるのか判断し、同期した
プレイヤにそのタイム・ベースをセットする。全部のプ
レイヤが新規のタイム・ベースをとることができるとは
限らない。例えば、同期をとりたいと思うプレイヤの１
つがプッシュ・データソースを持っている場合、プレイ
ヤのタイムベースを使用して他のプレイヤを駆動しなけ
ればならない。 ・レートをプレイヤのすべてにセットする。ユーザが指
定するレートをプレイヤがサポートできない場合にはプ
レイヤは使用されたレートをリターンする。（プレイヤ
がサポートするレートを問い合わせるための機構はな
い。） ・プレイヤの状態の同期をとる。（例えば、プレイヤの
すべてを停止する。） ・プレイヤの処理の同期をとる： ・各プレイヤにメディア・タイムをセットする。 ・プレイヤのすべてを先取りする。 ・同期プレイヤの中で最大開始待ち時間を判断する。 ・最大待ち時間を考慮に入れた時間を用いて syncStart
を呼び出すことで、プレイヤを始動させる。
【０２１１】ユーザはプレイヤのすべてについて遷移イ
ベントに注意し、イベントが通知されたものがどれであ
るか覚えていなければならない。例えば、ユーザはプレ
イヤを先取りする時には syncStart を呼び出す前にプ
レイヤのすべてが先取りされた状態であることを確信で
きるように、PrefetchComplete イベントを通知したか
覚えておく必要がある。同様に、同期したプレイヤが特
定の時間に停止するように求める時にはユーザは各プレ
イヤで通知された停止イベントを待ち受けて実際にプレ
イヤのすべてがいつ停止したか判断する必要がある。
【０２１２】いくつかの場合に同期したプレイヤで通知
されるイベントに対しては慎重に対処する必要がある。
プレイヤの状態を確信するために、ユーザはいくつかの
段階において同期したプレイヤが全て同一状態に達する
のを待ってから継続する必要がある場合もある。
【０２１３】例えば、１つのプレイヤを用いて同期した
プレイヤグループを駆動すると仮定する。ユーザはこの
１つのプレイヤと対話してメディア・タイムを１０にセ
ットしてプレイヤを始動させ、次にそのメディア・タイ
ムを２０に変更する。次にユーザは以下を行う： ・最初の setMediaTime コールを同期プレイヤのすべて
に次々と渡す。 ・プレイヤを始動するためにプレイヤ上で prefetch を
コールする。 ・第２回のセット・メディア・タイムの要求を受け取る
とプレイヤ上で stopをコールする。 ・新規の時間を用いてプレイヤ上で setMediaTime をコ
ールする。 ・先取り操作を再開する。 ・プレイヤのすべてが先取りされた時にはそれらのプレ
イヤの開始待ち時間を考慮に入れて syncStart をコー
ルすることでプレイヤを始動させる。
【０２１４】このような場合、プレイヤのすべてから P
refetchCompleteイベントを単に待ち注意してから sync
Start をコールするだけでは十分でない。ユーザはこれ
らのイベントが第１又は第２の prefetch 操作に答えて
通知されたかどうかわからない。このような問題を回避
するために、ユーザは stop を呼び出してプレイヤのす
べてが stop イベントを通知するのを待ってから継続す
る時に阻止することができる。このようにすれば、ユー
ザが受け取る次回の PrefetchComplete イベントが実際
にユーザに関心のあるイベントであることが保証され
る。
【０２１５】［８.０ プレイヤを使用して他のコント
ローラを管理し、同期をとる。］syncStart を用いて手
動でプレイヤの同期をとるには同期プレイヤのすべての
状態を入念に管理することが必要である。ユーザはイベ
ントに注意し、適宜それらのプレイヤ上でコントロール
メソッドを呼び出して各プレイヤを個別にコントロール
しなければならない。ほんの少数のプレイヤでさえこれ
は直ちに困難なタスクとなる。プレイヤインタフェース
を通じて、ＪＭＦはより簡単な解決法を提供する。ある
プレイヤを用いればどんなコントローラの操作でも管理
できる。
【０２１６】ユーザは管理プレイヤと対話する時に適宜
管理されるコントローラにユーザの指示を自動的に次々
と渡す。管理プレイヤは他のコントローラのすべてにつ
いても状態管理と同期化を引き受けている。
【０２１７】このような機構は addController メソッ
ドと removeController メソッドを通じて実装される。
プレイヤ上で addController をコールする時にはユー
ザが指定するコントローラはプレイヤで管理されるコン
トローラのリストに追加される。逆に removeControlle
r をコールする時には指定したコントローラを管理され
るコントローラのリストから削除する。
【０２１８】一般に、ユーザはプレイヤ又は他のコント
ローラの同期をとる必要がある時にはこの addControll
er 機構を使用しなければならない。これは個々に同期
したプレイヤを管理しようとするよりも、簡単で，速
く，しかもエラーを犯しにくくする。
【０２１９】プレイヤがコントローラのコントロールを
受ける時には以下となる： ・コントローラはプレイヤのタイムベースを引き受け
る。 ・プレイヤの持続期間はコントローラの持続時間とプレ
イヤ自身のうち長い方のものとなる。複数のコントロー
ラがプレイヤのコントロールのもとに置かれる場合には
プレイヤの持続期間はそれらのコントローラのすべての
持続期間のうちでもっとも長いものである。 ・プレイヤの開始待ち時間はコントローラの開始待ち時
間とプレイヤ自身のうち長い方のものとなる。複数のコ
ントローラがプレイヤのコントロールのもとに置かれる
場合にはプレイヤの開始待ち時間はそれらのコントロー
ラのすべての開始待ち時間のうちでもっとも長いもので
ある。
【０２２０】追加されたすべてのコントローラがイベン
トを通知した後で管理プレイヤだけが非同期メソッドに
ついて完了イベントを通知する。管理プレイヤは適宜管
理されるコントローラで生成した他のイベントを再度通
知する。
【０２２１】［８.１ コントローラの追加］addContro
ller メソッドを使用して特定のプレイヤで管理された
コントローラのリストにコントローラを追加する。追加
するためにはコントローラは実現化状態になければなら
ない。そうでなければ NotRealizedError をスローす
る。２つのプレイヤは互いのコントロール下に置くこと
はできない。例えば、プレイヤ１がプレイヤ２のコント
ロール下に置かれている時にプレイヤ２をプレイヤ１の
コントロール下に置く場合は必ずまず最初にプレイヤ１
をプレイヤ２のコントロールからはずす。
【０２２２】コントローラがいったんプレイヤに追加さ
れると、追加されたコントローラ上では直接メソッドを
コールしない。追加されたコントローラをコントロール
するためにユーザは管理プレイヤと対話する。プレイヤ
２にプレイヤ１をコントロールさせるために、以下をコ
ールする： player2.addController(player1);
【０２２３】［８.２ 追加コントローラの操作を管理
する］特定のプレイヤで管理されたコントローラグルー
プの操作をコントロールするために、ユーザは管理プレ
イヤと直接対話する。被管理コントローラ上では直接コ
ントロールメソッドをコールしてはならない。
【０２２４】例えば、管理されるコントローラのすべて
に始動を準備させるために管理プレイヤ上で prefetch
を呼び出す。同様に、管理されるコントローラを始動さ
せたいと思う時には管理プレイヤ上で start を呼び出
す。管理プレイヤはコントローラのすべてが先取りされ
た状態であるか確かめてコントローラの中で最大開始待
ち時間を判断し、さらに、これらのコントローラを始動
するために syncStartを呼び出して最大開始待ち時間を
考慮に入れた時間を指定する。
【０２２５】管理プレイヤ上でコントローラメソッドを
呼び出す時にはプレイヤは適宜管理されるコントローラ
にメソッド呼出しを伝える。管理されるコントローラ上
でコントローラメソッドを呼び出す前にプレイヤはその
コントローラが適正な状態にあることを保証する。以下
の表は管理プレイヤ上でコントロールメソッドを呼び出
す時に何が管理されるコントローラに起こるのか記述し
ている。
【０２２６】
【表２】
【０２２７】［８.３ コントローラの除去］removeCon
troller メソッドを使用して特定のプレイヤで管理され
たコントローラのリストからコントローラを除去する。
プレイヤ１のコントロールをプレイヤ２に解除させるた
めに、以下を呼び出す： player2.removeController(player1);
【０２２８】［９.０ ＪＭＦの拡張］ＪＭＦ構成を用
いれば上級開発者は新規タイプのコントローラ及びデー
タソースを作成し統合することができる。例えば、ユー
ザは新規プレイヤを実装して決まったメディア・フォー
マットをサポートすることもある。
【０２２９】本項目はＪＭＦプレイヤ構成を紹介し新規
プレイヤと DataSource をＪＭＦに組み入れる方法を説
明している。
【０２３０】［９.１ プレイヤ構成の理解］「プレイ
ヤの作成」（３.１）で説明された通り、クライアント
・プログラマは Manager.createPlayer を呼び出して特
定のメディア・ソースに対して新規プレイヤを得る。cr
eatePlayer が呼び出される時には適切なプレイヤを作
成して、そのコーラ(caller)にリターンされる。
【０２３１】マネージャは特定のメディア・ソースに対
してプレイヤを構築する。まず最初にＵＲＬ又は Media
Locator から DataSource を構築し、次にそれを用いて
プレイヤを作成する。（DataSource はプロトコルに固
有のメディア・データのソースである。プレイヤは通常
DataSource を使用してメディア・コンテンツの転送を
管理する。）
【０２３２】プレイヤを作成する時にマネージャは図１
０に示された以下を行う： ・指定したプロトコルに対して連結された DataSource
を得る。 ・DataSource で指定されたコンテンツ・タイプに対し
てプレイヤを得る。 ・DataSource をプレイヤにアタッチする。
【０２３３】［９.１.１ DataSource の探出し(locati
ng)］createDataSource メソッドは指定した MediaLoca
tor に適切な DataSourceを探し出して実体化する。こ
うするために、このメソッドはまず最初に DataSource
クラス名のサーチリストを作成し、次に有用なデータソ
ースが見つかるまで当該リスト中の各クラスを経て進
む。DataSource クラス名のサーチリストを作成するた
めに createDataSource は以下を行う： １．PackageManager からプロトコル・パッケージ・プ
リフィックスのベクトルを得る。 ２．以下の形式のクラス名を追加する： <package-prefix>.media.protocol.<protpcol>.DataSou
rcefor each <package-prefix>in the protocol packag
e-prefix-vector.
【０２３４】マネージャは実体化でき、かつ MediaLoca
tor を接続できる DataSource を見つけるまでリスト中
の各クラスを経て進む。
【０２３５】［９.１.２ プレイヤの探出し］createPl
ayer メソッドは類似する機構を用いて特定の DataSour
ce に適切なプレイヤを探し出して実体化する。プレイ
ヤはあるタイプの MediaHandler であってこれは DataS
ource からデータを読み取るオブジェクトである。Medi
aHandler はそれらがサポートするコンテント・タイプ
で識別される。マネージャは DataSource から得られた
コンテント・タイプ名を使用して MediaHandler オブジ
ェクトを見つける。ＪＭＦは２つのタイプの MediaHand
ler，Player 及び MediaProxy をサポートしている。
【０２３６】MediaProxy はある DataSource からのコ
ンテントを処理して別の DataSourceを作成する。一般
に、MediaProxy はサーバに接続してメディア・データ
を得るのに必要な情報が全部入っているテキスト構成を
読み取る。
【０２３７】createPlayer が呼び出される時にはマネ
ージャはまず最初に DataSource からのコンテント名と
PackageManager でリターンされたインストールされた
パッケージのリストを用いてクラス名のサーチリストを
作成する。次にマネージャは構築でき、かつ DataSourc
e をアタッチできる MediaHandler を見つけるまでリス
ト中の各クラスを経て進む。
【０２３８】MediaHandler がプレイヤである場合には
その処理は終了し、マネージャは新規プレイヤをリター
ンする。MediaHandler が MediaProxy である場合には
マネージャは MediaProxy から新規 DataSource を得
て、DataSource がサポートするコンテント・タイプに
ついて新規リストを作成してこのサーチ処理を繰り返
す。
【０２３９】適切なプレイヤが見つからなければコンテ
ント・タイプ名の代りに"unknown"を使ってこの手順が
繰り返される。「unknown」のコンテント・タイプはし
ばしばプラットフォームに依存するやり方で非常に様々
なメディア・タイプを扱うことのできる総合プレイヤに
よってサポートされる。
【０２４０】MediaHandler クラス名のサーチリストを
構築するために createPlayer は以下を行う： １．PackageManager からコンテント・パッケージ・プ
レフィックスのベクトルを得る。 ２．以下の形式のクラス名を追加する： <package-prefix>.media.content.<content type>.Hand
lerfor each <package-prefix>in the content package
-prefix-vector.
【０２４１】［９.２ 新規プレイヤ実装の統合］ユー
ザはＪＭＦの他の部分とシームレスに働くことのできる
プレイヤのカスタム実装を作成できる。プレイヤをＪＭ
Ｆに統合するためには以下を行う必要がある： ・Player.setSource を実装して DataSource をチェッ
クし、プレイヤがそのタイプのソースを扱うことができ
るかどうか判断する。クライアント・プログラマが cre
atePlayer を呼び出す時マネージャが適切なプレイヤを
探すと setSource が呼び出される。 ・新規プレイヤのクラスが入っているパッケージをイン
ストールする。 ・PackageManager でコントロールされるコンテント・
パッケージ・プリフィックスのリストに、そのパッケー
ジ・プリフィックスを追加する。このマネージャはある
プレイヤを探すために用いるコンテント・パッケージ・
プリフィックスのリストについて PackageManager に問
い合わせる。
【０２４２】例えば、コンテント・タイプ mpeg.sys に
対して新規プレイヤをインテグレートするためにはユー
ザは新規プレイヤのクラスが入っている下記の通り呼び
出されるパッケージを作成してインストールすることに
なる： <package-prefix>.media.content.mpg.sys
【０２４３】パッケージ・プリフィックスはユーザのコ
ード用の識別子（例えば、COM.yourbiz）である。ユー
ザのインストレーション・プログラムはまた PackageMa
nagerで管理されるコンテント・パッケージ・プリフィ
ックスのリストにユーザのパッケージ・プリフィックス
を追加することも必要である。
【０２４４】 Vector packagePrefix = PackageManager.getContentPrefixList(); string myPackagePrefix = new String("COM.yourbiz"); // Add new package prefix to end of the package prefix list. packagePrefix.addElement(myPackagePrefix); PackageManager.setContentPrefixList(); // Save the changes to the package prefix list. PackageManager.commitContentPrefixList();
【０２４５】［９.３ 新規データソースの実装］DataS
ource はメディア・プロトコル・ハンドラの抽象化であ
る。ユーザは新規タイプの DataSource を実装すれば、
PullDataSource 又は PushDataSourceを拡張することに
より追加プロトコルをサポートすることができる。ユー
ザの DataSource はそのストリーム中のメディア位置の
指定時間への変更をサポートしている場合には Positio
nableインタフェースを実装しなければならない。DataS
ource がそのストリーム中の特定の地点にシークする処
理をサポートしている場合には対応する SourceStream
は Seekable インタフェースを実装しなければならな
い。
【０２４６】DataSource は SourceStream の集まりを
管理する。PullDataSource だけがプル・データ・スト
リームをサポートしている。PullDataSource は PullSo
urceStream の集まりを管理する。PushDataSource だけ
がプッシュ・データ・ストリームをサポートしている。
PushDataSource は PushSourceStream の集まりを管理
する。ユーザは新規 DataSource を実装する時には対応
するソース・ストリーム、すなわち PullSourceStream
又は PushSourceStream を実装する必要もある。
【０２４７】新規の PullDataSource，FTPDataSource
が実装される方法を示した例については「付録Ｂ：サン
プル・データソースの実装」を参照のこと。
【０２４８】［９.４ 新規データソースの実装の統
合］カスタム DataSource の実装をＪＭＦに統合するた
めの機構はあるプレイヤを統合するのに用いられる機構
に類似している。ユーザは以下を行う必要がある： ・新規 DataSource クラスが入っているパッケージをイ
ンストールする。 ・PackageManager でコントロールされるプロトコル・
パッケージ・プリフィックスのリストにそのパッケージ
・プリフィックスを追加する。このマネージャはある D
ataSource を探すために用いるプロトコル・パッケージ
・プリフィックスのリストについて PackageManager に
問い合わせる。
【０２４９】［付録Ａ：Ｊａｖａ Ｍｅｄｉａ Ａｐｐ
ｌｅｔ］本 Java Applet は Java Media プログラムに
おいて適正なエラーチェックを実演するものである。Pl
ayerApplet と同様、本 Java Applet はメディア・イベ
ント・リスナーを用いて単純なメディア・プレイヤを作
成する。このアプレットは始動するとすぐにメディア・
クリップの再生を開始する。メディアが終わりになる
と、このクリップは初めから再生する。
【０２５０】 -------------------------------------------------------------------- import java.applet.Applet; import java.awt.*; import java.lang.String; import java.net.URL; import java.net.MalformedURLException; import java.io.IOException; import javax.media.*; /** * This is a Java Applet that demonstrates how to create a simple * media player with a media event listener. It will play the * media clip right away and continuously loop. * * <!-- Sample HTML * <applet code=TypicalPlayerApplet width=320 height=300> * <param name=file value="Asternmy.avi"> * </applet> * --> * / public class TypicalPlayerApplet extends Applet implements ControllerListener { // media player Player player = null; // component in which video is a playing Component visualComponent = null; // controls gain, position, start, stop Component controlComponent = null; // displays progress during download Component progressBar = null; /** * Read the applet file parameter and create the media * player. * / public void init() { setLayout(new BroaderLayout()); // input file name from html param String MediaFile = null; // URL for our media file URL url = null; // URL for doc containing applet URL codeBase = getDocumentBase(); // Get the media filename info. // The applet tag should contain the path to the // source media file, relative to the html.page. if ((mediaFile = getParameter("FILE")) == null) Fatal("Invalid media file parameter"); try { // Create an url from the name and the url to the // document containing this applet. if ((url = new URL(codeBase, mediaFile)) == null) Fatal("Can't build URL for " + mediafile); // Create an instance of a player for this media if ((player = Manager.createPlayer(url)) == null) Fatal("Could not create player for "+url); // Add ourselves as a listener for player's events player.addControllerListener(this); } catch (MalformatURLException u) { Fatal("Invalid media file URL!"); } catch(IOException i) { Fatal("IO exception creating player for "+url); } // This applet assumes that its start() calls // player.start().This causes the player to become // Realized. Once Realized, the Applet will get // the visual and control panel components and add // them to the Applet. These components are not added // during init() bacause thy are long operations that // would make us appear unresposive to the user. } /** * Start media file playback. This function is called * the first time that the Applet runs and every * time the user re-enters the page. */ public void start() { // Call start() to prefetch and start the player. if (player != null) player.start(); { /** * Stop media file playback and release resources before * leaving the page. * / public void stop() { if (player != null) { player.stop(); player.deallocate(); } } /** * This controllerUpdate function must be defined in order * to implement a ControllerListener interface. This * function will be called whenever there is a media event. */ public synchronized void controllerUpdate(ControllerEvent event) { // If we're getting messages from a dead player, // just leave if (player == null) return; // When the player is Realized, get the visual // and control components and add them to the Applet if (event instanceof RealizeCompleteEvent) { if ((visualComponent = player.getVisualComponent()) != null) add("Center", visual Component); if ((controlComponent = player.getControlPanelComponent()) != null) add("South", control Component); // force the applet to draw the components validate(); } else if (event instanceof CachingControlEvent) { // Put a progress bar up when downloading starts, // take it down when downloading ends. CachingControlEvent e = (CachingControlEvent) event; CatchingControl cc = e.getCachingControl(); long cc_progress = e.getContentProgress(); long cc_length = cc.getContentLength(); // Add the bar if not already there ... if (progressBar == null) if ((progressBar = cc.getProgressBarComponent()) != null) { add("North", progressBar); validate(); } // Remove bar when finished ownloading if (progressBar != null) if (cc_progress == cc_length) { remove (progressBar); progressBar = null; validate(); } } else if (event instanceof EndOfMediaEvent) { // We've reached the end of the media; rewind and // start over player.setMediaTime(new Time(0)); player.start(); } else if (event instanceof ControllerErrorEvent) { // Tell TypicalPlayerApplet.start() to call it a day player = null; Fatal (((ControllerErrorEvent)event).getMessage()); } } void Fatal (String s) { // Applications will make various choices about what // to do here. We print a message and then exit System.err.println("FATAL ERROR: " + s); throw new Error(s); // Invoke the uncaught exception // handler System.exit() is another // choice } } --------------------------------------------------------------------
【０２５１】[付録Ｂ：サンプル・データソースの実
装］このサンプルは新規 DataSource を実装して、追加
プロトコルであるFTPプロトコルをサポートする方法を
実演するものである。以下の２つのクラスがある：・Da
taSource が PullDataSource を拡張して intel.media.
protocol.PullProtocolHandler を実装する。・FTPSour
ceStream が PullSourceStream を実装する。
【０２５２】 FTP Data Source -------------------------------------------------------------------- package COM.intel.media.protocol.ftp; import javax.media.protocol.PullDataSource; import javax.media.protocol.SourceStream; import javax.media.protocol.PullSourceStream; import javax.media.Time; import javax.media.Duration; import java.io.*; import java.net.*; import java.util.Vector; public class DataSource extends PullDataSource { public static final int FTP_PORT = 21; public static final int FTP_SUCCESS = 1; public static final int FTP_TRY_AGAIN = 2; public static final int FTP_ERROR = 3; // used to send commands to server protected Socket controlSocket; // used to receive file protected Socket dataSocket; // wraps controlSocket's output stream protected PrintStream controlOut; // wraps controlSocket's input stream protected InputStream controlIn; // hold (possively multi-line) server response protected Vector response = new Vector(1); // reply code from previous command protected int previousReplyCode; // are we waiting for command reply? protected boolean replyPending; // user login name protected String user = "anonymous"; // user login password protected String password = "anonymous"; // FTP server name protected String hostString; // file to retrieve protected String fileString; public void connect() throws IOException { initCheck(); // make sure the locator is set if (controlSocket != null) { disconnect(); } // extract FTP server name and target filename from locator parseLocator(); controlSocket = new Socket(hostString, FTP_PORT); controlOut = new PrintStream(new BufferedOutputStream( controlSocket.getOutputStream()), true); controlIn = new BufferedInputStream(controlSocket.getInputStream()); if (readReply() == FTP_ERROR) { throw new IOException("connection failed"); } if (issueCommand("USER " + user) == FTP_ERROR) { controlSocket.close(); throw new IOException("USER command failed"); } if (issueCommand("PASS " + password) == FTP_ERROR) { controlSocket.close(); throw new IOException("PASS command failed"); } } public void disconnect() { if (controlSocket == null) { return; } try { issueCommand("QUIT"); controlSocket.close(); } catch (IOException e) { // do nothing, we just want to shutdown } controlSocket = null; controlIn = null; controlOut = null; } public void start() throws IOException { serverSocket serverSocket; InetAddress myAddress = InetAddress.getLocalHost(); byte[] address = myAddress.getAddress(): String portCommand = "PORT "; serverSocket = new ServerSocket(0, 1); // append each byte of our address (comma-separated) for (int i = 0; i < address.length; i++) { portCommand = portCommand + (address[i] & 0xFF) + ","; } // append our server socket's port as two comma-separated // hex bytes portCommand = portCommand + ((serverSocket.getLocalPort() >>> 8) & 0xFF) + "," + (serverSocket.getLocalPort() & 0xFF) // issue PORT command if (issueCommand(portCommand) == FTP_ERROR) { serverSocket.close(); throw new IOException("PORT"); } // issue RETRieve command if (issuCommand("RETR " + fileString) == FTP_ERROR) { serverSocket.close(); throw new IOException("RETR"); } dataSocket = serverSocket.accept(); serverSocket.close(); } public void stop() { try { // issue ABORt command issueCommand("ABOR"); dataSocket.close(); } catch(IOException e) {} } public String getContentType() { // We don't get MIME info from FTP server. This // implementation makes an attempt guess the type using // the File name and returns "unknown" in the default case. // A more robust mechanisms should // be supported for real-world applications. String locatorString = getLocator().toExternalForm(); int dotPos = locatorString.lastIndexOf("."); String extension = locatorString.substring(dotPos + 1); String typeString = "unknown"; if (extension.equals("avi")) typeString = "video.x-msvideo"; else if (extension.equals("mpeg")|| extension.equals("mpeg")) typeString = "video.mpeg"; else if (extension.equals("mov")) typeString = "video.quicktime"; else if (extension.equals("wav")) typeString = "audio.x-wav"; else if (extension.equals("au")) typeString = "audio.basic"; return typeString; } public PullSourceStream[] getStreams() { PullSourceStream[] streams = new PullSourceStream[1]; try { streams[0] = new FTPSourceStream(dataSocket.getInputStream()); } catch(IOException e) { System.out.println("error getting streams"); } return streams; } public Time getDuration() { return Duration.DURATION_UNKNOWN; } public void setUser(String user) { this.user = user; } public String getUser() { return user; } public void setPassword(String password) { this.password = password; } public String getPassword() { return password; } private int readReply() throws IOException { previousReplyCode = readResponse(); System.out.println(previousReplyCode); switch (previousReplyCode / 100) { case 1: replyPending = true; // fall through case 2: case 3: return FTP_SUCCESS; case 5: if (previousReplyCode == 530) { if (user == null) { throw new IOException("Not logged in"); } return FTP_ERROR; } if (previousReplyCode == 550) { throw new FileNotFoundException(); } } return FTP_ERROR } /** * Pulls the response from the server and returns the code as a * number. Returns -1 on failure. */ private int readResponse() throws IOException { StringBuffer buff = new StringBuffer(32); String responseStr; int c; int continuingCode = -1; int code = 0; response.setSize(0); while (true) { while ((c = controlIn.read()) != -1) { if (c == '＼r') { if ((c = controlIn.read()) != '＼n') { buff.append('＼r') } } buff.append((char)c); if (c == '＼n') { break; } } responseStr = buff／toString(); buff.setLength(0); try { code = Integer.parseInt(responseStr.substring(0, 3)); } catch (NumberFormatException e) { code = -1; } catch (StringIndexOutOfBoundsException e) { /* this line does't contain a response code, so * we just completely ignore it */ continue; } response.addElement(responseStr); if (continuingCode ! = -1) { /* we've seen a XXX- sequence */ if (code != continuingCode || (responseStr.length() >= 4 && responseStr.charAt(3) == '-)) { continue; } else { /* seen the end of code sequence */ continuingCode = -1; break; } } else if (responseStr.length() >= 4 && responseStr.charAt(3) == '-') { continuingCode = code; continue; } else { break; } } previousReplyCode = code; return code; } private int issueCommand(String cmd) throws IOException { int reply; if (replyPending) { if (readReply() == FTP_ERROR) { System.out.print("Error reading pending reply＼n"); } } replyPending = false; do { System.out.println(cmd); controlOut.print(cmd + "＼r＼n"); reply = readReply(); } while (reply == FTP_TRY_AGAIN); return reply; } /** * Parses the mediaLocater field into host and file strings */ protected void parseLocator() { initCheck(); String rest = getLocator().getRemainder(); System.out.println("Begin parsing of: " + rest); int p1, p2 = 0; p1 = rest.indexOf("//"); p2 = rest.indexOf("/", p1+2); hostString = rest.substring(p1 + 2, p2); fileString = rest.substring(p2); System.out.println("host: " + hostString + " file: " + fileString); } } --------------------------------------------------------------------
【０２５３】 Source Stream -------------------------------------------------------------------- package intel.media.protocol.ftp; import java.io.*; import javax.media.protocol.ContentDescriptor; import javax.media.protocol.PullSourceStream; import javax.media.protocol.SourceStream; public class FTPSourceStream implements PullSourceStream { protected InputStream dataIn; protected boolean eofMarker; protected ContentDescriptor cd; public FTPSourceStream(InputStream in) { this.dataIn = in; eofMarker = false; cd = new ContentDescriptor("unknown"); } // SourceStream methods public ContentDescriptor getContentDescriptor() { return cd; } public void close() throws IOException { dataIn.close(); } public boolean endOfStream() { return eofMarker; } // PullSourceStream methods public int available() throws IOException { return dataIn.available(); } public int read(byte[] buffer, int offset, int length) throws IOException { int n= dataIn.read(buffer, offset, length); if (n == -1) { eofMarker = true; } return n; } public boolean willReadBlock() throws IOException { if(eofMarker) { return true; } else { return dataIn.available() == 0; } } public long getContentLength() { return SourceStream.LENGTH_UNKNOWN; } } --------------------------------------------------------------------
【０２５４】［付録Ｃ：サンプル・コントローラの実
装］本サンプルは単純なタイム・ライン・コントローラ
をＪＭＦに実装できる方法を例証している。この例には
以下の３つのクラスがある： ・TimeLineController.java Controller. ユーザは一連の時間値（タイム・ラインを
表す）をコントローラに与え、ユーザが現在タイム・ラ
イン中のどの区分にいるのか経過を追う。 ・TimeLineEvent.java タイム・ライン中の区分が変わる時に TimeLineControl
ler で通知されるイベント。 ・EventPostingBase.java Controller メソッドの addControllerListener と rem
oveControllerListener を扱う TimeLineController で
用いられる基本クラス。これはイベントを通知するため
にサブクラスで使用できる postEvent メソッドも提供
する。この実装は本書では示されていない２つの追加ク
ラスも用いている。 ・EventPoster スレッドをスピンしてイベントを ControllerListener
に通知するクラス。 ・BasicClock クロック・メソッドのすべてを実装している単純なクロ
ック実装。
【０２５５】 TimeLineEvent -------------------------------------------------------------------- TimeLineEvent.java import javax.media.*; // TimeLineEvent -- posted by TimeLineController when we have // switched segments in the time line. public class TimeLineEvent extends ControllerEvent { protected int segment; public TimeLineEvent (Controller source, int currentSegment) { super (source); segment = CurrentSegment; } public final int getSegment () { return segment; } } --------------------------------------------------------------------
【０２５６】 EventPostingBase -------------------------------------------------------------------- EventPostingBase.java import javax.media.*; import COM.yourbiz.media.EventPoster; // EventPoster supports two methods; // public EventPoster (); // public void postEvent (ControllerListener who, // ControllerEvent what); // A list of controller listeners that we are supported to send // events to. class ListenerList { ControllerListener observer; ListenerList next; } public class EventPostingBase { protected ListenerList olist; protected Object olistLock; protected EventPoster eventPoster; // We sync around a new object so that we don't mess with // the super class synchronization. EventPostingBase () { olisLock = new object (); } public void addControllerListener (ControllerListener observer) { synchronized (olistLock) { if (eventPoster == null) { eventPoster = new EventPoster (); } ListenerList iter; for (iter = olist; iter ! = null; iter.next) { if (iter.observer == observer) return; } iter = new ListenerList (); iter.next = olist; iter.observer = observer; olist = iter; } } public void removeControllerListener (ControllerListener observer) { synchronized (olistLock) { if (olist == null) { return; } else if (olist.observer == observer) { olist = olist.next; } else { ListenerList iter; for (iter = olist; iter.next != null; iter = iter.next) { if (iter.next.observer == observer) { iter.next = next.next; return; } } } } } protected void postEvent (ControllerEvent event) { synchronized (olistLock) { ListenerList iter; for (iter = olist; iter != null; iter = iter.next) { eventPoster.postEvent (iter.observer, event); } } } } --------------------------------------------------------------------
【０２５７】 TimeLineController -------------------------------------------------------------------- TimeLineController.java import javax.media.*; import COM.yourbiz.media.BasicClock; // This Controller uses two custom classes: // The base class is EventPostingBase. It has three methods: // public void addControllerListener (ControllerListener // observer); // public void removeControllerListener (ControllerListener // observer); // protected void postEvent (ControllerEvent event); // // This Controller posts TimeLineEvents. TimeLineEvent has // two methods: // public TimeLineEvent (Controller who, int // segmentEntered); // public final int getSegment (); public class TimeLineController extends EventPostingBase implements Controller. Runnable { Clock ourClock; // This simple controller really only has two states: // Prefetched and Started. int ourState; long timeLine[]; int currentSegment = -1; long duration; Thread myThread; // Create a TimeLineController giving it a sorted time line. // The TimeLineController will post events indicating when // it has passed to different parts of the time line. public TimeLineController (long timeLine[]) { this.timeLine = timeLine; ourClock = new BasicClock (); duration = timeLine[timeLine.length-1]; myThread = null; // We always start off ready to go! ourState = Controller.Prefetched; } // Binary search for which segment we are now in. Segment // 0 is considered to start at 0 and end at timeLine[0]. // Segment timeLine.length is considered to start at // timeLine[timeLine.length-1] and end at infinity. At the // points of 0 and timeLine[timeLine.length-1] the // Controller will stop (and post an EndOfMedia event). int computeSegment (long time) { int max = timeLine.length; int min = 0; for (;;) { if (min == max) return min; int current = min + ((max - min) >> 1); if (time < timeLine[current]) { max = current; } else { min = current + 1; } } } // These are all simple... public float setRate (float factor) { // We don't support a rate of 0.0. Not worth the extra math // to handle something the user should do with the stop() // method! if (factor == 0.0f) { factor = 1.0f; } float newRate = ourClock.setRate (factor); postEvent (new RateChangeEvent (this, newRate)); return newRate; } public void setTimeBase (TimeBase master) throws IncompatibleTimeBaseException { ourClock.setTimeBase (master); } public long getStopTime () { return ourClock.getStopTime (); } public long getSyncTime () { return ourClock.getSyncTime (); } public long mapToTimeBase (long t) throws ClockStoppedException { return ourClock.mapToTimeBase (t); } public long getMediaTime () { return ourClock.getMediaTime (); } public TimeBase getTimeBase () { return ourClock.getTimeBase (); } public float getRate () { return ourClock.getRate (); } // From Controller public int getState () { return ourState; } public int getTargetState () { return ourState; } public void realize () { postEvent (new RealizeCompleteEvent (this, ourState, ourState, ourState)); } public void prefetch () { postEvent (new PrefetchCompleteEvent (this, ourState, ourState, ourState)); } public void deallocate () { postEvent (new DeallocateEvent (this, ourState, ourState, ourState, ourClock.getMediaTime ())); } public long getStartLatency () { // We can start immediately, of course! return 0; } public Control[] getControls () { return new cintrol[0]; } public long getDuration () { return duration; } // This one takes a little work as we need to compute if we // changed segments. public void setMediaTime (Time now) { ourClock.setMediaTime (now); postEvent (new MediaTimeSetEvent (this, now)); checkSegmentChange (now); } // We now need to spin a thread to compute/observe the // passage of time. public synchronized void syncStart (long tbTime) { long startTime = ourClock.getMediaTime (); // We may actually have to stop immediately with an // EndOfMediaEvent. We compute that now. If we are already // past end of media, then we // first post the StartEvent then we post a EndOfMediaEvent boolean endOfMedia; float rate = ourClock.getRate (); if ((startTime > duration && rate >= 0.0f) || (startTime < 0 && rate <= 0.0f)) { endOfMedia = true; } else { endOfMedia = false; } // We face the same possible program with being past the stop // time. If so, we stop immediately. boolean pastStopTime; long stopTime = ourClock.getStopTime (); if ((stopTime ! = Long.MAX_VALUE) && ((startTime >= stopTime && rate >= 0.0f) || (startTime <= stopTime && rate <= 0.0f)) { pastStopTime = true; } else { pastStopTime = false; } if (!endOfMedia && !pastStopTime) { ourClock.syncStart (tbTime); ourState = Controller.Started; } postEvent (new StartEvent (this, Controller.Prefetched, Controller.Started, Controller.Started, startTime, tbTime)); if (endOfMedia) { postEvent (new EnOfMediaEvent (this, contrpllerStarted, Controller.Prefetched, Controller.Prefetched, startTime)); } else if (pastStopTime) { postEvent (new StopAtTimeEvent (this, Controller.Started, Controller.Prefetched, Controller.Prefetched, startTime)); } else { myThread = new Thread (this, "TimeLineController"); // Set thread to appopriate priority... myThread.start (); } } // Nothing really special here exept that we need to notify // the thread that we may have. public synchronized void setStopTime (Time stopTime) { ourClock.setStopTime (StopTime); postEvent (new StopTimeChangeEvent (this, stopTime)); notifyAll (); } // This one is also pretty easy. We stop and tell the running // thread to exit. public synchronized void stop () { int previousState = ourState; ourClock.stop () ourState = Controller.Prefetched; postEvent (new StopByRequestEvent (this, previousState, Controller.Prefetched, Controller.Prefetched, ourClock.getMediaTime ())); notifyAll () // Wait for thread to shut down. while (myThread !- null) { try { wait (); } catch (InterruptedException e) { // NOT REACHED } } } protected void checkSegmentChange (long timeNow) { int segment = computeSegment (timeNow); if (segment != currentSegment) { currentSegment = segment; postEvent (new TimeLineEvent (this, currentSegment)); } } // Most of the real work goes here. We have to decide when // to post events like EndOfMediaEvent and StopAtTimeEvent // and TimeLineEvent. public synchronized void run () { for (;;) { // First, have we changed segments? If so, post an event! long timeNow = ourClock.getMediaTime (); checkSegmentChange (timeNow); // Second, have we already been stopped? If so, stop // the thread. if (ourState == Controller.Prefetched) { myThread = null; // If someone is waiting for the thread to die, let them // know. notifyAll (); break; } // Current rate. Our setRate() method prevents the value // 0 so we don't check for that here. float ourRate = ourClock.getRate (); // How long in clock time do we need to wait before doing // something? long mediaTimeToWait; long endOfMediaTime; // Next, are we past end of media? if (ourRate > 0.0f) { mediaTimeToWait = duration - timeNow; endOfMediaTime = duration; } else { mediaTimeToWait = timeNow; endOfMediaTime = 0; } // If we are at (or past) time to stop due to EndOfMedia. // we do that now! if (mediaTimeToWait <= 0) { ourClock.stop (); ourClock.setMediaTime (endOfMediaTime); ourState = Controller.Prefetched; postEvent (new EndOfMediaEvent (this, Controller.Started, Controller.Prefetched, Controller.Prefetched, endOfMediaTime)); continue; } // How long until we hit our stop time? long stoptime = ourClock.getStopTime (); if (stopTime != Long.MAX_VALUE) { long timeToStop; if (ourRate > 0.0f) { timeToStop = stopTime - timeNow; } else { timeToStop = timeNow - stopTime; } // If we are at (or past) time to stop due to the stop // time, we stop now! if (timeToStop <= 0) { ourClock.Stop (); ourClock.setMediaTime (stopTime); ourState = Controller.Prefetched; poatEvent (new StopAtTimeEvent (this, Controller.Prefetched, Controller.Prefetched, stopTime)); continue; } else if (timeToStop < mediaTimeToWait) { mediaTimeToWait = timeToStop; } } // How long until we pass into the next time line segment? long timeToNextSegment; if (ourRate > 0.0f) { timeToNextSegment = timeLine[currentSegment] - timeNow; } else { if (curentSegment == 0) { timeToNextSegment = timeNow; } else { timeToNextSegment = timeNow - timeLine[currentSegment-1]; } } if (timeToNextSegment < mediaTimeToWait) { mediaTimeToWait = timeToNextSegment; } // Do the ugly math to compute what value to pass to // wait(): long waitTime; if (ourRate > 0) { waitTime = (long) ((float) mediaTimeToWait / ourRate) / 1000000; } else { waitTime = (long) ((float) mediaTimeToWait / -ourRate) / 1000000; } // Add one because we just rounded down and we don't // really want to waste CPU being woken up early. waitTime++; if (waitTime > 0) { // Bug in some systems deals poorly with really large // numbers. We will cap our wait() to 1000 seconds // which point we will probably decide to wait again. if (waitTime > 1000000) waitTime = 1000000; try { wait (waitTime); } catch (InterruptedExeption e) { // NOT REACHED } } } ----------------------------------------------------------------------
【０２５８】［付録Ｄ：ＣｏｎｔｒｏｌｌｅｒＡｄａｐ
ｔｅｒ］この付録は特定のイベントに対応するために容
易に拡張できる ControllerListener，ControllerAdapt
er の実装を説明している。
【０２５９】［ControllerAdapter の実装］Controller
Adapter は ControllerEvent を受け取ってそれらを適
切なスタブ・メソッドに届けるイベント・アダプタであ
る。クラスはこのアダプタを使用しているが、その方法
はアダプタを拡張してこれらのクラスが関係するメッセ
ージ・ハンドラだけを取り替えることである。
【０２６０】 ---------------------------------------------------------------------- import javax.media.*; public void cachingControl(CachingControlEvent e) {} public void controllerClosed(ControllerClosedEvent e) {} public void controllerError(ControllerErrorEvent e) {} public void connectionError(ConnectionErrorEvent e) {} public void internalError(InternalErrorEvent e) {} public void resourceUnavailable(ResourceUnavailableEvent e) {} public void durationUpdate(DurationUpdateEvent e) {} public void mediaTimeSet(MediaTimeSetEvent e) {} public void rateChange(RateChangeEvent e) {} public void stopTimeChange(StopTimeChangeEvent e) {} public void trasition(TransitionEvent e) {} public void prefetchComplete(PrefetchCompleteEvent e) {} public void realizeComplete(RealizeCompleteEvent e) {} public void start(StartEvent e) {} public void stop(StopEvent e) {} public void dataStarved(DataStarvedEvent e) {} public void deallocate(DeallocateEvent e) {} public void endOfMedia(EndOfMediaEvent e) {} public void restarting(RestartingEvent e) {} public void stopAtTime(StopAtTimeEvent e) {} public void stopByRequest(StopByRequestEvent e) {} /** * Main dispatching function. Subclasses should not need to * override this method, but instead subclass only * the individual event methods listed above that they need */ public void controllerUpdate(ControllerEvent e) { if (e instanceof CachingControlEvent) { cachingControl((CachingControlEvent)e); } else if (e instanceof ControllerClosedEvent) { controllerClosed((ControllerClosedEvent)e); if (e instanceof ControllerErrorEvent) { controllerError((ControllerErrorEvent)e); if (e instanceof DataLostErrorEvent) { connectionError((ConnectionErrorEvent)e); } else if (e instanceof InternalErrorEvent) { internalError((InternalErrorEvent)e); } else if (e instanceof ResourceUnavailableEvent) { resourceUnavailable((ResourceUnavailableEvent)e); } } } else if (e instanceof DurationUpdateEvent) { durationUpdate((DurationUpdateEvent)e); } else if (e instanceof MediaTimeSetEvent) { mediaTimeSet((MediaTimeSetEvent)e); } else if (e instanceof RateChangeEvent) { rateChange((RateChangeEvent)e); } else if (e instanceof StopTimeChangeEvent) { stopTimeChange((StopTimeChangeEvent)e); } else if (e instanceof TransitionEvent) { transition((TransitionEvent)e); } if (e instanceof PrefetchCompleteEvent) { prefetvhComplete((PrefetchCompleteEvent)e); } else if (e instanceof RealizeCompleteEvent) { realizeComplete((RealizeCompleteEvent)e); } else if (e instanceof StartEvent) { start((StartEvent)e); } else if (e instanceof StopEvent) { stop((StopEvent)e); if(e instanceof DataStarvedEvent) { dataStarved((DataStarvedEvent)e); } else if (e instanceof DeallocateEvent) { deallocate((DeallocateEvent)e); } else if (e instanceof EndOfMediaEvent) { endOfMedia((EndOfMediaEvent)e); } else if (e instanceof RestartingEvent) { restarting((RestartingEvent)e); } else if (e instanceof StopAtTimeEvent) { stopAtTime((StopAtTime)e); } else if (e instanceof StopByRequestEvent) { stopByRequest((StopByRequest)e); } } } } } -------------------------------------------------------------------
【０２６１】［ControllerAdapter の使用］Controller
Adapter を用いて ControllerListener インタフェース
を実装するためにはユーザは以下を行う必要がある： １．ControllerAdapter をサブクラスにしてユーザが関
心のあるイベントについてイベント・メソッドを無効に
する。 ２．addControllerListener を呼び出すことにより、特
定のコントローラに対してリスナーとしてユーザの Con
trollerAdapter クラスを登録する。
【０２６２】コントローラはあるイベントを通知すると
登録された各リスナー上で controllerUpdate を呼び出
す。ControllerAdapter はそのイベントを適切なイベン
ト・メソッドに自動的に届けてユーザが関心のないイベ
ントをフィルタで取り除く。
【０２６３】例えば、以下のコードはＪＤＫ１.１の無
名の内部クラスを用いて ControllerAdapter を拡張し
て内蔵の(self contained)プレイヤを作成し、そのプレ
イヤはメディアの終わりにくると自動的にメディアの初
めにリセットされて、割当てを領域を開放される。
【０２６４】 ------------------------------------------------------------------- player.addControllerListener(new ControllerAdapter() { public void endOfMedia(EndOfMediaEvent e) { Controller controller = e.getSource(); controller.stop(); controller.setMediaTime(0); controller.deallocate(); } } -------------------------------------------------------------------
【０２６５】ユーザはイベント・メソッドの実装におい
て、複数のプレイヤに対してリスナーとして単一の Con
trollerAdapter を登録する場合にはどのプレイヤがそ
のイベントを発生させたか判断する必要がある。コント
ローライベントには getSource を呼び出すことにより
アクセスできるソースの参照番号の「スタンプ」とな
る。
【図面の簡単な説明】
【図１】本発明を実施するための模範的コンピュータ・
システムのブロック線図である。
【図２】本発明のＲＴＰセッション・マネージャを示す
図である。
【図３】本発明のＲＴＰデパッケタイザを示す図であ
る。
【図４】本発明の処理の流れ図である。
【図５】Java Media Player の概念図である。
【図６】コントローラで通知されるイベントを示す図で
ある。
【図７】プレイヤの状態それぞれでプレイヤが行う操作
の説明図である。
【図８】メディア・タイムのセッティングを示す図であ
る。
【図９】スライドショープレイヤの説明図である。
【図１０】プレイヤを作成する時のマネージャの動作説
明図である。
【符号の説明】
１１０ キーボード １１１ マウス １１２ 大容量保存装置 １１３ ＣＰＵ １１４ ビデオメモリ １１５ メイン・メモリ １１６ ビデオ増幅器 １１７ CRT １２０ 通信インタフェース １２１ ネットワーク・リンク １２２ ローカル・ネットワーク １２３ ホスト １２５ インターネット １２６ サーバ
───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 エマ パトゥキ アメリカ合衆国 94043 カリフォルニア 州 マウンテン ビュー，485Ｃ イージ ー ストリート，＃11−Ｆ，レミントン ドライブ 575 Ｅ. (72)発明者 ダニエル シー．ダブリュー．ウォン アメリカ合衆国 95131 カリフォルニア 州 サン ホセ，リトルトン ドライブ 1285

Claims (1)

    【特許請求の範囲】
  1. 【請求項１】 データストリームを受け取る工程；前記
    データストリーム中のデータのタイプに基づいてデパッ
    ケタイザを選択する工程；前記データストリームのパケ
    ットを前記デパッケタイザに提供する工程；前記パケッ
    トをフレームに組立てて作る工程；を含む：データスト
    リーム用の選択可能なデパッケタイザを提供する方法。
JP34352498A 1997-10-27 1998-10-27 選択可能なデパッケタイザ構成 Ceased JP2000022741A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/958,610 1997-10-27
US08/958,610 US6181713B1 (en) 1997-10-27 1997-10-27 Selectable depacketizer architecture

Publications (2)

Publication Number Publication Date
JP2000022741A true JP2000022741A (ja) 2000-01-21
JP2000022741A5 JP2000022741A5 (ja) 2006-10-05

Family

ID=25501103

Family Applications (1)

Application Number Title Priority Date Filing Date
JP34352498A Ceased JP2000022741A (ja) 1997-10-27 1998-10-27 選択可能なデパッケタイザ構成

Country Status (4)

Country Link
US (3) US6181713B1 (ja)
EP (1) EP0912064A3 (ja)
JP (1) JP2000022741A (ja)
CA (1) CA2251416A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004038970A (ja) * 2002-06-28 2004-02-05 Microsoft Corp マルチメディアデータを利用するためのアプリケーションプログラミングインタフェース
JP2010288301A (ja) * 2002-06-04 2010-12-24 Qualcomm Inc ポータブルデバイスにおけるマルチメディアレンダリングのためのシステム

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6973641B1 (en) * 1998-06-04 2005-12-06 Microsoft Corporation Persistent representations for complex data structures as interpreted programs
US6584509B2 (en) * 1998-06-23 2003-06-24 Intel Corporation Recognizing audio and video streams over PPP links in the absence of an announcement protocol
US6092120A (en) * 1998-06-26 2000-07-18 Sun Microsystems, Inc. Method and apparatus for timely delivery of a byte code and serialized objects stream
US7558472B2 (en) 2000-08-22 2009-07-07 Tivo Inc. Multimedia signal processing system
US6233389B1 (en) 1998-07-30 2001-05-15 Tivo, Inc. Multimedia time warping system
US6560655B1 (en) * 1999-06-22 2003-05-06 Microsoft Corporation Synchronization manager for standardized synchronization of separate programs
US7089300B1 (en) * 1999-10-18 2006-08-08 Apple Computer, Inc. Method and apparatus for administering the operating system of a net-booted environment
US6804266B1 (en) 2000-01-24 2004-10-12 Ati Technologies, Inc. Method and apparatus for handling private data from transport stream packets
US6988238B1 (en) 2000-01-24 2006-01-17 Ati Technologies, Inc. Method and system for handling errors and a system for receiving packet stream data
US6763390B1 (en) * 2000-01-24 2004-07-13 Ati Technologies, Inc. Method and system for receiving and framing packetized data
US6885680B1 (en) 2000-01-24 2005-04-26 Ati International Srl Method for synchronizing to a data stream
US6778533B1 (en) 2000-01-24 2004-08-17 Ati Technologies, Inc. Method and system for accessing packetized elementary stream data
US6999424B1 (en) 2000-01-24 2006-02-14 Ati Technologies, Inc. Method for displaying data
US7366961B1 (en) 2000-01-24 2008-04-29 Ati Technologies, Inc. Method and system for handling errors
US6785336B1 (en) 2000-01-24 2004-08-31 Ati Technologies, Inc. Method and system for retrieving adaptation field data associated with a transport packet
US8284845B1 (en) 2000-01-24 2012-10-09 Ati Technologies Ulc Method and system for handling data
US6674805B1 (en) 2000-05-02 2004-01-06 Ati Technologies, Inc. System for controlling a clock signal for synchronizing a counter to a received value and method thereof
US7113546B1 (en) 2000-05-02 2006-09-26 Ati Technologies, Inc. System for handling compressed video data and method thereof
KR20020020957A (ko) * 2000-06-06 2002-03-16 요트.게.아. 롤페즈 인터랙티브 프로세스 시스템
US7191242B1 (en) * 2000-06-22 2007-03-13 Apple, Inc. Methods and apparatuses for transferring data
US7136577B1 (en) * 2000-06-29 2006-11-14 Tandberg Telecom As RTP-formated media clips
FR2813472B1 (fr) * 2000-08-30 2002-11-01 At Sky Dispositif routeur de flux de donnees numeriques
US7095945B1 (en) 2000-11-06 2006-08-22 Ati Technologies, Inc. System for digital time shifting and method thereof
GB0108059D0 (en) * 2001-03-30 2001-05-23 British Telecomm Software customisation
JP2003037623A (ja) * 2001-07-23 2003-02-07 Philips Japan Ltd Ｍｐｅｇネットワーク上におけるダイレクトｒｔｐ伝送方法及びシステム
SE0201313D0 (sv) * 2002-04-29 2002-04-29 Electrolux Home Prod Corp Behållare för dosering
US7730155B1 (en) 2002-10-01 2010-06-01 Apple Inc. Method and apparatus for dynamically locating resources
CN100412843C (zh) * 2002-12-23 2008-08-20 皇家飞利浦电子股份有限公司 可扩展的光盘播放机、播放设备、记录器和升级它们的方法
US7613835B2 (en) * 2003-09-08 2009-11-03 Sony Corporation Generic API for synchronization
US20050060420A1 (en) * 2003-09-11 2005-03-17 Kovacevic Branko D. System for decoding multimedia data and method thereof
US7925790B2 (en) 2003-09-17 2011-04-12 Sony Corporation Middleware filter agent between server and PDA
US7774774B1 (en) * 2003-10-22 2010-08-10 Apple Inc. Software setup system
US7266726B1 (en) 2003-11-24 2007-09-04 Time Warner Cable Inc. Methods and apparatus for event logging in an information network
US8302111B2 (en) 2003-11-24 2012-10-30 Time Warner Cable Inc. Methods and apparatus for hardware registration in a network device
US9213538B1 (en) 2004-02-06 2015-12-15 Time Warner Cable Enterprises Llc Methods and apparatus for display element management in an information network
US8078669B2 (en) 2004-02-18 2011-12-13 Time Warner Cable Inc. Media extension apparatus and methods for use in an information network
US20080235390A1 (en) * 2007-03-21 2008-09-25 Fumio Noda Moving Image Displaying Method and System
JP4100421B2 (ja) * 2005-09-26 2008-06-11 株式会社日立製作所 コンピュータシステム
KR100782646B1 (ko) * 2006-02-13 2007-12-06 엘지전자 주식회사 미디어 플레이어의 리소스 설정방법
KR100760087B1 (ko) * 2006-02-13 2007-09-18 엘지전자 주식회사 서비스 또는 컴포넌트의 재생을 위한 미디어 플레이어설정방법
US7672269B2 (en) * 2006-02-14 2010-03-02 Motorola, Inc. Methods of distributing an installation program on a wireless link and supporting memory circuit and apparatus
US7818774B2 (en) * 2006-03-24 2010-10-19 Zenith Electronics Llc Internet protocol conversion module for televisions
US7937693B2 (en) * 2006-04-26 2011-05-03 9Rays.Net, Inc. System and method for obfuscation of reverse compiled computer code
US9198084B2 (en) 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
MY166373A (en) * 2006-06-23 2018-06-25 Tencent Tech Shenzhen Co Ltd Method, system and apparatus for playing advertisements
WO2008035339A2 (en) * 2006-09-21 2008-03-27 Vringo, Inc. Personalized installation files
US20080117906A1 (en) * 2006-11-20 2008-05-22 Motorola, Inc. Payload header compression in an rtp session
US8370818B2 (en) 2006-12-02 2013-02-05 Time Warner Cable Inc. Methods and apparatus for analyzing software interface usage
JP2009027557A (ja) * 2007-07-20 2009-02-05 Toshiba Corp コンテンツデータ配信端末、及びコンテンツデータ配信システム
US8811294B2 (en) * 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US20090307733A1 (en) * 2008-06-04 2009-12-10 Samsung Electronics Co., Ltd. Downloading method and apparatus of terminal entity
US9398089B2 (en) * 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US8137201B2 (en) * 2009-01-09 2012-03-20 Microsoft Corporation Arrangement for building and operating human-computation and other games
US20100205321A1 (en) * 2009-02-12 2010-08-12 Qualcomm Incorporated Negotiable and adaptable periodic link status monitoring
US9264248B2 (en) * 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US9582238B2 (en) 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US9100385B1 (en) * 2010-10-01 2015-08-04 Google Inc. Management and synchronization of electronic media content information
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US20130013318A1 (en) * 2011-01-21 2013-01-10 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
US9767195B2 (en) 2011-04-21 2017-09-19 Touchstream Technologies, Inc. Virtualized hosting and displaying of content using a swappable media player
US8904289B2 (en) * 2011-04-21 2014-12-02 Touchstream Technologies, Inc. Play control of content on a display device
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9330277B2 (en) 2012-06-21 2016-05-03 Google Technology Holdings LLC Privacy manager for restricting correlation of meta-content having protected information based on privacy rules
US8959574B2 (en) 2012-06-21 2015-02-17 Google Technology Holdings LLC Content rights protection with arbitrary correlation of second content
US9542172B2 (en) 2013-02-05 2017-01-10 Apple Inc. Automatic updating of applications
US11716558B2 (en) 2018-04-16 2023-08-01 Charter Communications Operating, Llc Apparatus and methods for integrated high-capacity data and wireless network services
EP3864917A4 (en) 2018-10-12 2022-07-06 Charter Communications Operating, LLC APPARATUS AND METHODS FOR IDENTIFYING CELLS IN WIRELESS NETWORKS
US11129171B2 (en) 2019-02-27 2021-09-21 Charter Communications Operating, Llc Methods and apparatus for wireless signal maximization and management in a quasi-licensed wireless system
US11026205B2 (en) 2019-10-23 2021-06-01 Charter Communications Operating, Llc Methods and apparatus for device registration in a quasi-licensed wireless system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4612636A (en) * 1984-12-31 1986-09-16 Northern Telecom Limited Multiple channel depacketizer
US5559559A (en) * 1991-06-14 1996-09-24 Wavephore, Inc. Transmitting a secondary signal with dynamic injection level control
US5387941A (en) * 1991-06-14 1995-02-07 Wavephore, Inc. Data with video transmitter
US5377051A (en) * 1993-01-13 1994-12-27 Hitachi America, Ltd. Digital video recorder compatible receiver with trick play image enhancement
US5390184A (en) * 1993-09-30 1995-02-14 Northern Telecom Limited Flexible scheduling mechanism for ATM switches
US5691986A (en) * 1995-06-07 1997-11-25 Hitachi America, Ltd. Methods and apparatus for the editing and insertion of data into an encoded bitstream
KR100209880B1 (ko) * 1995-10-30 1999-07-15 윤종용 Mpeg-2 영상복호화장치의 시스템클럭 복구장치

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010288301A (ja) * 2002-06-04 2010-12-24 Qualcomm Inc ポータブルデバイスにおけるマルチメディアレンダリングのためのシステム
JP2004038970A (ja) * 2002-06-28 2004-02-05 Microsoft Corp マルチメディアデータを利用するためのアプリケーションプログラミングインタフェース
JP4652674B2 (ja) * 2002-06-28 2011-03-16 マイクロソフト コーポレーション マルチメディアデータを利用するためのアプリケーションプログラミングインタフェース

Also Published As

Publication number Publication date
EP0912064A3 (en) 2000-08-23
EP0912064A2 (en) 1999-04-28
CA2251416A1 (en) 1999-04-27
US20020034193A1 (en) 2002-03-21
US6252889B1 (en) 2001-06-26
US6944185B2 (en) 2005-09-13
US6181713B1 (en) 2001-01-30

Similar Documents

Publication Publication Date Title
JP2000022741A (ja) 選択可能なデパッケタイザ構成
US6631403B1 (en) Architecture and application programming interfaces for Java-enabled MPEG-4 (MPEG-J) systems
JP5368605B2 (ja) 回線容量が制約されたネットワーク上の多メディア資産の送出及び動的プレゼンテーション用システム
US5752159A (en) Method for automatically collecting and delivering application event data in an interactive network
US7080386B2 (en) Architecture with digital signal processor plug-ins for general purpose processor media frameworks
US6539437B1 (en) Remote control inputs to java applications
JP2002528971A (ja) 構成可能な機能をもつテレビジョン・セットトップ・ボックス
WO2010107622A2 (en) Hosted application platform with extensible media format
EP1782282A1 (en) Multimedia content management system
JP2003504753A (ja) アプリケーションライフサイクルに従ってアプリケーションを管理するための方法および装置
US10244022B2 (en) Media streams from containers processed by hosted code
JP2004538695A (ja) コンピュータベースのマルチメディア作成、管理、および展開プラットフォーム
JP2001022879A (ja) 情報処理方法及び装置及びコンピュータ可読媒体
Muhlhauser et al. Services, frameworks, and paradigms for distributed multimedia applications
Roussel Exploring new uses of video with videoSpace
Peng et al. Digital television application manager
CN113542706B (zh) 跑步机的投屏方法、装置、设备及存储介质
Micucci et al. Time sensitive architectures: a reflective approach
WO2002017638A1 (en) Open architecture set-top box
US20020176692A1 (en) System and method of synchronizing playback of video and user agent content in an optical disc player
Chhonkar et al. Music Player Android Application
Psaier A Java-based streaming media server
Jo et al. Modeling of multimedia streaming services based on the TMO structuring scheme
AU2002317631B2 (en) Method and system for computer software application execution
Specifications User's Guide

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20051026

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060816

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070910

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070925

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071225

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080129

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20080527