WO2004095837A1

WO2004095837A1 - 再生装置、プログラム。

Info

Publication number: WO2004095837A1
Application number: PCT/JP2004/005778
Authority: WO
Inventors: Hiroshi Hamasaka; Masayuki Kozuka; Masataka Minami
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2003-04-22
Filing date: 2004-04-22
Publication date: 2004-11-04
Also published as: EP1628477A1; CN1778111A; JPWO2004095837A1; EP1628477A4; US20040213542A1; US20060204092A1

Abstract

ビデオストリームと、字幕用のグラフィクスストリームとから構成されるAVClipが記録された光ディスクにおいて、このAVClipが対応している解像度を、Clip情報から検出する。再生装置に接続可能なディスプレイ装置の解像度と、検出手段により検出された解像度との比率を算出して、算出された解像度比に基づいた字幕コンテンツを、ビデオストリームと共に再生する。

Description

明細書

再生装置、プログラム。技術分野

本発明は、動画データと、補助データから構成されるコンテンツを再生する再生装置に関し、動画データと同期させながら、補助データを表示する改良に関する。背景技術

BD- ROMのような大容量ディスクで供給されるコンテンツには、対応している解像度の違いにより、 2 つのタイプがある。 1 つは、 1920 X 1080 という解像度をもった高画質なもの、もう 1 つは 720 x480 という解像度をもつた標準画質のものである。

高解像度をもったコンテンツは、 HDTV Hi Definition Television)と呼ばれるディスプレイ装置での再生に適している。一方標準解像度をもつたコンテンツは、 SDTV(Standard Definition Television)と呼ばれるディスプレイ装置での再生に適している。これらコンテンツ、ディスプレイ装置のうちコンテンツ側の解像度が 1920x 1080 であり、ディスプレイ装置が HDTV 型である時、コンテンツを構成する動画、字幕は本来の解像度での表示が行われることになる。この本来の解像度での再生によりユーザは、映画館並みの高画質で映画コンテンッを鑑賞することができる。

従来技術では、 HDTV 型のディスプレイ装置、 SDTV 型のディスプレイ装置のそれぞれで表示されることを想定して、動画だけではなく補助データを作成する必要がある。補助データが字幕である場合、 HDTV対応のビデオストリームと、 HDTV対応の字幕グラフィクスとからなるデジタルストリーム、 SDTV 対応のビデオストリームと、 SDTV 対応の字幕グラフイクスとからなるデジタルストリームを製作し、記録媒体に記録するという手間を払うことになる。だが字幕は、映画コンテンツが頒布されるべき国 ·地域に応じた多数のものが必要であり、各言語についての字幕グラフィクスを、 SDTV— HDTVのそれぞれについて作成してビデオストリ —ムと多重させるというのは多大な工数を要する。そのため、少数派の言語については、 SDTV 対応の字幕、 HDTV 対応の字幕のうち一方のみが製作され、他方の製作が省略されることがある。 HDTV対応の字幕、 SDTV 対応の字幕のうちどちらかの製作が省略されれば、たとえ動画データが HDTV対応であり、ディスプレイ装置が HDTV対応であっとしても、 HDTV 対応の解像度での字幕表示は行えない。コスト面からの要請からとはいえ、少数派の言語を用いるユーザを、 HDTV対応の流れから置き去りにすることは、映画会社がグローバルな市場展開を実現するうえで望ましくない。発明の開示

本発明の目的は、 SDTV対応の字幕グラフィクス及び HDTV対応の字幕グラフィクスのうち、どちらかの製作が省略されたとしても、製作された場合と同等な字幕表示を行い得る再生装置を提供することである。上記目的と達成するため、本発明に係る再生装置は、動画データにおけるフレーム画像を表現するための解像度を検出する検出手段と、再生装置に接続されたディスプレイ装置の解像度と、検出手段により検出された解像度との比率が 1である場合、動画データと多重化されて記録媒体に記録されている補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 1表示手段と、解像度の比率が 1でない場合、サーバ装置から供給された補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 2表示手段とを備えている。第 2表示手段は、ディスプレイ装置側の解像度と、コンテンツ側の解像度との比率が 1 でない場合に、サーバ装置から供給を受けた字幕データを表示するので、たとえォーサリングを行う製作者がデジタルストリームの製作時にあたって、字幕グラフィクスの製作を省略したとしても、サ —バ装置による字幕データの供給さえ可能であれば、字幕表示を実現することができる。

コンテンツ出荷までに字幕データの製作が間に合わなくても、後日字幕データを供給しさえすれば少数派言語での字幕表示を、ユーザに行わせることができるので、世界中の幅広い地域に居住するユーザに対し、

HDTV対応の字幕を視聴する機会を与えることができる。これによりコンテンッを頒布するにあたっての市場拡大を実現することができる。

またディスプレイ装置側の解像度と、コンテンツ側の解像度との比率に応じて字幕を表示するので、『コンテンツ一ディスプレイ装置』の組合せが動的に変わるとしても、その組合せに最適な表示を行うことがでぎる。

尚、上記再生装置は、補助データの供給をサーバ装置から受けているが、これは本発明において、任意的に付加された事項であり、本発明に係る再生装置はこの技術的事項を必須とはしない。何故なら、動画デ一夕が記録された記録媒体とは異なる供給源から補助データの供給が可能であれば、サーバ装置による供給を受けなくても上述した目的達成は可能になるからである。図面の簡単な説明

図 1 は、本発明に係る再生装置の、使用行為についての形態を示す図である。

図 2は、 BD-R0Mの構成を示す図である。

図 3は、 AVCl ipがどのように構成されているかを模式的に示す図である。

図 4 ( a ) は、プレゼンテーショングラフィクスストリームの構成を示す図である。

図 4 ( b ) は、 PESバケツトの内部構成を示す図である。

図 5は、様々な種別の機能セグメントにて構成される論理構造を示す図である。

図 6は、字幕の表示位置と、 Epochとの関係'を示す図である。

図 7 ( a ) は、 0DS によるグラフィクスオブジェクトがどのように行われるかを示す図である。

図 7 ( b ) は、 PDSのデータ構造を示す図である。図 8 (a) は、 WDSのデータ構造を示す図である。

図 8 (b) は、 PCSのデータ構造を示す図である。

図 9.は、字幕表示を実現するための記述例を示す図である。

図 1 0は、 DS1 における PCSの記述例を示す図である。

図 1 1は、 DS2における PCSの記述例を示す図である。

図 1 2は、 DS3における PCSの記述例を示す図である。

図 1 3は、映画コンテンツの中身と、字幕コンテンツの中身とを対比して示す図である。

図 1 4は、テキストタイプの字幕コンテンッの一例を示す図である。図 1 5は、本発明に係る再生装置の内部構成を示す図である。

図 1 6は、グラフィクスデコーダ 9の内部構成を示す図である。

図 1 7は、 Graphics Controller3.7の処理手順を示すフローチャートである。

図 1 8は、映画コンテンッ再生処理の処理手順を示すフローチヤ一トである。

図 1 9は、テキスト字幕表示処理の処理手順を示すフ口一チャートである。

図 20 (a) 〜（c) は、解像度比に基づくアウトラインフォントの拡大処理を示す図である。

図 2 1 (a) 〜（c) は、第 2実施形態に係る制御部 29による HTML 文書の変換処理についての説明図である。

図 22 (a) 〜（c) は、行間調整の処理手順を示す説明図である。発明を実施するための最良の形態

(第 1実施形態）

以降、本発明に係る再生装置の実施形態について説明する。尚、説明にあたって補助データは字幕データであるものとして説明を進める。先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図 1は、本発明に係る再生装置の、使用行為についての形態を示す図である。図 1において、本発明に係る再生装置は再生装置 200であり、テレビ 300、リモコン 400と共にホ一ムシァタ一システムを形成する。

BD-R0M 1 00は、映画コンテンツをホームシアターシステムに供給する目的をもつ。映画コンテンツは、デジタルストリームである AVClip と、その管理情報である Clip情報とから構成される。 AVClipは、映画コンテンツの動画、音声、字幕を構成する実体データである。映画コンテンッにおける字幕は、ビットマップタイプの字幕であり、グラフイクスストリームと呼ばれるエレメンタリストリームにより構成される。 Cli 情報は、動画データにおけるフレーム画像を表現するための解像度を示す解像度情報を内部に有する。解像度情報に示される解像度は、 1920 X 1080(1080i) , 720 x 480 (480i , 480ρ) , 1440 1080, 1280 720, 540 x 480といった数値が代表的である。尚、添え字" i" は、インターレス方式の意味であり、添え字" P" は、プログレッシブ方式の意味である。再生装置 200は、 BD-R0M1 00を装填して、 BD-R0M 1 00に記録されている映画コンテンツの再生を行う。

ディスプレイ装置 3 0 0 は、 HDMKHigh Definition Multimedia Interface)を介して再生装置と接続されており、この HDMI を介して再生装置は、ディスプレイ装置 300から解像度情報を取得することができる。この解像度情報は、ディスプレイ装置 300の解像度を示すものなので、これにより再生装置は、ディスプレイ装置 300における表示解像度が、高解像度対応であるか、標準画質対応であるかを知り得る。

リモコン 400は、ユーザからの操作を受け付ける携帯機器である。サーバ装置 500は、様々な言語にじた字幕コンテンツを保持しており、再生装置からの要求に応じて字幕コンテンツを再生装置に供給する。字幕コンテンツの供給の仕方には、ストリーミング、一括ダウン口ードの 2種がある。映画コンテンツにおける字幕がビットマップタイプの字幕であるのに対し、字幕コンテンッにはビットマップタイプのもの，テキストタイプのものの 2種類がある。

続いて、映画コンテンツが BD-R0M 上にどのように記録されるかについて説明する。図 2は、 BD- ROMの構成を示す図である。本図の第 4段目に BD- ROMを示し、第 3段目に BD- ROM上のトラックを示す。本図のトラックは、 BD-R0M の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリュ一ム領域と、リードァゥト領域とからなる。本図のポリュ一ム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いて BD- ROMの応用層フォ一マツト（アプリケーションフォーマツト）を表現すると、図中の第 1段目のようになる。本図に示すように BD- ROMには、 ROOTディレクトリの下に BDMVディレクトリがあり、 BDMV ディレクトリの配下には、 XXX.M2TS、 XXX.CLPI といったファィルが存在する。ファイル XXX. M2TS が AVClip にあたり、ファイル XXX.CLPIが Cli 情報にあたる。

本図に示すようなアプリケーションフォーマツトを作成することにより、本発明に係る記録媒体は生産される。

続いて、映画コンテンツの構成要素（AVClip— Clip 情報）のうち、 AVClipについて説明する。

図 3は、 AVClipがどのように構成されているかを模式的に示す図である。

AVCli は（第 4段目）、複数のビデオフレーム（ピクチャ pjl，2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーデ、ィォストリームを（第 1段目）、 PESパケット列に変換し（第 2段目）、更に TS パケットに変換し（第 3段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム、対話系のィンタラクティブグラフィクスストリーム（第 7段目）を、 PESバケツト列に変換し（第 6段目）、更に TSバケツトに変換して（第 5段目）、これらを多重化することで構成される。

以上が AVClipに多重化されるェレメン夕リストリームである（インタラクティブグラフィクスストリームについては、本発明の主眼ではないので説明を省略する）。

続いてプレゼンテーショングラフィクスストリームについて説明する。このプレゼンテーショングラフィクスストリームの特徴は、ビットマップ型のグラフイクスを、表示のための制御情報と一体化して構成している点である。図 4 ( a ) は、プレゼンテーショングラフィクスストリームの構成を示す図である。第 1段目は、 AVClipを構成する TSパケット列を示す。第 2段目は、グラフィクスストリームを構成する PESパケット列を示す。第 2段目における PESバケツト列は、第 1段目における TSバケツトのうち、所定の PIDをもつ TSバケツ卜からペイロードを取り出して、連結することにより構成される。

第 3段目は、グラフィクスストリームの構成を示す。グラフィクスス卜リームは、 PCS(Presentation Composition Segment)、 WDS(Window Define Segment) 、 PDSCPalette Dif inition Segment) 、 ODS Object— Def inition—Segment)、 END (END of Display Set Segment) と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、 PCS は、画面構成セグメントと呼ばれ、 WDS,PDS，ODS,END は定義セグメントと呼ばれる。 PESバケツトと機能セグメントとの対応関係は、 1対 1 の関係、 1対多の関係である。

図 4 (b) は、機能セグメントを変換することで得られる PESバケツトを示す図である。図 4 (b) に示すように PESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応する DTS、 PTSが存在する。尚以降の説明では、機能セグメントが格納される PESパケトのへッダ内に存在する DTS及ぴ PTSを、機能セグメントの DTS及び PTSとして扱う。

これら様々な種別の機能セグメントは、図 5のような論理構造を構築する。図 5は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第 3段目に機能セグメントを、第 2段目に Display Setを、第 1段目に Epochをそれぞれ示す。

第 2段目の Display Set(DSと略す）とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のダラフィクスを構成するものの集合をいう。図中の破線は、第 3段目の機能セグメントが、どの DSに帰属しているかという帰属関係を示す。 PCS-TOS- PDS- 0DS- ENDという一連の機能セグメントが、 1 つの DS ¾構成していることがわかる。再生装置は、この DSを構成する複数機能セグメントを BD- ROMから読み出せば、一画面分のグラフィクスを構成することができる。

第 1段目の Epochとは、 AVC l ipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデ一タ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のクラフィクスデータを格納しておくためのオブジェクトノッファである。これらについてのメモリ管理に、連続性があるというのは、この Epochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう（※ここでフラッシュとは、プレーン及ぴバッファの格納内容を全部クリアしてしまうことである。）。この矩形領域の縦横の大きさ及び位置は、 Epochにあたる期間において、終始固定されている。図 6は、字幕の表示位置と、 Epoch との関係を示す図である。本図では、動画の各ビクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり 5つの字幕「本当は」「ゥソだった」「あなたが」「ずつと」「すきだった」のうち、 3つの字幕「本当は」「ゥソだった」「あなたが」は画面の下側に、「ずっと」「すきだった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。か,かる時間的な変動がある場合、 AVC l i pの再生時間軸において、下側の余白に字幕が出現している期間が 1つの Epochl、上側の余白に字幕が出現している期間が別の Epoch2 になる。これら 2 つの Epochは、それぞれ独自の字幕の描画領域をもつことになる。 Epochlでは、画面の下側の余白が字幕の描画領域（wi ndowl)になる。一方 Epoch2 では、画面の上側の余白が字幕の描画領域（wi ndow2)になる。これらの Epochl , 2 において、バッファ 'プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上が Epochについての説明である。続いて Di sp lay Setについて説明する。

図 5における破線 hkl , 2は、第 2段目の機能セグメントが、どの Epoch に帰属しているかという帰属関係を示す。 Epoch Start, Acquisition Point, Normal Caseという一連の DSは、第 1段目の Epochを構成していることがわかる o 『Epoch Start：』、『Acquisition Point』、『Normal Case』は、 DS の類型である。本図における Acquisition Point. Normal Case の順序は、一例にすぎず、どちらが先であってもよい。

『EpochStart』は、" 新表示" という表示効果をもたらす DSであり、新たな Epochの開始を示す。そのため Epoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。 Epoch Start は、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。

『Acquisition Point』は、" 表示リフレッシュ" という表示効果をもたらす Display Setであり、先行する Epoch Startと全く同じ Display Set をいう。 Acquisition Point たる DS は、 Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、 Acquisition Pointたる DSから頭出しを行えば、グラフィックス表示を確実に実現することができる。

『Normal CaseJ は、" 表示アップデート" という表示効果をもたらす DSであり、前の画面合成からの差分のみを含む。例えば、ある DSvの字幕は、先行する DSuと同じ内容であるが、画面構成が、この先行する DSu とは異なる場合、 PCS のみの DSv、又は、 PCS のみの DSv を設けてこの DSvを Normal Caseの DSにする。こうすれば、重複する 0DSを設ける必要はなくなるので、 BD-R0M における容量削減に寄与することができる。一方、 Normal Caseの DSは、差分にすぎないので、 Normal Case単独では画面構成は行えない。

続いて Definition Segment (0DS， WDS, PDS)について説明する。

『0bject— Definition_Segment』は、ビットマップ型のグラフィクスであるグラフィクスォブジヱクトを定義する機能セグメントである。このグラフィクスォブジェクトについて以下説明する。 BD- ROMに記録されている AVClip は、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、 1920 x 1080画素という高精細な大きさに設定されている。 1920 X 1080という解像度があるので、 BD-R0Mでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。画素の色にあたっては、一画素当たりのインデックス値（赤色差成分（Cr値），青色差成分（Cb値），輝度成分 Y値，透明度（T値））のビット長が 8ビットになっており、これによりフルカラーの 16,777,216色から任意の 256色を選んで画素の色として設定することができる。グラフィクスォブジェクトによる字幕は、透明色の背景に、文字列を配置することで描画される。

0DS によるグラフィクスオブジェクトの定義は、図 7 (a) に示すようなデータ構造をもってなされる。 0DS は、図 7 ( a ) に示すように自身が 0DSであることを示す『 segment— type』と、 0DSのデータ長を示す『segment— length』と、 Epochにおいてこの 0DSに対応するグラフイクスオブジェクトを一意に識別する『object— id』と、 Epochにおける 0DS のノ一ジョンを示す Γ object— version— number 』と、 riast_insequence_f lagj と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ robject_data_fragmentJ とからなる。以上が 0DSの説明である。

『Palette Dif inition Segment (PDS)』は、色変換用のパレットを定義する情報である。 PDS のデータ構造を図 7 (b) に示す。図 7 (b) に示すように PDSは、自身が PDSであることを示す『segment一 type』、 PDSのデータ長を示す『segment_length』、この PDSに含まれるパレットを一意に識別する『pallet— id』、 Epochにおける Epochの PDSのパージヨンを示す『pallet— version— number』、各エントリ一についての情報『palleし entry』からなる。『pal let_entry』は、各エントリーにおける赤色差成分（Cr値），青色差成分（Cb値），輝度成分 Y値，透明度（T値）を示す。

続いて WDSについて説明する。

『window— definition— segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。 Epoch では、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は" window" と呼ばれ、この WDSで定義される。図 8 (a) は、 WDSのデータ構造を示す図である。本図に示すように WDSは、グラフィックスプレーンにおいてゥインドウを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window— horizontal— position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window— vertical— position』と、グラフィックスプレーンにおけるゥインドウの横幅を示す『window一 width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。

以上が 0DS、 PDS、 WDS, END についての説明である。続いて PCS について説明する。

PCS は、対話的な画面を構成する機能セグメントである。 PCS は、図 8 (b) に示すデータ構造で構成される。本図に示すように PCS は、『segment— type』と、『segment— length』と、『composi ti on— numberj と、『composi tion— state』と、『pal let— update— flagj と、 palLet— id』と、『Composition— Object (1)〜（！ n)』とから構成される。

『compositioii_number』は、 0から 15までの数値を用いて Display Set におけるグラフィクスアップデートを識別する。

『composition_state』は、本 PCSから始まる Display Setが、 Normal Caseであるか、 Acquisition Pointでめる力、、 Epoch Startでめる力を. 示す。

『pallet_update_flag』は、本 PCSにおいて PalletOnly Displey Update がなされているかどうかを示す。

『pallet_id』は、 Pal letOnly Displey Updateに用いられるべきパレットを示す。

『Composition— Object(l) · · · (n)』は、この PCSが属する Display Set 内の、個々のウィンドウをどのように制御するかを示す情報である。図 8 (b) の破線 wdl は、任意の Composition_Object(i)の内部構成をクローズアップしている。この破線 wdl に示すように、 Composition— Object(i) は、『 object— id 』、『 window— id 』ゝ Γ object— cropped— flag 』、『 object— horizontal— position 』ゝ『object一 vertical一 position』、『cropping— rectangle 情報 (1) (2)

(n)』からなる。

『object_id』は、 Composition_Object(i)に対応するウィンドウ内に存在する 0DSの識別子を示す。

『window— id』は、本 PCS において、グラフィクスオブジェクトに割り当てられるべきウィンドウを示す。 1 つのウィンドウには最大 2つのグラフィクスオブジェクトが割り当てられる。

『object— cropped_flag』は、ォブジヱクトノッファにおいてクロップされたグラフィクスォブジェクトを表示するか、グラフィクスォブジヱクトを非表示とするかを切り換えるフラグである。" 1" と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスォブジェタトが表示され、" 0" と設定された場合、グラフィクスォプジヱクトは非表示となる。

『object— horizontal— positionj は、グラフィックスプレーンにおけるグラフイクスォブジヱクトの左上画素の水平位置を示す。

『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。

『 cropping— rectangle 情報（1) (2) (n) 』は、

『object— cropped_flag』が 1 に設定されている場合に有効となる情報要素である。破線 wd2は、任意の cropping— rectangle情報（i)の内部構成をクローズアップしている。この破線に示すように cropping— rectangle 情報 (i) は、

Γ object— cropping—horizontal— position 』、

『 object— cropping— vertical—address』、『 object— cropping—width』、『object— cropping— heightj 力、らなる。

『object— cropping—horizontal— positioiU は、グラフィックスプレーンにおけるク口ップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフイクスォプジェクトの一部を切り出すための枠である。

『object— cropping— vertical— address』は、グラフィックスプレーンにおけるク口ップ矩形の左上画素の垂直位置を示す。

『object— cropping— width』は、グラフィックスプレーンにおけるク口ップ矩形の横幅を示す。

『object— cropping_height』は、グラフィックスプレーンにおけるク口ップ矩形の縦幅を示す。

以上が PCSのデータ構造である。続いて PCSの具体的な記述について説明する。この具体例は、図 6に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとは』『ゥソだった』『あなたが』というように徐々に表示させるというものである。図 9は、かかる字幕表示を実現するための記述例である。本図における Epochは、 DS1 (Epoch Start). DS2(Normal Case), DS3(Normal Case)を有する。 DS1 は、字幕の表示枠となる window を定義する WDS、台詞『ほんとはゥソだったあなたが』を表す 0DS、 1 つ目の PCS を備える。 DS2(Normal Case)は、 2つ目の PCSを有する。 DS3(Normal Case) は 3つ目の PCSを有する。

次に個々の PCS をどのように記述するかについて説明する。 Display Setに属する TOS、 PCSの記述例を図 1 0〜図 1 2に示す。図 1 0は、 DS1 における PCSの記述例を示す図である。

図 1 0 において、 WDS の window_horizontal_position 、 window— vertical—positionは、グラフィックスプレーンにおけるウインドゥの左上座標 LP1を、 window_width, windo _ eig tは、ウィンドウの表示枠の横幅、縦幅を示す。

図 1 0 におけるクロップ情報の object_cropping— horizontal— posi t ion, object— cropping— vertical— po sitionは、ォブジクトノッファにおけるグラフィクスォブジヱクトの左上座標を原点とした座標系においてクロップ範囲の基準 ST1を示している。そして基 ^; 力、ら object— cropping width 、 object— croppingjieight に示される範囲（図中の太枠部分）がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフイツクスプレーンの座標系において object— horizontal— position, object— vertical— position を基準点 (左上）とした破線の範囲 cplに配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドウ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。

図 1 1は、 DS2における PCSの記述例を示す図である。本図における WDS の記述は、図 1 0と同じなので説明を省略する。クロップ情報の記述は、図 1 0 と異なる。図 1 1 におけるクロップ情報の object— cropping— horizontal— posi t ion, object— cropping— vertical— po sition，は、オブジェクトバッファ上の字幕『本当はゥソだった。あなたが』のうち、『ゥソだった』の左上座標を示し、 object— cropping— height, object— cropping— width は、 uゥソにった』の横幅、縦幅を示す。こうすることにより、『ゥソだった』がグラフイツタスプレーンにおけるウインドウ内に書き込まれる。これにより字幕『ゥソだった』は動画像と合成され表示される。

図 1 2は、 DS3における PCSの記述例を示す図である。本図における WDS の記述は、図 1 0と同じなので説明を省略する。クロップ情報の記述は、図 1 0 と異なる。図 1 2 におけるクロップ情報の object— cropping— horizontal— posi t ion, object— cropping— vertical— po sition,は、オブジェクトバッファ上の字幕『本当はゥソだった。あなたが』のうち、『あなたが』の左上座標を示し、 object— cropping— height, object— cropping— width は、 ll ¾なにカ』の横幅、縦幅を示す。こうすることにより、『あなたが』がグラフィックスプレーンにおけるウィンドウ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。

DS1.2.3の PCSを以上のように記述することで、字幕の表示効果を実現することができる。このように PCS の記述により Fadeln/Out や Wipeln/Out, Scroll といった表示効果を実現できることが、本発明に係る PCSの利点である。

以上説明した機能セグメントには、 0DS、 PCSには DTS、 PTSが付加されている。

0DSの DTSは、 0DSのデコードを開始すべき時間を 90KHzの時間精度で示しており、 0DSの PTSはデコードを終了すべき時刻を示す。

PCSの DTS は、 PCSが再生装置上のバッファにロードすべきタィミングを示す。

PCS の PTS は、 PCSを用いた画面のアツプデートを実行するタィミングを示す。

以上説明したように、ビットマップタイプの字幕を構成するグラフィクスストリームは、字幕を表示するための制御情報や、再生時間軸における処理タィミングを示すタィムスタンプを有しているので、再生装置は、このグラフィクスストリームのみを処理することにより、字幕表示を実現することができる。以上が AVClip についての説明である。引き続き Clip情報について説明する。

Cli 情報（XXX.CLPI)は、個々の AVClipについての管理情報である。 Clip情報（XXX.CLPI)は、ビデオストリーム、オーディォストリームについての「属性情報」と、頭出し時のリファレンステーブルである「EP_map」とからなる。

属性情報（Attribute)は.、ビデオストリームについての属性情報 (Video属性情報）、属性情報数（Number)、 AVC1 ipに多重化される複数ォ一ディォストリームのそれぞれについての属性情報（Audio 属性情報 #1 ~#m)からなる。ビデオ属性情報は、ビデオストリームがどのような圧縮方式で圧縮されたか（Coding)、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか（Resolution) アスペクト比はどれだけであるか（Aspect)、フレームレートはどれだけであるか (Framerate)を示す。

一方、オーディオストリームについての属性情報（Audio 属性情報 #1〜 #m)は、そのオーディオストリ一ムがどのような圧縮方式で圧縮されたか（Coding)、そのオーディオストリームのチャネル番号が何であるか (Cli. )、何という言語に対応しているか（Lang)、サンプリング周波数がどれだけであるかを示す。

上述した C l ip情報の Reso l ut i on に、対応する AVCl ip におけるビデォストリ一ムの解像度が、示されることになる。

以上が Cl i p 情報についての説明である。続いてサーバ装置により供給される字幕コンテンツについて説明する。先ずビットマップタイプの字幕コンテンッについて説明する。

ビットマップタィプの字幕コンテンツは、先に示した AVC l ip を構成する複数エレメンタリストリームのうち、グラフィクスストリームのみから構成される。 BD-R0Mにおけるグラフィクスストリーム同様、字幕コンテンッを構成するグラフィクスストリームは、 PCS、 TOS、 PDS、 0DS、 ENDという機能セグメントからなり、各機能セグメントには PTS、 DTSが付加されている。これらのタイムスタンプにより字幕コンテンツは、 BD - ROM側のビデオストリームと、同期表示されることになる。

図 1 3は、映画コンテンツの中身と、字幕コンテンツの中身とを対比して示す図である。図 1 3の上段は、映画コンテンツ側のビデオストリーム及びグラフィクスストリームであり、下段は字幕コンテンツ側のグラフィクスストリ一 Λである。本図の上段における G0P及ぴ Di spl ay Set は、それぞれ AV ストリームの再生開始から 1 分後、 1 分 40秒後、 2分後に再生されるものである。

本図の下段における Di spl ay Set も、それぞれ AV ストリ一ムの再生開始から 1分後， 1分 40秒後、 2分後に再生されるものである。かかる再生タイミングの調整は、 Di sp lay Setに属する I CS、 TOS、 PDS、 0DSに付された PTS、 DTS に、所望の値を設定することでなされる。つまり字幕コンテンツにおける機能セグメントにも、タイムスタンプを付することにより、 HDにおける D i splay Setを、高い時間精度で、動画と同期させるのである。サーバ装置においてこのビットマップタイプの字幕コンテンッは、様々な解像度に応じたものが用意されている。この字幕コンテンッを再生装置からの要求に応じて、サーバ装置 5 0 0からダウン口 —ドすることで、ディスプレイ装置一コンテンツの組合せがどのようなものであっても、制御部 2 0 0は適切な解像度での字幕表示を行うことができる。

以上がビットマップタイプの字幕コンテンッについての説明である。続いてテキストタイプの字幕コンテンッについて説明する。テキストタイプの字幕コンテンツとは、字幕表示のために必要な情報を、テキストデータに対応させることで構成される字幕である。テキストは、ビットマップ字幕に対してデータ量が少なく、比較的転送レートが低い回線でも短時間で転送できる。このため回線速度に制約がある場合は、テキスト字幕の使用が望ましい。

テキストタイプの字幕コンテンッの一例を図 1 4に示す。本図に示すようにテキストタイプの字幕コンテンツは、字幕が存在するチャプターを示すチャプター番号と、字幕の表示開始時刻を示す「開始タイムコード」と、字幕の表示終了時刻を示す「終了タイムコード」と、字幕の「表示色」と、字幕の「サイズ」と、字幕の「表示位置」をテキストデータに対応づけることで構成される。この字幕コンテンッにおいて「サイズ」は、 SDTV ' HDTV のどちらかで表示されることを想定して大きさが定められている。

このテキスト字幕の展開に用いられるフォーマットは、アウトラインフォント（ベクターフォントともいう）であり、輪郭、端点により表現されているため、テキスト字幕の「サイズ」指定に応じて輪郭をスムーズに拡大できる。更に本再生装置はディスプレイ装置一コンテンツの解像度比が 1でない場合、ディスプレイ装置側の解像度に合わせてァゥトラインフォントの拡大'縮小を行い、開始タイムコード、終了タイムコードに基づき字幕表示を行う。尚、本明細書における拡大とは、本来のデ一夕を、より数が多い画素で表現するこという。また本明細書における縮小とは、本来のデータを、より少ない画素で表現するこという。

拡大'縮小がなされたビットマップを表示するのではないので、この字幕コンテンツを用いれば、ジャギーゃ文字潰れがないきれいな字幕表示を行うことができる。

尚テキストデータの表示位置については、図 1 0に示したような WDS の window— horizontal— posi tion、 window— vertical— posi tionに基づき、定めても良い。これらの表示位置は、グラフィクスストリームの製作時に綿密に規定されているので、これらを利用することで、テキスト字幕の見易さを維持することができる。以上が字幕コンテンツの説明である。続いて本発明に係る再生装置の実施形態について説明する。図 1 5 は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的.に生産される。本発明に係る再生装置は、主としてシステム LSI と、ドライブ装置という 2つのパーッからなり、これらのパーツを装置のキヤビネット及び基板に実装することで工業的に生産することができる。システム LSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、 BD ドライブ 1、リードバッファ 2、デマルチプレクサ 3、ビデオデコーダ 4、ビデオプレーン 5、 Background stillプレーン 6、合成部 7、スィッチ 8、 P- Graphics デコーダ 9、 Presentation Graphics プレーン 1 0、合成部 1 1 、フォントゼネレータ 1 2、ト Graphics デコーダ 1 3、スィッチ 1 4、 Enhanced Interactive Graphics プレーン 1 5、合成部 1 6、 HDD 1 7, リードバッファ 1 8、デマルチプレクサ 1 9、オーディオデコーダ 20、スィッチ 2 1、スィツチ 22、静的シナリオメモリ 23、動的シナリオメモリ 24、 CLUT部 26、 CLUT部 27、スィッチ 28、制御部 29から構成される。

BD-R0M ドライブ 1は、 BD- ROM のローディング/イジヱクトを行い、 BD-R0Mに対するアクセスを実行する。

リ一ドバッファ 2は、 FIFO メモリであり、 BD- ROM から読み出された TSバケツトが先入れ先出し式に格納される。

デマルチプレクサ（De-MUX) 3は、リードパッファ 2から TS パケットを取り出して、 TSバケツトを PESバケツトに変換する。そして変換により得られた PESバケツトのうち、所望のものをビデオデコーダ 4、ォーディォデコーダ 20、 P- Graphics デコーダ 9、 I-Graphics デコーダ 1 3のどれかに出力する。

'ビデオデコーダ 4は、デマルチプレクサ 3から出力された複数 PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン 5に書き込む。

ビデオプレーン 5は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。再生装置に複数のプレーンを設けておき、これらプレーンの格納内容を画素毎に加算して、映像出力を行えば、複数の映像内容を合成させた上で映像出力を行うことができる。ビデオプレーン 5における解像度は 1920 x 1080 であり、このビデォプレーン 5に格納されたピクチャデータは、 16ビットの YUV値で表現された画素データにより構成される。

Background stillプレーン 6は、背景画として用いるべき静止画を格納しておくプレーンである。本プレーンにおける解像度は 1920 x 1080 であり、この Background still プレーン 6に格納されたピクチャデー夕は、 16ビットの YUV値で表現された画素データにより構成される。合成部 7は、ビデオプレーン 5に格納されている非圧縮状態のピクチャデータを、 Background stillプレーン 6に格納されている静止画と合成する。

スィッチ 8は、ビデオプレーン 5における非圧縮状態のピクチャデ一夕をそのまま出力するか、 Background stillプレーン 6の格納内容と合成して出力するかを切り換えるスィッチである。

P-Graphics デコーダ 9は、 BD- R0M、 HDD 1 7から読み出されたグラフイクスストリームをデコードして、ラスタグラフィクスを Presentation Graphicsプレーン 1 0に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。

Presentation Graphics プレーン 1 0は、一画面分の領域をもったメモリであり、一画面分のラスタグラフィクスを格納することができる。本プレーンにおける解像度は ί920 X 1080 であり、 Presentation Graphicsプレーン 1 0中のラスタグラフ.イクスの各画素は 8ビットのィンデックスカラーで表現される。 CLUT(Color Lookup Table)を用いてかかるインデックスカラ一を変換することにより、 Presentation Graphics プレーン 1 0に格納されたラスタグラフイクスは、表示に供される。合成部 1 1は、非圧縮状態のピクチャデータ（i)、 Background still プレーン 6の格納内容が合成されたピクチャデータ（ii)の何れかを、 Presentation Graphicsプレーン 1 0の格納内容と合成する。

フォントゼネレータ 1 2は、アウトラインフォントを具備しており、このアウトラインフォントを用いて制御部 29が取得したテキストコードを展開することで文字描画を行う。この展開は、 Enhanced Interactive Graphicsプレーン 1 5上でなされる。

I-Grap .ics デコーダ 1 3は、 BD-R0M、 HDD 1 7から読み出されたインタラタティブグラフィクスストリームをデコードして、ラスタグラフィクスを Enhanced Interactive Graphicsプレーン 1 5に書き込む。ィンタラクティブグラフィクスストリームのデコードにより、対話画面を構成するボタンが画面上に現れることになる。

スィッチ 1 4は、フォントゼネレータ 1 2が生成したフオント列及び制御部 29がダイレクトに描画した描画内容、 I- Graphicsデコーダ 1 3 が生成したボタンの何れかを選択的に Enhanced Interactive Graphics プレーン 1 5に投入するスィツチである。

Enhanced Interactive Graphics プレーン 1 5は、横 1920 X縦 1080 の解像度、横 960 X縦 540の解像度に対応しうる表示用プレーンである。合成部 1 6は、非圧縮状態のピクチャデータ（i)、 Background still プレーン 6の格納内容が合成されたピクチャデータ（ii)、 Presentation Graphicsプレーン 1 0及ぴ Background still プレーン 6の格納内容と合成されたピクチャデータ（iii)を Enhanced Interactive Graphics プレーン 1 5の格納内容と合成する。

HDD 1 7は、サーバ装置からのダウンロードにより取得した字幕コンテンッを格納しておくための内部媒体である。

リードバッファ 1 8は、 FIFO メモリであり、 HDD 1 7から読み出された TSパケットが先入れ先出し式に格納される。

デマルチプレクサ（De-MUX) 1 9は、リードバッファ 1 8から TS パケットを取り出して、 TSバケツトを PESバケツトに変換する。そして変換により得られた PESバケツトのうち、所望のものをオーディオデコーダ 2 0、 P-Grap icsデコーダ 9のどれかに出力する。

オーディオデコーダ 2 0は、デマルチプレクサ 1 9から出力された PESバケツトを復号して、非圧縮形式のオーディォデータを出力する。

スィッチ 2 1は、オーディオデコーダ 2 0への入力源を切り換えるためのスィツチであり、本スィツチによりオーディオデコーダ 2 0への入力は、 BD-R0M側、 HDD側に切り換わる。

スィッチ 2 2は、 P-Graphi csデコーダ 9への入力源を切り換えるスィツチであり、本スィッチ 2 2により HDD 1 7から読み出されたプレゼンテーシヨングラフィクスストリーム、 BD-R0Mから読み出されたプレゼンテ一シヨングラフィクスストリームを選択的に P-Graphi cs デコーダ 9 に投入することができる。

静的シナリオメモリ 2 3は、カレントの CI ip 情報を格納しておくためのメモリである。カレント C l i p情報とは、 BD-R0Mに記録されている複数 C l ip情報のうち、現在処理対象になっているものをいう。

通信部 2 4は、制御部 2 9からの指示に応じてサーバ装置 5 0 0をァクセスし、当該サーバ装置 5 0 0から字幕コンテンッをダウンロードする。

スィッチ 2 5は、 BD- ROM及ぴ HDD 1 7から読み出された各種データを、リードバッファ 2、リードバッファ 1 8、静的シナリオメモリ 2 3、動的シナリオメモリ 2 4のどれかに選択的に投入するスィッチである。

CLUT部 2 6は、ビデオプレーン 5に格納されたラスタグラフイクスにおけるインデックスカラーを、 PDS に示される Y，Cr, Cb値に基づき変換する。

111"部2 7は、 Enhanced I nteract ive Graphi csプレーン 1 5に格納されたラスタグラフィクスにおけるインデックスカラーを、プレゼンテーショングラフィクスストリームに含まれる PDSに示される Y，Cr， Cb値に基づき変換する。

スィツチ 2 8は、 CLUT部 2 7による変換をスルー出力するよ切り換えるスィッチである。制御部 29は、 HDMIを介してディスプレイ装置側の解像度を示す解像度情報を取得する。そしてこれを Clip情報における解像度と比較して、解像度比を算出する。解像度比が 1.0であるなら、 AVClipに多重されているグラフィクスストリームをそのまま表示する。もし解像度比が 1でないなら、 HDD1 7に記録されている字幕コンテンツを表示する。

テキストタイプの字幕コンテンツを表示させる場合、テキストゃフォント種をフォントゼネレー夕 1 2に与えることにより（Text and Font), フォントゼネレータ 1 2 にフォント列を生成させ、 Enhanced Interactive Graphics プレーン 1 5に配置させる。こうして Enhanced InteractiveGraphicsプレーン 1 5の描画がなされれば、ビデオプレ一ン 5の格納内容の拡大 '縮小を命じた上で、 Enhanced Interactive Graphics プレーン 1 5の格納内容を合成部 1 6に合成させる（Display layout ControDo

続いて図 1 6を参照しながら、 P-Graphicsデコーダ 9の内部構成について説明する。図 1 6に示すようにグラフィクスデコーダ 9は、 Coded Data Buffer 33、周辺回路 33 a、 Stream Graphics Processor 34、 Object Buffer 35、 Composition Buffer 36、 Graphics Control ler 3 7から構成される。

Coded Data Buffer 33は、機能セグメントが DTS、 PTSと共に格納されるバッファである。

周辺回路 3 3 a は、 Coded Data Buffer 3 3 - Stream Graphics Processor34間の転送、 Coded Data Buffer33 -Composition Buffer 36間の転送を実現するワイャロジックである。この転送処理において現在時点が 0DS の DTS に示される時刻になれば、 0DS を、 Coded Data Buffer33から Stream Graphics Processor34に転送する。また現在時刻が PCS、PDSの DTSに示される時刻になれば、 PCS、PDSを Composition Buffer 36に転送するという処理を行う。

Stream Graphics Processor 34は、 0DSをデコードして、デコードにより得られたインデックスカラ一からなる非圧縮状態のビットマップをグラフィクスォブジヱクトとして Object Buffer 35に書き込む。 Object Buffer 35は、 Stream Graphics Processor 34のデコードにより得られたダラフィクスオブジェクトが配置される。

Composition Buffer36は、 PCS、 PDSが配置されるメモリである。 Graphics Controller 3 7は、 Composition Buffer 3 6に配置された PCS を解読して、 PCS に基づく制御をする。この制御の実行タイミングは、 PCSに付加された PTSの値に基づく。以上が P- Graphicsデコーダ 9 の内部構成についての説明である。

この Graphics Controller 3 7 について説明する。 Graphics Controllers 7は、図 1 7に示すような処理手順を行うフローチャートである。

ステップ S 1は、本フローチャートのメインルーチンであり、ステツプ S 1に規定した事象の成立を待つ。

ステップ S 1は、現在の再生時点が PCSの DTS時刻になっているか否かの判定であり、もしなつていれば、ステップ S 1〜ステップ S 1 3の処理を行う。

ステップ S 1は、 PCSの composition_stateが、 Epoch— Start であるか否かの判定であり、もし Epoch Startであるなら、ステップ S 6においてグラフィクスプレーン 8を全クリアする。それ以外であるなら、ステツプ S 7 において WDS の windowjiorizontal— position、 indow_vertival_posi tion window_width、 window— height に示される windowをクリアする。

ステップ S 8は、ステップ S 6又はステップ S 7でのクリァ後の実行されるステップであり、任意の ODSx の PTS時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン 8全体のクリアにあたっては、そのクリア時間に長時間を費するので、ある ODS(ODSx)のデコードが既に完了していることもある。ステップ S 8はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかの 0DSのデコード時刻を経過しているなら、ステップ S 9〜ステップ S 1 1を実行する。ステップ S 9は、 object_crop_flagが 0を示しているか否かの判定であり、もし 0を示しているなら、グラフィクスォブジェクトを非表示とする（ステップ S 1 0)。

もし 0を示していないなら、 object— cropping— horizontal— posi tioiu object— cropping— vertival— position 、 cropping— width 、 cropping_height に基づきク口ップされたグラフィクスオブジェクトを、グラフィクスプレーン 8 の window において object_cropping_horizont l_posi tion, obj ect_crop mg_verti val_po sitionに示される位置に書き込む（ステツプ S 1 1 )。以上の処理により、ウィンドウに 1つ以上のグラフィクスォブジヱクトが描かれることになる。

ステップ S 1 2は、別の ODSyの PTS時刻が経過しているか否かの判定である。 ODSx をグラフィクスプレーン 8に書き込んでいる際、別の 0DSのデコードが既に完了していれば、この ODSyを ODSxにして（ステツプ S 1 3)、ステップ S 9に移行する。これにより、別の 0DS に対しても、ステップ S 9〜S 5 1の処理が繰り返し行われる。 '

図 1 8は、映画コンテンッ再生処理の処理手順を示すフローチャートである。ステップ S 2 1において Clip 情報における解像度を参照し、ステップ S 22において HDMIを介して、接続されているディスプレイ装置から解像度を取得する。

ステップ S 23では、映画コンテンツ-ディスプレイ装置間の解像度比を算出する。ステップ S 24において AVCUp に多重されているビデォストリームをビデオデコーダ 4に投入することで動画再生を開始させた後、ステップ S 25において解像度比が 1であるか否かを判定する。もし 1であればステップ S 26においてスィッチ 22、スィッチ 25を切り換えて AVClipに多重されているグラフイクスストリームを CLUT部 9に投入することで字幕表示を実行する。

ステップ S 27では HD に字幕コンテンッが存在するか否かの判定を行う。もし存在すればステップ S 28をスキップしてステップ S 29に移行するが、存在すればステップ S 28においてサーバ装置から HD に字幕コンテンツをダウンロードする。

ステップ S 29では、字幕コンテンツがテキストタイプであるか、ビットマップタイプであるかの判定を行う。もしビットマップタイプであれば、ステップ S 30においてスィッチ 22、スィッチ 25を切り換えて HD上の字幕コンテンッを P- Graphicsデコーダ 9に投入することで字幕表示を実行する。

もしテキストタイプであるなら、ステップ S 3 1において、テキスト字幕の表示処理を行う。

図 1 9は、テキスト字幕表示処理の処理手順を示すフローチヤ一トである。本フ口チャートのステップ S 33〜ステップ S 37からなる処理は、図 1 7のステップ S 1〜ステップ S 1 3に相当する処理であり、ビデオストリームの再生進行に伴い字幕表示を行うというものである。つまり AVClipに多重されたグラフィクスストリームの再生は、 Graphics Controller37に委ねればよいが、テキストデータ再生は制御部 29自らが行う必要がある。制御部 29自らが、テキストデータ再生を行うための処理手順が、この図 1 9である。

ステップ S 33〜ステップ S 3 7のうちステップ S 33〜ステップ S 35は、ループ処理を構成しており、ステップ S 33〜ステップ S 3 5に規定される事象のうち、何れかの成立を判定する。

ステップ S 33は、字幕コンテンツにおける開始タイムコードの中に現在の再生時点に合致するものが存在するかどうかの判定である。もし存在すれば、このタイムコードを開始タイムコード i としてステップ S 36に移行する。ステップ S 36は、アウトラインフォントを用いて、開始タイムコード i に対応するテキストデータ中の文字を展開し、表示する処理である。

ステップ S 34は、現在の再生時点が開始タイムコード i に対応する. 終了タイムコードであるか否かの判定である。もしそうであるなら、ステツプ S 37において表示された文字を消去する。

ステップ S 35は、映画コンテンッの再生が終了したか否かの判定であり、もしそうであるなら、本フローチャートの処理を終了す

次に、ステップ S 36で行われる処理、つまり解像度比に基づくァゥトラインフォントの拡大処理について図 20 (a) 〜（c) を参照しながら説明する。字幕コンテンッにおいて字幕の「サイズ」は、 SDTVZHDTV のどちらかになるように大きさが定められている。これは、字幕グラフイクス同様、 SDTV/HDTV の双方について字幕を製作するのではなく、一方の製作を省略して、製作コストを低減させたいとの映画製作者側の要望からである。ディスプレイ 3 0 0が HDTV であるのに、字幕コンテンッの「サイズ」が SDTV対応であれば、 HDTV型のディスプレイ 3 0 0に、 SDTV対応の字幕を表示せざるを得ない。上述したように HDTV型のディスプレイ 3 0 0は解像度が高いので、 SDTV対応の字幕をそのまま表示したのでは、画面全体に対する字幕の割合が小さくなり、見た目が悪い。そこで制御部 2 9は、字幕コンテンッの表示にあたって制御部 2 9は、ディスプレイ 3 0 0が対応している解像度と、字幕コンテンツが対応している解像度との水平方向の比率、及び、垂直方向の比率をそれぞれ求め、算出された水平方向の比率、及び、垂直方向の比率に応じて、水平方向、及び、垂直方向にァゥトラインフォントを拡大又は縮小する処理を行う。このような拡大処理を行うのは、 1 つの画素の形状が、 SDTV、 HDTVのそれぞれで違っているためである。図 2 0 ( a ) は、 SDTV、 HDTV のそれぞれにおける画素形状を示す図である。 SDTV型のディスプレイ装置は、一画素の形状が横長の長方形になっている。これに対し HDTV 型のディスプレイ装置における一画素の形状は、正方形になっている。そのため、 SDTV の解像度を想定したフオントをそのまま拡大したのでは、図 2 0 ( b ) に示すように、字幕を構成する各文字が縦長になって現れ見苦しい。そこで拡大にあたって、縦'横の拡大率を、それぞれ違う値にする。

ここで SDTV対応の字幕コンテンツを、 HDTV型のディスプレイ装置に表示させるケースを想定する。ディスプレイ装置における解像度が 1920 X 1080であり、映画コンテンツにおける解像度が 720 X 480である場合、水平方向の解像度比は、水平方向の解像度比 = 1 920画素 720画素 2. 67となる。また垂直方向の解像度比は、垂直方向の解像度比 = 1 080画素/ 480画素 = 2. 25となる。こうして水平、垂直方向の解像度比が算出されれば、 SDTV対応のサイズに定められたアウトラインフォントを、図 2 0 ( c ) に示すように横 2. 67倍、縦 2. 25倍に拡大する。このように拡大されたフォントを用いてテキストデータを展開し、開始タイムコード、終了タイムコードに従つて表示させれば、ディスプレイ装置側の解像度に応じた解像度で、字幕を表示させることができる。 1 つの言語体系で使用される文字一式のアウトラインフォントが再生装置に具備されていれば、字幕を適切にディスプレイ装置に表示させることができる。

逆に、 HDTV 対応の字幕コンテンッを、 SDTV 型のディスプレイ装置に表示させるケースでは、水平方向の解像度比 = 720画素 1920画素 = 0. 375となる。また垂直方向の解像度比は、垂直方向の解像度比 = 480画素/ 1080画素 0. 444となる。こうして水平、垂直方向の解像度比が算出されれば、アウトラインフオントを、横 0. 375倍、縦 0. 444倍に縮小する。このように縮小されたフォントを用いてテキストデータを展開し、開始タイムコード、終了タィムコードに従って表示させれば、ディスプレイ装置側の解像度に応じた解像度で、字幕を表示させることができる。アウトラインフォントは、どのような画素数にも拡大可能なので、 SDTV 対応のフォント、 HDTV 対応のフォントのそれぞれを再生装置に具備しておく必要はない。 1 つの言語体系で使用される文字一式のァゥトラインフォントが再生装置に具備されていれば、字幕を適切にディスプレイ装置に表示させることができる。

以上のように本実施形態によれば、映画コンテンッ側の解像度情報と、ディスプレイ装置側の解像度情報との比率が 1 でなければ AVCl ip に多重されているプレゼンテーショングラフィクスストリームに代えて、サ —バ装置から取得した字幕コンテンッを用いるので、 AVCl ipに多重されているプレゼンテーショングラフィクスストリームを拡大'縮小しなくても、ディスプレイ装置側の解像度にあった字幕表示を行うことができる。ビットマップの拡大'縮小は不要なので、たとえ AVC l ipに多重されている字幕がビットマップで描画されていたとしても、字幕を美しく表示することができる。

かかる字幕データの代用は、コンテンツ側の解像度と、ディスプレイ装置側の解像度との比率が 1でない場合になされるので、双方の解像度がー致している場合にはなされない。過剰な字幕データ表示を避けることから、字幕データをサーバ装置からダウンロードすることに伴う通信コストを最低限にすることができる。

(第 2実施形態）

第 1実施形態では解像度比に応じて、アウトラインフォントを拡大 · 縮小することで字幕の大きさを調整した。これに対し第 2実施形態は、ビットマップフォントで、字幕表示を実現する。ビットマップフォントは、アウトラインフォントに比べてその展開に必要とされる処理負荷が小さいので、限られた性能をもつ CPUにおいて字幕を表示する場合に使用すると、好適である。ビットマップフォントでの字幕表示を実現するため、図 1 4に示した字幕コンテンッにおけるテキストデータは、 HTML で記述された HTML 文書に置き換えられている。そして制御部 2 9は、この HTML 文書を解釈して表示処理を行うことで字幕表示を実現する。その一方第 2実施形態に係る制御部 2 9は、ディスプレイ装置一字幕コンテンッの解像度比が 1. 0でない場合、ディスプレイ装置側の解像度に整合するよう、 HTMLで記述された HTML文書に対し、変換処理を施す。図 2 1を参照しながら、第 2実施形態に係る制御部 2 9による変換処理について説明する。図 2 1の HTML 文書において上半分は解像度変換前の HTML文書を、下半分は解像度変換後の HTML文書を示す。

変換前の HTML 文書における解像度情報は、く meta name="Resolution"C0NTENT="48(H">と規定されている部分である。またこの HTML文書における font size descriptionは SDTV型のディスプレィ装置にて表示される場合のビットマップフォントのサイズを示している。つまりく font size=l>であることがわかる。ここでブラウザが表示できるフォントには、複数ポイント数のものがあり、これらは 1から 7までの font sizeで指示することができる。この図 2 1の一例では、最も小さなボイント数のフオントを HTML 文書は、表示に選んでいることを意味する。

制御部 29は、 <meta name="Resolution"CONTENT="480 〉の記述から、この HTML文書が SDTV対応であることを知得する。そして接続されているディスプレー部分 00が、 HDTVであることを HDMI を介して知得すれば、この解像度比から HTML文書におけるく： font size=l〉の記述を、く font size=5>に変換する。このような変換により、ブラウザでの表示時に文字列は拡大表示されることになる。

また〈meta name="Resolution"C0NTENT="480i ">¾r

こうして倍率が算出されれば、フォントを 267%に拡大し、行間を 84% にする。

ここで HTML 文書に以下の文字表示の記述が存在するものとする。これはフォントサイズ =3の文字列を二段表記で表示させるものである。

表示文字列

上述した比率で、この文字列を拡大するよう HTML 文書を書き換えれば以下のようになる。 <f ont s i ze="3" >

く span styl e="f ont-s i ze : 67%； 1 i ne-hei ght： 84%" >

表示文字列

この書き換えにより、文字は 2. 67 倍になるとともに、表示文字列の行間は 84%になるので、図 2 2 ( c ) に示すように、字幕領域の上方向への広がりは抑制され、動画の視認性を妨げない。

(第 3実施形態）

第 3実施形態は「文書 +静止画」で構成されるページコンテンツについての説明である。かかるコンテンツは、マークアップ言語で記述された文書に、静止画をはめ込んで得られる文書であり、 web ページにおいて多く見受けられる。 BD- ROMでも、かかるコンテンツは、メニュ一画像として用いられる。かかるコンテンツにおいて静止画は、文書中の決められた枠内に収められるように縮小されて表示される。

しかしこのように表示されるコンテンツの再生時にあたつて、デイスプレイ装置における対応解像度と、コンテンツにおける対応解像度とが違えば、はめ込みのために縮小した静止画を更に拡大する必要がある。例えば、オリジナルの HTML文書が SDTV対応であり、以下のような記述をもっているものとする。くオリジナルの HTML文書〉

く img src=" . . /pi cture/xxx. j pg 》これを HDTVで表示しょうとすると、第 1実施形態で求めた水平方向、垂直方向の解像度比に基づき、拡大表示させねばならない、この拡大表示を実現するには、 HTMLの上述した記述を、以下のように書き換えればよい,

<変換後の HTML文書 >

く img src=".. / icture/xxx. j g" eight=225% widt =267%> 225%= 1080/480、 267%= 1920/720 文書中の静止画はめ込みでは、原本たる静止画の画素を間引くことで静止画の縮小を行う。そのためかかる間引きで原本たる静止画の一部に欠落がある。一部欠落がある静止画を更に拡大しょうとすると、かかる欠落も拡大されることになるので、静止画の本来の美しさを表現することができない。この欠落について、 JFIF JPEG File Interchange Format)形式の静止画を用いてより詳細に説明する。 JFIF 形式の静止画は、 "appkication TypeO segment",

"start of frame typeO segment", "Image— Width", "Image— Height"という複数の機能セグメントから構成される。

JFIF形式の静止画データのフォーマツトを以下に示す。

Start of image Segment (OxFF, 0xD8)

Start of frame type0(0xFF, OxCO)

Field Length

Sample

Image— Height

Image—Width

End of image Segment このうち水平方向、垂直方向の解像度は、

" Image— Width" , " ImageJIeight"に記述される。 SDTV対応の HTML文書にはめ込まれて表示される場合、この静止画は、水平方向、垂直方向において以下の比率に縮小されて、表示されることになる。水平方向の比率 = 720/Image jidth

垂直方向の比率 = 480/Image— Height

この HTML文書を HDTV型のディスプレイ装置に表示するには、上述のように、水平 ·垂直方向に縮小された静止画を、拡大することになる。つまり静止画は上述したような拡大がなされた場合、水平、垂直方向に以下の比率に示すように拡大されることになる。

水平方向の比率 = 267% · Image_Wi dt

垂直方向の比率 = 225%· Image— Height

はめ込みのために縮小した静止画が更に拡大されれば、上述した欠落が存在する状態のまま拡大されることになり、静止画の本来の美しさが損なわれる。そこで第 3実施形態では、ページコンテンツの再生にあたって、静止画がはめ込まれた状態のページコンテンッを拡大するのではなく、ディスプレイ装置側の解像度と、コンテンツ側の解像度との比率を求め、その比率に基づき、オリジナルの静止画の拡大を行う。具体的にいうと、以下の手法で水平、垂直方向の拡大比率を算出する。水平方向の比率 = 1920/Image— Wi dth

垂直方向の比率 = 1080/Image— Height 静止画に記述されている Image jidth, Image_Height の情報を、 HDTV 側の解像度に合わせて拡大することで、上述したような欠損の拡大は発生しえない。これにより静止画は本来の美しさを損なわずに拡大されることになる。

(備考）

以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（A) (B) (0 (D)……の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及び T それらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。

(備考）

(A)第 1実施形態、第 2実施形態では、補助データの一例として字幕データについて説明したが、これに限らない。動画と共に再生されるのであれば、メニューやポタン、アイコン、バナーであってもよい。

(B)表示の対象は、装置側のディスプレイ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィタスが

BD-R0Mに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、 PCS に基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレイ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。

(C)字幕は、映画の台詞を表す文字列であるとして説明を進めたが、商標を構成するような図形，文字，色彩の組合せや、国の紋章，旗章，記章, 国家が採用する監督/証明用の公の記号 ·印章、政府間国際機関の紋章，旗章，記章，特定商品の原産地表示を含んでいてもよい。

(D)第 1実施形態では、字幕を画面の上側、下側に横書きで表示するものとしたが、字幕を画面の右側、左側に表示するものとしてもよい。こうすることにより、日本語字幕を縦書きで表示することができる。

(E)各実施形態における AVCl ipは、映画コンテンツを構成するものであつたが、 AVC l ipはカラオケを実現するものであってもよい、そしてこの場合、歌の進行に応じて、字幕の色を変えるという表示効果を実現してもよい。

(F)第 1実施形態、第 2実施形態において再生装置は、字幕データの供給をサーバ装置から受けているが、サーバ装置以外の供給源から供給を受けてもよい。例えば、 BD- ROM以外の記録媒体を別途購入し、これを HDD にインストールすることで字幕データの供給を受けても良い。また字幕データが記録された半導体メモリと接続することで字幕データの供給を受けてもよい。産業上の利用可能性

本発明に係る記録媒体、再生装置は、ディスプレイ装置一コンテンツの組合せに応じた字幕表示を実現することができるので、より付加価値が高い映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。

Claims

6H 求の

1 . 再生装置であって、

動画データにおけるフレーム画像を表現するための解像度を検出する検出手段と、

再生装置に接続されたディスプレイ装置の解像度と、検出手段により検出された解像度との比率が 1である場合、動画データと多重化されて記録媒体に記録されている補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 1表示手段と、

解像度の比率が 1でない場合、サーバ装置から供給された補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 2 表示手段と

を備えることを特徴とする再生装置。

2 . サーバ装置から供給される補助データはテキストデータであり、前記第 2表示手段による補助データ表示は、

フォントを用いて、テキストデータを展開することでなされる、請求項 1記載の再生装置。

3 . 前記第 2表示手段は、テキストデータの展開にあたって、ディスプレイ装置が対応している解像度と、補助データが対応している解像度との水平方向の比率、及び、垂直方向の比率をそれぞれ求め、算出された水平方向の比率、及び、垂直方向の比率に応じて、水平方向、及び、垂直方向にフォントを拡大又は縮小する

ことを特徴とする請求項 2記載の再生装置。

4 . 補助データが、複数行にわたって表示される字幕である場合、前記第 2表示手段は、所定の比率に従い、字幕の行間を調整する処理を行う

ことを特徴とする請求項 3記載の再生装置。

5 . 前記所定の比率は、

ディスプレイ装置の縦画素数と、動画データの縦画素数との比率を、ディスプレイ装置の横画素数と、動画データの横画素数の比率で割った値である、請求項 4記載の再生装置。

6 . コンピュータに再生処理を行わせるプログラムであって、動画データにおけるフレーム画像を表現するための解像度を検出する検出ステップと、

再生装置に接続されたディスプレイ装置の解像度と、検出手段により検出された解像度との比率が 1である場合、動画データと多重化されて記録媒体に記録されている補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 1表示ステップと、

解像度の比率が 1でない場合、サーバ装置から供給された補助データを、動画データと同期させながら前記ディスプレイ装置に表示する第 2 表示ステップと

をコンピュー夕に実行させることを特徴とするプログラム。