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

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

Info

Publication number
WO2005122566A1
WO2005122566A1 PCT/JP2005/010627 JP2005010627W WO2005122566A1 WO 2005122566 A1 WO2005122566 A1 WO 2005122566A1 JP 2005010627 W JP2005010627 W JP 2005010627W WO 2005122566 A1 WO2005122566 A1 WO 2005122566A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
data
video data
video
output
Prior art date
Application number
PCT/JP2005/010627
Other languages
English (en)
French (fr)
Inventor
Yasushi Fujinami
Kuniaki Takahashi
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
Priority to JP2005010627A priority Critical patent/JP4320303B2/ja
Application filed by Sony Corporation, Sony Computer Entertainment Inc. filed Critical Sony Corporation
Priority to US11/570,262 priority patent/US8107796B2/en
Priority to CA 2569949 priority patent/CA2569949A1/en
Priority to AU2005253423A priority patent/AU2005253423B2/en
Priority to MXPA06013877A priority patent/MXPA06013877A/es
Priority to BRPI0511958-8A priority patent/BRPI0511958A/pt
Priority to EP05748465A priority patent/EP1761056A4/en
Priority to KR20067025927A priority patent/KR101154721B1/ko
Publication of WO2005122566A1 publication Critical patent/WO2005122566A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H04N19/68—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience involving the insertion of resynchronisation markers into the bitstream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4341—Demultiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • 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
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • H04N7/52—Systems for transmission of a pulse code modulated video signal with one or more other pulse code modulated signals, e.g. an audio signal or a synchronizing signal
    • H04N7/54—Systems for transmission of a pulse code modulated video signal with one or more other pulse code modulated signals, e.g. an audio signal or a synchronizing signal the signals being synchronous
    • H04N7/56—Synchronising systems therefor

Definitions

  • the present invention relates to a data processing device and a data processing method, a program, a program recording medium, a data recording medium, and a data structure, and in particular, for example, to a data processing that enables highly convenient data processing.
  • the present invention relates to an apparatus 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 that records and reproduces data of a television broadcast program on a DVD, and a navigation system that records map information and the like on a DVD and displays the map information.
  • 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 apparatus is characterized in that the usage information used for decoding the encoded video data, which is arranged immediately before each of one or more decoding startable points in the encoded video data in access units, is used as the usage information.
  • Reference information indicating whether or not the video data corresponding to the encoded video data of each of one or more access units arranged from the first to the next use information is referred to in decoding other encoded video data.
  • the first determination means for determining whether or not the output of the video data is later than the output of the output data to be output in synchronization with the video data; and If it is determined that the output of the access data is behind the output of the output data, the processing of the encoded video data of one access unit is performed.
  • the video data is converted to another encoded video data.
  • a second determining means for determining whether or not the processing is referred to in decoding the video data, and a video corresponding to the encoded video data of the access unit for which the processing is instructed by the instructing means in the second determining means.
  • skip control means for skipping the processing of the encoded video data of the access unit instructed to skip the processing by the instruction means. It is characterized by having.
  • the use information used for decoding the encoded video data which is arranged immediately before each of one or more decoding start possible points in the encoded video data in access units, is obtained from the use information.
  • Reference indicating whether or not the video data corresponding to the encoded video data of each of one or more access units arranged until the next use information is referred to in the decoding of other encoded video data.
  • the video data based on an instruction step for instructing to skip the processing of the access unit, and reference information for video data corresponding to the coded video data of the access unit for which the processing is instructed to be skipped in the instruction step.
  • the use information used for decoding the encoded video data which is arranged immediately before each of one or more decoding start possible points in the encoded video data of the access unit, is The video data corresponding to the encoded video data of each of one or more access units located between 5
  • the encoded video data of one access unit is The video data is obtained based on an instruction step for instructing to skip the processing of the access unit, and reference information for the video data corresponding to the encoded video data of the access unit indicated to skip the processing in the instruction step.
  • a second determination step for determining whether or not it is referred to for decoding another encoded video is performed. If it is determined in the instruction step that the video data corresponding to the coded video data of the access unit for which the processing skip has been instructed is not referred to in decoding other coded video data, the processing in the instruction step is performed. And a skip control step of skipping the processing of the coded video data of the designated access unit.
  • the program recorded on the program recording medium of the present invention is used for decoding encoded video data, which is arranged immediately before each of one or more decoding start points in the encoded video data on an access unit basis.
  • the video data corresponding to the coded video data of each of one or more access units arranged between the usage information and the next usage information is the decoding of the other coded video data.
  • reference information indicating whether or not the video data is referred to is included, it is determined whether or not the output of the video data is later than the output of the output data to be output in synchronization with the video data. In the determination step and the first determination step, the output of the video data is later than the output of the output data.
  • the encoded data is obtained by encoding video data in a predetermined unit, encoded video data in access units, and output data to be output in synchronization with the video data.
  • usage information used immediately before each of one or more decoding start possible points in the coded video data in an access unit and used for decoding the coded video data, and the usage information includes the usage information.
  • the video data corresponding to each encoded video data of one or more access units located between and the next usage information is referred to for decoding other encoded video data It is characterized by including reference information indicating
  • the coded data is output in synchronization with the coded video data of an access unit obtained by coding the video data of a predetermined unit and the video data.
  • Output data to be decoded and one or more decoding starts for encoded video data per access unit
  • Utilization information which is located immediately before each possible point and is used for decoding encoded video data, includes one or more accesses arranged between the utilization information and the next utilization information.
  • the video data corresponding to each encoded video data unit includes reference information indicating whether or not the video data is referred to for decoding other encoded video data.
  • one or more decoding start possible points in the coded video data in units of access units may be set immediately before each point.
  • the usage information used to decode the coded video data and the coded video data of one or more access units located between the usage information and the next usage information.
  • the video data to be output includes reference information indicating whether or not the encoded video data is referred to in decoding of other encoded video data
  • the output of the video data is output in synchronization with the output of the video data. It is determined whether the video data output is behind the output data output. If you are instructed to skip the processing of one access Interview knit encoded video data.
  • the coded data is output in synchronization with the coded video data of an access unit obtained by coding the video data of a predetermined unit and the video data.
  • Including the output data to be output and usage information used for decoding the encoded video data which is arranged immediately before each of one or more decoding start possible points in the encoded video data in access units.
  • the video data corresponding to the coded video data of each of one or more access units located between the usage information and the next usage information is referred to for decoding other coded video data. It contains reference information indicating whether or not it is.
  • 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 mark-type value
  • FIG. 9 is a diagram showing the relationship between PlayListO, PlayltemO, clips, and the program stream stored in the clip stream file.
  • 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. 10 is a diagram showing the clip information file ClipO. Diagram showing PT / JP2005 / 010627 tax, Fig. 11 is a diagram showing the relationship between the str r earn-id and private-st ream identifying the elementary stream, and the elementary stream.
  • Fig. 12 is a diagram showing the relationship between the elementary stream and the elementary stream.
  • Fig. 13 shows the syntax of StaticInfoO
  • Fig. 13 shows the syntax of DynamicInfoO
  • Fig. 14 shows the syntax of EP-map ()
  • Figure 16 shows the syntax of the MPEG-2 System program stream, program stream pack, and program stream pack header.
  • Figure 16A and Figure 16B show the syntax of the MPEG-2 System PES packet.
  • FIG. 17B and Fig. 17C show the syntax of the MPEG-2 System PES packet
  • Fig. 18A and Fig. 18B show the MPEG-2 System PES packet syntax.
  • FIG. 3 is a diagram illustrating the syntax of a PES packet of the -2 System.
  • FIGS. 19A and 19B are diagrams showing the relationship between the value described in the stream_id of PES-packet 0 in the MPEG-2 System and the attribute (type) of the elementary stream.
  • Fig. 0 shows the stream-id used by the disk device.
  • Fig. 21 shows the private_stream and PES- payloadO syntax.
  • Fig. 22 shows the private-siream-id value and private.
  • FIG. 25 is a diagram showing a specific example of the “PLAYLIST.DAT” file.
  • FIGS. 26A and 26B are clip information files “00001. CLP”, “00002.
  • FIG. 27 shows a specific example of EPjnapO in the clip information file “00001. CLP”.
  • Fig. 28 is a diagram showing a specific example of PyListMarkO in ayList # 0 and PlayList # 1
  • Fig. 29 is a flowchart illustrating pre-playback processing
  • Fig. 30 is FIG.
  • FIG. 31 is a flowchart illustrating the playback process
  • FIG. 31 is a flowchart illustrating the Pyltem transfer process
  • Fig. 32 is a flow chart for explaining the time code display processing
  • Fig. 33 is a flowchart for explaining the stream switching processing
  • Fig. 34 is a flow chart for explaining the processing of the buffer control module 215.
  • FIG. 35 is a flowchart for explaining the process of the buffer control module 215
  • FIG. 36 is a flowchart for explaining the process of reading a video stream
  • FIG. FIG. 38 is a flowchart for explaining a process for reading a subtitle stream
  • FIG. 39 is a flowchart for explaining a process for reading a subtitle stream
  • FIG. 41 is a flowchart illustrating output attribute control processing
  • FIG. 42 is clip information.
  • Figure 43 shows a concrete example of the set of pts-change_point and DynamicInfoO described in the file "00003. CLP”. Flowchart explaining control processing and background Z screen saver processing.
  • Fig. 45 is a diagram showing another syntax of private-stream2_PES-payloadO.
  • Fig. 46 is a diagram showing another syntax of au-in formationO. It is. BEST MODE FOR CARRYING OUT THE INVENTION
  • the encoded data is a
  • Usage information used for decoding for example, priva te one stream one 2—PES—pay l oad 0 in FIG. 23) and
  • the usage information is such that video data corresponding to the coded video data of each of the one or more access units arranged between the usage information and the next usage information is the same as that of the other coded video data.
  • Reference information indicating whether or not it is referred to for decoding for example, aureflga in Fig. 24) Including
  • First determining means for determining whether or not the output of the video data is behind the output of the output data for example, FIG. 2A and FIG. 2A which perform the processing of step S 272 in FIG. 39
  • the decode control module 2 1 in Fig. 2B
  • Instruction means for example, the decoding control module 2 14 in FIGS. 2A and 2B for performing the processing in step S 273 in FIG. 39;
  • Second determination means for determining whether or not the decoding control module 2 14 in FIG. 2A and FIG. 2B performs the processing of step S275 in FIG.
  • the second determination unit it is determined that the video data corresponding to the encoded video data of the access unit for which the skip of the process has been instructed by the instruction unit is not referred to in decoding other encoded video data.
  • skip control means for skipping the processing of the coded video data of the access unit for which the processing means has been instructed by the instruction means for example, performing the processing of step S277 in FIG. And the video decoder control module 2 16 shown in FIG. A and FIG. 2B.
  • the output of the output data is output by the video Output control means for repeatedly outputting the video data when it is determined that the video data is delayed from the output of the video data (for example, FIG. 2A and FIG. 2 Equipped with video decoder control module 2 16) shown in Fig. B
  • the encoded data is a
  • Usage information (for example, pri va te one stre am—21 PES—pay l oad O in FIG. 23) and
  • the usage information is such that the video data corresponding to the encoded video data of each of the one or more access units arranged between the usage information and the next usage information is the same as that of the other encoded video data. It includes reference information indicating whether or not it is referred to for decoding (for example, au-reset Hag in FIG. 24),
  • a first determination step of determining whether or not the output of the video data is behind the output of the output data (for example, step S 27 2 in FIG. 39);
  • the first determination step when it is determined that the output of the video data is behind the output of the output data, one An instruction unit for instructing that the processing of the encoded video data of the access unit be skipped (for example, step S273 in FIG. 39); A second determining step of determining whether or not the video data is referred to by a code of another encoded video data based on the reference information for the video data corresponding to the encoded video data (for example, , Step S 27 5 in FIG. 39) and
  • the second determination step it is determined that the video data corresponding to the encoded video data of the access unit for which the skip of the process has been instructed in the instruction step is not referred to in decoding other encoded video data.
  • a skip control step for skipping the processing of the coded video data of the access unit for which the processing skip was instructed in the instruction step (for example, step S 2 in FIG. 39)
  • the encoded data is a
  • Coded video data in access units obtained by coding video data in a predetermined unit obtained by coding video data in a predetermined unit
  • Usage information used for decoding for example, pri va in FIG. 23) te—st ream one 2—PES one pay l oad 0)
  • the usage information is such that video data corresponding to the coded video data of each of the one or more access units arranged between the usage information and the next usage information is the same as that of the other coded video data. It includes reference information indicating whether or not it is referred to for decoding (for example, au-ref-Hag in FIG. 24).
  • a first determination step for example, step S 27 2 in FIG. 39 for determining whether or not the output of the video data is later than the output of the output data
  • the first determining step when it is determined that the output of the video data is later than the output of the output data, it is instructed to skip processing of the encoded video data of one access unit.
  • An instruction step eg, step S2773 in FIG. 39
  • a second determination step for example, step S275 of FIG. 39 for determining whether or not the video data is referred to by decoding of another encoded video data;
  • a skip control step for example, step S2777 in FIG. 39 for skipping the processing of the coded video data of the access unit for which the processing skip is instructed in the instruction step. It is characterized by including.
  • the data recording medium described in claim 6 is
  • the encoded data is a
  • Coded video data in access units obtained by coding video data in a predetermined unit obtained by coding video data in a predetermined unit
  • the usage information includes video data corresponding to the coded video data of each of the one or more access units arranged between the usage information and the next usage information, and other coded video data.
  • Includes reference information eg, au_re and fl ag in Fig. 24) that indicates whether or not it is referenced in decoding
  • FIG. 1 is a block diagram showing a hardware configuration example of an embodiment of a disk drive to which the present invention is applied.
  • the disc device shown in FIG. 1 can be applied to, for example, a disc 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. It records video data, content data such as audio data and subtitle data, and data required to play back content data.
  • 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.
  • the disk device shown in FIG. 1 can receive data read from a distant disk 101 and transmitted. 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.
  • data is distributed 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 an in-net network. It is also possible to receive and process.
  • the disk device it is also possible to receive data from a server or other devices, temporarily record the data 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 according to an instruction such as reading from the drive interface 114, and reads the data from the drive. Processing such as supplying to the interface 114 is performed.
  • the bus 1 1 1 has a CPU Central Processing Unit 1 1 2, a memory 1 13, a drive interface 1 14, an input interface 1 1 5, a video decoder 1 1 6, an audio decoder 1 1 7, and a video output. 1 1 8 and audio output interface 1 1 9 are connected.
  • 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, controls the entire disk device, and performs various processes, which will be described later.
  • 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. In the case where a hard disk is provided in the disk device shown in FIG. 1 and the software modules to be executed by the CPU 112 are recorded (installed) on the hard disk, the memory 113 is used as the memory. However, it is possible to use only volatile memory.
  • the program (software module group) executed by the CPU 112 can be recorded (stored) in advance in the memory 113 as a recording medium built in the disk device.
  • the program may be a disk 101, a flexible disk other than the disk 101, a compact disc read compact disk (CD-ROM), a magnetic disk (M0), a magnetic disk, and a memory card. It can be stored (recorded) temporarily or permanently on a removable recording medium such as. 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 transferred from the down site to the disk device via a satellite for digital satellite broadcasting by radio, or connected to a disk device via a network such as a LAN (Local Area Network) or the Internet. In the disk device, the program transferred in this way can be received by the input interface 115 and can be installed in the built-in memory 113.
  • LAN Local Area Network
  • the program may be processed by one CPU, or may be processed in a distributed manner by a plurality of CPUs.
  • the drive 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 to the CP 111 via the bus 111 via the bus 111. It is supplied to U112, memory 113, video decoder 116, audio decoder 117, etc.
  • the input interface 115 receives a signal supplied when a key (button) (not shown) or a remote controller (remote controller) is operated by a user, and receives the signal via a bus 111. Supply to CPU1 1 and 2.
  • the input interface 115 also functions as a communication interface such as a modem (including an Asymmetric Digital Subscriber Line (ADSL) modem) and a NIC (Network Interface Card).
  • a modem including an Asymmetric Digital Subscriber Line (ADSL) modem
  • NIC Network Interface Card
  • the video decoder 1 16 is read from the disk 101 by the disk drive 102, and is supplied via the drive interface 114 and the path 111. Audio data) and decode the resulting video data
  • the audio decoder 117 encodes audio data read from the disk 101 by the disk drive 102 and supplied via the drive interface 114 and the bus 111. Decodes the data (encoded audio data) and supplies the resulting audio data to the CPU 112 and audio output module 119 via the bus 111. I do.
  • the video output interface 118 performs necessary processing on video data supplied via the path 111 and outputs the processed data from the video output terminal 120.
  • the audio output interface 1 19 performs necessary processing on the audio data supplied via the bus 1 1 1 and outputs it from the audio output terminal 1 2 1.
  • 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 data output from the video output terminal 120 is video data. It is supplied to the 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), and thus the audio output from the audio output terminal 121 is supplied to the audio output device. Is output.
  • the supply of video data and audio data from the disk device to the video output device and the audio output device can be performed either by wire or wirelessly.
  • FIG. 2A and FIG. 2B are executed by the CPU 11 of FIG. 3 shows a configuration example of a software module group.
  • the software modules executed by the CPU 112 are roughly divided into an operating system (OS) 201 and a video content playback program 210 as an application program.
  • OS operating system
  • video content playback program 210 video content playback program
  • the operating system 201 When the power of the disk device is turned on, the operating system 201 starts first (the CPU 112 executes the operating system 201), and performs necessary processing such as initial setting. Call the video content playback program 210, which is an application program.
  • the operating system 201 provides the video content playback program 210 with an infrastructure (infrastructure) service such as file reading. 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. 2 1 1, Player control module 2 1 2, Content data supply module 2 1 3, Decode control module 2 14 4, Buffer control module 2 15 5, Video decoder control module 2 16, Audio decoder control module 2 1 7. It consists of a subtitle decoder control module 218, a graphics processing module 219, a video output module 220, and an audio output module 221.
  • the video content playback program 210 is software that plays a central role in playing the disc 101, and when the disc 101 is inserted (inserted) into the disc drive 102, the disc 101 is played. It is checked whether 1 is a format disc on which contents are recorded, which will be described later. 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. Reads a file of metadata (database information) required for playback and controls playback of content based on the metadata.
  • the scribing control module 211 interprets and executes a scribing program (script) described in a scribing file recorded on the disc 101.
  • a scribing program for example, "manipulate the graphics processing module 219 to create and display images such as menus", "use a signal from a UI (User Interface) such as a remote control, etc.
  • the display of the menu can be changed (for example, the force on the menu is moved), and the operation of “controlling the player control module 2 1 2” can be described.
  • 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 211 analyzes, for example, a PlayListO or a ClipO described later, which is recorded on the disc 101, and according to the analysis result, the content data supply module 211. 3, the decode control module 215 and the buffer control module 215. In addition, the player control module 211 controls switching such as a stream to be played back and a stream switching described later according to an instruction from the script control module 211 or the input interface 115. Do. 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 213 can control the content of the content from the disc 101 based on the control of the player control module 221 or based on the amount of data stored in the buffer control module 215. It requests the operating system 201 to read data and metadata.
  • the meta data read from the disk 101 by the operating system 201 in response to a request from the content data supply module 213 is supplied to necessary modules. Also, if the operating system 201 is a content data supply module 211 The content data read from the disk 101 in response to these requests 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 12. I do.
  • the decode control module 2 14 has a built-in clock section 2 14 A that measures the time, and outputs the video data output under the control of the video decoder control module 2 16 and synchronizes with the video data.
  • the output of data to be output (output data), that is, the synchronization with the output of audio data output under the control of the audio decoder control module 217 is managed here.
  • 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 overnight supply module. By making a request from the operating system 201 to the operating system 201, the content data read from the disk 101 is temporarily stored.
  • 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 will be described later with reference to FIG. It has a built-in video readout function unit 233, audio readout function unit 234, and subtitle readout function unit 235. 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 215 processes the data request from the audio decoder control module 217 in the audio read function section 234, thereby processing the data stored in the buffer 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 read function unit 235 to be stored in the buffer 215A. The data is supplied to the subtitle decoder control module 218.
  • Video decoder control module 2 1 6
  • the video decoder control module 216 operates the video reading function section 233 (FIG. 3) in the buffer control module 215 to decode the video data (video coded data). ) Is read from the buffer 215A of the buffer control module 215 in units of video access units, and supplied to the video decoder 116 shown in FIG. Also, 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 the 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 the encoded audio data (audio encoded 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 217 controls the audio decoder 117 to decode data in units of audio access units. 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 output in synchronization with one picture). In the present embodiment, it is assumed that the audio access unit has a known fixed length, for example.
  • the subtitle decoder control module 218 operates the subtitle reading function section 235 (Fig. 3) in the buffer control module 215 to encode the subtitle data (subtitle coded data). ) Is read from the buffer 215A 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 the 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). In the present embodiment, it is assumed that 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 according to the control (instruction) of the player control module 221, and performs the processing from the video decoder control module 216. Add (overlay) with video data. 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 212, and overwrites the output video data.
  • the graphics processing module 219 includes an aspect ratio of the video output device connected to the video output terminal 120 of FIG. 1 and an aspect ratio of the video data recorded on the disk 101.
  • the aspect ratio of video data to be output to the video output module 220 is converted based on the information indicating the instruction.
  • the graphics processing module 2 1 9 is The video data output to the video output module 220 is squeezed (reduced) in the horizontal direction (horizontal direction) and output with blackness on the left and right. 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 the aspect ratio of 16: 9, the graphics processing is performed.
  • the module 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 219 outputs the video data to be output to the video output module 220 without squeezing.
  • the graphics processing module 219 captures the 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.
  • the video output module 220 exclusively occupies a part of the memory 113 shown in FIG. 1 and is used as a FIF0 (First In First Out) 220 A (buffer).
  • FIF0 First In First Out
  • the video data from 9 is temporarily stored, and the video data stored in the FIF0220A is appropriately read out and output to the video output terminal 120 (FIG. 1).
  • the audio output module 221 is a part of the memory 113 shown in FIG. And exclusively used as a FIF0 2 1 A (buffer) to temporarily store the audio data from the audio decoder control module 2 17 (audio decoder 1 17). Reads the audio data stored in FIF02-21A as appropriate, and outputs it to the audio output terminal 121 (Fig. 1).
  • the audio output module 221 has a dual channel in which the audio data from the audio decoder control module 217 is the audio data of the “main audio” on the left channel and the “sub audio” of the right channel. If the audio data is in the (Dual) (Nike language) mode, the audio data from the audio decoder control module 217 is output to the audio output terminal 121 in accordance with the audio output mode specified in advance.
  • the audio output module 22.1 when “main audio” is specified as the audio output mode, the audio output module 22.1 outputs the audio of the left channel of the audio data from the audio decoder control module 217. Audio data as right channel audio data, and outputs the left channel and right channel audio data (“main audio” audio data) to the audio output terminal 122.
  • “sub-audio” is specified as the audio output mode
  • the audio output module 221 outputs the audio data of the right channel in the audio data from the audio decoder control module 217.
  • One night 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 1 2 1.
  • the audio output module 221 sends the audio output Output to the audio output terminal 121 as it is.
  • the audio output module 221 is not involved in specifying the audio output mode. Output the audio data from the audio decoder control module 217 to the audio output terminal 121 as it is.
  • the audio output mode can be specified interactively by operating a remote controller or the like on a screen or the like on which a menu generated by the video content reproduction program 210 is displayed, for example.
  • 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. Temporarily memorize the night. 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 shown in FIGS. 2A and 2B. 2 17, or supply to the subtitle decoder control module 2 18.
  • the buffer control module 2 15 has, in addition to the buffer 2 15 A, a data header storage unit 2 31 which is a part of the memory 113 and a data write pointer storage unit 2 32, As an internal module, it has a video reading function section 233, an audio reading function section 234, and a subtitle reading 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 for the storage capacity, overwrites the oldest data. Then, the latest data is stored in an infinite loop.
  • the data head pointer storage unit 2 31 stores the position (address) where the oldest data that has not yet been read from the buffer 2 15 A among the data stored in the buffer 2 15 A is stored. ) Is stored.
  • the data write pointer storage unit 232 stores a write pointer indicating the position (address) of the buffer 215 A 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 215 A, valid data is stored from the position indicated by the data start pointer to the position indicated by the data write pointer clockwise. Data.
  • the video readout function section 233 In response to a request from the video decoder control module 216 shown in FIGS. 2A and 2B, the video readout function section 233 outputs a video stream from the buffer 215A (the elementary stream for video data). ) Is read and supplied to the video decoder control module 216. In response to a request from the audio decoder control module 217 shown in FIGS. 2A and 2B, the audio read function section 234 also outputs audio streams (audio data related data) from the buffer 215A. (Rementary stream) and read the audio decoder control module.
  • audio streams audio data related data
  • the subtitle reading function unit 235 also receives a request from the subtitle decoder control module 218 shown in FIGS. 2A and 2B from the buffer 215A to output the subtitle stream (elements relating to the subtitle data). And sends it to the subtitle decoder control module 218.
  • a program stream (MPEG2_System Program Stream) conforming to the standard of the Moving Picture Experts Group (MPEG) 2 is recorded on the optical disc 101, and the optical disc 101
  • the program stream read from 101 is stored.
  • one or more elementary streams such as a video stream, an audio stream, and a subtitle stream are time-division multiplexed.
  • the video reading 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.
  • the 234 also has a function of demultiplexing the program stream, and separates and reads an 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 read function unit 233 has a video read pointer storage unit 241, a stream-id register 242, and an au_information () register 243, which are part of the memory 113 in FIG. .
  • the video read pointer storage 241 stores the buffer 2 A video read pointer that points to the position (address) where the video stream is stored is stored.
  • the video read function unit 233 stores the data stored in the buffer 215 A at the position indicated by the video read buffer. Read 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.
  • the au—information 0 register 243 stores au_information (), which will be described later, which is data (used for reading the video stream) necessary to read the video stream from the buffer 215A.
  • 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. ing.
  • the audio read pointer storage unit 251 stores an audio read pointer pointing to the position (address) of the buffer 215A where the audio stream is stored.
  • the audio read function unit 234 stores the audio read pointer of the buffer 215A.
  • the data stored at the position indicated by the audio read pointer is read as an audio stream.
  • the stream register id 252 and the pri vat—stream register id 253 analyze the program stream stored in the buffer 215 A and read the audio stream to be read from the program stream.
  • the stream_id and private-stream_id described later for identification are stored respectively.
  • the subtitle readout function unit 235 is a part of the memory 113 shown in FIG. 1.
  • the subtitle read function flag storage unit 261 stores a subtitle read function flag. When the subtitle read function flag stored in the subtitle read function flag storage unit 261, for example, is 0, the subtitle read function unit 235 does not operate, and is stored in the subtitle read function flag storage unit 261. When the subtitle read function flag set is, for example, 1, the subtitle read function unit 235 functions.
  • the subtitle read pointer storage unit 262 stores a subtitle read point indicating the position (address) of the buffer 215 A where the subtitle stream is stored, and the subtitle read function unit 235 stores the buffer 215.
  • the data stored in the position of A, which is indicated by the subtitle read pointer, is read as the 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 identify the subtitle stream to be read from the program stream, as described below. The stream-id and private-stream-id are stored.
  • FIG. 4 schematically shows the directory structure of the disc 101.
  • the file system of the disk 101 is, for example, defined by ISO (International Organization for Standardization)-9660 or UDF (Universa 1 Disk Format: http://www.osta.org/specs/).
  • ISO International Organization for Standardization
  • UDF Universal 1 Disk Format: http://www.osta.org/specs/.
  • a file system is used, and the files recorded on disk 101 are managed hierarchically by a directory structure.
  • the file system is not limited to the file system described above.
  • a “VIDEO” directory is placed in a root directory indicating a base point of the file system, and two directories, a “CLIP” directory and a “STREAM” directory, are placed in the “VIDEO” directory. The directory is located.
  • the "VIDEO" directory contains two data files, a "CLIP” directory and a "STREAM” directory, and two data files, a "SCRIPT.DAT” file and a "PLAYLIST.DAT” file. I have.
  • the "SCRIPT.DAT” file is a script file that describes the script program.
  • the SCRIPT.DAT file describes a script program used to make the playback mode of the disc 101 interactive.
  • 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 (PlayList 0 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 compresses and encodes one or more data (stream) such as video data, audio data, subtitle data, etc.
  • a time-division multiplexed program stream of one or more elementary streams obtained as a result is stored.
  • the clip information file describes (file) metadata about 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 given a file name in accordance with the naming rule of 5 characters + period + "PS”, and the clip information file has the corresponding clip stream file and File names are given according to the same five-character number + period + "CLP" naming convention.
  • 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 by whether the part other than the file name extension (the part to the left 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 bit length of the data in the “Syntax” column of the corresponding row.
  • “bslbf” bit string left bit first
  • “Uimsbf” unsigned integer most significant bit first
  • name_length represents the size of the name_string that is arranged thereafter, in terms of the number of bytes.
  • name-string represents the name (file name) of the "PLAYLIST. DAT" file.
  • name-string up to the number of bytes represented by name-length from the beginning is used as a valid name. For example, if name-length is 10, the first 10 bytes of name-string are interpreted as a valid name.
  • Number_of_PlayLists (16 bits) is placed after name_string.
  • number_of—PlayLists represents the number of subsequent PlayLists 0.
  • PlayList () 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 PlayList 0.
  • PlayLis data-length indicates the size of PlayList 0.
  • PlayList_data length reserved for— word alignment (1 5 bits) and capture—enable—flag—PUyList (1 bit) are sequentially arranged.
  • the 15-bit reserved_for—word—alignment is a 1-bit capture—enable_flag—placed after that, to take the so-called single-door line (word alignment) at the PlayList position (to align to the 16-bit position) ).
  • capture—enable—flag_PlayList is 0 or 1, for example, 1 indicates that secondary use of video data belonging to PlayList () is permitted.
  • 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 PlayList 0 is not permitted (prohibited).
  • capture_enable-flag_PlayList is 1 bit, but in addition, capture-enable-flag_PlayList is composed of multiple bits and the secondary use of video data belonging to PlayList () is gradually It is possible to allow it. That is, capture_enable_flag_PlayList can be composed of, for example, 2 bits. If the value of capture—enable_flag—PUyList is OOB (B indicates that the preceding digit is a binary number), the secondary use of video data is prohibited, and capture_enable—flag— If the value of PlayList is 01B, only secondary use of reducing the size of the video to 64X64 pixels or less can be permitted.
  • capture_enable_nag_PlayList is 10B
  • secondary use of video data can be permitted without any size restrictions. Further, as described above, in the secondary use of video data, it is also possible to limit the size of the video data, instead of limiting the size.
  • the value of capture—enabIe_flag—PlayList is 01B
  • capture_enable—flag—PlayList is permitted
  • capture_enable—flag—PlayList is 2 bits as described above, reservecljor-word-alignment arranged before it is 14 bits in order to take a word line.
  • 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.
  • number_of_PlayIterns (16 bits) is placed.
  • the numbe of—Playltems indicates the number of PlayltemOs that follow.
  • 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 PyListO of FIG.
  • length (16 bits) is arranged, and length represents the size of PlayltemO including it.
  • CI ip—Information—file_name is the clip information file (extension in FIG. 4 is PS) corresponding to the clip stream file (the file extension is PS in FIG. 4) played by Playtem ().
  • CLP file is the clip information file (extension in FIG. 4 is PS) corresponding to the clip stream file (the file extension is PS in FIG. 4) played by Playtem ().
  • IN_time and OUT-time are time information for specifying the playback start position and the playback end position of the clip stream file specified by the CI ip-information_file name, respectively.
  • the position in the middle of the clip stream file (including the beginning) can be specified as the playback start position.
  • the position in the middle of the clip stream file (including the end) can be specified.
  • the position can be specified as the playback end position.
  • PlayltemO the content from IN_time to 0UT_time of the clip stream file specified by CI ip—Information—file—name is reproduced.
  • 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 P1 containing the PlayListMarkO. ayLis t () (Fig. 5)
  • a set of zero or more MarkOs which is a mark on the time axis of the playback performed in accordance with (a).
  • One MarkO represents time information representing one time (position) on the time axis of playback performed according to PlayList 0, type information representing the type of MarkO, and type information representing the type in which the type information generates an event. At least, it has the argument information which is 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.
  • umber_of_PlyList_arks (16 pits) is arranged, and number_of-PlayList-marks indicates the number of MarkOs arranged subsequently. After number_of—PlayListjnarks, the structure of Mark 0 is described by the number of number_of—P1ayList_marks.
  • Mark_type (8 bits) is placed at the head of MarkO.
  • markjyp e 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 whose type is caption is a mark of the head position of capping, which is the unit of cueing that divides PI ayListO.
  • 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 cap.
  • MarkO of the event type (hereinafter referred to as an event mark as appropriate) is a mark of a position where 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.
  • the relationship between the value of mark-type and the type of MarkO is shown in FIG. According to FIG.
  • mark_type of the index mark is set to 2
  • mark_type of the event mark is set to 3.
  • 0 and 4 to 255 of the values of 8 pits represented by mark_type are reserved for future expansion.
  • mark-type is followed by mark-name-length (8 bits).
  • mark-name-string (24 bytes) is placed.
  • mark—name—length and mark—name—string are used to describe the name of MarkO
  • mark—name—length is the valid size of mark—name—string
  • mark—name—string is , MarkO, respectively. Therefore, the head of mark-name-string, and the mark-name-ength up to the number of pite represented by th represent a valid name of MarkO.
  • mark— name_length is followed by four elements that associate MarkO defined on PlayList 0 with the clip stream file.
  • ref— to— Playltem_id (16 bits), mark— time— stamp (32 bits), entry— ES—stream—id (8 bits), entry—ES—private—stream—id (8 bits) are arranged sequentially.
  • ref-to-JPyltem-id an ID assigned by a serial number to Play 11 em 0 to which MarkO belongs is described.
  • the refjo—Playltem—id identifies the PyltemO (FIG. 6) to which Mark 0 belongs, and, as described in FIG. 6, 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 ref—to—Playitem—id.
  • Fig. 9 shows PlayListO, Playtem (), clips, and clips. It shows the relationship between the program streams stored in the lipstream file. .
  • PlayListO is composed of three PlayltemOs, and each of the three PlayltemOs is assigned ID # 0, # 1, and # 2 assigned with serial numbers.
  • Playltem 0 to which ID # i is assigned as appropriate will be referred to as Playltem # i.
  • clips which are contents reproduced by PlayltemtO, Playltemtl, and Playltem # 2 are shown as Clip A, Clip B, and Clip C, respectively.
  • the entity of the clip is specified by Clipjnformation_file_name in PlayltemO in Fig. 6 (and further specified by the clip information file) Of the program stream stored in the clip stream file, from Iltime to OUT-time It is a program stream.
  • 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.
  • MarkO which is the mark of the position (time) tO on the time axis of playback performed according to PlayListO, has its ref-to-Playltem-id and mark-time-stamp, as follows. Is described in
  • entry-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. Used for That is, in the entry-ES-stream-id, an elementary stream (with which MarkO is associated) is arranged, as shown in FIGS.
  • W is written in the entry-ES-stream-id and the entry_ES-private-stream-id of MarkO that are not associated with a specific elementary stream, for example, [0].
  • mark_data is an argument that is an argument of the event generated by MarkO if MarkO is an event mark Information.
  • MarkO is a cap mark or index mark
  • mark-data can also be used as the cap index number indicated by the cap mark index.
  • FIG. 10 shows the internal structure of such a clip information file ClipO.
  • the unit (range) of the video data permitted for secondary use differs between the capture—enable—flag_PlayList in FIG. 5 and the capture—enable—flag—CI ip in FIG.
  • the capture_enable-flag-Clip in FIG. 10 can also be a plurality of bits instead of one bit, as described in capture-enable-flag_PlayList in FIG.
  • StreamlnfoO At the head of StreamlnfoO, length (16 bits) is placed, and this length indicates the size of StreamlnfoO including it. Following the length, a stream id (8 bits) and a private_stream-id (8 bits) are arranged, and the element stream associated with Streamlnfo 0 is specified by the stream-id and the private-stream-id ( Identified).
  • FIG. 11 shows a relationship between a stream_id and a private stream_id for identifying an elementary stream, and an elementary stream.
  • stream id is the same as defined in MPEG2-System standard
  • the value is determined in advance for each attribute (type) of elementary stream (data) in the MPEG2-System standard. Therefore, the element list of the attribute defined in the MPEG2-System standard can be specified only by the stream-id.
  • the present embodiment it is possible to handle an elementary stream that is not specified in the MPEG2-System standard, and the private-stream-id is an attribute not specified in the MPEG2-System standard. This is information for identifying the elementary stream.
  • Figure 11 shows the elementary stream of a video encoded by the encoding (decoding) method specified by MPEG, and the element of audio encoded by ATRAC (Adaptive TRans form Acoustic Coding). Evening stream (hereinafter, appropriately referred to as ATRAC audio stream), LPC (Linear Pulse Code Modulation) encoded elementary stream (hereinafter, appropriately referred to as LPCM audio stream), and subtitle elementary It shows the relationship between stream-id and private-stream-id for an elementary stream with four attributes of a stream (hereinafter referred to as a subtitle stream as appropriate).
  • ATRAC audio stream LPC (Linear Pulse Code Modulation) encoded elementary stream
  • LPCM audio stream Linear Pulse Code Modulation
  • subtitle elementary shows the relationship between stream-id and private-stream-id for an elementary stream with four attributes of a stream (hereinafter referred to as a subtitle stream as appropriate).
  • an elementary stream of a video encoded by the encoding method specified by MPEG must have a value in the range of OxEO to OxEF (Ox means that the character string that follows is hexadecimal ), And multiplexing using stream-id for identifying an elementary stream is specified. Therefore, an elementary stream of video encoded by the encoding method specified by MPEG can be identified by a stream_id having a value in the range of OxE0 to OxEF, and the elementary stream of 16 videos can be identified. Can be multiplexed into the program stream. The elementary stream of video encoded by the encoding method specified by MPEG can be identified by the stream_id of the value in the range of OxEO to OxEF, so the private_seam_id is unnecessary. (Can be ignored).
  • stream-id is not defined for ATRAC audio streams, LPCM audio streams, and subtitle streams.
  • the stream-id is a value representing the attribute of private-stream-1 in the MPE G2-System.
  • OxBD is adopted, and as shown in Fig. 11, identification (identification) is performed using private-stream-id.
  • a private-stream_id having a value in the range of 0x00 to OxOF is used to identify an 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.
  • a private-stream-id having a value in the range of 0x80 to 0x9F is used to identify a subtitle stream. Therefore, 32 subtitle streams can be multiplexed in the program stream.
  • Staticlnfo () and reserved_for_word_alignment (8 bits) are sequentially arranged.
  • str (described in StreamlnfoO including its StickInfoO) Information that does not change during playback of the elementary stream specified by eam_id and private-stream-id is described. Details of Static Info 0 will be described later with reference to FIG.
  • pts—change—point represents the time at which the Dynamiclnfo 0 information set with it becomes valid.
  • pts_change_point representing the time at the beginning of the elementary stream is present at ion—start described at the beginning of the clip information file Clip 0 corresponding to the clip stream file in which the elementary stream is stored. — Equal to time.
  • Dynamiclnf o 0 Top, stream-id and private-stream-id This element describes, as it were, dynamic information that changes during the playback of the elementary stream specified.
  • the information described in DynamicInfoO becomes valid when the playback time indicated by the set pts_change_point is reached. The details of DynamicInfoO will be described later with reference to FIG.
  • EP—map 0 is placed after pts—change—point and DynamicInfoO of the set of number—0 and the number of Dynamic Info. Note that EPjnap 0 will be described later with reference to FIG. Description of rstatidnfoO "
  • 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 element list corresponding to the StaticInfoO is determined by the stream_id and private_stream_id included in the Semlnfo0 of FIG. 10 including the StaticInfoO.
  • StaticInfoO uses picture-size (4 bits), frame-per-rate (4 bits), and cc-flag (1 Bit) and reserved reserved—for—word—a lingment for taking a single door line.
  • picture—size represents the size of the video data (the image displayed by) corresponding to the video stream.
  • frame-rate represents the frame frequency of the video data corresponding to the video stream.
  • cc_flag indicates whether or not the video stream includes closed caption (Closed Caption) data. That is, for example, if the video stream includes closed caption data, cc_flag is set to 1; if the video stream does not include closed caption data, cc_flag is set to 0. You.
  • Staticlnfo 0 is audio—language—code (16 bits), channel—conf iguration (8 bits), lfe—existence (1 bit), sampling—frequency (4 bits), and reserved—for—word—a lingment
  • audio-language-code describes a code representing the language of the audio included in the audio stream.
  • the channel configuration indicates the attribute of audio data included in the audio stream, such as monaural (mono) / stereo (stereo) / multi-channel.
  • ling-frequency is information indicating the sampling frequency of audio data included in the audio stream.
  • Staticlnfo 0 is composed of subtitle_language_code (16 bits) and configable_flag (1 bit), and a word line 3 ⁇ 4 7t 3 ⁇ 4 ) 6 reserved_f or_word_al ingment.
  • subtitle language—code
  • conf igurable flag is information indicating whether the display of subtitle data included in the subtitle stream is allowed to be changed from the default display method. For example, the display method is allowed to be changed. If it is permitted, 1 is described, and if it is not permitted, 0 is described.
  • the display method of the subtitle data includes the display size of the subtitle data, the display position, the display color, the display pattern (for example, blinking display), and the display direction (for example, vertical or horizontal direction). .
  • FIG. 13 shows the syntax of DynamicInfoO.
  • DynamicInfoO At the beginning of DynamicInfoO, reserved—for—ord_alignment (8 bits) for the word line is arranged, and the content of the following elements differs depending on the attributes of the elementary stream corresponding to DynamicInfoO. .
  • the attribute of the elementary list corresponding to DynamicInfoO is determined by the stream_id and private-stream-id included in Streamlnfo 0 of FIG. 10 including DynamicInfoO, as in the case of StaticInfoO described in FIG. You.
  • 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, the data corresponding to the elementary stream corresponding to the DynamicInfoO, that is, the elementary stream is processed.
  • the output attribute of the data that is output as a result (the output attribute of the data obtained from the elementary stream) is described in DynamicInfoO.
  • Dynamiclnfo 0 is for display—aspect—rat io (4 hits) and word line And reserve_—for_word—alingment.
  • diplay-aspect-ratio 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-aspect-ratio, for example, information indicating whether the aspect ratio is 16: 9 or 4: 3 is described. In addition to the aspect ratio, the size of the image displayed by the video data (X pixels, XY pixels) Can be described.
  • Dynamiclnfo 0 is composed of reserved-for-word_alingment for taking 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 each elementary stream for each elementary stream multiplexed with the program stream stored in the clip stream file corresponding to the clip information file ClipO in FIG. 10 including the EP-map (). Describes the information of the point at which decoding can be started (entry point) at which decoding can start in the list.
  • the point at which decoding can be started can be obtained by calculation, but a variable-rate stream.
  • the point at which decoding can be started cannot be calculated, and the stream is not actually analyzed. And can not find.
  • Quickly recognizing the decoding start possible point is important for random access. According to EPjnapO, the decoding start possible point can be quickly recognized.
  • the start of the intra picture including Sequence-header 0 is a decoding start point.
  • EP—map () is reserved—for—word—alignment (8 bits) for the door line, followed by number_of—stream—id—entries (8 bits). It has been done. Ber—of—stream—id—entries indicates the number of elementary streams in which information on decoding startable points is described in EPjnap0.
  • the information for identifying the elementary stream and the information about the decoding start point of the elementary stream are number_of— stre am—id—Repeatedly arranged by the number represented by entries.
  • stream-id 8 bits
  • private_stream_id 8 bits
  • PTS_EP—start which is one of the information of the decoding start possible point, is in the clip stream file that stores the program stream in which the elementary stream specified by the stream_id and private_stream—id is multiplexed as described above. Represents the time (playback time) at which decoding can be started.
  • the elementary stream identified by stream-id and private-stream-id is multiplexed in the other one of the information of the decoding start possible point 11 ⁇ _61 ) -31 & 1 ⁇ as described above.
  • the value at which the decoding start possible position is counted in pack 0 of the program stream is described.
  • the size of packO is fixed at 2048 bytes.
  • one section of the disk 101 (FIG. 1) is 2048 bytes.
  • a private-stream_2 packet (PES-packet () with the attribute of private-stream-2) described below is placed immediately before the decoding start point (entry point).
  • rivate—stream—2 packets contain information used to decode the video stream located between the private—stream—2 packet and the next private—stream—2 bucket. Have been.
  • the RPN-EP-start as information on the decoding startable point is not the actual decoding startable point itself, but the private located immediately before the actual decoding startable point.
  • Stream Describes the start position of the two buckets.
  • PTS-EP_start_ti RPN_EP_stt (D-ty is used for each elementary stream specified by stream-id and private-stream-id , Which are sorted in ascending order in advance, so that the set of PTS-EP-31 & and! ⁇ 1 ⁇ -81 ) -5 1 ⁇ as the information of the decoding start possible point can be binary searched. I have. '
  • the clip stream file is based on MPEG2-Program-StreamO 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—Program—StreamO defined in Table 2-31 of the MPEG-2 System standard, one or more packs 0 and one MPEG—program—end— Consists of code.
  • MPEG2-Program-StreamO is also described in Japanese Patent No. 2785220.
  • One packO consists of one Pack—header 0 and an arbitrary number of PES—packet 0 as defined in Table 2-32 of the MPEG-2 System standard. Is done. 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.
  • the number of PES-packetOs in one packO is one, two, or three. If PackO starts with pri ivate-stream- 2 packets described later, there is always a PES- packet () of the corresponding video stream immediately after (in the same PackO). In addition, a padding packet can be placed as the third PES_packet 0. Note that private-stream- 2 packets are always placed at the beginning of PackO.
  • PackO does not start with private—stream—2 packets
  • PackO is preceded by PES—packet 0 that stores the content data such as video, audio, and subtitles.
  • a padding-packet can be placed as the second PES-packet 0.
  • FIG. 16A and FIG. 16B to FIG. 18A and FIG. 18B show PES-packet 0 defined in Table 2-17 of the MPEG-2 System standard.
  • PES-packet_length whose structure changes according to packet_start—code—prefix, stream—id, and PES—packet_length (FIGS. 16A and 16B) and stream—
  • Information indicating a display timing called a Presentation Time Stamp and information indicating a decode timing called a DTS (Decoding Time Stamp) can be arranged.
  • a PTS is added to all access units (decoding units that constitute an elementary stream defined by MPEG2-System), and a DTS is added when specified in MPEG2-System.
  • the element list multiplexed in the program stream is stored in PES_packet_data_byte (FIG. 18A and FIG. 18B) of PES_packet0.
  • PES_packet_data_byte (FIG. 18A and FIG. 18B) of PES_packet0.
  • a value corresponding to the attribute of the elementary stream is described in order to identify the elementary stream stored in the PES-p_acket_data_byte.
  • FIG. 19A and FIG. 19B show Table 2-18 of the MPEG-2 System standard.
  • the value shown in FIG. 20 among the stream_ids defined in the MPEG-2 System standard shown in FIGS. 19A and 19B is adopted.
  • the stream_id of the PES-packet 0 of the elementary stream with the attribute called private-stream-1 is 10111101B as shown in FIG. Is done.
  • the stream_id of the PES-packet () of the padding-packet is set to 10111110B according to FIG.
  • the stream-id of the PES-packet 0 of the elementary stream of the attribute called private-stream-2 is 101111UB according to FIG.
  • the stream_id of the PES-packet () of the audio stream (audio elementary stream) defined by MPEG is set to ⁇ .
  • the lower 5 bits xxxxx of ⁇ ⁇ are audio stream numbers that distinguish the audio stream
  • the program stream (MPEG2—Program—Stream 0) contains a number that can be distinguished by this audio stream number.
  • the stream-id of PES-packet 0 of the video stream (video elementary stream of video) defined by MPEG is set to 11 ⁇ .
  • the lower 4 bits xxxx of ⁇ ⁇ ⁇ are video stream namers for distinguishing video streams, and the program stream is a number that can be distinguished by the video stream namers.
  • the video stream (defined video stream in MPEG) can be multiplexed.
  • PES-packet 0 having a stream-id of ⁇ is used to store a video stream defined by MPEG
  • PES-packetO having a stream-id of xxxxxxB is an audio defined by MPEG. Used to store streams.
  • the stream-id of PES-packet 0 used to store an elementary stream of a coding method not defined by MPEG is not specified by MPEG, and therefore Elementary stream of coding system not defined by MPEG As with video streams and audio streams defined in MPEG, stream-id cannot be simply specified and stored in PES_packet 0.
  • the PES_packet_data_byte of the PES_packet () of the private_stream-1 is extended to store an elementary stream of a coding scheme not defined by MPEG.
  • Figure 21 shows the syntax of private-streamlJES-payloadO.
  • Private_streaml_PES_pay load 0 is composed of private—header 0 and private—payloadO.
  • private—pay load 0 stores an elementary stream of an encoding system 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 beginning of private—header ().
  • private-stream-id is identification information for identifying an elementary stream stored in private-payloadO, 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 list stored in private-payload0.
  • three patterns of OOOOxxxxB, OOOlxxxxB, and ⁇ are adopted as values of private—stream_icl.
  • "x" represents an arbitrary value of 0 or 1, as in the case of FIG.
  • the ATRAC audio stream is private—payload
  • the private-stream-id of private-streaml_PES-payloadO stored in 0 is OOOOxxxxB.
  • the private-stream-id of the private-streaml-PES-payloadO in which the LPCM audio stream is stored in the private-payloadO is OOOlxxxxB.
  • the private-stream-id of the private-streaml-PES-payload 0 in which the subtitle stream is stored in the private-payloadO is lOOxxxxxB.
  • FIG. 11 summarizes the relationship between FIG. 20 and FIG.
  • private-stream_id in private-stream and PES-payloadO, the elements following private-stream_id have different contents depending on the attributes of the element list stored in private_payload0.
  • private— payloa The attribute of the elementary stream stored in d () is determined by the private-stream-id at the head of private-header ().
  • the reserved-fo future-use (8 bits) for future expansion is AU-locator (16 bits) is allocated after that.
  • the AU-locator uses the position immediately after the AU-locator as a reference, and the private access of the ATRAC audio stream audio unit (ATRAC audio access unit) (audio frame) stored in payloadO. Indicates the head position. If there is no audio access unit in private_payload (), for example, OxFFFF is described in AU-locator.
  • fs—flag 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, if the LPCM audio stream is monaural, ch-flag is set to 1, and if the LPCM audio stream is stereo, ch-flag is set to 2.
  • the AU-locator uses the position immediately after the AU-locator as a reference, and the audio access unit (LPCM audio access unit) (LPCM audio access unit) of the LPCM audio stream stored in the private-payloadO. Frame). If there is no audio access unit in private-payloadO, for example, OxFFFF is described in AU-locator.
  • the AU-locator indicates the head position of the subtitle access unit of the subtitle stream stored in private-payloadO with reference to the position immediately after the AU-locator. If no subtitle access unit exists in private-payloadO, AU_locator describes OxFFFF, for example.
  • Fig. 23 shows the syntax of private-stream2-PES-payloadO.
  • PES— payload is the PES of private— stream— 2—the PES_packe of the packed tO and an extension of the data—byte (FIGS. 18A and 18B), that is, the PES of the private_stream_2.
  • An extended PES-packet-data-byte of one packet 0, which describes information used for decoding the video stream.
  • PES_packet 0 of private_stream_2 is arranged immediately before a decoding start possible point in the video stream. Therefore, in this embodiment, if the private-stream-2 PES_packet () is found from the program stream, the decoding can be started from the video stream immediately after that.
  • the RPN-EP-start of EPjnapO in Fig. 14 described above is the start position of PES_packet () of private stream-2 for the video stream. Indicates.
  • PES— payloadO has a reserved_for_future_use (8 bits) for future expansion at the beginning, followed by video_s t ream— id (8 bits), IstRef one picture (16 bits), 2ndRef one picture (16 bits), 3rdRef_picture (16 bits), 4thRef_picture (16 bits), au-information (), and VBIO are arranged sequentially.
  • the video stream (the PES that stores the video stream that is decoded using the information stored in the private-stream 2 packet's PES-packet 0 (private-stream2-PES_pay load 0) by this video-stream-id packet 0) is specified.
  • IstRef— picture, 2ndRef— picture, 3rdRef— picture, 4thRef_picture is a PES of packet video stream identified by video— stream— id.
  • the IstRe picture, 2ndRef_picture, 3rdRef picture, and 4thRe picture are described in, for example, Japanese Unexamined Patent Application Publication No. 09-46712 (Japanese Patent Application No. 07-212420), bytes—to—first—P_pic by tes—to_second_P — The details are disclosed as pics.
  • au_information describes information about the video access unit in the video stream from PES-packet 0 of private-stream-2 to the next PES-packet 0 of private_stream_2. The details of au-informationO will be described later with reference to FIG.
  • VBIO is used to describe Closed Caption information. Private str with private_stream2_PES_payload () PES-packet 0 of earn-2 is placed at each decoding start possible point for each video stream.
  • Fig. 24 shows the syntax of au-informationO in Fig. 23.
  • au informationO is prefixed with length (16 bits). length indicates the size of au-informationO containing it. Following the length, reserved—for one word—alignment (8 bits) and number—of—access—unit (8 pits) are arranged in order. reserved—for—word—al ignment is used to take a single door line.
  • the number—of—access—unit is the private—stream 2—PES—payloadO in FIG. 23, the private—stream—2 PES with the same video—stream_id—the packet 0, From ormatnio 0 to just before the next au— information 0 (if this au—infromationO is the last au—informationO in the clip stream file, by the end of the clip stream file), video—stream— Indicates the number of access units (pictures) included in the video stream indicated by id.
  • the contents of the for loop are arranged for the number of the number—of—access—units.
  • one or more video access units included between PES-packet 0 of private-stream-2 and PES_packet () of the next private-stream-2 including number-0 and access_unit Information is placed.
  • pic_struct_copy (4 bits), au_ref_f 1 ag (1 bit), AU-length (21 bits), and reserved are arranged in the for loop.
  • pic_struct—copy contains, in the case of MPEG4-AVC (IS0 / IEC 14496-10), the corresponding video access unit, which is set to IS0 / IEC 14496-10, D.2.2.
  • pic-struct 0 is information such as displaying a picture as a frame or displaying a top field of a picture and then displaying a bottom field.
  • au—ref—flag indicates whether the corresponding access unit is a reference image that is referred to when decoding another access unit (picture of), and is set to 1 if it is a reference image, and is referred to. If it is not an 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 the above-described format data recorded on the disc 101 in 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, 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 occasionally supplied from the buffer control module 215 in FIGS. 2A and 2B to the caption decoder control module 218 and decoded.
  • FIGS. 25 to 28 show that the three clip information files “000 01.CLP”, “00002.CLP”, and “CIP” are stored in the “CLIP” directory on the disc 101 as shown in FIG. "00003. CLP” is recorded, and the three clip information files “00001. CLP”, “00002. CLP”, and “00003. CLP” are stored in the "STREAM” directory.
  • "PLAYLIST.DAT” file and clip information files "00001. CLP”, “00002. CLP”, and “00003.PS” when “0001.PS", "00002.PS” and “00003.PS” are recorded. Specific examples such as “CLP” are shown. However, in FIGS. 25 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.
  • the number of PlayLists is two, and the number of PlayLists is two. Therefore, the number of PlayListOs included in the “PLAYLIST.DAT” file is two. In FIG. 25, of the two PlayListOs, the first is PlayList # 0 and the second is PlayList # 1.
  • PlayList # 0 which is the first PlayList 0
  • capture—enable_flag—PlayList is 1, and therefore secondary use of video data played according to PlayList # 0 is permitted.
  • number_o and ayltems are two, and therefore, the number of PyltemOs included in PlayList # 0 is two.
  • Specific examples of the two PlayltemOs, PlayItem # 0 and Playltem # l, are described below the column of “PlayListtOj”.
  • Play Item # 0 which is the first Play Item 0 included in PlayList # 0
  • the Clip—Information—file—name described in FIG. 6 is “00001. CLP” and the In—time is 180 and 090.
  • 0UT_time is 27, 180, 090, respectively. Therefore, the clip reproduced by Playtem # 0 of PlayList # 0 is the time from 180, 090 to 27, 180, 090 of the clip stream file “00001.PS” corresponding to the clip information file “00001.CLP”. Up to.
  • the Clip—Information_file_name described in FIG. 6 is “00002. CLP”
  • the In_time is 90,000
  • the OUT—Ume is described in FIG. 27,090,000 respectively. Therefore, the clip reproduced by Pyl temifl of PlayList # 0 is from time 90,000 to time 27,090,000 of the clip stream file "00002.PS" corresponding to the clip information file "00002. CLP". is there.
  • PlayList # 1 which is the second PlayListO
  • the capture—enable—flag—PyList is 0, and therefore, the video data reproduced according to PyList # 1 Secondary use of is not permitted (prohibited).
  • PlayList # 1 number-of-Playltems is 1. 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”.
  • PlayItem # 0 which is one PlaytemO included in PlayList # 1
  • Clip_Information—file—name described in FIG. 6 is “00003. CLP”
  • In time is 90,000
  • OUT time Are 81,090,000 respectively. Therefore, the clip played by Playtem # 0 of PlayList # 1 is The time is from 90,000 to 81,090,000 in the crisp stream file "00003.PS" corresponding to the lip information file "00003. CLP”.
  • FIG. 26A and FIG. 26B show a specific example of the clip information file ClipO described in FIG. That is, FIGS. 26A and 26B show specific examples of the clip information files “00001. CLP”, “00002. CLP”, and “00003. CLP” in FIG.
  • the presentation—star t—time is 90,000 and the presentation—end—time is 27,990,000. 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) content is available.
  • capture—enable—flag_Clip is 1, and therefore, the clip stream file “00001.PS” corresponding to the clip information file “00 001.CLP”
  • the secondary use of the video stream (video data corresponding to) multiplexed with the program stream stored in is allowed.
  • the number_of—streams of the clip information file “00001.CLP” is 4, and accordingly, the corresponding clip stream file “00001.PS” Four element streams are multiplexed in the stored program stream.
  • FIGS. 26A and 26B A specific example of the StreamlnfoO (FIG. 10) of each of the streams stream # 0, streamtl, stream # 2, and stream # 3 is "" 00001 .CLP "" below.
  • the stream-id is OxEO. Therefore, the elementary stream stream # 0 is the 20th elementary stream. As described in the figure and FIG. 22 (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.
  • this video stream stream # 0 is 720 ⁇ 480 pixel video data having a frame period of 29.97 Hz, and further includes closed caption data.
  • the elementary stream stream # l is an ATRAC audio stream as described with reference to FIGS. 20 and 22.
  • the ATRAC audio stream stream # l which is the second elementary stream of the clip stream file "00001.PS" Is the audio_language-code power of StaticInfoO (Fig. 12) included in the StreamlnfoO. '[This, each has become. Therefore, this ATRAC audio stream stream is Japanese and stereo audio data. Also, a low-frequency emphasis channel is not included, and the sampling frequency is 48 kHz. Further, for the ATRAC audio stream stream, which is the second elementary stream of the clip stream file "00001.PS", the number of the StreamlnfoO (Fig. 10) and the Dynamiclnfo are 0, and pts_change—the set of point and DynamicInfoO does not exist.
  • this elementary stream stream # 2 is a subtitle stream as described with reference to FIGS. 20 and 22.
  • the subtitle_language_code of StaticInfoO included in Stre amlnfoO Is set to 'Japanese' and configurable-flag is set to 0. Therefore, this subtitle stream stream # 2 is Japanese subtitle data, and changing its display method is not permitted (prohibited).
  • the number—of Dynamiclnfo of Stream InfoO (FIG. 10) is 0, and pts —Change— Point and Dynamic Info 0 set does not exist.
  • the elementary stream stream # 3 is a subtitle stream as described with reference to FIGS. 20 and 22.
  • each private-stream is 0x80 and 0x81.
  • the subtitle stream stream # 2 which is the fourth elementary stream of the clip stream file "00001.PS"
  • code is 'Japanese' and configurable-Hag is 1 respectively. Therefore, the subtitle stream stream # 3 is Japanese subtitle data, and its display method is permitted to be changed.
  • the number of StreamInfoO (Fig. 10) is 0 and Dynamiclnfo is 0.
  • Pts_change the set of point and Dynamiclnfo 0 does not exist.
  • the presentation—start—time is 90,000 and the resention_end—time is 27,090,000.
  • 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
  • capture—enable_flag—Clip is 0, and therefore, the clip stream file “00002.PS” corresponding to the clip information file “00 002. CLP”.
  • the secondary use of the video stream multiplexed with the program stream stored in the (non-compliant video stream) is not permitted (prohibited).
  • the number—0 and streams of the clip information file “00002. CLP” is 4, and accordingly, the corresponding clip stream file “00002.PS” As in the case of the above-described crib stream file “00001.PS”, four elementary streams are multiplexed in the program stream stored in the “C” stream.
  • FIGS. 26A and 26B A specific example of StreamlnfoO (FIG. 10) of each of the streams stream # 0, streamtl, stream # 2, and stream # 3 is described below the column ““ 00002.CLP ””.
  • the first to fourth elementary stream 36 and 111 # 0 to # 3 of the clip stream file "00002.PS” Since the contents of amlnfoO are the same as the contents of Streamlnfo () of each of the first to fourth elementary stream streams # 0 to # 3 of the clip stream file "00001.PS", the clip stream file "00002.
  • the first elementary stream in PS is a video stream
  • the second elementary stream stream # l is an ATRAC audio stream.
  • the third elementary stream, stream # 2, and the fourth elementary stream, stream # 3, are both subtitle streams.
  • the presentation-star time is set to 90,000 and the resentation_end- time is set to 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", it is 900 seconds ((81, 090, 000-90, 000) / 90kHz). Content is available.
  • clip information file "00003. CLP” capture-enable-Hag-Clip is 1, and therefore, the clip stream file "00003.PS" corresponding to the clip information file "00 003. CLP”. Secondary use of the video stream multiplexed with the program stream stored in is allowed.
  • the number—of—streams of the clip information file “00003 ⁇ CLP” is 3, and therefore, the corresponding clip stream file “00003.PS” In the program stream stored in "", three elementary streams are multiplexed.
  • the three elementary streams are stream # 0, streamtl , Stream # 2, the specifics of the StreamlnfoO (FIG. 10) of each of the three elementary streams stream # 0, stream # 1, and stream # 2 are shown in FIGS. 26A and 26B. An example is provided below the "" 00003. CLP "" column.
  • the stream-id is OxEO. Accordingly, the elementary stream s eam # 0 is the second elementary stream. As described in FIG. 0 and FIG. 22 (or FIG. 11), it is a video stream. Note that, similarly to the first elementary stream stream # 0 of the clip stream file "00001.PS", the private_stream-id is 0x00.
  • 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—Dynamiclnfo of Stre amlnfoO (FIG. 10) is 2
  • the In Streamlnfo 0 two sets of pts—change—point and Dynamiclnfo 0 are described.
  • the stream-id is OxEl
  • the elementary elementary stream stream # l is Figure 20 and As described in FIG. 22 (or FIG. 11), it is a video stream.
  • Each stream-id is OxEO and OxEl.
  • the private_streamjd is 0x00.
  • the video stream streamttl which is the second elementary stream of the clip stream file "00003.PS"
  • the flag is the same as that for video stream stream # 0, which is the first elementary stream. Therefore, the video stream streamttl, which is the second elementary stream of the clip stream file "00003.PS", is a video stream of 720 x 480 pixels with a frame period of 29.97 Hz, and a closed caption. Does not contain data.
  • the elementary stream stream # 2 is an ATRAC audio stream as described with reference to FIGS. 20 and 22.
  • the ATRAC audio stream stream # 2 which is the third elementary stream of the clip stream file "00003.PS”
  • sampling-frequency is the same as that of ATRAC audio stream stream # l which is the second elementary stream of clip stream file '' 00001. PS " Therefore, the third elementary stream of clip stream file “000 03.PS”, ATRAC audio stream stream ⁇ , is Japanese and stereo audio data, and includes low-frequency emphasis channel. And the sampling frequency is 48kHz.
  • 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.
  • EP—map 0 number—0 and stream—id—entries are 1. Therefore, this EPjnapO contains information on the decoding start possible point for one elementary stream. Is described.
  • FIG. 27 is an EP-map () of the clip information file “00001.CLP”, and in the clip stream file “00001.CLP” corresponding to the clip information file “0000 1.CLP”, s eam_id is As described with reference to FIGS. 26A and 26B, the OxEO elementary stream is the first video stream stream # 0 of the clip stream file “00001. CLP”.
  • the information described in EP-map () in Fig. 7 is PTS-EP_start and RPN-EP_start at the point where the decoding of video stream stream # 0 can start.
  • FIG. 28 shows a specific example of PlayListMarkO in PlayList # 0 and PlayList # 1 (PlayList 0 in FIG. 5) described in FIG. .
  • FIG. 28 The upper part of FIG. 28 shows PlayListMarkO (FIG. 7) of PlayList # 0.
  • the seven Mark ( Mark # 0, which is the first MarkO in), is a cap mark because its mark-type (Fig. 7) is 'Chapter'.
  • Mark # 0 has re-to—Play Item—id (Fig. 7) set to 0, so the two PlayItems # 0 and # 1 in Fig. 25 included in PlayList # 0 are , PlayItem # 0.
  • Mark_0 has a mark_time-stamp of 180, 090
  • the time (playback time) of the clip stream file played by Playtem # 0 included in PlayList # 0 is 180, 090. It is.
  • MarkJO is not associated with any element evening stream because entry-ES-stream-id and entry-ES-private-stream_id are both 0.
  • Mar O represents the chapter with the number 1 because the mark-data is 1.
  • the clip stream file reproduced by PlayItem # 0 included in PlayList # 0 is described in Clip-Infomation-file-name of P1 ayltem # 0 described in FIG.
  • the clip stream file "00001.PS" specified from "00001 ⁇ CLP”. Therefore, the above-mentioned times 180 and 090 represented by the mark_time_stamp of Mark # 0 are the clip stream file "00001.PS”. PS ".
  • Mark # 4 which is the fifth MarkO among the seven MarkOs included in PlayList # 0 is a cap mark similar to the first Mark # 0.
  • Mark # 4 which is the fifth MarkO, is a cap mark because markjype (Fig. 7) is 'Chapter'.
  • Mark # 4 has a re_to_Play It em— id (Fig. 7) of 1, so the PlayList # 0 contains two PlayItems # 0 and # 1 of Fig. 25 included in PlayList # 0. Belongs to Playltem # l. Also, since Mark # 4 has 90,000 mark-t irae-sta immediately, the clip played by Playtem #l included in PlayList # 0 It is a mark on the stream file at time 90,000.
  • Mark # 4 has no entry-ES-stream-id and en try_ES-private-stream entry id of 0, so it is not associated with any elementary stream.
  • Mark # 4 has a mark-data of 2 and therefore represents a chapter with a number of 2.
  • the clip stream file played by Playltem # l included in PlayList # 0 is described in Clip-Infomat- lion-name of P1 ayltem # l described in Fig. 25.
  • the clip stream file “00002.PS” specified from “00002. CLP”. Therefore, the above-mentioned time 90,000 represented by the mark—time-stamp of Mark # 4 is the clip stream file. This is the time of "00002.PS".
  • Mark # l which is the second MarkO among the seven Marks () included in PyList # 0 has mark-type (Fig. 7) of 'Index'. It is an index.
  • Mark # l has a ref—to—Playltem_id (FIG. 7) of 0, so PlayItem # of the two PlayItem # 0 and # 1 in FIG. 25 included in PlayList # 0 Belongs to 0. Since Mark_l has mark_time-stamp of 5,580,090, the mark on time 5,580,090 of the clip stream file played by Playtem # 0 included in PlayList # 0 is there.
  • 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 has an index of 1 because mark-data is 1.
  • the clip stream file reproduced by PlayltemltO included in PlayList # 0 is the clip stream file “00001.PS” as described above.
  • the time 5, 580, and 090 described by the instant are clip stream files
  • Mark # 2 which is the third, sixth, and seventh MarkO of the seven MarkOs included in PlayList # 0, are the same as the second MarkO Index.
  • Mark # 3 which is the fourth MarkO in (), is an event mark because it has a mark-type (Fig. 7) E vent '.
  • Mark # 3 is an event mark because it has a mark-type (Fig. 7) E vent '.
  • Mark # 3 is an event mark because it has a mark-type (Fig. 7) E vent '.
  • ref_to_PlayItem_id (FIG. 7) is 0, it belongs to ayltem # 0 of the two PlayItems # 0 and # 1 in FIG. 25 included in PyList # 0.
  • the mark-time-stamp is 16, 380, 090, so the time 16, 380,090 of the clip stream file reproduced by PI ayl tem # 0 included in PlayList # 0. This is the sign above.
  • Mark # 3 is not associated with any elementary stream because entry-ES_stream_id and entry-ES-private-stream-id are both 0. For Mark # 3, since mark-data is 0, an event with 0 as an argument is generated.
  • the clip stream file reproduced by PI file # 0 included in PlayList # 0 is the clip stream file "00001.PS" as described above.
  • the time 16, 380, and 090 described by time—st amp are the times of the clip stream file “00001.PS”.
  • the time from the beginning of PlayItem () to which Mark 0 belongs is shown on the right side of the outside of the list of PlayListMarkO of PlayList # 0, and on the right side, PlayList # The time from the beginning of 0 is shown.
  • the lower part of FIG. 28 shows PyListMarkO (FIG. 7) of PlayList # l.
  • the number of MarkO included in PlayList # l (PlayListMarkO of PlayList # l) is 3 since the number of PlayList # O in PlayListMarkO is 0.
  • MarkJO which is the first MarkO of the three MarkOs included in PlayList # l, has a markjype (Fig. 7) of "Chapter". Mark. Further, Mark # 0 has a re-to-Play It em-id (FIG. 7) of 0, and therefore belongs to one PlayItem # 0 of FIG. 25 included in PlayList # l. Mark # 0 is a mark on time 90,000 of the clip stream file reproduced by Pyltem # 0 included in PlayList # l because mark-time-stamp is 90,000. . In addition, Mark # 0 is not associated with any elementary list since entry-ES-stream-id and entry_ES_private-stream_id are all 0. Also, Mark_0 represents the caption of number 0 because mark_data is 0.
  • the clip stream file reproduced by PlayItem # 0 included in PlayList # 1 is described in Clip-Infomat-file-name of PlayItem # 0 described in FIG.
  • the clip stream file "00003.PS” is a clip stream file "00003.PS” specified from "00003. CLP". Therefore, the above-mentioned time 90,000 represented by the mark_time_stamp of Mark # 0 is the clip stream file "00003.PS”. Time.
  • Mark # l which is the second MarkO among the three MarkOs included in PlayList # l, has a mark-type (Fig. 7) of 'Event'. Mark. Mark # l is included in PlayList # l because ref—to Playltem id (Fig. 7) is 0. It belongs to one PlayItem # 0 in FIG. Also, since Mark # l has the mark-time-s immediate value of 27,090,000, the clip stream played by 1> 1 & 1 tem # 0 included in 1 > 1 & 1 ⁇ 31 # 1 This is a mark on the file at time 27,090,000.
  • the element stream is identified (identified) by stream-id of OxE0. That is, as described in FIG. 20 and FIG. 22, it is associated with the video stream. Markiil generates an event with 1 as an argument because mark-data is 1.
  • the clip stream file reproduced by PlayItem # 0 included in PlayList # l is the clip stream file "00003.PS" as described above.
  • the above-mentioned time 27,090,000 represented by stam P is the time of the clip stream file “00003.PS”.
  • the video stream having the stream_id of OxEO to which MarkJl is associated is the Clip—Infomation—file of PlayItem # 0 included in PlayList # l in FIG. 25 to which the Mark # l belongs.
  • the stream described in “00003.CLP” described in the name is a Dex stream whose id is OxEO, that is, from the clip information file “00003.CLP” in FIG. 26A and FIG. 26B.
  • Mark # 2 which is the third MarkO among the three MarkOs included in PlayList # l, has a mark-type (Fig. 7) of "Evennt". It is an event mark. Furthermore, Mark # 2 has a ref_to Playltem_id (Fig. 7) of 0, so it is included in PyList # l. It belongs to one ayltem # 0 of Fig. 25 included. Mark #l has a mark-time-stamp of 27,540,000, so the time 27,540, of the clip stream file reproduced by PlayItem # 0 included in PlayList # l It is a mark above 000.
  • the clip stream file reproduced by PlayItem # 0 included in PlayList # l is the clip stream file “00003.PS” as described above, and thus represents the Mark # 2, as described above.
  • Time 27,540,000 is the time of the clip stream file "00003.PS”.
  • the video stream with stream-id OxEl associated with Mark # 2 is the Clip-Infomat- ment-file of PlayItem # 0 included in PlayList # l in Fig. 25 to which Mark # 2 belongs.
  • Stream described in “00003. CLP” described in name Video stream with id OxEl, ie, from clip information file “00003. CLP” in FIG. 26A and FIG. 26B
  • the second elementary stream (video stream) s eam # l of the three elementary streams stream # 0 to # 2 multiplexed in the clip stream file "00003.PS" to be recognized.
  • the time from the beginning of the ayItem () to which Mark 0 belongs is shown on the right outside the column of the PlayListMarkO list of PlayList # l.
  • cap mark and index mark are Although the number of the index index to be represented is described in mark-data, the number of the index to be represented by the capture index is not described in mark_data, for example, P It can be recognized by counting the number of cap index marks in the ayL istMark O.
  • 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 executes the file of the operating system 201 in step S101.
  • the disc 101 is checked using the system function, and it is determined whether the disc 101 is a normal disc for the video content reproduction program 210.
  • step S101 when it is determined that the disk 101 is not a normal disk, that is, for example, the file system adopted for the disk 101 corresponds to the operating system 201. If the type is not compatible, or if the "VIDEO" directory is not located in the root directory, the video content playback program 210 determines that it is not compatible with the disc 101, and proceeds to step S10. Proceeding to 2, the graphics processing module 219 performs error processing and ends the pre-playback processing.
  • the graphics processing module 219 generates an error message indicating that the disk 101 is not normal (video data of the disk 101) as an error processing, and outputs the error message from the video output module 220. Then, an error message is displayed.
  • the error processing for example, it is possible to output a warning sound from the audio output module 221 or eject the disk 101 from the disk drive 102. It is.
  • step S101 determines whether the disk 101 is a normal disk. If it is determined in step S101 that 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. 3 by operating system 2 0 1 and disk 1 0 1 (Fig. 4) Requests and reads two files, a "SCRIPT. DAT” file and a "PLAYLIST.DAT” file located in the "VIDEO" directory, and proceeds to step S104. move on. In step S104, the "SCRIPT.MT” file is supplied to the script control module 211, and the "PLAYLIST.DAT” file is supplied to the player control module 212.
  • step S104 proceeds from step S104 to S105 to S107, and the player control module 221 performs an initialization process.
  • the script control module 211 waits until the initialization processing of the player control module 211 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, and the player control module 2 12 reads the “PLAYLIST.DAT” file in FIG. Since number—of_PyLists is 2, it recognizes that there are two PlayLists (), the first PlayList # 0 and the second PyList # l. Further, the player control module 2 1 2 determines the number_of—Playltems for the first PlayList # 0 in the “PLAYLIST.DAT” file in FIG. 1 & 51 # 0 recognizes that there are two PlayltemOs, the first PlayItem # 0 and the second PI ayl tem # l.
  • the player control module 2 1 2 includes the first PlayItem # 0 and the second PlayItem # l included in P1ayList # 0 in the “PLAYLIST.DAT” file in FIG.
  • the clip information file (file name) of the first PlayItem # 0 included in PIayList # 0 is "00001. CLP”
  • the second Playltem # l Recognize that the clip information file is "00002. CLP”.
  • the player control module 2 1 2 has one P1 ayltemO (PlayltemfO) because the number—ofJ ayltems is 1 for the second PlayListiH, and furthermore, the PiayItem # 0 C1 ip—Information—file—name, etc., recognizes that the clip information file of PI ayl tem # 0 is “00003. CLP”.
  • P1 ayltemO PlayertemfO
  • 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.
  • step S106 the reading of the clip information file in step S106 is sufficient only with the clip information file of PUyltem of PlayListO to be played first, but in the present embodiment, as described above, The clip information file of PlayltemO of NayList 0 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 a clip stream file corresponding to the read clip information file exists on the disc 101 or not. That is, in step S107, the clip information files "00001. CLP", “0000 2. CLP”, and “00003. CLP” are read successfully, and Clip files "00001.PS”, “00002.PS”, “00003.PS”, which are different from the information files "00001. CLP", "00002. CLP” and "00003. CLP” only in the file name extension. Determines if "" exists in the "STREAM” directory under the "VIDEO" directory on disk 101.
  • 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, if the clip information file required for playback according to the “PLAYLIST.DAT ′ ′ file ⁇ the clip stream file is not recorded on the disc 101, the video content playback program 2 If it is determined that the disc does not correspond to the disc 101, the process proceeds to step S102, where the above-described error processing is performed, and the pre-playback processing ends.
  • step S107 it is 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 212 ends the initialization processing, and proceeds to step S108.
  • step S108 the script control module 211 starts interpretation and execution of the "SCR LPT. DAT" file.
  • FIG. 30 shows that the video content reproduction program 210 It is a flowchart explaining a reproduction process.
  • the player control module 2 1 2 first receives the PlayListO instructed by the scribing control module 2 1 1 in steps S 1 2 1 and S 1 2 2, that is, the first PlayList 0 (PlayList 0). # 0) playback preparation process is performed.
  • step S121 the player control module 211 checks the IN-time (FIG. 6) of the first PlayltemifO included in the first PlayListitO, and proceeds to step S122.
  • the clip stream file "00001.PS" played by the first PlayItem # 0 included in the first PlayList # 0 the? Investigate the playback start position corresponding to 11 1116 of 1 & ⁇ 6111 # 0 to start playback.
  • the IN-time of the first PlayItem # 0 included in the first PlayList # 0 is 180,090.
  • the player control module 2 1 2 is the EP shown in Fig. 27 of the clip stream file "00001. CLP" played by the first PI ayl tem # 0 included in the first PlayList # 0. — From map (), find a playback start position suitable for the IN-time of Playtem # 0 180, 090.
  • the player control module 2 1 2 calculates the expression PTS-EP_s of the PTS EP start indicating the decoding start possible point described in EP-map ().
  • tart ⁇ IN Search for the largest PTS—EP—start that satisfies time by using a binary search or the like.
  • PTS-EP_start below IN-time is searched is that the position represented by IN-time is not always the decoding start possible point.
  • IN-time is 180,090 as described above.
  • the player control module 2 1 corresponding to the retrieved PTS- 6? -31 &! 0) 181) -3 ⁇ & Dearu 305 (sectors) is read, is that 305 RPN_EP-
  • the position on the clip stream file "00001.PS" represented by "start” is determined as the reproduction start position.
  • the player control module 2 12 proceeds from step S 122 to step S 123 to control the graphics processing module 219 so as to display the time code.
  • the graphics processing module 219 generates a time code (video data thereof) 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 displayed at step S123 is, for example, a value obtained by converting the head of PlayListO into 00:00:00 (hour: minute: second). Note that the number of the cap index may be displayed together with the time code or instead of the time code. Analysis of rpiayl istMarkO "
  • step S124 the player control module 221 performs the PlayList (), which is instructed by the script control module 211 to play, That is, an analysis process for analyzing PlayListMarkO (FIG. 7) described in the first ⁇ PlayList 0 (PlayList # 0) is performed.
  • the player control module 2 1 2 in the P 1 ayL is tMark 0 shown in the upper part of FIG. 28, of number_o of the first PlayList # 0 in the “PLAYLIST.DAT” file that has already been read. Since f_P lyList_marks is 7, it is recognized that the number of MarkOs included in PlayList # 0 is 7.
  • the player control module 2 12 analyzes the seven MarkOs in the upper part of FIG. 28 included in the PlayListlfO, and from the re-to-Playl tem_id, the first to fourth of the seven MarkOs. It recognizes that the four MarkO up to belong to the first PlayltemO (PlayItem # 0) of PlayList # 0.
  • the player control module 2 1 2 extracts the mark-time-stamp of the four MarkOs belonging to the first PyItem # 0 of PlayList # 0, and as an array having four elements, decode control module 2 Pass to 14. That is, by this, the mark—time_st amp 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 ⁇ , ⁇ 16, 380, 090 ⁇ are passed from the player control module 212 to the decode control module 214.
  • Decode control module 2 1 4 A message indicating that the time measured in A matches the time of the “mark processing” attribute, the time that matches the “mark processing” attribute time, and the “mark processing” attribute. To the player control module 2 1 2.
  • step S124 the player control module 212 determines an elementary stream to be reproduced.
  • the player control module 2 1 2 transmits the CI of the first PyItem # 0 (FIG. 25) in the first PlayList # 0, which is the PI ayList 0, which is instructed to be reproduced by the script control module 2 1 1.
  • the clip information file “00001. CLP” in FIG. 26A and FIG. 26B in which the file name is described in ip—Information—fime—name, the number—of_st reams is 4, Recognize that four elementary streams are multiplexed in the corresponding clip stream file "00001 • PS".
  • the player control module 2 1 2 needs the stream-id of the StaticInfoO of the clip information file “00001. CLP” in FIGS. 26A and 26B for the four elementary streams.
  • the private_stream—id is examined in order, and it is recognized that the four elementary streams are one video stream, one ATRAC audio stream, and two subtitle streams. That is, the number of elementary streams of each attribute multiplexed in the clip stream file “00001.PS” is recognized.
  • the information on the number of elementary stream streams of each attribute multiplexed in the clip stream file is used to switch the elementary stream during playback (audio switching, subtitle switching, etc.). Also, the subtitle stream is stored in the clip stream file. May not be present (subtitles are not included in the content), and information on the number of elementary streams in the “subtitle stream” attribute is used to determine whether or not a subtitle stream exists. .
  • the player control module 212 selects and determines the elementary stream to be reproduced based on the result of the above-described StickInfoO search. In this case, the player control module 221 multiplexes the elementary stream into the clip stream file “00001.PS”. Among the four elementary stream streams that have been converted, there is only one elementary stream with the attributes “video stream” and “audio stream”, so “video stream” and “audio stream”. There is no choice for the elementary stream with the attribute of “stream”, and one video stream and audio stream (ATRAC audio stream) is determined as the elementary stream to be played.
  • the two 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 streams is Although it is necessary to specify, the player control module 2 1 2 identifies the four elementary streams multiplexed in the clip stream file “00001.PS” by using stream—id and the necessary private stream. by id Do.
  • 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”.
  • a video stream is identified by the stream-id of OxEO, as described for the clip information file “00001. CLP” in FIGS. 26A and 26B.
  • the player control module 211 is an elementary stream having an attribute of “audio stream” among the four elementary streams multiplexed in the clip stream file “00001.PS”.
  • a certain ATRAC audio stream is referred to as a stream—id of OxBD and a private—of 0x00. stream—Specified by id.
  • each subtitle stream is a stream_id that is OxBD and a private_stream that is 0x80. — Specify with id, stream-id which is OxBD, and private- stream-id which is 0x81.
  • the stream can be specified.
  • the combination of stream-id and private-stream-id is a mechanism provided to extend the multiplexing of the MPEG2-System.
  • the MPEG2 standard Be bound.
  • sub-stream-id similar to private-stream-id is defined, but sub-stream_id is described on a data base for stream identification. It is not possible to write the stream information in a fixed area that describes 8 or 32 stream information (for example, VI4-49, Table 4.2.1- 2 (VTS-AST—A TRT), VI4-52, Table 4.2.1-3 (VTS—SPST—ATRT), etc.)
  • a combination of stream_id and private-stream-id describes a metadata.
  • the clip information file C1 ip () in FIG. 10 it can be represented by number_o and s eams.
  • the number of elementary streams multiplexed in the clip stream file can be described irrespective of the number (however, the range of numbers that can be represented by number_o and streams), and the clip information file Clip
  • the stream_id and private stream id as metadata described in () It can be specified from the combination.
  • the combination of the stream-id and the private-stream-id is a combination of the elementary stream multiplexed in the corresponding clip stream file in the clip information file of FIG.
  • entry_ES_stream_id ten try_ES_pri vate_s tream_id () ⁇ " ⁇ -& in PlayListMarkO in Fig. 7
  • the combination of stream_id and private-stream-id may be used to specify the elementary stream that describes the information of the start point that can be decoded, for example, in EP-map () in Fig. 14. Is also used.
  • step S125 the process proceeds from step S125 to S126, and the player control module 212 determines that the elementary stream to be reproduced in 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 played, that is, the video stream, ATRAC audio stream, and subtitle stream that are determined to be played in step S125.
  • the elementary stream to be played that is, the video stream, ATRAC audio stream, and subtitle stream that are determined to be played in step S125.
  • Investigate Dynamiclnfo (Fig. 10), which represents the number of DynamicInfoO (Fig. 13) in which the attribute is described.
  • the video stream, ATRAC audio stream, and subtitle stream to be played back are elementary streams multiplexed to the clip stream file “0 0001. PS”, and their number-0 Dynamiclnfo is 0 as described in “00001. CLP” in FIGS. 26A and 26B.
  • the player control module 2 1 2 does not perform any particular processing for controlling the output attribute of the elementary stream to be reproduced.
  • step S126 the process proceeds to step S127, in which the player control module 212 performs preparation processing for starting reproduction of the elementary stream to be reproduced.
  • the player control module 2 12 sends the content data supply module 2 13 a file name of a clip stream file “00001.PS” in which the elementary stream to be reproduced is multiplexed, and a step S 12.
  • 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 data head pointer stored in the data head pointer storage section 231 and the data stored in the data write pointer storage section 232 are stored.
  • the same value is assigned to the stored caption readout.
  • the data head pointer stored in the data head pointer storage unit 231, and the data write pointer stored in the data write pointer 2332 are stored in the buffer 215 of the buffer control module 215. Refers to the same position of A. This means that no effective data has been accumulated in the buffer 211A.
  • the player control module 211 sets the stream-id as identification information for identifying (identifying) the elementary stream to be reproduced, and further, if necessary, the private-stream-id and the buffer control module. Supply to Joule 2 1 5
  • the video stream having the attribute “video stream” is specified by the stream_id of OxEO
  • the ATRAC audio stream having the attribute “audio stream” is , OxBD stream-id, and private_stream_id of 0x00.
  • the subtitle stream with the attribute of “subtitle stream” is the OxBD stream—id and 0x80 of private—. Specified by stream_id.
  • the player control module 2 12 supplies these stream-id and private-str earn-id to the buffer control module 2 15.
  • the video readout function unit 2 3 3 3 outputs the stream-id from the player control module 2 1 2, which is the OxEO for the video stream, to the stream 1 It is stored in the id register 242. Also, the audio reading function unit 234 uses the stream_id register 252 as a stream_id as OxBD and a private_stream_id as 0xOO from the player control module 212.
  • the subtitle read function unit 2 35 from the player control module 2 12, outputs the stream_id of OxBD and the private-stream-id of 0x80 by using the stream-id register 26 3 and the private-stream —
  • the subtitle read function unit 2 35 from the player control module 2 12, outputs the stream_id of OxBD and the private-stream-id of 0x80 by using the stream-id register 26 3 and the private-stream —
  • the player control module 2 12 stores the stream-id and private-stream-id of the elementary stream to be played back supplied to the buffer control module 2 15 for future processing.
  • the player control module 2 1 2 uses these stream-id and private-stream-id when a message requesting a stream switching described later occurs, or to specify a stream that is currently being reproduced in mark processing described later. use.
  • the player control module 2 12 initializes the buffer control module 2 15 (Fig. 3), and also adds subtitles with values according to the clip stream file in which the elementary stream to be played is multiplexed.
  • the read function flag is set in the subtitle read function flag storage unit 261.
  • the subtitle read function unit 235 functions. In order to perform this, a subtitle read function flag having a value of 1 is set in the subtitle read function flag storage unit 261. If the subtitle stream is not included in the clip stream file in which the element list to be played is multiplexed, the subtitle read function flag storage unit 26 1 contains a subtitle read function flag with a value of 0. Set. In this case, the subtitle reading function section 235 does not function (in particular, no processing is performed).
  • the player control module 2 1 2 is a script control module.
  • the first PlayItem # 0 (Fig. 25) contained in the first PlayList # 0 (Fig. 25) included in the first PlayList # 0 instructed to play from the file 211 is the IN-time of 180,090 and the OUT-time of 27, 180, 090 to the decoded control module 214.
  • IN-time controls the start of decoding of the clip reproduced by PI ayl tem 0, 0UT_time controls the end of decoding of that clip, and Used for control respectively.
  • 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, for example, the default display method.
  • the player control module 212 controls the content data supply module 212, whereby the content data supply module 212 operates the operating system.
  • the content data supply module 2 13 specifies the clip stream file “00001.PS” in the “STREAM” directory under the “VIDEO” directory on the disc 101 (FIG. 4).
  • the operating system 201 is requested 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 reading of the program stream stored in the clip stream file “00001.PS” from the disc 101 is started, and the program stream is supplied to the buffer control module 215 ⁇ 5.
  • the buffer control module 2 15 (FIG. 3) stores the program stream read and supplied from the disk 101 at the position pointed to by the data write pointer of the data write pointer storage section 232 of the buffer 215 A. And the write pointer is incremented by the size of the written data.
  • the content data supply module 2 13 reads the data from the disk 101 if there is free space in the buffer 2 15 A of the buffer control module 2 15, It is supplied to and stored in the buffer 215 A of the buffer control module 215. Therefore, it is assumed that a sufficient amount of data is constantly stored in the buffer 215A.
  • the decoder control module 216 controls the video decoder control module 216, the audio decoder control module 217, and the subtitle decoder control module 218. 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 response to the request, the buffer control module 2 1 Five 1 video access unit stored in buffer 2 15 A passed from the, 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 Pic-st ruc and copy, au-re and ag, AU-l get ength etc.
  • the time stamp is passed from the video decoder control module 2 16 to the decode control module 2 14 each time the video decoder control module 2 16 obtains the video access unit.
  • 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 obtains one (ATRAC) audio access unit stored in buffer 215A and the time stamp (PTS, DTS) attached to the 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 215A
  • PTS time stamp
  • the subtitle decoder control module 218 requests data from the subtitle reading function unit 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 added 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.
  • the element to be played If the subtitle stream does not exist in the evening stream, or if the subtitle access unit is not stored in the buffer 215A, the data from the buffer control module 215 to the subtitle decoder control module 218 is Is not passed.
  • the video decoder control module 2 16 each time 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 passed to the decode control module 214.
  • 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 Then, the process proceeds from step S129 to S130, and decoding of the data is started.
  • the decode control module 214 receives the 180,090 that is the Iltime of the first PlayItem # 0 included in PlayList # 0 given from the player control module 212 in step S127, Based on the time stamp passed from the decoder control module 2 16, audio decoder control module 2 17, and subtitle decoder control module 2 18 as described in step S 129, it is necessary to secure synchronization.
  • the decoding is commanded to the video decoder control module 216, the audio decoder control module 217, and the subtitle decoder control module 218, with the timing shifted if necessary.
  • the method of instructing the start of the decod by shifting the timing for ensuring the synchronization is described in, for example, Japanese Patent No. 3496725, and is simply described in the video decoder control module 2 16 and the audio decoder control.
  • the minimum value of the time stamps passed from the control module 2 17 and the subtitle decoder control module 2 18 is set as the initial value of the time measured by the timer 2 14 A, and the time is set.
  • 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. Further, 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 an instruction to start decoding from the decode control module 2 14, and responds to the instruction to read audio from the buffer control module 2 15 (FIG. 3).
  • One audio access unit obtained from the functional unit 2 3 4 is passed to an audio decoder 1 17 (FIG. 1) for decoding.
  • 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 sequentially decodes the audio access units obtained from the audio readout function section 2 34 of the buffer control module 2 15 by the audio decoder 1 17, respectively.
  • the audio data obtained as a result of decoding is supplied to the audio output module 2 2 1.
  • 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. You.
  • 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 with the subtitle decoding software that it has. 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 data supplied from the video decoder control module 216 as described above, and further, if necessary. hand The graphics processing is performed on the subtitle data supplied from the subtitle decoder control module 218.
  • the graphics processing module 219 first performs caption processing such as enlarging or reducing the caption data from the caption decoder control module 218 in accordance with a display mode instruction from the player control module 221.
  • caption processing such as enlarging or reducing the caption data from the caption decoder control module 218 in accordance with a display mode instruction from the player control module 221.
  • the graphics processing module 219 transmits the subtitle data from the subtitle decoder control module 218. , Save as is.
  • the graphics processing module 219 adds the video data from the video decoder control module 216 to the subtitle data from the subtitle decoder control module 218 or the subtitle data after the subtitle processing.
  • the output video data in which the subtitle 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 sends an instruction from the script control module 211 or the player control module 212 to display information such as a menu, a message, a time code, a caption, or an index number. If it receives the information, it generates the information, overlays it on the output video data, and supplies it to the video output module 220.
  • step S132 the video output module 220 outputs the output supplied from the delay processing module 219 as described in step S131.
  • Video data is sequentially stored in the FIFO22OA, and the output video stored in the FIFO22OA is stored. Data is output sequentially 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 FIFO 220 OA is sufficient, but if there is not enough, the output video data is output.
  • 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, and the FIFO 220 When 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. As a result, the graphics processing module 2 19, and further, the video decoder control module 2 16 and the subtitle decoder control module 2 18 restart the stopped processing.
  • the audio output module 221 also sequentially stores the audio data supplied from the audio decoder control module 217 as described in step S130 in FIF0221A, The audio data stored in the FIFO 221A is sequentially output at a predetermined output (sampling frequency).
  • the audio output module 221 has a storage capacity of FIF0 221 A (remaining As long as there is room, the audio data from the audio decoder control module 217 is accepted, but if there is not enough space, the audio decoder control module 217 stops the reception of audio data overnight. Request. As a result, the audio decoder control module 217 stops the processing.
  • the audio output module 221 requests the audio decoder control module 217 to stop accepting the audio data, and then the output of the audio data from the FIF02 21A proceeds, and the FIF0221A has a margin. At that point, the audio decoder control module 217 is requested to accept the audio data. As a result, the audio decoder control module 217 resumes the stopped processing. As described above, as data is output from the video output module 220 and the audio output module 221, the elementary stream is decoded.
  • the playback of the first Playltem # 0 of the first PlayList # 0 in FIG. 25 starts, but according to PlayList # 0
  • the playback of the second Playltem # l starts. That is, a PI aylt em transfer is performed in which the PI ay It em is transferred from the Play tem # 0 to the Play tem #l.
  • the decode control module 2 14 sets the time measured by the timer unit 2 14 A to the first PlayItem # 0 given from the player control module 2 12 in step 127 of FIG. If it becomes equal to the OUT-time of 27, 180, 090 (FIG. 25), in step S151, the decoding interruption control is performed, and the reproduction of PlayItem # 0 is ended.
  • the decode control module 214 operates the video decoder control module 211, the audio decoder control module 217, and the subtitle decoder control module 218 to stop the decoding operation. Further, the decode control module 2 14 controls the video output module 2 20 to continuously output the output video data that is currently being output. The decode control module 2 14 finishes playing the first PlayItem # 0. Is transmitted to the player control module 2 1 2.
  • the player control module 2 1 2 includes the first PlayList # 0 and the second PlayList # 1 in the first PlayList # 0 in step S105 in FIG. 29.
  • the process proceeds from step S 15 1 to S 15 2, and 2
  • the reproduction of the first Playltem # l is started in the same manner as in the case of the first PyltemifO described above.
  • the player control module 2 1 As in the case of step S 1 22 in FIG. For, the position of 1 ⁇ —8? —31 & 1 ⁇ described in EPjnap 0 is determined as the reproduction start position. Further, the player control module 2 12 recognizes Mark 0 belonging to the second Play It em # l as described in step S 124 of FIG. 30, and executes step S 1 25 5 of FIG. As described in, recognition of the number of elementary streams of each attribute multiplexed in the clip stream file "00002.PS" played by Play Item # l, and playback Yes The elementary stream (to be played) is determined.
  • the player control module 2 12 performs the same processing as in step S 127 of FIG.
  • the player control module 2 1 2 determines the RPN_EP_start of EPjnapO determined as the playback start position and the file name of the clip stream file in which the elementary stream to be played is multiplexed.
  • #l (Fig. 25)
  • CI ip Information—file—name The file name of the clip stream file “00002.PS” corresponding to “00002.
  • the player control module 2 12 starts supplying the buffer control module 2 15 with the program stream stored in the clip stream file “00002.PS” in which the elementary stream to be reproduced is multiplexed. Before the buffer control module 2 1 5 initialize.
  • the data start button stored in the data start pointer storage section 2 31 and the data write pointer storage section 2 32 are stored.
  • Data write pointer, video read pointer storage unit 241, video read pointer stored in the audio storage unit 251, audio read pointer stored in the storage unit 251, and subtitle read pointer storage unit 262 The same value is substituted for the stored caption readout button.
  • the player control module 212 also sets the stream_id as identification information for identifying the elementary stream to be reproduced, and further, if necessary. , Private_stream_id to the buffer control module 215.
  • the video readout function section 2 3 3 outputs the stream_id from the player control module 2 1 2 for the video stream of the elementary stream to be reproduced. Is stored in the stream-id register 242. Also, the audio reading function unit 234 outputs the stream_id and private_stream_id of the audio stream among the elementary streams to be reproduced from the player control module 212. stream—id Regis evening 2 5 2 and private— str eam_id Regis evening 2 53, respectively.
  • the clip stream file “00002.PS” in which the elementary streams to be reproduced are multiplexed includes the subtitle stream
  • the subtitle reading function unit 2 from the player control module 2 12 35, the stream-id and private-stream-id of the subtitle stream of the elementary stream to be played are supplied, and the subtitle is read.
  • the read-out function unit 235 stores the stream-id and the private-stream_id in the stream_id register 263 and 01 "& 16_36 &111" [1 register 264], respectively.
  • the player control module 2 12 initializes the buffer control module 2 15 (FIG. 3) by further adding a value corresponding to the clip stream file in which the element stream to be played back is multiplexed. Is set in the subtitle reading function flag storage unit 26 1.
  • the subtitle stream is included in the clip stream file “00002.PS” in which the element list to be reproduced is multiplexed, so that the subtitle reading function unit 235 functions. Therefore, a subtitle read function flag having a value of 1 is set in the subtitle read function flag storage unit 261.
  • the player control module 2 1 2 decodes the 90,000 IN_time and 27,090,000 OUT-time of the second Playltem # l (FIG. 25) to be played back.
  • the player control module 2 1 2 decodes the 90,000 IN_time and 27,090,000 OUT-time of the second Playltem # l (FIG. 25) to be played back.
  • 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 conf igurable_flag (Fig. 12) of the subtitle stream to be played is set to 1 that allows the display method to be changed, the subtitle stream from the player control module 2 1 2 to the graphics processing module 2 19
  • the indication of the stream display method is the same as the current display method. You may make it so.
  • the reproduction of the second Playltem # l is performed in the same manner as the reproduction of the first PlayItem # 0. Then, while the reproduction of the second Playltem # l is being performed, the decode control module 2 14 continues to check the time being counted by the built-in clock unit 2 14 A, and the clock unit 2 14 A Is the OUT—time of the second PyItem # l given from the player control module 2 1 in step S 1 52 (FIG. 31), 27,090,000 ( 25), the same decoding interruption control as in step S151 is performed, and the reproduction of Playltem # l ends.
  • step S123 of FIG. 30 the display of the evening 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 measured by the timer 214A is supplied to the player control module 212, and the flow advances to step S172.
  • step S 17 2 the player control module 2 12 receives the message from the decoded control module 2 14 and the current time, converts the current time into a time code, and 7 Proceed to 3.
  • step S 173 the player control module 2 12 performs the graphics processing so as to display the time code obtained in step S 172. Control module 219 and return to step S171.
  • the time code is updated every second.
  • the time code update interval is not limited to one second.
  • the elementary stream 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. It is given to the player control module 2.12 by executing or by the user operating the remote control.
  • the script control module 211 executes the scribing program in which the stream switching instruction is described, the script control module 211 supplies a stream switching request message to the player control module 211. Also, the input input 1 1 5 When a signal instructing stream switching is received from the remote controller by operating the player, a message requesting stream switching is supplied to the player control module 212.
  • a subtitle stream switching message which is a message requesting a subtitle stream switching, is supplied to the player control module 2 1 2,
  • step S191 the number of subtitle streams recognized when the elementary stream to be reproduced is determined in step S125 of FIG. 30 is checked.
  • the player control module 2 12 ignores the subtitle stream switching message, and accordingly, the subsequent steps S 192 to S 1
  • the process proceeds to steps S192 to S194 in order, and the subtitle stream to be reproduced is switched from the currently reproduced subtitle stream to another subtitle stream.
  • the player control module 2 12 specifies the currently reproduced subtitle stream on the clip information file. More specifically, for example, the stream multiplexed with the clip stream file "00002.PS" by the second Playltem # l constituting the first PlayList # 0 described in FIG. — Assuming that the subtitle stream with the id of OxBD and private—s stream—id of 0x80 is being played, in step S192, the subtitle stream that is currently being played is a clip stream file “00002.PS "Clip information file of Fig. 26A and Fig. 26B of two subtitle streams multiplexed in” It is specified that this is stream # 2, which is the third subtitle stream on LP ".
  • 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).
  • the next subtitle stream of the third subtitle stream stream # 2 is the fourth subtitle stream stream # 3 in the clip information file "00002. CLP". Therefore, in step S193, the fourth subtitle stream stream # 3 is recognized as the subtitle stream to be reproduced next.
  • the currently playing subtitle stream is the clip information file of Fig. 26A and Fig. 26B of the two subtitle streams multiplexed into the clip stream file "00002.PS".
  • the stream is the stream # 3 that is the fourth subtitle stream on “00002. CLP”, for example, the third subtitle stream is recognized as the subtitle stream to be reproduced next.
  • step S194 the player control module 212 transmits 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) to the subtitle reading function section 235 so that its stream-id and private-stream-id are used from the next reading from the subtitle access unit buffer 215A.
  • the buffer control module 215 (Fig. 3) to the subtitle reading function section 235 so that its stream-id and private-stream-id are used from the next reading from the subtitle access unit buffer 215A.
  • the stream-id and private-stream-id provided from the player control module 221 in step S 194 are represented by stream-id Register 2 6 3 and 1 "& 16_5 6 & 111-1
  • the subtitle access unit specified by the stream_id and private_stream_id newly set to the stream-id register 263 and the private-stream-id register 264, respectively. Performed on knits.
  • the subtitle stream to be reproduced is switched from the currently reproduced subtitle stream to another subtitle stream.
  • the buffer control module 215 has five pointers for reading and writing data from / to the buffer 215A.
  • the buffer control module 215 stores the data head pointer stored in the data head pointer storage section 231 and the data write pointer storage section 232 in the data write pointer storage section 232.
  • the subtitle readout stored in the unit 262 is provided.
  • the subtitle reading function flag storage unit 261, the stream ID register 263, and the PRIVATE-STREAM-ID register 264 of the read-out function unit 235 are not shown.
  • the data start pointer stored in the data start pointer storage unit 231 is the oldest data remaining in the buffer 215 A (data that needs to be read and data that has not been read yet). Represents the position of the oldest data (evening).
  • the data write pointer stored in the data write pointer storage section 232 indicates the position of the data write to the buffer 215 A, and this position is where the newest data is written in the buffer 215 A Is the position where
  • 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 is, as shown in FIG. 35, the one that points to the oldest data position among the video read pointer, audio read pointer, and subtitle read pointer. It is always updated to point to the same location.
  • the video read pointer, audio read The audio read pointer of the read pointer or subtitle read pointer points to the position of the oldest data, and the data start pointer matches the audio read pointer.
  • the data write pointer is When new data is read from 01 and written to buffer 215A, it is updated clockwise to point to the position immediately after the new data written.
  • 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, subtitle data, and the read data, and skips the read when reading. In addition, it will be the sum of the day and night parts of the other streams.
  • the data head pointer is the oldest data position in the video read pointer, audio read pointer, or subtitle read pointer. It is updated to point to the same location as that pointing to.
  • the buffer control module 215 writes the data to the buffer 215A in order to prevent the data write pointer from overtaking the data head pointer when writing data to the buffer 215A. Control. In other words, as long as no overtaking occurs at the head of the data due to the data write pointer, the buffer control module 215 determines the data read from the disk 101 as the buffer pointed to by the data write pointer. The buffer is written to the 2A position, and the data is updated. On the other hand, if it is about to overtake the first data point due to the data write pointer, the buffer control module 215 instructs the content data supply module 213 to stop reading data from the disk 101. (Interruption) is requested, and writing of data to buffer 2115A is stopped. As a result, it is possible to prevent the buffer 2A from overflowing.
  • the data read from the disk 101 is written to the buffer 215A by the positional relationship between the two buses, the first data bus and the data write button. Just controlled.
  • the buffer control module 215 sets the video read pointer, the audio read pointer, and the subtitle read pointer for reading the data from the buffer 215 A overnight, and furthermore, the data head pointer becomes the data write pointer. Control the reading of data from buffer 2 15 A to avoid overtaking.
  • the buffer control module 215 includes the video decoder control module 216 and the audio decoder control module.
  • data is read from the buffer 215A pointed to by the video read pointer, audio read pointer, or subtitle read pointer, and the video read pointer is read.
  • Audio read pointer also The 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 decoder control module The request from the subtitle decoder control module 218 or the subtitle decoder control module 218 is frozen, for example, and waited until a sufficient amount of data is prepared. As a result, underflow of the buffer 215 A can be prevented.
  • buffer 215A has a range from the position indicated by the data head pointer to the position indicated by the write pointer in the clockwise direction (shaded in FIGS. 34 and 35).
  • the 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.
  • Video read pointer, audio read pointer, and subtitle read pointer exist.
  • the data head pointer is updated so as to point to the oldest data position among the positions indicated by the video read pointer, the audio read pointer, and the subtitle read pointer.
  • the update of the data head pointer can be performed, for example, so as to point to the position of the past data for a predetermined time (for example, one second) from the position of the oldest data.
  • the video read button / audio read button indicates the position of the oldest data. It is expected that there are many cases.
  • the data head pointer is moved from the oldest data position pointed to by the video read pointer or the audio read pointer to, for example,
  • the buffer can be left at 2 15 A.
  • the audio read pointer points to the position of the oldest data
  • the data head pointer points to the position of the data that is one second past from that position.
  • the responsiveness of the disk device can be improved by updating the data pointer at the beginning of the data to point to the position of the past data for one second.
  • the head of the data is shifted from the oldest data position indicated by the audio readout button to the data position one second past the data position.
  • the data required to start the special playback is only one second stored in the buffer 215A. If it is past data, it is possible to start trick play immediately without re-reading data from the disk 101 as described above.
  • the buffer control module 215 sets the data start pointer, the data write pointer, and the video
  • the read pointer, audio read pointer, and subtitle read pointer are all initialized to point to the same location on buffer 215A.
  • the video reading function section 233 parses the program stream stored in the buffer 215A, and the video decoder control module
  • the program stream stored in buffer 215A is requested on request from 216.
  • a video stream (video access unit) is extracted (separated) from the video stream, read out, and supplied to the video decoder control module 216.
  • the audio readout function section 234 is also stored in the buffer 215A.
  • the audio stream (audio access unit) is analyzed from the program stream stored in the buffer 215A in response to a request from the audio decoder control module 217 in response to the parsing of the program stream thus obtained. It extracts and reads it out and supplies it to the audio decoder control module 217.
  • the subtitle read 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 and read from the program stream thus obtained, and supplied to the subtitle decoder control module 218.
  • the clip stream file If the elementary stream multiplexed with the program stream stored in the file "00001.PS" is the elementary stream to be played, the program stream is transferred from the disk 101.
  • the decoding start described in the EP_map () (FIG. 27) of the clip stream file "00001.PS” is started in step S122 of FIG. From the information on the possible points, 305 sectors are determined as the reproduction start position. Further, in step S128 of FIG. 30, 305 sectors as the reproduction start position are designated, and the operation system 201 is designated.
  • the information about the decoding startable point described in the EP-mapO indicates the position of the private-stream-2 PES-packet 0 located immediately before the actual decoding startable point.
  • step S211 the video readout function unit 2 3 3 proceeds to step S212, where the PES of the private-stream-2 is the PES of the packet ().
  • step 1 27 it is determined whether or not the stream ID matches the stream ID of the video stream to be reproduced, which is stored in the stream ID register 24 2 (FIG. 3).
  • step S212 when it is determined that the video-stream-id described in private-stream2-PES_payload () does not match the st-ream_id stored in the stream-id register 242, That is, if the PES-packet 0 of the private-stream-2 found in the immediately preceding step S211 is not located at the decoding start point of the video stream to be played back, the step S211 Then, a search is performed for PES-packet 0 of another private_stream 12 in the program stream stored in the buffer 215A, 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, If the PES packet 0 of private_stream—2 found in 2 1 1 is located at the decoding start point of the video stream to be played, the process proceeds to step S 2 13 and the video reading function unit 2 3 3 reads out au_informationO described in the private—stream 2 PES—packet 0 private—stream2—PES—pay 1 oadO from the buffer 2 15 A and reads the au_information () register 24 3 (third (Fig.), And proceed to step S214.
  • step S2114 the video readout function unit 233 converts the private-stream_2 PES_packet () (video_stream_id (Fig. 23)) found in the immediately preceding step S211 into a stream-id
  • the video read pointer stored in the video read pointer storage unit 231 is updated by the size of private—stream_2 PES_packet 0) that matches the stream_id stored in 242 (FIG. 3).
  • the video read pointer is updated so as to point to the position of the actual decode startable point of the video stream in step S2114.
  • step S2 14 proceeds from step S2 14 to S2 15 and the video readout function unit 2 3 3 determines whether or not the video decoder control module 2 16 has received the data request, and determines that there is no request. If so, the process returns to step S215, and the same processing is repeated.
  • step S215 If it is determined in step S215 that the data request has been received from the video decoder control module 216, the process proceeds to step S216, where the video reading function unit 233 sets the video reading point. While parsing the program stream from the position of the buffer 2 15 A pointed to by the au_information () register 243, while analyzing the program stream from the position of A, the number of bytes described in the AU_length of au—informationO stored in the au_informationO That is, one video access unit is read out from the buffer 215A and supplied to the video decoder control module 216, and the video read pointer is read out from the buffer 215A as one video access unit. Update by the size of the unit.
  • au-informationO contains the PES-packet 0 of private-stream-2 including it, and the next PES-packet () of private-stream-2. Describes the number of video access units (pictures) contained in the field.
  • au-informationO has pic-struct-copy, au-re as information on each video access unit as many as its number-of-access-units.
  • the flag and AU-length are described.
  • each AU-length is included between the PES-packet of the pri- vate-stream-2 that contains it and the PES-packet 0 of the next private-stream-2.
  • the number_of—access represents the size of each unit of the video access unit, so that the video reading function unit 233 uses the AU—length to access the access unit without parsing the video stream.
  • the program stream stored in the clip stream file recorded on the disc 101 is one or more of the video streams of the video access unit.
  • the private_stream_2 PES-packet () describing the AU-length indicating the size of the video access unit is included.
  • Str eam PES of 2 — Based on the AU_length described in packet 0, read video access units (video streams in units) from buffer 215A without parsing video streams, It can be supplied to the decoder control module 2 16.
  • the video readout function unit 233 when supplying the video access unit to the video decoder control module 216 in step S216, sends au-information as information on the video access unit.
  • the PIC—struct—copy, au_ref_flag and AU—length described in 0 and the time stamp (PTS, DTS) added to each video access unit are also supplied to the video decoder control module 211. I do.
  • 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 number_of_access_units of au_informationO (Fig. 24) stored in the au_informationO registry 243 has been processed.
  • step S217 if it is determined that the access units as many as the number_o and the number of the access-units have not been processed yet, that is, the number of the access units as many as the number-of-the access-units, If the data has not yet been read from the buffer 215A and supplied to the video decoder control module 216, the process returns to step S215, and the same processing is repeated thereafter.
  • step S 217 If it is determined in step S 217 that the number of access units represented by number—of—access—units has been processed, that is, the number of access units represented by the number_of—access—units is stored in the buffer.
  • the process returns to step S 2 11 to search for the PES_packet () of the next private stream 2, and so on. The process is repeated.
  • step S230 the audio readout function section 234 reads the playback data stored in the stream-id register 252 (FIG. 3) in step S127 of FIG. Checks whether the stre am—id of the target audio stream represents the PES—packet 0 of private stream—1 judge.
  • step S230 when it is determined that the stream-id stored in the stream-id register 2 52 does not represent the PES_packet 0 of the private-stream-1, that is, the stream-id register 25 2 If the stream-id stored in is an ⁇ ⁇ ⁇ assigned to an audio stream encoded according to the MPEG standard, as described in FIG. 20, the process proceeds to step S231, and the audio reading function unit The 234 searches the program stream stored in the buffer 215A for a synchronization code representing the head of the audio frame specified by MPEG Audio.
  • the audio read function unit 2 3 4 4 updates the audio read pointer to indicate the position of the start of the audio frame, and proceeds from step S 2 3 1 to S 2 3 2. move on .
  • the audio reading 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 pointer, and the flow advances 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 of the PES_packet () found in the immediately preceding step S232.
  • step S237 the audio readout function unit 234 determines whether or not a request for data has been received from the audio decoder control module 217. Same Is repeated.
  • 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 process proceeds to step S 238, and the audio read function unit 234 performs the audio read function. While parsing the program stream from the position of buffer 215 A pointed to by the output pointer, one known fixed-length audio access unit is read from buffer 215 A, and the audio is read. This is supplied to the audio decoder control module 217 together with the time stamp (PTS, DTS) added to the access unit. 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, and returns to step S237. Hereinafter, the same processing is repeated.
  • PTS time stamp
  • step S234 When the audio read function unit 234 finds the private_stream-1 PES-packet 0 in step S234, the process proceeds to step S235, and the private-stream 1 PES-packet 0 PES packet-data-by.
  • te Private—streaml_PES_payload () (FIG. 21) is extracted and the private_stream—id described in FIG. 21 is used as the private_stream_id register in the step S 127 of FIG. 30. It determines whether it matches the private-stream-id of the audio stream to be played, which is stored in Fig. 3).
  • step S 235 it is determined that the private—stream—id described in private—streaml—PES—payloadO does not match the private—stream_id stored in the private—stream—id register 253 If the PES—packet 0 of private—stream—1 found in the previous step S 234 is not the audio stream to be played back, the process returns to step S 234 and the buffer 2 15 A search for PES-packet 0 of another private stream-1 in the program stream stored in A is performed, and the same processing is repeated thereafter.
  • step S 235 the private_stream stored in the private—streaml—PES—payload () prprivate—s stream—id force s, private—stream—id register — If it is determined to match the id, that is, if the PES—packet 0 of private—stream—1 found in the previous step S 234 is an audio stream to be played back, step S 23 Proceeding to 6, the audio read function unit 234 stores the AU_locator described in the PES of the private_stream_l—private—s treaml—PES—pay load 0 of the packet 0 (FIG. 21) in the buffer 2 15 A From the AU-locator, and the value indicated by the AU-locator is added to obtain the head position of the audio access unit.
  • the AU-locator performs private-streaming based on the position immediately after the AU_locator, and performs priva- tion of PES_payload ().
  • te—pay l oad Indicates the head position of the audio access unit (or subtitle access unit) stored in O, so the value represented by AU—locat or is added to the position immediately after All oca or. By doing this, the (absolute) start position of the audio access unit can be determined.
  • the audio read function unit 234 further stores the audio read pointer storage unit 251 in step S 236 so as to point to the head position of the audio access unit obtained as described above.
  • the audio read pointer stored in the memory is updated, and the flow advances to step S237.
  • 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 process proceeds to step S 238, and the audio read function unit 234 A single fixed-length audio access unit is read from buffer 215A while parsing the program stream from buffer 215A, pointed to by the audio read-in button. The information is supplied to the audio decoder control module 217 together with the time stamp added to the audio access unit.
  • the audio readout function unit 234 updates the audio readout pointer by the size of one audio access unit read out from the buffer 215A, and returns to step S237.
  • 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 subtitle stream is included in the clip stream file in which the element stream to be reproduced is multiplexed. If it is not set and 0 is set in the subtitle read function flag storage unit 261 in step S127 of FIG. 30, the subtitle read function unit 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 added to the clip stream file in which the element stream to be reproduced is multiplexed. If “1” is set in the subtitle read function flag storage unit 26 1 in step S 127 of FIG. 30, the process proceeds to step S 25 2 and the subtitle read function unit 2 35 Searches for the PES_packet () that matches the stream_id of the subtitle stream to be played, stored in the stream-id register 26 3 (FIG. 3), from the program stream stored in the buffer 215A. .
  • the stream-id register 263 (FIG. 3) stores the stream-id of the subtitle stream to be reproduced.
  • step S252 the search for the PES-packet 0 of private_stream_l is performed, and when the PES-packet0 of private-stream_l is found, the process proceeds to step S253, where the subtitle read function unit 23 PES of private—stre am—1—PES of packet 0—packet—data—data—byte private—streaml—PES_payload () Extract private—stream—id described in Fig. 21
  • 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 2 64 (FIG. 3) in step S127 of FIG. 30. Determine whether to do so.
  • step S253 it is determined that the private_streaml-id described in private_streaml-PES-payloadO does not match the private-stream-id stored in the private-stream-id register 264. If the PES_packet 0 of private—stream—1 found in the previous step S 252 is not the subtitle stream to be played back, return to step S 252 and store it in the buffer 215 A. The PES-packet 0 of another private stream-1 in the program stream thus searched is searched for, and the same processing is repeated thereafter.
  • step S 253 private—streaml—PES—payload () ⁇ private—stream—id force described private—stream—id register private—stream—id stored in register 264 If it is determined that they match, that is, if the PES-packet 0 of private-stream-1 found in the immediately preceding step S252 is a subtitle stream to be reproduced, the process proceeds to step S254 to read subtitles.
  • the functional part 2 3 5 has its private_stream— 1 Reads the Allocator described in PES-packet () private-streaml_PES-payload () (Fig. 21) from buffer 215A, and finds the position immediately after the AU-locator and the AU_locator. The head position of the subtitle access unit is obtained by adding the value to the subtitle access unit.
  • the Allocator uses the position immediately after the AU-locator as a reference, and sets the subtitle access unit (or the audio access unit) stored in the private-payloadO of the private-streaml-PES-payloadO. Access unit), the (absolute) start position of the subtitle access unit can be obtained by adding the value indicated by the AU-locator to the position immediately after the AU-locator. .
  • the subtitle readout function unit 235 further performs the subtitle readout 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 pointer and go to step S255.
  • step S255 the subtitle reading function unit 235 determines whether or not a data request has been received from the subtitle decoder control module 218. Return and repeat the same process.
  • step S255 If it is determined in step S255 that the 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 to While analyzing the syntax of the program stream from the position of the buffer 2 15 A pointing to, one subtitle access unit of the size described at the top of the subtitle access unit is transferred to the buffer 2 15 A. , And supplies it to the subtitle decoder control module 218 together with the time stamp added to the subtitle access unit. That is, subtitles At the top of the access unit, the size of the subtitle access unit is described as described in Fig. 2A and Fig. 2B. The data is read from the position of the buffer 215 A pointed to by the subtitle read button, and the subtitle access unit that is the read data is read together with the time stamp added to the subtitle access unit. Supplied to dam control module 218.
  • the subtitle reading function unit 235 updates the subtitle reading pointer by the size of one subtitle access unit read from the buffer 215A, returns to step S255, and returns to step S255. 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 217 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 output of the video decoder And the output of the audio data as the output data to be output in synchronization with the video data.
  • the decode control module 216 corrects the difference between the output of the video data and the output of the audio data to be output in synchronization with the video data, and outputs the video data and the audio data. And A re-synchronization process is performed to output in synchronization.
  • step S271 the decryption control module 216 sets the time stamp of the video access unit from the video decoder control module 216 and the audio control module. Determine whether the deviation from the audio access unit timestamp from 2 17 is large.
  • the video decoder control module 216 receives the video access unit from the buffer control module 215 every time the video access unit is obtained.
  • the access unit time stamp is supplied to the decode control module 214.
  • the audio control module 217 supplies the time stamp of the audio access unit to the decode control module 216.
  • 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 time stamp of the video access unit and the time stamp of the audio access unit If the deviation from the amplifier is within a range that can be regarded as being in a predetermined synchronization, for example, two video frames (about 66 milliseconds), the process returns to step S271, and Judgment (monitoring) of deviation between time stamps is continued.
  • step S 271 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 different. If the time stamp is judged to be large, that is, the difference between the time stamp of the video access unit and the time stamp of the audio access unit is out of the range where it can be considered that predetermined synchronization is achieved. If there is, the process proceeds to step S 27 2, where the decode control module 2 14 receives the time stamp of the video access unit from the video decoder control module 2 16 and the time stamp from the audio control module 2 17.
  • the video data output (data And over de)
  • the instruction to the video decoder control module 216 not to perform decoding and output (display) of the video access unit that is, the video access unit An instruction to skip processing is output, and the flow advances to step S274.
  • step S274 the video decoder control module 216 receives the skip instruction from the decode control module 214, and responds to the skip instruction to transmit the video from the buffer control module 215. Check the au-ref-flag (Fig. 24) supplied with the access unit.
  • au_informationO located in private_stream2_2 (private-stream2- PES-payloadO (Fig. 23) of PES_packet 0) contains au_reset flag as information on access unit.
  • the buffer control module 215, together with the video access unit, The au—ref—flag is supplied to the video decoder control module 2 16.
  • step S274 the au-ref-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_reset flag of the video access unit supplied from the buffer control module 215 based on the result of the inspection. It is determined whether or not this video access unit is a non-reference image that is not referred to in decoding another picture.
  • the au-ref-flag 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 If it is determined in step S275 that the video access unit supplied from the buffer control module 215 is not a non-reference image (video access unit), that is, the buffer control module 215 If the video access unit supplied from is a reference image, the process proceeds to step S276, where the video decoder control module 216 transfers the video access unit to the video decoder 116 as usual. The next video access unit is processed by the buffer control module.
  • video access unit supplied from the buffer control module 215 If it is determined in step S275 that the video access unit supplied from the buffer control module 215 is not a non-reference image (video access unit), that is, the buffer control module 215 If the video access unit supplied from is a reference image, the process proceeds to step S276, where the video decoder control module 216 transfers the video access unit to the video decoder 116 as usual. The next video access unit is processed by the buffer control module.
  • step S275 If it is determined in step S275 that the video access unit supplied from the notfa control module 215 is a non-reference image, the process proceeds to step S277, where the video decoder control module In step S 2 7 1, the processing by the video decoder 1 16 of the video access unit is skipped, and the next video access unit is supplied from the buffer control module 2 15. People.
  • 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 delayed behind the output of the video data. If so, the process proceeds to step S 278, and the degod control module 214 is now decoding the video decoder control module 216 in order to wait for the video access unit to process. A repeat output instruction for repeatedly outputting video data corresponding to the video access unit is output, and the flow advances to step S279.
  • step S279 the video decoder control module 2 16 receives the instruction of the repeated output from the decoded control module 2 14 and in response to the instruction of the repeated output, the video decoder 1 16 Repeats the video data corresponding to the video access unit The output is returned to the graphics processing module 219 and the next video access unit is supplied from the buffer control module 215, and the process returns to step S271.
  • the decode control module 214 determines whether the output of the video data is behind the output of the audio data, and determines whether the output of the video data is behind the output of the audio data. If there is, the video decoder control module 216 is instructed to skip the processing of one access unit. Then, the video decoder control module 2 16 determines whether the access unit is a reference image or a non-reference image based on au-ref-flag of the access unit instructed to skip. If it is determined that the image is a non-reference image, the video decoder 116 skips the 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 for reference when decoding another access unit that is subsequently decoded. Therefore, if the processing of the access unit of the reference image is skipped in the synchronization control for synchronizing the output of the video data and the output of the audio data, other access units referring to the reference image are skipped. It cannot be decoded, and as a result, the synchronization control appears as noise in the video display.
  • the video access unit is PES_packed and PES_packet 0 (Fig. 16A
  • private—st ream2—PES—pay load () FIG. 23
  • PES_packet data—byte extended
  • the private-stream-2 PES-packet 0 of the allocated private-stream-2 is multiplexed, and the au-information () of the private-stream2- PES-payloadO (Fig. 24) contains the video for each video access unit.
  • Au-ref-flag indicating whether the access unit is a reference image or a non-reference image is described.
  • the au_ref_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 provide the video access unit with little cost by examining the au-re-flag of the video access unit supplied with the video access unit. Or a non-reference image.
  • the decode control module 2 14 constantly checks the current time measured by the built-in clock section 2 14 A. In, it is determined whether or not the current time coincides with 1 ⁇ _11 ⁇ -51 of any of Mark 0 described in PyListMarkO (FIG. 7) immediately.
  • the player control module 212 may play the first PlayItem # 0 of the first PlayList # 0 shown in FIG. Then, among the seven Marks 0 included in P1 ayListMarkO shown in the upper part of Fig. 28, the four Marks 0 to 4 belong to the first PlayItem # 0 of PlayList # 0.
  • the four Mark 0] nark_time__stamps ⁇ 180, 090 ⁇ , ⁇ 5,580,090 ⁇ , ⁇ 10, 980, 090 ⁇ , ⁇ 16, 380, 090 ⁇ , and the mark—time
  • the attribute of the time represented by one sta immediately is “mark processing” and is passed to the decode control module 214.
  • step S301 the decoding control module 214 determines that the current time is within the time (mark_Ume-stamp) of the attribute of "mark processing" supplied from the player control module 212 as described above. It is determined whether any of them 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 any one of the times of the attribute of “mark processing”, the decode control module 214 sets the current time to “mark processing”. The message indicating that the time of the attribute has been reached and the time of the attribute of the “mark processing” that matches the current time are supplied to the player control module 2 12, and the process proceeds to step S 302.
  • step S302 the player control module 212 sends a message indicating that the current time has become the time of the attribute of "mark processing",
  • the time (mark_time_stamp) of the attribute of “mark processing” that matches the time is received from the decode control module 214, and the MarkO whose mark_time_stamp matches the current time is a MarkO to be processed by the mark processing (hereinafter, referred to as “markO”). (Referred to as mark to be processed as appropriate).
  • the player control module 211 recognizes PlayltemO of the PlayList () currently being played back, and the PlayList 0 and Playltem 0 and the “mark” that matches the current time from the decode control module 214.
  • the PlayList MarkO (Fig. 7) in the "PLAYLIST.DAT" file (Fig. 5) from the time (mark-time-stamp) of the attribute of "Processing" (hereinafter referred to as mark time as appropriate).
  • mark time the mark to be processed is recognized.
  • the player control module 2 12 The time is 1 ) 1 & 1 ⁇ 5 ⁇ ! ⁇ () shown in the upper part of Fig. 28. sta Recognizes that it is immediate.
  • the player control module 211 is shown in the upper part of FIG. Of the four MarkOs from 1st to 4th included in P1 ayListMarkO, the 4th MarkO whose mark—time—st a instant matches the mark time of 16, 380, 090 is the target mark. Recognize as
  • the player control module 2 1 2 Upon recognizing the processing target ma rk as described above, the player control module 2 1 2 proceeds from step S302 to S303, and specifies an elementary stream in the processing target ma rk entry—ES_stream — Whether id and entrv ES_private_stream_id (Fig. 7) are described Is determined.
  • step S303 en try— ES—stream—id and en try—ES—private—stream—id (FIG. 7) that specify the elementary stream are not described in the mark to be processed. If entry_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 entry-ES-stream-id and entry-ES-private-stream-id (FIG. 7) for specifying an elementary stream are described in the mark to be processed. If it is determined that the elementary stream is being played back, the player control module 2 12 2 adds the entry—ES—stream—id and, if necessary, the entry—ES_private— It is determined whether or not the elementary stream specified by the stream_id is included.
  • step S304 the elementary stream being played back includes the elementary stream specified by the entry-ES-stream-id and entry-ES-private-stream-id of the mark to be processed. If it is determined that there is not, the process returns to step S301. That is, if the elementary stream specified by the en try—ES—str earn—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 step S At 304, it is determined that the elementary stream being played back includes the elementary stream specified by the en try—ES—stream—id and en try_ES—private—stream_id of the mark to be processed.
  • the elementary stream specified by the entry-ES-stream-id and entry_ES-private-stream-id of the mark to be processed is reproduced. If the mark has been processed, it is determined that the mark to be processed is valid, and the process proceeds to step S305, and thereafter, processing according to the mark to be processed is performed.
  • step S305 the player control module 212 determines the mark to be processed by referring to the mark-type of the mark to be processed (FIG. 7).
  • step S305 when it is determined that the mark to be processed is a cap mark or an index mark, that is, the mark-type of the mark to be processed is "Chapter” or "Index", If there is, the process proceeds to step S306, and the player control module 2 12 instructs the graphics processing module 2 19 to display the caption or index number to the caption mark or index mark which is the mark to be processed. Is updated to the chapter or index number represented by, and the process returns 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— ⁇ pe of the mark to be processed is “Ev ent”, step S3 Proceeding to 07, the player control module 2 1 2 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 2 1 1, and executes step S 3 Go to 08.
  • step S308 the script control module 211 receives the event message from the player control module 211 and mark-data, and uses the event message as an interrupt request in advance as "SCRIPT. DAT". "A series of processes described in the file are performed using mark-data as an argument, and the process returns to step S301.
  • the script control module 211 receives the event message corresponding to the second MarkO and the event message corresponding to the third MarkO, in both cases.
  • the same event handler interrupt processing routine
  • 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.
  • the mark-data is not limited to 1 or 2, and the processing performed in response to the mark-data is not limited to the display of the 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.
  • the script control module 211 controls the graphics processing module 211 and the second The icon of type is displayed at the brightness corresponding to the mark-data minus 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 is eccentric to the axis of the DC (Direct Current) module.
  • the vibration mode is read from mark_data. It can be operated only for the operation time corresponding to the value obtained by subtracting 34 (a numerical value from 1 to 8).
  • 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 by rules set in advance, and by rules set by the manufacturer of the disc 101 or a content provider that provides data recorded on the disc 101. It is possible to do.
  • 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-streamjd and entry-ES-private-stream-id for specifying an elementary stream are not described in the mark to be processed, the mark-type of the mark to be processed is specified. Processing is performed. In addition, even if entry_ES_stream_id and entry_ES_private_stream_id that specify an elementary stream are described in the mark to be processed, the entry_ES_stream_id and entry_ES_stream_id of that entry are described.
  • MarkO and the third MarkO are associated with elementary streams whose stream-ids are specified by OxEO and OxEl, respectively.
  • PlayltemO (PyItem # 0) is described in the second PlayList # l.
  • the clip stream file “00003. PS” is played.
  • the clip stream file “00003.PS” is described in the clip information file “00003.CLP” in FIGS. 26A and 26B corresponding to the clip stream file “00003.PS”.
  • the video stream stream # 0 specified by the OxEO s stream—id the video stream stream # l specified by the OxEl stream—id
  • the OxBD s earn—id
  • three elementary streams of the audio stream 1 # specified by the private-stream-id of 0x00 are multiplexed.
  • a video stream stream # having a stream-id of OxEO multiplexed with the crisp stream file "00003.PS" 0 is associated, and the third MarkO contains the clip stream file "00003.PS".
  • the multiplexed video stream sstream # l whose stream-id is OxEl is associated with the stream.
  • the player control module 2 12 28 It recognizes that three Marks 0 included in PlayListMarkO shown in the lower part of FIG. 11 belong to PlayItem # 0 of ayList # l, and the mark-time-sta of these three Marks 0 is immediately ⁇ 90, 000 ⁇ , ⁇ 27, 090,000 ⁇ , ⁇ 27, 540, 000 ⁇ are passed to the decode control module 214 with the mark—the time attribute indicated by time_stamp is “mark processing”. are doing.
  • the decoding control module 214 sets the current time measured by the timer 214A during the reproduction of the PlayltemttO of PlayList # l to the time ⁇ 90, 000 ⁇ , ⁇ 27,090,000 ⁇ whose attribute is “mark processing”. ⁇ Or ⁇ 27,540,000 ⁇ (step S301), and if the current time matches the time of the attribute "mark processing", the current time A mark time, which is the time of the attribute of “mark processing” that matches with “”, and a message indicating that the current time has become the time of the attribute of “mark processing” are supplied to the player control module 211.
  • the decode control module 214 receives the mark time 27,090,000, which is the time of the “mark processing” attribute that matches the current time, and a message indicating that the current time is the time of the “mark processing” attribute. Are supplied to the player control module 2 12.
  • the player control module 2 1 2 recognizes that PlayItem # 0 of PlayList # l is currently being reproduced, and the lower part of FIG. Among the MarkOs described in the PlayListMarkO shown in (1), the marks of three MarkOs belonging to PlayItem # 0—time_stamps of 90, 000, 27, 090, 000, 27, 540, 000, respectively, and decode control By comparing the mark time ⁇ ⁇ ⁇ ⁇ ⁇ , 090, 000 from module 2 14 with the mark time 27,0 90, 000, Markjime-sta immediately matches Mark (), that is, Fig. 28
  • the second MarkO (Mark # l) described in the lower PlayListMarkO is recognized as a processing target mark (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 stream-id of OxEO (second 6A and 26B) .
  • the player control module 2 12 determines whether or not the video stream stream # 0 is included in the elementary stream being played. Is determined (steps S303, S304).
  • step S304 when the video stream stream # 0 is not included in the elementary stream being reproduced, the processing target mark is ignored (step S304).
  • the processing target mark is determined to be valid, and the processing corresponding to the processing target mark is performed (step S 305 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'.
  • Player control module The file 211 supplies an event message indicating the occurrence of the event and the mark-data of the mark to be processed to the script control module 211 (steps S305 and S307).
  • the script control module 211 receives an event message from the player control module 211 as an interrupt request, and supplies a series of processes described in advance in the “SCRIPT.DAT” file together with the event message. Mark —data is used as an argument (step S308).
  • mark— time_stamp representing one playback time on the time axis of PlayListO
  • mark_type pe representing the type of MarkO
  • mark_data serving as an argument of the event mark.
  • mark type of the mark to be processed indicates the type of generating the event
  • mark_data and the event message of the mark to be processed are notified. Then, processing corresponding 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 the mark-data.
  • the player control module First, the output attribute of each of one or more elementary streams to be reproduced, that is, one or more elementary streams determined to be reproduced in step S125 of FIG. Investigate the number of DynamicInfoOs (Fig. 13) to be described-number-o and Dynamiclnfo (Fig. 10).
  • the player control module 2 12 When the number-of-dynamiclnfo is 0 for all of the one or more elementary streams to be reproduced, the player control module 2 12 does not perform any processing.
  • the player control module 2 12 performs the output attribute control process according to the flowchart of 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 PlayItem # 0 of the first PlayUst # 0) corresponding to the clip information file "00001. CLP” is played.
  • the clip information file "00001.CLP” (Fig. 26A and Fig. 26B)
  • the four element stream streams # 0 multiplexed into the clip stream file "00001.PS” For all of # 1 to # sam # 3, since the number_o and Dynamiclnfo are 0, the output attribute control processing is not performed.
  • step S320 the player control module 212 sets the clip information file ClipO (FIG. 10) corresponding to the clip stream file to be reproduced.
  • the pts—change_point described in the above is passed to the decode control module 2 14 together with the time of the attribute of “DynamicInfo () processing”, and the decoded control module 2 14 Pts—change_point, which is the time of the attribute of “DynamicInfo () process” of the above, is received, and the process proceeds to step S321.
  • step S321 the decode control module 214 determines that the current time measured by the clock section 214A is the time of the attribute of "DynamicInfo () processing". ) Is determined, and if it is determined that they do not match, the process returns to step S3221.
  • step S321 the current time is set to "DynamicInfo () If it is determined that the time coincides with (any one of) the times of the attribute of “processing”, the decode control module 2 14 4 outputs a message indicating that the current time has become the time of the attribute of “DynamicInfo () processing”. Then, the time of the attribute of “DynamicInfoO processing” that matches the current time (hereinafter, appropriately referred to as “DynamicInfo time”) is supplied to the player control module 21, and the process proceeds to step S 3 222.
  • step S 3 32 the player control module 2 12 sends from the decode control module 2 14 a message indicating that the current time has become the time of the attribute of “DynamicInfo () processing” and the Dynamic Info time.
  • the DynamicInfoO that is received and set with pts—change—point (FIG. 10) that matches the Dynamiclnio time is recognized as the DynamiclnfoO to be processed, which is the Dynamiclnfo0 to be processed, and the process proceeds to step S323. No.
  • step S 3 23 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 219 or the audio output module 2 2 1 and go to step S32.
  • DynamicInfoO FIG. 13
  • step S324 the graphics processing module 219 or the audio output module 221 sends the video data or audio data according to the output attribute supplied from the player control module 212 in the previous step S323. Control of the output is started, and the process returns to step S3221.
  • the video data is described as an output attribute (display method), for example, is output according to the aspect ratio.
  • the audio data is described as an output attribute (output method), for example, a stereo image. Or output according to dual (Nike language).
  • FIG. 42 shows a set of pts—change_point and Dynamic Info () described in the clip information file “00003. CLP” in FIG. 26A and FIG. 26B (FIG. 10). ).
  • the first elementary stream among the three elementary streams 36 & 111 # 0 to 56 am # 2 multiplexed in the clip stream file "00003.PS” The video information stream # 0 and the third elementary stream, the audio stream stream # 2, are described in the clip information file "00003.” in FIGS. 26A and 26B.
  • CLP number-0 and Dynamiclnfo are 2 and 3, respectively. Therefore, in the clip information file "00003.CLP", two sets of pts-change-point and DynamicInfoO are described for the first video stream streamttO of the clip stream file "00003.PS".
  • Third audio stream sstream # 2 [This is a description of 3 sets of pts-change-point and Dynamiclnfo 0].
  • No. 420 shows two sets of pts_change, one point and DynamicInfoO describing the first video stream of the cribstream file "00003.PS". Indicates three sets of pts-change_point and DynamicInfoO described for the third audio stream stream # 2 of the clip stream file "00003.PS".
  • Fig. 42 In the upper part of Fig. 42, two sets of pts-change-point and DynamicInfoO described for video stream stream # 0 have pts-change-point of 90,000, Dynamicl nfoO's display—aspect_ratio (Fig. 13) is '4: 3'. In the second set, the pts—change—point is 54,090,000, and the display—aspect ratio of DynamicInfoO is “16: 9”.
  • the clip stream file "00003.PS" is identified by the siream—id, which is OxEO.
  • the first video stream stream # 0 to be played and the third audio stream stream # 2 identified by the stream-id of OxBD and the private-stream-id of 0x00 are the playback targets. It is assumed that the stream is determined as
  • the player control module 2 1 2 uses the two sets of pts—change—point and upper set in FIG. 42 describing the video stream stream # 0 specified by the stream—id, which is OxEO. Dynamiclnfo () and three sets of audio stream stream # 2 specified by stream-id of OxBD and private-stream-id of 0x00 are described at the bottom of Fig. 42. Investigate pts_change—point and Pts in dynamiclfo () change—point and recognize the initial value.
  • change—point is 90,000.
  • the time of 90,000 corresponds to the clip information file of FIG. 26A and FIG. 26B corresponding to the clip stream file “00003.PS” in which the video stream stream # 0 is multiplexed.
  • “00003. CLP” it represents the start time of the clip stream file "00003.PS”, which corresponds to the time of 90,000 described in the presentation-star and Ume.
  • pts—change_point is 90,000.
  • the time of 90,000 is a clip stream file “00003.PS” in which the audio stream stream # 2 is multiplexed.
  • the clip information file “000 03.CLP” in FIG. 26A and FIG. 26B corresponding to “0 36 & 011_5 1 > It matches the described time of 90,000.
  • the player control module 2 1 2 matches the time 90,000 described in present ation—start—time, which represents the start time of the clip stream file “0 0003.PS”. Therefore, ⁇ is recognized as the initial value, so the first set of pts—change—point and the two sets of pts—change—point and DynamicInfoO in the upper part of FIG. The first set of pts_change_point and pts_change_point of Dynamiclnfo 0 is recognized as the initial value.
  • the player control module 211 sets the pts_change__point recognized as the initial value as a set. Indicate the output attribute of the corresponding elementary stream according to DynamicInfoO.
  • the pts-change_poini which is the initial value of 90,000, is set on the upper side of Fig. 42.
  • display-aspect-ratio is '4: 3'.
  • the player control module 2 1 2 indicates that the display—aspect ratio is “4: 3”, that is, that the video stream stream # 0 is video data having an aspect ratio of 4: 3.
  • Output attribute information controls the graphics processing module 219.
  • the initial value is 90,000 pts—change—point and the set DynamicInfoO
  • the channel_assignment is 'Dua' .
  • the player control module 211 sends information on the output attribute that the channel-assignment is “Dual”, that is, the output attribute that the audio stream streain is dual audio data. Supply to output module 2 2 1
  • step S 126 of FIG. 30 control processing of the output attribute for pts—change one point as an initial value as described above is performed. Thereafter, the player control module 2 1 2 Are the two pts—change—points 90, 000 and 54,090,000 at the top of FIG. 42 for video stream stre am # 0 and the bottom of FIG. 42 for audio stream s eam # 2.
  • ⁇ 27,090,000 ⁇ which is a time other than the initial value of 90,000 out of the three pts—change—points of 90,000, 27,090,000, and 32,490,000 ⁇ 32, 490, 000 ⁇ , ⁇ 54, 090, 000 ⁇ are passed to the decode control module 2 14 together with the time of the attribute of “Dynami c Info 0 processing” (step S 3 0 0 ).
  • 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 start of the playback of the video stream stream # 0 and the audio stream stream # 2 (playback of PlayItem # 0 of the second PlayList # l for playing back the clip stream file "00003.PS"), Starts monitoring of the current time being measured by the timer section 2 14 A.
  • the decode control module 2 14 sets the current time to the time of the attribute “Dynami clnfoO processing” ⁇ 27,090,000 ⁇ , ⁇ 32,490,000 ⁇ , ⁇ 54,090,0 5010627
  • the Dynamiclnfo time which is the time of the attribute of the “DynamicInfoO process” that matches the current time, is supplied to the player control module 2 12 (step S 3 21).
  • the decode control module 214 sets, as the Dynamiclnfo time, 27,090,000 of the attribute of the “DynamicInfo () process” that matches the current time. Supply to player control module 2 1 2
  • the player control module 2 1 2 receives the Dynamiclnfo time 27,090,000 from the decode control module 2 14, and the two pts—change_points on the upper side of FIG. 42 for the video stream stream # 0, From the three pts—change—points in the lower part of FIG. 42 for the stream stream, the pts—change—point that matches the Dynamic Info time of 27,090,000 is investigated.
  • Pts_change that matches that 27,090,000 DynamicInfo () that is set with point, that is, the second Dynamiclnfo 0 in the lower part of Fig. 42 for audio stream stream # 2 is recognized as DynamicInfoO to be processed Yes (step S322).
  • the player control module 2 12 supplies the output attribute described in the processing target Dynarai clnfoO to the graphics processing module 2 19 (Step S32 3).
  • the player control module 2 12 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 When the graphics processing module 219 is supplied with the output attribute from the player control module 221, the graphics processing module 219 performs the video processing according to the output attribute.
  • the control of the output of the mode is started (step S324).
  • the graphics processing module 219 may, for example, display a video-aspect ratio (display-aspect ratio (FIG. 13)) indicated by an output attribute from the player control module 221. ) And the aspect ratio of the video output device connected to the video output terminal 120 in FIG. 1, based on the aspect ratio of the video data output to the video output module 220. Perform the conversion.
  • a video-aspect ratio display-aspect ratio (FIG. 13)
  • FOG. 13 display-aspect ratio
  • the processing module 219 squeezes the video data to be output to the video output module 220 in the horizontal direction, and outputs the image 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 image 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 video stream stream # From time 90,000, which is the start of playback of 0, to time 54,090,000 Previously, a video stream of 4: 3 aspect ratio could be obtained from video stream sam # 0. After time 54,090,000, video data with an aspect ratio of 16: 9 is obtained from the video stream streamttO.
  • the graphics processing module 219 starts from time 90,000. Until just before time 54,090,000, the video data having the aspect ratio of 4: 3 obtained from the video stream stream # 0 is supplied as it is to the video output device having the aspect ratio of 4: 3 and displayed. .
  • the video data with an aspect ratio of 16: 9 obtained from the video stream stream # 0 is squeezed in the vertical direction.
  • 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 2 21 starts controlling the output of the audio data according to the output attribute (step S 3 2 4) .
  • the audio output module 221 includes, for example, an instruction of channel assignment of audio data (channe-as-sigment (FIG. 13)) represented by an output attribute from the player control module 221.
  • An audio decoder control module based on an input interface provided by the user operating the remote control and an audio output mode supplied from the player control module 212 via the interface 115 (FIG. 1). Processes the audio data from 217 and outputs it to audio output terminal 121 (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 2 21 processes audio data from the audio decoder control module 2 17 according to the audio output mode supplied from the player control module 2 12, Output to audio output terminal 1 2 1. That is, for example, when “main audio” is specified as the audio output mode, the audio output module 221 outputs the audio of the left channel of the audio data from the audio decoder control module 217.
  • the audio data is copied as audio data for the right channel, and the audio data of the left and right channels (“main audio” audio data) is output to the audio output terminals 121.
  • 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. One night 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 121. Further, when “primary / secondary” is specified as the audio output mode, the audio output module 2 21 receives the audio data from the audio decoder control module 2 17 as it is, and outputs the audio data to the audio output terminal 1 2 Output to 1.
  • the audio output module 221 is supplied from the player control module 221. Sa Regardless of the audio output mode used, the audio data from the audio decoder control module 217 is output to the audio output terminal 121 as it is.
  • the audio output output module 221 outputs the audio stream from time 90, 000 to immediately before time 27,090, 000.
  • the audio data of the left channel of the dual audio data obtained from the stream is copied as audio data of the right channel, and the audio data of the left channel and the right channel are output to the audio output terminal 1. 2 Output to 1.
  • the stereo audio data obtained from the audio stream stream # 2 is output to the audio output terminal 1 2 1 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.
  • the left and right channels of the audio are output to the audio output terminals 1 2 1.
  • the playback time of the elementary stream being played is pts—change—determines whether it matches the point. If the playback time of the element list being played matches the pts_change point, the Dynamiclnfo 0 set with that Dts_change—point is recognized and included in the recognized DynamicInfoO.
  • the output of the elementary stream being reproduced is controlled according to the output attribute to be reproduced. Therefore, it is possible to control the output of the elementary stream according to the playback time and the output attribute of the elementary stream.
  • the player control module 2 12 instructs the graphics processing module 2 19 to instruct the graphics processing module 2 19 in the initial display of the subtitle data in step S341. Become 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.
  • the initialization of the display method instruction performed in step S341 is performed according to the display method instruction described in 127 of FIG. Corresponds to 10627 initialization.
  • step S3 41 the process proceeds to step S3 42, in which the player control module 2 1 2 operates the remote controller to input a subtitle data from the input interface 1 15. For the display of, it is determined whether or not a new display method has been instructed.
  • step S 3 42 If it is determined in step S 3 42 that a new display method has been instructed, the process proceeds to step S 3 43, where the player control module 2 12 converts the subtitle stream (subtitle data corresponding to the subtitle stream) into Determine whether or not it is currently playing.
  • step S3343 If it is determined in step S3343 that the subtitle stream is not being reproduced, the process returns to step S3342.
  • step S334 If it is determined in step S334 that the subtitle stream is being played, the process proceeds to step S345, where the player control module 2 12. It is determined whether or not the instruction is for the display method of. If it is determined in step S3343 that the instruction for the new display method is the instruction for the default display method, the process returns to step S314, and as described above, the player control module 2 12 controls the graphics processing module 219 so that the display method of the subtitle data is set to the default display method.
  • 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, to enlarge or reduce the subtitle data. If the instruction is a non-default display method such as displaying the subtitle stream by changing the brightness or making it easier to see, the process proceeds to step S3456, and the player control module 212 sends the currently reproduced subtitle stream.
  • Clip information file C l ip 0 (Fig. 10) corresponding to the clip stream file in which 05010627
  • step S347 the player control module 2 12 determines the configurable flag of the StaticInfoO acquired in step S346. In step S347, the configurable 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 212 controls the graphics processing module 219 to output the subtitle data to the output video data. An error message indicating that the display method cannot be changed is overlaid, and the process returns to step S342. This causes an error message to be displayed.
  • step S347 if it is determined in step S347 that the conf igurable_flag is set to 1 indicating that the change of the subtitle display format is allowed, the process proceeds to step S349, where the player control module 2 1 2 The user operates the remote controller to supply the new display mode instruction supplied from the input interface 115 to the graphics processing module 219, and the process proceeds to step S350. '
  • step S350 the graphics processing module 219 transmits the subtitle data supplied from the subtitle decoder control module 218 to the display method supplied from the player control module 221 in the immediately preceding step S349. , The processing such as enlargement or reduction or change of brightness is started, and the process returns to step S342. As a result, the caption data is displayed in the display size, display position, display color, and the like according to the display method specified by the user by operating the remote controller.
  • step S342 there is no instruction for a new display method and If determined to be 10627, the process proceeds to step S351, and the player control module 212 determines whether the transfer of PlaylteniO described in FIG. 31 has been performed. If determined, the process returns to step S342.
  • step S351 If it is determined in step S351 that the transfer of PlayltemO has been performed, the process returns to step S341, and as described above, the player control module 212 sets the display method of the subtitle data to the default display method.
  • the graphics processing module 219 is controlled so as to use the method. 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 subtitle data corresponding to the subtitle stream is displayed only when the CO nfigurable flag of the subtitle stream is set to 1 indicating that the display format can be changed.
  • the system is changed according to, for example, a display system instruction input by the user operating the remote controller.
  • _flag is set to 1 to allow the change of the display method, if the user operates the remote controller to change the subtitle display while the subtitle stream stream # 3 is displayed, the The subtitle display size and the like are changed according to the operation.
  • the clip stream file “00001.PS” is being reproduced according to the first P1 ayltem # 0 of the first PlayList # 0 in FIG.
  • the four element multiplexed in the clip stream file “00001.PS” are described.
  • the third and fourth subtitle streams are subtitle streams.
  • the third subtitle stream streain # 2 and the fourth subtitle stream stream # 3 for example, the third subtitle stream It is assumed that stream # 2 is currently being played.
  • 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 the clip information file for StaticInfoO (FIG. 10) corresponding to the subtitle stream being reproduced (step S346).
  • 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 Find the StaticInfoO for the third subtitle stream stream # 2 from the clip information file "00001. CLP".
  • the player control module 2 1 2 6 In FIG. B the configurable_fIag that is 0 described in StickInfo () for the third subtitle stream stream # 2 is determined (step S347), and the third subtitle stream stream Regarding # 2, recognize that changing the display format is not allowed.
  • the player control module 2 12 determines that the subtitle stream being reproduced (caption data corresponding to) does not correspond to scaling or the like, and controls the graphics processing module 2 19 to An error message to that effect is generated (step S348), and output overlaid on the video.
  • the control module 211 searches for StaticInfoO for the fourth subtitle stream stream # 3 from the corresponding clip information file "00001. CLP".
  • the player control module 2 1 2 has a configurable element of 1 described in the Static Info for the fourth subtitle stream stream # 3 in FIGS. 26A and 26B.
  • the flag is determined (step S347), and thereby, it is recognized that the change of the display method is permitted for the fourth subtitle stream streani # 3.
  • the player control module 211 determines that the subtitle stream being reproduced (caption data corresponding to) corresponds to scaling or the like, and is supplied by the user operating the remote controller.
  • the instruction of the display method is supplied to the graphics processing module 211 (step S3 49).
  • the graphics processing control module 219 then enlarges or reduces the subtitle data from the subtitle decoder control module 218 according to the display method instruction from the player control module 212. Overlay video data from 216 and output.
  • the player control module 212 initializes the subtitle data display method instruction to the graphics processing module 219 at the start of playback of the first PlayItem 0 of PlayListO (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 a new subtitle stream played according to the newly played PlayltemO is checked, and if one configurable flag is 0, graphics Initialize the instruction of the display method of the subtitle data to the processing module 219, and if the configurable—flag is 1, maintain the instruction of the display method to the Dallax processing module 219 as it was before the transfer of Playltem 0. It is possible.
  • the new display method instruction is supplied to the graphics processing module 219. (Step S 349), but the indication of the display method is, for example, It is possible to store it in the nonvolatile memory constituting the memory 113 (FIG. 1) and to supply the instruction of the display method stored in the nonvolatile memory 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 instruction of the display method stored in the non-volatile memory is updated with the instruction of the new display method, and the instruction of the display method stored in the non-volatile memory is sent to the graphics processing module 219. It is possible to supply.
  • 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 static information O included in the clip information file ClipO (FIG. 10), which does not change during the playback of the elementary stream for each elementary stream.
  • Caption data StaticInfoO of the caption data is obtained, and based on the configurable one flag included in the StaticInfoO indicating whether or not the display of the caption data is allowed to be changed from the default display method, the subtitle data being reproduced is displayed. It is determined whether changing the display from the default display method is permitted.
  • the display processing for the subtitle data is performed, that is, for example, the processing for enlarging or reducing the subtitle data or changing the display color is performed. Therefore, it is possible to control the change of the display method for the subtitles.
  • FIG. 44 illustrates a flowchart describing the capture control process, and a background Z screen saver process which is an example of a process of secondary use of video data captured by the capture control process. A flowchart is also shown.
  • a capture instruction for instructing the capture of video data is transmitted to the player control module via the input interface 115 (FIG. 1). —Started when supplied to rule 2 1 2.
  • step S371 the player control module 2 12 determines whether or not the video stream is being reproduced. If it is determined that the video stream is not being reproduced, the capture control is performed. The key control process ends.
  • step S371 determines whether the video stream is being played.
  • step S372 the player control module 212 plays the PlayListO corresponding to the playing video stream.
  • capture— enable— flag— PiayList in PlayList () is, as described in FIG. 5, two video data (video data belonging to PlayList 0) corresponding to the video stream reproduced by PlayList 0. Indicates whether the next use is permitted.
  • capture—enable_flag_Clip in the clip information file ClipO is the video data corresponding to the video stream stored in the clip stream file corresponding to the clip information file ClipO. Indicates whether the next use is permitted.
  • step S373 the player control module 212 has the capt ure— enable— flag—PlayList and capture—enable— obtained in the previous step S373.
  • flag—CI ip it is determined whether or not the video data being reproduced when the capture instruction is input from the input interface 115 (FIG. 1) can be captured.
  • step S3 73 If it is determined in step S3 73 that the capture of the video data that was being played when the capture instruction was input from the input menu 1 15 is not possible, that is, If at least one of the capture_enable_flag—PlayList or capture_enable—flag_Clip obtained in step S3733 is 0 indicating that secondary use of video data is not permitted, go to step S374.
  • the player control module 2 12 overlays an error message indicating that capture of video data is not possible, and ends the capture control processing. This will display an error message.
  • step S373 the video data being played back when the capture instruction was input from the input interface 115 is displayed. If it is determined that the picture can be captured, that is, both the capture_enable—flag_PlayList and the capture—enable_flag—Clip obtained in the previous step S373 allow the secondary use of video data. If it is set to 1, the process proceeds to step S375, and the player control module 212 sets the key of the picture of the video data being reproduced when the capture instruction is input from the input interface 115. The instruction of the capture is supplied to the graphics processing module 211, and the process proceeds to step S376.
  • step S3776 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 1 1 3 (Fig. 1) is stored, and the capture control process ends. If capture-enable one flag has a multiple-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 reduced image is captured at this point. 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 logical product is 1 by taking the logical product of the capture — en ab 1 e — f 1 ag — P 1 ayL ist and the capt ure — enap 1 e — f 1 ag_C 1 ip , That is, if both capture_enable—flag—PlayList and capture—enable—flag—Clip are set to 1 that allows secondary use, it is determined that secondary use of video data is possible. And a CAPTCHA is performed.
  • the reproduction of the video stream that is, the video stream multiplexed into the clip stream file “00001.PS”
  • capture_enable—flag PlayerList in the first PlayList # 0
  • playback is performed by the first PlayItem # 0.
  • the secondary use of the video data being played back (video data corresponding to the video stream multiplexed to the clip stream file “00001.PS”) is determined to be possible, and the capture is performed. Is Also, for example, according to the second P1 ayltem # l of the first PlayList # 0 in FIG.
  • the reproduction of the video stream is performed according to the Playltem of the second PlayList # l in FIG. If there is a capture instruction from the user
  • the capture—enable—flag_PlayList in the first PI ayL is t # l is 0, and FIG. 26A and FIG. 26A corresponding to the clip stream file “00003.PS” played by the PlayltemlfO of the second PlayList # l Since capture—enable—flag—CI ip in the clip information file “00003. CLP” in FIG. 26B is 1, the video data being played back (the clip stream file “00003.PS” was multiplexed).
  • the picture captured by the capture control process and stored in the memory 113 can be used secondarily in the background Z screen saver process.
  • the background / screen saver processing is performed, for example, in a state in which 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 is not inserted, or when the reproduction of the elementary stream ends.
  • step S is, in the background screen server process, step S
  • the player control module 212 controls the graphics processing module 219 so as to display the picture stored in the memory 113 by the capture control processing.
  • Graphics processing module The module 219 displays the picture stored in the memory 113 by the capture control processing in accordance with the control from the player control module 212.
  • the graphics processing module 219 if the picture stored in the memory 113 is displayed as a still image, a so-called wallpaper (background) is realized, and the image is enlarged, reduced, or moved at regular intervals. Screen saver is realized.
  • the background screen saver process for displaying the picture stored in the memory 113 by the capture control process can be performed by another independent application instead of the player control module 212.
  • the capture—enable—flag—for the video data being played back indicates whether the secondary use of video data corresponding to a unit larger than the video access unit, for example, PlayListO or PlayltemO, is permitted.
  • PI ayList or capture— enable— flag— Clip is acquired and its capture— enable— flag— PlayList or capture— enable— flag—
  • Based on the Clip secondary use of the video data during playback is possible. It is determined whether permission is granted. If it is determined that the secondary use of the video data being played is permitted, the video data being played is captured, and the background Z screen saver using the captured video data is used. Processing is executed. Therefore, it is possible to control the secondary use of video data.
  • a capture enable flag—PlayList is provided in PlayListO (FIG. 5), and PlayList In the clip information file ClipO (Fig. 10) corresponding to the clip stream file played by emO, capture— enable— flag— Ci ip is provided, and its capture— enable— flag— PyList and capture— enable One flag—Clip and both are used to determine the permission (permission / non-permission) of secondary use.
  • playListO Fig. 5
  • capture_enable—flag_PlayList is only provided, or PlaytemO is used.
  • ClipO Fig.
  • capture_enable—flag only a Clip is provided
  • capture—enable—flag PlayUst or ⁇ capture—enable—flag— It is also possible to use only one of the CI ips to determine whether secondary use is possible.
  • step S376 the graphics processing module 219 according to the capture instruction from the player control module 221 causes the video decoder control module 211 to perform the following processing.
  • the picture of the video data from step 6, ie, only one picture has been captured it is also possible to capture a plurality of pictures.
  • the number of pictures to be captured at one time can be predetermined, for example.
  • extend the bits of capture—enable—flag_PlayList or capture—enable—flag—Clip to include the number of pictures that can be captured at one time for that capture—enable—flag—PlayList or capture—enable—flag—Clip. May be included.
  • use permission information (capture—enable—flag—PlayList, capture—enable— flag—Clip) is described in the PlayListO or the clip information file CI ip0, and the usage permission information multiplexes the entire video data played by the PlayListO or the clip stream file corresponding to the clip information file Clip (). Video data corresponding to the coded video stream—whether or not secondary use is possible for the entire evening is determined.
  • use permission information describes video data in other arbitrary units, and is used according to the use permission information. It is possible to determine whether secondary use is possible for video data of an arbitrary unit.
  • FIG. 45 shows the syntax of private-stream2-PES_payload () in which the usage permission information is arranged.
  • FIG. 46 shows the syntax of au-information 0 in which the usage permission information is arranged. Is shown.
  • the private-stream2-PES-payload0 in Fig. 45 is the same as the video-stream-id except that capture-enable-flag-ps2 is placed as usage permission information immediately before the id.
  • the configuration is the same as in FIG.
  • the configuration of au-iniormationO in Fig. 46 is the same as that in Fig. 24 except that capture-enable-flag-AU is placed as the license information immediately before pic-struc and copy. ing.
  • the capture—enable—flag—ps2 located in private—stream2—PES—payloadO in FIG. 45 is the PES—packet 0 of private—stream—2 including its private—stream2—PES—pay load 0 Power, etc., indicates whether to allow secondary use of the video data corresponding to the video stream located immediately before the next private-stream-2 PES-packetO. Therefore, according to private_stream2—PES—pay load 0 in FIG. 45, according to capture—enable—flag—ps2, the video data between the point where decoding can start and the point where decoding can start It is possible to determine whether or not to permit the secondary use of In addition, capture_enable_flag—AU placed in au-informationO in FIG.
  • au—information 0 (capture—enable—flag—AU as usage permission information in Figure 46) overlaps two or more of them. In this case, it is possible to determine whether the secondary use of a picture of a certain video data is possible based on the logical product of two or more use permission information that are adopted in duplicate. Can be.
  • the video readout function section 233 of the buffer control module 215 executes the program stream stored in the buffer 2115A. Search from. Therefore, in the case of adopting the pri vate_stream2_PES_pay load 0 in FIG. 45 where capture—enable_flag-ps2 is placed, or the au—informationO in FIG. 46 where capture—enable—flag—AU is placed, The player control module 211 determines capture enable flag—ps2, capture—enable—flag—AU, H It is necessary to contact the data read function section 2 3 3.
  • the above-described series of processing is performed by software, but the above-described series of processing may be performed by a dedicated hardware.
  • the video decoder 1 16 (FIG. 1)
  • a hardware decoder was adopted, but a video decoder 1
  • a software decoder is adopted as the subtitle decoder, but a hard-water decoder can be adopted as the subtitle decoder.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

ビデオデータと、それと同期して出力されるべき出力データの同期をとる。ビデオデータの出力が、それと同期して出力されるべき出力データの出力よりも遅れている場合、ステップＳ２７３において、１つのアクセスユニットの処理をスキップすることが指示される。さらに、ステップＳ２７５において、処理のスキップが指示されたアクセスユニットのビデオデータに対するau_ref_flagに基づき、そのビデオデータが、他のビデオデータのデコードに参照されるか否かが判定され、処理のスキップが指示されたアクセスユニットのビデオデータが、他のビデオデータのデコードに参照されない場合、ステップＳ２７７において、処理のスキップが指示されたアクセスユニットの処理がスキップされる。本発明は、例えば、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つのァク セスュニットの符号化ビデオデータの処理をスキップすることを指示 する指示手段と、 指示手段において処理のスキップが指示されたァク セスュニットの符号化ビデオデータに対応するビデオデータに対する 参照情報に基づき、 そのビデオデータが、 他の符号化ビデオデータの デコードに参照されるか否かを判定する第 2の判定手段と、 第 2の判 定手段において、 指示手段において処理のスキップが指示されたァク セスュニットの符号化ビデオデ一夕に対応するビデオデータが、 他の 符号化ビデオデータのデコードに参照されないと判定された場合に、 指示手段において処理のスキップが指示されたアクセスュニットの符 号化ビデオデータの処理をスキップさせるスキップ制御手段とを備え ることを特徴とする。 本発明のデータ処理方法は、 アクセスュニッ卜単位の符号化ビデオ データにおける 1以上のデコード開始可能点それぞれの直前に配置さ れる、 符号化ビデオデータのデコードに利用される利用情報が、 その 利用情報から次の利用情報までの間に配置されている 1以上のァクセ スュニットそれぞれの符号化ビデオデータに対応するビデオデータが 、 他の符号化ビデオデータのデコ一ドに参照されるか否かを表す参照 情報を含む場合において、 ビデオデータの出力が、 それと同期して出 力されるべき出力データの出力よりも遅れているか否かを判定する第 1の判定ステップと、 第 1の判定ステップにおいて、 ビデオデータの 出力が、 出力データの出力よりも遅れていると判定された場合に、 1 つのアクセスュニッ卜の符号化ビデオデータの処理をスキップするこ とを指示する指示ステップと、 指示ステップにおいて処理のスキップ が指示されたアクセスュニッ卜の符号化ビデオデータに対応するビデ ォデ一夕に対する参照情報に基づき、 そのビデオデータが、 他の符号 化ビデオデータのデコ一ドに参照されるか否かを判定する第 2の判定 ステップと、 第 2の判定ステップにおいて、 指示ステップにおいて処 理のスキップが指示されたアクセスユニットの符号化ビデオデー夕に 対応するビデオデータが、 他の符号化ビデオデータのデコードに参照 されないと判定された場合に、 指示ステップにおいて処理のスキップ が指示されたアクセスュニットの符号化ビデオデータの処理をスキッ プさせるスキップ制御ステップとを含むことを特徴とする。
本発明のプログラムは、 アクセスュニッ卜単位の符号化ビデオデー 夕における 1以上のデコード開始可能点それぞれの直前に配置される 、 符号化ビデオデータのデコードに利用される利用情報が、 その利用 情報から次の利用情報までの間に配置されている 1以上のアクセスュ ニットそれぞれの符号化ビデオデータに対応するビデオデータが、 他 5 010627 の符号化ビデオデータのデコードに参照されるか否かを表す参照情報 を含む場合において、 ビデオデータの出力が、 それと同期して出力さ れるべき出力データの出力よりも遅れているか否かを判定する第 1の 判定ステップと、 第 1の判定ステップにおいて、 ビデオデータの出力 が、 出力データの出力よりも遅れていると判定された場合に、 1つの アクセスュニットの符号化ビデオデ一夕の処理をスキップすることを 指示する指示ステップと、 指示ステツプにおいて処理のスキップが指 示されたアクセスュニットの符号化ビデオデ一夕に対応するビデオデ 一夕に対する参照情報に基づき、 そのビデオデータが、 他の符号化ビ デォデ一夕のデコードに参照されるか否かを判定する第 2の判定ステ ップと、 第 2の判定ステップにおいて、 指示ステップにおいて処理の スキップが指示されたアクセスユニットの符号化ビデオデー夕に対応 するビデオデータが、 他の符号化ビデオデータのデコードに参照され ないと判定された場合に、 指示ステップにおいて処理のスキップが指 示されたアクセスュニットの符号化ビデオデータの処理をスキップさ せるスキップ制御ステップとを含むことを特徵とする。
本発明のプログラム記録媒体に記録されているプログラムは、 ァク セスュニット単位の符号化ビデオデータにおける 1以上のデコード開 始可能点それぞれの直前に配置される、 符号化ビデオデータのデコ一 ドに利用される利用情報が、 その利用情報から次の利用情報までの間 に配置されている 1以上のアクセスュニットそれぞれの符号化ビデオ データに対応するビデオデータが、 他の符号化ビデオデータのデコー ドに参照されるか否かを表す参照情報を含む場合において、 ビデオデ 一夕の出力が、 それと同期して出力されるべき出力デ一夕の出力より も遅れているか否かを判定する第 1.の判定ステップと、 第 1の判定ス テツプにおいて、 ビデオデータの出力が、 出力デ一夕の出力よりも遅 れていると判定された場合に、 1つのアクセスュニッ卜の符号化ビデ ォデータの処理をスキップすることを指示する指示ステップと、 指示 ステップにおいて処理のスキップが指示されたアクセスュニットの符 号化ビデオデータに対応するビデオデータに対する参照情報に基づき 、 そのビデオデータが、 他の符号化ビデオデータのデコードに参照さ れるか否かを判定する第 2の判定ステップと、 第 2の判定ステップに おいて、 指示ステップにおいて処理のスキップが指示されたアクセス ュニッ卜の符号化ビデオデータに対応するビデオデータが、 他の符号 化ビデオデータのデコ一ドに参照されないと判定された場合に、 指示 ステップにおいて処理のスキップが指示されたアクセスュニットの符 号化ビデオデータの処理をスキップさせるスキップ制御ステップとを 含むことを特徴とする。
本発明のデータ記録媒体は、 符号化データは、 所定の単位のビデオ データを符号化して得られる、 アクセスュニット単位の符号化ビデオ データと、 ビデオデータと同期して出力されるべき出力データと、 ァ クセスュニット単位の符号化ビデオデータにおける 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のシン P T/JP2005/010627 タクスを示す図、 第 1 1図は、 エレメンタリストリームを識別する st r earn一 idおよび private— st ream と、 エレメンタリストリームとの関 係を示す図、 第 1 2図は、 StaticInfoOのシンタクスを示す図、 第 1 3図は、 DynamicInfoOのシンタクスを示す図、 第 1 4図は、 EP— map( )のシンタクスを示す図、 第 1 5図 Aおよび第 1 5図 Bは、 MPEG- 2 Sy stemのプログラムストリーム、 プログラムストリームパック、 および プログラムストリームパックヘッダのシンタクスを示す図、 第 1 6図 Aおよび第 1 6図 Bは、 MPEG- 2 Sys t emの 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 temにおける PES—packet 0の s tream_idに記述される値と、 エレメンタリストリームの属性 （種類） との関係を示す図、 第 2 0図は、 ディスク装置が採用する stream— id を示す図、 第 2 1図は、 private_streamし PES— payloadOのシンタク スを示す図、 第 2 2図は、 private— siream— idの値と、 private— paylo ad()に格納されるエレメン夕リストリームの属性との関係を示す図、 第 2 3図は、 private一 strean^—PES—payloadOのシンタクスを示す図 、 第 24図は、 au_information()のシンタクスを示す図、 第 2 5図は 、 "PLAYLIST.DAT"ファイルの具体例を示す図、 第 2 6図 Aおよび第 2 6図 Bは、 クリップ情報ファイル" 00001. CLP", " 00002. CLP", " 00003 .CLP"の具体例を示す図、 第 2 7図は、 クリップ情報ファイル" 00001. CLP"の中の EPjnapOの具体例を示す図、 第 2 8図は、 ayList #0と P layList #1の中の； P yListMarkOの具体例を示す図、 第 2 9図は、 再 生前処理を説明するフローチヤ一卜、 第 3 0図は、 再生処理を説明す るフ口一チヤ一ト、 第 3 1図は、 P yltem乗り換え処理を説明するフ ローチャート、 第 3 2図は、 タイムコード表示処理を説明するフロー チャート、 第 3 3図は、 ストリーム切り替え処理を説明するフローチ ャ一ト、 第 34図は、 バッファ制御モジュール 2 1 5の処理を説明す るフローチヤ一ト、 第 3 5図は、 バッファ制御モジュール 2 1 5の処 理を説明するフローチャート、 第 3 6図は、 ビデオストリームの読み 出しの処理を説明するフローチャート、 第 3 7図は、 オーディオスト リームの読み出しの処理を説明するフローチャート、 第 3 8図は、 字 幕ストリームの読み出しの処理を説明するフローチャート、 第 3 9図 は、 再同期処理を説明するフ口一チャート、 第 4 0図は、 マーク処理 を説明するフローチャート、 第 4 1図は、 出力属性の制御処理を説明 するフローチヤ一ト、 第 42図は、 クリップ情報ファイル" 00003. CLP "に記述されている pts— change_pointと DynamicInfoOとのセッ卜の具 体例を示す図、 第 4 3図は、 字幕表示制御処理を説明するフローチヤ —ト、 第 44図は、 キヤプチャ制御処理とバックグラウンド Zスクリ ーンセーバ処理を説明するフローチャート、 第 4 5図は、 private— st ream2_PES— payloadOの他のシンタクスを示す図、 第 46図は、 au— in formationOの他のシンタクスを示す図である。 発明を実施するための最良の形態
以下に本発明の実施の形態を説明するが、 請求の範囲に記載の構成 要件と、 発明の実施の形態における具体例との対応関係を例示すると 、 次のようになる。 この記載は、 請求の範囲に記載されている発明を サポー卜する具体例が、 発明の実施の形態に記載されていることを確 認するためのものである。 従って、 発明の実施の形態中には記載され ているが、 構成要件に対応するものとして、 ここには記載されていな い具体例があつたとしても、 そのことは、 その具体例が、 その構成要 件に対応するものではないことを意味するものではない。 逆に、 具体 例が構成要件に対応するものとしてここに記載されていたとしても、 そのことは、 その具体例が、 その構成要件以外の構成要件には対応し ないものであることを意味するものでもない。
さらに、 この記載は、 発明の実施の形態に記載されている具体例に 対応する発明が、 請求の範囲に全て記載されていることを意味するも のではない。 換言すれば、 この記載は、 発明の実施の形態に記載され ている具体例に対応する発明であって、 この出願の請求の範囲には記 載されていない発明の存在、 すなわち、 将来、 分割出願されたり、 補 正により追加される発明の存在を否定するものではない。
請求の範囲 1に記載のデータ処理装置は、
符号化データを処理するデータ処理装置 （例えば、 第 1図のディス ク装置） において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニ ット単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデ一夕における 1以上 のデコ一ド開始可能点それぞれの直前に配置される、 前記符号化ビデ ォデータのデコードに利用される利用情報（例えば、 第 2 3図の pr iva t e一 s t ream一 2— PES— pay l oad 0 )と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデー 夕に対応するビデオデータが、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報（例えば、 第 2 4図の au re f f l ag) を含み、
前記ビデオデータの出力が、 前記出力データの出力よりも遅れてい るか否かを判定する第 1の判定手段 （例えば、 第 3 9図のステップ S 2 7 2の処理を行う第 2図 Aおよび第 2図 Bのデコード制御モジユー ル 2 1 4 ) と、
前記第 1の判定手段において、 前記ビデオデータの出力が、 前記出 力データの出力よりも遅れていると判定された場合に、 1つのァクセ スユニットの符号化ビデオデータの処理をスキップすることを指示す る指示手段 （例えば、 第 3 9図のステップ S 2 7 3の処理を行う第 2 図 Aおよび第 2図 Bのデコード制御モジュール 2 1 4 ) と、
前記指示手段において処理のスキップが指示されたアクセスュニッ トの符号化ビデオデータに対応するビデオデータに対する前記参照情 報に基づき、 そのビデオデータが、 他の符号化ビデオデータのデコ一 ドに参照されるか否かを判定する第 2の判定手段 （例えば、 第 3 9図 のステップ S 2 7 5の処理を行う第 2図 Aおよび第 2図 Bのデコード 制御モジュール 2 1 4 ) と、
前記第 2の判定手段において、 前記指示手段において処理のスキッ プが指示されたアクセスュニットの符号化ビデオデータに対応するビ デォデータが、 他の符号化ビデオデータのデコードに参照されないと 判定された場合に、 前記指示手段において処理のスキップが指示され たアクセスユニットの符号化ビデオデー夕の処理をスキップさせるス キップ制御手段 （例えば、 第 3 9図のステップ S 2 7 7の処理を行う 第 2図 Aおよび第 2図 Bのビデオデコーダ制御モジュール 2 1 6 ) と を備えることを特徴とする。
請求の範囲 2に記載のデータ処理装置は、
前記第 1の判定手段において、 前記出力デ一夕の出力が、 前記ビデ ォデータの出力よりも遅れていると判定された場合に、 前記ビデオデ 一夕を繰り返し出力させる出力制御手段 （例えば、 第 3 9図のステツ プ S 2 7 9の処理を行う第 2図 Aおよび第 2図 Bのビデオデコーダ制 御モジュール 2 1 6 ) をさらに備える
ことを特徴とする。
請求の範囲 3に記載のデータ処理方法は、
符号化データを処理するデータ処理方法において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニ ット単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上 のデコード開始可能点それぞれの直前に配置される、 前記符号化ビデ ォデータのデコードに利用される利用情報（例えば、 第 2 3図の pr i va t e一 s t r e am— 2一 PES— pay l oad O )と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデ一 夕に対応するビデオデータが、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報（例えば、 第 2 4図の au一 reし H ag) を含み、
前記ビデオデータの出力が、 前記出力データの出力よりも遅れてい るか否かを判定する第 1の判定ステップ （例えば、 第 3 9図のステツ プ S 2 7 2 ) と、
前記第 1の判定ステップにおいて、 前記ビデオデータの出力が、 前 記出力データの出力よりも遅れていると判定された場合に、 1つのァ クセスユニットの符号化ビデオデータの処理をスキップすることを指 示する指示ステップ （例えば、 第 3 9図のステップ S 2 7 3 ) と、 前記指示ステップにおいて処理のスキップが指示されたアクセスュ ニットの符号化ビデオデ一夕に対応するビデオデータに対する前記参 照情報に基づき、 そのビデオデータが、 他の符号化ビデオデータのデ コ一ドに参照されるか否かを判定する第 2の判定ステップ （例えば、 第 3 9図のステツプ S 2 7 5 ) と、
前記第 2の判定ステツプにおいて、 前記指示ステツプにおいて処理 のスキップが指示されたアクセスユニットの符号化ビデオデー夕に対 応するビデオデータが、 他の符号化ビデオデータのデコードに参照さ れないと判定された場合に、 前記指示ステップにおいて処理のスキッ プが指示されたアクセスユニットの符号化ビデオデータの処理をスキ ップさせるスキップ制御ステップ （例えば、 第 3 9図のステップ S 2
7 7 ) と
を含むことを特徴とする。
請求の範囲 4に記載のプログラム、 および請求の範囲 5に記載のプ ログラム記録媒体に記録されているプログラムは、
符号化データを処理するデータ処理を、 コンピュータに行わせるプ ログラムにおいて、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニ ッ卜単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上 のデコード開始可能点それぞれの直前に配置される、 前記符号化ビデ ォデ一夕のデコードに利用される利用情報（例えば、 第 2 3図の pr i va t e— s t ream一 2— PES一 pay l oad 0 )と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデー 夕に対応するビデオデータが、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報（例えば、 第 2 4図の au— re f— H ag) を含み、
前記ビデオデ一夕の出力が、 前記出力データの出力よりも遅れてい るか否かを判定する第 1の判定ステップ （例えば、 第 3 9図のステツ プ S 2 7 2 ) と、
前記第 1の判定ステップにおいて、 前記ビデオデータの出力が、 前 記出力データの出力よりも遅れていると判定された場合に、 1つのァ クセスュニットの符号化ビデオデータの処理をスキップすることを指 示する指示ステップ （例えば、 第 3 9図のステップ S 2 7 3 ) と、 前記指示ステップにおいて処理のスキップが指示されたアクセスュ ニットの符号化ビデオデータに対応するビデオデータに対する前記参 照情報に基づき、 そのビデオデータが、 他の符号化ビデオデ一夕のデ コードに参照されるか否かを判定する第 2の判定ステップ （例えば、 第 3 9図のステツプ S 2 7 5 ) と、
前記第 2の判定ステップにおいて、 前記指示ステップにおいて処理 のスキップが指示されたアクセスユニットの符号化ビデオデ一夕に対 応するビデオデータが、 他の符号化ビデオデ一夕のデコードに参照さ れないと判定された場合に、 前記指示ステップにおいて処理のスキッ プが指示されたアクセスュニッ卜の符号化ビデオデータの処理をスキ ップさせるスキップ制御ステップ （例えば、 第 3 9図のステップ S 2 7 7 ) と を含むことを特徴とする。
請求の範囲 6に記載のデータ記録媒体は、
符号化データが記録されているデータ記録媒体において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニ ッ卜単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力デ一夕と、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上 のデコード開始可能点それぞれの直前に配置される、 前記符号化ビデ ォデータのデコードに利用される利用情報（例えば、 第 2 3図の pr iva t e一 s t ream一 2一 PES一 pay l oad () )と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデ一 夕に対応するビデオデ一夕が、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報（例えば、 第 2 4図の au_reし f l ag) を含む
ことを特徴とする。
以下、 図面を参照して、 本発明の実施の形態について説明する。
[ハードウェア構成]
第 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 0 2は、 図示せぬインタ一フェースを内蔵 し、 そのインターフェースを通じて、 ドライブインタ一フェース 1 1 4に接続されている。 ディスクドライブ 1 0 2は、 そこに装着された ディスク 1 0 1を駆動し、 ドライブイン夕一フェース 1 1 4からの読 み出し等の命令にしたがって、 ディスク 1 0 1からデータを読み出し て、 ドライブインターフェース 1 1 4に供給する等の処理を行う。 バス 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 は、 CPU1 1 2が実行するソフトウェアモジュール群を記憶している 。 また、 メモリ 1 1 3は、 CPU1 1 2の動作上必要なデータを一時記 憶する。 なお、 メモリ 1 1 3は、 不揮発性メモリのみ、 または揮発性 メモリと不揮発性メモリとの組み合わせで構成することが可能である 。 また、 第 1図のディスク装置に、 ハードディスクを設け、 そのハ一 ドディスクに、 CPU1 1 2が実行するソフトウェアモジュール群を記 録 （インスト一ル） しておく場合には、 メモリ 1 1 3は、 揮発性メモ リのみで構成することが可能である。
ここで、 CPU1 1 2が実行するプログラム （ソフトウェアモジユー ル群） は、 ディスク装置に内蔵されている記録媒体としてのメモリ 1 1 3に予め記録しておく （記憶させておく） ことができる。
あるいはまた、 プログラムは、 ディスク 1 0 1、 さらには、 デイス ク 1 0 1以外のフレキシブルディスク、 CD- ROM (Compact Disc Read 0 nly Memory), M0 (Magneto Optical)ディスク、 磁気ディスク、 メモリ 力一ドなどのリム一バブル記録媒体に、 一時的あるいは永続的に格納 (記録） しておくことができる。 このようなリムーバブル記録媒体は 、 いわゆるパッケージソフトウエアとして提供することができる。 なお、 プログラムは、 メモリ 1 1 3にあらかじめ記憶させておくこ と、 あるいは、 上述したようなリムーパブル記録媒体からディスク装 置にインストールすることができる。 また、 プログラムは、 ダウン口 一ドサイトから、 ディジタル衛星放送用の人工衛星を介して、 デイス ク装置に無線で転送したり、 LAN(Local Area Network), インターネ ットといったネットワークを介して、 ディスク装置に有線で転送し、 ディスク装置では、 そのようにして転送されてくるプログラムを、 入 力インターフェース 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 0 2によってデイス ク 1 0 1から読み出され、 ドライブインターフェース 1 1 4およびパ ス 1 1 1を介して供給される、 ビデオデータの符号化データ （符号化 オーディオデータ） をデコードし、 その結果得られるビデオデ一夕を
、 バス 1 1 1を介して、 CPU 1 1 2やビデオ出カインターフェ一ス 1 1 8に供給する。
オーディオデコーダ 1 1 7は、 ディスクドライブ 1 0 2によってデ イスク 1 0 1から読み出され、 ドライブインターフェ一ス 1 1 4およ びバス 1 1 1を介して供給される、 オーディオデータの符号化デ一夕 (符号化オーディオデ一夕） をデコードし、 その結果得られるオーデ ィォデ一夕を、 バス 1 1 1を介して、 CPU 1 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」
ォペレ一ティングシステム 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 In t er f ace)からの信号に W 従いメニューの表示を変更する （例えば、 メニュー上の力一ソルを移 動する等） 」 、 「プレイヤ制御モジュール 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 J
コンテンツデ一タ供給モジュール 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」
ビデオデコーダ制御モジュール 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 J
グラフィクス処理モジュール 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 20に出力するビデオデ一夕を、 横方向 （ 水平方向） にスクイ一ズ （縮小） 処理し、 左右に黒味を入れて出力す る。 また、 例えば、 ビデオ出力装置のアスペクト比.が 4:3である場合 において、 ビデオデータのァスぺクト比を指示する情報が 16:9のァス ぺクト比を表しているときには、 グラフィクス処理モジュール 2 1 9 は、 ビデオ出力モジュール 22 0に出力するビデオデータを、 縦方向 (垂直方向） にスクイ一ズ （縮小） 処理し、 上下に黒味を入れて出力 する。
なお、 ビデオ出力装置のアスペクト比と、 ビデオデータのァスぺク ト比を指示する情報が表すアスペクト比とが、 いずれも、 4:3や 16:9 で、 同一である場合、 グラフィクス処理モジュール 2 1 9は、 ビデオ 出力モジュール 2 20に出力するビデオデ一夕を、 スクイーズ処理す ることなく、 そのまま出力する。
その他、 グラフィクス処理モジュール 2 1 9は、 例えば、 プレイヤ 制御モジュール 2 1 2からの要求に応じて、 現在処理中のビデオデー 夕をキヤプチヤする。 さらに、 グラフィクス処理モジュール 2 1 9は 、 そのキヤプチヤしたビデオデータを記憶し、 あるいは、 プレイヤ制 御モジュール 2 1 2に供給する。
「ビデオ出力モジュール 220 J
ビデオ出力モジュ一ル 22 0は、 第 1図のメモリ 1 1 3の一部を排 他的に占有して FIF0(First In First Out) 220 A (バッファ） とし て使用し、 グラフィクス処理モジュール 2 1 9からのビデオデータを 一時的に記憶し、 また、 その FIF0220 Aに記憶されたビデオデータ を適宜読み出して、 ビデオ出力端子 1 20 (第 1図） に出力する。
「オーディオ出力モジュール 2 2 1」
オーディオ出力モジュール 22 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からのオーディオデータが、 左チャネルが 「主 音声」 のオーディオデ一夕で、 右チャネルの 「副音声」 のオーディオ データであるデュアル（Dua l) (ニケ国語） モードのオーディオデータ である場合、 あらかじめ指定された音声出力モードに従って、 オーデ ィォデコーダ制御モジュール 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 tereo)モ一ドのォ一ディォデータである場合、 ォ一ディォ出力モジュール 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から読み出されたデ一夕を順次記憶し、 その記憶容量分のデータ を記憶した後は、 最も古いデータに上書きする形で、 最新のデ一夕を 、 いわば無限ループ状に記憶していく。
データ先頭ポインタ記憶部 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 Picture Expe rts Group)2の規格に準拠したプログラムストリーム （MPEG2_Sys tem Program Stream) が記録されており、 バッファ 2 1 5 Aには、 光ディ スク 1 0 1から読み出されたプログラムストリームが記憶される。 こ のプログラムストリームは、 ビデオストリームや、 オーディオストリ —ム、 字幕ストリーム等の 1以上のエレメン夕リストリームが時分割 多重されている。 ビデオ読み出し機能部 2 3 3は、 プログラムストリ 一ムのデマルチプレクスの機能を有し、 バッファ 2 1 5 Aに記憶され たプログラムストリームから、 ビデオストリームを分離して読み出す 同様に、 オーディオ読み出し機能部 2 34も、 プログラムストリ一 ムのデマルチプレクスの機能を有し、 バッファ 2 1 5 Aに記憶された プログラムストリームから、 オーディォストリームを分離して読み出 す。 字幕読み出し機能部 2 3 5も、 プログラムストリームのデマルチ プレクスの機能を有し、 バッファ 2 1 5 Aに記憶されたプログラムス トリームから、 字幕ストリームを分離して読み出す。
ここで、 ビデオ読み出し機能部 2 3 3は、 第 1図のメモリ 1 1 3の 一部であるビデオ読み出しボインタ記憶部 241、 stream— idレジス 夕 242、 および au_information()レジスタ 243を有している。 ビデオ読み出しポインタ記憶部 24 1は、 バッファ 2 1 5 Aの、 ビ デォストリームが記憶された位置 （アドレス） を指すビデオ読み出し ポインタを記憶し、 ビデオ読み出し機能部 2 3 3は、 バッファ 2 1 5 Aの、 ビデオ読み出しボイン夕が指す位置に記憶されているデータを 、 ビデオストリームとして読み出す。 stream— idレジスタ 242は、 バッファ 2 1 5 Aに記憶されたプログラムストリームを解析し、 その プログラムストリームの中から読み出すビデオストリームを識別 （特 定） するための後述する stream— idを記憶する。 au— information 0レ ジス夕 243は、 バッファ 2 1 5 Aからビデオストリームを読み出す ために必要な （ビデオストリームの読み出しに利用される） データで ある後述する au_information()を記憶する。
オーディオ読み出し機能部 2 34は、 第 1図のメモリ 1 1 3の一部 であるオーディオ読み出しポインタ記憶部 2 5 1、 stream— idレジス 夕 2 52、 および private— st ream_idレジスタ 2 5 3を有している。 オーディォ読み出しボインタ記憶部 2 5 1は、 バッファ 2 1 5 Aの 、 オーディオストリームが記憶された位置 （アドレス） を指すオーデ ィォ読み出しポインタを記憶し、 オーディオ読み出し機能部 234は 、 バッファ 2 1 5Aの、 オーディオ読み出しポインタが指す位置に記 憶されているデータを、 オーディオストリームとして読み出す。 stre anし idレジスタ 2 52と pri vat e— stream一 idレジス夕 2 5 3は、 バッフ ァ 2 1 5 Aに記憶されたプログラムストリームを解析し、 そのプログ ラムストリームの中から読み出すオーディォストリームを識別するた めの後述する stream_idと private— stream_idを、 それぞれ記憶する。 字幕読み出し機能部 2 3 5は、 第 1図のメモリ 1 1 3の一部である 字幕読み出し機能フラグ記憶部 2 6 1、 字幕読み出しボイン夕記憶部 26 2 , stream_idレジスタ 26 3、 および private— stream— idレジス 夕 2 64を有している。 字幕読み出し機能フラグ記憶部 2 6 1は、 字幕読み出し機能フラグ を記憶する。 字幕読み出し機能フラグ記憶部 2 6 1に記憶された字幕 読み出し機能フラグが、 例えば 0である場合、 字幕読み出し機能部 2 3 5は機能動作せず、 字幕読み出し機能フラグ記憶部 2 6 1に記憶さ れた字幕読み出し機能フラグが、 例えば 1である場合、 字幕読み出し 機能部 2 3 5は機能する。
字幕読み出しポインタ記憶部 2 6 2は、 バッファ 2 1 5 Aの、 字幕 ストリームが記憶された位置 （アドレス） を指す字幕読み出しポイン 夕を記憶し、 字幕読み出し機能部 2 3 5は、 バッファ 2 1 5 Aの、 字 幕読み出しポインタが指す位置に記憶されているデ一タを、 字幕スト リームとして読み出す。 stream— idレジスタ 2 6 3と private— stream— idレジスタ 2 64は、 バッファ 2 1 5 Aに記憶されたプログラムスト リームを解析し、 そのプログラムストリームの中から読み出す字幕ス トリームを識別するための後述する stream— idと private— stream— idを 、 それぞれ記憶する。
[ディスク 1 0 1に記録されたデータのデータフォーマツトの説明
]
次に、 ディスク 1 0 1に記録されたデータのデ一タフォ一マツトに ついて説明する。
第 4図は、 ディスク 1 0 1のディレクトリ構造を模式的に示してい る。
ディスク 1 0 1のファイルシステムとしては、 例えば、 ISO(Intern ational Organization for Standardizat ion) - 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図の PlayList 0) が 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に記録された各ファイルの詳細について説明 する。
「PLAYLIST.DAT」
第 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— s tringのサイズを 、 バイ ト数で表す。 name— stringは、 "PLAYLIST. DAT"ファイルの名称 (ファイル名） を表す。
なお、 name— stringについては、 その先頭から、 name— lengthで表さ れるバイ ト数までが有効な名称として使用される。 たとえば name— len gthが値 10である場合には、 name— stringの先頭から 10バイト分が有効 な名称として解釈される。
name_stringの後には、 number_of_PlayLists (16ビット） が配置さ れる。 number_of— PlayListsは、 続く PlayList 0の個数を表す。 numbe し of— PlayListsの後に、 その number_of—：?1& 1^313の数だけの？1& 1^5 tOが配置される。
PlayList ()は、 ディスク 1 0 1に記録されたクリップストリームフ アイルの再生手順が記述されたプレイリストであり、 以下のような内 部構造を有する。
即ち、 PlayList 0の先頭には、 PlayLisし data— length (32ビット） が配置される。 PlayLisし data— lengthは、 その PlayList 0のサイズを 表す。
PlayList_data lengthの後には、 reserved for— word alignment (1 5ビット） と capture— enable— flag— PUyList (1ビット） が順次配置さ れる。 15ビットの reserved_for— word— alignmentは、 その後に配置さ れる 1ビットの capture— enable_f lag— PlayListの位置で、 いわゆるヮ 一ドアライン（word alignment)をとるため （ 1 6ビットの位置に揃え るため） に配置される。 capture_enable_f lag— PlayListは、 PUyList 0によって再生されるビデオストリームに対応するビデオデータ （P1 ayListOに属するビデオデータ） の、 光ディスク 1 0 1が再生される 第 1図のディスク装置内での 2次利用を許可するか否かを表す 1ビッ トのフラグである。 capture— enable— flag_PlayListが、 0または 1の うちの、 例えば 1である場合、 PlayList ()に属するビデオデータの 2 次利用が許可されていることを表し、 capture_enable— flag— PlayList が、 0または 1のうちの、 例えば 0である場合、 PlayList 0に属する ビデオデータの 2次利用が許可されていない （禁止されている） こと を表す。
なお、 第 5図では、 capture_enable— flag_PlayListを 1ビットとし たが、 その他、 capture— enable— flag_PlayListは、 複数ビットで構成 し、 PlayList ()に属するビデオデ一夕の 2次利用を、 いわば段階的に 許可するようにすることが可能である。 即ち、 capture— enable_flag_ PlayListは、 例えば、 2ビットで構成することができる。 そして、 ca pture— enable_f lag— PUyListの値が OOB (Bは、 その前の数字が 2進数 であることを表す） である場合には、 ビデオデータの 2次利用を禁止 し、 capture_enable— flag—PlayListの値が 01Bである場合には、 ビデ ォデ一夕を、 64X 64ピクセル以下のサイズに縮小して利用する 2次利 用のみを許可することができる。 また、 capture_enable_nag_PlayLi stの値が 10Bである場合には、 サイズの制限なしで、 ビデオデ一夕の 2次利用を許可することができる。 さらに、 上述のように、 ビデオデータの 2次利用にあたって、 サイ ズに制限を設けるのではなく、 用途に制限を設けるようにすることも 可能である。 即ち、 capture— enabIe_flag—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ビット とした場合、 その前に配置される reservecljor— word— alignmentは、 ワードァラインをとるために、 14ビットとなる。
また、 capture— enable— flag一 PlayListにより、 ビデオデ一夕のディ スク装置内での 2次利用を許可する他、 ディスク装置外での 2次利用 を許可するようにすることも可能である。 ここで、 ビデオデータの、 ディスク装置外での 2次利用を許可する場合には、 ビデオデータは、 例えば、 ディスク装置に着脱可能な記録媒体やディスク装置に接続可 能な他の装置に着脱可能な記録媒体に記録され、 あるいはインタ一ネ ット等のネットワークを介して、 他の装置に送信 （配信） される。 こ の場合、 ビデオデータには、 そのビデオデータを記録媒体に記録する 回数や配信する回数を制限する情報を付加するようにすることができ る。
capture— enable一 flag— PlayLisUこ続 て 、 PlayList— name— length (8ビット） と PlayList— name— string (255バイト） とが順次配置され る。 PlayLisし name— lengthは、 その後に配置される PlayLisし name_st ringのサイズを、 バイト数で表し、 ：？1& 1^3し1^1116_3 11^は、 PlayLi st()の名称を表す。
?1& 3し纖6—5 11^の後には、 number_of_PlayI terns (16ビッ卜 ) が配置される。 numbeし of— Playltemsは、 続く PlayltemOの個数を 表す。
number— 0し Play It em の後には、 その number—of—Play 11 emsの数だけ の PlayltemOの構造が記述される。
ここで、 1つの P yList 0では、 PlayltemO単位で、 コンテンツの 再生手順を記述することができる。
また、 PlayList ()の中の、 number— of— Playl temsの数だけの Playl te m()それぞれに対しては、 その？1& 1^31()の中でュニークな10(1(1611 1 f ication)が付される。 即ち、 PlayList 0中の最初の PlayltemOには 、 IDとして 0番が付され、 以下、 続く PlayltemOに対して、 その出現 順に、 1番、 2番、 · · · と通し番号の IDが付される。
number_of— Play It emsの数だけの； PlayltemOの後には、 1つの PlayL istMarkOが配置される。 PlayListMarkOは、 PlayList 0にしたがつ て行われる再生の時間軸上の印となる後述する MarkOの集合で、 その 詳細については、 第 7図を参照して後述する。
「PlayItem()の説明」
次に、 第 6図は、 第 5図の P yListOに含まれる PlayltemOの内部 構造を示している。
PlayltemOの先頭には、 length (16ビット） が配置され、 lengthは 、 それを含む PlayltemOのサイズを表す。
lengthに続いては、 CI ip一 Information— fi le— name一 length (16ビッ ト） と Clip— Information— file— name (可変長) が順次配置される。 C1 ip— Information— file— namejengthは、 その後に配置される CI ip— Info rmation— f ile— nameのサイズを、 バイ ト数で表す。 CI ip— Inf ormat ion— file_nameは、 Playl tem()によって再生するクリップストリームファ ィル （第 4図の拡張子が PSのファイル） に対応するクリップ情報ファ ィル （第 4図の拡張子が CLPのファイル） のファイル名を表す。 なお 、 クリップストリームファイルおよびクリップ情報ファイルのフアイ ル名の、 上述した命名規則により、 Clip_Information_file— nameから 、 PlayltemOによって再生するクリップ情報ファイルのファイル名を 認識し、 そのクリップス卜リームファイルを特定することができる。
Clip— Information— file— nameに続いては、 IN— t ime (32ピット） と 0 UT_time (32ビット） が順次配置される。
IN_t imeと OUT— timeは、 それぞれ、 CI ip— Inf ormat ion_fi le一 nameか ら特定されるクリップストリームファイルの再生開始位置と再生終了 位置を指定する時刻情報である。
IN— timeによれば、 クリップストリームファイルの （先頭を含む） 途中の位置を再生開始位置として指定することができ.、 OUT— timeによ れば、 クリップストリームファイルの (最後を含む） 途中の位置を再 生終了位置として指定することができる。
ここで、 PlayltemOによれば、 CI ip— Inf ormat ion— f i le— nameから特 定されるクリップストリームファイルの、 IN_timeから 0UT_timeまで の間のコンテンツが再生される。 この PlayltemOによって再生される コンテンツを、 以下、 適宜、 クリップという。
rpiayListMarkOの説明」
次に、 第 7図は、 第 5図の PlayListOに含まれる PlayListMarkOの 内部構造を示している。
PlayListMarkOは、 上述したように、 その PlayListMarkOを含む P1 ayLis t() (第 5図） にしたがって行われる再生の時間軸上の印となる 、 0以上の MarkOの集合である。 1つの MarkOは、 PlayList 0にした がって行われる再生の時間軸上の 1つの時刻 （位置） を表す時刻情報 、 MarkOのタイプを表すタイプ情報、 およびタイプ情報がイベントを 発生させるタイプを表しているときの、 そのイベントの引数となる引 数情報を、 少なくとも有する。
即ち、 PlayListMarkOの先頭には、 length (32ビット） が配置され る。 lengthは、 それを含む PlayListMarkOのサイズを表す。
lengthの後には、 umber_of_Pl yList_ arks (16ピット） が配置さ れ、 number_of— PlayList— marksは、 それに続いて配置される MarkOの 個数を表す。 number_of— PlayListjnarksの後には、 その number_of— P1 ayL i s t_marksの数だけ Mark 0の構造が記述される。
MarkOの先頭には、 mark_type (8ビット） が配置される。 markjyp eは、 上述のタイプ情報であり、 それを含む MarkOのタイプを表す。 本実施の形態では、 MarkOのタイプとして、 例えば、 チヤプ夕（Cha pter)、 ィンデクス（Index)、 イベント（Event)の 3種類が用意されて いる。
タイプがチヤプ夕の MarkO (以下、 適宜、 チヤプタマークという） は、 PI ayLis 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— string (24バイ 卜) が目 置 れる。 mark— name— lengthと mark— name— stringは、 MarkO の名称を記述するためのものであり、 mark— name— lengthは、 mark— nam e— stringの有効なサイズを、 mark— name— stringは、 MarkOの名称を、 それぞれ表す。 従って、 mark— name— stringの先頭力、ら mark— name— leng thが表すパイト数までが、 MarkOの有効な名称を表す。
mark— name_lengthに続いては、 PlayList 0上で定義される MarkOを クリップストリームファイルと対応付ける 4つの要素 ref— to— Playlte m_id (16ビッ卜) 、 mark— time— stamp (32ヒッ卜) 、 entry— ES— stream —id (8ビット） 、 entry— ES— private— stream— id (8ビット） が順次配 置される。
ref—toJP yltem— idには、 MarkOが属する Play 11 em 0に対して通し 番号で付された IDが記述される。 refjo— Playltem— idによって、 Mark 0 が属する P yltemO (第 6図） が特定され、 ひいては、 第 6図で 説明したように、 クリップ情報ファイルとクリップストリームフアイ ルが特定される。
mark— time— st ampは、 ref— to—Playl tem— idによって特定されるクリ ップストリ一ムファイル内での MarkOが表す位置 （時刻） を表す。 ここで、 第 9図は、 PlayListO, Playl tem()、 クリップ、 およびク リップストリームファイルに格納されたプログラムストリームの関係 を示している。 .
第 9図では、 PlayListOは、 3つの PlayltemOから構成されており 、 その 3つの PlayltemOそれぞれには、 通し番号で付される ID#0, #1 ， #2が付されている。 ここで、 以下、 適宜、 ID#iが付された Playltem 0を、 Playltem#iと記述する。
また、 第 9図では、 PlayltemtO, Playltemtl, Playl tem#2によって 再生されるコンテンツであるクリップが、 それぞれ、 クリップ A、 ク リップ B、 クリップ Cとして示されている。
クリップの実体は、 第 6図の PlayltemOにおける Clipjnformation _file_nameから特定される （クリップ情報ファイルから、 さらに特定 される） クリップストリームファイルに格納されたプログラムストリ ームのうちの、 Iltimeから OUT— timeまでのプログラムストリームで ある。 第 9図では、 クリップ A、 クリップ B、 クリップ Cの実体とし てのプログラムストリームが、 プログラムストリーム A、 プログラム ストリーム B、 プログラムストリーム Cとして、 それぞれ示されてい る。
例えば、 第 9図において、 PlayListOにしたがって行われる再生の 時間軸上の位置 （時刻） tOの印となる MarkOにおいては、 その ref— to —Playltem— idと mark— time— stampま、 次のように記述される。
即ち、 時刻 tOは、 Playltemiflの再生が行われる時刻であるため、 re f一 to_PlayItem_idには、 その Playltem#lの IDである 1が記述される。 さらに、 時刻 tOでは、 P yItem#lによって、 クリップ Bの実体である プログラムストリーム Bが再生されるため、 mark— time— st ampには、 プログラムストリーム Bが格納されたクリップストリームファイルに おける時刻 tOに相当する時刻が記述される。 再び、 第 7図に戻り、 entry— 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_packet ()) の後述する stream —idが記述される。 また、 entry— ES— private— stream— idには、 必要に 応じて、 MarkOを関連付けるエレメンタリストリーム （が配置される 、 後述する第 2 1図に示す private— streamし PES_payload()における p rivate— header 0) の後述する private— stream— idが記述される。
例えば、 ビデオストリーム # 1とビデオストリーム# 2が多重化さ れているクリップにおいて、 ビデオス卜リーム # 1を再生している場 合と、 ビデオス卜リーム # 2を再生している場合でチヤプ夕の発生時 刻を変更したいときには、 ビデオストリーム# 1再生時のチヤプ夕マ ーク発生時刻の MarkOの entry— ES—s tream— idと entry— ES— private— s tr eam— idに、 ビテオス卜リーム # 1の stream— idと private— stream_idが 記述され、 また、 ビデオストリーム # 2再生時のチヤプ夕マーク発生 時亥 ijの Mark 0 の entry— ES— stream— idと entry— ES— private— stream— id に、 ビデオストリーム # 2の st ream— idと private— st ream_idが記述さ れる。
なお、 特定のエレメンタリストリームに関連付けない MarkOの entr y— ES—s tream— idと、 entry_ES— private— stream— idに W：、 例え【ま、 ず れも 0が記述される。
entry— ES_private— stream一 idの後には、 mark— data (3 2ビット） が配置される。 mark— dataは、 MarkOがイベントマークである場合に 、 そのイベントマークによって発生されるイベントの引数となる引数 情報である。 なお、 mark— dataは、 MarkOがチヤプ夕マークやインデ クスマークである場合に、 そのチヤプタマークゃィンデクスマークが 表すチヤプ夕ゃィンデクスの番号として使用することも可能である。
「Clip()の説明」
次に、 第 4図の" CLIP"ディレクトリに置かれる、 拡張子が CLPのク リップ情報ファイルの内部構造について説明する。
第 4図では、 "CUP"ディレクトリに、 3つのクリップ情報ファイル " 00001. CLP", " 00002. CLP" , " 00003. CLP"が置かれており、 それぞれ には、 " STREAM"ディレクトリに置かれたクリップストリームファイル " 00001.PS", " 00002.PS", " 00003.PS"の性質等を示すメタデータが格 納されている。
第 1 0図は、 そのようなクリップ情報ファイル ClipOの内部構造を 示している。
クリップ情報ファイル Clip 0の先頭には、 presentation— start— tim eと presentation_end— time (いずれも 3 2ビット） が、 順次配置され る。 presentation— start— timeと presentation— end— timeは、 クリツフ 情報ファイル ClipOに対応するクリップストリームファイル （に格納 されているプログラムストリーム） の先頭と最後の時刻を表す。 なお 、 クリップストリームファイルの時刻は、 MPEG2_Systemの時刻で使わ れている 90kHzの倍数で記述される。
pre sent at ion— end— t i me ίこ続レ て【ま、 reserved— for— word— a 1 ignment (7ビット） と capture— enable— ag— Clip (1ビット） が順次配置され る。 7ビッ卜の reserved— f or— word— al ignmentは、 ワードァラインをと るためのもので、 capture_enable— flag— CI ipは、 上述した第 5図の ca pture_enable_nag_PlayListと同様に、 ビデオデータの 2次利用を許 可するか否かを表すフラグである。 但し、 第 5図の capture— enable— flag一 PlayListは、 PlayListOによ つて再生されるビデオストリームに対応するビデオデータ （PlayList 0に属するビデオデータ） の 2次利用を許可するか否かを表すのに対 して、 第 10図の capture— enable— flag_Clipは、 クリップ情報フアイ ル ClipOに対応するクリップストリームファイルに格納されているビ デォストリ一ム （ビデオのエレメン夕リストリーム） に対応するビデ ォデ—夕の 2次利用を許可するか否かを表す。 従って、 第 5図の capt ure— enable— flag_PlayListと、 第 1 0図の capture— enable— flag— CI ip とでは、 2次利用を許可するビデオデータの単位 （範囲） が異なる。 なお、 第 1 0図の capture_enable— flag— Clipも、 第 5図の capture— enable— flag_PlayListで説明したように、 1ビットではなく、 複数ビ ットとすることが可能である。
capture— enable— flag_Cl ipの後には、 number— o.f— streams (8ヒッ卜
) が配置され、 この numbeし 0し streamsには、 それに続く Streamlnfo ( )構造の個数が記述される。 従って、 number— of— streamsに続いては、 その number_oし Streamsの数だけ、 Streamlnfo 0の構造が記述される
StreamlnfoOの先頭には、 length (16ビット） が配置され、 この le ngthは、 それを含む StreamlnfoOのサイズを表す。 lengthに続いては 、 stream一 id (8ビット） と private_stream— id (8ビット） が配置され ており、 この stream— idと private— stream— idによって、 Streamlnfo 0 に関連付けるエレメン夕リストリームが特定 （識別） される。
ここで、 第 1 1図は、 エレメンタリストリ一ムを識別する stream— i dおよび private一 stream_idと、 エレメンタリストリームとの関係を示 している。
stream idは、 MPEG2-Sys tem規格において規定されているのと同一 のものであり、 その値は、 MPEG2- System規格において、 エレメンタリ ストリーム （データ） の属性 （種類） ごとに、 あらかじめ決められて いる。 従って、 MPEG2- System規格で定義されている属性のエレメン夕 リストリ一ムは、 stream— idだけで特定することができる。
本実施の形態では、 MPEG2- System規格において規定されていない属 性のエレメン夕リストリームも扱うことが可能になっており、 privat e— stream— idは、 MPEG2- System規格において規定されていない属性の エレメンタリストリームを識別するための情報である。
第 1 1図では、 MPEGで規定されている符号化 （復号） 方式でェンコ —ドされたビデオのエレメンタリストリ一ム、 ATRAC (Adapt ive TRans form Acoustic Coding)方式でエンコードされたオーディオのエレメ ン夕リストリーム （以下、 適宜、 ATRACオーディオストリームという ) 、 LPC (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で行うことができるので、 private_s eam_idは不要である （無 視することができる） 。
一方、 MPEG2- Systemでは、 ATRACオーディオストリーム、 LPCMォ一 ディォストリーム、 字幕ストリームについては、 stream— idは定義さ れていない。
そこで、 本実施の形態では、 MPEG2- Systemで stream— idが定義され ていないエレメン夕リストリームについては、 その stream一 idに、 MPE G2- Systemにおいて private—stream— 1という属性を表す値である 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— stream— idが使用される。 従って、 プログラムストリー ムには、 32本の字幕ス卜リームを多重化することができる。
なお、 stream_idおよび private_stream— idについては、 さらに後述 する。
第 1 0図に戻り、 private— stream— idの後には、 Stat iclnfo () , res erved_for_word_alignment (8ビット） が順次配置される。 Staticlnf οθには、 （その S ticInfoOを含む StreamlnfoOに記述された） str eam_idおよび private— stream— idによって特定されるエレメン夕リス トリームの再生中に変化しない情報が記述される。 Stat ic Info 0の詳 細については、 第 1 2図を参照して後述する。
reserved— for— word— a 1 ignmentは、 ワードァラインをとるために使 用される。
reserved— for— word— a 1 ignmenUこ続レ てま、 number— of—Dynamic Info (8ビット） が配置され、 number— of— Dynamiclnfoは、 その後に続いて 配置される pts— change— point (32ピット） と Dynamiclnf o 0のセット の数を表す。
従って、 number— of— Dynamiclnfoiこ続レ てま、 その number— of— Dynam ic Infoの数だけのセット数の pts— change— pointと Dynamic Info 0の構 造が記述される。
pts— change— pointは、 それとセットになっている Dynamiclnf o 0の 情報が有効になる時刻を表す。 ここで、 エレメン夕リストリームの先 頭の時刻を表す pts_change_pointは、 そのエレメン夕リストリームが 格納されたクリップストリームファイルに対応するクリップ情報ファ ィル Clip 0の最初に記述される present at ion— start— timeに等しい。
Dynamiclnf o 0 ίこま、 s t ream— idおよび private— s t ream— id ίこよつて 特定されるエレメン夕リストリームの再生中に変化する、 いわば動的 な情報が記述される。 DynamicInfoOに記述された情報は、 それとセ ットになっている p t s_change_poi n tが表す再生時刻となったときに有 効になる。 なお、 DynamicInfoOの詳細については、 第 1 3図を参照 して後述する。
number— 0し Dynamic Infoの数だけのセッ卜の pts— change— pointと Dyn amicInfoOの後には、 EP— map 0が配置される。 なお、 EPjnap 0につい ては、 第 14図を参照して後述する。 rstatidnfoOの説明」
次に、 第 1 2図を参照して、 第 1 0図の StaticInfoOの詳細に'つい て説明する。
第 1 2図は、 StaticInfoOのシンタクスを示している。
StaticInfoOは、 対応するエレメンタリストリームの属性 （種類） により内容が異なっている。 StaticInfoOに対応するエレメン夕リス トリ一ムの属性は、 その StaticInfoOを含む第 1 0図の S eamlnf o 0 に含まれる stream— idと private_stream_idにより判断される。
StaticInfoOに対応するエレメンタリストリ一ムがビデオストリー ムである場合（stream==VIDE0)、 StaticInfoOは、 picture— size (4ビ ット） ， frame一 rate (4ビット） ， および cc— flag (1ビット） と、 ヮ 一ドアラインをとるための reserved— for— word— a lingmentとで構成さ れる。
picture— sizeは、 ビデオストリームに対応するビデオデータ （によ つて表示される画像） の大きさを表す。 frame— rateは、 ビデオストリ —ムに対応するビデオデータのフレーム周波数を表す。 cc_flagは、 ビデオストリームにクロ一ズドキヤプション（Closed Caption)データ が含まれているか否かを表す。 即ち、 例えば、 ビデオストリームにク ローズドキヤプションデータが含まれている場合には、 cc_flagは 1 とされ、 ビデオストリームにクローズドキャプションデータが含まれ ていない場合には、 cc— flagは 0とされる。
StaticInfoOに対応するエレメンタリストリームがオーディオスト リームである場合（stream==AUDI0)、 Stat iclnf o 0は、 audio— languag e— code (16ビッ卜) ， channel— conf igurat ion (8ビッ卜) , lfe— exis tence (1ビッ卜) 、 および sampl ing— frequency (4ビッ卜) と、 ヮー ドアラインをとるための reserved— for— word一 a lingmentとで構成され る。
audio— language— codeには、 ォ一ディォストリームに含まれている オーディォデ一夕の言語を表すコードが記述される。 channeし config urationは、 モノラル（mono)/ステレオ（stereo)/マルチチャネル等の 、 オーディオストリームに含まれているオーディオデータの属性を表 す。 lfe— existenceは、 オーディオストリームに低域強調チャネルが 含まれているかどうかを表し、 含まれていれば 1となり、 含まれてい なければ 0となる。 sa即 ling— frequencyは、 オーディオストリームに 含まれているオーディオデータのサンプリング周波数を示す情報であ る。
StaticInfoOに対応するエレメンタリストリームが字幕ストリーム である場合（stream==SUBTITLE)、 Staticlnfo 0は、 subt i t le_languag e— code (16ビット） および conf igurable_flag (1ビット） と、 ワード ァラインをと ¾ 7t ¾) 6 reserved_f or_word_al ingmentとで構成される 。
subtitle— language— codeには、 字幕ストリームに含まれている字幕 デ一夕の言語を表すコードが記述される。 conf igurable— flagは、 字 幕ストリ一ムに含まれている字幕データの表示をデフォルトの表示方 式から変更することを許可するか否かを表す情報で、 例えば、 表示方 式の変更が許可されている場合には 1が記述され、 許可されていない 場合には 0が記述される。 なお、 字幕データの表示方式としては、 字 幕デ一夕の表示サイズや、 表示位置、 表示色、 表示パターン （例えば 、 点滅表示など） 、 表示方向 （例えば、 垂直方向や水平方向） などが ある。
「DynamicInfo()の説明」
次に、 第 1 3図を参照して、 第 1 0図の DynamicInfoOの詳細につ いて説明する。
第 1 3図は、 DynamicInfoOのシンタクスを示している。
DynamicInfoOの先頭には、 ワードァラインのための reserved— for— ord_alignment (8ビット） が配置されており、 その後に続く要素は 、 DynamicInfoOに対応するエレメン夕リストリームの属性により内 容が異なっている。 DynamicInfoOに対応するエレメンタリストリ一 ムの属性は、 第 1 2図で説明した StaticInfoOにおける場合と同様に 、 DynamicInfoOを含む第 1 0図の Streamlnfo 0に含まれる stream_id と private— stream— idにより判断される。
DynamicInfoOには、 第 1 0図で説明したように、 エレメン夕リス トリームの再生中に変化する動的な情報が記述される。 この動的な情 報は、 特に限定されるものではないが、 第 1 3図の実施の形態では、 DynamicInfoOに対応するエレメンタリストリ一ムに対応するデ一夕 、 即ち、 エレメンタリストリームが処理されることによって出力され るデータの出力属性 （エレメンタリストリームから得られるデ一夕の 出力属性） が、 DynamicInfoOに記述される。
具体的には、 DynamicInfoOに対応するエレメン夕リストリームが ビデオストリームである場合（stream==VIDE0)、 Dynamiclnf o 0は、 di splay— aspect— rat io (4ヒッ卜) と、 ワードァラインのための reserve d— for_word— al ingmentとで構成される。 diplay— aspect— ratioには、 ビデオストリームに対応するビデオデータの出力属性 （表示方式） と しての、 例えば、 そのビデオデータのアスペクト比が記述される。 即 ち、 diplay— aspect— ratioには、 例えば、 アスペクト比が、 16:9また は 4:3のうちのいずれであるかを表す情報が記述される。 なお、 ビデ ォストリームの DynamicInfoOには、 アスペクト比の他、 例えば、 ビ デォデータによって表示される画像のサイズ （X画素 XY画素） など を記述することが可能である。
DynamicInfoOに対応するエレメン夕リストリ一ムがオーディォス トリームである場合（stream==AUDIO)、 Dynamiclnfo 0は、 channel— as signment (4ビット） と、 ワードァラインをとるための reserved— for— 暫 d— alingmentとで構成される。 cha匿 1— assig匿 ntには、 オーディ ォストリームに 2チャネルのォ一ディォデ一夕が含まれている場合に 、 その 2チャネルの出力属性 （出力方式） が記述される。 即ち、 chan nel— assignmentには、 オーディオデ一夕が、 ステレオまたはデュアル (ニケ国語） のうちのいずれのチャネル割り当てがされているもので あるかを表す情報が記述される。
DynamicInfoOに対応するエレメンタリストリームが字幕ストリー ムである場合（stream==SUBTITLE)、 Dynamiclnfo 0は、 ワードァライ ンをとるための reserved—for— word_alingmentで構成される。 即ち、 第 1 3図の実施の形態では、 字幕ストリームに関しては、 動的な情報 としての出力属性は定義されていない。
「EP_map 0の説明」
次に、 第 14図を参照して、 第 1 0図の EP—mapOの詳細について説 明する。
第 14図は、 EPjnapOのシンタクスを示している。
EPjnapOには、 その EP— map()を含む第 1 0図のクリップ情報フアイ ル ClipOに対応するクリップストリームファイルに格納されたプログ ラムストリームに多重化されているエレメンタリストリーム毎に、 各 エレメン夕リストリ一ムの、 デコードを開始することができるデコ一 ド開始可能点 (エントリポイント) の情報が記述される。
ここで、 固定レートのストリームについては、 デコード開始可能点 は、 計算によって求めることができるが、 可変レートのストリーム、 あるいは MPEG規格にしたがって符号化されたビデオストリームのよう に、 ビデオアクセスアクセスュニットごとにサイズが異なるストリー ムについては、 デコード開始可能点は、 計算によって求めることがで きず、 実際にストリームを解析しないと見つけることができない。 デ コード開始可能点を迅速に認識することは、 ランダムアクセスを行う ために重要であり、 EPjnapOによれば、 デコード開始可能点を迅速に 認識することができる。
なお、 MPEG2_Videoでは、 Sequence— header 0 (シーケンスヘッダ） 等を含めたィントラピクチャの先頭が、 デコード開始可能点である。
EP— map()の先頭には、 ヮ—ドアラインのための reserved— for— word— alignment (8ビット） が配置されており、 続いて number_of— stream— i d— entries (8ビッ卜） が配置されてレ る。 醒 ber— of— stream— id— entr i esは、 EPjnap 0にデコード開始可能点の情報が記述されているエレ メン夕リストリームの本数を表す。
1111111136し0【_3 6&111—1(1ー611 163の後には、 エレメン夕リストリーム を識別するための情報と、 そのエレメン夕リストリームのデコード開 始可能点の情報とが、 numb e r _o f— s t r e am— i d— e n t r i e sが表す数だけ繰 り返し配置される。
即ち、 111111^6し0し3 6&111—1(1—611 163の直後には、 エレメン夕リス トリ一ムを識別する情報としての stream— id (8ビット） と private_st ream— id (8ビット） が配置され、 それに続けて、 number— of— EP— entr i es (32ビット） が配置される。 number— 0し EP— entriesは、 その直前の stream— idと private— stream— idで識別 （特定） されるエレメン夕リス トリ一ムのデコード開始可能点の数を表す。
number— of— 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っでぁる11^_61)—31&1^には、 上 述のように stream— idと private— stream— idで特定されるエレメン夕リ ストリームが多重化されているプログラムストリームが格納されたク リップストリ一ムファイル内での、 デコード開始可能点の位置を、 プ ログラムス卜リームの pack 0単位で数えたときの値が記述される。 な お、 本実施の形態では、 packOのサイズは 2048バイトで固定であると する。 また、 本実施の形態では、 ディスク 1 0 1 (第 1図） の 1セク 夕が、 2048バイトであるとする。
ここで、 ビデオストリームについては、 そのデコード開始可能点 （ エントリポイント） の直前に、 後述する private— stream_2パケット （ private— stream— 2の属性の PES— packet ()) が配置きれている。 rivat e— stream— 2パケットは、 その private— stream— 2パケットから、 次の pr ivate— stream— 2バケツトまでの間に配置されているビデオストリ一ム をデコードするのに利用される情報が格納されている。 このため、 ビ デォストリームについては、 デコード開始可能点の情報としての RPN— EP— startには、 実際のデコード開始可能点そのものではなく、 実際の デコード開始可能点の直前に配置されている private— stream— 2バケツ トの先頭の位置が記述される。 また、 EP_map()において、 デコード開始可能点の情報としての PTS— EP_s t ar t i: RPN_EP_s t t (D-ty卜は、 stream— idと private— stream— idで特定されるエレメン夕リストリームごとに、 あらかじめ、 昇順に ソートされている。 これにより、 デコード開始可能点の情報としての PTS— EP— 31& と!^1^—81)—5 1^とのセットは、 二分探索が可能となって いる。 '
なお、 可変レートのストリームや、 ビデオアクセスアクセスュニッ トごとにサイズが異なるストリームを対象としたランダムアクセスの 方法は、 例えば、 特開 2000- 341640号公報 （特願平 11-317738号） など 'に記載されている。
「クリップストリ一ムファイルの説明」
次に、 第 4図の" STREAM"ディレクトリに置かれる、 拡張子が PSのク リップストリームファイル （第 4図では、 " 00001.PS"， " 00002.PS", " 00003.PS") の内部構造について説明する。
クリップストリ一ムファイルは、 MPEG-2 System (ISO/IEC 13818-1 )に定義された MPEG2— Program— StreamOをべ一スに構成されている。 即ち、 第 1 5図 Aおよび第 1 5図 Bは、 MPEG- 2 Sys tern (ISO/IEC 13 818- 1:2000)規格に記述されている Table2- 31， Table2-32, Table2-33 を示している。
クリップストリームファイルに格納されたプログラムストリームは 、 MPEG- 2 System規格の Table2- 31に定義されている MPEG2—Program— St reamOであり、 1つ以上の pack 0と、 1つの MPEG— program— end— code で構成される。 なお、 MPEG2— Program— StreamOの説明は、 特許第 2785 220号などにも記載されている。
1つの packOは、 MPEG- 2 System規格の Table2- 32に定義されている ように、 1つの Pack— header 0と、 任意の数の PES— packet 0とで構成 される。 Pack— header 0の詳細は、 MPEG- 2 System規格の Table2- 33に 定義されている。
ここで、 MPEG- 2 System規格では、 packOのサイズは、 可変長とし て定義されているが、 ここでは、 第 1 4図で説明したように、 2048バ イトで固定であるとする。 さらに、 ここでは、 1つの packOの PES— pa cketOの数は、 1つ、 2つ、 または 3つとする。 PackOが後述する pr ivate— stream— 2パケットで始まる場合、 その直後 （同じ PackO内） に 対応するビデオストリームの PES— packet ()が必ず存在する。 またこれ に加えて 3つ目の PES_packet 0として padding— packet (パディングパ ケット） を置くことができる。 なお private— stream— 2パケットは必ず PackOの先頭におかれる。
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_start— code— prefix, stream— id、 および P ES— packet_length (第 1 6図 Aおよび第 1 6図 B) と s t ream— 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である場合（s tream_ id==padding一 stream)、 PES— packet— data— by teに代えて、 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— packet 0の PES_packet— data— byte (第 1 8図 Aおよび第 1 8図 B ) に格納される。 そして、 PES— packet 0の st ream— idには、 その PES— ρ acket_data_byteに格納されたエレメンタリストリームを識別するた めに、 そのエレメン夕リストリームの属性に応じた値が記述される。
PES_packet 0の 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 ()の stream_idは、 第 2 0図にしたがい、 10111110Bとされる。 さらに、 private— stream— 2と 呼ばれる属性のエレメンタリストリ一ムの PES— packet 0の stream一 id は、 第 2 0図にしたがい、 101111UBとされる。
また、 MPEGで定義されたオーディオストリーム （オーディオのエレ メン夕リストリーム） の PES—packet ()の stream_idは、 ΙΙΟχχχχχΒとさ れる。 なお、 ΙΙΟχχχχχΒのうちの下位 5ビット xxxxxは、 オーディオス トリームを区別するオーディォストリームナンパであり、 プログラム ストリーム （MPEG2— Program— St ream 0) には、 このオーディオストリ ームナンパで区別することのできる数である 3 2 (= 25) 本のォ一 ディォストリーム （MPEGで定義されたオーディオストリーム） を多重 化することができる。
さらに、 MPEGで定義されたビデオストリーム （ビデオのエレメン夕 リストリーム） の PES— packet 0の stream— idは、 11 ΙΟχχχχΒとされる。 なお、 ΙΙΙΟχχχχΒのうちの下位 4ビット xxxxは、 ビデオストリームを 区別するビデオストリームナンパであり、 プログラムストリームには 、 このビデオストリームナンパで区別することのできる数である 1 6
(= 24) 本のビデオストリーム （MPEGで定義されたビデオストリー ム） を多重化することができる。
ところで、 stream— idが ΙΙΙΟχχχχΒの PES— packet 0は、 MPEGで定義さ れたビデオストリ一ムを格納するために使用され、 stream— idが ΙΙΟχχ xxxBの PES—packetOは、 MPEGで定義されたオーディオストリームを格 納するために使用される。 一方、 MPEGで定義されていない符号化方式 (たとえば ATRAC方式） のエレメン夕リストリ一ムを格納するのに使 用する PES— packet 0の stream— idは、 MPEGでは規定されておらず、 従 つて、 MPEGで定義されていない符号化方式のエレメンタリストリ一ム は、 MPEGで定義されたビデオストリ一ムやオーディォストリームと同 様に、 単純に、 stream— idを指定して、 PES_packet 0に格納すること はできない。
そこで、 本実施の形態では、 private— stream— 1の PES— packet ()の PE S_packet— data— byteを拡張し、 MPEGで定義されていない符号化方式の エレメンタリストリームを格納する。
ここで、 private— stream— 1の PES_packet ()の、 拡張した PES— packet —data— byteを、 private— st re ami— PES— pay load 0と記述する。
「private— st reaml— PES— payloadOの説明」
第 2 1図は、 private—streamlJES— payloadOのシンタクスを示し ている。
pr i vat e_streaml_PES_pay load 0は、 private— header 0と private— p ayloadOとで構成される。 private— pay load 0には、 ATRACオーディオ ストリームや、 LPCMオーディオストリーム、 字幕ストリームなどの、 MPEGで定義されていない符号化方式のエレメン夕リストリームが格納 される。
private— header ()の先頭には、 private— stream— id (8ビッ卜） が配 置される。 private— stream— idは、 private— payloadOに格納されるェ レメンタリストリームを識別する識別情報で、 その属性 （種類） に応 じて、 例えば、 以下のような値とされる。
即ち、 第 2 2図は、 private— stream— idの値と、 private— payload 0 に格納されるエレメン夕リストリ一ムの属性との関係を示している。 第 2 2図では、 OOOOxxxxB, OOOlxxxxB, ΙΟΟχχχχχΒの 3パターンが 、 private— stream_iclの値として採用されている。 なお、 "x"は、 第 2 0図における場合と同様に、 0または 1のうちの任意の値を表す。 第 2 2図によれば、 ATRACオーディオストリームが private— payload 0に格納される private— streaml_PES— payloadOの private— s t ream— id は、 OOOOxxxxBとされる。 なお、 OOOOxxxxBのうちの下位 4ビット xxxx は、 ATRACオーディォストリームを区別するォ一ディォストリ一ムナ ンバであり、 プログラムストリーム （MPEG2— Program— St ream 0) には 、 このオーディオストリームナンパで区別することのできる数である 1 6 (= 24) 本の ATRACオーディオストリームを多重化することがで きる。
さらに、 第 2 2図によれば、 LPCMオーディオストリームが private— payloadOに格納される private— streaml— PES— payloadOの private— st ream— idは、 OOOlxxxxBとされる。 なお、 OOOlxxxxBのうちの下位 4ビ ット xxxxは、 LPCMオーディォストリ一ムを区別するオーディォストリ ームナンパであり、 プログラムストリームには、 このオーディオスト リームナンパで区別することのできる数である 1 6 (= 24) 本の LPC Mオーディォストリームを多重化することができる。
また、 第 2 2図によれば、 字幕ストリームが private— payloadOに 格納される private— streaml— PES— payload 0の private— stream— idは、 lOOxxxxxBとされる。 なお、 ΙΟΟχχχχχΒのうちの下位 5ビット xxxxxは 、 字幕ストリームを区別する字幕ストリームナンパであり、 プロダラ ムストリームには、 この字幕ストリ一ムナンパで区別することのでき る数である 3 2 (== 25) 本の字幕ストリームを多重化することがで きる。
ここで、 第 20図と第 22図の関係をまとめたものが、 上述した第 1 1図である。
第 2 1図に戻り、 private— streamし PES— payloadOにおいて、 priva te— stream_idに続く要素は、 pr ivate_payload 0に格納されるエレメ ン夕リストリ一ムの属性により内容が異なっている。 private— payloa d()に格納されるエレメンタリストリームの属性は、 private—header ( )の先頭の private— stream— idにより判断される。
private_payload()に格納されるエレメン夕リストリ一ムが ATRACォ —ディォストリ一ムである場合（private一 stream— id==ATRAC)、 将来の 拡張用の reserved— foし future— use (8ビット） が配置され、 その後、 AU— locator (16ビット） が配置される。 AU— locatorは、 その AU— locat orの直後の位置を基準として、 private— payloadOに格納された ATRAC オーディォストリームのオーディォアクセスュニット （ATRACオーデ ィォアクセスュニッ卜) (オーディオフレーム） の先頭位置を表す。 private_payload()にオーディオアクセスュニットが存在しない場合 、 AU— locatorには、 例えば OxFFFFが記述される。
private_payload()に格納されるエレメンタリストリームが LPCMォ 一ディォストリームである場合（private_stream— id==LPCM)、 fs_flag (1ヒッ卜) ， reserved— for— future— use (3ヒッ卜 j ， ch_f lag (4ビ ット） 、 および AU— locator (16ビット） が順次配置される。
fs— flagは、 private— payloadOに格納される LPCMオーディォストリ ームのサンプリング周波数を示す。 即ち、 例えば、 サンプリング周波 数が 48KHzの場合、 fs— flagは 0とされ、 サンプリング周波数が 44. ΙΚΗζ の場合、 fs— flagは 1とされる。
ch— flagは、 private— payloadOに格納される LPCMオーディオストリ ームのチャネル数を示す。 例えば、 LPCMオーディオストリームがモノ ラルの場合、 ch— flagは 1とされ、 LPCMオーディオストリームがステレ ォの場合、 ch一 flagは 2とされる。
AU—locatorは、 その AU— locatorの直後の位置を基準として、 privat e— payloadOに格納される LPCMオーディォストリームのオーディオア クセスユニット （LPCMオーディオアクセスユニット） （オーディオフ レーム） の先頭位置を示す。 private— payloadOにオーディオアクセ スユニットが存在しない場合、 AU— locatorには、 例えば OxFFFFが記述 される。
private一 payloadOに格納されるエレメンタリストリームが字幕ス トリームである場合（private_streanし id==SUBTITLE)、 将来の拡張の ための reserved_for_future_use ( 8ビット） が配置され、 その後に 、 AU— locator (16ビット） が配置される。 AU— locatorは、 その AU—loc at orの直後の位置を基準として、 private— payloadOに格納される字 幕ストリームの字幕アクセスュニットの先頭位置を示す。 private— pa yloadOに字幕アクセスユニットが存在しない場合、 AU_locatorには 、 例えば OxFFFFが記述される。
「private— st ream2— PES— payloadOの説明」
次に、 第 2 3図は、 private— stream2— PES— payloadOのシンタクス を示している。
private— stream2— PES— payload ()は、 private— stream— 2の PES— packe tOの PES_packeし data— byte (第 1 8図 Aおよび第 1 8図 B) を拡張 したもの、 即ち、 private_stream_2の PES一 packet 0の、 拡張した PES— packet— data— byteであり、 ビデオストリームのデコードに利用される 情報が記述される。
本実施の形態では、 private_stream_2の PES_packet 0は、 ビデオス トリームにおけるデコード開始可能点の直前に配置される。 従って、 本実施の形態では、 プログラムストリームから private— stream— 2の PE S_packet ()を見つければ、 その直後のビデオストリームからデコ一ド を開始することができる。
ここで、 上述した第 1 4図の EPjnapOの RPN— EP— startは、 ビデオス トリームについては、 private stream— 2の PES _packet()の先頭の位置 を示す。
private— stream2— PES— payloadOの先頭には、 将来の拡張用の reser ved_for_future_use (8ビット） が配置され、 続けて、 video_s t ream— id (8ビット） ， IstRef一 picture (16ビット） ， 2ndRef一 picture (16 ビット） ， 3rdRef_picture (16ビット） ， 4thRef_picture (16ビット ) , au— information()、 および VBIOが、 順次配置される。
video— stream— icHこ【ま、 private— stream— 2の PES— packet 0の直後 ίこ 配置されるビデオストリームの PES— packet ()の stream— id (と同一の 値） が記述される。 この video— stream— idによって、 private— s t ream— 2の PES— packet 0 (の private— stream2—PES_pay load 0) に格納された 情報を利用してデコードされるビデオストリーム （が格納された PES— packet 0) が特定される。
IstRef— picture, 2ndRef— picture, 3rdRef— picture, 4thRef_pictu reは、 video— stream— idによって特定されるビデオストリームの、 pri vate— stream一 2の PES— packet 0力、ら次の private— stream— 2の PES— packe tOまでの中の 1 , 2, 3， 4番目の参照画像を含む最後の packOの 位置を相対値で、 それぞれ表す。 なお、 IstReし picture, 2ndRef_pic ture, 3rdRef— picture, 4thReし pictureについては、 例えば、 特開平 09- 46712号公報 （特願平 07- 211420号） に、 bytes— to— first— P_pic by tes— to_second_P— picとして、 その詳細が開示されている。
au— information ()には、 private— stream— 2の PES— packet 0力 ら、 次 の private_stream_2の PES— packet 0までのビデオストリームの中のビ デォアクセスュニットに関する情報が記述される。 au— informationO の詳細については、 第 24図を参照して後述する。
VBIOは、 Closed Captionの情報を記述するために使用される。 以上のよう ¾private_stream2_PES_payload()を有する private str earn— 2の PES— packet 0は、 ビデオストリームごとの、 デコード開始可 能点ごとに配置される。
次に、 第 24図は、 第 2 3図の au— informationOのシンタクスを示 している。
au— informationOの先頭には、 length (16ビット） が配置される。 lengthは、 それを含む au— informationOのサイズを表す。 lengthに続 いては、 reserved— for一 word— al ignment (8ビッ卜) 、 および number— o f— access— unit (8ピット） が順次配置される。 reserved— for— word— al ignmentは、 ヮ一ドアラインをとるために使用される。
number— of— access— uni "ま、 それを含む private_stream— 2の PES— pac ket ()から、 次の private— stream_2の PES_packet ()までの間に含まれ るビデオアクセスユニット （ピクチャ） の数を表す。
即ち、 number— of— access— unitは、 第 2 3図の private— s tream2— PES —payloadOが同一の video— stream_idを有する private— stream— 2の PES — packet 0の中で、 この au— inf ormatnio 0力 ら次の au— inf ormat ion 0 の直前までに （この au— infromationOがクリップストリ一ムファイル で最後の au— informationOであれば、 クリップストリームファイルの 最後までに） 、 video— stream— idで示されるビデオストリームに含ま れるアクセスユニット （ピクチャ） の数を示す。
number— of— access— uni tの後には、 その number— of— access— uni tの数 だけ forループの内容が配置される。 即ち、 number— 0し access_unitを 含む private— stream— 2の PES— packet 0から、 次の private— stream— 2の PES_packet()までの間に含まれる 1以上のビデオアクセスュニットそ れぞれに関する情報が配置される。
forループ内に配置される情報 （ビデオアクセスユニットに関する 情報） は、 以下のようになつている。 即ち、 forループ内には、 pic_struct_copy (4ビット） ， au_ref_f 1 ag (1ビット） ， AU— length (21ビット） ， reservedが配置される。 pic_struct— copyには、 ビデオストリームが MPEG4-AVC (IS0/IEC 14 496-10) の場合に、 対応するビデオアクセスユニットに対して設定さ れている、 IS0/IEC 14496-10, D.2.2に定義されている pic— struct ( ) のコピーが記述される。 なお、 pic— struct 0 は、 例えば、 ピクチ ャをフレームとして表示する、 あるいは、 ピクチャのトップフィール ドを表示して、 その後、 ボトムフィールドを表示する、 などといった 情報である。
au— ref— flagは、 対応するアクセスユニットが、 他のアクセスュニ ット （のピクチャ） のデコードにあたって参照される参照画像である か否かを表し、 参照画像である場合には 1とされ、 参照画像でない場 合には 0とされる。
AU— lengthは、 対応するアクセスュニットのサイズをバイト単位で 表す。
[ディスク 1 0 1に記録されたデータの具体例]
次に、 第 2 5図乃至第 2 8図は、 第 1図のディスク 1 0 1に記録さ れた、 上述したようなフォーマツトのデ一夕の具体例を示している。
ここで、 第 2 5図乃至第 2 8図では、 ビデオストリームとしては、 MPEG2- Videoを採用し、 オーディオストリームとしては、 ATRACオーデ ィォストリ一ムを採用している。 但し、 ビデオストリームやオーディ ォストリームは、 これに限定されるものではない。 即ち、 ビデオスト リームとしては、 例えば、 MPEG4- Visualや 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図に示し たように、 "CLIP"ディレクトリに、 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図乃至第 2 8図では、 "PLAYLIST.DAT"ファイル等のデータの一部を 省略してある。
即ち、 第 2 5図は、 第 5図で説明した" PLAYLIST.DAT"ファイルの具 体例を示している。
第 2 5図では、 number一 0し PlayListsは 2となっており、 従って、 "P LAYLIST.DAT"ファイルに含まれる PlayListOの数は 2である。 第 2 5 図では、 その 2つの PlayListOのうちの 1番目が PlayList #0と、 2 番目が PlayList #1と、 それぞれ記載されている。
1番目の PlayList 0である PlayList #0については、 capture— enabl e_flag— PlayListが 1となっており、 従って、 PlayList #0にしたがつ て再生されるビデオデータの 2次利用が許可されている。 また、 Play List #0については、 number_oし ayltemsが 2となっており、 従って 、 PlayList #0に含まれる P yltemOの数は 2である。 第 2 5図では、 その 2つの PlayltemOである PlayItem#0と Playltem#lの具体例が、 「 PlayListtOj の欄の下方に記載されている。
PlayList #0に含まれる 1番目の Play Item 0である Play It em#0では 、 第 6図で説明した Clip— Information— file— nameが" 00001. CLP"に、 I n— timeが 180， 090に、 0UT_t imeが 27， 180， 090に、 それぞれなっている 。 従って、 PlayList #0の Playl tem#0によって再生されるクリップは 、 クリップ情報ファイル" 00001.CLP"に対応するクリップストリ一ム ファイル" 00001.PS"の、 時刻 180， 090から 27, 180， 090までである。
PlayList #0に含まれる 2番目の Play Item 0である Play It em#lでは 、 第 6図で説明した Clip— Information_file_nameが" 00002. CLP"に、 I n_timeが 90, 000に、 OUT— Umeが 27, 090， 000に、 それぞれなっている。 従って、 PlayList #0の P yl temiflによって再生されるクリップは、 クリップ情報ファィル" 00002. CLP"に対応するクリッブストリ一ムフ アイル" 00002.PS"の、 時刻 90， 000から 27, 090， 000までである。
一方、 第 2 5図において、 2番目の PlayListOである PlayList #1 については、 capture— enable— flag— P yListが 0となっており、 従つ て、 P yList #1にしたがって再生されるビデオデータの 2次利用が 許可されていない （禁止されている） 。 また、 PlayList #1について は、 number— of— Playltemsが 1となっており、 従って、 PlayList #1に 含まれる PlayltemOの数は 1である。 第 2 5図では、 その 1つの Play ItemOである PlayItem#0の具体例が、 「PlayList#l」 の欄の下方に記 載されている。
PlayList #1に含まれる 1つの Playl temOである PlayItem#0では、 第 6図で説明した Clip_Informat ion— file— nameが" 00003. CLP"に、 In— timeが 90, 000に、 OUT— t imeが 81， 090, 000に、 それぞれなっている。 従 つて、 PlayList #1の Playl tem#0によって再生されるクリップは、 ク リップ情報ファィル" 00003. CLP"に対応するクリッブストリームファ ィル" 00003.PS"の、 時刻 90， 000から 81, 090， 000までである。
次に、 第 2 6図 Aおよび第 2 6図 Bは、 第 1 0図で説明したクリッ プ情報ファイル ClipOの具体例を示している。 即ち、 第 2 6図 Aおよ び第 2 6図 Bは、 第 4図のクリップ情報ファイル" 00001. CLP"， " 0000 2. CLP" , " 00003. CLP"の具体例を示している。
クリップ情報ファイル" 00001. CLP"においては、 presentation— star t— timeが 90， 000に、 presentation— end— t imeが 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_of— streamsは 4となっており、 従って、 対 応するクリップストリームファイル" 00001.PS"に格納されたプロダラ ムストリ一ムには、 4本のエレメン夕リストリームが多重化されてい る。
いま、 その 4本のエレメン夕リストリームを、 stream#0， stream#l ， stream#2, stream#3とすると、 第 2 6図 Aおよび第 2 6図 Bでは、 その 4本のエレメン夕リストリーム stream#0， streamtl, 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 2図） の picture_sizeが' 7 20X480'に、 frame— rateが' 29.97Hz'に、 cc— Π agが' Yes'に、 それぞ れなっている。 従って、 このビデオストリーム stream#0は、 720 X480 ピクセルの、 フレーム周期が 29.97Hzのビデオデータであり、 さらに 、 クローズドキャプションデータを含んでいる。
さらに、 クリップストリームファイル" 00001.PS"の 1本目のエレメ ン夕リストリ一ムであるビデオストリーム stream#0については、 Stre amlnfoO (第 1 0図） の number— of— Dynamiclnfoが 0になっており、 p ts— change一 pointと Dynamiclnfo 0とのセッ卜は？子&しない。
次に、 クリップストリームファイル" 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力 日本語' ίこ、 channel— configurat ion STEREO'【こ、 1 fe_existence^' υ 【こ、 sampl ing— frequency力 ' 48kHz'【こ、 それぞれ なっている。 従って、 この ATRACオーディオストリーム stream は、 日本語で、 かつステレオのオーディオデータである。 また、 低域強調 チャネルは含まれておらず、 サンプリング周波数は、 48kHzである。 さらに、 クリップストリームファイル" 00001.PS"の 2本目のエレメ ン夕リストリ一ムである ATRACオーディオストリーム stream につい ては、 StreamlnfoO (第 1 0図） の number— oし Dynamiclnfoが 0にな つており、 pts_change— pointと DynamicInfoOとのセットは存在しな い。
次に、 クリップストリームファイル" 00001.PS"の 3本目のエレメン 夕リストリ一ム stream#2については、 s tream_idが OxBDとなっており 、 private— stream—idが 0x80となっている。 従って、 このエレメンタ リストリーム stream#2は、 第 2 0図および第 2 2図で説明したように 、 字幕ストリームである。
また、 クリップストリームファイル" 00001.PS"の 3本目のエレメン 夕リストリ一ムである字幕ストリーム stream#2については、 その Stre amlnfoOに含まれる StaticInfoO (第 1 2図） の subt i tie— language— codeが'日本語'に、 configurable— flagが 0に、 それぞれなっている 。 従って、 この字幕ストリーム stream#2は、 日本語の字幕データであ り、 また、 その表示方式を変更することは許可されていない （禁止さ れている） 。
さらに、 クリップストリームファイル" 00001.PS"の 3本目のエレメ ン夕リストリームである字幕ストリーム stream#2については、 Stream InfoO (第 1 0図） の number— of Dynamiclnfoが 0になっており、 pts —change— pointと Dynamic Info 0とのセッ卜 ま存在しない。
次に、 クリップストリ一ムファイル" 00001.PS"の 4本目のエレメン 夕リストリーム stream#3については、 stream— idが OxBDとなっており 、 private_stream— idが 0x81となっている。 従って、 このエレメン夕 リストリ一ム stream#3は、 第 2 0図および第 2 2図で説明したように 、 字幕ストリームである。
なお、 クリップストリームファイル" 00001.PS"の 3本目のエレメン 夕リストリ一ムである字幕ストリ一ム stream#2と、 4本目のエレメン 夕リストリームである字幕ストリーム stream#3とを区別するために、 それぞれの private— stream一 idは、 0x80と 0x81とになっている。
また、 クリップストリ一ムファイル" 00001.PS"の 4本目のエレメン 夕リストリームである字幕ストリーム stream#2については、 その Stre amlnfoOに含まれる StaticInfoO (第 1 2図） の sub t i tie— language— codeが'日本語'に、 configurable—Hagが 1に、 それぞれなっている 。 従って、 この字幕ズトリーム stream#3は、 日本語の字幕データであ り、 また、 その表示方式を変更することが許可されている。
さらに、 クリップストリームファイル" 00001.PS"の 4本目のエレメ ンタリストリームである字幕ストリ一ム stream#3については、 Stream InfoO (第 1 0図） の number— 0し Dynamiclnfoが 0になっており、 pts _change— pointと Dynamiclnfo 0とのセットは存在しない。
次に、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報フアイ ル" 00002. CLP"については、 presentation— start— timeが 90, 000に、 r esen tion_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および第 26図 Bにおいて、 クリップ情報ファ ィル" 00002. CLP"の number— 0し streamsは 4となっており、 従って、 対 応するクリップストリームファイル" 00002.PS"に格納されたプロダラ ムストリ一ムには、 上述したクリッブストリームファイル" 00001.PS" における場合と同様に、 4本のエレメンタリストリームが多重化され ている。
いま、 その 4本のエレメンタリストリ一ムを、 stream#0, streamttl , stream#2, stream#3とすると、 第 2 6図 Aおよび第 2 6図 Bでは、 その 4本のエレメンタリストリ一ム stream#0， streamtl, stream#2, stream#3それぞれの StreamlnfoO (第 1 0図） の具体例が、 「" 00002 .CLP"」 の欄の下方に記載されている。
ここで、 第 2 6図 Aおよび第 26図 Bでは、 クリップストリームフ アイル" 00002.PS"の 1乃至 4本目のエレメンタリストリーム streani#0 乃至 #3それぞれの StreamlnfoOの内容は、 上述したクリップストリー ムファイル" 00001.PS"の 1乃至 4本目のエレメンタリストリーム st re 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本目のエレメン夕リストリ一ム streamsはビデオストリームで あり、 2本目のエレメン夕リストリーム stream#lは ATRACオーディオ ストリームである。 また、 その 3本目のエレメンタリストリ一ム stre am#2と、 4本目のエレメンタリストリ一ム stream#3は、 いずれも字幕 ストリームである。
次に、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報フアイ ル" 00003. CLP"については、 presentation— starし timeが 90, 000に、 r esentation_end— timeが 81, 090， 000に、 それぞれなっている。 従って 、 クリツプ情報ファィル" 00003. CLP"に対応するクリップストリーム ファイル" 00003.PS"に格納されたプログラムストリームによれば、 90 0秒分 （（81， 090， 000-90， 000)/90kHz) のコンテンツが利用可能である 。
また、 クリップ情報ファイル" 00003. CLP"においては、 capture— ena ble— Hag一 Clipが 1になっており、 従って、 クリップ情報ファイル" 00 003. CLP"に対応するクリップストリームファイル" 00003.PS"に格納さ れたプログラムストリームに多重化されたビデオストリームについて は、 その 2次利用が許可されている。
さらに、 第 2 6図 Aおよび第 2 6図 Bにおいて、 クリップ情報ファ ィル" 00003· CLP"の number— of— streamsは 3となっており、 従って、 対 応するクリップストリームファイル" 00003.PS"に格納されたプロダラ ムストリームには、 3本のエレメンタリストリームが多重化されてい る。
いま、 その 3本のエレメンタリストリ一ムを、 stream#0, streamtl ， stream#2とすると、 第 2 6図 Aおよび第 2 6図 Bでは、 その 3本の エレメンタリストリーム stream#0， stream#l, stream#2それぞれの St reamlnfoO (第 1 0図） の具体例が、 「" 00003. CLP"」 の欄の下方に 記載されている。
クリツプストリームファイル" 00003.PS"の 1本目のエレメンタリス トリ一ム stream#0については、 stream— idが OxEOとなっており、 従つ て、 このエレメン夕リストリーム s eam#0は、 第 2 0図および第 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 20 X480'に、 frame— rateが' 29.97Hz'に、 cc— flagが' No'に、 それぞれ なっている。 従って、 このビデオストリーム stream#0は、 720 X480ピ クセルの、 フレーム周期が 29.97Hzのビデオデータであり、 さらに、 クローズドキヤプションデータを含んでいない。
さらに、 クリップストリームファイル" 00003.PS"の 1本目のエレメ ンタリストリームであるビデオストリーム stream#0については、 Stre amlnfoO (第 1 0図） の number_of— Dynamiclnfoが 2になっており、 つて、 その Streamlnfo 0にま、 pts— change— pointと Dynamiclnfo 0 とのセットが 2セット記述されている。
次に、 クリップストリームファイル" 00003.PS"の 2本目のエレメン 夕リス卜リーム stream#lについては、 s t ream— 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本目のエレメンタリ ストリーム stream#0と同様に、 private— s treamjdは、 0x00になって いる。
また、 クリップストリームファイル" 00003.PS"の 2本目のエレメン タリストリームであるビデオストリーム stream#lについては、 その St reamlnfoOに含まれる StaticInfoO (第 1 2図） の picture— size, fr ame_rate, cc— flagが、 1本目のエレメン夕リストリームであるビデ ォストリーム stream#0についてのものと同一になっている。 従って、 クリップストリームファイル" 00003.PS"の 2本目のエレメン夕リスト リームであるビデオストリーム streamttlは、 720 X 480ピクセルの、 フ レーム周期が 29.97Hzのビデオデ一夕であり、 さらに、 クローズドキ ャプションデータを含んでいない。
さらに、 クリップストリームファイル" 00003.PS"の 2本目のエレメ ン夕リストリームであるビデオストリ一ム stream#lについては、 Stre amlnfoO (第 1 0図） の number_of— Dynamiclnfoが 0になっており、 p ts— change— pointと Dynamic Info 0とのセッ卜は存在しない。
次に、 クリップストリ一ムファイル" 00003.PS"の 3本目のエレメン 夕リストリーム stream については、 stream_idが OxBDとなっており 、 private— stream— idが 0x00となっている。 従って、 このエレメン夕 リストリーム stream#2は、 第 2 0図および第 2 2図で説明したように 、 ATRACオーディオストリームである。 また、 クリップストリームファイル" 00003.PS"の 3本目のエレメン タリストリームである ATRACオーディォストリーム stream#2について は、 その StreamlnfoOに含まれる S ticInfoO (第 1 2図） の audio— language一 code, channel_conf igurat ion, 1 f e_exi s tence, sampling— frequencyが、 クリップストリームブアイル' ' 00001. PS"の 2本目のェ レメン夕リストリームである ATRACオーディォストリーム stream#lの ものと同一になっている。 従って、 クリップストリームファイル" 000 03.PS"の 3本目のエレメン夕リストリームである ATRACオーディォス トリーム stream^は、 日本語で、 かつステレオのオーディオデータで ある。 また、 低域強調チャネルは含まれておらず、 サンプリング周波 数は、 48kHzである。
さらに、 クリップストリームファイル" 00003.PS"の 3本目のエレメ ンタリストリ一ムである ATRACォ一ディォストリ一ム stream^につい ては、 StreamlnfoO (第 1 0図) の number— of— Dynamiclnfoが 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 0の number— 0し st ream— id— entriesは 1に なっており、 従って、 この EPjnapOには、 1つのエレメンタリストリ —ムについてのデコード開始可能点の情報が記述されている。
また、 第 2 7図の EP— map ()では、 s t ream— i dが OxEOになっている。 従って、 第 2 0図および第 2 2図で説明したことから、 EPjnapOには 、 OxEOとなっている stream idによって特定されるビデオストリーム についてのデコード開始可能点の情報 （PTS一 EP— 31 と1?18?—31&1^ (第 1 4図） ） が記述されている。 即ち、 第 2 7図は、 クリップ情報 ファイル" 00001.CLP"の EP— map()であり、 クリップ情報ファイル" 0000 1.CLP"に対応するクリップストリームファイル" 00001. CLP"において 、 s eam_idが OxEOのエレメンタリストリームは、 第 2 6図 Aおよび 第 2 6図 Bで説明したように、 クリップストリ一ムファイル" 00001. C LP"の 1本目のビデオストリーム stream#0であるから、 第 2 7図の EP— map()に記述されている情報は、 そのビデオストリ一ム stream#0のデ コ一ド開始可能点の PTS— EP_startと RPN— EP_startである。
第 2 7図では、 クリップストリームファイル" 00001. CLP"の 1本目 のビデオストリーム stream#0のデコード開始可能点のうちの、 先頭か ら 5点の？13ー —3 ]^と1^ 6?—31&1^が記載されてぉり、 6点目以降 の PTS— EP_s t ar tと RPN_EP— s t ar tの記載は省略してある。
なお、 第 2 7図の EP— map 0において、 private— stream— idは 0x00に なっているが、 stream— idがビデオストリームを表している場合は、 上述したように、 private—stream— idは無関係である （無視される） 次に、 第 2 8図は、 第 2 5図で説明した PlayList #0と PlayList #1 (第 5図の PlayList 0) の中の PlayListMarkOの具体例を示している 。
第 2 8図上側は、 PlayList #0の PlayListMarkO (第 7図） を示し ている。
第 2 8図上側において、 PlayList #0の PlayListMarkOにおける num ber— of— PlayList— marksは 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 Item— id (第 7図） が 0になっているので、 PlayList #0に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 PlayItem#0 に属する。 また、 Mark#0は、 mark_time— stampが 180， 090になっている ので、 PlayList #0に含まれる Playl tem#0によって再生されるクリツ プストリームファイルの時刻 （再生時刻） 180， 090上の印である。 さ らに、 MarkJOは、 entry— ES一 stream— idおよび entry— ES— private— strea m_idがいずれも 0になっているので、 いずれのエレメン夕リストリ一 ムにも関連付けられていない。 また、 Mar Oは、 mark— dataが 1になつ ているので、 番号が 1のチヤプタを表す。
なお、 ここでは、 PlayList #0に含まれる PlayItem#0によって再生 されるクリップストリームファイルは、 第 2 5図で説明した、 その P1 ayltem#0の Clip— Infomat ion— file— nameに記述されている" 00001 · CLP" から特定されるクリップストリームファイル" 00001. PS"であり、 従つ て、 Mark#0の mark— time_stampが表す、 上述した時刻 180, 090は、 クリ ップストリームファイル" 00001.PS"の時刻である。
第 2 8図上側において、 PlayList #0に含まれる 7つの MarkOのう ちの 5番目の MarkOである Mark#4も、 1番目の Mark#0と同様のチヤプ 夕マークである。
即ち、 5番目の MarkOである Mark#4は、 markjype (第 7図） が' Ch apter'になっているので、 チヤプ夕マークである。 さらに、 Mark#4は 、 reし to_P lay It em— id (第 7図） が 1になっているので、 PlayList #0 に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 Playltem#lに 属する。 また、 Mark#4は、 mark— t irae— s t a即が 90， 000になっているの で、 PlayList #0に含まれる Playl tem#lによって再生されるクリップ ストリームファイルの時刻 90， 000上の印である。 さらに、 Mark#4は、 entry— ES— stream— idおよび en try_ES— private— st ream一 idがいずれも 0 になっているので、 いずれのエレメンタリストリ一ムにも関連付けら れていない。 また、 Mark#4は、 mark— dataが 2になっているので、 番号 が 2のチヤプタを表す。
なお、 ここでは、 PlayList #0に含まれる Playltem#lによって再生 されるクリップストリームファイルは、 第 2 5図で説明した、 その P1 ayltem#lの Clip—Infomat ion— f i le— nameに記述されている" 00002. CLP" から特定されるクリップストリームファイル" 00002.PS"であり、 従つ て、 Mark#4の mark— time一 stampが表す、 上述した時刻 90， 000は、 クリ ップストリームファイル" 00002.PS"の時刻である。
また、 第 2 8図上側において、 P yList #0に含まれる 7つの Mark ( )のうちの 2番目の MarkOである Mark#lは、 mark— type (第 7図） が' I ndex'になっているので、 インデクスマ一クである。 さらに、 Mark#l は、 ref— to— Playltem_id (第 7図） が 0になっているので、 PlayList #0に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 PlayItem#0 に属する。 また、 Mark#lは、 mark_time— stampが 5， 580, 090になってい るので、 PlayList #0に含まれる Playl tem#0によって再生されるクリ ップストリームファイルの時刻 5, 580,090上の印である。 さらに、 Mar k#lは、 entry— ES— stream— idおよび entry—ES— private— stream— idがい ずれも 0になっているので、 いずれのエレメンタリストリ一ムにも関 連付けられていない。 また、 Mark#lは、 mark— dataが 1になっているの で、 番号が 1のインデクスを表す。
なお、 ここでは、 PlayList #0に含まれる PlayltemltOによって再生 されるクリップストリ一ムファイルは、 上述したように、 クリップス トリームファイル" 00001.PS"であり、 従って、 Mark#lの mark time st a即が表す、 上述した時刻 5, 580, 090は、 クリップストリームファイル
" 00001.PS"の時刻である。
第 2 8図上側において、 PlayList #0に含まれる 7つの MarkOのう ちの 3番目、 6番目、 7番目の MarkOである Mark#2, Markft5, 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になっているので、 P yList #0 に含まれる第 2 5図の 2つの PlayItem#0と #1のうちの、 ayltem#0に 属する。 また、 Mark#3は、 mark— time— stampが 16， 380， 090になってい るので、 PlayList #0に含まれる PI ayl t em#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に含まれる PI ayl tem#0によって再生 されるクリップストリームファイルは、 上述したように、 クリップス トリ一ムファイル" 00001.PS"であり、 従って、 Mark#3の mark— time— st ampが表す、 上述した時刻 16， 380, 090は、 クリップストリームフアイ ル" 00001.PS"の時刻である。
ここで、 第 2 8図上側では、 PlayList #0の PlayListMarkOの一覧 表の欄外の右側に、 Mark 0が属する Play Item ()の先頭からの時間を示 してあり、 さらにその右側に、 PlayList #0の先頭からの時刻を示し てある。 次に、 第 2 8図下側は、 PlayList#lの P yListMarkO (第 7図） を 示している。
第 2 8図下側において、 PlayList#lの PlayListMarkOにおける numb er— 0し PlayListjnarksは 3になっており、 従って、 PlayList#l (の Pla yListMarkO) に含まれる MarkOの数は 3である。
また、 第 2 8図下側において、 PlayList#lに含まれる 3つの MarkO のうちの 1番目の MarkOである MarkJOは、 markjype (第 7図） が' Ch apter'になっているので、 チヤプ夕マークである。 さらに、 Mark#0は 、 reし to— Play It em— id (第 7図） が 0になっているので、 PlayList#l に含まれる第 2 5図の 1つの PlayItem#0に属する。 また、 Mark#0は、 mark— time— st ampが 90， 000になっているので、 PlayList#lに含まれる P yltem#0によって再生されるクリップストリームファイルの時刻 90， 000上の印である。 さらに、 Mark#0は、 entry— ES— stream— idおよび ent ry_ES_private—stream_idがいずれも 0になっているので、 いずれのェ レメンタリストリ一ムにも関連付けられていない。 また、 Mark#0は、 mark_dataが 0になっているので、 番号が 0のチヤプ夕を表す。
なお、 ここでは、 PlayList#lに含まれる PlayItem#0によって再生さ れるクリップストリームファイルは、 第 2 5図で説明した、 その Play ltem#0の Clip— Infomat ion— file— nameに記述されている" 00003. CLP"か ら特定されるクリップストリームファイル" 00003. PS"であり、 従って 、 Mark#0の mark— time_stampが表す、 上述した時刻 90, 000は、 クリツ プストリームファイル" 00003.PS"の時刻である。
第 2 8図下側において、 PlayList#lに含まれる 3つの MarkOのうち の 2番目の MarkOである Mark#lは、 mark— type (第 7図） が' Event'に なっているので、 イベントマークである。 さらに、 Mark#lは、 ref— to Playltem id (第 7図） が 0になっているので、 PlayList#lに含まれ る第 2 5図の 1つの PlayItem#0に属する。 また、 Mark#lは、 mark— tim e— s 即が 27, 090， 000になっているので、 1>1& 1^31#1に含まれる1>1& 1 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図で説明したように、 ビデオストリームに関連付けられて いる。 また、 Markiilは、 mark— dataが 1になっているので、 引数として 1を伴うイベントを発生させる。
なお、 ここでは、 PlayList#lに含まれる PlayItem#0によって再生さ れるクリップストリームファイルは、 上述したように、 クリップスト リームファイル" 00003.PS"であり、 従って、 Mark#lの mark— time— stam Pが表す、 上述した時刻 27, 090， 000は、 クリップストリームファイル" 00003.PS"の時刻である。
また、 MarkJlが関連付けられている、 s tream— idが OxEOのビデオス トリームは、 その Mark#lが属する、 第 2 5図の PlayList#lに含まれる PlayItem#0の Clip— Infoma t ion— file— nameに記述されている" 00003. CL P"に記述されている stream— idが OxEOのどデォストリーム、 即ち、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00003. CLP"から 特定される、 クリップストリームファイル" 00003.PS"に多重化されて いる 3本のエレメンタリストリーム stream#0乃至 #2のうちの、 1本目 のエレメンタリストリーム （ビデオストリーム） stream#0である。 次に、 第 2 8図下側において、 PlayList#lに含まれる 3つの MarkO のうちの 3番目の MarkOである Mark#2は、 mark— type (第 7図） が 'Ev ent'になっているので、 イベントマークである。 さらに、 Mark#2は、 ref_to Playltem_id (第 7図） が 0になっているので、 P yList#lに 含まれる第 2 5図の 1つの ayltem#0に属する。 また、 Mark#lは、 ma rk— time— stampが 27, 540, 000になっているので、 PlayLis t#lに含まれ る PlayItem#0によって再生されるクリッブストリ一ムファイルの時刻 27， 540, 000上の印である。 さらに、 Mark#2は、 entry— ES— stream— idが OxElで、 entry— ES— private— stream_idが 0になっているので、 stream— idが OxElで特定 （識別） されるエレメンタリストリーム、 即ち、 第 2 0図および第 2 2図で説明したように、 ビデオストリームに関連付け られている。 また、 Mark#2は、 mark— dataが 2になっているので、 引数 として 2を伴うイベントを発生させる。
なお、 ここでは、 PlayList#lに含まれる PlayItem#0によって再生さ れるクリップストリームファイルは、 上述したように、 クリップスト リームファイル" 00003.PS"であり、 従って、 Mark#2が表す、 上述した 時刻 27， 540, 000は、 クリップストリームファイル" 00003.PS"の時刻で ある。
また、 Mark#2が関連付けられている、 stream— idが OxElのビデオス トリームは、 その Mark#2が属する、 第 2 5図の PlayList#lに含まれる PlayItem#0の Clip— Infomat ion— fi le— nameに記述されている" 00003. CL P"に記述されている stream— idが OxElのビデオストリーム、 即ち、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00003. CLP"から 認識される、 クリップストリームファイル" 00003.PS"に多重化されて いる 3本のエレメンタリストリーム stream#0乃至 #2のうちの、 2本目 のエレメンタリストリーム （ビデオストリーム） s eam#lである。 ここで、 第 2 8図下側では、 PlayList#lの PlayListMarkOの一覧表 の欄外の右側に、 Mark 0が属する ay Item ()の先頭からの時刻を示し てある。
なお、 第 2 8図においては、 チヤプ夕マークやインデクスマークが 表すチヤプタゃィンデクスの番号が、 mark— dat aに記述されているが 、 チヤプ夕マ一クゃィンデクスマ一クが表すチヤプ夕ゃィンデクスの 番号は、 mark_da t aに記述しなくても、 例えば、 P l ayL i s tMark Oにお けるチヤプ夕マ一クゃィンデクスマークの数をカウン卜することによ つて認識することができる。
[ディスク装置の動作説明]
次に、 第 1図のディスク 1 0 1に、 第 2 5図乃至第 2 8図で説明し たようなデータ （ファイル） が記録されているとして、 第 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"フ アイルと、 "PLAYLIST.DAT"ファイルとの 2つのデ一夕ファイルを要求 して読み込み、 ステップ S 1 04に進む。 ステップ S 1 04では、 "S CRIPT.MT"ファイルが、 スクリプト制御モジュール 2 1 1に供給され るとともに、 "PLAYLIST.DAT"ファイルが、 プレイヤ制御モジュール 2 1 2に供給される。
その後、 ステップ S 1 04から 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 LAYL I ST. DAT"ファイルにおいて number— o f_P yL i s t sが 2になっている ことから、 1番目の PlayList#0と 2番目の P yList#lとの 2つの Play List ()が存在することを認識する。 さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 5図の" PLAYLIST.DAT"ファイルにおける 1番目の Play List#0について、 number_of— Playltemsが 2となっていることから、 そ の？1& 51#0には、 1番目の PlayItem#0と 2番目の PI ayl t em#lとの 2 つの PlayltemOが存在することを認識する。 そして、 プレイヤ制御モ ジュール 2 1 2は、 第 2 5図の" PLAYLIST.DAT"ファイルにおける、 P1 ayList#0に含まれる 1番目の PlayItem#0と 2番目の Playl tem#lそれぞ れの CI ip_Inforination_n le— nameを参照することにより、 PIayList#0 に含まれる 1番目の PlayItem#0のクリップ情報ファイル （のファイル 名） が" 00001. CLP"であり、 2番目の Playltem#lのクリップ情報ファ ィルが" 00002. CLP"であることを認識する。
プレイヤ制御モジュール 2 1 2は、 2番目の PlayListiHについても 同様にして、 その number— ofJ ayltemsが 1であることから、 1つの P1 ayltemO (PlayltemfO) が存在し、 さらに、 その PiayItem#0の中の C1 ip— Information— fi le— name力、ら、 その PI ayl tem#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の PUyltemのクリップ情報ファイルだ けで十分であるが、 本実施の形態では、 上述したように、 すべての N ayList 0の PlayltemOのクリップ情報ファイルを先読みしておくこと とする。
ステップ S 1 06の処理後は、 ステップ 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 0 2に進み、 上述したエラ一処理 が行われ、 再生前処理を終了する。
一方、 ステップ S 1 0 7において、 ステップ S 1 0 5で認識したク リップ情報ファイルの読み込みに成功し、 かつ、 クリップ情報フアイ ルに対応するクリップストリームファイルが、 ディスク 1 0 1に存在 すると判定された場合、 プレイヤ制御モジュール 2 1 2は、 初期化処 理を終了し、 ステップ S 1 0 8に進む。
ステップ S 1 0 8では、 スクリプト制御モジュール 2 1 1が、 "SCR LPT. DAT"ファイルの解釈と実行を開始する。
例えば、 いま、 スクリプト制御モジュール 2 1 1が、 "SCRIPT.DAT" ファイルを実行することにより、 1番目の PlayList 0 (PlayListttO) の再生が、 プレイヤ制御モジュール 2 1 2に指示されたとすると、 第 3 0図の再生処理が行われる。
「再生処理」
即ち、 第 3 0図は、 ビデオコンテンツ再生プログラム 2 1 0が行う 再生処理を説明するフローチャートである。
「再生準備処理」
再生処理では、 プレイヤ制御モジュール 2 1 2は、 まずステップ S 1 2 1と S 1 2 2において、 スクリブト制御モジュール 2 1 1力 ら再 生を指示された PlayListO、 即ち、 1番目の PlayList 0 (PlayList#0 ) の再生準備処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 ステップ S 1 2 1におい て、 1番目の PlayListitOに含まれる 1番目の PlayltemifOの IN— time ( 第 6図） を確認して、 ステップ S 1 22に進み、 1番目の PlayList#0 に含まれる 1番目の PlayItem#0によって再生されるクリップストリ一 ムファイル" 00001.PS"上の、 その？1& ^6111#0の11 1116に相当する、 再生を開始する再生開始位置を調査する。
ここで、 ？13 ^6111()の11^1116 (第 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番目の PI ayl tem #0によって再生されるクリップストリ一ムファイル" 00001. CLP"の、 第 2 7図に示した EP— map()から、 Playl tem#0の IN— timeである 180， 090 に適した再生開始位置を探し出す。
即ち、 プレイヤ制御モジュール 2 1 2は、 例えば、 EP— map()に記述 されたデコード開始可能点を表す PTS EP startのうちの、 式 PTS— EP_s tart≤IN— timeを満たす最大の PTS— EP— startを、 二分探索 （バイナリ サーチ） 等を用いて検索する。 ここで、 IN— time以下の PTS— EP_start を検索するのは、 IN— timeによって表される位置が、 デコード開始可 能点であるとは限らないからである。
いまの場合、 IN— timeは、 上述したように、 180,090である。 また、 1番目の NayList#0に含まれる 1番目の PlayItem#0によって再生され るクリツプストリ一ムファイル" 00001. CLP"の、 第 2 7図に示した EP一 iap()においては、 式 PTS_EP— start^IN— timeを満たす最大の PTS— EP— s tartとして、 180， 090が記述されている。 従って、 プレイヤ制御モジ ユール 2 1 2では、 第 2 7図に示した EP— map()から、 その 180,090と なっている PTS— EP— s tar tが検索される。
さらに、 プレイヤ制御モジュール 2 1 2では、 その検索された PTS— 6?—31& に対応する!0)181)—3{& でぁる305 (セクタ） が読み出され 、 その 305である RPN_EP—startによって表されるクリップストリ一ム ファイル" 00001.PS"上の位置が、 再生開始位置として決定される。 プレイヤ制御モジュール 2 1 2は、 以上のようにして再生開始位置 を決定すると、 ステップ S 1 2 2から S 1 2 3に進み、 タイムコード を表示するように、 グラフィクス処理モジュール 2 1 9を制御する。 グラフィクス処理モジュール 2 1 9は、 プレイヤ制御モジュール 2 1 2の制御にしたがい、 タイムコード （のビデオデータ） を生成してビ デォ出力モジュール 2 2 0に出力する。 これにより、 タイムコードの 表示が開始される。
ここで、 ステップ S 1 2 3で表示が開始されるタイムコードは、 例 えば、 PlayListOの先頭を 00:00:00 (時間：分：秒） に換算した値とす る。 なお、 タイムコードとともに、 またはタイムコードではなく、 チ ャプ夕ゃィンデクスの番号を表示するようにしても良い。 rpiayl istMarkOの解析処理」
ステップ S 1 2 3でタイムコードの表示が開始された後は、 ステツ プ S 1 24に進み、 プレイヤ制御モジュール 2 1 2は、 スクリプト制 御モジュール 2 1 1から再生を指示された PlayList()、 即ち、 1番目 ©PlayList 0 (PlayList#0) に記述されている PlayListMarkO (第 7 図） を解析する解析処理を行う。
具体的には、 プレイヤ制御モジュール 2 1 2は、 既に読み込んであ る" PLAYLIST.DAT"ファイルにおける 1番目の PlayList#0の、 第 2 8図 上側に示した P 1 ayL i s tMark 0において、 number_o f_P l yLis t_marksが 7になっていることから、 その PlayList#0に含まれる MarkOの数が 7 であることを認識する。
さらに、 プレイヤ制御モジュール 2 1 2は、 PlayListlfOに含まれる 、 第 2 8図上側の 7つの MarkOを解析し、 その reし to—Pl ayl tem_idか ら、 7つの MarkOのうちの 1番目から 4番目までの 4つの MarkOが、 PlayList#0の 1番目の PlayltemO (PlayItem#0) に属していることを 認識する。
その後、 プレイヤ制御モジュール 2 1 2は、 PlayList#0の 1番目の P yItem#0に属している 4つの MarkOの mark— t ime— stampを取り出し 、 要素数が 4の配列として、 デコード制御モジュール 2 1 4に渡す。 即ち、 これにより、 第 2 8図上側の 7つの MarkOのうちの 1番目から 4番目までの 4つの MarkOそれぞれの mark— time_st ampである {180， 09 0}、 {5, 580,090}, {10,980,090}, {16, 380， 090}の 4つの時刻が、 プレイヤ制御モジュール 2 12から、 デコード制御モジュール 2 1 4 に渡される。 このときこれら時刻の属性は 「マーク処理」 であること も、 プレイヤ制御モジュール 2 1 2から、 デコード制御モジュール 2 14に伝えられる。 デコード制御モジュール 2 1 4は、 計時部 2 14 Aで計時している時刻が、 「マーク処理」 の属性の時刻に一致したと き、 その旨を示すメッセージ、 「マーク処理」 の属性の時刻に一致し た時刻、 および 「マーク処理」 の属性を、 プレイヤ制御モジュール 2 1 2に伝える。
「再生するエレメン夕リストリームの決定処理」
次に、 ステップ S 1 24から S 1 2 5に進み、 プレイヤ制御モジュ ール 2 1 2は、 再生するエレメン夕リストリームを決定する。
即ち、 プレイヤ制御モジュール 2 1 2は、 スクリプト制御モジユー ル 2 1 1から再生を指示された PI ayLis t0である 1番目の PlayList#0 における 1番目の P yItem#0 (第 2 5図） の CI ip— Information— f ime— nameにファイル名が記述されている、 第 26図 Aおよび第 26図 Bの クリップ情報ファイル" 00001. CLP"において、 number— of_st reamsが 4 になっていることから、 対応するクリップストリームファイル" 00001 • PS"に、 4本のエレメン夕リストリームが多重化されていることを認 識する。 さらに、 プレイヤ制御モジュール 2 1 2は、 その 4本のエレ メン夕リストリームに対する、 第 2 6図 Aおよび第 2 6図 Bのクリッ プ情報ファイル" 00001. CLP"の StaticInfoOの stream— idと必要な priv ate_stream— idを順に調査し、 その 4本のエレメン夕リストリームが 、 1本のビデオストリーム、 1本の ATRACオーディオストリーム、 お よび 2本の字幕ストリームであることを認識する。 即ち、 クリップス トリームファイル" 00001.PS"に多重化されている各属性のエレメン夕 リストリームの本数が認識される。
なお、 クリッブストリームファイルに多重化されている各属性のェ レメン夕リストリームの本数の情報は、 再生中でのエレメン夕リスト リームの切り替え （オーディオ切り替え、 字幕切り替え等） に使用さ れる。 また、 字幕ストリームは、 クリップストリ一ムファイル中に存 在しない （コンテンツに字幕が含まれない） 場合があり、 字幕ス卜リ ームが存在するかどうかの判断に、 「字幕ストリーム」 の属性のエレ メン夕リストリームの本数の情報が使用される。
プレイヤ制御モジュール 2 1 2は、 以上のような S ticInfoOの調 査の結果に基づいて、 再生するエレメン夕リストリームを選択、 決定 するが、 いまの場合、 クリップストリームファイル" 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で、 それぞれ特定する。
以上のように、 クリップストリームファイルに対応するクリップ情 報ファイルのメタデータとして記述される st ream— idと private— strea m— idの組み合わせによって、 そのクリップストリームファイルに多重 化されているエレメン夕リストリームを特定することができる。 ここで、 stream— idと private— stream— idの組み合わせは、 MPEG2-Sy stemの多重化を拡張するために設けたメカニズムである。 この st ream — 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し s eamsで表すことができる数だけ記述す ることができ、 従って、 クリップストリームファイルに多重化されて いるエレメンタリストリームを、 その数によらず （但し、 number_oし streamsで表すことができる数の範囲） 、 クリップ情報ファイル Clip( )に記述されたメタデータとしての stream_idと private stream idの 組み合わせから特定することが可能となる。
なお、 本実施の形態では、 stream— idと private— stream— idの組み合 わせは、 第 1 0図のクリップ情報ファイルにおいて、 対応するクリツ プストリ一ムファイルに多重化されているエレメン夕リストリームを 特定するのに使用される他、 例えば、 第 7図の PlayListMarkOにおけ る entry_ES_s tream_id ten try_ES_pri vat e_s tream_id ( ) α"^- &と して、 MarkOを関連付けるエレメン夕リストリームの特定にも使用さ れる。 さらに、 stream_idと private— stream— idの組み合わせは、 その 他、 例えば、 第 1 4図の EP—map()において、 デコード可能開始点の情 報を記述するエレメン夕リストリームの特定にも使用される。
「出力属性の制御処理」
その後、 ステップ S 1 2 5から S 1 2 6に進み、 プレイヤ制御モジ ユール 2 1 2は、 再生対象のエレメン夕リストリーム、 即ち、 ステツ プ S 1 2 5で再生すると決定したエレメンタリストリ一ムの出力属性 の制御処理を行う。
具体的には、 プレイヤ制御モジュール 2 1 2は、 まず、 再生対象の エレメンタリストリーム、 即ち、 ステップ S 1 2 5で再生すると決定 したビデオストリ一ム、 ATRACオーディオストリーム、 字幕ストリー ムそれぞれについて、 出力属性が記述される DynamicInfoO (第 1 3 図） の数を表す number— 0し Dynamiclnfo (第 1 0図） を調査する。 ここで、 いまの場合、 再生対象のビデオストリーム、 ATRACオーデ ィォストリーム、 字幕ストリームは、 クリップストリームファイル" 0 0001. PS"に多重化されているエレメン夕リストリ一ムであり、 それら の number— 0し Dynamiclnfoは、 第 2 6図 Aおよび第 2 6図 Bの" 00001. CLP"で説明したように、 いずれも 0になっている。 このように、 再生 対象のエレメン夕リストリームのすべてについて、 number of Dynami c l n f oが 0である場合、 プレイヤ制御モジュール 2 1 2は、 再生対象の エレメンタリス卜リームの出力属性の制御処理としては、 特に処理を 行わない。
なお、 再生対象のエレメン夕リストリームについての number_o f_Dy nami c l n f oが 0でない場合に、 そのエレメン夕リストリ一ムの出力属性 の制御として行われる処理については、 後述する。
「再生開始の準備処理」
ステップ S 1 2 6の処理後は、 ステップ S 1 2 7に進み、 プレイヤ 制御モジュール 2 1 2は、 再生対象のエレメンタリストリ一ムの再生 開始の準備処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 コンテンツデータ供給モ ジュール 2 1 3に対し、 再生対象のエレメンタリストリームが多重化 されているクリップストリームファイル" 00001 . PS"のファイル名と、 ステップ S 1 2 2で決定した再生開始位置である EP—map Oに記述され た RPN_EP— s t ar 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は、 再生対象のエレメンタ リストリームを識別 （特定） するための識別情報としての stream一 id 、 さらには、 必要に応じて、 private— stream— idを、 バッファ制御モ ジュール 2 1 5に供給する。
即ち、 上述したように、 再生対象のエレメンタリストリームのうち の、 「ビデオストリーム」 の属性のビデオストリームは、 OxEOとなつ ている stream_idによって特定され、 「オーディオストリーム」 の属 性の ATRACオーディオストリームは、 OxBDとなっている stream— id、 お よび 0x00となっている private_stream_idによって特定され、 「字幕 ストリーム」 の属性の字幕ストリームは、 OxBDとなっている stream— i d、 および 0x80となっている private— stream_idによって特定される。 プレイヤ制御モジュール 2 1 2は、 これらの stream— idと private— str earn— idを、 バッファ制御モジュール 2 1 5に供給する。
バッファ制御モジュール 2 1 5 (第 3図） では、 ビデオ読み出し機 能部 2 3 3が、 プレイヤ制御モジュール 2 1 2からの、 ビデオストリ —ムについての OxEOとなっている stream— idを、 stream一 idレジスタ 2 42に記憶させる。 また、 オーディオ読み出し機能部 2 34が、 プレ ィャ制御モジュール 2 1 2からの、 OxBDとなっている stream一 idと、 0 xOOとなっている private一 stream— idを、 stream_idレジスタ 2 5 2と p rivate stream idレジス夕 2 5 3に、 それぞれ記憶させる。 さらに、 字幕読み出し機能部 2 3 5が、 プレイヤ制御モジュール 2 1 2からの 、 OxBDとなっている stream_idと、 0x80となっている private一 stream一 idを、 stream— idレジス夕 2 6 3と private— stream— idレジス夕 2 64 に、 それぞれ記憶させる。
なお、 プレイヤ制御モジュール 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図） の初期化として、 さらに、 再生対象のエレメンタリストリ ームが多重化されているクリップストリームファイルに応じた値の字 幕読み出し機能フラグを、 字幕読み出し機能フラグ記憶部 2 6 1にセ ッ卜する。
即ち、 いまの場合、 再生対象のエレメン夕リストリームが多重化さ れているクリッブストリ一ムファイル" 00001.PS"には、 字幕ストリ一 ムが含まれるため、 字幕読み出し機能部 2 3 5を機能させるために、 値が 1の字幕読み出し機能フラグが、 字幕読み出し機能フラグ記憶部 2 6 1にセッ卜される。 なお、 再生対象のエレメン夕リストリ一ムが 多重化されているクリップストリームファイルに字幕ストリームが含 まれていない場合、 字幕読み出し機能フラグ記憶部 2 6 1には、 値が 0の字幕読み出し機能フラグがセットされる。 この場合、 字幕読み出 し機能部 2 3 5は機能しない （特に処理を行わない） 。
また、 プレイヤ制御モジュール 2 1 2は、 スクリプト制御モジュ一 ル 2 1 1から再生を指示された 1番目の PlayList#0に含まれる 1番目 の PlayItem#0 (第 2 5図） の IN— timeである 180, 090と、 OUT— timeであ る 27， 180, 090とを、 デコ一ド制御モジュール 2 14に対して与える。 デコード制御モジュール 2 14では、 IN— timeは、 PI ayl t em 0によつ て再生されるクリップのデコード開始の制御に、 0UT_timeは、 そのク リップのデコード終了、 さらには、 後述する Playltem乗り換えの制御 に、 それぞれ使用される。
さらに、 プレイヤ制御モジュール 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に供 口 <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 ream一 2の PES一 packe t 0に記述された 情報 （以下、 適宜、 付加情報ともいう） である p i c— s t rucし copyや、 a u一 reし 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 14に 渡す。
また、 バッファ制御モジュール 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 29から S 1 30に進み、 そのデー 夕のデコードが開始される。
即ち、 デコード制御モジュール 2 14は、 ステップ S 1 2 7でプレ ィャ制御モジュール 2 1 2から与えられた、 PlayList#0に含まれる 1 番目の PlayItem#0の Iltimeである 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 IFO 2 2 O Aに順次記憶させ、 その FIFO 2 2 O Aに記憶された出力ビ デォデ一夕を、 あらかじめ決められた出力レートで順次出力する。 ビデオ出力モジュール 2 2 0は、 F IFO 2 2 O 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に要求した後に、 FIF0 2 2 0 Aからの出力ビデオデ一夕の出力が進み、 F IFO 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に順次記憶させ、 その F IFO 2 2 1 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に要求した後に 、 FIF02 2 1 Aからのオーディオデ一夕の出力が進み、 FIF02 2 1 A に余裕ができた時点で、 オーディオデ一夕の受け入れを、 オーディオ デコーダ制御モジュール 2 1 7に要求する。 これにより、 オーディオ デコーダ制御モジュール 2 1 7は、 停止していた処理を再開する。 以上のようにして、 ビデオ出力モジュール 2 2 0およびオーディオ 出力モジュール 22 1からデータが出力されるにつれて、 エレメンタ リストリームのデコードが行われていく。
第 1図のディスク装置がディスク 1 0 1を再生するときの全体の処 理または動作の流れは、 第 2 9図および第 3 0図で説明したとおりで あるが、 以下、 ディスク装置においてディスク 1 0 1の再生が行われ ているときの、 その他の処理または動作について説明する。
[Playltem乗り換え]
第 2 9図および第 30図で説明したようにして、 第 2 5図における 1番目の PlayList#0の 1番目の Playltem#0の再生が始まるが、 PlayLi st#0によれば、 その 1番目の PlayltemttOの再生が終了すると、 2番目 の Playltem#lの再生が開始される。 即ち、 Playl tem#0から Playl tem#l に PI ay It emを乗り換える PI aylt em乗り換えが行われる。
そこで、 第 3 1図のフローチャートを参照して、 この; Play It em乗り 換えの処理について説明する。 第 29図および第 30図で説明したようにして、 第 2 5図における PlayList#0の 1番目の PlayltemifO (のクリップ） の再生が開始される と、 デコード制御モジュール 2 14 (第 2図 Aおよび第 2図 B) は、 その 1番目の PlayItem#0の再生が行われている間、 内蔵する計時部 2 14 Aが計時している時刻を確認し続けている。
「PlayItem#0の再生終了」
そして、 デコード制御モジュール 2 1 4は、 計時部 2 14 Aが計時 している時刻が、 第 30図のステップ 1 2 7でプレイヤ制御モジュ一 ル 2 1 2から与えられた 1番目の PlayItem#0の OUT— timeである 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 20を制御し、 現在出力中の出力ビデオデータを引き続き出力させる また、 デコード制御モジュール 2 14は、 1番目の PlayItem#0の再 生が終了した旨のメッセージを、 プレイヤ制御モジュール 2 1 2に伝 える。
「PlayItem#lの再生開始」
プレイヤ制御モジュール 2 1 2は、 上述したように、 第 29図のス テツプ S 1 0 5で、 1番目の PlayList #0に、 1番目の Playl tem#0と 2番目の Playltem#lとが存在することを認識しており、 デコード制御 モジュール 2 14から、 1番目の PlayIteni#0の再生が終了した旨のメ ッセージが伝えられると、 ステップ S 1 5 1から S 1 5 2に進み、 2 番目の Playltem#lの再生を、 上述した 1番目の P yltemifOにおける場 合と同様にして開始する。
即ち、 2番目の Playltera#lの再生手順を概説すれば、 まず、 プレイ ャ制御モジュール 2 1 2は、 第 30図のステップ S 1 2 2における場 合と同様にして、 2番目の Playltem#lについて、 EPjnap 0に記述され た1^ —8?—31&1^のぅちのぃずれかを、 再生開始位置として決定する。 さらに、 プレイヤ制御モジュール 2 1 2では、 第 30図のステップ S 1 24で説明したようにして、 2番目の Play It em#lに属する Mark 0 の認識や、 第 30図のステツプ S 1 2 5で説明したようにして、 Play Item#lによって再生されるクリッブストリームファイル" 00002. PS"に 多重化されている各属性のエレメンタリス卜リ一ムの本数の認識、 さ らには、 再生する （再生対象の） エレメン夕リストリームの決定等が 行われる。
そして、 プレイヤ制御モジュール 2 1 2は、 第 3 0図のステップ S 1 27における場合と同様の処理を行う。
即ち、 プレイヤ制御モジュール 2 1 2は、 再生開始位置として決定 した EPjnapOの RPN_EP_startと、 再生対象のエレメンタリストリーム が多重化されているクリップストリームファイルのファイル名、 即ち 、 いまの場合、 2番目の Playltem#l (第 2 5図） の CI ip— Inf ormat i on —file— 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に記憶されるデータ書き 込みポインタ、 ビデオ読み出しポインタ記憶部 24 1に記憶されるビ デォ読み出しボインタ、 オーディォ読み出しボイン夕記憶部 2 5 1に 記憶されるォ一ディォ読み出しボインタ、 字幕読み出しボインタ記憶 部 2 6 2に記憶される字幕読み出しボイン夕に、 同じ値が代入される さらに、 プレイヤ制御モジュール 2 1 2は、 再生対象のエレメン夕 リストリームを識別するための識別情報としての stream_id、 さらに は、 必要に応じて、 private_stream_idを、 バッファ制御モジュール 2 1 5に供給する。
バッファ制御モジュール 2 1 5 (第 3図） では、 ビデオ読み出し機 能部 2 3 3が、 プレイヤ制御モジュール 2 1 2からの、 再生対象のェ レメンタリストリームのうちのビデオストリ一ムについての stream_i dを、 stream— idレジスタ 242に記憶させる。 また、 オーディオ読み 出し機能部 2 34が、 プレイヤ制御モジュール 2 1 2からの、 再生対 象のエレメンタリストリ一ムのうちのオーディォストリ一ムの st ream —idと private— stream— idを、 stream— idレジス夕 2 5 2と private— str eam_idレジス夕 2 53に、 それぞれ記憶させる。
さらに、 いま再生対象となっているエレメンタリストリームが多重 化されているクリップストリームファイル" 00002.PS"には、 字幕スト リームが含まれるため、 プレイヤ制御モジュール 2 1 2から字幕読み 出し機能部 2 3 5には、 再生対象のエレメン夕リストリームのうちの 字幕ストリ一ムの stream— idと private— stream— idが供給され、 字幕読 み出し機能部 2 3 5は、 その stream— idと private— stream_idを、 stre am_idレジスタ 2 6 3と01" &16_3 6&111」[1レジスタ 2 64に、 それぞ れ記憶させる。
そして、 プレイヤ制御モジュール 2 1 2は、 バッファ制御モジュ一 ル 2 1 5 (第 3図） の初期化として、 さらに、 再生対象のエレメン夕 リストリームが多重化されているクリップストリームファイルに応じ た値の字幕読み出し機能フラグを、 字幕読み出し機能フラグ記憶部 2 6 1にセットする。
即ち、 いまの場合、 再生対象のエレメン夕リストリ一ムが多重化さ れているクリップストリームファイル" 00002.PS"には、 字幕ストリー ムが含まれるため、 字幕読み出し機能部 2 3 5を機能させるために、 値が 1の字幕読み出し機能フラグが、 字幕読み出し機能フラグ記憶部 2 6 1にセットされる。
また、 プレイヤ制御モジュール 2 1 2は、 再生しょうとしている 2 番目の Playltem#l (第 2 5図） の IN_timeである 90， 000と、 OUT— time である 27, 090, 000とを、 デコード制御モジュール 2 14に対して与え る。
さらに、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジ ユール 2 1 9に対する字幕ストリームの表示方式の指示を初期化する 。 即ち、 プレイヤ制御モジュール 2 1 2は、 字幕ストリームの表示方 式をデフォルトの表示方式とするように、 グラフィクス処理モジユー ル 2 1 9を制御する。
なお、 再生対象の字幕ストリームについて、 conf igurable_flag ( 第 1 2図） が、 表示方式の変更を許可する 1になっている場合には、 プレイヤ制御モジュール 2 1 2からグラフィクス処理モジュール 2 1 9に対する字幕ストリームの表示方式の指示は、 現在の表示方式のま まとするようにしても良い。
以下、 2番目の Playltem#lの再生は、 1番目の PlayItem#0の再生と 同様にして行われていく。 そして、 デコード制御モジュール 2 1 4は 、 その 2番目の Playltem#lの再生が行われている間、 内蔵する計時部 2 14 Aが計時している時刻を確認し続けており、 計時部 2 14Aが 計時している時刻が、 ステップ S 1 52 (第 3 1図） でプレイヤ制御 モジュール 2 1 2から与えられた 2番目の P yItem#lの OUT— 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 72に進む。 ステップ 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番目の P l ayL i s t #0を構成する 1番目の P l ayI t em#0によって再生されるクリップストリ一ムファイル" 00001. P S"や、 2番目の P l ay I t em#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 92乃至 S 1 94に順次進み、 再生する字幕ストリームが、 現在再生 されている字幕ストリームから、 他の字幕ストリームに切り替えられ る。
即ち、 ステップ S 1 92において、 プレイヤ制御モジュール 2 1 2 は、 現在再生.中の字幕ストリームを、 クリップ情報ファイル上で特定 する。 具体的には、 例えば、 いま、 第 2 5図で説明した 1番目の Play Li st #0を構成する 2番目の Playltem#lによって、 クリップストリーム ファイル" 00002.PS"に多重化された、 stream— idが OxBDで、 private— s tream— idが 0x80の字幕ストリームが再生されていることとすると、 ス テツプ S 1 9 2では、 現在再生中の字幕ストリームが、 クリップスト リームファイル" 00002.PS"に多重化された 2本の字幕ストリームのう ちの、 第 2 6図 Aおよび第 26図 Bのクリップ情報ファイル" 00002. C LP"上で 3本目の字幕ストリームである stream#2であることが特定さ れる。
そして、 ステップ S 1 9 3に進み、 プレイヤ制御モジュール 2 1 2 は、 ステップ S 1 9 2で特定した字幕ストリームの、 クリップ情報フ アイル上で次の字幕ストリームを、 次に再生する字幕ストリームとし て認識 （特定） する。 第 2 6図 Aおよび第 2 6図 Bでは、 クリップ情 報ファイル" 00002. CLP"上で、 3本目の字幕ストリーム stream#2の次 の字幕ストリームは、 4本目の字幕ストリーム stream#3であるから、 ステップ S 1 9 3では、 この 4本目の字幕ストリーム stream#3が、 次 に再生する字幕ストリームとして認識される。
なお、 現在再生中の字幕ストリームが、 クリップストリームフアイ ル" 00002.PS"に多重化された 2本の字幕ストリ一ムのうちの、 第 2 6 図 Aおよび第 2 6図 Bのクリップ情報ファイル" 00002. CLP"上で 4本 目の字幕ストリームである stream#3であることが特定された場合は、 例えば、 3本目の字幕ストリーム stream が、 次に再生する字幕スト リームとして認識される。
その後、 ステップ S 1 9 4に進み、 プレイヤ制御モジュール 2 1 2 は、 ステップ S 1 9 3で認識した次に再生する字幕ストリームの 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と 1" &16_5 6&111—1(1レジス夕 2 64に、 それぞれ新たにセットし 、 次回以降のバッファ 2 1 5 Aからの読み出しは、 その stream— idレ ジス夕 263と private— stream— idレジス夕 2 64にそれぞれ新たに セッ卜された stream_idと private_stream_idによって特定される字幕 アクセスュニットを対象として行われる。
以上のようにして、 再生する字幕ストリームが、 現在再生されてい る字幕ストリームから、 他の字幕ス卜リームに切り替えられる。
[バッファ制御モジュール 2 1 5の処理]
次に、 第 34図乃至第 3 8図を参照して、 バッファ制御モジュール 2 1 5 (第 3図） の処理、 即ち、 バッファ 2 1 5 Aへのデータの書き 込みと、 バッファ 2 1 5 Aからのデータの読み出しについて説明する バッファ制御モジュール 2 1 5は、 第 3図で説明したように、 バッ ファ 2 1 5 Aに対するデータの読み書きを行うための 5つのポインタ を有している。
即ち、 第 34図および第 3 5図に示すように、 バッファ制御モジュ ール 2 1 5は、 データ先頭ポインタ記憶部 2 3 1に記憶されるデータ 先頭ポインタ、 データ書き込みポインタ記憶部 2 32に記憶されるデ 一夕書き込みボイン夕、 ビデオ読み出しボイン夕記憶部 241に記憶 されるビデオ読み出しボイン夕、 オーディォ読み出しボイン夕記憶部 2 5 1に記憶されるオーディオ読み出しポインタ、 および字幕読み出 しボイン夕記憶部 2 62に記憶される字幕読み出しボイン夕を有して いる。
なお、 第 34図および第 3 5図では、 第 3図におけるビデオ読み出 し機能部 23 3の stream— idレジス夕 242および au— informat ion 0 レジスタ 243、 オーディオ読み出し機能部 2 34の stream— idレジ ス夕 2 52および private_stream idレジス夕 2 5 3、 並びに字幕読 み出し機能部 2 3 5の字幕読み出し機能フラグ記憶部 2 6 1 、 s t ream i dレジスタ 2 6 3、 および pr iva t e— s t ream— i dレジス夕 2 6 4の図示 は、 省略してある。
データ先頭ポインタ記憶部 2 3 1に記憶されたデ一夕先頭ポインタ は、 バッファ 2 1 5 Aに残る最も古いデータ （読み出す必要があるデ 一夕であって、 まだ読み出されていないデ一夕のうちの最も古いデー 夕） の位置を表す。 データ書き込みポインタ記憶部 2 3 2に記憶され たデータ書き込みボイン夕は、 バッファ 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図に示したように、 オーディオ読み出しボイ ン夕が指している最も古いデ一夕の位置から 1秒分だけ過去のデ一夕 の位置を指すように、 データ先頭ポインタを更新する場合には、 リバ —ス方向への特殊再生が指示されたときに、 その特殊再生を開始する のに必要なデータが、 バッファ 2 1 5 Aに記憶されている 1秒分だけ 過去のデータであれば、 上述したようなディスク 1 0 1からのデータ の再読み出しを行わずに、 即座に、 特殊再生を開始することが可能と T JP2005/010627 なる。
なお、 オーディォ読み出しボイン夕が指している最も古いデ一夕の 位置から 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 St 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 0を探索して見つけ出す。 すなわち、 pr ivate— stream— 2の PES— packet 0の stream—idは、 第 2 0図で説明した ように、 10111111B(=0xBF)であり、 ビデオ読み出し機能部 2 3 3は、 stream— idが 10111111Bとなっている PES— packet 0を探索して見つけ出 す。
ここで、 例えば、 いま、 上述したように、 クリップストリームファ ィル" 00001. PS"に格納されたプログラムストリ一ムに多重化されたェ レメンタリストリ一ムが、 再生対象のエレメンタリストリ一ムである とすると、 そのプログラムストリームをディスク 1 0 1から読み出し て、 バッファ 2 1 5 Aに記憶させるときに、 第 3 0図のステップ S 1 2 2において、 クリップストリームファイル" 00001.PS"の EP_map() ( 第 2 7図） に記述されたデコード開始可能点の情報から、 305セクタ が再生開始位置として決定され、 さらに、 第 3 0図のステップ S 1 2 8において、 再生開始位置である 305セクタが指定され、 オペレ一テ ィングシステム 2 0 1に対して、 クリップストリームファイル" 00001 .PS"に格納されたプログラムストリ一ムの読み出しが要求される。 また、 ビデオストリームについては、 EP— mapOに記述されたデコー ド開始可能点の情報は、 実際のデコード開始可能点の直前に配置され た private—stream— 2の PES— packet 0の位置を表す。
従って、 クリップストリ一ムファイル" 00001.PS"に格納されたプロ グラムストリームがディスク 1 0 1から読み出され、 バッファ 2 1 5 Aに記憶された直後においては、 デ一夕先頭ボイン夕ゃビデオ読み出 しポインタが指すバッファ 2 1 5 Aの位置には、 private— stream— 2の PES— packet 0が記憶されている。
ビデオ読み出し機能部 2 3 3は、 ステップ S 2 1 1において、 priv ate_stream— 2の PES_packet 0が見つかると、 ステップ S 2 1 2に進み 、 その private— stream— 2の PES— packet ()の PES— packet— data— byteであ る private— stream2— PES— payloadO (第 2 3図） に記述されている vid eo_stream— idを抜き出し、 その video— stream— idが、 第 3 0図のステ ップ S 1 2 7で stream— idレジス夕 24 2 (第 3図） に記憶された、 再生対象のビデオストリームの stream— idと一致するかどうかを判定 する。 ステップ S 2 1 2において、 private— stream2— PES_payload()に記 述されている video— stream— idが、 stream— idレジス夕 242に記憶さ れた st-ream_idと一致しないと判定された場合、 即ち、 直前のステツ プ S 2 1 1で見つけ出された private— stream— 2の PES—packet 0が、 再 生対象のビデオストリームのデコード開始点に配置されたものでない 場合、 ステップ S 2 1 1に戻り、 バッファ 2 1 5 Aに記憶されたプ口 グラムストリ一ム中の他の private_stream一 2の； PES— packet 0の探索が 行われ、 以下、 同様の処理が繰り返される。
一方、 ステップ 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 3 3は 、 その private— st ream一 2の PES— packet 0の private— stream2— PES— pay 1 oadOに記述されている au_informationOを、 バッファ 2 1 5 Aから 読み出し、 au_information()レジスタ 24 3 (第 3図） に記憶させ、 ステップ S 2 1 4に進む。
ステップ S 2 1 4では、 ビデオ読み出し機能部 2 3 3は、 直前のス テツプ S 2 1 1で見つけ出した private—stream_2の PES_packet() (vi deo_stream_id (第 2 3図） が、 stream— idレジス夕 242 (第 3図） に記憶された stream_idと一致する private— stream_2の PES_packet 0 ) のサイズだけ、 ビデオ読み出しポインタ記憶部 2 3 1に記憶された ビデオ読み出しボインタを更新する。
即ち、 クリップストリ一ムファイルでは、 private_stream_2の PES— packet 0の直後に、 その video stream idと一致する stream idのビデ ォストリーム （PES— packet ()) が配置されており、 従って、 ステップ S 2 1 4では、 ビデオ読み出しポインタは、 ビデオストリームの実際 のデコ一ド開始可能点の位置を指すように更新される。
その後、 ステップ S 2 1 4から 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_information()レジス夕 24 3に記憶され た au— informationOの AU_lengthに記述されたバイト数のデ一夕、 つ まり 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 ()までの間に含まれるビデオアクセスユニット （ピクチャ ) の数を表す number— of— access— uni tが記述されている。
さらに、 au— informationOには、 第 2 4図で説明したように、 その number— of— access— uni tの数だけのビデオアクセスュニッ卜それぞれ に関する情報としての pic— struct— copy, au— reし flag、 および AU— len gthが記述されている。
au— informat ionO ίこ number— of access uni tの数だナ記述されてレ る AU— lengthそれぞれは、 第 24図で説明したように、 それを含む pri vate— stream— 2の PES— packet ら、 次の private— stream— 2の PES— pac ket 0までの間に含まれる、 number_of— access一 uni tの数のビデオァク セスュニットそれぞれのサイズを表すから、 ビデオ読み出し機能部 2 3 3は、 その AU— lengthを用いることで、 ビデオストリームの構文解 析を行うことなく、 アクセスユニットの切り出しを行うことが出来る 即ち、 従来、 MPEG2- Videoや MPEG4- AVCのアクセスユニットを切り出 す場合には、 ビデオストリームの構文を知った上で、 ビデオストリー ムの構文解析を行う必要があつたが、 ディスク 1 0 1に記録されたク リップストリームファイルに格納されたプログラムストリームは、 ビ デォアクセスュニット単位のビデオストリームにおける 1以上の実際 のデコード開始可能点それぞれの直前に、 ビデオアクセスュニットの サイズを表す AU— lengthが記述された private_stream_2の PES— packet ( )を含んでいるので、 ビデオ読み出し機能 2 3 3は、 その private— str eam— 2の PES— packet 0に記述された AU_lengthに基づき、 ビデオストリ ームの構文解析を行うことなく、 バッファ 2 1 5 Aから、 ビデオァク セスユニット （単位のビデオストリーム） を読み出し、 ビデオデコー ダ制御モジュール 2 1 6に供給することができる。
なお、 ビデオ読み出し機能部 2 3 3は、 ステップ S 2 1 6において 、 ビデオアクセスュニッ卜を、 ビデオデコーダ制御モジュール 2 1 6 に供給するときに、 そのビデオアクセスュニッ卜に関する情報として au— information 0に記述されてレ る pi c— struct— copy, au_ref_f lag および AU— 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— informationOレジス夕 2 43に記憶された au— inf orma tionO (第 24図） の number— of— access_uni tが表す数だけのァクセ スュニットを処理したかどうかを判定する。
ステップ 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— of—access— unitが表す 数だけのアクセスユニットを処理したと判定された場合、 即ち、 numb er_of— access— unitが表す数だけのアクセスユニットを、 バッファ 2 1 5 Aから読み出してビデオデコーダ制御モジュール 2 1 6に供給し た場合、 ステップ S 2 1 1に戻り、 次の private— stream— 2の PES_pack et()の探索が行われ、 以下、 同様の処理が繰り返される。
「オーディォストリームの読み出し」
次に、 第 3 7図のフローチャートを参照して、 オーディオ読み出し 機能部 2 34 (第 3図） による、 ノ ッファ 2 1 5 Aからのオーディォ ストリームの読み出し処理の詳細について説明する。
オーディオ読み出し機能部 2 3 4は、 まず最初に、 ステップ S 2 3 0において、 第 3 0図のステップ S 1 2 7で stream— idレジス夕 2 5 2 (第 3図） に記憶された、 再生対象のオーディオストリームの stre am— idが、 private stream— 1の PES— packet 0を表しているかどうかを 判定する。
ステップ S 2 3 0において、 stream— idレジスタ 2 5 2に記憶され た stream— idが、 private— stream— 1の PES_packet 0を表していない判 定された場合、 即ち、 stream— idレジスタ 2 5 2に記憶された stream— idが、 第 2 0図で説明したように、 MPEG規格にしたがって符号化され たオーディオストリームに割り当てられる ΙΙΟχχχχχΒである場合、 ス テツプ 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 34は、 バッ ファ 2 1 5 Aに記憶されたプログラムストリ一ム中の、 stream— idレ ジス夕 2 5 2に記憶された stream— idに一致する PES— packet 0を、 ォ 一ディォ読み出しポインタが示す位置から探索して見つけ出し、 ステ ップ S 2 3 3に進む。 '
ステップ S 2 3 3では、 オーディオ読み出し機能部 2 34は、 ォー ディォ読み出しポインタ記憶部 2 5 1に記憶されたオーディオ読み出 しポインタを、 直前のステップ S 2 3 2で見つけ出した PES_packet() の PES— packet— data_byte (第 1 6図 Aおよび第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 B) の先頭を指すように更新し、 ステップ S 2 3 7 に進む。 ：
ステップ S 2 3 7では、 オーディオ読み出し機能部 2 34は、 ォー ディォデコーダ制御モジュール 2 1 7から、 データの要求があつたか どうかを判定し、 ないと判定した場合、 ステップ S 2 3 7に戻り、 同 様の処理を繰り返す。
また、 ステップ S 2 3 7において、 オーディオデコーダ制御モジュ ール 2 1 7から、 データの要求があつたと判定された場合、 ステップ S 2 3 8に進み、 オーディオ読み出し機能部 2 34は、 オーディオ読 み出しポインタが指しているバッファ 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— 1の PES— packet 0を表してい ると判定された場合、 即ち、 stream— idレジスタ 2 5 2に記憶された s tream— idが、 10111101B(=0xBD)であり、 第 2 0図で説明したように、 private— stream— 1の PES— packet 0を表している場合、 ステップ S 2 3 4に進み、 オーディオ読み出し機能部 2 34は、 バッファ 2 1 5 Aに 記憶されたプログラムストリ一ム中の private— stream_lの PES— packet 0を探索して見つけ出す。 すなわち、 オーディオ読み出し機能部 2 3 4は、 stream— idが 10111101Bとなっている PES jacket 0を探索して見 つけ出す。
オーディオ読み出し機能部 2 34は、 ステップ S 2 34において、 private_stream— 1の PES— packet 0が見つかると、 ステップ S 2 3 5に 進み、 その private stream 1の PES—packet 0の PES packet— data— by te である private— streaml_PES_payload() (第 2 1図） に記述されてい る private— stream— idを抜き出し、 その pr ivate_s tream_idが、 第 3 0 図のステップ S 1 2 7で private_stream_idレジス夕 2 5 3 (第 3図 ) に記憶された、 再生対象のオーディオストリームの private— stream —idと一致するかどうかを判定する。
ステップ S 2 3 5において、 private— streaml— PES— payloadOに記 述されてレ る private— stream— idが、 private— stream— idレジス夕 2 5 3に記憶された private— stream_idと一致しないと判定された場合、 即ち、 直前のステップ S 2 34で見つけ出された private— stream— 1の PES— packet 0が、 再生対象のオーディオストリームではない場合、 ス テツプ S 2 34に戻り、 バッファ 2 1 5 Aに記憶されたプログラムス トリ一ム中の他の private— stream— 1の PES— packet 0の探索が行われ、 以下、 同様の処理が繰り返される。
一方、 ステップ S 2 3 5において、 private— streaml— PES— payload( ) ίこ記述されてレ る pr ivate— s tream— id力 s、 private— stream— idレジス 夕 2 5 3に記憶された private_stream— idと一致すると判定された場 合、 即ち、 直前のステップ S 2 34で見つけ出された private— stream —1の PES— packet 0が、 再生対象のオーディオストリーム'である場合、 ステップ S 2 3 6に進み、 オーディオ読み出し機能部 2 34は、 その private_stream_lの PES— packet 0の priva te—s treaml— PES— pay load 0 (第 2 1図） に記述されている AU_locatorを、 バッファ 2 1 5 Aから 読み出し、 その AU一 locatorの直後の位置と、 その AU—locatorが表す値 とを加算することで、 オーディオアクセスュニッ卜の先頭位置を求め る。
即ち、 AU一 locatorは、 第 2 1図で説明したように、 その AU_locator の直後の位置を基準として、 private— streamし PES_payload()の priva t e— pay l oad Oに格納されるオーディオアクセスュニット （あるいは字 幕アクセスユニット） の先頭位置を表すから、 All oca t orの直後の位 置に、 その AU— l ocat orが表す値を加算することにより、 オーディオア クセスユニットの （絶対的な） 先頭位置を求めることができる。 オーディオ読み出し機能部 2 3 4は、 さらに、 ステップ S 2 3 6に おいて、 以上のようにして求めたォ一ディォアクセスュニットの先頭 位置を指すように、 オーディォ読み出しボインタ記憶部 2 5 1に記憶 されたオーディォ読み出しボインタを更新し、 ステップ 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から読み出し、 そのォ一 ディォアクセスュニットに付加されているタイムスタンプとともに、 オーディオデコーダ制御モジュール 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であると判定された場 合、 即ち、 例えば、 再生対象のエレメン夕リス卜リームが多重化され ているクリップストリ一ムファイルに字幕ストリームが含まれておら ず、 第 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 5 2では、 バッファ 2 1 5 Aに記憶されたプ ログラムストリーム中の private— stream— 1の PES— packet 0が探索され ることになる。
ステップ S 2 5 2において、 private_stream_lの PES— packet 0の探 索が行われ、 private— stream_lの PES— packet 0が見つかると、 ステツ プ S 2 5 3に進み、 字幕読み出し機能部 2 3 5は、 その private— stre am— 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で p rivate— stream— idレジスタ 2 64 (第 3図） に記憶された、 再生対象 の字幕ストリームの private— stream— idと一致するかどうかを判定す る。
ステップ S 2 5 3において、 private_streaml— PES— payloadOに記 述されている private—stream— idが、 private— stream一 idレジス夕 2 6 4に記憶された private— stream— idと一致しないと判定された場合、 即ち、 直前のステップ S 2 5 2で見つかった private— stream— 1の PES_ packet 0が、 再生対象の字幕ストリームではない場合、 ステップ S 2 5 2に戻り、 バッファ 2 1 5 Aに記憶されたプログラムストリ一ム中 の他の private— stream— 1の PES— packet 0の探索が行われ、 以下、 同様 の処理が繰り返される。
一方、 ステップ S 2 5 3において、 private— streaml— PES— payload( ) ίこ記述されてレ る private— stream— id力 private— stream— idレジス 夕 2 64に記憶された private— stream— idと一致すると判定された場 合、 即ち、 直前のステップ S 2 5 2で見つかった private— stream— 1の PES— packet 0が、 再生対象の字幕ストリームである場合、 ステップ S 2 54に進み、 字幕読み出し機能部 2 3 5は、 その private_stream— 1 の PES— packet ()の private— streaml_PES—payload() (第 2 1図） に記 述されている Allocatorを、 バッファ 2 1 5 Aから読み出し、 その AU —locatorの直後の位置と、 その AU_locatorが表す値とを加算すること で、 字幕アクセスユニットの先頭位置を求める。
即ち、 Allocatorは、 第 2 1図で説明したように、 その AU— locator の直後の位置を基準として、 private— streaml— PES— payloadOの priva te— payloadOに格納される字幕アクセスュニット （あるいはオーディ ォアクセスユニット） の先頭位置を表すから、 AU— locatorの直後の位 置に、 その AU— locatorが表す値を加算することにより、 字幕アクセス ユニットの （絶対的な） 先頭位置を求めることができる。
字幕読み出し機能部 2 3 5は、 さらに、 ステップ S 2 54において 、 以上のようにして求めた字幕アクセスュニットの先頭位置を指すよ うに、 字幕読み出しボインタ記憶部 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に進み、 字幕読み出し機能部 23 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 2 7 2に進み、 デコ —ド制御モジュール 2 1 4は、 ビデオデコーダ制御モジュール 2 1 6 からのビデオアクセスュニッ卜のタイムスタンプと、 オーディォ制御 モジュール 2 1 7からのォ一ディォアクセスュニッ卜のタイムスタン プとを比較することにより、 ビデオデータの出力 （デコード） と、 ォ 一ディォデータの出力とのうちのいずれが遅れているかを判定する。 ステップ S 2 7 2において、 ビデオデータの出力が、 オーディォデ 一夕の出力よりも遅れていると判定された場合、 ステツプ S 2 7 3に 進み、 デコード制御モジュール 2 1 4は、 1ビデオアクセスユニット だけ、 ビデオアクセスユニットの処理を進めるために、 ビデオデコ一 ダ制御モジュール 2 1 6に対して、 ビデオアクセスユニットのデコ一 ドと出力 （表示） を行わない旨の指示、 即ち、 ビデオアクセスュニッ トの処理のスキップの指示を出力して、 ステップ S 2 7 4に進む。 ステップ S 2 7 4では、 ビデオデコーダ制御モジュール 2 1 6は、 デコード制御モジュール 2 1 4からのスキップの指示を受信し、 その スキップの指示に応じて、 バッファ制御モジュール 2 1 5からのビデ ォアクセスユニットとともに供給される au—ref— flag (第 2 4図） を 検査する。
即ち、 rivate_s tream_2( PES_packet 0の private— stream2— PES— pa yloadO (第 2 3図） に配置された au_informat ionO (第 2 4図） に は、 アクセスユニットに関する情報としての au_reし flagが含まれて おり、 ノ ッファ制御モジユール 2 1 5は、 第 3 0図のステップ S 1 2 9や、 第 3 6図のステップ S 2 1 6で説明したように、 ビデオァクセ スュニッ卜とともに、 そのビデオアクセスュニットの au—ref— flagを 、 ビデオデコーダ制御モジュール 2 1 6に供給する。
ステップ S 2 74では、 このように、 アクセスユニットとともに供 給される、 そのアクセスュニットの au一 ref—flagが検査される。
そして、 ステップ S 2 74から S 2 7 5に進み、 ビデオデコーダ制 御モジュール 2 1 6は、 バッファ制御モジュール 2 1 5から供給され たビデオアクセスュニットの au_reし flagの検査の結果に基づき、 そ のビデオアクセスユニットが、 他のピクチャのデコードにあたって参 照されない非参照画像であるかどうかを判定する。
ここで、 第 2 4図で説明したように、 ビデオアクセスユニットの au — ref— flagは、 そのアクセスュニットが参照画像であるか否かを表し 、 参照画像である場合には 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に戻る。
以上のように、 デコード制御モジュール 2 1 4では、 ビデオデータ の出力が、 オーディオデータの出力よりも遅れているか否かを判定し 、 ビデオデータの出力が、 オーディオデ一夕の出力よりも遅れている 場合には、 1つのアクセスユニットの処理のスキップを、 ビデオデコ —ダ制御モジュール 2 1 6に指示する。 そして、 ビデオデコーダ制御 モジュール 2 1 6では、 スキップが指示されたアクセスュニットの au — re f— f l agに基づき、 そのアクセスユニットが参照画像であるか、 ま たは非参照画像であるかを判定し、 非参照画像である場合に、 ビデオ デコーダ 1 1 6に、 スキップが指示されたアクセスュニッ卜の処理を スキップさせる。 従って、 ビデオデ一夕の出力と、 オーディオデ一夕 の出力との同期を、 容易にとることができる。
即ち、 処理をスキップするアクセスユニットが参照画像である場合 、 そのアクセスユニットに対応するビデオデータは、 その後にデコー ドされる他のアクセスュニットのデコード時に参照するためにデコー ドする必要がある。 従って、 ビデオデータの出力と、 オーディオデー 夕の出力との同期をとるための同期制御において、 参照画像のァクセ スユニットの処理をスキップしてしまうと、 その参照画像を参照する 他のアクセスユニットをデコードすることができず、 その結果、 ビデ ォデ一夕の表示において、 同期制御がノイズとして現れてしまう。
このため、 処理をスキップするのは、 参照画像でないアクセスュニ ット、 即ち、 非参照画像のアクセスユニットとするのが望ましい。 一方、 従来のエレメン夕リストリームについて、 非参照画像のァク セスュニットを探すためには、 エレメンタリストリームの構文解析を 行う必要があるが、 例えば、 MPEG4-AVCなどにしたがった符号化によ り得られるエレメン夕リストリームは、 構文が非常に複雑であるため 、 構文解析に、 多大なコストがかかる。
これに対して、 ディスク 1 0 1に記録されたクリップストリームフ アイルに格納されたプログラムストリームには、 ビデオアクセスュニ ットが PES_packeし data_byteに配置される PES— packet 0 (第 1 6図 A および第 1 6図 B乃至第 1 8図 Aおよび第 1 8図 B) とは別に、 PES_ packet— data— byteを拡張した private— st ream2— PES— pay load () (第 2 3図） が配置された private— stream— 2の PES— packet 0が多重化されて おり、 その private— stream2— PES— payloadOの au—information() (第 24図） には、 ビデオアクセスユニットごとに、 そのビデオアクセス ュニットが参照画像であるか、 または非参照画像であるかを表す au—r ef— flagが記述されている。 そして、 その au_ref_flagは、 対応するビ デォアクセスュニットとともに、 バッファ制御モジュール 2 1 5から ビデオデコーダ制御モジュール 2 1 6に供給される。 従って、 ビデオ デコーダ制御モジュール 2 1 6は、 ビデオアクセスュニットとともに 供給される、 そのビデオアクセスュニットの au— reし flagを検査する ことにより、 コストをほとんどかけずに、 ビデオアクセスユニットが 参照画像であるか、 または非参照画像であるかを認識することができ る。
[マーク処理]
次に、 第 40図のフローチャートを参照して、 PlayListMarkO (第 7図） に記述された MarkOに基づいて行われるマーク処理について説 明する。
デコード制御モジュール 2 1 4は、 内蔵する計時部 2 1 4 Aによつ て計時されている現在時刻を、 常時確認しており、 ステップ S 3 0 1 において、 現在時刻が、 P yListMarkO (第 7図） に記述されたいず れかの Mark 0の1^ _ 11^—51&即にー致したか否かを判定する。
即ち、 第 3 0図のステップ S 1 24で説明したように、 プレイヤ制 御モジュール 2 1 2は、 第 2 5図に示した 1番目の PlayList#0の 1番 目の PlayItem#0を再生しょうとするときに、 第 2 8図上側に示した P1 ayListMarkOに含まれる 7つの Mark 0のうちの 1番目から 4番目まで の 4つの Mark 0が、 PlayList#0の 1番目の PlayItem#0に属しているこ とを認識し、 その 4つの Mark 0の] nark_time__stampである {180, 090}、 {5,580,090}, {10， 980， 090}、 {16, 380， 090}を、 その mark— t ime一 sta 即が表す時刻の属性が 「マーク処理」 である旨とともに、 デコード制 御モジュール 2 1 4に渡している。
ステップ S 3 0 1では、 デコード制御モジュール 2 14において、 現在時刻が、 上述のようにしてプレイヤ制御モジュール 2 1 2から供 給された 「マーク処理」 の属性の時刻（mark_Ume— stamp)のうちのい ずれかと一致するかどうかが判定される。
ステップ S 3 0 1において、 現在時刻が、 「マーク処理」 の属性の 時刻のうちのいずれとも一致しないと判定された場合、 ステップ S 3 0 1に戻り、 同様の処理が繰り返される。
また、 ステップ S 3 0 1において、 現在時刻が、 「マーク処理」 の 属性の時刻のうちのいずれかと一致すると判定された場合、 デコード 制御モジュール 2 14は、 現在時刻が、 「マ一ク処理」 の属性の時刻 となった旨のメッセ一ジと、 現在時刻と一致した 「マーク処理」 の属 性の時刻とを、 プレイヤ制御モジュール 2 1 2に供給して、 ステップ S 3 02に進む。
ステップ S 3 0 2では、 プレイヤ制御モジュール 2 1 2が、 現在時 刻が、 「マーク処理」 の属性の時刻となった旨のメッセージと、 現在 時刻と一致した 「マーク処理」 の属性の時刻（mark_time_stamp)とを 、 デコード制御モジュール 2 14から受信し、 mark_time_stampが現 在時刻に一致した MarkOを、 マーク処理の処理対象とする MarkO (以 下、 適宜、 処理対象 markという） として認識する。
即ち、 プレイヤ制御モジュール 2 1 2は、 現在再生されている Play List ()の PlayltemOを認識しており、 その PlayList 0および Playltem 0と、 デコード制御モジュール 2 14からの、 現在時刻と一致した 「 マーク処理」 の属性の時刻（mark— time— stamp) (以下、 適宜、 マ一ク 時刻という） とから、 "PLAYLIST.DAT"ファイル （第 5図） の PlayList MarkO (第 7図） を参照することにより、 処理対象 markを認識する。 具体的には、 例えば、 いま、 第 2 5図に示した 1番目の PlayList#0 の 1番目の PlayItem#0が再生されているとすると、 そのことにより、 プレイヤ制御モジュール 2 1 2は、 マーク時刻が、 第 28図上側に示 した1)1& 1^5{!^^()に含まれる 7つの MarkOのうちの 1番目から 4番 目までの 4つの MarkOのうちのいずれかの markjime一 sta即であるこ とを認識する。
そして、 デコード制御モジュール 2 14からプレイヤ制御モジユー ル 2 1 2に供給されたマーク時刻が、 例えば、 16, 380，.090であったと すると、 プレイヤ制御モジュール 2 1 2は、 第 28図上側に示した P1 ayListMarkOに含まれる 1番目から 4番目までの 4つの MarkOのうち の、 mark— time— st a即が、 マーク時刻である 16， 380， 090に一致する 4 番目の MarkOを、 処理対象 markとして認識する。
プレイヤ制御モジュール 2 1 2は、 以上のようにして、 処理対象 ma rkを認識すると、 ステップ S 3 02から S 3 0 3に進み、 処理対象 ma rkにおいて、 エレメン夕リストリームを特定する entry— ES_stream— id と entrv ES_private_stream_id (第 7図） が記述されているかどうか を判定する。
ステップ S 3 0 3において、 処理対象 markに、 エレメンタリストリ —ムを特疋する en try— ES— stream— idと en try— 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と ent ry—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 t ream一 idと entry— ES— private一 stream— idに よって特定されるエレメン夕リストリームが含まれないと判定された 場合、 ステップ S 3 0 1に戻る。 即ち、 処理対象 markの en try— ES—str earn— idと entry_ES— private— stream— idによって特定されるエレメン夕 リストリームが再生されていない場合、 処理対象 markは、 無視される 一方、 ステップ S 3 04において、 再生中のエレメン夕リストリ一 ムに、 処理対象 markの en try— ES— stream— idと en try_ES— private— s trea m_idによって特定されるエレメン夕リストリームが含まれると判定さ れた場合、 即ち、 処理対象 markの entry— ES— stream— idと entry_ES— pri vate— stream— idによって特定されるエレメンタリストリ一ムが再生さ れている場合、 処理対象 markは有効であるとして、 ステップ S 3 0 5 に進み、 以下、 その処理対象 markに応じた処理が行われる。
即ち、 ステップ S 3 0 5では、 プレイヤ制御モジュール 2 1 2は、 処理対象 markの mark— type (第 7図） を参照することにより、 その処 理対象 markを判定する。
ステップ S 3 0 5において、 処理対象 markが、 チヤプ夕マークまた はインデクスマ一クであると判定された場合、 即ち、 処理対象 markの mark— typeが、 ' Chap t er'または' Index'である場合、 ステップ S 3 0 6に進み、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジ ユール 2 1 9に命じて、 チヤプ夕またはインデクスの番号の表示を、 処理対象 markであるチヤプ夕マークまたはィンデクスマークが表すチ ャプタまたはィンデクスの番号に更新させて、 ステップ S 3 0 1に戻 る。
また、 ステップ S 3 0 5において、 処理対象 markが、 イベントマ一 クであると判定された場合、 即ち、 処理対象 markの mark— ^peが、 ' Ev en t 'である場合、 ステップ S 3 0 7に進み、 プレイヤ制御モジュール 2 1 2は、 イベントの発生を表すイベントメッセージと、 処理対象 ma rkの mark— da t aを、 スクリプト制御モジュール 2 1 1に通知 （供給） して、 ステツプ S 3 0 8に進む。
ステップ S 3 0 8では、 スクリプト制御モジュール 2 1 1が、 プレ ィャ制御モジュール 2 1 2からのイベントメッセージと mark— da t aと を受信し、 イベントメッセージを割り込み要求として、 あらかじめ" S CRIPT. DAT"ファイルに記述された一連の処理を、 mark— da t aを引数と して行って、 ステップ S 3 0 1に戻る。
即ち、 スクリプト制御モジュール 2 1 1では、 mark— da t aに対応し た処理が行われる。 具体的には、 例えば、 第 2 8図下側に示した PlayList の PlayLis tMarkOでは、 2番目の MarkO (Marktl) と 3番目の MarkO (Mark#2 ) とは、 いずれも、 mark— typeが' Event'であるが、 mark_da は、 そ れぞれ 1 (Mark#l) と 2 (Marktt2) で異なっている。
スクリプト制御モジュール 2 1 1は、 2番目の MarkOに対応するィ ベントメッセージを受信した場合と、 3番目の MarkOに対応するィべ ントメッセージを受信した場合の、 いずれも場合も、 そのイベントメ ッセージに応じて、 同一のイベントハンドラ （割り込み処理ルーチン ) で処理を行うが、 イベントハンドラ内において、 イベントメッセ一 ジとともに供給される mark_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— streamjdと entr y—ES— private— stream— idが記述されていない場合には、 処理対象 mark の mark— typeに応じた処理が行われる。 また、 処理対象 markにおいて 、 エレメンタリストリ一ムを特定する entry_ES_stream_idと entry— ES — private_stream— idが記述されている場合であっても、 その en try— ES _s t ream— i dと en t ry— ES— pr i va t e_s tream_i dによって特定されるエレメ ン夕リストリームが再生中であれば、 処理対象 markの mark— typeに応 じた処理が行われる。 従って、 例えば、 いま、 第 2 5図に示した 2番目の PlayUst#lの再 生が行われているとすると、 以下のようなマーク処理が行われる。 即ち、 2番目の PlayListUlの PlayListMarkOにおいては、 第 2 8図 下側に示したように、 markjime— s 即がそれぞれ 90, 000， 27, 090,00 0, 27， 540， 000に指定されている 1番目の MarkO (Mark#0)、 2番目の M arkO (Marktl) 、 3番目の MarkO (Mark#2) が記述されている。 さらに、 第 2 8図下側の ayListMarkOにおいては、 2番目の Mark 0と 3番目の MarkOの entry— ES— stream— idには、 それぞれ、 OxEOと Ox Elが記述されているから、 2番目の MarkOと 3番目の MarkOは、 それ ぞれ、 stream— idが OxEOと OxElで特定されるエレメンタリストリ一ム が関連付けられている。
ここで、 第 2 5図で説明したように、 2番目の PlayList#lには、 1 つの PlayltemO (P yItem#0)だけが記述され、 その Playltem#0によれ ば、 クリップストリームファイル" 00003.PS"が再生される。 そして、 クリップストリームファイル" 00003.PS"には、 そのクリップストリー ムファイル" 00003.PS"に対応する第 2 6図 Aおよび第 2 6図 Bのクリ ップ情報ファイル" 00003. CLP"で説明したように、 OxEOとなっている s tream— idで特定されるビデオストリーム stream#0、 OxElとなっている stream— idで特定されるビデオストリーム stream#l、 OxBDとなってい る s earn— idおよび 0x00となっている private— stream— idで特定される オーディォストリ 1 "ム stream#2の 3つのエレメンタリストリームが多 重化されている。
従って、 第 2 8図下側の PlayListMarkOの 2番目の MarkOには、 ク リッブストリ一ムファイル" 00003.PS"に多重化されている、 stream— i dが OxEOとなっているビデオストリ一ム stream#0が関連付けられてお り、 3番目の MarkOには、 クリップストリ一ムファイル" 00003. PS"に 多重化されている、 stream— idが OxElとなっているビデオストリーム s tream#lが関連付けられている。
第 2 5図の 2番目の PlayUst#lの PlayItem#0の再生が開始される場 合、 第 3 0図のステップ S 1 24で説明したようにして、 プレイヤ制 御モジュール 2 1 2は、 第 28図下側に示した PlayListMarkOに含ま れる 3つの Mark 0が、 ayList#lの PlayItem#0に属していることを認 識し、 その 3つの Mark 0の mark— time— st a即である {90， 000}、 {27, 090 ,000}、 {27, 540， 000}を、 その mark— time_stampが表す時刻の属性が 「 マ一ク処理」 である旨とともに、 デコード制御モジュール 2 14に渡 している。
マーク処理では、 デコード制御モジュール 2 14が、 PlayList#lの PlayltemttOの再生中に、 計時部 2 14 Aによって計時される現在時刻 が、 属性が 「マーク処理」 の時刻 {90， 000}、 {27,090,000}、 {27, 540, 000}のうちのいずれかに一致するかを、 常時確認しており （ステップ S 30 1) 、 現在時刻が、 属性が 「マーク処理」 の時刻に一致すると 、 現在時刻と一致した 「マーク処理」 の属性の時刻であるマーク時刻 と、 現在時刻が、 「マーク処理」 の属性の時刻となった旨のメッセ一 ジとを、 プレイヤ制御モジュール 2 1 2に供給する。
即ち、 例えば、 いま、 現在時刻が、 「マーク処理」 の属性の時刻 {9 0, 000} {27,090,000}、 {27, 540， 000}のうちの、 27, 090, 000に一致し たとすると、 デコード制御モジュール 2 14は、 現在時刻と一致した 「マーク処理」 の属性の時刻であるマーク時刻 27, 090, 000と、 現在時 刻が、 「マーク処理」 の属性の時刻となった旨のメッセージとを、 プ レイヤ制御モジュール 2 1 2に供給する。
プレイヤ制御モジュール 2 1 2は、 PlayList#lの PlayItem#0が現在 再生されていることを認識しており、 その P yList#lの第 28図下側 に示したPlayListMarkOに記述された MarkOのうちの、 PlayItem#0に 属する 3つの MarkOの mark— time_stampである 90, 000, 27, 090, 000, 2 7, 540, 000それぞれと、 デコ一ド制御モジュール 2 1 4からのマーク 時刻である Π, 090, 000とを比較することにより、 そのマーク時刻 27,0 90, 000に、 markjime— sta即が一致する Mark()、 即ち、 第 2 8図下側 の PlayListMarkOに記述された 2番目の MarkO (Mark#l)を、 処理対象 markとして認識する （ステップ S 3 0 2) 。
処理対象 markである、 第 2 8図下側の PlayListMarkOに記述された 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 ) 。
一方、 再生中のエレメン夕リストリームの中に、 ビデオストリーム s eam#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_stampと、 MarkOのタイプを表す mark_ty peと、 イベントマークの引数となる mark_dataとを含む 0以上の Mark( )を有する PlayListMarkO (第 7図） を含む PlayList 0 (第 5図） に したがって再生されているクリッブストリームファイルの再生時刻で ある現在時刻が、 mark— time— sta即に一致するか否かが判定され、 現 在時刻が、 mark— time— sta即に一致する場合に、 その一致した現在時 刻であるマーク時刻に等しい mark— Ume— stampを有する MarkOが、 処 理対象！ narkとして認識される。 さらに、 その処理対象 markが有する ma rk— typeが、 イベントを発生させるタイプを表している場合、 即ち、 処理対象 markが、 イベントマークである場合、 処理対象 markが有する mark_dataとィベントメッセージとが通知され、 その mark— dataに応じ た処理が実行される。 従って、 クリップストリームファイルの再生時 刻に応じ、 mark— dataに応じた処理を実行することが可能となる。
[出力属性の制御処理]
次に、 第 4 1図のフロ一チヤ一トを参照して、 第 3 0図のステップ S 1 2 6などで行われる出力属性の制御処理の詳細について説明する 。 '
第 3 0図のステップ S 1 2 6で説明したように、 プレイヤ制御モジ ユール 2 1 2は、 まず、 再生対象の 1以上のエレメン夕リストリーム 、 即ち、 第 3 0図のステップ S 1 2 5で再生すると決定した 1以上の エレメン夕リストリ一ムそれぞれについて、 出力属性が記述される Dy namicInfoO (第 1 3図） の数を表す number— oし Dynamiclnfo (第 1 0 図） を調査する。
そして、 再生対象の 1以上のエレメン夕リストリームのすべてにつ いて、 number— of— Dynamiclnfoが 0になっている場合、 プレイヤ制御モ ジュール 2 1 2は、 特に処理を行わない。
一方、 再生対象のエレメン夕リストリームについての number— 0し 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番目の PlayUst#0の 1番目の PlayItem#0) が再生され るときには、 クリップ情報ファイル" 00001. CLP" (第 2 6図 Aおよび 第 2 6図 B) では、 クリップストリームファイル" 00001.PS"に多重化 されている 4つのエレメン夕リストリーム stream#0乃至 s eam#3のす ベてについて、 number_oし Dynamiclnfoが 0になっているから、 出力属 性の制御処理は行われない。
同様に、 クリップ情報ファイル" 00002. CLP"に対応するクリップス トリ一ムファイル" 00002.PS" (を再生する 1番目の PlayList#0の 2番 目の Playltem#l) が再生されるときも、 クリップ情報ファイル'' 00002 . CLP" (第 2 6図 Aおよび第 2 6図 B) では、 クリップストリームフ アイル" 00002.PS"に多重化されている 4つのエレメン夕リストリ一ム stream#0乃至 streamsのすべてについて、 number— oし Dynamic Infoが 0 になっているから、 出力属性の制御処理は行われない。
一方、 クリップ情報ファイル" 00003. CLP"に対応するクリップスト リームファイル" 00003.PS" (を再生する 2番目の PlayList#lの Playlt emtO) が再生されるときは、 クリップ情報ファイル" 00003.CLP" (第 2 6図 Aおよび第 2 6図 B) において、 クリップストリームファイル "00003.PS"に多重化されている 3つのエレメン夕リストリーム stream #0乃至 stream#2のうちの、 1番目のエレメンタリストリ一ムであるビ デォストリーム stream#0と、 3番目のエレメンタリストリームである ォ一ディストリーム stream#2 ついて、 number— of— Dynamiclnf oが 0で ない 2と 3に、 それぞれなつているから、 出力属性の制御処理が行われ る。
即ち、 出力属性の制御処理では、 まず最初に、 ステップ S 3 2 0に おいて、 プレイヤ制御モジュール 2 1 2は、 再生対象のクリップスト リームファイルに対応するクリップ情報ファイル ClipO (第 1 0図） に記述された pts— change_pointを、 「DynamicInfo()処理」 の属性の 時刻である旨とともに、 デコード制御モジュール 2 1 4に渡し、 デコ —ド制御モジュール 2 1 4は、 プレイヤ制御モジュール 2 1 2からの 「DynamicInfo()処理」 の属性の時刻である pts— change_pointを受信 して、 ステップ S 3 2 1に進む。
ステップ S 3 2 1では、 デコード制御モジュール 2 1 4が、 計時部 2 1 4 Aによって計時されている現在時刻が、 「DynamicInfo()処理 」 の属性の時刻である pts— change— point (のいずれか） に一致したか どうかを判定し、 一致していないと判定した場合、 ステップ S 3 2 1 に戻る。
また、 ステップ S 3 2 1において、 現在時刻が、 「DynamicInfo() 処理」 の属性の時刻 （のいずれか） に一致したと判定された場合、 デ コード制御モジュール 2 1 4は、 現在時刻が、 「DynamicInfo()処理 」 の属性の時刻となった旨のメッセージと、 現在時刻と一致した 「Dy namicInfoO処理」 の属性の時刻 （以下、 適宜、 Dynamiclnf o時刻とい う） とを、 プレイヤ制御モジュール 2 1 2に供給して、 ステップ S 3 2 2に進む。
ステップ S 3 3 2では、 プレイヤ制御モジュール 2 1 2が、 現在時 刻が、 「DynamicInfo()処理」 の属性の時刻となった旨のメッセージ と、 Dynamic Info時刻とを、 デコード制御モジュール 2 14から受信 し、 その Dynamiclnio時刻に一致する pts— change—point (第 1 0図） とセットになっている DynamicInfoOを、 処理対象の Dynamiclnf o 0で ある処理対象 DynamicInioOとして認識して、 ステップ S 323に進 む。
ステップ S 3 2 3では、 プレイヤ制御モジュール 2 1 2は、 処理対 象 DynamicInfoOとなっている DynamicInfoO (第 1 3図） に記述され た出力属性を、 グラフィクス処理モジュール 2 1 9またはオーディオ 出力モジュール 2 2 1に供給して、 ステップ S 32 に進む。
ステップ S 3 24では、 グラフィクス処理モジュール 2 1 9または オーディォ出力モジュール 22 1が、 直前のステップ S 32 3でプレ ィャ制御モジュール 2 1 2から供給された出力属性にしたがって、 ビ デォデータまたはオーディォデ一夕の出力の制御を、 それぞれ開始し 、 ステップ S 3 2 1に戻る。
これにより、 ビデオデ一夕が、 出力属性 （表示方式） として記述さ れた、 例えばアスペクト比に応じて出力され、 あるいは、 オーディオ データが、 出力属性 （出力方式） として記述された、 例えば、 ステレ ォまたはデュアル （ニケ国語） に応じて出力される。 次に、 第 4 2図を参照して、 出力属性の制御処理の詳細について、 さらに説明する。
即ち、 第 4 2図は、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報フ アイル" 00003. CLP"に記述されている pts— change_pointと Dynamic Info ()とのセット （第 1 0図） を示している。
ここで、 上述したように、 クリップストリームファイル" 00003.PS" に多重化されている 3つのエレメンタリストリ一ム3 6&111#0乃至5 6 am#2のうちの、 1番目のエレメン夕リストリームであるビデオストリ —ム stream#0と、 3番目のエレメンタリストリ一ムであるオーデイス トリ一ム stream#2については、 第 2 6図 Aおよび第 2 6図 Bのクリツ プ情報ファイル" 00003. CLP"において、 number— 0し Dynamiclnfoが、 そ れぞれ 2と 3になっている。 従って、 クリップ情報ファイル" 00003. CLP "において、 クリップストリームファイル" 00003.PS"の 1番目のビデ ォストリ一ム streamttOについては、 2セットの pts— change— pointおよ び DynamicInfoOが記述されており、 3番目のオーディオストリーム s tream#2【こつレ てま、 3セッ卜の pts— change— pointおよび Dynamiclnfo 0が記述されている。
第 4 20上側は、 クリッブストリ一ムファイル" 00003.PS"の 1番目 のビデオストリ一ム streamsについて記述されている 2セッ卜の pts_ change一 pointおよび DynamicInfoOを示しており、 第 4 2図下側は、 クリップストリームファイル" 00003.PS"の 3番目のオーディォストリ —ム stream#2について記述されている 3セットの pts一 change_pointお よび DynamicInfoOを示している。
なお、 第 42図上側では、 1番目のビデオストリーム streamsにつ いて記述されている 2セットの pts— change_pointおよび DynamicInfo( )の他に、 そのビデオストリーム stream#0について、.第 2 6図 Aおよ 2005/010627 び第 2 6図 Bのクリップ情報ファイル" 00003. CLP"に記述されている s tream— id (=0xE0)， pr i vat e_siream_id (=0x00) , number— oし Dynami cln fo(=2)も、 図示してある。 同様に、 第 4 2図下側でも、 3番目のォ一 ディォストリーム stream について記述されている 3セッ 卜の pts_ch ange— pointおよび DynamicInfoOの他に、 そのオーディオストリーム s tream#2について、 第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファ ィル" 00003. CLP"に記述されている stream— id(=0xBD)， pr i vate_s t rea m_id(=0x00), number— of— Dynamiclnio (=3)も、 図示してある。
第 4 2図上側において、 ビデオストリーム stream#0について記述さ れている 2セットの pts— change— pointおよび DynamicInfoOのうちの 1セット目では、 pts— change—pointが 90， 000になっており、 Dynamicl nfoOの display— aspect_ratio (第 1 3図） が' 4:3'になっている。 さ らに、 その 2セット目では、 pts— change— pointが 54, 090, 000になって おり、 DynamicInfoOの display— aspecし ratioが' 16:9'になっている 。
一方、 第 4 2図下側において、 オーディオストリ一ム stream#2につ いて記述されている 3セットの pts— change— pointおよび DynamicInfo( )のうちの 1セット目では、 pts_change_pointが 90， 000になっており 、 Dy謹 iclnfo 0の channel— assignment (第 1 3図） が' Dual'になつ ている。 さらに、 その 2セット目では、 pts— changejtointが 27， 090, 0 00になっており、 DynamicInfoOの channel— assignment力 Stereo'に なっている。 また、 その 3セット目では、 pts— change_pointが 32， 490 ， 000になっており、 DynamicInfoOの channel— assignmentが' Dual'に なっている。
例えば、 いま、 第 3 0図のステップ S 1 2 5において、 クリップス トリームファイル" 00003.PS"の、 OxEOとなっている si ream— idで特定 される 1番目のビデオストリーム stream#0と、 OxBDとなっている stre am— idおよび 0x00となっている private— stream— idで特定される 3番目 のオーディォストリーム stream#2とが、 再生対象のストリームとして 決定されたとする。
この場合、 プレイヤ制御モジュール 2 1 2は、 OxEOとなっている st ream— idで特定されるビデオストリ一ム stream#0について記述されて いる第 42図上側の 2セットの pts— change— pointおよび Dynamiclnfo ( )と、 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という時刻は、 ビデ ォストリーム stream#0が多重化されているクリップストリ一ムフアイ ル" 00003.PS"に対応する第 2 6図 Aおよび第 2 6図 Bのクリップ情報 ファイル" 00003. CLP"において、 クリップストリームファイル" 00003. PS"の先頭の時刻を表す presentation— starし Umeに記述されている時 刻 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#2が多重化されているクリッブストリームファイル" 00003. PS" に対応する第 2 6図 Aおよび第 2 6図 Bのクリップ情報ファイル" 000 03.CLP"において、 クリップストリームファイル" 00003.PS"の先頭の 時刻を表す0 36 & 011_5 1>し^1116に記述されてぃる時刻90,000に 一致する。
プレイヤ制御モジュール 2 1 2は、 クリップストリームファイル" 0 0003. PS"の先頭の時刻を表す present at ion— start— timeに記述されて いる時刻 90，000にー致する 13—(^&1^6_0011^を、 初期値として認識す る。 従って、 第 42図上側の 2セットの pts— change— pointおよび Dyna micInfoOのうちの 1セット目の pts— change— pointと、 第 42図下側 の 3セットの pts— change— pointおよび Dynamiclnfo 0のうちの 1セッ ト目の pts_change_pointが、 初期値として認識される。
そして、 プレイヤ制御モジュール 2 1 2は、 クリップストリームフ アイル" 00003.PS"の再生が開始される前に （第 3 0図のステップ S 1 2 6で） 、 初期値として認識した pts_change__pointとセットになって いる DynamicInfoOにしたがって、 対応するエレメン夕リストリーム の出力属性を指示する。
即ち、 OxEOとなっている stream— idで特定されるビデオストリ一ム s tream#0については、 第 42図上側で、 初期値である 90, 000になって いる pts— change_poiniとセットになっている Dynamiclnfo 0において 、 display— aspect— ratioが' 4:3'になっている。 この場合、 プレイヤ 制御モジュール 2 1 2は、 display— aspect一 ratioが' 4:3'になってい る旨、 即ち、 ビデオストリーム stream#0が、 4 : 3のアスペクト比の ビデオデータである旨の出力属性の情報を、 グラフィクス処理モジュ ール 2 1 9を制御する。
また、 OxBDとなっている stream_idおよび 0x00となっている private stream idで特定されるオーディォストリーム stream#2については、 10627 第 4 2図下側で、 初期値である 90, 000になっている pts— change—point とセッ 卜 ίこなっている DynamicInfoO ίこおレ て、 c annel_ass ignment が' Dua になっている。 この場合、 プレイヤ制御モジュール 2 1 2は 、 channel— assignmentが' Dual'になっている旨、 即ち、 オーディオス トリ一ム streain が、 デュアルのオーディオデータである旨の出力属 性の情報を、 オーディオ出力モジュール 2 2 1に供給する。
ここで、 第 3 0図のステップ S 1 2 6では、 以上のような初期値と しての pts— change一 pointを対象とした出力属性の制御処理が行われる その後、 プレイヤ制御モジュール 2 1 2は、 ビデオストリーム stre am#0についての第 42図上側の 2つの pts— change— pointである 90， 000 および 54, 090， 000と、 オーディォストリーム s eam#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}を、 「Dynami c Inf o 0処理」 の属性の 時刻である旨とともに、 デコード制御モジュール 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#2の再生 （クリップストリームフ アイル" 00003.PS"を再生する 2番目の PlayList#lの PlayItem#0の再生 ) の開始後、 計時部 2 1 4 Aによって計時されている現在時刻の監視 を開始する。
そして、 デコード制御モジュール 2 1 4は、 現在時刻が、 「Dynami clnfoO処理」 の属性の時刻 {27, 090， 000}, {32,490,000}, {54,090,0 5010627
00}のうちのいずれかに一致した場合、 その現在時刻と一致した 「Dyn amicInfoO処理」 の属性の時刻である Dynamiclnfo時刻を、 プレイヤ 制御モジュール 2 1 2に供給する （ステップ S 3 2 1) 。
即ち、 例えば、 現在時刻が、 27,090,000になったとすると、 デコ一 ド制御モジュール 2 14は、 「DynamicInfo()処理」 の属性の時刻の うちの、 現在時刻と一致する 27，090,000を、 Dynamiclnfo時刻として 、 プレイヤ制御モジュール 2 1 2に供給する
プレイヤ制御モジュール 2 1 2は、 デコード制御モジュール 2 1 4 からの Dynamiclnfo時刻である 27， 090, 000を受信し、 ビデオストリ一 ム stream#0についての第 42図上側の 2つの pts— change_pointと、 ォ 一ディォストリ一ム stream についての第 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番目の Dynamiclnfo 0を 、 処理対象 DynamicInfoOとして認識する （ステップ S 322) 。
処理対象 DynamicInfoOが、 ビデオストリ一ムについての Dynamicln fo()である場合、 プレイヤ制御モジュール 2 1 2は、 処理対象 Dynarai clnfoOに記述されている出力属性を、 グラフィクス処理モジュール 2 1 9に供給する （ステップ S 32 3) 。 また、 処理対象 Dynamiclnf οθが、 オーディォストリームについての DynamicInfoOである場合、 プレイヤ制御モジュール 2 1 2は、 処理対象 DynamicInfoOに記述さ れている出力属性を、 オーディオ出力モジュール 22 1に供給する （ ステップ S 3 2 3 ) 。
グラフィクス処理モジュ一ル 2 1 9は、 プレイヤ制御モジュール 2 1 2から出力属性が供給されると、 その出力属性にしたがって、 ビデ ォデ一夕の出力の制御を開始する （ステップ S 3 2 4) 。
即ち、 グラフィクス処理モジュール 2 1 9は、 例えば、 プレイヤ制 御モジュール 2 1 2からの出力属性が表す、 ビデオデ一夕のァスぺク ト比の指示（display— aspecし ratio (第 1 3図） ）と、 第 1図のビデオ 出力端子 1 2 0に接続されたビデオ出力装置のァスぺクト比とに基づ いて、 ビデオ出力モジュール 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や 1 6:9で、 同一である場合、 グラフィクス処理モジュール 2 1 9は、 ピ デォ出力モジュール 2 2 0に出力するビデオデータを、 スクイ一ズ処 理することなく、 そのまま出力する。
ここで、 第 42図上側において、 OxEOとなっている stream_idで特 定されるビデオストリ一ム stream#0について記述されている 2セット の pts_change— pointおよび DynamicInfoOによれば、 ビデオストリ一 ム stream#0の再生開始時である時刻 90， 000から、 時刻 54， 090, 000の直 前までは、 ビデオストリーム s eam#0から、 4 ： 3のアスペクト比の ビデオデ一夕が得られる。 そして、 時刻 54, 090， 000以後は、 ビデオス 卜リーム s t reamttOから、 1 6 ： 9のアスペクト比のビデオデータが得 られる。
従って、 例えば、 第 1図のビデオ出力端子 1 2 0に接続されたビデ ォ出力装置のァスぺクト比が 4 : 3であるとすると、 グラフィクス処理 モジュール 2 1 9では、 時刻 90, 000から時刻 54, 090, 000の直前までは 、 ビデオストリーム s t ream#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し as s i gnmen 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に出力 する。
また、 例えば、 出力属性が表すオーディオデータのチャネル割り当 ての指示が、 ステレオ（S t ereo)モ一ドを表している場合、 オーディオ 出力モジュール 2 2 1は、 プレイヤ制御モジュール 2 1 2から供給さ れる音声出力モードにかかわらず、 ォ一ディォデコーダ制御モジユー ル 2 1 7からのオーディオデータを、 そのまま、 オーディオ出力端子 1 2 1に出力する。
ここで、 第 42図下側において、 OxBDとなっている stream— idおよ び 0x00となっている privat stream— idで特定されるオーディォスト リーム stream#2について記述されている 3セットの pts— change— point および Dynamic Info 0によれば、 オーディォストリ一ム stream#2の再 生開始時である時刻 90, 000から、 時刻 27, 090， 000の直前までは、 ォー ディォストリーム stream#2から、 デュアルのオーディォデータが得ら れる。 また、 時刻 27,090， 000から、 時刻 32，490， 000の直前までは、 ォ —ディォストリーム. stream#2から、 ステレオのオーディォデータが得 られ、 時刻 32， 490， 000以後は、 ォ一ディォストリーム stream から、 デュアルのオーディォデータが得られる。
従って、 例えば、 音声出力モードとして、 「主音声」 が指定されて いるとすると、 オーディオ出力出力モジュール 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 ntに一致するか否かが判定される。 そして、 再生中のエレメン夕リス トリ一ムの再生時刻が、 pts_change一 pointに一致する場合、 その] Dts_ change— pointとセットになっている Dynamiclnf o 0が認識され、 その 認識された DynamicInfoOに含まれる出力属性にしたがって、 再生中 のエレメン夕リストリームの出力が制御される。 従って、 エレメン夕 リストリームの再生時刻と出力属性に応じて、 そのエレメンタリスト リームの出力を制御することが可能となる。
[字幕表示制御処理]
次に、 第 43図のフローチヤ一トを参照して、 字幕ストリームに対 応する字幕データの表示を制御する字幕表示制御処理について説明す る。
PlayListO (第 5図） （の PlayltemO ) の再生が開始されると、 プ レイヤ制御モジュール 2 1 2は、 ステップ S 34 1において、 グラフ イクス処理モジュール 2 1 9に対する字幕データの表示方式の指示を 初期化する。 即ち、 プレイヤ制御モジュール 2 1 2は、 字幕データの 表示方式をデフオル卜の表示方式とするように、 グラフィクス処理モ ジュール 2 1 9を制御する。 なお、 ステップ S 34 1で行われる表示 方式の指示の初期化は、 第 3 0図の 1 2 7で説明した表示方式の指示 10627 の初期化に対応する。
ステップ 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 3 4 3において、 字幕ストリームが再生されていないと 判定された場合、 ステップ S 3 4 2に戻る。
また、 ステップ S 3 4 3において、 字幕ストリームが再生されてい ると判定された場合、 ステップ S 3 4 5に進み、 プレイヤ制御モジュ ール 2 1 2.は、 新たな表示方式の指示が、 デフォルトの表示方式の指 示であるかどうかを判定する。 ステップ S 3 4 3において、 新たな表 示方式の指示が、 デフォルトの表示方式の指示であると判定された場 合、 ステップ S 3 4 1に戻り、 上述したように、 プレイヤ制御モジュ ール 2 1 2は、 字幕データの表示方式をデフォルトの表示方式とする ように、 グラフィクス処理モジュール 2 1 9を制御する。
一方、 ステップ S 3 4 5において、 新たな表示方式の指示が、 デフ オルトの表示方式の指示でないと判定された場合、 即ち、 新たな表示 方式の指示が、 例えば、 字幕データを拡大や縮小して表示する、 ある いは明るさを変えて見やすくする等、 デフォルトでない表示方式の指 示である場合、 ステップ S 3 4 6に進み、 プレイヤ制御モジュール 2 1 2は、 現在再生している字幕ストリームが多重化されたクリップス トリームファイルに対応するクリップ情報ファイル C l ip 0 (第 1 0図 05010627
) の StaticIn.foO (第 1 2図） のうちの、 現在再生している字幕スト リームについての Stat icInfoOを取得し、 ステップ S 347に進む。 ステップ S 347では、 プレイヤ制御モジュール 2 1 2は、 ステツ プ S 346で取得した StaticInfoOの configurable— flagを判定する ステップ S 347において、 configurable— flagが、 字幕デ一夕の 表示方式の変更を許可しない旨の 0になっていると判定された場合、 ステップ S 348に進み、 プレイヤ制御モジュール 2 1 2は、 グラフ イクス処理モジュール 2 1 9を制御することにより、 出力ビデオデー 夕に、 字幕デ一夕の表示方式を変更することができない旨のエラ一メ ッセージをオーバーレイさせ、 ステップ S 342に戻る。 これにより 、 エラーメッセージが表示される。
一方、 ステップ S 347において、 conf igurable_flagが、 字幕デ —夕の表示方式の変更を許可する旨の 1になっていると判定された場 合、 ステップ S 349に進み、 プレイヤ制御モジュール 2 1 2は、 ュ 一ザがリモコンを操作することにより入カイン夕一フェース 1 1 5か ら供給された新たな表示方式の指示を、 グラフィクス処理モジュール 2 1 9に供給して、 ステップ S 3 50に進む。 '
ステップ S 3 50では、 グラフィクス処理モジュール 2 1 9は、 字 幕デコーダ制御モジュール 2 1 8から供給される字幕データを、 直前 のステップ S 349でプレイヤ制御モジュール 2 1 2から供給された 表示方式の指示にしたがって拡大または縮小等あるいは明るさを変え る等の処理を開始し、 ステップ S 342に戻る。 これにより、 字幕デ —夕は、 ユーザがリモコンを操作することによって指示した表示方式 にしたがった表示サイズや、 表示位置、 表示色等で表示される。
一方、 ステップ S 342において、 新たな表示方式の指示がなかつ 10627 たと判定された場合、 ステップ S 3 5 1に進み、 プレイヤ制御モジュ —ル 2 1 2は、 第 3 1図で説明した PlaylteniOの乗り換えが行われた かどうかを判定し、 行われていないと判定した場合、 ステップ S 34 2に戻る。
また、 ステップ S 3 5 1において、 PlayltemOの乗り換えが行われ たと判定された場合、 ステップ S 341に戻り、 上述したように、 プ レイヤ制御モジュール 2 1 2は、 字幕データの表示方式をデフォルト の表示方式とするように、 グラフィクス処理モジュール 2 1 9を制御 する。 即ち、 この場合、 PlayltemOの乗り換えが行われたときには、 字幕データの表示方式は、 デフオル卜の表示方式に戻される。
以上のように、 字幕表示制御処理においては、 字幕ストリームの CO nfigurable— flagが、 表示方式の変更を許可する旨の 1になっている場 合にのみ、 その字幕ストリームに対応する字幕データの表示方式が、 例えば、 ユーザがリモコンを操作することにより入力される表示方式 の指示に応じて変更される。
従って、 例えば、 第 2 6図 Aおよび第 26図 Bに示したクリップ情 報ファイル" 00001. CLP"によれば、 対応するクリップストリームファ ィル" 00001.PS"に多重化されている 4本のエレメンタリストリ一ムの うちの 3本目のエレメン夕リストリームである字幕ストリーム st ream #2についての configurable— flagは、 表示方式の変更を許可しない旨 の 0になっているので、 その字幕ストリーム stream#2が表示されてい るときに、 ユーザが字幕の表示を変更するようにリモコンを操作して も、 その表示は変更されない。
一方、 例えば、 クリップストリームファイル" 00001.PS"に多重化さ れている 4本のエレメン夕リストリームのうちの 4本目のエレメン夕 リストリームである字幕ストリ一ム stream#3についての configurable 2005/010627
_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本 目の字幕ストリーム streain#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に ついての StaticInfoOを探し出す。
さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 6図 Aおよび第 2 6図 Bにおいて 3本目の字幕ストリーム stream#2についての S ticIn fo()に記述されている、 0になっている configurable_fIagを判定し （ ステップ S 34 7) 、 これにより、 3本目の字幕ストリーム stream#2 については、 表示方式の変更が許可されていないことを認識する。 この場合、 プレイヤ制御モジュール 2 1 2は、 再生中の字幕ストリ ーム （に対応する字幕データ） が拡大縮小等に対応していないと判断 し、 グラフィクス処理モジュール 2 1 9を制御することにより、 その 旨のエラ一メッセージを生成させ （ステップ S 348) 、 ビデオデ一 夕にオーバーレイして出力させる。
一方、 クリップストリームファイル" 00001.PS"に多重化されている 4本のエレメンタリストリ一ムの 3本目の字幕ストリ一ム stream#2と 、 4本目の字幕ストリーム stream#3のうちの、 3本目の字幕ストリ一 ム stream#2ではなく、 4本目の字幕ストリーム s tream#3が、 現在再生 されている場合には、 ユーザがリモコンを操作することによって表示 方式の指示の供給を受けたプレイヤ制御モジュール 2 1 2は、 対応す るクリップ情報ファイル" 00001. CLP"から、 4本目の字幕ストリ一ム s t ream#3についての Stat icInfoOを探し出す。
さらに、 プレイヤ制御モジュール 2 1 2は、 第 2 6図 Aおよび第 2 6図 Bにおいて 4本目の字幕ストリ一ム stream#3についての Static In foOに記述されている、 1になっている configurable一 flagを判定し （ ステップ S 34 7) 、 これにより、 4本目の字幕ストリーム streani#3 については、 表示方式の変更が許可されていることを認識する。
この場合、 プレイヤ制御モジュール 2 1 2は、 再生中の字幕ス卜リ ーム （に対応する字幕データ） が拡大縮小等に対応していると判断し 、 ユーザがリモコンを操作することによって供給された表示方式の指 示を、 グラフィクス処理モジュール 2 1 9に供給する （ステップ S 3 49) 。
これにより、 その後、 グラフィックス処理制御モジュール 219は 、 プレイヤ制御モジュール 212からの表示方式の指示にしたがい.、 字幕デコーダ制御モジュール 218からの字幕デ一夕を拡大または縮 小等し、 ビデオデコーダ制御モジュール 216からのビデオデータに オーバーレイして出力する。
なお、 プレイヤ制御モジュール 2 12は、 PlayListOの最初の Play Item 0の再生開始時に、 グラフィクス処理モジュール 2 19に対する 字幕データの表示方式の指示を初期化する （ステップ S 341) 。 即 ち、 プレイヤ制御モジュール 212は、 字幕データの表示方式をデフ オルトの表示方式とするように、 グラフィクス処理モジュール 2 19 を制御する。
さらに、 プレイヤ制御モジュール 212は、 PlayltemOの乗り換え 時にも、 グラフィクス処理モジュール 219に対する字幕データの表 示方式の指示を初期化する （ステップ S 341 , S 351) 。
伹し、 PlayltemOの乗り換え時においては、 その後に新たに再生さ れる PlayltemOにしたがって再生される新たな字幕ストリームについ ての configurable— flagを調査し、 conf igurable一 flagが 0である場合 には、 グラフィクス処理モジュール 219に対する字幕データの表示 方式の指示を初期化し、 configurable— flagが 1である場合には、 ダラ フィクス処理モジュール 219に対する表示方式の指示を、 Playltem 0の乗り換え前のまま維持するようにすることが可能である。
また、 第 43図の字幕表示制御処理では、 ユーザがリモコンを操作 することにより、 新たな表示方式の指示が入力された場合に、 その新 たな表示方式の指示を、 グラフィクス処理モジュール 219に供給す るようにしたが （ステップ S 349) 、 表示方式の指示は、 例えば、 メモリ 1 13 (第 1図） を構成する不揮発性メモリに記憶し、 その不 揮発性メモリに記憶された表示方式の指示を、 グラフィクス処理モジ ユール 219に供給するようにすることが可能である。
即ち、 例えば、 第 1図のディスク装置の初期設定として、 不揮発性 メモリに、 ユーザ設定の表示方式の指示を記憶させておき、 ユーザが リモコンを操作することにより、 新たな表示方式の指示が入力された 場合には、 不揮発性メモリに記憶された表示方式の指示を、 新たな表 示方式の指示に更新する一方、 その不揮発性メモリに記憶された表示 方式の指示を、 グラフィクス処理モジュール 219に供給するように することが可能である。 この場合、 不揮発性メモリには、 前回の再生 終了時における表示方式の指示が保持されるので、 次回の PlayListO の再生時に、 ユーザがリモコンを操作することにより、 前回の再生終 了時における表示方式の指示を入力しなくても、 その表示方式で、 字 幕データの表示が開始される。
なお、 この場合、 不揮発性メモリに記憶させる表示方式の指示には 、 例えば、 字幕データを拡大または縮小するときの拡大率または縮小 率等が含まれるものとする。
以上のように、 字幕表示制御処理によれば、 クリップ情報ファイル ClipO (第 10図） に含まれる、 エレメンタリストリ一ムごとの、 そ のエレメン夕リストリームの再生中に変化しない StaticInfoOのうち の、 字幕データの StaticInfoOが取得され、 その StaticInfoOに含ま れる、 字幕データの表示をデフォルトの表示方式から変更することを 許可するか否かを表す configurable一 flagに基づき、 再生中の字幕デ —夕の表示をデフォルトの表示方式から変更することが許可されてい るか否かが判定される。 そして、 再生中の字幕デ一夕の表示をデフォ ルトの表示方式から変更することが許可されている場合には、 字幕デ 一夕の表示方式の変更の指示にしたがって、 その字幕デ一夕の表示処 理、 即ち、 例えば、 字幕データを拡大または縮小、 あるいは表示色を 変更する等して表示する処理が行われる。 従って、 字幕デ一夕の表示 方式の変更を制御することができる。
[キヤプチヤ制御処理]
次に、 第 44図のフローチャートを参照して、 ビデオストリームに 対応するビデオデータのキヤプチャを制御するキヤプチャ制御処理に ついて説明する。 なお、 第 44図には、 キヤプチャ制御処理を説明す るフローチヤ一卜とともに、 そのキヤプチャ制御処理によってキヤプ チヤされたビデオデータを 2次利用する処理の例であるバックグラウ ンド Zスクリーンセーバ処理を説明するフローチャートも、 図示して ある。
キヤプチャ制御処理は、 例えば、 ュ一ザがリモコンを操作すること により、 ビデオデータのキヤプチャを指示するキヤプチャ指示が、 入 力インターフエ一ス 1 1 5 (第 1図） を介して、 プレイヤ制御モジュ —ル 2 1 2に供給されると開始される。
即ち、 キヤプチャ制御処理では、 まず最初に、 ステップ S 3 7 1に おいて、 プレイヤ制御モジュール 2 1 2が、 ビデオストリームを再生 中であるかどうかを判定し、 再生中でないと判定した場合、 キヤプチ ャ制御処理は終了する。
一方、 ステップ S 3 7 1において、 ビデオストリームを再生中であ ると判定された場合、 ステップ S 3 7 2に進み、 プレイヤ制御モジュ —ル 2 1 2は、 再生中のビデオストリームに対応する PlayListO (第 5図） から、 capture_enable— flag—PlayListを取得するとともに、 再 生中のビデオストリームに対応するクリップ情報ファイル ClipO (第 1 0図) から、 capture— enable— flag— Clipを取得する。 ここで、 PlayList ()における capture— enable— flag— PiayListは、 第 5図で説明したように、 その PlayList 0によって再生されるビデオス トリームに対応するビデオデータ （PlayList 0に属するビデオデ一夕 ) の 2次利用を許可するか否かを表す。 また、 クリップ情報ファイル ClipOにおける capture— enable_flag_Clipは、 第 1 0図で説明したよ うに、 そのクリップ情報ファイル ClipOに対応するクリップストリ一 ムファイルに格納されているビデオストリームに対応するビデオデー 夕の 2次利用を許可するか否かを表す。
ステップ S 3 7 2の処理後は、 ステップ S 3 7 3に進み、 プレイヤ 制御モジュール 2 1 2は、 直前のステップ S 3 7 3で取得された capt ure— enable— flag— PlayListと capture— enable— flag— CI ipとに つき、 キヤプチャ指示が入力イン夕一フェース 1 1 5 (第 1図） から入力さ れたときに再生されていたビデオデータのピクチヤのキヤプチヤの可 否を判定する。
ステップ S 3 7 3において、 キヤプチャ指示が入カイン夕一フエ一 ス 1 1 5から入力されたときに再生されていたビデオデータのピクチ ャのキヤプチヤが不可であると判定された場合、 即ち、 直前のステツ プ S 3 7 3で取得された capture_enable_flag— PlayListまたは captur e_enable—flag_Clipのうちの少なくとも一方が、 ビデオデータの 2次 利用を許可しない旨の 0になっている場合、 ステップ S 3 74に進み 、 プレイヤ制御モジュール 2 1 2は、 グラフィクス処理モジュール 2 1 9を制御することにより、 ビデオデ一夕のキヤプチヤが不可である 旨のエラーメッセージをオーバーレイさせ、 キヤプチャ制御処理を終 了する。 これにより、 エラーメッセージが表示される。
一方、 ステップ S 37 3において、 キヤプチャ指示が入力インタ一 フェース 1 1 5から入力されたときに再生されていたビデオデ一夕の ピクチャのキヤプチヤが可能であると判定された場合、 即ち、 直前の ステップ S 3 7 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 37 6に進む。
ステップ 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図） それぞ れの c ap t u r e— en ab 1 e— f 1 ag— P 1 ayL i s tと c ap t ur e— enab 1 e— f 1 ag_C 1 i pとの 論理積をとつて、 その論理積が 1である場合、 即ち、 capture_enable— flag— PlayListと capture— enable— flag— Clipが、 いずれも、 2次利用 を許可する 1になっている場合にのみ、 ビデオデ一夕の 2次利用が可 能であると判断され、 キヤプチヤが行われる。 従って、 例えば、 第 2 5図における 1番目の PlayList#0の 1番目の P yItem#0にしたがって、 ビデオストリームの再生、 即ち、 クリップ ストリームファイル" 00001.PS"に多重化されたビデオストリ一ムの再 生が行われている場合に、 ユーザからのキヤプチャ指示があつたとき には、 1番目の PlayList#0における capture_enable— flag— PlayListは 1であり、 その 1番目の PlayItem#0によって再生されるクリップスト リ一ムファイル" 00001.PS"に対応する第 26図 Aおよび第 2 6図 Bの クリップ情報ファイル" 00001. CLP"における cap t ure— enab 1 e—f 1 ag— C 1 i pは 1であるから、 再生中のビデオデータ （クリップストリームフアイ ル" 00001.PS"に多重化されたビデオストリームに対応するビデオデー 夕） の 2次利用は可能であると判断され、 キヤプチヤが行われる。 また、 例えば、 第 25図における 1番目の PlayList#0の 2番目の P1 ayltem#lにしたがって、 ビデオストリームの再生、 即ち、 クリップス トリ一ムファイル" 00002.PS"に多重化されたビデオストリームの再生 が行われている場合に、 ユーザからのキヤプチャ指示があつたときに は、 1番目の PlayList#0における capture_enable_flag— PlayListは 1 であり、 その 2番目の Playliemiflによって再生されるクリップストリ —ムファイル" 00002.PS"に対応する第 26図 Aおよび第 26図 Bのク リップ情報ファイル" 00002. CLP"における capture— enable_f lag— Clip は 0であるから、 再生中のビデオデータ （クリップストリ一ムフアイ ル" 00002.PS"に多重化されたビデオストリームに対応するビデオデー 夕） の 2次利用は不可であると判断され、 キヤプチヤが行われない。 さらに、 例えば、 第 2 5図における 2番目の PlayList#lの Playltem きにしたがって、 ビデオストリームの再生、 即ち、 クリップストリー ムファイル" 00003.PS"に多重化されたビデオストリームの再生が行わ れている場合に、 ユーザからのキヤプチャ指示があったときには、 2 番目の PI ayL is t#lにおける capture— enable— flag_PlayLi stは 0であり 、 2番目の PlayList#lの PlayltemlfOによって再生されるクリップスト リームファイル" 00003.PS"に対応する第 2 6図 Aおよび第 2 6図 Bの クリップ情報ファイル" 00003. CLP"における capture— enable— flag— CI i pは 1であるから、 再生中のビデオデ一夕 （クリップストリームフアイ ル" 00003.PS"に多重化されたビデオストリームに対応するビデオデ一 夕） の 2次利用は不可であると判断され、 キヤプチャは行われない。 なお、 この場合、 2番目の PlayList#lにおける capture— enable— a g— PlayListが 0であることが確認された時点で、 ビデオデータの 2次 利用は不可であると判断することができるので、 2番目の： PlayList#l の PI ay It em#0によって再生されるクリップストリームファイル" 000Q3 .PS"に対応する第 26図 Aおよび第 2 6図 Bのクリップ情報ファイル " 00003. CLP"における capture_enable— flag— Clipの確認は省略するこ とができる。
キヤプチャ制御処理によってキヤプチヤされ、 メモリ 1 1 3に記憶 されたピクチャは、 バックグラウンド Zスクリーンセーバ処理におい て 2次利用することができる。
バックグラウンド/スクリーンセーバ処理は、 例えば、 プレイヤ制 御モジュール 2 1 2が動作しているが、 エレメン夕リストリームの再 生が行われていない状態、 即ち、 ディスクドライブ 1 0 2 (第 1図） にディスク 1 0 1が挿入されていない状態、 あるいはエレメンタリス トリ一ムの再生が終了した状態となったときなどに行われる。
即ち、 バックグラウンド スクリーンセ一バ処理では、 ステップ S
3 8 1において、 プレイヤ制御モジュール 2 1 2は、 キヤプチャ制御 処理によってメモリ 1 1 3に記憶されたピクチャを表示するように、 グラフィクス処理モジュール 2 1 9を制御する。 グラフィクス処理モ ジュール 2 1 9は、 プレイヤ制御モジュール 2 12からの制御にした がい、 キヤプチャ制御処理によってメモリ 1 1 3に記憶されたピクチ ャを表示させる。
ここで、 グラフィクス処理モジュール 21 9において、 メモリ 1 1 3に記憶されたピクチャを静止画で表示させれば、 いわゆる壁紙（バ ックグラウンド）が実現され、 一定周期で拡大や縮小、 移動等しなが ら表示させれば、 スクリーンセーバーが実現される。 また、 キヤプチ ャ制御処理によってメモリ 1 13に記憶されたピクチャの表示を行う バックグラウンドノスクリーンセーパ処理は、 プレイヤ制御モジユー ル 212ではなく、 他の独立したアプリケーションによって行うこと が可能である。
また、 このときメモリ 1 13に記憶されたピクチャに使用制限を表 すフラグが付加されている場合にはその制限に従う。
以上のように、 ビデオアクセスユニット単位より大きな単位の、 例 えば、 PlayListOや PlayltemOに対応するビデオデータの 2次利用を 許可するか否かを表す、 再生中のビデオデータに対する capture— enab le— flag— PI ayLi stや capture— enable— flag— Clipが取得され、 その cap t ure— enable— flag— PlayListや capture— enable— flag— Clipに基つざ、 再 生中のビデオデータの 2次利用が許可されているか否かが判定される 。 そして、 再生中のビデオデ一夕の 2次利用が許可されていると判定 された場合、 再生中のビデオデ一夕がキヤプチヤされ、 そのキヤプチ ャされたビデオデ一夕を利用したバックグラウンド Zスクリーンセー バ処理が実行される。 従って、 ビデオデータの 2次利用の制御が可能 となる。
なお、 第 44図のキヤプチャ制御処理では、 PlayListO (第 5図） において、 capture enable flag— PlayListを設けるとともに、 Playlt emOによって再生されるクリップストリームファイルに対応するクリ ップ情報ファイル ClipO (第 1 0図） において、 capture— enable— fla g— Ci ipを設け、 その capture— enable— flag— P yLi stと capture— enable 一 flag— Clipとの両方を用いて、 2次利用の許可 （可否） を判定するよ うにしたが、 PlayListO (第 5図） において、 capture_enable— flag_ PlayListを設けるだけか、 または、 Playl temOによって再生されるク リップストリ一ムファイルに対応するクリップ情報ファイル ClipO ( 第 1 0図） において、 capture_enable— flag— Clipを設けるだけにして 、 capture— enable— flag— PlayUstまた ί capture— enable— flag— CI ipの 一方だけを用いて、 2次利用の可否を判定するようにすることも可能 である。
また、 第 44図のキヤプチャ制御処理では、 ステップ S 3 7 6にお いて、 グラフィクス処理モジュール 2 1 9が、 プレイヤ制御モジユー ル 2 1 2からのキヤプチヤの指示にしたがい、 ビデオデコーダ制御モ ジュール 2 1 6からのビデオデータのピクチャ、 即ち、 1つのピクチ ャだけをキヤプチヤするようにしたが、 その他、 複数のピクチャをキ ャプチヤすることも可能である。 つまり、 ビデオデコーダ制御モジュ —ル 2 1 6が出力する時系列の複数のピクチャ （動画としての複数の ピクチャのシーケンス） をキヤプチヤすることが可能である。 この場 合、 一度にキヤプチャされるピクチャの枚数は、 例えば、 あらかじめ 決めておくことができる。 あるいは、 capture— enable— flag_PlayList や capture— enable— flag— Clipのビッ卜を拡張して、 その capture— enab le— flag— PlayListや capture— enable— flag— Clipに、 一度にキヤプチャ 可能なピクチャの枚数の情報を含めるようにしても良い。
さらに、 上述の場合には、 ビデオデ一夕の 2次利用を許可するか否 かの利用許可情報 (capture— enable— flag— PlayList, capture— enable— flag— Clip)を、 PlayListOや、 クリップ情報ファイル CI ip 0に記述し 、 その利用許可情報によって、 PlayListOによって再生されるビデオ データ全体や、 クリップ情報ファイル Clip ()に対応するクリップスト リームファイルに多重化されたビデオストリームに対応するビデオデ —夕全体についての 2次利用の可否を判定するようにしたが、 利用許 可情報は、 その他の任意の単位のビデオデータについて記述し、 その 利用許可情報によって、 任意の単位のビデデータについての 2次利用 の可否を判定することが可能である。
即ち、 第 4 5図は、 利用許可情報が配置された private— stream2—PE S_payload()のシンタクスを示しており、 第 4 6図は、 利用許可情報 が配置された au— information 0のシンタクスを示している。
なお、 第 4 5図の private— stream2— PES— payload 0は、 video— strea m一 idの直前に、 利用許可情報としての capture— enable— flag— ps2が配 置されている他は、 第 2 3図における場合と同様に構成されている。 第 46図の au— iniormationOも、 pic— strucし copyの直前に、 利用許 可情報としての capture— enable— flag— AUが配置されている他は、 第 2 4図における場合と同様に構成されている。
第 45図の private— stream2— PES— payloadOに配置された capture— e nable— f lag— ps2は、 その private— stream2— PES— pay load 0を含む pr iva te— stream— 2の PES— packet 0力、ら、 次の private— stream— 2の PES— packe tOの直前までに配置されるビデオストリームに対応するビデオデ一 夕の 2次利用を許可するか否かを表す。 従って、 第 4 5図の private_ stream2— PES— pay load 0に配置された capture— enable— flag— ps2によれ ば、 あるデコード開始可能点から次のデコ一ド開始可能点までの間の ビデオデータについて、 その 2次利用を許可するか否かを判定するこ とができる。 また、 第 46図の au一 informationOに配置された capture— enable_f lag— AUは、 その capture_enable— flag— AUに対応するビデオアクセスュ ニッ卜のビデオデータの 2次利用を許可するか否かを表す。 従って、 第 4 6図の au—information()に配置された capture— enable— flag— AUに よれば、 ビデオアクセスユニット単位のビデオデータについて、 即ち 、 ピクチャ単位で、 その 2次利用を許可するか否かを判定することが できる。
ここで、 PlayListO (第 5図） における利用許可情報としての capt ure— enable— flag— PlayList、 クリップ情報ファイル CI ip 0 (第 1 0図 ) における利用許可情報としての capture—enableJlag_Clip、 privat e_stream2_PES_payload() (第 4 5図） における利用許可情報として の capture_enable— f lag_ps2， au— information 0 (第 46図） におけ る利用許可情報としての capture—enable— flag— AUは、 そのうちの 2以 上を重複して採用することが可能であり、 この場合、 あるビデオデ一 夕のピクチャの 2次利用の可否は、 その重複して採用される 2以上の 利用許可情報の論理積等に基づいて判定することができる。
また、 第 46図の au— informationOが配置される第 2 3図または第 4 5図の privat e—stream2一 PES— pay load 0を含む privat e— stream— 2の P ES— packet ()は、 第 3 6図のステップ S 2 1 1で説明したように、 バ ッファ制御モジュール 2 1 5 (第 3図） のビデオ読み出し機能部 2 3 3が、 バッファ 2 1 5 Aに記憶されたプログラムストリーム中から探 索する。 従って、 capture— enable_flag一 ps2が配置された第 4 5図の p r i vat e_stream2_PES_pay load 0や、 capture— enable— flag— AUが配置さ れた第 4 6図の au— informationOを採用する場合には、 プレイヤ制御 モジュール 2 1 2は、 ビデオデ一夕の 2次利用の可否を判定するにあ たって、 capture一 enable flag— ps2や capture— enable— flag— AU 、 ヒ デォ読み出し機能部 2 3 3に問い合わせる必要がある。
なお、 本実施の形態では、 上述した一連の処理を、 ソフトウェアに よって行うこととしたが、 上述した一連の処理は、 専用のハードゥエ ァにより行うこともできる。
また、 本実施の形態では、 ビデオデコーダ 1 1 6 (第 1図） として
、 ハードウェアデコ一ダを採用することとしたが、 ビデオデコーダ 1
1 6としては、 ソフトウエアデコーダを採用することも可能である。 オーディオデコーダ 1 1 7 (第 1図） についても、 同様である。
さらに、 本実施の形態では、 字幕デコーダとして、 ソフトウェアデ コ一ダを採用することとしたが、 字幕デコーダとしては、 ハードゥエ アデコーダを採用することも可能である。

Claims

請 求 の 範 囲
1 . 符号化データを処理するデータ処理装置において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニッ 卜単位の符号化ビデオデ一夕と、
前記ビデオデ一夕と同期して出力されるべき出力デ一夕と、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上の デコ一ド開始可能点それぞれの直前に配置される、 前記符号化ビデオ デ一夕のデコードに利用される利用情報と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデ一 夕に対応するビデオデータが、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報を含み、
前記ビデオデータの出力が、 前記出力データの出力よりも遅れてい るか否かを判定する第 1の判定手段と、
前記第 1の判定手段において、 前記ビデオデータの出力が、 前記出 力データの出力よりも遅れていると判定された場合に、 1つのァクセ スュニッ卜の符号化ビデオデータの処理をスキップすることを指示す る指示手段と、
前記指示手段において処理のスキップが指示されたアクセスュニッ トの符号化ビデオデータに対応するビデオデータに対する前記参照情 報に基づき、 そのビデオデータが、 他の符号化ビデオデータのデコ一 ドに参照されるか否かを判定する第 2の判定手段と、
前記第 2の判定手段において、 前記指示手段において処理のスキッ プが指示されたアクセスュニットの符号化ビデオデ一夕に対応するビ デォデ一夕が、 他の符号化ビデオデータのデコードに参照されないと 判定された場合に、 前記指示手段において処理のスキップが指示され たアクセスュニットの符号化ビデオデータの処理をスキップさせるス キップ制御手段と
を備えることを特徴とするデータ処理装置。
2 . 前記第 1の判定手段において、 前記出力データの出力が、 前記ビ デォデ一夕の出力よりも遅れていると判定された塲合に、 前記ビデオ データを繰り返し出力させる出力制御手段をさらに備える
ことを特徴とする請求の範囲 1に記載のデータ処理装置。
3 . 符号化データを処理するデータ処理方法において、
前記符号化データは、
所定の単位のビデオデ一夕を符号化して得られる、 アクセスュニッ ト単位の符号化ビデオデ一夕と、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上の デコ一ド開始可能点それぞれの直前に配置される、 前記符号化ビデオ データのデコードに利用される利用情報と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデ一 夕に対応するビデオデータが、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報を含み、
前記ビデオデ一夕の出力が、 前記出力デ一夕の出力よりも遅れてい るか否かを判定する第 1の判定ステップと、
前記第 1の判定ステップにおいて、 前記ビデオデータの出力が、 前 記出力データの出力よりも遅れていると判定された場合に、 1つのァ クセスユニットの符号化ビデオデータの処理をスキップすることを指 示する指示ステップと、
前記指示ステップにおいて処理のスキップが指示されたアクセスュ ニットの符号化ビデオデータに対応するビデオデータに対する前記参 照情報に基づき、 そのビデオデータが、 他の符号化ビデオデータのデ コードに参照されるか否かを判定する第 2の判定ステップと、 前記第 2の判定ステップにおいて、 前記指示ステップにおいて処理 のスキップが指示されたアクセスュニットの符号化ビデオデー夕に対 応するビデオデータが、 他の符号化ビデオデータのデコードに参照さ れないと判定された場合に、 前記指示ステップにおいて処理のスキッ プが指示されたアクセスュニットの符号化ビデオデ一夕の処理をスキ ップさせるスキップ制御ステップと
を含むことを特徴とするデータ処理方法。
4 . 符号化デ一夕を処理するデータ処理を、 コンピュータに行わせる プログラムにおいて、
前記符号化データは、
所定の単位のビデォデ一夕を符号化して得られる、 アクセスュニッ ト単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上の デコード開始可能点それぞれの直前に配置される、 前記符号化ビデオ データのデコードに利用される利用情報と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデー 夕に対応するビデオデータが、 他の符号化ビデオデータのデコ一ドに 参照されるか否かを表す参照情報を含み、
前記ビデオデータの出力が、 前記出力データの出力よりも遅れてい るか否かを判定する第 1の判定ステップと、
前記第 1の判定ステップにおいて、 前記ビデオデ一夕の出力が、 前 記出力データの出力よりも遅れていると判定された場合に、 1つのァ クセスュニッ卜の符号化ビデオデータの処理をスキップすることを指 示する指示ステップと、
前記指示ステップにおいて処理のスキップが指示されたアクセスュ ニットの符号化ビデオデ一夕に対応するビデオデ一夕に対する前記参 照情報に基づき、 そのビデオデータが、 他の符号化ビデオデ一夕のデ コードに参照されるか否かを判定する第 2の判定ステップと、 前記第 2の判定ステップにおいて、 前記指示ステップにおいて処理 のスキップが指示されたアクセスュニットの符号化ビデオデータに対 応するビデオデータが、 他の符号化ビデオデータのデコ一ドに参照さ れないと判定された場合に、 前記指示ステップにおいて処理のスキッ プが指示されたアクセスュニットの符号化ビデオデータの処理をスキ ップさせるスキップ制御ステップと
を含むことを特徴とするプログラム。
5 . 符号化データを処理するデータ処理を、 コンピュータに行わせる プログラムが記録されているプログラム記録媒体において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニッ ト単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力デ一夕と、 前記アクセスュニッ卜単位の符号化ビデオデ一夕における 1以上の デコード開始可能点それぞれの直前に配置される、 前記符号化ビデオ デ一夕のデコードに利用される利用情報と
を含み、 前記利用情報は、 その利用情報から次の利用情報までの 間に配置されている 1以上の前記アクセスュニットそれぞれの符号化 ビデオデータに対応するビデオデ一夕が、 他の符号化ビデオデータの デコードに参照されるか否かを表す参照情報を含み、
前記ビデオデータの出力が、 前記出力デ一夕の出力よりも遅れてい るか否かを判定する第 1の判定ステップと、
前記第 1の判定ステップにおいて、 前記ビデオデータの出力が、 前 記出力デ一夕の出力よりも遅れていると判定された場合に、 1つのァ クセスュニッ卜の符号化ビデオデータの処理をスキップすることを指 示する指示ステップと、
前記指示ステップにおいて処理のスキップが指示されたアクセスュ ニットの符号化ビデオデータに対応するビデオデータに対する前記参 照情報に基づき、 そのビデオデータが、 他の符号化ビデオデータのデ コ一ドに参照されるか否かを判定する第 2の判定ステップと、 前記第 2の判定ステップにおいて、 前記指示ステップにおいて処理 のスキップが指示されたアクセスュニットの符号化ビデオデ一夕に対 応するビデオデータが、 他の符号化ビデオデ一夕のデコードに参照さ れないと判定された場合に、 前記指示ステップにおいて処理のスキッ プが指示されたアクセスュニットの符号化ビデオデータの処理をスキ ップさせるスキップ制御ステップと
を含むことを特徴とするプログラムが記録されているプログラム記 録媒体。
6 . 符号化デ一夕が記録されているデータ記録媒体において、 前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニッ ト単位の符号化ビデオデータと、
前記ビデオデータと同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデ一夕における 1以上の デコード開始可能点それぞれの直前に配置される、 前記符号化ビデオ デ一夕のデコードに利用される利用情報と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデー 夕に対応するビデオデ一夕が、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報を含む
ことを特徴とするデータ記録媒体。
7 . 符号化デ一夕のデ一夕構造において、
前記符号化データは、
所定の単位のビデオデータを符号化して得られる、 アクセスュニッ ト単位の符号化ビデオデ一夕と、
前記ビデオデ一夕と同期して出力されるべき出力データと、 前記アクセスュニット単位の符号化ビデオデータにおける 1以上の デコード開始可能点それぞれの直前に配置される、 前記符号化ビデオ データのデコードに利用される利用情報と
を含み、
前記利用情報は、 その利用情報から次の利用情報までの間に配置さ れている 1以上の前記アクセスュニットそれぞれの符号化ビデオデー 夕に対応するビデオデ一夕が、 他の符号化ビデオデータのデコードに 参照されるか否かを表す参照情報を含む
ことを特徴とするデータ構造。
PCT/JP2005/010627 2004-06-11 2005-06-03 データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造 WO2005122566A1 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2005010627A JP4320303B2 (ja) 2005-06-03 2005-01-18 ディスク製造用の位置決め装置
US11/570,262 US8107796B2 (en) 2004-06-11 2005-06-03 Data processing device, data processing method, program, program recording medium, data recording medium, and data structure
CA 2569949 CA2569949A1 (en) 2004-06-11 2005-06-03 Data processing apparatus, data processing method, program, program recording medium, data recording medium, and data structure
AU2005253423A AU2005253423B2 (en) 2004-06-11 2005-06-03 Data processing device, data processing method, program, program recording medium, data recording medium, and data structure
MXPA06013877A MXPA06013877A (es) 2004-06-11 2005-06-03 Dispositivo de procesamiento de datos, metodo de procesamiento de datos, programa, medio de grabacion de programa, medio de grabacion de datos, y estructura de datos.
BRPI0511958-8A BRPI0511958A (pt) 2004-06-11 2005-06-03 aparelho e método de processamento de dados, programa, meio de gravação de programa, e, estrutura de dados de dados codificados
EP05748465A EP1761056A4 (en) 2004-06-11 2005-06-03 DATA PROCESSING DEVICE, DATA PROCESSING METHOD, PROGRAM, PROGRAM RECORDING MEDIUM, DATA RECORDING MEDIUM, AND DATA STRUCTURE
KR20067025927A KR101154721B1 (ko) 2004-06-11 2005-06-03 데이터 처리 장치, 데이터 처리 방법 및 기록 매체

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=35503502

Family Applications (1)

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

Country Status (12)

Country Link
US (1) US8107796B2 (ja)
EP (1) EP1761056A4 (ja)
JP (1) JP4606070B2 (ja)
KR (1) KR101154721B1 (ja)
CN (1) CN100563320C (ja)
AU (1) AU2005253423B2 (ja)
BR (1) BRPI0511958A (ja)
CA (1) CA2569949A1 (ja)
MX (1) MXPA06013877A (ja)
MY (1) MY146077A (ja)
TW (1) TW200606829A (ja)
WO (1) WO2005122566A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2009845A1 (en) * 2007-06-07 2008-12-31 Thomson Licensing Method and apparatus for error messaging in a multimedia network
JP6809028B2 (ja) * 2016-08-09 2021-01-06 富士通株式会社 情報処理装置、行動支援プログラムおよび行動支援方法
CN117560501B (zh) * 2024-01-11 2024-04-12 杭州国芯科技股份有限公司 一种多标准视频解码器

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06181569A (ja) * 1992-12-14 1994-06-28 Sony Corp 画像符号化及び復号化方法又は装置、及び画像記録媒体
JPH08251543A (ja) * 1995-03-14 1996-09-27 Victor Co Of Japan Ltd 画像及び音声情報の再生システム
JP2000341640A (ja) * 1999-03-19 2000-12-08 Sony Corp 記録装置および方法、再生装置および方法、並びに記録媒体

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5559999A (en) * 1994-09-09 1996-09-24 Lsi Logic Corporation MPEG decoding system including tag list for associating presentation time stamps with encoded data units
US5594660A (en) * 1994-09-30 1997-01-14 Cirrus Logic, Inc. Programmable audio-video synchronization method and apparatus for multimedia systems
JP3063838B2 (ja) * 1997-10-02 2000-07-12 日本電気株式会社 オーディオ・ビデオ同期再生装置および方法
JP3818819B2 (ja) 1999-02-23 2006-09-06 松下電器産業株式会社 画像符号化方式変換装置、画像符号化方式変換方法および記録媒体

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06181569A (ja) * 1992-12-14 1994-06-28 Sony Corp 画像符号化及び復号化方法又は装置、及び画像記録媒体
JPH08251543A (ja) * 1995-03-14 1996-09-27 Victor Co Of Japan Ltd 画像及び音声情報の再生システム
JP2000341640A (ja) * 1999-03-19 2000-12-08 Sony Corp 記録装置および方法、再生装置および方法、並びに記録媒体

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP1761056A4 (en) 2012-07-04
US20080049138A1 (en) 2008-02-28
KR20070032677A (ko) 2007-03-22
KR101154721B1 (ko) 2012-07-06
US8107796B2 (en) 2012-01-31
MY146077A (en) 2012-06-29
EP1761056A1 (en) 2007-03-07
CN101002466A (zh) 2007-07-18
CN100563320C (zh) 2009-11-25
MXPA06013877A (es) 2007-03-07
JP4606070B2 (ja) 2011-01-05
AU2005253423A1 (en) 2005-12-22
CA2569949A1 (en) 2005-12-22
JP2005354522A (ja) 2005-12-22
BRPI0511958A (pt) 2008-01-22
AU2005253423B2 (en) 2009-10-29
TWI317511B (ja) 2009-11-21
TW200606829A (en) 2006-02-16

Similar Documents

Publication Publication Date Title
TWI263978B (en) Data processing apparatus, data processing method, data processing method of recording medium, data recording medium and data structure of recording medium
WO2005122569A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造
US7584511B2 (en) Data processing apparatus, data processing method, program, program recording medium, data recording medium, and data structure
WO2006059519A1 (ja) データ記録装置およびデータ記録方法、データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、並びにデータ構造
JP2006165704A (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、並びにデータ記録媒体
WO2005122570A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体並びにデータ構造
WO2006059482A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、並びにデータ構造
WO2005122175A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造
WO2005122566A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体、ならびに、データ構造
WO2005122168A1 (ja) データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、データ記録媒体並びにデータ構造
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: PA/a/2006/013877

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 7209/DELNP/2006

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2005748465

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2005253423

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2569949

Country of ref document: CA

Ref document number: 11570262

Country of ref document: US

Ref document number: 1020067025927

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

ENP Entry into the national phase

Ref document number: 2005253423

Country of ref document: AU

Date of ref document: 20050603

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2005253423

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 200580027257.5

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2005748465

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020067025927

Country of ref document: KR

ENP Entry into the national phase

Ref document number: PI0511958

Country of ref document: BR

WWP Wipo information: published in national office

Ref document number: 11570262

Country of ref document: US