WO2006059483A1 - 再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体 - Google Patents

再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体 Download PDF

Info

Publication number
WO2006059483A1
WO2006059483A1 PCT/JP2005/021075 JP2005021075W WO2006059483A1 WO 2006059483 A1 WO2006059483 A1 WO 2006059483A1 JP 2005021075 W JP2005021075 W JP 2005021075W WO 2006059483 A1 WO2006059483 A1 WO 2006059483A1
Authority
WO
WIPO (PCT)
Prior art keywords
playback
player
state
content data
stream
Prior art date
Application number
PCT/JP2005/021075
Other languages
English (en)
French (fr)
Inventor
Toshiya Hamada
Yasushi Fujinami
Tatsuya Kakumu
Shusuke Utsumi
Koji Ihara
Original Assignee
Sony Corporation
Sony Computer Entertainment Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation, Sony Computer Entertainment Inc. filed Critical Sony Corporation
Priority to PL05806735T priority Critical patent/PL1818932T3/pl
Priority to CN2005800476765A priority patent/CN101111895B/zh
Priority to MX2007006428A priority patent/MX2007006428A/es
Priority to KR1020077012539A priority patent/KR101235466B1/ko
Priority to DE602005024163T priority patent/DE602005024163D1/de
Priority to AT05806735T priority patent/ATE484828T1/de
Priority to US11/720,609 priority patent/US8369683B2/en
Priority to EP05806735A priority patent/EP1818932B1/en
Priority to AU2005310796A priority patent/AU2005310796B2/en
Publication of WO2006059483A1 publication Critical patent/WO2006059483A1/ja
Priority to HK07111620.8A priority patent/HK1106317A1/xx

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/34—Indicating arrangements 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2562—DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal

Definitions

  • the present invention relates to a playback device, a playback method and a playback program, a recording medium, and a data structure that can easily control playback of a program recorded on a large-capacity recording medium.
  • DVD Digital Versatile Disc
  • Disc-shaped recording media are being developed.
  • DVD video (DVD-Video) is defined as a standard for recording video content on a DVD.
  • DVD video a DVD player playing a disc can take various states.
  • the possible states of this DVD player are classified into five types of states called domains, and a model has been applied in which DVD players transition between domains according to various conditions.
  • the DVD domain can be thought of as a kind of state variable with five possible values. DVD players monitor this state variable to see what type of content is currently being read from the disc.
  • D VD video defines the following five types of domains.
  • Video manager menu domain (VMGM_D0M)
  • Video title set menu domain (VTSM_D0M)
  • the first play domain in (1) means the first section of the disc and indicates the readiness for playback on the DVD player.
  • Non-replay command is enabled.
  • the video manager menu domain (2) means the main menu of the entire disc or the disc surface, and shows the display of the title menu. Commands related to menus are enabled.
  • the video title set menu domain means a menu of a title or group of titles, or a submenu (subpicture, language, audio or angle). Either display is shown.
  • the title domain in (4) means the video content in the title, and the playback command is valid.
  • the stop state in (5) means that the head has left the disk playback and returned to its original position, and the playback command is valid.
  • the navigation commands that control the operation of the DVD player are limited by the domain applied to the current state.
  • a “select button” command that selects a predetermined item from a menu is meaningful only when the menu is displayed.
  • the “select button” command is a meaningful command in the state of either the video manager menu domain (2) or the video title set menu domain (3) described above.
  • the “fast forward” command to instruct video playback at a speed higher than the normal 1x speed makes sense when the player is stopped or a menu screen consisting of still images is displayed. Do not do. In other words, the “fast forward” command is a meaningful command in the title domain.
  • Non-Patent Document 1 “; i im Taylor, DVD dismantling new book, first edition, Nexus Intercom Co., Ltd., 2 0 0 3 June 7, p 2 7 1 " It is described in.
  • a conventional DV video has a problem in that it is difficult to implement in a DV player because there are many types of domains and the conditions for state transition between domains are fine.
  • a title domain and two types of menu domains are defined.
  • the main content for example, a movie main part
  • the main content for example, a movie main part
  • the main content should be played in the title domain, but in reality, there will be a problem even if the movie main part is played in the menu domain. Absent.
  • PGC program chain
  • an object of the present invention is to clearly define the state transition of the player operation and facilitate the production of interactive content, a reproduction method and a reproduction program, a recording medium, and a data structure. To provide a body.
  • the invention described in claim 1 is directed to a playback device that plays back content data recorded on a recording medium, and at least one of a video stream and an audio stream.
  • a reading means for reading out data from a recording medium on which content data including either of them and a playback control program for controlling playback of content are recorded, a player means for playing back content data in accordance with the playback control program, and a player Control command output means for giving a control command according to a user operation to the means, and the player means is classified into two states classified by whether or not the content data is being reproduced, and a control command from the control command output means
  • the playback apparatus is characterized in that the playback of content data is controlled on the basis of four states defined by combinations with two states classified according to whether or not the content is accepted.
  • the invention described in claim 12 is a playback method for playing back content data recorded on a recording medium.
  • the content data including at least one of a video stream and an audio stream is provided.
  • the control is based on the four states defined by the combination of the two states classified according to whether or not and the two states classified according to whether or not control commands corresponding to user operations are accepted. This is a playback method.
  • the invention described in claim 13 is a playback program for causing a computer device to execute a playback method for playing back a content night recorded on a recording medium.
  • the playback method includes at least a video stream and an audio stream.
  • a reproduction control program read from a recording medium on which content data including any one of these and a reproduction control program for controlling reproduction of the content data are recorded
  • the reproduction of the content data to be made by means of the player means is classified and 2 state classified by whether or not reproducing Conte Ndde Isseki, in whether or not to accept the control command corresponding to a user operation 2
  • This is a playback program characterized in that control is based on four states defined by combinations with states.
  • the invention described in claim 14 is a recording medium readable by a computer device on which a reproduction program for causing a computer device to execute a reproduction method for reproducing content data recorded on a recording medium is recorded.
  • the playback method is based on a playback control program read from a recording medium on which content data including at least one of a video stream and an audio stream and a playback control program for controlling playback of a content stream are recorded.
  • Content data playback performed by the player means is classified by two states classified by whether or not the player means playing content data and whether or not a control command corresponding to a user operation is accepted. Control based on 4 states defined by combination with 2 states A recording medium readable by a computer device.
  • the invention described in claim 15 is recorded with a content overnight including at least one of a video stream and an audio stream, and a playback control program for causing the player means to control playback of the content data.
  • the playback control program accepts two states classified according to whether or not the content is being played back and a control command corresponding to a user operation. It is defined that the playback of content is controlled by giving a playback control command to the player means that controls the playback of content data based on the 4 states defined by the combination of the 2 states classified by whether or not This is a recording medium readable by a computer device.
  • the invention described in claim 18 includes: a content data including at least one of a video stream and an audio stream; and a playback control program that causes the player means to control the playback of the content data.
  • the playback control program is classified into two states classified according to whether or not content data is being reproduced and two states classified according to whether or not a control command corresponding to a user operation is accepted.
  • the data structure is characterized in that a playback control command is given to a player means for controlling playback of content data based on four states defined by a combination with a state to control content playback.
  • the invention described in claim 19 is a playback device that plays back a content stream recorded on a recording medium, and includes a content stream that includes at least one of a video stream and an audio stream.
  • a reading unit that reads data from a recording medium on which is recorded a reproduction control program that controls reproduction of content data, a player unit that reproduces content data according to the reproduction control program, and a player unit that responds to user operations.
  • a control command output unit that provides a control command, and the player unit is classified into two states classified by whether or not the content is being played and whether or not the control command is received from the control command output unit.
  • Content data is re-based based on the four states defined by the combination with the two states classified.
  • a reproducing apparatus characterized that you have to control the.
  • the invention described in claims 1, 12, 13, 14, and 19 includes the content overnight including at least one of a video stream and an audio stream, and content data. Whether or not the content data of the player means is played back by the player means according to the playback control program read from the recording medium on which the playback control program for controlling playback is read.
  • the player means the state of the player means because the control is based on the four states defined by the combination of the two states classified by the two states and the two states classified by whether the control command corresponding to the user operation is accepted. This makes it easier to understand the operation during state transition, facilitates the implementation of the player means, and reduces the burden of content production.
  • the invention described in claim 15 is a content control including at least one of a video stream and an audio stream, and a playback control program for controlling the playback of content data by a player means.
  • a content control including at least one of a video stream and an audio stream, and a playback control program for controlling the playback of content data by a player means.
  • the invention described in claim 18 includes a content control including at least one of a video stream and an audio stream, and a playback control program for controlling the playback of the content overnight to a player means.
  • the playback control program is classified into two states classified according to whether or not the content data is being reproduced, and whether or not a control command corresponding to the user operation is accepted.
  • Content data based on 4 states defined by combinations with states Since the playback control command is given to the player means that controls the playback of content, the playback of content is controlled, so even content that requires complex control can be easily produced and provided as a data structure .
  • This invention defines two states, a stop state and a play state, from the viewpoint of play list playback as states of a movie player that plays a play list, and provides control commands corresponding to user operations without using a script program.
  • Two states, normal mode and menu mode, are defined depending on whether they are accepted, and playback of the playlist is controlled by state transitions between these four states. As a result, the AV stream playback can be controlled from the scribble program.
  • FIG. 1 is a schematic diagram showing the layer structure of the UMD video standard
  • FIG. 2 is a schematic diagram schematically showing an example player model according to an embodiment of the present invention
  • FIG. 3 is a movie.
  • FIG. 4 is a diagram for explaining a play state and a stop state of a movie player
  • FIG. 5 is a schematic diagram schematically showing an event model of a movie player according to an embodiment of the present invention.
  • Fig. 6 is a schematic diagram showing an example of an event that occurs during playback of a playlist.
  • Fig. 7A and Fig. 7B are diagrams showing a list of example properties of a movie player object.
  • Fig. 1 is a schematic diagram showing the layer structure of the UMD video standard
  • FIG. 2 is a schematic diagram schematically showing an example player model according to an embodiment of the present invention
  • FIG. 3 is a movie.
  • FIG. 4 is a diagram for explaining
  • FIG. 8 is a schematic diagram showing a list of examples of methods possessed by a movie player object.
  • Fig. 9 is a schematic diagram showing an example of key input by user input. The figure is a schematic diagram showing an example key input by user input.
  • Fig. 11 A, Fig. 11 B, and Fig. 11 C are schematic diagrams showing an example control command in response to a key input.
  • Figure 1 and Figure 2 show an example of events corresponding to key input.
  • Fig. 13 is a schematic diagram showing an example event handler
  • Fig. 14 is a schematic diagram showing an example event handler
  • Fig. 15 is a user input event.
  • Fig. 16 is a diagram for explaining an example of a script program
  • Fig. 17 is a schematic line showing an example of a script program.
  • Fig. 18, Fig. 18 is a schematic diagram showing the management structure of an example of a file applied to the UMD video standard, and Fig. 19 shows the syntax of an example showing the overall structure of the file "PLAYLIST.DAT"
  • Fig. 20 is a schematic diagram showing the internal structure of an example of a block PlayltemO.
  • Fig. 21 is a schematic diagram showing the internal structure of an example of a block PlayListMarkO.
  • Fig. 22 is a block MarkO.
  • Fig. 23 is a diagram for explaining the designation of the mark time in the clip AV stream file.
  • Fig. 24 is the overall structure of the clip AV stream file "XXXXX.CLP".
  • Figure 25 is a schematic diagram showing the syntax of an example.
  • Fig. 20 is a schematic diagram showing the internal structure of an example of a block PlayltemO.
  • Fig. 21 is a schematic diagram showing the internal structure of an example of a block PlayListMarkO.
  • FIG. 26 is a schematic diagram showing the internal structure of an example of a block StaticInfoO.
  • Fig. 27 is a schematic diagram showing the internal structure of an example of a block Dynamiclnf (i ().
  • FIG. 28 is a schematic diagram showing an example of the internal structure of the block EP_map ()
  • FIG. 29 is a block diagram schematically showing the configuration of an example of a disc playback apparatus to which the present invention can be applied
  • FIG. 30 and FIG. 30B are functional block diagrams for explaining the operation of the disc playback apparatus in more detail.
  • FIG. 31 shows the definition of the movie player state according to the present invention.
  • Fig. 3 Fig. 3 2 is a schematic diagram showing the current state and the state after state transition by the method for each of the 4 states of the movie player.
  • FIG. 34 is a schematic diagram for explaining an example of the state transition of a movie player when executing playO.
  • Fig. 34 is a schematic diagram for explaining how to play a play item.
  • Fig. 35 is a playlist.
  • Fig. 3-6 is a schematic diagram illustrating the operation of an example of a movie player when the start point and end point of a playlist are reached during playback of the playlist.
  • Fig. 3-6 is a schematic diagram for explaining playback between playlists.
  • Fig. 7 shows the flow of processing in the scribble layer at the end of the playlist and a flow chart showing an example of the operation of the movie player in more detail.
  • FIG. 39 is a schematic diagram for explaining the backup of the player status
  • Fig. 40 is for explaining the backup of the player status
  • Fig. 41 is a schematic diagram for explaining the restoration and destruction of resume information
  • Fig. 42 is a schematic diagram for explaining the restoration and destruction of resume information
  • Figure 43 illustrates the restoration and destruction of resume information
  • Fig. 44 is a schematic diagram for explaining the restoration and destruction of resume information
  • Fig. 45 shows the operation of an example of a UMD video player using the argument resumelnfoClearFlag of the method stopO.
  • Fig. 46 is a schematic diagram showing an example of the life cycle of the player status.
  • Fig. 47 A and Fig. 47 B are schematic diagrams showing an example of the life cycle of the resume information.
  • Fig. 48 The figure is a schematic diagram showing an example of a life cycle of a user's night.
  • E CMA Scribble a script language for cross platform based on Java Script (registered trademark), which was praised by ECMA (European Computer Manufacturers Association).
  • the ECMA script is suitable for use in the player model according to the present invention because it has a high affinity with HTML documents and can define unique objects.
  • conventional DVD video uses non-generic commands defined in the DV Video standard to describe a control program for realizing inductive functions.
  • the control program is embedded in a plurality of locations in a plurality of files and data files, as well as distributed in an AV stream file, and the conditions and order in which the embedded control program is executed are as follows: It was decided by the standard.
  • the script language based on this E CMA script is used.
  • the standard based on the embodiment of the present invention is called a UMD (Universal Media Disc: registered trademark) video standard.
  • UMD Universal Media Disc
  • the part related to script is called the UMD video scribble standard.
  • the UMD video standard is outlined below.
  • Figure 1 shows the layer structure of the UMD video standard.
  • the UMD video standard defines a three-layer structure of script layer, playlist layer, and clip layer, and stream management is performed based on this structure.
  • M P EG 2 digitally encoded video, audio, and subtitles are handled as an M P EG 2 stream that is multiplexed as a bucketed element stream of M P EG 2 (Moving Pictures Experts Group 2).
  • the MP E G 2 stream in which the video, audio, and subtitle elementary streams are multiplexed is called a clip AV stream.
  • the clip AV stream is stored in the clip AV stream file.
  • a clip information file (Clip Information File) is created simultaneously in a one-to-one correspondence with the clip AV stream file.
  • a set consisting of these clip information files and the corresponding clip AV stream file is called a clip.
  • a clip should be called a unit of recording on a disc.
  • the order in which clips are played during playback is managed by the playlist layer, which is the upper layer of the clip.
  • the playlist layer is a layer that specifies the playback path of the clip, and includes one or more playlists (PlayList).
  • a playlist consists of a set of play items (Pla yltem). Play items include the clip playback range. The set of In and Out points shown is included, and clips can be played in any order by connecting play items. Play items can be specified with duplicate clips.
  • the in and out points of a clip AV stream file are specified by a time stamp (time in the clip), and the time stamp is converted to a byte position on the clip AV stream according to the information in the clip information file. .
  • the playlist only has a structure in which play items indicating all or part of the clip are played according to the order, and only the playlist can be used to branch the playback order and to interact with the user. You can't do it.
  • a plurality of playlists are collected in one file “PLAYL I ST. DAT”.
  • the Scribe Layer is a layer built by UMD Video Scribe that extends ECMA Scribe of the language specification.
  • UMD video scripts are based on ECMA scripts and are enhanced with extensions to implement features specific to UMD video.
  • the scribble layer is an upper layer of the playlist layer, and is composed of a command sequence for instructing playback of a playlist and player settings.
  • a playlist with conditional branching such as selecting one of the streams prepared for multiple languages by a script layer command, or changing the playback flow to a playlist selected according to a certain condition. Reproduction can be realized.
  • Multistory is an example of an application that uses playlist playback with conditional branching. This script layer introduces interactive functions with the user.
  • the script layer is configured by a file called a resource file.
  • the image data used for the script data (script program) described based on the actual ECMA script, sound data for outputting sound effects during button operations, the background image of the menu screen, etc. It includes evening screen design and image data (bitmap data) for displaying GUI parts such as button images.
  • the resource file is given a file name according to a predetermined naming rule.
  • the file name extension “RC0” indicates that the file is a resource file.
  • a model of a playback device that plays back data according to the UMD video standard, that is, a player model will be described.
  • the player first reads the resource file, playlist file, and clip information file from the disc, and then reads the clip AV stream file according to the playback order defined by these files, video, audio, and subtitles. Play etc.
  • the function block that plays the playlist is implemented as an object in the script program.
  • the object that plays this playlist is called a movie player object in the UMD video standard.
  • the play list playback command and the player setting command are the methods of this player object.
  • Movie pre Job objects are controlled by methods from the script layer.
  • FIG. 2 schematically shows an exemplary player model according to the embodiment of the present invention described above.
  • the movie player 300 is a module that manages playback of video, audio, and subtitles in the UMD video standard.
  • the movie player object described above is an object in a script program in order to operate a movie object from a scribe program.
  • a movie player object is an abstracted module that implements the functions of a movie player and can be handled in a script program.
  • the movie player 3 0 0 has a lower layer (native implementation platform 3 0 1 in the example of FIG. 2) caused by user input 3 1 0 or the like, and a script layer 3 which is an upper layer.
  • the clip AV stream file is read, and the read clip AV stream is decoded and displayed.
  • the internals of the movie player object 300 depend on the implementation of the UMD video player that plays UMD video. From the script layer 30.2, the method I property such as the method property is used as a black boxed object. Application Programming Interface) is provided.
  • the UMD video player UMD Video Player refers to an actual device equipped with a movie player. All UMD video players are equipped with a movie player that complies with the restrictions of the UMD video standard and is compatible with playback.
  • the movie player object 300 has a path for receiving the control command 3 1 1 from the native implementation platform 30 1, a path for notifying the script layer 302 of the event 3 1 2, and the script layer 302 There are three input / output paths that accept methods 3 1 3 from.
  • the control command 3 11 is a command for controlling the operation of the movie player object 300 from the natively implemented platform 30 1.
  • the native implementation platform 301 is an interface between a part unique to a device and a movie player 300 in, for example, a UMD video player as an actual device.
  • Event 3 1 2 is a script event from the movie player 300 to the script layer 302.
  • Method 3 1 3 is a method instructed to the movie player 300 from the script program of the script layer 302.
  • the movie player object 300 has a UMD video standard playlist and clip information database 320 inside.
  • the movie player object 3 0 0 uses this data base 3 2 0 to invalidate (mask) the user input 3 1 0 and set the playback position specified by the time in the clip AV stream. Performs processing to convert to byte position.
  • the playback module 3 2 1 in the movie player object 3 0 0 performs the decoding of the clip AV stream, which is MPEG2PS (Program Stream) in which video, audio, and subtitles are multiplexed.
  • the playback module 3 2 1 has two states, play and stop, and transitions between these two states by control instructions and methods (see Fig. 3).
  • the clip A V stream is not limited to M P E G 2 P S. For example, even if MPEG 2 TS (Transport Time Stream) is used as the clip AV stream, it can be handled in the same manner on the model.
  • the script layer 302 is a layer that executes a script program based on the UMD video script standard, and controls the movie player object 300 and displays the screen. This script layer 302 plays the role of realizing the scenario intended by the content creator.
  • the script layer 3 0 2 issues a method 3 1 3 to the movie player object 3 0 0 and receives an event 3 1 2 from the movie player object 3 0 0.
  • the script layer 30 2 is connected to the native implementation platform 3 0 1 for the key implementation 3 1 4 corresponding to the user input 3 1 0 and the screen drawing etc. for the native implementation platform 3 0 1. Execute the method 3 1 5 etc.
  • the native implementation platform 301 has various functions other than those specified in the UMD video standard.
  • controller object 3 3 0 is defined in native implementation platform 30 1
  • method 3 15 is defined as a method of controller object 3 3 0.
  • buttons arranged on the menu screen are drawn by the native implementation platform 3 0 1 based on the method 3 1 5 passed from the script layer 3 0 2 script program to the native implementation platform 3 0 1 .
  • a key event 3 1 4 corresponding to the user input 3 1 0 is notified from the native implementation platform 3 0 1 to the script layer 3 0 2,
  • the script program in the script layer 30 2 performs processing corresponding to the key input 3 10 based on the key ⁇ vent 3 14.
  • GUI such as buttons
  • the native implementation platform 3 0 1 is a movie player
  • the platform on which JET 300 and the Scribbled Program operate for example, when the actual UMD video player is hardware, the processing between the hardware and the player model to serve as the mediating, 0 implemented in specific hardware
  • the native implementation platform 3 0 1 accepts user input 3 1 0 from the user, and whether the received user input 3 1 0 is an instruction to the movie player 3 0 0, and the script layer 3 0 2 Determine whether the command is for the displayed button.
  • the native implementation platform 3 0 1 controls the user input 3 1 0 as an internal control command for the movie player 3 0 0 if it is determined that the user input 3 1 0 is a command for the video player 3 0 0.
  • Command 3 1 1 is converted and a control command is issued to the movie player 3 0 0.
  • the native implementation platform 3 0 1 is a GUI component that the user input 3 1 0 draws and displays in the script layer 3 0 2 If it is determined that the command is directed to the script layer 3 0 2, the key event 3 14 corresponding to the user input 3 1 0 is notified to the script layer 3 0 2. Then, for example, a button image can be displayed on the screen based on the method 3 1 5 instructed by the script layer 3 0 2 according to the key ⁇ vent 3 1 4. In other words, events and methods can be directly passed between the native implementation platform 30 1 and the script layer 3 202 without going through the movie player 3 0 0.
  • FIG. 3 shows an example of the internal structure of the movie player 300.
  • the movie player 3 0 0 includes the database 3 2 0 and the playback module 3 2 1.
  • the database 320 is an area for storing playlist information read from the disc and clip information, that is, clip information.
  • the playback module 3 2 1 includes a decoder engine 3 2 2 and a property 3 2 3 which is a value representing the state of the playback module 3 2 1.
  • Property 3 2 3 is the property 3 2.3 A (read-only parameter) whose value is determined by the default setting of movie player 3 0 0, for example, language code, and playback module 3 2 1
  • properties 3 2 3 B player status
  • Property 3 2 3 A whose value is determined by default, is set by the native system, for example, the actual device, and the value is not changed by the playlist information or the script program.
  • Property 3 2 3 A can only read the value from the script program.
  • the property 3 2 3 B representing the state of the playback module 3 2 1 can read a value from the script program and write a value from a part of the scribe program.
  • the movie player object 300 plays the specified playlist according to the instruction from the script layer 30 or the native implementation platform 301.
  • the movie player 3 0 0 refers to the database 3 2 0 and obtains the playback position of the clip AV stream corresponding to the specified playlist at the byte position in the file.
  • the decoder engine 3 2 2 controls the decoding of the clip AV stream based on the playback position information.
  • the movie player 300 has two states of play (stop) and stop (stop) according to the play status of the playlist ⁇ ⁇ .
  • the play state refers to a state where a play list is specified and the play list is being played.
  • the play state includes various playback modes such as 2x, 1Z 2x, variable speed playback, forward fast forward and reverse fast forward, and pause (pause).
  • the so-called frame-by-frame playback in which playback is advanced or returned in frame units, is a state in which a pause state and a play state are repeated.
  • the stop state is a state where the playlist is not played. In the stop state, no playlist is selected, and the value of the player status indicating “currently playing playlist number” is undefined.
  • the state of the movie player 3 0 0 is associated with the state transition of play and step in the decoder engine 3 2 2 in the movie player 3 0 0, and the state according to the state transition of the decoder engine 3 2 2
  • the value of Patty 3 2 3 B is updated.
  • Resume information 3 2 4 stores the state immediately before the stop state. For example, a playlist with a movie player 3 0 0 If the state transitions to the stop state while decoding and playing, the state immediately before the stop state is stored.
  • a plurality of the resume information 3 2 4 can be stored in a non-volatile memory of the player as hardware so as to be identified for each disk title.
  • a disc has unique identification information (called title ID) for each title of the disc, and resume information 3 2 4 is stored in association with this identification information. In this way, based on the information in the resume information 3 2 4, when the disc with the title corresponding to the identification information transitions from the stop state to the play state next time, the disc is played back in the previous stop state. It is possible to start from the position immediately before.
  • the event model of the movie player 300 will be described.
  • the movie player 300 generates various events in the play state where the play list is played back. This event causes execution of a processing program written in a script called an event handler.
  • An event handler is a method that is called when an event occurs.
  • a program execution model that starts execution of a processing program when this event occurs is called an event-driven model. In the event-driven model, an irregular event occurs and a program prepared for the event occurrence is executed.
  • the script program controls the operation of the movie player object 300 by an event handler group.
  • FIG. 5 schematically shows an event model of the movie player 3 0 0 according to one embodiment of the present invention.
  • the event handlers onEven t AO, onEven t BO, and onEven t CO are interfaced.
  • the contents of each event handler are described in a script.
  • the content of the event handler is created and implemented, for example, by the content creator.
  • an event handler is prepared for each event notified from the movie player object 300 to the script program.
  • the event handler onEventAO is the processing program that is executed when event A occurs.
  • event B and event C when event B occurs, the corresponding event handler onEventBO is executed, and when event C occurs, the corresponding event handler onEventCO is executed.
  • the event handler that is called when an event occurs is selected on the system side, so there is no need for the content creator to describe the process to determine which event has occurred in the scribble program. .
  • Figure 6 shows an example of an event that occurs during playback of a playlist. Since the chapter mark ChapterMark is set at the beginning of the playlist PlayList, the event Chapter corresponding to the chapter mark is generated at the start of playback from the beginning of the playlist. Furthermore, every time the chapter changes, the event Chapter is notified to the script layer 302 and the corresponding event handler onChapter is executed. In addition, when playback reaches the time when the event mark EventMark is set, a corresponding mark event occurs. When playback reaches the end of the playlist, playback is paused at the end of the playlist, and the event PlayListEnd is notified from the movie player 300 to the script player 300.
  • event handler If the event handler is not described by the content creator, either the player's built-in behavior specified in the standard (default event handler) is executed, or the event is ignored and nothing is executed. When it is not necessary to perform any processing, it is possible to actively ignore events by not writing event handlers corresponding to event events.
  • an event model in addition to the above, if an object registers a listener corresponding to a certain event in the player object and the event that occurred in the player object is registered, the event is registered from the player object.
  • the event model according to this embodiment is simpler than the event listener model that requires processing such as event registration and event registration deletion.
  • the single method model knows which event has occurred and switches the processing routine prepared for each event. Preprocessing must be described in the method. The method is
  • a model that prepares a processing program (event handler) for each event is advantageous in this respect.
  • an object defined by a language that conforms to the E CMA scripting language specification has properties and methods.
  • the movie player object 300 according to this embodiment also has properties and methods in the same manner as described above with reference to FIGS. Properties can be directly read and written by specifying the target object name and property name from an external object. In addition to this, by defining a method setXXXO ("XXX" is the target property name) that sets property values and a method getXXXO that reads property values, you can read and write properties of other objects. It can be done by method.
  • FIG. 7A and FIG. 7B list examples of properties of the movie player object 3 0 0. This corresponds to property 3 2 3 in Fig. 3.
  • FIG. 7A shows an example of properties belonging to the ready parameter 3 2 3 A in FIG.
  • Properties scriptVersion is UMD Video Script Indicates the version.
  • the property audioChannelCapabi 1 i ty indicates the number of audio channels that the UMD video player can play.
  • Property ⁇ languageCode indicates the language code of the menu display language set in the UMD video player.
  • the property audioLanguageCode indicates the language code of the audio language set in the UMD video player.
  • Property subtitleLanguageCode indicates the language code of the subtitle language set in the UMD video player.
  • the script file to be read from the disc is determined based on the language code shown in the property languageCode set in this read-only parameter 3 2 3 A. If the loaded disc does not have a scribe file for that language, the default script file is read. For example, among the multiple script files, the file located at the top of the disk is read as the default script file.
  • FIG. 7B shows an example of properties belonging to the player status 3 2 3 B in FIG.
  • Property playListNumber indicates the number of the currently playing playlist.
  • Property chapterNumber indicates the number of the currently playing chapter.
  • Property videoNumber indicates the number of the video stream currently being played.
  • Property audioNumber indicates the number of the audio stream currently being played.
  • Property subtitle Number indicates the number of the currently playing subtitle stream.
  • Property pi ayListTime indicates the time when the play list head is 0.
  • the property audioFlag indicates the designation of audio playback NZ NZ FF and dual mono LR.
  • Property subtitleFlag indicates ON ZOF F of caption display.
  • Each property belonging to this player status 3 2 3 B has such information when the move player 3 300 is in a playback or pause state.
  • each property belonging to the player stage 3 2 3 B at that time is backed up as a resume information 3 24. At this time, the contents of the player status 3 2 3 B may be cleared.
  • FIG. 8 shows a list of examples of methods that the movie player object 300 has. This corresponds to method 3 1 3 in Fig. 2.
  • the method play 0 plays the video.
  • the method playChapter () plays a video by specifying a chapter.
  • Method resumeO starts playback using resume information 324.
  • the method stopO stops video playback.
  • the method pauseO pauses video playback.
  • the method playStepO plays the video frame by frame.
  • the method changeStreamO changes the video stream, audio stream and Z or subtitle stream.
  • the method getPlayerStatusO gets the status of playback, stop, pause, etc. in the movie player 300.
  • Method changeResumelnfoO changes the contents of resume information 3 24.
  • the method reset O stops video playback and clears the contents of resume information 3 24.
  • the UMD video standard allows video to be displayed on a portion of the display screen.
  • the following four methods are related to video display in this case.
  • the method setPosO sets the video display position.
  • the method getPosO gets the display position of the video To do.
  • the method setSizeO sets the video display size.
  • the method getSizeO gets the video display size.
  • the movie player 300 and the native implementation platform 301 are integrally configured.
  • the disk is actually loaded, and it is associated with the relationship between the UMD player as the hardware that plays back the disk and the software that controls the UMD player. Whether to do this by software depends on the configuration at the time of implementation.
  • the UMD player when configured with a personal computer or the like, it can be configured with software other than the disk drive.
  • a video decoder or an audio decoder can be configured in hardware. Therefore, the methods, commands, and events performed between the movie player 300 and the native implementation platform 301 are not limited to explicit exchanges as shown in FIG.
  • the native implementation platform 3 0 1 first receives the user input 3 1 0.
  • the native implementation platform 3 0 1 receives the key input from the user as the user input 3 1 0, and determines whether the user input 3 1 0 is a command for the movie player 300 or an event for the script program of the script layer 302. Then, according to the determination result, control command 3 1 1 or key event 3 14. is generated and notified to the corresponding upper layer (movie player 300 or script layer 302).
  • FIGS. 9 and 10 show an example of key input by user input 3 10. Each key beginning with “VK” shown in Fig. 9 and Fig. 10 One means a virtual key (virtual key).
  • FIG. 9 shows an example of key-in force relating to the operation of the movie player 300.
  • Key VK_PLAY provides a function corresponding to the playback key that instructs playback.
  • Key VK—STOP provides a function corresponding to the stop key that instructs playback to stop.
  • Key VK One PAUSE provides a function corresponding to the pause key to instruct playback pause.
  • Key VK_FAST_FORWARD provides a function corresponding to the fast-forward key to instruct fast-forward playback.
  • Key VK_FAST T_REVERSE provides a function corresponding to the fast-rewind key to instruct fast-rewind playback.
  • Key VK_SL0W — FORWARD provides a function corresponding to the slow (forward) key that indicates slow play in the forward direction.
  • Key VK_SLOW_REVERS E provides a function corresponding to the slow (reverse) key that instructs reverse slow play.
  • Key VK— STEP_FORWARD provides a function corresponding to the frame advance (forward) key that instructs frame advance playback in the forward direction.
  • Key VK— STEP_REVERSE provides a function corresponding to the frame advance (reverse) key that instructs reverse frame advance playback.
  • Key VK_NEXT provides a function corresponding to the next designation key that inputs a value that means “next”.
  • Key VK—PREVIOUS provides a function corresponding to the pre-specified key to input a value that means “previous”. For example, the key VK_NEXT and key VK-PREVIOUS can be used to indicate the movement to the previous or next chapter.
  • Key VK_ANGLE provides a function corresponding to the angle switch key that indicates the angle switch for multi-angle video.
  • Key VK— SUBT I TLE provides functions corresponding to subtitle switching keys for switching between English subtitles, Japanese subtitles, and subtitle display / non-display.
  • Key VK— AUD IO provides the ability to switch audio settings such as surround and bilingual audio settings.
  • the key VK_V IDE0_ASPECT is It provides a function corresponding to the aspect switch key that instructs video aspect ratio switching.
  • FIG. 10 shows an example of key input related to menu operation.
  • Key VK_UP provides a function corresponding to the up direction key that inputs a value that means “up”.
  • Key VK—DOWN provides a function corresponding to a downward designation key for inputting a value meaning “down”.
  • Key VK_RI GHT provides a function corresponding to the right direction key that inputs a value that means “right”.
  • Key VK_LEFT provides a function corresponding to the left direction key that inputs a value meaning “left”.
  • Key VK_UP—RI GHT provides a function corresponding to the upper right direction designation key for inputting a value meaning “upward diagonally right”.
  • Key VK— UP_LEFT provides a function corresponding to the upper left direction designation key to input a value meaning “upward left”.
  • Key VK_D0WN—RI GHT provides a function corresponding to the lower right direction designation key to input a value that means “down diagonally right”.
  • the key VK_D0WN_LEFT provides a function corresponding to the lower left direction specification key for inputting a value meaning “down diagonally left”.
  • Key VKJENU provides a function corresponding to the menu key to display the menu.
  • Key VK—ENTER provides a function corresponding to the OK key that indicates “OK”.
  • the key VK—RETURN provides a function corresponding to the return key, which indicates that one processing step is to be returned.
  • Key VK—C0L0RED_KEY_1 is the colored function key 1
  • key VK_C 0L0RED_KEY_2 is the colored function key 2
  • key VK_C0L0RED_KEY _3 is the colored function key 3
  • key VK_C0L0RED_KEY—4 is the colored function key 4.
  • Key VK—C0L0RED—KEY_5 provides functions corresponding to colored function key 5
  • key VK—C0L0RED_KEY_6 provides functions corresponding to colored function key 6. Since the key input shown in Fig. 9 and the key input shown in Fig. 10 have different roles, it is necessary to assign the notification destination to the native implementation platform 301. As described above, the key input shown in FIG.
  • FIG. 9 gives instructions regarding video, audio, and subtitle playback.
  • the native implementation platform 30 1 receives the key input shown in Fig. 9 as the user input 3 1 0, the received key input is converted into Fig. 1 A, Fig. 1 B and Fig. 1 C. Is converted to the command shown below and notified to the movie player 300.
  • the key input shown in FIG. 10 is a user input 3 1 0 to the GUI
  • this user input needs to be notified to the script layer 3 0 2 where the screen configuration and buttons are arranged and processed. is there.
  • the native implementation platform 3 0 1 receives the key input shown in Fig. 1 0 as user input 3 1 0, it converts it to event 3 1 4 in Fig. 2 and notifies it to the script layer 3 0 2 To do.
  • Figure 12 shows an example event 3 1 4 corresponding to this key input.
  • the user input 3 1 0 is transmitted to the movie player 3 0 0, and the movie player 3 0 0 notifies the event indicating that a stream switching request has been issued to the script. Then, audio and subtitles are switched by the stream switching method from the scribble program to the movie player 300. Therefore, it is a key input that should be transmitted from the native implementation platform 3 0 1 to the movie player 3 100.
  • the commands in FIG. 11A, FIG. 11B, and FIG. 11C will be described in more detail.
  • Command uo_UmeSearch (pl ayL ist Time) Instructs playback from the specified time of the playlist being played.
  • the argument "plaListListTime" represents the time when the top of the playlist is 0. Since this command cannot specify a playlist number, the time indicated by the argument play ListTime is the specified time within the range of the playlist currently being played.
  • the command uo_play () instructs to start playback at 1x speed. The starting position will be determined based on Resume Information 3 24. If there is no information corresponding to Resume Information 3 24, this user operation is invalid. This command corresponds to the execution of the method playO with no playlist number specified. Also, with this command, the playlist number cannot be specified by user operation.
  • the command uo_playChapter (chapterNumber) indicates the start of playback from the chapter specified by the argument chapterNumber of the playlist being played. If there is no designation of a cap evening, it instructs to start playback from the beginning of the currently playing cap evening. This corresponds to the method playChapterO with no chapter number specified.
  • the command uo_playPrevChapter 0 instructs to start playback from the previous chapter.
  • the command uo_playNextChapter 0 instructs the start of playback from the current next chapter.
  • the command uo_jumpToEnd indicates a jump to the end of the playlist. This command corresponds to a user operation that instructs the movie player 300 to stop the current playback and generate the event playListEnd. In response to this command, the event handler onPlayListEnd is executed in the script layer 300.
  • the command uo_forwardScan (speed) instructs forward playback at the playback speed specified by the argument speed.
  • the command uo .backwardScan (speed) Instructs reverse playback at the playback speed specified in.
  • the command uo_playStep (forward) indicates forward frame playback.
  • the command uo1 playStep (backward) indicates reverse frame-by-frame playback.
  • the command uo one pauseOnO instructs to pause playback based on user operation.
  • the command uo—pauseOff 0 cancels playback pause based on user operation.
  • the command uo_setAudioEnabled (boolean) specifies the audio stream ONZO F F. When this command is executed, the value of the flag audioF lag is also changed to the corresponding content.
  • the command uo—setSubtitleEnabled (boolean) specifies O N O F F for the subtitle stream. When this command is executed, the value of the flag subtitleFlag is also changed to the corresponding content.
  • the command uo_angleChange () instructs to change the display angle. When a user operation based on this command is transmitted to the movie player 300, the movie player 300 sends an event angleChange to the script layer 300.
  • Command Huo_audioChange udioStrea mNumber instructs to change the audio stream to be played.
  • the command uo_changeAudioChannel (value) instructs audio channel switching or single channel switching during dual mono playback.
  • the value of the flag audioFlag is also changed to the corresponding content.
  • the command uo_subtitleChange (subtitleStreamNumber) instructs to change the subtitle stream to be played.
  • the event menu jumps to the menu.
  • This event is a movie pre- It is notified from the native implementation platform 3 0 1 to the script layer 3 0 2, not to the 3 0 0.
  • the script layer 3 0 2 executes the event handler onMenu.
  • the event exit is an event emitted from the native implementation platform 3 0 1 when the native implementation platform 3 0 1 terminates the UMD video application.
  • the script layer 3 02 executes the event handler onExit.
  • the event resourceChanged is an event emitted from the native implementation platform 3 0 1 when a resource file switch occurs.
  • this event resouceChanged is received by the script layer 3 0 2
  • the script layer 3 0 2 will receive the event hand ⁇ nResourceChanged ⁇ iT ⁇
  • Event up, event down, event left, event right, event ⁇ focusIn, event ⁇ focusOut, event ⁇ push and event cance 1 have force on the button image that is the GU I component displayed on the screen. This is an event that occurs when the player is hit. This event is notified not to the movie player 3 00 but from the native implementation platform 3 0 1 to the script layer 3 0 2. Note that when the button image is focused, for example, the cursor for indicating the position on the screen indicates the display coordinates of the button image, and the button image can be selected. . Event up, event down, event left, and event right occur when the focus on the button image moves to the up, down, left, and right button images, respectively.
  • Event focusln is focused on a certain image
  • the event focusOut occurs when the focus is lost from the focused image.
  • event push occurs when a push operation is performed on the button image that is in focus.
  • the event cancel occurs when a cancel operation is performed for a button image press operation.
  • Event autoPlay and event cont inuePlay are events instructing the start of script execution in script layer 300.
  • the event autoPlay is an event that instructs to start script execution automatically when a disc is loaded.
  • the event continuePlay is executed when a disc is loaded. For example, based on the resume information 3 24, the resumption of scribing is instructed from the point when it was previously stopped.
  • the program corresponding to this event is called an event handler.
  • Events and event handlers can be associated with each other by name, for example.
  • the event name with “on” added to the beginning of the event name is the event name.
  • Figures 13 and 14 show an example event octla.
  • FIG. 13 shows a part of an example of an event held by the movie player object 300 and a corresponding event handler.
  • the event shown in FIG. 13 corresponds to the event 3 12 shown in FIG. 2 described above, and is notified from the movie player 3 00 to the script layer 3 202.
  • An event handler is a kind of interface whose contents are, for example, Implemented by content creators using the Scribble language. By configuring the event handler in this way, the action intended by the content creator can be realized when the event occurs.
  • Event mark and event handler onMarkO are executed when an event mark is detected.
  • the event mark is embedded in a playlist, and is detected by the movie player 300 during playback of the playlist.
  • the event mark is notified from the movie player 3 0 0 to the scribing layer 3 0 2.
  • Script layer 3 0 2 executes event handler onMarkO corresponding to this event mark.
  • the event palyListEnd and the event handler 011? 1 & 1 ⁇ 51 £ 11 (1 () are executed when the playlist ⁇ ends.
  • the event chapter and event handler onChapter 0 are the chapter marks (Chapter- The mark is executed when a mark is detected, for example, embedded in the playlist, and detected by the movie player 300 during playback of the playlist.
  • Event angleChange and event octal onAngleChange 0 are executed when an angle change is instructed by a user operation. For example, if the key input VK_ANGLE is input to the native implementation platform 3 0 1 as user input 3 1 0 in response to a user operation, the native implementation platform 3 0 1 sends the user input 3 1 0 to the command uo _angleChange. Convert to 0 and pass to movie player 3 0 0. The movie player 3 0 0 generates the event angleChange in response to this command uo_angleChange () and passes it to the script layer 3 0 2. The script layer 3 0 2 executes the event handler onAngleChangeO corresponding to this event angleChange.
  • Event audioChan ge and event handler onAudioChangeO are executed when an audio change is instructed by a user operation.
  • Event subtitleChange and event handler onSubt it leChange 0 are executed when a subtitle change is instructed by a user operation.
  • Figure 14 shows a part of an example event handler that controller object 330 has.
  • the event handler shown in Fig. 14 is an event handler that belongs to the controller object 3 30 of the native implementation platform 3 0 1 and notifies the script layer 3 0 2 from the native implementation platform 3 0 1. It is executed by doing.
  • Event menu and event handler onMenuO jump to the menu.
  • the event menu is an event notified from the native implementation platform 3 0 1 to the scribe layer 3 0 2 when a menu key is pressed by a user operation, for example.
  • the script layer 3 02 executes the corresponding event handler onMenu (), and arranges and displays the GUI components that make up the menu screen in the event handler onMenuO.
  • the event ex it and the event handler onExitO are events and corresponding event handlers emitted from the native implementation platform 3 0 1 when the native implementation platform 3 0 1 terminates the UMD video application.
  • the event exit is notified from the native implementation platform 30 1 to the script layer 300 2 when the end of the operation of the UMD video player is instructed by a user operation or the like, for example.
  • the script of the script layer 300 2 can perform the termination process in the event handler onExitO in response to the notified event exit.
  • Event resourceChanged and event handler onResourceChanged are events and corresponding event handlers issued from the native implementation platform 301 after the native implementation platform 301 switches the resource file.
  • Fig. 15 shows that when a user presses a key (for example, the “next” key) to instruct playback of the next chapter during normal playback of a disc in the UMD video player. Corresponding to the input, this is an example of jumping to the next chapter and starting playback and displaying the prepared message on the screen.
  • a key for example, the “next” key
  • the native implementation platform 3 0 As user input 3 1 0, the key VK—NEXT is passed. In the native implementation platform 3 0 1, the user command uo—playNextChapterO is generated in response to the user input 3 1 0 (step S 1 1). This user command uo_playNextChapter 0 is notified to the movie player 300.
  • This command uo—movie player that received playNextChapterO 3 0 0 searches the data base 3 2 0 and obtains the position of the next check mark from the playlist information on the basis of the currently reproduced position (step S 12).
  • step S 1 3 it is determined whether or not the next chapter mark exists. If it is determined that the next chapter mark does not exist, the current playback is continued without performing the chapter jump.
  • step S 1 3 if it is determined in step S 1 3 that the next check mark exists, the process proceeds to step S 14.
  • step S 1 4 the movie player 3 0 0 stops the current playback and the byte position in the clip AV stream file indicated by the next chapter mark Acquired from the special information of the information file. Then, in step S 15, the obtained in-file buy position is accessed, and reading of the stream is started from that position and playback is started.
  • Step S 16 and subsequent steps are a series of procedures for displaying a message on the screen informing that the cap has changed.
  • a changeover event occurs (step S 16). For example, a chapter mark provided at the beginning of a chapter is not detected by the movie player 300 and an event “chapter” is generated. This capture event is notified from the movie player 300 to the script layer 300. At the time of notification of this event, the movie player 300 notifies the script layer 3002 of the chapter number of the jump to jump.
  • the scribing layer 30 0 starts execution of an event handler corresponding to the notified event, for example, event handler onChapterO (step S 17).
  • the script of the script layer 302 executes this event handler, acquires the jump destination chapter number notified from the movie player 300 when the event occurs (step S 1 8), and executes the native implementation platform 3
  • step S 19 an instruction to display a predetermined message on the screen is displayed, such as the beginning of the cap of the acquired cap number.
  • the native implementation platform 30 1 displays a message on the screen (step S 19), and the processing by the event handler is terminated (step S 20).
  • the user jumps to a jump by operating the key “ne X t” that instructs the start of playback of the next chapter, and starts playback of the next chapter of the jump destination. Sometimes a message will be displayed on the screen indicating the beginning of the chapter.
  • the user input event changes the state of the movie player 300 and also triggers the generation of a new event, and various processes can be performed using newly generated events.
  • the player model as described above enables video, audio and caption playback. An event handler that is set in advance by the content creator at a certain time during playback is generated, and the event handler prepared in advance is executed. realizable.
  • the native player platform 3 0 1 controls the movie player 3 0 0 according to the user input 3 1 0 by the user operation. A command can be given to change the player state as the user intends.
  • the player The native implementation platform 3 0 1 that receives user input 3 1 0 by a single operation notifies the script layer 3 0 2 of the event to execute the action prepared by the content creator according to the user operation. It is also possible.
  • the content playback flow as shown in Fig. 16 is created by the content creator.
  • the content shown in FIG. 16 is composed of playlists 400 and 401, a top menu 4202, and a message 4103 as displayed elements.
  • the playlist 400 is for displaying a warning text screen that is automatically displayed when a disc is loaded.
  • the playlist 400 1 is, for example, the main part of the movie that is the main focus of this content.
  • GUI parts such as buttons are arranged so that playback of the playlist 4 0 1 can be instructed.
  • the message 4003 is displayed at an arbitrary time during the reproduction of the playlist 4001.
  • the event handler onAudioPay O automatically plays the playlist 400 and displays a warning text.
  • the event handler onP yL is tEnd O is an event handler that is called when play list playback ends. In the example shown in Fig. 16, it is called when playlist 400 or playlist 4 0 1 ends. Be taken out. That is, the event handler onPlayListEndO determines which playlist has ended, and when the playback of the playlist 400 is completed, instructs the start of playback of the playlist 401. Also, when playback of the playlist 40 1 is completed, the top menu screen 402 is called.
  • the event handler onMenuO is called when the user operates the menu key, and calls the top menu 402 and displays it on the screen.
  • the event handler onMarkO is executed when the time indicated by the mark Mark is reached during playback. In the example of Fig. 16, mark Mark is set for playlist 40 1, and when playback of playlist 40 1 reaches the time indicated by mark Mark, message 40 3 is displayed on the screen. It is like that.
  • the event handler onAutoPlay is called to play the playlist 400, and a warning screen is displayed.
  • event handler onPlayListEnd is called, and it is determined that playlist ⁇ 40 0 has been played to the end.
  • Playlist 40 1 is played.
  • the event handler onMenu is called and the top menu screen 402 is displayed.
  • the event handler onMenu starts playback from the top of the play list 401 according to a predetermined operation on the top menu screen 402.
  • FIG. 17 is a diagram for realizing the operation shown in FIG. An example script program is shown. As described above, event handlers are arranged in the script program, and corresponding event handlers are executed when events occur.
  • the script program is “movieplayer.play ()” that instructs the movie player 300 to play the playlist ⁇ stored in the resource file with the extension “RC0”.
  • Files are recorded hierarchically in the directory structure and recorded on the disc.
  • a disk file system a file system defined by ISO (International Organization for Standardization) -9660 or UDF (Universal Disk Format) can be applied.
  • the file “TITLE ID. DAT” is a file that stores a different title identifier for each title (content type). It has one file “TITLE ID. DAT” for one disk.
  • a resource file (“JA000000.RCO”) is placed under the directory "RESOURCE".
  • the resource file stores the scribing program that configures the scribing layer 300 2 and also uses the components used to configure the menu screen, such as image data and sound data. Data is stored.
  • Under the directory "R ES0URCE” there is usually one resource file. Not limited to this, multiple resource files can be placed under the directory "RESOURCE”. Multiple resource files are created for each language, for example, when preparing multiple menus with different display languages. Even in this case, only one resource file is used at the same time.
  • the extension after the delimiter period is fixed to “RC0” in the file name, and the file is a resource file. The file is indicated.
  • the contents of the resource file are schematically shown by the character string before the period.
  • the entire resource file name is in the format “CCdannnn. RC0” ⁇ the first two characters “(: (:” are the language code corresponding to the resource file, and the next one character “d” is the language code. Is a flag indicating whether or not is the default language, the next “a” is the aspect ratio of the display screen, the next four characters “nnnn” is the identification number,
  • file names are determined so that they do not overlap each other.
  • the resource file language attribute and the aspect ratio of the display screen can be known from the resource file file name.
  • select a resource file determine the appropriate resource file based on the file name.
  • the file name is a string consisting of 5 or several characters such as “00001” before the delimiter period (in this example, a number), and the extension after the period is “CLPJ”.
  • the extension “CLP” identifies the file as a clip information file.
  • One or more clip AV stream files are placed under the directory “STREAM”.
  • the clip AV stream file has a file name, a string consisting of 5 or several characters such as “00001” before the delimiter period (in this example, a number), and the extension after the period is “PS”.
  • the extension “PS” can identify that the file is a clip AV stream file.
  • a clip AV stream file includes a video stream, an audio stream, and a subtitle (subtitle) stream multiplexed, and an MPEG 2 (Movie Picture Exper ts Group 2) program stream.
  • a clip AV stream file is obtained by compressing and time-division-multiplexing video data and audio data as described above.
  • Video data and audio data can be obtained by reading this file and decoding it.
  • the ⁇ lipformation file is a file that describes the properties of this clip AV stream file and corresponds to the clip AV stream file.
  • the resource file includes a script file in which a script program is described, and stores a program used to make the playback mode of the disc to which this embodiment is applied interactive. Has been. Resource files are read prior to other files stored on disk.
  • the file “PLAYLIST.DAT” is a playlist file in which playlists that specify the playback order of clip AV streams are described.
  • the internal structure of the file “PLAYLIST.DAT” will be described with reference to FIGS. 19 to 21.
  • Figure 19 shows an example of the syntax that represents the overall structure of the file "PLAYLIST.DAT”.
  • the syntax is shown based on the C language description method used as a program description language for computer devices. This is the same in diagrams representing other syntaxes.
  • a field name_length has an 8-bit data length and indicates the length of the name assigned to this playlist file.
  • the field name—string has a data length of 2 5 5 bytes and indicates the name given to this playlist file.
  • the field name_string is valid from the beginning to the byte length represented by the field name_length. Used. For example, if the field name—length has the value “1 0”, the first 10 bytes from the beginning of the field name—sing is interpreted as a valid name.
  • 'Field number_o PlayLists has a 16-bit data length and indicates the number of blocks PlayListO described subsequently. The number of blocks PlayListO is described as many times as indicated in the PlayLists field with the for loop in the next line. Block PlayList 0 is the playlist itself.
  • field PlayList 0 An example of the internal structure of the block PlayList 0 will be described.
  • field PlayList one data_length is arranged.
  • the field PlayList and datajength has a data length of 32 bits, and indicate the data length of the block PlayList0 including the field PlayList-datajength.
  • a field reserved-for-word-alignment having a data length of 15 bits and a flag capture_enab-le_flag-PlayList having 1 table length 3 ⁇ 4 are arranged.
  • the word_al ignment is “Frequency with an overnight length of 1 hit capture— enabl 6— Combined with & 8_? 1 & 31 to place in block PlayLis t 0 1 Used to align 6 bits.
  • the flag capture-enable-flag-PlayList is a flag indicating whether or not secondary use of a moving image belonging to the block PlayList 0 including the capture-enable-flag-PlayList is permitted. For example, if the value of this flag capture_enable_flag_PlayList is “1”, it indicates that secondary use of the video images belonging to the PlayList 0 is permitted within the player.
  • the flag capture-enable_flag_PlayList is a 1-bit flag, but this is not limited to this example.
  • the flag “capture_enable_flag—PlayList is made up of multiple bits, and is used for secondary use. You may make it describe a floor-level permission.
  • the flag capture_enable_flag_PlayList has a 2-bit configuration. When the value is “0”, the next use is completely prohibited, and when the value is “1”, for example, a predetermined resolution such as 64 pixels ⁇ 64 lines. Secondary use is possible only when compression coding is performed below. If the value is "2", it is possible to use such as allowing secondary use without any restrictions.
  • bit 0 is the value “1”
  • bit 1 is the value “1”
  • it is in the same housing.
  • Permit secondary use in other applications eg wallpaper images and screen savers.
  • the value of bit 0 and bit 1 can be used in combination.
  • Field PlayLiss name_length has an 8-bit data length and indicates the length of the name assigned to this block PlayList 0.
  • the field P1 ayL is name_string has a data length of 2 5 5 bits, and indicates the name assigned to this block PlayList 0.
  • the field PlayList name_string is used as a valid name from the beginning to the byte length represented by the field PlayList name_string.
  • the field number_o Playltems has a data length of 16 bits.
  • Each block PlayltemO in the block PlayListO has identification information (I
  • D) is granted.
  • the first block PlayltemO described in the block PlayListO is numbered 0, and thereafter, serial numbers such as Nos. 1, 2,... Are added in the order of appearance of the block PlayltemO.
  • This serial number Is used as identification information of each block PlayltemO.
  • the for loop argument i which is repeated by the number of blocks P y ItemO, can be used as identification information for the corresponding program, PlayltemO.
  • Block P 1 ayL ist Mark 0 is placed next to the block Playl't em ().
  • a field length is arranged at the head of the block PlayltemO.
  • the field length has a 16-bit data length and indicates the length of the block PlayltemO.
  • the field CI ip_Information— ⁇ le—name_length is distributed.
  • the field CI ip—In format ion—file_name—length has a data length of 16 bits and indicates the length of the name of the clip information file corresponding to this block Play system 0.
  • Field Clip-Information-file-name has a variable data length in bytes, and indicates the name of the clip information file corresponding to this block PlayltemO.
  • the field Clipjnformation —file—name is used as a valid name from the beginning to the byte length represented by the field CI ip_Information— ⁇ le_name.
  • the clip AV stream file corresponding to the clip information file can be specified by the above-described file name correspondence.
  • the field IN_time and field 0UT_time each have a data length of 33 bits, and the playback start position of the clip AV stream file corresponding to the clip information file specified by the field C1 ip_Information_name_name in the block PlayltemO and This is time information for designating the playback end position.
  • clip AV You can specify the start of playback from a part other than the beginning of the stream file. Similarly, it is possible to specify playback end other than the rear end of the clip AV stream file.
  • the field reserved_for—word—al g nment is an adjustment field for making the data length of the data structure an integral multiple of 16 bits, and has a data length of 15 bits.
  • the internal structure of an example of the block PlayListMarkO is explained using Fig. 21.
  • the field th is arranged at the head of the block PlayListMarkO.
  • the field length has a data length of 32 bits and indicates the length of the block PlayListMarkO.
  • the field numb er— of— P yListjnarks is placed.
  • Field field number—O PlayList_marks has a 16-bit data length, and indicates the number of subsequent block Mark 0.
  • the number of blocks Mark 0 are described as many times as indicated in the field number_o by the for loop on the next line and indicated in PyL i s t.marks.
  • Block Mark 0 is preceded by field mark-type.
  • the field mark-type has a data length of 8 bits and indicates the type of the block MarkO including the field markjype.
  • two kinds of marks a cape mark and an event mark, are defined.
  • the chapter is a cueing unit for dividing the play list (block Play List 0), and the chapter mark indicates the chapter position by time information.
  • An event mark is a mark that generates a mark event.
  • Field mark_name_length has a data length of 8 bits and represents the length of the name assigned to this block MarkO.
  • the field mark name string placed on the bottom line of block Mark 0 is in this block MarkO. Indicates the attached name.
  • the field mark_name_string is used as a valid name from the beginning to the byte length represented by the field mark—namejength.
  • the element associates the block Mark 0 defined on the block PlayList 0 with the clip AV stream file. That is, the field “reset_PlayItem_id” has a data length of 16 bits and indicates identification information of the block “PlayltemO”. As a result, the clip information file and the clip AV stream file are specified.
  • the field mark—time_sta has a 33-bit data length and is used to specify the mark time in the clip AV stream file.
  • the outline will be described with reference to FIG.
  • the playlist consists of three play items (Playltem (# 0), PI ayl tem (#l) and Playl tem (# 2)) with numbers 0, 1 and 2 respectively. Becomes time t on the playlist. Is the play item number 1
  • each of the play items numbered 0, 1 and 2 is a clip stream file clip stream via the corresponding clip information file ( Program Stream) A, B, and C are supported.
  • time t on the playlist If you specify a mark for the field, re_to_PlayItem—id value, time t. “1” indicating a play item including “,” and the time t on the corresponding clip AV stream file B. The time corresponding to the field mark_ti write me sta immediately.
  • the field en try_ES—stream—id and the field en try ES—pri vate—streamjd are the stream ID (stream_id) of the packet (packetO) in which the corresponding element list stream is multiplexed, and the private list Frybe of ket hetta (pr i vat e— packet— header 0)
  • buckets packet 0
  • stream ID stream-id
  • private tono The private stream ID (private_stream_id) of the header header () is based on, for example, the program stream specification of the MP EG 2 system.
  • field entry_ES-stream_id and field entry-ES_private-stream_id are used, for example, when the clip AV stream # 0 and the clip AV stream # 1 have different chapter configurations. If the corresponding block MarkO is not associated with a particular elementary stream, the values of these two fields are each set to "0".
  • FIG. As described above, the clip information file “XXXXX.CLP” is the corresponding clip AV stream file “XXXXX.PS” placed under the directory “STREAM”. Describe the nature of the.
  • FIG. 24 shows an example of syntax indicating the entire 4: structure of the clip AV stream file “XXXX.CLP”.
  • the clip AV stream file “XXXXX. CLP” is preceded by field presentation_start—time and field presentation_end_time.
  • Field Hpresentat ion_s tar t_t ——— red present at ion—end— ti me has a data length of 33 to 3 bits, respectively, and indicates the time of the beginning and end of the corresponding clip AV stream file.
  • PTS Presentation Time Stamp
  • PTS has an accuracy of 90 kHz.
  • the word—al ignment is used to align the placement in the file “XXXXX.CLP” to the 16-bit position in combination with the flag capture_enable—flag_Clip with a data length of 1 bit.
  • This flag indicates whether secondary use of the video contained in the clip AV stream file corresponding to the file “XXXXX.CLP” is permitted, for example, the value of this flag capture-enable-flag_Cl ip is “1” indicates that secondary use of the video of the clip AV stream file corresponding to the file “XXXXX.CLP” is permitted within the playback device.
  • the field number—0 and streams has a data length of 8 bits and indicates the number of subsequent StreamlnfoO structures.
  • the block StreamlnfoO is described for the number of times indicated by the feed number “of_s treams” by the next force of field number_o and st reams.
  • block EP—map () is placed.
  • the internal structure of an example of the block StreamlnfoO will be described.
  • the field length is placed at the beginning of the block StreamlnfoO.
  • the field length has a 16-bit data length, and indicates the length of the block Streaming) 0.
  • a field stream id having a data length of 8 bits and a field private_stream_id are arranged, and the block StreamlnfoO is associated with the elementary stream as shown in FIG.
  • the block StreamlnfoO is associated with the video stream with the field s tream_id between the value "0xE0" to the value "0xEF", and with the value "0XBD” It is associated with (Adaptive Transform Acoustic Coding) audio stream, LPCM (Linear Pulse Code Modulation) audio stream or subtitle stream.
  • the block StreamlnfoO has a field private—stream—id of value “0 x 0 0” to value “0 0 F”, value “0 x 1 0” to value “0 x 1 F”, and value “0 x 8” 0 "to the value” 0x9 F "are associated with the ATRAC audio stream, LP CM audio stream, and subtitle stream, respectively.
  • the block StreamlnfoO is roughly divided into two types of information: information that does not change in the stream and information that changes in the stream.
  • Information that does not change in the stream is described in the block StaticInfoO.
  • information that changes in the stream is described in the block DynamicInfoO with the change point specified by time information.
  • the field number—of—Dynamic Info has an 8-bit data length, and indicates the number of blocks DynamicInfoO described later in the block StreamlnfoO.
  • field number—0 and field pt s_change_point and block Dynamic Info 0 are described as many times as indicated by Dynamiclnfo.
  • the field pts_change_point has a 33-bit data length and indicates the time when the corresponding block DynamicInfoO information becomes valid by PTS.
  • the start time for each stream is also indicated by the field pts_change_point, which is defined in the file “XXXXX.CLP” and is equal to the field present at ion-time described above.
  • the internal structure of an example of the block StaticInfoO will be described using Fig. 26.
  • the content of the block StaticInfoO is S depending on the type of the corresponding elementary stream.
  • the type of the corresponding elementary stream can be determined based on the values of the field stream_id and the field private_stream_id described using Figure 25.
  • the type of elementary stream supported by the block StaticInfoO is described using an if syntax, which is a video stream, an audio stream, or a subtitle (caption) stream.
  • the block StaticInfoO is described below for each elementary stream.
  • the block StaticInfoO consists of a field cc_flag which has a field picture_size and a field frame_rate each having a 4-bit data length and a 1-bit data length. Become.
  • the field picture_size and the field frame—rate are the size and frame size of the video stream. Each frequency is shown.
  • the flag cc_ag indicates whether or not the video stream contains closed captions. For example, the flag —flag has a value of “1” and the video stream contains a closed caption.
  • the book StaticInfoO has a field au dio_langu age—code with a data length of 16 bits and a field with an s of 8 bits. It consists of a field channel_conf iguration, a 1-bit length field 1 fe_existence, and a 4-bit data length field sampling_requency.
  • a field audio_language_code indicates a code representing a language included in the audio stream.
  • the field “channel” and “configuration” indicate the channel attribute of the audio data such as mono, stereo, and multi-channel.
  • the field lfe—existence indicates whether or not a low-frequency emphasis channel is included, eg, the value is "1", indicating that it is included.
  • a field “sampling_frequency” indicates a sampling frequency.
  • the field reserved_for_word_alignment is used to align the data alignment to 16 bits.
  • the block StaticInfoO contains a field with a data length of 16 bits, subt ⁇ le—language_code, and a flag with a bit length of 1 bit ⁇ conf igurable_f lag I will.
  • the field subtitle_language_code indicates a code representing the language included in the subtitle stream.
  • the flag configurable_flag indicates whether or not to allow change of the character size and position when displaying the subtitle stream. For example, the value is " 1 "indicates that permission is allowed.
  • the field reserved—for—word—alignent is used to align the data arrangement to 16 bits.
  • a field reserved_for_word_alignment having an 8-bit data length is arranged at the head.
  • the following contents vary depending on the type of the corresponding elementary stream.
  • the type of the corresponding elementary stream can be determined based on the value of field sae_id.
  • field 1 "& [6_5 63111-1 (1] described with reference to Fig. 25.
  • Fig. 27 Describes the elementary stream types supported by block DynamicInfoO using the if syntax to describe whether the stream is a video stream, audio stream, or subtitle (subtitle) stream. () Will be explained for each elementalist stream.
  • the block DynamicInfoO consists of a field display-aspect-ratio force with a data length of 4 bits.
  • Fielded display—aspec t_ratio indicates whether the video display output aspect ratio is 16: 9 or 4: 3.
  • the field reserved—for—word—al ignment is used to set the ti position to 1 '6 bits'.
  • the book DynamicInfoO has a field channel_assignment force having a data length of 4 bits.
  • DynamicInfoO consists of a 'field reserved_for-word-alignment' that is used to align the data arrangement to 16 bits. In other words, dynamically changing attributes are not defined for subtitle streams.
  • the block EPjnapO represents the decoding start possible position (also called entry point or random access point (RAP)) in the bit stream for each elementary stream using time information and position information.
  • RAP random access point
  • As the position information for example, a minimum unit of access in a recording medium on which an elementary stream is recorded can be used.
  • Each elementary stream can be decoded from the position indicated by block EPjnapO.
  • the decoding start possible position can be obtained by calculation, so information such as this block EPjnapO is unnecessary.
  • information such as this block EPjnapO is unnecessary.
  • it is important information for random access in the case of a variable rate stream or a stream whose data size changes for each access unit, such as MP EG video compression and encoding.
  • a field reserve_for_word_alignment having an 8-bit key length is arranged in order to align the arrangement to 16 bits. This is followed by the field number—0 and st ream—id—en tries.
  • the field number—of_stream—id—entries has an 8-bit data length and indicates the number of elementary streams described in this block EP-map ().
  • the first for loop causes the field stream id, fielded private—stream—id ⁇ 3 and field——rered number—of—EP—en tries force; Furthermore, for each description of the first for loop, the field PTS—EP_s tart and the field RPN_EP_s tart are allocated by the second for loop as many times as indicated by the field number—0 and EP_entries. Is done.
  • a field s earn—id and a field private_stream_id each having an 8-bit data length are arranged, and an example is shown in Fig. 25. I have identified.
  • the distributed field number_o and EP_entries have a 32-bit data length and indicate the number of entry points described for the corresponding elementary stream.
  • the field number—0 and the number of fields indicated by EP_entries! ⁇ 5 ⁇ ?-51 & the field RPN_EP_start are allocated.
  • Field PTS—EP_start and field RPN_EP_start each have a data length of 33 to 3 bits and represent the entry point itself.
  • the field PTS_EP_start indicates the time in the clip AV stream file of the entry point in PTS.
  • the field RPN_EP—start indicates the position of the entry point in the clip AV stream file, for example, in units of 2 048 bytes.
  • one sector which is a disk-shaped access unit, is 2 048 bytes. Therefore, the position of the entry point in the clip AV stream file is indicated in units of sectors by the field RPN_EP_start.
  • the block EP_map () associates the time on the clip AV stream with the position in the clip AV stream file.
  • a set of time information and position information for each elementary stream (a set of field PTS_EP_start and field RPN-EP-start in the second for loop). ) Is registered in advance in ascending order (or descending order) for both fields PTS—EP_start and RPN_EP_start. In other words, time information and position information are rearranged in a predetermined direction in advance. For this reason, it is possible to execute a binary tree search on the data as it is.
  • the video elementary list is described as an elementary list based on the MP EG 2-Video standard, but this is not limited to this example.
  • the video elementary stream may be based on MP EG4-Visua 1 or MP EG 4-AVC.
  • the audio elementalist stream is the ATRAC audio elementalist stream. However, this is not limited to this example, and can be applied to, for example, MP EG 1 Z2Z4 audio.
  • FIG. 29 schematically shows an example of the structure of a disc playback apparatus 100 to which the present invention can be applied.
  • bus 1 1 CPU (Central Processing Unit) 1 1 2, Memory 1 1.3, Drive-in evening interface 1 14, Input interface 1 1 5, Video decoder 1 1 6, Audio decoder 1 1 7.
  • Video output interface 1 1 8 and audio output interface 1 1 9 are connected respectively.
  • Each part of the disc playback device 100 can exchange a video stream, an audio stream, various commands and data, etc. via the bus 1 1 1.
  • a disk drive 102 is connected to the drive-in evening face 1 14.
  • the disk drive 102 exchanges data and commands with the bus 1 1 1 via the drive interface 1 14.
  • the CPU 1 1 2 has a ROM (Read Only Memory) and a RAM (Random Access Memory) (not shown), and the bus 11 1 1 is connected according to the program stored in the ROM. Data is exchanged with each part of the disc playback device 100 via this, and the entire disc playback device 100 is controlled. RAM is used as work memory for C P U 1 1 2.
  • the disc playback device 100 is a flash that can rewrite data and retains the stored contents even after the power source of the disc playback device 100 is set to OF.
  • Memory etc. Can have non-volatile memory.
  • Non-volatile memory for example, bus
  • the input interface 1 1 5 is supplied with an input signal from an input device on which an input operation is actually performed by a user.
  • the input device is, for example, a remote control commander that remotely operates the disc playback device 100 with an infrared signal or the like, or a key provided directly on the disc playback device 100.
  • the input interface 1 1 5 converts the input signals supplied from these input devices into control signals for the CPU 1 1 2 and outputs them.
  • the disc 1001 has a format such as that described in FIG. 18 and after, in which a playlist, a script program, a clip information file, a clip AV stream file, and the like are recorded.
  • the disc 1 0 1 is loaded into the disc drive 10 02, the disc 1 0 1 is played in accordance with automatic playback or user input operation.
  • the script file, playlist file, and clip information file read from the disc 100 are supplied to the CPU 1 1 2 and stored, for example, in the RAM of the CPU 1 1 2.
  • the CPU 1 1 2 reads the clip AV stream file from the disk 1 0 1 based on the data stored in the RAM and the script program.
  • the clip AV stream file read from the disc 1 0 1 is temporarily stored in the memory 1 1 3.
  • the video decoder 1 1 6 decodes the video stream and subtitle stream of the clip AV stream file stored in the memory 1 1 3 based on the instruction of the CPU 1 1 2
  • the decoded video data and subtitle data are subjected to image processing such as enlargement and reduction processing, respectively, by the CPU 1 1 2, for example; and are combined and added to form one video data.
  • image processes are not limited to this, and can also be performed by the video decoder 1 16 and the video output interface 1 1 8.
  • This video data is buffered in the memory 1 1 3 and supplied to the video output face 1 1 8.
  • the video output interface 1 1 8 converts the supplied video data into an analog video signal and outputs it to the video output terminal 1 2 0.
  • the audio decoder 1 1 7 decodes the audio stream of the clip AV stream file stored in the memory 1 1 3 based on the instruction of C P U 1 1 2.
  • the decoded audio data is buffered in the memory 1 1 3 and supplied to the audio output interface 1 1 9.
  • the audio output interface 1 1 9 converts the supplied audio data into, for example, an analog audio signal and outputs it to the audio output terminal 1 2 1.
  • each part shown in FIG. 29 is described as being configured by independent hardware, but this is not limited to this example.
  • the video decoder 1 1 6 and / or the audio decoder 1 1 7 can be configured by software operating on the C P U 1 1 2.
  • disk playback device 100 includes CPU 1.12 and a memory and operates by a program, it can be considered as a kind of computer device.
  • FIG. 30A and FIG. 30B are functional block diagrams for explaining the operation of the disc playback apparatus 100 shown in FIG. 29 in more detail. is there.
  • the disc playback apparatus 1 0 0 generally includes an operation system 2 0 1 and a video content playback unit 2 1 0.
  • the video content playback unit 2 1 0 is substantially a software program that runs on the operation system 2 '0 1.
  • the video content playback unit 210 is not limited to this, and the software and hardware may operate in an integrated manner. In the following description, it is assumed that the video content playback unit 2 10 is software.
  • the disk drive 1 0 2 is omitted.
  • the operation system 2 0 1 starts up first in the CPU 1 1 2 when the power is turned on to the disc playback device 1 0 0, and performs necessary processing such as initial setting of each part, and the application program (here, video content playback) Part 2 1 0) is called from ROM.
  • the operation system 20 0 1 performs basic operations such as reading a file from the disc 1 0 1 and interpreting the file system to the video content playback unit 2 1 0 during the operation of the video content playback unit 2 1 0.
  • the operation system 20 1 controls the disk drive 1 0 2 via the drive-in interface 1 1 4 according to the file read request passed from the video content playback unit 2 1 0, and 1 0 Read the data recorded in 1.
  • the read data is transferred to the video content playback unit 2 10 under the control of the operation system 2 0 1.
  • the operation system 20 1 has a multitask processing function, and can control a plurality of software modules apparently in parallel by, for example, time division control.
  • the modules constituting the video content playback unit 210 shown in FIGS. 30A and B are examples of the multitask processing function of the operation system 210. All can operate in parallel.
  • the video content playback unit 210 has several modules inside, and realizes the following functions.
  • the resource file is read from the disc 1 0 1 and passed to the script control module 2 1 1.
  • the files that make up the database are also read out to the player control module 2 1 2 hand over.
  • the script control module 211 stores the received resource file in a predetermined area of a RAM (not shown) of the CPU 112, for example.
  • CPU 1 1 2 (script control module 2 1 1) reads the script program stored in this RAM, interprets it and executes it.
  • the resource file may be stored in a predetermined area of the memory 1 1 3 and read into a RAM (not shown) of the CPU 1 1 2 as necessary.
  • the GUI processing such as creation and output of images such as menu screens, cursor movement according to user input, and change of menu screens can be performed by a script program. This is achieved by controlling At this time, The image data and sound data stored in the resource file on the memory 1 1 3 are used to create the menu screen.
  • the script control module 2 1 1 can control the player control module 2 1 2 by executing a script program.
  • the player control module 2 1 2 is a database stored in files such as playlist file “PLAYL I ST. DAT” and clip information file “XXXXX. CLP” read from disc 1 0 1. Referring to the information, the following control related to the playback of the video content recorded on the disc 10 1 is performed.
  • the time information on the video stream being played is acquired from the decode control module 2 1 4 and the time is displayed and mark events are generated.
  • the content data supply module 2 1 3 reads the content data such as the clip AV stream file from the disc 1 0 1 according to the instruction of the player control module 2 1 2 and passes it to the buffer control module 2 1 5.
  • the buffer control module 2 1 5 stores the received content data in the memory 1 1 3 as the buffer entity 2 1 5 A.
  • the content data supply module 2 1 3 is a buffer control module.
  • the content stored in the memory 1 1 3 is controlled according to the requests from the video decoder control module 2 1 6, the audio decoder control module 2 1 7 and the subtitle decoder control module 2 1 8. Supplied to these modules 2 1 6, 2 1 7 and 2 1 8 as required.
  • the content data supply module 2 13 receives the content data from the disk 100 1 so as to control the amount of content data stored by the buffer control module 2 15 to a predetermined level.
  • the decode control module 2 1 4 controls the operations of the video decoder control module 2 1 6, audio decoder control module 2 1 7, and subtitle decoder control module 2 1 8 in accordance with instructions from the player control module 2 1 2.
  • the decode control module 2 1 4 has a clock function inside, and the decoder control modules 2 1 6, 2 1 7 and 2 1 are provided so that video data and audio data are output synchronously. Control the operation of 8.
  • the buffer control module 2 15 exclusively uses a part of the memory 1 13 as the buffer entity 2 15 A.
  • the buffer control module 2 15 stores a data start pointer and a data write pointer.
  • the buffer control module 2 15 has a video readout function, an audio readout function, and a caption readout function as internal modules.
  • the video readout function has a video readout pointer.
  • a register for accumulating information au_information (), which is information about the session, is provided inside the video readout function.
  • the audio read function has an audio read pointer.
  • the subtitle read function has a subtitle read pin and a subtitle read function flag. Subtitle readout function Controls whether to enable or disable the caption reading function according to the value to be written.
  • the caption reading function when “1” is written to the caption reading function flag, the caption reading function is enabled, and when “0” is written, the caption reading function is disabled.
  • the video read function, audio read function, and subtitle read function which are internal modules of the buffer control module 2 1 5, further, each stream from the clip AV stream in which the video stream, audio stream, and subtitle stream are multiplexed, Demultiplexer function to separate.
  • a clip AV stream is formed by time-division multiplexing a plurality of elementary streams in the MPEG 2 system program stream format. Therefore, the video readout function, audio readout function, and subtitle readout function have a demultiplexer function for the program stream of the MPEG 2 system.
  • the video reading function reads and holds the value of the field stream-id (see Fig. 25) arranged in the stream.
  • the audio reading function and subtitle reading function read and hold the values of the field stream_id and the field private_stream—id (see Fig. 25).
  • the values of these fields stream_id and field private_stream—id are used when analyzing the supplied bitstream.
  • the video decoder control module 2 1 6 reads a single video access unit of the video stream from the memory 1 1 3 and supplies it to the video decoder 1 1 6. Give instructions to the read function.
  • the video decoder control module 2 1 6 controls the video decoder 1 1 6 1 1 6 Decodes the video stream supplied to each access unit. The video overnight generated by decoding the video stream is supplied to the graphics processing module 2 19.
  • the audio decoder control module 2 1 7 reads the single audio access unit of the audio stream from the memory 1 1 3 and supplies it to the audio decoder 1 7. Give instructions to the audio readout function in 5.
  • the access unit (audio frame) constituting the audio stream has a known fixed length.
  • the audio decoder control module 2 17 controls the audio decoder 1 17 to decode the audio stream supplied to the audio decoder 1 17 in units of access units.
  • the audio data generated by decoding the audio stream is supplied to the audio output module 2 42.
  • the subtitle decoder control module 2 1 8 reads out a single subtitle access unit size of the subtitle stream from the memory 1 1 3 and supplies it to the subtitle decoder control module 2 1 8.
  • the buffer control module 2 1 5 The subtitle reading function is instructed.
  • the subtitle access unit constituting the subtitle stream stores the length information of the unit at the head of the unit.
  • the subtitle decoder control module 2 1 8 has a subtitle decoding function and can decode the supplied subtitle stream.
  • the caption image data obtained by decoding the caption stream by the caption decoding function of the caption decoder control module 2 1 8 is supplied to the graphics processing module 2 19.
  • the graphics processing module 2 1 9 Based on the control of the coder control module 2 1 6, the video data decoded by the video decoder 1 1 6 and the subtitle image data decoded by the subtitle decoder control module 2 1 8 ′ are supplied.
  • the graphics processing module 2 19 adds predetermined subtitle image data to the supplied video data to generate a video signal for output.
  • the graphics processing module 2 19 further generates a menu image and a message image according to the instructions of the script control module 2 1 1 and the player control module 2 1 2 and synthesizes (overlays) the output video signal.
  • the graphics processing module 2 19 performs enlargement processing and reduction processing on the supplied subtitle image data in accordance with an instruction from the script control module 2 11 1 and adds the video data to a predetermined amount. .
  • the graphics processing module 2 19 can output the output signal based on the aspect ratio of the output video device specified in advance and the output aspect ratio specified in the content played from the disc 1 0 1.
  • Perform aspect conversion For example, if the aspect ratio of the output video device is 16: 9, if the output aspect ratio is 16: 9, the video data is output as it is, and the output aspect ratio is 4: 3.
  • the output video data is squeezed (reduced) so that the image height matches the screen height of the output video device, and a black image is inserted to the left and right of the image and output.
  • the output video device is 4: 3, if the output aspect ratio is 4: 3, the video data will be output as it is, and if the output aspect ratio is 16: 9, it will be output. Squeeze the video data so that the image width matches the screen width of the output video device, and insert black images above and below the image. Output.
  • the graphics processing module 2 19 captures the video signal currently being processed, and performs processing to return it to the player control module 2 1 2.
  • the video output module 2 4 1 exclusively occupies a portion of the memory 1 1 3 and is used as a buffer for FIF 0 (Fi rst In Fi rst t Out), and the graphics processing module 2 1 9
  • FIF 0 Fi rst In Fi rst t Out
  • the video data processed by is temporarily stored in this buffer, and is read out at a predetermined timing.
  • the video data read from the buffer is output from the video output interface 1 1 8.
  • the audio output module 2 4 2 exclusively occupies a part of the memory 1 1 3 and uses it as a FIFO buffer, stores the audio data output from the audio decoder 1 1 7 in this buffer, and reads it at a predetermined timing Take control.
  • the audio data read from the buffer is output from the audio output interface 1 1 9.
  • the audio output module 2 42 2 outputs audio data according to a previously specified audio output mode. If the audio output mode is set to “main audio”, for example, the left channel audio data is copied to the right channel in memory 1 1 3 and both outputs of the two channels are both left channel audio. Output as data. If the audio output mode is “Sub Audio”, for example, the right channel audio data is copied to the left channel in the memory 1 1 3 and both the 2 channel outputs are both right channel audio. Output as de-evening. Audio output mode is ⁇ Main 'Sub audio'' If the content is stereo or the content is stereo, the audio data is output as it is. 'The audio output mode can be set interactively by the user through the menu screen generated by the video content playback unit 2 '10.
  • the nonvolatile memory control module 2 5 0 In response to an instruction from the player control module 2 1 2, the nonvolatile memory control module 2 5 0 writes data to an area that is not erased even when the video content playback unit 2 1 0 ends, and reads data from the area. I do.
  • the title identification ID (Title—ID) as a key, it has a function to store multiple sets of data Saved_Player_Status and Saved—User—Data in the corresponding area.
  • Saved_Player_Status data Backup_Player_Status of the player control module 2 1 2 is stored. This data Backup-Player-Status corresponds to the data immediately before the player control module 2 1 2 ends, for example, the player status 3 2 3 B described above.
  • the data SavecLPlayer_Status is the resume information 3 24 It corresponds to. Further, the user_data stored in the player control module 2 1 2 is stored as data Saved_User—Data. Data User—Data is a predetermined data set for the player control module 2 1 2 by the user.
  • the non-volatile memory control module 2 5 0 stores the set of these data Saved_Player_Status and data Saved_User in association with the title ID of the disc 1 0 1 in a predetermined area of the non-volatile memory of the disc playback device 1 0 0. .
  • the storage medium in which the nonvolatile memory control module 2 5 0 stores data is not limited to the nonvolatile memory, and may be a hard disk, for example.
  • the state transition model of the movie player 300 is defined only in the internal state of the movie player 300.
  • the state of the movie player 300 is defined based on the operation and function of the movie player 300 itself.
  • two states are defined as to whether the movie player 300 is in the play state or in the stop state.
  • two states are defined as whether or not the movie player 300 receives control commands from the native implementation platform 301.
  • FIG. 31 conceptually shows the definition of the state of the movie player 300 according to the present invention.
  • the following describes how the movie player 300 looks from the operation side.
  • the movie player 300 is in a play state or a stop state from the viewpoint of play list reproduction.
  • the play state is a state in which the movie player 300 selects a playlist and plays back the selected playlist.
  • the stop state is a state in which the movie player 300 does not play the playlist. In the stop state, no playlist is selected.
  • the state in which the clip AV stream is decoded by the playback module 3 2 1 of the movie player 300 is the play state, and the state in which the clip AV stream is not decoded is the stop state.
  • the play state is further subdivided into several states. For example, normal playback at 1x normal speed in the forward direction, replay other than 1x normal speed in the forward and reverse directions
  • the playback state includes various playback states such as variable speed playback at a live speed and pause.
  • Frame-by-frame playback and frame-by-frame playback are realized by alternately performing normal playback and pause.
  • the movie player 300 is synonymous with being in a play state.
  • the movie player 300 has a mode that accepts control commands 3 1 1 from the native implementation platform 30 1 (referred to as normal mode) and a mode that ignores control commands 3 1 1 It has two operation modes. These two operation modes of the movie player 300 are defined as the states of the movie player 300.
  • the operation of the movie player 3 0 0 can be controlled by the user input 3 1 0 without using the script program of the script layer 3 0 2.
  • the movie player 3 0 0 does not accept the control command 3 1 1.
  • the movie player 3 0 0 accepts only the method 3 1 3 from the script layer 3 0 2. Therefore, all the operations of the movie player 300 can be controlled by the script program of the script layer 300.
  • user input 3 10 is passed to script layer 3 0 2 as event 3 1 4 from native implementation platform 3 0 1.
  • the script program of the script layer 3 0 2 controls the operation of the movie player 3 0 0 using the method 3 1 3 corresponding to the event 3 1 4.
  • the content creator can control the operation of the movie player 300.
  • Meni By using u-mode, a variety of controls can be realized with a small number of keys.
  • the movie player 300 has two states of play state and a skip state on the operation side, and has two operation modes of the normal mode and the menu mode on the function side. Therefore, the movie player 300 has four states defined by combining these two operation modes and the two function modes. That is, the movie player 300 belongs to one of these four states from when it is created until it disappears. The generation and disappearance of the movie player 300 will be described later.
  • the movie player 3 0 0 is displayed on the issued method 3 1 3 on the model. In response, the state is immediately changed.
  • the time from when a method 3 1 3 is issued to the movie player 3 0 0 until the movie player 3 0 0 completes the state transition corresponding to the method 3 1 3 is It depends on the implementation of the equipment.
  • a method 3 1 3 is issued to instruct a movie player 3 0 0 in a certain state to make a state transition to the same state as that state, the state of the movie player 3 0 0 does not change.
  • a method 3 13 that issues the transition of the state of the movie player 300 to the stopped state in the normal mode is issued.
  • the status of the movie player 3 0 0 does not change.
  • pause (pause) state is a kind of play state. To make a transition from the stop state to the pause state, specify pause. Use the method play 0 with the value pauseMode as an argument.
  • the state of each of the four states combining the two states of the movie player 300 and the two operation modes, and the state transition between the four states will be described.
  • the normal mode is “normal” and the menu mode is “me nuj.
  • the state of movie player 300 is the operation surface.
  • play state is “play”
  • stop state is “stop”.
  • the combination of the mode (mode) and the status (status) of the movie player 300 is expressed as a status ⁇ mode, status ⁇ .
  • the state change and mode switching in the movie player 300 are both referred to as state transitions.
  • X4 16 types of movie player 3 0 0 state transitions including transitions to one's own state. These state transitions are caused by a method 3 1 3 passed from the script layer 3 0 2 to the movie player 3 0 0.
  • the state transition in the movie player 3 0 0 is caused by the outside of the movie player 3 0 0 and is automatically set in the movie player 3 0 0 without any instruction from the script layer 3 0 2. There is no transition.
  • no state transition occurs in the movie player 300.
  • the movie player 300 is in a stop state in which the play list is not being played back, and the control command 3 1 1 from the native implementation platform 301 is not accepted. This state is used, for example, on a menu screen where no moving image is played in the background.
  • the control command 3 1 1 from the native mounting platform 3 0 1 should not be accepted at that time. Is effective. Therefore, immediately after the movie player 3 0 0 is generated, it is determined that this state is ⁇ Menu, Stop ⁇ .
  • This state is used, for example, when a moving image is not played back. Since this state accepts the control command 3 1 1, it is preferable not to use it immediately after the movie player 300 is generated.
  • the movie player 300 is in the play state where the playlist is being played, and the control command 3 1 1 from the native implementation platform 301 is not accepted. This state is used, for example, on a menu screen where a moving image is played in the background.
  • the above-described model when the movie player 300 is generated will be schematically described.
  • the disc player 100 when the disc player 100 is turned on and the operation system 201 is started in the CPU 1 1 2, the movie player 300 needs to be initialized.
  • the video content playback unit 2 1 0 is called from the ROM.
  • This video content playback unit 2 1 0 is executed by C P U 1 1 2.
  • the power source is turned into the OF F state in the disc playback device 100, the movie player 300 is turned off.
  • the movie player 300 is considered to have generated a silent (i immediate licit) object, and it is not necessary to explicitly generate the movie player 300 in the scribe program.
  • the state immediately after the movie player 300 is generated is the menu mode stop state (state ⁇ Menu, Stop ⁇ ).
  • the following properties of the movie player 300 are indeterminate values.
  • Pronoti videoNumber Note that in a UMD video player that has a “continuous playback function” that starts playback from the position where playback was stopped last time, the default value of each property for each of the above properties, for example, in the movie player 3 0 0 fc> initialization. Instead, values can be set using values stored in non-volatile memory. For example, resume information 3 2 4 can be used.
  • FIG. 32 shows a combination of the current state ⁇ Mode, Status ⁇ and the state ⁇ Mode, Status ⁇ after the state transition by method 3 1 3 for each of the 4 states of movie player 3 0 0.
  • the method stop (), the method playO and the method resumeO are prepared as methods 3 1 3 for generating a state transition for the movie player 3 0 0. Note that the operation of the method resume 0 changes depending on whether or not the resume information 324 exists.
  • the method stop 0 will be described.
  • the method stop 0 changes the movie player 3 0 0 to the stop state regardless of the state of the movie player 3 0 0.
  • the method stopO can specify the mode as an argument, and can change the mode of the movie player 300 simultaneously with the transition to the stop state.
  • the player status 3 2 3 B is backed up and held as the re-formed information 3 24.
  • the method playO is explained.
  • the method playO changes the movie player 3 0 0 to the play state.
  • the method playO is used as an argument.
  • the mode can be specified, and at the same time as the transition to the play state,
  • Player 3 0 0 mode can be changed. As will be described later ('When the method playO is executed when a certain condition is satisfied, the player status 3 2 3 B is backed up and the resume information 3 24 is held.
  • the method resumeO is described.
  • the method resume 0 is a method for restoring the resume information 3 24 to the player status 3 2 3 B to resume playback. That is, the method resume 0 causes the movie player 300 to start playback from the position indicated by the resume information 324. Even if the method resume 0 is executed when there is no resume information 3 24, the state of the movie player 3 0 0 does not change.
  • the conditions under which resume information 3 24 is restored by method resumeO are as follows.
  • the resumeO method is executed, if the resume information 3 24 exists and the current state is not the state ⁇ Normal, Play ⁇ , the movie player 3 0 0 restores the resume information 3 24 .
  • the resume information 3 24 exists, and the current state is the state ⁇ Menu, Stop ⁇ , state ⁇ No rma and Stop ⁇ , and state ⁇ Menu, Play ⁇ . If any one of them, the movie player 300 moves to the state ⁇ Norma and Play ⁇ , and at the same time, resumes the resume information 324.
  • the method PlayO has multiple arguments.
  • the method playO has three types of arguments: bow I number pauseMode, bow I number menuMode, and 5l number playUstNumber.
  • the argument pauseMode specifies the playback status in the play state, and can take one of the values “x 1”, “pause”, and “ ⁇ 1”.
  • the value “xlj” specifies normal speed forward playback.
  • the value “pause” specifies “pause”.
  • a value of “-1” specifies to maintain the current playback speed.
  • the argument pauseMode sets the details of the play state of the movie player 3 0 0 after the execution of the method play 0. If pause is specified, the picture at the position specified by the argument, or the picture at the position specified by the separately defined selection rule, is displayed if there is no specification by the argument. Become.
  • the argument menuMode specifies the mode of the movie player 300 (normal mode and menu mode), and can take one of the values "Normal”, "Menu”, and "-1".
  • the value “Normal” specifies switching to normal mode.
  • the value “Menu” specifies switching to menu mode.
  • a value of “-1” specifies to keep the current mode.
  • the argument playListNumber specifies the number of the playlist to be played.
  • the argument playListNumber can be omitted. In this case, it means that the currently selected playlist is not changed.
  • FIG. 33A shows an example in which the method play (xl, Normal, PL2) is issued to the movie player 300 in the state ⁇ Norma and Stop ⁇ . This shows that the state of the movie player 300 becomes a state where the playlist with the playlist number “PL 2” is played in the normal mode and the normal speed in accordance with the method play (xl, Normal, PL2). Movie player 300 has transitioned from state ⁇ Normal, Stop ⁇ to state ⁇ Normal, Play ⁇ .
  • Figure 33B shows the method play (xl, Normal) for the movie player 300 in the state ⁇ Normal, Play ⁇ that is paused during playback of the playlist with the playlist number “PL 1”. , PL2) is an example.
  • the state of the movie player 300 indicates that the play list with the play list number “P L 2” starts to play in the normal mode and the normal speed in accordance with the method play (xl, Normal, PL2).
  • the playback operation of the movie player 300 changes from the pause to the normal speed playback in the forward direction, but the state changes before and after the issuance of the method play (xl, Normal, P L2). No state transition has occurred.
  • Fig. 33C shows the method play (-for the player 300 in the state ⁇ Norma and Play ⁇ playing the playlist with the playlist number "PL 1" at the normal speed in the forward direction.
  • This is an example of issuing l, -1, PL2).
  • the status of the movie player 300 indicates that the playlist with the playlist number "PL 2" will be played in normal mode and normal speed. Yes.
  • the playlist ⁇ played on the movie player 300 is changed. The state remains in the state ⁇ Normal, Play ⁇ and no state transition has occurred.
  • Figure 3 3D shows that the playlist with the playlist number “PL 1” is being played at normal speed in the forward direction and is in the state ⁇ Normal, Play ⁇ . , -1, PL2) is an example.
  • the movie player 3 0 0 selects the playlist with the playlist number “PL 2”, and the playlist with the normal mode and playlist number “PL 2”. It shows that it will be in the state of being paused at the head of. In this case as well, the playback operation of the movie player 300 changes from normal speed playback in the forward direction to pause, but the state remains in the state ⁇ Norma and Play ⁇ , and no state transition has occurred. .
  • Figure 3 3 E shows that the method play is paused during playback of the playlist with the playlist number “PL 1” and is in the state ⁇ Normal, P 1 ay ⁇ .
  • This is an example when (-l, Menu) is issued.
  • argument PlayListNumber is omitted.
  • the movie player 3 0 0 selects the playlist with the playlist number “PL 1” and at the top of the playlist ⁇ with the menu mode and playlist number “PL 1”. It indicates that it is in a paused state.
  • the movie player 3 0 0 transitions from the state ⁇ Norma and Play ⁇ to the state ⁇ Menu, Stop ⁇ .
  • the movie player 300 performs various operations in response to the method PlayO from the script program, and at that time, state transition occurs depending on conditions.
  • the content creator can realize various operations in the movie player 300 by describing the method “playO” with different arguments in the script program.
  • the movie player 300 starts playback of the playlist with the playlist number selected only by executing the method “play O” from the script program.
  • Start playback of a playlist is to start playback of a playlist from a stopped state, or to stop playback of a playlist and select a new playlist, and start playback of the selected playlist ⁇ . To do.
  • the value of the argument is set to the player status 3 2 3 B.
  • the value of the argument is set by default value or automatic selection according to the rules defined for each parameter.
  • the movie player 3 0 0 starts playing the playlist, it continues to play until the end of the playlist. Playback from the beginning to the end of a playlist requires user operation and control from a script program. do not do.
  • the movie player 300 specifies the play items that make up the play list in the play list file "PLAYL I ST. DAT" (see Figure 19). Play sequentially as you did. The play items that make up the playlist are played continuously without control by the event handler.
  • the operation from the end of playback of a play item to the playback of the next play item depends on the implementation of the movie player 300 and is not specified in the format. For example, operations between play items such as whether to continue to display the last picture of a play item or immediately turn to a black screen are implementation-dependent. However, the gap time between the play items can be shortened as much as possible by taking some creative measures such as setting the IN point of the play item as a random access point (see entry point: Fig. 28). It is possible to make a careful consideration.
  • the speed during variable speed playback depends on the implementation of movie player 300. For example, tell the movie player 3 0 0 as an instruction of the native implementation platform 3 0 1 that can specify the speed, and pass “faster” or “slower” as an argument to the movie player 3 0 0
  • a method for realizing variable speed playback such as converting the speed to a speed that can be realized by the player 300, is conceivable, and which method is used depends on the implementation of the movie player 300.
  • the script program can know the speed determined by the movie player 3 0 0 by the method getPlayerStatusO.
  • the speed cannot be specified by the argument.
  • the method playO can be specified only for pause (argument “pause”) and normal speed play (argument “xl”).
  • Movie player 300 plays the next play item when it reaches the end of the play item while playing the play list in the forward direction. At this time, the movie player 300 plays the next play item in the same direction and at the same speed as the previous play item, and continues variable speed playback.
  • FIG. 35 shows an example of the operation of the movie player 300 when the start point and end point of the playlist are reached during playback of the playlist. If the player reaches the end of the playlist ⁇ during playback in the forward direction, the player 3 0 0 pauses with the last picture displayed. To delete the last picture, it is necessary to explicitly instruct the movie player 300 to stop (issue method stopO) in the event handler onPlayListEnd.
  • the previous play item In other words, play items that are played back in time when played forward are played. This replay of the previous play item also continues reverse playback from the end to the beginning. The playback speed is also maintained. Also, when the top of the playlist is reached during reverse playback, the variable speed playback is canceled and the movie player 300 is paused at the top of the playlist.
  • the state of the movie player 3 0 0 is changed to pause by the control command 3 1 1 instructing pause.
  • the playlist playback direction and playback speed when pausing is canceled with control command 3 1 1 depend on the implementation of the UMD video player.
  • the events that occur during playlist playback are the event angleChange, event audioChange and event subtitleChange according to the user operation, as well as embedded in the playlist, as described above with reference to Fig. 13
  • the movie player 300 plays the playlist with the number specified by the method playO. Once playback of the playlist is started, playback continues until the end of the playlist without control by the script program or control command 3 1 1.
  • the movie player 300 sends an event playUstEnd to the scribble program. It doesn't matter how you reach the end of Playlist ⁇ ⁇ .
  • playlist playback is normal playback, fast-forward playback, and flying from other playlists. Regardless of whether or not the playback is due to, for example, when the end of the playlist is reached, the movie player 300 emits the event playListEnd.
  • the state of the movie player 300 is paused, and the playback time of the playlist that the movie player 300 has internally is the end of the playlist. Matches the time.
  • the last time in the playlist is the playback end time of the last picture in the playlist, which matches the 0 UT point of the last play item on the playback time axis.
  • the event playListEnd is used to play a playlist in a line or to display a menu at a multi-story branch point.
  • the script handler executes the event handler onPlayListEnd. If this event handler onPlayListEnd describes a method playO for starting playback of another playlist, the movie player 300 starts playback of another playlist. In this way, playback of the playlist is continued.
  • playback of the playlist with the playlist number “PL l” ends, and the event PlayListEnd is generated.
  • the event handler onPlayListEnd of the script program is executed.
  • playback of the playlist with the playlist number “PL 2” is designated.
  • the movie player 300 receives the event handler onPlayListEnd and receives the specified play. Play the playlist with list number “PL 2”.
  • the playback path temporarily moves from the end of the playlist with the playlist number “PL 1” to the event handler onPlayListEnd, and further to the top of the playlist ⁇ with the playlist number “P L 2”.
  • an instruction to play a playlist that displays the menu screen at the event handler onPlayListEnd corresponding to the event playListEnd, with the end of the playlist as the branch point Can be considered.
  • FIG. 37 shows an example of the flow of processing in the script layer 302 at the end of the playlist and an example of the operation of the movie player 300 in more detail.
  • steps S30 to S33 show the processing on the script layer 302 side
  • steps S40 to S44 show the processing on the movie player 300 side.
  • step S 40 When playback reaches the end of the playlist (step S 40), the movie player 300 notifies the event playListEnd to the script layer 3 02 (step S 41). The movie player 300 transitions to a pause state while continuing to display the last picture of the playlist that has been played to the end in step S40 (step S42).
  • the script layer 302 Upon receiving the event playListEnd, the script layer 302 executes the event handler onPlayListEnd (step S30). The next action of the movie player 300 is this event handler onPlayList It depends on the description of the scribe in the End.
  • the movie player 300 does not receive a control command 3 1 1 after releasing the pause or starting forward playback when paused at the end of the playlist ⁇ after step S 40. , ignore.
  • the methods that start forward playback are the method playO and the method playStepO that specify the forward playback with an argument.
  • the control command 3 1 1 for starting forward playback includes command uo_play (), command u 0—playNextChapter 0, command uo_forwardScan 0, command uo—play Step (), command uo—pauseOnO and command uo— There is pauseOf f 0 and these commands are ignored when paused at the end of the playlist.
  • Mode switching is also effective in the last paused state of playlist ⁇ .
  • the normal mode player 3 0 0 receives a control command 3 1 1 other than the control command 3 1 1 for starting forward playback. Even in this case, when the method 3 1 3 is executed from the script program to the movie player 3 0 0, the operation instructed by the method 3 1 3 is followed.
  • the method sto P () is instructed by the event handler onPlayListEnd (step S 3 1).
  • the movie player 3 0 0 suspends the operation caused by the control command 3 1 1 by executing the method stop 0, and transitions to the stop state (step S 43).
  • the stop state for example, the last picture in the playlist that had been played back immediately before is erased, resulting in a black screen.
  • the event handler onPlayLi In stEnd, method 3 1 3 for reproducing the next playlist is instructed (step S 3 2).
  • the value “xl” is set as the argument pauseMode
  • the value “Menu” is set as the argument menuMode
  • the next play list number is specified as the argument playListNumber.
  • the event handler onPlayListEnd is ended in the script layer 30 2 (step S 3 3).
  • the mode is switched according to the method playO instructed in step S32, and the specified playlist ⁇ starts to be played at the specified speed (step S44). .
  • a player status area 5 01 a resume information area 5 0 2
  • a user data area 5 0 3 are defined, which are three types of indispensable memory areas.
  • These three types of memory areas 5 0 1 , 5 0 2 and 5 0 3 are formed on the memory 1 1 3, for example. You may form on RAM as a work memory of CPU 1 1 2.
  • the player status area 5 0 1 is a memory area that holds information indicating the playback state of the movie player 3 0 0. That is, the player status area 5 0 1 holds the player status 3 2 3 B in FIG.
  • the contents of the player status area 5 0 1 can be read from the scribing program 5 0 0 by the method getPlayerStatusO.
  • the resume information area 50 2 is a memory area for temporarily saving (backup) a part of the information held in the player status area 5 0 1. That is, a part of the information in the player status area 5 0 1 is held in the resume information area 5 02 as the resume information 3 24 in FIG. A part of the information in the player status area 5 0 1 evacuated to the resume information area 5 0 2 is restored to the player status area 5 0 1 as necessary (restoration). These backups and restorers are performed by the native implementation platform 301.
  • the information held in the resume information area 502 is used by the resume playback function that starts playback from the previous playback stop point.
  • the contents of the resume info area 5 0 2 can be read from the script program 5 0 0 by the method getResumelnfoO.
  • the parameters related to the stream can be changed from the script program 500 using the method changeResumelnfoO.
  • the information held in the resume information area 50 2 is written to the non-volatile memory 5 10 as necessary by the native mounting platform 3 0 1 (save).
  • information written from the resume information area 50 2 to the non-volatile memory 5 10 is read from the non-volatile memory 5 1 0 as necessary by the native mounting platform 3 0 1 (l oad), stored in the re-formation area 5 0 2.
  • 0 0 is a process that occurs in response to a specific state transition, and is automatically performed by the movie player 3 0 0.
  • the user data area 50 3 is an area for holding content-dependent information and can be used arbitrarily by the content creator. Usage is optional depending on the content, such as the history of the playlist playback path by the movie player 300 and the correct answer for the quiz.
  • Data can be written to the user data area 5 0 3 from the script program 5 0 0 by the method setUserDataO.
  • the contents of the user data area 50 3 can be read from the script program 50 0 0 by the method get UserData O.
  • Information held in the user data area 50 3 is written to the non-volatile memory 5 10 as needed by the native mounting platform 3 0 1 (save).
  • information written from the user data area 50 3 to the non-volatile memory 5 10 is read from the non-volatile memory 5 1 0 as required by the native implementation platform 30 1 (load). ), User data It is stored in the evening area 5 0 3.
  • resume operation The operation to restore the playback state using the information backed up in the resume information area 50 2 is called resume.
  • Resume is performed by the method resume O.
  • the player status 3 2 3 B in the player status area 5 0 1 is backed up to the resume information area 5 0 2 to be resume information 3 2 4 and the method res u me () In response to this, the playback state is restored using the resume information 3 2 4 backed up in the resume information area 5 0 2.
  • the player status 3 2 3 B includes the state of the movie player 3 00, that is, the play list number currently played by the movie player 3 00, the chapter number, the selected stream number, and the like.
  • the operation of the movie player 3 0 0 when the method res ume O is issued to the movie player 3 0 0 is re-used in the resume movie area 5 0 2 3 2 4 Depending on whether or not exists.
  • resume information 3 2 4 exists in the resume information area 5 0 2
  • the resume information 3 2 4 is restored as player status 3 2 3 B in the player status area 5 0 1.
  • the resume information 3 2 4 in the resume information area 50 2 is discarded.
  • the playback stream is displayed in the menu called during content playback.
  • FIG. 39 shows the player status 3 2 3 B held in the player status area 5 0 1 among the state transitions between the 4 states defined in the movie player 3 0 0.
  • the resume information area 5 0 2 Shows the state transition to be backed up.
  • FIG. 40 shows the conditions when the player status 3 2 3 B is backed up in the resume information area 50 2.
  • the movie player 3 0 0 changes from the state ⁇ Norma and play ⁇ to the state ⁇ Menu , Play ⁇ , the player status 3 2 3 B held in the player status area 5 0 1 is backed up in the resume information area 5 0 2.
  • the player status 3 2 3 B held in the player status area 5 0 1 is the resume information area Not backed up to 5 0 2.
  • the player status 3 2 3 B is backed up in the resume information area 50 2 and used as the resume information 3 24 in the following case.
  • the current state of the movie player 3 0 0 is the state ⁇ Normal, Play ⁇ , and the state directly changes to the state ⁇ Menu, Play ⁇ by executing the method play 0.
  • the state of the movie player 3 0 0 is the state ⁇ Normal, Play ⁇ , and when the method stopO is executed, the state ⁇ Normal, Stop ⁇ or state ⁇ Menu
  • InfoClearFlag has the value “false”.
  • Saving to 50 2 is assumed to be used to save the return position in this volume. For example, when performing a series of operations such as jumping to the movie menu during main part playback and returning to the main part again for playback, the player status 3 2 3 B is backed up in the resume information area 5 0 2 It is assumed that some resume information 3 24 will be used.
  • the resume information 3 2 4 in the resume information area 5 2 can be read using the method getResume l n f o O.
  • the parameters related to the stream in the resume information 3 2 4 in the resume information area 50 2 can be changed by the method changeResume Info 0.
  • the resume information 3 24 in the resume information area 50 2 can be discarded by specifying the argument of the method st op O.
  • Restoration information 3 2 4 stored in the resume information area 5 0 2 to the player status area 5 0 1 and discarding will be described with reference to FIGS. 41 to 44. .
  • the resume information 3 24 can be discarded after being restored as the player status 3 2 3 B in the player status area 5 0 1 and when it is discarded without being restored. is there.
  • Fig. 41 shows the state transitions among the four state transitions defined in the movie player 3 0 0, where the resume information 3 24 is restored to the player status area 5 0 1 and then discarded.
  • the resume information 3 24 is discarded after being restored.
  • the current state of the movie player 300 is state ⁇ Menu, Stop ⁇ , state ⁇ Norma and Stop ⁇ or state ⁇ Menu, Play ⁇ .
  • the state of the movie player 3 0 0 transitions to the state ⁇ Normal, Play ⁇ . To do. Further, the method resumeO when the resume information 3 24 does not exist in the resume information area 502 does not change the state of the movie player 3 0. At this time, the state ⁇ Mode, State ⁇ immediately before execution of the method resumeO is maintained, and the player status 3 2 3 B is not changed.
  • the current state of the movie player 300 is state ⁇ Menu, Stop ⁇ , state ⁇ Normal, Stop ⁇ or state ⁇ Menu, PI ay ⁇ .
  • Resume information 3 24 exists in the resume information area 5 0 2.
  • Resuming the resume information 3 24 in the resume information area 50 2 can also be caused by setting the argument of the method stopO.
  • an argument resumelnfoClearFlag that specifies whether or not to discard the resume information 324 in the resume information area 502 is defined as an argument of the method stopO.
  • the last position of the main part of the movie is recorded as the reusable form 3 24. If the user then plays back (and continues to play), it jumps to the end of the main movie and pauses, making usability worse.
  • Figure 45 shows the operation of an example of a UMD video player using the argument resumelnfoClearFlag of the method stopO.
  • Steps S50 to S54 show the processing on the script layer 302 side
  • steps S60 to S64 show the processing on the movie player 300 side.
  • step S 60 When playback reaches the end of the playlist (step S 60), the movie player 300 sends the event playListEnd to the script layer 30 2 (step S 61). The movie player 300 moves to a pause state while continuing to display the last picture of the playlist ⁇ that has been played to the end in step S 60 (step S 62).
  • the script layer 3 0 2 executes the event handler onPlayListEnd (step S 50).
  • the next step S 51 it is determined whether or not the playlist ⁇ notified of the event playListEnd is the end of the author scenario. Whether or not a playlist ⁇ is the last playlist in the scenario can be determined based on, for example, a script program 500.
  • step S 5 3 the method stopO argument resumelnfoClearFlag is set to the value Ffalsej, and the resume information 3 24 does not discard the method stop 0 to the movie player 3 0 0 Issue.
  • the movie player 3 0 0 changes to the stop state, and the player status 3 2 3 B is backed up in the resume information area 5 0 2.
  • step S 51 determines that the scenario is the last in step S 51
  • the process proceeds to step S 52, and the argument resumelnfoClearFlag of the method stopO is set to the value “True”.
  • the argument resumelnfoClearFlag of the method stopO is set to the value “True”.
  • step S 52 method end () is executed depending on the description of script program 500.
  • Figure 46 shows an example life cycle of player status 3 2 3 B.
  • a player status 3 2 3 B is also generated.
  • player status 3 2 3 B also disappears.
  • Player status 3 2 3 B is initialized when it is created.
  • the properties that indicate the status of movie player 300 indicate the stopped status, and the other properties are undefined.
  • the value of the player status 3 2 '3 B changes as the playback state of the movie player 3 00 changes.
  • the value of the player status 3 2 3 B changes when the contents of the resume information area 50 2 are restored.
  • the player status 3 2 3 B can be read out by the method getPlayerStatusO from the script layer 3 0 2.
  • player status 3 2 3 B is stored depends on the implementation of the movie player 300. Information can be held in any form as long as it can be obtained from the script by the method getPlayerStatusO.
  • Figures 47 A and 47 B show resume information 3 24 shows an example life cycle.
  • a memory area for the resume information is secured, and initialization is performed together with the creation of the resume information 324.
  • initialization is performed together with the creation of the resume information 324.
  • the contents of resume information 3 24 are discarded.
  • a UMD video player that implements non-volatile memory will be able to use the resume information when initializing the movie player 300
  • the video number, audioNumber, audioFlag, subtitleNumber, and subUtleFlag related to the stream in the resume information 3 24 can be changed by the method changeResumelnfoO from the script layer 3 0 2.
  • Resume information 3 24 values can be read.
  • the resume information 3 24 in the discarded state is read—and the value “0” is returned as the return value playStatus, the presence or absence of the resume info 3 24 can be distinguished.
  • a UMD video player equipped with a non-volatile memory stores the resume information 3 24 in the non-volatile memory when the movie player 300 ends (disappears). At that time, user data is also saved.
  • Figure 48 shows the life cycle of an example of user data.
  • Movie A memory area is secured when the player 300 is created, and user data is created. Initialization occurs at the same time as generation. When it is initialized, the contents of the user account are cleared (the method getUserDataO returns an array of length “0”).
  • a UMD video player with non-volatile memory loads user data from non-volatile memory when the movie player 300 is initialized. At this time, the resume information is also loaded at the same time.
  • the method setUserDataO When the method setUserDataO is executed, user data is written to the user data area 5 03.
  • the method setUserDataO holds an Int type array with a maximum data length of 64 bits in the user data area 50 3. Data in the user data area 50 3 can be read with the method getUserDataO from the scribble layer. If no user data is set, an array of length 0 is returned.
  • a UMD video player equipped with a non-volatile memory saves the data held in the user data area 50 3 to the non-volatile memory when the movie player 300 ends (disappears). At this time, resume information 3 24 is also saved at the same time.
  • the present invention has been described as applied to a disc playback apparatus 100 that processes both an audio stream and a video stream.
  • the present invention is not limited to this example.
  • the present invention can be applied to a case where only an audio stream or a video stream is reproduced.
  • the on-disc recording medium is used as the recording medium on which the content data is recorded.
  • this is not limited to this example.
  • a semiconductor memory can be used as a recording medium on which content data is recorded.
  • the disk reproducing apparatus 100 to which the present invention is applied is described as being configured with dedicated hardware, but this is not limited to this example. That is, the configuration other than the disk drive of the disk playback apparatus 100 can be realized by software operating on the computer apparatus.
  • the software that realizes the disc playback device 100 is recorded on a recording medium such as a CD-ROM (Compact Disc-Read Only Memory) or a DVD-ROM (Digital Versatile Disc-ROM). Can be supplied.
  • a recording medium on which software for realizing the disk playback device 1 0 0 is recorded is loaded into the disk drive of the computer device, and the software recorded on the recording medium is recorded.
  • Software on a computer device By connecting a UMD-compatible disk drive device to the computer device, a configuration equivalent to the disk reproducing device 100 according to the present invention can be realized. It is also possible to record and provide the software on a recording medium that records UMD video content.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)

Abstract

プレーヤ動作の状態遷移を明確に定義し、インタラクティブなコンテンツの制作を容易とする。ディスクを再生するプレーヤモデルとして、ストリームの再生を行うプレーヤ３００、プレーヤ３００とハードウェアとのインターフェイスであるプラットフォーム３０１及びコンテンツ制作者側の意図したシナリオを実現するためのスクリプトレイヤ３０２からなるモデルを考える。プレーヤ３００の状態を、プレイリスト再生を行っているか否かの２状態と、コマンド３１１を受け付けるか否かの２状態とを組み合わせた４状態で定義する。プレーヤ３００の４状態間の状態遷移は、スクリプトレイヤ３０２からのメソッド３１３で発生し、プレーヤ３００自身及びコマンド３１１では発生しない。プレーヤ３００の状態数が少なく状態遷移の条件が明快なので、インタラクティブなコンテンツの制作や機器への実装が容易である。

Description

明 細 書
再生装置、 再生方法および再生プログラム、 記録媒体、 ならびに、 データ構造体 技術分野
この発明は、 大容量の記録媒体に記録されたプログラムの再生制御 を容易に行うことができるようにした再生装置、 再生方法および再生 プログラム、 記録媒体、 ならびに、 データ構造体に関する。 背景技術
ランダムアクセスおよび着脱が可能な記録媒体として、 D VD (Dig ital Versatile Disc)が出現して久しいが、 近年では、 この DVDよ りも大容量のディスク状記録媒体や、 DVDより携帯に便利な小型の ディスク状記録媒体の開発が進められている。
DVDに対してビデオコンテンツを記録するための規格として、 D VDビデオ（DVD-Video)が規定されている。 D VDビデオにおいては 、 ディスク再生中の DVDプレーヤは、 様々な状態を取り得る。 DV Dビデオでは、 この DVDプレーヤの取り得る状態をドメインと呼ば れる 5種類の状態に分類し、 DVDプレーヤは、 様々な条件によって ドメインの間を遷移するというモデルが適用されていた。 すなわち、 D VDドメインは、 5個の可能な値を持つ状態変数の一種と考えるこ とができる。 DVDプレーヤは、 現在ディスクから読み取り中のコン テンッの種類を把握するために、 この状態変数を監視する。
D VDビデオでは、 次の 5種類のドメインが定義されている。
( 1 ) ファーストプレイ ドメイン（FP—D0M)
(2) ビデオマネージャメニュードメイン（VMGM_D0M) (3) ビデオタイ トルセッ トメニュードメイン（VTSM_D0M)
(4) タイ トルドメイン（TT_D0M)
( 5) 停止状態
なお、 （5) の停止状態は、 実際にはドメインではない。
( 1 ) の、 ファーストプレイ ドメインは、 ディスク最初のセクショ ンを意味し、 DVDプレーヤにおいて再生の準備状態を示す。 非再生 コマンドが有効とされる。 （2) の、 ビデオマネージャメニュードメ ィンは、 ディスク全体またはディスク面のメインメニューを意味し、 タイ トルメニューの表示を示す。 メニューに関係するコマンドが有効 とされる。 （3) の、 ビデオタイ トルセッ トメニュードメインは、 タ ィ トルまたはタイ トルのグループのメニュー、 あるいは、 サブメニュ ― (サブピクチャ、 言語、 オーディオまたはアングル） を意味し、 ル 一トメニューまたはサブメニューの何れかの表示を示す。 （4) の、 タイ トルドメインは、 タイ トル内のビデオコンテンツを意味し、 再生 コマンドが有効とされる。 また、 （5) の停止状態は、 ヘッドがディ スク再生から離れて元の位置に戻っている状態を意味し、 再生コマン ドが有効とされる。
DVDプレーヤの動作を制御するナビゲ一ションコマンドは、 現在 の状態に適用されるドメインによって制限される。 例えば、 メニュー から所定の項目を選択する 「選択ポタン」 コマンドは、 メニューが表 示されている場合に限り、 意味がある。 すなわち、 「選択ボタン」 コ マンドは、 上述の （2) のビデオマネージャメニュードメインまたは (3) のビデオタイ トルセッ トメニュードメインの何れかの状態の場 合に、 意味をなすコマンドとされる。 また例えば、 通常の 1倍速より 高速にビデオ再生を指示する 「早送り」 コマンドは、 プレーヤが停止 していたり、 静止画像で構成されるメニュー画面の表示中は、 意味を なさない。 すなわち、 「早送.り」 コマンドは、 タイ トルドメインにお いて、 意味をなすコマンドとされる。
このような D V Dビデオにおけるドメインについては、 例えば非特 許文献 1 「； i im Tay l or, D V D解体新書， 初版， ネクサスインターコ ム有限会社， 2 0 0 3年 6月 7日， p 2 7 1」 に記載されている。 このような従来の D V Dビデオにおいては、 上述したように、 ドメ インの種類が多く、 ドメイン間の状態遷移の条件も細かいため、 D V Dプレーヤに対する実装が難しいという問題点があった。
また、 ドメイン間遷移を十分に理解しないとディスク制作ができず 、 コンテンツ制作者側にとっても、 ディスクが作りにくい要因の一つ になっていたという問題点があった。 すなわち、 'ドメインの種類が多 く、 また、 ドメイン間遷移の条件が細かいため、 ドメイン間遷移を完 全に把握することが難しく、 特に複雑な構成のディスクを制作する際 に、 制作者側に多大な負担がかかっていた。
さらに、 ドメインの名称と実際の運用の方法とが必ずしも一致せず 、 ドメインの存在意義に必然性が乏しい面があった。 これは、 上述の ドメインの種類が多いと共に、 ドメイン間遷移の条件が細かいことと 相まって、 ディスク制作者側にディスク制作の負担を増加させる要因 となるという問題点があった。
例えば、 D V Dビデオでは、 上述のように、 タイ トルドメインと 2 種類のメニュードメイン （ビデオマネージャメニュードメインおよび ビデオタイ トルセッ トメニュードメイン） とが定義されている。 本来 は、 タイ トルドメイン中で、 D V Dに収録される主たるコンテンツ （ 例えば映画本編） が再生されるべきであるが、 実際には、 メニュード メイン中で映画本編を再生しても、 問題は生じない。 ドメイン間遷移 を発生させるコマンドには違いがあるが、 一旦これらのドメインに状 態遷移してしまえば、 メニュードメインおよびタイ トルドメインに、 プレーヤ動作としての差異が無い。 これは、 メニュードメインでのメ ニュー再生およびタイ トルドメィンでの映画本編の再生共、 コンテン ッデータとそれに関連する再生制御プログラムをひとまとまりとした P G C (プログラムチェイン） と呼ばれる共通の論理構造で実現して いる。
このことは、 却って自由なコンテンツ制作に制約を加えることにな ることがあるという問題点があった。 すなわち、 あるコンテンツがメ ニューであるか、 タイ トルであるかは、 ディスク制作者側の主観に依 存するものである。 例えば、 本編の再生中に分岐がある場合に、 分岐 の何れかを選択するための選択ボタンが表示されるような、 インタラ クティブ性を取り入れたコンテンツを考える。 この場合、 従来の D V Dビデオの方法では、 この選択ボタンが表示されるコンテンツをメニ ユードメインおよびタイ トルドメインの何れで再生すべきなのかが曖 昧である。 そのため、 例えば、 このコンテンツの後にさらにインタラ クティブ性を有するコンテンツを用意したい場合などに、 状態遷移の 予測が立て辛くなり、 動作の検証などが難しくなるおそれがあった。 発明の開示
したがって、 この発明の目的は、 プレーヤ動作の状態遷移を明確に 定義し、 イン夕ラクティブなコンテンツの制作を容易とするような再 生装置、 再生方法および再生プログラム、 記録媒体、 ならびに、 デー 夕構造体を提供することにある。
上述した課題を解決するために、 請求の範囲 1に記載の発明は、 記 録媒体に記録されたコンテンツデータを再生する再生装置において、 少なくともビデオストリームおよびオーディオストリームのうち何れ か一方を含むコンテンツデータと、 コンテンツデ一夕の再生を制御す る再生制御プログラムとが記録された記録媒体からデータを読み出す 読み出し手段と、 再生制御プログラムに従いコンテンツデータを再生 するプレーヤ手段と、 プレーヤ手段に対してユーザ操作に応じた制御 コマンドを与える制御コマンド出力手段とを備え、 プレーヤ手段は、 コンテンツデータを再生しているか否かで分類される 2状態と、 制御 コマンド出力手段からの制御コマンドを受け付けるか否かで分類され る 2状態との組み合わせにより定義される 4状態に基づきコンテンツ デ一夕の再生を制御するようにしたことを特徴とする再生装置である 。
また、 請求の範囲 1 2に記載の発明は、 記録媒体に記録されたコン テンッデータを再生する再生方法において、 少なくともビデオストリ ームおよびオーディオストリームのうち何れか一方を含むコンテンツ デ一夕と、 コンテンッデ一夕の再生を制御する再生制御プログラムと が記録された記録媒体から読み出された再生制御プログラムに従いプ レーャ手段でなされるコンテンツデータの再生を、 プレーヤ手段の、 コンテンッデ一夕を再生しているか否かで分類される 2状態と、 ユー ザ操作に応じた制御コマンドを受け付けるか否かで分類される 2状態 との組み合わせにより定義される 4状態に基づき制御するようにした ことを特徴とする再生方法である。
また、 請求の範囲 1 3に記載の発明は、 記録媒体に記録されたコン テンッデ一夕を再生する再生方法をコンピュータ装置に実行させる再 生プログラムにおいて、 再生方法は、 少なくともビデオストリームお よびオーディオストリームのうち何れか一方を含むコンテンツデータ と、 コンテンツデータの再生を制御する再生制御プログラムとが記録 された記録媒体から読み出された再生制御プログラムに従いプレーヤ 手段でなされるコンテンツデータの再生を、 プレーヤ手段の、 コンテ ンッデ一夕を再生しているか否かで分類される 2状態と、 ユーザ操作 に応じた制御コマンドを受け付けるか否かで分類される 2状態との組 み合わせにより定義される 4状態に基づき制御するようにしたことを 特徴とする再生プログラムである。
また、 請求の範囲 1 4に記載の発明は、 記録媒体に記録されたコン テンッデータを再生する再生方法をコンピュータ装置に実行させる再 生プログラムが記録されたコンピュータ装置に読み取り可能な記録媒 体において、 再生方法は、 少なくともビデオストリームおよびオーデ ィォストリームのうち何れか一方を含むコンテンツデータと、 コンテ ンッデ一夕の再生を制御する再生制御プログラムとが記録された記録 媒体から読み出された再生制御プログラムに従いプレーヤ手段でなさ れるコンテンツデータの再生を、 プレーヤ手段の、 コンテンツデ一夕 を再生しているか否かで分類される 2状態と、 ユーザ操作に応じた制 御コマンドを受け付けるか否かで分類される 2状態との組み合わせに より定義される 4状態に基づき制御するようにしたことを特徴とする コンピュータ装置に読み取り可能な記録媒体である。
また、 請求の範囲 1 5に記載の発明は、 少なくともビデオストリー ムおよびオーディォストリームのうち何れか一方を含むコンテンッデ 一夕と、 コンテンツデータの再生をプレーヤ手段に制御させる再生制 御プログラムとが記録された、 コンピュータ装置に読み取り可能な記 録媒体であって、 再生制御プログラムは、 コンテンツデ一夕を再生し ているか否かで分類される 2状態と、 ユーザ操作に応じた制御コマン ドを受け付けるか否かで分類される 2状態との組み合わせにより定義 される 4状態に基づきコンテンツデータの再生を制御するプレーヤ手 段に対して再生制御命令を与えてコンテンツの再生を制御させるよう にしたことを特徴とするコンピュータ装置に読み取り可能な記録媒体 である。
また、 請求の範囲 1 8に記載の発明は、 少なくともビデオストリ ムおよびォ一 ィォストリームのうち何れか一方を含むコンテンツデ 一夕と、 コンテンツデータの再生をプレーヤ手段に制御させる再生制 御プログラムとを含むデータ構造体であって、 再生制御プログラムは 、 コンテンツデータを再生しているか否かで分類される 2状態と、 ュ 一ザ操作に応じた制御コマンドを受け付けるか否かで分類される 2状 態との組み合わせにより定義される 4状態に基づきコンテンツデータ の再生を制御するプレーヤ手段に対して再生制御命令を与えてコンテ ンッの再生を制御させることを特徴とするデータ構造体である。 また、 請求の範囲 1 9に記載の発明は、 記録媒体に記録されたコン テンッデ一夕を再生する再生装置において、 少なくともビデオストリ —ムおよびオーディォストリームのうち何れか一方を含むコンテンツ デ一夕と、 コンテンツデータの再生を制御する再生制御プログラムと が記録された記録媒体からデータを読み出す読み出し部と、 再生制御 プログラムに従いコンテンツデータを再生するプレーヤ部と、 プレー ャ部に対してユーザ操作に応じた制御コマンドを与える制御コマンド 出力部とを備え、 プレーヤ部は、 コンテンツデ一夕を再生しているか 否かで分類される 2状態と、 制御コマンド出力部からの制御コマンド を受け付けるか否かで分類される 2状態との組み合わせにより定義さ れる 4状態に基づきコンテンツデータの再生を制御するようにしたこ とを特徴とする再生装置である。
上述したように、 請求の範囲 1 、 1 2、 1 3、 1 4および 1 9に記 載の発明は、 少なくともビデオストリームおよびオーディオストリー ムのうち何れか一方を含むコンテンッデ一夕と、 コンテンツデータの 再生を制御する再生制御プログラムとが記録された記録媒体から読み 出された再生制御プログラムに従いプレーヤ手段でなされるコンテ ッデ一夕の再生を、 プレーヤ手段の、 コンテンツデータを再生してい るか否かで分類される 2状態と、 ユーザ操作に応じた制御コマンドを 受け付けるか否かで分類される 2状態との組み合わせにより定義され る 4状態に基づき制御するようにしているため、 プレーヤ手段の状態 の数が少なく状態遷移の際の動作が理解し易くなり、 プレーヤ手段の 実装が容易になると共に、 コンテンッ制作の負担が軽減される。 また、 請求の範囲 1 5に記載の発明は、 少なくともビデオストリー ムおよびオーディォストリームのうち何れか一方を含むコンテンツデ 一夕と、 コンテンッデータの再生をプレーヤ手段に制御させる再生制 御プログラムとが記録された、 コンピュータ装置に読み取り可能な記 録媒体であって、 再生制御プログラムは、 コンテンツデータを再生し ているか否かで分類される 2状態と、 ユーザ操作に応じた制御コマン ドを受け付けるか否かで分類される 2状態との組み合わせにより定義 される 4状態に基づきコンテンツデータの再生を制御するプレーヤ手 段に対して再生制御命令を与えてコンテンツの再生を制御させるよう にしているため、 複雑な制御を要するコンテンツでも容易に制作する ことができる。
また、 請求の範囲 1 8に記載の発明は、 少なくともビデオストリー ムおよびオーディォストリームのうち何れか一方を含むコンテンツデ 一夕と、 コンテンッデ一夕の再生をプレーヤ手段に制御させる再生制 御プログラムとを含むデータ構造体であって、 再生制御プログラムは 、 コンテンツデータを再生しているか否かで分類される 2状態と、 ュ —ザ操作に応じた制御コマンドを受け付けるか否かで分類される 2状 態との組み合わせにより定義される 4状態に基づきコンテンツデータ の再生を制御するプレーヤ手段に対して再生制御命令を与えてコンテ ンッの再生を制御させるようにしているため、 複雑な制御を要する ンテンッでも容易に制作することができ、 データ構造として提供でき る。
この発明は、 プレイリストを再生するムービープレーヤの状態とし て、 プレイリスト再生の観点からストップ状態およびプレイ状態の 2 状態を定義すると共に、 スクリプトプログラムを介さない、 ユーザ操 作に応じた制御コマンドを受け付けるか否かで、 ノーマルモードおよ びメニューモードの 2状態を定義し、 これら 4状態間の状態遷移でプ レイリストの再生を制御するようにしている。 そのため、 A Vストリ ームの再生をスクリブトプログラムから制御できるようになるという 効果がある。
また、 ムービープレーヤの状態の数が少なく、 状態の定義も明快な ため、 状態遷移が発生する条件や状態遷移が発生するときの動作が理 解し易く、 A Vストリームの再生を行うプレーヤの実装が容易になる という効果がある。
さらに、 ムービープレーヤの状態の数が少なく、 状態の定義が明快 であることから、 状態遷移が発生する条件や状態遷移が発生するとき の動作が理解し易いため、 コンテンツ制作者側にとっても、 インタラ クティブ性を有するコンテンツ制作をより容易に行うことができるよ うになるという効果がある。 図面の簡単な説明
第 1図は、 U M Dビデオ規格のレイヤ構成を示す略線図、 第 2図は 、 この発明の実施の一形態による一例のプレーヤモデルを模式的に示 す略線図、 第 3図は、 ムービープレーヤの一例の内部構成を示す略線 図、 第 4図は、 ムービープレーヤのプレイ状態およびストップ状態を 説明するための図、 第 5図は、 この発明の実施の一形態によるムー —プレーヤのイベントモデルを模式的に示す模式図、 第 6図は、 プレ ィリス卜の再生中に発生する一例のイベントを示す略線図、 第 7図 A および第 7図 Bは、 ムービープレーヤオブジェク小が有する一例のプ 口パティを一覧して示す略線図、 第 8図は、 ムービープレーヤォブジ ェクトが有する一例のメソッドを一覧して示す略線図、 第 9図は、 ュ 一ザ入力による一例のキー入力を示す略線図、 第 1 0図は、 ユーザ入 力による一例のキー入力を示す略線図、 第 1 1図 A、 第 1 1図 Bおよ び第 1 1図 Cは、 キー入力に応じた一例の制御コマンドを示す略線図 、 第 1 2図は、 キー入力に対応する一例のイベントを示す略線図、 第 1 3図は、 一例のイベントハンドラを示す略線図、 第 14図は、 一例 のイベントハンドラを示す略線図、 第 1 5図は、 ユーザ入力イベント をきつかけとして、 用意されたプログラムが実行される一例の処理を 示すフローチャート、 第 1 6図は、 スクリプトプログラムの例につい て説明するための図、 第 1 7図は、 一例のスクリプトプログラムを示 す略線図、 第 1 8図は、 UMDビデオ規格に適用されるファイルの一 例の管理構造を示す略線図、 第 1 9図は、 ファイル" PLAYLIST.DAT"の 全体構造を表す一例のシンタクスを示す略線図、 第 20図は、 ブロッ ク PlayltemOの一例の内部構造を示す略線図、 第 2 1図は、 ブロック PlayListMarkOの一例の内部構造を示す略線図、 第 22図は、 ブロッ ク MarkO内のフィールド mark— typeについて説明するための図、 第 2 3図は、 クリップ AVストリームファイル内でのマーク時刻の指定に ついて説明するための図、 第 24図は、 クリップ A Vストリームファ ィル" XXXXX.CLP"の全体構造を表す一例のシンタクスを示す略線図、 第 2 5図は、 ブロック StreamlnioOのエレメン夕リストリームに対す る関連付けを説明するための図、 第 2 6図は、 ブロック StaticInfoO の一例の内部構造を示す略線図、 第 2 7図は、 ブロック Dynamiclnf(i( )の一例の内部構造を示す略線図、 第 2 8図は、 ブロック EP_map()の 一例の内部構造を示す略線図、 第 2 9図は、 この発明を適用可能な ディスク再生装置の一例の構成を概略的に示すブロック図、 第 3 0図 Aおよび第 3 0図 Bは、 ディスク再生装置における動作をより詳細に 説明するための機能ブロック図、 第 3 1図は、 この発明によるムービ —プレーヤの状態の定義を概念的に示す略線図、 第 3 2図は、 現在の 状態と、 メソッドによって状態遷移した後の状態を、 ムービープレー ャの 4状態のそれぞれについて組み合わせて示す略線図、 第 3 3図 A 、 第 3 3図 B、 第 3 3図 C、 第 3 3図 Dおよび第 3 3図 Eは、 メソッ ド playOを実行した際のムービープレーヤの状態遷移の例について説 明する略線図、 第 34図は、 プレイアイテムの再生方法を説明するた めの略線図、 第 3 5図は、 プレイリストの再生中にプレイリストの始 点、 終点に到達したときのムービープレーヤの一例の動作を示す略線 図、 第 3 6図は、 プレイリスト間の再生を説明するための略線図、 第 3 7図は、 プレイリストの最後におけるスクリブトレイヤでの処理の 流れと、 ムービープレーヤの動作の一例をより詳細に示すフローチヤ ート、 第 3 8図は、 UMDビデオプレーヤが備える 3種類のメモリ領 域について説明するための略線図、 第 3 9図は、 プレーヤステータス のバックアップについて説明するための略線図、 第 40図は、 プレー ャステータスのバックアップについて説明するための略線図、 第 4 1 図は、 リジュームインフォメーションのリストアと、 破棄について説 明するための略線図、 第 42図は、 リジュームインフォメーションの リストアと、 破棄について説明するための略線図、 第 43図は、 リジ ュ一ムインフォメーションのリストアと、 破棄について説明するため の略線図、 第 44図は、 リジュームインフォメーションのリストアと 、 破棄について説明するための略線図、 第 45図は、 メソッ ド stopO の引数 resumelnfoClearFlagを用いた UMDビデオプレーヤの一例の' 動作を示す略線図、 第 46図は、 プレーヤステータスの一例のライフ サイクルを示す略線図、 第 47図 Aおよび第 47図 Bは、 リジューム インフォメ一ションの一例のライフサイクルを示す略線図、 第 48図 は、 ユーザデ一夕の一例のライフサイクルを示す略線図である。 発明を実施するための最良の形態
以下、 この発明の実施の一形態について、 下記の順序に従い説明す る。
1. UMDビデオ規格について
2. UMDビデオ規格のプレーヤモデルについて
3. ムービープレーヤのイベントモデルについて
4. ムービープレーヤオブジェクトについて
5. スクリプトプログラムの例
6. ファイルの管理構造について
7. ディスク再生装置について
8. ム一ビープレーヤの状態遷移モデルについて
8— 1. ムービープレーヤの状態の定義について
8 - 2. ムービープレーヤに状態遷移を発生させるメソッドについ て
8— 3. プレイリス卜再生中のムービープレーヤの動作について 8 -4. ムービープレーヤの再生復帰機能について
8— 5. 各データのライフサイクルについて
1. UMDビデオ規格について 先ず、 理解を容易とするために、 この実施の一形態に適用可能なシ ステムについて概略的に説明する。 この発明の実施の一形態では、 E CMAスクリブトと呼ばれるスクリプト言語を用いてプレーヤモデル を記述している。 ECMAスクリプトは、 E CMA (European Comput er Manufacturers Association)により疋められた、 J a v a S c r i p t (登録商標） に基づいたクロスプラッ トフォーム用のスクリブ ト言語である。 ECMAスクリプトは、 HTML文書との親和性が高 いことと、 独自のオブジェクトの定義が可能であるため、 この発明に よるプレーヤモデルに用いて好適である。
すなわち、 従来からの DVDビデオでは、 インダラクティブな機能 を実現するための制御プログラムを記述するために、 D V Dビデオ規 格で定義された汎用的ではないコマンドを用いていた。 制御プロダラ ムは、 複数のファイルやデータファイルの中の複数の箇所、 さらには 、 AVストリームファイル中に分散されて埋め込むようにされ、 埋め 込まれた制御プログラムが実行される条件や順序は、 DVD規格で決 められていた。
このような DVDビデオのシステムでは、 汎用的なコンテンツ制作 システムを構築することが難しく、 そのため、 予め決められた脚本に 当てはめてスト一リーを作る、 テンプレートを用いたコンテンツ制作 を行っていた。 そして、 テンプレートでは対応できない、 複雑なコン テンッを制作する場合には、 先ず、 コンテンツ制作システムそのもの をカスタムメイ ドで作成していた。 この発明の実施の一形態では、 A Vコンテンツを制御するために、 汎用的で拡張性の高いスクリブト言 語である ECMAスクリプトを用いることで、 このような問題を解決 している。
以下では、 この E CMAスクリプトを元にしたスクリブト言語を用 いた、 この発明の実施の一形態に基づく規格を、 UMD (Universal M edia Disc：登録商標）ビデオ規格と呼ぶ。 また、 UMDビデオ規格 うち、 特にスクリプ卜に関する部分を UMDビデオスクリブト規格と 呼ぶ。
UMDビデオ規格について、 概略的に説明する。 第 1図は、 UMD ビデオ規格のレイヤ構成を示す。 UMDビデオ規格では、 スクリプト レイヤ、 プレイリストレイヤおよびクリップレイヤの 3層のレイヤ構 造が定義され、 この構造に基づきストリーム管理がなされる。
UMDビデオ規格においては、 ディジタル符号化されたビデオ、 ォ —ディォおよび字幕を、 M P E G 2 (Moving Pictures Experts Group 2)のバケツタイズドエレメン夕リストリームとして多重化した M P EG 2ストリームとして扱う。 このビデオ、 オーディオおよび字幕の エレメン夕リストリームが多重化された MP E G 2ストリームを、 ク リップ A Vストリーム（Clip AV Stream)と呼ぶ。 クリップ AVストリ —ムは、 クリップ A Vストリームファイルに格納される。 クリップ A Vストリ一ムファイルの記録時に、 当該クリップ AVストリームファ ィルに 1対 1に対応して、 クリップインフォメーションファイル（Cli p Information File)が同時に作成される。 これらクリップインフォ メ一シヨンファイルと、 対応するクリップ AVストリームファイルと からなる組を、 クリップ（Clip)と呼ぶ。
クリップは、 ディスクへの記録の単位ともいうべきものであり、 再 生時にどのような順序でクリップを再生するかは、 クリップの上位の レイヤであるプレイリス卜レイヤで管理する。 プレイリストレイヤは 、 クリップの再生経路を指定するレイヤであり、 1または複数のプレ イリスト（PlayList)を含む。 プレイリストは、 プレイアイテムの（Pla yltem)の集合からなる。 プレイアイテムには、 クリップの再生範囲を 示した一組のイン（I n)点およびァゥト（Ou t)点が含まれており、 プレ ィアイテムを連ねることによって、 任意の順序でクリップを再生する ことができるようになる。 プレイアイテムは、 クリップを重複して指 定することができる。 クリップ A Vストリームファイルのィン点およ びアウト点は、 タイムスタンプ （クリップ内時刻） で指定され、 タイ ムスタンプは、 クリップインフォメ一ションファイルの情報によって クリップ A Vストリーム上のバイ ト位置に変換される。
プレイリストは、 クリップの全部または一部を指すプレイアイテム を順序に従って再生していく構造だけを有しており、 プレイリストの みを用いて再生順の分岐や、 ユーザとの双方向性を実現することは、 できない。 この発明の実施の一形態では、 複数のプレイリストが 1つ のフアイル" PLAYL I ST. DAT"にまとめられている。
スクリブトレイヤは、 言語仕様の E C M Aスクリブトを拡張した、 U M Dビデオスクリブトによって構築されるレイヤである。 U M Dビ デォスクリプトは、 E C M Aスクリプトを基本として、 U M Dビデオ に特有な機能を実現するための拡張を加えたスクリブトである。 スクリブトレイヤは、 プレイリストレイヤの上位のレイヤであり、 プレイリス卜の再生指示や、 プレーヤ設定を行うコマンド列から構成 される。 スクリプトレイヤのコマンドにより、 複数の言語用に用意さ れたストリームのうち何れを選択する、 ある条件に従って選択される プレイリストに再生の流れが変化する、 というような、 条件分岐を伴 うプレイリス卜再生を実現することができる。 このような条件分岐を 伴うプレイリスト再生が用いられるアプリケーションの例としては、 マルチストーリが挙げられる。 このスクリプトレイヤにより、 ユーザ との双方向性機能 （インタラクティブ機能） が導入されることになる なお、 この発明の実施の一形態では、 スクリプトレイヤは、 リソー スファイルと呼ばれるファイルにより構成される。 リソ一スフアイ)レ は、 実際の E C M Aスクリブトに基づき記述されるスクリプトデータ (スクリプトプログラム） 、 ポタン操作の際の効果音などを出力する ためのサウンドデータ、 メニュー画面の背景画像などに用いる画像デ —夕からなるスクリーンデザィン、 ならびに、 ボタン画像などの G U I部品を表示させるための画像データ （ビッ トマップデータ） が含ま れる。
リソースファイルは、 複数、 存在することができる。 また、 この実 施の一形態においては、 リソースファイルは、 所定の命名規則に従い ファイル名が与えられ、 例えば、 ファイル名の拡張子 「RC0」 により 当該ファイルがリソースファイルであることが示される。
2 . U M Dビデオ規格のプレーヤモデルについて
次に、 U M Dビデオ規格に従ったデータを再生する再生装置 （プレ —ャ） のモデル、 すなわち、 プレーヤモデルについて説明する。 プレ —ャは、 先ず、 ディスクからリソースファイル、 プレイリストフィル およびクリップインフォメーションファイルを読み出し、 次に、 これ らにより定められている再生順序に従って、 クリップ A Vストリーム ファイルを読み出レ、 ビデオ、 オーディオおよび字幕などを再生する 。
スクリプトプログラムの言語仕様においては、 プレイリス卜を再生 する機能ブロックを、 スクリプトプログラム内のオブジェクトとして 実装する。 このプレイリスト再生を行うオブジェク トを、 U M Dビデ ォ規格では、 ムービープレーヤ（Mov i e P l ayer)オブジェク トと呼ぶ。 プレイリストの再生指示や、 プレーヤ設定を行うコマンドは、 このム 一ピープレーヤオブジェク卜が有するメソッ ドとなる。 ムービープレ ーャォブジェク卜は、 スクリプトレイヤからのメソッドによって制御 される。 このとき、 ムービープレーヤオブジェクトからスクリプトレ ィャに対して、 状態の変化や再生位置などを通知する機能が必要とな る。 これは、 ムービープレーヤオブジェクトがスクリプトプログラム に対してイベントを発することに対応し、 そのイベントに対応した処 理は、 イベントハンドラとして記述される。
このように、 ムービープレーヤオブジェクトからスクリプトプログ ラムへの情報伝達は、 イベントにより行い、 スクリプトプログラムか らムービープレーヤオブジェクトに対する制御をメソッドにより行う モデルを構築することにより、 クリップ A Vストリームの再生をスク リプトプログラムで制御できるようになる。
第 2図は、 上述した、 この発明の実施の一形態による一例のプレー ャモデルを模式的に示す。 ム一ビ一プレーヤ 3 0 0は、 U M Dビデオ 規格においてビデオ、 オーディォおよび字幕の再生を司るモジュール である。 上述したムービープレーヤオブジェクトは、 ムービーォブジ ェクトをスクリブトプログラムから操作するためにスクリプトプログ ラム内のオブジェクトとしたものである。 換言すれば、 ムービープレ ーャォブジェクトは、 ムービープレーヤの機能を実現する実装モジュ —ルを抽象化してスクリブトプログラム上で扱える形にしたものであ る。
なお、 ムービープレーヤ 3 0 0とムービープレーヤオブジェク卜は 、 実質的に同一の対象を表すと考えられるので、 以下、 これらを同一 の符号を付して説明する。
第 2図において、 ムービープレーヤ 3 0 0は、 ユーザ入力 3 1 0な どにより引き起こされる下位レイヤ （第 2図の例ではネイティブ実装 プラットフォーム 3 0 1 ) や、 上位レイヤであるスクリプトレイヤ 3 02からのメソッドに従って、 プレイリストおよびクリップインフォ メーションのデータベースに基づき、 クリップ A Vストリームフア ルの読み出し、 読み出されたクリップ AVストリームのデコードおよ び表示を行う。
ムービープレーヤオブジェクト 300の内部は、 UMDビデオを再 生する UMDビデオプレーヤの実装に依存するものであって、 スクリ ブトレイヤ 30.2からは、 ブラックボックス化されたオブジェクトと して、 メソッドゃプロパティといった AP I (Application Programmi ng Interface)が提供される。 ここで、 UMDビデオプレーヤ（UMD Vi deo Player)は、 ムービープレーヤを実装した実際の機器を指す。 全 ての UMDビデオプレーヤは、 UMDビデオ規格の制約を守ってムー ビープレーヤを実装しており、 再生互換を有する。
第 2図に示されるように、 ムービープレーヤオブジェクト 300は 、 ネィティブ実装プラッ トフオーム 30 1からの制御コマンド 3 1 1 を受け付けるパス、 スクリプトレイヤ 302に対してイベント 3 1 2 を通知するパス、 スクリプトレイヤ 302からのメソッド 3 1 3を受 け付けるパスの、 3本の入出力パスを有する。
制御コマンド 3 1 1は、 ネィティブ実装のプラッ トフオーム 30 1 からの、 ムービープレーヤオブジェクト 300の動作を制御するコマ ンドである。 ネイティブ実装プラットフォーム 30 1は、 例えば、 実 際の機器としての UMDビデオプレーヤにおける、 機器に固有の部分 とムービープレーヤ 300とのインターフェイスである。 イベント 3 1 2は、 ムービープレーヤ 300からスクリプトレイヤ 302に対す るスクリプトイベントである。 メソッド 3 1 3は、 スクリプトレイヤ 302のスクリブトプログラムからムービープレーヤ 300に指示さ れるメソッドである。 ムービープレーヤオブジェク ト 3 0 0は、 内部に、 U M Dビデオ規 格のプレイリス卜およびクリップィンフオメーションのデータべ一 3 2 0を有する。 ムービープレーヤオブジェク ト 3 0 0は、 このデ^" 夕ベース 3 2 0を用いて、 ユーザ入力 3 1 0に対する無効化（mask)や 、 時刻で指定された再生位置をクリップ A Vス卜リーム内のバイ ト位 置に変換する処理などを行う。
ムービープレーヤオブジェク卜 3 0 0内のプレイバックモジュール 3 2 1は、 ビデオ、 オーディオおよび字幕が多重された M P E G 2 P S (Program S t ream)であるクリップ A Vストリームのデコ一ドを行 う。 プレイバックモジュール 3 2 1は、 プレイおよびストップの 2状 態を持ち、 制御命令やメソッドによって、 この 2状態の間を遷移する (第 3図参照） 。 なお、 クリップ A Vストリームは、 M P E G 2 P Sに限られない。 例えば、 クリップ A Vストリームとして M P E G 2 T S (Transpor t S t ream)を用いても、 モデル上は同様に扱うことが できる。
スクリプトレイヤ 3 0 2は、 U M Dビデオスクリプト規格に基づく スクリプトプログラムを実行し、 ムービープレーヤオブジェクト 3 0 0の制御や、 画面表示を行うレイヤである。 このスクリプトレイヤ 3 0 2は、 コンテンツ制作者側の意図したシナリオを実現する役割を果 たす。 スクリプトレイヤ 3 0 2は、 ムービープレーヤオブジェクト 3 0 0に対してメソッド 3 1 3を発行し、 ムービープレーヤオブジェク ト 3 0 0からは、 イベント 3 1 2を受け取る。 スクリプトレイヤ 3 0 2は、 ネイティブ実装プラッ トフォーム 3 0 1との間で、 ユーザ入力 3 1 0に応じたキ Γベン卜 3 1 4や、 画面描画などをネィティブ実 装ブラッ トフォーム 3 0 1に対して指示するメソッ ド 3 1 5などのや りとりを行う。 なお、 ネイティブ実装プラットフォーム 3 0 1は、 U M Dビデオ規 格で規定した以外の様々な機能を有する。 この発明の実施の一形態 + は、 スクリプトレイヤ 3 0 2からネイティブ実装プラッ トフオーム 3 0 1に働きかけるメッツ ド 3 1 5が存在するため、 ネィティブ実装プ ラッ トフオーム 3 0 1にも、 機能を抽象化したオブジェク トを定義し 、 メソッ ド 3 1 5は、 スクリプトプログラム上では、 このオブジェク トに属するものと見なす。 これは、 メソッドは、 オブジェクトに属す るからである。 そこで、 ネイティブ実装プラットフォーム 3 0 1内に コント口一ラオブジェクト 3 3 0を定義し、 メソッド 3 1 5は、 コン トローラオブジェク ト 3 3 0のメソッドであると定める。
例えば、 メニュー画面上に配置されるポタンは、 スクリプトレイヤ 3 0 2のスクリブトプログラムからネィティブ実装プラッ トフオーム 3 0 1に渡されるメソッド 3 1 5に基づき、 ネィティブ実装プラット フォーム 3 0 1により描画される。 ユーザがそのポタンに対して選択 や決定などの操作を行ったときには、 ユーザ入力 3 1 0に応じたキ一 イベント 3 1 4がネィティブ実装プラッ トフオーム 3 0 1からスクリ ブトレイヤ 3 0 2に通知され、 スクリプトレイヤ 3 0 2内のスクリブ トプログラムは、 キ Γベント 3 1 4に基づきキー入力 3 1 0に応じ た処理を行う。
このように、 ビデオ、 オーディオおよび字幕のデコードや表示制御 はムービープレーヤ 3 0 0が司り、 ポタンなどの G U I (Graph i ca l U ser I n t er f ace)を構成するための部品画像 （以下、 G U I部品と呼ぶ ) の配置や表示、 ならびに、 G U I部品に対して選択や決定などの操 作がなされたときの処理は、 スクリプトレイヤ 3 0 2が行うというよ うに、 役割分担がなされている。
ネィティブ実装プラッ トフオーム 3 0 1は、 ムービープレーヤォブ ジェク ト 3 0 0やスクリブトプログラムが動作するための基盤となる プラッ トフォームであって、 例えば、 実際の U M Dビデオプレーヤ'が ハードウエアである場合、 ハ一ドウエアとプレーヤモデルとの間の処 理を仲介する役割を果たすように、 ハードウエアに固有に実装される 0
例えば、 ネイティブ実装プラッ トフォーム 3 0 1は、 ユーザからの ユーザ入力 3 1 0を受け付け、 受け付けたユーザ入力 3 1 0がムービ 一プレーヤ 3 0 0に対する命令なのか、 スクリプトレイヤ 3 0 2で描 画および表示しているボタンに対する命令なのかを判定する。 ネィテ イブ実装プラットフォーム 3 0 1は、 ユーザ入力 3 1 0がム一ビープ レーャ 3 0 0に対する命令であると判定されれば、 ユーザ入力 3 1 0 をムービープレーヤ 3 0 0に対する内部制御命令である制御コマンド 3 1 1に変換し、 ムービープレーヤ 3 0 0に対して制御命令を発する 一方、 ネイティブ実装プラットフォーム 3 0 1は、 ユーザ入力 3 1 0がスクリプトレイヤ 3 0 2で描画および表示している G U I部品に 対する命令であると判定されれば、 ユーザ入力 3 1 0に応じたキーィ ベント 3 1 4をスクリプトレイヤ 3 0 2に通知する。 そして、 このキ 一^ Γベント 3 1 4に応じてスクリプトレイヤ 3 0 2から指示されたメ ソッド 3 1 5に基づき、 例えば画面上にボタン画像を表示させること ができる。 すなわち、 ネイティブ実装プラッ トフォーム 3 0 1とスク リプトレイヤ 3 0 2とは、 ムービープレーヤ 3 0 0を介さずに、 直接 的にイベントおよびメソッドの受け渡しを行うことができる。
また例えば、 ネイティブ実装プラットフォーム 3 0 1は、 後述する ような、 ムービープレーヤ 3 0 0のプロパティにアクセスし、 ムービ —プレーヤ 3 0 0のステータスを見ることができるようにされている 次に、 ムービープレーヤ 3 0 0についてより詳細に説明する。 第 3 図は、 ムービープレーヤ 3 0 0の一例の内部構成を示す。 上述したよ うに、 ムービープレーヤ 3 0 0は、 データベース 3 2 0およびプレイ バックモジュール 3 2 1とから構成される。 データベース 3 2 0は、 ディスクから読み取ったプレイリストの情報と、 クリップの情報すな わちクリップインフォメ一ションとを格納する領域である。
プレイバックモジュール 3 2 1は、 デコーダエンジン 3 2 2と、 プ レイバックモジュール 3 2 1の状態を表す値であるプロパティ 3 2 3 とからなる。 プロパティ 3 2 3は、 例えば言語コードのように、 ム一 ビープレーヤ 3 0 0の初期設定で値が決まるプロパティ 3 2. 3 A (リ ードオンリ一パラメ一夕） と、 プレイバックモジュール 3 2 1の状態 によって値が変化するプロパティ 3 2 3 B (プレーヤステータス） の 2種類がある。
初期設定で値が決まるプロパティ 3 2 3 Aは、 ネイティブなシステ ム、 例えば実際の機器によって値がセッ トされ、 プレイリストゃクリ ップインフォメーション、 スクリブトプログラムから値を変更される ことがない。 プロパティ 3 2 3 Aは、 スクリプトプログラムから値を 読み出すことのみが可能とされる。 一方、 プレイバックモジュール 3 2 1の状態を表すプロパティ 3 2 3 Bは、 スクリプトプログラムから 値を読み出すことができると共に、 一部のスクリブトプログラムから 値を書き込むことが可能とされる。
なお、 この動作モデルにおいては、 プレイリストおよびクリップィ ンフオメーションは、 クリップ A Vストリームの再生前にディスクか らプリロードされていることを想定している。 これに限らず、 他の実 装であっても、 ムービープレーヤモデルで定めた動作を実現できてい ればよい。
ムービープレーヤオブジェクト 3 0 0は、 スクリプトレイヤ 3 0 またはネイティブ実装プラットフオーム 3 0 1からの指示に従い、 指 定されたプレイリストを再生する。 例えば、 ムービープレーヤ 3 0 0 は、 データベース 3 2 0を参照し、 指定されたプレイリストに対応す るクリップ A Vストリームの再生位置をファイル中のバイ ト位置で得 る。 プレイバックモジュール 3 2 1において、 デコーダエンジン 3 2 2は、 この再生位置情報に基づき、 クリップ A Vストリームのデコ一 ドを制御する。
ムービープレーヤ 3 0 0は、 第 4図に示されるように、 プレイリス 卜の再生状況に応じてプレイ（p l ay)およびストップ（s t op)の 2状態を 持つ。 プレイ状態は、 プレイリストが指定され、 プレイリストの再生 を行っている状態を指す。 通常再生の他、 2倍速、 1 Z 2倍速といつ た変速再生や、 順方向早送りおよび逆方向早送り、 一時停止 （ポーズ ) といった各種の状態（s t a t us)がプレイ状態に含まれる。 再生をフレ —ム単位で進めたり戻したりする所謂コマ送り再生は、 ポーズ状態と プレイ状態とを繰り返している状態である。 ストップ状態は、 プレイ リストを再生していない状態である。 ストップ状態においては、 プレ イリストが選択されておらず、 「現在再生中のプレイリスト番号」 を 表すプレーヤステータスの値は、 不定である。
例えば、 ムービープレーヤ 3 0 0の状態は、 ムービープレーヤ 3 0 0内のデコーダエンジン 3 2 2におけるプレイおよびス卜ップの状態 遷移に伴うもので、 デコーダエンジン 3 2 2の状態遷移に応じてプロ パティ 3 2 3 Bの値が更新される。
リジュームインフォメーション 3 2 4は、 ストップ状態直前の状態 を記憶する。 例えば、 ムービープレーヤ 3 0 0があるプレイリストを デコードしプレイ状態となっているときに、 状態がストップ状態に遷 移すると、 ストップ状態の直前の状態を記憶する。 また、 リジュー インフォメーション 3 2 4は、 ハードウエアとしてのプレーヤが持つ 不揮発性メモリに、 ディスクのタイ トル毎に識別可能なように複数を 記憶させることができる。 例えば、 ディスクは、 ディスクのタイ トル 毎にユニークな識別情報 （タイ トル I Dと呼ぶ） を有し、 リジューム インフォメーション 3 2 4をこの識別情報と関連付けて記憶する。 こ うすることで、 リジュームインフォメーション 3 2 4の情報に基づき 、 識別情報が対応するタイ トルのディスクが次にストップ状態からプ レイ状態に遷移したときに、 当該ディスクの再生を、 以前ストップ状 態になった直前の位置から開始させることができる。
3 . ムービープレーヤのイベントモデルについて
ム一ビープレーヤ 3 0 0のイベントモデルについて説明する。 ムー ビ一プレーヤ 3 0 0は、 プレイリストを再生するプレイ状態で、 様々 なイベントを発生する。 このイベントは、 イベントハンドラと呼ばれ る、 スクリプトで記述された処理プログラムの実行を引き起こす。 ィ ベントハンドラは、 ィベント発生によって呼び出されるメソッドであ る。 このィベント発生によって処理プログラムの実行を開始するプロ グラム実行モデルを、 イベントドリブンモデルと呼ぶ。 イベントドリ ブンモデルでは、 不定期なイベントが発生し、 イベント発生をきつか けに用意しておいたプログラムが実行される。 この実施の一形態にお いては、 スクリプトプログラムは、 イベントハンドラ群によってムー ビープレーヤオブジェクト 3 0 0の動作を制御する。
第 5図は、 この発明の実施の一形態によるムービープレーヤ 3 0 0 のイベントモデルを模式的に示す。 第 5図において、 イベントハンド ラ onEven t A O、 onEven t B Oおよび onEven t C Oは、 インタ一フェイスで あって、 それぞれのイベントハンドラの内容は、 スクリプトで記述さ れている。 イベントハンドラの内容は、 例えばコンテンツ制作者側 作成され実装される。 UMDビデオスクリプト規格においては、 ムー ビープレーヤオブジェクト 3 0 0からスクリプトプログラムに通知さ れるイベント毎に、 イベントハンドラが用意される。 第 5図の例では 、 イベント Aが発生したときに実行される処理プログラムは、 ィベン トハンドラ onEventAOに決められている。 イベント Bおよびイベント Cについても同様に、 イベント Bの発生時には対応するイベントハン ドラ onEventBOが実行され、 イベント Cの発生時には対応するィベン トハンドラ onEventCOが実行される。
ィベント発生に応じて呼び出されるイベントハンドラは、 システム 側で選択されるため、 コンテンツ制作者側では、 どのイベントが発生 したかを判断する処理を、 スクリブトプログラム内に記述しておく必 要が無い。
第 6図は、 プレイリストの再生中に発生する一例のイベントを示す 。 プレイリスト PlayListの先頭には、 チヤプタマーク ChapterMarkが 設定されているので、 プレイリストの先頭からの再生開始時には、 先 ず、 チヤプタマークに対応したイベント Chapterが発生する。 さらに 、 チヤプ夕が変わる度にィベント Chapterがスクリプトレイヤ 3 0 2 に通知され、 対応するイベントハンドラ onChapterが実行される。 ま た、 ィベントマ一ク Even tMarkが設定されている時刻に再生が到達す ると、 対応するマークイベントが発生する。 そして、 プレイリストの 最後まで再生が到達すると、 プレイリストの最後で再生が一時停止し 、 イベント PlayListEndがムービープレーヤ 3 0 0からスクリプトレ ィャ 3 0 2に通知される。 スクリプトレイヤ 3 0 2側では、 対応する イベントハンドラ0 1& 51£11(1()内で、 別のプレイリス卜の再生開 始が指示される。 このようにして、 コンテンツ制作者が意図した順序 で、 一連のプレイリスト再生が継続されていく。 ' このように、 プレーヤの動作中にはさまざまなィベン卜が発生する ものとし、 イベント発生を上位プログラムに伝えることで、 上位プロ グラムはプレーヤの状態を把握できるようになる。 上位プログラムの 方では、 各イベント発生通知時に実行されるプログラム （イベントハ ンドラ） を用意しておくことで、 各種イベント発生に対処する。 ィべ ントおよびイベントハンドラの詳細については、 後述する。
イベントハンドラがコンテンッ制作者によって記述されていない場 合には、 規格で規定されているプレーヤ組み込みの動作 （デフォルト のイベントハンドラ） を実行するか、 あるいは、 そのイベントが無視 され何も実行されない。 何も処理を行う必要がないときには、 ィベン 卜に対応したィベントハンドラを記述しないようにすることで、 積極 的にィベントを無視することができる。
イベントモデルとしては、 上述の他に、 あるイベントに対応するリ スナをオブジェクトがプレーヤオブジェク 卜に登録し、 プレーヤォブ ジェクト内で発生したイベントが登録されたイベントであれば、 プレ ーャォブジェク卜から当該イベントを登録したオブジェクトにィベン トを送信し、 当該オブジェク 卜で対応するメソッドを実行す ように したイベントリスナのモデルや、 どのようなイベントが発生しても一 つのメソッドを呼び出すようにした単一メソッドのモデルなどが考え られる。
この実施の一形態によるイベントモデルは、 イベント登録、 ィベン ト登録削除といった処理が必要なイベントリスナのモデルよりも簡単 である。 また、 単一メソッ ドのモデルは、 どのイベントが発生したか を知り、 ィベント毎に用意してある処理ルーチンを切り替えるという 前処理を、 そのメソッドの中に記述しておく必要がある。 メソッドは
、 コンテンツ制作者側が実装するものであるから、 モデルとしては te 単でも、 コンテンツ制作者側の負担が大きくなる。 さらに、 大きな」 つの処理プログラム （メソッド） がィ'ベントの発生毎に呼ばれること になり、 メモリの領域を多く占有し、 実行速度も遅くなると考えられ る。 この発明の実施の一形態による、 イベント毎に処理プログラム （ イベントハンドラ） を用意するモデルでは、 このような点について有 利であるといえる。
4. ムービープレーヤオブジェクトについて
次に、 ムービープレーヤオブジェクト 3 0 0の外部的な仕様につい て説明する。 一般に、 E CMAスクリプト言語仕様に従う言語により 定義されたオブジェクトは、 プロパティとメソッドとを持つ。 この実 施の一形態によるムービープレーヤオブジェクト 3 0 0も、 第 2図お よび第 3図を用いて既に説明したように、 同様にしてプロパティとメ ソッドとを有する。 プロパティは、 外部のオブジェクトから、 対象と なるオブジェクト名とプロパティ名とを指定することで、 直接的に読 み書きすることが可能である。 これに限らず、 プロパティ値の設定を 行うメソッド setXXXO ( 「XXX」 は、 対象のプロパティ名） や、 プロ パティ値の読み出しを行うメソッド getXXXOを定義することで、 他の オブジェクトのプロパティの読み書きを、 メソッドで行うことが可能 となる。
第 7図 Aおよび第 7図 Bは、 ムービープレーヤオブジェクト 3 0 0 が有する一例のプロパティを一覧して示す。 これは、 第 3図における プロパティ 3 2 3に対応する。 第 7図 Aは、 第 3図におけるリ一ドォ ンリーパラメータ 3 2 3 Aに属する一例のプロパティを示す。 プロパ ティ scriptVersionは、 UMDビデオスクリプト（UMD Video Script) のバージョンを示す。 プロパティ audioChannelCapabi 1 i tyは、 UMD ビデオプレーヤが再生可能なオーディォチャンネル数を示す。 プロ λ ティ languageCodeは、 UMDビデオプレーヤに設定された、 メニュー 表示言語の言語コードを示す。 プロパティ audioLanguageCodeは、 U MDビデオプレーヤに設定された、 オーディオ言語の言語コードを示 す。 プロパティ subtitleLanguageCodeは、 UMDビデオプレーヤに設 定された、 字幕 （サブタイトル） 言語の言語コードを示す。
ディスクが装填された際には、 このリードオンリ一パラメ一夕 3 2 3 Aに設定されたプロパティ languageCodeに示される言語コードに基 づき、 ディスクから読み出すスクリプトファイルが決められる。 装填 されたディスクに、 当該言語に対応するスクリブトファイルがない場 合は、 デフォルトのスクリプトファイルが読み出される。 例えば、 複 数のスクリプトファイルのうち、 ディスク上で最も先頭側に配置され るファイルがデフォルトのスクリブトファイルとして読み出される。 第 7図 Bは、 第 3図におけるプレーヤステータス 3 2 3 Bに属する 一例のプロパティを示す。 プロパティ playListNumberは、 現在再生中 のプレイリストの番号を示す。 プロパティ chapterNumberは、 現在再 生中のチヤプ夕の番号を示す。 プロパティ videoNumberは、 現在再生 中のビデオストリームの番号を示す。 プロパティ audioNumberは、 現 在再生中のオーディオストリームの番号を示す。 プロパティ subtitle Numberは、 現在再生中の字幕ストリームの番号を示す。 プロパティ pi ayListTimeは、 プレイリスト先頭を 0としたときの時刻を示す。 プロ パティ audioFlagは、 ォ一ディォ再生の〇NZ〇 F Fおよびデュアル モノ L Rの指定を示す。 プロパティ subtitleFlagは、 字幕表示の ON ZOF Fを示す。
なお、 デュアルモノ（dual mono)は、 ステレオオーディオの左右 ( L、 R) チャンネルを、 互いに独立したモノラルオーディオチャンネ ルとして用いるモードである。
このプレーヤステータス 3 2 3 Bに属する各プロパティは、 ムーピ 一プレーヤ 3 0 0が再生または一時停止状態のときに、 これらの情報 が存在する。 停止状態に遷移した場合、 その時点でプレーヤステ一夕 ス 3 2 3 Bに属する各プロパティは、 リジユームインフォメ一ション (resumelnformation) 3 24としてバックアップされる。 このとき、 プレーヤステータス 3 2 3 Bの内容をクリアしてもよい。
第 8図は、 ムービープレーヤオブジェクト 3 0 0が有する一例のメ ソッドを一覧して示す。 これは、 第 2図におけるメソッド 3 1 3に対 応する。 メソッド play 0は、 ビデオを再生する。 メソッド playChapte r()は、 チヤプ夕を指定してビデオを再生する。 メソッド resumeOは 、 リジュームインフォメーション 3 24を用いた再生開始を行う。 メ ソッド stopOは、 ビデオの再生を停止する。 メソッド pauseOは、 ビ デォの再生を一時停止する。 メソッド playStepOは、 ビデオをコマ送 り再生する。 メソッド changeStreamOは、 ビデオストリーム、 オーデ ィォストリームおよび Zまたは字幕ストリームを変更する。 メソッド getPlayerStatusOは、 ムービープレーヤ 3 0 0における再生、 停止 、 一時停止などの状態を取得する。 メソッド changeResumelnfoOは、 リジュームインフォメーション 3 24の内容を変更する。 メソッド re set Oは、 ビデオの再生を停止し、 リジュームインフォメーション 3 24の内容をクリァする。
UMDビデオ.規格では、 表示画面上の一部分にビデオを表示するこ とができるようになつている。 以下の 4つのメソッドは、 この場合の ビデオ表示に関するメソッドである。 メソッド setPosOは、 ビデオの 表示位置を設定する。 メソッド getPosOは、 ビデオの表示位置を取得 する。 メソッド setSizeOは、 ビデオの表示サイズを設定する。 メソ ッド getSizeOは、 ビデオの表示サイズを取得する。
なお、 実際には、 ムービープレーヤ 300とネイティブ実装プラッ トフオーム 30 1とは、 一体的に構成される。 すなわち、 実際にディ スクが装填され、 これを再生するハードウェアとしての UMDプレー ャと、 UMDプレーヤを制御するソフトウエアとの関係に対応付けら れ、 どの部分をハードウェアで行い、 どの部分をソフトウェアで行う かは、.実装時の構成に依存する。 例えば、 UMDプレーヤをパ一ソナ ルコンピュータなどで構成する場合は、 ディスクドライブ以外は、 ソ フトウェア的に構成することができる。 また、 単体の UMDプレーヤ として構成する場合は、 ディスクドライブ以外に、 例えばビデオデコ ーダゃオーディォデコーダなどをハ一ドウエア的に構成することがで きる。 したがって、 ムービープレーヤ 300とネイティブ実装プラッ トフオーム 30 1との間でなされるメソッドゃコマンド、 イベントは 、 第 2図に一例が示されるような明示的なやりとりに限られない。 一方、 ユーザからのキー入力については、 第 2図を用いて既に説明 したように、 ユーザ入力 3 1 0をネイティブ実装プラットフオーム 3 0 1が先ず、 受け取る。 つまり、 ネイティブ実装プラットフォーム 3 0 1は、 ユーザからのキー入力をユーザ入力 3 1 0として受け取り、 ユーザ入力 3 1 0がムービープレーヤ 300に対するコマンドなのか 、 スクリプトレイヤ 302のスクリプトプログラムに対するィベント なのかを判定し、 判定結果に応じて、 制御コマンド 3 1 1またはキー イベント 3 14.を発生し、 対応する上位レイヤ （ムービープレーヤ 3 00またはスクリプトレイヤ 302) に通知する。
第 9図および第 1 0図は、 ユーザ入力 3 1 0による一例のキー入力 を示す。 なお、 第 9図および第 1 0図に示される 「VK」 で始まる各キ 一は、 仮想的なキー（V i r t ua l Key)であることを意味する。
第 9図は、 ムービープレーヤ 3 0 0の操作に関する一例のキー入'力 を示す。 キー VK_PLAYは、 再生を指示する再生キーに対応する機能を 提供する。 キー VK— STOPは、 再生の停止を指示する停止キーに対応す る機能を提供する。 キ一VK一 PAUSEは、 再生の一時停止を指示する一時 停止キーに対応する機能を提供する。 キー VK_FAST_FORWARDは、 早送 り再生を指示する早送りキーに対応する機能を提供する。 キ一 VK_FAS T_REVERSEは、 早戻し再生を指示する早戻しキーに対応する機能を提 供する。 キー VK_SL0W— FORWARDは、 順方向のスロー再生を指示するス ロー （順方向） キーに対応する機能を提供する。 キ一 VK_SLOW_REVERS Eは、 逆方向のスロー再生を指示するスロー （逆方向） キーに対応す る機能を提供する。 キ一 VK— STEP_FORWARDは、 順方向のコマ送り再生 を指示するコマ送り （順方向） キーに対応する機能を提供する。 キー VK— STEP_REVERSEは、 逆方向のコマ送り再生を指示するコマ送り （逆 方向） キーに対応する機能を提供する。
キー VK_NEXTは、 「次」 を意味する値を入力する次指定キーに対応 する機能を提供する。 キ一 VK— PREVIOUSは、 「前」 を意味する値を入 力する前指定キーに対応する機能を提供する。 例えば、 キ一 VK_NEXT およびキ一VK— PREVI OUSを用いて、 前後のチヤプ夕への移動を指示す ることができる。
キ一 VK_ANGLEは、 マルチアングルのビデオに対するアングル切り替 えを指示するアングル切り替えキーに対応する機能を提供する。 キー VK— SUBT I TLEは.、 英語字幕、 日本語字幕、 字幕表示/非表示などを切 り替える字幕切り替えキーに対応する機能を提供する。 キー VK— AUD I O は、 サラウンドやバイリンガルなどオーディオ設定を切り替えるォー ディォ切り替えに対応する機能を提供する。 キー VK_V IDE0_ASPECTは 、 ビデオのァスぺクト比切り替えを指示するァスぺクト切り替えキー に対応する機能を提供する。
第 1 0図は、 メニュー操作に関する一例のキー入力を示す。 キ一 VK _UPは、 「上」 を意味する値を入力する上方向指定キーに対応する機 能を提供する。 キ一VK— DOWNは、 「下」 を意味する値を入力する下方 向指定キーに対応する機能を提供する。 キー VK_RI GHTは、 「右」 を意 味する値を入力する右方向指定キーに対応する機能を提供する。 キー VK_LEFTは、 「左」 を意味する値を入力する左方向指定キーに対応す る機能を提供する。 キー VK_UP— RI GHTは、 「右斜め上」 を意味する値 を入力する右上方向指定キーに対応する機能を提供する。 キー VK— UP_ LEFTは、 「左斜め上」 を意味する値を入力する左上方向指定キーに対 応する機能を提供する。 キー VK_D0WN— RI GHTは、 「右斜め下」 を意味 する値を入力する右下方向指定キーに対応する機能を提供する。 キー VK_D0WN_LEFTは、 「左斜め下」 を意味する値を入力する左下方向指定 キーに対応する機能を提供する。 これらの方向キーを用いることで、 例えば画面上のカーソル表示の移動を指示することができる。
キー VKJENUは、 メニューを表示させるメニューキーに対応する機 能を提供する。 キ一VK— ENTERは、 「決定」 を指示する決定キーに対応 する機能を提供する。 キー VK— RETURNは、 処理のステップを一つ戻す ことを指示する戻るキーに対応する機能を提供する。
キ一 VK— C0L0RED_KEY_1は、 色つきファンクションキ一 1、 キー VK_C 0L0RED_KEY_2は、 色つきファンクションキー 2、 キ一 VK_C0L0RED_KEY _3は、 色つきファンクションキー 3、 キ一 VK_C0L0RED_KEY— 4は、 色つ きファンクションキ一 4、 キー VK—C0L0RED— KEY_5は、 色つきファンク シヨンキー 5、 キー VK— C0L0RED_KEY_6は、 色つきファンクションキー 6にそれぞれ対応する機能を提供する。 上述の第 9図に示したキー入力と第 1 0図に示したキー入力とでは 役割が異なるため、 通知先をネィティブ実装プラットフオーム 3 0 1 で振り分ける必要がある。 上述したように、 第 9図に示されるキー入 力により、 ビデオ、 オーディオおよび字幕の再生に関する指示がなさ れる。 ネィティブ実装プラットフオーム 3 0 1は、 ユーザ入力 3 1 0 として第 9図に示されるキー入力を受け取ると、 受け取ったキー入力 を、 第 1 1図 A、 第 1 1図 Bおよび第 1 1図 Cに示すコマンドに変換 してムービープレーヤ 3 0 0に通知する。
一方、 第 1 0図に示されるキー入力は、 G U Iに対するユーザ入力 3 1 0であるので、 このユーザ入力は、 画面構成やポタンを配置する スクリプトレイヤ 3 0 2に通知されて処理される必要がある。 ネィテ ィブ実装ブラッ卜フォーム 3 0 1は、 ユーザ入力 3 1 0として第 1 0 図に示されるキー入力を受け取ると、 第 2図におけるイベント 3 1 4 に変換してスクリプトレイヤ 3 0 2に通知する。 第 1 2図は、 このキ 一入力に対応する一例のイベント 3 1 4を示す。
なお、 上述した第 9図および第 1 0図には、 キ一 VK_ANGLE、 キー VK .SUBTITLE, キー VK_AUDI0という、 ストリーム切り替えに関するキ一 入力も含まれている。 これらは、 先ずユーザ入力 3 1 0がムービープ レーャ 3 0 0に伝えられ、 ムービープレーヤ 3 0 0からスクリプトに ストリーム切り換え要求があったことを示すイベントが通知される。 そして、 スクリブトプログラムからムービープレーヤ 3 0 0に対する ストリ一ム切り換えのメソッドで、 オーディオや字幕が切り替わるよ うにしている。 そのため、 ネィティブ実装ブラットフオーム 3 0 1か らムービープレーヤ 3 0 0に対して伝えられるべきキー入力である。 上述した第 1 1図 A、 第 1 1図 Bおよび第 1 1図 Cのコマンドにつ いて、 より詳細に説明する。 コマンド uo_UmeSearch (p l ayL i s t T ime) は、 再生中のプレイリストの指定時刻からの再生を指示する。 引数 pl ayListTimeは、 プレイリストの先頭を 0としたときの時刻を表す。 こ のコマンドでは、 プレイリスト番号の指定はできないため、 引数 play ListTimeで表される時刻は、 現在再生中のプレイリス卜の範囲内での 指定時刻となる。 コマンド uo_play()は、 1倍速での再生開始を指示 する。 開始位置は、 リジュームィンフオメ一ション 3 24に基づき決 められる。 リジュームインフォメーション 3 24に対応する情報が無 い場合は、 このユーザ操作は無効とされる。 このコマンドは、 プレイ リスト番号の指定の無いメソッド playOを実行したときに対応する。 また、 このコマンドにおいて、 ユーザ操作ではプレイリスト番号を指 定できない。
コマンド uo_playChapter (chapterNumber)は、 再生中のプレイリス トの、 引数 chapterNumberで指定されたチヤプ夕からの再生開始を指 示する。 チヤプ夕の指定がない場合には、 現在再生中のチヤプ夕の先 頭からの再生開始を指示する。 これは、 チヤプタ番号の指定の無いメ ソッド playChapterOに対応する。 コマンド uo_playPrevChapter 0は 、 現在よりも一つ前のチヤプタからの再生開始を指示する。 コマンド uo_playNextChapter 0は、 現在の次のチヤプ夕からの再生開始を指示 する。
コマンド uo_jumpToEnd()は、 プレイリストの最後へのジャンプを指 示する。 このコマンドは、 ムービープレーヤ 3 00に対して、 現在の 再生を中止してィベント playListEndを発生させるように指示するュ 一ザ操作に対応する。 このコマンドに対応して、 スクリプトレイヤ 3 0 2では、 イベントハンドラ onPlayListEndが実行される。 コマンド u o_forwardScan(speed)は、 引数 speedで指定された再生速度での順方 向再生を指示する。 コマンド uo .backwardScan (speed)は、 弓 I数 speed で指定された再生速度での逆方向再生を指示する。 これらコマンド U0
_forwardScan(speed)およびコマンド uo一 backwardScan (speed)におけ る引数 speedは、 UMDビデオプレーヤの実装に依存する。
コマンド uo_playStep(forward)は、 順方向のコマ送り再生を指示す る。 コマンド uo一 playStep(backward)は、 逆方向のコマ送り再生を指 示する。 コマンド uo一 pauseOnOは、 ユーザ操作に基づき再生の一時停 止を指示する。 コマンド uo— pauseOff 0は、 ユーザ操作に基づき再生 の一時停止状態を解除する。
コマンド uo_setAudioEnabled (boolean)は、 オーディォストリ一ム の ONZO F Fを指定する。 このコマンドの実行時に、 フラグ audioF lagの値も対応した内容に変更する。 コマンド uo— setSubtitleEnabled (boolean)は、 字幕ストリームの O N O F Fを指定する。 このコマ ンドの実行時に、 フラグ subtitleFlagの値も対応した内容に変更する 。 コマンド uo_angleChange()は、 表示アングルの変更を指示する。 こ のコマンドによるユーザ操作がムービープレーヤ 3 0 0に伝えられる と、 ムービープレーヤ 3 0 0は、 スクリプト.レイヤ 3 0 2に対してィ ベン卜 angleChangeを通知する。 コマン Huo_audioChange udioStrea mNumber)は、 再生するオーディオストリームの変更を指示する。 コマ ンド uo_changeAudioChannel (value)は、 オーディォのチヤンネル切り 換えまたはデュアルモノ再生時の片チャンネル切り替えを指示する。 このコマンドの実行時に、 フラグ audioFlagの値も対応した内容に変 更する。 コマンド uo_subtitleChange(subtitleStreamNumber)は、 再 生する字幕ストリームの変更を指示する。
上述した第 1 2図に示すイベントおよびイベントのムービープレー ャ 3 0 0のメソッドとの関係について、 より詳細に説明する。 ィベン ト menuは、 メニューにジャンプする。 このイベントは、 ムービープレ ーャ 3 0 0に対してではなく、 ネィティブ実装プラッ 卜フォーム 3 0 1からスクリプトレイヤ 3 0 2に通知される。 このィベント menuが クリブトレイヤ 3 0 2に受け取られると、 スクリプトレイヤ 3 0 2は 、 イベントハンドラ onMenuを実行する。 イベント exitは、 ネイティブ 実装プラッ トフオーム 3 0 1が UMDビデオアプリケーションを終了 させる際に、 ネイティブ実装プラットフオーム 3 0 1から発せられる イベントである。 このイベント exitがスクリプトレイヤ 3 0 2に受け 取られると、 スクリプトレイヤ 3 02は、 イベントハンドラ onExitを 実行する。
イベント resourceChangedは、 リソースファイルの切り換えが発生 したときに、 ネィティブ実装プラットフオーム 3 0 1から発せられる イベントである。 このィベント resouceChangedがスクリプトレイヤ 3 0 2に受け取られると、 スクリプトレイヤ 3 0 2は、 イベントハンド ^nResourceChanged^^iT ^
イベント up、 イベント down、 イベント left、 イベント right、 ィべ ン卜 focusIn、 ィベン卜 focusOut、 ィベン'卜 pushおよびイベント cance 1は、 画面に表示されている GU I部品であるポタン画像にフォー力 スが当たっている場合に発生するイベントである。 このイベントは、 ムービープレーヤ 3 0 0に対してではなく、 ネイティブ実装プラット フォーム 3 0 1からスクリプトレイヤ 3 0 2に通知される。 なお、 ボ タン画像にフォーカスが当たった場合とは、 例えば、 画面上の位置を 指示するためのカーソルがボタン画像の表示座標を示し、 当該ボタン 画像が選択可能となっているような状態である。 イベント up、 ィベン ト down、 イベント leftおよびイベント rightは、 ポタン画像に対する フォーカスが、 それぞれ上、 下、 左および右のポタン画像に移動した 場合に発生する。 イベント focuslnは、 あるポタン画像にフォーカス が当たった場合に発生し、 イベント focusOutは、 フォーカスの当たつ ていたポタン画像からフォーカスが外れた場合に発生する。 また、 ィ ベント pushは、 フォ カスの当たっているボタン画像に対して押下操 作が行われた際に発生する。 イベント cancelは、 ポタン画像の押下操 作に対してキャンセル操作が行われた際に発生する。
ィベント autoPlayおよびィベント cont inuePlayは、 スクリプトレイ ャ 3 0 2におけるスクリプトの実行開始を指示するイベントである。 イベント autoPlayは、 ディスクの装填時に自動的にスクリプトの実行 を開始するように指示するィベントである。 イベント continuePlayは 、 ディスク装填時に、 例えばリジュームインフォメーション 3 24に 基づき、 以前中止された時点からのスクリブトの実行再開を指示する 第 1 2図で示したイベントに対しては、 イベントが発生したときに 実行されるプログラムが存在する。 このイベントに対応したプロダラ ムをイベントハンドラと称する。 イベントとイベントハンドラとは、 例えば名前で対応関係をつけることができる。 一例として、 イベント 名の先頭に 「on」 を付加したものがイベント八ンドラ名となる。 第 1 3図および第 1 4図は、 一例のイベント八ンドラを示す。 イベントハ ンドラの内容をコンテンツ制作者が記述することにより、 UMDビデ ォプレーヤにコンテンツ制作者が意図する様々な動作を実行させるこ とが可能になる。
第 1 3図は、 ムービープレーヤオブジェクト 3 0 0が持つ一例のィ ベントの一部と、 対応するイベントハンドラとを示す。 この第 1 3図 のイベントは、 上述した第 2図のイベント 3 1 2に対応し、 ムービー プレーヤ 3 0 0からスクリプトレイヤ 3 0 2に通知される。 イベント ハンドラは、 一種のインタ一フェイスであって、 その内容は、 例えば コンテンツ制作者がスクリブト言語を用いて実装する。 イベントハン ドラをこのように構成することで、 イベント発生時に、 コンテンツ'制 作者の意図する動作を実現することができる。
ィベント markおよびィベントハンドラ onMarkOは、 ィベントマ一ク (Event- mark)が検出された際に実行される。 イベントマークは、 例え ば、 プレイリスト中に埋め込まれ、 プレイリストの再生中にムービー プレーヤ 3 0 0により検出される。 ムービープレーヤ 3 0 0によりィ ベントマークが検出されると、 ムービープレーヤ 3 0 0からスクリブ トレイヤ 3 0 2に対してイベント markが通知される。 スクリプトレイ ャ 3 0 2は、 このイベント markに対応するイベントハンドラ onMarkO を実行する。 同様にして、 イベント palyListEndおよびイベントハン ドラ011?1& 1^51£11(1()は、 プレイリス卜が終了した際に実行される。 ィベント chapterおよびィベントハンドラ onChapter 0は、 チヤプタマ ーク（Chapter-mark)検出時に実行される。 チヤプ夕マークは、 例えば 、 プレイリスト中に埋め込まれ、 プレイリストの再生中にム一ビープ レ一ャ 3 0 0により検出される。
ィベント angleChangeおよびィベント八ンドラ onAngleChange 0は、 ユーザ操作によりアングル変更が指示されたときに実行される。 例え ば、 ユーザ操作に応じてキー入力 VK_ANGLEがユーザ入力 3 1 0として ネイティブ実装プラッ トフォーム 3 0 1に入力されると、 ネイティブ 実装ブラッ トフオーム 3 0 1は、 当該ユーザ入力 3 1 0をコマンド uo _angleChange 0に変換してム一ビープレーヤ 3 0 0に渡す。 ムービー プレーヤ 3 0 0は、 このコマンド uo_angleChange()に応じてィベント angleChangeを発生させ、 スクリプトレイヤ 3 0 2に渡す。 スクリプ トレイヤ 3 0 2は、 このイベント angleChangeに対応したイベントハ ンドラ onAngleChangeOを実行する。 同様にして、 イベント audioChan geおよびィベントハンドラ onAudioChangeOは、 ユーザ操作によりォ 一ディォの変更が指示されたときに実行される。 イベント subtitleCh angeおよびィベントハンドラ onSubt i t leChange 0は、 ユーザ操作によ り字幕変更が指示されたときに実行される。
第 1 4図は、 コント口一ラオブジェク ト 3 3 0が有する一例のィべ ントハンドラの一部を示す。 この第 1 4図に示されるイベントハンド ラは、 ネイティブ実装プラットフォーム 3 0 1のコントローラォブジ ェクト 3 3 0に属するイベントハンドラであり、 ネィティブ実装ブラ ッ トフォーム 3 0 1からスクリプトレイヤ 3 0 2に通知されることに より実行される。
ィベント menuおよびィベントハンドラ onMenuOは、 メニューにジャ ンプする。 イベント menuは、 例えば、 ユーザ操作などでメニューキー が押下されたときに、 ネィティブ実装ブラッ トフオーム 3 0 1からス クリブトレイヤ 3 0 2に通知されるイベントである。 スクリプトレイ ャ 3 0 2は、 このイベントを受けて、 対応するイベントハンドラ onMe nu()を実行し、 イベントハンドラ onMenuO内でメニュー画面を構成す る GU I部品の配置や表示などを行う。 イベント ex itおよびイベント ハンドラ onExitOは、 ネィティブ実装プラッ トフオーム 3 0 1が UM Dビデオアプリケーションを終了させる際に、 ネィティブ実装プラッ トフオーム 3 0 1から発せられるィベントおよび対応するィベントハ ンドラである。
イベント exitは、 例えば、 ユーザ操作などにより UMDビデオプレ —ャの動作の終了が指示された際に、 ネィティブ実装プラットフォ一 ム 3 0 1からスクリプトレイヤ 3 0 2に通知される。 スクリプトレイ ャ 3 0 2のスクリプトは、 通知されたイベント exitを受けて、 ィベン トハンドラ onExi tO内で終了処理を行うことができる。 ィベント resourceChangedおよびィベントハンドラ onResourceChang edは、 ネイティブ実装プラットフオーム 3 0 1がリソースファイル ½ 切り換えた後に、 ネイティブ実装プラットフオーム 3 0 1から発せら れるィベントおよび対応するィベン卜ハンドラである。
イベント autoPlayおよびイベントハンドラ onAutoPlay()、 ならびに
、 ィベント(：011"11116?1& ぉょびィべントハンドラ011(：01^ 1111^?1& 0は
、 それぞれスクリプトの実行を開始する。
なお、 コントローラオブジェクト 3 3 0のイベントハンドラ以外に 、 ポタンに関するイベントハンドラがある。 このポタンに関するィべ ントハンドラは、 この発明と関連性が低いので、 説明を省略する。 第 1 5図のフローチャートを用いて、 ユーザ入力イベントをきつか けとして、 用意されたプログラムが実行される一例の処理について、 概略的に説明する。 第 1 5図は、 UMDビデオプレーヤにおいてディ スクを通常再生中に、 ユーザにより、 次のチヤプ夕を再生することを 指示するためのキー （例えば" next"キー） が押されたときに、 このキ —入力に対応して、 次のチヤプ夕にジャンプして再生を開始すると共 に、 用意されたメッセージを画面上に表示する例である。
例えば、 UMDビデオプレーヤによりディスクを通常再生中に、 ュ —ザが UMDビデオプレ一ャのリモートコントロ一ルコマンダを用い てキー" next"を押下すると （ステップ S 1 0) 、 ネイティブ実装ブラ ットフオーム 3 0 1に対するユーザ入力 3 1 0として、 キー VK— NEXT が渡される。 ネイティブ実装プラット'フォーム 3 0 1では、 このユー ザ入力 3 1 0に対応してユーザコマンド uo— playNextChapterOが発生 する （ステップ S 1 1 ) 。 このユーザコマンド uo_playNextChapter 0 は、 ムービープレーヤ 3 0 0に通知される。
このコマンド uo— playNextChapterOを受け取ったムービープレーヤ 3 0 0は、 デ一夕ベース 3 2 0を検索し、 プレイリスト情報から現在 再生している位置を基準として、 次のチヤプ夕マークの位置を取得す る （ステップ S 1 2 ) 。 ステップ S 1 3で、 次のチヤプタマークが存 在するか否かが判断され、 若し、 存在しないと判断された場合、 チヤ プ夕ジャンプを行わず、 現在の再生が継続される。
一方、 ステップ S 1 3で、 次のチヤプ夕マークが存在すると判断さ れれば、 処理はステップ S 1 4に移行する。 ステップ S 1 4では、 ム ービ一プレーヤ 3 0 0は、 現在の再生を中止し、 次のチヤプタマーク が指し示す、 クリップ A Vストリームファイル内でのバイ ト位置を、 デ一夕ベース 3 2 0のクリップインフォメーションファイルの特徵点 情報から取得する。 そして、 ステップ S 1 5で、 取得されたファイル 内バイ 卜位置にアクセスし、 その位置からストリームの読み込みを開 始して再生を開始する。
ステップ S 1 6以下は、 チヤプ夕が切り替わつたことを知らせるメ ッセージを画面上に表示するための一連の手順である。 チヤプ夕が切 り替わりチヤプ夕の先頭からの再生が開始されると、 チヤプ夕ィベン 卜が発生する （ステップ S 1 6 ) 。 例えば、 チヤプ夕の先頭に設けら れたチヤプタマークがムービープレーヤ 3 0 0に検出ざれ、 イベント chap t erが発生される。 このチヤプ夕イベントは、 ムービープレーヤ 3 0 0からスクリプトレイヤ 3 0 2に通知される。 ムービープレーヤ 3 0 0は、 このイベントの通知時に、 ジャンプするチヤプ夕のチヤプ 夕番号も共に、 スクリプトレイヤ 3 0 2に対して通知する。 スクリブ トレイヤ 3 0 2.は、 通知されたイベントに対応するィベントハンドラ 、 例えばイベントハンドラ onChap t e r Oの実行を開始する （ステップ S 1 7 ) 。
この例では、 イベントハンドラ内には、 チヤプ夕が切り替わった際 に画面上にその旨を知らせるメッセージを表示する動作が記述されて いるものとする。 スクリプトレイヤ 3 0 2のスクリプトは、 このィ ントハンドラを実行し、 イベント発生時にムービープレーヤ 3 0 0か ら通知されたジャンプ先のチヤプタ番号を取得し （ステップ S 1 8 ) 、 ネイティブ実装プラッ トフォーム 3 0 1に対して、 例えば取得した チヤプ夕番号のチヤプ夕の先頭であるなど、 所定のメッセージを画面 上に表示する指示を出す。 ネィティブ実装プラッ トフオーム 3 0 1は 、 この指示に応じて、 画面上にメッセージを表示し （ステップ S 1 9 ) 、 イベントハンドラによる処理が終了される （ステップ S 2 0 ) 。 上述のような処理により、 ユーザが次のチヤプ夕の再生開始を指示 するキ一" n e X t "を操作することによりチヤプ夕ジャンプが行われ、 ジ ヤンプ先である次のチヤプ夕の再生開始時にチヤプタの先頭であるこ とを示すメッセージが画面上に表示されることになる。
このように、 ユーザ入力イベントは、 ムービープレーヤ 3 0 0の状 態を変化させ、 また、 新たなイベントを発生させる契機ともなり、 新 たに発生したィベントを利用して様々な処理を行わせることができる 以上のようなプレーヤモデルにより、 ビデオ、 オーディオおよび字 幕の再生が可能となる。 コンテンツ制作者が予め設定しておいた、 再 生中のある時刻にあるイベントを発生させて、 予め用意しておいたィ ベントハンドラが実行されることで、 コンテンツ制作者が意図する動 作を実現できる。 また、 プレイリストの再生中にプレーヤに対するュ 一ザ操作があった場合には、 ユーザ操作によるユーザ入力 3 1 0に応 じてネイティブ実装プラッ トフオーム 3 0 1からムービープレーヤ 3 0 0に対して制御コマンドが与えられ、 ユーザの意図する通りにプレ ーャの状態を変化させることができる。 さらに、 プレーヤに対するュ 一ザ操作によるユーザ入力 3 1 0を受けたネィティブ実装プラットフ オーム 3 0 1がスクリプトレイヤ 3 0 2のスクリプトにイベントを 知することにより、 ユーザ操作に応じ、 コンテンツ制作者が用意した 動作を実行させることも可能となる。
このようにプレーヤモデルを構築することで、 ビデオ、 オーディオ および字幕の再生と、 ィン夕ラクティブな操作とをユーザに提供する ことが可能となる。
5 . スクリプトプログラムの例
次に、 スクリプトレイヤ 3 0 2のスクリブトプログラムの例につい て説明する。 先ず、 第 1 6図に示されるようなコンテンツ再生の流れ が、 コンテンツ制作者により作られているものとする。 第 1 6図に示 されるコンテンツは、 表示される要素としては、 プレイリスト 4 0 0 および 4 0 1、 トップメニュー 4 0 2、 ならびに、 メッセージ 4 0 3 から構成される。 プレイリスト 4 0 0は、 ディスクが装填されると自 動的に表示される警告文画面を表示するためのものである。 プレイリ スト 4 0 1は、 例えばこのコンテンツの主眼である映画の本編である 。 トップメニュー画面 4 0 2は、 プレイリスト 4 0 1の再生を指示で きるように、 ボタンなどの G U I部品が配置される。 また、 メッセ一 ジ 4 0 3は、 プレイリスト 4 0 1の再生中の任意の時刻に表示される 。
さらに、 この第 1 6図の構成では、 幾つかのイベントハンドラが用 意されている。 イベントハンドラ onAu t oP l ay Oは、 ディスクが U M D プレーヤに装填されると、 プレイリスト 4 0 0を自動的に再生し、 警 告文を表示させる。 イベントハンドラ onP yL i s tEnd Oは、 プレイリ ストの再生が終了すると呼び出されるイベントハンドラで、 この第 1 6図の例では、 プレイリスト 4 0 0やプレイリスト 4 0 1の終了で呼 び出される。 すなわち、 イベントハンドラ onPlayListEndOは、 どの プレイリス卜が終了したかを判定し、 プレイリスト 400の再生が 了した場合には、 プレイリスト 40 1の再生開始を指示する。 また、' プレイリスト 40 1の再生が終了した場合には、 トップメニュー画面 40 2を呼び出す。
ィベントハンドラ onMenuOは、 ユーザがメニューキーを操作したと きに呼び出され、 トップメニュー 40 2を呼び出して画面に表示する 。 イベントハンドラ onMarkOは、 再生中にマーク Markが指し示す時刻 に到達したときに実行される。 この第 1 6図の例では、 プレイリスト 40 1に対してマーク Markが設定されており、 プレイリスト 40 1の 再生がマーク Markの指し示す時刻に到達すると、 画面上にメッセージ 40 3が表示されるようになっている。
すなわち、 第 1 6図の例では、 UMDビデオプレーヤにディスクが 装填されると、 イベントハンドラ onAutoPlayが呼び出されてプレイリ スト 40 0が再生され、 警告画面が表示される。 プレイリスト 40 0 の再生時間が経過し、 プレイリスト 4 0 0の.最後に到達すると、 ィべ ントハンドラ onPlayListEndが呼び出され、 プレイリス卜 40 0が最 後まで再生されたことが判定され、 次のプレイリスト 40 1が再生さ れる。 ここで、 プレイリスト 40 1の再生中に、 ユーザによりメニュ —キーが操作されると、 イベントハンドラ onMenuが呼び出され、 トツ プメニュー画面 40 2が表示される。 また、 イベントハンドラ onMenu により、 トップメニュー画面 40 2に対する所定の操作に応じて、 プ レイリスト 40 1の先頭から再生が開始される。 さらに、 プレイリス ト 4 0 1の再生時刻がマーク Markが指し示す時刻に到達したら、 ィべ ントハンドラ onMarkが呼び出され、 メッセージ 40 3が画面上に表示 される。 プレイリスト 40 1が最後まで再生されると、 イベントハン ドラ onPlayListEndが呼び出され、 プレイリスト 40 1が最後まで再 生されたことが判定され、 トップメニュー画面 402が表示される 第 1 7図は、 この第 1 6図に示すような動作を実現するための一例 のスクリプトプログラムを示す。 上述したように、 スクリプトプログ ラムは、 イベントハンドラが並べられ、 ィベン卜の発生に応じて対応 するイベントハンドラが実行されるようになっている。 スクリプトプ ログラムは、 拡張子が 「RC0」 であるリソースファイルに格納される ムービープレーヤ 300に対してプレイリス卜の再生を指示するメ ソッドは、 「movieplayer.play()」 である。 括弧内には、 引数として 、 再生するプレイリストの番号を記述する。 プレイリストの再生が終 了すると、 イベント playListEndが発生する。 このイベント playListE ndが発生すると、 スクリブトからィベントハンドラ movieplayer. onPl ayListEndOが呼び出される。 このとき、 スクリプトには、 イベント p layListEndと共に、 オブジェクト evenし infoが渡される。 オブジェク ト evenし infoには、 どのプレイリス卜が終了したかを表すプレイリス 卜番号などが格納される。 スクリプトでは、 このオブジェクト evenし infoの内容により、 次の動作を変えることができる。
6. ファイルの管理構造について
次に、 UMDビデオ規格に適用され'るファイルの管理構造について 、 第 1 8図を用いて説明する。 ファイルは、 ディレクトリ構造により 階層的に管理されて、 ディスク上に記録される。 ディスクのファイル システムは、 I S O (Internat ional Organization for Standardizat ion) - 966 0あるいは UD F (Universal Disk Format)などで規定 されたファイルシステムを適用することができる。
ルートディレクトリの下に、 ファイル" TITLEID.DAT"およびディレ クトリ" VIDEO"が置かれる。 ディレクトリ" VIDEO"の下には、 さらに、 ディレクトリ" RESOURCE" , ディレクトリ" CL IP"およびディレクトリ TREAM" , ならびに、 ファイル" PLAYL I ST. DAT"が置かれる。
ファイル" TITLE ID. DAT"は、 タイトル （コンテンツの種類） 毎に異 なるタイトル識別子が格納されるファイルである。 1つのディスクに 対し、 1つのファイル" TITLE ID. DAT"を有する。
ディレクトリ" RESOURCE"の下には、 リソースファイル（" JA000000. R CO" )が置かれる。 リソースファイルには、 上述したように、 スクリブ トレイヤ 3 0 2を構成するスクリブトプログラムが格納されると共に 、 メニュー画面を構成するために用いられるデ一夕、 例えば画像デー 夕やサウンドデータなどの部品データが格納される。 ディレクトリ" R ES0URCE"の下には、 通常、 1個のリソースファイルが置かれる。 これ に限らず、 ディレクトリ" RESOURCE"の下に、 複数のリソースファイル を置くこともできる。 複数のリソースファイルは、 例えば、 表示言語 の異なる複数のメニューなどを用意する際に、 言語毎に作成される。 この場合でも、 同時に用いられるリソースファイルは、 1個とされる なお、 リソースファイルは、 そのファイル名において、 デリミタで あるピリオドの後ろの拡張子を 「RC0」 に固定的として、 当該フアイ ルがリソースファイルであることを示すようにしている。 また、 ピリ ォドの前の文字列により、 当該リソースファイルの内容を概略的に示 すようにしている。 例えば、 リソースファイルのファイル名全体を 「 CCdannnn. RC0」 ·の形式として、 先頭の 2文字 「(： (：」 が当該リソースフ アイルに対応する言語コード、 次の 1文字 「d」 が当該言語コードが デフォルト言語であるか否かを表すフラグ、 次の 「a」 が表示画面の アスペクト比、 次の 4文字 「nnnn」 が識別番号を表す。 識別番号は、 複数のリソースファイルにおいて、 ファイル名が互いに重複しないよ うに決められる。
リソースファイルのファイル名の命名規則をこのようにすることで 、 リソースファイルのファイル名によって、 リソースデータの言語属 性と表示画面のアスペク ト比とが分かるようになつている。 リソース ファイルの選択時には、 適切なリソースファイルをファイル名に基づ き判別する。
ディレクトリ" CL IP"の下には、 1以上のクリップィンフオメ一ショ ンファイルが置かれる。 クリップインフォメーションファイルは、 フ アイル名を、 デリミタであるピリオドの前が 「00001」 などの 5文字 乃至数文字からなる文字列 （この例では数字） 、 ピリオドの後ろの拡 張子が 「CLPJ とされる。 拡張子 「CLP」 により、 当該ファイルがクリ ップインフォメ一ションファイルであることを識別できる。
ディレクトリ" STREAM"の下には、 1以上のクリップ A Vストリーム ファイルが置かれる。 クリップ A Vストリームファイルは、 ファイル 名を、 デリミタであるピリオドの前が 「00001」 などの 5文字乃至数 文字からなる文字列 （この例では数字） 、 ピリオドの後ろの拡張子が 「PS」 とされる。 拡張子 「PS」 により、 当該ファイルがクリップ A V ストリームファイルであることを識別できる。 この実施の一形態では 、 クリップ A Vストリームファイルは、 ビデオストリーム、 オーディ ォストリームおよびサブタイ トル （字幕） ストリームが多重化され、 M P E G 2 (Mov i ng P i c t ures Exper t s Group 2)のプログラムストリ ームとして、 上述の拡張子 「PS」 で識別されるファイルに格納される 上述したように、 クリップ A Vストリームファイルは、 ビデオデー 夕およびオーディォデ一夕を圧縮符号化および時分割多重して得られ るファイルであって、 このファイルを読み込み、 デコード処理を行う ことで、 ビデオデータおよびオーディオデ一夕が得られる。 また、 ^ リップィンフオメーションファイルは、 このクリップ AVス卜リーム ファイルの性質などが記述されるファイルであって、 クリップ AVス トリームファイルと対応する。 この実施の一形態では、 クリップイン フオメ一ションファイルと対応するクリップ AVストリームファイル とで、 ファイル名における、 拡張子の前の、 5文字乃至数文字からな る文字列を一致させておくことで、 両者の対応関係を容易に把握でき る。
リソースファイルは、 上述したように、 スクリプトプログラムが記 述されたスクリプトファイルを含み、 この実施の一形態が適用される ディスクの再生形態をィン夕ラクティブなものとするために用いるプ ログラムが格納されている。 リソースファイルは、 ディスクに格納さ れる他のファイルに先立って読み出される。
ファイル" PLAYLIST.DAT"は、 クリップ A Vストリームの再生順を指 定するプレイリス卜が記述されたプレイリストファイルである。 第 1 9図〜第 2 1図を用いて、 ファイル" PLAYLIST.DAT"の内部構造につい て説明する。 第 1 9図は、 ファイル" PLAYLIST.DAT"の全体構造を表す 一例のシンタクスを示す。 ここでは、 シンタクスをコンピュータ装置 などのプログラムの記述言語として用いられる C言語の記述法に基づ き示す。 これは、 他のシンタクスを表す図において、 同様である。 フィールド name_lengthは、 8ビッ トのデ一夕長を有し、 このプレ ィリストファイルに付された名称の長さを示す。 フィールド name— str ingは、 2 5 5バイ トのデータ長を有し、 このプレイリストファイル に付された名称を示す。 フィールド name_stringは、 その先頭から、 フィールド name_lengthが表すバイ ト長までが、 有効な名称として使 用される。 例えば、 フィールド name— lengthが値" 1 0"を持つ場合に は、 フィールド name— s ingの先頭から 1 0バイト分が有効な名称と； して解釈される。 ' フィ一ルド number_oし PlayListsは、 1 6ビットのデ一夕長を有し 、 続けて記述されるブロック PlayListOの個数を示す。 次行の forル —プによりフィ一ルド number_oし PlayListsに示される回数分だけ、 当該個数のブロック PlayListOが記述される。 ブロック PlayList 0は 、 プレイリストそのものである。
プロック PlayList 0の一例の内部構造について説明する。 プロック PlayList Oの先頭には、 フィールド PlayList一 data_lengthが配される 。 フィールド PlayLisし datajengthは、 3 2ビットのデータ長を有し 、 当該フィールド PlayList— datajengthを含むブロック PlayLis t 0の データ長を示す。 続いて、 1 5ビットのデータ長を有するフィールド reserved— for— word— al ignmentと、 1匕ッ卜のテー夕； ¾を有するフラ グ capture_enab-le_flag— PlayListと力 s配される。 フィ——Jレド reserved — for— word_al ignmentは、 う "一夕長が 1ヒッ卜のフラク capture— enabl 6— &8_?1& 31と組み合ゎせて、 ブロック PlayLis t 0内での配置を 1 6ビッ卜の位置に揃えるために用いられる。
フラグ capture— enable— flag—PlayLi s tは、 当該 capture— enable— f la g— PlayListを含むブロック PlayList 0に属する動画像の二次利用を許 可するか否かを示すフラグである。 例えば、 このフラグ capture_enab le_flag_PlayListの値が" 1 "であれば、 当該 PlayList 0に属する動画 像の、 再生機内での 2次利用を許可することを示す。
なお、 上述では、 フラグ capture— enable_flag_PlayListを 1ビット のフラグとしたが、 これはこの例に限定されない。 例えば、 フラグ ca pture_enable_flag— PlayListを複数ビット構成として、 2次利用の段 階的な許可を記述するようにしてもよい。 一例として、 フラグ captur e_enable_flag_PlayListを 2ビット構成とし、 値が" 0"の場合には 次利用を完全禁止とし、 値が" 1"の場合には例えば 64画素 X 64ラ ィンなど、 所定の解像度以下に圧縮符号化した場合のみ 2次利用を可 能とする。 また、 値が" 2"であれば、 制限無く 2次利用を許可すると いった利用が考えられる。 これに限らず、 2ビット構成のうちビット 0が値" 1"の場合にはコンテンツ再生アプリケ一ションでの 2次使用 を許可し、 ビット 1が値" 1 "の場合には同一筐体内の他のアプリケー シヨン （例えば壁紙画像やスクリーンセ一バ） での 2次使用を許可す る。 この場合には、 ビット 0およびビット 1の値を組み合わせて用い ることができる。
フィールド PlayLisし name_lengthは、 8ビットのデ一夕長を有し、 このブロック PlayList 0に付された名称の長さを示す。 フィールド P1 ayL isし name— stringは、 2 5 5ビットのデータ長を有し、 このブロッ ク PlayList 0に付された名称を示す。 フィールド PlayLisし name_stri ngは、 その先頭から、 フィールド PlayLisし name_stringが表すバイト 長までが、 有効な名称として使用される。
フィールド number_oし Playltemsは、 1 6ビットのデータ長を有し
、 続けて記述されるブロック PlayltemOの個数を示す。 次行の forル ープによりフィールド number— 0し Playltem2に示される回数分だけ、 当該個数のプロック PlayltemOが記述される。 ブロック Playl tem()は
、 プレイアイテムそのものである。
ブロック PlayListO内の各ブロック PlayltemOには、 識別情報 （ I
D) が付与される。 例えば、 ブロック PlayListO内の最初に記述され るブロック PlayltemOは、 0番とされ、 以降、 ブロック Playl temOの 出現順に、 1番、 2番、 · · · と通し番号が付される。 この通し番号 が各プロック PlayltemOの識別情報として用いられる。 ブロック P y ItemOの個数だけ繰り返される forループの引数 iを、 対応するプロ、 ク PlayltemOの識別情報として用いることができる。 プロック Playl't em ()の次に、 ブロック P 1 ayL i s t Mark 0が配置される。
第 20図を用いて、 ブロック PlayltemOの一例の内部構造について 説明する。 ブロック PlayltemOの先頭には、 フィールド lengthが配さ れる。 フィールド lengthは、 1 6ビッ トのデ一夕長を有し、 当該ブロ ック PlayltemOの長さを示す。 続いて、 フィールド CI ip_Informat ion — Π le— name_lengthが配 Sれる。 フィールド CI ip— In format ion— f i le_n ame— lengthは、 1 6ビッ トのデータ長を有し、 このブロック Playl tem 0に対応するクリップインフォメーションファイルの名称の長さを示 す。 フィールド Clip— Information— file— nameは、 バイ ト単位で可変長 のデータ長を有し、 このブロック PlayltemOに対応するクリップィン フオメ一ションファイルの名称を示す。 フィールド Clipjnformation —file— nameは、 その先頭から、 フィールド CI ip_Informat ion— Π le_na me一 lengthが表すバイ ト長までが、 有効な名称として使用される。 フ ィールド CI ip— Inf ormat ion— f i le_nameでクリップィンフオメーション ファイルが指定されると、 上述したファイル名の対応関係により、 当 該クリップインフォメーションファイルに対応するクリップ A Vスト リームファイルが特定できる。
フィールド IN_timeおよびフィ一ルド 0UT_timeは、 それぞれ 3 3ビ ッ 卜のデータ長を有し、 ブロック PlayltemO内においてフィールド C1 ip_Information_n le_nameで指定したクリップインフォメーションフ アイルに対応するクリップ AVストリームファイルの再生開始位置お よび再生終了位置を指定する時刻情報である。 これらフィールド IN— t imeおよびフィ一ルド 0UT_timeの情報を用いることで、 クリップ A V ストリームファイルの先頭以外の部分からの再生開始を指定すること ができる。 同様に、 クリップ A Vストリームファイルの後端以外の ¾ 生終了を指定することができる。 フィールド reserved_for— word—al g nmentは、 データ構造のデータ長を 1 6ビッ卜の整数倍にするための 調整用のフィールドであって、 1 5ビットのデータ長を有する。
第 2 1図を用いて、 ブロック PlayListMarkOの一例の内部構造につ いて説明する。 ブロック PlayListMarkOの先頭には、 フィールドの thが配される。 フィールド lengthは、 3 2ビットのデータ長を有し、 当該ブロック PlayListMarkOの長さを示す。 続いて、 フィールド numb er— of— P yListjnarksが配される。 フィールドフィールド number— oし PlayList_marksは、 1 6ビットのデ一夕長を有し、 続くブロック Mark 0の個数を示す。 次行の forループによりフィールド number_oし P yL i s t.marksに示される回数分だけ、 当該個数のブロック Mark 0が記述 される。
ブロック MarkOの一例の内部構造について説明する。 ブロック Mark 0は、 先頭にフィールド mark—typeが配される。 フィールド mark— type は、 8ビットのデータ長を有し、 当該フィールド markjypeを含むブ ロック MarkOの種類を示す。 この実施の一形態では、 第 2 2図に一例 が示されるように、 チヤプ夕マークおよびイベントマークの 2種類の マークが規定されている。 チヤプタは、 プレイリスト （ブロック Play List 0) を分割する頭出し単位であり、 チヤプ夕マークは、 チヤプタ 位置を時刻情報で示す。 イベントマークは、 マークイベントを発生さ せるマークである。
フィールド mark__name_lengthは、 8ビットのデータ長を有し、 この ブロック MarkOに付された名称の長さを示す。 ブロック Mark 0の最下 行に配されるフィールド mark name stringは、 このブロック MarkOに 付された名称を示す。 フィールド mark_name_stringは、 その先頭から 、 フィールド mark— namejengthが表すバイ ト長までが、 有効な名称 して使用される。
フィ——Jレド ref_to— Playltem— id、 フィ——Jレド mark— time— stamp、 フ ィー レド en try— ES— stream— idおよびフィーリレド en try— ES— private— s tr earn— idの 4要素は、 ブロック PlayList 0上で定義されるブロック Mark 0を、 クリップ AVストリームファイルと対応付ける。 すなわち、 フ ィ一ルド reし to_PlayItem_idは、 1 6ビットのデータ長を有し、 ブロ ック PlayltemOの識別情報を示す。 これにより、 クリップインフォメ —シヨンファイルと、 クリップ AVストリームファイルとが特定され る。
フィールド mark— time_sta即は、 3 3ビットのデ一夕長を有し、 ク リップ AVストリームファイル内でのマークの時刻を指定するために 用いられる。 第 2 3図を用いて、 概略的に説明する。 第 2 3図におい て、 プレイリストは、 番号 0、 1および 2がそれぞれ指定された 3つ のプレイアイテム （Playltem(#0)、 PI ayl tem(#l)および Playl tem(#2) ) からなり、 プレイリスト上の時刻 t。は、 番号 1のプレイアイテム
(PlayItem(#D) に含まれるものとする。 また、 番号 0、 1および 2 の各プレイアイテムは、 それぞれ対応するクリップィンフオメ一ショ ンファイルを介してクリップ A Vストリームファイルのプログラムス トリーム（Program Stream) A, Bおよび Cにそれぞれ対応しているも のとする。
このような場合において、 プレイリスト上の時刻 t。にマークを指 定する場合、 フィールド reし to_PlayItem— idの値を、 時刻 t。を含む プレイアイテムを示す " 1 "とし、 さらに、 対応するクリップ AVスト リームファイル B上で時刻 t。に相当する時刻を、 フィールド mark_ti me一 s t a即に記述する。
第 2 1図の説明に戻り、 フィールド mark— time_s tampに続けてフィ 1 ーリレド entry_ES— stream— idおよびフィー レド entry— ES— pr ivate_s tre'a m_idが配される。 フィ一ルド entry_ES— stream— idおよびフィールド en try— ES_private— stream— idは、 それぞれ 8ビットのデータ長を有し、 当該ブロック MarkOが特定のエレメンタリストリームに関連付けられ ている場合に、 そのエレメン夕リストリームを特定するために用いら れる。 フィールド en try_ES— stream— idおよびフィールド en try一 ES—pri vate— streamjdは、 それぞれ該当するエレメン夕リストリ一ムが多重 化されているバケツト（packetO)のストリーム I D (stream_id)と、 プライベ一卜ノ ケッ卜へッタ (pr i vat e— packet— header 0)のフライベ
—卜ス卜リ一ム I D (private_stream_id)を示す。
なお、 これらバケツ ト（packet 0)のストリ—ム I D (s tream— id)、 プライべ一トノ、。ケッ卜へッダ（private— packet— header ())のプライベ —トストリーム I D (private_stream_id)は、 例えば MP EG 2シス テムのプログラムストリームの規定に基づく。
これらフィ一ルド entry_ES— stream_idおよびフィ一ルド entry— ES_p rivate— stream_idは、 例えば、 クリップ AVストリーム # 0とクリッ プ A Vストリーム # 1とで異なるチヤプ夕構成である場合などに用い られる。 該当するブロック MarkOが特定のエレメン夕リストリームに 関連付けられていない場合には、 これら 2つのフィールドの値がそれ ぞれ" 0"とされる。
次に、 第 24図〜第 2 8図を用いて、 クリップインフォメーション ファイルの内部構造について説明する。 クリップインフォメーション ファイル" XXXXX.CLP"は、 上述したように、 ディレク トリ" STREAM"の 下に置かれた、 対応するクリップ AVストリームファイル" XXXXX.PS" の性質などを記述する。
第 24図は、 クリップ AVストリームファイル" XXXXX.CLP"の全 4： 構造を表す一例のシンタクスを示す。 クリップ A Vストリ一ムフアイ ル" XXXXX. CLP"は、 先頭に、 フィールド presentation_start— timeおよ びフィールド presentation_end_timeがそれぞれ配される。 フィ一ル Hpresentat ion_s tar t_t
Figure imgf000057_0001
ィ—— レド present at ion— end— t i me は、 それぞれ 3 3ビッ トのデータ長を有し、 対応するクリップ AVス トリームファイルの先頭と後端の時刻を示す。 時刻情報は、 MP EG 2システムにおける PTS (Presentation Time Stamp)を用いること ができる。 PTSは、 90 kH zの精度を有する。
次に、 7ビットのデータ長を有するフィ一ルド reserved— for_word_ alignmentと、 1ビッ卜の τ "―夕長を有するフラク capture— enable— f 1 ag_Cl ipと力配される。 フィーリレド reserved— for— word— al ignmentは、 データ長が 1ビットのフラグ capture_enable— flag_Clipと組み合わせ て、 ファイル" XXXXX.CLP"内での配置を 1 6ビッ トの位置に揃えるた めに用いられる。 フラグ capture_enable一 flag_Clipは、 当該ファイル "XXXXX.CLP"に対応するクリップ AVストリームファイルに含まれる 動画像の 2次利用を許可するか否かを示すフラグである。 例えば、 こ のフラグ capture— enable— flag_Cl ipの値が" 1 "であれば、 当該フアイ ル" XXXXX.CLP"に対応するクリップ AVストリームファイルの動画像 の、 再生機内での 2次利用を許可することを示す。
フィールド number— 0し streamsは、 8ビットのデータ長を有し、 続 くブロック StreamlnfoO構造の個数を示す。 フィールド number_oし s t reamsの次力、ら、 forノレープによりフィーソレド number— of_s treamsで示 される回数分だけ、 ブロック StreamlnfoOが記述される。 forループ の後には、 ブロック EP— map()が配される。 ブロック StreamlnfoOの一例の内部構造について説明する。 ブロッ ク StreamlnfoOの先頭には、 フィールド lengthが配される。 フィ一 ド lengthは、 1 6ビットのデ一夕長を有し、 当該ブロック Streaming) 0の長さを示す。 続いて、 それぞれ 8ビットのデータ長を有するフィ 一ルド stream一 idおよびフィールド private_stream_idが配され、 第 2 5図に一例が示されるように、 当該ブロック StreamlnfoOをエレメン タリストリームに関連付けている。 この第 2 5図の例では、 当該プロ ック StreamlnfoOは、 フィールド s tream_idが値" 0 x E 0 "〜値" 0 x E F"でビデオストリームに関連付けられ、 値" 0 X BD"で ATR A C (Adaptive Transform Acoustic Coding)ォ一ティォス卜リーム、 L P CM (Linear Pulse Code Modulat ion)オーディオストリームまたは 字幕ストリームと関連付けられる。 また、 当該ブロック StreamlnfoO は、 フィールド private— stream— idが値" 0 x 0 0"〜値" 0 0 F"、 値" 0 x 1 0"〜値" 0 x 1 F"および値" 0 x 8 0"〜値" 0 x 9 F"で、 ATRACオーディオストリーム、 L P CMオーディオストリームお よび字幕ストリームにそれぞれ関連付けられる。
なお、 第 2 5図での値の表記において、 「0 x」 は、 後続する数値 が 1 6進表記であることを示す。 これは、 以下の同様な表現において 、 共通である。
ここで、 ブロック StreamlnfoOは、 大別して、 ストリーム中で変化 しない情報とストリーム中で変化する情報との 2種類の情報が記述さ れている。 ストリーム中で変化しない情報は、 ブロック Stat icInfoO に記述される。 一方、 ストリーム中で変化する情報は、 変化点を時刻 情報で指定して、 ブロック DynamicInfoOに記述される。
ブロック StreamlnfoOにおいて、 ブロック Stat iclnfo 0の後ろにバ ィト位置を揃えるための、 8ビットのデータ長を有するフィールド re served— for— word— al ignment力配され、 その次に、 フィーリレド number— of— Dynamic Info力配される。 フィー レド number— of— Dynamic Infoは、 8ビットのデ一夕長を有し、 ブロック StreamlnfoO内にその後に記述 されるブロック DynamicInfoOの個数が示される。 forループにより、 フィールド number— 0し Dynamiclnfoで示される回数分だけ、 フィール ド p t s_change_po i n tおよびブロック Dynam i c I n f o 0が記述される。 フィールド pts_change_pointは、 3 3ビットのデータ長を有し、 対 応するプロック DynamicInfoOの情報が有効になる時刻を P T Sによ り示す。 ストリーム毎に先頭となる時刻も、 フィールド pts_change_p ointで示され、 これは、 ファイル" XXXXX.CLP"内で定義される、 上述 したフィ一ルド present at ion— starし timeと等しくなる。
第 2 6図を用いて、 ブロック StaticInfoOの一例の内部構造につい て説明する。 ブロック StaticInfoOは、 対応するエレメンタリストリ ームの種類により内容が Sなる。 対応するエレメン夕リストリームの 種類は、 第 2 5図を用いて説明した、 フィールド stream_idおよびフ ィ一ルド private— stream_idの値に基づき判断できる。 第 2 6図では 、 ブロック StaticInfoOが対応するエレメン夕リストリームの種類が ビデオストリーム、 オーディオストリームおよびサブタイトル （字幕 ) ストリームの何れであるかを、 if構文を用いてそれぞれ記述してい る。 以下、 ブロック StaticInfoOについて、 エレメンタリストリーム 毎に説明する。
エレメン夕リストリームがビデオストリームであった場合、 ブロッ ク StaticInfoOは、 それぞれ 4ビッ卜のデータ長を有するフィールド picture_sizeおよびフィー)レド frame— rate、 1ビッ卜のデ一夕長を有 するフラグ cc_flagからなる。 フィールド picture_sizeおよびフィ一 ルド frame— rateは、 当該ビデオストリームの画像のサイズおよびフレ ーム周波数をそれぞれ示す。 フラグ cc_ agは、 当該ビデオストリー ムがクローズドキャプションを含むか否かを示す。 例えば、 フラグ —flagの値が" 1"で、 当該ビデオストリ一ムがクローズドキヤプショ' ンを含む。 フィーリレド reserved— for— word— al'ignmenUま、 τ "一夕目 置 を 1 6ビットに揃えるために用いられる。
エレメンタリストリ一ムがオーディオストリームであった場合、 ブ 口ック StaticInfoOは、 1 6ビッ卜のデータ長を有するフィ一ルド au d i o_langu age— code、 8ビッ卜のテ一夕 sを有するフィ一ルド channel _conf igurat ion, 1ビッ卜の —タ長を有するフラク 1 fe_exis tence および 4ビットのデータ長を有するフィールド sampl ing_f requencyか らなる。 フィールド audio_language_codeは、 当該オーディオストリ ームに含まれている言語を表すコードを示す。 フィ一ルド channeし co nfigurationは、 モノラル、 ステレオ、 マルチチャンネルなど、 ォー ディォデータのチヤンネル属性を示す。 フィ一ルド lfe— existenceは 、 低域強調チャンネルが含まれているか否かを示し、 .例えば値が " 1" で、 含まれていることを示す。 フィールド sampl ing_frequencyは、 ォ 一ディォデ一夕のサンプリング周波数を示す。 フィールド reserved_f or_word_alignmentは、 データ配置を 1 6ビットに揃えるために用い られる。
エレメン夕リストリームがサブタイトル （字幕） ストリームであつ た場合、 ブロック StaticInfoOは、 1 6ビットのデータ長を有するフ ィールド subt Π le— language_codeおよび 1ビッ卜のテ一夕長を有する フラ ^conf igurable_f lag^らなる。 フィーリレド subti t le_language_c odeは、 当該字幕ストリームに含まれている言語を表すコードを示す 。 フラグ configurable_flagは、 当該字幕ストリームを表示する際に 、 文字の大きさや位置の変更を許可するか否かを示し、 例えば値が" 1"で、 許可することを示す。 フィールド reserved— for— word— al ignme ntは、 データ配置を 1 6ビッ 卜に揃えるために用いられる。
第 2 7図を用いて、 ブロック DynamicInfoOの一例の内部構造につ' いて説明する。 ブロック DynamicInfoOは、 先頭に、 8ビットのデ一 タ長を有するフィールド reserved_for_word_al ignmentが配される。 続く内容は、 対応するエレメン夕リストリームの種類により異なる。 対応するエレメン夕リストリームの種類は、 第 2 5図を用いて説明し た、 フィールド s eam_id.およびフィ一ルド 1" &【6_5 63111—1(1の値に 基づき判断できる。 第 2 7図では、 ブロック DynamicInfoOが対応す るエレメンタリストリームの種類がビデオストリーム、 オーディオス トリームおよびサブタイ トル （字幕） ストリームの何れであるかを、 if構文を用いてそれぞれ記述している。 以下、 ブロック Dynafli Info( )について、 エレメンタリストリ一ム毎に説明する。
エレメン夕リストリームがビデオストリームであった場合、 ブロッ ク DynamicInfoOは、 4ビットのデータ長を有するフィールド display —aspect— ratio力 らなる。 フィーリレド display— aspec t_ratioは、 ヒデ ォの表示出力ァスぺクト比が 1 6 ： 9か 4 ： 3かを示す。 フィ一ルド reserved—for— word— al ignmentは、 テ一タ目 ti置を 1 '6ビッ 卜に删'える ために用いられる。
エレメン夕リストリームがオーディオストリームであった場合、 ブ 口ック DynamicInfoOは、 4ビッ 卜のデータ長を有するフィ一ルド cha nnel_assignment力、らなる。 フィ——リレド channel— ass ignmentは、 当該 オーディオス卜リームが 2チャンネルで構成されている場合に、 出力 がステレオかデュアルモノかを示す。 デュアルモノは、 例えば 2ケ国 語の音声を再生可能とする際に用いられる。 フィールド reserved— for word .al ignmenUま、 データ配置を 1 6ビットに揃えるために用いら れる。
' エレメン夕リストリームが字幕ストリームであった場合、 ブロッ ^
DynamicInfoOは、 データ配置を 1 6ビッ 卜に揃えるために用いられ る、 'フィールド reserved_for— word— al ignmentで構成される。 すなわ ち、 字幕ストリームに関しては、 動的に変化する属性が定義されてい ない。
第 2 8図を用いて、 ブロック EPjnapOの一例の内部構造について説 明する。 ブロック EPjnapOは、 エレメンタリストリーム毎に、 ビット ストリーム内のデコード開始可能位置 （エントリポイント、 あるいは ランダムアクセスポイント（RAP)ともいう） を、 時刻情報と位置情報 とを用いて表したものである。 位置情報は、 例えばエレメン夕リスト リームが記録される記録媒体における、 アクセスの最小単位を用いる ことができる。 各エレメン夕リストリームは、 ブロック EPjnapOで示 された位置からのデコード処理が可能であるものとする。
固定レートのストリームでは、 デコード開始可能位置を計算で求め ることができるので、 このブロック EPjnapOのような情報は、 不要で ある。 一方、 可変レートのストリームや、 MP EG系のビデオの圧縮 符号化方式のようにアクセスュニッ ト毎にデータのサイズが変わるよ うなストリームの場合には、 ランダムアクセスを行うために重要な情 報となる。
ブロック EP— map()は、 先頭に、 配置を 1 6ビットに揃えるために、 8ビッ 卜のァ一夕長を有するフィールド reserve_for_word_al ignment が配される。 続いて、 フィールド number— 0し st ream— id— en triesが配 される。 フィ一リレド number— of_stream— id— entriesiま、 8ビットのデ 一夕長を有し、 このブロック EP— map()に記述されているエレメンタリ ストリームの数を示す。 第 1の forループにより、 フィールド stream id, フィーリレド private— stream— id^3よびフィ——リレド number— of— EP— en tries力、 スィー レド number— of— stream— id— en triesで τ される回数分 だけ、 記述される。 さらに、 第 1の forループの 1回の記述毎に、 第 2の forループにより、 フィ一ルド number— 0し EP_entriesで示される 回数分だけ、 フィ一ルド PTS—EP_s tartおよびフィールド RPN_EP_s tart が配される。
第 1の forループ内において、 最初に、 それぞれ 8ビットのデータ 長を有するフィ一ルド s earn— idおよびフィール private_stream_id が配され、 第 2 5図に一例が示されるようにして、 エレメンタリスト リームを特定している。 次に、 配されるフィールド number_oし EP_ent riesは、 3 2ビットのデ一夕長を有し、 当該エレメン夕リストリーム に対して記述されているエントリポイントの数を示す。 その後、 第 2 の forループにて、 フィ一ルド number— 0し EP_entriesが示す数だけ、 フィールド!^5^?ー51& ぉょびフィ一ルド RPN_EP_startがそれぞれ配 される。
フィールド PTS— EP_startおよびフィールド RPN_EP_startは、 それぞ れ 3 3ビットのデータ長を有し、 エントリポイント自体を表す。 フィ —ルド PTS_EP_startは、 ェントリポイントのクリップ AVストリーム ファイル内での時刻を P T Sで示す。 一方、 フィールド RPN_EP— start は、 エントリポイントのクリップ A Vストリームファイル内での位置 を例えば 2 0 4 8バイト単位で示す。
この実施の一形態においては、 ディスク状のアクセス単位である 1 セクタが 2 0 4 8バイトとされる。 そのため、 エントリポイントのク リップ A Vストリームファイル内での位置は、 フィールド RPN_EP_sta rtにより、 セクタ単位で示されることになる。
ここで、 ビデオストリームの再生開始可能位置の直前には、 必ず、 バケツト private— stream— 2力配される。 このバケツト private— stream —2は、 ビデオストリームをデコードするために利用可能な情報が格 されるパケッ トである。 そのため、 ビデオストリームのエントリポ'ィ ン卜の位置は、 当該バケツ ト private— stream— 2が格納されるパック pa ck()の位置とされる。
ブロック EP_map()は、 上述のようにして、 クリップ AVストリーム 上の時刻と、 クリップ A Vストリームファイル内での位置とを対応付 けている。 これにより、 クリップ AVストリームへのアクセスポイン トの時刻情報 （タイムスタンプ） が与えられたときに、 クリップ AV ストリームファイルの中でデータの読み出しを開始すべきデータァド レスを検索することが容易となり、 ディスクのラン,ダムアクセスをス ムースに行うことができる。
なお、 この実施の一形態では、 ブロック EP—inapOにおいて、 エレメ ン夕リストリーム毎の時刻情報と位置情報との組 （第 2の forループ 内のフィールド PTS_EP_startとフィールド RPN— EP— startとの組） は、 フィールド PTS— EP_startおよび RPN_EP_startの両方に対して昇順 （ま たは降順） に予め並べて登録するようにしている。 換言すれば、 時刻 情報と位置情報とは、 予め所定の方向に並べ替えられている。 このた め、 このままのデータに対して二分木検索を実行することが可能であ る。
なお、 この発明の実施の一形態では、 ビデオのエレメンタリストリ ームは、 MP EG 2—V i d e oの規格に基づくエレメンタリストリ ームであるとして説明したが、 これはこの例に限定されない。 例えば 、 ビデオのエレメン夕リストリームは、 MP EG4—V i s u a 1や 、 MP E G 4— A V Cによるものでもよい。 また、 オーディオのエレ メンタリストリ一ムは、 ATRACオーディオのエレメンタリストリ ームであるとして説明したが、 これもこの例に限らず、 例えば MP E G 1 Z2Z4オーディォにも適用可能である。
7. ディスク再生装置について
次に、 この発明の実施の一形態を適用可能なディスク再生装置につ いて説明する。 第 2 9図は、 この発明を適用可能なディスク再生装置 1 00の一例の構成を概略的に示す。 バス 1 1 1に対して、 CPU(C entral Processing Uni t) 1 1 2、 メモリ 1 1.3、 ドライブイン夕一 フェイス 1 14、 入力インタ一フェイス 1 1 5、 ビデオデコーダ 1 1 6、 オーディオデコーダ 1 1 7、 ビデオ出力インターフェイス 1 1 8 およびオーディォ出カインターフェイス 1 1 9がそれぞれ接続される 。 このディスク再生装置 1 00の各部は、 バス 1 1 1を介してビデオ- ストリーム、 オーディオストリーム、 各種コマンドやデータなどを互 いにやりとりできるようになっている。
ドライブイン夕一フェイス 1 14には、 さらに、 ディスクドライブ 102が接続される。 ディスクドライブ 1 02は、 ドライブインタ一 フェイス 1 14を介してバス 1 1 1とデータやコマンドのやりとりを 行う。
C PU 1 1 2は、 ROM(Read Only Memory)および R AM (Random Access Memory)を有し （図示しない） 、 R〇 Mに予め記憶されたプロ グラムゃデ一夕に従い、 バス 1 1 1を介してこのディスク再生装置 1 00の各部とデータゃコマンドのやりとりを行い、 このディスク再生 装置 1 00の全体を制御する。 RAMは、 C P U 1 1 2のワークメモ リとして用いられる。
なお、 第 29図では省略されているが、 ディスク再生装置 1 00は 、 データの書き換えが可能で、 且つ、 ディスク再生装置 1 00の電源 を OF Fとした後も記憶内容が保持される、 フラッシュメモリなどの 不揮発性メモリを持つことができる。 不揮発性メモリは、 例えばバス
1 1 1に接続され、 C PU 1 1 2による不揮発性メモリに対するデ 夕の書き込みや、 この不揮発性メモリからのデータの読み出しが可能 なようにされている。
入力インターフェイス 1 1 5は、 ユーザにより実際に入力操作が行 われる入力装置からの入力信号が供給される。 入力装置は、 例えば、 赤外線信号などで遠隔的にディスク再生装置 1 00を操作するリモー トコントロールコマンダや、 このディスク再生装置 1 00に直接的に 設けられたキーなどである。 入力インターフェイス 1 1 5は、 これら の入力装置から供給された入力信号を、 CPU 1 1 2に対する制御信 号に変換して出力する。
ディスク 1 0 1は、 第 1 8図以降で説明したようなフォーマツトで 以て、 プレイリスト、 スクリプトプログラム、 クリップインフォメー ションファイル、 クリップ AVストリームファイルなどが記録されて いる。 ディスク 1 0 1がディスクドライブ 1 02に装填されると、 自 動再生またはユーザの入力操作に従いディスク 1 0 1が再生される。 ディスク 1 0 1から読み出されたスクリプトファイルやプレイリスト ファイル、 クリップインフォメーションファイルは、 C PU 1 1 2に 供給され、 例えば CPU 1 1 2が有する RAMに記憶される。 CPU 1 1 2は、 RAMに記憶されたこれらのデ一夕やスクリプトプロダラ ムに基づき、 ディスク 1 0 1からクリップ AVストリームファイルを 読み出す。
ディスク 1 0 1から読み出されたクリップ AVストリームファイル は、 メモリ 1 1 3に一旦格納される。 ビデオデコーダ 1 1 6は、 C P U 1 1 2の命令に基づき、 メモリ 1 1 3に格納されたクリップ A Vス トリームファイルのビデオストリームや字幕ストリームをデコードす る。 デコードされたビデオデータや字幕データは、 例えば C P U 1 1 2によりそれぞれ拡大、 縮小処理などの画像処理を施されると共に、； 合成、 加算処理を施され、 1本のビデオデータとされる。 これらの画 像処理は、 これに限らず、 ビデオデコーダ 1 1 6やビデオ出力イン夕 一フェイス 1 1 8において行うこともできる。 このビデオデータは、 メモリ 1 1 3にバッファリングされ、 ビデオ出カイン夕一フェイス 1 1 8に供給される。 ビデオ出力イン夕一フェイス 1 1 8は、 例えば、 供給されたビデオデータをアナログビデオ信号に変換して、 ビデオ出 力端子 1 2 0に導出する。
同様に、 オーディオデコーダ 1 1 7は、 C P U 1 1 2の命令に基づ き、 メモリ 1 1 3に格納されたクリップ A Vストリームファイルのォ —ディォストリームをデコードする。 デコードされたオーディォデ一 夕は、 メモリ 1 1 3にバッファリングされ、 オーディオ出力イン夕一 フェイス 1 1 9に供給される。 オーディォ出力インターフェイス 1 1 9は、 供給されたオーディオデータを、 例えばアナログオーディオ信 号に変換してオーディォ出力端子 1 2 1に導出する。
なお、 ここでは、 第 2 9図に示される各部がそれぞれ独立したハ一 ドウエアで構成されているように説明したが、 これはこの例に限定さ れない。 例えば、 ビデオデコーダ 1 1 6および またはオーディオデ コーダ 1 1 7は、 C P U 1 1 2上で動作するソフトウェアにより構成 することができる。
また、 上述したディスク再生装置 1 0 0は、 C P U 1. 1 2およびメ モリを備え、 プログラムにより動作するので、 一種のコンピュータ装 置として考えることができる。
第 3 0図 Aおよび第 3 0図 Bは、 第 2 9図に示したディスク再生装 置 1 0 0における動作をより詳細に説明するための機能ブロック図で ある。 ディスク再生装置 1 0 0は、 概略的には、 オペレーションシス テム 2 0 1と、 ビデオコンテンツ再生部 2 1 0とからなる。 ビデオコ ンテンッ再生部 2 1 0は、 実質的には、 オペレーションシステム 2 '0 1上で動作するソフトウェアプログラムである。 これに限らず、 ビデ ォコンテンツ再生部 2 1 0は、 ソフトウェアとハードウェアが統合的 に動作するものとしてもよい。 以下では、 ビデオコンテンツ再生部 2 1 0がソフトウェアであるものとして説明する。 なお、 第 3 0図 Aお よび第 3 0図 Bでは、 ディスクドライブ 1 0 2は、 省略されている。 オペレーションシステム 2 0 1は、 ディスク再生装置 1 0 0に電源 が投入されると C P U 1 1 2において最初に起動し、 各部の初期設定 など必要な処理を行い、 アプリケーションプログラム （ここではビデ ォコンテンツ再生部 2 1 0 ) を R O Mから呼び出す。 オペレーション システム 2 0 1は、 ビデオコンテンツ再生部 2 1 0の動作中に、 ビデ ォコンテンツ再生部 2 1 0に対して、 ディスク 1 0 1からのファイル の読み出しやファイルシステムの解釈といった、 基本的なサービスを 提供する。 例えば、 オペレーションシステム 2 0 1は、 ビデオコンテ ンッ再生部 2 1 0から渡されたファイル読み出しリクエス卜に応じて 、 ドライブイン夕一フェイス 1 1 4を介してディスクドライブ 1 0 2 を制御し、 ディスク 1 0 1に記録されているデータを読み出す。 読み 出されたデータは、 オペレーションシステム 2 0 1の制御により、 ビ デォコンテンツ再生部 2 1 0に渡される。
また、 オペレーションシステム 2 0 1は、 マルチタスク処理機能を 備え、 複数のソフトウェアモジュールを、 例えば時分割制御により見 かけ上並列的に制御することができる。 すなわち、 第 3 0図 A， Bに 一例が示される、 ビデオコンテンツ再生部 2 1 0を構成する各モジュ ールは、 オペレーションシステム 2 0 1のマルチタスク処理機能によ り、 全て、 並列的な動作が可能である。
以下、 ビデオコンテンツ再生部 2 1 0の動作について、 より具体 に説明する。 ビデオコンテンツ再生部 2 1 0は、 内部にさらに幾つか のモジュールを有しており、 下記の機能を実現する。
( 1) 装填されたディスク 1 0 1が UMDビデオの規格に準じたディ スク （以下、 UMDビデオディスクと呼ぶ） であるか否かを判断する
(2) 装填されたディスク 1 0 1が UMDビデオディスクであると判 断した場合、 ディスク 1 0 1からリソースファイルを読み出して、 ス クリプト制御モジュール 2 1 1に渡す。
(3) 装填されたディスク 1 0 1が UMDビデオディスクであると判 断した場合、 さらに、 データベースを構成するファイル （プレイリス トファイル、 クリップインフォメーションファイルなど） を読み出し て、 プレーヤ制御モジュール 2 1 2に渡す。
以下、 ビデオコンテンツ再生部 2 1 0の各モジュールの動作につい て説明する。
スクリプト制御モジュール 2 1 1は、 受け取ったリソースファイル を、 例えば CPU 1 1 2の図示されない RAMの所定領域に記憶する 。 CPU 1 1 2 (スクリプト制御モジュール 2 1 1 ) は、 この RAM に記憶されたスクリプトプログラムを読み込み、 解釈して実行する。 リソースファイルをメモリ 1 1 3の所定領域に記憶させ、 必要に応じ て CPU 1 1 2の図示されない RAMに読み込むようにしてもよい。 プレーヤモデルの説明で既に述べたように、 メニュー画面などの画 像の作成および出力や、 ユーザ入力に応じたカーソル移動、 メニュー 画面の変更といった GU Iは、 スクリプトプログラムによりグラフィ クス処理モジュール 2 1 9を制御することで実現する。 このとき、 メ モリ 1 1 3上のリソースファイルに格納された画像データやサウンド データが用いられ、 メニュー画面などの作成が行われる。 また、 ス リプト制御モジュール 2 1 1は、 スクリプトプログラムの実行により 、 プレーヤ制御モジュール 2 1 2の制御などが可能である。
プレーヤ制御モジュール 2 1 2は、 ディスク 1 0 1から読み出され た、 プレイリストファイル" PLAYL I ST. DAT"や、 クリップインフォメー シヨンフアイル" XXXXX. CLP"といったファイルに格納されたデータべ ース情報を参照して、 ディスク 1 0 1に記録されているビデオコンテ ンッの再生に関わる、 以下のような制御を行う。
( 1 ) プレイリストやクリップインフォメーションといったデータべ ース情報を解析する。
( 2 ) コンテンツデータ供給モジュール 2 1 3、 デコード制御モジュ —ル 2 1 4およびバッファ制御モジュール 2 1 5を制御する。
( 3 ) スクリプト制御モジュール 2 1 1または入力インターフェイス 1 1 5からの指示に従い、 再生、 再生停止、 再生一時停止といったプ レーャの状態遷移制御や、 ストリーム切り替えなどの再生制御処理を 行う。
( 4 ) デコード制御モジュール 2 1 4から、 再生中のビデオストリー ムについて、 時刻情報を取得し、 時刻表示やマークイベントの生成な どを行う。
コンテンツデータ供給モジュール 2 1 3は、 プレーヤ制御モジユー ル 2 1 2の指示に従い、 ディスク 1 0 1からクリップ A Vストリーム ファイルといったコンテンツデータを読み出し、 バッファ制御モジュ —ル 2 1 5に渡す。 バッファ制御モジュール 2 1 5は、 渡されたコン テンッデータをバッファの実体 2 1 5 Aとしてのメモリ 1 1 3に溜め 込む。 コンテンツデータ供給モジュール 2 1 3は、 バッファ制御モジ ユール 2 1 5を制御し、 ビデオデコーダ制御モジュール 2 1 6、 ォー ディォデコーダ制御モジュール 2 1 7および字幕デコーダ制御モジ ^ ール 2 1 8からの要求に従い、 メモリ 1 1 3に溜め込まれたコンテシ ッデ一夕を、 これらのモジュール 2 1 6、 2 1 7および 2 1 8に所定 に供給する。 また、 コンテンツデータ供給モジュール 2 1 3は、 バッ ファ制御モジュール 2 1 5により溜め込まれるコンテンツデータの量 を所定に制御するように、 ディスク 1 0 1からコンテンツデ一夕の読 み込みを仃う。
デコード制御モジュール 2 1 4は、 プレーヤ制御モジュール 2 1 2 の指示に従い、 ビデオデコーダ制御モジュール 2 1 6、 オーディオデ コーダ制御モジュール 2 1 7および字幕デコーダ制御モジュール 2 1 8の動作を制御する。 また、 デコード制御モジュール 2 1 4は、 内部 に時計機能を有し、 ビデオデータとオーディォデ一夕とが同期的に出 力されるように、 各デコーダ制御モジュール 2 1 6 , 2 1 7および 2 1 8の動作を制御する。
バッファ制御モジュール 2 1 5は、 バッファの実体 2 1 5 Aとして 、 メモリ 1 1 3の一部を排他的に用いる。 また、 バッファ制御モジュ ール 2 1 5は、 データ先頭ポインタおよびデータ書き込みポインタを 記憶する。 バッファ制御モジュール 2 1 5は、 さらに、 内部モジユー ルとしてビデオ読み出し機能、 オーディオ読み出し機能および字幕読 み出し機能を有する。 ビデオ読み出し機能の内部には、 ビデオ読み出 しポインタを有する。 また、 ビデオ読み出し機能の内部には、 ァクセ スュニッ卜情報である情報 au_i n f orma t i on ()を蓄積するためのレジス タを備える。 オーディオ読み出し機能の内部には、 オーディオ読み出 しポインタを有する。 字幕読み出し機能の内部には、 字幕読み出しポ ィン夕と字幕読み出し機能フラグとを有する。 字幕読み出し機能フラ グは、 書き込む値に応じて字幕読み出し機能の有効/無効を制御する
。 例えば、 字幕読み出し機能フラグに " 1 "を書き込むと、 字幕読み ώ し機能が有効とされ、 " 0"を書き込むと、 字幕読み出し機能が無効と される。
バッファ制御モジュール 2 1 5の内部モジュールであるビデオ読み 出し機能、 オーディオ読み出し機能および字幕読み出し機能は、 さら に、 ビデオストリーム、 オーディオストリームおよび字幕ストリーム が多重化されたクリップ AVストリームから、 それぞれのストリーム を分離するデマルチプレクサ機能を有する。 この発明の実施の一形態 では、 MPEG 2システムのプログラムストリームの形式で複数のェ レメン夕リストリームが時分割多重されて、 クリップ AVストリーム が形成されている。 したがって、 ビデオ読み出し機能、 オーディオ読 み出し機能および字幕読み出し機能は、 MP E G 2システムのプログ ラムストリームに対するデマルチプレクサ機能を有する。
このため、 ビデオ読み出し機能は、 ストリーム内に所定に配置され るフィールド stream— id (第 2 5図参照） の値を読み取り、 保持する 。 同様に、 オーディオ読み出し機能および字幕読み出し機能は、 フィ 一ルド stream_idおよびフィールド private_stream— id (第 2 5図参照 ) の値を読み取り、 保持する。 これらフィールド stream_idやフィー ルド private_stream— idの値は、 供給されたビットストリームを解析 する際に用いる。
ビデオデコーダ制御モジュール 2 1 6は、 メモリ 1 1 3からビデオ ストリームの単一のビデオアクセスュニットを読み出してビデオデコ —ダ 1 1 6に供給するように、 バッファ制御モジュール 2 1 5内のビ デォ読み出し機能に対して指示を出す。 そして、 ビデオデコーダ制御 モジュール 2 1 6は、 ビデオデコーダ 1 1 6を制御して、 ビデオデコ ーダ 1 1 6に供給されたビデオストリームをアクセスュニット単位で デコードする。 ビデオストリームをデコードして生成されたビデオ 一夕は、 グラフィクス処理モジュール 2 1 9に供給される。 ' 同様に、 オーディオデコーダ制御モジュール 2 1 7は、 メモリ 1 1 3からオーディォストリームの単一のオーディォアクセスュニットを 読み出してオーディオデコーダ 1 1 7に供給するように、 バッファ制 御モジュール 2 1 5内のオーディオ読み出し機能に対して指示を出す 。 なお、 この実施の一形態では、 オーディオストリームを構成するァ クセスユニット （オーディオフレーム） は、 既知の固定長とする。 そ して、 オーディオデコーダ制御モジュール 2 1 7は、 オーディオデコ ーダ 1 1 7を制御して、 オーディオデコーダ 1 1 7に供給されたォ一 ディォストリームをアクセスュニット単位でデコードする。 オーディ ォストリームをデコ一ドして生成されたオーディォデ一夕は、 オーデ ィォ出力モジュール 2 4 2に供給される。
さらに、 字幕デコーダ制御モジュール 2 1 8は、 メモリ 1 1 3から 字幕ストリームの単一の字幕アクセスュニッ小を読み出して字幕デコ —ダ制御モジュール 2 1 8に供給するように、 バッファ制御モジユー ル 2 1 5内の字幕読み出し機能に対して指示を出す。 なお、 この実施 の一形態では、 字幕ストリームを構成する字幕アクセスュニットは、 ユニットの先頭に当該ユニットの長さ情報が格納されている。 字幕デ コーダ制御モジュール 2 1 8は、 字幕デコード機能を有し、 供給され た字幕ストリームをデコ一ドすることができる。 字幕デコーダ制御モ ジュール 2 1 8の字幕デコード機能により字幕ストリームがデコード された字幕の画像データは、 グラフィクス処理モジュール 2 1 9に供 給される。
グラフィクス処理モジュール 2 1 9は、 上述したように、 ビデオデ コーダ制御モジュール 2 1 6の制御に基づきビデオデコーダ 1 1 6で デコードされたビデオデータと、 字幕デコーダ制御モジュール 2 1 8 ' によりデコードされた字幕の画像データとが供給される。 グラフイク ス処理モジュール 2 1 9は、 供給されたこれらビデオデータに対して 字幕の画像データを所定に加算し、 出力するためのビデオ信号を生成 する。 グラフィクス処理モジュール 2 1 9では、 さらに、 スクリプト 制御モジュール 2 1 1やプレーヤ制御モジュール 2 1 2の指示に従い 、 メニュー画像やメッセージ画像を生成し、 出力ビデオ信号に対して 合成 （オーバーレイ） する。
例えば、 グラフィクス処理モジュール 2 1 9は、 供給された字幕の 画像データに対して、 スクリプト制御モジュール 2 1 1からの指示に 従い拡大処理や縮小処理を行い、 ビデオデータに対して所定に加算す る。
また、 グラフィクス処理モジュール 2 1 9は、 予め指定された出力 ビデオデバイスのアスペクトレシオと、 ディスク 1 0 1から再生され たコンテンツ内で指定された出力ァスぺクト.レシオとに基づき、 出力 信号のアスペクト変換を行う。 例えば、 出力ビデオデバイスのァスぺ ク トレシオが 1 6 : 9である場合、 出力ァスぺクトレシオが 1 6 : 9 であれば、 ビデオデータをそのまま出力し、 出力アスペク トレシオが 4 ： 3であれば、 出力されるビデオデータを、 画像の高さが出力ビデ ォデバイスの画面高さに一致するようにスクイーズ （縮小） 処理し、 画像の左右に黒画像を挿入して出力する。 出力ビデオデバイスが 4 ： 3である場合には、 出力アスペクトレシオが 4 ： 3であれば、 ビデオ デ一夕をそのまま出力し、 出力ァスぺクトレシオが 1 6 ： 9であれば 、 出力されるビデオデータを、 画像の幅が出力ビデオデバイスの画面 幅に一致するようにスクイーズ処理し、 画像の上下に黒画像を挿入し て出力する。
グラフィクス処理モジュール 2 1 9は、 さらに、 プレーヤ制御モ ユール 2 1 2からの要求に応じて、 現在処理中のビデオ信号をキヤプ チヤし、 プレーヤ制御モジュール 2 1 2に返すような処理も行う。 ビデオ出力モジュール 2 4 1は、 メモリ 1 1 3の 部を排他的に占 有して F I F 0 (F i rs t I n F i rs t Ou t)のバッファとして用い、 グラフ イクス処理モジュール 2 1 9により処理されたビデオデータをこのバ ッファに一時的に溜め込み、 所定のタイミングで読み出す制御を行う 。 バッファから読み出されたビデオデ一夕は、 ビデオ出力インターフ ェイス 1 1 8から出力される。
オーディォ出力モジュール 2 4 2は、 メモリ 1 1 3の一部を排他的 に占有して F I F Oのバッファとして用い、 オーディオデコーダ 1 1 7から出力されたオーディオデータをこのバッファに溜め込み、 所定 のタイミングで読み出す制御を行う。 バッファから読み出されたォー ディォデ一夕は、 オーディオ出力イン夕一フェイス 1 1 9から出力さ れる。
また、 オーディオ出力モジュール 2 4 2は、 コンテンツのオーディ ォモードがデュアルモノ （例えば 2ケ国語） であった場合、 予め指定 された音声出力モードに従いオーディオデータを出力する。 音声出力 モードが 「主音声」 に指定されている場合、 例えばメモリ 1 1 3にお いて左チャンネルのオーディォデータを右チャンネルにもコピーして 、 2チャンネルの出力を両方とも左チヤンネルのオーディォデータと して出力する。 音声出力モードが 「副音声」 であった場合には、 例え ばメモリ 1 1 3において右チャンネルのオーディオデ一夕を左チャン ネルにもコピーして、 2チャンネルの出力を両方とも右チャンネルの オーディオデ一夕として出力する。 音声出力モードが 「主 '副音声」 である場合や、 コンテンツがステレオである場合には、 オーディオデ —夕をそのまま出力する。 ' このような音声出力モードの設定は、 ビデオコンテンツ再生部 2 '1 0が生成するメニュー画面などにより、 ユーザが対話的に行うことが できるようになつている。
不揮発性メモリ制御モジュール 2 5 0は、 プレーヤ制御モジュール 2 1 2からの指示により、 ビデオコンテンツ再生部 2 1 0が終了して も消去されない領域へのデータの書き込みや、 当該領域からのデータ の読み出しを行う。 タイトル識別 I D (Title— ID)をキーとして、 デー タ Saved_Player_Statusおよびデ一夕 Saved— User— Dataの組を複数件、 当該領域に記憶する機能を有する。 データ Saved_Player_Statusとし て、 プレーヤ制御モジュール 2 1 2の持つデータ Backup_Player_Stat usが記憶される。 このデータ Backup— Player— Statusは、 例えば上述し たプレーヤステータス 3 2 3 Bの、 プレーヤ制御モジュール 2 1 2が 終了する直前のデータに対応し、 デ一夕 SavecLPlayer_Statusは、 リ ジュ一ムインフォメーション 3 24に対応す.る。 また、 データ Saved_ User— Dataとして、 プレーヤ制御モジュール 2 1 2が持つデ一夕 User_ Dataが記憶される。 データ User— Dataは、 ユーザによりプレーヤ制御 モジュール 2 1 2に対して設定された所定のデ一夕である。
不揮発性メモリ制御モジュール 2 5 0は、 ディスク再生装置 1 0 0 が有する不揮発性メモリの所定領域にこれらデータ Saved_Player_Sta tusおよびデータ Saved_User一 Dataの組を、 ディスク 1 0 1のタイトル I Dと関連付けて記憶する。 不揮発性メモリ制御モジュール 2 5 0が データを記憶する記憶媒体は、 不揮発性メモリに限らず、 例えばハー ドディスクなどでもよい。
8. ムービープレーヤの状態遷移モデルについて 8— 1 . ムービープレーヤの状態の定義について
次に、 この発明の実施の一形態によるムービープレーヤ 3 0 0の 態遷移モデルについて、 より詳細に説明する。 この発明では、 ムービ —プレーヤ 3 0 0の状態を、 ムービープレーヤ 3 0 0の内部状態にお いてのみ、 定義する。 すなわち、 この発明では、 ムービープレーヤ 3 0 0の状態を、 ムービープレーヤ 3 0 0それ自身の動作および機能に 基づきそれぞれ定義する。
より具体的には、 動作面において、 プレイリスト再生の観点から、 ム一ビ一プレーヤ 3 0 0がプレイ状態にあるかストップ状態にあるか の 2状態を定義する。 また、 機能面において、 ムービープレーヤ 3 0 0がネイティブ実装プラットフオーム 3 0 1からの制御コマンドを受 け付けるか否かの 2状態を定義する。
第 3 1図は、 この発明によるムービープレーヤ 3 0 0の状態の定義 を概念的に示す。 ムービープレーヤ 3 0 0の動作面から見た^態につ いて説明する。 第 3図も参照し、 ムービープレーヤ 3 0 0は、 プレイ リスト再生の観点から、 プレイ状態およびストップ状態の何れかの状 態にある。 プレイ状態は、 ム一ビープレーヤ 3 0 0がプレイリストを 選択し、 選択されたプレイリストの再生を行っている状態である。 一 方、 ストップ状態は、 ムービープレーヤ 3 0 0がプレイリストを再生 していない状態である。 ストップ状態では、 プレイリストは、 選択さ れていない。 換言すれば、 ムービープレーヤ 3 0 0のプレイバックモ ジュール 3 2 1でクリップ A Vストリームがデコードされている状態 がプレイ状態であって、 デコードされていない状態がストップ状態で あるといえる。
なお、 プレイ状態は、 さらに幾つかの状態に細分化される。 例えば 、 順方向 1倍速の通常再生、 順方向および逆方向への 1倍速以外の再 生速度で再生する変速再生、 一時停止といった、 各種の再生状態をプ レイ状態に含む。 コマ送りおよびコマ戻し再生は、 通常再生と一時停 止とを交互に行うことで実現される。 このような、 プレイリストの再 生中は、 ムービープレーヤ 3 0 0は、 プレイ状態にあることと同義で ある。
ムービープレーヤ 3 0 0の機能面から見た状態について説明する。 ムービープレーヤ 3 0 0は、 機能の観点から、 ネイティブ実装プラッ トフオーム 3 0 1からの制御コマンド 3 1 1を受け付けるモード （ノ —マルモードと呼ぶ） と、 制御コマンド 3 1 1を無視するモード （メ ニューモードと呼ぶ） との 2つの動作モードを有する。 これらムービ 一プレーヤ 3 0 0の 2つの動作モードを、 それぞれムービープレーヤ 3 0 0の状態として定義する。
ノーマルモードは、 ムービープレーヤ 3 0 0の動作を、 スクリプト レイヤ 3 0 2のスクリプトプログラムを介さずに、 ユーザ入力 3 1 0 によって制御することができる。
一方、 メニューモードは、 ムービープレーヤ 3 0 0が制御コマンド 3 1 1を受け付けない。 ムービープレーヤ 3 0 0は、 スクリプトレイ ャ 3 0 2からのメソッド 3 1 3のみを受け付ける。 そのため、 ム一ビ 一プレーヤ 3 0 0の動作を、 スクリプトレイヤ 3 0 2のスクリプトプ ログラムで全て、 制御できる。 例えば、 ユーザ入力 3 1 0は、 ネィテ ィブ実装プラッ トフオーム 3 0 1からのイベント 3 1 4として、 スク リプトレイヤ 3 0 2に渡される。 スクリプトレイヤ 3 0 2のスクリブ トプログラムは、 このイベント 3 1 4に応じたメソッド 3 1 3を用い て、 ムービープレーヤ 3 0 0の動作を制御する。
すなわち、 メニューモードを用いることで、 ムービープレーヤ 3 0 0の動作をコンテンツ制作者側が制御することができる。 また、 メニ ユーモードを利用することで、 少ない種類のキーで多彩な制御を実現 することができる。 ^ このように、 ムービープレーヤ 3 0 0は、 動作面ではプレイ状態'と スドッブ状態の 2状態を有すると共に、 機能面ではノーマルモードと メニューモードの 2つの動作モードを有する。 したがって、 ムービー プレーヤ 3 0 0としては、 これら動作面の 2状態と機能面の 2動作モ 一ドとをそれぞれ組み合わせた、 4状態が定義される。 すなわち、 ム —ビープレーヤ 3 0 0は、 生成されてから消滅するまでの間、 この 4 状態のうち何れかの状態に属する。 ムービープレーヤ 3 0 0の生成お よび消滅については、 後述する。
なお、 ムービープレーヤ 3 0 0に対して現在の状態と異なる状態に 遷移することを指示するメソッド 3 1 3を発行すると、 モデル上では 、 ムービープレーヤ 3 0 0は、 発行されたメソッド 3 1 3に応じて即 座に状態を遷移させる。 実際の機器においては、 ムービープレーヤ 3 0 0に対してあるメソッド 3 1 3を発行してから、 ムービープレーヤ 3 0 0が当該メソッド 3 1 3に応じた状態遷移を完了するまでの時間 は、 当該機器の実装に依存することになる。
また、 ある状態にあるムービープレーヤ 3 0 0に対して、 当該状態 と同一の状態に状態遷移させることを指示するメソッド 3 1 3を発行 しても、 ムービープレーヤ 3 0 0の状態は、 変化しない。 例えば、 既 にノーマルモードで、 且つ、 ストップ状態にあるムービープレーヤ 3 0 0に対して、 ムービープレーヤ 3 0 0の状態をノーマルモードで且 っストップ状態に遷移させるようなメソッド 3 1 3を発行しても、 ム 一ビープレーヤ 3 0 0の状態は、 変化しない。
さらに、 一時停止 （ポーズ） 状態は、 プレイ状態の一種である。 ス トップ状態から一時停止状態に遷移させるためには、 一時停止を指定 する値 pauseModeを引数としたメソッド play 0を用いる。
次に、 ムービープレーヤ 3 0 0の 2状態と 2動作モードとを組み ½ わせた 4状態それぞれの状態と、 4状態間の状態遷移について説明す る。 以下では、 ムービープレーヤ 3 0 0の状態を機能面で分類した状 態のうち、 ノーマルモードを 「normal」 とし、 メニューモードを 「me nuj とする。 また、 ムービープレーヤ 3 0 0の状態を動作面で分類し た状態のうち、 プレイ状態を 「play」 とし、 ストップ状態を 「stop」 とする。 そして、 ムービープレーヤ 3 0 0のモード（mode)および状態 (status)の組み合わせを、 便宜的に、 状態 {mode, status}と表す。 ま た、 以下では、 ムービープレーヤ 3 0 0における状態の変化とモード の切り換えとを、 共に状態遷移と呼ぶ。
第 3 1図からも分かるように、 ムービープレーヤ 3 0 0の状態遷移 は、 自らの状態への遷移も含めると、 4 X4= 1 6通りが存在する。 これらの状態遷移は、 スクリプトレイヤ 3 0 2からムービープレーヤ 3 0 0に渡されるメソッド 3 1 3によって引き起こされる。 すなわち 、 ムービープレーヤ 3 0 0における状態遷移.は、 ムービープレーヤ 3 0 0の外部から引き起こされ、 スクリプトレイヤ 3 0 2からのメソッ ドによる指示無しに、 ムービープレーヤ 3 0 0の内部で自動的に状態 遷移が発生することが無い。 また、 ネイティブ実装プラットフォーム 3 0 1からの制御コマンドでも、 ムービープレーヤ 3 0 0において状 態遷移が発生することが無い。
なお、 この実施の一形態では、 メソッド 3 1 3の引数の組み合わせ に制限があるため、 ムービープレーヤ 3 0 0において可能な 1 6通り の状態遷移の全てをメソッドで発生させることは、 できない。
以下、 ムービープレーヤ 3 0 0が取り得る 4状態 （状態 {Menu, Stop }、 状態 {Normal, Stop}、 状態 {Menu, Play}および状態 {Normal, Play}) について、 それぞれ説明する。 .
( 1 ) 状態 {Menu, Stop}
ムービープレーヤ 3 0 0がプレイリストの再生を行っていないスト ップ状態で、 且つ、 ネイティブ実装プラットフォーム 3 0 1からの制 御コマンド 3 1 1を受け付けない状態である。 この状態は、 例えば背 景に動画が再生されていないメニュー画面などで用いられる。
ムービープレーヤ 3 0 0の生成直後にスクリブトプログラムからの 制御を確実なものとするためには、 その時点でネィティブ実装プラッ トフオーム 3 0 1からの制御コマンド 3 1 1を受け付けないようにす ることが有効である。 そのため、 ムービープレーヤ 3 0 0の生成直後 は、 この状態 {Menu, S t op}になるように定める。
(2) 状態 {Normaし Stop}
ムービープレーヤ 3 0 0がプレイリストの再生を行っていないスト ップ状態で、 且つ、 ネイティブ実装プラッ トフォーム 3 0 1からの制 御コマンド 3 1 1を受け付ける状態である。 この状態は、 例えば動画 を再生していない状態で用いられる。 この状態は、 制御コマンド 3 1 1を受け付けるので、 ムービープレーヤ 3 00の生成直後には用いな いのが好ましい。
(3) 状態 {Menu, Play}
ムービープレーヤ 3 00がプレイリス卜の再生を行っているプレイ 状態で、 且つ、 ネイティブ実装プラットフォーム 3 0 1からの制御コ マンド 3 1 1を受け付けない状態である。 この状態は、 例えば背景に 動画が再生されているメニュー画面などで用いられる。
(4) 状態 {Normal, Play}
ムービープレーヤ 3 0 0がプレイリス卜の再生を行っているプレイ 状態で、 且つ、 ネイティブ実装プラットフォーム 3 0 1からの制御コ マンド 3 1 1を受け付ける状態である。 この状態は、 例えば本編の再 生中などに用いられる。
上述した、 ムービープレーヤ 300が生成される際のモデルについ て、 概略的に説明する。 ムービープレーヤ 300の生成は、 例えば上 述したように、 ディスク再生装置 1 00に電源が投入され、 C PU 1 1 2においてォペレ一ションシステム 20 1が起動されると、 各部の 初期設定など必要な処理を行うと共に、 ビデオコンテンツ再生部 2 1 0を ROMから呼び出す。 このビデオコンテンツ再生部 2 1 0が C P U 1 1 2により実行されることでなされる。 ディスク再生装置 1 00 において電源が OF F状態とされると、 ムービープレーヤ 300が消 滅される。
ここで、 ムービープレーヤ 300は、 喑黙の（i即 licit)オブジェク 卜が生成されているものと見做され、 スクリブトプログラムにおいて 明示的にムービープレーヤ 300の生成を行う必要はない。
上述したように、 ムービープレーヤ 300生成直後の状態は、 メニ ユーモードのストップ状態 （状態 {Menu, Stop}) とされる。 ムービー プレーヤ 300の生成直後では、 例えばムービープレーヤ 300が持 つ下記のプロパティが不定値となる。
プロパティ audi oF lag
プロパティ audioNumber
プロパティ chapterNumber
フロパティ pi ayLi s tNumber
プロパティ pi aySpeed
プロパティ subtitleFlag
プロパティ subti UeNumber
プロノ ティ videoNumber なお、 前回再生を停止された位置から再生を開始する 「続き再生機 能」 を備える UMDビデオプレーヤでは、 ムービープレーヤ 3 0 0 fc> 初期化において、 例えば上述の各プロパティについて、 各プロパティ のデフオルト値ではなく不揮発性メモリに保存された値を用いて値を 設定することができる。 例えば、 リジュームインフォメーション 3 2 4を利用できる。
8— 2. ムービープレーヤに状態遷移を発生させるメソッドについて 次に、 ムービープレーヤ 3 0 0に状態遷移を発生させるメソッド 3 1 3について説明する。 第 32図は、 現在の状態 {Mode, Status}と、 メソッド 3 1 3によって状態遷移した後の状態 {Mode，Status}を、 ム —ビープレーヤ 3 0 0の 4状態のそれぞれについて組み合わせて示す 。 第 3 2図から分かるように、 ムービープレーヤ 3 0 0に対して状態 遷移を発生させるメソッ ド 3 1 3として、 メソッド stop()、 メソッ ド playOおよびメソッド resumeOが用意される。 なお、 メソッ ド resume 0は、 リジュームインフォメーション 3 24が存在するか否かで動作 が変化する。
メソッド stop 0について説明する。 メソッ ド stop 0は、 ムービープ レーャ 3 0 0の状態の如何に関わらず、 ムービープレーヤ 3 0 0をス トップ状態に遷移させる。 メソッド stopOは、 引数にモードを指定す ることができ、 ストップ状態への遷移と同時に、 ムービープレーヤ 3 0 0のモードを変更することができる。 後述するように、 ある条件を 満たしてメソッ ド stop 0が実行されると、 プレーヤステータス 3 2 3 Bがバックアップされ、 リジユームィンフオメーション 3 24として 保持される。
メソッ ド playOについて説明する。 メソッ ド playOは、 ムービープ レーャ 3 0 0をプレイ状態に遷移させる。 メソッ ド playOは、 引数に モードを指定することができ、 プレイ状態への遷移と同時に、 ムービ
—プレーヤ 3 0 0のモードを変更することができる。 後述するよう ('こ 、 ある条件を満たしてメソッド playOが実行されると、 プレーヤステ —タス 3 2 3 Bがバックアップされると共に、 リジユームィンフオメ ーシヨン 3 24が保持される。
メソッド resumeOについて説明する。 メソッド resume 0は、 リジュ ームィンフオメーシヨン 3 24をプレーヤステータス 3 2 3 Bにリス トァして再生復帰させるメソッドである。 すなわち、 メソッ ド resume 0は、 ムービープレーヤ 3 0 0に対して、 リジュームインフォメ一シ ヨン 3 24で示された位置からの再生を開始させる。 リジュームイン フオメーシヨン 3 24が存在しない状態でメソッド resume 0が実行さ れても、 ムービープレーヤ 3 0 0の状態は変化しない。
メソッド resumeOによってリジュームインフォメーション 3 24が リストアされる条件は、 次の通りである。 メソッ ド resumeOが実行さ れた際に、 リジュームインフォメーション 3 24が存在し、 且つ、 現 在の状態が状態 {Normal, Play}でなければ、 ムービープレーヤ 3 0 0 は、 リジュームインフォメーション 3 24をリストアする。 換言すれ ば、 メソッド resumeOが実行された際に、 リジュームインフォメーシ ヨン 3 24が存在し、 且つ、 現在の状態が状態 {Menu, Stop}、 状態 {No rmaし Stop}および状態 {Menu, Play}のうち何れかであれば、 ムービー プレーヤ 3 0 0は、 状態 {Normaし Play}に遷移すると同時に、 リジュ ームインフォメーション 3 24をリストァする。
メソッ ド PlayOは、 複数の引数を持つ。 ここでは、 説明のため、 メ ソッド playOは、 弓 I数 pauseMode、 弓 I数 menuModeおよひ 5l数 playUstN umberの 3種類の引数を持つものとする。 実際には、 さらに多くの引 数が定義される。 引数 pauseModeは、 プレイ状態における再生の状況を指定し、 値 「x 1」 、 値 「pause」 および値 「-1」 の何れかの値を取り得る。 値 「xlj は、 通常速度の順方向再生を指定する。 値 「pause」 は、 一時停止を' 指定する。 値 「- 1」 は、 現状の再生速度を維持するよう指定する。 こ のように、 引数 pauseModeは、 メソッド play 0実行後のムービープレ ーャ 3 0 0のプレイ状態の詳細を設定する。 なお、 一時停止を指定し た場合、 引数で指定される位置のピクチャ、 または引数による指定が ない場合は、 別途定められた選択ルールで指定される位置のピクチャ が表示されて一時停止した状態になる。
引数 menuModeは、 ムービープレーヤ 3 0 0のモード （ノーマルモー ドおよびメニューモード） を指定し、 値 「Normal」 、 値 「Menu」 およ び値 「- 1」 の何れかの値を取り得る。 値 「Normal」 は、 ノーマルモ一 ドへの切り換えを指定する。 値 「Menu」 は、 メニューモードへの切り 換えを指定する。 値 「- 1」 は、 現在のモードを維持するよう指定する 。
引数 playListNumberは、 再生するプレイリストの番号を指定する。 引数 playListNumberは、 省略することができ、 その場合には、 現在選 択しているプレイリス卜のまま変更がないことを表す。
第 3 3図 A、 第 3 3図 B、 第 3 3図 C、 第 3 3図 Dおよび第 3 3図 Eを用いて、 メソッド playOを実行した際のム一ビープレーヤ 3 0 0 の状態遷移の例について説明する。 なお、 第 3 3図 A、 第 3 3図 B、 第 3 3図 (：、 第 3 3図 Dおよび第 3 3図 Eの各図において、 左側は、 ムービープレーヤ 3 0 0の現在の状態 340 Aを示し、 右側は、 現在 の状態 340 Aのムービープレーヤ 3 0 0に対してスクリプトプログ ラムがメソッド 3 1 3を発行することで遷移された遷移後の状態 34 0 Bを示す。 また、 状態 340 Aおよび 340 Bの下に、 その状態に おいて指定されているプレイリスト番号 （P L 1、 P L 2 ) が示され る。
第 33図 Aは、 状態 {Normaし Stop}の状態にあるムービープレーヤ 300に、 メソッ ド play(xl，Normal,PL2)を発行した場合の例である 。 メソッド play(xl，Normal,PL2)に応じて、 ム一ビープレーヤ 300 の状態がプレイリスト番号 「PL 2」 のプレイリストをノーマルモー ド且つ通常速度で再生する状態になることを表している。 ムービープ レーャ 300は、 状態 {Normal, Stop}から状態 {Normal, Play}に状態遷 移している。
第 33図 Bは、 プレイリスト番号 「PL 1」 のプレイリストを再生 中に一時停止している、 状態 {Normal, Play}の状態にあるムービープ レ一ャ 300に、 メソッド play(xl,Normal，PL2)を発行した場合の例 である。 メソッド play(xl, Normal, PL2)に応じて、 ムービープレーヤ 300の状態がプレイリスト番号 「P L 2」 のプレイリストをノーマ ルモード且つ通常速度で再生を開始する状態になることを表している 。 この場合、 ムービープレーヤ 300の再生動作が一時停止から順方 向の通常速度再生に変化するが、 状態は、 メソッド play(xl, Normal, P L2)の発行の前後で状態 {Normal, Play}のままであり、 状態遷移は発生 していない。
第 33図 Cは、 プレイリスト番号 「PL 1」 のプレイリストを順方 向の通常速度で再生中の、 状態 {Normaし Play}の状態にあるム一ビ一 プレーヤ 300に、 メソッド play(-l，- 1,PL2)を発行した場合の例で ある。 メソッド play(-l，- 1，PL2)に応じて、 ム一ビープレーヤ 300 の状態がプレイリスト番号 「PL 2」 のプレイリストをノーマルモ一 ド且つ通常速度で再生する状態になることを表している。 この場合も 、 ムービープレーヤ 300で再生されるプレイリス卜が変更されるが 、 状態は、 状態 {Normal, Play}のままであり、 状態遷移は発生してい ない。
第 3 3図 Dは、 プレイリスト番号 「P L 1」 のプレイリストを順方 向の通常速度で再生中の、 状態 {Normal, Play}の状態にあるムービー プレーヤ 3 0 0に、 メソッド play (pause,- 1，PL2)を発行した場合の例 である。 メソッド play(pause，-l,PL2)に応じて、 ムービープレーヤ 3 0 0は、 プレイリスト番号 「P L 2」 のプレイリストを選択すると共 に、 ノーマルモード且つプレイリスト番号 「P L 2」 のプレイリスト の先頭で一時停止している状態になることを表している。 この場合も 、 ムービープレーヤ 3 0 0の再生動作が順方向の通常速度再生から一 時停止に変化するが、 状態は、 状態 {Normaし Play}のままであり、 状 態遷移は発生していない。
第 3 3図 Eは、 プレイリスト番号 「P L 1」 のプレイリストを再生 中に一時停止している、 状態 {Normal , P 1 ay}の状態にあるム一ビープ レーャ 3 0 0に、 メソッド play (-l，Menu)を発行した場合の例である 。 メソッド playOにおいて、 引数 PlayListNumberが省略されている。 メソッド play(-l，Menu)に応じて、 ムービープレーヤ 3 0 0は、 プレ イリスト番号 「P L 1」 のプレイリストを選択すると共に、 メニュー モード且つプレイリスト番号 「P L 1」 のプレイリス卜の先頭で一時 停止している状態になることを表している。 ムービープレーヤ 3 0 0 は、 状態 {Normaし Play}から状態 {Menu, Stop}に状態遷移している。 . このように、 ムービープレーヤ 3 0 0は、 スクリプトプログラムか らのメソッド PlayOを受けて様々な動作を行い、 その際、 条件によつ ては状態遷移を生じる。 コンテンツ制作者は、 引数を変えたメソッ ド playOをスクリプトプログラムに記述することで、 ムービープレーヤ 3 0 0における様々な動作を実現することができる。 なお、 ムービープレーヤ 3 0 0は、 スクリプトプログラムからメソ ッド p l ay Oを実行することによってのみ、 プレイリスト番号を選択し たプレイリストの再生を開始する。 プレイリストの再生開始とは、 ス トップ状態からプレイリストの再生を開始すること、 あるいは、 ある プレイリストの再生を中断して新たなプレイリス小を選択し、 選択さ れたプレイリス卜の再生を開始することを指す。
スクリプトプログラムがムービープレーヤ 3 0 0に対し、 引数付き のメソッド p l ay Oを発行した際には、 引数の値がプレーヤステータス 3 2 3 Bにセットされる。 省略された引数については、 各パラメ一夕 毎に定められたルールに従い、 デフォルト値や自動選択によって当該 引数の値がセッ 卜される。
また、 コンテンツ制作者の意図しない順序でプレイリストを再生で きてしまっては問題があるため、 ユーザ操作に起因する制御コマンド 3 1 1では、 プレイリスト番号を指定してのプレイリスト再生開始が できないようにされる。 これは、 この発明の実施の一形態によるム一 ビープレーヤ 3 0 0の動作モデルにおける特徴の一つである。
さらに、 メソッド P l ay Oの引数の値として、 無効なプレイリストや 、 存在しない時刻が指定された場合は、 そのメソッ ド p l ay Oの実行は 、 失敗する。 これは、 スクリプトプログラムに誤りがあることを意味 し、 当該スクリプトプログラムが規格違反を含んでいることになる。 このときのエラーハンドリングは、 ムービープレーヤ 3 0 0の実装依 存になる。
ここで、 プレイアイテム間の再生について説明する。 ムービープレ —ャ 3 0 0は、 一旦プレイリストの再生を開始すると、 そのプレイリ ストの最後まで再生を継続する。 1つのプレイリストの先頭から最後 までの再生は、 ユーザ操作や、 スクリプトプログラムからの制御を要 しない。 ムービープレーヤ 3 0 0は、 第 3 4図に概略的に示されるよ うに、 プレイリストを構成するプレイアイテムを、 プレイリストファ ィル" PLAYL I ST. DAT" (第 1 9図参照） で指定された通りに順次、 再生 していく。 プレイリストを構成するプレイアイテムは、 イベントハン ドラによる制御無しで、 連続的に再生される。
プレイアイテムを再生し終えてから次のプレイアイテムを再生する までの間の動作は、 ムービープレーヤ 3 0 0の実装依存であり、 フォ 一マットでは規定しない。 例えば、 プレイアイテムの最後のピクチャ を表示し続けるか、 直ちに黒画面にしてしまうか、 といったプレイァ ィテ厶間の動作は、 実装依存となる。 ただし、 プレイアイテムの I N 点をランダムアクセスボイント （ェントリポイント ：第 2 8図参照） に設定するなどのォ一サリング上の工夫を行うことにより、 プレイァ ィテム間でのギャップ時間ができるだけ短くなるような配慮をする'こ とは、 可能である。
8— 3 . プレイリスト再生中のムービープレーヤの動作について 次に、 プレイリス卜再生中のムービープレーヤ 3 0 0の動作につい て説明する。 例えば 2倍速再生、 3倍速再生といった高速再生や、 1 / 2倍速再生のような低速再生、 また、 逆方向再生などの、 ユーザに よる変速再生指示は、 ユーザ入力 3 1 0としてネイティブ実装プラッ トフオーム 3 0 1に対して入力され、 このユーザ入力 3 1 0に応じて 、 実装に依存した制御コマンド 3 1 1の形でネィティブ実装プラット フォーム 3 0 1からムービープレーヤ 3 0 0に伝えられる。
変速再生時の速度は、 ムービープレーヤ 3 0 0の実装に依存する。 例えば、 速度指定が可能なネイティブ実装プラッ トフオーム 3 0 1の 命令としてムービープレーヤ 3 0 0に伝える、 「より速く」 か 「より 遅く」 を引数としてムービープレーヤ 3 0 0に渡し、 ムービープレー ャ 3 0 0が実現可能な速度に変換する、 などの変速再生の実現方法が 考えられ、 どの方法を用いるかは、 ムービープレーヤ 3 0 0の実装に 依存する。 スクリプトプログラムは、 メソッド getPlayerStatusOに より、 ムービープレーヤ 3 0 0が決めた速度を知ることができる。 一方、 スクリプトプログラムからムービープレーヤ 3 0 0に対する メソッド play 0では、 引数で速度を指定することが出来ない。 メソッ ド playOは、 一時停止 （引数 「pause」 ） および通常速度再生 （引数 「xl」 ) の 2通りのみが指定できる。
ムービープレーヤ 3 0 0は、 プレイリストを順方向で変速再生して いるときにプレイアイテムの終わりに到達した場合、 次のプレイアイ テムの再生を行う。 このとき、 ムービープレーヤ 3 0 0は、 当該次の プレイアイテムを前のプレイアイテムと同じ向き、 同じ速度で再生し 、 変速再生を継続する。
第 3 5図は、 プレイリストの再生中にプレイリストの始点、 終点に 到達したときのム一ビ一プレーヤ 3 0 0の一例の動作を示す。 ム一ビ —プレーヤ 3 0 0は、 順方向で再生中にプレイリス卜の最後に到達し た場合、 最後のピクチャを表示したまま一時停止となる。 最後のピク チヤを消去するには、 ィベントハンドラ onPlayListEndなどの中で、 明示的にムービープレーヤ 3 0 0に対して停止 （メソッド stopO発行 ) を指示する必要がある。
なお、 通常速度よりも高速で再生を行う高速再生時では、 プレイリ ス卜の終点に到達した際に、 プレイリス卜の最後のピクチャが飛び込 み点に該当していなくても、 プレイリス卜の最後のピクチャを表示す る。
一方、 ムービープレーヤ 3 0 0は、 プレイリストを逆方向で再生中 にプレイアイテムの先頭に到達した場合、 前のプレイアイテム、 すな わち、 順方向に再生した場合に時間的に前に再生されるようになって いるプレイアイテムの再生を行う。 この、 前のプレイアイテムの再 ¾ も、 最後から先頭に向かっての逆方向再生を継続する。 再生速度も維 持される。 また、 逆方向再生中にプレイリストの先頭に到達した時に は、 変速再生は解除され、 ムービープレーヤ 3 0 0は、 プレイリスト の先頭で一時停止となる。
さらに、 ムービープレーヤ 3 0 0は、 一時停止を指示する制御コマ ンド 3 1 1によっても、 状態が一時停止に変化する。 制御コマンド 3 1 1で一時停止を解除したときのプレイリストの再生方向、 再生速度 は、 UMDビデオプレーヤの実装依存である。
次に、 プレイリス卜の再生中に発生するイベントについて説明する 。 プレイリスト再生中に発生するイベントには、 第 1 3図を用いて既 に説明したように、 ユーザ操作に応じたイベント angleChange、 ィべ ント audioChangeおよびイベント subtitleChange、 ならびに、 プレイ リスト中に埋め込まれたマークに応じたィベント chapterおよびィベ ント eventマークがある。 また、 イベント発生時の動作の詳細な例は 、 第 1 5図を用いて既に説明されている。
ここでは、 プレイリストの最後での処理について説明する。 既に説 明したように、 ムービープレーヤ 3 0 0は、 メソッド playOによって 指定された番号のプレイリストを再生する。 一旦プレイリストの再生 が開始されると、 スクリプトプログラムや制御コマンド 3 1 1による 制御無しに、 当該プレイリス卜の最後まで、 再生が継続される。 再生 がプレイリストの最後に到達すると、 ムービープレーヤ 3 0 0は、 ィ ベント playUstEndをスクリブトプログラムに通知する。 プレイリス 卜の最後に到達するまでの方法については、 問わない。 すなわち、 プ レイリストの再生が通常再生、 早送り再生、 他プレイリス卜からの飛 び込みによる再生などの如何によらず、 プレイリストの最後に到達し た時点で、 ムービープレーヤ 300は、 イベント playListEndを発^ する。 ' 再生がプレイリス卜の最後に到達し、 ィベント playListEndが発生 されると、 ムービープレーヤ 300の状態が一時停止になり、 ムービ 一プレーヤ 300が内部的に有するプレイリストの再生時刻は、 プレ イリストの最後の時刻に一致している。 なお、 プレイリストの最後の 時刻とは、 プレイリストの最後のピクチャの再生終了時刻で、 再生時 間軸上で最後のプレイアイテムの 0 U T点と一致する。
イベント playListEndは、 プレイリストを一列に再生させる場合や 、 マルチストーリの分岐点でメニューを表示させるためなどに利用で さる。
例えば、 スクリプトプログラムは、 イベント playListEndが発生し たときに実行するプログラムとして、 ィベントハンドラ onPlayListEn dを有していれば、 そのイベントハンドラ onPlayListEndを実行する。 このィベントハンドラ onPlayListEndに、 他のプレイリストの再生を 開始するメソッド playOが記述されていれば、 ムービープレーヤ 30 0は、 他のプレイリストの再生を開始することになる。 このようにし て、 プレイリストの再生が継続される。
第 36図を用いてより具体的に説明すると、 プレイリスト番号 「P L l」 のプレイリストの再生が終了して、 イベント PlayListEndが発 生する。 このイベント playListEndの発生を受けて、 スクリプトプロ グラムが有するイベントハンドラ onPlayListEndが実行される。 この イベントハンドラ onPlayListEndには、 プレイリスト番号 「PL 2」 のプレイリストの再生が指定されている。 ムービープレーヤ 300は 、 このイベントハンドラ onPlayListEndを受けて、 指定されたプレイ リスト番号 「P L 2」 のプレイリストを再生する。
再生パスは、 プレイリスト番号 「PL 1」 のプレイリストの最後 ら一旦ィベントハンドラ onPlayListEndに移り、 さらにプレイリスド 番号 「P L 2」 のプレイリス卜の先頭に移ることになる。
また例えば、 マルチストーリの分岐点でメニューを表示させるよう な場合には、 プレイリストの最後を分岐点とし、 イベント playListEn dに対応するィベントハンドラ onPlayListEndにメニュー画面を表示さ せるプレイリストを再生する指示を記述することが考えられる。
第 37図は、 プレイリストの最後におけるスクリプトレイヤ 302 での処理の流れと、 ムービープレーヤ 30 0の動作の一例をより詳細 に示す。 第 37図において、 ステップ S 30〜ステップ S 33がスク リプトレイヤ 302側の処理を示し、 ステップ S 40〜ステップ S 4 4がムービープレーヤ 300側の処理を示す。
あるプレイリストを最後まで再生した後、 次のプレイリストが再生 されるためには、 スクリプトプログラムによる明示的な再生指示が必 要である。 プレイリストの再生順序は、 スクリプトプログラムで決め られているため、 ムービープレーヤ 300側では次に再生すべきプレ ィリストを自発的に決めることはできない。
再生がプレイリストの最後に到達すると （ステップ S 40) 、 ムー ビープレーヤ 300は、 ィベント playListEndをスクリプトレイヤ 3 02に通知する （ステップ S 4 1) 。 ムービープレーヤ 300は、 ス テツプ S 40で最後まで再生されたプレイリス卜の最後のピクチャを 表示し続けたまま、 一時停止に状態遷移する （ステップ S 42) 。
スクリプトレイヤ 302は、 イベント playListEndを受けて、 ィべ ントハンドラ onPlayListEndが実行される （ステップ S 30) 。 ムー ビ一プレーヤ 300の次の動作は、 このィベントハンドラ onPlayList End内でのスクリブトの記述によって決まる。
なお、 ムービープレーヤ 3 0 0は、 ステップ S 40の後、 プレイリ ス卜の最後で一時停止しているときに一時停止解除あるいは順方向再 生を開始するメソッドゃ制御コマンド 3 1 1を受けても、 無視する。 順方向再生を開始するメソッ ドは、 引数で順方向再生を指示したメソ ッ ド playOおよびメソッド playStepOである。 また、 順方向再生を開 始する制御コマンド 3 1 1としては、 コマンド uo_play()、 コマンド u 0— playNextChapter 0、 コマンド uo_f orwardScan 0、 コマンド uo— play Step()、 コマンド uo— pauseOnOおよびコマンド uo— pauseOf f 0があり 、 これらのコマンドは、 プレイリストの最後で一時停止しているとき には無視される。
プレイリストの最後で一時停止しているときでも、 メソッド stopO やメソッド resumeOは有効である。 また、 モード切替も、 プレイリス 卜の最後の一時停止状態において有効である。
イベント playListEndが発生した後でも、 ノーマルモードのム一ビ —プレーヤ 3 0 0は、 順方向再生を開始する制御コマンド 3 1 1以外 の制御コマンド 3 1 1を受け付ける。 その場合でも、 スクリプトプロ グラムからムービープレーヤ 3 0 0に対してメソッ ド 3 1 3が実行さ れると、 そのメソッド 3 1 3が指示する動作に従う。
第 3 7図の例では、 イベントハンドラ onPlayListEndでメソッド sto P()が指示される （ステップ S 3 1) 。 ムービープレーヤ 3 0 0は、 メソッド stop 0の実行により、 制御コマンド 3 1 1によって引き起こ された動作は中断され、 ストップ状態に遷移する （ステップ S 43) 。 ストップ状態では、 例えば直前まで再生していたプレイリストの最 後のピクチャが消去され、 黒画面となる。
さらに、 スクリプトレイヤ 3 0 2では、 イベントハンドラ onPlayLi stEndにおいて、 次のプレイリストを再生するためのメソッド 3 1 3 が指示される （ステップ S 3 2) 。 例えば、 メソッド playOにおい七 、 引数 pauseModeとして値 「xl」 、 引数 menuModeとして値 「Menu」 お' よび引数 playListNumberとして次に再生するプレイリスト番号がそれ ぞれ指定され、 ムービープレーヤ 3 0 0に対して、 メニューモードに モードを切り換えると共に、 引数 playListNumberで指定された番号の プレイリストを通常速度再生で再生することが指示される。 そして、 スクリプトレイヤ 3 0 2において、 イベントハンドラ onPlayListEnd が終了される （ステップ S 3 3) 。 ムービープレーヤ 3 0 0側では、 ステップ S 3 2で指示されたメソッド playOに応じてモードが切り換 えられると共に、 指定されたプレイリス卜が指定された速度で再生開 始される （ステップ S 44) 。
なお、 コンテンツ制作者は、 ユーザの操作性を高めるため、 プレイ リストの再生が終わった後は、 ム一ビープレーヤ 3 0 0に対して次の 動作を指定せずに、 そのままにしておくべきではない。 イベントハン ドラ01^1& 1^31511(1内に次の動作を記述してぉき、 ムービープレーヤ
3 0 0の状態をストップ状態に遷移させるか、 メソッド play 0で次の プレイリス卜の再生を指示するか、 メニュー画面に戻るようにォーサ リングすべきである。
8— 4. ム一ピ一プレーヤの再生復帰機能について
次に、 ムービープレーヤ 3 0 0の状態遷移と再生復帰機能について 説明する。 先ず、 第 3 8図を用いて、 UMDビデオプレーヤが備える 3種類のメモリ領域について説明する。 UMDビデオプレーヤのモデ ルでは、 必須の 3種類のメモリ領域である、 プレーヤステータス領域 5 0 1、 リジュームインフォメーション領域 5 0 2およびユーザデー 夕領域 5 0 3が定義される。 なお、 これら 3種類のメモリ領域 5 0 1 、 5 0 2および 5 0 3は、 例えばメモリ 1 1 3上に形成される。 C P U 1 1 2のワークメモリとしての RAM上に形成してもよい。
プレーヤステータス領域 5 0 1は、 ムービープレーヤ 3 0 0の再生 状態を表す情報を保持するメモリ領域である。 すなわち、 プレーヤス テ一夕ス領域 5 0 1には、 第 3図におけるプレーヤステータス 3 2 3 Bが保持される。 プレーヤステータス領域 5 0 1の内容は、 スクリブ トプログラム 5 0 0から、 メソッド getPlayerStatusOで読み出すこ とができる。
リジュームインフォメーション領域 5 0 2は、 プレーヤステータス 領域 5 0 1に保持される情報の一部を一時的に退避 （バックアップ） させるためのメモリ領域である。 すなわち、 プレーヤステータス領域 5 0 1の一部の情報は、 第 3図におけるリジュームインフォメ一ショ ン 3 24として、 リジュームインフォメーション領域 5 0 2に保持さ れる。 リジュームインフォメーション領域 5 0 2に退避されたプレー ャステータス領域 5 0 1の一部の情報は、 必要に応じてプレーヤステ —タス領域 5 0 1に復帰される （リストア） 。 これらバックアップお よびリストァは、 ネィティブ実装プラッ トフオーム 3 0 1により行わ れる。 リジユームィンフオメ一ション領域 5 0 2に保持された情報は 、 以前の再生停止箇所から再生を開始する、 リジューム（resume)再生 機能で使用される。
リジユームィンフオメーション領域 5 0 2の内容は、 スクリプトプ ログラム 5 0 0からメソッド getResumelnfoOで読み出すことができ る。 リジュームインフォメーション領域 5 0 2に保持されるリジュー ムインフォメーション 3 24のうち、 ストリームに関係するパラメ一 夕は、 スクリプトプログラム 5 0 0からメソッ ド changeResumelnfoO で値を変更することが可能である。 リジュームインフォメーション領域 5 0 2に保持された情報は、 ネ ィティブ実装プラッ トフオーム 3 0 1により必要に応じて不揮発性メ モリ 5 1 0に書き込まれる（s ave)。 同様に、 リジュームインフォメ丄 シヨン領域 5 0 2から不揮発性メモリ 5 1 0に書き込まれた情報は、 ネィティブ実装プラッ トフオーム 3 0 1により必要に応じて不揮発性 メモリ 5 1 0から読み出されて（l oad)、 リジユームィンフオメ一ショ ン領域 5 0 2に記憶される。
なお、 プレーヤステータス領域 5 0 1からリジュームインフォメー ション領域 5 0 2へのバックアップと、 リジュームインフォメ一ショ ン領域 5 0 2からプレーヤステータス領域 5 0 1へのリストアは、 メ ソッド実行によってムービープレーヤ 3 0 0が特定の状態遷移を行う ことに伴って発生する処理であり、 ムービープレーヤ 3 0 0が自動的 に行う。
ユーザデータ領域 5 0 3は、 コンテンツ依存の情報を保持する領域 であって、 コンテンツ制作者が任意に使用できる。 ムービープレーヤ 3 0 0によるプレイリストの再生経路の履歴、 クイズの正解ノ不正解 など、 コンテンツによって使い方は任意である。
ユーザデ—夕領域 5 0 3に対するデータの書き込みは、 スクリプト プログラム 5 0 0からメソッド se tUs erDa t a Oにより行うことができ る。 ユーザデータ領域 5 0 3の内容は、 スクリプトプログラム 5 0 0 からメソッド ge t UserDa t a Oで読み出すことができる。 ユーザデータ 領域 5 0 3に保持された情報は、 ネィティブ実装プラットフオーム 3 0 1により必要に応じて不揮発性メモリ 5 1 0に書き込まれる（s ave) 。 同様に、 ユーザデータ領域 5 0 3から不揮発性メモリ 5 1 0に書き 込まれた情報は、 ネイティブ実装プラッ トフォーム 3 0 1により必要 に応じて不揮発性メモリ 5 1 0から読み出されて（l oad)、 ユーザデー 夕領域 5 0 3に記憶される。
再生復帰機能を実現するために、 この発明の実施の一形態におい1 Γ 構築した U M Dビデオプレーヤのモデルについて説明する。
先ず、 リジューム動作について、 概略的に説明する。 リジュームィ ンフオメーション領域 5 0 2にバックアップされた情報を用いて再生 状態を復帰させる動作を、 リジューム（resume)と呼ぶ。 リジュームは 、 メソッド resume Oによって行われる。
より具体的には、 プレーヤステータス領域 5 0 1内のプレーヤステ 一夕ス 3 2 3 Bをリジュームインフォメ一ション領域 5 0 2にバック アップしてリジュームインフォメーション 3 2 4とし、 メソッド res u me ()に応じて、 リジユームィンフオメ一ション領域 5 0 2にバックァ ップされたリジユームィンフオメーション 3 2 4を用いて、 再生状態 を復帰させる。 プレーヤステータス 3 2 3 Bは、 ムービープレーヤ 3 0 0の状態、 すなわちムービープレーヤ 3 0 0が現在再生しているプ レイリストの番号、 チヤプ夕番号、 選択されたストリーム番号などか らなる。
ム一ビープレーヤ 3 0 0に対し、 メソッド r es ume Oを発行した時の ムービープレーヤ 3 0 0の動作は、 リジュ一ムィンフオメ一シヨン領 域 5 0 2内にリジユームィンフオメーション 3 2 4が存在するか否か により異なる。 リジュームインフォメーション領域 5 0 2内にリジュ ームインフォメーション 3 2 4が存在するときは、 当該リジュ一ムィ ンフオメーション 3 2 4が、 プレーヤステータス領域 5 0 1にプレ一 ャステータス 3 2 3 Bとしてリストアされる。 このとき、 リジューム インフォメ一ション領域 5 0 2内のリジュームインフォメーション 3 2 4は、 破棄される。
コンテンッ再生中に呼び出したメニューにおいて再生ストリームを 変更する場合は、 メソッド changeResumelnfoOを用いる。 メソッ ド ch angeResumelnfoOでリジュ一ムィンフオメーション領域 5 0 2に保持 されているリジュームインフォメーション 3 24を所定に変更した後 に、 メソッ ド resumeOでリジュームを行えば、 再生ストリームを変更 して再生を始めることができる。
メソッド resume 0を実行することで、 ムービープレーヤ 3 0 0にリ ジュ一ムを行わせることができるが、 メソッ ド getResumelnfoOでリ ジユームインフォメーション 3 24を取得した上で、 引数を指定した メソッド playOを実行することによつても、 リジュ一ムを実現するこ とが可能である。
プレーヤステータス 3 2 3 Bのリジュームインフォメ一ション領域 5 0 2へのバックアップについて、 第 3 9図および第 40図を用いて 説明する。 第 3 9図は、 ムービープレーヤ 3 0 0に定義される 4状態 間の状態遷移のうち、 プレーヤステータス領域 5 0 1に保持されてい るプレーヤステータス 3 2 3 Bがリジュームインフォメ一ション領域 5 0 2にバックアップされる状態遷移を示す。 第 40図は、 プレーヤ ステータス 3 2 3 Bがリジユームィンフオメーション領域 5 0 2にバ ックアツプされるときの条件を示す。
プレイリストを再生している、 ノーマルモードでプレイ状態 （状態 {Normal, lay}) のムービープレーヤ 3 0 0がストップ状態に遷移す ると、 プレーヤステータス領域 5 0 1に保持されているプレーヤステ 一タス 3 2 3 Bがリジュ一ムインフォメ一ション領域 5 0 2にバック アップされ、 リジュームインフォメ一ション 3 24として保持される 。 なお、 ストップ状態では、 プレーヤステータス 3 2 3 Bの一部の値 は、 不定になる。
また、 ムービープレーヤ 3 0 0が状態 {Normaし play}から状態 {Menu ，play}に遷移するときにも、 プレーヤステータス領域 5 0 1に保持さ れているプレーヤステータス 3 2 3 Bがリジュームインフォメーショ ン領域 5 0 2にバックアップされる。
一方、 メニューモードでプレイリストを再生しているムービープレ ーャ 3 0 0が状態遷移をしても、 プレーヤステータス領域 5 0 1に保 持されているプレーヤステータス 3 2 3 Bは、 リジュームインフォメ ーション領域 5 0 2にバックアップされない。
すなわち、 プレーヤステータス 3 2 3 Bがリジュームインフォメ一 ション領域 5 0 2にバックアップされリジュームインフォメーション 3 24とされるのは、 次の場合である。
( 1) ム一ビ一プレーヤ 3 0 0の現在の状態が状態 {Normal, Play}で あり、 メソッ ド play 0の実行により状態 {Menu, Play}に直接的に状態 遷移する場合。
(2) ムービープレーヤ 3 0 0の状態が状態 {Normal, Play}であり、 メソッド stopOの実行により、 状態 {Normal, Stop}あるいは状態 {Menu
，Stop}に状態遷移する場合。 このとき、 メソッ ド stopOの引数 resume
InfoClearFlagは、 値 「false」 である。
プレーヤステータス 3 2 3 Bのリジユームインフォメーション領域
5 0 2への保存 （バックアップ） は、 本編中の戻り位置を保存してお くために使用されることを想定している。 例えば、 本編再生中に動画 メニューに飛び、 再び本編に戻って再生といった一連の動作を実現す る際に、 リジユームインフォメーション領域 5 0 2にプレーヤステ一 タス 3 2 3 Bがバックアップされたデータであるリジュ一ムインフォ メ一ション 3 24が用いられることが想定される。
このため本編再生中、 すなわちムービープレーヤ 3 0 0が状態 {Nor mal, Play}の状態では、 リジュームインフォメーション領域 5 0 2内 のリジュームインフォメーション 3 2 4は、 破棄されている。 ムービ 一プレーヤ 3 0 0が状態 {Norma l , P l ay}の状態からその他の状態に遷 移したときに、 プレーヤステータス 3 2 3 Bがリジュ一ムィンフォ 'メ ーション領域 5 0 2にバックアップされ、 リジユームィンフオメーシ ヨン 3 2 4とされる。
このように、 リジューム再生を実現するため、 ムービープレーヤ 3 0 0の状態遷移に応じて、 プレーヤステータス 3 2 3 Bのリジューム インフォメーション領域 5 0 2へのバックアップと、 リジュームイン フオメ一ション領域 5 0 2内のリジュームインフォメーション 3 2 4 の破棄が適宜、 行われる。 また、 スクリプトレイヤ 3 0 2でメソッド resume Oが指示されたときに、 リジユームィンフオメ一ション領域 5 0 2内にリジュ一ムィンフオメーション 3 2 4が存在すれば、 リジュ —ムインフォメーション 3 2 4は、 プレーヤステータス領域 5 0 1に リストアされ、 プレーヤステータス 3 2 3 Bとされる。
スクリプトレイヤ 3 0 2から、 メソッド ge tResume l n f o Oを用いて 、 リジュ一ムィンフオメ一シヨン領域 5 0 2内のリジユームインフォ メ一シヨン 3 2 4を読み出すことができる。 リジュームインフォメ一 ション領域 5 0 2内のリジュームインフォメーション 3 2 4における 、 ストリームに関係するパラメ一夕は、 メソッ ド changeResume I n f o 0 によって変更することができる。 さらに、 メソッ ド s t op Oの引数で指 定することにより、 リジュームインフォメ一ション領域 5 0 2内のリ ジユームインフォメーション 3 2 4を破棄することができる。
リジユームインフォメ一ション領域 5 0 2に保持されたリジュ一ム インフォメーション 3 2 4のプレーヤステータス領域 5 0 1へのリス トァと、 破棄について、 第 4 1図〜第 4 4図を用いて説明する。 本編 中の戻り位置として保存したリジュームインフォメーション 3 2 4は 、 ムービープレーヤ 3 0 0が本編再生状態、 すなわち状態 {Normal, P1 ay}の状態に戻った後に破棄される。 このとき、 リジュームインフォ メーシヨン 3 24は、 プレーヤステータス領域 5 0 1にプレーヤステ —タス 3 2 3 Bとしてリストァされた後に破棄される場合と、 リスト ァされずに破棄される場合の 2つの場合がある。
すなわち、 このモデルでは、 ムービープレーヤ 3 0 0が状態 {Norma l，Play}の状態に戻ると、 リジュームインフォメーション領域 5 0 2 内のリジュームインフォメーション 3 24が破棄され、 その際に、 ム ービ プレーヤ 3 0 0などが所定の条件を満たしている場合は、 リジ ユームインフォメーション領域 5 0 2内のリジュームインフォメ一シ ヨン 3 24がプレーヤステータス領域 5 0 1にリストァされた後に破 棄されるという特徴を有する。 リジュームインフォメーション 3 24 がプレーヤステータス領域 5 0 1にリストァされる場合には、 リジュ ームィンクオメーシヨン 3 24で指定された箇所からの再生開始とな り、 これがリジューム再生に相当する。
第 4 1図は、 ムービープレーヤ 3 0 0に定義される 4状態間の状態 遷移のうち、 リジュームインフォメーション 3 24がプレーヤステ一 タス領域 5 0 1にリストアされ、 その後に破棄される状態遷移を示す 以下の （ 1 ) 〜 （3) .に記す 3条件が揃った場合に、 リジュームィ ンフオメ一シヨン 3 24がリストァされた後に破棄される。
( 1 ) ムービープレーヤ 3 0 0の現在の状態が状態 {Menu,Stop}、 状 態 {Normaし St op}または状態 {Menu, Play}である。
(2) リジュームインフォメーション 3 24がリジュームインフォメ ーシヨン領域 5 0 2内に存在する。
(3) メソッド resume 0の実行により状態 {Normaし Play}に遷移する 第 42図は、 これらの条件をまとめて示す。 なお、 ムービープレー ャ 3 0 0の状態が状態 {Normal, Play}の場合は、 リジュームインフォ' メーション 3 24が存在しないため、 第 42図中では定義されていな い。
なお、 リジュームインフォメーション領域 5 0 2内にリジ ^ームィ ンフオメ一シヨン 3 24が存在するときにメソッド resume 0が実行さ れると、 ムービープレーヤ 3 0 0の状態は、 状態 {Normal, Play}に遷 移する。 また、 リジュームインフォメーション領域 5 0 2内にリジュ ームインフォメ一ション 3 24が存在しない場合のメソッ ド resumeO は、 ムービープレーヤ 3 ΰ 0の状態を変更しない。 このとき、 メソッ ド resumeO実行直前の状態 {Mode, State}が維持され、 プレーヤステー タス 3 2 3 Bも変更されない。
一方、 以下の （4) 〜 （6) に記す 3条件が揃った場合に、 リジュ ームインフォメーション 3 24がリストァされずに破棄される。
(4) ムービープレーヤ 3 0 0の現在の状態が、 状態 {Menu，Stop}、 状態 {Normal, Stop}または状態 {Menu, PI ay}である。
( 5) リジュームインフォメーション 3 24がリジュームインフォメ ーシヨン領域 5 0 2内に存在する。
(6) PlayOメソッドの実行により、 状態 {Normal, Play}に遷移する 第 43図は、 これらの条件をまとめて示す。 なお、 ムービープレー ャ 3 0 0の状態が状態 {Normaし Play}の場合は、 リジユームィンフォ メーション 3 24がリジュ一ムィンフオメーション領域 5 0 2内に存 在しないため、 第 43図中では定義されていない。
なお、 リジユームインフォメーション 3 24が存在しないときに、 メソッド play 0の実行によりムービープレーヤ 3 0 0の状態が状態 {N ormal,Play}に遷移した場合、 結果として、 リジュームインフォメ一 シヨン 3 24が存在しない状況が保持される。
リジュームインフォメーション領 5 0 2内のリジュームインフォ メーシヨン 3 24の破棄は、 メソッド stopOの引数の設定によっても 発生させることができる。 具体的には、 この発明の実施の一形態では 、 メソッド stopOの引数として、 リジュームインフォメーション領域 5 0 2内のリジュームインフォメーション 3 24の破棄を行うか否か を指定する引数 resumelnfoClearFlagを定義した。 第 44図に示され るように、 メソッ ド stopOの実行時に、 引数 resumelnfoClearFlagに 対して値 「Truej が指定されたときに、 リジュームインフォメ一ショ ン 3 24の破棄が行われる。
例えば、 映画本編を最後まで再生してムービープレーヤ 3 0 0を停 止させた場合は、 映画本編の最後の位置がリジユームィンフオメーシ ヨン 3 24として記録されてしまう。 その後にユーザが再生 （続き再 生） をすると、 映画本編の最後にジャンプして一時停止した状態にな つてしまい、 使い勝手が悪くなる。
これを改善するには、 モデルの定義上、 自動的に記録されてしまう リジュ一ムインフォメ一ション 3 24を破棄する手段が必要になる。 映画本編の最後がどこであるかは、 コンテンツ制作者しか分からない ため、 スクリプトプログラム 50 0からムービープレーヤ 3 0 0に対 するメソッド stopOの引数 resumelnfoClearFlagによって、 リジュ一 ムインフォメーション 3 24の破棄を指定することが出来るようにし た。
第 4 5図は、 メソッ ド stopOの引数 resumelnfoClearFlagを用いた UMDビデオプレーヤの一例の動作を示す。 第 4 5図において、 ステ ップ S 5 0〜ステップ S 54がスクリプトレイヤ 3 0 2側の処理を示 し、 ステップ S 6 0〜ステップ S 64がムービープレーヤ 3 0 0側の 処理を示す。
再生がプレイリストの最後に到達すると （ステップ S 6 0) 、 ムー ビープレーヤ 3 0 0は、 イベント playListEndをスクリプトレイヤ 3 0 2に通知する （ステップ S 6 1 ) 。 ムービープレーヤ 3 0 0は、 ス テツプ S 6 0で最後まで再生されたプレイリス卜の最後のピクチャを 表示し続けたまま、 一時停止に状態遷移する （ステップ S 6 2) 。
スクリプトレイヤ 3 0 2は、 イベント playListEndを受けて、 ィべ ントハンドラ onPlayListEndが実行される （ステップ S 5 0) 。 次の ステツプ S 5 1では、 ィベント playListEndが通知されたプレイリス 卜がォーサシナリォの最後であるか否かが判断される。 あるプレイリ ス卜がシナリオの最後のプレイリストであるか否かは、 例えばスクリ ブトプログラム 5 0 0に基づき判断することができる。
若し、 最後ではないと判断されれば、 処理はステップ S 5 3に移行 し、 メソッド stopOの引数 resumelnfoClearFlagを値 Ffalsej とし、 リジュームインフォメーション 3 24を破棄しないメソッド stop 0を ムービープレーヤ 3 0 0に対して発行する。 ムービープレーヤ 3 0 0 は、 このメソッ ド stopOを受けて、 状態がストップ状態に遷移される と共に、 プレーヤステータス 3 2 3 Bがリジュームインフォメーショ ン領域 5 0 2にバックアップされる。
一方、 スクリプトレイヤ 3 0 2において、 ステップ S 5 1でシナリ ォの最後であると判断されれば、 処理はステップ S 5 2に移行し、 メ ソッド stopOの引数 resumelnfoClearFlagを値 「True」 とし、 リジュ —ムインフォメーション 3 24を破棄するメソッ ド stopOをムービー プレーヤ 3 0 0に対して通知する。 ムービープレーヤ 3 0 0は、 この メソッド stopOを受けて、 状態がストップ状態に遷移されると共に、 リジュームインフォメーション領域 5 0 2内のリジュームインフォメ ーシヨン 3 24が破棄される。
なお、 スクリプトレイヤ 3 0 2において、 ステップ S 5 2の後、 ス クリブトプログラム 5 0 0の記述によっては、 メソッ ド end()が実行 される。
8— 5. 各データのライフサイクルについて
次に、 プレーヤステータス 3 2 3 B、 リジュームインフォメ一ショ ン 3 24およびユーザデータのライフサイクルについて説明する。 第 46図は、 プレーヤステータス 3 2 3 Bの一例のライフサイクル を す。 ムービープレーヤ 3 0 0の生成時に、 プレーヤステータス 3 2 3 Bも生成される。 ムービープレーヤ 3 0 0が消滅すると、 プレー ヤステ一タス 3 2 3 Bも消滅する。 プレーヤステータス 3 2 3 Bは、 生成時に初期化される。 生成時は、 ムービープレーヤ 3 0 0の状態を 表すプロパティは、 停止状態を表し、 それ以外のプロパティは、 不定 となる。 プレーヤステータス 3 2 '3 Bの値は、 ムービープレーヤ 3 0 0における再生状態の変化に伴い変化する。 また、 プレーヤステ一夕 ス 3 2 3 Bの値は、 リジュームインフォメ一ション領域 5 0 2の内容 がリストアされたときに、 変化する。 また、 プレーヤステータス 3 2 3 Bは、 スクリプトレイヤ 3 0 2からのメソッド getPlayerStatusO により読み出すことができる。
なお、 プレーヤステータス 3 2 3 Bをどのような形で記憶するかは 、 ムービープレーヤ 3 0 0の実装に依存する。 スクリプトからメソッ getPlayerStatusOによって情報を得ることができるようになって さえいれば、 どのような形で情報を保持していてもよい。
第 4 7図 Aおよび第 47図 Bは、 リジュームインフォメーション 3 24の一例のライフサイクルを示す。 ムービープレーヤ 3 0 0生成時 にリジユームインフォメーションのメモリ領域が確保され、 リジユー ムインフォメーション 3 24の生成と共に初期化が行われる。 初期化 されると、 リジュームインフォメーション 3 24の内容は、 破棄され る。 不揮発性メモリを実装している UMDビデオプレーヤは、 ムービ —プレーヤ 3 0 0を初期化する際に、 リジユームインフォメーション
3 24を不揮発性メモリからロード（load)する。 このとき、 ユーザデ 一夕の口一ドも同時に行われる。
ムービープレーヤ 3 0 0の状態が状態 {Normaし Play}からその他の 状態に遷移したとき、 プレーヤステータス 3 2 3 Bは、 リジュームィ ンフオメ一ション領域 5 0 2にバックアップされる。
リジュームインフォメーション 3 24におけるストリ一ムに関係す るノ ラメ一夕 videoNumber、 audioNumber, audioFlag、 subt i t leNumbe rおよび subUtleFlagは、 スクリプトレイヤ 3 0 2からのメソッド cha ngeResumelnfoOによって変更することができる。
ムービープレーヤ 3 0 0において、 ノーマルモードでのプレイリス 卜再生が開始されたとき、 リジユームインフォメーション 3 24の内 容は、 破棄される。 このとき、 破棄に先立ってリジュームインフォメ ーシヨン 3 24のプレーヤステータス 3 2 3 Bへのリストァが行われ る場合と行われない場合とがある。 また、 引数 resumelnfoClearFlag の値が 「True」 とされた stopOメソッドが実行されたときに、 リジュ —ムインフォメーション 3 24の内容は破棄される。
リジュームインフォメーション 3 24が存在するときに、 メソッ ド resumeOが実行されると、 リジユームィンフオメ一ション 3 24のプ レーヤステ一タス 3 2 3 Bへのリストアが行われる。
スクリプトレイヤ 3 0 2から、 メソッド getResumelnfoOにより、 リジュームインフォメーション 3 24の値を読み出すことができる。 破棄された状態のリジユームインフォメーション 3 24を読み出す—と 、 返値 playStatusとして値 「0」 が戻るため、 リジュームインフォ'メ ーシヨン 3 24の有無を区別することが出来る。
ムービープレーヤ 3 0 0が終了 （消滅） するときに、 リジュームィ ンフオメーシヨン 3 24も消滅する。 不揮発メモリを実装している U MDビデオプレーヤは、 ムービープレーヤ 3 0 0が終了 （消滅） する 際に、 リジユームィンフオメーション 3 24を不揮発性メモリにセ一 ブする。 そのとき、 ユーザデータのセーブも同時に行われる。
第 48図は.、 ユーザデータの一例のライフサイクルを示す。 ムービ —プレーヤ 3 0 0の生成時にメモリ領域が確保され、 ユーザデータが 生成される。 生成と同時に初期化が行われる。 初期化されると、 ユー ザデ一夕の内容はクリアされる（メソッド getUserDataOで、 長さ 「0 」 の配列が返る）。 不揮発メモリを実装している UMDビデオプレー ャは、 ムービープレーヤ 3 0 0の初期化の際に、 ユーザデータを不揮 発性メモリからロードする。 このとき、 リジュームインフォメ一ショ ンのロードも同時に行われる。
メソッ ド setUserDataOが実行されたときに、 ユーザデータ領域 5 0 3にユーザデ一夕が書き込まれる。 メソッ ド setUserDataOにより 、 最大でデータ長が 64ビッ トの I n t型の配列がユーザデータ領域 5 0 3に保持される。 ユーザデータ領域 5 0 3のデータは、 スクリブ トレイヤ.3 0 2からのメソッド getUserDataOで読み出すことができ る。 ユーザデータがセットされていないときは、 長さが 0の配列が返 る。
スクリプトレイヤ 3 0 2からユーザデータ領域 5 0 3の内容をクリ ァするメソッ ドは、 無い。 ユーザデ一夕領域 5 0 3に対する上書きに より、 内容を書き換えることができる。
ムービープレーヤ 3 0 0が終了 （消滅） するときに、 ユーザデー 領域 5 0 3も消滅する。 不揮発性メモリを実装している UMDビデオ プレーヤは、 ムービープレーヤ 3 0 0が終了 （消滅） する際に、 ユー ザデータ領域 5 0 3の保持されているデータを不揮発性メモリにセー ブする。 このとき、 リジュームインフォメーション 3 24のセーブも 同時に行われる。
なお、 上述では、 この発明がオーディオストリームおよびビデオス トリームを共に処理するようなディスク再生装置 1 0 0に適用される ように説明したが、 これはこの例に限定されない。 例えば、 オーディ ォストリームのみ、 ビデオストリームのみを再生する場合にも、 この 発明を適用することができる。
また、 上述では、 コンテンツデ一夕が記録される記録媒体として、 ディスク上記録媒体を用いるように説明したが、 これはこの例に限定 されない。 例えば、 コンテンツデータが記録される記録媒体として、 半導体メモリを用いることができる。
さらに、 上述では、 この発明が適用されるディスク再生装置 1 0 0 が専用的なハードウエアで構成されるように説明したが、 これはこの 例に限定されない。 すなわち、 ディスク再生装置 1 0 0のディスクド ライブ以外の構成は、 コンピュータ装置上で動作するソフトウェアに よっても実現することができる。 この場合、 ディスク再生装置 1 0 0 を実現するソフトウェアは、 CD— R〇M(Compact Disc-Read Only Memory)や D VD— R〇M (Digi tal Versatile Disc-ROM)といった記 録媒体に記録されて供給することができる。 ディスク再生装置 1 0 0 を実現するためのソフトウェアが記録された記録媒体を、 コンピュー 夕装置のディスクドライブに装填し、 記録媒体に記録された当該ソフ トウエアをコンピュータ装置にインストールする。 コンピュータ装置 に対して、 UMDに対応したディスクドライブ装置を接続することで 、 この発明によるディスク再生装置 1 00と同等の構成が実現できる 。 UMDビデオのコンテンツを記録した記録媒体に、 当該ソフトゥェ ァを共に記録して提供することも考えられる。

Claims

請 求 の 範 囲
1 . 記録媒体に記録されたコンテンツデ一夕を再生する再生装置 お いて、
少なくともビデオストリームおよびオーディォストリームのうち何 れか一方を含むコンテンツデ一夕と、 該コンテンツデータの再生を制 御する再生制御プログラムとが記録された記録媒体からデータを読み 出す読み出し手段と、
上記再生制御プログラムに従い上記コンテンツデータを再生するプ レーャ手段と、
上記プレーヤ手段に対してユーザ操作に応じた制御コマンドを与え る制御コマンド出力手段と
を備え、
上記プレーヤ手段は、 上記コンテンツデータを再生しているか否か で分類される 2状態と、 上記制御コマンド出力手段からの制御コマン ドを受け付けるか否かで分類される 2状態との組み合わせにより定義 される 4状態に基づき上記コンテンツデータの再生を制御するように したことを特徴とする再生装置。
2 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段の上記 4状態間の状態遷移は、 上記再生制御プロ グラムによって発生されるようにしたことを特徴とする再生装置。
3 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段の上記 4状態間の状態遷移は、 上記制御コマンド によって発生させないようにしたことを特徴とする再生装置。
4 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段の上記 4状態間の状態遷移は、 上記プレーヤ手段 により自発的に ¾生しないようにしたことを特徴とする再生装置。
5 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段は、 初期化直後には、 上記コンテンツデ一夕 再 生していない状態で、 且つ、 上記制御コマンド出力手段からの上記制 御コマンドを受け付けない状態になるようにしたことを特徴とする再 生装置。
6 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段で再生中の上記コンテンツデータの状態を示す再 生状態情報を記憶する第 1の記憶手段と、
上記第 1の記億手段に記憶された上記再生状態情報がバックアップ される第 2の記憶手段と
をさらに有し、
上記第 1の記憶手段に記憶された上記再生状態情報の上記第 2の記 憶手段へのバックアツプおよび上記第 2の記憶手段にバックアップさ れた上記再生状態情報の上記第 1の記憶手段へのリストァは、 上記プ レーャ手段の上記 4状態間での状態遷移に伴い行われることを特徴と する再生装置。
7 . 請求の範囲 6に記載の再生装置において、
上記バックアップは、 上記プレーヤ手段が上記制御コマンドを受け 付ける状態且つ上記コンテンツデータを再生している状態から、 他の 状態へ遷移するときに行われることを特徴とする再生装置。
8 . 請求の範囲 6に記載の再生装置において、
上記リストァは、 上記プレーヤ手段の状態が上記制御コマンドを受 け付ける状態且つ上記コンテンツデ一夕を再生している状態に遷移す るときに行われることを特徴とする再生装置。
9 . 請求の範囲 6に記載の再生装置において、
上記リストアが、 上記再生制御プログラムによる、 上記第 2の記憶 手段にバックアツプされた上記再生状態情報を用いて上記コンテンツ デ一夕の再生を復帰する命令に基づく上記状態遷移に伴い行われ と きは、 上記リストァ後に上記第 2の記憶手段にバックアップされてい る上記再生状態情報を破棄するようにしたことを特徴とする再生装置
1 0 . 請求の範囲 6に記載の再生装置において、
上記再生制御プログラムによる上記コンテンツデータの再生を行う 命令に基づき上記プレーヤ手段の状態が、 上記制御コマンドを受け付 ける状態且つ上記コンテンツデ一夕を再生している状態に遷移すると きは、 上記第 2の記憶手段にバックアップされている上記再生状態情 報を破棄するようにしたことを特徴とする再生装置。
1 1 . 請求の範囲 6に記載の再生装置において、
上記再生制御プログラムから上記プレーヤ手段に対して渡される、 上記コンテンッの再生を停止させる命令に、 上記第 2の記憶手段にバ ックアップされている上記再生状態情報を破棄するか否かを示す情報 を付加するようにしたことを特徴とする再生装置。
1 2 . 記録媒体に記録されたコンテンツデータを再生する再生方法に おいて、
少なくともビデオストリームおよびオーディォストリームのうち何 れか一方を含むコンテンツデータと、 該コンテンツデータの再生を制 御する再生制御プログラムとが記録された記録媒体から読み出された 上記再生制御プログラムに従いプレーヤ手段でなされる上記コンテン ッデ一夕の再生を、
上記プレーヤ手段の、 上記コンテンツデータを再生しているか否か で分類される 2状態と、 ユーザ操作に応じた制御コマンドを受け付け るか否かで分類される 2状態との組み合わせにより定義される 4状態 に基づき制御するようにしたことを特徴とする再生方法。
1 3 . 記録媒体に記録されたコンテンツデータを再生する再生方 を コンピュータ装置に実行させる再生プログラムにおいて、
上記再生方法は、
少なくともビデオストリームおよびオーディォストリームのうち何 れか一方を含むコンテンツデータと、 該コンテンッデータの再生を制 御する再生制御プログラムとが記録された記録媒体から読み出された 上記再生制御プログラムに従いプレーヤ手段でなされる上記コンテン ッデ一夕の再生を、
上記プレーヤ手段の、 上記コンテンツデータを再生しているか否か で分類される 2状態と、 ユーザ操作に応じた制御コマンドを受け付け るか否かで分類される 2状態との組み合わせにより定義される 4状態 に基づき制御するようにしたことを特徴とする再生プログラム。
1 4 . 記録媒体に記録されたコンテンツデ一夕を再生する再生方法を コンピュータ装置に実行させる再生プログラムが記録されたコンビュ 一夕装置に読み取り可能な記録媒体において、
上記再生方法は、
少なくともビデオストリームおよびオーディォストリームのうち何 れか一方を含むコンテンツデータと、 該コンテンッデータの再生を制 御する再生制御プログラムとが記録された記録媒体から読み出された 上記再生制御プログラムに従いプレーヤ手段でなされる上記コンテン ッデータの再生を、
上記プレーヤ手段の、 上記コンテンツデータを再生しているか否か で分類される 2状態と、 ユーザ操作に応じた制御コマンドを受け付け るか否かで分類される 2状態との組み合わせにより定義される 4状態 に基づき制御するようにしたことを特徴とするコンピュータ装置に読 み取り可能な記録媒体。
1 5 . 少なくともビデオストリームおよびオーディオストリームめう ち何れか一方を含むコンテンツデ一夕と、 該コンテンッデ一夕の再生 をプレーヤ手段に制御ざせる再生制御プログラムとが記録された、 コ ンピュー夕装置に読み取り可能な記録媒体であって、
上記再生制御プログラムは、
上記コンテンツデータを再生しているか否かで分類される 2状態と 、 ユーザ操作に応じた制御コマンドを受け付けるか否かで分類される 2状態との組み合わせにより定義される 4状態に基づき上記コンテン ッデ一夕の再生を制御する上記プレーヤ手段に対して再生制御命令を 与えて上記コンテンッの再生を制御させるようにしたことを特徴とす るコンピュータ装置に読み取り可能な記録媒体。
1 6 . 請求の範囲 1 5に記載の記録媒体において、
上記再生制御プログラムは、 上記プレーヤ手段に対して上記 4状態 間の状態遷移を発生させるようにしたことを特徴とするコンピュータ 装置に読み取り可能な記録媒体。
1 7 . 請求の範囲 1 5に記載の記録媒体において、
上記再生制御プログラムは、
再生中の上記コンテンツデータの状態を示す再生状態情報を記憶す る第 1の記憶手段に記憶された上記再生状態情報の、 上記第 1の記憶 手段に記憶された上記再生状態情報がバックアツプされる第 2の記憶 手段へのバックアツプおよび上記第 2の記憶手段にバックアップされ た上記再生状態情報の上記第 1の記憶手段へのリストァが上記プレー ャ手段の上記 4状態間での状態遷移に伴い行われるようにされた上記 プレーヤ手段に対して渡される、 上記コンテンツの再生を停止させる 命令に、 上記第 2の記憶手段にバックアップされている上記再生状態 情報を破棄するか否かを示す情報を付加する
ようにしたことを特徵とするコンピュータ装置に読み取り可能な詁録 媒体。
1 8 . 少なくともビデオストリームおよびオーディオストリ一ムのう ち何れか一方を含むコンテンツデ一夕と、 該コンテンツデータの再生 をプレーヤ手段に制御させる再生制御プログラムと
を含むデータ構造体であって、
上記再生制御プログラムは、
上記コンテンッデ一夕を再生しているか否かで分類される 2状態と 、 ユーザ操作に応じた制御コマンドを受け付けるか否かで分類される 2状態との組み合わせにより定義される 4状態に基づき上記コンテン ッデ一夕の再生を制御する上記プレーヤ手段に対して再生制御命令を 与えて上記コンテンツの再生を制御させることを特徴とするデータ構 造体。
1 9 . 記録媒体に記録されたコンテンツデータを再生する再生装置に おいて、
少なくともビデオストリームおよびオーディォストリームのうち何 れか一方を含むコンテンツデータと、 該コンテンッデータの再生を制 御する再生制御プログラムとが記録された記録媒体からデータを読み 出す読み出し部と、
上記再生制御プログラムに従い上記コンテンッデータを再生するプ レーャ部と、
上記プレーヤ部に対してユーザ操作に応じた制御コマンドを与える 制御コマンド出力部と
を備え、
上記プレーヤ部は、 上記コンテンッデータを再生しているか否かで 分類される 2状態と、 上記制御コマンド出力部からの制御コマンドを 受け付けるか否かで分類される 2状態との組み合わせにより定義きれ る 4状態に基づき上記コンテンッデータの再生を制御するようにした ことを特徴とする再生装置。
PCT/JP2005/021075 2004-12-02 2005-11-10 再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体 WO2006059483A1 (ja)

Priority Applications (10)

Application Number Priority Date Filing Date Title
PL05806735T PL1818932T3 (pl) 2004-12-02 2005-11-10 Archiwizowanie programu zawartego na DVD obejmujące 4 stany sterowania urządzenia odtwarzającego, i skrypt sterujący
CN2005800476765A CN101111895B (zh) 2004-12-02 2005-11-10 再现装置和再现方法
MX2007006428A MX2007006428A (es) 2004-12-02 2005-11-10 Aparato de reproduccion, metodo de reproduccion, programa de reproduccion, medio de registro, y estructura de datos.
KR1020077012539A KR101235466B1 (ko) 2004-12-02 2005-11-10 재생 장치, 재생 방법, 기록 매체 및, 데이터 구조체를 기록한 컴퓨터 판독가능한 기록 매체
DE602005024163T DE602005024163D1 (de) 2004-12-02 2005-11-10 Sicherheitskopie von einem DVD Inhalt-Program, dass 4 Kontrol-Zustände von Wiedergabe-Geräte beinhaltet, und Kontrol_Skript.
AT05806735T ATE484828T1 (de) 2004-12-02 2005-11-10 Sicherheitskopie von einem dvd inhalt-program, dass 4 kontrol-zustände von wiedergabe-geräte beinhaltet, und kontrol_skript.
US11/720,609 US8369683B2 (en) 2004-12-02 2005-11-10 Reproducing apparatus, reproducing method, reproducing program, recording medium, and data structure
EP05806735A EP1818932B1 (en) 2004-12-02 2005-11-10 Backup of a DVD content program including 4 control states of the reproducing device, and control script.
AU2005310796A AU2005310796B2 (en) 2004-12-02 2005-11-10 Reproducing apparatus, reproducing method, reproducing program, recording medium, and data structure
HK07111620.8A HK1106317A1 (en) 2004-12-02 2007-10-26 Backup of a dvd content program including 4 control states of the reproducing device, and control script.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004-350193 2004-12-02
JP2004350193A JP4879480B2 (ja) 2004-12-02 2004-12-02 再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体

Publications (1)

Publication Number Publication Date
WO2006059483A1 true WO2006059483A1 (ja) 2006-06-08

Family

ID=36564918

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/021075 WO2006059483A1 (ja) 2004-12-02 2005-11-10 再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体

Country Status (14)

Country Link
US (1) US8369683B2 (ja)
EP (1) EP1818932B1 (ja)
JP (1) JP4879480B2 (ja)
KR (1) KR101235466B1 (ja)
CN (1) CN101111895B (ja)
AT (1) ATE484828T1 (ja)
AU (1) AU2005310796B2 (ja)
DE (1) DE602005024163D1 (ja)
ES (1) ES2354368T3 (ja)
HK (1) HK1106317A1 (ja)
MX (1) MX2007006428A (ja)
PL (1) PL1818932T3 (ja)
TW (1) TW200639811A (ja)
WO (1) WO2006059483A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110200299A1 (en) * 2008-11-13 2011-08-18 Yohei Kitahara Reproduction device and reproduction method

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001093226A (ja) 1999-09-21 2001-04-06 Sony Corp 情報通信システムおよび方法、ならびに、情報通信装置および方法
WO2008068960A1 (ja) * 2006-12-05 2008-06-12 Sharp Kabushiki Kaisha コンテンツの再生制御を行なう再生装置、制御プログラム、記録媒体および制御方法
US9977721B2 (en) 2007-12-20 2018-05-22 Netapp, Inc. Evaluating and predicting computer system performance using kneepoint analysis
US8805647B2 (en) * 2007-12-20 2014-08-12 Netapp, Inc. Evaluating and predicting computer system performance using kneepoint analysis
RU2518189C2 (ru) * 2008-06-26 2014-06-10 Панасоник Корпорэйшн Носитель записи, устройство воспроизведения, устройство записи, способ воспроизведения, способ записи и программа
US8699338B2 (en) 2008-08-29 2014-04-15 Nxp B.V. Signal processing arrangement and method with adaptable signal reproduction rate
JP4543107B2 (ja) * 2008-08-29 2010-09-15 株式会社東芝 映像音声再生装置および映像音声再生方法
US8634707B2 (en) 2008-10-24 2014-01-21 Panasonic Corporation BD playback system, BD playback device, display device, and computer program
WO2010050050A1 (ja) * 2008-10-31 2010-05-06 パイオニア株式会社 記録媒体再生装置、記録媒体再生方法、記録媒体再生プログラムおよび記録媒体再生プログラムを格納した記録媒体
WO2010050051A1 (ja) * 2008-10-31 2010-05-06 パイオニア株式会社 記録媒体再生装置、記録媒体再生方法、記録媒体再生プログラムおよび記録媒体再生プログラムを格納した記録媒体
IT1399311B1 (it) * 2010-04-07 2013-04-16 Magneti Marelli Spa Metodo per determinare l'istante di chiusura di un iniettore elettromagnetico di carburante
JP5488180B2 (ja) 2010-04-30 2014-05-14 ソニー株式会社 コンテンツ再生装置、制御情報提供サーバ、及びコンテンツ再生システム
EP2416318B1 (en) * 2010-08-04 2016-10-12 Nero Ag Multi-language buffering during media playback
WO2013022281A2 (ko) * 2011-08-09 2013-02-14 삼성전자 주식회사 다시점 비디오 예측 부호화 방법 및 그 장치, 다시점 비디오 예측 복호화 방법 및 그 장치
JP5194160B1 (ja) * 2011-10-19 2013-05-08 東芝テック株式会社 情報処理装置、情報処理方法及びプログラム
US9344755B2 (en) 2013-09-30 2016-05-17 Sonos, Inc. Fast-resume audio playback
EP2866107B1 (de) 2013-10-25 2020-12-09 Siemens Aktiengesellschaft Verfahren zum Wiedergeben des Ablaufs eines Programms eines Automatisierungsgerätes
CN106341730B (zh) * 2015-07-14 2019-06-07 北京国双科技有限公司 多媒体状态的识别方法、装置及系统
CN105472456B (zh) * 2015-11-27 2019-05-10 北京奇艺世纪科技有限公司 一种视频播放方法及装置
CN105430509B (zh) * 2015-11-27 2018-10-30 北京奇艺世纪科技有限公司 一种多媒体文件播放方法及装置
CN105657518A (zh) * 2016-02-04 2016-06-08 厦门幻世网络科技有限公司 一种播放动画的方法及装置
US11342002B1 (en) * 2018-12-05 2022-05-24 Amazon Technologies, Inc. Caption timestamp predictor

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10271454A (ja) 1997-03-20 1998-10-09 Sony Corp データ再生装置及びデータ再生方法
US20030161615A1 (en) 2002-02-26 2003-08-28 Kabushiki Kaisha Toshiba Enhanced navigation system using digital information medium
JP2004328450A (ja) * 2003-04-25 2004-11-18 Sony Corp 再生装置、再生方法、再生プログラムおよび記録媒体

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101023699B1 (ko) * 2002-12-05 2011-03-25 엘지전자 주식회사 대화형 광디스크 장치에서의 재생 제어방법
CA2497697C (en) * 2002-09-12 2013-07-09 Matsushita Electric Industrial Co., Ltd. Recording medium, playback device, program, playback method, and recording method
JP3858151B2 (ja) 2002-10-01 2006-12-13 パイオニア株式会社 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10271454A (ja) 1997-03-20 1998-10-09 Sony Corp データ再生装置及びデータ再生方法
US20030161615A1 (en) 2002-02-26 2003-08-28 Kabushiki Kaisha Toshiba Enhanced navigation system using digital information medium
JP2004328450A (ja) * 2003-04-25 2004-11-18 Sony Corp 再生装置、再生方法、再生プログラムおよび記録媒体

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110200299A1 (en) * 2008-11-13 2011-08-18 Yohei Kitahara Reproduction device and reproduction method
US8737806B2 (en) * 2008-11-13 2014-05-27 Mitsubishi Electric Corporation Reproduction device and reproduction method

Also Published As

Publication number Publication date
CN101111895A (zh) 2008-01-23
DE602005024163D1 (de) 2010-11-25
JP2006164328A (ja) 2006-06-22
AU2005310796A1 (en) 2006-06-08
ES2354368T3 (es) 2011-03-14
ATE484828T1 (de) 2010-10-15
KR20070085697A (ko) 2007-08-27
EP1818932A1 (en) 2007-08-15
US8369683B2 (en) 2013-02-05
JP4879480B2 (ja) 2012-02-22
TWI328801B (ja) 2010-08-11
PL1818932T3 (pl) 2011-05-31
EP1818932B1 (en) 2010-10-13
US20090279867A1 (en) 2009-11-12
MX2007006428A (es) 2007-07-20
KR101235466B1 (ko) 2013-02-20
AU2005310796B2 (en) 2011-03-10
EP1818932A4 (en) 2008-03-19
CN101111895B (zh) 2012-06-13
TW200639811A (en) 2006-11-16
HK1106317A1 (en) 2008-03-07

Similar Documents

Publication Publication Date Title
WO2006059483A1 (ja) 再生装置、再生方法および再生プログラム、記録媒体、ならびに、データ構造体
KR101154796B1 (ko) 재생 장치, 재생 방법 및 기록 매체
KR101087316B1 (ko) 재생 장치, 재생 방법 및 기록 매체
JP4332089B2 (ja) 再生装置、再生方法および再生プログラム、ならびに、記録媒体
KR101237160B1 (ko) 재생 장치 및 기록 매체
US8139926B2 (en) Reproduction apparatus, reproduction method, reproduction program, record medium, and data structure
AU2012200803A1 (en) Reproduction device, reproduction method, reproduction program, recording medium, and data structure

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005806735

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2005310796

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 3984/DELNP/2007

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: MX/a/2007/006428

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 11720609

Country of ref document: US

Ref document number: 1020077012539

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2005310796

Country of ref document: AU

Date of ref document: 20051110

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2005310796

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 200580047676.5

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2005806735

Country of ref document: EP