WO2006109716A1 - 記録媒体、再生装置、記録方法、再生方法 - Google Patents

記録媒体、再生装置、記録方法、再生方法 Download PDF

Info

Publication number
WO2006109716A1
WO2006109716A1 PCT/JP2006/307441 JP2006307441W WO2006109716A1 WO 2006109716 A1 WO2006109716 A1 WO 2006109716A1 JP 2006307441 W JP2006307441 W JP 2006307441W WO 2006109716 A1 WO2006109716 A1 WO 2006109716A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
time
information
audio
decoder
Prior art date
Application number
PCT/JP2006/307441
Other languages
English (en)
French (fr)
Inventor
Hiroshi Yahata
Tomoyuki Okada
Original Assignee
Matsushita Electric Industrial Co., Ltd.
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37086991&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2006109716(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to EP06731388A priority Critical patent/EP1873775A4/en
Priority to CN2006800111205A priority patent/CN101156209B/zh
Priority to US11/910,249 priority patent/US7991270B2/en
Priority to CA2602713A priority patent/CA2602713C/en
Priority to BRPI0607028-0A priority patent/BRPI0607028A2/pt
Priority to JP2007512969A priority patent/JP4414460B2/ja
Publication of WO2006109716A1 publication Critical patent/WO2006109716A1/ja

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/3027—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording used signal is digitally coded
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • 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
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2508—Magnetic discs
    • G11B2220/2516—Hard disks
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/40—Combinations of multiple record carriers
    • G11B2220/45—Hierarchical combination of record carriers, e.g. HDD for fast access, optical discs for long term storage or tapes for backup
    • G11B2220/455—Hierarchical combination of record carriers, e.g. HDD for fast access, optical discs for long term storage or tapes for backup said record carriers being in one device and being used as primary and secondary/backup media, e.g. HDD-DVD combo device, or as source and target media, e.g. PC and portable player
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/87—Regeneration of colour television signals
    • H04N9/8715—Regeneration of colour television signals involving the mixing of the reproduced video signal with a non-recorded signal, e.g. a text signal

Definitions

  • the present invention belongs to the technical field of the Out-of-MUX framework.
  • the out-of-MUX framework is a digital stream recorded on a read-only recording medium such as a BD-ROM and a local storage that is a rewritable recording medium.
  • the digital stream is read out at the same time, supplied to the decoder, and played back synchronously.
  • the digital stream power recorded on the BD-ROM here constitutes the main part of the movie work, and the digital stream power recorded in the local storage.
  • the main part on the BD-ROM and the commentary on the local storage can be used for playback, and the contents of the BD-ROM can be expanded.
  • the read-only recording medium there are those described in the following patent documents.
  • Patent Document 1 Japanese Patent Application No. 8-83478
  • the stream recorded in the BD-ROM and the stream recorded in the local storage are simultaneously read, and the TS packets constituting those streams are Must be supplied to the decoder.
  • the supply bit rate of these BD-ROM power is 48 Mbps and the supply bit rate from the local storage is 48 Mbps
  • 96 Mbit ( (48Mbit + 48Mbit) Data supply capability There is a possibility that it may occur within the above-mentioned simultaneous reading period. If such a worst case occurs, the bandwidth within the device must be increased so that TS packets can be supplied at a bit rate of 96 Mbps.
  • An object of the present invention is to provide a recording medium that can supply a digital stream supplied from a separate recording medium to a decoder without requiring a high band.
  • the recording medium records playlist information, and the playlist information includes main path information and sub path information, and the main path information includes a plurality of digital information. This is information that designates one of the streams as the main stream and defines the main playback section for that main stream.
  • the sub-path information is information that defines a sub-stream that is to be synchronized with the main playback section by designating another digital stream as a sub-stream.
  • the playlist information includes a stream table, and the stream table includes one or more combinations that are permitted to be played simultaneously among a plurality of elementary streams multiplexed in the main stream and the substream.
  • the stream table the total data size per unit time of the digital stream including the elementary streams that are permitted to be played back simultaneously and not including the elementary streams is permitted. Is characterized by being below a predetermined value.
  • the total data size per unit time of multiple elementary streams is less than or equal to a predetermined value. Even in the worst case, The amount of TS packets to be transferred per unit time does not exceed a predetermined upper limit. For example, if the unit time is 1 second and the predetermined upper limit value is 48Mbit, even if the TS packet supply amount is locally increased to 96Mbit for the simultaneous reading of the stream, "bits per second Because the amount is limited to 48Mbit or less, the worst case 96Mbit data supply will not last more than 0.5 seconds.
  • Pre-reading with an upper limit of “96Mbit X 0.5 seconds” allows TS packets to be stably supplied to the decoder without causing underflow, so simultaneous reading to realize an Out-of-MUX framework
  • the Out-of-MUX framework can be realized, so playback that realizes the Out-of-MUX framework.
  • the device can be supplied to the market at a low price.
  • FIG. 1 is a diagram showing a form of usage of a recording medium according to the present invention.
  • FIG. 2 is a diagram showing an internal configuration of a BD-ROM.
  • FIG. 3 A diagram schematically showing how a file with the extension .m2ts is structured.
  • FIG. 4 is a diagram showing in more detail how video streams and audio streams are stored in a PES packet sequence.
  • FIG. 6 is a diagram showing details of a transport stream.
  • FIG. 7 shows the internal structure of PAT and PMT packets.
  • FIG. 8 This shows how the TS packets that make up an AVClip are written to the BD-ROM.
  • FIG. 9 is a diagram showing an internal configuration of the Aligned Unit.
  • FIG. 10 is a diagram showing an internal configuration of Clip information.
  • FIG. 11 is a diagram showing an EPjnap setting for a movie video stream.
  • FIG. 12 is a diagram showing a data structure of PlayList information.
  • FIG. 13 is a diagram showing the relationship between AVClip and PlayList information.
  • FIG. 14 is a diagram showing an internal configuration of a local storage 200.
  • FIG. 15 is a diagram showing how the primary TS and secondary TS that constitute the Out-of-MUX application are supplied to the decoder in the internal configuration of the BD-ROM playback device.
  • FIG. 16 shows a data structure of PlayList information.
  • FIG. 17 shows a close-up of the internal structure of Subpath information.
  • FIG. 18 is a diagram showing the correspondence between the SubClip on the local storage 200, the PlayList information on the local storage 200, and the MainClip on the BD-ROM.
  • FIG. 19 (a) A diagram showing an internal structure of an STN_table.
  • FIG. 20 A TS packet from which the BD-ROM capability is also read and a TS packet from which the local storage card is also read are shown. Of these TS packets, those supplied to the decoder are shown.
  • FIG. 21 (a) to (d) are diagrams showing window shifts.
  • FIG. 22 is a graph showing the temporal transition of the data amount of TS packets from which BD-ROM power is read and TS packets from which local storage cards are also read.
  • FIG. 24 is a diagram showing a connection state of Playltem and SubPlayltem configuring the Out_of_MUX application.
  • FIG. 4 is a diagram illustrating a relationship between In_Time and Out_Time in SubPlayltem.
  • FIG. 27 is a diagram illustrating how TS1 and TS2 are specified in the MainClip referred to in the previous PlayItem and the SubClip referred in the current Playltem.
  • FIG. 29 is a diagram illustrating a relationship among a plurality of Video Presentation Units, a plurality of Audio Presentation Units specified by previousPlayItem and current Playltem, and an STC time axis. 30] A diagram showing the internal structure of a playback apparatus according to the present invention.
  • FIG. 31 is a flowchart of a playback procedure based on PlayList information.
  • FIG. 32 is a flowchart showing seamless connection in SubPlayItem.
  • FIG. 33 is a diagram showing an internal configuration of an authoring system that is effective in the second embodiment.
  • FIG. 34 is a flowchart showing a verification procedure for a primary TS and a secondary TS.
  • FIG. 37 is a diagram showing a correlation between PlayItem and SubPlayltem.
  • FIG. 38 is a diagram schematically showing how a plurality of TS packets existing on the ATC time axis are multiplexed.
  • FIG. 40 is a diagram illustrating how the primary TS and the secondary TS that configure the audio mixing application are supplied to the decoder in the internal configuration of the BD-ROM playback device.
  • FIG. 41 is a diagram illustrating an internal configuration of a playback device according to a fifth embodiment.
  • FIG. 42 is a diagram showing a correlation between Playltem and SubPlayltem specified in a playlist indicating audio mixing.
  • FIG. 43 A diagram showing an example of PlayList information constituting both the theatrical release version and the director's cut.
  • FIG. 1 is a diagram showing a form of usage of a recording medium according to the present invention.
  • the recording medium according to the present invention is a local storage 200.
  • the local storage 200 is used for supplying movie works to a home theater system including a playback device 300, a television 400, an AV amplifier 500, and a speaker 600.
  • the BD-ROM 100, the local storage 200, and the playback device 300 will be described.
  • the BD-ROM 100 is a recording medium on which movie works are recorded.
  • the local storage 200 is a hard disk that is incorporated in a playback device and is used as a tray for content distributed from a movie distributor's server.
  • the playback device 300 is a network-compatible digital home appliance and has a function of playing back the BD-ROM 100.
  • the content downloaded from the movie distributor's server 700 through the network is stored in the local storage 200, and thus the content recorded in the local storage 200 and the content recorded in the BD-ROM 100 are combined.
  • ROM100 can be expanded / updated. Recording contents of BD-ROM100
  • the technology that treats data that is not recorded on the BD-ROM100 by combining the recorded contents of the local storage 200 as if they were recorded is called “virtual package”.
  • the recording medium according to the present invention can be realized by an improvement on the file system.
  • FIG. 2 shows the internal structure of the BD-ROM.
  • the BD-ROM is shown in the fourth row of this figure, and the tracks on the BD-ROM are shown in the third row.
  • the track in this figure is drawn by stretching the track formed in a spiral shape from the inner periphery to the outer periphery of the BD-ROM in the horizontal direction.
  • This track includes a lead-in area, a volume area, and a lead-out area.
  • the volume area in this figure has a layer model of physical layer, file system layer, and application layer. If the application layer format of BD-ROM (application format) is expressed using the directory structure, it becomes like the first level in the figure. In the first stage, the BD-ROM has a BDMV directory under the Root directory.
  • BDMV directory Under the BDMV directory, there are further three subdirectories called a PLAYLIST directory, a CLIPINF directory, and a STREAM directory.
  • the CLIPINF directory contains files with the extension clpi (00001.clpi, 00002.clpi).
  • FIG. 3 is a diagram schematically showing how the file with the extension .m2ts is configured.
  • Files with the extension .m2ts (00001.m2ts, 00002.m2ts) contain AVClip.
  • the AVClip is a digital stream in the MPEG2-Transport Stream format. In this digital stream, digitized video and digitized audio (upper first stage) are converted into an elementary stream consisting of PES packets (upper second stage), and further converted into TS packets.
  • the video stream, audio stream, PG stream, and IG stream are described below.
  • a video stream is a stream that constitutes a moving image of a movie work, and is composed of a picture data camera that is an SD image or an HD image.
  • video streams such as VC-1 video stream, MPEG4-AVC video stream, and MPEG2-Video video stream.
  • a time stamp such as PTS or DTS is attached to an IDR picture, I picture, ⁇ picture, or ⁇ picture, and playback control is performed in units of this picture.
  • one unit of video stream which is a unit of playback control with PTS and DTS attached, is called “Video Presentation Unit”.
  • An audio stream is a stream that represents the sound of a movie work, and there are formats such as LPCM audio stream, DTS—HD audio stream, DD / DD + audio stream, and DD / MLP audio stream.
  • a time stamp is attached to the audio frame in the audio stream, and playback control is performed in units of the audio frame.
  • one unit of an audio stream which is a unit of playback control with a time stamp attached, is called an “Audio Presentation Unit”.
  • the PG stream is a graphics stream that constitutes subtitles for each language, and there are streams for multiple languages such as English, Japanese, and French.
  • PG stream is PCS (Presentation control Segment) ⁇ PDS (Pallet Define Segment) ⁇ WDS (Window D efine Segment) and ODS (Object Define Segment).
  • 0 DS (Object Define Segment) is a functional segment that defines a graphics object as a caption.
  • WDS Window Define Segment
  • PDS Pallet Define Segment
  • PCS Presentation Control Segment
  • page controls include Cut-In / Out, Fade-In / Out, Color Change, Scroll, and Wipe-1 n / Out, and with the PCS page control, certain subtitles are gradually erased. However, if the next subtitle is displayed, the display effect can be realized.
  • the IG stream is a graphics stream that realizes interactive control.
  • the dialog control defined by the IG stream is a dialog control compatible with the dialog control on the DVD playback device.
  • Powerful I stream ⁇ M ICSQnteractive Composition segment) ⁇ PDS (Palette Difinition Segment), ODS (Object Definition Segment).
  • 0 DS Object Definition Segment
  • PDS Palette Difinition Segment
  • ODS Object Definition Segment
  • 0 DS Object Definition Segment
  • PDS Palette Difinition Segment
  • the ICSOnteractive Composition Segment is a functional segment that realizes a state change in which the state of the button is changed in response to a user operation.
  • the ICS contains a button command to be executed when a confirm operation is performed on a button.
  • the AVClip is composed of one or more “STC_Sequence”.
  • STC_Sequence refers to an interval in which there is no STC (System Time Clock) discontinuity point, which is the system reference time of the AV stream.
  • the discontinuity of STC is that the discontinuity information (discontinuityjndicator) of the PCR packet carrying the PCR (Program Clock Reference) that the decoder refers to obtain the STC is ON.
  • Fig. 4 shows how a video stream and an audio stream are stored in a PES packet sequence. It shows in more detail whether it is delivered.
  • the first level in the figure shows the video stream, and the third level shows the audio stream.
  • the second row shows the PES packet sequence.
  • IDR, B picture, and P picture which are multiple Video Presentation Units in the video stream, are divided into multiple parts, and each divided part is a PES packet. It can be seen that it is stored in the payload (V # 1, V # 2, V # 3, V # 4 in the figure).
  • Audio frames that are Audio Presentation Units that make up an audio stream are stored in the payloads of individual PES packets (A # l and A # 2 in the figure) as shown by arrows aal and aa2. I can tell you.
  • FIG. 5 shows how a video game is multiplexed with a video stream and a transport stream.
  • the lower row shows multiple PES packets (V # 1, V # 2, V # 3, V # 4, A # 1, A # 2 in the figure) that store the video stream and audio stream. From the figure, it is important that the video stream and audio stream are stored in separate PES packets.
  • the upper row shows the program stream and transport stream that store the lower PES packets. When multiplexed into a program stream, PES packets are contained in one pack. When multiplexed into a transport stream, the PES packet is divided and each divided part is stored in the payload of multiple TS packets.
  • the storage method in BD-ROM is the latter transport stream, not the former program stream. Although this is not the case in Fig. 5, the video PES packet used for the transport stream generally stores one frame or two pairs of fields.
  • FIG. 6 is a diagram showing details of the transport stream.
  • the first level in this figure is a plurality of TS packet sequences that make up the MPEG2 transport stream, and the second level shows the internal structure of the TS packet.
  • one TS packet is also composed of a “header”, an “adaptation field”, a “payload”, and a force.
  • the lead line thl closes up the structure of the TS packet header.
  • a “start start indication payload_unit_start_indicator” indicating that the head of the PES packet is stored, an element multiplexed in the transport stream.
  • PID Packet Identifier
  • the lead-out line th2 closes up the internal configuration of the application field.
  • the application field is given to the TS packet when the application field control of the TS packet header is set to " ⁇ . Specifically, it must be the beginning of the video and audio frame and the entry point.
  • Random access display random_access_indicator
  • PCR Program Clock Reference
  • FIG. 7 is a diagram showing an internal configuration of the PAT and PMT packets. These packets describe the program structure of the transport stream.
  • a TS packet is called a PAT (Program Association Table) packet and indicates the program structure of the entire transport stream.
  • the PID of the PAT packet is always “0”.
  • a PAS Program Association Section
  • Leader line hm2 closes up the internal structure of PAS. As shown in this leader line, PAS shows program_number (number and number) and program map table (PMT PID) in association with each other.
  • Powerful TS packets are called PMT packets.
  • the PMS of the PMT packet includes “stream_type” indicating the stream type included in the program corresponding to the PMS and “elementary_PID” which is the PID of the stream.
  • Figure 8 shows the process by which TS packets that make up an AVClip are written to the BD-ROM.
  • the TS packet that constitutes the AVClip is shown in the first row of the figure.
  • the 188-byte TS packet that constitutes the AVClip is appended with a 4-byte TS_extr ajieader (hatched portion in the figure) as shown in the second row, and becomes a 192-byte long Source packet.
  • This TS_extra_header includes Arrival_Time_Stamp indicating the decoder input time information of the TS packet.
  • an ATS header is added to each TS packet to form a stream is to provide an input time to the decoder (STD) for each TS packet.
  • STD decoder
  • the transport stream is treated as a fixed bit rate. Therefore, a transport stream with a fixed bit rate is broadcast by multiplexing dummy TS packets called NULL packets.
  • the recording method with a fixed bit rate is inconvenient because it consumes a capacity wastefully. Therefore, NULL packets are not recorded on BD-ROM.
  • the ATS is added to each TS packet and the transport stream is recorded. By using this ATS, it is possible to restore the decoder input time for each TS packet and to support a variable bit rate recording method.
  • one set of ATS header and TS packet is called a source packet.
  • the Source packet that constitutes the AVClip constitutes one or more "ATC_Sequence" in the AVClip in the third level.
  • ATC_Sequence refers to an array of Source packets that do not have, consecutive arms ⁇ no arnv al time-base discontinutiy) in the Arrival- Time- Clock that is referred to. Say. If it is good, the source packet sequence that has continuity in the Arrival_Time_Clock referenced by the ArrivaLTime_Stamp is "ATC—Sequence"! Uh.
  • the ATC_Sequence becomes an AVClip and is recorded on the BD-ROM with the file name xxxxx.m2ts.
  • Such an AVClip is divided into one or more file extents and recorded in an area on the BD-ROM, like a normal computer file.
  • the fourth row shows how the AVClip is recorded on the BD-ROM.
  • Each file extent constituting the file in the fourth stage has a data length equal to or greater than a predetermined Sexetent.
  • Taccess is the time given according to the jump distance (distance of physical address to jump).
  • TS packets from which the BD-ROM power is also read are stored in a buffer called a read buffer, and then output to the decoder.
  • the input power to the read buffer is the bit rate of Rud.
  • the number of sectors in the ECC block is set to Secc. If
  • the TS packet from which the BD-ROM capability is also read is stored in the read buffer in the state of the source packet, and then supplied to the decoder at a transfer rate of TS_Recording_rate.
  • the TS packet output from the read buffer to the decoder needs to continue during Tjump.
  • the output from the read buffer is made in the state of the source packet that is not the TS packet, so if the size ratio of the TS packet to the source packet is 192/188, during the Tjump, (192/188 X TS_Recording_rate) Therefore, the source packet output from the read buffer must be continued.
  • Tx Boccupied / (Rud— TS— Recording— rate X (192/188))
  • Each file extent that constitutes an AVClip has a data length that is greater than or equal to the Sextent calculated so as not to cause underflow of the decoder, so that each file extent that constitutes an AVClip is discretely stored on the BD-ROM. Even if it is positioned, TS packets are continuously read out without interrupting the TS packet supply to the decoder during playback.
  • the file extent described above is configured with an aligned unit (aligned unit, 6 KByte data size) obtained by collecting 32 Source packets as a minimum unit. Therefore, the file size of a stream file (XXXXX.AVClip) on BD is always a multiple of 6KByte.
  • FIG. 9 shows the internal structure of the Aligned Unit.
  • An Aligned Unit consists of 32 Source packets and is written in three consecutive sectors.
  • Each BD-ROM sector has an error correction code in 32 units. Configure the ECC block.
  • the playback device can obtain 32 complete source packets as long as the BD-ROM is accessed in units of aligned units.
  • the above is the process of writing AVClip to the BD-ROM.
  • An AVClip that is recorded on a BD-ROM and multiplexed with a high-quality video stream is referred to as “MainClip”.
  • an AVClip that is recorded in local storage and played at the same time as the MainClip is called a “SubClip”.
  • a partial transport stream is obtained by demultiplexing the MainClip recorded on the BD-ROM. This partial transport stream corresponds to each elementary stream.
  • a partial transport stream obtained by demultiplexing the MainClip and corresponding to one elementary stream is called a “primary TS”.
  • FIG. 10 shows the internal structure of Clip information. As shown on the left side of this figure, Clip information is
  • Cliplnfo has an application type (application_type) of AVClip referred to by this Clip information.
  • application_type application type of AVClip
  • TS_recording_rate described above is described!
  • Sequence Infoi AVClip [This is one information on 3 ⁇ 4i, C—3 ⁇ 4equence, AT and Sequenced on W. The significance of providing such information is to notify the playback device in advance of STC and ATC discontinuities. In other words, if such discontinuities exist, the same value of PTS and ATS may appear in the AV Clip, causing inconvenience during playback. STC and ATC are continuous from anywhere in the transport stream. Sequence Info is provided to indicate whether it exists.
  • Program Info is information indicating a section (Program Sequence) in which Program content is constant.
  • a program is a collection of elementary streams that share the time axis for synchronized playback.
  • the significance of providing Program Sequence information is to notify the playback device in advance of changes in Program content.
  • the program content changes here are the points where the PID of the video stream changes or the video stream type changes from SD to HD images! Uh.
  • leader cu2 in the figure closes up the CPI configuration.
  • the CPI consists of Ne EP_map—for—one—stream—PID (EP—map—for—one—stream—PID [0] ⁇ EP—map—for—one—stream— PID [N e-1]).
  • EP_map_for_one_stream_PIDs are EP_maps for individual elementary streams belonging to the AVClip.
  • EP_map is information indicating the packet number (SPN_EP_start) of the entry position where the Access Unit exists on one elementary stream in association with the entry time (PTS_EP_start).
  • Lead line cu3 in the figure closes up the internal structure of EP_map_for_one_stream_PID.
  • EP_map_for_one_stream_PID includes Nc EP_High (EP_High (0) to EP_High (Nc-1)) and Nf EP ⁇ ow (EP ⁇ ow (0) to EP ⁇ ow (Nf-l
  • EP—High has the role of representing the upper bits of SPN—EP—start and PTS—EP—start of the Access Unit (Non-IDR I picture, IDR picture).
  • ow has a role indicating the lower bits of SPN_EP_start and PTS_EP_start of Access Unit (Non-IDR I picture, ID R picture).
  • EP_High (i) is the reference value for EP ⁇ ow “ref_to_EP ⁇ ow_id [i]” and the upper bits of PTS of Access Unit (Non-IDR I picture, IDR picture) “PTS_EP_High [i]” indicating “SPN_EP_High [i]” indicating the upper bits of the SPN of the Access Unit (Non-IDR I picture, IDR picture).
  • i is an identifier for identifying any EP_High.
  • EP ⁇ ow is “is_angle” indicating whether the corresponding Access Unit is an IDR picture or not.
  • EP ⁇ owjd is an identifier for identifying an arbitrary EP ⁇ ow.
  • Figure 11 shows the EPjnap settings for a movie video stream.
  • the first row shows multiple pictures arranged in the display order (IDR picture, I picture, B picture, P picture specified in MPEG4-AVC), and the second row shows the time axis of the picture. Show.
  • the fourth row shows the TS packet sequence on the BD-ROM, and the third row shows the EPjnap setting.
  • a file with the extension “mpls” (0000 1.mpls) is a file storing PlayList (PL) information.
  • FIG. 12 is a diagram showing the data structure of the PlayList information.
  • the PlayList information defines MainPath information (MainPathO) that defines MainPath and chapters. Includes PlayListMark information (PlayListMarkO).
  • MainPath is a playback path defined for the video stream that is the main video.
  • MainPath is defined from a plurality of Playltem information # 1 ⁇ '#m as indicated by an arrow mpl.
  • Playltem information defines one logical playback section that composes MainPath. Playltem The structure of the information is highlighted by the lead line hsl. As shown in this leader line, the Playltem information includes “ClipJnformation_file_name” indicating the file name of the playback section information of the AVClip to which the IN point and Out point of the playback section belong, “Clip_codec_identifier” indicating the encoding method of the AVClip, “Is_mult i—angle” indicating whether the Playltem forms a multi-angle, “connection_condition” indicating the connection status between this Playltem (current Playltem and its first PlayItem (previousPlayItem)), and this Playltem The target is!
  • FIG. 13 is a diagram showing the relationship between AVClip and PlayList information.
  • the first level shows the time axis of the PlayList information (PlayList time willow.
  • the second to fifth levels show the bidet stream that is referred to by EPjnap!
  • PlayList information includes Playltem information # 1, # 2 and! 2 and other Playltem information, and two playback sections are defined by the In_time and Out_time of these Platform information # 1, # 2. .
  • a time axis different from the AVClip time axis is defined. This is the PlayList time axis shown in the first row.
  • FIG. 14 is a diagram showing an internal configuration of the local storage 200.
  • the recording medium according to the present invention can be produced by improving the application layer.
  • the local storage 200 is shown in the fourth level of the figure, and the tracks on the local storage 200 are shown in the third level.
  • the track in this figure is drawn by extending the track formed in a spiral shape from the inner periphery to the outer periphery of the local storage 200 in the horizontal direction.
  • This track consists of a lead-in area, a volume area, and a lead-out area.
  • the volume area in this figure has a layer model of physical layer, file system layer, and application layer.
  • PlayList information which are constituent elements of the local storage 200, will be described.
  • AVClip (00003.m2ts, 00004.m2ts) on the local storage 200 constitutes a SubClip.
  • a partial transport stream can be obtained by demultiplexing the SubClip.
  • a partial transport stream obtained by demultiplexing a SubClip is called a “secondary TS”.
  • the powerful secondary TS constitutes the Out_of_MUX application.
  • the Out_of_MUX application will be described.
  • Out-of-MUX applications are, for example, two TSs: a primary TS on the BD-ROM and a secondary TS that is acquired via the network and recorded in the local storage. Is an application that enables various elementary streams to be combined between the two TSs by simultaneously selecting and playing.
  • FIG. 15 is a diagram showing how the primary TS and the secondary TS configuring the Out-of-MUX application are supplied to the decoder in the internal configuration of the BD-ROM playback device.
  • the BD-ROM drive device, simple storage, and network part are shown on the left side, and the decoder is shown on the right side.
  • the PID Filter that performs demultiplexing of streams is shown in the middle.
  • the primary TS (Vide 01.Audio 1 (English), Audio2 (Spanish), PG 1 (English Subtitle), IG1 (English Menu)) ⁇ Secondary TS (Audio2 (Japanese), Audio3 (Korean), PG2 (Japanese Subtitle), PG3 (Korean Subtitle), IG20apanese Menu), and IG3 (Korean Menu)) indicate the transport streams supplied from the BD-ROM and local storage, respectively. Since only the English (Audio 1) and Spanish (Audio 2) are recorded on the disc itself, this datum cannot be selected for dubbing in Japanese.
  • Japanese menu screen (IG 2) can be sent to the decoder. This allows the user to select Japanese dubbed audio (Audio 2) and Japanese subtitles (PG 2) from the Japanese menu screen (IG 2) and play along with the video (Videol). it can.
  • Out-of-MUX application is available for each type of elementary stream stored in two TSs that are played back simultaneously (in other words, video stored in the primary TS and secondary TS). Users can freely select audio and subtitles under the restrictions of 1 audio, 1 audio, 1 subtitle, and 1 menu.
  • All BD-ROM playback devices have the ability to decode the primary TS alone. There is no ability to decode two TSs simultaneously. Therefore, when an out-of-MUX application is installed without restrictions, it is necessary to add a large amount of hardware and software, which leads to an increase in the cost of the BD-ROM playback device. Therefore, the key to realizing an Out-of-MUX application is whether an Out_of_MUX application can be realized on a resource that can only decode the primary TS. [0052]
  • the restriction that playback is allowed for each type of elementary stream can be considered as "replacement" of the elementary stream of the primary TS with the elementary stream of the secondary TS.
  • an Out_of_MUX application can be realized on a resource for decoding one TS, and an increase in cost on the decoder side can be suppressed.
  • the audio, subtitle (PG), and menu (IG) stream of the primary TS are replaced with those of the secondary TS! /.
  • the secondary TS may also receive a force such as flash memory, primary storage memory, HDD over the network, or streaming via a direct network.
  • a force such as flash memory, primary storage memory, HDD over the network, or streaming via a direct network.
  • the secondary TS is supplied from a built-in HDD as shown in FIG.
  • Clip information (00003.clpi, 00004.clpi) existing on the local storage basically has the same data structure as that recorded on the BD-ROM.
  • TS_Recording_Rate of Clip information on the local storage is set to the same bit rate as AVClip reading from the BD-ROM. That is, TS_Recording_Rate described in Clip information of SubClip and TS_Recording_Rate described in Clip information of MainClip are the same. If the TS_Recording_Rate value of the MainClip and the TS_Recording_Rate of the SubClip are different, the data rate from each Source De-packetizer until it is sent to the buffer differs depending on which TS is sent. The assumption that an of-MUX application can assume one input TS is no longer valid.
  • the elementary stream to be played between the two TSs can be freely selected, if the audio of the primary TS is selected, the power from the source de-packetizer to the buffer in the decoder is used.
  • the bit rate for the secondary TS is set from the Source De-packetizer to the buffer in the decoder. It becomes complicated.
  • PlayList information on the local storage 200 is information that defines a bundle of two types of playback paths called MainPath and Subpath as Playlist (PL).
  • Fig. 16 shows the data structure of PlayList information.
  • PlayList information consists of MainPath information (MainPathO) that defines MainPath, PlayListMark information (PlayListMark (;)) that defines chapters, and Subpath information (SubpathO) that defines Subpaths.
  • MainPathO MainPath
  • PlayListMark information PlayListMark (;)
  • SubpathO Subpath information
  • the internal structure of the PlayList information and the internal structure of the Playltem information are the same as those of the BD-ROM, and will not be described.Subpath information will be described below.
  • MainPath is the playback path defined for the main video MainClip
  • Subpath is the playback path defined for the SubClip to be synchronized with MainPath.
  • FIG. 17 shows a close-up of the internal structure of the Subpath information.
  • the Subpath information includes SubPath_type indicating the type of SubClip and one or more SubPlayltem information (... SubPlayltemO...
  • the lead line hcl in the figure closes up the structure of the SubPlayltem information.
  • the SubPl ayltem information is “Clip jnformation_file_name”, “Clip_code c—identifier”, “SP—connection—condition”, “ref—to—3 ⁇ 4 f C—id [0]”, [ It consists of “SubPlayltem—In—time”, “SubPlayItem—Out—time”, “sync—Playltem—id”, and “sync—start—PTS—of—Playltem”.
  • “Clip_information_file_name” is information for uniquely specifying a SubClip corresponding to SubPlayltem by describing a file name of Clip information.
  • “Clip_codec_identifier” indicates an AVClip encoding method.
  • SP—connection—condition indicates the connection state between this SubPlayltem (current SubPlayltem) and the previous SubPlayltem (previous SubPlayltem).
  • SubPlayItem_In_time is information indicating the start point of SubPlayltem on the playback time axis of SubClip.
  • SubPlayItem_Out_time is information indicating the end point of SubPlayltem on the playback time axis of SubClip.
  • “sync_PlayItem_id” is information for uniquely designating the Playltems constituting the MainPath that should be synchronized with this SubPlayltem.
  • SubPlayltem-In-time exists on the playback time axis of the PlayItem specified by sync-Playltem-id.
  • Sync_start_PTS_of_PlayItem indicates where the starting point force of the SubPlayltem specified by SubPlayItem_In_time exists on the playback time axis of the PlayItem specified by sync_PlayItem_id.
  • FIG. 18 is a diagram showing the correspondence between the SubClip on the local storage 200, the PlayList information on the local storage 200, and the MainClip on the BD-ROM.
  • the first row shows the SubClip that exists on the local storage 200.
  • the secondary TS in the SubClip on the simple storage 200 has types such as an audio stream, a PG stream, and an IG stream. Any of these will be used for synchronized regeneration as SubPath.
  • the second level shows two time axes defined by PlayList information.
  • the lower time axis indicates the PlayList time axis defined by Playltem information
  • the upper time axis indicates the SubPlayltem time axis defined by SubPlayltem.
  • SubPlayltem-Clip-information-file-name of SubPlayltem information stores SubClip. It plays the role of SubClip selection, which of the m2ts files to select as the target of the playback section. I understand.
  • SubPlayItem.IN_time and SubPlayltem.OuUime play the role of defining the start and end points of the playback section on the SubClip.
  • the arrow Sync_PlayItem_Id is intended to synchronize with any Playltem! /, And plays the role of specifying synchronization, and sync_start_PTS_of_PlayItem plays the role of determining the position of SubPlayltem Jn_time on the PlayList time axis.
  • STN_Table that is characteristic in the PlayList information on the local storage 200.
  • PlayList information on the local storage 200 will be described.
  • STN_table is played simultaneously among multiple elementary streams multiplexed in MainClip specified by Clip_Information_file_name of Playltem information and multiple elementary streams multiplexed in SubClip specified by Clipjnformation_file_name of SubPlayltem information.
  • STN_Table in the PlayList information multiple elementary streams that are allowed to be played simultaneously constitute a so-called “system stream”.
  • STN_table is a plurality of elementary streams that are multiplexed in MainClip, each elementary stream that is multiplexed in SubClip! /, And Stream_entry that is Composed by associating with Stream_attribute.
  • Fig. 19 (a) shows the internal structure of STN_table.
  • STN_table includes multiple entry-attribute combinations of entry and attribute in STN_table, and the number of thread entries of these entry—attrioute (number—of—video—stream—entries, number —Of—audio—strea m—entnes, number—of—Ptj—stream—entries, number—of—IG—stream—entries).
  • the entry-attribute pair corresponds to each of the video stream, audio stream, PG stream, and IG stream that can be played in the Play Item, as indicated by the bracket symbol " ⁇ " in the figure. .
  • FIG. 19 (b) is a diagram showing Stream_attribute corresponding to the video stream.
  • Stream_attribute in the video stream includes “Video_format” indicating the display method of the video stream, “frame_rate” indicating the display frequency of the video stream, and the like.
  • FIG. 19 (c) is a diagram showing Stream_attribute corresponding to the audio stream.
  • Stream_attribute in the audio stream corresponds to “stream—coding—type” indicating the encoding method of the audio stream, “audio_presentation_type” indicating the channel configuration of the corresponding audio stream, and corresponding sampling frequency of the audio stream.
  • “Sampling_frequency” and “au” indicating the language attribute of the audio stream diojanguage code "force also Q
  • FIG. 19 (d) is a diagram showing Stream_entry in the video stream. As shown in this figure, the Stream_entry of the video stream is the PI used for video stream demultiplexing.
  • the Stream_attribute of the audio stream, IG stream, and PG stream multiplexed by MainClip is the open type shown in Fig. 19 (d).
  • STN_table indicates the elementary streams that are read from the BD-ROM and the elementary streams that are read from the local storage.
  • the STN_table indicates that the playback is permitted, but the STN_table allows unlimited playback of the elementary streams. If this happens, the decoder system may fail.
  • the decoded elementary stream is a video stream, an audio stream, a PG stream, and an IG stream that are selected for reproduction in the STN_table and are reproduced together.
  • Decoded elementary streams include both those that are read from local storage and those that also read BD-ROM capabilities.
  • the restriction imposed on the decoded elementary stream is that an AVClip (MainClip that does not include an elementary stream that is allowed to be played back simultaneously in the STN_table and includes an elementary stream that is allowed to be played back.
  • SubClip TS packet (Decodin g TS packet) is 48Mbit or less per second.
  • Window This unit time of 1 second is called “Window” and is placed at any position on the time axis of ATC Sequence.
  • the bit amount in the decoded elementary stream must satisfy the condition of 48 Mbit or less in any 1-second period.
  • FIG. 20 shows a TS packet read from the BD-ROM and a TS packet also read from the local storage camera, and shows those TS packets supplied to the decoder.
  • the first row in the figure shows the multiple TS packets from which the BD-ROM power was also read
  • the third row shows the multiple TS packets from which the local storage was also read.
  • hatched ones are TS packets (Decoding TS packets) that constitute a decoded elementary stream.
  • the second row in the figure shows the one belonging to the period of 1 second among the Decoding TS packet shown in the first row and the Decoding TS packet shown in the third row.
  • the MPEG2 decoder system standard there should be no overlap between TS packets on the ATC time axis in one transport stream.
  • the overlap rpl, rp2, rp3 between TS packets occurs on the ATC time axis.
  • overlapping of TS packet operations is allowed in a unit time called Window.
  • the fourth level expresses the conditions that the Decoding TS packet shown in the second level should satisfy. The meaning of this formula is that the number of Decoding TS packets mentioned above is converted into the number of bits (multiply 188, which is the number of bytes in the TS packet, and expressed as 8 bits), and the power is 48Mbit or less. .
  • the ability to impose the above conditions on the Decoding TS packet in an arbitrary period of 1 second is the limitation on the bit amount in this embodiment.
  • the Source packet sequence check whether the window is shifted by one packet at a time while checking whether it is capable of satisfying the limit of 48Mbit or less in the number of bits of Decoding TS packet within a period of 1 second. . If the restriction is satisfied, the window is shifted to the next TS packet, and if the restriction is not satisfied, it is determined that the BD-ROM standard is violated. And, as a result of repeating the powerful shift, the Out_Time of the Window becomes the last Source packet. If it reaches, the source packet is determined to conform to the BD-ROM standard.
  • Each TS packet is given an ATS with a time accuracy of 27 MHz.
  • the coordinates on the ATC time axis are forces with time accuracy of 1 / 27,000,000 seconds.
  • ATS does not always exist at each coordinate on the ATC time axis.
  • On the ATC time axis there are irregular periods in which there is no ATS or in which ATS exists. Since there are variations in the appearance of ATS, when shifting the window, if there is no ATS after 1 second from In_Time, how to adjust the Out_Time of Windows will be a problem.
  • the Out_Time of the Window is set as 1 second of In_Time in principle.
  • the coordinate of In_Time + 1 second is set as Out_Time.
  • Out_Time is the coordinate of the ATC time axis where ATS appears for the first time after In_Time + l seconds. Since the Window is shifted while adjusting the Out_Time while considering the blank period of the ATS, a different bit value is calculated each time the Window is shifted. By shifting In_Time by ITS packets and adjusting Out_Time accordingly, the transition of bit values on the ATC time axis can be calculated precisely.
  • FIG. 21 is a diagram showing window shift.
  • the upper row shows the source packet sequence to be verified, and the lower row shows Window In_Time and Out_Time.
  • In_Time of Window designates Source packet ffi.
  • the TS packet 'that exists one second after this Windows In_Time is set as the Out_Time of the Window.
  • the In_Time of the Window specifies the Source packet ffi + 1.
  • the ATS of the Source packet does not exist at the coordinates corresponding to the Source packet ⁇ +1 one second after In_Time of this Window.
  • the Out_Time of Window in (b) exceeds TS packet ', but since there is no Source packet immediately after TS packet ⁇ , the bit rate in Window of (b) is the Window rate of (a). It will be less than the bit rate in. This makes the window in (b) not worth checking. Therefore, by adjusting Out_Time, TS packet +2 that appears for the first time after 1 second from In_Time of Window is changed to 0 of Window. Set to ut_Time. If Out_Time is set in this way, the window in (b) is worth checking.
  • the In_Time of the window specifies the source packet ffi + 2! /.
  • Source packet +2 is located 1 second after In_Time of this Window.
  • the window in (c) is not worth checking because the number of TS packets is the same as in (b) Window. Therefore, in (c), the check is not performed and the In_Time of the window is further advanced.
  • Source packet ffi + 3 is specified for In_Time of Window.
  • the Out_Time is adjusted as described above, and the TS packet +4 that appears for the first time after 1 second of the Window In_Time is defined as the Window Out_Time. This makes the number of TS packets in the window different from (b) and is worth checking.
  • the first stage in FIG. 22 is a TS packet read from the BD-ROM and a TS read from the local storage. It is a graph which shows the time transition of the data amount of a packet. The horizontal axis is the time axis, and the vertical axis shows the transfer amount at each point on the time axis. In this graph, the amount of bits when reading from the BD-ROM and local storage changes as shown by the dashed curve.
  • the second tier in FIG. 22 shows the total data amount of the TS packets read from the BD-ROM and the TS packets read from the local storage that are supplied to the decoder.
  • the time transition of the total transfer amount is as shown by the solid curve.
  • This total data amount is the total amount of TS packets belonging to the streams permitted by STN_table. In the worst case, the total transfer amount is close to 96 Mbit, and it is considered that TS packets with this data amount will be supplied.
  • the time axis of the graph is divided into seven windows, and the supply amount in each window is compared with the transfer allowance for each window.
  • the third row in FIG. 22 is a graph in which the graph in the second row in FIG.
  • FIG. 6 is a diagram showing the amount of supply to a decoder in a window in comparison.
  • the transfer capacity in the window is 48M bits per second, which is 96Mbit when converted to 0.5 seconds.
  • the hatched pattern pnl in the figure indicates the amount of data supplied to the decoder.
  • the hatched pattern pn2 in the figure indicates the transfer capacity per window. Area force of the hatched part of the pattern pnl In any Windows, it is less than the area of the hatched part of the pattern pn2. This means that the amount of data supplied from the BD-ROM and local storage is kept below the allowable transfer amount in any window.
  • the transfer capacity to the decoder per second is 48 Mbit or less, so even if locally, the transfer capacity to the decoder is close to 96 Mbit.
  • 48Mbit 96Mbit X 0.5 seconds
  • a powerful 96Mbit transfer cannot be continued for 0.5 seconds. Therefore, if the decoder pre-reads from the local storage to the BD-ROM before this peak arrives, there will be no underflow or overflow of the decoder buffer.
  • the transfer allowable amount in the window that is, the value of 48 Mbit per second is determined based on a value that can be pre-read by a decoder-powered non-standard MPEG-compliant notifier.
  • the amount of data that can be prefetched into the buffer is larger, the amount of data per second can be further increased, and the window length can be further increased. For this reason, the numerical range used in the present invention should not be limited to 48 Mbit per second.
  • the sp_connection_condition information described in SubPlayltemfti can be defined as follows.
  • SP—CC connection—condition information
  • FIG. 24 is a diagram illustrating a connection state of Playltem and SubPlayltem configuring Out_of_MUX.
  • the first level in this figure is the SubClip time axis
  • the second level and the third level are the SubPlaytime time axis and the PlayList time axis.
  • the fourth level is the MainClip time axis.
  • the connection—condition information on the SubPlayltem side, SP—and C 5.
  • connection state power CC on the Playltem side is set to 5
  • Sync_Start_Pts_of_PlayItem in SubPlayltem indicates the same time point as In_Time of Playltem.
  • In_Time and Out_Time in SubPlayltem represent the same time as In_Time and Out_Time of Playltem.
  • Playltem In_Time and Out_Time are SubPlayltem In_Time
  • Out_Time Represents the same point in time.
  • PlayIntem In_Time, Out_Time, SubPlayltem In_Time, and Out_Time refer to the PTS of the Video Presentation Unit and Audio Presentation Unit, respectively.
  • In_Time and Out_Time of Playltem matches the In_Time and Out_Time of SubPlayltem is referred to by In-Time and Out-Time of Pla- temtem.
  • Video Presentation Unit, Audio Presentatio This means that the PTS value of n Unit is the same as the PTS value of the Video Presentation Unit and Audio Presentation Unit referenced by In_Time and Out_Time of SubPlayltem.
  • Figure 26 shows the STC value that should be referenced when playing the part existing from In_Time to Out_Time of Playltem, and the STC value that should be referenced when playing the part existing from In_Time to Out_Time of SubPlayltem. Show.
  • the second and third stages are the same as those shown in the previous figure.
  • the first level shows the STC value to be referred to in the graph format when playing the portion of SubPlayltem from In_Time to Out_Time.
  • the fourth row also shows the STC value to be referred to in the form of a graph when playing the part existing from Play_time In_Time to Out_Time.
  • the horizontal axis in the first row is the time axis, and the vertical axis represents the STC value at each time point on the time axis.
  • the STC value in the first row consists of the monotonic increase Uzkl in the period from In_Time to Out_Time in SubPlayltem information # 1, and the monotonically increasing calo zk2 in the period from In_Time to Out_Time in SubPlayltem information # 2.
  • the STC value in the 4th row consists of monotonically increasing zk3 in the period from Play_tem information # 1 In_Time to Out_Time, and monotonically increasing calo zk4 in the period from Play_tem information # 2 In_Time to Out_Time.
  • the initial value of the STC is the same in the above-described graph, and is the same at an intermediate time.
  • STC2G which is the STC value to be referred to
  • STCl (i) which is the STC value to be referenced.
  • the STC counter in the apparatus may generate the same clock value and supply it to the demultiplexing unit, thereby simplifying the control in the reproducing apparatus.
  • the video and audio may be interrupted at the SubPlayltem boundary. Inconveniences such as paused playback during playback. Also, when implementing the process of replacing the primary TS with the secondary TS in the Out-of-MU X application, it is necessary to switch the STC time axis before and after this replacement, which complicates the synchronization control in the playback device. To do.
  • the STC time for Playltem In_Time and Out_Time is set by Playltem for the video frame.
  • SubPlayltem is set for audio frames. This is because SubPlayltem is mainly used for commentary, and video streams are often not multiplexed. In this case, strictly speaking, the start / end times do not match due to the difference in the playback time length of each presentation unit. Therefore, it is necessary to allow an error of less than one frame at a minimum. Playltemfti and SubPlayltemfti start / end times are both on the same STC time axis.
  • the value on the left side may be 1 progressive frame of video with the longest playback time in Playltemfti or 2 interlaced field playback time ( ⁇ 1/25 seconds), or less than 1 second.
  • connection-condition ⁇ blueprint and sp-connection-condition ⁇ blueprint will be explained in detail.
  • the AV stream level, transport stream level, video presentation unit and audio presentation unit level, and elementary stream level are as follows: The conditions described must be met.
  • FIG. 27 is a diagram showing how TS1 and TS2 are specified in the AVClip referred to in previousPlayItem and previousSubPlayltem, and in the AVClip referred to in the current PlayPlaytem and current SubPlayltem. .
  • the fourth row in the figure shows the primary TS1 and the primary TS2, and the third row shows the MainClipl on the previous Playltem side and the MainClip2 on the current Playltem side.
  • the first row shows secondary TS1 and secondary TS2, and the second row shows SubClipl on the previous SubPlayltem side and SubClip2 on the current SubPlayltem side.
  • the primary TS1 is composed of hatched data in the MainClipl.
  • the hatched data in MainClipl starts with a Source packet that can start decoding for In_Time in Previous Playltem.
  • Such a source notebook is located at the head of the video presentation unit and audio presentation unit referred to in In-Time.
  • the hatched data ends with the last packet of MainClipl.
  • Primary TS2 is composed of data hatched in MainClip2.
  • Data hatched in MainClip2 starts with the first Source bucket force of MainClip2.
  • the hatched data in the MainClip ends with a Source packet that ends the decoding for the current PlayLem.
  • Powerful Source packet is the Video Presentation Unit, Audio Presentation referenced by Out-Time of Current Playltem Source packet located at the end of the unit.
  • the secondary TS1 is composed of hatched data in SubClipl.
  • the hatched data in SubClipl starts with a Source packet that can start decoding for In_Time in previousSubPlayltem.
  • the powerful source notebook is located at the head of the Video Presentation Unit and Audio Presentation Unit that can be referenced by referring to the In-Time force.
  • the hatched data ends with the last SubClipl packet.
  • Secondary TS2 is also configured with a data force hatched in SubClip2.
  • Data hatched in SubClip2 starts with the first Source packet of SubClip2.
  • the hatched data in SubClip ends with a Source packet that ends decoding for the current Playltem.
  • the source packet is a source packet located at the end of the video presentation unit and audio presentation unit referred to by the out-time of the current ubPlayltem.
  • the primary TS and the secondary TS should be configured to have the same time length and be created so that the PTS values of the Video Presentation Unit and the Audio Presentation Unit have the same value. .
  • MainClip on the previousPlayltem side and the SubClip on the previousPlayltem side must be multiplexed so that they end with the Video Presentation Unit and Audio Presentation Unit corresponding to Out-Time, and the MainClip on the current Playltem side, the Sub sub lipi on the current Playltem side, In—Time must be multiplexed to start with 7 video presentation units and audio presentation units.
  • the duration of transport stream playback for each Playltem is 3 seconds.
  • CC 5 means that the start time of the last Vide 0 Presentation Unit of the video stream that is the primary TS1 of the answer that is originally different and the end time of the first Video Presentation Unit of the video stream that is the primary TS2 match.
  • Ending time of Video Presentation Unit ⁇ When trying to match the starting time, the handling of Audio Presentation Unit that should be synchronized with the Video Presentation Unit becomes a problem. This is because the sampling frequency differs between video and audio, and the video presentation unit and audio presentation unit time lengths do not match.
  • the 1st to 3rd tiers have no connection-condition in ubPlayltem, and the 4th tier to the younger 7th tier show sp_connection_condition in Playltem.
  • the fourth level is the multiple video Ps in TS1 and TS2.
  • the fifth stage shows the Audio Presentation Unit in TS1 and the Audio Presentation Unit in TS2.
  • the sixth row shows the STC value in MainClip.
  • the seventh row shows the source packet sequence in MainClip.
  • hatching is attached to the Video Presentation Unit, Audio Presentation Unit, and Source packet on the TS1 side, and the hatched parts are the Video Presentation Unit and Audio of the TS21 rule. Te at the Presentation Unit, Source Notebook.
  • SP_CC 5 indicates that there is a gap in the ATC of the SubClip (first stage) and there is an overlap in the Audio Presentation Unit of the SubClip (second stage).
  • the boundary of the above-mentioned Video Presentation Unit is the end point PTSl (lstEnd) + Tpp of the last Video Presentation Unit in the 4th stage from the TS1 side.
  • Video Presentation Unit start point PTS2 (2ndSTART) in the 4th stage corresponds to Video Presentation Unit start point PTS2 (2ndSTART) in the 4th stage
  • TS1 if the end point of the Audio Presentation Unit that matches the boundary time point T4 is T5a, and the start point of the Audio Presentation Unit that matches the time point T4 is TS3a among TS2, the overlap in MainClip is the Audio Presentation Unit. Is from T3a to T5a.
  • the Audio Presentation Unit of SubClip is longer than the Audio Presentation Unit of MainClip. This is because the sampling frequency is set low for the convenience of supplying the audio stream in SubClip through the network, and therefore, the time length per Audio Presentation Unit is increased.
  • the sampling frequency is set low for the convenience of supplying the audio stream in SubClip through the network, and therefore, the time length per Audio Presentation Unit is increased.
  • the end point of the Audio Presentation Unit that coincides with the boundary time point T4 is T5b
  • the start point of the Audio Presentation Unit that matches time point T4 is T3b. In this case, the overlap is from T3b to T5b.
  • the last Audio Presentation Unit of the audio stream in TS1 includes a sample having a playback time equal to the end of the display period of the last video picture in TSl specified by previous Playltem and previousSubPlayltem.
  • the first Audio Presentation Unit of the audio stream in TS2 is a sample having the same playback time as the beginning of the display period of the first picture of TS2 specified by the current Playltem and current SubPlayltem. Including.
  • the first packet of TS2 contains PAT and may be followed immediately by one or more PMTs. If the PMT is larger than the payload of the TS packet, the PMT can be more than 2 packets.
  • the TS packet that stores the PMT may have a PCR or SIT.
  • FIG. 29 is a diagram illustrating a relationship among a plurality of Video Presentation Units, a plurality of Audio Presentation Units designated by the previous Playltem and the current Playltem, and the STC time axis.
  • the first row shows the multiple Video Presentation Units belonging to TS1 referenced by previousPlayltem and the multiple Video Presentation Units belonging to TS2 referenced by the current Playltem, and the second row shows This indicates the multiple Audio Presentation Units belonging to the time stamp referenced by previousSubPlayltem and the multiple Audio Presentation Units belonging to TS2 referenced by the current SubPlayltem.
  • the third row shows the STC time axis in TSl of previousSubPlayltem and the STC time axis in TS2 of the current SubPlayltem.
  • the overlap is from the start point T3b of the Audio Presentation Unit belonging to TS2 to the end time T5b of the Audio Presentation Unit corresponding to TS2. It becomes the figure 28 It is as shown in.
  • the In_Time of the current SubPlayltem and the Out_Time of the previous SubPlayltem specify the time point T4 that is the boundary of the Video Presentation Unit. Since the current Playltem In_Time and the SubPlayltem Out_Time also specify the time point T4 that is the boundary of the Video Presentation Unit, the Playltem In_Time and Out_Time match the SubPlayltem In_Time and Out_Time.
  • In_Time of previousSubPlayltem and Out_Time of current SubPlayltem are recorded on a recording medium different from BD-ROM, and coincide with the boundary of Video Presentation Unit in MainClip. It is likely that the Out_Time of previousPlayltem matches the In_Time of the current Playltem.
  • the encoding method for audio streams with the same PID has changed! /, The sampling frequency, the number of quantization bits, the number of channels, etc. have changed.
  • the PTS of the PES packet carrying the last PCS in TSl is the previous Playltem, previous Indicates the time point earlier than the playback time corresponding to Out_Time of SubPlayltem.
  • the TS2 PG stream must start with an Epoch Start, Epoch Continue type Display Set.
  • the PTS of the PES packet carrying the first PCS in TS2 is equal to the playback time corresponding to the In_Time of the current Playltem or the current SubPlayltem! /, Or later!
  • Extraction of TS1 source packets followed by Source packets from DTS2 can be defined as STC1 and STC2 on the same system time axis, and there is no overlap in these DTS / PTS values.
  • the PTS of the PES packet carrying the last ICS in TSl indicates a point earlier than the playback time corresponding to Out_Time of previousPlayItem and previousSubPlayltem.
  • the TS2 IG stream must begin with an Epoch Start.Epoch Continue type Display Set.
  • the PTS of the PES packet carrying the first ICS in TS2 is equal to the playback time corresponding to the In_Time of the current Playltem or the current SubPlayltem! /, Or later!
  • Extraction of TS1 source packets followed by Source packets from DTS2 can be defined as STC1 and STC2 on the same system time axis, and there is no overlap in these DTS / PTS values.
  • FIG. 30 shows the internal structure of the playback apparatus according to the present invention.
  • the reproducing apparatus according to the present invention is industrially produced based on the inside shown in the figure.
  • the playback device according to the present invention mainly comprises two parts, a system LSI and a drive device, and can be industrially produced by mounting these parts on the cabinet and substrate of the device.
  • a system LSI is an integrated circuit that integrates various processing units that perform the functions of a playback device.
  • the playback devices produced in this way are BD-ROM drive la, read buffer lb, c, ATC counter 2a, c.
  • the BD-ROM drive la performs loading / ejecting of the BD-ROM and accesses the BD-ROM disc.
  • the read buffer (RB) lb stores the source packet sequence read from the BD-ROM.
  • the read buffer (RB) lc accumulates the source packet sequence read from the LastPlay title.
  • the ATC Counter 2a is reset using the ATS of the source packet constituting the primary TS that is located at the beginning of the playback section, and thereafter outputs the ATC to the source bucket 2b.
  • a source depacketizer (Source De-packetizer) 2b extracts a TS packet from a Source packet constituting the primary TS and sends it out. In this transmission, the input time to the decoder is adjusted according to the ATS of each TS packet. Specifically, at the moment when the ATC value generated by ATC Counter2a and the ATS value of the Source packet become the same, TS_Recording_Rate is used to transfer only that TS packet to PID Filter 3b.
  • the ATC Counter 2c is reset by using the ATS of the source packet constituting the secondary TS that is positioned at the beginning of the playback section, and thereafter outputs the ATC to the source de- vizer 2d.
  • a source depacketizer 2d extracts a TS packet from a Source packet that constitutes a secondary TS and sends it out.
  • the input time to the decoder is adjusted according to the ATS. Specifically, at the moment when the ATC value generated by ATC Counter2c and the ATS value of the Source packet become the same, TS_Recording_Rate is used to transfer only that TS packet to PID Filter 3d.
  • the STC Counter 3a is reset by the PCR of the primary TS and outputs the STC.
  • PID Filter 3b is a demultiplexing unit for MainClip, and among the Source packets output from source bucketizer 2b, those having the PID reference value notified from PID converting unit 24 are respectively connected to video decoder 4 and audio. Output to otecoder 9, Interactive Graphics coder 11, Pre sentation Graphics decoder 13. Each decoder receives the elementary stream via PID Filter 3b, and performs playback processing from the decoded according to the PCR (STC1 time axis) of the primary TS. In this way, the elementary stream that is input to each decoder through the PID Filter 3b is subjected to decoding and reproduction according to the PCR of the primary TS.
  • PCR STC1 time axis
  • the STC Counter 3c is reset by the PCR of the secondary TS and outputs the STC.
  • the PID filter 3d performs demultiplexing with reference to this STC.
  • PID Filter3d is a demultiplexing unit for SubClip, and among the Source packets output from the source bucket 2d, those having the PID reference value notified from the PID conversion unit 24 are the audio coder 9, Output to Interactive Graphics Recorder 1 and Presentation Graphics Decoder 13. In this way, it passes through PID Filter3d and is input to each decoder. The elementary stream will be used for decoding and playback according to the PCR of the secondary TS.
  • In_Time and Out_Time in Playltem are the same as In_Time and Out_Time in SubPlaylt em.
  • both the primary TS and the secondary TS have the same time axis, and the primary TS and secondary TS that make up the out-of-MUX application can be handled as one stream.
  • the ATC time axis representing the input time to the decoder can be synchronized with the STC time axis representing the decoder reference time axis.
  • the two Source De-packetizers described above can process Source packets read from the BD-ROM power and Source packets read from the local storage, respectively. .
  • STC Counters 3a and 3c can process two TSs as one TS if they measure the same time. Since the decoder in the playback device operates on one STC time axis, the STC time management that is the same as when only the normal primary TS is played back can be shared. Video decoder 4, IG decoder 11, PG decoder 13, system decoders 15c and 16c, and audio decoder 9 can all be operated on the same STC time axis. This is a desirable restriction because the control does not change at all from the normal playback device that performs the operation. Furthermore, during authoring, it is only necessary to control the input timing of one TS and observe the noffer state, so verification during authoring becomes easy.
  • the video decoder 4 decodes a plurality of PES packets output from the PID Filter 3b, obtains an uncompressed picture, and writes it to the video plane 5.
  • the Transport Buffer (TB) 4a is a buffer that is temporarily stored when TS packets belonging to the video stream are output from the PID Filter 3b.
  • Multiplexed Buffer (MB) 4b is a buffer for storing PES packets when outputting a video stream from Transport Buffer 4a to Elementary Buffer 4c.
  • the Elementary Buffer (EB) 4c is a buffer that stores pictures in an encoded state (I picture, B picture, P picture).
  • the decoder (DEC.) 4d obtains a plurality of frame images by decoding individual frame images of the video elementary stream at predetermined decoding times (DTS), and writes them into the video plane 5.
  • DTS decoding times
  • the Re-order Buffer 4e is a buffer for changing the order of decoded pictures to the code order display order.
  • the switch 4f is a switch that realizes switching the order of pictures to the sign order power display order.
  • the video plane 5 is a plane for storing uncompressed pictures.
  • a plane is a memory area for storing pixel data for one screen in the playback device.
  • the resolution in the video plane 5 is 1920 ⁇ 1080, and the picture data stored in the video plane 5 is composed of pixel data expressed by 16-bit YUV values.
  • the audio decoder 9 includes a Transport Buffer 6, an Elementary Buffer 7, and a decoder 8, and decodes the audio stream.
  • Transport Buffer 6 stores the TS packet output from PID Filter 3b in a first-in first-out manner, and provides it to audio decoder 8.
  • Elementary Buffer 7 stores only TS packets having the PID of the audio stream to be played out of TS packets output from PID Filter 3b in a first-in first-out manner.
  • the audio decoder 8 is used.
  • Decoder 8 converts the TS packet stored in Transport Buffer 6 into a PES packet.
  • the PES packet is decoded and the uncompressed LPCM audio data is obtained and output. This produces a digital output in the audio stream.
  • the switch 10 a selectively supplies either the TS packet read from the BD-ROM or the TS packet read from the local storage 200 to the video decoder 4.
  • the switch 10b selectively supplies either the TS packet read from the BD-ROM or the TS packet read from the local storage 200 power to the Interactive Graphics decoder 11.
  • the switch 10c selectively supplies either the TS packet read from the BD-ROM or the TS packet read from the local storage to the Presentation Graphics decoder 13.
  • the Interactive Graphics (IG) decoder 11 decodes the IG stream that is also read from the BD-ROM100 or local storage 200, and writes the uncompressed graphics to the IG plane 12.
  • the Transport Buffer (TB) l la Coded Data Buffer (CDB) lb, Stream Graphics Processor (SGP) ⁇ lc, Object Buffer ld, Composition Buffer ⁇ le, Graphics Controller (Ctrl) ll.
  • Transport Buffer (TB) la is a buffer in which TS packets belonging to the IG stream are stored.
  • Coded Data Buffer (CDB) l lb is a buffer that stores the PES packets that make up the IG stream.
  • the Stream Graphics Processor (SGP) llc decodes the PES packet storing the graphics data, and writes the uncompressed bitmap consisting of the index color obtained by decoding to the ObjectBufferld as a graphics object.
  • SGP Stream Graphics Processor
  • Object Buffer Id a graphics object obtained by decoding the Stream Graphics Processor 1 lc is arranged.
  • the composition buffer is a memory in which control information for drawing graphics data is placed.
  • the Graphics Controller (Ctrl) l lf decodes the control information placed in the composition buffer and performs control based on the decoding result.
  • PG decoder 13 decodes the PG stream read from BD-ROM or local storage 200, Write to ics plane 14.
  • PG decoder 13 includes Transport Buffer (TB) 13a, Coded Data Buffer (CDB) 13b, Stream Graphics Processor (SGP) 13c 13 Object Buffer (OB) 13d, Composition Buffer (CB) 13e, Graphics Controller (Ctrl) 1313 ⁇ 4 Consists of.
  • the Transport Buffer (TB) 13a is a buffer that is temporarily accumulated when TS packets belonging to the PG stream are output from the PID filter 4.
  • the Coded Data Buffer (CDB) 13b is a buffer that stores PES packets that make up the PG stream.
  • the Stream Graphics Processor (SGP) 13c decodes the PES packet (ODS) storing the graphics data, and writes the uncompressed bitmap with index color power obtained by the decoding to the ObjectBufferl3d as a graphics object.
  • SGP Stream Graphics Processor
  • OB Object Buffer
  • the Composition Buffer (CB) 13e is a memory in which control information (PCS) for drawing graphics data is placed.
  • the Graphics Controller (Ctrl) 13f decodes the PCS arranged in the Composition Buffer 13e and performs control based on the decoding result.
  • the Presentation Graphics (PG) plane 14 is a memory having an area for one screen, and can store uncompressed graphics for one screen.
  • the system decoder 15 processes system control packets (PAT and PMT) in the secondary TS and controls the entire decoder.
  • Transport Bufferl5a stores system control packets (PAT and PMT) that exist in the primary TS.
  • the Elementary Buffer 15b supplies the system control packet to the decoder 15c.
  • the decoder 15c decodes the system control packet stored in the Elementary Buffer 15b.
  • the Transport Buffer 6a stores the system control packet that exists in the secondary TS.
  • the Elementary Buffer l6b supplies the system control packet in the secondary TS to the decoder 16c.
  • the decoder 16c decodes the system control packet stored in the Elementary Buffer l6b.
  • the memory 21 is a memory for storing current PlayList information and current Clip information.
  • Current PlayList information refers to information currently being processed among multiple PlayList information recorded on a BD-ROM.
  • Current Clip information is the information currently being processed among multiple Clip information recorded in BD-ROM / low-power storage.
  • the controller 22 realizes playback control of the BD-ROM by executing play list playback (playback control according to current PlayList information). It also controls ATS and ST C as described above. In this control, the controller 22 pre-reads the source packet in the BD-ROM and the local storage in the buffer in the decoder within a time range of 1 second. Such prefetching is performed because there is a guarantee that underflow or overflow will not occur due to the window limitation described above.
  • the PSR set 23 is a register built in the playback device, and includes 64 Player Setting / Static Registers (PSR) and 4096 General Purpose Registers (GPR). Of the Player Settings / Status Register settings (PSR), PSR4 to PSR8 are used to represent the current playback point.
  • PSR Player Setting / Static Registers
  • GPR General Purpose Registers
  • the PID conversion unit 24 converts the audio stream stored in the PSR set 23 and the stream number of the audio stream into a PID reference value based on the STN_Table, and converts the PID reference value as a conversion result to the PID Filter 3b and PID Filter 3d. Instruct.
  • the network unit 25 implements the communication function of this playback device.
  • the network unit 25 establishes a TCP connection, an FTP connection, etc. with the website corresponding to the URL. Download from the website by establishing a powerful connection.
  • the operation receiving unit 26 receives an operation performed on the remote controller from the user, and notifies the controller 22 of User Operation information indicating such an operation.
  • the above is the internal configuration of the playback device.
  • the controller 22 performs processing of the flowcharts shown in FIGS. 31 and 32.
  • a program that causes the CPU to execute the procedure can be created, written to the instruction ROM, and provided to the CPU for implementation in a playback device.
  • FIG. 31 is a flowchart of a playback procedure based on PlayList information. This flowchart configures PlayList information. Read the mpls file (Step Sl l), make the first PlayItem in the PlayList information the current PlayItem (Step S12), The loop structure repeats the processing from S13 to S25.
  • This loop structure uses step S23 as an end condition, and instructs the BD-ROM drive to read from the Access Unit corresponding to In_Time of the current Playltem to the Access Unit corresponding to Out_Time of the current Playltem (Step SI 3 ), It is determined whether or not previous Playltem exists in the current Playltem (Step S14), and the process of Step S15 and the process of Steps S16 to S21 are selectively performed according to the determination result. Execute. Specifically, if there is no previousPlayltem in the current Playltem (No in Step S14), the decoder is instructed to play from PlaylJn_Time to PlayItem_Out_Time (Step S15).
  • ATC_Sequence in the primary TS will be switched.
  • an offset value for the primary TS called ATC_deltal is calculated (step S17), and ATC_deltal is added to the ATC value (ATC1) in the previous ATC_Sequence to calculate the new ATC_Sequence ATC value.
  • ATC2 obtain (ATC2) (step S18).
  • STC_Sequence in the primary TS is switched.
  • an offset value called STC_deltal is obtained (step S19), and STC_deltal is added to the STC value (STC1) in the previous STC_Sequence (step S20), so that a new! / ⁇ STC_Sequence STC Find the value (STC2).
  • Step S25 is a process for searching whether there is a SubPlayltem to be reproduced in synchronization with the current Playltem.
  • each SubPlayltem constituting the SubPath information has information called Sync_PlayItem_Id
  • the SubPlayltem to be synchronized with the current Playltem has this Sync_PlayItem_Id set as the current Playltem. Therefore, in step S25, a search is performed as to whether or not the current Playltem exists in a plurality of SubPlayltems constituting the SubPlayltem power SubPath information designated by Sync_PlayItem_Id.
  • Step S22 determines whether or not the current playback time point on the AVClip time axis (the current PTM (Presentation TiMe) is the force that has reached the Out_Time of the current PlayStation (Step S22). If so, the process proceeds to Step S23.
  • S23 is a determination of whether or not the current Playltem has become the last Playltem in the PlayList information. If it is not the last Playltem, the next Platem in the PlayList information is made the current Playltem (Step S24), and Step SI The process proceeds to 3. With the above processing, the processing from step S13 to step S24 is performed on all the Playltems in the PlayList information.
  • FIG. 32 is a flowchart showing seamless connection in SubPlayltem.
  • step S25 If it is determined in step S25 that there is a SubPlayltem with the current Playltem specified as Sync_PlayItem_Id, that SubPlayltem is set as the current SubPlayltem (Step S31), and the Access Unit corresponding to Out_Time from the Access Unit corresponding to the SubPlayltem In_Time is set. Command local storage 200 to read up to Unit (step S32). Then, it is determined whether or not Previous SubPlayltem exists in the current Playltem (Step S33), and Steps S34 and S35, and Steps S36 to S41 are selectively executed according to the determination result.
  • Step S34 If there is Previous SubPlayltem in the current Playltem (Yes in Step S33), it waits for the current PTM to reach Sync_Start_Pts_of_PlayItem (Step S34), and if so, playback from SubPlayItem_In_Time to SubPlayItem_Out_Time is sent to the decoder. Command (step S35).
  • ATC_Sequence is switched.
  • an offset value for the secondary TS called ATC_delta2 is calculated (step S37), and ATC_delta 2 is added to the ATC value (ATC1) in the previous ATC_Sequence, so that a new! /, ATC_Sequence
  • An ATC value (ATC2) is obtained (step S38).
  • ATC_delta is the input of the first TS packet of the newly read transport stream (TS2) from the input time T1 of the last TS packet of the transport stream (TS1) read so far.
  • the offset value up to time T2 is given by the formula “ATC.delta ⁇ Nl / TS_recording_rate”.
  • N1 is the number of TS packets that follow the last video PES packet of TS1.
  • STC_Sequence is also switched.
  • STC_delta2 is obtained (step S39), and STC_delta2 is added to the STC value (STC1) in the previous STC_Sequence (step S40) to obtain a new STC_Sequence STC value (STC2).
  • STC_delta2 PTS l (lstEND) + Tpp-PTS2 (2ndSTART)
  • the calculation formula force is calculated.
  • step S41 After instructing the audio decoder 9 to mute Audio Overrap, the decoder is instructed to play from Playltem Jn_Time to PlayItem_Out_Time (step S41).
  • the controller 22 performs STC change processing.
  • this change processing is performed when the decoder is in a free-run state.
  • the transfer allowance is locally 96 Mbit in the period of 1 second. Even then, if the TS packet with a size of 96Mbit x 0.5 seconds is prefetched to the decoder, the buffer in the decoder will not underflow or overflow. In any period of the digital stream, the data volume is “96Mbit x 0.5 seconds” or less, and TS packets can be supplied without underflow or overflow. it can. This eliminates the possibility of spilling over the problem of quality of simultaneous reading to realize an out-of-MUX framework.
  • volume configuration information is created from the scenario created in step V (scenario creation process).
  • the volume configuration information is information indicating the format of the application layer of the optical disc in an abstract description.
  • An elementary stream is obtained by encoding (material encoding process). After that, multiple elementary streams are multiplexed (multiplexing step).
  • the multiplexed stream and volume configuration information is adapted to the application layer format of the BD-ROM, and the data to be recorded in the volume area of the BD-ROM is recorded.
  • Get an overview generally called volume data (formatting process).
  • the application layer format of the recording medium according to the present invention is an instance of a class structure described in a programming language, and is based on the syntax specified in the BD-ROM standard! / Clip information, PlayList information, etc. can be created by describing the instance.
  • tabular data can be defined using a programming language for statement, and other data that is only needed under certain conditions can be defined using ifX.
  • volume data is obtained after such adaptation processing, the volume data is reproduced to check whether the result of the scenario creation process is correct (emulation process). In this emulation process, it is desirable to simulate the buffer status of the BD-ROM player model.
  • a pressing process is performed.
  • the volume image is converted into a physical data string, and the master disk is cut using this physical data string to create a disk master disk.
  • BD-ROMs are manufactured from the master disc created by the press machine. This manufacturing mainly consists of various processes such as substrate molding, reflection film formation, protective film coating, bonding, and label printing.
  • the recording medium (BD-ROM) shown in each embodiment can be manufactured.
  • the planning process capability and the formatting process are also executed. Then, if AVClip, Clip information, and PlayList information that make up one volume data are obtained, those that should already be supplied by BD-ROM are excluded, and the remaining content is added as additional content. Combine them into one file using an archiver program. Through this process, additional content is obtained. If this is the case, the additional content will be provided to the WWW server and sent to the playback device in response to a request from the playback device.
  • the verification described in the previous embodiment is executed at the stage where the AVClip, Clip information, and PlayList information are completed and the elementary stream to be played back is determined by the STN_table in the P1 ayList information, that is, in the formatting process.
  • the authoring system for creating powerful application formats is described below.
  • FIG. 33 is a diagram showing an internal configuration of an authoring system that is helpful in the second embodiment.
  • the authoring system includes an input device 51, an encoding device 52, a server device 53, a material storage 54, a BD configuration information storage 55, client devices 56 to 58, a multiplexer 60, a BD scenario converter 61, and a formatter 62. It consists of Verifier63.
  • the input device 51 is loaded with a video cassette containing HD images and SD images, reproduces the video cassette, and outputs a reproduction signal to the encoding device 52.
  • the encoding device 52 encodes the reproduction signal output from the input device 51 to obtain an elementary stream such as a video stream or an audio stream.
  • the elementary stream thus obtained is output to the server device 53 through the LAN, and written to the material storage 54 in the server device 53.
  • the server device 53 includes two drive devices, a material storage 54 and a BD configuration information storage 55.
  • the material storage 54 is a built-in disk device of the server device 53, and sequentially stores elementary streams obtained by encoding of the encoding device 52.
  • the material storage 54 has two directories such as an HDstream directory and an SDstream directory, and elementary streams obtained by encoding HD images are written to the HDstream directory.
  • the BD configuration information storage 55 is a drive device in which BD volume configuration information is stored.
  • Multiplexer 60 uses the HDstream directory and SDstream directory in material storage 54. Among the elementary streams stored in the directory, the stream specified by the BD volume configuration information is read out, and multiplexed according to the BD volume configuration information to obtain an AVClip that is a multiplexed stream.
  • the BD scenario converter 61 obtains a BD scenario by converting the BD volume configuration information stored in the BD configuration information storage 55 into the BD-ROM application format.
  • the formatter 62 adapts the Clip obtained by the multiplexer 60 and the BD scenario obtained by the BD scenario converter 61 to the application layer format of the BD-ROM. In this way, the BD scenario can be used to obtain BD-ROM masters and downloadable content to be stored in local storage.
  • the verify unit 63 refers to the STN_table in the PlayList information generated by the scenario converter 61, and the BD-ROM primary TS and local storage secondary TS obtained by the multiplexer 60 implement the Out_of_MUX application. Therefore, determine whether the limit is satisfied.
  • the above is the internal configuration of the authoring system.
  • the implementation of the verify unit 63 in the authoring system is described below.
  • the verify unit 63 can be implemented in the authoring system by creating a program for causing the CPU to execute the processing procedures of the flowcharts shown in FIGS. 34 and 35, writing the program to the instruction ROM, and supplying the program to the CPU.
  • FIG. 34 is a flowchart showing the verification procedure for the primary TS and secondary TS.
  • This flowchart has a loop structure that repeats the processing from step S2 to step S7 after setting the ATS of the first source packet in the source packet sequence to In_Time of the current window in step S1.
  • This loop structure sets the ATS that exists after 1 second from the In_Time of the current window to the Out_Time of the current window (step S2), and counts the number of TS packets that exist from the In_Time to the Out_Time of the current window (Ste S3), calculating the number of bits in the current window from In_Time (step S4) and determining whether the bit value is 48 Mbit or less (step S5) Up to S6 force Wes.
  • This step S6 is a determination of whether or not the Out_Time of the current window has reached the last Source packet in the ATC time axis. If Step S6 is No, the next ATS in the Source packet sequence is Set the Rent Window to In_Time (step S7) and repeat steps S2 to S6. If any window determines that step S5 is No, it is determined that the BD-ROM standard is violated (step S9). If step S5 is determined to be Yes in all windows and step S6 is determined to be Yes, it is determined to be compliant with the BD-ROM standard (step S8).
  • Steps S81 to S83 are performed in one of the TS packets constituting the elementary stream of which STN_table is allowed to be replayed every time one current window is determined!
  • the bit rate of the one belonging to the current window is calculated for each elementary stream (step S81), and the calculated bit is selected from the plurality of video streams, the plurality of audio streams, the plurality of PG streams, and the plurality of IG streams.
  • Select the one with the highest rate (Step S82), and select the maximum bit rate of the video stream, the maximum bit rate of the audio stream, the maximum bit rate of the PG stream, and the maximum bit rate of the IG stream.
  • Summing up step S83), it is determined whether the total amount is 48Mbit or less (step S5).
  • Termination of TS packet indicated by Out_Time in Window By checking the bit amount at the location where it is useful, the verification work in authoring can be further simplified.
  • Progressive PlayList information is playlist information for designating multiple AVClips that should be played on the premise of streaming as one playback path.
  • Progressive PlayList information is useful for starting playback without splitting the cache size or waiting for all files to be downloaded by dividing the secondary TS to be downloaded / streamed into small files.
  • the Progressive PlayList information also includes many Playltem information powers corresponding to each of the plurality of AVClips.
  • CC 6! / Required conditions>
  • TS1 and TS2 specified by two Playltems and TS1 and TS2 specified by two SubPlayltems must satisfy the following conditions.
  • the TS1 audio stream may end with an incomplete audio stream. And an audio stream with the same PID in TS2 may start with an incomplete Audio Present Unit. If these TSL and TS2 are played back based on multiple Playltems and multiple SubPlayltems, one complete Aud 10 Presentation Unit can be protected from two Audio Presentation Units.
  • the stream to be recorded on the BD-ROM needs to be composed of 32 Source packets, all the stream files that make up one SubPlayltem need to be multiples of 6 KBytes. is there.
  • the first row shows a file (20000.m2ts) that has one continuous ATC / STC time and stores a stream that has a continuous encoding method.
  • the second row shows three stored files (20001.m2ts, 20002.m2t, 20003.m2ts) storing three streams. These three files store three primary TSs obtained by dividing one stream in the first stage into aligned units (6 KBytes).
  • FIG. 37 is a diagram showing the correlation between Playltem and SubPlayltem.
  • the second row shows three SubPlayItems (SubPlayItem # 1, SubPlayItem # 2, SubPlayItem # 3) in the PlayList information.
  • the third level shows nine SubPlayItems (SubPlayItem # l, SubPlayItem # 2, SubPlayItem # 3 to SubPlayltem # 9) in Progressive PlayList information.
  • the third level shows nine SubPlayItems (SubPlayItem # l, SubPlayItem # 2, SubPlayItem # 3 to SubPlayltem #
  • the AVClip that configures the Progressive PlayList information is divided into short segments for streaming. The process of supplying can be realized.
  • Fig. 38 shows how the multiple TS packets constituting the primary TS and the multiple TS packets constituting the secondary TS are multiplexed when the audio power constituting the primary TS is replaced with the audio constituting the secondary TS.
  • FIG. 38 is a diagram schematically showing how a plurality of TS packets existing on the ATC time axis are multiplexed.
  • the first level shows the primary TS.
  • the primary TS is a TS packet that stores V, Al, and A2 (one video and two audio). These TS packets are 2 Type This is obtained by multiplexing three elementary streams.
  • the second row shows the secondary TS.
  • the secondary TS is composed of TS packets that store two types of audio A3 and A4.
  • the time zone p3 in which the TS packets of these secondary TSs are multiplexed constitutes the primary TS and the time zone pi in which the audio packets of the primary TS are multiplexed on the ATC time axis indicating the input time axis to the decoder. It consists of time zone p2 when TS packets are not transferred.
  • FIG. 39 shows that when subtitles (PG stream) and menu (IG stream) are exchanged in addition to audio, a plurality of TS packets constituting the primary TS and a plurality of TS packets constituting the secondary TS are arranged. It is a figure which shows typically how it is multiplexed.
  • the multiplexer 60 simulates the noffer state when the primary TS is reproduced in the decoder model, and the transfer time zone of each packet in the primary TS and the non-transfer time of the primary TS. Detect the band. these If the PES packets that make up the secondary TS are detected, the PES packets that make up the secondary TS are forwarded to the same type of packet transfer time zone or non-transfer time zone. Attaching a powerful ATS to each TS packet. Since the ATs attached in this way indicate the transfer time zone and non-transfer time zone of the same type of packet, each PES packet that constitutes the secondary TS has the same type of packet in the primary TS as shown in FIG. It is sent to the decoder in the transfer time zone and the non-transfer time zone.
  • the multiplexer 60 converts the PES packets that make up the elementary stream into packs, and the TS stream header of each pack.
  • SCR System Clock Reference
  • the SCR attached in this way also shows the same type of bucket transfer time zone and no-transfer time zone, so each PES packet that makes up the secondary PS (program stream supplied from the local storage)
  • the same type of packet in the primary PS is sent to the decoder in the transfer time zone and the non-transfer time zone.
  • multiplexing is performed by selecting the transfer period of the same type of packet in the primary TS and the non-transfer period in the primary TS during the input period of the packets constituting the secondary TS.
  • By realizing powerful multiplexing on the authoring system shown in the second embodiment it becomes easy to produce a movie work that realizes the Out_of_MUX application. This makes it easy to ensure that no overflow occurs during playback at the authoring stage.
  • an audio mixing application will be described in detail.
  • This application is an application that is an exception to the Out_of_MUX specification of one elementary stream per type.
  • the exception is that the audio mixing application selects the audio stream corresponding to the primary TS and the audio stream corresponding to the secondary TS at the same time, and simultaneously decodes the audio of the primary TS and the audio of the secondary TS. Is an exception.
  • Fig. 40 is a diagram illustrating how the primary TS and the secondary TS configuring the audio mixing application are supplied to the decoder in the internal configuration of the BD-ROM playback device.
  • BD-ROM drive la, local storage 200, and network unit 25 are shown on the left side, and each decoder is shown on the right side, among the internal configurations of the BD-ROM playback device.
  • the PID Filter that performs demultiplexing of streams is shown in the middle.
  • the primary TS Video 1 'Audio 1 (English), Audio2 (Spanish), PG 1 (English Subtitle), IG1 (Englis h Menu)) ⁇ Secondary TS (Audio3 (Commentary), PG2 (Japanese Subtitle)) , PG3 (Korean Subtitle), PG4 (Chinese Subtitle), and IG2 (English Menu)) indicate transport streams supplied from the BD-ROM and the local storage cartridge, respectively. Since the disc alone contains only English (Audi 0 1) and Spanish (Audio 2), the movie director's commentary audio cannot select this disc power.
  • an audio stream that belongs to the primary TS is called a primary audio stream
  • an audio stream that belongs to the secondary TS is called a secondary audio stream.
  • the secondary audio stream is different from the primary audio stream in that the audio frame of the secondary audio stream includes “downmixing information” and metadata that can be used as “gain control information”.
  • Downmixing information is information for downmixing. Downmixing is a conversion that reduces the number of audio playback channels to be less than the number of code channels. Downmixing information is defined as a conversion coefficient matrix for downmixing, and this downmixing is performed by a playback device. Let me do it.
  • One example of downmixing is playing a 5.1ch audio stream in 2ch.
  • “Gain control information” is information that increases or decreases the gain at the time of audio output on the primary audio stream side.
  • the metadata of the secondary audio stream can reduce the output of the primary audio stream that is played back simultaneously in real time.
  • the volume of the playback output of the primary audio stream and the volume of the playback output of the secondary audio stream are combined to avoid a situation where the speaker is damaged. be able to. This completes the description of the audio stream in the present embodiment. Subsequently, an improvement in PlayList information in the present embodiment will be described.
  • the PlayList information in this embodiment is permitted to be replayed!
  • the combination of the multiple primary audio streams and the multiple secondary audio streams is the combination of each Playltem. It is shown in STN_table.
  • STN_table in this embodiment will be described.
  • STN_table has a combination of Stream_entry and Stream_attribute in the secondary audio stream. It exists separately from the combination of Stream_entry and Stream_attribute in the primary audio stream. Then, the stream between the Stream_entry and the Stream_attribute in the secondary audio stream is Comb_info_S econdary—audio—Primary—audio and J heart 1.
  • Comb_info_Secondary_audio_Primary_audio uniquely specifies one or more primary audio streams that can mix the playback output of the secondary audio stream. As a result, when a primary audio stream having a predetermined attribute is reproduced, the secondary audio stream is not mixed, and when the primary audio stream having other attributes is reproduced. It is possible to set whether or not to perform mixing according to the audio attribute such as mixing the secondary audio stream at the time of authoring.
  • FIG. 41 is a diagram showing the internal structure of the playback apparatus according to the fifth embodiment.
  • TB6, EB7, and audio decoder 8 are replaced with an Audio Mixing Processor (the part surrounded by a dotted line).
  • This Audio Mixing Processor inputs two audio streams from the primary TS and secondary TS, and decodes and mixes them simultaneously. Other configurations are the same as the internal configuration for realizing out-of-MUX applications. After that, I will talk about the Audio Mixing Processor.
  • the Audio Mixing Proces sor consists of Transport Buffers 6a and 6b, EB7a and 7b, Preload Buffer 7c, Audio Decoders 8a and 8b, and Mixers 9a and 9b.
  • the Transport Buffer 6a stores the TS packet having the PID of the audio stream output from the PID Filter 3b in a first-in first-out manner and supplies the TS packet to the audio decoder 8a.
  • the Transport Buffer 6b stores only the TS packets having the PID of the audio stream output from the PID Filter 3d in a first-in first-out manner and provides them to the audio decoder 8b.
  • EB7a is a buffer for storing PES packets obtained by converting TS packets stored in buffer 6a.
  • the EB 7b is a buffer for storing a PES packet obtained by converting the TS packet stored in the buffer 6a.
  • the preload buffer 7c is a memory for preloading the file so und.bdmv read from the BD-ROM / local storage.
  • the file sound.bdmv is a file that stores audio data that should be output for menu operations.
  • the audio decoder 8a performs a decoding process on the PES packet constituting the primary TS, and obtains and outputs uncompressed LPCM audio data. As a result, digital output in the audio stream is performed.
  • the audio decoder 8b performs a decoding process on the PES packet constituting the secondary TS, and obtains and outputs uncompressed LPCM audio data. As a result, digital output in the audio stream is performed. [0205]
  • the mixer 9a mixes the LPCM digital audio output from the audio decoder 8a with the LPCM digital audio output from the audio decoder 8b.
  • the mixer 9b mixes the LPCM digital audio output from the mixer 9a and the sound data stored in the notch 7c.
  • the mixing by the sound mixer 9b is performed by the controller 22 decoding a navigation command intended to generate a click sound.
  • the audio mixing application also includes the primary audio stream and the secondary audio stream power
  • the primary audio stream and the secondary audio stream are simultaneously read out as shown in the second embodiment. It is executed assuming the case. Specifically, the window is shifted one by one on the ATC time axis that MainClip and SubClip are based on. The procedure for this shift is the same as that shown in the flowchart of FIG.
  • the calculated bit rate is the highest among the video stream, multiple primary audio streams, multiple secondary audio streams, multiple PG streams, and multiple IG streams at each ATC time axis coordinate indicated in the ATS.
  • the primary audio stream and the secondary audio stream are simultaneously read from both the BD-ROM and the local storage, the decoder for the primary audio stream, and the secondary audio stream Even when it is supplied to the decoder, it can be guaranteed that the amount of bits per second does not exceed the predetermined upper limit. This gives you a strong guarantee that you can efficiently create an audio mixing application. Therefore, an audio mixing application It is possible to supply tl content as it appears, download it to the local storage, and supply the local storage to the decoder as well, so that supply that adds commentary after shipment of the BD-ROM The law can be easily realized.
  • the In_Time and Out_Time in the Playltem are matched with the In_Time and Out_Time in the SubPlayltem to match the connection points between the Playltems and the connection points of the SubPlayltem.
  • this connection point matching is not required and a certain time difference is allowed.
  • Fig. 42 is a diagram showing the correlation between the Playltem and SubPlayltem specified in the playlist showing audio mixing.
  • the second tier in FIG. 42 shows three SubPlayItems (SubPlayItem # 1, SubPlayItem # 2, and SubPlantem # 3) in the PlayList information.
  • the start of SubPlayItem # 3 in the second row is 3 seconds before the start point of Playltem # 3 in the first row.
  • the starting point of SubPlayItem # 5 in the third row is 3 seconds before the starting point of Playltem # 3 in the first row.
  • the time interval for switching the STC time axis between Playltem and SubPlayltem is 3 seconds, so the STC time axis does not change too frequently.
  • the first tier in FIG. 43 shows an example of PlayList information that constitutes both the theater release version and the director's cut.
  • Playltem # l, Playltem # 2, and Playltem # 4 are director's cuts
  • Playltem # l, Playltem # 3, and Playltem # 4 are theatrical releases. .
  • Playltem # l and Playltem # 4 can be shared by both versions, titles can be created effectively. Since different images are shorter than the whole, the data capacity of the entire disk can be effectively reduced.
  • the third row in FIG. 43 shows SubPlayItem (SubPlayItem # l, SubPlayItem # 2, SubPlayltem # 3 corresponding to Playltem information # 1, Playltem information # 2, Playltem information # 3, and Playltem information # 4, respectively.
  • the In_Time and Out_Time of Playltem do not match the In_Time and Out_Time of SubPlayltem, so synchronization between ATC Counter2a and 2c, and STC Counter3a and STC Counter3c is unnecessary, and The room for equipment design can be expanded.
  • the primary audio stream and the secondary audio stream are simultaneously read from the BD-ROM and local storage and supplied to the decoder, the primary audio stream and the secondary audio stream are targeted for bit amount restriction.
  • the bit amount limitation when realizing a Picture in Picture (PiP) playback application will be described.
  • PiP playback is when MainClip that configures a moving image is specified by MainPath information of PlayList information, and SubCli P that configures another moving image is specified by SubPlayltem information of PlayList information
  • Primary Video is composed of HD images
  • Secondary Video is composed of SD images.
  • HD images have a resolution of 1920 x 1080 and, like film material, have a frame interval of 3750 (or 3753 or 3754) clocks.
  • SD images have a resolution of 720 x 480 and have a display interval of 1501 clocks, similar to NTSC material, or a frame interval of 1800 clocks, similar to PAL material.
  • the resolution of the SD image is about 1/4 of the resolution of the HD image
  • the Primary Video that is the HD image and the Secondary Video that is the SD image are displayed on the same screen. Is about 1/4 the size of Primary Video.
  • Secondary Video is a moving image in which only directors and performers appear, and it is assumed that acting is performed pointing to the video content in Primary Video. If it is such a moving image power ⁇ Secondary Video, the director and performers point to the content of the movie main video by combining the powerful Secondary Video video inner valley with the video content of the Primary Video, It is possible to achieve a fun screen production as explained.
  • a video stream (secondary video stream) for Secondary Video is specified by a plurality of SubPlayltem information in the SubPath information of the PlayList information.
  • PiP_Position and PiP_Size information elements are newly added to the powerful SubPlay Item information.
  • PiP_Position indicates the position where the secondary video playback video should be placed using the X and Y coordinates on the screen plane for primary video playback.
  • PiP_Size indicates the vertical size and horizontal size of the secondary video playback video.
  • In-Time and Out-Time of Sub Playltem information must indicate the same time as In-Time and Out-Time of Playltem information.
  • the hardware configuration of the playback apparatus according to this embodiment that performs decoding of the Secondary Video stream includes the video stream. Another set of component forces for decoding has been added.
  • the components for decoding the video stream are Transport Buffer, Multiplexed Buffer, Elementary Buffer, decoder, and Video plane, which decode the secondary video stream.
  • the following Scaller and synthesis unit are added to the playback apparatus according to the present embodiment.
  • Scalier enlarges or reduces the playback video obtained on the Secondary Video plane based on the vertical and horizontal sizes indicated by PiP_Size of the SubPlayltem information.
  • the synthesizer realizes PiP playback by combining the enlarged or reduced playback video made by Scalier and the playback video obtained by the video decoder.
  • the composition of the primary video playback video and the secondary video playback video by the compositing unit is performed in accordance with PiP_Position defined in the SubPlayltem information. By doing so, a composite video in which the primary video playback video and the secondary video playback video are combined is played back.
  • the synthesis by the synthesis unit black and white synthesis, layer synthesis, and the like can be performed. It is also possible to remove the background in the secondary video, extract the person portion, and then synthesize the primary video playback video.
  • the above is the description of the playback device according to the present embodiment.
  • the primary video stream and secondary video stream are It is a verification target for limiting the bit amount.
  • the primary video stream, the secondary video stream, the plurality of primary audio streams, and the plurality of secondary audio streams at each coordinate of the ATC time axis indicated in the ATS.
  • Multiple PG streams, multiple IG streams with the highest calculated bit rate select the maximum bit rate of the primary video stream, the maximum bit rate of the secondary video stream, the bit of the primary audio stream Maximum rate, maximum secondary stream bit rate, maximum PG stream bit rate Value and the maximum value of the bit rate of the IG stream are summed to determine whether the total amount is 48 Mbit or less.
  • the last Video Presentation Unit of TSl is selected as Out-Time of previousPlayltem
  • the first Video Presentation Unit of TS2 is selected as previousPlayltem
  • the InSubtime of previousSubPlayltem is selected.
  • the Video Presentation Unit in the middle of TS2 may be selected as the Out_Time of the current SubPlayltem and the In_Time of the current SubPlayltem.
  • Out_of_MUX the amount of data supplied to the decoder does not necessarily increase.
  • the primary audio stream is MainClip, which consists of CBR DD (Dolby Digital) and VBR MLP, and this MLP is supplied from the local storage. Shall be replaced by the CBR DD. In this case, the amount of data supplied to the decoder is reduced. If this is clear, verification may be omitted.
  • the playback time difference of each video stream / audio stream within one Playltem is small.
  • This difference can also be one video frame (1/60 to 1/25 seconds), or less than 1 second, or even as a percentage of the total playback time (less than 1%, etc.). Good, or a combination of the two.
  • the difference between the playback time lengths of the two streams stored with the same PID is the minimum playback unit of the stream with the shorter playback time. It is desirable that the playback time is less than (one frame). This case corresponds to the case where Dolby Digital (AC-3), MLP (Meridian Lossless Packing) and a single elementary stream are stored on a BD-ROM.
  • PID was used to distinguish between primary audio streams and secondary audio streams, but when using MPEG2-PS, the streamjd in the PES packet header should be different. desirable.
  • the primary audio stream and the secondary audio stream only need to be distinguished at the system stream level so that the two audio streams can be distinguished by one demultiplexer. Or before bundling the two streams into one,
  • Audio data for the click sound (file sound.bdmv) is preloaded by BD-RO It is desirable to do this when loading M or switching titles. This is because when the file sound.bdmv is read during playback of an AVClip, the seek of an optical pickup to read a file other than the AVClip occurs. On the other hand, since it is rare that AVClip playback continues when the title is switched when a BD-ROM is loaded, reading the file sound.bdmv at such timing increases the responsiveness of the device and interrupts AVClip playback. It can be made difficult.
  • TM Java
  • J2ME Personal Basis Profile
  • GEM 1.0.2 Globally Executable MHP specification
  • TM platform may be configured to cause the playback device to execute the BD-J application. And when you run this application, you can let the playback device run the Out_of_MUX framework!
  • the decoder in the BD-ROM playback device plays back the AVClip based on the playlist information in accordance with the title selection by the “module manager”.
  • the application manager When the “module manager” selects a title, the application manager performs signaling using the application management table (AMT) corresponding to the previous title and the AMT corresponding to the current title. This signaling terminates the operation of the application not listed in the AMT corresponding to the current title, and is listed in the AMT corresponding to the previous title.
  • the AMT corresponding to the current title is controlled to start the application operation described in the AMT.
  • Each area in the local storage shown in each embodiment is preferably provided under the directory corresponding to the disk root certificate in the BD-ROM.
  • the disk root certificate is the power of the creator who created this BD-ROM.
  • the root certificate that received the cloth is assigned to the BD-ROM.
  • the disk root certificate is encoded in the X.509 format, for example.
  • the X.509 specification is published by the International Brass and Telephone Consultative Committee, CCITT Recommendation X.509 (1988), “The Directory-Au thentication Framework.
  • BD-ROM and local storage are encrypted with Advancend Access Content System (AACS), signed information is added, and usage rights are specified in the permission file. Is desired.
  • AACS Advancend Access Content System
  • BD-J Extension includes various packages specially designed to give the Java (TM) platform functionality beyond GEM [1. 0.2].
  • the packages supplied by BD-J Extension are as follows.
  • This package provides special functions that should be added to Java (TM) Media FrameWork. Control over the selection of angles, audio, and subtitles Added to this package. Org.bluray.ti
  • This package is an API for mapping "services” to "titles” in GEM [1.0.2], a mechanism for querying title information for BD-ROM capabilities, and a mechanism for selecting new titles. including.
  • This package includes an API for managing the lifetime of an application. It also includes an API that queries and matches information necessary for signaling when executing an application.
  • This package defines constants for key events specific to BD-ROM, and includes classes that realize synchronization with video playback.
  • this package can be recorded on BD-ROM (on-disc content) and recorded on BD-ROM !, NA! / ⁇ Local Provides a mechanism (Binding Scheme) for binding content on storage (off-disc content).
  • Binding Scheme associates content on BD-ROM (AVClip, subtitles, BD-J application) with related content on Local Storage. This Binding Scheme realizes seamless playback regardless of the location of the content.
  • Virtual Package information is information that expands volume management information in BD-ROM.
  • the volume management information is information that defines the directory file structure existing on a certain recording medium, and includes directory management information about the directory and file management information about the file.
  • Virtual Package information is an extension of the directory-file structure in BD-ROM by adding new file management information to the volume management information indicating the BD-ROM directory-file structure.
  • the program according to the present invention is an executable program (object program) that can be executed by a computer, and executes each step of the flowchart shown in the embodiment and individual procedures of functional components to the computer. It consists of one or more program codes.
  • program codes such as processor native code and JAVA (TM) byte code.
  • TM JAVA
  • modes for realizing each step by the program code Realize each step using external functions If it can, it will be a call program code that calls this external function.
  • the program code power to realize one step may belong to different object programs.
  • each step force S in the flowchart may be realized by combining arithmetic, logical, and branch instructions.
  • a program that can be used in the present invention can be created as follows. First, a software developer uses a programming language to write a source program that implements each flowchart and functional components. In this description, the software developer uses a class structure, variables, array variables, and external function calls according to the syntax of the programming language to describe each flowchart and source program that implements functional components.
  • the described source program is given to the compiler as a file.
  • the compiler translates these source programs to generate an object program.
  • Translation by the compiler consists of processes such as syntax analysis, optimization, resource allocation, and code generation.
  • syntax analysis lexical analysis, syntax analysis, and semantic analysis of the source program are performed, and the source program is converted into an intermediate program.
  • the intermediate program is divided into basic blocks, control flow analysis, and data flow analysis.
  • resource allocation variables in the intermediate program are allocated to registers or memory of the processor of the target processor in order to adapt to the instruction set of the target processor.
  • code generation each intermediate instruction in the intermediate program is converted into program code to obtain an object program.
  • the linker allocates these object programs and related library programs in the memory space, and combines them into one to generate a load module.
  • the load module generated in this way is premised on reading by a computer, and causes the computer to execute the processing procedure shown in each flowchart and the processing procedure of functional components.
  • the program according to the present invention can be created through the above processing.
  • the program according to the present invention can be used as follows. When the program according to the present invention is used as a thread loading program, the load module corresponding to the program is written in the instruction ROM together with the basic input / output program (BIOS) and various middleware (operation system).
  • BIOS basic input / output program
  • the program according to the present invention can be used as a control program for the playback device by incorporating such an instruction ROM into the control unit and causing the CPU to execute it.
  • the playback device When the playback device is a model with a built-in hard disk, a basic input / output program (BIOS) is built into the instruction ROM, and various middleware (operation system) is preinstalled on the hard disk. It is also installed in the boot ROM power playback device for booting the system from the hard disk. In this case, only the load module is supplied to the playback device via a portable recording medium or network, and installed as a single application on the hard disk. Then, the playback device performs bootstrap with the boot ROM, starts the operation system, causes the CPU to execute the application as one application, and uses the program according to the present invention.
  • BIOS basic input / output program
  • middleware operation system
  • the hard disk model playback device can use the program of the present invention as one application, the program according to the present invention can be transferred alone, lent, or supplied through a network.
  • the controller 22 can be realized as a single system LSI.
  • a system LSI is a device in which a bare chip is mounted on a high-density substrate and packaged.
  • a system LSI that includes multiple bare chips mounted on a high-density substrate and knocked to give the bare chip the same external structure as a single LSI is also included in the system LSI.
  • system LSI types such as QFP (tad flood array) and PGA (pin grid array).
  • QFP is a system LSI with pins attached to the four sides of the package.
  • a PGA is a system LSI with many pins attached to the entire bottom surface.
  • These pins serve as interfaces with other circuits. Since pins in the system LSI have such an interface role, by connecting other circuits to these pins in the system LSI, the system LSI serves as the core of the playback device.
  • the bare chip packaged in the system LSI consists of a "front end part", a “backend part”, and a "digital processing part".
  • the “front-end part” is the part that digitizes the analog signal
  • the “back-end part” is the part that outputs the data obtained as a result of the digital processing.
  • Each component shown as an internal configuration diagram in each embodiment is mounted in this digital processing unit.
  • the load module As described earlier in “Use as embedded program”, the load module, basic input / output program (BIOS), and various middleware (operation system) are written in the instruction ROM.
  • the load module corresponding to this program is created in particular, so the system ROM according to the present invention is produced by packaging the instruction ROM storing the load module corresponding to the program as a bare chip. be able to.
  • SoC System on chip
  • SiP System in Package
  • the integrated circuit generated as described above may be referred to as an IC, an LSI, a super-LSI, or an unroller LSI depending on the degree of integration.
  • each recording / reproducing apparatus may be configured as one chip.
  • Integrated circuit implementation is not limited to the above-described SoC implementation and SiP implementation, and may be realized by a dedicated circuit or a general-purpose process. It is conceivable to use a Field Programmable Gate Array (FPGA) that can be programmed after manufacturing the LSI, or a silicon figureable 'processor that can reconfigure the connection and settings of the circuit cells inside the LSI.
  • FPGA Field Programmable Gate Array
  • semiconductor If integrated circuit technology that replaces LSI appears as a result of technological advancement or derived technology, naturally, it is also possible to use this technology to integrate functional blocks. For example, biotechnology can be applied.
  • the recording medium and the reproducing apparatus according to the present invention have the internal configuration disclosed in the above embodiment, and are apparently mass-produced based on the internal configuration, so that they can be used industrially in qualities.
  • the playback device according to the present invention has industrial applicability.

Abstract

　 　BD-ROMにはPlayList情報が記録されている。PlayList情報は、MainPath情報、SubPath情報を含み、前記MainPath情報は、複数AVClipの1つを、MainClipとして指定して、そのMainClipに対し、主たる再生区間を定義している。前記SubPath情報は、複数AVClipのうち他のものを、SubClipとして指定して、そのSubClipに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義している。 　PlayList情報はSTN_tableを含み、STN_tableは、SubClip及びSubClipに多重化された複数のエレメンタリストリームのうち、再生が許可されているものを示している。そしてSTN_tableにおいて再生が許可されている複数エレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないAVClipの単位時間(1秒)当たりの総サイズは、例えば、48Mbit以下に抑制されている。

Description

明 細 書
記録媒体、再生装置、記録方法、再生方法
技術分野
[0001] 本発明は、 Out-of-MUXフレームワークの技術分野に属する発明である。
背景技術
[0002] Out- of- MUXフレームワークとは、 BD- ROM等のリードオンリー型の記録媒体に記 録されているデジタルストリームと、リライタブル型の記録媒体である、ローカルストレ ージに記録されて 、るデジタルストリ一ムとを同時に読み出して、デコーダに供給し、 同期再生させる技術である。
ここで BD-ROMに記録されて!、るデジタルストリーム力 映画作品の本編を構成す るものであり、ローカルストレージに記録されているデジタルストリーム力 映画監督の コメンタリを構成する場合、上述した Out-of-MUXフレームワークを実現することにより 、 BD- ROM上の本編と、ローカルストレージ上のコメンタリとを再生に供して、 BD- RO Mの内容拡充を図ることができる。尚、リードオンリー型記録媒体の先行技術としては 、以下の特許文献に記載されているものがある。
特許文献 1：特願平 8— 83478号公報
発明の開示
発明が解決しょうとする課題
[0003] ところで上述した Out-of-MUXフレームワークでは、 BD- ROMに記録されたストリー ムと、ローカルストレージに記録されたストリームとを同時に読み出して、それらのスト リームを構成する TSパケットを、デコーダに供給せねばならない。このデコーダへの 供給にどれだけの帯域が必要であるかを検討すると、これら BD-ROM力もの供給ビッ トレートが 48Mbps、ローカルストレージからの供給ビットレートが 48Mbpsである場合、 ワーストケースにおいて、 96Mbit(48Mbit+48Mbit)ものデータ供給力 上述した同時 読み出しの期間内において発生する可能性がある。かかるワーストケースの発生が 考えられるなら、 96Mbpsというビットレートで TSパケットを供給できるよう装置内の帯域 を上げねばならない。またそれが不可能であるならば、デコーダ内に大きなバッファ を設けておき、当該供給が一時点に集中しないように、 TSパケットの先読みをデコー ダに行わせる必要がある。し力し上述した同時読み出しの期間力 短ければいざしら ず、 2時間という映画再生のオーダであれば、バッファの容量が不足し、充分な先読 みが行えない。
[0004] 充分な先読みが行えないため、先読みのためのバッファにアンダーフローが生じる と、ビデオ又はオーディオの欠落が発生するため再生品質が著しく低下する。力とい つて、高いビットレートでのデータ供給が必要になるなら、再生装置の低価格化を大 きく妨げる結果となる。
本発明の目的は、高い帯域を必要とせずとも、別々の記録媒体から供給されたデ ジタルストリームを、デコーダに供給することができる、記録媒体を提供することである 課題を解決するための手段
[0005] 上記目的を達成するため、本発明にかかる記録媒体は、プレイリスト情報が記録さ れ、前記プレイリスト情報は、メインパス情報、サブパス情報を含み、前記メインパス情 報は、複数デジタルストリームの 1つを、メインストリームとして指定して、そのメインスト リームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、複数デジタルストリームのうち他のものを、サブストリームとし て指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再 生区間を定義する情報であり、前記プレイリスト情報はストリームテーブルを含み、前 記ストリームテーブルは、メインストリーム及びサブストリームに多重化された複数のェ レメンタリストリームのうち、同時に再生することが許可されている組み合わせを 1っ以 上示し、ストリームテーブルにお 、て同時に再生することが許可されて 、るエレメンタ リストリームを含み、再生が許可されて 、な 、エレメンタリストリームを含まな 、デジタ ルストリームの単位時間当たりの総データサイズは、所定値以下であることを特徴とし ている。
発明の効果
[0006] ストリームテーブルにお 、て再生が許可されて!、る複数エレメンタリストリームの単 位時間当たりの総データサイズは、所定値以下であり、ワーストケースにおいても、単 位時間当たりに転送すべき TSパケットの量は、所定の上限値を上回ることはない。 例えば単位時間が 1秒であり、所定の上限値が 48Mbitである場合、ストリームの同 時読み出しのため、 TSパケットの供給量が局所的に 96Mbitにまであがったとしても、 " 1秒当たりのビット量が 48Mbit以下"に制限されるため、ワーストケースにあたる 96Mbit のデータ供給量は、 0.5秒以上継続することはな 、。
[0007] ストリームの再生時間軸上のどの時点においても「ワーストケースが 0.5秒以上継続 しない」との保障があるので、 96Mbit X 0.5秒のサイズの TSパケットを、常に先読みし てデコーダに供給するように、再生装置を構成しておけば、デコーダ内のバッファの アンダーフローを回避することができる。
「96Mbit X 0.5秒」を上限値とした先読みにより、アンダーフローを生じさせることなく 、 TSパケットを安定的にデコーダに供給することができるので、 Out-of-MUXフレーム ワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。 バ ンド幅を高めるなくことなぐ BD-ROMのみを対象としたような再生装置において、 Out -of-MUXフレームワークを実現することができるので、 Out-of-MUXフレームワークを 実現するような再生装置を、低価格で、市場に供給することができる。
[0008] また「1秒当たり 48Mbps以下」との制限があるので、再生装置は、上述したような"常 に先読みを行う"という単純な制御を実行していれば、ワーストケースとなるデータ供 給が発生したとしてもアンダーフローの発生を避けることができる。ワーストケースとな るデータ供給がいつ発生する力を予測する予測処理等の実装を省略することができ るので、再生装置を、容易に開発することができる。
図面の簡単な説明
[0009] [図 1]本発明に係る記録媒体の、使用行為についての形態を示す図である。
[図 2]BD- ROMの内部構成を示す図である。
[図 3]拡張子. m2tsが付与されたファイルがどのように構成されているかを模式的に示 す図である。
[図 4]PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納さ れるかを更に詳しく示す図である。
[図 5]ビデ才ゃ才一ディォが、プログラムストリーム、トランスポートストリームにどのよう に多重化されるかを示す図である。
[図 6]トランスポートストリームの詳細を示す図である。
[図 7]PAT、 PMTパケットの内部構成を示す図である。
[図 8]AVClipを構成する TSパケットがどのような過程を経て BD-ROMに書き込まれる かを示す。
[図 9]Aligned Unitの内部構成を示す図である。
[図 10]Clip情報の内部構成を示す図である。
[図 11]映画のビデオストリームに対する EPjnap設定を示す図である。
[図 12]PlayList情報のデータ構造を示す図である。
[図 13]AVClipと、 PlayList情報との関係を示す図である。
[図 14]ローカルストレージ 200の内部構成を示す図である。
[図 15]Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSが BD- RO M再生装置の内部構成において、デコーダにどのように供給されるかを示す図である
[図 16]PlayList情報のデータ構造を示す図である。
[図 17]Subpath情報の内部構成をクローズアップして示す図である。
[図 18]ローカルストレージ 200上の SubClipと、ローカルストレージ 200上の PlayList情 報と、 BD- ROM上の MainClipとの対応を示す図である。
[図 19] (a) STN_tableの内部構成を示す図である。
(b)ビデオストリームに対応した Stream_attributeを示す図である。
(c)オーディオストリームに対応した Stream_attributeを示す図である。
(d)ビデオストリームにおける Stream_entryを示す図である。
[図 20]BD-ROM力も読み出された TSパケットと、ローカルストレージカも読み出された TSパケットとを示し、これらの TSパケットのうち、デコーダに供給されるものを示す。
[図 21] (a)〜（d) Windowのシフトを示す図である。
[図 22]BD-ROM力も読み出された TSパケット、ローカルストレージカも読み出された T Sパケットのデータ量の時間的推移を示すグラフである。
[図 23] (a) (b)各 Windowの転送許容量と、 Windowにおけるデコーダへの供給量とを 対比して示す図である。
[図 24]Out_of_MUXアプリケーションを構成する Playltem、 SubPlayltemの接続状態を 示す図である。
[図 25]図 24に示した、 Playltemの connection— condition情報、 SubPlayltemの sp—conne ction— condition情報が" =5"に設定されて!、る場合の、 Playltemにおける In— Time、 Ou t_Timeと、 SubPlayltemにおける In_Time、 Out_Timeとの関係を示す図である。
[図 26]PlayItemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、参照 されるべき STC値、 SubPlayltemの In_Timeから Out_Timeまでに存在する部分を再生 する場合に、参照されるべき STC値を示す。
[図 27]previousPlayItemにて参照されて!、る MainClip、カレント Playltemにて参照され ている SubClipにおいて、 TS1、 TS2がどのように特定されるかを示す図である。
[図 28]CC = 5、及び、 SP_CC = 5の詳細を示す図である。
[図 29]previousPlayItem及びカレント Playltemにて指定される複数の Video Presentati on Unitと、複数の Audio Presentation Unitと、 STC時間軸との関係を示す図である。 圆 30]本発明に係る再生装置の内部構成を示す図である。
[図 31]PlayList情報に基づく再生手順のフローチャートである。
[図 32]SubPlayItemにおけるシームレス接続を示すフローチャートである。
[図 33]第 2実施形態に力かるォーサリングシステムの内部構成を示す図である。
[図 34]プライマリ TS、セカンダリ TSに対するべリファイ手順を示すフローチャートである
[図 35]同種のエレメンタリストリームが複数存在する場合の、プライマリ TS、セカンダリ
TSに対するべリファイ手順を示すフローチャートである。
[図 36]CC=6の詳細な説明を示す図である。
[図 37]PlayItemと SubPlayltemの相関を示した図である。
[図 38]ATC時間軸に存在する複数の TSパケットが、どのように多重化されるかを模式 的に示す図である。
[図 39]オーディオに加えて、字幕 (PG)やメニュー（IG)も入れ替えられる場合、プライ マリ TSを構成する複数の TSパケットと、セカンダリ TSを構成する複数の TSパケットとが 、どのように多重化されるかを模式的に示す図である。
[図 40]オーディオミキシングアプリケーションを構成するプライマリ TS、セカンダリ TSが 、 BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示 す図である。
圆 41]第 5実施形態に係る再生装置の内部構成を示す図である。
[図 42]オーディオミキシングを示すプレイリストにて指定される Playltemと SubPlayltem の相関を示した図である。
[図 43]劇場公開版とディレクターズカットの両方を構成する PlayList情報の一例を示 す図である。
符号の説明
la BD— ROMドライブ
lb，c リードバッファ
lb,a,c ATCカウンタ
2a, d Source Oepacketizer
2c，d ATCカウンタ
3a，c STCカウンタ
3b,d PID Filter
4 ビデオデコーダ
5 ビデオプレーン
6 Transport Buffer
7 Elementary Buffer
8 オーディオデコーダ
10a,b,c,d スィッチ
11 Interactive Graphicsデコ ~~ダ
12 Interactive Graphicsプレ ~~ン
13 Presentation Graphicsデコ ~~グ
14 Presentation Graphicsプレ ~~ン 21 メモリ
22 コントローラ
23 PSRセット
24 PID変換部
25 ネットワーク部
26 操作受付部
100 BD-ROM
200 ローカルストレージ
300 再生装置
400 テレビ
500 AVアンプ
発明を実施するための最良の形態
[0012] (第 1実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明 に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図 1は、 本発明に係る記録媒体の、使用行為についての形態を示す図である。図 1において 、本発明に係る記録媒体は、ローカルストレージ 200である。ローカルストレージ 200 は、再生装置 300、テレビ 400、 AVアンプ 500、スピーカ 600から構成されるホーム シアターシステムに、映画作品を供給するという用途で使用される。
[0013] 以降、 BD- ROM100、ローカルストレージ 200、再生装置 300について説明を行う。
BD-ROM100は、映画作品が記録された記録媒体である。
ローカルストレージ 200は、再生装置に組み込まれ、映画配給者のサーバから配信 されたコンテンツの受け皿として利用されるハードディスクである。
[0014] 再生装置 300は、ネット対応型のデジタル家電機器であり、 BD-ROM100を再生す る機能をもつ。また、映画配給者のサーバ 700から、ネットワークを通じてダウンロー ドしたコンテンツを、ローカルストレージ 200に格納し、こうしてローカルストレージ 200 に記録されたコンテンツと、 BD-ROM100に記録されたコンテンツと組み合わせて、 B D- ROM100のコンテンツを拡張/更新を行うことができる。 BD- ROM100の記録内容 に、ローカルストレージ 200の記録内容を組み合わせて、 BD- ROM100に記録され ていないデータを、恰も、記録されているように扱う技術を"バーチャルパッケージ"と いう。
[0015] 以上が本発明に係る記録媒体の使用形態についての説明である。
続、て本発明に係る記録媒体の生産行為につ 、て説明する。本発明に係る記録 媒体は、ファイルシステム上における改良で実現することができる。
く BD- ROMの概要 >
図 2は、 BD- ROMの内部構成を示す図である。本図の第 4段目に BD- ROMを示し、 第 3段目に BD- ROM上のトラックを示す。本図のトラックは、 BD- ROMの内周から外周 にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。こ のトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図の ボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。 ディレクトリ構造を用いて BD- ROMの応用層フォーマット (アプリケーションフォーマット )を表現すると、図中の第 1段目のようになる。この第 1段目において BD- ROMには、 R ootディレクトリの下に、 BDMVディレクトリがある。
[0016] この BDMVディレクトリの配下には、更に PLAYLISTディレクトリ、 CLIPINFディレクトリ 、 STREAMディレクトリと呼ばれる 3つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子 mplsが付与されたファイル (OOOOl.mpls)がある。
CLIPINFディレクトリには、拡張子 clpiが付与されたファイル (00001.clpi,00002.clpi) がある。
[0017] STREAMディレクトリには、拡張子 m2tsが付与されたファイル (00001.m2ts,00002.m2 ts)がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイル力 BD-ROM上に 配置されて ヽることがゎカゝる。
< BD- ROMの構成その 1.AVClip >
先ず初めに、拡張子. m2tsが付与されたファイルについて説明する。図 3は、拡張子 .m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。 拡張子. m2tsが付与されたファイル (00001.m2ts,00002.m2ts)は、 AVClipを格納してい る。 AVClipは MPEG2-Transport Stream形式のデジタルストリームである。このデジタ ルストリームは、デジタル化された映像、デジタル化された音声を (上 1段目）、 PESパ ケットからなるエレメンタリストリームに変換し (上 2段目）、更に TSパケットに変換して（ 上 3段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム (Presentatiion Gr aphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム (Interactive GraphicsdG)ストリーム)を (下 1段目、下 2段目)、 TSパケットに変換して (下 3段目)、こ れらを多重化することで構成される。
以降、これらのビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームに ついて説明する。
<ビデ才ストリーム >
ビデオストリームは、映画作品の動画像を構成するストリームであり、 SD画像、 HD画 像であるピクチャデータカゝら構成される。ビデオストリームには、 VC-1のビデオストリ ーム、 MPEG4- AVCのビデオストリーム、 MPEG2- Videoのビデオストリームといった形 式が存在する。 MPEG4-AVCのビデオストリームでは、 IDRピクチャ, Iピクチャ ,Ρピクチ ャ ,Βピクチャに、 PTS、 DTSといったタイムスタンプが付され、このピクチヤの単位で、 再生制御がなされる。このように、 PTS、 DTSが付されて、再生制御の単位となる、ビ デォストリームの一単位を" Video Presentation Unit"という。
<オーディオストリーム >
オーディオストリームは、映画作品の音声を表すストリームであり、 LPCMオーディオ ストリーム、 DTS—HDオーディオストリーム、 DD/DD+オーディオストリームや DD/MLP オーディオストリームといった形式が存在する。オーディオストリームにおけるオーディ オフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御 がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディ ォストリームの一単位を" Audio Presentation Unit"という。
< PGストリーム >
PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、 日本 語、フランス語というように複数言語についてのストリームが存在する。 PGストリームは 、 PCS(Presentation control Segment) ^ PDS(Pallet Define Segment) ^ WDS(Window D efine Segment), ODS(Object Define Segment)という一連の機能セグメントからなる。 0 DS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグ メントである。
[0019] WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量 を定義する機能セグメントであり、 PDS(Pallet Define Segment)は、グラフィクスォブジ ェタトの描画にあたっての、発色を規定する機能セグメントである。 PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである 。かかるページ制御には、 Cut-In/Out, Fade-In/Out, Color Change, Scroll, Wipe- 1 n/Outといったものがあり、 PCSによるページ制御を伴うことにより、ある字幕を徐々に 消去しつつ、次の字幕を表示させると!、う表示効果が実現可能になる。
[0020] < IGストリーム >
IGストリームは、対話制御を実現するグラフィクスストリームである。 IGストリームにて 定義される対話制御は、 DVD再生装置上の対話制御と互換性がある対話制御であ る。力力る I ストリ ~~ム【ま、 ICSQnteractive Composition segment)ゝ PDS(Palette Difinit ion Segment), ODS(Object Definition Segment)と呼ばれる機能セグメントからなる。 0 DS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメント である。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画さ れる。 PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたって の、発色を規定する機能セグメントである。 ICSOnteractive Composition Segment)は、 ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメ ントである。 ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンド を含む。
[0021] ここで AVClipは、 1つ以上の" STC_Sequence"から構成される。 "STC_Sequence"とは 、 AVストリームのシステム基準時刻である STC(System Time Clock)の不連続点 (syste m time-base discontinuity)が存在しない区間をいう。 STCの不連続点はデコーダが S TCを得るために参照する PCR(Program Clock Reference)を運ぶ PCRパケットの不連 続情報 (discontinuityjndicator)が ONである点である。
[0022] 図 4は、 PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格 納されるかを更に詳しく示している。本図における第 1段目は、ビデオストリームを示し 、第 3段目はオーディオストリームを示す。第 2段目は、 PESパケット列を示す。本図の 矢印 yyl,yy2,yy3,yy4に示すように、ビデオストリームにおける複数の Video Presentati on Unitである IDR、 Bピクチャ、 Pピクチャは、複数に分割され、個々の分割部分が、 P ESパケットのペイロード (図中の V#1,V#2,V#3,V#4)に格納されることがわかる。またォ 一ディォストリームを構成する Audio Presentation Unitであるオーディオフレームは、 矢印 aal ,aa2に示すように、個々の PESパケットのペイロード (図中の A#l ,A#2)に格納 されていることがわ力る。
[0023] 図 5は、ビデ才ゃ才一ディォが、プログラムストリーム、トランスポートストリームにどの ように多重化されるかを示している。下段は、ビデオストリームと、オーディオストリーム とを格納した複数の PESパケット (図中の V#1,V#2,V#3,V#4,A#1,A#2)を示す。ビデオ ストリーム及びオーディオストリームは、別個の PESパケットに格納されることが本図か らゎ力る。上段は、下段の PESパケットを格納したプログラムストリーム及びトランスポ 一トストリームを示す。プログラムストリームに多重化される場合、 PESパケットは、 1パ ックに収められる。トランスポートストリームに多重化される場合、 PESパケットは分割さ れ、個々の分割部分は、複数の TSパケットのペイロードに格納される。 BD- ROMにお ける格納方式は、前者のプログラムストリームではなぐ後者のトランスポートストリーム のものとなる。図 5ではそのようになっていないが、トランスポートストリームに使われる ビデオ PESパケットは 1つのフレーム、もしくはペアとなる 2つのフィールドを格納する のが一般的である。
[0024] 図 6は、トランスポートストリームの詳細を示す図である。本図における第 1段目は、 MPEG2トランスポートストリームを構成する複数の TSパケット列であり、第 2段目は TS パケットの内部構成を示す。この第 2段目に示すように、 1つの TSパケットは、 "ヘッダ "と、 "適用フィールド（adaptation field) "と、 "ペイロード"と力も構成される。引き出し 線 thlは、 TSパケットヘッダの構成をクローズアップしている。このこの引き出し線に示 すように、 TSパケットヘッダには、 PESパケットの先頭を格納していることを示す「ュ- ット開始表示 (payload_unit_start_indicator)」、トランスポートストリームに多重ィ匕される エレメンタリストリームの種別を示す「PID (Packet Identifier)」、 TSパケットに適用フィ 一ルドが存在している力否かを示す「適用フィールド制御」などが存在する。
[0025] 引き出し線 th2は、適用フィールドの内部構成をクローズアップしている。適用フィー ルドは TSパケットヘッダの適用フィールド制御が" Γに設定されている場合に、 TSパ ケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、 エントリーポイントであることを示す「ランダムアクセス表示（random_access_indicator)」 、 T— STD (Transport System Target Decoder)の ¾ i C (System Time Clock)を与 る「 PCR (Program Clock Reference)」などが、この適用フィールドに格納される。
[0026] 図 7は、 PAT、 PMTパケットの内部構成を示す図である。これらのパケットは、トラン スポートストリームのプログラム構成を記述するものである。
本図における引き出し線 hmlは、トランスポートストリームに存在する PID=0の TSパケ ットの構成をクローズアップしている。かかる TSパケットは、 PAT (Program Association Table)パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。 PATパケ ットの PIDは常に" 0"である。 PATパケットには、 PAS (Program Association Section)が 格納される。引き出し線 hm2は、 PASの内部構成をクローズアップしている。この引き 出し線に示すように PASは、 program_number (番糸且番号)と、 program map table(PMT の PID)とを対応付けて示している。引き出し線 hm3は、トランスポートストリームに存在 する PID=0xl00の TSパケットの構成をクローズアップしている。力かる TSパケットは、 P MTパケットと呼ばれる。引き出し線 hm4に示すように、 PMTパケットの PMSは、その PM Sに対応する番組に含まれるストリーム種別を示す「stream_type」と、そのストリームの PIDである「elementary_PID」とを含む。本図の例では、番糸且番号 #1の番糸且は、 PID=0x 100の PMTを有しており、 PID=0x200と 0x201とを有する MPEG2ビデオと、 ADTSォー ディォとが、この番組番号 #1の番組を構成していることがわかる。このようにして、常に PID=0である PATから PMTの PIDを取得し、この PMTの PIDから PMTパケットを取得し て、 PMSを参照することで、トランスポートストリーム中の番組と、その構成ストリームの PIDやストリームタイプとを知得することができる。
[0027] 続いて、以上のように構成された AVClip力 BD- ROMにどのように書き込まれる力 を説明する。図 8は、 AVClipを構成する TSパケットがどのような過程を経て BD-ROM に書き込まれるかを示す。本図の第 1段目に AVClipを構成する TSパケットを示す。 AVClipを構成する 188バイトの TSパケットは、第 2段目に示すように 4バイトの TS_extr ajieader (図中のハッチング部)、が付されて、 192バイト長の Sourceパケットになる。こ の TS_extra_headerは、当該 TSパケットのデコーダ入力時刻情報を示す Arrival_Time_ Stampを含む。 ATSヘッダを TSパケットごとに付与してストリームを形成する理由は、 T Sパケットごとにデコーダ（STD)への入力時刻を与えるためである。デジタル放送では トランスポートストリームは固定ビットレートとして扱われる。そのため、 NULLパケットと 呼ばれるダミーの TSパケットを多重化して固定ビットレートとしたトランスポートストリー ムを放送して 、る。光ディスクのような限られた記録容量の記録媒体にストリームを記 録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である 。そのため BD- ROMでは NULLパケットを記録することはしない。そして、可変ビットレ ートの記録方式に対応するため、個々の TSパケットに ATSを付与した上でトランスポ 一トストリームを記録する。この ATSを用いることで、 TSパケットごとにデコーダ入力時 刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降 、 ATSヘッダと TSパケットの 1組をソースパケット（Source Packet)と呼ぶ。
[0028] AVClipを構成する Sourceパケットは、第 3段目における AVClipにおいて、 1つ以上 の" ATC_Sequence"を構成する。 "ATC_Sequence"とは、 Sourceパケットの配列であつ て、その Arrival— Time— Stamp ^参照し飞 ヽる Arrival— Time— Clockに、 , 連腕 \no arnv al time-base discontinutiy)が存在しないものをいう。いい力えれば、その ArrivaLTime _Stampが参照している Arrival_Time_Clockに、連続性が存在する Sourceパケット列を" ATC— Sequence"と！、う。
[0029] かかる ATC_Sequenceが AVClipになり、 xxxxx.m2tsというファイル名で BD- ROMに記 録される。
かかる AVClipは、通常のコンピュータファイル同様、 1つ以上のファイルエクステント に分割され、 BD-ROM上の領域に記録される。第 4段目は AVClipがどのように BD-R OMに記録されるかを模式的に示す。この第 4段目においてファイルを構成する各フ アイルエクステントは、予め定められた Sexetent以上のデータ長を有する。
[0030] AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの 最小データ長 Sexetentを検討する。 ここで BD- ROMにおいて光ピックアップのジャンプに要する時間は、 Tjump = Taccess+Toverhead
で与えられる。
Taccessは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時 間である。
BD- ROM力も読み出された TSパケットは、リードバッファと呼ばれるバッファに格納 された上、デコーダに出力される力 リードバッファへの入力力 Rudというビットレート で行われ、 ECCブロックにおけるセクタ数を Seccとした場合、
丄、 overneadi 、
Toverhead≤ (2 X Secc X 8)/Rud = 20m秒
という計算で与えられる。
BD- ROM力も読み出された TSパケットは、 Sourceパケットの状態でリードバッファに 格納された上、 TS_Recording_rateという転送レートで、デコーダに供給される。
[0031] TS_Recording_rateという転送レートでの、デコーダへの TSパケット供給が跡絶えさ せないためには、 Tjumpの間、リードバッファからデコーダへの TSパケット出力が継続 している必要がある。ここでリードバッファからの出力は、 TSパケットではなぐ Source パケットの状態でなされるので、 TSパケットの Sourceパケットとのサイズ比を 192/188と した場合、 Tjumpの間、（192/188 X TS_Recording_rate)という転送レートにより、リード バッファからの Sourceパケット出力が継続している必要がある。
従って、リードバッファ力 アンダーフローしないためのバッファ蓄積量は、
Boccupied≥ (Tjump/ 1000 X 8) X ((192/188) X TS— Recording— rate)
となる。
リードバッファへの入力レートは Rud、リードバッファからの出力レートは TS_Recordin g_rate X (192/ 188)であるので、リードバッファへの蓄積レートは、入力レート一出カレ ートの計算で与えられ、 (Rud - TS_Recording_rate X (192/188》になる。
[0032] この Boccupiedを、リードバッファに蓄積するのに要する時間 Txは、
Tx = Boccupied/(Rud— TS— Recording— rate X (192/188))
になる。 BD-ROMからの読み出しには、この時間 Txにおいて Rudでの TSパケット入力を継続 する必要があるので、 AVClipを複数のエクステントに分割して記録する場合の、エタ ステント一個当たりの最小データ長 Sexetentは、
¾exetent = Rud X Tx
= Rud X Boccupied/(Rud— TS— Recording— rate X (192/188))
≥ Rud X (Tjump/1000 X 8) X ((192/188) X TS— Recording— rate)
/(Rud—TS— Recording— rate X (192/188))
≥ (Rud X Tjump/1000 X 8) X
X TS— Recording— rate X 192/(Rud X 188— TS— Recording— rate X 192)
になる。
よって
Sexetent≥
(Tjump X Rud/ 1000 X 8) X
(TS— Recording— rate X 192/(Rud X 188— TS— Recording— rate X 192》
になる。
AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさな いように算出された Sextent以上のデータ長をもつことにより、 AVClipを構成する各フ アイルエクステントが、 BD-ROM上において離散的に位置されたとしても、再生時に おいてデコーダへの TSパケット供給が途絶えさせることなぐ連続的に読み出される ことになる。
上述したファイルエクステントは、 Sourceパケット 32個集めたァラインドユニット（Align ed Unit, 6KByteのデータサイズ）を最小単位として構成されている。したがって、 BD でのストリームファイル（XXXXX.AVClip)のファイルサイズは常に 6KByteの倍数とな る。
図 9は、 Aligned Unitの内部構成を示す図である。 Aligned Unitは、 32個の Sourceパ ケットから構成され、連続する 3つのセクタに書き込まれる。 32個の Sourceパケットから なるグループは、 6144バイト (=32 X 192)であり、これは 3個のセクタサイズ 6144バイト (= 2048 X 3)と一致する。 BD-ROMにおけるセクタは、 32個単位で誤り訂正符号が付され 、 ECCブロックを構成する。再生装置は Aligned Unitの単位で BD- ROMをアクセスす る限り、 32個の完結した Sourceパケットを得ることができる。以上が BD-ROMに対する AVClipの書き込みのプロセスである。 BD- ROMに記録され、高画質なビデオストリー ムが多重化されている AVClipを、以下" MainClip"と呼ぶ。これに対し、ローカルストレ ージに記録され、 MainClipと同時に再生される AVClipを、 "SubClip"とよぶ。
[0034] BD- ROMに記録されている MainClipに対して、多重分離を行うことで、パーシャルト ランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々の エレメンタリストリームに対応するものである。 MainClipを多重分離することで得られる パーシャルトランスポートストリームであって、 1つのエレメンタリストリームに対応するも のを"プライマリ TS"という。
< BD- ROMの構成その 2.Clip情報 >
続 、て拡張子 .clpiが付与されたファイルにつ 、て説明する。拡張子 .clpiが付与され たファイル (00001.clpi,00002.clpi)は、 Clip情報を格納している。 Clip情報は、個々の A VClipについての管理情報である。図 10は、 Clip情報の内部構成を示す図である。 本図の左側に示すように Clip情報は、
OAVClipについての情報を格納した『ClipInfoO』、
ii) ATC Sequence'STC Sequenceに関する情報を格納した『Sequence InfoO』 iii) Program Sequenceに関する情報を格納した『Program InfoO』
iv)『Characteristic Point Info(CPlO)』からなる。
[0035] Cliplnfoには、この Clip情報が参照する AVClipのアプリケーションタイプ（application _type)がある。力かる Cliplnfoを参照することで、アプリケーションタイプによって MainC lipか SubClipかや、動画を含んで!/、るのか静止画 (スライドショー)を含んで!/、るのかな どが識別できる。また Cliplnfoには、上述した TS_recording_rateが記述されて!、る。
Sequence Infoi 、 AVClip【こ れ 、 1つ W上の ¾ i，C— ¾equence、 ATし— Sequencedこ ついての情報である。これらの情報を設けておくことの意義は、 STC、 ATCの不連続 点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、 AV Clip内において同じ値の PTS,ATSが出現する可能性があり、再生時に不都合が生じ る。 STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでで あるかを示すため、 Sequence Infoは設けられている。
[0036] Program Infoとは、 Program内容が一定である区間 (Program Sequence)を示す情報 である。 Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム 同士の集まりである。 Program Sequence情報を設けておくことの意義は、 Program内 容の変化点を、予め再生装置に通知するためである。ここでの Program内容の変化 点とは、ビデオストリームの PIDが変化したり、ビデオストリームの種類が SD画像から H D画像に変化して 、る点等を！、う。
続いて Characteristic Point Infoについて説明する。図中の引き出し線 cu2は、 CPI の構成をクローズアップしている。引き出し線 cu2に示すように、 CPIは、 Ne個の EP_ma p— for— one— stream— PID(EP— map— for— one— stream— PID[0]〜EP— map— for— one— stream— PID[N e-1])からなる。これら EP_map_for_one_stream_PIDは、 AVClipに属する個々のエレメン タリストリームについての EP_mapである。 EP_mapは、 1つのエレメンタリストリーム上に おいて、 Access Unitが存在するエントリー位置のパケット番号 (SPN_EP_start)を、ェン トリー時刻 (PTS_EP_start)と対応づけて示す情報である。図中の引き出し線 cu3は、 EP _map_for_one_stream_PIDの内部構成をクローズアップして 、る。
[0037] これによると、 EP_map_for_one_stream_PIDは、 Nc個の EP_High(EP_High(0)〜EP_High (Nc-1))と、 Nf個の EP丄 ow(EP丄 ow(0)〜EP丄 ow(Nf-l》とからなることがわかる。ここで E P— Highは、 Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の SPN— EP— start及び PTS— EP —startの上位ビットを表す役割をもち、 EP丄 owは、 Access Unit(Non- IDR Iピクチャ、 ID Rピクチャ)の SPN_EP_start及び PTS_EP_startの下位ビットを示す役割をもつ。
[0038] 図中の引き出し線 cu4は、 EP_Highの内部構成をクローズアップしている。この引き 出し線に示すように、 EP_High(i)は、 EP丄 owに対する参照値である『ref_to_EP丄 ow_id[i ]』と、 Access Unit(Non-IDR Iピクチャ、 IDRピクチャ)の PTSの上位ビットを示す『PTS_E P_High[i]』と、 Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の SPNの上位ビットを示 す『SPN_EP_High[i]』と力もなる。ここで iとは、任意の EP_Highを識別するための識別子 である。
[0039] 図中の引き出し線 cu5は、 EP丄 owの構成をクローズアップしている。引き出し線 cu5 に示すように、 EP丄 owは、対応する Access Unitが IDRピクチャか否かを示す『is_angle — change_point(EP丄 ow_id)』と、対応する Access Unitのサイズを示す『し end_position_off set(EP丄 ow_id)』と、対応する Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の PTSの 下位ビットを示す『PTS_EP丄 ow(EP丄 owjd)』と、対応する Access Unit(Non- IDR Iピク チヤ、 IDRピクチャ)の SPNの下位ビットを示す『SPN_EP丄 ow(EP丄 ow_id)』とからなる。こ こで EP丄 owjdとは、任意の EP丄 owを識別するための識別子である。
[0040]
< Clip情報の説明その 2.EP_map>
以下、具体例を通じて、 EPjnapについて説明する。図 11は、映画のビデオストリー ムに対する EPjnap設定を示す図である。第 1段目は、表示順序に配置された複数の ピクチャ (MPEG4-AVCに規定された IDRピクチャ、 Iピクチャ、 Bピクチャ、 Pピクチャ)を 示し、第 2段目は、そのピクチヤにおける時間軸を示す。第 4段目は、 BD-ROM上の T Sパケット列を示し、第 3段目は、 EPjnapの設定を示す。
[0041] 第 2段目の時間軸において、時点 tl〜t7に、 Access Unitとなる IDRピクチャ及び Iピ クチャが存在するものとする。そしてこれらの tl〜t7の時間間隔が、 1秒程度であると すると、映画に用いられるビデオストリームにおける EPjnapは、 tl〜t7をエントリ一時 刻 (PTS_EP_start)として示し、これに対応づけてエントリー位置 (SPN_EP_start)を示す よう、設定される。
< PlayList情報 >
続いて、 PlayList情報について説明する。拡張子" mpls"が付与されたファイル (0000 1.mpls)は、 PlayList(PL)情報を格納したファイルである。
[0042] 図 12は、 PlayList情報のデータ構造を示す図であり、本図において、引き出し線 mp 1に示すように PlayList情報は、 MainPathを定義する MainPath情報 (MainPathO)と、チ ャプターを定義する PlayListMark情報 (PlayListMarkO)を含む。
< PlayList情報の説明その 1.MainPath情報 >
先ず MainPathについて説明する。 MainPathは、主映像たるビデオストリームゃォー ディォストリームに対して定義される再生経路である。
[0043] MainPathは、矢印 mplで示すように複数の Playltem情報 #1 · · · '#mから定義される。
Playltem情報は、 MainPathを構成する 1つの論理的な再生区間を定義する。 Playltem 情報の構成は、引き出し線 hslによりクローズアップされている。この引き出し線に示 すように Playltem情報は、再生区間の IN点及び Out点が属する AVClipの再生区間情 報のファイル名を示す『ClipJnformation_file_name』と、 AVClipの符号化方式を示す『 Clip_codec_identifier』と、 Playltemがマルチアングルを構成するか否かを示す『is_mult i— angle』と、この Playltem (カレント Playltemリと、その 1っ刖の PlayItem(previousPlayItem )との接続状態を示す『connection_condition』と、この Playltemが対象として!/、る STC_S equenceを一意に示す『reむ o_STC_id[0]』と、再生区間の始点を示す時間情報『In_tim e』と、再生区間の終点を示す時間情報『Out_time』と、この Playltemにおいてマスクす べきユーザオペレーションがどれであるかを示す『UO_mask_table』と、この Playltemの 途中へのランダムアクセスを許可するか否かを示す『PlayItem_random_access_flag』と 、この Playltemの再生終了後、最後のピクチャの静止表示を継続する力否かを示す『 Still_mode』と、『STN_table』とカゝら構成される。このうち、再生経路を構成するのは、再 生区間の始点を示す時間情報『In_time』、再生区間の終点を示す時間情報『Out_tim e』の組みであり、再生経路情報とは、この『In_time』及び『Out_time』の組み力 構成 される。
[0044] 図 13は、 AVClipと、 PlayList情報との関係を示す図である。第 1段目は、 PlayList情 報がもつ時間軸 (PlayList時間柳を示す。第 2段目から第 5段目は、 EPjnapにて参照 されて!/ヽるビデ才ストリームを示す。
PlayList情報は、 Playltem情報 #1, #2と!、う 2つの Playltem情報を含んでおり、これら P layltem情報 #1,#2の In_time,Out_timeにより、 2つの再生区間が定義されることになる。 これらの再生区間を配列させると、 AVClip時間軸とは異なる時間軸が定義されること になる。これが第 1段目に示す PlayList時間軸である。このように、 Playltem情報の定 義により、 AVClipとは異なる再生経路の定義が可能になる。
[0045] 以上が、 BD-ROM100についての説明である。
<ローカルストレージ 200 >
続いて、本発明に力かる記録媒体である、ローカルストレージ 200について説明す る。図 14は、ローカルストレージ 200の内部構成を示す図である。本図に示すように 、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。 [0046] 本図の第 4段目にローカルストレージ 200を示し、第 3段目にローカルストレージ 20 0上のトラックを示す。本図のトラックは、ローカルストレージ 200の内周から外周にか けて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このト ラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリ ユーム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレ クトリ構造を用いてローカルストレージ 200の応用層フォーマット (アプリケーションフォ 一マット)を表現すると、図中の第 1段目のようになる。
[0047] 本図のディレクトリ構造において ROOTディレクトリの配下には、「organization#l」と いうサブディレクトリがあり、その配下に、「disc#l」というサブディレクトリがある。ディレ クトリ「organization#l」とは、映画作品の特定のプロバイダに割り当てられたディレクト リである。「disc#l」は、そのプロバイダが提供した BD-ROMのそれぞれに割り当てら れたディレクトリである。
[0048] 特定のプロバイダに対応するディレクトリに、各 BD-ROMに対応するディレクトリを設 けることにより、各 BD- ROMについてのダウンロードデータが個別に格納される。この サブディレクトリの配下に、 BD- ROMに格納されていたのと同様、 PlayList情報 (00002 .mpls)、 Clip情報 (00003. clpi,00004.clpi)、 AVClip(00003.m2ts,00004.m2ts)が格納さ れている。
続いて、ローカルストレージ 200の構成要素となる、 PlayList情報、 Clip情報、 AVCli pについての説明する。
[0049] <ローカルストレージ 200の構成その 1. AVClip >
ローカルストレージ 200上の AVClip(00003.m2ts,00004.m2ts)は、 SubClipを構成す る。この SubClipに対して、多重分離を行うことで、パーシャルトランスポートストリーム が得られる。 SubClipを多重分離することで得られるパーシャルトランスポートストリー ムを"セカンダリ TS"という。力かるセカンダリ TSは、 Out_of_MUXアプリケーションを構 成するものである。以降、 Out_of_MUXアプリケーションについて説明する。
( Out- of- MUXアプリケーション）
Out- of- MUXアプリケーションとは、例えば、 BD- ROM上のプライマリ TSと、ネットヮ ークなどを介して取得して、ローカルストレージに記録されたセカンダリ TSの 2つの TS を同時に再生選択することで、この 2本の TS間で様々なエレメンタリストリームの組み 合わせを可能とするアプリケーションである。
[0050] 図 15は、 Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSが、 B D-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図 である。本図では、 BD-ROM再生装置の内部構成のうち、 BD-ROMドライブ装置、口 一力ルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、 ストリームの多重分離を行う PID Filterを示す。そして本図におけるプライマリ TS(Vide 01.Audio 1 (English) ,Audio2(Spanish) , PG 1 (English Subtitle), IG1 (English Menu))ゝセカ ンダリ TS(Audio2(Japanese),Audio3(Korean),PG2(Japanese Subtitle) , PG3(Korean Sub title),IG20apanese Menu),IG3(Korean Menu))は、それぞれ BD- ROM、ローカルストレ ージカゝら供給されるトランスポートストリームを示す。ディスク単体には英語 (Audio 1) とスペイン語 (Audio 2)しか記録されていないため、 日本語吹き替えなどをこのデイス タカも選択することはできない。し力しながら、コンテンツプロバイダが提供する日本 語吹き替え（Audio 2)の入ったセカンダリ TSを、ローカルストレージにダウンロードす れば、 日本語吹き替え音声 (Audio 2)と、 日本語字幕 (PG 2)と、 日本語メニュー画面 (IG 2)とを、デコーダに送り込むことができる。こうすることでユーザーは、 日本語吹き 替え音声 (Audio 2)と、 日本語字幕 (PG 2)とを、 日本語メニュー画面 (IG 2)から選択 して、映像 (Videol)と共に再生することができる。
[0051] Out-of-MUXアプリケーションは、同時に再生される 2つの TSの中に格納されたェ レメンタリストリームの種別ごとに 1つまで (言い換えれば、プライマリ TSとセカンダリ TS に格納されているビデオ 1本、オーディオ 1本、字幕 1本、メニュー 1本まで）という制 限下で、ユーザーが自由に、音声及び字幕を選択することができる。
全ての BD-ROM再生装置はプライマリ TS単体をデコードできる能力は持つ力 2つ の TSを同時にデコードする能力はない。したがって、 Out-of-MUXアプリケーションを 制限なく導入した場合には、ハードウェアの大規模ィ匕や、ソフトウェアを多く追加せざ るを得なくなり、 BD- ROM再生装置のコストアップに繋がる。そのため、 Out-of-MUX アプリケーションの実現にあたっては、プライマリ TSだけをデコードできるリソース上で 、 Out_of_MUXのアプリケーションを実現することができるかどうかどうかが鍵となる。 [0052] エレメンタリストリームの種別ごとに 1つまで、再生を許可するという制限は、プライマ リ TSのエレメンタリストリームをセカンダリ TSのエレメンタリストリームで「入れ換える」と 考えればよい。そのようにすることで、 1本の TSをデコードするリソース上で、 Out_of_M UXアプリケーションを実現することができ、デコーダ側のコストアップを抑制することが できる。本図の例では、プライマリ TSのオーディオ、字幕 (PG)、メニュー（IG)ストリー ムをセカンダリ TSのそれらと入れ換えて!/、る。
[0053] セカンダリ TSは、上述したようなローカルストレージである内蔵 HDDの他、フラッシュ メモリや一次記憶メモリ、ネットワーク越しの HDDや直接ネットワークを介したストリーミ ングなど力も入力されることもある。説明の便宜上、セカンダリ TSは、図 1に示したよう な内蔵型の HDDから供給されるものとする。
<ローカルストレージ 200の構成その 2.Clip情報 >
ローカルストレージ上に存在する Clip情報 (00003.clpi,00004.clpi)は、基本的には、 BD- ROMに記録されているものと同じデータ構造をもつ。ここでローカルストレージ上 の Clip情報の TS_Recording_Rateは、 BD- ROMからの AVClip読み出しと同じビットレー トに設定されている。つまり SubClipの Clip情報に記述された TS_Recording _Rateと、 M ainClipの Clip情報に記述された TS_Recording _Rateとは同一である。仮に、 MainClip の TS_Recording _Rateの値と、 SubClipの TS_Recording_Rateとが異なると、夫々の Sour ce De-packetizerから、バッファに送り込むまでのデータレートがどちらの TSを送り込 むかによって異なることになり、 Out-of-MUXアプリケーションは 1つの入力 TSと仮定 できるという仮定が成り立たなくなる。
[0054] また、 2つの TS間で再生されるべきエレメンタリストリームは、自在に選択されるので 、プライマリ TSのオーディオが選択されれば Source De- packetizerからデコーダ内の バッファまで力 プライマリ TS用のビットレートに設定され、セカンダリ TSのオーディオ が選択されると Source De-packetizerからデコーダ内のバッファまでが、セカンダリ TS のためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑 になってしまうからである。
くローカルストレージ 200の構成その 2.PlayList情報 >
続いて、ローカルストレージ 200上の PlayList情報について説明する。拡張子" mpls "が付与されたファイル (00002.mpls)は、 MainPath, Subpathと呼ばれる 2種類の再生 経路を束ねたものを Playlist(PL)として定義する情報である。図 16は、 PlayList情報の データ構造を示す図であり、本図に示すように PlayList情報は、 MainPathを定義する MainPath情報 (MainPathO)と、チャプターを定義する PlayListMark情報 (PlayListMark( ；))と、 Subpathを定義する Subpath情報 (SubpathO)とからなる。力かる PlayList情報の内 部構成、及び、 Playltem情報の内部構成は、 BD-ROMのものと同じであり、説明を省 略する。以降、 Subpath情報について説明する。
< PlayList情報の説明その 1.Subpath情報 >
MainPathが、主映像たる MainClipに定義される再生経路であるのに対し、 Subpath は、 MainPathと同期すべき SubClipに対して定義される再生経路である。
[0055] 図 17は、 Subpath情報の内部構成をクローズアップして示す図である。本図におけ る矢印 hcOに示すように Subpath情報は、 SubClipの類型を示す SubPath_typeと、 1っ以 上の SubPlayltem情報 (· · · SubPlayltemO · · とを含む。
図中の引き出し線 hclは、 SubPlayltem情報の構成をクローズアップしている。 SubPl ayltem情報は、図中の矢印 hclに示すように『Clip jnformation_file_name』、『Clip_code c— identifier』、『SP— connection— condition』、『ref— to— ¾ f C— id[0]』、 [[SubPlayltem— In— time』 、『SubPlayItem— Out— time』、『sync— Playltem— id』、『sync— start— PTS— of— Playltem』からな る。
[0056] 『Clip_information_file_name』は、 Clip情報のファイル名を記述することにより、 SubPla yltemに対応する SubClipを一意に指定する情報である。
『Clip_codec_identifier』は、 AVClipの符号化方式を示す。
『SP— connection— condition』は、この SubPlayltem (カレント SubPlayltem)と、その 1つ前 の SubPlayltem(previousSubPlayltem)との接続状態を示す。
[0057] 『reむ o_STC_id[0]』は、この Playltemが対象として!/、る STC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、 SubClipの再生時間軸上における、 SubPlayltemの始点を 示す情報である。
『SubPlayItem_Out_time』は、 SubClipの再生時間軸上における、 SubPlayltemの終点 を示す情報である。 [0058] 『sync_PlayItem_id』は、 MainPathを構成する Playltemのうち、本 SubPlayltemが同期 すべきものを一意に指定する情報である。 SubPlayltem— In— timeは、この sync— Playltem— idで指定された Play Itemの再生時間軸上に存在する。
『sync_start_PTS_of_PlayItem』は、 sync_PlayItem_idで指定された Play Itemの再生時 間軸上にぉ 、て、 SubPlayItem_In_timeで指定された SubPlayltemの始点力 どこに存 在するかを示す。
[0059] < SubPath情報につ!、ての詳細その 2.三者の関係 >
ここでの三者とは、ローカルストレージ 200上の SubClip、ローカルストレージ 200上 の PlayList情報、 BD- ROM上の MainClipの三者を!、う。
図 18は、ローカルストレージ 200上の SubClipと、ローカルストレージ 200上の PlayLi st情報と、 BD- ROM上の MainClipとの対応を示す図である。本図において第 1段目は 、ローカルストレージ 200上に存在する SubClipを示す。この第 1段目に示すように、口 一力ルストレージ 200上の SubClip内のセカンダリ TSには、オーディオストリーム、 PG ストリーム、 IGストリームといった種別がある。これらのうち何れ力が、 SubPathとして同 期再生に供されることになる。
[0060] 第 2段目は、 PlayList情報により定義される 2つの時間軸を示す。第 2段目のうち下側 の時間軸は、 Playltem情報により定義される PlayList時間軸を示し、上側の時間軸は SubPlayltemにより定義される SubPlayltem時間軸を示す。
本図に示すように、 SubPlayltem情報の SubPlayltem— Clip— information— file— nameは、 S ubClipを格納した. m2tsファイルのうち、どれを再生区間の対象として選ぶかという、 Su bClip選択の役割を果たして 、ることがわかる。
[0061] そして SubPlayItem.IN_time、 SubPlayltem.OuUimeは、 SubClip上の、再生区間の始 点及び終点を定義するという役割を果たしていることがわかる。
矢印 Sync_PlayItem_Idは、どの Playltemとの同期を意図して!/、る力と 、う同期指定の 役割を果たし、 sync_start_PTS_of_PlayItemは、 PlayList時間軸上における SubPlayltem Jn_timeの位置を決める役割を果たす。
[0062] 以上が、 SubPath情報についての説明である。
< STN— table > このローカルストレージ 200上の PlayList情報にお!、て特徴的であるのは、 STN_Ta bleである。以降、ローカルストレージ 200上の PlayList情報について説明する。
STN_tableは、 Playltem情報の Clip_Information_file_nameで指定されている MainClip に多重化された複数エレメンタリストリーム、及び、 SubPlayltem情報の Clipjnformatio n_file_nameで指定された SubClipに多重化されている複数エレメンタリストリームのうち 、同時に再生することが許可されている組み合わせを 1つ以上示すテーブルである。 PlayList情報における STN_Tableにおいて、同時に再生することが許可されている複 数エレメンタリストリームは、いわゆる"システムストリーム，，を構成することになる。
[0063] 具体的にいうと STN_tableは、 MainClipに多重化されている複数エレメンタリストリー ム、 SubClipに多重化されて!/、るエレメンタリストリームのそれぞれにつ!/、ての Stream_e ntryを、 Stream_attributeと対応付けることで構成される。
図 19 (a)は、 STN_tableの内部構成を示す図である。本図に示すように STN_tableは 、 STN_tableにおける entryと、 attributeとの組み (entry- attribute)を複数含み、これら e ntry— attriouteの糸且みの個数 (number— of— video— stream— entries, number— of— audio— strea m—entnes,number— of— Ptj— stream— entries, number— of— IG— stream— entries)を すァ ~~タ概 造になっている。
[0064] entry-attributeの組みは、図中の括弧記号" { "に示すように、 Play Itemにおいて再 生可能なビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームのそれぞ れに対応している。
entry— attributeの詳細につ!、て説明する。
[0065] 図 19 (b)は、ビデオストリームに対応した Stream_attributeを示す図である。
ビデオストリームにおける Stream_attributeは、ビデオストリームの表示方式を示す『 Video_format』と、ビデオストリームの表示周波数を示す『frame_rate』等を含む。
図 19 (c)は、オーディオストリームに対応した Stream_attributeを示す図である。 オーディオストリームにおける Stream_attributeは、オーディオストリームの符号化方 式を示す『stream— coding— type』と、対応するオーディオストリームのチャネル構成を示 す『audio_presentation_type』と、対応するオーディオストリームのサンプリング周波数 を示す対応する『Sampling_frequency』と、オーディオストリームの言語属性を示す『au diojanguage code』力もなる Q
[0066] 図 19 (d)は、ビデオストリームにおける Stream_entryを示す図である。本図に示すよ うに、ビデオストリームの Stream_entryは、ビデオストリームの多重分離に用いられる PI
Dを示す「ref_to_Stream_PID_of_Main_Clip」を含む。
MainClipにて多重化されているオーディオストリーム、 IGストリーム、 PGストリームの S tream_attributeは、この図 19 (d)の开式になっている。
[0067] <再生が許可されて!、るエレメンタリストリームのデータ量制限 >
STN_tableは、 BD- ROMから読み出されるエレメンタリストリーム、ローカルストレージ 力 読み出されるエレメンタリストリームのうち、再生が許可されて 、るものを示すが、 かかる STN_tableが、無制限に、エレメンタリストリームの再生を許可しているとなると、 デコーダシステムの破綻を招く恐れがある。
[0068] その理由は、以下の通りである。 MPEG2のデコーダシステム標準によると、 1つのト ランスポートストリームにおける ATC時間軸の TSパケット間には、オーバーラップが存 在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせる ための基本原則である。一方、 BD-ROMにおけるストリームの再生が許可されると共 に、ローカルストレージにおけるストリームの再生が許可されており、 BD- ROMからの AVClip再生と、ローカルストレージからの AVClip再生とを同時に実行する場合、 BD- ROMからの TSパケットと、ローカノレストレージからの TSパケットとにオーバーラップが 生じてしまう。
[0069] そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課し ている。
デコードエレメンタリストリームとは、 STN_tableにおいて再生が許可されていて、一 緒に再生するため、選択されたビデオストリーム、オーディオストリーム、 PGストリーム 、 IGストリームである。デコードエレメンタリストリームには、ローカルストレージからの読 み出されるものと、 BD-ROM力も読み出されるものの両者がある。
[0070] デコードエレメンタリストリームに課される制限とは、 STN_tableにおいて同時に再生 することが許可されて 、るエレメンタリストリームを含み、再生が許可されて ヽな 、エレ メンタリストリームを含まない AVClip(MainClip,SubClip)を構成する TSパケット (Decodin g TSパケット)の、 1秒当たりのビット量は 48Mbit以下になるというものである。
この 1秒という単位時間は、 "Window"と呼ばれ、 ATC Sequenceの時間軸上の任意 の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのよ うな 1秒の期間においても、この 48Mbit以下という条件を満たす必要がある。
[0071] 図 20は、 BD-ROMから読み出された TSパケットと、ローカルストレージカも読み出さ れた TSパケットとを示し、これらの TSパケットのうち、デコーダに供給されるものを示す 。本図の第 1段目は、 BD- ROM力も読み出された複数の TSパケット、第 3段目は、ロー カルストレージカも読み出された複数の TSパケットを示す。これら第 1段目、第 3段目 の TSパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構 成する TSパケット (Decoding TSパケット)である。本図における第 2段目は、第 1段目に 示した Decoding TSパケット、第 3段目に示した Decoding TSパケットのうち、 1秒という 期間に属すものを示す。上述したように、 MPEG2のデコーダシステム標準によると、 1 つのトランスポートストリームにおける ATC時間軸の TSパケット間には、オーバーラッ プが存在してはならない。し力し、本図によると、 ATC時間軸において、 TSパケット間 のオーバーラップ rpl,rp2,rp3が発生していることがわかる。このように、 Windowという 単位時間において、 TSパケット動作のオーバーラップが許容されているのである。し かし、 MPEG2のデコーダシステム標準にはない別の要件が課されている。それが上 述した、 lWindow当たり 48Mbit以下という制限である。第 4段目は、この第 2段目に示 す、 Decoding TSパケットが満たすべき条件を数式で表している。この数式の意味は、 上述した Decoding TSパケットの個数を、ビット数に換算した値 (TSパケットのバイト数 である 188をかけ、ビット数 8で表した値)力 48Mbit以下になるというものである。
[0072] 任意の 1秒という期間において、 Decoding TSパケットに以上のような条件を課すの 力 本実施形態におけるビット量の制限である。 Out_of_MUXアプリケーションのため のォーサリング時には、 Sourceパケット列において、かかる Windowを、 1パケットずつ シフトさせつつ、 1秒という期間内の、 Decoding TSパケットのビット数力 48Mbit以下と いう制限を満たす力どうかをチェックする。もし、制限を満たせば、次の TSパケットに W indowをシフトさせ、制限を満たさねば、 BD-ROM規格に違反していると断定する。そ して、力かるシフトを繰り返した結果、 Windowの Out_Timeが、最後の Sourceパケットに 達すれば、当該 Sourceパケットは、 BD-ROM規格に整合しているとの判定を下す。
[0073] < Windowのシフト >
TSパケットのそれぞれには、 27MHzの時間精度をもつ ATSが付与されている。 ATC 時間軸上の座標は、 1/27,000,000秒という時間精度をもつ力 この ATC時間軸上の 各座標に、 ATSが存在するとは限らない。 ATC時間軸には、 ATSがまったく存在しな い期間や、 ATSが存在する期間が不規則に現れる。 ATSの出現にバラツキがあるの で、 Windowをシフトするにあたって、 In_Timeから 1秒後に ATSが存在しない場合、 Win dowの Out_Timeをどのように調整するかが問題になる。
[0074] Windowの Out_Timeは、原則として In_Timeの 1秒として設定される。ここで ATC時間 軸において、 In_Timeの 1秒後にあたる座標に ATSが存在すれば、 In_Time + l秒の座 標を、 Out_Timeとする。もし In_Timeの 1秒後にあたる座標に ATSが存在しなければ、 I n_Time + l秒以降であって、 ATSが初めて現れる ATC時間軸の座標を、 Out_Timeと する。 ATSの空白期間を考慮しながら Out_Timeを調整しつつ、 Windowをシフトしてゆ くので、 Windowがシフトする度に、異なるビット値が算出される。 In_Timeを ITSパケット ずつシフトしてゆき、これに伴い Out_Timeを調整することで、 ATC時間軸におけるビッ ト値の遷移を緻密に計算してゆくことができる。
[0075] 図 21は、 Windowのシフトを示す図である。（a)〜（d)のそれぞれのうち、上段はベリ フアイの対象となる Sourceパケット列を示し、下段は、 Windowの In_Time、 Out_Timeを 示す。同図（a)では、 Windowの In_Timeは、 Sourceパケット ffiを指定している。この Win dowの In_Timeから 1秒後に存在する TSパケット 'が、 Windowの Out_Timeに設定される 同図（b)では、 Windowの In_Timeは、 Sourceパケット ffi+1を指定している。一方、この Windowの In_Timeから 1秒後にお 、て、 Sourceパケット ·+1にあたる座標には、 Source パケットの ATSが存在しない。この（b)における Windowの Out_Timeは、 TSパケット 'を 越えたものになるが、 TSパケット ·の直後に、 Sourceパケットが存在しないため、（b) の Windowにおけるビットレートは、（a)の Windowにおけるビットレートより少なくなつて しまう。これでは、（b)の Windowは、チェックに値しなくなる。そこで、 Out_Timeの調整 により、 Windowの In_Timeから 1秒以降に初めて現れる TSパケット ·+2を、 Windowの 0 ut_Timeにする。 Out_Timeをこのように設定すれば、（b)の Windowは、チェックに値す るちのとなる。
[0076] 同図（c)では、 Windowの In_Timeは、 Sourceパケット ffi+2を指定して!/、る。一方、この Windowの In_Timeから 1秒後には、 Sourceパケット ·+2が位置している。この（c)の Win dowは、 TSパケットの数が、（b)の Windowにおける数と変わらず、チェックに値しない 。故に、この（c)では、チェックが行われず、更に Windowの In_Timeを進める。
同図（d)では、 Windowの In_Timeは、 Sourceパケット ffi+3を指定している。一方、この Window_In_Timeから 1秒後において、 Sourceパケット '+3にあたる位置には、 Sourceパ ケットが存在しない。そこで上述したような Out_Timeの調整を行い、 Windowの In_Time 力 1秒以降に初めて現れる TSパケット ·+4を、 Windowの Out_Timeとする。こうするこ とで、 Window内の TSパケット数は、（b)と違うものとなり、チェックに値する。
[0077] 以上のような Windowシフトを伴う、ビット量チェックをォーサリング時に実行すること で、ローカルストレージ及び BD- ROMから TSパケットが読み出され、デコーダに供給 されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。 以上の Windowシフトによる保障を、図 22〜図 26の具体例を参照しながら説明する 図 22の第 1段目は、 BD- ROMから読み出された TSパケット、ローカルストレージから 読み出された TSパケットのデータ量の時間的推移を示すグラフである。横軸は時間 軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、 B D- ROM及びローカルストレージからの読み出し時のビット量は、破線の曲線のように 推移する。
[0078] 図 22の第 2段目は、 BD- ROMから読み出された TSパケット、ローカルストレージから 読み出された TSパケットのうち、デコーダに供給されるものの合計のデータ量を示す 。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量 は、 STN_tableで許可されたストリームに属する TSパケットの合計量となる。ワーストケ ースにおいては、合計の転送量が 96Mbit近くになり、このデータ量の TSパケットが供 給されると考えられる。グラフの時間軸を、 7つの Windowに分割して、個々の Window における供給量と、 Window毎の転送許容量とを対比する。 [0079] 図 22の第 3段目は、この図 22の第 2段目におけるグラフを 1秒という期間で区切った ものであり、図 23 (a) (b)は、各 Windowの転送許容量と、 Windowにおけるデコーダへ の供給量とを対比して示す図である。 Windowにおける転送許容量は、 1秒当たり 48M bitであり、 0.5秒に換算すれば 96Mbitとなる。図中のパターン pnlのハッチングは、デ コーダへのデータ供給量を示す。図中のパターン pn2のハッチングは、 Window毎の 転送許容量を示す。パターン pnlのハッチングが付された部分の面積力 何れの Win dowにおいても、パターン pn2のハッチングが付された部分の面積以下になっている。 これは、 BD- ROM及びローカルストレージからのデータ供給量が、どの Windowにお いても、 Windowにおける転送許容量以下に抑えられていることを意味する。
[0080] ATC時間軸上のどの時点においても、 1秒当たりのデコーダへの転送許容量は、 48 Mbit以下になるので、たとえ局所的に、デコーダへの転送許容量が 96Mbit近くにな つたとしても、 48Mbit = 96Mbit X 0.5秒の計算により、力かる 96Mbitでの転送が 0.5秒 継続することはありえない。従ってデコーダが、このピークが到来する前に、 BD-ROM 、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダ 一フロー又はオーバーフローが生じることはな 、。
[0081] Windowにおける転送許容量、つまり、 1秒当たり 48Mbitという数値は、 MPEGに準拠 したデコーダ力 ノ ッファに先読みできる数値を、目安にして定めたものである。バッ ファに先読みできるデータ量力 もっと大きい場合は、 1秒当たりのデータ量を更に大 きくしたり、また Windowの時間長を更に長くすることができる。このことから、本発明に 力かる数値範囲は、 1秒当たり 48Mbitというものに、限定されるべきでない。
[0082] 以上が、 STN_tableにおいて再生が許可されているセカンダリ TSにおけるデータ量 制限についての説明である。
、 connection— condition†青報、 sp— connection— condition†青報の設定
次に、 Out_of_MUXアプリケーションを実現する場合の、 Playltemにおける connectio n— conmtion†青報、及び、 SubPlayltemにおける sp— connection— condition†青報の設定に 、て説明する。 connection— condition†*報のフィ ~~ノレドの値、 sp— connection— conditi on情報のフィールドの値は" Γ, "5", "6"の値を取る事ができ、それぞれ以下のような 意味を持つ。 [0083] connection— condition=l(CC=l)： この Playltem (カレント Playltem)と直前の Playltem( previousPlayltem)とはシームレス接続される保証がない。つまり、フリーズして再生が 途切れることが許容された接続形態 (ノンシームレス接続)である。
connection_condition=5(CC=5)： カレント Playltem側の MainClipに多重化されて!/ヽ るビデオストリーム、 PGストリーム、 IGストリームと、 previousPlayltem側の MainClipに多 重化されているビデオストリーム、 PGストリーム、 IGストリームとがシームレス接続され る保証がある。一方、 MainClipに多重化されているオーディオストリームについてはこ の限りではない。
[0084] connection— condition=6(CC=6)： カレント Playltemと previousPlayltemに属するそれ ぞれの TSストリームは論理的に連続であり（時間軸が連続しており、符号化方式も連 続している）、オーディオストリーム、ビデオストリームともにシームレス接続される保証 がある。
SubPlayltemfti内に記述された sp_connection_condition情報は、次のように定義がで きる。
[0085] sp— connection— condition情報 (SP—CC=1)： この SubPlayltem (カレント SubPlayltem)と 直前の SubPlayltem(previousSubPlayltem)とはシームレス接続される保証がない sp_connection_condition情報 (SP_CC=5) :カレント SubPlayltem側の SubClipに多重ィ匕 されている PGストリーム、 IGストリームと、 previousSubPlayltem側の SubClipに多重化さ れている PGストリーム、 IGストリームとがシームレス接続される保証がある。一方、 Sub Clipに多重化されて!/、るオーディオストリームにつ 、てはこの限りではな!/、。
[0086] sp— connection— condition情報 (SP—CC=6) : カレント SubPlayltemと、 previousSubPlaylt emとに属するそれぞれの TSストリームは論理的に連続しており（時間軸が連続してお り、符号ィ匕方式も連続している）、シームレス接続される保証がある。
Out_of_MUXアプリケーションを実現する Playltemに対して設定されるべき SubPlaylt emは、 SubPlayltem内のビデオストリームやオーディオストリーム、または PGストリーム や IGストリームが Playltem内にあつたとしても不整合を起こさないようにすべきである。 そのため、全く同一の接続条件となる。つまり Playltem#l、 Playltem#2力CC=1で接続 されるならば、それに対応する SubPlayItem#l、 SubPlavItem#2も CC=1で接続される。 同様に、 Playltem#l、 Playltem#2が CC=5で接続されるならば、それに対応する SubPl ayltem#l、 SubPlayItem#2も CC=5の条件を満たしながら接続される。
以下、図 24、図 25、図 26を参照しながら、 Out_of_MUXアプリケーションを構成する Playltem ^ SubPlayltemの In— Time、 Out— Timeの関係と、 connection— condition†青報の羊 細について説明する。
[0087] < In— Time、 Out— Timeの関係 >
図 24は、 Out_of_MUXを構成する Playltem、 SubPlayltemの接続状態を示す図であ る。本図における第 1段目は、 SubClip時間軸であり、第 2段目、第 3段目は、 SubPlaylt em時間軸、 PlayList時間軸である。第 4段目は、 MainClip時間軸である。本図におい て、 Playltem側の connection— condition情報力 ' = 5"である場合、 SubPlayltem側の con nection— condition情報 、 SP—し C = 5にな 。
[0088] 図 25は、図 24に示した、 Playltemの connection_condition情報、 SubPlayltemの sp_c onnection_condition情報が" =5"に設定されている場合の、 Playltemにおける In_Time 、 Out_Timeと、 SubPlayltemにおける In_Time、 Out_Timeとの関係を示す図である。第 1 段目、第 4段目は図 24と同じである。図 24に示した 2つの PlayItem(PlayItem情報 #1、 Playltem情報 #2)のうち、 Playltem情報 #1の In_Timeは、時刻 tlを表し、 Out_Timeは、 時刻 t2を表す。 Playltem情報 #2の In_Timeは時刻 t3、 Playltem情報 #2の Out_Timeは、 時刻 t4を表す。
[0089] Playltem側の接続状態力CC = 5に設定されていると、 SubPlayltemにおける Sync_St art_Pts_of_PlayItemは、 Playltemの In_Timeと同じ時点を示す。そして SubPlayltemにお ける In_Time、 Out_Timeは、 Playltemの In_Time、 Out_Timeと同じ時刻を表す。このよう に、 Playltemの connection— condition†青報力 21 =o 場合、 ¾ub Playltemの sp— conn ection_condition情報も" =5"に設定され、尚且つ、 Playltemの In_Time、 Out_Timeは、 SubPlayltemの In_Time、 Out_Timeと同一時点を表す。
[0090] Playltemの In_Time、 Out_Time、 SubPlayltemの In_Time、 Out_Timeは、それぞれ Vide o Presentation Unit, Audio Presentation Unitの PTSを参照している。 Playltemの In_Ti me、 Out_Timeと、 SubPlayltemの In_Time、 Out_Timeとが一致しているということは、 Pla yltemの In— Time、 Out— Timeで参照 れ video Presentation Unit、 Audio Presentatio n Unitの PTS値が、 SubPlayltemの In_Time、 Out_Timeで参照される Video Presentation Unit, Audio Presentation Unitの PTS値と同じであることを意味する。そうすると、プラ ィマリ TS、セカンダリ TSは、時間長が同じで、ォーサリング時において Video Presenta tion Unit, Audio Presentation Unitの PTSが、同じになるよう、エンコードされる必要が ある。このようにプライマリ TS、セカンダリ TSを作成しておくことも、 CC = 5、 SP_CC=5を 実現するにあたっての条件になる。
[0091] <同期再生するにあたって、参照すべき STC値 >
図 26は、 Playltemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、 参照されるべき STC値、 SubPlayltemの In_Timeから Out_Timeまでに存在する部分を 再生する場合に、参照されるべき STC値を示す。第 2段目、第 3段目は、前図に示し たものと同じである。第 1段目は、 SubPlayltemの In_Timeから Out_Timeまでに存在する 部分を再生する場合に、参照されるべき STC値をグラフ形式で示している。第 4段目 も、 Playltemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、参照さ れるべき STC値をグラフ形式で示している。第 1段目における横軸は時間軸であり、 縦軸は時間軸上の各時点における STC値を表す。第 1段目における STC値は、 SubPl ayltem情報 #1の In_Timeから Out_Timeまでの期間における単調増力 Uzklと、 SubPlaylt em情報 #2の In_Timeから Out_Timeまでの期間における単調増カロ zk2とからなる。第 4 段目における STC値は、 Playltem情報 #1の In_Timeから Out_Timeまでの期間における 単調増加 zk3と、 Playltem情報 #2の In_Timeから Out_Timeまでの期間における単調増 カロ zk4とからなる。
[0092] Playltemの In_Timeは、 SubPlayltemの In_Timeと同じ時点を表すので、上述したグラ フにおいて、 STCの初期値は同じであり、途中の時点においても同じなる。つまり、 P1 ayltemの In_Timeから Out_Timeまでに存在する任意の時点 iの Sourceパケットをデコー ダに供給する際、参照すべき STC値である STC2G)は、 SubPlayltemの In_Timeから Out _Timeまでに存在する同じ時点 iの Sourceパケットをデコーダに供給する際、参照すベ き STC値である STCl(i)と同じになる。 STC値が同じであると、装置内の STCカウンタは 、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置におけ る制御が簡略化される。 [0093] 仮に、上述した図 25、図 26の制限に反し、 1つの Playltemに対して 2つ以上の SubPl ayltemを準備した場合、その SubPlayltemの境界において、映像や音声が途切れてし まい、 Playltemの途中で再生が一時停止するなどの不便が生じる。また、 Out-of-MU Xアプリケーションにおいて、プライマリ TSをセカンダリ TSに入れ換えるという処理を実 現する場合、この入れ替えの前後で、 STC時間軸を切り替える必要があるので、再生 装置における同期制御が複雑化する。一方、 Playltem、もしくは SubPlayltemの In_Tim e、 Out_Timeを共に、一連続な STC時間軸に定義した場合、上述したような途切れや トランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、 1 つの Playltemに対して同一の開始点、同一の終了点を SubPlayltemにもたせるのであ る。
[0094] < In— Time、 Out— Timeの誤差 >
ここで Playltemにおけ。 In— l ime、 Out— Timeと、 SubPlayltemにおける In— Time、 Out— Ti meとの一致は、完全に一致していることを要求するのではなぐ多少の誤差を許容す る趣旨である。この In_Time、 Out_Time間の誤差について説明する。
Playltemの In_Time、 Out_Timeとなる STC時刻は、 Playltemがビデオフレームに対し て設定される。これに対し、 SubPlayltemではオーディオフレームに対して設定される こととなる。何故なら、 SubPlayltemは、コメンタリが主用途でビデオストリームが多重化 されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションュ ニットの再生時間長の違いから、開始/終了時刻が合わない。したがって、最低でも、 1フレーム未満の誤差を認める必要がある。 Playltemftiと SubPlayltemftiの開始/終了 時刻に関して、どちらも同一の STC時間軸に対して、
I (Piayltem#n.uut- Playltenwn.In) - (¾ubPiayItem#n.uut— time- ¾ubPiayItem#n.In— ti me) I≤ Playltemftiの中で最小の再生時間を持つビデオの 1プログレッシブフレーム もしくは 2インターレースフィールドの再生時間≤ 1/60秒
としても規定する。上記左辺の値は、 Playltemftiの中で最大の再生時間を持つビデ ォの 1プログレッシブフレームもしくは 2インターレースフィールドの再生時間（≤ 1/25 秒）としても良いし、 1秒以下などとしても良い。
以上が、 Playltem, SubPlayltemにおける In_Time、 Out_Timeの関係についての説明 である。
[0095] 次に、 connection— condition†青報、 sp— connection— condition†青報につ ヽて詳しく説明 する。 CC = 5、 SP_CC=5の条件を満たすには、 AVストリームのレベル、トランスポート ストリームのレべノレ、 Video Presentation Unit及び Audio Presentation Unitのレべノレ、 エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要が ある。
<AVストリームのレベル >
Current Playltemの connection— condition情報、及ひ、 sp— connection— condition情報 力 S "5"に設定されていることは、 Previous Playltemで再生される AVストリームの終了点 と、 Current Playltemで再生される AVストリームの開始点との間に、 "Clean Break"が 存在することを意味する。
[0096] Clean Breakを実現するには、 Previous Playltemで再生される AVClipと、 Current PI ayltemで再生される AVストリームと力 以下の要件を満たさねばならな！/、。
(1) Previous Playltemで指定されている MainClipの終了点に、不必要な Access Unit が存在せず、 PTSを有する不要な Access Unitが、 Previous Playltemの Out_Time以降 力 排除されていること。
[0097] 同様に、 Previous SubPlayltemで指定されている SubClipの終了点に、不必要な Acc ess Unitが存在せず、 PTSを有する不要な Access Unit力 Previous SubPlayltemの Ou t_Time以降力 排除されて 、ること。
(2) Current Playltemにて指定される AVストリームの開始点において、 PTSをもつ不 要な Access Unitが、 Current Playltemの In_Timeの前から取り除かれていること。そし て、 MainClipの最初の Audio Presentation Unitが、 STC時間軸の In_Timeで再生され る Sampleを含んで 、ること。
[0098] 同様に、 Current SubPlayltemにて指定される AVストリームの開始点において、 PTS をもつ不要な Access Unit力 Current SubPlayltemの In_Timeの前から取り除かれてい ること。そして、 SubClipの最初の Audio Presentation Unitが、 STC時間軸の In_Timeで 再生される Sampleを含んで!/、ること。
(3) Previous Playltemにて指定される MainClipを構成する全ての Sourceパケットが、 Current Playltemにて指定される MainClipの先頭パケットが送り込まれる前に、デコー ダシステムに取り込まれるように、多重化されること。
[0099] 同様に、 Previous SubPlayltemにて指定される SubClipの全データが、 Current SubPl ayltemにて指定される SubClipの先頭パケットが送り込まれる前に、デコーダシステム に取り込まれるように、多重化されること。
以上が、 AVストリームにおいて満たすべき条件についての説明である。続いて、トラ ンスポートストリームのレベルにおいて満たすべき条件について説明する。
<トランスポートストリームのレベル >
ここで CC = 5にお!/、てシームレス接続の対象となる 2つのプライマリ TSを、プライマリ TS1、プライマリ TS2と呼ぶ。 SP_CC=5においてシームレス接続の対象となる 2つのプラ ィマリ TSを、セカンダリ TS1、セカンダリ TS2と呼ぶ。
[0100] 図 27は、 previousPlayItem、 previousSubPlayltemにて参照されて 、る AVClip、カレ ント Playltem、カレント SubPlayltemにて参照されている AVClipにおいて、 TS1、 TS2が どのように特定されるかを示す図である。本図における第 4段目は、プライマリ TS1、プ ライマリ TS2を示し、第 3段目は、 previousPlayltem側の MainClipl、カレント Playltem側 の MainClip2を示す。第 1段目は、セカンダリ TS1、セカンダリ TS2を示し、第 2段目は、 previousSubPlayltem側の SubClipl、カレント SubPlayltem側の SubClip2を示す。
[0101] プライマリ TS1は、 MainCliplにおいて、ハッチングが付されたデータから構成される 。 MainCliplにおけるハッチングが付されたデータは、 Previous Playltemにおける In_Ti meに対するデコードを開始することができる Sourceパケットから始まる。かかる Source ノヽケットは、 In— Time ^参照して ヽる Video Presentation Unit及ぴ Audio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、 MainCliplの 最後のパケットで終わる。
[0102] プライマリ TS2は、 MainClip2においてハッチングが付されたデータから構成される。
MainClip2においてハッチングが付されたデータは、 MainClip2の最初の Sourceバケツ ト力 始まる。そして MainClipにおいてハッチングが付されたデータは、カレント Playlt emに対するデコードを終了する Sourceパケットで終わる。力かる Sourceパケットは、 Cu rrent Playltemの Out— Timeで参照される Video Presentation Unit, Audio Presentation Unitの末尾に位置する Sourceパケットである。
[0103] セカンダリ TS1は、 SubCliplにおいて、ハッチングが付されたデータから構成される 。 SubCliplにおけるハッチングが付されたデータは、 previousSubPlayltemにおける In_ Timeに対するデコードを開始することができる Sourceパケットから始まる。力かる Sourc eノヽケットは、 In— Time力参照して ヽる Video Presentation Unit及ぴ Audio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、 SubCliplの 最後のパケットで終わる。
[0104] セカンダリ TS2は、 SubClip2においてハッチングが付されたデータ力も構成される。 S ubClip2においてハッチングが付されたデータは、 SubClip2の最初の Sourceパケットか ら始まる。そして SubClipにおいてハッチングが付されたデータは、カレント Playltemに 対するデコードを終了する Sourceパケットで終わる。力かる Sourceパケットは、カレント ubPlayltemの Out— Timeで参照 れる Video Presentation Unit, Audio Presentation U nitの末尾に位置する Sourceパケットである。
[0105] 以上の説明から、 CC = 5、 SP_CC=5において、接続すべき 2つのトランスポートストリ ームが、 MainClip、 SubClip内に、どのように配置されるかがわかる。 previousPlayltem 側の MainClipは、 previousPlayltemの Out_Timeで参照される Video Presentation Unit 、 Audio Presentation Unitで終わっていなければならず、カレント Playltem側の MainC lipも、カレント Playltemの In_Timeで参照される Video Presentation Unit, Audio Presen tation Unitで始まらなければならない。この関係は、 previousSubPlayltemの同様であ り、 previousSubPlayltem側の SubClipは、 previousSubPlayltemの Out_Timeで参照され る Audio Presentation Unitで終わっていなければならず、カレント SubPlayltem側の Su bClipも、カレント SubPlayltemの In_Timeで参照される Audio Presentation Unitで始まら なければならな 、。これは上述したように、 previousSubPlayltemの Out_Timeから参照 される Video Presentation Unit、 Audio Presentation Unit以降に、余分な Audio Prese ntation Unitは存在してはならないからである。一方、 previousSubPlayltem側の SubCli pは、 previousSubPlayltemの In— Timeで参照 れる Audio Presentation Unitで始ま 必 要はなぐカレント SubPlayltem側の SubClipも、カレント SubPlayltemの Out_Timeで参 照される Audio Presentation Unitで終わる必要はない。 [0106] 以上の図 24、図 27から、プライマリ TS、セカンダリ TSは、同じ時間長に構成され、 Vi deo Presentation Unit, Audio Presentation Unitの PTS値が同一値になるように作成 されねばならな ヽ。更に previousPlayltem側の MainClip、 previousPlayltem側の SubCli pは、 Out— Timeにあたる Video Presentation Unit、 Audio Presentation Unitで終わるよ う、多重化されねばならず、カレント Playltem側の MainClip、カレント Playltem側の Sub し lipi 、 In— Time【こあ 7こる Video Presentation Unit、 Audio Presentation Unitで開始す るよう、多重化されねばならない。
[0107] そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
• TS1と TS2におけるプログラム数が 1つであること
'ビデオストリームの数力 S1つであること
'オーディオストリーム数が同じであること
•Previous Playltemにおける STN— tableと、 Current Playltemにおける STN— tableとは 同じ内容になること
.個々の Playltemにおけるトランスポートストリームの再生期間は 3秒
以上が、 CC = 5、 SP_CC=5で 2つのストリームを接続するにあたってトランスポートス トリームのレベルで満たすべき条件である。続いて、 Video Presentation Unit, Audio Presentation Unitのレベルで満たすべき条件につ!、て説明する。
Video Presentation Unit、 Audio Presentation Unitのレヘル〉
CC = 5とは、本来、別々である答のプライマリ TS1たるビデオストリームの最後の Vide 0 Presentation Unitの開始時刻と、プライマリ TS2たるビデオストリームの最初の Video Presentation Unitの終了時刻とを一致させることをいう。 Video Presentation Unitの 終了時刻 ·開始時刻を一致させようとすると、かかる Video Presentation Unitと同期再 生すべき Audio Presentation Unitの扱いが問題になる。何故なら、ビデオと、オーデ ィォとではサンプリング周波数が異なり、 Video Presentation Unit, Audio Presentatio n Unitの時間長は一致しないからである。
[0108] 図 28は、 CC = 5、及び、 SP_CC = 5の詳細を示す図である。第 1段目〜第 3段目は、 ubPlayltemにおける connection— condition 不し、束 4段目〜弟 7段目は、 Playltemに おける sp_connection_conditionを示す。第 4段目は、 TS1、 TS2における複数の Video P resentation Unit 不し、第 5段目は、 TS1における Audio Presentation Unit、 TS2にお ける Audio Presentation Unitを示す。第 6段目は、 MainClipにおける STCの値を示す 。第 7段目は、 MainClipにおけ Sourceパケット列を示す。
[0109] 本図において、ハッチングが付されているのは、 TS1側の Video Presentation Unit, Audio Presentation Unit, Sourceパケットであり、ハッチングが付されていないのは、 T S21則の Video Presentation Unit、 Audio Presentation Unit、 Sourceノヽケットで te 。 本図において CC = 5とは、 Video Presentation Unit境界を一致させるものの (第 4段 目）、 MainClipの ATCにおいてギャップがあり (第 7段目）、 MainClipの Audio Presentati on Unitでオーバラップが存在する (第 5段目）状態をいう。 SP_CC=5とは、 SubClipの AT Cにおいてギャップがあり (第 1段目）、 SubClipの Audio Presentation Unitでオーバラッ プが存在する (第 2段目 )状態を ヽぅ。
[0110] 上述した Video Presentation Unitの境界とは、 TS1側から見ればと、第 4段目におけ る最後の Video Presentation Unitの終了点 PTSl(lstEnd)+Tppにあたり、 TS2側から見 れば、第 4段目における Video Presentation Unitの開始点 PTS2(2ndSTART)にあたる
TS1のうち、境界時点 T4に一致する Audio Presentation Unitの終了点を T5a、 TS2の うち、時点 T4に一致する Audio Presentation Unitの開始点を T3aとした場合、 MainCli pにおけるオーバラップは、 Audio Presentation Unitは T3aから T5aにまでとなる。
[0111] また本図にお 、て、 SubClipの Audio Presentation Unitは、 MainClipの Audio Presen tation Unitより長くなつている。これは、 SubClipにおけるオーディオストリームはネット ワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、その ため Audio Presentation Unitlつ当たりの時間長が長くなる力もである。この第 1段目 における Sourceパケット列においても、第 7段目同様のギャップが存在し、第 2段目に おける Audio Presentation Unitにおいても、第 4段目と同様のオーバーラップが存在 している。 SubClipの TS1における Audio Presentation Unitのうち、境界時点 T4に一致 する Audio Presentation Unitの終了点を T5b、 SubClipの TS2における Audio Presentat ion Unitのうち、時点 T4に一致する Audio Presentation Unitの開始点を T3bとした場 合、オーバラップは T3bから T5bまでとなる。 [0112] この図から、 CC = 5、 SP_CC=5を実現するには、 Video Presentation Unit, Audio Pr esentation Unit,パケットのレベルにおいて、以下の 4つの条件を満たさねばならな いことがわ力る。
(1)TS1におけるオーディオストリームの最後の Audio Presentation Unitは、 previous Playltem, previousSubPlayltemにて指定される TSlにおける最後のビデオのピクチャ の表示期間の終期に等しい再生時刻をもつサンプルを含む。
[0113] (2)TS2におけるオーディオストリームの、最初の Audio Presentation Unitは、カレント Playltem,カレント SubPlayltemにて指定される TS2の最初のピクチャの表示期間の先 頭と等 Uヽ再生時刻をもつサンプルを含む。
(3)接続点の Audio Presentation Unit列において、ギャップが存在しない。これは接 続点において、 Audio Presentation Unit列のオーバーラップが発生してもよいことを 意味する。しかしかかるオーバーラップは、 2つのオーディオフレーム再生期間より短 Vヽ大きさでなければならな！/、。
[0114] (4)TS2の最初のパケットは、 PATを含み、 1つ以上の PMTがその直後に後続してもよ い。 PMTが TSパケットのペイロードより大きければ、 PMTは、 2パケット以上になること もある。 PMTを格納した TSパケットには、 PCRや SITが存在してもよい。
< In— Time、 Out— Timeと Video Presentation Unitとの関係 >
図 29は、 previousPlayltem及びカレント Playltemにて指定される複数の Video Prese ntation Unitと、複数の Audio Presentation Unitと、 STC時間軸との関係を示す図であ る。第 1段目は、 previousPlayltemが参照している TS1に帰属する複数の Video Presen tation Unitと、カレント Playltemが参照している TS2に帰属する複数の Video Presentat ion Unitとを示し、第 2段目は previousSubPlayltemが参照しているタイムスタンプに帰 属している複数の Audio Presentation Unitと、カレント SubPlayltemが参照している TS2 に帰属する複数の Audio Presentation Unitとを示す。第 3段目は、 previousSubPlaylte mの TSlにおける STC時間軸と、カレント SubPlayltemの TS2における STC時間軸とを示 す。第 2段目に示す TS1における Audio Presentation Unit, TS2における Audio Presen tation Unitのうち、 TS2に属する Audio Presentation Unitの開始点 T3bから、 TS2に該 当する Audio Presentation Unitの終了時刻 T5bまでがオーバラップになるのは、図 28 に示した通りである。そしてカレント SubPlayltemの In_Time、 previousSubPlayltemの Ou t_Timeは、それぞれ、 Video Presentation Unitの境界である時点 T4を指定している。 カレント Playltemの In_Time、 SubPlayltemの Out_Timeもまた、 Video Presentation Unit の境界である時点 T4を指定しているので、 Playltemの In_Time、 Out_Timeは、 SubPlayl temの In_Time、 Out_Timeと一致して 、ることになる。このように previousSubPlayltemの I n_Time、カレント SubPlayltemの Out_Timeは、 BD- ROMとは異なる記録媒体に記録さ れているにも拘らず、 MainClipにおける Video Presentation Unitの境界と一致してお り、更にまた、 previousPlayltemの Out_Time、カレント Playltemの In_Timeと一致してい ることがゎカゝる。
[0115] 以上が Video Presentation Unit, Audio Presentation Unitレべノレの条件についての 詳細である。
くエレメンタリストリームのレベル >
次に、 CC = 5、 SP_CC=5実現のための、エレメンタリストリームレベルでの符号化条 件について説明する。
[0116] 個々のエレメンタリストリームのレベルでは、以下の符号ィ匕条件を満たす必要がある
(1)ビデオストリーム
'シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、 •シームレス接続の直前のビデオストリームは、 sequence_end_code(MPEG- 2 Video 時)、 end_of_ sequence_rbsp(MPEG-4 AVC時)で完了すること、
(2)オーディオストリーム
•同一の PIDをもつオーディオストリームの符号化方式が変わらな!/、こと、 サンプリング周波数や量子化ビット数、チャンネル数などが変わらな 、こと、
(3) PGストリーム
a)TSl及び TS2における PGストリームの数が同一である。
[0117] b)TSlにおける PGストリームは、 End of Display Setと呼ばれる機能セグメントで終了 して ヽること
c)TSlにおける最後の PCSを運ぶ PESパケットの PTSは、 previous Playltem、 previous SubPlayltemの Out_Timeにあたる再生時刻より早 、時点を示す。
d)TS2の PGストリームは、 Epoch Start, Epoch Continueタイプの Display Setから始ま らねばならない。
[0118] e)TS2における最初の PCSを運ぶ PESパケットの PTSは、カレント Playltem、カレント Su bPlayltemの In_Timeにあたる再生時刻と等し!/、か、より遅!、時点を示す。
DTS2からの Sourceパケットが続ぐ TS1力もの Sourceパケットの取り出しは、同じシス テム時間軸の、 STC1、 STC2として定義することができ、これらの DTS値/ PTS値には 重複が存在しない。
(4)IGストリーム
a)TSl及び TS2における IGストリームの数が同一である。
[0119] b)TSlにおける IGストリームは、 End of Display Setと呼ばれる機能セグメントで終了 して ヽること
c) TSlにおける最後の ICSを運ぶ PESパケットの PTSは、 previousPlayItem、 previousS ubPlayltemの Out_Timeにあたる再生時刻より早い時点を示す。
d) TS2の IGストリームは、 Epoch Start.Epoch Continueタイプの Display Setから始まら ねばならない。
[0120] e)TS2における最初の ICSを運ぶ PESパケットの PTSは、カレント Playltem、カレント Su bPlayltemの In_Timeにあたる再生時刻と等し!/、か、より遅!、時点を示す。
DTS2からの Sourceパケットが続ぐ TS1力もの Sourceパケットの取り出しは、同じシス テム時間軸の、 STC1、 STC2として定義することができ、これらの DTS値/ PTS値には 重複が存在しない。
previousPlayltemと、カレント Playltemとを CC = 5で接続し、 previousSubPlayltemと、 カレント SubPlayltemとを SP_CC=5で接続するには、以上の AVストリームのレベル、トラ ンスポートストリームのレべノレ、 Video Presentation Unit及び Audio Presentation Unit のレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならな い。
[0121] 以上がローカルストレージ 200の構成たる PlayList情報についての説明である。
以上で本発明に力かる記録媒体にっ 、ての説明を終える。続 、て本発明に係る再 生装置について説明する。
図 30は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生 装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は 、主としてシステム LSIと、ドライブ装置という 2つのパーツからなり、これらのパーツを 装置のキャビネット及び基板に実装することで工業的に生産することができる。システ ム LSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうし て生産される再生装置は、 BD- ROMドライブ la、リードバッファ lb,c、 ATCカウンタ 2a, c.Source Depacketizer2b,d、 ATCカウンタ 2c,d、 STCカウンタ 3a,c、 PID Filter3b,d、 ビデオデコーダ 4、 Transport Buffer(TB)4a、 Multiplexed Buffer(MB)4b、 Coded Pictu re Buffer(CPB)4c、ビデオデコーダ 4d、 Re-order Buffer4e、スィッチ 4f、ビデオプレー ン 5、オーディオデコーダ 9、 Transport Buffer6、 Elementary Buffer7、デコーダ 8、ス イッチ lOa,b,c,d、 Interactive Graphicsアコ ~~ダ 11、 Transport Buffer(TB)l la、 Coded Data Buffer(CDB)l lb、 Stream Graphics Processor(SGP)l lc、 Object Bufferl ld、 C omposition Bufferl le、 Grapnics Controller 1 Ifゝ Interactive Graphicsプレ ~~ン 12、 Pr esentation Graphicsアコ ~~タ 13、 Transport Buffer(TB)13a、 Coded Data Buffer(CDB )13b、 Stream Graphics Processor(SGP)13c、 Object Buffer 13d、 Composition Buffer 13e、 Graphics Controller 13f、 Presentation Graphicsプレ ~~ン 14、 Transport Buffer 15a、 Elementary Buffer 15b、アコ ~~タ l5c、 Transport Buffer 16a、 Elementary Buffer 16b、デコーダ 16c、合成部 17、メモリ 21、コントローラ 22、 PSRセット 23、 PID変換部 24、ネットワーク部 25、操作受付部 26、ローカルストレージ 200から構成される。
[0122] BD— ROMドライブ laは、 BD— ROMのローデイング/イジェクトを行い、 BD— ROMディ スクに対するアクセスを実行する。
リードバッファ (RB)lbは、 BD- ROMから読み出された Sourceパケット列を蓄積する。 リードバッファ (RB)lcは、 LastPlayタイトルからから読み出された Sourceパケット列を 蓄積する。
[0123] ATC Counter2aは、プライマリ TSを構成する Sourceパケットのうち、再生区間の最初 に位置するものの ATSを用いてリセットされ、以降ソースデバケツタイザ 2bに ATCを出 力してゆく。 ソースデバケツタイザ (Source De- packetizer)2bは、プライマリ TSを構成する Source パケットから TSパケットを取り出して、送出する。この送出にあたって、各 TSパケットの ATSに応じてデコーダへの入力時刻を調整する。具体的には、 ATC Counter2aが生 成する ATCの値と、 Sourceパケットの ATS値とが同一になった瞬間に TS_Recording_Ra teで、その TSパケットだけを PID Filter3bに転送する。
[0124] ATC Counter2cは、セカンダリ TSを構成する Sourceパケットのうち、再生区間の最 初に位置するものの ATSを用いてリセットされ、以降ソースデバケツタイザ 2dに ATCを 出力してゆく。
ソースデバケツタイザ (Source De- packetizer)2dは、セカンダリ TSを構成する Source パケットから TSパケットを取り出して、送出する。この送出にあたって、 ATSに応じてデ コーダへの入力時刻を調整する。具体的には、 ATC Counter2cが生成する ATCの 値と、 Sourceパケットの ATS値とが同一になった瞬間に TS_Recording_Rateで、その TS パケットだけを PID Filter 3dに転送する。
[0125] STC Counter3aは、プライマリ TSの PCRによってリセットされ、 STCを出力する。
PID Filter3bは、 MainClip用の多重分離部であり、ソースデバケツタイザ 2bから出力 された Sourceパケットのうち、 PID変換部 24から通知された PID参照値をもつものを、 夫々ビテォデコーダ 4、ォーアイォテコーダ 9、 Interactive Graphicsテコーダ 11、 Pre sentation Graphicsデコーダ 13に出力する。各デコーダは、 PID Filter3bを経由した エレメンタリストリームを受け取って、プライマリ TSの PCR(STC1時間軸）に従いデコー ドから再生の処理を行う。このように PID Filter3bを通過して各デコーダに入力される エレメンタリストリームは、プライマリ TSの PCRに従って、デコード及び再生に供される ことになる。
[0126] STC Counter3cは、セカンダリ TSの PCRによってリセットされ、 STCを出力する。 PID フィルタ 3dは、この STCを参照して、多重分離を行う。
PID Filter3dは、 SubClip用の多重分離部であり、ソースデバケツタイザ 2dから出力 された Sourceパケットのうち、 PID変換部 24から通知された PID参照値をもつものを、 夫々ォーティオアコーダ 9、 Interactive Graphicsテコーダ丄 1、 Presentation Graphics デコーダ 13に出力する。このように PID Filter3dを通過して各デコーダに入力される エレメンタリストリームは、セカンダリ TSの PCRに従って、デコード及び再生に供される ことになる。
[0127] 記録媒体の説明で述べたように、 Playltemにおける In_Time、 Out_Timeは、 SubPlaylt emにおける In_Time、 Out_Timeと一致しているので、 ATC Counter2aと ATC Counter 2cとが同一の値（時刻）を刻めば、プライマリ TSとセカンダリ TSの両方の時間軸が揃う ことになり、 Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSを 1 本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表す ATC時間 軸と、デコーダ基準時間軸を表す STC時間軸とを同期させることができる。
[0128] ATC時間軸の同期により、上述した 2つの Source De- packetizerは、それぞれ、 BD -ROM力 から読み出された Sourceパケット、ローカルストレージからから読み出され た Sourceパケットを処理することができる。
STC時間軸の同期により、 STC Counter3a,cは、同一の時刻を計時すれば、 2つの TSを 1つの TSとして処理することができる。再生装置におけるデコーダは、 1つの STC 時間軸で動くため、通常のプライマリ TSだけの再生時と変わることなぐ STC時間の管 理を共通化することができる。ビデオデコーダ 4、 IGデコーダ 11、 PGデコーダ 13、シ ステムデコーダ 15c,16c、オーディオデコーダ 9の全てが同一の STC時間軸で動か せることは、再生装置開発の観点力もすると、 BD-ROMの再生のみを行う通常の再 生装置と、制御が一切変わらないため望ましい制限となる。更にォーサリング時にお いては、 1つの TSの入力タイミングを制御して、ノ ッファ状態を観測すればよいので、 ォーサリング時の検証も容易になる。
[0129] ビデオデコーダ 4は、 PID Filter3bから出力された複数 PESパケットを復号して非圧 縮形式のピクチャを得てビデオプレーン 5に書き込むものであり、 Transport Buffer4a 、 Multiplexed Buffer4b、 Elementary Buffer4c、テコータ 4d、 Re-order Buffer4e、スィ ツチ 4 ゝら構成される。
Transport Buffer(TB)4aは、ビデオストリームに帰属する TSパケットが PID Filter3bか ら出力された際、一旦蓄積されるノ ッファである。
[0130] Multiplexed Buffer(MB)4bは、 Transport Buffer4aから Elementary Buffer4cにビデオ ストリームを出力するにあたって、ー且 PESパケットを蓄積しておくためのバッファであ る。
Elementary Buffer(EB)4cは、符号化状態にあるピクチャ (Iピクチャ、 Bピクチャ、 Pピク チヤ)が格納されるバッファである。
[0131] デコーダ (DEC.)4dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の 復号時刻（DTS)ごとにデコードすることにより複数フレーム画像を得て、ビデオプレ ーン 5に書き込む。
Re-order Buffer4eは、復号されたピクチャの順序を、符号ィ匕順序力 表示順序に 入れ替えるためのバッファである。
[0132] スィッチ 4fは、符号ィ匕順序力 表示順序へと、ピクチャの順序を入れ替えを実現す るスィッチである。
ビデオプレーン 5は、非圧縮形式のピクチャを格納しておくためのプレーンである。 プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ 領域である。ビデオプレーン 5における解像度は 1920 X 1080であり、このビデオプレ ーン 5に格納されたピクチャデータは、 16ビットの YUV値で表現された画素データに より構成される。
[0133] オーディオデコーダ 9は、 Transport Buffer 6, Elementary Buffer 7,デコーダ 8から 構成され、オーディオストリームのデコードを行う。
Transport Buffer6は、 PID Filter3bから出力された TSパケットを、先入れ先だし式に 格納して、オーディオデコーダ 8に供する。
Elementary Buffer7は、 PID Filter3bから出力された TSパケットのうち再生されるべ きオーディオストリームの PIDを有する TSパケットのみを、先入れ先だし式に格納して
、オーディオデコーダ 8に供する。
[0134] デコーダ 8は、 Transport Buffer6に格納された TSパケットを PESパケットに変換して
、この PESパケットに対しデコード処理を行い、非圧縮状態の LPCM状態のオーディ ォデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がな される。
スィッチ 10aは、 BD- ROMから読み出された TSパケット、ローカルストレージ 200から 読み出された TSパケットのどちらかを、選択的にビデオデコーダ 4に供給する。 [0135] スィッチ 10bは、 BD- ROMから読み出された TSパケット、ローカルストレージ 200力 ら読み出された TSパケットのどちらかを、選択的に Interactive Graphicsデコーダ 11に 供給する。
スィッチ 10cは、 BD- ROMから読み出された TSパケット、ローカルストレージから読 み出された TSパケットのどちらかを、選択的に Presentation Graphicsデコーダ 13に供 給する。
[0136] Interactive Graphics(IG)デコーダ 11は、 BD- ROM100又はローカルストレージ 200 力も読み出された IGストリームをデコードして、非圧縮グラフィクスを IGプレーン 12に 書き込むものであり、 Transport Buffer(TB)l la、 Coded Data Buffer(CDB)l lb、 Strea m Graphics Processor(SGP)丄 lc、 Object Bufferl ld、 Composition Buffer丄 le、 Graphi cs Controller(Ctrl)l ll¾ら構成される。
[0137] Transport Buffer(TB)l laは、 IGストリームに帰属する TSパケットがー且蓄積される バッファである。
Coded Data Buffer(CDB)l lbは、 IGストリームを構成する PESパケットが格納される バッファである。
Stream Graphics Processor(SGP)l lcは、グラフィクスデータを格納した PESパケット をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビッ トマップをグラフィクスオブジェクトとして ObjectBufferl ldに書き込む。
[0138] Object Bufferl Idは、 Stream Graphics Processor 1 lcのデコードにより得られたグラ フィクスオブジェクトが配置される。
Composition Bufferl leは、グラフィクスデータ描画のための制御情報が配置される メモリである。
Graphics Controller(Ctrl)l lfは、 Composition Bufferl leに配置された制御情報を 解読して、解読結果に基づく制御をする。
[0139] Interactive Graphics(IG)プレーン 12は、 IGデコーダ 10によるデコードで得られた非 圧縮グラフィクスが書き込まれる。
Presentation Graphics(PG)デコーダ 13は、 BD- ROM又はローカルストレージ 200か ら読み出された PGストリームをデコードして、非圧縮グラフィクスを Presentation Graph icsプレーン 14に書き込む。 PGデコーダ 13は、 Transport Buffer(TB)13a、 Coded Dat a Buffer(CDB)13b、 Stream Graphics Processor(SGP)13cゝ Object Buffer(OB)13d、 C omposition Buffer(CB)13e、 Graphics Controller(Ctrl)131¾ら構成される。
[0140] Transport Buffer(TB)13aは、 PGストリームに帰属する TSパケットが PIDフィルタ 4か ら出力された際、一旦蓄積されるノ ッファである。
Coded Data Buffer(CDB)13bは、 PGストリームを構成する PESパケットが格納される バッファである。
Stream Graphics Processor(SGP)13cは、グラフィクスデータを格納した PESパケット（ ODS)をデコードして、デコードにより得られたインデックスカラー力もなる非圧縮状態 のビットマップをグラフィクスオブジェクトとして ObjectBufferl3dに書き込む。
[0141] Object Buffer(OB)13dは、 Stream Graphics Processorl3cのデコードにより得られた グラフィクスオブジェクトが配置される。
Composition Buffer(CB)13eは、グラフィクスデータ描画のための制御情報 (PCS)が 配置されるメモリである。
Graphics Controller(Ctrl)13fは、 Composition Buffer 13eに配置された PCSを解読し て、解読結果に基づく制御をする。
[0142] Presentation Graphics(PG)プレーン 14は、一画面分の領域をもったメモリであり、一 画面分の非圧縮グラフィクスを格納することができる。
システムデコーダ 15は、セカンダリ TSにおけるシステム制御パケット (PATや PMT)を 処理しデコーダ全体を制御する。
Transport Bufferl5aは、プライマリ TSに存在するシステム制御パケット (PATや PMT) を格納する。
[0143] Elementary Bufferl5bは、システム制御パケットをデコーダ 15cに供する。
デコーダ 15cは、 Elementary Bufferl5bに格納されたシステム制御パケットを、デコ ードする。
Transport Bufferl6aは、セカンダリ TSに存在するシステム制御パケットを格納する。
[0144] Elementary Bufferl6bは、セカンダリ TSにおけるシステム制御パケットをデコーダ 16 cに供する。 デコーダ 16cは、 Elementary Bufferl6bに格納されたシステム制御パケットを、デコ ードする。
メモリ 21は、カレントの PlayList情報やカレントの Clip情報を格納しておくためのメモ リである。カレント PlayList情報とは、 BD- ROMに記録されている複数 PlayList情報のう ち、現在処理対象になっているものをいう。カレント Clip情報とは、 BD- ROM/ロー力 ルストレージに記録されている複数 Clip情報のうち、現在処理対象になっているもの をいう。
[0145] コントローラ 22は、プレイリスト再生 (カレント PlayList情報に従った再生制御のことで ある）を実行することで、 BD-ROMの再生制御を実現する。また上述のような ATS、 ST Cの制御も行なう。この制御にあたってコントローラ 22は、 1秒という時間的範囲にお いて、 BD- ROM、ローカルストレージ内の Sourceパケットを、デコーダ内のバッファに 先読みしておく。このような先読みを行うのは、上述したウィンドウの制限により、アン ダーフロー又はオーバーフローが生じないとの保障があるからである。
[0146] PSRセット 23は、再生装置に内蔵されるレジスタであり、 64個の Player Setting/Statu s Register(PSR)と、 4096個の General Purpose Register (GPR)とからなる。 Player Setti ng/Status Registerの設定値 (PSR)のうち、 PSR4〜PSR8は、現在の再生時点を表現す るのに用いられる。
PID変換部 24は、 PSRセット 23に格納されているオーディオストリーム、オーディオ ストリームのストリーム番号を、 STN_Tableに基づき、 PID参照値に変換して、変換結果 たる PID参照値を PID Filter3b、 PID Filter 3dに指示する。
[0147] ネットワーク部 25は、本再生装置における通信機能を実現するものであり、 URL指 定が与えられれば、その URLにあたる webサイトとの TCPコネクション、 FTPコネクショ ン等を確立する。力かるコネクション確立により webサイトからのダウンロードを実行す る。
操作受付部 26は、リモコンに対してなされた操作をユーザカゝら受け付け、そうした 操作を示す User Operation情報をコントローラ 22に通知する。
[0148] 以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ 22の実 装について説明する。コントローラ 22は、図 31、図 32に示したフローチャートの処理 手順を CPUに実行させるプログラムを作成して命令 ROMに書き込み、 CPUに供する ことで再生装置に実装することができる。
図 31は、 PlayList情報に基づく再生手順のフローチャートである。本フローチャート は、 PlayList情報を構成する. mplsファイルを読み込み (ステップ Sl l)、 PlayList情報に ぉける先頭のPlayItemをカレントPlayItemにした上で(ステップS 12)、このカレント Playl temに対して、ステップ S13〜ステップ S25の処理を繰り返すループ構造になってい る。このループ構造は、ステップ S23を終了条件としたものであり、カレント Playltemの In_Timeに対応する Access Unitから、カレント Playltemの Out_Timeに対応する Access Unitまでを読み出しを BD- ROMドライブに命じ (ステップ SI 3)、カレント Playltemに pre viousPlayltemが存在するか否かを判定して (ステップ S 14)、判定結果に応じて、ステ ップ S 15の処理、ステップ S 16〜ステップ S 21の処理を選択的に実行する。具体的 には、カレント Playltemに previousPlayltemがなければ (ステップ S14で No)、 PlayltemJ n_Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S 15)。
[0149] カレント Playltemに previousPlayltemがあれば (ステップ S 14で Yes)、カレント Playltem 力 SCC = 5であるか否かを判定し (ステップ S I 6)、 CC = 5であるなら (ステップ SI 6で Yes )、ステップ SI 7〜ステップ S20の処理を行う。
上述した previousPlayltemが存在する場合、プライマリ TSにおける ATC_Sequenceが 切り替わることになる。この切替において、 ATC_deltalと呼ばれるプライマリ TSのため のオフセット値を算出し (ステップ S 17)、それまでの ATC_Sequenceにおける ATC値 (A TC1)に、 ATC_deltalをカ卩算することにより、新しい ATC_Sequenceの ATC値 (ATC2)を 得る (ステップ S 18)。
[0150] また、上述した、 previousPlayltemが存在する場合、プライマリ TSにおける STC_Sequ enceが切り替わることになる。この切り替えにおいて、 STC_deltalと呼ばれるオフセット 値を求めて (ステップ S 19)、それまでの STC_Sequenceにおける STC値 (STC1)に、 STC _deltalを加算することにより (ステップ S20)、新し!/ヽ STC_Sequenceの STC値 (STC2)を 求める。
そして Audio Overrapのミュートをオーディオデコーダ 9に指示した上で、 Playltem Jn _Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S21)。カレント Playltem力 SCC = 5でないなら、 CC=1、 CC=6の処理を行う。
[0151] ステップ S15、ステップ S16〜ステップ S21のどちらかの処理を実行すればステップ S25の処理を実行する。ステップ S25は、カレント Playltemと同期再生すべき SubPlayl temが存在するかどうかをサーチする処理である。ここで SubPath情報を構成する各 Su bPlayltemは、 Sync_PlayItem_Idという情報を有しており、カレント Playltemと同期再生 すべき SubPlayltemは、この Sync_PlayItem_Idが、カレント Playltemに設定されている。 そこでステップ S25では、カレント Playltemを Sync_PlayItem_Idに指定した SubPlayltem 力 SubPath情報を構成する複数の SubPlayltemの中に存在するかどうかをサーチす る。
[0152] もし存在しない場合、ステップ S22に移行する。ステップ S22は、 AVClip時間軸に おける現在の再生時点 (カレント PTM(Presentation TiMe》がカレント Playltemの Out_T imeに到達した力どうかを判定する (ステップ S22)。到達すれば、ステップ S23に移行 する。ステップ S23は、カレント Playltemが PlayList情報における最後の Playltemにな つたか否かの判定であり、最後の Playltemでなければ、 PlayList情報における次の Pla yltemを、カレント Playltemにして (ステップ S24)、ステップ S I 3に移行する。以上の処 理により、 PlayList情報における全ての Playltemに対して、ステップ S 13〜ステップ S2 4の処理が施されることになる。
[0153] 図 32は、 SubPlayltemにおけるシームレス接続を示すフローチャートである。
ステップ S25においてカレント Playltemを Sync_PlayItem_Idに指定した SubPlayltemが 存在すると判定された場合、その SubPlayltemをカレント SubPlayltemに設定して (ステ ップ S31)、 SubPlayltemの In_Timeに相当する Access Unitから、 Out_Timeに相当する Access Unitまでの読み出しをローカルストレージ 200に命じる (ステップ S32)。そして カレント Playltemに Previous SubPlayltemが存在するか否かを判定して (ステップ S33) 、判定結果に応じて、ステップ S34、ステップ S35の処理、ステップ S36〜ステップ S4 1の処理を選択的に実行する。具体的には、カレント Playltemに Previous SubPlayltem がなければ (ステップ S33で No)、カレント PTMが、 Sync_Start_Pts_of_PlayItemに到達 するのを待ち (ステップ S34)、到達すれば、 SubPlayItem_In_Timeから SubPlayItem_Out _Timeまでの再生をデコーダに命じる (ステップ S35)。 [0154] カレント Playltemに Previous SubPlayltemがあれば (ステップ S33で Yes)、カレント Pla yltem力 P_CC=5であるか否かを判定し (ステップ S36)、 SP_CC=5であるなら (ステップ S36で Yes)、ステップ S37〜ステップ S41の処理を行う。
上述した、 previousPlayltemが存在する場合、 ATC_Sequenceが切り替わることにな る。この切替において、 ATC_delta2と呼ばれるセカンダリ TSのためのオフセット値を算 出し (ステップ S37)、それまでの ATC_Sequenceにおける ATC値 (ATC1)に、 ATC_delta 2をカ卩算することにより、新し!/、ATC_Sequenceの ATC値 (ATC2)を得る (ステップ S38)。
[0155] ATC_deltaとは、これまで読み出されているトランスポートストリーム (TS1)の最後の TS パケットの入力時点 T1から、新たに読み出されたトランスポートストリーム (TS2)の最初 の TSパケットの入力時点 T2までのオフセット値を 、、 "ATC.delta≥ Nl/TS_recordin g_rate"という計算式で与えられる。ここで N1は、 TS1の最後のビデオ PESパケットに後 続する、 TSパケットのパケット数である。
[0156] また、上述した、 previousPlayltemが存在する場合、 STC_Sequenceも切り替わること になる。この切り替えにおいて、 STC_delta2を求めて (ステップ S39)、それまでの STC_ Sequenceにおける STC値 (STC1)に、 STC_delta2をカ卩算することにより (ステップ S40)、 新しい STC_Sequenceの STC値 (STC2)を求める。
先行 STC_Sequenceにおいて最後に再生されるピクチャの表示開始時刻を PTSKlst END),ピクチャの表示期間を Tppとし、後続 STC_Sequenceにおいて最初に表示され るピクチャの開始時刻を PTS2(2ndSTART)とした場合、 CC = 5では、 PTSl(lstEND) + Tppの時刻と、 PTS2(2ndSTART)の時刻とを一致させる必要があるから、 STC_delta2は
STC_delta2 = PTS l(lstEND) + Tpp - PTS2(2ndSTART)
との計算式力 算出される。
そして Audio Overrapのミュートをオーディオデコーダ 9に指示した上で、 Playltem Jn _Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S41)。
[0157] コントローラ 22は、上述したように、 STCの変更処理を行うが、再生装置の一般的な 実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。 フリーラン状態とは、デコーダが STCとの同期制御を行っていない状態をいう。その後 、 STC時間軸が設定できる状態まで、 STCが復帰すれば、デコーダは、フリーラン状 態から、 STCとの同期制御へと移行する。一方、ステップ S36においてカレント Playlte m力 SCC = 5でないと判定されたなら (ステップ S36で No)、 CC=1、 CC=6の処理を行う。
[0158] 以上のように本実施形態によれば、 Windowと呼ばれる 1秒当たりの転送許容量は、 48Mbit以下に制限されているので、この 1秒という期間において、転送許容量が局所 的に 96Mbitまであがったとしても、 96Mbit X 0.5秒のサイズの TSパケットを、デコーダ に先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローす ることはない。デジタルストリームにおけるどの期間であっても、データ量は「96Mbit X 0.5秒」以下であり、アンダーフロー又はオーバーフローが生じることなぐ TSパケット を供給することができるので、ビデオ又はオーディオの欠落を避けることができる。こ れにより Out-of-MUXフレームワーク実現のための同時読み出し力 品質上の問題 に波及する恐れはなくなる。
[0159] また、 Playltemにおける In_Time、 Out_Timeと、 SubPlayltemにおける In_Time、 Out_Ti meとが一致していて、 Playltem側の接続状態が CC = 5であるなら、 SubPlayltem側の 接続状態も SP_CC=5になるので、 Playltemが切り替えられたとしても、多重分離部を 再設定することなぐ Playltemから Playltemへの切り替えと、 SubPlayltemから SubPlaylt emへの切り替えとを同時に実行することができる。多重分離部が参照する STC時間 軸を同期させつつ、 PlayList情報に基づく再生処理を進行させてゆくことができる。
[0160] (第 2実施形態）
本実施形態では、先の実施形態で述べた、 BD-ROMの製作について、詳しく説明 する。先の実施形態に係る BD-ROMは、以下の工程を順次実行することにより、作る ことができる。 く BD- ROMの記録工程 >
先ず初めに、 BD-ROMをどのような筋書きで再生させるかを決めるかを企画して (企 画工程)、動画収録、音声収録等の素材作成を行い (素材作成工程)、企画工程にお V、て作成された筋書きから、ボリューム構成情報を作成する (シナリオ作成工程)。
[0161] ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを 示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをェン コードすることにより、エレメンタリストリームを得る (素材エンコード工程)。その後、複 数のエレメンタリストリームの多重化を行う (多重化工程)。
[0162] こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、 B D- ROMの応用層フォーマットに適合させる作業を行 、、 BD- ROMのボリューム領域 に記録すべきデータの全体像 (一般にボリュームデータという)を得る (フォーマッティ ング工程)。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述さ れたクラス構造体のインスタンスであり、 BD- ROM規格に規定された構文に基づ!/、て 、クラス構造体のインスタンスを記述することで、 Clip情報, PlayList情報等を作成する ことができる。この場合、テーブル形式のデータは、プログラミング言語の for文を用い て定義することができ、その他、特定の条件下のみ、必要になるようなデータは、 ifX を用いて定義することができる。
[0163] こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生し てみてシナリオ作成工程の結果が正しいか否かの確認を行う (エミユレーシヨン工程） 。このエミユレーシヨン工程では、 BD- ROMプレーヤモデルのバッファ状態のシミュレ ートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列 に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作 成する。さらにプレス装置によって作成された原盤から、 BD-ROMを製造する。この 製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの 印刷と 、つた諸工程力 なる。
[0164] 以上の工程を経て、各実施形態に示した記録媒体 (BD-ROM)を作ることができる。
<追加コンテンツの作成工程〉
映画作品を、 BD-ROMコンテンツと、追加コンテンツとで構成する場合は、上述した 企画工程力もフォーマッティング工程までを実行する。そうして、 1つのボリュームデー タを構成する AVClip、 Clip情報、 PlayList情報が得られれば、これらのうち、既に BD- ROMにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバ プログラム等で 1つのファイルにまとめる。こうした処理を経て、追加コンテンツが得ら れれば、力かる追加コンテンツを WWWサーバーに供し、再生装置からの要求に応じ て、再生装置に送出する。
[0165] 先の実施形態で述べたベリファイは、 AVClip、 Clip情報、 PlayList情報が完成し、 P1 ayList情報内の STN_tableにより、再生すべきエレメンタリストリームが確定した段階、 つまり、フォーマッティング工程で実行される。以降、力かるアプリケーションフォーマ ットを作成するォーサリングシステムについて説明する。
<ォーサリングシステム >
図 33は、第 2実施形態に力かるォーサリングシステムの内部構成を示す図である。 本図に示すようにォーサリングシステムは、入力装置 51、エンコード装置 52、サーバ 装置 53、素材ストレージ 54、 BD構成情報ストレージ 55、クライアント装置 56〜58、 マルチプレクサ 60、 BDシナリオコンバータ 61、フォーマッタ 62、 Verifier63から構成 される。
[0166] 入力装置 51は、 HD画像、 SD画像が収められたビデオカセットを装填し、このビデ ォカセットを再生して再生信号をエンコード装置 52に出力する。
エンコード装置 52は、入力装置 51から出力された再生信号をエンコードして、ビデ ォストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得ら れたエレメンタリストリームは、 LANを通じてサーバ装置 53に出力され、サーバ装置 5 3内の素材ストレージ 54に書き込まれる。
[0167] サーバ装置 53は、素材ストレージ 54、 BD構成情報ストレージ 55という 2つのドライ ブ装置からなる。
素材ストレージ 54は、サーバ装置 53の内蔵ディスク装置であり、エンコード装置 52 のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ 54 は、 HDstreamディレクトリ、 SDstreamディレクトリといった 2つのディレクトリをもち、 HD 画像をエンコードすることにより得られたエレメンタリストリームは HDstreamディレクトリ に書き込まれる。
[0168] BD構成情報ストレージ 55は、 BDボリューム構成情報が格納されるドライブ装置で ある。
マルチプレクサ 60は、素材ストレージ 54内の HDstreamディレクトリ、 SDstreamディレ クトリに格納されているエレメンタリストリームのうち、 BDボリューム構成情報により指定 されて 、るものを読み出し、これを BDボリューム構成情報に従 、多重化することで、 多重化ストリームである AVClipを得る。
[0169] BDシナリオコンバータ 61は、 BD構成情報ストレージ 55に格納されている BDボリュ ーム構成情報を BD-ROMアプリケーションフォーマットに変換することにより BDシナリ ォを得る。
フォーマッタ 62は、マルチプレクサ 60によりえられた Clip、 BDシナリオコンバータ 61 により得られた BDシナリオを、 BD- ROMの応用層フォーマットに適応させる。こうして 適応されら BDシナリオから、 BD- ROMの原盤や、ローカルストレージに格納されるべ きダウンロード用コンテンツが得られる。
[0170] ベリファイ部 63は、シナリオコンバータ 61が生成した PlayList情報内の STN_tableを 参照して、マルチプレクサ 60が得た BD- ROM用のプライマリ TS、ローカルストレージ 用のセカンダリ TSが、 Out_of_MUXアプリケーションを実現するため制限を満たすかど うかを判定する。
以上が、ォーサリングシステムの内部構成である。以降、ォーサリングシステムおけ るべリファイ部 63の実装について説明する。
[0171] くべリファイ部 63実装のための処理手順 >
ベリファイ部 63は、図 34、図 35に示したフローチャートの処理手順を CPUに実行さ せるプログラムを作成して命令 ROMに書き込み、 CPUに供することでォーサリングシ ステム内に実装することができる。
図 34は、プライマリ TS、セカンダリ TSに対するべリファイ手順を示すフローチャート である。本フローチャートは、ステップ S1において、 Sourceパケット列における最初の Sourceパケットの ATSを、カレント Windowの In_Timeに設定した上で、ステップ S2〜ス テツプ S7の処理を繰り返すループ構造を有している。このループ構造は、カレント Wi ndowの In_Timeから 1秒以降に存在する ATSを、カレント Windowの Out_Timeに設定し て (ステップ S2)、カレント Windowの In_Timeから Out_Timeまでに存在する TSパケット数 をカウントし (ステップ S3)、 In_Timeからカレント Windowにおけるビット数を算出して (ス テツプ S4)、そのビット値が 48Mbit以下であるかを判定する処理 (ステップ S5)を、ステ ップ S6力 Wesと判定されるまで繰り返すものである。このステップ S6は、カレント Windo wの Out_Timeが、 ATC時間軸における最後の Sourceパケットに到達したかどうかの判 定であり、もしステップ S6が Noであるなら、 Sourceパケット列における次の ATSを、力 レント Windowの In_Timeにして (ステップ S7)、ステップ S2〜ステップ S6の処理を繰り 返す。どれかの Windowで、ステップ S5が Noと判定されたなら、 BD- ROM規格に違反 していると判定される (ステップ S9)。全ての Windowでステップ S5が Yesと判定され、ス テツプ S6が Yesと判定されたなら、 BD-ROM規格に適合して 、ると判定される (ステツ プ S8)。
[0172] プライマリ TS、セカンダリ TSは、以上のベリファイを経ているので、プライマリ TS、セ カンダリ TSがそれぞれ BD-ROM、ローカルストレージカも供給される場合でも、上述 したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームのそれぞれに、 同種のエレメンタリストリームが複数存在する場合、図 35の手順で、ベリファイを行う のが望ましい。図 35に示すベリファイ手順は、図 34におけるステップ S3〜ステップ S 4を、ステップ S81〜ステップ S83に置き換えたものである。
[0173] このステップ S81〜ステップ S83は、カレント Windowが 1つ決定される度に、 STN_ta bleにお!/、て、再生が許可されて!、るエレメンタリストリームを構成する TSパケットのう ち、カレント Windowに属するもののビットレートを、エレメンタリストリーム毎に算出して (ステップ S81)、複数のビデオストリーム、複数のオーディオストリーム、複数の PGスト リーム、複数の IGストリームのうち、算出されたビットレートが最も高いものを選び (ステ ップ S82)、ビデオストリームのビットレートの最大値、オーディオストリームのビットレー トの最大値、 PGストリームのビットレートの最大値、 IGストリームのビットレートの最大値 を合計して (ステップ S83)、その合計量が 48Mbit以下であるかを判定する (ステップ S 5)ものである。
[0174] 同種のエレメンタリストリームは、 Out_of_MUXアプリケーションでは、必ず排他的に 選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所 におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下 の通りである。
(1) Windowの In_Timeが指し示す TSパケットの先頭
(2) Windowの In_Timeが指し示す TSパケットの終了
(3) Windowの Out_Timeが指し示す TSパケットの先頭
(4) Windowの Out_Timeが指し示す TSパケットの終了 力かる箇所におけるビット量を重点的にチェックすることで、ォーサリングでのベリフ アイ作業を、より簡略化することができる。
[0176] 以上のように本実施形態によれば、セカンダリ TSの再生を許可した STN_tableを作 成した際、その STN_tableに基づく再生処理で、アンダーフロー又はオーバーフロー が生じるかどうかを、ォーサリングの段階で、あら力じめ検証しておくことができる。
(第 3実施形態）
本実施形態は、 Playltem間、 SubPlayltem間の接続に、 CC=6という新たな類型を設 ける実施形態である。
[0177] CC=6とは、 Progressive PlayList情報を構成する複数の Playltem情報間の接続状態 を規定する。 Progressive PlayList情報とは、ストリーミングを前提にして再生されるべ き複数の AVClipを、 1つの再生経路として指定してゆくためのプレイリスト情報である
、 Progressive PlayList情報
Progressive PlayList情報は、ダウンロード/ストリーミングするセカンダリ TSを細切れ のファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウン ロードを待たずに、再生を開始することができる利便がある。
[0178] ストリーミングを前提にしたコンテンツは、短い長さの多くの AVClipにて規定されて いるので、 Progressive PlayList情報は、これら複数 AVClipのそれぞれに対応する、 多くの Playltem情報力も構成される。一方、細かい単位に分割された AVClipは、ストリ 一ミングのために分割されたのであって、 STC、 ATCに不連続点が存在している訳で はない。そのため、 CC = 5ではない別の状態として、力かる AVClip間の接続状態を 規定しておく必要がある。こうして規定された接続状態を、 CC=6という。 < CC=6にお!/、て満たすべき条件 >
CC=6である場合、 2つの Playltemから指定される TS1、 TS2と、 2つの SubPlayltemか ら指定される TS1、 TS2とは、以下の条件を満たす必要がある。
[0179] 1)TS2におけるビデオストリームは、 GOPから始まらなければならない。
2)TS2のオーディオストリームと同じ PIDをもつ TS1のオーディオストリームとにおいて 、接続点における Audio Presentation Unit列に、ギャップが存在しない。
TS1のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そ して、 TS2における同じ PIDをもつオーディオストリームは、不完全な Audio Presentatio n Unitから始まってもよい。複数の Playltem、複数の SubPlayltemに基づき、これらの T Sl、 TS2を再生させてゆけば、 2つの Audio Presentation Unit力ら、 1つの完結した Aud 10 Presentation Unit力 Sネ守られる。
[0180] CC=6では実際にはストリームが連続しているため、 CC=5の時のようなビデオだけ がシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするような ことはなぐ全てのエレメンタリストリームがシームレスに接続される。 以上のように CC=6は、論理的に連続しているストリームを、ストリーミングの都合から 、複数の部分に分割した場合の分割境界を意味する。ただし、 BD-ROMに記録され るべきストリームは 32個の Sourceパケットから構成される必要があるので、 1つの SubPl ayltemを構成する 1つのストリームファイルは、全て、 6KByteの倍数になっている必要 がある。
[0181] < CC=6の詳細 >
図 36は、 CC=6の詳細な説明を示す図である。第 1段目は、 1本の連続した ATC/ST C時間を有し、符号化方式も連続して!/、るストリームを格納したファイル (20000.m2ts) を示す。第 2段目は、 3つのストリームを格納した格納した 3つのファイル (20001.m2ts,2 0002.m2t,20003.m2ts)を示す。これらの 3つのファイルは、第 1段目における 1本のスト リームを、ァラインドユニット（6KByte)単位で区切ることで得られた、 3つのプライマリ T Sを格納している。
[0182] 図 37は、 Playltemと SubPlayltemの相関を示した図である。第 1段目は、 PlayList情 報における 3つの PlayItem(PlayItem情報 #1、 Playltem情報 #2、 Playltem情報 #3)を示 す。これら 3つの Playltemはプライマリ TSを指定しており、 Playltem情報 #1、 Playltem情 報 #2間は CC = 1に設定され、 Playltem情報 #2、 Playltem情報 #3間は、 CC = 5に設定 されている。第 2段目は、 PlayList情報における 3つの SubPlayItem(SubPlayItem#l、 Su bPlayItem#2、 SubPlayItem#3)を示す。これら 3つの SubPlayltemはセカンダリ TSを指定 しており、 SubPlayItem#l、 SubPlayItem#2間は CC = 1に設定され、 SubPlayItem#2、 Su bPlayItem#3間は、 CC = 5に設定されている。第 3段目は、 Progressive PlayList情報 における 9つの SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubPlayItem#3〜SubPla yltem#9)を示す。これら 9つの SubPlayltemはセカンダリ TSを指定しており、 SubPlaylte m#3、 SubPlayItem#4間は CC=1に設定され、 SubPlayItem#6、 SubPlayItem#7間は、 CC =5に設定され、それ以外は、 CC=6に設定されている。 Progressive PlayListの SubPl ayltemは、 CC=6で接続される力 Playltemが CC=1、 CC=5で接続されるタイミングで は、 Playltemと同様に CC=1、 CC=5の条件を満たしながら接続される。
[0183] 以上のように本実施形態によれば、 Playltem, SubPlayltemにおける接続状態に、 C C=6という新たな類型を導入することで、 Progressive PlayList情報を構成する AVClip を短く区切って、ストリームングで供給するという処理を実現することができる。
(第 4実施形態）
第 1実施形態では、各 Windowにおけるビット量を、どのように制限するかについて 説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えば よいかを提案する。
[0184] <ビデオ +オーディオの多重化 >
図 38は、プライマリ TSを構成するオーディオ力 セカンダリ TSを構成するオーディ ォに入れ替えられる場合、プライマリ TSを構成する複数の TSパケットと、セカンダリ TS を構成する複数の TSパケットとが、どのように多重化されるかを模式的に示す図であ る。
図 38は、 ATC時間軸に存在する複数の TSパケットが、どのように多重化されるかを 模式的に示す図である。第 1段目は、プライマリ TSを示す。プライマリ TSは V、 Al、 A2 (ビデオ 1本、オーディオ 2本）を格納した TSパケットである。これらの TSパケットは、 2 種類 3本のエレメンタリストリームを多重化して得たものである。
[0185] 第 2段目は、セカンダリ TSを示す。セカンダリ TSは、 1種類 2本のオーディオ A3、 A4 を格納した TSパケットからなる。これらセカンダリ TSの TSパケットが多重化される時間 帯 p3は、デコーダへの入力時間軸を示す ATC時間軸上で、プライマリ TSのオーディ ォパケットが多重化された時間帯 piと、プライマリ TSを構成する TSパケットが転送され てない時間帯 p2とからなる。
[0186] このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されても デコードすべきエレメンタリストリームのビットレートの和がプライマリ TSの許容最大ビ ットレート（48Mbps)を超えない保証ができる。図 38の上述した一例は、一番簡単な 例で、セカンダリ TSにオーディオしかな 、場合である。
<ビデオ +オーディオ + PGストリーム + IGストリームの多重化 >
図 39は、オーディオにカ卩えて、字幕 (PGストリーム）やメニュー（IGストリーム)も入れ 替えられる場合、プライマリ TSを構成する複数の TSパケットと、セカンダリ TSを構成す る複数の TSパケットとが、どのように多重化されるかを模式的に示す図である。
[0187] 本図において、セカンダリ TSのパケットの転送が許可される時間帯 k3は、
1)プライマリ TSにおける同種のパケットの転送時間帯 kl
2)プライマリ TSの無転送時間帯 k2
の和である。
セカンダリ TSに格納されている他ストリーム種別（Video、 IG、 PG等）についても上記 1)、 2)のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類の ストリームの転送時間帯でセカンダリ TS内に多重化が可能力判断され、これで不足 する場合には、 2)のプライマリ TSの無転送時間帯を利用して多重化されることが効 率的である。
[0188] <マルチプレクサ 60の処理 >
本実施形態に力かるマルチプレクサ 60の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ 60は、デコーダモデル において、プライマリ TSを再生する際のノッファ状態をシミュレートし、プライマリ TSに おける各パケットの転送時間帯や、プライマリ TSの無転送時間帯を検出する。これら の時間帯を検出すれば、セカンダリ TSを構成する各 PESパケットが、同種のパケットの 転送時間帯や、無転送時間帯に転送されるよう、セカンダリ TSを構成する各 PESパケ ットを TSパケットに変換して、各 TSパケットに、力かる ATSを付す。こうして付された AT Sは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリ TSを構 成する各 PESパケットは、図 39に示したように、プライマリ TSにおける同種のパケット の転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。
[0189] く DVDによる供給 >
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム 形式ではなぐプログラムストリーム形式にする場合、マルチプレクサ 60は、エレメン タリストリームを構成する PESパケットを、パックに変換して、各パックの TSヘッダに SC R(System Clock Reference)を付す。こうして付された SCRも、 ATS同様、同種のバケツ トの転送時間帯や、無転送時間帯を示すので、セカンダリ PS (ローカルストレージから 供給されるプログラムストリーム)を構成する各 PESパケットは、図 39に示したように、プ ライマリ PS(BD- ROMから供給されるプログラムストリーム)における同種のパケットの転 送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレー ジ力 供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種 のパケットの転送時間帯や、無転送時間帯を、パック（PESパケット）という大きな時間 単位で表現するので、ォーサリング時における負担は格段に小さぐ実現が容易とな る。これは、 DVD再生装置において、 Out_of_MUXアプリケーションを実現するにあた つての、禾 IJ点となる。
[0190] 以上のように本実施形態によれば、プライマリ TSにおける同種のパケットの転送期 間、プライマリ TSにおける無転送期間を、セカンダリ TSを構成するパケットの入力期 間に選び多重化を行うので、第 1実施形態に示したビット量制限を満たしやすくなる。 力かる多重化を第 2実施形態に示したォーサリングシステム上で実現することにより、 Out_of_MUXアプリケーションを実現するような映画作品を製作しやすくなる。これによ り、再生時のオーバフローが生じないような保障をォーサリングの段階で、容易に行う ことができる。
(第 5実施形態） 本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本ァ プリケーシヨンは、 1つの種別につき、 1つのエレメンタリストリームという Out_of_MUXの 規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシ ングアプリケーションはプライマリ TSにあたるオーディオストリームと、セカンダリ TSに あたるオーディオストリームとを同時に選択し、プライマリ TSの音声とセカンダリ TSの 音声の 2つの音声を同時にデコードする点が例外となる。
[0191] 図 40は、オーディオミキシングアプリケーションを構成するプライマリ TS、セカンダリ TSが、 BD-ROM再生装置の内部構成において、デコーダにどのように供給されるか を示す図である。本図では、 BD-ROM再生装置の内部構成のうち、 BD-ROMドライブ la、ローカルストレージ 200、ネットワーク部 25を左側に示し、各デコーダを右側に示 す。真ん中に、ストリームの多重分離を行う PID Filterを示す。そして本図におけるプ ライマリ TS(Video 1 'Audio 1 (English) ,Audio2(Spanish) , PG 1 (English Subtitle) ,IG1 (Englis h Menu))ゝセカンダリ TS(Audio3(Commentary),PG2(Japanese Subtitle),PG3(Korean S ubtitle),PG4(Chinese Subtitle),IG2(English Menu))は、それぞれ BD- ROM、ローカル ストレージカゝら供給されるトランスポートストリームを示す。ディスク単体には英語 (Audi 0 1)とスペイン語 (Audio 2)しか記録されていないため、映画監督のコメンタリ音声は 、このディスク力も選択することはできない。し力しながら、コンテンツプロバイダが提 供する Audio 3(Commnetary)の入ったセカンダリ TSを、ローカノレストレージにダウン口 ードすれば、英語音声（Audio 1)と、 Audio 3(Commentry)とを、デコーダに送り込む ことができる。これらの英語音声（Audio 1)と、 Audio 3(Commentry)とを、デコーダがミ キシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像 (Videol) と共に再生させることができる。
[0192] Out-of-MUXアプリケーションとの相違は 2つのオーディオストリームを同時にデコ ードする点のみである。如何なるプライマリ TSに対しても、ディスク発売後に監督のコ メンタリ音声を付加するなどといったことが想定されるため、プライマリ TSへのビットレ ート制限などは好ましくなぐ Out-of-MUXと同様にセカンダリ TSへの制限を導入する 。オーディオミキシングでは、各エレメンタリストリーム（ビデオ、オーディオ、字幕、メ- ユー）に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソ ースを 2つ必須とする。
[0193] くプライマリ、セカンダリオーディオストリームの構成〉
オーディオミキシングアプリケーションを実現するにあたって、プライマリ TSにおける 属することになるオーディオストリームを、プライマリオーディオストリームといい、セカ ンダリ TSに属することになるオーディオストリームをセカンダリオーディオストリームとい う。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて 説明する。
[0194] プライマリオーディオストリームは、 32本存在し、それらは 0x1100から 0x111Fまでの P IDをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリー ム同様、 32本存在し、 OxlAOOから OxlAlFまでの PIDをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカ ンダリオーディオストリームのオーディオフレームに、 "ダウンミキシング情報，，と、 "ゲイ ン制御情報"と力もなるメタデータを含む点である。
[0195] "ダウンミキシング情報"は、ダウンミキシングのための情報である。ダウンミキシング とは、音声の再生チャネル数を符号ィ匕チャンネル数よりも少なくする変換であり、ダウ ンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、 このダウンミキシングを再生装置に行わせる。 5.1chの音声ストリームを 2chで再生する ことなどがダウンミキシングの一例である。
[0196] "ゲイン制御情報"とは、プライマリオーディオストリーム側の音声出力時のゲインを 上げ下げする情報である力 ここでは下げるだけでよい。このようにセカンダリオーデ ィォストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出 力をリアルタイムに下げることができる。 Primaryオーディオと Secondaryオーディオを 重畳する場合には、あらかじめミキシングされる Primaryオーディオと Secondaryォー ディォの対が分かっているため、 2本のオーディオのゲインをリアルタイムに制御する 必要は無く、 Primaryオーディオのゲインだけを下げて Secondaryオーディオのゲイン はそのままにミキシング (重畳)することで十分である。力かるメタデータを配置すること で、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリ ームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避ける ことができる。以上が、本実施形態におけるオーディオストリームについての説明であ る。続いて、本実施形態における PlayList情報における改良について説明する。
[0197] くオーディオミキシングアプリケーションを実現するための STN_table>
同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、 本実施形態における PlayList情報には、再生が許可されて!、る複数プライマリオーデ ィォストリーム、複数セカンダリオーディオストリームの組合せが、各 Playltemの STN_ta bleに示されている。
[0198] 以降、本実施形態における STN_tableにつ 、て説明する。オーディオミキシングアブ リケーシヨンを実現するため、 STN_tableには、セカンダリオーディオストリームにおけ る Stream_entryと、 Stream_attributeとの組み力 プライマリオーディオストリームにおけ る Stream_entryと、 Stream_attributeとの組みとは別に存在する。そして、セカンダリオ 一ディォストリームにおける Stream_entryと、 Stream_attributeとの糸且みが、 Comb_info_S econdary— audio— Primary— audioと対 J心 1、丄けりれて V、る。
[0199] (Comb— info— secondary— audio— Primary— audio)
Comb_info_Secondary_audio_Primary_audioは、そのセカンダリオ一ディォストリームの 再生出力をミキシングすることができる 1つ以上のプライマリオーディオストリームを一 意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリ ームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ 以外の属性を有して 、るようなプライマリオーディオストリームの再生時にぉ 、てのみ 、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミ キシングの可否を、ォーサリング時に設定しておくことができる。
[0200] (sp— connection— condition情 Rノ
ま 7こ PlayList†青報【こお 、て、 Sub Playltemの sp— connection— condition†青報 ί¾、 Playlte m情報の connection_condition情報と同じ値に設定される。よって Playltem情報の conn ection— condition†青報力 21 =o C、&)るなら、 SubPlayltem†青報の sp— connection— condition 情報も SP_CC=5に設定される。また SubPlayltem情報の In_Time、 Out_Timeは、 Playlte m情報の In_Time、 Out_Timeと同じ時点を指し示す。
[0201] 以上が本実施形態における記録媒体の改良である。続いて本実施形態に係る再 生装置の内部構成にっ 、て説明する。
<再生装置の内部構成 >
図 41は、第 5実施形態に係る再生装置の内部構成を示す図である。本図に示すよ うに、 TB6、 EB7、オーディオデコーダ 8は、 Audio Mixing Processor (点線で囲まれ た部分）に置き換えられている。この Audio Mixing Processorは、プライマリ TSとセカ ンダリ TSから 2本の音声ストリームを入力し、同時にデコードしてミキシングするもので ある。その他の構成は Out- of-MUXアプリケーションを実現するための内部構成と同 様である。以降、 Audio Mixing Processorについて詈兄明する。 Audio Mixing Proces sorは、 Transport Buffer6a、 6b、 EB7a、 7b、プリロードバッファ 7c、オーディオデコー ダ 8a、 8b、ミキサ 9a、 9bから構成される。
[0202] Transport Buffer6aは、 PID Filter3bから出力された、オーディオストリームの PIDを 有する TSパケットを、先入れ先だし式に格納して、オーディオデコーダ 8aに供する。
Transport Buffer6bは、 PID Filter3dから出力された、オーディオストリームの PIDを 有する TSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ 8bに供す る。
[0203] EB7aは、バッファ 6aに格納された TSパケットを変換することで得られる、 PESパケット を格納するバッファである。
EB7bは、バッファ 6aに格納された TSパケットを変換することで得られる、 PESバケツ トを格納するバッファである。
プリロードバッファ 7cは、 BD- ROM/ローカルストレージから読み出されたファイル so und.bdmvをプリロードしておくためのメモリである。ファイル sound.bdmvとは、メニュー に対する操作に出力すべきオーディオデータを格納したファイルである。
[0204] オーディオデコーダ 8aは、プライマリ TSを構成する PESパケットに対しデコード処理 を行い、非圧縮状態の LPCM状態のオーディオデータを得て出力する。これによりォ 一ディォストリームにおけるデジタル出力がなされる。
オーディオデコーダ 8bは、セカンダリ TSを構成する PESパケットに対しデコード処理 を行い、非圧縮状態の LPCM状態のオーディオデータを得て出力する。これによりォ 一ディォストリームにおけるデジタル出力がなされる。 [0205] ミキサ 9aは、オーディオデコーダ 8aから出力される LPCM状態のデジタルオーディ ォと、オーディオデコーダ 8bから出力される LPCM状態のデジタルオーディオとをミキ シングする。
ミキサ 9bは、ミキサ 9aから出力される LPCM状態のデジタルオーディオと、ノ ッファ 7 cに格納されて 、るサウンドデータとをミキシングする。このサウンドミキサ 9bによるミキ シングは、クリック音の発音を意図したようなナビゲーシヨンコマンドを、コントローラ 22 が解読することでなされる。
[0206] 以上が、本実施形態に力かる再生装置についての説明である。
<オーディオミキシングアプリケーションに対するべリファイ >
上述したように、オーディオミキシングアプリケーションはプライマリオーディオストリ ーム、セカンダリオーディオストリーム力も構成されるので、第 2実施形態に示したよう なべリファイは、プライマリオーディオストリーム、セカンダリオーディオストリームが同 時に読み出された場合を想定して実行される。具体的にいうと、 MainClip, SubClipが 基準としている ATC時間軸において、 1ずつ Windowを、シフトさせてゆく。このシフト の手順は、図 35のフローチャートに示したものと同じである。そして ATSに示される A TC時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリー ム、複数のセカンダリオーディオストリーム、複数の PGストリーム、複数の IGストリーム のうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレート の最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーデ ィォストリームのビットレートの最大値、 PGストリームのビットレートの最大値、 IGストリ ームのビットレートの最大値を合計して、その合計量が 48Mbit以下であるかを判定す る。 48Mbitを越えていれば、 BD-ROM規格に違反していると判定結果を下す。
[0207] 以上のように本実施形態によれば、 BD- ROM、ローカルストレージの双方からプライ マリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマ リオ一ディォストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに 供給する場合でも、 1秒当たりのビット量が、所定の上限を越えないという保障を施す ことができる。力かる保障を与えるので、オーディオミキシングアプリケーションを、効 率的に作成することができる。そのため、オーディオミキシングアプリケーションを実 現するような追力 tlコンテンツを、ローカルストレージにダウンロードして、ローカルストレ 一ジカもデコーダに供給するという供給態様が可能になるので、 BD-ROMの出荷後 に、コメンタリを追加するような供給法を容易に実現することができる。
[0208] (第 6実施形態）
第 1実施开態では、 Playltemにおける In_Time、 Out_Timeと、 SubPlayltemにおける In _Time、 Out_Timeとを一致させることで、 Playltem間の接続点、及び、 SubPlayltemの 接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この 接続点の一致を要求せず、ある程度の時間差を認める。
[0209] この時間差を認める場合、別の制限が必要になる。 Playltem, SubPlayltem間のシー ムレス接続において、上述した STCの変更処理を行うが、この変更処理は、デコーダ 力 Sフリーラン状態にある場合になされる。この場合、シームレス接続では STCが復帰 するまで、デコーダは、同期制御に移ることができないので、 STC変更を伴うシームレ ス接続は実装の都合上、頻繁には受け入れられない。したがって、 Playltemと SubPla yltemの両方にぉ 、て連続する CC=5の接続点は所定の時間間隔 (例えば 3秒程度） を置いて起こるように制限されるべきである。
[0210] 図 42は、オーディオミキシングを示すプレイリストにて指定される Playltemと SubPlayl temの相関を示した図である。図 42の第 1段目は、 PlayList情報における 3つの Playlte m(PlayItem情報 #1、 Playltem情報 #2、 Playltem情報 #3)を示す。これら 3つの Playltem はプライマリ TSを指定しており、 Playltem情報 #1、 Playltem情報 #2間は CC=1に設定さ れ、 Playltem情報 #2、 Playltem情報 #3間は、 CC = 5に設定されている。図 42の第 2段 目は、 PlayList情報における 3つの SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubP layltem#3)を示す。これら 3つの SubPlayltemはセカンダリ TSを指定しており、 SubPlaylt em#l、 SubPlayItem#2間は CC=1に設定され、 SubPlayItem#2、 SubPlayItem#3間は、 S P_CC = 5に設定されている。図 42の第 3段目は、 Progressive PlayList情報における 9 っの3 ？1& ½6111(3 ？1& ½6]11#1、 SubPlayItem#2、 SubPlayItem#3〜SubPlayItem#9) を示す。これら 9つの SubPlayltemはセカンダリ TSを指定しており、 SubPlayItem#3、 Sub Playltem#4間は SP_CC=1に設定され、 SubPlayItem#4、 SubPlayItem#5間は、 SP_CC=5 に設定され、それ以外は、 SC=6に設定されている。 [0211] 本図において、第 2段目の SubPlayItem#3の開始は、第 1段目における Playltem#3の 開始点より 3秒前である。同様に、第 3段目の SubPlayItem#5の開始点は、第 1段目に おける Playltem#3の開始点より 3秒前である。
Playltemと、 SubPlayltemとの STC時間軸切り替えのための時間間隔は、 3秒になつ ているので、 STC時間軸の変更が頻繁になり過ぎることはない。
[0212] また CC=1のタイミングは Playltemに合わせて SP_CC=1で接続される。これは CC=1 のノンシームレス接続時に SubPlayltemだけが再生を連続して継続した場合に、 Playlt emと SubPlayltemの同期再生がずれていくことを防ぐためでもある。
Playltemの途中で SubPlayltemを SP_CC=5で接続すると!/、う接続形態は、一枚のデ イスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。
[0213] 図 43の第 1段目は、劇場公開版とディレクターズカットの両方を構成する PlayList情 報の一例を示す。この PlayList情報のうち、 Playltem#l、 Playltem#2、 Playltem#4から 構成されるがディレクターズカットであり、 Playltem#l、 Playltem#3、 Playltem#4から構 成されるのが劇場公開版である。このように、 Playltem#lと Playltem#4はどちらのバー ジョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異 なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えること 力 Sできる。図 43の第 2段目は、同図の第 1段目における Playltem#l、 Playltem#2、 Pla yltem#4に対応するコメンタリを 1つの SubPlayltemとして定義し、 Playltem#l、 Playltem #3、 Playltem#4に対応するコメンタリとを、別の SubPlayltemとして定義する一例を示 す。この場合、 2つの SubPlayltemのそれぞれにおいて、 Playltem情報 #1、 Playltem情 報 #4に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。
[0214] 図 43の第 3段目は、 Playltem情報 #1、 Playltem情報 #2、 Playltem情報 #3、 Playltem 情報 #4のそれぞれに対応する SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubPlayl tem#3、 SubPlayItem#4)を定義する一例を示す。そして SubPlayItem#lと、 SubPlayltem #2及び SubPlayItem#3との間、 SubPlayItem#2及び SubPlayItem#3と、 SubPlayItem#4と の間は、 CC = 5で接続するものとする。これらの接続点は、 Playltemにおける接続点 と、 3秒の時間間隔を設ける。つまり Playltem#lが終わる 3秒前にコメンタリの方は Sub Playltem#2と SubPlavItem#3に CC=5 (もしくは CC=6)を使って分岐させている。 [0215] また、 Playltem#2、 Playltem#3が終わった 3秒後に CC=5 (もしくは CC=6)を使って Su bPlayItem#4に分岐している。 SubPlayItem#2と SubPlayItem#3の開始、及び、 SubPlay Item#4の開始は、 Playltem#2と Playltem#3の開始、及び、 Playltem#4の開始から、 3 の時間間隔を置いている。以上の時間間隔を置くことにより、 STC時間軸の変更が 頻繁になり過ぎることはない。
[0216] 厳密には、 CC=5は、 SubPlayItem#3から SubPlayItem#4への復帰の時だけ（ATC/S TC時間軸がリセットされるシームレス接続)必要であり、その他は CC=6で代用が可能 である。
以上のように本実施形態によれば、 Playltemの In_Time、 Out_Timeと、 SubPlayltem の In_Time、 Out_Timeとが一致していないので、 ATC Counter2aと 2c、および STC Co unter3aと STC Counter3cの同期は不要となり、再生装置の設計の余地を広げること ができる。
[0217] (第 7実施形態）
第 6実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリーム を BD-ROM、ローカルストレージから同時に読み出しデコーダに供給する場合、ブラ ィマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象と したが、本実施形態では、 Picture in Picture(PiP)再生アプリケーションを実現する場 合におけるビット量制限について説明する。
[0218] PiP再生とは、 PlayList情報の MainPath情報により、動画像を構成する MainClipが指 定されており、 PlayList情報の SubPlayltem情報により、別の動画像を構成する SubCli Pが指定されている場合、前者の動画像 (Primary Video)と、後者の動画像 (Secondary Video)とを、同じ画面内に表示するこという。ここで Primary Videoは HD画像から構成 され、 Secondary Videoは SD画像から構成される。 HD画像は、 1920 X 1080という解像 度を有し、フィルム素材同様、 3750 (もしくは 3753か 3754)クロックのフレーム間隔を有 する。 SD画像は、 720 X 480という解像度を有し、 NTSC素材同様、 1501クロックの表 示間隔、又は、 PAL素材同様、 1800クロックのフレーム間隔を有する。
[0219] SD画像の解像度は、 HD画像の解像度の約 1/4程度なので、 HD画像たる Primary V ideoと、 SD画像たる Secondary Videoとを同じ画面上に表示すると、 Secondary Video は、 Primary Videoに対し、約 1/4程度の大きさになる。
ここで Secondary Videoは、監督や出演者のみが登場している動画像であり、 Primar y Videoにおける映像内容を指さすような演技を行っているものとする。かかる動画像 力 ^Secondary Videoであるなら、力力る Secondary Videoの映像内谷を、 Primary Video の映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や 出演者が指さして、解説しているような、楽しい画面演出を実現することができる。
[0220] <本実施形態における PlayList情報 >
Secondary Videoのためのビデオストリーム (セカンダリビデオストリーム)は、 PlayList 情報の SubPath情報における複数の SubPlayltem情報にて指定される。力かる SubPlay Item情報には、 PiP_Position、 PiP_Sizeという情報要素が新規に追加される。
"PiP_Position"は、 Primary Video再生のための画面プレーン上の X座標、 Y座標を 用いて、 Secondary Videoの再生映像が配置されるべき位置を示す。
[0221] "PiP_Size"は、 Secondary Video再生映像の縦サイズ、横サイズを示す。
また、本実施形態にぉ 、て SubPlayltemの sp_connection_condition情報が" =5"に設 定されて!/、ると!/、うことは、カレント SubPlayltem側の SubClipに多重化されて!/、るセ力 ンダリビデオストリームと、 previousSubPlayltem側の SubClipに多重化されているセカ ンダリビデオストリームとがシームレス接続される保証があることを意味する。かかる Su bPiayltemの sp— connection— condition†青報 ίま、 Playltem†青報の connection— condition†青 報と同じ値に設定されるので、 Playltem情報の connection_condition情報が" =5"であ るなら、 SubPlayltem情報の sp_connection_condition情報も" =5"に設定されねばなら ない。つまり Playltem側のプライマリビデオストリームがシームレス接続されるなら、 Sub Playltem側のセカンダリビデオストリームもシームレス接続されねばならな!/、。また Sub Playltem情報の In— Time、 Out— Timeは、 Playltem情報の In— Time、 Out— Timeと同じ時点 を指し示さねばならない。
[0222] 以上が、本実施形態における記録媒体の改良である。
<本実施形態における再生装置の改良 >
続いて、再生装置の改良について説明する。 Secondary Videoストリームのデコード を行うベぐ本実施形態に係る再生装置のハードウェア構成には、ビデオストリームを デコードするための構成要素力 Sもう一組、追加されている。ここでビデオストリームを デコードするための構成要素とは、 Transport Buffer, Multiplexed Buffer, Elementary Buffer、デコーダ、 Videoプレーンであり、これらはセカンダリビデオストリームをデコー ドする。その他、本実施形態に係る再生装置には、以下の Scaller、合成部が追加さ れている。
[0223] Scalierは、 SubPlayltem情報の PiP_Sizeに示される縦 ·横の大きさに基づき、 Seconda ry Videoプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、 Scalierによりされた拡大又は縮小された再生映像と、ビデオデコーダに より得られた再生映像とを合成することで PiP再生を実現する。合成部による Primary Videoの再生映像と、 Secondary Videoの再生映像との合成は、 SubPlayltem情報にて 規定されている、 PiP_Positionに従ってなされる。こうすることにより、 Primary Videoの 再生映像と、 Secondary Videoの再生映像とが合成された合成映像が再生されること になる。この合成部による合成では、クロマキ一合成、レイヤ合成等が可能であり、 Se condary Videoにおける背景を取り除き、人物部分を抜き出した上で、 Primary Video の再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置に ついての説明である。
[0224] < PiPアプリケーションに対するべリファイ >
PiP再生の実現にあたって、プライマリ TSたるビデオストリーム (プライマリビデオストリ 一ム)、セカンダリ TSたるビデオストリーム (セカンダリビデオストリーム)を同時に読み出 し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリーム を、ビット量を制限するためのベリファイの対象とする。
[0225] 具体的にいうと ATC時間軸において Windowをシフトさせた際、 ATSに示される ATC 時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、 複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数 の PGストリーム、複数の IGストリームのうち、算出されたビットレートが最も高いものを 選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリーム のビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカ ンダリオ一ディォストリームのビットレートの最大値、 PGストリームのビットレートの最大 値、 IGストリームのビットレートの最大値を合計して、その合計量が 48Mbit以下である かを判定する。
[0226] 以上のように本実施形態によれば、 BD- ROM、ローカルストレージの双方からプライ マリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応 するデコーダに供給する場合でも、 1秒当たりのビット量が、所定の上限を越えないと いう保障を施すことができる。力かる保障を与えるので、 PiPアプリケーションを、効率 的に作成することができる。
[0227] (備考）
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明 したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えること ができる。各実施形態に示した通り実施する力、これらの改良'変更を施すか否かは 、何れも任意的
であり、実施する者の主観によることは留意されたい。
[0228] (In— Time、 Out— Time)
図 27では、 TSlの最後の Video Presentation Unitを previousPlayltemの Out— Timeと して選び、 TS2の最初の Video Presentation Unitを previousPlayltem, previousSubPla yltemの In_Timeとして選んだ力 TSlの途中の Video Presentation Unitを previousPlay Itemの Out_Timeとして選び、 TS2の途中の Video Presentation Unitをカレント Playltem 、カレント SubPlayltemの In_Timeとして選んでもよい。この場合、 Playltem、カレント Sub Playltemは、シームレスに接続することができず、 CC=1,SP_CC=1として接続せねばな らない。
[0229] (PlayList情報全体）
2つの Playltem間を CC = 5で接続しょうとする場合、 1つの PlayList情報に属する全 ての Playltem情報、全ての SubPlayltem情報は、 CC = 5として接続せねばならない。
(デコーダへのデータ供給量）
Out_of_MUXにお 、て、デコーダへのデータ供給量は必ずしも大きくなる訳ではな い。例えば、プライマリオーディオストリームが MainClipであり、 CBRの DD(Dolby Digit al)と、 VBRの MLPとから構成されていて、この MLPが、ローカルストレージから供給さ れた CBRの DDに置き換えられるものとする。この場合、デコーダへのデータ供給量は かえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。
[0230] (再生時間差）
CC = 5、 SP_CC=5を実現するにあたって、 1つの Playltemの中での各ビデオストリー ム /オーディオストリームの再生時間差も小さ 、ことが望ま U、。この差もビデオ 1フレ ーム分（1/60〜1/25秒）としても良いし、 1秒以下などとしても良いし、全体の再生時 間に対する割合（1%以下など)であっても良いし、これら 2つを組み合わせたもので あっても良 、。 1つの SubPlayltemの中での各ビデオ/オーディオエレメンタリストリーム の再生時間差も同様である。
[0231] 1つの PIDに、 2つのエレメンタリストリームを格納するケースにおいては、同一 PIDで 格納される 2つのストリームの再生時間長の差は、どちらか再生時間が短いストリーム の方の最小再生単位（1フレーム）の再生時間長未満であることが望ましい。かかるケ ースに該当するのは、 Dolby Digital (AC- 3)と、 MLP(Meridian Lossless Packing)と 力 1つのエレメンタリストリームに格納されて、 BD-ROMに記録される場合である。
[0232] (追加コンテンツに対する処理）
ローカルストレージ 200にダウンロードされた追加コンテンツは、何ヶ月、何年か経 過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
(PIDの代用）
オーディオミキシングアプリケーションの実現時にぉ 、て、プライマリオーディオスト リーム、セカンダリオーディオストリームの区別に PIDを用いたが、 MPEG2-PSを使う場 合には、 PESパケットヘッダの streamjdをそれぞれ異なるものにするのが望ましい。
[0233] またプライマリオーディオストリーム、セカンダリオーディオストリームは、 2つの音声 ストリームが 1つのデマルチプレクサでも弁別可能なように、システムストリームレベル において区別されていればよい。もしくは、 2つのストリームを 1つに束ねる前に、片方 の
PIDを重複しな 、ように付け替えておくだけでもよ!/、。
[0234] (プリロード）
クリック音のためのオーディオデータ（ファイル sound.bdmv)のプリロードは、 BD-RO Mのローデイング時やタイトル切替時に行うことが望ましい。何故なら、 AVClipの再生 中にファイル sound.bdmvを読み出そうとすると、 AVClipとは別のファイルを読み出す ための光ピックアップのシークが発生する力もである。一方、 BD-ROMの装填時ゃタ ィトル切替時には、 AVClipの再生が継続していることは希なので、かかるタイミングに ファイル sound.bdmvを読み出すことにより、機器の応答性を高め AVClip再生が途切 れにくくすることができる。
[0235] (Java(TM)プラットフォーム）
各実施形態にかかる再生装置に、 Java(TM)2Micro_Edition(J2ME) Personal Basis P rofile(PBP 1.0)と、 Globally Executable MHP specification(GEM 1.0.2)for package med ia targetsとをフル実装することで Java(TM)プラットフォームを構成し、 BD- Jアプリケー シヨンを再生装置に実行させてもよい。そしてこのアプリケーションの実行にあたって 、 Out_of_MUXフレームワークを再生装置に実行させてもよ!、。
[0236] (タイトル）
BD-ROMの装填やユーザ操作、装置の状態に応じてタイトルを選択する"モジユー ルマネージャ"を再生装置に設けるのが望ましい。 BD-ROM再生装置内のデコーダ は、この"モジュールマネージャ"によるタイトル選択に応じて、プレイリスト情報に基づ く AVClipの再生を行う。
[0237] アプリケーションマネージャは、 "モジュールマネージャ"がタイトルの選択を行った 際、前のタイトルに対応するアプリケーション管理テーブル (AMT)と、カレントタイトル に対応する AMTとを用いてシグナリングを実行する。このシグナリングは、前のタイト ルに対応する AMTには記載されている力 カレントタイトルに対応する AMTには記載 されていないアプリケーションの動作を終了させ、前のタイトルに対応する AMTには 記載されておらず、カレントタイトルに対応する AMTには記載されているアプリケーシ ヨンの動作を開始させるという制御を行う。
[0238] (ローカルストレージ内のディレクトリ構成）
各実施形態に示したローカルストレージ内の各領域は、 BD-ROMにおけるディスク ルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、この BD-ROMを作成した作成者力 ルート認証局力も配 布を受けたルート証明書を、 BD-ROMに割り当てたものである。ディスクルート証明書 はたとえば X.509の形式で符号されて ヽる。 X.509の仕様は国際電信電話諮問委員 会より発行されており、 CCITT Recommendation X.509 (1988), "The Directory - Au thentication Framework こ れて 、 。
また、 BD- ROM、ローカルストレージの記録内容は、 Advancend Access Content Sy stem(AACS)にて暗号ィ匕され、署名情報が付されて、利用権限が、パーミッションファ ィルに規定されて 、るのが望まし 、。
(実装すべきパッケージ）
BD-ROM再生装置を、 Java(TM)プラットフォームとして実施するにあたっては、以下 の BD- J Extentionを再生装置に実装するのが望ましい。 BD- J Extentionは、 GEM[1. 0.2]を越えた機能を、 Java(TM)プラットフォームに与えるために特ィ匕された、様々なパ ッケージを含んでいる。 BD-J Extentionにて供給されるパッケージには、以下のもの がある。
• org.bluray.media
このパッケージは、 Java(TM) Media FrameWorkに追加すべき、特殊機能を提供す る。アングル、音声、字幕の選択についての制御力 このパッケージに追加される。 •org.bluray.ti
このパッケージは、 GEM[1.0.2]における"サービス"を"タイトル"にマップして動作す るための APIや、 BD-ROM力もタイトル情報を問 、合わせる機構や新たなタイトルを選 択する機構を含む。
• org. bluray. application
このパッケージは、アプリケーションの生存区間を管理するための APIを含む。また 、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問 、合わせ る APIを含む。
•org.biuray.ui
このパッケージは、 BD-ROMに特化されたキーイベントのための定数を定義し、映 像再生との同期を実現するようなクラスを含む。
•org. bluray. vfs このパッケージは、データの所在に拘らず、データをシームレスに再生するため、 B D- ROMに記録されたコンテンツ (on-discコンテンツ)と、 BD- ROMに記録されて!、な!/ヽ Local Storage上のコンテンツ (off-discコンテンツ)とをバインドする機構 (Binding Schem e)を提供する。
[0240] Binding Schemeとは、 BD- ROM上のコンテンツ (AVClip、字幕、 BD- Jアプリケーショ ン)と、 Local Storage上の関連コンテンツとを関連付けるものである。この Binding Sche meは、コンテンツの所在に拘らず、シームレス再生を実現する。
(Virtual Package)
Virtual Packageを生成させるような処理を BD- ROM再生装置に行わせてもよい。こ れは、再生装置が Virtual Package情報を生成することでなされる。 Virtual Package情 報とは、 BD-ROMにおけるボリューム管理情報を拡張した情報である。ここでボリユー ム管理情報は、ある記録媒体上に存在するディレクトリ ファイル構造を規定する情 報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管 理情報とからなる。 Virtual Package情報とは、 BD- ROMのディレクトリ—ファイル構造 を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、 BD-R OMにおけるディレクトリ一ファイル構造の拡張を図ったものである。
[0241] 淛御手順の実現）
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構 成要素による制御手順は、ハードウェア資源を用 、て具体的に実現されて 、ることか ら、自然法則を利用した技術的思想の創作といえ、 "プログラムの発明"としての成立 要件を満たす。
[0242] ·本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログ ラム (オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや 、機能的構成要素の個々の手順を、コンピュータに実行させるような 1つ以上のプロ グラムコードから構成される。ここでプログラムコードは、プロセッサのネイティブコード 、 JAVA (TM)バイトコードというように、様々な種類がある。またプログラムコードによる 各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現 することができる場合、この外部関数をコールするコール文力 プログラムコードにな る。また、 1つのステップを実現するようなプログラムコード力 別々のオブジェクトプロ グラムに帰属することもある。命令種が制限されている RISCプロセッサでは、算術演 算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップ 力 S実現されることちある。
[0243] 本発明に力かるプログラムは、以下のようにして作ることができる。先ず初めに、ソフ トウエア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成 要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア 開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部 関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプ ログラムを記述する。
[0244] 記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは 、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程か らなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行 い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対 して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割 付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム 中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリ に割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコード に変換し、オブジェクトプログラムを得る。
[0245] オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する 。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空 間に割り当て、これらを 1つに結合して、ロードモジュールを生成する。こうして生成さ れるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フロ 一チャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実 行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる [0246] 本発明に係るプログラムは、以下のようにして使用することができる。本発明に係る プログラムを糸且込プログラムとして使用する場合、プログラムにあたるロードモジユー ルを、基本入出力プログラム (BIOS)や、様々なミドルウェア (オペレーションシステム)と 共に、命令 ROMに書き込む。こうした命令 ROMを、制御部に組み込み、 CPUに実行 させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用 することができる。
[0247] 再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム (BIO S)が命令 ROMに組み込まれており、様々なミドルウェア (オペレーションシステム)が、 ハードディスクにプレインストールされている。また、ハードディスクから、システムを起 動するためのブート ROM力 再生装置に設けられている。この場合、ロードモジユー ルのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、 1つのァ プリケーシヨンとしてハードディスクにインストールする。そうすると、再生装置は、ブー ト ROMによるブートストラップを行い、オペレーションシステムを起動した上で、 1つの アプリケーションとして、当該アプリケーションを CPUに実行させ、本発明に係るプログ ラムを使用する。
[0248] ハードディスクモデルの再生装置では、本発明のプログラムを 1つのアプリケーショ ンとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネ ットワークを通じて供給することができる。
(コントローラ 22)
コントローラ 22は、一個のシステム LSIとして実現することができる。
[0249] システム LSIとは、高密度基板上にベアチップを実装し、パッケージングしたものを いう。複数個のベアチップを高密度基板上に実装し、ノ ッケージングすることにより、 あたカゝも 1つの LSIのような外形構造を複数個のベアチップに持たせたものも、システ ム LSIに含まれる (このようなシステム LSIは、マルチチップモジュールと呼ばれる。；)。 ここでパッケージの種別に着目するとシステム LSIには、 QFP (タッドフラッドアレイ） 、 PGA (ピングリッドアレイ)という種別がある。 QFPは、パッケージの四側面にピンが 取り付けられたシステム LSIである。 PGAは、底面全体に、多くのピンが取り付けられ たシステム LSIである。 [0250] これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システム LSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システム LSI におけるこれらのピンに、他の回路を接続することにより、システム LSIは、再生装置の 中核としての役割を果たす。
システム LSIにパッケージングされるベアチップは、 "フロントエンド部"、 "バックェン ド部"、 "デジタル処理部"からなる。 "フロントエンド部"は、アナログ信号を、デジタル 化する部分であり、 "バックエンド部"はデジタル処理の結果、得られたデータを、アナ 口グイ匕して出力する部分である。
[0251] 各実施形態において内部構成図として示した各構成要素は、このデジタル処理部 内に実装される。
先に"組込プログラムとしての使用"で述べたように、命令 ROMには、プログラムにあ たるロードモジュールや、基本入出力プログラム (BIOS)、様々なミドルウェア (オペレー シヨンシステム)が書き込まれる。本実施形態において、特に創作したのは、このプロ グラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュール を格納した命令 ROMを、ベアチップとしてパッケージングすることにより、本発明に係 るシステム LSIは生産することができる。
[0252] 具体的な実装につ!、ては、 SoC実装や SiP実装を用いることが望まし 、。 SoC(Syste m on chip)実装とは、 1チップ上に複数の回路を焼き付ける技術である。 SiP(System in Package)実装とは、複数チップを榭脂等で 1パッケージにする技術である。以上の過 程を経て、本発明に係るシステム LSIは、各実施形態に示した再生装置の内部構成 図を基に作ることができる。
[0253] 尚、上述のようにして生成される集積回路は、集積度の違いにより、 IC、 LSI,スーパ -LSI,ウノレ卜ラ LSIと呼称されることちある。
さらに、各記録再生装置の構成要素の一部又は全てを 1つのチップとして構成して もよい。集積回路化は、上述した SoC実装, SiP実装に限るものではなぐ専用回路又 は汎用プロセスで実現してもよい。 LSI製造後に、プログラムすることが可能な FPGA ( Field Programmable Gate Array)や、 LSI内部の回路セルの接続や設定を再構成可 能なシリコンフィギユラブル'プロセッサを利用することが考えられる。更には、半導体 技術の進歩又は派生する技術により LSIに置き換わる集積回路化の技術が登場すれ ば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バ ィォ技術の適応などが可能性としてありうる。
産業上の利用可能性
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されて おり、この内部構成に基づき量産することが明らかなので、資質において工業上利用 することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有 する。

Claims

請求の範囲
[1] プレイリスト情報が記録された記録媒体であって、
前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの 1つを、メインストリームとして指定して、そのメインストリー ムに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブス トリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報 であり、
前記プレイリスト情報はストリームテープノレを含み、
前記ストリームテーブルは、
メインストリーム及びサブストリームに多重化された複数のエレメンタリストリームのう ち、同時に再生することが許可されている組み合わせを 1つ以上示し、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリ ームを含み、再生が許可されて 、な 、エレメンタリストリームを含まな 、デジタルストリ ームの単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする記録媒体。
[2] メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場 同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値 力 所定値以下になる
ことを特徴とする請求項 1記載の記録媒体。
[3] 前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリ オーディオストリームとがあり、
プライマリオーディオストリーム及びセカンダリオーディオストリームは、オーディオミ キシングアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、 複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそ れぞれから選ばれる
ことを特徴とする請求項 2記載の記録媒体。
[4] 前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデ ォストリームとがあり、
プライマリビデオストリーム及びセカンダリビデオストリームは、ピクチャインピクチャ アプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれる ことを特徴とする請求項 2記載の記録媒体。
[5] プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる 再生区間が定義されたサブストリームとを、再生する再生装置であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定 義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するバケツ トを、メインパス情報に従って読み出す第 1読出部と、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケット を、サブパス情報に従って読み出す第 2読出部と、
デコーダと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリ ームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パ ケットを得て、デコーダに供給する多重分離部とを備え、
多重分離部力 デコーダに供給されるパケットの、単位時間当たりの総データサイ ズは、所定値以下である
ことを特徴とする再生装置。
[6] メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場 同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値 力 所定値以下になる
ことを特徴とする請求項 5記載の再生装置。
[7] 前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリ オーディオストリームとがあり、
前記デコーダは、
プライマリオーディオストリームをデコードする第 1デコーダと、及び、セカンダリオ一 ディォストリームをデコードする第 2デコーダと、第 1、第 2デコーダによるデコード結果 を合成する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそ れぞれ力 選ばれている
ことを特徴とする請求項 6記載の再生装置。
[8] 前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデ ォストリームとがあり、
前記デコーダは、
プライマリビデオストリームをデコードする第 1デコーダと、及び、セカンダリビデオス トリームをデコードする第 2デコーダと、第 1、第 2デコーダによるデコード結果を合成 する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれて ヽ る
ことを特徴とする請求項 6記載の再生装置。
[9] アプリケーションデータを記録媒体に記録する記録方法であって、
アプリケーションデータを生成するステップ、
アプリケーションデータに対するベリファイを行うステップ
ベリファイ結果が正当であるアプリケーションデータが書き込まれた記録媒体を得る ステップを備え、
アプリケーションデータは、プレイリスト情報と、デジタルストリームとを含み、 前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの 1つを、メインストリームとして指定して、そのメインストリー ムに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブス トリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報 であり、
前記プレイリスト情報はストリームテープノレを含み、
前記ストリームテーブルは、
メインストリーム及びサブストリームに多重化された複数のエレメンタリストリームのう ち、同時に再生することが許可されている組み合わせを 1つ以上示し、
前記べリファイのステップは、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリ ームを含み、再生が許可されて 、な 、エレメンタリストリームを含まな 、デジタルストリ ームの単位時間当たりの総データサイズ力 s、所定値以下であることを確認する ことを特徴とする記録方法。
[10] メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場 同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値 力 所定値以下になる
ことを特徴とする請求項 9記載の記録方法。
[11] 前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリ オーディオストリームとがあり、
プライマリオーディオストリーム及びセカンダリオーディオストリームは、オーディオミ キシングアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそ れぞれから選ばれる
ことを特徴とする請求項 10記載の記録方法。
[12] 前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデ ォストリームとがあり、
プライマリビデオストリーム及びセカンダリビデオストリームは、ピクチャインピクチャ アプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれる ことを特徴とする請求項 10記載の記録方法。
[13] ストリームは、複数のパケットから構成され、各パケットには、ァライバルタイムスタン プが付与されており、
前記記録方法は、
複数ァライバルタイムスタンプの基準となる時間軸上に、前記単位時間の長さをも つウィンドウを定義し、ァライバルタイムスタンプに示される座標に従い、当該ウィンド ゥを、この時間軸上でシフトさせてゆくステップを含み、
前記べリファイステップにおける総データサイズの確認は、
ウィンドウ力 ^回するシフトする毎に、行われる
ことを特徴とする請求項 9記載の記録方法。
[14] プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる 再生区間が定義されたサブストリームとを、再生する再生方法であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定 義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するバケツ トを、メインパス情報に従って読み出す第 1読出ステップと、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケット を、サブパス情報に従って読み出す第 2読出ステップと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリ ームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パ ケットを得て、デコーダに供給する多重分離ステップとを備え、
多重分離部力 デコーダに供給されるパケットの、単位時間当たりの総データサイ ズは、所定値以下である
ことを特徴とする再生方法。
PCT/JP2006/307441 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法 WO2006109716A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP06731388A EP1873775A4 (en) 2005-04-07 2006-04-07 RECORDING MEDIUM, PLAYING DEVICE, RECORDING METHOD AND PLAYBACK PROCESS
CN2006800111205A CN101156209B (zh) 2005-04-07 2006-04-07 记录媒体、再现装置、记录方法、再现方法
US11/910,249 US7991270B2 (en) 2005-04-07 2006-04-07 Recording medium, reproducing device, recording method, and reproducing method
CA2602713A CA2602713C (en) 2005-04-07 2006-04-07 Recording medium, reproducing device, recording method, and reproducing method
BRPI0607028-0A BRPI0607028A2 (pt) 2005-04-07 2006-04-07 meio de gravação, dispositivo de reprodução, método de gravação, e método de reprodução
JP2007512969A JP4414460B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
JP2005-111425 2005-04-07
JP2005111426 2005-04-07
JP2005-111429 2005-04-07
JP2005111425 2005-04-07
JP2005111429 2005-04-07
JP2005-111428 2005-04-07
JP2005-111427 2005-04-07
JP2005111427 2005-04-07
JP2005-111426 2005-04-07
JP2005111428 2005-04-07

Publications (1)

Publication Number Publication Date
WO2006109716A1 true WO2006109716A1 (ja) 2006-10-19

Family

ID=37086991

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/JP2006/307442 WO2006109717A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法
PCT/JP2006/307441 WO2006109716A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法
PCT/JP2006/307443 WO2006109718A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/307442 WO2006109717A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/307443 WO2006109718A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法

Country Status (9)

Country Link
US (5) US7991270B2 (ja)
EP (3) EP1873776B1 (ja)
JP (5) JP4414460B2 (ja)
KR (1) KR101268327B1 (ja)
CN (2) CN102034513B (ja)
BR (1) BRPI0607028A2 (ja)
CA (1) CA2602713C (ja)
TW (1) TWI393124B (ja)
WO (3) WO2006109717A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199528A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
JP2008199527A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
US9131203B2 (en) 2009-09-30 2015-09-08 Sharp Kabushiki Kaisha Information recording medium, reproduction method and recording method using information recording medium, information recording/reproduction device, and 3D conversion unit and information recording device
JP2016507088A (ja) * 2013-06-19 2016-03-07 ドルビー ラボラトリーズ ライセンシング コーポレイション プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102034513B (zh) * 2005-04-07 2013-04-17 松下电器产业株式会社 记录方法和再现装置
EP2011338A1 (en) * 2006-04-21 2009-01-07 Nero AG Apparatus and method for encoding and decoding plurality of digital data sets
JP4779797B2 (ja) 2006-05-10 2011-09-28 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4552889B2 (ja) * 2006-05-10 2010-09-29 ソニー株式会社 記録装置、記録方法および記録プログラム、ならびに、撮像装置および撮像方法
JP4690965B2 (ja) * 2006-08-11 2011-06-01 株式会社東芝 データ記録再生装置
CN101536505B (zh) * 2006-11-16 2011-09-07 富士通半导体股份有限公司 Gop间管理装置
JP4321628B2 (ja) 2007-05-31 2009-08-26 ソニー株式会社 記憶装置、記憶方法および記憶プログラム、ならびに、データ処理装置、データ処理方法およびデータ処理プログラム
JP4750759B2 (ja) * 2007-06-25 2011-08-17 パナソニック株式会社 映像音声再生装置
KR100933003B1 (ko) * 2008-06-20 2009-12-21 드리머 Ｂｄ-ｊ 기반 채널 서비스 제공 방법 및 이를 실현시키기위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체
CA2691727C (en) 2008-09-30 2016-10-04 Panasonic Corporation Recording medium, playback device, system lsi, playback method, glasses, and display device for 3d images
CN102547359B (zh) * 2009-02-19 2014-12-10 松下电器产业株式会社 再现装置、集成电路
JP5829604B2 (ja) * 2009-05-18 2015-12-09 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． ３ｄトリックプレイのためのエントリー・ポイント
US8437603B2 (en) * 2009-05-25 2013-05-07 Panasonic Corporation Recording medium, reproduction device, integrated circuit, reproduction method, and program
US8332529B1 (en) * 2009-05-29 2012-12-11 Adobe Systems Incorporated Media content including introduced code
JP4984181B2 (ja) * 2009-06-22 2012-07-25 ソニー株式会社 再生装置および再生方法
DK2453661T3 (en) * 2009-07-10 2017-10-30 Panasonic Ip Man Co Ltd PLAYBACK, RECORDING PROCEDURE AND SYSTEM, INCLUDING A RECORDING MEDIUM AND PLAYBACK
JP2011151784A (ja) * 2009-12-25 2011-08-04 Panasonic Corp 動画像多重化装置、映像音声記録装置及び動画像多重化方法
KR20120028546A (ko) * 2010-09-15 2012-03-23 삼성전자주식회사 전송 스트림에 대한 트릭 모드 제어 방법 및 이를 수행하는 전송 스트림 전송 장치
US8989280B2 (en) * 2011-06-30 2015-03-24 Cable Television Laboratories, Inc. Frame identification
US20130084053A1 (en) * 2011-10-04 2013-04-04 Utc Fire & Security Corporation System to merge multiple recorded video timelines
US20130336379A1 (en) * 2012-06-13 2013-12-19 Divx, Llc System and Methods for Encoding Live Multimedia Content with Synchronized Resampled Audio Data
KR20140029991A (ko) * 2012-08-31 2014-03-11 삼성전자주식회사 프로그래시브 플레이리스트 재생 장치 및 재생 방법, 기록 장치 및 기록 방법, 이를 위한 정보저장매체
KR102056589B1 (ko) 2013-01-21 2019-12-18 돌비 레버러토리즈 라이쎈싱 코오포레이션 상이한 재생 디바이스들에 걸친 라우드니스 및 동적 범위의 최적화
EP2992683A1 (en) * 2013-04-30 2016-03-09 Dolby Laboratories Licensing Corporation System and method of outputting multi-lingual audio and associated audio from a single container
JP6476192B2 (ja) 2013-09-12 2019-02-27 ドルビー ラボラトリーズ ライセンシング コーポレイション 多様な再生環境のためのダイナミックレンジ制御
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US20200210855A1 (en) * 2018-12-28 2020-07-02 Robert Bosch Gmbh Domain knowledge injection into semi-crowdsourced unstructured data summarization for diagnosis and repair
US11947696B2 (en) * 2021-07-16 2024-04-02 EMC IP Holding Company LLC File system content obfuscation in high security environments

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002158971A (ja) * 2000-04-21 2002-05-31 Sony Corp 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
WO2004023481A1 (ja) * 2002-08-30 2004-03-18 Fujitsu Limited Ｒｏｍ−ｒａｍ媒体及び、その記憶装置
EP1408505A1 (en) 2002-10-11 2004-04-14 Deutsche Thomson-Brandt Gmbh Method and apparatus for synchronizing data streams containing audio, video and/or other data
JP2004120099A (ja) * 2002-09-24 2004-04-15 Sony Corp 情報処理装置および方法、プログラム、並びに記録媒体
WO2005011273A1 (ja) 2003-06-18 2005-02-03 Matsushita Electric Industrial Co., Ltd. 再生装置、記録媒体、プログラム、再生方法

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0385972A (ja) 1989-08-30 1991-04-11 Toshiba Corp ディジタル撮像方法及びその装置
US5448440A (en) 1994-06-16 1995-09-05 Minnesota Mining And Manufacturing Company Data storage device with roller lubricant that provides excellent drag force characteristics
TW436777B (en) * 1995-09-29 2001-05-28 Matsushita Electric Ind Co Ltd A method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
CN1309252C (zh) 1997-09-17 2007-04-04 松下电器产业株式会社 将视频数据记录在光盘的设备和方法
JP2002093125A (ja) * 1997-09-17 2002-03-29 Matsushita Electric Ind Co Ltd 光ディスク、ビデオデータ編集装置、編集プログラムを記録したコンピュータ読み取り可能な記録媒体、光ディスクの再生装置、再生プログラムを記録したコンピュータ読み取り可能な記録媒体
JP3997367B2 (ja) * 1998-04-30 2007-10-24 ソニー株式会社 記録再生装置および方法、並びに記録媒体
AU1384400A (en) 1998-12-14 2000-07-03 Koninklijke Philips Electronics N.V. Record carrier, and apparatus and method for playing back a record carrier, and method of manufacturing a record carrier
KR100795255B1 (ko) 2000-04-21 2008-01-15 소니 가부시끼 가이샤 정보 처리 장치 및 방법, 프로그램과 기록 매체
WO2001082610A1 (en) * 2000-04-21 2001-11-01 Sony Corporation Information processing apparatus and method, program, and recorded medium
WO2001082611A1 (fr) * 2000-04-21 2001-11-01 Sony Corporation Procede et appareil de traitement d'informations, support enregistre, et programme
DK2172938T3 (da) 2001-03-08 2013-07-22 Sony Corp Anordning og fremgangsmåde til gengivelse af data
CN100370821C (zh) 2002-04-10 2008-02-20 索尼株式会社 数据记录装置、数据记录方法、程序存储介质以及程序
KR100582953B1 (ko) * 2002-06-05 2006-05-23 엘지전자 주식회사 기록매체의 기록 스트림 관리방법
TWI315867B (en) 2002-09-25 2009-10-11 Panasonic Corp Reproduction apparatus, optical disc, recording medium, and reproduction method
JP3717880B2 (ja) 2002-10-01 2005-11-16 パイオニア株式会社 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
AU2003284480A1 (en) * 2002-11-28 2004-06-18 Matsushita Electric Industrial Co., Ltd. Data processing device
DE602004023815D1 (de) 2003-01-20 2009-12-10 Lg Electronics Inc Aufzeichnungsmedium mit einer datenstruktur zur verwaltung der wiedergabe von darauf aufgezeichneten standbildern und aufzeichnungs- und wiedergabeverfahren und vorrichtungen
KR100920655B1 (ko) * 2003-03-03 2009-10-09 엘지전자 주식회사 고밀도 광디스크의 스틸 픽처 관리방법
JP3657946B2 (ja) 2003-03-25 2005-06-08 株式会社東芝 情報記録媒体、情報記録／再生方法、および情報記録／再生装置
EP2068563B1 (en) * 2003-06-30 2010-11-10 Panasonic Corporation Recording medium, reproduction device, recording method, program, and reproduction method
WO2005015907A1 (ja) 2003-08-08 2005-02-17 Matsushita Electric Industrial Co., Ltd. データ処理装置及びデータ処理方法
KR20050036277A (ko) 2003-10-15 2005-04-20 엘지전자 주식회사 고밀도 광디스크의 네비게이션 정보 관리방법
KR20050066264A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
EP1728251A1 (en) 2004-03-17 2006-12-06 LG Electronics, Inc. Recording medium, method, and apparatus for reproducing text subtitle streams
US7756398B2 (en) 2004-03-26 2010-07-13 Lg Electronics, Inc. Recording medium and method and apparatus for reproducing text subtitle stream for updating palette information
EP2270802A3 (en) * 2004-07-22 2011-01-19 Panasonic Corporation Playback apparatus for performing application-synchronized playback
EP1787297A1 (en) * 2004-08-17 2007-05-23 LG Electronics Inc. Method and apparatus of reproducing data recorded on recording medium and local storage
CN102034513B (zh) * 2005-04-07 2013-04-17 松下电器产业株式会社 记录方法和再现装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002158971A (ja) * 2000-04-21 2002-05-31 Sony Corp 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体
WO2004023481A1 (ja) * 2002-08-30 2004-03-18 Fujitsu Limited Ｒｏｍ−ｒａｍ媒体及び、その記憶装置
JP2004120099A (ja) * 2002-09-24 2004-04-15 Sony Corp 情報処理装置および方法、プログラム、並びに記録媒体
EP1408505A1 (en) 2002-10-11 2004-04-14 Deutsche Thomson-Brandt Gmbh Method and apparatus for synchronizing data streams containing audio, video and/or other data
WO2005011273A1 (ja) 2003-06-18 2005-02-03 Matsushita Electric Industrial Co., Ltd. 再生装置、記録媒体、プログラム、再生方法

Non-Patent Citations (1)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199528A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
JP2008199527A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
US9131203B2 (en) 2009-09-30 2015-09-08 Sharp Kabushiki Kaisha Information recording medium, reproduction method and recording method using information recording medium, information recording/reproduction device, and 3D conversion unit and information recording device
JP2016507088A (ja) * 2013-06-19 2016-03-07 ドルビー ラボラトリーズ ライセンシング コーポレイション プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ

Also Published As

Publication number Publication date
WO2006109718A1 (ja) 2006-10-19
US20090185791A1 (en) 2009-07-23
CN102005228B (zh) 2013-04-10
TWI393124B (zh) 2013-04-11
JP2011090771A (ja) 2011-05-06
EP1873775A4 (en) 2009-10-14
JP4414460B2 (ja) 2010-02-10
US20090154904A1 (en) 2009-06-18
EP1873776B1 (en) 2011-11-30
KR20070121813A (ko) 2007-12-27
JP2011081897A (ja) 2011-04-21
JP4944237B2 (ja) 2012-05-30
WO2006109717A1 (ja) 2006-10-19
TW200703250A (en) 2007-01-16
JP4676493B2 (ja) 2011-04-27
CN102034513A (zh) 2011-04-27
JPWO2006109717A1 (ja) 2008-11-13
US8059942B2 (en) 2011-11-15
EP1873776A1 (en) 2008-01-02
EP1873773A4 (en) 2009-10-14
US7991270B2 (en) 2011-08-02
US20120002943A1 (en) 2012-01-05
JPWO2006109716A1 (ja) 2008-11-13
CN102005228A (zh) 2011-04-06
EP1873773B1 (en) 2011-11-30
EP1873775A1 (en) 2008-01-02
US8548298B2 (en) 2013-10-01
JP4774469B2 (ja) 2011-09-14
BRPI0607028A2 (pt) 2009-07-28
CN102034513B (zh) 2013-04-17
CA2602713A1 (en) 2006-10-19
KR101268327B1 (ko) 2013-05-28
JPWO2006109718A1 (ja) 2008-11-13
JP4676492B2 (ja) 2011-04-27
CA2602713C (en) 2014-05-13
US20120106926A1 (en) 2012-05-03
EP1873773A1 (en) 2008-01-02
US8116613B2 (en) 2012-02-14
EP1873776A4 (en) 2009-09-30
US20090097821A1 (en) 2009-04-16

Similar Documents

Publication Publication Date Title
JP4414460B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP5314097B2 (ja) 記録装置および情報記録方法
CN101156209B (zh) 记录媒体、再现装置、记录方法、再现方法
JP4827642B2 (ja) 記録装置、記録方法、プログラムおよび集積回路
RU2415483C2 (ru) Устройство воспроизведения

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680011120.5

Country of ref document: CN

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

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2007512969

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1200702020

Country of ref document: VN

WWE Wipo information: entry into national phase

Ref document number: 3784/KOLNP/2007

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 1020077025227

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2006731388

Country of ref document: EP

Ref document number: 2007141173

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2006731388

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11910249

Country of ref document: US

ENP Entry into the national phase

Ref document number: PI0607028

Country of ref document: BR

Kind code of ref document: A2