JP2005318471A - 動画像のメタデータ - Google Patents

動画像のメタデータ Download PDF

Info

Publication number
JP2005318471A
JP2005318471A JP2004136687A JP2004136687A JP2005318471A JP 2005318471 A JP2005318471 A JP 2005318471A JP 2004136687 A JP2004136687 A JP 2004136687A JP 2004136687 A JP2004136687 A JP 2004136687A JP 2005318471 A JP2005318471 A JP 2005318471A
Authority
JP
Japan
Prior art keywords
vclick
data
buffer
moving image
information
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.)
Pending
Application number
JP2004136687A
Other languages
English (en)
Inventor
Yoichiro Yamagata
洋一郎 山縣
Yasushi Tsumagari
康史 津曲
Hideki Takahashi
秀樹 高橋
Toshimitsu Kaneko
敏充 金子
Tatsu Kamibayashi
達 上林
Hiroshi Isozaki
宏 磯崎
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004136687A priority Critical patent/JP2005318471A/ja
Priority to TW094112303A priority patent/TWI286295B/zh
Priority to EP05103130A priority patent/EP1592020A3/en
Priority to US11/116,321 priority patent/US20050244147A1/en
Priority to KR1020050036431A priority patent/KR100676432B1/ko
Priority to CNA2005100670907A priority patent/CN1708115A/zh
Publication of JP2005318471A publication Critical patent/JP2005318471A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T13/00—Animation
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/93—Regeneration of the television signal or of selected parts thereof
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2562—DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

【課題】視聴者の手元にある動画像と、視聴者の手元もしくはネットワーク上にあるメタデータとを組み合わせた処理を行う場合に、バッファを効率よく利用可能で、ランダムアクセスを容易であり、データロスの影響が小さいメタデータを提供する。
【解決手段】有効期間を特定するデータと、動画像中の時空間領域を記述したオブジェクト領域データと、表示属性および／または動作属性を有し、独立して処理可能なデータ単位であるVclickアクセスユニットを、１以上含むことにより、メタデータを構成する。
【選択図】 図４

Description

この発明は、クライアント装置にある動画像データとネットワーク（またはディスク）上のメタデータとを組み合わせて動画像ハイパーメディアを実現したり、また動画像にテロップや吹き出しを表示したりする方法に関する。
ハイパーメディアは、動画像、静止画像、音声、テキストなどのメディア間にハイパーリンクと呼ばれる関連性を定義し、相互に、または一方から他方を参照できるようにしたものである。例えばインターネットを使って閲覧することのできるＨＴＭＬで記述されたホームページには、テキストや静止画が配置されており、これらテキストや静止画のいたるところにリンクが定義されている。そしてこれらのリンクを指定することにより直ちにリンク先である関連情報を表示させることができる。興味のある語句を直接指示すれば関連情報にアクセスできるため、操作が容易かつ直感的である。
一方、テキストや静止画ではなく動画像を中心にしたハイパーメディアでは、動画像中に登場する人や物などのオブジェクトからそれを説明するテキストや静止画などの関連コンテンツへのリンクが定義されており、視聴者がこのオブジェクトを指示することによりこれら関連コンテンツが表示される。このとき、動画像に登場するオブジェクトの時空間的な領域とその関連コンテンツへのリンクを定義するには、動画像中のオブジェクトの時空間的な領域を表すデータ（オブジェクト領域データ）が必要となる。
オブジェクト領域データとしては、２値以上の値を持つマスク画像系列、ＭＰＥＧ−４の任意形状符号化、特許文献１で説明されている図形の特徴点の軌跡を記述する方法、さらに特許文献２で説明されている方法などを用いることができる。動画像中心のハイパーメディアを実現するためには、このほかにもオブジェクトが指定されたときに他の関連コンテンツを表示させるという動作を記述したデータ（動作情報）などが必要となる。これらの動画像以外のデータを動画像のメタデータと呼ぶことにする。
動画像とメタデータを視聴者に提供する方法としては、まず動画像とメタデータの両方が記録された記録媒体（ビデオＣＤ、ＤＶＤなど）を作る方法がある。また、すでにビデオＣＤやＤＶＤとして所有している動画像のメタデータを提供するには、メタデータのみをネットワーク上からダウンロード、もしくはストリーミングにより配信すればよい。さらに、動画像とメタデータの両方のデータをネットワークで配信しても良い。このとき、メタデータは効率的にバッファを使用することが可能で、ランダムアクセスに適しており、ネットワークにおけるデータロスに強い形式であることが望ましい。
また、動画像の切り替えが頻繁に生じる場合には（例えば、複数のカメラアングルで撮影された動画像が用意されており、視聴者は自由にカメラアングルを選択できるような場合…ＤＶＤビデオのマルチアングル映像のようなものなど）、動画像の切り替えに対応して高速にメタデータの切り替えができなければならない。
特開２０００−２８５２５３号公報 特開２００１−１１１９９６号公報
視聴者の手元にある動画像に関連したネットワーク上のメタデータを視聴者の元にストリーミング配信したり、視聴者の元にあるメタデータを再生したりする際は、
ａ）バッファの利用効率を向上させること、
ｂ）ランダムアクセスをしやすくすること、
ｃ）データロスの影響が小さいこと、
ｄ）メタデータの切り替えが高速にできること
が望まれる。
とくに、バッファの効率的な利用に関しては、バッファサイズが固定されていると、それに再生装置の仕様を合わせるか、コンテンツプロバイダがバッファ利用に関して細かなメンテナンスを行わなければならなくなる。また、バッファにメタデータの情報がないと、検索処理の都度、メタデータをディスクから読み込むか外部回線を介して受信する必要性が生じ、結果的に処理時間がかかる（この処理時間が長いとユーザを苛立たせることになる）。また、特殊再生（トリックプレイ、早送り、早戻しなど）をする場合に、その特殊再生の都度メタデータを受信しなければ、コンテンツ再生とメタデータ再生の同期がとれないという問題も起き得る。
この発明は上記の課題の少なくとも１つ（とくにａ）を解決すべくなされたものである。
この発明の一実施の形態に係る動画像メタデータ（そのデータ構造）は、システムが独立して処理可能なデータ単位であるアクセスユニットを、一つまたは複数含むことにより構成される。ここで、アクセスユニット（図４、図７７、図７８のVclick_AU）は、動画像の時間軸に対して定義される有効期間を特定する第１データ（４０２、Ｂ０１／Ｂ０２、Ｃ０１／Ｃ０２）と、前記動画像中の時空間領域を記述したオブジェクト領域データ（４００）と、前記時空間領域に関連した表示方法を特定するデータおよび前記時空間領域が指定された際にシステムが行う動作を特定するデータのうちの少なくとも１つを含む第２データ（４０３）を含んで構成される。
また、この発明の一実施の形態では、メタデータの再生時に用いるバッファ（図２の２０９；図８７の３２２）のサイズを指定するバッファサイズ情報の記述（３２１）を含む初期化情報（３２０）を備えるように構成される。
メタデータは単独で処理可能なアクセスユニットの集合体として構成されるため、バッファを効率よく使用でき、ランダムアクセスが容易であり、データロスの影響が小さく、メタデータの切り替えが高速にできるようになる。
ここで、ユーザＩ／ＦやＤＶＤのイベントを制御するインターフェース・ハンドラと、バッファリング機能を制御するメタデータ・マネージャと、メタデータのバッファを分ける実施の形態では、それぞれを個別に制御することができる。その際、バッファの初期状態を初期化情報（３２０）で必要な都度設定できる。
とくに、この初期化情報（３２０）で設定されたサイズのバッファに過去に再生したメタデータの一部も残す（図９４参照）ようにしておけば、コンテンツの早戻しをした際にも早戻し分に対応するメタデータがバッファに残っているので、メタデータとコンテンツとの同期再生が、早戻しなどの特殊再生時にも保証できるようになる。
以下、図面を参照しながらこの発明の一実施の形態を説明する。
（アプリケーションの概要）
図１はこの発明のオブジェクト・メタデータを動画像と共に利用することにより実現されるアプリケーション（動画像ハイパーメディア）の画面上の表示例である。図１（ａ）の１００は動画像の再生画面、そして１０１はマウスカーソルである。動画像の再生画面１００で再生される動画像のデータは、ローカルにある動画像データ記録媒体に記録されている。１０２は動画像中に登場するオブジェクトの領域である。ユーザがオブジェクトの領域内にマウスカーソルを移動させてクリック等によりオブジェクトを選択すると、所定の機能が実行される。例えば図１（ｂ）では、ローカルおよび／またはネットワーク上にあるドキュメント（クリックされたオブジェクトに関連した情報）１０３が表示されている。そのほか、動画像の別の場面にジャンプしたり、別の動画像ファイルが再生されたり、再生モードを変更するなどの機能を実行することができる。
オブジェクトの領域１０２のデータ及びこの領域がクリック等により指定された場合のクライアント装置の動作データなどをまとめて、オブジェクト・メタデータまたは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データＶＣＤはネットワーク上のサーバ装置２０１に置かれている場合もある。すなわち、VclickデータＶＣＤは、ディスク内および／またはディスク外に用意しておくことができる。そして、ディスク外にVclickデータＶＣＤを用意しておけば、VclickデータＶＣＤが記録されていない旧タイプのディスク（過去に市販されたビデオディスクなど）のコンテンツ再生においても、あるいはＴＶ放送を録画したコンテンツの再生においても、VclickデータＶＣＤを利用した再生が可能になる（それらのコンテンツに対応してVclickデータＶＣＤが作成されている場合）。
さらには、ビデオ記録可能な媒体（例えばＤＶＤ−Ｒディスク、ＤＶＤ−ＲＷディスク、ＤＶＤ−ＲＡＭディスク、ハードディスクなど）と、ビデオレコーダ（例えばＤＶＤ−ＶＲレコーダ、ＤＶＤ−ＳＲレコーダ、ＨＤ−ＤＶＤレコーダ、ＨＤＤレコーダなど）を用いてユーザが独自のディスクを作成した場合において、このディスクにVclickデータＶＣＤを含むＥＮＡＶコンテンツを記録するか、このディスク以外のパーソナルコンピュータのデータストレージなどにVclickデータＶＣＤを用意しこのパーソナルコンピュータとレコーダを接続すれば、ＤＶＤ−ＲＯＭビデオ＋図２のＥＮＡＶプレーヤと同様なメタデータ再生を楽しむことができる。
図５４は、上述した、Vclick情報ファイルＶＣＩ、Vclickアクセス・テーブルＶＣＡ、VclickストリームＶＣＳ、Vclick情報ファイル・バックアップＶＣＩＢ、Vclickアクセス・テーブル・バックアップＶＣＡＢを構成するためのファイルの例を示す。Vclick情報ファイルＶＣＩを構成するファイル（VCKINDEX.IFO）は、例えばXML（Extensible Markup Language）言語で記述されており、VclickストリームＶＣＳと、その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ファイルにて構成されており、前述のVclick情報ファイルＶＣＩ（VCKINDEX.IFO）と全く同じ内容のものである。VCKINDEX.IFOが何らかの理由により（ディスクの傷や汚れ等により）、読み込みが不可能な場合、このVCKINDEX.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情報ファイルＶＣＩは、XML言語で構成されており、最初に、XML言語であることが宣言され、次にXML言語で構成されたVclick情報ファイルＶＣＩであることが宣言される。更に、<vclickinfo>タグを用いてVclick情報ファイルＶＣＩの内容を記述する。
<vclickinfo>の領域は、0もしくは1つの<vmg>タグと、0もしくは1つ以上の<vts>タグから構成される。<vmg>の領域は、ＤＶＤビデオにおけるＶＭＧ空間を表しており、<vmg>の領域に記述されたVclickストリームは、ＶＭＧ空間のＤＶＤビデオデータに付加されることを表している。また、<vts>の領域は、ＤＶＤビデオにおけるＶＴＳ空間を表しており、<vts>タグ内にnum属性を付加することによりＶＴＳ空間の番号を指定している。例えば、<vts num="n">はn番目のＶＴＳ空間を示している。<vts num="n">の領域に記述されたVclickストリームは、n番目のＶＴＳ空間を構成するＤＶＤビデオデータに付加されることを表している。
<vmg>の領域は、0もしくは1つ以上の<vmgm>タグから構成される。<vmgm>の領域は、ＶＭＧ空間におけるＶＭＧメニュー・ドメインを表しており、<vmgm>タグ内にnum属性を付加することによりＶＭＧメニュー・ドメインの番号を指定している。例えば、<vmgm num="n">はn番目のＶＭＧメニュー・ドメインを示している。<vmgm num="n">の領域に記述されたVclickストリームは、n番目のＶＭＧメニュー・ドメインを構成するＤＶＤビデオデータに付加されることを表している。
更に、<vmgm>の領域は、0もしくは1つ以上の<pgc>タグから構成される。<pgc>の領域は、ＶＭＧメニュー・ドメインにおけるＰＧＣ（Program Chain）を表しており、<pgc>タグ内にnum属性を付加することによりＰＧＣの番号を指定している。例えば、<pmg num="n">はn番目のＰＧＣを示している。<pgc num="n">の領域に記述されたVclickストリームは、n番目のＰＧＣを構成するＤＶＤビデオデータに付加されることを表している。
次に、<vts>の領域は、0もしくは1つ以上の<vts_tt>タグと、0もしくは1つ以上の<vtsm>タグとから構成される。<vts_tt>の領域は、ＶＴＳ空間におけるタイトル・ドメインを表しており、<vts_tt>タグ内にnum属性を付加することによりタイトル・ドメインの番号を指定している。例えば、<vts_tt num="n">はn番目のタイトル・ドメインを示している。<vts_tt num="n">の領域に記述されたVclickストリームは、n番目のタイトル・ドメインを構成するＤＶＤビデオデータに付加されることを表している。
また、<vtsm>の領域は、ＶＴＳ空間におけるＶＴＳメニュー・ドメインを表しており、<vtsm>タグ内にnum属性を付加することによりＶＴＳメニュー・ドメインの番号を指定している。例えば、<vtsm num="n">はn番目のＶＴＳメニュー・ドメインを示している。<vtsm="n">の領域に記述されたVclickストリームは、n番目のＶＴＳメニュー・ドメインを構成するＤＶＤビデオデータに付加されることを表している。
更に、<vts_tt>の領域もしくは<vtsm>の領域は、0もしくは1つ以上の<pgc>タグから構成される。<pgc>の領域は、タイトル・ドメインもしくＶＴＳメニュー・ドメインにおけるＰＧＣ（Program Chain）を表しており、<pgc>タグ内にnum属性を付加することによりＰＧＣの番号を指定している。例えば、<pmg num="n">はn番目のＰＧＣを示している。<pgc num="n">の領域に記述されたVclickストリームは、n番目のＰＧＣを構成するＤＶＤビデオデータに付加されることを表している。
図５５〜図５７の例においては、6つのVclickストリームが、ＤＶＤビデオコンテンツに付加されている。例えば、最初の（一番目の）Vclickストリームは、<vmg>での<vmgm num="1">における<pgc num="1">において、<object>タグを用いて指定されている。これは、ＶＭＧ空間における、１番目のＶＭＧメニュー・ドメインにおける、1番目のＰＧＣに対して、<object>タグにより指定されたVclickストリームが付加されることを示している。
<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick1.vck"においてVclickストリームの存在する場所が指定されている。ここで、"file://dvdrom:/"はVclickストリームがエンハンスドＤＶＤディスク内に存在することを示し、更に、"dvd_enav/"はディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick1.vck"はVclickストリームのファイル名を示している。また、Vclickストリームを記述する<object>タグと、Vclickアクセス・テーブルＶＣＡを記述する<object>タグを併記することにより、Vclickストリームに対応したVclickアクセス・テーブルＶＣＡの情報を記述することができる。<object>タグ内において"data"属性を用い、Vclickアクセス・テーブルＶＣＡの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick1.ifo"においてVclickアクセス・テーブルＶＣＡの存在する場所が指定されている。ここで、"file://dvdrom:/"はVclickアクセス・テーブルＶＣＡがエンハンスドＤＶＤディスク内に存在することを示し、更に、"dvd_enav/"はディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick1.ifo"はVclickアクセス・テーブルＶＣＡのファイル名を示している。
次の（ニ番目の）Vclickストリームは、<vmg>における、<vmgm num="n">において、<object>タグを用いて指定されている。これは、ＶＭＧ空間における、１番目のＶＭＧメニュー・ドメイン全体に対して、<object>タグにより指定されたVclickストリームが付加されることを示している。<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"http//www.vclick.com/dvd_enav/vclick2.vck"においてVclickストリームの存在する場所が指定されている。ここで、"http//www.vclick.com/dvd_enav/"はVclickストリームが外部のサーバ（図２の２０１など）内に存在することを示し、"vclick2.vck"はVclickストリームのファイル名を示している。
Vclickアクセス・テーブルＶＣＡに関しても同様に、<object>タグ内において"data"属性を用い、Vclickアクセス・テーブルＶＣＡの存在する場所を示す。例えば、この発明の一実施の形態においては、"http//www.vclick.com/dvd_enav/vclick2.ifo"においてVclickアクセス・テーブルＶＣＡの存在する場所が指定されている。ここで、"http//www.vclick.com/dvd_enav/"はVclickアクセス・テーブルＶＣＡが外部のサーバ（２０１）内に存在することを示し、"vclick2.ifo"はVclickアクセス・テーブルＶＣＡのファイル名を示している。
三番目のVclickストリームは、<vts num="1">における、<vts_tt num="1">における、<pgc num="1">において、<object>タグを用いて指定されている。これは、１番目のＶＴＳ空間における、１番目のタイトル・ドメインにおける、1番目のＰＧＣに対して、<object>タグにより指定されたVclickストリームが付加されることを示している。<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick3.vck"においてVclickストリームの存在する場所が指定されている。ここで、"file://dvdrom:/dvd_enav/"は、Vclickストリームがディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick3.vck"はVclickストリームのファイル名を示している。
四番目のVclickストリームは、<vts num="1">における、<vts_tt num="n">において、<object>タグを用いて指定されている。これは、１番目のＶＴＳ空間における、n番目のタイトル・ドメインにおいて、<object>タグにより指定されたVclickストリームが付加されることを示している。<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick4.vck"においてVclickストリームの存在する場所が指定されている。ここで、"file://dvdrom:/dvd_enav/"は、Vclickストリームがディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick4.vck"はVclickストリームのファイル名を示している。
五番目のVclickストリームは、<vts num="1">における、<vtsm num="1">において、<object>タグを用いて指定されている。これは、１番目のＶＴＳ空間における、１番目のＶＴＳメニュー・ドメインにおいて、<object>タグにより指定されたVclickストリームが付加されることを示している。<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick5.vck"においてVclickストリームの存在する場所が指定されている。ここで、"file://dvdrom:/dvd_enav/"は、Vclickストリームがディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick5.vck"はVclickストリームのファイル名を示している。
六番目のVclickストリームは、<vts num="1">における、<vtsm num="1">における、<pgc num="1">において、<object>タグを用いて指定されている。これは、１番目のＶＴＳ空間における、１番目のＶＴＳメニュー・ドメインにおける、1番目のＰＧＣに対して、<object>タグにより指定されたVclickストリームが付加されることを示している。<object>タグでは、"data"属性を用いて、Vclickストリームの存在する場所を示す。例えば、この発明の一実施の形態においては、"file://dvdrom:/dvd_enav/vclick6.vck"においてVclickストリームの存在する場所が指定されている。ここで、"file://dvdrom:/dvd_enav/"は、Vclickストリームがディスク中の"DVD_ENAV"ディレクトリの下に存在することを示し、"vclick6.vck"はVclickストリームのファイル名を示している。
図５８は、前述のVclickインフォＶＣＩの記述例にて記述されたVclickストリームＶＣＳとＤＶＤビデオコンテンツの関係を例示する図である。この例では、１番目のＶＴＳ空間（ＶＴＳ＃１）における、1番目のＶＴＳメニュー・ドメイン（ＶＴＳメニュー＃１）での1番目のＰＧＣ（ＰＧＣ＃１）に対して、前述の五番目のVclickストリームＶＣＳ（Vclick#5）と、六番目のVclickストリームＶＣＳ（Vclick#6）が付加されている。これは、ＤＶＤビデオコンテンツに対して、二つのVclickストリームＶＣＳ（Vclick#5とVclick#6）が付加されていることを表している。これらのストリーム（Vclick#5とVclick#6）は、例えば、ユーザによって、あるいはコンテンツ・プロバイダ（コンテンツ・オーサ）によって、切り替えることが可能となっている。
ユーザが切り替える場合は、VclickストリームＶＣＳを切り替えるための“Vclick切り替えボタン”が図２の装置に付属するリモートコントローラに備え付けてあり、これにより二つもしくはそれ以上のVclickストリームを自由に変更することができる。図示しないが、このリモートコントローラは、一般的なＤＶＤビデオプレーヤのリモートコントローラキーの他に“Vclick切り替えボタン”を持ち、このボタンが押されると、プレーヤはVclickストリーム切り替えモードに入る。そして、このモードにおいて“Vclick切り替えボタン”をクリックするか、あるいはこのモードにおいて図示しないリモートコントローラの上下または左右カーソルキーを押すことで、Vclickストリームのストリーム番号の指定を順次切り替えることができる。あるいは、このモードにおいて、図示しないリモートコントローラのテンキーから、ダイレクトにVclickストリームＶＣＳのストリーム番号を指定する方法も採用できる。
一方、VclickストリームＶＣＳをコンテンツ・プロバイダが変更する場合は、Markup言語にVclick切り替えのためのコマンド（記述形式は例えば"changeVclick()"）が記述されており、コンテンツ・プロバイダがMarkup言語にて指定したタイミングでこの切り替えコマンドを発行することで、二つもしくはそれ以上のVclickストリームＶＣＳを自由に変更できる。
図５９〜図６５は、Vclick情報ファイルＶＣＩの別の記述例（7つ）を示す。最初の例（図５９）においては、一つのＰＧＣ（ＰＧＣ＃１）に対し、ディスク上に記録されている二つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２）とサーバ（図２の２０１など）上に記録されている一つのVclickストリーム（Vclickストリーム＃３）が付加されている。これは前述のように、ユーザのリモートコントローラ操作によってVclickストリーム＃１、Vclickストリーム＃２、Vclickストリーム＃３を自由に切り替えさせることもでき、コンテンツ・プロバイダによって（例えば前述した"changeVclick()"コマンドを用いて）切り替えさせることもできる。
上記の例においてコンテンツ・プロバイダによって切り替えさせる場合、例えば、再生装置（図２の２００など）にVclickストリーム＃３の再生が指示されたが再生装置（２００）が外部サーバ（２０１）につながっていない場合、あるいは、つながってはいるがVclickストリーム＃３が外部サーバから取得できない場合は、取得できないVclickストリーム＃３に代わって、ティスク上のVclickストリーム＃１またはVclickストリーム＃２に代替させることができる。また、<object>タグ内の"priority”属性は、それぞれのストリームを切り替える際の順番を示しており、例えば、前述のユーザ（“Vclick切り替えボタン”を用いる）やコンテンツ・プロバイダ（Vclick切り替えのためのコマンド"changeVclick()"を用いる）がVclickストリームを順次切り替える際に、"priority”属性の順序を参照することで、Vclickストリーム＃１→Vclickストリーム＃２→Vclickストリーム＃３→Vclickストリーム＃１→．．．というように切り替えることができる。
また、コンテンツ・プロバイダは、Markup言語において、Vclick切り替えのためのコマンド（記述形式は例えば"changeVclick(priority)"）を用いることにより、コンテンツ・プロバイダがMarkup言語にて指定したタイミングでコマンドを発行し、任意のVclickストリームを選択することもできる。例えば、"changeVclick(2)"コマンドを発行した場合は、"priority属性"が"2"であるVclickストリーム＃２が再生される。
次の例（図６０）においては、一つのＰＧＣ（ＰＧＣ＃２）に対し、ディスク上に記録されている二つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２）が付加されている。ここで、<object>タグ内の"audio"属性は、オーディオ・ストリーム番号に対応しており、この例においては、ＤＶＤビデオコンテンツのオーディオ・ストリーム＃１が再生されている場合は、Vclickストリーム＃１（Vclick1.vck）を同期再生し、オーディオ・ストリーム＃２が再生されている場合は、Vclickストリーム＃２（Vclick2.vck）を同期再生することを示す。
例えば、ビデオコンテンツのオーディオ・ストリーム＃１が日本語音声、オーディオ・ストリーム＃２が英語音声にて構成されている場合、図６８に示すようにVclickストリーム＃１を日本語にて（つまりVclickオブジェクトの説明の表示が日本語で記述されている、またはVclickオブジェクトがクリックさせたあとのアクセス先が日本語で構成されているサイトやページ）構成し、図６７に示すようにVclickストリーム＃２を英語にて（つまりVclickオブジェクトの説明の表示が英語で記述されている、またはVclickオブジェクトがクリックさせたあとのアクセス先が日本語で構成されているサイトやページ）を構成することにより、ＤＶＤビデオコンテンツの音声の言語とVclickストリームの言語を合わせることができる。実際には、再生装置は、再生装置内のシステムパラメータであるＳＰＲＭ（１）（オーディオ・ストリーム番号）を参照し、それに対応したVclickストリームを、このVclick情報ファイルＶＣＩから検索して再生する。
上記は一例にすぎず、例えばＤＶＤビデオコンテンツが英語音声である場合に日本語のMarkupページが同期再生されるように構成してもよい（図６７の左側と図６８の右側の組み合わせなど）。逆に、ＤＶＤビデオコンテンツが日本語音声である場合に英語のMarkupページが同期再生されるように構成してもよい。これは、Vclickオブジェクトのアクション属性（図２０）のScriptフィールドに記述する情報を何にするかで自在に実現できる。
三番目の例（図６１）においては、一つのＰＧＣ（ＰＧＣ＃３）に対し、ディスク上に記録されている三つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２、Vclickストリーム＃３）が付加されている。ここで、<object>タグ内の"subpic"属性は、サブピクチャ・ストリーム番号（副映像番号）に対応しており、この例においては、ＤＶＤビデオコンテンツのサブピクチャ・ストリーム＃１が再生されている場合は、Vclickストリーム＃１（Vclick1.vck）を同期再生し、サブピクチャ・ストリーム＃２が再生されている場合は、Vclickストリーム＃２（Vclick2.vck）を同期再生し、サブピクチャ・ストリーム＃３が再生されている場合は、Vclickストリーム＃３（Vclick3.vck）を同期再生することを示す。
例えば、ビデオコンテンツのサブピクチャ・ストリーム＃１が日本語字幕、サブピクチャ・ストリーム＃３が英語字幕にて構成されている場合、図７０に示すように、Vclickストリーム＃１を日本語にて（つまりVclickオブジェクトの説明の表示が日本語で記述されている、またはVclickオブジェクトがクリックさせたあとのアクセス先が日本語で構成されているサイトやページ）構成し、図６９に示すように、Vclickストリーム＃２を英語にて（つまりVclickオブジェクトの説明の表示が英語で記述されている、またはVclickオブジェクトがクリックさせたあとのアクセス先が日本語で構成されているサイトやページ）を構成することにより、ＤＶＤビデオコンテンツの字幕の言語とVclickストリームの言語を合わせることができる。実際には、再生装置は、再生装置内のシステムパラメータであるＳＰＲＭ（２）（サブピクチャ・ストリーム番号）を参照し、それに対応したVclickストリームを、このVclick情報ファイルＶＣＩから検索して再生する。なお、上記は一例にすぎず、例えばユーザの希望に応じて、ＤＶＤビデオコンテンツが英語字幕（または日本語字幕）である場合に日本語解説（または英語解説）のMarkupページが同期再生されるように構成することもできる。
四番目の例（図６２）においては、一つのＰＧＣ（ＰＧＣ＃４）に対し、ディスク上に記録されている二つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２）が付加されている。ここで、<object>タグ内の"angle"属性は、アングル番号に対応しており、この例においては、ビデオコンテンツのアングル＃１が再生されている場合は、Vclickストリーム＃１（Vclick1.vck）を同期再生し（図７１）、アングル＃３が再生されている場合は、Vclickストリーム＃２（Vclick2.vck）を同期再生し（図７２）、アングル＃２が再生されている場合は、Vclickストリームを再生しないことを示す。通常、アングルが異なる場合は、人物などのVclickオブジェクトを付加する対象の位置が異なるため、アングルごとにVclickストリームを構成する必要がある（後述する図８３がこの場合の一例に対応）。あるいは、前述した図５のように、一つのVclickストリーム５０６にそれぞれのVclickオブジェクト・データをマルチプレクスしてもよい。実際には、再生装置（図２のクライアント装置２００に対応）は、再生装置内のシステムパラメータであるＳＰＲＭ（３）（アングル番号）を参照し、それに対応したVclickストリームＶＣＳを、このVclick情報ファイルＶＣＩから検索して再生する。
五番目の例（図６３）においては、一つのＰＧＣ（ＰＧＣ＃５）に対し、ディスク上に記録されている三つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２、Vclickストリーム＃３）が付加されている。ここで、<object>タグ内の"aspect"属性は、（初期）表示アスペクト比に対応しており、<object>タグ内の"display"属性は、（現在）表示モードに対応している。
この例においては、ＤＶＤビデオコンテンツ自体が"１６：９"のアスペクト比で構成されており、"１６：９"のアスペクト比をもつＴＶモニターには"ワイド（wide）"出力を、"４：３"のアスペクト比をもつＴＶモニターには"レターボックス（lb）"または"パンスキャン（ps）"出力が許されている例を示す。これに対して、Vclickストリームは、（初期）表示アスペクト比が"１６：９"かつ（現在）表示モードが"wide"のときはVclickストリーム＃１を同期再生し（図７３）、（初期）表示アスペクト比が"４：３"かつ（現在）表示モードが"lb"のときはVclickストリーム＃２を同期再生し（図７４）、（初期）表示アスペクト比が"４：３"かつ（現在）表示モードが"ps（パンスキャン）"のときはVclickストリーム＃３を同期再生する（図７５）。
ここで、例えば"１６：９"のアスペクト比で表示されていたときに人物の真横に表示されていたVclickオブジェクトの吹き出しを"４：３"のアスペクト比の"レターボックス"に表示する場合は、画面の上下（図７４では図示上下のハッチング部分）に表示してもよい。あるいは、この吹き出しを"４：３"のアスペクト比の"パンスキャン"で表示する場合は、画面の左右が切れてしまうが、吹き出しおよびオブジェクトの位置を、図７５に例示されるように、表示が可能な位置に変更（移動）してもよい。
また、画面の構成に応じて、吹き出し文字の表示エリアが画面からはみ出さないように吹き出しのサイズを小さくしたり、または吹き出し文字の表示エリアサイズとオブジェクトサイズの表示バランスが適正となるように吹き出し文字の表示エリアを大きくしたり、吹き出し文字の表示エリア内の文字のサイズを小さくまたは大きくして吹き出しエリア内の文字の表示バランスを適正化してもよい。ここで、吹き出し内の文字サイズを小さくしたときは、文字周辺と文字との間のコントラストを大きくとり、文字周辺に対して文字が目立つように文字の色を工夫し（例えば白地に赤文字とか黒地に黄文字）、および／またはフォントを太字に変更するなどして、文字の視認性が悪くならないように工夫するとよい。
これにより、ＤＶＤビデオコンテンツの表示状態に応じたVclickオブジェクトの表示を行うことが可能になる。実際には、再生装置は、再生装置内のシステムパラメータであるＳＰＲＭ（１４）（ビデオ用のプレーヤ構成）における“初期表示アスペクト比”と“現在表示モード”を参照し、それに対応したVclickストリームＶＣＳを、Vclick情報ファイルＶＣＩから検索して再生する。
六番目の例（図６４）においては、一つのＰＧＣ（ＰＧＣ＃６）に対し、ディスク上に記録されている一つのVclickストリーム（Vclickストリーム＃１）が付加されている。前例と同様に、<object>タグ内の"aspect"属性は、（初期）表示アスペクト比に対応しており、<object>タグ内の"display"属性は、（現在）表示モードに対応している。この例においては、ＤＶＤビデオコンテンツ自体が"４：３"のアスペクト比で構成されており、"４：３"のアスペクト比をもつＴＶモニターには"通常"モードで出力する場合に適用される。
最後に、前述の機能を組み合わせて用いることが可能であることを示す例（図６５）を示す。一つのＰＧＣ（ＰＧＣ＃７）に対し、ディスク上に記録されている四つのVclickストリーム（Vclickストリーム＃１、Vclickストリーム＃２、Vclickストリーム＃３、Vclickストリーム＃４）が付加されている。この例においては、ＤＶＤビデオコンテンツのオーディオ・ストリーム＃１が再生され、かつサブピクチャ・ストリーム＃１が再生され、かつアングル＃１が再生されている場合はVclickストリーム＃１（Vclick1.vck）を同期再生し、オーディオ・ストリーム＃１が再生され、かつサブピクチャ・ストリーム＃２が再生され、かつアングル＃１が再生されている場合はVclickストリーム＃２（Vclick2.vck）を同期再生し、アングル＃２が再生されている場合はVclickストリーム＃３（Vclick3.vck）を同期再生し、オーディオ・ストリーム＃２が再生され、かつサブピクチャ・ストリーム＃２が再生されている場合はVclickストリーム＃４（Vclick4.vck）を同期再生する。
以上、7つの例（図５９〜図６５）に関して、ＤＶＤビデオコンテンツのＰＧＣとその属性に対する付加されるVclickストリームの関係を図６６に示す。図６６の例においては、大きくいってＰＧＣ毎にVclickストリームＶＣＳが割り当てられており、その割り当て方が、各ＰＧＣの属性等に応じて細分化されている。
すなわち、ＰＧＣ＃１ではそのＰＧＣ全体に対してVclick#1〜#3のストリームが割り当てられている（図５９に対応）。この例では、Vclick#1のストリームを例えば英語ページとし、Vclick#2のストリームを例えば日本語ページとし、Vclick#3のストリームを例えば中国語ページとし、これらのストリームを適宜切り替え選択できるように構成できる（ビデオコンテンツのＰＧＣの再生区間に応じてメタデータのストリーム選択を行う構成）。
図６６のＰＧＣ＃２では、そのオーディオ＃１に対してVclick#1のストリームが割り当てられ、そのオーディオ＃２に対してVclick#2のストリームが割り当てられている（図６０に対応）。ＰＧＣ＃３ではそのサブビクチャ（字幕などの副映像）＃１に対してVclick#1のストリームが割り当てられ、そのサブビクチャ＃２に対してVclick#2のストリームが割り当てられ、そのサブビクチャ＃３に対してVclick#3のストリームが割り当てられている（図６１に対応）。ＰＧＣ＃４ではそのアングル＃１に対してVclick#1のストリームが割り当てられ、そのアングル＃２に対してはVclickストリームが割り当てられておらず、そのアングル＃３に対してVclick#2のストリームが割り当てられている（図６２に対応）。ＰＧＣ＃５では、表示のアスペクト比が１６：９のワイドならVclick#1のストリームが割り当てられ、表示のアスペクト比が４：３のパンスキャンならVclick#2のストリームが割り当てられ、表示のアスペクト比が４：３のレターボックスならVclick#3のストリームが割り当てられている（図６３に対応）。ＰＧＣ＃６では、表示のアスペクト比が通常の４：３ならVclick#4のストリームが割り当てられるようになっている（図６４に対応）。
図６６のＰＧＣ＃７では、アングル＃１のオーディオ＃１（例えば英語音声）にリンクしたサブピクチャ＃１（例えば英語字幕）に対してはVclick#1のストリーム（例えば英語ページ）が割り当てられ、アングル＃１のオーディオ＃１（英語音声）にリンクしたサブピクチャ＃２（例えば日本語字幕）に対してはVclick#2のストリーム（例えば日本語ページ）が割り当てられている。また、アングル＃１のオーディオ＃２（例えば日本語音声）にリンクしたサブピクチャ＃１（英語字幕）に対してはVclickストリームは割り当てられておらず、アングル＃１のオーディオ＃２（日本語音声）にリンクしたサブピクチャ＃２（日本語字幕）に対してはVclick#4のストリーム（例えば他の日本語ページ）が割り当てられている。さらに、アングル＃２のオーディオ＃１（英語音声）にリンクしたサブピクチャ＃１（英語字幕）とサブピクチャ＃２（日本語字幕）に対してはVclick#3のストリーム（例えば中国語ページ）が割り当てられていおり、アングル＃２のオーディオ＃２（日本語音声）にリンクしたサブピクチャ＃１（英語字幕）とサブピクチャ＃２（日本語字幕）に対してはVclick#3のストリーム（中国語ページ）が割り当てられている。そのうち、アングル＃２のオーディオ＃２（日本語音声）にリンクしたサブピクチャ＃２（日本語字幕）に対してはVclick#3のストリーム（中国語ページ）の他にVclick#4のストリーム（他の日本語ページ）がさらに割り当てられている。アングル＃２のオーディオ＃２（日本語音声）にリンクしたサブピクチャ＃２（日本語字幕）に対しては、Vclick#3のストリーム（中国語ページ）またはVclick#4のストリーム（他の日本語ページ）を切り替え選択できる。
なお、Vclickストリームと同期再生する対象がＤＶＤビデオコンテンツである場合は、Vclickストリーム切り替えのタイミングは、大きくはＤＶＤビデオのタイトル（ＶＴＳ）単位とすることができ、それより小さな切り替えタイミングの単位としてはパートオブタイトル（チャプタ）単位とすることができる。また、より小さな切り替えタイミングの単位としてはプログラムチェーン（ＰＧＣ）単位とすることができ、さらに小さくはプログラム（ＰＧ）単位とすることができ、もっと小さくはセル単位とすることができる。
この発明の一実施の形態に係るVclickストリームがＤＶＤ−ＶＲ、ＤＶＤ−ＳＲ、ＨＤ−ＤＶＤレコーダなどの録再系に適用される場合は、ユーザ定義のＰＧＣ（プレイリスト）を単位として、あるいはＰＧＣを構成するプログラム内の一部にマーキングされるエントリポイントを単位として、Vclickストリームを切り替えるようにしてもよい。
この発明の一実施の形態における再生装置（エンハンスドＤＶＤプレーヤ）は、ＤＶＤビデオコンテンツを再生する前に、Vclick情報ファイルＶＣＩをあらかじめ読み込むことにより、もしくは適宜参照することにより、ＤＶＤビデオコンテンツの再生状態に応じて、逐次付加するVclickストリーム・ファイルを変化させることが可能となる。これにより、Vclickストリームを構成するにあたり自由度を持つことができ、オーサリングの負担を軽減することが可能となる。
また、一つのVclickコンテンツのファイル数（ストリーム数）を増やし、各々のファイル・サイズを小さくすることにより、再生装置に必要とされるVclickストリームＶＣＳを格納するための領域（図２の装置ではバッファ２０９）を小さくすることも可能になる。
また、ファイル・サイズは大きくなるが、ファイル数を減らす（つまり一つのストリームが複数のVclickデータを含む構成にする）ことにより、ＤＶＤビデオコンテンツの再生状態が変化した場合、スムーズにVclickデータを切り替えることが可能となる（バッファリングされているVclickデータの情報量が大きいため）。
（データ構造の概略とアクセス・テーブル）
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を有する。
上記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ストリームＶＣＳは次の条件を満たしている：
ｉ）VclickストリームＶＣＳ中のVclick_AUはタイムスタンプの昇順に並べられている。このとき、Vclick_AUの有効期間を次のように決定する：あるＡＵのタイムスタンプ値をtとおく。VclickストリームＶＣＳにおいて当該ＡＵ以降にあるＡＵのタイムスタンプ値uについて、上記条件によりu >= tなる関係が成立する。このようなuの中でu≠tである最小の値をt’とおく。時刻tを開始時刻、時刻t’を終了時刻とする期間を、当該ＡＵの有効期間とする。ただし、当該ＡＵ以降にu > tなるタイムスタンプ値uを有するＡＵが存在しない場合、当該ＡＵの有効期間の終了時刻は、動画像の終了時刻に一致するものとする。
ii）Vclick_AUのアクティブ期間は、先に定義したとおり、Vclick_AU含まれるオブジェクト領域データに記述されているオブジェクト領域の時間範囲である。
ここで、VclickストリームＶＣＳについて、アクティブ期間に関する次の制約条件をおく：
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データをサーバ装置２０１からクライアント装置２００に送信するときに使用するプロトコルとしては、例えばＲＴＰ（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_AUの有効期間指定方法の説明）
図７７は、図４とは別のVclick_AUのデータ構造の例である。図４との違いは、Vclick_AUの有効期間を特定するためのデータが、タイムスタンプのみではなく、タイムスタンプＢ０１と存続時間または継続時間Ｂ０２の組み合わせとなっている点である。タイムスタンプＢ０１はVclick_AUの有効期間の開始時刻であり、継続時間Ｂ０２はVclick_AUの有効期間の開始時刻から終了時刻までの継続時間である。継続時間の具体的な構成は、例えば図７９のようにすればよい。ここでtime_typeは図７９のデータが継続時間を意味することを特定するためのＩＤであり、durationが継続時間である。durationはあらかじめ決められた単位（例えば、１ミリ秒や０．１秒など）で継続時間を表す。
このようにVclick_AUを特定するためのデータとして継続時間も記述することの利点は、処理対象のVclick_AUだけを見ればそのVclick_AUの継続時間を知ることができる点である。従って、例えばあるタイムスタンプで有効なVclick_AUを探索しているような場合に、他のVclick_AUのデータを調べることなく、そのVclick_AUが探索対象であるかどうかが判定できる。ただし、図４の場合よりも継続時間Ｂ０２の分だけデータサイズが大きくなる。
図７８は図７７とはまた別のVclick_AUのデータ構造の例である。この例では、Vclick_AUの有効期間を特定するためのデータとしてVclick_AUの有効期間の開始時刻を特定するタイムスタンプＣ０１と終了時刻を特定するタイムスタンプＣ０２を使用している。このデータ構造を用いる場合の利点は図７７のデータ構造を用いる場合と実質的に同じである。
図８０は、この発明の一実施の形態に係るVclick情報の記述例８を説明する図である。この例では、一つのＰＧＣ（ＰＧＣ＃８）に対し、ディスク上に記録されている一つのVclickストリームＶＣＳ＃１（Vclick1.vck）が付加されている。ここでは、<object>タグ内に"start"、"end"属性が記述されている。ここで、"start"属性は、VclickストリームＶＣＳの表示を開始する時間の相対値を、'HH:MM:SS:FF'形式（時間：分：秒：フレーム）の精度で表している。また、"end"属性は、VclickストリームＶＣＳの表示を終了する時間の相対値を、'HH:MM:SS:FF'形式（時間：分：秒：フレーム）の精度で表している。ここで、"start"、"end"属性は、VclickストリームＶＣＳがこの例のようにＰＧＣに対して付加されている場合は、ＰＧＣの開始位置からの相対時間を表している。もし、タイトル・ドメイン（"<vts_tt>"）に対して付加されている場合は、タイトル・ドメインの開始位置からの相対時間を表す。
図８１は、この発明の一実施の形態に係るVclick情報の記述例９を説明する図である。この例では、一つのＰＧＣ（ＰＧＣ＃９）に対し、ディスク上に記録されている一つのVclickストリームＶＣＳ（Vclick2.vck）が付加されている。ここでは、<object>タグ内の"start_ptm"、"end_ptm"属性が記述されている。ここで、"start_ptm"属性は、付加オブジェクトの表示を開始する時間の相対値を、PTM（Presentation Time:90kHzのクロックによるカウンタ）の精度で表している。また、"end_ptm"属性は、付加オブジェクトの表示を終了する時間の相対値を、PTM（Presentation Time:90kHzのクロックによるカウンタ）の精度で表している。ここで、"start_ptm"、"end_ptm"属性は、付加オブジェクトがこの例のようにＰＧＣに対して付加されている場合は、ＰＧＣの開始位置からの相対時間を表している。もし、タイトル・ドメイン（"<vts_tt>"）に対して付加されている場合は、タイトル・ドメインの開始位置からの相対時間を表す。
図８２は、この発明の他の実施の形態に係る再生処理手順を説明するフローチャートである。このフローチャートは、ユーザからの入力（リモコン操作など）に応じて再生するVclickストリームＶＣＳを変更する手順を例示している。
まず、ＤＶＤビデオコンテンツの再生に同期してVclickストリームＶＣＳを再生しているとき（ステップＳ８２０１ノーのループ）、ユーザからなんらかの入力があったものとする（ステップＳ８２０１イエス）。ここでのユーザ入力としては、音声の切り替え、字幕の切り替え、アングルの切り替え等の再生属性の変更や、早送り、巻き戻し、スキップ等の特殊再生の開始などが考えられる。
ユーザ入力が再生属性の変更であった場合は（ステップＳ８２０２の“再生属性の変更”側分岐）、再生装置（図２ではクライアント装置２００）は、変更された再生属性情報（例えば音声のストリーム番号、サブピクチャ・ストリーム番号、アングル番号）に対応したデータ（Vclick_AU）を現在再生中のVclickストリームＶＣＳ中から検索する（ステップＳ８２０４）。変更された再生属性情報に対応するVclick_AUが再生中のVclickストリームＶＣＳから検索できた場合（ステップＳ８２０５イエス）、再生を行うVclick_AUのフィルタＩＤ（図１４のfiltering_id）を検索されたVclick_AUのもつフィルタＩＤに変更し（ステップＳ８２０６）、変更後の新しいフィルタＩＤで識別されるVclick_AUを含むVclickストリームＶＣＳを選択して、その再生を開始する。
もし、再生中のVclickストリームＶＣＳ中に再生するVclick_AUが見つからなかった場合は（ステップＳ８２０５ノー）、対応するVclick_AUを含むVclickストリームＶＣＳを再生する必要がある。このVclickストリームＶＣＳを検索するのに、VclickインフォＶＣＩのファイル（図５４のVCKINDEX.IFO）を用いる（ステップＳ８２０７）ことができる。この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ストリームＶＣＳが現在デコード中のものと同じかどうかチェックする。同じであれば（ステップＳ８２０３イエス）、同じ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インフォＶＣＩファイル上に、指定された再生位置に対応したVclickストリームＶＣＳが存在しない場合は（ステップＳ８２０８ノー）、VclickストリームＶＣＳの再生を停止し、ＤＶＤビデオコンテンツの再生を継続する。
図８３は、この発明の他の実施の形態に係るVclickストリームＶＣＳ（マルチストリーム）の構成方法を説明する図である。この例は、図５の変形例である。すなわち、図５の例では複数アングルのVclick_AUが１本のVclickストリームＶＣＳに纏められているが、図８３では、複数アングル各々のVclick_AUを、対応する複数VclickストリームＶＣＳに格納している。つまり、図８３の例では、Vclickストリーム８３６は日本語アングル１用のVclick_AU８３０〜８３１で構成され、Vclickストリーム８３７は日本語アングル２用のVclick_AU８３２で構成され、Vclickストリーム８３８は英語アングル１用のVclick_AU８３３〜８３４で構成されている。
図８４は、この発明の他の実施の形態に係る起動処理手順を説明するフローチャートである。この処理手順は、図８３のような複数Vclickストリームがある場合に対応している。
まず、VclickインフォＶＣＩファイル（図５４のVCKINDEX.IFO）をエンハスドＤＶＤビデオディスク（図５３）あるいは外部サーバ装置２０１（図２）から読み込み（ステップＳ８４０１）、再生装置（図２ではクライアント装置２００）のメモリ（ワークメモリあるいはバッファ２０９）に格納する。このVclickインフォＶＣＩファイルから、VclickストリームＶＣＳの存在する場所およびそのファイル名などの情報を得ることができる（図５４の説明におけるVclickインフォ・ファイルの解説参照）。こうして得た情報から、必要なVclickストリームＶＣＳ（図８３の例では３本のストリーム８３６〜８３８）を抽出する（ステップＳ８４０２）。抽出したVclickストリームＶＣＳのデータはバッファ２０９に格納される（ステップＳ８４０３）。
このバッファ格納において、複数のストリーム（図８３では８３６〜８３８）のどれからバッファリングするか（バッファへの読み込み優先度の設定方法）については、幾つかの方法がある。その方法の第１の例は、各ストリームに対応するビデオコンテンツのＰＧＣ番号の小さいものから該当ストリームを読み込むというものである。例えばＰＧＣ＃１にVclickストリーム#1が付加されており、ＰＧＣ＃２にVclickストリーム#２が付加されており、読み込むべきストリームがVclickストリーム#1とVclickストリーム#２であるときは、まずVclickストリーム#1がバッファ２０９に読み込まれ、次にVclickストリーム#2がバッファ２０９に読み込まれる。
第２の例は、プレーヤ（クライアント装置２００）に予め設定されている言語に従い読み込み優先度を決めるというものである。例えば、プレーヤに第１言語（あるいはデフォルト選択の言語）として日本語が設定され、第２言語として英語が設定されている場合であって、Vclickストリーム#1に英語の属性（例えば図２５の“language”で英語が指定される）が付与され、Vclickストリーム#2に日本語の属性（例えば図２５の“language”で日本語が指定される）が付与されているときは、まずVclickストリーム#2がバッファ２０９に読み込まれ、次にVclickストリーム#1がバッファ２０９に読み込まれる。
第３の例は、読み込むべきストリームがディスクにある場合を、外部サーバにある場合より優先させるものである。例えばVclickストリーム#2が外部サーバにありVclickストリーム#1とVclickストリーム#3がディスクにある場合において、Vclickストリーム#1〜Vclickストリーム#3を読み込むときは、まずVclickストリーム#1とVclickストリーム#3がその番号順でバッファ２０９に読み込まれ、その後にVclickストリーム#2がバッファ２０９に読み込まれる。
バッファ２０９にアサインされたサイズ（後述する図８７の例では２Ｍバイト）までVclickストリームの格納が済むと（ステップＳ８４０４イエス）、ＤＶＤビデオコンテンツの再生が開始される（ステップＳ８４０５）。あるいは、バッファ２０９に格納されたVclickストリームのサイズが予め決められた再生サイズ（後述する図８７の例では１２ｋバイト）に達したら、ＤＶＤビデオコンテンツの再生を開始する（ステップＳ８４０５）ようにしてもよい。
ＤＶＤビデオコンテンツの再生開始後、その再生情報（タイトル、ＰＧＣ番号、音声ストリーム番号、サブピクチャストリーム番号、アングル番号、アスペクト比情報、再生時間情報など）を取得し（ステップＳ８４０６）、取得した情報の少なくとも一部（例えばＰＧＣ番号）に基づいて、それに対応するVclickストリームをVclickインフォ・ファイルより検索する（ステップＳ８４０７）。例えば、ステップＳ８４０６で取得した再生情報が図６６におけるＰＧＣ＃１であったとすれば、Vclick#1〜#3のストリームがステップＳ８４０７において検索される。そして、Vclickストリーム#1〜#3のデータが現在バッファ２０９内にあれば（ステップＳ８４０８イエス）、直ぐにVclickストリーム#1〜#3の再生が、現在のＤＶＤ再生（ステップＳ８４０５）と同期して、開始される。
Vclickストリーム#1〜#3のデータが現在バッファ２０９内にないときは（ステップＳ８４０８ノー）、バッファ２０９から不要データを消去して（ステップＳ８４０９）、あるいは不要データのバッファエリアにオーバーライトするようにして、バッファ２０９に、検索されたVclickストリーム#1〜#3のデータが読み込まれる（ステップＳ８４１０）。そして、バッファ２０９に読み込まれるデータ量が最小の再生サイズ（例えば１２ｋバイト）に達したら、そのバッファリングされたVclickストリームの再生が、現在のＤＶＤ再生（ステップＳ８４０５）と同期して、開始される。
なお、ステップＳ８４０３およびステップＳ８４１０におけるバッファ２０９への読み込みにおいては、図４８、図４９に示した“NULL_AU”の部分については、データ転送は行われない（“NULL_AU”であるか否かは、図４８の“Vclick AU Header”内の図示しないフラグで識別できる）。
上記では、VclickストリームＶＣＳ上に“NULL_AU”を配する事で、バッファ２０９からメディア・デコーダ２１６への無用なデータ転送と、その結果生ずるメディア・デコーダ２１６での処理のオーバーヘッドを軽減する方法を記述した。しかし、Vclickアクセス・テーブルＶＣＡを用いてVclickストリームＶＣＳ上のAUにアクセスする場合、VclickストリームＶＣＳ上の“NULL_AU”に代わって、Vclickアクセス・テーブルＶＣＡ上の“NULL Pointer”を用いて、更に無用な処理のオーバーヘッドを回避する事が可能である。以下、これについて述べる。
図４７は“NULL_AU”の説明（図４８〜図４９の説明）に関連した、VclickストリームＶＣＳの例である。図４７のVclickストリームＶＣＳにおいて、アクセスユニットＡＵは#1,#2,#3の順に並べられている。このVclickストリームＶＣＳに対応するVclickアクセス・テーブルＶＣＡは、例えば図６に示すようになっている。図６において、offset#3は、例えば、AU#1の先頭位置、offset#4はAU#3の先頭位置を指している。この図６の構成を前記“NULL Pointer”を用いる場合に拡張すると、図８５のようになる。
図８５は、この発明の他の実施の形態に係るVclickアクセス・テーブルＶＣＡの構成例を説明する図である。図８５の例には、図６と異なり、タイムスタンプ８５０がtime*のとき、該当するアクセスポイント８５１が“NULL”であることを示す場合が追加されている。つまり、この“NULL”であることを示すNULL Pointer（ファイルポインタｆｐの１つ）を利用する場合のVclickアクセス・テーブルＶＣＡが、図８５に例示されている。
図８５のアクセスポイント８５１中の“NULL”は、「当該VclickストリームＶＣＳにおけるＡＵのアクティブ期間は、time*以上time#4未満の時間範囲と交わり（または係わり）を持たない」ことを意味するフラグである。いま、図２のインタフェース・ハンドラ２０７からメタデータ・マネージャ２１０へ与えられる動画像クロックTについて、下記の条件が成立したとする：
time* <= T < time#4
この時、メタデータ・マネージャ２１０は、図８５のVclickアクセス・テーブルＶＣＡを検索して、“NULL”のフラグを得る。“NULL”フラグを得た場合は、メタデータ・マネージャ２１０は、VclickストリームＶＣＳを読み込むことなく、動作を終了するか、或いは、次の動作に移る。この場合のメタデータ・マネージャ２１０の動作の一例を図８６のフローチャートに示す。
図８６は、この発明の他の実施の形態に係るメタデータ・マネージャの処理手順の例を説明するフローチャートである。すなわち、メタデータ・マネージャ２１０がインターフェース・ハンドラ２０７から動画像クロックＴを受け取ると（ステップＳ８６０１）、バッファ２０９内のアクセスポイントテーブルを検索し、 t<= Tである最大のtを求め（ステップＳ８６０２）、 tと組になるoffset値ｈを見出す（ステップＳ８６０３）。見出されたｈが“NULL”であれば（これは、図４７、図４９、図８５の例でいえば、ステップＳ８６０２で求めたｔが“time*”に該当する場合）（ステップＳ８６０４イエス）、ステップＳ８６０１に戻り、ステップＳ８６０１〜Ｓ８６０４の処理を繰り返す。
見出されたｈが“NULL”でなければ（図４７、図４９、図８５の例でいえば、ステップＳ８６０２で求めたｔが例えば“time#4”に該当する場合）（ステップＳ８６０４ノー）、ファイルポインタｆｐをｈとする（ステップＳ８６０５）。そして、インターフェース・ハンドラ２０７は、このｈに対応するアクセスユニットＡＵのタイムスタンプ値t’（図８５の例では、アクセスポイント８５１の“offset#4”に対応する、タイムスタンプ８５０の“time#4”）を読む（ステップＳ８６０６）。
次に、ファイルポインタｆｐを、現在のｆｐに現在のＡＵのサイズを足した値に変更し（ステップＳ８６０７）、変更後のｆｐがVclickインフォ・ファイルの最後を指しているかどうかチェックする。ｆｐがファイルの最後を指していないときは（ステップＳ８６０８ノー）、インターフェース・ハンドラ２０７は現在のＡＵのタイムスタンプ値ｕを読む（ステップＳ８６０９）。そして、読んだタイムスタンプ値ｕが前記タイムスタンプ値t’より大きくなければ（ステップＳ８６１０ノー）、ステップＳ８６０７に戻り、ステップＳ８６０７〜Ｓ８６１０の処理を繰り返す。ｕがt’より大きいとき（ステップＳ８６１０イエス）、あるいはｆｐがファイルの最後を指しているときは（ステップＳ８６０８イエス）、インターフェース・ハンドラ２０７は、バッファ２０９に対して、「オブジェクト・メタデータ・ストリーム（現在のＡＵを含むVclickストリームＶＣＳ）のオフセットｈからファイルポインタｆｐまでのデータを、メタデータ・デコーダ２１７へ転送せよ」との指令を出す（ステップＳ８６１１）。こうして、「“NULL”であることを示すNULL Pointerを利用する場合」のメタデータ・マネージャ２１０の動作例（図８６）は終了する。
図８７はこの発明のさらに他の実施の形態に係るバッファアサインモデルを説明する図（初期化用文書の例）である。以下、実際にVclickデータＶＣＤ用のバッファをアサインするモデルを説明する。図８７の３２２は、図２（または後述する図９１、図９８、図１０４、図１０６）のバッファ２０９に対応するもので、初期化用文書３２０で特定サイズが割り当てられたリングバッファを示す。あるいは、このリングバッファ３２２は、図示しないワークメモリの一部に確保されたバッファリングエリアであってもよい。
ここでは、リングバッファ３２２（図２では２０９）のバッファサイズを定義するため、Loading InformationファイルなどのXML形式で記述された初期化用文書３２０を使用する。XML文書内でのバッファ３２２（図２の２０９に対応）のアサインは、memoryタグのname属性の値をAssignとすることで定義し、また、アサインするサイズはmemoryタグのsize属性の値で定義する（この定義の記載方法は図８７の例では３２１）。この初期化用文書３２０がロードされるたびに、バッファ３２２をアサインする。このとき、指定した量だけバッファ３２２にコンテンツが蓄積した時点を再生開始タイミングとし、その時点から再生を開始する再生開始タイミング判定用定義３２３を付け加えてもよい。この再生開始タイミング判定定義はmemoryタグのname属性をPlaybackとすることで定義し、バッファ３２２のアサインサイズはsize属性の値で定義する。なお、バッファアサイン直後、もしくは利用開始直前までに少なくとも一回、バッファ３２２はフラッシュ初期化しておく（このバッファフラッシュについては図９７を参照して後述する）。
上記初期化用文書３２０は、エンハンスドＤＶＤビデオディスク（図５３のディスク、あるいは図１０３〜図１０６の２３１）においては、VclickデータＶＣＤ内（より具体的には、例えば図５３のVclickインフォＶＣＩ内；図５４ではVCKINDEX.IFOファイル内）に格納することができる。もしくは、初期化用文書３２０は、サーバ上におかれたダウンロード用のVclickデータに格納されていても良い。ディスク上の初期化用文書とサーバ上の初期化用文書が両方存在する場合はサーバ上の初期化用文書を常に参照する。または、バージョン管理によって参照する初期化用文書を決定しても良い。
図８８は、この発明のさらに他の実施の形態に係るバッファアサイン時の処理手順を説明するフローチャートである。ネットワーク接続にてVclickストリームＶＣＳをダウンロードする場合、回線状態によっては十分な速度でダウンロードできない時もある。その場合、無駄なバッファエリアを他のエンジンで利用することもできるので、バッファアサイン時には、以下のような処理を行うとよい：
<1>図８７の初期化用文書３２０よりアサインサイズ３２１と再生開始サイズ３２３を読み出す（ステップＳ８８０１）；
<2>ネットワークからダウンロードするかどうか判定する（ステップＳ８８０２）；
<3>ダウンロードする場合は（ステップＳ８８０２イエス）、現在のネットワークの回線状態を検出する（ステップＳ８８０３）。
<4>検出された回線状態により、バッファのアサインサイズを調整する（ステップＳ８８０４）。たとえば、利用時間帯によってはインターネット回線がビジーで繋がりにくいことがあり、そのときはネットワークからのダウンロードでバッファの内容が更新される前にバッファの内容を読み出し切ってしまう可能性がある。その場合はVclickストリームの再生が途中で途切れる恐れがある。そのようなときは、過去の経験データなどに基づいて、回線状態に応じたバッファサイズを幾つか決めておくことが考えられる。たとえば、回線がいつでも繋がるような状態ではバッファサイズは２Ｍバイトとし、繋がりにくいときは８Ｍバイトとし、その中間状態では４Ｍバイトとする。そして、例えばバッファサイズに８Ｍバイトをアサインしたときは、回線が繋がっているときは、８Ｍバイト目一杯使ってVclickデータをバッファに入れられるだけ入れておく。そうすれば、一度回線が切られ、次に回線が繋がるまでの間にバッファリングしておくVclickデータの量が大きくなるので、Vclickストリームの再生が途中で途切れる恐れが少なくなる。
<5>ダウンロードしない場合は（ステップＳ８８０２ノー）、初期化用文書３２０に記載されたアサインサイズをアサインサイズとして、バッファ３２２をアサインする（ステップＳ８８０５）；
<6>アサインサイズ分バッファ３２２をアサインする（ステップＳ８８０６）。
以上のように、初期化用文書３２０に記述されたアサインサイズを利用するか、回線状態によりアサインサイズを調整するかどうかの判断をする処理が可能である。また、回線状態によってアサインサイズを変更（図８７では３２１のサイズを変更）した場合において、「再生開始タイミングが指定された」コンテンツであった場合（図８７では３２３のサイズ指定がある場合）は、それに応じて、少なくとも“「変更されたアサインサイズ」≧「再生開始タイミング時の蓄積コンテンツサイズ」”となるように再生開始タイミング時の蓄積コンテンツサイズも変更する。
そうすれば、「再生開始タイミング時の蓄積コンテンツサイズ」も考慮して「変更されたアサインサイズ」を水増しする（例えばバッファアサインサイズを回線状態に応じて４Ｍバイトから２Ｍバイトに変更したが、そのときに再生開始タイミングが３Ｍバイトと指定されていたら、実際のバッファアサインサイズは少なくとも１Ｍバイト水増しして３Ｍバイト以上とする）といった必要性が無くなる。すなわち、この場合では図８７の再生開始サイズ３２３を２Ｍバイト以下に変更することになる。これによって無駄なバッファエリア（上記の例では１Ｍバイト分）を他のエンジンで利用することができるようになる。
また、ネットワークの状態によって、同様に再生開始タイミング時のアサインサイズのみを調整することもできる。すなわち、“「現在のアサインサイズ」≧「再生開始タイミング時の蓄積コンテンツサイズ」”となるように、図８７の再生開始サイズ（再生開始タイミング判定用定義）３２３の記述を変更する（現在のサイズ指定３２３よりも指定サイズを小さくする）。この場合は、再生開始までのVclickデータのバッファへのロード時間を短縮することができる。
図８９は、この発明のさらに他の実施の形態に係るバッファの使用例を説明する図である。図８９には、バッファ３２２（図２、図９１等では２０９）の使用量の変化が例示されている（ここでは、バッファ作成から実際のデータの書込み開始までの処理過程は省略されている）。
実際にバッファ３２２（または２０９）へデータ書込みが始まった直後、図８７に示す初期化用文書３２０内の再生開始タイミング判定用定義３２３に記載されたサイズ分（もしくは再生機器によって定義された分）３２３だけ一定量バッファ３２２にデータがたまるまでは再生は開始されない（図８９の再生開始待ち状態３２４部分）。この再生が開始されるタイミングは、サーバ〜クライアント間の接続を開始してからの時間（ダウンロードを始めてからの時間）、またはバッファ３２２（または２０９）にコンテンツがどれだけ蓄積されたかのいずれかによって定義することができる。
サーバ〜クライアント間の接続が確立されてからの時間を使う場合は、ダウンロード速度とバッファ３２２（または２０９）容量によってその時間を決定する。この時間は、回線が切断されるなどのエラーによって再度接続が必要になった場合で、バッファ３２２内に蓄積されたコンテンツを使用して再度接続を確立してダウンロードを開始するようになった場合でも、再生が途切れない程度のコンテンツ（Vclickデータ）をバッファ３２２内にダウンロードできる時間であり、この時間は、再生機器側で定義し決定する。この場合は再生機器側で時間を定義することで環境に応じたそれぞれのスループットに最適な時間を定義することができる。
また、上記の時間をバッファ３２２（または２０９）内コンテンツ蓄積量で判断する場合は、次のようにすればよい。すなわち、回線が切断されるなどのエラーによって再度回線接続が必要になった場合でもバッファ３２２内に蓄積されたコンテンツを使用して再度接続を確立してダウンロードを開始するまで再生が途切れない程度のコンテンツをバッファ３２２内に蓄積している蓄積量で、上記の時間を定義する。
ここで、この実施の形態に適用される規格（EnhancedＤＶＤ規格あるいはＥＤＶＤ規格）において最低スループットが規定（例えば128kbps）されているときは、「再生が途切れない程度のコンテンツをバッファ３２２内に蓄積している蓄積量で定義する」ことは、機器（プレーヤ）側での定義の他に、コンテンツの再生開始タイミングに定義しておくことが可能となる。
その後、再生開始時からは「データの書込み」と「データの再生のための読出し」が平行して行われる（図８９の再生初期状態３２５部分）。バッファへのダウンロード速度がバッファからの再生利用量より十分早い場合には、バッファ３２２は徐々に使用量を増加させていく（図８９の状態３２５内の右肩上がりカーブ参照）。しかしまだバッファ３２２は一杯にならない。バッファ３２２内のデータが初期化用文書３２０内のアサインサイズ３２１まで増加した後（図８９のバッファフル状態３２６部分）は、時間の経過にともないバッファ３２２使用量はアプリケーションで利用したデータ分の減少とデータ読み込みによる増加を繰り返すため、図８９のバッファフル状態３２６内の実線カーブ部分のように微小な増減を繰り返すことになる。
図９０および図９２〜図９６は、この発明のさらに他の実施の形態に係るリングバッファの利用例を説明する図である。ここではバッファ３２２（図２、図９１他では２０９）を決められたサイズ分で利用するので、リングバッファとして利用している。その利用方法を以下に示す。
図９０ではバッファ３２２を連続したものと考え、図中では円３２７にて示す。円を左周り（反時計回り）３２８に新しく受信したデータを記録していくように利用する。現在受信完了位置３３１から左周りに受信したVclickストリームＶＣＳを記録３２９し、現在再生位置３３２からも左周りでVclickストリームＶＣＳを必要になる都度、送出３３０していく。
このような利用方法において、例えば図８９の再生開始待ち状態３２４および再生初期状態３２５では、図９２のように現在再生位置３３２から左、現在受信完了位置３３１までの領域３４１ａはデータが書き込まれている状態で、現在受信完了位置３３１から右、現在再生位置３３２までの領域３４１はデータが書き込まれていない状態となる。次にある程度時間がたつとバッファ３２２（２０９）への書込みが、再生による読出しに追いついてしまいバッファフル状態（図８９の３２６部分）になる。すると、図９３に示されるように、現在再生位置３３１が現在受信完了位置３３２に近くなる。その後は「再生による読出し」で使用した分だけ、「書込み」を行うので、バッファ３２２使用量は微少な上下動を繰り返す。
以上のようなリングバッファ３２２を図２のバッファ２０９にあてはめて対応をとると、例えば以下のようになる。すなわち、VclickストリームＶＣＳに含まれるアクセスユニットＡＵのタイムスタンプは昇順に並んでいる。図２のインターフェース・ハンドラ２０７は、メタデータ・マネージャ２１０に対して、ある動画像クロック値Ｔを送る。すると、メタデータ・マネージャ２１０は、受け取ったクロック値Ｔを含むアクセスユニットＡＵをバッファ２０９（図８７では３２２）から検索する。該当するＡＵが検索されると、当該ＡＵはバッファ２０９からメディアデコーダ２１７に転送される。この転送に伴い、当該ＡＵが読み込まれた以前にバッファ２０９に読み込まれた（古い）ＡＵが占める領域をバッファ２０９から解放する。この解放されたバッファエリアは、図９２では領域３４１に対応する。メタデータ・マネージャ２１０は、解放された領域の総バイト数分だけVclickストリームＶＣＳをネットワーク２２１から読み込むように、バッファ２０９に指示を出す。もしくは、メタデータ・マネージャ２１０はインターフェースハンドラ２０７を介してネットワーク・マネージャ２０８に解放された領域の総バイト数分だけVclickストリームＶＣＳをネットワーク２２１から読み込むように指示を出す。
図９１は、この発明のさらに他の実施の形態に係る「再生による読出し」おおび「書込み」のアルゴリズムを説明する図である。インターフェース・ハンドラ２０７よりメタデータ・マネージャ２１０に対して、ある動画像クロック値３３３を送る。メタデータ・マネージャ２１０は受け取ったクロック値３３３を含むＡＵを検索する。このとき、インターフェース・ハンドラ２０７からの動画像クロックの値から判断して、ＡＵに重複がある場合は、メタデータ・マネージャ２１０で丸め込んでもよい（具体的には、重複のあるＡＵはそのうちの１つのＡＵの情報を用いる）。メタデータ・マネージャ２１０は該当するＡＵデータ３３４をバッファ２０９（図８７では３２２）より読出し、メディアデコーダ２１６に該当データ３３５を送出する。送出後、インターフェース・ハンドラ２０７に送出した総バイト数３３６を通知する。インターフェース・ハンドラ２０７は送出した総バイト数３３６と等しいバイト数３３７を読込みよう、ネットワークマネージャ２０８に通知する。すると、ネットワークマネージャ２０８は、指示されたバイト数分、サーバ２０１からVclickストリームＶＣＳを取り出し、バッファ２０９（３２２）に書き込む３３８。また、ネットワークマネージャ２０８は、書き込んだバイト数３３９をインターネットハンドラ２０７に通知する。以上の操作を必要都度繰り返す。これが基本モデルである。
次に、図９４〜図９６を参照して特殊なバッファモデルを説明する。このモデルでは、「現在受信完了位置３３１」と「現在再生位置３３２」に隔たりを持たせ、意図的に「現在再生位置よりも過去のデータを保持しておく」ようにしている。こうすることで、特殊再生時にユーザオペレーションに対する使用感あるいはレスポンスを改善している。仮に０．５ｍｓ毎のVclick_AUが２時間分あったとする。そのとき画面上には常に２つの対象オブジェクトが表示される場合、VclickストリームＶＣＳのサイズは約７Mbyteとなる。またアサインされたバッファ３２２（図２、図９１他では２０９）を２Mbyteとしたとして、図９４の場合、意図的に２５％のバッファを過去データ３４３として利用する。上記の条件であれば約８．５分のVclickストリームＶＣＳがバッファにストックされている計算になる。仮に巻き戻し再生を行っても、過去分のデータがバッファに保持されているので、動画像の巻き戻し再生と同時再生されるVclickデータの再生も途切れることなく、ユーザへの使用感あるいはレスポンス性能を向上させることができる。
上記と同じ条件であれば、図９５は意図的に５０％のバッファを過去データ３４３として利用する。上記の条件であれば約１７分のVclickストリームＶＣＳがバッファにストックされている計算になる。仮に巻き戻しを想定した場合、より多くの過去分データを保持しておくことにより、動画像の巻き戻し再生と同時再生されるVclickデータの再生も長時間途切れることなく、ユーザへの使用感あるいはレスポンス性能を向上させることが可能となる。
また、図９６の例では、意図的に７５％のバッファを過去データ３４３として利用する。上記の条件であれば約２５．５分のVclickストリームＶＣＳがバッファにストックされている計算になる。仮に巻き戻しを想定した場合、さらに多くの過去分データを保持しておくことにより、動画像の巻き戻し再生と同時再生されるVclickデータの再生もさらに長時間途切れることなく、ユーザへの使用感あるいはレスポンス性能を向上させることが可能となる。
図９７は、この発明のさらに他の実施の形態に係るバッファフラッシュ（初期化）時の処理手順（バッファフラッシュモデル）を説明するフローチャートである。すなわち、インターフェース・ハンドラ２０７からフラッシュ指示を受信してから（ステップＳ９７０１）、バッファ２０９をフラッシュ（消去）する（ステップＳ９７０２）。このバッファフラッシュは、以下のタイミングで行うことができる：
（a）初期化用文書によるバッファ生成時；
（b）再生中の映像の未来もしくは過去へのジャンプ操作（バッファ上に映像データがない場合）；
（c）回線切断時（ストリーム取得先変更等、意図的な回線切断）…コネクションをクローズしたら、バッファをクリア。
換言すれば、バッファ（図２の２０９；図８７の３２２）以外へのデータアクセスが発生する場合に、このバッファはクリアまたはフラッシュされる（ステップＳ９７０２）。
図９８は、この発明のさらに他の実施の形態に係る「バッファクリア時のシーケンス」を説明する図である。この例では、バッファフラッシュのタイミングはインターフェース・ハンドラ２０７より通知され、インターフェース・ハンドラ２０７からメタデータ・マネージャ２１０に通知がある都度、バッファ２０９のフラッシュが行なわれる。
図９９は、この発明のさらに他の実施の形態に係る「Get連続発行による特殊再生」（イベント発生の都度Vclickデータを要求するモデル）を説明する図である。ここでは、仮に回線を切断し、再度VclickストリームＶＣＳをダウンロードする場合のモデルを示している。インターフェース・ハンドラ２０７よりネットワークマネージャ２０８に対して回線切断指示３４６（図９８）を出す。ネットワークマネージャ２０８は回線断処理完了後、インターフェース・ハンドラ２０７に回線切断完了通知３４７（図９８）を送信する。その後インターフェース・ハンドラ２０７はメタデータ・マネージャ２１０にバッファ２０９のクリア指示３４４（図９８）を出す。メタデータ・マネージャ２１０は、クリア完了後、インターフェース・ハンドラ２０７にクリア完了通知３５２（図９８）を送信する。その後、回線再接続が必要であれば、インターフェース・ハンドラ２０７は、ネットワークマネージャ２０８に対し、回線接続通知３４９（図９８）を送信し、接続完了後、回線接続完了通知３５０（図９８）を受信する。その後は必要な処理を行う。
またＨＴＴＰプロトコルには（Keep aliveの説明）接続を保ったままであれば、HTTP:GETメソッドが発行された順にデータを送り、メソッドの発行タイミングによりデータの送付は前後しないという特性があり、これをKeep Alive特性という。このKeep Alive特性を利用すると以下のような動作が可能となる。すなわち、Keep Alive特性はバッファのフラッシュを行わなければ情報が途切れることはない。かつ情報が前後することもないので、イベントが発生する都度、HTTP:GETメソッドを発行すれば、VclickストリームＶＣＳが順次ダウンロードされる（図９９）。
図１００は、この発明のさらに他の実施の形態に係る「Get連続発行による特殊再生」（予めイベント発生順が分かっているモデル）を説明する図である。ここで、イベントの発生順が予め分かっているときは、一度にHTTP:GETメソッドを発行してもよい。このKeep Alive特性を利用することにより、VclickストリームＶＣＳを任意の順にダウンロードし、シャッフル再生やランダム再生を行なうことができる。
図１０１は、この発明のさらに他の実施の形態に係る「早送り再生時のバッファ状態」を説明する図である。早送り（ＦＦ）あるいは早戻し（ＦＲ）再生時はＤＶＤコンテンツの再生ペースが早まるので、これと同期するバッファ２０９からのメタデータの読み出しペースも早くなり、バッファ２０９にバッファリングされているメタデータの消費が早くなる。バッファ２０９へのメタデータの補充がこの高速消費に追いつかなくなると、場合によってはバッファ２０９が一時的に空になってしまう。すると、再びバッファ２０９に最低限のメタデータ（例えば図８７の３２３に記述されるサイズのデータ）がバッファリングされるまで待ち時間が生じることになり、早いＤＶＤ再生速度に対してバッファ２０９からのメタデータの供給が追いつけずに、両者間の再生同期関係が成立しなくなる。
この問題は、早送りあるいは早戻し再生時におけるバッファリングでは、メタデータ（Vclickデータ）の読み飛ばしを行うようにアプリケーション（制御ファームウエア）を組むことで、解決できる。例えば、０．１秒毎に１０秒分バッファリングしたときのデータ量は、読み飛ばしして例えば１秒毎に１００秒分バッファリングしたときと同じになる。この場合、１０倍速のＦＦ／ＦＲ再生に合わせてバッファ２０９からメタデータの読み出しがなされても、再生時間ベースでみれば、バッファ２０９のデータ消費レートは、見かけ上、読み飛ばしをしない場合の１倍速の通常再生時の消費レートと同じになる。このようにして、バッファ２０９へのメタデータのバッファリングが早いＤＶＤ再生速度に追いつけるように考慮すれば、上記の問題は解決できる。
図１０１では、実線三角カーブで、上記読み飛ばしがない（あるいは読み飛ばしの間隔が不十分）な場合のバッファ２０９のデータ消費状態を例示している。この場合は、早いＤＶＤ再生に合わせてバッファ２０９内のメタデータが短時間に消費されてしまうので、バッファ２０９にバッファリングされているメタデータ量の増減が激しくなる。一方、図１０１の破線三角カーブは、適切な読み飛ばしが行われてバッファリングが再生速度に実用上問題なく追いついている場合の、バッファ２０９のデータ消費状態を例示している。
図１０２は、この発明のさらに他の実施の形態に係る「早送りまたは早戻し再生時のアクセスユニットの取り扱い方法（早送り／早戻しモデル）」を説明する図である。早送り時は、メタデータマネージャ２１０が、バッファ２０９からメディアデコーダ２１６に転送するＡＵを間引く。インターフェース・ハンドラ２０７は、メタデータ・マネージャ２１０に対して、動画像クロック（Ｔ）３５３、３５６を送る。メタデータ・マネージャ２１０は、受け取ったクロックTに適当な時間α３５４とβ３５５（ただしα＞β）を加えた時刻を計算し、時刻T+βから時刻T+αに含まれるタイムスタンプを有するＡＵ（図１０２ではＡＵ２とＡＵ５）をメディアデコーダ２１６に転送するように指示を出す。かつ、送出したサイズ分をネットワークから読み込むように指示を出す。αとβの値は早送り速度に依存して定めることができる。こうすることで、早送り時のＡＵを速度に応じて必要分転送することができ、早送り再生時にも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データがサーバ装置にある場合）。 この発明の一実施の形態に係る通常再生の終了処理手順を説明するフローチャート図（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情報の記述例２を説明する図。 この発明の一実施の形態に係る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アクセスユニットの継続時間のデータ構造を説明する図。 この発明の一実施の形態に係るVclick情報の記述例８を説明する図。 この発明の一実施の形態に係るVclick情報の記述例９を説明する図。 この発明の他の実施の形態に係る再生処理手順を説明するフローチャート図。 この発明の他の実施の形態に係るVclickストリーム（マルチストリーム）の構成方法を説明する図。 この発明の他の実施の形態に係る起動処理手順を説明するフローチャート図。 この発明の他の実施の形態に係るVclickアクセス・テーブルの構成例を説明する図。 この発明の他の実施の形態に係るメタデータ・マネージャの処理手順の例を説明するフローチャート図。 この発明のさらに他の実施の形態に係るバッファアサインモデルを説明する図（初期化用文書の例）。 この発明のさらに他の実施の形態に係るバッファアサイン時の処理手順を説明するフローチャート図。 この発明のさらに他の実施の形態に係るバッファの使用例を説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その１）を説明する図。 この発明のさらに他の実施の形態に係る「再生による読出し」おおび「書込み」のアルゴリズムを説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その２）を説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その３）を説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その４）を説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その５）を説明する図。 この発明のさらに他の実施の形態に係るリングバッファの利用例（その６）を説明する図。 この発明のさらに他の実施の形態に係るバッファフラッシュ（初期化）時の処理手順を説明するフローチャート図。 この発明のさらに他の実施の形態に係る「バッファクリア時のシーケンス」を説明する図。 この発明のさらに他の実施の形態に係る「Get連続発行による特殊再生」（イベント発生の都度Vclickデータを要求するモデル）を説明する図。 この発明のさらに他の実施の形態に係る「Get連続発行による特殊再生」（予めイベント発生順が分かっているモデル）を説明する図。 この発明のさらに他の実施の形態に係る「早送り再生時のバッファ状態」を説明する図。 この発明のさらに他の実施の形態に係る「早送りまたは早戻し再生時のアクセスユニットの取り扱い方法」を説明する図。 この発明のさらに他の実施の形態に係る「Vclickストリームが動画像データ記録媒体上にあったときのモデル」（シームレス再生を保証する場合）を説明する図。 図１０３のモデルにおける処理を説明する図。 この発明のさらに他の実施の形態に係る「Vclickストリームが動画像データ記録媒体上にあったときのモデル」（シームレス再生を保証しない場合）を説明する図。 図１０５のモデルにおける処理を説明する図。
符号の説明
２００…クライアント装置；２０１…サーバ装置；２０２…Vclickエンジン；２０３…動画再生エンジン；２０９、３２２…バッファ（リングバッファ）；２２１…サーバ装置とクライアント装置を結ぶネットワーク；３０１〜３０５…Vclickアクセスユニット；４００…Vclickアクセスユニットのオブジェクト領域データ；４０１…Vclickアクセスユニットのヘッダ；４０２…Vclickアクセスユニットのタイムスタンプ；４０３…Vclickアクセスユニットのオブジェクト属性情報。

Claims (11)

  1. ビデオコンテンツの再生に伴って再生可能な動画像のメタデータを有するものであって、独立に処理可能なデータ単位であるアクセスユニットで構成されるストリームを含むデータ構造において、
    前記データ構造が、前記メタデータの再生時に用いるバッファのサイズを指定するバッファサイズ情報の記述を含む初期化情報を備えるように構成されたデータ構造。
  2. 前記初期化情報が、前記バッファにどのくらいのデータがバッファリングされたら再生開始するかを指定する再生サイズ情報の記述を含むように構成された請求項１に記載のデータ構造。
  3. 前記バッファサイズ情報の記述および前記再生サイズ情報の記述により指定されるバッファサイズは可変であり、前記バッファサイズ情報の記述によりバッファサイズが変更された場合は、この変更後のバッファサイズ以下となるように、前記再生サイズ情報の記述により指定されるバッファサイズが変更されるように構成された請求項２に記載のデータ構造。
  4. 前記初期化情報における前記バッファサイズ情報の記述が、現在の前記メタデータの再生位置からみて、時間的に過去のデータも含めてバッファリングできるようなサイズを記述するように構成された請求項１ないし請求項３のいずれか１項に記載のデータ構造。
  5. 前記バッファ以外へのデータアクセスが発生する場合に前記バッファをクリアまたはフラッシュするように構成された請求項１ないし請求項４のいずれか１項に記載のデータ構造。
  6. 前記ビデオコンテンツの情報を格納するエリアと、前記動画像メタデータを含む情報を格納するエリアとを持ち、請求項１ないし請求項５のいずれか１項に記載のデータ構造を用いて情報記録がなされるように構成された情報媒体。
  7. 請求項１ないし請求項５のいずれか１項に記載のデータ構造を用いて情報記録がなされた情報媒体から、前記ビデオコンテンツを再生するとともに、前記動画像メタデータを適宜再生するように構成された再生装置。
  8. ビデオコンテンツを含む情報の記録がなされた情報媒体から前記ビデオコンテンツを再生するとともに、この媒体以外から、請求項１ないし請求項５のいずれか１項に記載のデータ構造を用いて前記アクセスユニットで構成されるストリームを含む前記データ構造の情報を読み取って、前記動画像メタデータを適宜再生するように構成された再生装置。
  9. 請求項１ないし請求項５のいずれか１項に記載のデータ構造を用いて情報記録がなされた情報媒体から、前記ビデオコンテンツを再生するとともに、前記動画像メタデータを適宜再生するように構成された再生方法。
  10. ビデオコンテンツを含む情報の記録がなされた情報媒体から前記ビデオコンテンツを再生するとともに、この媒体以外から、請求項１ないし請求項５のいずれか１項に記載のデータ構造を用いて前記アクセスユニットで構成されるストリームを含む前記データ構造の情報を読み取って、前記動画像メタデータを適宜再生するように構成された再生方法。
  11. ビデオコンテンツの再生に伴って再生可能な動画像メタデータを有するものであって、独立に処理可能なデータ単位であるアクセスユニットで構成されるストリームを含むデータ構造。
JP2004136687A 2004-04-30 2004-04-30 動画像のメタデータ Pending JP2005318471A (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2004136687A JP2005318471A (ja) 2004-04-30 2004-04-30 動画像のメタデータ
TW094112303A TWI286295B (en) 2004-04-30 2005-04-18 Meta data for moving picture
EP05103130A EP1592020A3 (en) 2004-04-30 2005-04-19 Meta data for moving picture
US11/116,321 US20050244147A1 (en) 2004-04-30 2005-04-28 Meta data for moving picture
KR1020050036431A KR100676432B1 (ko) 2004-04-30 2005-04-29 동화상의 메타 데이터
CNA2005100670907A CN1708115A (zh) 2004-04-30 2005-04-29 用于运动图像的元数据

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004136687A JP2005318471A (ja) 2004-04-30 2004-04-30 動画像のメタデータ

Publications (1)

Publication Number Publication Date
JP2005318471A true JP2005318471A (ja) 2005-11-10

Family

ID=34939384

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004136687A Pending JP2005318471A (ja) 2004-04-30 2004-04-30 動画像のメタデータ

Country Status (6)

Country Link
US (1) US20050244147A1 (ja)
EP (1) EP1592020A3 (ja)
JP (1) JP2005318471A (ja)
KR (1) KR100676432B1 (ja)
CN (1) CN1708115A (ja)
TW (1) TWI286295B (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU771770B2 (en) * 2000-06-14 2004-04-01 Sap Aktiengesellschaft Communication between client and server computers via HTTP, method, computer program product and system
JP2004296065A (ja) * 2003-03-10 2004-10-21 Toshiba Corp 情報記憶媒体、情報再生装置、および情報再生方法
JP2005332274A (ja) * 2004-05-20 2005-12-02 Toshiba Corp 動画像中のオブジェクトに関するメタデータストリームのデータ構造、検索方法及び再生方法
JP4600248B2 (ja) * 2005-11-07 2010-12-15 ソニー株式会社 データ通信システム及びデータ通信方法
US20080159724A1 (en) * 2006-12-27 2008-07-03 Disney Enterprises, Inc. Method and system for inputting and displaying commentary information with content
JP4345830B2 (ja) * 2007-03-09 2009-10-14 ソニー株式会社 情報記録装置、および情報記録方法
US7890556B2 (en) * 2007-04-04 2011-02-15 Sony Corporation Content recording apparatus, content playback apparatus, content playback system, image capturing apparatus, processing method for the content recording apparatus, the content playback apparatus, the content playback system, and the image capturing apparatus, and program
KR101206698B1 (ko) * 2010-10-06 2012-11-30 한국항공대학교산학협력단 스트리밍 콘텐츠 제공 장치 및 방법
TWI571789B (zh) * 2012-03-06 2017-02-21 敦泰電子股份有限公司 電容式觸控螢幕的控制系統及方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR19990032182A (ko) * 1997-10-16 1999-05-06 정선종 가변길이 파일의 버퍼 관리 장치 및 그 방법
AU2003220332A1 (en) * 2002-03-15 2003-09-29 Metatv System and method for construction, delivery and display of itv content
WO2004019602A2 (en) * 2002-08-21 2004-03-04 Disney Enterprises, Inc. Digital home movie library
JP2006041844A (ja) * 2004-07-26 2006-02-09 Toshiba Corp メタデータのデータ構造及びそのメタデータの処理方法

Also Published As

Publication number Publication date
TW200537394A (en) 2005-11-16
TWI286295B (en) 2007-09-01
KR20060047667A (ko) 2006-05-18
EP1592020A3 (en) 2005-11-09
EP1592020A2 (en) 2005-11-02
CN1708115A (zh) 2005-12-14
KR100676432B1 (ko) 2007-02-01
US20050244147A1 (en) 2005-11-03

Similar Documents

Publication Publication Date Title
KR100676433B1 (ko) 동화상의 메타 데이터
KR100679003B1 (ko) 동화상의 메타 데이터
AU2005246159B2 (en) Data structure of meta data stream on object in moving picture, and search method and playback method therefore
US7461082B2 (en) Data structure of metadata and reproduction method of the same
US20080104123A1 (en) Data structure of metadata and reproduction method of the same
KR100676432B1 (ko) 동화상의 메타 데이터
JP2005285209A (ja) 動画像のメタデータ
JP2006099671A (ja) 動画像のメタデータの検索テーブル
JP4008951B2 (ja) メタデータストリームを再生するための装置及びプログラム
US20060053150A1 (en) Data structure of metadata relevant to moving image
JP2006050105A (ja) メタデータの構造及びその再生装置と方法
US7555494B2 (en) Reproducing a moving image in a media stream
JP2006005682A (ja) 動画像のメタデータのデータ構造及びその再生方法
JP4133982B2 (ja) メタデータと動画像の再生装置
US20060085479A1 (en) Structure of metadata and processing method of the metadata
JP2006041844A (ja) メタデータのデータ構造及びそのメタデータの処理方法
JP2006113632A (ja) メタデータのデータ構造及びメタデータの再生装置とその方法
JP2006080918A (ja) メタデータのデータ構造及びメタデータの再生装置と方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061114

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080829

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080909

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090120