JP5209513B2 - recoding media - Google Patents

Description

  The present invention relates to a recording medium that enables a user to interactively operate a program recorded on a large-capacity recording medium such as a Blu-ray Disc.

  In recent years, the Blu-ray Disc (Blu-ray Disc) standard has been proposed as a standard for a disc-type recording medium that can be recorded and is removable from a recording / reproducing apparatus. In the Blu-ray Disc standard, a disk having a diameter of 12 cm and a cover layer of 0.1 mm is used as a recording medium, a blue-violet laser having a wavelength of 405 nm and an objective lens having a numerical aperture of 0.85 are used as an optical system, and the maximum size is 27 GB (gigabytes). ) Recording capacity. As a result, it is possible to record Japanese BS digital high-definition broadcasting for 2 hours or more without degrading the image quality.

  As a source (supply source) of an AV (Audio / Video) signal to be recorded on the recordable optical disc, a conventional analog signal by analog television broadcast, for example, digital television including BS digital broadcast, for example. It is assumed to be a digital signal by broadcasting. In the Blu-ray Disc standard, a standard that defines a method for recording AV signals by these broadcasts has already been created.

  On the other hand, as a derivation standard of the current Blu-ray Disc, there is a movement to develop a read-only recording medium in which movies, music, and the like are recorded in advance. As a disc-shaped recording medium for recording movies and music, a DVD (Digital Versatile Disc) is already widely used, but a read-only optical disc based on the Blu-ray Disc project is Blu-ray Disc's. It differs from existing DVDs in that it can record high-definition video for 2 hours or more with high capacity and high transfer speed.

  By the way, in the current Blu-ray Disc standard, a method of displaying a list of video contents recorded on a disc on the screen, a cursor is displayed on the list, and a user selects a video content to be reproduced. Functions related to the user interface are not defined. These functions are realized by the main body of the recording / reproducing apparatus that performs recording / reproduction with respect to the Blu-ray Disc. Therefore, even when the same recording medium is reproduced, the layout of the content list screen differs depending on the recording / reproducing apparatus used for reproduction, and the user interface is also different, which is not always easy for the user to use. As a playback-only disc, a menu screen as intended by a disc (content) producer is displayed regardless of the playback device, and a user interface as intended is required to be realized.

  Furthermore, a multi-story function in which a selection screen is displayed during video content reproduction and a story branches according to a user's selection is generally called an interactive function. In order to realize this interactive function, it is necessary for the disc creator to create a scenario in which the playback order and branching are determined, and to describe the scenario using a program language, a script language, etc., and record it on the disc. On the playback device side, by reading and executing the program, playback of video content according to the intention of the creator and selection screen presentation for branching are realized.

  As described above, in the current Blu-ray Disc standard (Blu-ray Disc Rewritable Format Ver1.0), the configuration method of the menu screen and the branch selection screen for realizing the user interface as intended by the producer, the user A method for describing processing for input is not defined. Therefore, at present, it is difficult to realize reproduction according to the scenario intended by the producer using Blu-ray Disc in a compatible manner without being influenced by the manufacturer and model of the reproduction apparatus. There was a problem.

  In addition, for playback-only discs, producers are demanding a multi-angle function that allows users to select the desired subject angle by shooting the same subject with multiple cameras, and there is a mechanism to achieve this. There is a need to.

  On the other hand, in the past, for example, in the DVD (Digital Versatile Disc) standard, the interactive function as described above has already been realized. For example, during playback of a video by DVD video, a menu screen can be called using a remote control commander, etc., and a playback scene can be changed by, for example, selecting a button arranged on the menu screen. there were. A multi-angle function was also realized.

  As described above, it is required that the user interface and interactive function that are realized by a conventional recording medium such as a DVD can be realized even when a large-capacity recording medium such as a Blu-ray Disc is used as a read-only disk. ing.

  Accordingly, an object of the present invention is to provide a recording medium for realizing a user interface having a high degree of freedom in a large-capacity recorded medium.

  Another object of the present invention is to provide a recording medium that realizes a more expressive user interface in a large-capacity recorded medium.

In order to solve the above-described problems, the present invention is a recording medium having a predetermined data structure in which content data to be played back by a playback device is recorded, and the data structure is encoded in units of one or more frames. A first flag indicating whether or not the playback unit can be played back at a plurality of angles, the number of angles included in the playback unit, and each of the angles provided for each playback unit of the video stream. wherein the position information indicating the position on the corresponding video stream, provided for encoding unit, and a second flag showing whether to switch the angle at the beginning of the encoding units in is loaded into the reproducing apparatus when the data structure is loaded into the reproducing apparatus Te, the first flag, in which the reproduction unit can be reproduced with a plurality of angles If showing the bets, change the reproduction position of the video stream based on the location information, to be able to read the video stream constituting a predetermined angle, in addition position based on the second flag, for each angle A recording medium in which a playback apparatus performs a process using the above data structure for changing the playback position of an interleaved recorded video stream so that a video stream constituting another angle can be read. .

  As described above, according to the present invention, a recording medium is provided with a video stream and a first flag provided for each playback unit of the video stream, which indicates whether the playback unit can be played back at a plurality of angles. The number of angles included in the playback unit and the position information indicating the position of each angle on the video stream are recorded, and the video stream constituting the angle can be read based on the position information. The angle can be switched during playback of the video stream.

  The present invention also provides a main stream that is mainly played back, a substream that is played back with the main stream as a subordinate to the main stream, and a flag that indicates whether or not the substream is repeatedly played back asynchronously with respect to the main stream. Is recorded, and the reproduction of the substream can be controlled based on the flag, so that the substream can be repeatedly reproduced asynchronously with respect to the main stream during the reproduction of the main stream.

  The present invention also includes video data, audio data to be played back corresponding to the video data, and at least a flag indicating whether the video data and the audio data are multiplexed or independent files. Since the recorded video data and audio data can be reproduced based on the flag, the method of reading the video data and audio data from the recording medium can be controlled based on the flag.

It is a basic diagram which shows typically the structure of the reproduction | regeneration order specification of AV stream file. It is a UML figure which shows the relationship between a clip AV stream, clip information, a clip, a play item, and a play list. It is an approximate line figure for explaining a method of referring to the same clip from a plurality of play lists. It is a basic diagram for demonstrating the management structure of the file recorded on a recording medium. FIG. 11 is a schematic diagram illustrating syntax that represents an example of a structure of a file “info.bdav”. It is a basic diagram which shows the syntax showing the structure of an example of block UIAppInfoBDAV (). It is a basic diagram which shows the syntax showing the structure of an example of block TableOfPlayLists (). It is a basic diagram which shows the syntax showing the structure of an example of file "#####. Rpls" and "#####. Vpls". FIG. 25 is a schematic diagram illustrating a syntax that describes an example of a structure of a block UIAppInfoPlayList (). [Fig. 22] Fig. 22 is a schematic diagram illustrating a syntax that describes an example of a structure of a block PlayList (). [Fig. 22] Fig. 22 is a schematic diagram illustrating syntax that represents an example of a structure of a block PlayItem (). It is a basic diagram for demonstrating a bridge clip. FIG. 22 is a schematic diagram illustrating a syntax that describes an example of a structure of a block PlayListMark (). FIG. 10 is a schematic diagram illustrating syntax that represents an example of a structure of a file “%%%%%. Clpi”. It is a basic diagram which shows an example of the plane structure used as an image display system in one Embodiment of this invention. It is a basic diagram which shows the resolution and displayable color of an example of a moving image plane, a caption plane, and a graphics plane. It is a block diagram which shows the structure of an example which synthesize | combines a moving image plane, a caption plane, and a graphics plane. It is a basic diagram which shows an example of the input / output data of a pallet. It is an approximate line figure showing an example pallet table stored in a pallet. It is a basic diagram which shows an example of the menu screen displayed on a graphics plane. It is a basic diagram which shows the internal structure of an example of the scenario at the time of using the scenario description language defined uniquely. It is a basic diagram for demonstrating the classification | category of the structure of a scenario. It is a basic diagram for demonstrating the classification | category of the structure of a scenario. It is a basic diagram for demonstrating a title and a chapter. It is a basic diagram for demonstrating a BD virtual player model. It is a flowchart which shows roughly operation | movement of the BD virtual player 30 by the command described by a scenario. It is a flowchart for demonstrating reproduction | regeneration operation | movement of a play list. It is a basic diagram which shows an example of the command used in a scenario. It is a basic diagram which shows the management structure of an example file by this one Embodiment. It is a basic diagram which shows the syntax showing the structure of an example of file "scenario.hdmv". It is a basic diagram which shows the syntax showing the data structure of an example of block Autoplay (). It is a basic diagram which shows the syntax showing the structure of an example of block Scenario (). FIG. 11 is a schematic diagram illustrating a syntax representing an example data structure of a file “entrylist.data”. It is a basic diagram which shows the syntax showing the structure of an example of block AppInfo (). It is a basic diagram which shows the syntax showing the structure of an example of block ScenarioEntry (). FIG. 11 is a schematic diagram illustrating syntax that represents an example of a structure of a file “xxxx.mpls”. It is a basic diagram which shows the syntax showing the structure of an example of block PLControlInfo (). It is a figure for demonstrating the field PL_playback_type. It is a figure for demonstrating the field PL_random_access_mode. [Fig. 22] Fig. 22 is a schematic diagram illustrating a syntax that describes an example of a structure of a block PlayList (). [Fig. 22] Fig. 22 is a schematic diagram illustrating syntax that represents an example of a structure of a block PlayItem (). It is a figure for demonstrating the field PI_random_access_mode. It is a figure for demonstrating field still_mode. It is a figure for demonstrating the field is_seamless_angle_change. FIG. 22 is a schematic diagram illustrating syntax that represents an example of a structure of a block SubPlayItem (). It is a figure for demonstrating the field is_repeat_flag. It is a figure for demonstrating the synchronous reproduction | regeneration with respect to the main play item of a sub play item. FIG. 9 is a schematic diagram illustrating syntax that represents an example of a structure of a file “zzzzz.clpi”. It is a basic diagram which shows the syntax showing the structure of an example of block ClipInfo (). It is a figure for demonstrating the field application_type. It is a basic diagram which shows the syntax showing the structure of an example of block SequenceInfo (). It is a basic diagram which shows the syntax showing the structure of an example of block ProgramInfo (). It is a basic diagram which shows the syntax showing the structure of an example of block StreamCodingInfo (). It is a basic diagram which shows the syntax showing the structure of an example of block CPI (). It is a figure for demonstrating field CPI_type. It is a basic diagram which shows the syntax showing the data structure of an example of block EP_map_for_HDMV (). It is a figure for demonstrating an extent. It is a basic diagram which shows the example of the state in which the clip AV stream is fragmented and recorded on the disc. It is a figure for demonstrating a multi-angle function. It is a figure for demonstrating providing the several angle switchable point in one interleave unit. It is a figure for demonstrating flag is_angle_change_point. It is a basic diagram which shows the example of a non-seamless multi-angle block. It is a figure for demonstrating that the discontinuity has arisen when angle switching was performed by the non-seamless multi-angle block. It is a figure for demonstrating the 1st reproduction | regeneration method of a non-seamless multi-angle block. It is a figure for demonstrating the 2nd reproduction | regeneration method of a non-seamless multi-angle block. 1 is a functional block diagram showing a configuration of an example of a player decoder 100 that can be applied to an embodiment of the present invention.

  Hereinafter, an embodiment of the present invention will be described. In one embodiment of the present invention, based on the Blu-ray Disc standard (Blu-ray Disc Rewritable Format Ver1.0) which is a recording / playback standard, an interactive function required for a playback-only disc, a multi-angle function, etc. The function can be realized.

  First, in order to facilitate understanding, with regard to Blu-ray Disc, AV (Audio / Video) recorded on a content, that is, a disc specified in “Blu-ray Disc Rewritable Format Ver1.0 part 3 Audio Visual Specifications” The data management structure will be described. Hereinafter, this management structure is referred to as a BDAV format.

  For example, a bit stream encoded by an encoding method such as MPEG (Moving Pictures 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 disc as a file by a file system defined by “Blu-ray Disc Rewritable Format Ver1.0 part 2”, which is one of the standards for Blu-ray Disc. This file is referred to as a clip AV stream file (or AV stream file).

  The clip AV stream file is a management unit on the file system, and is not necessarily a management unit that is easily understood by the user. When considering user convenience, a mechanism for playing video content divided into multiple clip AV stream files together, a mechanism for playing only part of a clip AV stream file, and special playback And information for smoothly performing cueing playback must be recorded on the disk as a database. This database is defined by "Blu-ray Disc Rewritable Format Ver1.0 part3", which is one of the standards related to Blu-ray Disc.

  FIG. 1 schematically shows a reproduction order designation mechanism for designating a part or all of an AV stream file and arranging and reproducing only necessary parts. In FIG. 1, a play list (PlayList) designates a part or the whole range of an AV stream file and gives an instruction to reproduce only a necessary part. When the user reproduces the content, it is selected in units of this playlist. That is, the playlist is a unit of video / audio that the user implicitly expects to be collected together, that is, to be played back continuously.

  The simplest playlist structure consists of a series of AV stream files from the start of recording to the end of recording. If no editing is performed, this is one playlist.

  The playlist includes a designation of an AV stream file to be reproduced, and a collection of a reproduction start point and a reproduction end point that designate a reproduction portion of the designated AV stream file. A set of information of the reproduction start point and the reproduction end point is referred to as a play item (PlayItem). A play item can be considered as one reproduction unit. A playlist is composed of a set of play items. Playing a play item means playing a part of an AV stream file referenced by the play item.

  As described above, the clip AV stream is a bit stream in which video data and audio data are multiplexed in the MPEG2 TS (transport stream) format or the like. Information regarding the clip AV stream is recorded in a file as clip information (Clip Information).

      A clip AV stream file and a clip information file in which corresponding clip information is recorded are regarded as a group of objects, and are referred to as a clip. That is, a clip is one object composed of a clip AV stream and clip information.

  A file is generally treated as a byte sequence. The content of the clip AV stream file is expanded on the time axis, and the entry point in the clip is designated mainly on a time basis. When a time stamp of an access point to a predetermined clip is given, the clip information file can be used to find address information to start reading data in the clip AV stream file.

  All playlists and clips recorded in one disc are managed by volume information.

  FIG. 2 is a UML (Unified Modeling Language) diagram showing the relationship between the clip AV stream, the clip information (Stream Attributes), the clip, the play item, and the play list as described above. A play list is associated with one or a plurality of play items, and the play item is associated with one clip. A plurality of play items having different start points and / or end points can be associated with one clip. One clip AV stream file is referenced from one clip. Similarly, one clip information file is referenced from one clip. The clip AV stream file and the clip information file have a one-to-one correspondence. By defining such a structure, it is possible to specify a non-destructive reproduction order in which only an arbitrary part is reproduced without changing the clip AV stream file.

  Also, as shown in FIG. 3, the same clip can be referenced from a plurality of playlists. In the example of FIG. 3, clip 1 is referenced from two playlists 2 and 3. In FIG. 3, the horizontal direction of the clip 1 represents the time axis. The playlist 2 refers to the sections a to f of the clip 1 including the commercial section bc and the scene e. On the other hand, the playlist 3 refers to the section d-g of the clip 1 including the scene e. By specifying the playlist 2, the sections a to f of the clip 1 can be reproduced, and by specifying the playlist 3, the sections d-g of the clip 1 can be reproduced.

  Next, the management structure of a file recorded on a recording medium defined by “Blu-ray Disc Rewritable Format Ver1.0 part3” will be described with reference to FIG. Files are managed hierarchically by a directory structure. On the recording medium, first, one directory (root directory in the example of FIG. 4) is created. Below this directory is a range managed by one recording / reproducing system.

  A directory BDAV is placed under the root directory. As shown in FIG. 4, a plurality of directories BDAV can be placed under the root directory, such as directories BDAV, BDAV1, BDAV2,... BDAVn. In the following description, a plurality of directories BDAV, BDAV1, BDAV2,.

The following six types of files are placed under the directory BDAV.
(1) info.bdav
(2) menu.tidx, mark.tidx
(3) menu.tdt1, menu.tdt2, mark.tdt1, mark.tdt2
(4) #####. Rpls, #####. Vpls
(5) %%%%%. Clpi
(6) *****. M2ts

  In the files “#####. Rpls” and “#####. Vpls” in (4), “#####” indicates an arbitrary number. Similarly, in the file “%%%%%. Clpi” of (5), “%%%%%” indicates an arbitrary number. In the file “*****. M2ts” in (6), “*****” is a pair of the file “*****. M2ts” and the file “%%%%%. Clpi”. It is a number corresponding to one. For example, the number “*****” can be the same as the number “%%%%%”.

  The file “info.bdav” in (1) is a file in which information on the entire directory BDAV is stored. The files “menu.tidx” and “mark.tidx” in (2) are files storing thumbnail image information. The files “menu.tdt1”, “menu.tdt2”, “mark.tdt1”, and “mark.tdt2” in (3) are files that store thumbnail images. The extensions “tdt1” and “tdt2” of each file indicate whether the thumbnail image data stored in the file is encrypted.

  The files “#####. Rpls” and “#####. Vpls” in (4) are files in which playlist information is stored. The files “#####. Rpls” and “#####. Vpls” are placed under the directory PLAYLIST provided under the directory BDAV.

  The file “%%%%%. Clpi” in (5) is a file in which clip information is stored. The file “%%%%%. Clpi” is placed under a directory CLIPINF provided under the directory BDAV. The file “*****. M2ts” in (6) is a clip AV stream file in which the clip AV stream is stored. This clip AV stream file is associated with one clip information file “%%%%%. Clpi” by a file name number “*****”. The file “*****. M2ts” is placed under the directory STREAM provided under the directory BDAV.

  Each file will be described in more detail. The file “info.bdav” of (1) is provided only under the directory BDAV. FIG. 5 shows syntax that represents an example of the structure of the file “info.bdav”. Here, the syntax is shown based on a description method in C language used as a program description language such as a computer device. This is the same in the diagrams representing other syntaxes.

  In FIG. 5, the file “info.bdav” has a block for each function-specific information. The field type_indicator stores a character string “BDAV” and indicates that this file is a file “info.bdav”. A field version_number indicates the version of this file “info.bdav”. The block UIAppInfoBDAV () stores information related to the directory BDAV. The block TableOfPlayLists () stores information related to the arrangement of playlists. The block MakersPrivateData () stores information unique to the manufacturer of the recording / reproducing apparatus.

  At the head of the file “info.bdav”, an address indicating the head of each block is described. For example, in the field TableOfPlayLists_Start_address, the start position of the block “TableOfPlayLists ()” is indicated by the relative number of bytes in the file.

  FIG. 6 shows syntax that represents an example of the structure of block UIAppInfoBDAV (). In the field length, the length from the field immediately after the field length to the end of the block UIAppInfoBDAV () is indicated in bytes. A field BDAV_character_set describes a character set of a character string recorded in the field BDAV_name in the block UIAppInfoBDAV (). ASCII, Unicode, etc. can be selected as the character set.

  The flag BDAV_protect_flag indicates whether or not the content placed under the directory BDAV can be shown to the user without restriction. For example, when this flag is set to the value “1” and the user can correctly input a personal identification number PIN (Personal Identification Number), the content placed under the directory BDAV may be shown to the user. It shall be possible. On the other hand, when the flag BDAV_protect_flag is set to the value “0”, the content placed under the directory BDAV can be shown to the user without the input of the personal identification number PIN by the user.

  The personal identification number PIN is recorded in the field PIN. The personal identification number PIN is composed of, for example, four digits 0 to 9, and represents a personal identification number required when the reproduction control is enabled as described above. Each number of the personal identification number PIN is encoded in accordance with, for example, ISO (International Organization for Standarization) / IEC (International Electrotechnical Commission) 646.

  With the above information shown in the block UIAppInfoBDAV (), playback restrictions on the directory BDAV are defined. Although details will be described later, playback restrictions for individual playlists are defined in the block UIAppInfoPlayList () shown in the files "#####. Rpls" and "#####. Vpls". Defined by the playback_control_flag flag.

  In this example, when the reproduction of the content under the directory BDAV is resumed, a resume function for designating a playlist to be preferentially reproduced can be used. This resume function is assumed to be used when it is desired to resume playback from the point where the previous viewing was interrupted.

  In FIG. 6, a flag resume_valid_flag indicates whether the resume function is valid / invalid. For example, when this flag is set to the value “0”, the resume function is disabled, and when this flag is set to the value “1”, the resume function is enabled. The playlist specified in the field resume_PlayList_file_name is handled as a playlist to be played back with priority.

  A field ref_to_menu_thumbnail_index is an area for storing a thumbnail number for specifying a thumbnail image representing the directory BDAV. In the Blu-ray Disc standard, a still image representing the directory BDAV is particularly called a menu thumbnail. A thumbnail image having the index thumbnail_index specified by the field ref_to_menu_thumbnail_index becomes the menu thumbnail of this directory BDAV.

  A field BDAV_name_length indicates the byte length of the directory BDAV name indicated in the field BDAV_name. In this field BDAV_name, from the left, the number of bytes indicated by the field BDAV_name_length is a valid character string, which indicates the name of this directory BDAV. In the field BDAV_name, any value may be contained in the byte string after the valid character string indicated by the field BDAV_name_length.

  FIG. 7 shows syntax that represents an example of the structure of the block TableOfPlayLists (). A field number_of_PlayLists indicates the number of playlists placed under this directory BDAV. This shows the order of playlists when the list of playlists indicated by the field PlayList_file_name is displayed on the playlist list display screen or the like in the subsequent “for” statement loop, in which the number of playlists is a loop variable. The playlist is specified by a file name such as “#####. Rpls” or “#####. Vpls” in the field PlayList_file_name.

  The files “#####. Rpls” and “#####. Vpls” are placed under the directory PLAYLIST as described above. These files have a one-to-one correspondence with one playlist.

  FIG. 8 shows syntax that represents an example structure of the files “#####. Rpls” and “#####. Vpls”. In FIG. 8, the files “#####. Rpls” and “#####. Vpls” have blocks for each function-specific information. A character string indicating this file is stored in the field type_indicator, and the version of this file is indicated in the field version_number.

  The block UIAppInfoPlayList () stores attribute information related to this playlist. The block PlayList () stores information regarding play items that constitute the play list. The block PlayListMark () stores information on marks attached to this playlist. The block MakersPrivateData () stores information unique to the manufacturer of the device that recorded the playlist file. In the fields PlayList_start_address, PlayListMark_start_address and MakersPrivateData_start_address provided at the beginning of the files “#####. Rpls” and “#####. Vpls”, the start address of the corresponding block is indicated as 32-bit address information, for example. It is.

  Since the start address of each block is indicated at the beginning of the files "#####. Rpls" and "#####. Vpls", data padding_word of arbitrary length can be placed before and / or after the block. Can be inserted. However, the start position of the block UIAppInfoPlayList () that is the first block of the files “#####. Rpls” and “#####. Vpls” is fixed to the 320th byte from the beginning of the file.

  FIG. 9 shows syntax that represents an example of the structure of a block UIAppInfoPlayList (). The block UIAppInfoPlayList () stores various attribute information related to the playlist that is not directly required for playback of the playlist. In the field PlayList_character_set, a character set of character string information related to the playlist is specified.

  The flag playback_control_flag specifies whether or not to restrict information display and playlist reproduction based on the PIN. For example, if the flag playback_control_flag is “1”, information display such as thumbnail images of the playlist and playback of the playlist cannot be performed unless the correct PIN number is input by the user. The flag write_protect_flag is an erasure prohibition flag. For example, if the flag write_protect_flag has a value “1”, it is necessary to make the user interface such that the user cannot easily delete the playlist. The flag is_played_flag indicates that this playlist has been played. The flag is_edited_flag indicates that this playlist has been edited.

  A field time_zone indicates a time zone where the play list is recorded. A field record_time_and_date indicates the recording date and time of the playlist. A field PlayList_duration indicates the playback time of the playlist.

  In the fields maker_ID and maker_model_code, for example, information specifying the manufacturer and the recorder of the recorder that last updated the playlist is indicated by a number. The field channel_number indicates the channel number of the recorded clip AV stream, and the field channel_name indicates the channel name. The length of the channel name indicated in the field channel_name is indicated in the field channel_name_length. Of the area of the field channel_name, the character string having the length indicated by the field channel_name_length is valid. In the field PlayList_name, the play list name is indicated with the value indicated in the field PlayList_name_length as the effective length. In the field PlayList_detail, detailed information of the play list is indicated with the value indicated in the field PlayList_detail_length as an effective length.

  FIG. 10 shows syntax that represents an example of the structure of a block PlayList (). The field length indicates the byte length from the field immediately after the field length to the end of the block PlayList (). A field PL_CPI_type indicates the type of CPI (Characteristic Point Information) that the playlist has. A field number_of_PlayItems indicates the number of play items constituting the play list. A field number_of_SubPlayItems indicates the number of post-audio recording play items (sub play items) attached to the play list. Although details are omitted, a playlist can have a sub play item only when a predetermined condition is satisfied.

  The block PlayItem () stores play item information. The block SubPlayItem () stores information on sub play items.

  FIG. 11 shows syntax that represents an example of the structure of a block PlayItem (). In the field Clip_Information_file_name, the file name of the clip information file (file whose extension is clpi) corresponding to the clip referred to by the play item is indicated by a character string. The clip information file is a file whose extension is “clpi”.

  A field Clip_codec_identifier indicates an encoding method of a clip referred to by the play item. In this example, the field Clip_codec_Identifier is fixed to the value “M2TS”. The field connection_condition is information indicating how this play item is connected to the next play item. That is, the field connection_condition indicates whether or not play items can be reproduced seamlessly between play items.

  A field ref_to_STC_id specifies a sequence STC_sequence in the clip referred to by this play item. The sequence STC_sequence is a structure unique to the Blu-ray Disc standard that represents a continuous range of PCR (Program Clock Reference), which is a time axis reference in MPEG2 TS (Transport Stream). A number STC_id unique within the clip is assigned to the sequence STC_sequence. In this sequence STC_sequence, a consistent time axis without discontinuity can be defined, so that the start time and end time of a play item can be uniquely determined. That is, the start point and the end point of each play item must exist in the same sequence STC_sequence. In the field ref_to_STC_id, a sequence STC_sequence is specified by a number STC_id.

  Fields IN_time and OUT_Time indicate time stamps pts (presentation_time_stamp) on the sequence STC_sequence of the start point and end point of this play item, respectively.

  The block BridgeSequnceInfo () stores information related to a bridge clip (Bridge-Clip). A bridge clip is a bit stream created when realizing a function of seamless playback between play items, as shown in an example in FIG. It is possible to play two play items seamlessly by playing a bit stream different from the bit stream that should originally be played, that is, a bridge clip instead, at the joint between the previous play item and the current play item. it can. Since the function of the bridge clip is not related to the present invention, the details are omitted.

  FIG. 13 shows syntax that represents an example of the structure of a block PlayListMark (). The block PlayListMark () has a data structure in which mark information is stored. The mark is a structure for holding the time on the playlist, and by using the mark, functions such as setting a cue point in the playlist and providing a chapter structure for subdividing the playlist Is realized. Furthermore, the display start / stop timing of an image drawn on a graphics plane to be described later can be specified using a mark.

  The field length indicates the byte length from the field immediately after the field length to the end of the block PlayListMark (). A field number_of_PlayList_marks represents the number of marks in the playlist. One loop in the “for” statement indicates information of one mark. The flag mark_invalid_flag indicates whether or not this mark is valid. For example, the flag mark_invalid_flag indicates that the mark is valid when the value is “0”. If the value is “1”, the mark information exists in the database, but the mark cannot be seen by the user. Indicates that it is marked.

  A field mark_type represents the type of this mark. The types of marks include the mark indicating the position of the video as the thumbnail image (representative image) of the playlist, the resume mark indicating how far it has been played back, the chapter mark indicating the cue point, and skipping playback of a certain section first. There are a skip mark indicating progress, a mark indicating the timing to start reading the graphics image, a mark indicating the timing to start displaying the graphics image, a mark indicating the timing to stop displaying the graphics image, and the like.

  A field mark_name_length indicates the data length of a field mark_name described later. The field maker_ID indicates the manufacturer of the recording machine that created this mark. This is used to identify the manufacturer's unique mark. Field ref_to_PlayItem_id indicates on which play item the time indicated by this mark exists. A field mark_time_stamp indicates the time indicated by this mark.

  The field entry_ES_PID indicates which elementary stream, that is, the stream to which the video data and / or audio data is encoded. A field ref_to_menu_thumbnail_index and a field ref_to_mark_thumbnail_index indicate thumbnail images that visually represent marks. As the thumbnail image, for example, an image obtained by extracting a video at a time designated by the mark as a still image can be considered.

  The field duration is used when the mark has a length on the time axis. For example, in the case of a skip mark, the field duration specifies how much time to jump.

  The field makers_information is an area for recording information unique to the manufacturer. The field mark_name is an area for storing a name when the mark is given a name, and the size is specified by the above-described field mark_name_length.

  FIG. 14 shows syntax that represents an example of the structure of the file “%%%%%. Clpi”. As described above, the file “%%%%%. Clpi” is placed under the directory CLIPINF and is created for each AV stream file (file “*****. M2ts”). Inside the file “%%%%%. Clpi”, blocks are configured for each function-specific information. A character string indicating this file is stored in the field type_indicator, and the version of this file is indicated in the field version_number.

  The block ClipInfo () stores information about the clip. The block SequenceInfo () stores information on the discontinuity point of the PCR that represents the time base of the transport stream in the MPEG2 system. The block ProgramInfo () stores information related to the MPEG2 system program. The block CPI () stores information on feature point information CPI that represents a characteristic part in the AV stream, such as a random access startable point. The block ClipMark () stores mark information such as an index point for cueing attached to a clip and a commercial start and / or end point. The block MakersPrivateData () stores information unique to the recorder manufacturer.

  Also, address information indicating the head of each block in the file “%%%%%. Clpi” is indicated as fields SequenceInfo_start_address, ProgramInfo_start_address, CPI_start_address, ClipMark_start_address, and MakersPrivateData_start_address at the head of the file. Note that the clip file “%%%%%. Clpi” itself has a low relevance to the present invention, and a detailed description thereof will be omitted.

  The BDAV format has a data structure as schematically described above, so that a playlist is constructed with a sequence of play items in which a part to be reproduced in a clip AV stream is designated by a set of start and end points, and the user It is possible to manage a group of playback units recognized by.

  Next, an embodiment of the present invention will be described. In the present invention, the above-described BDAV format is expanded to construct a format suitable for a read-only disc. First, a plain configuration for realizing a menu screen for presenting the contents of the disc will be described, and then a scenario structure for allowing the content creator to specify the playback order of the playlist will be added. Furthermore, in the scenario structure, data necessary for realizing functions such as still (pause), random shuffle playback, and multi-angle, which are characteristic of a read-only disc, and a storage method thereof will be described.

  In the embodiment of the present invention, the image display system has a plane configuration as shown in FIG. The moving image plane 10 is displayed on the rearmost (bottom) side, and handles images (mainly moving image data) specified in the play list. The subtitle plane 11 is displayed on the moving image plane 10 and handles subtitle data displayed during moving image reproduction. The graphics plane 12 is displayed in the foreground and handles graphics data such as character data for displaying a menu screen and bitmap data representing buttons. One display screen is displayed by combining these three planes.

  Here, a characteristic point different from the conventional DVD video is that the sub-picture on which the subtitle, the menu screen, the button, etc. described in the conventional technology are displayed is separated into the subtitle plane 11 and the graphics plane 12, and the subtitle The buttons can be controlled independently. As described above, in the conventional DVD video, graphics display such as a menu screen and buttons and subtitle display are controlled by the same mechanism, and these are displayed on the same plane. The number of bitmap images that can be displayed simultaneously is limited to one. Therefore, a conventional DVD video cannot display a plurality of bitmap images at the same time. In the present invention, the subtitle plane 11 for displaying subtitles and the graphics plane 12 for displaying graphics are provided independently to solve the problems of the conventional DVD video.

  Regarding the image display system, the subtitle plane 11 and the graphics plane 12 can be considered to be extensions to the conventional “Blu-ray Disc Rewritable Format Ver1.0 part3”.

  The moving picture plane 10, the subtitle plane 11, and the graphics plane 12 can be displayed independently, and have, for example, resolution and displayable colors as shown in FIG. The video plane 10 has a resolution of 1920 pixels × 1080 lines, a data length converted to 16 pixels, and a luminance signal Y and color difference signals Cb and Cr of 4: 2: 2 (hereinafter referred to as YCbCr ( 4: 2: 2)). Note that YCbCr (4: 2: 2) has a luminance signal Y of 8 bits per pixel, color difference signals Cb and Cr of 8 bits each, and color difference signals Cb and Cr constitute one color data with two horizontal pixels. It is a color system to consider.

  The graphics plane 12 has a resolution of 1920 pixels × 1080 lines, the sampling depth of each pixel is 8 bits, and the color system has an 8-bit color map address using a palette of 256 colors. The subtitle plane 11 is 1920 pixels × 1080 lines, and the sampling depth of each pixel is 8 bits. The color system is an 8-bit color map address using a palette of 256 colors.

  The graphics plane 12 and the caption plane 11 can be alpha-blended in 256 levels, and the opacity can be set in 256 levels when combined with other planes. The opacity can be set for each pixel. In the following, it is assumed that the opacity α is expressed in the range of (0 ≦ α ≦ 1), is completely transparent when the opacity α = 0, and completely opaque when the opacity α = 1.

  The subtitle plane 11 handles PNG (Portable Network Graphics) format image data. The graphics plane 12 can also handle PNG format image data. In the PNG format, when the sampling depth of one pixel is 1 to 16 bits and the sampling depth is 8 bits or 16 bits, the alpha channel, that is, opacity information (referred to as alpha data) of each pixel component. ) Can be added. When the sampling depth is 8 bits, opacity can be specified in 256 steps. Alpha blending is performed using the opacity information by the alpha channel. In addition, palette images of up to 256 colors can be used, and the element number (index) of a palette prepared in advance is expressed by an index number.

  The image data handled by the caption plane 11 and the graphics plane 12 is not limited to the PNG format. You may make it handle the image data compression-encoded by other compression-encoding systems, such as a JPEG system, the image data by which run length compression was carried out, the bitmap data which has not been compression-encoded, etc.

  FIG. 17 shows an example configuration for synthesizing three planes according to FIGS. 15 and 16 described above. The moving image data of the moving image plane 10 is supplied to the 422/444 conversion circuit 20. The moving image data is converted from YCbCr (4: 2: 2) to YCbCr (4: 4: 4) by the 422/444 conversion circuit 20 and input to the multiplier 21.

  The image data of the subtitle plane 11 is input to the palette 22 and output as RGB (4: 4: 4) image data. When the opacity by alpha blending is designated, the designated opacity α1 (0 <= α1 <= 1) is output from the palette 22.

  FIG. 18 shows an example of input / output data of the pallet 22. In the palette 22, for example, palette information corresponding to a PNG format file is stored as a table. The palette 22 refers to the index number using the input 8-bit pixel data as an address. Based on this index number, RGB (4: 4: 4) data each consisting of 8-bit data is output. At the same time, the palette 22 extracts alpha channel data representing opacity.

  FIG. 19 shows an example pallet table stored in the pallet 22. For each of 256 color index values [0x00] to [0xFF] ([0x] indicates hexadecimal notation), three primary color values R, G, and B each represented by 8 bits; An opacity α is assigned. The palette 22 is referred to the palette table based on the input PNG format image data, and R, G, and B color data (RGB data) each consisting of 8-bit data corresponding to the index value specified by the image data. ) And opacity α are output for each pixel.

  The RGB data output from the palette 22 is supplied to the RGB / YCbCr conversion circuit 29, where each data length is converted into 8-bit luminance signal Y and color signal Cb, Cr data (hereinafter collectively referred to as YCbCr data and Called). This is because the subsequent inter-plane synthesis needs to be performed in a common data format, and is therefore unified to YCbCr data, which is the data format of moving image data.

  The YCbCr data and the opacity data α1 output from the RGB / YCbCr conversion circuit 29 are input to the multiplier 23, respectively. The multiplier 23 multiplies the input YCbCr data with opacity data α1. The multiplication result is input to one input terminal of the adder 24. The multiplier 23 multiplies the opacity data α1 for each of the luminance signal Y and the color difference signals Cb and Cr in the YCbCr data. Further, the complement (1-α1) of the opacity data α1 is supplied to the multiplier 21.

  In the multiplier 21, the moving image data input from the 422/444 conversion circuit 20 is multiplied by the complement (1-α1) of the opacity data α1. The multiplication result is input to the other input terminal of the adder 24. In the adder 24, the multiplication results of the multipliers 21 and 23 are added. Thereby, the moving image plane 10 and the caption plane 11 are combined. The addition result of the adder 24 is input to the multiplier 25.

  Similarly to the caption plane 11, RGB (4: 4: 4) data is output from the palette table 26 and input to the RGB / YCbCr conversion circuit 26 for the image data of the graphics plane 12. When the color system of the image data of the graphics plane 12 is RGB (4: 4: 4), the color system is converted into YCbCr (4: 4: 4) and output from the RGB / YCbCr conversion circuit 27. The YCbCr data output from the RGB / YCbCr conversion circuit 27 is input to the multiplier 28.

  When the image data used in the graphics plane 12 is in the PNG format, opacity data α2 (0 ≦ α2 ≦ 1) can be set for each pixel in the image data. The opacity data α2 is supplied to the multiplier 28. The multiplier 28 multiplies the YCbCr data input from the RGB / YCbCr conversion circuit 27 by the opacity data α2 for each of the luminance signal Y and the color difference signals Cb and Cr. A multiplication result by the multiplier 28 is input to one input terminal of the adder 29. Further, the complement (1-α2) of the opacity data α2 is supplied to the multiplier 25.

  In the multiplier 25, the addition result of the adder 24 is multiplied by the complement (1-α2) of the opacity data α2. The multiplication result of the multiplier 25 is input to the other input terminal of the adder 27 and added with the multiplication result of the multiplier 28 described above. Thereby, the graphics plane 12 is further synthesized with the synthesis result of the moving picture plane 10 and the caption plane 11.

  In the caption plane 11 and the graphics plane 12, for example, by setting the opacity α = 0 of the area where there is no image to be displayed, the plane displayed below the plane can be displayed transparently. 10 can be displayed as the background of the caption plane 11 or the graphics plane 12.

  Note that the configuration shown in FIG. 17 can be realized by either hardware or software.

  By setting the plane as described above, it is possible to display menu screens and buttons necessary for the reproduction-only standard. When a button on the menu screen is selected, a playlist corresponding to the button is reproduced. At this time, it is necessary to record information on how the playlists are linked on the disc. Next, a scenario for defining a connection (link) between playlists will be described.

  On the graphics plane 12, a screen for prompting the user to perform an operation, for example, a menu screen can be displayed. FIG. 20 shows an example of the menu screen 60 displayed on the graphics plane 12. On the menu screen 60, characters and images can be displayed at specific positions, and “links” and “buttons” where a new operation is started when the user instructs selection or execution can be arranged.

  “Link” is, for example, a description indicating how to access a predetermined file for a character string or image data, and the user displays the character string or image data displayed on the screen using a pointing device or the like. By designating, the file can be accessed according to the access method set for the character string or image data. For the “button”, for example, three types of image data of a normal state, a selected state, and a pressed state are prepared in the “link”, and when the button image is designated by the user, the three types of image data are displayed. The data display is switched to make it easier for the user to recognize the operation performed by the user.

  The designation operation for “link” or “button” is performed by, for example, moving the cursor display on the screen using a mouse, and moving the mouse button to 1 on a character string or image by “link” or an image by “button”. Or it is done by performing a click action that is pressed multiple times. The same operation can be performed by a pointing device other than the mouse. Further, the present invention is not limited to this, and “link” and “button” can be designated by operating the remote control commander or the keyboard. For example, a “link” or “button” to be designated by a predetermined key such as a direction key is selected, and a “link” or “button” selected by a decision key or the like is designated.

  In the example of FIG. 20, a title 61 is displayed as image data at the top of the menu screen 60 displayed on the graphics plane 12. Following the title 61, selection items 62A, 62B, 62C and 62D as links are displayed. For example, by selecting and specifying one of the selection items 62A, 62B, 62C, and 62D by a key operation of the remote control commander, a file set as a link to the specified selection item is accessed.

  At the bottom of the menu screen 60, there are displayed buttons 64 and 65 for selecting whether or not subtitles are displayed and for selecting the output sound from, for example, English and Japanese. By operating these buttons 64 and 65 as described above, for example, a file for displaying a screen for performing each setting is accessed, and a predetermined screen is displayed.

  In the lower left part of the menu screen 60, a character string 63 indicating an item selection method is displayed. This character string 63 is also a display on the graphics plane 12.

  In order to display the screen as shown in FIG. 20 as an example, some description language capable of describing the screen display method and link information is required. In one embodiment of the present invention, as this description language, by using a command group in which original display control commands for subtitles and buttons are added to those that are modified based on DVD video navigation commands, Menu screen display using Blu-ray Disc is now possible.

  Now, on the Blu-ray Disc menu screen 60 as described above, for example, a list of playlists is displayed with image data, character strings, buttons, etc., and by specifying a playlist, the specified playlist is recorded on the disc. Is expected to be read from and played back.

  In the example of FIG. 20 described above, a list of play lists is displayed on the menu screen 60. The menu screen 60 and the video / audio that is played back when a selection item on the menu screen 60 is selected are actually configured by a structure in which a plurality of playlists are arranged. By associating playlists in a plurality of playlists constituting one item of a menu, a mechanism for branching a story can be realized. By allowing the story to be branched, the multi-story function where the story changes according to the user's selection, the function that automatically plays back the appropriate language according to the player's set language, and the scene according to the user's age The pantalel function to be replaced can be realized.

  Such a function is particularly useful for a recorded disc, and is not assumed in the current Blu-ray Disc standard, which is mainly used for recording / reproducing television broadcasts.

  Hereinafter, the structure in which the plurality of playlists are arranged is referred to as a scenario. FIG. 21 shows an example internal structure of the scenario 70. This scenario 70 includes a plurality of playlists 73A to 73M. The scenario 70 is provided with two locations (screens 80A and 80B) where the branch selection screen is displayed using the graphics plane 12. For example, the screen 80A has graphics data 74A and a playlist 73C for displaying a branch selection screen. Similarly, the screen 80B has graphics data 74B and a playlist 73J for displaying a branch selection screen.

  As described above, the scenario determines the arrangement of the playlist and defines the display timing for the graphics plane 12. The timing of display on the graphics plane 12 can be specified by a display control command added to an image displayed on the graphics plane.

  In the example of FIG. 21, for example, the menu screen 60 described above corresponds to 80A in the scenario 70. The selection item (for example, the selection item 62A) on the menu screen 60 is configured by graphics 72A. That is, when the selection item 62A is designated on the menu screen 60, the playlist 73D corresponding to the selection item is reproduced.

  In the scenario 70 of FIG. 21, first, when a disc is inserted into the player, the playlist 73A is reproduced. When the playback of the playlist 73A is finished, the playlist 73B is played back continuously. When the playback of the playlist 73B is finished, the playlist 73C is played, the graphics data 72A is read, and the story is given to the user. A screen 80A for prompting selection of a branch is displayed.

  After the screen 80A is displayed, the story is branched based on the user's selection. In the example of FIG. 20, by the first selection, after the screen 80A, the playlists 73D, 73E, and 73F are played in this order, and the entire playback is finished. After the reproduction of the playlist 73F is ended, the main menu screen (for example, the menu screen 60 described above) may be returned.

  In the second selection on the screen 80A, the playlist 73G is reproduced after the screen 80A. In the playlist 73G, for example, a mark is set at a predetermined timing. When the playlist 73G is reproduced, the playlist 73G is branched at the mark position of the playlist 73G, or the playlist 73G is reproduced to the end, based on the settings of the reproducing apparatus itself or other scenarios selected by the user or the branch selection screen. Is controlled. When the playlist 73G is played back to the end, after the playback of the playlist 73G is finished, the playlists 73M and 73I are played back, and the playlist 73J is further played back.

  On the other hand, when the playlist 73G branches at the mark position, the playlists 73K and 73L are reproduced next, and when the reproduction of the playlist 73L is completed, the playlist 73I is started from the mark position set in the playlist 73I. Playback continues.

  In the playlist 73J, the graphics data 72B is read, and a screen 80B that prompts the user to select a branch of the story is displayed. In the first selection on the screen 80B, the above-described playlist 73F is reproduced. On the other hand, in the second selection on the screen 80B, reproduction from the mark position set in the playlist 73K is performed.

  In the scenario reproduction, a command sequence (program) is prepared for each playlist, and the player executes the program when the mark is detected, the input from the user, or the operation change of the player is detected. Is done.

  For example, when any of the playlists 73A to 73M in the scenario 70 is being played back, if a menu button provided on the remote control commander is pressed, a menu screen 60 on which a list of scenarios is displayed is displayed. That is, consider a case where it is desired to realize an operation in which the reproduction process is transferred to a playlist for displaying the menu screen 60. In this case, as an event handler corresponding to an event (menu button press event) that occurs when the menu button of the remote control commander is pressed, an instruction to shift the process to a playlist that displays the menu screen 60 is used as scenario data. It is described as one of

  One scenario is defined in the directory and is composed of one or a plurality of playlists. Here, the directory is, for example, a BDAV directory of the above-described recording / playback standard, or an HDMV directory (details will be described later) assumed as a playback-only data area in the embodiment of the present invention.

  Here, the classification of the scenario configuration will be described with reference to FIGS. 22 and 23. FIG. The scenario structure is roughly divided into three types: (1) single playlist, (2) sequential playlist, and (3) multi-playlist, as shown in FIG. can do.

  The single playlist of (1) is a scenario composed of a single playlist as shown in FIG. 23A. Timeline can be defined and there is no interruption during scenario playback. If the content is a movie, for example, the scenario is such that only the main movie is played after loading the disc.

  The sequential playlist of (2) is a scenario configured by arranging a plurality of playlists in series without branching, as shown in FIG. 23B as an example. Each playlist is arranged so that the end of the playlist and the beginning of the next playlist are connected. A timeline through each playlist can be defined. If the content is a movie, for example, the scenario is a combination of a menu screen and a movie main part. When the play list for displaying the menu screen is executed after loading the disc, and the reproduction of the main movie is instructed on the menu screen, the next play list is executed and the main movie is reproduced.

  The multi-playlist of (3) is a scenario that includes connection due to branching or convergence of the playlist, as shown in FIG. 23C. A timeline through a playlist cannot be defined. For example, a timeline is defined in each playlist. According to the multi-playlist, it is possible to realize an interactive property or a game property in which the reproduction content is changed by a user input. In the case where the content is a movie, for example, the same scene is recorded at various angles, and this is a scenario for realizing a multi-angle that can be selected and watched according to a user instruction during playback.

  In the case of read-only media, one scenario is defined in the HDMV directory as will be described later. It is necessary to show the user a more detailed unit of scenario. However, the unit of the playlist does not always match the unit recognized by the user. For example, when three movies are recorded in one playlist, it is necessary to show the cue point of each movie to the user. In this way, the cue point (entry point) independent of the playlist structure is hereinafter referred to as a title and / or chapter.

  Titles and chapters will be described with reference to FIG. The title represents an arbitrary playback start point in the scenario. In the example of FIG. 24, the title 1 is set at the head of the playlist 470A. Title 2 is set in the middle of the playlist 470D. Title 1 is from the top of playlist 470A to immediately before title 2. The chapter is a unit obtained by further subdividing the title, and this is also a unit that the user can recognize as a playback start point. Title 1 is further subdivided by chapter. In the example of FIG. 24, chapters 1, 2, and 3 are set for title 1, and title 1 is subdivided into three. Also, as shown in FIG. 24, the position of the title and chapter can also specify the middle of the playlist.

  Next, consider a model of a playback device that operates according to a scenario description. Hereinafter, the modeled playback device is referred to as a BD (Blu-ray disc) virtual player, and the definition of the configuration of the BD virtual player is referred to as a BD virtual player model.

  The BD virtual player model will be described with reference to FIG. After loading the disc, the BD virtual player 30 reads a scenario described in the scenario description language defined in the present invention and recorded on the disc as a PBC program 40, and operates according to the description of the scenario.

  The BD virtual player 30 reproduces a disc-shaped recording medium defined according to an embodiment of the present invention, and is an object on a computer environment such as a personal computer. The computer environment is not limited to a general-purpose personal computer. For example, a playback device and / or a recording / playback device configured exclusively for playing back a disk-shaped recording medium defined by an embodiment of the present invention. Includes the software environment embedded in. Hereinafter, a disk-shaped recording medium defined by one embodiment of the present invention is abbreviated as a disk.

  The state of the BD virtual player 30 can be roughly classified into two states: a state A in which a playlist and graphics are played back and a state B in which playback is stopped. The transition from a certain state to another state and the designation of the next action in the certain state are performed by a command for the object of the BD virtual player 30.

  Note that state A includes a plurality of operations. As operations included in the state A, variable speed reproduction such as high-speed reproduction and reverse reproduction, special reproduction such as jump reproduction that reproduces from an arbitrary time on the disc, and the like can be considered. When the display on the graphics plane 12 is performed on the BD virtual player 30, these variable speed reproduction and special reproduction may be restricted.

  A PBC (Play Back Control) program 40 corresponds to, for example, a scenario recorded on a disc. Although the details will be described later, the scenario instructs the playback method of the playlist recorded on the disc and the display of the menu screen. The PBC program 40 and the BD virtual player 30 exchange methods via an API (Application Programming Interface) 41 to reproduce a playlist recorded on the disc.

  There are two scenarios, a global command area and a local command area, in which commands including a program in which commands for instructing player operations are arranged are arranged.

  The global command area stores a program effective for the entire scenario. For example, when a disc is inserted into the player, the global command area is automatically executed by the player first to initialize parameters and configure a menu screen. This area describes a program that jumps to a playlist. The local command area is an area for describing a program related to each playlist. Local commands are further classified into four types: pre-commands, play item commands, post commands, and button commands.

  FIG. 26 schematically shows the operation of the BD virtual player 30 according to commands described in the scenario according to the embodiment of the present invention. FIG. 26A shows an example of the operation when loading a disc. As described above, one scenario is created for the HDMV directory described later. When the disc is inserted into the player and the disc is initially accessed (step S30), the register, that is, the common parameter 32 is initialized (step S31). In the next step S32, the program is read from the disk and executed. Note that the initial access means that the disc is played back for the first time as when the disc is inserted.

  A command group (program) that is first read and executed at the time of disk loading is referred to as a global command. The global command describes, for example, an advertisement video (trailer) or a jump command to a playlist that constitutes a menu screen, and the player reproduces the playlist according to the command.

  FIG. 26B shows an example of the operation when the player 30 is in a stop state and the user presses a play key, for example, to instruct playback. This corresponds to the state transition from the state B to the state A in FIG. For the first stop state (step S40), the user instructs reproduction using a remote controller, for example (UOP: User Operation). When the reproduction is instructed, first, the register, that is, the common parameter 32 is initialized (step S41), and in the next step S42, the play list reproduction phase is started.

  Playback of a playlist in the playlist playback phase will be described with reference to FIG. FIG. 27A is an example in the case where the play list includes a single play item. In the playlist, programs are arranged in three places: a pre-command area, a play item command area, and a post command area. When the play list shifts to the play phase, first, the pre-command in the pre-command area is executed (step S10). When the pre-command execution is finished, the play item shifts to the play item playback phase (step S11). ). In the play item playback phase, the stream specified by the start point and end point of the play item is played (step S110). When the reproduction up to the end point is completed, the play item command is executed (step S111). When the play item command is executed, the post command in the post command area is executed next (step S12), and the reproduction of the play list is ended.

  Note that the post command describes a jump command to a playlist to be reproduced next and a jump command to a playlist constituting the menu screen in general use. If there is no jump command, playback stops there, and the player transitions to a stopped state (state B in FIG. 25).

  FIG. 27B is an example when the playlist includes a plurality of play items. Even in this case, a pre-command area, a play item command area, and a post-command area are arranged in the play list, and programs are stored respectively. When a plurality of play items are included, play item streams and play item commands for the number of play items are arranged in time series in the play item command area.

  Even when the play list includes a plurality of play items, the pre-command is executed first when the play list shifts to the play phase (step S10). In the next play item playback phase, the playback of the stream from the start point to the end point of the play item and the execution of the play item command are executed by the number of play items included in the playlist. In the example of FIG. 27B, the first play item stream is reproduced (step S110-1), and the corresponding play item command is executed (step S111-1). Next, although not shown, the second play item stream is reproduced (step S110-2), and the corresponding play item command is executed (step S111-2). This is performed for the number of play items, the last play item stream is reproduced (step S110-n), and when the corresponding play item command is executed (step S111-n), the play item reproduction phase ends. When the play item playback phase ends, a post command is executed (step S12), and the play list playback phase ends.

  FIG. 28 shows a part of the command. By writing a command as illustrated in FIG. 28 in a post command area or a button command area described later, a jump to a specific playlist can be realized. The commands are not limited to those illustrated in FIG. 28, and other commands can be defined.

  A command related to the reproduction start position designation will be described. The command LinkPlayList (playListNumber) instructs to start playing the playlist specified by “playListNumber”. The command LinkPlayItem (playListNumber, playItemNumber) instructs the start of playback from the specified play item of the specified playlist. “playItemNumber” is “PlayItem_id”, and its value starts from “0”. By specifying a value “0” for “playItemNumber”, the play item is played from the beginning.

  The command Link (position) (object) instructs movement within the scenario. That is, it is instructed by this command to move from the currently moving location to the previous or next playlist, play item, or chapter. The parameter “position” takes one of the values “prev”, “next”, “top”, “Parent”, or “tail”, and the movement target (playlist, play item) indicated by the parameter “object”. Or, a movement method for the chapter) is instructed.

  The command Exit instructs to stop scenario playback. In this case, the value of the standard register is not retained. With the command RSM, the resume information stored in the memory in the player is called, set in the register, and playback is started.

  A command related to acquisition of the player state will be described. With the command getMenuDescriptionLanguage (), the language used for menu display is acquired. With the command getScenarioNumber (), the command getPlayListNumber (), and the command getChapterNumber (), the scenario number, the playlist number, and the chapter number that are being reproduced are respectively acquired. The player version information is acquired by the command getPlayerSupport ().

  A command relating to a video stream will be described. Whether or not a specified video stream is included is acquired by a command getVideoStreamAvailability (). The video stream to be decoded is specified by the command setVideoStreamNumber (). The number of the currently selected video stream is acquired by the command getVideoStreamNumber (). With the command getVideoStreamAttr (), the attribute of the currently selected video stream is acquired. Note that the attributes of the video stream are, for example, the encoding mode of the video stream, the resolution, the aspect ratio, the display mode when the aspect ratio is 4: 3, and the presence or absence of closed captions. An angle number is specified by the command setAngleNumber (). The angle number being selected is acquired with the command getAngleNumber (). The maximum number of video streams is acquired with the command getMaxVideoStreams ().

  Next, a method for storing a command or database describing a scenario according to an embodiment of the present invention on a disk will be described. FIG. 29 shows an example of a file management structure according to this embodiment. First, one root directory is created on the disk. The area under this root directory is a range managed by one recording / reproducing system.

  A directory BDMV is placed under the root directory. Although not shown, a plurality of directories BDMV can be placed under the root directory as shown in FIG. Hereinafter, the methods defined in the embodiment of the present invention are collectively referred to as BDMV.

  Under the directory BDMV, two files, that is, a file “scenario.hdmv” and a file “entrylist.data” are placed, and a plurality of directories such as a directory “PLAYLIST”, a directory “CLIPINF”, and a directory “STREAM” are placed. .

  FIG. 30 shows syntax that represents an example of the structure of the file “scenario.hdmv”. This file “scenario.hdmv” is a file that is first read and executed at the time of initial access such as when a disc is inserted. In the file “scenario.hdmv”, a file identification symbol (field type_indicator) and a version number (field version_number) are first described, and then blocks collecting data for each function are arranged.

  The field type_indicator has a data length of 32 bits and stores a specific character string indicating that this file is the file “scenario.hdmv”. A field version_number has a data length of 32 bits and contains a version number. The field Scenario_start_address is an unsigned integer having a data length of 32 bits, and stores a value representing the position where the block Scenario () is started as a relative number of bytes from the beginning of the file “scenario.hdmv”.

  The block Autoplay () starts from a fixed position of the 41st byte from the beginning of the file. In the block Autoplay (), the program to be executed at the time of initial access (when the disc is first played back as when the disc is inserted) is described. The global command described above is stored in this block Autoplay (). An arbitrary number of padding words (padding_word) are placed after Autoplay (), and a space can be provided after the block.

  FIG. 31 shows syntax that represents an example of the data structure of the block Autoplay () shown in FIG. The field length is an unsigned integer having a data length of 32 bits, and describes the data length in bytes from immediately after the field length to the end of the block Autoplay (). Field number_of_commands represents the number of field command (i) that follows. The field command (i) is a value having a data length of 32 bits, and describes commands such as a set of player parameters, start of reproduction of a specified playlist, calculation, and the like described in FIG. Yes.

  The block Scenario () describes the “scenario” described so far. Information on the playback order of the playlist and the local command area for each playlist are described in this block Scenario ().

  FIG. 32 shows syntax that represents an example of the structure of block Scenario (). The block Scenario () is a block that defines scenario information, that is, a link between playlists, and stores information such as the above-mentioned pre-command, post-command, play item command, and the command itself. The block Scenario () includes an area in which a field indicating command information stored in the block Scenario () is described, and an area in which actual commands are listed.

  In the field length, a value expressing the length from immediately after the field length to the end of the block Scenario () in bytes is described. A field number_of_PlayLists represents the number of playlists constituting the scenario. This field number_of_PlayLists and subsequent data is data for each playlist. That is, data for each playlist is described by a for loop from the next line of field number_of_PlayLists, with the value indicated by field number_of_PlayLists being the maximum value of loop counter i.

  A field Pre_Command_start_id represents a start number in a command table of a program (pre-command) executed before playing a playlist. That is, the number indicated by the field Pre_Command_start_id represents a loop counter j in a for loop in which a field PL_Command (i) described later is listed. Similarly, the field Post_Command_start_id represents the start number in the command table of the program (post command) executed after playing the playlist. That is, the number indicated by the field Post_Command_start_id represents a loop counter j in a for loop in which a field PL_Command (j) described later is listed.

  A field number_of_Pre_Commands represents the number of commands constituting a program (pre-command) that is executed before reproducing the playlist. Similarly, a field number_of_Post_Commands represents the number of commands constituting a program (post command) executed after reproducing this playlist. These programs are described in a command table described later.

  The next field number_of_PlayItems represents the number of play items constituting this play list. A field PI_Command_start_id represents a start number in the command table of a command to be executed after playing the play item. That is, the number indicated by the field PI_Command_start_id represents a loop counter j in a command table described later. A field number_of_PI_Commands represents the number of commands (play item commands) to be executed after the play item is reproduced. That is, in the command table described later, the number of commands starting from the position indicated by the field PI_Command_start_id and indicated by the field number_of_PI_Commands are executed after playing the play item.

  A field number_of_PL_Commands represents the number of commands in the command table from the next line. The command table is configured by a for loop in which a field PL_Command (j) is listed. Numbers j are sequentially assigned to the commands in the command table. The number j corresponds to the loop counter j of the for loop for describing the command table. The field PL_Command (j) represents one command, and the number j is referred to from the above-described field Pre_Command_start_id, field Post_Command_start_id, and field PI_Command_start_id.

  FIG. 33 shows syntax that represents an example of the data structure of the file “entrylist.data”. In the file “entrylist.data”, a file identification symbol (field type_indicator), a version number (field version_number), and a block start address (field ScenarioEntry_start_address) are described first, followed by a block in which data for each function is collected. It is out.

  The field type_indicator has a data length of 32 bits and stores a specific character string indicating that this file is a file describing a title or a menu entry point. The field version_number has a data length of 32 bits and stores a version number. The field ScenarioEntry_start_address is an unsigned integer having a data length of 32 bits, and stores a value representing the position at which the block ScenarioEntry () starts with the relative number of bytes from the beginning of the file “entrylist.data”.

  FIG. 34 shows syntax that represents an example of the structure of a block AppInfo (). The field length is an unsigned integer having a data length of 32 bits, and describes the length from immediately after this field length to the end of the block AppInfo () in bytes. A field HDMV_name_character_set represents a character set describing a field HDMV_name described later. A field PIN_valid_flag indicates whether or not a password is set at the time of reproduction. When the setting is valid, the immediately following field PIN indicates a password. A field HDMV_name_length represents the length of the effective part of the next field HDMV_name. A field HDMV_name is an area in which a name assigned to the directory HDMV in which the file “entrylist.data” is stored is stored in a text format. The field HDMV_name has a fixed data length of 255 bytes. The part where the name is actually stored is from the beginning of the field HDMV_name to the length specified by the field HDMV_name_length.

  FIG. 35 shows syntax that represents an example of the structure of the block ScenarioEntry (). The block ScenarioEntry () lists the cue points in the scenario. Here, as described above, one scenario is created for the directory HDMV, and a playback order is defined by connecting a plurality of playlists placed under the directory HDMV. On the other hand, when viewed from the user, the scenario does not necessarily appear as one video / audio unit, but appears to be composed of a plurality of “titles”.

  For example, if three movies are recorded on one disc, there is only one scenario that defines the playback order on the disc, but the user seems to have three titles recorded on the disc. appear. Alternatively, a list of the three titles is displayed, and it appears that the title menu screen is divided into four titles including a title menu screen that allows the user to select. Since the menu screen is also a unit of video and audio for the user, it is regarded as a kind of title in the embodiment of the present invention.

  In this way, there is a difference between the unit called scenario that defines the connection of playlists and the unit that the user recognizes as a set of video and audio. Therefore, as described above, the cue point is defined in the scenario. It is necessary to keep. The cue point in this scenario is called a title entry. Information of the title entry is described in this block ScenarioEntry ().

  Returning to the description of FIG. 35, the field length is an unsigned integer having a data length of 32 bits, and stores the length immediately after this field length to the end of the block ScenarioEntry () in bytes. A field name_character_set represents a character set expressing a field TopMenu_name and a field Title_name which will be described later.

  The next block Top Menu PL () designates an entry point to a playlist or playlist group constituting a menu displayed when the user presses the title menu key of the remote controller. There is one top menu in the scenario, and for example, it is used as a menu for presenting a title to the user. A submenu for setting audio and subtitles can be provided as a lower menu for the top menu. The sub menu is also referred to as a stream setting menu.

  The field flags is an area representing attribute information related to the top menu, although details are omitted. A field TopMenu_ref_to_PlayList_file_name designates a playlist that constitutes the top menu or a playlist that serves as an entrance to a playlist group. The field TopMenu_ref_to_PlayItem_id specifies the number of the play item when the top menu is started from a specific play item in the playlist specified by the field TopMenu_ref_to_PlayList_file_name. In the case of playback from the top of the playlist, the value of the field TopMenu_ref_to_PlayItem_id is “0”. A field TopMenu_name_length represents the length of the name assigned to the top menu. A field TopMenu_name stores a character string of a name assigned to the top menu.

  Next to the block Top Menu PL (), information on the title is described. A field number_of_Titles represents the number of title cue points (title entries) in the for loop immediately after that. The field flags is an area representing attribute information related to the title, although details are omitted. A field Title_ref_to_PlayList_file_name represents a file name of a playlist including a title entry. The field Title_ref_to_PlayItem_id is used when a title starts from a specific play item in the playlist specified by the field Title_ref_to_PlayList_file_name. A field Title_name_length represents the length of the name given to the title. A field Title_name stores a character string of a name attached to a title.

  Next, information about the submenu is described. Below “Stream Setup Menu”, entry points to play lists or play list groups constituting stream setting menus (that is, sub-menus) that can be held for each play item are described. The stream setting menu can be used when a menu is individually prepared for each playlist, such as switching between audio, subtitles, and angles. For example, a screen displayed by pressing the buttons 64 and 65 in FIG. 20 described above is a submenu.

  A field number_of_PlayLists represents the number of playlists used for the stream setting menu. The value of this field number_of_PlayLists is used as the loop count of the immediately following for loop. The field SSMenu_flags is an area for storing attribute information related to the stream setting menu, although details are omitted. A field SSMenu_ref_to_PlayList_file_name designates a playlist that constitutes a stream setting menu or a playlist serving as an entrance to a playlist group. A field SSMenu_ref_to_PlayItem_id specifies the number of a play item when the stream setting menu is started from a specific play item in the playlist specified by the field SSMenu_ref_to_PlayList_file_name. If playback is from the beginning of the playlist, the value of the field SSMenu_ref_to_PlayItem_id is “0”.

  FIG. 36 shows syntax that represents an example of the structure of the file “xxxxx.mpls”. In FIG. 36, a file “xxxxx.mpls” includes blocks for each function-specific information. A character string indicating this file is stored in the field type_indicator, and the version of this file is indicated in the field version_number. In the fields PlayList_start_address and PlayListMark_start_address, the head address of the corresponding block is indicated as address information having a data length of 32 bits, for example.

  The block PLControlInfo () stores attribute information related to this playlist. The block PlayList () stores information regarding play items that constitute the play list. The block PlayListMark () stores information on marks attached to this playlist.

  In the file “xxxxx.mpls”, since the head addresses of the blocks PLControlInfo (), PlayList () and PlayListMark () are indicated before these blocks, an arbitrary length is placed before and / or after each block. Padding data padding_word can be inserted. However, the start position of the block PLControlInfo () that is the first block of the file “xxxxx.mpls” is fixed to the 41st byte from the beginning of the file.

  FIG. 37 shows syntax that represents an example of the structure of the block PLControlInfo (). This block PLControlInfo () stores various attribute information relating to the playlist that is not directly required for playback of the playlist. In the field PlayList_character_set, a character set of character string information related to the playlist is specified.

  The field PL_playback_type takes a value as shown in FIG. 38 as an example, and a normal playlist in which this playlist is played sequentially, a playlist in which play items are played back randomly, or a playlist in which play items are shuffled played back. Represents whether or not Random shuffle is specified in units of playlists. That is, a play item for normal reproduction and a play item block for random shuffle are not mixed in one play list. In the case of a reproduction-only recording medium, random reproduction or shuffle reproduction may be designated depending on the creator's intention, so such information is required.

  The field playback_count specifies the number of times the play item is played when this play list is a play list of random play or shuffle play. That is, the number of play items used for random playback or shuffle playback can be specified by this field playback_count.

  A field PL_UOP_mask_table () stores information for restricting user operations. If user operations such as playback, fast forward, and fast reverse are to be prohibited during playback of this playlist, appropriate designation is made in this area. For example, by setting the value in this field PL_UOP_mask_table () to a predetermined value, warning display and copyright display can be skipped by fast-forwarding so that they are not reproduced.

  The field PL_random_access_mode takes a value as shown in FIG. 39 as an example, and indicates whether or not random access for jumping into and playing back at an arbitrary position in this playlist is possible. For example, when there is a playlist that the user always wants to show to the user, the value of the field PL_random_access_mode is set to [0x1]. As a result, when this play list is reproduced, fast forward, fast reverse, reproduction from an arbitrary time, and the like become impossible. On a playback-only recording medium, there are cases where scenes that the user wants to show to the user, such as production company logos and precautions, are recorded. This field PL_random_access_mode is information necessary for preventing such a scene from being skipped by variable speed reproduction or the like.

  A field PlayList_duration indicates the playback time of the playlist. In the field PlayList_name, the play list name is indicated with the value indicated in the field PlayList_name_length as the effective length. In the field PlayList_detail, detailed information of the play list is indicated with the value indicated in the field PlayList_detail_length as an effective length.

  FIG. 40 shows syntax that represents an example of the structure of a block PlayList (). The field length indicates the byte length from the field immediately after the field length to the end of the block PlayList (). A field number_of_PlayItems indicates the number of play items constituting the play list. A field number_of_SubPlayItems indicates the number of auxiliary play items (sub play items) reproduced simultaneously with the main play item.

  The block PlayItem () stores play item information. The block SubPlayItem () stores information on sub play items.

  FIG. 41 shows syntax that represents an example of the structure of a block PlayItem (). In the field Clip_Information_file_name, the file name of a clip information file (file whose extension is “clpi”) one-to-one with the clip referred to by the play item is indicated by a character string.

  A field Clip_codec_identifier indicates an encoding method of a clip referred to by the play item. In this embodiment, the field Clip_codec_Identifier is fixed to the value “M2TS”. That is, in this embodiment, the clip encoding method referred to by the play item is fixed to the method indicated by the value “M2TS”.

  The flag is_multi_angle represents whether or not this play item has a multi-angle structure to be described later (first flag).

  The field connection_condition is information indicating how this play item and the next play item are connected. That is, the field connection_condition indicates whether or not play items can be reproduced seamlessly between play items.

  A field ref_to_STC_id specifies a sequence STC_sequence in the clip referred to by this play item. The sequence STC_sequence is a structure unique to the Blu-ray Disc standard that represents a continuous range of PCR (Program Clock Reference), which is a time axis reference in MPEG2 TS (Transport Stream). A number STC_id unique within the clip is assigned to the sequence STC_sequence. In this sequence STC_sequence, a consistent time axis without discontinuity can be defined, so that the start time and end time of a play item can be uniquely determined. That is, the start point and the end point of each play item must exist in the same sequence STC_sequence. In the field ref_to_STC_id, a sequence STC_sequence is specified by a number STC_id.

  Fields IN_time and OUT_Time indicate time stamps pts (presentation_time_stamp) on the sequence STC_sequence of the start point and end point of this play item, respectively.

  A field PI_UOP_mask_table () stores data for restricting user operations. The user operation restricted here should not react even if the user performs the operation. For example, when fast-forwarding is not executed on the menu screen, a setting is made to disable the fast-forwarding user operation here.

  Note that the field PI_UOP_mask_table () provided for each play item stores the same purpose information as the field PL_UOP_mask_table () provided in the block PLControlInfo () related to the play list reproduction described above. If the play list or play item prohibits it, the user operation is prohibited. In other words, a sum operation is performed on the play list information and the play item information, and the restriction on the user operation during playback of a play item is determined.

  The field PID_filter () is a table that determines the priority order of streams to be played back by this play item, although details are omitted.

  The field PI_random_access_mode takes a value as shown in FIG. 42 as an example, and indicates whether or not random access for jumping into and playing back at an arbitrary position in the play item is possible. For example, if there is a playlist that the user always wants to show to the user, the value of the field PI_random_access_mode is set to [0x1]. Thereby, when this play item is reproduced, fast forward, fast reverse, reproduction from an arbitrary time, etc. can be made impossible.

  The field still_mode is a field for determining whether to pause after playing the play item. The field still_mode takes a value as shown in FIG. 43. For example, when the value of the field still_mode is [0x1], the field still_mode indicates that the pause is performed, and the pause is performed for the time specified in the field of the next field still_time. I do. Thereby, it is possible to realize a reproduction such as a slide show in which still images are displayed one after another at regular intervals. In this case, each still image is a play item. Note that the field still_time can be set not only for a finite time but also for pause (pause setting) until the user inputs it. For example, setting the field still_mode to [0x2] enables the pause setting.

  If the value of the flag is_multi_angle described above is set to “1”, for example, the play item is determined to be multi-angle, and information for multi-angle is added below “Angle”.

  A field number_of_angles represents the number of angles. The field is_seamless_angle_change takes a value as shown in FIG. 44, and whether or not each angle is arranged on the disc so that the angles can be switched seamlessly, that is, between the angles can be switched smoothly. Represents

  In the next for loop, information on a clip constituting an angle is described. In the field Clip_Information_file_name in the for loop, the file name of the clip information file (file whose extension is “clpi”) corresponding one-to-one with the clip referred to by the play item is indicated by a character string. A field ref_to_STC_id specifies a sequence STC_sequence in the clip referred to by this play item.

  Here, the angle corresponding to the value angle_id = 0 is already defined in the first half of this block PlayItem (), as in the case of a normal play item that does not constitute an angle. Angles after the value angle_id = 1 are defined in this for loop. Therefore, the angle corresponding to the value angle = 0 is not included in this for loop.

  FIG. 45 shows syntax that represents an example of the structure of a block SubPlayItem (). The field length represents the length from the field immediately after this to the end of SubPlayItem () in bytes. In the field Clip_Information_file_name, the file name of the clip information file (file whose extension is “clpi”) corresponding one-to-one with the clip referred to by this sub play item is indicated by a character string.

  A field Clip_codec_identifier indicates a coding scheme of a clip referenced by the sub play item. In this embodiment, the field Clip_codec_Identifier is fixed to the value “M2TS”.

  The field is_repeat_flag takes a value as shown in FIG. 46, and indicates whether or not this sub play item is repeatedly reproduced asynchronously with the main play item (main path). For example, when the value of this field is_repeat_flag is “1”, this sub play item is repeatedly reproduced asynchronously with the main play item until the reproduction of the main play item is completed. When the value of this field is_repeat_flag is “0”, this sub play item is reproduced only once in synchronization with the main play item.

  For example, when this sub play item is an audio-only sub play item, BGM (Back Ground Music) playback can be performed by setting the value of the field is_repeat_flag to “1”.

  A field SubPlayItem_type represents what kind of property the sub play item has. For example, if the value of the field SubPlayItem_type is “1”, it represents an audio-only sub play item.

  A field ref_to_STC_id specifies a sequence STC_sequence in the clip referred to by this play item. Fields SubPlayItem_IN_time and SubPlayItem_OUT_Time indicate time stamps pts (presentation_time_stamp) on the sequence STC_sequence of the start point and end point of this sub play item, respectively.

  When the value of the above-mentioned field is_repeat_flag is “0”, for example, indicating that this sub play item is played back in synchronization with the main play item, the sub play item is the main play item by the field sync_PlayItem_id and the field sync_start_PTS_of_PlayItem. The time at which the item is to be synchronized and played is specified.

  As an example is shown in FIG. 47, the play item of the main path is designated by the field sync_PlayItem_id (PlayItem = 1), and the time on the main play item at which the sub play item starts to be reproduced is represented by the field sync_start_PTS_of_PlayItem ( t1). In addition, as a sub play item, it is indicated that a corresponding clip is reproduced for a period specified by a field SubPlayItem_IN_time and a field SubPlayItem_OUT_time.

  FIG. 48 shows syntax that represents an example of the structure of the file “zzzzz.clpi”. In FIG. 48, the file “zzzzz.clpi” includes blocks for each function-specific information. A character string indicating this file is stored in the field type_indicator, and the version of this file is indicated in the field version_number. The field SequenceInfo_start_address, the field ProgramInfo_start_address, the field CPI_start_address, and the field ClipMark_start_address each indicate the start position of the corresponding block.

  FIG. 49 shows syntax that represents an example of the structure of the block ClipInfo (). The field length represents the length from the immediately following field to the end of the block ClipInfo () in bytes. A field Clip_stream_type represents the type of the clip AV stream. In the reproduction-only standard, a value indicating that the clip is a normal clip, for example, a value “1” may be fixed.

  The field application_type indicates how the clip AV stream (file with extension “m2ts”) is created. The field application_type takes a value as shown in FIG. 50 as an example, and indicates whether this clip AV stream is a normal video stream or a stream that is multiplexed suitable for displaying a still image.

  More specifically, according to this example, the value of the field application_type is “1”, which indicates that the file of the corresponding clip AV stream complies with the rules of the HDMV transport stream according to this embodiment. At this time, a normal moving image is reproduced from the clip AV stream.

  The value of the field application_type is “2”, which indicates that the corresponding clip AV stream file complies with the HDMV transport stream rules for still images synchronized with audio playback. At this time, the clip AV stream is, for example, an MPEG2 format file, and video data and audio data are multiplexed. The video data is configured such that, for example, I pictures in MPEG2 are arranged as still images. Thereby, for example, playback such as a slide show displayed in synchronization with the audio time axis is possible. Such reproduction is referred to as a time-based slide show.

  The value of the field application_type is “3”, which indicates that the corresponding clip AV stream file complies with the HDMV transport stream rules for still images that are reproduced asynchronously with the audio. At this time, the audio data and the video data are separate files. For example, while the audio data is being reproduced, the video data is displayed by switching the still image based on an arbitrary interval or user designation. Similar to the above, the video data can be configured such that, for example, MPEG2 I pictures are arranged as still images. Such reproduction is called a browsable slide show.

  When the value of the field application_type is “0”, the corresponding clip AV stream does not comply with the rules of the HDMV transport stream.

  Here, multiplexing suitable for still image display mainly assumes that an application such as a still image slide show is easily realized. In such an application, if one still image and subtitles or graphics data superimposed thereon are encapsulated and multiplexed, reading becomes easy.

  If multiplexing is performed in the same way as a normal moving image, the subtitles that should be displayed simultaneously with a certain still image are multiplexed near the image data of the previous still image (so-called multiplexing phase difference) If a wider range of stream data is not read, it is not possible to display one still image in which subtitles and graphics are superimposed.

  That is, in one embodiment of the present invention, graphics data for displaying video data or subtitles is stored and transmitted in a TS (Transport Stream) packet in MPEG. One TS packet consists of 188 bytes, and the video data and graphics data described above are divided so as to fit in each TS packet and stored in the TS packet. At this time, if a subtitle data packet corresponding to a certain still image data (referred to as image P1) is placed behind a packet of the subsequent still image data (referred to as image P2), it corresponds to the image P1. In order to display subtitles, data must be read to the end of the image P2.

  If multiplexing is performed only for one still image and its accompanying subtitles and graphics (encapsulation), a stream in which no other data is mixed can be created. By repeating this process for each still image and connecting streams, a single stream in which data for each still image (and subtitles and graphics data attached to the still image) are connected in series can be created. The multiplexed stream is used as a still picture HDMV stream.

  Furthermore, as described above, there are two types of still picture HDMV streams: a time-based slide show and a browsable slide show. In this embodiment, the two types are distinguished by assigning different numbers in the field application_type.

  Thus, by encapsulating and recording a still image and subtitles and graphics associated therewith, the accessibility when playing back while switching still images is improved.

  Returning to the description of FIG. 49, the field TS_recording_rate represents the recording rate of the clip AV stream file in bytes / second. A field num_of_source_packets represents the number of packets included in the clip AV stream. Since the field BD_system_use and the block TS_type_info_block () are not related to the present invention, their descriptions are omitted.

  FIG. 51 shows syntax that represents an example of the structure of block SequenceInfo (). The field length represents the length from the field immediately after this to the end of the block SequenceInfo () in bytes. A field num_of_ATC_sequences indicates the number of sequences ATC_sequence indicating that recording was performed at consecutive times. In the case of a read-only medium, the number of sequences ATC_sequence can be set to “1”, and the details are omitted. The field SPN_ATC_start indicates the start of the sequence ATC_sequence with a packet number. When the number of the sequence ATC_sequence is one, the field SPN_ATC_start coincides with the head of the clip AV stream file and the value is “0”.

  A field num_of_STC_sequences represents the number of sequences STC_sequence on the sequence ATC_sequence. In the case of a read-only medium, the number of sequences STC_sequence can be set to “1”, and the details are omitted. The field offset_STC_id has a fixed value of “0”. A field PCR_PID represents the PID of a TS packet including a PCR (Program Clock Reference) in MPEG2 TS. The field SPN_STC_start indicates the start of the sequence STC_sequence with a packet number. When the number of the sequence STC_sequence is one, the field SPN_STC_start coincides with the head of the clip AV stream file and has a value “0”. A field presentation_start_time and a field presentation_end_time represent a valid range in the clip AV stream. The range indicated by the field presentation_start_time and the field presentation_end_time is a range that can be referred to from the play item.

  FIG. 52 shows syntax that represents an example of the structure of the block ProgramInfo (). In this case, the syntax structure for the recording / reproducing medium can be applied to the reproduction-only medium, and since there is no new structure, a detailed description is omitted. However, restrictions such as the value of the field num_of_program_sequences being “1” and the value of the field num_of_groups being “1” can be added.

  FIG. 53 shows syntax that represents an example of the structure of a block StreamCodingInfo (). This also has substantially the same structure as the recording / playback medium syntax structure, similar to the above-mentioned block ProgramInfo (), and for video data, attribute information such as the format of the video data, frame rate, aspect ratio, audio data As for, attribute information such as sampling frequency is described. However, when applied to a read-only medium, as shown in FIG. 53, it is necessary to add a field language_code representing the language of the caption and audio stream. This information is useful when selecting the optimal audio / subtitle language according to the language setting of the player.

  FIG. 54 shows syntax that represents an example of the structure of a block CPI (). In general, in an encoded stream such as an MPEG stream in which inter-frame compression is performed, a portion where decoding can be started is limited to a portion such as the top of a GOP (Group Of Picture). CPI (Characteristic Point Information) is a database that collects information on the position of a start point that can be decoded, and is a table in which a reproduction time is associated with an in-file address. That is, the CPI is a table of information indicating the head position of the decoding unit.

  By defining the database in this way, for example, when reproduction is desired from an arbitrary time, the address in the file at the reproduction position can be known by referring to the CPI based on the reproduction time. Since this address is the head of the decoding unit, the player can read out the data from it and decode it to display the image quickly.

  Note that the start position of the decode unit (in this example, the start position of the GOP) stored in the CPI is referred to as an EP (Entry Point) entry.

  A field CPI_type represents the type of CPI and takes a value as shown in FIG. In the case of the present invention, the value indicates that the CPI is for a read-only medium. Specifically, the value is set to “8”, indicating that an EP entry map (EP_map_type_for_HDMV) for HDMV is stored.

  FIG. 56 shows a syntax representing an example data structure of the map EP_map of the EP entry for the read-only medium, that is, the block EP_map_for_HDMV () in the field CPI_type described above. The map EP_map is a table in which the reproduction time and the address in the file are associated with each other at the head position of the GOP. In the example of FIG. 56, a database is created as a table in which MPEG PTS (Presentation Time Stamp) and SPN (Source Packet Number) are associated with each other at the head position of GOP. SPN indicates a source packet number and corresponds to a byte address from the beginning of the file.

  The structure of the map EP_map for recording and reproduction and the structure of the map EP_map for this reproduction-only medium are substantially the same. In this embodiment, in order to reduce the amount of data and speed up the search, each value is divided into coarse and fine, and a search in coarse units (coarse) and a search in finer units (fine ) Can be performed separately. Therefore, the internal structure is divided into two for loops corresponding to coarse and fine, respectively, which is slightly more complicated than the simple table “PTS vs. file address of first I picture of GOP”. .

  A field EP_fine_table_start_address indicates the position of the table for performing the above-described finer search. In the next for loop, a table for coarse search (coarse) is stored by fields PTS_EP_coarse and SPN_EP_coarse, and a table for fine search (fine) referenced from rough units by field ref_to_EP_fine_id Is described. Fields PTS_EP_coarse and SPN_EP_coarse indicate the higher-order bits of PTS and SPN, respectively.

  Next, a for loop storing fields PTS_EP_fine and SPN_EP_fine for performing a precise search is arranged with a padding word interposed therebetween. In addition, a flag is_angle_change_point and a field I_end_position_offset are stored. Although details will be described later, a flag is_angle_change_point indicates whether each EP entry corresponds to an angle switchable point when the clip AV stream forms a multi-angle (second flag).

  Here, the flag is_angle_change_point will be described. First, in order to facilitate understanding, how the clip AV stream is arranged on the disc will be described.

  The clip AV stream is composed of an array of blocks (blocks) of data with continuous logical addresses on the disk 10. Hereinafter, a block of data in which logical addresses on the disc are continuous by the clip AV stream is referred to as an extent. FIG. 57 schematically shows how extents are arranged on a disk. In the example of FIG. 57, one clip AV stream is composed of an array of three extents 601A, 601B, and 601C. The length of the extent and its placement are properly controlled during disk creation.

  At this time, if the extents 601A, 601B, and 601C are configured so as to comply with the definition of the minimum size of the extent and the clip AV stream is recorded on the disc 600, continuous supply of data is guaranteed at the time of reproduction.

  As shown in FIG. 57, when one file is composed of a plurality of extents 601A, 601B and 601C, the extents are read one after another from one extent 601A to the next extent 601B in order to read the file. The operation is repeated. When reading the next extent 601B after reading a certain extent 601A, it is necessary to change the number of revolutions of the disk 600 and move the optical pickup constituting the reading unit for the disk 600 in the player.

  The access time when the optical pickup is moved on the disk 600 is about 0.8 seconds at the maximum. During the movement of the optical pickup, data can be taken out from the drive constituting the disk reading unit. Can not. On the other hand, since video and audio are decoded and reproduced continuously, a mechanism that absorbs the influence of this access time is required.

  An access jump occurs between a certain extent 601A and the next extent 601B. When the byte length of the previous extent 601A is large, a sufficient amount of data can be read from the extent 601A and stored in the buffer before the jump. For this reason, even during the jump, the data stored in the buffer can be supplied to the decoder to continuously decode.

  That is, if the size of the extent 601A before the jump is sufficiently large, it is possible to guarantee continuous supply of the stream even while jumping to the next extent 601B. Therefore, in order to be able to store a sufficient amount of data in the buffer, the lower limit of the extent size may be limited. The minimum extent size is determined as a unique value from the read rate from the disk 600 and the access time of the drive. The condition for continuous data supply can be determined by whether or not data is arranged in compliance with the minimum size specification of extents.

FIG. 58 shows an example of a state in which the clip AV stream is fragmented and recorded on the disc like the extents 601D and 601E. In FIG. 58, in order to guarantee that the recorded clip AV stream can be read from the recording medium at a predetermined bit rate, the size of one extent (referred to as size S) is expressed by the following equation (1). It is necessary to satisfy the conditions as indicated.
S × 8 / (S × 8 / Rud + Ts)> = Rmax (1)

  In Expression (1), “S” represents the extent size in bytes, and “Ts” represents the full stroke access time from one extent 601D to the next extent 601E, that is, the maximum access time in seconds. “Rud” represents the bit rate of reading from the disc, and “Rmax” represents the bit rate of the clip AV stream. The units of “Rud” and “Rmax” are bits / second. Note that “8” multiplied by the extent size S is for byte / bit conversion.

  That is, if the data of the clip AV stream is continuously arranged so that the sizes of the extents 601D and 601E are S bytes or more, the arrangement of the extents 601D and 601E can be seamlessly reproduced.

When the equation (1) is transformed, the following equation (2) is obtained.
S × 8> = Rmax · Rud · Ts / (Rud−Rmax) (2)
When specific numerical values are calculated based on the equation (2), for example, when the clip AV stream has a bit rate Rmax = 28 (bits / second), Rud = 35 Mbps (Mega Bit per second), Ts = 0.8 Assuming seconds, S> = 14 MB (Mega Byte). That is, in this example, the minimum extent size S is 14 MB.

  As described above, it is possible to determine conditions for continuous data supply when continuously reading one file. This can also be applied to the realization of a seamless angle switching function that seamlessly switches the angle to be read in the multi-angle function.

  The multi-angle function will be described with reference to FIG. As shown in FIG. 59A, the multi-angle function has a section (multi-angle block) in which a plurality of playback paths are prepared, and the user can freely select an angle he / she wants to see while playing the section. It is a function that can be changed. For example, such a multi-angle block can be configured by photographing the same object in parallel with a plurality of cameras while changing the angle.

  In addition, the image | video which comprises a multi angle is not restricted to what was targeting the same scene. A multi-angle can be constituted by a plurality of videos intended to be selectively displayed at the same time on the playback time series.

  The multi-angle block is composed of one play item. That is, one play item includes videos of a plurality of angles. In the example of FIG. 59A, three angles (angle (0), angle (1), and angle (2)) can be selected in the multi-angle block.

  In the multi-angle block, in order to shorten the access time when switching between the angles, as shown in an example in FIG. 59B, each stream constituting the multi-angle is recorded in a special arrangement on the disc. This is called an interleave block, and one continuous portion is called an interleave unit. The interleave unit is recorded at continuous addresses on the disc and satisfies the condition of the minimum extent size. The interleave block is a group of interleave units corresponding to each angle in time, arranged in order of angle, and further arranged in time series.

  If the angle is switched in units of interleave units, jumps are always made after reading the minimum extent size, so that the above-mentioned conditions for continuous data supply are satisfied. Furthermore, seamless angle switching can be realized by aligning the head of the GOP with the head of the interleave unit so that MPEG decoding is always possible from the head of the interleave unit.

  Here, consider a position where seamless angle switching is possible. From the nature of the MPEG stream that performs inter-frame compression and the condition of continuous data supply from the disc, it can be seen that angle switching cannot be performed at any byte position. The simplest method is to enable switching in units of interleave units that satisfy the minimum extent size. Furthermore, if the head of the interleave unit and the head of the GOP, that is, the EP entry are matched, the MPEG stream can be decoded continuously.

  Here, for example, if the angle switchable points are increased and the number of interleave blocks is increased by interleaving, one file is cut into pieces, and the management information of the file system increases. For example, in the Blu-ray Disc file system, when a file is divided into a plurality of extents, the number of disk regions increases, the file system database becomes larger, and the upper limit of the number of files that can be recorded becomes smaller. come.

  Therefore, in the embodiment of the present invention, as shown in an example in FIG. 60, the size of one interleave unit is increased, the number of interleave units in the interleave block is reduced, and a plurality of interleave units are included in one interleave unit. An angle switchable point is provided. Since the angle switchable point is also a start point that can be decoded, it matches any EP entry.

  The flag is_angle_change_point described above indicates whether or not the EP entry pointing to the head of the GOP corresponds to an angle switchable point. The flag is_angle_change_point takes a value as shown in FIG. 61, and the flag is_angle_change_point is “1”, indicating that the EP entry is an angle switchable point. The value “0” indicates that the EP entry is It is shown that it is not an angle switchable point.

  Whether or not a certain EP entry can be a seamless angle switching point can basically be determined by whether or not the EP entry and the previous angle switching point are at least the size of the minimum extent. That is, the interval between the angle-switchable EP entries whose flag is_angle_change_point value is “1” needs to be more than the minimum extent size.

  Next, a seamless angle switching operation using this flag is_angle_change_point will be described with reference to FIG. In FIG. 60, a point indicated by an upward arrow is an angle switchable point. On the disc, as shown in an example in FIG. 60B, a point indicated by an upward arrow is an EP entry in which the angle can be switched, and the flag is_angle_change_point is set to a value “1”.

  Referring to FIG. 60A, for example, assume that the user switches from angle (0) to angle (1) during angle playback. At that time, the player continues to read the stream of the angle up to the point where the flag is_angle_change_point has the value “1” among the EP entries nearest to the angle (0). Next, the EP entry in the angle (1) at the same time as the time of the EP entry is searched from the clip information file, the byte position in the file is acquired, and reading is started therefrom. With the above operation, seamless angle switching can be realized.

  As an example of the playback path on the disc at this time, as shown in FIG. 60B, a jump between angles is performed at a position where the flag is_angle_change_point is “1”.

  Next, consider the case of non-seamless angle switching. Non-seamless angle switching refers to angle switching in which discontinuity may occur in the video when the angle is switched. In the case of seamless angle switching, as described above, when angle switching is specified, playback is performed up to the point where the angle can be switched and the angle switching is executed. However, in the case of non-seamless angle switching, continuous data supply or GOP switching is performed. Since the angle switching is designated and the angle can be switched immediately without considering the first condition, there is an advantage that the time until the switching is short.

  FIG. 62 shows an example of a non-seamless multi-angle block. In the case of non-seamless angle switching, since the image may be discontinuous, it is not always necessary to move to another angle at the same time. For example, the angle may be exited during GOP playback, and the jump may be made to the head of the nearest GOP before that time. As illustrated in FIG. 62A, when jumping from the angle (0) to the angle (1), the head of the GOP is searched for at the angle (1). In this example, the angle (1 ) Is playing. FIG. 62B shows a reproduction path on the disc at this time.

  On the other hand, even for a non-seamless multi-angle block, the connection at the exit of the multi-angle block is required to be seamless. This is a very effective way to improve the playback quality when the angle is never switched, so that there is no discontinuity in the image at the entrance and exit of the multi-angle block as in normal playback. Because it is.

  In the embodiment of the present invention, the connection point between the multi-angle block and the main part is seamlessly connected in the non-seamless multi-angle block by setting the flag is_angle_change_point.

  First, seamless connection at the entrance from the main part to the angle block is relatively easy to realize. In other words, if the end of the main part (that is, the rear end of the play item immediately before the entrance of the non-seamless multi-angle block) is arranged so as to satisfy the conditions of the minimum extent size, it can be seamlessly connected to any angle from the main part. can do.

  On the other hand, in the vicinity of the exit connecting through the angle block and connecting to the main part, for example, when angle switching is performed as shown in the route shown in FIG. Data up to the end of does not meet the minimum extent size. For this reason, in the jump at the exit of the multi-angle block, the condition for continuous data supply is not satisfied, and discontinuities such as a video pause or a black screen appear. FIG. 63B shows the playback path on the disc at this time.

  In the example of FIG. 63A, the position extending from the angle (2) to the angle (1) to the exit of the multi-angle block does not satisfy the minimum extent size. For this reason, when moving from the angle (1) to the main part, the amount of data read from the angle (1) is insufficient, and discontinuity of the reproduced video occurs.

  In the embodiment of the present invention, the flag is_angle_change_point is also used in the non-seamless angle switching block in order to solve the problem in the non-seamless angle switching. During playback of a non-seamless multi-angle block, discontinuity may occur at the time of angle switching, so basically the values of the flags is_angle_change_point are all “1” as shown in FIG. 63B described above. . In other words, it is possible to jump out from the angle being reproduced at an arbitrary location, and to jump into an arbitrary location and perform reproduction.

  Here, the definition of the flag is_angle_change_point in the clip in the non-seamless multi-angle block is defined. As described above, in an area where the value of the flag is_angle_change_point is “0”, angle switching (jumping) to another angle during reproduction and reproduction position interruption (jumping) from the original angle at which the switching occurred are prohibited. In addition, it is assumed that the area where the value of the flag is_angle_change_point is “1” can jump out and jump in. Then, the value of a predetermined number of flags is_angle_change_point near the exit of each angle is set to “0”, and jumping out or jumping in an area where the value of the predetermined number of flags is_angle_change_point is set to “0” is prohibited. At this time, the size of the area in which the value of the predetermined number of flags is_angle_change_point is “0” is equal to or larger than the minimum extent size.

  By setting the flag is_angle_change_point in this way, even in a non-seamless multi-angle block, jumping in and jumping out just before the exit of the multi-angle block can be prohibited.

  As an example, as shown in FIG. 64B and FIG. 65B, the six EP entries on the rear end side of each interleave unit are set as areas where the value of the flag is_angle_change_point is “0”, and the other EP entries are set in the flag is_angle_change_point. Set the value to be “1”.

  Next, a method for reproducing a non-seamless multi-angle block in which the flag is_angle_change_point is set as described above will be described. The first method is a method of prohibiting angle switching in an area where the value of the flag is_angle_change_point is “0”.

  This will be described with reference to FIG. As described above, the value of the flag is_angle_change_point is set to “0” in the six EP entries on the rear end side of each interleave unit (FIG. 64B). As shown in an example in FIG. 64A, when the playback position enters an area where the value of the flag is_angle_change_point is “0”, angle switching is prohibited. For example, even if the user performs an operation for instructing angle switching in this area, the player ignores it. In this example, the angle is not switched, and the multi-angle block is left as it is and the play item of the main part is transferred. The reproduction path on the disc in this case is shown in FIG. 64B.

  The second method is a method in which angle switching in an area where the value of the flag is_angle_change_point is “0” is permitted, but the jump destination after the switching is a place where the value of the flag is_angle_change_point is “1”.

  This will be described with reference to FIG. As described above, the value of the flag is_angle_change_point is set to “0” in the 6EP entries on the rear end side of each interleave unit (FIG. 65B). As an example shown in FIG. 65A, in the multi-angle block, when angle switching is designated within a position less than the minimum extent size from the block exit, that is, in an area where the value of the flag is_angle_change_point is “0”, At the switched angle, the playback position is returned to the area where the value of the flag is_angle_change_point is “1”, and playback is continued from that position. The reproduction path on the disc in this case is shown in FIG. 65B.

  Regardless of which of the first and second methods is used, when jumping at the exit of the multi-angle block, the next play item is reproduced after reading data of the minimum extent size or more. Thereby, it is possible to prevent the reproduction from becoming discontinuous (non-seamless) at the exit of the angle block.

  In FIG. 64 described above, the interleave block is configured by the non-seamless multi-angle block. However, in the non-seamless multi-angle block, as shown in FIG. 65, the block can be configured without the interleave arrangement.

  FIG. 66 is a functional block diagram showing a structure of an example of a player decoder 100 'applicable to the embodiment of the present invention. The player decoder 100 'interprets data reproduced from a disc loaded in a drive device (not shown), outputs an AV stream, and enables an interactive operation by the user on the output AV stream.

  Note that the overall operation of the player decoder 100 'is controlled by a CPU (not shown). For example, the stream and data flow in each part of the player decoder 100 'are monitored and controlled by the CPU.

  When a disc is loaded in a drive device (not shown), as described above, first, the file “scenario.hdmv” and the file “entrylist.data” are played, and the file “scenario.hdmv” and the file “entrylist.data” Based on the description, other necessary files are read and the content recorded on the disc is reproduced. For example, based on the description of the file “scenario.hdmv” and the file “entrylist.data”, moving image data to be displayed on the moving image plane 10, image data to be displayed on the subtitle plane 11 and the graphics plane 12, a playlist file, etc. Is read from the disk.

  Hereinafter, among these data read from the disc, a stream that needs to be continuously processed, such as moving image data, sub-picture (caption data), and audio data, is referred to as a real-time stream. Non-real-time data that does not require continuous processing, such as a scenario file and a playlist file, is referred to as a store object. Store objects are stored and expanded on a memory or the like and processed as necessary.

  The player decoder 100 'has two input channels of channels (1) and (2), and the store object is input to the input terminal 101 of the input channel (1). A real-time stream is input to the input terminal 202 of the input channel (2). A store object can also be input to the input terminal 202. In this embodiment, the real-time stream and some store objects input to the input terminal 202 are MPEG2 TS.

  For example, in the drive device, the rotation speed of the disk is set to a high speed such as double speed to increase the read transfer rate from the disk and operate in a time-sharing manner, so that channels (1) and (2) 2 System readout can be realized.

  First, the system of the input channel (1) will be described. The store object input to the input terminal 101 is input to the switch circuit 102. When the program code in the file “scenario.hdmv” is input as the store object, the output terminal 102A is selected in the switch circuit 102 and the input program code is stored in the code buffer 104. Other programs that can be used include HTML documents and ECMA scripts.

  On the other hand, when image data or audio data is input as a store object, the output terminal 102 B is selected in the switch circuit 102, and the input image data is input to the switch circuit 103. When the real-time stream input to the input terminal 202 does not include image data to be displayed on the subtitle plane 11 or the graphics plane 12, the switch circuit 103 selects the input terminal 103 </ b> A and inputs from the switch circuit 102. The processed image data and audio data are stored in the content buffer 105.

  Similarly, when the real-time stream input to the input terminal 202 includes image data to be displayed on the subtitle plane 11 or the graphics plane 12 or audio data for sound effects, the switch circuit 103. The input terminal 103B is selected and the image data / audio data is stored in the content buffer 105. Store objects stored in the code buffer 104 and the content buffer 105 are read as necessary and supplied to the multimedia engine 106.

  Of the store objects stored in the content buffer 105, the image data is also supplied to the graphic decoder A500 and the graphic decoder B301 via the switch circuits 107 and 108, respectively.

  In the example of FIG. 66, the graphics decoder A300 decodes PNG format image data, and the graphics decoder B301 decodes JPEG format image data. Note that the graphics decoders A300 and B301 are not limited to this, and may decode image data of other data formats, or may support image data of a plurality of formats.

  The multimedia engine 106 includes an XML parser 106A, a script interpreter 106B and a graphics renderer 106C, a sound player 106D for reproducing sound effects, and a scenario file analysis engine 106E. The multimedia engine 106 may be configured by independent hardware, or may be realized by processing based on a predetermined program of a CPU (not shown) described above.

  The XML parser 106A has a function of analyzing an XML (Extensible Markup Language) document and can also analyze an HTML document. The HTML document interpreted by the XML parser 106A is converted into a format that can be executed by the player decoder 100. The script interpreter 106B analyzes the ECMA script and converts it into a format executable by the player decoder 100. In addition, the graphics renderer 106C decodes the image data into a format that can be developed on the caption plane 11 and the graphics plane 12. The sound player 106D reproduces audio data used for button click sounds and the like.

  In the multimedia engine 106, processing of these XML parser 106A, script interpreter 106B, and graphics renderer 106C is performed using the buffer 109 as a work memory. For example, the code buffer 109A among the buffers 109 is used by the XML parser 106A and the script interpreter 106B. The graphics renderer 106C uses the graphics buffer 109D among the buffers 109. In addition to the above-described code buffer 109A and graphics buffer 109D, the buffer 109 includes a font buffer 109B that stores font data used to display a character string, and a hierarchical tree structure obtained by analyzing an HTML document by the XML parser 106A. For example, a tree buffer 109C. The sound player 106D reproduces the audio data stored in the sound buffer 109E.

  In the multimedia engine 106, for example, a scenario file “scenario.hdmv” stored in the code buffer 104 is read, and the scenario analysis engine 106E analyzes the scenario based on the description of the read file. Then, a drive device (not shown) is controlled based on the analyzed scenario description, and the moving image data to be displayed on the moving image plane 10, the subtitle plane 11 and the graphics plane 12 are displayed from the disc inserted in the drive device. Necessary files such as image data and audio data are read and the content is reproduced.

  The data stored in the code buffer 104 and the content buffer 105 can be held in the code buffer 104 and the content buffer 105 until the data is no longer needed. Therefore, the data stored in the code buffer 104 and the content buffer 105 can be read and used as many times as necessary.

  Further, in the multimedia engine 106, for example, an ECMA script stored in the code buffer 104 is read, and another ECMA script or HTML document from the code buffer 104 is read out as needed based on the description of the read ECMA script. And image data from the content buffer 105 are read.

  In addition to the above, the multimedia engine 106 performs demultiplex processing of a plurality of types of input data, a JavaVM (Java (registered trademark) virtual machine) function, and the like. Further, the multimedia engine 106 receives an input from an operation unit (not shown) from a user, such as a remote control commander or a pointing device, and processes it in a predetermined manner. The user input is also supplied to a graphic decoder A300, a graphic decoder B301, an audio decoder 118, an MPEG video decoder 120, and a system decoder 121, which will be described later.

  The image data processed by the graphics renderer 106C is supplied to the sub-picture plane 302 and the graphics plane 303 via the switch circuits 130 and 131, respectively. In this example, it is assumed that the image data supplied to the sub-picture plane 502 and the graphics plane 303 is bitmap data after image data in PNG format or JPEG format is decoded by the graphics renderer 106C. The timing at which image data is supplied to each of these planes 302 and 303 is controlled by the multimedia engine 106.

  Here, the sub-picture plane 302 and the graphics plane 303 correspond to the caption plane 11 and the graphics plane 12 described above, respectively. The moving image plane 135 corresponds to the moving image plane 10 described above. Note that the sub-picture plane 302, the graphics plane 303, and the moving image plane 135 are composed of, for example, a frame memory.

  The multimedia engine 106 further supplies a control signal for switching or synthesizing the moving image plane 135, the sub-picture plane 302, and the graphics plane 303 to the presentation processor 139 described later. Similarly, the multimedia engine 106 supplies a control signal for controlling the output of the audio stream to the presentation processor 141 described later.

  Next, the system of the input channel (2) will be described. The real-time stream input in the MPEG2 TS to the input terminal 202 is supplied to the PID filter 110, the PID (Packet Identification) stored in the MPEG2 TS transport packet is extracted, and the stream stored in the transport packet is extracted. An attribute is detected. In the PID filter 110, the input real-time stream is distributed to a system corresponding to each transport packet based on the stream attribute.

  If the transport packet is a packet in which image data belonging to the store object is stored based on the PID, the transport packet is temporarily stored in the buffer TBn 111A, read at a predetermined timing, and input to the input terminal. 103B is input to the selected switch circuit 103 and stored in the content buffer 105 via the switch circuit 103.

  In the PID filter 110, if the transport packet is a packet in which PNG format data is stored based on the PID, the transport packet is temporarily stored in the buffer TBn 111B and the buffer Bn 112B, and at a predetermined timing. The input terminal 107B is read and input to the selected switch circuit 107, and is supplied to the graphic decoder A 500 via the switch circuit 107.

  The graphic decoder A300 removes the header information of the supplied transport packet and decodes the PNG data stored in the transport packet into image data for displaying subtitles or graphics. When this image data is used as subtitles, it is input to the input terminal 130B of the switch circuit 130 at a predetermined timing, and is developed on the sub-picture plane 302 via the switch circuit 130. Similarly, when used as a button, in order to display on the graphics plane, it is input to the input end 131C of the switch circuit 131 at a predetermined timing, and developed on the graphics plane 303 via the switch circuit 131.

  If the PID filter 110 determines that the transport packet is a packet storing JPEG data based on the PID, the transport packet is temporarily stored in the buffer TBn 111C and the buffer Bn 112C and read at a predetermined timing. The input terminal 108B is input to the selected switch circuit 108 and supplied to the graphic decoder B500 via the switch circuit 108.

  The graphic decoder B301 removes the header information of the supplied transport packet and decodes the JPEG data stored in the transport packet into bitmap image data. When this image data is used as subtitles, it is input to the input terminal 130C of the switch circuit 130 at a predetermined timing, and is developed on the sub-picture plane 302 via the switch circuit 130. Similarly, when used as a button, in order to display on the graphics plane, it is input to the input end 131B of the switch circuit 131 at a predetermined timing, and is developed on the graphics plane 302 via the switch circuit 131.

  In the PID filter 110, if the transport packet is a packet in which audio data is stored based on the PID, the transport packet is temporarily stored in the buffer TBn111D and the buffer Bn112D and read at a predetermined timing. And supplied to the audio decoder 118. Audio data stored in the transport packet is compressed and encoded by a method based on, for example, Dolby Digital.

  The audio decoder 118 includes, for example, a linear PCM (Pulse Code Modulation) audio decoder 119, removes header information of the input transport stream, and compresses and encodes audio data stored in the transport packet. Decode and finally convert to linear PCM audio data. When linear PCM audio data that is not compressed and encoded is stored in the transport packet, the data is input to the linear PCM audio decoder 119 as it is, for example, and is output without being processed.

  The linear PCM audio data output from the audio decoder 118 is input to the audio presentation processor 141, added with a predetermined acoustic effect based on the control of the multimedia engine 106, and derived to the output terminal 142.

  In the PID filter 110, if the transport packet is a packet storing moving image data based on the PID, the transport packet is temporarily stored in the buffer TBn111E, the buffer MBn113, and the buffer EBn114, It is read out at timing and supplied to the MPEG video decoder 120. The moving image data stored in the transport packet is compressed and encoded by the MPEG2 system.

  The MPEG video decoder 120 removes the header information of the supplied transport packet and decodes the moving image data compressed and encoded by the MPEG2 method stored in the transport packet into baseband moving image data. .

  The moving image data output from the MPEG decoder 120 is input to the input terminal 124A of the switch circuit 124 and also input to the input terminal 124B of the switch circuit 124 via the buffer 123. In the switch circuit 124, the input terminals 124A and 124B are selected at a predetermined timing, and the output moving image data is developed on the moving image plane 134.

  In the PID filter 110, if the transport packet is a packet in which system information is stored based on the PID, the transport packet is supplied to the system decoder 121 via the buffers TBn 111F and Bsys 115. In the system decoder 121, the head information of the supplied transport packet is removed, and the stored system information is extracted. The system information is passed to a CPU (not shown), for example.

  The image data on the sub-picture plane 302 is supplied to the palette 304 corresponding to the palette table 22 in FIG. 17 described above, and the palette consisting of 256 colors is referred to by an index, and RGB data is output. Transparency data α1 is extracted. The RGB data is converted into YCbCr data by the RGB / YCbCr conversion circuit 306 corresponding to the RGB / YCbCr conversion circuit 29 in FIG. The YCbCr data is supplied to the presentation processor 139 together with the opacity data α1.

  The image data on the graphics plane 303 is supplied to the palette 305 corresponding to the palette table 26A in FIG. 17 described above, and RGB data and opaque data α2 are output. The RGB data is supplied to the RGB / YCbCr conversion circuit 307 corresponding to the RGB / YCbCr conversion circuit 26B in FIG. 17, and the color system converts from RGB (4: 4: 4) to YCbCr (4: 4: 4). Is done. The YCbCr data output from the RGB / YCbCr conversion circuit 307 is supplied to the presentation processor 139 together with the opaque data α2.

  The output of the moving image plane 135 is supplied to the presentation processor 139 via the up / down converter 138. The up / down converter 138 is a circuit that converts the resolution of an image, and converts, for example, a high definition HD (High Definition) image into an SD (Standard Definition) image having a normal resolution.

  The presentation processor 139 performs alpha blending processing using the opacity α1 based on the image data of the subtitle plane 11 (sub-picture plane 302) and the opacity α2 based on the graphics plane 12 (graphics plane 303) described with reference to FIG. I do.

  That is, in the presentation processor 139, the image data of the sub picture plane 302 is synthesized with the moving image plane 135 based on the opacity α1 set in the image data of the sub picture plane 302. Further, based on the opacity α2 set in the image data of the graphics plane 303, the image data of the graphics plane 303 is synthesized with the image data obtained by synthesizing the moving image plane 135 and the sub-picture plane 302. The image data obtained by combining the image data of the graphics plane 303, the image data of the sub-picture plane 302 (caption data), and the image data of the moving image plane 135 is derived to the output terminal 140.

  Note that the presentation processor 139 can also perform effect processing on image data in real time.

  In such a configuration, when a disc on which content described and data-structured according to an embodiment of the present invention is recorded is inserted into a drive device (not shown), a file “scenario.hdmv” or the like is read and the file The content recorded on the disc is played according to the description of “scenario.hdmv”. When an instruction is given by an operating means (not shown) by the user, the multimedia engine 106 controls each part of the drive device and the player decoder 100 'based on this instruction, and reproduction according to the instruction is performed.

  For example, when an angle switching instruction is made by an operation means not shown, the multimedia engine 106 based on this instruction refers to a necessary file such as the files “scenario.hdmv” and “entrylist.data” and can switch the clip. A drive device (not shown) is controlled based on the point information, and the reading position on the disk is changed and the angle is switched as described above. In addition, the operation unit can issue an instruction to cancel the pause setting when displaying a still image.

  In the above description, each part of the player decoder 100 ′ has been described as being configured by hardware, but this is not limited to this example. For example, the player decoder 100 'can be realized as a software process. In this case, the player decoder 100 'can be operated on the computer device. Further, the player decoder 100 'can be realized by a configuration in which hardware and software are mixed. For example, it can be considered that the audio decoder 118 and the MPEG video decoder 120 are configured by hardware, and the others are configured by software.

  The player decoder 100 ′ is configured only by software, or a mixture of hardware and software, and a program that is executed by a computer device is recorded on a recording medium such as a CD-ROM (Compact Disc-Read Only Memory) and provided. Is done. By loading this CD-ROM into the CD-ROM drive of the computer device and installing the program recorded on the CD-ROM in the computer device in a predetermined manner, the above-described processing can be executed on the computer device. Can do. Note that the configuration of the computer apparatus is very well known, and thus the description thereof is omitted.

  As described above, the present invention can realize an interactive function in which reproduction changes according to user input by extending the Blu-ray Disc standard for recording and reproduction on a recorded large-capacity disc. become able to.

  In addition, according to the embodiment of the present invention, since the playlist and the information of the playlist that constitutes the top menu are described in the database, the designated title can be directly reproduced with a remote control key or the like, regardless of selection on the screen Or the top menu screen can be called.

  In addition, according to the embodiment of the present invention, since a flag indicating whether or not the angle can be switched is provided for each head of the decoding unit, a seamless angle switching function in which discontinuity does not occur at the angle switching point is realized. be able to.

  Furthermore, according to the embodiment of the present invention, since the flag indicating whether or not the sub play item can be reproduced asynchronously with the main play item is provided, the BGM that is repeatedly reproduced asynchronously with respect to the main path is provided. Can be realized.

  Furthermore, according to an embodiment of the present invention, since still images and accompanying subtitles and graphics are encapsulated and recorded, the accessibility when performing a slide show or the like that is played while switching still images is performed. Will improve.

10 Movie plane 11 Subtitle plane 12 Graphics plane 22 Palette 30 BD virtual player 31 Player command 32 Common parameter 40 Playback control program 41 Method 60 Menu screen 70 Scenario 73A-73M Playlist 100 Player decoder 104 Code buffer 105 Content buffer 106 Multimedia Engine 109 Buffer 110 PID filter 116 Sub picture decoder 117 Still picture decoder 118 Audio decoder 120 MPEG video decoder 132 Sub picture plane 133 Graphics plane 134 Still picture plane 135 Moving picture plane 226 PNG decoder buffer 227 PNG decoder 228 Object buffer 229 Plain buffer 231 audio mixer 300 graphics decoder A
301 Graphics decoder B
302 Sub picture plane 303 Graphics plane 601A, 601B, 601C, 601D, 601E Extent

Claims (5)

A recording medium having a predetermined data structure on which content data to be played back by a playback device is recorded,
The data structure indicates a video stream encoded with one or a plurality of frames as a unit, and whether or not the reproduction unit provided for each reproduction unit of the video stream can be reproduced at a plurality of angles. The first flag, the number of angles included in the reproduction unit, the position information indicating the position on the video stream corresponding to each angle, and the angle provided for each encoding unit are set to the encoding unit. Including a second flag indicating whether switching is possible at the beginning,
When loaded into the playback device and the data structure is read into the playback device,
Video stream the first flag, indicating that those said reproduction unit can be reproduced with a plurality of angles, which change the reproduction position of the video stream on the basis of the position information, constituting a predetermined angle Can be read , and at the position based on the second flag, the playback position of the video stream interleaved and recorded for each angle is changed, and a video stream constituting another angle is read. The recording apparatus performs a process using the data structure so that the playback apparatus can perform the recording. The recording medium according to claim 1,
A recording medium in which the second flag is provided in a predetermined area on the end side of the angle. The recording medium according to claim 2,
When the switching of the playback position in the predetermined area has been designated, have such performed the switching instructed <br/> recording medium. The recording medium according to claim 2,
The predetermined when an area within the switching of the playback position has been instructed, the row intends <br/> recording medium reproduction of the angle back with the switching destination of the angle to the predetermined region immediately before. The recording medium according to claim 2,
The size of the predetermined area is a recording medium based on a maximum access time from the first area to the second area, and a difference between the video stream read speed and the video stream playback speed.

Images