JP2006099671A - 動画像のメタデータの検索テーブル - Google Patents

Abstract

【課題】視聴者の手元にある動画像と、視聴者の手元もしくはネットワーク上にあるメタデータとを組み合わせた処理を効率よく行う。
【解決手段】メタデータは、有効期間を特定するデータ、動画像中の時空間領域を記述したオブジェクト領域データ、関連属性情報等を有し、独立して処理可能なデータ単位であるVclickアクセスユニットを、１以上含む。このメタデータへのアクセスに利用される検索テーブル（VCKSRCT.IFO）をVclickデータに含める。
【選択図】 図５３

Description

この発明は、クライアント装置にある動画像データとネットワーク（またはディスク）上のメタデータとを組み合わせて動画像ハイパーメディアを実現したり、また動画像にテロップや吹き出しを表示したりする方法に関する。

ハイパーメディアは、動画像、静止画像、音声、テキストなどのメディア間にハイパーリンクと呼ばれる関連性を定義し、相互に、または一方から他方を参照できるようにしたものである。例えばインターネットを使って閲覧することのできるＨＴＭＬで記述されたホームページには、テキストや静止画が配置されており、これらテキストや静止画のいたるところにリンクが定義されている。そしてこれらのリンクを指定することにより直ちにリンク先である関連情報を表示させることができる。興味のある語句を直接指示すれば関連情報にアクセスできるため、操作が容易かつ直感的である。

一方、テキストや静止画ではなく動画像を中心にしたハイパーメディアでは、動画像中に登場する人や物などのオブジェクトからそれを説明するテキストや静止画などの関連コンテンツへのリンクが定義されており、視聴者がこのオブジェクトを指示することによりこれら関連コンテンツが表示される。このとき、動画像に登場するオブジェクトの時空間的な領域とその関連コンテンツへのリンクを定義するには、動画像中のオブジェクトの時空間的な領域を表すデータ（オブジェクト領域データ）が必要となる。

オブジェクト領域データとしては、２値以上の値を持つマスク画像系列、ＭＰＥＧ−４の任意形状符号化、特許文献１で説明されている図形の特徴点の軌跡を記述する方法、さらに特許文献２で説明されている方法などを用いることができる。動画像中心のハイパーメディアを実現するためには、このほかにもオブジェクトが指定されたときに他の関連コンテンツを表示させるという動作を記述したデータ（動作情報）などが必要となる。これらの動画像以外のデータを動画像のメタデータと呼ぶことにする。

動画像とメタデータを視聴者に提供する方法としては、まず動画像とメタデータの両方が記録された記録媒体（ビデオＣＤ、ＤＶＤなど）を作る方法がある。また、すでにビデオＣＤやＤＶＤとして所有している動画像のメタデータを提供するには、メタデータのみをネットワーク上からダウンロード、もしくはストリーミングにより配信すればよい。さらに、動画像とメタデータの両方のデータをネットワークで配信しても良い。このとき、メタデータは効率的にバッファを使用することが可能で、ランダムアクセスに適しており、ネットワークにおけるデータロスに強い形式であることが望ましい。

また、動画像の切り替えが頻繁に生じる場合には（例えば、複数のカメラアングルで撮影された動画像が用意されており、視聴者は自由にカメラアングルを選択できるような場合…ＤＶＤビデオのマルチアングル映像のようなものなど）、動画像の切り替えに対応して高速にメタデータの切り替えができなければならない。
特開２０００−２８５２５３号公報 特開２００１−１１１９９６号公報

視聴者の手元にある動画像に関連したネットワーク上のメタデータを視聴者の元にストリーミング配信したり、視聴者の基にあるメタデータを再生したりする際の課題は、バッファの利用効率を向上させること、ランダムアクセスをしやすくすること、メタデータの切り替えが高速にできること、ユーザが必要なメタデータを自由に検索しアクセスできることである。この発明はこれらの課題の一部あるいは全部を解決すべくなされたものである。

この発明の一実施の形態に係る動画像メタデータは、動画像の時間軸に対して定義される有効期間内に関する情報として、前記有効期間を特定するデータと、前記動画像中の時空間領域を記述したオブジェクト領域データと、前記時空間領域に関連した表示方法を特定するデータおよび／または前記時空間領域が指定された際に行う処理を特定するデータとを有する。ここで、前記メタデータは、独立して処理可能なデータ単位であるアクセスユニット（Vclick_AU）を１以上含むことにより構成される。

また、この発明の一実施の形態に係る動画像メタデータは、それぞれのオブジェクトに関連するキーワードをまとめたテーブル（VCKSRCT.IFO）を持つことができる。このテーブルを用いることにより、ユーザが全てのメタデータの中から取得したい情報の検索を行なう場合に、対応する情報が記録されているメタデータ（Vclickデータ）へアクセスすることを可能にする。

また、より迅速に対象のVclickデータへアクセスするために、Vclickデータの再生開始時間などを属性情報として持つことも可能にしている。

メタデータは単独で処理可能なアクセスユニット（Vclick_AU）の集合体として構成されるため、バッファを効率よく使用でき、ランダムアクセスが容易であり、データロスの影響が小さく、メタデータの切り替えが高速にできるようになる。さらに、メタデータ（Vclickデータ）へ迅速にアクセスすることが可能になる。

以下、図面を参照しながらこの発明の一実施の形態を説明する。

（アプリケーションの概要）
図１はこの発明のオブジェクト・メタデータを動画像と共に利用することにより実現されるアプリケーション（動画像ハイパーメディア）の画面上の表示例である。図１（ａ）の１００は動画像の再生画面、そして１０１はマウスカーソルである。動画像の再生画面１００で再生される動画像のデータは、ローカルにある動画像データ記録媒体に記録されている。１０２は動画像中に登場するオブジェクトの領域である。ユーザがオブジェクトの領域内にマウスカーソルを移動させてクリック等によりオブジェクトを選択すると、所定の機能が実行される。例えば図１（ｂ）では、ローカルおよび／またはネットワーク上にあるドキュメント（クリックされたオブジェクトに関連した情報）１０３が表示されている。そのほか、動画像の別の場面にジャンプしたり、別の動画像ファイルが再生されたり、再生モードを変更するなどの機能を実行することができる。

オブジェクトの領域１０２のデータ及びこの領域がクリック等により指定された場合のクライアント装置の動作データなどをまとめて、オブジェクト・メタデータまたはVclickデータと呼ぶことにする。オブジェクト・メタデータはローカルにある動画像データ記録媒体（光ディスク、ハードディスク、半導体メモリ等）に動画像データと共に記録されていても良いし、ネットワーク上のサーバに蓄積されていてネットワーク経由でクライアントに送られるようにしても良い。以下ではこのアプリケーションがどのように実現されるかについて詳細に説明する。

（システムモデル）
図２はこの発明の一実施の形態に係るストリーミング装置（ネットワーク対応ディスクプレーヤ）の概略構成を示す図である。この図を用いて各構成要素の機能について説明する。

２００はクライアント装置、２０１はサーバ装置、２２１はサーバ装置２０１とクライアント装置２００を結ぶネットワークである。クライアント装置２００は、動画再生エンジン２０３、Vclickエンジン２０２、ディスク装置２３０、ユーザ・インタフェース２４０、ネットワーク・マネージャ２０８、ディスク装置マネージャ２１３、を備えている。また、２０４から２０６は動画再生エンジンに含まれる装置、２０７、２０９から２１２、２１４から２１８はVclickエンジンに含まれる装置、２１９と２２０はサーバ装置２０１に含まれる装置である。クライアント装置２００はディスク装置２３０にある動画像データの再生や、ＨＴＭＬ等のマークアップ言語で書かれたドキュメントの表示を行うことができる。また、ネットワーク上にあるＨＴＭＬ等のドキュメントの表示を行うことも可能である。

クライアント装置２００にある動画像データに関連したメタデータがサーバ装置２０１に存在する場合、クライアント装置２００はこのメタデータとディスク装置２３０にある動画像データとを利用した再生を以下のように行うことが可能である。まず、サーバ装置２０１はクライアント装置２００からの要求によりネットワーク２２１を介してクライアント装置２００にメディアデータＭ１を送る。クライアント装置２００では、送られてきたメディアデータを動画像の再生と同期させて処理することでハイパーメディアなどの付加機能を実現させる（ここでの“同期”とは、物理的に完全なタイミングの一致のみに限定されず、多少のタイミングずれも許容している）。

動画再生エンジン２０３は、ディスク装置２３０にある動画像データを再生するためのエンジンであり、２０４、２０５、２０６の装置を有している。２３１は動画像データ記録媒体であり、具体的にはＤＶＤ、ビデオＣＤ、ビデオテープ、ハードディスク、半導体メモリなどである。動画像データ記録媒体２３１にはデジタルおよび／またはアナログの動画像データが記録されている。動画像データに関連したメタデータは、動画像データと共に動画像データ記録媒体２３１に記録されている場合もある。２０５は、動画像再生制御用のコントローラであり、Vclickエンジン２０２のインタフェース・ハンドラ２０７から出力される“コントロール”信号に応じて、動画像データ記録媒体２３１からの映像・音声・副映像データＤ１の再生を制御することもできるように構成されている。

具体的には、動画像再生コントローラ２０５は、動画像の再生時に、インタフェース・ハンドラ２０７からあるイベント（例えばユーザ指示によるメニュー・コールやタイトル・ジャンプ）が発生した際に送信される“コントロール”信号に応じて、インタフェース・ハンドラ２０７に対して、映像・音声・副映像データＤ１の再生状況を示す“トリガ”信号を出力することができる。その際（トリガ信号の出力と同時に、あるいはその前後の適当なタイミングで）、動画像再生コントローラ２０５は、プロパティ情報（例えばプレーヤに設定されている音声言語、副映像字幕言語、再生動作、再生位置、各種時間情報、ディスクの内容等）を示す“ステータス”信号をインタフェース・ハンドラ２０７に出力することができる。これらの信号の送受信により動画像データ読み出しの開始および停止や、動画像データ中の所望の位置へのアクセスが可能となる。

ＡＶデコーダ２０６は、動画像データ記録媒体２３１に記録されている映像データ、音声データ、および副映像データをそれぞれデコードし、デコードされた映像データ（前述の映像データと前述の副映像データを合成したもの）と音声データをそれぞれ出力する機能を持っている。これにより、動画再生エンジン２０３は、既存のＤＶＤビデオ規格に基づいて製造される通常のＤＶＤビデオプレーヤの再生エンジンと同じ機能を持つようになる。つまり、図２のクライアント装置２００は、ＭＰＥＧ−２プログラムストリーム構造の映像、音声等のデータを通常のＤＶＤビデオプレーヤと同様に再生することができ、これにより既存のＤＶＤビデオディスク（従来のＤＶＤビデオ規格に則ったディスク）の再生が可能となる（既存ＤＶＤソフトに対する再生互換確保）。

インタフェース・ハンドラ２０７は、動画像再生エンジン２０３、ディスク装置マネージャ２１３、ネットワーク・マネージャ２０８、メタデータ・マネージャ２１０、バッファ・マネージャ２１１、スクリプト・インタプリタ２１２、メディア・デコーダ２１６（メタデータ・デコーダ２１７を含む）、レイアウト・マネージャ２１５、ＡＶレンダラー２１８などのモジュール間のインタフェース制御を行う。また、ユーザ操作（マウス、タッチパネル、キーボード等の入力デバイスへの操作）による入力イベントをユーザ・インタフェース２４０から受け取り、適切なモジュールにイベントを送信する。

インタフェース・ハンドラ２０７はVclickアクセス・テーブル（図５３を参照して後述するＶＣＡに対応）を解釈するアクセステーブル・パーサー、Vclick情報ファイル（図５３を参照して後述するＶＣＩに対応）を解釈する情報ファイル・パーサー、Vclickエンジンの管理するプロパティを記録しておくプロパティ・バッファ、Vclickエンジンのシステムクロック、動画再生エンジンにある動画像クロック２０４のクロックをコピーした動画像クロック等を有している。

ネットワーク・マネージャ２０８は、ネットワークを介してＨＴＭＬ等のドキュメントや静止画・音声等のデータをバッファ２０９へ取得する機能を持っており、インターネット接続部２２２の動作を制御する。ネットワーク・マネージャ２１２は、ユーザ操作または、メタデータ・マネージャ２１０からの要求を受けたインタフェース・ハンドラ２０７より、ネットワークへの接続や非接続の指示が来ると、インターネット接続部２２２の接続・非接続の切替を行う。また、サーバ装置２０１とインターネット接続部２２２とのネットワーク確立時には、制御データやメディアデータ（オブジェクト・メタデータ）の送受信を行う。

クライアント装置２００からサーバ装置２０１へ送信するデータとしては、セッション構築の要求、セッション終了の要求、メディアデータ（オブジェクト・メタデータ）送信の要求、ＯＫやエラーなどのステータス情報などがある。また、クライアント装置の状態情報の送信を行うようにしても良い。一方、サーバ装置２０１からクライアント装置２００へ送信するデータにはメディアデータ（オブジェクト・メタデータ）、ＯＫやエラーなどのステータス情報がある。

ディスク装置マネージャ２１３は、ＨＴＭＬ等のドキュメントや静止画・音声等のデータをバッファ２０９へ取得する機能及び、動画再生エンジン２０３へ映像・音声・副映像データＤ１を送信する機能を持っている。ディスク装置マネージャ２１３は、メタデータ・マネージャ２１０からの指示に従ってデータ送信処理を行う。

バッファ２０９は、ネットワークを介して（ネットワーク・マネージャ経由で）サーバ装置２０１から送られてきたメディアデータＭ１を一時的に蓄積する。また、動画像データ記録媒体２３１にメディアデータＭ２が記録されていることがあるが、この場合も同様にディスク装置マネージャ経由でバッファ２０９へメディアデータＭ２を蓄積することになる。なお、メディアデータにはVclickデータ（オブジェクト・メタデータ）、ＨＴＭＬ等のドキュメントやこれに付随する静止画・動画像データなど）が含まれる。

動画像データ記録媒体２３１にメディアデータＭ２が記録されている場合は、映像・音声・副映像データＤ１の再生を開始する前にあらかじめ動画像データ記録媒体２３１からメディアデータＭ２を読み出し、バッファ２０９に記憶しておいてもよい。これは、動画像データ記録媒体２３１上のメディアデータＭ２と映像・音声・副映像データＤ１のデータ記録位置が異なるため、通常の再生を行った場合にはディスクのシーク等が発生してシームレスな再生が保障できなくなってしまうため、これを回避するための手段となる。

以上のように、サーバ装置２０１からダウンロードしたメディアデータＭ１も、動画像データ記録媒体２３１に記録されているメディアデータＭ２と同様に、バッファ２０９に記憶させることにより、映像・音声・副映像データＤ１とメディアデータを同時に読み出して再生することが可能になる。

なお、バッファ２０９の記憶容量には限界がある。つまり、バッファ２０９に記憶できるメディアデータＭ１、Ｍ２のデータサイズには限りがある。このため、メタデータ・マネージャ２１０、および／またはバッファ・マネージャ２１１の制御（バッファ・コントロール）により、不必要なデータの消去を行うことにしてもよい。

メタデータ・マネージャ２１０は、バッファ２０９に蓄積されたメタデータを管理しており、インタフェース・ハンドラ２０７からの動画像の再生に同期させた適切なタイミング（“動画像クロック”信号）を受けて、該当するタイムスタンプを持つメタデータをバッファ２０９よりメディア・デコーダ２１６に転送する。

なお、該当するタイムスタンプを持つメタデータがバッファ２０９に存在しない場合は、メディア・デコーダ２１６に転送しなくてもよい。また、メタデータ・マネージャ２１０は、バッファ２０９より送出したメタデータのサイズ分、または、任意のサイズのデータをサーバ装置２０１、またはディスク装置２３０からバッファ２０９へ読み込むためのコントロールを行う。具体的な処理としては、メタデータ・マネージャ２１０は、インタフェース・ハンドラ２０７経由で、ネットワーク・マネージャ２０８、またはディスク装置マネージャ２１３に対し、指定サイズ分のメタデータ取得要求を行う。ネットワーク・マネージャ２０８、またはディスク装置マネージャ２１３は、指定サイズ分のメタデータをバッファ２０９に読み込み、メタデータ取得済の応答をインタフェース・ハンドラ２０７経由で、メタデータ・マネージャ２１０へ通知する。

バッファ・マネージャ２１１は、バッファ２０９に蓄積されたメタデータ以外のデータ（ＨＴＭＬ等のドキュメントやこれに付随する静止画・動画像データなど）の管理をしており、インタフェース・ハンドラ２０７からの動画像の再生に同期させた適切なタイミング（“動画像クロック”信号）を受けてバッファ２０９に蓄積されたメタデータ以外のデータをパーサー２１４やメディア・デコーダ２１６に送る。バッファ・マネージャ２１１は、不要になったデータをバッファ２０９から削除してもよい。

パーサー２１４は、ＨＴＭＬ等のマークアップ言語で書かれたドキュメントの構文解析を行い、スクリプトはスクリプト・インタプリタ２１２へ、そしてレイアウトに関する情報はレイアウト・マネージャ２１５に送る。

スクリプト・インタプリタ２１２は、パーサー２１４から入力されるスクリプトを解釈し、実行する。スクリプトの実行には、インタフェース・ハンドラ２０７から入力されるイベントやプロパティの情報を利用することもできる。動画像中のオブジェクトがユーザにより指定された場合には、スクリプトはメタデータ・デコーダ２１７からスクリプト・インタプリタ２１２へ入力される。

ＡＶレンダラー２１８は、映像・音声・テキスト出力を制御する機能をもつ。具体的には、ＡＶレンダラー２１８は、レイアウト・マネージャ２１５から出力される“レイアウト・コントロール”信号に応じて、例えば、映像・テキストの表示位置、表示サイズや（これらとともに表示タイミング、表示時間を含むこともある）、音声の大きさ（これらとともに出力タイミング、出力時間を含むこともある）を制御したり、指定されているモニターの種別かつ／または表示する映像の種類に応じて、その映像の画素変換を行う。制御の対象となる映像・音声・テキスト出力は、動画再生エンジン２０３およびメディア・デコーダ２１６からの出力である。さらに、ＡＶレンダラー２１８は、インタフェース・ハンドラ２０７から出力される“ＡＶ出力コントロール”信号に従って、動画再生エンジン２０３から入力される映像・音声データとメディア・デコーダから入力される映像・音声・テキストデータのミキシング（混合）、スイッチング（切替）を制御する機能をもつ。

レイアウト・マネージャ２１５は、“レイアウト・コントロール”信号をＡＶレンダラー２１８に出力する。“レイアウト・コントロール”信号には、出力する動画・静止画・テキストの大きさやその位置に関する情報（表示開始・終了・継続といった表示時間に関する情報を含む場合もある）が含まれており、どのようなレイアウトで表示すべきかをＡＶレンダラー２１８に指示するための情報となっている。また、インタフェース・ハンドラ２０７から入力されるユーザのクリック等の入力情報に対して、どのオブジェクトが指定されたのかを判定し、指定されたオブジェクトに対して定義された関連情報の表示などの動作命令を取り出すようにメタデータ・デコーダ２１７に対して指示する。取り出された動作命令は、スクリプト・インタプリタ２１２に送られ実行される。

メディア・デコーダ２１６（メタデータデコーダを含む）は、動画・静止画・テキストデータをデコードする。これらデコードされた映像データ、テキスト画像データをメディア・デコーダ２１６からＡＶレンダラー２１８に送信する。また、これらデコードデータは、インタフェース・ハンドラ２０２からの“メディア・コントロール”信号の指示によりデコードを行うとともに、インタフェース・ハンドラ２０２からの“タイミング”信号に同期してデコードが行われる。

２１９はサーバ装置２０１のメタデータ記録媒体であり、クライアント装置２００に送信するメタデータが記録されたハードディスク、光ディスク、半導体メモリ、磁気テープなどである。このメタデータは、動画像データ記録媒体２３１に記録されている動画像データに関連したメタデータである。このメタデータには、後で説明するオブジェクト・メタデータが含まれている。２２０はサーバ装置２０１のネットワーク・マネージャであり、クライアント装置２００とネットワーク２２１を介してデータの送受信を行う。

（ＥＤＶＤデータ構造とＩＦＯファイル）
図５３は、動画像データ記録媒体２３１としてエンハンスドＤＶＤビデオディスクを用いた際のデータ構造の一例を示す図である。エンハンスドＤＶＤビデオディスクのＤＶＤビデオエリアは、ＤＶＤビデオ規格と同じデータ構造のＤＶＤビデオコンテンツ（ＭＰＥＧ−２プログラムストリーム構造を持つ）を格納する。さらに、エンハンスドＤＶＤビデオディスクの他の記録エリアは、ビデオコンテンツの再生をバラエティに富んだものにできるエンハンスド・ナビゲーション（以下ＥＮＡＶと略記する）コンテンツを格納する。なお、上記“他の記録エリア”は、ＤＶＤビデオ規格でも存在が認められている。

ここで、ＤＶＤビデオディスクの基本的なデータ構造について説明する。すなわち、ＤＶＤビデオディスクの記録エリアは、内周から順にリードインエリア、ボリュームスペース、およびリードアウトエリアを含んでいる。ボリュームスペースは、ボリューム／ファイル構造情報エリア、およびＤＶＤビデオエリア（ＤＶＤビデオゾーン）を含み、さらにオプションで他の記録エリア（ＤＶＤアザーゾーン）を含むことができる。

上記ボリューム／ファイル構造情報エリアは、ＵＤＦ（Universal Disk Format）ブリッジ構造のために割り当てられたエリアである。ＵＤＦブリッジフォーマットのボリュームは、ＩＳＯ／ＩＥＣ１３３４６のパート２に従って認識されるようになっている。このボリュームを認識するスペースは、連続したセクタからなり、図５３のボリュームスペースの最初の論理セクタから始まる。その最初の１６論理セクタは、ＩＳＯ９６６０で規定されるシステム使用のために予約されている。従来のＤＶＤビデオ規格との互換性を確保するには、このような内容のボリューム／ファイル構造情報エリアが必要となる。

また、ＤＶＤビデオエリアには、ビデオマネージャＶＭＧという管理情報と、ビデオタイトルセットＶＴＳ（ＶＴＳ＃１〜ＶＴＳ＃ｎ）というビデオコンテンツが１つ以上記録されている。ＶＭＧは、ＤＶＤビデオエリアに存在する全てのＶＴＳに対する管理情報であり、制御データＶＭＧＩ、ＶＭＧメニュー用データＶＭＧＭ＿ＶＯＢＳ（オプション）、およびＶＭＧのバックアップデータを含んでいる。また、各ＶＴＳは、そのＶＴＳの制御データＶＴＳＩ、ＶＴＳメニュー用データＶＴＳＭ＿ＶＯＢＳ（オプション）、そのＶＴＳ（タイトル）の内容（映画等）のデータＶＴＳＴＴ＿ＶＯＢＳ、およびＶＴＳＩのバックアップデータを含んでいる。従来のＤＶＤビデオ規格との互換性を確保するには、このような内容のＤＶＤビデオエリアも必要となる。

各タイトル（ＶＴＳ＃１〜ＶＴＳ＃ｎ）の再生選択メニュー等は、ＶＭＧを用いてプロバイダ（ＤＶＤビデオディスクの制作者）により予め与えられ、特定タイトル（例えばＶＴＳ＃１）内での再生チャプター選択メニューや記録内容（セル）の再生手順等は、ＶＴＳＩを用いてプロバイダにより予め与えられている。従って、ディスクの視聴者（ＤＶＤビデオプレーヤのユーザ）は、予めプロバイダにより用意されたＶＭＧ／ＶＴＳＩのメニューやＶＴＳＩ内の再生制御情報（プログラムチェーン情報ＰＧＣＩ）に従ってそのディスクの記録内容を楽しむことができる。しかし、ＤＶＤビデオ規格では、視聴者（ユーザ）が、プロバイダが用意したＶＭＧ／ＶＴＳＩと異なる方法でＶＴＳの内容（映画や音楽）を再生することはできない。

プロバイダが用意したＶＭＧ／ＶＴＳＩと異なる方法でＶＴＳの内容（映画や音楽）を再生したり、プロバイダが用意したＶＭＧ／ＶＴＳＩとは異なる内容を付加して再生したりする仕組みのために用意したのが、図５３のエンハンスドＤＶＤビデオディスクである。このディスクに含まれるＥＮＡＶコンテンツは、ＤＶＤビデオ規格に基づき製造されたＤＶＤビデオプレーヤではアクセスできない（仮にアクセスできたとしてもその内容を利用できない）が、この発明の一実施の形態のＤＶＤビデオプレーヤ（例えば図２のVclickエンジン２０２を装備したクライアント装置２００）ではアクセスでき、その再生内容を利用できるようになっている。

ＥＮＡＶコンテンツは、音声、静止画、フォント・テキスト、動画、アニメーション、Vclickデータ等のデータと、これらの再生を制御するための情報であるＥＮＡＶドキュメント（これはMarkup/Script言語で記述されている）を含むように構成される。この再生を制御するための情報には、ＥＮＡＶコンテンツ（音声、静止画、フォント・テキスト、動画、アニメーション、Vclick等から構成される）および／またはＤＶＤビデオコンテンツの再生方法（表示方法、再生手順、再生切換手順、再生対象の選択等）がMarkup言語やScript言語を用いて記述されている。例えば、Markup言語として、ＨＴＭＬ（Hyper Text Markup Language）／ＸＨＴＭＬ（eXtensible Hyper Text Markup Language）やＳＭＩＬ（Synchronized Multimedia Integration Language）、Script言語として、ＥＣＭＡ（European Computer Manufacturers Association）ScriptやJavaScript（登録商標）のようなScript言語などを組み合わせながら用いることができる。

ここで、図５３のエンハンスドＤＶＤビデオディスクは、他の記録エリア以外の内容がＤＶＤビデオ規格に従っているので、既に普及しているＤＶＤビデオプレーヤを用いても、ＤＶＤビデオエリアに記録されたビデオコンテンツを再生できる（つまり従来のＤＶＤビデオディスクと互換性がある）。他の記録エリアに記録されたＥＮＡＶコンテンツは従来のＤＶＤビデオプレーヤでは再生できない（あるいは利用できない）が、この発明の一実施の形態に係るＤＶＤビデオプレーヤでは再生でき利用できる。従って、この発明の一実施の形態に係るＤＶＤビデオプレーヤを用いＥＮＡＶコンテンツを再生すれば、プロバイダが予め用意したＶＭＧ／ＶＴＳＩの内容だけに限定されることなく、よりバラエティに富んだビデオ再生が可能になる。

特に、図５３に示すように、ＥＮＡＶコンテンツはVclickデータＶＣＤを含み、このVclickデータＶＣＤは、Vclick情報ファイル（Vclickインフォ）ＶＣＩ、Vclickアクセス・テーブルＶＣＡ、VclickストリームＶＣＳ、Vclick情報ファイル・バックアップ（Vclickインフォ・バックアップ）ＶＣＩＢ、Vclickアクセス・テーブル・バックアップＶＣＡＢを含んで構成される。

Vclick情報ファイルＶＣＩは、後述のVclickストリームＶＣＳが、ＤＶＤビデオコンテンツのどの箇所（例えば、ＤＶＤビデオコンテンツのタイトル全体、チャプター全体、あるいはその一部であるプログラムチェーン、プログラム、またはセル等）に付加しているかを表すデータである。Vclickアクセス・テーブルＶＣＡは、後述のVclickストリームＶＣＳ毎に存在し、VclickストリームＶＣＳにアクセスするためのテーブルである。VclickストリームＶＣＳは、動画像中のオブジェクトの位置情報やオブジェクトがクリックされた際の動作記述等のデータを含むストリームである。Vclick情報ファイル・バックアップＶＣＩＢは、前述のVclick情報ファイルＶＣＩのバックアップであり、Vclick情報ファイルＶＣＩと常に同じ内容のものである。また、Vclickアクセス・テーブル・バックアップＶＣＡＢは、前述のVclickアクセス・テーブルＶＣＡのバックアップであり、Vclickアクセス・テーブルＶＣＡと常に同じ内容のものである。

なお、図５３の例では、Vclick情報ファイルＶＣＩ内に、後述する“Vclickデータの検索テーブル（VCKSRCT.IFO）”を格納できるようになっている。

図５３の例ではVclickデータＶＣＤはエンハンスドＤＶＤビデオディスク上に記録されている。しかし、前述したようにVclickデータＶＣＤはネットワーク上のサーバ装置２０１に置かれている場合もある。すなわち、VclickデータＶＣＤ（Vclickデータの検索テーブルを含む）は、ディスク内および／またはディスク外に用意しておくことができる。そして、ディスク外にVclickデータＶＣＤを用意しておけば、VclickデータＶＣＤが記録されていない旧タイプのディスク（過去に市販されたビデオディスクなど）のコンテンツ再生においても、あるいはＴＶ放送を録画したコンテンツの再生においても、VclickデータＶＣＤを利用した再生が可能になる（それらのコンテンツに対応してVclickデータＶＣＤが作成されている場合）。

さらには、ビデオ記録可能な媒体（例えばＤＶＤ−Ｒディスク、ＤＶＤ−ＲＷディスク、ＤＶＤ−ＲＡＭディスク、ハードディスクなど）と、ビデオレコーダ（例えばＤＶＤ−ＶＲレコーダ、ＤＶＤ−ＳＲレコーダ、ＨＤ−ＤＶＤレコーダ、ＨＤＤレコーダなど）を用いてユーザが独自のディスクを作成した場合において、このディスクにVclickデータＶＣＤを含むＥＮＡＶコンテンツを記録するか、このディスク以外のパーソナルコンピュータのデータストレージなどにVclickデータＶＣＤを用意しこのパーソナルコンピュータとレコーダを接続すれば、ＤＶＤ−ＲＯＭビデオ＋図２のＥＮＡＶプレーヤと同様なメタデータ再生を楽しむことができる。

図５４は、上述した、Vclick情報ファイルＶＣＩ、Vclickアクセス・テーブルＶＣＡ、VclickストリームＶＣＳ、Vclick情報ファイル・バックアップＶＣＩＢ、Vclickアクセス・テーブル・バックアップＶＣＡＢを構成するためのファイルの例を示す。Vclick情報ファイルＶＣＩを構成するファイル（VCKINDEX.IFO）とVclickデータの検索テーブル（VCKSRCT.IFO）は、例えばXML（Extensible Markup Language）言語で記述されており、Vclick情報ファイルを構成するファイル（VCKINDEX.IFO）には、VclickストリームＶＣＳと、そのVclickストリームＶＣＳが付加されるＤＶＤビデオコンテンツの位置情報（ＶＴＳ番号、タイトル番号、ＰＧＣ番号等）が記述されている。Vclickデータの検索テーブル（VCKSRCT.IFO）は、検索処理を迅速に行なうために、VclickオブジェクトとＤＶＤビデオコンテンツとの対応が取れるようになっている。Vclickアクセス・テーブルＶＣＡは、一つ以上のファイルから構成されており（VCKSTR01.IFO〜VCKSTR99.IFO、または任意のファイル・ネーム）、一つのアクセス・テーブルＶＣＡ・ファイルは、一つのVclickストリームＶＣＳに対応する。

Vclickストリーム・ファイルは、VclickストリームＶＣＳの位置情報（ファイルの先頭からの相対バイト・サイズ）と時間情報（対応する動画像のタイムスタンプもしくはファイルの先頭からの相対時間情報）の関係が記述されており、与えられた時間に対応する再生開始位置を検索することができる。

VclickストリームＶＣＳは、一つ以上のファイルから構成されており（VCKSTR01.VCK〜VCKSTR99.VCK、または任意のファイル・ネーム）、前述のVclick情報ファイルＶＣＩの記述を参照して、付加されるＤＶＤビデオコンテンツとともに再生できる。また、複数の属性が存在する場合（例えば日本語用VclickデータＶＣＤと英語用VclickデータＶＣＤ等）は、属性毎に、異なるVclickストリームＶＣＳ（つまり異なるファイル）として構成することも可能である。また、それぞれの属性をマルチプレクスして、一つのVclickストリームＶＣＳ（つまり一つのファイル）として構成することも可能である（例えば図５参照）。

なお、前者（異なる属性を複数のVclickストリームＶＣＳで構成）の場合は、再生装置（プレーヤ）にいったん記憶させるときのバッファ（図２の例では２０９）の占有容量を少なくすることができる。また、後者（異なる属性を一つのVclickストリームＶＣＳで構成…前述した図５のような例など）の場合は、属性を切り替えるとき、ファイルを切り替えずに、一つのファイルを再生したままでよいので、切り替える速度を速くすることができる。

ここで、VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡの関連付けは、例えばファイル名にて行うことが可能である。前述の例においては、一つのVclickストリームＶＣＳ（VCKSTRXX.VCK、XXは01〜99）に対して、一つのVclickアクセス・テーブルＶＣＡ（VCKSTRXX.IFO、XXは01〜99）を割り当てており、拡張子以外のファイル名を同じものにすることにより、VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡの関連付けが識別可能になる。

これ以外にも、Vclick情報ファイルＶＣＩにて、VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡの関連付けを記述することにより（具体的には、ＶＣＩ内においてＶＣＳの記述とＶＣＡの記述を並行に記載することにより）、VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡの関連付けが識別可能になる。

Vclick情報ファイル・バックアップはVCKINDEX.BUPファイルとVCKSRCT.BUPファイルにて構成されており、前述のVclick情報ファイル（VCKINDEX.IFO）とVclickデータの検索テーブル（VCKSRCT.IFO）の全く同じ内容である。VCKINDEX.IFO及びVCKSRCT.IFO が何らかの理由により（ディスクの傷や汚れ等により）、読み込みが不可能な場合、このVCKINDEX.BUP、VCKSRCT.BUPを代わりに読み込むことにより、所望の手続きを行うことができる。Vclickアクセス・テーブル・バックアップはVCKSTR01.BUP〜VCKSTR99.BUPファイルにて構成されており、前述のVclickアクセス・テーブル（VCKSTR01.IFO〜VCKSTR99.IFO）と全く同じ内容のものである。一つのVclickアクセス・テーブル（VCKSTRXX.IFO、XXは01〜99）に対して、一つのVclickアクセス・テーブル・バックアップ（VCKSTRXX.BUP、XXは01〜99）を割り当てており、拡張子以外のファイル名を同じものにすることにより、Vclickアクセス・テーブルとVclickアクセス・テーブル・バックアップの関連付けが識別可能になる。VCKSTRXX.IFO が何らかの理由により（ディスクの傷や汚れ等により）、読み込みが不可能な場合、このVCKSTRXX.BUPを代わりに読み込むことにより、所望の手続きを行うことができる。

（データ構造の概略とアクセス・テーブル）
VclickストリームＶＣＳには、動画像データ記録媒体２３１に記録されている動画像に登場する人・物などのオブジェクトの領域に関するデータと、クライアント装置２００におけるオブジェクトの表示方法とユーザがそれらオブジェクトを指定したときにクライアント装置が取るべき動作のデータが含まれている。以下では、Vclickデータの構造とその構成要素の概要について説明する。

まず動画像に登場する人・物などのオブジェクトの領域に関するデータであるオブジェクト領域データについて説明する。

図３はオブジェクト領域データの構造を説明する図である。３００は、１つのオブジェクトの領域が描く軌跡をＸ（映像の水平方向の座標値）、Ｙ（映像の垂直方向の座標値）、Ｔ（映像の時刻）の３次元座標上に表現したものである。オブジェクト領域はあらかじめ決められた範囲内の時間（例えば０．５秒から１．０秒の間や、２秒から５秒の間、など）ごとにオブジェクト領域データに変換される。図３では１つのオブジェクト領域３００が３０１から３０５の５つのオブジェクト領域データに変換されており、これらオブジェクト領域データは別々のVclickアクセスユニット（ＡＵ）（後述）に格納される。このときの変換方法としては、例えばＭＰＥＧ−４の形状符号化やＭＰＥＧ−７の時空間領域記述子などを使うことができる。ＭＰＥＧ―４形状符号化やＭＰＥＧ−７時空間記述子はオブジェクト領域の時間的な相関を利用してデータ量を削減する方式であるため、途中からデータが復号できないことや、ある時刻のデータが欠落した場合に周囲の時刻のデータも復号できなくなるという問題がある。図３のように長い時間連続して動画像中に登場しているオブジェクトの領域を時間方向に分割してデータ化することにより、ランダムアクセスを容易にし、一部のデータの欠落の影響を軽減することができる。各Vclick_AUは動画像の中である特定の時間区間でのみ有効である。このVclick_AUが有効な時間区間をVclick_AUの有効期間（lifetime）と呼ぶ。

図４は、この発明の一実施の形態で用いるVclickストリームＶＣＳ中の、独立にアクセス可能な１単位（Vclick_AU）の構造を表したものである。４００はオブジェクト領域データである。図３で説明したとおり、ここには１つのオブジェクト領域のある連続した時間区間における軌跡がデータ化されている。このオブジェクト領域が記述されている時間区間をそのVclick_AUのアクティブ期間（active time）と呼ぶ。通常はVclick_AUのアクティブ期間はそのVclick_AUの有効期間と同一である。しかし、Vclick_AUのアクティブ期間をそのVclick_AUの有効期間の一部とすることも可能である。

４０１はVclick_AUのヘッダである。ヘッダ４０１には、Vclick_AUを識別するためのＩＤと、そのＡＵのデータサイズを特定するデータが含まれる。４０２はタイムスタンプであり、このVclick_AUの有効期間開始のタイムスタンプを示している。通常はVclick_AUのアクティブ期間と有効期間が同一であるため、オブジェクト領域データ４００に記述されたオブジェクト領域が動画像のどの時刻に相当するかも示している。図３に示されるように、オブジェクト領域はある時間範囲に及んでいるため、通常はタイムスタンプ４０２にはオブジェクト領域の先頭の時刻を記述しておく。もちろんオブジェクト領域データに記述されたオブジェクト領域の時間間隔やオブジェクト領域の末尾の時刻も記述するようにしても良い。４０３はオブジェクト属性情報であり、例えばオブジェクトの名称、オブジェクトが指定された際の動作記述、オブジェクトの表示属性などが含まれる。これらVclick_AU内のデータに関しては、後でより詳細に説明する。Vclick_AUは、サーバ装置（図２の２０１など）においては送信しやすいようにタイムスタンプ順に並べて記録しておくほうが良い。

図５は複数のＡＵをタイムスタンプ順に並べてVclickストリームＶＣＳを生成する方法を説明する図である。この図では、カメラアングル１とカメラアングル２の２つのカメラアングルがあり、クライアント装置でカメラアングルを切り替えると表示される動画像も切り替えられることを想定している。また、選択可能な言語モードには日本語と英語の２種類があり、それぞれの言語に対して別々のVclickデータが用意されている場合を想定している。

図５に於いて、カメラアングル１かつ日本語用のVclick_AUは５００、５０１、５０２であり、カメラアングル２かつ日本語用のVclick_AUのＡＵは５０３である。そして英語用のVclick_AUは５０４と５０５である。５００から５０５はそれぞれ動画像中の一つのオブジェクトに対応したデータである。すなわち、図３と図４で説明したとおり一つのオブジェクトに関するメタデータは一つまたは複数のVclick_AUで構成されている（図５では１つの長方形が１つのＡＵを表している）。この図の横軸は動画像中の時間に対応しており、オブジェクトの登場時間に対応させて５００から５０５を表示してある。

各Vclick_AUの時間的な区切りは任意でもよいが、図５に例示されるように、全てのオブジェクトに対してVclick_AUの区切りを揃えておくと、データの管理が容易になる。５０６は、これらのVclick_AU（５００から７０５）から構成されたVclickストリームＶＣＳである。VclickストリームＶＣＳは、ヘッダ部５０７に続いてVclick_AUをタイムスタンプ順にならべることにより構成される。

選択しているカメラアングルはユーザが視聴中に変更する可能性が高いため、このようにVclickストリームＶＣＳに異なるカメラアングルのVclick_AUを多重化してVclickストリームＶＣＳを作った方が良い。これは、クライアント装置２００側で高速な表示切り替えが可能だからである。例えば、Vclickデータがサーバ装置２０１に置かれているとき、複数のカメラアングルのVclick_AUを含むVclickストリームＶＣＳをそのままクライアント装置２００に送信すれば、クライアント装置２００では視聴中のカメラアングルに対応したVclick_AUが常に届いているため、瞬時にカメラアングルの切り替えができる。もちろん、クライアント装置２００の設定情報をサーバ装置２０１に送り、必要なVclick_AUのみをVclickストリームＶＣＳから選択して送信することも可能であるが、この場合はサーバ（２０１）との通信を行う必要があるため多少処理が遅くなる（もっとも、通信に光ファイバなどの高速手段を用いればこの処理遅延の問題は大筋解決できる）。

一方、動画像タイトル、ＤＶＤビデオのＰＧＣ、動画像のアスペクト比、視聴地域等の属性は変更の頻度が低いため、別々のVclickストリームＶＣＳとして作成しておいた方がクライアント装置２００の処理が軽くなり、ネットワークの負荷も軽くなる。複数のVclickストリームＶＣＳがある場合にどのVclickストリームＶＣＳを選択すべきかは、すでに説明したようにVclick情報ファイルＶＣＩを参照して決定できる。

次に、別のVclick_AUの選択方法について説明する。クライアント装置２００がサーバ装置２０１から、Vclickストリーム（ＶＣＳ）５０６を取得し、クライアント装置２００の側で必要なアクセスユニット（ＡＵ）のみを利用する場合を考える。この場合、必要なVclick_AUを識別する為のＩＤが各ＡＵに振られていても良い。これをフィルタＩＤと呼ぶ。

必要とされるアクセスユニット（ＡＵ）の条件は、例えば、Vclick情報ファイルＶＣＩ中に次のように記述される：
<pgc num="7">
//audio/subpictureストリームとangleによるVclickストリームＶＣＳの定義
<object data="file://dvdrom:/dvd_enav/vclick1.vck" audio="1" subpic="1" angle="1"/>
<object data="file://dvdrom:/dvd_enav/vclick1.vck" audio="3" subpic="2" angle="1"/>
</pgc>
ここでは、一つのVclickストリームＶＣＳに対して、二種類のフィルタリング条件が記述されている。これは、クライアントのシステムパラメータの設定に応じて、同一のVclickストリームＶＣＳから異なる属性を有する二種類のVclick_AUが選択可能である事を示している。

なお、Vclick情報ファイルＶＣＩは、動画像データ記録媒体（例えば図５３のエンハンスドＤＶＤビデオディスク）上に存在しても良いし、サーバ装置２０１からネットワーク経由でクライアント装置２００にダウンロードされるように構成しても良い。Vclick情報ファイルＶＣＩは、通常は、動画像データ記録媒体（エンハンスドＤＶＤビデオディスク）やサーバ装置（２０１）など、VclickストリームＶＣＳと同じところから供給される。

アクセスユニット（ＡＵ）が前述したフィルタＩＤを持たない場合、メタデータ・マネージャ２１０が必要なVclick_AUを識別するには、ＡＵのタイムスタンプや属性などを見て、与えられた条件に適合するＡＵを選択する。

フィルタＩＤを用いる例を、上記の記述に即して説明する。audioはオーディオ・ストリーム番号を表しているが、これを４ビットの数値で表現する。同様に、副映像番号subpicとアングル番号angleに、それぞれ４ビットの数値を割り当てる。これにより、三つのパラメータの状態を１２ビットの数値で表現する事ができる。例えば、audio="3"、subpic="2"かつangle="1"のパラメータは、１６進表記で0x321と表現される。これをフィルタＩＤとして用いる。即ち、Vclick_AUは１２ビットのフィルタＩＤをVclick_AUヘッダ内に有する（図１４のfiltering_id参照）。これは、ＡＵを選別する独立なパラメータ値のそれぞれに数字を割り当て、当該数字の組み合わせによりフィルタＩＤを定める方法である。なお、フィルタＩＤはVclick_AUヘッダ以外の場所に記述しても良い。

クライアント装置２００のフィルタリング動作を図４４に示す。まず、メタデータ・マネージャ２１０がインタフェース・ハンドラ２０７から、動画像クロック値ＴとフィルタＩＤ xとを受け取る（ステップＳ４４０１）。データ・マネージャ２１０は、バッファ２０９に格納されているVclickストリームＶＣＳの中から、有効期間が動画像クロック値Ｔを含むようなVclick_AUを全て見出す（ステップＳ４４０２）。このようなＡＵを見出すには、Vclickアクセス・テーブルＶＣＡを用いて、図４５及び図４６のような手続きを用いることができる。メタデータ・マネージャ２１０は、上記Vclick_AUヘッダを調べ、xと同一のフィルタＩＤを有するＡＵのみをメディア・デコーダ２１６に送る（ステップＳ４４０３〜Ｓ４４０５）。

以上の手続きによって、バッファ２０９からメタデータ・デコーダ２１７に送られるVclick_AUは次の性質を有する：
i）これら全てのＡＵは同一の有効期間を有するが、動画像クロックＴは当該有効期間に含まれる；
ii）これら全てのＡＵは、同一のフィルタＩＤ xを有する。

iii）上記i）及びii）の条件を満足する、当該オブジェクト・メタデータ・ストリーム中のＡＵは、これらのＡＵ以外には存在しない。

なお、あるフィルタＩＤで特定のＡＵを識別し選択するということは、選択されたＡＵを含むVclickストリームを選択することにもなる。一方、再生すべきVclickストリームの選択は、VclickインフォＶＣＩファイルを参照することによっても可能である。

上記では、フィルタＩＤは、パラメータに割り当てられたの組み合わせによって定義されていたが、Vclick情報ファイルＶＣＩの中でフィルタＩＤを直接指定するようにしても良い。例えば、IFOファイル中には次のように定められている：
<pgc num="5">
<param angle="1">
<object data="file://dvdrom:/dvd_enav/vclick1.vck" filter_id="3"/>
</param>
<param angle="3">
<object data="file://dvdrom:/dvd_enav/vclick2.vck" filter_id="4"/>
</param>
<param aspect="16:9" display="wide">
<object data="file://dvdrom:/dvd_enav/vclick1.vck" filter_id="2"/>
</param>
</pgc>
上記の記述は、各パラメータの指定によって、VclickストリームＶＣＳとフィルタＩＤの値が定まる事を示している。フィルタＩＤによるVclick_AUの選別と、バッファ２０９からメディア・デコーダ２１７へのＡＵの転送は、図４４の手続きと同じである。上記Vclick情報ファイルＶＣＩの指定に基づき、プレーヤのアングル番号が3である場合、"vclick2.vck"というファイルに格納されているVclickストリームＶＣＳから、フィルタＩＤの値が4に等しいVclick_AUのみが、バッファ２０９からメディア・デコーダ２１７に送られる。

サーバ装置２０１にVclickデータがある場合、動画像が先頭から再生される場合にはサーバ装置２０１はVclickストリームＶＣＳを先頭から順にクライアント装置に配信すればよい。しかし、ランダムアクセスが生じた場合にはVclickストリームＶＣＳの途中からデータを配信する必要がある。このとき、VclickストリームＶＣＳ中の所望の位置に高速にアクセスするためには、Vclickアクセス・テーブルＶＣＡが必要となる。

図６はVclickアクセス・テーブルＶＣＡの例である。このテーブルはあらかじめ作成され、サーバ装置２０１内に記録されている。Vclick情報ファイルＶＣＩと同じファイルにしておくことも可能である。６００はタイムスタンプの配列であり、動画像のタイムスタンプが列挙されている。６０１はアクセスポイントの配列であり、動画像のタイムスタンプに対応したVclickストリームＶＣＳの先頭からのオフセット値が列挙されている。動画像のランダムアクセス先のタイムスタンプに対応した値がVclickアクセス・テーブルＶＣＡにない場合は、近い値のタイムスタンプのアクセスポイントを参照し、そのアクセスポイント周辺でVclickストリームＶＣＳ内のタイムスタンプを参照しながら送信開始場所を探索する。もしくは、Vclickアクセス・テーブルＶＣＡから動画像のランダムアクセス先のタイムスタンプよりも手前の時刻のタイムスタンプを探索し、そのタイムスタンプに対応したアクセスポイントからVclickストリームＶＣＳを送信する。

上記Vclickアクセス・テーブルＶＣＡは、サーバ装置２０１が格納しており、サーバ装置２０１がクライアントからのランダムアクセスに応じて、送信すべきVclickデータの検索の便宜に資する為のものである。しかし、サーバ装置２０１が格納しているVclickアクセス・テーブルＶＣＡをクライアント装置２００にダウンロードして、VclickストリームＶＣＳの検索をクライアント装置２００に行わせるようにしても良い。特に、VclickストリームＶＣＳが、サーバ装置２０１からクライアント装置２００に一括ダウンロードされる場合、Vclickアクセス・テーブルＶＣＡも又、サーバ装置２０１からクライアント装置２００に一括ダウンロードされる。

一方、VclickストリームＶＣＳがＤＶＤなどの動画像記録媒体に記録されて提供される場合も考えられる。この場合も、再生コンテンツのランダムアクセスに応じて、利用すべきデータを検索するために、クライアント装置２００がVclickアクセス・テーブルＶＣＡを利用する事は有効である。この場合Vclickアクセス・テーブルＶＣＡは、VclickストリームＶＣＳ同様、動画像記録媒体に記録されており、クライアント装置２００は当該動画像記録媒体から当該Vclickアクセス・テーブルＶＣＡを内部の主記憶等に読み出して利用する。

動画像のランダム再生などに伴って発生する、VclickストリームＶＣＳのランダム再生は、メタデータ・デコーダ２１７によって処理される。図６のVclickアクセス・テーブルＶＣＡにおいて、タイムスタンプtimeは、動画像記録媒体に記録された動画像のタイムスタンプの形式を有する時刻情報である。例えば、動画像がＭＰＥＧ−２で圧縮されて記録されているなら、timeはＭＰＥＧ−２のＰＴＳ（Presentation Time Stamp）の形式をとる。更に、動画像が、例えばＤＶＤのように、タイトルやプログラム・チェーンなどのナビゲーション構造を持つ場合、それらを表現するパラメータ（タイトル番号TTN、ビデオタイトルセットタイトル番号VTS_TTN、タイトルプログラムチェーン番号TT_PGCN、パートオブタイトル番号PTTNなど）がtimeの形式に含まれる。

タイムスタンプの値の集合には、何らかの自然な全順序関係が定義されているものと仮定する。例えば、上記のＰＴＳについては時刻としての自然な順序関係が導入可能である。ＤＶＤのパラメータを含むタイムスタンプについても、ＤＶＤの自然な再生順序に従って、順序関係を導入する事が可能である。VclickストリームＶＣＳは次の条件を満たしている：
i）VclickストリームＶＣＳ中のVclick_AUはタイムスタンプの昇順に並べられている。

このとき、Vclick_AUの有効期間を次のように決定する：あるＡＵのタイムスタンプ値をtとおく。VclickストリームＶＣＳにおいて当該ＡＵ以降にあるＡＵのタイムスタンプ値uについて、上記条件によりu >= tなる関係が成立する。このようなuの中でu≠tである最小の値をt’とおく。時刻tを開始時刻、時刻t’を終了時刻とする期間を、当該ＡＵの有効期間とする。ただし、当該ＡＵ以降にu > tなるタイムスタンプ値uを有するＡＵが存在しない場合、当該ＡＵの有効期間の終了時刻は、動画像の終了時刻に一致するものとする。

Vclick_AUのアクティブ期間は、先に定義したとおり、Vclick_AU含まれるオブジェクト領域データに記述されているオブジェクト領域の時間範囲である。ここで、VclickストリームＶＣＳについて、アクティブ期間に関する次の制約条件をおく：
ii）Vclick_AUのアクティブ期間は、当該ＡＵの有効期間に含まれている。

上記i）、ii）の制約条件を満たすVclickストリームＶＣＳは、以下に示すような良い性質を有する：
第一には、下に述べるように、VclickストリームＶＣＳのランダムアクセスを高速に行う事が可能である。第二には、VclickストリームＶＣＳの再生を行う際のバッファ処理を単純化する事が可能となる。

バッファ（図２の２０９など）にはVclickストリームＶＣＳがVclick_AU単位で格納され、大きいタイムスタンプを持つＡＵから消去されて行く。もし、上記二つの仮定が無ければ、有効なＡＵをバッファ上に保持しておく為に、大きなバッファと複雑なバッファ管理が必要になる。以後、VclickストリームＶＣＳは、上記i）及びii）の二条件を満たすと仮定して説明を行う。

図６のVclickアクセス・テーブルＶＣＡにおいて、アクセスポイントoffsetはVclickストリームＶＣＳ上の位置を指し示す。例えば、VclickストリームＶＣＳはファイルであり、offsetは当該ファイルのファイル・ポインタの値を指し示す。タイムスタンプtimeと組になっているアクセスポイントoffsetの関係は次のようになっている：
ｉ）offsetの示す位置は、あるVclick_AUの先頭位置である；
ii）当該ＡＵがもつタイムスタンプの値は、timeの値以下である；
iii）当該ＡＵより一つ前にあるＡＵがもつタイムスタンプの値は、timeより真に小さい。

Vclickアクセス・テーブルＶＣＡにおけるtimeの並びの間隔は任意で良いし、均等である必要もない。しかし、検索等の便宜を考慮して、均等にとっても良い。

Vclickアクセス・テーブルＶＣＡを用いた具体的な検索手順を図４５及び図４６に示す。VclickストリームＶＣＳがサーバ装置２０１からバッファ２０９に予めダウンロードされる場合、Vclickアクセス・テーブルＶＣＡも同様にサーバ装置２０１からダウンロードされ、バッファ２０９内に格納される。VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡとが共に動画像データ記録媒体２３１に蓄積されている場合も同様に、VclickストリームＶＣＳとVclickアクセス・テーブルＶＣＡはディスク装置２３０からロードされ、バッファ２０９内に格納される。

メタデータ・マネージャ２１０は、インタフェース・ハンドラ２０７から動画像クロックＴを受け取ると（ステップＳ４５０１）、バッファ２０９に格納されているVclickアクセス・テーブルＶＣＡのtimeを検索し、t’ <= Tなる最大のtime t’を求める（ステップＳ４５０２）。ここでの検索のアルゴリズムとして、例えばバイナリ・サーチを用いて、高速に検索を行う事ができる。Vclickアクセス・テーブルＶＣＡにおいて、得られたtime t’と組になっているoffset値を変数hに代入する（ステップＳ４５０３）。メタデータ・マネージャ２１０は、バッファ２０９に格納されているVclickストリームＶＣＳの先頭からhバイト目に存在するＡＵxを見出し（ステップＳ４５０４）、xのタイムスタンプ値を変数tに代入する（ステップＳ４５０５）。上記条件より、tはt’以下であるから、t <= Tが成立する。

メタデータ・マネージャ２１０は、xから始めて、当該VclickストリームＶＣＳ中のVclick_AUを順次調べて行き、次のＡＵを改めてxとおく（ステップＳ４５０６）。続いて、変数h’にxのオフセット値を代入し（ステップＳ４５０７）、xのタイムスタンプ値を変数uに代入する（ステップＳ４５０８）。u > Tであれば（ステップＳ４５０９イエス）、バッファ２０９に対して、VclickストリームＶＣＳのオフセットhからh’までを、メディア・デコーダ２１６に送るよう指示を出す（ステップＳ４５１０〜Ｓ４５１１）。一方、u <= Tであって（ステップＳ４５０９ノー）、かつu > tであれば（ステップＳ４６０１イエス）、tの値をuで更新する（即ちt = uとする）（ステップＳ４６０２）。そして、変数hの値をh’で更新する（即ちh= h’とする）（ステップＳ４６０３）。

VclickストリームＶＣＳ上に、次のＡＵが存在すれば（即ち、xが最後のＡＵでなければ）（ステップＳ４６０４イエス）、次のＡＵを改めてxとおき、上記手続きを繰り返す（図４５のステップＳ４５０６へ戻る）。ここで、もし、xが当該VclickストリームＶＣＳの最後のVclick_AUであれば（ステップＳ４６０４ノー）、バッファ２０９に対して、VclickストリームＶＣＳのオフセットhから最後までを、メディア・デコーダ２１６に送るよう指示を出す（ステップＳ４６０５〜Ｓ４６０６）。

以上の手続きによって、バッファ２０９からメディア・デコーダ２１６に送られるVclick_AUは、明らかに次の性質を有する：
ｉ）全てのVclick_AUは同一の有効期間を有する。しかも、動画像クロックＴは当該有効期間に含まれる。

ii）上記i）の条件を満足する、当該VclickストリームＶＣＳ中のVclick_AUは、これらのＡＵ以外には存在しない。

VclickストリームＶＣＳにおけるVclick_AUの有効期間は、当該ＡＵのアクティブ期間を含んでいるが、これらは常に一致しているとは限らない。実際、図４７に示すような状況が考えられる。それぞれオブジェクト１及びオブジェクト２を記述するＡＵ#1及びＡＵ#2の有効期間は、ＡＵ#3の有効期間の開始時刻（t476）までである。しかし、各ＡＵのアクティブ期間は有効期間に一致していない（図４７の例ではt476≠t474≠t472）。

いま、ＡＵが#1、#2、#3の順に並んだVclickストリームＶＣＳを考える。そして、図４７の例において、動画像クロックＴが指定されたとする。この場合、図４５及び図４６に示すような手続きによれば、当該VclickストリームＶＣＳからＡＵ#1とＡＵ#2とがメディア・デコーダ２１６に送られる。メディア・デコーダ２１６は受け取ったVclick_AUのアクティブ期間を認識できるため、この処理によりランダムアクセスが実現可能である。しかし実際には、オブジェクトが存在しない時刻Ｔ（有効期間内ではあるが非アクティブ期間であるt474〜t476の間）についても、バッファ２０９からのデータ転送と、メディア・デコーダ２１６におけるデコード処理が発生するため、クライアント装置２００におけるハードウエアの計算効率が低下するという問題がある。この問題は、NULL_AUと呼ぶ特別なVclick_AUを導入することで解決できる。

NULL_AUの構造を図４８に示す。NULL_AUは、通常のVclick_AUが必ず持つオブジェクト領域データを持たない。すなわち、NULL_AUは有効期間のみを持ち、アクティブ期間は存在しない。NULL_AUのヘッダには当該ＡＵがNULL_AUである事を示すフラグが含まれている。NULL_AUは、VclickストリームＶＣＳにおいて、オブジェクト（図４９の例ではオブジェクト２）のアクティブ期間が存在しない時間範囲（図４９の例ではt494〜t496）に挿入する事ができる。

メタデータ・マネージャ２１０は、ヘッダ（図４８の“Vclick AU Header”）に含まれる図示しないフラグから当該ＡＵが“NULL_AU”であることを検知すると、このNULL_AUをメディア・デコーダ２１６に送出しない。このようなNULL_AUを導入した場合、図４７は例えば図４９の様に変化する。図４９のＡＵ#4がNULL_AUである。この場合、VclickストリームＶＣＳおいて、Vclick_AUは例えばＡＵ#1'、#2'、#4、#3の順に並んでいる。NULL_AUを含むVclickストリームＶＣＳに関して、図４５及び図４６に相当するメタデータ・マネージャ２１０の動作を図５０、図５１及び図５２に示す。

すなわち、メタデータ・マネージャ２１０がインターフェース・ハンドラ２０７から動画像クロックＴを受け取り（ステップＳ５００１）、 t’ <= Tである最大のt’を求め（ステップＳ５００２）、 t’と組になるoffset値を変数hに代入する（ステップＳ５００３）。続いて、オブジェクトメタデータストリームにおいてオフセット値hにあるアクセスユニットＡＵをxとおき（ステップＳ５００４）、xのタイムスタンプ値を変数tに格納する（ステップＳ５００５）。ここで、xがNULL_AUであれば（ステップＳ５００６イエス）、xの次のＡＵを改めてxとおいて（ステップＳ５００７）、ステップＳ５００６に戻る。ここで、xがNULL_AUでなければ（ステップＳ５００６ノー）、xのオフセット値を変数h’に格納する（ステップＳ５１０１）。この後の処理（図５１のステップＳ５１０２〜Ｓ５１０５および図５２のステップＳ５２０１〜Ｓ５２０６）は、図４５のステップＳ４５０８〜Ｓ４５４５１１および図４６のステップＳ４６０１〜Ｓ４６０６と同様な処理となる。

（検索テーブル）
ユーザが全てのVclickストリーム（あるいは複数のVclickストリーム群）からある特定のVclickデータを検索したい場合のために、対象Vclickデータの検索を効率的に行なう検索テーブルを用意する。この検索テーブルの情報（VCKSRCT.IFO）は、図５３の例ではディスク２３１のVclick情報ＶＣＩ内に格納され、この検索テーブルのファイルは図５４に例示するようにＤＶＤ＿ＥＮＡＶというディレクトリ内に配置される。

図５５は、この発明の一実施の形態に係るＤＶＤ再生準備処理を説明するフローチャート図である。図５５に示すように、検索テーブル（VCKSRCT.IFO）は、ディスクが再生機器（ディスクドライブ）に挿入され（Ｓ５５０１）、VCKINDEX.IFOがロードされた後に読み込まれる（Ｓ５５０２）。この検索テーブル（VCKSRCT.IFO）は、ディスク上もしくはサーバ上、または再生機器内に記録することができる。コンテンツ製作者があらかじめ検索の利便性のためにこのテーブルを用意する場合にはディスク内に記録しておくことが考えられる。また、ディスク作成後に検索テーブルをアップデートしたい場合などにはサーバ上に新たに検索テーブルを作成し、アップデートすることもできる。また、再生機器自らのファームウエアが、Vclick IDやアノテーション（Vclick_AUで記述されているオブジェクトに関する注釈を表す文字列：図１９参照）から検索テーブルを作成することもできる。

すなわち、検索テーブルの情報（VCKSRCT.IFO）がサーバ上にあるときは（Ｓ５５０３イエス）サーバから検索テーブルがロードされ（Ｓ５５０４）、サーバになくてもディスク上にあるときは（Ｓ５５０３ノー；Ｓ５５０５イエス）ディスクから検索テーブルがロードされる。（Ｓ５５０４）。サーバにもディスクにもないときは（Ｓ５５０３ノー；Ｓ５５０５ノー）、再生機器は検索テーブルなしでユーザからの再生開始指示を待つか、自動的に検索テーブルの情報（VCKSRCT.IFO）を作成する（Ｓ５５０６）。

この自動作成は、例えばデフォルトで用意した複数のVclickオブジェクトのＩＤそれぞれに、関連する時間および／またはテキストを、図５４のVCKINDEX.IFO（VclickデータとＤＶＤビデオの関係を示す情報）を参照して対応付けることで具現できる（図５８中の（ａ）参照）。

あるいは、図１４に示した“continue_flag”や“ojbect_subid”等を利用して、検索テーブルの情報（VCKSRCT.IFO）を自動作成することも可能である（図５８中の（ｂ）参照）。

あるいは、デフォルトで用意した複数のVclickオブジェクトのＩＤそれぞれに、ＤＶＤビデオのコンテンツとして記録された映像のチャプタ毎の指定時間を対応させることで、検索テーブルの情報（VCKSRCT.IFO）を自動作成することも可能である（図５８中の（ｃ）、図５９等参照）。

図５６および図５７は、オブジェクトの選択方法および再生方法の一例を説明するフローチャート図である。メニューを含むDVD再生中にユーザ動作により、検索が開始される（Ｓ５６０１またはＳ５７０１）。リモコンなどによってユーザの検索が開始されると、検索メニューを表示し（Ｓ５６０２またはＳ５７０２）、キーワードによる一致検索（Ｓ５６０６〜Ｓ５６０７またはＳ５７０６〜Ｓ５７０７）か、選択検索か（Ｓ５６０３またはＳ５７０３）が選ばれる。

図５８は、この発明の一実施の形態に係る検索テーブルの構成例（その１）を説明する図である。ユーザはVcobjタグ内に記述されるテキスト情報（図５８中の“丸・丸・丸・丸”や“菱形・菱形・菱形・菱形”等参照）によるテキストの一致検索、もしくは選択検索を行なうことができる。テキストの一致検索はリモコン、キーボードやマウスなどの入力装置を使用してユーザが検索したい言葉を入力する。その言葉に一致、もしくは関連のあるVclickデータを検索して、対応するサムネイルの表示や対応個所へのジャンプなどによって、ユーザに検索結果を表示（通知）できる。

また、選択検索の場合には、ユーザはリモコン、キーボード、マウス等の入力装置を用い、画面上に表示されるキーワードを順番に選択していくことによって検索対象にアクセスすることができる。この方法を採用することで、検索対象の絞込みが可能となる。また、上記２つの方法（選択検索と一致検索）を組み合わせて利用することもできる。

検索テーブルの情報（VCKSRCT.IFO）は、図５８に例示されるようにXMLで作成されており、Vcobjタグ内に属性として対象VclickデータのobjectIDを持つことで関連付けている。また、より早く対象オブジェクトにアクセスするためにオブジェクトの再生開始時間などを属性情報として持つこともできる。

図５９は、この発明の一実施の形態に係る検索テーブルの構成例（その２）を説明する図である。図５９に例示されるように、同じテキスト情報に異なったVclickデータが指定されている（Vcobj id=“03h”とVcobj id=“04h”）ような場合に対応するため、属性情報にチャプターナンバーや表示時間など（例えばtime=“00:00-00:50”と“ch=1”）の指定をすることも可能としている。

図６０は、この発明の一実施の形態に係る検索テーブルの構成例（その３）を説明する図である。図６０の例では、XMLデータを階層構造にしておき、peopleタグの子要素として役名を表すcast、役者の名前を表すactorなどを持つ（ここでは、例えば“<people>人の名前”が上位階層で“<cast>役名”と“<actor>役者名”が下位階層）。このように、XMLデータを階層構造にすることで、階層を上から下へたどるような（場合によっては階層を下流へたどる途中で下から上へ戻るような）選択検索により、想定するVclcikデータへの容易なアクセスを可能にする。

図６１は、この発明の一実施の形態に係る検索テーブルの構成例（その４）を説明する図である。図６１の例は、図６０の階層構造を深くした場合である。この例では、「人の名前」→「役名」→「シーン」の順に選択することで対象Vclickデータへ容易に到達することができるようになる。

図６２は、この発明の一実施の形態に係る検索テーブルの構成例（その５）を説明する図である。この例においては、「人」→「アイテム」→「シーン」における「シーン」と、「アイテム」→「人」→「シーン」における「シーン」の内容が同じであるような場合が考えられる。そこで、図６２の例では、同じデータの再利用を可能にするために各要素を別に（別ファイルとして）設け、同じデータ（図６２の例では、誰かがコップというアイテムを持つ「シーン」のデータ）を適宜反復参照することで再利用可能にしている。

図６３は、この発明の一実施の形態に係る検索テーブルを用いる場合において、異なる場面で同じデータを使い回す場合の例を説明する図である。この例では、人の検索データＩ＊とアイテムの検索データＩが、「人→アイテム→シーン」という検索手順と「アイテム→人→シーン」という検索手順において、共用（使い回し）できることが図解されている。

図６４は、この発明の一実施の形態に係る検索方法（選択検索）を説明する図である。この図は、選択検索を行なったときの手順を例示している。すなわち、(a)ユーザ動作により検索が開始される→(b)選択検索か一致検索かを選ぶ→(c)選択検索を選んだ場合、次の選択肢「人」「アイテム」「シーン」が表示される→(d)「人」を選ぶと次の選択し「Aさん」「Bさん」…が表示される→(e)Aさんを選択すると、(f)次の選択肢「服」「靴」「コップ」などが表示される。

ここで、検索手順の階層構造の途中で検索操作を終了を選択すれば、そこまでにヒットしている検索結果を全て表示させることもできる。また、「戻る」で１段階づつ前の選択肢へ戻ることもできる。また、画面左上の“一致”を選択することで、現在ヒットしている選択肢に絞り込まれた中で一致検索を行なうこともできる。なお、図示中カッコ内に表示される数字（例えば図６４（ｅ）の“Ａさん（３０）”の「３０」）は現在ヒットしている検索結果の数を例示している。

図６５は、この発明の一実施の形態に係る検索方法（一致検索）を説明する図である。この図は、キーワードの一致検索を行なった場合の手順を例示している。すなわち、(a)ユーザ動作により検索が開始される→(b)選択検索か一致検索かを選ぶ→(c)一致検索を選んだ場合、キーワード入力フィールドが表示される→(d)検索キーワードとして例えば「Aさん、服」と入力した結果、一致した検索結果が表示される。ここ(d)で、続けるを選択することでさらにキーワードの入力を続けることもできる。あるいは、(d)で選択を選ぶことで、現在ヒットしている検索結果の中での選択検索を行なうこともできる。なお、(d)の図示において、検索結果の後にある（30）は現在ヒットしている検索結果の数を例示している。

次にサーバ装置・クライアント装置間のプロトコルについて説明する。Vclickデータをサーバ装置２０１からクライアント装置２００に送信するときに使用するプロトコルとしては、例えばＲＴＰ（Real-time Transport Protocol）がある。ＲＴＰはＵＤＰ／ＩＰとの相性が良く、リアルタイム性を重視しているためにパケットが欠落する可能性がある。ＲＴＰを用いると、VclickストリームＶＣＳは送信用パケット（ＲＴＰパケット）に分割されて送信される。ここではVclickストリームＶＣＳの送信用パケットへの格納方法例を説明する。

図７と図８はそれぞれVclick_AUのデータサイズが小さい場合と大きい場合の送信用パケット構成方法を説明する図である。図７の７００はVclickストリームＶＣＳである。送信用パケットはパケットヘッダー７０１とペイロードからなる。パケットヘッダー７０１にはパケットのシリアル番号、送信時刻、発信元の特定情報などが含まれている。ペイロードは送信データを格納するデータ領域である。ペイロードにVclick_AU７００から順に取り出したVclick_AU（７０２）を納めていく。ペイロードに次のVclick_AUが入りきらない場合には残りの部分にパディングデータ７０３を挿入する。パディングデータはデータのサイズを合わせるためのダミーデータであり、例えば０値の連続である。ペイロードのサイズを１つまたは複数のVclick_AUサイズと等しくできる場合にはパディングデータは不要である。

一方、図８はペイロードに１つのVclick_AUが収まりきらない場合の送信用パケットの構成方法である。Vclick_AU（８００）はまず１番目の送信用パケットのペイロードに入りきる部分（８０２）のみペイロードに格納される。残りのデータ（８０４）は第２の送信用パケットのペイロードに格納され、ペイロードの格納サイズに余りが生じていればパディングデータ８０５で埋める。一つのVclick_AUを３つ以上のパケットに分割する場合の方法も同様である。

ＲＴＰ以外のプロトコルとしては、ＨＴＴＰ（Hypertext Transport Protocol）またはＨＴＴＰＳを用いることができる。ＨＴＴＰはＴＣＰ／ＩＰとの相性が良く、この場合欠落したデータは再送されるため信頼性の高いデータ通信が行えるが、ネットワークのスループットが低い場合にはデータの遅延が生じるおそれがある。ＨＴＴＰではデータの欠落がないため、VclickストリームＶＣＳをどのようにパケットに分割して格納するかを特に考慮する必要はない。

（再生手順（ネットワーク））
次に、VclickストリームＶＣＳがサーバ装置２０１上にある場合における再生処理の手順について説明する。

図３７はユーザが再生開始を指示してから再生が開始されるまでの再生開始処理手順を表す流れ図である。まずステップＳ３７００でユーザにより再生開始の指示が入力される。この入力は、インタフェース・ハンドラ２０７が受け取り、動画像再生コントローラ２０５に動画像再生準備の命令を出す。次に、分岐処理ステップＳ３７０１として、すでにサーバ装置２０１とのセッションが構築されているかどうかの判定を行う。セッションがまだ構築されていなければステップＳ３７０２に、すでに構築されていればステップＳ３７０３に処理を移す。ステップＳ３７０２ではサーバとクライアント間のセッションを構築する処理を行う。

図９はサーバ・クライアント間の通信プロトコルとしてＲＴＰ用いた場合の、セッション構築からセッション切断までの通信手順例である。セッションの始めにサーバ・クライアント間でネゴシエーションを行う必要があるが、ＲＴＰの場合にはＲＴＳＰ（Real Time Streaming Protocol）が用いられることが多い。ただし、ＲＴＳＰの通信には高信頼性が要求されるため、ＲＴＳＰはＴＣＰ／ＩＰで、ＲＴＰはＵＤＰ／ＩＰで通信を行うのが好ましい。まず、セッションを構築するために、クライアント装置（図２の例では２００）はストリーミングされるVclickデータに関する情報提供をサーバ装置（図２の例では２０１）に要求する（ＲＴＳＰのDESCRIBEメソッド）。

ここで、再生される動画像に対応したデータを配信するサーバ（２０１）のアドレスは、例えば動画像データ記録媒体にアドレス情報を記録しておくなどの方法であらかじめクライアント（２００）に知らされているものとする。サーバ装置２０１はこの応答としてVclickデータの情報をクライアント装置２００に送る。具体的には、セッションのプロトコルバージョン、セッション所有者、セッション名、接続情報、セッションの時間情報、メタデータ名、メタデータ属性といった情報がクライアント装置に送られる。これらの情報記述方法としては、例えばＳＤＰ（Session Description Protocol）を使用する。次にクライアント装置２００はサーバ装置２０１にセッションの構築を要求する（ＲＴＳＰのSETUPメソッド）。サーバ装置２０１はストリーミングの準備を整え、セッションＩＤをクライアント装置２００に返す。ここまでの処理がＲＴＰを用いる場合のステップＳ３７０２の処理である。

ＲＴＰではなくＨＴＴＰが使われている場合の通信手順は、例えば図１０のように行う。まず、ＨＴＴＰより下位の階層であるＴＣＰでのセッション構築（3 way handshake）を行う。ここで、先ほどと同様に、再生される動画像に対応したデータを配信するサーバ（２０１）のアドレスはあらかじめクライアント（２００）に知らされているものとする。この後、クライアント装置２００の状態（例えば、製造国、言語、各種パラメータの選択状態など）をＳＤＰ等を用いてサーバ装置２０１に送る処理が行われるようにしてもよい。ここまでがＨＴＴＰの場合のステップＳ３７０２の処理となる。

ステップＳ３７０３では、サーバ装置２０１とクライアント装置２００間のセッションが構築された状態で、サーバ（２０１）にVclickデータ送信を要求する処理を行う。これはインタフェース・ハンドラ２０７がネットワーク・マネージャ２０８に指示を出し、ネットワーク・マネージャ２０８がサーバ（２０１）に要求を出すことにより行われる。ＲＴＰの場合には、ネットワーク・マネージャ２０８はＲＴＳＰのPLAYメソッドをサーバに送ることでVclickデータ送信を要求する。サーバ装置は、これまでにクライアントから受け取った情報とサーバ装置内にあるVclickインフォＶＣＩを参照して送信すべきVclickストリームＶＣＳを特定する。さらに、Vclickデータ送信要求に含まれる再生開始位置のタイムスタンプ情報とサーバ装置内にあるVclickアクセス・テーブルＶＣＡを用いてVclickストリームＶＣＳ中の送信開始位置を特定し、VclickストリームＶＣＳをパケット化してＲＴＰによりクライアント装置に送る。

一方ＨＴＴＰの場合には、ネットワーク・マネージャ２０８はＨＴＴＰのGETメソッドを送信することによりVclickデータ送信を要求する。この要求には、動画像の再生開始位置のタイムスタンプの情報を含めても良い。サーバ装置は、ＲＴＰの時と同様の方法により送信すべきVclickストリームＶＣＳと、このストリーム中の送信開始位置を特定し、VclickストリームＶＣＳをＨＴＴＰによりクライアント装置に送る。

次に、ステップＳ３７０４では、サーバから送られてくるVclickストリームＶＣＳをバッファ２０９にバッファリングする処理を行う。これは、VclickストリームＶＣＳの再生中にサーバからのVclickストリーム送信が間に合わず、バッファ２０９が空になってしまうことをさけるために行われる。メタデータ・マネージャ２１０からバッファに十分なVclickストリームＶＣＳが蓄積されたことがインタフェース・ハンドラに通知されると、ステップＳ３７０５の処理に移る。ステップＳ３７０５では、インタフェース・ハンドラがコントローラ２０５に動画像の再生開始命令を出し、さらにメタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出を開始するよう命令を出す。

図３８は図３７とは別の再生開始処理の手順を説明する流れ図である。図３７の流れ図で説明される処理では、ネットワークの状態やサーバ、クライアント装置の処理能力により、ステップＳ３７０４でのVclickストリームＶＣＳを一定量バッファリングする処理に時間がかかる場合がある。すなわち、ユーザが再生を指示してから実際に再生が始まるまでに時間がかかってしまうことがある。図３８の処理手順では、ステップＳ３８００でユーザが再生開始を指示すると、次のステップＳ３８０１で直ちに動画像の再生が開始される。すなわち、ユーザからの再生開始指示を受けたインタフェース・ハンドラ２０７は、直ちにコントローラ２０５に再生開始命令を出す。これにより、ユーザは再生を指示してから動画像を視聴するまで待たされることがなくなる。次の処理ステップＳ３８０２からステップＳ３８０５までは、図３７のステップＳ３７０１からステップＳ３７０４と同一の処理である。

ステップＳ３８０６では、再生中の動画像に同期させてVclickストリームＶＣＳを復号する処理を行う。すなわち、インタフェース・ハンドラ２０７は、メタデータ・マネージャ２１０からバッファ２０９に一定量のVclickストリームＶＣＳが蓄積された通知を受け取ると、メタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出開始を命令する。メタデータ・マネージャ２１０はインタフェース・ハンドラから再生中の動画像のタイムスタンプを受け取り、バッファに蓄積されたデータからこのタイムスタンプに該当するVclick_AUを特定し、メタデータ・デコーダ２１７へ送出する。

図３８の処理手順では、ユーザは再生を指示してから動画像を視聴するまで待たされることがないが、再生開始直後はVclickストリームＶＣＳの復号が行われないため、オブジェクトに関する表示が行われなかったり、オブジェクトをクリックしても何も動作が起こらないなどの問題点がある。

上記の問題は、動画像再生開始後VclickストリームＶＣＳの復号が開始されたあとは解消する。従い、再生開始後一定量のＶＣＳ（Vclick_AU）の復号が済むまでの期間を、ユーザが苛立たない程度に短縮すればこの問題は実用上解決できる。そこで、クライアント装置２００とサーバ装置２０１を高速回線を介して常時接続状態としておき、ディスク装置２３１にVclickを利用するＤＶＤディスクが装填されたとき（あるいは装填されたディスクから再生するタイトルが選択されたあと）、ステップＳ３８０２〜Ｓ３８０３の処理を予めバックグラウンドで実行しておくことが考えられる。この場合、ステップＳ３８００のユーザ指示があると、直ぐにステップＳ３８０１のＤＶＤ再生が開始されると同時に、ステップＳ３８０２〜Ｓ３８０３の処理を飛ばして、高速回線を介してサーバから直ぐにVclickストリームＶＣＳのバッファ取り込み（ステップＳ３８０４〜Ｓ３８０５）が始まる。この取り込み量が一定量（例えば１２ｋバイト）に達したら、直ちにVclickストリームＶＣＳ（その中の最初のVclick_AU）の復号が始まる（ステップＳ３８０６）。

動画像の再生中、クライアント装置２００のネットワーク・マネージャ２０８はサーバ装置２０１から次々に送られてくるVclickストリームＶＣＳを受信し、バッファ２０９に蓄積する。蓄積されたオブジェクト・メタデータは適切なタイミングでメタデータ・デコーダ２１７に送られる。すなわち、メタデータ・マネージャ２０８は、メタデータ・マネージャ２１０から送られてくる再生中の動画像のタイムスタンプを参照し、バッファ２０９に蓄積されているデータからそのタイムスタンプに対応したVclick_AUを特定し、この特定されたオブジェクト・メタデータをＡＵ単位でメタデータ・デコーダ２１７に送る。メタデータ・デコーダ２１７は受け取ったデータを復号する。ただし、クライアント装置２００が現在選択しているカメラアングルと異なるカメラアングル用のデータの復号は行わないようにしても良い。また、再生中の動画像のタイムスタンプに対応したVclick_AUがすでにメタデータ・デコーダ２１７にあることがわかっている場合には、オブジェクト・メタデータをメタデータ・デコーダ２１７に送らないようにしても良い。

再生中の動画像のタイムスタンプは逐次インタフェース・ハンドラ２０７からメタデータ・デコーダ２１７に送られている。メタデータ・デコーダ２１７ではこのタイムスタンプに同期させてVclick_AUを復号し、必要なデータをＡＶレンダラー２１８に送る。例えば、Vclick_AUに記述された属性情報によりオブジェクト領域の表示が指示されている場合には、オブジェクト領域のマスク画像や輪郭線などを生成し、再生中の動画像のタイムスタンプに合わせてＡ／Ｖレンダラー２１８に送る。また、メタデータ・デコーダ２１７は再生中の動画像のタイムスタンプとVclick_AUの有効時刻とを比較し、不要になった古いオブジェクト・メタデータを判定してそのデータを削除する。

図３９は再生停止処理の手順を説明する流れ図である。ステップＳ３９００では、ユーザにより動画像の再生中に再生停止が指示される。次にステップＳ３９０１で動画像再生を停止する処理が行われる。これはインタフェース・ハンドラ２０７がコントローラ２０５に停止命令を出すことにより行われる。また、同時にインタフェース・ハンドラはメタデータ・マネージャ２１０にオブジェト・メタデータのメタデータ・デコーダ２１７への送出停止を命令する。

ステップＳ３９０２はサーバ（２０１）とのセッションを切断する処理である。ＲＴＰを用いている場合には、図９に示すようにＲＴＳＰのTEARDOWNメソッドをサーバに送る。TEARDOWNのメッセージを受け取ったサーバ装置２０１はデータ送信を中止してセッションを終了し、クライアント装置２００に確認メッセージを送る。この処理により、セッションに使用していたセッションＩＤが無効となる。一方、ＨＴＴＰを用いている場合には、図１０に示されているようにＨＴＴＰのCloseメソッドをサーバ（２０１）に送り、セッションを終了させる。

（ランダムアクセス手順（ネットワーク））
次に、VclickストリームＶＣＳがサーバ装置２０１上にある場合におけるランダムアクセス再生の手順について説明する。

図４０はユーザがランダムアクセス再生の開始を指示してから再生が開始されるまでの処理手順を表す流れ図である。まずステップＳ４０００でユーザによりランダムアクセス再生の開始指示が入力される。入力の方法としては、チャプター等のアクセス可能位置のリストからユーザが選択する方法、動画像のタイムスタンプに対応づけられたスライドバー上からユーザが一点を指定する方法、直接動画像のタイムスタンプを入力する方法などがある。入力されたタイムスタンプは、インタフェース・ハンドラ２０７が受け取り、動画再生コントローラ２０５に動画像再生準備の命令を出す。もしもすでに動画像を再生中である場合には、再生中の動画像の再生停止を指示してから動画像再生準備の命令を出す。次に、分岐処理ステップＳ４００１として、すでにサーバ装置２０１とのセッションが構築されているかどうかの判定を行う。動画像を再生中である場合など、すでにセッションが構築されている場合にはステップＳ４００２のセッション切断処理を行う。セッションがまだ構築されていればステップＳ４００２の処理を行わずにステップＳ４００３に処理を移す。ステップＳ４００３ではサーバ（２０１）とクライアント（２００）間のセッションを構築する処理を行う。この処理は図３７のステップＳ３７０２と同一の処理である。

次にステップＳ４００４では、サーバ装置２０１とクライアント装置２００間のセッションが構築された状態で、サーバ（２０１）に再生開始位置のタイムスタンプを指定してVclickデータ送信を要求する処理を行う。これはインタフェース・ハンドラ２０７がネットワーク・マネージャ２０８に指示を出し、ネットワーク・マネージャ２０８がサーバ（２０１）に要求を出すことにより行われる。ＲＴＰの場合には、ネットワーク・マネージャ２０８はＲＴＳＰのPLAYメソッドをサーバに送ることでVclickデータ送信を要求する。このとき、Range記述を用いるなどの方法で再生開始位置を特定するタイムスタンプもサーバ（２０１）に送る。サーバ装置２０１は、これまでにクライアント（２００）から受け取った情報とサーバ装置２０１内にあるVclickインフォＶＣＩを参照して送信すべきオブジェクト・メタデータ・ストリームを特定する。さらに、サーバ装置２０１は、Vclickデータ送信要求に含まれる再生開始位置のタイムスタンプ情報とサーバ装置２０１内にあるVclickアクセス・テーブルＶＣＡを用いてVclickストリームＶＣＳ中の送信開始位置を特定し、VclickストリームＶＣＳをパケット化してＲＴＰによりクライアント装置２００に送る。

一方、ＨＴＴＰの場合には、ネットワーク・マネージャ２０８はＨＴＴＰのGETメソッドを送信することによりVclickデータ送信を要求する。この要求には、動画像の再生開始位置のタイムスタンプの情報が含まれている。サーバ装置２０１は、ＲＴＰの時と同様に、Vclick情報ファイルＶＣＩを参照して送信すべきVclickストリームＶＣＳを特定し、さらにタイムスタンプ情報とサーバ装置２０１内にあるVclickアクセス・テーブルＶＣＡを用いてVclickストリームＶＣＳ中の送信開始位置を特定し、VclickストリームＶＣＳをＨＴＴＰによりクライアント装置２００に送る。

次に、ステップＳ４００５では、サーバ（２０１）から送られてくるVclickストリームＶＣＳをバッファ２０９にバッファリングする処理を行う。これは、VclickストリームＶＣＳの再生中にサーバ（２０１）からのVclickストリーム送信が間に合わず、バッファ２０９が空になってしまうことをさけるために行われる。メタデータ・マネージャ２１０からバッファ２０９に十分なVclickストリームＶＣＳが蓄積されたことがインタフェース・ハンドラに通知されると、ステップＳ４００６の処理に移る。ステップＳ４００６では、インタフェース・ハンドラ２０７が、コントローラ２０５に動画像の再生開始命令を出し、さらにメタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出を開始するよう命令を出す。

図４１は図４０とは別のランダムアクセス再生開始処理の手順を説明する流れ図である。図４０の流れ図で説明される処理では、ネットワークの状態やサーバ／クライアント装置（２０１／２００）の処理能力により、ステップＳ４００５でのVclickストリームＶＣＳを一定量バッファリングする処理に時間がかかる場合がある。すなわち、ユーザが再生を指示してから実際にステップＳ４００６での再生が始まるまでにユーザを苛立たせるほど時間がかかってしまうことがある。

これに対し、図４１の処理手順では、ステップＳ４１００でユーザが再生開始を指示すると、次のステップＳ４１０１で直ちに動画像の再生が開始される。すなわち、ユーザからの再生開始指示を受けたインタフェース・ハンドラ２０７は、直ちにコントローラ２０５にランダムアクセス再生開始命令を出す。これにより、ユーザは再生を指示してから動画像を視聴するまで待たされることがなくなる。以後の処理ステップＳ４１０２からステップＳ４１０６までは、図４０のステップＳ４００１からステップＳ４００５と同一の処理である。

ステップＳ４１０７では、再生中の動画像に同期させてVclickストリームＶＣＳを復号する処理を行う。すなわち、インタフェース・ハンドラ２０７は、メタデータ・マネージャ２１０からバッファ２０９に一定量のVclickストリームＶＣＳが蓄積された通知を受け取ると、メタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出開始を命令する。メタデータ・マネージャ２１０は、インタフェース・ハンドラ２０７から再生中の動画像のタイムスタンプを受け取り、バッファ２０９に蓄積されたデータからこのタイムスタンプに該当するVclick_AUを特定し、特定したＡＵをメタデータ・デコーダ２１７へ送出する。

図４１の処理手順では、ユーザは再生を指示してから動画像を視聴するまで待たされることがないが、再生開始直後はVclickストリームＶＣＳの復号が行われないため、オブジェクトに関する表示が行われなかったり、オブジェクトをクリックしても何も動作が起こらないなどの問題点がある。

上記の問題は、動画像再生開始後VclickストリームＶＣＳの復号が始まったあとは解消するのであるから、再生開始後ＶＣＳの復号が始まるまでの期間を、ユーザが苛立たない程度に短縮すればこの問題は実用上解決できる。そこで、クライアント装置２００とサーバ装置２０１を高速回線を介して常時接続状態としておき、ディスク装置２３１にVclickを利用するＤＶＤディスクが装填されたとき（あるいは装填されたディスクから再生するタイトルが選択されたあと）、ステップＳ４１０２〜Ｓ４１０４の処理を予めバックグラウンドで実行しておくことが考えられる。この場合、ステップＳ４１００のユーザ指示があると、直ぐにステップＳ４１０１のＤＶＤ再生が開始されると同時に、ステップＳ４１０２〜Ｓ４１０４の処理を飛ばして、高速回線を介してサーバから直ぐにVclickストリームＶＣＳのバッファ取り込みが始まる（ステップＳ４１０６）。この取り込み量が一定量（例えば１２ｋバイト）に達したら、直ちにVclickストリームＶＣＳ（その中の最初のVclick_AU）の復号が始まる（ステップＳ４１０７）。なお、その後の動画像の再生中の処理と動画像停止処理は、通常のＤＶＤ再生処理の場合と同一であるため、説明は省略する。

（再生手順（ローカル））
次に、VclickストリームＶＣＳが動画像データ記録媒体２３１上にある場合における再生処理の手順について説明する。

図４２はユーザが再生開始を指示してから再生が開始されるまでの再生開始処理手順を表す流れ図である。まずステップＳ４２００でユーザにより再生開始の指示が入力される。この入力は、インタフェース・ハンドラ２０７が受け取り、動画再生コントローラ２０５に動画像再生準備の命令を出す。次に、ステップＳ４２０１では、使用するVclickストリームＶＣＳを特定する処理が行われる。この処理では、インタフェース・ハンドラは動画像データ記録媒体２３１上にあるVclick情報ファイルＶＣＩを参照し、ユーザが再生を指定した動画像に対応するVclickストリームＶＣＳを特定する。

ステップＳ４２０２では、バッファにVclickストリームＶＣＳを格納する処理が行われる。この処理を行うため、インタフェース・ハンドラ２０７はまずメタデータ・マネージャ２１０にバッファを確保する命令を出す。確保すべきバッファのサイズは、特定されたVclickストリームＶＣＳを格納するのに十分なサイズとして決められるが、通常はこのサイズを記述したバッファ初期化用文書が動画像データ記録媒体２３１に記録されている。初期化用文書がない場合には、あらかじめ決められているサイズを適用する。バッファの確保が完了すると、インタフェース・ハンドラ２０７はコントローラ２０５に特定されたVclickストリームＶＣＳを読み出してバッファに格納する命令を出す。

VclickストリームＶＣＳがバッファ２０９に格納されると、次にステップＳ４２０３の再生開始処理が行われる。この処理では、インタフェース・ハンドラ２０７が動画再生コントローラ２０５に動画像の再生命令を出し、同時にメタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出を開始するよう命令を出す。

動画像の再生中、動画像データ記録媒体２３１から読み出されたVclick_AUはバッファ２０９に蓄積される。蓄積されたVclickストリームＶＣＳは適切なタイミングでメタデータ・デコーダ２１７に送られる。すなわち、メタデータ・マネージャ２０８は、メタデータ・マネージャ２１０から送られてくる再生中の動画像のタイムスタンプを参照し、バッファ２０９に蓄積されているデータからそのタイムスタンプに対応したVclick_AUを特定し、この特定されたVclick_AUをメタデータ・デコーダ２１７に送る。メタデータ・デコーダ２１７は受け取ったデータを復号する。ただし、クライアント装置が現在選択しているカメラアングルと異なるカメラアングル用のデータの復号は行わないようにしても良い。また、再生中の動画像のタイムスタンプに対応したVclick_AUがすでにメタデータ・デコーダ２１７にあることがわかっている場合には、VclickストリームＶＣＳをメタデータ・デコーダ２１７に送らないようにしても良い。

再生中の動画像のタイムスタンプは逐次インタフェース・ハンドラからメタデータ・デコーダ２１７に送られている。メタデータ・デコーダ２１７ではこのタイムスタンプに同期させてVclick_AUを復号し、必要なデータをＡＶレンダラー２１８に送る。例えば、オブジェクト・メタデータのＡＵに記述された属性情報によりオブジェクト領域の表示が指示されている場合には、オブジェクト領域のマスク画像や輪郭線などを生成し、再生中の動画像のタイムスタンプに合わせてＡ／Ｖレンダラー２１８に送る。また、メタデータ・デコーダ２１７は再生中の動画像のタイムスタンプとVclick_AUの有効時刻とを比較し、不要になった古いVclick_AUを判定してそのデータを削除する。

ユーザにより動画像の再生中に再生停止が指示されると、インタフェース・ハンドラ２０７はコントローラ２０５に動画像再生の停止命令と、VclickストリームＶＣＳの読み出しの停止命令を出す。この指示により、動画像の再生が終了する。

（ランダムアクセス手順（ローカル））
次に、VclickストリームＶＣＳが動画像データ記録媒体２３１上にある場合におけるランダムアクセス再生の処理手順について説明する。

図４３はユーザがランダムアクセス再生の開始を指示してから再生が開始されるまでの処理手順を表す流れ図である。まずステップＳ４３００でユーザによりランダムアクセス再生開始の指示が入力される。入力の方法としては、チャプター等のアクセス可能位置のリストからユーザが選択する方法、動画像のタイムスタンプに対応づけられたスライドバー上からユーザが一点を指定する方法、直接動画像のタイムスタンプを入力する方法などがある。入力されたタイムスタンプは、インタフェース・ハンドラ２０７が受け取り、動画再生コントローラ２０５に動画像のランダムアクセス再生準備の命令を出す。

次に、ステップＳ４３０１では、使用するVclickストリームＶＣＳを特定する処理が行われる。この処理では、インタフェース・ハンドラは動画像データ記録媒体２３１上にあるVclick情報ファイルＶＣＩを参照し、ユーザが再生を指定した動画像に対応するVclickストリームＶＣＳを特定する。さらに、動画像データ記録媒体２３１上にあるVclickアクセス・テーブルＶＣＡ、もしくはメモリ（バッファ２０９もしくはその他のワークメモリエリア）上に読み込んであるVclickアクセス・テーブルＶＣＡを参照し、動画像のランダムアクセス先に対応するVclickストリームＶＣＳ中のアクセスポイントを特定する。

ステップＳ４３０２は分岐処理であり、特定されたVclickストリームＶＣＳが現在バッファ２０９に読み込まれているかどうかを判定する。バッファに読み込まれていない場合にはステップＳ４３０３の処理を行ってからステップＳ４３０４の処理に移る。現在バッファに読み込まれている場合には、ステップＳ４３０３の処理は行わずにステップＳ４３０４の処理に移る。ステップＳ４３０４は動画像のランダムアクセス再生開始、及びVclickストリームＶＣＳの復号開始である。この処理では、インタフェース・ハンドラ２０７が動画再生コントローラ２０５に動画像のランダムアクセス再生命令を出し、同時にメタデータ・マネージャ２１０にVclickストリームＶＣＳのメタデータ・デコーダ２１７への送出を開始するよう命令を出す。その後は動画像の再生に同期させてVclickストリームＶＣＳの復号処理が行われる。その後の動画像再生中および動画像再生停止処理については、通常の再生処理と同一であるため、説明は省略する。

（クリックから関連情報表示までの手順）
次に、ユーザがマウス等のポインティングデバイスを使ってオブジェクト領域内をクリックした場合のクライアント装置の動作について説明する。ユーザがクリックを行うと、まず動画像上のクリックされた座標位置がインタフェース・ハンドラ２０７に入力される。インタフェース・ハンドラ２０７はメタデータ・デコーダ２１７にクリック時の動画像のタイムスタンプと座標を送る。メタデータ・デコーダ２１７は、タイムスタンプと座標から、ユーザによって指示されたオブジェクトがどれであるかを特定する処理を行う。メタデータ・デコーダ２１７では、動画像の再生に同期させてVclickストリームＶＣＳをデコードしており、従ってクリックされた時のタイムスタンプにおけるオブジェクトの領域が生成されているため、この処理は容易に実行できる。クリックされた座標に複数のオブジェクト領域が存在する場合には、Vclick_AU内に含まれる階層情報を参照して最も前面にあるオブジェクトを特定する。

ユーザによって指定されたオブジェクトが特定されると、メタデータ・デコーダ２１７はそのオブジェクト属性情報４０３に記述されたアクション記述（動作を指示するスクリプト）をスクリプト・インタプリタ２１２に送る。アクション記述を受け取ったスクリプト・インタプリタ２１２は、その動作内容を解釈し、実行する。例えば、指定されたＨＴＭＬファイルの表示を行ったり、指定された動画像の再生を開始したりする。これらＨＴＭＬファイルや動画像データは、クライアント装置２００に記録されている場合、サーバ装置２０１からネットワーク経由で送られてくる場合、ネットワーク上の別のサーバ上に存在している場合の、いずれでも良い。

（データ構造の詳細）
次に、より具体的なデータ構造の構成例について説明する。図１１はVclickストリームＶＣＳ（図５では５０６）のデータ構造の例である。各データ要素の意味は以下の通りである：
vcs_start_codeは、VclickストリームＶＣＳの始まりを示す；
data_lengthは、このVclickストリームＶＣＳにおけるdata_lengthより後の部分のデータ長をバイトで指定する；
data_bytesはVclick_AUのデータ部である。この部分には先頭にVclickストリーム５０６のヘッダ５０７（図５）があり、続いて１つまたは複数のVclick_AU（図４）やNULL_AU（図４８）が並ぶ。

図１２はVclickストリーム（図５の例でいえばストリーム５０６のヘッダ５０７）のデータ構造の例である。各データ要素の意味は以下の通りである：
vcs_header_codeは、VclickストリームＶＣＳ（５０６）のヘッダ（５０７）の始まりを示す；
data_lengthは、VclickストリームＶＣＳのヘッダのうち、data_lengthより後の部部のデータ長をバイト単位で表す；
vclick_versionは、フォーマットのバージョンを指定する。この値はこの仕様の中では例えば01hとする；
bit_rateは、このVclickストリームＶＣＳの最大のビット・レートを指定する。

図１３はVclick_AU（図５の例でいえば５００〜５０５の各長方形部分）のデータ構造の例である。各データ要素の意味は以下の通りである：
vclick_start_codeは、各Vclick_AUの始まりを示す；
data_lengthは、このVclick_AUのdata_lengthより後の部分のデータ長をバイトで指定する；
data_byteはVclick_AUのデータ部である。この部分にヘッダ４０１、タイムスタンプ４０２、オブジェクト属性情報４０３、オブジェクト領域情報４００が含まれる。

図１４はVclick_AUのヘッダ４０１（図４）のデータ構造の例である。各データ要素の意味は以下の通りである：
vclick_header_codeは、各Vclick_AUのヘッダの始まりを示す；
data_lengthは、このVclick_AUのヘッダにおけるdata_lengthより後の部分のデータ長をバイトで指定される；
filtering_idはVclick_AUの識別ＩＤである。クライアント装置の属性とこのＩＤにより、復号すべきVclick_AUかどうかを判定するためのデータである；
object_idはVclickデータで記述されるオブジェクトの識別番号である。object_idの同じ値が2つのVclick_AUの中で使用される場合、両者は意味的に同一のオブジェクト用のデータである；
object_subidはオブジェクトの意味的な連続性を表す。２つのVclick_AUにおいてobject_idおよびobject_subidの両方が同じである場合、両者は連続的なオブジェクトを意味する；
continue_flagはフラグである。このフラグが"1"である場合、このVclick_AUに記述されたオブジェクト領域と、同一のobject_idを有する次のVclick_AUに記述されたオブジェクト領域とは連続していることを示す。そうでない場合にはこのフラグは"0"となる；
layerは、オブジェクトの階層値を表す。階層値が大きいほどオブジェクトが画面上で手前にあることを意味する。なお、上述したように、filtering_idにより「復号すべきVclick_AUかどうかを判定」できることから、filtering_idにより、「復号すべきVclick_AUを含むVclickストリームＶＣＳ」も識別できることになる。すなわち、filtering_idにより、「動画像メタデータのストリーム選択を行う」ことができる。

図１５はVclick_AUのタイムスタンプ（図４の４０２）のデータ構造の例である。この例では、動画像データ記録媒体としてＤＶＤを用いる場合を仮定している。以下のタイムスタンプを用いることにより、ＤＶＤ上の動画像の任意の時刻を指定することが可能となり、動画像とVclickデータの同期が実現できる。各データ要素の意味は以下の通りである：
time_typeは、ＤＶＤ用タイムスタンプの始まりを示す；
data_lengthは、このタイムスタンプのうちdata_lengthより後の部分のデータ長をバイトで指定する；
VTSNは、ＤＶＤビデオのVTS（ビデオタイトルセット）番号を示す。

TTNは、ＤＶＤビデオのタイトル・ドメインにおけるタイトル番号を示すもので、ＤＶＤプレーヤのシステムパラメータSPRM(4)にストアされる値に相当する；
VTS_TTNは、ＤＶＤビデオのタイトル・ドメインにおけるVTSタイトル番号を示すもので、ＤＶＤプレーヤのシステムパラメータSPRM(5)にストアされる値に相当する；
TT_PGCNは、ＤＶＤビデオのタイトル・ドメインにおけるタイトルＰＧＣ（プログラムチェーン）番号を示すもので、ＤＶＤプレーヤのシステムパラメータSPRM(6)にストアされる値に相当する；
PTTNは、ＤＶＤビデオの部分タイト（Part_of_Title）番号を示すもので、ＤＶＤプレーヤのシステムパラメータSPRM(7)にストアされる値に相当する。

CNは、ＤＶＤビデオのセル番号を示す；
AGLNは、ＤＶＤビデオのアングル番号を示す；
PTS[s .. e]は、ＤＶＤビデオの表示タイムスタンプのうち、sビット目からeビット目までのデータを示す。

図１６はVclick_AUのタイムスタンプ・スキップのデータ構造の例である。タイムスタンプ・スキップがタイムスタンプの代わりにVclick_AUに記述されている場合、このVclick_AUのタイムスタンプが直前のVclick_AUのタイムスタンプと同一である事を意味している。各データ要素の意味は以下の通りである：
time_typeは、タイムスタンプ・スキップの始まりを示す；
data_lengthは、このタイムスタンプ・スキップのうちdata_lengthより後の部分のデータ長をバイトで指定する。しかし、タイムスタンプ・スキップはtime_typeとdata_lengthのみから構成されるため、この値は常に0となる。

図１７はVclick_AUのオブジェクト属性情報４０３（図４）のデータ構造の例である。各データ要素の意味は以下の通りである：
vca_start_codeは、各Vclick_AUのオブジェクト属性情報の始まりを示す；
data_lengthは、このオブジェクト属性情報のうちdata_lengthより後の部分のデータ長をバイトで指定する；
data_bytesはオブジェクト属性情報のデータ部である。この部分には１つまたは複数の属性が記述される。

次に、オブジェクト属性情報４０３の中に記述される属性情報の詳細について説明する。図１８はオブジェクト属性情報４０３の中で記述可能な属性の種類の一覧である。最大値の欄には、それぞれの属性について、一つのオブジェクト・メタデータＡＵ内に記述可能な最大のデータ数の例を示してある。

attribute_idは、各属性データ中に含まれるＩＤで、属性の種類を見分けるためのデータである。名前属性は、オブジェクトの名前を特定するための情報である。アクション属性は、動画像中のオブジェクト領域がクリックされたときに、どのようなアクションを行うべきかが記述される。輪郭線属性は、オブジェクトの輪郭線をどのように表示させるかの属性を表す。点滅領域属性は、オブジェクト領域を点滅して表示する際の点滅色を特定する。モザイク領域属性は、オブジェクト領域をモザイク化して表示する際のモザイク化の仕方が記述されている。塗りつぶし領域属性は、オブジェクト領域に色を付けて表示させる際の色を特定する。

テキストカテゴリーに属する属性は、動画像に文字を表示させたいときに、表示させる文字に関する属性を定義する。テキスト情報には、表示させるテキストを記述する。テキスト属性は、表示させるテキストの色やフォント等の属性を特定する。ハイライト効果属性は、テキストの一部または全てをハイライト表示させる際に、どの文字をどのようにハイライト表示させるかを特定する。点滅効果属性は、テキストの一部または全てを点滅表示させる際に、どの文字をどのように点滅表示させるかを特定する。スクロール効果属性には、表示させるテキストをスクロールさせる際に、どの方向にどのような速さでスクロールさせるかが記述されている。カラオケ効果属性は、テキストの色を順次変更していく際に、どのようなタイミングでどこの文字の色を変更させるかを特定する。

最後に、階層拡張属性は、オブジェクトの階層値がVclick_AU内で変化する場合に、階層値の変化のタイミングとその値を定義するために用いられる。以上の属性のデータ構造について、以下で個々に説明する。

図１９はオブジェクトの名前属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。名前属性については、この値は00hとする；
data_lengthは、名前属性データのdata_lengthより後のデータ長をバイトで表す；
languageは、以下の要素（nameとannotation）の記述に用いた言語を特定する。言語の指定にはISO-639「code for the representation of names of languages」を用いる；
name_lengthは、バイトでname要素のデータ長さを指定する；
nameは文字列であり、このVclick_AUで記述されているオブジェクトの名前を表す；
annotation_lengthは、バイトでannotation要素のデータ長を表す；
annotationは文字列であり、このVclick_AUで記述されているオブジェクトに関する注釈を表す。

図２０はオブジェクトのアクション属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。アクション属性については、この値は01hとする；
data_lengthは、アクション属性データのうちdata_lengthより後の部分のデータ長をバイトで表す；
script_languageは、script要素に記述されているスクリプト言語の種類を特定する；
script_lengthは、バイト単位でscript要素のデータ長を表す；
scriptは文字列であり、このVclick_AUで記述されているオブジェクトがユーザにより指定された場合に実行すべきアクションをscript_languageで指定されたスクリプト言語で記述されている。

図２１はオブジェクトの輪郭線属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性のタイプを指定する。輪郭線属性については、この値は02hとする；
data_lengthは、輪郭線属性データうちdata_lengthより後の部分のデータ長を指定する；
color_r、color_g、color_b、color_aは、このオブジェクト・メタデータＡＵで記述されているオブジェクトの輪郭の表示色を指定する；
color_r、color_gおよびcolor_bはそれぞれ色のRGB表現における赤、緑および青の値を指定する。一方、color_aは透明度を示す；
line_typeは、このVclick_AUで記述されているオブジェクトの輪郭線の種類（実線、破線など）指定する；
thicknessは、このVclick_AUで記述されているオブジェクトの輪郭線の太さをポイントで指定する。

図２２はオブジェクトの点滅領域属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。点滅領域属性データについては、この値は03hとする；
data_lengthは、点滅領域属性データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
color_r、color_g、color_b、color_aは、このVclick_AUで記述されているオブジェクトの領域の表示色を指定する。color_r、color_gおよびcolor_bはそれぞれ色のRGB表現における赤、緑および青の値を指定する。一方、color_aは透明度を示す。オブジェクト領域の点滅は、塗りつぶし領域属性の中で指定された色とこの属性で指定された色とを交互に表示させることにより実現される；
intervalは、点滅の時間間隔を指定する。

図２３はオブジェクトのモザイク領域属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。モザイク領域属性データについては、この値は04hとする；
data_lengthは、モザイク領域属性データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
mosaic_sizeは、モザイク・ブロックのサイズをピクセル単位で指定する；
randomnessはモザイク化したブロックの位置を入れ替える場合に、どの程度ランダムに入れ替えるかを表す。

図２４はオブジェクトの塗りつぶし領域属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。塗りつぶし領域属性データについては、この値は05hとする；
data_lengthは、塗りつぶし属性データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
color_r、color_g、color_b、color_aは、このVclick_AUで記述されているオブジェクト領域の表示色を指定する。color_r、color_gおよびcolor_bはそれぞれ色のRGB表現における赤、緑および青の値を指定する。一方、color_aは透明度を示す。

図２５はオブジェクトのテキスト情報のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト情報については、この値は06hとする；
data_lengthは、オブジェクトのテキスト情報のうちdata_lengthより後の部分のデータ長をバイトで指定する；
languageは、記述されたテキストの言語を示す。言語の指定方法は、例えばISO-639「code for the representation of names of languages」を使うことができる；
char_codeは、テキストのコード種類を特定する。例えば、UTF-8、UTF-16、ASCII、Shift JISなどを指定する；
directionは、文字を並べる際の方向として、左方向、右方向、下方向、上方向を特定する。例えば、英語やフランス語ならば通常文字は左方向に並べる。一方、アラビア語ならば右方向に、日本語ならば左方向か下方向のどちらかに並べる。ただし、言語ごとに決まっている並び方向以外を指定しても良い。また、斜め方向を指定できるようにしても良い；
text_lengthは、バイトでtimed textの長さを指定する；
textは文字列であり、char_codeで指定された文字コードを用いて記述されたテキストである。

図２６はオブジェクトのテキスト属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト属性については、この値は07hとする；
data_lengthは、オブジェクトのテキスト属性のうちdata_lengthより後の部分のデータ長をバイトで指定する；
font_lengthは、フォントの記述長をバイト単位で指定する；
fontは文字列であり、テキストを表示する際に用いるフォントを指定する；
color_r、color_g、color_b、color_aは、テキストを表示する際の表示色を指定する。色はRGBにより表現される。また、color_r、color_gおよびcolor_bは、赤、緑および青の値をそれぞれ指定する。また、color_aは透過度を示す。

図２７はオブジェクトのテキスト・ハイライト効果属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト・ハイライト効果属性データについては、この値は08hとする；
data_lengthは、オブジェクトのテキスト・ハイライト効果属性データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
entryは、このテキスト・ハイライト効果属性データ中のhighlight_effect_entryの数を示す；
data_bytesにentry個のhighlight_effect_endtryが含まれる；
highlight_effect_endtryの仕様は以下に示す通りである。

図２８はオブジェクトのテキスト・ハイライト効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
start_positionは、強調される文字の開始位置を先頭から当該文字までの文字数により指定する；
end_positionは、強調される文字の終了位置を先頭から当該文字までの文字数により指定する；
color_r、color_g、color_b、color_aは、強調後の文字の表示色を指定する。色はRGBにより表現される。また、color_r、color_gおよびcolor_bは、赤、緑および青の値をそれぞれ指定する。また、color_aは透過度を示す。

図２９はオブジェクトのテキスト点滅効果属性のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト点滅効果属性データについては、この値は09hとする；
data_lengthは、テキスト点滅効果属性データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
entryは、このテキスト点滅効果属性データ中のblink_effect_entryの数を示す；
data_bytesにentry個のblink_effect_entryを含む；
blink_effect_entryの仕様は以下の通りである。

図３０はオブジェクトのテキスト点滅効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
start_positionは、点滅させる文字の開始位置を先頭から当該文字までの文字数により指定する；
end_positionは、点滅させる文字の終了位置を先頭から当該文字までの文字数により指定する；
color_r、color_g、color_b、color_aは、点滅文字の表示色を指定する。色はRGBにより表現される。また、color_r、color_gおよびcolor_bは、赤、緑および青の値をそれぞれ指定する。また、color_aは透過度を示す。ここで指定された色と、テキスト属性で指定された色とを交互に表示させることで文字を点滅させる；
intervalは、点滅の時間間隔を指定する。

図３１はオブジェクトのテキスト・スクロール効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト・スクロール効果属性データについては、この値は0ahとする；
data_lengthは、テキスト・スクロール効果属性データのうちdeta_lengthより後の部分のデータ長をバイト単位で指定する；
directionは文字をスクロールする方向を指定する。例えば、0は右から左を、1は左から右を、2は上から下を、3は下から上を示す；
delayは、スクロールの速度を、表示させる先頭の文字が表示されてから最後の文字が表示されるまでの時間差により指定する。

図３２はオブジェクトのテキスト・カラオケ効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトのテキスト・カラオケ効果属性データについては、この値は0bhとする；
data_lengthは、テキスト・カラオケ効果属性データのうちdeta_lengthより後の部分のデータ長をバイト単位で指定する；
start_timeはこの属性データのdata_bytesに含まれる先頭のkaraoke_effect_entryで指定される文字列の文字色の変更開始時刻を指定する；
entryは、このテキスト・カラオケ効果属性データ中のkaraoke_effect_entryの数を示す；
data_bytesにentry個のkaraoke_effect_entryを含む；
karaoke_effect_entryの仕様は次に示す。

図３３はオブジェクトのテキスト・カラオケ効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
end_timeはこのエントリーで指定される文字列の文字色の変更終了時刻を表す。また、このエントリーに続くエントリーがある場合には、次のエントリーで指定される文字列の文字色の変更開始時刻も表す；
start_positionは文字色を変更すべき文字列の先頭文字の位置を、先頭から当該文字までの文字数により指定する；
end_positionは文字色を変更すべき文字列の最後の文字の位置を、先頭から当該文字までの文字数により指定する。

図３４はオブジェクトの階層属性拡張のデータ構造の例である。各データ要素の意味は以下の通りである：
attribute_idは、属性データのタイプを指定する。オブジェクトの階層属性拡張データについては、この値は0chとする；
data_lengthは、階層属性拡張データのうちdeta_lengthより後の部分のデータ長をバイト単位で指定する；
start_timeはこの属性データのdata_bytesに含まれる先頭のlayer_extension_entryで指定される階層値が有効となる開始時刻を指定する；
entryは、この階層属性拡張データに含まれるlayer_extension_entryの数を指定する；
data_bytesにentry個のlayer_extension_entryが含まれる；
layer_extension_entryの仕様を次に説明する。

図３５はオブジェクトの階層属性拡張のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである：
end_timeは、このlayer_extension_entryで指定される階層値が無効になる時刻を指定する。また、このエントリーの次にもエントリーがある場合には、次のエントリーで指定ｓれる階層値が有効になる開始時刻も同時に指定する；
layerは、オブジェクトの階層値を指定する。

図３６はオブジェクト・メタデータのＡＵのオブジェクト領域データ４００のデータ構造の例である。各データ要素の意味は以下の通りである：
vcr_start_codeは、オブジェクト領域データの開始を意味する；
data_lengthは、オブジェクト領域データのうちdata_lengthより後の部分のデータ長をバイトで指定する；
data_bytesはオブジェクト領域が記述されているデータ部である。オブジェクト領域の記述には、例えばMPEG-7のSpatioTemporalLocatorのバイナリフォーマットを用いることができる。

＜まとめ＞
この発明の一実施の形態に係る情報媒体（光ディスク等）には、ビデオコンテンツの再生に伴って再生可能な動画像のメタデータを有するものであって、独立に処理可能なデータ単位であるアクセスユニットで構成されるストリームを含むデータ構造を用いてデータ記録が行われる。ここで、前記データ構造は前記メタデータへのアクセスに利用される検索テーブルを含むように構成される。この検索テーブルにより、ユーザが知りたい情報へのアクセスが容易になり、動画像メタデータの情報を有意義に活用できる。

前記検索テーブルは所定の属性情報を持つように構成できる。この属性情報を利用して、ユーザが知りたい情報へのアクセスをより高速化できる。

前記検索テーブルは階層構造を有するように構成できる。これにより、検索テーブルを用いた検索において、一致検索または選択検索が階層をたどって選択可能になる。

前記検索テーブルは検索データを個別ファイル（別ファイル）に持つように構成できる。これにより、同じ検索データを複数箇所から参照して使い回すことが可能となり、検索データの効率的な利用ができる。

なお、この発明は上記した実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を種々変形して具体化することができる。例えば、この発明は現在世界的に普及しているＤＶＤ−ＲＯＭビデオのみならず、近年急速に需要が伸びている録画再生可能なＤＶＤ−ＶＲ（ビデオレコーダ）にも適用できる。さらには、近々普及が始まるであろう次世代ＨＤ−ＤＶＤの再生系または録再系にも適用可能である。

さらに、上記した実施の形態に開示されている複数の構成要素を適宜に組み合わせることにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除しても良いものである。さらに、異なる実施の形態に係る構成要素を適宜組み合わせても良い。

この発明の一実施の形態に係るハイパーメディアの表示例を説明する図。 この発明の一実施の形態に係るシステムの構成例を示すブロック図。 この発明の一実施の形態に係るオブジェクト領域とオブジェクト領域データの関係を説明する図。 この発明の一実施の形態に係るオブジェクト・メタデータのアクセスユニットのデータ構造例を説明する図。 この発明の一実施の形態に係るVclickストリームの構成方法を説明する図。 この発明の一実施の形態に係るVclickアクセス・テーブルの構成例を説明する図。 この発明の一実施の形態に係る送信用パケットの構成例を説明する図。 この発明の一実施の形態に係る送信用パケットの別の構成例を説明する図。 この発明の一実施の形態に係るサーバ・クライアント間の通信例を説明する図。 この発明の一実施の形態に係るサーバ・クライアント間の別の通信例を説明する図。 この発明の一実施の形態に係るVclickストリームのデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickストリームのヘッダのデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickアクセスユニット（ＡＵ）のデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickアクセスユニット（ＡＵ）のヘッダのデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickアクセスユニット（ＡＵ）のタイムスタンプのデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickアクセスユニット（ＡＵ）のタイムスタンプ・スキップのデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクト属性情報のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクト属性情報の種類の例を説明する図。 この発明の一実施の形態に係るオブジェクトの名前属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのアクション属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトの輪郭線属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトの点滅領域属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのモザイク領域属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトの塗りつぶし領域属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト情報データのデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト・ハイライト効果属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト・ハイライト効果属性のエントリーのデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト点滅効果属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト点滅効果属性のエントリーのデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキストスクロール効果属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト・カラオケ効果属性のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトのテキスト・カラオケ効果属性のエントリーのデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトの階層属性拡張のデータ要素の例を説明する図。 この発明の一実施の形態に係るオブジェクトの階層属性拡張のエントリーのデータ要素の例を説明する図。 この発明の一実施の形態に係るVclickアクセスユニット（ＡＵ）のオブジェクト領域データのデータ要素の例を説明する図。 この発明の一実施の形態に係る通常再生の開始処理手順を説明するフローチャート図（Vclickデータがサーバ装置にある場合）。 この発明の一実施の形態に係る別の通常再生の開始処理手順を説明するフローチャート図（Vclickデータがサーバ装置にある場合）。 この発明の一実施の形態に係る通常再生の終了処理手順を説明するフローチャート図（Vclickデータがサーバ装置にある場合）。 この発明の一実施の形態に係るランダムアクセス再生の開始処理手順を説明するフローチャート図（Vclickデータがサーバ装置にある場合）。 この発明の一実施の形態に係る別のランダムアクセス再生の開始処理手順を説明するフローチャート図（Vclickデータがサーバ装置にある場合）。 この発明の一実施の形態に係る通常再生の開始処理手順を説明するフローチャート図（Vclickデータがクライアント装置にある場合）。 この発明の一実施の形態に係るランダムアクセス再生の開始処理手順を説明するフローチャート図（Vclickデータがクライアント装置にある場合）。 この発明の一実施の形態に係るクライアント装置のフィルタリング動作を説明するフローチャート図。 この発明の一実施の形態に係るVclickアクセス・テーブルを用いたVclickストリーム中のアクセスポイント検索手順を説明するフローチャート図（その１）。 この発明の一実施の形態に係るVclickアクセス・テーブルを用いたVclickストリーム中のアクセスポイント検索手順を説明するフローチャート図（その２）。 この発明の一実施の形態に係るVclick_AUの有効期間とアクティブ期間が一致していない例を説明する図。 この発明の一実施の形態に係るNULL_AUのデータ構造の例を説明する図。 この発明の一実施の形態に係るNULL_AUを用いた場合のVclick_AUの有効期間とアクティブ期間の関係の例を説明する図。 この発明の一実施の形態に係るNULL_AUを用いた場合のメタデータ・マネージャの処理手順の例（その１）を説明するフローチャート図。 この発明の一実施の形態に係るNULL_AUを用いた場合のメタデータ・マネージャの処理手順の例（その２）を説明するフローチャート図。 この発明の一実施の形態に係るNULL_AUを用いた場合のメタデータ・マネージャの処理手順の例（その３）を説明するフローチャート図。 この発明の一実施の形態に係るエンハンスドＤＶＤビデオディスクの構造の例を説明する図。 この発明の一実施の形態に係るエンハンスドＤＶＤビデオディスク内のディレクトリ構成の例を説明する図。 この発明の一実施の形態に係るＤＶＤ再生準備処理を説明するフローチャート図。 この発明の一実施の形態に係るオブジェクト選択方法を説明するフローチャート図。 この発明の一実施の形態に係るオブジェクト再生方法を説明するフローチャート図。 この発明の一実施の形態に係る検索テーブルの構成例（その１）を説明する図。 この発明の一実施の形態に係る検索テーブルの構成例（その２）を説明する図。 この発明の一実施の形態に係る検索テーブルの構成例（その３）を説明する図。 この発明の一実施の形態に係る検索テーブルの構成例（その４）を説明する図。 この発明の一実施の形態に係る検索テーブルの構成例（その５）を説明する図。 この発明の一実施の形態に係る検索テーブルを用いる場合において、異なる場面で同じデータを使い回す場合の例を説明する図。 この発明の一実施の形態に係る検索方法（選択検索）を説明する図。 この発明の一実施の形態に係る検索方法（一致検索）を説明する図。

符号の説明

２００…クライアント装置；２０１…サーバ装置；２０２…Vclickエンジン；２０３…動画再生エンジン；２０９、３２２…バッファ（リングバッファ）；２２１…サーバ装置とクライアント装置を結ぶネットワーク；３０１〜３０５…Vclickアクセスユニット；４００…Vclickアクセスユニットのオブジェクト領域データ；４０１…Vclickアクセスユニットのヘッダ；４０２…Vclickアクセスユニットのタイムスタンプ；４０３…Vclickアクセスユニットのオブジェクト属性情報。

Claims (7)

1. ビデオコンテンツの再生に伴って再生可能な動画像のメタデータを有するものであって独立に処理可能なデータ単位であるアクセスユニットで構成されるストリームを含むデータ構造を用いてデータ記録を行なうものにおいて、
   前記データ構造が、前記メタデータへのアクセスに利用される検索テーブルを含むように構成された情報媒体。
2. 前記検索テーブルが、所定の属性情報を持つように構成された請求項１に記載の情報媒体。
3. 前記検索テーブルは一致検索または選択検索を選択可能に構成され、この検索テーブルが階層構造を有するように構成された請求項１または請求項２に記載の情報媒体。
4. 前記検索テーブルが検索データを個別ファイルに持つように構成された請求項１ないし請求項３のいずれか１項に記載の情報媒体。
5. 請求項１ないし請求項４のいずれか１項に記載の情報媒体から、前記ビデオコンテンツを再生するとともに、前記動画像メタデータを適宜再生するように構成された再生装置。
6. ビデオコンテンツの再生に伴って再生可能な動画像のメタデータを有するものであって独立に処理可能なデータ単位であるアクセスユニットで構成されるストリーム、および検索テーブルを含むように構成されたデータ構造を用いるものにおいて、
   前記検索テーブルを用いて前記メタデータへのアクセスを行なうように構成した方法。
7. ビデオコンテンツの再生に伴って再生可能な動画像のメタデータを有するものであって独立に処理可能なデータ単位であるアクセスユニットで構成されるストリーム、および検索テーブルを含むように構成されたデータ構造を用いるものにおいて、
   前記検索テーブルを用いて前記メタデータへのアクセスを行なうように構成した装置。

Images