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

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

Info

Publication number
WO2005122175A1
WO2005122175A1 PCT/JP2005/010905 JP2005010905W WO2005122175A1 WO 2005122175 A1 WO2005122175 A1 WO 2005122175A1 JP 2005010905 W JP2005010905 W JP 2005010905W WO 2005122175 A1 WO2005122175 A1 WO 2005122175A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
data
information
mark
playlist
Prior art date
Application number
PCT/JP2005/010905
Other languages
English (en)
French (fr)
Inventor
Yasushi Fujinami
Toshiya Hamada
Tatsuya Kakumu
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 CA002569780A priority Critical patent/CA2569780A1/en
Priority to EP05751015A priority patent/EP1758120A4/en
Priority to KR1020067025928A priority patent/KR101118823B1/ko
Priority to US11/628,358 priority patent/US8340495B2/en
Priority to CN2005800271962A priority patent/CN101002268B/zh
Publication of WO2005122175A1 publication Critical patent/WO2005122175A1/ja

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
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • 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
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/20—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of the game platform
    • A63F2300/206—Game information storage, e.g. cartridges, CD ROM's, DVD's, smart cards
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2562—DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction

Definitions

  • Data processing apparatus and data processing method program and program recording medium, data recording medium, and data structure
  • the present invention relates to a data processing device and a data processing method, a program and a program recording medium, a data recording medium, and a data structure.
  • the present invention relates to a processing device and a data processing method, a program and a program recording medium, a data recording medium, and a data structure.
  • a DVD Digital Versatile Disc
  • a DVD apparatus that performs various processes using a DVD has also become widespread.
  • Examples of the DVD device include a DVD recorder for recording and reproducing data of a television broadcast program on a DVD, a car navigation system for recording map information and the like on a DVD and displaying the map information, and a DVD.
  • Non-Patent Document 1 DVD Specification for Read-Only Disc Part 3; Version 1.1 Dcecmber 1997”.
  • the present invention has been made in view of such a situation, and is intended to perform data processing with high convenience and the like.
  • the data processing device provides a method in which time information indicating one reproduction time on the time axis of a playlist, type information indicating a type of mark information, and a A determination is made as to whether or not the reproduction time of the data being reproduced according to the playlist including the mark information including the argument information serving as the argument of the event matches the time information.
  • the type information indicates the type that causes the event
  • the argument information of the mark information and the occurrence of the event are notified.
  • a executing means for executing a process corresponding to the argument information notified by the notifying means.
  • the time information indicating one playback time on the time axis of the playlist, the type information indicating the type of the mark information, and the evening information indicates the type that generates the event
  • a determination is made as to whether or not the reproduction time of the data being reproduced according to the playlist including the mark information including the argument information serving as the argument of the event matches the time information.
  • the mark information having the time information it is recognized that the mark information having the time information is recognized.
  • an execution step of executing a process according to the argument information notified by the notification step.
  • the program according to the present invention includes a time information representing one reproduction time on a time axis of a playlist, a type information representing a type of mark information, and an event when the type information represents a type that generates an event. Determining whether or not the reproduction time of the data reproduced according to the playlist including the mark information including the argument information as the argument of the data coincides with the time information.
  • a recognition step for recognizing the mark information having the time information and the mark information recognized in the recognition step have the When the type information indicates the type that causes the event, the argument information having the mark information and the event information
  • a notification step of notifying the raw characterized in that it comprises an execution step that perform processing corresponding to the argument information notified by the notification step.
  • the program recorded on the program recording medium of the present invention includes time information indicating one reproduction time on the time axis of the playlist, type information indicating the type of mark information, and an event in which the type information generates an event. Indicates whether the playback time of the data played according to the playlist including the mark information including the mark information including the argument information serving as the argument of the event matches the time information.
  • a recognition step of recognizing the mark information having the following: when the type information of the mark information recognized in the recognition step indicates a type that causes an event, the argument information of the mark information; and the event A notification step of notifying the occurrence of the error, and an execution step of executing a process according to the argument information notified by the notification step.
  • the data recording medium of the present invention records recorded data including encoded data obtained by encoding data and a playlist indicating a data reproduction procedure, and the playlist is composed of the playlist.
  • the playlist includes playlist mark information having mark information serving as a mark on the time axis, the mark information includes time information indicating one playback time on the time axis of the playlist, type information indicating a type of mark information, When the type information indicates a type that generates an event, the type information includes argument information serving as an argument of the event.
  • the data structure of the present invention is a data structure that includes encoded data obtained by encoding data and a playlist that indicates a playback procedure of a video, wherein the playlist is a mark on the time axis of the playlist.
  • the playlist contains mark information, which is a piece of play information on the time axis of the playlist, time information indicating the time, type information indicating the type of mark information, and type information indicating an event.
  • the argument information that is the argument of the event when expressing the type that generates the event. .
  • time information indicating one reproduction time on the time axis of the playlist, and type indicating the type of mark information are provided.
  • Information and the type information trigger the event
  • the play time of the data being played according to the playlist containing the mark information including the mark information including the argument information as the argument of the event when the type of the event is represented matches the time information. If it is determined that the reproduction time of the data matches the time information, the mark information having the time information is recognized. Further, when the type information included in the recognized mark information indicates the type that causes the event, the argument information included in the mark information and the occurrence of the event are notified, and the processing according to the argument information is performed. Is executed.
  • recorded data including encoded data obtained by encoding data and a playlist indicating a data reproduction procedure are recorded, and the playlist is based on the time axis of the playlist.
  • the playlist includes playlist mark information having mark information serving as an upper mark.
  • the mark information includes time information indicating one playback time on the time axis of the playlist, type information indicating the type of mark information, and type information. When indicating the type that generates the event, it contains the argument information that is the argument of the event.
  • the playlist in a data structure including encoded data obtained by encoding data and a playlist indicating a data reproduction procedure, the playlist is a mark on the time axis of the playlist.
  • the playlist includes playlist mark information having mark information.
  • the mark information includes time information indicating one playback time on the time axis of the playlist, type information indicating the type of mark information, and type information indicating an event. Contains the argument information that is the argument of the event when expressing the type that generates the event.
  • FIG. 1 is a block diagram showing an example of a hardware configuration of a disk device according to an embodiment of the present invention.
  • FIGS. 2A and 2B are diagrams showing a configuration of a software module group executed by a CPU 112.
  • FIG. 3 is a block diagram showing a configuration example of the buffer control module 215
  • FIG. 4 is a diagram showing a directory configuration example on the disk 101
  • FIG. 5 is a diagram showing "PLAYLIST.
  • Fig. 6 shows the syntax of PlayltemO
  • Fig. 7 shows the syntax of PlayListMarkO
  • Fig. 8 shows the relationship between the value of mark_type and the type of MarkO.
  • Fig. 9 is a diagram showing the relationship between PlayListO, PlayltemO, clips, and the program stream stored in the clip stream file.
  • FIG. 10 is a diagram showing the syntax of the clip information file ClipO.
  • FIG. 11 is a diagram showing the relationship between the stream_id and private_stream_id for identifying the elementary stream and the elementary stream
  • FIG. 12 is a diagram showing the syntax of StaticInfoO
  • FIG. 13 is a diagram showing the syntax of DynamicInfoO
  • FIG. 14 is a diagram showing the syntax of EP-map ()
  • FIG. 15A and FIG. 15B are program streams of the MPEG-2 System
  • Figures 16A and 16B show the syntax of the program stream pack and the program stream pack header.
  • Figures 17A and 16B show the syntax of the MPEG-2 System PES packet.
  • 7B and FIG. 17C are diagrams showing the syntax of the MPEG-2 System PES packet.
  • FIGS. 18A and 18B are diagrams showing the syntax of the MPEG-2 System PES packet.
  • 9A and 1B are diagrams showing the relationship between the value described in the stream JD of PES-packet 0 in the MPEG-2 System and the attribute (type) of the elementary stream.
  • Fig. 21 shows the streamjd used by the disk device.
  • Fig. 21 shows the private_stream and PES_payload () syntax.
  • Fig. 22 shows the private_stream-id value and private-payload ().
  • 23 is a diagram showing the syntax of private__stream2_PES_payload ()
  • FIG. 24 is a diagram showing the syntax of au_information ()
  • FIG. 25 is a diagram showing "PLAYLIST 26A and 26B are diagrams showing specific examples of the clip information files "00001.
  • FIG. 27 is a diagram showing a specific example of EP_map () in the clip information file "00001. CLP”.
  • Fig. 28 is FIG. 29 shows a specific example of PlayListMarkO in PlayList # 0 and PlayList # 1, FIG. 29 is a flowchart for explaining pre-playback processing, FIG. 30 is a flow chart for explaining reproduction processing, and FIG. The figure shows a flow chart explaining the Playltem transfer processing, FIG. 32 shows a flow chart explaining the time code display processing, FIG. 33 shows a flow chart explaining the stream switching processing, and FIG. 34 shows the buffer control 35 is a flowchart for explaining the processing of the module 215, FIG.
  • FIG. 35 is a flowchart for explaining the processing of the buffer control module 215, FIG. 36 is a flowchart for explaining the processing of reading a video stream, and FIG. FIG. 7 is a flowchart for explaining the processing for reading the audio stream, and FIG. 38 is a flowchart for explaining the processing for reading the subtitle stream.
  • FIG. 39 is a flowchart illustrating resynchronization processing
  • FIG. 40 is a flowchart illustrating mark processing
  • FIG. 41 is a flowchart illustrating output attribute control processing
  • FIG. 42 is clip information.
  • File "00003. CLP Figure 43 shows an example of the actual set of pt s__change_point and Dynamic Info described in ".
  • Figure 43 is a flowchart explaining the subtitle display control processing.
  • Figure 44 is the capture control.
  • FIG. 45 is a diagram showing another syntax of pr ivat e_s t ream2_PES_payl oad (), and FIG. 46 is au_in format ion 0 11 is a diagram illustrating another syntax of the present invention.
  • the data processing device In a data processing device for processing recording data recorded on a data recording medium (for example, a disk device in FIG. 1),
  • a playlist (for example, P1 ayList 0 in FIG. 5) representing the procedure for reproducing the data
  • the playlist includes playlist mark information (for example, PlayListMarkO in FIG. 5) having mark information (for example, MarkO in FIG. 7) serving as a mark on the time axis of the playlist,
  • the mark information includes:
  • Time information indicating one playback time on the time axis of the playlist (for example, mark_time__stamp in FIG. 7);
  • Type information indicating the type of the mark information (for example, mark_type in FIG. 7);
  • the argument information (eg, mark—data in FIG. 7) that is the argument of the event
  • Judgment means for judging whether or not the reproduction time of the data reproduced according to the playlist matches the time information (for example, FIG. 2A for performing the processing of step S301 in FIG. 40) And the decode control module 2 14) in Fig. 2B,
  • the recognition unit recognizes the mark information having the time information (for example, the process of step S302 in FIG. 40).
  • the player control module 2 1 2) of FIGS. 2A and 2B and the type information of the mark information recognized by the recognition means indicates a type that generates an event
  • Notification means for notifying the argument information included in the mark information and the occurrence of an event (for example, the player control module shown in FIGS. 2A and 2B for performing the processing of step S307 in FIG. 40) 2 1 2) and
  • Execution means for executing processing according to the argument information notified by the notification means for example, the script control module 2 1 1 of FIGS. 2A and 2B for performing the processing of step S 308 in FIG. 40) )
  • the recording data is a
  • a playlist (for example, P1ayListO in FIG. 5) representing the procedure for reproducing the data
  • the playlist includes playlist mark information (for example, PlayListMarkO in FIG. 5) having mark information (for example, MarkO in FIG. 7) serving as a mark on the time axis of the playlist,
  • the mark information is:
  • Time information (eg, mark—time_stamp in FIG. 7) indicating one playback time on the time axis of the playlist;
  • Type information indicating the type of the mark information (for example, mark_type in FIG. 7);
  • argument information for example, mark-1 dat a in FIG. 7 serving as an argument of the event and
  • a determining step for example, step S310 in FIG. 40 for determining whether or not the reproduction time of the data reproduced according to the playlist matches the time information
  • a recognition step of recognizing the mark information having the time information (for example, step S30 in FIG. 40) 2) and
  • a notification step of notifying the argument information included in the mark information and the occurrence of the event For example, step S307 in FIG. 40)
  • An execution step of executing a process according to the argument information notified by the notification step (for example, step S308 in FIG. 40).
  • a playlist (for example, P 1 ayL ist O in FIG. 5) representing the procedure for reproducing the data Including
  • the playlist includes playlist mark information (for example, PyL istMark O in FIG. 5) having mark information (for example, Mark O in FIG. 7) serving as a mark on the time axis of the playlist. ,
  • playlist mark information for example, PyL istMark O in FIG. 5
  • mark information for example, Mark O in FIG. 7
  • the mark information includes:
  • Time information indicating one playback time on the time axis of the playlist (for example, mark-time-stamp in FIG. 7);
  • Type information indicating the type of the mark information for example, mark.type in FIG. 7
  • argument information serving as an argument of the event when the type information indicates a type that generates an event for example, Mark_data a
  • a determining step for example, step S310 in FIG. 40 for determining whether or not the playback time of the data being played back according to the playlist matches the time information
  • a recognition step of recognizing the mark information having the time information (for example, step S30 in FIG. 40) 2) and
  • a notification step of notifying the argument information included in the mark information and the occurrence of the event For example, step S307 in FIG. 40)
  • An execution step of executing a process according to the argument information notified by the notification step (for example, step S308 in FIG. 40).
  • the data recording medium described in claim 6 is
  • a playlist showing the playback procedure of the above-mentioned day (for example, P1 in FIG. 5)
  • the playlist includes playlist mark information (for example, PlayListMarkO in FIG. 5) having mark information (for example, MarkO in FIG. 7) serving as a mark on the time axis of the playlist,
  • the mark information includes:
  • Time information indicating one playback time on the time axis of the playlist (for example, mark—time one st amp in FIG. 7);
  • Type information representing the type of the mark information (for example, type of mark in FIG. 7);
  • the argument information (for example, mark-1 dat a in FIG. 7) and the argument
  • the data structure described in claim 7 is:
  • a playlist (for example, P1 ayList () in FIG. 5) representing the playback procedure of the above
  • the playlist includes playlist mark information (for example,? 1 &! ⁇ 313 ⁇ 4 ⁇ 0 in FIG. 5) having mark information (for example, MarkO in FIG. 7) serving as a mark on the time axis of the playlist.
  • Mark information includes:
  • Time information indicating one playback time on the time axis of the playlist (for example, mark_Ume_s t amp in FIG. 7);
  • Type information indicating the type of the mark information (for example, “mark—type” in FIG. 7);
  • argument information (for example, mark-1 dat a in FIG. 7) serving as an argument of the event and
  • FIG. 1 is a block diagram showing an example of a hardware configuration of a disk device according to an embodiment of the present invention.
  • the disk device shown in FIG. 1 can be applied to, for example, a disk player, a game device, a car navigation system, and the like.
  • the disk 101 is, for example, an optical disk such as a DVD, or a magneto-optical disk, a magnetic disk, or the like.
  • the disk 101 is used for content data such as video data, audio data, and subtitle data. Further, data necessary for reproducing the content data is recorded.
  • the data (recorded data) recorded on the disc 101 also includes a computer-executable program as necessary.
  • the disc 101 which is a disc-shaped recording medium, is adopted as the recording medium.
  • other recording media such as a semiconductor memory or a tape-shaped recording medium, may be used. Good.
  • the first In the illustrated disk device data read from a distant disk 101 and transmitted can be input. That is, data can be read from the disk 101 by another device connected to the disk device, and the data read by the other device can be received and processed by the disk device.
  • the disk device it is also possible to receive and process data from a server or the like storing the same data as the data recorded on the disk 101 in a storage via a network such as the Internet. is there. Further, in the disk device, it is possible to receive data from a server or other device, record the data temporarily on the disk 101, and then process the data recorded on the disk 101. .
  • the disk 101 is detachable from the disk drive 102.
  • the disk drive 102 has a built-in interface (not shown), and is connected to the drive interface 114 through the interface.
  • the disk drive 102 drives the disk 101 mounted thereon, reads data from the disk 101 in accordance with a command such as reading from the drive interface 114, and reads the data from the disk interface 114.
  • Bus 1 1 1 has a CPU (Central Processing Unit) 1 1 2, memory 1 1 3, drive interface 1 14, input interface 1 1 5, video decoder 1 1 6, audio decoder 1 1 7, video output interface 1 1 8, Audio output interface 1 1 9 is connected.
  • CPU Central Processing Unit
  • the CPU 112 and the memory 113 form a computer system. That is, the CPU 112 executes a software module group, which will be described later, which is a program stored in the memory 113, and the disk device. In addition to controlling the entire system, various processes described later are performed.
  • the memory 113 stores a group of software modules executed by the CPU 112.
  • the memory 113 temporarily stores data necessary for the operation of the CPU 112.
  • the memory 113 can be composed of only a nonvolatile memory or a combination of a volatile memory and a nonvolatile memory.
  • the memory 113 is provided as follows. It is possible to construct only with volatile memory.
  • the program (software module group) executed by the CPU 112 can be recorded (stored) in advance in the memory 113 serving as a recording medium built in the disk device. .
  • the program may be a disk 101, a flexible disk other than disk 101, a CD-R0M (Compact Disk Read 0 nly Memory), an MO (Magne to Optical) disk, or a magnetic disk. It can be stored (recorded) temporarily or permanently on a removable recording medium such as a memory card. Such a removable recording medium can be provided as so-called package software.
  • the program can be stored in the memory 113 in advance, or can be installed in a disk device from a removable recording medium as described above.
  • the program can be transmitted wirelessly from a down site to a disk device via an artificial satellite for digital satellite broadcasting, or transmitted to a disk via a network such as a LAN (Local Area Network) or the Internet.
  • the program is transferred to the device by wire, and the disk device receives the transferred program by the input interface 115 and instructs the built-in memory 113 Can be tall.
  • the program may be processed by one CPU, or may be processed in a distributed manner by a plurality of CPUs.
  • the drive-in interface 114 controls the disk drive 102 under the control of the CPU 112, whereby the data read from the disk 101 by the disk drive 102 is transferred via the bus 111. And supply them to the CPU 112, memory 113, video decoder 116, audio decoder 117, etc.
  • the input interface 115 receives a signal supplied by a user operating a key (button) not shown or a remote control (remote controller), and transmits the signal via the bus 111 to the CPU 112. Supply to.
  • the input interface 115 also functions as a communication interface such as a modem (including an ADSL (Asymmetric Digital Subscriber Line) modem) and a NIC (Network Interface Card).
  • a modem including an ADSL (Asymmetric Digital Subscriber Line) modem
  • NIC Network Interface Card
  • the video decoder 116 reads out the disk 101 from the disk 101 by the disk drive 102, and supplies the encoded data (code) of the video data supplied through the drive-in interface 114 and the bus 111.
  • the decoded video data is supplied to the CPU 112 and the video output interface 118 via the path 111.
  • the audio decoder 117 reads the encoded data of the audio data (encoded audio data) read from the disk 101 by the disk drive 102 and supplied via the drive interface 114 and the bus 111. Data) and decode the resulting audio data over the bus 1 1 1 to the CPU 112 and audio Interface 1 1 9
  • the video output interface 1118 performs necessary processing on video data supplied via the bus 111, and outputs the processed video data from the video output terminal 120.
  • the audio output interface 119 performs necessary processing on audio data supplied via the bus 111, and outputs the processed audio data from the audio output terminal 121.
  • the video output terminal 120 is connected to a video output device such as a CRT (Cathode Ray Tube) or a liquid crystal panel (not shown). Therefore, the video output output from the video output terminal 120 is It is supplied to the video output device and displayed.
  • the audio output terminal 121 is connected to an audio output device such as a speaker or an amplifier (not shown). Therefore, the audio data output from the audio output terminal 121 is supplied to the audio output device. Output.
  • the supply of the video data and the audio data from the disk device to the video output device and the audio output device can be performed either by wire or wirelessly.
  • FIGS. 2A and 2B show a configuration example of a software module group executed by the CPU 112 of FIG.
  • the software modules executed by the CPU 112 are broadly divided into an operating system (OS) 201 and a video content reproduction program 210 as an application program.
  • OS operating system
  • video content reproduction program 210 video content reproduction program
  • the operating system 201 starts first when the disk device is powered on (the CPU 112 executes the operating system 201), performs necessary processing such as initial settings, and performs application processing.
  • the video content playback program 210 is called.
  • the operating system 201 provides the video content playback program 210 with an infrastructure (infrastructural) service such as reading a file. That is, for example, with respect to reading of a file, the operating system 201 responds to a request to read a file from the video content reproduction program 210 via the drive interface 114 via the drive interface 114. Operate 2 to read the data on the disc 101 and provide a service to pass it to the video content playback program 210.
  • the operating system 201 also interprets the file system.
  • the operating system 201 has a multi-task processing function, and can operate a plurality of software modules simultaneously (apparently) in a time-sharing manner. That is, the video content reproduction program 210 is composed of several software modules, but each software module can operate in parallel.
  • Video content playback program 2 1 0 Video content playback program 2 1 0
  • the video content playback program 210 is a script control module 211, a player control module 212, a content data supply module 212, a decode control module 214, a buffer control module 211, and a video decoder. It consists of a control module 2 16, an audio decoder control module 2 17, a subtitle decoder control module 2 18, a graphics processing module 2 19, a video output module 220, and an audio output module 2 21.
  • the video content playback program 210 is software that plays a central role in playing back the disc 101. When 1 is inserted (inserted) into the disk drive 102, it is checked whether the disk 101 is a format disk (described later) on which content is recorded. Further, the video content reproduction program 210 reads and executes a script file, which will be described later, from the disc 101, and reproduces the content recorded on the disc 101 from the disc 101.
  • Required for database database information
  • FIGS. 2A and 2B in principle, solid arrows indicate content data, and dotted arrows indicate control data.
  • the script control module 211 interprets and executes a script program (script) described in a script file recorded on the disc 101.
  • a script program for example, "manipulate the graphics processing module 219 to create and display an image such as a menu”, “display a menu according to a signal from a UI (User Interface) such as a remote control” Operations (eg, moving the cursor on a menu) and "controlling the player control module 211" can be described.
  • UI User Interface
  • the player control module 212 refers to metadata (database information) and the like recorded on the disc 101, and controls the reproduction of the content. That is, the player control module 2 12, for example, stores a PlayListO and a ClipO described later, which are recorded on the disc 101. The analysis is performed, and the content data supply module 212, the decode control module 214, and the buffer control module 215 are controlled in accordance with the analysis result. In addition, the player control module 211 switches the stream to be played back, and controls the stream switching described later, etc., according to an instruction from the script control module 211 or the input interface 115. Further, the player control module 214 acquires the time from the decode control module 214, and performs time display, processing of a mark (Mark O) described later, and the like.
  • a mark Mark O
  • the content data supply module 2 13 can control the content data from the disc 101 based on the control of the player control module 2 12 or based on the amount of data stored in the buffer control module 2 15. It requests the operating system 201 to read the metadata, etc.
  • the metadata and the like read from the disk 101 by the operating system 201 in response to the request from the content supply module 212 are supplied to necessary modules.
  • the data of the content read from the disk 101 by the operating system 201 in response to a request from the content data supply module 212 is supplied to the buffer control module 215.
  • the decode control module 2 14 controls the operation of the video decoder control module 2 16, the audio decoder control module 2 17, and the subtitle decoder control module 2 18 according to the control from the player control module 2 1 2. I do.
  • the decode control module 214 has a built-in clock section 214 A that measures the time, and controls the video decoder. The output of the video data output under the control of the module 216 and the output of data (output data) to be output in synchronization with the video data, that is, here, the control of the audio decoder control module 217 Manages synchronization with audio data output by
  • the buffer control module 215 incorporates a buffer 215 A, which is a part of the storage area of the memory 113 shown in FIG. 1, and the buffer 215 A stores the content data supply module 215. 3 makes a request to the operating system 201 to temporarily store content data read from the disk 101.
  • the buffer control module 215 is stored in the buffer 215A according to the request of the video decoder control module 216, the audio decoder control module 217, or the subtitle decoder control module 218.
  • the data is supplied to the video decoder control module 216, the audio decoder control module 217, or the subtitle decoder control module 218.
  • the buffer control module 215 incorporates a video read function unit 2.33, an audio read function unit 234, and a subtitle read function unit 235 described later with reference to FIG. Then, the buffer control module 215 processes the data stored in the buffer 215 A by processing the data request from the video decoder control module 216 in the video read function section 233. The video decoder control module 216 is supplied. Similarly, the buffer control module 2 15 processes the data request from the audio decoder control module 2 17 in the audio read function section 2 The data stored in 215A is supplied to the audio decoder control module 217, and the data request from the subtitle decoder control module 218 is processed by the subtitle reading function unit 235. Then, the data stored in the buffer 215A is supplied to the subtitle decoder control module 218.
  • the video decoder control module 2 16 operates the video read function section 2 3 3 (FIG. 3) in the buffer control module 2 15 to convert the video data encoded data (video encoded data) into a video codec.
  • the data is read from the buffer 215 A of the buffer control module 215 in units of access units and supplied to the video decoder 116 shown in FIG.
  • the video decoder control module 216 controls the video decoder 116 to decode data in video access unit units. Further, the video decoder control module 216 supplies video data obtained as a result of decoding by the video decoder 116 to the graphics processing module 219.
  • the video access unit is, for example, one picture (one frame or one field) of video data.
  • the audio decoder control module 217 operates the audio readout function section 234 (FIG. 3) in the buffer control module 215 to transfer data (audio coded data) obtained by encoding audio data.
  • the data is read from the buffer 215A of the buffer control module 215 in units of audio access units, and supplied to the audio decoder 117 shown in FIG.
  • the audio decoder control module 211 controls the audio decoder 117, and the audio access unit. Decode the data in units of data. Further, the audio decoder control module 217 supplies audio data obtained as a result of decoding by the audio decoder 117 to the audio output module 221.
  • the audio access unit is a predetermined amount of audio data (for example, an amount that is output in synchronization with one picture).
  • the audio access unit has a known fixed length, for example.
  • the caption decoder control module 218 operates the caption reading function unit 235 (FIG. 3) in the buffer control module 215 to convert the data (caption coded data) obtained by encoding the caption data into Data is read from the buffer 215 A of the buffer control module 215 in units of subtitle access units. Further, the subtitle decoder control module 218 includes therein subtitle decoding software (not shown), and decodes data read from the buffer 215A. Further, the caption decoder control module 218 supplies the caption data (caption image data) obtained as a result of the decoding to the graphics processing module 219.
  • the subtitle access unit is a predetermined amount of subtitle data (for example, an amount output in synchronization with one picture).
  • the size of the subtitle access unit is described, for example, at the top of the subtitle access unit.
  • the graphics processing module 219 enlarges or reduces the caption data from the caption decoder control module 218 in accordance with the control (instruction) of the player control module 221 and controls the video decoder control module. Adds (overlays) with the video data from file 2 16. Further, the graphics processing module 219 determines the size (frame) of the video after addition with the caption data on the display screen of the video output device connected to the video output terminal 120 in FIG. The video data is enlarged or reduced in order to meet the requirement, and the resulting video data is output to the video output module 220.
  • the graphics processing module 219 generates a menu, a message, and the like according to an instruction (control) of the script control module 211 or the player control module 211, and overlays the output video data.
  • the graphics processing module 219 controls the aspect ratio of the video output device connected to the video output terminal 120 of FIG. 1 and the output ratio of the video data recorded on the disk 101.
  • the aspect ratio of the video data to be output to the video output module 220 is converted based on the information indicating the aspect ratio.
  • the processing module 219 squeezes (reduces) the video data output to the video output module 2.20 in the horizontal direction (horizontal direction), and outputs the image with blackness on the left and right sides. Also, for example, when the aspect ratio of the video output device is 4: 3 and the information indicating the aspect ratio of the video data indicates an aspect ratio of 16: 9, the graphics processing module The 219 squeezes (reduces) the video data to be output to the video output module 220 in the vertical direction (vertical direction), and outputs the image with blackness at the top and bottom.
  • the graphics processing module The 219 outputs the video data output to the video output module 220 without any squeezing processing.
  • the graphics processing module 219 captures video data currently being processed, for example, in response to a request from the player control module 221. Further, the graphics processing module 211 stores the captured video data or supplies the captured video data to the player control module 212.
  • Video output module 220
  • the video output module 220 exclusively occupies a part of the memory 113 shown in FIG. 1 and is used as a FIFO (First In First Out) 220 A (buffer) Then, the video data from the graphics processing module 219 is temporarily stored, and the video data stored in the FIF220A is read out as appropriate, and the video data is output to the video output terminal 120 (FIG. 1). Output.
  • FIFO First In First Out
  • the audio output module 2 21 exclusively occupies a part of the memory 1 13 in FIG. 1 and is used as FIF0 2 1 A (buffer), and the audio decoder control module 2 1 7 (audio decoder 1 1 7) Temporarily store the audio data from, read out the audio data stored in the FIF022A as appropriate, and output it to the audio output terminal 122 (Fig. 1).
  • the audio output module 221 outputs the audio data from the audio decoder control module 217 as audio data of the “main audio” on the left channel and audio of the “sub audio” on the right channel. If the data is dual (Nike) mode audio data, the audio data from the audio decoder control module 217 is transferred to the audio output terminals 121 according to the audio output mode specified in advance. Output.
  • the audio output module 221 when “main audio” is specified as the audio output mode, the audio output module 221 outputs the left channel audio data of the audio data from the audio decoder control module 217. Copy the audio data of the right channel and output the audio data of the left and right channels (“main audio” audio data) to the audio output terminal 121.
  • “sub-audio” is specified as the audio output mode
  • the audio output module 221 outputs the audio data of the right channel of the audio data from the audio decoder control module 217.
  • the evening is copied as the left channel audio data, and the left channel and right channel audio data (“sub audio” audio data) are output to the audio output terminals 12 1.
  • “primary / secondary” is specified as the audio output mode
  • the audio output module 22 1 outputs the audio data from the audio decoder control module 2 17 directly to the audio output terminal 1 2 Output to 1.
  • the audio output module 221 will operate the audio decoder irrespective of the audio output mode specification.
  • the audio data from the control module 217 is directly output to the audio output terminal 121.
  • the designation of the audio output mode is, for example, video content playback On a screen or the like on which a menu generated by the program 210 is displayed, the user can interactively perform the operation by operating a remote controller or the like.
  • FIG. 3 shows a configuration example of the buffer control module 215 of FIGS. 2A and 2B.
  • the buffer control module 215 exclusively uses a part of the memory 113 shown in FIG. 1 as the buffer 215A, and the buffer 215A is read from the disk 101. Data is temporarily stored. Also, the buffer control module 215 reads out the data stored in the buffer 215A, and reads the video decoder control module 216 and the audio decoder control module 216 shown in FIGS. 2A and 2B. 17 or supply to subtitle decoder control module 2 18
  • the buffer control module 2 15 has a data head pointer storage section 2 31 1 and a data write pointer storage section 2 32 which are a part of the memory 113 in addition to the buffer 2 15 A, and has an internal As a module, it has a video readout function section 233, an audio readout function section 234, and a subtitle readout function section 235.
  • the buffer 215A is, for example, a ring buffer.
  • the buffer 215A sequentially stores data read from the disk 101, and after storing data of the storage capacity, overwrites the oldest data. the latest data, continue to store so to speak, in an infinite loop d
  • the data heading storage unit 231 stores the position where the oldest data that has not been read from the buffer 215A yet is stored among the data stored in the buffer 215A ( Stores the data head pointer that points to (address).
  • the data write pointer storage section 232 stores a write pointer indicating the position (address) of the buffer 215A to which the latest data read from the disk 101 is written.
  • the position pointed to by the data write pointer is updated clockwise (clockwise) in the figure each time data read from the disk 101 is stored in the buffer 215A.
  • the position pointed to by the data head pointer is updated clockwise in the figure according to the reading of data from the buffer 215A. Therefore, of the data stored in the buffer 215A, the effective data is the data stored from the position indicated by the data start pointer to the position indicated by the data write pointer clockwise. is there.
  • the video read function unit 233 sends a video stream (elementary stream related to video data) from the buffer 215A. ) Is read and supplied to the video decoder control module 216.
  • the audio reading function section 234 also outputs an audio stream (elements relating to audio data) from the buffer 215A. Restream) and supplies it to the audio decoder control module 217.
  • the subtitle reading function unit 235 also transmits a subtitle stream (elements relating to subtitle data) from the buffer 215A in response to a request from the subtitle decoder control module 218 in FIGS. 2A and 2B. Restream) and supplies it to the subtitle decoder control module 218.
  • a subtitle stream (elements relating to subtitle data) from the buffer 215A in response to a request from the subtitle decoder control module 218 in FIGS. 2A and 2B. Restream) and supplies it to the subtitle decoder control module 218.
  • the optical disc 101 includes, for example, a program stream (MPEG2-System System) compliant with the MPEG (Moving Picture Elements Group) 2 standard.
  • Program Stream is recorded, and the buffer 215 A stores the program stream read from the optical disc 101.
  • one or more elementary streams such as a video stream, an audio stream, and a subtitle stream are time-division multiplexed.
  • the video read function unit 233 has a function of demultiplexing the program stream, and separates and reads the video stream from the program stream stored in the buffer 215A.
  • 34 also has a function of demultiplexing the program stream, and separates and reads the audio stream from the program stream stored in the buffer 215A.
  • the subtitle reading function unit 235 also has a function of demultiplexing the program stream, and separates and reads the subtitle stream from the program stream stored in the buffer 215A.
  • the video readout function unit 23 has a video readout storage unit 241, a stream id register 242, and an au informationO register 243, which are part of the memory 113 in FIG. ing.
  • the video read pointer storage unit 241 stores a video read pointer that points to the position (address) of the buffer 215A where the video stream is stored.
  • the video read function unit 233 stores the video read pointer of the buffer 215A.
  • the data stored at the position pointed to by the read-in button is read out as a video stream.
  • the stream-id register 242 analyzes the program stream stored in the buffer 215A, and stores a stream-id described later for identifying (specifying) a video stream to be read from the program stream. . au_inf ormaUon 0 Register 243 reads the video stream from the buffer 2 15A Au-1 informationO, which is data (used for reading a video stream) necessary for the operation, is stored.
  • the audio read function unit 234 has an audio read pointer storage unit 251, a stream_id register 252, and a private stream_id register 253, which are part of the memory 113 in FIG.
  • the audio read-in storage unit 251 stores an audio read-out pointer pointing to the position (address) of the buffer 215A where the audio stream is stored, and the audio read-out function unit 234 stores the buffer 215A.
  • the data stored at the position indicated by the audio read pointer is read as an audio stream.
  • stream_id register 2 52 and private___stream_id register 2 53 analyze the program stream stored in buffer 2 15 A and identify the audio stream to be read from the program stream as described below.
  • the subtitle reading function part 2 35 is a subtitle output function that is a part of the memory 113 of FIG. Flag storage unit 26 1, Subtitle readout storage unit
  • the subtitle read function flag storage unit 261 stores a subtitle read function flag. If the subtitle read function flag stored in the subtitle read function flag storage unit 1 is, for example, 0, the subtitle read function unit 2
  • the subtitle read function unit 235 functions.
  • the subtitle read pointer storage unit 26 2 is a subtitle read point that points to the position (address) of the buffer 2 15 A where the subtitle stream is stored.
  • the subtitle reading function unit 235 reads out the data stored in the position of the caption read-in button in the buffer 21A as a subtitle stream.
  • the stream-id register 2 63 and the private_stream-id register 264 analyze the program stream stored in the buffer 215 A, and provide a stream_id and a stream_id described later for identifying a subtitle stream to be read from the program stream. private_stream_id is stored respectively.
  • FIG. 4 schematically shows the directory structure of the disc 101.
  • the file system of the disk 101 is specified by, for example, IS0 (International Organization for Standardization)-9660, UDF (Universa 1 Disk Format: http://www.osta.org/specs/), etc.
  • a file system is used, and the files recorded on the disk 101 are managed hierarchically by a directory structure.
  • the file system is not limited to the file system described above.
  • the “VIDEO” directory is located in the root directory indicating the base of the file system, and the “VIDEO” directory has two directories, a “CLIP” directory and a “STREAM” directory. Is placed.
  • the "VIDEO" directory contains two directories, a "CLIP” directory and a "STREAM” directory, a "SCRIPT.DAT” file, There are two data files, LAYLIST.DAT "file.
  • the "SCRIPT.DAT” file is a script file that describes the script program. That is, the "SCRIPT.DAT” file describes a script program used to make the playback mode of the disc 101 inactive.
  • the script program described in the “SCRIPT. DAT” file is interpreted and executed by the script control module 211 shown in FIGS. 2A and 2B.
  • the “PLAYLIST.DAT” file stores one or more playlists (PlayListO in FIG. 5, which will be described later) in which a procedure for reproducing content such as video data recorded on the disc 101 is described.
  • One or more clip information files are stored in the "CLIP” directory, and one or more clip stream files are stored in the "STREAM” directory. That is, in FIG. 4, three clip information files “00001.CLP”, “00002. CLP”, and “00003.CLP” are placed in the “CLIP” directory, and the “STREAM” directory contains Three clip stream files “00001.PS”, “00002.PS”, and “00003.PS” are placed.
  • a clip stream file is a time-multiplexed program of one or more elementary streams obtained by compressing and encoding one or more data (streams) such as video data, audio data, and subtitle data.
  • the stream is stored.
  • the clip information file describes (file) metadata relating to the clip stream, such as the properties of the corresponding clip stream file.
  • the clip stream file and the clip information file have a one-to-one correspondence.
  • the clip stream file is named according to the naming convention of 5 characters + period + "PS".
  • the file name is given, and the file name is given to the clip information file according to the same naming rule of 5 characters + period + "CLP" as the corresponding clip stream file.
  • a file is a clip stream file or a clip information file can be identified by the file name extension (the part to the right of the period), and furthermore, the corresponding clip stream file And the clip information file can be identified based on whether the part other than the file name extension (the part on the left side of the period) matches.
  • FIG. 5 shows the internal structure (syntax) of the “PLAYLIST.DAT” file under the “VIDEO” directory in FIG.
  • the description in the “Syntax” column indicates the data structure
  • the description in the “No: of bits” column indicates the data bit length in the “Syntax” column of the corresponding line.
  • “bslbf” (bit string left bit first) in the description of the "Mnemonic” column means that the data of the "Syntax” column of the corresponding line is sent from the left bit
  • "uimsbf" (unsigned integer most significant bit first) means that the data in the "Syntax” column of the corresponding line is an unsigned integer value and is sent out from the most significant bit.
  • name_length 8 bits
  • name.string 255 bytes
  • name-length indicates the size of the name-string that is arranged thereafter, in bytes.
  • name-string represents the name (file name) of the "PLAYLIST. DAT" file.
  • name_length up to the number of bytes represented by name_length from the beginning are used as valid names. For example, if the value of name_length is 10, the first 10 bytes of name_string are interpreted as a valid name.
  • the name—string is followed by the number—of—PyLists (16 bits).
  • number—of—PlayLists represents the number of subsequent PlayLists 0. After PlayLists, PlayLists of the number_of_PlayLists are arranged.
  • PyListO is a playlist in which the playback procedure of the clip stream file recorded on the disc 101 is described, and has the following internal structure.
  • PlayLis data_length (32 bits) is arranged at the head of PlayListO.
  • PlayList_data_length represents the size of PlayList 0.
  • PlayList-data length After one PlayList-data length, + reserved_for_ord_alignment (15 bits) and capture-enable-flag-PlayList (1 bit) are arranged in order.
  • the 15-bit reservedJor_word_alignment is located at the position of the 1-bit capture_enable_nag_PlayList that is placed after that, to take a so-called single door line (word alignment) (to align it to the 16-bit position).
  • capture_enable—flag_PlayList is the secondary use of the video data (video data belonging to P1 ayLis) corresponding to the video stream played by PlayList 0 on the optical disc 101 in the disc device of FIG. 1 bit to indicate whether to allow Flag.
  • capture_enable_flag_PlayList is one of 0 or 1, for example 1, it indicates that secondary use of video data belonging to PlayListO is permitted, and capture— enable—flag-PlayList is 0 or 1. For example, if it is 0, it indicates that the secondary use of the video data belonging to PlayListO is not permitted (prohibited).
  • capture_enable_flag_JlayList is 1 bit, but capture_enable_flag_PlayList is composed of multiple bits, so that secondary use of video data belonging to PlayListO is allowed in a stepwise manner. Is possible. That is, capture_enable_flag_PlayList can be composed of, for example, 2 bits. If the value of capture_enable-ag-PlayList is 00B (B indicates that the preceding digit is a binary number), the secondary use of video data is prohibited, and the value of capture_enable_nag_PlayList is 01B. In the case of, it is possible to permit the secondary use of using the video data reduced to a size of 64 ⁇ 64 pixels or less. If the value of capture-enable-flag-PlayList is 1 OB, secondary use of video data can be permitted without any size restriction.
  • the size of the video data instead of limiting the size.
  • the value of capture_enable-ag_PlayList is 01B
  • the value of capture_enable_flag_PlayList is In the case of 10B
  • the data in Fig. 1 Applications other than the video content reproduction application 210 in the screen device include, for example, an application for processing display of a wallpaper background) / screen saver. If capture-enable-flag-PlayList is 2 bits as described above, reserved_for_word_alignment placed before it is 14 bits to take a word line.
  • the capture_enable flag_PlayList can be used to permit secondary use of the video data in the disc device and also to allow secondary use outside the disc device.
  • the video data can be attached / detached to, for example, a recording medium that can be attached / detached to the disk device or another device that can be connected to the disk device. It is recorded on a simple recording medium or transmitted (distributed) to another device via a network such as the Internet. In this case, information limiting the number of times the video data is recorded on the recording medium and the number of times the video data is distributed can be added to the video data.
  • PlayList_name_l ength 8 bits
  • PlayList one name—string (255 bytes) Is performed.
  • PlayLis name-length represents the size of the PlayLis name_string to be arranged thereafter in bytes
  • PlayList_name_string represents the name of PlayList ().
  • PlayList name—string is followed by number_of_Play I terns (16 bits). 11111111) 6 then 0? 13 1161113 represents the number of subsequent P 1 ay 11 em 0.
  • a unique ID (Identification) in the PlayList 0 is assigned to each of the PlayLists () in the PlayList 0 as many as the number_of-Playltems. That is, the first PlayltemO in PlayList 0 is numbered 0 as an ID, and subsequent PlayltemOs are sequentially numbered 1, 2, and so on in the order of appearance.
  • PlayListMarkO is a set of MarkO to be described later, which is a mark on the time axis of the reproduction performed according to PlayList 0, and the details thereof will be described later with reference to FIG.
  • FIG. 6 shows an internal structure of PlayltemO included in PlayListO of FIG.
  • length (16 bits) is arranged, and length represents the size of PlayltemO including it.
  • Clip—Information—file—name—length (16 bits) and Clip_Information__nie-name (variable length) are arranged in order.
  • CI ip_Information_ file_name is the clip information file (the file with the extension CLP in Fig. 4) corresponding to the clip stream file (the file with the extension PS in Fig. 4) to be played by Playtem () File name. Note that the file name of the clip information file to be played by PlayltemO is changed from the Clip- It can recognize and specify the clip stream file.
  • IN-time and OUT-time are time information for specifying the playback start position and playback end position of the clip stream file specified by CI ip—Information—file—name, respectively.
  • a position in the middle of the clip stream file (including the beginning) can be specified as the playback start position.
  • a position in the middle of the clip stream file (including the end) can be played back. Can be specified as a location.
  • PlayltemO the content from IN_time to 0UT_time of the clip stream file specified by Clip-Information-file-name is played.
  • the content reproduced by PlayltemO is referred to as a clip as appropriate.
  • FIG. 7 shows an internal structure of PlayListMarkO included in PlayListO of FIG.
  • PlayListMarkO is a set of zero or more MarkOs that serve as marks on the time axis of playback performed according to P1ayListO (FIG. 5) including PlayListMarkO.
  • One MarkO represents time information indicating one time (position) on the time axis of playback performed according to PlayList 0, type information indicating the type of MarkO, and type information indicating the type in which the event generates an event. At least, it has the argument information which becomes the argument of the event when
  • length (32 bits) is placed at the head of PlayListMarkO.
  • length indicates the size of PlayListMarkO that includes it.
  • number_o and PlayLis and marks (16 bits) are placed, and 1111110) 6 and 0? 1 & 1 ⁇ 3 then 11 ⁇ 3 indicates the number of Mark 0s placed subsequently.
  • number_o and PlayListjnarks MarkO structures are described by the number of that number-o and P1 ayListjnarks.
  • MarkO type (8 bits) is placed at the head of MarkO.
  • mark_type is the above-mentioned type information, and represents the type of MarkO including it.
  • three types of MarkO, such as a chapter, an index, and an event are prepared.
  • MarkO of the type “caption” is a mark of the head position of the caption, which is the unit of cueing that divides PlayListO.
  • MarkO of type index (hereinafter referred to as an index mark as appropriate) is a mark of the start position of the index, which is a unit that subdivides the chapter.
  • MarkO of the event type (hereinafter referred to as an event mark as appropriate) is a mark of a position at which an event is generated during reproduction of content according to PlayListO. The occurrence of the event due to the event mark is notified to the script control module 211 as described later.
  • mark_type 1 is set to the mark_type of the caption mark.
  • 2 is set to mark1 type of the index mark, and .3 is set to mark_type of the event mark.
  • mark_type 0 and 4 to 255 of the 8-bit value represented by mark_type are reserved for future extension.
  • mark_type is followed by mark—name—length (8 bits).
  • mark-name is used to describe the name of MarkO
  • mark—name—length is the valid size of mark—name—string
  • mark—name_string is Indicates the name of MarkO, respectively. Therefore, the effective name of MarkO is from the head of mark-name-string to the number of bytes indicated by mark-name-length.
  • mark_name-length Following mark_name-length, four elements that associate MarkO defined on PlayList 0 with the clip stream file ref_to-PlayItem-id (16 doodles), mark-time-stamp (32 bits, entry—ES—stream one id (8 bits), entry_ES—private—stream—id (8 bits) are arranged sequentially.
  • Re-to-Playltem-id an ID assigned with a serial number to PlayltemO to which MarkO belongs is described.
  • Ref—to—Playltemjd specifies the PlayltemO (FIG. 6) to which Mark 0 belongs, and, as described in FIG. 6, specifies the clip information file and the clip stream file.
  • mark—time—stamp represents the position (time) represented by MarkO in the clip stream file specified by “re-play—Playltem_id”.
  • FIG. 9 shows the relationship between PlayList 0, PlayltemO, clips, and program streams stored in the clip stream file.
  • PlayListO is composed of three PlayltemOs, and each of the three PlayltemOs is assigned ID # 0, # 1, # 2 assigned with a serial number.
  • Playltem 0 to which ID # i is assigned as appropriate will be referred to as Playltem # i.
  • the clips played by PlayItem # 0, Playltem # l, and 'Playltem are clip A and clip A, respectively. Shown as Lip B, Clip C.
  • the entity of the clip is specified by Clip—Information—file_name in PlayltemO in Fig. 6 (further specified from the clip information file) Of the program stream stored in the clip stream file, from IN_time to 0UT_time Is the program stream.
  • Clip—Information—file_name in PlayltemO in Fig. 6 further specified from the clip information file
  • the program streams as the entities of clip A, clip B, and clip C are shown as program stream A, program stream B, and program stream C, respectively.
  • the ref_to_PlayItem_id describes 1 which is the ID of the Playltem # l. Furthermore, at time tO, since Playltem # l plays the program stream B, which is the substance of clip B, mark_time_s immediately indicates the time corresponding to time tO in the clip stream file in which program stream B is stored. Is described.
  • en.try_ES stream_id and entry_ES—private—stream—id are used to identify the elementary stream when MarkO is associated with a specific elementary stream. Is done. That is, the entry-ES-stream_id is provided with an element list stream (to which MarkO is associated), which will be described later with reference to FIGS. 16A and 16B to 18A and 18B. Stream-id of PES_packetO) shown below is described. In addition, element entry stream (associated with MarkO) is placed in entry-ES-private-stream-id if necessary. Private_stream_id described later of Private-header 0) in private-streaml_PES-payload () shown in FIG. 21 described later is described.
  • stream_id of the video stream # 1 and the private stream-1 id in the entry_ES_stream_id and entry_ES_private-str earn-id of MarkO at the time of occurrence of the chapter mark when playing video stream # 1.
  • stream_id and private stream_id of video stream # 2 are described in en try—ES—stream—id and en try—ES—private—stream—id of Mark 0 at the time of occurrence of a chapter mark during playback of video stream # 2. Is done.
  • entry-ES_stream-id and entry-ES_private_stream-id of MarkO that is not associated with a specific elementary stream.
  • mark—data (32 pits) is placed after entry—ES_private_stream—id.
  • mark_data is argument information that is an argument of an event generated by the event mark when MarkO is an event mark. If MarkO is a caption index mark, mark-data can be used as the number of the caption index indicated by the caption index mark.
  • FIG. 10 shows the internal structure of such a clip information file ClipO.
  • presentation star
  • timing and presentation__end_time (both 32 bits) are arranged sequentially.
  • reserved—for—word—a 1 ignment (7 bits) and capture—enable—flag—Clip (1 bit) are arranged in order.
  • 7-bit reserved—for_word—alignment is for taking a word line
  • capture—enable_flag—Clip is secondary use of video data, like capture_enable—flag_PlayList in FIG. 5 described above. This flag indicates whether or not to permit.
  • capture—enable_flag—PlayList in FIG. 5 indicates whether secondary use of video data (video data belonging to PlayList 0) corresponding to the video stream reproduced by PlayListO is permitted or not.
  • capture-enable-flag_Clip in FIG. 10 is a video corresponding to the video stream (video elementary stream) stored in the clip stream file corresponding to the clip information file ClipO. Indicates whether to allow secondary use overnight. Therefore, the capture enable flag PlayList in FIG. 5 and the capture—enable flag Clip in FIG. The units (ranges) of video data permitted for secondary use differ between and.
  • the capture-enable-flag-CI ip in FIG. 10 can also be a plurality of bits instead of one bit, as described in capture-enable-flag_PlayList in FIG.
  • number—of—streams (8 bits) are placed.
  • this number_o streams the number of Streamlnf o () structures that follow is described. Therefore, following number-10 and streams, the length (16 bits) is placed at the beginning of StreamlnfoO where the structure of Streamlnfo 0 is described by the number of Streams that is number_o and Streams, and this length is Represents the size of StreamlnfoO including.
  • a stream_id (8 bits) and a private_stream_id (8 bits) are arranged, and the elementary stream to be associated with the Streamlnfo 0 is specified (identified) by the stream-id and the private-stream-id. .
  • FIG. 11 shows the relationship between streamjd for identifying the elementary stream and private_stream_id, and the elementary stream.
  • the stream_id is the same as that specified in the MPEG2-System standard, and its value is predetermined in the MPEG2-System standard for each attribute (type) of elementary stream (data). I have. Therefore, an elementary stream having the attribute defined by the MPEG2-System standard can be specified only by the stream_id.
  • Fig. 11 shows an elementary stream of video encoded in the encoding (decoding) method specified by MPEG and an elementary stream of audio encoded in ATRAC (Adaptive TRans form Acoustic Coding).
  • ATRAC audio stream an elementary stream of audio encoded in ATRAC (Adaptive TRans form Acoustic Coding).
  • Stream hereinafter referred to as “ATRAC audio stream” as appropriate
  • LPCM audio stream Linear Pulse Code Modulation
  • LPCM audio stream subtitle elementary stream
  • the relationship between stream-id and private_stream_id is shown for an elementary stream having four attributes of “subtitle stream” as appropriate.
  • an elementary stream of a video encoded by the encoding method specified by MPEG has a value in the range of OxEO to OxEF (Ox is a hexadecimal number of a character string that follows. Multiplexing using the stream_id for identifying the elementary stream. Therefore, for an elementary stream of video encoded by the encoding method specified by MPEG, 16 video elements that can be identified by a stream-id having a value in the range of OxE0 to OxEF. The mental stream can be multiplexed into the program stream.
  • the elementary stream of a video encoded by the encoding method specified by MPEG can be identified by a stream_id of a value in the range of OxEO to OxEF. Is unnecessary (can be ignored). .
  • stream-id is not defined for ATRAC audio streams, LPCM audio streams, and subtitle streams.
  • the stream-id is defined in the MPEG2-System.
  • OxBD which is a value indicating the attribute private—stream_l in the MPE G2-System
  • the private stream_id is used as shown in Fig. 11. Identification (specification).
  • a private_stream-id having a value in the range of 0x00 to OxOF is used for identification of the ATRAC audio stream. Therefore, 16 ATRAC audio streams can be multiplexed into the program stream.
  • a value private-stream-id in the range from 0x10 to OxlF is used for identification of the LPCM audio stream. Therefore, 16 LPCM audio streams can be multiplexed in the program stream.
  • private_streain_Jd with a value in the range of 0x80 to 0x9F is used to identify the subtitle stream. Therefore, 32 subtitle streams can be multiplexed in the program stream.
  • Staticlnfo 0, reserved-for-word-alignment (8 bits).
  • Staticlnf ⁇ describes information that does not change during playback of the elementary stream specified by the stream_id and private-stream_id (described in the StreamlnfoO including the StaticInfoO). The details of StaticInfoO will be described later with reference to FIG.
  • the reserved—for or word—alignment is used to take the first door line.
  • pts_change—point represents the time at which the Dynamiclnfo 0 information set with it becomes valid.
  • pts_change_point which represents the time at the beginning of the elementary stream, is equal to presentation_star time described first in the clip information file ClipO corresponding to the clip stream file in which the elementary stream is stored.
  • EPjnap 0 is placed. Note that EPjnapO will be described later with reference to FIG.
  • Fig. 12 shows the syntax of StaticInfoO.
  • the contents of StaticInfoO differ depending on the attribute (type) of the corresponding elementary stream.
  • the attribute of the elementary stream corresponding to the StaticInfoO is determined by the streamId and private streamId included in the StreamlnfoO of Fig. 10 including the StaticInfoO.
  • Staticlnfo 0 is picture—size (4 bits), frame_rate (4 bits), and cc—flag (1 Bit) and reserved reserved-for-d-ali-entry to take one door line.
  • picture_size represents the size of (the image displayed by) the video data corresponding to the video stream.
  • frame_rate represents the frame frequency of video data corresponding to the video stream.
  • cc_flag indicates whether or not the video stream includes closed caption data. That is, for example, when the video stream includes closed caption data, cc_flag is set to 1, and when the video stream does not include closed caption data, cc_flag is set to 0.
  • Staticlnfo 0 is audio_language—code (16 bits), channel—configuration (8 bits), lfe— It consists of existence (1 bit), samp 1 ing one frequency (4 bits), and reserved—foreword—alingment for taking the door line.
  • audio_language_code describes a code indicating the language of the audio data contained in the audio stream.
  • Channel and configuration indicate the attributes of the audio data included in the audio stream, such as monaural (mono) / stereo '(stereo) / multi-channel.
  • lfe_existence indicates whether the audio stream contains a low-frequency emphasis channel, and is 1 if it is included and 0 if it is not.
  • the sampling frequency is This is information indicating the sampling frequency of the included audio data.
  • Staticlnfo 0 is used to obtain a word line with subtitle_language_code (16 bits) and configurable—flag (1 bit).
  • a subtitle_language code composed of reserved—for one word—alingment describes a code representing the language of the subtitle data included in the subtitle stream.
  • configurable_flag is information indicating whether the display of subtitle data included in the subtitle stream is permitted to be changed from the default display method.For example, when the display method is permitted to be changed, Is described as 1. If not permitted, 0 is described.
  • the display method of the caption data includes the display size of the caption data, the display position, the display color, the display pattern (for example, blinking display), the display direction (for example, vertical and horizontal directions), and the like.
  • FIG. 13 shows the syntax of DynamicInfoO.
  • DynamicInfoO reserved_for one word-alignment (8 bits) for a word line is arranged, and the content of subsequent elements differs depending on the attribute of the elementary stream corresponding to DynamicInfoO.
  • the attribute of the element list list corresponding to the DynamicInfoO is the stream_id included in the StreamlnfoO of FIG. 10 including the DynamicInfoO. And private_stream_id.
  • DynamicInfoO describes dynamic information that changes during playback of the elementary stream.
  • this dynamic information is not particularly limited, in the embodiment of FIG. 13, data corresponding to the elementary stream corresponding to DynamicInfoO, that is, the elementary stream is processed.
  • the output attribute of the data output by (the attribute of the data obtained from the elementary stream) is described in DynamicInfoO.
  • Dynamiclnfo 0 is expressed as display-aspect-ratio (4-bit) and word-line. It consists of reserve d—for—word—al ingment.
  • diplay—aspect—rat io describes, for example, the aspect ratio of the video data as an output attribute (display method) of the video data corresponding to the video stream. That is, in the diplay_aspec ratio, for example, information indicating whether the aspect ratio is 16: 9 or 4: 3 is described. It should be noted that, in addition to the aspect ratio, for example, the size of the image displayed by the video data (X pixels and XY pixels) can be described in DynamicInfoO of the video stream.
  • Dynamiclnfo 0 uses channel—as signment (4 bits) and reserved—for—word—al ingment for taking a word line. It is composed of In the channel-assignment, when the audio stream includes audio data of two channels, the output attribute (output method) of the two channels is described. That is, the channel assignment contains audio data in stereo or dual Information indicating which channel is assigned to (Nike language) is described.
  • Dynamiclnfo 0 is composed of reserved one for one word one alingment for obtaining a word alignment. That is, in the embodiment of FIG. 13, the output attribute as dynamic information is not defined for the subtitle stream.
  • Fig. 14 shows the syntax of EPjnapO.
  • EPjnapO contains, for each elementary stream multiplexed with the program stream stored in the clip stream file corresponding to the clip information file ClipO of FIG. 10 including the EP_map 0, of each elementary stream. Information on the point at which decoding can be started (entry point) at which decoding can be started is described.
  • the point at which decoding can be started can be obtained by calculation.
  • each video access access unit For streams of different sizes, the point at which decoding can be started cannot be found by calculation, and cannot be found without actually analyzing the stream.
  • Quickly recognizing the decoding start possible point is important for random access. According to EPjnapO, the decoding start possible point can be quickly recognized.
  • Sequencejieader 0 sequence header
  • the beginning of the intra picture including the above is the point at which decoding can be started.
  • EP_mapO reserved_for_word_alignment (8 bits) for the door line is arranged, followed by number_o and stream_id—entries (8 bits).
  • number_of_s t reara_id_entr ies represents the number of elementary re-streams in which information on decoding startable points is described in EP-mapO.
  • the information for identifying the elementary stream and the information about the decoding start point of the elementary stream are number 0 and streamjd—the number represented by the entries. They are arranged repeatedly.
  • streamjd (8 bits) and private_stream_id (8 bits) as information for identifying the elementary stream are arranged, followed by number_of_EP_entries (32 bits) Is arranged.
  • the number_o and EP_entries indicate the number of possible decoding start points of the elementary stream identified (specified) by the immediately preceding streamjd and private-stream-id.
  • the set with t (32 bits) is repeatedly arranged by the number represented by number_of—EP—entries.
  • PTS-EP—start which is one of the information about the decoding start possible point, is in the clip stream file that stores the program stream in which the elementary stream specified by stream_id and private_stream_id is multiplexed as described above. Represents the time (playback time) at which decoding can be started.
  • RPN_EP_start which is another piece of information on the decoding start possible point, includes a clip stream in which a program stream in which the elementary stream specified by stream_id and private one stream_id is multiplexed as described above is stored. The value when the position of the decoding startable point in the file is counted in packO units of the program stream is described. In this embodiment, it is assumed that the size of packO is fixed at 2048 bytes. In the present embodiment, it is assumed that one section of the disk 101 (FIG. 1) is 2048 bytes.
  • a private-stream 2 packet (PES-packet 0 having a private-stream-12 attribute) described later is arranged immediately before the decoding start point (entry point).
  • the private_stream-2 packet stores information used to decode the video stream located between the private-stream-2 packet and the next private-stream-2 packet.
  • RPN_EP_start as the information about the decoding startable point is not the actual decoding startable point itself, but the private_stream 12 bucket located immediately before the actual decoding startable point. Describes the position of the head of the table.
  • the set of PTS_EP-1 start and RPN_EP_start as decoding start point information is pre-sorted in ascending order for each elementary stream specified by s stream-1 id and private_s tream_ id. I have.
  • the set of? 3_6? -31 & and 1 ⁇ 1 £ 1 ) __51 & 1 ⁇ as the information about the start point of decoding can be binary searched.
  • the clip stream file is configured based on MPEG2_Program_Stream () defined in the MPEG-2 System (ISO / IEC 13818-1). That is, Fig. 15A and Fig. 15B show Table2-31, Table2-32 and Table2-33 described in the MPEG-2 System (ISO / IEC 13818-1: 2000) standard. ing.
  • the program stream stored in the clip stream file is MPEG2-Prograin_StreamOmO defined in Table 2-31 of the MPEG-2 System standard, and is composed of one or more packO and one MPEG-program-end_code. Be composed.
  • MPEG2_Program_Stream () is also described in Japanese Patent No. 2785220 and the like.
  • One packO is composed of one Packjieader () and an arbitrary number of PES_packet 0 as defined in Table 2-32 of the MPEG-2 System standard. Details of Pack—header 0 are defined in Table 2-33 of the MPEG-2 System standard.
  • the size of packO is defined as a variable length, but here, as described in FIG. 14, it is assumed that the size is fixed at 2048 bytes. Further, here, the number of PES-packetO of one pack 0 is one, two, or three.
  • PES-packet When PackO starts with a private-stream-2 packet, which will be described later, there is always a PES-packet 0 of the corresponding video stream immediately after (in the same PackO). Also this In addition to the above, padding_packet (padding packet) can be placed as the third PES_packet (). Privaie_stream_2 packet is always placed at the top of Pack 0.
  • PES-packet 0 containing content data such as video, audio and subtitles is placed at the head of PackO.
  • a padding_packet can be placed as the second PES—packet 0.
  • FIG. 16A and FIG. 16B through FIG. 18A and FIG. 18B show a PES packet 0 defined in Table 2-17 of the MPEG-2 System standard.
  • PES—packet 0 is packet—star t—code ”refix, stream-id, and PES_packet_length (FIG. 16A and FIG. 16B), and the header part (stuffing one byte) whose structure changes according to the stream_id, etc. (Fig. 16A and Fig. 16B to Fig. 18A and Fig. 18B) and PES-packet_data_byte (Fig. 18A and Fig. 18B) Can be different.
  • padding-byte (OxFF) (FIG. 18A and FIG. 18) is used instead of PES-packet-data-byte. ( Figure B) is repeated as many times as necessary.
  • Information indicating display timing called “Presentation Time Stamp” and information indicating decoding timing called DTS (Decoding Time Stamp) can be arranged.
  • a PTS is added to all access units (decoding units constituting an elementary stream defined in MPEG2-System), and MPEG2-System It is assumed that DTS is added when specified in m.
  • the elementary stream multiplexed with the program stream is stored in data_byte (FIG. 18A and FIG. 18B) by PES-packing of PES-packetO.
  • data_byte FIG. 18A and FIG. 18B
  • PES-packing of PES-packetO In the stream_id of the PES_packet (), a value corresponding to the attribute of the elementary stream is described in order to identify the elementary stream stored in the PES_packet_data_byte.
  • the stream-id of the PES-packet 0 of the elementary stream having an attribute called private_stream-11 is set to 10111101B according to FIG.
  • the stream-id of PES_packet 0 of padding_packet is set to 10111110B according to FIG.
  • the stream_id of the PES-packet 0 of the elementary stream having the attribute called “private_stream-12” is set to 10111111B according to FIG.
  • the stream_id of the PES-packet 0 of the audio stream (audio elementary stream) defined by MPEG is set to ⁇ .
  • the stream_id of the PES-packetO of the video stream (video elementary stream) defined by MPEG is set to ⁇ .
  • Video streams (video streams defined by MPEG) can be multiplexed.
  • PES_packet () whose stream id is ⁇ is used to store a video stream defined by MPEG
  • PES-packetO whose streamjd is xxx xxxB stores an audio stream defined by MPEG.
  • the stream-id of the PES-packet0 used to store an elementary stream of a coding method not defined by the MPEG is not specified by the MPEG.
  • the elementary stream of the encoding method not defined in, like the video stream and audio stream defined in MPEG, can simply specify the stream-id and store it in one PES packet0. Can not.
  • the PES_packet () of the private_stream_l is expanded to expand the data-byte to store an elementary stream of an encoding scheme not defined by MPEG.
  • Figure 21 shows the syntax of private-streamed PES_payload ().
  • private_streaml_PES_payload () is composed of private-header 0 and private-payloadO.
  • private_payload 0 stores an elementary stream of an encoding scheme not defined by MPEG, such as an ATRAC audio stream, an LPCM audio stream, and a subtitle stream.
  • private—stream_id (8 bits) is placed at the head of private—header 0.
  • private-stream-id is identification information for identifying an elementary stream stored in private_payload 0, and has the following value, for example, according to its attribute (type).
  • FIG. 22 shows the relationship between the value of private_stream_id and the attribute of the elementary stream stored in private-payload0.
  • three patterns of OOOOxxxxB, OOOlxxxxB, and ⁇ are adopted as private_stream-id values.
  • "x" represents an arbitrary value of 0 or 1, as in the case of FIG.
  • the private-stream-id of the private-streaml-PES-payloadO in which the ATRAC audio stream is stored in private_payload0 is OOOOxxxxB.
  • the LPCM audio stream is private_ private-streaml-one: PES-payloadO ⁇ private_stream-id stored in payloadO id is OOOlxxxxB.
  • the caption stream is stored in private-payloadO private-seaml-PES-payloadO O private_stream_id3 ⁇ 4, ⁇ .
  • a subtitle stream of a book can be multiplexed.
  • FIG. 11 summarizes the relationship between FIG. 20 and FIG.
  • private-streaml-PES-payloadO the content of the element following private-stream_id differs depending on the attribute of the elementary stream stored in private-payload0.
  • the attribute of the elementary stream stored in private_paylod () is determined by the private_stream_id at the head of privatejieader ().
  • AU_locator (16 bits) are allocated.
  • AU The locator is based on the position immediately after the AU_locator, and the audio access unit (ATRAC audio unit) of the ATRAC audio stream stored in private_payload () is used. Indicates the start position of the audio unit. If no audio access unit exists in private_payload (), for example, OxFFFF is described in Allocator.
  • fsjlag indicates the sampling frequency of the LPCM audio stream stored in private-payloadO. That is, for example, when the sampling frequency is 48 KHz, fs_flag is set to 0, and when the sampling frequency is 44. ⁇ , fs_flag is set to 1.
  • ch_flag indicates the number of channels of the LPCM audio stream stored in private-payloadO. For example, when the LPCM audio stream is monaural, ch_flag is set to 1, and when the LPCM audio stream is stereo, ch_flag is set to 2.
  • B Allocator is the reference to the position immediately after the AU-locator, indicating the head position of the O one Dioa access unit of LPCM audio O stream stored in privat E_payload () (LPCM audio access unit) (audio frame) If there is no audio access unit in private_payload (), for example, OxFFFF is described in the AU-locator.
  • reserved_Jor_future_use (8 bits) for future expansion is placed, and then AU — The locator (16 bits) is located.
  • AU—locator is the character stored in private—payloadO based on the position immediately after the AU—locator. Indicates the head position of the subtitle access unit of the curtain stream. If no subtitle access unit exists in private_payloadO, for example, OxFFFF is described in AU_locator.
  • FIG. 23 shows the syntax of private_stream2_PES_j) ay load 0.
  • pr ivate_stream2_PES_pay load 0 is an extension of pr ivate—st ream—2 PESjpacke ")? 83 — & ( ⁇ 6 then (1 & 1 & _ ⁇ 16 (Fig. 18A and Fig. 18B), That is, extended PES_packed data_byte of PES_packet () of private-stream_2 describes information used for decoding a video stream.
  • PES-packet0 of private-stream_2 is arranged immediately before the start point of decoding in the video stream. Therefore, in the present embodiment, if the private_stream-2 PES-packet 0 is found from the program stream, decoding can be started from the video stream immediately after that.
  • RPN-EP_start of EPjnapO in FIG. 14 indicates the head position of PES_packet 0 of private-stream 12 for the video stream.
  • video—stream—id is the same as the PES—packet 0 stream—id of the video stream located immediately after the private—stream—2 PES—packet 0. Value) is described.
  • This video—stream—id identifies the video stream (PES_packet 0 containing the) that is decoded using the information stored in the private—stream—2 PES—packet () (of private_stream2_PES—payloadO). Is done.
  • IstRef—picture, 2ndRef—picture, 3rdRef—picture, 4thRef_picture is the PES of pri vate—stream—2 of the video stream identified by video__stream_id—the packet 0 power, the PES of the next pri vate—stream—2 —
  • the relative position of the last packO including the first, second, third, and fourth reference images up to and including packe tO.
  • the lstRef_picture, 2ndRef_picture, 3rdRe-picture, and 4thRe-picture are described in, for example, Japanese Patent Application Laid-Open No. 09-46712 (Japanese Patent Application No. 07-212420). — The details are disclosed as second_P—pic.
  • au-informationO information about the video access unit in the video stream up to PES_packet 0 of the next private_stream-12 is described. The details of au-informationO will be described later with reference to FIG.
  • VBI0 is used to describe Closed Caption information.
  • the PES-packet 0 of the private_str_eam_2 having 3 ⁇ 4private_stream2_PES_pay load 0 is arranged for each decoding start possible point for each video stream.
  • Fig. 24 shows the syntax of au_information () in Fig. 23. ⁇
  • Length (16 bits) is placed at the head of au_inforniationO. length indicates the size of the au-informationO containing it. Following the length, reserved_f or_ ord_alignment (8 hits j and number—of .access unit (8 bits) are sequentially arranged. reserved for word_al The ignment is used to take the worder line.
  • the number_0 and access_unit represent the number of video access units (pictures) included from the PES-pac ket () of the private_stream_12 containing it to the next PES_packet 0 of the private_stream_2.
  • the number-of-one access-unit is a private-stream-2_PES-payloadO in FIG. 23, in which private-stream-2 PES-packet 0 has the same video-stream-id. informatnio 0 force, before the next au—information 0 (by the end of the clip stream file if this au_infromation () is the last au_information () in the clip stream file), video_stream 1 id Indicates the number of access units (pictures) included in the video stream indicated by.
  • the contents of the for loop are arranged by the number—of—access—unit. That is, information on each of the one or more video access units included between the PES_packet () of the private-stream-12 and the next private-stream-2 including the number_of_access_unit is included. Be placed.
  • the information placed in the for loop (information about the video access unit) is as follows.
  • Pic_struc and copy include IS0 / IEC 14496-10, D.2.2 set for the corresponding video access unit when the video stream is MPEG4-AVC (IS0 / IEC 14 496-10).
  • a copy of the defined pic_struct () is described.
  • Pic_struct () displays the picture as a frame, or displays the top field of the picture, and then displays the bottom field. Information.
  • au re fl ag indicates whether or not the corresponding access unit is a reference image that is referred to when decoding another access unit (picture of), and is set to 1 when the corresponding access unit is a reference image, If it is not a reference image, it is set to 0.
  • AU_length indicates the size of the corresponding access unit in bytes.
  • FIGS. 25 to 28 show specific examples of data in the format described above, which is recorded on the disc 101 of FIG.
  • MPEG2-Video is adopted as the video stream
  • ATRAC audio stream is adopted as the audio stream.
  • video streams and audio streams are not limited to these. That is, as the video stream, for example, MPEG4-Visual or MPEG4-AVC can be adopted.
  • the audio stream for example, an MPEG1 / 2/4 audio LPCM audio stream or the like can be adopted.
  • a subtitle stream is not always decoded and displayed (output) at the same interval. That is, the caption stream is sometimes supplied from the buffer control module 215 of FIGS. 2A and 2B to the caption decoder control module 218 and decoded.
  • FIGS. 25 to 28 show three clip information files “000 01. CLP” and “00002. CLP” in the “CL IP ′” directory on the disc 101 as shown in FIG. ",” 00003. CLP “is recorded and” STREAM “directory
  • the three clip information files “00001. CLP”, “00002. CLP”, and “00003. CLP” respectively correspond to the three clip stream files “00001.PS”, “00002.PS”, and “00003”.
  • the following shows specific examples of the "PLAYLIST.DAT” file, the clip information files "00001. CLP", “00002. CLP”, and “00003. CLP” when ".PS" is recorded. .
  • the second clip information files "00001. CLP” and “00002. CLP” when ".PS” is recorded.
  • FIGS. 5 to 28 a part of the data such as the “PLAYLIST.DAT” file is omitted.
  • FIG. 25 shows a specific example of the “PLAYLIST.DAT” file described in FIG.
  • PlayLists is 2 for number_o, and accordingly, the number of PlayListOs included in the “PLAYLIST.DAT” file is 2.
  • the first is PlayList # 0 and the second is PlayList # 1.
  • PlayList # 0 which is the first PlayList ()
  • the capture_enabl e ag_PlayList is 1, so the secondary use of video data played according to PlayList # 0 is allowed.
  • Playltems is number_o and the number of Playltems is 2. Therefore, the number of PlayltemOs included in PlayList # 0 is 2.
  • FIG. 25 specific examples of the two PlayltemOs, PlayltemifO and Playltem # 1, are described below the column of “PlayList # 0j”.
  • Playl tem # 0 which is the first Playl temO included in PlayList # 0
  • the Clip—Information two file—name described in FIG. 6 is “00001. CLP”
  • In_time 180, 090, and OUT—
  • the time is 27, 180, and 090, respectively. Therefore, the clip reproduced by Playtem # 0 of PlayList # 0 is from time 180, 090 to time 27, 180, 090 of the clip stream file “00001.PS” corresponding to the clip information file “00001. CLP”.
  • Playl tem # 1 which is the second Playl temO included in PlayList # 0
  • the Clip-Information—file name described in FIG. 6 is “00002. CLP”
  • I 11_ 11 ⁇ is 90,000
  • OUT— time 27,090,000 respectively. Therefore, the clip reproduced by Playltem # l of PlayList # 0 is from time 90,000 to time 27,090,000 in the clip stream file "00002.PS” corresponding to the clip information file "00002. CLP”. It
  • PlayList # 1 which is the second PlayListO
  • capture_enable_flag_PlayList is 0, and therefore, secondary use of video data reproduced according to PlayList # 1 is permitted. Not (prohibited).
  • number_of_PlayItems is 1, and therefore, the number of PlayltemOs included in PlayList # 1 is 1.
  • FIG. 25 a specific example of PlayItem # 0, which is one PlayItemO, is described below the column of “PlayList # l”.
  • Playl tem # 0 which is one Playl temO included in PlayList # 1
  • Clip—Information_file one name described in FIG. 6 is “00003. CLP”
  • In—time 90,000
  • 0UT_time is 81, 090, 000, respectively. Therefore, the clip played by PlayItem # 0 of PlayList # 1 is from time 90,000 to time 81,090,000 of the clip stream file "00003.PS" corresponding to the clip information file "00003..CLP".
  • FIGS. 26A and 26B show specific examples of the clip information file ClipO described with reference to FIG. 26A and 26B show specific examples of the clip information files “00001. CLP”, “0000 2.CLP”, and “00003. CLP” in FIG.
  • the presentation-start.time is set to 90,000
  • the resentation end time is set to 27,990,000, respectively. Has become. Therefore, according to the program stream stored in the clip stream file “00001.PS” corresponding to the clip information file “00001.CLP”, 310 seconds ((27,990,000-90,000) / 90kHz ) Is available.
  • capture_enable_flag_Clip is 1, and therefore, the program stored in the clip stream file “00001.PS” corresponding to the clip information file “00 001.CLP” Secondary use of the video stream (corresponding to the video data) multiplexed into the stream is permitted.
  • the number—0 and streams of the clip information file “00001. CLP” is 4, and accordingly, the corresponding clip stream file “00001.PS” In the program stream stored in "", four elementary stream streams are multiplexed.
  • the stream_id is OxEO. Therefore, this elementary stream stream # 0 is shown in FIGS. As explained in Fig. 2 (or Fig. 11), it is a video stream. In the present embodiment, as described above, the private stream-id is irrelevant for the video stream, but is 0x00 in FIGS. 26A and 26B.
  • the picture—size of StaticInfoO (FIG. 1) included in the StreamInfoO is “720X480”, frame-rate is set to '29 .97Hz 'and cc_flag is set to'Yes'.
  • this video stream streamifO is video data of 720 ⁇ 480 pixels with a frame period of 29.97 Hz, and further includes closed caption data.
  • the Dynamiclnfo of Stre amlnfoO (Fig. 10) becomes 0. There is no set of pts—change_point and Dynamiclnfo ().
  • this elementary stream stream # l is an ATRAC audio stream as described with reference to FIGS. 20 and 22.
  • the audio_language_code of StaticInfoO (Fig. 12) included in the StreamlnfoO is set to "Japanese”.
  • the ATRAC audio stream stream # l which is the second elementary stream of the clip stream file "00001.PS" is described.
  • StreamlnfoO (Fig. 10) numl) er and Dynamiclnfo are 0, and there is no set of pts_change—point and DynamicInfoO. 1
  • this elementary stream stream # 2 is a caption stream as described in FIGS. 20 and 22.
  • the subtitle-language code of StaticInfoO (Fig. 12) included in Stre amlnfoO is 'Japanese' and configurable_flag are 0, respectively. Therefore, this subtitle stream stream # 2 is Japanese subtitle data, and changing its display method is not permitted (prohibited).
  • the number-of_DynamicInfo of Stream InfoO (Fig. 10) is 0.
  • Pts -change- point and Dynamic Info 0 do not exist.
  • the elementary stream stream # 3 is a caption stream as described with reference to FIGS. 20 and 22.
  • the subtitle stream stream # 2 which is the third element of the clip stream file "00001.PS", and the fourth element 01 " ⁇ & _ 3 ⁇ 6 & 111- are respectively 0x80 and 0x81 in order to distinguish them from the subtitle stream stream # 3 which is a tally stream.
  • the subtitle stream stream # 3 is Japanese subtitle data, and its display method is allowed to be changed.
  • the number—of—Dynamiclnfo of Stream InfoO (FIG. 10) is 0, and pts —Change— There is no set of point and Dynamiclnfo ().
  • the presentation_start—time is 90,000
  • the presentation_end-time is 27,090,000, respectively. Has become. Therefore, according to the program stream stored in the clip stream file “00002.PS” corresponding to the clip information file “00002 ⁇ CLP”, 300 seconds ((27,090,000-90,000) / 90kHz) content is available. Also, in the clip information file “00002.CLP”, the capture_enable_flag—Clip is 0, so the clip stream file corresponding to the clip information file "00 002. CLP" Secondary use of video streams (corresponding to video data) multiplexed with the program stream stored in “00002.PS” is not permitted (prohibited).
  • the program stream stored in the corresponding clip stream file “00002.PS” includes the above-mentioned clip stream file “ 00001.PS ", four elementary streams are multiplexed.
  • FIG. 26A and FIG. 26B the contents of the StreamlnfoO of the first to fourth elementary streams stream # 0 to # 3 of the clip stream file “00002.PS” are described above.
  • the contents are the same as the contents of the StreamlnfoO of each of the first to fourth elementary stream streams # 0 to # 3 of the stream file "00001.PS”, and the description thereof will be omitted.
  • the content of the 36 amlnfoO of each of the first to fourth element evening streams 36 & 111 # 0 to # 3 of the clip stream file “00002.PS” is the clip stream file “00001.PS”.
  • the first elementary stream stream # 0 of the clip stream file “00002.PS” is the same as the contents of the respective Streamlnfo () of the first to fourth elementary streams stream # 0 to # 3 of the video stream.
  • the second elementary stream stream # l is an ATRAC audio stream.
  • the third elementary stream stream # 2 and the fourth elementary small ream stream # 3 are both subtitle streams.
  • 6361 ⁇ & 011_611 1116 is 81,090,000 respectively. Therefore, according to the program stream stored in the clip stream file “00003.PS” corresponding to the clip information file “00003. CLP”, 900 seconds ((81, 090, 000-90, 000) / 90kHz) content is available. In the clip information file "00003. CLP", capture_enable_flag_Clip is set to 1. Therefore, the clip stream file corresponding to the clip information file "00 003. CLP" Secondary use of the video stream multiplexed with the program stream stored in “00003.PS” is permitted.
  • the number_oi_streams of the clip information file “00003. CLP” is 3, and accordingly, the clip information file is stored in the corresponding clip stream file “00003.PS”.
  • the program stream three elementary streams are multiplexed.
  • the stream_id is OxEO. Therefore, this elementary stream stream # 0 is shown in FIG. And a video stream, as described in Figure 2 and Figure 2 (or Figure 11). . Note that, like the first elementary stream stream # 0 of the clip stream file “00001.PS”, the private one stream_id is 0x00.
  • the picture_size of the StaticInfoO (Fig. 12) included in the StreamlnfoO is set to '720X480'.
  • frame— rate is set to '29 .97Hz 'and cc_flag is set to' No '. Therefore, this video stream stream # 0 is video data of 720 ⁇ 480 pixels with a frame period of 29.97 Hz, and does not include closed caption data.
  • the number_of_DynamicInfo of Stre amlnfoO (Fig. 10) is 2, In Streamlnfo 0, two sets of pts—change—point and Dynamiclnfo 0 are described.
  • the stream-id is OxEl
  • the elementary stream stream # l is As described in FIG. 20 and FIG. 22 (or FIG. 11), it is a video stream.
  • Each stream id is OxEO and OxEl.
  • the private-stream_id is 0x00.
  • the video stream stream # l which is the second elementary stream of the clip stream file "00003.PS”
  • picture_size, frame rate, cc of StaticInfoO (Fig. 12) included in the StreamInfoO —Flag is the same as that for the video stream stream # 0 that is the first elementary stream.
  • the video stream stream # l which is the second elementary stream of the clip stream file “00003.PS”
  • the stream_id is OxBD and the private-stream-id is 0x00. Therefore, the elementary stream streams are ATRAC audio streams as described with reference to FIGS. 20 and 22.
  • ATRAC audio stream stream # 2 which is the third elementary stream of the clip stream file "00003.PS"
  • audio_language_code which is the second elementary stream of clip stream file "00001.PS”. Therefore, the third elementary stream of the clip stream file "000 03. PS" Trim stream # 2 is Japanese and stereo audio data. Also, a low-frequency emphasis channel is not included, and the sampling frequency is 48 kHz.
  • FIG. 27 shows a specific example of EPjnapO in the clip information file Clip 0 described in FIG. That is, FIG. 27 shows a specific example of the EP-map () of FIG. 14 in the clip information file “00001. CLP” of FIG.
  • EPjnapO in Fig. 27 the stream-id is OxEO. Therefore, as described in FIGS. 20 and 22, EPjnapO contains information on the decoding start possible point (PTS-EP-3 & 1) for the video stream specified by the stream-id of OxEO. ⁇ And 1 ⁇ 8? —3131 ⁇ (Fig. 14)) are described. That is, FIG. 27 shows EPjnapO of the clip information file “00001.CLP”. In the clip stream file “00001.CLP” corresponding to the clip information file “0000 1.CLP”, the element whose stream-id is OxEO As described in FIGS. 26A and 26B, the evening stream is the first video stream s eam # 0 of the clip stream file “00001. CLP”. The information described in the EP-map () of the The code start possible point is PTS-EP-start and RPN_EP__start.
  • FIG. 28 shows a specific example of PlayListMarkO in PlayList # 0 and Playtist # 1 (PlayListO of FIG. 5) described in FIG. 25.
  • the upper part of FIG. 28 shows the PlayListMarkO of PlayList # 0. (Fig. 7). '
  • PlayList # O of PlayList # 0 has a number_of_PlayUstjnarks of 7, and therefore, the number of MarkOs included in (PlayListMarkO of) PlayList # 0 is 7.
  • Mark # 0 which is the first MarkO among the seven Marks () included in PlayList # 0 has a mark_type (FIG. 7) of 'Chapter'. , Is the mark.
  • Mark # 0 has a re-to—Play It em-id (Fig. 7) of 0, so the two PlayItems # 0 and # 1 in Fig. 25 included in PlayList # 0 are Belongs to PlayItem # 0.
  • Mark # 0 since Mark # 0 has] ⁇ _ 1111 ⁇ _51 & immediately 180 and 090, the time (playback time) of the clip stream file played by Playtem # 0 included in PlayList # 0 180, This is the sign on 090.
  • Mark # 0 is entry-ES stream id and entry-ES-private-strea Since each m-id is 0, it is not associated with any element evening list.
  • Mark # 0 represents the caption of number 1 because mark_data is 1.
  • the clip stream file reproduced by Playtem # 0 included in PlayList # 0 is described in the Clip1 Infomation_filejtiame of P1 ayltem # 0 described in FIG. CLP "is the clip stream file" '00001.PS ". Therefore, the above-mentioned times 180 and 090 represented by the mark_time_sta of Mark # 0 are the same as those of the clip stream file" 00001.PS ". It is time.
  • Mark # 4 which is the fifth MarkO among the seven MarkOs included in PlayList # 0 is a cap mark similar to the first MarkO.
  • Mark # 4 which is the fifth MarkO
  • mark_type (Fig. 7) is 'Chapter', so it is a cap mark.
  • Mark # 4 has a ref_to_PlayItem_id (FIG. 7) of 1 and belongs to Playtem #l of the two PlayItems # 0 and # 1 of FIG. 25 included in PlayList # 0.
  • Mark # 4 is a mark on time 90,000 of the clip stream file reproduced by Playtem #l included in PlayList # 0 since the mark one Ume_stamp is 90,000.
  • Mark # 4 is not associated with any elementary stream since entry-ES-stream-id and entry-ES-private-stream-id are all 0.
  • Mark_4 has a mark_data of 2, and thus represents a caption of number 2.
  • the clip stream file played by Playltem # l included in PlayList # 0 is described in the CI iD Infomation file name of P1 ayliem # l described in FIG. CLP " Therefore, the above-mentioned time 90,000 represented by mark__time_stamp of Mark # 4 is the time of the clip stream file "00002.PS".
  • Mark_l which is the second MarkO among the seven Marks () included in PlayList # 0 has mark_type (FIG. 7) of 'Index'. It is an index mark.
  • Mark # l has re_to_PlayItem— id (Fig. 7) set to 0, so PlayItem # of two PlayItem # 0 and # 1 in Fig. 25 included in PlayList # 0 Belongs to 0.
  • Mark # l is 1 ⁇ -11 ⁇ _81 & immediately becomes 5,580,090, time 5,5 of the clip stream file reproduced by Playtem # 0 included in PlayList # 0. It is a mark on 580,090.
  • Mark # l is not associated with any elementary stream because entry-ES-stream-id and entry-ES_private-stream-id are both 0.
  • Mark # l represents the index with the number 1 since mark-1 data is 1.
  • the clip stream file reproduced by Playtem # 0 included in PlayList # 0 is the clip stream file “00001.PS” as described above. Therefore, the mark_time_stamp The times 5,580,090 described above are the times of the clip stream file "00001.PS”.
  • Mark # 3 which is the fourth MarkO among the seven Marks () included in PlayList # 0 has a mark-type (Fig. 7) of 'E vent'. It is an event mark.
  • Mark # 3 Ref_to_PlayItem_id (FIG. 7) is 0, and therefore belongs to PlayItem # 0 of the two PlayItems # 0 and # 1 in FIG. 25 included in PlayList # 0.
  • Mark-time-siamp of Mark # 3 is 16, 380, 090, time 16, 380, of the clip stream file reproduced by Playtem # 0 included in PlayList # 0 This is the sign on 090.
  • Mark # 3 has no entry-ES-stream-id and entry_ES-private-stream-id of 0, so it is not associated with any elementary stream. For Mark # 3, since mark-data is 0, an event with 0 as an argument is generated.
  • the clip stream file reproduced by Pyltem # 0 included in PlayList # 0 is the clip stream file "00001.PS" as described above, and therefore, the mark_time_st a
  • the times 16, 380, and 090 described above are the times of the clip stream file “00001.PS”.
  • FIG. 28 shows PlayListMarkO (FIG. 7) of PlayList # l.
  • the number of MarkO included in PlayList # 1 (PlayListMarkO of PlayList # l) is 3 as for the number of PlayListMarks in PlayListMarkO of PlayList # 1.
  • Mark # 0 which is the first MarkO among the three MarkOs included in PlayList # l, has a markjype (Fig. 7) of "Chapter". It is the evening mark.
  • Mark # 0 is Since ref_to_PlayItem_id (FIG. 7) is 0, it belongs to one PlayItem # 0 in FIG. 25 included in PyList # l.
  • MarkJO has a mark-time-sta immediate of 90,000, and thus is a mark on the time 90,000 of the clip stream file reproduced by Playlist # 0 included in PlayList # 1.
  • Mark_0 is not associated with any elementary stream because entry_ES-stream_id and entry_ES_private-stream_id are both 0.
  • Mark # 0 indicates that the number is 0 because mark-data is 0.
  • the clip stream file played by Playltem # 0 included in PlayList # l is stored in (110_11 ⁇ 0] 1 ⁇ 011_16_1 ⁇ 1116 of Play 116111 # 0 described in FIG.
  • the clip stream file “00003.PS” specified from “00003. (1 ⁇ )” described. Therefore, the above-mentioned time 90,000 represented by mark—time_stanip of Mark # 0 is: This is the time of the clip stream file "00003.PS".
  • Mark # l which is the second MarkO of the three MarkOs included in PlayList # l has mark_type (Fig. 7) set to "Event".
  • Mark_l belongs to one PlayItem # 0 in Fig. 25 included in PlayList # l because ref_to_PlayItem_id (Fig. 7) is 0. Also, since Mark # l is mark Um 6_3 (& Immediately becomes 27,090,000, the time 27, 090 ,, of the clip stream file reproduced by Playtem # 0 included in PlayList # l In addition, Mark # l is specified by .entry-ES-stream-id is OxEO and entry-ES-private_stream-id is 0, so stream-id is specified by OxE0 ( The element list to be identified) is associated with the video stream as described with reference to Fig. 20 and Fig. 22. In Mark # l, mark-data is 1 So, as an argument Raises an event with 1.
  • the clip stream file reproduced by PlayItem # 0 included in PlayList # 1 is the clip stream file “00003.PS” as described above. Therefore, the mark_time_stamp The time 27,090,000 described above is the time of the clip stream file “00003.PS”.
  • the video stream with stream-id OxEO associated with Mark # l is included in PlayList # l of FIG.
  • the stream_id described in "00003. CLP" described in 110_11 ⁇ 0111 & 11011_16-11 & 1116 is an OxEO video stream, that is, the clip information file in FIG. 26A and FIG. 26B "00003. CLP
  • Mark # 2 has reLto—PlayItem_id (Fig. 7) set to 0. Therefore, it belongs to one? Layltem # 0 in Fig. 25 included in PlayList # l, and Mark # l has a mark-time-stamp of 27,540,000. #l is a mark on the time 27,540,000 of the clip stream file played by PlayItem # 0 included in # l.
  • Mark # 2 is entry-ES-stream-id is OxEl, entry-ES Since —private_stream—id is 0, the elementary stream whose stream—id is identified (identified) by OxEl, that is, associated with the video stream as described in FIGS. 20 and 22 Mark has an argument of 2 because mark data is 2. Raises an event with 2 as.
  • the clip stream file reproduced by PlayItem # 0 included in PlayListftl is the clip stream file “00003.PS” as described above, and accordingly, the above described time 27 represented by Mark # 2 , 540, 000 are the times of the clip stream file “00003.PS”.
  • the video stream of 36 & 111-1 (1 is ( ⁇ 81 is associated with Mark # 2, and the Clip_Infomation of PlayItem # 0 included in PlayList # l of FIG.
  • the stream_id described in "00003.CLP" described in the file-name is recognized from the OxEl video stream, that is, the clip information file "00003. CLP" in FIGS. 26A and 26B.
  • This is the second elementary stream (video stream) stream # l among the three elementary stream streams # 0 to # 2 multiplexed in the clip stream file "00003.PS".
  • the time from the beginning of PlayltemO to which MarkO belongs is shown on the right outside the column of the PlayListMarkO list of PlayList # l.
  • the number of the chapter index represented by the cap mark or index is described in mark_data, but the number of the index represented by the cap mark or index is: Even if it is not described in mark-data, it can be recognized, for example, by counting the number of cap mark index marks in PyListMarkO.
  • FIG. 29 is a flowchart for explaining the pre-reproduction processing performed by the video content reproduction program 210.
  • the operation or processing of the disk device described with reference to the flowchart is not necessarily required to be performed in chronological order according to the order described in the flowchart, but may be performed in parallel or individually. However, in this specification, the operation or processing of the disk device will be described along a flowchart for convenience.
  • the video content playback program 210 checks the disc 101 using the file system function of the operating system 201 in step S101, and It is determined whether or not 1 is a normal disc for the video content reproduction program 210.
  • step S101 if disk 101 is not a normal disk Is determined, that is, for example, if the file system adopted for the disk 101 is of a type not supported by the operating system 201, or the "VIDEO" directory is placed in the root directory. If not, it is determined that the video content playback program 210 is not compatible with the disc 101, and the process proceeds to step S102, where the graphics processing module 219 performs error processing and performs playback. Pre-processing ends.
  • the graphics processing module 219 generates an error message indicating that the disk 101 is not normal (a video data of the disk 101) as an error processing, and outputs the error message from the video output module 220. Display the error message.
  • the error processing for example, it is possible to output a warning sound from the audio output module 221 or to eject the disc 101 from the disc drive 102. is there.
  • step S101 determines whether the disk 101 is a normal disk.
  • the process proceeds to step S103, where the video content playback program 210 is executed by the content data supply module 210.
  • the operating system 201 has a "SCRIPT, DAT” file located in the "VIDEO" directory on the disk 101 (Fig. 4) and a "PLAYL IST. DAT” file. Requests and reads the two data files, and proceeds to step S104.
  • step S104 the "SCRIPT. DAT” file is supplied to the script control module 211, and the "PLAYLIST. DAT” file is supplied to the player control module 212.
  • step S 104 the process proceeds from step S 104 to S 105 to S 107, and the player control module 221 performs an initialization process.
  • the script The control module 211 waits until the initialization process of the player control module 212 ends.
  • step S105 the player control module 211 analyzes the "PLAYLIST.DAT" file, and the clip information file used in the "PLAYLIST.DAT” file. Investigate the number of files and their file names.
  • the “PLAYLIST.DAT” file is as shown in FIG. 25.
  • the player control module 2 1 2 uses the number_o in the “PLAYLIST.DAT” file in FIG. Since PUyLists is 2, it recognizes that there are two PlayLists 0, the first PlayList # 0 and the second PlayList # l. Further, since the number—of_PlayItems of the first PlayList # 0 in the “PLAYLIST.DAT” file in FIG. 25 is 2, the player control module 2 1 2 It recognizes that there are two PlayltemOs, the first Playltem # 0 and the second Playltem # l.
  • the player control module 2 1 2 includes the first Playl tem # 0 and the second Playl tem #l included in P1 ayList # 0 in the “PLAYLIST.DAT” file in FIG. Clip_Information—By referring to filp_name, the clip information file (the file name) of the first PlayItem # 0 included in PlayList # 0 is “00001. CLP” and the clip information file of the second Playltem # l Is recognized as "00002. CLP”.
  • the player control module 2 1 2 has a P1 ayltemO (PlayItei # 0) because the number_o and Playltems of the second PlayList # l are 1, and furthermore, the Playltem # 0 from C1 ip Information file_name in PlayItem # 0 It recognizes that the file is "00003. CLP".
  • step S105 the player control module 2122 starts from the disc 101 and returns to the clip information file recognized in step S105, ie, Read the three clip information files "00001.CLP”, "00002. CLP”, and "00003. CLP” from the "CLIP” directory in the "VIDEO" directory.
  • reading of the clip information file in step S106 is sufficient only with the clip information file of the Playltem of the PlayListO to be played first, but in the present embodiment, as described above, The clip information file of PlayltemO of P1 ayListO shall be read in advance.
  • step S107 the player control module 212 determines whether or not the clip information file recognized in step S105 has been successfully read. It is determined (checked) whether or not the read clip information file has a corresponding clip stream file on the disc 101. That is, in step S107, the clip information files "00001. CLP”, “00002. CLP”, and “00003. CLP” were successfully read, and further, the clip information files "00001. CLP", “0. Clip stream files "00001.PS”, “00002.PS”, and "00003.PS” that differ only in the file name extension from "0002. CLP” and "00003. CLP” Determines whether the file exists in the "STREAM” directory under the "VIDEO" directory.
  • step S107 it is determined that reading of the clip information file recognized in step S105 has failed, or the clip stream file corresponding to the clip information file does not exist on disc 101. Is determined, that is, for example, "PLAYLIST.DA If the clip information file required for playback according to the "T" file is not recorded on the disc 101, the video content playback program 210 must be compatible with the disc 101. Upon making a determination, the process proceeds to step S102, where the above-described error processing is performed, and the pre-reproduction processing ends.
  • step S107 it was determined that the clip information file recognized in step S105 was successfully read, and that a clip stream file corresponding to the clip information file exists on disc 101.
  • the player control module 211 ends the initialization processing, and proceeds to step S108.
  • step S108 the script control module 211 starts interpreting and executing the "SCR IPT. DAT" file.
  • FIG. 30 is a flowchart for explaining a reproduction process performed by the video content reproduction program 210.
  • the player control module 2 1 2 first executes the PlayList () instructed to play from the script control module 2 1 1 in steps S 1 2 1 and S 1 2 2, that is, the first PlayList.
  • a playback preparation process for 0 (PlayList # 0) is performed.
  • step S121 the player control module 2 1 2 sets the IN—time () of the first PlayItem # 0 included in the first PyList # 0. (Fig. 6) and proceed to step S122, where the clip stream file “00001.PS” played by the first PlayItem # 0 included in the first PyList # 0 Investigate the playback start position corresponding to the IN-time of PlayItem # 0 to start playback.
  • the Playtime O Iltime (Fig. 6) points to the beginning of the clip stream file, the program stream can be read from the beginning of the clip stream file, but IN_time is If it points to something other than the beginning of the file, it is necessary to find out (investigate) the position corresponding to IN-time and read the program stream from there.
  • the IN-time of the first PlayItem # 0 included in the first PlayList # 0 is 180,090.
  • the player control module 2 1 2 uses the clip stream file “00001. CLP” played by the first Pyltem # 0 included in the first PlayList # 0, from the EP1 map 0 shown in FIG. Find a playback start position suitable for 180-090, which is the IN-time of Playtem # 0.
  • the player control module 2 1 2 performs, for example, a binary search for the maximum PTS-EP_start that satisfies the expression PTS_EP_sart ⁇ IN_time among the PTS-EP_starts indicating the start points of decoding described in the EP-mapO (Binary search).
  • PTS_EP—start that is less than IN_time is searched because the position indicated by INJime is not necessarily the decoding start possible point. .
  • IN-time is 180,090 as described above.
  • the expression PTS EP_star The largest PTS—EP—s that satisfies t ⁇ IN—time 180 and 090 are described as tart. Therefore, in the player control module 2 12, the PTS_EP_start of 180 and 090 is retrieved from EPjnapO shown in FIG.
  • the player control module 2 12 proceeds from step S 122 to S 123 and controls the graphics processing module 2 19 so as to display the time code.
  • the graphics processing module 219 generates time code (of the video data) and outputs it to the video output module 220 under the control of the player control module 221. This starts the display of the time code.
  • the time code at which the display is started in step S123 is, for example, a value obtained by converting the head of 'PlayListO' to 00:00:00 (hour: minute: second).
  • the number of the cap index may be displayed together with the time code or instead of the time code.
  • step S124 the player control module 221 performs the PlayList (), which is instructed by the script control module 211 to play, That is, analysis processing for analyzing PlayListMarkO (FIG. 7) described in the first PlayListO (PlayList # 0) is performed.
  • the player control module 2 1 2 reads the first PlayList # 0 in the already read “PLAYLIST.DAT” file, as shown in FIG.
  • the number—of—PlayListjnarks is 7, it is recognized that the number of MarkOs included in the PlayList # 0 is 7.
  • the player control module 2 12 analyzes the seven MarkOs shown in the upper part of FIG. 28 included in the PlayListifO, and from the re_to_PlayItem_id, the four MarkOs from the first to the fourth of the seven MarkOs. It recognizes that MarkO belongs to the first PlayltemO (PlayltemftO) of PlayLis 0.
  • the player control module 211 extracts the mark_time_sta immediately of the four MarkOs belonging to the first PlayItem # 0 of the PlayList # 0, and passes it to the decode control module 214 as an array having four elements. That is, by this, the mark_time_sta of each of the four MarkOs from the first to the fourth of the seven MarkOs in the upper part of FIG. 28 is ⁇ 180, 090 ⁇ , ⁇ 5, 580, 090 ⁇ , ⁇ 10 , 980, 090 ⁇ and ⁇ 16, 380, 090 ⁇ are passed from the player control module 212 to the decode control module 214.
  • the fact that the attribute of these times is “mark processing” is also transmitted from the player control module 212 to the decode control module 214.
  • the decode control module 214 resets the message indicating this to the time of the “mark processing” attribute.
  • the notified time and the attribute of “mark processing” are transmitted to the player control module 2 12.
  • step S125 the player control module 212 determines an elementary stream to be reproduced.
  • the player control module 2 1 2 The file name is described in the CI ip—Information_file_name of the first PlayItem # 0 (FIG. 25) in the first PlayList # 0, which is the PlayList 0 instructed to be played back from the file 211.
  • the clip information file “00001.CLP” in FIG. 26A and FIG. 26B since the number—of—streams is 4, the corresponding clip stream file “00001 • PS” contains four elements. Recognize that evening stream is multiplexed.
  • the player control module 2 with respect to the four elementary lists, performs the operation of 31 &(; 11 ⁇ 0 () of the clip information file “00001.0 ⁇ ” in FIGS. 26A and 26B.
  • Information on the number of elementary streams of each attribute multiplexed in the clip stream file is used for switching elementary streams during playback (audio switching, subtitle switching, etc.). Also, the subtitle stream may not be present in the clip stream file (the content does not include subtitles), and the elementary stream having the attribute “subtitle stream” is used to determine whether or not the subtitle stream exists. Is used.
  • the player control module 211 selects and decides the elementary stream to be reproduced based on the result of the StaticInfoO investigation as described above. In this case, the player control module 221 multiplexes the elementary stream into the clip stream file “00001.PS”.
  • the player control module 221 multiplexes the elementary stream into the clip stream file “00001.PS”.
  • elementary streams with the attributes "video stream” and "audio stream” Since there is only one stream each, there is no choice for the elementary stream with the attributes of “video stream” and “audio stream”, and there is no choice, and the one video stream and audio stream (ATRAC audio stream) Is determined as the elementary stream to be played.
  • the elementary stream having the attribute of “subtitle stream” there are two of the four elementary streams multiplexed in the clip stream file “00001.PS”.
  • One of the subtitle streams is selected and determined as the elementary stream to be played.
  • the first subtitle stream in the order of appearance in the clip information file "00001. CLP" is selected from the two subtitle streams.
  • each of the four elementary stream streams is identified.
  • the player control module 211 specifies the four elementary streams multiplexed in the clip stream file “00001.PS” by using the stream_id and the necessary private-stream_id.
  • the player control module 212 is an elementary stream having an attribute of “video stream” among the four elementary streams multiplexed in the clip stream file “00001.PS”. As described with reference to the clip information file “00001. CLP” in FIG. 26A and FIG. 26B, the video stream to be specified is specified by the stream-id of OxEO.
  • the player control module 2 1 2 Among the four elementary streams multiplexed in the file “00001.PS”, the ATRAC audio stream, which is the elementary stream with the attribute of “audio stream”, is shown in FIG. 26A and FIG. 6 As described for the clip information file "00001. CLP" in Fig. B, it is specified by the stream_id of OxBD and the private_stream-id of 0x00.
  • the player control module 211 is an elementary stream having attributes of “subtitle stream” in the four elementary streams multiplexed in the clip stream file “00001.PS”. As described for the clip information file “00001. CLP” in FIG. 26A and FIG. 26B, the subtitle streams of OxBD and private_stream_id Stream-id and private-stream-id of 0x81.
  • the combination of stream-id and private-one stream-id is a mechanism provided to extend the multiplexing of the MPEG2-System.
  • stream — id and private_stream_id in metadata (database) to identify an elementary stream, it is possible to reliably identify an elementary stream.
  • the current mechanism can be used as it is.
  • Prevail in sex That is, for example, in the BD (Blue ray Disc) standard, the PID (Packet ID) of the transport stream (Transport Stream) of the MPE G2 standard is used to specify the data, so that it is restricted by the MPEG2 standard.
  • the PID Packet ID
  • Transport Stream Transport Stream
  • the sub_stream_id can be described on a database to specify a stream.
  • the combination of stream_id and private_stream-id describes the message data.
  • the clip information file C1 ip () in FIG. Therefore, the elementary streams multiplexed in the clip stream file can be described irrespective of the number (the range of the number that can be represented by number, number_o, and streams) in the clip information file CI ip It can be specified from the combination of stream_id and private stream_id as the metadata described in parentheses ().
  • the combination of stream_id and private-stream-id specifies the elementary stream multiplexed with the corresponding clip stream file in the clip information file of FIG.
  • the entry-ES-stream-id and the entry-ES-private-stream-id are combined to specify the element stream associated with MarkO.
  • the combination of stream_id and private_stream_id In addition, for example, in EPjnap O in Fig. 14, it is also used to specify an elementary stream that describes information on a decodable start point.
  • step S125 the process proceeds from step S125 to step S126, and the player control module 212 sets the elementary stream to be reproduced, that is, the elementary stream determined to be reproduced in step S125. Performs output attribute control processing.
  • the player control module 212 first outputs the elementary stream to be reproduced, that is, the video stream, the ATRAC audio stream, and the subtitle stream that are determined to be reproduced in step S125.
  • the elementary stream to be reproduced that is, the video stream, the ATRAC audio stream, and the subtitle stream that are determined to be reproduced in step S125.
  • the video stream, ATRAC audio stream, and subtitle stream to be played back are elementary stream multiplexed in the clip stream file “0 0001. PS”, and their number is 0 to Dynami. c lnfo is 0 as described in “00001 ⁇ CLP” in FIG. 26A and FIG. 26B. As described above, when the number_o and Dynami c lnfo of all the elementary stream to be reproduced are 0, the player control module 2 1 2 performs control processing of the output attribute of the elementary stream to be reproduced as No special processing is performed.
  • step S126 the process proceeds to step S127, in which the player The control module 212 performs a preparation process for starting reproduction of the elementary stream to be reproduced.
  • the player control module 2 12 starts supplying the buffer control module 2 15 with the program stream stored in the clip stream file “00001.PS” in which the elementary stream to be reproduced is multiplexed. Before starting, initialize the buffer control module 2 15.
  • the buffer control module 2 15 (FIG. 3) stores the data start pointer stored in the data start pointer storage section 2 31 and the data write pointer storage section 2 32 in the data write pointer storage section 2 32.
  • Data read pointer, video read pointer stored in the video read pointer storage unit 241, audio read pointer stored in the audio read pointer storage unit 251, and subtitle read pointer storage unit 262 The same value is assigned to the stored subtitle read pointer.
  • the data start pointer stored in the data start pointer storage unit 2 31 and the data write data stored in the data write pointer 2 32 are stored in the buffer 2 15 of the buffer control module 2 15. Refers to the same position of A. This means that no valid data is stored in the buffer 215A.
  • the player control module 2 1 2 outputs a stream—id as identification information for identifying (identifying) the elementary stream to be reproduced. Further, if necessary, a private stream_id is supplied to the buffer control module 215.
  • the video stream having the attribute “video stream” is specified by the stream_id of OxEO, and the ATRAC audio stream having the attribute “audio stream”. Is specified by the stream_id of OxBD and the private_stream_id of 0x00.
  • the subtitle stream of the attribute “subtitle stream” is stream_id of OxBD, and private—st ream of 0x80. —Specified by id.
  • the player control module 2 12 supplies these stream-id and private-str earn-1 id to the buffer control module 2 15.
  • the video reading function unit 233 converts the stream-id, which is OxEO for the video stream, from the player control module 2 12 into the stream-id, Store it in register 2 42.
  • the audio read function unit 234 stores the stream-id as OxBD and the private-stream-id as 0xOO from the player control module 212 in the stream_id register 252.
  • the subtitle reading function unit 235 stores the stream_id of OxBD and the private_stream_id of 0x80 from the player control module 212 in the stream_id register 263 and the private stream_id register 264, respectively. Let it. .
  • the player control module 2 12 stores the stream-id and private_stream-id of the elementary stream to be reproduced, which have been supplied to the buffer control module 2 15, for future processing.
  • the player control module 2 1 2 uses these stream ids and private-stream_ids This is used when a message requesting to switch streams to be generated occurs, or to specify the stream currently being played back in the mark processing described later.
  • the player control module 2 12 initializes the buffer control module 2 15 (Fig. 3), and further adds subtitles with values according to the clip stream file in which the element list to be played is multiplexed.
  • the read function flag is set in the subtitle read function flag storage unit 261.
  • the subtitle reading function unit 235 since the subtitle stream is included in the clip stream file “00001.PS” in which the elementary streams to be reproduced are multiplexed, the subtitle reading function unit 235 must be operated. , A subtitle read function flag having a value of 1 is set in the subtitle read function flag storage unit 26 1. If a subtitle stream is not included in the clip stream file in which the elementary stream to be played is multiplexed, a subtitle read function flag with a value of 0 is set in the subtitle read function flag storage unit 26 1. Is done. In this case, the subtitle reading function unit 235 does not function (in particular, no processing is performed).
  • the player control module 2 12 is an INJ ime of the first PlayItem # 0 (FIG. 25) included in the first PlayList # 0 instructed to be reproduced by the script control module 211. 180, 090 and 0, UT_time of 27, 180, 090 are given to the decode control module 214.
  • I.ltime controls the start of decoding of a clip reproduced by Playltem ()
  • OUT-time controls the end of decoding of the clip
  • Playltem (described later). Used to control transfer.
  • the player control module 2 1 2 includes a graphics processing module. Initialize the instruction of the display method of the subtitle stream for Yule 219. That is, the player control module 211 controls the graphics processing module 219 so that the display method of the subtitle stream is, for example, the default display method.
  • step S127 the player control module 212 controls the content data supply module 212, whereby the content data supply module 211 operates the Read the clip stream file that stores the program stream in which the elementary stream to be played is multiplexed using the function of the streaming system 201. That is, the content data supply module 213 specifies the clip stream file “00001.PS” in the “STREAM” directory under the “VIDEO” directory on the disc 101 (FIG. 4). Then, it specifies 305 sectors, which is the playback start position determined in step S122, and requests the operating system 201 to read the file. The content data supply module 2 13 specifies that the data read from the disk 101 is to be supplied to the buffer control module 2 15.
  • the buffer control module 215 (FIG. 3) stores the program stream read and supplied from the disk 101 into the data write pointer storage section 232 of the buffer 215A. Write to the pointed location, write data only the size of the written data Increment the pointer.
  • the content data supply module 213 reads the data from the disk 101 if there is free space in the buffer 215A of the reference control module 215.
  • the data is supplied to and stored in the buffer 215A of the buffer control module 215. Therefore, it is assumed that a sufficient amount of data is constantly stored in the buffer 215A.
  • reading of data from the disk 101 is started, and when the data starts to be stored in the buffer 215 A of the buffer control module 215, steps S128 to S129 are performed.
  • the decoder control module 2 14 controls the video decoder control module 2 16, the audio decoder control module 2 17, and the subtitle decoder control module 2 18. Start reading data from 15A.
  • the video decoder control module 2 16 requests data from the video readout function section 2 33 of the buffer control module 2 15 (FIG. 3), and in accordance with the request, the buffer control module 2 1 Buffer 2 passed from 5 2.1 A video access unit stored in 5 A, PTS and DTS added to the video access unit (hereinafter referred to as time stamp as appropriate), and placed immediately before decoding start possible point
  • the information described in the PES of the pr ivat e—st reamj—packet t 0 (hereinafter, also referred to as additional information as appropriate), such as pic_s t ruc and copy, a u_re and fl ag, and AU_length obtain.
  • the time stamp is transmitted from the video decoder control module 216 to the decode control module. Passed to le 2 14.
  • the audio decoder control module 2 17 also requests the audio read function section 2 34 of the buffer control module 2 15 (FIG. 3) to perform a data transfer, and the buffer control module 2 15 responds to the request. It gets one (ATRAC) audio access unit stored in buffer 2 15 A and the time stamp (PTS, DTS) attached to that audio access unit. The time stamp is passed from the audio decoder control module 217 to the decode control module 214 each time the audio decoder control module 217 obtains the audio access unit.
  • ATRAC audio access unit stored in buffer 2 15 A
  • PTS time stamp
  • the caption decoder control module 218 requests data from the caption reading function section 235 of the buffer control module 215 (FIG. 3), and passes the data from the buffer control module 215 in response to the request.
  • the subtitle access unit stored in the buffer 215A and the time stamp attached to the subtitle access unit are obtained.
  • the time stamp is passed from the subtitle decoder control module 218 to the decode control module 214 each time the subtitle decoder control module 218 obtains the subtitle access unit. If the subtitle stream does not exist in the elementary stream to be played back or if the subtitle access unit is not stored in the buffer 215A, the subtitle decoder control module 2 No data is passed to 18. .
  • the video decoder control module 2 16 the audio decoder control module 2 17, and the subtitle decoder control module 2 18 request data from the buffer control module 2 15, the data The result of the request is sent to the decode control module 2 1 4 hand over.
  • the data buffer 2 when data is passed from the buffer control module 215 to the video decoder control module 216, the audio decoder control module 217, and the subtitle decoder control module 218, the data buffer 2 The details of reading from 15A will be described later.
  • the video decoder control module 2 16 the audio decoder control module 2 17, and the subtitle decoder control module 2 18 start reading data from the buffer 2 15 A of the buffer control module 2 15, From S129, proceed to S130, and the decod- ing of that day starts.
  • the decoding control module 2 14 receives the first ?? included in PlayList # 0 given from the player control module 2 12 in step S127. 1 & ⁇ 6111 # 0 1_1! 16 180, 090, and further, the video decoder control module 2 16, audio decoder control module 2 17, subtitle decoder control module 2 18 from step S 1 29 Based on the time stamp passed as described in 9, the timing is shifted if necessary to ensure synchronization, and decoding is started by the video decoder control module 2 16 and the audio decoder control module 2. 17 and the subtitle decoder control module 218.
  • a method of instructing the start of decoding with staggered timing to ensure synchronization is described in, for example, Japanese Patent No. 3496725, and is simply described as a video decoder control module 2 16 and an audio decoder control module.
  • the minimum value of the time stamps passed from each of the subtitle decoder control module and subtitle decoder control module is calculated by the timer section.
  • There is a method to start the time measurement by setting it as the initial value of the time measured by the timer, and instruct the start of decoding when the time measured by the timekeeping unit 2 14 A and the time stamp match. .
  • the video decoder control module 2 16 receives the decode start instruction from the decode control module 2 14, and in response to the instruction, the video read function section 2 3 3 of the buffer control module 2 15 (FIG. 3). The obtained one video access unit is passed to a video decoder 116 (FIG. 1) for decoding. Furthermore, the video decoder control module 216 supplies the video data obtained as a result of decoding by the video decoder 116 to the graphics processing module 219. Thereafter, the video decoder control module 2 16 sequentially decodes the video access units obtained from the video read function section 2 33 of the buffer control module 2 15 by the video decoder 1 16, and The video data obtained as a result of decoding is supplied to the graphics processing module 219.
  • the audio decoder control module 2 17 also receives a decode start instruction from the decode control module 2 14, and responds to the instruction to perform the audio read function 2 3 of the buffer control module 2 15 (FIG. 3).
  • One audio access unit obtained from 4 is passed to an audio decoder 1 17 (FIG. 1) for decoding. Further, the audio decoder control module 217 supplies audio data obtained as a result of decoding by the audio decoder 117 to the audio output module 221.
  • the audio decoder control module 2 17 uses the audio decoder 1 17 to obtain one audio access unit obtained from the audio read function section 2 34 of the buffer control module 2 15.
  • the audio data is decoded sequentially and the audio data obtained as a result of the decoding is supplied to the audio output module 221.
  • the subtitle decoder control module 218 also receives the decoding start instruction from the decode control module 214 and, in response to the instruction, reads the subtitle of the buffer control module 215 (FIG. 3).
  • One subtitle access unit obtained from the section 235 is decoded by the subtitle decoding software provided therein, and the subtitle data (caption image data) obtained as a result of the decoding is supplied to the graphics processing module 219. .
  • the subtitle decoder control module 218 sequentially decodes each subtitle access unit obtained from the subtitle readout function unit 235 of the buffer control module 215 using the internal subtitle decoding software. Then, the subtitle data obtained as a result of the decoding is supplied to the graphics processing module 219.
  • step S130 the graphics processing module 219 executes the video decoding control module 216 supplied from the video decoder control module 216 as described above, and furthermore, if necessary. Accordingly, graphics processing is performed on the subtitle data supplied from the subtitle decoder control module 218.
  • the graphics processing module 219 first performs subtitle processing such as enlargement or reduction according to the display method instruction from the player control module 221, according to the display method instruction from the player control module 218. U.
  • the graphics processing module 219 sends the character from the subtitle decoder control module 218 to Save the Makuhari night as it is.
  • the graphics processing module 219 adds the video data from the video decoder control module 216 and the subtitle data from the subtitle decoder control module 218 or the subtitle data after the subtitle processing. Then, output video data in which caption data is overlaid on the video data from the video decoder control module 216 is obtained and supplied to the video output module 220.
  • the graphics processing module 211 is a script control module.
  • the user control module 212 and the player control module 212 are capable of transmitting information such as menus, messages, time codes, captions, or index numbers.
  • the display instruction is received, the information is generated, overlaid on the output video overnight, and supplied to the video output module 220.
  • step S132 the video output module 220 is supplied from the delay processing module 219 as described in step S131.
  • the output video data is sequentially stored in the FIF022OA, and the output video data stored in the FIF022OA is sequentially output at a predetermined output rate.
  • the video output module 220 accepts the output video data from the graphics processing module 219 as long as the storage capacity (remaining capacity) of the FIF0 220 A is sufficient.
  • the video output module 220 requests the graphics processing module 219 to stop accepting the output video data, and then the output of the output video data from the FIF0 220 A proceeds.
  • 0 A has room, it requests the graphics processing module 219 to accept the output video data.
  • This request is transmitted from the graphics processing module 219 to the video decoder control module 216 and the subtitle decoder control module 218 similarly to the request to stop accepting the output video data.
  • the graphics processing module 220 requests the graphics processing module 219 to stop accepting the output video data, and then the output of the output video data from the FIF0 220 A proceeds.
  • 0 A has room, it requests the graphics processing module 219 to accept the output video data.
  • This request is transmitted from the graphics processing module 219 to the video decoder control module 216 and the subtitle decoder control module 218 similarly to the request to stop accepting the output video data.
  • the audio output module 221 also sequentially stores the audio data supplied from the audio decoder control module 217 in the FIF0221A as described in step S130, and stores the data in the FIFO.
  • the audio output module 221 accepts the audio data from the audio decoder control module 217 as long as the storage capacity (remaining capacity) of FIF0 221 A is sufficient. Stopping the reception of audio data is controlled by the audio decoder control module.
  • Step 2 17 stops the processing.
  • the output of the audio data from the F IFO 2 2 1 A advances, and the F IF 0 2 1 A
  • the audio decoder control module 217 requests the audio decoder control module 217 to accept the audio data.
  • the audio decoder control module 217 resumes the stopped processing.
  • the elementary stream is decoded.
  • playback of the first PlayList # 0 of the first PlayList # 0 in FIG. 25 starts.
  • PlayList # 0 When the reproduction of the second PlayItem # 0 ends, the reproduction of the second Playltem # l starts. That is, the PI ay Item is changed from PlayItem # 0 to Playltem # l.
  • the decoding control module 2 14 (2nd Figure A and Figure 2B) continue to check the time being counted by the built-in clock unit 214A while the first Playtem # 0 is being played.
  • the decode control module 2 14 determines that the time measured by the timer 214A is the player control module at step 127 of FIG. When the value is equal to 27, 180, 090 (FIG. 25), which is the 0UT_Ume of the first PlayItem # 0 given from the PlayItem # 2, in step S151, the control of the decode interruption is performed and the PlayItem # The reproduction of 0 ends.
  • the decode control module 214 operates the video decoder control module 216, the audio decoder control module 217, and the subtitle decoder control module 218 to stop the decoding operation. Further, the decode control module 214 controls the video output module 220 to continuously output the output video data currently being output. The decode control module 214 ends the reproduction of the first PlayItem # 0. A message to the effect is transmitted to the player control module 2 1 2.
  • the player control module 2 1 2 includes the first PlayList # 0 and the first Playltem # 0 and the second Playltem #l.
  • the decoding control module 2 14 has received a message indicating that the reproduction of the first PlayItem # 0 has been completed, the process proceeds from step S 15 1 to S 15 2, and Playback of the first Playltem # l is started in the same manner as in the case of the first PlayItem # 0 described above.
  • the player control module 2 1 2 As in the case of the step S 1 22 in FIG. Regarding, one of RPN_EP-start described in EPjnap 0 is determined as the reproduction start position. Further, as described in step S124 of FIG. 30, the player control module 2 1 2 includes the MarkO belonging to the second nayltem # l. Of the attributes multiplexed in the clip stream file "00002.PS" played by PlayItem # l as described in step S125 of FIG. The number of elementary streams is recognized, and the elementary stream to be reproduced (to be reproduced) is determined.
  • the player control module 2 12 performs the same processing as in step S 127 of FIG.
  • the file name of the file that is, in this case, the clip stream file corresponding to "00002. CLP" described in CI ip_Information —file—name of the second Pl ayl t emif l (Fig. 25)
  • the file name of “00002. PS” is given to the content data supply module 2 13.
  • the player control module 2 12 starts supplying the program stream stored in the clip stream file “00002 • PS” in which the element stream to be reproduced is multiplexed to the buffer control module 2 15. Initializes the buffer control module 2 15 before being executed.
  • the data is stored in the data head pointer stored in the data head pointer storage unit 231, and the data write pointer storage unit 2332.
  • Data write pointer, video read pointer stored in video read pointer storage unit 21, audio read pointer stored in audio read pointer storage unit 251, stored in subtitle read pointer storage unit 26 2 The same value is assigned to the subtitle readout Further, the player control module 2 12 supplies a stream_id as identification information for identifying an elementary stream to be reproduced, and further supplies a private_stream_id to the buffer control module 2 15 as necessary.
  • the video reading function unit 233 converts the stream_id.d from the player control module 2 12 for the video stream of the elementary stream to be played back.
  • the audio reading function unit 234 converts the stream_id and private_stream_id of the audio stream of the elementary stream to be played back from the player control module 212 into the stream_id Regis evening 2 52 and private— str eam_id Regis evening 2 53 3
  • the subtitle reading function unit 23 from the player control module 2 12 includes the subtitle stream. 5 is supplied with the stream-id and private-stream-id of the subtitle stream of the elementary stream to be played, and the subtitle reading function unit 23 5 sends the stream-id and private-stream-id. Are stored in the stream_id register 263 and the private_stream_id register 264, respectively.
  • the player control module 2.12 initializes the buffer control module 2 15 (FIG. 3) by adding a value according to the clip stream file in which the element stream to be played back is multiplexed.
  • the subtitle read function flag is set in the subtitle read function flag storage unit 261. That is, in this case, since the clip stream file “00002.PS” in which the elementary stream to be reproduced is multiplexed includes the subtitle stream, the subtitle reading function unit 235 is required to function. , A subtitle read function flag having a value of 1 is set in the subtitle read function flag storage unit 26 1.
  • the player control module 2 1 2 decodes 90, 000, which is the IN_time of the second Playltem # l (FIG. 25) to be played, and 27,090, 000, which is the OUT-time. Give to control module 2 14.
  • the player control module 212 initializes a subtitle stream display method instruction to the graphics processing module 219. That is, the player control module 211 controls the graphics processing module 219 so that the display method of the subtitle stream is the default display method.
  • the player control module 2 1 2 to the graphics processing module 2 1 9
  • the instruction of the display method of the subtitle stream for may be the same as the current display method. .
  • the reproduction of the second Playltem # l is performed in the same manner as the reproduction of the first Playltem # 0. Then, while the reproduction of the second Playltem # l is being performed, the decode control module 214 keeps checking the time being counted by the built-in timer 214A. The time that is being measured is 27,090,000 (Fig. 25), which is the second Pyltemitl's 0UT_time given by the player control module 2 12 in step S 1.52 (Fig. 31). If equal, go to step S 1 5 1 Then, the same decoding interruption control as in the case of the above is performed, and the reproduction of Playltem # l ends.
  • step S123 of FIG. 30 the display of the time code is started, and the display of the time code is sequentially updated.
  • step S 171 informs the user that 1 second has elapsed.
  • the current time being timed by the timekeeping section 2 14 A is supplied to the player control module 2 12, and the flow advances to step S 17 2.
  • the player control module 2 12 receives the message and the current time from the decode control module 2 14, converts the current time into a time code, and Proceed to.
  • step S 173 the player control module 221 controls the graphics processing module 219 to display the time code obtained in step S 172, and returns to step S 171.
  • the time code is updated every second.
  • the time code update interval is not limited to one second.
  • the clip stream file "00001.PS" reproduced by the first PlayItem # 0 constituting the first PlayList # 0 described in FIG.
  • the clip stream file "00002.PS" contains the information described in Fig. 26A and Fig. 26B.
  • two subtitle streams are multiplexed.
  • the elementary list to be reproduced is converted into the plurality of elementary streams having the same attribute. You can switch streams from one of the streams to the other.
  • the stream switching request is made, for example, when the stream switching instruction is described as a script program in the “SCRIPT. DAT” file (FIG. 4), and the script control module 211 executes the script program.
  • the program is given to the player control module 2 12 by executing or by operating the remote control by the user.
  • the script control module 211 when the script control module 211 executes a scribing program in which a stream switching instruction is described, the script control module 211 supplies a stream switching request message to the player control module 211.
  • the input interface 115 When the user operates the remote controller to receive a signal indicating stream switching from the remote controller, the input interface 115 outputs a message requesting stream switching to the player control module 211. To supply.
  • a subtitle stream switching message which is a message requesting a subtitle stream switching
  • the player control module 2 12 191 the character recognized when the elementary stream to be played back was determined in step S125 of FIG. 30. Check the number of curtain streams.
  • the player control module 2 12 ignores the subtitle stream switching message, and accordingly, the subsequent steps S 19 2 to S 1 The processing of 94 is not performed.
  • the process proceeds to steps S192 to S194, and the subtitle stream to be reproduced is switched from the currently reproduced subtitle stream to another subtitle stream. .
  • the player control module 212 specifies the currently reproduced subtitle stream on the clip information file. More specifically, for example, the stream-multiplexed to the clip stream file “00002.PS” by the second Playltem # l constituting the first PlayList # 0 described in FIG. Assuming that a subtitle stream with an id of OxBD and private—stream—id of 0x80 is being played, in step S192, the currently playing subtitle stream is a clip stream file “00002.PS”. Out of the two subtitle streams multiplexed into the clip information file "00002.CLP" in Fig. 26A and Fig. 26B, which is the stream that is the third subtitle stream Is done.
  • the player control module 2122 sets the next subtitle stream in the clip information file of the subtitle stream identified in step S192 as the next subtitle stream to be reproduced. Recognize (specify). In Fig. 26A and Fig. 26B, in the clip information file "00002. CLP", the next subtitle stream of the third subtitle stream stream # 2 is the fourth subtitle stream stream # Because it is 3, In step SI93, the fourth subtitle stream stream # 3 is recognized as the next subtitle stream to be reproduced.
  • the currently reproduced subtitle stream is the clip information file “00002” shown in FIGS. 26A and 26B among the two subtitle streams multiplexed into the clip stream file “00002.PS”. If it is specified that the stream is stream # 3 which is the fourth subtitle stream on the .CLP ", for example, the third subtitle stream stream # 2 is recognized as the subtitle stream to be reproduced next.
  • step S194 the player control module 212 sends the stream_id and private-stream_id of the subtitle stream to be reproduced next recognized in step S193 to the buffer control module 215 (FIG. 3).
  • the subtitle read function unit 235 of the subtitle access unit is instructed to use the stream-id and private_stream_id from the next read from the subtitle access unit buffer 215A.
  • the stream_id and private-stream ID provided from the player control module 212 in step S 194 are converted into the stream_id register 266.
  • 3 and private—stream_id register 264 are newly set, respectively, and the next read from buffer 21.5 A will be newly set to its stream_id register 263 and private_stream_id register 264, respectively.
  • the subtitle stream to be reproduced is switched from the currently reproduced subtitle stream to another subtitle stream.
  • the buffer control module The processing of 2 15 (Fig. 3), that is, the writing of data to the buffer 2 15A and the reading of data from the buffer 2 15 A are explained in Fig. 3. As described in the above, there are five pointers for reading and writing data to and from the buffer 2115A.
  • the buffer control module 2 15 stores the data stored in the data head pointer storage section 2 31.
  • the video read pointer stored in the video read pointer storage unit 241, the video read pointer stored in the video read pointer storage unit 241, the audio read pointer stored in the audio read pointer storage unit 2501, and the subtitle read pointer stored in the subtitle storage unit 251 It has a subtitle readout button stored in the storage unit 262.
  • the stream_id register 242 and the au_information () register 243 of the video reading function unit 233 and the stream-id register 234 of the audio reading function unit 234 in FIG. 52 and a private stream-id register 253, and a caption reading function flag storage unit 261, a stream-id register 263, and a private_stream_id register 264 of the subtitle reading function unit 23 are omitted from illustration. is there.
  • the first data pointer stored in the data first pointer storage unit 23 1 is the oldest data remaining in the buffer 215 A (the oldest data that needs to be read and has not been read yet). Day and evening).
  • the data write pointer stored in the data write pointer storage section 232 writes the data to the buffer 215A. This is the location where the newest data will be written in buffer 215A.
  • the video read pointer stored in the video read pointer storage unit 241 indicates the position of the video stream to be read from the buffer 215A.
  • the audio read pointer stored in the audio read pointer storage unit 251 indicates the position of the audio stream to be read from the buffer 215A, and the subtitle read pointer stored in the subtitle read pointer storage unit 262.
  • the pointer indicates the position of the subtitle stream to be read from buffer 215A.
  • the data head pointer, the data write pointer, the video read pointer, the audio read pointer, and the subtitle read pointer all move clockwise through the buffer 215A.
  • the data head pointer points to the position of the most * ⁇ data among the video read pointer, audio read pointer, and subtitle read pointer as shown in FIG. Should always be updated to point to the same location as Here, in FIG. 35, among the video read pointer, the audio read pointer, and the subtitle read pointer, the audio read pointer points to the position of the oldest data, and the data head pointer indicates the oldest data position. Match the audio read pointer.
  • the data write pointer starts from the disk 101.
  • the new data is updated clockwise to point to the position immediately after.
  • the video read pointer, the audio read pointer, or the subtitle read pointer is increased by an amount corresponding to the read amount. Is updated clockwise.
  • the portion corresponding to the read amount includes the portion corresponding to the actually read video, audio, and subtitle data, and the portion included in the read data. In addition, it will be the sum of the day and night parts of the other streams.
  • the data head pointer When the video read pointer, audio read pointer, or subtitle read pointer is updated, the data head pointer indicates the position of the oldest data in the video read pointer, audio read pointer, or subtitle read pointer. It is updated to point to the same location as what it is pointing to.
  • the buffer control module 215 sends the data to the buffer 215A in order to prevent the data write pointer from overtaking the data start pointer when writing the data to the buffer 215A. Control the writing of.
  • the buffer control module 215 reads the data read from the disk 101 into the buffer pointed to by the data write pointer. The data is written to the location A, and the data write pointer is updated. On the other hand, when the data write pointer is about to overtake the data head pointer, the buffer control module 215 instructs the content data supply module 213 to stop reading data from the disk 101 (interruption). ) Is required, and Writing of data to buffer 2 15 A is stopped. As a result, it is possible to prevent the overflow of the buffer 215A.
  • writing data to buffer 215A during the data read from disk 101 is performed only by the positional relationship between the two pointers, the data start pointer and the data write pointer. Is controlled by
  • the buffer control module 21 when reading data from the buffer 215A, has a video read pointer, an audio read pointer, and a subtitle read pointer, and consequently, a data head pointer overtakes a data write pointer. Control the reading of data from buffer 215A so that it does not occur.
  • the buffer control module 215 includes the video decoder control module 216 and the audio decoder control module 215. 17, or in response to a request from the subtitle decoder control module 218, data is read from the buffer 215 A pointed by the video read pointer, audio read pointer, or subtitle read pointer, and the video read pointer, The audio read pointer or subtitle read pointer is updated, and the data start pointer is updated as necessary.
  • the buffer control module 215, the video decoder control module 216, and the audio A request from the video decoder control module 217 or the subtitle decoder control module 218 is frozen, for example, and waited until sufficient data is prepared. As a result, the buffer 2 Can be prevented.
  • the buffer 2 15A has a range from the position indicated by the data head pointer to the position indicated by the data write pointer clockwise (the part shaded in FIGS. 34 and 35). ), Data to be supplied to the video decoder control module 2 16, the audio decoder control module 2 17, and the subtitle decoder control module 2 18 are stored.
  • a video read pointer There is an audio readout pointer and a subtitle readout pointer.
  • the data head pointer is updated to point to the oldest data position among the positions pointed to by the video read pointer, the audio read pointer, or the subtitle read pointer.
  • the update of the start pointer can be performed, for example, so as to point to a position of data that is a predetermined time (for example, one second) from the position of the oldest data.
  • the video read button / audio read button often indicates the position of the oldest data.
  • the data head pointer is updated from the oldest data position pointed to by the video read pointer or the audio read pointer to, for example, one second worth of past data position, as shown in FIG.
  • the audio readout pointer indicates the position of the oldest data.
  • the data head pointer points to the position of the data one second past from that position.
  • the responsiveness of the disk device can be improved by updating the data heading to indicate the position of the data for one second in the past.
  • the data head pointer is updated so that it points to the position of the data L seconds past the position of the oldest data pointed to by the audio read button.
  • the data necessary to start the special playback is the past data for 1 second stored in the buffer 215A. In this case, it is possible to immediately start the trick play without re-reading the data from the disk 101 as described above.
  • the buffer control module 215 The data start pointer, data write pointer, video read pointer, audio read pointer, and subtitle read pointer are all initialized to point to the same position on buffer 215A.
  • the video reading function section 233 parses the program stream stored in the buffer 215A, and the video decoder control module In response to a request from 216, a video stream (video access unit) is extracted (separated) from the program stream stored in the buffer 215A and read out, and the video decoder control module 216 Similarly, the audio read function unit 234 also parses the program stream stored in the buffer 215 A, and in response to a request from the audio decoder control module 217, the buffer 2 15 From the program stream stored in 15A, extract and read the audio stream (audio access unit) Coda Supply to control module 2 17.
  • the subtitle reading function unit 235 also analyzes the syntax of the program stream stored in the buffer 215A, and stores it in the buffer 215A in response to a request from the subtitle decoder control module 218.
  • a subtitle stream (subtitle access unit) is extracted from the program stream, read out, and supplied to the subtitle decoder control module 218.
  • the elementary stream multiplexed with the program stream stored in the clip stream file “00001.PS” is the elementary stream to be reproduced.
  • the program stream is read from the disk 101 and stored in the buffer 215A, in step S122 of FIG. 30, the EP of the clip stream file "00001.PS” is read.
  • 305 sectors are determined as the reproduction start position.
  • the reproduction start position 305 is determined. The sector is specified and the operating The reading of the program stream stored in the clip stream file "00001 • PS" is requested to the Wing system 201.
  • the information about the decoding start possible point described in EPjnapO indicates the position of the PES-packet 0 of private-stream-2 placed immediately before the actual decoding start possible point.
  • step S211 If the video read function unit 233 finds the PES_packet 0 of private_stream_2 in step S211, the process proceeds to step S212, and the PES-packet () of the PES-packet () of the private-stream-2 is data.
  • the PES-packet () of the PES-packet () of the private-stream-2 is data.
  • step S212 when it is determined that private_stream2—video_stream_id described in PES_payload () does not match the stream_id stored in the stream_id register 242, that is, the immediately preceding step S 2 If the PES-packet 0 of private_stream-2 found in 1 1 is not located at the decoding start point of the video stream to be played back, return to step S 2 11 1 and store in buffer 2 15 A. The PES_packet () of another private_stream_2 in the stored program stream is searched, and the same processing is repeated thereafter.
  • step S212 when it is determined that the video_stream_id described in private_stream2_PES_payload () matches the stream_id stored in the stream_id register 242, that is, If the PES_packet 0 of private_stream_2 found in S211 is located at the decoding start point of the video stream to be played, the process proceeds to step S213, where the video read function unit 233 private—stream—PES of stream—packet 0 COpr ivat e_s t ream2_PES_pay 1 aujnformationO described in oadO is read from buffer 2 15 A, stored in au_information () register 243 (FIG. 3), and step S 2 Proceed to 14.
  • step S214 the video reading function unit 233 stores the PES_packet 0 (video_stream_id (FIG. 23)) of the private_stream__2 found in the immediately preceding step S211 in the stream_id register 242 (FIG. 3).
  • the video read pointer stored in the video read pointer storage unit 231 is updated by the size of 1 ⁇ 3 _ ⁇ ) & 1 ⁇ (0) of 01 "16_5 6 & 111-2 matching the stream-id.
  • the video stream (PES_packet.O) of the stream_id that matches the video__stream_id is arranged immediately after the PES-packet 0 of the private_stream_2. Therefore, in step S214, the video read pointer is It is updated to point to the position of the actual decoding start point of the video stream.
  • step S214 the process proceeds from step S214 to S215, and the video readout function unit 233 determines whether or not the data request has been received from the video decoder control module 216. Returning to step S215, the same processing is repeated.
  • step S215 the video decoder control module If it is determined from 2 16 that a data request has been received, the process proceeds to step S 2 16 and the video read function unit 2 3 3 While parsing the program stream, the data of the number of bytes described in AUJength of au_information () stored in au informationO register 243, that is, one video access unit is stored in buffer 215A. And supplies it to the video decoder control module 216, and updates the video read pointer by the size of one video read unit read from the buffer 215A.
  • the au-one informationO is included between the private-stream-2 PES-packet 0 containing it and the next private-stream-2 PES_packet ().
  • Numbe indicates the number of video access units (pictures), and 0 indicates an access_unit.
  • au_information () describes pic_struc, copy, au_re, flag, and AU_length as information on each video access unit as many as the number_o and access_unit. .
  • au_inforiat ionO ⁇ iko number—of—access—unit
  • the number of AUJengths described, as described in FIG. 24, is the PES—packet 0 power of the pri vate—stream—2 that contains it. Since the size of each video access unit of number_o and access_unit included between the PES of the next private—stream—2 and pac ket 0 represents the size of each video access unit, the video read function unit 2 33 3 sets the AUJength to By using this, the access unit can be cut out without parsing the video stream.
  • the program stream stored in the clip stream file recorded on disc 101 is A PES packet () of private-stream_2 in which AU_length indicating the size of the video access unit is described immediately before each of one or more actual decoding start points in the video stream of the data access unit.
  • the video read function 233 based on the AU_length described in the PES-packetO of the private str earn-12, performs the video access unit (from the buffer 215A) without parsing the video stream. (A unit video stream) and supply it to the video decoder control module 216.
  • the video reading function unit 233 when supplying the video access unit to the video decoder control module 216 in step S216, describes au_information () as information about the video access unit.
  • the supplied pic— struct_copy, au_ref_flag, and AlJ_length, and the time stamp (PTS, DTS) added to each video access unit are also supplied to the video decoder control module 216.
  • step S216 one video access unit is read from the buffer 215A, and is supplied to the video decoder control module 216. Then, the process proceeds to step S217, where the video read function unit 23 In step 3, it is determined whether or not the number of access units represented by the number_o access_unit of the au__informationO (FIG. 24) stored in the au_information () registry 243 has been processed.
  • step S217 If it is determined in step S217 that the number of access units equal to the number_o and the number of access_units have not yet been processed, If the number of access units represented by number_of_access_unit has not been read from the buffer 215 A and supplied to the video decoder control module 216 yet, the process returns to step S 215, and the same processing follows. Is repeated.
  • step S 217 when it is determined that the number of access units represented by number_o and access_unit have been processed, that is, the number of access units represented by number_o and access one unit is stored in buffer 2 15
  • the process returns to step S 211, and the next private_stream_2 PES_packet () is searched for, and the same processing is repeated thereafter.
  • step S230 the audio reading function unit 234 stores the stream of the audio stream to be reproduced, which is stored in the stream_id register 252 (FIG. 3) in step S127 of FIG. 30. It is determined whether am-id represents private-stream-1 PES-packet0.
  • step S230 if it is determined that the stream_id stored in the stream_id register 252 does not represent the PES-packet 0 of the privat_stream_l, that is, it is stored in the stream_id register 252. If the stream-id is llOxxxxxB assigned to the audio stream coded according to the MPEG standard, as described in FIG. 20, the process proceeds to step S231 and the audio reading function is performed.
  • the unit 234 is defined by MPEG Audio from the program stream stored in the buffer 215A. Search for a synchronization code indicating the beginning of the audio frame obtained.
  • the audio read function unit 234 Since the position of the synchronization code is at the beginning of the audio frame, the audio read function unit 234 updates the audio read pointer to indicate the position of the beginning of the audio frame, and the steps S231 to S2 Go to 3 2.
  • the audio read function unit 234 matches the stream_id stored in the stream_id register 252 in the program stream stored in the buffer 215A. PES_packet 0 is searched for and found from the position indicated by the audio read-in window, and the process proceeds to step S233.
  • step S233 the audio read function unit 234 finds the audio read pointer stored in the audio read pointer storage unit 251 in the PES—packe found in the immediately preceding step S233. Update the PES of t () to point to the beginning of the PES—packe t—dat a—byte (FIG. 16A and FIG. 16B to FIG. 18A and FIG. 18B), and step S 2 Proceed to 3 7.
  • step S 237 the audio readout function unit 234 determines whether or not a data request has been received from the audio decoder control module 217, and if it determines that there is no data request, returns to step S 237. Repeat the same process.
  • step S 237 If it is determined in step S 237 that the data request has been received from the audio decoder control module 217, the flow advances to step S 238 to read the audio. While parsing the program stream from the position of buffer 2 15 A pointed to by the read-in bus, one known fixed-length audio access unit is read from buffer 2 15 A, and Time stamp (PTS, DTS) added to the audio access unit At the same time, supply it to the audio decoder control module 217. 'Then, the audio read function unit 234 updates the audio read pointer by the size of one audio access unit read from the buffer 215A, returns to step S237, and returns to step S237. Below, the same processing is repeated.
  • PTS Time stamp
  • step S234 the audio reading function unit 234 proceeds to step S235, and the private_streaml_PES which is the PES-packet-data_byte of the PES-packet 0 of the private_stream-1
  • the private—stream_id described in —payload () (FIG. 21) is extracted, and the private—stream_id is used as the private—stream_id register at step S127 in FIG. It determines whether or not it matches the private-stream-id of the audio stream to be played, which is stored in Figure 3).
  • step S235 it is determined that the private_stream_id described in the private_stream and PES-payloadO does not match the private_stream_id stored in the private_stream_id register 253. If That is, if the private_stream—first PES—packet () found in the immediately preceding step S234 is not the audio stream to be played back, the process returns to step S234 and is stored in the buffer 211A. A search for PES_packet () of another private_stream_l in the program stream is performed, and the same processing is repeated thereafter.
  • step S235 it is determined that private_stream-id stored in private_streaml_id and private_stream-id stored in the private_stream-id register 253 are described as private_streaml_PES_payload ().
  • the process proceeds to step S236, and the audio read function unit 234 Is the private—stream-1 PES—packet 0 private—s treaml—PES—payload 0
  • the AUJocator described in (Fig. 21) is read from the buffer 215A, and the position immediately after the AUJocator and the value represented by the AUJocator are added to determine the head position of the audio access unit. . '
  • the AU-locator is based on the position immediately after the AU-locator as a reference, and the audio access stored in the private_st reaml_PES—private_payload () of the pay load 0 is used. Since the start position of the unit (or subtitle access unit) is indicated, the (absolute) start position of the audio access unit is obtained by adding the value indicated by the AUJocator to the position immediately after AU-locator. be able to.
  • step S 236 the audio read function unit 234 further stores the audio read pointer in the audio read pointer storage unit 25 1 so as to point to the head position of the audio access unit determined as described above. Update the audio read pointer and go to step S237. No.
  • step S 237 the audio readout function unit 234 determines whether or not a data request has been received from the audio decoder control module 217, and if not, returns to step S 237. Repeat the same process.
  • step S 237 If it is determined in step S 237 that the audio decoder control module 217 has received the request for overnight, the process proceeds to step S 238, and the audio reading function unit 234 While parsing the program stream from the location of buffer 2 15 A pointed to by the audio read-in window, it parses a single fixed-length audio access unit from buffer 2 15 A. The data is read out and supplied to the audio decoder control module 217 together with the time stamp added to the audio access unit.
  • the audio readout function section 234 updates the audio readout pointer by the size of one audio access unit read out from the buffer 215A, returns to the step S237, and returns to step S237. Below, the same processing is repeated.
  • step S251 the subtitle read function unit 235 sets the subtitle read function flag stored in the subtitle read function flag storage unit 261 in step S127 of FIG. Is determined. If it is determined in step S251 that the subtitle read function flag is 0, that is, for example, the elementary stream to be reproduced is multiplexed. If the caption stream file contains no caption stream and 0 is set in the caption read function flag storage unit 26 1 in step S127 of FIG. 30, the caption read function Part 235 does not perform any processing.
  • step S251 when it is determined in step S251 that the subtitle read function flag is 1, that is, for example, the subtitle stream is included in the clip stream file in which the element list to be reproduced is multiplexed. If 1 is set in the subtitle reading function flag storage unit 261, in step S127 of FIG. 30, the process proceeds to step S252, where the subtitle reading function unit 235 The PES_packet () that matches the stream-id of the subtitle stream to be reproduced, which is stored in the stream_id register 26 3 (FIG. 3), is searched from the program stream stored in the buffer 215A.
  • the stream_id register 2263 (FIG. 3) stores the stream_id of the subtitle stream to be reproduced.
  • step S252 the PES-packetO of the private_stream-11 in the program stream stored in the buffer 215A is searched.
  • step S252 a search for PES_packet () of private.—stream_l is performed, and if a PES—packe of private—stream—1 is found, the process proceeds to step S253, where the subtitle reading function unit 2 3 5 is a private-stream_id described in its private-stream- 1 PES- packet () PES- packet-data-byte private-streaml- PES_pay load 0 (Fig. 21). Unchecked It is determined whether or not the private_stream__id matches the private_stream_id of the subtitle stream to be reproduced, which is stored in the private_stream_id register 264 (FIG. 3) in step S127 of FIG. 30.
  • step S253 private-stream-id described in private-streaml-PES_payload () does not match private-stream-id stored in private-stream-id register 264. If it is determined that the PES_packetO of the private_stream-11 found in the immediately preceding step S 252 is not the subtitle stream to be reproduced, the process returns to step S 252 and is stored in the buffer 2 15 A. The search for PES_packet 0 of the other private stream 11 in the program stream is performed, and the same processing is repeated thereafter.
  • step S253 if it is determined that the private_stream_id stored in the private_streaml-PES_payload () In other words, if PES_packet () of private_stream_l found in the immediately preceding step S 252 is a subtitle stream to be reproduced, the process proceeds to step S 254, and the subtitle reading function unit 2 35 5
  • the PES—packet () private stream is streamed, and the AU—locator described in PES_payload () (FIG. 21) is read from buffer 215A, the position immediately after the AU_locator and the AU_locator.
  • the start position of the subtitle access unit is obtained by adding the value indicated by the locator.
  • the AU-locator accesses the subtitles stored in the private-st reaml-PES-pay load 0 private-payloadO based on the position immediately after the AU-locator. Indicates the start position of the unit (or audio access unit), so the position immediately after the AU locator By adding the value represented by the All ocator to the position, the (absolute) head position of the subtitle access unit can be obtained.
  • the subtitle readout function unit 235 further stores the subtitles stored in the subtitle readout pointer storage unit 262 so as to point to the head position of the subtitle access unit obtained as described above in step S254. Update the read pointer and go to step S255.
  • step S255 the caption reading function unit 235 determines whether or not a data request has been received from the caption decoder control module 218, and if it determines that there is no data request, returns to step S255. Repeat the same process.
  • step S255 If it is determined in step S255 that a data request has been received from the subtitle decoder control module 218, the process proceeds to step S256, where the subtitle read function unit 235 sets the subtitle read pointer While analyzing the syntax of the program stream from the position of buffer 2 15 A pointed to by, one subtitle access unit of the size described at the top of the subtitle access unit is stored in buffer 21. 5A, and supplies it to the subtitle decoder control module 218 together with the time stamp added to the subtitle access unit. That is, the size of the subtitle access unit is described at the top of the subtitle access unit, as described in FIG. 2A and FIG. 2B. The data corresponding to the size is read from the position of the buffer 215 A pointed to by the subtitle read button, and the read subtitle access unit is written together with the time stamp added to the subtitle access unit. The subtitle decoder control module 218 is supplied.
  • the subtitle reading function section 235 reads from the The subtitle readout point is updated by the size of one subtitle access unit issued, and the process returns to step S255, where the same processing is repeated.
  • the decode control module 214 shifts the timing if necessary in order to secure synchronization, and starts decoding by the video decoder control module 216,
  • the audio decoder control module 211 and the subtitle decoder control module 218 are instructed. For example, depending on the progress of the decoding process of the video decoder 116 and the audio decoder 117, the video data is output. And the output of audio data as output data to be output in synchronization with the video data may be shifted.
  • the decode control module 2 14 corrects the difference between the output of the video data and the output of the audio data that should be output in synchronization with the video data.
  • the resynchronization process is performed to output the data synchronously.
  • step S271 the decode control module 216 sets the time stamp of the video access unit from the video decoder control module 216 and the audio control module 2 Determine if the deviation from the audio access unit timestamp from 17 is large. That is, as described in step S129 of FIG. 30, each time the video decoder control module 216 obtains the video access unit from the buffer control module 215, the video decoder unit 216 receives the video access unit. The nick time stamp is supplied to the decode control module 214. Similarly, each time the audio control module 2 17 obtains the audio access unit from the buffer control module 2 15, it supplies the time stamp of the audio access unit to the decode control module 2 14.
  • step S 271 the decode control module 218 receives the same timing from each of the video decoder control module 216 and the audio control module 217 at the same timing (which can be regarded as the same timing. ) Compare the supplied timestamps and determine if the timestamp deviation is large.
  • step S271 it is determined that the difference between the time stamp of the video access unit from the video decoder control module 216 and the time stamp of the audio access unit from the audio control module 217 is not large.
  • the difference between the time stamp of the video access unit and the time stamp of the audio access unit is within a range in which it can be considered that a predetermined synchronization is obtained. For example, in the case of two video frames (approximately 66 milliseconds), the flow returns to step S271, and the determination (monitoring) of a time stamp deviation is continued. .
  • step S271 the time stamp of the video access unit from the video decoder control module 216 and the time stamp of the audio access unit from the audio control module 217 are largely different. Is determined, that is, the video access If the difference between the time stamp of the sunit and the time stamp of the audio access kit is out of the range in which it can be considered that predetermined synchronization is achieved, the process proceeds to step S272 and the decoding is performed.
  • the control module 214 compares the time stamp of the video access unit from the video decoder control module 216 with the time stamp of the audio access unit from the audio control module 217 to obtain video data. It determines which of the output (decode) and the output of the audio data is delayed.
  • step S 272 If it is determined in step S 272 that the output of the video data is behind the output of the audio data, the process proceeds to step S 273, and the decoding control module 2 14 determines that the video access unit has only one video access unit. In order to proceed with the processing of the access unit, an instruction to the video decoder control module 216 not to decode and output (display) the video access unit, that is, the video access unit An instruction to skip processing is output, and the flow advances to step S274. In the chip S 2 74, the video decoder control module 216 receives the skip instruction from the decode control module 214, and responds to the skip instruction together with the video access unit from the buffer control module 215. Check the supplied au_ref-flag (Fig. 24).
  • the au_.information () (Fig. 24) located in the private-stream-2 PES- packet 0 private-stream2- PES-payloadO contains information about the access unit.
  • the au_re flag is included, and the buffer control module 215, together with the video access unit as described in step S129 of FIG. 30 and step S216 of FIG. 36, The au ref flag for that video access unit Supply to the video decoder control module 216.
  • step S274 the au_re flag of the access unit thus supplied together with the access unit is inspected.
  • step S275 the video decoder control module 216 determines the au_recheck flag of the video access unit supplied from the buffer control module 215 based on the result of the inspection. Then, it is determined whether or not the video access unit is a non-reference image that is not referred to in decoding another picture.
  • au—re fl ag of the video access unit indicates whether the access unit is a reference image, and is 1 when the access unit is a reference image. If it is not a reference image, that is, if it is a non-reference image, it is set to 0.
  • step S275 when it is determined that the video access unit supplied from the buffer control module 215 is not (a video access unit of) a non-reference image (that is, the video access unit supplied from the buffer control module 215), If the obtained video access unit is a reference image, the process proceeds to step S276, where the video decoder control module 216 causes the video access unit to process the video access unit as usual. Wait for the next video access unit to be supplied from the buffer control module 215, and return to step S274.
  • step S275 If it is determined in step S275 that the video access unit supplied from the buffer control module 215 is a non-reference image, the process proceeds to step S277, where the video decoder control module 16 skips the processing by the video decoder 1 16 of the video access unit, waits for the next video access unit to be supplied from the buffer control module 2 15, and proceeds to step S 27 1 Return to
  • step S272 when it is determined that the output of the video data is not behind the output of the audio data, that is, the output of the audio data is behind the output of the video data. If so, the process proceeds to step S 278, where the decode control module 216 sends the currently decoded video to the video decoder control module 216 in order to wait for the processing of the video access unit. An instruction to repeatedly output video data corresponding to the access unit is output, and the flow advances to step S279.
  • step S279 the video decoder control module 216 receives the instruction of the repetitive output from the decode control module 214, and in accordance with the instruction of the repetitive output, the video decoder 116 now decodes. It repeats the video data corresponding to the video access unit being output to the graphics processing module 219, and waits for the next video access unit to be supplied from the buffer control module 215. Return to step S27.
  • the decoding control module r2 14 determines whether or not the video data output is behind the audio data output, and the video data output is more than the audio data output. If it is late, it instructs the video decoder control module 216 to skip processing of one access unit. And video decoder control Module 2 16 determines whether the access unit is a reference image or a non-reference image based on the au-re fl ag of the access unit instructed to skip, and determines whether the access unit is a non-reference image. In some cases, it causes the video decoder 1 16 to skip processing of the access unit instructed to skip. Therefore, the output of the video data and the output of the audio data can be easily synchronized.
  • the access unit whose processing is to be skipped is a reference image
  • the video data corresponding to the access unit needs to be decoded to refer to when decoding another access unit that is subsequently decoded.
  • the access unit processing of the reference image is skipped, other access units that refer to the reference image are decoded.
  • the synchronization control appears as noise in the video data display.
  • the video access unit has PES_packet_da — by te PES — packet t 0 (first 6 A and FIG. 16 B to FIG. 18 A and FIG. 18 B) are separate from the PES_packet t dat a by te pri iva testr eara2 PES_pay l oad 0 (second The PES_packet 0 of private-stream-2 where the 3) is located is multiplexed, and the au-information 0 (Fig. 24) of the private-stream2-one PES_payload () is assigned to each video access unit.
  • Au_ref_flag indicating whether the video access unit is a reference image or a non-reference image is described. Then, the au flag is supplied from the buffer control module 215 to the video decoder control module 216 together with the corresponding video access unit.
  • the video decoder control module 2 16 can determine, at little cost, whether the video access unit is a reference image or not. Alternatively, it can be recognized whether the image is a non-reference image.
  • the decode control module 214 constantly checks the current time measured by the built-in clock unit 214A.In step S301, the current time is set to Pl.ayListMarkO (Fig. 7). It is determined whether or not it matches the mark_time_stamp of any of MarkO described in).
  • the player control module 2 12 transmits the first PyItem # 0 of the first PyList # 0 shown in FIG.
  • four MarkOs from the first to the fourth of the seven Marks 0 included in P1 ayListMarkO shown in the upper part of Fig. 28 are added to the first PlayItem # 0 of PlayList # 0. Recognizing that they belong, the four MarkO's mark—time sta is ⁇ 180, 090 ⁇ , ⁇ 5,580,090 ⁇ , ⁇ 10, 980, 090 ⁇ , ⁇ 16, 380, 090 ⁇ are replaced by the decode control module 2 14 with the indication that the attribute of the time represented by the mark—time—s mp is “mark processing”. Has passed.
  • step S301 the decoding control module 214 determines whether the current time is one of the times (mark-time_stainp) of the attribute of “mark processing” supplied from the player control module 212 as described above. It is determined whether or not they match.
  • step S301 If it is determined in step S301 that the current time does not match any of the times of the attribute of "mark processing", the process returns to step S301, and the same processing is repeated.
  • step S301 If it is determined in step S301 that the current time matches one of the times of the attribute of “mark processing”, the decode control module 214 determines that the current time has the attribute of “mark processing”. Is supplied to the player control module 2 12, and a message indicating that the time has arrived and the time of the attribute of “mark processing” that matches the current time are supplied to the player control module 2 12, and the flow advances to step S 302.
  • step S302 the player control module 2 12 sends a message indicating that the current time has become the time of the attribute of “mark processing” and the time of the attribute of “mark processing” that matches the current time (mark —Time—stamp) is received from the decode control module 214, and the MarkO whose mark—time—sta immediately matches the current time is the target of the mark processing (hereinafter referred to as the processing target as appropriate). mark).
  • the player control module 211 recognizes PlayltemO of PlayList 0 that is currently being played. 1 & 1 ⁇ 3) 1 & 1 6111 0 and the time of the attribute of “mark processing” from the decode control module 2 14 that matches the current time (mark time stamp) Then, the target mark is recognized by referring to the PlayList MarkO (FIG. 7) of the “PLAYLIST.DAT” file (FIG. 5). Specifically, for example, assuming that the first PlayItem # 0 of the first PlayList # 0 shown in FIG. 25 is being played back, the player control module 2 12 It recognizes that the time is immediately one of the four MarkOs from the first to the fourth of the seven MarkOs included in the PlayListMarkO shown in the upper part of FIG. 28.
  • the player control module 2 1 2 has the P1 ayListMarkO shown in the upper part of FIG. Among the four MarkOs from 1st to 4th included in, the fourth MarkO whose mark_time_stamp matches the mark time of 16, 380, 090 is recognized as the processing target mark.
  • step S302 the process advances from step S302 to S303 to specify the elementary stream in the processing target ma rk entry_ES_stream_id And entry—ES_private—stream—id (Fig. 7) are determined.
  • step S303 it is determined that entry-ES-stream-id and entry-ES-private-stream-id (Fig. 7) that specify the element list are not described in the mark to be processed. If the entry is ES_str earn—id and entry—ES—private—stream—id are both 0x00, skip step S304 and proceed to step S305. Processing according to the processing target mark is performed.
  • step S303 the elementary mark is added to the mark to be processed. If it is determined that the entry_ES—stream—id and entry—ES—private—sstream_id (FIG. 7) that specify the stream are described, the process proceeds to step S304, and the player control module 211 Then, it is determined whether or not the elementary stream being reproduced contains the entry_ES_stream_id and, if necessary, the elementary stream specified by the entry_ES_private_stream_id.
  • step S304 it is determined that the elementary stream being reproduced does not include the elementary stream identified by the entry-ES-stream-id and entry-ES-private_stream-id of the mark to be processed. If so, the process returns to step S301. That is, if the elementary stream specified by the entry_ES-stream_id and entry_ES-private-stream-id of the mark to be processed is not being reproduced, the mark to be processed is ignored, while the reproduction is performed in step S304.
  • processing target is determined to be valid. The corresponding processing is performed.
  • step S305 the player control module 2 12 determines the mark to be processed by referring to markjype (FIG. 7) of the mark to be processed.
  • step S305 If it is determined in step S305 that the mark to be processed is a cap mark or an index mark, that is, if the mark type of the mark to be processed is 'Chapter' or 'Index', step S 3 0 Proceeding to 6, the player control module 2 12 instructs the graphics processing module 2 19 to display the caption or index number to the caption or index represented by the caption mark or index mark to be processed. Update the index number and return to step S301.
  • step S305 If it is determined in step S305 that the mark to be processed is an event mark, that is, if the mark_type of the mark to be processed is 'Ev ent', the process proceeds to step S307 and the player proceeds to step S307.
  • the control module 211 notifies (supplies) the event message indicating the occurrence of the event and the mark_data of the processing target mark to the script control module 211, and proceeds to step S308.
  • step S308 the script control module 211 receives the event message and mark_data from the player control module 212, and sets the event message as an interrupt request in advance in the "SCRIPT.DAT" file. A series of processes described is performed using mark-data as an argument, and the process returns to step S301.
  • the second MarkO (Mark # l) and the third MarkO (ark # 2) are both mark_type Is 'Event', but mark_data is different between 1 (Mark # l) and 2 (Mark # 2), respectively.
  • the scribing control module 2 1 1 receives the event message corresponding to the second MarkO and the event message corresponding to the third MarkO in both cases.
  • event handler interrupt handling routine
  • different processing is performed for each mark data for the event message.
  • the script control module 211 controls the graphics processing module 219 to display the first type of icon.
  • the script processing module 211 controls the graphics processing module 219 to display the second type of icon.
  • mark-data is not limited to 1 or 2
  • the processing performed in response to mark_data is not limited to the display of a simple icon as described above.
  • mark_data is a value in the range of 3 to 18
  • the script control module 211 controls the graphics processing module 219 to display the first type of icon from mark_data.
  • the brightness is adjusted to the value obtained by subtracting 2 (a numerical value from 1 to 16).
  • the scribing control module 211 controls the graphics processing module 219 to display the second type of icon.
  • Mark1 data is subtracted by 18 (a numerical value from 1 to 16).
  • a controller operated by the user is connected to the input interface 115 (Fig. 1), and the controller eccentrically moves the DC (Direct Current) motor to the axis.
  • the DC Direct Current
  • a built-in vibration motor that generates vibration when the DC motor is operated is installed, when the mark-data is in the range of 35 to 42, the vibration motor is subtracted from mark_data by 34. Operating time according to the value (number from 1 to 8) Can work.
  • mark_data is a numerical value, and its usage and algorithm can be described by a script program executed by the script control module 211. Therefore, mark-data is used in accordance with a predetermined rule, and is a rule set by the manufacturer of the disc 101 or a content provider that provides data recorded on the disc 101. It is possible to use it.
  • the mark to be processed is recognized from the mark time which is the time of the attribute of the “mark processing”. Furthermore, if entry-ES_stream-id and entry_ES-private_stream-id that specify an elementary stream are not described in the mark to be processed, processing according to the mark-type of the mark to be processed is performed. . Further, even if entry_ES_stream-id and entry-ES_private-stream_id for specifying an elementary stream are described in the processing target mark, the entry_ES_stream-id and entry-ES-private-stream-id are described. If the elementary stream specified by is being reproduced, the processing corresponding to the mark-type of the processing target mark is performed.
  • the second PlayList # l shown in FIG. 25 is being reproduced, the following mark processing is performed. That is, in the PyListMarkO of the second PlayList # l, as shown in the lower part of FIG. 28, the mark-time-stamp is specified as 90, 000, 27, 090, 000, 27,540,000, respectively. The first 3 ⁇ 4 ⁇ () (3 ⁇ 41 &# 0), the second MarkO (Mark # l), and the third MarkO (Mark # 2) are described. Further, in the PlayListMarkO at the bottom of FIG. 28, the entry—ES stream id of the second Mark 0 and the third MarkO includes OxEO and Ox, respectively. Since El is described, the second MarkO and the third MarkO are associated with elementary streams whose stream_id is specified by OxEO and OxEl, respectively.
  • a video stream stream # 0 whose stream_id is OxEO and multiplexed with the clip stream file "00003.PS" is included.
  • the third MarkO is associated with a video stream stream # l multiplexed in the clip stream file “00003.PS” and having a streamjd of OxEl.
  • the player control module 2 1 2 8 Recognize that the three MarkOs included in the PlayListMarkO shown in the lower part of the figure belong to PlayList # 0 of PlayList # 1, and the mark-time_s tamp of the three MarkOs is ⁇ 90,000 ⁇ , ⁇ 27,090,000 ⁇ , ⁇ 27,540,000 ⁇ , and the attribute of the time represented by the mark time stamp is " The mark processing is passed to the decode control module 214.
  • the decoding control module 216 sets the current time measured by the timer 224A during the reproduction of PlayItem # 0 of PlayList # l to the time ⁇ 90, 000 ”having the attribute“ mark processing ”. ⁇ , ⁇ 27, 090,000 ⁇ , ⁇ 27, 540, 000 ⁇ , it is always checked whether it matches (Step S301), the current time is set, and the attribute is "mark processing". When the time coincides with the current time, a mark time, which is the time of the attribute of “mark processing” that matches the current time, and a message indicating that the current time has become the time of the attribute of “mark processing” are transmitted to the player. Supply to control module 2 1 2.
  • the decode control module 2 14 calculates that the mark time 27,090,000, which is the time of the “mark processing” attribute that matches the current time, and that the current time is the time of the “mark processing” attribute To the player control module 2 12.
  • the player control module 2 12 recognizes that PlayItem # 0 of PlayList # l is currently being played, and the PlayList # 1 shown in the lower part of FIG. Of the MarkO described in 1 ⁇ 51 Mark ⁇ 0, the mark_time_stamp of three MarkOs belonging to PlayItem # 0, 90, 000, 27, 090, 000, 27, 540, 000, respectively, and the decode control module By comparing the mark time 27,090,000 from 2 14 with the mark time 27,0 90,000, Mark () whose mark-time_sta immediately matches the mark time, that is, the lower mark in FIG.
  • the second MarkO (Mark # l) described in PlayListMarkO is recognized as a mark to be processed (step S302).
  • OxEO is specified as entry_ES__stream_id.
  • the entry_ES_stream_id of OxEO is multiplexed with the clip stream file “00003.PS” and the video stream stream # 0 of which stream_id is OxEO (see FIG. 26A and FIG. 6 Figure B), and the player control module 2 12 determines whether or not the video stream stream # 0 is included in the elementary stream being played (step S3). 0 3, S 304).
  • step S304 If the video stream stream # 0 is not included in the elementary stream being reproduced, the mark to be processed is ignored (step S304).
  • the processing target mark is determined to be valid, and the processing according to the processing target mark is performed (step S3). 05 to S308).
  • the second MarkO described in the PlayList MarkO at the bottom of FIG. 28, which is the processing target mark is an event mark because its mark-type is set to 'Event'.
  • the player control module 211 supplies the script control module 211 with the event message indicating the occurrence of the event and the mark—data of the mark to be processed (steps S305, S307).
  • an event message from the player control module 212 is used as an interrupt request, and a series of processing described in advance in the 'SCRIPT. DAT' file is executed together with the event message.
  • the supplied mark—data is used as an argument (step S308).
  • one on the time axis of PlayListO PlayListMarkO (Fig. 7) having 0 or more Mark () including mark_time-sta immediately indicating the playback time of the mark, mark-ty pe indicating the type of MarkO, and mark_data as an argument of the event mark 0 (FIG. 5), it is determined whether or not the current time, which is the playback time of the clip stream file being played back, matches mark-tinie_sta immediately. If it matches, MarkO having mark—time_sta immediately equal to the mark time that is the matching current time is recognized as the mark to be processed.
  • mark_type of the mark to be processed indicates the type of generating the event, that is, when the mark to be processed is an event mark, the mark-data and the event message of the mark to be processed are Is notified, and processing according to the mark-data is executed. Therefore, according to the playback time of the clip stream file, it is possible to execute processing corresponding to mark_data.
  • step S12′6 of FIG. 30 the details of the output attribute control processing performed in step S12′6 of FIG. 30 will be described.
  • the player control module 2 1 2 for each of the one or more elementary streams to be reproduced, that is, for each of the one or more elementary streams determined to be reproduced in step S 125 of FIG. Investigate the number of DynamicInfoO (Fig. 13) in which the output attribute is described (Fig. 13)-Dynamiclnfo (Fig. 10).
  • the player control module 2 12 If number_o and Dynamiclnfo are 0 for all of one or more elementary streams to be reproduced, the player control module 2 12 does not perform any processing. On the other hand, if the number—of—Dynamiclnfo of the elementary stream to be played back is not 0, the player control module 2 12 performs output attribute control processing according to the flowchart in FIG.
  • FIG. 26A and FIG. 26B three clip information files “00001. CLP”, “00002. CLP”, and “00003. CLP” recorded on the disc 101 are, for example, shown in FIG. 26A and FIG. 26B.
  • the clip stream file "00001.PS” (the first PlayList # 0 of the first PyList # 0 to play) corresponding to the clip information file "00001.CLP" is At the time of playback, the four elementary streams streani # 0 multiplexed in the clip stream file "00001.PS" are included in the clip information file "00001.CLP" (Fig. 26A and Fig. 26B). In all of stream # 3, the number_o and Dynamiclnfo are 0, so the output attribute control processing is not performed.
  • step S320 the player control module 2 12 writes the information into the clip information file ClipO (FIG. 10) corresponding to the clip stream file to be reproduced.
  • the decoded pts-change_point is passed to the decode control module 2 14 together with the time of the attribute of “DynamicInfo 0 processing”, and the decoded control module 2 14 sends the “DynamicInfo ( ) Processing ”, the time pts—change—point, which is the attribute time, is received, and the process proceeds to step S321.
  • step S321 the decode control module 214 sets the current time measured by the timer 214A to pts—change one point (one of the points) of the attribute of the “DynamicInfo () process”. It is determined whether or not they match, and if it is determined that they do not match, the process returns to step S321.
  • step S321 if it is determined that the current time matches (any one of) the attributes of the “DynamicInfo () process”, the decode control module 214 determines that the current time is “DynamicInfoO”.
  • the message indicating that the time of the attribute of the process J has been reached and the time of the attribute of the “DynamicInfoO process” that matches the current time (hereinafter, appropriately referred to as Dynamiclnfo time) are supplied to the player control module 212. Then, the process proceeds to step S3222.
  • step S3332 the player control module 212 sends a message indicating that the current time has become the time of the attribute of "DynamicInfo () processing".
  • the Dynamiclnfo time are received from the decode control module 214, and the DynamicInfoO set with pts—change—point (FIG. 10) that matches the Dynamiclnfo time is the Dynamiclnfo 0 to be processed. Recognize it as DynamicInfoO to be processed, and proceed to step S323.
  • step S 323 the player control module 2 12 sends the output attribute described in DynamicInfoO (FIG. 13), which is the processing target DynamicInfoO, to the graphics processing module 2 19 or the audio output module 2 2 1 And proceed to step S324.
  • DynamicInfoO FIG. 13
  • step S324 the graphics processing module 219 or the audio output module 221 sends the video or audio data according to the output attribute supplied from the player control module 212 in the immediately preceding step S323. Control of the output is started, and the process returns to step S321.
  • video data is described as an output attribute (display method), for example, output according to the aspect ratio
  • audio data is described as an output attribute (output method), for example, stereo.
  • output according to dual Natural Language
  • FIG. 42 shows a set of pts—change—point and Dynamiclnfo 0 described in the clip information file “00003. CLP” in FIG. 26A and FIG. 26B (FIG. 10). Is shown.
  • Fig. 42 shows two sets of pts-change-point and Dynamiclnfo 0 describing the first video stream stream # 0 of the clip stream file "00003.PS", and the lower part of Fig. 42 The side shows three sets of pts-change_point and DynamicInfoO described for the third audio stream stream # 2 of the clip stream file "00003.PS".
  • step S125 of FIG. 30 in the clip stream file "00003.PS", the first video stream stream # 0 specified by the stream ID of OxEO, It is assumed that the third audio stream stream # 2 specified by the stream_id of OxBD and the private_stream_id of 0x00 has been determined as a stream to be reproduced.
  • the player control module 2 1 2 includes two sets of pts—change—point and DynamicInfo in the upper part of FIG. 42 that describe the video stream stream # 0 specified by the stream—id, which is OxEO. (), OxBD stream-id and 0x00 private st Investigate the pts_change_point in the three sets of pts-change-point and Dynamicl nfo () at the bottom of Fig. 42 describing the audio stream stream # 2 specified by the ream-id, and set the initial value. recognize.
  • pts- change—point is 90,000.
  • the time of 90,000 corresponds to the clip information file “00003.A” in FIGS. 26A and 26B corresponding to the clip stream file “00003.PS” in which the video streams are multiplexed.
  • this time coincides with the time 90,000 described in present at ion—start one time, which indicates the start time of the clip stream file “00003.PS”.
  • the three sets of pts-change-point in the lower part of Fig. 42 describing the audio stream stream # 2 specified by the stream-id of OxBD and the private_stream_id of 0x00 are described.
  • the first set of DynamicInfoO, the pts_change—point is 90,000.
  • the time of 90,000 corresponds to the clip information file “000 03.CLP of FIGS. 26A and 26B corresponding to the clip stream file“ 00003.PS ”in which the audio stream stream is multiplexed. "Present at the beginning of the clip stream file" 00003.PS ", which matches the time 90,000 described in the" present ation_star "time.
  • the player control module 2 1 2 sets the pts—change—point corresponding to the time 90,000 described in present ation—star and time, which indicates the start time of the clip stream file “0 0003. Recognize as a value. Therefore, the two sets of pts—change—point and Dyna The pts-change_point of the first set of micInfoO and the pts_change_point of the three sets of pts-change-point and DynamicInfoO shown in the lower part of Fig. 42 are recognized as the initial values.
  • the player control module 211 sets the pts_change_point recognized as the initial value. Indicate the output attribute of the corresponding elementary stream according to the DynamicInfoO in question.
  • the initial value is 90,000 at the bottom of FIG.
  • the channel—ass ignment is “Dual.”
  • the player control module 2 1 2 uses the channel—assignment Is supplied to the audio output module 221, that is, the information indicating that the audio stream is “Dual”, that is, the audio stream stream # 2 is dual audio data.
  • step S126 of FIG. 30 the output attribute control processing for pts change—point as the initial value as described above is performed. Thereafter, the player control module 2 1 2 sends the two pts—change_points 90, 000 and 54, 090, 000 on the upper side of FIG. 42 for the video stream stre am # 0, and the second for the audio stream stream # 2.
  • Times other than the initial value of 90,000 out of the three pts-change_points 90, 000, 27,090,000 and 32,490,000 at the bottom of the figure ⁇ 27,090,000 ⁇ , ⁇ 32,490,000 ⁇ and ⁇ 54, 090, 000 ⁇ are passed to the decode control module 214 with the time of the attribute of "DynamicInfo () processing" (step S320).
  • the decode control module 2 14 receives the time ⁇ 27, 090, 000 ⁇ , ⁇ 32, 490, 000 ⁇ , ⁇ 54, 090, 000 ⁇ of the attribute of “DynamicInfo () processing” from the player control module 2 1 2. After the playback of the video stream stream # 0 and the audio stream stream (playback of PlayItem # 0 of the second PlayList # l that plays back the clip stream file "00003.PS"), Open monitoring of the current time as measured by part 2 14A.
  • the decoding control module 2 14 sets the time when the current time matches one of the time ⁇ 27,090,000 ⁇ , ⁇ 32,490,000 ⁇ , ⁇ 54,090, 0000 ⁇ of the attribute of “Dynami clnfoO processing”. Then, the Dynamiclnfo time, which is the time of the attribute of “DynamicInfoO processing” that matches the current time, is supplied to the player control module 2 12 (step S 3 21).
  • the decode control module 214 matches the current time of the attribute of “DynamicInfo () processing” with the current time of 27,090,000. Is supplied to the player control module 212 as Dynamiclnfo time.
  • the player control module 2 1 2 is the decode control module 2 14 27,090,000 at 1 ⁇ 1 ⁇ 1111 (: 11 ⁇ 0 time from the video stream # 0, and the two pts-change-point and The pts_change_point that matches the Dynamic Info time of 27,090,000 is examined from among the three pts_change_points shown in the lower part of Fig. 42 for stream # 2, and matches the 27,090,000.
  • pts_change Recognizes DynamicInfo () that is set with point, that is, the second Dynamic Info 0 in the lower part of FIG.
  • step S32 When the processing target DynamicInfoO is a Dynamiclnfo () for a video stream, the player control module 2 12 supplies the output attribute described in the processing target Dynami clnfoO to the graphics processing module 2 19 (step S 32 3). If the processing target Dynamiclnf ⁇ is DynamicInfoO for an audio stream, the player control module 2 1 2 supplies the output attribute described in the processing target DynamicInfoO to the audio output module 221 (step S 3 2 3).
  • the graphics processing module 219 Upon receiving the output attribute from the player control module 212, the graphics processing module 219 starts controlling the output of the video data in accordance with the output attribute (step S324).
  • the graphics processing module 219 may, for example, indicate an aspect ratio of video data represented by an output attribute from the player control module 211 (display-aspec and ratio (FIG. 13)).
  • the aspect ratio of video data output to the video output module 220 is converted based on the aspect ratio of the video output device connected to the video output terminal 120 in FIG. .
  • the aspect ratio of the video output device is 16: 9
  • the graphics processing module 219 sends the video output module 220 to the video output module 220.
  • the output video data is squeezed in the horizontal direction and output with blackness on the left and right.
  • the aspect ratio of the video output device is 4: 3 and the indication of the aspect ratio of the video data as the output attribute indicates a 16: 9 aspect ratio
  • the graphics processing module 219 squeezes the video data to be output to the video output module 220 in the vertical direction, and outputs the video data with blackness at the top and bottom.
  • the graphics processing module 219 outputs the video data to be output to the video output module 220 without any squeezing processing.
  • the graphics processing module 219 outputs the time 54 to the time 54 from the time 90,000. Up to just before 090,000, the video stream with the 4: 3 aspect ratio obtained from the video stream stream # 0 The video data is supplied as is to a video output device with a 4: 3 aspect ratio and displayed.
  • video data with an aspect ratio of 16: 9 obtained from the video stream stream # 0 is squeezed in the vertical direction, and the top and bottom are darkened.
  • the video signal is converted to a 4: 3 aspect ratio video signal and supplied to a 4: 3 aspect ratio video output device for display.
  • the audio output module 221 starts controlling the output of the audio data according to the output attribute (step S 324).
  • the audio output module 221 includes, for example, an instruction for channel assignment of audio data represented by an output attribute from the player control module 221 (channel l-as-signment (FIG. 13)).
  • the audio decoder control module 2 1 based on the audio output mode supplied from the player control module 2 12 via the input interface 115 (FIG. 1). Processes the audio data from 7 and outputs it to audio output terminal 1 2 1 (Fig. 1).
  • the instruction for channel assignment of the audio data represented by the output attribute indicates that the left channel is the audio data of the “main audio” and the right channel is the audio data of the “sub audio”.
  • the audio output module 221 processes the audio data from the audio decoder control module 217 according to the audio output mode supplied from the player control module 221. Output to the audio output terminal 1 2 1. That is, for example, “main voice” is specified as the voice output mode.
  • the audio output module 221 copies the audio data of the left channel of the audio data from the audio decoder control module 217 as audio data of the right channel
  • the audio output module 221 copies the left channel audio data.
  • the right channel audio data (“main audio” audio data) is output to the audio output terminals 1 2 1.
  • the audio output module 221 When “sub-audio” is specified as the audio output mode, the audio output module 221 outputs the audio data of the right channel of the audio data from the audio decoder control module 217. The evening is copied as the left channel audio data, and the left channel and right channel audio data (“sub-audio” audio data) are output to the audio output terminals 12 1. Further, when “main / sub” is specified as the audio output mode, the audio output module 221 receives the audio data from the audio decoder control module 217 as it is, and outputs the audio data to the audio output terminal. Output to 1 2 1.
  • the audio output module 221 is supplied from the player control module 221 Regardless of the audio output mode, the audio data from the audio decoder control module 217 is output directly to the audio output terminal 121.
  • the audio output output module 22 1 starts from the time 90, 000, and immediately before the time 27, 090,000, from the audio stream stream.
  • the left channel audio data of the obtained dual audio data is copied as right channel audio data, and the left channel and right channel audio data are output to the audio output terminal 122.
  • stereo audio data obtained from the audio stream stream # 2 is output to the audio output terminal 121 as it is.
  • the audio data of the left channel of the dual audio data obtained from the audio stream stream # 2 is copied as the audio data of the right channel, and the audio data of the left channel is copied.
  • the audio data of the channel and the right channel are output to audio output terminals 1 2 1.
  • the playback time of the elementary stream being played back is pts— change— poi It is determined whether or not nU matches.
  • the Dynami cInfo set with the pts-change_point is recognized, and the recognized Dynami c Info O
  • the output of the elementary stream being reproduced is controlled in accordance with the output attribute included in. Therefore, it is possible to control the output of the elementary stream in accordance with the playback time and output attribute of the elementary stream.
  • the player control module 2 1 2 in step S 3 4 4 1 Initializes the subtitle data display method instruction. That is, the player control module 211 controls the graphics processing module 219 so that the display method of the subtitle data is set to the default display method. Note that the initialization of the display method instruction performed in step S3401 corresponds to the initialization of the display method instruction described in 127 of FIG.
  • step S3 41 the process proceeds to step S3 42, in which the player control module 2 12 transmits the subtitle data from the input interface 1 15 by the user operating the remote controller. For the display of, it is determined whether or not a new display method has been instructed.
  • step S334 If it is determined in step S334 that a new display method has been instructed, the process proceeds to step S334, where the player control module 212 reproduces the subtitle stream (the corresponding subtitle data) at the present time. Doing Is determined.
  • step S343 If it is determined in step S343 that the subtitle stream is not being reproduced, the process returns to step S342.
  • step S343 If it is determined in step S343 that the subtitle stream is being reproduced, the process proceeds to step S345, where the player control module 212 sends a new display method instruction to the default display method instruction. Is determined. If it is determined in step S343 that the instruction for the new display method is the instruction for the default display method, the process returns to step S341, and as described above, the player control module 2 12 The graphics processing module 219 is controlled so that the subtitle data display mode is set to the default display mode.
  • step S345 if it is determined in step S345 that the instruction for the new display method is not the instruction for the default display method, that is, the instruction for the new display method is, for example, display by enlarging or reducing subtitle data
  • the instruction is a non-default display method such as changing the brightness or changing the brightness so as to make it easier to see
  • the process proceeds to step S346, and the player control module 2 1 2 multiplexes the currently reproduced subtitle stream.
  • the currently playing subtitle stream from the StaticInfoO (FIG. 12) of the clip information file Clip 0 (FIG. 10) corresponding to the clip stream file that has been played, and the process proceeds to step S347. .
  • step S347 the player control module 211 determines the configurable flag of the StaticInfoO acquired in step S346.
  • the conf igurable_flag does not permit the change of the display method of the subtitle data. If it is determined that the value is 0, the process proceeds to step S348, and the player control module 2 1 2 By controlling the EXS processing module 219, an error message indicating that the display format of the subtitle data cannot be changed is overlaid on the output video data, and the process returns to step S3422. As a result, an error message is displayed.
  • step S347 if it is determined in step S347 that conf igurab l ej g is set to 1 indicating that the change of the display method of subtitles is allowed, the process proceeds to step S349.
  • the player control module 2 1 2 supplies the new display mode instruction supplied from the input interface 1 15 by the user operating the remote controller to the graphics processing module 2 19, and the step S 3 Go to 50.
  • step S 350 the graphics processing module 219 supplies the caption data supplied from the caption decoder control module 218 to the caption data supplied from the player control module 221 in the immediately preceding step S 349.
  • processing such as enlargement or reduction or change in brightness is started according to the instruction of the display method, and the process returns to step S3422.
  • the caption data is displayed in a display size, a display position, a display color, and the like according to the display method instructed by the user operating the remote controller.
  • step S 3 42 determines whether or not the transfer of ayl tem O has been performed. If it is determined that the transfer has not been performed, the process returns to step S 3 42. '
  • step S 351 If it is determined in step S 351 that the transfer of the playlist has been performed, the process returns to step S 341, and as described above, the player control module 2 12 Control the graphics processing module 219 so that the default display method is used as the default display method To do. That is, in this case, when the transfer of PlayltemO is performed, the display method of the subtitle data is returned to the default display method.
  • the display method of the subtitle data corresponding to the subtitle stream is changed. For example, it is changed according to a display mode instruction input by the user operating the remote controller.
  • the configurable-ag of the subtitle stream stream # 2 which is the third elementary stream of the four elementary streams, is set to 0 indicating that the display method cannot be changed. Even if the user operates the remote control to change the subtitle display while the subtitle stream stream # 2 is displayed, the display is not changed.
  • the configurable —flag of the subtitle stream stream # 3, which is the fourth elementary stream among the four elementary streams multiplexed in the clip stream file “00001.PS”, is displayed as
  • the value is set to 1 to allow the change of the method.
  • the display size of the subtitles is changed.
  • the clip stream file “00001.PS” is being reproduced according to the first P1 ayltem # 0 of the first PlayList # 0 in FIG.
  • the third and fourth subtitle streams are subtitle streams, and the third subtitle stream stream # 2 and It is assumed that, for example, the third one of the subtitle streams stream # 3 is currently being reproduced.
  • the display method instruction is transmitted from the input control interface 115 (FIG. 1) to the player control module 2. Supplied to 1 2.
  • the player control module 211 searches for the StaticInfoO (FIG. 10) corresponding to the subtitle stream being reproduced from the clip information file (step S 346, in this case, The subtitle stream being reproduced is the third subtitle stream stream # 2 multiplexed in the clip stream file “00001.PS”, and the player control module 2 1 2 transmits the corresponding clip information file “00001”.
  • CLP "to find a StickInfoO for the third subtitle stream stream # 2.
  • the player control module 2 12 is set to 0 as described in Static Info () of the third subtitle stream stream # 2 in FIG. 26A and FIG. 26B.
  • the configurable flag is determined (step S347), and as a result, it is recognized that the change of the display method is not permitted for the third subtitle stream stream # 2.
  • the player control module 212 determines that the subtitle stream being reproduced (caption data corresponding to) does not support scaling, etc., and controls the graphics processing module 219 to determine An error message to that effect is generated (step S348), and the video data Overlay in the evening and output.
  • the third subtitle stream of the third subtitle stream stream # 2 Of the four elementary streams multiplexed into the clip stream file “00001.PS” and the third subtitle stream of the fourth subtitle stream stream # 3
  • the player control module 2 1 2 which has been supplied with the display method instruction by the user operating the remote control, Then, from the corresponding clip information file "00001. CLP", find out Static Info 0 for the fourth subtitle stream stream # 3.
  • the player control module 2 1 2 has a configurable value of 1 described in Static Info () for the fourth subtitle stream stream # 3 in FIGS. 26A and 26B. —Flag is determined (step S347), and thereby, it is recognized that the change of the display method is permitted for the fourth subtitle stream stream # 3.
  • the player control module 2 1 2 determines that the subtitle stream '(corresponding to the subtitle data) being reproduced corresponds to enlargement / reduction, etc., and is supplied by the user operating the remote controller.
  • the indication of the display method is supplied to the graphics processing module 219 (step S349).
  • the graphics processing control module 219 then enlarges or reduces the caption data from the caption decoder control module 218 according to the display method instruction from the player control module 221 and performs video processing. Overlays the video data from the decoder control module 216 and outputs it.
  • the player control module 2 12 sends the first Play 11 em 0 of PlayListO to the graphics processing module 2 19 at the start of playback.
  • the instruction for the display method of the subtitles is initialized (step S341). That is, the player control module 212 controls the graphics processing module 219 so that the display method of the subtitle data is set to the default display method.
  • the player control module 212 also initializes the subtitle data display method instruction to the graphics processing module 219 when changing the PlayltemO (steps S341 and S351).
  • the configurable-flag of the new subtitle stream played according to the newly played PlayltemO is checked, and if the configurable_flag is 0, the graphics processing module Initialize the instruction of the display method of the subtitle data to 219, and if the configurable-flag is 1, keep the instruction of the display method to the Dallafix processing module 219 before switching to Playltem 0. It is possible.
  • the new display method instruction is supplied to the graphics processing module 219.
  • the indication of the display method is stored, for example, in the non-volatile memory constituting the memory 113 (FIG. 1), and the display method stored in the nonvolatile memory is stored.
  • the instructions can be provided to the graphics processing module 219.
  • an instruction of a display method of a user setting is stored in a non-volatile memory, and an instruction of a new display method is input by a user operating a remote controller.
  • the display mode instruction stored in the non-volatile memory is updated with a new display mode instruction, and the display mode stored in the non-volatile memory is updated.
  • the display method at the end of the previous playback is held in the non-volatile memory, so that the user operates the remote controller at the next playback of the PlayListO to display the display method at the end of the previous playback. Even if the user does not input the instruction, the display of the subtitle data is started by the display method.
  • the indication of the display method to be stored in the nonvolatile memory includes, for example, an enlargement ratio or a reduction ratio when the caption data is enlarged or reduced.
  • the subtitle data SUticInfoO of the subtitle data is acquired, and based on the configurable_flag included in the StaticInfoO and indicating whether to allow the display of the subtitle data to be changed from the default display method, It is determined whether changing the display from the default display method is permitted. If the display of the subtitle data being reproduced is permitted to be changed from the default display method, the display processing of the subtitle data is performed in accordance with the instruction to change the display method of the subtitle data. That is, for example, processing for displaying the caption data by enlarging or reducing it, or changing the display color is performed. Therefore, it is possible to control the change of the subtitle data display method. '
  • FIG. 44 illustrates the capture control process.
  • a flowchart for explaining a background screen saver process which is an example of a process of secondary use of video data captured by the capture control process, is also illustrated.
  • a capture instruction for instructing the capture of video data is transmitted to the player control module 212 via the input interface 115 (FIG. 1). Triggered when supplied.
  • step S371 the player control module 212 determines whether or not the video stream is being played. If it is determined that the video stream is not being played, the capture control is performed. The process ends.
  • step S371 determines whether the video stream is being played. If it is determined in step S371 that the video stream is being played, the process proceeds to step S372, where the player control module 212 reads the PlayListO (FIG. 5) corresponding to the playing video stream. , Capture—enable_flag_PlayList, and capture—enable_nag_Clip from the clip information file ClipO (FIG. 10) corresponding to the video stream being played.
  • capture_enable_flag PlayerList in PlayList 0 is, as described in FIG. 5, whether or not secondary use of video data (video data belonging to PlayListO) corresponding to the video stream reproduced by PlayListO is permitted.
  • capture—enable—flag_Clip in the clip information file CI ip () corresponds to the video stream stored in the clip stream file corresponding to the clip information file ClipO, as described in FIG. Indicates whether to allow secondary use of video data overnight.
  • step S3773 the player control module 2 1 2 reads the capt ure_enab 1 e_f 1 ag_P 1 ayL ist and captture_enab 1 acquired in the previous step S3773.
  • e_f 1 ag_C 1 ip it is determined whether or not the picture of the video that was being played back when the capture instruction was input from the input interface 115 (FIG. 1) can be captured.
  • step S373 If it is determined in step S373 that the capture of the video data that was being played when the capture instruction was input from the input interface 115 is not possible, that is, If at least one of capture_enable_flag_PlayList or capture_enable_flag_Clip obtained in step S373 is set to .0 indicating that secondary use of video data is not permitted, the process proceeds to step S374. Then, by controlling the graphics processing module 219, the player control module 211 overlays an error message indicating that video data cannot be captured, and ends the capture control processing. This will display an error message.
  • step S373 determines whether it is possible to capture the picture of the video data that was being played when the capture instruction was input from the input interface 115, that is, in step S37 If both the capture_enable_flag_PlayList and capture_enable_flag_Clip obtained in step 3 indicate that the secondary use of the video data is permitted, the process proceeds to step S375, and the player control module 2 1 2 The capture instruction of the picture of the video data being reproduced when the capture instruction is input from the input interface 115 is supplied to the graphics processing module 211, and the flow advances to step S376.
  • step S376 the graphics processing module 219 captures the picture of the video data from the video decoder control module 216 according to the capture instruction from the player control module 221 and stores it in the memory 111. 3 (Fig. 1) and end the capture control process. Note that if capture-enable-flag has a multi-bit configuration and usage conditions are restricted, the response will be taken at this point. That is, if the size of the captured image is limited, the image reduced at this point is captured. If there is a restriction on the application to be used, a flag to that effect is recorded at the same time.
  • the PlayListO (Fig. 5) and the clip information file ClipO (Fig. 10) corresponding to the video stream that is being played when the user gives a capture instruction, respectively.
  • the AND of capture—enable—flag—PlayList and capture—enable—flag_Cl ip is taken, and if the AND is 1, that is, capture—enable one flag—PlayList and capture—enable_f g—Clip is In any case, the secondary use of video data is determined to be possible only when the secondary use is set to 1, and the capture is performed.
  • the reproduction of the video stream that is, the reproduction of the video stream multiplexed into the clip stream file “00001.PS”
  • capture—enable_flag—PlayList in the first PlayList # 0 is 1
  • the clip list reproduced by the first PlayItem # 0 Capture-enable—flag Cli in the clip information file “00001.CLP” in FIG. 26A and FIG. Since p is 1, the secondary use of the video data being played (video data corresponding to the video stream multiplexed to the clip stream file "00001.PS”) is determined to be possible, and the caption is made. Is performed.
  • the reproduction of the video stream that is, the reproduction of the video stream multiplexed with the clip stream file “00002.PS” Capture__enable_nag in the first PlayList # 0—the PlayList is 1, and the clip stream that is played by the second Playltem # l when the user issues a capture instruction Since capture—enable_flag_Clip in the clip information file “00002. CLP” in FIG. 26A and FIG.
  • the capture_enable_flag_PlayList in the second PlayList # l is 0, and the clip stream file "00003.PS reproduced by PlayItem # 0 of the second PlayList # l Since capture-enable-flag-Clip is 1 in the clip information file "00003. CLP" corresponding to "Clip stream file” in Fig. 26A and Fig. 26B corresponding to " 00003. It is determined that the secondary use of the video data corresponding to the video stream multiplexed on the PS "is not possible, and no capture is performed. In this case, capture enable f la in the second PlayList # l When g_PlayList is confirmed to be 0, it can be determined that the video data is 2k and cannot be used.
  • the picture captured by the capture control processing and stored in the memory 113 can be used secondarily in the background Z screen server processing.
  • Background Z screen saver processing is performed, for example, in a state where the player control module 211 is operating but the elementary stream is not being played back, ie, the disk drive 102 (FIG. 1). This is performed, for example, when the disc 101 has not been inserted, or when the playback of the elementary stream has ended.
  • step S38 # the player control module 211 sets the graphics processing module 2 so as to display the picture stored in the memory 113 by the capture control process. Control one nine.
  • the graphics processing module 211 displays the pictures stored in the memory 113 by the capture control processing in accordance with the control from the player control module 212.
  • the pictures stored in the memory 113 are displayed as still images in the graphics processing module 219, a so-called wallpaper (background) is realized, and the graphics processing module 219 does not enlarge, reduce, move, etc. in a fixed cycle. If displayed, a screen saver is realized. Also, the picture stored in the memory 113 is displayed by the capture control processing. The background / screen saver processing can be performed by another independent application instead of the player control module 211.
  • capture—enable, flag, and PlayList are provided in PlayListO (FIG. 5), and the clip information file ClipO corresponding to the clip stream file played by Playlt em ().
  • capture_enable_flag_Clip is provided, and the permission (permission / non-permission) of secondary use is determined by using both capture—enable—flag—PlayList and capture—enable—flag_Clip.
  • PlayListO Fig. 5
  • only capture-enable-flag-PlayList is provided, or in the clip information file ClipO (Fig. 10) corresponding to the clip stream file played by PlayltemO.
  • Capture—enable—with just a flag Clip It is also possible to use only one of capture—enable—flag—PlayList or capture—enable—flag—CI ip to determine whether secondary use is possible.
  • step S376 the graphics processing module 219 transmits the video decoder control module 216 according to the capture instruction from the player control module 221.
  • the graphics processing module 219 transmits the video decoder control module 216 according to the capture instruction from the player control module 221.
  • a permission IS report for capturing or not enabling the secondary use of video data capture—enable—flag—PlayList, capture—enable one flag—Clip), and PlayList ( ).
  • the license information describes the video data of any other unit, and the video license of the arbitrary unit is described based on the license information. It is possible to judge whether or not secondary use is possible. That is, FIG. 45 shows the syntax of private_stream2_PES-payloadO in which the use permission information is arranged, and FIG. 46 shows the syntax of au-information 0 in which the use permission information is arranged.
  • private_stream2_PES-payloadO in Fig. 45 is configured in the same way as in Fig. 23 except that capture_enable- flag_ps2 is placed as usage permission information immediately before video_stream_id. .
  • the au_information () in Fig. 46 is also configured in the same way as in Fig. 24, except that pic_s true and capture_enable-flag-AU are placed just before copy as usage information. I have.
  • Capture_enable—flag—ps2 located in private—stream2—PES—payloadO in FIG. 5 is the private—stream2—PES—including payload 0, private—stream—2 PES—packet 0, etc. Indicates whether to permit secondary use of the video data corresponding to the video stream placed immediately before the next private—stream—2 PES—packetO. Therefore, according to the capture—enab 1 e_f 1 a.g_ps2 located in private—s stream2_PES_payload 0 in FIG. 45, the video data from one decoding start possible point to the next decoding start possible point It is possible to determine whether or not to permit the secondary use of
  • capture_enable__flag-AU arranged in au_information () in FIG. 46 indicates whether or not the secondary use of the video data of the video access unit corresponding to capture_enable_flag-AU is permitted. Therefore, according to capture_enable_flag-AU assigned to au-informationO in FIG. 46, it is determined whether or not to permit the secondary use of video data in units of video access units, that is, in units of pictures. Can be done.
  • capt as usage permission information in PlayListO (Fig. 5) ure_enable_flag_PlayList, capture—enable—flag—Clip as use permission information in clip information file CI ip 0 (FIG. 10), capture—enable—flag—as use permission information in private_stream2_PES_payload () (FIG. 45).
  • capture-enable_flag_AU as usage permission information in ps2, au_information () (Fig. 46), two or more of them can be used in duplicate, and in this case, a picture of a certain video data Whether or not secondary use is possible can be determined based on the logical product of two or more use permission information that are adopted in duplicate.
  • the PES_packet () of private-stream-2 including private-stream2-PES-payloadO in Fig. 23 or Fig. 45 where au_information () in Fig. 46 is located is the same as step S2 in Fig. 36.
  • the video readout function section 233 of the buffer control module 215 searches the program stream stored in the buffer 215A. Therefore, in the case of using private_stream2—PES—payload 0 in FIG. 45 where capture_enable—flag—ps2 is located, or au_iniormation () in FIG. 46 where capture—enable—flag—AU is located
  • the player control module 2 1 .2 capture. Enable. Flag 1. ps2 and capture— enable— flag— AU. You need to contact 233.
  • the above-described series of processing is performed by software, but the above-described series of processing may be performed by a dedicated hardware. .
  • a hardware decoder is adopted as the video decoder 116 (FIG. 1), but a software decoder may be adopted as the video decoder 116.
  • a software decoder is adopted as the subtitle decoder, but a hard-water decoder may be adopted as the subtitle decoder.

Abstract

データの再生時刻に応じ、引数情報に応じた処理を実行する。プレイリストの時間軸上の１つの再生時刻を表すmark_time_stampと、Mark（）のタイプを表すmark_typeと、mark_typeがイベントを発生させるタイプであるときに、そのイベントの引数となるmark_dataとを含むMark()を有するPlayListMark()を含むプレイリストにしたがって再生されているデータの再生時刻が、mark_time_stampに一致する場合、ステップＳ３０２において、そのmark_time_stampを有するMark()が認識され、その認識されたMark()が有するmark_typeがイベントを発生させるタイプを表している場合に、ステップＳ３０７において、そのMark()が有するmark_dataと、イベントの発生とが通知される。そして、ステップＳ３０８において、そのmark_dataに応じた処理が実行される。本発明は、例えば、DVDを利用したゲーム装置などに適用できる。

Description

明 細 書
データ処理装置およびデ一夕処理方法、 プログラムおよびプロダラ ム記録媒体、 データ記録媒体、 ならびに、 データ構造 技術分野
本発明は、 データ処理装置およびデータ処理方法、 プログラムおよ びプログラム記録媒体、 デ一夕記録媒体、 ならびに、 データ構造に関 し、 特に、 例えば、 利便性等の高いデータ処理を可能とするデータ処 理装置およびデータ処理方法、 プログラムおよびプログラム記録媒体 、 データ記録媒体、 ならびに、 データ構造に関する。 背景技術
近年、 大容量で、 ランダムアクセスが可能な記録メディアとして、 例えば、 DVD(Digital Versatile Disc)が普及し、 さらに、 DVDを利用 して各種の処理を行う DVD装置も広く普及している。
DVD装置としては、 例えば、 DVDに対して、 テレビジョン放送番組の データ等の記録再生を行う DVDレコーダや、 DVDに地図情報等を記録し 、 その地図情報の表示を行うカーナビゲーシヨンシステム、 DVDにゲ ームのプログラム等を記録し、 そのプログラムを実行するゲーム装置 などがある。
なお、 DVDについては、 例えば、 非特許文献 1 「DVD Specification s for Read-Only Disc Part 3; Version 1.1 Dcecmber 1997」 に、 そ の詳細が記載されている。
DVDのように、 大量のデータを記録することができる記録メディァ や、 それを利用して各種の処理を行う DVD装置などには、 そのような 大量のデータについて、 利便性等の高いデータ処理を行うことが要請 される。 発明の開示
本発明は、 このような状況に鑑みてなされたものであり、 利便性等 の高いデータ処理を行うことができるようにするものである。
本発明のデータ処理装置は、 プレイリストの時間軸上の 1つの再生 時刻を表す時刻情報と、 マーク情報のタイプを表すタイプ情報と、 タ イブ情報がイベントを発生させるタイプを表しているときの、 そのィ ベントの引数となる引数情報とを含むマーク情報を有するプレイリス トマ一ク情報を含むプレイリス卜にしたがって再生されているデータ の再生時刻が、 時刻情報に一致するか否かを判定する判定手段と、 判 定手段において、 データの再生時刻が、 時刻情報に一致すると判定さ れた場合に、 その時刻情報を有するマーク情報を認識する認識手段と 、 認識手段において認識されたマーク情報が有するタイプ情報が、 ィ ベントを発生させるタイプを表している場合に、 マーク情報が有する 引数情報と、 イベントの発生とを通知する通知手段と、 通知手段によ つて通知される引数情報に応じた処理を実行する実行手段とを備える ことを特徴とする。
本発明のデータ処理方法は、 プレイリストの時間軸上の 1つの再生 時刻を表す時刻情報と、 マーク情報のタイプを表すタイプ情報と、 夕 イブ情報がイベントを発生させるタイプを表しているときの、 そのィ ベントの引数となる引数情報とを含むマーク情報を有するプレイリス トマ一ク情報を含むプレイリス卜にしたがって再生されているデータ の再生時刻が、 時刻情報に一致するか否かを判定する判定ステップと 、 判定ステップにおいて、 データの再生時刻が、 時刻情報に一致する と判定された場合に、 その時刻情報を有するマーク情報を認識する認 識ステップと、 認識ステップにおいて認識されたマーク情報が有する タイプ情報が、 イベントを発生させるタイプを表している場合に、 マ ーク情報が有する引数情報と、 イベントの発生とを通知する通知ステ ップと、 通知ステップによって通知される引数情報に応じた処理を実 行する実行ステップとを含むことを特徴とする。
本発明のプログラムは、 プレイリス卜の時間軸上の 1つの再生時刻 を表す時刻情報と、 マーク情報のタイプを表すタイプ情報と、 タイプ 情報がイベントを発生させるタイプを表しているときの、 そのィベン トの引数となる引数情報とを含むマーク情報を有するプレイリストマ —ク情報を含むプレイリストにしたがって再生されているデータの再 生時刻が、 時刻情報に一致するか否かを判定する判定ステップと、 判 定ステップにおいて、 データの再生時刻が、 時刻情報に一致すると判 定された場合に、 その時刻情報を有するマーク情報を認識する認識ス テツプと、 認識ステップにおいて認識されたマーク情報が有するタィ プ情報が、 イベントを発生させるタイプを表している場合に、 マーク 情報 有する引数情報と、 イベントの発生とを通知する通知ステップ と、 通知ステップによって通知される引数情報に応じた処理を実行す る実行ステップとを含むことを特徴とする。
本発明のプログラム記録媒体に記録されているプログラムは、 プレ イリストの時間軸上の 1つの再生時刻を表す時刻情報と、 マーク情報 のタイプを表すタイプ情報と、 タイプ情報がイベントを発生させる夕 イブを表しているときの、 そのイベントの引数となる引数情報とを含 むマーク情報を有するプレイリストマーク情報を含むプレイリストに したがって再生されているデータの再生時刻が、 時刻情報に一致する か否かを判定する判定ステップと、 判定ステップにおいて、 デ一夕の 再生時刻が、 時刻情報に一致すると判定された場合に、 その時刻情報 を有するマーク情報を認識する認識ステップと、 認識ステップにおい て認識されたマーク情報が有するタイプ情報が、 イベントを発生させ るタイプを表している場合に、 マーク情報が有する引数情報と、 ィべ ントの発生とを通知する通知ステップと、 通知ステップによって通知 される引数情報に応じた処理を実行する実行ステップとを含むことを 特徴とする。
本発明のデータ記録媒体は、 デー夕を符号化して得られる符号化デ —夕と、 データの再生手順を表すプレイリス卜とを含む記録データが 記録されており、 プレイリストは、 そのプレイリス卜の時間軸上の印 となるマーク情報を有するプレイリストマーク情報を含み、 マーク情 報は、 プレイリストの時間軸上の 1つの再生時刻を表す時刻情報と、 マーク情報のタイプを表すタイプ情報と、 タイプ情報がイベントを発 生させるタイプを表しているときの、 そのイベントの引数となる引数 情報とを含むことを特徴とする。
本発明のデータ構造は、 データを符号化して得られる符号化データ と、 テ '一夕の再生手順を表すプレイリストとを含むデータ構造におい て、 プレイリストは、 プレイリストの時間軸上の印となるマーク情報 を有するプレイリストマーク情報を含み、 マーク情報は、 プレイリス 卜の時間軸上の 1つの再生.時刻を表す時刻情報と、 マーク情報のタイ プを表すタイプ情報と、 タイプ情報がイベントを発生させるタイプを 表しているときの、 そのイベントの引数となる引数情報とを含むこと を特徴とする。 .
本発明のデータ処理装置およびデータ処理方法、 並びにプログラム およびプログラム記録媒体に記録されているプログラムにおいては、 プレイリス卜の時間軸上の 1つの再生時刻を表す時刻情報と、 マーク 情報のタイプを表すタイプ情報と、 タイプ情報がイベントを発生させ るタイプを表しているときの、 そのイベントの引数となる引数情報と を含むマーク情報を有するプレイリストマーク情報を含むプレイリス トにしたがって再生されているデータの再生時刻が、 時刻情報に一致 するか否かが判定され、 データの再生時刻が、 時刻情報に一致すると 判定された場合に、 その時刻情報を有するマーク情報が認識される。 さらに、 その認識されたマーク情報が有するタイプ情報が、 イベント を発生させるタイプを表している場合に、 マーク情報が有する引数情 報と、 イベントの発生とが通知され、 その引数情報に応じた処理が実 行される。
本発明のデータ記録媒体においては、 データを符号化して得られる 符号化データと、 データの再生手順を表すプレイリストとを含む記録 データが記録されており、 プレイリストは、 そのプレイリストの時間 軸上の印となるマーク情報を有するプレイリストマーク情報を含み、 マーク情報は、 プレイリストの時間軸上の 1つの再生時刻を表す時刻 情報と、 マーク情報のタイプを表すタイプ情報と、 タイプ情報がィべ ントを発生させるタイプを表しているときの、 そのイベントの引数と なる引数情報とを含んでいる。
本発明のデータ構造においては、 データを符号化して得られる符号 化データと、 データの再生手順を表すプレイリストとを含むデータ構 造において、 プレイリス卜は、 プレイリストの時間軸上の印となるマ ーク情報を有するプレイリストマーク情報を含み、 マーク情報は、 プ レイリストの時間軸上の 1つの再生時刻を表す時刻情報と、 マーク情 報のタイプを表すタイプ情報と、 タイプ情報がイベントを発生させる タイプを表しているときの、 そのイベントの引数となる引数情報とを 含んでいる。
本発明によれば、 利便性等の高いデータ処理が可能となる。 特に、 データの再生時刻に応じ、 引数情報に応じた処理を実行することが可 能となる。 図面の簡単な説明
第 1図は、 本発明を適用したディスク装置の一実施の形態のハード ウェア構成例を示すブロック図、 第 2図 Aおよび第 2図 Bは、 CPU1 1 2が実行するソフトウエアモジュール群の構成例を示すブロック図 、 第 3図は、 バッファ制御モジュール 2 1 5の構成例を示すブロック 図、 第 4図は、 ディスク 1 0 1におけるディレクトリ構成例を示す図 、 第 5図は、 "PLAYLIST.DAT"ファイルのシンタクスを示す図、 第 6図 は、 PlayltemOのシンタクスを示す図、 第 7図は、 PlayListMarkOの シンタクスを示す図、 第 8図は、 mark_typeの値と、 MarkOのタイプ との関係を示す図、 第 9図は、 PlayListO, PlayltemO, クリップ、 およびクリップストリームファイルに格納されたプログラムストリー ムの関係を示す図、 第 1 0図は、 クリップ情報ファイル ClipOのシン タクスを示す図、 第 1 1図は、 エレメン夕リストリームを識別する st ream— idおよび private— stream_idと、 エレメン夕リストリ一ムとの関 係を示す図、 第 1 2図は、 StaticInfoOのシンタクスを示す図、 第 1 3図は、 DynamicInfoOのシンタクスを示す図、 第 14図は、 EP一 map( )のシンタクスを示す図、 第 1 5図 Aおよび第 1 5図 Bは、 MPEG- 2 Sy stemのプログラムストリーム、 プログラムストリームパック、 および プログラムストリームパックヘッダのシンタクスを示す図、 第 1 6図 Aおよび第 1 6図 Bは、 MPEG- 2 Sys temの PESパケットのシンタクスを 示す図、 第 1 7図 A、 第 1 7図 Bおよび第 1 7図 Cは、 MPEG- 2 Syste mの PESパケットのシンタクスを示す図である。 第 1 8図 Aおよび第 1 8図 Bは、 MPEG- 2 Systemの PESパケットのシンタクスを示す図、 第 1 9図 Aおよび第 1 9図 Bは、 MPEG- 2 Sys t emにおける PES— packet 0の s treamjdに記述される値と、 エレメンタリストリームの属性 （種類） との関係を示す図、 第 20図は、 ディスク装置が採用する streamjd を示す図、 第 2 1図は、 private_streamし PES_payload()のシンタク スを示す図、 第 22図は、 private_stream— idの値と、 private— paylo ad()に格納されるエレメンタリストリームの属性との関係を示す図、 第 23図は、 private__stream2_PES_payload()のシンタクスを示す図 、 第 24図は、 au_information()のシンタクスを示す図、 第 2 5図は 、 "PLAYLIST.DAT"ファイルの具体例を示す図、 第 26図 Aおよび第 2 6図 Bは、 クリップ情報ファイル" 00001. CLP"， " 00002. CLP", " 00003 .CLP"の具体例を示す図、 第 27図は、 クリップ情報ファイル" 00001. CLP"の中の EP_map()の具体例を示す図、 第 2 8図は、 PlayList #0と P layList #1の中の PlayListMarkOの具体例を示す図、 第 29図は、 再 生前処理を説明するフローチャート、 第 30図は、 再生処理を説明す るフローチヤ一ト、 第 3 1図は、 Playltem乗り換え処理を説明するフ ローチャート、 第 32図は、 タイムコード表示処理を説明するフロー チャート、 第 3 3図は、 ストリーム切り替え処理を説明するフローチ ヤート、 第 34図は、 バッファ制御モジュール 2 1 5の処理を説明す るフローチャート、 第 35図は、 バッファ制御モジュール 2 1 5の処 理を説明するフローチャート、 第 36図は、 ビデオストリームの読み 出しの処理を説明するフローチャート、 第 3 7図は、 オーディオスト リームの読み出しの処理を説明するフローチャート、 第 3 8図は、 字 幕ストリームの読み出しの処理を説明するフローチャート、 第 3 9図 は、 再同期処理を説明するフローチャート、 第 40図は、 マーク処理 を説明するフローチャート、 第 41図は、 出力属性の制御処理を説明 するフローチャート、 第 42図は、 クリップ情報ファイル" 00003. CLP "に記述されている pt s__change_po intと Dynami c Inf o Oとのセットの真 体例を示す図、 第 4 3図は、 字幕表示制御処理を説明するフローチヤ ート、 第 4 4図は、 キヤプチャ制御処理とバックグラウンド Zスクリ —ンセ一バ処理を説明するフローチャート、 第 4 5図は、 pr ivat e_s t ream2_PES_payl oad ()の他のシンタクスを示す図、 第 4 6図は、 au_in f ormat i on 0の他のシンタクスを示す図である。 発明を実施するための最良の形態
以下に本発明の実施の形態を説明するが、 請求の範囲に記載の構成 要件と、 発明の実施の形態における具体例との対応関係を例示すると 、 次のようになる。 この記載は、 請求の範囲に記載されている発明を サポートする具体例が、 発明の実施の形態に記載されていることを確 認するためのものである。 従って、 発明の実施の形態中には記載され ているが、 構成要件に対応するものとして、 ここには記載されていな い具体例があつたとしても、 そのことは、 その具体例が、 その構成要 件に対応するものではないことを意味するものではない。 逆に、 具体 例が構成要件に対応するものとしてここに記載されていたとしても、 そのことは、 その具体例が、 その構成要件以外の構成要件には対応し ないものであることを意味するものでもない。
さらに、 この記載は、 発明の実施の形態に記載されている具体例に 対応する発明が、 請求の範囲に全て記載されていることを意味するも のではない。 換言すれば、 この記載は、. 発明の実施の形態に記載され ている具体例に対応する発明であって、 この出願の請求の範囲には記 載されていない発明の存在、 すなわち、 将来、 分割出願されたり、 補 正により追加される発明の存在を否定するものではない。
請求の範囲 1に記載のデータ処理装置は、 データ記録媒体に記録されている記録データを処理するデータ処 a 装置 （例えば、 第 1図のディスク装置） において、
目 U 記録ァ一タは、
データを符号化して得られる符号化データと、
前記データの再生手順を表すプレイリス卜 （例えば、 第 5図の P1 ayList 0) と
を含み、
前記プレイリストは、 そのプレイリス卜の時間軸上の印となるマー ク情報 （例えば、 第 7図の MarkO) を有するプレイリストマーク情報 (例えば、 第 5図の PlayListMarkO) を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報 （ 例えば、 第 7図の mark_time__stamp) と、
前記マーク情報のタイプを表すタイプ情報 （例えば、 第 7図の ma rk_type) と、
Ιίί記タイプ情報がイベントを発生させるタイプを表しているとき の、 そのイベントの引数となる引数情報 （例えば、 第 7図の mark— dat a) と
を含み、
前記プレイリストにしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定手段 （例えば、 第 40図のステップ S 30 1の処理を行う第 2図 Aおよび第 2図 Bの デコード制御モジュール 2 14) と、
前記判定手段において、 前記データの再生時刻が、 前記時刻情報に 一致すると判定された場合に、 その時刻情報を有する前記マーク情報 を認識する認識手段 （例えば、 第 40図のステップ S 3 02の処理を 行う第 2図 Aおよび第 2図 Bのプレイヤ制御モジュール 2 1 2 ) と、 前記認識手段において認識された前記マーク情報が有する前記タイ プ情報が、 イベントを発生させるタイプを表している場合に、 前記マ ーク情報が有する前記引数情報と、 イベントの発生とを通知する通知 手段 （例えば、 第 40図のステップ S 3 07の処理を行う第 2図 Aお よび第 2図 Bのプレイヤ制御モジュール 2 1 2) と、
前記通知手段によって通知される前記引数情報に応じた処理を実行 する実行手段 （例えば、 第 40図のステップ S 3 08の処理を行う第 2図 Aおよび第 2図 Bのスクリプト制御モジュール 2 1 1) と
を備えることを特徴とする。
請求の範囲 3に記載のデータ処理方法は、
データ記録媒体に記録されている記録デ一夕を処理するデータ処理 方法において、
前記記録データは、
データを符号化して得られる符号化データと、
前記データの再生手順を表すプレイリスト （例えば、 第 5図の P1 ayListO) と
を含み、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマー ク情報 （例えば、 第 7図の MarkO) を有するプレイリストマーク情報 (例えば、 第 5図の PlayListMarkO) を含み、
前記マーク情報は、 .
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報 （ 例えば、 第 7図の mark— time_stamp) と、
前記マーク情報のタイプを表すタイプ情報 （例えば、 第 7図の ma rk_type) と、 前記タイプ情報がイベントを発生させるタイプを表しているとき の、 そのイベントの引数となる引数情報 （例えば、 第 7図の mark一 dat a) と
を含み、
前記プレイリストにしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定ステップ （例え ば、 第 4 0図のステップ S 3 0 1 ) と、
前記判定ステップにおいて、 前記データの再生時刻が、 前記時刻情 報に一致すると判定された場合に、 その時刻情報を有する前記マーク 情報を認識する認識ステップ （例えば、 第 4 0図のステップ S 3 0 2 ) と、
前記認識ステップにおいて認識された前記マーク情報が有する前記 タイプ情報が、 イベントを発生させるタイプを表している場合に、 前 記マーク情報が有する前記引数情報と、 イベントの発生とを通知する 通知ステップ （例えば、 第 4 0図のステップ S 3 0 7 ) と、
前記通知ステップによって通知される前記引数情報に応じた処理を 実行する実行ステップ （例えば、 第 4 0図のステップ S 3 0 8 ) と を含むことを特徴とする。
請求の範囲 4に記載のプログラム、 および請求の範囲 5に記載のプ ログラム記録媒体に記録されたプログラムは、
データ記録媒体に記録されている記録データを処理するデータ処理 を、 コンピュータに行わせるプログラムにおいて、
BU d記録： r一夕は、
データを符号化して得られる符号化データと、
前記データの再生手順を表すプレイリスト （例えば、 第 5図の P 1 ayL i s t O ) と を含み、
前記プレイリス卜は、 そのプレイリストの時間軸上の印となるマー ク情報 （例えば、 第 7図の Mark O ) を有するプレイリストマーク情報 (例えば、 第 5図の P yL i s tMark O ) を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報 （ 例えば、 第 7図の mark一 t ime—s t amp) と、
前記マーク情報のタイプを表すタイプ情報 （例えば、 第 7図の ma rk.type) と、 前記タイプ情報がイベントを発生させるタイプを 表しているときの、 そのイベントの引数となる引数情報 （例えば、 第 7図の mark_dat a) と
を含み、
前記プレイリストにしたがって再生されている前記デ一夕の再生時 刻が、 前記時刻情報に一致するか否かを判定する判定ステップ （例え ば、 第 4 0図のステップ S 3 0 1 ) と、
前記判定ステップにおいて、 前記データの再生時刻が、 前記時刻情 報に一致すると判定された場合に、 その時刻情報を有する前記マーク 情報を認識する認識ステップ （例えば、 第 4 0図のステップ S 3 0 2 ) と、
前記認識ステップにおいて認識された前記マーク情報が有する前記 タイプ情報が、 イベントを発生させるタイプを表している場合に、 前 記マーク情報が有する前記引数情報と、 イベントの発生とを通知する 通知ステップ （例えば、 第 4 0図のステップ S 3 0 7 ) と、
前記通知ステップによって通知される前記引数情報に応じた処理を 実行する実行ステップ （例えば、 第 4 0図のステップ S 3 0 8 ) と を含むことを特徴とする。 請求の範囲 6に記載のデータ記録媒体は、
データを符号化して得られる符号化データと、
前記デ一夕の再生手順を表すプレイリスト （例えば、 第 5図の P1
-、
ayList 0 と
を含む記録データが記録されており、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマー ク情報 （例えば、 第 7図の MarkO) を有するプレイリストマーク情報 (例えば、 第 5図の PlayListMarkO) を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報 （ 例えば、 第 7図の mark— time一 st amp) と、
前記マーク情報のタイプを表すタイプ情報 （例えば、 第 7図の ma rk一 type) と、
前記タイプ情報がイベントを発生させるタイプを表しているとき の、 そのイベントの引数となる引数情報 （例えば、 第 7図の mark一 dat a) と'
を含む
ことを特徴とする。
請求の範囲 7に記載のデータ構造は、
データを符号化して得られる符号化データと、
前記デ一夕の再生手順を表すプレイリスト （例えば、 第 5図の P1 ayList ()) と
を含む記録デ一夕が記録されており、
前記プレイリストは、 そのプレイリス卜の時間軸上の印となるマー ク情報 （例えば、 第 7図の MarkO) を有するプレイリストマーク情報 (例えば、 第5図の？1& !^31¾^^0) を含み、 前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報 （ 例えば、 第 7図の mark_Ume_s t amp) と、
前記マーク情報のタイプを表すタイプ情報 （例えば、 第 7図の ma rk— type) と、
前記タイプ情報がイベントを発生させるタイプを表しているとき の、 そのイベントの引数となる引数情報 （例えば、 第 7図の mark一 dat a) と
を含む
ことを特徴とする。
以下、 図面を参照して、 本発明の実施の形態について説明する。
[ハードウェア構成]
第 1図は、 本発明を適用したディスク装置の一実施の形態のハード ウェアの構成例を示すブロック図である。
第 1図のディスク装置は、 例えば、 ディスクプレーヤや、 ゲーム装 置、 カーナビゲ一シヨンシステムその他に適用することができる。 第 1図のディスク装置において、 ディスク 1 0 1は、 例えば、 DVD などの光ディスク、 あるいは光磁気ディスク、 磁気ディスクなどであ り、 ビデオデータや、 オーディオデータ、 字幕データなどのコンテン ッデ一夕、 さらには、 コンテンツデータを再生するのに必要なデータ が記録されている。
なお、 ディスク 1 0 1に記録されるデータ （記録データ） には、 必 要に応じて、 コンピュータが実行可能なプログラムも含まれる。 また 、 本実施の形態では、 記録媒体として、 ディスク状の記録媒体である ディスク 1 0 1を採用するが、 その他、 記録媒体としては、 例えば、 半導体メモリや、 テープ状の記録媒体であってもよい。 さらに、 第 1 図のディスク装置には、 遠方にあるディスク 1 0 1から読み出されて 送信されてくるデータを入力することができる。 即ち、 ディスク 1 0 1からのデータの読み出しは、 ディスク装置に接続した別の装置で行 レ その別の装置で読み出されたデータを、 ディスク装置で受信して 処理することができる。 また、 ディスク装置では、 ディスク 1 0 1に 記録されたデータと同様のデータをストレージに記憶しているサーバ 等から、 インターネット等のネットワークを介して、 データの配信を 受けて処理することも可能である。 さらに、 ディスク装置では、 サー バその他の装置からのデ一夕を受信し、 一旦、 ディスク 1 0 1に記録 してから、 そのディスク 1 0 1に記録されたデータを処理することも 可能である。
ディスクドライブ 1 0 2には、 ディスク 1 0 1が着脱可能になって いる。 ディスクドライブ 1 02は、 図示せぬイン夕一フェースを内蔵 し、 そのインターフェースを通じて、 ドライブインターフェース 1 1 4に接続されている。 ディスクドライブ 1 02は、 そこに装着された ディスク 1 0 1を駆動し、 ドライブインターフェース 1 14からの読 み出し等の命令にしたがって、 ディスク 1 0 1からデ一夕を読み出し て、 ドライブインターフェース 1 14に供給する等の処理を行う。 バス 1 1 1には、 CPU(Central 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が 接続されている。
CPU1 1 2およびメモリ 1 1 3は、 コンピュータシステムを形成し ている。 即ち、 CPU1 1 2は、 メモリ 1 1 3に記憶されたプログラム である、 後述するソフトウェアモジュール群を実行し、 ディスク装置 全体を制御するとともに、 後述する各種の処理を行う。 メモリ 1 1 3 は、 CPU 1 1 2が実行するソフトウェアモジュール群を記憶している 。 また、 メモリ 1 1 3は、 CPU 1 1 2の動作上必要なデータを一時記 憶する。 なお、 メモリ 1 1 3は、 不揮発性メモリのみ、 または揮発性 メモリと不揮発性メモリとの組み合わせで構成することが可能である 。 また、 第 1図のディスク装置に、 ハードディスクを設け、 そのハー ドディスクに、 CPU 1 1 2が実行するソフトウエアモジュール群を記 録 （インストール） しておく場合には、 メモリ 1 1 3は、 揮発性メモ リのみで構成することが可能である。
ここで、 CPU 1 1 2が実行するプログラム （ソフトウェアモジュ一 ル群） は、 ディスク装置に内蔵されている記録媒体としてのメモリ 1 1 3に予め記録しておく （記憶させておく） ことができる。
あるいはまた、 プログラムは、 ディスク 1 0 1、 さらには、 デイス ク 1 0 1以外のフレキシブルディスク、 CD- R0M (Compac t Di sc Read 0 nly Memory) , MO (Magne t o Op t i cal)ディスク、 磁気ディスク、 メモリ カードなどのリムーバブル記録媒体に、 一時的あるいは永続的に格納 (記録） しておくことができる。 このようなリムーバブル記録媒体は 、 いわゆるパッケージソフトウエアとして提供することができる。 なお、 プログラムは、 メモリ 1 1 3にあらかじめ記憶させておくこ と、 あるいは、 上述したようなリム一バブル記録媒体からディスク装 置にインストールすることができる。 また、 プログラムは、 ダウン口 一ドサイトから、 ディジタル衛星放送用の人工衛星を介して、 デイス ク装置に無線で転送したり、 LAN (Local Area Ne twork) , インターネ ットといったネットワークを介して、 ディスク装置に有線で転送し、 ディスク装置では、 そのようにして転送されてくるプログラムを、 入 力インターフェース 1 1 5で受信し、 内蔵するメモリ 1 1 3にィンス トールすることができる。
さらに、 プログラムは、 1の CPUにより処理されるものであっても 良いし、 複数の CPUによって分散処理されるものであっても良い。
ドライブイン夕一フェース 1 14は、 CPU1 1 2の制御の下、 ディ スクドライブ 1 02を制御し、 これにより、 ディスクドライブ 1 02 がディスク 1 0 1から読み出したデータを、 バス 1 1 1を介して、 CP U1 1 2や、 メモリ 1 1 3、 ビデオデコーダ 1 1 6、 オーディオデコ —ダ 1 1 7などに供給する。
入力インターフェース 1 1 5は、 図示せぬキー （ポタン） や、 リモ コン （リモートコントローラ） がユーザに操作されることによって供 給される信号を受信し、 バス 1 1 1を介して、 CPU1 1 2に供給する 。 なお、 入力インタ一フェース 1 1 5は、 その他、 例えば、 モデム （ ADSL (Asymmetric Digital Subscriber Line)モデムを含む) や、 NIC( Network Interface Card)などの通信インターフェースとしても機能 する。
ビ ォデコーダ 1 1 6は、 ディスクドライブ 1 02によってデイス ク 1 0 1から読み出され、 ドライブイン夕一フェース 1 14およびバ ス 1 1 1を介して供給される、 ビデオデータの符号化データ （符号化 オーディオデータ） をデコードし、 その結果得られるビデオデータを 、 パス 1 1 1を介して、 CPU1 12やビデオ出カイン夕ーフェース 1 1 8に供給する。
オーディオデコーダ 1 1 7は、 ディスクドライブ 1 02によってデ イスク 1 0 1から読み出され、 ドライブインターフェース 1 14およ びバス 1 1 1を介して供給される、 オーディオデータの符号化データ (符号化オーディオデータ） をデコードし、 その結果得られるオーデ ィォデ一夕を、 バス 1 1 1を介して、 CPU1 1 2やオーディ才出カイ ンタ一フェース 1 1 9に供給する。
ビデオ出力イン夕一フェース 1 1 8は、 バス 1 1 1を介して供給さ れるビデオデータに必要な処理を施し、 ビデオ出力端子 1 2 0から出 力する。 オーディォ出カインターフェース 1 1 9は、 バス 1 1 1を介 して供給されるオーディオデータに必要な処理を施し、 オーディオ出 力端子 1 2 1から出力する。
ビデオ出力端子 1 2 0は、 図示せぬ CRT (Cathode Ray Tube)や、 液 晶パネル等のビデオ出力装置に接続されており、 従って、 ビデオ出力 端子 1 2 0から出力されるビデオデ一夕は、 ビデオ出力装置に供給さ れて表示される。 オーディオ出力端子 1 2 1は、 図示せぬスピーカや アンプなどのオーディオ出力装置に接続されており、 従って、 オーデ ィォ出力端子 1 2 1から出力されるオーディォデータは、 オーディオ 出力装置に供給されて出力される。
なお、 ディスク装置から、 ビデオ出力装置とオーディオ出力装置へ のビデオデータとオーディオデータの供給は、 有線または無線のいず れによって行うことも可能である。
[ソフトウエアモジュール群の構成]
次に、 第 2図 Aおよび第 2図 Bは、 第 1図の CPU 1 1 2が実行する ソフトウエアモジュール群の構成例を示している。
CPU 1 1 2が実行するソフトウェアモジュール群は、 ォペレ一ティ ングシステム （OS) 2 0 1と、 アプリケーションプログラムとしての ビデオコンテンツ再生プログラム 2 1 0に大別される。
「オペレーティングシステム 2 0 1 J
オペレーティングシステム 2 0 1は、 ディスク装置の電源が投入さ れると最初に起動し （CPU 1 1 2がオペレーティングシステム 2 0 1 を実行し） 、 初期設定等の必要な処理を行い、 アプリケーションプロ グラムであるビデオコンテンツ再生プログラム 2 1 0を呼び出す。 オペレーティングシステム 2 0 1は、 ビデオコンテンツ再生プログ ラム 2 1 0に対して、 ファイルの読み出し等のィンフラ (インフラス トラクチャ（inf ras t ruc ture) ) 的なサービスを提供する。 即ち、 オペ レーティングシステム 2 0 1は、 例えば、 ファイルの読み出しに関し ては、 ビデオコンテンツ再生プログラム 2 1 0からのファイルの読み 出しのリクエストに対して、 ドライブインターフェース 1 1 4を介し てディスクドライブ 1 0 2を操作して、 ディスク 1 0 1のデータを読 み出し、 ビデオコンテンツ再生プログラム 2 1 0に渡すサービスを提 供する。 また、 オペレーティングシステム 2 0 1は、 ファイルシステ ムの解釈等も行う。
なお、 オペレーティングシステム 2 0 1は、 マルチタスク処理の機 能を備えており、 複数のソフトウェアモジュールを、 時分割で （見か け上） 同時に動作させることができる。 即ち、 ビデオコンテンツ再生 プログラム 2 1 0は、 幾つかのソフトウェアモジュールで構成される が、 各ソフトウェアモジュールは、 並列で動作することができる。
「ビデオコンテンツ再生プログラム 2 1 0」
ビデオコンテンツ再生プログラム 2 1 0は、 スクリプト制御モジュ ール 2 1 1、 プレイヤ制御モジュール 2 1 2、 コンテンツデータ供給 モジュール 2 1 3、 デコード制御モジュール 2 1 4、 バッファ制御モ ジュール 2 1 5、 ビデオデコーダ制御モジュール 2 1 6、 オーディオ デコーダ制御モジュール 2 1 7、 字幕デコーダ制御モジュール 2 1 8 、 グラフィックス処理モジュール 2 1 9、 ビデオ出力モジュール 2 2 0、 およびオーディォ出力モジュール 2 2 1で構成されている。 ビデオコンテンツ再生プログラム 2 1 0は、 ディスク 1 0 1の再生 にあたって中心的な役割を果たすソフトウエアであり、 ディスク 1 0 1がディスクドライブ 1 0 2に装着 （挿入） されると、 そのディスク 1 0 1が、 コンテンッが記録された後述するフォーマツトのディスク であるかを確認する。 さらに、 ビデオコンテンツ再生プログラム 2 1 0は、 ディスク 1 0 1から、 後述するスクリプトファイルを読み出し て実行し、 また、 ディスク 1 0 1から、 そのディスク 1 0 1に記録さ れたコンテンツを再生するのに必要なメタデータ （データベース情報
) のファイルを読み出し、 そのメタデータに基づいて、 コンテンツの 再生を制御する。
以下、 第 2図 Aおよび第 2図 Bのビデオコンテンッ再生プログラム 2 1 0を構成するソフトウェアモジュールについて説明する。 なお、 第 2図 Aおよび第 2図 Bにおいては、 原則として、 実線の矢印は、 コ ンテンッのデータを表し、 点線の矢印は、 制御のデータを表す。
「スクリプト制御モジュール 2 1 1」
スクリブト制御モジュール 2 1 1は、 ディスク 1 0 1に記録された スクリプトファイルに記述されているスクリプトプログラム （スクリ ブト） を解釈して実行する。 スクリプトプログラムでは、 例えば、 「 グラフィクス処理モジュール 2 1 9を操作し、 メニュー等の画像を作 成して表示する」 、 「リモコン等の UI (User Inter f ace)からの信号に 従いメニューの表示を変更する （例えば、 メニュー上のカーソルを移 動する等） 」 、 「プレイヤ制御モジュール 2 1 2を制御する」 等の動 作を記述することができる。
「プレイヤ制御モジュール 2 1 2」 '
プレイヤ制御モジュール 2 1 2は、 ディスク 1 0 1に記録されてい るメタデータ （データベース情報） 等を参照し、 コンテンツの再生に 関する制御を行う。 即ち、 プレイヤ制御モジュール 2 1 2は、 例えば 、 ディスク 1 0 1に記録されている、 後述する P l ayL i s t Oや Cl ip Oを 解析し、 その解析結果にしたがって、 コンテンツデ一夕供給モジユー ル 2 1 3や、 デコード制御モジュール 2 1 4、 バッファ制御モジュ一 ル 2 1 5を制御する。 また、 プレイヤ制御モジュール 2 1 2は、 スク リプト制御モジュール 2 1 1や入力インターフェース 1 1 5からの指 示にしたがい、 再生対象のストリームを切り替える、 後述するストリ ーム切り替え等の制御を行う。 さらに、 プレイヤ制御モジュール 2 1 4は、 デコード制御モジュール 2 1 4から時刻を取得し、 時刻表示や 、 後述するマーク （Mark O ) の処理等を行う。
「コンテンツデータ供給モジュール 2 1 3」
コンテンツデータ供給モジュール 2 1 3は、 プレイヤ制御モジユー ル 2 1 2の制御にしたがい、 あるいは、 バッファ制御モジュール 2 1 5に蓄積されたデータの量に基づき、 ディスク 1 0 1からのコンテン ッのデータやメタデ一夕等の読み出しを、 オペレーティングシステム 2 0 1に要求する。
なお、 オペレーティングシステム 2 0 1が、 コンテンッデ一夕供給 モジュール 2 1 3からの要求に応じてディスク 1 0 1から読み出した メタデータ等は、 必要なモジュールに供給される。 また、 オペレ一テ ィングシステム 2 0 1が、 コンテンツデータ供給モジュール 2 1 3か らの要求に応じてディスク 1 0 1から読み出したコンテンツのデータ は、 バッファ制御モジュール 2 1 5に供給される。
「デコード制御モジュール 2 1 4」
デコード制御モジュール 2 1 4は、 プレイヤ制御モジュール 2 1 2 からの制御にしたがい、 ビデオデコーダ制御モジュール 2 1 6、 ォ一 ディォデコーダ制御モジュール 2 1 7、 および字幕デコーダ制御モジ ユール 2 1 8の動作を制御する。 また、 デコード制御モジュール 2 1 4は、 時刻を計時する計時部 2 1 4 Aを内蔵し、 ビデオデコーダ制御 モジュール 2 1 6の制御によって出力されるビデオデ一夕の出力と、 そのビデオデータと同期して出力されるべきデータ （出力データ） の 出力、 即ち、 ここでは、 オーディオデコーダ制御モジュール 2 1 7の 制御によって出力されるオーディォデータの出力との同期を管理する
「バッファ制御モジュール 2 1 5」
バッファ制御モジュール 2 1 5は、 第 1図のメモリ 1 1 3の記憶領 域の一部であるバッファ 2 1 5 Aを内蔵しており、 そのバッファ 2 1 5 Aに、 コンテンツデータ供給モジュール 2 1 3がオペレーティング システム 2 0 1に要求を行うことによってディスク 1 0 1から読み出 されたコンテンツのデータを一時記憶する。
また、 バッファ制御モジュール 2 1 5は、 ビデオデコーダ制御モジ ユール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 または字 幕デコーダ制御モジュール 2 1 8の要求にしたがって、 バッファ 2 1 5 Aに記憶されたデータを、 ビデオデコーダ制御モジュール 2 1 6、 オーディォデコーダ制御モジュール 2 1 7、 または字幕デコーダ制御 モジュール 2 1 8に供給する。
即ち、 バッファ制御モジュール 2 1 5は、 後述する第 3図で説明す るビデオ読み出し機能部 2 .3 3、 オーディオ読み出し機能部 2 3 4、 および字幕読み出し機能部 2 3 5を内蔵している。 そして、 バッファ 制御モジュール 2 1 5は、 ビデオデコーダ制御モジュール 2 1 6から のデータの要求を、 ビデオ読み出し機能部 2 3 3で処理することによ り、 バッファ 2 1 5 Aに記憶されたデータを、 ビデオデコーダ制御モ ジュール 2 1 6に供給する。 同様に、 バッファ制御モジュール 2 1 5 は、 オーディオデコーダ制御モジュール 2 1 7からのデータの要求を 、 オーディオ読み出し機能部 2 3 4で処理することにより、 バッファ 2 1 5 Aに記憶されたデ一夕を、 オーディオデコーダ制御モジュール 2 1 7に供給するとともに、 字幕デコーダ制御モジュール 2 1 8から のデ一夕の要求を、 字幕読み出し機能部 2 3 5で処理することにより 、 バッファ 2 1 5 Aに記憶されたデータを、 字幕デコーダ制御モジュ —ル 2 1 8に供給する。
「ビデオデコーダ制御モジュール 2 1 6 J
ビデオデコーダ制御モジュール 2 1 6は、 バッファ制御モジュール 2 1 5内のビデオ読み出し機能部 2 3 3 (第 3図） を操作して、 ビデ ォデータを符号化したデータ （ビデオ符号化データ） を、 ビデオァク セスユニット単位で、 バッファ制御モジュール 2 1 5のバッファ 2 1 5 Aから読み出し、 第 1図のビデオデコーダ 1 1 6に供給する。 また 、 ビデオデコーダ制御モジュール 2 1 6は、 ビデオデコーダ 1 1 6を 制御し、 ビデオアクセスユニット単位のデータをデコードさせる。 さ らに、 ビデオデコーダ制御モジュール 2 1 6は、 ビデオデコーダ 1 1 6でのデコードの結果得られるビデオデータを、 グラフィクス処理モ ジュール 2 1 9に供給する。
ここで、 ビデオアクセスユニットとは、 例えば、 ビデオデータの 1 ピクチャ （ 1フレームまたは 1フィールド） 分である。
「オーディオデコーダ制御モジュール 2 1 7」
オーディオデコーダ制御モジュール 2 1 7は、 バッファ制御モジュ ール 2 1 5内のオーディオ読み出し機能部 2 3 4 (第 3図） を操作し て、 オーディオデータを符号化したデータ （オーディオ符号化データ ) を、 オーディオアクセスユニット単位で、 バッファ制御モジュール 2 1 5のバッファ 2 1 5 Aから読み出し、 第 1図のオーディォデコ一 ダ 1 1 7に供給する。 また、 オーディオデコーダ制御モジュール 2 1 7は、 オーディオデコーダ 1 1 7を制御し、 オーディオアクセスュニ ット単位のデータをデコードさせる。 さらに、 オーディオデコーダ制 御モジュール 2 1 7は、 オーディオデコーダ 1 1 7でのデコードの結 果得られるオーディォデータを、 オーディォ出力モジュール 2 2 1に 供給する。
ここで、 オーディオアクセスユニットとは、 オーディオデータの所 定のデ一夕量分 （例えば、 1ピクチャに同期して出力される分） であ る。 本実施の形態では、 オーディオアクセスユニットは、 例えば、 既 知の固定長であるとする。
「字幕デコーダ制御モジュール 2 1 8」
字幕デコーダ制御モジュール 2 1 8は、 バッファ制御モジュール 2 1 5内の字幕読み出し機能部 2 3 5 (第 3図） を操作して、 字幕デー タを符号化したデータ （字幕符号化データ） を、 字幕アクセスュニッ ト単位で、 バッファ制御モジュール 2 1 5のバッファ 2 1 5 Aから読 み出す。 また、 字幕デコーダ制御モジュール 2 1 8は、 内部に、 図示 せぬ字幕デコードソフトウェアを備えており、 バッファ 2 1 5 Aから 読み出したデータをデコードする。 さらに、 字幕デコーダ制御モジュ —ル 2 1 8は、 そのデコードの結果得られる字幕データ （字幕の画像 データ） を、 グラフィクス処理モジュール 2 1 9に供給する。
ここで、 字幕アクセスユニットとは、 字幕データの所定のデータ量 分 （例えば、 1ピクチャに同期して出力される分） である。 本実施の 形態では、 字幕アクセスユニットのサイズは、 例えば、 その字幕ァク セスュニッ卜の先頭に記述されていることとする。
「グラフィクス処理モジュール 2 1 9」
グラフィクス処理モジュール 2 1 9は、 プレイヤ制御モジュール 2 1 2の制御 （指示） にしたがい、 字幕デコーダ制御モジュール 2 1 8 からの字幕データの拡大や縮小を行い、 ビデオデコーダ制御モジユー ル 2 1 6からのビデオデータと加算 （オーバ一レイ） する。 さらに、 グラフィクス処理モジュール 2 1 9は、 字幕データとの加算後のビデ ォデ一夕のサイズ （画枠） を、 第 1図のビデオ出力端子 1 2 0に接続 されたビデオ出力装置の表示画面にあわせるための拡大または縮小等 を行い、 その結果得られるビデオデータを、 ビデオ出力モジュール 2 2 0に出力する。
また、 グラフィクス処理モジュール 2 1 9は、 スクリプト制御モジ ユール 2 1 1やプレイヤ制御モジュール 2 1 2の指示 （制御） に従い 、 メニューやメッセージ等を生成し、 出力ビデオデ一夕にオーバーレ ィする。
さらに、 グラフィクス処理モジュール 2 1 9は、 第 1図のビデオ出 力端子 1 2 0に接続されたビデオ出力装置のァスぺクト比と、 デイス ク 1 0 1に記録されたビデオデータのァスぺクト比を指示する情報等 とに基づいて、 ビデオ出力モジュール 2 2 0に出力するビデオデータ のアスペクト比の変換を行う。
即ち、 例えば、 ビデオ出力装置のアスペクト比が 16 : 9である場合に おいて、 ビデオデータのァスぺクト比を指示する情報が 4 : 3のァスぺ クト比を表しているときには、 グラフィクス処理モジュール 2 1 9は 、 ビデオ出力モジュール 2 .2 0に出力するビデオデータを、 横方向 （ 水平方向） にスクイーズ （縮小） 処理し、 左右に黒味を入れて出力す る。 また、 例えば、 ビデオ出力装置のアスペクト比が 4 : 3である場合 において、 ビデオデータのァスぺクト比を指示する情報が 16 : 9のァス ぺクト比を表しているときには、 グラフィクス処理モジュール 2 1 9 は、 ビデオ出力モジュール 2 2 0に出力するビデオデータを、 縦方向 (垂直方向） にスクイーズ （縮小） 処理し、 上下に黒味を入れて出力 する。 なお、 ビデオ出力装置のアスペクト比と、 ビデオデータのァスぺク ト比を指示する情報が表すアスペクト比とが、 いずれも、 4 : 3や 16 : 9 で、 同一である場合、 グラフィクス処理モジュール 2 1 9は、 ビデオ 出力モジュール 2 2 0に出力するビデオデ一夕を、 スクイーズ処理す ることなく、 そのまま出力する。
その他、 グラフィクス処理モジュール 2 1 9は、 例えば、 プレイヤ 制御モジュール 2 1 2からの要求に応じて、 現在処理中のビデオデー タをキヤプチヤする。 さらに、 グラフィクス処理モジュール 2 1 9は 、 そのキヤプチヤしたビデオデータを記憶し、 あるいは、 プレイヤ制 御モジュール 2 1 2に供給する。
「ビデオ出力モジュール 2 2 0」
ビデオ出力モジュール 2 2 0は、 第 1図のメモリ 1 1 3の一部を排 他的に占有して F IFO (F i rs t In Fi rs t Out) 2 2 0 A (バッファ） とし て使用し、 グラフィクス処理モジュール 2 1 9からのビデオデータを 一時的に記憶し、 また、 その FIF0 2 2 0 Aに記憶されたビデオデータ を適宜読み出して、 ビデオ出力端子 1 2 0 (第 1図） に出力する。
「オーディオ出力モジュール 2 2 1」
オーディオ出力モジュール 2 2 1は、 第 1図のメモリ 1 1 3の一部 を排他的に占有して FIF0 2 2 1 A (バッファ） として使用し、 オーデ ィォデコーダ制御モジュール 2 1 7 (オーディオデコーダ 1 1 7 ) か らのオーディオデータを一時的に記憶し、 また、 その F IF0 2 2 1 Aに 記憶されたオーディオデータを適宜読み出して、 オーディオ出力端子 1 2 1 (第 1図） に出力する。
さらに、 オーディオ出力モジュール 2 2 1は、 オーディオデコーダ 制御モジュール 2 1 7からのオーディオデータが、 左チャネルが 「主 音声」 のオーディオデータで、 右チャネルの 「副音声」 のオーディオ データであるデュアル（Dual) (ニケ国語） モードのオーディオデータ である場合、 あらかじめ指定された音声出力モードに従って、 オーデ ィォデコーダ制御モジュール 2 1 7からのオーディオデータを、 ォー ディォ出力端子 1 2 1に出力する。
即ち、 音声出力モードとして、 例えば、 「主音声」 が指定されてい るときには、 オーディオ出力モジュール 2 2 1は、 オーディオデコー ダ制御モジュール 2 1 7からのオーディオデータのうちの左チャネル のオーディォデ一夕を、 右チャネルのオーディォデータとしてコピー し、 その左チャネルと右チャネルのオーディオデータ （ 「主音声」 の オーディオデータ） を、 オーディオ出力端子 1 2 1に出力する。 また 、 音声出力モードとして、 「副音声」 が指定されているときには、 ォ —ディォ出力モジュール 2 2 1は、 オーディオデコーダ制御モジュ一 ル 2 1 7からのオーディオデータのうちの右チャネルのオーディオデ 一夕を、 左チャネルのオーディオデ一夕としてコピーし、 その左チヤ ネルと右チャネルのオーディオデータ （ 「副音声」 のオーディオデー 夕） を、 オーディオ出力端子 1 2 1に出力する。 さらに、 音声出力モ —ドとして、 「主 ·副」 が指定されているときには、 オーディオ出力 モジュール 2 2 1は、 オーディオデコーダ制御モジュール 2 1 7力 ら のオーディオデータを、 そのまま、 オーディオ出力端子 1 2 1に出力 する。
なお、 オーディオデコーダ制御モジュール 2 1 7からのオーディオ データが、 ステレオ（S t ereo)モードのォ一ディォデータである場合、 オーディォ出力モジュール 2 2 1は、 音声出力モードの指定にかかわ らず、 オーディオデコーダ制御モジュール 2 1 7からのオーディオデ 一夕を、 そのまま、 オーディオ出力端子 1 2 1に出力する。
ここで、 音声出力モードの指定は、 例えば、 ビデオコンテンツ再生 プログラム 2 1 0が生成するメニューが表示された画面等において、 ユーザがリモコン等を操作することにより対話的に行うことができる
[バッファ制御モジュール 2 1 5の構成]
次に、 第 3図は、 第 2図 Aおよび第 2図 Bのバッファ制御モジユー ル 2 1 5の構成例を示している。
バッファ制御モジュール 2 1 5は、 第 1図のメモリ 1 1 3の一部を 、 バッファ 2 1 5 Aとして排他的に使用し、 そのバッファ 2 1 5 Aに 、 ディスク 1 0 1から読み出されたデータを一時記憶させる。 また、 バッファ制御モジュール 2 1 5は、 バッファ 2 1 5 Aに記憶されたデ —夕を読み出して、 第 2図 Aおよび第 2図 Bのビデオデコーダ制御モ ジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 または 字幕デコーダ制御モジュール 2 1 8に供給する。
即ち、 バッファ制御モジュール 2 1 5は、 バッファ 2 1 5 Aの他、 メモリ 1 1 3の一部であるデータ先頭ポインタ記憶部 2 3 1、 および データ書き込みポインタ記憶部 2 3 2を有するとともに、 内部モジュ —ルとして、 ビデオ読み出し機能部 2 3 3、 オーディオ読み出し機能 部 2 3 4、 字幕読み出し機能部 2 3 5を有する。
バッファ 2 1 5 Aは、 例えば、 リングバッファであり、 ディスク 1 0 1から読み出されたデータを順次記憶し、 その記憶容量分のデータ を記憶した後は、 最も古いデータに上書きする形で、 最新のデータを 、 いわば無限ループ状に記憶していく d
データ先頭ボイン夕記憶部 2 3 1は、 バッファ 2 1 5 Aに記憶され たデ一夕のうち、 まだ、 バッファ 2 1 5 Aから読み出されていない最 も古いデータが記憶されている位置 （アドレス） を指すデータ先頭ポ インタを記憶する。 データ書き込みポインタ記憶部 2 3 2は、 ディスク 1 0 1から読み 出された最新のデータが書き込まれるバッファ 2 1 5 Aの位置 （アド レス） を指す書き込みポインタを記憶する。
ここで、 データ書き込みポインタが指す位置は、 バッファ 2 1 5 A に、 ディスク 1 0 1から読み出されたデータが記憶されるごとに、 図 中、 右回り （時計回り） に更新されていき、 データ先頭ポインタが指 す位置は、 バッファ 2 1 5 Aからのデータの読み出しに応じて、 図中 、 右回りに更新されていく。 したがって、 バッファ 2 1 5 Aに記憶さ れたデータのうち、 いわば有効なデータは、 データ先頭ポインタが指 す位置から、 右回りに、 データ書き込みポインタが指す位置までに記 憶されているデータである。
ビデオ読み出し機能部 2 3 3は、 第 2図 Aおよび第 2図 Bのビデオ デコーダ制御モジュール 2 1 6からの要求に応じて、 バッファ 2 1 5 Aからビデオストリーム （ビデオデータに関するエレメンタリストリ ーム） を読み出し、 ビデオデコーダ制御モジュール 2 1 6に供給する 。 オーディオ読み出し機能部 2 3 4も、 第 2図 Aおよび第 2図 Bのォ 一ディォデコーダ制御モジュール 2 1 7からの要求に応じて、 バッフ ァ 2 1 5 Aからオーディオストリーム （オーディオデータに関するェ レメン夕リストリーム） を読み出し、 オーディオデコーダ制御モジュ ール 2 1 7に供給する。 字幕読み出し機能部 2 3 5も、 第 2図 Aおよ び第 2図 Bの字幕デコーダ制御モジュール 2 1 8からの要求に応じて 、 バッファ 2 1 5 Aから字幕ストリーム （字幕データに関するエレメ ン夕リストリーム） を読み出し、 字幕デコーダ制御モジュール 2 1 8 に供給する。
即ち、 光ディスク 1 0 1には、 例えば、 MPEG (Moving P i c t ure Expe r t s Group) 2の規格に準拠したプログラムストリーム （MPEG2- Sys t em Program Stream) が記録されており、 バッファ 2 1 5 Aには、 光ディ スク 1 0 1から読み出されたプログラムストリームが記憶される。 こ のプログラムストリームは、 ビデオストリームや、 オーディオストリ ーム、 字幕ストリーム等の 1以上のエレメンタリストリ一ムが時分割 多重されている。 ビデオ読み出し機能部 2 33は、 プログラムストリ 一ムのデマルチプレクスの機能を有し、 バッファ 2 1 5 Aに記憶され たプログラムストリームから、 ビデオストリームを分離して読み出す 同様に、 オーディオ読み出し機能部 2 34も、 プログラムストリー ムのデマルチプレクスの機能を有し、 バッファ 2 1 5 Aに記憶された プログラムストリームから、 オーディォストリームを分離して読み出 す。 字幕読み出し機能部 23 5も、 プログラムストリームのデマルチ プレクスの機能を有し、 バッファ 2 1 5 Aに記憶されたプログラムス トリ一ムから、 字幕ストリームを分離して読み出す。
ここで、 ビデオ読み出し機能部 2 3 3は、 第 1図のメモリ 1 1 3の 一部であるビデオ読み出しボイン夕記憶部 24 1、 stream一 idレジス 夕 242、 および au一 informationOレジスタ 243を有している。 ビデオ読み出しポインタ記憶部 241は、 バッファ 2 1 5Aの、 ビ デォストリームが記憶された位置 （アドレス） を指すビデオ読み出し ポインタを記憶し、 ビデオ読み出し機能部 233は、 バッファ 2 1 5 Aの、 ビデオ読み出しボイン夕が指す位置に記憶されているデータを 、 ビデオストリームとして読み出す。 stream一 idレジスタ 242は、 バッファ 2 1 5 Aに記憶されたプログラムストリームを解析し、 その プログラムストリームの中から読み出すビデオストリ一ムを識別 （特 定） するための後述する stream—idを記憶する。 au_inf ormaUon 0レ ジス夕 243は、 ノ ッファ 2 1 5 Aからビデオストリームを読み出す ために必要な （ビデオストリームの読み出しに利用される） データで ある後述する au一 informationOを記憶する。
オーディオ読み出し機能部 2 34は、 第 1図のメモリ 1 1 3の一部 であるオーディオ読み出しポインタ記憶部 2 5 1、 stream_idレジス 夕 252、 および private一 stream_idレジスタ 2 53を有している。 オーディォ読み出しボイン夕記憶部 2 5 1は、 バッファ 2 1 5 Aの 、 オーディオストリームが記憶された位置 （アドレス） を指すオーデ ィォ読み出しポインタを記憶し、 オーディオ読み出し機能部 234は 、 バッファ 2 1 5Aの、 オーディオ読み出しポインタが指す位置に記 憶されているデータを、 オーディオストリームとして読み出す。 stre am— idレジス夕 2 52と private__stream_idレジスタ 2 5 3は、 バッフ ァ 2 1 5 Aに記憶されたプログラムストリームを解析し、 そのプログ ラムストリームの中から読み出すオーディォストリームを識別するた めの後述する 5 6&111ー1(1と0)：^&16_8 6&111—1(1を、 それぞれ記憶する。 字幕読み出し機能部 2 3 5は、 第 1図のメモリ 1 1 3の一部である 字幕 み出し機能フラグ記憶部 26 1、 字幕読み出しボイン夕記憶部
262、 stream— idレジスタ 26 3、 および private— stream_idレジス 夕 264を有している。
字幕読み出し機能フラグ記憶部 2 6 1は、 字幕読み出し機能フラグ を記憶する。 字幕読み出し機能フラグ記憶部 26 1に記憶された字幕 読み出し機能フラグが、 例えば 0である場合、 字幕読み出し機能部 2
35は機能動作せず、 字幕読み出し機能フラグ記憶部 26 1に記憶さ れた字幕読み出し機能フラグが、 例えば: Lである場合、 字幕読み出し 機能部 23 5は機能する。
字幕読み出しポインタ記億部 26 2は、 バッファ 2 1 5Aの、 字幕 ストリームが記憶された位置 （アドレス） を指す字幕読み出しポイン 夕を記憶し、 字幕読み出し機能部 2 3 5は、 ノ ッファ 2 1 5Aの、 字 幕読み出しボイン夕が指す位置に記憶されているデータを、 字幕スト リームとして読み出す。 stream— idレジスタ 2 6 3と private_stream一 idレジスタ 264は、 バッファ 2 1 5 Aに記憶されたプログラムスト リームを解析し、 そのプログラムストリームの中から読み出す字幕ス トリームを識別するための後述する stream_idと private_stream_idを 、 それぞれ記憶する。
[ディスク 1 0 1に記録されたデータのデータフォーマツトの説明
]
次に、 ディスク 1 0 1に記録されたデ一夕のデータフォーマットに ついて説明する。
第 4図は、 ディスク 1 0 1のディレクトリ構造を模式的に示してい る。
ディスク 1 0 1のファイルシステムとしては、 例えば、 IS0(Intern at ional Organization for Standardization) - 9660や、 UDF (Universa 1 Disk Format :http://www. osta. org/specs/)などで規定されたファ ィルシステムが用いられており、 ディスク 1 0 1に記録されたデ一夕 のファイルはディレクトリ構造により階層的に管理されている。 ここ で、 ファイルシステムは、 上述したファイルシステムに限定されるも のではない。
第 4図では、 ファイルシステムの基点を示すルート（root)ディレク トリに、 "VIDEO"ディレクトリが置かれ、 "VIDEO"ディレクトリには、 "CLIP"ディレクトリと、 "STREAM"ディレクトリとの 2つのディレクト リが置かれている。
"VIDEO"ディレクトリには、 "CLIP"ディレクトリと" STREAM"ディレ クトリとの 2つのディレクトリの他に、 "SCRIPT.DAT"ファイルと、 "P LAYLIST.DAT"ファイルの 2つのデータファイルが置かれている。
"SCRIPT.DAT"ファイルは、 スクリブトプログラムが記述されたスク リプトファイルである。 即ち、 "SCRIPT.DAT"ファイルには、 ディスク 1 0 1の再生形態をイン夕ラクティブなものとするために使用するス クリプトプログラムが記述されている。 この" SCRIPT. DAT"ファイルに 記述されたスクリブトプログラムは、 第 2図 Aおよび第 2図 Bのスク リプト制御モジュール 2 1 1によって解釈、 実行される。
"PLAYLIST.DAT"ファイルには、 ディスク 1 0 1に記録されたビデオ データ等のコンテンツの再生手順が記述されたプレイリスト （後述す る第 5図の PlayListO) が 1以上格納されている。
"CLIP"ディレクトリには、 1以上のクリップ情報ファイルが置かれ 、 "STREAM"ディレクトリには、 1以上のクリップストリームファイル が置かれる。 即ち、 第 4図では、 "CLIP"ディレクトリには、 3つのク リップ情報ファイル" 00001.CLP"， " 00002. CLP", " 00003. CLP"が置か れており、 " STREAM"ディレクトリには、 3つのクリップストリームフ アイル" 00001.PS"， " 00002.PS", " 00003.PS"が置かれている。
クリップストリームファイルには、 ビデオデ一夕、 オーディオデー 夕、 字幕データなどの 1以上のデータ （ストリーム） を圧縮、 符号化 して得られる 1以上のエレメン夕リストリ一ムを時分割多重化したプ ログラムストリームが格納されている。
クリップ情報ファイルには、 対応するクリップストリームファイル の性質等の、 クリップストリームに関する （ファイル） メタデータが 記述されている。
即ち、 クリップストリームファイルとクリップ情報ファイルとは、 1対 1に対応している。 第 4図では、 クリップストリームファイルに は、 5文字の数字 +ピリオド +"PS"という命名規則にしたがって、 フ アイル名が付されており、 クリップ情報ファイルには、 対応するクリ ップストリームファイルと同一の 5文字の数字 +ピリォド +"CLP"とい う命名規則にしたがって、 フアイル名が付されている。
従って、 ファイルが、 クリップストリームファイルまたはクリップ 情報ファイルのうちのいずれであるかは、 ファイル名の拡張子 （ピリ ォドより右側の部分） によって識別することができ、 さらに、 対応す るクリップストリームファイルとクリツプ情報ファイルとは、 フアイ ル名の拡張子以外の部分 （ピリオドより左側の部分） がー致するかど うかによって識別することができる。
以下、 ディスク 1 0 1に記録された各ファイルの詳細について説明 する。
rPLAYLIST.DAT J
第 5図は、 第 4図の" VIDEO"ディレクトリ下の" PLAYLIST.DAT"ファ ィルの内部構造 （シンタクス（syntax)) を示している。
ここで、 第 5図において、 "Syntax"の欄の記載がデータ構造を表し 、 "No: of bits"の欄の記載は、 対応する行の" Syntax"の欄のデ一夕 のビット長を表す。 さらに、 "Mnemonic"の欄の記載のうちの" bslbf" ( bit string left bit first)は、 対応する行の" Syntax"の欄のデータ が左のビットから送り出されることを意味し、 "uimsbf" (unsigned in teger most significant bit first)は、 対応する行の" Syntax"の欄 のデータが、 符号なし整数値であり、 最上位ビットから送り出される ことを意味する。 以下説明する、 第 5図と同様の図についても、 同様 である。
"PLAYLIST.DAT"ファイルにおいては、 その先頭から、 その名称 （フ アイル名） 等の情報を記述するための name_length (8ビット） と name .string (255バイ ト） が順次配置される。 即ち、 name一 lengthは、 その後に配置される name— stringのサイズを 、 バイト数で表す。 name— stringは、 "PLAYLIST. DAT"ファイルの名称 (ファイル名） を表す。
なお、 name一 stringについては、 その先頭から、 name_lengthで表さ れるバイト数までが有効な名称として使用される。 たとえば name_len gthが値 10である場合には、 name_stringの先頭から 10パイト分が有効 な名称として解釈される。
name— stringの後には、 number— of— P yLists (16ビット） が配置さ れる。 number— of— PlayListsは、 続く PlayLis t 0の個数を表す。 画 be r_oし PlayListsの後に、 その number_of_PlayListsの数だけの PlayLis tOが配置される。
P yListOは、 ディスク 1 0 1に記録されたクリップストリームフ アイルの再生手順が記述されたプレイリストであり、 以下のような内 部構造を有する。
即ち、 PlayListOの先頭には、 PlayLisし data_length (32ビット） が配置される。 PlayList_data_lengthは、 その PlayList 0のサイズを 表す。
PlayList— data一 lengthの後には、 + reserved_f or_ ord_al ignment (1 5ビット） と capture— enable— flag— PlayList (1ビット） が順次配置さ れる。 15ビットの reservedJor_word_alignmentは、 その後に配置さ れる 1ビットの capture_enable_nag_PlayListの位置で、 いわゆるヮ 一ドアライン（word aligmnent)をとるため （1 6ビットの位置に揃え るため） に配置される。 capture_enable— f lag_PlayListは、 PlayList 0によって再生されるビデオストリームに対応するビデオデータ （P1 ayLis )に属するビデオデータ） の、 光ディスク 1 0 1が再生される 第 1図のディスク装置内での 2次利用を許可するか否かを表す 1ビッ トのフラグである。 capture_enable_flag_PlayListが、 0または 1の うちの、 例えば 1である場合、 PlayListOに属するビデオデ一夕の 2 次利用が許可されていることを表し、 capture— enable—flag一 PlayLi st が、 0または 1のうちの、 例えば 0である場合、 PlayListOに属する ビデオデータの 2次利用が許可されていない （禁止されている） こと を表す。
なお、 第 5図では、 capture一 enable_f lag_JlayListを 1ビットとし たが、 その他、 capture_enable_flag_PlayListは、 複数ビットで構成 し、 PlayListOに属するビデオデータの 2次利用を、 いわば段階的に 許可するようにすることが可能である。 即ち、 capture_enable_flag_ PlayListは、 例えば、 2ビットで構成することができる。 そして、 ca pture_enable一 ag—PlayListの値が 00B (Bは、 その前の数字が 2進数 であることを表す） である場合には、 ビデオデータの 2次利用を禁止 し、 capture_enable_nag_PlayListの値が 01Bである場合には、 ビデ ォデータを、 64X64ピクセル以下のサイズに縮小して利用する 2次利 用の を許可することができる。 また、 capture—enable—flag—PlayLi stの値が 1 OBである場合には、 サイズの制限なしで、 ビデオデ一夕の 2次利用を許可することができる。
さらに、 上述のように、 ビデオデータの 2次利用にあたって、 サイ ズに制限を設けるのではなく、 用途に制限を設けるようにすることも 可能である。 即ち、 capture_enable一 ag_PlayListの値が 01Bである 場合には、 ビデオコンテンツ再生アブ.リケーシヨン 2 1 0 (第 2図 A および第 2図 B) のみでの 2次利用を許可し、 capture_enable_flag_ PlayListの値が 10Bである場合には、 第 1図のディスク装置内の、 ビ デォコンテンツ再生アプリケーション 2 1 0を含む任意のアプリケ一 シヨンによる 2次利用を許可することができる。 ここで、 第 1図のデ イスク装置内のビデオコンテンツ再生アプリケーション 2 1 0以外め アプリケーションとしては、 例えば、 壁紙ひ ックグラウンド）ゃスク リーンセーバーの表示の処理を行うアプリケーションなどがある。 なお、 capture— enable— flag— PlayListを、 上述のように、 2ビット とした場合、 その前に配置される reserved_for_word_alignmentは、 ワードァラインをとるために、 14ビットとなる。
また、 capture_enable一 f lag_PlayListにより、 ビデオデ一夕のディ スク装置内での 2次利用を許可する他、 ディスク装置外での 2次利用 を許可するようにすることも可能である。 ここで、 ビデオデータの、 ディスク装置外での 2次利用を許可する場合には、 ビデオデータは、 例えば、 ディスク装置に着脱可能な記録媒体やディスク装置に接続可 能な他の装置に着脱可能な記録媒体に記録され、 あるいはィンターネ ット等のネットワークを介して、 他の装置に送信 （配信） される。 こ の場合、 ビデオデータには、 そのビデオデータを記録媒体に記録する 回数や配信する回数を制限する情報を付加するようにすることができ る。
c ap t u r e— en ab 1 e— f 1 ag— P 1 ayL i s 11こ続レ て【ま、 P 1 ayL i s t_name_l engt h (8ビット） と PlayList一 name— string (255バイト） とが順次配置され る。 PlayLisし name— lengthは、 その後に配置される PlayLisし name_st ringのサイズを、 バイト数で表し、 PlayList_name_stringは、 PlayLi st()の名称を表す。
PlayList— name— stringの後には、 numb er_of_Pl ay I terns (16ビッ卜 ) が配置される。 11111111)6し0し？13 1161113は、 続く P 1 ay 11 em 0の個数を 表す。
number一 0し Playltemsの後には、 その number_of_PIayI temsの数だけ の P 1 ay 11 em ()の構造が記述される。 ここで、 1つの PlayList 0では、 PlayltemO単位で、 コンテンツの 再生手順を記述することができる。
また、 PlayList 0の中の、 number_of—Playl temsの数だけの Playl te m()それぞれに対しては、 その PlayList 0の中でユニークな ID (Identi fication)が付される。 即ち、 PlayList 0中の最初の PlayltemOには 、 IDとして 0番が付され、 以下、 続く PlayltemOに対して、 その出現 順に、 1番、 2番、 · · · と通し番号の IDが付される。
number— 0し Playltemsの数だけの PlayltemOの後には、 1つの PlayL istMarkOが配置される。 PlayListMarkOは、 PlayList 0にしたがつ て行われる再生の時間軸上の印となる後述する MarkOの集合で、 その 詳細については、 第 7図を参照して後述する。
「PlayItem()の説明」
次に、 第 6図は、 第 5図の PlayListOに含まれる PlayltemOの内部 構造を示している。
PlayltemOの先頭には、 length (16ビット） が配置され、 lengthは 、 それを含む PlayltemOのサイズを表す。
lengthに続レ てま、 Clip— Information— file— name— length (16ビッ ト） と Clip_Information__nie一 name (可変長） が順次配置される。 C1 ip— Information— file— name— lengthは、 その後に配置される CI ip— Info rmation一 file_nameのサイズを、 バイト数で表す。 CI ip_Informat ion_ file_nameは、 Playl tem()によって再生するクリップストリームファ ィル （第 4図の拡張子が PSのファイル） に対応するクリップ情報ファ ィル （第 4図の拡張子が CLPのファイル） のファイル名を表す。 なお 、 クリップストリームファイルおよびクリップ情報ファイルのフアイ ル名の、 上述した命名規則により、 Clip一 Information— file— nameから 、 PlayltemOによって再生するクリップ情報ファイルのファイル名を 認識し、 そのクリップストリームファイルを特定することができる。
Clip_Information— f ile— nameに続いては、 IN— time (32ビット） と 0 UT一 time (32ピット） が順次配置される。
IN— timeと OUT— timeは、 それぞれ、 CI ip— Informat ion— f i le— nameか ら特定されるクリップストリームファイルの再生開始位置と再生終了 位置を指定する時刻情報である。
IN_timeによれば、 クリップストリームファイルの （先頭を含む） 途中の位置を再生開始位置として指定することができ、 0UT_timeによ れば、 クリップストリームファイルの （最後を含む） 途中の位置を再 生終了位置として指定することができる。
ここで、 PlayltemOによれば、 Clip一 Information一 file— nameから特 定されるクリップストリームファイルの、 IN_timeから 0UT_timeまで の間のコンテンツが再生される。 この PlayltemOによって再生される コンテンツを、 以下、 適宜、 クリップという。
「PlayListMark()の説明」
次 ίこ、 第 7図は、 第 5図の PlayListOに含まれる PlayListMarkOの 内部構造を示している。
PlayListMarkOは、 上述したように、 その PlayListMarkOを含む P1 ayListO (第 5図） にしたがって行われる再生の時間軸上の印となる 、 0以上の MarkOの集合である。 1つの MarkOは、 PlayList 0にした がって行われる再生の時間軸上の 1つの時刻 （位置） を表す時刻情報 、 MarkOのタイプを表すタイプ情報、 およびタイプ情報がイベントを 発生させるタイプを表しているときの、 そのイベントの引数となる引 数情報を、 少なくとも有する。
即ち、 PlayListMarkOの先頭には、 length (32ビット） が配置され る。 lengthは、 それを含む PlayListMarkOのサイズを表す。 lengthの後には、 number_oし PlayLisし marks (16ビット） が配置さ れ、 1111110)6し0し？1& 1^3し11^ 3は、 それに続いて配置される Mark 0の 個数を表す。 number_oし PlayListjnarksの後には、 その number— oし P1 ayListjnarksの数だけ MarkOの構造が記述される。
MarkOの先頭には、 mark一 type (8ビット） が配置される。 mark_typ eは、 上述のタイプ情報であり、 それを含む MarkOのタイプを表す。 本実施の形態では、 MarkOのタイプとして、 例えば、 チヤプ夕（Cha pter)、 インデクス（Index)、 イベント（Event)の 3種類が用意されて いる。
タイプがチヤプタの MarkO (以下、 適宜、 チヤプ夕マークという） は、 PlayLis tOを分割する頭出しの単位であるチヤプ夕の先頭位置の 印である。 また、 タイプがインデクスの MarkO (以下、 適宜、 インデ クスマークという） は、 チヤプタを細分化した単位であるインデクス の先頭位置の印である。 タイプがイベントの MarkO (以下、 適宜、 ィ ベントマークという） は、 PlayListOにしたがったコンテンツの再生 中においてィベントを発生させる位置の印である。 イベントマークに よるイベントの発生は、 後述するように、 スクリプト制御モジュール 2 1 1に通知される。
ここで、 mark_typeの値と、 MarkOのタイプとの関係を、 第 8図に 示す。 第 8図によれば、 チヤプ夕マークの mark_typeには、 1がセッ トされる。 また、 インデクスマークの mark一 typeには、 2がセットさ れ、 イベントマークの mark_typeには、. 3がセットされる。 なお、 第 8図では、 mark_typeで表される 8ビットの値のうちの、 0と、 4乃 至 2 5 5は、 将来の拡張のための予約（reserved)とされている。
第 7図に戻り、 mark_typeの後には、 mark— name— length (8ビット） が配置される。 また、 MarkOの最後には、 mark— name一 s tr ing (24パイ 卜) が配置される。 mark— name— lengthと mark— name— stringは、 MarkO の名称を記述するためのものであり、 mark— name— lengthは、 mark— nam e一 stringの有効なサイズを、 mark— name_s tringは、 MarkOの名称を、 それぞれ表す。 従って、 mark— name— stringの先頭力 ら mark一 name— leng thが表すバイト数までが、 MarkOの有効な名称を表す。
mark_name一 lengthに続いては、 PlayList 0上で定義される MarkOを クリップストリームファイルと対応付ける 4つの要素 ref_to—PlayIte m一 id (16匕ッ 卜) 、 mark— t i me— stamp (32ヒッ卜リ 、 entry— ES— stream 一 id (8ビット） 、 entry_ES— private— stream— id (8ビット） が順次配 置される。
reし to— Playltem— idには、 MarkOが属する PlayltemOに対して通し 番号で付された IDが記述される。 ref— to— Playltemjdによって、 Mark 0 が属する PlayltemO (第 6図） が特定され、 ひいては、 第 6図で 説明したように、 クリップ情報ファイルとクリップストリ一ムフアイ ルが特定される。
mark— time— st ampは、 reし to— Playltem_idによって特定されるクリ ップストリームファイル内での MarkOが表す位置 （時刻） を表す。 ここで、 第 9図は、 PlayList 0， PlayltemO, クリップ、 およびク リップストリームファイルに格納されたプログラムストリームの関係 を示している。
第 9図では、 PlayListOは、 3つの PlayltemOから構成されており 、 その 3つの PlayltemOそれぞれには、' 通し番号で付される ID#0， #1 ， #2が付されている。 ここで、 以下、 適宜、 ID#iが付された Playltem 0を、 Playltem#iと記述する。
また、 第 9図では、 PlayItem#0， Playltem#l， ' Playltem によって 再生されるコンテンツであるクリップが、 それぞれ、 クリップ A、 ク リップ B、 クリップ Cとして示されている。
クリップの実体は、 第 6図の PlayltemOにおける Clip— Information — file_nameから特定される （クリップ情報ファイルから、 さらに特定 される） クリップストリームファイルに格納されたプログラムストリ ームのうちの、 IN_timeから 0UT_timeまでのプログラムストリームで ある。 第 9図では、 クリップ A、 クリップ B、 クリップ Cの実体とし てのプログラムストリームが、 プログラムストリーム A、 プログラム ストリーム B、 プログラムストリーム Cとして、 それぞれ示されてい る。
例えば、 第 9図において、 PlayListOにしたがって行われる再生の 時間軸上の位置 （時刻） tOの印となる MarkOにおいては、 その reし to 一 Playltem_idと mark— time_stampは、 次のように記述される。
即ち、 時刻 tOは、 Playltem#lの再生が行われる時刻であるため、 re f_to_PlayItem_idには、 その Playltem#lの IDである 1が記述される。 さらに、 時刻 tOでは、 Playltem#lによって、 クリップ Bの実体である プロクラムストリーム Bが再生されるため、 mark_time_s 即には、 プログラムストリーム Bが格納されたクリップストリームファイルに おける時刻 tOに相当する時刻が記述される。
再び、 第 7図に戻り、 en.try_ES— stream_idと、 entry_ES一 private— s tream— idは、 MarkOを、 特定のエレメン夕リストリームに関連付ける 場合に、 そのエレメン夕リストリームを特定するために使用される。 即ち、 entry— ES— stream_idには、 MarkOを関連付けるエレメン夕リス トリ一ム （が配置される、 後述する第 1 6図 Aおよび第 1 6図 B乃至 第 1 8図 Aおよび第 1 8図 Bに示す PES_packetO) の後述する stream —idが記述される。 また、 entry— ES— private— stream— idには、 必要に 応じて、 MarkOを関連付けるエレメン夕リストリーム （が配置される 、 後述する第 2 1図に示す private一 streaml_PES—payload()における P rivate— header 0) の後述する private_stream_idが記述される。
例えば、 ビデオストリーム # 1とビデオストリーム # 2が多重化さ れているクリップにおいて、 ビデオストリーム # 1を再生している場 合と、 ビデオストリーム # 2を再生している場合でチヤプ夕の発生時 刻を変更したいときには、 ビデオストリーム# 1再生時のチヤプタマ ーク発生時刻の MarkOの entry_ES_stream_idと entry_ES_private—str earn— idに、 ビデオス卜リ一ム # 1の stream— idと private一 stream一 idが 記述され、 また、 ビデオストリーム # 2再生時のチヤプタマーク発生 時刻の Mark 0 の en try— ES— stream— idと en try— ES— private— stream— id に、 ビデオストリーム # 2の stream_idと private stream_idが記述さ れる。
なお、 特定のエレメンタリストリ一ムに関連付けない MarkOの entr y— ES_stream— idと、 entry— ES_private_stream— idには、 例えば、 いず れも 0が記述される。
entry— ES_private_stream— idの後には、 mark— data (3 2ピット） が配置される。 mark_dataは、 MarkOがイベントマークである場合に 、 そのイベントマークによって発生されるイベントの引数となる引数 情報である。 なお、 mark一 dataは、 MarkOがチヤプ夕マ一クゃインデ クスマークである場合に、 そのチヤプタマ一クゃインデクスマークが 表すチヤプタゃィンデクスの番号として使用することも可能である。
「Clip()の説明」
次に、 第 4図の" CLIP"ディレクトリに置かれる、 拡張子が CLPのク リップ情報ファイルの内部構造について説明する。
第 4図では、 " CLIP"ディレクトリに、 3つのクリップ情報ファイル " 00001. CLP", " 00002. CLP", " 00003. CLP"が置かれており、 それぞれ には、 " STREAM"ディレクトリに置かれたクリップストリームファイル " 00001.PS", " 00002.PS", " 00003.PS"の性質等を示すメタデ一夕が格 納されている。
第 1 0図は、 そのようなクリップ情報ファイル ClipOの内部構造を 示している。
クリップ情報ファイル ClipOの先頭には、 presentation— starし tim eと presentation__end_time (いずれも 3 2ビット） が、 順次配置され る。 presentation— starし timeと presentation— end— timeは、 クリッフ 情報ファイル ClipOに対応するクリップストリームファイル （に格納 されているプログラムストリーム) の先頭と最後の時刻を表す。 なお 、 クリップストリームファイルの時刻は、 MPEG2_Systemの時刻で使わ れている 90kHzの倍数で記述される。
present at ion— end一 t ime l続レ て【 、 reserved— for— word— a 1 ignment (7ビット） と capture— enable— flag— Clip (1ビット） が順次配置され る。 7ビットの reserved— for_word—al ignmentは、 ワードァラインをと るためのもので、 capture— enable_flag—Cl ipは、 上述した第 5図の ca pture_enable— flag_PlayListと同様に、 ビデオデータの 2次利用を許 可するか否かを表すフラグである。
伹し、 第 5図の capture— enable_f lag— PlayListは、 PlayListOによ つて再生されるビデオストリームに対応するビデオデータ （PlayList 0に属するビデオデータ） の 2次利用を許可するか否かを表すのに対 して、 第 1 0図の capture一 enable—flag_Clipは、 クリップ情報フアイ ル ClipOに対応するクリップストリームファイルに格納されているビ デォストリーム （ビデオのエレメンタリストリーム） に対応するビデ ォデ一夕の 2次利用を許可するか否かを表す。 従って、 第 5図の capt ure enable flag PlayListと、 第 1 0図の capture— enable flag Clip とでは、 2次利用を許可するビデオデータの単位 （範囲） が異なる。 なお、 第 1 0図の capture—enable一 flag— CI ipも、 第 5図の capture一 enable—flag_PlayListで説明したように、 1ビットではなく、 複数ビ ットとすることが可能である。
capture_enable— f lag— CI ipの後には、 number— of— streams (8ビッ卜 ) が配置され、 この number_oし streamsには、 それに続く Streamlnf o ( )構造の個数が記述される。 従って、 number一 0し streamsに続いては、 その number_oし Streamsの数だけ、 Streamlnf o 0の構造が記述される StreamlnfoOの先頭には、 length (16ビット） が配置され、 この le ngthは、 それを含む StreamlnfoOのサイズを表す。 lengthに続いては 、 stream_id (8ビット） と private_stream_id (8ビット） が配置され ており、 この stream— idと private— stream— idによって、 Streamlnf o 0 に関連付けるエレメンタリストリームが特定 （識別） される。
ここで、 第 1 1図は、 エレメン夕リストリームを識別する streamj dおよび、 private_stream_idと、 エレメン夕リストリームとの関係を示 している。
st ream一 idは、 MPEG2- System規格において規定されているのと同一 のものであり、 その値は、 MPEG2- System規格において、 エレメンタリ ストリーム （データ） の属性 （種類） ごとに、 あらかじめ決められて いる。 従って、 MPEG2- System規格で定義されている属性のエレメン夕 リストリームは、 stream_idだけで特定することができる。
本実施の形態では、 MPEG2- System規格において規定されていない属 性のエレメン夕リストリームも扱うことが可能になっており、 privat e— stream— idは、 MPEG2- System規格において規定されていない属性の エレメンタリストリ一ムを識別するための情報である。 第 1 1図では、 MPEGで規定されている符号化 （復号） 方式でェンコ —ドされたビデオのエレメン夕リストリーム、 ATRAC (Adaptive TRans form Acoustic Coding)方式でエンコードされたオーディオのエレメ ン夕リストリーム （以下、 適宜、 ATRACオーディオストリームという ) 、 LPCM (Linear Pulse Code Modulation)方式でエンコードされたォ 一ディォのエレメンタリストリーム (以下、 適宜、 LPCMオーディオス トリームという） 、 字幕のエレメン夕リストリーム （以下、 適宜、 字 幕ストリームという） の 4つの属性のエレメンタリストリームについ て、 stream一 idおよび private_stream_idとの関係を示している。
MPEG2- System規格では、 MPEGで規定されている符号化方式でェンコ 一ドされたビデオのエレメンタリストリームは、 OxEO乃至 OxEFの範囲 の値を （Oxは、 その後に続く文字列が 1 6進数であることを表す） 、 エレメン夕リストリームを識別する stream_idとして用いて多重化す ることが規定されている。 従って、 MPEGで規定されている符号化方式 でエンコードされたビデオのエレメン夕リストリームについては、 Ox E0乃至 OxEFの範囲の値の stream一 idで識別することができる 16本のビ デォのエレメンタリストリームを、 プログラムストリームに多重化す ることができる。
なお、 MPEGで規定されている符号化方式でェンコ一ドされたビデオ のエレメン夕リストリームの識別は、 OxEO乃至 OxEFの範囲の値の stre am一 idで行うことができるので、 pr ivate_stream一 idは不要である （無 視することができる） 。 .
一方、 MPEG2- Systemでは、 ATRACオーディオストリーム、 LPCMォ一 ディォストリーム、 字幕ストリームについては、 stream— idは定義さ れていない。
そこで、 本実施の形態では、 MPEG2- Systemで stream— idが定義され ていないエレメン夕リストリームについては、 その stream_idに、 MPE G2- Systemにおいて private— st ream_lという属性を表す値である OxBD を採用し、 さらに、 第 1 1図に示すように、 private— stream_idを用 いて識別 （特定） を行うこととしている。
即ち、 ATRACオーディオストリームの識別には、 0x00乃至 OxOFの範 囲の値の private_stream一 idが使用される。 従って、 プログラムスト リームには、 16本の ATRACオーディォストリームを多重化することが できる。 また、 LPCMオーディオストリームの識別には、 0x10乃至 OxlF の範囲の値 private—stream— idが使用される。 従って、 プログラムス トリームには、 16本の LPCMオーディオストリームを多重化することが できる。 さらに、 字幕ストリームの識別には、 0x80乃至 0x9Fの範囲の 値の private_streain_Jdが使用される。 従って、 プログラムストリー ムには、 32本の字幕ストリームを多重化することができる。
なお、 stream_idおよび private_stream—idについては、 さらに後述 する。
第 1 0図に戻り、 private_stream—idの後には、 Stat iclnfo 0 , res erved— for— word—alignment (8ビット） が順次配置される。 Staticlnf οθには、 (その StaticInfoOを含む StreamlnfoOに記述された) str eam_idおよび private—stream_idによって特定されるエレメンタリス トリームの再生中に変化しない情報が記述される。 StaticInfoOの詳 細については、 第 1 2図を参照して後述する。
reserved—f or一 word— al ignmentは、 ヮ一ドアライン とるために使 用される。
reserved— f or— word— al ignmenUこ続レ てま、 number— of— Dynamic Info (8ビット） が配置され、 number_oし Dynamiclnfoは、 その後に続いて 配置される pts__change— point (32ビット） と Dynamiclnfo 0のセット の数を表す。
従って、 number— of— Dynamiclnfoiこ続レ てま、 その number— of一 Dynam ic Infoの数だけのセット数の pts— change— pointと Dynamic Info 0の構 造が記述される。
pts_change— pointは、 それとセットになっている Dynamiclnf o 0の 情報が有効になる時刻を表す。 ここで、 エレメン夕リストリームの先 頭の時刻を表す pts_change_pointは、 そのエレメンタリストリームが 格納されたクリップストリームファイルに対応するクリップ情報ファ ィル ClipOの最初に記述される presentation_starし timeに等しい。
Dynamiclnf 0 () ίこ fま、 stream一 idおよび private— stream— idiこよって 特定されるエレメンタリストリームの再生中に変化する、 いわば動的 な情報が記述される。 DynamicInioOに記述された情報は、 それとセ ットになっている p t s一 change— po i n tが ¾す再生時刻となったときに有 効になる。 なお、 DynamicInioOの詳細については、 第 13図を参照 して後述する。
number_of_DynamicInf oCD^7c:t† -i2;ッ卜の pts— change— pointと Dyn amicInfoOの後には、 EPjnap 0が配置される。 なお、 EPjnapOについ ては、 第 14図を参照して後述する。
rstaticInfoOの説明」 '
次に、 第 12図を参照して、 第 10図の StaticInfoOの詳細につい て説明する。
第 12図は、 StaticInfoOのシンタクスを示している。
StaticInfoOは、 対応するエレメンタリストリームの属性 （種類） により内容が異なっている。 StaticInfoOに対応するエレメンタリス トリ一ムの属性は、 その StaticInfoOを含む第 10図の StreamlnfoO に含まれる stream一 idと private stream idにより判断される。 StaticInfoOに対応するエレメン夕リストリームがビデオストリー ムである場合（stream==VIDEO)、 Stat iclnf o 0は、 picture— size (4ビ ット） ， frame_rate (4ビット） ， および cc— flag (1ビット） と、 ヮ 一ドアラインをとるための reserved— forー爾 d—ali職 en tとで ft成さ れる。
picture_sizeは、 ビデオストリームに対応するビデオデータ （によ つて表示される画像） の大きさを表す。 frame_rateは、 ビデオストリ ームに対応するビデオデータのフレーム周波数を表す。 cc_flagは、 ビデオストリームにクローズドキヤプション（Closed Caption)データ が含まれているか否かを表す。 即ち、 例えば、 ビデオストリームにク ローズドキヤプションデータが含まれている場合には、 cc_flagは 1 とされ、 ビデオストリームにクローズドキャプションデータが含まれ ていない場合には、 cc_flagは 0とされる。
StaticInfoOに対応するエレメン夕リストリームがオーディオスト リームである場合（stream==AUDIO)、 Stat iclnf o 0は、 audio_languag e— code (16ビッ卜) ， channel— configurat ion (8ビッ卜) ， lfe— exis tence (1ビット) 、 および samp 1 ing一 frequency (4ビット) と、 ヮー ドアラインをとるための reserved— foreword— alingmentとで構成され る。
audio_language_codeには、 オーディオストリームに含まれている オーディォデータの言語を表すコ一ドが記述される。 channeし conf ig urationは、 モノラル（mono)/ステレオ' (stereo)/マルチチャネル等の 、 オーディオストリームに含まれているオーディォデータの属性を表 す。 lfe_existenceは、 オーディオストリームに低域強調チャネルが 含まれているかどうかを表し、 含まれていれば 1となり、 含まれてい なければ 0となる。 sampling frequencyは、 オーディオストリームに 含まれているオーディォデータのサンプリング周波数を示す情報であ る。
StaticInfoOに対応するエレメンタリストリームが字幕ストリ一ム である場合（stream==SUBTITLE)、 Staticlnfo 0は、 subt i t le_languag e_code (16ビット） および configurable— flag (1ビット） と、 ワード ァラインをとるための reserved—for一 word— alingmentとで構成される subtitle_language一 codeには、 字幕ストリームに含まれている字幕 データの言語を表すコードが記述される。 configurable_flagは、 字 幕ストリームに含まれている字幕データの表示をデフォルトの表示方 式から変更することを許可するか否かを表す情報で、 例えば、 表示方 式の変更が許可されている場合には 1が記述され、 許可されていない 場合には 0が記述される。 なお、 字幕データの表示方式としては、 字 幕データの表示サイズや、 表示位置、 表示色、 表示パターン （例えば 、 点滅表示など） 、 表示方向 （例えば、 垂直方向や水平方向） などが ある。
rDynamicInfoOの説明」
次に、 第 13図を参照して、 第 10図の DynamicInfoOの詳細につ いて説明する。
第 1 3図は、 DynamicInfoOのシンタクスを示している。
DynamicInfoOの先頭には、 ワードァラインのための reserved_for一 word— alignment (8ビット） が配置されており、 その後に続く要素は 、 DynamicInfoOに対応するエレメンタリストリームの属性により内 容が異なっている。 DynamicInfoOに対応するエレメン夕リストリ一 ムの属性は、 第 12図で説明した StaticInfoOにおける場合と同様に 、 DynamicInfoOを含む第 10図の StreamlnfoOに含まれる stream_id と private_stream_idにより判断される。
DynamicInfoOには、 第 10図で説明したように、 エレメンタリス トリームの再生中に変化する動的な情報が記述される。 この動的な情 報は、 特に限定されるものではないが、 第 1 3図の実施の形態では、 DynamicInfoOに対応するエレメン夕リストリームに対応するデータ 、 即ち、 エレメンタリストリームが処理されることによって出力され るデータの出力属性 （エレメンタリストリームから得られるデータの 出力属性） が、 DynamicInfoOに記述される。
具体的には、 DynamicInfoOに対応するエレメンタリストリームが ビデオストリ一ムである場合（stream==VIDE0)、 Dynamiclnf o 0は、 di splay一 aspect一 rat io (4ビッ卜) と、 ワードァラインのための reserve d— for— word— al ingmentとで構成される。 diplay— aspect— rat ioには、 ビデオストリームに対応するビデオデータの出力属性 （表示方式） と しての、 例えば、 そのビデオデータのアスペクト比が記述される。 即 ち、 diplay_aspecし ratioには、 例えば、 アスペクト比が、 16:9また は 4:3のうちのいずれであるかを表す情報が記述される。 なお、 ビデ ォストリームの DynamicInfoOには、 アスペクト比の他、 例えば、 ビ デォデータによって表示される画像のサイズ （X画素 XY画素） など を記述することが可能である。
DynamicInfoOに対応するエレメン夕リストリームがオーディォス トリームである場合（stream==AUDI0)、 Dynamiclnfo 0は、 channel— as signment (4ビット) と、 ワードァラインをとるための reserved— for— word— al ingmentとで構成される。 channel— assignmentには、 ォ一ティ ォストリームに 2チャネルのォ一ディォデータが含まれている場合に 、 その 2チャネルの出力属性 （出力方式） が記述される。 即ち、 chan nel assignmentには、 オーディオデータが、 ステレオまたはデュアル (ニケ国語） のうちのいずれのチャネル割り当てがされているもので あるかを表す情報が記述される。
DynamicInfoOに対応するエレメン夕リストリームが字幕ストリー ムである場合（stream==SUBTITLE)、 Dynamiclnf o 0は、 ワードァライ ンをとるための reserved一 for一 word一 alingmentで構成される。 即ち、 第 1 3図の実施の形態では、 字幕ストリームに関しては、 動的な情報 としての出力属性は定義されていない。
「EP— mapOの説明」
次に、 第 1 4図を参照して、 第 1 0図の EP— mapOの詳細について説 明する。
第 1 4図は、 EPjnapOのシンタクスを示している。
EPjnapOには、 その EP_map 0を含む第 1 0図のクリップ情報フアイ ル ClipOに対応するクリップストリームファイルに格納されたプログ ラムストリームに多重化されているエレメンタリストリーム毎に、 各 エレメンタリス卜リームの、 デコードを開始することができるデコ一 ド開始可能点 （エントリポイント） の情報が記述される。
ここで、 固定レートのストリームについては、 デコード開始可能点 は、 計算によって求めることができるが、 可変レートのストリーム、 あるいは MPEG規格にしたがって符号化されたビデオストリームのよう に、 ビデオアクセスアクセスユニットごとにサイズが異なるストリー ムについては、 デコード開始可能点は、 計算によって求めることがで きず、 実際にストリームを解析しないと見つけることができない。 デ コード開始可能点を迅速に認識することは、 ランダムアクセスを行う ために重要であり、 EPjnapOによれば、 デコード開始可能点を迅速に 認識することができる。
なお、 MPEG2- Videoでは、 Sequencejieader 0 (シーケンスヘッダ） 等を含めたィントラピクチャの先頭が、 デコード開始可能点である。
EP_map 0の先頭には、 ヮードアラインのための reserved_for_word_ alignment (8ビット） が配置されており、 続いて number_oし s tream_i d— entries (8ビット） が配置されている。 number_of_s t reara_i d_en t r iesは、 EP— mapOにデコード開始可能点の情報が記述されているエレ メン夕リストリームの本数を表す。
number_of—st ream—id— entriesの後には、 エレメン夕リストリーム を識別するための情報と、 そのエレメンタリストリームのデコード開 始可能点の情報とが、 number— 0し streamjd— entriesが表す数だけ繰 り返し配置される。
即ち、 number_oし stream_id_entriesの直後には、 エレメン夕リス トリ一ムを識別する情報としての streamjd (8ビット） と private_st ream一 id (8ビット） が配置され、 それに続けて、 number_of_EP_entri es (32ビット） が配置される。 number_oし EP_entriesは、 その直前の streamjdと private— stream— idで識別 （特定） されるエレメン夕リス 卜リームのデコード開始可能点の数を表す。
number_oし EP— entriesの後には、 その直前の stream— idと private— s tream_idで特定されるエレメンタリストリームのデコード開始可能点 の情報としての PTS— EP— start (32ビット） と RPN— EP_s tar t (32ビット ) とのセットが、 number_of— EP— entriesが表す数だけ繰り返し配置さ れる。
デコード開始可能点の情報の 1つである PTS一 EP— startは、 上述のよ うに stream_idと private_stream_idで特定されるエレメン夕リストリ ームが多重化されているプログラムストリームが格納されたクリップ ストリームファイル内での、 デコード開始可能点の時刻 （再生時刻） を表す。 デコード開始可能点の情報の他の 1つである RPN_EP_startには、 上 述のように stream_idと private一 stream_idで特定されるエレメン夕リ ストリームが多重化されているプログラムストリームが格納されたク リップストリームファイル内での、 デコード開始可能点の位置を、 プ ログラムストリームの packO単位で数えたときの値が記述される。 な お、 本実施の形態では、 packOのサイズは 2048バイトで固定であると する。 また、 本実施の形態では、 ディスク 1 0 1 (第 1図） の 1セク 夕が、 2048バイトであるとする。
ここで、 ビデオストリームについては、 そのデコード開始可能点 （ エントリポイント） の直前に、 後述する private—st ream— 2パケット （ private— stream一 2の属性の PES— packet 0) が配置されている。 privat e_stream— 2パケットは、 その private— stream— 2パケットから、 次の pr ivate— stream— 2パケットまでの間に配置されているビデオストリーム をデコードするのに利用される情報が格納されている。 このため、 ビ デォストリームについては、 デコード開始可能点の情報としての RPN_ EP_startには、 実際のデコード開始可能点そのものではなく、 実際の デコード開始可能点の直前に配置されている private_stream一 2バケツ 卜の先頭の位置が記述される。
また、 EPjnapOにおいて、 デコード開始可能点の情報としての PTS_ EP一 startと RPN_EP_startとのセットは、 s tream一 idと private_s tream_ idで特定されるエレメン夕リストリームごとに、 あらかじめ、 昇順に ソートされている。 これにより、 デコ一ド開始可能点の情報としての ?丁3_6?—31& と1^1£1)__51&1^とのセットは、 二分探索が可能となって いる。
なお、 可変レートのストリームや、 ビデオアクセスアクセスュニッ トごとにサイズが異なるストリームを対象としたランダムアクセスの 方法は、 例えば、 特開 2000-341640号公報 （特願平 11-317738号） など に記載されている。
「クリップス卜リームファイルの説明」
次に、 第 4図の" STREAM"ディレクトリに置かれる、 拡張子が PSのク リップストリームファイル （第 4図では、 " 00001.PS"， " 00002.PS", "00003.PS") の内部構造について説明する。
クリップストリームファイルは、 MPEG- 2 System (ISO/IEC 13818-1 )に定義された MPEG2_Program_Stream()をベースに構成されている。 即ち、 第 1 5図 Aおよび第 1 5図 Bは、 MPEG- 2 Sys tem (ISO/IEC 13 818- 1:2000)規格に記述されている Table2- 31， Table2-32, Table2 - 33 を示している。
クリップストリ一ムフアイルに格納されたプログラムス卜リームは 、 MPEG - 2 System規格の Table2- 31に定義されている MPEG2—Prograin_St reamOであり、 1つ以上の packOと、 1つの MPEG— program— end_code で構成される。 なお、 MPEG2_Program_Stream()の説明は、 · 特許第 2785 220号などにも記載されている。
1つの packOは、 MPEG-2 System規格の Table2- 32に定義されている ように、 1つの Packjieader ()と、 任意の数の PES_packet 0とで構成 される。 Pack— header 0の詳細は、 MPEG- 2 System規格の Table2- 33に 定義されている。
ここで、 MPEG-2 System規格では、 packOのサイズは、 可変長とし て定義されているが、 ここでは、 第 14図で説明したように、 2048バ イトで固定であるとする。 さらに、 ここでは、 1つの pack 0の PES— pa cketOの数は、 1つ、 2つ、 または 3つとする。 PackOが後述する pr ivate—stream—2パケットで始まる場合、 その直後 （同じ PackO内） に 対応するビデオストリ一ムの PES— packet 0が必ず存在する。 またこれ に加えて 3つ目の PES_packet ()として padding_packet (パディングパ ケット） を置くことができる。 なお privaie_stream_2パケットは必ず Pack 0の先頭におかれる。
PackOが private_stream— 2パケットで始まらない場合には、 PackO の先頭にはビデオ、 オーディオ、 字幕などのコンテンツデータの格納 された PES—packet 0が置かれる。 これに加えて 2つ目の PES— packet 0 として padding_packet (パディングパケット） を置くことができる。 第 1 6図 Aおよび第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 Bは、 MPEG- 2 System規格の Table2- 17で定義されている PES一 packet 0を示し ている。
PES— packet 0は、 packet— star t—code』refix， stream一 id、 および P ES_packet_length (第 1 6図 Aおよび第 1 6図 B) と、 stream_id等 により構造の変化するヘッダ部分 （stuffing一 byteを含む） （第 1 6 図 Aおよび第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 B) と、 PES一 pa cket_data_byte (第 1 8図 Aおよび第 1 8図 B ) とに大別することが できる。 なお、 PES— packet 0が、 padding_packetである場合（stream_ id==padding一 stream)、 PES— packet— data— byteに代えて、 padding— byt e (OxFF) (第 1 8図 Aおよび第 1 8図 B) が必要な数だけ繰り返し配 置される。
ここで、 PES_packet()のヘッダ部分には、 第 1 6図 Aおよび第 1 6 図 B、 ならびに、 第 1 7図 A、 第 1 7図 Bおよび第 1 7図 Cに示すよ うに、 PTS(Presentation Time Stamp)と呼ばれる表示タイミングを示 す情報と、 DTS(Decoding Time Stamp)と呼ばれるデコードタイミング を示す情報とを配置することができる。 本実施の形態では、 すべての アクセスユニット （MPEG2- Systemで定義された、 エレメン夕リストリ ームを構成するデコード単位） に対して PTSが付加され、 MPEG2- Syste mに定める場合に DTSが付加されるとする。
プログラムストリームに多重化されるエレメン夕リストリームは、 PES— packetOの PES— packeし data_byte (第 1 8図 Aおよび第 1 8図 B ) に格納される。 そして、 PES_packet()の stream_idには、 その PES_p acket一 data_byteに格納されたエレメンタリストリ一ムを識別するた めに、 そのエレメン夕リストリームの属性に応じた値が記述される。
PES— packetOの stream_idに記述される値と、 エレメンタリストリ —ムの属性 （種類） との関係は、 MPEG- 2 System規格の Table 2- 18に 定義されている。 ここで、 第 1 9図 Aおよび第 1 9図 Bに、 MPEG- 2 S ystem規格の Table 2- 18を示す。
本実施の形態では、 第 1 9図 Aおよび第 1 9図 Bに示した MPEG- 2 S ystem規格で定義されている stream— idのうちの、 例えば、 第 2 0図に 示す値を採用する。
即ち、 本実施の形態では、 10111101B, 10111110B, 10111111B, 110 χχχχχΒ, ΙΙΙΟχχχχΒの 5パターンを、 stream_idの値として採用する。 なお、 "X"は、 0または 1のうちの任意の値を表す。
そして、 private_stream一 1と呼ばれる属性のエレメンタリストリー ムの PES— packet 0の stream— idは、 第 2 0図にしたがい、 10111101Bと される。 また、 padding_packetの PES_packet 0の stream一 idは、 第 2 0図にしたがい、 10111110Bとされる。 さらに、 pr ivate_s tream一 2と 呼ばれる属性のエレメンタリストリームの PES— packet 0の stream_id は、 第 2 0図にしたがい、 10111111Bとされる。
また、 MPEGで定義されたオーディオストリーム （オーディオのエレ メンタリストリーム） の PES— packet 0の stream_idは、 ΙΙΟχχχχχΒとさ れる。 なお、 ΙΙΟχχχχχΒのうちの下位 5ビット xxxxxは、 オーディオス トリ一ムを区別するオーディォストリームナンパであり、 プログラム ストリーム （MPEG2_Program— StreamO) には、 このオーディオストリ ームナンパで区別することのできる数である 3 2 (= 25) 本のォ一 ディォストリーム （MPEGで定義されたオーディオストリーム） を多重 化することができる。
さらに、 MPEGで定義されたビデオストリーム （ビデオのエレメンタ リストリーム） の PES—packetOの stream_idは、 ΙΙΙΟχχχχΒとされる。 なお、 ΙΙΙΟχχχχΒのうちの下位 4ビット xxxxは、 ビデオストリームを 区別するビデオストリームナンパであり、 プログラムストリームには 、 このビデオストリームナンパで区別することのできる数である 1 6 (= 24) 本のビデオストリーム （MPEGで定義されたビデオストリー ム） を多重化することができる。
ところで、 stream一 idが ΙΙΙΟχχχχΒの PES_packet()は、 MPEGで定義さ れたビデオストリームを格納するために使用され、 streamjdが ΙΙΟχχ xxxBの PES— packetOは、 MPEGで定義されたオーディォストリームを格 納するために使用される。 一方、 MPEGで定義されていない符号化方式 (たとえば ATRAC方式） のエレメンタリストリームを格納するのに使 用する PES一 packet 0の stream一 idは、 MPEGでは規定されておらず、 従 つて、 MPEGで定義されていない符号化方式のエレメンタリストリーム は、 MPEGで定義されたビデオストリームやオーディォストリームと同 様に、 単純に、 stream— idを指定して、 PES一 packet 0に格納すること はできない。
そこで、 本実施の形態では、 private_stream_lの PES_packet ()の PE S_packeし data—byteを拡張し、 MPEGで定義されていない符号化方式の エレメンタリストリームを格納する。
ここで、 private— stream_lの PES一 packet ()の、 拡張した PES— packet —data .byteを、 rivate streaml— PES— payloadOと c:述する。 「private— streaml一 PES— payload 0の説明」
第 2 1図は、 private— streamし PES_payload()のシンタクスを示し ている。
private_streaml_PES_payload()は、 private— header 0と private— p ayloadOとで構成される。 private_payload 0には、 ATRACオーディオ ストリームや、 LPCMオーディオストリーム、 字幕ストリームなどの、 MPEGで定義されていない符号化方式のエレメン夕リストリームが格納 される。
private— header 0の先頭には、 private— stream_id (8ビッ卜） が配 置される。 private— stream—idは、 pr ivate_payload 0に格納されるェ レメンタリストリームを識別する識別情報で、 その属性 （種類） に応 じて、 例えば、 以下のような値とされる。
即ち、 第 2 2図は、 private_stream_idの値と、 private— payload 0 に格納されるエレメン夕リストリームの属性との関係を示している。 第 2 2図では、 OOOOxxxxB, OOOlxxxxB, ΙΟΟχχχχχΒの 3パターンが 、 private_stream— idの値として採用されている。 なお、 "x"は、 第 2 0図における場合と同様に、 0または 1のうちの任意の値を表す。 第 2 2図によれば、 ATRACオーディオストリームが private_payload 0に格納される private— streaml— PES— payloadOの private— stream— id は、 OOOOxxxxBとされる。 なお、 OOOOxxxxBのうちの下位 4ビット xxxx は、 ATRACオーディォストリームを区別するオーディォストリームナ ンパであり、 プログラムストリーム (MPEG2_Program_StreamO) には 、 このオーディォストリームナンパで区別することのできる数である 1 6 (= 2 ) 本の ATRACオーディオストリームを多重化することがで きる。
さらに、 第 2 2図によれば、 LPCMオーディオストリームが private_ payloadOに格納される private— streaml一: PES— payloadO ©private_s t ream一 idは、 OOOlxxxxBとされる。 なお、 OOOlxxxxBのうちの下位 4ビ ット xxxxは、 LPtMオーディォストリームを区別するオーディォストリ —ムナンパであり、 プログラムストリームには、 このオーディオス卜 リームナンパで区別することのできる数である 1 6 (= 24) 本の LPC Mオーディォストリームを多重化することができる。
また、 第 2 2図によれば、 字幕ストリームが private— payloadOに 格納される private— s eaml— PES— payloadO O private_stream_id¾, ΙΟΟχχχχχΒとされる。 なお、 ΙΟΟχχχχχΒのうちの下位 5ビット xxxxxは 、 字幕ストリームを区別する字幕ストリームナンパであり、 プロダラ ムストリームには、 この字幕ストリームナンパで区別することのでき る数である 3 2 (= 25) 本の字幕ストリームを多重化することがで きる。
ここで、 第 2 0図と第 2 2図の関係をまとめたものが、 上述した第 1 1図である。
第 2 1図に戻り、 private— streaml— PES— payloadOにおいて、 priva te— stream_idに続く要素は、 private一 payload 0に格納されるエレメ ン夕リストリームの属性により内容が異なっている。 private_payloa d()に格納されるエレメンタリストリ一ムの属性は、 privatejieader ( )の先頭の private一 stream_idにより判断される。
private— payloadOに格納されるエレメンタリストリームが ATRACォ 一ディォストリームである場合（private一 stream— id==ATRAC)、 将来の 拡張用の reserved— for_future— use (8ビット） が配置され、 その後、 AU_locator (16ビット） が配置される。 AU— locatorは、 その AU_locat orの直後の位置を基準として、 private_payload()に格納された ATRAC オーディォストリームのオーディォアクセスュニット （ATRACオーデ ィォアクセスュニット） （オーディオフレーム） の先頭位置を表す。 private_payload()にオーディォアクセスュニットが存在しない場合 、 Allocatorには、 例えば OxFFFFが記述される。
private_payload()に格納されるエレメン夕リストリームが LPCMォ —ディォストリームである場合（private— stream_id==LPCM)、 fs— flag (1ビッ卜) ， reserved— for— future— use (3ビッ卜) ， ch— flag (4ビ ット） 、 および Allocator (16ビット） が順次配置される。
fsjlagは、 private— payloadOに格納される LPCMオーディォストリ ームのサンプリング周波数を示す。 即ち、 例えば、 サンプリング周波 数が 48KHzの場合、 fs— flagは 0とされ、 サンプリング周波数が 44. ΙΚΗζ の場合、 fs_flagは 1とされる。
ch_flagは、 private— payloadOに格納される LPCMオーディォストリ ームのチャネル数を示す。 例えば、 LPCMオーディオストリームがモノ ラルの場合、 ch_flagは 1とされ、 LPCMオーディオストリームがステレ ォの場合、 ch_flagは 2とされる。
Allocatorは、 その AU—locatorの直後の位置を基準として、 privat e_payload()に格納される LPCMオーディォストリームのォ一ディオア クセスユニット （LPCMオーディオアクセスユニット） （オーディオフ レーム） の先頭位置を示す b private_payload()にオーディオアクセ スユニットが存在しない場合、 AU一 locatorには、 例えば OxFFFFが記述 される。
private_payload()に格納されるエレメン夕リストリームが字幕ス トリ一ムである場合（private— stream— id==SUBTITLE)、 将来の拡張の ための reserved_Jor_future_use (8ビット） が配置され、 その後に 、 AU— locator (16ビット） が配置される。 AU— locatorは、 その AU— loc a torの直後の位置を基準として、 private— payloadOに格納される字 幕ストリームの字幕アクセスュニットの先頭位置を示す。 private_pa yloadOに字幕アクセスュニットが存在しない場合、 AU_locatorには 、 例えば OxFFFFが記述される。
「private— stream2— PES— payloadOの説明」
次に、 第 2 3図は、 pr i vat e_st ream2_PES_j)ay load 0のシンタクス を示している。
pr i vat e_stream2_PES_pay load 0は、 pr ivate— s t ream— 2の PESjpacke ")の？83— &(^6し(1&1&_^ 16 (第 1 8図 Aおよび第 1 8図 B) を拡張 したもの、 即ち、 private— stream_2の PES_packet()の、 拡張した PES_ packeし data_byteであり、 ビデオストリームのデコードに利用される 情報が記述される。
本実施の形態では、 private一 stream_2の PES一 packet 0は、 ビデオス トリームにおけるデコ一ド開始可能点の直前に配置される。 従って、 本実施の形態では、 プログラムストリームから private_stream— 2の PE S— packet 0を見つければ、 その直後のビデオストリームからデコード を開始することができる。
ここで、 上述した第 1 4図の EPjnapOの RPN— EP_startは、 ビデオス トリームについては、 private— stream一 2の PES_packet 0の先頭の位置 を示す。
private一 stream2— PES一 payloadOの先頭には、 将来の拡張用の reser ved_for_future_use (8ビット） が配置され、 続けて、 video一 stream一 id (8ビット） ， IstRef— picture (16ビット） ， 2ndReし picture (16 ビット） , 3rdRef— picture (16ビット） ， 4thRef一 picture (16ビット ) ， au_information(), および VBI0が、 順次配置される。
video— stream— idには、 private— stream— 2の PES— packet 0の直後に 配置されるビデオストリームの PES— packet 0の stream— id (と同一の 値） が記述される。 この video— stream— idによって、 private— stream— 2の PES— packet () (の private_stream2_PES— payloadO) に格納された 情報を利用してデコードされるビデオストリーム （が格納された PES_ packet 0) が特定される。
IstRef— picture, 2ndRef— picture, 3rdRef— picture, 4thRef_pictu reは、 video__stream_idによって特定されるビデオストリームの、 pri vate— stream— 2の PES— packet 0力、ら次の pri vat e— stream— 2の PES— packe tOまでの中の 1 , 2， 3， 4番目の参照画像を含む最後の packOの 位置を相対値で、 それぞれ表す。 なお、 lstRef_picture， 2ndRef_pic ture, 3rdReし picture, 4thReし pictureについては、 例えば、 特開平 09-46712号公報 （特願平 07- 211420号） に、 bytes— to— firsし P— pic by tes— to— second_P— picとして、 その詳細が開示されている。
au— informationOには、 private— stream— 2の PES— packet 0力、ら、 次 の private_stream一 2の PES_packet 0までのビデオストリ一ムの中のビ デォアクセスユニットに関する情報が記述される。 au一 informationO の詳細については、 第 2 4図を参照して後述する。
VBI0は、 Closed Captionの情報を記述するために使用される。 以上のよう ¾pr i vat e_stream2_PES_pay load 0を有する pri vate— str eam_2の PES— packet 0は、 ビデオストリームごとの、 デコード開始可 能点ごとに配置される。
次に、 第 24図は、 第 2 3図の au_information()のシンタクスを示 している。 ·
au_inforniationOの先頭には、 length (16ビット） が配置される。 lengthは、 それを含む au— informationOのサイズを表す。 lengthに続 レ ては、 reserved_f or_ ord_al ignment (8ヒッ卜 j 、 および number— o f .access unit (8ビッ卜) が順次配置される。 reserved for word_al ignmentは、 ワードァラインをとるために使用される。
number— 0し access_uni tは、 それを含む pr ivate_stream一 2の PES— pac ket ()から、 次の private_stream_2の PES_packet 0までの間に含まれ るビデオアクセスユニット （ピクチャ） の数を表す。
即ち、 number— of一 access— unitは、 第 2 3図の pr ivate— s tream2_PES —payloadOが同一の video— stream— idを有する private— stream— 2の PES —packet 0の中で、 この au— inf ormatnio 0力、ら次の au— informat ion 0 の直前までに （この au_infromation()がクリップストリ一ムファイル で最後の au_information()であれば、 クリップストリームファイルの 最後までに） 、 video_stream一 idで示されるビデオストリームに含ま れるアクセスユニット （ピクチャ） の数を示す。
number— 0し access— uni tの後には、 その number— of— access— uni tの数 だけ forループの内容が配置される。 即ち、 number_of_access_unitを 含む private— stream一 2の PES— packet 0力、ら、 次の private— stream— 2の PES_packet()までの間に含まれる 1以上のビデオアクセスュニットそ れぞれに関する情報が配置される。
forループ内に配置される情報 （ビデオアクセスュニッ卜に関する 情報） は、 以下のようになつている。
良ロち、 forjレーフ内にま、. pic— struct— copy (4ビッ卜） ， au— ref— Π ag (1ビット） ， AU_length (21ビット） ， reservedが配置される。 pic_strucし copyには、 ビデオストリームが MPEG4-AVC (IS0/IEC 14 496-10) の場合に、 対応するビデオアクセスユニットに対して設定さ れている、 IS0/IEC 14496-10, D.2.2に定義されている pic_struct ( ) のコピーが記述される。 なお、 pic_struct () は、 例えば、 ピクチ ャをフレームとして表示する、 あるいは、 ピクチャのトップフィール ドを表示して、 その後、 ボトムフィールドを表示する、 などといった 情報である。
au一 reし f l agは、 対応するアクセスユニットが、 他のアクセスュニ ット （のピクチャ） のデコードにあたって参照される参照画像である か否かを表し、 参照画像である場合には 1とされ、 参照画像でない場 合には 0とされる。
AU_l engthは、 対応するアクセスュニッ卜のサイズをバイト単位で 表す。
[ディスク 1 0 1に記録されたデータの具体例]
次に、 第 2 5図乃至第 2 8図は、 第 1図のディスク 1 0 1に記録さ れた、 上述したようなフォーマットのデータの具体例を示している。
ここで、 第 2 5図乃至第 2 8図では、 ビデオストリームとしては、 MPEG2-Vi deoを採用し、 オーディオストリームとしては、 ATRACオーデ ィォストリームを採用している。 但し、 ビデオストリームやオーディ ォストリームは、 これに限定されるものではない。 即ち、 ビデオスト リームとしては、 例えば、 MPEG4-Vi sua lや MPEG4- AVCなど.を採用する ことができる。 さらに、 オーディオストリームとしては、 例えば、 MP EG1/2/4オーディォゃ LPCMオーディォストリームなどを採用すること ができる。
なお、 字幕ストリームは、 ビデオストリームやオーディオストリー ムと異なり、 同じ間隔で連続的なデコード ·表示 （出力） が行われる とは限らない。 すなわち、 字幕ストリームは、 時折、 第 2図 Aおよび 第 2図 Bのバッファ制御モジュール 2 1 5から字幕デコーダ制御モジ ユール 2 1 8に供給されてデコードされる。
第 2 5図乃至第 2 8図は、 ディスク 1 0 1において、 第 4図に示し たように、 " CL IP' 'ディレクトリに、 3つのクリップ情報ファイル" 000 01 . CLP" , " 00002. CLP" , " 00003. CLP"が記録され、 " STREAM"ディレク トリに、 その 3つのクリップ情報ファイル" 00001. CLP"， " 00002. CLP" , " 00003. CLP"それぞれに対応する 3つのクリップストリームフアイ ル" 00001.PS"， " 00002.PS", " 00003.PS"が記録されている場合の、 "P LAYLIST.DAT"ファイル、 クリップ情報ファイル" 00001. CLP"， " 00002. CLP"、 および" 00003. CLP"等の具体的な例を示している。 但し、 第 2
5図乃至第 28図では、 "PLAYLIST.DAT"ファイル等のデ一夕の一部を 省略してある。
即ち、 第 2 5図は、 第 5図で説明した" PLAYLIST.DAT"ファイルの具 体例を示している。
第 25図では、 number_oし PlayListsは 2となっており、 従って、 "P LAYLIST.DAT"ファイルに含まれる PlayListOの数は 2である。 第 2 5 図では、 その 2つの PlayListOのうちの 1番目が PlayList #0と、 2 番目が PlayList #1と、 それぞれ記載されている。
1番目の PlayList ()である PlayList #0については、 capture_enabl e一 ag_PlayListが 1となっており、 従って、 PlayList #0にしたがつ て再生されるビデオデ一夕の 2次利用が許可されている。 また、 Play List #0については、 number_oし Playltemsが 2となっており、 従って 、 PlayList #0に含まれる PlayltemOの数は 2である。 第 2 5図では、 その 2つの PlayltemOである PlayltemifOと Playltem#lの具体例が、 「 PlayList#0j の欄の下方に記載されている。
PlayList #0に含まれる 1番目の Playl temOである Playl tem#0では 、 第 6図で説明した Clip— Information二 file— nameが" 00001. CLP"に、 I n_timeが 180, 090に、 OUT— t imeが 27， 180， 090に、 それぞれなっている 。 従って、 PlayList #0の Playl tem#0によって再生されるクリップは 、 クリップ情報ファイル" 00001. CLP"に対応するクリップストリーム ファイル" 00001.PS"の、 時刻 180， 090から 27， 180, 090までである。 PlayList #0に含まれる 2番目の Playl temOである Playl tem#lでは 、 第 6図で説明した Clip—Information— file一 nameが" 00002. CLP"に、 I 11_ 11^が90,000に、 OUT— timeが 27， 090， 000に、 それぞれなっている。 従って、 PlayList #0の Playltem#lによって再生されるクリップは、 クリップ情報ファイル'' 00002. CLP"に対応するクリップストリームフ アイル" 00002.PS"の、 時刻 90, 000から 27, 090， 000までである。
一方、 第 2 5図において、 2番目の PlayListOである PlayList #1 については、 capture一 enable_flag_PlayListが 0となっており、 従つ て、 PlayList #1にしたがって再生されるビデオデータの 2次利用が 許可されていない （禁止されている） 。 また、 PlayList #1について は、 number_of_PlayItemsが 1となっており、 従って、 PlayList #1に 含まれる PlayltemOの数は 1である。 第 2 5図では、 その 1つの Play ItemOである PlayItem#0の具体例が、 「PlayList#l」 の欄の下方に記 載されている。
PlayList #1に含まれる 1つの Playl temOである Playl tem#0では、 第 6図で説明した Clip— Information_f ile一 nameが" 00003. CLP"に、 In— timeが 90， 000に、 0UT_t imeが 81, 090， 000に、 それぞれなっている。 従 つて、 PlayList #1の PlayItem#0によって再生されるクリップは、 ク リップ情報ファイル" 00003..CLP"に対応するクリップストリームファ ィル" 00003.PS"の、 時刻 90, 000から 81,090， 000までである。
次に、 第 2 6図 Aおよび第 26図 Bは、 第 1 0図で説明したクリッ プ情報ファイル ClipOの具体例を示している。 即ち、 第 26図 Aおよ び第 26図 Bは、 第 4図のクリップ情報ファイル" 00001. CLP", " 0000 2.CLP", "00003. CLP"の具体例を示している。
クリップ情報ファイル" 00001. CLP"においては、 presentat ion— star t .timeが 90, 000に、 resentation end timeが 27， 990， 000に、 それぞ れなっている。 従って、 クリップ情報ファイル" 00001.CLP"に対応す るクリップストリームファイル" 00001.PS"に格納されたプログラムス トリームによれば、 310秒分 （（27， 990， 000-90, 000) /90kHz) のコンテ ンッが利用可能である。
また、 クリップ情報ファイル" 00001.CLP"においては、 capture_ena ble_flag_Clipが 1になっており、 従って、 クリップ情報ファイル" 00 001. CLP"に対応するクリップストリームファイル" 00001.PS"に格納さ れたプログラムストリームに多重化されたビデオストリ一ム （に対応 するビデオデータ） については、 その 2次利用が許可されている。 さらに、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報ファ ィル" 00001. CLP"の number— 0し streamsは 4となっており、 従って、 対 応するクリップストリームファイル" 00001.PS"に格納されたプロダラ ムストリームには、 4本のエレメン夕リストリームが多重化されてい る。
いま、 その 4本のエレメンタリストリームを、 stream#0, streamtl ， stream#2, s tream#3とすると、 第 2 6図 Aおよび第 2 6図 Bでは、 その 4本のエレメンタリストリーム stream#0, stream#l, stream#2, stream#3それぞれの StreamlnfoO (第 1 0図） の具体例が、 「"00001 .CLP"」 の欄の下方に記載されている。
クリップストリームファイル" 00001.PS"の 1本目のエレメンタリス トリーム stream#0については、 stream_idが OxEOとなっており、 従つ て、 このエレメン夕リストリーム stream#0は、 第 2 0図および第 2 2 図 （あるいは第 1 1図） で説明したように、 ビデオストリームである 。 なお、 本実施の形態では、 ビデオストリームについては、 上述した ように、 private— stream— idは無関係であるが、 第 2 6図 Aおよび第 2 6図 Bでは、 0x00になっている。 また、 クリップストリームファイル" 00001.PS"の 1本目のエレメン タリストリームであるビデオストリーム stream#0については、 その St reamlnfoOに含まれる StaticInfoO (第 1 図） の picture— sizeが' 7 20X480'に、 frame—rateが' 29.97Hz'に、 cc_f lagが' Yes'に、 それぞ れなっている。 従って、 このビデオストリーム streamifOは、 720X480 ピクセルの、 フレーム周期が 29.97Hzのビデオデータであり、 さらに 、 クローズドキャプションデータを含んでいる。 - さらに、 クリップストリ一ムファイル" 00001.PS"の 1本目のエレメ ン夕リストリームであるビデオストリーム stream#0については、 Stre amlnfoO (第 1 0図） の number—oし Dynamiclnfoが 0になっており、 p ts—change_pointと Dynamiclnfo ()とのセッ卜は存在しない。
次に、 クリップストリームファイル" 00001.PS"の 2本目のエレメン 夕リストリ一ム stream#lについては、 stream_idが OxBDとなっており 、 private_stream_idが 0x00となっている。 従って、 このエレメンタ リストリーム stream#lは、 第 2 0図および第 2 2図で説明したように 、 ATRACオーディオストリームである。
また、 クリップストリームファイル" 00001.PS"の 2本目のエレメン 夕リストリームである ATRACオーディォストリーム stream#lについて は、 その StreamlnfoOに含まれる StaticInfoO (第 1 2図） の audio一 language_codeが'日本語'に、 channeし conf igurat ionが' STEREO'に、 1 fe_existence力 NO' こ、 sampl ing— frequency力 ' 48kHz' ίこ、 それそれ なっている。 従って、 この ATRACォー ,ディォストリ ~Astream#lは、 日本語で、 かつステレオのオーディオデータである。 また、 低域強調 チャネルは含まれておらず、 サンプリング周波数は、 48kHzである。 さらに、 クリップストリームファイル" 00001.PS"の 2本目のエレメ ン夕リストリームである ATRACオーディォストリ一ム stream#lについ ては、 StreamlnfoO (第 1 0図） の numl)er一 oし Dynamiclnf oが 0にな つており、 pts_change— pointと DynamicInfoOとのセットは存在しな い。 1
次に、 クリップストリームファイル" 00001.PS"の 3本目のエレメン 夕リストリーム stream#2については、 stream一 idが OxBDとなっており 、 private— streamjdが 0x80となっている。 従って、 このエレメンタ リストリーム stream#2は、 第 20図および第 22図で説明したように 、 字幕ストリームである。
また、 クリップストリームファイル" 00001.PS"の 3本目のエレメン 夕リストリームである字幕ストリーム stream#2については、 その Stre amlnfoOに含まれる StaticInfoO (第 1 2図) の subti t le— language一 codeが'日本語'に、 configurable_f lagが 0に、 それぞれなっている 。 従って、 この字幕ストリーム stream#2は、 日本語の字幕データであ り、 また、 その表示方式を変更することは許可されていない （禁止さ れている） 。
さら'に、 クリップストリームファイル" 00001.PS"の 3本目のエレメ ンタリストリームである字幕ストリ一ム stream#2については、 Stream InfoO (第 1 0図） の number—of_DynamicInfoが 0になっており、 pts —change— pointと Dynamic Info 0とのセッ卜は存在しなレ 。
次に、 クリップストリームファイル" 00001.PS"の 4本目のエレメン 夕リストリーム stream#3については、 stream_idが OxBDとなっており 、 private_stream_idが 0x81となってい.る。 従って、 このエレメン夕 リストリーム stream#3は、 第 20図および第 2 2図で説明したように 、 字幕ストリームである。
なお、 クリップストリ一ムファイル" 00001.PS"の 3本目のエレメン 夕リストリームである字幕ストリーム stream#2と、 4本目のエレメン タリストリームである字幕ストリーム stream#3とを区別するために、 それぞれの01"^& _3^6&111ー は、 0x80と 0x81とになっている。
また、 クリップストリームファイル" 00001.PS"の 4本目のエレメン タリストリームである字幕ストリーム stream^については、 その Stre amlnfoOに含まれる StaticInfoO (第 1 2図) の subt i t le— language— codeが'日本語'に、 conf igurable_flagが 1に、 それぞれなっている 。 従って、 この字幕ストリーム stream#3は、 日本語の字幕データであ り、 また、 その表示方式を変更することが許可されている。
さらに、 クリップストリームファイル" 00001.PS"の 4本目のエレメ ンタリストリームである字幕ストリーム stream#3については、 Stream InfoO (第 1 0図） の number— of— Dynamiclnfoが 0になっており、 pts —change— pointと Dynamiclnfo ()とのセッ卜は存在しない。
次に、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報フアイ ル" 00002. CLP"については、 presentation_start— timeが 90， 000に、 pr esentation_end一 timeが 27， 090, 000に、 それぞれなっている。 従って 、 クリップ情報ファイル" 00002· CLP"に対応するクリップストリ一ム ファイル" 00002.PS"に格納されたプログラムストリームによれば、 30 0秒分 （（27, 090， 000-90， 000) /90kHz) のコンテンツが利用可能である また、 クリップ情報ファイル" 00002.CLP"においては、 capture_ena ble_flag— Clipが 0になっており、 従って、 クリップ情報ファイル" 00 002. CLP"に対応するクリップストリームファイル" 00002.PS"に格納さ れたプログラムストリームに多重化されたビデオストリーム （に対応 するビデオデータ） については、 その 2次利用が許可されていない （ 禁止されている） 。
さらに、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報ファ ィル" 00002. CLP"の number— oし streamsは 4となっており、 従って、 対 応するクリップストリームファイル" 00002.PS"に格納されたプロダラ ムストリームには、 上述したクリップス卜リームファイル" 00001.PS" における場合と同様に、 4本のエレメンタリストリームが多重化され ている。
いま、 その 4本のエレメンタリストリームを、 stream#0， streamttl , stream* 2, stream#3とすると、 第 26図 Aおよび第 26図 Bでは、 その 4本のエレメン夕リストリーム stream#0， stream#l, stream#2, stream#3それぞれの StreamlnfoO (第 1 0図） の具体例が、 「" 00002 .CLP"」 の欄の下方に記載されている。
ここで、 第 26図 Aおよび第 2 6図 Bでは、 クリップストリ一ムフ アイル" 00002.PS"の 1乃至 4本目のエレメンタリストリーム stream#0 乃至 #3それぞれの StreamlnfoOの内容は、 上述したクリップストリー ムファイル" 00001.PS"の 1乃至 4本目のエレメン夕リストリーム stre am#0乃至 #3それぞれの StreamlnfoOの内容と同一になっているので、 その説明は省略する。
なお、 上述のように、 クリップストリームファイル" 00002.PS"の 1 乃至 4本目のエレメン夕リストリ一ム3 6&111#0乃至#3それぞれの3 6 amlnfoOの内容は、 クリップストリームファイル" 00001. PS"の 1乃至 4本目のエレメンタリストリーム stream#0乃至 #3それぞれの Streamln fo()の内容と同一であるので、 クリップストリームファイル" 00002.P S"の 1本目のエレメンタリストリーム stream#0はビデオストリ一ムで あり、 2本目のエレメンタリストリーム stream#lは ATRACオーディオ ストリームである。 また、 その 3本目のエレメンタリストリーム stre am#2と、 4本目のエレメンタリス小リーム s t ream#3は、 いずれも字幕 ストリ一ムである。 次に、 第 2 6図 Aおよび第 26図 Bにおいて、 クリップ情報フアイ ル" 00003.CLP"については、 presentation_start— timeが 90， 000に、 pr
6361^& 011_611 1116が81，090，000に、 それぞれなっている。 従って 、 クリップ情報ファイル" 00003. CLP"に対応するクリップストリ一ム ファイル" 00003.PS"に格納されたプログラムストリームによれば、 90 0秒分 （（81， 090, 000- 90， 000)/90kHz) のコンテンツが利用可能である また、 クリップ情報ファイル" 00003. CLP"においては、 capture— ena ble_flag_Clipが 1になっており、 従って、 クリップ情報ファイル" 00 003. CLP"に対応するクリップストリームファイル" 00003.PS"に格納さ れたプログラムストリームに多重化されたビデオストリームについて は、 その 2次利用が許可されている。
さらに、 第 26図 Aおよび第 26図 Bにおいて、 クリップ情報ファ ィル" 00003. CLP"の number_oi— streamsは 3となっており、 従って、 対 応するクリップストリームファイル" 00003.PS"に格納されたプロダラ ムストリームには、 3本のエレメン夕リス卜リームが多重化されてい る。
いま、 その 3本のエレメン夕リストリームを、 stream#0, streamtl ， stream#2とすると、 第 26図 Aおよび第 26図 Bでは、 その 3本の エレメン夕リストリーム stream#0， stream#l, stream#2それぞれの St reamlnfoO (第 1 0図） の具体例が、 「" 00003. CLP"」 の欄の下方に 記載されている。 ·
クリップストリ一ムファイル" 00003.PS"の 1本目のエレメン夕リス トリ一ム stream#0については、 stream_idが OxEOとなっており、 従つ て、 このエレメンタリストリーム stream#0は、 第 20図および第 2 2 図 （あるいは第 1 1図） で説明したように、 ビデオストリームである 。 なお、 クリップストリームファイル" 00001. PS"の 1本目のエレメン 夕リストリ一ム stream#0と同様に、 private一 stream_idは、 0x00にな つている。
また、 クリップストリームファイル" 00003.PS"の 1本目のエレメン 夕リストリームであるビデオストリーム stream#0については、 その St reamlnfoOに含まれる StaticInfoO (第 1 2図） の picture_sizeが' 7 20X480'に、 frame— rateが' 29.97Hz'に、 cc_flagが' No'に、 それぞれ なっている。 従って、 このビデオストリーム stream#0は、 720X480ピ クセルの、 フレーム周期が 29· 97Hzのビデオデータであり、 さらに、 クローズドキヤプションデ一夕を含んでいない。
さらに、 クリップストリームファイル' '00003.PS"の 1本目のエレメ ンタリストリームであるビデオストリ一ム stream#0については、 Stre amlnfoO (第 1 0図） の number_of_DynamicInfoが 2になっており、 従って、 その Streamlnfo 0には、 pts— change— pointと Dynamiclnfo 0 とのセットが 2セット記述されている。
次に、 クリップストリ一ムファイル" 00003.PS"の 2本目のエレメン 夕リストリーム stream#lについては、 stream— idが OxElとなっており 、 従って、 このエレメン夕リストリーム stream#lは、 第 2 0図および 第 2 2図 （あるいは第 1 1図） で説明したように、 ビデオストリーム である。 なお、 クリップストリームファイル" 00003.PS"の 1本目のェ レメン夕リストリームであるビデオストリーム stream#0と、 2本目の エレメン夕リストリームであるビデオストリーム stream#lとを区別す るために、 それぞれの stream一 idは、 OxEOと OxElとになっている。 ま た、 クリップス卜リームファイル" 00001.PS"の 1本目のエレメンタリ ストリーム streamifOと同様に、 private— stream_idは、 0x00になって いる。 また、 クリップストリームファイル" 00003.PS"の 2本目のエレメン 夕リストリームであるビデオストリーム stream#lについては、 その St reamlnfoOに含まれる StaticInfoO (第 1 2図） の picture_size， fr ame一 rate, cc—flagが、 1本目のエレメン夕リストリームであるビデ ォストリーム stream#0についてのものと同一になっている。 従って、 クリップストリームファイル" 00003.PS"の 2本目のエレメン夕リスト リームであるビデオストリーム stream#lは、 720X480ピクセルの、 フ レーム周期が 29· 97Hzのビデオデータであり、 さらに、 クローズドキ ャプシヨンデータを含んでいない。
さらに、 クリップストリームファイル" 00003.PS"の 2本目のエレメ ン夕リストリ一ムであるビデオストリ一ム stream#lについては、 Stre amlnfoO (第 1 0図） の number— oし Dynamiclnf oが 0になっており、 p ts— change— pointと Dynamic Info 0とのセットは存在しない。
次に、 クリップストリームファイル" 00003.PS"の 3本目のエレメン タリストリーム streamsについては、 s tream_idが OxBDとなっており 、 private— stream— idが 0x00となっている。 従って、 このエレメン夕 リストリーム streamsは、 第 2 0図および第 2 2図で説明したように 、 ATRACオーディオストリームである。
また、 クリップストリームファイル" 00003.PS"の 3本目のエレメン 夕リストリームである ATRACオーディォストリーム stream#2について は、 その StreamlnfoOに含まれる StaticInfoO (第 1 2図） の audio_ language_code, channel一 configuration, 1 fe一 existence, sampl ing_ frequencyが、 クリップストリームファイル" 00001. PS"の 2本目のェ レメン夕リストリ一ムである ATRACオーディォストリーム stream#lの ものと同一になっている。 従って、 クリップストリームファイル" 000 03. PS"の 3本目のエレメン夕リストリームである ATRACォ一ディォス トリーム stream#2は、 日本語で、 かつステレオのオーディオデータで ある。 また、 低域強調チャネルは含まれておらず、 サンプリング周波 数は、 48kHzである。
さらに、 クリップストリームファイル" 00003.PS"の 3本目のエレメ ンタリストリームである ATRACオーディォストリーム stream#2につい ては、 StreamlnfoO (第 1 0図) の number_oし Dynamiclnf oが 3にな つており、 従って、 その StreamlnfoOには、 pts— change_pointと Dyna micInfoOとのセットが 3セット記述されている。
次に、 第 2 7図は、 第 1 0図で説明したクリップ情報ファイル Clip 0のうちの EPjnapO具体例を示している。 即ち、 第 2 7図は、 第 4図 のクリップ情報ファイル" 00001. CLP"の中の、 第 1 4図の EP— map()の 具体例を示している。
第 2 7図において、 EP— map ()の number— of— stream— id— entriesは 1に なっており、 従って、 この EPjnapOには、 1つのエレメンタリストリ ームについてのデコード開始可能点の情報が記述されている。
また、'第 2 7図の EPjnapOでは、 s tream一 idが OxEOになっている。 従って、 第 2 0図および第 2 2図で説明したことから、 EPjnapOには 、 OxEOとなっている stream— idによって特定されるビデオストリーム についてのデコード開始可能点の情報 (PTS— EP— 3 &1^と1^ 8?—3131^ (第 14図） ） が記述されている。 即ち、 第 2 7図は、 クリップ情報 ファイル" 00001. CLP"の EPjnapOであり、 クリップ情報ファイル" 0000 1.CLP"に対応するクリップストリームファイル" 00001. CLP"において 、 stream—idが OxEOのエレメン夕リストリ一ムは、 第 2 6図 Aおよび 第 2 6図 Bで説明したように、 クリップストリームファイル" 00001. C LP"の 1本目のビデオストリーム s eam#0であるから、 第 2 7図の EP— map()に記述されている情報は、 そのビデオストリーム stream#0のデ コード開始可能点の PTS— EP— startとRPN_EP__startでぁる。
第 2 7図では、 クリップストリームファイル" 00001. CLP"の 1本目 のビデオストリーム stream#0のデコード開始可能点のうちの、 先頭か ら 5点の PTS_EP— 31&1^と10^^?_31&1^が記載されてぉり、 6点目以降 の PTS一 EP_startと: RPN_EP_startの記載は省略してある。
なお、 第 2 7図の EPjnapOにおいて、 private_stream— idは 0x00に なっているが、 stream_idがビデオストリームを表している場合は、 上述したように、 private_streanLidは無関係である （無視される） 次に、 第 2 8図は、 第 2 5図で説明した PlayList #0と Playtist #1 (第 5図の PlayListO) の中の PlayListMarkOの具体例を示している 第 2 8図上側は、 PlayList #0の PlayListMarkO (第 7図） を示し ている。 '
第 2 8図上側において、 PlayList #0の PlayLis tMarkOにおける num ber_of一 PlayUstjnarksは 7になっており、 従って、 PlayList #0 (の P layListMarkO) に含まれる MarkOの数は 7である。
また、 第 2 8図上側において、 PlayList #0に含まれる 7つの Mark( )のうちの 1番目の MarkOである Mark#0は、 mark_type (第 7図） が' C hapter'になっているので、 チヤプ夕マークである。 さらに、 Mark#0 は、 reし to— Play It em一 id (第 7図) が 0になっているので、 PlayList #0に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 PlayItem#0 に属する。 また、 Mark#0は、 ]^ _1111^_51&即が180, 090になってぃる ので、 PlayList #0に含まれる Playl tem#0によって再生されるクリツ プストリームファイルの時刻 （再生時刻） 180, 090上の印である。 さ らに、 Mark#0は、 entry— ES stream idおよび entry— ES— private— strea m一 idがいずれも 0になっているので、 いずれのエレメン夕リストリー ムにも関連付けられていない。 また、 Mark#0は、 mark_dataが 1になつ ているので、 番号が 1のチヤプ夕を表す。
なお、 ここでは、 PlayList #0に含まれる Playl tem#0によって再生 されるクリップストリームファイルは、 第 2 5図で説明した、 その P1 ayltem#0の Clip一 Infomation_f ilejtiameに記述されている" 00001.CLP" から特定されるクリップストリームファイル' '00001.PS"であり、 従つ て、 Mark#0の mark_time_sta即が表す、 上述した時刻 180， 090は、 クリ ップストリームファイル" 00001.PS"の時刻である。
第 28図上側において、 PlayList #0に含まれる 7つの MarkOのう ちの 5番目の MarkOである Mark#4も、 1番目の Mark#0と同様のチヤプ 夕マークである。
即ち、 5番目の MarkOである Mark#4ば、 mark_type (第 7図） が' Ch apter'になっているので、 チヤプ夕マークである。 さらに、 Mark#4は 、 ref_to_PlayItem_id (第 7図） が 1になっているので、 PlayList #0 に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 Playl tem#lに 属する。 また、 Mark#4は、 mark一 Ume_stampが 90， 000になっているの で、 PlayList #0に含まれる Playl tem#lによって再生されるクリップ ストリームファイルの時刻 90,000上の印である。 さらに、 Mark#4は、 entry— ES— stream— idおよび entry— ES— private— stream— idがいずれも 0 になっているので、 いずれのエレメン夕リストリームにも関連付けら れていない。 また、 Mark#4は、 mark_dataが 2になっているので、 番号 が 2のチヤプ夕を表す。
なお、 ここでは、 PlayList #0に含まれる Playltem#lによって再生 されるクリップストリームファイルは、 第 2 5図で説明した、 その P1 ayliem#lの CI iD Infomation file nameに記述されている" 00002. CLP" から特定されるクリップストリームファイル" 00002.PS"であり、 従つ て、 Mark#4の mark__time_stampが表す、 上述した時刻 90, 000は、 クリ ップストリームファイル" 00002.PS"の時刻である。
また、 第 28図上側において、 PlayList #0に含まれる 7つの Mark( )のうちの 2番目の MarkOである Mark#lは、 mark_type (第 7図） が' I ndex'になっているので、 インデクスマ一クである。 さらに、 Mark#l は、 reし to_PlayItem— id (第 7図） が 0になっているので、 PlayList #0に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 PlayItem#0 に属する。 また、 Mark#lは、 1^ ー 11^_81&即が5， 580，090になってぃ るので、 PlayList #0に含まれる Playl tem#0によって再生されるクリ ップストリームファイルの時刻 5，580，090上の印である。 さらに、 Mar k#lは、 entry— ES— stream— idおよび en try— ES_pri vat e— stream— idがい ずれも 0になっているので、 いずれのエレメンタリストリームにも関 連付けられていない。 また、 Mark#lは、 mark一 dataが 1になっているの で、 番号が 1のインデクスを表す。
なお、 ここでは、 PlayList #0に含まれる Playl tem#0によって再生 されるクリップストリームファイルは、 上述したように、 クリップス トリ一ムファイル" 00001.PS"であり、 従って、 Mark#lの mark_time_st ampが表す、 上述した時刻 5， 580, 090は、 クリップストリームファイル "00001.PS"の時刻である。
第 28図上側において、 PlayList #0に含まれる 7つの MarkOのう ちの 3番目、 6番目、 7番目の MarkOである Mark#2， Mark#5, Mark#6 も、 2番目の Mark#lと同様のインデクスマークである。
また、 第 2 8図上側において、 PlayList #0に含まれる 7つの Mark( )のうちの 4番目の MarkOである Mark#3は、 mark— type (第 7図） が 'E vent'になっているので、 イベントマークである。 さらに、 Mark#3は 、 ref_to_PlayItem_id (第 7図） が 0になっているので、 PlayList #0 に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 PlayItem#0に 属する。 また、 Mark#3は、 mark— t ime— siampが 16， 380， 090になってい るので、 PlayList #0に含まれる Playl tem#0によって再生されるクリ ップストリームファイルの時刻 16， 380, 090上の印である。 さらに、 Ma rk#3は、 entry— ES— stream— idおよび en try_ES— private— stream— idがい ずれも 0になっているので、 いずれのエレメン夕リストリームにも関 連付けられていない。 また、 Mark#3は、 mark— dataが 0になっているの で、 引数として 0を伴うイベントを発生させる。
なお、 ここでは、 PlayList #0に含まれる P yl tem#0によって再生 されるクリップストリームファイルは、 上述したように、 クリップス トリームファイル" 00001.PS"であり、 従って、 Mark#3の mark_time_st a即が表す、 上述した時刻 16， 380, 090は、 クリップストリームフアイ ル" 00001.PS"の時刻である。
ここで、 第 28図上側では、 PlayList #0の PlayListMarkOの一覧 表の ίί外の右側に、 MarkOが属する PlayltemOの先頭からの時間を示 してあり、 さらにその右側に、 PlayList #0の先頭からの時刻を示し てある。
次に、 第 28図下側は、 PlayList#lの PlayListMarkO (第 7図） を 示している。
第 28図下側において、 PlayList#lの PlayListMarkOにおける numb er_oし PlayList— marksは 3になっており、 従って、 PlayList#l (の Pla yListMarkO) に含まれる MarkOの数は 3である。
また、 第 28図下側において、 PlayList#lに含まれる 3つの MarkO のうちの 1番目の MarkOである Mark#0は、 markjype (第 7図） が' Ch apter'になっているので、 チヤプ夕マ一クである。 さらに、 Mark#0は 、 ref_to_PlayItem_id (第 7図） が 0になっているので、 P yList#l に含まれる第 2 5図の 1つの PlayItem#0に属する。 また、 MarkJOは、 mark— time— sta即が 90, 000になっているので、 PlayList#lに含まれる P layltem#0によって再生されるクリップストリームファイルの時刻 90, 000上の印である。 さらに、 Mark#0は、 entry_ES一 stream_idおよび ent ry_ES_private一 stream_idがいずれも 0になっているので、 いずれのェ レメン夕リストリームにも関連付けられていない。 また、 Mark#0は mark— dataが 0になっているので、 番号が 0のチヤプ夕を表す。
なお、 ここでは、 PlayList#lに含まれる Playltem#0によって再生さ れるクリップストリームファイルは、 第 2 5図で説明した、 その Play 116111#0の(110_11^0]1^^011_ 16_1^1116に記述されてぃる"00003.(1^"か ら特定されるクリップストリームファイル" 00003.PS"であり、 従-つて 、 Mark#0の mark—time_stanipが表す、 上述した時刻 90， 000は、 クリツ プストリームファイル" 00003.PS"の時刻である。
第 2 8図下側において、 PlayList#lに含まれる 3つの MarkOのうち の 2番目の MarkOである Mark#lは、 mark_type (第 7図） が' Event'に
- ヽ なっているので、 イベントマークである。 さらに、 Mark#lは、 ref— to _PlayItem_id (第 7図） が 0になっているので、 PlayList#lに含まれ る第 2 5図の 1つの PlayItem#0に属する。 また、 Mark#lは、 mark Um 6_3(&即が27，090，000になってぃるので、 PlayList#lに含まれる Playl tem#0によって再生されるクリップストリームファイルの時刻 27， 090，, 000上の印である。 さらに、 Mark#lは、 . entry— ES一 stream— idが OxEOで 、 entry— ES—private_stream— idが 0になっているので、 stream— idが Ox E0で特定 （識別） されるエレメン夕リストリ一ム、 即ち、 第 2 0図お よび第 2 2図で説明したように、 ビデオストリームに関連付けられて いる。 また、 Mark#lは、 mark— dataが 1になっているので、 引数として 1を伴うイベントを発生させる。
なお、 ここでは、 PlayList#lに含まれる PlayItem#0によって再生さ れるクリップストリームファイルは、 上述したように、 クリップスト リームファイル" 00003.PS"であり、 従って、 Mark#lの mark— time_stam pが表す、 上述した時刻 27，090，000は、 クリップストリームファイル" 00003.PS"の時刻である。
また、 Mark#lが関連付けられている、 stream— idが OxEOのビデオス トリ一ムは、 その Mark#lが属する、 第 2 5図の PlayLis t#lに含まれる ?1& 116111#0の(：110_11^0111&11011_ 16—11&1116に記述されてぃる"00003. CL P"に記述されている stream_idが OxEOのビデオストリーム、 即ち、 第 26図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00003. CLP"から 特定される、 クリップストリ一ムファイル" 00003.PS"に多重化されて いる 3本のエレメンタリストリーム stream#0乃至 #2のうちの、 1本目 のエレメン夕リストリーム （ビデオストリーム） stream#0である。 次に、 第 28図下側において、 PlayList#lに含まれる 3つの MarkO のうぢの 3番目の MarkOである Mark#2は、 mark_type (第 7図） が 'Ev ent'になっているので、 イベントマークである。 さらに、 Mark#2は、 reLto—PlayItem_id (第 7図） が 0になっているので、 PlayList#lに 含まれる第 2 5図の 1つの？layltem#0に属する。 また、 Mark#lは、 ma rk— time—stampが 27， 540， 000になっているので、 PlayList#lに含まれ る PlayItem#0によって再生されるクリップストリームファイルの時刻 27, 540， 000上の印である。 さらに、 Mark#2は、 entry— ES— stream— idが OxElで、 entry— ES—private_stream— idが 0になっているので、 stream— idが OxElで特定 （識別） されるエレメン夕リストリーム、 即ち、 第 2 0図および第 22図で説明したように、 ビデオストリームに関連付け られている。 また、 Mark は、 mark dataが 2になっているので、 引数 として 2を伴うイベントを発生させる。
なお、 ここでは、 PlayListftlに含まれる PlayItem#0によって再生さ れるクリップストリームファイルは、 上述したように、 クリップスト リームファイル" 00003.PS"であり、 従って、 Mark#2が表す、 上述した 時刻 27， 540， 000は、 クリップストリームファイル" 00003. PS"の時刻で ある。
また、 Mark#2が関連付けられている、 3 6&111—1(1が(^81のビデォス トリームは、 その Mark#2が属する、 第 2 5図の PlayList#lに含まれる PlayItem#0の Clip_Infomation— file一 nameに記述されている" 00003. CL P"に記述されている stream_idが OxElのビデオストリーム、 即ち、 第 26図 Aおよび第 26図 Bのクリップ情報ファイル" 00003. CLP"から 認識される、 クリップストリームファイル" 00003.PS"に多重化されて いる 3本のエレメン夕リストリーム stream#0乃至 #2のうちの、 2本目 のエレメンタリストリーム （ビデオストリーム） stream#lである。 ここで、 第 2 8図下側では、 PlayList#lの PlayListMarkOの一覧表 の欄外の右側に、 MarkOが属する PlayltemOの先頭からの時刻を示し てある。
なお、 第 28図においては、 チヤプ夕マークやインデクスマ一クが 表.すチヤプタゃィンデクスの番号が、 mark_dataに記述されているが 、 チヤプタマークやインデクスマ一クが表すチヤプタゃインデクスの 番号は、 mark—dataに記述しなくても、 例えば、 P yListMarkOにお けるチヤプ夕マークゃィンデクスマークの数をカウントすることによ つて認識することができる。
[ディスク装置の動作説明]
次に、 第 1図のディスク 1 0 1に、 第 2 5図乃至第 28図で説明し たようなデータ （ファイル） が記録されているとして、 第 1図のディ スク装置の動作について説明する。
ディスク 1 0 1がディスクドライブ 1 0 2に挿入されると、 その旨 を示すメッセージがドライブインターフェ一ス 1 1 4、 さらには、 第 2図 Aおよび第 2図 Bのォペレ一ティングシステム 2 0 1を経由して 、 ビデオコンテンツ再生プログラム 2 1 0に伝えられる。 ビデオコン テンッ再生プログラム 2 1 0は、 ディスク 1 0 1がディスクドライブ 1 0 2に挿入された旨のメッセージをオペレーティングシステム 2 0 1から受信すると、 第 2 9図の再生前処理を開始する。
「再生前処理」
即ち、 第 2 9図は、 ビデオコンテンツ再生プログラム 2 1 0が行う 再生前処理を説明するフローチャートである。
ここで、 以下、 フローチャートによって説明するディスク装置の動 作または処理は、 必ずしもフローチャートとして記載された順序に沿 つて時系列に行われる必要はなく、 並列的あるいは個別に行われるこ ともある。 但し、 本明細書では、 便宜上、 ディスク装置の動作または 処理を、 フローチャートに沿って説明する。
再生前処理では、 ビデオコンテンツ再生プログラム 2 1 0は、 ステ ップ S 1 0 1において、 ォペレ一ティングシステム 2 0 1のファイル システム機能を使用して、 ディスク 1 0 1をチェックし、 ディスク 1 0 1が、 ビデオコンテンツ再生プログラム 2 1 0用の正常なディスク であるか否かを判定する。
ここで、 上述したように、 ディスク.1 0 1へのアクセス （ファイル の読み出し） は、 オペレーティングシステム 2 0 1のファイルシステ ム機能を使用して行われるが、 以下では、 その説明は、 適宜省略する 。
ステップ S 1 0 1において、 ディスク 1 0 1が正常なディスクでな いと判定された場合、 即ち、 例えば、 ディスク 1 0 1に採用されてい るファイルシステムが、 オペレーティングシステム 2 0 1の対応して いないタイプであった場合や、 ルートディレクトリに" VIDEO"ディレ クトリが置かれていない場合、 ビデオコンテンツ再生プログラム 2 1 0はディスク 1 0 1に対応していないと判断して、 ステップ S 1 0 2 に進み、 グラフィクス処理モジュール 2 1 9が、 エラー処理を行って 、 再生前処理を終了する。
即ち、 グラフィックス処理モジュール 2 1 9は、 エラー処理として 、 ディスク 1 0 1が正常でない旨のエラーメッセージ （のビデオデ一 夕） を生成し、 ビデオ出力モジュール 2 2 0から出力させ、 これによ り、 エラ一メッセージを表示させる。 なお、 エラー処理としては、 そ の他、 例えば、 オーディオ出力モジュール 2 2 1からの警告音の出力 や、 ディスクドライブ 1 0 2からのディスク 1 0 1の排出等を行うよ うにすることが可能である。
一方、 ステップ S 1 0 1において、 ディスク 1 0 1が正常なデイス クであると判定された場合、 ステップ S 1 0 3に進み、 ビデオコンテ ンッ再生プログラム 2 1 0は、 コンテンツデータ供給モジュール 2 1 3によって、 ォペレ一ティングシステム 2 0 1に対し、 ディスク 1 0 1 (第 4図) の" VIDEO "ディレクトリに置かれている" SCRIPT, DAT"フ アイルと、 " PLAYL I ST. DAT"ファイルとの 2つのデ一タファイルを要求 して読み込み、 ステップ S 1 0 4に進む。 ステップ S 1 0 4では、 " S CRIPT. DAT"ファイルが、 スクリプト制御モジュール 2 1 1に供給され るとともに、 " PLAYL IST. DAT"ファイルが、 プレイヤ制御モジュール 2 1 2に供給される。
その後、 ステップ S 1 0 4から S 1 0 5乃至 S 1 0 7に進み、 プレ ィャ制御モジュール 2 1 2は、 初期化処理を行う。 なお、 スクリプト 制御モジュール 2 1 1は、 プレイヤ制御モジュール 2 1 2の初期化処 理が終了するまで待つ。
「プレイヤ制御モジュール 2 1 2の初期化処理」
初期化処理では、 ステップ S 1 0 5において、 プレイヤ制御モジュ —ル 2 1 2が、 "PLAYLIST.DAT"ファイルの解析を行い、 "PLAYLIST.DA T"ファイルの中で使われているクリップ情報ファイルの数とそのファ ィル名を調査する。
即ち、 いまの場合、 "PLAYLIST.DAT"ファイルは、 第 2 5図に示した. ものとなっており、 プレイヤ制御モジュール 2 1 2は、 第 2 5図の "P LAYLIST.DAT"ファイルにおいて number_oし PUyLis t sが 2になっている ことから、 1番目の PlayList#0と 2番目の PlayList#lとの 2つの Play List 0が存在することを認識する。 さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 5図の" PLAYLIST.DAT"ファイルにおける 1番目の Play List#0について、 number— of_PlayItemsが 2となっていることから、 そ の PlayList#0には、 1番目の Playl tem#0と 2番目の Playl tem#lとの 2 つの PlayltemOが存在することを認識する。 そして、 プレイヤ制御モ ジュール 2 1 2は、 第 2 5図の" PLAYLIST.DAT"ファイルにおける、 P1 ayList#0に含まれる 1番目の Playl tem#0と 2番目の Playl tem#lそれぞ れの Clip_Information— filp_nameを参照することにより、 PlayList#0 に含まれる 1番目の PlayItem#0のクリップ情報ファイル （のファイル 名） が" 00001. CLP"であり、 2番目の Playltem#lのクリップ情報ファ ィルが" 00002. CLP"であることを認識する。
プレイヤ制御モジュール 2 1 2は、 2番目の PlayList#lについても 同様にして、 その number_oし Playltemsが 1であることから、 1つの P1 ayltemO (PlayItei#0) が存在し、 さらに、 その Playl tem#0の中の C1 ip Information file_nameから、 その PlayItem#0のクリップ情報ファ ィルが" 00003. CLP"であることを認識する。
その後、 ステップ S 1 0 5から S 1 0 6に進み、 プレイヤ制御モジ ユール 2 1 2は、 ディスク 1 0 1から、 ステップ S 1 0 5で認識した クリップ情報ファイル、 即ち、 ディスク 1 0 1の" VIDEO"ディレクト リ内の" CLIP"ディレクトリから 3つのクリップ情報ファイル" 00001.C LP", " 00002. CLP", " 00003. CLP"を読み込む。
ここで、 ステップ S 1 0 6でのクリツプ情報ファイルの読み込みは 、 最初に再生される PlayListOの Playltemのクリップ情報ファイルだ けで十分であるが、 本実施の形態では、 上述したように、 すべての P1 ayListOの PlayltemOのクリップ情報ファイルを先読みしておくこと とする。
ステップ S 1 0 6の処理後は、 ステップ S 1 0 7に進み、 プレイヤ 制御モジュール 2 1 2は、 ステップ S 1 0 5で認識したクリップ情報 ファイルの読み込みに成功したかどうかを判定し、 さらに、 その読み 込んだクリップ情報ファイル 対応するクリップストリ ムファイル が、 ディスク 1 0 1に存在するか否かを判定 （チェック） する。 即ち 、 ステップ S 1 0 7では、 クリップ情報ファイル" 00001. CLP"， " 0000 2. CLP", " 00003. CLP"の読み込みに成功し、 さらに、 そのクリップ情 報ファイル" 00001. CLP"， " 00002. CLP", " 00003. CLP"それぞれとファ ィル名の拡張子のみが異なるクリップストリームファイル" 00001.PS" 、 " 00002.PS"、 " 00003.PS"が、 ディスク 1 0 1の" VIDEO"ディレクト リの下にある" STREAM"ディレクトリに存在するかどうかを判定する。 ステップ S 1 0 7において、 ステップ S 1 0 5で認識したクリップ 情報ファイルの読み込みに失敗したと判定されるか、 または、 クリツ プ情報ファイルに対応するクリップストリームファイルが、 ディスク 1 0 1に存在しないと判定された場合、 即ち、 例えば、 "PLAYLIST.DA T"ファイルにしたがった再生に必要なクリップ情報ファイルゃクリッ ブストリームファイルが、 ディスク 1 0 1に記録されていない場合、 ビデオコンテンツ再生プログラム 2 1 0は、 ディスク 1 0 1に対応し ていないと判断して、 ステップ S 1 02に進み、 上述したエラー処理 が行われ、 再生前処理を終了する。
一方、 ステップ S 1 07において、 ステップ S 1 05で認識したク リップ情報ファイルの読み込みに成功し、 かつ、 クリップ情報フアイ ルに対応するクリップストリームファイルが、 ディスク 1 0 1に存在. すると判定された場合、 プレイヤ制御モジュール 2 1 2は、 初期化処 理を終了し、 ステップ S 1 08に進む。
ステップ S 1 0 8では、 スクリプト制御モジュール 2 1 1が、 "SCR IPT. DAT"ファイルの解釈と実行を開始する。
例えば、 いま、 スクリプト制御モジュール 2 1 1が、 "SCRIPT.DAT" ファイルを実行することにより、 1番目の PlayListO (PlayList#0) の再生が、 プレイヤ制御モジュール 2 1 2に指示されたとすると、 第 30図の再生処理が行われる。
「再生処理」
即ち、 第 3 0図は、 ビデオコンテンツ再生プログラム 2 1 0が行う 再生処理を説明するフローチャートである。
「再生準備処理」
再生処理では、 プレイヤ制御モジュール 2 1 2は、 まずステップ S 1 2 1と S 1 2 2において、 スクリプ.ト制御モジュール 2 1 1から再 生を指示された PlayList()、 即ち、 1番目の PlayList 0 (PlayList#0 ) の再生準備処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 ステップ S 1 2 1におい て、 1番目の P yList#0に含まれる 1番目の PlayItem#0の IN— time ( 第 6図） を確認して、 ステップ S 1 22に進み、 1番目の P yList#0 に含まれる 1番目の PlayItem#0によって再生されるクリップストリ一 ムファイル" 00001.PS"上の、 その PlayItem#0の IN—timeに相当する、 再生を開始する再生開始位置を調査する。
ここで、 PlayltemOの Iltime (第 6図） が、 クリップストリーム ファイルの先頭を指し示している場合には、 クリップストリームファ ィルの先頭から、 プログラムストリームを読み出せば良いが、 IN_tim eが、 クリップストリームファイルの先頭以外を指し示している場合 には、 IN— timeに対応する位置を探し出し （調査し） 、 そこからプロ グラムストリームを読み出す必要がある。
具体的には、 第 2 5図に示した場合、 1番目の PlayList#0に含まれ る 1番目の PlayItem#0の IN一 timeは、 180, 090である。 プレイヤ制御モ ジュール 2 1 2は、 1番目の PlayList#0に含まれる 1番目の P yltem #0によって再生されるクリップストリームファイル" 00001. CLP"の、 第 27図に示した EP一 map 0から、 Playl tem#0の IN— t imeである 180, 090 に適した再生開始位置を探し出す。
即ち、 プレイヤ制御モジュール 2 1 2は、 例えば、 EP一 mapOに記述 されたデコ一ド開始可能点を表す PTS— EP_startのうちの、 式 PTS_EP_s tart≤IN_timeを満たす最大の PTS— EP_startを、 二分探索 （バイナリ サーチ） 等を用いて検索する。 ここで、 IN_time以下の PTS_EP— start を検索するのは、 INJimeによって表される位置が、 デコード開始可 能点であるとは限らないからである。 .
いまの場合、 IN— timeは、 上述したように、 180, 090である。 また、 1番目の PlayList#0に含まれる 1番目の Play It em#0によって再生され るクリップストリームファイル" 00001. CLP"の、 第 27図に示した6?_ mapOにおいては、 式 PTS EP_s tar t≤ IN—t imeを満たす最大の PTS— EP— s tartとして、 180, 090が記述されている。 従って、 プレイヤ制御モジ ユール 2 1 2では、 第 27図に示した EPjnapOから、 その 180, 090と なっている PTS_EP_startが検索される。
さらに、 プレイヤ制御モジュール 2 1 2では、 その検索された PTS_ EP_startに対応する RPN_EP_startである 305 (セクタ） が読み出され 、 その 305である RPN_EP_startによって表されるクリップストリーム ファイル" 00001.PS"上の位置が、 再生開始位置として決定される。 プレイヤ制御モジュール 2 1 2は、 以上のようにして再生開始位置 を決定すると、 ステップ S 1 22から S 1 23に進み、 タイムコード を表示するように、 グラフィクス処理モジュール 2 1 9を制御する。 グラフィクス処理モジュール 2 1 9は、 プレイヤ制御モジュール 2 1 2の制御にしたがい、 タイムコード （のビデオデータ） を生成してビ デォ出力モジュール 220に出力する。 これにより、 タイムコードの 表示が開始される。
ここで、 ステップ S 1 2 3で表示が開始されるタイムコードは、 例 えば、' PlayListOの先頭を 00:00:00 (時間：分：秒） に換算した値とす る。 なお、 タイムコードとともに、 またはタイムコードではなく、 チ ャプ夕ゃィンデクスの番号を表示するようにしても良い。
「PlaylistMarkOの解析処理」
ステップ S 1 2 3でタイムコードの表示が開始された後は、 ステツ プ S 1 24に進み、 プレイヤ制御モジュール 2 1 2は、 スクリプト制 御モジュール 2 1 1から再生を指示された PlayList()、 即ち、 1番目 の PlayListO (PlayList#0) に記述されている PlayListMarkO (第 7 図） を解析する解析処理を行う。
具体的には、 プレイヤ制御モジュール 2 1 2は、 既に読み込んであ る" PLAYLIST.DAT"ファイルにおける 1番目の PlayList#0の、 第 2 8図 上側に示した PlayListMarkOにおいて、 number— of— PlayListjnarksが 7になっていることから、 その PlayList#0に含まれる MarkOの数が 7 であることを認識する。
さらに、 プレイヤ制御モジュール 2 1 2は、 PlayListifOに含まれる 、 第 28図上側の 7つの MarkOを解析し、 その reし to_PlayI tem_idか ら、 7つの MarkOのうちの 1番目から 4番目までの 4つの MarkOが、 PlayLis 0の 1番目の PlayltemO (PlayltemftO) に属していることを 認識する。
その後、 プレイヤ制御モジュール 2 1 2は、 PlayList#0の 1番目の PlayItem#0に属している 4つの MarkOの mark_t ime_sta即を取り出し 、 要素数が 4の配列として、 デコード制御モジュール 2 14に渡す。 即ち、 これにより、 第 2 8図上側の 7つの MarkOのうちの 1番目から 4番目までの 4つの MarkOそれぞれの mark_time_sta即である {180， 09 0}、 {5， 580， 090}、 {10, 980， 090}、 {16， 380， 090}の 4つの時刻が、 プレイヤ制御モジュール 2 12から、 デコード制御モジュール 2 1 4 に渡ざれる。 このときこれら時刻の属性は 「マーク処理」 であること も、 プレイヤ制御モジュール 2 1 2から、 デコード制御モジュール 2 14に伝えられる。 デコード制御モジュール 2 14は、 計時部 2 14 Aで計時している時刻が、 「マーク処理」 の属性の時刻に一致したと き、 その旨を示すメッセージ、 「マーク処理」 の属性の時刻に一致し た時刻、 および 「マーク処理」 の属性を、 プレイヤ制御モジュール 2 1 2に伝える。
「再生するエレメン夕リストリームの決定処理」
次に、 ステップ S 1 24から S 1 2 5に進み、 プレイヤ制御モジュ —ル 2 1 2は、 再生するエレメン夕リストリ一ムを決定する。
即ち、 プレイヤ制御モジュール 2 1 2は、 スクリプト制御モジュ一 ル 2 1 1から再生を指示された PlayList 0である 1番目の PlayList#0 における 1番目の PlayItem#0 (第 2 5図） の CI ip— Informat ion_f ime_ nameにファイル名が記述されている、 第 26図 Aおよび第 26図 Bの クリップ情報ファイル" 00001. CLP"において、 number— of— streamsが 4 になっていることから、 対応するクリップストリームファイル" 00001 • PS"に、 4本のエレメン夕リストリームが多重化されていることを認 識する。 さらに、 プレイヤ制御モジュール 2 1 2は、 その 4本のエレ メンタリストリ一ムに対する、 第 26図 Aおよび第 26図 Bのクリッ プ情報ファィル"00001.0^"の31& (；11^0()の5 6&111__1(1と必要な0]* ate_stream__idを順に調査し、 その 4本のエレメン夕リストリームが 、 1本のビデオストリーム、 1本の ATRACオーディオストリーム、 お よび 2本の字幕ストリームであることを認識する。 即ち、 クリップス トリ一ムファイル" 00001.PS"に多重化されている各属性のエレメン夕 リストリームの本数が認識される。
なお、 クリップストリームファイルに多重化されている各属性のェ レメンタリストリームの本数の情報は、 再生中でのエレメンタリスト リームの切り替え （オーディオ切り替え、 字幕切り替え等） に使用さ れる。 また、 字幕ストリームは、 クリップストリームファイル中に存 在しない （コンテンツに字幕が含まれない） 場合があり、 字幕ストリ ームが存在するかどうかの判断に、 「字幕ストリーム」 の属性のエレ メンタリストリームの本数の情報が使用される。
プレイヤ制御モジュール 2 1 2は、 以上のような StaticInfoOの調 査の結果に基づいて、 再生するエレメンタリストリームを選択、 決定 するが、 いまの場合、 クリップストリ一ムファイル" 00001.PS"に多重 化されている 4本のエレメン夕リストリームの中に、 「ビデオストリ —ム」 と 「オーディオストリーム」 の属性のエレメンタリストリーム は、 それぞれ 1本しかないので、 「ビデオストリーム」 と 「オーディ ォストリーム」 の属性のエレメン夕リストリームについては、 選択の 余地がなく、 その 1本のビデオストリームとオーディオズトリーム （ ATRACオーディオストリーム） が、 再生するエレメン夕リストリーム として決定される。
また、 「字幕ストリーム」 の属性のエレメン夕リストリームについ ては、 クリップストリ一ムファイル" 00001.PS"に多重化されている 4 本のエレメンタリストリームの中に 2本存在するので、 その 2本の字 幕ストリームのうちのいずれか 1本の字幕ストリームが、 再生するェ レメン夕リストリームとして選択、 決定される。 ここでは、 例えば、 2本の字幕ストリームのうちの、 クリップ情報ファイル" 00001. CLP" での出現順で最初の字幕ストリームが選択されることとする。
ここで、 上述のように、 クリップストリームファイル" 00001.PS"に 多重化されている 4本のエレメン夕リストリームの属性と本数を認識 するにあたっては、 その 4本のエレメン夕リストリームそれぞれを特 定する必要があるが、 プレイヤ制御モジュール 2 1 2は、 クリップス トリームファイル" 00001.PS"に多重化されている 4本のエレメンタリ ストリームの特定を、 stream_idと必要な private— stream_idによって 行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 クリップストリームファ ィル" 00001.PS"に多重化されている 4本のエレメンタリストリームの うちの、 「ビデオストリーム」 の属性のエレメンタリストリ一ムであ るビデオストリームを、 第 2 6図 Aおよび第 2 6図 Bでクリップ情報 ファイル" 00001. CLP"について説明したように、 OxEOとなっている str eam— idで特定する。
また、 プレイヤ制御モジュール 2 1 2は、 クリップストリ一ムファ ィル" 00001.PS"に多重化されている 4本のエレメンタリストリームの うちの、 「オーディオストリーム」 の属性のエレメンタリス卜リーム である ATRACオーディォストリームを、 第 2 6図 Aおよび第 2 6図 B でクリップ情報ファイル" 00001. CLP"について説明したように、 OxBD となっている stream_id、 および 0x00となっている private_stream一 id で特定する。
さらに、 プレイヤ制御モジュール 2 1 2は、 クリップストリームフ アイル" 00001.PS"に多重化されている 4本のエレメン夕リストリ一ム . における 「字幕ストリーム」 の属性のエレメン夕リストリームである 2本の字幕ストリームそれぞれを、 第 2 6図 Aおよび第 2 6図 Bでク リップ情報フアイル" 00001. CLP"について説明したように、 OxBDとな つている stream_id、 および 0x80となっている private_stream_idと、 OxBDとなっている stream— id、 および 0x81となっている private—strea m— idで、 それぞれ特定する。
以上のように、 クリップストリームファイルに対応するクリップ情 報ファイルのメタデータとして記述される 3 6&111^(1と0]~^&16_3^6& m_idの組み合わせによって、 そのクリップストリームファイルに多重 化されているエレメンタリストリームを特定することができる。
ここで、 stream— idと private一 stream— idの組み合わせは、 MPEG2-Sy stemの多重化を拡張するために設けたメカニズムである。 この stream — idと private_stream_idの組み合わせを、 メタデータ （データベース ) において、 エレメンタリストリームを特定するために使用すること により、 エレメンタリス卜リームを確実に特定することが可能になる 。 また、 将来、 private— stream一 idの意味を拡張し、 対応するエレメ ン夕リストリームの本数や種類 （属性） を増やした場合にも現在のメ 力二ズムをそのまま使用可能であるため、 拡張性において勝っている 即ち、 例えば、 BD(Blue ray Disc)規格では、 データの特定に、 MPE G2規格のトランスポートストリーム（Transport Stream)の PID (Packet ID)が用いられるため、 MPEG2規格に拘束される。 また、 例えば、 DV D- Video規格では、 private— stream— idに類似する sub— stream— idが定 義されているが、 sub_stream_idは、 ストリームの特定のためにデー タベース上に記述することができるようにはなっておらず、 8本ある いは 32本のストリーム情報を記述する固定的な領域に記述することが できるにすぎないため （たとえば VI4- 49、 Table 4.2.1-2 (VTS- AST— A TRT) や VI4-52、 Table 4.2.1-3 (VTS_SPST_ATRT) 等参照） 、 拡張性 に乏しい。
これに対して、 stream_idと private_stream—idの組み合わせは、 メ 夕データが記述される、 例えば、 第 1 0図のクリップ情報ファイル C1 ip()において、 number—oし streamsで表すことができる数だけ記述す ることができ、 従って、 クリップストリームファイルに多重化されて いるエレメンタリストリームを、 その数によらず （伹し、 number_oし streamsで表すことができる数の範囲） 、 クリップ情報ファイル CI ip( )に記述されたメタデ一夕としての stream_idと private一 stream_idの 組み合わせから特定することが可能となる。
なお、 本実施の形態では、 stream_idと private— stream— idの組み合 わせは、 第 1 0図のクリップ情報ファイルにおいて、 対応するクリツ ブストリームファイルに多重化されているエレメン夕リストリームを 特定するのに使用される他、 例えば、 第 7図の PlayListMarkOにおけ る entry— ES— st ream一 idと entry— ES— private— stream— idの組み合わせと して、 MarkOを関連付けるエレメン夕リストリームの特定にも使用さ れる。 さらに、 stream_idと private_stream_idの組み合わせは、 その 他、 例えば、 第 1 4図の EPjnap Oにおいて、 デコード可能開始点の情 報を記述するエレメンタリストリームの特定にも使用される。
「出力属性の制御処理」
その後、 ステップ S 1 2 5から S 1 2 6に進み、 プレイヤ制御モジ ユール 2 1 2は、 再生対象のエレメン夕リストリーム、 即ち、 ステツ プ S 1 2 5で再生すると決定したエレメン夕リストリームの出力属性 の制御処理を行う。
具体的には、 プレイヤ制御モジュール 2 1 2は、 まず、 再生対象の エレメン夕リストリーム、 即ち、 ステップ S 1 2 5で再生すると決定 したビデオストリーム、 ATRACオーディオストリーム、 字幕ストリ一 ムそれぞれについて、 出力属性が記述される Dynami c Inf o O (第 1 3 図） の数を表す number_oし Dynami c lnf o (第 1 0図） を調査する。
ここで、 いまの場合、 再生対象のビデオストリーム、 ATRACオーデ ィォストリーム、 字幕ストリームは、 クリップストリームファイル" 0 0001. PS"に多重化されているエレメン夕リストリームであり、 それら の number— 0し Dynami c lnf oは、 第 2 6図 Aおよび第 2 6図 Bの" 00001 · CLP"で説明したように/いずれも 0になっている。 このように、 再生 対象のエレメン夕リストリームのすべてについて、 number_oし Dynami c lnf oが 0である場合、 プレイヤ制御モジュール 2 1 2は、 再生対象の エレメンタリス卜リームの出力属性の制御処理としては、 特に処理を 行わない。
なお、 再生対象のエレメン夕リストリ一ムについての number_oし Dy nami c lnfoが 0でない場合に、 そのエレメン夕リストリームの出力属性 の制御として行われる処理については、 後述する。
「再生開始の準備処理」
ステップ S 1 2 6の処理後は、 ステップ S 1 2 7に進み、 プレイヤ 制御モジュール 2 1 2は、 再生対象のエレメンタリストリームの再生 開始の準備処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 コンテンツデータ供給モ ジュール 2 1 3に対し、 再生対象のエレメン夕リストリームが多重化 されているクリップストリームファイル" 00001. PS"のファイル名と、 ステップ S 1 2 2で決定した再生開始位置である EPjnap Oに記述され た RPN_EP— s tar t (=305) を与える。
さらに、 プレイヤ制御モジュール 2 1 2は、 再生対象のエレメンタ リストリームが多重化されているクリップストリームファイル" 00001 . PS"に格納されたプログラムストリームの、 バッファ制御モジュール 2 1 5への供給が開始される前に、 バッファ制御モジュール 2 1 5を 初期化する。
具体的には、 バッファ制御モジュール 2 1 5 (第 3図） では、 デ一 夕先頭ポインタ記憶部 2 3 1に記憶されるデ一夕先頭ポインタ、 デ一 夕書き込みポインタ記憶部 2 3 2に記憶されるデータ書き込みポイン 夕、 ビデオ読み出しポインタ記憶部 2 4 1に記憶されるビデオ読み出 しポインタ、 オーディオ読み出しポインタ記憶部 2 5 1に記憶される オーディオ読み出しポインタ、 字幕読み出しポインタ記憶部 2 6 2に 記憶される字幕読み出しポインタに、 同じ値が代入される。
これにより、 データ先頭ポインタ記憶部 2 3 1に記憶されたデ一夕 先頭ポインタと、 データ書き込みポインタ 2 3 2に記憶されたデータ 書き込みボイン夕とは、 バッファ制御モジュール 2 1 5のバッファ 2 1 5 Aの同一の位置を指す。 これは、 バッファ 2 1 5 Aに、 有効なデ 一夕が蓄積されていない状態を表す。
さらに、 プレイヤ制御モジュール 2 1 2は、 再生対象のエレメンタ リストリームを識別 （特定） するための識別情報としての s t ream— i d 、 さらには、 必要に応じて、 private一 stream_idを、 バッファ制御モ ジュール 2 1 5に供給する。
即ち、 上述したように、 再生対象のエレメン夕リストリームのうち の、 「ビデオストリーム」 の属性のビデオストリームは、 OxEOとなつ ている stream_idによって特定され、 「オーディオストリーム」 の属 性の ATRACオーディオストリームは、 OxBDとなっている stream_id、 お よび 0x00となっている private_stream_idによって特定され、 「字幕 ストリーム」 の属性の字幕ストリームは、 OxBDとなっている stream_i d、 および 0x80となっている private— st ream—idによって特定される。 プレイヤ制御モジュール 2 1 2は、 これらの stream— idと private—str earn一 idを、 バッファ制御モジュール 2 1 5に供給する。
バッファ制御モジュール 2 1 5 (第 3図） では、 ビデオ読み出し機 能部 233が、 プレイヤ制御モジュール 2 1 2からの、 ビデオストリ ームについての OxEOとなっている stream— idを、 s t ream— idレジスタ 2 42に記憶させる。 また、 オーディオ読み出し機能部 234が、 プレ ィャ制御モジュール 2 1 2からの、 OxBDとなっている stream— idと、 0 xOOとなっている private— stream— idを、 s tream_idレジスタ 2 5 2と p rivate— stream— idレジス夕 2 53に、 それぞれ記憶させる。 さらに、 字幕読み出し機能部 2 3 5が、 プレイヤ制御モジュール 2 12からの 、 OxBDとなっている stream_idと、 0x80となっている private_stream_ idを、 stream_idレジスタ 2 63と private一 stream_idレジスタ 264 に、 それぞれ記憶させる。 .
なお、 プレイヤ制御モジュール 2 1 2は、 バッファ制御モジュール 2 1 5に供給した再生対象のエレメンタリストリームの stream— idと p rivate_stream— idを、 今後の処理のために記憶する。 プレイヤ制御モ ジュール 2 1 2は、 これらの stream idや private— stream_idを、 後述 するストリーム切り替えを要求するメッセージの発生時や、 後述する マーク処理において現在再生中のストリームを特定するために使用す る。
プレイヤ制御モジュール 2 1 2は、 バッファ制御モジュール 2 1 5 (第 3図） の初期化として、 さらに、 再生対象のエレメン夕リストリ ームが多重化されているクリップストリームファイルに応じた値の字 幕読み出し機能フラグを、 字幕読み出し機能フラグ記憶部 26 1にセ ットする。
即ち、 いまの場合、 再生対象のエレメンタリストリームが多重化さ れているクリップストリームファイル" 00001.PS"には、 字幕ストリー ムが含まれるため、 字幕読み出し機能部 2 3 5を機能させるために、 値が 1の字幕読み出し機能フラグが、 字幕読み出し機能フラグ記憶部 26 1にセットされる。 なお、 再生対象のエレメンタリストリ一ムが 多重化されているクリップストリームファイルに字幕ストリームが含 まれていない場合、 字幕読み出し機能フラグ記憶部 26 1には、 値が 0の字幕読み出し機能フラグがセットされる。 この場合、 字幕読み出 し機能部 23 5は機能しない （特に処理を行わない） 。
また、 プレイヤ制御モジュール 2 1 2は、 スクリプト制御モジュ一 ル 2 1 1から再生を指示された 1番目の PlayList#0に含まれる 1番目 の PlayItem#0 (第 2 5図） の INJ imeである 180, 090と、 0UT_timeであ る 27， 180, 090とを、 デコード制御モジュール 2 14に対して与える。 デコード制御モジュール 2 14では、 I.ltimeは、 Playl tem()によつ て再生されるクリップのデコード開始の制御に、 OUT一 timeは、 そのク リップのデコード終了、 さらには、 後述する Playl tem乗り換えの制御 に、 それぞれ使用される。
さらに、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジ ユール 2 1 9に対する字幕ス卜リームの表示方式の指示を初期化する 。 即ち、 プレイヤ制御モジュール 2 1 2は、 字幕ストリームの表示方 式を、 例えば、 デフォルトの表示方式とするように、 グラフィクス処 理モジュール 2 1 9を制御する。
「データ読み込み開始」
その後、 ステップ S 1 2 7から S 1 2 8に進み、 プレイヤ制御モジ ユール 2 1 2は、 コンテンツデータ供給モジュール 2 1 3を制御し、 これにより、 コンテンツデ一夕供給モジュール 2 1 3は、 オペレーテ. ィングシステム 2 0 1の機能を使用して、 再生対象のエレメンタリス トリームが多重化されたプログラムストリームが格納されたクリップ ストリームファイルを読み出す。 すなわち、 コンテンツデータ供給モ ジュ一ル 2 1 3は、 ディスク 1 0 1 (第 4図） の" VIDEO"ディレクト リの下にある" STREAM"ディレクトリのクリップス卜リームフアイル" 0 0001. PS"を 定し、 さらに、 ステップ S 1 2 2で決定された再生開始 位置である 305セクタを指定して、 オペレーティングシステム 2 0 1 に対してファイル読み出しを要求する。 また、 コンテンツデータ供給 モジュール 2 1 3は、 ディスク 1 0 1から読み出したデータを、 バッ ファ制御モジュール 2 1 5に供給するように指定する。
これにより、 ディスク 1 0 1からの、 クリップストリームファイル " 00001. PS"に格納されたプログラムストリームの読み出しが開始され 、 そのプログラムストリ一ムは、 バッファ制御モジュール 2 1 5に供 給される。 .
バッファ制御モジュール 2 1 5 (第 3図） は、 ディスク 1 0 1から 読み出されて供給されたプログラムストリ一ムを、 バッファ 2 1 5 A のデータ書き込みポインタ記憶部 2 3 2のデータ書き込みポインタが 指す位置に書き込み、 書き込んだデータのサイズだけデータ書き込み ポインタをインクリメントする。
ここで、 以下、 特に断らない限り、 コンテンツデータ供給モジユー ル 2 1 3は、 、リファ制御モジュール 2 1 5のバッファ 2 1 5 Aに空 きがあれば、 ディスク 1 0 1からデ一夕を読み出し、 バッファ制御モ ジュール 2 1 5のバッファ 2 1 5 Aに供給して記憶させることとする 。 従って、 バッファ 2 1 5 Aには、 常時、 十分なデ一夕が蓄積されて いるとする。
「デコーダ制御開始」
以上のようにして、 ディスク 1 0 1からのデータの読み出しが開始 され、 そのデータがバッファ制御モジュール 2 1 5のバッファ 2 1 5 Aに蓄積され始めると、 ステップ S 1 2 8から S 1 2 9に進み、 デコ —ド制御モジュール 2 1 4は、 ビデオデコーダ制御モジュール 2 1 6 、 オーディオデコーダ制御モジュール 2 1 7、 字幕デコーダ制御モジ ユール 2 1 8を制御し、 デコード動作の前段階として、 バッファ 2 1 5 Aからのデータの読み出しを開始させる。
即ち、 これにより、 ビデオデコーダ制御モジュール 2 1 6は、 バッ ファ制御モジュール 2 1 5 (第 3図） のビデオ読み出し機能部 2 3 3 にデータを要求し、 その要求に応じてバッファ制御モジュール 2 1 5 から渡される、 バッファ 2.1 5 Aに記憶された 1つのビデオアクセス ユニット、 そのビデオアクセスユニットに付加されている PTSと DTS ( 以下、 適宜、 タイムスタンプという） 、 およびデコード開始可能点の 直前に配置されている pr ivat e— s t reamjの PES— packe t 0に記述された 情報 （以下、 適宜、 付加情報ともいう） である pi c_s t rucし copyや、 a u_reし f l ag、 AU_l engthなどを得る。 なお、 タイムスタンプは、 ビデ ォデコーダ制御モジュール 2 1 6がビデオアクセスュニットを得る毎 に、 ビデオデコーダ制御モジュール 2 1 6からデコード制御モジユー ル 2 1 4に渡される。
一方、 オーディオデコーダ制御モジュール 2 1 7も、 バッファ制御 モジュール 2 1 5 (第 3図） のオーディオ読み出し機能部 2 3 4にデ 一夕を要求し、 その要求に応じてバッファ制御モジュール 2 1 5から 渡される、 バッファ 2 1 5 Aに記憶された 1つの（ATRAC)オーディオ アクセスュニットと、 そのオーディォアクセスュニットに付加されて いるタイムスタンプ （PTS， DTS) を得る。 なお、 タイムスタンプは、 オーディオデコーダ制御モジュール 2 1 7がオーディオアクセスュニ ットを得る毎に、 オーディオデコーダ制御モジュール 2 1 7からデコ ード制御モジュール 2 1 4に渡される。
さらに、 字幕デコーダ制御モジュール 2 1 8は、 バッファ制御モジ ユール 2 1 5 (第 3図） の字幕読み出し機能部 2 3 5にデータを要求 し、 その要求に応じてバッファ制御モジュール 2 1 5から渡される、 バッファ 2 1 5 Aに記憶された 1つの字幕アクセスュニッ卜と、 その 字幕アクセスユニットに付加されているタイムスタンプを得る。 なお 、 タイムスタンプは、 字幕デコーダ制御モジュール 2 1 8が字幕ァク セスュニッ卜を得る毎に、 字幕デコーダ制御モジュール 2 1 8からデ コード制御モジュール 2 1 4に渡される。 また、 再生対象のエレメン 夕リストリームに、 字幕ストリームが存在しない場合や、 バッファ 2 1 5 Aに、 字幕アクセスユニットが記憶されていない場合は、 パッフ ァ制御モジュール 2 1 5から字幕デコーダ制御モジュール 2 1 8には 、 データは渡されない。 .
ここで、 ビデオデコーダ制御モジュール 2 1 6、 オーディオデコ一 ダ制御モジュール 2 1 7、 および字幕デコーダ制御モジュール 2 1 8 は、 バッファ制御モジュール 2 1 5に対してデータを要求する毎に、 そのデータの要求に対する結果を、 デコード制御モジュール 2 1 4に 渡す。
また、 バッファ制御モジュール 2 1 5から、 ビデオデコーダ制御モ ジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 および 字幕デコーダ制御モジュール 2 1 8に対してデータが渡されるときの 、 そのデータのバッファ 2 1 5 Aからの読み出しの詳細については、 後述する。
「デコード開始」
以上のように、 ビデオデコーダ制御モジュール 2 1 6、 オーディオ デコーダ制御モジュール 2 1 7、 字幕デコーダ制御モジュール 2 1 8 が、 バッファ制御モジュール 2 1 5のバッファ 2 1 5 Aからデータを 読み出し始めると、 ステップ S 1 2 9から S 1 3 0に進み、 そのデー 夕のデコ一ドが開始される。
即ち、 デコード制御モジュール 2 1 4は、 ステップ S 1 2 7でプレ ィャ制御モジュール 2 1 2から与えられた、 P l ayL i s t #0に含まれる 1 番目の？1 & ^ 6111#0の1 _ 1!16でぁる180， 090、 さらには、 ビデオデコ一 ダ制御モジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7 、 字幕デコーダ制御モジュール 2 1 8からステップ S 1 2 9で説明し たように渡されるタイムスタンプに基づき、 同期を確保するために必 要であればタイミングをず.らして、 デコード開始を、 ビデオデコーダ 制御モジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 および字幕デコーダ制御モジュール 2 1 8に指令する。
ここで、 同期を確保するためのタイミングをずらしたデコード開始 の指令の方法は、 例えば、 特許第 3496725号に記載されており、 簡単 には、 ビデオデコーダ制御モジュール 2 1 6、 オーディオデコーダ制 御モジュール 2 1 7、 字幕デコーダ制御モジュール 2 1 8それぞれか ら渡されたタイムスタンプのうちの最小値を、 計時部 2 1 4 Aによつ て計時される時刻の初期値として設定して時刻の計時を開始し、 計時 部 2 1 4 Aによって計時される時刻と、 タイムスタンプとがー致した 時点で、 デコード開始を指令する方法がある。
ビデオデコーダ制御モジュール 2 1 6は、 デコード制御モジュール 2 1 4からのデコード開始の指示を受け、 その指示に応じて、 バッフ ァ制御モジュール 2 1 5 (第 3図） のビデオ読み出し機能部 2 3 3か ら得た 1つのビデオアクセスユニットを、 ビデオデコーダ 1 1 6 (第 1図） に渡してデコードさせる。 さらに、 ビデオデコーダ制御モジュ ール 2 1 6は、 ビデオデコーダ 1 1 6によるデコードの結果得られる ビデオデ一夕を、 グラフィクス処理モジュール 2 1 9に供給する。 以後、 ビデオデコーダ制御モジュール 2 1 6は、 バッファ制御モジ ユール 2 1 5のビデオ読み出し機能部 2 3 3から得られる 1ずつのビ デォアクセスユニットを、 ビデオデコーダ 1 1 6で順次デコードし、 そのデコードの結果得られるビデオデータを、 グラフィクス処理モジ ユール 2 1 9に供給していく。
一方、 オーディオデコーダ制御モジュール 2 1 7も、 デコード制御 モジュール 2 1 4からのデコード開始の指示を受け、 その指示に応じ て、 バッファ制御モジュール 2 1 5 (第 3図） のオーディオ読み出し 機能部 2 3 4から得た 1つのオーディオアクセスュニットを、 オーデ ィォデコーダ 1 1 7 (第 1図） に渡してデコードさせる。 さらに、 ォ —ディォデコーダ制御モジュール 2 1 7は、 オーディオデコーダ 1 1 7によるデコードの結果得られるオーディオデータを、 オーディォ出 力モジュール 2 2 1に供給する。
以後、 オーディオデコーダ制御モジュール 2 1 7は、 バッファ制御 モジュール 2 1 5のオーディォ読み出し機能部 2 3 4から得られる 1 ずつのオーディオアクセスュニットを、 オーディォデコーダ 1 1 7で 順次デコードし、 そのデコ一ドの結果得られるオーディォデータを、 オーディオ出力モジュール 2 2 1に供給していく。
また、 字幕デコーダ制御モジュール 2 1 8も、 デコード制御モジュ ール 2 1 4からのデコード開始の指示を受け、 その指示に応じて、 バ ッファ制御モジュール 2 1 5 (第 3図） の字幕読み出し機能部 2 3 5 から得た 1つの字幕アクセスュニットを、 内部に持つ字幕デコードソ フトウェアでデコードし、 そのデコードの結果得られる字幕データ （ 字幕の画像データ） を、 グラフィクス処理モジュール 2 1 9に供給す. る。
以後、 字幕デコーダ制御モジュール 2 1 8は、 バッファ制御モジュ ール 2 1 5の字幕読み出し機能部 2 3 5から得られる 1ずつの字幕ァ クセスュニットを、 内部に持つ字幕デコードソフトウエアで順次デコ ードし、 そのデコードの結果得られる字幕データを、 グラフィクス処 理モジュール 2 1 9に供給していく。
「グラフィクス処理」
その後、 ステップ S 1 3 0から S 1 3 1に進み、 グラフィクス処理 モジュール 2 1 9は、 上述したようにして、 ビデオデコーダ制御モジ ユール 2 1 6から供給されるビデオデ一夕、 さらには、 必要に応じて 、 字幕デコーダ制御モジュール 2 1 8から供給される字幕データを対 象に、 グラフィクス処理を行う。
即ち、 グラフィクス処理モジュール 2 1 9は、 まず字幕デコーダ制 御モジュール 2 1 8からの字幕デ一夕を、 プレイヤ制御モジュール 2 1 2からの表示方式の指示に従って、 拡大や縮小等する字幕処理を行 う。 プレイヤ制御モジュール 2 1 2から、 表示方式の指示がない場合 、 またはデフォルトの表示方式の指示があった場合、 グラフィクス処 理モジュール 2 1 9は、 字幕デコーダ制御モジュール 2 1 8からの字 幕デ一夕を、 そのまま保存する。
さらに、 グラフィクス処理モジュール 2 1 9は、 ビデオデコーダ制 御モジュール 2 1 6からのビデオデータと、 字幕デコーダ制御モジュ ール 2 1 8からの字幕デ一夕、 または字幕処理後の字幕データとを加 算し、 ビデオデコーダ制御モジュール 2 1 6からのビデオデータに字 幕データがオーバ一レイされた出力ビデオデータを得て、 ビデオ出力 モジュール 2 2 0に供給する。
なお、 グラフィクス処理モジュール 2 1 9は、 スクリプト制御モジ. ユール 2 1 1やプレイヤ制御モジュール 2 1 2から、 例えば、 メニュ —や、 メッセ一ジ、 タイムコード、 チヤプ夕またはインデクスの番号 等の情報の表示の指示を受けた場合は、 その情報を生成し、 出力ビデ ォデ一夕にオーバ一レイして、 ビデオ出力モジュール 2 2 0に供給す る。
「出力処理」
ステップ S 1 3 1の処理後は、 ステップ. S 1 3 2に進み、 ビデオ出 力モジュール 2 2 0は、 ステップ S 1 3 1で説明したようにしてダラ フィクス処理モジュール 2 1 9から供給される出力ビデオデ一夕を、 F IF0 2 2 O Aに順次記憶させ、 その F IF0 2 2 O Aに記憶された出力ビ デォデ一夕を、 あらかじめ決められた出力レートで順次出力する。 ビデオ出力モジュール 2 2 0は、 F IF0 2 2 0 Aの記憶容量 （残量） に余裕がある限り、 グラフィクス処理モジュール 2 1 9からの出力ビ デォデータを受け入れるが、 余裕がない場合には、 出力ビデオデ一夕 の受け入れの停止を、 グラフィクス処理モジュール 2 1 9に要求する 。 これにより、 グラフィクス処理モジュール 2 1 9は、 処理を停止す るとともに、 処理の停止を、 ビデオデコーダ制御モジュール 2 1 6お よび字幕デコーダ制御モジュール 2 1 8に要求する。 これにより、 ビ デォデコーダ制御モジュール 2 1 6および字幕デコーダ制御モジユー ル 2 1 8が処理を停止する。
ビデオ出力モジュール 2 2 0は、 出力ビデオデ一夕の受け入れの停 止を、 グラフィクス処理モジュール 2 1 9に要求した後に、 F IF0 2 2 0 Aからの出力ビデオデータの出力が進み、 F IF0 2 2 0 Aに余裕がで きた時点で、 出力ビデオデータの受け入れを、 グラフィクス処理モジ ユール 2 1 9に要求する。 この要求は、 出力ビデオデ一夕の受け入れ の停止の要求と同様に、 グラフィクス処理モジュール 2 1 9から、 ビ デォデコーダ制御モジュール 2 1 6および字幕デコーダ制御モジユー ル 2 1 8に伝えられる。 これにより、 グラフィクス処理モジュール 2
1 9、 さらには、 ビデオデコーダ制御モジュール 2 1 6および字幕デ コーダ制御モジュール 2 1 8は、 停止していた処理を再開する。
一方、 オーディォ出力モジュール 2 2 1も、 ステップ S 1 3 0で説 明したようにしてオーディオデコーダ制御モジュール 2 1 7から供給 されるオーディオデータを、 F IF0 2 2 1 Aに順次記憶させ、 その FIFO
2 2 l' Aに記憶されたオーディオデータを、 あらかじめ決められた出 力レート （サンプリング周波数） で順次出力する。
オーディォ出力モジュール 2 2 1は、 F IF0 2 2 1 Aの記憶容量 （残 量） に余裕がある限り、 オーディオデコーダ制御モジュール 2 1 7か らのオーディオデータを受け入れるが、 余裕がない場合には、 オーデ ィォデータの受け入れの停止を、 オーディォデコーダ制御モジュール
2 1 7に要求する。 これにより、 オーディオデコーダ制御モジュール
2 1 7は、 処理を停止する。
オーディオ出力モジュール 2 2 1は、 オーディオデータの受け入れ の停止を、 オーディオデコーダ制御モジュール 2 1 7に要求した後に
、 F IFO 2 2 1 Aからのォ一ディォデ一夕の出力が進み、 F IF0 2 2 1 A に余裕ができた時点で、 オーディオデータの受け入れを、 オーディオ デコーダ制御モジュール 2 1 7に要求する。 これにより、 オーディオ デコーダ制御モジュール 2 1 7は、 停止していた処理を再開する。 以上のようにして、 ビデオ出力モジュール 220およびオーディオ 出力モジュール 22 1からデ一夕が出力されるにつれて、 エレメン夕 リストリームのデコードが行われていく。
第 1図のディスク装置がディスク 1 0 1を再生するときの全体の処 理または動作の流れは、 第 2 9図および第 30図で説明したとおりで. あるが、 以下、 ディスク装置においてディスク 1 0 1の再生が行われ ているときの、 その他の処理または動作について説明する。
[Playltem乗り換え]
第 2 9図および第 30図で説明したようにして、 第 2 5図における 1番目の PlayList#0の 1番目の Playl tem#0の再生が始まるが、 PlayLi st#0によれば、 その 1番目の PlayItem#0の再生が終了すると、 2番目 の Playltem#lの再生が開始される。 即ち、 PlayItem#0から Playltem#l に PI ay It emを乗り換える PI ay Item乗り換えが行われる。
そこで、 第 3 1図のフローチャートを参照して、 この Playltem乗り 換えの処理について説明する。
第 2 9図および第 30図で説明したようにして、 第 2 5図における PlayList#0の 1番目の PlayItem#0 (のクリップ） の再生が開始される と、 デコード制御モジュール 2 14 (第 2図 Aおよび第 2図 B) は、 その 1番目の Playl tem#0の再生が行われている間、 内蔵する計時部 2 14 Aが計時している時刻を確認し続けている。
「PlayItem#0の再生終了」
そして、 デコード制御モジュール 2 1 4は、 計時部 2 14Aが計時 している時刻が、 第 30図のステップ 1 2 7でプレイヤ制御モジユー ル 2 1 2から与えられた 1番目の PlayItem#0の 0UT_Umeである 27, 180 ，090 (第 2 5図） に等しくなると、 ステップ S 1 5 1において、 デコ 一ド中断制御を行い、 PlayItem#0の再生を終了する。
即ち、 デコード制御モジュール 2 14は、 ビデオデコーダ制御モジ ユール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 字幕デコ ーダ制御モジュール 2 1 8を操作して、 デコード動作を停止させる。 さらに、 デコード制御モジュール 2 14は、 ビデオ出力モジュール 2 2 0を制御し、 現在出力中の出力ビデオデータを引き続き出力させる また、 デコード制御モジュール 2 14は、 1番目の PlayItem#0の再 生が終了した旨のメッセージを、 プレイヤ制御モジュール 2 1 2に伝 える。
「PlayItem#lの再生開始」
プレイヤ制御モジュール 2 1 2は、 上述したように、 第 29図のス テツプ S 1 0 5で、 1番目の P yList #0に、 1番目の Playl tem#0と 2番目の Playltem#lとが存在することを認識しており、 デコード制御 モジュール 2 14から、 1番目の PlayItem#0の再生が終了した旨のメ ッセージが伝えられると、 ステップ S 1 5 1から S 1 5 2に進み、 2 番目の Playltem#lの再生を， 上述した 1番目の PlayItem#0における場 合と同様にして開始する。
即ち、 2番目の Playltem#lの再生手順を概説すれば、 まず、 プレイ ャ制御モジュール 2 1 2は、 第 30図のステップ S 1 2 2における場 合と同様にして、 2番目の Playltem#lについて、 EPjnap 0に記述され た RPN_EP一 startのうちのいずれかを、 再生開始位置として決定する。 さらに、 プレイヤ制御モジュール 2 1 2では、 第 30図のステップ S 1 24で説明したようにして、 2番目の nayltem#lに属する MarkO の認識や、 第 3 0図のステップ S 1 2 5で説明したようにして、 P l ay I t em#lによって再生されるクリップストリームファイル" 00002. PS"に 多重化されている各属性のエレメン夕リストリームの本数の認識、 さ らには、 再生する （再生対象の） エレメンタリストリームの決定等が 行われる。
そして、 プレイヤ制御モジュール 2 1 2は、 第 3 0図のステップ S 1 2 7における場合と同様の処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 再生開始位置として決定 した8?_1^0 ()の1^18?_^ & 1^と、 再生対象のエレメン夕リストリーム が多重化されているクリップストリームファイルのファイル名、 即ち 、 いまの場合、 2番目の P l ayl t emif l (第 2 5図） の CI ip_Informat i on —f i l e— nameに記述された" 00002. CLP"に対応するクリップストリーム ファイル" 00002. PS"のファイル名を、 コンテンッデータ供給モジュ一 ル 2 1 3に対して与える。
さらに、 プレイヤ制御モジュール 2 1 2は、 再生対象のエレメン夕 リストリームが多重化されているクリップストリームファイル" 00002 • PS"に格納されたプログラムストリームの、 バッファ制御モジュール 2 1 5への供給が開始される前に、 バッファ制御モジュール 2 1 5を 初期化する。
即ち、 これにより、 バッファ制御モジュール 2 1 5 (第 3図） にお いて、 データ先頭ポインタ記憶部 2 3 1に記憶されるデータ先頭ボイ ンタ、 データ書き込みボイン夕記憶部 2 3 2に記憶されるデータ書き 込みポインタ、 ビデオ読み出しポインタ記憶部 2 1に記憶されるビ デォ読み出しボインタ、 オーディォ読み出しボインタ記憶部 2 5 1に 記憶されるオーディオ読み出しポインタ、 字幕読み出しポインタ記憶 部 2 6 2に記憶される字幕読み出しボイン夕に、 同じ値が代入される さらに、 プレイヤ制御モジュール 2 1 2は、 再生対象のエレメンタ リストリームを識別するための識別情報としての stream_id、 さらに は、 必要に応じて、 private_stream_idを、 バッファ制御モジュール 2 1 5に供給する。
バッファ制御モジュール 2 1 5 (第 3図） では、 ビデオ読み出し機 能部 233が、 プレイヤ制御モジュール 2 1 2からの、 再生対象のェ レメン夕リストリ一ムのうちのビデオストリームについての stream_i. dを、 stream_idレジスタ 242に記憶させる。 また、 オーディオ読み 出し機能部 234が、 プレイヤ制御モジュール 2 1 2からの、 再生対 象のエレメン夕リストリ一ムのうちのオーディオストリ一ムの st ream _idと private— stream— idを、 stream一 idレジス夕 2 52と private— str eam_idレジス夕 2 5 3に、 それぞれ記憶させる。
さらに、 いま再生対象となっているエレメンタリストリームが多重 化されているクリップストリームファイル" 00002.PS"には， 字幕スト リームが含まれるため、 プレイヤ制御モジュール 2 1 2から字幕読み 出し機能部 23 5には、 再生対象のエレメン夕リストリームのうちの 字幕ストリームの stream— idと private— stream一 idが供給され、 字幕読 み出し機能部 23 5は、 その stream一 idと private— stream— idを、 stre am_idレジスタ 26 3と private_stream_idレジス夕 264に、 それぞ れ記憶させる。
そして、 プレイヤ制御モジュール 2.1 2は、 バッファ制御モジュ一 ル 2 1 5 (第 3図） の初期化として、 さらに、 再生対象のエレメン夕 リストリームが多重化されているクリップストリームファイルに応じ た値の字幕読み出し機能フラグを、 字幕読み出し機能フラグ記憶部 2 6 1にセッ卜する。 即ち、 いまの場合、 再生対象のエレメン夕リストリームが多重化さ れているクリップストリームファイル" 00002.PS"には、 字幕ストリー ムが含まれるため、 字幕読み出し機能部 23 5を機能させるために、 値が 1の字幕読み出し機能フラグが、 字幕読み出し機能フラグ記憶部 26 1にセットされる。
また、 プレイヤ制御モジュール 2 1 2は、 再生しょうとしている 2 番目の Playltem#l (第 2 5図） の IN_t imeである 90， 000と、 OUT— time である 27, 090， 000とを、 デコード制御モジュール 2 14に対して与え る。
さらに、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジ ユール 2 1 9に対する字幕ストリームの表示方式の指示を初期化する 。 即ち、 プレイヤ制御モジュール 2 1 2は、 字幕ストリームの表示方 式をデフォルトの表示方式とするように、 グラフィクス処理モジユー ル 2 1 9を制御する。
なお、 再生対象の字幕ストリームについて、 configurable— flag ( 第 1 2·図） が、 表示方式の変更を許可する 1になっている場合には、 プレイヤ制御モジュール 2 1 2からグラフィクス処理モジュール 2 1 9に対する字幕ストリームの表示方式の指示は、 現在の表示方式のま まとするようにしても良い。.
以下、 2番目の Playltem#lの再生は、 1番目の Playl tem#0の再生と 同様にして行われていく。 そして、 デコード制御モジュール 2 14は 、 その 2番目の Playltem#lの再生が行われている間、 内蔵する計時部 2 14 Aが計時している時刻を確認し続けており、 計時部 2 14 Aが 計時している時刻が、 ステップ S 1.52 (第 3 1図） でプレイヤ制御 モジュール 2 1 2から与えられた 2番目の P yltemitlの 0UT_timeであ る 27, 090， 000 (第 2 5図） に等しくなると、 ステップ S 1 5 1におけ る場合と同様のデコード中断制御を行い、 Playltem#lの再生を終了す る。
[タイムコードの表示]
次に、 上述したように、 第 30図のステップ S 1 2 3において、 タ ィムコードの表示が開始されるが、 このタイムコードの表示は、 順次 更新されていく。
そこで、 第 3 2図のフローチャートを参照して、 タイムコードの表 示の処理について説明する。
デコード制御モジュール 2 14 (第 2図 Aおよび第 2図 B) は、 そ の内蔵する計時部 2 14 Aによって 1秒が計時されると、 ステップ S 1 7 1において、 1秒が経過した旨のメッセージとともに、 その計時 部 2 14 Aによって計時されている現在時刻を、 プレイヤ制御モジュ —ル 2 1 2に供給し、 ステップ S 1 7 2に進む。 ステップ S 1 7 2で は、 プレイヤ制御モジュール 2 1 2は、 デコード制御モジュール 2 1 4からのメッセージと現在時刻を受信し、 その現在時刻を、 タイムコ —ドに換算して、 ステップ S 1 7 3に進む。
ステップ S 1 7 3では、 プレイヤ制御モジュール 2 1 2は、 ステツ プ S 1 7 2で得たタイムコードを表示するように、 グラフィクス処理 モジュール 2 1 9を制御レ、 ステップ S 1 7 1に戻る。
これにより、 タイムコードは、 1秒ごとに更新される。 なお、 タイ ムコードの更新の間隔は、 1秒に限定されるものではない。
[ストリーム切り替え] .
次に、 第 2 5図で説明した 1番目の PlayList#0を構成する 1番目の PlayItem#0によって再生されるクリップストリ一ムファイル" 00001. P S"や、 2番目の Playltem#lによって再生されるクリップストリ一ムフ アイル" 00002.PS"には、 第 2 6図 Aおよび第 2 6図 Bで説明したよう に、 2本の字幕ストリームが多重化されている。
このように、 クリップストリームファイルに、 複数の、 同一の属性 のエレメンタリストリームが多重化されている場合においては、 再生 対象のエレメンタリストリ一ムを、 その複数の、 同一の属性のエレメ ンタリストリームのうちの 1つから、 他の 1つに切り替えるストリー ム切り替えを行うことができる。
そこで、 第 3 3図のフローチャートを参照して、 ストリーム切り替 えの処理について説明する。
ストリーム切り替えの要求は、 例えば、 " SCRIPT. DAT"ファイル （第 4図） に、 ストリーム切り替えの指示がスクリプトプログラムとして 記述されている場合に、 スクリプト制御モジュール 2 1 1が、 そのス クリブトプログラムを実行することによって、 あるいは、 ユーザがリ モコンを操作することによって、 プレイヤ制御モジュール 2 1 2に与 えられる。
即ち、 スクリプト制御モジュール 2 1 1は、 ストリーム切り替えの 指示が記述されているスクリブトプログラムを実行すると、 ストリー ム切り替えを要求するメッセージを、 プレイヤ制御モジュール 2 1 2 に供給する。 また、 入力イン夕一フェース 1 1 5は、 ユーザがリモコ ンを操作することによって、 リモコンから、 ストリーム切り替えを指 示する信号を受信すると、 ストリーム切り替えを要求するメッセージ を、 プレイヤ制御モジュール 2 1 2に供給する。
例えば、 いま、 プレイヤ制御モジュ^-ル 2 1 2に対して、 字幕スト リームの切り替えを要求するメッセージである字幕ストリーム切り替 えのメッセージが供給されたとすると、 プレイヤ制御モジュール 2 1 2は、 ステツプ S 1 9 1において、 第 3 0図のステツプ S 1 2 5で行 われた再生対象のエレメン夕リストリ一ムの決定のときに認識した字 幕ストリームの本数をチェックする。
プレイヤ制御モジュール 2 1 2は、 字幕ストリームの本数をチエツ クした結果、 その本数が 1本以下である場合、 字幕ストリーム切り替 えのメッセージを無視し、 従って、 以降のステップ S 1 9 2乃至 S 1 94の処理は行われない。
一方、 字幕ストリームの本数が 2本以上である場合、 ステップ S 1 9 2乃至 S 1 94に順次進み、 再生する字幕ストリームが、 現在再生 されている字幕ストリームから、 他の字幕ストリームに切り替えられ る。
即ち、 ステップ S 1 9 2において、 プレイヤ制御モジュール 2 1 2 は、 現在再生中の字幕ストリームを、 クリップ情報ファイル上で特定 する。 具体的には、 例えば、 いま、 第 2 5図で説明した 1番目の Play List#0を構成する 2番目の Playltem#lによって、 クリップストリーム ファイル" 00002.PS"に多重化された、 stream— idが OxBDで、 private— s tream— idが 0x80の字幕ストリームが再生されていることとすると、 ス テツプ S 1 9 2では、 現在再生中の字幕ストリームが、 クリップスト リームファイル" 00002.PS"に多重化された 2本の字幕ストリームのう ちの、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00002. C LP"上で 3本目の字幕ストリームである stream であることが特定さ れる。
そして、 ステップ S 1 9 3に進み、 プレイヤ制御モジュール 2 1 2 は、 ステップ S 1 9 2で特定した字幕ストリームの、 クリップ情報フ アイル上で次の字幕ストリームを、 次に再生する字幕ストリームとし て認識 （特定） する。 第 2 6図 Aおよび第 2 6図 Bでは、 クリップ情 報ファイル" 00002. CLP"上で、 3本目の字幕ストリーム stream#2の次 の字幕ストリームは、 4本目の字幕ス卜リーム st ream#3であるから、 ステップ S I 9 3では、 この 4本目の字幕ストリーム stream#3が、 次 に再生する字幕ストリ一ムとして認識される。
なお、 現在再生中の字幕ストリームが、 クリップストリームフアイ ル" 00002.PS"に多重化された 2本の字幕ストリームのうちの、 第 2 6 図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00002. CLP"上で 4本 目の字幕ストリームである stream#3であることが特定された場合は、 例えば、 3本目の字幕ストリーム stream#2が、 次に再生する字幕スト リームとして認識される。
その後、 ステップ S 1 94に進み、 プレイヤ制御モジュール 2 1 2 は、 ステップ S 1 93で認識した次に再生する字幕ストリームの stre am_idと private— stream_idを、 バッファ制御モジュール 2 1 5 (第 3 図） の字幕読み出し機能部 2 3 5に対して与え、 その stream一 idと pri vate_stream_idを、 次回からの、 字幕アクセスユニットのバッファ 2 1 5 Aからの読み出しから使用するように指示する。
バッファ制御モジュール 2 1 5 (第 3図） の字幕読み出し機能部 2 3 5では、 ステップ S 1 94でプレイヤ制御モジュール 2 1 2から与 えられる stream_idと private— stream一 idを、 stream_idレジス夕 2 6 3と private— st ream_idレジスタ 264に、 それぞれ新たにセットし 、 次回以降のバッファ 2 1.5 Aからの読み出しは、 その stream_idレ ジス夕 2 63と private_stream_idレジス夕 2 64にそれぞれ新たに セットされた 3 6&111—1(1と0]：^&16__3 6&111_1(1にょって特定される字幕 アクセスュニットを対象として行われる。
以上のようにして、 再生する字幕ストリームが、 現在再生されてい る字幕ストリームから、 他の字幕ストリームに切り替えられる。
[バッファ制御モジュール 2 1 5の処理]
次に、 第 34図乃至第 38図を参照して、 バッファ制御モジュール 2 1 5 (第 3図） の処理、 即ち、 バッファ 2 1 5 Aへのデータの書き 込みと、 バッファ 2 1 5 Aからのデータの読み出しについて説明する バッファ制御モジュール 2 1 5は、 第 3図で説明したように、 ノ ッ ファ 2 1 5 Aに対するデータの読み書きを行うための 5つのボインタ を有している。
即ち、 第 34図および第 35図に示すように、 バッファ制御モジュ ール 2 1 5は、 データ先頭ポインタ記憶部 2 3 1に記憶されるデータ. 先頭ボイン夕、 データ書き込みボイン夕記憶部 2 32に記憶されるデ 一夕書き込みポインタ、 ビデオ読み出しポインタ記憶部 241に記憶 されるビデオ読み出しボイン夕、 オーディォ読み出しボイン夕記億部 2 5 1に記憶されるオーディオ読み出しポインタ、 および字幕読み出 しボイン夕記憶部 262に記憶される字幕読み出しボイン夕を有して いる。
なお、 第 34図および第 35図では、 第 3図におけるビデオ読み出 し機能部 23 3の stream_idレジスタ 242および au_information() レジスタ 243、 ォ一ディォ読み出し機能部 2 34の stream—idレジ ス夕 2 52および private一 stream— idレジス夕 2 53、 並びに字幕読 み出し機能部 2 3 5の字幕読み出し機能フラグ記憶部 26 1、 stream —idレジスタ 26 3、 および private_stream_idレジスタ 264の図示 は、 省略してある。
データ先頭ボインタ記憶部 23 1に記憶されたデータ先頭ボインタ は、 バッファ 2 1 5 Aに残る最も古いデータ （読み出す必要があるデ 一夕であって、 まだ読み出されていないデータのうちの最も古いデー 夕） の位置を表す。 デ一夕書き込みポインタ記憶部 2 32に記憶され たデータ書き込みポィンタは、 バッファ 2 1 5 Aへのデータの書き込 みの位置を示し、 この位置は、 バッファ 2 1 5 Aで最も新しいデータ が書き込まれる位置である。
ビデオ読み出しボインタ記憶部 2 4 1に記憶されたビデオ読み出し ポインタは、 バッファ 2 1 5 Aから読み出すビデオストリームの位置 を表す。 また、 オーディオ読み出しポインタ記憶部 2 5 1に記憶され たオーディオ読み出しポインタは、 バッファ 2 1 5 Aから読み出すォ 一ディォストリ一ムの位置を表し、 字幕読み出しポインタ記憶部 2 6 2に記憶された字幕読み出しポインタは、 バッファ 2 1 5 Aから読み 出す字幕ストリームの位置を表す。
なお、 第 3図で説明したように、 データ先頭ポインタ、 データ書き 込みポインタ、 ビデオ読み出しポインタ、 オーディオ読み出しポイン 夕、 および字幕読み出しポインタは、 いずれも、 バッファ 2 1 5 Aを 右回りに移動する。
さらに、 本実施の形態では、 データ先頭ポインタは、 第 3 5図に示 すように、 ビデオ読み出しポインタ、 オーディオ読み出しポインタ、 または字幕読み出しボイン夕のうちの、 最も *ぃデ一夕の位置を指し ているものと同一の位置を指すように、 常時更新されるものとする。 ここで、 第 3 5図では、 ビデオ読み出しポインタ、 オーディオ読み出 しポインタ、 または字幕読み出しポインタのうちの、 オーディオ読み 出しポインタが、 最も古いデータの位置を指しており、 データ先頭ポ インタは、 そのオーディオ読み出しポインタと一致している。
以上のようなデータ先頭ポインタ、 デ一夕書き込みポインタ、 ビデ ォ読み出しポインタ、 オーディオ読み出しポインタ、 および字幕読み 出しポインタを有するバッファ制御モジュール 2 1 5では、 データ書 き込みポインタは、 ディスク 1 0 1から新たなデータが読み出され、 バッファ 2 1 5 Aに書き込まれると、 その書き込まれた新たなデ一夕 の直後の位置を指すように、 右回りに更新される。
さらに、 ビデオ読み出しポインタ、 オーディオ読み出しポインタ、 または字幕読み出しポインタは、 バッファ 2 1 5 Aから、 ビデオスト リーム、 オーディオストリーム、 または字幕ストリームが読み出され ると、 その読み出し量に応じた分だけ、 それぞれ、 右回りに更新され る。 ここで読み出し量に応じた分とは、 実際に読み出したビデオ、 ォ 一ディォ、 字幕のデータに対応する部分と、 読み出したデータの間に 含まれており、 読み出しの際には読み飛ばしを行った、 他のストリー ムのデ一夕の部分をあわせたものとなる。
また、 データ先頭ポインタは、 ビデオ読み出しポインタ、 オーディ ォ読み出しポインタ、 または字幕読み出しボイン夕が更新されると、 そのビデオ読み出しポインタ、 オーディオ読み出しポインタ、 または 字幕読み出しボインタのうちの、 最も古いデータの位置を指している ものと同一の位置を指すように更新される。
ここで、 バッファ制御モジュール 2 1 5は、 バッファ 2 1 5 Aへの デ一ダの書き込みについては、 データ書き込みボインタがデータ先頭 ポィン夕を追い越さないように、 バッファ 2 1 5 Aへのデ一夕の書き 込みを制御する。
即ち、 データ書き込みボイン夕によるデータ先頭ボイン夕の追い越 しが発生しない限り、 バッファ制御モジュール 2 1 5では、 ディスク 1 0 1から読み出されたデータが、 データ書き込みポインタが指すバ ッファ 2 1 5 Aの位置に書き込まれ、 データ書き込みポインタが更新 されていく。 一方、 データ書き込みポインタによるデータ先頭ポイン 夕の追い越しが発生しそうになると、 バッファ制御モジュール 2 1 5 では、 コンテンツデータ供給モジュール 2 1 3に対して、 ディスク 1 0 1からのデータの読み出しの停止 （中断） が要求され、 さらに、 バ ッファ 2 1 5 Aへのデータの書き込みが停止される。 これにより、 バ ッファ 2 1 5 Aのオーバ一フローを防止することができる。
以上のように、 ディスク 1 0 1から読み出されたデ一夕の、 バッフ ァ 2 1 5 Aへの書き込みは、 データ先頭ポインタとデータ書き込みポ ィン夕との 2つのボイン夕の位置関係だけで制御される。
一方、 ノ ッファ制御モジュール 2 1 5は、 ゾ ッファ 2 1 5 Aからの データの読み出しについては、 ビデオ読み出しポインタ、 オーディオ 読み出しポインタ、 および字幕読み出しポインタ、 ひいては、 データ 先頭ポインタが、 データ書き込みポインタを追い越さないように、 バ ッファ 2 1 5 Aからのデータの読み出しを制御する。
即ち、 ビデオ読み出しポインタ、 オーディオ読み出しポインタ、 ま たは字幕読み出しポインタによるデータ書き込みボイン夕の追い越し が発生しない限り、 バッファ制御モジュール 2 1 5では、 ビデオデコ ーダ制御モジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 または字幕デコーダ制御モジュール 2 1 8からの要求に応じて、 ビデオ読み出しポインタ、 オーディオ読み出しポインタ、 または字幕 読み出しポインタが指すバッファ 2 1 5 Aの位置からデータが読み出 され、 ビデオ読み出しポインタ、 オーディオ読み出しポインタ、 また は字幕読み出しポインタが更新されるとともに、 必要に応じて、 デ一 夕先頭ポインタが更新される。 一方、 ビデオ読み出しポインタ、 ォー ディォ読み出しボインタ、 または字幕読み出しボイン夕によるデ一夕 書き込みボイン夕の追い越しが発生しそうになると、 バッファ制御モ ジュール 2 1 5では、 ビデオデコーダ制御モジュール 2 1 6、 オーデ ィォデコーダ制御モジュール 2 1 7、 または字幕デコーダ制御モジュ ール 2 1 8からの要求が、 例えば凍結され、 十分なデータが用意され るまで待たされる。 これにより、 バッファ 2 1 5 Aのアンダーフロ一 を防止することができる。
以上から、 バッファ 2 1 5 Aには、 データ先頭ポインタが指す位置 から、 右回りに、 データ書き込みポインタが指す位置までの範囲 （第 3 4図および第 3 5図において影を付してある部分） に、 ビデオデコ —ダ制御モジュール 2 1 6、 オーディオデコーダ制御モジュール 2 1 7、 および字幕デコーダ制御モジュール 2 1 8に供給すべきデータが 記憶されており、 さらに、 その範囲内に、 ビデオ読み出しポインタ、 オーディォ読み出しボイン夕、 および字幕読み出しボインタは存在す る。
なお、 上述の場合には、 データ先頭ポインタは、 ビデオ読み出しポ インタ、 オーディオ読み出しポインタ、 または字幕読み出しポインタ が指している位置のうちの、 最も古いデータの位置を指すように更新 することとしたが、 その他、 デ一夕先頭ポインタの更新は、 例えば、 その最も古いデータの位置から、 所定の時間 （例えば、 1秒） 分だけ 過去のデータの位置を指すように行うことが可能である。
即ち'、 一般には、 ビデオ読み出しポインタ、 ォ一ディォ読み出しポ インタ、 または字幕読み出しポインタのうちの、 ビデオ読み出しボイ ン夕ゃオーディォ読み出しボイン夕が、 最も古いデータの位置を指す ことが多いと予想される。 .
従って、 データ先頭ポインタを、 ビデオ読み出しポインタまたはォ 一ディォ読み出しポインタが指す最も古いデータの位置から、 例えば 、 1秒分だけ過去のデータの位置を指すように更新した場合、 第 3 4 図に示すように、 ビデオ読み出しボイン夕またはオーディォ読み出し ボイン夕が指す最も古いデータの位置から過去 1秒分のデータを、 バ ッファ 2 1 5 Aに残しておくことができる。 ここで、 第 3 4図では、 オーディォ読み出しボイン夕が、 最も古いデータの位置を指しており 、 データ先頭ポインタは、 その位置から 1秒分だけ過去のデータの位 置を指している。
以上のように、 1秒分だけ過去のデータの位置を指すように、 デー タ先頭ボイン夕を更新することにより、 ディスク装置の応答性を向上 させることができる。
即ち、 第 3 5図に示したように、 オーディオ読み出しポインタが指 している最も古いデータの位置を指すように、 データ先頭ボイン夕を 更新する場合には、 例えば、 リバース方向への特殊再生が指示された ときに、 バッファ 2 1 5 Aからの読み出しが終了したデータを、 ディ スク 1 0 1から再度読み出す必要があるため、 特殊再生が指示されて から、 その特殊再生が可能となるまでに、 ある程度の時間がかかる。
これに対して、 第 3 4図に示したように、 オーディオ読み出しボイ ン夕が指している最も古いデータの位置から L秒分だけ過去のデー夕 の位置を指すように、 データ先頭ポインタを更新する場合には、 リバ ース方向への特殊再生が指示されたときに、 その特殊再生を開始する のに必要なデータが、 バッファ 2 1 5 Aに記憶されている 1秒分だけ 過去のデータであれば、 上述したようなディスク 1 0 1からのデータ の再読み出しを行わずに、 即座に、 特殊再生を開始することが可能と なる。
なお、 オーディオ読み出しポインタが指している最も古いデ一夕の 位置から 1秒分だけ過去のデ一夕の位置を指すように、 データ先頭ポ イン夕を更新する場合であっても、 特殊再生を開始するのに必要なデ 一夕が、 バッファ 2 1 5 Aに記憶されていないことがあり得る。 この 場合には、 特殊再生を開始するのに必要なデータが、 デ スク 1 0 1 から再度読み出される。
次に、 バッファ 2 1 5 Aからのビデオストリ一ム、 オーディオスト リーム、 字幕ストリームそれぞれの読み出しの詳細について説明する 第 3 0図のステップ S 1 2 7で説明したように、 クリップストリー ムファイルの再生が開始されるときに、 バッファ制御モジュール 2 1 5においては、 データ先頭ポインタ、 データ書き込みポインタ、 ビデ ォ読み出しポインタ、 オーディオ読み出しポインタ、 字幕読み出しポ インタが、 すべて、 バッファ 2 1 5 A上の同じ位置を指すように初期 化される。
そして、 ディスク 1 0 1からクリップストリームファイルに格納さ れたプログラムストリーム（MPEG2- Sys t em Program S t ream)が読み出 され、 バッファ制御モジュール 2 1 5に供給されると、 バッファ制御 モジュール 2 1 5では、 そのプログラムストリームが、 バッファ 2 1 5 Aのデータ書き込みボイン夕が指す位置に記憶されるとともに、 デ 一夕書き込みポインタが、 右回りに更新されていく。
さらに、 バッファ制御モジュール 2 1 5 (第 3図） では、 ビデオ読 み出し機能部 2 3 3が、 バッファ 2 1 5 Aに記憶されたプログラムス トリ一ムの構文解析を行い、 ビデオデコーダ制御モジュール 2 1 6か らの要求に応じて、 パッファ 2 1 5 Aに記憶されたプログラムストリ —ムから、 ビデオストリーム （ビデオアクセスユニット） を抽出 （分 離） して読み出し、 ビデオデコーダ制御モジュール 2 1 6に供給する 同様に、 オーディォ読み出し機能部.2 3 4も、 バッファ 2 1 5 Aに 記憶されたプログラムストリームの構文解析を行い、 オーディォデコ ーダ制御モジュール 2 1 7からの要求に応じて、 バッファ 2 1 5 Aに 記憶されたプログラムストリームから、 オーディオストリーム （ォ一 ディォアクセスユニット） を抽出して読み出し、 オーディオデコーダ 制御モジュール 2 1 7に供給する。 字幕読み出し機能部 2 3 5も、 バ ッファ 2 1 5 Aに記憶されたプログラムストリームの構文解析を行い 、 字幕デコーダ制御モジュール 2 1 8からの要求に応じて、 バッファ 2 1 5 Aに記憶されたプログラムストリームから、 字幕ストリーム （ 字幕アクセスユニット） を抽出して読み出し、 字幕デコーダ制御モジ ユール 2 1 8に供給する。
「ビデオストリームの読み出し」
次に、 第 3 6図のフローチャートを参照して、 ビデオ読み出し機能 部 2 3 3 (第 3図） による、 ノ ッファ 2 1 5 Aからのビデオストリ一 ムの読み出し処理の詳細について説明する。
ビデオ読み出し機能部 2 3 3は、 まず最初に、 ステップ S 2 1 1に おいて、 バッファ 2 1 5 Aに記憶されたプログラムストリーム中の pr ivate— stream_2の PES— packet ()を探索して見つけ出す。 すなわち、 pr ivate— stream_2の PES— packet 0の stream— idは、 第 2 0図で説明した ように、 10111111B(=0xBF)であり、 ビデオ読み出し機能部 2 3 3は、 streani_idが 10111111Bとなっている PES_packet 0を探索して見つけ出 す。
ここで、 例えば、 いま、 上述したように、 クリップストリームファ ィル" 00001.PS"に格納されたプログラムストリームに多重化されたェ レメン夕リストリームが、 再生対象のエレメン夕リストリームである とすると、 そのプログラムストリ一ムをディスク 1 0 1から読み出し て、 バッファ 2 1 5 Aに記憶させるときに、 第 3 0図のステップ S 1 2 2において、 クリップストリームファイル" 00001.PS"の EP— map 0 ( 第 2 7図） に記述されたデコード開始可能点の情報から、 305セクタ が再生開始位置として決定され、 さらに、 第 3 0図のステップ S 1 2 8において、 再生開始位置である 305セクタが指定され、 オペレーテ W ィングシステム 2 0 1に対して、 クリップストリームファイル" 00001 • PS"に格納されたプログラムストリームの読み出しが要求される。 また、 ビデオストリームについては、 EPjnapOに記述されたデコー ド開始可能点の情報は、 実際のデコード開始可能点の直前に配置され た private— stream— 2の PES— packet 0の位置を表す。
従って、 クリップストリームファイル" 00001.PS"に格納されたプロ グラムストリームがディスク 1 0 1から読み出され、 バッファ 2 1 5 Aに記憶された直後においては、 データ先頭ボイン夕ゃビデオ読み出 しポインタが指すバッファ 2 1 5 Aの位置には、 private_stream一 2の PES_packet ()が記憶されている。
ビデオ読み出し機能部 2 33は、 ステップ S 2 1 1において、 priv ate_stream_2の PES_packet 0が見つかると、 ステップ S 2 1 2に進み 、 その private— stream— 2の PES— packet ()の PES— packeし data— byteであ る private一 streamlPES-PayloadO (第 23図） に記述されている vid eo— stream一 idを抜き出し、 その video一 stream一 idが、 第 30図のステ ップ S 1 27で streamjdレジスタ 242 (第 3図） に記憶された、 再生対象のビデオストリームの st ream一 idと一致するかどうかを判定 する。
ステップ S 2 1 2において、 private_stream2— PES_payload()に記 述されている video_stream_idが、 s tream_idレジス夕 242に記憶さ れた stream— idと一致しないと判定された場合、 即ち、 直前のステツ プ S 2 1 1で見つけ出された private_stream—2の PES— packet 0が、 再 生対象のビデオストリームのデコード開始点に配置されたものでない 場合、 ステップ S 2 1 1に戻り、 バッファ 2 1 5 Aに記憶されたプロ グラムストリーム中の他の private_stream_2の PES_packet ()の探索が 行われ、 以下、 同様の処理が繰り返される。 一方、 ステップ S 2 1 2において、 private— stream2_PES—payload( )に記述されている video— stream_idが、 stream— idレジスタ 242に 記憶された stream_idと一致すると判定された場合、 即ち、 直前のス テツプ S 2 1 1で見つけ出された private_stream_2の PES_packet 0が 、 再生対象のビデオストリームのデコード開始点に配置されたもので ある場合、 ステップ S 2 1 3に進み、 ビデオ読み出し機能部 2 33は 、 その private— stream— 2の PES— packet 0 COpr ivat e_s t ream2_PES_pay 1 oadOに記述されている aujnformationOを、 バッファ 2 1 5 Aから 読み出し、 au_information()レジスタ 243 (第 3図） に記憶させ、 ステップ S 2 14に進む。
ステップ S 2 14では、 ビデオ読み出し機能部 23 3は、 直前のス テツプ S 21 1で見つけ出した private_stream__2の PES_packet 0 (vi deo_stream_id (第 23図） が、 stream_idレジス夕 242 (第 3図） に記憶された stream— idと一致する 01" 16_5 6&111—2の1^3_{)& 1^( 0 ) のサイズだけ、 ビデオ読み出しポインタ記憶部 23 1に記憶された ビデオ読み出しボインタを更新する。
即ち、 クリップストリームファイルでは、 private_stream_2の PES一 packet 0の直後に、 その video__stream_idと一致する stream_idのビデ ォストリーム （PES_packet.O) が配置されており、 従って、 ステップ S 2 14では、 ビデオ読み出しポインタは、 ビデオストリームの実際 のデコード開始可能点の位置を指すように更新される。
その後、 ステップ S 2 14から S 2 1 5に進み、 ビデオ読み出し機 能部 2 3 3は、 ビデデコーダ制御モジュール 2 1 6から、 データの要 求があつたかどうかを判定し、 ないと判定した場合、 ステップ S 2 1 5に戻り、 同様の処理を繰り返す。
また、 ステップ S 2 1 5において、 ビデオデコーダ制御モジュール 2 1 6から、 データの要求があつたと判定された場合、 ステップ S 2 1 6に進み、 ビデオ読み出し機能部 2 3 3は、 ビデオ読み出しポイン 夕が指しているバッファ 2 1 5 Aの位置からのプログラムストリーム の構文解析を行いつつ、 au一 informationOレジスタ 24 3に記憶され た au_information()の AUJengthに記述されたバイト数のデ一夕、 つ まり 1つのビデオアクセスュニットを、 バッファ 2 1 5 Aから読み出 し、 ビデオデコーダ制御モジュール 2 1 6に供給するとともに、 ビデ ォ読み出しボインタを、 バッファ 2 1 5 Aから読み出した 1つのビデ. オアグセスュニットのサイズ分だけ更新する。
即ち、 au一 informationOには、 第 24図で説明したように、 それを 含む private— stream— 2の PES— packet 0力 ら、 次の private— stream— 2の PES_packet()までの間に含まれるビデオアクセスュニット （ピクチャ ) の数を表す numbeし 0し access_unitが記述されている。
さらに、 au_information()には、 第 24図で説明したように、 その number_oし access_unitの数だけのビデオアクセスュニットそれぞれ に関する情報としての pic_strucし copy, au_reし flag、 および AU_len gthが記述されている。
au_inforiat ionO ίこ number— of— access—uni tの数たナ ci述されてレ る AUJengthそれぞれは、 第 24図で説明したように、 それを含む pri vate— stream— 2の PES— packet 0力、ら、 次の private— stream— 2の PES— pac ket 0までの間に含まれる、 number_oし access_unitの数のビデオァク セスュニットそれぞれのサイズを表すから、 ビデオ読み出し機能部 2 3 3は、 その AUJengthを用いることで、 ビデオストリームの構文解 析を行うことなく、 アクセスユニットの切り出しを行うことが出来る 。
即ち、 従来、 MPEG2- Videoや MPEG4- AVCのアクセスユニットを切り出 す場合には、 ビデオストリームの構文を知った上で、 ビデオストリー ムの構文解析を行う必要があつたが、 ディスク 1 0 1に記録されたク リップストリームファイルに格納されたプログラムストリームは、 ビ デォアクセスュニット単位のビデオストリームにおける 1以上の実際 のデコード開始可能点それぞれの直前に、 ビデオアクセスユニットの サイズを表す AU_lengthが記述された private— stream_2の PES一 packet ( )を含んでいるので、 ビデオ読み出し機能 2 3 3は、 その private一 str earn一 2の PES一 packetOに記述された AU_lengthに基づき、 ビデオストリ ームの構文解析を行うことなく、 バッファ 2 1 5Aから、 ビデオァク セスユニット （単位のビデオストリーム） を読み出し、 ビデオデコー ダ制御モジュール 2 1 6に供給することができる。
なお、 ビデオ読み出し機能部 2 33は、 ステップ S 2 1 6において 、 ビデオアクセスユニットを、 ビデオデコーダ制御モジュール 2 1 6 に供給するときに、 そのビデオアクセスュニットに関する情報として au_information() ίこ記述されて る pic— struct_copy, au_ref_f lag, および AlJ_lengthと、 ビデオアクセスュニット単位に付加されている タイムスタンプ （PTS， DTS) も、 ビデオデコーダ制御モジュール 2 1 6に供給する。
ステップ S 2 1 6において、 バッファ 2 1 5 Aから 1つのビデオア クセスュニットが読み出され、 ビデオデコーダ制御モジュール 2 1 6 に供給された後は、 ステップ S 2 1 7に進み、 ビデオ読み出し機能部 2 3 3は、 au_information()レジス夕 243に記憶された au__inf orma tionO (第 24図） の number_oし access— unitが表す数だけのァクセ スュニットを処理したかどうかを判定する。
ステップ S 2 1 7において、 number_oし access_unitが表す数だけ のアクセスユニットを、 まだ処理していないと判定された場合、 即ち 、 number一 of_access_unitが表す数だけのアクセスユニットを、 まだ 、 バッファ 2 1 5 Aから読み出してビデオデコーダ制御モジュール 2 1 6に供給していない場合、 ステップ S 2 1 5に戻り、 以下、 同様の 処理が繰り返される。
また、 ステップ S 2 1 7において、 number_oし access_unitが表す 数だけのアクセスユニットを処理したと判定された場合、 即ち、 numb er_oし access一 unitが表す数だけのアクセスュニットを、 バッファ 2 1 5 Aから読み出してビデオデコーダ制御モジュール 2 1 6に供給し た場合、 ステップ S 2 1 1に戻り、 次の private_stream_2の PES_pack et()の探索が行われ、 以下、 同様の処理が繰り返される。
「オーディオストリ一ムの読み出し」
次に、 第 37図のフローチャートを参照して、 オーディオ読み出し 機能部 234 (第 3図） による、 バッファ 2 1 5 Aからのオーディオ ストリームの読み出し処理の詳細について説明する。
オーディオ読み出し機能部 234は、 まず最初に、 ステップ S 2 3 0において、 第 3 0図のステップ S 1 27で stream_idレジスタ 2 5 2 (第 3図） に記憶された、 再生対象のオーディオストリームの stre am一 idが、 private— stream— 1の PES— packet 0を表しているかどうかを 判定する。
ステップ S 23 0において、 stream_idレジス夕 2 52に記憶され た st ream一 idが、 pr i vat e_stream_lの PES— packet 0を表していない判 定された場合、 即ち、 stream_idレジス夕 2 5 2に記憶された stream一 idが、 第 2 0図で説明したように、 MPEG規格にしたがって符号化され たォ一ディォストリ一ムに割り当てられる llOxxxxxBである場合、 ス テツプ S 2 3 1に進み、 オーディオ読み出し機能部 2 34は、 バッフ ァ 2 1 5 Aに記憶されたプログラムストリームから、 MPEG Audioで定 められたオーディオフレーム先頭を表す同期コ一ドを探す。 同期コ'一 ドの位置がオーディオフレーム先頭なので、 ォ一ディォ読み出し機能 部 2 3 4は、 オーディオ読み出しポインタを、 オーディオフレーム先 頭の位置を示すように更新し、 ステップ S 2 3 1から S 2 3 2に進む 。 ステップ S 2 3 2では、 オーディオ読み出し機能部 2 3 4は、 バッ ファ 2 1 5 Aに記憶されたプログラムストリーム中の、 s t ream_i dレ ジス夕 2 5 2に記憶された s t ream_i dに一致する PES_packe t 0を、 ォ 一ディォ読み出しボイン夕が示す位置から探索して見つけ出し、 ステ ップ S 2 3 3に進む。
ステップ S 2 3 3では、 オーディオ読み出し機能部 2 3 4は、 ォ一 ディォ読み出しポインタ記憶部 2 5 1に記憶されたオーディオ読み出 しポインタを、 直前のステップ S 2 3 2で見つけ出した PES— packe t () の PES— packe t— dat a—byte (第 1 6図 Aおよび第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 B ) の先頭を指すように更新し、 ステップ S 2 3 7 に進む。
ステップ S 2 3 7では、 オーディオ読み出し機能部 2 3 4は、 ォ一 ディォデコーダ制御モジュール 2 1 7から、 データの要求があつたか どうかを判定し、 ないと判定した場合、 ステップ S 2 3 7に戻り、 同 様の処理を繰り返す。
また、 ステップ S 2 3 7において、 オーディオデコーダ制御モジュ ール 2 1 7から、 データの要求があつたと判定された場合、 ステップ S 2 3 8に進み、 オーディオ読み出し.機能部 2 3 4は、 オーディオ読 み出しボイン夕が指しているバッファ 2 1 5 Aの位置からのプロダラ ムストリームの構文解析を行いつつ、 既知の固定長の 1つのオーディ ォアクセスュニットを、 バッファ 2 1 5 Aから読み出し、 そのオーデ ィォアクセスユニットに付加されているタイムスタンプ （PTS， DTS) とともに、 オーディオデコーダ制御モジュール 2 1 7に供給する。 ' そして、 オーディオ読み出し機能部 2 34は、 バッファ 2 1 5 Aか ら読み出した 1つのオーディオアクセスュニットのサイズ分だけ、 ォ 一ディォ読み出しポインタを更新して、 ステップ S 2 3 7に戻り、 以 下、 同様の処理が繰り返される。
一方、 ステップ S 2 3 0において、 stream_idレジスタ 2 5 2に記 憶された stream— idが、 private_stream_lの PES_packet 0を表してい ると判定された場合、 即ち、 stream_idレジスタ 2 5 2に記憶された s tream_idが、 10111101B(=0xBD)であり、 第 2 0図で説明したように、 private— stream_lの PES一 packet ()を表している場合、 ステップ S 2 3 4に進み、 オーディオ読み出し機能部 2 34は、 バッファ 2 1 5 Aに 記憶されたプログラムストリーム中の private— stream— 1の PES— packet 0を探索して見つけ出す。 すなわち、 オーディオ読み出し機能部 2 3 4は、 stream— idが 101111018となってぃる？65_ &0¾^0を探索して見 つけ出す。
オーディオ読み出し機能部 2 34は、 ステップ S 2 34において、 private_stream_lの PES_packet 0が見つかると、 ステップ S 2 3 5に 進み、 その private_stream— 1の PES— packet 0の PES—packet—data_byte である private— streaml_PES—payload() (第 2 1図） に記述されてい る private—stream_idを抜き出し、 その private—stream一 idが、 第 3 0 図のステップ S 1 2 7で private— stream_idレジス夕 2 5 3 (第 3図 ) に記憶された、 再生対象のオーディオストリームの private一 stream —idと一致するかどうかを判定する。
ステップ S 2 3 5において、 private_streamし PES— payloadOに記 述 sれている private— stream— idが、 private— stream— idレジス夕 2 5 3に記憶された private stream— idと一致しないと判定された場合、 即ち、 直前のステツプ S 2 34で見つけ出された private_stream— 1め PES— packet ()が、 再生対象のオーディオストリームではない場合、 ス テツプ S 234に戻り、 ノ ッファ 2 1 5 Aに記憶されたプログラムス トリーム中の他の private_stream_lの PES_packet ()の探索が行われ、 以下、 同様の処理が繰り返される。
一方、 ステップ S 23 5において、 rivate_streaml_PES_payload( )【こ目 ci述されてレ る private— stream— idカ、 private— stream一 idレジス タ 25 3に記憶された private— stream— idと一致すると判定された場 合、 即ち、 直前のステップ S 234で見つけ出された private一 stream _1の PES— packet 0が、 再生対象のオーディオストリームである場合、 ステップ S 2 3 6に進み、 オーディオ読み出し機能部 2 34は、 その private— stream一 1の PES— packet 0の private—s treaml一 PES— payload 0
(第 2 1図） に記述されている AUJocatorを、 バッファ 2 1 5Aから 読み出し、 その AUJocatorの直後の位置と、 その AUJocatorが表す値 とを加算することで、 オーディオアクセスユニットの先頭位置を求め る。 '
即ち、 AU—locatorは、 第 2 1図で説明したように、 その AU—locator の直後の位置を基準として、 private— st reaml_PES— pay load 0の priva te_payload()に格納されるオーディォアクセスュニット （あるいは字 幕アクセスユニット） の先頭位置を表すから、 AU— locatorの直後の位 置に、 その AUJocatorが表す値を加算することにより、 オーディオア クセスユニットの （絶対的な） 先頭位置を求めることができる。
オーディオ読み出し機能部 234は、 さらに、 ステップ S 2 36に おいて、 以上のようにして求めたオーディォアクセスュニッ卜の先頭 位置を指すように、 オーディオ読み出しポインタ記憶部 2 5 1に記憶 されたオーディオ読み出しポインタを更新し、 ステップ S 2 37に進 む。
ステップ S 2 3 7では、 オーディオ読み出し機能部 2 3 4は、 ォー ディォデコーダ制御モジュール 2 1 7から、 データの要求があつたか どうかを判定し、 ないと判定した場合、 ステップ S 2 3 7に戻り、 同 様の処理を繰り返す。
また、 ステップ S 2 3 7において、 オーディオデコーダ制御モジュ —ル 2 1 7から、 デ一夕の要求があつたかと判定された場合、 ステツ プ S 2 3 8に進み、 オーディオ読み出し機能部 2 3 4は、 オーディオ 読み出しボイン夕が指しているバッファ 2 1 5 Aの位置からのプログ ラムストリームの構文解析を行いつつ、 既知の固定長の 1つのオーデ ィォアクセスュニットを、 バッファ 2 1 5 Aから読み出し、 そのォー ディォアクセスュニッ卜に付加されているタイムスタンプとともに、 オーディオデコーダ制御モジュール 2 1 7に供給する。
そして、 オーディオ読み出し機能部 2 3 4は、 ノ ッファ 2 1 5 Aか ら読み出した 1つのオーディオアクセスユニットのサイズ分だけ、 ォ —ディォ読み出しポインタを更新して、 ステップ S 2 3 7に戻り、 以 下、 同様の処理が繰り返される。
「字幕ストリームの読み出し」
次に、 第 3 8図のフローチャートを参照して、 字幕読み出し機能部 2 3 5 (第 3図） による、 ノ ッファ 2 1 5 Aからの字幕ストリームの 読み出し処理の詳細について説明する。
字幕読み出し機能部 2 3 5は、 まず最初に、 ステップ S 2 5 1にお いて、 第 3 0図のステップ S 1 2 7で字幕読み出し機能フラグ記憶部 2 6 1に記憶された字幕読み出し機能フラグを判定する。 ステップ S 2 5 1において、 字幕読み出し機能フラグが 0であると判定された場 合、 即ち、 例えば、 再生対象のエレメン夕リストリームが多重化され ているク Uップストリームファイルに字幕ストリームが含まれておら ず、 第 3 0図のステップ S 1 2 7で字幕読み出し機能フラグ記憶部 2 6 1に、 0がセットされた場合、 字幕読み出し機能部 2 3 5は特に処 理を行わない。
一方、 ステップ S 2 5 1において、 字幕読み出し機能フラグが 1で あると判定された場合、 即ち、 例えば、 再生対象のエレメン夕リスト リームが多重化されているクリップストリームファイルに字幕ストリ ームが含まれており、 第 3 0図のステップ S 1 2 7で字幕読み出し機 能フラグ記憶部 2 6 1に、 1がセットされた場合、 ステップ S 2 5 2 に進み、 字幕読み出し機能部 2 3 5は、 stream_idレジスタ 2 6 3 ( 第 3図） に記憶された、 再生対象の字幕ストリームの stream—idに一 致する PES_packet()を、 バッファ 2 1 5 Aに記憶されたプログラムス トリームから探索する。
ここで、 第 3 0図のステップ S 1 2 7で説明したように、 stream_i dレジス夕 2 6 3 (第 3図） には、 再生対象の字幕ストリームの strea m_idが記憶されるが、 字幕ストリームの stream一 idは、 第 2 0図で説 明したように、 private— stream— 1の PES— packet 0を表す 10111101B (=0 xBD)である。
従って、 ステップ S 2 52では、 バッファ 2 1 5 Aに記憶されたプ ログラムストリーム中の private_stream一 1の PES一 packetOが探索され ることになる。
ステップ S 2 5 2において、 private.— stream_lの PES_packet()の探 索が行われ、 private— stream— 1の PES— packe )が見つかると、 ステツ プ S 2 5 3に進み、 字幕読み出し機能部 2 3 5は、 その private— stre am— 1の PES— packet ()の PES— packet— data— byteである private— streaml— PES _pay load 0 (第 2 1図） に記述されている private— stream_idを抜 き出し、 その private_stream__idが、 第 3 0図のステップ S 1 2 7で p rivate_stream_idレジスタ 264 (第 3図） に記憶された、 再生対象 の字幕ストリームの private_stream_idと一致するかどうかを判定す る。
ステップ S 2 5 3において、 private— streaml—PES_payload()に記 述されてレ る private— stream一 idが、 private— stream— idレジス夕 2 6 4に記憶された private— stream— idと一致しないと判定された場合、 即ち、 直前のステップ S 2 52で見つかった private_stream一 1の PES_ packetOが、 再生対象の字幕ストリームではない場合、 ステップ S 2 52に戻り、 バッファ 2 1 5 Aに記憶されたプログラムストリ一ム中 の他の private— stream一 1の PES_packet 0の探索が行われ、 以下、 同様 の処理が繰り返される。
一方、 ステップ S 25 3において、 private— streaml—PES_payload( ) ίこ sci述 sれて る private— stream— id力、 private— stream— idレジス 夕 264に記憶された private_stream_idと一致すると判定された場 合、 即ち、 直前のステップ S 2 52で見つかった private_stream_lの PES_packet()が、 再生対象の字幕ストリームである場合、 ステップ S 2 54に進み、 字幕読み出し機能部 2 3 5は、 その private— streamj の PES— packet ()の private」streamし PES_payload() (第 2 1図） に記 述されている AU— locatorを、 バッファ 2 1 5 Aから読み出し、 その AU _locatorの直後の位置と、 その AU一 locatorが表す値とを加算すること で、 字幕アクセスユニットの先頭位置を求める。
即ち、 AU— locatorは、 第 2 1図で説明したように、 その AU— locator の直後の位置を基準として、 private— st reaml— PES— pay load 0の priva te— payloadOに格納される字幕アクセスユニット （あるいはオーディ ォアクセスユニット） の先頭位置を表すから、 AU locatorの直後の位 置に、 その All ocat orが表す値を加算することにより、 字幕アクセス ユニットの （絶対的な） 先頭位置を求めることができる。
字幕読み出し機能部 2 3 5は、 さらに、 ステップ S 2 5 4において 、 以上のようにして求めた字幕アクセスュニットの先頭位置を指すよ うに、 字幕読み出しポインタ記憶部 2 6 2に記憶された字幕読み出し ポインタを更新し、 ステップ S 2 5 5に進む。
ステップ S 2 5 5では、 字幕読み出し機能部 2 3 5は、 字幕デコー ダ制御モジュール 2 1 8から、 データの要求があつたかどうかを判定 し、 ないと判定した場合、 ステップ S 2 5 5に戻り、 同様の処理を繰 り返す。
また、 ステップ S 2 5 5において、 字幕デコーダ制御モジュール 2 1 8から、 データの要求があつたかと判定された場合、 ステップ S 2 5 6に進み、 字幕読み出し機能部 2 3 5は、 字幕読み出しポインタが 指しているパッファ 2 1 5 Aの位置からのプログラムストリームの構 文解析を行いつつ、 字幕アクセスュニットの先頭に記述されているサ ィズ分の 1つの字幕アクセスュニットを、 バッファ 2 1 5 Aから読み 出し、 その字幕アクセスュニットに付加されているタイムスタンプと ともに、 字幕デコーダ制御モジュール 2 1 8に供給する。 即ち、 字幕 アクセスュニットの先頭には、 第 2図 Aおよび第 2図 Bで説明したよ うに、 その字幕アクセスユニットのサイズが記述されており、 字幕読 み出し機能部 2 3 5は、 そのサイズ分のデータを、 字幕読み出しボイ ン夕が指しているバッファ 2 1 5 Aの位置から読み出し、 その読み出 したデータである字幕アクセスュニットを、 その字幕アクセスュニッ 卜に付加されているタイムスタンプとともに、 字幕デコーダ制御モジ ユール 2 1 8に供給する。
そして、 字幕読み出し機能部 2 3 5は、 ノ ッファ 2 1 5 Aから読み 出した 1つの字幕アクセスュニッ卜のサイズ分だけ、 字幕読み出しポ イン夕を更新して、 ステップ S 2 5 5に戻り、 以下、 同様の処理が繰 り返される。
[再同期処理]
次に、 第 2図 Aおよび第 2図 Bのデコード制御モジュール 2 1 4に よる、 ビデオデ一夕とオーディオデコーダとの同期制御について説明 する。
第 3 0図の S 1 3 0で説明したように、 デコード制御モジュール 2 1 4は、 同期を確保するために必要であればタイミングをずらして、 デコード開始を、 ビデオデコーダ制御モジュール 2 1 6、 オーディオ デコ一ダ制御モジュール 2 1 7、 および字幕デコーダ制御モジュール 2 1 8に指令するが、 例えば、 その後のビデオデコーダ 1 1 6とォ一 ディォデコーダ 1 1 7のデコード処理の進行程度によって、 ビデオデ —夕の出力と、 そのビデオデータと同期して出力されるべき出力デー 夕としてのオーディォデータの出力とがずれることがある。
そごで、 デコード制御モジュール 2 1 4では、 ビデオデータの出力 と、 そのビデオデータと同期して出力されるべきオーディォデ一夕の 出力とに生じたずれを補正し、 ビデオデータとオーディォデ一夕とが 同期して出力されるようにするための再同期処理が行われる。
第 3 9図のフローチヤ一卜を参照して、 再同期処理について説明す る。
再同期処理では、 まず最初に、 ステップ S 2 7 1において、 デコ一 ド制御モジュール 2 1 4は、 ビデオデコーダ制御モジュール 2 1 6か らのビデオアクセスュニットのタイムスタンプと、 オーディォ制御モ ジュール 2 1 7からのオーディォアクセスュニットのタイムスタンプ とのずれが大であるかどうかを判定する。 即ち、 第 3 0図のステップ S 1 2 9で説明したように、 ビデオデコ ーダ制御モジュール 2 1 6は、 バッファ制御モジュール 2 1 5からビ デォアクセスュニットを得るたびに、 そのビデオアクセスュニッ卜の タイムスタンプを、 デコード制御モジュール 2 1 4に供給する。 同様 に、 オーディオ制御モジュール 2 1 7も、 バッファ制御モジュール 2 1 5からオーディオアクセスュニットを得るたびに、 そのオーディォ アクセスュニットのタイムスタンプを、 デコード制御モジュール 2 1 4に供給する。
ステップ S 2 7 1では、 デコード制御モジュール 2 1 4は、 ビデオ デコーダ制御モジュール 2 1 6とオーディオ制御モジュール 2 1 7と のそれぞれから、 同一タイミングで （同一タイミングとみなすことが できる、 ある時間内に） 供給されるタイムスタンプどうしを比較し、 それらのタイムスタンプのずれが大であるかどうかを判定する。
ステップ S 2 7 1において、 ビデオデコーダ制御モジュール 2 1 6 からのビデオアクセスユニットのタイムスタンプと、 オーディオ制御 モジュール 2 1 7からのオーディォアクセスュニットのタイムスタン プとのずれが大でないと判定された場合、 即ち、 ビデオアクセスュニ ッ卜のタイムスタンプと、 オーディォアクセスュニットのタイムス夕 ンプとのずれが、 あらかじめ定められた同期がとれているとみなすこ とができる範囲内である、 例えば、 2ビデオフレーム （約 6 6ミリ秒 ) である場合、 ステップ S 2 7 1に戻り、 タイムスタンプどうしのず れの判定 （監視） が続行される。 .
一方、 ステップ S 2 7 1において； ビデオデコーダ制御モジュール 2 1 6からのビデオアクセスュニットのタイムスタンプと、 オーディ ォ制御モジュール 2 1 7からのオーディオアクセスュニットのタイム スタンプとのずれが大であると判定された場合、 即ち、 ビデオァクセ スュニットのタイムスタンプと、 オーディォアクセスュ ッ卜のタイ ムスタンプとのずれが、 あらかじめ定められた同期がとれているとみ なすことができる範囲外である場合、 ステップ S 27 2に進み、 デコ —ド制御モジュール 2 14は、 ビデオデコーダ制御モジュール 2 1 6 からのビデオアクセスユニットのタイムスタンプと、 オーディオ制御 モジュール 2 1 7からのオーディオアクセスュニッ卜のタイムスタン プとを比較することにより、 ビデオデータの出力 （デコード） と、 ォ —ディォデータの出力とのうちのいずれが遅れているかを判定する。 ステップ S 2 72において、 ビデオデータの出力が、 オーディオデ 一夕の出力よりも遅れていると判定された場合、 ステップ S 27 3に 進み、 デコード制御モジュール 2 14は、 1ビデオアクセスユニット だけ、 ビデオアクセスユニットの処理を進めるために、 ビデオデコー ダ制御モジュール 2 1 6に対して、 ビデオアクセスュニッ卜のデコー ドと出力 （表示） を行わない旨の指示、 即ち、 ビデオアクセスュニヅ トの処理のスキップの指示を出力して、 ステップ S 274に進む。 スチップ S 2 74では、 ビデオデコーダ制御モジュール 21 6は、 デコード制御モジュール 2 14からのスキップの指示を受信し、 その スキップの指示に応じて、 バッファ制御モジュール 2 1 5からのビデ ォアクセスュニットとともに供給される au_ref一 flag (第 24図） を 検査する。
即ち、 private— stream— 2の PES— packet 0の private— stream2— PES— pa yloadO (第 2 3図） に配置された au_.informat ion() (第 24図） に は、 アクセスュニットに関する情報としての au_reし flagが含まれて おり、 ノ ッファ制御モジュール 2 1 5は、 第 30図のステップ S 1 2 9や、 第 36図のステップ S 2 1 6で説明したように、 ビデオァクセ スユニッ トとともに、 そのビデオアクセスユニットの au ref flagを 、 ビデオデコーダ制御モジュール 2 1 6に供給する。
ステップ S 2 7 4では、 このように、 アクセスユニットとともに供 給される、 そのアクセスュニットの au_reし f l agが検査される。
そして、 ステップ S 2 7 4から S 2 7 5に進み、 ビデオデコーダ制 御モジュール 2 1 6は、 バッファ制御モジュール 2 1 5から供給され たビデオアクセスュニットの au_reし f l agの検査の結果に基づき、 そ のビデオアクセスュニットが、 他のピクチャのデコードにあたって参 照されない非参照画像であるかどうかを判定する。
ここで、 第 2 4図で説明したように、 ビデオアクセスユニットの au —reし f l agは、 そのアクセスユニットが参照画像であるか否かを表し 、 参照画像である場合には 1とされ、 参照画像でない場合、 即ち、 非 参照画像である場合には 0とされる。
ステップ S 2 7 5において、 バッファ制御モジュール 2 1 5から供 給されたビデオアクセスュニットが非参照画像 （のビデオアクセスュ ニット） でないと判定された場合、 即ち、 バッファ制御モジュール 2 1 5がら供給されたビデオアクセスュニッ卜が参照画像である場合、 ステップ S 2 7 6に進み、 ビデオデコーダ制御モジュール 2 1 6は、 通常通り.、 そのビデオアクセスユニットを、 ビデオデコーダ 1 1 6に 処理させ、 次のビデオアクセスユニットが、 バッファ制御モジュール 2 1 5から供給されるのを待って、 ステップ S 2 7 4に戻る。
また、 ステップ S 2 7 5において、 ノ ッファ制御モジュール 2 1 5 から供給されたビデオアクセスュニットが非参照画像であると判定さ れた場合、 ステップ S 2 7 7に進み、 ビデオデコーダ制御モジュール 2 1 6は、 そのビデオアクセスユニットの、 ビデオデコーダ 1 1 6に よる処理をスキップさせ、 次のビデオアクセスユニットが、 バッファ 制御モジュール 2 1 5から供給されるのを待って、 ステップ S 2 7 1 に戻る。
このように、 ビデオアクセスュニッ卜の処理がスキップされること により、 ビデオアクセスユニットの処理が、 ほぼ 1ビデオアクセスュ ニット分だけ進められる （処理時間が短縮される） 。 その結果、 ォー ディォデータの出力よりも遅れていたビデオデータの出力が早まるこ とになる。
一方、 ステップ S 2 7 2において、 ビデオデータの出力が、 オーデ ィォデ一夕の出力よりも遅れていないと判定された場合、 即ち、 ォー ディォデ一夕の出力が、 ビデオデータの出力よりも遅れている場合、 ステップ S 2 7 8に進み、 デコード制御モジュール 2 1 4は、 ビデオ アクセスュニットの処理を待たせるために、 ビデオデコーダ制御モジ ユール 2 1 6に対して、 いまデコードされているビデオアクセスュニ ットに対応するビデオデータを繰り返して出力する繰り返し出力の指 示を出力して、 ステップ S 2 7 9に進む。
ステップ S 2 7 9では、 ビデオデコーダ制御モジュール 2 1 6は、 デコード制御モジュール 2 1 4からの繰り返し出力の指示を受信し、 その繰り返し出力の指示に応じて、 いまビデオデコーダ 1 1 6でデコ 一ドされているビデオアクセスュニットに対応するビデオデータを繰 り返して、 グラフィクス処理モジュール 2 1 9に出力し、 次のビデオ アクセスユニットが、 バッファ制御モジュール 2 1 5から供給される のを待って、 ステップ S 2 7 1に戻る。
以上のように、 デコード制御モジュ r~ル 2 1 4では、 ビデオデータ の出力が、 オーディォデータの出力よりも遅れているか否かを判定し 、 ビデオデータの出力が、 オーディオデータの出力よりも遅れている 場合には、 1つのアクセスユニットの処理のスキップを、 ビデオデコ ーダ制御モジュール 2 1 6に指示する。 そして、 ビデオデコーダ制御 モジュール 2 1 6では、 スキップが指示されたアクセスュニッ卜の au —reし f l agに基づき、 そのアクセスユニットが参照画像であるか、 ま たは非参照画像であるかを判定し、 非参照画像である場合に、 ビデオ デコーダ 1 1 6に、 スキップが指示されたアクセスュニットの処理を スキップさせる。 従って、 ビデオデータの出力と、 オーディオデータ の出力との同期を、 容易にとることができる。
即ち、 処理をスキップするアクセスュニットが参照画像である場合 、 そのアクセスユニットに対応するビデオデ一夕は、 その後にデコー ドされる他のアクセスュニットのデコード時に参照するためにデコ一 ドする必要がある。 従って、 ビデオデータの出力と、 オーディオデー 夕の出力との同期をとるための同期制御において、 参照画像のァクセ スュニットの処理をスキップしてしまうと、 その参照画像を参照する 他のアクセスユニットをデコードすることができず、 その結果、 ビデ ォデータの表示において、 同期制御がノイズとして現れてしまう。
このため、 処理をスキップするのは、 参照画像でないアクセスュニ ット、'即ち、 非参照画像のアクセスュニットとするのが望ましい。 一方、 従来のエレメン夕リストリ一ムについて、 非参照画像のァク セスュニットを探すためには、 エレメンタリストリームの構文解析を 行う必要があるが、 例えば、 MPEG4-AVCなどにしたがった符号化によ り得られるエレメン夕リストリームは、 構文が非常に複雑であるため 、 構文解析に、 多大なコストがかかる。
これに対して、 ディスク 1 0 1に記録されたクリップストリームフ アイルに格納されたプログラムストリームには、 ビデオアクセスュニ ットが PES_packe t_da — by t eに配置される PES— packe t 0 (第 1 6図 A および第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 B ) とは別に、 PES_ packe t一 dat a by t eを拡張した pr i va t e s t r eara2 PES_pay l oad 0 (第 2 3図） が配置された private— stream— 2の PES_packet 0が多重化されて おり、 その private一 stream2一 PES_payload()の au— information 0 (第 24図） には、 ビデオアクセスユニットごとに、 そのビデオアクセス ュニットが参照画像であるか、 または非参照画像であるかを表す au一 r ef_flagが記述されている。 そして、 その au— reし flagは、 対応するビ デォアクセスュニッ卜とともに、 バッファ制御モジュール 2 1 5力 ら ビデオデコーダ制御モジュール 2 1 6に供給される。 従って、 ビデオ デコーダ制御モジュール 2 1 6は、 ビデオアクセスュニットとともに 供給される、 そのビデオアクセスュニットの au_ref_flagを検査する ことにより、 コストをほとんどかけずに、 ビデオアクセスユニットが 参照画像であるか、 または非参照画像であるかを認識することができ る。
[マーク処理]
次に、 第 40図のフローチャートを参照して、 PI ayListMarkO (第 7図） に記述された MarkOに基づいて行われるマーク処理について説 明する。
デコード制御モジュール 2 14は、 内蔵する計時部 2 14 Aによつ て計時されている現在時刻を、 常時確認しており、 ステップ S 3 0 1 において、 現在時刻が、 Pl.ayListMarkO (第 7図） に記述されたいず れかの MarkOの mark_time_stampに一致したか否かを判定する。
即ち、 第 30図のステップ S 1 24で説明したように、 プレイヤ制 御モジュール 2 1 2は、 第 2 5図に示.した 1番目の P yList#0の 1番 目の P yItem#0を再生しょうとするときに、 第 2 8図上側に示した P1 ayListMarkOに含まれる 7つの Mark 0のうちの 1番目から 4番目まで の 4つの MarkOが、 PlayList#0の 1番目の PlayItem#0に属しているこ とを認識し、 その 4つの MarkOの mark— time sta即である {180， 090}、 {5,580,090}, {10， 980, 090}、 {16, 380， 090}を、 その mark— t ime— s mpが表す時刻の属性が 「マーク処理」 である旨とともに、 デコード制 御モジュール 2 14に渡している。
ステップ S 30 1では、 デコード制御モジュール 2 14において、 現在時刻が、 上述のようにしてプレイヤ制御モジュール 2 1 2から供 給された 「マーク処理」 の属性の時刻（mark— time_stainp)のうちのい ずれかと一致するかどうかが判定される。
ステップ S 30 1において、 現在時刻が、 「マーク処理」 の属性の 時刻のうちのいずれとも一致しないと判定された場合、 ステップ S 3 0 1に戻り、 同様の処理が繰り返される。
また、 ステップ S 30 1において、 現在時刻が、 「マーク処理」 の 属性の時刻のうちのいずれかと一致すると判定された場合、 デコード 制御モジュール 2 1 4は、 現在時刻が、 「マーク処理」 の属性の時刻 となった旨のメッセージと、 現在時刻と一致した 「マーク処理」 の属 性の時刻とを、 プレイヤ制御モジュール 2 1 2に供給して、 ステップ S 30 2に進む。
ステップ S 3 02では、 プレイヤ制御モジュール 2 1 2が、 現在時 刻が、 「マーク処理」 の属性の時刻となった旨のメッセージと、 現在 時刻と一致した 「マーク処理」 の属性の時刻（mark—time— stamp)とを 、 デコード制御モジュール 2 14から受信し、 mark一 time— st a即が現 在時刻に一致した MarkOを、 マーク処理の処理対象とする MarkO (以 下、 適宜、 処理対象 markという） として認識する。
即ち、 プレイヤ制御モジュール 2 1 2は、 現在再生されている Play List 0の PlayltemOを認識しており、 その？1& 1^3 ）ぉょび？1& 1 6111 0と、 デコード制御モジュール 2 14からの、 現在時刻と一致した 「 マーク処理」 の属性の時刻（mark time stamp) (以下、 適宜、 マーク 時刻という） とから、 "PLAYLIST.DAT"ファイル （第 5図） の PlayList MarkO (第 7図） を参照することにより、 処理対象 markを認識する。 具体的には、 例えば、 いま、 第 2 5図に示した 1番目の PlayList#0 の 1番目の PlayItem#0が再生されているとすると、 そのことにより、 プレイヤ制御モジュール 2 1 2は、 マーク時刻が、 第 2 8図上側に示 した PlayListMarkOに含まれる 7つの MarkOのうちの 1番目から 4番 目までの 4つの MarkOのうちのいずれかの mark一 time_sta即であるこ とを認識する。
そして、 デコード制御モジュール 2 1 4からプレイヤ制御モジユー ル 2 1 2に供給されたマーク時刻が、 例えば、 16,380,090であったと すると、 プレイヤ制御モジュール 2 1 2は、 第 2 8図上側に示した P1 ayListMarkOに含まれる 1番目から 4番目までの 4つの MarkOのうち の、 mark_time_stampが、 マーク時刻である 16， 380， 090に一致する 4 番目の MarkOを、 処理対象 markとして認識する。
プレイヤ制御モジュール 2 1 2は、 以上のようにして、. 処理対象 ma rkを認識すると、 ステップ S 3 0 2から S 3 0 3に進み、 処理対象 ma rkにおいて、 エレメン夕リストリームを特定する entry_ES_stream_id と entry— ES_private— stream— id (第 7図) が記述されているかどうか を判定する。
ステップ S 3 0 3において、 処理対象 markに、 エレメン夕リストリ —ムを特疋する entry— ES— stream— idと entry— ES— private— stream一 id ( 第 7図） が記述されていないと判定された場合、 即ち、 entry一 ES_str earn— idと entry— ES— private— stream— idが、 いずれも 0x00である場合、 ステップ S 3 04をスキップして、 ステップ S 3 0 5に進み、 以下、 処理対象 markに応じた処理が行われる。
また、 ステップ S 3 0 3において、 処理対象 markに、 エレメンタリ ストリームを特定する entry_ES— stream— idと entry— ES— private— s trea m_id (第 7図） が記述されていると判定された場合、 ステップ S 3 0 4に進み、 プレイヤ制御モジュール 2 1 2は、 再生中のエレメンタリ ストリームに、 その entry_ES_stream_id、 さらには、 必要に応じて en try一 ES_private— stream一 idによって特定されるエレメンタリストリー ムが含まれるかどうかを判定する。
ステップ S 3 04において、 再生中のエレメン夕リストリームに、 処理対象 markの entry— ES— s tream一 idと entry—ES—private_stream—id よって特定されるエレメン夕リストリームが含まれないと判定された 場合、 ステップ S 3 0 1に戻る。 即ち、 処理対象 markの entry_ES— str eam_idと entry_ES— private—stream— idによって特定されるエレメン夕 リストリームが再生されていない場合、 処理対象 markは、 無視される 一方、 ステップ S 3 04において、 再生中のエレメンタリストリ一 ムに、 処理対象 markの entry— ES— stream— idと entry— ES— private— strea m_idによって特定されるエレメン夕リストリームが含まれると判定さ れた場合、 即ち、 処理対象 markの entry_ES_stream_idと entry— ES_pri vate_stream_idによって特定されるエレメン夕リストリームが再生さ れている場合、 処理対象] narkは有効であるとして、 ステップ S 3 0 5 に進み、 以下、 その処理対象 markに応じた処理が行われる。
即ち、 ステップ S 3 0 5では、 プレイヤ制御モジュール 2 1 2は、 処理対象 markの markjype (第 7図） を参照することにより、 その処 理対象 markを判定する。
ステップ S 3 0 5において、 処理対象 markが、 チヤプ夕マークまた はインデクスマークであると判定された場合、 即ち、 処理対象 markの mark typeが、 ' Chapter'または' Index'である場合、 ステップ S 3 0 6に進み、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジ ユール 2 1 9に命じて、 チヤプ夕またはインデクスの番号の表示を、 処理対象 markであるチヤプ夕マークまたはィンデクスマークが表すチ ャプ夕またはィンデクスの番号に更新させて、 ステップ S 30 1に戻 る。
また、 ステップ S 3 0 5において、 処理対象 markが、 イベントマ一 クであると判定された場合、 即ち、 処理対象 markの mark_typeが、 'Ev ent'である場合、 ステップ S 307に進み、 プレイヤ制御モジュール 2 1 2は、 イベントの発生を表すイベントメッセージと、 処理対象 ma rkの mark_dataを、 スクリプト制御モジュール 2 1 1に通知 （供給） して、 ステップ S 308に進む。
ステップ S 3 0 8では、 スクリプト制御モジュール 2 1 1が、 プレ ィャ制御モジュール 2 1 2からのイベントメッセージと mark_dataと を受信し、 イベントメッセージを割り込み要求として、 あらかじめ" S CRIPT.DAT"ファイルに記述された一連の処理を、 mark— dataを引数と して行って、 ステップ S 30 1に戻る。
即ち、 スクリプト制御モジュール 2 1 1では、 marldataに対応し た処理が行われる。
具体的には、 例えば、 第.28図下側に示した PlayList #1の PlayLis tMarkOでは、 2番目の MarkO (Mark#l) と 3番目の MarkO ( ark#2 ) とは、 いずれも、 mark_typeが' Event'であるが、 mark_dataは、 そ れぞれ 1 (Mark#l) と 2 (Mark#2) で異なっている。
スクリブト制御モジュール 2 1 1は、 2番目の MarkOに対応するィ ベントメッセージを受信した場合と、 3番目の MarkOに対応するィべ ントメッセージを受信した場合の、 いずれも場合も、 そのイベントメ ッセージに応じて、 同一のイベントハンドラ （割り込み処理ルーチン ) で処理を行うが、 イベントハンドラ内において、 イベントメッセ一 ジとともに供給される mar dataを検査することにより、 イベントメ ッセージに対して、 mark一 dataごとに異なる処理を行う。
具体的には、 例えば、 mark_dataが 1である場合には、 スクリプト制 御モジュール 2 1 1は、 グラフィクス処理モジュール 2 1 9を制御し て、 第 1の種類のアイコンの表示を行わせる。 また、 例えば、 mark_d ataが 2である場合、 スクリプト処理モジュール 2 1 1は、 グラフイク ス処理モジュール 2 1 9を制御して、 第 2の種類のアイコンの表示を 行わせる。
なお、 mark— dataは、 1や 2に限定されるものではなく、 また、 mar k_dataに対応して行われる処理も、 上述したような、 単なるアイコン の表示限定されるものではない。
即ち、 例えば、 mark_dataが 3乃至 18の範囲の値である場合には、 ス クリブト制御モジュール 2 1 1は、 グラフィクス処理モジュール 2 1 9を制御し、 第 1の種類のアイコンの表示を、 mark_dataから 2を減じ た値 （1〜16の数値） に対応する明るさで行わせる。 また、 例えば、 m ark— dataが 19乃至 34の範囲の値である場合には、 スクリブト制御モジ ユール 2 1 1は、 グラフィクス処理モジュール 2 1 9を制御し、 第 2 の種類のアイコンの表示を、 mark一 dataから 18を減じた値 （1〜16の数 値） に対応する明るさで行わせる。
その他、 例えば、 入力インタ一フェース 1 1 5 (第 1図） に、 ユー ザが操作するコントローラが接続されており、 そのコントローラが、 DC (Direct Current)モー夕の軸に偏芯させたおもりを取り付けた、 DC モータを動作させると振動が発生する振動モ一夕を内蔵する場合には 、 mark— dataが 35乃至 42の範囲の値であるときに、 その振動モータを 、 mark_dataから 34を減じた値 （1〜8の数値） に応じた動作時間だけ 動作させることができる。
mark_dataは数値であり、 その使用法やアルゴリズムは、 スクリブ ト制御モジュール 2 1 1が実行するスクリプトプログラムにより記述 することができる。 従って、 mark—dataは、 事前に取り決められたル —ルで使用する他、 ディスク 1 0 1の製造者、 あるいはディスク 1 0 1に記録されるデータを提供するコンテンツプロバイダなどが独自に 設定したルールで使用することが可能である。
以上のように、 マーク処理では、 現在時刻が、 「マーク処理」 の属 性の時刻と一致すると、 その 「マーク処理」 の属性の時刻であるマー ク時刻から、 処理対象 markが認識される。 さらに、 処理対象 markにお いて、 エレメンタリストリームを特定する entry— ES_stream— idと entr y_ES— private_stream一 idが記述されていない場合には、 処理対象 mark の mark— typeに応じた処理が行われる。 また、 処理対象 markにおいて 、 エレメン夕リストリームを特定する entry_ES_stream一 idと entry— ES _private一 stream_idが記述されている場合であっても、 その entry_ES _stream— idと entry—ES—private— stream— idによつて特定されるエレメ ン夕リストリームが再生中であれば、 処理対象 markの mark—typeに応 じた処理が行われる。
従って、 例えば、 いま、 第 2 5図に示した 2番目の PlayList#lの再 生が行われているとすると、 以下のようなマーク処理が行われる。 即ち、 2番目の PlayList#lの P yListMarkOにおいては、 第 2 8図 下側に示したように、 mark一 time— stampがそれぞれ 90, 000， 27， 090， 00 0， 27,540,000に指定されてぃる 1番目の¾^^() (¾1& #0)、 2番目の M arkO (Mark#l) 、 3番目の MarkO (Mark#2) が記述されている。 さらに、 第 2 8図下側の PlayListMarkOにおいては、 2番目の Mark 0と 3番目の MarkOの entry— ES stream idには、 それぞれ、 OxEOと Ox Elが記述されているから、 2番目の MarkOと 3番目の MarkOは、 それ ぞれ、 stream_idが OxEOと OxElで特定されるエレメンタリストリーム が関連付けられている。
ここで、 第 2 5図で説明したように、 2番目の PlayListiflには、 1 つの PlayltemO (PlayItem#0)だけが記述され、 その P yl tem#0によれ ば、 クリップストリームファイル" 00003.PS"が再生される。 そして、 クリップストリームファイル" 00003.PS"には、 そのクリップストリ一 ムファイル" 00003.PS"に対応する第 26図 Aおよび第 2 6図 Bのクリ ップ情報ファィル" 00003. CLP"で説明したように、 OxEOとなっている s tream一 idで特定されるビデオストリーム stream#0、 OxElとなっている stream_idで特定されるビデオストリ一ム stream#l、 OxBDとなってい る stream— idおよび 0x00となっている private_stream— idで特定される オーディオストリーム stream#2の 3つのエレメンタリストリームが多 重化されている。
従って、 第 28図下側の PlayListMarkOの 2番目の MarkOには、 ク リップストリ一ムファイル" 00003.PS"に多重化されている、 stream_i dが OxEOとなっているビデオストリーム s t ream#0が関連付けられてお り、 3番目の MarkOには、 クリップストリ一ムファイル" 00003.PS"に 多重化されている、 streamjdが OxElとなっているビデオストリーム s tream#lが関連付けられている。
第 2 5図の 2番目の PlayList#lの PlayItem#0の再生が開始される場 合、 第 30図のステップ S 1 24で説明したようにして、 プレイヤ制 御モジュール 2 1 2は、 第 2 8図下側に示した PlayListMarkOに含ま れる 3つの MarkOが、 PlayLis t#lの Playl tem#0に属していることを認 識し、 その 3つの MarkOの mark— time_s tampである {90， 000}、 {27, 090 ，000}、 {27, 540,000}を、 その mark time stampが表す時刻の属性が 「 マーク処理」 である旨とともに、 デコード制御モジュール 2 1 4に渡 している。
マーク処理では、 デコード制御モジュール 2 1 4が、 PlayList#lの PlayItem#0の再生中に、 計時部 2 1 4 Aによって計時される現在時刻 が、 属性が 「マーク処理」 の時刻 {90， 000}、 {27, 090,000}, {27， 540， 000}のうちのいずれかに一致するかを、 常時確認しており （ステップ S 3 0 1 ) 、 現在時刻が、 属性が 「マーク処理」 の時刻に一致すると 、 現在時刻と一致した 「マーク処理」 の属性の時刻であるマーク時刻 と、 現在時刻が、 「マ一ク処理」 の属性の時刻となった旨のメッセ一 ジとを、 プレイヤ制御モジュール 2 1 2に供給する。
即ち、 例えば、 いま、 現在時刻が、 「マーク処理」 の属性の時刻 {9 0,000}, {27, 090,000}, {27, 540， 000}のうちの、 27， 090， 000に一致し たとすると、 デコード制御モジュール 2 1 4は、 現在時刻と一致した 「マーク処理」 の属性の時刻であるマーク時刻 27, 090, 000と、 現在時 刻が、 「マーク処理」 の属性の時刻となった旨のメッセージとを、 プ レイヤ制御モジュール 2 1 2に供給する。
プレイヤ制御モジュール 2 1 2は、 PlayList#lの PlayItem#0が現在 再生されていることを認識しており、 その PlayList#lの第 2 8図下側 に示した？ 1^51¾^^0に.記述された MarkOのうちの、 PlayItem#0に 属する 3つの MarkOの mark_time_stampである 90， 000， 27, 090, 000, 2 7， 540， 000それぞれと、 デコード制御モジュール 2 1 4からのマーク 時刻である 27, 090， 000とを比較することにより、 そのマーク時刻 27， 0 90,000に、 mark— time_sta即が一致する Mark()、 即ち、 第 2 8図下側 の PlayListMarkOに記述された 2番目の MarkO (Mark#l)を、 処理対象 markとして認識する （ステップ S 3 0 2) 。
処理対象 markである、 第 2 8図下側の？1& 31¾^^0に記述された 2番目の MarkOにおいては、 entry_ES__stream_idとして、 OxEOが指定 されている。 この OxEOとなっている entry_ES_stream_idは、 上述した ことから、 クリップストリームファイル" 00003.PS"に多重化されてい る、 stream_idが OxEOとなっているビデオストリーム stream#0 (第 2 6図 Aおよび第 2 6図 B) を表すものであり、 プレイヤ制御モジユー ル 2 1 2は、 再生中のエレメン夕リストリームの中に、 そのビデオス トリ一ム stream#0が含まれるかどうかを判定する （ステップ S 3 0 3 ， S 3 04 ) 。
そして、 再生中のエレメン夕リストリームの中に、 ビデオストリー ム stream#0が含まれない場合には、 処理対象 markは無視される （ステ ップ S 3 04 ) 。
一方、 再生中のエレメン夕リストリームの中に、 ビデオストリーム stream#0が含まれる場合には、 処理対象 markは有効であるとして、 そ の処理対象 markに応じた処理が行われる （ステップ S 3 0 5乃至 S 3 0 8 ) 。
即ち、 いまの場合、 処理対象 markである、 第 2 8図下側の PlayList MarkOに記述された 2番目の MarkOは、 その mark— typeが' Event'にな つているからイベントマークであり、 従って、 プレイヤ制御モジュ一 ル 2 1 2は、 ィベンドの発生を表すイベントメッセージと、 処理対象 markの mark— dataを、 スクリプト制御モジュール 2 1 1に供給する （ ステップ S 3 0 5, S 3 0 7) 。 そして、 スクリプト制御モジュール 2 1 1では、 プレイヤ制御モジュール.2 1 2からのイベントメッセ一 ジを割り込み要求として、 あらかじめ' 'SCRIPT. DAT"ファイルに記述さ れた一連の処理を、 そのイベントメッセージとともに供給された mark —dataを引数として行う （ステップ S 3 0 8 ) 。
以上のように、 マーク処理によれば、 PlayListOの時間軸上の 1つ の再生時刻を表す mark_time— sta即と、 MarkOのタイプを表す mark—ty peと、 ィベントマークの引数となる mark_dataとを含む 0以上の Mark ( )を有する PlayListMarkO (第 7図） を含む PlayLis t 0 (第 5図） に したがって再生されているクリップストリームファイルの再生時刻で ある現在時刻が、 mark—tinie_sta即に一致するか否かが判定され、 現 在時刻が、 mark—time一 st a即に一致する場合に、 その一致した現在時 刻であるマーク時刻に等しい mark— time_sta即を有する MarkOが、 処 理対象 markとして認識される。 さらに、 その処理対象 markが有する ma rk_typeが、 イベントを発生させるタイプを表している場合、 即ち、 処理対象 markが、 イベントマ一クである場合、 処理対象 markが有する mark— dataとィベントメッセージとが通知され、 その mark— dataに応じ た処理が実行される。 従って、 クリップストリームファイルの再生時 刻に応じ、 mark_dataに応じた処理を実行することが可能となる。
[出力属性の制御処理]
次に、 第 41図のフローチャートを参照して、 第 3 0図のステップ S 1 2' 6などで行われる出力属性の制御処理の詳細について説明する 第 30図のステップ S 1 2 6で説明したように、 プレイヤ制御モジ ユール 2 1 2は、 まず、 再生対象の 1以上のエレメン夕リストリーム 、 即ち、 第 30図のステップ S 1 2 5で再生すると決定した 1以上の エレメンタリストリームそれぞれについて、 出力属性が記述される Dy namicInfoO (第 1 3図） の数を表す number— oし Dynamiclnfo (第 1 0 図） を調査する。
そして、 再生対象の 1以上のエレメンタリストリームのすべてにつ いて、 number_oし Dynamiclnfoが 0になっている場合、 プレイヤ制御モ ジュール 2 1 2は、 特に処理を行わない。 一方、 再生対象のエレメン夕リストリームについての number—of— Dy namiclnfoが 0でない場合、 プレイヤ制御モジュール 2 1 2は、 第 4 1 図のフローチャートにしたがった出力属性の制御処理を行う。
従って、 ディスク 1 0 1に記録された 3つのクリップ情報ファイル " 00001. CLP", " 00002. CLP", " 00003. CLP"が、 例えば、 第 2 6図 Aお よび第 2 6図 Bに示したようになつている場合に、 クリップ情報ファ ィル" 00001.CLP"に対応するクリップストリームファイル" 00001.PS" (を再生する 1番目の P yList#0の 1番目の Playltem#0) が再生され るときには、 クリップ情報ファイル" 00001.CLP" (第 2 6図 Aおよび 第 2 6図 B) では、 クリップストリームファイル" 00001.PS"に多重化 されている 4つのエレメンタリストリーム streani#0乃至 stream#3のす ベてについて、 number_oし Dynamiclnfoが 0になっているから、 出力属 性の制御処理は行われない。
同様に、 クリップ情報ファイル" 00002. CLP"に対応するクリップス トリ一ムファイル" 00002.PS" (を再生する 1番目の PlayList#0の 2番 目の Piayltem#l) が再生されるときも、 クリップ情報ファイル" 00002 . CLP" (第 2 6図 Aおよび第 2 6図 B) では、 クリップストリームフ アイル" 00002.PS"に多重化されている 4つのエレメンタリストリーム stream#0乃至 stream#3のす.ベてについて、 number__o f一 Dynamic Infoが 0 になっているから、 出力属性の制御処理は行われない。
一方、 クリップ情報ファイル" 00003. CLP"に対応するクリップスト リームファイル" 00003.PS" (を再生する 2番目の PlayList#lの Playlt em#0) が再生されるときは、 クリップ情報ファイル" 00003. CLP" (第 2 6図 Aおよび第 2 6図 B) において、 クリップストリームファイル " 00003.PS"に多重化されている 3つのエレメン夕リストリーム stream #0乃至 stream#2のうちの、 1番目のエレメン夕リストリームであるビ デォストリーム streamsと、 3番目のエレメン夕リストリームである オーディストリーム stream#2について、 number— of— Dynamiclnf oが 0で ない 2と 3に、 それぞれなつているから、 出力属性の制御処理が行われ る。
即ち、 出力属性の制御処理では、 まず最初に、 ステップ S 320に おいて、 プレイヤ制御モジュール 2 1 2は、 再生対象のクリップスト リームファイルに対応するクリップ情報ファイル ClipO (第 1 0図） に記述された pts—change_pointを、 「 Dynamiclnf o 0処理」 の属性の 時刻である旨とともに、 デコード制御モジュール 2 14に渡し、 デコ —ド制御モジュール 2 14は、 プレイヤ制御モジュール 2 1 2からの 「DynamicInfo()処理」 の属性の時刻である pts— change— pointを受信 して、 ステップ S 3 2 1に進む。
ステップ S 32 1では、 デコード制御モジュール 2 14が、 計時部 2 14 Aによって計時されている現在時刻が、 「DynamicInfo()処理 」 の属性の時刻である pts— change一 point (のいずれか） に一致したか どうかを判定し、 一致していないと判定した場合、 ステップ S 32 1 に戻る。
また、 ステップ S 32 1において、 現在時刻が、 「DynamicInfo() 処理」 の属性の時刻 （のいずれか） に一致したと判定された場合、 デ コード制御モジュール 2 14は、 現在時刻が、 「DynamicInfoO処理 J の属性の時刻となった旨のメッセージと、 現在時刻と一致した 「Dy namicInfoO処理」 の属性の時刻 （以下、 適宜、 Dynamiclnf o時刻とい う） とを、 プレイヤ制御モジュール 2 1 2に供給して、 ステップ S 3 2 2に進む。
ステップ S 3 3 2では、 プレイヤ制御モジュール 2 1 2が、 現在時 刻が、 「DynamicInfo()処理」 の属性の時刻となった旨のメッセージ と、 Dynamiclnfo時刻とを、 デコード制御モジュール 2 14から受信 し、 その Dynamiclnfo時刻に一致する pts— change— point (第 1 0図） とセットになっている DynamicInfoOを、 処理対象の Dynamiclnf o 0で ある処理対象 DynamicInfoOとして認識して、 ステップ S 323に進 む。
ステップ S 32 3では、 プレイヤ制御モジュール 2 1 2は、 処理対 象 DynamicInfoOとなっている DynamicInfoO (第 1 3図） に記述され た出力属性を、 グラフィクス処理モジュール 2 1 9またはオーディォ 出力モジュール 2 2 1に供給して、 ステップ S 324に進む。
ステップ S 324では、 グラフィクス処理モジュール 2 1 9または オーディォ出力モジュール 22 1が、 直前のステップ S 323でプレ ィャ制御モジュール 2 1 2から供給された出力属性にしたがって、 ピ デォデ一夕またはオーディォデータの出力の制御を、 それぞれ開始し 、 ステップ S 32 1に戻る。
これにより、 ビデオデータが、 出力属性 （表示方式） として記述さ れた、'例えばアスペクト比に応じて出力され、 あるいは、 オーディオ データが、 出力属性 （出力方式） として記述された、 例えば、 ステレ ォまたはデュアル （ニケ国語） に応じて出力される。
次に、 第 42図を参照して、 出力属性の制御処理の詳細について、 さらに説明する。
即ち、 第 42図は、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報フ アイル" 00003. CLP"に記述されている pts— change— pointと Dynamiclnfo 0とのセット （第 1 0図） を示している。
ここで、 上述したように、 クリップストリームファイル" 00003.PS" に多重化されている 3つのエレメン夕リストリーム31 &111#0乃至3 6 am#2のうちの、 1番目のエレメン夕リストリームであるビデオストリ ーム stream#0と、 3番目のエレメン夕リストリームであるオーデイス トリーム stream#2については、 第 2 6図 Aおよび第 2 6図 Bのクリッ プ情報ファイル" 00003. CLP"において、 number_oし Dynamic Infoが、 そ れぞれ 2と 3になっている。 従って、 クリップ情報ファイル" 00003.CLP "において、 クリップストリームファイル" 00003.PS"の 1番目のビデ ォストリ一ム stream#0については、 2セットの pts_change— pointおよ び Dynamic Info ()が記述されており、 3番目のォ一ディォストリーム s tream#2については、 3セッ卜の pts— change— pointおよび Dynamiclnfo. 0が記述されている。
第 4 2図上側は、 クリップストリームファイル" 00003.PS"の 1番目 のビデオストリーム st ream#0について記述されている 2セットの pts— change— pointおよび Dynamiclnfo 0を示しており、 第 42図下側は、 クリップストリームファイル" 00003.PS"の 3番目のォ一ディォストリ ーム stream#2について記述されている 3セットの pts— change_pointお よび DynamicInfoOを示している。
なお、 第 42図上側では、 1番目のビデオストリーム stream#0につ いて記述されている 2セットの pts_change_pointおよび DynamicInfo( )の他に、 そのビデオストリーム stream#0について、 第 2 6図 Aおよ び第 2 6図 Bのクリップ情報ファイル" 00003. CLP"に記述されている s tream— id (=0xE0)， private_stream_id (,=0x00) , number— of— Dynamic In fo(=2)も、 図示してある。 同様に、 第 42図下側でも、 3番目のォ一 ディォストリーム stream#2について記.述されている 3セットの pts— ch ange— pointおよび DynamicInfoOの他に、 そのオーディォストリーム s tream#2について、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファ ィル" 00003. CLP"に記述されている stream— id(=0xBD), pr ivate_s t rea m id(=0x00), number of—DynamicInfo(=3)も、 図示してある。 第 42図上側において、 ビデオストリ一ム stream#0について記述さ れている 2セットの pts_change_pointおよび DynamicInfoOのうちの 1セット目では、 pts_change_pointが 90， 000になっており、 Dynamicl nfoOの display— aspecし ratio (第 1 3図） が' 4:3'になっている。 さ らに、 その 2セット目では、 013ー(；11&1^6_0011^が54，090，000になって おり、 DynamicInfoOの display— aspecし rat ioが' 16:9'になっている 一方、 第 4 2図下側において、 オーディオストリーム stream#2につ いて記述されている 3セットの pts— change— pointおよび DynamicInfo( )のうちの 1セット目では、 pts_change_pointが 90， 000になっており 、 DynamicInfoOの channel— assignment (第 1 3図） が' Dual'になつ ている。 さらに、 その 2セット目では、 pts— change_pointが 27,090，0 00になっており、 DynamicInfoOの channel— ass ignmentが' Stereo'に なっている。 また、 その 3セット目では、 pts_change_pointが 32， 490 ，000になっており、 DynamicInfoOの channel— assignment'が' Dual'に なつ Tいる。
例えば、 いま、 第 3 0図のステップ S 1 2 5において、 クリップス トリームファイル" 00003.PS"の、 OxEOとなっている stream一 idで特定 される 1番目のビデオストリ一ム stream#0と、 OxBDとなっている stre am_idおよび 0x00となっている private_stream_idで特定される 3番目 のオーディォストリーム stream#2とが、 再生対象のストリームとして 決定されたとする。
この場合、 プレイヤ制御モジュール 2 1 2は、 OxEOとなっている st ream— idで特定されるビデオストリーム stream#0について記述されて いる第 4 2図上側の 2セットの pts— change— pointおよび DynamicInfo( )と、 OxBDとなっている stream— idおよび 0x00となっている private st ream一 idで特定されるオーディォストリーム stream#2について記述さ れている第 42図下側の 3セットの pts— change一 pointおよび Dynamicl nfo()との中の pts_change_pointを調査し、 初期値を認識する。
即ち、 OxEOとなっている stream—idで特定されるビデオストリ一ム s tream#0について記述されている第 4 2図上側の 2セットの pts_chang e_pointおよび DynamicInfoOのうちの 1セット目では、 pts— change— p ointが 90， 000になっている。 そして、 この 90， 000という時刻は、 ビデ ォストリーム streamsが多重化されているクリップストリームフアイ ル" 00003.PS"に対応する第 2 6図 Aおよび第 2 6図 Bのクリップ情報 ファイル" 00003. CLP"において、 クリップストリームファイル" 00003. PS"の先頭の時刻を表す present at ion— st art一 timeに記述されている時 刻 90， 000に一致する。
同様に、 OxBDとなっている stream— idおよび 0x00となっている priva te_stream_idで特定されるオーディォストリーム stream#2について記 述されている第 4 2図下側の 3セットの pts一 change一 pointおよび Dyna micInfoOのうちの 1セット目では、 pts_change— pointが 90， 000にな つている。 そして、 この 90, 000という時刻は、 オーディオストリーム stream が多重化されているクリップストリームファイル" 00003. PS" に対応する第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファイル" 000 03.CLP"において、 クリップストリームファイル" 00003.PS"の先頭の 時刻を表す present at ion_s tarし timeに記述されている時刻 90， 000に 一致する。
プレイヤ制御モジュール 2 1 2は、 クリップストリームファイル" 0 0003. PS"の先頭の時刻を表す present at ion— starし timeに記述されて いる時刻 90， 000に一致する pts— change— pointを、 初期値として認識す る。 従って、 第 4 2図上側の 2セットの pts— change— pointおよび Dyna micInfoOのうちの 1セット目の pts一 change_pointと、 第 42図下铺 の 3セットの pts— change— pointおよび DynamicInfoOのうちの 1セッ ト目の pts_change_pointが、 初期値として認識される。
そして、 プレイヤ制御モジュール 2 1 2は、 クリップストリ一ムフ アイル" 00003.PS"の再生が開始される前に （第 30図のステップ S 1 26で） 、 初期値として認識した pts_change_pointとセットになって いる DynamicInfoOにしたがって、 対応するエレメン夕リストリーム の出力属性を指示する。
即ち、 OxEOとなっている stream— idで特定されるビデオストリーム s tream#0については、 第 42図上側で、 初期値である 90， 000になって いる pts_change一 pointとセットになっている DynamicInfoOにおいて 、 display_aspecし ratioが' 4:3'になっている。 この場合、 プレイヤ 制御モジュール 2 1 2は、 display— aspecし ratioが' 4:3'になってい る旨、 即ち、 ビデオストリーム stream#0が、 4 : 3のアスペクト比の ビデオデ一夕である旨の出力属性の情報を、 グラフィクス処理モジュ ール 2' 1 9を制御する。
また、 OxBDとなっている s tream_i dおよび 0x00となっている pr i va t e _stream— idで特定されるオーディォストリーム stream については、 第 4 2図下側で、 初期値である 90， 000になってぃる 13_(^&1^6_0(^1^ とセットになっている DynamicInfoOにおいて、 channel— ass ignment が' Dual'になっている。 この場合、 プレイヤ制御モジュール 2 1 2は 、 channel— assignmentが' Dual'になっている旨、 即ち、 オーディオス トリーム stream#2が、 デュアルのオーディォデータである旨の出力属 性の情報を、 オーディオ出力モジュール 22 1に供給する。
ここで、 第 30図のステップ S 1 2 6では、 以上のような初期値と しての pts change— pointを対象とした出力属性の制御処理が行われる その後、 プレイヤ制御モジュール 2 1 2は、 ビデオストリーム stre am#0についての第 42図上側の 2つの pts— change_pointである 90， 000 および 54， 090， 000と、 オーディォストリーム stream#2についての第 4 2図下側の 3つの pts一 change_pointである 90， 000， 27,090,000、 およ び 32, 490, 000のうちの、 初期値 90， 000以外の時刻である {27， 090， 000} , {32,490,000}, {54， 090， 000}を、 「DynamicInfo()処理」 の属性の 時刻である旨とともに、 デコード制御モジュール 2 1 4に渡す （ステ ップ S 3 2 0 ) 。
デコード制御モジュール 2 1 4は、 プレイヤ制御モジュール 2 1 2 からの、 「DynamicInfo()処理」 の属性の時刻 {27， 090， 000}， {32, 490 ，000}， {54, 090， 000}を受信し、 さらに、 ビデオストリーム stream#0 およびオーディォストリーム stream の再生 （クリップストリ一ムフ アイル" 00003.PS"を再生する 2番目の PlayList#lの PlayItem#0の再生 ) の開始後、 計時部 2 14 Aによって計時されている現在時刻の監視 を開 する。
そして、 デコード制御モジュール 2 1 4は、 現在時刻が、 「Dynami clnfoO処理」 の属性の時刻 {27，090，000}, {32,490,000}, {54,090, 0 00}のうちのいずれかに一致した場合、 その現在時刻と一致した 「Dyn amicInfoO処理」 の属性の時刻であ Dynamiclnfo時刻を、 プレイヤ 制御モジュール 2 1 2に供給する （ステップ S 3 2 1 ) 。
即ち、 例えば、 現在時刻が、 27，090 000になったとすると、 デコー ド制御モジュール 2 1 4は、 「DynamicInfo()処理」 の属性の時刻の うちの、 現在時刻と一致する 27， 090， 000を、 Dynamiclnfo時刻として 、 プレイヤ制御モジュール 2 1 2に供給する。
プレイヤ制御モジュール 2 1 2は、 デコード制御モジュール 2 14 からの1^1^1111(：11^0時刻でぁる27，090，000を受信し、 ビデオストリー ム stream#0についての第 42図上側の 2つの pts一 change— pointと、 ォ 一ディォストリーム stream#2についての第 42図下側の 3つの pts_ch ange_pointとの中から、 Dynamic Info時刻である 27, 090, 000に一致す る pts_change_pointを調査し、 その 27， 090, 000に一致する pts_change — pointとセットになっている DynamicInfo()、 即ち、 オーディオスト リーム stream#2についての第 42図下側の 2番目の Dynamic Info 0を 、 処理対象 DynamicInfoOとして認識する （ステップ S 3 2 2 ) 。 処理対象 DynamicInfoOが、 ビデオストリームについての Dynamicln fo()である場合、 プレイヤ制御モジュール 2 1 2は、 処理対象 Dynami clnfoOに記述されている出力属性を、 グラフィクス処理モジュール 2 1 9に供給する （ステップ S 32 3 ) 。 また、 処理対象 Dynamiclnf οθが、 オーディォストリームについての DynamicInfoOである場合、 プレイヤ制御モジュール 2 1 2は、 処理対象 DynamicInfoOに記述さ れている出力属性を、 オーディオ出力モジュール 22 1に供給する （ ステップ S 3 2 3 ) 。
グラフィクス処理モジュール 2 1 9は、 プレイヤ制御モジュール 2 12から出力属性が供給されると、 その出力属性にしたがって、 ビデ ォデータの出力の制御を開始する （ステップ S 324) 。
即ち、 グラフィクス処理モジュール 2 1 9は、 例えば、 プレイヤ制 御モジュール 2 1 2からの出力属性が表す、 ビデオデータのァスぺク ト比の指示（display—aspecし ratio (第 1 3図） ）と、 第 1図のビデオ 出力端子 1 2 0に接続されたビデオ出力装置のァスぺクト比とに基づ いて、 ビデオ出力モジュール 220に出力するビデオデータのァスぺ クト比の変換を行う。
具体的には、 例えば、 ビデオ出力装置のアスペクト比が 16:9である 場合において、 出力属性としてのビデオデ一夕のァスぺクト比の指示 が 4 :3のァスぺクト比を表しているときには、 グラフィクス処理モジ ユール 2 1 9は、 ビデオ出力モジュール 2 2 0に出力するビデオデ一 夕を、 横方向にスクイーズ処理し、 左右に黒味を入れて出力する。 ま た、 例えば、 ビデオ出力装置のアスペクト比が 4:3である場合におい て、 出力属性としてのビデオデータのァスぺクト比の指示が 16:9のァ スぺクト比を表しているときには、 グラフィクス処理モジュール 2 1 9は、 ビデオ出力モジュ一ル 2 2 0に出力するビデオデータを、 縦方 向にスクイーズ処理し、 上下に黒味を入れて出力する。 さらに、 例え ば、 ビデオ出力装置のアスペクト比と、 出力属性としてのビデオデー 夕のアスペクト比の指示が表すアスペクト比とが、 いずれも、 4:3や 1 6:9で、 同一である場合、 グラフィクス処理モジュール 2 1 9は、 ビ デォ出力モジュール 2 2 0に出力するビデオデータを、 スクイーズ処 理することなく、 そのまま出力する。
ここで、 第 42図上側において、 OxEOとなっている stream_idで特 定されるビデオストリーム streamsについて記述されている 2セット の pts— change_pointおよび DynamicInfoOによれば、 ビデオス卜リー ム3 6&111#0の再生開始時でぁる時刻90，000から、 時刻 54， 090, 000の直 前までは、 ビデオストリーム stream#0から、 4 ： 3のアスペクト比の ビデオデータが得られる。 そして、 時刻 54, 090， 000以後は、 ビデオス トリ一ム stream#0から、 1 6 ： 9のアスペクト比のビデオデータが得 られる。 .
従って、 例えば、 第 1図のビデオ出力端子 1 2 0に接続されたビデ ォ出力装置のァスぺクト比が 4 :3であるとすると、 グラフィクス処理 モジュール 2 1 9では、 時刻 90,000から時刻 54, 090, 000の直前までは 、 ビデオストリーム stream#0から得られる 4 ： 3のアスペクト比のビ デォデータが、 そのまま 4 ： 3のアスペクト比のビデオ出力装置に供 給されて表示される。
そして、 時刻 54， 090， 000以後は、 ビデオストリーム s t ream#0から得 られる 1 6 ： 9のアスペクト比のビデオデータが、 縦方向にスクイ一 ズ処理され、 さらに、 上下に黒味が入った 4 ： 3のアスペクト比のビ デォ信号に変換され、 4 ： 3のアスペクト比のビデオ出力装置に供給 されて表示される。
一方、 オーディオ出力モジュール 2 2 1は、 プレイヤ制御モジユー ル 2 1 2から出力属性が供給されると、 その出力属性にしたがって、 オーディオデータの出力の制御を開始する （ステップ S 3 2 4 ) 。
即ち、 オーディオ出力モジュール 2 2 1は、 例えば、 プレイヤ制御 モジュール 2 1 2からの出力属性が表す、 オーディオデータのチヤネ ル割り当ての指示（channe l— as s ignmen t (第 1 3図） ）と、 ユーザがリ モコンを操作することによって入力インタ一フェース 1 1 5 (第 1図 ) を介してプレイヤ制御モジュール 2 1 2から供給される音声出力モ ードとに基づいて、 オーディオデコーダ制御モジュール 2 1 7からの オーディオデータを処理し、 オーディオ出力端子 1 2 1 (第 1図） に 出力する。
具体的には、 例えば、 出力属性が表すオーディオデータのチャネル 割り当ての指示が、 左チャネルが 「主音声」 のオーディオデータで、 右チャネルの 「副音声」 のオーディオデータであるデュアル（Dual) ( ニケ国語） モードを表している場合、 オーディオ出力モジュール 2 2 1は、 プレイヤ制御モジュール 2 1 2から供給される音声出力モード にしたがって、 オーディオデコーダ制御モジュール 2 1 7からのォ一 ディォデ一夕を処理して、 オーディオ出力端子 1 2 1に出力する。 即ち、 音声出力モードとして、 例えば、 「主音声」 が指定されてい るときには、 オーディオ出力モジュール 2 2 1は、 オーディオデコー ダ制御モジュール 2 1 7からのオーディオデ一夕のうちの左チャネル のオーディォデ一夕を、 右チャネルのオーディォデータとしてコピー し、 その左チャネルと右チャネルのオーディォデ一タ ( 「主音声」 の オーディオデータ） を、 オーディオ出力端子 1 2 1に出力する。 また 、 音声出力モードとして、 「副音声」 が指定されているときには、 ォ —ディォ出力モジュール 2 2 1は、 オーディオデコーダ制御モジユー ル 2 1 7からのオーディォデ一夕のうちの右チャネルのオーディォデ. 一夕を、 左チャネルのオーディォデ一夕としてコピーし、 その左チヤ ネルと右チャネルのオーディオデ一タ （ 「副音声」 のオーディオデー 夕） を、 オーディオ出力端子 1 2 1に出力する。 さらに、 音声出力モ ードとして、 「主 ·副」 が指定されているときには、 ォ一ディォ出力 モジュール 2 2 1は、 オーディォデコーダ制御モジュール 2 1 7から のオーディオデータを、 そのまま、 オーディオ出力端子 1 2 1に出力 する。
ま 、 例えば、 出力属性が表すオーディオデ一夕のチャネル割り当 ての指示が、 ステレオ（Stereo)モードを表している場合、 オーディオ 出力モジュール 2 2 1は、 プレイヤ制御モジュール 2 1 2から供給さ れる音声出力モードにかかわらず、 オーディォデコーダ制御モジユー ル 2 1 7からのオーディオデータを、 そのまま、 オーディオ出力端子 1 2 1に出力する。
ここで、 第 42図下側において、 OxBDとなっている stream— idおよ び 0x00となっている private— st ream_idで特定されるオーディォスト リーム stream#2について記述されている 3セッ卜の pts— change— point および DynamicInfoOによれば、 オーディオストリーム stream の再 生開始時である時刻 90, 000から、 時刻 27, 090, 000の直前までは、 ォ一 ディォストリーム stream から、 デュアルのオーディォデータが得ら れる。 また、 時刻 27,090， 000から、 時刻 32,490, 000の直前までは、 ォ —ディォストリ一ム stream#2から、 ステレオのオーディォデ一夕が得 られ、 時刻 32,490， 000以後は、 オーディオストリーム stream#2から、 デュアルのオーディォデータが得られる。
従って、 例えば、 音声出力モードとして、 「主音声」 が指定されて いるとすると、 オーディオ出力出力モジュール 2 2 1では、 時刻 90，0 00から、 時刻 27， 090,000の直前までは、 オーディオストリーム stream から得られるデュアルのオーディォデ一夕のうちの左チャネルのォ 一ディォデータが、 右チャネルのオーディオデータとしてコピーされ 、 その左チャネルと右チャネルのオーディオデータが、 オーディオ出 力端子 1 2 1に出力される。
また、 時刻 27, 090， 000から、 時刻 32， 490， 000の直前までは、 オーデ ィォストリーム stream#2から得られるステレオのォ一ディォデータが 、 そのまま、 オーディオ出力端子 1 2 1に出力される。 ·
そして、 時刻 32， 490, 000以後は、 オーディオストリーム stream#2か ら得られるデュアルのオーディォデータのうちの左チャネルのオーデ ィォデ一夕が、 右チャネルのオーディォデ一夕としてコピーされ、 そ の左チャネルと右チャネルのオーディォデ一夕が、 オーディォ出力端 子 1 2 1に出力される。
以上のように、 出力属性の制御処理では、 クリップストリ一ムファ ィルに多重化されているエレメンタリストリームごとに、 そのエレメ ン夕リストリ一ムの再生時刻を表す pts— change— pointと、 そのエレメ ン夕リストリームの出力属性を含む DynamicInfoOとのセットを 0セ ット以上含むクリップ情報ファイル ClipO (第 1 0図） の記述に基づ き、 再生中のエレメン夕リストリームの再生時刻が、 pts— change— poi nUこ一致するか否かが判定される。 そして、 再生中のエレメンタリス トリームの再生時刻が、 pt s_change一 po intに一致する場合、 その pts一 change_pointとセッ卜になっている Dynami cInf o Oが認識され、 その 認識された Dynami c Info Oに含まれる出力属性にしたがって、 再生中 のエレメン夕リストリームの出力が制御される。 従って、 エレメン夕 リストリームの再生時刻と出力属性に応じて、 そのエレメン夕リス卜 リームの出力を制御することが可能となる。
[字幕表示制御処理]
次に、 第 4 3図のフローチャートを参照して、 字幕ストリームに対 応する字幕データの表示を制御する字幕表示制御処理について説明す る。
P l ayL i s t O (第 5図） （の P l ayl tem O ) の再生が開始されると、 プ レイヤ制御モジュール 2 1 2は、 ステップ S 3 4 1において、 グラフ イクス処理モジュール 2 1 9に対する字幕データの表示方式の指示を 初期化する。 即ち、 プレイヤ制御モジュール 2 1 2は、 字幕データの 表示方式をデフォルトの表示方式とするように、 グラフィクス処理モ ジュール 2 1 9を制御する。 なお、 ステップ S 3 4 1で行われる表示 方式の指示の初期化は、 第 3 0図の 1 2 7で説明した表示方式の指示 の初期化に対応する。
ステップ S 3 4 1の処理後は、 ステップ S 3 4 2に進み、 プレイヤ 制御モジュール 2 1 2は、 ュ一ザがリモコンを操作することにより入 力インタ一フェース 1 1 5から、 字幕デ一夕の表示について、 新たな 表示方式の指示があつたかどうかを判定する。
ステップ S 3 4 2において、 新たな表示方式の指示があつたと判定 された場合、 ステップ S 3 4 3に進み、 プレイヤ制御モジュール 2 1 2は、 字幕ストリーム （に対応する字幕データ） を、 現在再生してい るかどうかを判定する。
ステップ S 343において、 字幕ストリームが再生されていないと 判定された場合、 ステップ S 342に戻る。
また、 ステップ S 343において、 字幕ストリームが再生されてい ると判定された場合、 ステップ S 345に進み、 プレイヤ制御モジュ ール 2 1 2は、 新たな表示方式の指示が、 デフォルトの表示方式の指 示であるかどうかを判定する。 ステップ S 343において、 新たな表 示方式の指示が、 デフォルトの表示方式の指示であると判定された場 合、 ステップ S 341に戻り、 上述したように、 プレイヤ制御モジュ ール 2 1 2は、 字幕データの表示方式をデフォルトの表示方式とする ように、 グラフィクス処理モジュール 2 1 9を制御する。
一方、 ステップ S 345において、 新たな表示方式の指示が、 デフ オルトの表示方式の指示でないと判定された場合、 即ち、 新たな表示 方式の指示が、 例えば、 字幕データを拡大や縮小して表示する、 ある いは明るさを変えて見やすくする等、 デフォルトでない表示方式の指 示である場合、 ステップ S 346に進み、 プレイヤ制御モジュール 2 1 2は、 現在再生している字幕ストリームが多重化されたクリップス トリームファイルに対応するクリップ情報ファイル Clip 0 (第 1 0図 ) の StaticInfoO (第 1 2図） のうちの、 現在再生している字幕スト リームについての StaticInfoOを取得し、 ステップ S 347に進む。 ステップ S 347では、 プレイヤ制御モジュール 2 1 2は、 ステツ プ S 346で取得した StaticInfoOの configurable一 flagを判定する ステップ S 347において、 conf igurable_f lagが、 字幕デ一夕の 表示方式の変更を許可しない旨の 0になっていると判定された場合、 ステップ S 348に進み、 プレイヤ制御モジュール 2 1 2は、 グラフ イクス処理モジュール 2 1 9を制御することにより、 出力ビデオデー 夕に、 字幕データの表示方式を変更することができない旨のエラーメ ッセージをオーバーレイさせ、 ステップ S 3 4 2に戻る。 これにより 、 エラ一メッセージが表示される。
一方、 ステップ S 3 4 7において、 conf igurab l ej gが、 字幕デ 一夕の表示方式の変更を許可する旨の 1になっていると判定された場 合、 ステップ S 3 4 9に進み、 プレイヤ制御モジュール 2 1 2は、 ュ —ザがリモコンを操作することにより入力インターフェース 1 1 5か ら供給された新たな表示方式の指示を、 グラフィクス処理モジュール 2 1 9に供給して、 ステップ S 3 5 0に進む。
ステツプ S 3 5 0では、 グラフィクス処理モジュール 2 1 9は、 字 幕デコ一ダ制御モジュール 2 1 8から供給される字幕データを、 直前 のステップ S 3 4 9でプレイヤ制御モジュール 2 1 2から供給された 表示方式の指示にしたがって拡大または縮小等あるいは明るさを変え る等の処理を開始し、 ステップ S 3 4 2に戻る。 これにより、 字幕デ 一夕は、 ユーザがリモコンを操作することによつて指示した表示方式 にしたがった表示サイズや、 表示位置、 表示色等で表示される。
一方、 ステップ S 3 4 2において、 新たな表示方式の指示がなかつ たと判定された場合、 ステップ S 3 5 1に進み、 プレイヤ制御モジュ ール 2 1 2は、 第 3 1図で説明した P l ayl t em Oの乗り換えが行われた かどうかを判定し、 行われていないと判定した場合、 ステップ S 3 4 2に戻る。 '
また、 ステップ S 3 5 1において、 P l ayl t em Oの乗り換えが行われ たと判定された場合、 ステップ S 3 4 1に戻り、 上述したように、 プ レイヤ制御モジュール 2 1 2は、 字幕データの表示方式をデフォルト の表示方式とするように、 グラフィクス処理モジュール 2 1 9を制御 する。 即ち、 この場合、 PlayltemOの乗り換えが行われたときには、 字幕データの表示方式は、 デフォルトの表示方式に戻される。
以上のように、 字幕表示制御処理においては、 字幕ストリームの CO nfigurable_flagが、 表示方式の変更を許可する旨の 1になっている場 合にのみ、 その字幕ストリームに対応する字幕データの表示方式が、 例えば、 ユーザがリモコンを操作することにより入力される表示方式 の指示に応じて変更される。
従って、 例えば、 第 2 6図 Aおよび第 2 6図 Bに示したクリップ情 報ファイル" 00001. CLP"によれば、 対応するクリップストリ一ムファ ィル" 00001.PS"に多重化されている 4本のエレメンタリストリ一ムの うちの 3本目のエレメン夕リストリームである字幕ストリ一ム stream #2についての configurable— agは、 表示方式の変更を許可しない旨 の 0になっているので、 その字幕ストリーム stream#2が表示されてい るときに、 ユーザが字幕の表示を変更するようにリモコンを操作して も、 その表示は変更されない。
一方、 例えば、 クリップストリームファイル" 00001.PS"に多重化さ れている 4本のエレメンタリストリームのうちの 4本目のエレメン夕 リストリームである字幕ストリーム stream#3についての configurable —flagは、 表示方式の変更を許可する旨の 1になっているので、 その字 幕ストリーム stream#3が表示されているときに、 ユーザが字幕の表示 を変更するようにリモコンを操作すると、 その操作に応じて、 字幕の 表示サイズ等が変更される。 ·
即ち、 例えば、 いま、 第 2 5図の 1番目の PlayList#0の 1番目の P1 ayltem#0にしたがい、 クリップストリームファイル" 00001. PS"が再生 されているとする。 また、 第 2 6図 Aおよび第 2 6図 Bでクリップ情 報ファイル" 00001. CLP"について説明したように、 クリップストリー ムファイル" 00001.PS"に多重化されている 4本のエレメンタリストリ ームのうちの、 3本目と 4本目が字幕ストリームであるが、 その 3本 目の字幕ストリーム stream#2と、 4本目の字幕ストリーム stream#3の うちの、 例えば、 3本目の字幕ストリーム stream#2が、 現在再生され ているとする。
ユーザが、 リモコンを操作することにより、 字幕の表示方式の指示 を入力すると （ステップ S 342) 、 その表示方式の指示は、 入カイ ン夕ーフェース 1 1 5 (第 1図） からプレイヤ制御モジュール 2 1 2 に供給される。 プレイヤ制御モジュール 2 1 2は、 表示方式の指示が 供給されると、 再生中の字幕ストリームに対応する StaticInfoO (第 1 0図） を、 クリップ情報ファイルから探し出す （ステップ S 346 即ち、 いまの場合、 再 中の字幕ストリームは、 クリップストリ一 ムファイル" 00001.PS"に多重化されている 3本目の字幕ストリーム st ream#2であり、 プレイヤ制御モジュール 2 1 2は、 対応するクリップ 情報ファイル" 00001. CLP"から、 3本目の字幕ストリーム stream#2に ついての S ticInfoOを探し出す。
さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 6図 Aおよび第 2 6図 Bにおいて 3本目の字幕ストリ一ム stream#2についての Static In fo()に記述されている、 0になっている configurable— flagを判定し （ ステップ S 347 ) 、 これにより、 3本目の字幕ストリーム stream#2 については、 表示方式の変更が許可されていないことを認識する。 この場合、 プレイヤ制御モジュール 2 1 2は、 再生中の字幕ストリ —ム （に対応する字幕データ） が拡大縮小等に対応していないと判断 し、 グラフィクス処理モジュール 2 1 9を制御することにより、 その 旨のエラーメッセ一ジを生成させ （ステップ S 348) 、 ビデオデー 夕にオーバーレイして出力させる。
一方、 クリップストリームファイル" 00001.PS"に多重化されている 4本のエレメンタリストリームの 3本目の字幕ストリーム stream#2.と 、 4本目の字幕ストリーム stream#3のうちの、 3本目の字幕ストリー ム stream#2ではなく、 4本目の字幕ストリーム stream^が、 現在再生 されている場合には、 ユーザがリモコンを操作することによって表示 方式の指示の供給を受けたプレイヤ制御モジュール 2 1 2は、 対応す るクリップ情報ファイル" 00001. CLP"から、 4本目の字幕ストリーム s tream#3についての Static Info 0を探し出す。
さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 6図 Aおよび第 2 6図 Bにおいて 4本目の字幕ストリーム st ream#3についての Static In fo()に記述されている、 1になっている configurable—flagを判定し （ ステップ S 347) 、 これにより、 4本目の字幕ストリーム stream#3 については、 表示方式の変更が許可されていることを認識する。
この場合、 プレイヤ制御モジュール 2 1 2は、 再生中の字幕ストリ —ム '（に対応する字幕データ） が拡大縮小等に対応していると判断し 、 ユーザがリモコンを操作することによって供給された表示方式の指 示を、 グラフィクス処理モジュール 2 1 9に供給する （ステップ S 3 49) 。
これにより、 その後、 グラフィックス処理制御モジュール 2 1 9は 、 プレイヤ制御モジュール 2 1 2からの表示方式の指示にしたがい、 字幕デコーダ制御モジュール 2 1 8かちの字幕データを拡大または縮 小等し、 ビデオデコーダ制御モジュール 2 1 6からのビデオデータに オーバーレイして出力する。
なお、 プレイヤ制御モジュール 2 1 2は、 PlayListOの最初の Play 11 em 0の再生開始時に、 グラフィクス処理モジュール 2 1 9に対する 字幕デ一夕の表示方式の指示を初期化する （ステップ S 341) 。 即 ち、 プレイヤ制御モジュール 212は、 字幕データの表示方式をデフ オルトの表示方式とするように、 グラフィクス処理モジュール 219 を制御する。
さらに、 プレイヤ制御モジュール 212は、 PlayltemOの乗り換え 時にも、 グラフィクス処理モジュール 219に対する字幕データの表 示方式の指示を初期化する （ステップ S 341， S 351) 。
但し、 PlayltemOの乗り換え時においては、 その後に新たに再生さ れる PlayltemOにしたがって再生される新たな字幕ストリームについ ての configurable— flagを調査し、 conf igurable_f lagが 0である場合 には、 グラフィクス処理モジュール 219に対する字幕デ一夕の表示 方式の指示を初期化し、 configurable— flagが 1である場合には、 ダラ フィクス処理モジュール 219に対する表示方式の指示を、 Playltem 0の乗り換え前のまま維持するようにすることが可能である。
また、 第 43図の字幕表示制御処理では、 ユーザがリモコンを操作 することにより、 新たな表示方式の指示が入力された場合に、 その新 たな表示方式の指示を、 グラフィクス処理モジュール 219に供給す るようにしたが （ステップ S 349) 、 表示方式の指示は、 例えば、 メモリ 1 13 (第 1図） を構成する不揮発性メモリに記憶し、 その不 揮発性メモリに記憶された表示方式の指示を、 グラフィクス処理モジ ユール 219に供給するようにすることが可能である。
即ち、 例えば、 第 1図のディスク装置の初期設定として、 不揮発性 メモリに、 ユーザ設定の表示方式の指示を記憶させておき、 ユーザが リモコンを操作することにより、 新たな表示方式の指示が入力された 場合には、 不揮発性メモリに記憶された表示方式の指示を、 新たな表 示方式の指示に更新する一方、 その不揮発性メモリに記憶された表示 方式の指示を、 グラフィクス処理モジュール 2 19に供給するように することが可能である。 この場合、 不揮発性メモリには、 前回の再生 終了時における表示方式の指示が保持されるので、 次回の PlayListO の再生時に、 ユーザがリモコンを操作することにより、 前回の再生終 了時における表示方式の指示を入力しなくても、 その表示方式で、 字 幕データの表示が開始される。
なお、 この場合、 不揮発性メモリに記憶させる表示方式の指示には 、 例えば、 字幕データを拡大または縮小するときの拡大率または縮小 率等が含まれるものとする。
以上のように、 字幕表示制御処理によれば、 クリップ情報ファイル ClipO (第 10図） に含まれる、 エレメンタリストリームごとの、 そ のエレメン夕リストリームの再生中に変化しない S ticInfoOのうち の、 字幕データの SUticInfoOが取得され、 その StaticInfoOに含ま れる、 字幕デ一夕の表示をデフォルトの表示方式から変更することを 許可するか否かを表す configurable_flagに基づき、 再生'中の字幕デ 一夕の表示をデフオルトの表示方式から変更することが許可されてい るか否かが判定される。 そして、 再生中の字幕データの表示をデフォ ルトの表示方式から変更することが許可されている場合には、 字幕デ 一夕の表示方式の変更の指示にしたがって、 その字幕デ一夕の表示処 理、 即ち、 例えば、 字幕データを拡大または縮小、 あるいは表示色を 変更する等して表示する処理が行われる。 従って、 字幕データの表示 方式の変更を制御することができる。 '
[キヤプチヤ制御処理]
次に、 第 44図のフローチャートを参照して、 ビデオストリームに 対応するビデオデータのキヤプチヤを制御するキャプチャ制御処理に ついて説明する。 なお、 第 44図には、 キヤプチャ制御処理を説明す るフローチャートとともに、 そのキヤプチャ制御処理によってキヤプ チヤされたビデオデータを 2次利用する処理の例であるバックグラウ ンド スクリーンセ一バ処理を説明するフローチャートも、 図示して ある。
キヤプチャ制御処理は、 例えば、 ュ一ザがリモコンを操作すること により、 ビデオデータのキヤプチャを指示するキヤプチャ指示が、 入 力インターフェース 1 15 (第 1図） を介して、 プレイヤ制御モジュ —ル 212に供給されると開始される。
即ち、 キヤプチャ制御処理では、 まず最初に、 ステップ S 371に おいて、 プレイヤ制御モジュール 212が、 ビデオストリ一ムを再生 中であるかどうかを判定し、 再生中でないと判定した場合、 キヤプチ ャ制御処理は終了する。
一方、 ステップ S 371において、 ビデオストリームを再生中であ ると判定された場合、 ステップ S 372に進み、 プレイヤ制御モジュ ール 212は、 再生中のビデオストリームに対応する PlayListO (第 5図） から、 capture— enable_flag_PlayListを取得するとともに、 再 生中のビデオストリームに対応するクリップ情報ファイル ClipO (第 10図） から、 capture— enable_nag_Clipを取得する。
ここで、 PlayList 0における capture_enable_f lag— PlayListは、 第 5図で説明したように、 その PlayListOによって再生されるビデオス トリームに対応するビデオデータ （PlayListOに属するビデオデータ ) の 2次利用を許可するか否かを表す。' また、 クリップ情報ファイル CI ip()における capture— enable— flag_Clipは、 第 10図で説明したよ うに、 そのクリップ情報ファイル ClipOに対応するクリップストリ一 ムファイルに格納されているビデオストリームに対応するビデオデ一 夕の 2次利用を許可するか否か 表す。 ステップ S 3 7 2の処理後は、 ステップ S 3 7 3に進み、 プレイヤ 制御モジュール 2 1 2は、 直前のステップ S 3 7 3で取得された capt ure_enab 1 e_f 1 ag_P 1 ayL i s tと c apture_enab 1 e_f 1 ag_C 1 i pとに ¾つき、 キヤプチャ指示が入力インターフェース 1 1 5 (第 1図） から入力さ れたときに再生されていたビデオデ一夕のピクチャのキヤプチャの可 否を判定する。
ステップ S 3 7 3において、 キヤプチャ指示が入カインターフェ一 ス 1 1 5から入力されたときに再生されていたビデオデータのピクチ ャのキヤプチヤが不可であると判定された場合、 即ち、 直前のステツ プ S 3 7 3で取得された capture一 enable_flag_PlayListまたは captur e—enable_f lag— Clipのうちの少なくとも一方が、 ビデオデータの 2次 利用を許可しない旨の.0になっている場合、 ステップ S 374に進み 、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジュール 2 1 9を制御することにより、 ビデオデータのキヤプチヤが不可である 旨のエラ一メッセージをオーバ一レイさせ、 キヤプチャ制御処理を終 了する。 これにより、 エラーメッセージが表示される。
一方、 ステップ S 37 3において、 キヤプチャ指示が入力インター フェース 1 1 5から入力されたときに再生されていたビデオデータの ピクチャのキヤプチヤが可能であると判定された場合、 即ち、 直前の ステップ S 37 3で取得された capture一 enable_flag_PlayListおよび capture_enable_flag_Clipの両方が、 ビデオデ一夕の 2次利用を許可 する旨の 1になっている場合、 ステップ S 3 7 5に進み、 プレイヤ制 御モジュール 2 1 2は、 キヤプチャ指示が入力イン夕一フェース 1 1 5から入力されたときに再生されていたビデオデータのピクチャのキ ャプチヤの指示を、 グラフィクス処理モジュール 2 1 9に供給し、 ス テツプ S 376に進む。 ステップ S 3 7 6では、 グラフィクス処理モジュール 2 1 9は、 プ レイヤ制御モジュール 2 1 2からのキヤプチヤの指示にしたがい、 ビ デォデコーダ制御モジュール 2 1 6からのビデオデータのピクチャを キヤプチヤし、 メモリ 1 1 3 (第 1図） に記憶させて、 キヤプチャ制 御処理を終了する。 なお、 capture— enable— flagが複数ビット構成に なっており、 使用条件の制約が行われている場合にはこの時点で対応 が行われる。 すなわちキヤプチャした画像の大きさに制限がある場合 には、. この時点で縮小した画像がキヤプチャされる。 また使用するァ プリケーションに制約がある場合にはその旨を知らせるフラグが同時 に記録される。
以上のように、 キヤプチャ制御処理では、 ユーザからのキヤプチャ 指示があつたときに再生されているビデオストリームに対応する Play ListO (第 5図） とクリップ情報ファイル ClipO (第 1 0図） それぞ れの capture— enable— flag— PlayListと capture— enable— flag_Cl ipとの 論理積をとつて、 その論理積が 1である場合、 即ち、 capture— enable一 flag— PlayListと capture— enable_f g— Clipが、 いずれも、 2次利用 を許可する 1になっている場合にのみ、 ビデオデータの 2次利用が可 能であると判断され、 キヤプチヤが行われる。
従って、 例えば、 第 2 5図における 1番目の PlayList#0の 1番目の PlayItem#0にしたがって、 ビデオストリームの再生、 即ち、 クリップ ストリームファイル" 00001.PS"に多重化されたビデオストリームの再 生が行われている場合に、 ユーザからのキヤプチャ指示があつたとき には、 1番目の PlayList#0における capture— enable_flag— PlayListは 1であり、 その 1番目の PlayItem#0によって再生されるクリップスト リームファイル" 00001.PS"に対応する第 2 6図 Aおよび第 26図 Bの クリップ情報ファイル" 00001. CLP"における capture一 enable— flag Cli pは 1であるから、 再生中のビデオデータ （クリップストリームフアイ ル" 00001.PS"に多重化されたビデオス卜リームに対応するビデオデー 夕） の 2次利用は可能であると判断され、 キヤプチヤが行われる。 また、 例えば、 第 2 5図における 1番目の PlayList#0の 2番目の P1 ayltem#lにしたがって、 ビデオストリームの再生、 即ち、 クリップス トリームファイル" 00002.PS"に多重化されたビデオストリームの再生 が行われている場合に、 ユーザからのキヤプチャ指示があつたときに は、 1番目の PlayList#0における capture__enable_nag— PlayListは 1 であり、 その 2番目の Playltem#lによって再生されるクリップストリ —ムファイル" 00002.PS"に対応する第 2 6図 Aおよび第 26図 Bのク リップ情報ファイル" 00002. CLP"における capture— enable_flag_Clip は 0であるから、 再生中のビデオデータ （クリップストリ一ムフアイ ル" 00002.PS"に多重化されたビデオストリームに対応するビデオデ一 夕） の 2次利用は不可であると判断され、 キヤプチヤが行われない。 さらに、 例えば、 第 25図における 2番目の PlayListMの Playltem #0にしたがって、 ビデオストリームの再生、 即ち、 クリップストリー ムフアイル" 00003. PS"に多重化されたビデオス卜リームの再生が行わ れている場合に、 ユーザからのキヤプチャ指示があったときには、 2 番目の PlayList#lにおける capture一 enable_f lag_PlayListは 0であり 、 2番目の PlayList#lの PlayItem#0によって再生されるクリップスト リームファイル" 00003.PS"に対応する第 26図 Aおよび第 2 6図 Bの クリップ情報ファイル" 00003. CLP"における capture一 enable—flag一 Cli pは 1であるから、 再生中のビデオデ一夕 （クリップストリームフアイ ル" 00003. PS"に多重化されたビデオストリ一ムに対応するビデオデ一 夕） の 2次利用は不可であると判断され、 キヤプチャは行われない。 なお、 この場合、 2番目の PlayList#lにおける capture enable f la g_PlayListが 0であることが確認された時点で、 ビデオデータの 2k、 利用は不可であると判断することができるので、 2番目の PlayListifl の PlayItem#0によって再生されるクリップストリームファイル" 00003 • PS"に対応する第 2 6図 Aおよび第 26図 Bのクリップ情報ファイル " 00003. CLP"における capture_enable_nag— Clipの確認は省略するこ とができる。
キヤプチャ制御処理によってキヤプチヤされ、 メモリ 1 1 3に記憶 されたピクチャは、 バックグラウンド Zスクリーンセ一バ処理におい て 2次利用することができる。
バックグラウンド Zスクリーンセーバ処理は、 例えば、 プレイヤ制 御モジュール 2 1 2が動作しているが、 エレメン夕リストリームの再 生が行われていない状態、 即ち、 ディスクドライブ 1 0 2 (第 1図） にディスク 1 0 1が揷入されていない状態、 あるいはエレメン夕リス トリームの再生が終了した状態となったときなどに行われる。
即ち、 バックグラウンド /スクリーンセ一バ処理では、. ステップ S 38 ίにおいて、 プレイヤ制御モジュール 2 1 2は、 キヤプチャ制御 処理によってメモリ 1 1 3に記憶されたピクチャを表示するように、 グラフィクス処理モジュール 2 1 9を制御する。 グラフィクス処理モ ジュール 2 1 9は、 プレイヤ制御モジュール 2 1 2からの制御にした がい、 キヤプチャ制御処理によってメモリ 1 1 3に記憶されたピクチ ャを表示させる。
ここで、 グラフィクス処理モジュール 2 1 9において、 メモリ 1 1 3に記憶されたピクチャを静止画で表示させれば、 いわゆる壁紙（バ ックグラウンド）が実現され、 一定周期で拡大や縮小、 移動等しなが ら表示させれば、 スクリーンセーバーが実現される。 また、 キヤプチ ャ制御処理によってメモリ 1 1 3に記憶されたピクチャの表示を行う バックグラウンド/スクリーンセ一バ処理は、 プレイヤ制御モジユー ル 2 1 2ではなく、 他の独立したアプリケ一ションによって行うこと が可能である。
また、 このときメモリ 1 1 3に記憶されたピクチャに使用制限を表 すフラグが付加されている場合にはその制限に従う。
以上のように、 ビデオアクセスユニット単位より大きな単位の、 例 えば、 P 1 ayL i s t 0や P 1 ay 11 em 0に対応するビデオデータの 2次利用を 許可するか否かを表す、 再生中のビデオデータに対する capture— enab le— flag— PI ayL is tや capture— enable— flag— Clipが取得され、 その cap t ure— enable— flag— PlayListや capture— enable— flag— Clipに基づき、 再 生中のビデオデータの 2次利用が許可されているか否かが判定される 。 そして、 再生中のビデオデータの 2次利用が許可されていると判定 された場合、 再生中のビデオデータがキヤプチヤされ、 そのキヤプチ ャされたビデオデータを利用したバックグラウンド/スクリーンセー バ処理が実行される。 従って、 ビデオデータの 2次利用の制御が可能 となる。
なお、 第 44図のキヤプチャ制御処理では、 PlayListO (第 5図） において、 capture— enable一 flag一 PlayListを設けるとともに、 Playlt em()によって再生されるクリップストリームファイルに対応するクリ ップ情報ファイル ClipO (第 1 0図） において、 capture_enable_fla g_Cl ipを設け、 その capture— enable— flag— PlayListと cap t ure— enable — flag_Clipとの両方を用いて、 2次利用の許可 （可否） を判定するよ うにしたが、 PlayListO (第 5図） において、 capture— enable— flag一 PlayListを設けるだけか、 または、 PlayltemOによって再生されるク リップストリ一ムファイルに対応するクリップ情報ファイル ClipO ( 第 1 0図） において、 capture— enable— flag Clipを設けるだけにして 、 capture— enable— flag— PlayListまたは capture— enable— flag— CI ipの 一方だけを用いて、 2次利用の可否を判定するようにすることも可能 である。
また、 第 44図のキヤプチャ制御処理では、 ステップ S 376にお いて、 グラフィクス処理モジュール 2 1 9が、 プレイヤ制御モジユー ル 2 1 2からのキヤプチヤの指示にしたがい、 ビデオデコーダ制御モ ジュール 2 1 6からのビデオデ一夕のピクチャ、 即ち、 1つのピクチ ャだけをキヤプチヤするようにしたが、 その他、 複数のピクチャをキ ャプチヤすることも可能である。 つまり、 ビデオデコーダ制御モジュ ール 2 1 6が出力する時系列の複数のピクチャ （動画としての複数の ピクチャのシーケンス） をキヤプチヤすることが可能である。 この場 合、 一度にキヤプチャされるピクチャの枚数は、 例えば、 あらかじめ 決めておくことができる。 あるいは、 capture— enable_f lag— PlayList や capture— enable— flag— CI ipのビッ卜を ム¾して、 その capture— enab le一 flag— PlayListや capture一 enable— flag— Clipに、 一度にキヤプチャ 可能なピクチャの枚数の情報を含めるようにしても良い。
さらに、 上述の場合には、 ビデオデータの 2次利用を許可するか否 力の禾' J用許可 IS報、capture— enable— f lag— PlayList, capture— enable一 flag— Clip)を、 PlayList ().や、 クリップ情報ファイル ClipOに記述し 、 その利用許可情報によって、 PlayListOによって再生されるビデオ データ全体や、 クリップ情報ファイル ClipOに対応するクリップスト リームファイルに多重化されたビデオストリームに対応するビデオデ —夕全体についての 2次利用の可否を判定するようにしたが、 利用許 可情報は、 その他の任意の単位のビデオデータについて記述し、 その 利用許可情報によって、 任意の単位のビデデ一夕についての 2次利用 の可否を判定することが可能である。 即ち、 第 4 5図は、 利用許可情報が配置された private_stream2_PE S—payloadOのシンタクスを示しており、 第 46図は、 利用許可情報 が配置された au— information 0のシンタクスを示している。
なお、 第 4 5図の private_stream2_PES— payloadOは、 video_strea m_idの直前に、 利用許可情報としての capture— enable— flag_ps2が配 置されている他は、 第 2 3図における場合と同様に構成されている。 第 46図の au_information()も、 pic_s trueし copyの直前に、 利用許 可情報としての capture— enable— flag— AUが配置されている他は、 第 2 4図における場合と同様に構成されている。
第 4 5図の private— stream2— PES— payloadOに配置された capture_e nable— f lag— ps2は、 その private— stream2一 PES』ayload 0を含む priva te— stream— 2の PES— packet 0力、ら、 次の private— stream— 2の PES— packe tOの直前までに配置されるビデオストリームに対応するビデオデー 夕の 2次利用を許可するか否かを表す。 従って、 第 4 5図の private— s tream2_PES_payload 0に配置された cap t ure— enab 1 e_f 1 a.g_ps2によれ ば、 あるデコード開始可能点から次のデコード開始可能点までの間の ビデオデ一夕について、 その 2次利用を許可するか否かを判定するこ とができる。
また、 第 46図の au_information()に配置された capture_enable__f lag一 AUは、 その capture_enable_flag一 AUに対応するビデオアクセスュ ニッ卜のビデオデ一夕の 2次利用を許可するか否かを表す。 従って、 第 46図の au— informationOに配置された capture_enable_flag一 AUに よれば、 ビデオアクセスユニット単位のビデオデ一夕について、 即ち 、 ピクチャ単位で、 その 2次利用を許可するか否かを判定することが できる。
ここで、 PlayListO (第 5図） における利用許可情報としての capt ure_enable_f lag_PlayList, クリップ情報ファイル CI ip 0 (第 1 0図 ) における利用許可情報としての capture— enable— flag— Clip、 privat e_stream2_PES_payload() (第 45図） における利用許可情報として の capture— enable— flag— ps2, au_information() (第 46図） におけ る利用許可情報としての capture—enable_flag_AUは、 そのうちの 2以 上を重複して採用することが可能であり、 この場合、 あるビデオデー 夕のピクチャの 2次利用の可否は、 その重複して採用される 2以上の 利用許可情報の論理積等に基づいて判定することができる。
また、 第 46図の au_information()が配置される第 2 3図または第 45図の private— stream2— PES— payloadOを含む private— stream— 2の P ES_packet ()は、 第 36図のステップ S 2 1 1で説明したように、 バ ッファ制御モジュール 2 1 5 (第 3図） のビデオ読み出し機能部 2 3 3が、 バッファ 2 1 5 Aに記憶されたプログラムストリーム中から探 索する。 従って、 capture_enable— f lag— ps2が配置された第 45図の p rivate— stream2— PES— payload 0や、 capture— enable— flag— AUが配置さ れた第 46図の au_iniormation()を採用する場合には、 プレイヤ制御 モジュール 2 1 2は、 ビデオデ一夕の 2次利用の可否を判定するにあ たって、. capture一 enable一 flag一 ps2や capture— enable— flag— AU 、 ヒ デォ読み出し機能部 23 3に問い合わせる必要がある。
なお、 本実施の形態では、 上述した一連の処理を、 ソフトウェアに よって行うこととしたが、 上述した一連の処理は、 専用のハードゥエ ァにより行うこともできる。 .
また、 本実施の形態では、 ビデオデコーダ 1 1 6 (第 1図） として 、 ハードウェアデコーダを採用することとしたが、 ビデオデコーダ 1 1 6としては、 ソフトウェアデコーダを採用することも可能である。 ォ一ディォデコーダ 1 1 7 (第 1図） についても、 同様である。 さらに、 本実施の形態では、 字幕デコーダとして、 ソフトウェアデ コーダを採用することとしたが、 字幕デコーダとしては、 ハードゥエ アデコーダを採用することも可能である。

Claims

請 求 の 範 囲
1 . データ記録媒体に記録されている記録データを処理するデ一夕処 理装置において、
前記記録データは、
データを符号化して得られる符号化データと、
前記データの再生手順を表すプレイリス卜と
を含み、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマ一. ク情報を有するプレイリストマーク情報を含み、
前記マーク情報は、
前記プレイリス卜の時間軸上の 1つの再生時刻を表す時刻情報と、 前記マーク情報のタイプを表すタイプ情報と、
前記タイプ情報がイベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報と
を含み、
前言 プレイリストにしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定手段と、
前記判定手段において、 前記データの再生時刻が、 前記時刻情報に 一致すると判定された場合に、 その時刻情報を有する前記マーク情報 を認識する認識手段と、
前記認識手段において認識された前記マーク情報が有する前記タイ プ情報が、 イベントを発生させるタイ.プを表している場合に、 前記マ —ク情報が有する前記引数情報と、 イベントの発生とを通知する通知 手段と、
前記通知手段によって通知される前記引数情報に応じた処理を実行 する実行手段と を備えることを特徴とするデータ処理装置。
2 . 前記実行手段は、 前記引数情報に応じた処理を、 割り込み処理に よって実行する
ことを特徴とする請求の範囲 1に記載のデータ処理装置。
3 . データ記録媒体に記録されている記録データを処理するデータ処 理方法において、
前記記録データは、
データを符号化して得られる符号化デ一夕と、
前記データの再生手順を表すプレイリストと
を含み、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマ一 ク情報を有するプレイリストマ一ク情報を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報と、 前記マーク情報のタイプを表すタイプ情報と、
前 タイプ情報がイベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報と
を含み、
前記プレイリストにしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定ステップと、 前記判定ステップにおいて、 前記データの再生時刻が、 前記時刻情 報に一致すると判定された場合に、 その時刻情報を有する前記マーク 情報を認識する認識ステップと、
前記認識ステップにおいて認識された前記マーク情報が有する前記 タイプ情報が、 イベントを発生させるタイプを表している場合に、 前 記マーク情報が有する前記引数情報と、 ィベン卜の発生とを通知する 通知ステップと、
前記通知ステップによって通知される前記引数情報に応じた処理を 実行する実行ステップと
を含むことを特徴とするデータ処理方法。
4 . データ記録媒体に記録されている記録データを処理するデータ処 理を、 コンピュータに行わせるプログラムにおいて、
刖記記録 ~5 "—タは、
データを符号化して得られる符号化データと、
前記データの再生手順を表すプレイリストと
を含み、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマー ク情報を有するプレイリストマ一ク情報を含み、
前記マ一ク情報は、
前記プレイリス卜の時間軸上の 1つの再生時刻を表す時刻情報と、 前記マーク情報のタイプを表すタイプ情報と、
前記 'タイプ情報がィベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報と
を含み、
前記プレイリストにしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定ステップと、 前記判定ステップにおいて、 前記データの再生時刻が、 前記時刻情 報に一致すると判定された場合に、 その時刻情報を有する前記マーク 情報を認識する認識ステツプと、
前記認識ステップにおいて認識された前記マーク情報が有する前記 タイプ情報が、 イベントを発生させるタイプを表している場合に、 前 記マーク情報が有する前記引数情報と、 イベントの発生とを通知する 通知ステップと、
前記通知ステップによって通知される前記引数情報に応じた処理を 実行する実行ステップと
を含むことを特徴とするプログラム。
5 . データ記録媒体に記録されている記録データを処理するデータ処 理を、 コンピュータに行わせるプログラムが記録されているプロダラ ム記録媒体において、
前記記録データは、
データを符号化して得られる符号化デ一夕と、
前記データの再生手順を表すプレイリストと
を含み、
前記プレイリストは、 そのプレイリス卜の時間軸上の印となるマー ク情報を有するプレイリストマーク情報を含み、
前記マーク情報は、
前記プレイリス卜の時間軸上の 1つの再生時刻を表す時刻情報と、 前記マーク情報のタイプを表すタイプ情報と、
前記タイプ情報がイベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報と
を含み、
前記プレイリス卜にしたがって再生されている前記データの再生時 刻が、 前記時刻情報に一致するか否かを判定する判定ステップと、 前記判定ステップにおいて、 前記デ 夕の再生時刻が、 前記時刻情 報に一致すると判定された場合に、 その時刻情報を有する前記マーク 情報を認識する認識ステツプと、
前記認識ステップにおいて認識された前記マ一ク情報が有する前記 タイプ情報が、 イベントを発生させるタイプを表している場合に、 前
1.88 記マーク情報が有する前記引数情報と、 イベントの発生とを通知する 通知ステップと、
前記通知ステップによって通知される前記引数情報に応じた処理を 実行する実行ステップと
を含むことを特徴とするプログラムが記録されているプログラム記 録媒体。
6 . デ一夕を符号化して得られる符号化データと、
前記データの再生手順を表すプレイリストと
を含む記録データが記録されており、
前記プレイリストは、 そのプレイリストの時間軸上の印となるマー ク情報を有するプレイリス卜マーク情報を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報と、 前記マーク情報のタイプを表すタイプ情報と、
前記タイプ情報がイベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報と
を含む
ことを特徴とするデータ記録媒体。
7 . データを符号化して得られる符号化データと、
前記デ一夕の再生手順を表すプレイリストとを含むデータ構造にお いて、
前記プレイリストは、 該プレイリス卜の時間軸上の印となるマーク 情報を有するプレイリストマーク情報を含み、
前記マーク情報は、
前記プレイリストの時間軸上の 1つの再生時刻を表す時刻情報と、 前記マ一ク情報のタイプを表すタイプ情報と、 前記タイプ情報がイベントを発生させるタイプを表しているときの 、 そのイベントの引数となる引数情報とを含むことを特徴とするデー タ構造。
PCT/JP2005/010905 2004-06-11 2005-06-08 データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造 WO2005122175A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CA002569780A CA2569780A1 (en) 2004-06-11 2005-06-08 Data processing apparatus, data processing method, program, program recording medium, data recording medium, and data structure
EP05751015A EP1758120A4 (en) 2004-06-11 2005-06-08 DATA PROCESSING DEVICE, DATA PROCESSING METHOD, PROGRAM, PROGRAM RECORDING MEDIUM, DATA RECORDING MEDIUM, AND DATA STRUCTURE
KR1020067025928A KR101118823B1 (ko) 2004-06-11 2005-06-08 데이터 처리 장치, 데이터 처리 방법 및 기록 매체
US11/628,358 US8340495B2 (en) 2004-06-11 2005-06-08 Data processing device, data processing method, program, program recording medium, data recording medium, and data structure
CN2005800271962A CN101002268B (zh) 2004-06-11 2005-06-08 数据处理设备和数据处理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004-174571 2004-06-11
JP2004174571A JP4244331B2 (ja) 2004-06-11 2004-06-11 データ処理装置およびデータ処理方法、並びにプログラムおよびプログラム記録媒体

Publications (1)

Publication Number Publication Date
WO2005122175A1 true WO2005122175A1 (ja) 2005-12-22

Family

ID=35503334

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/010905 WO2005122175A1 (ja) 2004-06-11 2005-06-08 データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造

Country Status (8)

Country Link
US (1) US8340495B2 (ja)
EP (1) EP1758120A4 (ja)
JP (1) JP4244331B2 (ja)
KR (1) KR101118823B1 (ja)
CN (1) CN101002268B (ja)
CA (1) CA2569780A1 (ja)
TW (1) TW200606831A (ja)
WO (1) WO2005122175A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4552889B2 (ja) 2006-05-10 2010-09-29 ソニー株式会社 記録装置、記録方法および記録プログラム、ならびに、撮像装置および撮像方法
JP5278059B2 (ja) * 2009-03-13 2013-09-04 ソニー株式会社 情報処理装置及び方法、プログラム、並びに情報処理システム
CN104252488B (zh) * 2013-06-28 2017-12-22 华为技术有限公司 处理数据的方法和服务器
CN103400592A (zh) * 2013-07-30 2013-11-20 北京小米科技有限责任公司 录音方法、播放方法、装置、终端及系统
US20180020228A1 (en) * 2016-07-12 2018-01-18 Mediatek Inc. Video processing system with multiple syntax parsing circuits and/or multiple post decoding circuits
JP6711339B2 (ja) * 2017-10-25 2020-06-17 横河電機株式会社 通信処理装置、プログラム、および通信処理方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07284065A (ja) * 1994-04-06 1995-10-27 Sony Corp オーディオ情報と動画像情報との再生方法
JPH11341440A (ja) * 1998-05-22 1999-12-10 Toshiba Corp 画像表示装置、同装置に適用される画像切り替え表示方法
JP2001176246A (ja) * 1999-12-17 2001-06-29 Sharp Corp 記録再生装置
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
JP2003023604A (ja) * 2001-05-12 2003-01-24 Lg Electronics Inc 動画像データとそれに対する付加情報ファイルが記録された記録媒体と、その記録媒体の再生装置及び方法
WO2004025651A1 (ja) 2002-09-12 2004-03-25 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム、再生方法、記録方法
WO2004049710A1 (ja) 2002-11-28 2004-06-10 Sony Corporation 再生装置、再生方法、再生プログラムおよび記録媒体

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5970205A (en) 1994-04-06 1999-10-19 Sony Corporation Method and apparatus for performing variable speed reproduction of compressed video data
DE69524658T2 (de) * 1994-04-06 2002-08-22 Sony Corp Wiedergabe von Aufzeichnungsmedien
JP3376314B2 (ja) * 1999-05-12 2003-02-10 株式会社東芝 デジタル映像情報媒体、デジタル映像情報記録再生装置およびデジタル映像情報処理方法
CA2374578C (en) 2000-03-17 2016-01-12 Siemens Aktiengesellschaft Plant maintenance technology architecture
EP2268016A3 (en) * 2000-04-21 2013-01-02 Sony Corporation Information processing method and apparatus, program and recording medium
KR20030062737A (ko) * 2002-01-18 2003-07-28 엘지전자 주식회사 재기록 가능 고밀도 기록매체의 축소영상 기록방법
JP2004007518A (ja) 2002-03-27 2004-01-08 Matsushita Electric Ind Co Ltd パッケージメディア、再生装置、および再生方法
WO2004001748A1 (en) * 2002-06-21 2003-12-31 Lg Electronics Inc. Recording medium having data structure for managing reproduction of video data recorded thereon
MXPA04002365A (es) * 2002-06-21 2004-11-22 Lg Electronics Inc Medio de grabacion que tiene estructura de datos para manejar la reproduccion de datos de video grabados en el mismo.
EP1550121A4 (en) * 2002-09-05 2009-06-03 Lg Electronics Inc RECORDING MEDIUM WITH DATA STRUCTURE FOR BRANDS CORRESPONDING TO A PLAYLIST, FOR MANAGING REPROCUTION OF RECORDED IMAGES RECORDED ON THE MEDIUM, AND METHODS AND DEVICES FOR RECORDING AND REPRODUCING
KR100995043B1 (ko) * 2003-01-20 2010-11-19 엘지전자 주식회사 스틸 화상의 재생을 관리하기 위한 데이터 구조를 구비한기록 매체와, 기록 재생 방법 및 장치
EP1617434B1 (en) * 2003-04-23 2017-06-14 Panasonic Corporation Recording medium, reproducing apparatus, recording method, reproducing program, and reproducing method
US8996420B2 (en) * 2003-11-21 2015-03-31 Intel Corporation System and method for caching data
US8472792B2 (en) * 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US7664872B2 (en) * 2005-01-05 2010-02-16 Divx, Inc. Media transfer protocol

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07284065A (ja) * 1994-04-06 1995-10-27 Sony Corp オーディオ情報と動画像情報との再生方法
JPH11341440A (ja) * 1998-05-22 1999-12-10 Toshiba Corp 画像表示装置、同装置に適用される画像切り替え表示方法
JP2001176246A (ja) * 1999-12-17 2001-06-29 Sharp Corp 記録再生装置
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
JP2003023604A (ja) * 2001-05-12 2003-01-24 Lg Electronics Inc 動画像データとそれに対する付加情報ファイルが記録された記録媒体と、その記録媒体の再生装置及び方法
WO2004025651A1 (ja) 2002-09-12 2004-03-25 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム、再生方法、記録方法
WO2004049710A1 (ja) 2002-11-28 2004-06-10 Sony Corporation 再生装置、再生方法、再生プログラムおよび記録媒体

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DVD SPECIFICATIONS FOR READ-ONLY DISC PART 3; VERSION 1.1, December 1997 (1997-12-01)
See also references of EP1758120A4 *

Also Published As

Publication number Publication date
JP4244331B2 (ja) 2009-03-25
KR101118823B1 (ko) 2012-06-12
US8340495B2 (en) 2012-12-25
EP1758120A4 (en) 2011-10-19
JP2005353212A (ja) 2005-12-22
CN101002268B (zh) 2010-09-08
CA2569780A1 (en) 2005-12-22
TWI333196B (ja) 2010-11-11
KR20070018989A (ko) 2007-02-14
EP1758120A1 (en) 2007-02-28
CN101002268A (zh) 2007-07-18
US20080059509A1 (en) 2008-03-06
TW200606831A (en) 2006-02-16

Similar Documents

Publication Publication Date Title
KR101104507B1 (ko) 데이터 처리 장치 및 데이터 처리 방법, 프로그램 기록 매체, 데이터 기록 매체
KR101217351B1 (ko) 데이터 처리 장치 및 데이터 처리 방법과 프로그램 기록 매체
WO2006059519A1 (ja) データ記録装置およびデータ記録方法、データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、並びにデータ構造
US20060021060A1 (en) Data processing apparatus, data processing method, program, program recording medium, data recording medium, and data structure
WO2005122569A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造
WO2005122175A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造
WO2005122570A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体並びにデータ構造
WO2006059482A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、並びにデータ構造
WO2005122168A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体並びにデータ構造
US8107796B2 (en) Data processing device, data processing method, program, program recording medium, data recording medium, and data structure
KR20070020503A (ko) 데이터 처리 장치 및 데이터 처리 방법, 프로그램 및프로그램 기록 매체, 데이터 기록 매체, 및, 데이터 구조

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 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: 11628358

Country of ref document: US

Ref document number: 2005751015

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2569780

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1020067025928

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

WWE Wipo information: entry into national phase

Ref document number: 200580027196.2

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020067025928

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2005751015

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11628358

Country of ref document: US