JP2012134994A - Information processor, information processing method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To adequately reproduce a 3D image content.SOLUTION: Device planes for storing graphics, video, or background images are storage areas in which an L-area for storing an image for L and an R-area for storing an image for R are arranged side by side. A configuration of the device planes is defined for the whole device planes which are the storage areas of images of two planes and include resolutions of the images. In changing the configuration, the resolutions of the graphics, video, and background images are made the same. This technique can be applied to a BD player and the like for reproducing a BD.

Description

  The present technology relates to an information processing device, an information processing method, and a program, and in particular, an information processing device and an information processing method capable of appropriately reproducing content of a 3D (Dimension) image from a recording medium, for example. And related to the program.

  For example, as a content such as a movie, a content of a two-dimensional (2D) image is mainstream, but recently, a content of a three-dimensional (3D) image (graphic) capable of stereoscopic viewing has attracted attention.

  There are various methods for displaying 3D images (hereinafter, also referred to as stereo images). Regardless of which method is used, the amount of 3D images is greater than the amount of 2D images. Become big.

  Also, high-resolution image content such as movies may have a large capacity, and in order to record such a large-capacity image content as a 3D image with a large amount of data, a large-capacity recording medium is required.

  Examples of such a large-capacity recording medium include a Blu-Ray® Disc (hereinafter also referred to as BD) such as a BD (Blu-Ray®) -ROM (Read Only Memory).

  BD can handle BD-J (BD Java (registered trademark)), and can provide advanced interactive functions with BD-J (Patent Document 1).

International Publication No. 2005/052940

  By the way, in the current BD standard, how to record and play back the content of the 3D image on the BD is not stipulated.

  However, if the method of recording and playing back 3D image content is left to the author who authors the 3D image content, the 3D image content may not be played back properly.

  The present technology has been made in view of such a situation, and makes it possible to appropriately reproduce 3D image content from a recording medium such as a BD.

  An information processing apparatus or program according to one aspect of the present technology is a device plane that stores graphics, video, or background images, and a storage area for an image for one surface that stores an image for the left eye. A storage area for two planes of an area and an R area that is a storage area for one plane storing an image for the right eye, and the configuration of the device plane is an image for the two planes Information processing that is defined for the entire device plane, which is a storage area, and includes image resolution, and in the configuration change, the graphics, video, and background images have the same resolution. A program for causing a computer to function as a device or an information processing device.

  In the information processing method according to one aspect of the present technology, a device plane that stores graphics, video, or background images includes an L area that is a storage area for an image that stores an image for the left eye, and a right area. An image storage area for two faces, an R area that is an image storage area for one face for storing an eye image, and the configuration of the device plane is a storage area for the two face images. The information processing method is defined for an entire device plane and includes an image resolution, and the graphics, video, and background images have the same resolution when the configuration is changed.

  In one aspect of the present technology, a device plane that stores graphics, video, or background images includes an L region that is a storage region for an image that stores an image for the left eye, and an image for the right eye. And an R area that is an image storage area for one surface that stores the image, and the device plane configuration is the device that is an image storage area for the two surfaces Defined for the entire plane and includes the resolution of the image. In the configuration change, the resolutions of the graphics, video, and background images are set to the same resolution.

  The information processing apparatus may be an independent apparatus, or may be an internal block constituting one apparatus.

  The program can be provided by being transmitted via a transmission medium or by being recorded on a recording medium.

  According to the present technology, it is possible to appropriately reproduce 3D image content.

It is a figure explaining the outline | summary of a BDMV format. It is a figure explaining the management structure of a BD file. FIG. 3 is a block diagram illustrating a hardware configuration example of a BD player. It is a figure explaining the outline | summary of the process of 3D image by the 3D corresponding | compatible player. FIG. 3 is a diagram for describing drawing of a graphics 3D image on a graphics plane 11 by a BD-J application. 3 is a diagram illustrating a graphics mode in which a BD-J application reproduces a graphics image by drawing a graphics 3D image on the graphics plane 11. FIG. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure which shows the video mode which reproduces | regenerates the image of a video which is one of the configurations. It is a figure which shows the background mode which reproduces | regenerates the background image which is one of the configurations. It is a figure which shows the relationship between the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14 which are device planes. It is a figure which shows the image frame (Resolution) and color depth (color-depth) which are one of the configurations. It is a figure explaining the method of drawing a 3D image with a 2nd drawing system in the case of mismatching of a 3D image. It is a figure explaining a device plane. It is a figure which shows the bit field provided in order to designate a configuration in the file of a BD-J object. It is a figure which shows the default prescription | regulation value of initial_video_mode, initial_graphics_mode, and initial_background_mode. It is a figure which shows the combination of the resolution (image frame) of Video + PG, BD-J graphics, and background of reproduction | regeneration other than KEEP_RESOLUTION reproduction | regeneration. It is a figure which shows the combination of the resolution (image frame) of Video + PG, BD-J graphics, and background of reproduction | regeneration other than KEEP_RESOLUTION reproduction | regeneration. It is a figure which shows the example of a process of a configuration change. It is a figure which shows the predetermined | prescribed initial value of graphics mode and background mode. It is a figure which shows the graphics reproduced when reproducing | regenerating a 3D image (stereo image) of 1920x2160 pixel, and a background mode. It is a figure explaining the change of the resolution (image frame) as a configuration by the API call by the BD-J application. It is a figure explaining change of graphics modes. It is a figure which shows the change of the graphics mode from stereo graphics mode to offset graphics mode. It is a figure explaining change of background mode. It is a figure explaining change of a video mode. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure which shows PG playback mode and TextST playback mode which can be selected in each video mode. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure explaining the process of the 3D corresponding player about PG. FIG. 4 is a diagram for describing switching between 3D image playback and 2D image playback in a 3D-compatible player. It is a figure explaining the setting of the position and size of the video by the author, and the correction of the position and size of the video by the 3D-compatible player. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure which shows the graphics plane 11 of 1920x2160 pixel. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. 14 is a flowchart for describing graphics processing by a 3D-compatible player. 14 is a flowchart for describing graphics processing by a 3D-compatible player. 14 is a flowchart for describing graphics processing by a 3D-compatible player. 3 is a diagram illustrating an example of a GUI drawn on a graphics plane 11. FIG. It is a figure which shows the 1st focus system and the 2nd focus system. It is a flowchart explaining the management of the focus of a 3D-compatible player. It is a figure which shows the position on the display screen where the 3D image of a cursor can be seen, and the position of the cursor on the graphics plane. It is a figure explaining the consistency with the image for left eyes and the image for right eyes of graphics. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure which shows the image which straddles L graphics plane 11L and R graphics plane 11R. It is a figure which shows drawing of the image for left eyes for animation, and drawing of the image for right eyes for animation. It is a block diagram which shows the functional structural example of a 3D corresponding | compatible player. It is a figure which shows the definition of extended API of Image Frame Accurate Animation. It is a figure which shows the definition of the extended API of Sync Frame Accurate Animation. It is a figure which shows the sample code of Image Frame Accurate Animation. It is a figure which shows the sample code of Image Frame Accurate Animation. It is a figure which shows the sample code of Sync Frame Accurate Animation. It is a figure which shows the sample code of Sync Frame Accurate Animation.

  Hereinafter, a case where the embodiment of the present technology is applied to a BD will be described as an example.

  [BD management structure]

  First, regarding the current BD, content recorded on a BD-ROM, which is a read-only BD, as defined in "Blu-ray Disc Read-Only Format Ver1.0 part3 Audio Visual Specifications", that is, AV ( A management structure (hereinafter also referred to as BDMV format) of audio / video data and the like will be described.

  For example, a bit stream that is encoded by an encoding method such as MPEG (Moving Picture Experts Group) video or MPEG audio and multiplexed according to the MPEG2 system is called a clip AV stream (or AV stream). The clip AV stream is recorded on the BD as a file by a file system defined by “Blu-ray Disc Read-Only Format part 2”, which is one of the standards related to BD. A clip AV stream file is called a clip AV stream file (or AV stream file).

  The clip AV stream file is a management unit on the file system, and information necessary for reproducing the clip AV stream file (the clip AV stream) is recorded on the BD as a database. This database is defined in “Blu-ray Disc Read-Only Format part 3” which is one of the BD standards.

  FIG. 1 is a diagram for explaining the outline of the BDMV format.

  The BDMV format is composed of four layers.

  The lowest layer is a layer to which the clip AV stream belongs, and is hereinafter also referred to as a clip layer as appropriate.

  The layer one layer above the clip layer is a layer to which a play list (Movie PlayList) belongs for designating a playback position for the clip AV stream, and is also referred to as a play list layer hereinafter.

  The layer immediately above the playlist layer is a layer to which a movie object (Movie Object) composed of commands for designating the playback order and the like belongs to the playlist, and is also referred to as an object layer hereinafter.

  The layer (uppermost layer) one above the object layer is a layer to which an index table for managing titles stored in the BD belongs, and is hereinafter also referred to as an index layer.

  The clip layer, playlist layer, object layer, and index layer will be further described.

  A clip AV stream, clip information (Clip Information), and the like belong to the clip layer.

  The clip AV stream is a stream in which video data, audio data, and the like as content data are in the form of TS (MPEG2 TS (Transport Stream)).

  Clip information (Clip Information) is information related to the clip AV stream, and is recorded on the BD as a file.

  Note that the clip AV stream includes a graphics stream such as subtitles and menus as necessary.

  The subtitle (graphics) stream is called a presentation graphics (PG (Presentation Graphics)) stream, and the menu (graphics) stream is called an interactive graphics (IG (Interactive Graphics)) stream.

  A set of a clip AV stream file and a file (clip information file) of corresponding clip information (clip information related to the clip AV stream of the clip AV stream file) is called a clip.

  A clip is one object composed of a clip AV stream and clip information.

  A plurality of positions including the first and last positions (time) when the content corresponding to the clip AV stream constituting the clip is expanded on the time axis are set as access points. An access point is mainly designated by a time-stamp and a higher layer playlist (PlayList).

  The clip information constituting the clip includes the address (logical address) of the position of the clip AV stream represented by the access point specified by the time stamp in the playlist.

  A playlist (Movie PlayList) belongs to the playlist layer.

  The playlist is composed of a play item (PlayItem) including an AV stream file to be played, a playback start point (IN point) for specifying a playback position of the AV stream file, and a playback end point (OUT point). The

  Therefore, the playlist is composed of a set of play items.

  Here, the reproduction of the play item means reproduction of a section of the clip AV stream specified by the IN point and the OUT point included in the play item.

  Movie objects (Movie Objects) and BD-J objects (Blu-ray Disc Java (registered trademark) Objects) belong to the object layer.

  The movie object includes terminal information that links the HDMV (High Definition Movie) navigation command program (navigation command) and the movie object.

  The navigation command is a command for controlling play list reproduction. The terminal information includes information for permitting a user's interactive operation on a BD player that plays BD. In the BD player, user operations such as menu call and title search are controlled based on terminal information.

  The BD-J object is a Java (registered trademark) program, and can provide a user with a more advanced (sophisticated) interactive function than a navigation command.

  An index table (Index table) belongs to the index layer.

  The index table is a top-level table that defines the title of the BD-ROM disc.

  An entry (column) in the index table corresponds to a title, and each entry is linked to an object (movie object, BD-J object) of a title (HDMV title, BD-J title) corresponding to the entry. .

  FIG. 2 is a diagram for explaining a BD file management structure defined by “Blu-ray Disc Read-Only Format part 3”.

  In BD, files are managed hierarchically by a directory structure.

  Here, in FIG. 2, a file under a directory (including a directory) means a file immediately under the directory, and a file included in the directory is a file directly under the directory or the directory. Means a file under a so-called subdirectory.

  The top-level directory of BD is a root directory.

  A directory “BDMV” and a directory “CERTIFICATE” exist immediately below the root directory.

  The directory “CERTIFICATE” stores copyright information (file).

  The directory “BDMV” stores files in the BDMV format described in FIG.

  Directly under the directory “BDMV”, two files “index.bdmv” and “MovieObject.bdmv” are stored. Note that files (except for the directory) other than the files “index.bdmv” and “MovieObject.bdmv” cannot be stored immediately under the directory “BDMV”.

  The file “index.bdmv” includes the index table described with reference to FIG. 1 as information relating to a menu for playing a BD.

  The BD player, for example, displays an initial menu (screen) including items such as playing all BD contents, playing only specific chapters, repeatedly playing, displaying a predetermined menu, etc. Play based on "index.bdmv".

  In addition, a movie object (Movie Object) that is executed when each item is selected can be set in the file “index.bdmv”. When one item is selected from the initial menu screen by the user, the BD The player executes the Movie Object command set in the file “index.bdmv”.

  The file “MovieObject.bdmv” is a file including information on Movie Object. The Movie Object includes a command for controlling the playback of the PlayList recorded on the BD. For example, the BD player records on the BD by selecting and executing one of the MovieObjects recorded on the BD. Play the content (title) that has been played.

  Directly under the directory “BDMV”, directories “PLAYLIST”, “CLIPINF”, “STREAM”, “AUXDATA”, “META”, “BDJO”, “JAR”, and “BACKUP” are provided.

  The directory “PLAYLIST” stores a playlist database. That is, a playlist file “xxxxx.mpls” is stored in the directory “PLAYLIST”. As the file name of the file “xxxxx.mpls”, a file name composed of a 5-digit number “xxxxx” and an extension “mpls” is used.

  The directory “CLIPINF” stores a database of clips. That is, the clip information file “xxxxx.clpi” for each of the clip AV stream files is stored in the directory CLIPINF ”. The file name of the clip information file“ xxxxx.clpi ”is a 5-digit number“ xxxxx ”. The file name consisting of the extension “clpi” is used.

  The directory “STREAM” stores a clip AV stream file “xxxxx.m2ts”. TS is stored in the clip AV stream file “xxxxx.m2ts”. As the file name of the clip AV stream file “xxxxx.m2ts”, a file name consisting of a 5-digit number “xxxxx” and an extension “m2ts” is used.

  As the file names of the clip information file “xxxxx.clpi” and the clip AV stream file “xxxxx.m2ts” constituting a certain clip, matching file names are used except for the extension. Thereby, the clip information file “xxxxx.clpi” and the clip AV stream file “xxxxx.m2ts” constituting a certain clip can be easily specified.

  The directory “AUXDATA” stores a sound file, a font file, a font index file, a bitmap file, and the like used for displaying a menu.

  In FIG. 2, a file “sound.bdmv” and a file with an extension “otf” are stored in the directory “AUXDATA”.

  The file “sound.bdmv” stores predetermined sound data (audio data). As the file name of the file “sound.bdmv”, “sound.bdmv” is fixedly used.

  A file with the extension “otf” stores font data used in subtitle display, BD-J object (application), and the like. A 5-digit number is used for a portion other than the extension in the file name of the file with the extension “otf”.

  The directory “META” stores metadata files. The directory “BDJO” and the directory “JAR” store files of BD-J objects. The directory “BACKUP” stores backups of files recorded on the BD.

  [BD player hardware configuration example]

  FIG. 3 is a block diagram illustrating a hardware configuration example of a BD player that plays BDs.

  The BD player shown in FIG. 3 can play back a BD on which 3D image content is recorded.

  The BD player includes a processor (computer) such as a CPU (Central Processing Unit) 102. An input / output interface 110 is connected to the CPU 102 via the bus 101.

  The CPU 102 executes a program stored in a ROM (Read Only Memory) 103 according to a command input by the user by operating the input unit 107 or the like via the input / output interface 110. . Alternatively, the CPU 102 loads a program recorded on the hard disk 105 or the disk 100 mounted in the drive 109 to a RAM (Random Access Memory) 104 and executes it.

  Thereby, the CPU 102 performs various processes described later. Then, the CPU 102 outputs the processing result as necessary, for example, via the input / output interface 110, from the output unit 106, transmitted from the communication unit 108, and further recorded in the hard disk 105.

  The input unit 107 includes a keyboard, a mouse, a microphone, and the like. The output unit 106 includes an LCD (Liquid Crystal Display), a speaker, and the like. The communication unit 108 includes a network card or the like.

  Here, the program executed by the CPU 102 can be recorded in advance on a hard disk 105 or a ROM 103 as a recording medium built in the BD player.

  Alternatively, the program can be stored (recorded) in a removable recording medium such as the disk 100. Such a removable recording medium can be provided as so-called package software. Here, examples of the removable recording medium include a flexible disk, a CD-ROM (Compact Disc Read Only Memory), an MO (Magneto Optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, and a semiconductor memory.

  The program can be downloaded from the removable recording medium as described above to the BD player, downloaded to the BD player via the communication network or the broadcast network, and installed in the built-in hard disk 105. That is, for example, the program is wirelessly transferred from a download site to a BD player via a digital satellite broadcasting artificial satellite, or wired to a BD player via a network such as a LAN (Local Area Network) or the Internet. Can be transferred.

  In FIG. 3, a disc 100 is, for example, a BD, in which 3D image content is recorded so as to maintain compatibility with a BD that is played back by a legacy player.

  Therefore, the disc 100 can be played back by a legacy player, and can also be played back by the BD player of FIG. 3 which is a BD player (hereinafter also referred to as a 3D-compatible player) capable of playing back 3D image content. it can.

  Here, the legacy player is a BD player that can reproduce a BD on which a 2D image content is recorded, but cannot reproduce a 3D image content.

  The legacy player can play back 2D image content from the disc 100, but cannot play back 3D image content.

  On the other hand, in the BD player of FIG. 3 which is a 3D-compatible player, 2D image content can be reproduced from the disc 100, and 3D image content can also be reproduced.

  In the BD player of FIG. 3, when the BD disc 100 is loaded in the drive 109, the CPU 102 controls the drive 109 to reproduce the disc 100.

  [Description of BD-J application]

  On the disc 100 (FIG. 3), a BD-J application (BD-J title) (BD-J object) is recorded as one of the contents of the 3D image.

  In the BD player of FIG. 3 which is a 3D-compatible player, the CPU 102 executes a Java (registered trademark) virtual machine, and a BD-J application is executed on the Java (registered trademark) virtual machine.

  FIG. 4 is a diagram illustrating an outline of 3D image processing (outline of BD-J stereoscopic graphics) by a 3D-compatible player.

  The 3D-compatible player draws a 3D image on the logical plane 10, the PG plane 12, or the video plane 13. Note that the entities of the logical plane 10, the PG plane 12, and the video plane 13 are, for example, a partial storage area of the RAM 104 in FIG.

  The 3D image drawn by the 3D-compatible player includes BD-J graphics, PG (Presentation Graphics), TextST (Text subtitle), video, and background defined in the BD standard.

  Here, in FIG. 4, graphics 3D images (stereo graphics source) are a left-eye image (L (Left) -view) that is an image observed by the left eye and an image that is observed by the right eye. It consists of an image for the right eye (R (Right) -view).

  Similarly, a PG 3D image (stereo PG source), a video 3D image (stereo video source), and a background 3D image (stereo background source) are composed of a left-eye image and a right-eye image. The

  Note that the left-eye image and the right-eye image constituting the video 3D image or the like can be encoded by, for example, H.264 AVC (Advanced Video Coding) / MVC (Multi-view Video coding) or the like. it can.

  Here, in H.264 AVC / MVC, an image stream called a base view (Base View) and an image stream called a dependent view (Dependent View) are defined.

  The base view is not allowed to use predictive coding with another stream as a reference image, but the dependent view is allowed to use predictive coding with the base view as a reference image. Of the left-eye image and the right-eye image, for example, the left-eye image can be a base view, and the right-eye image can be a dependent view.

  The 3D-compatible player draws the 3D image drawn on the logical plane 10 on the graphics plane 11 or the background plane 14.

  The graphics plane 11 includes an L graphics plane (L (Left) graphics plane) 11L that stores an image for the left eye, and an R graphics plane (R (Right) graphics plane) 11R that stores an image for the right eye. .

  The left-eye image constituting the graphics 3D image drawn on the logical plane 10 is drawn on the L graphics plane 11L, and the right-eye image is drawn on the R graphics plane 11R.

  Here, the L graphics plane 11L is a storage area (L area) of an image for one surface that stores an L (Left) image (left eye image) observed by the left eye. The R graphics plane 11 </ b> R is a storage area (R area) of an image for one surface that stores an R (Right) image (right eye image) observed with the right eye.

  The L graphics plane 11L and the R graphics plane 11R, that is, the entity of the graphics plane 11 is a partial storage area of the RAM 104 in FIG.

  The same applies to the PG plane 12, the video plane 13, and the background plane 14.

  The PG plane 12 includes an L-PG plane (L (Left) PG plane) 12L that stores an image for the left eye, and an R-PG plane (R (Right) PG plane) 12R that stores an image for the right eye. Is done.

  The 3D-compatible player draws the left-eye image constituting the PG 3D image on the L-PG plane 12L, and draws the right-eye image on the R-PG plane 12R.

  The video plane 13 includes an L video plane (L (Left) video plane) 13L that stores an image for the left eye, and an R video plane (R (Right) video plane) 13R that stores an image for the right eye. .

  The 3D-compatible player draws the left-eye image constituting the video 3D image on the L video plane 13L, and draws the right-eye image on the R video plane 13R.

  The background plane 14 includes an L background plane (L (Left) background plane) 14L that stores an image for the left eye, and an R background plane (R (Right) background plane) 14R that stores an image for the right eye. Composed.

  The image for the left eye constituting the background 3D image drawn on the logical plane 10 is drawn on the L background plane 14L, and the image for the right eye is drawn on the R background plane 14R.

  The left-eye image and right-eye image drawn (stored) on the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14 are supplied to the mixer 15.

  The mixer 15 is a graphics left-eye image from the graphics plane 11, a PG left-eye image from the PG plane 12, a video left-eye image from the video plane 13, and a background from the background plane 14. The left-eye image is blended (mixed) (synthesized), and the left-eye image as a result of the synthesis is output.

  Also, the mixer 15 is a graphics right-eye image from the graphics plane 11, a PG right-eye image from the PG plane 12, a video right-eye image from the video plane 13, and a background plane 14. The background image for the right eye is blended and synthesized, and the image for the right eye that is the result of the synthesis is output.

  The left-eye image output from the mixer 15 is supplied to a display (not shown) as a left display output (L (Left) display output). The right-eye image output from the mixer 15 is supplied to a display (not shown) as a right display output (R (Right) display output).

  On a display (not shown), the left-eye image and the right-eye image from the mixer 15 are displayed alternately or simultaneously, thereby displaying a 3D image.

  The BD-J application can draw an image on the graphics plane 11 and the background plane 14 among the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14.

  In the present embodiment, it is assumed that the BD-J application can access only the logical plane 10 and cannot directly access the graphics plane 11 and the background plane 14.

  Therefore, the BD-J application can only perform image drawing on the logical plane 10 and cannot directly perform on the graphics plane 11 and the background plane 14. Therefore, the BD-J application indirectly draws an image on the graphics plane 11 or the background plane 14 by drawing an image on the logical plane 10.

  However, in the following, for convenience of description, drawing of an image on the graphics plane 11 and the background plane 14 via the logical plane 10 by the BD-J application is simply performed on the graphics plane 11 and the background plane 14. Also described as drawing an image on

  Note that the 3D-compatible player can be configured without the logical plane 10. In this case, the BD-J application directly draws an image on the graphics plane 11 or the background plane 14.

  The BD-J application can perform video and PG playback control such as video and PG scaling and position (display position) control in addition to drawing images on the graphics plane 11 and the background plane 14. it can.

  In the BD-J application, video and PG are handled as one set (collectively). That is, the BD-J application does not distinguish (cannot distinguish) video and PG.

  [Drawing graphics image by BD-J application]

  FIG. 5 is a diagram illustrating the rendering of a graphics 3D image on a graphics plane 11 (Stereoscopic grapics planes) by the BD-J application.

  As the 3D image drawing method, the first drawing method and the second drawing method can be employed.

  FIG. 5A is a diagram illustrating the first drawing method.

  In the first drawing method, the author of the BD-J application draws on the stereo plane.

  That is, in the first rendering method, graphics 3D image data is composed of left-eye image data and right-eye image data, and the BD-J application uses the left-eye image and right-eye image. The work image is drawn on the logical plane 10.

  Then, the left-eye image and right-eye image drawn on the logical plane 10 are drawn on the graphics plane 11 as they are. That is, the image for the left eye drawn on the logical plane 10 is directly drawn on the L graphics plane 11L, and the image for the right eye drawn on the logical plane 10 is drawn on the R graphics plane 11R as it is. .

  FIG. 5B is a diagram illustrating the second drawing method.

  In the second drawing method, the author of the BD-J application draws on a monoplane. At the same time, the author supplies an offset value (graphics plane offset value). The 3D-compatible player generates a stereo plane from the mono plane based on the offset value.

  That is, in the second rendering method, the 3D image data generates a 3D image, that is, the original original image data, and the original image is given parallax, and the left image and the right eye are converted from the original image. And parallax data for generating an image for use.

  The BD-J application draws the original image on the logical plane 10. The 3D-compatible player draws an image for the left eye and an image for the right eye generated by giving parallax to the original image drawn on the logical plane 10 on the L graphics plane 11L and the R graphics plane 11R, respectively. To do.

  Here, assuming that the parallax data is an offset value (offset), the number of pixels (the number of pixels) by which the position of the original image is shifted in the horizontal direction (x direction) can be adopted as the offset value.

  In the L graphics plane 11L, the original image drawn on the logical plane 10 is drawn at a position shifted in the horizontal direction by the offset value, with the right direction from the left as the positive direction. That is, an image obtained as a result of shifting the horizontal position of the original image drawn on the logical plane 10 by the offset value is drawn on the L graphics plane 11L as the left-eye image.

  In the R graphics plane 11R, the original image drawn on the logical plane 10 is drawn at a position shifted in the horizontal direction by the offset value, with the right direction from the right as the positive direction. That is, an image obtained as a result of shifting the horizontal position of the original image drawn on the logical plane 10 by the offset value is drawn on the R graphics plane 11R as the right-eye image.

  Since the original image drawn on the logical plane 10 is drawn on the L graphics plane 11L with the horizontal position shifted, drawing is performed when the horizontal position is not shifted (the horizontal position is not shifted). Area (pixels) in which drawing is not performed. In the area of the L graphics plane 11L where the original image is not drawn, a transparent color is drawn. The same applies to the R graphics plane 11R.

  Here, when the offset value is positive, the 3D image displayed by the left-eye image and the right-eye image is lifted to the near side in the depth direction perpendicular to the display screen of the display (not shown). Looks. On the other hand, when the offset value is negative, the 3D images displayed by the left-eye image and the right-eye image appear to be recessed on the far side in the depth direction.

  FIG. 6 is a diagram illustrating a graphics mode in which a BD-J application reproduces a graphics image by drawing a graphics 3D image on the graphics plane 11.

  On the Reference Decoder Model, the 3D-compatible player always has 2-plane (L graphics plane 11L and R graphics plane 11R), and the BD-J application has a specification for drawing on the logical plane 10.

  Finally, the graphics left-eye image (L graphics plane) drawn on the L graphics plane 11L is the video (and PG) left-eye image (L video plane) drawn on the L video plane 13L. ). Also, the graphics right-eye image (R graphics plane) drawn on the R graphics plane 11R is blended with the video right-eye image (R video plane) drawn on the R video plane 13R.

  FIG. 6A illustrates a mono-logical-plane + offset value mode (hereinafter also referred to as an offset graphics mode) that is one mode Mode # 1 of the graphics mode.

  In the offset graphics mode, the BD-J application draws a mono image that is a graphics 2D image on the logical plane 10. Further, the BD-J application gives an offset value to the 3D-compatible player.

  The 3D-compatible player generates a stereo image, which is a graphics 3D image, from the mono image drawn on the logical plane 10 and the offset value given from the BD-J application. Further, the BD player draws (stores) the image for the left eye constituting the stereo image on the L graphics plane 11L (L region), and also converts the image for the right eye constituting the stereo image to the R graphics plane 11R. Draw (store) in (R area).

  Then, the mixer 15 blends and outputs the graphics left-eye image drawn (stored) on the L graphics plane 11L with the video (and PG) left-eye image drawn on the L video plane 13L. Furthermore, the mixer 15 blends the graphics right-eye image drawn on the R graphics plane 11R with the video right-eye image drawn on the R video plane 13R, and outputs the blended result.

  FIG. 6B illustrates a stereo-logical-plane mode (hereinafter also referred to as a stereo graphics mode) that is one mode Mode # 2 of the graphics mode.

  In the stereo graphics mode, the BD-J application draws the left-eye image and the right-eye image constituting the stereo image that is a graphics 3D image on the logical plane 10.

  The 3D-compatible player draws the left-eye image drawn on the logical plane 10 on the L graphics plane 11L, and draws the right-eye image drawn on the logical plane 10 on the R graphics plane 11R.

  Then, the mixer 15 blends the graphics image for the left eye drawn on the L graphics plane 11L with the video image for the left eye drawn on the L video plane 13L, and outputs the blended image. Furthermore, the mixer 15 blends the graphics right-eye image drawn on the R graphics plane 11R with the video right-eye image drawn on the R video plane 13R, and outputs the blended result.

  FIG. 6C illustrates a forced-mono-logical-plane mode (hereinafter also referred to as forced mono graphics mode) that is one mode Mode # 3 of the graphics mode.

  In the forced mono graphics mode, the BD-J application draws a stereo image that is a graphics 3D image on the logical plane 10.

  The 3D-compatible player is one of the L graphics image and the R graphics image among the stereo images drawn on the logical plane 10, for example, only the L graphics image is converted into the L graphics plane 11L and the R graphics plane. For example, the drawing is performed only on the L graphics plane 11L.

  The mixer 15 blends the graphics mono image drawn on the L graphics plane 11L with the video image drawn on the L video plane 13L, and outputs the blended image.

FIG. 6D illustrates a flattened-stereo-logical-plane mode (hereinafter also referred to as a flat stereo graphics mode) that is one mode Mode # 4 of the graphics mode.
In the flat stereo graphics mode, the BD-J application draws a left-eye image and a right-eye image that form a stereo image that is a graphics 3D image on the logical plane 10.

  The 3D-compatible player is one of the left-eye image and the right-eye image drawn on the logical plane 10, for example, only the left-eye image is converted into the L graphics plane 14L and the R graphics plane 14R. Draw both images and discard the other image for the right eye.

  Then, the graphics left-eye image drawn on the L graphics plane 14L is supplied to the mixer 15, and the graphics left-eye image drawn on the graphics plane 14R is either (as the right-eye image). Is also supplied to the mixer 15.

  FIG. 6E illustrates a mono-logical-plane mode (hereinafter also referred to as mono graphics mode) which is one mode Mode # 5 of the graphics mode.

  In the mono graphics mode, the BD-J application draws a mono image, which is a graphics 2D image, on the logical plane 10.

  The 3D-compatible player draws the mono image drawn on the logical plane 10 only on the L graphics plane 11L, for example, one of the L graphics plane 11L and the R graphics plane 11R.

  The mixer 15 blends the graphics mono image drawn on the L graphics plane 11L with the video image drawn on the L video plane 13L, and outputs the blended image.

  [Set and get offset value]

  In the 3D-compatible player, the offset value can be applied to the graphic plane 11 and the PG plane 12.

  Here, an offset value (data that gives a parallax to a graphics image) applied to the graphic plane 11 is also referred to as a graphics plane offset value. An offset value (data that gives parallax to a PG image) applied to the PG plane 12 is also referred to as a PG plane offset value.

  For setting and obtaining the graphics plane offset value, the following API for reading and writing the offset value is defined, and the graphics plane offset value can be set and obtained by the dedicated API.

org.bluray.ui.3D
public void setOffset (int offset)
The default value is 0
public int getOffset ()
The default value is 0

  The setOffset () method is a method for storing (setting) the graphics plane offset value in an internal storage area that is a storage area provided inside the BD player, and getOffset () is an internal storage of the BD player. This method acquires the graphics plane offset value stored in the area.

  Further, the BD player has a PSR (Player Setting Register) that stores information related to BD playback, and the graphics plane offset value and the PG plane offset value are reserved by the legacy player in the PSR. For example, it can be stored in PSR # 21.

  Here, the substance of the internal storage area and the PSR is a partial storage area of the RAM 104 or the hard disk 105 in FIG.

  By the way, in the current BD standard (BD-ROM standard), writing to the PSR of a BD player from a BD-J application is prohibited.

  If the BD player in FIG. 3 which is a 3D-compatible player is allowed to write to the PSR from the BD-J application, a large-scale revision of the current BD standard is required.

  Therefore, a 3D-compatible player can indirectly write to the PSR by defining an offset value as General Preference.

  That is, the 3D-compatible player stores information related to BD playback, using BD standard graphics and an offset value, which is data that gives disparity to PG images, as one of the general preferences of the BD standard. A general preference API (Application Programming Interface) for reading and writing offset values to / from PSR # 21.

  Here, PSR # 21 is mapped to the General Preference of the BD standard part3-2 Annex L, and the value can be set and acquired by the org.dvb.user.GeneralPreference API.

  General Preference name for accessing PSR with General Preference API can be defined as follows.

  That is, the general preference name of the graphics plane offset value can be defined as “graphics offset”, for example. Further, the general preference name of the PG plane offset value can be defined as, for example, “subtitle offset”.

  Note that the default values of “graphics offset” General Preference and “subtitle offset” General Preference are both 0, for example.

  For setting and obtaining the graphics plane offset value, the following dedicated API can be defined, and the graphics plane offset value can be set and obtained by the dedicated API.

org.bluray.ui.3D
public void setOffset (int offset)
The default value is 0
public int getOffset ()
The default value is 0

  The setOffset () method is a method for storing the graphics plane offset value in the internal storage area of the BD player (in this case, for example, PSR), and getOffset () is stored in the internal storage area of the BD player. This method obtains the graphics plane offset value.

  FIG. 7 shows the functional configuration of the BD player in FIG. 3 as a 3D-compatible player that reads and writes BD standard graphics and offset values of PG (hereinafter, including TextST unless otherwise specified) as described above. It is a block diagram which shows an example.

  That is, FIG. 7A shows the BD standard graphics and the PG offset value read / write to / from the internal storage area of the 3D compatible player as shown in FIG. It is a block diagram which shows the functional structural example of a BD player.

  In the 3D-compatible player in FIG. 7A, the BD-J application requests reading / writing (setting or acquisition) of the offset value from an API (General Preference API) dedicated to reading / writing the offset value.

  The API for reading / writing the offset value sets the offset value (graphics plane offset value, PG plane offset value) in the internal storage area of the 3D-compatible player in response to a request from the BD-J application, or Gets the offset value from the internal storage area of the 3D-compatible player and returns it to the BD-J application.

  In FIG. 7A, the playback control engine (Playback Control Engine) is an image (original image) drawn on the logical plane 10 by the BD-J application in accordance with the offset value set in the internal storage area of the 3D-compatible player. Then, control for generating (reproducing) the image for the left eye and the image for the right eye is performed.

  As described above, an API for reading and writing offset values is defined, and the API for reading and writing offset values gives disparity to BD standard graphics and PG images in response to requests from BD-J applications. By reading / writing the offset value, which is data, to / from the internal storage area of the 3D-compatible player, the offset value that gives the parallax to the image can be indirectly set and acquired from the BD-J application.

  FIG. 7B is a diagram showing a 3D-compatible player having a general preference API for reading and writing an offset value to / from PSR # 21, using BD standard graphics and PG offset values as one of the general preferences of the BD standard. 3 is a block diagram illustrating a functional configuration example of a BD player 3; FIG.

  In the 3D-compatible player in FIG. 7B, the BD-J application requests the general preference API (General Preference API) to read and write (set or acquire) the offset value.

  That is, when the offset value for which reading / writing is requested is a graphics plane offset value, the BD-J application calls the general preference API with the general preference name (General Preference name) as “graphics offset”.

  Further, when the offset value for requesting reading / writing is the PG plane offset value, the BD-J application calls the general preference API with the general preference name as “subtitle offset”.

  The general preference API sets an offset value to PSR # 21 in the PSR (Player Setting Register) or obtains an offset value from PSR # 21 in response to a request from the BD-J application. Return to BD-J application.

  In FIG. 7B, the playback control engine (Playback Control Engine) determines the left eye from the image (original image) drawn on the logical plane 10 by the BD-J application according to the offset value set in PSR # 21. Control for generating (reproducing) the image for use and the image for the right eye is performed.

  As described above, the General Preference API uses the BD standard graphics and the offset value, which is data that gives disparity to the PG image, as one of the BD standard general preferences in response to a request from the BD-J application. By reading / writing an offset value with respect to PSR # 21 that stores information related to BD playback, an offset value that gives parallax to an image can be indirectly set and acquired from a BD-J application.

  [configuration]

  FIG. 8 is a diagram showing a video mode for reproducing a video image, which is one of the configurations of the video plane 13.

  FIG. 8A shows a mono-video mode (hereinafter also referred to as a mono video mode) which is one mode Mode # 1 of the video mode.

  In the mono video mode, the 3D-compatible player converts a mono image, which is a 2D image of video, into one of the L video plane 13L (L region) and the R video plane 13R (R region), for example, L video. Draw (store) only on the plane 13L.

  The video mono image drawn (stored) only on the L video plane 13 </ b> L is supplied to the mixer 15.

  FIG. 8B shows a dual-mono-video mode (hereinafter also referred to as a dual mono video mode) which is one mode Mode # 2 of the video mode.

  In the dual mono video mode, the 3D-compatible player draws (stores) a mono image that is a 2D image of a video on the L video plane 13L (L region) (as an image for the left eye) and displays the mono image. , (As an image for the right eye), is drawn (stored) on the R video plane 13R (R region).

  The video mono image drawn (stored) on the L video plane 13L and the video mono image drawn on the R video plane 13R are both supplied to the mixer 15.

  FIG. 8C shows a stereo-video mode (hereinafter also referred to as a stereo video mode) which is one mode Mode # 3 of the video mode.

  In the stereo video mode, the 3D-compatible player draws the left-eye image constituting the stereo image that is the 3D image of the video on the L video plane 13L, and the right-eye image constituting the stereo image is rendered as the R video Draw on the plane 13R.

  The video image for the left eye drawn (stored) on the L video plane 13 </ b> L and the video image for the right eye drawn on the R video plane 13 </ b> R are both supplied to the mixer 15.

  FIG. 8D shows a flattened-stereo-video mode (hereinafter also referred to as a flat stereo video mode) that is one mode Mode # 4 of the video mode.

  In the flat stereo video mode, the 3D-compatible player selects one of the left-eye image and the right-eye image constituting the stereo image that is a 3D image of the video, for example, only the left-eye image, Drawing is performed on both the video plane 13L and the R video plane 13R, and the other right-eye image is discarded.

  Then, the video image for the left eye drawn (stored) on the L video plane 13L is supplied to the mixer 15, and the video image for the left eye drawn on the R video plane 13R is (the image for the right eye). ) To the mixer 15.

  FIG. 8E shows a forced-mono-video mode (hereinafter also referred to as forced mono video mode) which is one mode Mode # 5 of the video mode.

  In the forced mono video mode, the 3D-compatible player selects one of the left-eye image and the right-eye image that form a stereo image that is a 3D image of the video, for example, only the left-eye image. For example, the drawing is performed only on the L video plane 13L, which is one of the video plane 13L and the R video plane 13R, and the other right-eye image is discarded.

  Then, only the video image for the left eye drawn (stored) on the L video plane 13 </ b> L is supplied to the mixer 15.

  FIG. 9 is a diagram illustrating a background mode for reproducing a background image, which is one of the configurations of the background plane 14.

  FIG. 9A shows a dual-mono-background mode (hereinafter also referred to as a dual mono background mode) which is one mode Mode # 1 of the background mode.

  In the dual mono background mode, the BD-J application draws a mono image that is a background 2D image on the logical plane 10 as an image for the left eye and an image for the right eye.

  Then, the 3D-compatible player draws (stores) the image for the left eye drawn on the logical plane 10 on the L background plane 14L (L region), and the image for the right eye drawn on the logical plane 10 , R is drawn (stored) on the R background plane 14R (R region).

  The background image for the left eye drawn (stored) on the L background plane 14 </ b> L and the image for the right eye background drawn on the R background plane 14 </ b> R are both supplied to the mixer 15.

  FIG. 9B shows a stereo-background mode (hereinafter also referred to as a stereo background mode) which is one mode Mode # 2 of the background mode.

  In the stereo background mode, the BD-J application draws a left-eye image and a right-eye image that form a stereo image that is a background 3D image on the logical plane 10.

  Then, the 3D-compatible player draws the image for the left eye drawn on the logical plane 10 on the L background plane 14L, and draws the image for the right eye drawn on the logical plane 10 on the R background plane 14R. To do.

  Both the background image for the left eye drawn on the L background plane 14 </ b> L and the background image for the right eye drawn on the R background plane 14 </ b> R are supplied to the mixer 15.

  FIG. 9C shows a flattened-stereo-background mode (hereinafter also referred to as a flat stereo background mode) which is one mode Mode # 3 of the background mode.

  In the flat stereo background mode, the BD-J application draws a left-eye image and a right-eye image that form a stereo image that is a background 3D image on the logical plane 10.

  Then, the 3D-compatible player selects one of the left-eye image and the right-eye image drawn on the logical plane 10, for example, only the left-eye image, the L background plane 14L, and R Drawing on both of the background planes 14R, discarding the other right-eye image.

  The background image for the left eye drawn on the L background plane 14L is supplied to the mixer 15, and the image for the left eye drawn on the R background plane 14R is (as the image for the right eye). ,) Are supplied to the mixer 15.

  FIG. 9D shows a mono-background mode (hereinafter also referred to as a mono background mode) which is one mode Mode # 4 of the background mode.

  In the mono background mode, the BD-J application draws a mono image that is a background 2D image on the logical plane 10.

  Then, the 3D-compatible player draws the mono image drawn on the logical plane 10 only on the L background plane 14L, for example, one of the L background plane 14L and the R background plane 14R.

  The background mono image drawn on the L background plane 14 </ b> L is supplied to the mixer 15.

  FIG. 9E shows a forced-mono-background mode (hereinafter also referred to as forced mono background mode) that is one mode Mode # 5 of the background mode.

  In the forced mono background mode, the BD-J application draws a left-eye image and a right-eye image that form a stereo image that is a background 3D image on the logical plane 10.

  Then, the 3D-compatible player selects one of the left-eye image and the right-eye image drawn on the logical plane 10, for example, only the left-eye image, the L background plane 14L, and R Drawing is performed only on one of the background planes 14R, for example, the L background plane 14L, and the other image for the right eye is discarded.

  The background image for the left eye drawn on the L background plane 14 </ b> L is supplied to the mixer 15.

  Here, the graphics plane 11 for storing graphics, the video plane 13 for storing video (and the PG plane 12 for storing PG), and the background plane 14 for storing background shown in FIG. 4 are summarized. Also referred to as a device plane.

  In the BD player of FIG. 3 which is a 3D-compatible player, the device plane configuration is (1) image frame and color depth, (2) video mode (Video mode), (3) graphics mode (BD-J Graphics mode), and (4) background mode.

  FIG. 10 shows the relationship among the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14, which are device planes.

  The graphics plane 11 includes an L graphics plane 11L as an L area that is a storage area for storing a left-eye image and an R graphics plane 11R as an R area that is a storage area for storing a right-eye image. . In the graphics plane 11, the L graphics plane 11L and the R graphics plane 11R are arranged side by side.

  That is, in FIG. 10, the L graphics plane 11L and the R graphics plane 11R are moved up and down so that the L graphics plane 11L that is the L region is on the upper side and the R graphics plane 11R that is the R region is on the lower side. The graphics plane 11 is configured by arranging them side by side.

  Other device planes, that is, the PG plane 12, the video plane 13, and the background plane 14 are also configured in the same manner as the graphics plane 11.

  Images drawn on the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14 are superimposed in this order from the front side in the order of the graphics plane 11, the PG plane 12, the video plane 13, and the background plane 14. (Blend), the L region image and the R region image obtained as a result are alternately drawn (stored) on the logical screen 21 that abstracts the display screen of the display, for example.

  Here, the substance of the logical screen 21 is a partial storage area of the RAM 104.

  In addition, the device plane is a storage area in which an L area and an R area, which are storage areas for one image, are arranged one above the other, and is therefore a storage area for two images. The screen 21 is a storage area for one image.

  The configuration of the device plane is defined for the entire device plane, which is a storage area for two plane images, for a 3D image.

  FIG. 11 shows (1) image frame (Resolution) and color depth (color-depth), which is one of the configurations of the device plane.

  In FIG. 11, the image frame of 5 lines from the top (the width of the device plane × the number of vertical pixels) (resolution) and the color depth indicate the image frame and color depth of the 3D image, and the remaining 5 The image frame and color depth of the row (5 rows from the bottom) indicate the image frame and color depth of the 2D image.

  If one surface of a 2D image is an image for one surface, the 3D image is composed of an image for the left eye and an image for the right eye, and thus becomes an image for two surfaces. In addition, since the device plane is a storage area in which an L area and an R area, which are storage areas for one image, are arranged vertically, a 3D image stored in such a device plane The image frame has a size obtained by doubling the number of pixels in the vertical direction of the corresponding 2D image (a 2D image having the same size as the left-eye image (or right-eye image)).

  In the current BD standard, for 2D images, graphics (images) stored in the graphics plane 11 and background (images) stored in the background plane 14 are both In principle, it matches the image frame of the video stored in the video plane 13.

  However, for 2D images, when the video frame stored in the video plane 13 is 1920 × 1080 pixels, the background frame stored in the background plane 14 is stored in the video plane 13. Similarly to the video image frame, the image frame is 1920 × 1080 pixels, but the graphics image frame stored in the graphics plane 11 is 1/2 in the horizontal and vertical directions of the video image frame stored in the video plane 13, respectively. There is a case of 2 (960 × 540 pixels) (fourth line from the bottom in FIG. 11) (hereinafter also referred to as a 2D image mismatch case).

  In this case, the graphics of 960 × 540 pixels stored in the graphics plane 11 is 1920 × 1080 which is a video image frame stored in the video plane 13 by doubling the horizontal and vertical dimensions. Displayed after matching the pixels.

  For 3D images, there are cases corresponding to 2D image mismatch cases (hereinafter also referred to as 3D image mismatch cases).

  In the case of 3D image mismatch, when the video frame stored in the video plane 13 is 1920 × 2160 pixels, the background frame stored in the background plane 14 is stored in the video plane 13. Similarly to the video image frame, the image frame is 1920 × 2160 pixels, but the graphics image frame stored in the graphics plane 11 is 1/2 in the horizontal and vertical directions of the video image frame stored in the video plane 13, respectively. It becomes 960 × 1080 pixels set to 2 (in FIG. 11, the third row from the top).

  Even in the case of non-matching 3D images, 960 × 1080 pixel graphics is doubled horizontally and vertically to match the size of 1920 × 2160 pixels, which is the video frame stored in the video plane 13 It is displayed after letting.

  FIG. 12 is a diagram for explaining a method of drawing a 3D image by the second drawing method (FIG. 5B) in the case of mismatching 3D images.

  In the second drawing method, as described with reference to FIG. 5B, the original image from which the 3D image is generated is drawn on the logical plane 10, and then the original image is even in the horizontal direction by an offset value. The left-eye image and the right-eye image generated in this way are drawn on the graphics plane 11.

  Here, in the second drawing method, each of an upper half and a lower half of a vertically long image obtained by arranging two images of an original image and a copy of the original image in the horizontal direction is horizontal according to an offset value. It can be said that this is a method of drawing two images obtained by shifting in the direction on the graphics plane 11 as an image for the left eye and an image for the right eye.

  Now, in the second drawing, 960 × 1080 pixel graphics in the case of mismatching 3D images can be obtained by sliding each of the upper half and the lower half horizontally according to the offset value. When the image for the left eye and the image for the right eye of × 540 pixels are drawn on the graphics plane 11, and then the horizontal and vertical images of the left eye image and the right eye image on the graphics plane 11 are respectively doubled, The resulting left-eye image and right-eye image are images in which the amount of shift in the horizontal direction is twice the offset value.

  Therefore, in this case, the position in the depth direction of the 3D image displayed by the image for the left eye and the image for the right eye is a position different from the position intended by the author.

  Therefore, in the case of 3D image mismatch, when drawing a 3D image with the second drawing method, an image obtained by doubling the horizontal and vertical sides of the original image from which the 3D image is generated is logically It is necessary to draw on the graphics plane 11 the image for the left eye and the image for the right eye, which are generated by drawing on the plane 10 and then smoothing the image drawn on the logical plane 10 by the offset value in the horizontal direction. is there.

  By doing in this way, the position in the depth direction of the 3D image displayed by the image for the left eye and the image for the right eye is the position intended by the author.

  FIG. 13 is a diagram illustrating a device plane.

  In the current BD standard, an image storage area for one screen is assumed as the logical screen 21, and an image for the left eye (Left / Left is stored in the logical screen 21 that is the image storage area for one screen. -eye) and right-eye images (Right / Right-eye) are not supposed to be drawn alternately.

  The current BD standard assumes that there is a one-to-one relationship between the device plane configuration and the logical screen 21. Under this premise, the processing of 3D images requires two separate logical screens, that is, a logical screen for drawing a left-eye image and a logical screen for drawing a right-eye image. .

  Therefore, in the BD player of FIG. 3 which is a 3D-compatible player, the device configuration for L / R is defined on one side by doubling the definition of resolution in the vertical direction. The logical screen itself is one surface as before, and a drawing model that simultaneously draws the output for L / R is defined there.

  That is, the BD player in FIG. 3 includes device planes (graphics plane 11, video plane 13 (PG plane 12), and background plane 14) that store BD-standard graphics, video, or background images. .

  The device plane has two planes, an L area that is an area for storing one image for storing an image for the left eye and an R area that is an area for storing one image for storing an image for the right eye. The storage areas of the image planes are arranged side by side, and the configuration of the device plane is defined for the entire device plane, which is the storage area of the image for two planes.

  Then, the left-eye image and the right-eye image stored in the device plane are drawn on the logical screen 21 alternately, for example.

  By doing in this way, a logical screen for storing a left-eye image (L image) and a logical screen for storing a right-eye image (R image) are not separately provided as logical screens. It will end.

  [Video mode, graphics mode, background mode]

  The configuration can be specified (set) by providing a bit field for specifying the configuration in the BD-J object (Object) file.

  FIG. 14 shows bit fields provided in the BD-J object file for designating the configuration.

  In the file of the BD-J object, four fields of initial_configuration_id, initial_graphics_mode, initial_video_mode, and initial_background_mode can be provided to specify the configuration.

  initial_configuration_id is a field for specifying (1) image frame and color depth. If the value taken by initial_configuration_id is a configuration id, the following value is defined as the configuration id.

HD_1920_1080 = 1
HD_1280_720 = 2
SD_720_576 = 3
SD_720_480 = 4
QHD_960_540 = 5
HD_1920_2160 = 6
HD_1280_1440 = 7
SD_720_1152 = 8
SD_720_960 = 9
QHD_960_1080 = 10

  HD_1920_1080 is the image frame and color depth of the sixth line from the top of FIG. 11, HD_1280_720 is the image frame and color depth of the eighth line from the top of FIG. 11, and SD_720_576 is 10 lines from the top of FIG. The image frame and color depth of the eye, SD_720_480 is the image frame and color depth of the ninth line from the top of FIG. 11, QHD_960_540 is the image frame and color depth of the seventh line from the top of FIG. 11, and HD_1920_2160 is 11 shows the image frame and color depth of the first line from the top, HD_1280_1440 shows the image frame and color depth of the second line from the top of FIG. 11, and SD_720_1152 shows the image frame and color depth of the fifth line from the top of FIG. SD_720_960 represents the image frame and color depth in the fourth row from the top in FIG. 11, and QHD_960_1080 represents the image frame and color depth in the third row from the top in FIG. 11, respectively.

  initial_graphics_mode is a field for specifying (3) graphics mode.

  Here, the graphics mode (BD-J Graphics mode) includes the offset graphics mode (offset), the stereo graphics mode (stereo), the mono graphics mode (mono (Legacy playback mode)), and the forced mono graphics mode described in FIG. There are a total of five modes: (forced mono (Legacy playback mode)) and flat stereo graphics mode (flattened-stereo).

  The following values are defined as initial_graphics_mode for specifying the graphics mode.

GRAPHICS_MONO_VIEW = 22
GRAPHICS_STEREO_VIEW = 23
GRAPHICS_PLANE_OFFSET = 24
GRAPHICS_DUAL_MONO_VIEW = 25
GRAPHICS_FORCED_MONO_VIEW = 26

  Note that GRAPHICS_MONO_VIEW represents a mono-brax mode, GRAPHICS_STEREO_VIEW represents a stereo graphics mode, GRAPHICS_PLANE_OFFSET represents an offset graphics mode, GRAPHICS_DUAL_MONO_VIEW represents a flat stereo graphics mode, and GRAPHICS_FORCED_MONO_VIEW represents a forced mono graphics mode.

  When initial_configuration_id is set to any one of 1, 2, 3, 4, and 5, initial_graphics_mode is ignored.

  initial_video_mode is a field for specifying (2) video mode.

  Here, as the video mode, the dual mono video mode (dual-mono), stereo video mode (stereo), flat stereo video mode (flattened-stereo), and mono video mode (mono ( Legacy playback mode)) and forced mono video mode (forced-mono).

  The following values are defined as initial_video_mode for specifying the video mode.

VIDEO_MONO_VIEW = 27
VIDEO_STEREO_VIEW = 28
VIDEO_FLATTENED_STEREO_VIEW = 29
VIDEO_DUAL_MONO_VIEW = 30
VIDEO_FORCED_MONO_VIEW = 31

  VIDEO_MONO_VIEW represents the mono video mode, VIDEO_STEREO_VIEW represents the stereo video mode, VIDEO_FLATTENED_STEREO_VIEW represents the flat stereo video mode, VIDEO_DUAL_MONO_VIEW represents the dual mono video mode, and VIDEO_FORCED_MONO_VIEW represents the forced mono video mode.

  When initial_configuration_id is set to any one of 1, 2, 3, 4, and 5, initial_video_mode is ignored.

  initial_background_mode is a field for specifying (4) background mode.

  Here, as the background mode, the dual mono background mode (dual-mono), stereo background mode (stereo), flat stereo background mode (flattened-stereo) described in FIG. There are a total of five modes: ground mode (mono (Legacy playback mode)) and forced mono background mode (forced-mono).

  The following values are defined as initial_background_mode that specifies the background mode.

BACKGROUND_MONO_VIEW = 17
BACKGROUND_STEREO_VIEW = 18
BACKGROUND_FLATTENED_STEREO_VIEW = 19
BACKGROUND_DUAL_MONO_VIEW = 20
BACKGROUND_FORCED_MONO_VIEW = 21

  The background_mono_view is a mono background mode, the background_stereo_view is a stereo background mode, the background_flattened_stereo_view is a flat stereo background mode, the background_dual_mono_view is a dual mono background mode, the background_forced_mono_view is a forced mono background mode, Represent each.

  When initial_configuration_id is set to any one of 1, 2, 3, 4, and 5, initial_background_mode is ignored.

  Here, in the BD-J Object file, it is possible to adopt a specification that specifies only initial_configuration_id among initial_configuration_id, initial_graphics_mode, initial_video_mode, and initial_background_mode.

  In the BD-J Object file, when only initial_configuration_id is specified, default specified values of initial_video_mode, initial_graphics_mode, and initial_background_mode are required.

  FIG. 15 shows default specified values of initial_video_mode, initial_graphics_mode, and initial_background_mode.

  Note that STEREO_VIEW in the video mode (initial_video_mode) represents the above-described VIDEO_STEREO_VIEW or VIDEO_FLATTENED_STEREO_VIEW, and MONO_VIEW represents the above-described VIDEO_MONO_VIEW or VIDEO_DUAL_MONO_VIEW.

  Further, STEREO_VIEW in the graphics mode (initial_graphics_mode) represents the above-described GRAPHICS_STEREO_VIEW or GRAPHICS_PLANE_OFFSET, and MONO_VIEW represents the above-described GRAPHICS_MONO_VIEW or GRAPHICS_DUAL_MONO_VIEW.

  Further, STEREO_VIEW in the background mode (initial_background_mode) represents the above-described BACKGROUND_STEREO_VIEW or BACKGROUND_FLATTENED_STEREO_VIEW, and MONO_VIEW represents the above-mentioned BACKGROUND_MONO_VIEW or BACKGROUND_DUAL_MONO_VIEW.

  [Change Configuration]

  Next, the configuration change will be described.

  The configuration is the timing when BD-J title is activated, when auto-reset is performed during PlayList playback (dynamic change), and when API is called by the BD-J application (dynamic change). It can be changed.

  Unlike playback of conventional mono video + mono graphics, the plane configuration can be changed even during AV playback.

  That is, in the 3D-compatible player, the configuration can be changed while an AV stream (video) is being reproduced.

  As with Mono-view, in playback other than KEEP_RESOLUTION playback, the image frame is aligned (when BD-J title is activated, video / background is aligned with the graphics image frame, and during PlayList playback, graphics / background is Change the configuration so that when the API is called by the BD-J application, the plain image frame set by the API is aligned with the other non-configured plain image frames so that the video image frame is aligned. This process is performed by a 3D-compatible player. Also, error processing when changing the configuration depends on the 3D-compatible player.

  Here, KEEP_RESOLUTION playback is a playback mode that synthesizes SD (Standard definition) video, HD (High Definition) graphics, and HD background, 1920 × 1080 pixel Graphics, 720 × 480 pixel Video + PG. In some cases, a background of 1920 × 1080 pixels is combined, and in some cases, a Graphics of 1920 × 1080 pixels, a Video + PG of 720 × 576 pixels, and a background of 1920 × 1080 pixels are combined. Note that playback of an image of 1280 × 720 pixels, which is an HD image, is not included in KEEP_RESOLUTION playback.

  16 and 17 show combinations of Video + PG, BD-J graphics, and background resolution (image frame) for playback other than KEEP_RESOLUTION playback. In addition, FIG. 17 is a figure following FIG.

  FIG. 18 shows an example of configuration change processing.

  FIG. 18A shows an example of processing of a 3D-compatible player when the configuration (video mode) of graphics (graphics plane 11) is changed from STEREO_VIEW to MONO_VIEW.

  For example, in a 3D-compatible player, when the video mode is STEREO_VIEW and graphics are drawn on the L graphics plane 11L and the R graphics plane 11R constituting the graphics plane 11 of 1920 × 2160 pixels, the graphics plane Suppose that the video mode is changed from STEREO_VIEW to MONO_VIEW without resetting 11 (as a storage area).

  In this case, in the 3D-compatible player, only an image stored (drawn) in the L graphics plane 11L, which is one of the L graphics plane 11L and the R graphics plane 11R constituting the graphics plane 11, is logically stored. The image supplied and displayed on the screen 21 and stored in the other R graphics plane 11R is discarded.

  In this case, the 3D-compatible player may forcibly terminate as an error (image reproduction).

  FIG. 18B shows an example of processing of the 3D-compatible player when the video mode is changed from MONO_VIEW to STEREO_VIEW.

  For example, in a 3D-compatible player, when the video mode is MONO_VIEW, and graphics are drawn only on the L graphics plane 11L constituting the 1920 × 1080 pixel graphics plane 11, the graphics plane 11 is not reset. Assume that the video mode is changed from MONO_VIEW to STEREO_VIEW.

  In this case, in the 3D-compatible player, the graphics drawn on the L graphics plane 11L are copied to the R graphics plane 11R, and the graphics drawn on the L graphics plane 11L are supplied to the logical screen 21 as an image for the left eye. At the same time, graphics copied to the R graphics plane 11R are supplied to the logical screen 21 as an image for the right eye.

  In this case, the 3D-compatible player may forcibly terminate as an error (image reproduction).

  [Change of configuration when starting BD-J title]

  In principle, the following three rules # 1-1, # 1-2, and # 1-3 are applied to change the configuration when starting the BD-J title.

  That is, rule # 1-1 is a rule that the resolution (image frame) of the three images of Graphics, Video, and Background must always be the same in the configuration (of the device plane). is there.

  According to rule # 1-2, when PlayList playback is performed in addition to KEEP_RSOLUTION playback, the resolution (image frame) of the three images, Graphics, Video, and Background, must match the video resolution in the configuration. This is the rule.

  Rule # 1-3 is a rule that when the graphics is QHD graphics in the configuration, the resolution after being scaled by 2 times in the vertical direction and 2 times in the horizontal direction is set as the resolution of the configuration. .

  The values of video mode, graphics mode, and background mode are determined according to the default value specified by the initial_configuration_id of the BD-J object file (video mode, graphics mode, and background mode are determined). .

  When autostart_first_PlayList_flag of the BD-J object file is set to 1b, the video plane configuration is not the default value, but follows the rules for auto-reset (dynamic change) during PlayList playback.

  [Configuration change when auto-reset is performed during PlayList playback (dynamic change)]

  In principle, the following three rules # 2-1, # 2-2, and # 2-3 are applied to change the configuration when auto-reset during PlayList playback is performed.

  That is, rule # 2-1 is a rule that in the (device plane) configuration, the resolution (image frame) of the three images of Graphics, Video, and Background must always be the same resolution. is there.

  According to rule # 2-2, when PlayList playback is performed in addition to KEEP_RSOLUTION playback, the resolution (image frame) of the three images Graphics, Video, and Background must match the video resolution in the configuration. This is the rule.

  Rule # 2-3 is a rule that when the graphics is QHD graphics in the configuration, the resolution after scaling by 2 times in the vertical direction and 2 times in the horizontal direction is used as the resolution of the configuration. .

  At the start of PlayList playback, the video plane configuration is automatically aligned with the video attributes of the PlayList.

  If the configuration is automatically aligned with the video attributes of the PlayList, the current BD standard specifies that the graphics plane and background plane should also be automatically aligned with the video plane attributes as a mandatory function on the BD player side. Yes. However, in 3D-compatible players, when switching from stereo PlayList (playlist that plays 3D images) to mono PlayList (playlist that plays 2D images), or from mono PlayList to stereo PlayList, the modes of graphics and background (Graphics mode and background mode) are set to predetermined initial values (predetermined initial values).

  FIG. 19 shows predetermined initial values of the graphics mode and the background mode.

  FIG. 20 illustrates graphics and background images that are played back when a 3D image (stereo image) of 1920 × 2160 pixels is played back.

  As graphics, a 3D image of 1920 × 2160 pixels is reproduced, and as a background, a 3D image of 1920 × 2160 pixels is reproduced.

  [Configuration change when BD-J application calls API (dynamic change)]

  In principle, the following three rules # 3-1, # 3-2, and # 3-3 are applied to change the configuration when an API is called by a BD-J application.

  That is, rule # 3-1 is a rule that in the configuration (device plane), the resolution (image frame) of the three images of Graphics, Video, and Background must always be the same resolution. is there.

  According to Rule # 3-2, when PlayList playback is performed in addition to KEEP_RSOLUTION playback, the resolution (image frame) of the three images of Graphics, Video, and Background must match the video resolution in the configuration. This is the rule.

  Rule # 3-3 is a rule that when the graphics is QHD graphics in the configuration, the resolution after scaling by 2 times in the vertical direction and 2 times in the horizontal direction is set as the resolution of the configuration. .

  FIG. 21 is a diagram for explaining a change in resolution (image frame) as a configuration by calling an API by a BD-J application.

  When the resolution of the graphics 3D image is changed by calling an API during the playback of the graphics 3D image (stereo G), video 3D image (stereo V), and background 3D image (stereo B) The 3D-compatible BD player automatically changes the resolution of the video 3D image and the background 3D image in accordance with the rules # 3-1, # 3-2, and # 3-3 described above.

  In addition, the resolution of the background 3D image is changed by calling an API during playback of the graphics 3D image (stereo G), video 3D image (stereo V), and background 3D image (stereo B). In this case, the 3D-compatible BD player automatically changes the resolution of the graphics 3D image and video 3D image according to the rules # 3-1, # 3-2, and # 3-3 described above. To do.

  Furthermore, during the playback of graphics 3D images (stereo G), video 3D images (stereo V), and background 3D images (stereo B), the resolution of the video 3D image is changed by calling an API. In this case, the 3D-compatible BD player automatically changes the resolution of the graphics 3D image and background 3D image according to the rules # 3-1, # 3-2, and # 3-3 described above. To do.

  [Change of plane configuration mode (change of graphics mode, video mode, and background mode)]

  The 3D-compatible player can seamlessly change (switch) the graphics mode between the stereo graphics mode (stereo graphics) and the offset graphics mode (offset graphics).

  FIG. 22 is a diagram illustrating the change of the graphics mode.

  FIG. 22A shows a graphics 3D image (plane offset gfx (graphics)), video (and PG) 3D image (stereo video + PG), and background 3D image (stereo background) in playback in the offset graphics mode. This shows a case where the graphics mode is changed from the offset graphics mode to the stereo graphics mode.

  In this case, from the playback of graphics 3D image (plane offset gfx) in offset graphics mode, video (and PG) 3D image (stereo video + PG), background 3D image (stereo background), in stereo graphics mode The graphics 3D image (stereo gfx (graphics)), the video (and PG) 3D image (stereo video + PG), and the background 3D image (stereo background) playback is switched, this switching, Can be done seamlessly.

  From the reverse switching, ie, playback of 3D graphics (stereo gfx) in stereo graphics mode, 3D image (stereo video + PG) of video (and PG), background 3D image (stereo background), offset graphics It is possible to seamlessly switch to playback of graphics 3D images (plane offset gfx), video (and PG) 3D images (stereo video + PG), and background 3D images (stereo background). .

  FIG. 22B shows the graphics mode during playback of a graphics 3D image (stereo gfx), a video (and PG) 3D image (stereo video + PG), and a background 2D image (mono background) in the stereo graphics mode. This shows a case where the stereo graphics mode is changed to the offset graphics mode.

  In this case, from playback of graphics 3D images (stereo gfx) in stereo graphics mode, video (and PG) 3D images (stereo video + PG), background 2D images (mono background), in offset graphics mode Switching to playback of graphics 3D images (plane offset gfx), video (and PG) 3D images (stereo video + PG), and background 2D images (mono background) is performed seamlessly. be able to.

  From reverse switching, ie, playback of graphics 3D images (plane offset gfx) in offset graphics mode, video (and PG) 3D images (stereo video + PG), background 2D images (mono background), stereo You can seamlessly switch to graphics 3D images (stereo gfx), video (and PG) 3D images (stereo video + PG), and background 2D images (mono background) in graphics mode. .

  FIG. 23 illustrates a change of the graphics mode from the stereo graphics mode to the offset graphics mode.

  When the graphics mode is changed from the stereo graphics mode (stereo gfx) to the offset graphics mode (Plane offset gfx), the video (L / R (Left / Right) video) and background (L / R (Left The playback of / Right) background) continues.

  On the other hand, for graphics, the playback target is switched from a graphics 3D image (stereo gfx) in the stereo graphics mode to a graphics 3D image (plane offset gfx) in the offset graphics mode.

  The implementation of how to switch the playback target depends on the individual 3D-compatible player. However, it should be avoided that the so-called black-out or AV (video) playback is interrupted when switching the playback target.

  If the resolution is also changed when changing the graphics mode, blackout may occur.

  Next, the 3D-compatible player can seamlessly change (switch) the background mode between the stereo background mode (stereo background) and the mono background mode (mono background).

  FIG. 24 is a diagram for explaining the change of the background mode.

  FIG. 24A shows a background during playback of a graphics 3D image (stereo gfx), a video (and PG) 3D image (stereo video + PG), and a background 3D image (stereo background) in stereo background mode. This shows a case where the mode is changed from the stereo background mode to the mono background mode.

  In this case, from the playback of graphics 3D images (stereo gfx), video (and PG) 3D images (stereo video + PG), background 3D images (stereo background) in stereo background mode, graphics 3D images (stereo gfx), video (and PG) 3D images (stereo video + PG), and switching to playback of background 2D images (mono background) in mono background mode, this switching is seamless It can be carried out.

  The reverse switching can also be performed seamlessly.

  FIG. 24B shows a graphics 3D image (plane offset gfx), a video (and PG) 3D image (stereo video + PG), and a background 2D image (mono background) in mono background mode. This shows a case where the ground mode is changed from the mono background mode to the stereo background mode.

  In this case, from playback of graphics 3D image (plane offset gfx), video (and PG) 3D image (stereo video + PG), background 2D image (mono background) in mono background mode, graphics 3D Switching to playback of images (plane offset gfx), video (and PG) 3D images (stereo video + PG), background 3D images (stereo background) in stereo background mode, this switching is Can be done seamlessly.

  The reverse switching can also be performed seamlessly.

  Next, the 3D-compatible player changes (switches) the video mode between the stereo video mode (stereo video), the flat stereo video mode (flattened-stereo video), and the dual-mono video mode (dual-mono video). Can be done seamlessly.

  FIG. 25 is a diagram for explaining the change of the video mode.

  FIG. 25A is a diagram for explaining video mode change when a video image is reproduced together with a graphics 3D image (stereo gfx) and a background 3D image (stereo background).

  When the video mode is the stereo video mode and the 3D image (stereo video + PG) of the video (and PG) in the stereo video mode is being played back, the video mode is changed from the stereo video mode to the flat stereo video mode. The video image is changed from a 3D image (stereo video + PG) of the video (and PG) in the stereo video mode to a 3D image (and flattened video + of the video (and PG) in the flat stereo video mode. PG) is switched, but this switching can be performed seamlessly.

  The reverse switching can also be performed seamlessly.

  In addition, when the video mode is the flat stereo video mode and a 3D image (flattened video + PG) of the video (and PG) in the flat stereo video mode is being played back, the video mode is changed from the flat stereo video mode. When switched to dual mono video mode, the video image will change from video (and PG) 3D image (flattened video + PG) in flat stereo video mode to video (and PG) in dual mono video mode Switching to a 3D image (dual-mono video + PG) is possible, but this switching can be performed seamlessly.

  The reverse switching can also be performed seamlessly.

  FIG. 25B is a diagram for describing video mode change when a video image is reproduced together with a graphics 3D image (plane offset gfx) and a background 2D image (mono background).

  When the video mode is a dual mono video mode and a 3D image (dual-mono video + PG) of a video (and PG) in the dual mono video mode is being played back, the video mode is changed from the dual mono video mode. When changed to flat stereo video mode, the video image is from video (and PG) 3D image (dual-mono video + PG) in dual video mode, video (and PG) in flat stereo video mode The 3D image (flattened video + PG) is switched to, but this switching can be performed seamlessly.

  The reverse switching can also be performed seamlessly.

  In addition, when the video mode is the flat stereo video mode and a 3D image (flattened video + PG) of the video (and PG) in the flat stereo video mode is being played back, the video mode is changed from the flat stereo video mode. When switched to stereo video mode, the video image will change from 3D image of video (and PG) in flat stereo video mode (flattened video + PG) to 3D image of video (and PG) in stereo video mode Switching to (stereo video + PG) is possible, but this switching can be performed seamlessly.

  The reverse switching can also be performed seamlessly.

  [3D-compatible player whose configuration is changed]

  In the current BD standard, the configuration is defined by resolution (image frame) and color depth. For this reason, changing the configuration changes the resolution. However, when the resolution is changed, playback is temporarily stopped and the display screen is blacked out.

  On the other hand, for example, the playback mode of the graphics plane mono-logical-plane + offset value can be specified as a 1920 × 1080 / 32bpp configuration, but in this case, for example, mono-logical-plane + offset value There is a possibility that blackout is induced by switching from stereo to logical-plane.

  Therefore, in 3D-compatible players, the plane configuration is unified into two plane definitions (1920 x 2160 pixels, 1280 x 1440 pixels, (960 x 1080 pixels), 720 x 960 pixels, 720 x 1152 pixels), and resolution / color Define attributes other than depth as mode values. Then, when only the mode is changed without changing the resolution, the configuration can be changed without setting the display screen in a blackout state. Further, like the legacy player, the configuration can be changed by calling the Configuration Preference setting API.

  FIG. 26 is a block diagram illustrating a functional configuration example of the BD player in FIG. 3 as such a 3D-compatible player.

  In the 3D-compatible player in FIG. 26, an L area that is a storage area for one image that stores an image for the left eye and an R area that is a storage area for one image that stores an image for the right eye. A configuration of a device plane, which is a storage area in which storage areas for two image planes are arranged side by side, is defined for the entire device plane.

  In addition, five modes of a mono graphics mode, a stereo graphics mode, an offset graphics mode, a forced mono graphics mode, and a flat stereo graphics mode are defined as graphics modes. Further, five modes of a mono video mode, a dual mono video mode, a stereo video mode, a forced mono video mode, and a flat stereo video mode are defined as video modes. As the background mode, five modes of a mono background mode, a dual mono background mode, a stereo background mode, a forced mono background mode, and a flat stereo background mode are defined.

  The configuration of the device plane includes (1) image frame (resolution) and color depth, (2) video mode, (3) graphics mode, and (4) background mode. The setting (change) of the video mode, (3) graphics mode, and (4) background mode can be performed by the configuration mode setting API.

  In the 3D-compatible player in FIG. 26, when the video mode, the graphics mode, or the background mode is changed, the BD-J application calls the configuration mode setting API, and the video mode, the graphics mode, or Request background mode change (setting).

  In response to a request from the BD-J application, the configuration mode setting API directly selects the necessary ones from the presentation engine, the video decoder, and the display processor. Alternatively, the video mode, the graphics mode, or the background mode is changed (set) by controlling indirectly.

  On the other hand, when changing the image frame (resolution) and the color depth, the BD-J application calls the resolution setting API and requests a change (setting) of the resolution or the like.

  The resolution setting API controls the necessary ones of the presentation engine, video decoder, and display processor directly or indirectly according to the request from the BD-J application. And change (set) the color depth.

  In FIG. 26, a presentation engine (Presentation Engine) is a playback control engine (Playback) (not shown) that controls the playback of BDs by decoding audio and video and HDMV graphics and presentation functions (Presentation functions). To the Control Engine).

  In FIG. 26, a video decoder performs video decoding. In addition, the display processor superimposes the graphics plane, video (video + PG) plane, and background plane, and then displays the resulting image on the display connected to the BD player. The hardware to output.

  As described above, the device plane configuration is defined for the entire device plane, which is an image storage area for two surfaces, and the resolution (image frame) and color depth are defined in the device plane configuration. Separately, graphics mode etc. are included. The 3D-compatible player sets the graphics mode and the like by calling the configuration mode setting API. In this way, the graphics mode and the like can be changed without changing the resolution.

  [Switch PG / Text subtitle configuration]

  From the BD-J application, Video + PG / TextST (Text subtitle) is handled as a group (without distinction). Further, the BD-J application cannot control the PG plane 12 individually, but can control the position and scaling (size) of the video. In the current BD standard, when video position and scaling are controlled from a BD-J application, PG / TextST is aligned with video.

  Therefore, when video scaling control is performed, the PG plane offset value is scaled by a scaling ratio (enlargement ratio or reduction ratio) for scaling the video.

  On the other hand, in a 3D-compatible player, as a playback mode for playing back PG (including TextST), a mode for playing back a PG image of a mono image that is a 2D image (1-plane (legacy playback)), A 3D image PG is generated by a mode (2-planes) for reproducing a PG image of a certain stereo image, and a left eye image and a right eye image (with parallax) generated from a 2D image and an offset value. It is desirable to be able to set the mode (1-plane + offset) for playing

  Therefore, a 3D-compatible player indirectly performs PG plane control (configuration switching between 1-plane (legacy playback), 1-plane + offset, and 2-planes) by selecting a PG stream. .

  Therefore, for HDMV PG, as a PG stream of a PG image of a BD standard, a PG stream of a PG image of a mono image that is a 2D image, a PG stream of a stereo image that is a 3D image, A stereo PG stream, and an offset PG stream that is a PG stream of a mono image PG used to generate a stereo image together with an offset value that gives parallax to the mono image (e.g., a mono image PG Stream including the image and the offset value).

  Furthermore, for HDMV PG, a mono 1-stream (legacy content) mode, an L / R 2 stream mode, and a 1-stream + plane-offset mode are defined as PG playback modes for playing back PG images.

  Here, when the PG playback mode is the mono 1-stream mode, a 2D PG image is played back using the mono PG stream.

  When the PG playback mode is the L / R 2 stream mode, a 3D PG image is played by playing back the left-eye image and the right-eye image using the stereo PG stream.

  When the PG playback mode is the 1-stream + plane-offset mode, a left-eye image and a right-eye image are generated based on the offset value using the offset PG stream, and the left-eye image is generated. And the right-eye image are reproduced, and the 3D PG image is reproduced.

  As for HDMV TextST, TextST stream of BD standard TextST image, TextST stream of TextST image of TextST image of mono image that is 2D image, TextST stream of TextST image of stereo image that is 3D image A stereo TextST stream, and an offset TextST stream that is a TextST stream of a mono image TextST image used to generate a stereo image, together with an offset value that gives parallax to the mono image (e.g., a mono image TextST stream Stream including the image and the offset value).

  Furthermore, for HDMV TextST, the mono 1-stream (legacy content) mode, L / R 2 stream mode, and 1-stream + plane-offset mode are defined as TextST playback modes for playing back TextST images.

  Here, when the TextST playback mode is the mono 1-stream mode, a 2D TextST image is played back using the mono TextST stream.

  When the TextST playback mode is the L / R 2 stream mode, a 3D TextST image is played back by playing back a left-eye image and a right-eye image using a stereo TextST stream.

  When the TextST playback mode is 1-stream + plane-offset mode, the left-eye image and right-eye image are generated based on the offset value using the offset TextST stream, and the left-eye image is generated. By replaying the right eye image, the 3D image TextST image is replayed.

  A 3D-compatible player can switch (set) the PG / TextST configuration through an API for selecting a stream.

  FIG. 27 shows a PG playback mode and a TextST playback mode that can be selected in each video mode.

  For HDMV PG, the video mode (configuration) is mono video mode (mono), flat stereo video mode (flattened stereo), dual mono video mode (dual-mono), forced mono video mode (forced-mono), and In any case of the stereo video mode (stereo), it is possible to select the 1-stream + plane-offset mode (mono + offset) (offset PG stream).

  Therefore, the offset PG stream can be selected regardless of whether the video mode is a mono video mode, a flat stereo video mode, a dual mono video mode, a forced mono video mode, or a stereo video mode. is there.

  For HDMV PG, the video modes are flat stereo video mode (flattened stereo), dual mono video mode (dual-mono), forced mono video mode (forced-mono), and stereo video mode (stereo). In either case, it is possible to select the L / R 2 stream mode (stereo) (stereo PG stream).

  Therefore, the stereo PG stream can be selected regardless of whether the video mode is any of the flat stereo video mode, the dual mono video mode, the forced mono video mode, and the stereo video mode.

  However, when the video mode is mono video mode (mono), flat stereo video mode (flattened stereo), forced mono video mode (forced-mono), or dual mono video mode (dual-mono), the offset PG When the stream (mono + offset) is selected, the mono image of the offset PG stream is reproduced ignoring the offset value (with the offset value set to 0).

  If the stereo PG stream (stereo) is selected when the video mode is mono video mode (mono) or forced mono video mode (forced-mono), a stereo image corresponding to the stereo PG stream is configured. Only the left-eye image and the right-eye image, for example, the left-eye image (LPG stream) are reproduced.

  Further, when the video mode is the flat stereo video mode or the dual mono video mode, when a stereo PG stream is selected, the stream number that is a number assigned to the stream matches the selected stereo PG stream. If there is an offset PG stream (if it is recorded on the BD), instead of the selected stereo PG stream, the mono image of the offset PG stream having the same stream number as the stereo PG stream has an offset value. Ignored and played.

  On the other hand, for HDMV TextST, the video mode (configuration) is mono video mode (mono), flat stereo video mode (flattened stereo), forced mono video mode (forced-mono), and dual mono video mode (dual- In any case of mono), it is possible to select 1-stream + plane-offset mode (mono + offset) (text subtitle stream for offset).

  Therefore, the offset TextST stream (offset Text subtitle stream) should be selected when the video mode is one of the mono video mode, flat stereo video mode, forced mono video mode, or dual mono video mode. Is possible.

  For HDMV TextST, the video modes are flat stereo video mode (flattened stereo), dual mono video mode (dual-mono), forced mono video mode (forced-mono), and stereo video mode (stereo). In either case, it is possible to select the L / R 2 stream mode (stereo) (stereo text subtitle stream).

  Therefore, a stereo TextST stream (stereo text subtitle stream) should be selected regardless of whether the video mode is a flat stereo video mode, a dual mono video mode, a forced mono video mode, or a stereo video mode. Is possible.

  However, when the video mode is mono video mode (mono), flat stereo video mode (flattened stereo), forced mono video mode (forced-mono), or dual mono video mode (dual-mono), TextST for offset When the stream (mono + offset) is selected, the mono image of the offset TextST stream is reproduced ignoring the offset value.

  Also, when the video mode is mono video mode (mono) or forced mono video mode (forced-mono) and stereo TextST stream (stereo) is selected, a stereo image corresponding to the stereo TextST stream is configured. For example, only the left-eye image (L TextST stream) that is one of the left-eye image and the right-eye image is reproduced.

  Further, when the video mode is the flat stereo video mode or the dual mono video mode, when a stereo TextST stream is selected, the stream number, which is the number assigned to the stream, matches the selected stereo TextST stream. If there is an offset TextST stream, instead of the selected stereo TextST stream, a mono image of the offset TextST stream having the same stream number as that stereo TextST stream is reproduced while ignoring the offset value.

  FIG. 28 is a block diagram illustrating a functional configuration example of the BD player in FIG. 3 as a 3D-compatible player that reproduces the PG or TextST image as described above.

  In FIG. 28, the 3D-compatible player includes a BD-J application, a PG / TextST stream selection API, a video control API, a PG selection engine (Playback Control Function), a TextST selection engine (Playback Control Function), and a video control engine (Playback Control Function). ), A playback control engine, a presentation engine, and the like.

  With reference to FIG. 29, the processing of the 3D-compatible player in FIG. 28 will be described using the processing for PG as an example.

  The BD-J application calls the PG / TextST stream selection API and requests selection of the PG stream. The PG / TextST stream selection API selects a PG stream requested from the BD-J application.

  That is, as described with reference to FIG. 27, if the PG / TextST stream selection API can select the PG stream requested from the BD-J application for the current video mode, Control the PG selection engine to select.

  The PG selection engine selects a PG stream in accordance with the control of the PG / TextST stream selection API from the PG streams recorded on the disc 100 (FIG. 3), which is a BD, and is not shown in FIG. It supplies to PG decoder (stereo PG decoder) or a mono PG decoder (mono PG decoder).

  Here, when the PG stream selected by the PG selection engine is a stereo PG stream, the stereo PG stream is supplied to the stereo PG decoder.

  When the PG stream selected by the PG selection engine is an offset PG stream, the offset PG stream is supplied to the mono PG decoder.

  The stereo PG decoder decodes the PG stream supplied from the PG selection engine into a left-eye image and a right-eye image that form a stereo image, and an L-PG plane 12L and an R-PG plane 12R of the PG plane 12 Draw each.

  On the other hand, the mono PG decoder decodes the offset PG stream supplied from the PG selection engine into a mono image and draws it on the logical plane 10.

  The PG generation API uses an offset value (for example, an offset value included in the offset PG stream, an internal storage area of a 3D-compatible player, or an offset stored in PSR # 21 from a mono image drawn on the logical plane 10. Value) is used to generate a left-eye image and a right-eye image. The PG generation API draws the left-eye image and the right-eye image on the L-PG plane 12L and the R-PG plane 12R of the PG plane 12, respectively.

  In the 3D-compatible BD player, as described with reference to FIG. 27, depending on the combination of the current video mode and the PG stream (PG playback mode) selected by the PG selection engine, a stereo image corresponding to the stereo PG stream is displayed. One of the left-eye image and the right-eye image, for example, only the left-eye image is reproduced or the offset value is ignored, and the mono image corresponding to the offset PG stream Only may be played.

  As described above, in a 3D-compatible player, as a PG stream of a BD standard PG image, a mono PG stream that is a PG stream of a mono image that is a 2D image and a PG stream of a stereo image that is a 3D image A stereo PG stream that is a PG stream of an image, an offset PG stream that is a PG stream of a mono PG image, and an offset value that is data that gives parallax to the mono image Is defined. Then, the PG / TextST stream selection API selects a mono PG stream, a stereo PG stream, or an offset PG stream in accordance with a request from the BD-J application.

  Therefore, it is possible to indirectly control PG image reproduction (PG configuration) from the BD-J application.

  [Switch between 3D image playback and 2D image playback]

  FIG. 30 is a diagram illustrating switching between 3D image playback and 2D image playback in a 3D-compatible player.

  In FIG. 30, first, the operation mode of the 3D-compatible player is a 3D playback mode for playing back 3D images.

  The graphics mode is stereo graphics mode (stereo gfx (graphics)), the video mode is stereo video mode (stereo video), the background mode is mono background mode (mono background), respectively. .

  Thereafter, the graphics mode is changed to an offset graphics mode (plane offset gfx), and the video mode is changed to a dual mono video mode (dual-mono video).

  Furthermore, in FIG. 30, the operation mode is changed from the 3D playback mode to the 2D playback mode (Legacy playback mode) for playing back 2D images in the same manner as the legacy player.

  Along with the change of the operation mode, the graphics mode is changed from the offset graphics mode (plane offset gfx) to the mono graphics mode (mono gfx). Furthermore, the video mode is changed from the dual mono video mode (dual-mono video) to the mono video mode (mono video). The background mode remains the mono background mode (mono background).

  In FIG. 30, the operation mode is changed again from the 2D playback mode to the 3D playback mode.

  In accordance with the change of the operation mode, the graphics mode is changed from the mono graphics mode (mono gfx) to the stereo graphics mode (stereo gfx). Furthermore, the video mode is changed from the mono video mode (mono video) to the flattened stereo video mode (flattened stereo video). The background mode remains the mono background mode (mono background).

  In FIG. 30, after that, the background mode is changed from the mono background mode (mono background) to the stereo background mode (stereo background).

  In FIG. 30, for example, when the operation mode is changed from the 3D playback mode to the 2D playback mode, if the resolution (image frame) is changed, the display screen may be blacked out.

  [Pixel coordinate system for video]

  To control the position and size of video from a BD-J application, JMF (Java Media Framework) control such as "javax.tv.media.AWTVideoSizeControl" or "org.dvb.media.BackgroundVideoPRsentationControl" Can be used.

  Note that the author of the BD-J application sets the position and size of the video not by coordinates on the plane (video plane 13) but by display coordinates.

In addition, the 3D-compatible player must correct the position and size of each of the left-eye image (L video source) and the right-eye image (R video source).

For example, for a video plane 13 of 1920 × 2160 pixels, the display coordinate system is a coordinate system having a size of 1920 × 1080 pixels whose vertical direction is ½. In this case, the author must set the position and size of the video as follows, for example.

RctangL src = new RctangL (0,0,1920,1080);
RctangL dest = new RctangL (100,100,960,540);
AWTVideoSizeControl videoSizeControl = (AWTVideoSizeControl) player.getControl ("javax.tv.media.AWTVideoSizeControl");
videoSizeControl.setSize (new AWTVideoSize (src, dest));

  FIG. 31 is a diagram illustrating the setting of the video position and size by the author, and the correction of the video position and size by the 3D-compatible player.

  The author sets the position and size of the left eye image of the video. In FIG. 31, the position and size of the video image for the left eye are set for a display coordinate system having a size of 1920 × 1080 pixels.

  The 3D-compatible player sets the position and size of the video left-eye image relative to the display coordinate system in the L video plane 13L of the video plane 13 as they are.

  Furthermore, the 3D-compatible player applies the video position and size settings of the L video plane 13L to the R video plane 13R as they are.

  Therefore, from the viewpoint of the author, by setting the video position and size for the L video plane 13L, the same position and size as the video position and size are also set for the R video plane 13R.

  Here, the depth information is not given from the outside regarding the video. Therefore, the mechanism for adding the offset is not only useless, but also causes unintended output by the video producer.

  That is, the video producer should produce an image of the video so that the intended 3D image is displayed. Therefore, in a 3D-compatible player, for example, a video image (left-eye image and left-eye image) drawn on the video plane 13 by externally applied information such as an offset value stored in PSR # 21 (FIG. 7). If processing such as shifting the position of the image for the right eye) is performed, an image unintended by the video producer may be displayed.

  Therefore, in the 3D-compatible player, the L / R video plane is defined on the configuration, but the author of the BD-J application is restricted so that only the L video plane can be handled. That is, the 3D-compatible player must apply the L video scaling / L video positioning API call by the BD-J application to the R video scaling / R video positioning as it is.

  Note that if the video is scaled to that size by setting the video size, the PG plane offset value is the scaling that scales the video, as described in [Switching PG / Text subtitle configuration]. Although scaled by a ratio (magnification or reduction), the graphics plane offset value is similarly scaled by the video scaling ratio.

  FIG. 32 is a block diagram illustrating a functional configuration example of the BD player in FIG. 3 as a 3D-compatible player that performs video position setting (correction) and size setting (scaling) as described above.

  The 3D-compatible player in FIG. 32 has an image size stored in the L video plane 13L (L area), an L API for setting the position, and an image size stored in the R video plane 13R (R area). And an R API for setting the position. One API of the L API and the R API sets the same size and position as the image size and position set by the other API.

  That is, in the 3D-compatible player in FIG. 32, the video decoder decodes the video, and the resulting left-eye image and right-eye image are converted into the L API and the R API. Supply.

  The API for L consists of the L video scaling (L (Left) video scaling) API and the L video positioning (L (Left) positioning) API, and requests for setting the position and size of the video from the BD-J application. Is set to the position and size of the left-eye image from the video decoder.

  That is, the L video scaling API performs scaling for controlling the size of the image for the left eye from the video decoder to a size according to a request from the BD-J application, and supplies it to the L video positioning API.

  The L video positioning API controls the position of the image for the left eye from the L video scaling API to a position according to the request from the BD-J application, and the resulting image for the left eye is transferred to the L video plane 13L. Draw (draw the image for the left eye from the L video scaling API at a position on the L video plane 13L in response to a request from the BD-J application).

  In addition, the L video scaling API calls an R video scaling API described later and makes a request similar to that of the BD-J application. Further, the L video positioning API calls an R video positioning API, which will be described later, and makes a request similar to the request from the BD-J application.

  In addition, the L video scaling API sets the scaling ratio (enlargement ratio or reduction ratio) S when the video image (the image for the left eye) is scaled in response to a call for setting the video size. Supply to the generation API and graphics generation API.

  The R API consists of the R video scaling (R (Right) video scaling) API and the R video positioning (R (Right) positioning) API, and can be used to request video position and size settings from the L API. In response, the position and size of the right-eye image from the video decoder are set.

  That is, the R video scaling API controls the size of the image for the right eye from the video decoder to a size according to a request from the L video scaling API and supplies it to the R video positioning API.

  The R video positioning API controls the position of the right eye image from the R video scaling API to a position according to the request from the L video positioning API, and the resulting right eye image is transferred to the R video plane 13R. draw.

  As described above, the size of the image stored in the L video plane 13L (L region) and the API for L for setting the position, the size of the image stored in the R video plane 13R (R region), and The API for R that sets the position is one API, for example, the API for R is the size of the image that the API for L that is the other API sets in response to a request from the BD-J application, The same size and position as the position are set.

  Therefore, the author can handle only the L video plane 13L, which is one of the L video plane 13L (L region) and the R video plane 13R (R region), for the video plane 13 that stores the BD standard video image. It is possible to prevent a video image unintended by the video producer from being displayed.

  In the 3D-compatible player, the processing described in FIG. 29 is further performed on PG.

  However, in the PG generation API, the PG plane offset value (for example, the offset value included in the offset PG stream, the internal storage area of the 3D-compatible player, or PSR # 21 is used with the scaling ratio S from the L video scaling API. The stored offset value) is scaled (the PG plane offset value is multiplied by the scaling ratio S).

  In the PG generation API, a left-eye image and a right-eye image are generated from the mono image drawn on the logical plane 10 using the scaled PG plane offset value.

  Further, in the 3D-compatible player, the configuration mode change API selects a graphics mode image in response to a request from the BD-J application from graphics images recorded on the disc 100 (FIG. 3) as a BD, Draw on the graphics plane 11.

  That is, when the video mode is, for example, a stereo graphics mode, a left-eye image and a right-eye image of a graphics that is a stereo image are respectively an L graphics plane 11L and an R graphics plane 11R of the graphics plane 11. Drawn on.

  Further, when the video mode is, for example, the offset graphics mode, a graphics image that is a mono image is drawn on the logical plane 10, and the graphics generation API has a scaling ratio S from the L video scaling API. The graphics plane offset value (for example, the internal storage area of the 3D-compatible player or the offset value stored in PSR # 21) is scaled.

  Then, the graphics generation API generates an image for the left eye and an image for the right eye from the mono image drawn on the logical plane 10 using the scaled graphics plane offset value, and the L graphics plane 11L and the R graphics plane. Each is drawn on 11R.

  [Pixel coordinate system for graphics]

The effective pixel coordinate system for stereo graphics configuration (configuration for displaying graphics 3D images) is
(0, 0)-(1920, 2160)
(0, 0)-(1280, 1440)
(0, 0)-(720, 960)
(0, 0)-(720, 1152)
(0, 0)-(960, 1080)
One of them.

  top-half is assigned to L graphics view and bottom-half is assigned to R graphics view.

  FIG. 33 shows a graphics plane 11 having 1920 × 2160 pixels.

  The image drawn on the L graphics plane 11L that is the upper storage area (top-half) of the graphics plane 11 becomes a left-eye image (L (Left) graphics view) that is observed with the left eye. An image drawn on the R graphics plane 11R, which is the lower storage area (bottom-half), is an image for the right eye (R (Right) graphics view) that is observed with the right eye.

  In FIG. 33, one container (Root container) and two components (Components) that are children of the container are drawn on the graphics plane 11.

  The coordinates of a component are expressed by coordinates relative to the container that is the parent of the component.

  In the 3D-compatible player, a buffer area for guard purposes should not be provided at the edge of the graphics plane 11.

  In addition, 3D-compatible players must introduce a mechanism to prevent inconsistencies with L-view / R-view.

  Here, the BD player, which is a legacy player, does not have a mechanism for detecting completion of drawing by the BD-J application and transferring it to the monitor after completion. In the case of L / R video output, inconsistency of output may occur between L / R graphics.

  Therefore, in the 3D-compatible player, some API call is defined as a signal indicating completion of drawing by the BD-J application. Conversely, if the BD-J application does not call the corresponding drawing completion notification API, nothing is output to the screen. The author must use this method.

  That is, after the image (left-eye image) is drawn on the L graphics plane 11L and before the drawing of the image on the R graphics plane 11R is completed, the drawing contents of the graphics plane 11 are the same as the left-eye image and the right-eye. When the image is displayed on the display screen, the left-eye image and the right-eye image are not aligned so that they can be viewed as a 3D image (in this case, the right-eye image Since the drawing of the image is incomplete, the user who sees the image on the display screen feels uncomfortable.

  In this way, in order to prevent the user from feeling uncomfortable, the 3D-compatible player has a function of suppressing inconsistency between the left-eye image and the right-eye image, that is, to be viewed as a 3D image. It has a function of preventing the left-eye image and the right-eye image that are not in a matched state from being displayed on the display screen.

  Specifically, the 3D-compatible player displays the left-eye image and the right-eye image for display after the drawing of both the left-eye image and the right-eye image on the graphics plane 11 is completed. Output to.

  Therefore, the 3D-compatible player needs to recognize that the drawing of both the left-eye image and the right-eye image on the graphics plane 11 has been completed.

  [Direct-drawing model]

  In Direct-drawing, a 3D-compatible player has no way of knowing whether or not the issue of a drawing command for drawing a graphics image from a BD-J application has been completed.

  That is, when the BD-J application issues drawing commands # 1, # 2,..., #N and the image is drawn on the graphics plane 11 according to the drawing commands # 1 to #N. Thereafter, the 3D-compatible player cannot recognize whether or not a drawing command is further issued from the BD-J application, that is, whether or not the drawing command has been issued by the BD-J application.

  Therefore, the author of the BD-J application does not return the processing to the BD-J application until the drawing of the image on the graphics plane 11 is completed when drawing the image on the graphics plane 11 by the drawing command. The rendering integrity guarantee API call that guarantees the graphics rendering integrity is obligatory as signaling to the 3D-compatible player.

  Alternatively, when drawing an image on the graphics plane 11 using a drawing command, a call for a drawing completion notification API for notifying that drawing of an image on the graphics plane 11 has been completed is obligated as signaling to a 3D-compatible player.

  Alternatively, when drawing an image on the graphics plane 11 by using a drawing command, a drawing start notification API for notifying that drawing of an image on the graphics plane 11 is started, and subsequent drawing of the image on the graphics plane 11 are performed. Calling the drawing completion notification API for notifying the completion of the is required as signaling to the 3D-compatible player.

  In this case, the 3D-compatible player calls the graphics plane by calling the drawing integrity guarantee API by the BD-J application, calling the drawing completion notification API, or calling the drawing start notification API, and then calling the drawing completion notification API. 11 that the drawing of the image with respect to 11 has been completed, that is, the issue of the drawing command has been completed. As a result, it is possible to display the left-eye image and the right-eye image that are in a matched state (so as to be seen as a 3D image).

  Here, as the drawing integrity guarantee API, a dedicated API that takes a drawing command string as an argument can be defined.

  As the drawing completion notification API, for example, a java.awt.Toolkit # sync () method can be employed. In this case, the 3D-compatible player does not output the image drawn on the graphics plane 11 unless the java.awt.Toolkit # sync () method is called, and therefore the graphics plane 11 is displayed on the display screen. The image drawn on is not displayed.

  Furthermore, as the drawing start notification API, for example, a predetermined method of java (registered trademark) or a dedicated API can be defined.

  If the java.awt.Toolkit # sync () method is called multiple times during one frame (between 1-video and frame), the graphics-frame may drop frames. Therefore, do not call the java.awt.Toolkit # sync () method more than once in succession or continuously with a small amount of drawing.

  [Repaint model]

  In the AWT (Abstract Windowing toolkit) paint model, the repaint () method of the root container as a part constituting a graphics image calls the update () method of each component as a part constituting the graphics image.

  In the AWT paint model, the 3D-compatible player can completely control (full control) the graphics image drawing process, and the 3D-compatible player has finished drawing the image on the graphics plane 11. I can recognize that.

  Therefore, a 3D-compatible player is mounted so that the left-eye image and the right-eye image are displayed in an aligned state without calling the drawing completion notification API described above. be able to.

  FIG. 34 shows the drawing integrity guarantee API call by the BD-J application, the drawing completion notification API call, or the drawing start notification API call, and the subsequent drawing completion notification API call. FIG. 4 is a block diagram illustrating a functional configuration example of the BD player in FIG.

  Here, the BD-J application calls the drawing completion notification API when drawing of the image on the graphics plane 11 is completed.

  The 3D-compatible player includes buffers 201L and 201R as the graphics plane 11, and buffers 202L and 202R.

  In FIG. 34, the buffers 201L and 202L correspond to the L graphics plane 11L, and the buffers 201R and 202R correspond to the R graphics plane 11R.

  The set of buffers 201L and 201R and the set of buffers 202L and 202R alternately function as a back buffer (hidden buffer) and a front buffer.

  Here, the back buffer is a buffer in which graphics images are drawn from the BD-J application, and the front buffer is displayed on the display screen (logical screen 21) while the image is being drawn in the back buffer. This is a buffer for storing displayed images.

  FIG. 34A shows a 3D-compatible player in a state where the set of buffers 201L and 201R serves as a back buffer and the set of buffers 202L and 202R serves as a front buffer.

  In FIG. 34A, graphics images (left-eye image and right-eye image) are drawn by the BD-J application in the buffers 201L and 201R as back buffers, and the buffers 202L and 202R as front buffers are drawn. The images (left eye image and right eye image) stored in 202R are output as output to the display screen.

  The BD-J application calls the drawing completion notification API when drawing of the graphics image is finished in the buffers 201L and 201R serving as back buffers.

  When the drawing completion notification API is called, the 3D-compatible player starts outputting the image stored in the back buffer to the display screen instead of the front buffer.

  That is, FIG. 34B shows the 3D-compatible player immediately after the drawing completion notification API is called.

  When the drawing completion notification API is called, the 3D-compatible player stores the images stored in the buffers 201L and 201R serving as the back buffer instead of the images stored in the buffers 202L and 202R serving as the front buffer. Starts outputting the image to the display screen.

  Further, the 3D-compatible player copies the images stored in the buffers 201L and 201R serving as back buffers to the buffers 202L and 202R serving as front buffers.

  Thereafter, the 3D-compatible player switches the back buffer and the front buffer.

  That is, the 3D-compatible player sets the buffers 201L and 201R serving as back buffers as front buffers and the buffers 202L and 202R serving as front buffers as back buffers.

  That is, FIG. 34C shows a 3D-compatible player in a state where the set of buffers 201L and 201R serves as a front buffer, and the set of buffers 202L and 202R serves as a back buffer.

  The BD-J application starts drawing graphics images in the buffers 202L and 202R serving as back buffers, and the same processing is repeated thereafter.

  FIG. 35 is a flowchart for explaining graphics processing by the 3D-compatible player in FIG. 34 when the BD-J application calls the drawing integrity guarantee API.

  In step S11, the 3D-compatible player determines whether or not the drawing integrity guarantee API has been called from the BD-J application. If it is determined that there is no drawing integrity, the process returns to step S11.

  If it is determined in step S11 that the drawing integrity guarantee API has been called, the process proceeds to step S12, and the 3D-compatible player sequentially executes the drawing command sequence that is an argument of the drawing integrity guarantee API, The graphics image obtained as a result of the execution is drawn in the back buffer, and the graphics image stored in the front buffer is output to the display screen (output for display).

  Thereafter, after the drawing to the back buffer is completed, the 3D-compatible player outputs the graphics image stored in the back buffer on the display screen instead of the front buffer (output for display) in step S13. To do).

  In step S14, the 3D-compatible player copies the graphics image stored in the back buffer to the front buffer.

  Thereafter, the 3D-compatible player switches the back buffer and the front buffer in step S15, returns to step S11, and thereafter the same processing is repeated.

  As described above, in a 3D-compatible player, when a BD-J application calls a rendering integrity guarantee API that guarantees the rendering integrity of graphics images for the graphics plane 11 (which is a back buffer). In addition, an image drawn on the graphics plane 11 is output for display.

  Therefore, the image drawn on the graphics plane 11 can be displayed after waiting for the graphics image drawing by the 3D-compatible player to be completed. It is possible to prevent the ophthalmic image from being displayed on the display screen.

  FIG. 36 is a flowchart for describing graphics processing by the 3D-compatible player in FIG. 34 when the BD-J application calls the drawing completion notification API.

  The 3D-compatible player waits for a drawing command issued from the BD-J application, and executes the drawing command in step S21.

  In step S22, the 3D-compatible player draws the graphics image obtained as a result of executing the drawing command in the back buffer, and outputs the graphics image stored in the front buffer to the display screen (display). Output for).

  Thereafter, in step S23, the 3D-compatible player determines whether a drawing completion notification API has been called from the BD-J application.

  If it is determined in step S23 that the drawing completion notification API has not been called, the process returns to step S21 after waiting for the issuance of a drawing command from the BD-J application, and the same processing is repeated thereafter.

  If it is determined in step S23 that the drawing completion notification API has been called, the 3D-compatible player proceeds to step S24, and displays the graphics image stored in the back buffer instead of the front buffer. Output to (output for display).

  In step S25, the 3D-compatible player copies the graphics image stored in the back buffer to the front buffer.

  Thereafter, in step S26, the 3D-compatible player switches the back buffer and the front buffer, waits for the issuance of a drawing command from the BD-J application, returns to step S21, and thereafter the same processing is repeated.

  As described above, in the 3D-compatible player, when the BD-J application calls the drawing completion notification API that notifies the graphics plane 11 (that is, the back buffer) that drawing of the graphics image has ended. In addition, an image drawn on the graphics plane 11 is output for display.

  Accordingly, since the image drawn on the graphics plane 11 can be displayed after the notification that the drawing of the graphics image by the BD-J application has been completed, the left that is not in a consistent state is displayed. It is possible to prevent the image for the eye and the image for the right eye from being displayed on the display screen.

  FIG. 37 is a flowchart for describing graphics processing by the 3D-compatible player in FIG. 34 when the BD-J application calls the drawing start notification API and then calls the drawing completion notification API.

  In step S31, the 3D-compatible player determines whether or not the drawing start notification API is called from the BD-J application. If it is determined that the drawing start notification API has not been called, the process returns to step S31.

  If it is determined in step S31 that the drawing start API has been read, the 3D-compatible player waits for a drawing command issued from the BD-J application, proceeds to step S32, and executes the drawing command.

  Thereafter, in step S33, the 3D-compatible player determines whether a drawing completion notification API has been called from the BD-J application.

  If it is determined in step S33 that the drawing completion notification API has not been called, the process returns to step S32 after waiting for the issuance of a drawing command from the BD-J application, and the same processing is repeated thereafter.

  If it is determined in step S33 that the drawing completion notification API has been called, the 3D-compatible player proceeds to step S34 to draw the graphics image obtained as a result of the execution of the drawing command in the back buffer. The graphics image stored in the front buffer is output to the display screen (output for display).

  Thereafter, in step S35, the 3D-compatible player outputs the graphics image stored in the back buffer on the display screen instead of the front buffer (outputs for display).

  In step S36, the 3D-compatible player copies the graphics image stored in the back buffer to the front buffer.

  Thereafter, the 3D-compatible player switches the back buffer and the front buffer in step S37, returns to step S31, and thereafter the same processing is repeated.

  As described above, in the 3D-compatible player, the calling of the drawing start notification API for starting the drawing of the graphics image to the graphics plane 11 (that is, the back buffer) and the subsequent drawing of the graphics image are completed. When the drawing completion notification API that notifies this is called from the BD-J application, an image drawn on the graphics plane 11 is output for display.

  Accordingly, since the image drawn on the graphics plane 11 can be displayed after the notification that the drawing of the graphics image by the BD-J application has been completed, the left that is not in a consistent state is displayed. It is possible to prevent the image for the eye and the image for the right eye from being displayed on the display screen.

  [Pixel coordinate system for background]

The effective pixel coordinate system in the stereo background configuration (configuration that displays a 3D background image) is
(0, 0)-(1920, 2160)
(0, 0)-(1280, 1440)
(0, 0)-(720, 960)
(0, 0)-(720, 1152)
One of them.

  top-half is assigned to L background view and bottom-half is assigned to R background view.

  The background image format (Contents format) is one of single-color, JPEG (JFIF), or MPEG2 drip-feed, and the format is MPEG2 drip-feed. In this case, the background image must be an SD image (SD video only).

  Further, as a background image, a JPEG (JFIF) image having 1920 × 2160 pixels, 1280 × 1440 pixels, 720 × 960 pixels, or 720 × 1152 pixels can be used.

  [Focus management]

  For example, when a widget-based GUI (Graphical User Interface) or the like is adopted as a graphics image, in a legacy player, a plurality of components that are children of a container are included in the GUI at a time. You can't have focus.

  Further, in the legacy player, a plurality of root containers constituting the GUI cannot be activated at a time (in a focused state).

  Here, a container is a component (part) of a graphics image and can have a parent (upper layer) and a child (lower layer). A container that has no children and only children is called a root container.

  A component is a type of container that can have a parent but cannot have children.

  When the GUI as a graphics image is a 3D image, each of the left-eye image and the right-eye image constituting the 3D image has a focus on the corresponding container, and the focus transition is the same ( Equivalent).

  That is, a container constituting one of the left-eye image and right-eye image is focused, but the container constituting the other image corresponding to that container is not focused. In this case, the user who sees the 3D image displayed by the left-eye image and the right-eye image feels uncomfortable.

  In this way, in order to prevent the user from feeling uncomfortable, the 3D-compatible player ensures that the focus transition is the same between the container for the left eye image and the container for the right eye image. , Manage focus.

  FIG. 38 shows an example of a GUI drawn on the graphics plane 11.

  The GUI shown in FIG. 38 includes one root container and two corresponding components # 1, # 2, and # 3 that are children of the root container.

  In FIG. 38, components # 1, # 2, and # 3 drawn on the L graphics plane 11L constitute a left-eye image, and components # 1, # drawn on the R graphics plane 11R. 2 and # 3 constitute a right-eye image.

  For example, when the component #i of the image for the left eye is focused, the component #i that is the corresponding component of the image for the right eye must also be focused.

  The 3D-compatible player supports by allowing two containers or components to have the focus at the same time so that the state transition / management of the widget can be symmetrical between L / R. For this purpose, it is necessary to make a container or component instance have a flag representing whether or not the focus is held so that the container or component instance can be managed. The third focus request must fail. That is, the number of containers or components that hold the focus is limited to zero or two.

  As a focus method for focusing two corresponding containers (components) of the left-eye image and the right-eye image, there are a first focus method and a second focus method.

  FIG. 39 shows the first focus method and the second focus method.

  FIG. 39A shows a first focus method (1-root-container across L / R graphics plane).

  In the first focus method, a container (component) on the L graphics plane 11L that is a child of a container (Root Container) straddling the L graphics plane 11L and the R graphics plane 11R, and an R graphics plane 11R The two corresponding containers with the container (component) are given focus at the same time.

  FIG. 39B shows a second focus method (2-root-containers (one for L graphics plane, another for R graphics plane)).

  In the second focus method, a root container is drawn on each of the L graphics plane 11L and the R graphics plane 11R, and the respective root containers are simultaneously activated (in a focused state).

  FIG. 40 is a flowchart for explaining the focus management of the BD player in FIG. 3 as a 3D-compatible player that gives focus to two corresponding containers (components) of the left-eye image and the right-eye image. .

  Note that the container (component) constituting the GUI drawn on the graphics plane 11 has a focus flag indicating whether or not the focus is set.

  When there is a focus request (request), the 3D-compatible player sets 0 as an initial value to a variable i for counting the number of containers in step S51.

  In step S52, the 3D-compatible player selects a focused component (hereinafter also referred to as a focus holding component) among the components (containers) that are children of the container c (i) on the graphics plane 11. However, it is determined based on the focus flag which the component has whether two already exist.

  If it is determined in step S52 that two focus holding components are not present among the components that are children of the container c (i), the 3D-compatible player proceeds to step S53, and a request (request) is made. Give the corresponding focus to the two corresponding components. Further, in step S53, the 3D-compatible player sets a value indicating that the focus is set to the focus flag of each of the two components having the focus, and the process proceeds to step S54.

  On the other hand, if it is determined in step S52 that two focus holding components are present among the components that are children of the container c (i), the 3D-compatible player skips step S53 and proceeds to step S54. , The variable i is incremented by 1, and the process proceeds to step S55.

  In step S55, the 3D-compatible player determines whether the variable i is less than the number N of containers on the graphics plane 11. If it is determined in step S55 that the variable i is less than the number N of containers on the graphics plane 11, the process returns to step S22 and the same processing is repeated.

  If it is determined in step S55 that the variable i is not less than the number N of containers on the graphics plane 11, the process ends.

  As described above, in the 3D-compatible player, when two containers are not focused in response to the focus request, the container of the L graphics plane 11L (L region) that stores the left-eye image, and the container The container of the R graphics plane 11R (R region) that stores the image for the right eye corresponding to is brought into a focused state.

  Therefore, for example, among the containers constituting the 3D image widget, the focus transition can be made similar in the container for the left eye image and the container for the right eye image.

  [Handling mouse events]

  In the case of Stereo graphics, the two-dimensional coordinates on the mouse / cursor screen may be different on the L / R graphics plane. For this reason, BD-J applications require coordinate transformation to describe processing that depends on mouse events, but the offset value for coordinate transformation may differ depending on the implementation of the BD player, so it is unknown. .

  That is, FIG. 41 shows, for example, the position on the display screen where the 3D image of the cursor of a pointing device such as a mouse can be seen, and the position of the cursor on the graphics plane 11.

  The cursor is displayed by a BD player, but in a 3D-compatible player, the 3D image of the cursor is displayed (so that it can be seen) at a position in front of the graphics 3D image (3D image reproduced from the disc 100). Is desirable.

  On the other hand, when the cursor is displayed as a 3D image, the cursor of the image for the left eye on the logical screen 21 is shifted by a predetermined offset value Δx from the position (x, y) of the display screen where the 3D image of the cursor can be seen. The right eye image cursor on the logical screen 21 is also shifted by a predetermined offset value Δx from the display screen position (x, y) at which the 3D image of the cursor can be seen. At the position (x−Δx, y).

  Here, the position of the cursor in the depth direction of the 3D image changes according to the predetermined offset value Δx.

  In a 3D-compatible player, when the 3D image of the cursor is displayed at a position in front of the graphics 3D image, the value max-depth representing the position in the foreground in the depth direction (Z direction) of the graphics 3D image is is necessary. However, in a 3D-compatible player, it is difficult to calculate the value max-depth from a graphics 3D image.

  Therefore, for example, the value max-depth is recorded on the disc 100 (FIG. 3) that is a BD, and the 3D-compatible player sets the value max-depth to PSR (FIG. 7) (for example, PSR # 21). Can be set (stored).

  In this case, in a 3D-compatible player (or a display that displays a 3D image output from the 3D-compatible player), the value max-depth stored in the PSR is referred to, and the cursor is positioned in front of the position represented by the value max-depth. The offset value Δx for displaying can be obtained. Then, the 3D image of the cursor can be displayed at a position in front of the graphics 3D image.

  Note that an OSD (On Screen display) displayed by the 3D-compatible player can also be displayed at a position in front of the graphics 3D image in the same manner as the cursor.

  Also, on the disc 100 (FIG. 3) that is a BD, a value min-depth that represents the position in the depth direction of the 3D image reproduced from the disc 100 that is a BD is recorded together with the value max-depth. It is possible to set the value max-depth and the value min-depth in the PSR (FIG. 7).

  As described above, in a 3D-compatible player, playback from a BD is performed by setting, in the PSR, a value max-depth or the like that represents the position in the depth direction of the 3D image recorded on the disc 100 that is a BD. The cursor and OSD can be displayed in front of the 3D image.

  Incidentally, the 3D-compatible player can arbitrarily set the offset value Δx for displaying the 3D image of the cursor. The offset value Δx does not need to be constant, and can be changed (set) for each frame, for example.

  Therefore, when the 3D-compatible player issues an event with the cursor position as an argument to the BD-J application, the display screen position (x, y) is used as the cursor position. The application must obtain the position (x + Δx, y) (or (x−Δx, y)) of the cursor on the graphics plane 11 by performing coordinate conversion of the position (x, y) of the display screen. I must.

  However, in order for the BD-J application to perform coordinate conversion of the position (x, y) of the display screen, it is necessary to recognize the offset value Δx, and the offset value that can be arbitrarily set by a 3D-compatible player △ x is difficult for BD-J applications to recognize.

  Therefore, the coordinate system of mouse events is limited to the L graphics plane. BD players are obliged to adopt coordinates on the L graphics plane as 2D position information when issuing mouse events.

  That is, in a 3D-compatible player, for example, a 3D image of a cursor of a pointing device such as a mouse is composed of an image for the left eye and an image for the right eye, but when issuing an event with the cursor position as an argument The cursor position is one of the L graphics plane 11L (L region) and the R graphics plane 11R (R region) of the graphics plane 11 of the 3D image of the cursor, for example, the L graphics plane 11L. The position on (L region) is used.

  As a result, the BD-J application can know (recognize) the position on the L graphics plane 11L as the cursor position of the 3D image, so that the author of the BD-J application uses the L graphics as the cursor position. Using the position on the plane 11L, it is possible to describe processing for an event (such as a mouse event) that uses the cursor position as an argument.

  [Drawing operations}

  3D-compatible players must ensure L-view / R-view consistency. That is, the graphics left-eye image and right-eye image are displayed on the display screen after being rendered in a state of being consistent with the graphics plane 11 (so that it can be viewed as a 3D image). Must be guaranteed.

  The initialization (reset) of the graphics plane 11 is the same. That is, when one of the L graphics plane 11L and the R graphics plane 11R of the graphics plane 11 is initialized, the other must also be initialized.

  However, the semantic consistency between L-view / R-view, that is, the consistency of the image contents between the graphics left-eye image and right-eye image, is the responsibility of the author of the BD-J application ( Authoring responsibility).

  FIG. 42 is a diagram illustrating the consistency between the graphics image for the left eye and the image for the right eye.

  FIG. 42A shows a left-eye image and a right-eye image of graphics drawn in a matched state.

  In FIG. 42A, the drawing of the image for the left eye on the L graphics plane 11L and the drawing of the image for the right eye on the R graphics plane 11R have been completed. The eye image and the right eye image must be displayed on the display screen.

  The drawing integrity guarantee API described in FIG. 35 uses a drawing command string as an argument, but the drawing command string that is an argument of the drawing integrity guarantee API is consistent (so that it can be seen as a 3D image). The drawing command sequence for drawing the left-eye image and the right-eye image in a state of being in a state of being in accordance with the drawing integrity guarantee API, the graphics left-eye image and right-eye image are It is guaranteed that the image is drawn in a consistent state.

  FIG. 42B shows a left-eye image and a right-eye image of graphics that are not matched.

  In FIG. 42B, the drawing of the image for the left eye on the L graphics plane 11L is finished, but the drawing of the image for the right eye on the R graphics plane 11R is not finished.

  The 3D-compatible player must not display the left-eye image and the right-eye image in the state shown in FIG. 42B on the display screen.

  The consistency between the graphics image for the left eye and the image for the right eye can be ensured, for example, by adopting triple buffering in a 3D-compatible player.

  FIG. 43 is a block diagram illustrating a functional configuration example of the BD player in FIG. 3 as a 3D-compatible player employing triple buffering.

  The 3D-compatible player includes a back buffer (hidden buffer) 211 as a graphics plane 11, and front buffers 212 and 213.

  The back buffer 211 includes buffers 211L and 211R. The front buffer 212 includes buffers 212L and 212R, and the front buffer 213 includes buffers 213L and 213R.

  In FIG. 43, buffers 211L, 212L, and 213L correspond to the L graphics plane 11L, and store an image for the left eye. The buffers 211R, 212R, and 213R correspond to the R graphics plane 11R and store an image for the right eye.

  The BD-J application issues a drawing command, and graphics 3D images (left-eye image and right-eye image) as a result of executing the drawing command are drawn in the back buffer 211.

  On the other hand, the front buffers 212 and 213 are alternately selected, and the left-eye image and the right-eye image stored in the selected buffer (hereinafter also referred to as a selection buffer) are displayed on the display screen. (Supplied to the Display processor).

  Of the front buffers 212 and 213, the left buffer for the left eye stored (drawn) in the back buffer 211 after the drawing of the left eye image and the right eye image in the back buffer 211 is completed. The image and the right eye image are copied.

  In order to prevent the generation of tearing artifacts, the selection of the front buffers 212 and 213 that are alternately selected as the selection buffer is performed by reading (copying) the left-eye image and the right-eye image from the back buffer. It is executed at the timing of VBI (Vertical Blanking Interval) after completion to the last horizontal line.

  [Frame Accurate Animation]

  There are two types of FAA (Frame Accurate Animation): Image Frame Accurate Animation and Sync Frame Accurate Animation. In a 3D-compatible player, the left-eye image and right-eye image for animation are operated in synchronization. To do this (for L / R synchronization), for both Image Frame Accurate Animation and Sync Frame Accurate Animation, drawing the image for the left eye for animation and for the right eye for animation It is desirable that the image drawing is performed separately (animation is simultaneously operated in two places).

  That is, in the legacy player, the animation operates only at one place. If an image or buffer that straddles L / R is used, animation can be simulated in two places, but due to the performance requirements of the BD player, a sufficient animation frame rate cannot be achieved.

  FIG. 44 is a diagram for explaining an animation by an image straddling L / R.

  In FIG. 44, one image of w × (h + 1080) pixels is drawn across the L graphics plane 11L of the graphics plane 11 of 1920 × 2160 pixels and the R graphics plane 11R.

  In FIG. 44, a portion (center portion) of the w × (h + 1080) pixel image except the upper w × h pixel image and the lower w × h pixel image is represented by a transparent pixel ( By painting with a transparent color), the upper w × h pixel image becomes the left eye image for animation, and the lower w × h pixel image becomes the right eye image for animation. be able to.

  That is, by filling the central portion of one image of FIG. 44 with a transparent color, the appearance of the one image is the same for the L graphics plane 11L and the R graphics plane 11R. It can be in a state drawn at a position. Therefore, it is possible to realize an animation of a 3D image in which a w × h pixel image on the L graphics plane 11L and a w × h pixel image on the R graphics plane 11R are operated in synchronization.

  However, in FIG. 44, although the image for the left eye and the image for the right eye for animation are images of w × h pixels, a huge 1 of w × (h + 1080) pixels. One image needs to be drawn.

  As a result, depending on the performance of the BD player, it takes time to draw an image, and it becomes difficult to display an animation of a 3D image at a sufficient frame rate.

  Therefore, the 3D-compatible player separately performs drawing of the left eye image for animation and drawing of the right eye image for animation.

  FIG. 45 is a diagram illustrating drawing of an image for the left eye for animation and drawing of an image for the right eye for animation.

  In the 3D-compatible player, an image for the left eye for animation is drawn on the L graphics plane 11L (L region). Further, in the 3D-compatible player, the right-eye image for animation is displayed on the R graphics plane 11R (R region) separately from the drawing of the left-eye image for animation on the L graphics plane 11L (L region). Drawn.

  As a result, the left-eye image and the right-eye image for animation can be quickly drawn, and as a result, the animation of the 3D image can be displayed at a sufficient frame rate.

  FIG. 46 is a diagram of a 3D-compatible player that separately performs drawing of the left-eye image for animation on the L graphics plane 11L and drawing of the right-eye image for animation on the R graphics plane 11R. 3 is a block diagram illustrating a functional configuration example of a BD player 3; FIG.

  FIG. 46A shows a configuration example of a 3D-compatible player that draws an animation as an Image Frame Accurate Animation.

  An image buffer 231 is a buffer that functions as a cache memory for a BD-J application to load and save resources from the disc 100 (FIG. 3) that is a BD, and is used for animation. A list of images for the left eye (a list of images for L) and a list of images for the right eye for animation (a list of images for R) are stored.

  The pixel transfer device 232L sequentially reads out images for the left eye for animation from the image buffer 231 in units of pixels (pixels) and draws them on the L graphics plane 11L.

  The pixel transfer device 232R sequentially reads out images for the right eye for animation from the image buffer 231 in units of pixels (pixels) and draws them on the R graphics plane 11R.

  FIG. 46B shows a configuration example of a 3D-compatible player that draws animation as Sync Frame Accurate Animation.

  The graphics memory 241 is a work memory of a 3D-compatible player, and stores a left eye image buffer for animation (L image buffer) and a right eye image for animation (R use). Image buffer).

  The pixel transfer unit 242L sequentially reads out images for the left eye for animation from the graphics memory 241 in units of pixels and draws them on the L graphics plane 11L.

  The pixel transfer device 242R sequentially reads out images for the right eye for animation from the graphics memory 241 in units of pixels and draws them on the R graphics plane 11R.

  Here, FIG. 47 shows the definition of the extended API of Image Frame Accurate Animation.

  FIG. 48 shows the definition of the extended API of Sync Frame Accurate Animation.

  Further, FIG. 49 and FIG. 50 show sample codes of Image Frame Accurate Animation. FIG. 50 is a diagram following FIG. 49.

  51 and 52 show sample codes for Sync Frame Accurate Animation. FIG. 52 is a diagram following FIG.

  Here, the embodiments of the present technology are not limited to the above-described embodiments, and various modifications can be made without departing from the gist of the present technology.

  That is, in this embodiment, the 3D-compatible player in FIG. 3 performs processing for the content of the 3D image recorded on the disc 100 and the Java (registered trademark) application. The 3D image content and Java (registered trademark) application to be processed in the player are data supply means other than the recording medium such as the disc 100, specifically, for example, an object carousel or data carousel that is a digital broadcasting application. Therefore, the 3D-compatible player can process the 3D image content and Java (registered trademark) application supplied from the object carousel and data carousel.

  10 logical planes, 11 graphics planes, 11LL graphics plane, 11RR graphics plane, 12PG plane, 12LL L-PG plane, 12RR R-PG plane, 13 video plane, 13LL video plane, 13RR video plane, 14 back Ground plane, 14L L background plane, 14R R background plane, 15 mixer, 21 logic screen, 101 bus, 102 CPU, 103 ROM, 104 RAM, 105 hard disk, 106 output unit, 107 input unit, 108 communication unit, 109 Drive, 110 input / output interface, 111 removable recording medium, 201L, 201R, 202L, 202R buffer, 211 back buffer 211L, 211R, 212 front buffer, 212L, 212R buffer, 213 front buffer, 213L, 213R buffer, 231 image buffer, 232L, 232R pixel transfer device, 241 graphics memory, 242 L, 242R pixel transfer device

Claims (3)

The device plane that stores graphics, video, or background images has an L area that is a storage area for one image that stores an image for the left eye, and an image for one plane that stores an image for the right eye. It is a storage area of the image for two sides with the R area which is the storage area of
The configuration of the device plane is defined for the entire device plane, which is a storage area for the two plane images, and includes the resolution of the image.
An information processing apparatus that sets the resolution of the graphics, video, and background images to the same resolution in the configuration change. The device plane that stores graphics, video, or background images has an L area that is a storage area for one image that stores an image for the left eye, and an image for one plane that stores an image for the right eye. It is a storage area of the image for two sides with the R area which is the storage area of
The configuration of the device plane is defined for the entire device plane, which is a storage area for the two plane images, and includes the resolution of the image.
In the configuration change, the graphics, video, and background images have the same resolution. The device plane that stores graphics, video, or background images has an L area that is a storage area for one image that stores an image for the left eye, and an image for one plane that stores an image for the right eye. It is a storage area of the image for two sides with the R area which is the storage area of
The configuration of the device plane is defined for the entire device plane, which is a storage area for the two plane images, and includes the resolution of the image.
A program for causing a computer to function as an information processing apparatus that changes the resolution of the graphics, video, and background images to the same resolution when the configuration is changed.

Images