再生装置、再生方法、プログラム
【課題】再生装置の実装の自由度を奪うことなく、ティアリングに起因する左右の映像の不整合の発生を、最低限に抑える。
【解決手段】ビデオストリームの再生時間軸における複数のフレーム期間のうち、i番目のフレーム期間において表示されるべき立体視映像に描画イメージを合成する場合、i番目のフレーム期間が開始されるまでに、レフトビュープレーンメモリへの描画イメージの書き込み、及び、ライトビュープレーンメモリへの描画イメージの書き込みを完了する必要がある。この書き込みの指示を同時に命じるべく、アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む。
【解決手段】ビデオストリームの再生時間軸における複数のフレーム期間のうち、i番目のフレーム期間において表示されるべき立体視映像に描画イメージを合成する場合、i番目のフレーム期間が開始されるまでに、レフトビュープレーンメモリへの描画イメージの書き込み、及び、ライトビュープレーンメモリへの描画イメージの書き込みを完了する必要がある。この書き込みの指示を同時に命じるべく、アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、立体視再生の技術分野に属する発明である。
【背景技術】
【０００２】
立体視再生とは、ライトビュー用とレフトビュー用の２つの視点の映像を準備することにより、立体視を実現する技術である。立体視ディスプレイの実現にはさまざまな方式があるが、視聴者の左眼と右眼とに、異なる表示画像を見せ、その両眼間の視差を利用することにより、立体的な映像を擬似的に作ることが基本原理である。
例えば、立体視表示の実現方式の一つにシャッター眼鏡を利用した方式がある。この方式では、表示ディスプレイの映像を左眼用と右眼用とで高速で更新する。この更新タイミングと同期させて、視聴者の左眼と右眼の視野をメガネによって交互に高速に塞ぐことで、ディスプレイで表示される左眼用の画像はシャッター眼鏡により左眼だけによって見え、逆に右眼用の画像は右眼によってだけ見える仕組みを実現できる。
【０００３】
現状、ビデオストリームの立体視再生を利用する形態は、劇場等での応用が主流であるが、今後は家庭設置用の再生装置で立体視ビデオストリームを再生して楽しむ利用形態も普及が予想される。
特にBD-ROM等のパッケージメディアでは、ビデオだけでなく、背景イメージ、字幕、そして描画イメージを別々のプレーンとして持ち、表示機器にはこれらを重ね合わせた映像を表示することができるので、これら背景イメージ、字幕、そして描画イメージのそれぞれで立体視を行えば、対話性の富んだ、立体視再生を実現することができる。これらのうち、ビデオおよび字幕については、再生装置の映像出力信号とフレーム単位で同期する方式が採用されているため、ちらつきのない美しい動画再生が実現されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平９-１３９９５７号公報
【特許文献２】特開２０００-１０２０３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで立体視コンテンツの再生時に、アプリケーションを起動して、動画再生に同期したGUIをアプリケーションに描画させることで、立体視コンテンツの再生時におけるユーザ操作を容易に行わせたいという要望がある。これは、既存のBD-ROMコンテンツにおいて、コンテンツと、アプリケーションとを連動させて、アプリケーションにGUI処理を行わせるという高度な処理が実現されており、これを立体視コンテンツでも実現したいというコンテンツ制作者側からの要望による。
【０００６】
アプリケーションによる描画は、ビットマップパターンを生成して、そのビットマップパターンを１画素ずつ、左右のプレーンメモリに書き込むという処理になる。このような描画を繰り返すことにより、メニューのオープンにあたって、アニメーションによる視覚効果を導入することができる。ところが、画素書き込みの途中で、表示を行うべきフレーム期間が到来した場合、画素の書込途中の映像内容が、表示に供されることになる。画素書き込みの途中で、表示を行うべきフレーム期間が到来し、書込途中の映像内容が表示されることで画面のちらつきが生じることを、”ティアリング”という。
【０００７】
平面視再生においてティアリングは、ユーザの許容範囲となるが、立体視再生の場合、ティアリングは、深刻な不快感をもたらす。右目用プレーンメモリ、左目用プレーンメモリのうち、双方の描画が完了している箇所では立体視効果が生じるものの、ティアリングによって未描画になっている部分では立体視効果が生じないばかりか、左右の目で全く異なる映像が見えるという、現実には起こり得ない状況となるからである。例えば、左目におけるメニューの描画が完了したが、右目におけるメニューの下半分の描画が未完である場合、立体視再生時において、メニューの下半分の部分では左右両眼の間で映像の不整合が生じることになり、ユーザに視覚的な不快感を与える。
【０００８】
立体視再生時におけるティアリングは、左右の映像の不整合という現象が顕在化するので、かかる不整合を確実に防ぐ手だてがないと、立体視再生を行うような再生装置の商品化は難しい。かかる技術的障壁に対しては、左右のイメージプレーンに対する書き込みを完全並列化することが考えられる。しかし再生装置プレーヤモデルの策定にあたって、このようなイメージプレーン書き込みの完全並列化を強制するのは再生装置の実装の自由度を奪うことになり望ましくない。また、ハードウエアの簡易化の余地を奪うので、低コスト競争の足かせになることは明確である。
【０００９】
本発明の目的は、再生装置の実装の自由度を奪うことなく、ティアリングに起因する左右の映像の不整合の発生を、最低限に抑えることができる再生装置を提供することである。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明にかかる再生装置は、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生部と、
アプリケーションを動作させるプラットフォーム部と、
複数のプレーンメモリと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、複数のプレーンメモリに対する描画イメージの書き込みを行う描画部とを備え、
複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする。
【発明の効果】
【００１１】
アプリケーションプログラムインターフェイスの呼び出し時において、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアがバイトコードアプリケーションから引き渡されるので、右目用のプレーンメモリへの画素書き込みと、左目用プレーンメモリへの画素書き込みとを交互に行うような実装が可能になる。この場合、画素書き込みの途中で、表示を行うべきフレーム期間が到来したとしても、画素書き込みの進捗は、右目用と、左目用とで大体同じになる。たとえティアリングが生じたとしても、右目におけるティアリングと、左目におけるティアリングとは同一になるから、両目に映じる映像内容が一致しない映像の不整合の発生は避けられるか、発生したとしても、ユーザに不快を感じさせない許容範囲になる。
【００１２】
左イメージプレーン、右イメージプレーンのうち、どちらか一方の書き込みを先に行い、他方を後にするとの実装であっても、パラメータがアプリケーションから引き渡されないことによる遅延を避けることができるので、表示を行うべきフレーム期間の到来までに、左イメージプレーン、右イメージプレーンへの書き込みを同時に完了させる確率を高めることができる。
【００１３】
イメージプレーンに対する書き込みをライン単位で行う場合であっても、左イメージプレーン→右イメージプレーンの順に行う場合であっても、両目に映じる映像内容が一致しない映像の不整合の発生確率を低下させうるので、再生装置の実装の自由度を奪うことなく、ティアリングに起因する左右の映像の不整合の発生を、最低限に抑えることができる。
【図面の簡単な説明】
【００１４】
【図１】再生装置の使用行為についての形態の一例を示す図である。
【図２】本願の課題解決手段を具備した再生装置の基本的な内部構成を示す。
【図３】ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。
【図４】イメージプレーン１０４c,１０４dの内部構成を示す。
【図５】プレーンオフセットの符号が正（レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす）である場合、像が表示画面よりも手前にあるように見える原理を説明するための図である。
【図６】像が表示画面よりも奥にあるように見える原理を説明するための図である。
【図７】正と負のプレーンオフセットの見え方の違いの一例を示す図である。
【図８】描画イメージの書き込みに用いられるアプリケーションプログラムインターフェイスを示す。
【図９】図８のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。
【図１０】図９（ｃ）のように引数が指定された場合、StereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。
【図１１】フレームi,j,kのそれぞれにおける、左右イメージメモリ、左右のイメージプレーンの書き込み内容を示す。
【図１２】フレームi,j,kにおけるイメージプレーンの書き込み内容が図１１のものである場合、どのようなエフェクトが再生されるかを示す。
【図１３】左右のイメージプレーンへの書き込みをどのように行うべきかを示す。
【図１４】StereoGraphics#drawImageを用いず、左イメージプレーン、右イメージプレーンのそれぞれに対して、個別に、書き込みを行う場合、表示内容がどのようになるかを示す。
【図１５】StereoGraphics#drawImageを用いて、左イメージプレーン、右イメージプレーンのそれぞれに対して、画素の書き込みをライン単位に交互に行う場合、表示内容がどのようになるかを示す。
【図１６】バイトコードアプリケーションによるメニュー表示のフローチャートである。
【図１７】StereoGraphics#drawImageがコールされた際のライン描画手順を示すフローチャートである。
【図１８】第２実施形態に係る再生装置のうち、改良が施された部分（イメージメモリ、イメージプレーン、レンダリングエンジン、合成部）のみを描く。
【図１９】スイッチ１２３、スイッチ１２４による切り替えを示す。
【図２０】左右のイメージプレーンへの書き込みをどのように行うべきかを示す。
【図２１】StereoGraphics#drawImageがコールされた際のダブルバッファを用いた描画手順を示す。
【図２２】動作モードオブジェクトの内部構成の一例を示す図である。
【図２３】タイトル切り替え時におけるプレーンメモリの解像度設定の処理手順の一例を示すフローチャートである。
【図２４】BD-ROM１００の内部構成を示す図である。
【図２５】第４実施形態に係る再生装置の内部構成を示すブロック図である。
【図２６】左右プレーンの交互出力を実現する場合のフレーム処理の処理手順を示すフローチャートである。
【図２７】描画要求の発行タイミングの調整を伴う場合の左右描画処理調停部３０の処理手順を示すフローチャートである。
【図２８】ラインの交互出力を実現する場合の、フレーム処理を示すフローチャートである。
【図２９】描画要求の統合を伴う左右描画処理調停部３０の処理手順を示すフローチャートである。
【図３０】左右同時描画要求Cと、描画要求A,Bを示す図である。
【図３１】画面更新要求をトリガとした左右描画処理調停部３０の処理手順を示すフローチャートである。
【図３２】左イメージプレーン９と右イメージプレーン１０とを連結することで構成される連結イメージプレーンを示す。
【図３３】描画要求の切り抜きを伴う左右描画処理調停３０の処理のフローチャートである。
【図３４】描画要求と、左右同時描画要求とを示す。
【図３５】描画要求の変換を伴う左右描画処理調停部３０の処理のフローチャートである。
【発明を実施するための形態】
【００１５】
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。
図１は、記録媒体、再生装置の、使用行為についての形態の一例を示す図である。本図に示すように、記録媒体１００、再生装置２００は、リモコン３００、テレビ４００、シャッター眼鏡５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
【００１６】
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、テレビ４００と接続され、記録媒体１００を再生する。かかる再生は、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力を交互に繰り返すことでなされる。こうして再生される再生映像には、2D映像、3D映像が存在する。2D映像とは、例えば表示装置の表示画面を含む平面をX-Y平面として捉えて、このX-Y平面上に位置する表示画面の表示位置における画素にて表現される画像であり、平面視画像とも呼ばれる。
【００１７】
対照的に3D映像とは、上述のX-Y平面として捉えた平面と直交する直線を軸とし（本実施の形態ではX-Y平面に垂直な直線を軸（Z軸）として定義する）、表示装置の表示画面におけるX-Y平面上の画素に、本実施の形態で説明する構成を採用することにより、人の目には立体的に見えるようにした、または表示画面よりも手前または奥に見えるようにした映像である。
リモコン３００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン３００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
【００１８】
表示機器４００は、再生装置２００からの映像出力を受け取って、L画像とR画像とを同じタイミングでそのまま交互に出力する。タイミングの同一化は、映像出力と表示切り替えのフレームレートを同一とすることで実現される。視聴者の眼の負担を軽減するため、表示切り替え側のフレームレートのみを逓倍する構成をとることもできる。この場合は、L画像および続いて出力されたR画像のセットを表示ディスプレイ４００が蓄積し、表示ディスプレイ側でこれらの画像を高速に切り替えることで、高フレームレートの表示を行うこととなる。以降の説明においては、L画像、R画像の順番で出力された画像が表示ディスプレイ側でセットとして扱われることを前提として説明を行う。但し、逆順であっても同様の構成を取ることができる。
【００１９】
シャッター眼鏡５００は、液晶シャッターと、制御部とから構成され、ユーザの両目における視差を用いて立体視を実現する。シャッター眼鏡５００の液晶シャッターは、印加電圧を変えることにより、光の透過率が変化する性質を有する液晶レンズを用いたシャッターである。シャッター眼鏡５００の制御部は、再生装置から送られるR画像とL画像の出力の切り替えの同期信号を受け、この同期信号に従って、第１の状態、第２の状態の切り替えを行う。
【００２０】
第１の状態とは、右目に対応する液晶レンズが光を透過しないように印加電圧を調節し、左目に対応する液晶レンズが光を透過するように印加電圧を調節した状態であり、この状態において、左目にL画像が入射し、右目にはL画像が入射されない状態となる。
第２の状態とは、右目に対応する液晶レンズが光を透過するように印加電圧を調節し、左目に対応する液晶レンズが光を透過しないように印加電圧を調節した状態であり、この状態において、右目にR画像が入射し、左目にはR画像が入射されない状態となる。
【００２１】
一般にR画像と、L画像とは、その撮影位置の差に起因して、ライトビューから見える像とレフトビューから見える像には見え方に若干の差があるような画像である。
この像の見え方の差の程度を人間の左目／右目のそれぞれから見える像の差の程度（つまり、視差の程度）とすることにより、利用して人間の目から見える像を立体として認識できるのである。そこで、シャッター眼鏡５００が、以上のような第１の状態、第２の状態の切り替えを、R画像とL画像の出力の切り替えタイミングに同期させれば、ユーザは、平面的な表示が立体的に見えると錯覚する。次に、R画像、L画像を表示するにあたっての時間間隔について説明する。
【００２２】
具体的には、平面表示の画像において、R画像とL画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であれば足りる。本実施形態では、テレビ４００がビデオストリームを再生するための表示周期を示すフレーム期間を2つに分割して、分割により得られたそれぞれの期間を、右目、左目を切り替えるための時間間隔とする。フレーム期間を分割することで得られた期間のうち、左目で視聴させるための期間を”レフトビュー期間”という。また右目で視聴させるための期間を”ライトビュー期間”という。ここでフレーム周期が1/24秒であれば、レフトビュー期間、ライトビュー期間はそれぞれ、1/48秒となる。フレーム周期が1/60秒であれば、レフトビュー期間、ライトビュー期間はそれぞれ、1/120秒となる。
【００２３】
（第１実施形態）
以下、本願明細書の課題解決手段を具備した再生装置の実施形態のうち、イメージプレーンに、シングルバッファを用いた再生装置の実施形態について説明する。図２は、本願の課題解決手段を具備した再生装置の基本的な内部構成を示す。本図に示すように、再生装置２００は、読出部１０１、ビデオデコーダ１０２、プレーンメモリセット１０３（ビデオプレーン１０４a,１０４b、イメージプレーン１０４c,１０４dを含む）合成部１０５、イメージメモリ１０６、レンダリングエンジン１０７、プラットフォーム部１１０、ヒープメモリ１１１、バイトコードインタプリタ１１２、クラスローダ１１３、アプリケーションマネージャ１１４、ミドルウェア１１５から構成される。
【００２４】
読出部１０１は、記録媒体１００からビデオストリーム、描画イメージのデータ構造体、バイトコードアプリケーションのクラス構造体、アプリケーション管理テーブルを読み出し、ビデオストリームについてはビデオデコーダ１０２に供給する。
ビデオデコーダ１０２は、読み出されたビデオストリームを復号して非圧縮形式のピクチャをプレーンメモリセット１０３に書き込む。
【００２５】
プレーンメモリセット１０３は、複数のプレーンメモリから構成される。プレーンメモリとは、一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオ、字幕、GUI、背景画像のデコードによって得られた1画面分の画素データを格納する。
【００２６】
これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。このレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
【００２７】
左ビデオプレーン１０４aおよび右ビデオプレーン１０４bは、プレーンメモリセットの1つであり、それぞれ左眼用のビデオのピクチャ、右眼用のビデオのピクチャが格納される。
左イメージプレーン１０４cおよび右イメージプレーン１０４dは、プレーンメモリセットのうちの1つであり、ビデオプレーンの上の重畳させるべきイメージを非圧縮形式で格納する。左イメージプレーン１０４cは、左眼用のイメージデータを格納するレフトビュープレーンメモリである。右イメージプレーン１０４dは、右眼用のイメージデータを格納するライトビュープレーンメモリである。本実施形態において左イメージプレーン及び右イメージプレーンは、それぞれシングルバッファから構成されているので、各イメージプレーンに格納されている描画イメージであって、現在表示対象になっているものに、新たな描画イメージを上書きすることにより、各イメージプレーンの画面更新を行う。イメージプレーンにおける直前の表示対象である描画イメージに、新たな表示対象である描画イメージを直接上書きするので、上書き処理の途上においては、直前の表示対象である描画イメージと、新たな表示対象である描画イメージとが混在したようなティアリングが発生する。
【００２８】
合成部１０５は、複数のプレーンメモリのレイヤ合成を行う。
イメージメモリ１０６は、記録媒体１００に記録されたデータ構造体のインスタンスが生成された場合、データ構造のインスタンスであるイメージオブジェクトを格納しておくためのメモリである。かかるイメージオブジェクトは、RGB値のビットマップであり、バイトコードアプリケーションからはインスタンス変数によって指示される。3Dモードでは、右用のイメージオブジェクト、左目用のイメージオブジェクトを個別に格納することができる。
【００２９】
レンダリングエンジン１０７は、左イメージプレーン１０４cおよび右イメージプレーン１０４ｄに対する描画処理を行う。レンダリングエンジン１０７によるイメージ描画は、イメージメモリ１０６上のイメージオブジェクトを、イメージメモリ１０６からイメージプレーン１０４c,１０４dにコピーすることでなされる。コピーの対象になるイメージオブジェクトは、インスタンス変数で指示される。
【００３０】
プラットフォーム部１１０は、ROM等の不揮発性メモリに記憶された組込みプログラムと、この組込みプログラムを実行するハードウエア(MPU、レジスタ、周辺回路を含む)とから構成され、記録媒体１００に記録されたクラス構造体のインスタンスであるバイトコードアプリケーションを動作させる。ここでバイトコードアプリケーションとは、オブジェクト指向プログラミング言語を用いて記述されたクラス構造体をコンパイルすることで得られた実行形式のプログラムであり、機器に依存しないコード(バイトコード)によって記述されているものをいう。バイトコードアプリケーションとして典型的なものにはJava（登録商標）アプリケーションがある。
【００３１】
ヒープメモリ１１１は、バイトコードアプリケーションを構成するバイトコードやバイトコードアプリケーションが利用するシステムパラメータが配置されるスタック領域である。ヒープメモリ１１１上で動作するバイトコードアプリケーションによる描画は、１／３０秒、１／１５秒、１／５秒などのように、可変のフレームレートでなされる。このフレームレートは、ビデオ再生のフレームレートである１／２４秒、１／６０秒と整数倍にならないので、バイトコードアプリケーションは、再生装置のクロックを用いて、自身の描画タイミングに到来したかどうかを検知し、描画タイミングが到来すれば、書き込みを行う。
【００３２】
バイトコードインタプリタ１１２は、ヒープメモリ１１１に格納されているバイトコードアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
クラスローダ１１３は、記録媒体１００に記録されたアプリケーションのクラス構造体のインスタンスをヒープメモリ１１１に生成することにより、バイトコードアプリケーションのロードを行う。
【００３３】
アプリケーションマネージャ１１４は、アプリケーション管理テーブルに基づき、バイトコードアプリケーションの正当性を検証した上で、バイトコードアプリケーションを起動したりバイトコードアプリケーションを終了したりする等、バイトコードアプリケーションのアプリケーションシグナリングを行う。
ミドルウェア１１５は、プラットフォーム部で動作しているバイトコードアプリケーションに対して、各種機能を提供する組込み機器用のオペレーティングシステムである。機能提供は、ミドルウェアが実装しているパッケージのメンバー関数を呼び出すことでなされる。ミドルウェアが実装しているパッケージは、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等の描画処理を、レンダリングエンジン１０７を通じて左イメージプレーン１０４cおよび右イメージプレーン１０４dに対して行うライブラリを含む。そしてミドルウェア１１５は、このライブラリの機能によって、イメージ描画を実行する描画部を具備している。バイトコードアプリケーションはこれらの描画処理の要求を連続的に発行することで、様々なグラフィクス描画処理を実現することができる。かかるパッケージには、java.awtパッケージがあり、イメージ描画のアプリケーションプログラムインターフェイスは、このjava.awtパッケージのメソッドになる。他、java.awtパッケージにはない拡張メソッドも、イメージ描画のAPIとなる。イメージ描画の内容には、線や矩形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等があり、これらのイメージ描画は、描画内容の種別を示す情報によって識別される。
【００３４】
本実施形態では、バイトコードアプリケーションからの要求によるイメージ描画にあたって、ミドルウェアは、１画面分のイメージプレーンの描画イメージの書き込みに、ｎフレームに相当する実行サイクルを必要とすると仮定する。これは、バイトコードアプリケーションによってAPIがコールされてから、ミドルウェアがそのレスポンスを返すまでのターンアラウンド時間であり、プラットフォーム部−ミドルウェア−ハードウエア間のオーバーヘッドを含む。一般にJavaアプリケーションの実装において、ある画像を描画したくなったら、その場(例えばkフレーム)で描画命令を発行し、その発行から所定のフレームの遅延時間後に表示がなされることになる。この表示時における遅延時間について、Javaアプリケーションはケアしないことが一般的である。
【００３５】
そうすると、左イメージプレーン、右イメージプレーンの双方への描画イメージの書き込みのために、２×ｎフレームに相当する遅延時間が必ず発生することになる。例えば、任意のフレームｋにおいて、立体視のための描画イメージを表示させたい場合、フレームｋでStereoGraphics#drawImageメソッドを発行すれば、このフレームｋから”２×ｎフレーム”だけ遅れて、描画イメージが表示されることになる。
【００３６】
以下、これらの構成要素の処理内容を、参考図を交えてより更に詳しく説明する。
図３は、ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。
図中の矢印vw1は、レフトビュー期間における視点への映像入力を示し、図中の矢印vw2は、ライトビュー期間における視点への映像入力を示す。レフトビュー期間では、矢印vw1に示すように、レフトビュー期間では、左ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの左目に入射する。ライトビュー期間では、この矢印vw2に示すように、右ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの右目に入射する。
【００３７】
図４は、イメージプレーン１０４c,１０４dの内部構成を示す。解像度が1920×1080に設定されている場合、同図（ａ）に示すように、イメージプレーン１０４c,１０４dは横1920×縦1080の３２ビット長の記憶素子からなる。イメージプレーン１０４c,１０４dは、1920×1080の解像度で、1画素当たり３２ビットのR,G,B,α値を格納できるメモリアロケーションをもつ。記憶素子に記憶される３２ビットのR,G,B,α値は、８ビットのR値、８ビットのG値、８ビットのB値、８ビットの透明度αから構成される。１画面分のプレーンメモリの規模は、８Ｍバイトであり、左右のプレーンメモリの双方でダブルバッファを構成しようとすると、８Ｍバイト×４ものメモリ規模が必要になる。そしてダブルバッファでは、画面切り替え時にバッファからバッファへの転送が必要になり、この８Ｍバイトという規模のデータ転送が頻発するので、必要となるメモリ帯域が多大になる。このような事情から本実施形態では、イメージプレーンをシングルバッファによって構成している。
【００３８】
同図（ｂ）は、イメージプレーン１０４c,１０４dに格納されている画素データを示す。本図に示すように、イメージプレーン１０４c,１０４dに格納されているグラフィクスデータは、前景部分にあたる画素データ、背景部分にあたる画素データから構成される。ここで背景部分にあたる記憶素子には、透明色を示すα値が格納されており、この部分には、ビデオプレーンとの合成時において、イメージプレーンの字幕やビデオプレーンにおける動画像が透けて見えるようになる。一方、前景部分にあたる記憶素子には、透明色以外を示すR,G,B値が格納されており、この透明色以外のR,G,B値によって、描画イメージが描かれることになる。
【００３９】
合成部１０５によるプレーン合成時において、透明画素にあたる部分には、他のプレーンメモリの格納内容が透けて見えるようになり、かかる透明部分の存在によって、プレーン合成が可能になる。
図５は、プレーンオフセットの符号が正（レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす）である場合、像が表示画面よりも手前にあるように見える原理を説明するための図である。
【００４０】
本図において、丸で示したものは、表示画面上に表示される像である。まず、2Dモードである場合、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図５（ａ））。結果として表示される像は表示画面上に位置する。
レフトビュー期間において、左目に見える像はプレーンオフセットが０の場合に比べて右側の位置に見えるようシフトして表示する。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、プレーンオフセットが０の場合に比べて左側の位置に見えるようにシフトして表示する。このとき左目にはシャッター眼鏡５００により何も見えないようにする（図５（ｂ））。
【００４１】
人間は両目を用いて焦点をあわせてその焦点位置に像があるように認識する。従って、シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態とを交互に短い時間間隔で切り替えると、人間の両目は表示画面よりも手前の位置に焦点位置を、合わせようとし、結果として表示画面よりも手前に位置する焦点位置に像があるように錯覚を起こす（図５（ｃ））。
【００４２】
図６は、像が表示画面よりも奥にあるように見える原理を説明するための図である。
図６において、丸で示したものは、表示画面上に表示される像である。まず2Dモードにおいて、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図６（ａ））。結果として表示される像は表示画面上に位置する。
【００４３】
一方、レフトビュー期間において、左目に見える像はプレーンオフセットが０の場合に比べて左側の位置に見えるようにする。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、オフセットが０の場合に比べて右側の位置に見えるようにする、このとき左目にはシャッター眼鏡５００により何も見えないようにする（図６（ｂ））。
【００４４】
シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態と互に短い時間間隔で切り替えると、人間の両目は表示画面よりも奥の位置に焦点位置を、合わせようとし、結果として表示画面よりも奥の位置に像があるように錯覚を起こす（図６（ｃ））。
図７は、正と負のプレーンオフセットの見え方の違いの一例を示す図である。
【００４５】
本図（ａ）は、レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす場合を示す。図５に示したようにレフトビュー出力時の字幕がライトビュー出力時の字幕より右の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより手前にくるので、字幕も手前に見えるようになる。
【００４６】
本図（ｂ）は、レフトビュー期間における描画イメージの書き込み位置を左方向へずらし、ライトビュー期間における描画イメージの書き込み位置を右方向へずらす場合を示す。図６に示したように、レフトビュー出力時の字幕がライトビューの出力時の字幕より左の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより奥にゆくので、字幕も奥に見えるようになる。
【００４７】
図８は、描画イメージの書き込みに用いられるアプリケーションプログラムインターフェイスを示す。
同図（ａ）におけるjava.awt.Graphics#fillRectメソッドは、第１引数の位置で指定された矩形範囲を、第２引数で指定された色(正確にはjava.awt.Graphics#setColorメソッドで指定されたカレント色であるが、簡略化のため、以下では第２引数として説明を行う)で塗り潰す機能を呼び出すアプリケーションプログラムインターフェイスである。描画対象プレーンとしては、左イメージプレーン１０４cおよび右イメージプレーン１０４dの他に、BD-Jアプリが独自に生成した一時処理用の描画領域（BufferedImage）を対象とすることもできる。矩形範囲の位置は、描画先となる矩形領域の左上の座標（x１，y１）と右下の座標（x２，y２）の組み合わせで表現される。描画対象プレーンとしては、左イメージプレーン１０４cおよび右イメージプレーン１０４dの他に、BD-Jアプリが独自に生成した一時処理用の描画領域（BufferedImage）を対象とすることもできる。
【００４８】
同図（ｂ）におけるjava.awt.Graphics#drawImageメソッドは、第１引数の位置で指定された描画位置に、第２引数で指定された描画イメージを書き込む機能を呼び出すためのAPIである。正確には、指定された描画イメージを矩形にトリミングしてから描画するための、矩形位置を指定する引数を渡すことも可能であるが、ここでは省略する。
StereoGraphics#drawImageメソッドは、左イメージプレーンにおいて、第１引数の位置で指定された矩形範囲に、第２引数で指定された描画イメージを書き込み、右イメージプレーンにおいて、第３引数の位置で指定された矩形範囲に、第４引数で指定された描画イメージを書き込む機能を呼び出すAPIである。
【００４９】
矩形範囲は、描画先となる矩形領域の左上の座標（x１，y１）と右下の座標（x２，y２）の組み合わせで表現される。また、イメージオブジェクトとしては、JPEGやPNG形式のデータ構造から生成したインスタンス（ビットマップ画像）の他に、BufferedImageを用いることができる。
前述したようにjava.awt.Graphics#drawImageメソッドではイメージコピー処理が規定されているが、この処理では１つの矩形領域のコピーしか指定することができない。一方、StereoGraphics#drawImageメソッドによる左右同時イメージコピーは、描画位置と描画イメージとのペアを含む。描画先プレーンはそれぞれ左イメージプレーン１０４cと右イメージプレーン１０４dに固定されているものとし、イメージプレーンの指定は、StereoGraphics#drawImageメソッドの引数から除外されている。BD-ROM再生装置にStereoGraphics#drawImageメソッドを実装しようとする場合、StereoGraphics#drawImageメソッドによる左右同時イメージコピー処理はBD-Java規格上は存在しないため、例えばStereoGraphics#drawImageのような拡張メソッドを追加する必要がある。
【００５０】
図９は、図８のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。同図（ａ）は、APIの種別がjava.awt.Graphics#fillRectメソッドである場合、描画すべき矩形範囲、描画色が、具体的にどのようなものに設定できるかを表形式で示す。以降の説明において、APIで規定される描画要求の表記には、本図のものを用いる。java.awt.Graphics#fillRectメソッドの場合、描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、イメージプレーン座標系におけるXY座標で表現される。また、描画色は、(R=255,G=0,B=0)というRGB値によって表現される。
【００５１】
同図（ｂ）は、APIの種別がjava.awt.Graphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを表形式で示す。java.awt.Graphics#drawImageメソッドの場合、描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の”ビットマップイメージ１”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５２】
同図（ｃ）は、APIの種別がStereoGraphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを表形式で示す。APIの種別がStereoGraphics#drawImageメソッドである場合、左イメージプレーンにおける描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられる変数名を用いて表現される。本図の”ビットマップイメージ１”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５３】
右イメージプレーンにおける描画すべき矩形範囲は、(X3=55,Y3=100),(X4=255,Y4=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の”ビットマップイメージ２”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５４】
図１０は、図９（ｃ）のように引数が指定された場合、StereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。図中の手前側は、描画イメージを格納したイメージメモリを示す。図中の奥手側は、互いに重ね合わされた左イメージプレーン及び左ビデオプレーンの組み、右イメージプレーン及び右ビデオプレーンの組みを示す。この左イメージプレーン、右イメージプレーンに、図９で描画すべき矩形範囲として示した、具体的なXY座標をプロットしている。
【００５５】
本図によると、左右のイメージプレーンでは、X座標がわずかにずれているため、描画イメージがそれぞれ横方向に少しずれた位置にコピーされることになる。図中の矢印ig1,ig2は、左右イメージプレーンから左右のイメージプレーンへのコピーを示す。この場合はR画像の描画位置がL画像の描画位置よりも５ピクセル分右にずれているため、視聴者にはディスプレイの奥に引っ込んでいるような表示として感じられることになる。左右それぞれの視点向けに用意した異なるビットマップを指定しているので立体視としての効果は向上しているが、描画イメージとして同一のビットマップを用いることもできる。
【００５６】
図１１は、フレームi,j,kのそれぞれにおける、左右のビデオプレーン、左右のイメージプレーンの書き込み内容を示す。フレームiの書き込み内容は、1つのボタン部材であり、フレームjの書き込み内容は3つのボタン部材、フレームｋの書き込み内容は、字幕、音声、特典といった文字列が付加された3つのボタン部材である。
図１２は、フレームi,j,kにおけるイメージプレーンの書き込み内容が図１１のものである場合、どのようなエフェクトが再生されるかを示す。上述したような書き込みを行うことにより、フレームiにおいて1つのボタン部材が表示された後に、フレームjにおいて1つのボタン部材が3つに増え、フレームｋにおいて3つのボタン部材に文字列が付加されることでメニューが完成する様子が描かれる。
【００５７】
かかるイメージプレーンの書き込みにあたって、上から1ラインずつ、左右交互に描画することで、最悪でも左右同じ場所にティアリングが発生するようにする。
図１３は、左右のイメージプレーンへの書き込みがどのように行われるかを示す。第１段目は、バイトコードアプリケーションの動作の時間軸を示し、第２段目は左イメージメモリ、第３段目は右イメージメモリ、第４段目は左ビデオプレーン、第５段目は右ビデオプレーンを示す。フレームｋの直後であるフレームｋ＋１、フレームｋ＋２は、描画イメージの書き込みが行われるフレームである。図中のライン１、ライン２、ライン３〜ライン７０は、描画イメージを構成する各ラインの画素データが順次、イメージプレーンに書き込まれてゆく過程を示す。この書き込みは、左イメージプレーンへのライン１の書き込み、右イメージプレーンへのライン１の書き込み、左イメージプレーンへのライン２の書き込み、右イメージプレーンへのライン２の書き込みというように、ライン単位で交互になされていることがわかる。
【００５８】
ここでバイトコードアプリケーションによる左右のイメージプレーンへの書き込みに、２フレーム期間が必要であるものと仮定する。この場合、第１段目におけるバイトコードアプリケーションは、フレームｋにてStereoGraphics#drawImageを呼び出すと、2フレーム期間後のフレームｋ＋２に描画が完了することになる。
図１４は、StereoGraphics#drawImageを用いず、左イメージプレーン、右イメージプレーンのそれぞれに対して、個別に、書き込みを行う場合、表示内容がどのようになるかを示す。同図（ａ）は、左右イメージプレーンに対する書き込み進捗の違いを示す。左イメージプレーンへの書き込みを先に行ったため、左イメージプレーンでは、「字幕」「音声」「特典」のボタン部材が存在するが、右イメージプレーンへの書き込みは後であったので、右イメージプレーンには「字幕」のボタン部材しか存在しない。
【００５９】
上述したように、本実施形態ではイメージプレーンがシングルバッファで構成されており、イメージプレーン上のフレームjに表示されるべき描画イメージに、フレームｋに表示されるべき描画イメージを上書きすることにより、イメージプレーンの画面更新を行っている。よって本図では、左イメージプレーンにフレームjに表示されるべき描画イメージの一部が残存している(ハッチング部参照)。フレームjに表示されるべき描画イメージの残存部は、右イメージプレーンにのみ存在し、左イメージプレーンには存在しないため、かかる残存部において、左右両眼の間での不整合が発生する。
【００６０】
同図（ｂ）は、シャッター眼鏡５００を通じて、（ａ）のイメージプレーンを視聴した場合に視聴することができる立体視映像を示す。本図において「字幕」のボタン部材は、左右イメージプレーンに共通に存在するから、立体視効果により画面から手前に出現しているように見える。対照的に「音声」「特典」のボタン部材は、左右イメージプレーンに共通に存在しないので、立体視効果が得られないばかりか、左右の目で全く異なる映像が見えるという、現実にはあり得ない状況となる。このような左右両眼の間での映像の不整合は、ユーザに視覚的な不快感を与える。
【００６１】
図１５は、StereoGraphics#drawImageを用いて、左イメージプレーン、右イメージプレーンのそれぞれに対して、画素の書き込みをライン単位に交互に行う場合、表示内容がどのようになるかを示す。同図（ａ）は、左右イメージプレーンに対する書き込み進捗の違いを示す。左右イメージプレーンへのライン単位の書き込みを交互行うため、左右イメージプレーンにおける書き込みの進捗は同程度となる。
【００６２】
イメージプレーン上のフレームjに表示されるべき描画イメージに、フレームｋに表示されるべき描画イメージを上書きすることにより、イメージプレーンの画面更新を行っているので、本図でも、前図と同様、フレームｋに表示されるべき描画イメージの一部が残存している(ハッチング部参照)。
具体的にいうと、左右イメージプレーンには、それぞれ「字幕」「音声」のボタン部材しか存在しない。イメージプレーンの書込内容が未完成のまま表示に供されることでティアリングが発生する。しかしフレームｋに表示されるべき描画イメージの残存部は、右イメージプレーンにも、左イメージプレーンにも存在するため、かかる残存部で、左右の映像の不整合は発生しない。
【００６３】
同図（ｂ）は、シャッター眼鏡５００を通じて、（ａ）のイメージプレーンを視聴した場合に視聴することができる立体視映像を示す。本図において「字幕」「音声」のボタン部材は、左右イメージプレーンに共通に存在するから、立体視効果により画面から手前に出現しているように見える。左右のイメージプレーンに対する書き込みが未完であっても、左右のイメージプレーンの内容は大体同じものになる。また、左右の不整合が発生したとしても、その発生の程度は、ライン画素のレベルになるので、ユーザに視覚的な不快感を与えることはない。
【００６４】
StereoGraphics#drawImageを用いた描画処理を再生装置に実行させるため、どのようなプログラムを作成すべきかについて説明する。
図１６は、バイトコードアプリケーションによるメニュー表示のフローチャートである。ステップＳ１において、描画イメージを最初に表示すべきフレームを”フレームｔ”とし、ステップＳ２〜ステップＳ７のループに移行する。ステップＳ２〜ステップＳ７は、フレームｔに表示すべき左イメージのインスタンスを生成して、イメージ１とし(ステップＳ２)、フレームｔに表示すべき右イメージのインスタンスを生成して、イメージ２として(ステップＳ３)、フレームｔの始期が到来するのを待ち(ステップＳ４)、始期が到来すれば、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を特定する(ステップＳ５)。そして、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を引数で指定した上で、StereoGraphics#drawImageメソッドのコールを行い(ステップＳ６)、次にイメージを表示すべきフレームをフレームｔとする処理(ステップＳ７)を、繰り返すものである。
【００６５】
図１７は、StereoGraphics#drawImageメソッドがコールされた際のライン描画手順を示すフローチャートである。描画イメージの描画対象行を示す変数Yを「1」に初期化して(ステップＳ１１)、ステップＳ１２〜ステップＳ１４のループに移行する。このループでは、第２引数として指示される描画イメージのYライン目のRGB値を、左イメージプレーンの(x1,y1+Y-1)から、(x2,y1+Y-1）までに書き込み(ステップＳ１２)、第４引数のYライン目のRGB値を、右イメージプレーンの(x3,y3+Y-1)から(x4,y3+Y-1)までに書き込む(ステップＳ１３)という処理を、ステップＳ１４がYesと判定されるまで繰り返す。ステップＳ１４は、y1+Y-1がy2であり、尚且つ、y3+Y-1=y4という条件を満たすかどうかの判定であり、この条件を満たさない場合、ステップＳ１５において変数Yをインクリメントした上、ステップＳ１２に移行する。このループの繰り返しによって、左イメージプレーンにおける描画を行うべき矩形範囲にImage1を構成するライン画素が書き込まれてゆき、右イメージプレーンにおける描画を行うべき矩形範囲にImage2を構成するライン画素が書き込まれてゆく。
【００６６】
以上のように本実施形態によれば、アプリケーションプログラムインターフェイスの呼び出し時において、左目用のプレーンメモリへの書き込み指定と、右目用のプレーンメモリへの書き込み指定とのペアがバイトコードアプリケーションから引き渡されるので、右目用のプレーンメモリへの画素書き込みと、左目用プレーンメモリへの画素書き込みとを交互に行うような実装が可能になる。この場合、画素書き込みの途中で、表示を行うべきフレーム期間が到来したとしても、画素書き込みの進捗は、右目用と、左目用とで大体同じになる。たとえティアリングが生じたとしても、右目におけるティアリングと、左目におけるティアリングとは同一になるから、両目に映じる映像内容が一致しない左右の映像の不整合の発生は避けられる。
【００６７】
(第２実施形態)
本実施形態は、左イメージプレーン、右イメージプレーンのそれぞれに、ダブルバッファモデルを採用する実施形態である。図１８は、第２実施形態に係る再生装置のうち、改良が施された部分（イメージメモリ、イメージプレーン、レンダリングエンジン、合成部）のみを描く。
【００６８】
本図において、イメージメモリ１０５、レンダリングエンジン１０６、合成部１０７は、第１実施形態と同じであるが、イメージプレーン１０４c、１０４dが、左イメージプレーン１２１、右イメージプレーン１２２に置き換えられており、左イメージプレーン１２１、右イメージプレーン１２２と、合成部１１０との間に、スイッチ１２３、スイッチ１２４が存在する。
【００６９】
左イメージプレーン１２１は、2つのプレーンメモリから構成される。これらのうち、一方は左表示対象バッファとなり、他方は左描画対象バッファになる。左表示対象バッファは、合成部による合成の対象となるバッファである。左描画対象バッファは、バイトコードアプリケーションによる書き込みの対象になるバッファである。これらのバッファは何れも、１画面分の画素データ(ＲＧＢα値)を格納しうる容量をもつ。
【００７０】
右イメージプレーン１２２は、2つのプレーンメモリから構成される。これらのうち、一方は右表示対象バッファとなり、他方は右描画対象バッファになる。右表示対象バッファは、合成部による合成の対象となるバッファである。右描画対象バッファは、バイトコードアプリケーションによる書き込みの対象になるバッファである。これらのバッファは何れも、１画面分の画素データ(ＲＧＢα値)を格納しうる容量をもつ。
【００７１】
スイッチ１２３は、左イメージプレーン１２１を構成する2つのプレーンメモリのうち、表示対象バッファになっているものの画素内容を合成部１１０に出力する。
スイッチ１２４は、右イメージプレーン１２２を構成する2つのプレーンメモリのうち、表示対象バッファになっているものの画素内容を合成部１１０に出力する。
図１９は、スイッチ１２３、スイッチ１２４による切り替えを示す。同図（ａ）は、フレームｉに表示すべき描画イメージの出力状態を示す。同図（ａ）では、左イメージプレーン１２１、右イメージプレーン１２２のうち、上側のバッファが表示対象バッファになっており、フレームiの描画イメージが格納されている。そして下側のバッファが描画対象バッファに設定され、ここに次に表示すべきフレームjの描画イメージが書き込まれつつある。同図（ｂ）は、フレームjに表示されるべき描画イメージの書き込みが完了した状態を示す。下側のプレーンメモリに対する書き込みが完了したので、スイッチ１２３、スイッチ１２４を下側に切り替えることにより、フレームjの描画イメージを出力する。こうすることで、フレームjの描画イメージが表示に供される。
【００７２】
（ｃ）は、表示対象バッファから描画対象バッファへのコピーを示す。これにより左イメージプレーン１２１の内容は、何れもフレームjに表示されるべき描画イメージとなり、右イメージプレーン１２２の内容は、何れもフレームjに表示されるべき描画イメージになる。これにより、フレームの一部だけを描きかえてフレームｋの描画イメージを生成する場合にも、描きかえられない部分について前のフレームjと整合することが保証される。（ｄ）は、フレームｋに表示されるべき描画イメージが、上側のプレーンメモリに書き込まれている状態を示す。この上側のバッファへの書き込みが完了すると、スイッチ１２３、スイッチ１２４は上側に通され、上側のバッファが表示対象バッファになる。
【００７３】
図２０は、左右のイメージプレーンへの書き込みを完成させるために、どのような書き込みを行うべきかを示す。第１段目は、バイトコードアプリケーションの動作の時間軸を示し、第２段目は左描画対象バッファ、第３段目は右描画対象バッファ、第４段目は左ビデオプレーン、第５段目は右ビデオプレーンを示す。フレームｋの直後であるフレームｋ＋１は、右描画対象バッファへの書き込みが行われるフレーム、フレームｋ＋２は、左描画対象バッファへの書き込みが行われるフレームである。左右のイメージプレーンへの書き込みに2フレーム期間が必要である場合、バイトコードアプリケーションがフレームｋにてStereoGraphics#drawImageメソッドを呼び出すと、２フレームが経過した後のフレームｋ＋２で描画処理が完結する。そして、フレームｋ＋２の開始時点になれば、左描画対象バッファ、右描画対象バッファが左表示対象バッファ、右表示対象バッファに切り替えられて、新たな描画イメージが表示に供される。
【００７４】
図２１は、StereoGraphics#drawImageがコールされた際のダブルバッファを用いた描画手順を示す。本フローチャートでは、描画イメージの描画対象行を示す変数Yを「1」に初期化して(ステップＳ２１)、ステップＳ２２〜ステップＳ２４のループに移行する。このループでは、第２引数として指示される描画イメージのYライン目のRGB値を、左イメージプレーンの(x1,y1+Y-1)から、(x2,y1+Y-1）までに書き込む(ステップＳ２２)という処理を、ステップＳ２３がYesと判定されるまで繰り返す。ステップＳ２３は、y1+Y-1がy2という条件を満たすかどうかの判定であり、この条件を満たさない場合、ステップＳ２４において変数Yをインクリメントした上、ステップＳ２２に移行する。このループの繰り返しによって、左イメージプレーンにおける描画を行うべき矩形範囲にImage1を構成するライン画素が書き込まれてゆく。
【００７５】
その後、変数Yを1に初期化して(ステップＳ２５)、ステップＳ２６〜ステップＳ２８からなるループに移行する。このループでは、第４引数のYライン目のRGB値を、右イメージプレーンの(x3,y3+Y-1)から(x4,y3+Y-1)までに書き込む(ステップＳ２６)という処理を、ステップＳ２７がYesと判定されるまで繰り返す。ステップＳ２７は、y3+Y-1=y4という条件を満たすかどうかの判定であり、満たさない場合、ステップＳ２８において変数YをインクリメントしてステップＳ２６に戻る。以降、ステップＳ２６〜ステップＳ２８が繰り返されることにより、右イメージプレーンにおける描画を行うべき矩形範囲にImage2を構成するライン画素が書き込まれてゆく。ステップＳ２６〜ステップＳ２８のループを終了した後、ステップＳ２９において左描画対象バッファと、左表示対象バッファとの交替及び右描画対象バッファと右表示対象バッファとの交替を同時実行することにより、表示切り替えを行う。
【００７６】
以上のように本実施形態によれば、イメージプレーンにダブルバッファを採用することで、左右の映像の不整合の発生の回避が可能になる。
(第３実施形態)
本実施形態は、記録媒体におけるタイトルを生存区間としたアプリケーションシグナリングを再生装置に実行させて、このアプリケーションシグナリングの実行の際、イメージプレーンの規模を指定する改良に関する。
【００７７】
本実施形態では、記録媒体に以下のインデックステーブル、動作モードオブジェクトが記録されている。
インデックステーブルは記録媒体全体に関する管理情報であり、再生装置への記録媒体挿入後に、インデックステーブルが最初に読み出されることで、再生装置において記録媒体が一意に認識される。
【００７８】
インデックステーブルは、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、再生装置の動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。ここでプレイリストは、ビデオストリームを含むデジタルストリームに再生順序を規定することで特定される再生単位である。
【００７９】
ここで、タイトル番号レジスタにおけるタイトル番号は、０、１〜９９９、不定値(0xFFFF)という番号がある。タイトル番号０は、トップメニュータイトルのタイトル番号である。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値(0xFFFF)のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。
【００８０】
インデックステーブルは、各タイトル番号のそれぞれに対応したエントリー(インデックステーブルエントリー)を有し、個々のインデックステーブルエントリーに、動作モードを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。
再生装置においてタイトル番号レジスタの値は、記録媒体の装填後、不定値0xFFFF→１〜９９９→０というように変化する。このタイトル番号の変化は、記録媒体の装填時に、ファーストプレイタイトルの再生を開始し、ファーストプレイタイトルの再生後、１から999までのタイトル番号レジスタのタイトル番号で指示されるタイトルの再生を行い、タイトル番号で指示されるタイトルの再生が終了すれば、トップメニュータイトルを再生してユーザによる選択待ちを行うというものである。１〜９９９のタイトル番号をもつタイトルのうち、タイトル番号レジスタに格納されているタイトル番号と、同じタイトル番号をもつものが、現在の再生対象、つまりカレントタイトルになる。タイトル番号レジスタにどのような番号を設定するかは、トップメニュータイトルに対するユーザ操作や、プログラムによるタイトル番号レジスタの設定によって決定される。
【００８１】
以上がインデックステーブルについての説明である。続いて、動作モードオブジェクトの詳細について説明する。
動作モードオブジェクトは、プレイリストと、アプリケーションとの関連付けにより、タイトルを定義する情報である。図２２は、動作モードオブジェクトの内部構成の一例を示す図である。本図に示すように、動作モードオブジェクトは、「アプリケーション管理テーブル」、「端末管理テーブル」、「アプリケーションキャッシュ情報」、「プレイリストアクセス情報」、「キーインタレストテーブル」から構成される。
「アプリケーション管理テーブル」は、複数のエントリーを含む。引き出し線bj1は、アプリケーション管理テーブルにおけるエントリーをクローズアップして示している。この引き出し線に示すように、アプリケーション管理テーブルのエントリーは、タイトルにおいて、アプリケーションを自動的に起動させるべきか(AutoStart)、他のアプリケーションからの呼出しを待って起動すべきか(Present)という起動の仕方を示す「制御コード」と、JARファイルのファイル名となる５桁の数値を用いて、対象となるアプリケーションを示す「アプリケーションID」と、「アプリケーション詳細情報」を含む。引き出し線bj2は、「アプリケーション詳細情報」の内部構成をクローズアップして示している。本引出線に示すように、「アプリケーション詳細情報」は、アプリケーションがロードされる場合の「優先度」と、アプリケーションがタイトルアンバウンドであるか否か、ディスクバウンドであるか否かを示す「バインディング情報」と、アプリケーションの名称を示す文字列と、アプリケーションの言語属性を示す「言語コード」と、アプリケーションに対応づけるアイコンの所在を指し示す「アイコンロケータ」とを、アプリケーション毎にして格納している。
【００８２】
アプリケーション管理テーブルは、タイトルを生存区間として管理することで、各アプリケーションによるメモリリソースなどの消費を、タイトルという再生単位を区切りにて管理することができる。これによりたとえ、あるタイトルの再生中に複数のアプリケーションによるリソースの利用が競合して、デッドロック状態に陥ったとしても、ユーザによって別のタイトルが選択されれば、それらアプリケーションは全て終了させられるので、デッドロック状態は、強制的に解消することになる。また、あるタイトルの再生中に暴走したアプリケーションがメモリを占有したとしても、ユーザによって別のタイトルが選択されれば、そのアプリケーションは強制的に終了させられるので、メモリ容量の圧迫は、強制的に解消することになる。こうすることで不要なメモリリソースを消費しない、安定したメモリリソースの管理を実現することができる。安定したメモリリソースの管理を実現することができるので、メモリリソースの容量が限られた家電機器の実装において、より真価を発揮する。
【００８３】
「端末管理テーブル」は、動作中のアプリケーションが、欧州デジタル放送端末(DVB-MHP)が実現しているような、HAViインターフェイスによるGUIを表示する際の処理を規定する管理テーブルであり、GUI表示を実行するにあたってのコンフィグレーション情報や、GUIに用いるフォントデータ、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。このコンフィグレーション情報は、動作モードオブジェクト内のアプリケーション管理テーブルによって起動されるべきアプリケーションがグラフィクスを描画するにあたって、再生されるビデオストリームの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報である。引き出し線bj3は、端末管理テーブルの内部構成をクローズアップして示している。この引き出し線bj3に示すように、端末管理テーブルは、HD3D＿1920×1080、HD3D＿1280×720、HD＿1920×1080、HD＿1280×720、QHD＿960×540,SD,SD＿50HZ＿720×576,SD＿60HZ＿720×480の何れかに設定することができる。
【００８４】
「アプリケーションキャッシュ情報」は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、当該タイトルにおけるAV再生が開始されるまでに、どのアプリケーションを構成するファイルを、プラットフォーム内のキャッシュに読み込むべきかを示す情報であり、アプリケーション管理テーブルにより生存区間が規定されたアプリケーションに対応付けられたエントリーを含む。各エントリーは、アプリケーション管理テーブルにより生存区間が規定されたアプリケーションのそれぞれをプラットフォームにおけるキャッシュに読み込ませる旨を再生装置に指示する情報であり、各エントリーに付与された順位は、その順位がもっとも高いエントリーに対応するアプリケーションを最初にプラットフォームのキャッシュに読み込ませ、それ以降、順位が高い順に、残りのエントリーに対応するアプリケーションを、キャッシュフルになるまで、順次プラットフォームのキャッシュに読み込ませる旨を再生装置に指示する。こうすることで、低速な光ディスク媒体からバイトコードアプリケーションのクラスロードを行う場合でも、クラスロードが長くかかることによるスタートアップディレイを低減することができる。
【００８５】
「プレイリストアクセス情報」は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、自動的に再生されるべき自動再生プレイリストの指定を含む。また、プレイリストアクセス情報は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、動作させることができるアプリケーションが選択できるプレイリストの指定を含む。引き出し線bj4は、自動再生プレイリストを指定する情報の内部構成をクローズアップして示している。引出線bj4に示すように、自動再生プレイリストを指定する情報として、3Dプレイリスト1920×1080、3Dプレイリスト1280×720、2Dプレイリスト1920×1080、2Dプレイリスト1280×720、2Dプレイリスト720×576、2Dプレイリスト720×480の指定が可能になる。
【００８６】
何れかのタイトルが選択された際、再生装置は、選択されたカレントタイトルに対応するもののプレイリストアクセス情報により指定されたプレイリストの再生を、アプリケーションからの再生指示を待つことなく開始し、プレイリスト再生の終了よりも、バイトコードアプリケーション実行が先に終了した場合、プレイリストの再生を継続して行う。
こうした先行再生により、アプリケーションのクラスロードに時間がかかり、描画イメージが表示されないため、対話画面がなかなか出力されないような場合、プレイリスト再生による再生映像がそのまま出力させるので、アプリケーションにおける起動遅延が顕著な場合でも、とりあえずプレイリストの再生映像をユーザに視聴させることができる。アプリケーションのスターティングディレィの間、何かが写っている状態にしておくことができるので、ユーザに安心感を与えることができる。
【００８７】
また終了が同時でないため、リソースの枯渇によってアプリケーションが異常終了し、アプリケーションのGUIが自動的に消去されたとしても、プレイリスト再生画面の表示をそのまま継続していれば、プレイリストの再生映像が、表示装置に出力される。かかる出力継続によって、たとえバイトコードアプリケーションが異常終了したとしても、表示装置は、とりあえず何かが写っているという状態になり、アプリケーションの異常終了によって、画面がブラックアウトするという事態を防ぐことができる。
【００８８】
「キーインタレストテーブル」は、再生キーエントリー、停止キーエントリー、早送りキーエントリー、巻戻しキーエントリー、上方向キーエントリー、下方向キーエントリー、右方向キーエントリー、左方向キーエントリーなど、再生装置におけるリモコンに備え付けられているそれぞれのキーについてのエントリから構成される。これらのキーエントリーは、対象となるキーが押下された際、キーイベントを発生させるか、発生させないかが設定される。ユーザ操作に応じてイベントが発生した場合、再生装置のイベントマネージャは、発生したイベントがキーインタレストテーブルに記載されているかどうかを判定する。そして記載されているなら、そのイベントをバイトコードアプリケーションに処理させるべく、キーイベントを出力する。
【００８９】
一方、発生したイベントがキーインタレストテーブルに記載されていない場合、再生装置のオペレーションマネージャは、そのイベントに対応するAV機能を再生制御エンジンに実行させる。こうすることで、バイトコードアプリケーションにイベントの対応漏れや、バグがあったとしても、オペレーションマネージャにより、再生制御エンジン部に対する再生制御が行われることになる。アプリケーションにバグがあったとしても違和感がない制御がなされることは、キーインタレストテーブル側から保証されているので、アプリケーションを開発するソフトハウスは、バグの発生等に躊躇することなく、他社にはない再生制御を実現することができる。
【００９０】
図２３は、タイトル切り替え時におけるプレーンメモリの解像度設定の処理手順の一例を示すフローチャートである。本フローチャートは、ステップＳ３１、ステップＳ３２、ステップＳ３３、ステップＳ３６の判定結果に応じて、ステップＳ３４、ステップＳ３５、ステップＳ３７の処理を選択的に実行する。
ステップＳ３１は、自動再生プレイリストが存在するかどうかの判定であり、ステップＳ３２は、直前の表示モードは3Dであるか否かの判定である。ステップＳ３３は、選択されたタイトルの自動再生プレイリストが、1920×1080の3Dプレイリスト又は1280×720の3Dプレイリストであるかどうかの判定である。
【００９１】
自動再生プレイリストが存在しない場合、ステップＳ３６において動作モードオブジェクトのデフォルト解像度がHD3D＿1920×1080、HD3D＿1280×720であるかどうかが判定され、もしYesであれば、ステップＳ３５において、表示モードを3Dに設定し、動作モードオブジェクトにおけるデフォルト解像度に応じて1920×1080、あるいは1280×720に設定する。もしNoであれば、ステップＳ３７において表示モードを2Dに設定し、解像度を動作モードオブジェクトにおけるデフォルト解像度に設定する。
【００９２】
自動再生プレイリストが存在しない場合、ステップＳ３２において直前の表示モードが2Dであるかどうか、又は、ステップＳ３３においてプレイリストが3Dプレイリストで、その解像度が1920×1080、1280×720であるがどうかを判定する。ステップＳ３２、ステップＳ３３のどちらかがNoであれば、ステップＳ３４において表示モードを2Dに設定し、解像度を、自動再生プレイリストの解像度に設定する。
【００９３】
ステップＳ３２がYes、ステップＳ３３もYesと判定された場合、ステップＳ３５において、表示モードを3Dに設定し、解像度を、自動再生プレイリストの解像度に応じて1920×1080、又は、1280×720に設定する。
本実施形態では、イメージプレーンを含むプレーンメモリのアクセスのため、バイトコードアプリケーションは、getCurrentConfigurationメソッド、getBestConfigurarionメソッド、setConfigurationメソッド、setCoherentConfigurarionメソッドを利用することができる。
【００９４】
getCurrentConfigurationは、プレーンメモリの表示設定をバイトコードアプリケーションに取得させるためのAPIである。
getBestConfigurationメソッドは、バイトコードアプリケーションに、再生装置における個々のプレーンの最善の設定情報を返す。
setConfigurationメソッドは引数に指定したプレーンに対する設定のみを変更するためのものである。
【００９５】
setCoherentConfigurationsメソッドは、複数のプレーンメモリに共通に設定される。例えば引数として解像度を指定し、setCoherentConfigurationsメソッドを呼出せば、個々のプレーンメモリの解像度を同一にすることができる。
よって、タイトル起動時に、動作モードオブジェクトの端末管理テーブル、又は、プレイリストアクセス情報にて設定されたイメージプレーンの解像度を、getCurrentConfigurationメソッドを用いて取得して取得した解像度を用いて左右のイメージプレーンに表示すべき描画イメージの描画発生を調整し、位置決めを行ってからStereoGraphics#drawImageメソッドを発行する。
【００９６】
または、getCurrentConfigurationメソッドを用いて取得した解像度が、描画イメージに適合した解像度であるか否かを判定して、描画イメージに適合した解像度であればそのままStereoGraphics#drawImageメソッドを発行する。
描画イメージに不適合な解像度であれば、setConfigurationメソッドを用いてイメージプレーンを適切な解像度に設定した上でStereoGraphics#drawImageメソッドをコールする。
【００９７】
バイトコードアプリケーションは、以上の過程で指定されたイメージプレーンの解像度を、アプリケーションプログラムインターフェイスを介して取得することができるので、StereoGraphics#drawImageメソッドの呼び出しにあたって、最適な矩形範囲の指定が可能になる。
以上のように本実施形態によれば、動作モードオブジェクトにおける端末管理テーブル、及び、プレイリスト管理テーブルにて指定されたイメージプレーンの座標系において、描画イメージを描画すべき矩形範囲を定めることができる。
【００９８】
（第４実施形態）
本実施形態は、これまでの実施形態の統合であり、記録媒体１００をBD-ROMとして構成し、再生装置２００をBD-ROM再生装置として構成する場合の形態である。
本実施の形態では、立体表示を行う対象映像は、BD-ROM記録媒体に記録されているものを再生して視聴することを前提にする。BD-ROM規格では、BD-ROM規格に準拠した形式でローカルストレージ内あるいは、リムーバブルメディアに記録されているデータを再生することも可能である。これらを含めて再生装置２００によって立体視映像表示が実施される形態を説明する。もちろん本実施例の変形としては、立体表示を行う対象映像は例えば放送波などの無線、ケーブルなどの有線、あるいは他の記録媒体を介して提供されていても構わない。
【００９９】
続いて再生装置２００が再生の対象としている、BD-ROM１００の内部構成について説明する。図２４は、BD-ROM１００の内部構成を示す図である。
本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。また、リードインの内側にはBCA（Burst Cutting Area）と呼ばれる領域があり、この領域から情報を読み出すことができることのできる主体は制限されているため、例えば著作権保護技術などに利用される。
【０１００】
本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもち、ボリューム領域には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、UDFやISO９６６０などのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっており、２５５文字のファイル名、ディレクトリ名を読み出すことが可能である。
【０１０１】
ディレクトリ構造を用いてBD-ROMの応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。この第１段目においてBD-ROMには、Rootディレクトリの下に、CERTIFICATEディレクトリ、及びBDMVディレクトリがある。
BDMVディレクトリはBD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリであり、BDMVディレクトリの配下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリ、METAディレクトリと呼ばれる６つのサブディレクトリが存在し、先の実施形態で述べたインデックステーブルを格納したファイルであるINDEX.BDMVと、DVDと互換がある制御を実現するプログラムを格納したMovieObject.bdmvの２種類のファイルが配置されている。
【０１０２】
STREAMディレクトリには、いわばトランスポートストリーム本体となるファイルを格納しているディレクトリであり、拡張子”m２ts”が付与されたファイル（00001.m2ts）が存在する。
PLAYLISTディレクトリには、拡張子”mpls”が付与されたファイル（00001.mpls）が存在する。
【０１０３】
CLIPINFディレクトリには、拡張子”clpi”が付与されたファイル（00001.clpi）が存在する。
BDJOディレクトリには、拡張子”bdjo”付与されたファイル（XXXXX.bdjo）が存在する。
JARディレクトリには、拡張子”jar”が付与されたファイル（YYYYY.jar）が存在する。
【０１０４】
METAディレクトリには、XMLファイル（ZZZZZ.xml）が存在する。
以下、これらのファイルについて説明する。
先ず初めに、拡張子”m２ts”が付与されたファイルについて説明する。拡張子”m２ts”が付与されたファイルは、MPEG-TS（TransportStream）形式のデジタルAVストリームを格納したストリームファイルであり、これまでの実施形態で説明したビデオストリーム、１つ以上のオーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム等を多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分をそれぞれ示している。
拡張子”mpls”が付与されたファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。”プレイリスト”とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの”型”を定義する。プレイリスト情報によって定義される再生経路は、いわゆる”マルチパス”である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。このマルチパスにおいて左目用のビデオストリームの再生経路を規定し、サブパスにおいて右目用のビデオストリームの再生経路を規定すれば、立体視を再生するためのビデオストリームの組合せを、好適に規定することができる。
【０１０５】
かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。再生制御のためのJava(TM)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(TM)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMF(JavaMedia Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。
拡張子”clpi”が付与されたファイルは、MPEG2形式のストリームファイルのそれぞれに１対１に対応するClip情報ファイルである。このClip情報ファイルを通じることにより、ストリームファイルは”AVClip”として管理されることになる。Clip情報は、AVClipにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すEP＿mapをもっているので、ストリームファイルのアクセスに先立ち、このクリップ情報をメモリにロードしておけば、アクセスしようとするストリームファイル中のトランスポートストリームがどのようなものであるのかを把握することができる。以上のClip情報及びPL情報は、”静的シナリオ”に分類される。
拡張子BDJOを付したファイルは、BD-Jオブジェクトを格納したファイルである。BD-Jオブジェクトとは、先の実施形態で述べた動作モードオブジェクトのことであり、BD-Javaアプリケーションを実行する際に使用される各種の情報を含んでいる。BD-ROM規格では、映像の再生中にアプリケーションプログラムを実行することによって、動的な再生制御や、再生中のユーザとのインタラクション等、映像の再生を行いながら任意の計算機処理を行わせることが可能である。BD-ROMではこのアプリケーションプラットフォーム規格としてJava（登録商標）が用いられており、BD-ROM規格上で採用されるJava（登録商標）プラットフォームは、BD-Java、あるいはBD-Jと呼ばれ、その実行アプリケーションはBD-Javaアプリ、あるいはBD-Jアプリと呼ばれる。
JARファイルは、BD-Jアプリケーションのクラス構造体のファイル(クラスファイル)を、デジタル証明書マニフェストファイル、ディスク署名シグネチャファイル、ディスク署名暗号鍵ファイル、パーミッションリクエストファイルとひとまとめにしてアーカイブしたファイルである。上述したようなアプリケーションキャッシュ情報によるキャッシュへのロードは、このJARファイルをひとまとめにしてなされる。
【０１０６】
以下、JARファイルにアーカイブされているデータ要素について説明する。
(i)クラス構造体のファイルにて定義されるBD-Jアプリケーションは、Xletインターフェイスを通じて、プラットフォーム内のアプリケーションマネージャにより、制御されるJava(TM)Xletである。Xletインターフェイスは、”loaded”,”paused”、”active”,”destroyed”といった4つの状態をもち、イベントドリブンつまり、イベントによって状態遷移を行うとともに制御を実行する。xletインターフェイスでは、アプリケーションの動作のトリガとなるキーイベントが予め登録される。このように、動作のトリガとなるキーイベントの登録は、イベントリスナによってなされる。
【０１０７】
(ii)デジタル証明書マニュフェストファイルは、デジタル証明書に対応するものであり、Java(TM)アーカイブファイルの属性、Java(TM)アーカイブファイル内のクラスファイルやデータファイルのハッシュ値が記載されているマニフェストファイルである。
(iii)ディスク署名シグネチャファイルは、マニフェストファイルのハッシュ値が記載されているシグネチャファイルである。
【０１０８】
(iv)ディスク署名暗号鍵ファイルは、「デジタル証明書チェーン」と、シグネチャファイルの「署名情報」とが記載されているファイルである。
「署名情報」は、署名処理をデジタル署名シグネチャファイルに施すことで得られる。これらの署名処理には、デジタル署名シグネチャファイル内のデジタル証明書チェーンにおける公開鍵に対応する秘密鍵が用いられる。
【０１０９】
「デジタル証明書チェーン」とは、一つ目の証明書（ルート証明書）が二つ目の証明書を署名し、また同じようにn番目の証明書がn+１番目の証明書を署名している形をもつ複数の証明書群である。デジタル証明書チェーンの最後の証明書を「リーフ証明書」と呼ぶ。この構成を利用することにより、ルート証明書から順番に次の証明書を保障していくことにより、デジタル証明書チェーンの最後の証明書までを保障することができる。
【０１１０】
(v)パーミッションリクエストファイルは、実行されるJava(TM)アプリケーションにどのパーミッションを与えるのかの情報を格納する。具体的に、クレデンシャル(デジタル信用証明書)、アプリ間通信の許可情報を含む。
”クレデンシャル”とは、ある組織に帰属する組織ディレクトリ内のファイルを共有化するための情報である。この共有化は、ある組織に属するアプリケーション用ファイルを利用する権限を、他の組織に属するアプリケーションに提供することでなされる。そのためクレデンシャルは、権限を提供する側の組織を示す提供者組織ID、権限を受領する側の組織の識別を示す受領者組織IDを含む。
【０１１１】
(vi)これらのファイル以外にも、PNGファイルが格納される。PNGファイルは描画イメージを定義するデータ構造体であり、本実施形態では、描画イメージを定義するデータ構造体をBD-Jアプリケーションのクラス構造体と共にJARファイルに格納して、ロードすることができる。
BD-Jアプリケーションを規定するクラスファイルは、以上のシグネチャファイル、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルとひとまとめにされて、ロードされるので、再生装置は、BD-Jアプリケーションを動作させるにあたって、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルを用いて、BD-Jアプリケーションを署名することができる。このように、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルを用いて署名されたBD-Jアプリケーションを、”Signedアプリケーション”という。一方、署名がなされず、その権能の一部又は全部が制限されたBD-Jアプリケーションを”Un-Signedアプリケーション”という。以上の署名により、BD-Jアプリケーションの動作は、コンテンツの作りにとって不利にならないものに制限される。以上のパーミッションリクエストファイルを用いれば、StereoGraphics#drawImageメソッドによる描画やその他、立体視再生を実現するためのプレーンメモリへの書き込みを、ある特定の権限が付与されたBD-Jアプリケーションに限定することができる。
METAディレクトリに格納されたメタファイル（ZZZZZ.xml）には、ディスクに入っている映像作品に関する様々な情報が格納されている。メタファイルに格納されている情報としては、ディスクのディスク名及び画像、ディスクの作成主体者の名称の情報、各タイトルに関わるタイトル名等がある。
【０１１２】
以上がBDMVディレクトリの説明である。
CERTIFICATEディレクトリの下には、ディスクのルート証明書のファイル(app.discroot.cert)が存在する。
これはBD-Jアプリを実行する際に、アプリケーションが改竄されていないか、及びアプリケーションの身元確認を行なうプロセス（以下、署名検証という）に用いられるデジタル証明書の情報が含まれている。
【０１１３】
以上がBD-ROM１００についての説明である。メタファイルなど一部のファイルはBD-ROM規格では必ずしも必須とされておらず、一部のファイルが存在していなくともBD-ROM１００は映像記録媒体としてBD-ROM規格のもと再生可能である。
次に本実施形態に係る再生装置２００の詳細について説明する。
図２５は、第４実施形態に係る再生装置の内部構成を示すブロック図である。図２５に示すように、再生装置は、BDドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、左ビデオプレーン５、右ビデオプレーン６、イメージメモリ７、イメージデコーダ８、左イメージプレーン９、右イメージプレーン１０、静的シナリオメモリ１１、動的シナリオメモリ１２、制御部１３、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生制御エンジン１８、アプリデータ関連付けモジュール１９、プレーン合成部２０、UO探知モジュール２１、レンダリングエンジン２２、ネットワークインターフェース２３、ローカルストレージ２４、仮想ファイルシステム２５、オーディオデコーダ２６、リムーバブルメディア２７、次元判定部２８、次元モード記憶部２９、左右描画処理調停部３０から構成される。
【０１１４】
BDドライブ１は、BD-ROMのローディング/イジェクトを行い、BD-ROMに対するアクセスを実行する。
トラックバッファ２は、FIFOメモリであり、BD-ROMから読み出されたデジタルストリームを構成するソースパケットが先入れ先出し式に格納される。
デマルチプレクサ３は、仮想ファイルシステム２５を通じて、BDドライブ１にローディングされているBD-ROM、またはローカルストレージ２４上、またはリムーバブルメディア２７に保存されているトランスポートストリームの多重分離を行う。多重分離によって得られる、GOPを構成するビデオフレームは、ビデオデコーダ４に出力され、同じくGOPと同時に再生されるべきオーディオフレームはオーディオデコーダ２６に出力される。同じく多重分離によって得られるグラフィックストリームは、イメージメモリ７に格納され、同じく多重分離によって得られるシナリオ情報は動的シナリオメモリ１２に格納される。デマルチプレクサ３による多重分離は、TSパケットをPESパケットに変換するという変換処理を含む。また、デマルチプレクサ３は、次元判定部２８を用いて、立体視（3D）用の処理を行うか２D用の処理を行うかを切り替える。
【０１１５】
ビデオデコーダ４は、Multiview Video Coding（MVC）と呼ばれるMPEG-4 AVC/H.２６４の修正規格に準拠したデコーダであり、MPEG-4 AVCに基づき符号化された圧縮状態のビデオストリームを、映像の時間方向の類似性、視点間の類似性に基づき動き予測を行うことで、デコードする。
左ビデオプレーン５および右ビデオプレーン６は、ビデオデコーダ４のデコードによって得られた非圧縮形式のピクチャを格納するためのメモリであり、それぞれ左眼用のビデオのピクチャ、右眼用のビデオのピクチャが格納される。
【０１１６】
イメージメモリ７は、BD-J端末において仮想ファイルシステム２５から読み出されたグラフィックストリームや字幕データ、あるいは画像イメージ等のイメージデータを格納するバッファである。
イメージデコーダ８は、イメージメモリ７に格納されたグラフィックストリーム、あるいは字幕データ、あるいはイメージデータをデコードして左イメージプレーン９および右イメージプレーン１０に書き込む。
【０１１７】
左イメージプレーン９および右イメージプレーン１０は、BD-J端末においてGFXプレーンと呼ばれるプレーンメモリであり、それぞれ左眼用のイメージデータ、右眼用のイメージデータを非圧縮形式で格納する。BD-ROMにおいては、イメージプレーンに相当するものは複数用意されており、それぞれを独立させてビデオプレーンに重畳させることができる。具体的には、イメージデコーダ８から出力されたグラフィックストリーム・字幕データ・イメージデータや、レンダリングエンジン２２によって行われる描画処理の結果生成されるイメージデータ、さらに図には記載していないが背景（スチル）用プレーンが挙げられる。しかし本実施の形態の中では、説明を簡単にするためにイメージプレーンを１枚として説明するものとし、以降では特にレンダリングエンジン２２によって行われる描画処理を中心とした記載を行う。
【０１１８】
静的シナリオメモリ１１は、カレントプレイリストやカレントのストリーム管理情報を格納しておくためのメモリである。カレントプレイリストとは、仮想ファイルシステム２５から読み出すことのできるPLのうち、その時点での処理対象になっているものをいう。カレントストリーム管理情報とは、仮想ファイルシステム２５から読み出すことのできる複数ストリーム管理情報のうち、その時点での処理対象になっているものをいう。
【０１１９】
動的シナリオメモリ１２は、カレント動的シナリオを格納し、HDMVモジュール１４、BD-Jモジュール１５による処理に供されるメモリである。カレント動的シナリオとは、仮想ファイルシステム２５から読み出すことのできる複数シナリオ情報のうち、その時点での実行対象になっているものをいう。
制御部１３は、ROM、RAM、CPUからなるマイコンシステムであり、ROMには再生装置を制御するプログラムが記録されており、ROM内のプログラムがCPUに読み込まれ、プログラムとハードウエア資源とが協動することにより、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生制御エンジン１８、アプリデータ関連付けモジュール１９、左右描画処理調停部３０の機能を実現する。
【０１２０】
HDMVモジュール１４は、DVD映像仮想プレーヤである。HDMV（High Definition Movie Mode）とは、DVDとの親和性のある映像再生形式である。
BD-Jモジュール１５は、第１実施形態に示したプラットフォーム部の構成要素のうち、ヒープメモリ１１１、バイトコードインタプリタ１１２、クラスローダ１１３、アプリケーションマネージャ１１４によって構成される部分に対応する機能モジュールであり、BD-Jアプリを実行する。
【０１２１】
モード管理モジュール１６は、仮想ファイルシステム２５から読み出されたモード管理テーブルを保持して、モード管理及び分岐制御を行う。モード管理モジュール１６によるモード管理とは、動的シナリオをどのHDMVモジュール１４、BD-Jモジュール１５に実行させるかという、モジュールを割り当てる処理を実施する。
ディスパッチャ１７は、UO検知モジュール２１により受け取ったユーザの操作（ユーザオペレーション、以下UOとも記す）から、現在の再生装置におけるモードに適切なUOのみを選んで、そのモードを実行するモジュールに渡す。例えばHDMVモードの実行中に、上下左右、アクティベートといったUOを受け付けた場合、HDMVモードのモジュールにこれらのUOを出力するのがディスパッチャ１７の処理である。
【０１２２】
AV再生制御エンジン１８は、HDMVモジュール１４、あるいはBD-Jモジュール１５からの呼び出しに応じて、AV再生機能、プレイリストの再生機能を実行する。AV再生機能とはBD-ROMにて定義されている、DVDプレーヤ、CDプレーヤから踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、副映像切り替え、アングル切り替えといった処理である。プレイリスト再生機能とは、このAV再生機能のうち、再生開始や再生停止をプレイリスト情報に従って行う。
【０１２３】
アプリデータ関連付けモジュール１９は、仮想ファイルシステム２５から読み出される情報と、機器内で計算した結果、及びアプリケーションが設定する属性情報を元に、アプリケーション関連付け情報を生成、及び更新する機能を有している。
UO検知モジュール２１は、装置の視聴者が再生装置に対して入力を実施したユーザの操作（UO）を受け取る。これは例えばリモコン・コントローラのような遠隔機器で入力されるものである場合もあるし、機器に対して設置されるボタンのようなインタフェースによって直接入力されるものである場合もある。
【０１２４】
プレーン合成部２０は、左ビデオプレーン５または右ビデオプレーン６に格納されている非圧縮形式のビデオのピクチャデータと、左イメージプレーン９または右イメージプレーン１０に格納されているイメージデータとの合成処理を行い、結果を映像として出力する。またプレーン合成部２０は、１プレーン分の合成処理が完了した時点で、左右どちらのプレーンを対象とする合成処理が完了したかを通知する合成処理完了通知を、左右描画処理調停部３０に対して行う。
【０１２５】
レンダリングエンジン２２は、左イメージプレーン９および右イメージプレーン１０に対する描画処理を行う。BD-Jモジュール１５は、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等の描画処理を、レンダリングエンジン２２を通じて左イメージプレーン９および右イメージプレーン１０に対して行うライブラリを有しており、BD-Jアプリはこれらの描画処理の要求を連続的に発行することで、様々なグラフィクス描画処理を実現することができる。
【０１２６】
ネットワークインターフェース２３は、インターネット上に公開されたBD-ROM追加コンテンツのダウンロードに用いられる。BD-ROM追加コンテンツとは、オリジナルのBD-ROMにないコンテンツで、例えば追加の副音声、字幕、特典映像、アプリケーションなどである。BD-Jモジュール１５からネットワークインターフェース２３を制御することができ、インターネット上に公開された追加コンテンツをローカルストレージ２４やリムーバブルメディア２７にダウンロードすることができる。
【０１２７】
ローカルストレージ２４は、再生装置に内蔵されているハードディスク等の磁気記録装置である。BD-ROM１００に記録されているファイル形式またはそれに準ずる形で、トランスポートストリームや再生に使用する各種のデータを記録する。
仮想ファイルシステム２５は、BD-ROM１００あるいは、ローカルストレージ２４あるいは、リムーバブルメディア２７に記録されているファイルに対するリード・ライト機構を提供するファイルシステムである。
【０１２８】
BD-ROMの再生時に必要とされるファイルアクセスは、通常BD-ROM１００に対して行われるが、仮想ファイルシステム２５はローカルストレージ２４あるいはリムーバブルメディア２７に存在するファイルを、あたかもBD-ROM１００上に記録されているファイルであるかのように仮想的にファイルのアドレス変換を行う機構を備える。すなわち本仮想ファイルシステム２５はファイルの物理的な記録先を抽象化する機構を提供する。
【０１２９】
オーディオデコーダ２６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。
リムーバブルメディア２７は再生装置に装着された外部スロットから挿入される記憶媒体である。記憶媒体の種類は典型的にはSDカードなどのフラッシュメディアが利用されるが、USBメモリ、リムーバブルハードディスク、その他任意の種類の記憶媒体であってもよい。
【０１３０】
次元判定部２８は、再生対象の映像が、立体視（3D）用のものであるか、２D用のものであるかを判定し、その結果を次元モード記憶部２９に出力する。判定は、カレントプレイリストあるいはカレントストリームの中に、立体視（3D）に対応する映像か対応しない映像かのフラグが含まれている場合には、これを使用することにしてもよいし、あるいは再生装置を鑑賞するユーザの指定によって切り替えが行われるようになっていてもよい。
【０１３１】
次元モード記憶部２９は、その時点で再生されている映像が、立体視（3D）用のものであるか、通常の２D用のものであるかを記憶する。
左右描画処理調停部３０は、ミドルウェア１１５の構成要素であり、BD-Jモジュール１５から連続的に発行される描画要求の中から左イメージプレーン９への描画要求と右イメージプレーン１０への描画要求のセットを抽出する。立体視のグラフィックスを描画する典型的なBD-Jアプリでは、ある一つの描画対象オブジェクトについて、左眼視点から見た形状を左イメージプレーン９に描画し、右眼視点から見た形状を右イメージプレーン１０に描画するというセットの処理を連続して行うことが多いと想定される。そこで、これらセットを成す描画処理に対応している描画要求の対を抽出し、プレーン合成部２０が左眼と右眼の視覚の不整合を生じさせるような映像を出力しないように、レンダリングエンジン２２の描画処理のタイミングおよび描画順序を制御することで、立体視映像のちらつきを抑制することが可能となる。
【０１３２】
描画要求のセットの抽出およびレンダンリングエンジン２２の描画処理の制御に関する具体的な方法については後述する。
本実施の形態では以下、プレイリスト中に3D用か２D用かを識別する次元識別フラグを有しているものとして説明する。
先ず、本再生装置がどのようにして3D映像を作り出すかを図２５に示される構成図をもとに説明する。BD-ROM上に配置されたストリームは、右眼用ストリームと左眼用ストリームを別々に記録していても良いし、一つのストリームファイルに規則を持って埋め込んでおいても良いが、本実施の形態においては、予め一つのストリームファイルに右眼用ストリームと左眼用ストリームが埋め込まれていることを前提に記載する。
【０１３３】
デマルチプレクサ３はストリームのヘッダ情報から左眼用ストリームと右眼用ストリームの振り分けを行う。
本実施の形態における再生装置２００は、一組のビデオデコーダと左眼用のビデオプレーンである左ビデオプレーン５と右眼用のビデオプレーンである右ビデオプレーン６を持ち、立体視映像を出力する際にはこのビデオデコーダが左眼用の映像と右眼用の映像の処理を交互に行い、それぞれ左ビデオプレーン５と右ビデオプレーン６に交互に出力する。
【０１３４】
再生装置２００に対して再生指示が行われると、図２６に示した処理が開始される。この再生指示自体は、ユーザの再生時の指定（例えば再生ボタンの押下）に従って行われる場合、BD-ROM１００の再生装置への挿入によって自動的に行われる場合、その他BD-Jモジュールを含む、何らかの装置内の設定によって自動的に行われる場合等、指示の開始はさまざまなケースが考えられる。本実施の形態では、任意の形式によって開始されたものと考えてよい。
【０１３５】
図２６は、左右プレーンの交互出力を実現する場合のフレーム処理の処理手順を示すフローチャートである。フレーム処理とは、映像信号のフレーム期間において、ビデオプレーンやイメージプレーンからデータを読み出し、重畳して出力するという処理である。つまり、ミドルウェアからイメージプレーンへの描画イメージの書き込みについては、第１実施形態から第３実施形態までで説明を終えているので、本実施形態ではイメージプレーン及びビデオプレーンから合成部へのデータ読み出しを中心にして説明を行う。
【０１３６】
ステップＳ４０１において、仮想ファイルシステム２５から読み出される１つ以上のプレイリスト、複数ストリームの中から、再生処理対象として指定されたプレイリストとトランスポートストリームを抽出し、カレントプレイリスト（PL）情報とカレントストリーム管理情報に設定する。
またデマルチプレクサ３は静的シナリオメモリ１１のカレントプレイリスト情報を参照し、処理対象となるトランスポートストリームを取得する。
【０１３７】
ステップＳ４０２においては、デマルチプレクサ３は静的シナリオメモリ１１のカレントプレイリスト情報から次元識別フラグを取得し、次元判定部２８に引き渡し、再生対象のストリームが２D用か3D立体視用かの判定結果を得る。
判定結果が２Dであった場合は、２Dの映像出力処理を行う。この場合、そもそもL画像とR画像は同一の画像であるか、もし別々の映像が存在していたとしても、どちらかの映像が破棄され表示されず、その結果従来のBD-ROM再生と同様の処理となる。一例として、２Dの映像出力が常に左ビデオプレーン５に出力され、イメージデコーダ８やレンダリングエンジン２２は常に左イメージプレーン９にのみイメージデータを出力し、プレーン合成部２０は常に左ビデオプレーン５と左イメージプレーン９の合成のみを行う構成が挙げられる。
【０１３８】
ステップＳ４０２の判定が3Dであった場合は、3D映像の再生を開始する。
本実施の形態では、再生装置２００は、プレーン合成部２０を通して、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力とを交互に繰り返すものとする。
さて、3D映像の再生が開始されると、再生装置２００はステップＳ４０３L以降の処理に従って、左右の出力映像を生成する。L画像の生成処理は、ステップＳ４０３L、ステップＳ４０４L、ステップＳ４０５L、ステップＳ４０６Lに相当し、R画像の生成処理は、ステップＳ４０３、ステップＳ４０４R、ステップＳ４０５R、ステップＳ４０６Rに相当する。
【０１３９】
ステップＳ４０３Lの処理は、処理対象となるトランスポートストリームから、ビデオデコーダにより、左眼用のビデオピクチャを取り出し、左ビデオプレーン５に出力する。
続いてステップＳ４０４LおよびステップＳ４０５Lにおいて、プレーン合成部２０は、左ビデオプレーン５のビデオピクチャと左イメージプレーン９のイメージデータについて、プレーン全体にわたって合成する処理を行う。
【０１４０】
ここでは、左ビデオプレーン５と左イメージプレーン９の解像度が同じで、いずれも幅Wピクセル、高さHピクセルであるものとする。この場合、合成の処理は１番上の行（y=０）から１番下の行（y=H-１）の方向に向かって順番に、左ビデオプレーン５のy行目のラインデータの上に左イメージプレーン９のy行目のラインデータを重畳して、L画像のy行目が生成され、最終的な映像出力として出力される。
【０１４１】
プレーン全体に対して合成処理が完了すると、プレーン合成部２０はステップＳ４０６Lの処理にて、L画像の合成処理が完了したという合成処理完了通知を、左右描画処理調停部３０に対して行う。
続いて、ステップＳ４０３R、ステップＳ４０４R、ステップＳ４０５R、ステップＳ４０６Rの各処理により、R画像の生成が行われるが、これらの処理はそれぞれ、ステップＳ４０３L、ステップＳ４０４L、ステップＳ４０５L、ステップＳ４０６Lと同様のものであるため、ここでは説明を省略する。
【０１４２】
以上が、本実施の形態におけるL画像とR画像の生成および出力である。
この構成においては、左イメージプレーン９のイメージデータ、続いて右イメージプレーン１０の画像が、交互にプレーン合成部２０に送られることとなる。
そのため、例えば左イメージプレーン９のイメージデータが全て送られたステップＳ４０６Lのタイミングで、レンダリングエンジン２２が左イメージプレーン９および右イメージプレーン１０の画像を書き換えたものとする。この場合、その後にステップＳ４０３Rが実行されることにより、プレーン合成部に送られるR画像は、書き換え後の右イメージプレーン１０の格納内容となる。
【０１４３】
一方、プレーン合成部に送られたL画像は、既に送られた書き換え前の画像であるから、結果として出力されるL画像とR画像は、R画像だけが書き換えを反映した不整合なものとなってしまう。
そこで、本実施の形態においては、左右描画処理調停部３０が図２７に示したフローチャートの処理によってレンダリングエンジン２２の処理タイミングを調整する。
【０１４４】
図２７は、描画要求の発行タイミングの調整を伴う場合の左右描画処理調停部３０の処理手順を示すフローチャートである。
左右描画処理調停部３０は、まずステップＳ５０１により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。ステップＳ５０２において、ステップＳ５０１で受け取った描画要求の種別情報が、第１実施形態で説明した「左右同時イメージコピー」であるか否かを判定する。
【０１４５】
描画要求の種別が「左右同時イメージコピー」でなかった場合には、ステップＳ５０３の処理にて、レンダリングエンジン２２に対して描画要求をそのまま発行する。これは従来のBD-Jモジュール１５と同様の処理になるため、説明は省略する。
描画要求の種別が「左右同時イメージコピー」だった場合は、ステップＳ５０４L以降の処理に移る。「左右同時イメージコピー」の描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、これら２つのイメージコピー処理の結果は、プレーン合成部２０において確実に同一フレームの映像出力として処理される必要があり、さもなくば左右の表示の不整合を引き起こすこととなる。
【０１４６】
そこで、まずステップＳ５０４Lの処理にて、プレーン合成部２０からL画像の合成完了通知（図２６のステップＳ４０６Lにて発行されたもの）が来るのを待ってから、ステップＳ５０５Lの処理にてレンダリングエンジン２２に対して左イメージプレーン９に関連するイメージコピー処理の描画要求を発行する。これらの処理により、イメージコピー処理が十分高速なハードウエア（具体的には、プレーン合成部２０がR画像の合成を行っている約０．５フレーム期間内にイメージコピーが完了する場合）においては、「左右同時イメージコピー」のうち左イメージプレーン９に対するイメージコピーの結果は、次のフレーム期間において、映像出力に反映されることを保証することができる。
【０１４７】
続いてR画像についても同様に、ステップＳ５０４Rの処理にて、プレーン合成部２０からR画像の合成完了通知（図２６のステップＳ４０６Rにて発行されたもの）が来るのを待ってから、ステップＳ５０５Rの処理にてレンダリングエンジン２２に対して右イメージプレーン１０に関連するイメージコピー処理の描画要求を発行する。これらの処理により、「左右同時イメージコピー」のうち右イメージプレーン１０に対するイメージコピーの結果は、図２６においては次のフレームにおいて、映像出力に反映されることを保証することができる。
【０１４８】
以上の処理により、「左右同時イメージコピー」を構成する２つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力に反映されるため、L画像とR画像の表示不整合に伴うちらつきを抑止することが可能となる。
また、本実施の形態においては、ステップＳ５０４LおよびステップＳ５０４Rにて合成処理完了通知を待つ。尚、「左右同時イメージコピー」は１フレームあたり1回に制約されることになるが、複数の描画要求を組み合わせて１フレームの描画を構成する必要がある場合には、まず前述のBufferedImage上に描画結果を生成しておき、最後に１回の「左右同時イメージコピー」で左右のイメージプレーンにコピーを行う実装とすればよい。これは、従来のBD-Jアプリにおいても、ちらつき防止のために頻繁に用いられている手法である。
【０１４９】
また、「左右同時イメージコピー」のみをステップＳ５０４L以降の処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「左右同時矩形塗り潰し」等を新たに導入し、ステップＳ５０４L以降の処理対象としてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１５０】
更に3D→2D切り替え時の強制コピーを実行してもよい。即ち、ステップＳ４０２の判定が２Dであった場合は、前述の通り、例えば、2Dモードの映像出力は常に左ビデオプレーン５に出力され、レンダリングエンジン２２は常に左イメージプレーン９にのみ描画を行い、プレーン合成部２０は常に左ビデオプレーン５と左イメージプレーン９の合成のみを行うことになる。
【０１５１】
ここで、２Dのストリームの再生が一旦終了し、続いて3Dのストリームの再生が開始される場合を考える。２Dのストリームの再生中は、BD-Jアプリも2D描画のアプリとして動作するため、左イメージプレーン９に対してのみ描画を行い、右イメージプレーンには何も描画を行わず、例えば全面黒色のままとなっている。ところが、この状態のままで3Dのストリームの再生に切り替わると、プレーン合成部２０はステップＳ４０４R、ステップＳ４０５Rの処理にて、何も描画がなされていない右イメージプレーン１０の画像を出力してしまう。3Dストリームに切り替わると、BD-Jアプリも3D描画のアプリとして動作を開始することが期待されるが、これらの切り替わりのタイミングにタイムラグが存在すると、一瞬R画像のみ全面黒色の出力がなされるため、ちらつきが発生してしまう。
【０１５２】
このようなちらつきを回避するには、プレーン合成部２０の動作が２Dから3Dに切り替わるタイミングで、左イメージプレーン９の内容を右イメージプレーン１０に強制的にコピーするようにすればよい。
ストリームが２Dから3Dに切り替わる場合だけではなく、例えばBD-Jモジュールの動作モードのみを２Dから3Dに切り替える機能が存在する場合についても、切り替えのタイミングで同様のコピーを行うようにすることで、BD-Jアプリの実装如何に関わらず、同種のちらつきを防止することができる。
【０１５３】
さらに、BD-Jモジュールが左イメージプレーン９のみを用いて3D描画を行う1plane＋Offsetモードに対応している場合、コピー処理とシフト処理とを実行することで、左右の不整合を解消することができる。
1plane＋Offsetモードとは、左イメージプレーン９全体をL画像としては左にnピクセル分、R画像としては右にnピクセル分シフトして出力することで、プレーン全体を手前あるいは奥まって表示させるモードである。かかる1plane＋Offsetモードにおいて、左イメージプレーン９全体が右にnピクセル分シフトされた後に、シフト後の画像を右イメージプレーン１０にコピーする。その後、左イメージプレーン９全体を左にnピクセル分シフトさせれば、描画モードの遷移前と遷移後のL画像およびR画像の出力が一致するため、ちらつきを抑止することが可能となる。
【０１５４】
この1plane＋Offsetモードから左右両方のイメージプレーンを使用する3D描画モードに遷移する場合においても、かかるシフト及びコピー処理を適用することができる。
以上が、本発明にかかる立体視ビデオ再生方式の実施形態である。
（第５実施形態）
本実施形態では、プレーン合成部２０および左右描画処理調停部３０の別の実施形態について説明する。
【０１５５】
プレーン合成部２０、左右描画処理調停部３０以外の構成要素については第４実施形態と同様であるためここでは説明を省略し、異なる部分についてのみ説明を行う。
図２８は、ラインの交互出力を実現する場合の、フレーム処理を示すフローチャートである。
ステップＳ７０１およびステップＳ７０２は、それぞれ図２６のステップＳ４０１、ステップＳ４０２と同様であり、ステップＳ７０２の判定結果が3Dであった場合は、3D映像の再生を開始する。
【０１５６】
3D映像の再生が開始されると、再生装置２００はステップＳ７０３L以降の処理に従って、左右の出力映像を生成する。まず、ステップＳ７０３LおよびステップＳ７０３Rの処理により、処理対象となるトランスポートストリームから、ビデオデコーダにより、左眼用のビデオピクチャおよび右眼用のビデオピクチャを取り出し、それぞれ左ビデオプレーン５、右ビデオプレーン６に出力する。
【０１５７】
続いてステップＳ７０４のループ処理で、プレーン合成部２０は、左右のプレーン全体にわたって合成する処理を行う。
ここでは、左右のビデオプレーンと左右のイメージプレーンの解像度が同じで、いずれも幅Wピクセル、高さHピクセルであるものとする。この場合、合成の処理は１番上の行（y=０）から１番下の行（y=H-１）の方向に向かって１ラインずつ順番に行われる。
１ライン毎の処理としては、まずステップＳ７０５Lにおいて、左ビデオプレーン５のy行目の映像の上に左イメージプレーン９のy行目の映像を重畳して、出力L画像のy行目が生成され、最終的な映像出力として出力する。
【０１５８】
続いて、ステップＳ７０５Rにおいて、右ビデオプレーン６のy行目の映像の上に右イメージプレーン１０のy行目の映像を重畳して、出力R画像のy行目が生成され、最終的な映像出力として出力する。ここでは上から順番に１ラインずつ処理する構成をとったが、下から上への順番など、他の順番に処理を行ってもよい。また、ビデオプレーンとイメージプレーンの解像度を同一としたが、これらの解像度が異なる構成をとってもよい。
【０１５９】
プレーン全体に対して合成処理が完了すると、プレーン合成部２０はステップＳ７０６の処理にて、L画像とR画像の両方の合成処理が完了したという合成処理完了通知を、左右描画処理調停部３０に対して行う。
以上が、本実施の形態において立体視映像を映し出す際の処理の流れである。
この構成においては、左イメージプレーン９のイメージデータ、続いて右イメージプレーン１０の画像が１ラインずつ交互に、すなわち１フレームとして見れば両画像が並行でプレーン合成部２０に送られることとなる。
【０１６０】
そのため、例えばBD-Jアプリがある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をこの順番で描画しようとした場合、レンダリングエンジン２２は、まず左イメージプレーン９の画像を書き換える。しかし、このタイミングで、左右イメージ出力が実行されると、生成されるL画像については左イメージプレーン９の書き換えを反映したものになるが、R画像についてはまだ右イメージプレーン１０は書き換え前であるため、結果として出力されるL画像とR画像は、L画像だけが書き換えを反映した不整合なものとなってしまう。
【０１６１】
そこで、本実施の形態においては、左右描画処理調停部３０が図２９に示したフローチャートの処理によってレンダリングエンジン２２の処理順序を制御することで、前述のような不整合な表示の回避を行う。図２９は、描画要求の統合を伴う左右描画処理調停部３０の処理手順を示すフローチャートである。
まずステップＳ８０１により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求Aが発行されるのを待つ。発行される描画要求は、先の実施の形態と同様の構造で表現される。
【０１６２】
次にステップＳ８０２において、ステップＳ８０１で受け取った描画要求Aの種別情報が「イメージコピー」で、かつ描画対象プレーンが左イメージプレーン９であるか否かを判定する。
ステップＳ８０２の条件を満たさなかった場合は、ステップＳ８０３の処理にて、レンダリングエンジン２２に対して描画要求Aをそのまま発行する。これは従来のBD-Jモジュール１５と同様の処理になるため、説明は省略する。
【０１６３】
ステップＳ８０２の条件を満たした場合、描画要求Aの処理はこのタイミングでは行わずに保留しておき、次のステップＳ８０４において、BD-Jモジュール１５からの次の描画要求Bが発行されるのを待つ。
次にステップＳ８０５において、ステップＳ８０４で受け取った描画要求Bの種別情報が「イメージコピー」で、かつ描画対象プレーンが右イメージプレーン１０であるか否かを判定する。
【０１６４】
ステップＳ８０５の条件を満たした場合は、続くステップＳ８０９の処理にて、描画要求Aのイメージコピーの描画位置と、描画要求Bのイメージコピーの描画位置との比較を行う。具体的には両者の描画先矩形領域のY座標を意味するy１およびy２の値がともに一致するか否かを判定する。
立体視のグラフィックスを描画する典型的なBD-Jアプリでは、ある一つの描画対象オブジェクトについて、左眼視点から見た形状を左イメージプレーン９に描画し、右眼視点から見た形状を右イメージプレーン１０に描画するというセットの処理を連続して行うことが多いと想定される。さらに、左右の描画の違いは視点の差に起因するものであるため、Y座標は同じでX座標のみ視差の分だけずらした描画であることが想定される。そこで、描画要求Aおよび描画要求Bがそれぞれ左イメージプレーン９、右イメージプレーン１０へのイメージコピーで、その描画位置の差がX座標のみであることを判定することで、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。したがって、これら２つのイメージコピー処理の結果は、プレーン合成部２０において確実に同一フレームの映像出力として処理を行う必要がある。
【０１６５】
そこで、ステップＳ８０９の条件を満たした場合、左右描画処理調停部３０はステップＳ８１０の処理により、レンダリングエンジン２２に対して描画要求Aおよび描画要求Bの代わりに、描画要求A,Bを統合した左右同時描画要求Cを発行する。
図３０（ａ）は、上記統合によって得られた左右同時描画要求Cを示す図である。図３０（ａ）における左右同時描画要求９０３(描画要求C)は、図３０（ｂ）における描画要求９０１（描画要求A）と、図３０（ｃ）における描画要求９０２（描画要求B）の２つの描画要求を１つにまとめたものである。
【０１６６】
左右同時描画要求Cを受けたレンダリングエンジン２２は、左イメージプレーン９へのイメージコピー処理と右イメージプレーン１０へのイメージコピー処理を、順番に行うのではなく、例えば左右のコピー処理をビットマップイメージの上から下へと１ラインずつ交互に行うようにする。これにより、左右イメージプレーンへの描画処理が同時並行的に実行されることになるため、図２８におけるプレーン合成部２０の合成処理ステップＳ７０４、ステップＳ７０５L、ステップＳ７０５Rがどのタイミングで動作していても、出力映像としてのL画像とR画像の表示の不整合は最小限に抑えることが可能となる。
【０１６７】
ここではレンダリングエンジン２２は左右を１ラインずつ処理する例を挙げたが、交互に切り替える処理の単位は１ラインずつに限定されるものではなく、また２つのレンダリングエンジンを備えることで完全な並列処理を行う構成をとってもよい。
一方で、ステップＳ８０５またはステップＳ８０９の条件が満たされなかった場合は、描画要求Aと描画要求Bは一つのオブジェクトについて左右の視点から見た描画を行うという、セットではなかったと判断され、以降は従来と同様の処理、すなわち表示のちらつきの発生も許容する処理が行われることになる。
【０１６８】
そこで次のステップＳ８０６の処理にて、警告メッセージを出力することで、BD-Jアプリの開発者あるいは再生装置２００のユーザに対して、本BD-Jアプリではちらつきが発生する可能性がある旨を通知することができる。警告メッセージの出力としては、例えばBD-Java仕様におけるExceptionメッセージをスローすることで、BD-Jアプリの開発者に警告を知らせてもよいし、表示ディスプレイ４００に警告メッセージを表示することで、BD-Jアプリの開発者あるいは再生装置２００のユーザに対して警告を知らせる構成をとってもよい。
【０１６９】
続いてステップＳ８０７およびステップＳ８０８の処理にて、保留されていた描画要求Aおよび描画要求Bをレンダリングエンジン２２に対してそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
以上の処理により、ステップＳ８０２、ステップＳ８０５、ステップＳ８０９の条件を満たす2つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力の中で同時に反映されることになる。したがって、ちらつき（ティアリング）が発生する可能性はあるものの、L画像とR画像の表示不整合に伴う左右の視覚の不整合を伴うちらつきは抑制することが可能となる。
【０１７０】
尚、判定対象のバリエーションとして以下のものを採用してもよい。つまり本実施の形態においては、「イメージコピー」のみをステップＳ８０２、ステップＳ８０５の判定処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「矩形塗り潰し」等についても判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１７１】
また本実施例ではステップＳ８１０において即時に左右同時描画要求を発行しているが、図２８のステップＳ７０６による合成処理完了通知を待ってから、左右同時描画要求を発行するような構成としてもよい。この構成をとった場合、イメージコピー処理が十分高速なハードウエアにおいては、図２８においては次フレームのステップＳ７０５L、ステップＳ７０５Rの処理が実行される前にイメージコピー処理を完了させることができるため、ティアリングも発生しない、より高品位な画面の更新を実現することが可能となる。
【０１７２】
更に、本実施の形態ではL画像とR画像の処理を上から１ラインずつ交互に行うことで、擬似的にL画像とR画像の生成を並行で行う構成をとるものとしているが、処理の単位は１ラインに限るものではない。
出力の２系統にしてもよい。つまり再生装置のハードウエアの構成によっては、デマルチプレクサ３は別の出力方式を実施しても良い。図２５の構成図にはビデオデコーダとイメージデコーダ、プレーン合成部を各一組ずつ有しているが、例えばこれらの構成を２つずつ持つハードウエアでは、左眼用と右眼用の映像を別々の系統で処理することができる。すなわち、左眼用のビデオデコーダが左ビデオプレーン５にビデオピクチャを格納し、左眼用のイメージデコーダが左イメージプレーン９にイメージデータを格納し、左眼用のプレーン合成部が左ビデオプレーン５と左イメージプレーン９のピクチャを合成し、右眼用についても同様に別系統で処理するような構成をとることで、L画像の生成処理とR画像の生成処理を完全に並列で行うようにしてもよい。
【０１７３】
また本実施形態においては、プレーン合成部２０の映像出力は、L画像とR画像を１ラインずつ交互に出力する構成をとっているが、映像出力についてもこの形式に限定するものではない。例えば、前述の左眼用と右眼用の二系統のハードウエアを持つ構成においては、映像出力としても左眼用映像出力と右眼用映像出力の二系統を有する構成もとることができる。また、プレーン合成部２０の映像出力の先に出力映像の一時保存用バッファを設けることにより、実施の形態１と同様の、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力を交互に繰り返すような構成をとることもできる。
【０１７４】
（第６実施形態）
描画要求に加え、画面更新要求を発行することで映像出力を実現する改良である。
図３０（ｄ）は、画面更新要求９０４を示す。この画面更新要求９０４は、BD-Javaの規格においてjava.awt.Toolkit#syncメソッドとして規定される。画面更新処理は、現在のイメージプレーンの画像を確実に表示ディスプレイ側に送ることをBD-Jアプリ側から保証するためのものであり、イメージプレーンとしてダブルバッファ構成を導入している実装、すなわち描画対象バッファと表示対象バッファとを個別に持つことでティアリングを抑える実装において、特に意味を持つものである。
【０１７５】
図３１は、画面更新要求をトリガとした左右描画処理調停部３０の処理手順を示すフローチャートである。
本フローチャートのステップＳ１００１、ステップＳ１００２、ステップＳ１００３、ステップＳ１００４、ステップＳ１００５、ステップＳ１００６、ステップＳ１００７、ステップＳ１００８の各処理は、それぞれステップＳ８０１、ステップＳ８０２、ステップＳ８０３、ステップＳ８０４、ステップＳ８０５、ステップＳ８０６、ステップＳ８０７およびステップＳ８０８、ステップＳ８０９と同様である。
【０１７６】
ステップＳ１００２、ステップＳ１００５、ステップＳ１００８の各条件が満たされた場合、すなわち、描画要求Aと描画要求Bが一つのオブジェクトについて左右の視点から見た描画を行うセットに該当すると判断された場合、描画要求Aおよび描画要求Bに相当する処理はこのタイミングでは行わない。つまり、描画要求A,Bを保留しておき、次のステップＳ１００９において、BD-Jモジュール１５からの次の描画要求Cが発行されるのを待つ。
【０１７７】
次のステップＳ１０１０において、描画要求Cの種別が「画面更新」であるか否かを判断する。描画要求Cが「画面更新」であった場合は、左右描画処理調停部３０はステップＳ１０１３の処理により、レンダリングエンジン２２に対して描画要求Aおよび描画要求Bの代わりに、左右同時描画要求を発行する。
描画要求Cが「画面更新」でなかった場合は、ステップＳ１０１１において、警告メッセージを出力した後、ステップＳ１０１２において、保留されていた描画要求A、描画要求B、描画要求Cをレンダリングエンジン２２に対して順番にそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
【０１７８】
以上が、本実施の形態における左右描画処理調停部３０の処理の流れである。
イメージプレーンがシングルバッファ構成をとっている場合は、画面更新要求の有無に関わらず、イメージプレーンの画像がプレーン合成部２０の動作タイミングに応じて映像出力に反映されるため、画面更新要求自体は必ずしも意味を持たない。一方、イメージプレーンがダブルバッファ構成をとっている場合は、画面更新要求が重要な意味を持つ。本実施の形態では、BD-Jアプリが左イメージプレーン９への「イメージコピー」、右イメージプレーン１０への「イメージコピー」、「画面更新」の３つをこの順番で呼び出さなければ、警告メッセージが出力されることになるため、BD-Jアプリ開発者に様々な再生装置において再生互換性が高いBD-Jアプリの開発を促すことができる。
【０１７９】
（第７実施形態）
前述の第４実施形態、第５実施形態および第６実施形態においては、左イメージプレーン９と右イメージプレーン１０はそれぞれ別個のイメージプレーンとしており、BD-Jアプリからの描画要求の観点では、描画対象プレーンが別々のものとして扱うことを前提としていた。本実施形態においては、左イメージプレーン９および右イメージプレーン１０を、BD-Jアプリの観点では同一のプレーンとして扱うものとする。
【０１８０】
図３２（ａ）は、左イメージプレーン９と右イメージプレーン１０とを左右に並べて連結することで構成される連結イメージプレーン（以降、サイドバイサイド形式と呼ぶ）を示す。この構成においては、左右のイメージプレーンの解像度がそれぞれ幅Wピクセル、高さHピクセルであるとすると、連結イメージプレーンは幅W×２ピクセル、高さHピクセルとなる。
【０１８１】
このサイドバイサイド形式のイメージプレーンの連結は、左右のイメージプレーンを、物理的に連続する同一のメモリとして構成することで実現可能となる。
左イメージプレーン９と右イメージプレーン１０は別々のメモリによって構成し、BD-Jアプリに対してのみ一つの連結イメージプレーンとして見せるような構成を採用することでも実現可能である。
【０１８２】
図３２（ｂ）は、左イメージプレーン９と右イメージプレーン１０を上下に並べて連結したものを一つの一般として扱う連結イメージプレーン（以降、トップアンドボトム形式と呼ぶ）を示す。この構成においては、左右のイメージプレーンの解像度が幅Wピクセル、高さHピクセルであるとすると、連結イメージプレーンは幅Wピクセル、高さH×２ピクセルとなる。
【０１８３】
このトップアンドボトム形式におけるイメージプレーンの連結にあたっても、左右のイメージプレーンを、物理的に連続する同一のメモリとして構成するのが望ましい。左イメージプレーン９と右イメージプレーン１０は別々のメモリによって構成し、BD-Jアプリに対してのみ一つの連結イメージプレーンとして見せるような構成としてもよい。
トップアンドボトム形式の連結イメージプレーンを持つ場合、BD-Jアプリケーションは、図３２（ｂ）において、左イメージプレーンと右イメージプレーンとを上下にまたがるような矩形領域をイメージコピー処理の対象にすることができる。
【０１８４】
さて、本実施形態に係る再生装置２００がディスプレイ４００に立体視映像を映し出す際の処理は、図３３に示される処理によって実現されるものとする。
図３３は、本実施の形態における左右描画処理調停３０の処理のフローチャートである。
まずステップＳ１１０１において、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。描画要求が発行されれば、Ｓ１１０２において、ステップＳ１１０１で受け取った描画要求の種別情報が「イメージコピー」で、かつ描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるものであるか否かを判定する。
【０１８５】
ステップＳ１１０２の条件を満たさない場合は、ステップＳ１１０３において、レンダリングエンジン２２に対して描画要求をそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
ステップＳ１１０２の条件を満たした場合には、ステップＳ１１０４Lに移行する。
描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるような描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、本実施の形態においては、ステップＳ１１０４L以降の処理によって、左右描画処理調停部３０がレンダリングエンジン２２の処理タイミングを調整することで、L画像とR画像の表示の不整合の回避を試みる。
【０１８６】
まず、ステップＳ１１０４Lにおいて、プレーン合成部２０からL画像の合成完了通知（図２６のステップＳ４０６Lにて発行されたもの）が来るのを待つ。
次に、ステップＳ１１０５Lにおいて、描画位置として左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理の描画要求をレンダリングエンジン２２に対して発行する。例えば図３２（ａ）における矩形領域１３０１の場合は、左上が（x１，y１）、右下が（W，y２）で指定される矩形領域を対象としたイメージコピーを発行すればよい。
【０１８７】
R画像についても同様に、ステップＳ１１０４Rにおいて、プレーン合成部２０からR画像の合成完了通知（図２６のステップＳ４０６Rにて発行されたもの）が来るのを待つ。そして合成完了通知が発行されれば、ステップＳ１１０５Rにおいて、描画位置として右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理の描画要求をレンダリングエンジン２２に対して発行する。図３２（ａ）における矩形領域１３０１の場合は、左上が（W，y１）、右下が（x２，y２）で指定される矩形領域を対象としたイメージコピーを発行すればよい。
【０１８８】
これらの処理により、イメージコピー処理が十分高速なハードウエアにおいては、左イメージプレーン９に対するイメージコピーの結果は、図２６においては次のフレームのステップＳ４０４L、ステップＳ４０５Lの処理にて映像出力に反映され、右イメージプレーン１０に対するイメージコピーの結果は、次のフレームのステップＳ４０４R、ステップＳ４０５Rの処理にて映像出力に反映されることを保証することができ、２つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力に反映されるため、L画像とR画像の表示不整合に伴うちらつきを防止することが可能となる。
【０１８９】
尚、本実施の形態においては、「イメージコピー」のみをステップＳ１１０２の判定処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「矩形塗り潰し」等についても判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１９０】
(第８実施形態)
連結イメージプレーンに対する描画要求の分離を実現する実施形態である。描画要求の分離は、ある矩形範囲に対する描画要求を、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理と、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理とに分離して、これらのイメージコピー処理を同時に実行させるものである。
【０１９１】
図３４は、描画要求と、左右同時描画要求とを示す。
図中の描画要求１４０１は、解像度が幅1000ピクセル、高さ1500ピクセルの描画イメージである”ビットマップイメージ１”を、トップアンドボトム形式のイメージプレーンにおける(x1,y1)=(200,300),(x2,y2)=(1200,1800)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
【０１９２】
左右同時描画要求１４０２は、描画要求１４０１を変換することで得られる左右同時描画要求であり、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理、及び、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理を左右同時に要求するものである。
左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理は、”ビットマップイメージ１”のx1=0,y1=0,x2=1000,y2=780の矩形領域を、イメージプレーンにおける(x1,y1)=(200,300),(x2,y2)=(1200,1080)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
【０１９３】
右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理は、”ビットマップイメージ１”のx1=0,y1=780,x2=1000,y2=1500の矩形領域を、イメージプレーンにおける(x1,y1)=(200,0),(x2,y2)=(1200,720)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
図３５は本実施の形態における左右描画処理調停部３０の処理のフローチャートである。まずステップＳ１２０１の処理により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。
【０１９４】
次に、ステップＳ１２０２において、ステップＳ１２０１で受け取った描画要求の種別情報が「イメージコピー」で、かつ描画範囲が左右の領域にまたがるものであるか、又は、上下の領域にまたがるものであるか否かを判定する。トップアンドボトム形式の連結イメージプレーンを持つ場合、BD-Jアプリは、上下にまたがるような矩形領域を描画範囲としてイメージコピー処理を要求することができる。
【０１９５】
サイドバイサイド形式の連結イメージプレーンを持つ場合、BD-Jアプリは、左右にまたがるような矩形領域を描画範囲としてイメージコピー処理を要求することができる。
ステップＳ１２０２の条件を満たさない場合は、ステップＳ１２０３の処理にて、レンダリングエンジン２２に対して描画要求をそのまま発行することで、これまでと同様の描画処理が実行される。
【０１９６】
ステップＳ１２０２の条件を満たした場合には、ステップＳ１２０４において、受け付けた描画要求を、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理と、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理とを同時に実行させる左右同時描画要求に変換して、レンダリングエンジン２２に発行する。
【０１９７】
描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるような描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、ステップＳ１２０４において、1つのイメージコピー処理を要求する描画要求を、2つのイメージコピー処理を同時に要求する左右同時描画要求に変換することにより、レンダリングエンジン２２の処理順序を制御し、L画像とR画像の表示の不整合の回避を行う。
【０１９８】
尚、左右同時描画要求１４０２を受けたレンダリングエンジン２２は、前述の実施形態で説明したように、左イメージプレーン９へのイメージコピー処理と右イメージプレーン１０へのイメージコピー処理を順番に行うのではなく、例えば左右のコピー処理をビットマップイメージの上から下へと１ラインずつ交互に行うようにすることで、出力映像としてのL画像とR画像の表示の不整合を最小限に抑えることができる。
【０１９９】
ただし、本実施の形態においては、左イメージプレーン９への描画位置のY座標と右イメージプレーン１０への描画位置のY座標が一致しない場合がある。そのため、コピー処理は単純に上から１ラインずつ交互に行うのではなく、例えば左イメージプレーン９のy行目へのコピー処理を行い、その次には、右イメージプレーン１０の同じくy行目へのコピー処理を行うような順序でコピーを行うのが望ましい。
【０２００】
また本実施の形態においては、「イメージコピー」のみをステップＳ１２０２の判定処理の対象とし、イメージコピー以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとった。しかしイメージコピー以外の処理でも、例えば「矩形塗り潰し」等を、左右同時描画要求を行うかどうか判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０２０１】
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
【０２０２】
(立体視方式)
各実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。
【０２０３】
テレビ４００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
【０２０４】
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２０５】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０２０６】
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
【０２０７】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
【０２０８】
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていてもよいし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。
【０２０９】
(ビデオデコーダの構成)
各実施形態において、ビデオデコーダは、左目用のビデオデコーダ5a、右目用のビデオデコーダ5bのそれぞれのものが存在すると説明したが、これらを一体にしてもよい。
（半導体メモリカード記録装置及び再生装置の実施形態）
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
【０２１０】
まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。
BD-ROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。
例えば、BD-ROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。
【０２１１】
以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
半導体メモリカード再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。
【０２１２】
一方、BD-ROMには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するMKB（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びMKBに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、MKB、及び暗号化タイトルキーは対になっており、さらにBD-ROM上の通常コピーできない領域（BCAと呼ばれる領域）に書き込まれた識別子（例えばボリュームID）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。
【０２１３】
装填されたBD-ROMを再生装置において再生する場合、例えばBD-ROM内の暗号化タイトルキー、MKBと対になっている（または対応する）デバイスキーが再生装置内になければ、暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵（タイトルキー）は、鍵自体が暗号化されて（暗号化タイトルキー）BD-ROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵を導き出すことができないからである。
【０２１４】
逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しければ、例えば上述の暗号解読に必要な鍵（デバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。
【０２１５】
以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。
半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを介してデータを読み出すように構成すればよい。
【０２１６】
より詳細には、再生装置のスロット（図示せず）に半導体メモリーカードが挿入されると、半導体メモリーカードI/Fを経由して再生装置と半導体メモリーカードが電気的に接続される。半導体メモリーカードに記録されたデータは半導体メモリーカードI/Fを介して読み出すように構成すればよい。
次に、例えば電子配信を利用して、図1、図２４に示した記録媒体１００に記録されたデータ、例えば記録媒体１００に記録されたオリジナルのコンテンツに対応するデータ（例えば、ビデオストリーム、オーディオストリーム、字幕データ、字幕データ、背景画像、GUI、アプリケーション、アプリケーション管理テーブルなど）の全部若しくは一部（例えば再生に必要なデータのアップデートデータ）、または追加コンテンツを配信データとして、半導体メモリーに記録する動作について説明をする。
【０２１７】
上述の動作は本実施の形態において説明をした再生装置がその半導体メモリーに記録する動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDメモリーカードを例に説明をする。
【０２１８】
再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバ（図示せず）へ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報（例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等）をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。
【０２１９】
この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。
【０２２０】
例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。
生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。
次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。
【０２２１】
次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
【０２２２】
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。
【０２２３】
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、
（１） 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック
（２） 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック
（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番どのような順序で行なってもよい。
【０２２４】
上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いて、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。
【０２２５】
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号（例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等）は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の（１）の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
【０２２６】
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域（第１の記録領域と称す）とは別の記録領域（第２の記録領域と称す）に設けること、およびこの第２の記録領域へのアクセスをするための制御回路を設けるとともに、第２の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
【０２２７】
例えば、第２の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第２の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第２の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行すると、要求を受けた制御回路は第２の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第１の記録領域に記録するように構成すればよい。
【０２２８】
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のＸ.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
【０２２９】
また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。
【産業上の利用可能性】
【０２３０】
本発明は、立体視映像を再生する再生機器において、描画更新のタイミングにおけるちらつきを抑止する技術に関し、特に、再生機器の映像出力と非同期に画像を更新する機能を持つ立体視映像再生装置に適用可能である。
【符号の説明】
【０２３１】
１００ 記録媒体
２００ 再生装置
３００ リモコン
４００ テレビ
５００ シャッター眼鏡
【技術分野】
【０００１】
本発明は、立体視再生の技術分野に属する発明である。
【背景技術】
【０００２】
立体視再生とは、ライトビュー用とレフトビュー用の２つの視点の映像を準備することにより、立体視を実現する技術である。立体視ディスプレイの実現にはさまざまな方式があるが、視聴者の左眼と右眼とに、異なる表示画像を見せ、その両眼間の視差を利用することにより、立体的な映像を擬似的に作ることが基本原理である。
例えば、立体視表示の実現方式の一つにシャッター眼鏡を利用した方式がある。この方式では、表示ディスプレイの映像を左眼用と右眼用とで高速で更新する。この更新タイミングと同期させて、視聴者の左眼と右眼の視野をメガネによって交互に高速に塞ぐことで、ディスプレイで表示される左眼用の画像はシャッター眼鏡により左眼だけによって見え、逆に右眼用の画像は右眼によってだけ見える仕組みを実現できる。
【０００３】
現状、ビデオストリームの立体視再生を利用する形態は、劇場等での応用が主流であるが、今後は家庭設置用の再生装置で立体視ビデオストリームを再生して楽しむ利用形態も普及が予想される。
特にBD-ROM等のパッケージメディアでは、ビデオだけでなく、背景イメージ、字幕、そして描画イメージを別々のプレーンとして持ち、表示機器にはこれらを重ね合わせた映像を表示することができるので、これら背景イメージ、字幕、そして描画イメージのそれぞれで立体視を行えば、対話性の富んだ、立体視再生を実現することができる。これらのうち、ビデオおよび字幕については、再生装置の映像出力信号とフレーム単位で同期する方式が採用されているため、ちらつきのない美しい動画再生が実現されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平９-１３９９５７号公報
【特許文献２】特開２０００-１０２０３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで立体視コンテンツの再生時に、アプリケーションを起動して、動画再生に同期したGUIをアプリケーションに描画させることで、立体視コンテンツの再生時におけるユーザ操作を容易に行わせたいという要望がある。これは、既存のBD-ROMコンテンツにおいて、コンテンツと、アプリケーションとを連動させて、アプリケーションにGUI処理を行わせるという高度な処理が実現されており、これを立体視コンテンツでも実現したいというコンテンツ制作者側からの要望による。
【０００６】
アプリケーションによる描画は、ビットマップパターンを生成して、そのビットマップパターンを１画素ずつ、左右のプレーンメモリに書き込むという処理になる。このような描画を繰り返すことにより、メニューのオープンにあたって、アニメーションによる視覚効果を導入することができる。ところが、画素書き込みの途中で、表示を行うべきフレーム期間が到来した場合、画素の書込途中の映像内容が、表示に供されることになる。画素書き込みの途中で、表示を行うべきフレーム期間が到来し、書込途中の映像内容が表示されることで画面のちらつきが生じることを、”ティアリング”という。
【０００７】
平面視再生においてティアリングは、ユーザの許容範囲となるが、立体視再生の場合、ティアリングは、深刻な不快感をもたらす。右目用プレーンメモリ、左目用プレーンメモリのうち、双方の描画が完了している箇所では立体視効果が生じるものの、ティアリングによって未描画になっている部分では立体視効果が生じないばかりか、左右の目で全く異なる映像が見えるという、現実には起こり得ない状況となるからである。例えば、左目におけるメニューの描画が完了したが、右目におけるメニューの下半分の描画が未完である場合、立体視再生時において、メニューの下半分の部分では左右両眼の間で映像の不整合が生じることになり、ユーザに視覚的な不快感を与える。
【０００８】
立体視再生時におけるティアリングは、左右の映像の不整合という現象が顕在化するので、かかる不整合を確実に防ぐ手だてがないと、立体視再生を行うような再生装置の商品化は難しい。かかる技術的障壁に対しては、左右のイメージプレーンに対する書き込みを完全並列化することが考えられる。しかし再生装置プレーヤモデルの策定にあたって、このようなイメージプレーン書き込みの完全並列化を強制するのは再生装置の実装の自由度を奪うことになり望ましくない。また、ハードウエアの簡易化の余地を奪うので、低コスト競争の足かせになることは明確である。
【０００９】
本発明の目的は、再生装置の実装の自由度を奪うことなく、ティアリングに起因する左右の映像の不整合の発生を、最低限に抑えることができる再生装置を提供することである。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明にかかる再生装置は、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生部と、
アプリケーションを動作させるプラットフォーム部と、
複数のプレーンメモリと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、複数のプレーンメモリに対する描画イメージの書き込みを行う描画部とを備え、
複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする。
【発明の効果】
【００１１】
アプリケーションプログラムインターフェイスの呼び出し時において、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアがバイトコードアプリケーションから引き渡されるので、右目用のプレーンメモリへの画素書き込みと、左目用プレーンメモリへの画素書き込みとを交互に行うような実装が可能になる。この場合、画素書き込みの途中で、表示を行うべきフレーム期間が到来したとしても、画素書き込みの進捗は、右目用と、左目用とで大体同じになる。たとえティアリングが生じたとしても、右目におけるティアリングと、左目におけるティアリングとは同一になるから、両目に映じる映像内容が一致しない映像の不整合の発生は避けられるか、発生したとしても、ユーザに不快を感じさせない許容範囲になる。
【００１２】
左イメージプレーン、右イメージプレーンのうち、どちらか一方の書き込みを先に行い、他方を後にするとの実装であっても、パラメータがアプリケーションから引き渡されないことによる遅延を避けることができるので、表示を行うべきフレーム期間の到来までに、左イメージプレーン、右イメージプレーンへの書き込みを同時に完了させる確率を高めることができる。
【００１３】
イメージプレーンに対する書き込みをライン単位で行う場合であっても、左イメージプレーン→右イメージプレーンの順に行う場合であっても、両目に映じる映像内容が一致しない映像の不整合の発生確率を低下させうるので、再生装置の実装の自由度を奪うことなく、ティアリングに起因する左右の映像の不整合の発生を、最低限に抑えることができる。
【図面の簡単な説明】
【００１４】
【図１】再生装置の使用行為についての形態の一例を示す図である。
【図２】本願の課題解決手段を具備した再生装置の基本的な内部構成を示す。
【図３】ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。
【図４】イメージプレーン１０４c,１０４dの内部構成を示す。
【図５】プレーンオフセットの符号が正（レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす）である場合、像が表示画面よりも手前にあるように見える原理を説明するための図である。
【図６】像が表示画面よりも奥にあるように見える原理を説明するための図である。
【図７】正と負のプレーンオフセットの見え方の違いの一例を示す図である。
【図８】描画イメージの書き込みに用いられるアプリケーションプログラムインターフェイスを示す。
【図９】図８のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。
【図１０】図９（ｃ）のように引数が指定された場合、StereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。
【図１１】フレームi,j,kのそれぞれにおける、左右イメージメモリ、左右のイメージプレーンの書き込み内容を示す。
【図１２】フレームi,j,kにおけるイメージプレーンの書き込み内容が図１１のものである場合、どのようなエフェクトが再生されるかを示す。
【図１３】左右のイメージプレーンへの書き込みをどのように行うべきかを示す。
【図１４】StereoGraphics#drawImageを用いず、左イメージプレーン、右イメージプレーンのそれぞれに対して、個別に、書き込みを行う場合、表示内容がどのようになるかを示す。
【図１５】StereoGraphics#drawImageを用いて、左イメージプレーン、右イメージプレーンのそれぞれに対して、画素の書き込みをライン単位に交互に行う場合、表示内容がどのようになるかを示す。
【図１６】バイトコードアプリケーションによるメニュー表示のフローチャートである。
【図１７】StereoGraphics#drawImageがコールされた際のライン描画手順を示すフローチャートである。
【図１８】第２実施形態に係る再生装置のうち、改良が施された部分（イメージメモリ、イメージプレーン、レンダリングエンジン、合成部）のみを描く。
【図１９】スイッチ１２３、スイッチ１２４による切り替えを示す。
【図２０】左右のイメージプレーンへの書き込みをどのように行うべきかを示す。
【図２１】StereoGraphics#drawImageがコールされた際のダブルバッファを用いた描画手順を示す。
【図２２】動作モードオブジェクトの内部構成の一例を示す図である。
【図２３】タイトル切り替え時におけるプレーンメモリの解像度設定の処理手順の一例を示すフローチャートである。
【図２４】BD-ROM１００の内部構成を示す図である。
【図２５】第４実施形態に係る再生装置の内部構成を示すブロック図である。
【図２６】左右プレーンの交互出力を実現する場合のフレーム処理の処理手順を示すフローチャートである。
【図２７】描画要求の発行タイミングの調整を伴う場合の左右描画処理調停部３０の処理手順を示すフローチャートである。
【図２８】ラインの交互出力を実現する場合の、フレーム処理を示すフローチャートである。
【図２９】描画要求の統合を伴う左右描画処理調停部３０の処理手順を示すフローチャートである。
【図３０】左右同時描画要求Cと、描画要求A,Bを示す図である。
【図３１】画面更新要求をトリガとした左右描画処理調停部３０の処理手順を示すフローチャートである。
【図３２】左イメージプレーン９と右イメージプレーン１０とを連結することで構成される連結イメージプレーンを示す。
【図３３】描画要求の切り抜きを伴う左右描画処理調停３０の処理のフローチャートである。
【図３４】描画要求と、左右同時描画要求とを示す。
【図３５】描画要求の変換を伴う左右描画処理調停部３０の処理のフローチャートである。
【発明を実施するための形態】
【００１５】
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。
図１は、記録媒体、再生装置の、使用行為についての形態の一例を示す図である。本図に示すように、記録媒体１００、再生装置２００は、リモコン３００、テレビ４００、シャッター眼鏡５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
【００１６】
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、テレビ４００と接続され、記録媒体１００を再生する。かかる再生は、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力を交互に繰り返すことでなされる。こうして再生される再生映像には、2D映像、3D映像が存在する。2D映像とは、例えば表示装置の表示画面を含む平面をX-Y平面として捉えて、このX-Y平面上に位置する表示画面の表示位置における画素にて表現される画像であり、平面視画像とも呼ばれる。
【００１７】
対照的に3D映像とは、上述のX-Y平面として捉えた平面と直交する直線を軸とし（本実施の形態ではX-Y平面に垂直な直線を軸（Z軸）として定義する）、表示装置の表示画面におけるX-Y平面上の画素に、本実施の形態で説明する構成を採用することにより、人の目には立体的に見えるようにした、または表示画面よりも手前または奥に見えるようにした映像である。
リモコン３００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン３００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
【００１８】
表示機器４００は、再生装置２００からの映像出力を受け取って、L画像とR画像とを同じタイミングでそのまま交互に出力する。タイミングの同一化は、映像出力と表示切り替えのフレームレートを同一とすることで実現される。視聴者の眼の負担を軽減するため、表示切り替え側のフレームレートのみを逓倍する構成をとることもできる。この場合は、L画像および続いて出力されたR画像のセットを表示ディスプレイ４００が蓄積し、表示ディスプレイ側でこれらの画像を高速に切り替えることで、高フレームレートの表示を行うこととなる。以降の説明においては、L画像、R画像の順番で出力された画像が表示ディスプレイ側でセットとして扱われることを前提として説明を行う。但し、逆順であっても同様の構成を取ることができる。
【００１９】
シャッター眼鏡５００は、液晶シャッターと、制御部とから構成され、ユーザの両目における視差を用いて立体視を実現する。シャッター眼鏡５００の液晶シャッターは、印加電圧を変えることにより、光の透過率が変化する性質を有する液晶レンズを用いたシャッターである。シャッター眼鏡５００の制御部は、再生装置から送られるR画像とL画像の出力の切り替えの同期信号を受け、この同期信号に従って、第１の状態、第２の状態の切り替えを行う。
【００２０】
第１の状態とは、右目に対応する液晶レンズが光を透過しないように印加電圧を調節し、左目に対応する液晶レンズが光を透過するように印加電圧を調節した状態であり、この状態において、左目にL画像が入射し、右目にはL画像が入射されない状態となる。
第２の状態とは、右目に対応する液晶レンズが光を透過するように印加電圧を調節し、左目に対応する液晶レンズが光を透過しないように印加電圧を調節した状態であり、この状態において、右目にR画像が入射し、左目にはR画像が入射されない状態となる。
【００２１】
一般にR画像と、L画像とは、その撮影位置の差に起因して、ライトビューから見える像とレフトビューから見える像には見え方に若干の差があるような画像である。
この像の見え方の差の程度を人間の左目／右目のそれぞれから見える像の差の程度（つまり、視差の程度）とすることにより、利用して人間の目から見える像を立体として認識できるのである。そこで、シャッター眼鏡５００が、以上のような第１の状態、第２の状態の切り替えを、R画像とL画像の出力の切り替えタイミングに同期させれば、ユーザは、平面的な表示が立体的に見えると錯覚する。次に、R画像、L画像を表示するにあたっての時間間隔について説明する。
【００２２】
具体的には、平面表示の画像において、R画像とL画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であれば足りる。本実施形態では、テレビ４００がビデオストリームを再生するための表示周期を示すフレーム期間を2つに分割して、分割により得られたそれぞれの期間を、右目、左目を切り替えるための時間間隔とする。フレーム期間を分割することで得られた期間のうち、左目で視聴させるための期間を”レフトビュー期間”という。また右目で視聴させるための期間を”ライトビュー期間”という。ここでフレーム周期が1/24秒であれば、レフトビュー期間、ライトビュー期間はそれぞれ、1/48秒となる。フレーム周期が1/60秒であれば、レフトビュー期間、ライトビュー期間はそれぞれ、1/120秒となる。
【００２３】
（第１実施形態）
以下、本願明細書の課題解決手段を具備した再生装置の実施形態のうち、イメージプレーンに、シングルバッファを用いた再生装置の実施形態について説明する。図２は、本願の課題解決手段を具備した再生装置の基本的な内部構成を示す。本図に示すように、再生装置２００は、読出部１０１、ビデオデコーダ１０２、プレーンメモリセット１０３（ビデオプレーン１０４a,１０４b、イメージプレーン１０４c,１０４dを含む）合成部１０５、イメージメモリ１０６、レンダリングエンジン１０７、プラットフォーム部１１０、ヒープメモリ１１１、バイトコードインタプリタ１１２、クラスローダ１１３、アプリケーションマネージャ１１４、ミドルウェア１１５から構成される。
【００２４】
読出部１０１は、記録媒体１００からビデオストリーム、描画イメージのデータ構造体、バイトコードアプリケーションのクラス構造体、アプリケーション管理テーブルを読み出し、ビデオストリームについてはビデオデコーダ１０２に供給する。
ビデオデコーダ１０２は、読み出されたビデオストリームを復号して非圧縮形式のピクチャをプレーンメモリセット１０３に書き込む。
【００２５】
プレーンメモリセット１０３は、複数のプレーンメモリから構成される。プレーンメモリとは、一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオ、字幕、GUI、背景画像のデコードによって得られた1画面分の画素データを格納する。
【００２６】
これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。このレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
【００２７】
左ビデオプレーン１０４aおよび右ビデオプレーン１０４bは、プレーンメモリセットの1つであり、それぞれ左眼用のビデオのピクチャ、右眼用のビデオのピクチャが格納される。
左イメージプレーン１０４cおよび右イメージプレーン１０４dは、プレーンメモリセットのうちの1つであり、ビデオプレーンの上の重畳させるべきイメージを非圧縮形式で格納する。左イメージプレーン１０４cは、左眼用のイメージデータを格納するレフトビュープレーンメモリである。右イメージプレーン１０４dは、右眼用のイメージデータを格納するライトビュープレーンメモリである。本実施形態において左イメージプレーン及び右イメージプレーンは、それぞれシングルバッファから構成されているので、各イメージプレーンに格納されている描画イメージであって、現在表示対象になっているものに、新たな描画イメージを上書きすることにより、各イメージプレーンの画面更新を行う。イメージプレーンにおける直前の表示対象である描画イメージに、新たな表示対象である描画イメージを直接上書きするので、上書き処理の途上においては、直前の表示対象である描画イメージと、新たな表示対象である描画イメージとが混在したようなティアリングが発生する。
【００２８】
合成部１０５は、複数のプレーンメモリのレイヤ合成を行う。
イメージメモリ１０６は、記録媒体１００に記録されたデータ構造体のインスタンスが生成された場合、データ構造のインスタンスであるイメージオブジェクトを格納しておくためのメモリである。かかるイメージオブジェクトは、RGB値のビットマップであり、バイトコードアプリケーションからはインスタンス変数によって指示される。3Dモードでは、右用のイメージオブジェクト、左目用のイメージオブジェクトを個別に格納することができる。
【００２９】
レンダリングエンジン１０７は、左イメージプレーン１０４cおよび右イメージプレーン１０４ｄに対する描画処理を行う。レンダリングエンジン１０７によるイメージ描画は、イメージメモリ１０６上のイメージオブジェクトを、イメージメモリ１０６からイメージプレーン１０４c,１０４dにコピーすることでなされる。コピーの対象になるイメージオブジェクトは、インスタンス変数で指示される。
【００３０】
プラットフォーム部１１０は、ROM等の不揮発性メモリに記憶された組込みプログラムと、この組込みプログラムを実行するハードウエア(MPU、レジスタ、周辺回路を含む)とから構成され、記録媒体１００に記録されたクラス構造体のインスタンスであるバイトコードアプリケーションを動作させる。ここでバイトコードアプリケーションとは、オブジェクト指向プログラミング言語を用いて記述されたクラス構造体をコンパイルすることで得られた実行形式のプログラムであり、機器に依存しないコード(バイトコード)によって記述されているものをいう。バイトコードアプリケーションとして典型的なものにはJava（登録商標）アプリケーションがある。
【００３１】
ヒープメモリ１１１は、バイトコードアプリケーションを構成するバイトコードやバイトコードアプリケーションが利用するシステムパラメータが配置されるスタック領域である。ヒープメモリ１１１上で動作するバイトコードアプリケーションによる描画は、１／３０秒、１／１５秒、１／５秒などのように、可変のフレームレートでなされる。このフレームレートは、ビデオ再生のフレームレートである１／２４秒、１／６０秒と整数倍にならないので、バイトコードアプリケーションは、再生装置のクロックを用いて、自身の描画タイミングに到来したかどうかを検知し、描画タイミングが到来すれば、書き込みを行う。
【００３２】
バイトコードインタプリタ１１２は、ヒープメモリ１１１に格納されているバイトコードアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
クラスローダ１１３は、記録媒体１００に記録されたアプリケーションのクラス構造体のインスタンスをヒープメモリ１１１に生成することにより、バイトコードアプリケーションのロードを行う。
【００３３】
アプリケーションマネージャ１１４は、アプリケーション管理テーブルに基づき、バイトコードアプリケーションの正当性を検証した上で、バイトコードアプリケーションを起動したりバイトコードアプリケーションを終了したりする等、バイトコードアプリケーションのアプリケーションシグナリングを行う。
ミドルウェア１１５は、プラットフォーム部で動作しているバイトコードアプリケーションに対して、各種機能を提供する組込み機器用のオペレーティングシステムである。機能提供は、ミドルウェアが実装しているパッケージのメンバー関数を呼び出すことでなされる。ミドルウェアが実装しているパッケージは、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等の描画処理を、レンダリングエンジン１０７を通じて左イメージプレーン１０４cおよび右イメージプレーン１０４dに対して行うライブラリを含む。そしてミドルウェア１１５は、このライブラリの機能によって、イメージ描画を実行する描画部を具備している。バイトコードアプリケーションはこれらの描画処理の要求を連続的に発行することで、様々なグラフィクス描画処理を実現することができる。かかるパッケージには、java.awtパッケージがあり、イメージ描画のアプリケーションプログラムインターフェイスは、このjava.awtパッケージのメソッドになる。他、java.awtパッケージにはない拡張メソッドも、イメージ描画のAPIとなる。イメージ描画の内容には、線や矩形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等があり、これらのイメージ描画は、描画内容の種別を示す情報によって識別される。
【００３４】
本実施形態では、バイトコードアプリケーションからの要求によるイメージ描画にあたって、ミドルウェアは、１画面分のイメージプレーンの描画イメージの書き込みに、ｎフレームに相当する実行サイクルを必要とすると仮定する。これは、バイトコードアプリケーションによってAPIがコールされてから、ミドルウェアがそのレスポンスを返すまでのターンアラウンド時間であり、プラットフォーム部−ミドルウェア−ハードウエア間のオーバーヘッドを含む。一般にJavaアプリケーションの実装において、ある画像を描画したくなったら、その場(例えばkフレーム)で描画命令を発行し、その発行から所定のフレームの遅延時間後に表示がなされることになる。この表示時における遅延時間について、Javaアプリケーションはケアしないことが一般的である。
【００３５】
そうすると、左イメージプレーン、右イメージプレーンの双方への描画イメージの書き込みのために、２×ｎフレームに相当する遅延時間が必ず発生することになる。例えば、任意のフレームｋにおいて、立体視のための描画イメージを表示させたい場合、フレームｋでStereoGraphics#drawImageメソッドを発行すれば、このフレームｋから”２×ｎフレーム”だけ遅れて、描画イメージが表示されることになる。
【００３６】
以下、これらの構成要素の処理内容を、参考図を交えてより更に詳しく説明する。
図３は、ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。
図中の矢印vw1は、レフトビュー期間における視点への映像入力を示し、図中の矢印vw2は、ライトビュー期間における視点への映像入力を示す。レフトビュー期間では、矢印vw1に示すように、レフトビュー期間では、左ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの左目に入射する。ライトビュー期間では、この矢印vw2に示すように、右ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの右目に入射する。
【００３７】
図４は、イメージプレーン１０４c,１０４dの内部構成を示す。解像度が1920×1080に設定されている場合、同図（ａ）に示すように、イメージプレーン１０４c,１０４dは横1920×縦1080の３２ビット長の記憶素子からなる。イメージプレーン１０４c,１０４dは、1920×1080の解像度で、1画素当たり３２ビットのR,G,B,α値を格納できるメモリアロケーションをもつ。記憶素子に記憶される３２ビットのR,G,B,α値は、８ビットのR値、８ビットのG値、８ビットのB値、８ビットの透明度αから構成される。１画面分のプレーンメモリの規模は、８Ｍバイトであり、左右のプレーンメモリの双方でダブルバッファを構成しようとすると、８Ｍバイト×４ものメモリ規模が必要になる。そしてダブルバッファでは、画面切り替え時にバッファからバッファへの転送が必要になり、この８Ｍバイトという規模のデータ転送が頻発するので、必要となるメモリ帯域が多大になる。このような事情から本実施形態では、イメージプレーンをシングルバッファによって構成している。
【００３８】
同図（ｂ）は、イメージプレーン１０４c,１０４dに格納されている画素データを示す。本図に示すように、イメージプレーン１０４c,１０４dに格納されているグラフィクスデータは、前景部分にあたる画素データ、背景部分にあたる画素データから構成される。ここで背景部分にあたる記憶素子には、透明色を示すα値が格納されており、この部分には、ビデオプレーンとの合成時において、イメージプレーンの字幕やビデオプレーンにおける動画像が透けて見えるようになる。一方、前景部分にあたる記憶素子には、透明色以外を示すR,G,B値が格納されており、この透明色以外のR,G,B値によって、描画イメージが描かれることになる。
【００３９】
合成部１０５によるプレーン合成時において、透明画素にあたる部分には、他のプレーンメモリの格納内容が透けて見えるようになり、かかる透明部分の存在によって、プレーン合成が可能になる。
図５は、プレーンオフセットの符号が正（レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす）である場合、像が表示画面よりも手前にあるように見える原理を説明するための図である。
【００４０】
本図において、丸で示したものは、表示画面上に表示される像である。まず、2Dモードである場合、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図５（ａ））。結果として表示される像は表示画面上に位置する。
レフトビュー期間において、左目に見える像はプレーンオフセットが０の場合に比べて右側の位置に見えるようシフトして表示する。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、プレーンオフセットが０の場合に比べて左側の位置に見えるようにシフトして表示する。このとき左目にはシャッター眼鏡５００により何も見えないようにする（図５（ｂ））。
【００４１】
人間は両目を用いて焦点をあわせてその焦点位置に像があるように認識する。従って、シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態とを交互に短い時間間隔で切り替えると、人間の両目は表示画面よりも手前の位置に焦点位置を、合わせようとし、結果として表示画面よりも手前に位置する焦点位置に像があるように錯覚を起こす（図５（ｃ））。
【００４２】
図６は、像が表示画面よりも奥にあるように見える原理を説明するための図である。
図６において、丸で示したものは、表示画面上に表示される像である。まず2Dモードにおいて、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図６（ａ））。結果として表示される像は表示画面上に位置する。
【００４３】
一方、レフトビュー期間において、左目に見える像はプレーンオフセットが０の場合に比べて左側の位置に見えるようにする。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、オフセットが０の場合に比べて右側の位置に見えるようにする、このとき左目にはシャッター眼鏡５００により何も見えないようにする（図６（ｂ））。
【００４４】
シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態と互に短い時間間隔で切り替えると、人間の両目は表示画面よりも奥の位置に焦点位置を、合わせようとし、結果として表示画面よりも奥の位置に像があるように錯覚を起こす（図６（ｃ））。
図７は、正と負のプレーンオフセットの見え方の違いの一例を示す図である。
【００４５】
本図（ａ）は、レフトビュー期間における描画イメージの書き込み位置を右方向へずらし、ライトビュー期間における描画イメージの書き込み位置を左方向へずらす場合を示す。図５に示したようにレフトビュー出力時の字幕がライトビュー出力時の字幕より右の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより手前にくるので、字幕も手前に見えるようになる。
【００４６】
本図（ｂ）は、レフトビュー期間における描画イメージの書き込み位置を左方向へずらし、ライトビュー期間における描画イメージの書き込み位置を右方向へずらす場合を示す。図６に示したように、レフトビュー出力時の字幕がライトビューの出力時の字幕より左の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより奥にゆくので、字幕も奥に見えるようになる。
【００４７】
図８は、描画イメージの書き込みに用いられるアプリケーションプログラムインターフェイスを示す。
同図（ａ）におけるjava.awt.Graphics#fillRectメソッドは、第１引数の位置で指定された矩形範囲を、第２引数で指定された色(正確にはjava.awt.Graphics#setColorメソッドで指定されたカレント色であるが、簡略化のため、以下では第２引数として説明を行う)で塗り潰す機能を呼び出すアプリケーションプログラムインターフェイスである。描画対象プレーンとしては、左イメージプレーン１０４cおよび右イメージプレーン１０４dの他に、BD-Jアプリが独自に生成した一時処理用の描画領域（BufferedImage）を対象とすることもできる。矩形範囲の位置は、描画先となる矩形領域の左上の座標（x１，y１）と右下の座標（x２，y２）の組み合わせで表現される。描画対象プレーンとしては、左イメージプレーン１０４cおよび右イメージプレーン１０４dの他に、BD-Jアプリが独自に生成した一時処理用の描画領域（BufferedImage）を対象とすることもできる。
【００４８】
同図（ｂ）におけるjava.awt.Graphics#drawImageメソッドは、第１引数の位置で指定された描画位置に、第２引数で指定された描画イメージを書き込む機能を呼び出すためのAPIである。正確には、指定された描画イメージを矩形にトリミングしてから描画するための、矩形位置を指定する引数を渡すことも可能であるが、ここでは省略する。
StereoGraphics#drawImageメソッドは、左イメージプレーンにおいて、第１引数の位置で指定された矩形範囲に、第２引数で指定された描画イメージを書き込み、右イメージプレーンにおいて、第３引数の位置で指定された矩形範囲に、第４引数で指定された描画イメージを書き込む機能を呼び出すAPIである。
【００４９】
矩形範囲は、描画先となる矩形領域の左上の座標（x１，y１）と右下の座標（x２，y２）の組み合わせで表現される。また、イメージオブジェクトとしては、JPEGやPNG形式のデータ構造から生成したインスタンス（ビットマップ画像）の他に、BufferedImageを用いることができる。
前述したようにjava.awt.Graphics#drawImageメソッドではイメージコピー処理が規定されているが、この処理では１つの矩形領域のコピーしか指定することができない。一方、StereoGraphics#drawImageメソッドによる左右同時イメージコピーは、描画位置と描画イメージとのペアを含む。描画先プレーンはそれぞれ左イメージプレーン１０４cと右イメージプレーン１０４dに固定されているものとし、イメージプレーンの指定は、StereoGraphics#drawImageメソッドの引数から除外されている。BD-ROM再生装置にStereoGraphics#drawImageメソッドを実装しようとする場合、StereoGraphics#drawImageメソッドによる左右同時イメージコピー処理はBD-Java規格上は存在しないため、例えばStereoGraphics#drawImageのような拡張メソッドを追加する必要がある。
【００５０】
図９は、図８のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。同図（ａ）は、APIの種別がjava.awt.Graphics#fillRectメソッドである場合、描画すべき矩形範囲、描画色が、具体的にどのようなものに設定できるかを表形式で示す。以降の説明において、APIで規定される描画要求の表記には、本図のものを用いる。java.awt.Graphics#fillRectメソッドの場合、描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、イメージプレーン座標系におけるXY座標で表現される。また、描画色は、(R=255,G=0,B=0)というRGB値によって表現される。
【００５１】
同図（ｂ）は、APIの種別がjava.awt.Graphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを表形式で示す。java.awt.Graphics#drawImageメソッドの場合、描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の”ビットマップイメージ１”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５２】
同図（ｃ）は、APIの種別がStereoGraphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを表形式で示す。APIの種別がStereoGraphics#drawImageメソッドである場合、左イメージプレーンにおける描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられる変数名を用いて表現される。本図の”ビットマップイメージ１”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５３】
右イメージプレーンにおける描画すべき矩形範囲は、(X3=55,Y3=100),(X4=255,Y4=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の”ビットマップイメージ２”とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
【００５４】
図１０は、図９（ｃ）のように引数が指定された場合、StereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。図中の手前側は、描画イメージを格納したイメージメモリを示す。図中の奥手側は、互いに重ね合わされた左イメージプレーン及び左ビデオプレーンの組み、右イメージプレーン及び右ビデオプレーンの組みを示す。この左イメージプレーン、右イメージプレーンに、図９で描画すべき矩形範囲として示した、具体的なXY座標をプロットしている。
【００５５】
本図によると、左右のイメージプレーンでは、X座標がわずかにずれているため、描画イメージがそれぞれ横方向に少しずれた位置にコピーされることになる。図中の矢印ig1,ig2は、左右イメージプレーンから左右のイメージプレーンへのコピーを示す。この場合はR画像の描画位置がL画像の描画位置よりも５ピクセル分右にずれているため、視聴者にはディスプレイの奥に引っ込んでいるような表示として感じられることになる。左右それぞれの視点向けに用意した異なるビットマップを指定しているので立体視としての効果は向上しているが、描画イメージとして同一のビットマップを用いることもできる。
【００５６】
図１１は、フレームi,j,kのそれぞれにおける、左右のビデオプレーン、左右のイメージプレーンの書き込み内容を示す。フレームiの書き込み内容は、1つのボタン部材であり、フレームjの書き込み内容は3つのボタン部材、フレームｋの書き込み内容は、字幕、音声、特典といった文字列が付加された3つのボタン部材である。
図１２は、フレームi,j,kにおけるイメージプレーンの書き込み内容が図１１のものである場合、どのようなエフェクトが再生されるかを示す。上述したような書き込みを行うことにより、フレームiにおいて1つのボタン部材が表示された後に、フレームjにおいて1つのボタン部材が3つに増え、フレームｋにおいて3つのボタン部材に文字列が付加されることでメニューが完成する様子が描かれる。
【００５７】
かかるイメージプレーンの書き込みにあたって、上から1ラインずつ、左右交互に描画することで、最悪でも左右同じ場所にティアリングが発生するようにする。
図１３は、左右のイメージプレーンへの書き込みがどのように行われるかを示す。第１段目は、バイトコードアプリケーションの動作の時間軸を示し、第２段目は左イメージメモリ、第３段目は右イメージメモリ、第４段目は左ビデオプレーン、第５段目は右ビデオプレーンを示す。フレームｋの直後であるフレームｋ＋１、フレームｋ＋２は、描画イメージの書き込みが行われるフレームである。図中のライン１、ライン２、ライン３〜ライン７０は、描画イメージを構成する各ラインの画素データが順次、イメージプレーンに書き込まれてゆく過程を示す。この書き込みは、左イメージプレーンへのライン１の書き込み、右イメージプレーンへのライン１の書き込み、左イメージプレーンへのライン２の書き込み、右イメージプレーンへのライン２の書き込みというように、ライン単位で交互になされていることがわかる。
【００５８】
ここでバイトコードアプリケーションによる左右のイメージプレーンへの書き込みに、２フレーム期間が必要であるものと仮定する。この場合、第１段目におけるバイトコードアプリケーションは、フレームｋにてStereoGraphics#drawImageを呼び出すと、2フレーム期間後のフレームｋ＋２に描画が完了することになる。
図１４は、StereoGraphics#drawImageを用いず、左イメージプレーン、右イメージプレーンのそれぞれに対して、個別に、書き込みを行う場合、表示内容がどのようになるかを示す。同図（ａ）は、左右イメージプレーンに対する書き込み進捗の違いを示す。左イメージプレーンへの書き込みを先に行ったため、左イメージプレーンでは、「字幕」「音声」「特典」のボタン部材が存在するが、右イメージプレーンへの書き込みは後であったので、右イメージプレーンには「字幕」のボタン部材しか存在しない。
【００５９】
上述したように、本実施形態ではイメージプレーンがシングルバッファで構成されており、イメージプレーン上のフレームjに表示されるべき描画イメージに、フレームｋに表示されるべき描画イメージを上書きすることにより、イメージプレーンの画面更新を行っている。よって本図では、左イメージプレーンにフレームjに表示されるべき描画イメージの一部が残存している(ハッチング部参照)。フレームjに表示されるべき描画イメージの残存部は、右イメージプレーンにのみ存在し、左イメージプレーンには存在しないため、かかる残存部において、左右両眼の間での不整合が発生する。
【００６０】
同図（ｂ）は、シャッター眼鏡５００を通じて、（ａ）のイメージプレーンを視聴した場合に視聴することができる立体視映像を示す。本図において「字幕」のボタン部材は、左右イメージプレーンに共通に存在するから、立体視効果により画面から手前に出現しているように見える。対照的に「音声」「特典」のボタン部材は、左右イメージプレーンに共通に存在しないので、立体視効果が得られないばかりか、左右の目で全く異なる映像が見えるという、現実にはあり得ない状況となる。このような左右両眼の間での映像の不整合は、ユーザに視覚的な不快感を与える。
【００６１】
図１５は、StereoGraphics#drawImageを用いて、左イメージプレーン、右イメージプレーンのそれぞれに対して、画素の書き込みをライン単位に交互に行う場合、表示内容がどのようになるかを示す。同図（ａ）は、左右イメージプレーンに対する書き込み進捗の違いを示す。左右イメージプレーンへのライン単位の書き込みを交互行うため、左右イメージプレーンにおける書き込みの進捗は同程度となる。
【００６２】
イメージプレーン上のフレームjに表示されるべき描画イメージに、フレームｋに表示されるべき描画イメージを上書きすることにより、イメージプレーンの画面更新を行っているので、本図でも、前図と同様、フレームｋに表示されるべき描画イメージの一部が残存している(ハッチング部参照)。
具体的にいうと、左右イメージプレーンには、それぞれ「字幕」「音声」のボタン部材しか存在しない。イメージプレーンの書込内容が未完成のまま表示に供されることでティアリングが発生する。しかしフレームｋに表示されるべき描画イメージの残存部は、右イメージプレーンにも、左イメージプレーンにも存在するため、かかる残存部で、左右の映像の不整合は発生しない。
【００６３】
同図（ｂ）は、シャッター眼鏡５００を通じて、（ａ）のイメージプレーンを視聴した場合に視聴することができる立体視映像を示す。本図において「字幕」「音声」のボタン部材は、左右イメージプレーンに共通に存在するから、立体視効果により画面から手前に出現しているように見える。左右のイメージプレーンに対する書き込みが未完であっても、左右のイメージプレーンの内容は大体同じものになる。また、左右の不整合が発生したとしても、その発生の程度は、ライン画素のレベルになるので、ユーザに視覚的な不快感を与えることはない。
【００６４】
StereoGraphics#drawImageを用いた描画処理を再生装置に実行させるため、どのようなプログラムを作成すべきかについて説明する。
図１６は、バイトコードアプリケーションによるメニュー表示のフローチャートである。ステップＳ１において、描画イメージを最初に表示すべきフレームを”フレームｔ”とし、ステップＳ２〜ステップＳ７のループに移行する。ステップＳ２〜ステップＳ７は、フレームｔに表示すべき左イメージのインスタンスを生成して、イメージ１とし(ステップＳ２)、フレームｔに表示すべき右イメージのインスタンスを生成して、イメージ２として(ステップＳ３)、フレームｔの始期が到来するのを待ち(ステップＳ４)、始期が到来すれば、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を特定する(ステップＳ５)。そして、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を引数で指定した上で、StereoGraphics#drawImageメソッドのコールを行い(ステップＳ６)、次にイメージを表示すべきフレームをフレームｔとする処理(ステップＳ７)を、繰り返すものである。
【００６５】
図１７は、StereoGraphics#drawImageメソッドがコールされた際のライン描画手順を示すフローチャートである。描画イメージの描画対象行を示す変数Yを「1」に初期化して(ステップＳ１１)、ステップＳ１２〜ステップＳ１４のループに移行する。このループでは、第２引数として指示される描画イメージのYライン目のRGB値を、左イメージプレーンの(x1,y1+Y-1)から、(x2,y1+Y-1）までに書き込み(ステップＳ１２)、第４引数のYライン目のRGB値を、右イメージプレーンの(x3,y3+Y-1)から(x4,y3+Y-1)までに書き込む(ステップＳ１３)という処理を、ステップＳ１４がYesと判定されるまで繰り返す。ステップＳ１４は、y1+Y-1がy2であり、尚且つ、y3+Y-1=y4という条件を満たすかどうかの判定であり、この条件を満たさない場合、ステップＳ１５において変数Yをインクリメントした上、ステップＳ１２に移行する。このループの繰り返しによって、左イメージプレーンにおける描画を行うべき矩形範囲にImage1を構成するライン画素が書き込まれてゆき、右イメージプレーンにおける描画を行うべき矩形範囲にImage2を構成するライン画素が書き込まれてゆく。
【００６６】
以上のように本実施形態によれば、アプリケーションプログラムインターフェイスの呼び出し時において、左目用のプレーンメモリへの書き込み指定と、右目用のプレーンメモリへの書き込み指定とのペアがバイトコードアプリケーションから引き渡されるので、右目用のプレーンメモリへの画素書き込みと、左目用プレーンメモリへの画素書き込みとを交互に行うような実装が可能になる。この場合、画素書き込みの途中で、表示を行うべきフレーム期間が到来したとしても、画素書き込みの進捗は、右目用と、左目用とで大体同じになる。たとえティアリングが生じたとしても、右目におけるティアリングと、左目におけるティアリングとは同一になるから、両目に映じる映像内容が一致しない左右の映像の不整合の発生は避けられる。
【００６７】
(第２実施形態)
本実施形態は、左イメージプレーン、右イメージプレーンのそれぞれに、ダブルバッファモデルを採用する実施形態である。図１８は、第２実施形態に係る再生装置のうち、改良が施された部分（イメージメモリ、イメージプレーン、レンダリングエンジン、合成部）のみを描く。
【００６８】
本図において、イメージメモリ１０５、レンダリングエンジン１０６、合成部１０７は、第１実施形態と同じであるが、イメージプレーン１０４c、１０４dが、左イメージプレーン１２１、右イメージプレーン１２２に置き換えられており、左イメージプレーン１２１、右イメージプレーン１２２と、合成部１１０との間に、スイッチ１２３、スイッチ１２４が存在する。
【００６９】
左イメージプレーン１２１は、2つのプレーンメモリから構成される。これらのうち、一方は左表示対象バッファとなり、他方は左描画対象バッファになる。左表示対象バッファは、合成部による合成の対象となるバッファである。左描画対象バッファは、バイトコードアプリケーションによる書き込みの対象になるバッファである。これらのバッファは何れも、１画面分の画素データ(ＲＧＢα値)を格納しうる容量をもつ。
【００７０】
右イメージプレーン１２２は、2つのプレーンメモリから構成される。これらのうち、一方は右表示対象バッファとなり、他方は右描画対象バッファになる。右表示対象バッファは、合成部による合成の対象となるバッファである。右描画対象バッファは、バイトコードアプリケーションによる書き込みの対象になるバッファである。これらのバッファは何れも、１画面分の画素データ(ＲＧＢα値)を格納しうる容量をもつ。
【００７１】
スイッチ１２３は、左イメージプレーン１２１を構成する2つのプレーンメモリのうち、表示対象バッファになっているものの画素内容を合成部１１０に出力する。
スイッチ１２４は、右イメージプレーン１２２を構成する2つのプレーンメモリのうち、表示対象バッファになっているものの画素内容を合成部１１０に出力する。
図１９は、スイッチ１２３、スイッチ１２４による切り替えを示す。同図（ａ）は、フレームｉに表示すべき描画イメージの出力状態を示す。同図（ａ）では、左イメージプレーン１２１、右イメージプレーン１２２のうち、上側のバッファが表示対象バッファになっており、フレームiの描画イメージが格納されている。そして下側のバッファが描画対象バッファに設定され、ここに次に表示すべきフレームjの描画イメージが書き込まれつつある。同図（ｂ）は、フレームjに表示されるべき描画イメージの書き込みが完了した状態を示す。下側のプレーンメモリに対する書き込みが完了したので、スイッチ１２３、スイッチ１２４を下側に切り替えることにより、フレームjの描画イメージを出力する。こうすることで、フレームjの描画イメージが表示に供される。
【００７２】
（ｃ）は、表示対象バッファから描画対象バッファへのコピーを示す。これにより左イメージプレーン１２１の内容は、何れもフレームjに表示されるべき描画イメージとなり、右イメージプレーン１２２の内容は、何れもフレームjに表示されるべき描画イメージになる。これにより、フレームの一部だけを描きかえてフレームｋの描画イメージを生成する場合にも、描きかえられない部分について前のフレームjと整合することが保証される。（ｄ）は、フレームｋに表示されるべき描画イメージが、上側のプレーンメモリに書き込まれている状態を示す。この上側のバッファへの書き込みが完了すると、スイッチ１２３、スイッチ１２４は上側に通され、上側のバッファが表示対象バッファになる。
【００７３】
図２０は、左右のイメージプレーンへの書き込みを完成させるために、どのような書き込みを行うべきかを示す。第１段目は、バイトコードアプリケーションの動作の時間軸を示し、第２段目は左描画対象バッファ、第３段目は右描画対象バッファ、第４段目は左ビデオプレーン、第５段目は右ビデオプレーンを示す。フレームｋの直後であるフレームｋ＋１は、右描画対象バッファへの書き込みが行われるフレーム、フレームｋ＋２は、左描画対象バッファへの書き込みが行われるフレームである。左右のイメージプレーンへの書き込みに2フレーム期間が必要である場合、バイトコードアプリケーションがフレームｋにてStereoGraphics#drawImageメソッドを呼び出すと、２フレームが経過した後のフレームｋ＋２で描画処理が完結する。そして、フレームｋ＋２の開始時点になれば、左描画対象バッファ、右描画対象バッファが左表示対象バッファ、右表示対象バッファに切り替えられて、新たな描画イメージが表示に供される。
【００７４】
図２１は、StereoGraphics#drawImageがコールされた際のダブルバッファを用いた描画手順を示す。本フローチャートでは、描画イメージの描画対象行を示す変数Yを「1」に初期化して(ステップＳ２１)、ステップＳ２２〜ステップＳ２４のループに移行する。このループでは、第２引数として指示される描画イメージのYライン目のRGB値を、左イメージプレーンの(x1,y1+Y-1)から、(x2,y1+Y-1）までに書き込む(ステップＳ２２)という処理を、ステップＳ２３がYesと判定されるまで繰り返す。ステップＳ２３は、y1+Y-1がy2という条件を満たすかどうかの判定であり、この条件を満たさない場合、ステップＳ２４において変数Yをインクリメントした上、ステップＳ２２に移行する。このループの繰り返しによって、左イメージプレーンにおける描画を行うべき矩形範囲にImage1を構成するライン画素が書き込まれてゆく。
【００７５】
その後、変数Yを1に初期化して(ステップＳ２５)、ステップＳ２６〜ステップＳ２８からなるループに移行する。このループでは、第４引数のYライン目のRGB値を、右イメージプレーンの(x3,y3+Y-1)から(x4,y3+Y-1)までに書き込む(ステップＳ２６)という処理を、ステップＳ２７がYesと判定されるまで繰り返す。ステップＳ２７は、y3+Y-1=y4という条件を満たすかどうかの判定であり、満たさない場合、ステップＳ２８において変数YをインクリメントしてステップＳ２６に戻る。以降、ステップＳ２６〜ステップＳ２８が繰り返されることにより、右イメージプレーンにおける描画を行うべき矩形範囲にImage2を構成するライン画素が書き込まれてゆく。ステップＳ２６〜ステップＳ２８のループを終了した後、ステップＳ２９において左描画対象バッファと、左表示対象バッファとの交替及び右描画対象バッファと右表示対象バッファとの交替を同時実行することにより、表示切り替えを行う。
【００７６】
以上のように本実施形態によれば、イメージプレーンにダブルバッファを採用することで、左右の映像の不整合の発生の回避が可能になる。
(第３実施形態)
本実施形態は、記録媒体におけるタイトルを生存区間としたアプリケーションシグナリングを再生装置に実行させて、このアプリケーションシグナリングの実行の際、イメージプレーンの規模を指定する改良に関する。
【００７７】
本実施形態では、記録媒体に以下のインデックステーブル、動作モードオブジェクトが記録されている。
インデックステーブルは記録媒体全体に関する管理情報であり、再生装置への記録媒体挿入後に、インデックステーブルが最初に読み出されることで、再生装置において記録媒体が一意に認識される。
【００７８】
インデックステーブルは、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、再生装置の動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。ここでプレイリストは、ビデオストリームを含むデジタルストリームに再生順序を規定することで特定される再生単位である。
【００７９】
ここで、タイトル番号レジスタにおけるタイトル番号は、０、１〜９９９、不定値(0xFFFF)という番号がある。タイトル番号０は、トップメニュータイトルのタイトル番号である。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値(0xFFFF)のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。
【００８０】
インデックステーブルは、各タイトル番号のそれぞれに対応したエントリー(インデックステーブルエントリー)を有し、個々のインデックステーブルエントリーに、動作モードを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。
再生装置においてタイトル番号レジスタの値は、記録媒体の装填後、不定値0xFFFF→１〜９９９→０というように変化する。このタイトル番号の変化は、記録媒体の装填時に、ファーストプレイタイトルの再生を開始し、ファーストプレイタイトルの再生後、１から999までのタイトル番号レジスタのタイトル番号で指示されるタイトルの再生を行い、タイトル番号で指示されるタイトルの再生が終了すれば、トップメニュータイトルを再生してユーザによる選択待ちを行うというものである。１〜９９９のタイトル番号をもつタイトルのうち、タイトル番号レジスタに格納されているタイトル番号と、同じタイトル番号をもつものが、現在の再生対象、つまりカレントタイトルになる。タイトル番号レジスタにどのような番号を設定するかは、トップメニュータイトルに対するユーザ操作や、プログラムによるタイトル番号レジスタの設定によって決定される。
【００８１】
以上がインデックステーブルについての説明である。続いて、動作モードオブジェクトの詳細について説明する。
動作モードオブジェクトは、プレイリストと、アプリケーションとの関連付けにより、タイトルを定義する情報である。図２２は、動作モードオブジェクトの内部構成の一例を示す図である。本図に示すように、動作モードオブジェクトは、「アプリケーション管理テーブル」、「端末管理テーブル」、「アプリケーションキャッシュ情報」、「プレイリストアクセス情報」、「キーインタレストテーブル」から構成される。
「アプリケーション管理テーブル」は、複数のエントリーを含む。引き出し線bj1は、アプリケーション管理テーブルにおけるエントリーをクローズアップして示している。この引き出し線に示すように、アプリケーション管理テーブルのエントリーは、タイトルにおいて、アプリケーションを自動的に起動させるべきか(AutoStart)、他のアプリケーションからの呼出しを待って起動すべきか(Present)という起動の仕方を示す「制御コード」と、JARファイルのファイル名となる５桁の数値を用いて、対象となるアプリケーションを示す「アプリケーションID」と、「アプリケーション詳細情報」を含む。引き出し線bj2は、「アプリケーション詳細情報」の内部構成をクローズアップして示している。本引出線に示すように、「アプリケーション詳細情報」は、アプリケーションがロードされる場合の「優先度」と、アプリケーションがタイトルアンバウンドであるか否か、ディスクバウンドであるか否かを示す「バインディング情報」と、アプリケーションの名称を示す文字列と、アプリケーションの言語属性を示す「言語コード」と、アプリケーションに対応づけるアイコンの所在を指し示す「アイコンロケータ」とを、アプリケーション毎にして格納している。
【００８２】
アプリケーション管理テーブルは、タイトルを生存区間として管理することで、各アプリケーションによるメモリリソースなどの消費を、タイトルという再生単位を区切りにて管理することができる。これによりたとえ、あるタイトルの再生中に複数のアプリケーションによるリソースの利用が競合して、デッドロック状態に陥ったとしても、ユーザによって別のタイトルが選択されれば、それらアプリケーションは全て終了させられるので、デッドロック状態は、強制的に解消することになる。また、あるタイトルの再生中に暴走したアプリケーションがメモリを占有したとしても、ユーザによって別のタイトルが選択されれば、そのアプリケーションは強制的に終了させられるので、メモリ容量の圧迫は、強制的に解消することになる。こうすることで不要なメモリリソースを消費しない、安定したメモリリソースの管理を実現することができる。安定したメモリリソースの管理を実現することができるので、メモリリソースの容量が限られた家電機器の実装において、より真価を発揮する。
【００８３】
「端末管理テーブル」は、動作中のアプリケーションが、欧州デジタル放送端末(DVB-MHP)が実現しているような、HAViインターフェイスによるGUIを表示する際の処理を規定する管理テーブルであり、GUI表示を実行するにあたってのコンフィグレーション情報や、GUIに用いるフォントデータ、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。このコンフィグレーション情報は、動作モードオブジェクト内のアプリケーション管理テーブルによって起動されるべきアプリケーションがグラフィクスを描画するにあたって、再生されるビデオストリームの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報である。引き出し線bj3は、端末管理テーブルの内部構成をクローズアップして示している。この引き出し線bj3に示すように、端末管理テーブルは、HD3D＿1920×1080、HD3D＿1280×720、HD＿1920×1080、HD＿1280×720、QHD＿960×540,SD,SD＿50HZ＿720×576,SD＿60HZ＿720×480の何れかに設定することができる。
【００８４】
「アプリケーションキャッシュ情報」は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、当該タイトルにおけるAV再生が開始されるまでに、どのアプリケーションを構成するファイルを、プラットフォーム内のキャッシュに読み込むべきかを示す情報であり、アプリケーション管理テーブルにより生存区間が規定されたアプリケーションに対応付けられたエントリーを含む。各エントリーは、アプリケーション管理テーブルにより生存区間が規定されたアプリケーションのそれぞれをプラットフォームにおけるキャッシュに読み込ませる旨を再生装置に指示する情報であり、各エントリーに付与された順位は、その順位がもっとも高いエントリーに対応するアプリケーションを最初にプラットフォームのキャッシュに読み込ませ、それ以降、順位が高い順に、残りのエントリーに対応するアプリケーションを、キャッシュフルになるまで、順次プラットフォームのキャッシュに読み込ませる旨を再生装置に指示する。こうすることで、低速な光ディスク媒体からバイトコードアプリケーションのクラスロードを行う場合でも、クラスロードが長くかかることによるスタートアップディレイを低減することができる。
【００８５】
「プレイリストアクセス情報」は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、自動的に再生されるべき自動再生プレイリストの指定を含む。また、プレイリストアクセス情報は、動作モードオブジェクトに対応するタイトルがカレントタイトルになった際、動作させることができるアプリケーションが選択できるプレイリストの指定を含む。引き出し線bj4は、自動再生プレイリストを指定する情報の内部構成をクローズアップして示している。引出線bj4に示すように、自動再生プレイリストを指定する情報として、3Dプレイリスト1920×1080、3Dプレイリスト1280×720、2Dプレイリスト1920×1080、2Dプレイリスト1280×720、2Dプレイリスト720×576、2Dプレイリスト720×480の指定が可能になる。
【００８６】
何れかのタイトルが選択された際、再生装置は、選択されたカレントタイトルに対応するもののプレイリストアクセス情報により指定されたプレイリストの再生を、アプリケーションからの再生指示を待つことなく開始し、プレイリスト再生の終了よりも、バイトコードアプリケーション実行が先に終了した場合、プレイリストの再生を継続して行う。
こうした先行再生により、アプリケーションのクラスロードに時間がかかり、描画イメージが表示されないため、対話画面がなかなか出力されないような場合、プレイリスト再生による再生映像がそのまま出力させるので、アプリケーションにおける起動遅延が顕著な場合でも、とりあえずプレイリストの再生映像をユーザに視聴させることができる。アプリケーションのスターティングディレィの間、何かが写っている状態にしておくことができるので、ユーザに安心感を与えることができる。
【００８７】
また終了が同時でないため、リソースの枯渇によってアプリケーションが異常終了し、アプリケーションのGUIが自動的に消去されたとしても、プレイリスト再生画面の表示をそのまま継続していれば、プレイリストの再生映像が、表示装置に出力される。かかる出力継続によって、たとえバイトコードアプリケーションが異常終了したとしても、表示装置は、とりあえず何かが写っているという状態になり、アプリケーションの異常終了によって、画面がブラックアウトするという事態を防ぐことができる。
【００８８】
「キーインタレストテーブル」は、再生キーエントリー、停止キーエントリー、早送りキーエントリー、巻戻しキーエントリー、上方向キーエントリー、下方向キーエントリー、右方向キーエントリー、左方向キーエントリーなど、再生装置におけるリモコンに備え付けられているそれぞれのキーについてのエントリから構成される。これらのキーエントリーは、対象となるキーが押下された際、キーイベントを発生させるか、発生させないかが設定される。ユーザ操作に応じてイベントが発生した場合、再生装置のイベントマネージャは、発生したイベントがキーインタレストテーブルに記載されているかどうかを判定する。そして記載されているなら、そのイベントをバイトコードアプリケーションに処理させるべく、キーイベントを出力する。
【００８９】
一方、発生したイベントがキーインタレストテーブルに記載されていない場合、再生装置のオペレーションマネージャは、そのイベントに対応するAV機能を再生制御エンジンに実行させる。こうすることで、バイトコードアプリケーションにイベントの対応漏れや、バグがあったとしても、オペレーションマネージャにより、再生制御エンジン部に対する再生制御が行われることになる。アプリケーションにバグがあったとしても違和感がない制御がなされることは、キーインタレストテーブル側から保証されているので、アプリケーションを開発するソフトハウスは、バグの発生等に躊躇することなく、他社にはない再生制御を実現することができる。
【００９０】
図２３は、タイトル切り替え時におけるプレーンメモリの解像度設定の処理手順の一例を示すフローチャートである。本フローチャートは、ステップＳ３１、ステップＳ３２、ステップＳ３３、ステップＳ３６の判定結果に応じて、ステップＳ３４、ステップＳ３５、ステップＳ３７の処理を選択的に実行する。
ステップＳ３１は、自動再生プレイリストが存在するかどうかの判定であり、ステップＳ３２は、直前の表示モードは3Dであるか否かの判定である。ステップＳ３３は、選択されたタイトルの自動再生プレイリストが、1920×1080の3Dプレイリスト又は1280×720の3Dプレイリストであるかどうかの判定である。
【００９１】
自動再生プレイリストが存在しない場合、ステップＳ３６において動作モードオブジェクトのデフォルト解像度がHD3D＿1920×1080、HD3D＿1280×720であるかどうかが判定され、もしYesであれば、ステップＳ３５において、表示モードを3Dに設定し、動作モードオブジェクトにおけるデフォルト解像度に応じて1920×1080、あるいは1280×720に設定する。もしNoであれば、ステップＳ３７において表示モードを2Dに設定し、解像度を動作モードオブジェクトにおけるデフォルト解像度に設定する。
【００９２】
自動再生プレイリストが存在しない場合、ステップＳ３２において直前の表示モードが2Dであるかどうか、又は、ステップＳ３３においてプレイリストが3Dプレイリストで、その解像度が1920×1080、1280×720であるがどうかを判定する。ステップＳ３２、ステップＳ３３のどちらかがNoであれば、ステップＳ３４において表示モードを2Dに設定し、解像度を、自動再生プレイリストの解像度に設定する。
【００９３】
ステップＳ３２がYes、ステップＳ３３もYesと判定された場合、ステップＳ３５において、表示モードを3Dに設定し、解像度を、自動再生プレイリストの解像度に応じて1920×1080、又は、1280×720に設定する。
本実施形態では、イメージプレーンを含むプレーンメモリのアクセスのため、バイトコードアプリケーションは、getCurrentConfigurationメソッド、getBestConfigurarionメソッド、setConfigurationメソッド、setCoherentConfigurarionメソッドを利用することができる。
【００９４】
getCurrentConfigurationは、プレーンメモリの表示設定をバイトコードアプリケーションに取得させるためのAPIである。
getBestConfigurationメソッドは、バイトコードアプリケーションに、再生装置における個々のプレーンの最善の設定情報を返す。
setConfigurationメソッドは引数に指定したプレーンに対する設定のみを変更するためのものである。
【００９５】
setCoherentConfigurationsメソッドは、複数のプレーンメモリに共通に設定される。例えば引数として解像度を指定し、setCoherentConfigurationsメソッドを呼出せば、個々のプレーンメモリの解像度を同一にすることができる。
よって、タイトル起動時に、動作モードオブジェクトの端末管理テーブル、又は、プレイリストアクセス情報にて設定されたイメージプレーンの解像度を、getCurrentConfigurationメソッドを用いて取得して取得した解像度を用いて左右のイメージプレーンに表示すべき描画イメージの描画発生を調整し、位置決めを行ってからStereoGraphics#drawImageメソッドを発行する。
【００９６】
または、getCurrentConfigurationメソッドを用いて取得した解像度が、描画イメージに適合した解像度であるか否かを判定して、描画イメージに適合した解像度であればそのままStereoGraphics#drawImageメソッドを発行する。
描画イメージに不適合な解像度であれば、setConfigurationメソッドを用いてイメージプレーンを適切な解像度に設定した上でStereoGraphics#drawImageメソッドをコールする。
【００９７】
バイトコードアプリケーションは、以上の過程で指定されたイメージプレーンの解像度を、アプリケーションプログラムインターフェイスを介して取得することができるので、StereoGraphics#drawImageメソッドの呼び出しにあたって、最適な矩形範囲の指定が可能になる。
以上のように本実施形態によれば、動作モードオブジェクトにおける端末管理テーブル、及び、プレイリスト管理テーブルにて指定されたイメージプレーンの座標系において、描画イメージを描画すべき矩形範囲を定めることができる。
【００９８】
（第４実施形態）
本実施形態は、これまでの実施形態の統合であり、記録媒体１００をBD-ROMとして構成し、再生装置２００をBD-ROM再生装置として構成する場合の形態である。
本実施の形態では、立体表示を行う対象映像は、BD-ROM記録媒体に記録されているものを再生して視聴することを前提にする。BD-ROM規格では、BD-ROM規格に準拠した形式でローカルストレージ内あるいは、リムーバブルメディアに記録されているデータを再生することも可能である。これらを含めて再生装置２００によって立体視映像表示が実施される形態を説明する。もちろん本実施例の変形としては、立体表示を行う対象映像は例えば放送波などの無線、ケーブルなどの有線、あるいは他の記録媒体を介して提供されていても構わない。
【００９９】
続いて再生装置２００が再生の対象としている、BD-ROM１００の内部構成について説明する。図２４は、BD-ROM１００の内部構成を示す図である。
本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。また、リードインの内側にはBCA（Burst Cutting Area）と呼ばれる領域があり、この領域から情報を読み出すことができることのできる主体は制限されているため、例えば著作権保護技術などに利用される。
【０１００】
本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもち、ボリューム領域には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、UDFやISO９６６０などのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっており、２５５文字のファイル名、ディレクトリ名を読み出すことが可能である。
【０１０１】
ディレクトリ構造を用いてBD-ROMの応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。この第１段目においてBD-ROMには、Rootディレクトリの下に、CERTIFICATEディレクトリ、及びBDMVディレクトリがある。
BDMVディレクトリはBD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリであり、BDMVディレクトリの配下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリ、METAディレクトリと呼ばれる６つのサブディレクトリが存在し、先の実施形態で述べたインデックステーブルを格納したファイルであるINDEX.BDMVと、DVDと互換がある制御を実現するプログラムを格納したMovieObject.bdmvの２種類のファイルが配置されている。
【０１０２】
STREAMディレクトリには、いわばトランスポートストリーム本体となるファイルを格納しているディレクトリであり、拡張子”m２ts”が付与されたファイル（00001.m2ts）が存在する。
PLAYLISTディレクトリには、拡張子”mpls”が付与されたファイル（00001.mpls）が存在する。
【０１０３】
CLIPINFディレクトリには、拡張子”clpi”が付与されたファイル（00001.clpi）が存在する。
BDJOディレクトリには、拡張子”bdjo”付与されたファイル（XXXXX.bdjo）が存在する。
JARディレクトリには、拡張子”jar”が付与されたファイル（YYYYY.jar）が存在する。
【０１０４】
METAディレクトリには、XMLファイル（ZZZZZ.xml）が存在する。
以下、これらのファイルについて説明する。
先ず初めに、拡張子”m２ts”が付与されたファイルについて説明する。拡張子”m２ts”が付与されたファイルは、MPEG-TS（TransportStream）形式のデジタルAVストリームを格納したストリームファイルであり、これまでの実施形態で説明したビデオストリーム、１つ以上のオーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム等を多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分をそれぞれ示している。
拡張子”mpls”が付与されたファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。”プレイリスト”とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの”型”を定義する。プレイリスト情報によって定義される再生経路は、いわゆる”マルチパス”である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。このマルチパスにおいて左目用のビデオストリームの再生経路を規定し、サブパスにおいて右目用のビデオストリームの再生経路を規定すれば、立体視を再生するためのビデオストリームの組合せを、好適に規定することができる。
【０１０５】
かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。再生制御のためのJava(TM)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(TM)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMF(JavaMedia Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。
拡張子”clpi”が付与されたファイルは、MPEG2形式のストリームファイルのそれぞれに１対１に対応するClip情報ファイルである。このClip情報ファイルを通じることにより、ストリームファイルは”AVClip”として管理されることになる。Clip情報は、AVClipにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すEP＿mapをもっているので、ストリームファイルのアクセスに先立ち、このクリップ情報をメモリにロードしておけば、アクセスしようとするストリームファイル中のトランスポートストリームがどのようなものであるのかを把握することができる。以上のClip情報及びPL情報は、”静的シナリオ”に分類される。
拡張子BDJOを付したファイルは、BD-Jオブジェクトを格納したファイルである。BD-Jオブジェクトとは、先の実施形態で述べた動作モードオブジェクトのことであり、BD-Javaアプリケーションを実行する際に使用される各種の情報を含んでいる。BD-ROM規格では、映像の再生中にアプリケーションプログラムを実行することによって、動的な再生制御や、再生中のユーザとのインタラクション等、映像の再生を行いながら任意の計算機処理を行わせることが可能である。BD-ROMではこのアプリケーションプラットフォーム規格としてJava（登録商標）が用いられており、BD-ROM規格上で採用されるJava（登録商標）プラットフォームは、BD-Java、あるいはBD-Jと呼ばれ、その実行アプリケーションはBD-Javaアプリ、あるいはBD-Jアプリと呼ばれる。
JARファイルは、BD-Jアプリケーションのクラス構造体のファイル(クラスファイル)を、デジタル証明書マニフェストファイル、ディスク署名シグネチャファイル、ディスク署名暗号鍵ファイル、パーミッションリクエストファイルとひとまとめにしてアーカイブしたファイルである。上述したようなアプリケーションキャッシュ情報によるキャッシュへのロードは、このJARファイルをひとまとめにしてなされる。
【０１０６】
以下、JARファイルにアーカイブされているデータ要素について説明する。
(i)クラス構造体のファイルにて定義されるBD-Jアプリケーションは、Xletインターフェイスを通じて、プラットフォーム内のアプリケーションマネージャにより、制御されるJava(TM)Xletである。Xletインターフェイスは、”loaded”,”paused”、”active”,”destroyed”といった4つの状態をもち、イベントドリブンつまり、イベントによって状態遷移を行うとともに制御を実行する。xletインターフェイスでは、アプリケーションの動作のトリガとなるキーイベントが予め登録される。このように、動作のトリガとなるキーイベントの登録は、イベントリスナによってなされる。
【０１０７】
(ii)デジタル証明書マニュフェストファイルは、デジタル証明書に対応するものであり、Java(TM)アーカイブファイルの属性、Java(TM)アーカイブファイル内のクラスファイルやデータファイルのハッシュ値が記載されているマニフェストファイルである。
(iii)ディスク署名シグネチャファイルは、マニフェストファイルのハッシュ値が記載されているシグネチャファイルである。
【０１０８】
(iv)ディスク署名暗号鍵ファイルは、「デジタル証明書チェーン」と、シグネチャファイルの「署名情報」とが記載されているファイルである。
「署名情報」は、署名処理をデジタル署名シグネチャファイルに施すことで得られる。これらの署名処理には、デジタル署名シグネチャファイル内のデジタル証明書チェーンにおける公開鍵に対応する秘密鍵が用いられる。
【０１０９】
「デジタル証明書チェーン」とは、一つ目の証明書（ルート証明書）が二つ目の証明書を署名し、また同じようにn番目の証明書がn+１番目の証明書を署名している形をもつ複数の証明書群である。デジタル証明書チェーンの最後の証明書を「リーフ証明書」と呼ぶ。この構成を利用することにより、ルート証明書から順番に次の証明書を保障していくことにより、デジタル証明書チェーンの最後の証明書までを保障することができる。
【０１１０】
(v)パーミッションリクエストファイルは、実行されるJava(TM)アプリケーションにどのパーミッションを与えるのかの情報を格納する。具体的に、クレデンシャル(デジタル信用証明書)、アプリ間通信の許可情報を含む。
”クレデンシャル”とは、ある組織に帰属する組織ディレクトリ内のファイルを共有化するための情報である。この共有化は、ある組織に属するアプリケーション用ファイルを利用する権限を、他の組織に属するアプリケーションに提供することでなされる。そのためクレデンシャルは、権限を提供する側の組織を示す提供者組織ID、権限を受領する側の組織の識別を示す受領者組織IDを含む。
【０１１１】
(vi)これらのファイル以外にも、PNGファイルが格納される。PNGファイルは描画イメージを定義するデータ構造体であり、本実施形態では、描画イメージを定義するデータ構造体をBD-Jアプリケーションのクラス構造体と共にJARファイルに格納して、ロードすることができる。
BD-Jアプリケーションを規定するクラスファイルは、以上のシグネチャファイル、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルとひとまとめにされて、ロードされるので、再生装置は、BD-Jアプリケーションを動作させるにあたって、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルを用いて、BD-Jアプリケーションを署名することができる。このように、マニフェストファイル、デジタル証明書チェーン、パーミッションリクエストファイルを用いて署名されたBD-Jアプリケーションを、”Signedアプリケーション”という。一方、署名がなされず、その権能の一部又は全部が制限されたBD-Jアプリケーションを”Un-Signedアプリケーション”という。以上の署名により、BD-Jアプリケーションの動作は、コンテンツの作りにとって不利にならないものに制限される。以上のパーミッションリクエストファイルを用いれば、StereoGraphics#drawImageメソッドによる描画やその他、立体視再生を実現するためのプレーンメモリへの書き込みを、ある特定の権限が付与されたBD-Jアプリケーションに限定することができる。
METAディレクトリに格納されたメタファイル（ZZZZZ.xml）には、ディスクに入っている映像作品に関する様々な情報が格納されている。メタファイルに格納されている情報としては、ディスクのディスク名及び画像、ディスクの作成主体者の名称の情報、各タイトルに関わるタイトル名等がある。
【０１１２】
以上がBDMVディレクトリの説明である。
CERTIFICATEディレクトリの下には、ディスクのルート証明書のファイル(app.discroot.cert)が存在する。
これはBD-Jアプリを実行する際に、アプリケーションが改竄されていないか、及びアプリケーションの身元確認を行なうプロセス（以下、署名検証という）に用いられるデジタル証明書の情報が含まれている。
【０１１３】
以上がBD-ROM１００についての説明である。メタファイルなど一部のファイルはBD-ROM規格では必ずしも必須とされておらず、一部のファイルが存在していなくともBD-ROM１００は映像記録媒体としてBD-ROM規格のもと再生可能である。
次に本実施形態に係る再生装置２００の詳細について説明する。
図２５は、第４実施形態に係る再生装置の内部構成を示すブロック図である。図２５に示すように、再生装置は、BDドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、左ビデオプレーン５、右ビデオプレーン６、イメージメモリ７、イメージデコーダ８、左イメージプレーン９、右イメージプレーン１０、静的シナリオメモリ１１、動的シナリオメモリ１２、制御部１３、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生制御エンジン１８、アプリデータ関連付けモジュール１９、プレーン合成部２０、UO探知モジュール２１、レンダリングエンジン２２、ネットワークインターフェース２３、ローカルストレージ２４、仮想ファイルシステム２５、オーディオデコーダ２６、リムーバブルメディア２７、次元判定部２８、次元モード記憶部２９、左右描画処理調停部３０から構成される。
【０１１４】
BDドライブ１は、BD-ROMのローディング/イジェクトを行い、BD-ROMに対するアクセスを実行する。
トラックバッファ２は、FIFOメモリであり、BD-ROMから読み出されたデジタルストリームを構成するソースパケットが先入れ先出し式に格納される。
デマルチプレクサ３は、仮想ファイルシステム２５を通じて、BDドライブ１にローディングされているBD-ROM、またはローカルストレージ２４上、またはリムーバブルメディア２７に保存されているトランスポートストリームの多重分離を行う。多重分離によって得られる、GOPを構成するビデオフレームは、ビデオデコーダ４に出力され、同じくGOPと同時に再生されるべきオーディオフレームはオーディオデコーダ２６に出力される。同じく多重分離によって得られるグラフィックストリームは、イメージメモリ７に格納され、同じく多重分離によって得られるシナリオ情報は動的シナリオメモリ１２に格納される。デマルチプレクサ３による多重分離は、TSパケットをPESパケットに変換するという変換処理を含む。また、デマルチプレクサ３は、次元判定部２８を用いて、立体視（3D）用の処理を行うか２D用の処理を行うかを切り替える。
【０１１５】
ビデオデコーダ４は、Multiview Video Coding（MVC）と呼ばれるMPEG-4 AVC/H.２６４の修正規格に準拠したデコーダであり、MPEG-4 AVCに基づき符号化された圧縮状態のビデオストリームを、映像の時間方向の類似性、視点間の類似性に基づき動き予測を行うことで、デコードする。
左ビデオプレーン５および右ビデオプレーン６は、ビデオデコーダ４のデコードによって得られた非圧縮形式のピクチャを格納するためのメモリであり、それぞれ左眼用のビデオのピクチャ、右眼用のビデオのピクチャが格納される。
【０１１６】
イメージメモリ７は、BD-J端末において仮想ファイルシステム２５から読み出されたグラフィックストリームや字幕データ、あるいは画像イメージ等のイメージデータを格納するバッファである。
イメージデコーダ８は、イメージメモリ７に格納されたグラフィックストリーム、あるいは字幕データ、あるいはイメージデータをデコードして左イメージプレーン９および右イメージプレーン１０に書き込む。
【０１１７】
左イメージプレーン９および右イメージプレーン１０は、BD-J端末においてGFXプレーンと呼ばれるプレーンメモリであり、それぞれ左眼用のイメージデータ、右眼用のイメージデータを非圧縮形式で格納する。BD-ROMにおいては、イメージプレーンに相当するものは複数用意されており、それぞれを独立させてビデオプレーンに重畳させることができる。具体的には、イメージデコーダ８から出力されたグラフィックストリーム・字幕データ・イメージデータや、レンダリングエンジン２２によって行われる描画処理の結果生成されるイメージデータ、さらに図には記載していないが背景（スチル）用プレーンが挙げられる。しかし本実施の形態の中では、説明を簡単にするためにイメージプレーンを１枚として説明するものとし、以降では特にレンダリングエンジン２２によって行われる描画処理を中心とした記載を行う。
【０１１８】
静的シナリオメモリ１１は、カレントプレイリストやカレントのストリーム管理情報を格納しておくためのメモリである。カレントプレイリストとは、仮想ファイルシステム２５から読み出すことのできるPLのうち、その時点での処理対象になっているものをいう。カレントストリーム管理情報とは、仮想ファイルシステム２５から読み出すことのできる複数ストリーム管理情報のうち、その時点での処理対象になっているものをいう。
【０１１９】
動的シナリオメモリ１２は、カレント動的シナリオを格納し、HDMVモジュール１４、BD-Jモジュール１５による処理に供されるメモリである。カレント動的シナリオとは、仮想ファイルシステム２５から読み出すことのできる複数シナリオ情報のうち、その時点での実行対象になっているものをいう。
制御部１３は、ROM、RAM、CPUからなるマイコンシステムであり、ROMには再生装置を制御するプログラムが記録されており、ROM内のプログラムがCPUに読み込まれ、プログラムとハードウエア資源とが協動することにより、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生制御エンジン１８、アプリデータ関連付けモジュール１９、左右描画処理調停部３０の機能を実現する。
【０１２０】
HDMVモジュール１４は、DVD映像仮想プレーヤである。HDMV（High Definition Movie Mode）とは、DVDとの親和性のある映像再生形式である。
BD-Jモジュール１５は、第１実施形態に示したプラットフォーム部の構成要素のうち、ヒープメモリ１１１、バイトコードインタプリタ１１２、クラスローダ１１３、アプリケーションマネージャ１１４によって構成される部分に対応する機能モジュールであり、BD-Jアプリを実行する。
【０１２１】
モード管理モジュール１６は、仮想ファイルシステム２５から読み出されたモード管理テーブルを保持して、モード管理及び分岐制御を行う。モード管理モジュール１６によるモード管理とは、動的シナリオをどのHDMVモジュール１４、BD-Jモジュール１５に実行させるかという、モジュールを割り当てる処理を実施する。
ディスパッチャ１７は、UO検知モジュール２１により受け取ったユーザの操作（ユーザオペレーション、以下UOとも記す）から、現在の再生装置におけるモードに適切なUOのみを選んで、そのモードを実行するモジュールに渡す。例えばHDMVモードの実行中に、上下左右、アクティベートといったUOを受け付けた場合、HDMVモードのモジュールにこれらのUOを出力するのがディスパッチャ１７の処理である。
【０１２２】
AV再生制御エンジン１８は、HDMVモジュール１４、あるいはBD-Jモジュール１５からの呼び出しに応じて、AV再生機能、プレイリストの再生機能を実行する。AV再生機能とはBD-ROMにて定義されている、DVDプレーヤ、CDプレーヤから踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、副映像切り替え、アングル切り替えといった処理である。プレイリスト再生機能とは、このAV再生機能のうち、再生開始や再生停止をプレイリスト情報に従って行う。
【０１２３】
アプリデータ関連付けモジュール１９は、仮想ファイルシステム２５から読み出される情報と、機器内で計算した結果、及びアプリケーションが設定する属性情報を元に、アプリケーション関連付け情報を生成、及び更新する機能を有している。
UO検知モジュール２１は、装置の視聴者が再生装置に対して入力を実施したユーザの操作（UO）を受け取る。これは例えばリモコン・コントローラのような遠隔機器で入力されるものである場合もあるし、機器に対して設置されるボタンのようなインタフェースによって直接入力されるものである場合もある。
【０１２４】
プレーン合成部２０は、左ビデオプレーン５または右ビデオプレーン６に格納されている非圧縮形式のビデオのピクチャデータと、左イメージプレーン９または右イメージプレーン１０に格納されているイメージデータとの合成処理を行い、結果を映像として出力する。またプレーン合成部２０は、１プレーン分の合成処理が完了した時点で、左右どちらのプレーンを対象とする合成処理が完了したかを通知する合成処理完了通知を、左右描画処理調停部３０に対して行う。
【０１２５】
レンダリングエンジン２２は、左イメージプレーン９および右イメージプレーン１０に対する描画処理を行う。BD-Jモジュール１５は、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等の描画処理を、レンダリングエンジン２２を通じて左イメージプレーン９および右イメージプレーン１０に対して行うライブラリを有しており、BD-Jアプリはこれらの描画処理の要求を連続的に発行することで、様々なグラフィクス描画処理を実現することができる。
【０１２６】
ネットワークインターフェース２３は、インターネット上に公開されたBD-ROM追加コンテンツのダウンロードに用いられる。BD-ROM追加コンテンツとは、オリジナルのBD-ROMにないコンテンツで、例えば追加の副音声、字幕、特典映像、アプリケーションなどである。BD-Jモジュール１５からネットワークインターフェース２３を制御することができ、インターネット上に公開された追加コンテンツをローカルストレージ２４やリムーバブルメディア２７にダウンロードすることができる。
【０１２７】
ローカルストレージ２４は、再生装置に内蔵されているハードディスク等の磁気記録装置である。BD-ROM１００に記録されているファイル形式またはそれに準ずる形で、トランスポートストリームや再生に使用する各種のデータを記録する。
仮想ファイルシステム２５は、BD-ROM１００あるいは、ローカルストレージ２４あるいは、リムーバブルメディア２７に記録されているファイルに対するリード・ライト機構を提供するファイルシステムである。
【０１２８】
BD-ROMの再生時に必要とされるファイルアクセスは、通常BD-ROM１００に対して行われるが、仮想ファイルシステム２５はローカルストレージ２４あるいはリムーバブルメディア２７に存在するファイルを、あたかもBD-ROM１００上に記録されているファイルであるかのように仮想的にファイルのアドレス変換を行う機構を備える。すなわち本仮想ファイルシステム２５はファイルの物理的な記録先を抽象化する機構を提供する。
【０１２９】
オーディオデコーダ２６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。
リムーバブルメディア２７は再生装置に装着された外部スロットから挿入される記憶媒体である。記憶媒体の種類は典型的にはSDカードなどのフラッシュメディアが利用されるが、USBメモリ、リムーバブルハードディスク、その他任意の種類の記憶媒体であってもよい。
【０１３０】
次元判定部２８は、再生対象の映像が、立体視（3D）用のものであるか、２D用のものであるかを判定し、その結果を次元モード記憶部２９に出力する。判定は、カレントプレイリストあるいはカレントストリームの中に、立体視（3D）に対応する映像か対応しない映像かのフラグが含まれている場合には、これを使用することにしてもよいし、あるいは再生装置を鑑賞するユーザの指定によって切り替えが行われるようになっていてもよい。
【０１３１】
次元モード記憶部２９は、その時点で再生されている映像が、立体視（3D）用のものであるか、通常の２D用のものであるかを記憶する。
左右描画処理調停部３０は、ミドルウェア１１５の構成要素であり、BD-Jモジュール１５から連続的に発行される描画要求の中から左イメージプレーン９への描画要求と右イメージプレーン１０への描画要求のセットを抽出する。立体視のグラフィックスを描画する典型的なBD-Jアプリでは、ある一つの描画対象オブジェクトについて、左眼視点から見た形状を左イメージプレーン９に描画し、右眼視点から見た形状を右イメージプレーン１０に描画するというセットの処理を連続して行うことが多いと想定される。そこで、これらセットを成す描画処理に対応している描画要求の対を抽出し、プレーン合成部２０が左眼と右眼の視覚の不整合を生じさせるような映像を出力しないように、レンダリングエンジン２２の描画処理のタイミングおよび描画順序を制御することで、立体視映像のちらつきを抑制することが可能となる。
【０１３２】
描画要求のセットの抽出およびレンダンリングエンジン２２の描画処理の制御に関する具体的な方法については後述する。
本実施の形態では以下、プレイリスト中に3D用か２D用かを識別する次元識別フラグを有しているものとして説明する。
先ず、本再生装置がどのようにして3D映像を作り出すかを図２５に示される構成図をもとに説明する。BD-ROM上に配置されたストリームは、右眼用ストリームと左眼用ストリームを別々に記録していても良いし、一つのストリームファイルに規則を持って埋め込んでおいても良いが、本実施の形態においては、予め一つのストリームファイルに右眼用ストリームと左眼用ストリームが埋め込まれていることを前提に記載する。
【０１３３】
デマルチプレクサ３はストリームのヘッダ情報から左眼用ストリームと右眼用ストリームの振り分けを行う。
本実施の形態における再生装置２００は、一組のビデオデコーダと左眼用のビデオプレーンである左ビデオプレーン５と右眼用のビデオプレーンである右ビデオプレーン６を持ち、立体視映像を出力する際にはこのビデオデコーダが左眼用の映像と右眼用の映像の処理を交互に行い、それぞれ左ビデオプレーン５と右ビデオプレーン６に交互に出力する。
【０１３４】
再生装置２００に対して再生指示が行われると、図２６に示した処理が開始される。この再生指示自体は、ユーザの再生時の指定（例えば再生ボタンの押下）に従って行われる場合、BD-ROM１００の再生装置への挿入によって自動的に行われる場合、その他BD-Jモジュールを含む、何らかの装置内の設定によって自動的に行われる場合等、指示の開始はさまざまなケースが考えられる。本実施の形態では、任意の形式によって開始されたものと考えてよい。
【０１３５】
図２６は、左右プレーンの交互出力を実現する場合のフレーム処理の処理手順を示すフローチャートである。フレーム処理とは、映像信号のフレーム期間において、ビデオプレーンやイメージプレーンからデータを読み出し、重畳して出力するという処理である。つまり、ミドルウェアからイメージプレーンへの描画イメージの書き込みについては、第１実施形態から第３実施形態までで説明を終えているので、本実施形態ではイメージプレーン及びビデオプレーンから合成部へのデータ読み出しを中心にして説明を行う。
【０１３６】
ステップＳ４０１において、仮想ファイルシステム２５から読み出される１つ以上のプレイリスト、複数ストリームの中から、再生処理対象として指定されたプレイリストとトランスポートストリームを抽出し、カレントプレイリスト（PL）情報とカレントストリーム管理情報に設定する。
またデマルチプレクサ３は静的シナリオメモリ１１のカレントプレイリスト情報を参照し、処理対象となるトランスポートストリームを取得する。
【０１３７】
ステップＳ４０２においては、デマルチプレクサ３は静的シナリオメモリ１１のカレントプレイリスト情報から次元識別フラグを取得し、次元判定部２８に引き渡し、再生対象のストリームが２D用か3D立体視用かの判定結果を得る。
判定結果が２Dであった場合は、２Dの映像出力処理を行う。この場合、そもそもL画像とR画像は同一の画像であるか、もし別々の映像が存在していたとしても、どちらかの映像が破棄され表示されず、その結果従来のBD-ROM再生と同様の処理となる。一例として、２Dの映像出力が常に左ビデオプレーン５に出力され、イメージデコーダ８やレンダリングエンジン２２は常に左イメージプレーン９にのみイメージデータを出力し、プレーン合成部２０は常に左ビデオプレーン５と左イメージプレーン９の合成のみを行う構成が挙げられる。
【０１３８】
ステップＳ４０２の判定が3Dであった場合は、3D映像の再生を開始する。
本実施の形態では、再生装置２００は、プレーン合成部２０を通して、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力とを交互に繰り返すものとする。
さて、3D映像の再生が開始されると、再生装置２００はステップＳ４０３L以降の処理に従って、左右の出力映像を生成する。L画像の生成処理は、ステップＳ４０３L、ステップＳ４０４L、ステップＳ４０５L、ステップＳ４０６Lに相当し、R画像の生成処理は、ステップＳ４０３、ステップＳ４０４R、ステップＳ４０５R、ステップＳ４０６Rに相当する。
【０１３９】
ステップＳ４０３Lの処理は、処理対象となるトランスポートストリームから、ビデオデコーダにより、左眼用のビデオピクチャを取り出し、左ビデオプレーン５に出力する。
続いてステップＳ４０４LおよびステップＳ４０５Lにおいて、プレーン合成部２０は、左ビデオプレーン５のビデオピクチャと左イメージプレーン９のイメージデータについて、プレーン全体にわたって合成する処理を行う。
【０１４０】
ここでは、左ビデオプレーン５と左イメージプレーン９の解像度が同じで、いずれも幅Wピクセル、高さHピクセルであるものとする。この場合、合成の処理は１番上の行（y=０）から１番下の行（y=H-１）の方向に向かって順番に、左ビデオプレーン５のy行目のラインデータの上に左イメージプレーン９のy行目のラインデータを重畳して、L画像のy行目が生成され、最終的な映像出力として出力される。
【０１４１】
プレーン全体に対して合成処理が完了すると、プレーン合成部２０はステップＳ４０６Lの処理にて、L画像の合成処理が完了したという合成処理完了通知を、左右描画処理調停部３０に対して行う。
続いて、ステップＳ４０３R、ステップＳ４０４R、ステップＳ４０５R、ステップＳ４０６Rの各処理により、R画像の生成が行われるが、これらの処理はそれぞれ、ステップＳ４０３L、ステップＳ４０４L、ステップＳ４０５L、ステップＳ４０６Lと同様のものであるため、ここでは説明を省略する。
【０１４２】
以上が、本実施の形態におけるL画像とR画像の生成および出力である。
この構成においては、左イメージプレーン９のイメージデータ、続いて右イメージプレーン１０の画像が、交互にプレーン合成部２０に送られることとなる。
そのため、例えば左イメージプレーン９のイメージデータが全て送られたステップＳ４０６Lのタイミングで、レンダリングエンジン２２が左イメージプレーン９および右イメージプレーン１０の画像を書き換えたものとする。この場合、その後にステップＳ４０３Rが実行されることにより、プレーン合成部に送られるR画像は、書き換え後の右イメージプレーン１０の格納内容となる。
【０１４３】
一方、プレーン合成部に送られたL画像は、既に送られた書き換え前の画像であるから、結果として出力されるL画像とR画像は、R画像だけが書き換えを反映した不整合なものとなってしまう。
そこで、本実施の形態においては、左右描画処理調停部３０が図２７に示したフローチャートの処理によってレンダリングエンジン２２の処理タイミングを調整する。
【０１４４】
図２７は、描画要求の発行タイミングの調整を伴う場合の左右描画処理調停部３０の処理手順を示すフローチャートである。
左右描画処理調停部３０は、まずステップＳ５０１により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。ステップＳ５０２において、ステップＳ５０１で受け取った描画要求の種別情報が、第１実施形態で説明した「左右同時イメージコピー」であるか否かを判定する。
【０１４５】
描画要求の種別が「左右同時イメージコピー」でなかった場合には、ステップＳ５０３の処理にて、レンダリングエンジン２２に対して描画要求をそのまま発行する。これは従来のBD-Jモジュール１５と同様の処理になるため、説明は省略する。
描画要求の種別が「左右同時イメージコピー」だった場合は、ステップＳ５０４L以降の処理に移る。「左右同時イメージコピー」の描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、これら２つのイメージコピー処理の結果は、プレーン合成部２０において確実に同一フレームの映像出力として処理される必要があり、さもなくば左右の表示の不整合を引き起こすこととなる。
【０１４６】
そこで、まずステップＳ５０４Lの処理にて、プレーン合成部２０からL画像の合成完了通知（図２６のステップＳ４０６Lにて発行されたもの）が来るのを待ってから、ステップＳ５０５Lの処理にてレンダリングエンジン２２に対して左イメージプレーン９に関連するイメージコピー処理の描画要求を発行する。これらの処理により、イメージコピー処理が十分高速なハードウエア（具体的には、プレーン合成部２０がR画像の合成を行っている約０．５フレーム期間内にイメージコピーが完了する場合）においては、「左右同時イメージコピー」のうち左イメージプレーン９に対するイメージコピーの結果は、次のフレーム期間において、映像出力に反映されることを保証することができる。
【０１４７】
続いてR画像についても同様に、ステップＳ５０４Rの処理にて、プレーン合成部２０からR画像の合成完了通知（図２６のステップＳ４０６Rにて発行されたもの）が来るのを待ってから、ステップＳ５０５Rの処理にてレンダリングエンジン２２に対して右イメージプレーン１０に関連するイメージコピー処理の描画要求を発行する。これらの処理により、「左右同時イメージコピー」のうち右イメージプレーン１０に対するイメージコピーの結果は、図２６においては次のフレームにおいて、映像出力に反映されることを保証することができる。
【０１４８】
以上の処理により、「左右同時イメージコピー」を構成する２つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力に反映されるため、L画像とR画像の表示不整合に伴うちらつきを抑止することが可能となる。
また、本実施の形態においては、ステップＳ５０４LおよびステップＳ５０４Rにて合成処理完了通知を待つ。尚、「左右同時イメージコピー」は１フレームあたり1回に制約されることになるが、複数の描画要求を組み合わせて１フレームの描画を構成する必要がある場合には、まず前述のBufferedImage上に描画結果を生成しておき、最後に１回の「左右同時イメージコピー」で左右のイメージプレーンにコピーを行う実装とすればよい。これは、従来のBD-Jアプリにおいても、ちらつき防止のために頻繁に用いられている手法である。
【０１４９】
また、「左右同時イメージコピー」のみをステップＳ５０４L以降の処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「左右同時矩形塗り潰し」等を新たに導入し、ステップＳ５０４L以降の処理対象としてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１５０】
更に3D→2D切り替え時の強制コピーを実行してもよい。即ち、ステップＳ４０２の判定が２Dであった場合は、前述の通り、例えば、2Dモードの映像出力は常に左ビデオプレーン５に出力され、レンダリングエンジン２２は常に左イメージプレーン９にのみ描画を行い、プレーン合成部２０は常に左ビデオプレーン５と左イメージプレーン９の合成のみを行うことになる。
【０１５１】
ここで、２Dのストリームの再生が一旦終了し、続いて3Dのストリームの再生が開始される場合を考える。２Dのストリームの再生中は、BD-Jアプリも2D描画のアプリとして動作するため、左イメージプレーン９に対してのみ描画を行い、右イメージプレーンには何も描画を行わず、例えば全面黒色のままとなっている。ところが、この状態のままで3Dのストリームの再生に切り替わると、プレーン合成部２０はステップＳ４０４R、ステップＳ４０５Rの処理にて、何も描画がなされていない右イメージプレーン１０の画像を出力してしまう。3Dストリームに切り替わると、BD-Jアプリも3D描画のアプリとして動作を開始することが期待されるが、これらの切り替わりのタイミングにタイムラグが存在すると、一瞬R画像のみ全面黒色の出力がなされるため、ちらつきが発生してしまう。
【０１５２】
このようなちらつきを回避するには、プレーン合成部２０の動作が２Dから3Dに切り替わるタイミングで、左イメージプレーン９の内容を右イメージプレーン１０に強制的にコピーするようにすればよい。
ストリームが２Dから3Dに切り替わる場合だけではなく、例えばBD-Jモジュールの動作モードのみを２Dから3Dに切り替える機能が存在する場合についても、切り替えのタイミングで同様のコピーを行うようにすることで、BD-Jアプリの実装如何に関わらず、同種のちらつきを防止することができる。
【０１５３】
さらに、BD-Jモジュールが左イメージプレーン９のみを用いて3D描画を行う1plane＋Offsetモードに対応している場合、コピー処理とシフト処理とを実行することで、左右の不整合を解消することができる。
1plane＋Offsetモードとは、左イメージプレーン９全体をL画像としては左にnピクセル分、R画像としては右にnピクセル分シフトして出力することで、プレーン全体を手前あるいは奥まって表示させるモードである。かかる1plane＋Offsetモードにおいて、左イメージプレーン９全体が右にnピクセル分シフトされた後に、シフト後の画像を右イメージプレーン１０にコピーする。その後、左イメージプレーン９全体を左にnピクセル分シフトさせれば、描画モードの遷移前と遷移後のL画像およびR画像の出力が一致するため、ちらつきを抑止することが可能となる。
【０１５４】
この1plane＋Offsetモードから左右両方のイメージプレーンを使用する3D描画モードに遷移する場合においても、かかるシフト及びコピー処理を適用することができる。
以上が、本発明にかかる立体視ビデオ再生方式の実施形態である。
（第５実施形態）
本実施形態では、プレーン合成部２０および左右描画処理調停部３０の別の実施形態について説明する。
【０１５５】
プレーン合成部２０、左右描画処理調停部３０以外の構成要素については第４実施形態と同様であるためここでは説明を省略し、異なる部分についてのみ説明を行う。
図２８は、ラインの交互出力を実現する場合の、フレーム処理を示すフローチャートである。
ステップＳ７０１およびステップＳ７０２は、それぞれ図２６のステップＳ４０１、ステップＳ４０２と同様であり、ステップＳ７０２の判定結果が3Dであった場合は、3D映像の再生を開始する。
【０１５６】
3D映像の再生が開始されると、再生装置２００はステップＳ７０３L以降の処理に従って、左右の出力映像を生成する。まず、ステップＳ７０３LおよびステップＳ７０３Rの処理により、処理対象となるトランスポートストリームから、ビデオデコーダにより、左眼用のビデオピクチャおよび右眼用のビデオピクチャを取り出し、それぞれ左ビデオプレーン５、右ビデオプレーン６に出力する。
【０１５７】
続いてステップＳ７０４のループ処理で、プレーン合成部２０は、左右のプレーン全体にわたって合成する処理を行う。
ここでは、左右のビデオプレーンと左右のイメージプレーンの解像度が同じで、いずれも幅Wピクセル、高さHピクセルであるものとする。この場合、合成の処理は１番上の行（y=０）から１番下の行（y=H-１）の方向に向かって１ラインずつ順番に行われる。
１ライン毎の処理としては、まずステップＳ７０５Lにおいて、左ビデオプレーン５のy行目の映像の上に左イメージプレーン９のy行目の映像を重畳して、出力L画像のy行目が生成され、最終的な映像出力として出力する。
【０１５８】
続いて、ステップＳ７０５Rにおいて、右ビデオプレーン６のy行目の映像の上に右イメージプレーン１０のy行目の映像を重畳して、出力R画像のy行目が生成され、最終的な映像出力として出力する。ここでは上から順番に１ラインずつ処理する構成をとったが、下から上への順番など、他の順番に処理を行ってもよい。また、ビデオプレーンとイメージプレーンの解像度を同一としたが、これらの解像度が異なる構成をとってもよい。
【０１５９】
プレーン全体に対して合成処理が完了すると、プレーン合成部２０はステップＳ７０６の処理にて、L画像とR画像の両方の合成処理が完了したという合成処理完了通知を、左右描画処理調停部３０に対して行う。
以上が、本実施の形態において立体視映像を映し出す際の処理の流れである。
この構成においては、左イメージプレーン９のイメージデータ、続いて右イメージプレーン１０の画像が１ラインずつ交互に、すなわち１フレームとして見れば両画像が並行でプレーン合成部２０に送られることとなる。
【０１６０】
そのため、例えばBD-Jアプリがある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をこの順番で描画しようとした場合、レンダリングエンジン２２は、まず左イメージプレーン９の画像を書き換える。しかし、このタイミングで、左右イメージ出力が実行されると、生成されるL画像については左イメージプレーン９の書き換えを反映したものになるが、R画像についてはまだ右イメージプレーン１０は書き換え前であるため、結果として出力されるL画像とR画像は、L画像だけが書き換えを反映した不整合なものとなってしまう。
【０１６１】
そこで、本実施の形態においては、左右描画処理調停部３０が図２９に示したフローチャートの処理によってレンダリングエンジン２２の処理順序を制御することで、前述のような不整合な表示の回避を行う。図２９は、描画要求の統合を伴う左右描画処理調停部３０の処理手順を示すフローチャートである。
まずステップＳ８０１により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求Aが発行されるのを待つ。発行される描画要求は、先の実施の形態と同様の構造で表現される。
【０１６２】
次にステップＳ８０２において、ステップＳ８０１で受け取った描画要求Aの種別情報が「イメージコピー」で、かつ描画対象プレーンが左イメージプレーン９であるか否かを判定する。
ステップＳ８０２の条件を満たさなかった場合は、ステップＳ８０３の処理にて、レンダリングエンジン２２に対して描画要求Aをそのまま発行する。これは従来のBD-Jモジュール１５と同様の処理になるため、説明は省略する。
【０１６３】
ステップＳ８０２の条件を満たした場合、描画要求Aの処理はこのタイミングでは行わずに保留しておき、次のステップＳ８０４において、BD-Jモジュール１５からの次の描画要求Bが発行されるのを待つ。
次にステップＳ８０５において、ステップＳ８０４で受け取った描画要求Bの種別情報が「イメージコピー」で、かつ描画対象プレーンが右イメージプレーン１０であるか否かを判定する。
【０１６４】
ステップＳ８０５の条件を満たした場合は、続くステップＳ８０９の処理にて、描画要求Aのイメージコピーの描画位置と、描画要求Bのイメージコピーの描画位置との比較を行う。具体的には両者の描画先矩形領域のY座標を意味するy１およびy２の値がともに一致するか否かを判定する。
立体視のグラフィックスを描画する典型的なBD-Jアプリでは、ある一つの描画対象オブジェクトについて、左眼視点から見た形状を左イメージプレーン９に描画し、右眼視点から見た形状を右イメージプレーン１０に描画するというセットの処理を連続して行うことが多いと想定される。さらに、左右の描画の違いは視点の差に起因するものであるため、Y座標は同じでX座標のみ視差の分だけずらした描画であることが想定される。そこで、描画要求Aおよび描画要求Bがそれぞれ左イメージプレーン９、右イメージプレーン１０へのイメージコピーで、その描画位置の差がX座標のみであることを判定することで、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。したがって、これら２つのイメージコピー処理の結果は、プレーン合成部２０において確実に同一フレームの映像出力として処理を行う必要がある。
【０１６５】
そこで、ステップＳ８０９の条件を満たした場合、左右描画処理調停部３０はステップＳ８１０の処理により、レンダリングエンジン２２に対して描画要求Aおよび描画要求Bの代わりに、描画要求A,Bを統合した左右同時描画要求Cを発行する。
図３０（ａ）は、上記統合によって得られた左右同時描画要求Cを示す図である。図３０（ａ）における左右同時描画要求９０３(描画要求C)は、図３０（ｂ）における描画要求９０１（描画要求A）と、図３０（ｃ）における描画要求９０２（描画要求B）の２つの描画要求を１つにまとめたものである。
【０１６６】
左右同時描画要求Cを受けたレンダリングエンジン２２は、左イメージプレーン９へのイメージコピー処理と右イメージプレーン１０へのイメージコピー処理を、順番に行うのではなく、例えば左右のコピー処理をビットマップイメージの上から下へと１ラインずつ交互に行うようにする。これにより、左右イメージプレーンへの描画処理が同時並行的に実行されることになるため、図２８におけるプレーン合成部２０の合成処理ステップＳ７０４、ステップＳ７０５L、ステップＳ７０５Rがどのタイミングで動作していても、出力映像としてのL画像とR画像の表示の不整合は最小限に抑えることが可能となる。
【０１６７】
ここではレンダリングエンジン２２は左右を１ラインずつ処理する例を挙げたが、交互に切り替える処理の単位は１ラインずつに限定されるものではなく、また２つのレンダリングエンジンを備えることで完全な並列処理を行う構成をとってもよい。
一方で、ステップＳ８０５またはステップＳ８０９の条件が満たされなかった場合は、描画要求Aと描画要求Bは一つのオブジェクトについて左右の視点から見た描画を行うという、セットではなかったと判断され、以降は従来と同様の処理、すなわち表示のちらつきの発生も許容する処理が行われることになる。
【０１６８】
そこで次のステップＳ８０６の処理にて、警告メッセージを出力することで、BD-Jアプリの開発者あるいは再生装置２００のユーザに対して、本BD-Jアプリではちらつきが発生する可能性がある旨を通知することができる。警告メッセージの出力としては、例えばBD-Java仕様におけるExceptionメッセージをスローすることで、BD-Jアプリの開発者に警告を知らせてもよいし、表示ディスプレイ４００に警告メッセージを表示することで、BD-Jアプリの開発者あるいは再生装置２００のユーザに対して警告を知らせる構成をとってもよい。
【０１６９】
続いてステップＳ８０７およびステップＳ８０８の処理にて、保留されていた描画要求Aおよび描画要求Bをレンダリングエンジン２２に対してそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
以上の処理により、ステップＳ８０２、ステップＳ８０５、ステップＳ８０９の条件を満たす2つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力の中で同時に反映されることになる。したがって、ちらつき（ティアリング）が発生する可能性はあるものの、L画像とR画像の表示不整合に伴う左右の視覚の不整合を伴うちらつきは抑制することが可能となる。
【０１７０】
尚、判定対象のバリエーションとして以下のものを採用してもよい。つまり本実施の形態においては、「イメージコピー」のみをステップＳ８０２、ステップＳ８０５の判定処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「矩形塗り潰し」等についても判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１７１】
また本実施例ではステップＳ８１０において即時に左右同時描画要求を発行しているが、図２８のステップＳ７０６による合成処理完了通知を待ってから、左右同時描画要求を発行するような構成としてもよい。この構成をとった場合、イメージコピー処理が十分高速なハードウエアにおいては、図２８においては次フレームのステップＳ７０５L、ステップＳ７０５Rの処理が実行される前にイメージコピー処理を完了させることができるため、ティアリングも発生しない、より高品位な画面の更新を実現することが可能となる。
【０１７２】
更に、本実施の形態ではL画像とR画像の処理を上から１ラインずつ交互に行うことで、擬似的にL画像とR画像の生成を並行で行う構成をとるものとしているが、処理の単位は１ラインに限るものではない。
出力の２系統にしてもよい。つまり再生装置のハードウエアの構成によっては、デマルチプレクサ３は別の出力方式を実施しても良い。図２５の構成図にはビデオデコーダとイメージデコーダ、プレーン合成部を各一組ずつ有しているが、例えばこれらの構成を２つずつ持つハードウエアでは、左眼用と右眼用の映像を別々の系統で処理することができる。すなわち、左眼用のビデオデコーダが左ビデオプレーン５にビデオピクチャを格納し、左眼用のイメージデコーダが左イメージプレーン９にイメージデータを格納し、左眼用のプレーン合成部が左ビデオプレーン５と左イメージプレーン９のピクチャを合成し、右眼用についても同様に別系統で処理するような構成をとることで、L画像の生成処理とR画像の生成処理を完全に並列で行うようにしてもよい。
【０１７３】
また本実施形態においては、プレーン合成部２０の映像出力は、L画像とR画像を１ラインずつ交互に出力する構成をとっているが、映像出力についてもこの形式に限定するものではない。例えば、前述の左眼用と右眼用の二系統のハードウエアを持つ構成においては、映像出力としても左眼用映像出力と右眼用映像出力の二系統を有する構成もとることができる。また、プレーン合成部２０の映像出力の先に出力映像の一時保存用バッファを設けることにより、実施の形態１と同様の、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力を交互に繰り返すような構成をとることもできる。
【０１７４】
（第６実施形態）
描画要求に加え、画面更新要求を発行することで映像出力を実現する改良である。
図３０（ｄ）は、画面更新要求９０４を示す。この画面更新要求９０４は、BD-Javaの規格においてjava.awt.Toolkit#syncメソッドとして規定される。画面更新処理は、現在のイメージプレーンの画像を確実に表示ディスプレイ側に送ることをBD-Jアプリ側から保証するためのものであり、イメージプレーンとしてダブルバッファ構成を導入している実装、すなわち描画対象バッファと表示対象バッファとを個別に持つことでティアリングを抑える実装において、特に意味を持つものである。
【０１７５】
図３１は、画面更新要求をトリガとした左右描画処理調停部３０の処理手順を示すフローチャートである。
本フローチャートのステップＳ１００１、ステップＳ１００２、ステップＳ１００３、ステップＳ１００４、ステップＳ１００５、ステップＳ１００６、ステップＳ１００７、ステップＳ１００８の各処理は、それぞれステップＳ８０１、ステップＳ８０２、ステップＳ８０３、ステップＳ８０４、ステップＳ８０５、ステップＳ８０６、ステップＳ８０７およびステップＳ８０８、ステップＳ８０９と同様である。
【０１７６】
ステップＳ１００２、ステップＳ１００５、ステップＳ１００８の各条件が満たされた場合、すなわち、描画要求Aと描画要求Bが一つのオブジェクトについて左右の視点から見た描画を行うセットに該当すると判断された場合、描画要求Aおよび描画要求Bに相当する処理はこのタイミングでは行わない。つまり、描画要求A,Bを保留しておき、次のステップＳ１００９において、BD-Jモジュール１５からの次の描画要求Cが発行されるのを待つ。
【０１７７】
次のステップＳ１０１０において、描画要求Cの種別が「画面更新」であるか否かを判断する。描画要求Cが「画面更新」であった場合は、左右描画処理調停部３０はステップＳ１０１３の処理により、レンダリングエンジン２２に対して描画要求Aおよび描画要求Bの代わりに、左右同時描画要求を発行する。
描画要求Cが「画面更新」でなかった場合は、ステップＳ１０１１において、警告メッセージを出力した後、ステップＳ１０１２において、保留されていた描画要求A、描画要求B、描画要求Cをレンダリングエンジン２２に対して順番にそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
【０１７８】
以上が、本実施の形態における左右描画処理調停部３０の処理の流れである。
イメージプレーンがシングルバッファ構成をとっている場合は、画面更新要求の有無に関わらず、イメージプレーンの画像がプレーン合成部２０の動作タイミングに応じて映像出力に反映されるため、画面更新要求自体は必ずしも意味を持たない。一方、イメージプレーンがダブルバッファ構成をとっている場合は、画面更新要求が重要な意味を持つ。本実施の形態では、BD-Jアプリが左イメージプレーン９への「イメージコピー」、右イメージプレーン１０への「イメージコピー」、「画面更新」の３つをこの順番で呼び出さなければ、警告メッセージが出力されることになるため、BD-Jアプリ開発者に様々な再生装置において再生互換性が高いBD-Jアプリの開発を促すことができる。
【０１７９】
（第７実施形態）
前述の第４実施形態、第５実施形態および第６実施形態においては、左イメージプレーン９と右イメージプレーン１０はそれぞれ別個のイメージプレーンとしており、BD-Jアプリからの描画要求の観点では、描画対象プレーンが別々のものとして扱うことを前提としていた。本実施形態においては、左イメージプレーン９および右イメージプレーン１０を、BD-Jアプリの観点では同一のプレーンとして扱うものとする。
【０１８０】
図３２（ａ）は、左イメージプレーン９と右イメージプレーン１０とを左右に並べて連結することで構成される連結イメージプレーン（以降、サイドバイサイド形式と呼ぶ）を示す。この構成においては、左右のイメージプレーンの解像度がそれぞれ幅Wピクセル、高さHピクセルであるとすると、連結イメージプレーンは幅W×２ピクセル、高さHピクセルとなる。
【０１８１】
このサイドバイサイド形式のイメージプレーンの連結は、左右のイメージプレーンを、物理的に連続する同一のメモリとして構成することで実現可能となる。
左イメージプレーン９と右イメージプレーン１０は別々のメモリによって構成し、BD-Jアプリに対してのみ一つの連結イメージプレーンとして見せるような構成を採用することでも実現可能である。
【０１８２】
図３２（ｂ）は、左イメージプレーン９と右イメージプレーン１０を上下に並べて連結したものを一つの一般として扱う連結イメージプレーン（以降、トップアンドボトム形式と呼ぶ）を示す。この構成においては、左右のイメージプレーンの解像度が幅Wピクセル、高さHピクセルであるとすると、連結イメージプレーンは幅Wピクセル、高さH×２ピクセルとなる。
【０１８３】
このトップアンドボトム形式におけるイメージプレーンの連結にあたっても、左右のイメージプレーンを、物理的に連続する同一のメモリとして構成するのが望ましい。左イメージプレーン９と右イメージプレーン１０は別々のメモリによって構成し、BD-Jアプリに対してのみ一つの連結イメージプレーンとして見せるような構成としてもよい。
トップアンドボトム形式の連結イメージプレーンを持つ場合、BD-Jアプリケーションは、図３２（ｂ）において、左イメージプレーンと右イメージプレーンとを上下にまたがるような矩形領域をイメージコピー処理の対象にすることができる。
【０１８４】
さて、本実施形態に係る再生装置２００がディスプレイ４００に立体視映像を映し出す際の処理は、図３３に示される処理によって実現されるものとする。
図３３は、本実施の形態における左右描画処理調停３０の処理のフローチャートである。
まずステップＳ１１０１において、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。描画要求が発行されれば、Ｓ１１０２において、ステップＳ１１０１で受け取った描画要求の種別情報が「イメージコピー」で、かつ描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるものであるか否かを判定する。
【０１８５】
ステップＳ１１０２の条件を満たさない場合は、ステップＳ１１０３において、レンダリングエンジン２２に対して描画要求をそのまま発行することで、これまでの実施形態と同様の描画処理を実行する。
ステップＳ１１０２の条件を満たした場合には、ステップＳ１１０４Lに移行する。
描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるような描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、本実施の形態においては、ステップＳ１１０４L以降の処理によって、左右描画処理調停部３０がレンダリングエンジン２２の処理タイミングを調整することで、L画像とR画像の表示の不整合の回避を試みる。
【０１８６】
まず、ステップＳ１１０４Lにおいて、プレーン合成部２０からL画像の合成完了通知（図２６のステップＳ４０６Lにて発行されたもの）が来るのを待つ。
次に、ステップＳ１１０５Lにおいて、描画位置として左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理の描画要求をレンダリングエンジン２２に対して発行する。例えば図３２（ａ）における矩形領域１３０１の場合は、左上が（x１，y１）、右下が（W，y２）で指定される矩形領域を対象としたイメージコピーを発行すればよい。
【０１８７】
R画像についても同様に、ステップＳ１１０４Rにおいて、プレーン合成部２０からR画像の合成完了通知（図２６のステップＳ４０６Rにて発行されたもの）が来るのを待つ。そして合成完了通知が発行されれば、ステップＳ１１０５Rにおいて、描画位置として右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理の描画要求をレンダリングエンジン２２に対して発行する。図３２（ａ）における矩形領域１３０１の場合は、左上が（W，y１）、右下が（x２，y２）で指定される矩形領域を対象としたイメージコピーを発行すればよい。
【０１８８】
これらの処理により、イメージコピー処理が十分高速なハードウエアにおいては、左イメージプレーン９に対するイメージコピーの結果は、図２６においては次のフレームのステップＳ４０４L、ステップＳ４０５Lの処理にて映像出力に反映され、右イメージプレーン１０に対するイメージコピーの結果は、次のフレームのステップＳ４０４R、ステップＳ４０５Rの処理にて映像出力に反映されることを保証することができ、２つのイメージコピーの結果が、プレーン合成部２０にて同一フレームの映像出力に反映されるため、L画像とR画像の表示不整合に伴うちらつきを防止することが可能となる。
【０１８９】
尚、本実施の形態においては、「イメージコピー」のみをステップＳ１１０２の判定処理の対象とし、それ以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとったが、それ以外の処理、例えば「矩形塗り潰し」等についても判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０１９０】
(第８実施形態)
連結イメージプレーンに対する描画要求の分離を実現する実施形態である。描画要求の分離は、ある矩形範囲に対する描画要求を、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理と、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理とに分離して、これらのイメージコピー処理を同時に実行させるものである。
【０１９１】
図３４は、描画要求と、左右同時描画要求とを示す。
図中の描画要求１４０１は、解像度が幅1000ピクセル、高さ1500ピクセルの描画イメージである”ビットマップイメージ１”を、トップアンドボトム形式のイメージプレーンにおける(x1,y1)=(200,300),(x2,y2)=(1200,1800)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
【０１９２】
左右同時描画要求１４０２は、描画要求１４０１を変換することで得られる左右同時描画要求であり、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理、及び、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理を左右同時に要求するものである。
左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理は、”ビットマップイメージ１”のx1=0,y1=0,x2=1000,y2=780の矩形領域を、イメージプレーンにおける(x1,y1)=(200,300),(x2,y2)=(1200,1080)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
【０１９３】
右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理は、”ビットマップイメージ１”のx1=0,y1=780,x2=1000,y2=1500の矩形領域を、イメージプレーンにおける(x1,y1)=(200,0),(x2,y2)=(1200,720)の矩形範囲に、書き込むことを要求するイメージコピーの要求である。
図３５は本実施の形態における左右描画処理調停部３０の処理のフローチャートである。まずステップＳ１２０１の処理により、BD-Jアプリからの描画指示に基づいてBD-Jモジュール１５から描画要求が発行されるのを待つ。
【０１９４】
次に、ステップＳ１２０２において、ステップＳ１２０１で受け取った描画要求の種別情報が「イメージコピー」で、かつ描画範囲が左右の領域にまたがるものであるか、又は、上下の領域にまたがるものであるか否かを判定する。トップアンドボトム形式の連結イメージプレーンを持つ場合、BD-Jアプリは、上下にまたがるような矩形領域を描画範囲としてイメージコピー処理を要求することができる。
【０１９５】
サイドバイサイド形式の連結イメージプレーンを持つ場合、BD-Jアプリは、左右にまたがるような矩形領域を描画範囲としてイメージコピー処理を要求することができる。
ステップＳ１２０２の条件を満たさない場合は、ステップＳ１２０３の処理にて、レンダリングエンジン２２に対して描画要求をそのまま発行することで、これまでと同様の描画処理が実行される。
【０１９６】
ステップＳ１２０２の条件を満たした場合には、ステップＳ１２０４において、受け付けた描画要求を、左イメージプレーン９に含まれる部分のみを切り抜いたイメージコピー処理と、右イメージプレーン１０に含まれる部分のみを切り抜いたイメージコピー処理とを同時に実行させる左右同時描画要求に変換して、レンダリングエンジン２２に発行する。
【０１９７】
描画位置が左イメージプレーンと右イメージプレーンの双方にまたがるような描画要求が発行される場合は、BD-Jアプリとしては、ある一つの描画対象オブジェクトについて、左眼視点から見た形状と右眼視点から見た形状をセットで描画しようとしていることが予測される。そのため、ステップＳ１２０４において、1つのイメージコピー処理を要求する描画要求を、2つのイメージコピー処理を同時に要求する左右同時描画要求に変換することにより、レンダリングエンジン２２の処理順序を制御し、L画像とR画像の表示の不整合の回避を行う。
【０１９８】
尚、左右同時描画要求１４０２を受けたレンダリングエンジン２２は、前述の実施形態で説明したように、左イメージプレーン９へのイメージコピー処理と右イメージプレーン１０へのイメージコピー処理を順番に行うのではなく、例えば左右のコピー処理をビットマップイメージの上から下へと１ラインずつ交互に行うようにすることで、出力映像としてのL画像とR画像の表示の不整合を最小限に抑えることができる。
【０１９９】
ただし、本実施の形態においては、左イメージプレーン９への描画位置のY座標と右イメージプレーン１０への描画位置のY座標が一致しない場合がある。そのため、コピー処理は単純に上から１ラインずつ交互に行うのではなく、例えば左イメージプレーン９のy行目へのコピー処理を行い、その次には、右イメージプレーン１０の同じくy行目へのコピー処理を行うような順序でコピーを行うのが望ましい。
【０２００】
また本実施の形態においては、「イメージコピー」のみをステップＳ１２０２の判定処理の対象とし、イメージコピー以外の描画要求については従来と同様の処理、すなわち表示のちらつきの発生も許容する構成をとった。しかしイメージコピー以外の処理でも、例えば「矩形塗り潰し」等を、左右同時描画要求を行うかどうか判定の対象に加えてもよい。この場合は、ちらつきを抑止しうる描画処理種別の範囲を拡げることができる。
【０２０１】
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
【０２０２】
(立体視方式)
各実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。
【０２０３】
テレビ４００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
【０２０４】
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２０５】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０２０６】
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
【０２０７】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
【０２０８】
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていてもよいし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。
【０２０９】
(ビデオデコーダの構成)
各実施形態において、ビデオデコーダは、左目用のビデオデコーダ5a、右目用のビデオデコーダ5bのそれぞれのものが存在すると説明したが、これらを一体にしてもよい。
（半導体メモリカード記録装置及び再生装置の実施形態）
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
【０２１０】
まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。
BD-ROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。
例えば、BD-ROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。
【０２１１】
以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
半導体メモリカード再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。
【０２１２】
一方、BD-ROMには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するMKB（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びMKBに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、MKB、及び暗号化タイトルキーは対になっており、さらにBD-ROM上の通常コピーできない領域（BCAと呼ばれる領域）に書き込まれた識別子（例えばボリュームID）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。
【０２１３】
装填されたBD-ROMを再生装置において再生する場合、例えばBD-ROM内の暗号化タイトルキー、MKBと対になっている（または対応する）デバイスキーが再生装置内になければ、暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵（タイトルキー）は、鍵自体が暗号化されて（暗号化タイトルキー）BD-ROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵を導き出すことができないからである。
【０２１４】
逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しければ、例えば上述の暗号解読に必要な鍵（デバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。
【０２１５】
以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。
半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを介してデータを読み出すように構成すればよい。
【０２１６】
より詳細には、再生装置のスロット（図示せず）に半導体メモリーカードが挿入されると、半導体メモリーカードI/Fを経由して再生装置と半導体メモリーカードが電気的に接続される。半導体メモリーカードに記録されたデータは半導体メモリーカードI/Fを介して読み出すように構成すればよい。
次に、例えば電子配信を利用して、図1、図２４に示した記録媒体１００に記録されたデータ、例えば記録媒体１００に記録されたオリジナルのコンテンツに対応するデータ（例えば、ビデオストリーム、オーディオストリーム、字幕データ、字幕データ、背景画像、GUI、アプリケーション、アプリケーション管理テーブルなど）の全部若しくは一部（例えば再生に必要なデータのアップデートデータ）、または追加コンテンツを配信データとして、半導体メモリーに記録する動作について説明をする。
【０２１７】
上述の動作は本実施の形態において説明をした再生装置がその半導体メモリーに記録する動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDメモリーカードを例に説明をする。
【０２１８】
再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバ（図示せず）へ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報（例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等）をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。
【０２１９】
この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。
【０２２０】
例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。
生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。
次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。
【０２２１】
次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
【０２２２】
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。
【０２２３】
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、
（１） 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック
（２） 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック
（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番どのような順序で行なってもよい。
【０２２４】
上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いて、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。
【０２２５】
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号（例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等）は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の（１）の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
【０２２６】
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域（第１の記録領域と称す）とは別の記録領域（第２の記録領域と称す）に設けること、およびこの第２の記録領域へのアクセスをするための制御回路を設けるとともに、第２の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
【０２２７】
例えば、第２の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第２の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第２の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行すると、要求を受けた制御回路は第２の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第１の記録領域に記録するように構成すればよい。
【０２２８】
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のＸ.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
【０２２９】
また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。
【産業上の利用可能性】
【０２３０】
本発明は、立体視映像を再生する再生機器において、描画更新のタイミングにおけるちらつきを抑止する技術に関し、特に、再生機器の映像出力と非同期に画像を更新する機能を持つ立体視映像再生装置に適用可能である。
【符号の説明】
【０２３１】
１００ 記録媒体
２００ 再生装置
３００ リモコン
４００ テレビ
５００ シャッター眼鏡
【特許請求の範囲】
【請求項１】
再生装置であって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生部と、
アプリケーションを動作させるプラットフォーム部と、
複数のプレーンメモリと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、複数のプレーンメモリに対する描画イメージの書き込みを行う描画部とを備え、
複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする再生装置。
【請求項２】
前記プレーンメモリに書き込まれる描画イメージは、記録媒体に記録されたデータ構造体のインスタンスであり、
レフトビュープレーンメモリへの書き込み指定及びライトビュープレーンメモリへの書き込み指定は、
書き込みの対象となるインスタンスの指定と、
レフトビュープレーンメモリ及びライトビュープレーンメモリにおける座標の指定とを含む
ことを特徴とする請求項１記載の再生装置。
【請求項３】
前記描画イメージは、複数のラインデータからなり、
前記レフトビュープレーンメモリ及びライトビュープレーンメモリのうち、何れか一方にラインデータが書き込まれれば、
前記描画部は、レフトビュープレーンメモリ及びライトビュープレーンメモリのうち他方のプレーンメモリに対して、当該ラインデータと同じ行のラインデータの書き込みを行う
ことを特徴とする請求項１記載の再生装置。
【請求項４】
前記レフトビュープレーンメモリ及びライトビュープレーンメモリのそれぞれは、ダブルバッファであり、ダブルバッファを構成する2つのバッファのうち一方のものは表示対象バッファに割り当てられ、他方のものは描画対象バッファに割り当てられ、
前記描画部による描画イメージの書き込み先は、描画対象バッファであり、
表示対象バッファには、既に書き込みが完了した描画イメージであって、現在表示に供されている描画イメージが格納され、
描画対象バッファへの書き込みが完了した際、これまで描画対象バッファに割り当てらえていたバッファを表示対象バッファに変更し、これまで表示対象バッファに割り当られていたバッファを描画対象バッファに変更することで、描画イメージの立体視再生の更新を行う
ことを特徴とする請求項１記載の再生装置。
【請求項５】
アプリケーションプログラムインターフェイスの呼び出しがなされた場合、レフトビュープレーンメモリを構成する描画対象バッファ、及び、ライトビュープレーンメモリを構成する描画対象バッファのうち、何れか一方の書き込みを先に行い、当該書き込みが完了した後、レフトビュープレーンメモリを構成する描画対象バッファ、及び、ライトビュープレーンメモリを構成する描画対象バッファのうち、他方の書き込みを行う
ことを特徴とする請求項４記載の再生装置。
【請求項６】
記録媒体には複数のコンテンツが記録されており、
前記ビデオストリームは、特定のコンテンツに含まれており、
前記プラットフォーム部は、
複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに対応するアプリケーション管理テーブルに従ってアプリケーションを起動して実行し、
レフトビュープレーンメモリ及びライトビュープレーンメモリは、
動作モードオブジェクト内のコンフィグレーション情報に従って、メモリデバイス上に確保される
ことを特徴とする請求項１記載の再生装置。
【請求項７】
前記コンフィグレーション情報は、解像度コードを含み、解像度コードは、縦画素数及び横画素数を示す
ことを特徴とする請求項６記載の再生装置。
【請求項８】
コンピュータ上で再生処理を行う再生方法であって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生ステップと、
アプリケーションを動作させるプラットフォームステップと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、コンピュータにおける複数のプレーンメモリに対する描画イメージの書き込みを行う描画ステップとを備え、
前記複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする再生方法。
【請求項９】
コンピュータに再生処理を実行させるプログラムであって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生ステップと、
アプリケーションを動作させるプラットフォームステップと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、コンピュータにおける複数のプレーンメモリに対する描画イメージの書き込みを行う描画ステップとをコンピュータに実行させ、
前記複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とするプログラム。
【請求項１】
再生装置であって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生部と、
アプリケーションを動作させるプラットフォーム部と、
複数のプレーンメモリと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、複数のプレーンメモリに対する描画イメージの書き込みを行う描画部とを備え、
複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする再生装置。
【請求項２】
前記プレーンメモリに書き込まれる描画イメージは、記録媒体に記録されたデータ構造体のインスタンスであり、
レフトビュープレーンメモリへの書き込み指定及びライトビュープレーンメモリへの書き込み指定は、
書き込みの対象となるインスタンスの指定と、
レフトビュープレーンメモリ及びライトビュープレーンメモリにおける座標の指定とを含む
ことを特徴とする請求項１記載の再生装置。
【請求項３】
前記描画イメージは、複数のラインデータからなり、
前記レフトビュープレーンメモリ及びライトビュープレーンメモリのうち、何れか一方にラインデータが書き込まれれば、
前記描画部は、レフトビュープレーンメモリ及びライトビュープレーンメモリのうち他方のプレーンメモリに対して、当該ラインデータと同じ行のラインデータの書き込みを行う
ことを特徴とする請求項１記載の再生装置。
【請求項４】
前記レフトビュープレーンメモリ及びライトビュープレーンメモリのそれぞれは、ダブルバッファであり、ダブルバッファを構成する2つのバッファのうち一方のものは表示対象バッファに割り当てられ、他方のものは描画対象バッファに割り当てられ、
前記描画部による描画イメージの書き込み先は、描画対象バッファであり、
表示対象バッファには、既に書き込みが完了した描画イメージであって、現在表示に供されている描画イメージが格納され、
描画対象バッファへの書き込みが完了した際、これまで描画対象バッファに割り当てらえていたバッファを表示対象バッファに変更し、これまで表示対象バッファに割り当られていたバッファを描画対象バッファに変更することで、描画イメージの立体視再生の更新を行う
ことを特徴とする請求項１記載の再生装置。
【請求項５】
アプリケーションプログラムインターフェイスの呼び出しがなされた場合、レフトビュープレーンメモリを構成する描画対象バッファ、及び、ライトビュープレーンメモリを構成する描画対象バッファのうち、何れか一方の書き込みを先に行い、当該書き込みが完了した後、レフトビュープレーンメモリを構成する描画対象バッファ、及び、ライトビュープレーンメモリを構成する描画対象バッファのうち、他方の書き込みを行う
ことを特徴とする請求項４記載の再生装置。
【請求項６】
記録媒体には複数のコンテンツが記録されており、
前記ビデオストリームは、特定のコンテンツに含まれており、
前記プラットフォーム部は、
複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに対応するアプリケーション管理テーブルに従ってアプリケーションを起動して実行し、
レフトビュープレーンメモリ及びライトビュープレーンメモリは、
動作モードオブジェクト内のコンフィグレーション情報に従って、メモリデバイス上に確保される
ことを特徴とする請求項１記載の再生装置。
【請求項７】
前記コンフィグレーション情報は、解像度コードを含み、解像度コードは、縦画素数及び横画素数を示す
ことを特徴とする請求項６記載の再生装置。
【請求項８】
コンピュータ上で再生処理を行う再生方法であって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生ステップと、
アプリケーションを動作させるプラットフォームステップと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、コンピュータにおける複数のプレーンメモリに対する描画イメージの書き込みを行う描画ステップとを備え、
前記複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とする再生方法。
【請求項９】
コンピュータに再生処理を実行させるプログラムであって、
記録媒体に記録されているビデオストリームをデコードして、立体視映像の再生を行う再生ステップと、
アプリケーションを動作させるプラットフォームステップと、
アプリケーションからのアプリケーションプログラムインターフェイスの呼び出しに応じて、コンピュータにおける複数のプレーンメモリに対する描画イメージの書き込みを行う描画ステップとをコンピュータに実行させ、
前記複数のプレーンメモリには、レフトビュープレーンメモリと、ライトビュープレーンメモリとがあり、
前記アプリケーションプログラムインターフェイスの引数は、レフトビュープレーンメモリへの書き込み指定と、ライトビュープレーンメモリへの書き込み指定とのペアを含む
ことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【公開番号】特開２０１３−５９０３６（Ｐ２０１３−５９０３６Ａ）
【公開日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願番号】特願２０１２−２２３４８９（Ｐ２０１２−２２３４８９）
【出願日】平成２４年１０月５日（２０１２．１０．５）
【分割の表示】特願２０１１−５００４９６（Ｐ２０１１−５００４９６）の分割
【原出願日】平成２２年２月１２日（２０１０．２．１２）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願日】平成２４年１０月５日（２０１２．１０．５）
【分割の表示】特願２０１１−５００４９６（Ｐ２０１１−５００４９６）の分割
【原出願日】平成２２年２月１２日（２０１０．２．１２）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]