WO2011039990A1 - 立体視映像を再生することができる再生装置、集積回路、再生方法、プログラム - Google Patents

立体視映像を再生することができる再生装置、集積回路、再生方法、プログラム Download PDF

Info

Publication number
WO2011039990A1
WO2011039990A1 PCT/JP2010/005804 JP2010005804W WO2011039990A1 WO 2011039990 A1 WO2011039990 A1 WO 2011039990A1 JP 2010005804 W JP2010005804 W JP 2010005804W WO 2011039990 A1 WO2011039990 A1 WO 2011039990A1
Authority
WO
WIPO (PCT)
Prior art keywords
plane
graphics
eye
configuration
playback
Prior art date
Application number
PCT/JP2010/005804
Other languages
English (en)
French (fr)
Inventor
山地　治
ジェルマーノ ライクセンリング
Original Assignee
パナソニック株式会社
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 パナソニック株式会社 filed Critical パナソニック株式会社
Priority to JP2011534065A priority Critical patent/JP5097297B2/ja
Priority to CN201080043782.7A priority patent/CN102577409B/zh
Priority to US13/394,837 priority patent/US8558871B2/en
Priority to EP10820112.0A priority patent/EP2485497B1/en
Publication of WO2011039990A1 publication Critical patent/WO2011039990A1/ja

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

Definitions

  • a bytecode application is an executable program obtained by compiling a class structure written using an object-oriented programming language, and is written in device-independent code (bytecode).
  • a typical bytecode application is a Java (registered trademark) application.
  • middleware For bytecode applications, various functions are provided by middleware. Functions for bytecode applications are provided by calling member functions of packages implemented by middleware.
  • the package implemented by the middleware includes a library that performs drawing processing such as drawing of graphics such as lines and rectangles with color designation, filling of designated areas, copy / paste, and the like.
  • the middleware includes a drawing unit that executes graphics drawing by the function of the library.
  • the bytecode application can implement various graphics drawing processes by continuously issuing these drawing process requests.
  • the graphics drawing package includes a java.awt package, and the graphics drawing application program interface is a method of the java.awt package.
  • the platform for the operation of the bytecode application is not limited to the one premised on the planar reproduction, and the one premised on the stereoscopic reproduction has also appeared.
  • the platform based on stereoscopic playback has a graphics plane for the left eye and a graphics plane for the right eye, and these graphics planes are switched between the planar view mode and the stereoscopic view mode.
  • Patent Document 1 by preparing a post-switching video that looks exactly the same before and after switching between the planar mode and the stereoscopic mode, the sameness of the video output before and after the mode switching is prepared. The technology that guarantees is described.
  • the bytecode application and java.awt.Graphics are processed by multiple threads at the time of execution, and parameter exchange is performed by inter-thread communication via the stack. There is a big time lag. Therefore, it is not uncommon for a 2D graphics rendering request issued by another application thread to reach java.awt.Graphics after a mode switch issued by any application thread is accepted by java.awt.Graphics. .
  • the graphics requested by the 2D graphics rendering request are written only to the left-eye graphics plane out of the right-eye graphics plane and the right-eye graphics plane secured by mode switching. Then, the graphics of both eyes will be inconsistent, giving the user a visual discomfort.
  • the period during which the left-eye-right eye inconsistency is It will be a short period.
  • the occurrence of visual inconsistencies between the left and right eyes during stereoscopic playback has a significant impact on viewers even in a short period of time, and the viewers experience stereoscopic discomfort due to the discomfort. It is fully conceivable to dislike the content itself and show a rejection reaction to related products of stereoscopic content. Regardless of the length of time, visual inconsistencies between the left and right eyes are not acceptable.
  • the manufacturer may be possible for uniformly regulate the creation of the application.
  • the application that displays the content-specific GUI is created independently by the content provider. Yes, even if it is a demand from the reproduction quality, it is almost impossible to unilaterally push the demand on the manufacturer side.
  • An object of the present invention is to provide a playback device that does not give a visual discomfort to a user who enjoys stereoscopic playback even when the time lag of a drawing request from the bytecode application to the drawing unit is great. is there.
  • a playback device that can solve the above problems
  • a platform for running bytecode applications It has a left-eye graphics plane and a right-eye graphics plane
  • the platform unit includes a drawing unit that receives a graphics drawing request from a bytecode application and executes graphics drawing
  • the left-eye graphics plane and the right-eye graphics plane are configured in a one-plane configuration in which only the left-eye graphics plane is used for graphics rendering during stereoscopic playback and stereoscopic playback.
  • the graphics drawing request includes a 2D graphics drawing request and a 3D graphics drawing request.
  • Switching from the 1-plane configuration to the 2-plane configuration in the configuration described above invalidates the 2D graphics rendering requests made by the bytecode application so far, and stores the contents of the left-eye graphics plane for the right-eye. And a process of copying to a graphics plane, and after the copy is made, the drawing unit receives a 3D graphics drawing request.
  • the playback device having the above problem solving means invalidates the 2D graphics rendering request when switching the configuration of the graphics plane from the 1 plane configuration to the 2 plane configuration, so the graphics plane from the 1 plane configuration to the 2 plane configuration Even if there is a 2D graphics rendering request that reaches the rendering unit after switching the configuration of the 2D graphics, the 2D graphics rendering request is invalidated before the interplane copy from the left-eye graphics plane to the right-eye graphics plane is made. It will be.
  • the graphics plane configuration is switched from the 1 plane configuration to the 2 plane configuration because the 2D graphics rendering request on the stack is temporarily disabled and the left eye graphics plane is copied to the right eye graphics plane. After that, when the 2D graphics drawing request arrives at the drawing unit, only the stored contents of the left-eye graphics plane cannot be updated.
  • the playback device's manufacture is a quality of playback of stereoscopic content so that users who view the 3D graphics do not feel uncomfortable even if the application created by the content provider is operated and the 3D graphics is displayed on the application. You can pay sufficient attention to
  • the left-eye graphics plane alone is updated during copying from the left-eye graphics plane to the right-eye graphics plane. Is never done.
  • those that have already been copied to the right-eye graphics plane can be rewritten later by a 2D graphics rendering request during inter-plane copying. Can be completely cut off.
  • the invalidation of the 2D graphics rendering request after switching the graphics plane from the 1 plane configuration to the 2 plane configuration eliminates the possibility that only the graphics plane for one eye is rewritten independently, and the 3D rendered by the application Since the quality of the graphics is guaranteed from the standpoint of the platform corresponding to the application platform, the content provider can leave the quality of the 3D graphics rendered by the application to the manufacturer.
  • content providers can concentrate on producing stereoscopic content, so the production of stereoscopic content is promoted to a large extent, and stereoscopic content can be enhanced. it can.
  • a 2D graphics rendering request is processed by java.awt.Graphics, and a copy from the left-eye graphics plane to the right-eye graphics plane is executed by the device driver in the playback device, and these java.awt
  • a possible implementation is that .Graphics and the device driver operate in parallel.
  • the software implementation that java.awt.Graphics and the device driver operate in parallel is performed. Even in the form, when the graphics plane has a two-plane configuration, it is strictly guaranteed that the left-eye graphics plane and the right-eye graphics plane have the same content. Therefore, the degree of freedom of software implementation is not deprived from the manufacturer of the playback device.
  • the playback device may be configured as follows.
  • the playback device A decoder for decoding a stereoscopic video stream recorded on the recording medium;
  • the synthesis of the output system of the right eye is The storage content of either the left-eye graphics plane or the right-eye graphics plane is combined with the storage content of the right-eye video plane.
  • the composition unit after switching from the 1 plane configuration to the 2 plane configuration, after copying the storage content of the left-eye graphics plane to the right-eye graphics plane, the storage content of the right-eye graphics plane in the right-eye output system, Start the process of compositing with the content stored in the video plane for the right eye,
  • the drawing unit may accept the 3D graphics drawing request after combining the stored contents of the right-eye graphics plane and the stored contents of the right-eye video plane.
  • FIG. 1 shows a home theater system including a recording medium as a package medium, a playback device as a player device, a display device, and glasses. It is a block diagram which shows the internal structure of a reproducing
  • 3 is a block diagram illustrating a functional configuration of a drawing unit 115.
  • FIG. It is a figure which shows the internal structure of a plane synthesizer. The internal structure of the graphics planes 104c and 104d is shown. It is a figure which shows the processing content of the copy between planes. It is a figure which shows the graphics update after switching from 1 plane structure to 2 plane structure.
  • FIG. 6 is a diagram illustrating an example of an API for a graphics drawing function supported by the BD-J module 15.
  • FIG. FIG. 9 is a specific example of a drawing request that can be defined using the application program interface of FIG. 8.
  • FIG. 9 schematically shows what kind of writing is executed by calling Graphics # drawImage and StereoGraphics # drawImage when an argument is specified as shown in FIG.
  • FIG. 10 is a timing chart showing the temporal relationship of ignoring 2D graphics rendering requests, copying between planes, and adding an output system for the right eye along the video stream time axis.
  • FIG. It is a figure for the comparison explanation of how the stereoscopic image reproduced
  • FIG. 9 is a specific example of a drawing request that can be defined using the application program interface of FIG. 8.
  • FIG. 9 schematically shows what kind of writing is executed by calling Graphics # drawImage and StereoGraphics # drawImage when an argument
  • FIG. 10 is a diagram showing how a plurality of codes in a stack are processed in continuous photograph notation when mode switching is performed without executing invalidation.
  • a stereoscopic video to be reproduced by the writing in FIG. 14C is shown.
  • FIG. 16D shows a stereoscopic video to be reproduced by writing in FIG. 2 is a diagram showing an internal configuration of a BD-ROM 100.
  • FIG. It is a block diagram which shows the internal structure of a reproducing
  • the plane synthesizer 20 shows four synthesis modes (synthesis mode 1, synthesis mode 2, synthesis mode 3, and synthesis mode 4) realized by switching the four output systems.
  • 6 is a diagram illustrating an example of an API for a graphics drawing function supported by the BD-J module 15.
  • FIG. It is a figure which shows an example of the call code of the graphics drawing function API of FIG.
  • the invention of the reproducing apparatus provided with the above problem solving means can be implemented as a player device for reproducing the package medium, and the invention of the integrated circuit can be implemented as a system LSI incorporated in the player device.
  • the invention of the reproduction method can be implemented as a time series procedure realized by this player device.
  • the invention of the program can be implemented as an executable program recorded in a computer-readable recording medium and installed in a player device.
  • FIG. 1 shows a home theater system including a recording medium as a package medium, a reproducing device as a player device, a display device, and glasses.
  • the recording medium as the package medium and the playback device as the player device constitute a home theater system together with the display device, the glasses, and the remote controller, and are used by the user.
  • the recording medium 100 is an optical disc that supplies, for example, a movie work to the home theater system.
  • the playback device 200 is connected to the television 400 and plays back the recording medium 100. Such reproduction is performed by alternately repeating video output of a left-eye video (L image) and video output of a right-eye video (R image).
  • the reproduced video reproduced in this way includes 2D video and 3D video.
  • the 2D video is an image expressed by pixels at the display position of the display screen located on the XY plane, for example, by taking a plane including the display screen of the display device as the XY plane, and is also called a planar view image.
  • the playback mode of the playback device for playing back the 2D video is called “2D playback mode” or “planar playback mode”.
  • the graphics displayed by the playback device in this 2D playback mode is referred to as “2D graphics”.
  • a 3D image is an image obtained by adding a depth in the Z-axis direction with a straight line perpendicular to the plane captured as the XY plane described above as the Z-axis.
  • the playback mode of the playback device for playing back 3D video is referred to as “3D playback mode” or “stereoscopic playback mode”.
  • the graphics displayed by the playback device in this 3D playback mode is referred to as “3D graphics”.
  • the remote controller 300 is a device that accepts an operation on a hierarchical GUI from a user, and in order to accept such an operation, the remote controller 300 moves a menu key for calling a menu constituting the GUI and a focus of a GUI component constituting the menu.
  • An arrow key, a determination key for performing a confirmation operation on a GUI component constituting the menu, a return key for returning a hierarchical menu to a higher level, and a numerical key are provided.
  • the television 400 receives the video output from the playback device 200, and alternately outputs the L image and the R image as they are at the same timing.
  • the same timing is realized by making the frame rate of video output and display switching the same.
  • the display display 400 accumulates the set of the L image and the subsequently output R image, and displays these images at a high frame rate by switching these images at high speed on the display display side.
  • the shutter glasses 500 include a liquid crystal shutter and a control unit, and realize stereoscopic viewing using parallax between both eyes of the user.
  • the liquid crystal shutter of the shutter glasses 500 is a shutter using a liquid crystal lens having a property that light transmittance is changed by changing an applied voltage.
  • the control unit of the shutter glasses 500 receives the synchronization signal for switching between the output of the R image and the L image sent from the playback device, and switches between the first state and the second state in accordance with the synchronization signal.
  • the first state is a state in which the applied voltage is adjusted so that the liquid crystal lens corresponding to the right eye does not transmit light, and the applied voltage is adjusted so that the liquid crystal lens corresponding to the left eye transmits light. , The L image is incident on the left eye and the L image is not incident on the right eye.
  • the second state is a state in which the applied voltage is adjusted so that the liquid crystal lens corresponding to the right eye transmits light, and the applied voltage is adjusted so that the liquid crystal lens corresponding to the left eye does not transmit light. , The R image is incident on the right eye and the R image is not incident on the left eye.
  • an R image and an L image are images that have a slight difference in appearance between the image seen from the entrance to the right eye pupil and the image seen from the entrance to the left eye pupil due to the difference in the shooting position. It is.
  • the image seen from the human eye can be recognized as a three-dimensional image. It is. Therefore, if the shutter glasses 500 synchronize the switching between the first state and the second state as described above with the switching timing of the output of the R image and the L image, the user can make a planar display three-dimensional. The illusion that it looks like. Next, a time interval for displaying the R image and the L image will be described.
  • the frame period indicating the display cycle for the television 400 to play back the video stream is divided into two, and each period obtained by the division is set as a time interval for switching the right eye and the left eye. .
  • the period for viewing with the left eye is referred to as the “left eye pupil incidence period”.
  • the period for viewing with the right eye is referred to as the “right eye pupil incidence period”.
  • the frame period is 1/24 seconds
  • the left-eye pupil incidence period and the right-eye pupil incidence period are each 1/48 seconds.
  • the frame period is 1/60 seconds
  • the left-eye pupil incidence period and the right-eye pupil incidence period are each 1/120 seconds.
  • FIG. 2 shows a basic internal configuration of a playback device equipped with the problem solving means of the present application.
  • the playback apparatus 200 includes a reading unit 101, a video decoder 102, a plane memory set 103 (including video planes 104a and 104b and graphics planes 104c and 104d), a plane synthesizer 105, an image memory 106, and a rendering engine. 107, a platform unit 110, a heap memory 111, a byte code interpreter 112, a class loader 113, an application manager 114, and a drawing unit 115.
  • Reading unit 101 The reading unit 101 reads a video stream, a data structure, a class structure of a bytecode application, and an application management table from the recording medium 100, and supplies the video stream to the video decoder 102.
  • Video decoder 102 The video decoder 102 decodes the read video stream and writes a non-compressed picture in the plane memory set 103.
  • the plane memory set 103 is composed of a plurality of plane memories.
  • the plane memory is a memory for storing pixel data for one screen in units of lines and outputting the pixel data along the horizontal synchronization signal and the vertical synchronization signal.
  • Each plane memory stores pixel data for one screen obtained by decoding video, subtitles, GUI, and background images.
  • plane memories constitute a layer model, and the contents stored in each plane memory are used for layer synthesis.
  • this layer synthesis in the layer model of the plane memory, the process of superimposing the pixel values of the pixel data stored in the plane memory of the two layers is executed for all combinations of the two layers in the layer model. That is done.
  • the left-eye video plane 104a and the right-eye video plane 104b are one of plane memory sets, and store a left-eye video picture and a right-eye video picture, respectively.
  • the left-eye graphics plane 104c and the right-eye graphics plane 104d are one of the plane memory sets, and store graphics to be superimposed on the video plane in an uncompressed format.
  • the left-eye graphics plane 104c is a left-eye plane memory that stores left-eye graphics.
  • the right-eye graphics plane 104d is a right-eye plane memory that stores right-eye graphics.
  • the left-eye graphics plane and right-eye graphics plane are configured in a one-plane configuration that uses only the left-eye graphics plane for graphics rendering during planar playback and stereoscopic playback, and for graphics rendering during stereoscopic playback. 2 plane configuration using a left-eye graphics plane and a right-eye graphics plane.
  • Graphics here refers to the display content expressed by pixel data in ARGB format stored in these graphics planes, and the characters and symbols obtained by expanding the text code using fonts. It includes bitmaps and GIF / JPEG / PNG images (referred to as “drawing images” in this specification) obtained by decoding GIF / JPEG / PNG data.
  • Plane combiner 105 performs layer combination of a plurality of plane memories.
  • the plane synthesizer 105 includes a left-eye output system and a right-eye output system.
  • the left-eye output system and the right-eye output system independently synthesize layers between a plurality of plane memories. I do.
  • the output system for the left eye and the output system for the right eye are composed of a plurality of adders and connections between the adders.
  • the left-eye output system is shared with the 2D playback mode.
  • the output system for the right eye is valid only in 3D playback mode.
  • the graphics plane when the supply source to the adder is the left-eye graphics plane, the graphics plane can be configured as one plane, and when the supply source to the adder is the right-eye graphics plane, the graphics The plane can have a two-plane configuration.
  • Image memory 106 is a memory for storing a drawing image which is an instance of the data structure when an instance of the data structure recorded on the recording medium 100 is generated.
  • a drawing image is a bitmap in ARGB format, and is indicated by an instance variable from the bytecode application.
  • a drawing image object for the right and a drawing image object for the left eye can be stored separately.
  • the rendering engine 107 performs a drawing process on the left-eye graphics plane 104c and the right-eye graphics plane 104d. Image drawing by the rendering engine 107 is performed by copying a drawing image object on the image memory 106 from the image memory 106 to the graphics planes 104c and 104d. A drawing image object to be copied is specified by an instance variable.
  • Platform unit 110 includes a built-in program stored in a nonvolatile memory such as a ROM and hardware (including an MPU, a register, and a peripheral circuit) that executes the built-in program, and is recorded in the recording medium 100. Run a bytecode application that is an instance of a structure.
  • a nonvolatile memory such as a ROM and hardware (including an MPU, a register, and a peripheral circuit) that executes the built-in program, and is recorded in the recording medium 100.
  • Run a bytecode application that is an instance of a structure.
  • Heap memory 111 is a work area for a bytecode application to operate, and includes a multi-thread 111a and a multi-stack 111b.
  • Multi-thread 111a is a collection of logical execution subjects (threads) that execute bytecodes.
  • the multi-thread 111a performs an operation using an argument stored in the local variable or the operand stack as an operand, and the operation result is represented by the local variable or the operand.
  • Store on stack While there is only one MPU as the physical execution entity in the playback device, there can be a maximum of 64 threads as logical execution entities. Within the number of 64, it is possible to create a new thread or delete an existing thread, and the number of thread operations can be increased or decreased during the operation of the platform.
  • the multi-stack 111b is a collection of stacks that exist in a one-to-one ratio with each of a plurality of threads, and each stack has a program counter and one or more frames therein.
  • the “program counter” indicates which part is currently executed in the instance.
  • a “frame” is a stack expression area allocated for a single call to a method.
  • the “operand stack” that stores the arguments for that single call and the “local variable” used by the called method.
  • Stack Frames are stacked on the stack each time a call is made, so even if a method calls itself recursively, this frame is stacked one.
  • the byte code interpreter 112 converts the byte code assigned to the thread into a native code and causes the MPU to execute it.
  • the bytecode interpreter 112 processes the bytecode application as multithread.
  • Class loader 113 loads the bytecode application by generating an instance of the class structure of the application recorded in the recording medium 100 in the heap memory 111.
  • Application manager 114 The application manager 114 verifies the validity of the bytecode application based on the application management table, and then performs application signaling of the bytecode application, such as starting the bytecode application or terminating the bytecode application.
  • Drawing unit 115 is a middleware program for an embedded device that provides various functions to the bytecode application running on the platform unit.
  • the package implemented by this middleware program performs drawing processing such as drawing of lines and rectangles with color designation, painting of designated areas, designated copy / paste, etc., through the rendering engine 107.
  • a library for the right-eye graphics plane 104d The bytecode application implements various graphics drawing processes by continuously issuing these drawing process requests to the drawing unit.
  • FIG. 3 shows how the picture data stored in the video planes 104a and 104b looks to the user wearing the shutter glasses 500.
  • FIG. 3 shows how the picture data stored in the video planes 104a and 104b looks to the user wearing the shutter glasses 500.
  • the arrow vw1 in the figure indicates video input to the viewpoint during the right eye pupil incidence period
  • the arrow vw2 in the figure indicates video input to the viewpoint during the left eye pupil incidence period.
  • the right-eye pupil incidence period as shown by an arrow vw1
  • the stored content of the right-eye video plane enters the left eye of the user through the shutter glasses 500.
  • the left-eye pupil incidence period as shown by the arrow vw2
  • the stored contents of the left-eye video plane enter the user's left eye through the shutter glasses 500.
  • Such switching of the shutter enables stereoscopic playback of the video stream.
  • a menu composed of three button members to which character strings such as subtitles, voices, and privileges are added is configured by graphics stored in the graphics plane.
  • the target of stereoscopic playback is not limited to video. Menus made up of graphics are also subject to stereoscopic viewing.
  • Such configurations include a two-plane configuration and a one-plane configuration.
  • the 2-plane configuration is a plane configuration for playing back graphics drawn by a bytecode application in 3D-LR mode when the playback device is in 3D playback mode.
  • the 3D-LR mode is a playback mode in which a stereoscopic effect is created by writing left-eye graphics to the left-eye graphics plane and writing right-eye graphics to the right-eye graphics plane.
  • the 1-plane configuration is a plane configuration for playing back graphics drawn by a bytecode application in 1 plane + offset mode when the playback device is in 3D playback mode.
  • 1plane + Offset mode means that the pixel coordinates of the line unit in the plane memory are shifted leftward or rightward in the left eye pupil incidence period and the right eye pupil incidence period, and the image points of the right visual line and the left visual line are moved forward.
  • a playback mode in which the sense of depth is changed by displacing in the depth direction.
  • the image point of the eyes of both eyes will be in front, the right direction in the left eye pupil incidence period, If the pixel coordinates are changed to the left during the right eye pupil incidence period, the image point of the line of sight of both eyes will be in front.
  • This plane shift is ideal for easily creating stereoscopic images because only one plane memory is required for stereoscopic viewing.
  • This plane shift is only suitable for stereoscopic effects such as menus and subtitles because it only produces a stereoscopic image in which a planar image comes to the front or pulls in the back. This is somewhat unsatisfactory for realizing the stereoscopic effect. This is because the indentation and unevenness of the character's face cannot be reproduced.
  • the graphics plane configuration is in principle one plane configuration. Only when the bytecode application makes a configuration setting request and switches the graphics plane configuration to the 2-plane configuration, it can be switched to the 2-plane configuration.
  • the bytecode application needs to make a configuration setting request before drawing and set the graphics plane to a two-plane configuration.
  • FIG. 4 Functional configuration of the drawing unit 116
  • the drawing unit 116 as described above is a component for processing these drawing requests and configuration setting requests. From the functional point of view of software, The configuration is expressed as shown in FIG. FIG. 4 is a block diagram illustrating a functional configuration of the drawing unit 116.
  • the first level is the software layer configuration in the internal configuration of FIG. 2, and the second level shows the layer configuration of the plane memory, the right-eye output system, and the left-eye output system in the internal configuration of FIG. .
  • the third row shows a right eye image and a left eye image.
  • hatched ones indicate the constituent elements of the drawing unit.
  • the drawing unit is described with the resident-type bytecode applications “org.havi.ui” and “java.awt.Graphics” and the native code of the playback device. It consists of “device driver” which is an embedded program.
  • device driver which is an embedded program.
  • org.havi.ui manages the left-eye graphics plane and the right-eye graphics plane as HAVi graphics devices.
  • java.awt.Graphics Module is an improved module of java.awt.Graphics.
  • java.awt (Abstract Window Toolkit) is a basic library that summarizes functions for building GUIs, and has two classes: components and containers.
  • a component provides a drawing area for a Java application, and a container provides a function for arranging and storing a plurality of components.
  • What has been improved is different from ordinary java.awt.Graphics in that special processing is performed when switching the graphics plane from 1 plane to 2 planes is ordered. While the graphics plane is two planes, it is the same as normal java.awt.Graphics, except that 2D graphics drawing is not performed.
  • This special processing by java.awt.Graphics is ignoring 2D graphics rendering requests.
  • this “ignore” a method is adopted in which all call codes of 2D graphics rendering requests already accumulated in the stack are deleted and an Exception is returned to the requesting thread. After such ignorance is performed, 2D graphics rendering is not performed until switching of the graphics plane from 2 planes to 1 plane is commanded and the output system for the right eye is released.
  • Device driver 116 The device driver 116 writes the graphics to the left-eye graphics plane and the right-eye graphics plane according to the request of java.awt.Graphics and org.havi.ui.
  • This access copies the stored contents of the left-eye graphics plane to the right-eye graphics plane.
  • An arrow cp1 indicates a copy from the left-eye graphics plane to the right-eye graphics plane.
  • StereoGraphics Module is a resident-type bytecode application that is specially implemented in a playback device to accept 3D graphics drawing requests and draw graphics. The operation is started only when the switching of the graphics plane from the 1 plane to the 2 plane is instructed. When the graphics plane is switched from the 2 plane to the 1 plane, the operation is immediately finished.
  • the plane combiner 105 realizes the addition of the right eye output system. Next, the internal configuration of the synthesis unit will be described.
  • FIG. 5A shows the layer configuration of the plane memory and the components of the synthesis unit.
  • the combining unit includes an adder 41 provided in the output system for the left eye of the layer configuration of the plane memory, an adder 42 provided in the output system for the right eye of the layer configuration of the plane memory, and the switch 43. .
  • Adder 41 combines the stored contents of the left-eye video plane and the stored contents of the left-eye graphics plane in the left-eye output system.
  • Adder 42 In the output system for the right eye, the adder 42 combines the stored contents of the video plane for the right eye with either the graphics plane for the left eye or the graphics plane for the right eye.
  • the synthesis of the stored contents by the adders 41 and 42 is to superimpose pixel values of pixel data stored in the video plane and the graphics plane.
  • the pixel value superimposition the pixel value in the line unit of the plane memory is multiplied by the transmittance ⁇ as a weight, and the pixel value in the line unit of the plane memory located in the lower layer is multiplied by a weight of (1 ⁇ transmittance ⁇ ).
  • the adders 41 and 42 include a line memory that stores pixel data of line pixels in the plane memory, and a multiplication unit that multiplies each pixel value in the line pixel by an equivalent ratio. , Addition as described above is performed.
  • Switch 43 switches the pixel data supply source to the adder 42 to either the left-eye graphics plane or the right-eye graphics plane.
  • the graphics plane configuration is “one plane configuration”
  • the pixel data supply source is the right-eye graphics plane
  • the configuration is “2 plane configuration”.
  • composition mode 54.1 Composition mode
  • the output system in the 2D playback mode is fixed as shown in FIG.
  • the 3D playback mode there are an output system for the right eye and an output system for the left eye.
  • the data supply source to the adder is a plane memory for the right eye or the left eye.
  • FIGS. 5C to 5D There are two variations shown in FIGS. 5C to 5D depending on whether the plane memory is used. In other words, there is no variation in the output system in the 2D playback mode, but in the 3D playback mode, the plane synthesizer 20 realizes switching between the two output systems, so that two synthesis modes (synthesis mode A, synthesis mode B) are realized. ). Each mode will be described below with reference to FIGS. 5C to 5D.
  • FIG. 5 (c) shows a synthesis mode (synthesis mode A) by an output system in which the ratio of the graphics plane and the video plane is 2: 2. Since the number of graphics planes is two, the supply source to the adder 42 is the right-eye graphics plane.
  • FIG. 5D shows a synthesis mode (referred to as synthesis mode B) by an output system in which the ratio of the graphics plane and the video plane is 1: 2.
  • synthesis mode B only the graphics plane for the left eye is used. As a result, the same video is output for the graphics plane, so that it looks flat to the viewer's eyes.
  • the plane synthesizer 105 In the 2D playback mode, the plane synthesizer 105 has no right-eye output system, and the plane synthesizer 105 is in the state shown in FIG. However, at the time of switching from the 2D playback mode to the 3D playback mode, the output system for the right eye is added to the plane combiner 105, and the plane combiner 105 enters the state shown in FIG. 5C or FIG. Thus, making the adder 42 and the switch 43 effective is “addition of the right eye output system”. Conversely, disabling the adder 42 and the switch 43 is “releasing the output system for the right eye”.
  • Inter-plane copying means copying all pixels stored in the left-eye graphics plane to the right-eye graphics plane.
  • the plane configuration of the graphics plane which is the premise of this copy process, will be described.
  • FIG. 6 shows a common internal configuration of the left-eye graphics plane 104c and the right-eye graphics plane 104d.
  • the graphics planes 104c and 104d are composed of storage elements having a 32-bit length of horizontal 1920 ⁇ vertical 1080, as shown in FIG.
  • the graphics planes 104c and 104d store pixel data in the ARGB format 8888 format with a resolution of 1920 ⁇ 1080.
  • Each pixel in the ARGB format 8888 format is composed of 8-bit transparency A, 8-bit R value, 8-bit G value, and 8-bit B value.
  • FIG. 5B shows pixel data stored in the graphics planes 104c and 104d.
  • the graphics data stored in the graphics planes 104c and 104d is composed of pixel data corresponding to the foreground portion and pixel data corresponding to the background portion.
  • the A value indicating the transparent color is stored in the storage element corresponding to the background portion, and when this is combined with the video plane, the subtitles of the graphics plane and the moving image on the video plane can be seen through. become.
  • the storage element corresponding to the foreground portion stores R, G, and B values indicating colors other than the transparent color, and a drawing image is drawn by the R, G, and B values other than the transparent color.
  • the stored contents of other plane memories can be seen through the portion corresponding to the transparent pixel, and the presence of the transparent portion enables plane synthesis.
  • FIG. 7A shows the stored contents of the left-eye graphics plane and the right-eye graphics plane before the addition of the right-eye output system.
  • the menu that exists in the upper left is the same as the menu in the stereoscopic video in FIG. 3, and it can be seen that the pixel data that constitutes the menu exists in the left-eye graphics plane.
  • FIG. 7B schematically shows how the right eye output system is added.
  • the left-eye graphics plane is a collection of 1920 ⁇ 1080 pixel data, and among these, horizontal 1920 pixels constitute line pixels.
  • FIG. 7B symbolically indicate the line pixel copy from the left-eye graphics plane to the right-eye graphics plane.
  • 1920 ⁇ 1080 pixel data in the left-eye graphics plane is directly copied to the right-eye graphics plane.
  • FIG. 7C shows the storage contents of the left-eye graphics plane and the right-eye graphics plane after the addition of the right-eye output system.
  • FIG. 7 (c) there is a menu in each of the left-eye graphics plane and the right-eye graphics plane, and thus a visual mismatch between the left eye and the right eye cannot occur.
  • Ignore 2D graphics rendering request The above is an explanation of interplane copying and graphics planes. Next, details of ignoring a 2D graphics drawing request will be described. Ignoring a 2D graphics rendering request is to ignore a 2D graphics rendering request that has reached java.awt.Graphics after switching from a 1-plane configuration to a 2-plane configuration. When the graphics plane is changed to a two-plane configuration by switching the configuration, it means an aggressive process of erasing all 2D graphics drawing requests accumulated in the stack and terminating the 2D graphics drawing request as an exception. By “ignoring” with aggressive processing, 2D graphics rendering requests are removed from the stack for java.awt.Graphics to receive requests from bytecode applications. The process of ignoring the 2D graphics rendering request after the configuration change request is also called “invalidation” of the 2D graphics rendering request.
  • FIG. 8 shows the graphics update after switching from the 1-plane configuration to the 2-plane configuration.
  • the left end of the drawing is the origin of the time axis
  • the right direction of the drawing is the positive direction of the time axis
  • the left direction is the negative direction of the time axis.
  • the plane perpendicular to the time axis is the XY plane formed by the graphics plane.
  • coordinates on the XY plane orthogonal to the time axis are given as display coordinates.
  • the inter-plane copy is executed, and menus exist in both the left-eye graphics plane and the right-eye graphics plane.
  • the storage contents of the left-eye graphics plane and the right-eye graphics plane are updated as a result of the 3D graphics rendering request being issued in response to the menu confirmation operation.
  • FIG. 8 (b) shows the graphics by 2D graphics rendering request after switching the graphics plane configuration from 1 plane configuration to 2 plane configuration Indicates a case where an update was made.
  • a menu exists in the left-eye graphics plane at time u1.
  • the inter-plane copy is executed, and menus exist in both the left-eye graphics plane and the right-eye graphics plane.
  • only the stored contents of the left-eye graphics plane are updated because a 2D graphics rendering request is issued in response to the menu confirmation operation. While the stored contents of the left-eye graphics plane are updated, the stored contents of the right-eye graphics plane are not updated, and thus there is a visual mismatch between the left eye and the right eye.
  • the 2D graphics drawing request is realized as a call code of Graphics # drawImage API with the first and second arguments set. If the first, second, and third arguments are x1, y1, x2, y2, and image1, the API call code Graphics # drawImage (x1, y1, x2, y2, image1); The 2D graphics rendering request is made by describing in.
  • “3D graphics drawing request” is a call code of StereoGraphics # drawImage API in which the first argument, second argument, third argument, fourth argument, and fifth argument are set. If the argument is x1, y1, x2, y2, image1, x3, y3, x4, y4, image2, StereoGraphics # drawImage (x1, y1, x2, y2, image1, x3, y3, x4, y4, image2); A 3D graphics rendering request is made by describing the API call code in the bytecode application.
  • Configuration request is a call code of SetConfiguraionAPI in which the first argument and second argument are set. If the argument is the first argument and the second argument is width ⁇ height, number1, configure the graphics plane memory by writing the API call code setConfiguraion (width ⁇ height, number1); in the bytecode application A switch can be requested.
  • the frames corresponding to these calls are stacked on the stack corresponding to each multi-stack thread.
  • the arguments of the Graphics # drawImage API call, the StereoGraphics # drawImage API call, and the argument of the setConfiguraionAPI call are stacked on the operand stack of the frame in these stacks.
  • FIG. 9 shows an application program interface used for writing a drawing image.
  • java.awt.Graphics # drawImage Method The java.awt.Graphics # drawImage method in FIG. 9A is the drawing image specified by the second argument at the drawing position specified by the position of the first argument. API to call the function to write. To be exact, it is possible to pass an argument for designating a rectangular position for trimming the designated drawing image into a rectangle and drawing it, but it is omitted here.
  • StereoGraphics # drawImage method The StereoGraphics # drawImage method in Fig. 9 (b) writes the drawing image specified by the second argument to the rectangular range specified by the position of the first argument in the graphics plane for the left eye. In the left-eye graphics plane, this API calls a function for writing the drawing image specified by the fourth argument in the rectangular range specified by the position of the third argument.
  • the rectangular range is represented by a combination of the upper left coordinates (x1, y1) and the lower right coordinates (x2, y2) of the rectangular area to be rendered.
  • BufferedImage can be used in addition to the instance generated from the GIF / JPEG / PNG format data structure.
  • the java.awt.Graphics # drawImage method specifies image copy processing, but only one rectangular area copy can be specified in this processing.
  • simultaneous left and right image copying by the StereoGraphics # drawImage method includes a pair of a drawing position and a drawing image.
  • the drawing planes are fixed to the left-eye graphics plane 104c and the right-eye graphics plane 105d, respectively, and the designation of the graphics plane is excluded from the arguments of the StereoGraphics # drawImage method.
  • FIG. 10 is a specific example of a drawing request that can be defined using the application program interface of FIG.
  • FIG. 10A shows a rectangular range to be drawn and a drawing image when the API type is the java.awt.Graphics # drawImage method. It shows in tabular form what is specifically set.
  • the drawing image is expressed using an instance variable given to an instance of the data structure.
  • “Bitmap image 1” in the figure is an instance variable given to an instance composed of 200 pixels wide ⁇ 70 pixels high.
  • the drawing image is expressed using an instance variable given to an instance of the data structure.
  • “Bitmap image 2” in the figure is an instance variable given to an instance composed of 200 pixels wide ⁇ 70 pixels high.
  • FIG. 11A shows what writing is executed by calling Graphics # drawImage when an argument is specified as shown in FIG. 10A. This is shown schematically.
  • the front side in the figure shows an image memory storing a drawing image.
  • the back side in the figure shows a set of a left-eye graphics plane and a left-eye video plane, and a set of a right-eye graphics plane and a right-eye video plane that are overlapped with each other.
  • FIG. 11B when an argument is specified as shown in FIG. 10B, what kind of writing is executed by calling StereoGraphics # drawImage.
  • the front side in the figure shows an image memory storing a drawing image.
  • the back side in the figure shows a set of a left-eye graphics plane and a left-eye video plane, and a set of a right-eye graphics plane and a right-eye video plane that are overlapped with each other.
  • Specific XY coordinates shown as a rectangular range to be drawn in FIG. 10B are plotted on the left-eye graphics plane and the right-eye graphics plane.
  • Ignoring 2D graphics rendering requests, switching between planes, and adding an output system for the right eye when switching from the 1-plane configuration to the 2-plane configuration are as follows: (1) Ignoring 2D graphics rendering requests ⁇ (2) Planes Interim copy ⁇ (3) Addition of right-eye output system, and acceptance of 3D graphics rendering request after execution of addition of right-eye output system.
  • the temporal relationship when switching from the 2-plane configuration to the 1-plane configuration is that the acceptance of the 3D graphics rendering request is prohibited, the right eye output system is released, and the 2D graphics rendering request is accepted.
  • the timing chart of FIG. 12 shows the temporal relationship between these procedures.
  • FIG. 12 Temporal relationship of operations of each component
  • FIG. 12 is a timing chart showing the temporal relationship of operations by the bytecode application, StereoGraphics, java.awt.Graphics, and device driver along the video stream time axis. is there.
  • the first level shows a bytecode application
  • the second level shows StereoGraphics.
  • the third level shows java.awt.Graphics
  • the fourth level shows a device driver.
  • the fifth row shows a plurality of pictures continuously displayed in a frame period of 1 / 23.976 seconds and 1 / 59.94 seconds on the time axis of the video stream.
  • the sixth row shows the time axis of the video stream.
  • Circle symbols 1, 2, 3, and 4 indicate the order of invalidation by java.awt.Graphics, copying by device driver, and acceptance of 3D graphics rendering requests by StereoGraphics after calling setConfiguraion with two planes as arguments. Indicates whether is executed. According to the number of this circle symbol, first, Graphics # drawImage is invalidated by java.awt.Graphics, secondly, a copy of the graphics plane by the device driver, and thirdly, output for the right eye by the device driver It turns out that the output of the system is made. After these processes are completed, fourthly, it is understood that StereoGraphics is started and acceptance of StereoGraphics # drawImage is started.
  • the invalidation start time t0 in the second row is immediately after the setConfiguraionura API call is made.
  • the plain memory copy start time t1 is immediately after the completion of the invalidation of the 2D graphics rendering request. If the content of the left-eye graphics plane is rewritten by java.awt.Graphics during copying, the left-eye graphics plane will not match the right-eye graphics plane, and binocular vision will not match. Occurs. However, as shown in this figure, java.awt.Graphics ignores all 2D graphics rendering requests and then copies the graphics plane, so the stored contents of the left-eye graphics plane and the right-eye graphics plane There can be no discrepancy.
  • the characteristic of the device driver processing is that the copying is performed after the ignore of the 2D graphics rendering request is completed. That is, if the contents of the left-eye graphics plane are rewritten by java.awt.Graphics during copying, the left-eye graphics plane and the right-eye graphics plane will not match, and binocular vision will not match. Occurs. However, if java.awt.Graphics deletes all 2D graphics rendering requests from the stack and then the device driver copies the graphics plane, there will be no mismatch in the stored contents.
  • the addition time t2 of the output system for the right eye is immediately after the plane copy is completed.
  • the video output is switched from the planar view to the stereoscopic view immediately after the switching of the output system.
  • the start time t3 of StereoGraphics is immediately after the addition of the right eye output system. Since StereoGraphics is activated, the stereoscopic graphics can be updated after time t3. As is clear from the above timing chart, it is not possible to immediately draw StereoGraphics # drawImage by a 3D graphics drawing request after calling setConfiguraion. There is a time lag for executing a series of processes such as ignoring 2D graphics drawing requests, copying graphics planes, and switching output systems.
  • StereoGraphics in the second row is immediately after the point when the setConfiguraion call is made.
  • StereoGraphics that draws 3D graphics in response to StereoGraphics # drawImage is activated only when the graphics plane switch from 1 plane to 2 planes is ordered by a call to setConfiguraion, and the graphics plane is returned from 2 planes by another call to setConfiguraion.
  • the operation is finished immediately, so the operation period is very limited. Therefore, there is no problem caused by the operation of StereoGraphics in the 2D playback mode.
  • the release time t4 of the output system for the right eye in the 4th stage is immediately after the operation of StereoGraphics is completed.
  • the video output is switched from the planar view to the stereoscopic view immediately after the switching of the output system.
  • the acceptance time t5 of Graphics # drawImage in the third row is immediately after the completion of the output system from 2 planes to 1 plane. Since java.awt.Graphics accepts 2D graphics rendering requests, 2D graphics can be updated after this point.
  • FIG. 13A shows a process of updating graphics that the content creator considers ideal.
  • Aaa in this figure is an abbreviation for the menu for accepting selection of voice, caption, and privilege shown in FIG. 3
  • bbb is an abbreviation for the menu for accepting selection of English, Chinese, and Japanese shown in FIG. It is a thing.
  • aaa is written by calling the Graphics # drawImage API in the frame f, and in the frame f + 1, the Graphics # drawImage API is written.
  • the call code of Graphics # drawImage, the call code of setConfiguraion, and the call code of StereoGraphics # drawImage are arranged in the order of 2D graphics drawing request ⁇ setConfiguraion ⁇ StereoGraphics # drawImage, but it corresponds to the call code of GraphicsDrawImage Byte code, byte code that corresponds to the call code of setConfiguraion, and byte code that corresponds to the call code of StereoGraphics # drawImage are executed in parallel by three threads in multi-thread, so these call codes are setConfiguraion ⁇ Graphics # drawImage ⁇ StereoGraphics Assume that they are issued in the order of #drawImage.
  • FIG. 13 (b) shows three call codes issued by the bytecode application for updating the graphics in FIG. 13 (a).
  • the second level in the figure is a stack for inter-thread communication, and there are three codes rearranged in the order of setConfiguraion, Graphics # drawImage, and StereoGraphics # drawImage.
  • the first level of the figure shows a bytecode application, and the fourth level shows a plain memory.
  • the third level shows java.awt.Graphics, StereoGraphics, and device drivers that are components of the drawing unit.
  • FIG. 14 is a diagram showing how a plurality of codes in a stack are processed in a continuous photograph notation when switching between plane configurations is executed without executing invalidation.
  • the process of processing the code in the stack consists of four stages.
  • FIG. 14A is the first stage
  • FIG. 14B is the second stage
  • FIG. 14C is the third stage.
  • FIG. 14D shows the fourth stage.
  • the stack java.awt.Graphics, StereoGraphics, device driver, and plane memory are drawn in the same notation as in the previous figure.
  • an arrow with a circle symbol 2 symbolically represents a copy of the plane memory.
  • the arrow with the circle symbol 3 in FIG. 14B symbolizes the switching of the output system.
  • An arrow with a circle symbol 8 in FIG. 14C symbolically shows bbb writing by Graphics # drawImage.
  • the arrow with the circle symbol 9 in FIG. 14D symbolically shows bbb writing by StereoGraphics # drawImage.
  • FIG. 15 shows a stereoscopic video to be reproduced by the writing in FIG. 14C, since the right-eye graphics plane and the left-eye graphics plane are different, there is a discrepancy between the right-eye video and the left-eye video. The visual disagreement between the right eye and the left eye remains on the screen until the left-eye graphics plane and the right-eye graphics plane are updated by StereoGraphics, so that such disagreement gives a great discomfort to the user.
  • FIG. 16 shows, in continuous photograph notation, how a plurality of API call codes in the stack are processed when mode switching is executed after invalidation.
  • the process in which the code in the stack is processed consists of four stages, as in FIG. 14, where FIG. 16 (a) is the first stage, FIG. 16 (b) is the second stage, and FIG. The third stage, FIG. 16 (d), shows the fourth stage.
  • FIGS. 16A to 16D the stack, java.awt.Graphics, StereoGraphics, device driver, and plane memory are drawn in the same notation as in FIG. 13B.
  • an arrow with a circle symbol 1 indicates deletion of the call code of the 2D graphics rendering request API by invalidation.
  • the cross in the figure indicates that the call code of the subsequent setConfiguraion has been moved up by one by deleting Graphics # drawImage to write bbb out of the three call codes stored in the stack. Is schematically shown.
  • FIG. 16B an arrow with a circle symbol 2 symbolically represents a copy of the plane memory. Since FIG. 16 (a) java.awt.Graphics has copied the graphics plane in FIG. 16 (b) after all 2D graphics rendering requests have disappeared from the stack, the visual mismatch between the left eye and the right eye is It cannot happen.
  • FIG. 16C an arrow with a circle symbol 3 symbolizes the addition of the right eye output system.
  • FIG. 16D an arrow with a circle symbol 9 symbolically shows bbb writing by StereoGraphics # drawImage.
  • FIG. 17 shows a stereoscopic video to be reproduced by writing in FIG. Since the right-eye graphics plane and the left-eye graphics plane are different, no mismatch occurs.
  • the 2D graphics rendering request is invalidated before copying the graphics plane, after the pixel data copy from the left-eye graphics plane to the graphics plane is completed, the graphics plane for the left eye is copied. New graphics are never written. Even if the 2D graphics rendering request is delayed and reaches java.awt.Graphics, the graphics cannot be displayed according to the 2D graphics rendering request, and there is no visual mismatch between the eyes.
  • the 2D graphics rendering API is invalidated by deleting the call code of the 2D graphics rendering request API stored on the stack. However, the 2D graphics rendering request is ignored in the configuration. Change the 2D graphics rendering processing side so that the 2D graphics rendering request is returned without processing only while the graphics plane has a 2-plane configuration by switching, that is, the “temporary” of the 2D graphics rendering request at the time of configuration change "Invalidation".
  • the 2D graphics rendering prohibition flag is for instructing Graphics # drawImage to select whether to ignore a 2D graphics rendering request or accept a 2D graphics rendering request.
  • a process for referring to the 2D graphics rendering prohibition flag is incorporated at the top of the processing unit. If the 2D graphics rendering prohibition flag is on, this reference processing returns immediately with exception processing (typically no processing) without processing Graphics # drawImage, and the 2D graphics rendering prohibition flag is set. If it is off, Graphics # drawImage is executed.
  • the 2D graphics rendering processing side is changed so that the 2D graphics rendering request is returned without processing only while the graphics plane has a 2-plane configuration. Since ignoring drawing requests is realized, ignoring 2D graphics drawing requests can be realized with simple processing. Such simplification simplifies the implementation of ignoring 2D graphics rendering requests.
  • the third embodiment is an embodiment having substantially the same content as the embodiment described in the specification attached to the application in the priority application of the priority claim of the present application.
  • the target video to be stereoscopically displayed is played back and viewed on a BD-ROM recording medium.
  • BD-ROM BD-ROM standard
  • a mode in which stereoscopic video display is performed by the playback apparatus 200 including these will be described.
  • FIG. 18 is a diagram showing an internal configuration of the BD-ROM 100.
  • BD-ROM is shown in the 4th row of this figure, and tracks on the BD-ROM are shown in the 3rd row.
  • the track in this figure is drawn by extending the track formed in a spiral shape from the inner periphery to the outer periphery of the BD-ROM in the horizontal direction.
  • This track includes a lead-in area, a volume area, and a lead-out area.
  • BCA Burst Cutting Area
  • the volume area in this figure has a layer model of a physical layer, a file system layer, and an application layer, and application data such as video data is recorded in the volume area starting with file system information (volume).
  • the file system is UDF, ISO9660, etc., and logical data recorded in the same way as a normal PC can be read out using a directory and file structure, and a 255 character file name.
  • the directory name can be read out.
  • the application layer format (application format) of BD-ROM When the application layer format (application format) of BD-ROM is expressed using the directory structure, it becomes like the first row in the figure.
  • the BD-ROM In the first stage, the BD-ROM has a CERTIFICATE directory and a BDMV directory under the Root directory.
  • the BDMV directory is a directory in which data such as AV contents and management information handled by the BD-ROM is recorded. There are six subdirectories called, and two types of files, INDEX.BDMV and MovieObject.bdmv, are arranged.
  • the STREAM directory is a directory that stores a file that is the main body of the transport stream, and a file (000001.m2ts) with an extension “m2ts” is present.
  • the BDJO directory contains a file (XXXXX.bdjo) with the extension “bdjo”.
  • the XML file (ZZZZZ.xml) exists in the META directory.
  • a file with the extension “m2ts” is a stream file of a digital AV stream in the MPEG-TS (TransportStream) format, and includes a video stream, one or more audio streams, an interactive graphics stream, a graphics subtitle stream, and the like. It is obtained by multiplexing.
  • the video stream indicates the moving image portion of the movie
  • the audio stream indicates the audio portion of the movie.
  • the 2D dedicated stream file has a normal transport stream format
  • the 2D-3D combined stream file has a stereoscopic interleaved stream file format.
  • the stereoscopic interleaved stream file format interleaves the extent of the main transport stream (main TS) including the base-view video stream and the extent of the sub-transport stream (sub-TS) including the dependent-view video stream. Interleaved in the form.
  • PlayList Information A file with the extension “mpls” is a playlist information file storing playlist (hereinafter also referred to as PL) information.
  • a “playlist” is a playback path defined by specifying playback sections on the time axis of the transport stream (TS) and logically specifying the playback order between the playback sections. Of these, it plays the role of defining which part is played back and in what order the scene is developed.
  • the playlist information defines the “type” of the playlist.
  • the playback path defined by the playlist information is a so-called “multipath”. Multipath is a bundle of a playback path (main path) defined for a main TS and a playback path (subpath) defined for a subordinate TS. If the playback path of the base-view video stream is defined in this multi-pass and the playback path of the dependent-view video stream is defined in the sub-path, the combination of video streams for reproducing stereoscopic vision can be preferably defined. it can.
  • An application based on an object-oriented programming language orders the generation of a framework player instance that reproduces this playlist information, so that AV reproduction by multipass can be started.
  • the framework player instance is actual data generated on the heap memory of the virtual machine based on the media framework player class.
  • the command-based program can also start playback by multipass by issuing a playback command specifying this playlist information as an argument.
  • a file with the extension “clpi” is a stream information file corresponding to each of the stream files on a one-to-one basis.
  • the stream information file guarantees random access to an arbitrary source packet in the transport stream in the stream file and continuous reproduction with other transport streams.
  • the stream file is managed as “AVClip”.
  • the stream information file has a basic entry map that shows information such as the encoding format, frame rate, bit rate, resolution, etc. of the stream in AVClip, and the source packet number at the head position of the GOP in association with the presentation time stamp of the frame period. Therefore, if you load this stream information file into memory before accessing the stream file, you can understand what the transport stream is in the stream file you want to access. Execution of random access can be guaranteed.
  • the stream information file includes a 2D stream information file and a 3D stream information file.
  • the 3D stream information file includes clip information for base view (clip base information) and clip information for dependent view ( Clip dependent information).
  • the clip base information includes extent start point information for the base view, and the clip dependent information includes extent start point information for the dependent view.
  • the extent start point information for the base view is composed of a plurality of source packet numbers. Each source packet number indicates in what packet the extent division position in the main TS exists.
  • the extent start point information for the dependent view is also composed of a plurality of source packet numbers, and indicates how many packets have the division position in the sub-TS.
  • BD-J Object a file with the extension BDJO will be described.
  • BD-ROM By executing an application program during video playback, it is possible to perform arbitrary computer processing while playing back video, such as dynamic playback control and interaction with the user during playback. Is possible.
  • Java registered trademark
  • Java is used as the application platform standard in BD-ROM
  • the Java (registered trademark) platform adopted in the BD-ROM standard is called BD-Java or BD-J.
  • the execution application is called a BD-Java application or a BD-J application.
  • the file with the extension BDJO is a file that stores BD-J objects.
  • the BD-J object includes various types of information used when executing a BD-Java application.
  • the information includes an association with a playback title, an association with a JAR file described later, a reference value for PlayList information, an application management table, and the like.
  • the application management table is information that records detailed information of the BD-J application to be executed, that is, a character string indicating the name of the application, an icon locator indicating the location of the icon associated with the application, and the like for each application unit. It is.
  • JAR file This is program information of the BD-J application, and the archived format is a JAR file.
  • the BD-J application is loaded into the heap area (also called work memory) of the virtual machine, and is used when the program is executed, and one or more class files that are the runtime format of the Java (registered trademark) program Consists of various data.
  • a JAR file is a file format that includes this information.
  • Metafile The metafile (ZZZZZ.xml) stored in the META directory stores various information related to the video work on the disc. Information stored in the metafile includes a disc name and an image of the disc, information on the name of the disc creator, a title name related to each title, and the like.
  • the disk root certificate file (app.discroot.cert) exists under the CERTIFICATE directory.
  • BD-ROM 100 This completes the explanation of the BD-ROM 100. Some files such as metafiles are not necessarily required by the BD-ROM standard, and even if some files do not exist, the BD-ROM 100 can be played back as a video recording medium under the BD-ROM standard. .
  • FIG. 19 is a block diagram showing the internal configuration of the playback apparatus.
  • the playback device includes a BD-ROM drive 1, a track buffer 2, a demultiplexer 3, a video decoder 4, a left-eye video plane 5, a right-eye video plane 6, an image memory 7, an image decoder 8, and a left-eye.
  • the layer model of the plane memory in the first embodiment employs a simple model of graphics plane-video plane, but in the third embodiment, a model of graphics plane-subtitle plane-video plane-background graphics plane is used as a playback device.
  • the internal configuration is adopted.
  • BD drive 1 The BD drive 1 loads / ejects the BD-ROM and accesses the BD-ROM.
  • Track buffer 2 The track buffer 2 is a FIFO memory, and the ACCESS UNIT read from the BD-ROM is stored in a first-in first-out manner.
  • Demultiplexer 3 demultiplexes a BD-ROM loaded in the BD-ROM drive 1 or a transport stream stored on the local storage 24 or the removable medium 27 through the virtual file system 25.
  • Demultiplexing by the demultiplexer 3 includes a conversion process of converting TS packets into PES packets.
  • a video frame, an audio frame, a graphics stream, and a subtitle stream constituting the GOP are obtained by demultiplexing.
  • Video frames constituting the GOP are output to the video decoder 4, and audio frames multiplexed in the GOP are output to the audio decoder 26.
  • a graphics stream obtained by demultiplexing is output to the graphics decoder 19.
  • Video decoder 4 The video decoder 4 decodes the video frame output from the demultiplexer 3 and writes an uncompressed picture in the left-eye video plane 5 and the right-eye video plane 6.
  • Left-eye video plane 5, right-eye video plane 6 The left-eye video plane 5 and the right-eye video plane 6 are memories for storing uncompressed pictures, and store a left-eye video picture and a right-eye video picture, respectively. These correspond to HVideoDevice in the HAVi device.
  • the video decoder 4 continuously rewrites the left-eye video plane 5 and the right-eye video plane 6, thereby realizing the playback of the stereoscopic video stream. .
  • Image memory 7 is a buffer for storing an image image read from the virtual file system 25 and developed by the image decoder. In addition to the developed image, it can also be used as a general-purpose image buffer used by the BD-J application.
  • Image decoder 8 The image decoder 8 reads the compressed image image from the virtual file system, and writes it in the image memory in such a state that the rendering engine 22 can perform the copy process and the ⁇ operation process at high speed. Specifically, for example, a configuration in which data is written in the ARGB 8888 format can be given.
  • Left-eye graphics plane 9, right-eye graphics plane 10 The left-eye graphics plane 9 and the right-eye graphics plane 10 are memories for storing images to be superimposed on the video plane and the caption plane, and correspond to the HGraphicsDevice in the HAVi device. With this graphics plane, menu display and the like can be realized.
  • the static scenario memory 11 is a memory for storing the current PL and current stream management information.
  • the current PL is a PL that can be read from the virtual file system 25 and that is a processing target at that time.
  • the current stream management information refers to a plurality of stream management information that can be read from the virtual file system 25 and that is to be processed at that time.
  • Dynamic scenario memory 12 is a memory that stores a current dynamic scenario and is used for processing by the HDMV module 14 and the BD-J module 15.
  • the current dynamic scenario is a piece of scenario information that can be read from the virtual file system 25 and that is to be executed at that time.
  • Control unit 13 is a microcomputer system composed of a ROM, a RAM, and a CPU. A program for controlling the playback device is recorded in the ROM. By operating, the functions of the HDMV module 14, the BD-J module 15, the mode management module 16, the dispatcher 17, and the AV playback library 18 are realized.
  • HDMV module 14 The HDMV module 14 is a DVD-Video virtual player.
  • HDMV High Definition Movie Mode
  • HDMV is an operation mode that operates in a command interpreter format that is compatible with DVD.
  • the BD-J module 15 is a middleware platform including a Java (registered trademark) virtual machine, and executes a BD-J application.
  • the BD-J application is recorded in the BD-ROM 100 in association with the playback video, and is read by the dynamic scenario memory 12 during playback and then executed by the BD-J module 15.
  • the Java (registered trademark) virtual machine interprets the BD-J application and causes the CPU to execute it.
  • a part of the BD-J module 15 may be realized by hardware or may be realized by software.
  • Mode management module 16 holds the mode management table read from the virtual file system 25 and performs mode management and branch control.
  • the mode management by the mode management module 16 is a process of assigning a module, which HDMV module 14 and BD-J module 15 execute a dynamic scenario.
  • Dispatcher 17 selects only the UO appropriate for the mode in the current playback device from the user operation (user operation, hereinafter also referred to as UO) received by the UO detection module 21, and passes it to the module that executes the mode. For example, when the UMV such as up / down / left / right and activate is accepted during execution of the HDMV mode, the dispatcher 17 processes outputting these UOs to the HDMV mode module.
  • UO user operation
  • the AV playback library 18 is a library for executing an AV playback function and a playlist playback function in response to a call from the HDMV module 14 or the BD-J module 15. Functions as a control engine.
  • the AV playback function is a function group defined by the BD-ROM that follows the DVD player and CD player. Playback start, playback stop, pause, pause release, still image function release, playback speed Are fast-forwarding with an immediate value, rewinding with a playback speed specified with an immediate value, audio switching, sub-video switching, and angle switching.
  • the playlist playback function is a start / stop playback of the AV playback function according to the playlist information.
  • Graphics decoder 19 The graphics decoder 19 performs expansion processing of caption data, and writes the expanded left-eye caption image and right-eye caption image to the left-eye caption plane 30 and the right-eye caption plane 31, respectively.
  • plane combiner 20 The plane synthesizer 20 performs left-eye and right-eye composition processing on four types of planes, a background plane, a video plane, a caption plane, and a graphics plane, based on a composition mode to be described later, and outputs the result as a video To do.
  • UO detection module 21 receives a user operation (UO) input by the viewer of the device to the playback device. This may be input by a remote device such as a remote controller, or may be input directly by an interface such as a button installed on the device.
  • UO user operation
  • the rendering engine 22 draws on the image memory 7, the left-eye graphics plane 9, the right-eye graphics plane 10, the left-eye background plane 28, and the right-eye background plane 29 (hereinafter collectively referred to as graphics memory).
  • the BD-J module 15 has a library for performing drawing processing such as drawing of lines and rectangles with color designation, painting of a designated area, copy / paste of a designated image, and the like through the rendering engine 22.
  • the BD-J application can realize various graphics drawing processes for the graphics memory by continuously issuing these drawing process requests.
  • the network interface 23 is used for downloading BD-ROM additional content published on the Internet.
  • the BD-ROM additional content is content that does not exist in the original BD-ROM, and includes, for example, additional sub audio, subtitles, privilege video, and applications.
  • the network interface 23 can be controlled from the BD-J module 15, and additional content published on the Internet can be downloaded to the local storage 24 and the removable medium 27.
  • the local storage 24 is a magnetic recording device such as a hard disk built in the playback device. In the file format recorded on the BD-ROM 100 or in a form conforming thereto, various data used for transport stream and reproduction are recorded.
  • Virtual file system 25 is a file system that provides a read / write mechanism for files recorded on the BD-ROM 100, the local storage 24, or the removable medium 27.
  • the file access required for playback of the BD-ROM is normally performed on the BD-ROM 100.
  • the virtual file system 25 records the file existing in the local storage 24 or the removable medium 27 as if it was recorded on the BD-ROM 100.
  • Audio decoder 26 The audio decoder 26 decodes the audio frame output from the demultiplexer 3 and outputs uncompressed audio data.
  • Removable media 27 The removable medium 27 is a storage medium inserted from an external slot attached to the playback device.
  • the left-eye background plane 28 and the right-eye background plane 29 are memories for storing a background image, and correspond to HBackgroundDevice in the HAVi device.
  • a video plane is superimposed on the background plane. Therefore, if the video occupies the entire screen, the background plane will be hidden and invisible, but under circumstances where the video is scaled or reduced, a background image will be displayed around the video. Become. It is desirable that the graphics plane can be used in abundant colors, but the number of colors that can be used in the background plane is limited. In this case, it is preferable to treat the image that can be transferred to the background plane and the image that can be transferred to the graphics plane as different types of bitmap images. With this configuration, there is an effect that the amount of memory required for the background plane can be reduced by suppressing the number of colors of the background plane.
  • the subtitle plane for left eye 30 and the subtitle plane for right eye 31 are memories for storing subtitle images to be superimposed on the video.
  • the basic function of the plane synthesizer 20 is to synthesize four planes for the left eye and right eye, that is, the background plane, video plane, subtitle plane, and graphics plane in order from the bottom, and output as video. is there.
  • Video output can output different video for the left eye and right eye.
  • the viewer can obtain a stereoscopic effect by viewing different videos for the left eye and the right eye.
  • the left and right images are different in all planes.
  • the background plane displayed behind the video plane and the graphics plane such as a menu superimposed on the video plane may be the same image on the left and right.
  • the background plane and graphics will appear flat to the viewer, but this configuration is advantageous in terms of cost because it facilitates the production of BD-ROM content. .
  • the playback device plane synthesizer 20 supports a plurality of synthesis modes, and the BD-J app activates the synthesis mode when necessary. Can be switched automatically.
  • the graphics plane uses the same image on the left and right, but when the transition is made from the menu to the bonus game function, the graphics plane also requires a three-dimensional effect. It is only necessary to switch the graphics plane synthesis mode so that different graphics can be displayed with the right eye.
  • the same left and right images are used when used as the background around the scaled video, and the left and right images are different when used as the background for the game function.
  • the synthesis mode of the background plane can be switched.
  • FIG. 20A shows the layer configuration of the plane memory and the components of the plane synthesizer 20.
  • the demultiplexing unit 105 includes an adder 51, an adder 52, and an adder 53 provided in the left eye output system of the plane memory layer configuration, and an adder 61 provided in the right eye output system of the plane memory layer configuration.
  • Adder 62, adder 63, switch 64, and switch 65 are constituent elements.
  • the adder 51 combines the stored contents of the left-eye video plane with the stored contents of the left-eye background plane.
  • the adder 52 combines the stored content of the left-eye caption plane and the combined result of the adder 51.
  • the adder 53 combines the stored contents of the left-eye graphics plane and the combined result of the adder 52.
  • the adder 61 combines the stored contents of the left-eye video plane and the stored contents of the left-eye background plane or the right-eye background plane.
  • the adder 62 combines the stored content of the right-eye caption plane and the combined result of the adder 61.
  • the adder 63 combines the stored contents of the left-eye graphics plane or the right-eye graphics plane with the combined result of the adder 62.
  • the switch 64 switches the pixel data supply source for the adder 61 to either the left-eye background plane or the right-eye background plane.
  • the pixel data supply source to the adder 61 is a left-eye background plane
  • the configuration is a single plane configuration.
  • the pixel data supply source is a right-eye background plane
  • the configuration is two planes. It becomes composition.
  • the switch 65 switches the pixel data supply source to the adder 63 to either the left-eye graphics plane or the right-eye graphics plane.
  • the configuration is a one-plane configuration
  • the configuration is a two-plane configuration.
  • the subtitle plane configuration also has a one-plane configuration and a two-plane configuration. Since the description will be complicated, the description will be made assuming that the subtitle plane is fixed in a two-plane configuration.
  • FIG. 21A shows a synthesis mode (synthesis mode 1) based on an output system in which the ratio of the graphics plane, caption plane, video plane, and background plane is 2: 2: 2: 2. Since the number of planes of the graphics plane, subtitle plane, and background graphics plane are all two, the supply source to the adder 63 is the graphics plane for the right eye, and the supply source to the adder 61 is the background plane for the right eye It has become. In composition mode 1, two graphics planes are used for the left eye and for the right eye. Two background planes are used, one for the left eye and one for the right eye.
  • the background plane for the left eye from the bottom As the left-eye video output, the background plane for the left eye from the bottom, the video plane for the left eye, the subtitle plane for the left eye, and the graphics plane for the left eye are combined in this order.
  • the video plane, the right-eye caption plane, and the right-eye graphics plane are combined in this order.
  • both the graphics plane and the background plane can be three-dimensionally expressed.
  • FIG. 21B shows a synthesis mode (referred to as synthesis mode 2) based on an output system in which the ratio of the graphics plane, caption plane, video plane, and background plane is 1: 2: 2: 2. Since the number of planes in the graphics plane is “1”, the supply source to the adder 63 is the left-eye graphics plane, and the supply source to the adder 61 is the right-eye background plane. In the synthesis mode 2, only the left-eye graphics plane is used, and the left-eye graphics plane is referred to for both the left-eye video output and the right-eye video output. As a result, the same video is output for the graphics plane, so that it looks flat to the viewer's eyes.
  • synthesis mode 2 shows a synthesis mode (referred to as synthesis mode 2) based on an output system in which the ratio of the graphics plane, caption plane, video plane, and background plane is 1: 2: 2: 2. Since the number of planes in the graphics plane is “1”, the supply source to the adder 63 is the left-eye graphics plane, and the
  • the background plane two for the left eye and one for the right eye are used as in the synthesis mode 1.
  • the left-eye background plane, the left-eye video plane, the left-eye caption plane, and the left-eye graphics plane are synthesized from the bottom as the left-eye video output, and the right-eye background plane from the bottom as the right-eye video output.
  • the right-eye video plane, the right-eye caption plane, and the left-eye graphics plane are sequentially combined. Therefore, the background plane can be represented in three dimensions, but the graphics plane is limited to a planar expression.
  • FIG. 21C shows a synthesis mode (referred to as synthesis mode 3) based on an output system in which the ratio of the graphics plane, caption plane, video plane, and background plane is 2: 2: 2: 1. Since the number of background planes is one, the supply source to the adder 61 is the left-eye background plane. In composition mode 3, two graphics planes are used, one for the left eye and one for the right eye, but only the background plane is used for the left eye. Both the left-eye video output and the right-eye video output are both the left-eye background plane. Is referenced. As a result, the same video is output on the left and right sides of the background plane, so that it looks flat to the viewer's eyes.
  • the left-eye background plane, the left-eye video plane, the left-eye caption plane, and the left-eye graphics plane are sequentially combined as the left-eye video output, and the bottom-left background is output as the right-eye video output.
  • the plane, the right-eye video plane, the right-eye caption plane, and the right-eye graphics plane are combined in this order. Therefore, the graphics plane can be represented in three dimensions, but the background plane is limited to a planar expression.
  • FIG. 21D shows a synthesis mode (synthesis mode 4) using an output system in which the ratio of the graphics plane, caption plane, video plane, and background plane is 1: 2: 2: 1. Since the number of plane memories of the graphics plane is 1 plane and the number of background planes is 1, the supply source to the adder 63 is the left-eye graphics plane, and the supply source to the adder 61 is the left-eye background plane. It has become. In the synthesis mode 4, only the left eye is used for both the graphics plane and the background plane.
  • both the graphics plane and the background plane are limited to a planar expression.
  • FIG. 22 is a diagram illustrating an example of a graphics rendering function API supported by the BD-J module 15
  • FIG. 23 is a diagram illustrating an example of a call code of the graphics rendering function API of FIG. Triggered by these API calls from the BD-J application, that is, a drawing request, the BD-J module 15 executes an actual drawing process using the rendering engine 22.
  • Image drawing request 801 The image drawing request 801 is a request for copying a single bitmap image to the left-eye graphics plane 9 in the playback apparatus having the internal configuration of the third embodiment, and the Graphics # drawImage of the first embodiment. It corresponds to.
  • the drawing image of the copy source and the drawing position of the copy destination are input, and the target drawing image is copied to the designated drawing position of the left-eye graphics plane 9.
  • the drawn image exists in the image memory, and is transferred from the image memory to the left-eye graphics plane 9 by the rendering engine 22 at high speed.
  • Right / left image drawing request 802 The left / right image rendering request 802 requests that the two bitmap images be simultaneously copied to the left-eye graphics plane 9 and the right-eye graphics plane 10 in the playback apparatus having the internal configuration of the third embodiment. Yes, corresponding to StereoGraphics # drawImage of the first embodiment. This request receives two copy images to be copied and two drawing positions as input. One drawing image is drawn on the left-eye graphics plane 9, and the other drawing image is drawn on the right-eye graphics plane 10. Each drawing image exists in the image memory, and is transferred from the image memory to the left-eye graphics plane 9 and the right-eye graphics plane 10 by the rendering engine 22 at high speed.
  • the synthesis mode switching request 803 is an API for switching the synthesis mode of the plane synthesizer 20 in the playback apparatus having the internal configuration of the third embodiment, and corresponds to the configuration setting request of the first embodiment.
  • the difference from the first embodiment is that the resolution, graphics plane setting, and background plane setting are input.
  • the resolution is required when the playback device supports a plurality of resolutions, but in the third embodiment, it is assumed that the resolution is always fixed to 1920 ⁇ 1080.
  • a background plane exists as a plane memory, it is possible to select either a 1-plane configuration or a 2-plane configuration as a graphics plane and background plane setting in the synthesis mode switching request. it can.
  • the 1 plane configuration represents a mode in which the same video is output for the left eye and the right eye, and corresponds to the aforementioned 1 plane + Offset mode.
  • the 2-plane configuration represents a mode in which different videos are output for the left eye and the right eye, and corresponds to the 3D-LR mode described above.
  • the plane combiner 20 needs to transition to the combining mode 1 described later.
  • Background drawing request 804 is an API for copying one bitmap image to the left-eye background plane 28. Using the copy source drawing image as an input, the target drawing image is copied to the entire left-eye background plane 28.
  • Background drawing request 805 The background drawing request 805 is an API for copying two bitmap images to the left-eye background plane 28 and the right-eye background plane 29, respectively. Two drawing images to be copied are input, one drawing image is copied to the left-eye background plane 28, and the other drawing image is copied to the right-eye graphics plane 29. Each drawing image exists in the image memory, and is transferred from the image memory to the entire left-eye background plane 28 and the entire right-eye background plane 29 by the rendering engine 22 at high speed.
  • the copy destination of the background drawing request can be set for the entire background plane, or the drawing position can be specified in the same way as the graphics plane.
  • Processing Procedure when Synthesizing Mode Switching Request is made Next, a processing procedure when the synthesizing mode switching request 803 is called will be described with reference to FIG. The processing of the synthesis mode switching request 803 is performed by comparing the current synthesis mode of the plane synthesizer 20 with the requested synthesis mode.
  • the current background plane is one plane (synthesis mode 3 or synthesis mode 4) (S905).
  • the background plane is switched to 2 planes (S906).
  • the synthesis mode switching request 803 returns to the BD-J application after the processing of S909 is completed, and transfers control. Since the BD-J system supports multi-threading, other threads of the BD-J application operate independently while the synthesis mode switching request 803 is processed. Is implemented as a synchronous method, the thread that called the synthesis mode switching request 803 is blocked until the switching process is completed.
  • the image drawing request 801 which is a graphics plane drawing request for one plane, is prohibited (S1001), and when the image drawing request 801 is subsequently called, the call is ignored as described above. Raise an exception.
  • the initial state in which the graphics plane is one plane as described above, calling of the image drawing request 801 is permitted and calling of the left and right image drawing request 802 is prohibited. Both calls of the image drawing request 802 are prohibited.
  • the entire contents of the left-eye graphics plane 9 are copied to the right-eye graphics plane 10 (S1002).
  • the image of the left-eye graphics plane 9 is output as a video, and what kind of image is stored in the right-eye graphics plane 10 is undefined, for example, it remains black all over. ing.
  • the graphics plane is switched to 2 planes as it is, the entire black black right-eye graphics plane 10 is output as an image.
  • the fact that the BD-J application has called the compositing mode switching request 803 means that the BD-J application is expected to draw a correct image on the right-eye graphics plane 10 after that, but there is a time lag until drawing.
  • the synthesis mode of the plane synthesizer 20 is switched to the synthesis mode 1 or the synthesis mode 3 (S1003). If the current background plane is 2 planes, the mode may be changed to the synthesis mode 1, and if it is 1 plane, the mode may be changed to the synthesis mode 3.
  • the left and right image drawing request 802 which is a graphics plane drawing request for two planes, is prohibited (S1101), and when the left and right image drawing request 802 is subsequently called, the call is ignored as described above. Or to raise an exception.
  • calling of the image drawing request 801 is prohibited and calling of the left and right image drawing request 802 is permitted.
  • the image drawing request 801 and the left and right image drawing request are allowed. Both calls of 802 will be prohibited.
  • the synthesis mode of the plane synthesizer 20 is switched to the synthesis mode 2 or the synthesis mode 4 (S1102). If the current background plane is 2 planes, the mode may be changed to the synthesis mode 2, and if it is 1 plane, the mode may be changed to the synthesis mode 4.
  • a redraw request event is notified to the BD-J application (S1104).
  • redrawing may be necessary, but after switching to compositing mode where the graphics plane is one plane, the same graphics processing as the conventional BD-J specification is possible Since it is in a state, a redraw request event is notified in this step in order to be consistent with the conventional specification.
  • Whether the background plane has a 2-plane configuration or a 1-plane configuration is set by a configuration setting request by a bytecode application.
  • the situation described in the first embodiment that is, the configuration of the left-eye background plane and the right-eye background plane is requested to be switched from the 1-plane configuration to the 2-plane configuration.
  • the processing of S906 for switching the background plane to two planes and the processing of S908 for switching the background plane to one plane are realized by the same processing flow as in FIG. 25 (a) and FIG. 25 (b), respectively. To do.
  • the 2D graphics rendering request is invalidated before copying the background plane, so the pixel data from the left-eye background plane to the right-eye background plane is invalidated. After copying is completed, new graphics are not written to the left-eye background plane. Even if the 2D graphics rendering request is delayed and reaches java.awt.Graphics, the stored contents of the background plane cannot be displayed according to the 2D graphics rendering request, and there is a visual mismatch between the eyes of both eyes. Absent.
  • the present embodiment relates to an improvement of how to prohibit and cancel a one-plane drawing request in a playback apparatus in the playback apparatus in the layer model described in the first embodiment. .
  • FIG. 26 is a flowchart showing the processing procedure of org.havi.ui at the time of call of setConfiguraion. This flowchart corresponds to the highest level process of the plane configuration switching process, that is, the main routine, and there are flowcharts shown in FIGS. 27 to 30 as lower flowcharts of this flowchart. Hereinafter, a processing procedure in the main routine will be described.
  • step S901 it is determined whether the current graphics plane configuration is a one-plane configuration, and the second argument at the time of a setConfiguraion call, that is, whether the number of graphics planes specifies a two-plane configuration. is there. This determination is a more detailed description of step S901 in FIG. If this step S901 is Yes, in step S1000, two graphics planes having the resolution specified by the first argument are secured, and then steps S1001 to S1004 are executed.
  • Steps S1001 to S1004 are a procedure for switching to a two-plane configuration by a setConfiguraion call, which is the same as the processing procedure of FIG. 25A in the previous embodiment, and has the same reference numerals as those in FIG. is doing.
  • the one-plane drawing request for the graphics plane is prohibited (step S1001)
  • the pixel data is copied from the left-eye graphics plane to the right-eye graphics plane (step S1002)
  • the synthesis mode of the plane synthesizer is switched.
  • Step S1003 The prohibition of the 2-plane drawing request for the graphics plane is canceled (Step S1004).
  • Step S903 it is determined whether the current graphics plane configuration has a 2-plane configuration, and the second argument at the time of a setConfiguraion call, that is, whether the number of graphics planes specifies a 1-plane configuration. is there. This determination is a more detailed step S903 of FIG. If this step S903 is Yes, after securing one plane of the graphics plane of the resolution specified by the first argument in step S1100, steps S1101 to S1104 are executed.
  • Steps S1101 to S1104 are a procedure for switching to a one-plane configuration by a setConfiguraion call, which is the same as the processing procedure of FIG. 25B in the previous embodiment, and has the same reference numerals as those in FIG. is doing. Specifically, the drawing request for two planes with respect to the graphics plane is prohibited (step S1101), the synthesis mode of the plane combiner is switched (step S1102), and the prohibition of the drawing request for one plane with respect to the graphics plane is canceled (step S1103). ), A redrawing request event is notified (step S1104).
  • step S905 whether or not the current background plane configuration is a one-plane configuration and the second argument at the time of a setConfiguraion call, that is, whether the number of background planes specifies a two-plane configuration or not. It is a judgment.
  • This determination is a more detailed description of step S905 in FIG. If this step S905 is Yes, in step S1010, two background planes having the resolution specified by the first argument are secured, and then steps S1011 to S1014 are executed. Steps S1011 to S1014 are a procedure for switching to a two-plane configuration by a setConfiguraion call, and the processing procedure of FIG. 25A in the previous embodiment is applied to the background plane.
  • step S1011 the one-plane drawing request for the background plane is prohibited (step S1011)
  • the pixel data is copied from the left-eye background plane to the right-eye background plane (step S1012)
  • the plane synthesizer is synthesized.
  • the mode is switched (step S1013), and the prohibition of the 2-plane drawing request for the background plane is canceled (step S1004).
  • Step S907 is executed.
  • step S907 whether or not the current background plane configuration is a one-plane configuration, and the second argument at the time of a setConfiguraion call, that is, whether the number of background planes specifies a two-plane configuration. It is a judgment.
  • This determination is a more detailed description of step S907 in FIG. If this step S907 is Yes, in step S1110, one background plane having the resolution specified by the first argument is secured, and then steps S1111 to S1114 are executed. Steps S1111 to S1114 are a procedure for switching to a one-plane configuration by a setConfiguraion call, and the processing procedure of FIG.
  • step S1111 the drawing request for two planes with respect to the background plane is prohibited (step S1111), the synthesis mode of the plane combiner is switched (step S1112), and the prohibition of the drawing request for one plane with respect to the background plane is canceled ( In step S1113), a redraw request event is passed (step S1114).
  • FIG. 27 is a flowchart showing the processing procedure of java.awt.Graphics.
  • a loop consisting of step S1 to step S2 is executed.
  • Step S1 is a determination of whether or not a call to java.awt.Graphics has been made. If a call to java.awt.Graphics is made, graphics rendering is executed in accordance with the first and second arguments in step S3. .
  • Step S2 is a determination of whether or not the one-plane drawing request is prohibited. If prohibited, the process proceeds from step S2 to step S4.
  • Step S4 is a determination as to whether or not a call code of Graphics # drawImage exists in the stack.
  • step S5 the Graphics # drawImage is ignored by returning an Exception to the calling thread of the call code of Graphics # drawImage.
  • step S6 waits for a determination as to whether or not the one-plane drawing request has been canceled. If the request has been canceled, the process returns to the loop of steps S1 and S2.
  • java.awt.Graphics executes the above processing, the drawing request for one plane is prohibited in step S1001 of FIG. 25A, and then the drawing request for one plane is changed in step S1103 of FIG. Until the ban is lifted, java.awt.Graphics will never execute Graphics # drawImage.
  • StereoGraphics is a graphics drawing package dedicated to StereoGraphics that processes only StereoGraphics # drawImage, it is assumed that StereoGraphics is started when moving to step S1004 in FIG. 26, and the operation of StereoGraphics ends when moving to step S1101 in FIG. You have to control the state of StereoGraphics to make it happen.
  • the application manager may execute the processing procedure of FIG. 28 as state control unique to StereoGraphics.
  • FIG. 28 is a flowchart showing a procedure for controlling the status of StereoGraphics by the application manager.
  • Step S11 waits for a determination as to whether or not the prohibition of the two-plane drawing request has been cancelled. If cancelled, the process proceeds to step S12 to load and start StereoGraphics. Thereafter, the process proceeds to a loop of step S13 to step S14.
  • Step S13 causes StereoGraphics to process 3D graphics. As long as a 3D graphics call is generated, StereoGraphics executes graphics writing to the left-eye graphics plane and the right-eye graphics plane in accordance with the 3D graphics call.
  • Step S14 is a determination of whether or not a two-plane drawing request is prohibited. Unless prohibited, the loop from step S13 to step S14 is repeated. If it is prohibited, the operation of StereoGraphics is terminated in step S15, and the process proceeds to step S11 to wait for the prohibition to be released.
  • StereoGraphics By controlling the state of StereoGraphics from the outside as described above, StereoGraphics operates in a limited manner.
  • FIGS. 29 Improvement to Device Driver To execute the processing of FIGS. 25A and 25B, when switching of the synthesis mode is requested in step S1003 of FIG. 26 and step S1102 of FIG. 26, the output system for the right eye It is necessary for the device driver to realize the release / addition and switching of the data supply source to the right eye adder. Such an improvement may be achieved by adding the processing procedure shown in the flowcharts of FIGS. 29A and 29B to the device driver.
  • FIG. 29 (a) is a flowchart showing a processing procedure corresponding to a main routine of a synthesis mode switching procedure by the synthesis mode device.
  • Step S21 determines whether the playback mode is the 3D playback mode or the 2D playback mode. If the playback mode is the 2D playback mode, the output system for the right eye is released in step S22. If the playback mode is the 3D playback mode, it is determined in step S23 whether there is an output system for the right eye. If it is valid, the output system for the right eye is switched in step S25. If it is not valid, after adding the output system for the right eye in step S24, the output system for the right eye is switched in step S25.
  • FIG. 29B is a flowchart showing a procedure for switching the output system for the right eye.
  • Step S26 is a determination as to whether or not the first argument of setConfiguraion is 2 planes. If Step S26 is No, the supply source to the right-eye adder is set to the left-eye graphics plane in Step S27. If step S26 is Yes, the supply source to the right-eye adder is set to the right-eye graphics plane in step S28.
  • Step S29 is a determination of whether or not the second argument of setConfiguraion is 2 planes. If No, the supply source to the right-eye adder is set as the left-eye background plane in step S30. If Yes, the supply source of the right eye adder is set as the right eye background plane in step S31.
  • FIG. 30 Processing Procedure for Implementing StereoGraphics
  • the entity of StereoGraphics is a resident bytecode application that causes the MPU to perform line drawing in response to a StereoGraphics # drawImage call.
  • FIG. 30 is a flowchart showing a line drawing procedure when the StereoGraphics # drawImage method is called.
  • variable Y is a control variable in the loop of this flowchart, is initialized at the step, and is used to determine whether or not the end condition of the flowchart at step S54 is successful.
  • step S51 The variable Y indicating the drawing target line of the drawing image is initialized to “1” (step S51), and the process proceeds to a loop of step S52 to step S54.
  • the RGB value of the Y line of the drawing image specified as the second argument is written from (x1, y1 + Y-1) to (x2, y1 + Y-1) of the left image plane (
  • step S52 the process of writing the RGB value of the fourth argument Y-line from (x3, y3 + Y-1) to (x4, y3 + Y-1) in the right image plane (step S53) It repeats until it determines with step S54 being Yes.
  • FIG. 31 is a flowchart of menu display by the bytecode application.
  • step S41 the frame in which the drawing image is to be displayed first is “frame t”, and the process proceeds to a loop of step S42 to step S47.
  • steps S42 to S47 an instance of the left image to be displayed in frame t is generated as image 1 (step S42), and an instance of the right image to be displayed in frame t is generated as image 2 (step S42).
  • S43 Waits for the start of the frame t to arrive (step S44). When the start arrives, the rectangular range for drawing the left image plane and the rectangular range for drawing the right image plane are specified (step S44). S45).
  • step S46 the StereoGraphics # drawImage method is called (step S46), and then the image is displayed.
  • step S47 The process of setting the power frame as the frame t (step S47) is repeated.
  • the playback apparatus it is possible to cause the playback apparatus to execute the characteristic processing described in the previous embodiments by improving the components in the player model and the layer model of the BD-J terminal.
  • the characteristic processing unique to the present application can be incorporated into the playback device without making a significant change to the basic configuration of the playback device. Thereby, the development man-hours of the playback device can be greatly reduced, and the product introduction of the playback device can be accelerated.
  • the playback mode in the playback device is determined by a mode selection procedure executed when a title is selected.
  • the title of this specification has at least one operation mode object as an essential component.
  • the operation mode object is an operation management table that defines details of the behavior of the playback device during title playback in a certain mode. These titles are classified into HDMV titles and BD-J titles.
  • HDMV Title An “HDMV title” is a title to be played back in the HDMV mode described in the third embodiment, and is a playlist that is played back by a movie object and a playback command in the movie object ( Playlist information, clip information, and stream file).
  • the “movie object” is an operation mode object associated with the title number of the HDMV title in the index table, and a resume flag indicating whether resume is possible or a menu call is added to the batch program composed of the navigation command string.
  • a flag indicating whether or not to mask is associated with a flag indicating whether or not to mask the title search.
  • BD-J title is a title to be played back in the BD-J mode described in the third embodiment, and includes a class archive file and a BD-J object. Composed.
  • a class archive file is a file in which a class structure file (class file) of a bytecode application is archived together with a digital certificate manifest file, a disk signature signature file, a disk signature encryption key file, and a permission request file. is there.
  • the application is loaded together as a class archive file.
  • the validity of the application can be verified using a digital certificate, a disk signature, and a disk signature encryption key.
  • the permission request file exists, the operation by the application can be limited to those given a certain authority.
  • Byte code application archived in class archive file is called BD-J application.
  • BD-J Application is subjected to state control by an application manager by implementing the Xlet interface.
  • This Xlet interface includes public void initXlet () ⁇ , which is an interface that defines the behavior of the BD-J application in the initial state, and public void startXlet () ⁇ , which is an interface that defines the behavior of the BD-J application in the start state.
  • Public void pauseXlet () ⁇ which is an interface that defines the behavior of the BD-J application in the pause state
  • public void destroyXlet () ⁇ that is an interface that defines the behavior of the BD-J application in the destroy state
  • APIs that can be used to realize stereoscopic playback in BD-J applications include Java2Micro_Edition (J2ME) Personal Basis Profile (PBP 1.0) and GloballyationExecutable MHP specification (GEM1.0.2) for package media targets.
  • J2ME Java2Micro_Edition
  • PBP 1.0 Personal Basis Profile
  • GEM1.0.2 GloballyationExecutable MHP specification
  • java.net for network processing
  • java.awt for GUI processing
  • java.lang for language processing
  • java.io for I / O processing for recording media
  • utilities BD capable of 3D playback with structured programming using methods, constructors, interfaces, and events of classes such as java.util, javax.media for media framework, and org.havi.ui for HAVi devices -J Title can be described.
  • BD-J extension includes in-lid methods from methods in the java.net, java.awt, java.lang, java.io, java.util, and javax.media classes. Because it is a super interface, BD-J assumes stereoscopic playback on the extension of programming techniques using java.net, java.awt, java.lang, java.io, java.util, javax.media classes You can create a title.
  • the extension API for the BD-J mode includes a setting acquisition class for instructing the status setting and status acquisition of the playback device.
  • the setting acquisition class includes a constant field indicating a holding value of the player status register (PSR), an acquisition method for instructing acquisition of the holding value of the PSR, and a setting method for instructing setting of the holding value of the PSR.
  • PSR player status register
  • the method of the setting acquisition class includes the in-hired method of the method of the java.lang.Object class. If the argument at the time of the method call is invalid, the java.lang.IlleghalArgumentException event that is an event of the java.lang class is thrown. Since this class inherits the methods and events of java.lang.Object, the programmer can create a program that uses the retained value of the register set with an extension of java.lang.Object. This completes the description of the class archive file.
  • BD-J object specifies the details of the behavior of the playback device in BD-J mode.
  • the details of the behavior are as follows: application class loading when the corresponding title becomes the current title (1), application signaling when the corresponding title becomes the current title (2), activated by the application signaling HAVi device configuration (3) when the application executes GUI processing, playlist access for the current title (4), cache-in / cache-out of the class archive file when the corresponding title becomes the current title (5 ),
  • event assignment (6) in which an event that triggers an activated application is assigned to a key.
  • “Class loading” is a process of generating an instance of a class file archived in a class archive file in the platform heap area.
  • “Application signaling” is an application that automatically starts an application that is an instance of a class file. It is control which prescribes whether or not the life cycle of the application is the title boundary or the disc boundary.
  • the title boundary is management that causes a thread that is an application to disappear from the heap area simultaneously with the end of the title
  • the disk boundary is management that causes a thread that is an application to disappear from the heap area simultaneously with the disk ejection.
  • control that does not delete a thread from the heap area even if the disk is ejected is called “disk unboundary”.
  • “HAVi device configuration” defines the resolution of the graphics plane and the font used for character display when the application executes the GUI processing.
  • Playlist access is the designation of a playlist that can be played by the started application and a playlist that should be automatically played when a title is selected.
  • Class archive file cache-in is the process of pre-reading the class archive file subject to class loading to the cache.
  • Class archive file cache-out is the process of caching the class archive file existing in the cache. It is processing to delete from.
  • Event assignment for application driving is to assign an event registered in the event listener of the application to a key that can be operated by the user.
  • modules such as a command interpreter for executing navigation commands and a playback control engine for decoding and playing back playlists are the main operating elements of the software. .
  • a class loader for class loading an application manager for application signaling, a HAVi device, a playback control engine for playlist playback using the Java media framework, and cash-in and cash-out management
  • the software group such as the cache manager for event management and the event manager for event processing, that is, the software group similar to the software group in the multimedia platform terminal of digital broadcasting becomes the main subject of operation, so from BD-J title to HDMV title When switching from the HDMV title to the BD-J title, the software configuration of the playback device is greatly different.
  • FIG. 32 is a diagram illustrating an example of an internal configuration of a BD-J object.
  • the BD-J object includes an “application management table”, “terminal management table”, “application cache information”, “playlist access information”, and “key interest table”.
  • the “application management table” is a control table that instructs the application manager and class loader to perform application signaling with the title as a boundary.
  • the “terminal management table” is used for the HAVi device configuration and GUI for realizing the GUI. This is a management table for instructing the multimedia home platform (MHP) whether or not there is a font and a mask for user operation.
  • MHP multimedia home platform
  • “Application cache information” is a control table for instructing the cache manager to cache in / out the archive file when the title is selected, and playback control is performed to specify automatic playback of the playlist when the “playlist access information” title is selected.
  • This is a control table for instructing the engine (PCE).
  • the “key interest table” is a control table that instructs the event manager to associate keys with events.
  • the lead line bj1 shows a close-up entry in the application management table.
  • the application management table entry indicates whether the application should be automatically started in the title (AutoStart) or whether it should be started after waiting for a call from another application (Present).
  • “Control code” indicating “application type” and “application ID” indicating the target application using a 5-digit numerical value that is the file name of the archive file in which the BD-J application to be started is archived , “Application descriptor”.
  • a lead line bj2 shows a close-up of the internal configuration of the “application descriptor”.
  • the “application descriptor” includes “priority” when the application is loaded and “binding” indicating whether the application is title unbound or discbound.
  • ⁇ Information '' a character string indicating the name of the application, a ⁇ language code '' indicating the language attribute of the application, an ⁇ icon locator '' indicating the location of the icon associated with the application, and an ⁇ application profile value '' Is stored.
  • the lead line bj3 shows the configuration information in the terminal management table in close-up.
  • the configuration information is information for instructing the playback device to secure the graphics plane.
  • the terminal management table includes HD3D_1920 ⁇ 1080, HD3D_1280 ⁇ 720, HD_1920 ⁇ 1080, HD_1280 ⁇ 720, QHD_960. ⁇ 540, SD, SD — 50HZ — 720 ⁇ 576, SD — 60HZ — 720 ⁇ 480 can be set.
  • the lead line bj4 shows a close-up of the internal structure of the information for specifying the automatic playback playlist in the playlist access information.
  • 3D playlist 1920 ⁇ 1080, 3D playlist 1280 ⁇ 720, 2D playlist 1920 ⁇ 1080, 2D playlist 1280 ⁇ 720, 2D playlist 720 are used to specify the automatic playback playlist.
  • * 576 and 2D playlist 720 * 480 can be specified.
  • the playback device When any title is selected, the playback device starts playback of the playlist specified by the playlist access information corresponding to the selected current title without waiting for a playback instruction from the application. If the BD-J application execution ends before the end of list playback, playback of the playlist is continued.
  • FIG. 33 is a flowchart illustrating an example of a processing procedure for setting the resolution of the plane memory at the time of title switching.
  • the processes of step S64, step S65, and step S67 are selectively executed according to the determination results of step S61, step S62, step S63, and step S66.
  • Step S61 is a determination as to whether or not there is an automatic playback playlist
  • Step S62 is a determination as to whether or not the previous playback mode is 3D
  • Step S63 is a determination as to whether or not the auto-play playlist of the selected title is a 1920 ⁇ 1080 3D playlist or a 1280 ⁇ 720 3D playlist.
  • step S66 it is determined in step S66 whether the default resolution of the operation mode object is HD3D — 1920 ⁇ 1080, HD3D — 1280 ⁇ 720. If yes, the play mode is set to 3D in step S65. Then, it is set to 1920 ⁇ 1080 or 1280 ⁇ 720 according to the default resolution in the operation mode object. If No, in step S67, the playback mode is set to 2D, and the resolution is set to the default resolution in the operation mode object.
  • Step S62 If there is no automatic playback playlist, whether or not the previous playback mode is 2D in step S62, or whether or not the playlist is a 3D playlist in step S63 and the resolution is 1920 ⁇ 1080, 1280 ⁇ 720 Determine. If either Step S62 or Step S63 is No, the playback mode is set to 2D in Step S64, and the resolution is set to the resolution of the automatic playback playlist.
  • step S65 the playback mode is set to 3D, and the resolution is set to 1920 ⁇ 1080 or 1280 ⁇ 720 depending on the resolution of the automatic playback playlist. To do. *
  • 33.2 Relevance between playback mode and graphics plane configuration
  • the mode of the playback device is switched from 2D playback mode to 3D playback mode.
  • the graphics plane maintains the state of the 1 plane configuration. That is, by calling the setConfiguraion API, the graphics plane maintains the state of the 1 plane configuration unless it is required to switch the configuration of the graphics plane from the 1 plane configuration to the 2 plane configuration.
  • the playback device mode is switched from the 2D playback mode to the 3D playback mode even when a 3D playlist corresponding to stereoscopic playback is selected as the automatic playback playlist.
  • the graphics plane maintains the state of the 1 plane configuration.
  • the graphics plane configuration is Automatically switches from 1 plane configuration to 2 plane configuration.
  • the HAVi device configuration of the BD-J object corresponding to the current title is the configuration of the graphics plane for the left eye and the graphics plane for the right eye.
  • the requirement is that a setConfiguraion API that requires a two-plane configuration is required.
  • stereoscopic playback can be realized using the resolution defined in the HAVi device configuration based on the BD-J object when the current title is selected.
  • FIG. 34 is a diagram for explaining the principle that an image appears to be in front of the display screen when the sign of the plane offset is positive.
  • the image that is visible to the left eye is shifted and displayed so that it appears at the right position compared to the case where the plane offset is zero. At this time, nothing is visible to the right eye by the shutter glasses 500. On the other hand, the image visible to the right eye is displayed so as to be shifted so that it can be seen on the left side compared to the case where the plane offset is zero. At this time, nothing is visible to the left eye by the shutter glasses 500 (FIG. 34 (b)).
  • ⁇ Human uses both eyes to focus and recognizes that there is an image at the focal position. Therefore, when the shutter glasses 500 alternately switch between a state in which an image can be seen by the left eye and a state in which the image can be seen by the right eye at short time intervals, both eyes of the human will try to adjust the focal position to a position in front of the display screen. As a result, an illusion is caused so that an image is present at the focal position located in front of the display screen (FIG. 34C).
  • FIG. 35 1 Principle for Displaying Images from the Display Screen to the Back in the 1 + plane + Offset Mode
  • FIG. 35 is a diagram for explaining the principle of displaying images so that they are at the back of the display screen.
  • FIG. 35A what is indicated by a circle is an image displayed on the display screen.
  • the image that can be seen by the right eye and the image that can be seen by the left eye are at the same position, so the focal position when viewing this image using both eyes is located on the display screen (FIG. 35 (a)). .
  • the resulting image is located on the display screen.
  • the image visible to the left eye is made to appear on the left side as compared with the case where the plane offset is zero. At this time, nothing is visible to the right eye by the shutter glasses 500.
  • the image that can be seen by the right eye is made to appear on the right side as compared with the case where the offset is 0, and at this time, nothing is seen by the left eyeglasses by the shutter glasses 500 (FIG. 35B).
  • the human eyes try to adjust the focal position to a position deeper than the display screen. An illusion is caused so that there is an image at a position behind the display screen (FIG. 35C).
  • FIG. 36 Difference between positive and negative offsets in 1 plane + Offset mode
  • FIG. 36 is a diagram illustrating an example of a difference in appearance between positive and negative plane offsets.
  • This figure (a) shows the case where the writing position of the drawing image in the left eye pupil incidence period is shifted to the right, and the writing position of the drawing image in the right eye pupil incidence period is shifted to the left.
  • the graphics at the time of incident output to the left eye pupil can be seen at the right position from the graphics at the time of incident output to the right eye pupil. That is, since the convergence point (focus position) comes to the front of the screen, the graphics can also be seen to the front.
  • This figure (b) shows the case where the writing position of the drawing image in the left eye pupil incidence period is shifted leftward, and the writing position of the drawing image in the right eye pupil incidence period is shifted rightward.
  • the graphics at the time of the incident output to the left eye pupil appear to the left of the graphics at the time of the output of the incident to the right eye pupil.
  • the convergence point (focus position) goes deeper than the screen, the graphics can also be seen deeper.
  • the graphics plane is composed of a plurality of line memories, and the ARBG format pixel data constituting the graphics is stored in a double word (32 bits) length constituting the graphics plane line memory. It is stored in each element.
  • the coordinates on the screen of the pixel data constituting the graphics correspond to, for example, a set of a ROW address indicating the line memory of the pixel data in the graphics plane and a COLUMN address indicating the storage element in the line memory.
  • stereoscopic vision is realized by giving a horizontal offset to the X coordinate of the pixel data in the graphics plane.
  • the coordinates on the screen of the pixel data constituting the OSD correspond to a combination of a ROW address indicating the line memory of the pixel data in the graphics plane and a COLUMN address indicating the storage element in the line memory. Therefore, if the COLUMN address indicating the storage element for each piece of graphics pixel data in the graphics plane is increased or decreased by an address corresponding to the horizontal offset, the coordinates of the pixel data can be displaced in the left-right direction.
  • the address shift of the pixel data can be realized by a copy process of the pixel data accompanied with the address adjustment.
  • the offset in the offset sequence incorporated in the access unit structure of the video stream is used in the 1 plane + Offset mode. Since the offset sequence defines a horizontal offset for each frame in the GOP, the pixel pop-out degree in the 1 plane + Offset mode is precisely synchronized with the video stream.
  • stereoscopic playback can be easily realized in a one-plane configuration, so that it is possible to simplify graphics drawing processing by a bytecode application.
  • a flash medium such as an SD card is used as the type of storage medium, but it may be a USB memory, a removable hard disk, or any other type of storage medium.
  • the image drawing request 801 is an API for drawing only on the left-eye graphics plane 9. Therefore, when called in the synthesis mode 1 and the synthesis mode 3, in the video output as a result of the synthesis, only the left eye is updated, and the right eye remains as the video before the update. That is, the left-eye image and the right-eye image are different from each other, which may cause discomfort to the viewer. Therefore, such a drawing request needs to be prohibited. Therefore, copy processing to the graphics plane 9 for the left eye is performed only when the image drawing request 801 is invoked in the composition mode 2 and composition mode 4, and when it is invoked in the composition mode 1 or composition mode 3. Ignore the call.
  • the function corresponding to the image drawing request 801 is defined as an API that does not generate an exception.
  • the left / right image drawing request 802 is a function for drawing the left-eye graphics plane 9 and the right-eye graphics plane 10 at the same time, and has a meaning when called in the synthesis mode 1 or the synthesis mode 3, but the synthesis mode 2 and the synthesis mode 2.
  • mode 4 When called in mode 4, only the drawing for the left eye is meaningful, so there is a high possibility of an error in the BD-J application. Therefore, drawing processing on both graphics planes is performed only when the left / right image drawing request 802 is called in the combining mode 1 or the combining mode 3, and when called in the combining mode 2 and the combining mode 4, an exception is made. Shall be generated.
  • the left / right image rendering request 802 is a newly defined API that does not exist in the conventional BD-J specification, and even if an exception is generated, there is no conflict with the conventional specification, so the developer is surely notified of the error. For this reason, a method of generating an exception is desirable. However, like the image drawing request 801, the call may be ignored.
  • the background rendering request 804 is meaningful only in the synthesis mode 3 and the synthesis mode 4, and when called in the synthesis mode 1 or the synthesis mode 2, the video output of the synthesis result is different between the left eye and the right eye. Therefore, it is necessary to ban.
  • an exception is generated as in the case of the left and right image drawing request 802, but the call may be ignored.
  • the background rendering request 805 is meaningful only in the synthesis mode 1 or the synthesis mode 2, and when called in the synthesis mode 3 and the synthesis mode 4, there is a high possibility of an error in the BD-J application. It is desirable to ban. As a prohibition method, an exception is generated as in the case of the left and right image drawing request 802, but the call may be ignored.
  • the drawing request 802 When the left / right image drawing request 802 is called in the synthesis mode 2 or 4, if only the drawing processing portion for the left-eye graphics plane 9 in the drawing request is extracted and executed, the graphics plane is 1 It is possible to process the left and right image drawing request 802 even in a plane situation. Further, if these drawing requests are called at a timing when both the image drawing request 801 and the left and right image drawing request 802 existing during the composition mode switching are prohibited, the drawing request is temporarily suspended. The processing may be restarted at the timing when the synthesis mode switching processing is completed.
  • the synthesis mode switching of the plane synthesizer 20 may be performed only once. For example, when it takes a long time to switch the synthesis mode, it is desirable to switch the synthesis mode once. For example, consider a case where both the graphics plane and the background plane are switched from 1 plane to 2 planes, that is, the mode is switched from synthesis mode 4 to synthesis mode 1. First, the one-plane drawing request in S1001 is prohibited for both the graphics plane and the background plane, that is, both the image drawing request 801 and the background drawing request 804 are prohibited.
  • the left-eye plane is always used in the 1D 2D playback mode synthesis mode.
  • the 1-plane synthesis mode only the left-eye plane is used or the right-eye plane is used.
  • the playback apparatus 200 keeps the left or right main state of the video stream, and in the synthesis mode 2 and the synthesis mode 4, which of the left and right graphics planes is referred to is based on the above state. Similarly, in the synthesis mode 3 and the synthesis mode 4, it is only necessary to select which of the left and right background planes is to be referred to based on the above state.
  • the synthesis mode 3 and the synthesis mode 4 it is only necessary to select which of the left and right background planes is to be referred to based on the above state.
  • the video stream has information indicating whether the video for the left eye is main or whether the video for the right eye is main.
  • the BD-J application specifies the information. Also good.
  • 3D playlist playback procedure using object-oriented programming language (Description of 3D playlist playback procedure using object-oriented programming language)
  • the 3D playlist playback procedure using the object-oriented programming language may be described as follows.
  • BDLocator loc newBDlocator (bd: //1.PLAYLIST: 00001).
  • play list playback is started by calling start () which is a member function of the JMF player instance. If the variable name of the instance variable of the player instance is Player, it is described as Player.start (). (Description of stereoscopic dialogue screen) The bytecode application when creating a stereoscopic dialogue screen with two button members is described as (h-1) (h-2) (h-3) (h-4) ... May be.
  • H-2 Call the Hscene setLayout method with an instance of Flowlayout () in java.awt as an argument.
  • instance variable name of the Hscene class instance is “hs”, describe as hs.setLayout (new FlowLayout ()) ;.
  • Image normal StereoGraphics # drawImage (x1, y1, x2, y2, NormalButton1.bmp, x3, y3, x4, y4, NormalButton2.bmp); Is described.
  • Image focused StereoGraphics # drawImage (x1, y1, x2, y2, FocusedButton1.bmp, x3, y3, x4, y4, FocusedButton2.bmp); Is described.
  • variable name of the instance variable of the button class action state is actioned
  • file name of the left-eye image file is “actionedButton1.bmp”
  • file name of the right-eye image file is “actionedButton2.bmp”
  • Image actioned StereoGraphics # drawImage (x1, y1, x2, y2, actionedButton1.bmp, x3, y3, x4, y4, actionedButton2.bmp); Is described.
  • mt.addImage normal, 0
  • mt.addImage focused, 0
  • Write mt.addImage actioned, 0
  • H-7 Use add (), which is a member function of setLayout class, to add an instance of HGraphicsButton class to an instance of setLayout class. If the instance name of the instance variable of the setLayout class is “hs” and the instance name of the instance of the HGraphicsButton class to be added is “hgb1, hgb2”, describe as hs.add (hgb1); hs.add (hgb1); To do.
  • (h-8) Use the setVisible method, which is a member function of the setLayout class, to visualize an instance of the setLayout class.
  • the variable name of the instance variable of the setLayout class is “hs”, describe as hs.setVisible (true) ;.
  • (h-9) Using the requestFocus method that is a member function of the HGraphicsButton class, set the instance of the HGraphicsButton class to the focus state.
  • the variable name of the instance of the HGraphicsButton class is “hgb1”, it is described as hgb1.requestFocus () ;.
  • the digital interface When a digital interface having a high bandwidth transfer function is connected to another device in the home theater system via an interface, the digital interface shifts to the data transmission phase through the negotiation phase and performs data transmission.
  • this negotiation phase the TV capabilities of the digital interface (including decoding capability, playback capability, and display frequency) are grasped and set in the player setting register to determine the transmission method for subsequent transmissions. Yes, and includes a mutual authentication phase where each device is validated.
  • this negotiation phase one line of uncompressed and plain text pixel data in the layer-combined picture data is transferred to the television at a high transfer rate according to the horizontal synchronization period of the television.
  • uncompressed and plaintext audio data is transferred to other devices (including amplifiers and speakers as well as the television) connected to the playback device. .
  • devices such as a television, an amplifier, and a speaker can receive uncompressed / plaintext picture data and uncompressed / plaintext audio data, and can realize reproduction output.
  • the counterpart device has a decoding capability, it is possible to pass-through transmission of a video stream and an audio stream.
  • pass-through transmission a video stream and an audio stream can be transmitted in a compressed / encrypted format.
  • HDMI and USB exist as digital interfaces having such a high bandwidth transfer function.
  • An integrated circuit according to the present invention is a system LSI, and a mechanical part such as a drive unit of a recording medium or an external connector is excluded from a hardware configuration of a playback device, so that a logic circuit or a storage element is obtained.
  • the relevant part, that is, the core part of the logic circuit is incorporated.
  • the system LSI is a package in which a bare chip is mounted on a high-density substrate and packaged. By mounting multiple bare chips on a high-density substrate and packaging them, it is called a multichip module that has multiple bare chips with the same external structure as a single LSI. Included in the system LSI.
  • system LSIs are classified into QFP (Quad-Flood Array) and PGA (Pin-Grid Array).
  • QFP is a system LSI with pins attached to the four sides of the package.
  • the PGA is a system LSI with many pins attached to the entire bottom surface.
  • pins serve as power supply, ground, and interface with other circuits. Since pins in the system LSI have such an interface role, by connecting other circuits to these pins in the system LSI, the system LSI plays a role as the core of the playback device.
  • FIG. 37 is a diagram showing the architecture of an integrated circuit.
  • the architecture of the integrated circuit 70 that is a system LSI includes a front end unit 71, a signal processing unit 72, a back end unit 73, a media interface 74, a memory controller 75, a host microcomputer 76, and the like. And is connected to a drive, a memory, and a transmission / reception unit in the playback apparatus through a media interface 74 and a memory controller 75.
  • the drive in the playback device includes a BD-ROM drive, a local storage drive, a removable media drive, and the like.
  • the front-end processing unit 71 includes a preprogrammed DMA master circuit, an I / O processor, and the like, and executes all packet processing.
  • This packet processing includes processing for restoring an ATC sequence from a stereoscopic interleaved stream file, processing of a source packet depacketizer by a demultiplexing unit, and processing of a PID filter.
  • Stream processing as described above is realized by implementing DMA transfer between the track buffer, various plane memories, the coded data buffer in the video decoder, and the decoded data buffer secured in the memory of the playback device.
  • the signal processing unit 72 is composed of a signal processor, a SIMD processor, and the like, and executes signal processing in general. Signal processing includes decoding by a video decoder and decoding by an audio decoder.
  • the back end unit 73 is composed of an adder and a filter, and performs AV output processing in general.
  • the AV output processing includes pixel processing, and image superimposition, resizing, and image format conversion for layer synthesis are performed by the pixel processing. Also, digital / analog conversion and the like are executed together.
  • the media interface 74 is an interface with a drive and a network.
  • the memory controller 75 is a slave circuit for memory access, and realizes reading / writing of memory of packets and picture data in response to requests from the front end unit, signal processing unit, and back end unit. By reading and writing the memory through the memory controller 75, the memory becomes a track buffer, video plane, graphics plane, coded data buffer in the video decoder, decoded data buffer, elementary buffer, coded data buffer in the graphics decoder, composition data buffer. It will function as an object buffer.
  • the host microcomputer 76 includes a CPU, a ROM, and a RAM, and performs overall control over the media interface, front end unit, signal processing unit, and back end unit.
  • the overall control includes control as a control unit, a BD-J module, an HDMV module, and a module manager.
  • the CPU in the host microcomputer has an instruction fetch unit, a decoder, an execution unit, a register file, and a program counter.
  • a program for executing various processes described in the above embodiments is stored as a built-in program in a ROM in the host microcomputer together with a basic input / output program (BIOS) and various middleware (operation system). Has been. Therefore, the main functions of the playback device can be incorporated in this system LSI.
  • BIOS basic input / output program
  • the program shown in each embodiment can be created as follows. First, a software developer uses a programming language to write a source program that implements each flowchart and functional components. In this description, the software developer describes a source program that embodies each flowchart or functional component by using a class structure, a variable, an array variable, or an external function call according to the syntax of the programming language.
  • the described source program is given to the compiler as a file.
  • the compiler translates these source programs to generate an object program.
  • Translator translation consists of processes such as syntax analysis, optimization, resource allocation, and code generation.
  • syntax analysis lexical analysis, syntax analysis, and semantic analysis of the source program are performed, and the source program is converted into an intermediate program.
  • optimization operations such as basic block formation, control flow analysis, and data flow analysis are performed on the intermediate program.
  • resource allocation in order to adapt to the instruction set of the target processor, a variable in the intermediate program is allocated to a register or memory of the processor of the target processor.
  • code generation each intermediate instruction in the intermediate program is converted into a program code to obtain an object program.
  • the object program generated here is composed of one or more program codes that cause a computer to execute the steps of the flowcharts shown in the embodiments and the individual procedures of the functional components.
  • program codes such as a processor native code and a JAVA byte code.
  • a call statement that calls the external function becomes a program code.
  • a program code that realizes one step may belong to different object programs.
  • each step of the flowchart may be realized by combining arithmetic operation instructions, logical operation instructions, branch instructions, and the like.
  • the programmer When the object program is generated, the programmer activates the linker for these.
  • the linker allocates these object programs and related library programs to a memory space, and combines them into one to generate a load module.
  • the load module generated in this manner is premised on reading by a computer, and causes the computer to execute the processing procedures and the functional component processing procedures shown in each flowchart.
  • Such a program may be recorded on a computer-readable recording medium as a non-transitory computer program and provided to the user.
  • the recording medium in each embodiment includes all package media such as an optical disk and a semiconductor memory card.
  • the recording medium of the present embodiment will be described by taking an example of an optical disc (for example, an existing readable optical disc such as a BD-ROM or DVD-ROM) in which necessary data is recorded in advance.
  • a terminal device having a function of writing 3D content including data necessary for carrying out the present invention distributed via broadcasting or a network to an optical disc (for example, the function described on the left may be incorporated in a playback device) It may be good or may be a device different from the playback device) and recorded on a writable optical disc (for example, an existing writable optical disc such as BD-RE, DVD-RAM) and the recorded optical disc
  • a writable optical disc for example, an existing writable optical disc such as BD-RE, DVD-RAM
  • the video plane for the left eye and the video plane for the right eye are not indispensable components of the playback device, and it is sufficient for the playback device to have a graphics plane for the left eye and a graphics plane for the right eye.
  • Drawing images to be displayed on the graphics plane include moving images. If such a drawing image is written on the graphics plane, the problem of the present application can be solved even if a video decoder or a video plane does not exist in the playback device. Because it can.
  • the shutter glasses 500 are not essential components but optional. This is because the shutter glasses 500 are not necessary if the television 400 is an integral imaging method (optical reproduction method) and capable of autostereoscopic viewing.
  • the television 400 and the playback device 200 may be integrated.
  • Embodiments of Semiconductor Memory Card Recording Device and Playback Device Embodiments of a recording apparatus that records the data structure described in each embodiment in a semiconductor memory and a reproducing apparatus that reproduces the data structure will be described.
  • a part of the data may be encrypted as necessary from the viewpoint of protecting the copyright and improving the confidentiality of the data.
  • the encrypted data may be, for example, data corresponding to a video stream, data corresponding to an audio stream, or data corresponding to a stream including these.
  • data for example, a device key
  • a key necessary for decrypting the encrypted data in the BD-ROM is stored in advance in the playback device.
  • the BD-ROM decrypts the data corresponding to the key necessary for decrypting the encrypted data (for example, MKB (media key block) corresponding to the above-mentioned device key) and the encrypted data.
  • Data for encrypting the key itself (for example, the above-described device key and encrypted title key corresponding to MKB) is recorded.
  • the device key, the MKB, and the encrypted title key are paired, and are also associated with an identifier (for example, a volume ID) written in an area that cannot be normally copied (an area called BCA) on the BD-ROM. Has been. If this combination is not correct, the code cannot be decrypted.
  • the key necessary for decryption (for example, the title key obtained by decrypting the encrypted title key based on the above-mentioned device key, MKB and volume ID) can be derived.
  • the encrypted data can be decrypted using the necessary key.
  • the loaded BD-ROM When the loaded BD-ROM is played back on a playback device, for example, if the device key that is paired with (or corresponding to) the encrypted title key and MKB in the BD-ROM is not in the playback device, it is encrypted. The data is not played back. This is because the key (title key) required to decrypt the encrypted data is recorded on the BD-ROM with the key itself encrypted (encrypted title key), and a combination of MKB and device key. If is not correct, the key necessary for decryption cannot be derived.
  • the playback apparatus is configured such that the video stream is decoded by the decoder using the title key, and the audio stream is decoded by the audio decoder.
  • the above is the mechanism for protecting the copyright of the data recorded on the BD-ROM.
  • this mechanism is not necessarily limited to the BD-ROM.
  • a readable / writable semiconductor memory for example, SD
  • the present invention can be implemented even when applied to a portable semiconductor memory card such as a card.
  • an optical disk is configured to read data via an optical disk drive, whereas when a semiconductor memory card is used, data is read via an I / F for reading data in the semiconductor memory card. What is necessary is just to comprise so that it may read.
  • the playback device and the semiconductor memory card are electrically connected via the semiconductor memory card I / F. What is necessary is just to comprise so that the data recorded on the semiconductor memory card may be read through the semiconductor memory card I / F.
  • the playback device described in each embodiment is also realized as a terminal device that receives data (distribution data) corresponding to the data described in this embodiment from a distribution server of an electronic distribution service and records it on a semiconductor memory card. be able to.
  • Such a terminal device may be configured such that the playback device described in each embodiment can perform such an operation, or stores distribution data in a semiconductor memory separately from the playback device of the present embodiment. It may be configured to be performed by a dedicated terminal device that performs the above. Here, an example performed by the playback apparatus will be described. Further, an SD card will be described as an example of the recording destination semiconductor memory.
  • the playback device When recording distribution data on an SD memory card inserted in a slot provided in the playback device, first, transmission of distribution data is requested to a distribution server that stores distribution data. At this time, the playback device uses identification information for uniquely identifying the inserted SD memory card (for example, an identification number unique to each SD memory card, more specifically, for example, a serial number of the SD memory card). And the read identification information is transmitted to the distribution server together with the distribution request.
  • identification information for uniquely identifying the inserted SD memory card for example, an identification number unique to each SD memory card, more specifically, for example, a serial number of the SD memory card.
  • the identification information for uniquely identifying the SD memory card corresponds to, for example, the volume ID described above.
  • necessary data for example, a video stream, an audio stream, etc.
  • a key for example, a title key
  • the distribution server holds a secret key and is configured so that different public key information can be dynamically generated for each unique identification number of the semiconductor memory card.
  • the distribution server is configured to be able to encrypt the key (title key) necessary for decrypting the encrypted data (that is, configured to generate an encrypted title key). ).
  • the generated public key information includes, for example, information corresponding to the above-described MKB, volume ID, and encrypted title key. If the combination of the identification number unique to the semiconductor memory, the public key body included in the public key information described later, and the device key recorded in advance on the playback device is correct, the encrypted data is, for example, a key necessary for decryption (for example, Based on the device key, MKB, and the identification number unique to the semiconductor memory, a title key obtained by decrypting the encrypted title key) is obtained, and using the obtained key (title key) necessary for decryption, Encrypted data can be decrypted.
  • a key necessary for decryption for example, Based on the device key, MKB, and the identification number unique to the semiconductor memory, a title key obtained by decrypting the encrypted title key
  • the playback device records the received public key information and distribution data in the recording area of the semiconductor memory card inserted in the slot.
  • the received public key information includes, for example, a public key body (for example, the above-mentioned MKB and encrypted title key), signature information, a unique identification number of the semiconductor memory card, and a device list indicating information on devices to be invalidated. Yes.
  • the signature information includes, for example, a hash value of public key information.
  • This may be a device that is likely to be played illegally, such as a device key pre-recorded on the playback device, an identification number of the playback device, or an identification number of a decoder included in the playback device, or This is information for uniquely identifying a function (program).
  • the following describes the playback of encrypted data among the distribution data recorded in the recording area of the semiconductor memory card.
  • (1) Check whether the identification information unique to the semiconductor memory included in the public key information matches the unique identification number stored in advance in the semiconductor memory card (2) Calculate in the playback device Check that the hash value of the public key information and the hash value included in the signature information match (3) Based on the information indicated in the device list included in the public key information, the playback device that performs playback may perform unauthorized playback. Check whether it is possible (for example, check whether the device key shown in the device list included in the public key information matches the device key stored in advance in the playback device) To do. These checks may be performed in any order.
  • the identification information unique to the semiconductor memory included in the public key information does not match the unique identification number stored in advance in the semiconductor memory, and is calculated by the playback device. If the hash value of the key information and the hash value included in the signature information do not match or if it is determined that there is a possibility that the playback device that performs playback may be played back illegally, the playback device Controls that the encrypted data is not decrypted.
  • the hash value and signature of the public key information calculated in the playback device in which the unique identification information of the semiconductor memory card included in the public key information matches the unique identification number stored in advance in the semiconductor memory card. If it is determined that the hash values included in the information match and the playback device that performs playback is not likely to be played back illegally, the identification number unique to the semiconductor memory, the public key body included in the public key information, And the device key pre-recorded on the playback device is determined to be correct, and is obtained by decrypting the encrypted title key based on the key necessary for decryption (device key, MKB and identification number unique to the semiconductor memory) The encrypted data is decrypted using the title key.
  • the video decoder decrypts the video stream by using the above-described key necessary for decryption (the title key obtained by decrypting the encrypted title key).
  • the audio decoder decodes (decodes) the audio stream using the key necessary for the above-described decryption.
  • the present invention relates to a technique for suppressing flickering of an output video in a playback device that plays back a stereoscopic video, and is particularly applicable to a playback device having a switching function between a planar video playback mode and a stereoscopic video playback mode. .
  • BD-ROM drive 4 Video decoder 5 Left-eye video plane 6 Right-eye video plane 7 Image memory 8 Image decoder 9 Left-eye graphics plane 10 Right-eye graphics plane 15 BD-J module 20 Plane combiner 22 Rendering engine 28 Left-eye back Ground plane 29 Background plane for right eye 30 Subtitle plane for left eye 31 Subtitle plane for right eye 100 BD-ROM 200 Playback device 300 Remote control 400 Display 500 Shutter / polarized glasses

Landscapes

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

Abstract

　平面的な映像再生モードと立体的な映像再生モードの切替機能を持つ再生装置において、切替時に左目用画像と右目用画像の不整合が発生する。具体的には、平面的な映像再生モードから立体的な映像再生モードの切替える際に、Graphics#drawImageの描画要求を無効化して、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーしてから、グラフィクスプレーンの出力系統の切替えを行い、StereoGraphics#drawImageの描画要求の禁止を解除することで、左目用画像と右目用画像の不整合を防止する。

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 (14)

  1. 　再生装置であって、
    　バイトコードアプリケーションを動作させるプラットフォーム部と、
    　左目用グラフィクスプレーンと、右目用グラフィクスプレーンとを備え、
    　前記プラットフォーム部は、バイトコードアプリケーションからのグラフィクス描画要求を受け付けてグラフィクス描画を実行する描画部を含み、
    　前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがあり、
    　前記グラフィクス描画要求には、2Dグラフィクスの描画要求と、3Dグラフィクスの描画要求とがあり、
    　前記コンフィグレーションのうち、１プレーン構成から、２プレーン構成への切り替えは、これまでにバイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を無効化する処理と、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーする処理とを含み、当該コピーがなされた後に、描画部は3Dグラフィクスの描画要求を受け入れる
    　ことを特徴とする再生装置。
  2. 　前記再生装置は、
    　前記記録媒体に記録されている立体視ビデオストリームをデコードするデコーダと、
    　立体視ビデオストリームをデコードすることにより得られる左目用ピクチャデータを格納する左目用ビデオプレーンと、
    　立体視ビデオストリームをデコードすることにより得られる右目用ピクチャデータを格納する右目用ビデオプレーンと、
    　左目の出力系統の合成及び右目の出力系統の合成を実行する合成部とを備え、
    　前記左目の出力系統の合成とは、
    　左目用グラフィクスプレーンの格納内容と、左目用ビデオプレーンの格納内容とを合成するものであり、

    　前記右目の出力系統の合成とは、
    　左目用グラフィクスプレーン及び右目用グラフィクスプレーンのどちらかの格納内容を、右目用ビデオプレーンの格納内容と合成するものであり、
    　前記合成部は、前記１プレーン構成から２プレーン構成への切り替え時において、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーした後に、右目用出力系統における右目用グラフィクスプレーンの格納内容を、右目用ビデオプレーンの格納内容に合成する処理を開始し、
    　前記描画部による3Dグラフィクス描画の要求の受け入れは、右目用グラフィクスプレーンの格納内容と、右目用ビデオプレーンの格納内容との合成後になされる
    　ことを特徴とする請求項１記載の再生装置。
  3. 　前記コンフィグレーションのうち、２プレーン構成から、１プレーン構成への切り替えは、
    　3Dグラフィクス描画の要求を禁止する処理と、左目用グラフィクスプレーンの格納内容を、右目用ビデオプレーンの格納内容に合成する処理と、バイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を受け入れる処理とから構成される
    　ことを特徴とする請求項２記載の再生装置。
  4. 前記１プレーン構成から２プレーン構成への切り替え、及び、２プレーン構成から１プレーン構成への切り替えは、バイトコードアプリケーショによるコンフィグレーション設定要求の発行でなされ、
    　前記無効化の対象となる2Dグラフィクス描画要求は、前記コンフィグレーション設定要求に後続する2Dグラフィクス描画要求である
    　ことを特徴とする請求項３記載の再生装置。
  5. 　前記コンフィグレーション設定要求は、コンフィグレーション設定APIをコールするコードであり、コンフィグレーション設定APIのコールは、左目用グラフィクスプレーン及び右目用グラフィクスプレーンを１プレーン構成とするか、２プレーン構成とするかを引数で指定することができ、
    　前記2Dグラフィクスの描画要求とは、2Dグラフィクスの描画APIをコールするコードであり、
    　前記2Dグラフィクスの描画要求の無効化は、コンフィグレーション設定APIのコール後になされた2Dグラフィクスの描画APIのコールを例外終了させることでなされる
    　ことを特徴とする請求項４記載の再生装置。
  6. 　前記プラットフォーム部は、バイトコードアプリケーション及び描画部をマルチスレッドとして処理するものであり、
    　前記2Dグラフィクスの描画要求及びコンフィグレーション設定要求は、APIをコールするコードをスレッド間通信によって、バイトコードアプリケーションからグラフィクス描画モジュールに引き渡すことでなされ、
    　前記2Dグラフィクス描画要求の無効化は、スレッド間通信の途中で、2Dグラフィクス描画の描画要求を消去することでなされる
    　ことを特徴とする請求項５記載の再生装置。
  7. 　前記2Dグラフィクス描画描画APIは、java.awt.Graphics#drawImage APIであり、
    　前記コンフィグレーション設定APIは、HAViグラフィクスデバイスにおけるHAViスクリーンコンフィグレーション設定APIである
    　ことを特徴とする請求項５記載の再生装置。
  8. 　前記描画部は、左目用グラフィクスプレーンと右目用グラフィクスプレーンに同時に描画を行う、3D再生モード専用の左右プレーン描画モジュールを含み、
    　前記3Dグラフィクス描画の要求受け入れは、3D再生モード専用の左右プレーン描画モジュールを起動することでなされ、
    　前記描画部による3Dグラフィクス描画の要求禁止は、
    　当該3D再生モード専用の左右プレーン描画モジュールを終了させることでなされる
    　ことを特徴とする請求項３記載の再生装置。　
  9. 記録媒体には、複数のコンテンツが記録されており、
    　前記プラットフォーム部は、
    　複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに対応するアプリケーション管理テーブルに従ってバイトコードアプリケーションを起動して実行し、
    　前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションは、
    　コンテンツ再生の開始時に、動作モードオブジェクト内のコンフィグレーション情報に従って設定される
    　ことを特徴とする請求項１記載の再生装置。
  10. 前記コンフィグレーション情報は、解像度コードを含み、解像度コードは、縦画素数及び横画素数を示す
    　ことを特徴とする請求項９記載の再生装置。
  11. 　左目用グラフィクスプレーンと、右目用グラフィクスプレーンを備える再生装置に組み込むことができる集積回路であって、
    　バイトコードアプリケーションを動作させるプラットフォーム部を備え、
    　前記プラットフォーム部は、バイトコードアプリケーションからのグラフィクス描画要求を受け付けてグラフィクス描画を実行する描画部を含み、
    　前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがあり、
    　前記グラフィクス描画要求には、2Dグラフィクスの描画要求と、3Dグラフィクスの描画要求とがあり、
    　前記コンフィグレーションのうち、１プレーン構成から、２プレーン構成への切り替えは、これまでにバイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を無効化する処理と、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーする処理とを含み、当該コピーがなされた後に、描画部は3Dグラフィクスの描画要求を受け入れる
    　ことを特徴とする集積回路。
  12. 　バイトコードアプリケーションを動作させるプラットフォーム部と、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとを備えるコンピュータでの再生方法であって、
    　前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがあり、
    　前記グラフィクス描画要求には、2Dグラフィクスの描画要求と、3Dグラフィクスの描画要求とがあり、
    　前記コンフィグレーションのうち、１プレーン構成から、２プレーン構成への切り替えがバイトコードアプリケーションから要求された場合、これまでにバイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を無効化する処理と、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーする処理とを実行し、当該コピーがなされた後に、3Dグラフィクスの描画要求を受け入れる
    　ことを特徴とする再生方法。
  13. 　バイトコードアプリケーションを動作させるプラットフォーム部と、左目用グラフィクスプレーンと、右目用グラフィクスプレーンとを備えるコンピュータ上で動作するプログラムであって、
    　前記左目用グラフィクスプレーン及び右目用グラフィクスプレーンのコンフィグレーションには、平面視再生時及び立体視再生時において、グラフィクス描画に左目用グラフィクスプレーンのみを使用する１プレーン構成と、立体視再生時において、グラフィクス描画に左目用グラフィクスプレーン及び右目用グラフィクスプレーンを使用する２プレーン構成とがあり、
    　前記グラフィクス描画要求には、2Dグラフィクスの描画要求と、3Dグラフィクスの描画要求とがあり、
    　前記コンフィグレーションのうち、１プレーン構成から、２プレーン構成への切り替えがバイトコードアプリケーションから要求された場合、前記プログラムは、これまでにバイトコードアプリケーションによってなされた2Dグラフィクスの描画要求を無効化する処理と、左目用グラフィクスプレーンの格納内容を右目用グラフィクスプレーンにコピーする処理とをコンピュータに実行させ、当該コピーがなされた後に、3Dグラフィクスの描画要求を受け入れる
    　ことを特徴とするプログラム。
  14. 　請求項１３記載のプログラムが記録されていることを特徴とするコンピュータ読み取り可能な記録媒体。
PCT/JP2010/005804 2009-10-02 2010-09-27 立体視映像を再生することができる再生装置、集積回路、再生方法、プログラム WO2011039990A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2011534065A JP5097297B2 (ja) 2009-10-02 2010-09-27 再生装置、再生方法、再生プログラム
CN201080043782.7A CN102577409B (zh) 2009-10-02 2010-09-27 能再现立体视觉影像的再现装置、集成电路、再现方法
US13/394,837 US8558871B2 (en) 2009-10-02 2010-09-27 Playback device that can play stereoscopic video, integrated circuit, playback method and program
EP10820112.0A EP2485497B1 (en) 2009-10-02 2010-09-27 Playback device that can play stereoscopic video, integrated circuit, playback method and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-230394 2009-10-02
JP2009230394 2009-10-02

Publications (1)

Publication Number Publication Date
WO2011039990A1 true WO2011039990A1 (ja) 2011-04-07

Family

ID=43825838

Family Applications (1)

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

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
EP2400772B1 (en) * 2009-02-17 2016-04-13 Panasonic Intellectual Property Management Co., Ltd. Playback device, playback method, and program
JP4875127B2 (ja) * 2009-09-28 2012-02-15 パナソニック株式会社 三次元画像処理装置
CN102971770B (zh) * 2011-03-31 2016-02-10 松下电器产业株式会社 进行全周围立体图像的描绘的图像描绘装置、图像描绘方法
US9055277B2 (en) 2011-03-31 2015-06-09 Panasonic Intellectual Property Management Co., Ltd. Image rendering device, image rendering method, and image rendering program for rendering stereoscopic images
KR101706606B1 (ko) * 2012-05-31 2017-02-15 (주)재플 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
JP6346674B2 (ja) * 2014-11-21 2018-06-20 富士フイルム株式会社 時系列データ表示制御装置、その作動方法及びプログラム、並びにシステム
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 (4)

* 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
JP4266774B2 (ja) 2003-10-29 2009-05-20 シャープ株式会社 立体画像表示装置及び立体画像表示方法
WO2010095403A1 (ja) * 2009-02-17 2010-08-26 パナソニック株式会社 再生装置、再生方法、プログラム

Family Cites Families (22)

* 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
EP1501316A4 (en) 2002-04-25 2009-01-21 Sharp Kk METHOD FOR GENERATING MULTIMEDIA INFORMATION, AND DEVICE FOR REPRODUCING MULTIMEDIA INFORMATION
JP2004127255A (ja) * 2002-08-02 2004-04-22 Renesas Technology Corp 情報処理装置
JP4251907B2 (ja) * 2003-04-17 2009-04-08 シャープ株式会社 画像データ作成装置
JP3746506B2 (ja) * 2004-03-08 2006-02-15 一成 江良 立体視化パラメータ埋込装置及び立体視画像再生装置
JP2005321953A (ja) 2004-05-07 2005-11-17 Hitachi Ltd ストレージ制御装置、その動作プログラム、及びアクセス制御方法
CN101414473B (zh) 2004-06-18 2013-01-23 松下电器产业株式会社 再现装置、程序、再现方法
US20080010664A1 (en) 2004-08-30 2008-01-10 Maurizio Pelizza Method and System for Providing Interactive Services in Digital Television
US20080201695A1 (en) 2007-02-16 2008-08-21 Qing Zhou Computer graphics rendering
JP4689639B2 (ja) 2007-04-25 2011-05-25 キヤノン株式会社 画像処理システム
JP4854582B2 (ja) 2007-04-25 2012-01-18 キヤノン株式会社 画像処理装置、画像処理方法
EP2362672B1 (en) * 2008-12-01 2016-04-20 Sharp Kabushiki Kaisha Contents reproduction device, reproduction method, program and recording medium
JP4962817B2 (ja) * 2009-04-03 2012-06-27 ソニー株式会社 情報処理装置、情報処理方法、及び、プログラム
US20110012993A1 (en) * 2009-07-14 2011-01-20 Panasonic Corporation Image reproducing apparatus
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 (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4266774B2 (ja) 2003-10-29 2009-05-20 シャープ株式会社 立体画像表示装置及び立体画像表示方法
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
WO2010095403A1 (ja) * 2009-02-17 2010-08-26 パナソニック株式会社 再生装置、再生方法、プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2485497A4

Also Published As

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

Similar Documents

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

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080043782.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10820112

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13394837

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2011534065

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2010820112

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20127007836

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE