JP2006005682A - 動画像のメタデータのデータ構造及びその再生方法 - Google Patents

Abstract

【課題】動画像データと同様に、動画像のメタデータもバッファオーバーフローやアンダーフローが生じないようにバッファサイズや再生開始前のデータバッファリングサイズを決定する必要がある。
【解決手段】動画像のメタデータにおいて、バッファ内のデータ量のダイナミックレンジを記述し、バッファサイズ及びメタデータの再生開始前のデータバッファリングサイズをこのダイナミックレンジにより決定する。
【選択図】 図５６

Description

本発明は、クライアント装置にある動画像データと、クライアント装置もしくはネットワーク上のサーバー装置にあるメタデータとを組み合わせて動画像ハイパーメディアを実現したり、また動画像にテロップや吹き出しを表示したりするためのメタデータのデータ構造及びその再生方法に関する。

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

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

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

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

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

さらに、メタデータはバッファオーバーフローやアンダーフローが生じないようにバッファサイズや再生開始前のデータバッファリングサイズを決定できることが必要である。
特開２０００−２８５２５３公報 特開２００１−１１１９９６公報

視聴者の手元にある動画像に関連したメタデータであり、ネットワークを介して視聴者の元にストリーミング配信されたり、視聴者の元にあって再生されたりするメタデータに於いては、データの転送速度や使用するネットワークプロトコルに応じて、バッファサイズや再生開始前のデータバッファリングサイズを決定できることが望まれる。

そこで、本発明は、上記問題点に鑑み、データの転送速度や使用するネットワークプロトコルに応じて、バッファサイズや再生開始前のデータバッファリングサイズを決定できる発明を提供する。

本実施形態は、動画像に関連したメタデータであって、かつ、前記メタデータの再生まではバッファ内に一時的に蓄積されるものである。

前記メタデータ（そのデータ構造）は、独立して処理可能なデータ単位であるアクセスユニットを、一つまたは複数含むことにより構成される。

ここで、アクセスユニット（図４のVclick_AU）は、動画像の時間軸に対して定義される有効期間内に関する情報として、前記有効期間を特定する第１データ（４０２）と、前記動画像中の時空間領域を記述したオブジェクト領域データ（４００）と、前記時空間領域に関連した表示方法を特定するデータ及び前記時空間領域を指定された際に行う処理を特定するデータのうちの少なくとも１つを含む第２データ（４０３）を含んで構成される。

さらに、動画像メタデータに、一定速度でバッファにメタデータが入力される場合には、バッファ内のデータ量のダイナミックレンジを記述し、メタデータの再生開始前のデータバッファリングサイズをこのダイナミックレンジのサイズとし、さらにバッファサイズをダイナミックレンジの２倍以上とする。

さらに、動画像メタデータに、一定速度で入力、または、入力が停止される状態でバッファにメタデータが入力される場合には、バッファ内のデータ量の最小ダイナミックレンジを記述し、メタデータの再生開始前のデータバッファリングサイズをこのダイナミックレンジのサイズとし、さらにバッファサイズをダイナミックレンジ以上とする。

動画像に同期させたメタデータ再生に於いて、バッファオーバーフロー、アンダーフローが生じないことが保証できる。さらにストリームごとに適切なバッファサイズを決めるので無駄がなく、また、再生開始までの待ち時間が小さくなる。バッファサイズが少なくて済む場合には、記録媒体を他の用途に利用することもできる。

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

（１）アプリケーションの概要
図１は、本実施例のオブジェクト・メタデータを動画像と共に利用することにより実現されるアプリケーション（動画像ハイパーメディア）の画面上の表示例である。

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

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

図４４は、本実施例のVclickデータを動画像と共に利用することにより実現されるアプリケーション（動画像ハイパーメディア）の図１とは別の画面上の表示例である。

図１では動画像、関連情報を表示するウインドウはそれぞれ別々であったが、図４４では一つのウインドウＡ０１に動画像Ａ０２と関連情報Ａ０３が表示されている。関連情報としてテキストのみでなく、静止画Ａ０４やＡ０２とは別の動画像を表示させることも可能である。

以下ではこれらのアプリケーションがどのように実現されるかについて詳細に説明する。

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

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

動画像データ記録媒体２３１に記録された動画像データに関連したVclickデータは、動
画像データ記録媒体２３１に動画像データと共に記録されている場合と、サーバー装置２０１のメタデータ記録媒体２１９に記録されている場合とがある。Vclickデータがサーバー装置２０１に存在する場合、クライアント装置２００はこのVclickデータとディスク装置２３０にある動画像データとを利用した再生を以下のように行うことが可能である。まず、サーバー装置２０１はクライアント装置２００からの要求によりネットワーク２２１を介してクライアント装置２００にVclickデータを含むメディアデータＭ１を送る。クライアント装置２００では、送られてきたVcilckデータを動画像の再生と同期させて処理することでハイパーメディアなどの付加機能を実現させる。

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

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

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

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

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

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

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

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

バッファ２０９は、ネットワークを介して（ネットワーク・マネージャー経由で）サーバー装置２０１から送られてきたVclickデータ等のメディアデータＭ１を一時的に蓄積する。なお、動画像データ記録媒体２３１にメディアデータＭ２が記録されている場合にも、同様にディスク装置マネージャー経由でバッファ２０９へメディアデータＭ２を蓄積する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＥＮＡＶコンテンツは、音声、静止画、フォント・テキスト、動画、アニメーション、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情報ファイルを構成するファイル（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データの構造とその構成要素の概要について説明する。

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

図３はオブジェクト領域データの構造を説明する図である。３００は、１つのオブジェクトの領域が描く軌跡をＸ（映像の水平方向の座標値）、Ｙ（映像の垂直方向の座標値）、Ｔ（映像の時刻）の３次元座標上に表現したものである。オブジェクト領域は予め決められた範囲内の時間（例えば０．５秒から１．０秒の間や、２秒から５秒の間、など）ごとにオブジェクト領域データに変換される。図３では１つのオブジェクト領域３００が３０１から３０５の５つのオブジェクト領域データに変換されており、これらオブジェクト領域データは別々の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データがある場合、動画像が先頭から再生される場合にはサーバー装置２０１は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は、動画像記録媒体に記録された動画像のタイムスタンプの形式を有する時刻情報である。例えば、動画像がMPEG-2で圧縮されて記録されているなら、timeはMPEG-2のPTSの形式をとる。更に、動画像が、例えばＤＶＤのように、タイトルやプログラム・チェーンなどのナビゲーション構造を持つ場合、それらを表現するパラメータ（TTN、VTS_TTN、TT_PGCN、PTTNなど）がtimeの形式に含まれる。タイムスタンプの値は昇順または降順に並べられている。例えば、タイムスタンプとしてPTSが用いられている場合には時刻の順に並べることができる。ＤＶＤのパラメータを含むタイムスタンプについても、ＤＶＤの自然な再生順序に従って順序関係を定義できるため、タイムスタンプを順番に並べることが可能である。

図６のVclickアクセス・テーブルにおいて、アクセスポイントoffsetはVclickストリーム上の位置を指し示す。例えば、Vclickストリームはファイルであり、offsetは当該ファイルのファイル・ポインタの値を指し示す。タイムスタンプtimeと組になっているアクセスポイントoffsetの関係は次のようになっている：
ｉ）offsetの示す位置は、あるVclick_AUの先頭位置である。

ii）当該ＡＵがもつタイムスタンプの値は、timeの値以下である。

iii）当該ＡＵより一つ前にあるＡＵがもつタイムスタンプの値は、timeより真に小さい。

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

次にサーバー装置・クライアント装置間のプロトコルについて説明する。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データがサーバー装置にある場合の再生手順
次に、Vclickストリームがサーバー装置２０１上にある場合における再生処理の手順について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、動画像の再生中の処理と動画像停止処理は通常の再生処理の場合と同一であるため、説明は省略する。

（７）Vclickデータがクライアント装置にある場合の再生手順
次に、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ストリームをデコードしており、従ってクリックされた時のタイムスタンプにおけるオブジェクトの領域が生成されているため、この処理は容易に実行できる。クリックされた座標に複数のオブジェクト領域が存在する場合には、Vclick_AU内に含まれる階層情報を参照して最も前面にあるオブジェクトを特定する。

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

（１０）データ構造の詳細
次に、より具体的なデータ構造の構成例について説明する。図５で説明したとおり、Vclickストリーム５０６はVclickストリームのヘッダと複数のVclick AUから成る。図１１はVclickストリームのヘッダのデータ構造の例である。各データ要素の意味は以下の通りである。

vclick_versionは、Vclickストリームのヘッダの始まりを示すとともに、フォーマットのバージョンを指定する。

vclick_lengthは、このVclickストリームにおけるvclick_lengthより後の部分のデータ長をバイトで指定する。

次に、Vclick AUの詳細なデータ構造を説明する。Vclick AUの大まかなデータ構造は図４で説明したとおりである。

図１２はVclick AUのヘッダ４０１のデータ構造の例である。各データ要素の意味は以下の通りである。

vu_start_codeは、各Vclick_AUの始まりを示す。

vau_lengthは、このVclick_AUのヘッダにおけるvau_lengthより後の部分のデータ長をバイトで指定する。

vau_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"となる。２番目のビットは同様に、このVclick_AUに記述されたオブジェクト領域と、同一のobject_idを有する次のVclick_AUに記述されたオブジェクト領域との連続性を示す。

layerは、オブジェクトの階層値を表す。階層値が大きい（または小さい）ほどオブジェクトが画面上で手前にあることを意味する。クリックされた場所に複数のオブジェクトが存在する場合には、最も会装置が大きい（または小さい）オブジェクトがクリックされたものと判定する。

図１３はVclick_AUのタイムスタンプ４０２のデータ構造の例である。この例では、動画像データ記録媒体２０４としてＤＶＤを用いる場合を仮定している。以下のタイムスタンプを用いることにより、ＤＶＤ上の動画像の任意の時刻を指定することが可能となり、動画像とVclickデータの同期が実現できる。各データ要素の意味は以下の通りである。

time_typeは、ＤＶＤ用タイムスタンプの始まりを示す。

VTSNは、ＤＶＤビデオのVTS（ビデオ・タイトルセット）番号を示す。

TTNは、ＤＶＤビデオのタイトル・ドメインにおけるタイトル番号を示す。ＤＶＤプレーヤのシステムパラメータSPRM(4)にストアされる値に相当する。

VTS_TTNは、ＤＶＤビデオのタイトル・ドメインにおけるVTSタイトル番号を示す。ＤＶＤプレーヤのシステムパラメータSPRM(5)にストアされる値に相当する。

TT_PGCNは、ＤＶＤビデオのタイトル・ドメインにおけるタイトルPGC（プログラム・チェーン）番号を示す。ＤＶＤプレーヤのシステムパラメータ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は、タイムスタンプ・スキップの始まりを示す。

図１５はVclick_AUのオブジェクト属性情報４０３のデータ構造の例である。各データ要素の意味は以下の通りである。

attribute_lengthは、このオブジェクト属性情報のうちattribute_lengthより後の部分のデータ長をバイトで指定する。

data_bytesはオブジェクト属性情報のデータ部である。この部分には図１６に示した属性データの１つまたは複数が記述される。図１８の最大値の欄には、それぞれの属性について、一つのVclick AU内に記述可能な最大のデータ数の例を示した。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の数を示す。

highlight_entriesにentry個のhighlight_effect_entryが含まれる。

highlight_effect_entryの仕様は以下に示す通りである。

図２６はオブジェクトのテキスト・ハイライト効果属性のエントリーのデータ構造の例である。各データ要素の意味は以下の通りである。

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の数を示す。

karaoke_entriesにentry個のkaraoke_effect_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の数を指定する。

layer_entriesにentry個のlayer_extension_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バッファ
次に、バッファ２０９におけるデータ量の変動について説明した後、動画像の再生開始のタイミングを決定する方法について説明する。

（１１−１）データ量の変動モデル（モデル１）について
まず、バッファにおけるデータ量の変動モデル（モデル１）について説明する。

モデル１では、データ転送が最も厳しい状態のときのバッファ内のデータ量の変動を仮定している。ここで「データ転送が最も厳しい状態」とは、ネットワークから、またはディスクから読み出されてバッファに入力される際のデータ転送速度が常に保証できる最低限度の速度ｒ（ｂｐｓ）である状態を意味する。従って、バッファは入力されてくるデータの転送速度を変化させたり、一時停止するなどの制御はできない。モデル１が良く当てはまる例としては、プロトコルとしてUDP/IPを用いたネットワーク経由のデータ・ストリーミングが挙げられる。

（１１−１−１）バッファ内のデータ量変動の例
図４５はモデル１に従ったバッファ内のデータ量変動の例である。図の横軸は動画時刻、縦軸はバッファ内の（Vcilckストリームの）データ量である。モデル１では、バッファ内のデータは必要とされる動画時刻に一度にバッファから出力される。例えば、時刻Ｔ_１に必要となるデータのサイズはＤ_１であるため、時刻Ｔ_１においてバッファ内のデータ量は一度にＤ_１だけ少なくなる。同様に、時刻Ｔ_２においてはデータサイズＤ_２だけバッファから出力されている。Ｔ_１やＴ_２は、Vclick AUのタイムスタンプに相当している。同じタイムスタンプを持つVcilck AU全てのデータサイズ分だけそのタイムスタンプの時刻にバッファから出力される。また、バッファからのデータ出力がない時は、常に速度ｒでバッファ内のデータは増加する。

図のＢ_Ｈ及びＢ_Ｌはそれぞれ、データ量の変動全体におけるバッファ内データ量の最大値、最小値である。またＢ_ｍｉｎはデータ量のダイナミックレンジであり、Ｂ_ｍｉｎ＝Ｂ_Ｈ−Ｂ_Ｌにより算出される。モデル１において、Ｂ_Ｌが０よりも小さくなる場合にはアンダーフローが生じることを意味しており、動画像再生にVclickデータが間に合わないことになる。Ｂ_Ｌが負の場合にアンダーフローが生じないようにするためには、バッファへのデータ入力開始を動画再生開始よりも前にしておくことにより、動画像再生開始時のバッファ内のデータ量を−Ｂ_Ｌだけ増加させればよい。バッファ内のデータ一方、Ｂ_Ｈが実際に使用されるバッファサイズよりも大きい場合にはオーバーフローが生じることを意味しており、データ溢れによりVclickデータが欠落してしまう。Ｂ_Ｈが使用バッファサイズよりも大きくなってしまう時には、動画像再生開始時のバッファ内のデータ量をより小さくしていくことでオーバーフローが防げる。しかし、Ｂ_ｍｉｎが使用するバッファサイズよりも小さい場合には、アンダーフローかオーバーフローを避けることはできない。従ってＢ_ｍｉｎを算出するこのが重要となる。

（１１−１−２）Ｂ_ｍｉｎの算出方法
Ｂ_ｍｉｎを算出するために、まず定義したモデル１におけるバッファ内のデータ量の変動をＴ、Ｂ_Ｂ、Ｂ_Ａのテーブルにより表現する。

図４６は図４５のデータ量変動をテーブルにより表現したものである。Ｔは０とデータがバッファから出力される時刻であり、Ｂ_Ｂはデータが出力される直前のバッファ内のデータ量、Ｂ_Ａはデータが出力される直後のバッファ内のデータ量である。明らかにこのテーブルは図４６のグラフの情報全てを有している。例えば、このテーブルのＢ_Ｂの最大値、Ｂ_Ａの最小値からＢ_ｍｉｎを算出することができる。

テーブルは、保証できる最低限度のデータ転送速度ｒとVclickストリームとから作ることができる。図４７はテーブル作成アルゴリズムの例である。

まず、初期化処理であるステップＳ４７００を行う。ここで、変数Ｔ_０、Ｂ_Ｂ、Ｂ_Ａに初期値０を代入し、テーブルに登録する。また変数にも初期値０を代入しておく。ステップＳ４７０１は変数ｉを１だけ増加させるインクリメント処理を行う。

ステップＳ４７０２はデータがバッファから出力される時刻Ｔ_ｉを設定する。これはVclcik AUのタイムスタンプを順次見ていき、Ｔ_ｉ−１よりも大きなタイムスタンプのうち最小のタイムスタンプを見つけて設定する。

ステップＳ４７０３は、時刻Ｔ_ｉにバッファから出力されるデータサイズＤを設定する。これはタイムスタンプＴ_ｉを持つVclick AU全てのデータサイズの和と等しい。

ステップＳ４７０４及びステップＳ４７０５ではＴ_ｉにおけるＢ_Ｂ及びＢ_Ａの値を計
算する。Ｂ_Ａ＋ｒ（Ｔ_ｉ−Ｔ_ｉ−１）が新しいＢ_Ｂに、Ｂ_Ｂ−Ｄが新しいＢ_Ａの値になる。ステップＳ４７０６では算出されたＴ_ｉ、Ｂ_Ｂ、Ｂ_Ａをテーブルに登録する。

ステップＳ４７０７の分岐処理では、Vclick AUのタイムスタンプが最大かどうかを判定することにより処理の終了を判定する。

以上の処理によりＢ_ｍｉｎが算出される。

（１１−１−３）バッファサイズの決定
以上の処理によりＢ_ｍｉｎが算出されると、再生開始時のバッファサイズをＢ_ｍｉｎにすることでアンダーフローを確実に無くすことが可能である。図４５は、動画像再生開始時のバッファ内のデータサイズをＢ_ｍｉｎとすることで図４８のような変動になる。時刻Ｔ_Ｅは全てのデータ（Vclickストリーム）をバッファに入力し終える時間である。時刻０からＴ_Ｅまでのバッファ内のデータ量の変動の幅はＢ_ｍｉｎ以下であるため、バッファサイズは２×Ｂ_ｍｉｎとしておけば十分である。

ランダムアクセスの場合にも同じことが言える。図４９は時刻Ｔ_Ｒから動画像の再生を開始した場合の例である。Ｔ_ＲからＴ_Ｅまでの時刻におけるバッファ量の変動幅はＢ_ｍｉｎ以下であるため、ランダムアクセス再生開始時のバッファ内データ量をＢ_ｍｉｎとしておけばアンダーフローは生じない。また、バッファサイズも先ほどと同様に２×Ｂ_ｍｉｎ以上としておけばオーバーフローすることはない。

以上から、バッファ内のデータサイズがＢ_ｍｉｎとなってから再生（ランダムアクセスを含む）を開始する、バッファサイズは２×Ｂ_ｍｉｎ以上とする、ことでデータ転送が最も厳しい状態（モデル１）においても問題なく動画像及びVclickデータの再生が可能となる。

（１１−２）バッファへのデータ入力の制御として停止／再開が可能である場合のモデル（モデル２）について
次にデータ転送速度がrか０を選択できる場合、すなわち、バッファへのデータ入力の制御として停止／再開が可能である場合のモデル（モデル２）について考える。ローカルのディスクからデータを読み込む場合にはこのような制御が可能であるため、モデル２はモデル１よりも実際に近いモデルである。また、ネットワーク経由でデータを読み出す場合でもプロトコルとしてTCP/IPを利用している場合にはモデル１よりもモデル２が良く当てはまる。

図５０は、図４５とは別のVcilckデータを用いたときのモデル１におけるバッファ内のデータ量の変動例である。図５０ではモデル１を仮定しているため、常にデータ転送速度ｒでデータがバッファに入力されている。

一方、図５１は、図５０と同じVclickデータを用いているが、時刻Ｔ_ＭからＴ_１までの間だけバッファへのデータ入力を停止した場合である。図５１の場合のＢ_ｍｉｎは明らかに図５０の場合のよりも小さな値となる。このように、モデル２ではモデル１よりもＢ_ｍｉｎの値が小さくできるため、動画像再生の開始までに必要なバッファリング時間が短くなり、さらに必要なバッファサイズも小さくなる。

（１１−２−１）最小のダイナミックレンジＢ_ｍｉｎの算出方法
モデル２における最小のダイナミックレンジＢ_ｍｉｎの算出には、例えば図５２に示した処理を用いることができる。

初めの処理ステップＳ５２００において、図４７で説明した方法によりモデル１に従ったデータ量変動のテーブルを作成する。図５０が作成されたテーブルをグラフで表現した例である。

次の処理ステップＳ５２０１では、Ｂ_Ｂの最大値をＢ_ＭＡＸ１とし、最大値Ｂ_ＭＡＸ１を与える時刻をＴ_１とする。最大値を与える時刻が複数ある場合には、最小の時刻をＴ_１とする。

さらに、ステップＳ５２０２において、Ｔ≧Ｔ_１となるＴの範囲でのＢ_Ａの最小値を求めてＢ_ＭＩＮとする。ステップＳ５２０３では、Ｔ≧Ｔ_１となるＴの範囲での最大値を求めてＢ_ＭＡＸ２とし、そのときの時刻をＴ_２とする。Ｔ≧Ｔ_１の範囲でＢ_ＭＡＸ２を与える時刻が複数ある場合には、最小の時刻をＴ_２とする（図５０参照）。

ステップＳ５２０４の分岐処理では、Ｂ_ＭＡＸ１−Ｂ_ＭＡＸ２とＢ_ＭＩＮ−Ｂ_Ｌの比較を行う。これは、時刻Ｔ_１以降のバッファ内のデータ量をどれだけ減らすことができるかを判断する処理であり、図５０の例では図中のＤ_１とＤ_２を比較している。Ｂ_ＭＡＸ１−Ｂ_ＭＡＸ２の方が小さければステップＳ５２０５に進み、それ以外であればステップＳ５２０７に進む。

ステップＳ５２０５では削減データサイズＤにＢ_ＭＡＸ１−Ｂ_ＭＡＸ２を代入する。そしてステップＳ５２０６で、テーブルのＴ≧Ｔ_１となるＴ全てのデータについてＢ_ＡからＤを減らす。ステップＳ５２０６の処理は、時刻Ｔ_１の直前にバッファへのデータ入力を停止させ、時刻Ｔ_１以降のバッファ内のデータ量を減らすことに相当する（図５１参照）。この処理後のテーブルは、時刻Ｔ_２より後のデータ範囲に於いてダイナミックレンジは最小になっている。なぜなら、図５１からわかるようにデータ転送速度０（バッファへのデータ入力を停止）の区間は必ずバッファ内データ量の最大値を与えており、この区間の転送速度をrにすると最大値が増加してしまうからである。また逆に、転送速度がrである区間を転送速度０に変更すると、バッファ内データ量の最小値が更に小さくなり、ダイナミックレンジが増加してしまう。これが図５２の処理が最小のダイナミックレンジＢ_ｍｉｎを算出できる根拠となっている。

ステップＳ５２０４の分岐でステップＳ５２０７に進んだ場合には、まずステップＳ５２０７で削減データサイズＤをＢ_ＭＩＮ−Ｂ_Ｌに設定する。そしてステップＳ５２０６と同様にテーブルのＴ≧Ｔ_１となるＴ全てのデータについてＢ_ＡからＤを減らす処理を行う。

ステップＳ５２０６の処理を行った後は、ステップＳ５２０９においてステップＳ５２０２からの処理を繰り返し行うかどうかを判定する。しかし、ステップＳ５２０８の処理を行った場合には直ちにステップＳ５２１１でＢ_ｍｉｎを算出・出力して処理を終了する。これは、ステップＳ５２０８の後にはすでに最小のダイナミックレンジを与えるテーブルが完成しているからである。

ステップＳ５２０９ではＴ_２が０であるかどうかをチェックし、０でなければ処理を繰り返すため、ステップＳ５２１０に進む。ステップＳ５２１０は変数の更新処理であり、Ｂ_ＭＡＸ１にＢ_ＭＡＸ２を、Ｔ_１にＴ_２をそれぞれ代入し、再びステップＳ５２０２に処理を進める。

ステップＳ５２１１はモデル２における最小のダイナミックレンジＢ_ｍｉｎの値をＢ_ＭＡＸ１−Ｄ−Ｂ_Ｌとして算出し、処理を終える。図５３は、図５２の処理が終了した後のバッファ内のデータ量変動のグラフである。図５０に比べて遙かに小さなＢ_ｍｉｎが得られていることがわかる。

以上の処理によりダイナミックレンジＢ_ｍｉｎが算出される。

（１１−２−２）バッファサイズの決定
以上の処理により算出されたダイナミックレンジＢ_ｍｉｎがわかれば、動画像再生時に必要なバッファ内のデータ量と、必要なバッファのサイズがわかる。

すなわち、モデル２に於いて、バッファ内のデータ量がＢ_ｍｉｎとなってから再生を開始すればアンダーフローが生じないことが保証できる。また、バッファサイズをＢ_ｍｉｎ以上にしておけばオーバーフローすることもない。

図５４は、時刻Ｔ_Ｒからのランダムアクセス再生を行った際のバッファ内のデータ量の変位である。バッファ内のデータ量がＢ_ｍｉｎになった時点で再生を開始することにより、先ほどと同様にバッファアンダーフローが生じないことが保証される。バッファサイズについても同様にＢ_ｍｉｎ以上にしておけばオーバーフローしないことが保証できる。

モデル２は、転送速度がrか０かを選択できるモデルである。しかし、転送速度がr以上か０かを選択できる場合にも、モデル２を使って設定した動画像再生開始時のバッファ内のデータ量とバッファサイズを使えばアンダーフロー・オーバーフローが生じない。実際にはネットワークの転送速度には変動があるため、転送速度がｒ以上か０かを選択できるモデルは実際の動作とほぼ同じである。従って、モデル２を使って設定した動画像再生開始にバッファリングすべきデータ量とバッファサイズを実際のアプリケーションに於いて使用することができる。

（１１−３）Vclickストリームのヘッダのデータ構造
図５５は、モデル１もしくはモデル２により算出されたダイナミックレンジＢ_ｍｉｎを図２のシステムで利用することを可能にするためのVclickストリームのヘッダのデータ構造である。

図５５のデータ構造では図１１のデータ構造に加え、新たにmin_bufferが加わっている。min_bufferにはモデル１もしくはモデル２を用いて算出されたＢ_ｍｉｎの値が格納される。どちらのモデルで算出されたダイナミックレンジＢ_ｍｉｎを採用するかは、実際にどちらのモデルが使用状況に近いかにより判断される。どちらのモデルとも判断しがたい場合や、様々な使用環境が考えられる場合にはモデル１により算出した値を採用した方が良い。

なお、min_bufferが２つのモデルのうちのどちらを用いて算出された値であるかを明示するため、モデルを特定するフラグbuffer_modelを図５５のデータ構造に加えても良い。たとえば、buffer_modelが０のときモデル１、buffer_modelが１のときモデル２を採用していることを意味するようにしておくことで、モデルの特定が可能である。

（１１−４）バッファ制御の手順
図５６は図５５のデータを使用した場合のバッファ制御の手順である。

まず、ステップＳ５６００において、バッファ・マネージャー２１１がバッファ２０９内にVclick用のバッファとしてmin_buffer以上のサイズ（モデル２が使われている場合）か、min_bufferの２倍以上のサイズ（モデル１が使われている場合）の領域を確保する。そしてVclickデータのバッファへの読み込みを開始する。続いてステップＳ５６０１で、バッファ２０９内に蓄積されたVcilckデータのサイズがmin_bufferとなってから動画像及びVclickデータの再生を開始する。ステップＳ５６０２では、バッファに空きが生じたらVclickデータをバッファに読み込み、バッファが一杯になったらVclickデータの読み込みを停止する。そして読み込むVclickデータが無くなったら処理を終了する（Ｓ５６０３）。以上の制御により、バッファアンダーフローやオーバーフローを生じさせることなく、Vcilckデータと動画像の同時再生が可能となる。もちろん、min_bufferにダイナミックレンジＢ_ｍｉｎより大きな値を記述しておいても良い。この場合、必要以上のバッファサイズが確保されることになるが、動作上はなんら問題ない。

（１１−５）Vclickストリームのヘッダの他のデータ構造
図５７は図５５とは別のVclickストリームのヘッダのデータ構造である。

この例では、min_buffer_1にモデル１により算出されたダイナミックレンジＢ_ｍｉｎを記述し、min_buffer_2にモデル２により算出されたダイナミックレンジＢ_ｍｉｎを記述する。

クライアント装置２００では、Vcilckデータの使用状況に応じて、min_buffer_1とmin_buffer_2のどちらを使用するかを判断する。例えば、サーバー装置２０１からUDP/IPをベースとしたRTPプロトコルによりVcilckデータを受け取る場合には、モデル１により算出されたダイナミックレンジであるmin_buffer_1を用いてバッファ制御を行う。すなわち、バッファ２０９内にVclick用のバッファとしてmin_buffer_1の２倍以上のサイズの領域を確保し、さらに動画像の再生を開始するときにはバッファ２０９内に蓄積されたVcilckデータのサイズがmin_buffer_1となってから再生を開始するよう制御する。

一方、サーバー装置２０１からTCP/IPをベースとしたHTTPプロトコルによりVcilckデータを受け取る場合には、モデル２により算出されたダイナミックレンジであるmin_buffer_2を用いてバッファ制御を行う。すなわち、バッファ２０９内にVclick用のバッファとしてmin_buffer_2以上のサイズの領域を確保し、さらに動画像の再生を開始するときにはバッファ２０９内に蓄積されたVcilckデータのサイズがmin_buffer_2となってから再生を開始するよう制御する。図５５のデータ構造と同様に、min_buffer_1やmin_buffer_2にそれぞれモデル１及びモデル２により算出されたダイナミックレンジＢ_ｍｉｎより大きな値を記述しておいても良い。

（１１−６）第１の再生開始処理手順
図５８はユーザが再生開始を指示してから再生が開始されるまでの第１の再生開始処理手順を表す流れ図であり、基本的な流れは図３７で示される手順と同じである。

まず、ステップＳ３７００でユーザにより再生開始の指示が入力される。この入力は、インタフェース・ハンドラー２０７が受け取り、動画像再生コントローラ２０５に動画像再生準備の命令を出す。

次に、上記で説明したバッファ２０９内にVclick用のバッファとしてmin_buffer以上のサイズの領域を確保する。

そして、分岐処理ステップＳ３７０１として、すでにサーバー装置２０１とのセッションが構築されているかどうかの判定を行う。セッションがまだ構築されていなければステップＳ３７０２に、すでに構築されていればステップＳ３７０３に処理を移す。ステップＳ３７０２ではサーバーとクライアント間のセッションを構築する処理を行う。

以下の処理Ｓ３７０３〜Ｓ３７０５は、図３７で説明した内容で動画再生が行われる。

（１１−７）第２の再生開始処理手順
図５９は図５８とは他の再生開始処理の手順を説明する流れ図である。

図５８の流れ図で説明される処理では、ネットワークの状態やサーバー、クライアント装置の処理能力により、ステップＳ３７０４でのVclickストリームを一定量バッファリングする処理に時間がかかる場合がある。すなわち、ユーザが再生を指示してから実際に再生が始まるまでに時間がかかってしまうことがある。

図５９の処理手順では、ステップＳ３８００でユーザが再生開始を指示する。

次に、上記で説明したバッファ２０９内にVclick用のバッファとしてmin_buffer以上のサイズの領域を確保する。

そして、次のステップＳ３８０１で直ちに動画像の再生が開始される。次の処理ステップＳ３８０２からステップＳ３８０６までは、図３８のステップＳ３７０２からステップＳ３７０６と同一の処理である。

（１１−８）第３の再生開始処理手順
図６０はユーザが再生開始を指示してから再生が開始されるまでの再生開始処理手順を表す流れ図であり、基本的な流れは図４７で示される手順と同じである。

まず、ステップＳ４２００でユーザにより再生開始の指示が入力される。この入力は、インタフェース・ハンドラー２０７が受け取り、動画再生コントローラ２０５に動画像再生準備の命令を出す。

次に、ステップＳ４２０１では、使用するVclickストリームを特定する処理が行われる。この処理では、インタフェース・ハンドラーは動画像データ記録媒体２３１上にあるVclick情報ファイルを参照し、ユーザが再生を指定した動画像に対応するVclickストリームを特定する。

次に、上記で説明したバッファ２０９内にVclick用のバッファとしてmin_buffer以上のサイズの領域を確保する。

そして、ステップＳ４２０２では、バッファにVclickストリームを格納する処理が行われる。

以下の処理Ｓ４７０３は、図４７で説明した内容で動画再生が行われる。

（１１−９）第４の再生開始処理手順
図６１は図６０とは他の再生開始処理の手順を説明する流れ図である。

図６０の流れ図で説明される処理では、ネットワークの状態やサーバー、クライアント装置の処理能力により、Vclickストリームを一定量バッファリングする処理に時間がかかる場合がある。すなわち、ユーザが再生を指示してから実際に再生が始まるまでに時間がかかってしまうことがある。

図６１の処理手順では、ステップＳ４２００でユーザが再生開始を指示する。

次のステップで直ちに動画像の再生が開始される。

次に、ステップＳ４２０１では、使用するVclickストリームを特定する処理が行われる。この処理では、インタフェース・ハンドラーは動画像データ記録媒体２３１上にあるVclick情報ファイルを参照し、ユーザが再生を指定した動画像に対応するVclickストリームを特定する。

次に、上記で説明したバッファ２０９内にVclick用のバッファとしてmin_buffer以上のサイズの領域を確保する。

以下の処理は、図４７で説明した内容で動画再生が行われる。

（変更例）
なお、本発明は上記した実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を種々変形して具体化することができる。

（１）変更例１
例えば、本発明は現在世界的に普及しているＤＶＤ−ＲＯＭビデオのみならず、近年急速に需要が伸びている録画再生可能なＤＶＤ−ＶＲ（ビデオレコーダ）にも適用できる。さらには、近々普及が始まるであろう次世代ＨＤ−ＤＶＤの再生系または録再系にも適用可能である。

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

本発明の一実施例に係るハイパーメディアの表示例を説明する図である。 本発明の一実施例に係るシステムの構成例を示すブロック図である。 本発明の一実施例に係るオブジェクト領域とオブジェクト領域データの関係を説明する図である。 本発明の一実施例に係るオブジェクト・メタデータのアクセスユニットのデータ構造例を説明する図である。 本発明の一実施例に係る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アクセスユニットのオブジェクト属性情報

Claims (11)

1. 動画像に関連したメタデータであって、かつ、前記メタデータの再生まではバッファ内に一時的に蓄積されるメタデータのデータ構造において、
   前記メタデータは、独立して処理可能なデータ単位であるアクセスユニットを１以上含んで構成されるストリームのデータ構造をなし、
   前記各アクセスユニットは、
   前記動画像の時間軸に対して定義される有効期間を特定する第１データと、
   前記動画像中の時空間領域を記述したオブジェクト領域データと、
   前記時空間領域に関連した表示方法を特定するデータ、または、前記時空間領域が指定された際に行う処理を特定するデータの一方または両方を含む第２データとを有し、
   さらに、前記メタデータの再生開始時までに前記バッファ内に予め蓄積しておくべきメタデータ量を特定する情報を含んだ第３データを有する
   ことを特徴とするメタデータのデータ構造。
2. 前記第３データは、
   前記メタデータが前記バッファに一定速度で入力され、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合のダイナミックレンジである
   ことを特徴とする請求項１のメタデータのデータ構造。
3. 前記第３データは、
   前記メタデータが前記バッファに一定速度で入力されるか、または、入力が停止されるかが随時選択可能であり、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合の最小ダイナミックレンジである
   ことを特徴とする請求項１のメタデータのデータ構造。
4. 前記第３データは、
   前記メタデータが前記バッファに一定速度で入力され、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合のダイナミックレンジと、
   前記メタデータが前記バッファに一定速度で入力されるか、または、入力が停止されるかが随時選択可能であり、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合の最小ダイナミックレンジの両方を含む
   ことを特徴とする請求項１のメタデータのデータ構造。
5. 前記第３データは、再生開始時にバッファ内に予め蓄積しておくべきメタデータ量を特定する情報に加えて、前記メタデータの再生に必要なバッファサイズを特定する情報も有する
   ことを特徴とする請求項１記載のメタデータのデータ構造。
6. 前記第３データは、
   前記メタデータが前記バッファに一定速度で入力され、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合のダイナミックレンジであり、
   前記バッファサイズを前記ダイナミックレンジの２倍以上とする
   ことを特徴とする請求項５のメタデータのデータ構造。
7. 前記第３データは、
   前記メタデータが、前記バッファに一定速度で入力されるか、または、入力が停止されるかが随時選択可能であり、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合の最小ダイナミックレンジであり、
   前記バッファサイズを前記ダイナミックレンジの大きさ以上とする
   ことを特徴とする請求項５のメタデータのデータ構造。
8. 前記第３データは、
   前記メタデータが前記バッファに一定速度で入力され、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合のダイナミックレンジと、
   また、前記メタデータが、前記バッファに一定速度で入力されるか、または、入力が停止されるかが随時選択可能であり、前記アクセスユニットの有効期間の開始時刻に前記アクセスユニット単位でバッファから出力される場合の最小ダイナミックレンジの両方を含み、
   前記バッファサイズが前記ダイナミックレンジの２倍以上もしくは前記最小ダイナミックレンジの大きさ以上とする
   ことを特徴とする請求項５のメタデータのデータ構造。
9. 動画像に関連したメタデータであって、かつ、前記メタデータの再生まではバッファ内に一時的に蓄積されるメタデータの再生装置において、
   前記メタデータは、独立して処理可能なデータ単位であるアクセスユニットを１以上含んで構成されるストリームのデータ構造をなし、
   前記各アクセスユニットは、
   前記動画像の時間軸に対して定義される有効期間を特定する第１データと、
   前記動画像中の時空間領域を記述したオブジェクト領域データと、
   前記時空間領域に関連した表示方法を特定するデータ、または、前記時空間領域が指定された際に行う処理を特定するデータの一方または両方を含む第２データとを有し、
   さらに、前記メタデータの再生開始時までに前記バッファ内に予め蓄積しておくべきメタデータ量を特定する情報を含んだ第３データと、
   を有し、
   前記メタデータの再生指示があった場合に、前記第３データに基づいて前記バッファ内に前記メタデータ量を蓄積させる手段と、
   前記メタデータ量の蓄積後に前記メタデータを再生する手段と、
   を有する
   ことを特徴とするメタデータの再生装置。
10. 動画像に関連したメタデータであって、かつ、前記メタデータの再生まではバッファ内に一時的に蓄積されるメタデータの再生方法において、
    前記メタデータは、独立して処理可能なデータ単位であるアクセスユニットを１以上含んで構成されるストリームのデータ構造をなし、
    前記各アクセスユニットは、
    前記動画像の時間軸に対して定義される有効期間を特定する第１データと、
    前記動画像中の時空間領域を記述したオブジェクト領域データと、
    前記時空間領域に関連した表示方法を特定するデータ、または、前記時空間領域が指定された際に行う処理を特定するデータの一方または両方を含む第２データとを有し、
    さらに、前記メタデータの再生開始時までに前記バッファ内に予め蓄積しておくべきメタデータ量を特定する情報を含んだ第３データと、
    を有し、
    前記メタデータの再生指示があった場合に、前記第３データに基づいて前記バッファ内に前記メタデータ量を蓄積させるステップと、
    前記メタデータ量の蓄積後に前記メタデータを再生するステップと、
    を有する
    ことを特徴とするメタデータの再生方法。
11. 動画像に関連したメタデータであって、かつ、前記メタデータの再生まではバッファ内に一時的に蓄積されるメタデータの再生方法をコンピュータによって実現するプログラムにおいて、
    前記メタデータは、独立して処理可能なデータ単位であるアクセスユニットを１以上含んで構成されるストリームのデータ構造をなし、
    前記各アクセスユニットは、
    前記動画像の時間軸に対して定義される有効期間を特定する第１データと、
    前記動画像中の時空間領域を記述したオブジェクト領域データと、
    前記時空間領域に関連した表示方法を特定するデータ、または、前記時空間領域が指定された際に行う処理を特定するデータの一方または両方を含む第２データとを有し、
    さらに、前記メタデータの再生開始時までに前記バッファ内に予め蓄積しておくべきメタデータ量を特定する情報を含んだ第３データと、
    を有し、
    前記メタデータの再生指示があった場合に、前記第３データに基づいて前記バッファ内に前記メタデータ量を蓄積させる機能と、
    前記メタデータ量の蓄積後に前記メタデータを再生する機能と、
    を実現する
    ことを特徴とするメタデータの再生方法のプログラム。
    

Images