JP5097297B2 - 再生装置、再生方法、再生プログラム - Google Patents

再生装置、再生方法、再生プログラム Download PDF

Info

Publication number
JP5097297B2
JP5097297B2 JP2011534065A JP2011534065A JP5097297B2 JP 5097297 B2 JP5097297 B2 JP 5097297B2 JP 2011534065 A JP2011534065 A JP 2011534065A JP 2011534065 A JP2011534065 A JP 2011534065A JP 5097297 B2 JP5097297 B2 JP 5097297B2
Authority
JP
Japan
Prior art keywords
plane
graphics
eye
image
configuration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011534065A
Other languages
English (en)
Other versions
JPWO2011039990A1 (ja
Inventor
治 山地
ジェルマーノ ライクセンリング
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2011534065A priority Critical patent/JP5097297B2/ja
Application granted granted Critical
Publication of JP5097297B2 publication Critical patent/JP5097297B2/ja
Publication of JPWO2011039990A1 publication Critical patent/JPWO2011039990A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/7921—Processing of colour television signals in connection with recording for more than one processing mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/156—Mixing image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/183—On-screen display [OSD] information, e.g. subtitles or menus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N13/356—Image reproducers having separate monoscopic and stereoscopic modes
    • H04N13/359—Switching between monoscopic and stereoscopic modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N13/361—Reproducing mixed stereoscopic images; Reproducing mixed monoscopic and stereoscopic images, e.g. a stereoscopic image overlay window on a monoscopic image background
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8233—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a character code signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00246—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is obtained from a local device, e.g. device key initially stored by the player or by the recorder
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00253—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier
    • G11B20/00362—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier the key being obtained from a media key block [MKB]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00485—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier
    • G11B20/00492—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted
    • G11B20/00528—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted wherein each title is encrypted with a separate encryption key for each title, e.g. title key for movie, song or data file
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/10537—Audio or video recording
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B2020/1264—Formatting, e.g. arrangement of data block or words on the record carriers wherein the formatting concerns a specific kind of data
    • G11B2020/1289—Formatting of user data
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N2013/40—Privacy aspects, i.e. devices showing different images to different viewers, the images not being viewpoints of the same scene
    • H04N2013/405—Privacy aspects, i.e. devices showing different images to different viewers, the images not being viewpoints of the same scene the images being stereoscopic or three dimensional
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Computer Graphics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Television Signal Processing For Recording (AREA)
  • Processing Or Creating Images (AREA)

Description

バイトコードアプリケーションによるグラフィクス描画技術の技術分野に属する発明である。
バイトコードアプリケーションとは、オブジェクト指向プログラミング言語を用いて記述されたクラス構造体をコンパイルすることで得られた実行形式のプログラムであり、機器に依存しないコード(バイトコード)によって記述されているものをいう。バイトコードアプリケーションとして典型的なものにはJava（登録商標）アプリケーションがある。
バイトコードアプリケーションに対しては、ミドルウェアによって各種機能が提供される。バイトコードアプリケーションに対する機能提供は、ミドルウェアが実装しているパッケージのメンバー関数を呼び出すことでなされる。ミドルウェアが実装しているパッケージは、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、コピー・ペースト等の描画処理を行うライブラリを含む。そしてミドルウェアは、このライブラリの機能によって、グラフィクス描画を実行する描画部を具備している。バイトコードアプリケーションはこれらの描画処理の要求を連続的に発行することで、様々なグラフィクス描画処理を実現することができる。グラフィクス描画のためのパッケージには、java.awtパッケージがあり、グラフィクス描画のアプリケーションプログラムインターフェイスは、このjava.awtパッケージのメソッドになる。ここで、バイトコードアプリケーションの動作のためのプラットフォームには、平面視再生を前提にしたものに限定されず、立体視再生を前提にしたものも登場している。立体視再生を前提にしたプラットフォームは、左目用のグラフィクスプレーンと、右目用のグラフィクスプレーンとを有し、平面視モードと、立体視モードとにおいて、これらのグラフィクスプレーンを切り替えるようにしている。
更に特許文献１には、平面視モードと、立体視モードとの切替の前後における見え方が全く同じになるような切替後映像を用意することで、モード切替前後で出力される映像の同一性を保証する技術が記載されている。
特許第４２６６７７４号

ところで立体視コンテンツの再生時に、アプリケーションを起動して、動画再生に同期したGUIをアプリケーションに描画させることで、立体視コンテンツの再生時におけるユーザ操作を容易に行わせたいという要望がある。これは、既存のDVB-MHPコンテンツやBD-ROMコンテンツにおいて、コンテンツと、アプリケーションとを連動させて、アプリケーションにGUI処理を行わせるという高度な処理が実現されており、これを立体視コンテンツでも実現したいというコンテンツ制作者側からの要望による。
バイトコードアプリケーションやjava.awt.Graphicsは、その実行時にあたって複数のスレッドによって処理されており、またパラメータのやりとりは、スタックを介したスレッド間通信でなされるので、バイトコードアプリケーションによるグラフィクスの描画要求にはタイムラグが大きい。よって、何れかのアプリケーションスレッドが発したモード切り替えがjava.awt.Graphicsによって受理された後に、別のアプリケーションスレッドが発した2Dグラフィクス描画要求がjava.awt.Graphicsに到達するということも希ではない。
2Dグラフィクス描画要求が遅れて到達したために、モード切り替えによって確保された右目用グラフィクスプレーン、右目用グラフィクスプレーンのうち、左目用グラフィクスプレーンのみに、2Dグラフィクス描画要求によって要求されたグラフィクスが書き込まれることになると、両目のグラフィクスの不整合が生じることになり、ユーザに視覚的な不快感を与える。
無論、2Dグラフィクス描画要求によって左目−右目の視覚不整合が生じたとしても、その後の3Dグラフィクス描画要求の発行によって、グラフィクスの更新がなされれば、左目−右目の視覚不整合が生じる期間は、僅かな期間となる。しかし、立体視再生時における左目−右目の視覚不整合の発生は、たとえ僅かな期間であっても、視聴者に与える不快感の影響は大きく、その不快感が原因で、視聴者が立体視コンテンツ自体を嫌悪してしまい、立体視コンテンツの関連製品に拒否反応を示すことは充分考えられる。期間の長短に拘らず、左目−右目の視覚不整合は、許容されるものではない。
両目のグラフィクスの不整合を回避するには、アプリケーションの作成を、マニファクチャが一律に規律することが考えられるが、コンテンツ固有のGUIを表示するアプリケーションは、コンテンツプロンバイダによって独自に作成されるものであり、たとえ再生品質からも要望であるとしても、マニファクチャ側の要望を一方的に押し付けることは不可能に近い。
本発明の目的は、バイトコードアプリケーションから描画部への描画要求のタイムラグが多大であったとしても、立体視再生を楽しむユーザに視覚的な不快感を与えるこがない再生装置を提供することである。
上記課題を解決することができる再生装置は、
バイトコードアプリケーションを動作させるプラットフォーム部と、
左目用グラフィクスプレーンと、右目用グラフィクスプレーンとを備え、
前記プラットフォーム部は、バイトコードアプリケーションからのグラフィクス描画要求を受け付けてグラフィクス描画を実行する描画部を含み、
前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがあり、
前記グラフィクス描画要求には、2Dグラフィクスの描画要求と、3Dグラフィクスの描画要求とがあり、
前記コンフィグレーションのうち、１プレーン構成から、２プレーン構成への切り替えは、これまでにバイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を無効化する処理と、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーする処理とを含み、当該コピーがなされた後に、描画部は3Dグラフィクスの描画要求を受け入れる
ことを特徴としている。
上記課題解決手段を具備した再生装置は、グラフィクスプレーンのコンフィグレーションを、1プレーン構成から2プレーン構成に切り替える際、2Dグラフィクス描画要求を無効化するので、1プレーン構成から2プレーン構成へのグラフィクスプレーンのコンフィグレーション切替後に描画部に到達する2Dグラフィクス描画要求が存在したとしても、その2Dグラフィクス描画要求は、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのプレーン間コピーがなされる前に無効化されることになる。
スタック上の2Dグラフィクス描画要求を一時的に無効にした上で、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーがなされるので、グラフィクスプレーンのコンフィグレーションが1プレーン構成から2プレーン構成に切り替えられた後に、描画部に2Dグラフィクス描画要求が到達することで、左目用グラフィクスプレーンの格納内容のみが更新されることはありえない。再生装置のマニファクチャは、たとえコンテンツプロバイダが制作したアプリケーションを動作させて、そのアプリケーションに3Dグラフィクスを表示させる場合でも、その3Dグラフィクスを視聴するユーザに不快な思いさせないよう、立体視コンテンツの再生の品位に充分な配慮を払うことができる。
2Dグラフィクス描画要求の無効化は、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーに先立ちなされるので、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーの途中で、左目用グラフィクスプレーン単独の更新がなされることはない。左目用グラフィクスプレーンに格納されている画素のうち、既に右目用グラフィクスプレーンにコピーされたものが、プレーン間コピーの途中で、2Dグラフィクス描画要求によって事後的に書き換えられてしまうという可能性の根を完全に断つことができる。
グラフィクスプレーンのコンフィグレーションを1プレーン構成から2プレーン構成に変更する際、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとが同じ内容になっていることが厳密に保障されるので、僅かな期間の左目−右目の視覚不整合も、発生することはない。よって、3Dグラフィクスの品位を完全なレベルにまで向上させることができる。
グラフィクスプレーンが1プレーン構成から2プレーン構成に切り替えられた後の2Dグラフィクス描画要求の無効化によって、片目用のグラフィクスプレーンのみが単独で書き換えられる可能性を排除しており、アプリケーションによって描画される3Dグラフィクスの品位を、そのアプリケーションのプラットフォームにあたるプラットフォームの立場から保障しているので、コンテンツプロバイダは、アプリケーションによって描画される3Dグラフィクスの品位の維持をマニファクチャに委ねることができる。3Dグラフィクスの品質管理をマニファクチャに委ねることで、コンテンツプロバイダは、立体視コンテンツの制作に専念することができるので、立体視コンテンツの制作が多いに促進され、立体視コンテンツの充実化を図ることができる。
たとえ、バイトコードアプリケーションから描画モジュールへの描画要求のやりとりにタイムラグが発生したとしても、そのタイムラグが、立体視画像の品位を低下させる要因にはなりえないから、バイトコードアプリケーションから描画モジュールへの描画要求のやりとりにタイムラグが発生するようなソフトウェア実装も、許容されることになる。マニファクチャが再生装置を開発するにあたってのソフトウェア実装にも、自由度が認められるので、再生装置の製品開発が促進され、立体視再生が可能な再生装置の充実化を図ることができる。
現実の再生装置のソフトウェア実装では、2Dグラフィクス描画要求がjava.awt.Graphicsによって処理され、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーが、再生装置におけるデバイスドライバによって実行され、これらjava.awt.Graphicsと、デバイスドライバとがパラレルに動作するという実装形態が充分考えられる。しかし、本発明では、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーに先立ち2Dグラフィクス描画要求の無効化を行うので、java.awt.Graphicsと、デバイスドライバとがパラレルに動作するというソフトウェア実装の形態でも、グラフィクスプレーンが2プレーン構成である場合に、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとが同じ内容になっていることが厳密に保障される。よって再生装置のマニファクチャから、ソフトウェア実装の自由度が奪われることはない。
任意的であるが、上記再生装置は以下のように構成してもよい。例えば、前記再生装置は、
前記記録媒体に記録されている立体視ビデオストリームをデコードするデコーダと、
立体視ビデオストリームをデコードすることにより得られる左目用ピクチャデータを格納する左目用ビデオプレーンと、
立体視ビデオストリームをデコードすることにより得られる右目用ピクチャデータを格納する右目用ビデオプレーンと、
左目の出力系統の合成及び右目の出力系統の合成を実行する合成部とを備え、
前記左目の出力系統の合成とは、
左目用グラフィクスプレーンの格納内容と、左目用ビデオプレーンの格納内容とを合成するものであり、
前記右目の出力系統の合成とは、
左目用グラフィクスプレーン及び右目用グラフィクスプレーンのどちらかの格納内容を、右目用ビデオプレーンの格納内容と合成するものであり、
前記合成部は、前記１プレーン構成から２プレーン構成への切り替え時において、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーした後に、右目用出力系統における右目用グラフィクスプレーンの格納内容を、右目用ビデオプレーンの格納内容に合成する処理を開始し、
前記描画部による3Dグラフィクス描画の要求の受け入れは、右目用グラフィクスプレーンの格納内容と、右目用ビデオプレーンの格納内容との合成後になされるものでもよい。
左目用グラフィクスプレーンから右目用グラフィクスプレーンへのプレーン間コピーが完了されるまで、ビデオプレーンと、グラフィクスプレーンとの合成出力がなされることはないので、左目用グラフィクスプレーンの格納内容と、右目用グラフィクスプレーンの格納内容とで視覚の不整合が存在する状態のまま、グラフィクスが動画像と合成されて視聴者に供されることはない。左目で視聴すべきグラフィクスと、右目で視聴すべきグラフィクスとの完全な整合を維持することができる。
パッケージ媒体である記録媒体、プレーヤ機器である再生装置、表示装置、眼鏡によって構成されるホームシアターシステムを示す。 再生装置の内部構成を示すブロック図である。 ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。 描画部１１５の機能的な構成を示すブロック図である。 プレーン合成器の内部構成を示す図である。 グラフィクスプレーン１０４c,１０４dの内部構成を示す。 プレーン間コピーの処理内容を示す図である。 1プレーン構成から2プレーン構成への切り替え後のグラフィクス更新を示す図である。 BD-Jモジュール１５がサポートするグラフィクス描画機能のAPIの一例を示した図である。 図８のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。 図９のように引数が指定された場合、Graphics#drawImage及びStereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。 2Dグラフィクス描画要求の無視、プレーン間コピー、右目用出力系統の追加の時間的な関係を、ビデオストリーム時間軸に沿って示したタイミングチャートである。 Graphics#drawImageの無効化を実行するのとしないのとで、再生装置によって再生される立体視映像がどう違うのかの対比説明のための図である。 無効化を実行せずにモード切り替えを実行しようとする場合、スタックにおける複数のコードが、どのように処理されるかを連続写真的な表記で示す図である。 図１４（ｃ）の書き込みによって、再生されることになる立体視映像を示す。 無効化を行ってからモード切り替えを実行しようとする場合、スタックにおける複数のAPIコールコードが、どのように処理されるかを連続写真的な表記で示す。 図１６（ｄ）の書き込みによって、再生されることになる立体視映像を示す。 BD-ROM１００の内部構成を示す図である。 再生装置の内部構成を示すブロック図である。 プレーンメモリのレイヤ構成と、合成部の構成要素とを示す。 プレーン合成器２０が、４通りの出力系統の切り替えを実現することによりなされる４つの合成モード(合成モード１、合成モード２、合成モード３、合成モード４)を示す。 BD-Jモジュール１５がサポートするグラフィクス描画機能のAPIの一例を示した図である。 図２２のグラフィクス描画機能APIのコールコードの一例を示す図である。

合成モード切替要求８０３が呼び出された場合の処理手順を示す図である。 １プレーンから2プレーンに切り替える処理、2プレーンから1プレーンに切り替える処理の手順を示すフローチャートである。 setConfiguraionAPIコール時におけるorg.havi.uiの処理手順を示すフローチャートである。 java.awt.Graphicsの処理手順を示すフローチャートである。 アプリケーションマネージャによるStereoGraphicsの状態制御の手順を示すフローチャートである。 プレーン合成器による合成モード切り替え、及び、右目用出力系統の切り替えの手順を示すフローチャートである。 StereoGraphics#drawImageメソッドがコールされた際のライン描画手順を示すフローチャートである。 バイトコードアプリケーションによるメニュー表示のフローチャートである。 動作モードオブジェクトの内部構成の一例を示す図である。 タイトル選択時の解像度設定時における処理手順を示すフローチャートである。 立体視画像が表示画面よりも手前にあるように見える原理を説明するための図である。 立体視画像が表示画面よりも奥にあるように見える原理を説明するための図である。 正と負のプレーンオフセットの見え方の違いの一例を示す図である。 集積回路のアーキテクチャを示す図である。
以下、図面を参照しながら、本願に包含される再生装置の発明、集積回路の発明、再生方法の発明、プログラムの発明の実施形態について説明する。
上記課題解決手段を具備した再生装置の発明は、パッケージ媒体を再生するためのプレーヤ機器として実施することができ、集積回路の発明は、当該プレーヤ機器に組込まれるシステムLSIとして実施することができる。再生方法の発明は、このプレーヤ機器で実現される時系列手順として実施することができる。プログラムの発明は、コンピュータ読み取り可能な記録媒体に記録され、プレーヤ機器にインストールされる実行形式プログラムとして実施することができる。
１：再生装置の発明の使用形態
図１は、パッケージ媒体である記録媒体、プレーヤ機器である再生装置、表示装置、眼鏡によって構成されるホームシアターシステムを示す。同図に示すように、上記パッケージ媒体である記録媒体、プレーヤ機器である再生装置は、表示装置、眼鏡、リモコンと共にホームシアターシステムを構成し、ユーザによる使用に供される。
１.１：記録媒体１００
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する光ディスクである。
１.２：再生装置２００
再生装置２００は、テレビ４００と接続され、記録媒体１００を再生する。かかる再生は、左眼用映像（L画像）の映像出力と、右眼用映像（R画像）の映像出力を交互に繰り返すことでなされる。こうして再生される再生映像には、2D映像、3D映像が存在する。2D映像とは、例えば表示装置の表示画面を含む平面をX-Y平面として捉えて、このX-Y平面上に位置する表示画面の表示位置における画素にて表現される画像であり、平面視画像とも呼ばれる。この2D映像を再生するための再生装置の再生モードを“2D再生モード”又は“平面視再生モード”と呼ぶ。そして、この2D再生モードで、再生装置によって表示されるグラフィクスを“2Dグラフィクス”という。
対照的に3D映像とは、上述のX-Y平面として捉えた平面と直交する直線をZ軸として、Z軸方向の奥行きを加えた画像である。この3D映像を再生するための再生装置の再生モードを“3D再生モード”又は“立体視再生モード”と呼ぶ。そして、この3D再生モードで、再生装置によって表示されるグラフィクスを“3Dグラフィクス”という。
１.３：リモコン３００
リモコン３００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン３００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
１.４：テレビ４００
テレビ４００は、再生装置２００からの映像出力を受け取って、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
左目用ビデオプレーン１０４aおよび右目用ビデオプレーン１０４bは、プレーンメモリセットの1つであり、それぞれ左眼用のビデオのピクチャ、右眼用のビデオのピクチャが格納される。
２.４.２：左目用グラフィクスプレーン１０４c,右目用グラフィクスプレーン１０４d
左目用グラフィクスプレーン１０４cおよび右目用グラフィクスプレーン１０４dは、プレーンメモリセットのうちの1つであり、ビデオプレーンの上の重畳させるべきグラフィクスを非圧縮形式で格納する。左目用グラフィクスプレーン１０４cは、左眼用のグラフィクスを格納する左目用プレーンメモリである。右目用グラフィクスプレーン１０４dは、右眼用のグラフィクスを格納する右目用プレーンメモリである。左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがある。ここでの“グラフィクス”とは、これらグラフィクスプレーンに格納されたARGB形式の画素データによって表現される表示内容のことであり、フォントを用いてテキストコードを展開することにより得られた文字、記号のビットマップや、GIF/JPEG/PNGデータをデコードすることで得られるGIF/JPEG/PNGイメージ(本明細書では“描画イメージ”という)を含む。
２.５：プレーン合成器１０５
プレーン合成器１０５は、複数のプレーンメモリのレイヤ合成を行う。プレーン合成器１０５は、左目用の出力系統と、右目用の出力系統とから構成され、左目用の出力系統と、右目用の出力系統とでそれぞれ独立して、複数のプレーンメモリ間のレイヤ合成を行う。左目用出力系統、右目用出力系統は、複数の加算器と、加算器間の結線とから構成される。左目用出力系統は、2D再生モードとで共用される。右目用出力系統は、3D再生モードにおいてのみ有効となる。この右目用出力系統において、加算器への供給源を左目用グラフィクスプレーンとした場合、グラフィクスプレーンを１プレーン構成とすることができ、加算器への供給源を右目用グラフィクスプレーンとした場合、グラフィクスプレーンを２プレーン構成とすることができる。
２.６：イメージメモリ１０６
イメージメモリ１０６は、記録媒体１００に記録されたデータ構造体のインスタンスが生成された場合、データ構造のインスタンスである描画イメージを格納しておくためのメモリである。かかる描画イメージは、ARGB形式のビットマップであり、バイトコードアプリケーションからはインスタンス変数によって指示される。3D再生モードでは、右用の描画イメージオブジェクト、左目用の描画イメージオブジェクトを個別に格納することができる。
２.７：レンダリングエンジン１０７
レンダリングエンジン１０７は、左目用グラフィクスプレーン１０４cおよび右目用グラフィクスプレーン１０４ｄに対する描画処理を行う。レンダリングエンジン１０７によるイメージ描画は、イメージメモリ１０６上の描画イメージオブジェクトを、イメージメモリ１０６からグラフィクスプレーン１０４c,１０４dにコピーすることでなされる。コピーの対象になる描画イメージオブジェクトは、インスタンス変数で指示される。
２.１０：プラットフォーム部１１０
プラットフォーム部１１０は、ROM等の不揮発性メモリに記憶された組込みプログラムと、この組込みプログラムを実行するハードウエア(MPU、レジスタ、周辺回路を含む)とから構成され、記録媒体１００に記録されたクラス構造体のインスタンスであるバイトコードアプリケーションを動作させる。
２.１１：ヒープメモリ１１１
ヒープメモリ１１１は、バイトコードアプリケーションが動作を行うためのワーク領域であり、マルチスレッド１１１aと、マルチスタック１１１bとから構成される。
２.１１.１：マルチスレッド１１１a
マルチスレッド１１１aは、バイトコードを実行する論理的な実行主体(スレッド)の集まりであり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。再生装置における物理的な実行主体がMPU唯1つであるのに対し、論理的な実行主体たるスレッドは、最大64個存在し得る。この64個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、プラットフォームの動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドによりバイトコードアプリケーションを構成するバイトコードの並列実行を行い、バイトコードアプリケーションの高速化を図ることもできる。記録媒体からロードされるバイトコードアプリケーションやjava.awt.GraphicsやHAVi等のレジデント型のバイトコードアプリケーションを構成するバイトコードも、かかる並列実行に供される。
２.１１.２：マルチスタック１１１b
マルチスタック１１１bは、複数のスレッドのそれぞれと1対1の比率で存在しているスタックの集まりであり、各スタックは、プログラムカウンタと、1つ以上のフレームとをその内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する1回のコールに対して割り当てられたスタック式の領域であり、その1回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック”とからなる。フレームは、コールが1回なされる度にスタックに積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、1つ積み上げられる。
２.１２：バイトコードインタプリタ１１２
バイトコードインタプリタ１１２は、スレッドに割り当てられたバイトコードをネィティブコードに変換して、MPUに実行させる。バイトコードインタプリタ１１２は、バイトコードアプリケーションをマルチスレッドとして処理する。
２.１３：クラスローダ１１３
クラスローダ１１３は、記録媒体１００に記録されたアプリケーションのクラス構造体のインスタンスをヒープメモリ１１１に生成することにより、バイトコードアプリケーションのロードを行う。
２.１４：アプリケーションマネージャ１１４
アプリケーションマネージャ１１４は、アプリケーション管理テーブルに基づき、バイトコードアプリケーションの正当性を検証した上で、バイトコードアプリケーションを起動したりバイトコードアプリケーションを終了したりする等、バイトコードアプリケーションのアプリケーションシグナリングを行う。
２.１５：描画部１１５
描画部１１５は、プラットフォーム部で動作しているバイトコードアプリケーションに対して、各種機能を提供する組込み機器用のミドルウェアプログラムである。このミドルウェアプログラムが実装しているパッケージは、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたコピー・ペースト等の描画処理を、レンダリングエンジン１０７を通じて左目用グラフィクスプレーン１０４cおよび右目用グラフィクスプレーン１０４dに対して行うライブラリを含む。バイトコードアプリケーションはこれらの描画処理の要求を描画部に連続的に発行することで、様々なグラフィクス描画処理を実現する。
以下、これらの構成要素の処理内容を、参考図を交えてより更に詳しく説明する。
３：シャッター眼鏡５００による立体視映像の視聴
図３は、ビデオプレーン１０４a,１０４bに格納されたピクチャデータが、シャッター眼鏡５００を着用したユーザによってどのように見えるかを示す。
図中の矢印vw1は、右目瞳孔入射期間における視点への映像入力を示し、図中の矢印vw2は、左目瞳孔入射期間における視点への映像入力を示す。右目瞳孔入射期間では、矢印vw1に示すように、右目用ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの左目に入射する。左目瞳孔入射期間では、この矢印vw2に示すように、左目用ビデオプレーンの格納内容がシャッター眼鏡５００を通じてユーザの左目に入射する。こうしたシャッターの切り替えによって、ビデオストリームの立体視再生が可能になる。本図において、字幕、音声、特典といった文字列が付加された3つのボタン部材からなるメニューは、グラフィクスプレーンに格納されているグラフィクスによって構成される。このように、立体視再生の対象となるのは、ビデオに限られない。グラフィクスから構成されるメニューも立体視の対象になる。
以上が、シャッター眼鏡５００を着用することによる立体視映像の視聴である。続いて、グラフィクスプレーンの詳細について説明する。
次に、グラフィクスプレーン１０４c、１０４dにおけるコンフィグレーション設定について説明する。かかるコンフィグレーションには、2プレーン構成と、1プレーン構成とがある。
４.１：2プレーン構成
2プレーン構成とは、再生装置が3D再生モードである場合に、バイトコードアプリケーションが描画したグラフィクスを3D-LRモードで再生するためのプレーン構成である。3D-LRモードとは、左目用グラフィクスを左目用グラフィクスプレーンに書き込み、右目用グラフィクスを右目用グラフィクスプレーンに書き込むことで、立体視効果を作成するという再生モードである。
４.２：1プレーン構成
1プレーン構成とは、再生装置が3D再生モードである場合に、バイトコードアプリケーションが描画したグラフィクスを1plane＋Offsetモードで再生するためのプレーン構成である。1plane＋Offsetモードとは、左目瞳孔入射期間及び右目瞳孔入射期間のそれぞれにおいて、プレーンメモリにおけるライン単位の画素の座標を、左方向又は右方向にシフトさせ、右目視線及び左目視線の結像点を手前方向、又は、奥行方向に変位させることで奥行き感を変化させる再生モードである。具体的には、左目瞳孔入射期間で左方向、右目瞳孔入射期間で右方向に、画素座標を変化させれば、両目の視線の結像点は手前になり、左目瞳孔入射期間で右方向、右目瞳孔入射期間で左方向に、画素座標を変化させれば、両目の視線の結像点は手前になる。
かかるプレーンシフトでは、立体視のためのプレーンメモリが1プレーンで足りるので、簡易に立体視映像を作り出すのに最適である。このプレーンシフトでは、平面的な映像が手前に来たり、奥に引込んだりするという立体視映像を産み出すに過ぎないから、メニューや字幕の立体視効果には適しているものの、キャラクターや物体の立体視効果の実現にはやや物足りない。キャラクターの顔のくぼみや凹凸等が再現できないからである。
再生対象となるビデオストリームがベースビュービデオストリーム及びディペンデントビュービデオストリームの組みであり、再生装置が3D再生モードに設定されたとしても、グラフィクスプレーンのコンフィグレーションは、原則として1プレーン構成となる。バイトコードアプリケーションがコンフィグレーション設定要求を行い、グラフィクスプレーンのコンフィグレーションを2プレーン構成に切り替えた場合のみ、2プレーン構成に切り替えられる。
記録媒体に右目用描画イメージのデータ構造、左目用描画イメージのデータ構造が記録されていて、バイトコードアプリケーションが、これらを用いて、画像やボタン部材の立体視再生を実現しようとする場合、バイトコードアプリケーションは、描画に先立ちコンフィグレーション設定要求を行い、グラフィクスプレーンを２プレーン構成に設定しておく必要がある。
４：描画部１１６の機能構成
上述したような描画部１１６は、これらの描画要求、コンフィグレーション設定要求を処理するための構成要素であり、ソフトウェアの機能的な観点からすれば、描画部の内部構成は、図４のように表現される。図４は、描画部１１６の機能的な構成を示すブロック図である。第１段目は、図２の内部構成におけるソフトウェアのレイヤ構成であり、第２段目は、図２の内部構成におけるプレーンメモリのレイヤ構成と、右目用出力系統、左目用出力系統とを示す。第３段目は、右目映像、左目映像を示す。
第１段目のレイヤモデルにおいてハッチングを付したものは、描画部の構成要素となるものを示す。本図でハッチングを付して示すように、描画部は、レジデント型のバイトコードアプリケーションである『org.havi.ui』、『java.awt.Graphics』と、再生装置のネィティブコードで記述された組込みプログラムである『デバイスドライバ』とから構成される。以下、これら描画部の構成要素について説明する。
４.１：org.havi.uiモジュール
『org.havi.ui』は、左目用グラフィクスプレーン、右目用グラフィクスプレーンをHAViグラフィクスデバイスとして管理する。
４.２：java.awt.Graphicsモジュール
『java.awt.Graphicsモジュール』は、改良が施されたjava.awt.Graphicsのモジュールである。java.awt(Abstract Window Toolkit)とは、GUIを構築するための機能をまとめた基本ライブラリであり、コンポーネントと、コンテナという2つのクラスをもつ。コンポーネントがJavaアプリケーションの描画領域を提供し、コンテナが複数のコンポーネントを配置・格納する機能を提供する。どの点に改良が加えられたかというと、１プレーンから２プレーンへのグラフィクスプレーン切り替えが命じられた場合に、特殊な処理を行う点が、通常のjava.awt.Graphicsと異なる。グラフィクスプレーンが２プレーンになっている間は、2Dグラフィクス描画を行わないことを除き、通常のjava.awt.Graphicsと同じである。このjava.awt.Graphicsによる特殊な処理とは、2Dグラフィクス描画要求の無視である。第１実施形態では、この“無視”の一例として、既にスタックに蓄積されている2Dグラフィクス描画要求のコールコードを全て消去して、Exceptionを要求元のスレッドに返すというものを採用する。かかる無視を行った後は、2プレーンから1プレーンへのグラフィクスプレーン切り替えが命じられ、右目用の出力系統が解放されるまで、2Dグラフィクスの描画を行わない。
４.３：デバイスドライバ１１６
デバイスドライバ１１６は、java.awt.Graphics、org.havi.uiの要求に従い、左目用グラフィクスプレーン、右目用グラフィクスプレーンにグラフィクスを書き込む。
１プレーンから２プレーンへのグラフィクスプレーン切り替えにあたっては、左目用グラフィクスプレーンに格納されている１画面分の画素データを右目用グラフィクスプレーンにコピーするという処理を行い、出力系統の切り替えを行う。図中の矢印dr1,dr2は、デバイスドライバによる左目用グラフィクスプレーン、右目用グラフィクスプレーンへのアクセスを象徴的に現している。
このアクセスによって左目用グラフィクスプレーンの格納内容が右目用グラフィクスプレーンにコピーされる。矢印cp1は、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーを示す。以上のコピー後に、右目用出力系統が追加されることで、図４の第３段目に示すように、グラフィクスが合成された右目画像、左目画像が再生装置から出力されることになる。
４.４：StereoGraphicsモジュール
『StereoGraphicsモジュール』は、3Dグラフィクス描画の要求を受け付けて、グラフィクスの描画を行うために、特別に再生装置に実装されたレジデント型のバイトコードアプリケーションである。１プレーンから２プレーンへのグラフィクスプレーン切り替えが命じられ場合のみ起動され、グラフィクスプレーンが2プレーンから1プレーンに切り替えられた場合、直ちに動作を終える。
本実施形態で最も重要なのは、レイヤモデルの説明で述べた「右目用出力系統の追加」、「プレーン間コピー」、「2Dグラフィクス描画要求の無視」という3つの手順である。以下、これらの手順と、この手順を実現するための構成要素について説明する。
右目用出力系統の追加を実現するのはプレーン合成器１０５である。次に、合成部の内部構成について説明する。
５：プレーン合成器１０５の内部構成
図５（ａ）は、プレーンメモリのレイヤ構成と、合成部の構成要素とを示す。合成部は、プレーンメモリのレイヤ構成の左目用出力系統に設けられた加算器４１と、プレーンメモリのレイヤ構成の右目用出力系統に設けられた加算器４２と、スイッチ４３とを構成要素とする。
５.１：加算器４１
加算器４１は、左目用出力系統において、左目用ビデオプレーンの格納内容と、左目用グラフィクスプレーンの格納内容との合成を行う。
５.２：加算器４２
加算器４２は、右目用出力系統において、右目用ビデオプレーンの格納内容と、左目用グラフィクスプレーン及び右目用グラフィクスプレーンのどちらか一方との合成を行う。これら加算器４１、４２による格納内容の合成は、ビデオプレーン及びグラフィクスプレーンに格納されている画素データの画素値を重畳するというものである。画素値の重畳は、プレーンメモリのライン単位の画素値に透過率αを重みとして乗じるとともに、その下位階層に位置するプレーンメモリのライン単位の画素値に（１−透過率α）という重みを乗じて これら輝度の重み付けがなされた画素値同士を加算し、加算結果を、その階層におけるライン単位の画素の画素値とする処理である。加算器４１、４２は、プレーンメモリのライン画素の画素データを格納するラインメモリと、ライン画素における個々の画素値に等価率を乗算するための乗算部とを含み、ライン画素における個々の画素について、上述したような加算を行う。
５.３：スイッチ４３
スイッチ４３は、加算器４２に対する画素データの供給源を、左目用グラフィクスプレーン及び右目用グラフィクスプレーンの何れかに切り替える。加算器４２に対する画素データの供給源を左目用グラフィクスプレーンとした場合、グラフィクスプレーンのコンフィグレーションは、“１プレーン構成”になり、画素データの供給源を右目用グラフィクスプレーンとした場合、コンフィグレーションは、“２プレーン構成”となる。
５.４：合成モードのバリエーション
５.４.１：合成モード
2D再生モードにおける出力系統は、図５（ｂ）のもので固定される。これに対して3D再生モードでは、右目用の出力系統と、左目用の出力系統とがあり、左目用の出力系統では、加算器へのデータ供給源を右目用のプレーンメモリとするか、左目用のプレーンメモリとするかによって、図５（ｃ）〜（ｄ）に示す2通りのバリエーションが存在する。つまり、2D再生モードでは出力系統にバリエーションが存在しないが、3D再生モードにおいてプレーン合成器２０は、2通りの出力系統の切り替えを実現することにより、2つの合成モード(合成モードA、合成モードB)を有することになる。以下、それぞれのモードについて、図５（ｃ）〜（ｄ）のそれぞれを用いて説明する。
図５（ｃ）は、グラフィクスプレーン、ビデオプレーンの比率を、2:2とする出力系統による合成モード(合成モードA)を示す。グラフィクスプレーンのプレーン数は何れも、２プレーンであるので、加算器４２への供給源は右目用グラフィクスプレーンになっている。
５.４.２：合成モードB
図５（ｄ）は、グラフィクスプレーン、ビデオプレーンの比率を、1:2とする出力系統による合成モード(合成モードBという)を示す。合成モードBでは、グラフィクスプレーンは左目用だけが使用される。その結果、グラフィクスプレーンについては左右同じ映像が出力されるため、視聴者の目には平らに見えることとなる。
2D再生モードにおいて、プレーン合成器１０５には右目用出力系統が存在せず、プレーン合成器１０５は図５（ｂ）の状態になっている。しかし2D再生モードから3D再生モードへの切り替え時において、プレーン合成器１０５には右目用出力系統が追加され、プレーン合成器１０５は、図５（ｃ）又は図５（ｄ）の状態になる。このように、加算器４２及びスイッチ４３を有効状態にすることが、“右目用出力系統の追加”である。逆に、加算器４２及びスイッチ４３を無効状態にすることが、“右目用出力系統の解放”である。
続いて、プレーン間コピーの詳細について説明する。プレーン間コピーとは、左目用グラフィクスプレーンに格納されている全ての画素を、右目用グラフィクスプレーンにコピーすることを意味する。このコピー処理の前提となる、グラフィクスプレーンのプレーン構成について説明する。
６.グラフィクスプレーンの内部構成
図６は、左目用グラフィクスプレーン１０４c及び右目用グラフィクスプレーン１０４ｄの共通の内部構成を示す。解像度が1920×1080に設定されている場合、同図（ａ）に示すように、グラフィクスプレーン１０４c,１０４dは横1920×縦1080の３２ビット長の記憶素子からなる。グラフィクスプレーン１０４c,１０４dは、1920×1080の解像度で、ARGB形式8888形式により画素データを格納する。ARGB形式8888形式における各画素は、８ビットの透明度A、８ビットのR値、８ビットのG値、８ビットのB値から構成される。
６.１：画素データ
同図（ｂ）は、グラフィクスプレーン１０４c,１０４dに格納されている画素データを示す。本図に示すように、グラフィクスプレーン１０４c,１０４dに格納されているグラフィクスデータは、前景部分にあたる画素データ、背景部分にあたる画素データから構成される。ここで背景部分にあたる記憶素子には、透明色を示すA値が格納されており、この部分には、ビデオプレーンとの合成時において、グラフィクスプレーンの字幕やビデオプレーンにおける動画像が透けて見えるようになる。一方、前景部分にあたる記憶素子には、透明色以外を示すR,G,B値が格納されており、この透明色以外のR,G,B値によって、描画イメージが描かれることになる。
プレーン合成器１０５によるプレーン合成時において、透明画素にあたる部分には、他のプレーンメモリの格納内容が透けて見えるようになり、かかる透明部分の存在によって、プレーン合成が可能になる。
６.２：プレーン間コピー
プレーン間コピーについて説明する。グラフィクスプレーンを1プレーン構成から2プレーン構成に変更する場合、図６（ａ）に示した左目用グラフィクスプレーンの格納内容を、右目用グラフィクスプレーンに全てコピーせねばならない。このコピーは、左目用グラフィクスプレーンの格納内容である画素データの集まり、つまり、左目用グラフィクスプレーンに格納されている1920×1080のARGB形式の画素データを、全て右目用グラフィクスプレーンにコピーするというものである。何故なら、1プレーン構成から2プレーン構成に切り替えられた際、左目用グラフィクスプレーンには有効な画素が存在するのに対し、右目用グラフィクスプレーンには画素が全く存在せず無地の状態であると、左目−右目の視覚不一致が発生するからである。よって1プレーン構成から2プレーン構成への切り替えにあたっては、右目用グラフィクスプレーンの格納内容が再生出力に供される前に、左目用グラフィクスプレーンに存在する1920×1080の画素データの全てを、右目用グラフィクスプレーンにコピーせねばならない。対照的に、2プレーン構成から1プレーン構成への切り替え時には、このようなコピーは不要となる。2D再生モードでは、左目−右目の視覚不整合の発生を危惧しなくてもよいからである。よって、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのコピーは、グラフィクスプレーンのコンフィグレーションを、1プレーン構成から2プレーン構成に変更するにあたっての必須の処理となる。
７：プレーン間コピーの過程
以降、プレーン間コピーの過程を、図７（ａ）〜（ｃ）を交えながら説明する。図７（ａ）は、右目用出力系統の追加がなされる前の左目用グラフィクスプレーン、右目用グラフィクスプレーンの格納内容を示す。本図において、左上に存在するメニューは、図３の立体視映像におけるメニューと同じであり、かかるメニューを構成する画素データが左目用グラフィクスプレーンに存在することがわかる。図７（ｂ）は、右目用出力系統の追加がどのようになされるかを模式的に示す。左目用グラフィクスプレーンは、1920×1080の画素データの集まりであり、これらのうち、横1920の画素は、ライン画素を構成する。図７（ｂ）の矢印cy1,cy2,cy3,cy4,cy5は、左目用グラフィクスプレーンから右目用グラフィクスプレーンへのライン画素のコピーを象徴的に示している。かかるライン画素のコピーによって、左目用グラフィクスプレーンにおける1920×1080の画素データは、そのまま右目用グラフィクスプレーンに複製されることになる。図７（ｃ）は、右目用出力系統の追加がなされた後の左目用グラフィクスプレーン、右目用グラフィクスプレーンの格納内容を示す。図７（ｃ）において、左目用グラフィクスプレーン、右目用グラフィクスプレーンのそれぞれにメニューが存在するため、左目右目の視覚の不一致は発生し得ない。
８：2Dグラフィクス描画要求の無視
以上がプレーン間コピーと、グラフィクスプレーンとについての説明である。続いて、2Dグラフィクス描画要求の無視の詳細について説明する。2Dグラフィクス描画要求の無視は、1プレーン構成から2プレーン構成への切り替え後にjava.awt.Graphicsに到達した2Dグラフィクス描画要求を無視するというものである。コンフィグレーションの切り替えでグラフィクスプレーンを2プレーン構成にする際、スタックに蓄積された2Dグラフィクス描画要求を全て消去してしまい、2Dグラフィクス描画要求を例外終了させるという積極的な処理を意味する。積極的な処理を伴う“無視”によって、java.awt.Graphicsがバイトコードアプリケーションから要求を受け取るためのスタックから、2Dグラフィクス描画要求はなくなることになる。コンフィグレーション変更要求後の2Dグラフィクス描画要求を無視するという処理は、2Dグラフィクス描画要求の“無効化”とも呼ばれる。
1プレーン構成から2プレーン構成への切り替え後に2Dグラフィクス描画要求が到達することで、どのような弊害が生じるかを図８を参照しながら説明する。図８は、1プレーン構成から2プレーン構成への切り替え後のグラフィクス更新を示す。図８では、図面の左端を時間軸の原点とし、図面の右方向を時間軸の正方向、左方向を時間軸の負方向としている。そして、この時間軸と直交する平面を、グラフィクスプレーンがなすX-Y平面としている。グラフィクスの再生時においては、この時間軸と直交するX-Y平面における座標が表示座標として与えられる。以降の説明において、特に断らない限り、ビデオストリームの時間軸やX-Y座標系の表記には、本図と同様の表記を用いる。グラフィクス更新のための描画要求が、2Dグラフィクス描画要求であるか、3Dグラフィクス描画要求であるかによって、図８（ａ）のケース、図８（ｂ）のケースが発生する。
８.２：2プレーン構成への切り替え後における3Dグラフィクス描画要求による更新
図８（ａ）のケースは、グラフィクスプレーンのコンフィグレーションを、1プレーン構成から2プレーン構成に切り替えた後に、3Dグラフィクス描画要求によるグラフィクス更新がなされたケースを示す。この図８（ａ）のケースでは、図のメニューで提示された音声、字幕、特典のうち、音声が選択されたことで音声の言語として、英語、中国語、日本語の選択を受け付けるメニューが提示される表示例を想定している。本図において、時点u1では、左目用グラフィクスプレーンにメニューが存在する。時点u2では、コンフィグレーションが1プレーン構成から2プレーン構成に切り替えられたことで、プレーン間コピーが実行され、左目用グラフィクスプレーン、右目用グラフィクスプレーンの双方にメニューが存在する。時点u3では、メニューの確定操作に応じて3Dグラフィクス描画要求が発行されたことで、左目用グラフィクスプレーン、右目用グラフィクスプレーンの格納内容が更新された状態を示す。
８.３：2プレーン構成への切り替え後における2Dグラフィクス描画要求による更新
図８（ｂ）は、グラフィクスプレーンのコンフィグレーションを、1プレーン構成から2プレーン構成に切り替えた後に、2Dグラフィクス描画要求によるグラフィクス更新がなされたケースを示す。この図８（ｂ）のケースにおいて、時点u1では、左目用グラフィクスプレーンにメニューが存在する。時点u2では、コンフィグレーションが1プレーン構成から2プレーン構成に切り替えられたことで、プレーン間コピーが実行され、左目用グラフィクスプレーン、右目用グラフィクスプレーンの双方にメニューが存在する。時点u3では、メニューの確定操作に応じて2Dグラフィクス描画要求が発行されたことで、左目用グラフィクスプレーンの格納内容のみが更新された状態を示す。左目用グラフィクスプレーンの格納内容が更新されたのに対して、右目用グラフィクスプレーンの格納内容は未更新であるから、左目、右目の視覚の不整合が生じている。
無視の対象となる2Dグラフィクス描画要求がどのようなものか、3Dグラフィクス描画要求、コンフィグレーション設定要求がどのようなものかについて説明する。
『2Dグラフィクス描画要求』は、第１引数、第２引数の設定がなされたGraphics#drawImage APIのコールコードとして実現される。第１引数、第２引数、第３引数がx1,y1,x2,y2,image1である場合、Graphics#drawImage(x1,y1,x2,y2,image1);というAPIコールのコードをバイトコードアプリケーション中に記述することで2Dグラフィクス描画要求はなされる。
『3Dグラフィクス描画要求』は、第１引数、第２引数、第３引数、第４引数、第５引数の設定がなされたStereoGraphics#drawImage APIのコールコードのことである。引数がx1,y1,x2,y2,image1,x3,y3,x4,y4,image2である場合、StereoGraphics#drawImage(x1,y1,x2,y2,image1,x3,y3,x4,y4,image2);というAPIコールのコードをバイトコードアプリケーション中に記述することで3Dグラフィクス描画要求はなされる。
『コンフィグレーション設定要求』は、第１引数、第２引数の設定がなされたSetConfiguraionAPIのコールコードのことである。引数が第１引数、第２引数が、width×height,number1である場合、setConfiguraion(width×height,number1);というAPIコールのコードをバイトコードアプリケーション中に記述することでグラフィクスプレーンメモリのコンフィグレーション切り替えを要求することができる。
これら2Dグラフィクス描画要求であるGraphics#drawImage APIのコールコード、3Dグラフィクス描画要求であるStereoGraphics#drawImageLRのコールコードは、バイトコードアプリケーションを構成するスレッドによってスタックに蓄積され、描画部の構成要素であるjava.awt.Graphics、StereoGraphicsに供給される。
これらGraphics#drawImage API、StereoGraphics#drawImage API、setConfiguraion APIといったAPIをコールする場合、これらのコールに対応するフレームがマルチスタックの個々のスレッドに対応するスタック上に積み上げられる。そしてこれらのスタックにおけるフレームのオペランドスタックには、Graphics#drawImage APIコールの引数、StereoGraphics#drawImage APIコールの引数、setConfiguraionAPIコールの引数が積み上げられることになる。
図９は、描画イメージの書き込みに用いられるアプリケーションプログラムインターフェイスを示す。
９.１：java.awt.Graphics#drawImageメソッド
図９（ａ）におけるjava.awt.Graphics#drawImageメソッドは、第１引数の位置で指定された描画位置に、第２引数で指定された描画イメージを書き込む機能を呼び出すためのAPIである。正確には、指定された描画イメージを矩形にトリミングしてから描画するための、矩形位置を指定する引数を渡すことも可能であるが、ここでは省略する。
９.２：StereoGraphics#drawImageメソッド
図９（ｂ）におけるStereoGraphics#drawImageメソッドは、左目用グラフィクスプレーンにおいて、第１引数の位置で指定された矩形範囲に、第２引数で指定された描画イメージを書き込み、左目用グラフィクスプレーンにおいて、第３引数の位置で指定された矩形範囲に、第４引数で指定された描画イメージを書き込む機能を呼び出すAPIである。
矩形範囲は、描画先となる矩形領域の左上の座標（x１，y１）と右下の座標（x２，y２）の組み合わせで表現される。また、描画イメージオブジェクトとしては、GIF/JPEG/PNG形式のデータ構造から生成したインスタンスの他に、BufferedImageを用いることができる。
前述したようにjava.awt.Graphics#drawImageメソッドではイメージコピー処理が規定されているが、この処理では１つの矩形領域のコピーしか指定することができない。一方、StereoGraphics#drawImageメソッドによる左右同時イメージコピーは、描画位置と描画イメージとのペアを含む。描画先プレーンはそれぞれ左目用グラフィクスプレーン１０４cと右目用グラフィクスプレーン１０５dに固定されているものとし、グラフィクスプレーンの指定は、StereoGraphics#drawImageメソッドの引数から除外されている。
１０：描画要求の具体例
図１０は、図９のアプリケーションプログラムインターフェイスを用いて規定することができる描画要求の具体例である。
１０.１：java.awt.Graphics#drawImageによる描画要求の具体例
図１０（ａ）は、APIの種別がjava.awt.Graphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを表形式で示す。java.awt.Graphics#drawImageメソッドの場合、描画すべき矩形範囲は、(X1=50,Y1=100),(X2=250,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の"ビットマップイメージ１"とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
１０.２：StereoGraphics#drawImageによる描画要求の具体例
同図（ｂ）は、APIの種別がStereoGraphics#drawImageメソッドである場合、描画すべき矩形範囲、描画イメージが、具体的にどのようなものに設定されるかを示す図である。APIの種別がStereoGraphics#drawImageメソッドである場合、左目用グラフィクスプレーンにおける描画すべき矩形範囲は、(X1=50,Y1=100),(X2=255,Y2=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられる変数名を用いて表現される。本図の"ビットマップイメージ１"とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
右目用グラフィクスプレーンにおける描画すべき矩形範囲は、(X3=55,Y3=100),(X4=255,Y4=170)という、プレーン座標系におけるXY座標で表現される。また、描画イメージは、データ構造体のインスタンスに与えられるインスタンス変数を用いて表現される。本図の"ビットマップイメージ２"とは、横200画素×高さ70画素から構成されるインスタンスに与えられたインスタンス変数である。
１１.１：2Dグラフィクス描画要求によるグラフィクスプレーンへの書き込み
図１１（ａ）は、図１０（ａ）のように引数が指定された場合、Graphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。図中の手前側は、描画イメージを格納したイメージメモリを示す。図中の奥手側は、互いに重ね合わされた左目用グラフィクスプレーン及び左目用ビデオプレーンの組み、右目用グラフィクスプレーン及び右目用ビデオプレーンの組みを示す。
図１１（ａ）によると、左目用グラフィクスプレーンのみに、グラフィクスが書き込まれており、左目用のグラフィクスが更新されているものの、右目用グラフィクスプレーンにはグラフィクスが未書込みであるから、2Dグラフィクス描画要求により左目用グラフィクスプレーンのみが更新されている。1プレーン構成から2プレーン構成に切り替えた後の2Dグラフィクス描画要求によって左目−右目の視覚の不整合が生じていることがわかる。
１１.２：StereoGraphics#drawImageによるグラフィクスプレーンへの書き込み
図１１（ｂ）は、図１０（ｂ）のように引数が指定された場合、StereoGraphics#drawImageの呼び出しによって、どのような書き込みが実行されるかを模式的に示す。図中の手前側は、描画イメージを格納したイメージメモリを示す。図中の奥手側は、互いに重ね合わされた左目用グラフィクスプレーン及び左目用ビデオプレーンの組み、右目用グラフィクスプレーン及び右目用ビデオプレーンの組みを示す。この左目用グラフィクスプレーン、右目用グラフィクスプレーンに、図１０（ｂ）で描画すべき矩形範囲として示した、具体的なXY座標をプロットしている。
本図によると、左右のグラフィクスプレーンでは、X座標がわずかにずれているため、描画イメージがそれぞれ横方向に少しずれた位置にコピーされることになる。図中の矢印ig1,ig2は、左右イメージメモリから左右のイメージメモリへのコピーを示す。この場合はR画像の描画位置がL画像の描画位置よりも５ピクセル分右にずれているため、視聴者にはディスプレイの奥に引っ込んでいるような表示として感じられることになる。左右それぞれの視点向けに用意した異なるビットマップを指定しているので立体視としての効果は向上しているが、描画イメージとして同一のビットマップを用いることもできる。
以上のような視覚の不整合を回避するためにも、2プレーン構成においては、2Dグラフィクス描画要求を無視せねばならない。
以上の1プレーン構成から2プレーン構成に切り替える際の2Dグラフィクス描画要求の無視、プレーン間コピー、右目用出力系統の追加の時間的関係は、(1)2Dグラフィクス描画要求の無視→(2）プレーン間コピー→(3)右目用出力系統の追加というものであり、右目用出力系統の追加の実行後、3Dグラフィクス描画要求を受け入れるというものである。一方、2プレーン構成から1プレーン構成に切り替える際の時間的関係は、3Dグラフィクス描画要求の受け入れを禁止してから、右目用出力系統を解放し、2Dグラフィクス描画要求を受け入れるというものになる。これらの手順の時間的関係を表したのが、図１２のタイミングチャートである。
１２：各構成要素の動作の時間的関係
図１２は、バイトコードアプリケーション、StereoGraphics、java.awt.Graphics、デバイスドライバによる動作の時間的な関係を、ビデオストリーム時間軸に沿って示したタイミングチャートである。第１段目は、バイトコードアプリケーションを示し、第２段目は、StereoGraphicsを示す。第３段目は、java.awt.Graphicsを示し、第４段目は、デバイスドライバを示す。第５段目は、ビデオストリームの時間軸において1/23.976秒、1/59.94秒というフレーム期間で連続的に表示される複数のピクチャを示す。第６段目は、ビデオストリームの時間軸を示す。
１２.１：1プレーンから2プレーンへのコンフィグレーション切り替え
図中の星記号１が付された矢印は、第２引数を“２プレーン”としたsetConfiguraionのコールを象徴的に現している。丸記号１、２、３、４は、引数を２プレーンとしたsetConfiguraionのコール後に、どのような順序で、java.awt.Graphicsによる無効化、デバイスドライバによるコピー、StereoGraphicsによる3Dグラフィクス描画要求の受入れが実行されるかを示す。この丸記号の番号の通り、第１に、java.awt.GraphicsによるGraphics#drawImageの無効化がなされ、第２に、デバイスドライバによるグラフィクスプレーンのコピーが、第３に、デバイスドライバによる右目用出力系統の出力がなされていることがわかる。これらの処理が完了した後、第４に、StereoGraphicsが起動され、StereoGraphics#drawImageの受け入れが開始されていることがわかる。
第２段目における無効化の開始時点t0は、setConfiguraion APIのコールがなされた時点の直後である。プレーンメモリのコピーの開始時点t1は、2Dグラフィクス描画要求の無効化が完了した時点直後である。仮に、コピーの際中に、左目用グラフィクスプレーンの内容が、java.awt.Graphicsによって書き換えられれば、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとで格納内容の不一致が生じ、両眼視覚の不一致が生じる。しかし、本図に示すように、java.awt.Graphicsが2Dグラフィクス描画の要求を全て無視してから、グラフィクスプレーンのコピーを行うので、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとの格納内容の不一致は生じ得ない。
以上のように、デバイスドライバの処理のうち、特徴的であるのは、2Dグラフィクス描画要求の無視を完了してから、上記コピーを行う点にある。つまり、コピーの際中に、左目用グラフィクスプレーンの内容が、java.awt.Graphicsによって書き換えられれば、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとで格納内容の不一致が生じ、両眼視覚の不一致が生じる。しかし、java.awt.Graphicsが2Dグラフィクス描画要求を全てスタックから消滅させてから、デバイスドライバがグラフィクスプレーンのコピーを行えば、格納内容の不一致は生じ得ない。
右目用出力系統の追加時点t2は、プレーンコピーが完了した時点直後である。第５段目では、この出力系統の切り替え直後に、映像出力が平面視から立体視に切り替えられていることがわかる。
StereoGraphicsの起動時点t3は、右目用出力系統の追加時点直後である。StereoGraphicsが起動されたため、この時点t3以降に、立体視グラフィクスの更新が可能になる。以上のタイミングチャートからも明らかなように、setConfiguraionのコール後、直ちに3Dグラフィクス描画要求によるStereoGraphics#drawImageの描画が可能になる訳ではない。2Dグラフィクス描画要求の無視、グラフィクスプレーンのコピー、出力系統の切り替えといった一連の処理を実行するためのタイムラグが発生する。
１２.２：2プレーンから1プレーンへのコンフィグレーション切り替え
図中の星記号２が付された矢印は、第２引数を“１プレーン”としたsetConfiguraionのコールを象徴的に現している。丸記号５、６、７は、引数を１プレーンとしたSetConfiguraionのコール後に、どのような順序で、java.awt.Graphicsによる無効化、デバイスドライバによるコピー、StereoGraphicsによる3Dグラフィクス描画要求の受入れが実行されるかを示す。この丸記号の番号の通り、第１に、StereoGraphicsの動作が終了し、第２に、出力系統を左目用の出力系統のみになり、第３に、java.awt.GraphicsがGraphics#drawImageのコールを受け入れを開始していることがわかる。
第２段目におけるStereoGraphicsの終了時点t4は、setConfiguraionコールがなされた時点の直後である。StereoGraphics#drawImageに応じて3Dグラフィクス描画を行うStereoGraphicsは、setConfiguraionのコールによって、１プレーンから２プレーンへのグラフィクスプレーン切り替えが命じられた場合のみ起動され、再度のsetConfiguraionのコールによってグラフィクスプレーンが2プレーンから1プレーンに切り替えられた場合に、直ちに動作を終えるので、その動作期間は、非常に制限されている。よって、2D再生モードにStereoGraphicsが動作することによる不具合が発生することはない。
第４段目における右目用出力系統の解放時点t4は、StereoGraphicsの動作が終了した時点直後である。第５段目では、この出力系統の切り替え直後に、映像出力が平面視から立体視に切り替えられていることがわかる。
第３段目におけるGraphics#drawImageの受け付け時点t5は、２プレーンから１プレーンへの出力系統の完了した時点の直後である。java.awt.Graphicsが2Dグラフィクス描画の要求を受け付けるため、この時点以降に、2Dグラフィクスの更新が可能になる。
コピーの実行中や出力系統の切替え中には、グラフィクスプレーンの格納内容を出力に供しないので、再生装置からの出力内容が正しいものであることが保障される。以上がjava.awt.Graphics、デバイスドライバ、StereoGraphicsの時間的関係についての説明である。
１３：対比説明
再生装置の処理で最も特徴的なものは、2Dグラフィクス描画の無効化である。この無効化を実行するのとしないのとで、再生装置によって再生される立体視映像がどう違うのかの対比説明を行う。この対比説明にあたっては、図１３のような事例を題材に選ぶ。
１３.１：想定する事例
図１３（ａ）は、コンテンツ制作者が理想的であると考えているグラフィクスの更新の過程である。本図におけるaaaは、図３に示した音声、字幕、特典の選択を受け付けるメニューを略記したものであり、bbbは、図７に示した英語、中国語、日本語の選択を受け付けるメニューを略記したものである。この更新の過程は、４つのフレームf,f+1,f+2,f+3のうち、フレームfにおいて、Graphics#drawImage APIのコールによってaaaを書き込み、フレームf+1において、Graphics#drawImage APIのコールによってbbbを書き込み、フレームf+2において、グラフィクスプレーンを２プレーン化し、フレームf+3において2プレーン化されたグラフィクスプレーンのそれぞれにbbbを書き込むというものである。かかるグラフィクス更新を実現するため、フレームf,f+1ではGraphics#drawImage、フレームf+2ではsetConfiguraion、フレームf+3ではStereoGraphics#drawImageを発行しようとする。
バイトコードアプリケーションにおいて、Graphics#drawImageのコールコード、setConfiguraionのコールコード、StereoGraphics#drawImageのコールコードは、2Dグラフィクス描画要求→setConfiguraion→StereoGraphics#drawImageという順序で並んでいたが、GraphicsDrawImageのコールコードに該当するバイトコード、setConfiguraionのコールコードに該当するバイトコード、StereoGraphics#drawImageのコールコードに該当するバイトコードが、マルチスレッドにおける3つのスレッドによって並列実行されたため、これらのコールコードがsetConfiguraion→Graphics#drawImage→StereoGraphics#drawImageという順序で発行されたものとする。
図１３（ｂ）は、図１３（ａ）のグラフィクス更新のためにバイトコードアプリケーションが発した3つのコールコードを示す。本図の第２段目は、スレッド間通信のためのスタックであり、この中に、setConfiguraion、Graphics#drawImage、StereoGraphics#drawImageという順序に並べ替えられた3つのコードが存在する。本図の第１段目は、バイトコードアプリケーションを示し、第４段目は、プレーンメモリを示す。第３段目は、描画部の構成要素であるjava.awt.Graphics、StereoGraphics、デバイスドライバを示す。
１４.１：ケース１（無効化を行ってからプレーン構成の切り替えを実行する場合）
第１に、無効化を実行せずにプレーン構成の切り替えを実行しようとするケースを述べる。
図１４は、無効化を実行せずにプレーン構成の切り替えを実行しようとする場合、スタックにおける複数のコードが、どのように処理されるかを連続写真的な表記で示す図である。スタックにおけるコードが処理される過程は、４つのステージからなり、図１４（ａ）は、最初のステージ、図１４（ｂ）は2つ目のステージ、図１４（ｃ）は3つ目のステージ、図１４（ｄ）は4つ目のステージを示す。これらの図１４（ａ）〜（ｄ）では、前の図と同じ表記で、スタック、java.awt.Graphics、StereoGraphics、デバイスドライバ、プレーンメモリを描いている。
図１４（ａ）図中の丸記号２が付された矢印は、プレーンメモリのコピーを象徴的に現している。図１４（ｂ）における丸記号３が付された矢印は、出力系統の切り替えを象徴的に現している。図１４（ｃ）における図中の丸記号８が付された矢印は、Graphics#drawImageによるbbbの書き込みを象徴的に現している。図１４（ｄ）における丸記号９が付された矢印は、StereoGraphics#drawImageによるbbbの書き込みを象徴的に現している。
１５.ケース１で再生される立体視映像
図１５は、図１４（ｃ）の書き込みによって、再生されることになる立体視映像を示す。図１４（ｃ）では右目グラフィクスプレーンと、左目グラフィクスプレーンとが異なるものになったため、右目用の映像と、左目用の映像とで不一致が生じている。右目−左目の視覚の不一致は、StereoGraphicsによる左目用グラフィクスプレーン、右目用グラフィクスプレーンの更新がなされるまで画面上に残るので、かかる不一致がユーザに大きな不快感を与える。
１６.ケース２（無効化を行ってからモード切り替えを実行するケース）
図１６は、無効化を行ってからモード切り替えを実行しようとする場合、スタックにおける複数のAPIコールコードが、どのように処理されるかを連続写真的な表記で示す。スタックにおけるコードが処理される過程は、図１４と同様、４つのステージからなり、図１６（ａ）は、最初のステージ、図１６（ｂ）は2つ目のステージ、図１６（ｃ）は3つ目のステージ、図１６（ｄ）は4つ目のステージを示す。これらの図１６（ａ）〜（ｄ）では、図１３（ｂ）と同じ表記で、スタック、java.awt.Graphics、StereoGraphics、デバイスドライバ、プレーンメモリを描いている。
図１６（ａ）において、丸記号１が付された矢印は、無効化による2Dグラフィクス描画要求APIのコールコードの消去を示す。図中の×印は、スタックに格納された3つのコールコードのうち、bbbを書き込む旨のGraphics#drawImageが消去されることで、後続するsetConfiguraionのコールコードの順位が1つ繰り上がっていることを模式的に示している。
図１６（ｂ）において、丸記号２が付された矢印は、プレーンメモリのコピーを象徴的に現している。図１６（ａ）java.awt.Graphicsが2Dグラフィクス描画の要求が全てスタックから消滅させてから、図１６（ｂ）におけるグラフィクスプレーンのコピーを行っているので、左目及び右目の視覚上の不一致は生じ得ない。図１６（ｃ）において、丸記号３が付された矢印は、右目用出力系統の追加を象徴的に現している。図１６（ｄ）において、丸記号９が付された矢印は、StereoGraphics#drawImageによるbbbの書き込みを象徴的に現している。
１７.ケース２で再生される立体視映像
図１７は、図１６（ｄ）の書き込みによって、再生されることになる立体視映像を示す。右目グラフィクスプレーンと、左目グラフィクスプレーンとが異なるため、不一致が生じない。
以上のように本実施形態によれば、グラフィクスプレーンのコピーに先立ち、2Dグラフィクス描画要求を無効化するので、左目用グラフィクスプレーンからグラフィクスプレーンへの画素データコピーがなれた後に、左目用グラフィクスプレーンに新たなグラフィクスが書き込まれることはない。2Dグラフィクス描画要求が遅れて、java.awt.Graphicsに到達したとしても、その2Dグラフィクス描画要求に従い、グラフィクスが表示されることはありえず、両目の視覚の不一致が生じることはない。
（第２実施形態）
第１実施形態においては、スタック上に格納された2Dグラフィクス描画要求APIのコールコードを消去することにより、2Dグラフィックス描画の無効化を実現したが、2Dグラフィクス描画要求の無視は、コンフィグレーションの切り替えでグラフィクスプレーンが2プレーン構成になっている間のみ、2Dグラフィクス描画要求を無処理でリターンするように2Dグラフィクス描画処理側を変更する、つまり、コンフィグレーション変更時における2Dグラフィクス描画要求の"一時的な無効化"をも含む。
よって本実施形態では、グラフィクスプレーンが2プレーン構成になっている間のみ、2Dグラフィクス描画要求を無処理でリターンするようにする形態の無視を、2Dグラフィックス描画禁止フラグの実装によって実現する。
2Dグラフィックス描画禁止フラグとは、2Dグラフィクス描画要求を無視するか、2Dグラフィクス描画要求を受け付けるかの選択をGraphics#drawImageに命じるためのものである。この2Dグラフィックス描画禁止フラグの追加に伴うGraphics#drawImageの改良としては、その処理部の先頭に2Dグラフィックス描画禁止フラグを参照する処理を組込む。この参照処理とは、もし2Dグラフィックス描画禁止フラグがオンの場合はGraphics#drawImageの処理を行わずに即時に例外処理（典型的には無処理）でリターンし、2Dグラフィックス描画禁止フラグがオフであればGraphics#drawImageの処理を実行するというものである。
一方のsetConfigurationの改良としては、setConfigurationがコールされて、1プレーン構成から2プレーン構成への切り替えが命じられた場合、2Dグラフィックス描画禁止フラグをオフからオンに切り替える。こうすることで、グラフィクスプレーンが2プレーン構成に設定されている間、Graphics#drawImageは、スタックにおける2Dグラフィクス描画要求を処理することなく例外終了し、その呼出元のアプリケーションにリターンする。
逆に、setConfigurationがコールされて、2プレーン構成から1プレーン構成への切り替えが命じられた場合、2Dグラフィックス描画禁止フラグをオンからオフに切り替える。こうすることで、グラフィクスプレーンが1プレーン構成に設定されている間、Graphics#drawImageは、スタックにおける2Dグラフィクス描画要求を受け入れて、2Dグラフィクスの描画を行うことになる。
以上のように本実施形態によれば、グラフィクスプレーンが2プレーン構成になっている間のみ、2Dグラフィクス描画要求を無処理でリターンするように2Dグラフィクス描画処理側を変更するという形態によって、2Dグラフィクス描画要求の無視を実現するので、2Dグラフィクス描画要求の無視を簡易な処理で実現することができる。かかる簡易化によって、2Dグラフィクス描画要求の無視の実装が簡単になる。
(第３実施形態)
第３実施形態は、本願の優先権主張の基礎出願において、願書に添付した明細書に記載されていた実施形態と実質的に同じ内容の実施形態である。
本実施形態において立体表示を行う対象映像は、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とMovieObject.bdmvの２種類のファイルが配置されている。
STREAMディレクトリには、いわばトランスポートストリーム本体となるファイルを格納しているディレクトリであり、拡張子"m２ts"が付与されたファイル（０００００１.m２ts）が存在する。
PLAYLISTディレクトリには、拡張子"mpls"が付与されたファイル（０００００１.mpls）が存在する。
CLIPINFディレクトリには、拡張子"clpi"が付与されたファイル（０００００１.clpi）が存在する。
BDJOディレクトリには、拡張子"bdjo"付与されたファイル（XXXXX.bdjo）が存在する。
JARディレクトリには、拡張子"jar"が付与されたファイル（YYYYY.jar）が存在する。
METAディレクトリには、XMLファイル（ZZZZZ.xml）が存在する。
以下、これらのファイルについて説明する。
１８.１：AVClip
先ず初めに、拡張子"m２ts"が付与されたファイルについて説明する。拡張子"m２ts"が付与されたファイルは、MPEG-TS（TransportStream）形式のデジタルAVストリームのストリームファイルであり、ビデオストリーム、１つ以上のオーディオストリーム、対話的なグラフィクスストリーム、グラフィクス字幕ストリーム等を多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分をそれぞれ示している。ストリームファイルには、2D専用のものと、2D-3D兼用のものとがある。2D専用のストリームファイルは、通常のトランスポートストリーム形式であり、2D-3D兼用のストリームファイルは、立体視インターリーブドストリームファイルのファイル形式を有する。
立体視インターリーブドストリームファイル形式とは、ベースビュービデオストリームを含むメインのトランスポートストリーム(メインTS)のエクステントと、ディペンデントビュービデオストリームを含むサブトランスポートストリーム(サブTS)のエクステントとをインターリーブ形式で交互配置したものである。
１８.２：PlayList情報
拡張子"mpls"が付与されたファイルは、プレイリスト(以下PLとも記す)情報を格納したプレイリスト情報ファイルである。「プレイリスト」とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報は、かかるプレイリストの「型」を定義する。プレイリスト情報によって定義される再生経路は、いわゆる「マルチパス」である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるTSに対して定義された再生経路(サブパス)とを束ねたものである。このマルチパスにおいてベースビュービデオストリームの再生経路を規定し、サブパスにおいてディペンデントビュービデオストリームの再生経路を規定すれば、立体視を再生するためのビデオストリームの組合せを、好適に規定することができる。
オブジェクト指向プログラミング言語ベースのアプリケーションが、このプレイリスト情報を再生するフレームワークプレーヤインスタンスの生成を命じることで、マルチパスによるAV再生を開始させることができる。フレームワークプレーヤインスタンスとは、メディアフレームワークプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。またコマンドベースのプログラムが、このプレイリスト情報を引き数で指定した再生コマンドを発行することで、マルチパスによる再生を開始することもできる。
１８.３：Clip情報
拡張子"clpi"が付与されたファイルは、ストリームファイルのそれぞれに１対１に対応するストリーム情報ファイルである。ストリーム情報ファイルは、ストリームファイルにおけるトランスポートストリーム内の任意のソースパケットに対するランダムアクセスや、他のトランスポートストリームとの途切れ無き再生を保障する。このストリーム情報ファイルを通じることにより、ストリームファイルは「AVClip」として管理されることになる。ストリーム情報ファイルは、AVClipにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置のソースパケット番号を、フレーム期間のプレゼンテーションタイムスタンプと対応付けて示す基本エントリーマップをもっているので、ストリームファイルのアクセスに先立ち、このストリーム情報ファイルをメモリにロードしておけば、アクセスしようとするストリームファイル中のトランスポートストリームがどのようなものであるのかを把握することができるので、ランダムアクセスの実行を保障することができる。ストリーム情報ファイルには、2Dストリーム情報ファイルと、3Dストリーム情報ファイルとがあり、3Dストリーム情報ファイルは、ベースビューのためのクリップ情報(クリップベース情報)と、ディペンデントビューのためのクリップ情報(クリップディペンデント情報)とを含む。
クリップベース情報は、ベースビューのためのエクステントスタートポイント情報を含み、クリップディペンデント情報は、ディペンデントビューのためのエクステントスタートポイント情報を含む。ベースビューのためのエクステントスタートポイント情報は、複数のソースパケット番号から構成される。それぞれのソースパケット番号は、メインTSにおけるエクステントの分割位置が何パケット目に存在するかを示す。ディペンデントビューのためのエクステントスタートポイント情報も複数のソースパケット番号から構成され、サブTSにおける分割位置が何パケットに存在するかを示す。これらのエクステントスタートポイント情報を用いることで、立体視インターリーブドストリームファイルは、メインTSと、サブTSとに分割されることになる。 以上のClip情報及びPL情報は、"静的シナリオ"に分類される。
１８.４：BD-Jオブジェクト
続いて、拡張子BDJOを付したファイルについて説明する。BD-ROM規格では、映像の再生中にアプリケーションプログラムを実行することによって、動的な再生制御や、再生中のユーザとのインタラクション等、映像の再生を行いながら任意の計算機処理を行わせることが可能である。BD-ROMではこのアプリケーションプラットフォーム規格としてJava（登録商標）が用いられており、BD-ROM規格上で採用されるJava（登録商標）プラットフォームは、BD-Java、あるいはBD-Jと呼ばれ、その実行アプリケーションはBD-Javaアプリ、あるいはBD-Jアプリと呼ばれる。
拡張子BDJOを付したファイルは、BD-Jオブジェクトを格納したファイルである。BD-Jオブジェクトとは、BD-Javaアプリケーションを実行する際に使用される各種の情報を含んでいる。情報の中には、再生タイトルとの関連付け、後述するJARファイルとの関連付け、PlayList情報に対する参照値、アプリケーション管理テーブルなどが含まれる。
アプリケーション管理テーブルとは、実行するBD-Jアプリケーションの詳細情報、すなわちアプリケーションの名称を示す文字列、アプリケーションに対応づけるアイコンの所在を指し示すアイコンロケータ等の情報を、アプリケーション単位ごとに記録している情報である。
１８.５：JARファイル
BD-Jアプリのプログラム情報であり、これをアーカイブした形式がJARファイルである。BD-Jアプリは、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされる、Java（登録商標）プログラムの実行時形式である１つ以上のクラスファイル、及び、プログラムの実行時に使用される各種のデータから構成される。JARファイルはこれらの情報を含んだファイル形式である。
１８.６：メタファイル
METAディレクトリに格納されたメタファイル（ZZZZZ.xml）には、ディスクに入っている映像作品に関する様々な情報が格納されている。メタファイルに格納されている情報としては、ディスクのディスク名及び画像、ディスクの作成主体者の名称の情報、各タイトルに関わるタイトル名等がある。
以上がBDMVディレクトリの説明である。
CERTIFICATEディレクトリの下には、ディスクのルート証明書のファイル(app.discroot.cert)が存在する。
これはBD-Jアプリを実行する際に、アプリケーションが改竄されていないか、及びアプリケーションの身元確認を行なうプロセス（以下、署名検証という）に用いられるデジタル証明書の情報が含まれている。
以上がBD-ROM１００についての説明である。メタファイルなど一部のファイルはBD-ROM規格では必ずしも必須とされておらず、一部のファイルが存在していなくともBD-ROM１００は映像記録媒体としてBD-ROM規格のもと再生可能である。
１９.BD-ROM再生装置の内部構成
次に本実施形態に係る再生装置２００の詳細について説明する。
図１９は、再生装置の内部構成を示すブロック図である。本図に示すように、再生装置は、BD-ROMドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、左目用ビデオプレーン５、右目用ビデオプレーン６、イメージメモリ７、イメージデコーダ８、左目用グラフィクスプレーン９、右目用グラフィクスプレーン１０、静的シナリオメモリ１１、動的シナリオメモリ１２、制御部１３、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生ライブラリ１８、グラフィクスデコーダ１９、プレーン合成器２０、UO探知モジュール２１、レンダリングエンジン２２、ネットワークインターフェース２３、ローカルストレージ２４、仮想ファイルシステム２５、オーディオデコーダ２６、リムーバブルメディア２７、左目用バックグラウンドプレーン２８、右目用バックグラウンドプレーン２９、左目用字幕プレーン３０、右目用字幕プレーン３１から構成される。第１実施形態におけるプレーンメモリのレイヤモデルは、グラフィクスプレーン−ビデオプレーンという単純なモデルを採用したが、第３実施形態では、グラフィクスプレーン−字幕プレーン−ビデオプレーン−バックグラウンドグラフィクスプレーンというモデルを再生装置の内部構成をとして採用する。
１９.１：BDドライブ１
BDドライブ１は、BD-ROMのローディング/イジェクトを行い、BD-ROMに対するアクセスを実行する。
１９.２：トラックバッファ２
トラックバッファ２は、FIFOメモリであり、BD-ROMから読み出されたACCESS UNITが先入れ先出し式に格納される。
１９.３：デマルチプレクサ３
デマルチプレクサ３は、仮想ファイルシステム２５を通じて、BD-ROMドライブ１にローディングされているBD-ROM、またはローカルストレージ２４上、またはリムーバブルメディア２７に保存されているトランスポートストリームの多重分離を行う。デマルチプレクサ３による多重分離は、TSパケットをPESパケットに変換するという変換処理を含む。多重分離によってGOPを構成するビデオフレーム、オーディオフレーム、グラフィクスストリーム、字幕ストリームが得られる。GOPを構成するビデオフレームは、ビデオデコーダ４に出力され、GOPに多重化されているオーディオフレームはオーディオデコーダ２６に出力される。同じく多重分離によって得られるグラフィクストリームは、グラフィクスデコーダ１９に出力される。
１９.４：ビデオデコーダ４
ビデオデコーダ４は、デマルチプレクサ３から出力されたビデオフレームを復号して非圧縮形式のピクチャを左目用ビデオプレーン５および右目用ビデオプレーン６に書き込む。
１９.５−６：左目用ビデオプレーン５,右目用ビデオプレーン６
左目用ビデオプレーン５および右目用ビデオプレーン６は、非圧縮形式のピクチャを格納するためのメモリであり、それぞれ左目用のビデオのピクチャ、右目用のビデオのピクチャが格納される。これらはHAViデバイスにおけるHVideoDeviceに該当する。BD-Jアプリによってビデオ再生要求命令が発行されると、ビデオデコーダ４が継続的に左目用ビデオプレーン５および右目用ビデオプレーン６を書き換えることで、立体視ビデオストリームの再生を実現することができる。
１９.７：イメージメモリ７
イメージメモリ７は、仮想ファイルシステム２５から読み出され、イメージデコーダにより展開された画像イメージを格納するバッファである。また、展開された画像イメージ以外に、BD-Jアプリによって使用される汎用的なイメージバッファとしても利用することができる。
１９.８：イメージデコーダ８
イメージデコーダ８は、圧縮状態の画像イメージを仮想ファイルシステムから読み出し、レンダリングエンジン２２が高速にコピー処理やα演算処理を行えるような状態でイメージメモリに書き込む。具体的には、例えばARGB８８８８形式で書き込む構成が挙げられる。
１９.９−１０：左目用グラフィクスプレーン９,右目用グラフィクスプレーン１０
左目用グラフィクスプレーン９および右目用グラフィクスプレーン１０は、ビデオプレーンおよび字幕プレーンの上に重畳させるべきイメージを格納するためのメモリであり、HAViデバイスにおけるHGraphicsDeviceに該当する。このグラフィクスプレーンによって、メニュー表示などを実現することが可能となる。
１９.１１：静的シナリオメモリ１１
静的シナリオメモリ１１は、カレントのPLやカレントのストリーム管理情報を格納しておくためのメモリである。カレントPLとは、仮想ファイルシステム２５から読み出すことのできるPLのうち、その時点での処理対象になっているものをいう。カレントストリーム管理情報とは、仮想ファイルシステム２５から読み出すことのできる複数ストリーム管理情報のうち、その時点での処理対象になっているものをいう。
１９.１２：動的シナリオメモリ１２
動的シナリオメモリ１２は、カレント動的シナリオを格納し、HDMVモジュール１４、BD-Jモジュール１５による処理に供されるメモリである。カレント動的シナリオとは、仮想ファイルシステム２５から読み出すことのできる複数シナリオ情報のうち、その時点での実行対象になっているものをいう。
１９.１３：制御部１３
制御部１３は、ROM、RAM、CPUからなるマイコンシステムであり、ROMには再生装置を制御するプログラムが記録されており、ROM内のプログラムがCPUに読み込まれ、プログラムとハードウエア資源とが協動することにより、HDMVモジュール１４、BD-Jモジュール１５、モード管理モジュール１６、ディスパッチャ１７、AV再生ライブラリ１８の機能を実現する。
１９.１４：HDMVモジュール１４
HDMVモジュール１４は、DVD-Video仮想プレーヤである。HDMV（High Definition Movie Mode）とは、DVDとの親和性のあるコマンドインタプリタ形式で動作する動作モードである。
１９.１５：BD-Jモジュール１５
BD-Jモジュール１５は、Java（登録商標）仮想マシンを含むミドルウェアプラットフォームであり、BD-Jアプリを実行する。BD-Jアプリは、再生映像と関連付けされてBD-ROM１００の中に記録されており、再生時には動的シナリオメモリ１２に読み出された後、BD-Jモジュール１５によって実行される。Java（登録商標）仮想マシンは、BD-Jアプリを解釈しCPUに実行させる。BD-Jモジュール１５の一部はハードウエアによって実現されていてもよいし、ソフトウェアによって実現されていても良い。
１９.１６：モード管理モジュール１６
モード管理モジュール１６は、仮想ファイルシステム２５から読み出されたモード管理テーブルを保持して、モード管理及び分岐制御を行う。モード管理モジュール１６によるモード管理とは、動的シナリオをどのHDMVモジュール１４、BD-Jモジュール１５に実行させるかという、モジュールを割り当てる処理を実施する。
１９.１７：ディスパッチャ１７
ディスパッチャ１７は、UO検知モジュール２１により受け取ったユーザの操作（ユーザオペレーション、以下UOとも記す）から、現在の再生装置におけるモードに適切なUOのみを選んで、そのモードを実行するモジュールに渡す。例えばHDMVモードの実行中に、上下左右、アクティベートといったUOを受け付けた場合、HDMVモードのモジュールにこれらのUOを出力するのがディスパッチャ１７の処理である。
１９.１８：AV再生ライブラリ１８
AV再生ライブラリ１８は、HDMVモジュール１４、あるいはBD-Jモジュール１５からの呼び出しに応じて、AV再生機能、プレイリストの再生機能を実行するためのライブラリであり、かかるライブラリィによって制御部は、再生制御エンジンとして機能する。AV再生機能とはBD-ROMにて定義されている、DVDプレーヤ、CDプレーヤから踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切替、副映像切替、アングル切替といった処理である。プレイリスト再生機能とは、このAV再生機能のうち、再生開始や再生停止をプレイリスト情報に従って行う。
１９.１９：グラフィクスデコーダ１９
グラフィクスデコーダ１９は字幕データの展開処理を行い、展開された左目用字幕イメージと右目用字幕イメージを、それぞれ左目用字幕プレーン３０と右目用字幕プレーン３１に書き込む。
１９.２０：プレーン合成器２０
プレーン合成器２０は、後述する合成モードに基づいて、バックグラウンドプレーン、ビデオプレーン、字幕プレーン、グラフィクスプレーンの４種類のプレーンに対して左目用と右目用の合成処理を行い、結果を映像として出力する。
１９.２１：UO検知モジュール２１
UO検知モジュール２１は、装置の視聴者が再生装置に対して入力を実施したユーザの操作（UO）を受け取る。これは例えばリモコン・コントローラのような遠隔機器で入力されるものである場合もあるし、機器に対して設置されるボタンのようなインタフェースによって直接入力されるものである場合もある。
１９.２２：レンダリングエンジン２２
レンダリングエンジン２２は、イメージメモリ７、左目用グラフィクスプレーン９、右目用グラフィクスプレーン１０、左目用バックグラウンドプレーン２８および右目用バックグラウンドプレーン２９（以下、これらをまとめてグラフィクスメモリと呼ぶ）に対して描画処理を行う。BD-Jモジュール１５は、色指定を伴った線や矩形等図形の描画、指定領域の塗りつぶし、指定されたイメージのコピー・ペースト等の描画処理を、レンダリングエンジン２２を通じて行うライブラリを有しており、BD-Jアプリはこれらの描画処理の要求を連続的に発行することで、グラフィクスメモリに対する様々なグラフィクス描画処理を実現することができる。
１９.２３：ネットワークインターフェース２３
ネットワークインターフェース２３は、インターネット上に公開されたBD-ROM追加コンテンツのダウンロードに用いられる。BD-ROM追加コンテンツとは、オリジナルのBD-ROMにないコンテンツで、例えば追加の副音声、字幕、特典映像、アプリケーションなどである。BD-Jモジュール１５からネットワークインターフェース２３を制御することができ、インターネット上に公開された追加コンテンツをローカルストレージ２４やリムーバブルメディア２７にダウンロードすることができる。
１９.２４：ローカルストレージ２４
ローカルストレージ２４は、再生装置に内蔵されているハードディスク等の磁気記録装置である。BD-ROM１００に記録されているファイル形式またはそれに準ずる形で、トランスポートストリームや再生に使用する各種のデータを記録する。
１９.２５：仮想ファイルシステム２５
仮想ファイルシステム２５は、BD-ROM１００あるいは、ローカルストレージ２４あるいは、リムーバブルメディア２７に記録されているファイルに対するリード・ライト機構を提供するファイルシステムである。
BD-ROMの再生時に必要とされるファイルアクセスは、通常BD-ROM１００に対して行われるが、仮想ファイルシステム２５はローカルストレージ２４あるいはリムーバブルメディア２７に存在するファイルを、あたかもBD-ROM１００上に記録されているファイルであるかのように仮想的にファイルのアドレス変換を行う機構を備える。すなわち本仮想ファイルシステム２５はファイルの物理的な記録先を抽象化する機構を提供する。
１９.２６：オーディオデコーダ２６
オーディオデコーダ２６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。
１９.２７：リムーバブルメディア２７
リムーバブルメディア２７は再生装置に装着された外部スロットから挿入される記憶媒体である。
１９.２８−２９：バックグラウンドプレーン２８,２９
左目用バックグラウンドプレーン２８および右目用バックグラウンドプレーン２９は、背景イメージを格納するためのメモリであり、HAViデバイスにおけるHBackgroundDeviceに該当する。バックグラウンドプレーンの上にはビデオプレーンが重畳される。したがって、ビデオが画面全体を占有している場合にはバックグラウンドプレーンは隠れて見えなくなるが、ビデオがスケーリングすなわち縮小表示されている状況下においては、ビデオの周囲に背景イメージが表示されることになる。グラフィクスプレーンでは豊富な色使いが可能な一方、バックグラウンドプレーンで使える色数は制限されているような構成とすることが望ましい。この場合、バックグラウンドプレーンへ転送可能なイメージとグラフィクスプレーンへ転送可能なイメージを、別の種類のビットマップイメージとして区別して扱うことが好ましい。この構成では、バックグラウンドプレーンの色数を抑えることで、バックグラウンドプレーン用に必要となるメモリ量を削減できるという効果がある。
１９.３０−３１：左目用字幕プレーン３０および右目用字幕プレーン３１
左目用字幕プレーン３０および右目用字幕プレーン３１は、ビデオの上に重畳される字幕のイメージを格納するためのメモリである。
１９.２０.１：プレーン合成器２０による合成モード
続いて、プレーン合成器２０の合成モードについて詳しく説明を行う。
プレーン合成器２０の基本的な機能は、左目用と右目用のそれぞれ4のつのプレーン、すなわち下から順番にバックグラウンドプレーン、ビデオプレーン、字幕プレーン、グラフィクスプレーンを合成し、映像として出力することである。映像出力は左目用と右目用で異なる映像を出力することができる。これにより、左目と右目で異なる映像を見ることで、視聴者は立体視の効果を得ることができる。
しかしながら、立体的な視聴のためには必ずしも全てのプレーンにおいて左右異なる映像にする必要はない。例えば、ビデオプレーンだけが左右異なる映像になり、ビデオプレーンの後ろに表示されるバックグラウンドプレーンや、ビデオプレーンの上に重畳表示されるメニューなどのグラフィクスプレーンは、左右同じ映像でもよい。この場合、バックグラウンドプレーンおよびグラフィックは、視聴者には平らなように見えることになるが、このような構成をとることでBD-ROMコンテンツの製作が容易になるため、コスト面では有利になる。
このように、製作コストの低減と高機能な立体視視聴の両立を実現するため、再生機器のプレーン合成器２０は複数の合成モードをサポートし、BD-Jアプリは必要な時に合成モードを動的に切替えることができる。
例えば、平らなメニュー画面を表示している時には、グラフィクスプレーンは左右同じ画像を使用しているが、メニューから特典のゲーム機能へ遷移すると、グラフィクスプレーンでも立体的な効果が必要になるため、左目と右目で異なるグラフィクスを表示できるように、グラフィクスプレーンの合成モードを切替えればよい。同様に、バックグラウンドプレーンについても、スケーリング表示されているビデオの周辺の背景として使用される場合には左右同じ画像を使用し、ゲーム機能の背景として使用される場合には左右異なる画像となるように、バックグラウンドプレーンの合成モードも切替えることができる。
以上のように、プレーン合成器２０に複数の合成モードを持たせることで、単純なメニューを簡単に作りたい場合、技巧を凝らした立体的なメニューに仕上げたい場合など、様々な選択をコンテンツオーサリング側で行うことが可能となり、製作側の自由度を増すことができる。
次に、プレーン合成器２０における合成について説明する。
２０.プレーン合成器２０の構成要素
図２０（ａ）は、プレーンメモリのレイヤ構成と、プレーン合成器２０の構成要素とを示す。多重分離部１０５は、プレーンメモリのレイヤ構成の左目用出力系統に設けられた加算器５１、加算器５２、加算器５３と、プレーンメモリのレイヤ構成の右目用出力系統に設けられた加算器６１、加算器６２、加算器６３、スイッチ６４、スイッチ６５を構成要素とする。
加算器５１は、左目用ビデオプレーンの格納内容と、左目用バックグラウンドプレーンの格納内容との合成を行う。
加算器５２は、左目用字幕プレーンの格納内容と、加算器５１の合成結果との合成を行う。
加算器５３は、左目用グラフィクスプレーンの格納内容と、加算器５２の合成結果との合成を行う。
加算器６１は、左目用ビデオプレーンの格納内容と、左目用バックグラウンドプレーン又は右目用バックグラウンドプレーンの格納内容との合成を行う。
加算器６２は、右目用字幕プレーンの格納内容と、加算器６１の合成結果との合成を行う。
加算器６３は、左目用グラフィクスプレーン又は右目用グラフィクスプレーンの格納内容と、加算器６２の合成結果との合成を行う。
スイッチ６４は、加算器６１に対する画素データの供給源を、左目用バックグラウンドプレーン及び右目用バックグラウンドプレーンの何れかに切り替える。加算器６１に対する画素データの供給源を左目用バックグラウンドプレーンとした場合、コンフィグレーションは、１プレーン構成になり、画素データの供給源を右目用バックグラウンドプレーンとした場合、コンフィグレーションは、２プレーン構成となる。
スイッチ６５は、加算器６３に対する画素データの供給源を、左目用グラフィクスプレーン及び右目用グラフィクスプレーンの何れかに切り替える。加算器６１に対する画素データの供給源を左目用グラフィクスプレーンとした場合、コンフィグレーションは、１プレーン構成になり、画素データの供給源を右目用グラフィクスプレーンとした場合、コンフィグレーションは、２プレーン構成となる。
字幕プレーンも、右目用字幕プレーン、左目用字幕プレーンが存在するため、本来なら、字幕プレーンのコンフィグレーションも、１プレーン構成、２プレーン構成が存在するが、この字幕プレーンの１プレーン構成を想定すると説明が煩雑になるため、字幕プレーンは、２プレーン構成で固定するものとして説明を進める。
２１.合成モードのバリエーション
2D再生モードにおける出力系統は、図２０（ｂ）のもので固定される。これに対して3D再生モードでは、右目用の出力系統と、左目用の出力系統とがあり、左目用の出力系統では、加算器へのデータ供給源を右目用のプレーンメモリとするか、左目用のプレーンメモリとするかによって、図２１（ａ）〜（ｄ）に示す４通りのバリエーションが存在する。つまり、2D再生モードでは出力系統にバリエーションが存在しないが、3D再生モードにおいてプレーン合成器２０は、４通りの出力系統の切り替えを実現することにより、４つの合成モード(合成モード１、合成モード２、合成モード３、合成モード４)を有することになる。以下、それぞれのモードについて、図２１（ａ）〜（ｄ）のそれぞれを用いて説明する。
２１.１：合成モード１
図２１（ａ）は、グラフィクスプレーン、字幕プレーン、ビデオプレーン、バックグラウンドプレーンの比率を、2:2:2:2とする出力系統による合成モード(合成モード１)を示す。グラフィクスプレーン、字幕プレーン、バックグラウンドグラフィクスプレーンのプレーン数は何れも、２プレーンであるので、加算器６３への供給源は右目用グラフィクスプレーン、加算器６１への供給源は、右目用バックグラウンドプレーンになっている。合成モード１では、グラフィクスプレーンは左目用と右目用の二つが使用される。バックグラウンドプレーンも左目用と右目用の二つが使用される。左目用映像出力として、下から左目用バックグラウンドプレーン、左目用ビデオプレーン、左目用字幕プレーン、左目用グラフィクスプレーンの順に合成され、同じく右目用映像出力として、下から右目用バックグラウンドプレーン、右目用ビデオプレーン、右目用字幕プレーン、右目用グラフィクスプレーンの順に合成される。合成モード１では、グラフィクスプレーン、バックグラウンドプレーンの双方とも立体的な表現が可能である。
２１.２：合成モード２
図２１（ｂ）は、グラフィクスプレーン、字幕プレーン、ビデオプレーン、バックグラウンドプレーンの比率を、1:2:2:2とする出力系統による合成モード(合成モード２という)を示す。グラフィクスプレーンにおけるプレーン数は“１”であるから、加算器６３への供給源は左目用グラフィクスプレーン、加算器６１への供給源は、右目用バックグラウンドプレーンになっている。合成モード２では、グラフィクスプレーンは左目用だけが使用され、左目用映像出力と右目用映像出力にはいずれも左目用グラフィクスプレーンが参照される。その結果、グラフィクスプレーンについては左右同じ映像が出力されるため、視聴者の目には平らに見えることとなる。バックグラウンドプレーンについては、合成モード１と同様に、左目用と右目用の二つが使用される。合成モード２では、左目用映像出力として、下から左目用バックグラウンドプレーン、左目用ビデオプレーン、左目用字幕プレーン、左目用グラフィクスプレーンが合成され、右目用映像出力として、下から右目用バックグラウンドプレーン、右目用ビデオプレーン、右目用字幕プレーン、左目用グラフィクスプレーンが順に合成される。したがって、バックグラウンドプレーンは立体的な表現が可能であるが、グラフィクスプレーンについては平面的な表現に限定される。
２１.３：合成モード３
図２１（ｃ）は、グラフィクスプレーン、字幕プレーン、ビデオプレーン、バックグラウンドプレーンの比率を、2:2:2:1とする出力系統による合成モード(合成モード３という)を示す。バックグラウンドプレーンのプレーン数は１プレーンであるので、加算器６１への供給源は、左目用バックグラウンドプレーンになっている。合成モード３では、グラフィクスプレーンは左目用と右目用の二つが使用されるが、バックグラウンドプレーンは左目用だけが使用され、左目用映像出力と右目用映像出力にはいずれも左目用バックグラウンドプレーンが参照される。その結果、バックグラウンドプレーンについては左右同じ映像が出力されるため、視聴者の目には平らに見えることとなる。合成モード３では、左目用映像出力として、下から左目用バックグラウンドプレーン、左目用ビデオプレーン、左目用字幕プレーン、左目用グラフィクスプレーンが順に合成され、右目用映像出力として、下から左目用バックグラウンドプレーン、右目用ビデオプレーン、右目用字幕プレーン、右目用グラフィクスプレーンの順に合成される。したがって、グラフィクスプレーンは立体的な表現が可能であるが、バックグラウンドプレーンについては平面的な表現に限定される。
２１.４：合成モード４
図２１（ｄ）は、グラフィクスプレーン、字幕プレーン、ビデオプレーン、バックグラウンドプレーンの比率を、1:2:2:1とする出力系統による合成モード(合成モード４)を示す。グラフィクスプレーンのプレーンメモリ数は１プレーン、バックグラウンドプレーンのプレーン数は１プレーンであるので、加算器６３への供給源は左目用グラフィクスプレーン、加算器６１への供給源は、左目用バックグラウンドプレーンになっている。合成モード４では、グラフィクスプレーンおよびバックグラウンドプレーンの双方とも、左目用だけが使用される。すなわち、左目用映像出力として、下から左目用バックグラウンドプレーン、左目用ビデオプレーン、左目用字幕プレーン、左目用グラフィクスプレーンが順に合成され、右目用映像出力として、下から左目用バックグラウンドプレーン、右目用ビデオプレーン、右目用字幕プレーン、左目用グラフィクスプレーンが順に合成される。したがって、合成モード４では、グラフィクスプレーン、バックグラウンドプレーンのいずれも平面的な表現に限定される。
２２.グラフィクス描画機能のAPI
次に、BD-Jモジュール１５が持つグラフィクス機能について説明を行う。図２２は、BD-Jモジュール１５がサポートするグラフィクス描画機能のAPIの一例を示した図であり、図２３は、図２２のグラフィクス描画機能APIのコールコードの一例を示す図である。BD-JアプリからのこれらのAPI呼び出し、すなわち描画要求をトリガとして、BD-Jモジュール１５はレンダリングエンジン２２を用いて実際の描画処理を実行する。
２２.１：イメージ描画要求８０１
イメージ描画要求８０１は、第３実施形態の内部構成を有する再生装置において、一枚のビットマップイメージを左目用グラフィクスプレーン９にコピーする旨を要求するものであり、第１実施形態のGraphics#drawImageに相当する。コピー元の描画イメージとコピー先の描画位置を入力とし、対象となる描画イメージを左目用グラフィクスプレーン９の指定された描画位置へコピーする。描画イメージはイメージメモリに存在し、レンダリングエンジン２２により、高速にイメージメモリから左目用グラフィクスプレーン９への転送がなされる。
２２.２：左右イメージ描画要求８０２
左右イメージ描画要求８０２は、第３実施形態の内部構成を有する再生装置において、二枚のビットマップイメージをそれぞれ左目用グラフィクスプレーン９と右目用グラフィクスプレーン１０とに同時にコピーする旨を要求するものであり、第１実施形態のStereoGraphics#drawImageに相当する。この要求は、コピー元の描画イメージ２枚と描画位置２つを入力とし、一方の描画イメージは左目用グラフィクスプレーン９、もう一方の描画イメージは右目用グラフィクスプレーン１０へ描画を行う。それぞれの描画イメージはイメージメモリに存在し、レンダリングエンジン２２により、高速にイメージメモリから左目用グラフィクスプレーン９と右目用グラフィクスプレーン１０へ転送される。
２２.３：合成モード切替要求８０３
合成モード切替要求８０３は、第３実施形態の内部構成を有する再生装置において、プレーン合成器２０の合成モードを切替えるためのAPIであり、第１実施形態のコンフィグレーション設定要求に対応する。第１実施形態と異なるのは、解像度、グラフィクスプレーンの設定、およびバックグラウンドプレーンの設定を入力とする点である。解像度は再生機器が複数の解像度に対応する場合に必要となるが、第３実施形態においては、必ず１９２０×１０８０固定として扱うものとする。
第３実施形態では、プレーンメモリとしてバックグラウンドプレーンが存在するので、合成モード切替要求では、グラフィクスプレーンおよびバックグラウンドプレーンの設定として、それぞれ、１プレーン構成か２プレーン構成であるかを選択することができる。１プレーン構成は、左目用と右目用に同じ映像を出力するモードを表し、前述の1plane＋Offsetモードに相当するものである。２プレーン構成は、左目用と右目用にそれぞれ異なる映像を出力するモードを表し、前述の3D-LRモードに相当するものである。グラフィクスプレーン設定として２プレーン、バックグラウンドプレーン設定として２プレーンが要求された場合、プレーン合成器２０は後述する合成モード１へ遷移する必要がある。同様に、グラフィクスプレーン設定とバックグラウンドプレーン設定に基づいて、プレーン合成器２０がどの合成モードへ遷移すべきかが一意に定まる。
２２.４：バックグラウンド描画要求８０４
バックグラウンド描画要求８０４は、一枚のビットマップイメージを左目用バックグラウンドプレーン２８へコピーするためのAPIである。コピー元の描画イメージを入力とし、対象の描画イメージを左目用バックグラウンドプレーン２８全体へコピーする。
２２.５：バックグラウンド描画要求８０５
バックグラウンド描画要求８０５は、二枚のビットマップイメージをそれぞれ左目用バックグラウンドプレーン２８および右目用バックグラウンドプレーン２９へコピーするためのAPIである。コピー元の描画イメージ二枚を入力とし、一つの描画イメージは左目用バックグラウンドプレーン２８へ、もう一つの描画イメージは右目用グラフィクスプレーン２９へコピーされる。それぞれの描画イメージはイメージメモリに存在し、レンダリングエンジン２２により、高速にイメージメモリから左目用バックグラウンドプレーン２８および右目用バックグラウンドプレーン２９の全体へ転送される。
バックグラウンド描画要求のコピー先の設定には、バックグラウンドプレーン全体と設定することもできるし、グラフィクスプレーン同様に描画位置を指定できるようにしてもよい。
２４.合成モード切替要求時の処理手順
続いて、合成モード切替要求８０３が呼び出された場合の処理手順について、図２４を用いて説明する。合成モード切替要求８０３の処理は、プレーン合成器２０の現在の合成モードと、要求された合成モードとを比較し、遷移を行うものである。
まず、グラフィクスプレーンの設定として２プレーンが要求されていて、かつ、現在のグラフィクスプレーンが１プレーン（合成モード２あるいは合成モード４）であるかを確認し（S９０１）、そうであった場合には、グラフィクスプレーンを２プレーンに切替える（S９０２）。この処理については、詳細を後述する。
続いて、グラフィクスプレーンの設定として１プレーンが要求されていて、かつ、現在のグラフィクスプレーンが２プレーン（合成モード１あるいは合成モード３）であるかを確認し（S９０３）、そうであった場合には、グラフィクスプレーンを１プレーンに切替える（S９０４）。この処理についても、詳細を後述する。
次に、バックグラウンドプレーンの設定として２プレーンが要求されていて、かつ、現在のバックグラウンドプレーンが１プレーン（合成モード３あるいは合成モード４）であるかを確認し（S９０５）、そうであった場合には、バックグラウンドプレーンを２プレーンへ切替える（S９０６）。
バックグラウンドプレーンの設定として１プレーンが要求されていて、かつ、現在のバックグラウンドプレーンが２プレーン（合成モード１あるいは合成モード２）であるかを確認し（S９０７）、そうであった場合には、バックグラウンドプレーンを１プレーンへ切替える（S９０８）。最後に、切替処理が完了したことをBD-Jアプリへ通知する（S９０９）。この通知は、非同期のイベント処理として行うことが望ましい。
図２４のフローに示す処理を同期APIとして実装する場合、合成モード切替要求８０３はS９０９の処理完了後にBD-Jアプリへリターンし、制御を移す。BD-Jシステムはマルチスレッドをサポートしているため、合成モード切替要求８０３が処理されている間も、BD-Jアプリの他のスレッドは独立して動作しているが、合成モード切替要求８０３を同期メソッドとして実装すれば、合成モード切替要求８０３を呼び出したスレッドは、切替処理が完了するまでブロックされることになる。
２５.１：1プレーン構成から2プレーン構成への切り替え
次に、グラフィクスプレーンを１プレーンから２プレーンへ切替えるS９０２の処理について、より詳細な処理フローを図２５（ａ）を用いて説明する。
まず最初に、１プレーン用のグラフィクスプレーン描画要求である、イメージ描画要求８０１を禁止し（S１００１）、以降にイメージ描画要求８０１が呼び出された場合は、前述したように当該呼び出しを無視するか、例外を発生させるようにする。グラフィクスプレーンが１プレーンとなっている初期状態では、前述の通りイメージ描画要求８０１の呼び出しは許可、左右イメージ描画要求８０２の呼び出しは禁止となっているが、本ステップにより、イメージ描画要求８０１および左右イメージ描画要求８０２の双方の呼び出しが禁止されることになる。
続いて、左目用グラフィクスプレーン９の内容全体を、右目用グラフィクスプレーン１０にコピーする（S１００２）。合成モード切替前の状態では、左目用グラフィクスプレーン９の画像のみが映像として出力されており、右目用グラフィクスプレーン１０にはどのような画像が格納されているか不定で、例えば全面黒色のままとなっている。ところが、そのままグラフィクスプレーンを２プレーンに切替えると、この全面黒色の右目用グラフィクスプレーン１０が映像として出力されてしまう。BD-Jアプリが合成モード切替要求８０３を呼び出したということは、当然BD-Jアプリはその後右目用グラフィッスプレーン１０にも正しい画像を描画することが期待されるが、描画までにタイムラグが存在すると、一瞬右目用にのみ全面黒色の出力がなされるため、左右の映像の不整合が発生してしまう。このような不整合を回避するため、本ステップにて左目用グラフィクスプレーン９の内容を右目用グラフィクスプレーン１０に強制的にコピーすることで、左右の映像出力の整合を保つことができる。
次に、プレーン合成器２０の合成モードを、合成モード１または合成モード３へ切替える（S１００３）。現在のバックグラウンドプレーンが２プレーンの場合には合成モード１へ、１プレーンの場合には合成モード３へ遷移させればよい。
最後に、２プレーン用のグラフィクスプレーン描画要求である、左右イメージ描画要求８０２の禁止を解除し（S１００４）、以降に左右イメージ描画要求８０２が呼び出された場合にはコピー処理が実行されるようにする。本ステップにより、イメージ描画要求８０１の呼び出しは禁止、左右イメージ描画要求８０２の呼び出しは許可されることとなる。
上記のように、１プレーン用のグラフィクスプレーン描画要求を禁止した後にS１００２、S１００３の処理を行うことで、左目用と右目用の不整合を防止することができる。このような構成をとることにより、BD-Jアプリの実装の問題によって、合成モード切替要求８０３の処理途中でイメージ描画要求８０１が発生した場合にも、不整合が起こらないようにすることができる。
２５.２：2プレーン構成から1プレーン構成への切り替え
続いて、グラフィクスプレーンを２プレーンから１プレーンへ切替えるS９０４の処理について、より詳細な処理フローを図２５（ｂ）を用いて説明する。
まず最初に、２プレーン用のグラフィクスプレーン描画要求である、左右イメージ描画要求８０２を禁止し（S１１０１）、以降に左右イメージ描画要求８０２が呼び出された場合は、前述したように当該呼び出しを無視するか、例外を発生させるようにする。グラフィクスプレーンが２プレーンとなっている初期状態では、イメージ描画要求８０１の呼び出しは禁止、左右イメージ描画要求８０２の呼び出しは許可となっているが、本ステップにより、イメージ描画要求８０１および左右イメージ描画要求８０２の双方の呼び出しが禁止されることになる。
次に、プレーン合成器２０の合成モードを、合成モード２または合成モード４へ切替える（S１１０２）。現在のバックグラウンドプレーンが２プレーンの場合には合成モード２へ、１プレーンの場合には合成モード４へ遷移させればよい。
続いて、１プレーン用のグラフィクスプレーン描画要求である、イメージ描画要求８０１の禁止を解除し（S１１０３）、以降にイメージ描画要求８０１が呼び出された場合にはコピー処理が実行されるようにする。本ステップにより、イメージ描画要求８０１の呼び出しは許可、左右イメージ描画要求８０２の呼び出しは禁止されることとなる。
最後に、再描画要求イベントをBD-Jアプリへ通知する（S１１０４）。合成モードを切り替えた直後には再描画が必要となる可能性があるが、グラフィクスプレーンが１プレーンになっている合成モード切替後においては、従来のBD-J仕様と同様のグラフィクス処理が可能な状態となっているため、従来仕様との整合をとるために、本ステップにて再描画要求イベントを通知する。
以上のように、合成モードの切替が完了してからS１１０３の処理を行うことで、左目用の映像と右目用の映像の不整合を防止することができる。
バイトコードアプリケーションによるコンフィグレーション設定要求によって、バックグラウンドプレーンが2プレーン構成であるか、1プレーン構成であるかの設定がなされる。このようなコンフィグレーション切り替えにおいては、第１実施形態で述べた状況、つまり、左目用バックグラウンドプレーン及び右目用バックグラウンドプレーンのコンフィグレーションを、1プレーン構成から2プレーン構成へと切り替える旨を要求した後に、バックグラウンドプレーンに対するGraphics#drawImageによる要求がjava.awt.Graphicsに到達するという状況が生じる。そこで、バックグラウンドプレーンに対するコンフィグレーション設定要求を受信した後の1プレーン構成から2プレーン構成へのコンフィグレーションの切り替え時においては、バックグラウンドプレーンに対する2Dグラフィクス描画要求の無効化、左目用バックグラウンドプレーンから右目用バックグラウンドプレーンへのコピー、右目用出力系統の切り替え、3Dグラフィクス描画要求受け入れを実行し、2プレーン構成から1プレーン構成へのコンフィグレーション切り替え時においては、バックグラウンドプレーンに対するStereoGraphics#drawImageによる要求の禁止、右目用出力系統の切り替え、バックグラウンドプレーンに対するGraphics#drawImageの受け入れを実行する。こうすることで、1プレーン構成から2プレーン構成へのコンフィグレーションの切り替え後に、2Dグラフィクス描画要求がjava.awt.Graphicsに到達することによる左右の視覚の不一致発生を解消することができる。よって、この図２５（ａ）、（ｂ）の処理を、バックグラウンドプレーンに対するコンフィグレーション設定要求の後にも実行する。
よって、第３実施形態では、バックグラウンドプレーンを２プレーンへ切替えるS９０６およびバックグラウンドプレーンを１プレーンへ切り替えるS９０８の処理を、それぞれ図２５（ａ）および図２５（ｂ）と同様の処理フローによって実現する。
以上のように本実施形態によれば、グラフィクスプレーンだけではなく、バックグラウンドプレーンのコピーに先立ち、2Dグラフィクス描画要求を無効化するので、左目用バックグラウンドプレーンから右目用バックグラウンドプレーンへの画素データコピーがなれた後に、左目用バックグラウンドプレーンに新たなグラフィクスが書き込まれることはない。2Dグラフィクス描画要求が遅れて、java.awt.Graphicsに到達したとしても、その2Dグラフィクス描画要求に従い、バックグラウンドプレーンの格納内容が表示されることはありえず、両目の視覚の不一致が生じることはない。
(第４実施形態)
本実施形態は、第１実施形態で説明したレイヤモデルにおいて、１プレーン描画要求の禁止とその解除、２プレーン描画要求の禁止とその解除を、再生装置内にどのように実施するかという改良に関する。
２５：org.havi.uiに対する改良
図２５（ａ）（ｂ）の処理を実現するには、setConfiguraionコールがなされた場合における第２引数が2プレーン構成の指定である場合の処理、第３引数が2プレーン構成の指定である場合の処理を、org.havi.uiに追加させる必要がある。そのような改良は、org.havi.uiに、図２６のフローチャートの処理手順を追加すればよい。
２６：setConfiguraionコール時におけるorg.havi.uiの処理手順
図２６は、setConfiguraionコール時におけるorg.havi.uiの処理手順を示すフローチャートである。本フローチャートは、プレーン構成の切り替え処理の最上位の処理、つまり、メインルーチンに該当するものであり、本フローチャートの下位のフローチャートとして、図２７〜図３０のフローチャートが存在する。以下、メインルーチンにおける処理手順について説明する。
ステップＳ９０１は、現在のグラフィクスプレーンのコンフィグレーションが1プレーン構成であり、尚且つ、setConfiguraionコール時における第２引数、つまり、グラフィクスプレーンのプレーン数が、2プレーン構成を指定するものかどうかの判定である。かかる判定は、図２４のステップＳ９０１をより詳細にしたものである。このステップＳ９０１がYesであるなら、ステップＳ１０００において、第１引数で指定された解像度のグラフィクスプレーンを2プレーン確保した後、ステップＳ１００１〜ステップＳ１００４を実行する。
ステップＳ１００１〜ステップＳ１００４は、setConfiguraionコールによる2プレーン構成への切り替え手順であり、先の実施形態における図２５（ａ）の処理手順と同じであり、図２５（ａ）と同一の参照符号を付している。具体的には、グラフィクスプレーンに対する1プレーン用描画要求を禁止し(ステップＳ１００１)、左目用グラフィクスプレーンから右目用グラフィクスプレーンへの画素データコピーを行い(ステップＳ１００２)、プレーン合成器の合成モードを切り替え(ステップＳ１００３)、グラフィクスプレーンに対する2プレーン用描画要求の禁止を解除する(ステップＳ１００４)。
ステップＳ９０１がNoである場合、ステップＳ９０３の判定を実行する。ステップＳ９０３は、現在のグラフィクスプレーンのコンフィグレーションが2プレーン構成であり、尚且つ、setConfiguraionコール時における第２引数、つまり、グラフィクスプレーンのプレーン数が、1プレーン構成を指定するものかどうかの判定である。かかる判定は、図２４のステップＳ９０３をより詳細にしたものである。このステップＳ９０３がYesであるなら、ステップＳ１１００において第１引数で指定された解像度のグラフィクスプレーンを1プレーン確保した後、ステップＳ１１０１〜ステップＳ１１０４を実行する。
ステップＳ１１０１〜ステップＳ１１０４は、setConfiguraionコールによる1プレーン構成への切り替え手順であり、先の実施形態における図２５（ｂ）の処理手順と同じであり、図２５（ｂ）と同一の参照符号を付している。具体的には、グラフィクスプレーンに対する2プレーン用描画要求を禁止し(ステップＳ１１０１)、プレーン合成器の合成モードを切り替え(ステップＳ１１０２)、グラフィクスプレーンに対する1プレーン用描画要求の禁止を解除し(ステップＳ１１０３)、再描画要求イベントを通知する(ステップＳ１１０４)。
以上がグラフィクスプレーンに対するsetConfiguraionの処理手順の説明である。続いて、バックグラウンドプレーンに対する処理の詳細について説明する。
ステップＳ９０５は、現在のバックグラウンドプレーンのコンフィグレーションが1プレーン構成であり、尚且つ、setConfiguraionコール時における第２引数、つまり、バックグラウンドプレーンのプレーン数が、2プレーン構成を指定するものかどうかの判定である。かかる判定は、図２４のステップＳ９０５をより詳細にしたものである。このステップＳ９０５がYesであるなら、ステップＳ１０１０において、第１引数で指定された解像度のバックグラウンドプレーンを2プレーン確保した後、ステップＳ１０１１〜ステップＳ１０１４を実行する。ステップＳ１０１１〜ステップＳ１０１４は、setConfiguraionコールによる2プレーン構成への切り替え手順であり、先の実施形態における図２５（ａ）の処理手順をバックグラウンドプレーンに適用したものである。具体的には、バックグラウンドプレーンに対する1プレーン用描画要求を禁止し(ステップＳ１０１１)、左目用バックグラウンドプレーンから右目用バックグラウンドプレーンへの画素データコピーを行い(ステップＳ１０１２)、プレーン合成器の合成モードを切り替え(ステップＳ１０１３)、バックグラウンドプレーンに対する2プレーン用描画要求の禁止を解除する(ステップＳ１００４)。
ステップＳ９０５がNoである場合、ステップＳ９０７を実行する。ステップＳ９０７は、現在のバックグラウンドプレーンのコンフィグレーションが1プレーン構成であり、尚且つ、setConfiguraionコール時における第２引数、つまり、バックグラウンドプレーンのプレーン数が、2プレーン構成を指定するものかどうかの判定である。かかる判定は、図２４のステップＳ９０７をより詳細にしたものである。このステップＳ９０７がYesであるなら、ステップＳ１１１０で、第１引数で指定された解像度のバックグラウンドプレーンを1プレーン確保した後、ステップＳ１１１１〜ステップＳ１１１４を実行する。ステップＳ１１１１〜ステップＳ１１１４は、setConfiguraionコールによる1プレーン構成への切り替え手順であり、先の実施形態における図２５（ａ）の処理手順をバックグラウンドプレーンに適用したものである。具体的には、バックグラウンドプレーンに対する2プレーン用描画要求を禁止し(ステップＳ１１１１)、プレーン合成器の合成モードを切り替え(ステップＳ１１１２)、バックグラウンドプレーンに対する1プレーン用描画要求の禁止を解除し(ステップＳ１１１３)、再描画要求イベントを通する(ステップＳ１１１４)。
２７：java.awt.Graphicsに対する改良
第３実施形態における図２５（ａ）（ｂ）の処理を実施するには、図２６のステップＳ１００１において１プレーン用描画要求が禁止されてから、図２６のステップＳ１１０３において１プレーン用描画要求の禁止が解除されるまで、Graphics#drawImageを一切実行せず、またこれまでなされたGraphics#drawImageコールを無効化するような改良を、java.awt.Graphicsに加える必要がある。そのような改良は、java.awt.Graphicsに図２７のフローチャートの処理手順を追加すればよい。
図２７は、java.awt.Graphicsの処理手順を示すフローチャートである。ステップＳ１ーステップＳ２からなるループを実行している。ステップＳ１は、java.awt.Graphicsのコールがなされたかどうかの判定であり、java.awt.Graphicsのコールがなされれば、ステップＳ３において第１引数、第２引数に従い、グラフィクスの描画を実行する。ステップＳ２は、１プレーン用描画要求が禁止されたかどうかの判定である。もし禁止されれば、ステップＳ２からステップＳ４に移行する。ステップＳ４は、スタックの中に、Graphics#drawImageのコールコードが存在するか否かの判定である。もし存在すればステップＳ５において、Graphics#drawImageのコールコードの呼出元のスレッドにExceptionを返すことで、Graphics#drawImageを無視する。ステップＳ６は、１プレーン描画要求が解除されたかどうかの判定待ちであり、もし解除されれば、ステップＳ１〜ステップＳ２のループに戻る。java.awt.Graphicsが以上の処理を実行することで、図２５（ａ）のステップＳ１００１において１プレーン用描画要求が禁止されてから、図２５（ｂ）のステップＳ１１０３において１プレーン用描画要求の禁止が解除されるまで、java.awt.GraphicsはGraphics#drawImageを一切実行することはない。
２８：アプリケーションマネージャに対する改良点
図２５（ａ）、図２５（ｂ）によるプレーン構成の切り替えを実現するためのアプリケーションマネージャに対する改良点について述べる。StereoGraphicsはStereoGraphics#drawImageのみを処理する、StereoGraphics専用のグラフィクス描画パッケージであるから、図２６のステップＳ１００４への移行時にStereoGraphicsを起動するものとし、図２６のステップＳ１１０１への移行時にStereoGraphicsの動作を終了させるよう、StereoGraphicsの状態を制御せねばならない。このような状態制御を実現するには、StereoGraphics特有の状態制御として、図２８の処理手順をアプリケーションマネージャに実行させればよい。
図２８は、アプリケーションマネージャによるStereoGraphicsの状態制御の手順を示すフローチャートである。ステップＳ１１は、２プレーン描画要求の禁止が解除されたかどうかの判定待ちであり、解除されれば、ステップＳ１２に移行して、StereoGraphicsをロードして起動する。その後、ステップＳ１３〜ステップＳ１４のループに移行する。ステップＳ１３は、StereoGraphicsに3Dグラフィクスを処理させるものであり、3Dグラフィクスのコールが発生する限り、StereoGraphicsは、この3Dグラフィクスのコールに従い左目用グラフィクスプレーン及び右目用グラフィクスプレーンへのグラフィクス書き込みを実行する。ステップＳ１４は、２プレーン描画要求が禁止されたかどうかの判定である。禁止されない限り、ステップＳ１３〜ステップＳ１４のループを繰り返すことになる。もし禁止されれば、ステップＳ１５においてStereoGraphicsの動作を終了して、ステップＳ１１に移行し、禁止が解除されるのを待つ。
以上がアプリケーションマネージャによるStereoGraphicsの状態制御についての説明である。StereoGraphicsの状態を、外部から上述したように制御することで、StereoGraphicsは、限定的に動作することになる。
２９：デバイスドライバに対する改良
図２５（ａ）（ｂ）の処理を実施するには、図２６のステップＳ１００３及び図２６のステップＳ１１０２において、合成モードの切り替えが要求された際、右目用の出力系統の解放・追加や、右目用加算器へのデータ供給元の切り替えをデバイスドライバに実現させる必要がある。そのような改良は、デバイスドライバに図２９（ａ）（ｂ）のフローチャートの処理手順を追加すればよい。
図２９（ａ）は、合成モード器による合成モードの切り替え手順のメインルーチンにあたる処理手順を示すフローチャートである。ステップＳ２１は、再生モードが3D再生モードか、2D再生モードかの判定であり、2D再生モードなら、ステップＳ２２において右目用の出力系統を解放する。再生モードが3D再生モードなら、ステップＳ２３において右目用の出力系統が有かどうかを判定する。有効であれば、ステップＳ２５において、右目用の出力系統を切り替える。有効でなければ、ステップＳ２４において右目用の出力系統を追加した上で、ステップＳ２５において、右目用の出力系統を切り替える。
ステップＳ２５の右目用出力系統の切り替えについては、図２９（ｂ）のサブルーチンを使用して、より詳細に説明する。
図２９（ｂ）は、右目用の出力系統の切り替え手順を示すフローチャートである。ステップＳ２６は、setConfiguraionの第１引数が２プレーンであるかどうかの判定である。ステップＳ２６がNoであれば、ステップＳ２７において右目用加算器への供給元を左目用グラフィクスプレーンとする。ステップＳ２６がYesであれば、ステップＳ２８において右目用加算器への供給元を右目用グラフィクスプレーンとする。ステップＳ２９は、setConfiguraionの第２引数が２プレーンであるか否かの判定である。Noであるなら、ステップＳ３０において右目用加算器への供給元を左目用バックグラウンドプレーンとする。Yesであるなら、ステップＳ３１において右目用加算器の供給元を右目用バックグラウンドプレーンとする。
３０：StereoGraphicsを具現する処理手順
StereoGraphicsの実体は、StereoGraphics#drawImageコールに応じたライン描画をMPUに行わせるレジデント型のバイトコードアプリケーションである。図３０は、StereoGraphics#drawImageメソッドがコールされた際のライン描画手順を示すフローチャートである。
変数Yは、本フローチャートのループにおける制御変数であり、ステップにおいて初期化され、ステップＳ５４における本フローチャートの終了条件の成否判定に用いられる。
描画イメージの描画対象行を示す変数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を構成するライン画素が書き込まれてゆく。
以上がStereoGraphicsによるコピー手順についての説明である。続いて、StereoGraphics#drawImageを用いてGUI描画を行うバイトコードアプリケーションの具体例について説明する。StereoGraphics#drawImageを用いたGUI描画の具体例としては、複数のフレーム期間をかけて、描画イメージを左目用グラフィクスプレーン、右目用グラフィクスプレーンに書き込むというものになる。以下、StereoGraphics#drawImageを用いたバイトコードアプリケーションの記述例について説明する。
３１：バイトコードアプリケーションによるメニュー表示の具体例
図３１は、バイトコードアプリケーションによるメニュー表示のフローチャートである。ステップＳ４１において、描画イメージを最初に表示すべきフレームを”フレームｔ”とし、ステップＳ４２〜ステップＳ４７のループに移行する。ステップＳ４２〜ステップＳ４７は、フレームｔに表示すべき左イメージのインスタンスを生成して、イメージ１とし(ステップＳ４２)、フレームｔに表示すべき右イメージのインスタンスを生成して、イメージ２として(ステップＳ４３)、フレームｔの始期が到来するのを待ち(ステップＳ４４)、始期が到来すれば、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を特定する(ステップＳ４５)。そして、左イメージプレーンの描画を行うべき矩形範囲、右イメージプレーンの描画を行うべき矩形範囲を引数で指定した上で、StereoGraphics#drawImageメソッドのコールを行い(ステップＳ４６)、次にイメージを表示すべきフレームをフレームｔとする処理(ステップＳ４７)を、繰り返すものである。
以上のように本実施形態によれば、BD-Jターミナルのプレーヤモデル、レイヤモデルにおける構成要素に対する改良によって、これまでの実施形態で述べた特徴的な処理を再生装置に実行させることができるので、再生装置の基本構成に大幅な変更を加えることがなく、本願特有の特徴的な処理を、再生装置に組み込むことができる。これにより、再生装置の開発工数を大幅に削減することができ、再生装置の製品投入を早めることができる。
（第５実施形態)
本実施形態は、再生装置における再生モードを、タイトル選択時に実行されるモード選択プロシージャで決定するという実施形態である。ここで本明細書のタイトルは、少なくとも1つの動作モードオブジェクトを必須の構成要素とする。動作モードオブジェクトとは、あるモードにおけるタイトル再生時の再生装置の挙動の詳細を規定する動作管理テーブルである。そして、このタイトルには、HDMVタイトル、BD-Jタイトルといった種別がある。
３２.１：HDMVタイトル
「HDMVタイトル」とは、第３実施形態で述べたHDMVモードで再生されるべきタイトルのことであり、ムービーオブジェクトと、ムービーオブジェクト内の再生コマンドで再生されるプレイリスト(プレイリスト情報、クリップ情報、ストリームファイル)とから構成される。
「ムービーオブジェクト」とは、インデックステーブルにおいてHDMVタイトルのタイトル番号に対応付けられた動作モードオブジェクトのことであり、ナビゲーションコマンド列から構成されるバッチプログラムに、レジュームの可否を示すレジュームフラグ、メニューコールをマスクするか否かを示すフラグ、タイトルサーチをマスクするか否かを示すフラグを対応付けることで構成されている。
３２.２：BD-Jタイトル
「BD-Jタイトル」とは、第３実施形態で述べたBD-Jモードで再生されるべきタイトルのことであり、クラスアーカイブファイルと、BD-Jオブジェクトとから構成される。
「クラスアーカイブファイル」は、バイトコードアプリケーションのクラス構造体のファイル(クラスファイル)を、デジタル証明書マニフェストファイル、ディスク署名シグネチャファイル、ディスク署名暗号鍵ファイル、パーミッションリクエストファイルとひとまとめにしてアーカイブしたファイルである。アプリケーションのロードは、このクラスアーカイブファイルをひとまとめにしてなされ、クラスロード時に、デジタル証明書、ディスク署名、ディスク署名暗号鍵を用いたアプリケーションの正当性の検証ができるようになっている。またパーミッションリクエストファイルが存在するので、アプリケーションによる動作を、一定の権限が与えられたのものに限定することができる。
クラスアーカイブファイルにアーカイブされるバイトコードアプリケーションは、BD-Jアプリケーションと呼ばれる。
３２.２.１：BD-Jアプリケーション
BD-Jアプリケーションは、Xletインターフェイスをインプリメントすることで、アプリケーションマネージャによる状態制御に供される。このXletインターフェイスには、初期状態におけるBD-Jアプリケーションの挙動を規定するインターフェイスであるpublic void initXlet(){}、スタート状態におけるBD-Jアプリケーションの挙動を規定するインターフェイスであるpublic void startXlet(){}、ポーズ状態におけるBD-Jアプリケーションの挙動を規定するインターフェイスであるpublic void pauseXlet(){}、デストロイ状態におけるBD-Jアプリケーションの挙動を規定するインターフェイスであるpublic void destroyXlet(){}があり、これら初期状態、スタート状態、ポーズ状態、デストロイ状態の挙動が、オブジェクト指向プログラミング言語で記述される。またpublic void KeyListener(){}インターフェイスをインプリメントすることで、特定のキーイベントに応じたBD-Jアプリケーションの挙動を記述することができる。
public void ControllerListner(){}インターフェイスをインプリメントすることで、JMFプレーヤのコントローラの状態変化に応じたBD-Jアプリケーションの挙動を定義することができる。ここで、BD-Jアプリケーションのうち、例外処理の発生が想定される挙動については、try文を使用して記述することができる。またBD-Jアプリケーションのうち、例外処理発生時の挙動については、catch文で記述することができる。
BD-Jアプリケーションにおいて立体視再生の実現に利用できるAPIには、Java2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsがある。これらのAPIを利用すれば、ネットワーク処理のためのjava.net、GUI処理のためのjava.awt、言語処理のためのjava.lang、記録媒体に対するI/O処理のためのjava.io、ユーティリティであるjava.util、メディアフレームワークのためのjavax.media、HAViデバイスのためのorg.havi.uiといったクラスのメソッド、コンストラクタ、インターフェイス、イベントを用いた構造化プログラミングで、3D再生が可能なBD-Jタイトルの記述が可能になる。
またBD-JモードのためのエクステンションAPI(BD-Jエクステンションと呼ばれる)を用いることで、これまでの実施形態で述べた立体視再生のためのデータ構造、立体視再生における再生単位を用いた制御を実現する。このBD-Jエクステンションはjava.net、java.awt、java.lang、java.io、java.util、javax.mediaクラスのメソッドからのインへリッドメソッドを含み、これらのクラスのインターフェイスをエンベデッドインターフェイス、スーパーインターフェイスとしているので、java.net、java.awt、java.lang、java.io、java.util、javax.mediaクラスを用いたプログラミング技法の延長線上で、立体視再生を前提にしたBD-Jタイトルを作成することができる。
例えばBD-JモードのためのエクステンションAPIは、再生装置の状態設定や状態取得を命じる設定取得クラスを含む。かかる設定取得クラスは、プレーヤ状態レジスタ(PSR)の保持値を示すコンスタントフィールドと、PSRの保持値の取得を命じる取得メソッドと、PSRの保持値の設定を命じる設定メソッドとから構成される。
設定取得クラスのメソッドは、java.lang.Objectクラスのメソッドのインヘリッドメソッドを含む。また、メソッドコールの際の引数が不正であれば、java.langクラスのイベントであるjava.lang.IlleghalArgumentExceptionイベントをスロウする。本クラスは、java.lang.Objectのメソッドやイベントを継承しているので、プログラマは、java.lang.Objectの延長線で、レジスタセットの保持値を利用したプログラムを作成することができる。以上がクラスアーカイブファイルについての説明である。
３２.２.２：BD-Jオブジェクトの詳細
続いて、BD-Jモードの動作モードオブジェクトであるBD-Jオブジェクトの詳細について説明する。
「BD-Jオブジェクト」は、BD-Jモードにおける再生装置の挙動の詳細を規定する。その挙動の詳細には、対応するタイトルがカレントタイトルになった際のアプリケーションのクラスロード(1)、対応するタイトルがカレントタイトルになった際のアプリケーションシグナリング(2）、当該アプリケーションシグナリングによって起動されたアプリケーションがGUI処理を実行するにあたってのHAViデバイスコンフィグレーション(3)、当該カレントタイトルにおけるプレイリストアクセス(4)、対応するタイトルがカレントタイトルになった場合のクラスアーカイブファイルのキャッシュイン・キャッシュアウト(5)、起動されたアプリケーションのトリガとなるイベントをキーに割り当てるというイベント割当て(6)がある。
「クラスロード」とは、クラスアーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成する処理であり、「アプリケーションシグナリング」は、クラスファイルのインスタンスであるアプリケーションを自動起動させるか否か、又は、アプリケーションの生存区間をタイトルバウンダリーとするかディスクバウンダリーとするかを規定する制御である。タイトルバウンダリーとは、タイトルの終了と同時にアプリケーションであるスレッドをヒープ領域から消滅させるという管理であり、ディスクバウンダリーとは、ディスクイジェクトと同時にアプリケーションであるスレッドをヒープ領域から消滅させる管理である。逆にディスクイジェクトがされてもスレッドをヒープ領域から削除しない制御を「ディスクアンバウンダリー」という。「HAViデバイスコンフィグレーション」は、アプリケーションがGUI処理を実行するにあたってのグラフィクスプレーンの解像度や文字表示に用いるフォント等を規定するものである。
「プレイリストアクセス」とは、起動されたアプリケーションが再生を命じることができるプレイリストやタイトル選択時に自動的に再生すべきプレイリストの指定である。
「クラスアーカイブファイルのキャッシュイン」とは、クラスロードの対象となるクラスアーカイブファイルをキャッシュに先読みするとの処理であり、「クラスアーカイブファイルのキャッシュアウト」とは、キャッシュに存在するクラスアーカイブファイルをキャッシュから削除するとの処理である。「アプリケーション駆動のためのイベント割当」は、ユーザが操作可能なキーに、アプリケーションのイベントリスナに登録されているイベントを割り当てるというものである。
バイトコードアプリケーションのうち、BD-Jオブジェクト内のアプリケーション管理テーブルでアプリケーションシグナリングがなされるものを「BD-Jアプリケーション」という。、HDMVタイトルをBD-Jタイトルと対比すると、上述のHDMVタイトルでは、ナビゲーションコマンドを実行するためのコマンドインタプリタやプレイリストを解読して再生するための再生制御エンジンといったモジュールがソフトウェアの動作主体になる。
これに対しBD-Jタイトルでは、クラスロードのためのクラスローダやアプリケーションシグナリングのためのアプリケーションマネージャ、HAViデバイス、Javaメディアフレームワークによるプレイリスト再生のための再生制御エンジン、キャッシュイン・キャッシュアウト管理のためのキャッシュマネージャ、イベント処理のためのイベントマネージャといったソフトウェア群、つまり、デジタル放送のマルチメディアプラットフォーム端末におけるソフトウェア群と良く似たソフトウェア群が動作主体になるので、BD-JタイトルからHDMVタイトルへの切り替わり、HDMVタイトルからBD-Jタイトルへの切り替わりでは、再生装置におけるソフトウェア構成が大きく異なるものになる。
再生モードが切り替え後のソフトウェアの動作主体にとって、最適なものになっているかの確認と、切り替え後の動作モードに最適な再生モードの選択という2つの処理を実現するべく、最適な再生モードを選択するためのプロシージャをカレントタイトルの選択時に実行する。
３２.２.３：BD-Jオブジェクトの内部構成
以降、BD-Jオブジェクトについて説明する。図３２は、BD-Jオブジェクトの内部構成の一例を示す図である。本図に示すようにBD-Jオブジェクトは、「アプリケーション管理テーブル」、「端末管理テーブル」、「アプリケーションキャッシュ情報」、「プレイリストアクセス情報」、「キーインタレストテーブル」から構成される。
「アプリケーション管理テーブル」は、タイトルをバウンダリィとしたアプリケーションシグナリングをアプリケーションマネージャやクラスローダに指示する制御テーブルであり、「端末管理テーブル」は、GUIを実現するためのHAViデバイスコンフィグレーションやGUIに用いるフォント、ユーザ操作のマスクの有無をマルチディアホームプラットフォーム(MHP)に指示する管理テーブルである。「アプリケーションキャッシュ情報」は、タイトル選択時のアーカイブファイルのキャッシュイン／キャッシュアウトをキャッシュマネージャに指示する制御テーブルであり、「プレイリストアクセス情報」タイトル選択時におけるプレイリストの自動再生の指定を再生制御エンジン(PCE)に指示する制御テーブルである。「キーインタレストテーブル」は、キーと、イベントとの対応付けをイベントマネージャに指示する制御テーブルである。
引き出し線bj1は、アプリケーション管理テーブルにおけるエントリーをクローズアップして示している。この引き出し線に示すように、アプリケーション管理テーブルのエントリーは、タイトルにおいて、アプリケーションを自動的に起動させるべきか(AutoStart)、他のアプリケーションからの呼出しを待って起動すべきか(Present)という起動の仕方を示す「制御コード」と、「アプリケーションタイプ」と、起動すべきBD-Jアプリケーションをアーカイブしたアーカイブファイルのファイル名となる５桁の数値を用いて、対象となるアプリケーションを示す「アプリケーションID」と、「アプリケーション記述子」を含む。引き出し線bj2は、「アプリケーション記述子」の内部構成をクローズアップして示している。本引出線に示すように、「アプリケーション記述子」は、アプリケーションがロードされる場合の「優先度」と、アプリケーションがタイトルアンバウンドであるか否か、ディスクバウンドであるか否かを示す「バインディング情報」と、アプリケーションの名称を示す文字列と、アプリケーションの言語属性を示す「言語コード」と、アプリケーションに対応づけるアイコンの所在を指し示す「アイコンロケータ」と、「アプリケーションのプロファイル値」を、アプリケーション毎にして格納している。3D再生モードに対応するアプリケーションについては、このプロファイル値が=5に設定される。インデックステーブルにおけるBDMVアプリケーション情報の立体視コンテンツ存在フラグが1に設定されることは、このアプリケーションのプロファイル値が=5に設定されることが要件とされる。
引き出し線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の何れかに設定することができる。
引き出し線bj4は、プレイリストアクセス情報における自動再生プレイリストを指定する情報の内部構成をクローズアップして示している。引出線bj4に示すように、自動再生プレイリストを指定する情報として、3Dプレイリスト1920×1080、3Dプレイリスト1280×720、2Dプレイリスト1920×1080、2Dプレイリスト1280×720、2Dプレイリスト720×576、2Dプレイリスト720×480の指定が可能になる。
何れかのタイトルが選択された際、再生装置は、選択されたカレントタイトルに対応するもののプレイリストアクセス情報により指定されたプレイリストの再生を、アプリケーションからの再生指示を待つことなく開始し、プレイリスト再生の終了よりも、BD-Jアプリケーション実行が先に終了した場合、プレイリストの再生を継続して行う。
こうした先行再生により、アプリケーションのクラスロードに時間がかかり、描画イメージが表示されないため、対話画面がなかなか出力されないような場合、プレイリスト再生による再生映像がそのまま出力させるので、アプリケーションにおける起動遅延が顕著な場合でも、とりあえずプレイリストの再生映像をユーザに視聴させることができる。アプリケーションのスターティングディレィの間、何かが写っている状態にしておくことができるので、ユーザに安心感を与えることができる。
３３.１：タイトル切り替え時におけるグラフィクスプレーン設定
図３３は、タイトル切り替え時におけるプレーンメモリの解像度設定の処理手順の一例を示すフローチャートである。本フローチャートは、ステップＳ６１、ステップＳ６２、ステップＳ６３、ステップＳ６６の判定結果に応じて、ステップＳ６４、ステップＳ６５、ステップＳ６７の処理を選択的に実行する。
ステップＳ６１は、自動再生プレイリストが存在するかどうかの判定であり、ステップＳ６２は、直前の再生モードは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に設定する。
３３.２：再生モードと、グラフィクスプレーンコンフィグレーションとの関連性
立体視再生に対応した3Dプレイリストが再生対象として選ばれることで、再生装置のモードは、2D再生モードから3D再生モードから切り替わる。しかし、再生モードが3D再生モードになったとしても、グラフィクスプレーンは、1プレーン構成の状態を維持する。つまり、setConfiguraion APIをコールすることで、グラフィクスプレーンのコンフィグレーションを1プレーン構成から2プレーン構成に切り替えることが要求されない限り、グラフィクスプレーンは、1プレーン構成の状態を維持する。
同様にカレントタイトルの選択時において、立体視再生に対応した3Dプレイリストが、自動再生プレイリストとして選ばれることでも、再生装置のモードは、2D再生モードから3D再生モードから切り替わる。しかし、立体視再生に対応した3Dプレイリストが、自動再生プレイリストとして選ばれて、再生モードが3D再生モードになったとしても、グラフィクスプレーンは、1プレーン構成の状態を維持する。
ところが、カレントタイトルの選択時において、カレントタイトルに対応するBD-JオブジェクトのHAViデバイスコンフィグレーションが、左目用グラフィクスプレーン、右目用グラフィクスプレーンのコンフィグレーションを示している場合、グラフィクスプレーンのコンフィグレーションは、1プレーン構成から2プレーン構成に自動的に切り替わる。つまり、1プレーン構成から2プレーン構成へのコンフィグレーション切替えは、カレントタイトルの選択時において、カレントタイトルに対応するBD-JオブジェクトのHAViデバイスコンフィグレーションが、左目用グラフィクスプレーン、右目用グラフィクスプレーンのコンフィグレーションを示しているか、又は、2プレーン構成を要求するsetConfiguraion APIが要求されることが要件になる。
３３.３：グラフィクス描画要求無視の必然性
BD-JオブジェクトのHAViデバイスコンフィグレーションにおいて、グラフィクスプレーンが2プレーン構成であるか、1プレーン構成であるかが設定されるので、カレントタイトルの選択時において、1プレーン構成から2プレーン構成へのコンフィグレーション切り替え、1プレーン構成から2プレーン構成へのコンフィグレーション切り替えが実行される。このようなコンフィグレーション切り替えにおいては、第１実施形態で述べた状況、つまり、1プレーン構成から2プレーン構成へのコンフィグレーションの切り替え後に、2Dグラフィクス描画要求がjava.awt.Graphicsに到達するという状況が生じる。そこで、カレントタイトルの選択時において、1プレーン構成から2プレーン構成へのコンフィグレーションの切り替え時においては、2Dグラフィクス描画要求の無効化、グラフィクスプレーンコピー、右目用出力系統の切り替え、3Dグラフィクス描画要求受け入れを実行し、2プレーン構成から1プレーン構成へのコンフィグレーション切り替え時においては、3Dグラフィクス描画要求の禁止、右目用出力系統の切り替え、2Dグラフィクス描画要求の受け入れを実行する。こうすることで、1プレーン構成から2プレーン構成へのコンフィグレーションの切り替え後に、2Dグラフィクス描画要求がjava.awt.Graphicsに到達することによる左右の視覚の不一致発生を解消することができる。
以上のように本実施形態によれば、カレントタイトルの選択時において、BD-Jオブジェクトに基づき、HAViデバイスコンフィグレーションで規定された解像度を用いて立体視再生を実現することができる。
（第６実施形態)
本実施形態では、1プレーン構成である1plane＋Offsetモードにおいて画像が飛び出す原理について説明する。1plane＋Offsetモードでは、左目瞳孔入射期間における描画イメージの書き込み位置を右方向へずらし、右目瞳孔入射期間における描画イメージの書き込み位置を左方向へずらすことで、立体視映像を表示画面よりも手前にあるように見せることができる。
３４：1plane＋Offsetモードにおいて画像を飛出させる原理
図３４は、プレーンオフセットの符号が正である場合、像が表示画面よりも手前にあるように見える原理を説明するための図である。
本図において、丸で示したものは、表示画面上に表示される像である。まず、2D再生モードである場合、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図３４（ａ））。結果として表示される像は表示画面上に位置する。
左目瞳孔入射期間において、左目に見える像はプレーンオフセットが０の場合に比べて右側の位置に見えるようシフトして表示する。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、プレーンオフセットが０の場合に比べて左側の位置に見えるようにシフトして表示する。このとき左目にはシャッター眼鏡５００により何も見えないようにする（図３４（ｂ））。
人間は両目を用いて焦点をあわせてその焦点位置に像があるように認識する。従って、シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態とを交互に短い時間間隔で切り替えると、人間の両目は表示画面よりも手前の位置に焦点位置を、合わせようとし、結果として表示画面よりも手前に位置する焦点位置に像があるように錯覚を起こす（図３４（ｃ））。
３５：1plane＋Offsetモードにおいて画像を表示画面から奥に見せる原理
図３５は、画像が表示画面よりも奥にあるように見せる原理を説明するための図である。 図３５（ａ）において、丸で示したものは、表示画面上に表示される像である。まず2Dモードにおいて、右目に見える像も左目に見える像も同じ位置であるため、両目を用いて、この像を見たときの焦点位置は、表示画面上に位置する（図３５（ａ））。結果として表示される像は表示画面上に位置する。
一方、左目瞳孔入射期間において、左目に見える像はプレーンオフセットが０の場合に比べて左側の位置に見えるようにする。このとき右目にはシャッター眼鏡５００により何も見えないようにする。一方、右目に見える像は、オフセットが０の場合に比べて右側の位置に見えるようにする、このとき左目にはシャッター眼鏡５００により何も見えないようにする（図３５（ｂ））。
シャッター眼鏡５００により左目に像が見える状態と、右目に像が見える状態と互に短い時間間隔で切り替えると、人間の両目は表示画面よりも奥の位置に焦点位置を、合わせようとし、結果として表示画面よりも奥の位置に像があるように錯覚を起こす（図３５（ｃ））。
３６：1plane＋Offsetモードにおけるオフセットの正負の違い
図３６は、正と負のプレーンオフセットの見え方の違いの一例を示す図である。
本図（ａ）は、左目瞳孔入射期間における描画イメージの書き込み位置を右方向へずらし、右目瞳孔入射期間における描画イメージの書き込み位置を左方向へずらす場合を示す。図３４に示したように左目瞳孔への入射出力時のグラフィクスが右目瞳孔への入射出力時のグラフィクスより右の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより手前にくるので、グラフィクスも手前に見えるようになる。
本図（ｂ）は、左目瞳孔入射期間における描画イメージの書き込み位置を左方向へずらし、右目瞳孔入射期間における描画イメージの書き込み位置を右方向へずらす場合を示す。図３５に示したように、左目瞳孔への入射出力時のグラフィクスが右目瞳孔への入射の出力時のグラフィクスより左の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより奥にゆくので、グラフィクスも奥に見えるようになる。以上が、1プレーン構成のコンフィグレーションである場合の、立体視画像の見え方の説明である。
３６.１：グラフィクスプレーンにおける1plane＋Offsetモードの実現
グラフィクスプレーンは、複数のラインメモリからなり、グラフィクスを構成するARBG形式の画素データは、グラフィクスプレーンのラインメモリを構成するダブルワード(３２ビット)長の記憶素子にそれぞれ格納される。そしてグラフィクスを構成する画素データの画面上の座標は、例えばグラフィクスプレーンにおける画素データのラインメモリを指示するROWアドレスと、そのラインメモリにおける記憶素子を指示するCOLUMNアドレスとの組みに対応する。
1plane＋Offsetモードでは、グラフィクスプレーンにおける画素データのＸ座標に水平方向のオフセットを与えることで、立体視を実現する。上述したように、OSDを構成する画素データの画面上の座標は、グラフィクスプレーンにおける画素データのラインメモリを指示するROWアドレスと、そのラインメモリにおける記憶素子を指示するCOLUMNアドレスとの組みに対応するので、グラフィクスプレーンにおけるグラフィクスの各画素データの記憶素子を指示するCOLUMNアドレスを、水平方向のオフセットに相当するアドレスだけ、増減させれば、画素データの座標を左右方向に変位させることができる。画素データのアドレスシフトは、アドレス調整を伴う画素データのコピー処理によって実現できる。ここで、水平方向のオフセットにて指定される画素数Xだけ、画素データのX座標を変更したい場合、画素データのコピー時において、そのコピー先となる記憶素子を指示するCOLUMNアドレスを、画素数Xに相当するアドレスだけ前後に調整しておく。このような調整を前提にしてコピーを実行すれば、画素データの座標は、左右方向にシフトすることになる。プレーン合成器がレイヤ合成を行う際、グラフィクスプレーンを構成するラインメモリと、プレーン合成器内のラインメモリとの間で、上記画素データのコピーはなされるので、このコピーの際、上述したようなアドレス調整を行えば、グラフィクスプレーンの左右シフトは可能になる。
左右方向のシフト量としては、1plane＋Offsetモードにおいて、ビデオストリームのアクセスユニット構造に組込まれたオフセットシーケンスにおけるオフセットを用いる。オフセットシーケンスは、GOPにおける各フレーム毎に、水平方向のオフセットを規定されているため、1plane＋Offsetモードにおける画素の飛び出度合は、ビデオストリームと緻密に同期したものになる。
以上のように本実施形態によれば、1プレーン構成において簡易に立体視再生を実現することができるので、バイトコードアプリケーションによるグラフィクス描画処理の簡易化を実現することができる。
＜備考＞
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
（リムーバブルメディアの種類）
記憶媒体の種類は典型的にはSDカードなどのフラッシュメディアが利用されるが、USBメモリ、リムーバブルハードディスク、その他任意の種類の記憶媒体であってもよい。
(使用不可の描画要求がなされた際のエラーハンドリング)
第２実施の形態では、選択されている合成モードによって、使用可能な描画要求と使用不可の描画要求が存在する。使用不可の描画要求がなされた場合におけるエラー処理としては、以下のように処理することが望ましい。
まず、イメージ描画要求８０１は、左目用グラフィクスプレーン９にのみ描画を行うAPIである。そのため、合成モード１と合成モード３のときに呼び出された場合、合成の結果である映像出力では、左目のみが更新された映像となり、右目は更新前の映像のまま残ることになる。すなわち、左目の映像と右目の映像が食い違ってしまい、視聴者に不快感を与える恐れがあるため、このような描画要求は禁止する必要がある。そこで、合成モード２および合成モード４においてイメージ描画要求８０１が呼び出された場合にのみ、左目用グラフィクスプレーン９へのコピー処理を行うものとし、合成モード１あるいは合成モード３において呼び出された場合には、当該呼び出しを無視するものとする。従来のBD-J仕様においては、イメージ描画要求８０１に相当する機能は例外を発生しないAPIとして規定されているため、このような構成をとることにより、従来の平面視専用の再生装置の仕様との矛盾を発生させることなく、左目の映像と右目の映像の不整合を確実に防止することができる。
なお、従来仕様とは振る舞いが異なるものの、当該呼び出しを無視するのではなく、例外を発生するような構成にしてもよい。
(合成モード１、３において禁止すべき描画処理)
また、第３実施形態においては、「イメージコピー」のみを左目用グラフィクスプレーンへの描画要求の例として挙げているが、BD-Jの従来仕様に存在するその他の描画処理、例えば「矩形塗り潰し」や「文字列描画」等についても同様に、合成モード１あるいは合成モード３においては当然禁止とすべきである。
(合成モード１又は合成モード３で左右イメージ描画要求８０２が要求された場合の扱い)
左右イメージ描画要求８０２は、左目用グラフィクスプレーン９と右目用グラフィクスプレーン１０を同時に描画する機能であり、合成モード１あるいは合成モード３において呼び出された場合には意味を持つが、合成モード２および合成モード４において呼び出された場合は、左目用の描画しか意味を持たないため、BD-Jアプリの誤りである可能性が高い。そこで、合成モード１あるいは合成モード３において左右イメージ描画要求８０２が呼び出された場合のみ、両グラフィクスプレーンへの描画処理を行うものとし、合成モード２および合成モード４において呼び出された場合には、例外を発生させるものとする。
左右イメージ描画要求８０２は、従来のBD-J仕様には存在しない新しく定義されるAPIであり、例外を発生させても従来仕様との矛盾は起こらないため、確実に開発者にエラーを通知するために例外を発生させる方法が望ましいが、イメージ描画要求８０１と同様に、当該呼び出しを無視する構成としてもよい。
(合成モード３又は合成モード４でバックグラウンド描画要求８０４が要求された場合の扱い)
バックグラウンド描画要求８０４についても同様に、合成モード３および合成モード４においてのみ意味を持ち、合成モード１あるいは合成モード２において呼び出された場合は、合成結果の映像出力が左目と右目で食い違ってしまうため、禁止する必要がある。禁止の仕方としては、左右イメージ描画要求８０２と同様に例外を発生させるものとするが、当該呼び出しを無視する構成としてもよい。

バックグラウンド描画要求８０５についても同様に、合成モード１あるいは合成モード２においてのみ意味を持ち、合成モード３および合成モード４において呼び出された場合は、BD-Jアプリの誤りの可能性が大きいため、禁止するのが望ましい。禁止の仕方としては、左右イメージ描画要求８０２と同様に例外を発生させるものとするが、当該呼び出しを無視する構成としてもよい。
以上のように、特にイメージ描画要求８０１およびバックグラウンド描画要求８０４について、描画要求を受けつける合成モードを制限することにより、BD-Jアプリが誤った合成モードで描画を行おうとした場合でも、立体視のBD-ROM再生機器の上で発生しうる、左目用映像と右目用映像の不整合という問題を防止することが可能となる。
(描画要求を受け付けた上での不整合回避)
これまでの実施形態においては、禁止されている描画要求が発行された場合には、当該要求を無視するか例外を発生させる構成としたが、描画要求を受け付けたうえで左目用映像と右目用映像の不整合が起きないように処理する構成としてもよい。具体的には、例えば合成モード１あるいは合成モード３においてイメージ描画要求８０１が呼び出された場合には、左目用グラフィクスプレーン９に対してのみ描画処理を行うのではなく、左目用グラフィクスプレーン９および右目用グラフィクスプレーン１０に対して同時に、同一の描画処理を適用することで、左目用映像と右目用映像の不整合を防ぐことができる。また、合成モード２あるいは合成モード４において左右イメージ描画要求８０２が呼び出された場合には、描画要求の中の左目用グラフィクスプレーン９に対する描画処理部分のみを抽出して実行すれば、グラフィクスプレーンが１プレーンの状況においても左右イメージ描画要求８０２を処理することが可能となる。さらに、合成モード切替中に存在する、イメージ描画要求８０１および左右イメージ描画要求８０２の両方が禁止されているタイミングにこれらの描画要求が呼び出されば場合については、当該描画要求を一旦保留しておき、合成モード切替処理が完了したタイミングで処理を再開するようにすればよい。
(合成モードの切り替え回数)
なお、グラフィクスプレーンの切り替えとバックグラウンドプレーンの切替の両方が必要な場合においては、プレーン合成器２０の合成モード切替を一回で済むようにしてもよい。例えば、合成モード切替に時間がかかる場合などにおいては、合成モード切替を一回で済ませる方が望ましい。例えば、グラフィクスプレーンとバックグラウンドプレーンの双方を１プレーンから２プレーンに切替える、つまり合成モード４から合成モード１に切替える場合について考える。まずS１００１の１プレーン用描画要求の禁止を、グラフィクスプレーンとバックグラウンドプレーンの双方に対して行う、すなわち、イメージ描画要求８０１およびバックグラウンド描画要求８０４の両方を禁止する。続いて、S１００２のコピー処理についても、グラフィクスプレーンとバックグラウンドプレーンの双方に対して、左目用プレーンから右目用プレーンへのコピーを行う。次に、S１００３の合成モード切替処理として、プレーン合成器２０を合成モード４から合成モード１に直接切替える。最後に、S１００４の２プレーン用描画要求の禁止の解除についても、グラフィクスプレーンとバックグラウンドプレーンの双方に対して行う、すなわち、左右イメージ描画要求８０２およびバックグラウンド描画要求８０５の両方の禁止を解除すればよい。
(2D再生モードにおける合成モード)
第３実施形態では、１プレーンにおける2D再生モードの合成モードにおいては常に左目用のプレーンのみを使用する構成としたが、１プレーンの合成モードにおいても、左目用プレーンのみを使用するか右目用プレーンのみを使用するかを選択可能とする構成をとってもよい。例えば、ビデオストリームが左目用の映像がメインか、右目用の映像がメインかを表す情報を持っている場合は、グラフィクスプレーンおよびバックグラウンドプレーンが１プレーンの時には、ビデオストリームに合わせる形で、左目用プレーンのみを参照するか、右目用プレーンのみを参照するかを決定すべきである。この場合、ビデオストリームが左右どちらがメインであるかの状態を再生装置２００内に保持しておき、合成モード２および合成モード４においては、左右いずれのグラフィクスプレーンを参照するかを上記状態に基づいて選択し、同様に合成モード３および合成モード４においても、左右いずれのバックグラウンドプレーンを参照するかを上記状態に基づいて選択するようにすればよい。このような構成をとることで、例えばビデオストリームが右目用の映像がメインとなっている状況下で、グラフィクスプレーンを２プレーンから１プレーンに合成モード切替を行った場合、切替前の右目用グラフィクスプレーン１０の描画内容が引き続き切替後にも参照されることになるため、よりビデオストリームとの整合性がとれた合成モード切替を実現することができる。
(右目用プレーンから左目用プレーンへのコピータイミング)
第３実施形態の合成モード２〜４において、グラフィクスプレーンおよびバックグラウンドプレーンは常に左目用プレーンのみを参照するという第３実施形態のままであっても、グラフィクスまたはバックグラウンドの合成モードを２プレーンから１プレーンへ遷移させる際に、ビデオストリームが右目用の映像がメインとなっている場合にのみ、グラフィクスまたはバックグラウンドの右目用プレーンの内容を左目用プレーンへコピーをするようにすれば、同様の効果を得ることができる。
(左目用の映像、右目用の映像の識別)
第３実施形態においては、ビデオストリームが左目用の映像がメインか、右目用の映像がメインかを表す情報を持っているものとしたが、当該情報をBD-Jアプリが指定するようにしてもよい。
(オブジェクト指向プログラミング言語による3Dプレイリスト再生手順の記述)
各実施形態では、オブジェクト指向プログラミング言語による3Dプレイリスト再生手順は、以下のように記述してもよい。
3Dプレイリストであるプレイリストファイル00001.mplsを再生しようとする場合の記述は以下の通りである。
i)3Dプレイリストのプレイリストファイルのファイルパス(bd://1.PLAYLIST:00001)を引数としたBDLocatorクラスのインスタンスを生成する。このBDLocatorクラスのインスタンス変数を“loc”とした場合、BDLocator loc ＝ newBDlocator(bd://1.PLAYLIST:00001)と記述する。
ii)BDLocatorクラスのインスタンス変数の変数名を引数としたMediaLocatorクラスのインスタンスを生成する。BDLocatorクラスのインスタンス変数の変数名が“loc”であり、MediaLocatorクラスのインスタンス変数の変数名をm1とすれば、
MediaLocator m1 ＝ new MediaLocator(loc)と記述する。
iii)MediaLocatorクラスのインスタンス変数の変数名を引数としたjavax.media.Manager.creatPlayerクラスのインスタンス、つまりプレーヤインスタンスを生成する。MediaLocatorクラスのインスタンス変数の変数名がm1であり、プレーヤインスタンスのインスタンス変数の変数名がPlayerであれば、Player＝Manager.creatPlayer(m1);と記述する。
iv)最後に、JMFプレーヤインスタンスのメンバー関数であるstart()をコールすることでプレイリスト再生を開始する。プレーヤインスタンスのインスタンス変数の変数名がPlayerであれば、Player.start()と記述する。

(立体視対話画面の記述)
2つのボタン部材を有する立体視対話画面を作成する場合のバイトコードアプリケーションは、以下の(h-1)(h-2)(h-3)(h-4)・・・・のように記述してもよい。
(h-1)グラフィクスデバイスのインスタンスを引数として用いて、グラフィクスデバイスの振るスクリーンシーンのインスタンスを生成する。具体的には、Hscreen.getDefaultHscreen().getDefaultHGraphicsDevice()のインスタンスを引数として用いて、HsceneFactory.getinstance().getFullScreenSceneのインスタンスを生成する。HsceneFactory.getinstance().getFullScreenSceneインスタンスのインスタンス変数名を“hs”とした場合、
Hscene hs＝HsceneFactory.getinstance().getFullScreenScene(Hscreen.getDefaultHscreen().getDefaultHGraphicsDevice());と記述する。
(h-2)java.awtのFlowlayout()のインスタンスを引数として、HsceneのsetLayoutメソッドをコールする。Hsceneクラスインスタンスのインスタンス変数名を“hs”とした場合、hs.setLayout(new FlowLayout());と記述する。
(h-3)Hscreenクラスのインスタンス変数を引数として用いて、java.awtのMediaTrackerクラスのインスタンスを生成する。Hscreenクラスインスタンスのインスタンス変数名を“hs”とし、MediaTrackerクラスのインスタンス変数を“mt”とした場合、
MediaTracker mt＝newMediaTracker(hs);と記述する。
(h-4)左目用イメージファイル及び右目用イメージファイルのファイル名を引数として用いてStereoGraphics#drawImageをコールすることで、ノーマル状態のイメージクラスのインスタンス、フォーカス状態のイメージクラスのインスタンス、アクション状態のイメージクラスのインスタンスを作成する。
例えば、ボタン部材のノーマル状態のイメージクラスのインスタンス変数の変数名をnormalとし、左目用イメージファイルのファイル名を“NormalButton1.bmp”、右目用イメージファイルのファイル名を“NormalButton2.bmp”とした場合、
Image normal ＝ StereoGraphics#drawImage(x1,y1,x2,y2,NormalButton1.bmp,x3,y3,x4,y4,NormalButton2.bmp);
と記述する。
例えば、ボタン部材のフォーカス状態のイメージクラスのインスタンス変数の変数名をfocusedとし、左目用イメージファイルのファイル名を“FocusedButton1.bmp”、右目用イメージファイルのファイル名を“FocusedButton2.bmp”とした場合、
Image focused ＝ StereoGraphics#drawImage(x1,y1,x2,y2,FocusedButton1.bmp,x3,y3,x4,y4,FocusedButton2.bmp);
と記述する。
例えば、ボタン部材のアクション状態のイメージクラスのインスタンス変数の変数名をactionedとし、左目用イメージファイルのファイル名を“actionedButton1.bmp”、右目用イメージファイルのファイル名を“actionedButton2.bmp”とした場合、
Image actioned ＝ StereoGraphics#drawImage(x1,y1,x2,y2,actionedButton1.bmp,x3,y3,x4,y4,actionedButton2.bmp);
と記述する。
(h-5)状態イメージを引数としてMediaTrackerクラスのaddImageメソッドをコールすることで、MediaTrackerクラスのインスタンスにノーマル状態の状態イメージ、フォーカス状態の状態イメージ、アクション状態の状態イメージを追加する。
MediaTrackerクラスインスタンスのインスタンス変数名をmtとした場合、
mt.addImage(normal,0);
mt.addImage(focused,0);
mt.addImage(actioned,0);と記述する。
(h-6)java.awtのHGraphicsButtonクラスのインスタンスを生成する。HGraphicsButtonクラスインスタンスのインスタンス変数名を“hgb1,hgb2”とし、ボタン部材の状態が“normal”、“focused”、“actioned”である場合、
hgb1 = new HGraphicsButton(normal、focused、actioned);
hgb2 = new HGraphicsButton(normal、focused、actioned);
と記述する。
(h-7)setLayoutクラスのメンバー関数であるadd()を使用して、setLayoutクラスのインスタンスに、HGraphicsButtonクラスのインスタンスを追加する。setLayoutクラスのインスタンス変数の変数名を“hs”とし、追加すべきHGraphicsButtonクラスのインスタンスのインスタンス名を“hgb1,hgb2”とした場合、hs.add(hgb1); hs.add(hgb1);と記述する。
(h-8)setLayoutクラスのメンバー関数であるsetVisibleメソッドを使用して、setLayoutクラスのインスタンスを可視化する。setLayoutクラスのインスタンス変数の変数名を“hs”とした場合、hs.setVisible(true);と記述する。

(h-9)HGraphicsButtonクラスのメンバー関数であるrequestFocusメソッドを使用して、HGraphicsButtonクラスのインスタンスをフォーカス状態にする。HGraphicsButtonクラスのインスタンスの変数名を“hgb1”とした場合、hgb1.requestFocus();と記述する。

(再生装置２００と、テレビ４００との接続)
再生装置２００と、テレビ４００との接続は、高バンド幅転送機能を有するデジタルインターフェイスを介してなされるのが望ましい。
高バンド幅転送機能を有するデジタルインターフェイスは、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、ネゴシエーションフェーズを経て、データ伝送フェーズに移行し、データ伝送を行う。
このネゴシエーションフェーズは、デジタルインターフェイスのテレビのケーパビリティ(デコード能力、再生能力、表示周波数を含む)を把握して、プレーヤ設定レジスタに設定しておき、以降の伝送のための伝送方式を定めるものであり、互いの装置の正当性を確認し合う相互認証フェーズを含む。このネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮・平文形式の画素データを、テレビにおける水平同期期間に従いテレビに高い転送レートで転送する。一方、テレビにおける水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置(テレビのみならずアンプ、スピーカを含む)に、非圧縮・平文形式のオーディオデータを転送する。こうすることで、テレビ、アンプ、スピーカといった機器は、非圧縮・平文形式のピクチャデータ、非圧縮・平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮・暗号化形式のまま伝送することができる。このような高バンド幅転送機能を有するデジタルインターフェイスには、HDMIやUSBが存在する。
(集積回路の実施形態)
本発明にかかる集積回路は、システムLSIであり、再生装置のハードウェア構成のうち、記録媒体のドライブ部や、外部とのコネクタ等、機構的な部分を排除して、論理回路や記憶素子に該当する部分、つまり、論理回路の中核部分を内蔵したものである。システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものはマルチチップモジュールと呼ばれるが、このようなものに、システムLSIに含まれる。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、電源供給やグランド、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
図３７は、集積回路のアーキテクチャを示す図である。本図に示すように、システムLSIである集積回路７０のアーキテクチャは、フロントエンド部７１と、信号処理部７２と、バックエンド部７３と、メディアインターフェイス７４と、メモリコントローラ７５と、ホストマイコン７６とから構成され、メディアインターフェイス７４、メモリコントローラ７５を通じて、再生装置におけるドライブやメモリ、送受信部と接続されている。再生装置におけるドライブには、BD-ROMのドライブ、ローカルストレージのドライブ、リムーバブルメディアのドライブ等がある。
フロントエンド処理部７１は、プリプログラムされたDMAマスタ回路やI/Oプロセッサ等から構成され、パケット処理全般を実行する。このパケット処理には、立体視インターリーブドストリームファイルからATCシーケンスを復元する処理、多重分離部によるソースパケットデパケッタイザの処理、PIDフィルタの処理が該当する。再生装置のメモリに確保された、トラックバッファ、各種プレーンメモリ、ビデオデコーダにおけるコーデッドデータバッファ、デコーデッドデータバッファ間でDMA転送を実現することにより、上述したようなストリーム処理を実現する。
信号処理部７２は、信号処理プロセッサやSIMDプロセッサ等から構成され、信号処理全般を実行する。信号処理には、ビデオデコーダによるデコードやオーディオデコーダによるデコードがある。
バックエンド部７３は、加算器、フィルタから構成され、AV出力処理全般を行う。AV出力処理には画素処理があり、かかる画素処理によってレイヤ合成のための画像重畳、リサイズ、画像フォーマット変換がなされる。また、デジタル／アナログ変換等を併せて実行する。
メディアインターフェイス７４は、ドライブ、ネットワークとのインターフェイスである。
メモリコントローラ７５は、メモリアクセスのためのスレーブ回路であり、フロントエンド部、信号処理部、バックエンド部の要求に応じて、パケットやピクチャデータのメモリの読み書きを実現する。 このメモリコントローラ７５を通じたメモリの読み書きによって、メモリは、トラックバッファやビデオプレーン、グラフィクスプレーン、ビデオデコーダにおけるコーデッドデータバッファ、デコーデッドデータバッファ、エレメンタリバッファ、グラフィクスデコーダにおけるコーデッドデータバッファ、コンポジションデータバッファ、オブジェクトバッファとして機能することになる。
ホストマイコン７６は、CPU,ROM,RAMから構成され、メディアインターフェイス、フロントエンド部、信号処理部、バックエンド部に対して、全体制御を実行する。この全体制御には、制御部、BD-Jモジュール、HDMVモジュール、モジュールマネージャとしての制御がある。このホストマイコンにおけるCPUは、命令フェッチ部、デコーダ、実行ユニット、レジスタファイル、プログラムカウンタを有している。そして、これまでの実施形態で述べた各種処理を実行するプログラムは、組込プログラムとして、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)と共に、このホストマイコンにおけるマイコン内のROMに記憶されている。よって再生装置の主たる機能は、このシステムLSI内に組込んでおくことができる。
（プログラムの実施形態)
各実施形態に示したプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムを非一時的なコンピュータプログラムとしてコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。
(再生装置の必須の構成)
左目用ビデオプレーン、右目用ビデオプレーンは再生装置の必須の構成ではなく、再生装置の構成としては、左目用グラフィクスプレーン、右目用グラフィクスプレーンが存在すれば足りる。グラフィクスプレーンで表示すべき描画イメージには、動画像のものがあり、かかる描画イメージをグラフィクスプレーンに書き込めば、ビデオデコーダやビデオプレーンが再生装置に存在せずとも、本願の課題解決を図ることができるからである。
(ホームシアターシステムの必須の構成)
シャッター眼鏡５００は、必須の構成要素ではなく任意的なものである。何故なら、テレビ４００がインテグラルイメージング方式(光学再生方式)であり、裸眼立体視が可能なものなら、シャッター眼鏡５００は不要となるからである。テレビ４００と、再生装置２００とを一体構成にしてもよい。
（半導体メモリカード記録装置及び再生装置の実施形態)
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
まず、前提となる技術として、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を介して読み出すように構成すれば良い。
(受信装置としての実施形態)
各実施形態で説明した再生装置は、本実施の形態で説明をしたデータに相応するデータ（配信データ）を電子配信サービスの配信サーバから受信し、半導体メモリカードに記録する端末装置としても実現することができる。
かかる端末装置は、各実施形態で説明した再生装置がそのような動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDカードを例に説明をする。
再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバへ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報（例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等）をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。
この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。
例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。
生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。
次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。
次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、（１） 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック（２） 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。
上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いて、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
本発明は、立体視映像を再生する再生機器において、出力映像のちらつきを抑止する技術に関し、特に平面的な映像再生モードと立体的な映像再生モードの切替機能を持つ再生装置に適用可能である。
１ BD-ROMドライブ
４ ビデオデコーダ
５ 左目用ビデオプレーン
６ 右目用ビデオプレーン
７ イメージメモリ
８ イメージデコーダ
９ 左目用グラフィクスプレーン
１０ 右目用グラフィクスプレーン
１５ BD-Jモジュール
２０ プレーン合成器
２２ レンダリングエンジン
２８ 左目用バックグラウンドプレーン
２９ 右目用バックグラウンドプレーン
３０ 左目用字幕プレーン
３１ 右目用字幕プレーン
１００ BD-ROM
２００ 再生装置
３００ リモコン
４００ ディスプレイ
５００ シャッター/偏光眼鏡

Claims (3)

  1. バイトコードアプリケーションを動作させるプラットフォーム部と、
    第1のグラフィクスプレーンと、
    第２のグラフィクスプレーンと、
    前記プラットフォーム部が、前記バイトコードアプリケーションからのグラフィクスの描画の要求を受け付けて前記グラフィクスの描画を実行する描画部と、
    平面像のグラフィックスを再生する場合において、前記平面像のグラフィクスの描画に前記第1のグラフィクスプレーンを使用する１プレーン構成と、立体像のグラフィックスを再生する場合において、前記立体像のグラフィクスの描画に前記第1のグラフィクスプレーン及び前記第２のグラフィクスプレーンを使用する２プレーン構成のうちの一方のプレーン構成から他方のプレーン構成に切り替える切り替え部とを備え、
    前記グラフィクスの描画要求には、前記平面像のグラフィクスの描画要求と、前記立体像のグラフィクスの描画要求とがあり、
    前記切り替え部により前記１プレーン構成から、前記２プレーン構成へ切り替えるとき、前記バイトコードアプリケーションによってなされた前記前記平面像のグラフィクスの描画要求を無効化し、かつ、前記第1のグラフィクスプレーンの格納内容を前記第２のグラフィクスプレーンにコピーした後に、前記描画部は前記立体像のグラフィクスの描画要求を受け入れる
    ことを特徴とする再生装置。
  2. バイトコードアプリケーションを動作させるプラットフォーム部と、第1のグラフィクスプレーンと、第２のグラフィクスプレーンとを備えるコンピュータに用いる再生方法であって、
    平面像のグラフィックスを再生する場合において、前記平面像のグラフィクスの描画に前記第1のグラフィクスプレーンを使用する１プレーン構成と、立体像のグラフィックスを再生する場合において、前記立体像のグラフィクスの描画に前記第1のグラフィクスプレーン及び前記第２のグラフィクスプレーンを使用する２プレーン構成のうちの一方のプレーン構成から他方のプレーン構成に切り替える切り替えステップを含み、
    前記グラフィクスの描画要求には、前記平面像のグラフィクスの描画要求と、前記立体像のグラフィクスの描画要求とがあり、
    前記切り替えステップにより前記１プレーン構成から、前記２プレーン構成へ切り替えるとき、前記バイトコードアプリケーションによってなされた前記平面像のグラフィクスの描画要求を無効化する第1のステップと、前記第1のグラフィクスプレーンの格納内容を前記第２のグラフィクスプレーンにコピーする第２のステップとがなされた後に、前記立体像のグラフィクスの描画要求を受け入れる
    ことを特徴とする再生方法。
  3. バイトコードアプリケーションを動作させるプラットフォーム部と、第1のグラフィクスプレーンと、第２のグラフィクスプレーンとを備えるコンピュータを動作させる再生プログラムであって、
    平面像のグラフィックスを再生する場合において、前記平面像のグラフィクスの描画に前記第1のグラフィクスプレーンを使用する１プレーン構成と、立体像のグラフィックスを再生する場合において、前記立体像のグラフィクスの描画に前記第1のグラフィクスプレーン及び前記第２のグラフィクスプレーンを使用する２プレーン構成のうちの一方のプレーン構成から他方のプレーン構成に切り替える切り替えステップを含み、
    前記グラフィクスの描画要求には、前記平面像のグラフィクスの描画要求と、前記立体像のグラフィクスの描画要求とがあり、
    前記切り替えステップにより前記１プレーン構成から、前記２プレーン構成へ切り替えるとき、前記バイトコードアプリケーションによってなされた前記平面像のグラフィクスの描画要求を無効化する第1のステップと、前記第1のグラフィクスプレーンの格納内容を前記第２のグラフィクスプレーンにコピーする第２のステップとがなされた後に、前記立体像のグラフィクスの描画要求を受け入れる
    ことを特徴とするプログラム。
JP2011534065A 2009-10-02 2010-09-27 再生装置、再生方法、再生プログラム Active JP5097297B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011534065A JP5097297B2 (ja) 2009-10-02 2010-09-27 再生装置、再生方法、再生プログラム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2009230394 2009-10-02
JP2009230394 2009-10-02
PCT/JP2010/005804 WO2011039990A1 (ja) 2009-10-02 2010-09-27 立体視映像を再生することができる再生装置、集積回路、再生方法、プログラム
JP2011534065A JP5097297B2 (ja) 2009-10-02 2010-09-27 再生装置、再生方法、再生プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2012156735A Division JP5457513B2 (ja) 2009-10-02 2012-07-12 立体視映像を再生することができる再生装置

Publications (2)

Publication Number Publication Date
JP5097297B2 true JP5097297B2 (ja) 2012-12-12
JPWO2011039990A1 JPWO2011039990A1 (ja) 2013-02-21

Family

ID=43825838

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2011534065A Active JP5097297B2 (ja) 2009-10-02 2010-09-27 再生装置、再生方法、再生プログラム
JP2012156735A Expired - Fee Related JP5457513B2 (ja) 2009-10-02 2012-07-12 立体視映像を再生することができる再生装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2012156735A Expired - Fee Related JP5457513B2 (ja) 2009-10-02 2012-07-12 立体視映像を再生することができる再生装置

Country Status (7)

Country Link
US (1) US8558871B2 (ja)
EP (1) EP2485497B1 (ja)
JP (2) JP5097297B2 (ja)
KR (1) KR20120091007A (ja)
CN (1) CN102577409B (ja)
TW (1) TWI435592B (ja)
WO (1) WO2011039990A1 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5155441B2 (ja) * 2009-02-17 2013-03-06 パナソニック株式会社 再生方法、再生装置
JP4875127B2 (ja) * 2009-09-28 2012-02-15 パナソニック株式会社 三次元画像処理装置
WO2012132237A1 (ja) 2011-03-31 2012-10-04 パナソニック株式会社 立体視画像の描画を行う画像描画装置、画像描画方法、画像描画プログラム
WO2012132234A1 (ja) * 2011-03-31 2012-10-04 パナソニック株式会社 全周囲立体画像の描画を行う画像描画装置、画像描画方法、画像描画プログラム
WO2013180325A1 (ko) * 2012-05-31 2013-12-05 (주)재플 Tv 화면 제어 장치 및 이를 포함하는 시스템
US9584573B2 (en) * 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
RU2012138174A (ru) * 2012-09-06 2014-03-27 Сисвел Текнолоджи С.Р.Л. Способ компоновки формата цифрового стереоскопического видеопотока 3dz tile format
CN103347193B (zh) * 2013-07-23 2015-03-11 深圳市华星光电技术有限公司 快门眼镜、控制快门眼镜的控制系统及方法
US10935788B2 (en) * 2014-01-24 2021-03-02 Nvidia Corporation Hybrid virtual 3D rendering approach to stereovision
WO2016080066A1 (ja) * 2014-11-21 2016-05-26 富士フイルム株式会社 時系列データ表示制御装置、その作動方法及びプログラム、並びにシステム
CN106303493B (zh) * 2015-05-27 2018-06-29 深圳超多维光电子有限公司 图像处理方法及装置
US9520002B1 (en) * 2015-06-24 2016-12-13 Microsoft Technology Licensing, Llc Virtual place-located anchor
US11150915B2 (en) * 2019-09-13 2021-10-19 International Business Machines Corporation Deferred bytecode class verification in managed runtime environments
US11403075B2 (en) 2019-11-25 2022-08-02 International Business Machines Corporation Bytecode verification using class relationship caching
CN113268302B (zh) * 2021-05-27 2023-08-11 杭州灵伴科技有限公司 一种头戴式显示设备的显示模式切换方法、装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007052736A1 (ja) * 2005-11-02 2007-05-10 Matsushita Electric Industrial Co., Ltd. デジタル放送システム、受信装置、及び送出装置
WO2008044191A2 (en) * 2006-10-11 2008-04-17 Koninklijke Philips Electronics N.V. Creating three dimensional graphics data
JP2011205606A (ja) * 2009-07-14 2011-10-13 Panasonic Corp 映像再生装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3109846B2 (ja) 1991-02-20 2000-11-20 ホーチキ株式会社 消火設備の給水圧力制御システム
EP1098244A3 (en) 1999-11-02 2001-06-13 CANAL + Société Anonyme Graphical user interface
US20020154214A1 (en) 2000-11-02 2002-10-24 Laurent Scallie Virtual reality game system using pseudo 3D display driver
US7002618B2 (en) 2001-06-01 2006-02-21 Stereographics Corporation Plano-stereoscopic DVD movie
GB0129992D0 (en) 2001-12-14 2002-02-06 Ocuity Ltd Control of optical switching apparatus
US7319720B2 (en) 2002-01-28 2008-01-15 Microsoft Corporation Stereoscopic video
US6924799B2 (en) 2002-02-28 2005-08-02 Hewlett-Packard Development Company, L.P. Method, node, and network for compositing a three-dimensional stereo image from a non-stereo application
JPWO2003092303A1 (ja) 2002-04-25 2005-09-08 シャープ株式会社 マルチメディア情報生成装置およびマルチメディア情報再生装置
JP2004127255A (ja) * 2002-08-02 2004-04-22 Renesas Technology Corp 情報処理装置
JP4251907B2 (ja) * 2003-04-17 2009-04-08 シャープ株式会社 画像データ作成装置
JP4266774B2 (ja) 2003-10-29 2009-05-20 シャープ株式会社 立体画像表示装置及び立体画像表示方法
JP3746506B2 (ja) 2004-03-08 2006-02-15 一成 江良 立体視化パラメータ埋込装置及び立体視画像再生装置
JP2005321953A (ja) 2004-05-07 2005-11-17 Hitachi Ltd ストレージ制御装置、その動作プログラム、及びアクセス制御方法
WO2005124779A1 (ja) 2004-06-18 2005-12-29 Matsushita Electric Industrial Co., Ltd. 再生装置、プログラム、再生方法
EP1787470A1 (en) 2004-08-30 2007-05-23 Telecom Italia S.p.A. Method and system for providing interactive services in digital television
US20080201695A1 (en) 2007-02-16 2008-08-21 Qing Zhou Computer graphics rendering
JP4854582B2 (ja) 2007-04-25 2012-01-18 キヤノン株式会社 画像処理装置、画像処理方法
JP4689639B2 (ja) 2007-04-25 2011-05-25 キヤノン株式会社 画像処理システム
WO2010064472A1 (ja) * 2008-12-01 2010-06-10 シャープ株式会社 コンテンツ再生装置、再生方法、プログラム及び記録媒体
JP5155441B2 (ja) 2009-02-17 2013-03-06 パナソニック株式会社 再生方法、再生装置
JP4962817B2 (ja) * 2009-04-03 2012-06-27 ソニー株式会社 情報処理装置、情報処理方法、及び、プログラム
US20110080462A1 (en) 2009-10-02 2011-04-07 Panasonic Corporation Playback device, integrated circuit, playback method, and program for stereoscopic video playback
JP5454444B2 (ja) * 2010-10-01 2014-03-26 ソニー株式会社 立体画像データ送信装置、立体画像データ送信方法、立体画像データ受信装置および立体画像データ受信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007052736A1 (ja) * 2005-11-02 2007-05-10 Matsushita Electric Industrial Co., Ltd. デジタル放送システム、受信装置、及び送出装置
WO2008044191A2 (en) * 2006-10-11 2008-04-17 Koninklijke Philips Electronics N.V. Creating three dimensional graphics data
JP2011205606A (ja) * 2009-07-14 2011-10-13 Panasonic Corp 映像再生装置

Also Published As

Publication number Publication date
US8558871B2 (en) 2013-10-15
CN102577409B (zh) 2014-12-10
EP2485497A4 (en) 2013-01-09
US20120169729A1 (en) 2012-07-05
JP2012257260A (ja) 2012-12-27
WO2011039990A1 (ja) 2011-04-07
CN102577409A (zh) 2012-07-11
KR20120091007A (ko) 2012-08-17
JPWO2011039990A1 (ja) 2013-02-21
TW201138427A (en) 2011-11-01
EP2485497B1 (en) 2014-11-05
EP2485497A1 (en) 2012-08-08
JP5457513B2 (ja) 2014-04-02
TWI435592B (zh) 2014-04-21

Similar Documents

Publication Publication Date Title
JP5457513B2 (ja) 立体視映像を再生することができる再生装置
JP5155441B2 (ja) 再生方法、再生装置
JP4772163B2 (ja) 立体視再生を行う再生装置、再生方法、プログラム
JP5395117B2 (ja) 立体視再生が可能な再生装置、再生方法、プログラム
JP5632291B2 (ja) 特殊再生を考慮した再生装置、集積回路、再生方法
US20110080462A1 (en) Playback device, integrated circuit, playback method, and program for stereoscopic video playback
WO2010032403A1 (ja) 映像コンテンツを立体視再生する再生装置、再生方法、および再生プログラム
JP5469125B2 (ja) 記録媒体、再生装置、再生方法、プログラム
JPWO2012017603A1 (ja) 再生装置、集積回路、再生方法、プログラム
US20100303437A1 (en) Recording medium, playback device, integrated circuit, playback method, and program

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120828

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120921

R150 Certificate of patent or registration of utility model

Ref document number: 5097297

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150928

Year of fee payment: 3