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

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

Info

Publication number
WO2006018999A1
WO2006018999A1 PCT/JP2005/014490 JP2005014490W WO2006018999A1 WO 2006018999 A1 WO2006018999 A1 WO 2006018999A1 JP 2005014490 W JP2005014490 W JP 2005014490W WO 2006018999 A1 WO2006018999 A1 WO 2006018999A1
Authority
WO
WIPO (PCT)
Prior art keywords
playback
reproduction
content data
control command
mode
Prior art date
Application number
PCT/JP2005/014490
Other languages
English (en)
French (fr)
Inventor
Toshiya Hamada
Yasushi Fujinami
Tatsuya Kakumu
Takenori Ohshima
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 AU2005273384A priority Critical patent/AU2005273384A1/en
Priority to EP05768388A priority patent/EP1783771B1/en
Priority to CA002576305A priority patent/CA2576305A1/en
Priority to NZ553138A priority patent/NZ553138A/en
Priority to US11/573,717 priority patent/US20080075437A1/en
Priority to PL05768388T priority patent/PL1783771T3/pl
Priority to BRPI0514464-7A priority patent/BRPI0514464A/pt
Priority to MX2007001791A priority patent/MX2007001791A/es
Publication of WO2006018999A1 publication Critical patent/WO2006018999A1/ja
Priority to HK07109455.2A priority patent/HK1101620A1/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/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
    • 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
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • 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

Definitions

  • the present invention enables a user to perform interactive operations on a program recorded on a large-capacity recording medium, and can easily restrict a predetermined user operation, a reproduction method, a reproduction method, and the like program
  • the DVD Digital Versatile Disc
  • the DVD has been around for a long time as a recording medium that can be accessed and removed at random.
  • Disc-shaped recording media are being developed.
  • the conventional DVD-Video standard for playback only uses interactive images placed on the menu screen to achieve interactive functions. For example, while playing a video with a DVD video, you can use a remote control commander to call up the menu screen, select a button image placed on the menu screen, and change the playback screen. It was.
  • a control program for realizing an interactive function is described by a specific command defined in the DVD video standard.
  • the control program is also distributed and embedded in multiple locations in multiple files and data files, and even in AV stream files.
  • the conditions and order in which these are executed are also It is determined by the DVD video standard.
  • playback control operations (hereinafter referred to as user operations) by the user, such as jumping between chapters, can be freely performed. It is summer.
  • user operations playback control operations
  • content with complex playback controls such as a multi-story where a story branches under certain conditions, or a quiz game where a scenario progresses when a user selects an answer, The scene that wants to restrict the operation occurs.
  • warning screens it may be necessary to present a certain warning screen to the user before playing the main story. In this case, it is also necessary to restrict user operations so that warning screens cannot be skipped or fast-forwarded.
  • a flag indicating whether or not to permit the operation of each user operation such as playback and jump jump is provided. Used to set whether to allow user operations.
  • a prohibition flag for permitting or prohibiting a specific operation of the information reproducing apparatus in units of PGC (Program Chain) in the DVD video standard is set.
  • PCI Presentation Control Information
  • the combinations of prohibited user operations intended by content creators are often limited to several commonly used combinations. Therefore, the method of setting permission and non-permission for each user operation has an excessive degree of freedom, and as a result, it is considered that omissions and contradictions are likely to occur due to forgetting to set.
  • permission and disapproval can be set for each user operation. Therefore, it is necessary for the player manufacturer to verify whether or not the player operates correctly for all the combinations, and there is a problem that the burden of verifying the player is large.
  • an object of the present invention is to provide a playback device, a playback method, a playback program, a recording medium, and a recording device that can easily limit a user operation when playing back a program recorded on a large-capacity recording medium. It is to provide a de overnight structure.
  • the present invention provides a playback device for playing back content data recorded on a disc-shaped recording medium, specifying at least a content night and a playback path for the content data, and attribute information.
  • Reading means for reading data from a recording medium on which is recorded reproduction instruction information including a value indicating a restriction mode for the reproduction control instruction of content data and a reproduction control program for controlling reproduction of the content data, and a reproduction control program
  • Player means for reproducing the content data in accordance with the content data
  • control command generating means for generating a control command for the player means in response to a user operation for giving a contention evening playback control instruction.
  • the reproduction apparatus Indicates the restricted mode for each playback instruction information from the medium Read the value, generate a table for each playback instruction information based on the read value indicating the restriction mode, and check whether to allow execution of the control command generated by the control command generation means in the table.
  • the reproduction apparatus is characterized in that control is performed for each piece of reproduction instruction information.
  • the present invention also provides a reproduction method for reproducing content data recorded on a disc-shaped recording medium, wherein at least the content data and the content data are recorded.
  • a recording in which a playback path for content data is specified and playback instruction information including a value indicating a restriction mode for content data playback control instructions as attribute information and a playback control program for controlling playback of content data are recorded.
  • a control command for the player means is generated in accordance with a read step for reading data from the medium, a content playback step for playing back content data in accordance with the playback control program, and a user operation for giving a playback control instruction for content data
  • a control command generation step wherein the content reproduction step reads a value indicating the restriction mode for each reproduction instruction information from the recording medium, and sets a table for each reproduction instruction information based on the read value indicating the restriction mode.
  • Generation and control command generation step Whether to permit the execution of the control commands in generated, the reproducing method being characterized in that the so that to control for each reproduction instruction information on the basis of the table.
  • a playback program for causing a computer apparatus to execute a playback method for playing back content data recorded on a disc-shaped recording medium.
  • the playback method specifies at least the content data and a playback path for the content data, A read step for reading data from a recording medium in which reproduction instruction information including a value indicating a restriction mode for the reproduction control instruction of content data as information and a reproduction control program for controlling reproduction of the content data are recorded, and reproduction A content playback step of playing back content data in accordance with the control program, and a control command generation step of generating a control command for the player means in accordance with a user operation for giving a contention overnight playback control instruction, Con
  • the content playback step reads the value indicating the restriction mode for each reproduction instruction information from the recording medium, and generates a table for each reproduction instruction information based on the read value indicating the restriction mode.
  • the reproduction program is characterized in that whether or not to permit execution of the control command generated in the control command generation step is controlled for each reproduction
  • the present invention specifies at least content data, a playback route for content data, playback instruction information including a value indicating a restriction mode for the content data playback control instruction as attribute information, and playback of content data And a reproduction control program for controlling the recording medium.
  • the present invention specifies at least content data and a playback route for the content data, playback instruction information including a value indicating a restriction mode for the playback control instruction of the content data as attribute information, and content overnight playback And a playback control program for controlling the data structure.
  • the playback control program for controlling playback reads data from the recording medium on which the playback is recorded, and the playback device performs playback of the content data in accordance with the playback control program, and sets the value indicating the restriction mode read for each playback instruction information.
  • a table is generated for each playback instruction information, and whether or not the execution of the control command generated according to the user operation for giving the playback control instruction for the content overnight is permitted. Since each instruction information is controlled, user operations are performed during content production. Can be easily set in units of playback instruction information based on the restriction mode, and the playback device can also set restrictions on user operations. It can be easily verified based on the password.
  • the present invention specifies at least content data, a playback route for the content data, playback instruction information including a value indicating a restriction mode for the content data playback control instruction as attribute information, and content data playback Since the playback control program for controlling the playback is recorded on the recording medium, the playback control instruction for the content overnight that is given by the user operation to the playback device that plays the recording medium during content production is set to the restricted mode. It can be set easily based on this, and the playback device can easily verify the restrictions on user operations based on the restriction mode.
  • the data structure according to the present invention includes at least content data, a playback path for content data, playback instruction information including a value indicating a restriction mode for content data playback control instructions, and content data as attribute information.
  • Playback control program for controlling the playback of content data, the content data playback control instruction given by the user operation to the playback device that plays back the data having this data structure is created based on the restricted mode.
  • the playback device can easily verify restrictions on user operation based on the restriction mode.
  • a combination of restrictions on user operations is defined as a mode, a set of frequently used user operations is prepared in advance on the player side, and the provided user operations are provided on the content creator side. By selecting the combination mode, control over user operation is realized.
  • the content creator side has to prepare a module prepared in advance on the player side. Users can be restricted by simply selecting a mode, so that user operations can be controlled more easily, and the burden on production and verification by content creators is reduced. There is an effect.
  • FIG. 1 is a schematic diagram for explaining user operation control according to the conventional DVD video standard
  • Fig. 2 is a schematic diagram showing a layer structure of the UMD video standard
  • Fig. 3 is an embodiment of the present invention.
  • FIG. 4 is a schematic diagram illustrating an internal configuration of an example of a movie player
  • FIG. 5 illustrates three states of the movie player.
  • FIG. 6 is a schematic diagram schematically showing an event model of a movie player according to an embodiment of the present invention
  • FIG. 7 is an example of an event that occurs during the play of a playlist.
  • Fig. 8 is a schematic diagram showing a list of example properties of a movie player object.
  • Fig. 9 is a schematic diagram showing a list of examples of methods of a movie player object. 1 0 Fig.
  • FIG. 11 is a schematic diagram showing an example key input by a user input
  • Fig. 11 is a schematic diagram showing an example key input by a user input
  • Figure C is a schematic diagram showing an example of a control command corresponding to a key input
  • Figure 1 3 is a schematic diagram showing an example of an event corresponding to a key input
  • Figure 14 is an example of an example
  • Fig. 15 is a schematic diagram showing an event handler.
  • Fig. 16 is an example of a prepared program that is triggered by a user input event.
  • Fig. 17 is a flowchart showing the process.
  • Fig. 11 is a schematic diagram showing an example key input by a user input
  • Fig. 11 is a schematic diagram showing an example key input by a user input
  • Figure C is a schematic diagram showing an example of
  • FIG. 17 is a flowchart showing the process from loading a disc into the UMD video player until it is ejected.
  • Fig. 18 is a schematic diagram showing an example of the structure of a script file
  • Fig. 19 is a flowchart showing an example procedure for executing an event handler onAutoPlayO
  • Fig. 20 is an event handler onContinuePIayO.
  • Fig. 21 is a flowchart showing an example of processing at the end of playback.
  • Fig. 22 is a diagram for explaining an example of a script program.
  • Fig. 23 is an example script.
  • Fig. 24 is a schematic diagram showing the program.
  • Fig. 24 is a schematic diagram for explaining the file management structure applied to the UMD video standard.
  • FIG. 25 is the entire file "PLA YLIST.DAT”.
  • FIG. 26 is a schematic diagram showing an example of the internal structure of a block PlayltemO.
  • FIG. 27 is a schematic diagram showing an example of the internal structure of a block PlayListMarkO.
  • Fig. 29 is a diagram for explaining the field markjype in the lock MarkO.
  • Fig. 29 is a diagram for explaining the designation of the mark time in the clip AV stream file.
  • Fig. 30 is the clip AV stream.
  • Fig. 31 is a diagram for explaining the association of the block StreamlnfoO with the element list stream, and
  • Fig. 32 is a block diagram.
  • Fig. 33 is a schematic diagram showing the internal structure of an example of StaticInfoO.
  • Fig. 33 is a schematic diagram showing the internal structure of an example of StaticInfoO. Fig.
  • FIG. 33 is a schematic diagram showing the internal structure of an example of block DynamicInfoO.
  • Fig. 34 is a schematic line showing the internal structure of an example of block EP-mapO.
  • FIG. 35 is a block diagram schematically showing the structure of an example of a disc playback apparatus to which the present invention can be applied.
  • FIG. 36 A and FIG. 36 B show the operation of the disc playback apparatus in more detail.
  • Fig. 37 is a schematic block diagram showing the syntax of an example of the file "PLAYLIST.DAT" according to the embodiment of the present invention.
  • Fig. 38 shows the value represented by the field U0P_mask-mode.
  • a schematic diagram illustrating the meaning, Fig. 39 shows the user operation in the movie player.
  • FIG. 40 is a functional block diagram of an example for realizing the function of limiting the number of cases
  • FIG. 40 is a flowchart showing the procedure for creating an example of a command filter table
  • FIG. 41 corresponds to the user operation mask mode “1”.
  • Fig. 42 is a schematic diagram showing an example command filter table
  • Fig. 42 is a schematic diagram showing an example command fill table corresponding to the user operation mask mode "2”
  • Fig. 43 is a command fill table.
  • 10 is a flowchart showing an example of processing for limiting user operation.
  • CM A scribble A player model is described using a scribble language called CM A scribble.
  • E CMA script is defined by E CMA (European Computer Manufacturers Association) A cross-platform scripting language based on ipt (registered trademark).
  • 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.
  • UMD OJnive rsal Media Disc registered trademark
  • UMD video standard is called the UMD video scribing standard.
  • the UMD video standard is outlined below.
  • Figure 2 shows the layer structure of the UMD video standard.
  • a layer structure of the script layer, playlist layer, and clip layer is defined, and stream management is performed based on this structure.
  • MPEG 2 streams that are multiplexed as elementary streams of MPEG 2 (Moving Pictures Experts Group 2).
  • the MP EG 2 stream in which the video, audio, and subtitle elementary streams are multiplexed is called a clip AV stream.
  • Clip A V stream is stored in Clip A V stream file.
  • a clip information file (Clip Information File) is created simultaneously in a one-to-one correspondence with the clip AV small stream file.
  • a set consisting of these clip information files and the corresponding clip AV stream file is called a clip.
  • the clip should be called the unit of recording on the disc.
  • the order in which clips are played at the time of birth is managed by the playlist layer, which is the upper layer of the clip.
  • the playlist layer which is the upper layer of the clip.
  • a layer that specifies the playback path of a clip includes one or more playlists (PyL i st).
  • the playlist is composed of a set of play items (P l a yl t em).
  • a play item includes a set of In and Out points that indicate the playback range of the clip. By connecting the play items, clips can be played back in any order. become able to. 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 file by 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 script layer is a layer constructed by U M D video script that extends E C M A script of the language specification.
  • the U M D video script is based on the E C M A script and is an extended script that implements functions specific to U M D video.
  • the script layer is an upper layer of the playlist layer, and is composed of a command sequence for performing playlist playback instructions and player settings.
  • the script layer command is accompanied by conditional branching, such as selecting one of the streams prepared for multiple languages, or changing the playback flow to a playlist selected according to a certain condition. Play list playback can be realized.
  • An example of an application that uses playlist playback with conditional branching is multi-story.
  • This script layer introduces an interactive function with the user.
  • the script layer is composed of one file “SCRIPT.DAT” and managed as a resource.
  • the file “SCRIPT.DAT” is based on the scribble data described based on the actual ECMA scribb, the sound data for outputting sound effects during button operation, the image data used for the background image of the menu screen, etc.
  • a model of a playback device that plays back data in accordance with the UMD video standard, that is, a player model
  • the player first reads the script program, playlist, and clip information file from the disc, then reads the clip AV stream file according to the playback order determined by these, and then video, audio, subtitles, etc. Play.
  • the function block that plays the playlist is implemented as an object in the script program.
  • An object for playing a playlist is called a movie player object in the UMD video standard.
  • the play list playback instruction and the player setting command are the methods of this movie player object. Movie player objects are controlled by methods from the Scribble layer Is done.
  • FIG. 3 schematically shows an example player model according to the embodiment of the present invention described above.
  • the movie player 300 is a module that controls 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. In other words, the movie player object is a script program itself for realizing the function of the movie player.
  • the video player 3 0 0 is a lower layer (native implementation platform 3 0 1 in the example of FIG. 3) caused by a user input 3 1 0 or the like, or a script layer that is an upper layer.
  • 3 0 2 According to the method from 2, based on the playlist and clip information database, clip AV stream file Decode and display the read clip AV stream.
  • the inside of the movie player object 300 depends on the implementation of the UMD video player that plays UMD video. From the script layer 302, the API such as the method property is used as a black boxed object. (Application Programming Interface) is provided.
  • the UMD video player refers to an actual device in which a movie player is mounted. All UMD video players implement a movie player that complies with the restrictions of the UMD video standard and are compatible with playback.
  • the movie object 300 is a path for receiving the control command 3 1 1 from the native implementation platform 3 0 1 and a path for notifying the script layer 302 of the event 3 1 2. It has three input / output paths that accept methods 3 1 3 from script layer 3 02.
  • the control command 3 1 1 is a command for controlling the operation of the movie player object 300 from the native-implemented platform 30 1.
  • the native implementation platform 301 is, for example, an interface between a part unique to a device and a movie player 300 in 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.
  • the 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 inside. Has 3 2 0.
  • the movie player object 300 uses the data base 320 to invalidate (mask) the user input 310 and the playback position specified by the time to the byte position in the clip AV stream. Perform processing to convert.
  • the playback module 3 2 1 in the movie player object 300 decodes a clip AV stream that is MPEG2PS (Program Stream) in which video, audio, and subtitles are multiplexed.
  • the playback module 3 2 1 has three states: play, stop, and pause, and transitions between these three states according to control instructions and methods (see Fig. 4).
  • the script layer 302 is a layer that executes a scribe 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 3 0 2 instructs the native implementation platform 3 0 1 to perform key events 3 1 4 corresponding to user input 3 1 0 and screen drawing with the native implementation platform 3 0 1 Exchange method 3 1 5 etc.
  • 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 program of the script layer 3 0 2 to the native implementation platform 3 0 1.
  • the key corresponding to the user input 3 1 0 Event 3 1 4 is notified to script layer 3 0 2 from native implementation platform 3 0 1, and the script program in script layer 3 0 2 responds to key input 3 1 0 based on key event 3 1 4 Process.
  • GUI graphical user interface
  • the script layer 3 0 2 performs the division of roles, such as the processing when the operations such as selection and determination are performed on the GUI parts.
  • the native implementation platform 3 0 1 is a platform on which movie player objects 3 0 0 and a scribble program operate. For example, if the actual UMD video player is hardware, For example, the native implementation platform 3 0 1 accepts and accepts user input 3 1 0 from the user to play a role in mediating the processing between the software and the player model. It is determined whether the user input 3 1 0 is an instruction for the movie player 3 0 0 or an instruction for the button drawn and displayed in the script layer 3 0 2. The native implementation platform 3 0 1 is an internal control command for the user input 3 1 0 if it is determined that the user input 3 1 0 is a command for the movie player 3 0 0. Convert to control command 3 1 1 and issue control command to movie player 3 0 0.
  • the native implementation platform 3 0 1 is the user input 3 1 If it is determined that 0 is an instruction for the GUI component drawn and displayed in the script layer 3 0 2, the key event 3 1 4 corresponding to the user input 3 1 0 is notified to the script layer 3 0 2. Then, a button image can be displayed on the screen, for example, on the basis of the method 3 15 instructed from the script layer 3 0 2 according to the key ⁇ vent 3 1 4. In other words, the native implementation platform 30 1 and the script layer 30 2 can directly pass events and methods without going through the movie player 3 0 0.
  • FIG. 4 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.
  • the property 3 2 3 is a property 3 2 3 A (read-only parameter) whose value is determined by the initial setting of the movie player 3 0 0, for example, the language code, and the playback module 3 2 1
  • Property 3 2 3 A whose value is determined by default setting 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.
  • playback module 3 2 The property 3 2 3 B indicating the state of 1 can read values from the script program and write values from some scribe programs.
  • the movie player object 300 plays the specified playlist according to the instruction from the script layer 300 or the native implementation platform 301.
  • the movie player 3 0 0 refers to the data base 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 three states of play (stop), stop (pause), and pause (pause) according to the play status of the playlist ⁇ .
  • the play state refers to the state where the playlist ⁇ is being played and the time has passed.
  • variable speed playback such as double speed and ⁇ / 2 speed, forward fast forward and reverse fast forward are also included in the play state.
  • the pause state is a state in which the playlist is playing and the time axis is stopped.
  • 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. In the stop state, the playlist is not being played.
  • the state of the movie player 3 0 0 is associated with the state transition of play, pause, and stop in the decoder engine 3 2 2 of the movie player 3 0, and in response to the state transition of the decoder engine 3 2 2.
  • the value of property 3 2 3 B is updated.
  • Resume information 3 2 4 stores the status immediately before the stop status. For example, when a playlist with a movie player 300 is decoded and in play state, when the state transitions to the stop state, the state immediately before the stop state is stored. Also, a plurality of resume information 3 2 4 can be stored in a non-volatile memory possessed by the player as hardware so that each title of the disc can be identified. For example, a disc has unique identification information (referred to as 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 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 playback of the disc is changed to the previous stop state. You can start from the position just before.
  • title ID unique identification information
  • 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, irregular events occur and The prepared program is executed.
  • the script program controls the operation of the movie player object 300 by an event handler group.
  • FIG. 6 schematically shows an event model of the movie player 300 according to an embodiment of the present invention.
  • event handlers onEventAO, onEventB 0, and onEventC 0 are interfaces, and 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 determined as the processing program to be 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. .
  • FIG. 7 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. In addition, every time the chapter changes, the event Chapter is notified to the script layer 300 and the corresponding event handler onChapter is executed. Ma When playback reaches the time at which the event mark EventMark is set, the 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 layer 300. On the script layer 302 side, the start of playback of another playlist is instructed in the corresponding event handler onPlayListEndO. In this way, a series of playlist playbacks are continued in the order intended by the content creator.
  • the upper program can grasp the state of the player.
  • the host program handles various event occurrences by preparing a program (event handler) that is executed when each event occurrence is notified. Details of events and event handlers will be described later.
  • event handler If the event handler is not described by the content creator, either the player built-in behavior specified in the standard (default event handler) is executed, or the event is ignored and nothing is executed. When there is no need to do anything, events can be actively ignored by not writing event handlers corresponding to events.
  • an object registers a listener corresponding to an event in the player object, and if the event that occurred in the player object is registered, the event is registered from the player object.
  • An event listener model that sends an event to an object and executes the corresponding method on the object, and any event occurs.
  • a single method model that calls one method can be considered.
  • 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 needs to know which event has occurred, and describe the preprocessing in that method to switch the processing routine prepared for each event. Since the method is implemented by the content creator, the load on the content creator increases even though the model is simple. Furthermore, one large processing program (method) will be called each time an event occurs, occupying a lot of memory space, and the execution speed will be slow.
  • a model for preparing a processing program (event handler) for each event is advantageous in this respect.
  • an object defined by a language that conforms to the ECMA 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. Not limited to this, by defining a method se tXXX O (“XXX” is the target property name) that sets property values and a method ge tXXX O that reads property values, the properties of other objects are defined. Can be read and written by methods It becomes.
  • FIG. 8 shows a list of example properties that the movie player object 300 has. This corresponds to property 3 23 in Figure 4.
  • the properties belonging to the read-only parameter 32 3 A in Fig. 4 are as follows.
  • Property scriptVersion indicates the version of the UMD video script.
  • Property language Code 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 indicated by the property languageCode set in this read-only parameter 3 2 3 A. If the loaded disc does not have a script file corresponding to the language, the default script file is read. For example, among the multiple scribble files, the file located at the top of the disk is read as the default script file.
  • the properties belonging to the player status 32 3 B in FIG. 4 are as follows.
  • Property playListNumber indicates the number of the play list currently being played.
  • the property chapterNumber indicates the number of the currently playing chapter.
  • Property videoNumber indicates the number of the video stream currently being played.
  • the property audioNumber indicates the number of the audio stream currently being played.
  • Property subtitleNumber indicates the number of the subtitle stream currently being played.
  • Property playListTime indicates the time when the play list head is 0.
  • Property AudioFlag indicates the audio playback ON / 0 FF and dual mono LR specification.
  • Property subtiUeFIag indicates ONZO FF for caption display.
  • Dual mono is a mode that uses the left and right (L, R) channels of stereo audio as independent monaural audio channels.
  • Each property belonging to this player status 3 23 B has such information when the movie player 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 resume information 324.
  • the contents of the player status 3 23 B may be cleared.
  • FIG. 9 shows a list of examples of methods that the movie player object 300 has. This corresponds to method 3 1 3 in Fig. 3.
  • the method playO plays the video.
  • Method playCtiapter () plays a video by specifying a chapter.
  • 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 / or subtitle stream.
  • the method getPlayerStatus () obtains the status of playback, stop, pause, etc. in movie player 300.
  • Method resetO stops video playback and clears the contents of resume information 324.
  • 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 is for video Set the display position.
  • the method getPosO gets the video unpositioned position.
  • 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 300 1 are integrally configured.
  • the disk is actually loaded, and it is associated with the relationship between the UMD player as the hardware that plays the disk and the software that controls the UMD player. Whether it is done by software depends on the configuration at the time of implementation. For example, when the UMD player is configured with a personal computer or the like, it can be configured with software other than the disk drive.
  • a video decoder or audio decoder can be configured in hardware. Therefore, the methods, commands, and events performed between the movie player 300 and the native implementation platform 300 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 whether the user input 3 1 0 is a command for the movie player 300 or an event for the script layer 3 02 script program
  • the control command 3 11 or key event 3 14 is generated according to the determination result, and the corresponding upper layer (movie player 300 or script layer 30 2) is notified.
  • FIG. 10 shows an example of key input related to the operation of the movie player 300.
  • Key VK_P0WER provides a function corresponding to the power key.
  • the key VK—P0W ER—ON provides a function corresponding to the power ON key.
  • Key VK—POWER 1 OF F provides a function corresponding to the power OFF key.
  • Key VK_MENU provides a function corresponding to the menu key to display the menu.
  • Key VK —ENTER provides a function corresponding to the Enter key that indicates “OK”.
  • Key VK_RETURN provides a function corresponding to the return key that returns one processing step.
  • 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—PAUSE provides a function corresponding to a pause key that instructs playback to pause.
  • Key VK_FAST—FORWARD provides a function corresponding to the fast-forward key to instruct fast-forward playback.
  • Key VK_FAST_REVE RSE provides a function corresponding to the fast-rewind key to instruct fast-rewind playback.
  • Key VK— SLOW— FORWARD provides a function corresponding to the slow (forward) key that instructs forward slow playback.
  • the key VK_SLOW_REVERSE provides a function corresponding to the slow (reverse) key that instructs reverse slow playback.
  • Key VK— STEP— FORWARD provides a function corresponding to the frame advance (forward) key that instructs frame advance playback in the forward direction.
  • the key VK_STE P_REVERSE provides a function corresponding to the frame advance (reverse) key that instructs reverse frame advance playback.
  • Fig. 11 shows an example of key input for menu operation.
  • Key VK jEXT provides a function corresponding to the next designation key for inputting a value meaning “next”.
  • the key VK_PREVI0US is before entering a value that means "previous”.
  • Key VKJJP provides a function corresponding to the up direction key that inputs a value that means “up”.
  • Key VK_D0WN provides a function corresponding to the down direction designation key to input a value that means “down”.
  • the key VK—RIGHT provides a function corresponding to the right direction key for entering a value that means “right”.
  • Key VK One LEFT provides a function corresponding to the left direction designation key to input a value meaning “left”.
  • the key VK_UP_RIGHT provides a function corresponding to the upper right direction designation key for inputting a value meaning “upper right”.
  • Key VK — UP_LEFT provides a function corresponding to the upper left direction designation key for inputting a value meaning “upper left”.
  • Key VK_D0WN—RIGHT provides a function corresponding to the lower right direction designation key to input a value that means “lower right”.
  • the key VK_D 0WN_LEFT provides a function corresponding to the lower left direction designation key for inputting a value meaning “lower left”.
  • the key VK_ANGLE provides a function corresponding to the angle switch key that instructs to switch the multi-angle video.
  • Key VK_SUBTITLE provides a function corresponding to a subtitle switching key for switching English subtitles, Japanese subtitles, subtitle display Z, etc.
  • Key VK—AUDIO provides a function that supports audio switching for switching audio settings such as surround and bilingual.
  • the key VK—VIDE0_ASPECT provides a function corresponding to the aspect switch key that indicates the video aspect ratio switch.
  • Key VK_C0L0RED—KEY_1 is colored function key 1
  • key VK—C0L0RED_KEY 1-2 is colored function key 2
  • key VK—C0L0RED KEY 3 is colored function key 3
  • key VK_C0L0RED—KEY—4 provides functions corresponding to colored function key 4
  • key VK—COLORED —KEY—5 provides colored function key 5
  • key VK—COLORED—KEY_6 provides functions corresponding to colored function key 6.
  • the key input shown in Fig. 10 and the key input shown in Fig. 11 have different roles, it is necessary to distribute the notification destinations to the native implementation platform 301. As described above, the key input shown in FIG. 10 gives instructions regarding the reproduction of video, audio, and subtitles.
  • the native implementation platform 3 0 1 When the native implementation platform 3 0 1 receives the key input shown in FIG. 10 as the user input 3 1 0, the received key input is changed to FIG. 1 2 A, FIG. 1 2 B and 1 2 The command is converted to the command shown in Fig. C and notified to the movie player 300.
  • the key input shown in Fig. 11 is the user input 3 1 0 to the GUI. Therefore, this user input needs to be notified and processed to the scribble layer 3 0 2 where the screen configuration and buttons are arranged. There is.
  • the native implementation platform 3 0 1 receives the key input shown in Fig. 1 1 as the user input 3 1 0, it converts it to the event 3 1 4 in Fig. 3 and notifies the scribble layer 3 0 2 To do.
  • Figure 13 shows an example event 3 1 4 corresponding to this key input.
  • Fig. 10 and Fig. 11 mentioned above also include key inputs related to stream switching, such as key VK-ANGLE, key VK- SUBTITLE, key VK_AUDI 0. This is a key input for realizing the same function as the stream switching method for the movie player 300 from the program.
  • the command uo i timeSearch (playL is tTime) instructs playback from the specified time of the playlist being played.
  • Argument pi ayListTime represents the time when the top of the playlist is 0. Since this command cannot specify the playlist number, the time indicated by the argument play ListTirae is the specified time within the range of the currently playing playlist.
  • the command uo_play () instructs to start playback at a predetermined playback speed such as 1 ⁇ speed. The starting position is determined based on the resume information 3 24. If there is no information corresponding to resume function 24, this user operation is disabled. This command corresponds to the execution of the play 0 method with no playlist number specified. In this command, the playlist number cannot be specified by user operation.
  • the command uo— playChapter (chapterNumber) specifies the start of playback of the currently playing playlist from the chapter specified by the chapterNumber argument. If no chapter is specified, the player is instructed to start playback from the beginning of the currently playing chapter. This corresponds to the method playChapterO with no specified chapter number.
  • the command uo_playPrevChapter 0 instructs to start playback from the previous chapter.
  • the command uo playNextCliapterO instructs the start of playback from the current next chapter.
  • the command uo—stopO instructs to stop playback.
  • the command uoJumpToEndO 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 layListEnd.
  • the event handler onPlayListEnd is executed in the script layer 3 02.
  • the command u 0— iorwardScan (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 by the argument speed.
  • These commands uo The argument speed in forwardScan (speed) and the command uo— backwardScan (speed) depends on the implementation of the UMD video player.
  • Command uo playStep (forward 3 ⁇ 4, indicates forward frame-by-frame playback.
  • Command uo_pIayStep (backward) indicates reverse frame-by-frame playback.
  • Command uo— pauseOnO is used to pause playback based on user operation.
  • Command uo— pauseOff 0 cancels playback pause based on user operation.
  • the command uo—changeAudioChannel instructs audio channel switching or single channel switching during dual mono playback.
  • the value of the flag audioFlag is also changed to the corresponding contents.
  • Command uo setAudioEnabled specifies the audio stream ONZOFF.
  • the command uo_setSub UtleEnabled specifies ON / OF F of the subtitle stream.
  • the command uo_angleChange instructs to change the display angle.
  • command uo subtitleChange (subtiUeStreamNumber) instructs to change the subtitle stream to be played.
  • the event menu jumps to the menu. This event is not for the player player 3.00, but for the native implementation platform 3 0 1 notifies script layer 3 0 2
  • the script layer 302 executes the event handler onMenu.
  • the event exit is an event emitted from the native implementation platform 301 when the native implementation platform 301 terminates the UMD video application.
  • the script layer 302 executes the event handler onExit.
  • Event up, event down, event left, event right, event ⁇ focusIn, event focusOut, event ⁇ push and event cance 1 are focused on the button image that is the GUI component displayed on the screen. This event occurs when This event is notified to the script layer 302 not from the movie player 300 but from the native implementation platform 301.
  • 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.
  • the event focusln occurs when a certain button image is focused, and the event iocusOut occurs when the focused image is out of focus.
  • the event push occurs when a push operation is performed on the focused point image.
  • the event cancel occurs when a cancel operation is performed for a button image press operation.
  • Event autoPlay and event cont inuePlay This is an event for instructing the start of execution of a script in the manager 300.
  • the event aut oP l ay is an event that instructs to automatically start scribing when a disc is loaded.
  • Event cont i nueP l ay instructs to resume execution of the script from the point where it was previously stopped based on the resume information 3 24, for example, when the disc is loaded.
  • a program corresponding to this event is called an event handler.
  • Events and event handlers can be associated with each other by name, for example. As an example, the event handler name is “on” prepended to the event name.
  • Figures 14 and 15 show an example event handler. By describing the contents of the event handler, the content creator can cause the UMD video player to execute various actions intended by the content creator.
  • FIG. 14 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. 14 corresponds to the event 3 12 shown in FIG. 3 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, and its content is implemented by, for example, a content creator using a scribble language. By configuring the event handler in this way, the action intended by the content creator can be realized when an event occurs.
  • Event mark and event handler onMark O are executed when an event mark is detected.
  • the event mark is embedded in the playlist, and the movie player 3 0 during playback of the playlist. Detected by 0.
  • the event mark is notified from the movie player 300 to the scribble layer 300.
  • Script layer 3 0 2 executes event handler onMarkO corresponding to this event mark.
  • event palyListEnd and event handler onPlayListEndO are executed when the playlist ends.
  • Event chapter and event handler onChapterO are executed when a chapter mark is detected.
  • the chapter mark is embedded in a playlist, for example, and is detected by the movie player 300 during playback of the playlist.
  • Event angleChange and event handler onAngleChangeO are executed when an angle change is instructed by a user operation. For example, when the key input VK_ANGLE. Is input to the native implementation platform 30 1 as the user input 3 1 0 according to the user operation, the native implementation platform 30 1 sends the user input 3 1 0 to the command uo — angleChangeO. Convert and pass to movie player 300. The movie player 300 generates an event angleChange in response to this command uo_angleChange () and passes it to the script layer 302. Script layer 302 executes event handler onAngleChangeO corresponding to event angleChange. Similarly, the event audioChange and the event handler onAudioChangeO are executed when an audio change is instructed by the user operation. Event subtitleChange and event handler onSubtitleChangeO are executed when a subtitle change is instructed by a user operation.
  • Figure 15 shows a part of an example event handler of a system object.
  • the event handler shown in Figure 15 is
  • the native implementation platform 30 1 is a pre-installed pen handler and is notified from the native implementation platform 3 0 1 to the script layer 3 0 2.
  • Event menu and event handler onMenuO jump to the menu.
  • the event menu is an event notified from the native implementation platform 301 to the scribe layer 302 when, for example, a menu key is pressed by a user operation or the like.
  • Script Ray catcher 30 2 receives this event, executes the corresponding event handler onMe nu (), performs like GU I component placement and display that make up the menu screen in the event handler OnMenuO.
  • the event exit and event handler onExitO are an event emitted from the native implementation platform 301 and the corresponding event handler when the native implementation platform 301 terminates the UMD video application.
  • the event exit is notified from the native implementation platform 301 to the script layer 300 when the end of the operation of the UMD video player is instructed by a user operation or the like.
  • the script of the script layer 302 can execute the termination process in the event handler onExitO.
  • the event auto Play and event handler onAutoPlay (), and the event cont inuePlay and event handler onCont inuePlay 0 respectively start scribing.
  • event handlers for system objects there are event handlers for buttons.
  • the event handler related to this button is not related to the present invention, so the explanation is omitted.
  • Fig. 16 shows this key input when the user presses the "next" key to instruct to play the next chapter during normal playback of a disc in the UMD video player.
  • this is an example of starting playback by jumping to the next chapter and displaying the prepared message on the screen.
  • step S 1 0 when a user presses the key “next” using the remote control commander of the UMD video player during normal playback of a disc by the UMD video player (step S 1 0), the native implementation of the platform 3 0 1 Key VK_NEXT is passed as user input 3 1 0 for.
  • the user command uo_playNextChapter () is generated in response to the user input 3 10 (step S 1 1). This user command uo—playNextChapterO is notified to the player 300.
  • 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, a chapter jump is not performed and the current reproduction is continued.
  • step S 13 if it is determined in step S 13 that the next check mark exists, the process proceeds to step S 14.
  • step S14 the movie player 300 stops the current playback, and the byte position in the clip AV stream file indicated by the next chapter mark indicates the feature information of the clip information file in the database 3 20 Get from. And in step S 1 5 the retrieved file Access the internal byte position, start reading the stream from that position, and start playback.
  • 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 chapter event occurs (step S 16). For example, a chapter mark provided at the beginning of a chapter evening is 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 2 starts to execute an event handler corresponding to the notified event, for example, event handler onChapter O (step S 17).
  • the event handler describes the operation to display a message to notify that on the screen when a changeover occurs.
  • the script of script layer 302 executes this event handler, obtains the jump destination chapter number notified from movie player 300 when an event occurs (step S 1 8), and executes the native implementation platform 3 0 Instructs to display a predetermined message on the screen, such as the beginning of the chapter of the acquired chapter 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 2 0).
  • the user jumps to the chapter jump by operating the key “nex t” that instructs the start of playback of the next chapter. At the start of playback of the next chapter that is the destination, a message indicating that it is the beginning of the chapter will be displayed on the screen.
  • FIG. 17 schematically shows the process from loading a disc into the UMD video player until it is ejected.
  • the process described by the hatched block shows the state where the scribing is being executed.
  • the UMD video player loads the disc by a predetermined operation and makes it playable (step S30).
  • the resume information 324 is referred to by the native mounting platform 301, and the subsequent playback information corresponding to the disc is loaded (step S31).
  • step S 3 2 the content information 3 2 4 corresponding to the disc is referred to, and it is determined whether or not the playback information exists (step S 3 2). If it exists, the native implementation platform 30 The event continuePlay is notified from 1 to the script layer. The scribe layer 3 02 executes an event handler onContinuePlay corresponding to the notified event continuePlay (step S 3 3). If it is determined in step S32 that there is no continuous playback information corresponding to the disc, the process proceeds to step S34, and the event autoPlay is notified from the native implementation platform 30 1 to the script layer 3 02. Script layer 3 02 is the corresponding event Handler onAutoPlay is executed.
  • step S35 the disc playback operation is performed based on the description contents of the event handler onAutoPlay and event handler onContinuePlay, and the event generated by the disc playback operation and the event handler corresponding to the event are executed. Is done.
  • the corresponding event handler onExit is executed in the script layer 302 in step S36, and processing for terminating the UMD video application is performed. Executed.
  • the event exit is generated on the native implementation platform 30 1 based on, for example, a user input 3 10 corresponding to a predetermined operation on the remote control commander.
  • step S 37 the movie player 300 executes a process for stopping the reproduction operation. At this time, the state immediately before the stop is continued and stored in the resume information 324 as reproduction information. Then, the playback of the disc is finished (step S 38), and when the same disc is not played again (step S 39), the disc is ejected by the native mounting platform 301 in step S 40, and a series of Processing is terminated. When playing the same disc again, the process returns to step S 3 1.
  • Figure 18 shows an example of the structure of a script file.
  • the script file exists as a file in the file “SCRIPT.DAT” constituting the script layer 302.
  • ⁇ file consists of event handler group and main processing part .
  • event handler group one or more event handlers are arranged. Each time an event occurrence is notified to the script layer 302, an event handler corresponding to the notified event is searched and executed.
  • main processing section for example, definitions of global variables used in common for each event handler are described, and usually executed only once at the beginning.
  • Figure 19 shows an example procedure for executing the event handler onAutoPlayO. This process is performed when a playback instruction is given to the movie player 300 (step S50) so that playback is started from the beginning when the disc is loaded into the UMD video player.
  • step S 51 the native implementation platform 301 checks whether the event handler onAutoPlayO exists in the script. If it exists, the native implementation platform 30 0 1 notifies the event autoPlay to the script layer 302 (step S 5 2). In response to this, in step S54, the script layer 3002 executes the event handler onAutoPlayO. This automatically starts playback of the loaded disc.
  • step S 5 1 if it is determined in step S 5 1 that the event handler onAuto PlayO does not exist in the script, the process proceeds to step S 53, and the native implementation platform 30 1 sends an event exit to the script layer 3 02. Notice. In this case, for example, by operating a menu key or the like and giving a playback instruction from the menu screen mounted on the native mounting platform 301, the playback of the disc can be started. If script layer 30 2 has event handler on Exit 0, this event handler onExitO is executed.
  • Figure 20 shows an example procedure for executing the event handler onContinuePlayO. This process is performed when the user instructs the movie player 300 to play back the disc when loading the disc into the UMD video player (step S 60).
  • step S 61 the native mounting platform 3 0 1 checks whether or not the resume information 324 corresponding to the mounted disk exists. If it does not exist, the process proceeds to step S62, and playback starts from the beginning.
  • step S 63 If the resume information 324 corresponding to the loaded disc exists, the process moves to step S 63 to check whether the event handler onContinuePlayO exists in the script. If it exists, the native implementation platform 301 notifies the event ContinuePlay to the scribble layer. In response to this, the script layer 302 executes the event handler onCont inuePlayO (step S 64). As a result, playback of the loaded disc is resumed according to the event handler onContinuePlayO.
  • step S 63 if it is determined in step S 63 that there is no event handler onContinuePlayO in the script, the process proceeds to step S 65 and the default event handler onContinuePlayO is executed.
  • the default event handler onContinuePlayO simply starts playback from the previous playback end position based on the information in the resume information 324, for example.
  • the user interface by the event handler onAutoPlay and the event handler onContinuePlay is not limited to the above example, and various methods can be considered.
  • Figure 20 above Is instructed whether the resume information 324 corresponding to the loaded disc exists after the user has instructed continuous playback in step S 60, but this is done in the reverse order. The user may be prompted to select whether or not to continue playback if it exists.
  • Fig. 21 shows an example of processing at the end of playback. This process is performed when, for example, a user instructs the movie player 300 to end playback during playback of the disc (step S70).
  • the native implementation platform 3 0 1 starts the termination process (step S71).
  • the termination process is, for example, the following three processes.
  • step S 7 1 When the processing of step S 7 1 is executed and the currently executed event handler is finished (step S 7 2), the native implementation platform 3 0 1 changes to the script layer 30 2 in the next step S 7 3. On the other hand, an event exit is notified.
  • the script layer 302 receives the event handler onExitO (step S74).
  • the event handler onExi) executes, for example, a predetermined post-processing at the end of playback or a method setUserData that stores setting data by the user.
  • the end processing is performed by the native implementation platform 3 0 1.
  • the native implementation platform 3 0 for example, Subsequent information is stored in volatile memory (ie, the backup information is restored to the state information immediately before playback ends 3 2 4) and the system menu is changed.
  • the player model as described above enables playback of video, audio, and captions.
  • an event at a certain time during playback that is set in advance by the content creator is generated and an event handler prepared in advance by the content creator is executed. Can realize the intended operation.
  • a command corresponding to the user operation is notified from the native implementation platform 3 0 1 to the movie player 3 0 0 and the user intends
  • the state of the player can be changed as described above.
  • the native implementation platform that receives the user input by the user operation notifies the script layer 3002 of the event corresponding to the user input, so that the content creator can respond to the user operation.
  • the prepared operation can be realized.
  • the content shown in FIG. 22 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 strike 40 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 40 1 can be instructed.
  • the message 403 is displayed at an arbitrary time during the reproduction of the playlist 401. Further, in the configuration of FIG. 22, several event handlers are prepared.
  • the event handler onAutoPlayO automatically plays the playlist 400 and displays a warning text when a disc is loaded into the UMD player.
  • the event handler onPlayListEndO is an event handler that is called when the play list finishes playing. In the example of FIG. 22, the event handler onPlayListEndO is called when the play list 400 or the play list 401 ends. In other words, the event handler onPlayListEndO determines which playlist has ended, and when the playback of the playlist 400 has ended, instructs the start of playback of the playlist 401. Further, when the reproduction of the playlist 401 is finished, 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. 22, mark Mark is set for playlist 40 1, and message 403 is displayed on the screen when playback of playlist 40 1 reaches the time indicated by mark Mark. It is like that.
  • the disc 400 is played on the UMD video player and a warning screen is displayed.
  • Playlist 40 0 When the end of the playlist 400 has passed and the end of the playlist 400 is reached, the event handler onPlayLisnd is called to determine that the playlist 400 has been played to the end, and the next playlist 401 is played back. It is.
  • the event handler onMenu is called and the top menu screen 402 is displayed. Also, 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. 23 shows an example script program for realizing the operation shown in FIG. As described above, event handlers are arranged in the script program, and corresponding event handlers are executed when an event occurs.
  • the script program is stored in the file "SCRIPT.DAT" described later.
  • the method for instructing the movie player 300 to play the playlist is “movieplayer.play ()”.
  • event playListEnd occurs.
  • event handler movieplayer.onPlayListEndO is called from the script.
  • the object even and info are passed to the script together with the event p layListEnd.
  • the object even and info contains a playlist indicating which playlist has ended. Stores the default number. In the script, the following actions can be changed according to the contents of this object event inio.
  • 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 Standari- sion) -9660 or UDF (Universal Disk Format) can be applied.
  • the file “TITLEID.DAT” and directory “VIDEO” are placed under the root directory. Below the directory “VIDEO”, a directory “RESOURCE”, a directory “CLIP”, a directory “STREAM”, and a file “PLAYLIST.DAT” are also placed.
  • TITLEID.DAT is a file in which a different title identifier is stored for each title (content type). There is one file “TITLEID.DAT” for one disk.
  • the file “SCRIPT.DAT” is placed under the directory "RESOURCE”.
  • This file “SCRIPT.DAT” stores the script program constituting the script layer 302 as described above.
  • Under the directory "RESOURCE” there is usually one file “SCRIPT.DAT”.
  • multiple files “SCRIPT.DAT” can be placed under the directory "RESOURCE”. In this case, for example, change part of the file name so that they do not overlap each other.
  • the clip information file has a file name, a string consisting of 5 or several characters such as “00001” before the delimiter period (number in this example), and the extension after the period is “CLP”.
  • 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 file name is a string consisting of 5 or several characters such as “00001” before the delimiter period (number in this example), and the extension after the period is rPSj. With the extension rpsj, it can be identified 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 as a program stream of MPEG 2 (Moving Pictures Experts Group 2),
  • the clip AV stream file stored in the file identified by the above-mentioned extension “PS” is a file obtained by compression encoding and time-division multiplexing video data and audio data. By reading this file and decoding it, video data and audio data can be obtained.
  • the clip information file is a file that describes the nature of the clip AV stream file, and corresponds to the clip AV stream file.
  • the clip AV file corresponding to the clip information file By matching the character string consisting of 5 or several characters before the extension in the file name, the correspondence between them can be easily grasped.
  • the file “SCRIPT.DAT” is a script file in which the script program is described, and is used to make the playback mode of the disc to which this embodiment is applied interactive.
  • the program is stored.
  • the file “SCRIPT.DAT” is read prior to other files stored on the disk.
  • the file “PLAYLIST.DAT” is a playlist file in which a playlist that specifies the playback order of the clip AV stream is described.
  • the internal structure of the file “PLAYLIST.DAT” will be described with reference to FIGS.
  • Figure 25 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.
  • the field name_lengtli has an 8-bit data length and indicates the length of the name assigned to this playlist file.
  • 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 used as a valid name from the beginning to the byte length represented by the field name_length. For example, if the field name_length has the value "1 0", the first 10 bytes from the beginning of the field name_string are interpreted as a valid name.
  • the field number_o PlayLists has a data length of 16 bits and indicates the number of blocks PlayList 0 described subsequently. The number of times indicated in the field number—of_PlayLists by the for loop on the next line The number of blocks ⁇ ayL ist 0 is described. Block P 1 ayL ist 0 is the playlist itself.
  • the field ayLis and data-length are arranged at the head of the block PlayListO.
  • the field PlayLis_data_length has a 32-bit data length and indicates the data length of the block PlayLis) including the field PlayList-dataJength.
  • a field reserved-for-word-ignition having a data length of 15 bits and a flag of one hit: s 3 ⁇ 4 flag capture, enable, flagJPlayList are assigned.
  • Fiesolede reserved —for—word—alignment is used to align the placement in block PlayList 0 to the 16-bit position in combination with the flag Capture_enabl e_flag 1 PlayList with a length of 1 bit.
  • the flag capture-enableJlagJayUst is a 1-pit flag, but this is not limited to this example.
  • the flag “capture” enable—flag_PlayList may be composed of a plurality of bits, and the staged permission for secondary use may be described.
  • the flag captur e enable jlagJ> layList has a 2-bit configuration. When the value is "0”, secondary use is completely prohibited, and when the value is "1", for example, 64 pixels x 64 lines. Secondary use is possible only when compression encoding is performed below a predetermined resolution. Also, 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”
  • other applications in the same enclosure eg wallpaper images and screens
  • bit 0 and bit 1 values can be used in combination.
  • Field PlayLiss name-length has a data length of 8 bits and indicates the length of the name assigned to this block PlayList0.
  • Field P1 ayLis name_string has a data length of 255 bits and indicates the name assigned to this block PlayList ().
  • the field PlayLis- ting name—string is used as a valid name from the beginning to the byte length represented by the field PlayLis- ing name_sing.
  • Field number_o and Playltems have a data length of 16 bits and indicate the number of blocks PlayltemO described subsequently. The number of blocks PlayltemO is described for the number of times indicated in Playltem2 by the field number-0 by the for loop on the next line. Block PlayltemO is the play item itself.
  • Identification information is assigned to each block PlayltemO in the block PlayList (). For example, the first block PlayltemO described in the block PlayListO is numbered 0, and thereafter, serial numbers such as number 1, number 2,... Are added in the order of appearance of the block Playltem (). This serial number is used as identification information for each block Play system O. The for loop argument i repeated for the number of blocks Plau IiemO can be used as identification information for the corresponding block PlayltemO. Next to the block Playlt 'em (), the block PlayListMarkO is arranged.
  • the internal structure of an example of the block PlayltemO will be described with reference to FIG.
  • the field length has a data length of 16 bits, and indicates the length of the relevant block PlayltemO.
  • the field CI ip1 Information—file—name—length is placed.
  • the field CI ip-Information-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 Playsystem 0.
  • Field Clip_Iniorfflation_server_name has a variable data length in bytes, and indicates the name of the clip information file corresponding to this block PlayltemO.
  • the field Clip-Information-file-name is used as a valid name from its leading force to the byte length represented by the field Clip-Information-file-name_length.
  • File CI ip— Information— file name the clip AV stream file corresponding to the clip information file is determined according to the file name correspondence described above. Can be identified.
  • the field IN—time and field OUT—time each have a data length of 3 2 bits, and the clip format defined in the field C1 ip—Information—file—name in the block PlayltemO. This is time information for designating the playback start position and playback end position of the clip AV stream file corresponding to one transition file.
  • This field IN-time and field OUT-time it is possible to specify the start of playback from a portion other than the beginning of the clip AV stream file. Similarly, the end of playback other than the end of the clip AV stream file can be specified.
  • Field leng th is arranged at the head of the block PlayListMarkO.
  • the field length has a data length of 32 bits, Indicates the length of the block PlayListMarkO.
  • field numb er of_P yList—marks is placed.
  • the field field number—of—PlayListjnarks has a 16-bit data length and indicates the number of the subsequent block Mark 0.
  • the number of blocks MarkO are described as many times as indicated by PlayL istjnarks in the field number—0 by the for loop on the next line.
  • the block Mark 0 is preceded by a field mark_type.
  • Field mark 1 type has a data length of 8 bits and indicates the type of block MarkO including the field mark-type.
  • three types of marks are defined: a cap mark, an index mark, and an event mark.
  • the chapter is a cue unit for dividing the play list (block PlayListO)
  • the index is a cue unit for further dividing the chapter.
  • the chapter mark and the index mark respectively indicate the chapter position and the index position by time information.
  • An event mark is a mark that generates a mark event.
  • Field mark 1 name-length has a data length of 8 bits and indicates the length of the name assigned to this block MarkO.
  • a field mark_name_string arranged in the bottom line of the block MarkO indicates the name given to this block MarkO.
  • the field mark_name_st ring is used as a valid name from the beginning to the byte length represented by the field mark_name_length.
  • the field mark-time-sta has a data length of 32 bits and is used to specify the mark time in the clip AV stream file. This will be schematically explained with reference to Fig. 29.
  • the playlist consists of three play items (Playltem (# 0), Playltem (#l) and Playltem (# 2)) with numbers 0, 1 and 2 respectively. Time t on the list. Is included in the play item (#D) of number 1. Also, each of the play items of number 0, 1 and 2 is clip AV stream file via the corresponding clip information file. It is assumed that they correspond to Program Streams A, B, and C, respectively.
  • time t on the playlist If a mark is specified for the field, the value of the field ref—toJPlayItem_id is set to the time t. “1” indicating a play item including “,” and the time t on the corresponding clip AV stream file B. The time corresponding to is described in the field mark_time—stamp.
  • the field mark—time—sta is immediately followed by the field ——J red entry—ES—stream one id and the fine entry entry—ES—private—strea m one id.
  • the field entry_ES_stream_id and the field en try— ES_private— stream— id each have a data length of 8 bits, and the block MarkO is associated with a particular elementary stream. Is used to identify the elementary stream.
  • the field entry—ES stream—id and field entry—ES—private—stream—id are the stream ID (stream_id) of the packet (packetO) in which the corresponding elementary stream is multiplexed. shows Puraibe one Tosutori Ichimu ID ply base one Bok Nono 0 Kek Bok header (private- packet- header 0) (private- stream- id).
  • the stream ID (stream_id) of these buckets (packet 0) and the private stream ID (private_stream_id) of the private packet header (private_packet_header 0) are, for example, MP EG 2 sys System program stream specification.
  • 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".
  • the clip information file “XXXXX.CLP” describes the properties of the corresponding clip AV stream file “XXXXX.PS” placed under the directory “STREAM”.
  • FIG. 30 shows an example of syntax representing the entire structure of the clip AV stream file “XXXXX.CLP”.
  • field presentation—start—time and field presentation_end—time are arranged at the beginning.
  • Field presentation start t ime and field presentat ion— end— t ime Each has a 32-bit data length and indicates the time of the beginning and the end of the corresponding clip AV stream file.
  • PTS Presentation Time Stamp
  • PTS has an accuracy of 90 kHz.
  • a field reservedJor_word_alignment having a data length of 7 bits and a flag capture enable_flag-CI ip having a data length of 1 bit are arranged.
  • the field reserved— for_word—al ignment is used to align the placement in the file “XXXXX.CLP” to the position of 16 bits in combination with the flag capture 1 enable 1 Hag_Clip with a data length of 1 bit.
  • the flag capture_enable—ag—Clip is a flag indicating whether or not secondary use of the moving image included in the clip AV stream file corresponding to the file “XXXX.CLP” is permitted. For example, if the value of this flag capture-enable-flag-Clip is "1", secondary use of the video of the clip AV stream file corresponding to the file "XXXX.CLP" in the player Indicates permission.
  • the field number_o and streams has an 8-bit data length and indicates the number of subsequent StreamlnfoO structures.
  • Block. StreamlnfoO is described for the number of times indicated by the final number_of—s treams from the next force of the field number—of—st reams.
  • the block EPjnapO is placed after the for loop.
  • 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 Streamlnfo 0.
  • a field stream_id and a field private-stream-id each having a data length of 8 bits are arranged, and the block StreamlnfoO is designated as an element as shown in FIG. 31.
  • a talistostream Associated with a talistostream.
  • this block StreamlnfoO is associated with the video stream with the field s tream_id between the value "0 x E 0" to the value "0 x EF", and with the value "0 xBD” Associated with C (Adaptive Transform Acoustic Coding) audio stream, LP CM (Linear Pulse Code Modulation) audio stream or subtitle stream.
  • C Adaptive Transform Acoustic Coding
  • LP CM Linear Pulse Code Modulation
  • block StreamlnfoO has a field private—stream—id of value “0 x 0 0” to value “0 x 0 F”, value “0 x 1 0” to value “0 x 1 F” and value “0 x It is associated with ATRAC audio stream, LP CM audio stream, and subtitle stream from 8 0 "to value” 0x9 F ", 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 Block DynamicInfoO with the change point specified by time information.
  • a field with 8-bit data length is provided to align the byte position after the block Stat iclnfo 0 re served—for—word—alignment, and then the field number— of—Dynamiclnfo is arranged.
  • Field number—of— Dynaminlnfo has a data length of 8 bits, and indicates the number of blocks DynamicInfoO described later in block StreamlnfoO.
  • the field pts change—point and the block DynamicInfoO are described as many times as indicated by the field number_o and Dynamiclnfo.
  • the field pts—change—point has a data length of 32 bits, and the PTS indicates the time when the information of the corresponding block Dynamic I ⁇ ⁇ o 0 becomes valid.
  • the start time for each stream is also indicated by the field pts_change_point, which is equal to the field presentation-start-time defined above in the file "XXXXX.CLP".
  • the internal structure of an example of the block StaticInfoO will be described using Fig. 32.
  • the content of the block StaticInfoO varies depending on the type of the corresponding elementary stream.
  • the type of the corresponding elementary stream can be judged based on the values of the field stream-id and the field private-stream-id described with reference to Fig. 31.
  • the type of elementary stream corresponding to the block StaticInfoO is described using the if syntax to indicate whether the stream is a video stream, an audio stream, or a subtitle (caption) stream.
  • the block StaticInfoO has a flag with a field picture-size and a field frame-rate each with a 4-bit data length, and a header length of 1 cc cc a ag Consists of.
  • Field picture size and field frame-rate indicate the size of the video stream and the frame frequency, respectively.
  • the flag cc_flag indicates whether or not the video stream includes closed captions. For example, the flag — ag has a value of “1” and the video stream contains a closed caption.
  • Lock StaticInfoO is a field with a data length of 1 6 bits au dio— language— code, 8 hits—even: s ”5 fields—red channel—conf iguration, 1 bit data length It has the following fields: sampling_frequency force with a field length of 1 fe—exs is tance and a data length of 4 pits field audio—language—code indicates a code representing the language contained in the audio stream.
  • the field charnie and co nfiguration indicate the channel attributes of the audio data such as mono, stereo, multi-channel, etc.
  • the field lfe—existance indicates whether or not the low frequency emphasis channel is included, for example, the value is "1"
  • the field sampling_frequency indicates the sampling frequency of the audio data field reserved_f or—word_alignment is used to align the data alignment to 16 bits.
  • the block StaticInfoO is a field with a data length of 16 bits.
  • Subtitle language—code and a flag with a data length of 1 bit conf igur able—flag Consists of.
  • Field sub t i tie 1 language code indicates a code representing the language included in the subtitle stream.
  • Flag configurable The flag indicates whether or not to allow change of the character size and position when performing the subtitle stream. For example, the value is “1”, indicating that permission is allowed.
  • the field reserved—for one word_al ignme nt is used to align the data arrangement to 16 bits.
  • the internal structure of an example of the block DynamicInfoO will be explained using Fig. 33.
  • the block DynamicInfoO is preceded by a field having a data length of 8 bits.
  • the content that follows depends 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 with reference to FIG.
  • the type of elementary stream supported by the block DynamicInfoO is described using the if syntax to indicate whether it is a video stream, an audio stream, or a subtitle (caption) stream.
  • the block DynamicInfo () will be described below for each elementary stream.
  • the block DynamicInfoO consists of a field display —aspect—ratio force with a 4-bit data length.
  • the field display— aspect— rat io indicates whether the display output aspect ratio of the hit is 16: 9 or 4: 3.
  • the field reserved—for—word—al ignmeni is used to set the data layout to 16 bits.
  • the block DynamicInfoO consists of a field channel-assignment with a 4-bit data length.
  • the field channel—assignment indicates whether the output is stereo or dual mono when the audio stream consists of two channels. Dual mono is used, for example, to enable playback of audio in two languages.
  • the field reserved_for_word—alignment is used to align the data layout to 16 bits.
  • the block DynamicInfoO is composed of the field reserved—for_word_alignment used to align the data arrangement to 16 bits. In other words, dynamically changing attributes are not defined for subtitle streams.
  • the block EP-mapO represents the decoding start possible position (entry point) in the bit stream for each elementary stream using time information and position information. 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 EP_map ().
  • the decoding start position can be obtained by calculation, so information such as this block EPjnapO is unnecessary.
  • important information for random access and Become in the case of a variable rate stream or a stream in which the data size changes for each access unit, such as MP EG video compression and encoding, important information for random access and Become.
  • the field PTS—EP—start and field RPN— are repeated by the second for loop as many times as indicated by the field number_oi—EP—entries.
  • EP start is disposed.
  • a field stream-id and a field private_stream-id each having a data length of 8 bits are arranged, and an example is shown in FIG. 31. The list is identified.
  • the distributed field number_of_EP-entries has a data length of 32 bits and indicates the number of entry points described for the corresponding elementary stream.
  • field PTS—EP start and field RPN_EP_start are allocated as many as indicated by field number—0 and EP_entries.
  • Field PTS_EP_start and field RPN—EP_start each have a 32-bit data length and represent the entry point itself.
  • the field PTS_EP_start indicates the time in the clip A V stream file of the endpoint as PTS.
  • the field RPN_EP_sart indicates the position of the entry point in the clip AV stream file in units of 2048 bytes, for example.
  • one sector which is an access unit on the disk 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 R: PN_EP_start.
  • the packet private-stream-2 is always placed immediately before the position where the video stream can be played back.
  • This packet private—stream 1-2 is a packet that stores information that can be used to decode the video stream. Therefore, the position of the entry point of the video stream is the position of the pack packet () in which the packet private-stream-2 is stored.
  • Block EP niapO, clip AV stream as described above
  • the above time is associated with the position in the clip AV stream file.
  • time information time stamp
  • the set of time information and position information for each elementary stream (the set of field PTS_EP_start and field RPN_EP—start in the second for loop) is the field PTS_EP.
  • Registration is arranged in advance in ascending order (or descending order) for both start and RPlEI ⁇ start. In other words, time information and position information are rearranged in a predetermined direction in advance. For this reason, it is possible to perform a binary search on the data as it is.
  • the video element list stream is based on the MP EG 2-Video standard. Although described as being an elementary list based on, this is not limited to this example.
  • the elementary stream of video may be based on MPEG 4-Visua 1 or MPEG4-AVC.
  • the audio elementary stream has been described as being an ATRAC audio elementary stream, but this is not limited to this example, and can be applied to, for example, MPE G 1 2 4 audio.
  • FIG. 35 schematically shows an example of the configuration of a disc playback apparatus 100 to which the present invention can be applied.
  • C PU C entral Processing Unit
  • Memory 1 1 3 Memory 1 1 3
  • Drive interface 1 Input interface 1 1
  • Video decoder 1 1 6 Audio decoder 1 1 7
  • Each unit of the disc playback apparatus 100 can exchange a video stream, an audio stream, various commands, data, and the like via a bus 11 1 1.
  • a disk drive 102 is connected to the drive-in evening face 1 14.
  • the disk drive 1 0 2 exchanges data 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). According to a program stored in the ROM in advance, the CPU 1 Data and commands are exchanged with each unit of the disk playback device 100, and the entire disk device 100 is controlled. RAM is used as work memory for CPU 1 1 2.
  • 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 1 0 1 has the format as described in Fig. 24 and later, and includes playlists, script programs, and clip information. Recorded files, clip AV stream files, etc.
  • the disc 1 0 1 is loaded into the disc drive 1 0 2, 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 disk 1 0 1 is temporarily stored in memory 1 1 3.
  • the video decoder 1 1 6 decodes the video stream or subtitle 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 video data and subtitle data are subjected to image processing such as enlargement and reduction processing by the CPU 1 1 2, for example, and combined and added to form one video data. These 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 interface 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 the CPU 1 1 2.
  • the decoded audio data is buffered in memory 1 1 3 and the audio output interface. Supplied to face 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. 35 is described as being configured with 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 CPU 1 1 2.
  • FIGS. 36A and 36B are functional block diagrams for explaining in more detail the operation of the disc playback apparatus 100 shown in FIG.
  • the disc playback apparatus 100 is generally composed of a talented perusal system 2 0 1 and a video content playback unit 2 1 0.
  • the video content playback unit 2 10 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. In FIG. 36 A and FIG. 36 B, the disk drive 10 2 is omitted.
  • the operation system 2 0 1 starts up first in the CPU 1 1 2 when the disk playback device 1 0 0 is turned on 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 with respect to the video content playback unit 2 1 0 during the operation of the video content playback unit 2 1 0.
  • the operation system 2 0 1 is a video container.
  • the disk drive 10 2 is controlled via the drive interface 1 14 to read the data recorded on the disk 1 0 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 2 1 0 shown in FIG. 3 A as an example and FIG. 3 B as an example are all connected in parallel by the multitask processing function of the operation system 2 0 1. Operation is possible.
  • the video content playback unit 210 has several modules inside, and realizes the following functions.
  • the script file is read from the disk 1 0 1 and passed to the script control module 2 1 1.
  • the loaded disc 1 0 1 is a UMD video disc
  • 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 2 1 1 is the script file "SCRIPT.
  • the player control module 2 1 2 is a database that is stored in files such as the playlist file “PLAYLI ST. DAT” and the clip information file “XXXXX. 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 follows the instructions of the player control module 2 1 2 and clips the AV stream from the disc 1 0 1 Reads content data such as a file 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 controls the buffer control module 2 1 5 according to the request 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.
  • the content data stored in the memory 1 1 3 is supplied to these modules 2 1 6, 2 1 7 and 2 1 8 in a predetermined manner.
  • the content data supply module 2 13 reads the content data from the disc 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 14 has a clock function inside, and the decoder control modules 2 1 6, 2 1 7 and 2 1 8 are provided so that video data and audio data are output synchronously. To control the operation.
  • 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 reading function, an audio reading function, and a subtitle reading function as internal modules.
  • the video readout function has a video readout pointer.
  • the video readout function has an A register for storing information au_information (), which is unit information, is provided.
  • the audio read function has an audio read pointer.
  • the subtitle read function has a subtitle read pin and a subtitle read function flag.
  • the subtitle read function flag controls whether the subtitle read function is enabled or disabled according to the value to be written. For example, when “1” is written to the subtitle read function flag, the subtitle read function is enabled, and when “0” is written, the subtitle read 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 MP E G 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. 31) arranged in a predetermined 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. 31). The values of these field stream-id and field private_stream-id are used when analyzing the supplied bitstream.
  • Video decoder control module 2 1 6 video from memory 1 1 3 Read a single video access unit of a stream to deco
  • the video decoder control module 2 16 controls the video decoder 1 1 6 to decode the video stream supplied to the video decoder 1 1 6 in units of access units.
  • the video data 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 1 7 so that it can be Give instructions to the audio readout function.
  • 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 the single subtitle access unit 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 Instructions are given to the subtitle reading function in 5.
  • 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.
  • Subtitle decoder control mode The subtitle image data obtained by decoding the subtitle stream by the subtitle decoding function of module 2 1 8 is supplied to the graphics processing module 2 1 9.
  • the graphics processing module 2 1 9 is configured to process the video data decoded by the video decoder 1 1 6 based on the control of the video decoder control module 2 1 6 and the subtitle decoded by the subtitle decoder control module 2 1 8. Image data.
  • the graphics processing module 2 19 adds 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 in accordance with instructions from the script control module 2 11 for the supplied caption image display, and performs predetermined processing for the video display. to add.
  • the graphics processing module 2 1 9 converts the aspect ratio of 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. I do. 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 if 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.
  • Output video device is 4: If it is 3, if the output aspect ratio is 4: 3, the video data is output as it is, and if the output aspect ratio is 16: 9, the output video data has the width of the image. Squeeze processing to match the screen width of the output video device, and insert a black image above and below the image and output it.
  • 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 part of the memory 1 1 3 and uses it as a buffer for FIFO (Firs t In Fi rs t Out), and is processed by the graphics processing module 2 1 9
  • the recorded video data is temporarily stored in this buffer and 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, accumulates the audio data output from the audio decoder 1 1 9 in this buffer, and performs predetermined Control to read with.
  • 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 audio data of the left channel is copied to the right channel in memory 1 1 3 and both outputs of the two channels are audio of the left channel. Data and And output. If the audio output mode is “Sub Audio”, for example, the right channel video is copied to the left channel in memory 1 1 3 and the output of both channels are both set to the right channel. Output as audio data. When the audio output mode is “main / sub audio” or the content is stereo, the audio data is output as it is.
  • Such audio output mode setting can be interactively performed by the user through a menu screen generated by the video content playback unit 210.
  • 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.
  • data 3 & ⁇ 6 (3-1> 1 & 61 ”—31 & 13 Chobi Day 3 & 6 (1_1156 and 0 & 1 &)
  • Data Saved— Player_Status stores the data Backup— Player— Stus of the player control module 2 1 2.
  • This data Backup—Playe ⁇ Status is the player status 3 2 3 B described above, for example.
  • the player control module 2 1 2 corresponds to the data immediately before the end, and the data Saved—Player—Status corresponds to the resume information 3 24. Also, the player control module as the data Saved_User—Data. Data stored in 2 1 2 User—Data is stored.Data—User—Data is predetermined data set for the player control module 2 1 2 by the user.
  • the non-volatile memory control module 2 5 0 stores these data in a predetermined area of the flash memory. tus and data Saved—User_Data pair is stored in association with the title ID of disk 1 0 1.
  • the storage medium in which the nonvolatile memory control module 2 5 0 stores data is not limited to a flash memory, and may be a hard disk, for example.
  • a combination of restrictions on user operations is defined as a mode (user operation mask mode: referred to as UOP mask mode). That is, a flag indicating whether or not to permit the operation is not provided for each user operation, but a set of user operations that are considered to be frequently used is prepared on the player side in advance, and the content creator side Then, the restriction on the user operation is realized by selecting the prepared mode.
  • UOP mask mode user operation mask mode
  • the user operation mask mode information is defined as the field UOPjiiask-mode in the playlist syntax, and is held for each playlist. This user operation mask mode information is held only in the playlist hierarchy, not in multiple hierarchies. According to this, a combination of restrictions on user operations is implemented on the player side as a user operation mask mode. Provided to the producer. This reduces the burden of operation verification on the content creator side.
  • FIG. 37 shows an example of the syntax of the file “PLAYLIST.DAT” according to an embodiment of the present invention.
  • the file “PLAYL 1ST. DAT” according to the UMD video standard already described with reference to Fig. 25 is used in the field UOP-mask- mode has been added.
  • the field UOP- maskjnode is the field reserve-for-word-alignment after the field PlayLis and data-length in the file "PLAYLIST.DAT" in Fig. 25, and the field capture— enable— flag— Added between PI ayList. Therefore, the field UOP-mask-mode is described for each playlist included in the file "PLAYLIST.DAT". Note that the position of this field UOP_mask_mode is an example, and is not limited to this example.
  • the movie player 3 0 0 reads the file “PLAYLIST. DAT” at the start of playback of the disc 1 0 1, and during playback of this disc 1 0 1, Is stored in the internal memory. Therefore, the field UOP-masu-mode information is also held in memory while the corresponding playlist is being played.
  • Field UOPjnask—mode has a 4-bit data length and indicates a user operation mask mode defined for each playlist included in this file “PLAYLIST.DAT”.
  • FIG. 38 illustrates the meaning of the value represented by the field U0P1 maskjnode. A value of “0 x 0” means that the user operation mask mode of the playlist is set to all user operations. Indicates that the mode can be activated.
  • Field UOPjnask When mode is set to the value “0 x 1”, this indicates that the user operation mask mode “1” is set for the playlist. For playlists with user operation mask mode “1” set, only playback stop (stop) is valid as a user operation. Even if other user operations are performed during playback of the playlist, the player side ignores it.For playlists whose user operation mask mode is set to ⁇ 1 '', the playlist is ignored.
  • a user operation of so-called “dive playback” is started to start playback from an arbitrary time in the middle, playback starts at a predetermined speed in the forward direction (for example, 1x playback) from the top of the playlist. Define it to start. In other words, if a jump playback occurs for a playlist whose user operation mask mode is set to ⁇ 1 '' while another playlist is being played, Playback at a predetermined speed is performed.
  • This user operation mask mode “1” displays a message prohibiting unauthorized duplication, unauthorized broadcast, etc., which is played prior to movie content on a disc with movie content, etc. It is supposed to be used for playlists for playing warning screens (FBI WA RNING).
  • Playlists with “2” are set as user operations. During playback of the playlist, jumping to the end of the playlist is prohibited by user operation. However, playback is always allowed to stop. Also, high-speed playback in the forward direction and high-speed playback in the reverse direction are permitted.
  • This user operation mask mode “2” is less compulsory than the above-mentioned mode “1” for restricting user operations.
  • This user operation mask mode “2” is used, for example, for playlists that play promotional videos (trailers) recorded at the beginning or end of a disc with recorded content for rental. It is assumed that
  • FIG. 39 shows a functional block diagram of an example for realizing the user operation restriction function in the movie player 300.
  • the movie player 300 generates the command filter table 5 0 1 based on the attribute information 5 0 0 of the playlist read from the disc 1 0 1, that is, the value indicated by the field UOP-maskjnode.
  • the user operation is input as user input 3 1 0 to the native implementation platform 3 0 1.
  • the native implementation platform 3 0 1 converts the input user input 3 1 0 into a control command 3 1 1 and supplies it to the movie player 3 0 0.
  • This control command 3 1 1 is passed to the command filter 5 0 2 in the movie player 3 0 0.
  • the command filter 5 0 2 refers to the command filter table 5 0 1 and plays the passed control command 3 1 1 in the playback mode.
  • Judge 3 2 Judge whether to pass to 1 or not.
  • the user operation restricted by the field UOP_jnask_mode is a user operation corresponding to the control command 3 1 1 that is filtered by the command filter table 5 0 1 and is not passed to the playback module 3 2 1
  • Figure 4 0 shows the command filter 7 is a flowchart showing an example of a procedure for creating a table 5001.
  • the movie player 3 0 0 reads the playlist file and the clip information file from the disc 1 0 1.
  • the field UOP-mask-mode is read from the attribute information of the read playlist (step S81).
  • a command filter table 5 0 1 corresponding to the user operation mask mode indicated in the read field UOPjnask-mode is created (step S 8 2).
  • a command fill table 5 0 1 is created for each playlist.
  • FIG. 41 shows an example command fill table 5 0 1 corresponding to the user operation mask mode “1”.
  • this command filter table 5 0 playback is started from other than the beginning of the playlist, and the permitted control command 3 1 1 is the command uo—st op O (1st 2 (See Figure A, Figure 12 B, and Figure 12 C).
  • FIG. 42 shows an example command filter table 5 0 1 corresponding to the user operation mask mode “2”.
  • the start of playback from other than the top of the playlist is “permitted” and the command uo is included in each control command 3 1 1 described with reference to FIG. 1 2 A, FIG. 1 2 B and FIG. 1 2 C — Only j umpToEnd O is prohibited. In other words, the user operation In the masking mode “2”, all control commands 3 1 1 except the command uoJumpToEnd O are permitted.
  • the command filter table 5 0 1 as described in FIG. 4 1 and FIG. 4 2 is not prepared on the content producer side, but is generated inside the movie player 3 0 0.
  • the format of the command filter table 5 0 1 in the player is arbitrary and depends on the player implementation.
  • the command fill table 5 0 1 is shown for the user operation mask modes “1” and “2”, respectively, but this is not limited to this example.
  • the command filter table 5 0 1 may be generated by listing the user operation mask modes. It can also be described using the i f syntax. If the i f syntax is used, the function of the command filter table 5 0 1 can be realized by the scribble itself.
  • FIG. 43 is a flowchart showing an example of processing for restricting user operations using the command filter table 5 0 1.
  • the disc 1 0 1 is loaded into the player, and the command filter table 5 0 1 is generated based on the file “PLAYLIS T. DAT” read at the time of loading. It shall be.
  • step S 1 0 When a user operation on the player occurs in step S 1 0 0, a user input 3 1 0 corresponding to this user operation is input to the native implementation platform 3 0 1.
  • the native implementation platform 3 0 1 accepts this user input 3 1 0 in step S 1 0 1, in the next step S 1 0 2, the native implementation platform 3 0 1 accepts the received user input 3 1 0.
  • the movie player 3 0 0 Convert to command 3 1 1 and notify movie player 3 0 0.
  • the movie player 3 0 0 Upon receiving this control command 3 1 1, the movie player 3 0 0 refers to the command filter table 5 0 1 of the playlist currently being played back (step S 1 0 3).
  • step S 1 0 4 based on the command filter table 5 0 1, it is determined whether or not execution of the notified control command 3 1 1 is permitted.
  • step S 1 0 If it is determined that the execution of 3 1 1 is not permitted, the process proceeds to step S 1 0 5, and the movie player 3 0 0 does not execute the process according to the control command 3 1 1.
  • step S 1 0 6 it is determined whether or not the control command 3 1 1 is to be executed in the currently playing playlist.
  • the control command 3 1 1 instructs an operation such as a chapter jump that jumps to another chapter in the playlist, or a stream switching operation. Stop playback of the current playlist and start playback of another playlist ⁇ ⁇ ⁇ that is to be executed in the playlist or instruct to start playback from a predetermined chapter of another playlist Determine what you want to do.
  • step S 1 0 6 If it is determined in step S 1 0 6 that the control command 3 1 1 is to be executed in the currently playing playlist, the process proceeds to step S 1 0 7 and Control command 3 1 1 is executed.
  • the execution of this control command 3 1 1 can be limited by an event handler. In other words, after filtering by user operation mask for user operations, filtering by event handlers can be performed. Monkey.
  • step S 1 0 6 if it is determined in step S 1 0 6 that the control command 3 1 1 is not to be executed in the playlist that is currently being reproduced, the process proceeds to step S 1 0 8.
  • step S 1 0 8 the command filter table 5 0 1 of another playlist whose playback is newly started is referred to.
  • the control command 3 1 1 notified to the movie player 3 0 0 in step S 1 0 2 described above is a command for instructing an operation to jump from the currently playing playlist to another playlist ⁇ .
  • the command file table 5 0 1 of the jump destination playlist is referred to.
  • step S 1 0 9 to play back from the beginning in the other playlist based on the command fill table 5 0 1 of another playlist that is about to start playback. It is determined whether or not only is permitted. If it is determined that only playback from the beginning is permitted, the process proceeds to step S 110. Then, the movie player 300 starts playback from the head of the other playlist even if the control command 3 11 instructs playback from a position other than the head of the other playlist. Instruct the Playpack module 3 2 1 as follows.
  • step S 110 9 determines whether the other playlist is permitted to be played from a position other than the beginning. If it is determined in step S 110 9 that the other playlist is permitted to be played from a position other than the beginning, the process proceeds to step S 1 11. Then, the movie player 3 0 0 follows the control command 3 1 1 to play back the other play list from the time specified by the control command 3 1 1. Direct to Joule 3 2 1.

Landscapes

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

Abstract

コンテンツを再生する際のユーザオペレーションを容易に制限可能とする。コンテンツの再生を制御するユーザオペレーションを制限する制限モードを予め設定し、制限モードを示す値をプレイリスト毎に属性情報としてディスクに記録する。プレーヤは、ディスクの再生時に、制限モードに基づくテーブルをプレイリスト毎に生成し、プレーヤに対するユーザオペレーションにより生成されたコンテンツの再生制御を行う制御コマンドを、テーブルを参照してコマンドフィルタによりフィルタリングし制限する。制限モードは、例えばプレイリストを必ず先頭から例えば１倍速といった所定速度で再生しなければならないモードと、プレイリストを再生中にジャンプすることが禁止されるモードとが用意される。コンテンツ制作側でのユーザオペレーション制限に対する検証の負荷が軽減されると共に、プレーヤ側でも、動作の検証の負荷が軽減される。

Description

明 細 書
再生装置、 再生方法、 再生プログラム、 記録媒体、 ならびに、 デー 夕構造 技術分野
この発明は、 大容量の記録媒体に記録されたプログラムに対するュ —ザによるィン夕ラクティブな操作を可能とすると共に、 所定のユー ザ操作を制限することが容易な再生装置、 再生方法、 再生プログラム
、 記録媒体、 ならびに、 データ構造に関する。 背景技術
ランダムアクセスおよび着脱が可能な記録媒体として、 DVD (Dig ital Versatile Disc)が出現して久しいが、 近年では、 この DVDよ りも大容量のディスク状記録媒体や、 D V Dより携帯に便利な小型の ディスク状記録媒体の開発が進められている。
一方、 従来から存在する、 再生専用の DVDビデオ規格においては 、 メニュー画面上に配置されたポタン画像などを用いて、 イン夕ラク ティブな機能を実現している。 例えば、 DVDビデオにより動画を再 生中に、 リモートコントロールコマンダなどを用いてメニュー画面を 呼び出し、 メニュー画面上に配置されたポタン画像を選択して再生場 面を変更するなどの処理が可能であった。
このような DVDビデオ規格では、 イン夕ラクティブな機能を実現 するための制御プログラムは、 DVDビデオ規格で定義された特有の コマンドで記述される。 また、 制御プログラムは、 複数のファイルや データファイル中の複数の箇所、 さらには、 AVストリームファイル 中にも分散されて埋め込まれる。 これらが実行される条件や順序も、 D V Dビデオ規格で決められている。
そのため、 従来では、 汎用的なコンテンツ制作システムを作ること が難しく、 予め決められた脚本に当てはめてストーリーを作る、 所謂 テンプレートを用いたコンテンツ制作が行われていた。 テンプレート では対応できない、 複雑な構成のコンテンツを作る場合は、 先ずコン テンッ制作システムそのものをカスタムメイドとして作成していた。
ところで、 D V Dビデオなどの再生において、 通常、 映画本編の再 生中などでは、 チヤプタ間のジャンプなどのような、 ユーザによる再 生制御操作 （以下、 ユーザオペレーションと呼ぶ） は、 自由に行える ようになつている。 一方で、 ストーリ一が特定の条件で分岐するマル チストーリーや、 ュ一ザが回答を選択することでシナリオが進んでい くクイズゲームなどのように、 再生制御が複雑なコンテンツでは、 ュ 一ザオペレーションを制限したい場面が発生する。
例えば、 マルチストーリ一であれば、 過去の再生履歴によって次の ストーリ一が決まるような構成になっている場合がある。 このような 場合に、 チヤプ夕ジャンプなどのユーザ操作によって、 設定されたス トーリーから外れるような再生ができないように、 ユーザオペレ一シ ョンを制限する必要がある。
他の例として、 クイズゲームの場合は、 答えを選択できる時間が制 限されている場合がある。 この場合、 その制限時間の間、 ユーザが再 生の一時停止をできないように、 ユーザオペレーションを制限する必 要がある。 クイズゲームの場合、 さらに、 答えを選択することなく、 正解が示されたシーンにジヤンプできてしまうことを防ぐ必要がある このように、 ユーザとコンテンツとの間で双方向のやりとりが発生 するような場合、 コンテンツ制作者の意図通りの再生を実現するため に、 ユーザオペレーションを制限する必要がある。
また、 本編の再生前に、 所定の警告画面などをユーザに必ず提示し なければならないことがある。 この場合も、 警告画面をスキップした り、 早送りできないように、 ユーザオペレーションを制限する必要が ある。
従来の DVDビデオ規格においては、 第 1図に一例が示されるよう に、 再生、 チヤプ夕ジャンプなどといった、 ユーザオペレーションの それぞれについて、 その操作を許可するか否かを示すフラグを設け、 そのフラグを用いて、 ユーザオペレーションを許可するか否かを設定 していた。 特開 2 003— 20343 3号公報には、 D VDビデオ規 格における P GC (Program Chain)の単位で情報再生装置の特定動作 を許可または禁止する禁止フラグを、 P GC I (Program Chain Infom ation)内および P C I (Presentation Control Informat ion)内にそれ ぞれ構築した技術が記載されている。
ところが、 上述したような、 ユーザにより可能なユーザオペレ一シ ヨンのそれぞれに対してフラグを設ける方法は、 コンテンツ制作者側 にとって非常に使いづらいという問題点があつた。
例えば、 あるュ一ザオペレーションを許可したくない場合には、 当 該操作に関連する他のユーザォペレ一ションも、 同時に不許可にする ことが多いと予想される。 一例として、 「順方向早送り」 というユー ザオペレーションを不許可にしたい場合、 「逆方向早送り」 というュ 一ザオペレーションも共に不許可にしたいことが考えられる。 このよ うな場合、 従来の DVDビデオ規格では、 「順方向早送り」 を表すフ ラグと、 「逆方向早送り」 を表すフラグとがそれぞれ独立しているた め、 このユーザオペレーションに対してそれぞれフラグの設定を行わ なくてはいけなかった。 このような従来の設定方法では、 ユーザオペレーションに対する許 可および不許可について、 多数の組み合わせが発生してしまうことに なり、 ユーザオペレーションに対する制限に、 抜けや矛盾が発生し易 かったという問題点があつた。
例えば、 ユーザに必ず提示したい警告画面などを表示する場面で、 「順方向早送り」 および 「逆方向早送り」 を指示するユーザオペレー シヨンを禁止するようにする一方で、 「チヤプタジャンプ」 を指示す るユーザオペレーションを許可したままにしていた場合、 ユーザは、 「チヤプ夕ジャンプ」 を指示する操作を行うことで、 警告画面をスキ ップさせることができてしまう。
一方で、 コンテンツ制作者が意図する、 不許可とするユーザォペレ ーションの組み合わせは、 よく用いられている幾つかの組み合わせに 限定されていることが多いと考えられる。 そのため、 ユーザオペレー ション毎に許可および不許可を設定する方法は、 過剰な自由度を有し 、 その結果、 設定し忘れなどによる抜けや矛盾が発生し易いものと考 えられる。
さらに、 D V Dビデオ規格では、 ユーザオペレーションを制限する フラグが、 A Vストリームに近い下位の階層からアプリケ一ションに 近い上位の階層まで、 複数の階層に存在している。 したがって、 フラ グを設定する際には、 それら階層間の組み合わせも考慮する必要があ り、 難解なものになっていたという問題点があつた。
さらにまた、 フラグの設定によりコンテンッ制作者が意図したとお りの動作が実現されているか否かは、 コンテンッ制作者側で検証する 必要がある。 これは、 コンテンツ制作者側の負担になってしまうとい う問題点があった。
また、 ユーザオペレーション毎に許可および不許可が設定できるた め、 プレ"ャ製造者側では、 プレーヤが正しく動作するか否かを、 そ の全て組み合わせに対して検証する必要があり、 プレーヤ検証の負担 が大きいという問題点があつた。 発明の開示
したがって、 この発明の目的は、 大容量の記録媒体に記録されたプ ログラムを再生する際のュ一ザオペレーションを容易に制限すること ができる再生装置、 再生方法、 再生プログラム、 記録媒体、 ならびに 、 デ一夕構造を提供することにある。
この発明は、 上述した課題を解決するために、 円盤状記録媒体に記 録されたコンテンツデータを再生する再生装置において、 少なくとも コンテンッデ一夕と、 コンテンツデ一夕に対する再生経路を指定し、 属性情報としてコンテンツデータの再生制御指示に対する制限モード を示す値を含む再生指示情報と、 コンテンツデータの再生を制御する 再生制御プログラムとが記録された記録媒体からデータを読み出す読 み出し手段と、 再生制御プログラムに従いコンテンツデータを再生す るプレーヤ手段と、 コンテンッデ一夕の再生制御指示を与えるための ユーザォペレ一ションに応じてプレーヤ手段に対する制御コマンドを 生成する制御コマンド生成手段とを有し、 プレーヤ手段は、 記録媒体 から再生指示情報毎に制限モードを示す値を読み出し、 読み出された 制限モードを示す値に基づき再生指示情報毎にテ一ブルを生成し、 制 御コマンド生成手段で生成された制御コマンドの実行を許可するか否 かを、 テーブルに基づき再生指示情報毎に制御するようにしたことを 特徴とする再生装置である。
また、 この発明は、 円盤状記録媒体に記録されたコンテンツデータ を再生する再生方法において、 少なくともコンテンツデータと、 コン テンッデータに対する再生経路を指定し、 属性情報としてコンテンツ データの再生制御指示に対する制限モードを示す値を含む再生指示情 報と、 コンテンッデータの再生を制御する再生制御プログラムとが記 録された記録媒体からデータを読み出す読み出しのステップと、 再生 制御プログラムに従いコンテンツデータを再生するコンテンツ再生の ステップと、 コンテンッデータの再生制御指示を与えるためのユーザ オペレーションに応じてプレーヤ手段に対する制御コマンドを生成す る制御コマンド生成のステップとを有し、 コンテンッ再生のステップ は、 記録媒体から再生指示情報毎に制限モードを示す値を読み出し、 読み出された制限モードを示す値に基づき再生指示情報毎にテーブル を生成し、 制御コマンド生成のステップで生成された制御コマンドの 実行を許可するか否かを、 テーブルに基づき再生指示情報毎に制御す るようにしたことを特徴とする再生方法で.ある。
また、 この発明は、 円盤状記録媒体に記録されたコンテンツデータ を再生する再生方法をコンピュータ装置に実行させる再生プログラム において、 再生方法は、 少なくともコンテンツデータと、 コンテンツ データに対する再生経路を指定し、 属性情報としてコンテンツデータ の再生制御指示に対する制限モードを示す値を含む再生指示情報と、 コンテンツデータの再生を制御する再生制御プログラムとが記録され た記録媒体からデ一夕を読み出す読み出しのステップと、 再生制御プ ログラムに従いコンテンツデータを再生するコンテンツ再生のステツ プと、 コンテンッデ一夕の再生制御指示を与えるためのユーザォペレ ーシヨンに応じてプレーヤ手段に対する制御コマンドを生成する制御 コマンド生成のステップとを有し、 コンテンツ再生のステップは、 記 録媒体から再生指示情報毎に制限モードを示す値を読み出し、 読み出 された制限モードを示す値に基づき再生指示情報毎にテーブルを生成 し、 制御コマンド生成のステップで生成された制御コマンドの実行を 許可するか否かを、 テーブルに基づき再生指示情報毎に制御するよう にしたことを特徴とする再生プログラムである。
また、 この発明は、 少なくともコンテンツデータと、 コンテンツデ —夕に対する再生経路を指定し、 属性情報としてコンテンツデ一夕の 再生制御指示に対する制限モードを示す値を含む再生指示情報と、 コ ンテンッデータの再生を制御する再生制御プログラムとが記録される ことを特徴とする記録媒体である。
また、 この発明は、 少なくともコンテンツデータと、 コンテンツデ —夕に対する再生経路を指定し、 属性情報としてコンテンツデータの 再生制御指示に対する制限モードを示す値を含む再生指示情報と、 コ ンテンッデ一夕の再生を制御する再生制御プログラムとを有すること を特徴とするデータ構造である。
上述したように、 この発明は、 少なくともコンテンツデータと、 コ ンテンッデ一夕に対する再生経路を指定し、 属性情報としてコンテン ッデータの再生制御指示に対する制限モードを示す値を含む再生指示 情報と、 コンテンツデータの再生を制御する再生制御プログラムとが 記録された記録媒体からデータを読み出し、 再生装置は、 コンテンツ データの再生を再生制御プログラムに従い行い、 再生指示情報毎に読 み出された制限モードを示す値に基づき再生指示情報毎にテーブルを 生成し、 コンテンッデ一夕の再生制御指示を与えるためのユーザオペ レ一ションに応じて生成された制御コ了ンドの実行を許可するか否か を、 テーブルに基づき再生指示情報毎に制御するようにしているため 、 コンテンツ制作の際に、 ユーザオペレーション対する制限を、 制限 モードに基づき再生指示情報単位で容易に設定することができると共 に、 再生装置側でも、 ユーザオペレーションに対する制限を制限モー ドに基づき容易に検証することができる。
また、 この発明は、 少なくともコンテンツデータと、 コンテンツデ 一夕に対する再生経路を指定し、 属性情報としてコンテンツデ一夕の 再生制御指示に対する制限モードを示す値を含む再生指示情報と、 コ ンテンッデータの再生を制御する再生制御プログラムとが記録媒体に 記録されているため、 コンテンツ制作の際に、 記録媒体を再生する再 生装置に対するユーザオペレーションによりなされる、 コンテンッデ 一夕に対する再生制御指示を、 制限モードに基づき容易に設定するこ とができると共に、 再生装置側でも、 ユーザオペレーションに対する 制限を制限モードに基づき容易に検証することができる。
また、 この発明によるデ一夕構造は、 少なくともコンテンツデータ と、 コンテンツデータに対する再生経路を指定し、 属性情報としてコ ンテンッデータの再生制御指示に対する制限モードを示す値を含む再 生指示情報と、 コンテンツデータの再生を制御する再生制御プロダラ ムとを有するため、 コンテンツ制作の際に、 このデータ構造を有する データを再生する再生装置に対するユーザオペレーションによりなさ れる、 コンテンツデータに対する再生制御指示を、 制限モードに基づ き容易に設定することができると共に、 再生装置側でも、 ユーザオペ レーシヨンに対する制限を制限モードに基づき容易に検証することが できる。
この発明は、 ュ一ザオペレーションの制限の組み合わせをモ一ドと して定義し、 頻繁に使用されるユーザオペレーションのセットを予め プレーヤ側で用意し、 コンテンツ制作者側では、 提供されたユーザォ ペレーションの組み合わせのモードを選択することで、 ユーザォペレ —ションに対する制御を実現するようにしている。
そのため、 コンテンツ制作者側は、 予めプレーヤ側で用意されたモ 一ドを選択するだけで、 ユーザオペレーションに対して制限を加える ことができるため、 より容易にユーザオペレーションの制御が可能と なると共に、 コンテンツ制作者側による制作および検証の際の負担が 軽減されるという効果がある。 図面の簡単な説明
第 1図は 従来の D V Dビデオ規格によるユーザオペレーション制 御を説明するための略線図、 第 2図は、 U M Dビデオ規格のレイヤ構 成を示す略線図、 第 3図は、 この発明の実施の一形態による一例のプ レ一ャモデルを模式的に示す略線図、 第 4図は、 ムービープレーヤの 一例の内部構成を示す略線図、 第 5図は、 ムービープレーヤの 3状態 を説明するための図、 第 6図は、 この発明の実施の一形態によるムー ビープレーヤのイベントモデルを模式的に示す略線図、 第 7図は、 プ レイリス卜の再生中に発生する一例のイベントを示す略線図、 第 8図 は、 ムービープレーヤオブジェクトが有する一例のプロパティを一覧 して示す略線図、 第 9図は、 ムービープレーヤオブジェクトが有する 一例のメソッドを一覧して示す略線図、 第 1 0図は、 ュ一ザ入力によ る一例のキー入力を示す略線図、 第 1 1図は、 ユーザ入力による一例 のキー入力を示す略線図、 第 1 2図 A、 第 1 2図 Bおよび第 1 2図 C は、 キ一入力に応じた一例の制御コマンドを示す略線図、 第 1 3図は 、 キー入力に対応する一例のイベントを示す略線図、 第 1 4図は、 一 例のイベントハンドラを示す略線図、 第 1 5図は、 一例のイベントハ ンドラを示す略線図、 第 1 6図は、 ユーザ入力イベントをきっかけと して、 用意されたプログラムが実行される一例の処理を示すフローチ ャ一ト、 第 1 7図は、 U M Dビデオプレーヤにディスクがロードされ てからイジェク卜されるまでの処理を概略的に示すフローチヤ一ト、 第 1 8図は、 スクリプトファイルの構成例を示す略線図、 第 1 9図は 、 イベントハンドラ onAutoPlayOを実行する一例の手順を示すフロー チヤ一ト、 第 20図は、 イベントハンドラ onContinuePIayOを実行す る一例の手順を示すフローチャート、 第 2 1図は、 再生終了時の一例 の処理を示すフローチャート、 第 2 2図は、 スクリプトプログラムの 例について説明するための図、 第 23図は、 一例のスクリプトプログ ラムを示す略線図、 第 24図は、 UMDビデオ規格に適用されるファ ィルの管理構造を説明するための略線図、 第 2 5図は、 ファイル "PLA YLIST.DAT"の全体構造を表す一例のシンタクスを示す略線図、 第 26 図は、 ブロック PlayltemOの一例の内部構造を示す略線図、 第 2 7図 は、 ブロック PlayListMarkOの一例の内部構造を示す略線図、 第 28 図は、 ブロック MarkO内のフィ一ルド markjypeについて説明するた めの図、 第 2 9図は、 クリップ AVストリームファイル内でのマーク 時刻の指定について説明するための図、 第 3 0図は、 クリップ AVス トリ一ムファイル" XXXXX.CLP"の全体構造を表す一例のシンタクスを 示す略線図、 第 3 1図は、 ブロック StreamlnfoOのエレメン夕リスト リームに対する関連付けを説明するための図、 第 32図は、 ブロック StaticInfoOの一例の内部構瑋を示す略線図、 第 33図は、 ブロック DynamicInfoOの一例の内部構造を示す略線図、 第 34図は、 ブロッ ク EP— mapOの一例の内部構造を示す略線図、 第 3 5図は、 この発明を 適用可能なディスク再生装置の一例の構成を概略的に示すブロック図 、 第 3 6図 Aおよび第 36図 Bは、 ディスク再生装置における動作を より詳細に説明するための機能ブロック図、 第 37図は、 この発明の 実施の一形態によるファイル" PLAYLIST.DAT"の一例のシンタクスを示 す略線図、 第 3 8図は、 フィールド U0P_mask— modeが表す値の意味を 例示する略線図、 第 39図は、 ムービープレーヤ内でユーザオペレー シヨン制限機能を実現するための一例の機能ブロック図、 第 40図は 、 コマンドフィルタテ一プルの一例の作成手順を示すフローチヤ一ト 、 第 41図は、 ユーザオペレーションマスクモード 「1」 に対応する 一例のコマンドフィルタテーブルを示す略線図、 第 42図は、 ユーザ オペレーションマスクモード 「2」 に対応する一例のコマンドフィル 夕テーブルを示す略線図、 第 43図は、 コマンドフィル夕テーブルを 用いてユーザォペレ一ションを制限する一例の処理を示すフローチヤ ートである。 発明を実施するための最良の形態
以下、 この発明の実施の一形態について、 下記の順序に従い説明す る。
1. UMDビデオ規格について
2. UMDビデオ規格のプレーヤモデルについて
3. ムービープレーヤのイベントモデルについて
4. ム一ビ一プレーヤオブジェクトについて
5. スクリブトプログラムの例
6. ファイルの管理構造について
7. ディスク再生装置について
8. ユーザオペレーションの制御について
1. UMDビデオ規格について
先ず、 理解を容易とするために、 この実施の一形態に適用可能なシ ステムについて概略的に説明する。 この発明の実施の一形態では、 E
CM Aスクリブトと呼ばれるスクリブト言語を用いてプレーヤモデル を記述している。 E CMAスクリプトは、 E CMA (European Comput er Manufacturers Association)により定められに、 J a v a S c r i p t (登録商標） に基づいたクロスプラットフォーム用のスクリブ ト言語である。 ECMAスクリプトは、 HTML文書との親和性が高 いことと、 独自のオブジェクトの定義が可能であるため、 この発明に よるプレーヤモデルに用いて好適である。
また、 以下では、 この ECMAスクリプトを元にしたスクリプト言 語を用いた、 この発明の実施の一形態に基づく規格を、 UMD OJnive rsal Media Disc：登録商標）ビデオ規格と呼ぶ。 また、 UMDビデオ 規格のうち、 特にスクリブトに関する部分を UMDビデオスクリブト 規格と呼ぶ。
UMDビデオ規格について、 概略的に説明する。 第 2図は、 UMD ビデオ規格のレイヤ構成を示す。 UMDビデオ規格では、 スクリプト レイヤ、 プレイリストレイヤおよびクリップレイヤの 3.層のレイヤ構 造が定義され、 この構造に基づきストリーム管理がなされる。
UMDビデオ規格においては、 ディジタル符号化されたビデオ、 ォ —ディォおよび字幕を、 M P E G 2 (Moving Pictures Experts Group 2)のエレメンタリストリームとして多重化した MP EG 2ストリー ムとして扱う。 このビデオ、 オーディオおよび字幕のエレメン夕リス トリ一ムが多重化された MP EG 2ストリームを、 クリップ AVスト リーム（Clip AV Stream)と呼ぶ。 クリップ A Vストリームは、 クリツ プ A Vストリームファイルに格納される。 クリップ A Vストリームフ アイルの記録時に、 当該クリップ A Vス小リームファイルに 1対 1に 対応して、 クリップインフォメーションファイル（Clip Information File)が同時に作成される。 これらクリップインフォメーションファ ィルと、 対応するクリップ AVストリームファイルとからなる組を、 クリップ（Clip)と呼ぶ。
クリ.ップは、 ディスクへの記録の単位ともいうべきものであり、 再 生時にどのような順序でクリップを再生するかは、 クリップの上位の レイヤであるプレイリストレイヤで管理する。 プレイリストレイヤは
、 クリップの再生経路を指定するレイヤであり、 1または複数のプレ イリスト（P yL i s t)を含む。 プレイリストは、 プレイアイテムの（P l a yl t em)の集合からなる。 プレイアイテムには、 クリップの再生範囲を 示した一組のイン（In)点およびァゥト（Out)点が含まれており、 プレ ィアイテムを連ねることによって、 任意の順序でクリップを再生する ことができるようになる。 プレイアイテムは、 クリップを重複して指 定することができる。 クリップ 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ビデオ に特有な機能を実現するための拡張を加えたスクリプトである。
スクリプトレイヤは、 プレイリストレイヤの上位のレイヤであり、 プレイリストの再生指示や、 プレーヤ設定を行うコマンド列から構成 される。 スクリプトレイヤのコマンドにより、 複数の言語用に用意さ れたストリームのうち何れを選択する、 ある条件に従って選択される プレイリストに再生の流れが変化する、 というような、 条件分岐を伴 うプレイリスト再生を実現することができる。 このような条件分岐を 伴うプレイリスト再生が用いられるアプリケーションの例としては、 マルチストーリ一が挙げられる。 このスクリプトレイヤにより、 ユー ザとの双方向性機能 （インタラクティブ機能） が導入されることにな る。
なお、 この発明の実施の一形態では、 スクリプトレイヤは、 1つの ファイル" SCRIPT. DAT"から構成され、 リソースとして管理される。 フ アイル" SCRIPT. DAT"は、 実際の E C M Aスクリブトに基づき記述され るスクリブトデータ、 ポタン操作の際の効果音などを出力するための サウンドデータ、 メニュー画面の背景画像などに用いる画像データか らなるスクリーンデザイン、 ならびに、 ポタン画像などの G U I部品 を表示させるための画像データ （ビットマップデータ） が含まれる。 2 . U M Dビデオ規格のプレーヤモデルについて
次に、 U M Dビデオ規格に従ったデータを再生する再生装置 （プレ ーャ） のモデル、 すなわち、 プレーヤモデルについて説明する。 プレ ーャは、 先ず、 ディスクからスクリプトプログラム、 プレイリストお よびクリップインフォメ一ションファイルを読み出し、 次に、 これら により定められている再生順序に従って、 クリップ A Vストリームフ アイルを読み出し、 ビデオ、 オーディオおよび字幕などを再生する。 スクリプトプログラムの言語仕様においては、 プレイリストを再生 する機能ブロックを、 スクリプトプログラム内のオブジェクトとして 実装する。 このプレイリスト再生を行うオブジェクトを、 U M Dビデ ォ規格では、 ムービープレーヤ（Mov i e P l ayer)オブジェクトと呼ぶ。 プレイリストの再生指示や、 プレーヤ設定を行うコマンドは、 このム 一ビープレーヤオブジェクトが有するメソッドとなる。 ムービープレ ーャォブジェクトは、 スクリブトレイヤからのメソッドによって制御 される。 このとき、 ムービープレーヤオブジェクトからスクリプトレ ィャに対して、 状態の変化や再生位置などを通知する機能が必要とな る。 これは、 ム一ビープレーヤオブジェクトがスクリプトプログラム に対してイベントを発することに対応し、 そのイベントに対応した処 理は、 イベントハンドラとして記述される。
このように、 ムービープレーヤオブジェクトからスクリプトプログ ラムへの情報伝達は、 イベントにより行い、 スクリプトプログラムか らム一ビ一プレーヤオブジェクトに対する制御をメソッドにより行う モデルを構築することにより、 クリップ A Vストリームの再生をスク リプトプログラムで制御できるようになる。
第 3図は、 上述した、 この発明の実施の一形態による一例のプレー ャモデルを模式的に示す。 ム一ビープレーヤ 3 0 0は、 U M Dビデオ 規格においてビデオ、 オーディォおよび字幕の再生を司るモジュール である。 上述したムービープレーヤオブジェクトは、 ムービーォブジ ェクトをスクリブトプログラムから操作するためにスクリプトプログ ラム内のオブジェクトとしたものである。 換言すれば、 ムービープレ ーャォブジェク卜は、 ムービープレーヤの機能を実現するためのスク リプトプログラムそのものである。
なお、 ムービープレーヤ 3 0 0とムービープレーヤオブジェク卜は 、 実質的に同一の対象を表すと考えられるので、 以下、 これらを同一 の符号を付して説明する。
第 3図において、 ム一ビプレーヤ 3 0 0は、 ュ一ザ入力 3 1 0など により引き起こされる下位レイヤ （第 3図の例ではネィティブ実装プ ラットフオーム 3 0 1 ) や、 上位レイヤであるスクリプトレイヤ 3 0 2からのメソッドに従って、 プレイリストおよびクリップインフォメ —シヨンのデータベースに基づき、 クリップ A Vストリームファイル の読み出し、 読み出されたクリップ A Vストリームのデコードおよび 表示を行う。
ムービープレーヤオブジェクト 30 0の内部は、 UMDビデオを再 生する UMDビデオプレーヤの実装に依存するものであって、 スクリ ブトレイヤ 3 02からは、 ブラックボックス化されたオブジェクトと して、 メソッドゃプロパティといった A P I (Application Prograimi ng Interface)が提供される。 ここで、 UMDビデオプレーヤは、 ム —ビープレーヤを実装した実際の機器を指す。 全ての UMDビデオプ レ一ャは、 UMDビデオ規格の制約を守ってム一ビープレ一ャを実装 しており、 再生互換を有する。
第 3図に示されるように、 ム一ビープレ一ャォブジェクト 3 00は 、 ネィティブ実装ブラットフオーム 3 0 1からの制御コマンド 3 1 1 を受け付けるパス、 スクリプトレイヤ 302に対してイベント 3 1 2 を通知するパス、 スクリプトレイヤ 3 02からのメソッド 3 1 3を受 け付けるパスの、 3本の入出力パスを有する。
制御コマンド 3 1 1は、 ネィティブ実装のプラットフォーム 30 1 からの、 ムービープレーヤオブジェクト 300の動作を制御するコマ ンドである。 ネイティブ実装プラットフォーム 30 1は、 例えば、 実 際の機器としての UMDビデオプレーヤにおける、 機器に固有の部分 とムービープレーヤ 30 0とのインタ一フェイスである。 イベント 3 1 2は、 ムービープレーヤ 300からスクリプトレイヤ 302に対す るスクリプトイベントである。 メソッド 3 1 3は、 スクリプトレイヤ 302のスクリブトプログラムからムービープレーヤ 3 00に指示さ れるメソッドである。
ムービープレーヤオブジェクト 30 0は、 内部に、 UMDビデオ規 格のプレイリストおよびクリップインフォメーションのデータベース 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は、 プレイ、 ストップおよびポー ズの 3状態を持ち、 制御命令やメソッドによって、 この 3状態の間を 遷移する （第 4図参照） 。
スクリプトレイヤ 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 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 cal U ser Int er f ace)を構成するための部品画像 （以下、 G U I部品と呼ぶ ) の配置や表示、 ならびに、 G U I部品に対して選択や決定などの操 作がなされたときの処理は、 スクリプトレイヤ 3 0 2が行うというよ うに、 役割分担がなされている。
ネィティブ実装プラットフオーム 3 0 1は、 ムービープレーヤォブ ジェクト 3 0 0やスクリブトプログラムが動作するための基盤となる プラットフォームであって、 例えば、 実際の U M Dビデオプレーヤが ハ一ドウエアである場合、 ハ一ドウエアとプレーヤモデルとの間の処 理を仲介する役割を果たすように、 ハードウェアに固有に実装される 例えば、 ネイティブ実装プラットフォーム 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 0についてより詳細に説明する。 第 4 図は、 ムービープレーヤ 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 2 またはネイティブ実装プラットフォーム 3 0 1からの指示に従い、 指 定されたプレイリス卜を再生する。 例えば、 ムービープレーヤ 3 0 0 は、 デ一夕ベース 3 2 0を参照し、 指定されたプレイリストに対応す るクリップ A Vストリームの再生位置をフ.アイル中のバイト位置で得 る。 プレイバックモジュール 3 2 1において、 デコーダエンジン 3 2 2は、 この再生位置情報に基づき、 クリップ A Vストリームのデコ一 ドを制御する。
ムービープレーヤ 3 0 0は、 第 5図に示されるように、 プレイリス 卜の再生状況に応じてプレイ（p l ay)、 ストップ（s t op)およびポーズ（p ause)の 3状態を持つ。 プレイ状態は、 プレイリス卜の再生を行って おり、 時間が経過している状態を指す。 通常再生の他、 2倍速、 \ / 2倍速といった変速再生や、 順方向早送りおよび逆方向早送りもプレ ィ状態に含まれる。 ポーズ状態は、 プレイリストの再生を行っている 状態で、 時間軸が停止している状態である。 再生をフレーム単位で進 めたり戻したりする所謂コマ送り再生は、 ポーズ状態とプレイ状態と を繰り返している状態である。 ストップ状態は、 プレイリストを再生 していない状態である。 例えば、 ムービープレーヤ 3 0 0の状態は、 ムービープレーヤ 3 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の動作を制御する。
第 6図は、 この発明の実施の一形態によるムービープレーヤ 3 0 0 のイベントモデルを模式的に示す。 第 6図において、 イベントハンド ラ onEventAO、 onEventB 0および onEventC 0は、 インターフェイスで あって、 それぞれのイベントハンドラの内容は、 スクリプトで記述さ れている。 イベントハンドラの内容は、 例えばコンテンツ制作者側で 作成され実装される。 UMDビデオスクリプト規格においては、 ムー ビープレーヤオブジェクト 3 0 0からスクリプトプログラムに通知さ れるイベント毎に、 イベントハンドラが用意される。 第 6図の例では 、 イベント Aが発生したときに実行される処理プログラムは、 ィベン トハンドラ onEventAOに決められている。 イベント Bおよびイベント Cについても同様に、 ィベント Bの発生時には対応するィベントハン ドラ onEventBOが実行され、 イベント Cの発生時には対応するィベン トハンドラ onEventCOが実行される。
イベント発生に応じて呼び出されるイベントハンドラは、 システム 側で選択されるため、 コンテンツ制作者側では、 どのイベントが発生 したかを判断する処理を、 スクリブトプログラム内に記述しておく必 要が無い。
第 7図は、 プレイリストの再生中に発生する一例のイベントを示す 。 プレイリスト PlayListの先頭には、 チヤプタマーク ChapterMarkが 設定されているので、 プレイリストの先頭からの再生開始時には、 先 ず、 チヤプタマークに対応したイベント Chapterが発生する。 さらに 、 チヤプ夕が変わる度にイベント Chapterがスクリプトレイヤ 3 0 2 に通知され、 対応するイベントハンドラ onChapterが実行される。 ま た、 イベントマーク EventMarkが設定されている時刻に再生が到達す ると、 対応するマークイベントが発生する。 そして、 プレイリストの 最後まで再生が到達すると、 プレイリストの最後で再生が一時停止し 、 イベント P l ayL i s tEndがムービープレ一ャ 3 0 0からスクリプトレ ィャ 3 0 2に通知される。 スクリプトレイヤ 3 0 2側では、 対応する イベントハンドラ onP l ayLi s tEnd O内で、 別のプレイリストの再生開 始が指示される。 このようにして、 コンテンツ制作者が意図した順序 で、 一連のプレイリスト再生が継続されていく。
このように、 プレーヤの動作中にはさまざまなイベントが発生する ものとし、 イベント発生を上位プログラムに伝えることで、 上位プロ グラムはプレーヤの状態を把握できるようになる。 上位プログラムの 方では、 各イベント発生通知時に実行されるプログラム （イベントハ ンドラ） を用意しておくことで、 各種イベント発生に対処する。 ィべ ントおよびイベントハンドラの詳細については、 後述する。
イベントハンドラがコンテンツ制作者によって記述されていない場 合には、 規格で規定されているプレーヤ組み込みの動作 （デフォルト のイベントハンドラ） を実行するか、 あるいは、 そのイベントが無視 され何も実行されない。 何も処理を行う必要がないときには、 ィベン トに対応したィベントハンドラを記述しないようにすることで、 積極 的にイベントを無視することができる。
イベントモデルとしては、 上述の他に、 あるイベントに対応するリ スナをォブジェクトがプレーヤオブジェクトに登録し、 プレーヤォブ ジェクト内で発生したイベントが登録されたイベントであれば、 プレ ーャォブジェクトから当該イベントを登録したオブジェクトにィベン トを送信し、 当該オブジェクトで対応するメソッドを実行するように したイベントリスナのモデルや、 どのようなイベントが発生しても一 つのメソッドを呼び出すようにした単一メソッドのモデルなどが考え られる。
この実施の一形態によるイベントモデルは、 イベント登録、 ィベン ト登録削除といった処理が必要なイベントリスナのモデルよりも簡単 である。 また、 単一メソッドのモデルは、 どのイベントが発生したか を知り、 イベント毎に用意してある処理ルーチンを切り替えるという 前処理を、 そのメソッドの中に記述しておく必要がある。 メソッドは 、 コンテンツ制作者側が実装するものであるから、 モデルとしては簡 単でも、 コンテンツ制作者側の負担が大きくなる。 さらに、 大きな一 つの処理プログラム （メソッド） がイベントの発生毎に呼ばれること になり、 メモリの領域を多く占有し、 実行速度も遅くなると考えられ る。 この発明の実施の一形態による、 イベント毎に処理プログラム （ イベントハンドラ） を用意するモデルで 、 このような点について有 利であるといえる。
4 . ムービープレーヤオブジェクトについて
次に、 ムービープレーヤオブジェクト 3 0 0の外部的な仕様につい て説明する。 一般に、 E C M Aスクリプト言語仕様に従う言語により 定義されたオブジェクトは、 プロパティとメソッドとを持つ。 この実 施の一形態によるムービープレーヤオブジェクト 3 0 0も、 第 3図お よび第 4図を用いて既に説明したように、 同様にしてプロパティとメ ソッドとを有する。 プロパティは、 外部のオブジェクトから、 対象と なるオブジェクト名とプロパティ名とを指定することで、 直接的に読 み書きすることが可能である。 これに限らず、 プロパティ値の設定を 行うメソッド se tXXX O ( 「XXX」 は、 対象のプロパティ名） や、 プロ パティ値の読み出しを行うメソッド ge tXXX Oを定義することで、 他の オブジェクトのプロパティの読み書きを、 メソッドで行うことが可能 となる。
第 8図は、 ムービープレーヤオブジェクト 3 00が有する一例のプ 口パティを一覧して示す。 これは、 第 4図におけるプロパティ 3 23 に対応する。 第 4図におけるリードオンリーパラメータ 32 3 Aに属 するプロパティは、 以下の通りである。 プロパティ scriptVersionは 、 UMDビデオスクリプトのバージョンを示す。 プロパティ language Codeは、 UMDビデオプレーヤに設定された、 メニュー表示言語の言 語コードを示す。 プロパティ audioLanguageCodeは、 UMDビデオプ レーャに設定された、 オーディオ言語の言語コードを示す。 プロパテ ィ subtitleLanguageCodeは、 UMDビデオプレーヤに設定された、 字 幕 （サブタイトル） 言語の言語コードを示す。
ディスクが装填された際には、 このリードオンリ一パラメータ 3 2 3 Aに設定されたプロパティ languageCodeに示される言語コードに基 づき、 ディスクから読み出すスクリプトファイルが決められる。 装填 されたディスクに、 当該言語に対応するスクリプトファイルがない場 合は、 デフォルトのスクリプトファイルが読み出される。 例えば、 複 数のスクリブトファイルのうち、 ディスク上で最も先頭側に配置され るファイルがデフォルトのスクリプ卜ファイルとして読み出される。 第 4図におけるプレーヤステータス 32 3 Bに属するプロパティは 、 以下の通りである。 プロパティ playListNumberは、 現在再生中のプ レイリストの番号を示す。 プロパティ chapterNumberは、 現在再生中 のチヤプ夕の番号を示す。 プロパティ videoNumberは、 現在再生中の ビデオストリームの番号を示す。 プロパティ audioNumberは、 現在再 生中のォ一ディォストリームの番号を示す。 プロパティ subtitleNumb erは、 現在再生中の字幕ストリームの番号を示す。 プロパティ playLi stTimeは、 プレイリスト先頭を 0としたときの時刻を示す。 プロパテ ィ audioFlagは、 オーディォ再生の ON/0 F Fおよびデュアルモノ LRの指定を示す。 プロパティ subtiUeFIagは、 字幕表示の ONZO F Fを示す。
なお、 デュアルモノは、 ステレオオーディオの左右 （L、 R) チヤ ンネルを、 互いに独立したモノラルオーディオチャンネルとして用い るモードである。
このプレーヤステータス 3 23 Bに属する各プロパティは、 ムービ 一プレーヤ 300が再生または一時停止状態のときに、 これらの情報 が存在する。 停止状態に遷移した場合、 その時点でプレーヤステ一夕 ス 3 2 3 Bに属する各プロパティは、 リジュームインフォメーション 324としてバックアツプされる。 このとさ、 プレーヤステータス 3 23 Bの内容をクリアしてもよい。
第 9図は、 ムービープレーヤオブジェクト 3 0 0が有する一例のメ ソッドを一覧して示す。 これは、 第 3図におけるメソッド 3 1 3に対 応する。 メソッド playOは、 ビデオを再生する。 メソッド playCtiapte r()は、 チヤプタを指定してビデオを再生する。 メソッド stopOは、 ビデオの再生を停止する。 メソッド pauseOは、 ビデオの再生を一時 停止する。 メソッド playStepOは、 ビデオをコマ送り再生する。 メソ ッド changeStreamOは、 ビデオストリーム、 オーディオストリームお よび/または字幕ストリームを変更する。 メソッド getPlayerStatus( )は、 ム一ビープレーヤ 3 00における再生、 停止、 一時停止などの 状態を取得する。 メソッド resetOは、 ビデオの再生を停止し、 リジ ユームインフォメーション 324の内容をクリアする。
UMDビデオ規格では、 表示画面上の一部分にビデオを表示するこ とができるようになつている。 以下の 4つのメソッドは、 この場合の ビデオ表示に関するメソッドである。 メソッド setPosOは、 ビデオの 表示位置を設定する。 メソッド getPosOは、 ビデオの表未位置を取得 する。 メソッド setSizeOは、 ビデオの表示サイズを設定する。 メソ ッド getSizeOは、 ビデオの表示サイズを取得する。
なお、 実際には、 ム一ビープレーヤ 3 00とネイティブ実装プラッ トフオーム 3 0 1とは、 一体的に構成される。 すなわち、 実際にディ スクが装填され、 これを再生するハードウエアとしての UMDプレー ャと、 UMDプレーヤを制御するソフトウエアとの関係に対応付けら れ、 どの部分をハードウェアで行い、 どの部分をソフトウェアで行う かは、 実装時の構成に依存する。 例えば、 UMDプレーヤをパ一ソナ ルコンピュータなどで構成する場合は、 ディスクドライブ以外は、 ソ フトウェア的に構成することができる。 また、 単体の UMDプレーヤ として構成する場合は、 ディスクドライブ以外に、 例えばビデオデコ —ダゃオーディォデコーダなどをハードウエア的に構成することがで きる。 したがって、 ムービープレーヤ 3 00とネイティブ実装プラッ トフオーム 3 0 1との間でなされるメソッドやコマンド、 イベントは 、 第 3図に一例が示されるような明示的なやりとりに限られない。 一方、 ユーザからのキー入力については、 第 3図を用いて既に説明 したように、 ユーザ入力 3 1 0をネイティブ実装プラットフオーム 3 0 1が先ず、 受け取る。 つまり、 ネイティブ実装プラットフォーム 3 0 1は、 ユーザからのキー入力をユーザ入力 3 1 0として受け取り、 ュ一ザ入力 3 1 0がムービープレーヤ 3 00に対するコマンドなのか 、 スクリプトレイヤ 3 02のスクリプトプログラムに対するイベント なのかを判定し、 判定結果に応じて、 制御コマンド 3 1 1またはキー イベント 3 14を発生し、 対応する上位レイヤ （ムービープレーヤ 3 00またはスクリプトレイヤ 30 2 ) に通知する。
第 1.0図および第 1 1図は、 ユーザ入力 3 1 0による一例のキー入 力を示す。 なお、 第 1 0図および第 1 1図に示される 「νκ」 で始まる 各キーは、 実装に依存しない抽象化した仮想的なキーである。 第 1 0 図は、 ムービープレーヤ 3 0 0の操作に関する一例のキー入力を示す 。 キ一 VK_P0WERは、 電源キーに対応する機能を提供する。 キー VK— P0W ER— ONは、 電源 O Nキーに対応する機能を提供する。 キー VK— POWER一 OF Fは、 電源 O F Fキーに対応する機能を提供する。 キー VK_MENUは、 メ ニューを表示させるメニューキーに対応する機能を提供する。 キー VK —ENTERは、 「決定」 を指示する決定キーに対応する機能を提供する。 キー VK_RETURNは、 処理のステップを一つ戻す戻るキーに対応する機 能を提供する。
キー VK_PLAYは、 再生を指示する再生キーに対応する機能を提供す る。 キー VK— STOPは、 再生の停止を指示する停止キーに対応する機能 を提供する。 キー VK—PAUSEは、 再生の一時停止を指示する一時停止キ 一に対応する機能を提供する。 キー VK_FAST— FORWARDは、 早送り再生 を指示する早送りキーに対応する機能を提供する。 キー VK_FAST_REVE RSEは、 早戻し再生を指示する早戻しキーに対応する機能を提供する 。 キー VK— SLOW— FORWARDは、 順方向のスロー再生を指示するスロー （ 順方向） キーに対応する機能を提供する。 キー VK_SLOW_REVERSEは、 逆方向のスロー再生を指示するスロー （逆方向） キーに対応する機能 を提供する。 キー VK— STEP— FORWARDは、 順方向のコマ送り再生を指示 するコマ送り （順方向） キーに対応する機能を提供する。 キー VK_STE P_REVERSEは、 逆方向のコマ送り再生を指示するコマ送り （逆方向） キーに対応する機能を提供する。
第 1 1図は、 メニュー操作に関する一例のキー入力を示す。 キー VK jEXTは、 「次」 を意味する値を入力する次指定キーに対応する機能 を提供する。 キー VK_PREVI0USは、 「前」 を意味する値を入力する前 指定キーに対応する機能を提供する。 例えば、 キー VK_NEXTおよびキ 一 VK_PREVIOUSを用いて、 前後のチヤプ夕への移動を指示することが できる。
キー VKJJPは、 「上」 を意味する値を入力する上方向指定キーに対 応する機能を提供する。 キ一 VK_D0WNは、 「下」 を意味する値を入力 する下方向指定キーに対応する機能を提供する。 キー VK— RIGHTは、 「 右」 を意味する値を入力する右方向指定キーに対応する機能を提供す る。 キ一VK一 LEFTは、 「左」 を意味する値を入力する左方向指定キー に対応する機能を提供する。 キー VK_UP_RIGHTは、 「右上」 を意味す る値を入力する右上方向指定キ一に対応する機能を提供する。 キ一 VK — UP_LEFTは、 「左上」 を意味する値を入力する左上方向指定キーに対 応する機能を提供する。 キー VK_D0WN— RIGHTは、 「右下」 を意味する 値を入力する右下方向指定キーに対応する.機能を提供する。 キー VK_D 0WN_LEFTは、 「左下」 を意味する値を入力する左下方向指定キーに対 応する機能を提供する。 これらの方向キーを用いることで、 例えば画 面上のカーソル表示の移動を指示することができる。
キー VK_ANGLEは、 マルチアングルのビデオに対するァンダル切り替 えを指示するアングル切り替えキーに対応する機能を提供する。 キー VK_SUBTITLEは、 英語字幕、 日本語字幕、 字幕表示 Z非表示などを切 り替える字幕切り替えキ一に対応する機能を提供する。 キー VK— AUDIO は、 サラウンドやバイリンガルなどオーディォ設定を切り替えるォ一 ディォ切り替えに対応する機能を提供する。 キー VK— VIDE0_ASPECTは 、 ビデオのァスぺクト比切り替えを指示するァスぺクト切り替えキー に対応する機能を提供する。 キー VK_C0L0RED— KEY_1は、 色つきファン クシヨンキ一 1、 キ一 VK—C0L0RED_KEY一 2は、 色つきファンクションキ 一 2、 キー VK—C0L0RED KEY 3は、 色つきファンクションキー 3、 キー VK_C0L0RED— KEY— 4は、 色つきファンクションキー 4、 キ一VK— COLORED —KEY— 5は、 色つきファンクションキー 5、 キー VK— COLORED— KEY_6は、 色つきファンクションキー 6にそれぞれ対応する機能を提供する。 上述の第 1 0図に示したキ一入力と第 1 1図に示したキー入力とで は役割が異なるため、 通知先をネイティブ実装プラットフォーム 3 0 1で振り分ける必要がある。 上述したように、 第 1 0図に示されるキ 一入力により、 ビデオ、 オーディオおよび字幕の再生に関する指示が なされる。 ネィティブ実装プラットフオーム 3 0 1は、 ユーザ入力 3 1 0として第 1 0図に示されるキー入力を受け取ると、 受け取ったキ 一入力を、 第 1 2図 A、 第 1 2図 Bおよび第 1 2図 Cに示すコマンド に変換してム一ビープレーヤ 3 0 0に通知する。
一方、 第 1 1図に示されるキー入力は、 G U Iに対するユーザ入力 3 1 0であるので、 このユーザ入力は、 画面構成やポタンを配置する スクリブトレイヤ 3 0 2に通知されて処理される必要がある。 ネィテ ィブ実装プラットフオーム 3 0 1は、 ユーザ入力 3 1 0として第 1 1 図に示されるキー入力を受け取ると、 第 3図におけるイベント 3 1 4 に変換してスクリブトレイヤ 3 0 2に通知する。 第 1 3図は、 このキ 一入力に対応する一例のイベント 3 1 4を示す。
なお、 上述した第 1 0図および第 1 1図には、 キ一 VK— ANGLE、 キー VK— SUBTITLE、 キ一 VK_AUDI 0という、 ストリーム切り替えに関するキ —入力も含まれているが、 これらは、 スクリプトプログラムからムー ビ一プレーヤ 3 0 0に対するストリーム切り替えのメソッドと同様の 機能を実現するためのキー入力である。
上述した第 1 2図 A、 第 1 2図 Bおよび第 1 2図 Cのコマンドにつ いて、 より詳細に説明する。 コマンド uo一 t imeSearch (pl ayL i s tTime) は、 再生中のプレイリストの指定時刻からの再生を指示する。 引数 p i ayListTimeは、 プレイリストの先頭を 0としたときの時刻を表す。 こ のコマンドでは、 プレイリスト番号の指定はできないため、 引数 play ListTiraeで表される時刻は、 現在再生中のプレイリストの範囲内での 指定時刻となる。 コマンド uo_play()は、 例えば 1倍速といった所定 の再生速度での再生開始を指示する。 開始位置は、 リジュームインフ オメーシヨン 3 24に基づき決められる。 リジユームィンフオメーシ ヨン 3 24に対応する情報が無い場合は、 このュ一ザ操作は無効とさ れる。 このコマンドは、 プレイリスト番号の指定の無いメソッド play 0を実行したときに対応する。 また、 このコマンドにおいて、 ユーザ 操作ではプレイリスト番号を指定できない。
コマンド uo— playChapter(chapterNumber)は、 再生中のプレイリス トの、 引数 chapterNumberで指定されたチヤプ夕からの再生開始を指 示する。 チヤプ夕の指定がない場合には、 現在再生中のチヤプタの先 頭からの再生開始を指示する。 これは、 チヤプ夕番号の指定の無いメ ソッド playChapterOに対応する。 コマンド uo_playPrevChapter 0は 、 現在よりも一つ前のチヤプタからの再生開始を指示する。 コマンド uo一 playNextCliapterOは、 現在の次のチヤプ夕からの再生開始を指示 する。 コマンド uo— stopOは、 再生の停止を指示する。
コマンド uoJumpToEndOは、 プレイリストの最後へのジャンプを指 示する。 このコマンドは、 ムービープレーヤ 300に対して、 現在の 再生を中止してイベント layListEndを発生させるように指示するュ 一ザ操作に対応する。 このコマンドに対応して、 スクリプトレイヤ 3 02では、 イベントハンドラ onPlayListEndが実行される。 コマンド u 0— iorwardScan(speed)は、 引数 speedで指定された再生速度での順方 向再生を指示する。 コマンド uo— backwardScan(speed)は、 引数 speed で指定された再生速度での逆方向再生を指示する。 これらコマンド uo — forwardScan(speed)およびコマンド uo— backwardScan (speed)におけ る引数 speedは、 UMDビデオプレーヤの実装に依存する。
コマン uo—playStep(forward ¾、 順方向のコマ送り再生を指示す る。 コマンド uo_pIayStep(backward)は、 逆方向のコマ送り再生を指 示する。 コマンド uo— pauseOnOは、 ユーザ操作に基づき再生の一時停 止を指示する。 コマンド uo— pauseOff 0は、 ユーザ操作に基づき再生 の一時停止状態を解除する。
コマンド uo— changeAudioChannel (value)は、 オーディォのチヤンネ ル切り換えまたはデュアルモノ再生時の片チャンネル切り替えを指示 する。 このコマンドの実行時に、 フラグ audioFlagの値も対応した内 容に変更する。 コマンド uo一 setAudioEnabled(boolean)は、 オーディ ォストリームの ONZOF Fを指定する。 このコマンドの実行時に、 フラグ audioFlagの値も対応した内容に変更する。 コマンド uo_setSub UtleEnabled (boolean)は、 字幕ストリームの ON/OF Fを指定す る。 このコマンドの実行時に、 フラグ subtitleFlagの値も対応した内 容に変更する。 コマンド uo_angleChange()は、 表示アングルの変更を 指示する。 このコマンドによるユーザ操作がムービープレーヤ 30 0 に伝えられると、 ムービープレーヤ 3 0 0は、 スクリプトレイヤ 3 0 2に対してィベント angleChangeを通知する。 コマンド uo— audioChang e(audioStreamNumber)は、 再生するオーディオストリームの変更を指 示する。 コマンド uo一 subtitleChange(subtiUeStreamNumber)は、 再 生する字幕ス卜リームの変更を指示する。
上述した第 1 3図に示すイベントおよびイベントのムービープレー ャ 300のメソッドとの関係について、 より詳細に説明する。 ィベン ト menuは、 メニューにジャンプする。 このイベントは、 ム一ピ一プレ —ャ 3.00に対してではなく、 ネイティブ実装プラットフオーム 3 0 1からスクリプトレイヤ 3 0 2に通知される。 このイベント menuがス クリブトレイヤ 3 0 2に受け取られると、 スクリプトレイヤ 3 02は 、 イベントハンドラ onMenuを実行する。 イベント exitは、 ネイティブ 実装プラットフオーム 30 1が UMDビデオアプリケーションを終了 させる際に、 ネイティブ実装プラットフォーム 30 1から発せられる イベントである。 このイベント exitがスクリブトレイヤ 302に受け 取られると、 スクリプトレイヤ 302は、 イベントハンドラ onExitを 実行する。
イベント up、 イベント down、 イベント left、 イベント right、 ィべ ン卜 focusIn、 イベント focusOut、 ィベン卜 pushおよびイベント cance 1は、 画面に表示されている GU I部品であるポタン画像にフォ一力 スが当たっている場合に発生するイベントである。 このイベントは、 ムービープレーヤ 300に対してではなく， ネィティブ実装ブラット フォーム 30 1からスクリプトレイヤ 302に通知される。 なお、 ポ タン画像にフォーカスが当たった場合とは、 例えば、 画面上の位置を 指示するためのカーソルがポタン画像の表示座標を示し、 当該ポタン 画像が選択可能となっているような状態である。 イベント up、 ィベン ト down、 ィベンド leftおよびイベント rightは、 ボタン画像に対する フォーカスが、 それぞれ上、 下、 左および右のポタン画像に移動した 場合に発生する。 イベント focuslnは、 あるポタン画像にフォーカス が当たった場合に発生し、 イベント iocusOutは、 フォーカスの当たつ ていたポタン画像からフォーカスが外れた場合に発生する。 また、 ィ ベント pushは、 フォーカスの当たっているポ夕ン画像に対して押下操 作が行われた際に発生する。 イベント cancelは、 ポタン画像の押下操 作に対してキャンセル操作が行われた際に発生する。
ィベント autoPlayおよびィベント cont inuePlayは、 スクリプトレイ ャ 3 0 2におけるスクリプトの実行開始を指示するイベントである。 イベント aut oP l ayは、 ディスクの装填時に自動的にスクリブトの実行 を開始するように指示するイベントである。 イベント cont i nueP l ayは 、 ディスク装填時に、 例えばリジュームインフォメーション 3 2 4に 基づき、 以前中止された時点からのスクリプトの実行再開を指示する 第 1 3図で示したイベントに対しては、 イベントが発生したときに 実行されるプログラムが存在する。 このイベントに対応したプログラ ムをイベントハンドラと称する。 イベントとイベントハンドラとは、 例えば名前で対応関係をつけることができる。 一例として、 イベント 名の先頭に 「on」 を付加したものがイベントハンドラ名となる。 第 1 4図および第 1 5図は、 一例のイベントハンドラを示す。 イベントハ ンドラの内容をコンテンツ制作者が記述することにより、 U M Dビデ オプレ一ャにコンテンツ制作者が意図する様々な動作を実行させるこ とが可能になる。
第 1 4図は、 ムービープレーヤオブジェクト 3 0 0が持つ一例のィ ベントの一部と、 対応するイベントハンドラとを示す。 この第 1 4図 のイベントは、 上述した第 3図のイベント 3 1 2に対応し、 ムービー プレーヤ 3 0 0からスクリプトレイヤ 3 0 2に通知される。 イベント ハンドラは、 一種のインターフェイスであって、 その内容は、 例えば コンテンツ制作者がスクリブト言語を用いて実装する。 イベントハン ドラをこのように構成することで、 イベント発生時に、 コンテンツ制 作者の意図する動作を実現することができる。
ィベント markおよびィベントハンドラ onMark Oは、 イベントマーク が検出された際に実行される。 イベントマークは、 例えば、 プレイリ スト中に埋め込まれ、 プレイリストの再生中にム一ビ一プレーヤ 3 0 0により検出される。 ムービープレーヤ 3 00によりイベントマーク が検出されると、 ムービープレーヤ 30 0からスクリブトレイヤ 3 0 2に対してイベント markが通知される。 スクリプトレイヤ 3 0 2は、 このィベント markに対応するィベントハンドラ onMarkOを実行する。 同様にして、 イベント palyListEndおよびイベントハンドラ onPlayLis tEndOは、 プレイリストが終了した際に実行される。 イベント chapte rおよびイベントハンドラ onChapterOは、 チヤプタマーク検出時に実 行される。 チヤプ夕マークは、 例えば、 プレイリスト中に埋め込まれ 、 プレイリストの再生中にムービープレーヤ 300により検出される 。
ィベント angleChangeおよびィベントハンドラ onAngleChangeOは、 ユーザ操作によりアングル変更が指示されたときに実行される。 例え ば、 ユーザ操作に応じてキー入力 VK_ANGLE.がユーザ入力 3 1 0として ネイティブ実装プラットフオーム 30 1に入力されると、 ネイティブ 実装プラットフォーム 30 1は、 当該ユーザ入力 3 1 0をコマンド uo — angleChangeOに変換してムービープレーヤ 30 0に渡す。 ムービー プレーヤ 30 0は、 このコマンド uo_angleChange()に応じてィベント angleChangeを発生させ、 スクリプトレイヤ 302に渡す。 スクリプ トレイヤ 30 2は、 このィベント angleChangeに対応したィベントハ ンドラ onAngleChangeOを実行する。 同様にして、 イベント audioChan geおよびイベントハンドラ onAudioChangeOは、 ュ一ザ操作によりォ 一ディォの変更が指示されたときに実行される。 イベント subtitleCh angeおよびイベントハンドラ onSubtitleChangeOは、 ユーザ操作によ り字幕変更が指示されたときに実行される。
第 1 5図は、 システムオブジェクトが有する一例のイベントハンド ラの一部を示す。 この第 1 5図に示されるイベントハンドラは、 ネィ ティブ実装プラットフオーム 30 1が予め持っているィペントハンド ラであり、 ネィティブ実装プラットフオーム 3 0 1からスクリプトレ ィャ 3 0 2に通知される。
ィベント menuおよびィベントハンドラ onMenuOは、 メニューにジャ ンプする。 イベント menuは、 例えば、 ユーザ操作などでメニューキー が押下されたときに、 ネイティブ実装プラットフオーム 3 0 1からス クリブトレイヤ 3 02に通知されるイベントである。 スクリプトレイ ャ 30 2は、 このイベントを受けて、 対応するイベントハンドラ onMe nu()を実行し、 イベントハンドラ onMenuO内でメニュー画面を構成す る GU I部品の配置や表示などを行う。 イベント exitおよびイベント ハンドラ onExitOは、 ネイティブ実装プラットフオーム 30 1が UM Dビデオアプリケーションを終了させる際に、 ネィティブ実装プラッ トフオーム 3 0 1から発せられるィベンドおよび対応するイベントハ ンドラである。
イベント exitは、 例えば、 ユーザ操作などにより UMDビデオプレ —ャの動作の終了が指示された際に、 ネィティブ実装プラットフォー ム 30 1からスクリプトレイヤ 3 0 2に通知される。 スクリプトレイ ャ 30 2のスクリプトは、 通知されたイベント exitを受けて、 ィベン トハンドラ onExi tO内で終了処理を行うことができる。 イベント auto Playおよびイベントハンドラ onAutoPlay()、 ならびに、 イベント cont inuePlayおよびイベントハンドラ onCont inuePlay 0は、 それぞれスク リブトの実行を開始する。
なお、 システムオブジェクトのイベントハンドラ以外に、 ポタンに 関するイベントハンドラがある。 このポタンに関するイベントハンド ラは、 この発明と関連性が低いので、 説明を省略する。
第 1.6図のフローチヤ一卜を用いて、 ユーザ入カイベントをきっか けとして、 用意されたプログラムが実行される一例の処理について、 概略的に説明する。 第 1 6図は、 UMDビデオプレーヤにおいてディ スクを通常再生中に、 ユーザにより、 次のチヤプ夕を再生することを 指示するための" next"キ一が押されたときに、 このキー入力に対応し て、 次のチヤプ夕にジャンプして再生を開始すると共に、 用意された メッセ一ジを画面上に表示する例である。
例えば、 UMDビデオプレーヤによりディスクを通常再生中に、 ュ 一ザが UMDビデオプレーヤのリモ一トコントロールコマンダを用い てキー" next"を押下すると （ステップ S 1 0) 、 ネイティブ実装ブラ ットフオーム 3 0 1に対するユーザ入力 3 1 0として、 キー VK_NEXT が渡される。 ネイティブ実装プラットフォーム 30 1では、 このュ一 ザ入力 3 1 0に対応してユーザコマンド uo_playNextChapter()が発生 する （ステップ S 1 1) 。 このュ一ザコマンド uo— playNextChapterO は、 ム一ピ一プレーヤ 3 00に通知される。
このコマンド uo— playNextChapterOを受け取ったムービープレーヤ 300は、 データべ一ス 320を検索し、 プレイリスト情報から現在 再生している位置を基準として、 次のチヤプタマークの位置を取得す る (ステップ S 1 2) 。 ステップ S 1 3で、 次のチヤプ夕マークが存 在するか否かが判断され、 若し、 存在しないと判断された場合、 チヤ プタジャンプを行わず、 現在の再生が継続される。
一方、 ステップ S 1 3で、 次のチヤプ夕マークが存在すると判断さ れれば、 処理はステップ S 14に移行する。 ステップ S 14では、 ム 一ビープレーヤ 300は、 現在の再生を中止し、 次のチヤプ夕マーク が指し示す、 クリップ AVストリームファイル内でのバイト位置を、 データベース 3 2 0のクリップインフォメーションファイルの特徴点 情報から取得する。 そして、 ステップ S 1 5で、 取得されたファイル 内バイト位置にアクセスし、 その位置からストリームの読み込みを開 始して再生を開始する。
ステップ S 1 6以下は、 チヤプ夕が切り替わつたことを知らせるメ ッセージを画面上に表示するための一連の手順である。 チヤプタが切 り替わりチヤプ夕の先頭からの再生が開始されると、 チヤプ夕ィベン 卜が発生する （ステップ S 1 6 ) 。 例えば、 チヤプ夕の先頭に設けら れたチヤプ夕マークがム一ビープレーヤ 3 0 0に検出され、 イベント chapt erが発生される。 このチヤプ夕イベントは、 ムービープレーヤ 3 0 0からスクリプトレイヤ 3 0 2に通知される。 ムービープレーヤ 3 0 0は、 このイベントの通知時に、 ジャンプするチヤプ夕のチヤプ 夕番号も共に、 スクリプトレイヤ 3 0 2に対して通知する。 スクリブ トレイヤ 3 0 2は、 通知されたイベントに対応するイベントハンドラ 、 例えばイベントハンドラ onChapter 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 ) 。 上述のような処理により、 ユーザが次のチヤプ夕の再生開始を指示 するキー" nex t"を操作することによりチヤプ夕ジャンプが行われ、 ジ ヤンプ先である次のチヤプ夕の再生開始時にチヤプ夕の先頭であるこ とを示すメッセージが画面上に表示されることになる。
このように、 ユーザ入力イベントは、 ムービープレーヤ 3 00の状 態を変化させ、 また、 新たなイベントを発生させる契機ともなり、 新 たに発生したイベントを利用して様々な処理を行わせることができる 第 1 7図は、 UMDビデオプレーヤにディスクがロードされてから イジェクトされるまでの処理を概略的に示す。 なお、 第 1 7図中、 斜 線を付したブロックで記述された処理は、 スクリブトが実行されてい る状態を示す。
先ず、 ユーザにより UMDビデオプレーヤにディスクが装填される と、 UMDビデオプレーヤは、 所定の動作によりディスクをロードし 、 再生可能な状態にする （ステップ S 30.) 。 ディスクがロードされ ると、 ネィティブ実装プラッ卜フォーム 30 1によりリジュームイン フオメ一シヨン 324が参照され、 当該ディスクに対応する続き再生 情報がロードされる （ステップ S 3 1) 。
次に、 当該ディスクに対応するリジユームィンフオメーシヨン 3 2 4内が参照され、 続き再生情報が存在するか否かが判断され （ステツ プ S 3 2) 、 存在すれば、 ネイティブ実装プラットフォーム 30 1か らスクリプトレイヤに対してイベント continuePlayが通知される。 ス クリブトレイヤ 3 02は、 通知されたイベント continuePlayに対応す るイベントハンドラ onContinuePlayを実行する （ステップ S 3 3) 。 ステップ S 32で、 当該ディスクに対応する続き再生情報が存在しな いと判断されれば、 処理はステップ S 34に移行し、 ネイティブ実装 プラットフォーム 30 1からスクリプトレイヤ 3 02に対してィベン ト autoPlayが通知され、 スクリプトレイヤ 3 02は、 対応するィベン トハンドラ onAutoPlayを実行させる。
ステップ S 3 5では、 イベントハンドラ onAutoPlayやイベントハン ドラ onContinuePlayの記述内容に基づきディスクの再生動作などが行 われ、 ディスクの再生動作に伴い発生されたイベントや、 当該ィベン トに対応するイベントハンドラが実行される。
ここで、 ネイティブ実装プラットフオーム 30 1からイベント exit が発生されると、 ステップ S 36で、 スクリプトレイヤ 302におい て対応するイベントハンドラ onExitが実行され、 UMDビデオアプリ ケ一ションを終了させるための処理が実行される。 イベント exitは、 例えばリモートコントロールコマンダに対する所定の操作に応じたュ —ザ入力 3 1 0に基づき、 ネィティブ実装プラットフオーム 30 1で 発生される。
イベントハンドラ onExitに基づくスクリプト処理が終了すると、 ネ ィティブ実装プラットフオーム 30 1に処理が移る。 そして、 ステツ プ S 3 7で、 ムービープレーヤ 3 00において、 再生動作を停止する 処理が実行される。 このとき、 停止された直前の状態が続き再生情報 としてリジュームインフォメーション 324に記憶される。 そして、 ディスクの再生が終了され （ステップ S 38) 、 同じディスクを再び 再生しない際には （ステップ S 3 9) 、 ステップ S 40で、 ネィティ ブ実装プラットフォーム 30 1によりディスクがイジェクトされ、 一 連の処理が終了される。 また、 同じディスクを再び再生する際には、 処理はステップ S 3 1に戻される。
第 1 8図は、 スクリプトファイルの構成例を示す。 第 2図を用いて 既に説明したように、 スクリプトファイルは、 スクリプトレイヤ 30 2を構成するファイル" SCRIPT.DAT"内のファイルとして存在する。 ス クリプ.卜ファイルは、 ィベントハンドラ群とメイン処理部とからなる 。 イベントハンドラ群は、 1または複数のイベントハンドラが並べら れる。 イベントの発生がスクリプトレイヤ 3 02に通知される毎に、 通知されたイベントに対応したイベントハンドラが検索され、 実行さ れる。 メイン処理部は、 例えば各イベントハンドラに共通して用いら れるグローバル変数などの定義が記述され、 通常、 最初に 1回だけ実 行される。
第 1 9図は、 イベントハンドラ onAutoPlayOを実行する一例の手順 を示す。 UMDビデオプレーヤにディスクを装填する際に、 ユーザに より、 始めから再生を行うように、 ムービープレーヤ 30 0に対して 再生指示がなされた場合 （ステップ S 50) に、 この処理が行われる 。 ネィティブ実装プラットフオーム 30 1は、 ステップ S 5 1で、 ス クリプト中にィベントハンドラ onAutoPlayOが存在するか否かが調べ られる。 若し、 存在すれば、 ネイティブ実装プラットフォーム 3 0 1 は、 イベント autoPlayをスクリプトレイヤ 302に対して通知する （ ステップ S 5 2) 。 これを受けて、 ステップ S 54で、 スクリプトレ ィャ 3 0 2は、 イベントハンドラ onAutoPlayOを実行する。 これによ り、 装填されたディスクが自動的に再生開始される。
一方、 ステップ S 5 1で、 スクリプト中にイベントハンドラ onAuto PlayOが存在しないとされれば、 処理はステップ S 53に移行し、 ネ ィティブ実装プラットフォーム 30 1は、 イベント exitをスクリプト レイヤ 3 02に対して通知する。 この場合、 例えば、 メニューキーな どを操作して、 ネィティブ実装ブラッ卜フォーム 3 0 1に実装されて いるメニュー画面から再生指示を与えることで、 ディスクの再生を開 始することができる。 スクリプトレイヤ 30 2がィベントハンドラ on Exit 0を持っている場合、 このイベントハンドラ onExitOが実行され る。 第 20図は、 イベントハンドラ onContinuePlayOを実行する一例の 手順を示す。 UMDビデオプレーヤにディスクを装填する際に、 ユー ザにより、 続き再生を行うように、 ムービープレーヤ 30 0に対して 再生指示がなされた場合 （ステップ S 6 0) に、 この処理が行われる 。 ネィティブ実装プラットフオーム 3 0 1は、 ステップ S 6 1で、 装 填されたディスクに対応するリジユームインフォメーション 324が 存在するか否かが調べられる。 若し、 存在しなければ、 処理はステツ プ S 62に移行し、 先頭からの再生となる。
装填されたディスクに対応するリジュームインフォメーション 32 4が存在する場合には、 処理はステップ S 6 3に移行し、 スクリプト 中にイベントハンドラ onContinuePlayOが存在するか否かが調べられ る。 若し、 存在すれば、 ネイティブ実装プラットフォーム 30 1は、 ィベント continuePlayをスクリブトレイヤ.3 02に対して通知する。 これを受けて、 スクリプトレイヤ 302は、 イベントハンドラ onCont inuePlayOを実行する （ステップ S 64) 。 これにより、 装填された ディスクが、 イベントハンドラ onContinuePlayOに従い再生が再開さ れる。
一方、 ステップ S 6 3で、 スクリプト中にイベントハンドラ onCont inuePlayOが存在しないとされれば、 処理はステップ S 6 5に移行し 、 デフォルトのイベントハンドラ onContinuePlayOが実行される。 デ フォルトのイベントハンドラ onContinuePlayOは、 例えば、 リジュー ムインフォメーション 3 24の情報に基づき前回の再生終了位置から 、 単純に再生を開始する。
なお、 これらの、 イベント八ンドラ onAutoPlayおよびイベントハン ドラ onContinuePlayによるユーザインターフェイスは、 上述の例に限 られず、 様々な方法が考えられる。 例えば、 上述の第 20図において は、 ステップ S 60でユーザにより続き再生が指示されてから、 装填 されたディスクに対応するリジュームインフォメーション 324が存 在するか否かを調べているが、 これは、 順序を逆にし、 リジュームィ ンフオメ一ション 3 24が存在するか否かを先に調べ、 存在する場合 に、 続き再生を行うか否かの選択をユーザに促してもよい。
第 2 1図は、 再生終了時の一例の処理を示す。 ディスクの再生中に 、 例えばュ一ザにより、 ムービープレーヤ 3 00に対して再生を終了 する指示がなされた場合 （ステップ S 7 0) に、 この処理が行われる 。 再生終了を指示するュ一ザ入力 3 1 0がネイティブ実装プラットフ オーム 30 1に対して入力されると、 ネイティブ実装プラットフォー ム 3 0 1は、 終了処理を開始する （ステップ S 7 1) 。 終了処理は、 例えば下記の 3つの処理である。
(1) 新たなイベント発生の抑止
(2) キューに溜まったイベントハンドラの破棄
(3) ムービープレーヤ 3 00に対する制御コマンド uo— stopOの発 行
ステップ S 7 1の処理が実行され、 現在実行されているイベントハ ンドラが終了すると （ステップ S 7 2) 、 次のステップ S 7 3で、 ネ ィティブ実装プラットフオーム 3 0 1からスクリプトレイヤ 30 2に 対して、 イベント exitが通知される。 スクリプトレイヤ 3 02は、 こ れを受けて、 スクリプトレイヤ 30 2は、 イベントハンドラ onExitO を実行する （ステップ S 74) 。 イベントハンドラ onExi )により、 例えば、 再生終了時の所定の後処理や、 ユーザによる設定データを記 憶するメソッド s e t Us e rDa t aなどが実行される。
そして、 次のステップ S 7 5で、 ネイティブ実装プラットフォーム 3 0 1により、 終了処理がなされる。 この終了処理では、 例えば、 不 揮発性メモリに対する続き情報の保存 （すなわち、 再生終了直前の状 態のリジユームインフォメーション 3 2 4に対するパックアップ） や 、 システムメニューへの遷移などが行われる。
以上のようなプレーヤモデルにより、 ビデオ、 オーディオおよび字 幕の再生が可能となる。 また、 コンテンツ制作者が予め設定しておい た、 再生中のある時刻にあるイベントを発生させて、 コンテンツ制作 者が予め用意しておいたイベントハンドラを実行するようにしている ため、 コンテンツ制作者が意図する動作を実現できる。 さらに、 U M Dビデオプレーヤによるディスクの再生中にユーザ操作があった場合 は、 ネイティブ実装プラットフォーム 3 0 1からムービープレーヤ 3 0 0に対して、 ユーザ操作に応じたコマンドが通知され、 ユーザの意 図する通りにプレーヤの状態を変化させることができる。 さらにまた 、 ユーザ操作によるユーザ入力を受けたネィティブ実装プラットフォ —ムが、 スクリプトレイヤ 3 0 2に対してユーザ入力に対応するィべ ントを通知することにより、 ユーザ操作に応じてコンテンツ制作者が 用意した動作を実現することが可能となる。 このようにプレーヤモデ ルを構築することで、 ビデオ、 オーディオおよび字幕の再生と、 イン 夕ラクティブな操作とをユーザに提供することが可能となる。
5 . スクリプトプログラムの例
次に、 スクリプトレイヤ 3 0 2のスクリプトプログラムの例につい て説明する。 先ず、 第 2 2図に示されるようなコンテンツ再生の流れ が、 コンテンツ制作者により作られているものとする。 第 2 2図に示 されるコンテンツは、 表示される要素としては、 プレイリスト 4 0 0 および 4 0 1、 トップメニュー 4 0 2、 ならびに、 メッセージ 4 0 3 から構成される。 プレイリスト 4 0 0は、 ディスクが装填されると自 動的に表示される警告文画面を表示するためのものである。 プレイリ スト 40 1は、 例えばこのコンテンツの主眼である映画の本編である 。 トップメニュ一画面 40 2は、 プレイリスト 40 1の再生を指示で きるように、 ポタンなどの GU I部品が配置される。 また、 メッセ一 ジ 40 3は、 プレイリスト 40 1の再生中の任意の時刻に表示される さらに、 この第 22図の構成では、 幾つかのイベントハンドラが用 意されている。 イベントハンドラ onAutoPlayOは、 ディスクが UMD プレーヤに装填されると、 プレイリスト 400を自動的に再生し、 警 告文を表示させる。 イベントハンドラ onPlayListEndOは、 プレイリ ストの再生が終了すると呼び出されるイベントハンドラで、 この第 2 2図の例では、 プレイリスト 40 0やプレイリスト 40 1の終了で呼 び出される。 すなわち、 イベントハンドラ onPlayListEndOは、 どの プレイリストが終了したかを判定し、 プレイリスト 40 0の再生が終 了した場合には、 プレイリスト 40 1の再生開始を指示する。 また、 プレイリスト 40 1の再生が終了した場合には、 トップメニュー画面 402を呼び出す。
ィベントハンドラ onMenuOは、 ユーザがメニューキーを操作したと きに呼び出され、 トップメニュー 402を呼び出して画面に表示する 。 イベントハンドラ onMarkOは、 再生中にマーク Markが指し示す時刻 に到達したときに実行される。 この第 22図の例では、 プレイリスト 40 1に対してマーク Markが設定されており、 プレイリスト 40 1の 再生がマーク Markの指し示す時刻に到達すると、 画面上にメッセ一ジ 403が表示されるようになっている。
すなわち、 第 2 2図の例では、 UMDビデオプレーヤにディスクが スト 40 0が再生され、 警告画面が表示される。 プレイリスト 40 0 の再生時間が経過し、 プレイリスト 400の最後に到達すると、 ィべ ントハンドラ onPlayLis ndが呼び出され、 プレイリスト 400が最 後まで再生されたことが判定され、 次のプレイリスト 40 1が再生さ れる。 ここで、 プレイリスト 40 1の再生中に、 ユーザによりメニュ 一キーが操作されると、 イベントハンドラ onMenuが呼び出され、 トツ プメニュー画面 402が表示される。 また、 イベントハンドラ onMenu により、 トップメニュー画面 40 2に対する所定の操作に応じて、 プ レイリスト 40 1の先頭から再生が開始される。 さらに、 プレイリス ト 40 1の再生時刻がマーク Markが指し示す時刻に到達したら、 ィべ ントハンドラ onMarkが呼び出され、 メッセージ 40 3が画面上に表示 される。 プレイリスト 40 1が最後まで再生されると、 イベントハン ドラ onPlayListEndが呼び出され、 プレイリスト 40 1が最後まで再 生されたことが判定され、 トップメニュ 画面 402が表示される。 第 23図は、 この第 2 2図に示すような動作を実現するための一例 のスクリプトプログラムを示す。 上述したように、 スクリプトプログ ラムは、 イベントハンドラが並べられ、 イベントの発生に応じて対応 するイベントハンドラが実行されるようになっている。 スクリプトプ ログラムは、 後述するファイル" SCRIPT.DAT"に格納される。
ム一ビ一プレーヤ 30 0に対してプレイリストの再生を指示するメ ソッドは、 「movieplayer.play()」 である。 括弧内には、 引数として 、 再生するプレイリストの番号を記述する。 プレイリストの再生が終 了すると、 イベント playListEndが発生する。 このイベント playListE ndが発生すると、 スクリプトからイベントハンドラ movieplayer.onPl ayListEndOが呼び出される。 このとき、 スクリプトには、 イベント p layListEndと共に、 オブジェクト evenし infoが渡される。 オブジェク ト evenし infoには、 どのプレイリストが終了したかを表すプレイリス ト番号などが格納される。 スクリプトでは、 このオブジェクト event一 inioの内容により、 次の動作を変えることができる。
6. ファイルの管理構造について
次に、 UMDビデオ規格に適用されるファイルの管理構造について 、 第 24図を用いて説明する。 ファイルは、 ディレクトリ構造により 階層的に管理されて、 ディスク上に記録される。 ディスクのファイル システムは、 I S O (Internat ional Organization for Standarizat i on) - 9 660あるいは UD F (Universal Disk Format)などで規定さ れたファイルシステムを適用することができる。
ルートディレクトリの下に、 ファイル" TITLEID.DAT"およびディレ クトリ" VIDEO"が置かれる。 ディレクトリ" VIDEO"の下には、 さらに、 ディレクトリ" RESOURCE"、 ディレクトリ" CLIP"およびディレクトリ" S TREAM"、 ならびに、 ファイル" PLAYLIST.DAT"が置かれる。
ファイル" TITLEID.DAT"は、 タイトル （コンテンツの種類） 毎に異 なるタイトル識別子が格納されるファイルである。 1つのディスクに 対し、 1つのファイル" TITLEID.DAT"を有する。
ディレクトリ" RESOURCE"の下には、 ファイル" SCRIPT. DAT"が置かれ る。 このファイル" SCRIPT. DAT"は、 上述したように、 スクリプトレイ ャ 30 2を構成するスクリブトプログラムが格納される。 ディレクト リ" RESOURCE"の下には、 通常、 1個のファイル" SCRIPT. DAT"が置かれ る。 これに限らず、 ディレクトリ" RESOURCE"の下に、 複数のファイル "SCRIPT. DAT"を置くこともできる。 このときは、 例えばファイル名の 一部をそれぞれ変更し、 互いに重複しないようにする。 複数のフアイ ル" SCRIPT. DAT"は、 例えば、 表示言語の異なる複数のメニューなどを 用意する際に、 言語毎に 1つファイル" SCRIPT. DAT"が用いられる。 こ の場合でも、 実際に使用されるファイル" SCRIPT.DAT"は、 1つとされ る。
ディレクトリ" CL IP"の下には、 1以上のクリップインフォメーショ ンファイルが置かれる。 クリップインフォメーションファイルは、 フ アイル名を、 デリミタであるピリオドの前が 「00001」 などの 5文字 乃至数文字からなる文字列 （この例では数字） 、 ピリオドの後ろの拡 張子が 「CLP」 とされる。 拡張子 「CLP」 により、 当該ファイルがクリ ップインフォメーションファイルであることを識別できる。
ディレクトリ" STREAM"の下には、 1以上のクリップ A Vストリ一ム ファイルが置かれる。 クリップ A Vストリームファイルは、 ファイル 名を、 デリミタであるピリオドの前が 「00001」 などの 5文字乃至数 文字からなる文字列 （この例では数字） 、 ピリオドの後ろの拡張子が rPSj とされる。 拡張子 rpsj により、 当該ファイルがクリップ A V ス卜リームファイルであることを識別できる。 この実施の一形態では 、 クリップ A Vストリームファイルは、 ビデオストリーム、 オーディ ォストリームおよびサブタイトル （字幕） ストリームが多重化され、 M P E G 2 (Movi ng P i c tures Exper t s Group 2)のプログラムストリ —ムとして、 上述の拡張子 「PS」 で識別されるファイルに格納される 上述したように、 クリップ A Vストリームファイルは、 ビデオデ一 夕およびオーディォデータを圧縮符号化および時分割多重して得られ るファイルであって、 このファイルを読み込み、 デコード処理を行う ことで、 ビデオデータおよびオーディオデータが得られる。 また、 ク リップインフォメーションファイルは、 このクリップ A Vストリーム ファイルの性質などが記述されるファイルであって、 クリップ A Vス トリ一ムファイルと対応する。 この実施の一形態では、 クリップイン フオメーションファイルと対応するクリップ A Vストリームファイル とで、 ファイル名における、 拡張子の前の、 5文字乃至数文字からな る文字列を一致させておくことで、 両者の対応関係を容易に把握でき る。
ファイル" SCRIPT. DAT"は、 上述したように、 スクリプトプログラム が記述されたスクリプトファイルであり、 この実施の一形態が適用さ れるディスクの再生形態をィン夕ラクティブなものとするために用い るプログラムが格納されている。 ファイル" SCRIPT. DAT"は、 ディスク に格納される他のファイルに先立って読み出される。
ファイル" PLAYLIST.DAT"は、 クリップ AVストリームの再生順を指 定するプレイリストが記述されたプレイリストファイルである。 第 2 5図〜第 27図を用いて、 ファイル" PLAYLIST.DAT"の内部構造につい て説明する。 第 2 5図は、 ファイル" PLAYLIST.DAT"の全体構造を表す 一例のシンタクスを示す。 ここでは、 シンタクスをコンピュータ装置 などのプログラムの記述言語として用いられる C言語の記述法に基づ き示す。 これは、 他のシンタクスを表す図において、 同様である。 フィールド name_lengtliは、 8ビットのデ一夕長を有し、 このプレ ィリストファイルに付された名称の長さを示す。 フィールド name_str ingは、 2 5 5バイトのデータ長を有し、 このプレイリストファイル に付された名称を示す。 フィールド name_stringは、 その先頭から、 フィールド name_lengthが表すバイト長までが、 有効な名称として使 用される。 例えば、 フィールド name_lengthが値" 1 0"を持つ場合に は、 フィールド name_stringの先頭から 1 0バイト分が有効な名称と して解釈される。
フィールド number_oし PlayListsは、 1 6ビットのデータ長を有し 、 続けて記述されるブロック PlayList 0の個数を示す。 次行の forル ープによりフィールド number— of_PlayListsに示される回数分だけ、 当該個数のブロック Π ayL i s t 0が記述される。 ブロック P 1 ayL i s t 0は 、 プレイリストそのものである。
プロック PlayListOの一例の内部構造について説明する。 ブロック PlayListOの先頭には、 フィールド ayLisし data—lengthが配される 。 フィールド PlayLisし data_lengthは、 32ビットのデ一夕長を有し 、 当該フィールド PlayList—dataJengthを含むブロック PlayLis )の データ長を示す。 続いて、 15ビットのデータ長を有するフィールド reserved— for— word— al ignmentと、 1ヒッ卜のテ一夕： s ¾するフラ グ capture一 enable一 flagJPlayListと力配される。 フィーゾレド reserved —for— word— alignmentは、 テ一タ長が 1ビッ卜のフラク capture_enabl e_flag一 PlayLis tと組み合わせて、 プロック PlayLis t 0内での配置を 16ビットの位置に揃えるために用いられる。
フラグ capture一 enable一 flag— PlayLis " 、 当該 capture一 enable一 f la g— PlayListを含むブロック PlayList 0に属する動画像の二次利用を許 可するか否かを示すフラグである。 例えば、 このフラグ capture_enab le_ilag— MayListの値が" 1"であれば、 当該 PlayLis )に属する動画 像の、 再生機内での 2次利用を許可することを示す。
なお、 上述では、 フラグ capture—enableJlagJ ayUstを 1ピット のフラグとしたが、 これはこの例に限定されない。 例えば、 フラグ ca pture一 enable— flag_PlayListを複数ビット構成として、 2次利用の段 階的な許可を記述するようにしてもよい。 一例として、 フラグ captur e一 enable jlagJ>layListを 2ビット構成とし、 値が" 0"の場合には 2 次利用を完全禁止とし、 値が" 1 "の場合には例えば 64画素 X 64ラ ィンなど、 所定の解像度以下に圧縮符号化した場合のみ 2次利用を可 能とする。 また、 値が" 2"であれば、 制限無く 2次利用を許可すると いった利用が考えられる。 これに限らず、 2ビット構成のうちビット 0が値" 1"の場合にはコンテンッ再生アプリケ一ションでの 2次使用 を許可し、 ビット 1が値" 1"の場合には同一筐体内の他のアプリケ一 シヨン （例えば壁紙画像やスクリーンセーパ） での 2次使用を許可す る。 この場合には、 ビット 0およびビット 1の値を組み合わせて用い ることができる。
フィールド PlayLisし name—lengthは、 8ビットのデ一タ長を有し、 このブロック PlayLis t0に付された名称の長さを示す。 フィールド P1 ayLisし name_stringは、 255ビットのデータ長を有し、 このブロッ ク PlayList ()に付された名称を示す。 フィールド PlayLisし name— stri ngは、 その先頭から、 フィールド PlayLisし name_s ingが表すバイト 長までが、 有効な名称として使用される。
フィールド number_oし Playltemsは、 16ビットのデータ長を有し 、 続けて記述されるブロック PlayltemOの個数を示す。 次行の forル ープによりフィールド number— 0し Playltem2に示される回数分だけ、 当該個数のブロック PlayltemOが記述される。 ブロック PlayltemOは 、 プレイアイテムそのものである。
ブロック PlayList ()内の各ブロック PlayltemOには、 識別情報 （I D) が付与される。 例えば、 ブロック PlayListO内の最初に記述され るブロック PlayltemOは、 0番とされ、 以降、 ブロック Playl tem()の 出現順に、 1番、 2番、 · · · と通し番号が付される。 この通し番号 が各プロック Playl temOの識別情報として用いられる。 ブロック Plau IiemOの個数だけ繰り返される forループの引数 iを、 対応するブロッ ク PlayltemOの識別情報として用いることができる。 ブロック Playlt ' em()の次に、 ブロック PlayListMarkOが配置される。
第 26図を用いて、 ブロック PlayltemOの一例の内部構造について 説明する。 ブロック PlayltemOの先頭には、 フィ一ルド lengthが配さ れる。 フィールド lengthは、 1 6ビットのデータ長を有し、 当該プロ ック PlayltemOの長さを示す。 続いて、 フィールド CI ip一 Information —file— name— lengthが配される。 フィールド CI ip— Information— fi le—n ame_lengthは、 1 6ビットのデータ長を有し、 このブロック Playl tem 0に対応するクリップインフォメーションファイルの名称の長さを示 す。 フィールド Clip_Iniorfflation_iile_nameは、 バイト単位で可変長 のデータ長を有し、 このブロック PlayltemOに対応するクリップィン フオメ一ションファイルの名称を示す。 フィールド Clip—Information —file— nameは、 その先頭力 ら、 フィ一 レド Clip— Information— file— na me_lengthが表すバイト長までが、 有効な名称として使用される。 フ ィー レド CI ip— Information— fi le— nameでクリップィンフオメーション ファイルが指定されると、 上述したファイル名の対応関係により、 当 該クリップインフォメ一ションファイルに対応するクリップ AVスト リームフアイルが特定できる。
フィールド IN— timeおよびフィ一ルド OUT— timeは、 それぞれ 3 2ビ ッ卜のデータ長を有し、 ブロック PlayltemO内においてフィ一ルド C1 ip— Information— file— nameで ί旨定したクリップィンフオメ一ションフ アイルに対応するクリップ AVストリームファイルの再生開始位置お よび再生終了位置を指定する時刻情報である。 これらフィールド IN— t imeおよびフィールド OUT— timeの情報を用いることで、 クリップ AV ストリームファイルの先頭以外の部分からの再生開始を指定すること ができる。 同様に、 クリップ AVストリームファイルの後端以外の再 生終了を指定することができる。
第 2 7図を用いて、 ブロック PlayListMarkOの一例の内部構造につ いて説明する。 ブロック PlayListMarkOの先頭には、 フィールド leng thが配される。 フィールド lengthは、 32ビットのデータ長を有し、 当該ブロック PlayListMarkOの長さを示す。 続いて、 フィールド numb er一 of_P yList— marksが配される。 フィ—ルドフィールド number— of— PlayListjnarksは、 1 6ビットのデ一夕長を有し、 続くブロヅク Mark 0の個数を示す。 次行の forループによりフィールド number— 0し PlayL istjnarksに示される回数分だけ、 当該個数のブロック MarkOが記述 される。
ブロック Mark 0の一例の内部構造について説明する。 ブロック Mark 0は、 先頭にフィールド mark_typeが配される。 フィールド mark一 type は、 8ビットのデータ長を有し、 当該フィールド mark—typeを含むブ ロック MarkOの種類を示す。 この実施の一形態では、 第 28図に一例 が示されるように、 チヤプ夕マーク、 インデックスマークおよびィべ ントマークの 3種類のマークが規定されている。 チヤプタは、 プレイ リスト （ブロック PlayListO) を分割する頭出し単位であり、 インデ ックスは、 チヤプ夕をさらに分割する頭出し単位である。 チヤプタマ —クおよびインデックスマ一クは、 それぞれ、 これらチヤプ夕位置お よびインデックス位置を時刻情報で示す。 イベントマークは、 マーク イベントを発生させるマークである。
フィールド mark一 name— lengthは、 8ビットのデータ長を有し、 この プロック MarkOに付された名称の長さを示す。 ブロック MarkOの最下 行に配されるフィールド mark_name_stringは、 このブロック MarkOに 付された名称を示す。 フィールド mark_name_st ringは、 その先頭から 、 フィールド mark一 name_lengthが表すバイト長までが、 有効な名称と して使用される。
フィー Jレド ref— to— Playl tem— id、 フィー レド mark一 time— stamp、 フ ィ一レド entry一 ES— stream一 idおよびフィ一 Jレド en try— ES— private— s tr earn idの 4要素は、 ブロック PlayList 0上で定義されるブロック Mark 0を、 クリップ AVストリームファイルと対応付ける。 すなわち、 フ ィールド ref_to_PlayItem_idは、 1 6ピットのデータ長を有し、 ブロ ック PlayltemOの識別情報を示す。 これにより、 クリップインフォメ —シヨンファイルと、 クリップ AVストリームファイルとが特定され る。
フィールド mark— time— sta即は、 3 2ビットのデータ長を有し、 ク リップ AVストリームファイル内でのマークの時刻を指定するために 用いられる。 第 2 9図を用いて、 概略的に説明する。 第 2 9図におい て、 プレイリストは、 番号 0、 1および 2がそれぞれ指定された 3つ のプレイアイテム （Playltem(#0)、 Playltem(#l)および Playltem(#2) ) からなり、 プレイリスト上の時刻 t。は、 番号 1のプレイアイテム (PlayItem(#D) に含まれるものとする。 また、 番号 0、 1および 2 の各プレイアイテムは、 それぞれ対応するクリップインフォメ一ショ ンファイルを介してクリップ A Vストリームファイルのプログラムス トリーム（Program Sream)A、 Bおよび Cにそれぞれ対応しているも のとする。
このような場合において、 プレイリスト上の時刻 t。にマークを指 定する場合、 フィールド ref— toJPlayItem_idの値を、 時刻 t。を含む プレイアイテムを示す" 1"とし、 さらに、 対応するクリップ AVスト リームファイル B上で時刻 t。に相当する時刻を、 フィールド mark_ti me— st ampに記述する。
第 2 7図の説明に戻り、 フィ一ルド mark— time一 sta即に続けてフィ ——Jレド entry— ES— stream一 idおよびフィ一ノレド entry— ES— private— strea m一 idが配される。 フィールド entry_ES_stream_idおよびフィ一ルド en try— ES_private— stream— idは、 それぞれ 8ビットのデータ長を有し、 当該ブロック MarkOが特定のエレメン夕リストリームに関連付けられ ている場合に、 そのエレメン夕リストリームを特定するために用いら れる。 フィールド entry— ES一 stream— idおよびフィ一ルド entry— ES— pr i vate— stream— idは、 それぞれ該当するエレメン夕リストリームが多重 化されているバケツト（packetO)のストリーム I D (s tream_id)と、 プライべ一卜ノヽ0ケッ卜ヘッダ (private— packet— header 0)のプライベ 一トストリ一ム I D (private— stream— id)を示す。
なお、 これらバケツト（packet 0)のストリ一ム I D (stream_id)、 プライべ一卜パケッ卜へッ夕 (private— packet— header 0)のプライベ —トストリーム I D (private_stream_id)は、 例えば MP E G 2シス テムのプログラムストリームの規定に基づく。
これらフィ一ルド entry— ES_stream— idおよびフィールド entry— ES— p rivate_stream一 idは、 例えば、 クリップ A Vストリーム # 0とクリツ プ AVストリーム # 1とで異なるチヤプ夕構成である場合などに用い られる。 該当するブロック MarkOが特定のエレメンタリストリームに 関連付けられていない場合には、 これら 2つのフィールドの値がそれ ぞれ" 0"とされる。
次に、 第 30図〜第 34図を用いて、 クリップインフォメーション ファイルの内部構造について説明する。 クリップインフォメーション ファイル" XXXXX.CLP"は、 上述したように、 ディレクトリ" STREAM"の 下に置かれた、 対応するクリップ AVストリームファイル" XXXXX.PS" の性質などを記述する。
第 3 0図は、 クリップ AVストリームファイル" XXXXX.CLP"の全体 構造を表す一例のシンタクスを示す。 クリップ AVストリームフアイ ル" XXXXX.CLP"は、 先頭に、 フィールド presentation— start— timeおよ びフィールド presentation_end— timeがそれぞれ配される。 フィ一ル ド presentation start t imeおよびフィールド presentat ion— end— t ime は、 それぞれ 32ビットのデータ長を有し、 対応するクリップ AVス トリームファイルの先頭と後端の時刻を示す。 時刻情報は、 MP EG 2システムにおける P T S (Presentation Time Stamp)を用いること ができる。 PTSは、 9 0 kH zの精度を有する。
次に、 7ビットのデ一タ長を有するフィールド reservedJor_word_ alignmentと、 1ピッ卜のテータ長を有するフラク capture一 enable— fl ag— CI ipとが配される。 フィ一ルド reserved— for_word—al ignmentは、 データ長が 1ビットのフラグ capture一 enable一 Hag_Clipと組み合わせ て、 ファイル" XXXXX.CLP"内での配置を 1 6ビットの位置に揃えるた めに用いられる。 フラグ capture_enable— ag— Clipは、 当該ファイル " XXXXX.CLP"に対応するクリップ AVストリームファイルに含まれる 動画像の 2次利用を許可するか否かを示すフラグである。 例えば、 こ のフラグ capture一 enable— flag— Clipの値が" 1 "であれば、 当該フアイ ル" XXXXX.CLP"に対応するクリップ AVストリームファイルの動画像 の、 再生機内での 2次利用を許可することを示す。
フィールド number_oし streamsは、 8ビットのデータ長を有し、 続 くブロック StreamlnfoO構造の個数を示す。 フィールド number— of— st reamsの次力 ら、 forノレープによりフィ一ノレド number_of— s treamsで示 される回数分だけ、 ブロック. StreamlnfoOが記述される。 forループ の後には、 ブロック EPjnapOが配される。
ブロック StreamlnfoOの一例の内部構造について説明する。 ブロッ ク StreamlnfoOの先頭には、 フィールド lengthが配される。 フィール ド lengthは、 1 6ビットのデ一夕長を有し、 当該ブロック Streamlnfo 0の長さを示す。 続いて、 それぞれ 8ビットのデータ長を有するフィ 一ルド stream_idおよびフィールド private— stream— idが配され、 第 3 1図に一例が示されるように、 当該ブロック StreamlnfoOをエレメン タリストリ一ムに関連付けている。 この第 3 1図の例では、 当該プロ ック StreamlnfoOは、 フィ一ルド s tream_idが値" 0 x E 0"〜値" 0 x EF"でビデオストリームに関連付けられ、 値" 0 xBD"で ATRA C (Adaptive Transform Acoustic Coding)ォーティォストリーム、 L P CM(Linear Pulse Code Modulation)オーディオストリームまたは 字幕ストリームと関連付けられる。 また、 当該ブロック StreamlnfoO は、 フィールド private— stream— idが値" 0 x 0 0"〜値" 0 x 0 F"、 値" 0 x 1 0"〜値" 0 x 1 F "および値" 0 x 8 0"〜値" 0 x 9 F"で、 ATRACオーディォストリーム、 L P CMオーディォストリームお よび字幕ストリームにそれぞれ関連付けられる。
なお、 第 3 1図での値の表記において、 「0 x」 は、 後続する数値 が 1 6進表記であることを示す。 これは、 以下の同様な表現において 、 共通である。
ここで、 ブロック StreamlnfoOは、 大別して、 ストリーム中で変化 しない情報とストリーム中で変化する情報との 2種類の情報が記述さ れている。 ストリーム中で変化しない情報は、 ブロック StaticInfoO に記述される。 一方、 ス卜リーム中で変化する情報は、 変化点を時刻 情報で指定して、 プロック DynamicInfoOに記述される。
ブロック StreamlnfoOにおいて、 ブロック Stat iclnf o 0の後ろにパ イト位置を揃えるための、 8ビットのデ一夕長を有するフィールド re served— for— word— alignment力配され、 その次に、 フィー レド number— of— Dynamiclnfoが、配される。 フィールド number— of— Dynaminlnf oは、 8ビットのデータ長を有し、 プロック StreamlnfoO内にその後に記述 されるブロック DynamicInfoOの個数が示される。 forループにより、 フィールド number_oし Dynamiclnfoで示される回数分だけ、 フィ一ル ド pts change— pointおよびブロック DynamicInfoOが記述される。 フィールド pts— change— pointは、 3 2ビットのデータ長を有し、 対 応するブロック Dynami c I η ί o 0の情報が有効になる時刻を P T Sによ り示す。 ストリーム毎に先頭となる時刻も、 フィ一ルド pts_change_p ointで示され、 これは、 ファイル" XXXXX.CLP"内で定義される、 上述 したフィー レド presentation— start— timeと等しくなる。
第 3 2図を用いて、 ブロック StaticInfoOの一例の内部構造につい て説明する。 ブロック StaticInfoOは、 対応するエレメンタリストリ ームの種類により内容が異なる。 対応するエレメンタリストリームの 種類は、 第 3 1図を用いて説明した、 フィールド stream— idおよびフ ィールド private一 stream— idの値に基づき判断できる。 第 32図では 、 ブロック StaticInfoOが対応するエレメン夕リストリームの種類が ビデオストリーム、 オーディオストリームおよびサブタイトル (字幕 ) ストリームの何れであるかを、 if構文を用いてそれぞれ記述してい る。 以下、 ブロック StaticInfoOについて、 エレメン夕リストリーム 毎に説明する。
エレメンタリストリームがビデオストリームであった場合、 ブロッ ク StaticInfoOは、 それぞれ 4ビッ卜のデータ長を有するフィールド picture— sizeおよびフィールド frame— rate、 1ヒッ卜のァ一夕長を有 するフラグ cc一 agからなる。 フィールド picture一 sizeおよびフィ一 ルド frame— rateは、 当該ビデオストリームの画像のサイズおよびフレ ーム周波数をそれぞれ示す。 フラグ cc_flagは、 当該ビデオストリー ムがクローズドキャプションを含むか否かを示す。 例えば、 フラグ — agの値が" 1 "で、 当該ビデオストリームがクローズドキヤプショ ンを含む。 フィー レド reserved— for—word—al ignmen ま、 つ "一夕配置 を 1 6ビットに揃えるために用いられる。
エレメン夕リストリームがオーディオストリームであった場合、 ブ ロック StaticInfoOは、 1 6ビットのデータ長を有するフィールド au dio— language— code、 8ヒッ卜 つ—夕： sを有" 5一るフィ—— レド channel — conf iguration、 1ビッ卜のデータ長を有するフラク 1 f e— exs is tance および 4ピットのデータ長を有するフィ一ルド sampling_frequency力、 らなる。 フィールド audio— language— codeは、 当該オーディオストリ —ムに含まれている言語を表すコードを示す。 フィールド charnieし co nfigurationは、 モノラル、 ステレオ、 マルチチャンネルなど、 ォ一 ディォデータのチャンネル属性を示す。 フィールド lfe— existanceは 、 低域強調チャンネルが含まれているか否かを示し、 例えば値が" 1" で、 含まれていることを示す。 フィールド sampling_frequencyは、 ォ 一ディォデータのサンプリング周波数を示す。 フィールド reserved_f or— word_alignmentは、 データ配置を 1 6ビットに揃えるために用い られる。
エレメン夕リストリームがサブタイトル （字幕） ストリームであつ た場合、 ブロック StaticInfoOは、 1 6ビットのデータ長を有するフ ィ一ルド subtitle— language— codeおよび 1ビットのデータ長を有する フラグ conf igur able— flagからなる。 フィールド sub t i tie一 language— c odeは、 当該字幕ストリームに含まれている言語を表すコ一ドを示す 。 フラグ configurable— flagは、 当該字幕ストリームを行事する際に 、 文字の大きさや位置の変更を許可するか否かを示し、 例えば値が" 1"で、 許可することを示す。 フィールド reserved— for一 word_al ignme ntは、 データ配置を 1 6ビッ卜に揃えるために用いられる。
第 3 3図を用いて、 ブロック DynamicInfoOの一例の内部構造につ いて説明する。 ブロック DynamicInfoOは、 先頭に、 8ビットのデー タ長を有するフィ一ルド reservedjor— word一 alignmentが配される。 続く内容は、 対応するエレメンタリストリームの種類により異なる。 対応するエレメンタリストリームの種類は、 第 3 1図を用いて説明し た、 フィールド stream一 idおよびフィ一ルド pr ivate— stream_idの値に 基づき判断できる。 第 33図では、 ブロック DynamicInfoOが対応す るエレメンタリストリームの種類がビデオストリ一ム、 オーディオス トリームおよびサブタイトル （字幕） ストリームの何れであるかを、 if構文を用いてそれぞれ記述している。 以下、 ブロック DynamicInfo( )について、 エレメンタリストリーム毎に説明する。
エレメンタリストリームがビデオストリ一ムであった場合、 ブロッ ク DynamicInfoOは、 4ビットのデ一夕長を有するフィールド display —aspect— ratio力、らなる。 フィー レド display— aspect— rat ioは、 ヒテ ォの表示出力ァスぺクト比が 1 6 ： 9か 4 ： 3かを示す。 フィールド reserved— for— word— al ignmeniは、 ァータ配置を 1 6ビッ卜に ίίえる ために用いられる。
エレメンタリストリームがオーディオストリームであった場合、 ブ ロック DynamicInfoOは、 4ビットのデ一夕長を有するフィールド cha nnel— assignment力 らなる。 フィー レド channel— assignmentは、 当該 オーディオストリームが 2チャンネルで構成されている場合に、 出力 がステレオかデュアルモノかを示す。 デュアルモノは、 例えば 2ケ国 語の音声を再生可能とする際に用いられる。 フィールド reserved_for _word— alignmentは、 デ一夕配置を 1 6ビットに揃えるために用いら れる。
エレメンタリストリ一ムが字幕ストリームであった場合、 ブロック DynamicInfoOは、 データ配置を 1 6ビットに揃えるために用いられ る、 フィールド reserved— for_word_alignmentで構成される。 すなわ ち、 字幕ストリームに関しては、 動的に変化する属性が定義されてい ない。 ' 第 3 4図を用いて、 ブロック EPjnapOの一例の内部構造について説 明する。 ブロック EP— mapOは、 エレメン夕リストリーム毎に、 ビット ストリーム内のデコード開始可能位置 （エントリポイント） を、 時刻 情報と位置情報とを用いて表したものである。 位置情報は、 例えばェ レメンタリ.ストリームが記録される記録媒体における、 アクセスの最 小単位を用いることができる。 各エレメンタリストリームは、 ブロッ ク EP_map()で示された位置からのデコード処理が可能であるものとす る。
固定レートのストリ一ムでは、 デコード開始可能位置を計算で求め ることができるので、 このブロック EPjnapOのような情報は、 不要で ある。 一方、 可変レートのストリームや、 MP EG系のビデオの圧縮 符号化方式のようにアクセスュニット毎にデータのサイズが変わるよ うなストリームの場合には、 ランダムアクセスを行うために重要な情 報となる。
ブロック EPjnapOは、 先頭に、 配置を 1 6ビットに揃えるために、 8ヒットのつ—夕 を有" 5—るフィ一 Jレド reserve_f or— word— al ignment が配される。 続いて、 フィールド number— 0し stream_id— entriesが配 される。 フィー レド number— of— stream一 id— entriesfま、 8ビッ卜のテ —夕長を有し、 このプロック EPjnapOに記述されているエレメンタリ ストリームの数を示す。 第 1の forループにより、 フィールド stream— id、 フィー レド private— stream— idおよびフィー レド number— of— EP— en triesが、 フィールド薩 ber— of— stream_id— entriesで示される回数分 だけ、 記述される。 さらに、 第 1の forループの 1回の記述毎に、 第 2の forループにより、 フィ一ルド number_oi—EP— entriesで示される 回数分だけ、 フィールド PTS—EP— startおよびフィールド RPN—EP— start が配される。 第 1の forループ内において、 最初に、 それぞれ 8ビットのデータ 長を有するフィールド stream— idおよびフィ一ルド pr ivate_stream— id が配され、 第 3 1図に一例が示されるようにして、 エレメン夕リスト リームを特定している。 次に、 配されるフィールド numb er_of_EP—ent riesは、 3 2ビットのデータ長を有し、 当該エレメン夕リストリーム に対して記述されているエントリポイントの数を示す。 その後、 第 2 の forループにて、 フィールド number— 0し EP_entriesが示す数だけ、 フィールド PTS— EP一 startおよびフィールド RPN_EP_star tがそれぞれ配 される。
フィールド PTS_EP_startおよびフィールド RPN—EP_startは、 それぞ れ 3 2ビットのデータ長を有し、 エントリポイント自体を表す。 フィ —ルド PTS一 EP_startは、 ェントリポィントのクリップ A Vストリーム ファイル内での時刻を PT Sで示す。 一方、 フィールド RPN_EP_s tart は、 エントリポイントのクリップ AVストリームファイル内での位置 を例えば 2 048バイト単位で示す。
この実施の一形態においては、 ディスク上のアクセス単位である 1 セクタが 2 048バイトとされる。 そのため、 エントリポイントのク リップ AVストリームファイル内での位置は、 フィールド R:PN_EP_sta rtにより、 セクタ単位で示されることになる。
ここで、 ビデオストリームの再生開始可能位置の直前には、 必ず、 パケット private— stream— 2が配される。 このパケット private—stream 一 2は、 ビデオストリームをデコードするために利用可能な情報が格納 されるパケットである。 そのため、 ビデオストリームのエントリボイ ントの位置は、 当該パケット private— stream— 2が格納されるパック pa ck()の位置とされる。
ブロック EP niapOは、 上述のようにして、 クリップ AVストリーム 上の時刻と、 クリップ AVストリームファイル内での位置とを対応付 けている。 これにより、 クリップ AVストリームへのアクセスポイン トの時刻情報 （タイムスタンプ） が与えられたときに、 クリップ AV ストリームファイルの中でデータの読み出しを開始すべきデータアド レスを検索することが容易となり、 ディスクのランダムアクセスをス ムースに行うことができる。
なお、 この実施の一形態では、 ブロック EPjnapOにおいて、 エレメ ンタリストリーム毎の時刻情報と位置情報との組 （第 2の forループ 内のフィールド PTS_EP_startとフィールド RPN_EP— startとの組） は、 フィールド PTS_EP— startおよび RPlEI^startの両方に対して昇順 （ま たは降順） に予め並べて登録するようにしている。 換言すれば、 時刻 情報と位置情報とは、 予め所定の方向に並べ替えられている。 このた め、 このままのデ一夕に対して二分検索を実行することが可能である なお、 この発明の実施の一形態では、 ビデオのエレメン夕リストリ ームは、 MP E G 2— V i d e oの規格に基づくエレメンタリストリ —ムであるとして説明したが、 これはこの例に限定されない。 例えば 、 ビデオのエレメンタリストリームは、 MP E G 4— V i s u a 1や 、 MPEG4— AVCによるものでもよい。 また、 オーディオのエレ メン夕リストリームは、 ATRACオーディオのエレメンタリストリ ームであるとして説明したが、 これもこの例に限らず、 例えば MP E G 1 2 4オーディオにも適用可能である。
7. ディスク再生装置について
次に、 この発明の実施の一形態を適用可能なディスク再生装置につ いて説明する。 第 3 5図は、 この発明を適用可能なディスク再生装置 1 00の一例の構成を概略的に示す。 バス 1 1 1に対して、 C PU(C entral Processing Unit) 1 1 2, メモリ 1 1 3、 ドライブインター フェイス 1 14、 入力インタ一フェイス 1 1 5、 ビデオデコーダ 1 1 6、 オーディオデコーダ 1 1 7、 ビデオ入出力インターフェイス 1 1 8およびオーディオ入出力インターフェイス 1 1 9がそれぞれ接続さ れる。 このディスク再生装置 1 0 0の各部は、 バス 1 1 1を介してビ デォストリーム、 オーディオストリーム、 各種コマンドやデータなど を互いにやりとりできるようになっている。
ドライブイン夕一フェイス 1 14には、 さらに、 ディスクドライブ 1 02が接続される。 ディスクドライブ 1 0 2は、 ドライブインター フェイス 1 14を介してバス 1 1 1とデータゃコマンドのやりとりを 行う。
C P U 1 1 2は、 ROM (Read Only Memory)および R AM (Random Access Memory)を有し （図示しない） 、 ROMに予め記憶されたプロ グラムゃデ一夕に従い、 バス 1 1 1を介してこのディスク再生装置 1 00の各部とデータやコマンドのやりとりを行い、 このディスク装置 1 0 0の全体を制御する。 RAMは、 C PU 1 1 2のワークメモリと して用いられる。
入力インターフェイス 1 1 5は、 ユーザにより実際に入力操作が行 われる入力装置からの入力信号が供給される。 入力装置は、 例えば、 赤外線信号などで遠隔的にディスク再生装置 1 00を操作するリモー トコントロールコマンダや、 このディスク再生装置 1 0 0に直接的に 設けられたキーなどである。 入力インタ一フェイス 1 1 5は、 これら の入力装置から供給された入力信号を、 CPU 1 1 2に対する制御信 号に変換して出力する。
ディスク 1 0 1は、 第 24図以降で説明したようなフォ一マツトで 以て、 プレイリスト、 スクリプトプログラム、 クリップインフォメー ションファイル、 クリップ AVストリームファイルなどが記録されて いる。 ディスク 1 0 1がディスクドライブ 1 0 2に装填されると、 自 動再生またはユーザの入力操作に従いディスク 1 0 1が再生される。 ディスク 1 0 1から読み出されたスクリプトファイルやプレイリスト ファイル、 クリップインフォメーションファイルは、 C PU 1 1 2に 供給され、 例えば C PU 1 1 2が有する RAMに記憶される。 C PU 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に格納されたクリップ AVス トリームファイルのビデオストリームや字幕ストリームをデコードす る。 デコードされたビデオデータや字幕データは、 例えば C PU 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 PU 1 1 2の命令に基づ き、 メモリ 1 1 3に格納されたクリップ AVストリームファイルのォ 一ディォストリームをデコードする。 デコードされたオーディオデ一 夕は、 メモリ 1 1 3にバッファリングされ、 オーディオ出力インター フェイス 1 1 9に供給される。 オーディォ出力インターフェイス 1 1 9は、 供給されたオーディオデータを、 例えばアナログオーディオ信 号に変換してオーディオ出力端子 1 2 1に導出する。
なお、 ここでは、 第 3 5図に示される各部がそれぞれ独立したハー ドウエアで構成されているように説明したが、 これはこの例に限定さ れない。 例えば、 ビデオデコーダ 1 1 6および/またはオーディオデ コーダ 1 1 7は、 C P U 1 1 2上で動作するソフトウエアにより構成 することができる。
第 3 6図 Aおよび第 3 6図 Bは、 第 3 5図に示したディスク再生装 置 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 6図 Aお よび第 3 6図 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 6図 Aおよび 第 3 6図 Bに一例が示される、 ビデオコンテンツ再生部 2 1 0を構成 する各モジュールは、 オペレーションシステム 2 0 1のマルチタスク 処理機能により、 全て、 並列的な動作が可能である。
以下、 ビデオコンテンツ再生部 2 1 0の動作について、 より具体的 に説明する。 ビデオコンテンツ再生部 2 1 0は、 内部にさらに幾つか のモジュールを有しており、 下記の機能を実現する。
( 1 ) 装填されたディスク 1 0 1が UM Dビデオの規格に準じたディ スク (以下、 U M Dビデオディスクと呼ぶ) であるか否かを判断する
( 2 ) 装填されたディスク 1 0 1が UM Dビデオディスクであると判 断した場合、 ディスク 1 0 1からスクリプトファイルを読み出して、 スクリプト制御モジュール 2 1 1に渡す。
( 3 ) 装填されたディスク 1 0 1が U M Dビデオディスクであると判 断した場合、 さらに、 データベースを構成するファイル （プレイリス トファイル、 クリップインフォメーションファイルなど） を読み出し て、 プレーヤ制御モジュール 2 1 2に渡す。
以下、 ビデオコンテンツ再生部 2 1 0の各モジュールの動作につい て説明する。 スクリブト制御モジュール 2 1 1は、 スクリプトファイル" SCRIPT.
DAT"に記述されているスクリブトプログラムを解釈して実行する。 プ レ―ャモデルの説明で既に述べたように、 メニュー画面などの画像の 作成および出力や、 ユーザ入力に応じたカーソル移動、 メニュー画面 の変更といった G U Iは、 スクリプトプログラムによりグラフィクス 処理モジュール 2 1 9を制御することで実現する。 また、 スクリプト 制御モジュール 2 1 1は、 スクリプトプログラムの実行により、 プレ —ャ制御モジュール 2 1 2の制御.などが可能である。
プレーヤ制御モジュール 2 1 2は、 ディスク 1 0 1から読み出され た、 プレイリストファイル" PLAYLI 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_information()を蓄積するためのレジス 夕を備える。 オーディオ読み出し機能の内部には、 オーディオ読み出 しポインタを有する。 字幕読み出し機能の内部には、 字幕読み出しポ ィン夕と字幕読み出し機能フラグとを有する。 字幕読み出し機能フラ グは、 書き込む値に応じて字幕読み出し機能の有効 Z無効を制御する 。 例えば、 字幕読み出し機能フラグに " 1 "を書き込むと、 字幕読み出 し機能が有効とされ、 " 0"を書き込むと、 字幕読み出し機能が無効と される。
バッファ制御モジュール 2 1 5の内部モジュールであるビデオ読み 出し機能、 オーディオ読み出し機能および字幕読み出し機能は、 さら に、 ビデオストリーム、 オーディオストリームおよび字幕ストリーム が多重化されたクリップ AVストリームから、 それぞれのストリーム を分離するデマルチプレクサ機能を有する。 この発明の実施の一形態 では、 MP E G 2システムのプログラムストリームの形式で複数のェ レメン夕リストリームが時分割多重されて、 クリップ AVストリーム が形成されている。 したがって、 ビデオ読み出し機能、 オーディオ読 み出し機能および字幕読み出し機能は、 MP E G 2システムのプログ ラムストリームに対するデマルチプレクサ機能を有する。
このため、 ビデオ読み出し機能は、 ストリーム内に所定に配置され るフィールド stream_id (第 3 1図参照） の値を読み取り、 保持する 。 同様に、 オーディオ読み出し機能および字幕読み出し機能は、 フィ 一ルド stream_idおよびフィールド private— stream— id (第 3 1図参照 ) の値を読み取り、 保持する。 これらフィールド 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 O (F i rs t In F i rs t Out)のバッファとして用い、 グラフ イクス処理モジュール 2 1 9により処理されたビデオデータをこのバ ッファに一時的に溜め込み、 所定のタイミングで読み出す制御を行う 。 バッファから読み出されたビデオデーダは、 ビデオ出力インターフ ェイス 1 1 8から出力される。
オーディオ出力モジュール 2 4 2は、 メモリ 1 1 3の一部を排他的 に占有して F I F Oのバッファとして用い、 オーディオデコーダ 1 1 9から出力されたオーディォデータをこのバッファに溜め込み、 所定 の夕イミングで読み出す制御を行う。 バッファから読み出されたォー ディォデ一夕は、 オーディオ出力イン夕一フェイス 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)をキーとして、 デ一 タ 3&¥6(3ー1>1& 61"—31& 13ぉょびデー夕3& 6(1_1156し0&1&の組を複数件、 当該領域に記憶する機能を有する。 データ Saved— Player_Statusとし て、 プレーヤ制御モジュール 2 1 2の持つデータ Backup— Player— S t usが記憶される。 このデータ Backup—Playe^Statusは、 例えば上述し たプレーヤステータス 3 2 3 Bの、 プレーヤ制御モジュール 2 1 2が. 終了する直前のデータに対応し、 データ Saved— Player— Statusは、 リ ジュ一ムインフォメーション 3 24に対応する。 また、 データ Saved_ User— Dataとして、 プレーヤ制御モジュール 2 1 2が持つデータ User— Dataが記憶される。 デ一夕 User— Dataは、 ユーザによりプレーヤ制御 モジュール 2 1 2に対して設定された所定のデータである。
例えば、 ディスク再生装置 1 0 0が不揮発性のメモリであるフラッ シュメモリなどを有する場合、 不揮発性メモリ制御モジュール 2 5 0 は、 このフラッシュメモリの所定領域にこれらデ一夕 Saved— Player S tusおよびデータ S aved— Us er_Da t aの組を、 ディスク 1 0 1のタイト ル I Dと関連付けて記憶する。 不揮発性メモリ制御モジュール 2 5 0 がデータを記憶する記憶媒体は、 フラッシュメモリに限らず、 例えば ハードディスクなどでもよい。
8 . ユーザオペレーションの制御について
次に、 この発明の実施の一形態によるユーザオペレーション制限に ついて説明する。 この発明の実施の一形態では、 ユーザオペレーショ ンに対する制限の組み合わせを、 モード （ユーザオペレーションマス クモ一ド ： UOP mask modeと呼ぶ） として定義する。 すなわち、 その 操作を許可するか否かを示すフラグをユーザオペレーション毎に設け るのではなく、 頻繁に使用されると考えられるユーザオペレーション のセットを予めプレーヤ側で用意しておき、 コンテンツ制作者側では 、 用意されたモードを選択することで、 ユーザオペレーションに対す る制限を実現する。
ユーザオペレーションマスクモードの情報は、 プレイリストのシン タクスにおいてフィールド UOPjiiask— modeとして定義し、 プレイリス ト毎に持つものとする。 このユーザオペレーションマスクモード情報 は、 プレイリストの階層でのみ持ち、 複数の階層で持つことはしない これによれば、 ユーザオペレーションに対する制限の組み合わせは 、 ユーザオペレーションマスクモードとして、 プレーヤ側に実装され てコンテンツ制作者側に提供される。 そのため、 コンテンツ制作者側 による動作検証の負担が軽減される。
また、 コンテンツ制作者がユーザオペレーションの制限を行いたい 場合、 予め用意されたユーザオペレーションマスクモードを選択する だけでよいため、 ユーザオペレーションをより容易に制御することが できる。 そのため、 コンテンツ制作者側の制作および検証の負担が軽 減されると共に、 プレーヤ側の実装時の検証の負担も軽減される。 以下、 この発明の実施の一形態におけるユーザオペレーション制限 について、 より詳細に説明する。 第 3 7図は、 この発明の実施の一形 態によるファイル" PLAYLIST.DAT"の一例のシンタクスを示す。 第 3 7 図に一例が示されるように、 この実施の一形態では、 第 2 5図を用い て既に説明した U M Dビデオ規格によるフアイル" PLAYL 1ST. DAT"に対 して、 フィールド UOP— mask— modeが追加されている。 第 3 7図の例で は、 フィールド UOP— maskjnodeは、 第 2 5図のファイル" PLAYLIST. DAT "におけるフィ一ルド PlayLisし data— lengthの後のフィールド reserve —for— word— al ignmentと、 フィールド capture— enable— flag— PI ayList の間に追加されている。 したがって、 フィールド UOP— mask— modeは、 ファイル" PLAYLIST.DAT"に含まれるプレイリスト毎に記述される。 なお、 このフィールド UOP_mask_modeの位置は一例であって、 この 例に限定されるものではない。
第 4図を用いて既に説明したように、 ムービープレーヤ 3 0 0は、 ディスク 1 0 1の再生開始時にファイル" PLAYLIST. DAT"を読み込み、 このディスク 1 0 1の再生中は、 読み込んだプレイリス卜の情報を内 部のメモリに保持している。 したがって、 フィールド UOP— mas u— mode の情報も、 該当するプレイリストを再生中は、 メモリに保持されてい る。
フィールド UOPjnask— modeは、 4ビットのデータ長を有し、 このフ アイル" PLAYLIST. DAT"に含まれるプレイリスト毎に定義される、 ユー ザオペレーションマスクモードを示す。 第 3 8図は、 フィールド U0P一 maskjnodeが表す値の意味を例示する。 値 「0 x 0」 は、 当該プレイ リストのユーザオペレーションマスクモードが、 全てのユーザォペレ ーションが可能であるモードであることを示す。
フィールド UOPjnask— modeが値 「0 x 1」 とされているときは、 当 該プレイリストに対して、 ユーザオペレーションマスクモード 「 1」 が設定されていることを示す。 ユーザオペレーションマスクモード 「 1」 が設定されたプレイリストは、 ユーザオペレーションとしては、 再生停止（s t op)のみが有効とされる。 当該プレイリストの再生中にそ の他のユーザオペレーションが行われても、 プレーヤ側は、 無視する また、 ュ一ザオペレーションマスクモードが 「 1」 に設定されてい るプレイリストに対し、 当該プレイリスト中の任意の時刻からの再生 を開始する、 所謂 「飛び込み再生」 のユーザオペレーションがなされ たときは、 当該プレイリストの先頭から、 順方向の所定速再生 （例え ば 1倍速再生） として再生を開始しなければいけないように、 定義す る。 すなわち、 他のプレイリストを再生中に、 ユーザオペレーション マスクモードが 「 1」 に設定されているプレイリストに対する飛び込 み再生が発生した場合、 当該プレイリス卜の先頭から順方向の例えば 1倍速といつた所定速度での再生が行われる。
このユーザオペレーションマスクモ一ド 「 1」 は、 例えば映画コン テンッなどが収録されたディスク 1 0 1において、 映画コンテンツに 先立って再生される、 無断複製や無断放送などを禁止するメッセージ が表示される警告画面 （F B I WA R N I N G ) を再生するための プレイリストに対して用いられることが想定されている。
フィールド UOPjnaskjnodeが値 「0 x 2」 とされているときは、 当 該プレイリストに対して、 ユーザオペレーションマスクモード 「2」 が設定されていることを示す。 ユーザオペレーションマスクモード 「
2」 が設定されたプレイリストは、 ユーザオペレーションとしては、 当該プレイリストを再生中に、 ユーザ操作により当該プレイリストの 末尾にジャンプすることが禁止される。 ただし、 再生の停止は、 常に 許可される。 また、 順方向への高速再生や、 逆方向への高速再生は、 許可される。
このユーザオペレーションマスクモード 「2」 は、 上述のモード 「 1」 よりはユーザオペレーションの制限に対する強制力が弱い。 この ユーザオペレーションマスクモード 「2」 は、 例えば、 レンタル用の コンテンッが収録されたディスク 1 0 1の、 先頭や末尾に収録されて いる宣伝用映像 （トレーラ） を再生するプレイリストに対して用いら れることが想定されている。
なお、 フィールド UOPjnask— modeにおいて、 値 「0 x 3」 〜 「0 x F」 は、 将来のための予約値である
次に、 上述したフィールド UOP—mask— modeの値を用いて行われるュ —ザオペレーションの制御について説明する。 第 3 9図は、 ムービー プレーヤ 3 0 0内でュ一ザオペレーション制限機能を実現するための 一例の機能ブロック図を示す。 ムービープレーヤ 3 0 0は、 ディスク 1 0 1から読み込まれたプレイリストの属性情報 5 0 0、 すなわちフ ィールド UOP— maskjnodeが示す値に基づきコマンドフィルタテーブル 5 0 1を生成する。
一方、 ユーザオペレーションは、 ネイティブ実装プラットフォーム 3 0 1に対するユーザ入力 3 1 0として入力される。 ネィティブ実装 プラットフォーム 3 0 1は、 入力されたュ一ザ入力 3 1 0を制御コマ ンド 3 1 1に変換し、 ムービープレーヤ 3 0 0に供給する。 この制御 コマンド 3 1 1は、 ムービ一プレーヤ 3 0 0内のコマンドフィルタ 5 0 2に渡される。 コマンドフィルタ 5 0 2は、 コマンドフィルタテー ブル 5 0 1を参照し、 渡された制御コマンド 3 1 1をプレイバックモ ジュール 3 2 1に渡すか否かを判断する。 フィールド UOP_jnask_mode により制限されるユーザオペレーションは、 コマンドフィルタテープ ル 5 0 1でフィルタリングされ、 プレイバックモジュール 3 2 1に渡 されない制御コマンド 3 1 1に対応するユーザオペレーションである 第 4 0図は、 コマンドフィルタテーブル 5 0 1の一例の作成手順を 示すフローチャートである。 例えばディスク再生装置 1 0 0において ディスク 1 0 1がロードされると （ステップ S 8 0 ) 、 ムービープレ ーャ 3 0 0は、 ディスク 1 0 1からプレイリス卜やクリップインフォ メ一ションファイルを読み込む。 そして、 読み込んだプレイリス卜の 属性情報から、 フィールド UOP— mask— modeを読み込む （ステップ S 8 1 ) 。 そして、 読み込んだフィールド UOPjnask— modeに示されるュ一 ザオペレーションマスクモードに対応したコマンドフィルタテーブル 5 0 1を作成する (ステップ S 8 2 ) 。 コマンドフィル夕テーブル 5 0 1は、 プレイリスト毎に作成される。
第 4 1図は、 ユーザオペレーションマスクモード 「1」 に対応する 一例のコマンドフィル夕テーブル 5 0 1を示す。 このコマンドフィル タテーブル 5 0 1では、 当該プレイリストの先頭以外からの再生開始 が 「禁止」 とされると共に、 許可される制御コマンド 3 1 1は、 コマ ンド uo— s t op O (第 1 2図 A、 第 1 2図 Bおよび第 1 2図 C参照） の みとされる。
第 4 2図は、 ユーザオペレーションマスクモード 「2」 に対応する 一例のコマンドフィルタテーブル 5 0 1を示す。 当該プレイリストの 先頭以外からの再生開始が 「許可」 されると共に、 第 1 2図 A、 第 1 2図 Bおよび第 1 2図 Cを用いて説明した各制御コマンド 3 1 1中、 コマンド uo— j umpToEnd Oだけが禁止される。 換言すれば、 ユーザオペ レーシヨンマスクモード 「2」 では、 コマンド uoJ umpToEnd O以外の 制御コマンド 3 1 1が全て許可される。
第 4 1図および第 4 2図で説明したようなコマンドフィルタテープ ル 5 0 1は、 コンテンツ制作者側で用意するものではなく、 ムービー プレーヤ 3 0 0の内部で生成されるものである。 コマンドフィルタテ 一ブル 5 0 1をどのような形式でプレーヤ内部に持つかは、 任意であ つて、 プレーヤの実装に依存する。
なお、 第 4 1図および第 4 2図では、 コマンドフィル夕テーブル 5 0 1をユーザオペレーションマスクモード 「 1」 および 「2」 につい てそれぞれ示したが、 これはこの例に限定されない。 例えば、 コマン ドフィルタテーブル 5 0 1は、 ュ一ザオペレーションマスクモードを 一覧してまとめて生成してもよい。 また、 i f構文を用いて記述するこ ともできる。 i f構文を用いる場合は、 コマンドフィルタテーブル 5 0 1の機能をスクリブト自体によって実現することが可能である。
第 4 3図は、 コマンドフィルタテーブル 5 0 1を用いてユーザオペ レ一シヨンを制限する一例の処理を示すフローチャートである。 なお 、 このフローによる処理が開始されるのに先立って、 ディスク 1 0 1 がプレーヤにロードされ、 ロード時に読み込まれたファイル" PLAYLIS T. DAT"に基づき、 コマンドフィルタテーブル 5 0 1が生成されている ものとする。
ステップ S 1 0 0で、 プレーヤに対するユーザ操作が発生すると、 このユーザ操作に対応したユーザ入力 3 1 0がネイティブ実装プラッ トフオーム 3 0 1に入力される。 ステップ S 1 0 1で、 ネィティブ実 装プラットフオーム 3 0 1がこのユーザ入力 3 1 0を受け付けると、 次のステップ S 1 0 2で、 ネイティブ実装プラットフォーム 3 0 1は 、 受け付けたユーザ入力 3 1 0をムービープレーヤ 3 0 0に対する制 御コマンド 3 1 1に変換し、 ムービープレーヤ 3 0 0に通知する。 ムービープレーヤ 3 0 0は、 この制御コマンド 3 1 1を受け取ると 、 現在再生中のプレイリストのコマンドフィルタテーブル 5 0 1を参 照する （ステップ S 1 0 3 ) 。 そして、 ステップ S 1 0 4で、 コマン ドフィルタテーブル 5 0 1に基づき、 通知された制御コマンド 3 1 1 の実行が許可されているか否かを判断する。 若し、 当該制御コマンド
3 1 1の実行が許可されていないと判断されれば、 処理はステップ S 1 0 5に移行し、 ムービープレーヤ 3 0 0は、 当該制御コマンド 3 1 1による処理を実行しない。
一方、 ステップ S 1 0 4で、 当該制御コマンド 3 1 1の実行が許可 されていると判断されれば、 処理はステップ S 1 0 6に移行する。 ス テツプ S 1 0 6では、 当該制御コマンド 3 1 1が現在再生中のプレイ リスト内において実行されるものであるか否かが判断される。 すなわ ち、 ステップ S 1 0 6では、 例えば、 制御コマンド 3 1 1が当該プレ ィリスト内の他のチヤプタにジャンプするチヤプ夕ジャンプや、 スト リーム切り替えのような動作を指示する、 現在再生中のプレイリスト 内で実行されるものであるか、 他のプレイリストの所定のチヤプタか らの再生開始を指示するような、 現在のプレイリスト再生を中断して 新たに他のプレイリス卜の再生を開始するものであるかを判断する。 若し、 ステップ S 1 0 6で、 当該制御コマンド 3 1 1が現在再生中 のプレイリスト内で実行されるものであると判断されれば、 処理はス テツプ S 1 0 7に移行され、 当該制御コマンド 3 1 1が実行される。 なお、 この制御コマンド 3 1 1の実行に対して、 イベントハンドラに より制限を与えることができる。 すなわち、 ユーザオペレーションに 対して、 ユーザオペレーションマスクによるフィルタリングを行った 後に、 さらにイベントハンドラによるフィルタリングを行うことがで さる。
一方、 ステップ S 1 0 6で、 当該制御コマンド 3 1 1が現在再生中 のプレイリス卜で実行されるものではないと判断されれば、 処理はス テツプ S 1 0 8に移行される。 ステップ S 1 0 8では、 新たに再生が 開始されようとしている他のプレイリストのコマンドフィルタテ一ブ ル 5 0 1が参照される。 例えば、 上述のステップ S 1 0 2でムービー プレーヤ 3 0 0に通知された制御コマンド 3 1 1が、 現在再生中のプ レイリストから他のプレイリス卜にジャンプする動作を指示するコマ ンドであるような場合、 ジャンプ先のプレイリストのコマンドフィル 夕テーブル 5 0 1が参照される。
処理はステップ S 1 0 9に移行され、 新たに再生が開始されようと している他のプレイリストのコマンドフィル夕テーブル 5 0 1に基づ き、 当該他のプレイリストにおいて、 先頭からの再生のみが許可され ているか否かが判断される。 若し、 先頭からの再生のみが許可されて いると判断されれば、 処理はステップ S 1 1 0に移行される。 そして 、 ムービープレーヤ 3 0 0は、 当該制御コマンド 3 1 1が当該他のプ レイリストの先頭以外の位置からの再生を指示するものであっても、 当該他のプレイリストの先頭から再生開始するように、 プレイパック モジュール 3 2 1に対して指示する。
一方、 ステップ S 1 0 9で、 当該他のプレイリストが先頭以外の位 置からの再生が許可されていると判断されれば、 処理はステップ S 1 1 1に移行される。 そして、 ム一ビープレーヤ 3 0 0は、 当該制御コ マンド 3 1 1に従い、 制御コマンド 3 1 1により指定された時刻ゃチ ャプ夕から当該他のプレイリストを再生するように、 プレイバックモ ジュール 3 2 1に対して指示する。
以上説明したようにして、 この発明の実施の一形態によるユーザォ ペレーシヨンの制御が実現される

Claims

請 求 の 範 囲
1 . 円盤状記録媒体に記録されたコンテンツデータを再生する再生装 置において、
少なくともコンテンツデータと、 該コンテンツデータに対する再生 経路を指定し、 属性情報として上記コンテンツデータの再生制御指示 に対する制限モードを示す値を含む再生指示情報と、 該コンテンツデ 一夕の再生を制御する再生制御プログラムとが記録された記録媒体か らデ一夕を読み出す読み出し手段と、
上記再生制御プログラムに従い上記コンテンツデータを再生するプ レーャ手段と、
上記コンテンツデータの上記再生制御指示を与えるためのユーザォ ペレ一ションに応じて上記プレーヤ手段に対する制御コマンドを生成 する制御コマンド生成手段と
を有し、
上記プレーヤ手段は、 上記記録媒体から上記再生指示情報毎に上記 制限モードを示す値を読み出し、 読み出された該制限モードを示す値 に基づき上記再生指示情報毎にテーブルを生成し、 上記制御コマンド 生成手段で生成された上記制御コマンドの実行を許可するか否かを、 上記テーブルに基づき上記再生指示情報毎に制御するようにしたこと を特徴とする再生装置。
2 . 請求の範囲 1に記載の再生装置において、
上記制限モードは、 上記プレーヤ手段に対して上記コンテンツデー 夕の再生停止を指示する上記制御コマンドのみを許可するモードであ ることを特徴とする再生装置。
3 . 請求の範囲 1に記載の再生装置において、
上記制限モードは、 上記制御コマンドが、 上記制限モードを示す値 が含まれる上記属性情報を持つ上記再生指示情報に対応した再生区間 内の任意の時刻からの再生開始を指示する場合に、 該再生区間の先頭 から所定の再生速度で再生を行うように上記プレーヤ手段を制御する モードであることを特徴とする再生装置。
4 . 請求の範囲 1に記載の再生装置において、
上記制限モードは、
上記制限モードが示す値が含まれる上記属性情報を持つ上記再生指 示情報に対応する上記コンテンツデータを再生中に上記制御コマンド があった場合に、 上記プレーヤ手段に対して上記コンテンツデータの 再生停止を指示する上記制御コマンドのみを許可し、
上記制限モードを示す値が含まれる上記属性情報を持つ上記再生指 示情報に対応した再生区間内の任意の時刻からの再生開始を指示する 上記制御コマンドがあった場合に、 該再生区間の先頭から所定の再生 速度で再生を行うように上記プレーヤ手段を制御する
モードであることを特徴とする再生装置。
5 . 請求の範囲 1に記載の再生装置において、
上記制限モードは、 上記制限モードが示す値が含まれる上記属性情 報を持つ上記再生指示情報に対応する上記コンテンツデータを再生中 に、 上記制御コマンドが該再生指示情報に対応する該コンテンツデー 夕の再生を中止して該再生指示情報に対応した再生区間の末尾にジャ ンプすることを指示する場合、 該制御コマンドの実行を禁止するモー ドであることを特徴とする再生装置。
6 . 請求の範囲 1に記載の再生装置において、
上記プレーヤ手段は、 上記制御コマンドがあつたときに、 現在再生 中の上記コンテンツデータに対応する上記再生指示情報の上記属性情 報に含まれる上記制限モードを示す値に基づく上記テーブルにより該 制御コマンドの実行が許可されているか否かを判断し、
許可されていると判断された場合、 該制御コマンドが該再生指示情 報に対応した第 1の再生区間内で実行されるものか否かをさらに判断 し、
該制御コマンドが該第 1の再生区間内で実行されるものではないと 判断された場合に、 該制御コマンドにより新たに再生開始されようと している第 2の再生区間に対応する上記再生指示情報の上記属性情報 に含まれる上記制限モ一ドを示す値に基づく上記テーブルにより該第 2の再生区間の先頭からの再生のみが許可されているか否かをさらに 判断する
ようにしたことを特徴とする再生装置。
7 . 円盤状記録媒体に記録されたコンテンツデ一タを再生する再生方 法において、
少なくともコンテンツデ一夕と、 該コンテンッデータに対する再生 経路を指定し、 属性情報として上記コンテンツデータの再生制御指示 に対する制限モードを示す値を含む再生指示情報と、 該コンテンツデ 一夕の再生を制御する再生制御プログラムとが記録された記録媒体か らデータを読み出す読み出しのステップと、 上記再生制御プログラムに従い上記コンテンッデ一夕を再生するコ ンテンッ再生のステップと、
上記コンテンツデータの上記再生制御指示を与えるためのユーザォ ペレーシヨンに応じて上記プレーヤ手段に対する制御コマンドを生成 する制御コマンド生成のステップと
を有し、
上記コンテンツ再生のステップは、 上記記録媒体から上記再生指示 情報毎に上記制限モードを示す値を読み出し、 読み出された該制限モ 一ドを示す値に基づき上記再生指示情報毎にテーブルを生成し、 上記 制御コマンド生成のステップで生成された上記制御コマンドの実行を 許可するか否かを、 上記テーブルに基づき上記再生指示情報毎に制御 するようにしたことを特徴とする再生方法。
8 . 円盤状記録媒体に記録されたコンテンツデータを再生する再生方 法をコンピュータ装置に実行させる再生プログラムにおいて、 上記再生方法は、
少なくともコンテンツデータと、 該コンテンツデ一夕に対する再生 経路を指定し、 属性情報として上記コンテンツデータの再生制御指示 に対する制限モードを示す値を含む再生指示情報と、 該コンテンツデ
—夕の再生を制御する再生制御プログラムとが記録された記録媒体か らデータを読み出す読み出しのステップと、
上記再生制御プログラムに従い上記コンテンッデータを再生するコ ンテンッ再生のステップと、
上記コンテンツデータの上記再生制御指示を与えるためのユーザォ ペレーションに応じて上記プレーヤ手段に対する制御コマンドを生成 する制御コマンド生成のステップと
を有し、
上記コンテンツ再生のステップは、 上記記録媒体から上記再生指示 情報毎に上記制限モードを示す値を読み出し、 読み出された該制限モ ―ドを示す値に基づき上記再生指示情報毎にテーブルを生成し、 上記 制御コマンド生成のステップで生成された上記制御コマンドの実行を 許可するか否かを、 上記テーブルに基づき上記再生指示情報毎に制御 するようにしたことを特徴とする再生プログラム。
9 . 少なくとも
コンテンツデータと、 該コンテンツデータに対する再生経路を指定し、 属性情報として上 記コンテンツデータの再生制御指示に対する制限モードを示す値を含 む再生指示情報と、
該コンテンツデータの再生を制御する再生制御プログラムと が記録されることを特徴とする記録媒体。
1 0 . 請求の範囲 9に記載の記録媒体において、
再生装置により読み出された上記再生制御プログラムに従い上記コ ンテンッデ一夕が再生され、 上記コンテンツデータの上記再生制御指 示を与えるために上記再生装置に与えられるユーザオペレーションに 応じて上記コンテンツデータの再生を制御する制御コマンドが上記再 生装置上で生成され、
上記制限モードを示す値に基づき上記再生装置により上記再生指示 情報毎にテーブルが生成され、 上記制御コマンドの実行を上記再生装 置上で許可するか否かが、 上記テーブルに基づき上記再生指示情報毎 に制御されるようにしたことを特徴とする記録媒体。
1 1 . 請求の範囲 9に記載の記録媒体において、
上記制限モードは、 上記再生装置に対する上記コンテンツデ一夕の 再生停止の指示のみを許可するモ一ドであることを特徴とする記録媒 体。
1 2 . 請求の範囲 9に記載の記録媒体において、
上記制限モードは、 上記制限モードを示す値が含まれる上記属性情 報を持つ上記再生指示情報に対応した再生区間内の任意の時刻からの 再生開始が指示される場合に、 該再生区間の先頭から所定の再生速度 で再生を行うように上記再生装置による上記コンテンツデータの再生 を制御するモ一ドであることを特徴とする記録媒体。
1 3 . 請求の範囲 9に記載の記録媒体において、 上記制限モードは、
上記再生装置に対して、 再生中の上記制限モードが示す値が含まれ る上記属性情報を持つ上記再生指示情報に対応する上記コンテンツデ 一夕の再生停止の指示があった場合に、 該指示のみを許可し、 上記制限モードを示す値が含まれる上記属性情報を持つ上記再生指 示情報に対応した再生区間内の任意の時刻からの再生開始の指示があ つた場合に、 該再生区間の先頭から所定の再生速度で再生を行うよう に上記再生装置による上記コンテンツデータの再生を制御する モードであることを特徴とする記録媒体。
1 4 . 請求の範囲 9に記載の記録媒体において、
上記制限モードは、 上記制限モ一ドが示す値が含まれる上記属性情 報を持つ上記再生指示情報に対応する上記コンテンツデータを上記再 生装置が再生中に、 上記制御コマンドが該再生指示情報に対応する該 コンテンツデータの再生を中止して該再生指示情報に対応した再生区 間の末尾にジャンプする指示があった場合、 該指示の実行を禁止する モードであることを特徴とする記録媒体。
1 5 . 請求の範囲 1 0に記載の記録媒体において、
上記再生装置上で上記制御コマンドが生成されたときに、 現在再生 中の上記コンテンツデ一夕に対応する上記再生指示情報の上記属性情 報に含まれる上記制限モ一ドを示す値に基づく上記テーブルにより該 制御コマンドの実行が許可されているか否かが判断され、
許可されていると判断された場合、 該制御コマンドが該再生指示情 報に対応した第 1の再生区間内で実行されるものか否かがさらに判断 され、
該制御コマンドが該第 1の再生区間内で実行されるものではないと 判断された場合に、 該制御コマンドにより新たに再生開始されようと している第 2の再生区間に対応する上記再生指示情報の上記属性情報 に含まれる上記制限モードを示す値に基づく上記テーブルにより該第 2の再生区間の先頭からの再生のみが許可されているか否かがさらに 判断される
ようにしたことを特徴とする記録媒体。
1 6 . 少なくとも
コンテンツデータと、
該コンテンツデータに対する再生経路を指定し、 属性情報として上 記コンテンツデータの再生制御指示に対する制限モードを示す値を含 む再生指示情報と、
該コンテンッデータの再生を制御する再生制御プログラムと を有することを特徴とするデータ構造。
PCT/JP2005/014490 2004-08-19 2005-08-02 再生装置、再生方法、再生プログラム、記録媒体、ならびに、データ構造 WO2006018999A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
AU2005273384A AU2005273384A1 (en) 2004-08-19 2005-08-02 Reproduction device, reproduction method, reproduction program, recording medium, and data structure
EP05768388A EP1783771B1 (en) 2004-08-19 2005-08-02 Reproduction device, reproduction method and reproduction program
CA002576305A CA2576305A1 (en) 2004-08-19 2005-08-02 Reproducing apparatus, reproducing method, reproducing program, recording medium, and data structure
NZ553138A NZ553138A (en) 2004-08-19 2005-08-02 Reproduction device, reproduction method, reproduction program, recording medium, and data structure
US11/573,717 US20080075437A1 (en) 2004-08-19 2005-08-02 Reproduction Device, Reproduction Method, Reproduction Program, Recording Medium, and Data Structure
PL05768388T PL1783771T3 (pl) 2004-08-19 2005-08-02 Urządzenie odtwarzające, sposób odtwarzania oraz program odtwarzający
BRPI0514464-7A BRPI0514464A (pt) 2004-08-19 2005-08-02 aparelho de reprodução, método de reprodução de dados de conteúdo de reprodução de um meio de gravação em forma de disco, programa de reprodução, meio de gravação, e, estrutura de dados
MX2007001791A MX2007001791A (es) 2004-08-19 2005-08-02 Dispositivo de reproduccion, metodo de reproduccion, programa de reproduccion, metodo de registro y estructura de datos.
HK07109455.2A HK1101620A1 (en) 2004-08-19 2007-08-30 Reproduction device, reproduction method and reproduction program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004239346A JP4332089B2 (ja) 2004-08-19 2004-08-19 再生装置、再生方法および再生プログラム、ならびに、記録媒体
JP2004-239346 2004-08-19

Publications (1)

Publication Number Publication Date
WO2006018999A1 true WO2006018999A1 (ja) 2006-02-23

Family

ID=35907389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/014490 WO2006018999A1 (ja) 2004-08-19 2005-08-02 再生装置、再生方法、再生プログラム、記録媒体、ならびに、データ構造

Country Status (16)

Country Link
US (1) US20080075437A1 (ja)
EP (1) EP1783771B1 (ja)
JP (1) JP4332089B2 (ja)
KR (1) KR20070053270A (ja)
CN (1) CN101044572A (ja)
AU (1) AU2005273384A1 (ja)
BR (1) BRPI0514464A (ja)
CA (1) CA2576305A1 (ja)
HK (1) HK1101620A1 (ja)
MX (1) MX2007001791A (ja)
MY (1) MY149579A (ja)
NZ (1) NZ553138A (ja)
PL (1) PL1783771T3 (ja)
RU (1) RU2358335C2 (ja)
TW (1) TW200608363A (ja)
WO (1) WO2006018999A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2005332685B2 (en) * 2005-06-03 2011-02-03 The Nielsen Company (Us), Llc Methods and apparatus to detect a time-shift event associated with the presentation of media content
JP4642655B2 (ja) * 2005-12-28 2011-03-02 ソニー株式会社 再生装置および再生方法、プログラム、記録媒体、データ構造、記録媒体の製造方法および記録装置、並びに、データ構造の生成方法および生成装置
KR20070074432A (ko) * 2006-01-09 2007-07-12 엘지전자 주식회사 데이터 재생 방법 및 장치, 그리고 기록매체
US8156089B2 (en) * 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
US8578272B2 (en) 2008-12-31 2013-11-05 Apple Inc. Real-time or near real-time streaming
US8099473B2 (en) * 2008-12-31 2012-01-17 Apple Inc. Variant streams for real-time or near real-time streaming
US8260877B2 (en) 2008-12-31 2012-09-04 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
US9595300B2 (en) * 2009-10-21 2017-03-14 Media Ip, Llc Contextual chapter navigation
US8977783B2 (en) * 2009-10-21 2015-03-10 Media Ip, Llc High-speed secure content transfer to SD card from kiosk
US8942549B2 (en) * 2009-10-21 2015-01-27 Media Ip, Llc Resume point for digital media playback
US8898803B1 (en) 2010-01-11 2014-11-25 Media Ip, Llc Content and identity delivery system for portable playback of content and streaming service integration
GB201105502D0 (en) 2010-04-01 2011-05-18 Apple Inc Real time or near real time streaming
US8560642B2 (en) 2010-04-01 2013-10-15 Apple Inc. Real-time or near real-time streaming
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
TWI451279B (zh) 2010-04-07 2014-09-01 Apple Inc 即時或接近即時串流傳輸之內容存取控制
US8543724B2 (en) 2010-04-30 2013-09-24 Digital Keystone, Inc. Methods and apparatuses for a projected PVR experience
US8745749B2 (en) 2010-11-15 2014-06-03 Media Ip, Llc Virtual secure digital card
KR101831775B1 (ko) 2010-12-07 2018-02-26 삼성전자주식회사 멀티미디어 컨텐츠를 송수신하는 송신 장치 및 수신 장치와, 그 재생 방법
KR20120063451A (ko) 2010-12-07 2012-06-15 삼성전자주식회사 컨텐츠를 구성하는 데이터를 송신하는 송신 장치와 그 데이터를 수신하여 처리하는 수신 장치 및 그 방법
US8775827B2 (en) 2011-03-28 2014-07-08 Media Ip, Llc Read and write optimization for protected area of memory
US8949879B2 (en) 2011-04-22 2015-02-03 Media Ip, Llc Access controls for known content
US8856283B2 (en) 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming
US8843586B2 (en) 2011-06-03 2014-09-23 Apple Inc. Playlists for real-time or near real-time streaming
JP6181911B2 (ja) * 2012-04-23 2017-08-16 三菱電機ビルテクノサービス株式会社 映像データ処理装置、映像データ処理方法及びプログラム
US10741221B2 (en) * 2017-07-12 2020-08-11 Disney Enterprises, Inc. Menu navigation mode for media discs
CN109819306B (zh) * 2018-12-29 2022-11-04 花瓣云科技有限公司 一种媒体文件裁剪的方法、电子设备和服务器

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001332006A (ja) * 2000-05-17 2001-11-30 Toshiba Corp 背景画像取り込みシステム
US20050105888A1 (en) 2002-11-28 2005-05-19 Toshiya Hamada Reproducing device, reproduction method, reproduction program, and recording medium

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000358217A (ja) * 1999-06-14 2000-12-26 Matsushita Electric Ind Co Ltd デジタル放送システムおよびデジタルビデオ記録再生装置
AU2000264732A1 (en) * 2000-08-09 2002-02-18 Kanars Data Corporation Contents distribution system and distributed contents reproducing device
JP3818847B2 (ja) * 2000-12-27 2006-09-06 パイオニア株式会社 情報記録再生装置及び情報記録再生方法
KR20040000290A (ko) * 2002-06-24 2004-01-03 엘지전자 주식회사 고밀도 광디스크의 멀티 경로 데이터 스트림 관리방법
WO2005024828A1 (ja) * 2003-09-02 2005-03-17 Matsushita Electric Industrial Co., Ltd. 再生装置、システム集積回路、プログラム、再生方法、及び、情報記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001332006A (ja) * 2000-05-17 2001-11-30 Toshiba Corp 背景画像取り込みシステム
US20050105888A1 (en) 2002-11-28 2005-05-19 Toshiya Hamada Reproducing device, reproduction method, reproduction program, and recording medium

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN101044572A (zh) 2007-09-26
RU2007106077A (ru) 2008-08-27
JP4332089B2 (ja) 2009-09-16
BRPI0514464A (pt) 2008-06-10
CA2576305A1 (en) 2006-02-23
EP1783771A4 (en) 2009-04-08
MY149579A (en) 2013-09-13
TW200608363A (en) 2006-03-01
US20080075437A1 (en) 2008-03-27
JP2006059434A (ja) 2006-03-02
PL1783771T3 (pl) 2013-03-29
EP1783771A1 (en) 2007-05-09
TWI312505B (ja) 2009-07-21
NZ553138A (en) 2010-03-26
KR20070053270A (ko) 2007-05-23
AU2005273384A1 (en) 2006-02-23
RU2358335C2 (ru) 2009-06-10
HK1101620A1 (en) 2007-10-18
MX2007001791A (es) 2007-04-26
EP1783771B1 (en) 2012-10-03

Similar Documents

Publication Publication Date Title
WO2006018999A1 (ja) 再生装置、再生方法、再生プログラム、記録媒体、ならびに、データ構造
TWI328801B (ja)
US8019199B2 (en) Reproduction device, reproduction method, reproduction program, recording medium, and data structure
JP4241731B2 (ja) 再生装置、再生方法、再生プログラムおよび記録媒体
US8005339B2 (en) Reproduction apparatus, reproduction method, reproduction program, record medium, and data structure
US8139926B2 (en) Reproduction apparatus, reproduction method, reproduction program, record medium, and data structure
US20050149214A1 (en) Recording medium having a data structure for managing sound data and recording and reproducing methods and apparatus
JP5655478B2 (ja) 情報処理装置、情報処理方法
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 KP KR KZ LC LK LR LS LT LU LV 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: 2576305

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2005273384

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2005768388

Country of ref document: EP

Ref document number: 553138

Country of ref document: NZ

WWE Wipo information: entry into national phase

Ref document number: MX/a/2007/001791

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 1226/DELNP/2007

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 11573717

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2007106077

Country of ref document: RU

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2005273384

Country of ref document: AU

Date of ref document: 20050802

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2005273384

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 1020077006148

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 200580035923.X

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2005768388

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11573717

Country of ref document: US

ENP Entry into the national phase

Ref document number: PI0514464

Country of ref document: BR