WO2010116955A1 - 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム - Google Patents

情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム Download PDF

Info

Publication number
WO2010116955A1
WO2010116955A1 PCT/JP2010/056078 JP2010056078W WO2010116955A1 WO 2010116955 A1 WO2010116955 A1 WO 2010116955A1 JP 2010056078 W JP2010056078 W JP 2010056078W WO 2010116955 A1 WO2010116955 A1 WO 2010116955A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
file
data
clip
information
Prior art date
Application number
PCT/JP2010/056078
Other languages
English (en)
French (fr)
Inventor
加藤 元樹
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/995,305 priority Critical patent/US8582953B2/en
Priority to MX2010013105A priority patent/MX2010013105A/es
Priority to AU2010235565A priority patent/AU2010235565B2/en
Priority to PL10761654T priority patent/PL2288172T3/pl
Priority to RU2010149063/08A priority patent/RU2523196C2/ru
Priority to ES10761654.2T priority patent/ES2552391T3/es
Priority to BRPI1002810A priority patent/BRPI1002810A2/pt
Priority to DK10761654.2T priority patent/DK2288172T3/en
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to CN201080001711.0A priority patent/CN102292999B/zh
Priority to EP10761654.2A priority patent/EP2288172B1/en
Priority to CA 2724975 priority patent/CA2724975C/en
Publication of WO2010116955A1 publication Critical patent/WO2010116955A1/ja
Priority to HK12104520A priority patent/HK1164000A1/xx
Priority to US13/929,330 priority patent/US9781402B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor
    • H04N5/93Regeneration of the television signal or of selected parts thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/87Regeneration of colour television signals
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G11B20/1252Formatting, e.g. arrangement of data block or words on the record carriers on discs for discontinuous data, e.g. digital information signals, computer programme data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; 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/30Indexing; 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/3027Indexing; 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
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; 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/32Indexing; 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/322Indexing; 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 used signal is digitally coded
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189Recording image signals; Reproducing recorded image signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365Multiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347Demultiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4385Multiplex stream processing, e.g. multiplex stream decrypting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8451Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation 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/8205Transformation 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/8227Transformation 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
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/10527Audio or video recording; Data buffering arrangements
    • G11B2020/10537Audio or video recording
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/10527Audio or video recording; Data buffering arrangements
    • G11B2020/10537Audio or video recording
    • G11B2020/10592Audio or video recording specifically adapted for recording or reproducing multichannel signals
    • G11B2020/106113D video data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B2020/1264Formatting, e.g. arrangement of data block or words on the record carriers wherein the formatting concerns a specific kind of data
    • G11B2020/1289Formatting of user data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2541Blu-ray discs; Blue laser DVR discs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/765Interface circuits between an apparatus for recording and another apparatus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/765Interface circuits between an apparatus for recording and another apparatus
    • H04N5/775Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/84Television signal recording using optical recording
    • H04N5/85Television signal recording using optical recording on discs or drums
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation 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/8042Transformation 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation 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/8205Transformation 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/87Regeneration of colour television signals
    • H04N9/8715Regeneration 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 relates to an information processing device, an information processing method, a playback device, a playback method, and a program, and in particular, an information processing device that can appropriately play back 3D (Dimension) image content from a recording medium,
  • the present invention relates to an information processing method, a playback device, a playback method, and a program.
  • two-dimensional (2D) image content is the mainstream as content for movies and the like, but recently, three-dimensional (3D) image (graphic) content capable of stereoscopic viewing has attracted attention.
  • 3D images There are various methods for displaying 3D images (hereinafter, also referred to as stereo images). Regardless of which method is used, the amount of 3D images is greater than the amount of 2D images. Become big.
  • high-resolution image content such as movies may have a large capacity, and in order to record such a large-capacity image content as a 3D image with a large amount of data, a large-capacity recording medium is required.
  • Such a large-capacity recording medium includes, for example, Blu-Ray (registered trademark) Disc (hereinafter also referred to as BD) such as BD (Blu-Ray (registered trademark))-ROM (Read Only Memory).
  • BD Blu-Ray (registered trademark) Disc
  • BD Blu-Ray (registered trademark)
  • ROM Read Only Memory
  • the editing is performed by dividing or combining the filed signals at arbitrary positions by specifying the recording position of the signal on the recording medium by a predetermined unit smaller than the sector by the filer means. Even in the processing, it is not necessary to re-record in the recording medium so that only the editing target portion of the signal is made into a file, and the editing processing can be performed only on the file management information, and thus the editing processing can be greatly simplified.
  • a file management apparatus has been proposed (Patent Document 1).
  • the current BD standard does not stipulate how to record and play back 3D image content on a BD.
  • the 3D image content may not be played back properly.
  • the present invention has been made in view of such a situation, and enables a content of a stereo image (3D image) to be appropriately reproduced from a recording medium such as a BD.
  • the playback device includes a basic stream generated by encoding a video stream using a predetermined encoding method, and a first multiplexed stream including the basic stream among the extended streams, Then, an interleaved file that is a file in which the second multiplexed stream including the extension stream corresponding to the basic stream is interleaved in units of chunks having a predetermined data amount is read from the recording medium, and the first multiplexed Read out a first information file that is information of a multiplexed stream and includes the number of chunks constituting the multiplexed stream and a start packet number in the first multiplexed stream of each chunk; Information of the multiplexed stream, the number of chunks constituting the second multiplexed stream, and Read means for reading a second information file having a start packet number in the second multiplexed stream of each chunk, and using the first information file and the second information file, the interleaving Separating means for separating the file into the first multiplexe
  • the chunk may be a collection of source packets continuously arranged on the recording medium.
  • the number of chunks included in the first information file and the number of chunks included in the second information file may be equal.
  • the first information file further includes information on the total number of source packets constituting the first multiplexed stream, and the second information file further constitutes the second multiplexed stream. It is possible to have information on the total number of source packets.
  • the k-th chunk from the head of the stream is represented as B [k]
  • the head of the second multiplexed stream is
  • the kth chunk is represented as D [k]
  • the start packet number of B [k] is represented as SPN_chunk_start_1 [k]
  • the start packet number of D [k] is represented as SPN_chunk_start_2 [k]
  • the first When the total number of source packets constituting the multiplexed stream is represented as number_of_source_packets1, and the total number of source packets constituting the second multiplexed stream is represented as number_of_source_packets2, k 0 to (n ⁇ For 1),
  • a control means for controlling reading by the reading means can be further provided.
  • the control means represents the information of the first multiplexed stream, and represents the number of entry points in the first multiplexed stream and PTS (Presentation Time Stamp) for each entry point.
  • EP_map which is information including PTS_EP_start [i] and SPN_EP_start [i] which is a source packet number indicating the position is read, and PTS_EP_start [m] having the closest value smaller than the specified playback start time is detected.
  • SPN_EP_start [m] corresponding to PTS_EP_start [m] is detected, SPN_chunk_start_1 [k] having the closest value smaller than SPN_EP_start [m] and its k are detected, and the sum of SPN_chunk_start_1 [k] and SPN_chunk_start_2 [k]
  • the read start address of the interleaved file can be determined.
  • the base stream and the extended stream may be a Base view video stream and a Dependent view video stream generated by encoding a video stream with H.264 AVC / MVC, respectively.
  • the playback method includes a basic stream generated by encoding a video stream by a predetermined encoding method, and a first multiplexed stream including the basic stream among extended streams, Then, an interleaved file that is a file in which the second multiplexed stream including the extension stream corresponding to the basic stream is interleaved in units of chunks having a predetermined data amount is read from the recording medium, and the first multiplexed Read out a first information file that is information of a multiplexed stream and includes the number of chunks constituting the multiplexed stream and a start packet number in the first multiplexed stream of each chunk; Information of the multiplexed stream, the number of chunks constituting the second multiplexed stream, and A second information file having a start packet number in the second multiplexed stream of each chunk is read out, and the interleaved file is converted using the first information file and the second information file.
  • the program according to the first aspect of the present invention includes a basic stream generated by encoding a video stream by a predetermined encoding method and a first multiplexed stream including the basic stream among the extension streams,
  • An interleaved file which is a file interleaved in units of chunks of a predetermined data amount with the second multiplexed stream including the extension stream corresponding to the basic stream, is read from the recording medium, and the first multiplexed
  • a first information file that is stream information and includes the number of chunks constituting the multiplexed stream and a start packet number in the first multiplexed stream of each chunk; Number of chunks that are information on the multiplexed stream and constitute the second multiplexed stream , Reading a second information file having a start packet number in the second multiplexed stream of each chunk, and using the first information file and the second information file, the interleaved file
  • the computer is caused to execute processing including a step of separating the first multiplexed stream and the second multiple
  • the information processing apparatus provides the basic information generated by encoding a plurality of video data with a predetermined encoding method and the reproduction management information file for managing the reproduction of the extended stream in the basic information.
  • Recording status information indicating whether or not the stream data and the extended stream data are recorded on the optical disc in a state of being interleaved in units of extents that are predetermined data units is set, and interleaving is performed in units of the extents.
  • setting means for setting a virtual file for managing the basic stream and the extension stream in the reproduction management information file.
  • the setting means includes, in the reproduction management information file, identification information of a clip information file describing information related to a clip that is a reproduction section of the basic stream, and the three-dimensional image used together with the basic stream clip. It is possible to further set identification information of the clip information file that describes information about the clip of the extension stream.
  • the setting means can set information related to the extent of the basic stream in the clip information file of the basic stream, and can set information related to the extent of the extended stream in the clip information file of the extended stream. .
  • the base stream and the extended stream may be a Base view video stream and a Dependent view video stream generated by encoding a video stream with H.264 AVC / MVC, respectively.
  • the information processing method provides the basic information generated by encoding a plurality of video data using a predetermined encoding method and a reproduction management information file for managing reproduction of an extended stream in the basic information.
  • the program according to the second aspect of the present invention includes a playback management information file for managing playback of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the recording state information indicating whether the data and the data of the extension stream are recorded on the optical disc in a state of being interleaved in an extent unit which is a predetermined data unit is set and interleaved in the extent unit If it is recorded in a state, the computer is caused to execute a process including a step of setting a virtual file for managing the basic stream and the extension stream in the reproduction management information file.
  • the playback device is set in a playback management information file for managing playback of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the basic stream and the extension are based on a virtual file that manages the basic stream and the extension stream set in the reproduction management information file. Control means for reading a stream from the optical disc is provided.
  • a playback means for playing back the basic stream and the extended stream read from the optical disc can be further provided.
  • the playback management information file includes identification information of the clip information file in which information about the extent of the extension stream is described as information about the clip
  • the data read by the control unit is Separation means for separating the data of the basic stream and the data of the extension stream based on information on the extent set in the clip information file can be further provided.
  • the information on the extent may be a source packet number at which each extent starts in the stream file associated with the clip.
  • the base stream and the extended stream may be a Base view video stream and a Dependent view video stream generated by encoding a video stream with H.264 AVC / MVC, respectively.
  • the playback method is set in a playback management information file for managing playback of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the basic stream and the extension are based on a virtual file that manages the basic stream and the extension stream set in the reproduction management information file. Reading a stream from the optical disc.
  • the program according to the third aspect of the present invention is set in a reproduction management information file for managing reproduction of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the basic stream and the extended stream based on a virtual file for managing the basic stream and the extended stream set in the reproduction management information file.
  • a process including a step of reading from the optical disc. To be executed by a computer.
  • the playback device is set in a playback management information file for managing playback of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method. Recording state information indicating whether or not the basic stream data and the extension stream data are recorded on the optical disc in a state of being interleaved in extent units, which are predetermined data units, is in extent units.
  • a virtual file for managing the basic stream and the extension stream set in the reproduction management information file is referred to, and the reproduction management information file Playback of the extended stream that is set and managed by the virtual file If the identification information of the clip information file in which information related to the clip in between is described and the identification information of the clip information file of the clip of the extension stream recorded on the optical disc do not match, The data of the extension stream clip recorded on a recording medium different from the optical disc is read as data of the extension stream clip used for reproducing the 3D image together with the clip data of the basic stream. Control means for reading data is provided.
  • the base stream and the extended stream may be a Base view video stream and a Dependent view video stream generated by encoding a video stream with H.264 AVC / MVC, respectively.
  • the playback method according to the fourth aspect of the present invention is set in a playback management information file for managing playback of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method. Recording state information indicating whether or not the basic stream data and the extension stream data are recorded on the optical disc in a state of being interleaved in extent units, which are predetermined data units, is in extent units.
  • a virtual file for managing the basic stream and the extension stream set in the reproduction management information file is referred to, and the reproduction management information file Playback of the extended stream that is set and managed by the virtual file If the identification information of the clip information file in which information related to the clip in between is described and the identification information of the clip information file of the clip of the extension stream recorded on the optical disc do not match, The data of the extension stream clip recorded on a recording medium different from the optical disc is read as data of the extension stream clip used for reproducing the 3D image together with the clip data of the basic stream. Including reading data.
  • the program according to the fourth aspect of the present invention is set in a reproduction management information file for managing reproduction of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the extension stream managed by the virtual file When the identification information of the clip information file in which information about the clip that is the section is described does not match the identification information of the clip information file of the clip of the extension stream recorded on the optical disc, The data of the extension stream clip recorded on the recording medium different from the optical disc is read as data of the extension stream used for reproducing the 3D image together with the clip of the basic stream.
  • a computer is caused to execute a process including a step of reading.
  • a first multiplexed stream including the basic stream of the basic stream and the extended stream generated by encoding the video stream by a predetermined encoding method An interleaved file which is a file in which the second multiplexed stream including the extension stream corresponding to the basic stream is interleaved in units of chunks having a predetermined data amount is read from the recording medium, and the first multiplexed A first information file is read out, which is information on the multiplex stream and includes the number of chunks constituting the multiplex stream and the start packet number in the first multiplex stream of each chunk.
  • the second multiplexed stream information includes a number of chunks constituting the second multiplexed stream and a start packet number in the second multiplexed stream of each chunk. 2 information files are read out, and the interleaved file is separated into the first multiplexed stream and the second multiplexed stream using the first information file and the second information file. .
  • the basic stream data is stored in a reproduction management information file for managing reproduction of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the reproduction management information file is set in a reproduction management information file for managing reproduction of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method.
  • the basic stream and the extension stream based on a virtual file for managing the basic stream and the extension stream set in the reproduction management information file. Are read from the optical disc.
  • the reproduction management information file is set in a reproduction management information file for managing reproduction of a basic stream and an extended stream generated by encoding a plurality of video data using a predetermined encoding method. Recording state information indicating whether the data of the basic stream and the data of the extension stream are recorded on the optical disc in a state of being interleaved in units of extents that are predetermined data units is interleaved in units of the extents.
  • the virtual file managing the basic stream and the extension stream set in the playback management information file is referred to and set in the playback management information file.
  • the content of a stereo image (3D image) can be appropriately reproduced.
  • FIG. 1 It is a figure which shows the structural example of the reproduction
  • FIG. 12 is a diagram illustrating the syntax of PlayList () in FIG. 11.
  • Fig. 13 is a diagram illustrating the syntax of SubPath () in Fig. 12. It is a figure which shows the syntax of SubPlayItem (i) of FIG.
  • Fig. 13 is a diagram illustrating the syntax of PlayItem () in Fig. 12.
  • Fig. 16 is a diagram illustrating the syntax of STN_table () in Fig. 15. It is a figure which shows the specific example of 3D_PlayList. It is a figure which shows the meaning of type. It is a figure which shows the meaning of SubPath_type.
  • FIG. 6 is a diagram illustrating an example of syntax of chunk_map ().
  • FIG. It is a figure which shows the specific example of chunk_map (). It is a figure shown about separation of a chunk. It is a figure which shows the other example of 3D_PlayList.
  • FIG. 30 is a flowchart for describing playback processing performed in accordance with the 3D_PlayList file of FIG. 29. It is a figure which shows the further another example of 3D_PlayList. It is a figure which shows the syntax of a clpi file. It is a figure which shows the concept of the file management performed using the data of FIG. 33, FIG. It is a flowchart explaining the reproduction
  • EP_map It is a figure which shows the syntax of EP_map (). It is a flowchart explaining the random access process of a reproducing
  • FIG. 1 is a diagram showing a configuration example of a playback system including a playback device 201 to which the present invention is applied.
  • this playback system is configured by connecting a playback device 201 and a display device 203 with an HDMI (High Definition Multimedia Interface) cable or the like.
  • An optical disc 202 such as a BD is mounted on the playback device 201.
  • the data of each stream is recorded on the optical disc 202 in an interleaved state in units of extents.
  • the playback device 201 is a player that supports 3D playback of a stream recorded on the optical disc 202.
  • the playback device 201 plays back a stream recorded on the optical disc 202 and displays a 3D image obtained by playback on a display device 203 such as a television receiver. Similarly, the sound is reproduced by the reproducing device 201 and output from a speaker or the like provided in the display device 203.
  • the optical disc 202 records a stream that can display a 3D image.
  • H.264 ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ AVC (Advanced Video ⁇ ⁇ ⁇ Coding) / MVC (Multi-view Video coding) is adopted as an encoding method for recording a stream on the optical disc 202.
  • H.264 AVC / MVC Profile In H.264 AVC / MVC, an image stream called Base view video and an image stream called Dependent view video are defined.
  • H.264 AVC / MVC is simply referred to as MVC as appropriate.
  • FIG. 2 is a diagram showing an example of photographing.
  • shooting is performed on the same subject using an L image camera and an R image camera.
  • An elementary stream of video shot by the L image camera and the R image camera is input to the MVC encoder.
  • FIG. 3 is a block diagram showing a configuration example of the MVC encoder.
  • the MVC encoder 211 includes an H.264 / AVC encoder 221, an H.264 / AVC decoder 222, a Depth calculation unit 223, a Dependent view video encoder 224, and a multiplexer 225.
  • the stream of video # 1 captured by the L image camera is input to the H.264 / AVC encoder 221 and the depth calculator 223. Also, the stream of video # 2 captured by the R image camera is input to the Depth calculation unit 223 and the Dependent view video encoder 224. The stream of video # 2 may be input to the H.264 / AVC encoder 221 and the depth calculation unit 223, and the stream of video # 1 may be input to the depth calculation unit 223 and the DependentDependview video encoder 224.
  • the H.264 / AVC encoder 221 encodes the video # 1 stream as, for example, an H.264 AVC / High Profile video stream.
  • the H.264 / AVC encoder 221 outputs the AVC video stream obtained by encoding to the H.264 / AVC decoder 222 and the multiplexer 225 as a Base view video stream.
  • the H.264 / AVC decoder 222 decodes the AVC video stream supplied from the H.264 / AVC encoder 221, and outputs the video # 1 stream obtained by decoding to the Dependent view video encoder 224.
  • the Depth calculation unit 223 calculates Depth (parallax) based on the stream of the video # 1 and the stream of the video # 2, and outputs the calculated depth data to the multiplexer 225.
  • the Dependent video video encoder 224 encodes the video # 1 stream supplied from the H.264 / AVC decoder 222 and the video # 2 stream input from the outside, and outputs a Dependent video video stream.
  • Base view ⁇ video does not allow predictive encoding using another stream as a reference image, but as shown in FIG. 4, Dependent view video allows predictive encoding using Base ⁇ ⁇ view video as a reference image.
  • Dependent view video allows predictive encoding using Base ⁇ ⁇ view video as a reference image.
  • the L image is Base view video and the R image is encoded as Dependent view video
  • the data amount of the resulting Dependent view video stream is smaller than the data amount of the Base view video stream .
  • the Dependent view video encoder 224 outputs the Dependent view video stream obtained by encoding using such prediction between views to the multiplexer 225.
  • the multiplexer 225 includes the Base view video stream supplied from the H.264 / AVC encoder 221, the Dependent view video stream (Depth data) supplied from the Depth calculation unit 223, and the Dependent supplied from the Dependent view video encoder 224.
  • the view video stream is multiplexed as, for example, MPEG2 TS.
  • the Base view video stream and the Dependent view video stream may be multiplexed into one MPEG2 TS, or may be included in separate MPEG2 TS.
  • the multiplexer 225 outputs the generated TS (MPEG2 TS).
  • the TS output from the multiplexer 225 is recorded on the optical disc 202 together with other management data in the recording device, and provided to the playback device 201 in a form recorded on the optical disc 202.
  • D1 view video Dependent view video composed of Depth information
  • D2 view video Dependent view video composed of R images
  • B-D1 playback 3D playback performed using Base view video and D1 view video
  • B-D2 playback 3D playback using Base view video and D2 view video
  • the playback device 201 When performing B-D1 playback in accordance with a user instruction or the like, the playback device 201 reads the Base view video stream and D1 view video stream from the optical disc 202 and plays them back.
  • the playback device 201 reads the Base view video stream and D2 view video stream from the optical disc 202 and plays them back.
  • the playback device 201 reads only the Base view video stream from the optical disc 202 and plays it back.
  • the Base view video stream is an AVC video stream encoded in H.264 / AVC, a player that supports the BD format can play back the Base view video stream and display a 2D image. It becomes possible.
  • FIG. 5 is a diagram illustrating a configuration example of a TS.
  • the streams of Base view video, Dependent view video, Primary audio, Base PG, Dependent PG, Base IG, and Dependent IG are multiplexed.
  • the Dependent view video stream may be included in the Main ⁇ ⁇ ⁇ ⁇ TS together with the Base view video stream.
  • Main TS is a TS including at least the Base view video stream.
  • the Sub-TS is a TS that includes a stream other than the Base-view-video stream and is used together with the Main-TS.
  • ⁇ Streams of Base view and Dependent view are prepared for PG and IG so that 3D display is possible as well as video.
  • FIG. 6 is a diagram illustrating another configuration example of the TS.
  • each stream of Primary audio, Base PG, Dependent PG, Base IG and Dependent IG is multiplexed in Sub TS.
  • the video stream may be multiplexed on the Main TS, and the PG, IG stream, etc. may be multiplexed on the Sub TS.
  • FIG. 7 is a diagram showing still another configuration example of the TS.
  • the streams of Base view video, Primary audio, Base PG, Dependent PG, Base IG, and Dependent IG are multiplexed.
  • Sub TS includes Dependent video stream.
  • the Dependent video stream may be included in a different TS from the Base video stream.
  • FIG. 8 is a diagram illustrating an example of AV stream management by the playback apparatus 201.
  • the AV stream management is performed using two layers, PlayList and Clip, as shown in FIG.
  • the AV stream may be recorded not only on the optical disc 202 but also on the local storage of the playback device 201.
  • a pair of Clip Information which is one AV stream and information accompanying it is considered as one object, and these are collectively called Clip.
  • a file storing an AV stream is referred to as an AV stream file.
  • a file storing ClipCInformation is also called a Clip Information file.
  • the AV stream is developed on the time axis, and the access point of each Clip is mainly designated in the PlayList with a time stamp.
  • the Clip Information file is used for finding an address in the AV stream where decoding should start.
  • PlayList is a collection of AV stream playback sections.
  • One playback section in the AV stream is called PlayItem.
  • PlayItem is represented by a pair of IN point and OUT point of the playback section on the time axis. As shown in FIG. 8, the PlayList is composed of one or a plurality of PlayItems.
  • the first PlayList from the left in FIG. 8 is composed of two PlayItems, and the two PlayItems refer to the first half and the second half of the AV stream included in the left Clip, respectively.
  • the second PlayList from the left is composed of one PlayItem, whereby the entire AV stream included in the right Clip is referenced.
  • the third PlayList from the left is composed of two PlayItems, and the two PlayItems refer to a part of the AV stream included in the left Clip and a part of the AV stream included in the right Clip, respectively. .
  • the PlayList is used as playback management information for managing playback of AV streams.
  • a playback path created by an array of one or more PlayItems in a PlayList is called a main path.
  • a playback path created by arranging one or more SubPlayItems in parallel with the main path is called a sub path.
  • FIG. 9 is a diagram showing the structure of the main path and the sub path.
  • a PlayList can have one Main Path and one or more Sub Paths.
  • the above-described Base view video stream is managed as a stream that is referenced by PlayItems that constitute Main Path.
  • the Dependent view video stream is managed as a stream that is referenced by the SubPlayItem that constitutes the Sub Path.
  • the PlayList in FIG. 9 has one Main path and three Sub paths created from a sequence of three PlayItems.
  • the PlayItems that make up the Main Path are set with IDs in order from the top.
  • the Clip AV stream referenced by one PlayItem includes at least a video stream (main image data).
  • the Clip AV stream may or may not include one or more audio streams that are played back at the same timing (synchronously) as the video stream included in the Clip AV stream.
  • the Clip AV stream may or may not include one or more bitmap subtitle data (PG (Presentation Graphic)) streams that are played back in synchronization with the video stream included in the Clip AV stream. Also good.
  • PG Presentation Graphic
  • the Clip AV stream may or may not include one or more IG (Interactive Graphic) streams that are played back in synchronization with the video stream included in the Clip AV stream file.
  • the IG stream is used to display graphics such as buttons operated by the user.
  • a video stream and zero or more audio streams, zero or more PG streams, and zero or more IG streams reproduced in synchronization therewith are multiplexed. Yes.
  • one SubPlayItem refers to a video stream, an audio stream, a PG stream, or the like, which is a stream (different stream) different from the Clip AV stream referred to by the PlayItem.
  • Such AV stream management using PlayList, PlayItem, and SubPlayItem is described in, for example, Japanese Unexamined Patent Application Publication Nos. 2008-252740 and 2005-348314.
  • FIG. 10 is a diagram illustrating an example of a management structure of files recorded on the optical disc 202.
  • files are managed hierarchically by a directory structure.
  • One root directory is created on the optical disc 202.
  • Under the root directory is a range managed by one recording / reproducing system.
  • BDMV directory is placed under the root directory.
  • An Index file that is a file with the name “Index.bdmv” and a MovieObject file that is a file with the name “MovieObject.bdmv” are stored directly under the BDMV directory.
  • BACKUP directory PLAYLIST directory, CLIPINF directory, STREAM directory, etc. are provided under the BDMV directory.
  • the PLAYLIST directory stores a PlayList file that describes the PlayList.
  • Each PlayList file has a name that is a combination of a 5-digit number and an extension “.mpls”. In one PlayList file shown in FIG. 10, a file name “00000.mpls” is set.
  • the Clip Information file is stored in the CLIPINF directory. Each Clip Information file is set with a name combining a five-digit number and the extension “.clpi”.
  • the file names “00001.clpi”, “00002.clpi”, and “00003.clpi” are set in the three Clip information files in FIG.
  • the Clip Information file is referred to as a clpi file as appropriate.
  • the “00001.clpi” clpi file is a file in which information related to the clip of Base view video is described.
  • the "00002.clpi" clpi file is a file that describes information related to the clip of D2 video.
  • the “00003.clpi” clpi file is a file that describes information related to the clip of D1 video.
  • Stream file is stored in STREAM directory.
  • Each stream file is set with a name combining a 5-digit number and an extension “.m2ts”, or a name combining a 5-digit number and an extension “.ilvt”.
  • a file with the extension “.m2ts” is appropriately referred to as an m2ts file.
  • a file with the extension “.ilvt” is called an ilvt file.
  • the m2ts file of“ 00001.m2ts ” is a file for 2D playback. By specifying this file, the Base view video stream is read.
  • the m2ts file of“ 00002.m2ts ” is the file of the D2 view video stream
  • the m2ts file of“ 00003.m2ts ” is the file of the D1 view video stream.
  • the “10000.ilvt” ilvt file is a B-D1 playback file. By specifying this file, the Base view video stream and the D1 view video stream are read.
  • the ilvt file of“ 20000.ilvt ” is a file for B-D2 playback. By specifying this file, the Base view video stream and the D2 view video stream are read.
  • a directory for storing audio stream files is also provided under the BDMV directory.
  • FIG. 11 is a diagram illustrating the syntax of the PlayList file.
  • the PlayList file is a file with an extension “.mpls” stored in the PLAYLIST directory of FIG.
  • type_indicator in FIG. 11 represents the file type of “xxxxx.mpls”.
  • “Version_number” represents the version number of “xxxx.mpls”. version_number consists of a 4-digit number. For example, “0240” indicating “3D Spec version” is set in the PlayList file for 3D playback. A PlayList described in a PlayList file in which “0240” is set becomes a 3D_PlayList described later.
  • PlayList_start_address represents the start address of PlayList () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • PlayListMark_start_address represents the start address of PlayListMark () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • ExtensionData_start_address represents the start address of ExtensionData () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • ExtensionData_start_address After the ExtensionData_start_address, a 160-bit reserved_for_future_use is included.
  • AppInfoPlayList stores parameters related to playback control of the PlayList, such as playback restrictions.
  • PlayList parameters related to Main Path and Sub Path are stored. The contents of PlayList () will be described later.
  • PlayListMark stores PlayList mark information, that is, information about a mark that is a jump destination (jump point) in a user operation or command that commands chapter jump or the like.
  • ExtensionData Private data can be inserted into ExtensionData ().
  • FIG. 12 is a diagram showing the syntax of PlayList () in FIG.
  • Length is a 32-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of PlayList (). That is, length represents the number of bytes from reserved_for_future_use to the end of the PlayList.
  • a 16-bit reserved_for_future_use is prepared after the length.
  • FIG. 13 is a diagram showing the syntax of SubPath () in FIG.
  • Length is a 32-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of Sub-Path (). That is, length represents the number of bytes from reserved_for_future_use to the end of the PlayList.
  • a 16-bit reserved_for_future_use is prepared after the length.
  • SubPath_type is an 8-bit field that indicates the type of Sub-Path application.
  • SubPath_type is used, for example, when the type indicates whether Sub-Path is audio, bitmap subtitle, or text subtitle.
  • Is_repeat_SubPath is a 1-bit field that specifies the Sub-Path playback method, and indicates whether the Sub-Path playback is repeated during the Main Path playback or the Sub-Path playback is performed only once. For example, it is used when the playback timing of the Clip referenced by the Main Path differs from that of the Clip referenced by the Sub Path (when using the Main Path as a slideshow path for still images and the Sub Path as background music) The
  • FIG. 14 is a diagram showing the syntax of SubPlayItem (i) in FIG.
  • “Length” is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of SubItemplayItem ().
  • SubPlayItem refers to one Clip.
  • Clip_Information_file_name [0] represents the name of the Clip Information file of the Clip referred to by SubPlayItem.
  • Clip_codec_identifier [0] represents the codec system of Clip. Reserved_for_future_use is included after Clip_codec_identifier [0].
  • Is_multi_Clip_entries is a flag indicating whether or not a multi-clip is registered.
  • is_multi_Clip_entries flag is set, the syntax when SubPlayItem refers to a plurality of Clips is referenced.
  • Ref_to_STC_id [0] is information related to STC discontinuities (system time base discontinuities).
  • SubPlayItem_IN_time represents the start position of the Sub-Path playback section
  • SubPlayItem_OUT_time represents the end position
  • Sync_PlayItem_id and sync_start_PTS_of_PlayItem represent the time at which the Sub-Path starts to play on the Main-Path time axis.
  • SubPlayItem_IN_time, SubPlayItem_OUT_time, sync_PlayItem_id, and sync_start_PTS_of_PlayItem are commonly used in the Clip referred to by SubPlayItem.
  • Num_of_Clip_entries represents the number of clips to be referenced.
  • the number of Clip_Information_file_name [SubClip_entry_id] specifies the number of Clips excluding Clip_Information_file_name [0].
  • Chip_codec_identifier [SubClip_entry_id] represents the codec system of Clip.
  • Ref_to_STC_id [SubClip_entry_id] is information related to STC discontinuity points (system time base discontinuity points). Reserved_for_future_use is included after ref_to_STC_id [SubClip_entry_id].
  • FIG. 15 is a diagram showing the syntax of PlayItem () in FIG.
  • Length is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of PlayItem ().
  • Clip_Information_file_name [0] represents the name of the Clip Information file of the Clip referred to by PlayItem. Note that the same five-digit number is included in the file name of the m2ts file including the clip and the file name of the corresponding Clip Information file.
  • Clip_codec_identifier [0] represents the codec system of Clip. Reserved_for_future_use is included after Clip_codec_identifier [0]. is_multi_angle and connection_condition are included after reserved_for_future_use.
  • Ref_to_STC_id [0] is information related to STC discontinuities (system time base discontinuities).
  • IN_time represents the start position of the PlayItem playback section
  • OUT_time represents the end position
  • STN_table () includes AV stream information referenced by the target PlayItem.
  • information on the AV stream that is referenced by the SubPlayItem that constitutes the Sub-Path is also included.
  • FIG. 16 is a diagram illustrating the syntax of STN_table () in FIG.
  • STN_table () is set as an attribute of PlayItem.
  • Length is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of STN_table (). 16-bit reserved_for_future_use is prepared after the length.
  • Numberer_of_video_stream_entries represents the number of streams to which video_stream_id is given (registered) in STN_table ().
  • Video_stream_id is information for identifying a video stream. For example, a Base view video stream is specified by this video_stream_id.
  • the ID of the Dependent view video stream may be defined in STN_table (), or may be obtained by calculation by adding a predetermined value to the ID of the Base view video stream.
  • Video_stream_number is a video stream number that is used for video switching and is visible to the user.
  • “Number_of_audio_stream_entries” represents the number of streams of the first audio stream to which audio_stream_id is given, which is entered in STN_table ().
  • the audio_stream_id is information for identifying the audio stream
  • the audio_stream_number is an audio stream number that can be seen by the user used for audio switching.
  • “Number_of_audio_stream2_entries” represents the number of streams of the second audio stream to which audio_stream_id2 is provided, which is entered in STN_table ().
  • the audio_stream_id2 is information for identifying an audio stream
  • the audio_stream_number is an audio stream number that can be seen by the user used for audio switching. In this example, the sound to be reproduced can be switched.
  • “Number_of_PG_txtST_stream_entries” represents the number of streams to which PG_txtST_stream_id is entered in STN_table ().
  • a PG stream obtained by run-length encoding a bitmap subtitle and a text subtitle file (txtST) are entered.
  • PG_txtST_stream_id is information for identifying a subtitle stream
  • PG_txtST_stream_number is a subtitle stream number that can be seen by the user used for subtitle switching.
  • “Number_of_IG_stream_entries” represents the number of streams that are entered in STN_table () and given IG_stream_id. In this, the IG stream is entered.
  • IG_stream_id is information for identifying the IG stream, and
  • IG_stream_number is a graphics stream number that can be seen by the user used for graphics switching.
  • Main TS and Sub TS are also registered in STN_table (). It is described in stream_attribute () that the ID is not the elementary stream but the TS ID.
  • FIG. 17 is a diagram illustrating a specific example of 3D_PlayList, which is a PlayList for 3D playback.
  • the number_of_PlayItems on the second line corresponds to number_of_PlayItems in FIG. 12, and represents the number of PlayItems in the 3D_PlayList.
  • the description from the 2nd line to the 8th line is a description about PlayItem. That is, the third to eighth lines correspond to the description of PlayItem using the for sentence in FIG.
  • Ref_to_B_clpi_file_name on the fifth line corresponds to Clip_Information_file_name [0] in FIG. 15 and represents a 5-digit number excluding the extension “.m2ts” in the file name of the m2ts file storing the Base view video stream.
  • the m2ts file to be referred to and the Clip clpi file of Base view video are specified.
  • the type on the sixth line represents the type of arrangement on the optical disc 202 of the data of Base view video and D1 / D2 view video associated therewith.
  • type is set using reserved_for_future_use following Clip_codec_identifier [0] in FIG.
  • FIG. 18 is a diagram showing the meaning of type.
  • the value of type 0 indicates that Base view video, D1 view video, and D2 view video are not interleaved.
  • both or any of the existing D1 / D2 video packets are multiplexed into a single MPEG2-TS together with the Base video ⁇ ⁇ ⁇ ⁇ packet.
  • type 1 means that Base video, D1 view video, and D2 view video are all interleaved.
  • three TSs including a first TS including B view video, a second TS including D1 view video, and a third TS including D2 view video are interleaved on the optical disc 202 in units of extents. ing.
  • the value of type 2 indicates that Base video D1 view video is interleaved.
  • two TSs a first TS including a B view video packet and a second TS including a D1 view video packet, are interleaved on the optical disc 202 in units of extents.
  • a packet of D2 view video may be multiplexed in the first TS.
  • the D2TSview video packet may be multiplexed in the second TS.
  • type 3 indicates that Base view video and D2 view video are interleaved.
  • two TSs of the first TS including the packet of the B view video and the second TS including the packet of the D2 view video are interleaved on the optical disc 202 in units of extents.
  • a packet of D1 ⁇ view ⁇ ⁇ video may be multiplexed.
  • the second TS must not contain a D1Dview video packet.
  • the STN_table in the seventh row corresponds to the STN_table () in FIG.
  • the STN_table describes the ID of each stream referred to in the 3D_PlayList.
  • the number_of_SubPaths in the ninth line corresponds to number_of_SubPaths in FIG. 12 and represents the number of SubPaths in the 3D_PlayList.
  • the 9th to 14th lines describe the SubPath. That is, the 10th to 14th lines correspond to the description in the SubPath using the for statement in FIG.
  • the SubPath_type on the 12th line corresponds to the SubPath_type in FIG. 13 and represents the type of SubPath.
  • FIG. 19 is a diagram showing the meaning of SubPath_type.
  • a value of 8 for SubPath_type indicates a sub path for reproducing D1 view video.
  • a SubPath_type value of 9 indicates a sub path for playing D2 viewDvideo.
  • Ref_to_clpi_file_name on the 13th line in FIG. 17 corresponds to Clip_Information_file_name [0] in FIG.
  • ref_to_clpi_file_name represents a 5-digit number excluding the extension “.m2ts” in the file name of the m2ts file that stores D1 view vide. . This description identifies the clpi file to be referenced.
  • ref_to_clpi_file_name on the 13th line excludes the extension of “.m2ts” from the file name of the m2ts file storing D2 view vide when this SubPath is to play D2 view video. Represents a 5-digit number.
  • Lines 16 to 30 describe interleaved_file_info (), that is, a description related to the ilvt file.
  • interleaved_file_info a description related to the ilvt file.
  • a description about the ilvt file is prepared using reserved_for_future_use in PlayItem () and SubPath ().
  • Lines 17 to 22 are descriptions to be referred to when the value of type in line 6 is 1, and Base1view video, D1 view video, and D2 view video are all interleaved.
  • Ref_to_D1-B_interleaved_file_name on line 18 represents a 5-digit number excluding the extension of “.ilvt” in the file names of the ilvt files for playback of Base view video and D1 view video.
  • Ref_to_D2-B_interleaved_file_name on the 19th line represents a 5-digit number excluding the extension “.ilvt” in the file names of the ilvt files for playback of Base view video and D2 view video.
  • Ref_to_D1_clpi_file_name on the 20th line represents a 5-digit number excluding the extension “.m2ts” in the file name of the m2ts file storing D1 view vide.
  • the clpi file to be referred to when the m2ts file of D1 view vide is reproduced is specified.
  • Ref_to_D2_clpi_file_name on the 21st line represents a 5-digit number excluding the extension “.m2ts” in the file name of the m2ts file storing D2 view vide.
  • the clpi file to be referred to when the D2tsview vide m2ts file is played back is specified.
  • the 23rd to 26th lines are descriptions to be referred to when the type value of the 6th line is 2 and Base view video and D1 view video are interleaved.
  • Ref_to_D1-B_interleaved_file_name on the 24th line represents a 5-digit number excluding the extension “.ilvt” in the file names of the ilvt files for playback of Base view video and D1 view video.
  • Ref_to_D1_clpi_file_name on line 25 represents a 5-digit number excluding the extension of “.m2ts” in the file name of the m2ts file storing D1 view vide.
  • the clpi file to be referred to when the m2ts file of D1 view vide is reproduced is specified.
  • Ref_to_D2-B_interleaved_file_name on line 28 represents a 5-digit number excluding the extension of “.ilvt” in the file names of the ilvt files for playback of Base view video and D2 view video.
  • Ref_to_D2_clpi_file_name on line 29 represents a 5-digit number excluding the extension of “.m2ts” in the file name of the m2ts file storing D2 view vide.
  • the clpi file to be referred to when the D2tsview vide m2ts file is played back is specified.
  • FIG. 20 is a block diagram illustrating a configuration example of the playback device 201.
  • the controller 251 executes a control program prepared in advance and controls the overall operation of the playback device 201.
  • the controller 251 controls the disk drive 252, and reads a PlayList file for 3D playback. Further, the controller 251 reads Main TS and SubTS based on the ID registered in the STN_table, and supplies them to the decoder unit 256.
  • the disk drive 252 reads data from the optical disk 202 according to the control by the controller 251 and outputs the read data to the controller 251, the memory 253, or the decoder unit 256.
  • the memory 253 appropriately stores data necessary for the controller 251 to execute various processes.
  • the local storage 254 is composed of, for example, an HDD (Hard Disk Drive).
  • a D1 / D2 view video stream downloaded from the server 272 is recorded.
  • a stream recorded in the local storage 254 is also supplied to the decoder unit 256 as appropriate.
  • the Internet interface 255 communicates with the server 272 via the network 271 according to the control from the controller 251, and supplies the data downloaded from the server 272 to the local storage 254.
  • the decoder unit 256 decodes the stream supplied from the disk drive 252 or the local storage 254 and outputs the obtained video signal to the display device 203.
  • An audio signal is also output to the display device 203 via a predetermined path.
  • the operation input unit 257 includes an input device such as a button, a key, a touch panel, a jog dial, and a mouse, and a receiving unit that receives a signal such as an infrared ray transmitted from a predetermined remote commander.
  • the operation input unit 257 detects a user operation and supplies a signal representing the content of the detected operation to the controller 251.
  • FIG. 21 is a diagram illustrating a configuration example of the decoder unit 256.
  • the separation unit 281 separates the data supplied from the disk drive 252 into packet data constituting the Main TS and packet data constituting the Sub TS according to control by the controller 251. For example, the TS read from the optical disc 202 based on the stream ID described in STN_table () of the 3D PlayList file is supplied to the separation unit 281.
  • the separating unit 281 outputs and stores the packet constituting the separated Main TS to the read buffer 282 and outputs the packet constituting the Sub TS to the read buffer 285 for storage.
  • the separation unit 281 outputs and stores the packets constituting the Sub-TS supplied from the local storage 254 to the read buffer 285.
  • the D1 / D2 view vide downloaded from the server 272 may be stored in the local storage 254.
  • a D1 / D2 view vide stream as Sub TS is read from the local storage 254 and supplied to the separation unit 281.
  • the PID filter 283 distributes the packets that make up the Main TS stored in the read buffer 282 based on the PID set in each packet.
  • the controller 251 designates the PID of the packet constituting Base view video, the PID of the packet constituting D1 view video, and the PID of the packet constituting D2 view video.
  • the PID filter 283 reads the Base video video packet included in the Main TS from the read buffer 282, and outputs the packet to the ES buffer 284 for storage.
  • the ES buffer 284 stores an ES (Elementary Stream) composed of Base-view video packets.
  • the PID filter 283 extracts those packets based on the PID and outputs them to the switch 287.
  • the PID filter 286 reads the D1 / D2 vide packet contained in the Sub TS from the read buffer 285 and outputs it to the switch 287.
  • graphics data such as PG and IG is included in Main TS. May be multiplexed.
  • subtitle data and graphic data may be multiplexed in Sub TS.
  • the PID filter 283 and the PID filter 286 appropriately distribute the data based on the PID and output the data to a predetermined output destination.
  • a decoder or the like for decoding graphic data is connected to the output destination terminals (circles) shown in the blocks of the PID filter 283 and the PID filter 286 in FIG.
  • the switch 287 outputs the D1 / D2 view vide packet supplied from the PID filter 283 to the ES buffer 288 for storage. Further, the switch 287 outputs the D1 / D2 view vide packet supplied from the PID filter 286 to the ES buffer 288 for storage.
  • the ES buffer 288 stores an ES composed of D1 / D2 view video packets.
  • the switch 289 outputs, to the decoder 290, a packet to be decoded among the Base view video packet stored in the ES buffer 284 and the D1 / D2 view video packet stored in the ES buffer 288.
  • Time information such as DTS (Decoding Time Stamp) is set in the PES packets of Base view video and D1 / D2 view video, and reading from the buffer is performed based on the time information.
  • the video decoder 290 decodes the packet supplied from the switch 289, and outputs the data of Base view video or D1 / D2 view ⁇ video obtained by decoding.
  • FIG. 22 is a diagram illustrating an example of 3D_PlayList.
  • the 3D_PlayList described in the PlayList file of “00000.mpls” in FIG. 22 is a PlayList that manages the playback of the optical disc 202 in which Base view video, D1 view video, and D2 view video are all interleaved. That is, the value of type is 1.
  • the ref_to_B_clpi_file_name of PlayItem () is “00001”. From this description, when reproducing “00001.m2ts”, which is an m2ts file of Base view video, it is specified that the clpi file of “00001.clpi” in FIG. 10 is referred to.
  • SubPath_type of SubPath () [1] is “9”.
  • the SubPath_type of “9” indicates that the first SubPath is a sub path for reproducing D2 view video.
  • Ref_to_clpi_file_name of SubPath () [1] is “00002”. From this description, when reproducing D2 ⁇ view video, it is specified to refer to the clpi file of “00002.clpi” in FIG.
  • SubSub_type of SubPath () [2] is “8”.
  • the SubPath_type of “8” indicates that the second SubPath is a sub path for reproducing D1 view video.
  • Ref_to_clpi_file_name of SubPath () [2] is “00003”. From this description, when reproducing D1 ⁇ view video, it is specified to refer to the clpi file of “00003.clpi” in FIG.
  • Ref_to_D1-B_interleaved_file_name of interleaved_file_info () is “10000”. From this description, it is specified to refer to the “10000.ilvt” ilvt file in FIG. 10 when performing D1-B playback.
  • Ref_to_D2-B_interleaved_file_name is “20000”. From this description, when performing D2-B playback, it is specified that the “20000.ilvt” ilvt file in FIG. 10 is referred to.
  • Ref_to_D1_clpi_file_name is “00003”. From this description, when reproducing D1 ⁇ view0000video, it is specified that the file "00003.clpi" in FIG. 10 is referred to.
  • Ref_to_D2_clpi_file_name is “00002”. From this description, when reproducing D2Dview0000video, it is specified that the file "00002.clpi" in FIG. 10 is referred to.
  • FIG. 23 is a diagram illustrating the syntax of the clpi file used together with the 3D_PlayList of FIG.
  • FIG. 23A shows an example of a clpi file “00001.clpi”.
  • the “00001.clpi” clpi file is a file that is referred to when “00001.m2ts”, which is an m2ts file of Base view video, is reproduced.
  • Numberer_of_source_packets1 represents the number of source packets included in the m0000 file of “00001.m2ts”.
  • EP_map represents the location information of the entry point (EP) in the TS included in the m2ts file of “00001.m2ts”.
  • Chunk_map represents the Source Packet Number (SPN) indicating the start position of each chunk in order from the first chunk for the TS contained in the m0000s file of "00001.m2ts".
  • SPN Source Packet Number
  • a chunk is a collection of source packets that belong to one TS and are continuously arranged on the optical disc 202.
  • a description will be given assuming that one chunk corresponds to one extent arranged on the optical disc 202.
  • Chunk_map () represents the length of each chunk. A specific example of chunk_map () will be described later.
  • FIG. 23B shows an example of a clpi file “00002.clpi”.
  • the “00002.clpi” clpi file is a file to be referred to when reproducing D2 view video.
  • FIG. 23C shows an example of a clpi file “00003.clpi”.
  • the “00003.clpi” clpi file is a file to be referred to when reproducing D1 view video.
  • the description contents of B in FIG. 23 and C in FIG. 23 are the same as those shown in A of FIG.
  • FIG. 24 is a diagram showing the concept of file management performed using the data shown in FIGS.
  • file management is performed in the form of a three-layer structure of a physical layer, a file system layer, and an application layer.
  • the 3D_PlayList in FIG. 22 and the clpi file in FIG. 23 become application layer information.
  • the physical layer is a layer of the optical disc 202 in which the Base video, D1 ⁇ view video, and D2 view video are all recorded in an interleaved state.
  • the D124view24video chunk, the D2 view video chunk, and the Base view video chunk are arranged in that order.
  • a block with the letter “B” represents a chunk of Base view video
  • a block with the letter “D1” represents a chunk of D1 view video
  • a block with the letter “D2” represents a chunk of D2 view video.
  • Interleaved arrangement means a periodic arrangement in which extents of the same type of stream are not adjacent.
  • the stream file (m2ts file, ilvt file) designated by the application by the file name is associated with each chunk on the optical disc 202.
  • the file system is, for example, UDF file system.
  • the m2ts file of “00001.m2ts” is composed of Base video chunks arranged on the optical disc 202.
  • the “00002.m2ts” m2ts file is composed of D2Dview video chunks arranged on the optical disc 202.
  • the m2ts file of “00003.m2ts” is composed of chunks of D1 view video arranged on the optical disc 202.
  • the file “20000.ilvt” is composed of a D2 view video chunk and a Base view video chunk arranged on the optical disc 202.
  • the file “10000.ilvt” is composed of a chunk of D1 view video and a chunk of Base view video arranged on the optical disc 202.
  • the chunk of Base view video is read according to the management by the file system.
  • D2 view video chunk and Base view video chunk are read according to management by the file system.
  • step S1 the controller 251 confirms from the type value that all of Base view video, D1 view video, and D2 view video are interleaved.
  • step S2 the controller 251 goes to read interleaved_file_info ().
  • step S3 the controller 251 determines whether or not B-D1 playback has been instructed based on an operation by the user.
  • step S4 the controller 251 designates “10000.ilvt” (ref_to_D1-B_interleaved_file_name) described in interleaved_file_info (), The view video chunk and the D1 view video chunk are read from the optical disc 202.
  • the Base video chunk and D1 video chunk read by the disk drive 252 are supplied to the separation unit 281 of the decoder unit 256.
  • step S5 the separation unit 281 supplies the supplied data based on chunk_map () of “00001.clpi” (ref_to_B_clpi_file_name) and chunk_map () of “00003.clpi” (ref to D1_clpi_file_name) of FIG.
  • the data is separated into m2ts file data of "00001.m2ts” and m2ts file data of "00003.m2ts”.
  • the separation unit 281 outputs the data of the “00001.m2ts” m2ts file to the read buffer 282, and outputs the data of the “00003.m2ts” m2ts file to the read buffer 285. Data separation performed using chunk_map () will be described later.
  • the data of the “00001.m2ts” m2ts file stored in the read buffer 282 is supplied to the decoder 290 via the PID filter 283, the ES buffer 284, and the switch 289.
  • the data of the “00003.m2ts” m2ts file stored in the read buffer 285 is supplied to the decoder 290 via the PID filter 286, the switch 287, the ES buffer 288, and the switch 289.
  • step S6 the decoder 290 decodes (reproduces) the packets sequentially supplied from the switch 289.
  • step S7 the controller 251 determines “20000.ilvt” (described in interleaved_file_info ()). ref_to_D2-B_interleaved_file_name) is specified, and the chunk of Base view video and chunk of D2 view video are read from the optical disc 202 through UDF file system.
  • step S8 the separation unit 281 uses the “00001.clpi” (ref_to_B_clpi_file_name) chunk_map () and the “00002.clpi” (ref to D2_clpi_file_name) chunk_map () to supply the supplied data to “00001.clpi”.
  • the data is divided into m2ts file data of “m2ts” and m2ts file data of “00002.m2ts”.
  • the separation unit 281 outputs the data of the “00001.m2ts” m2ts file to the read buffer 282, and outputs the data of the “00002.m2ts” m2ts file to the read buffer 285.
  • the data of the “00001.m2ts” m2ts file and the data of the “00002.m2ts” m2ts file are supplied to the decoder 290 in the same manner as in the B-D1 reproduction, and are reproduced in step S6.
  • FIG. 26 is a diagram illustrating an example of the syntax of chunk_map ().
  • Numberer_of_chunks indicates the number of chunks to be referenced. After number_of_chunks, the number of chunk information described here is described.
  • SPN_chunk_start [i] represents, for example, the SPN (length) from the reference position to the start position of each chunk with reference to the start position of the first chunk.
  • the SPN up to the start position of each chunk is described in order from the first chunk.
  • FIG. 27 is a diagram showing a specific example of chunk_map ().
  • a in FIG. 27 is chunk_map () described in the clpi file “00001.clpi”, and number_of_chunks is (n + 1).
  • SPN_chunk_start [i] is 0, c1, c2, ..., cn.
  • the first value 0, as shown in C of FIG. 28, is based on the start position of the first chunk of Base view video included in the “00001.m2ts” m2ts file, and is the first value from the reference position. Indicates that the SPN up to the start position of the chunk (B [0]) is 0.
  • the second value c1 represents that the SPN from the reference position to the start position of the second chunk (B [1]) is c1.
  • the third value c2 indicates that the SPN from the reference position to the start position of the third chunk (B [2]) is c2.
  • the n + 1 th value cn represents that the SPN from the reference position to the start position of the n + 1 th chunk (B [n]) which is the last chunk is cn.
  • SPN_chunk_start [i] is 0, b1, b2, ..., bn.
  • the first value 0 is based on the start position of the first chunk of D2 view video included in the “00002.m2ts” m2ts file. Indicates that the SPN up to the start position of the chunk (D2 [0]) is 0.
  • the second value b1 represents that the SPN from the reference position to the start position of the second chunk (D2 [1]) is b1.
  • the third value b2 represents that the SPN from the reference position to the start position of the third chunk (D2 [2]) is b2.
  • the n + 1th value bn represents that the SPN from the reference position to the start position of the n + 1th chunk (D2 [n]) which is the last chunk is bn.
  • C in FIG. 27 is chunk_map () described in the clpi file “00003.clpi”, and number_of_chunks is (n + 1).
  • SPN_chunk_start [i] is 0, a1, a2, ..., an.
  • the first value 0, as shown in A of FIG. 28, is based on the start position of the first chunk of D1 view video contained in the m2ts file of “00003.m2ts”. Indicates that the SPN up to the start position of the chunk (D1 [0]) is 0.
  • the second value a1 indicates that the SPN from the reference position to the start position of the second chunk (D1 [1]) is a1.
  • the third value a2 represents that the SPN from the reference position to the start position of the third chunk (D1 [2]) is a2.
  • the n + 1-th value an indicates that the SPN from the reference position to the start position of the n + 1-th chunk (D1 [n]) which is the last chunk is an.
  • D1 [i], D2 [i], and B [i] are periodically arranged on the optical disc 202 in that order as shown in D of FIG.
  • the separation unit 281 determines the SPN corresponding to a1 from the top of the supplied data based on the description of the three chunk_map () in FIG. Are separated as D1 [0].
  • the separation unit 281 separates SPN data corresponding to b1 from the end position of D1 [0] as D2 [0], and SPN data corresponding to c1 from the end position of D2 [0]. Are separated as B [0].
  • the separation unit 281 separates SPN data corresponding to a2-a1 from the end position of B [0] as D1 [1].
  • Separating section 281 separates SPN data corresponding to b2-b1 from the end position of D1 [1] as D2 [1], and SPN parts corresponding to c2-c1 from the end position of D2 [1]. Are separated as B [1].
  • the chunks to be separated are only D1 [i] and B [i] when performing B-D1 playback, and D2 [i] and B [i] when performing B-D2 playback. Only.
  • the separation of data by the separation unit 281 is performed using information on the length of each chunk described in chunk_map ().
  • chunk_map () is optional for clpi files referenced by ref_to_B_clpi_file_name (may be omitted). If there is a chunk_map (), the player must ignore the chunk_map ().
  • chunk_map () is optional for clpi files corresponding to m2ts files on local storage 254 (it may not be present). If there is a chunk_map (), the player must ignore the chunk_map ().
  • the three TSs of the corresponding Base video TS, D1 view video TS, and D2 view video TS are each divided into the same number (n + 1) chunks. That is, for D1 [i], D2 [i], and B [i] in FIG. 28, chunks having the same subscript i value are divided so as to have the same reproduction time.
  • the corresponding TS of Base view video and D1 view video TS are each divided into the same number (n + 1) chunks. That is, for D1 [i] and B [i] to be interleaved, chunks having the same subscript i value are divided so as to have the same reproduction time.
  • the corresponding TS of Base ⁇ ⁇ view video and D2 view video TS are each divided into the same number (n + 1) chunks. That is, for D2 [i] and B [i] to be interleaved, chunks having the same subscript i value are divided so as to have the same reproduction time.
  • FIG. 29 is a diagram illustrating another example of the 3D_PlayList.
  • the 3D_PlayList described in the PlayList file of “0000.mpls” in FIG. 29 is a PlayList that manages the playback of the optical disc 202 on which Base view video and D2 view video are interleaved. That is, the value of type is 3.
  • 3D_PlayList in FIG. 29 is the same as the description of FIG. 22 except that the description of SubPath is only the description of SubPath referring to D2 view video and the description of interleaved_file_info () is different.
  • SubPath_type of SubPath () is “9”.
  • the SubPath_type of “9” indicates that this SubPath is a sub path for reproducing D2 view video.
  • Ref_to_clpi_file_name is “00002”.
  • Ref_to_D2-B_interleaved_file_name of interleaved_file_info () in FIG. 29 is “20000”. From this description, it is specified to refer to the ilvt file “20000.ilvt” in FIG. 10 when performing D2-B playback.
  • Ref_to_D2_clpi_file_name is “00002”. From this description, when reproducing D2 ⁇ view video, it is specified to refer to the clpi file of “00002.clpi” in FIG.
  • FIG. 30 is a diagram showing the syntax of the clpi file used together with the 3D_PlayList of FIG.
  • FIG. 30A is a diagram illustrating an example of a clpi file of “00001.clpi”
  • FIG. 30B is a diagram illustrating an example of a clpi file of “00002.clpi”.
  • Each clpi file includes the description of EP_map and the above-described chunk_map ().
  • FIG. 31 is a diagram showing the concept of file management performed using the data shown in FIGS.
  • the physical layer is a layer of the optical disc 202 in which Base video and D2 video are recorded in an interleaved state.
  • the m2ts file of “00001.m2ts” is composed of Base view video chunks arranged on the optical disc 202.
  • the “00002.m2ts” m2ts file is composed of D2Dview video chunks arranged on the optical disc 202.
  • the “10000.ilvt” ilvt file is composed of a chunk of D2 view video and a chunk of Base view video arranged on the optical disc 202.
  • the chunk of Base view video is read according to the management by the file system.
  • step S11 the controller 251 confirms from the value of type that Base view video and D2 view video are interleaved.
  • step S12 the controller 251 goes to read interleaved_file_info ().
  • step S13 the controller 251 designates “20000.ilvt” (ref_to_D2-B_interleaved_file_name) described in interleaved_file_info (), and through the UDF file system, The D2 view video chunk is read from the optical disc 202.
  • the Base video chunk and D2 video chunk read by the disk drive 252 are supplied to the separation unit 281 of the decoder unit 256.
  • step S14 the separation unit 281 uses the “00001.clpi” (ref_to_B_clpi_file_name) chunk_map () and the “00002.clpi” (ref to D2_clpi_file_name) chunk_map () to supply the supplied data to “00001.clpi”.
  • the data is divided into m2ts file data of “m2ts” and m2ts file data of “00002.m2ts”.
  • the separation unit 281 outputs the data of the “00001.m2ts” m2ts file to the read buffer 282, and outputs the data of the “00002.m2ts” m2ts file to the read buffer 285.
  • the data of the “00001.m2ts” m2ts file stored in the read buffer 282 is supplied to the decoder 290 via the PID filter 283, the ES buffer 284, and the switch 289.
  • the data of the “00002.m2ts” m2ts file stored in the read buffer 285 is supplied to the decoder 290 via the PID filter 286, the switch 287, the ES buffer 288, and the switch 289.
  • step S15 the decoder 290 decodes the packets sequentially supplied from the switch 289.
  • FIG. 33 is a diagram illustrating yet another example of 3D_PlayList.
  • the 3D_PlayList described in the “00000.mpls” PlayList file in FIG. 33 manages the playback of Base view video and D2 view video recorded on the optical disc 202 and D1 view video recorded in the local storage 254. PlayList to be. On the optical disc 202, Base view video and D2 view video are interleaved.
  • SubSub_type of SubPath () [1] is “9”.
  • the SubPath_type of “9” indicates that the first SubPath is a sub path for reproducing D2 view video.
  • Ref_to_clpi_file_name of SubPath () [1] is “00002”. From this description, when reproducing D2 ⁇ view video, it is specified to refer to the clpi file of “00002.clpi” in FIG.
  • SubSub_type of SubPath () [2] is “8”.
  • the SubPath_type of “8” indicates that the second SubPath is a sub path for reproducing D1 view video.
  • Ref_to_clpi_file_name of SubPath () [2] is “00003”. From this description, when reproducing D1 view video, it is specified to refer to the clpi file “00003.clpi” recorded in the local storage 254.
  • Ref_to_D2-B_interleaved_file_name of interleaved_file_info () is “20000”. From this description, when performing B-D2 playback, it is specified to refer to the ilvt file of “20000.ilvt” in FIG.
  • Ref_to_D2_clpi_file_name is “00002”. From this description, when reproducing D2Dview0000video, it is specified that the file "00002.clpi" in FIG. 10 is referred to.
  • the ilvt file related to the D1 view video is not necessary.
  • FIG. 34 is a diagram showing the syntax of the clpi file used together with the 3D_PlayList of FIG.
  • FIG. 34A is a diagram illustrating an example of a clpi file “00001.clpi”
  • FIG. 34B is a diagram illustrating an example of a clpi file “00002.clpi”. Both clpi files contain descriptions of EP_map and chunk_map ().
  • FIG. 35 is a diagram showing the concept of file management performed using the data shown in FIGS.
  • the physical layer includes an optical disc 202 in which Base ⁇ view video and D2 view video are interleaved, and a local D1 view video file referenced by the second SubPath. It becomes a layer of the storage 254.
  • the file name of the m2ts file storing D1 view video is “00003.m2ts”.
  • the file name of the clpi file corresponding to “00003.m2ts” is “00003.clpi”.
  • the m2ts file of “00001.m2ts” is composed of Base view video chunks arranged on the optical disc 202.
  • the “00002.m2ts” m2ts file is composed of D2Dview video chunks arranged on the optical disc 202.
  • the “10000.ilvt” ilvt file is composed of a chunk of D2 view video and a chunk of Base view video arranged on the optical disc 202.
  • the chunk of Base view video is read according to the management by the file system.
  • step S21 the controller 251 confirms from the type value that Base view video and D2 view video are interleaved.
  • step S22 the controller 251 goes to read interleaved_file_info ().
  • step S23 the controller 251 determines whether or not B-D1 playback is instructed.
  • step S24 the controller 251 determines “20000.ilvt” (ref_to_D2-) described in interleaved_file_info ().
  • the name X “00002” of the clip including D2 view ⁇ video that constitutes (B_interleaved_file_name) is extracted (the part of the name of the m2ts file including D2 view video excluding the extension).
  • step S26 the controller 251 recognizes that D2 view video is included in “20000.ilvt” because Y is the same as X.
  • the Clip including D2 view video is on the local storage 254.
  • step S27 the controller 251 designates “20000.ilvt” (ref_to_D2-B_interleaved_file_name) described in interleaved_file_info (), and reads the Base view video chunk and the D2 view video chunk from the optical disc 202 through the UDF file system. Let it come out.
  • the Base video chunk and D2 video chunk read by the disk drive 252 are supplied to the separation unit 281 of the decoder unit 256.
  • step S28 the separation unit 281 determines the supplied data based on the chunk_map () of “00001.clpi” (ref_to_B_clpi_file_name) and the chunk_map () of “00002.clpi” (ref to D2_clpi_file_name) as “00001.clpi”.
  • the data is divided into m2ts file data of “m2ts” and m2ts file data of “00002.m2ts”.
  • the separation unit 281 outputs the data of the “00001.m2ts” m2ts file to the read buffer 282, and outputs the data of the “00002.m2ts” m2ts file to the read buffer 285.
  • the data of the “00001.m2ts” m2ts file stored in the read buffer 282 is supplied to the decoder 290 via the PID filter 283, the ES buffer 284, and the switch 289.
  • the data of the “00002.m2ts” m2ts file stored in the read buffer 285 is supplied to the decoder 290 via the PID filter 286, the switch 287, the ES buffer 288, and the switch 289.
  • step S29 the decoder 290 decodes the packets sequentially supplied from the switch 289.
  • step S30 the controller 251 includes D2 view video that constitutes “20000.ilvt” (ref_to_D2-B_interleaved_file_name) described in interleaved_file_info (). Extract the Clip name X “00002”.
  • step S32 the controller 251 determines that the clip of D1 view video is on the local storage 254 because Y is different from the portion excluding the extension of “00001.clpi” (ref_to_B_clpi_file_name) and Y is different from X. Recognize that Here, when Y is the same as the part excluding the extension of “00001.clpi”, or when Y is the same as X, D1 view video is included in “20000.ilvt” Become.
  • step S33 the controller 251 causes the disk drive 252 to read the m2ts file “00001.m2ts” using the EP_map “00001.clpi” (ref_to_B_clpi_file_name).
  • the EP_map of “00001.clpi” includes entry point information that is the decoding start position of the m2ts file of “00001.m2ts”.
  • step S34 the controller 251 reads the m2ts file of “00003.m2ts” from the local storage 254 using the EP_map of “00003.clpi” (file referred to by SubPath () [2]).
  • the EP_map of “00003.clpi” includes information on the entry point that is the decoding start position of the m2ts file of “00003.m2ts”.
  • the read Base view video chunk and D1 view video chunk are supplied to the separation unit 281 of the decoder unit 256.
  • the data of the “00001.m2ts” m2ts file read from the optical disc 202 is stored in the read buffer 282 and then supplied to the decoder 290 via the PID filter 283, ES buffer 284, and switch 289.
  • the data of the “00003.m2ts” m2ts file read from the local storage 254 is stored in the read buffer 285, and then stored in the decoder 290 via the PID filter 286, the switch 287, the ES buffer 288, and the switch 289. Supplied.
  • step S29 the decoder 290 decodes the packets sequentially supplied from the switch 289.
  • FIG. 37 is a diagram collectively showing the contents of chunk_map () described with reference to FIG.
  • FIG. 38 is a diagram showing the syntax of EP_map () described in each clpi file together with chunk_map ().
  • EP_map () is referred to specify the decoding start position when performing random access.
  • Numberer_of_EP_entries represents the number of EPs (entry points).
  • PTS_EP_start [i] represents the PTS of the EP
  • SPN_EP_start [i] represents the SPN of the EP.
  • step S41 the controller 251 confirms from the value of type that Base view video, D1 view video, and D2 view video are all interleaved.
  • step S42 the controller 251 goes to read interleaved_file_info ().
  • step S43 the controller 251 determines that “10000.ilvt” (ref_to_D1-B_interleaved_file_name) described in the interleaved_file_info () is a read file.
  • step S44 the controller 251 uses the EP_map of “00001.clpi” (ref_to_B_clpi_file_name) to have PTS_EP_start having the closest value smaller than x Find [m].
  • step S45 the controller 251 extracts SPN_EP_start [m] corresponding to PTS_EP_start [m]. As described with reference to FIG. 38, PTS_EP_start [i] and SPN_EP_start [i] are associated and registered in the EP_map.
  • FIG. 40 is a diagram illustrating an example of positions specified by the processes in steps S44 and S45.
  • step S44 when playback is started from time x on the time axis, PTS_EP_start [m] having a closest value smaller than x is specified in step S44. Also, SPN_EP_start [m] corresponding to PTS_EP_start [m] is specified in step S45.
  • step S46 the controller 251 finds SPN_chunk_start [k] having a closest value smaller than SPN_EP_start [m] by using a chunk_map of “00001.clpi”.
  • FIG. 41 shows SPN_chunk_start [k] specified by the process of step S46.
  • step S47 the controller 251 adds the sum of SPN_chunk_start [k] of chunk_map () of “00001.clpi” and SPN_chunk_start [k] of chunk_map () of “00003.clpi” (refpito D1_clpi_file_name) to “10000”. Determined as the read start address of “.ilvt”.
  • the read start address of “10000.ilvt” determined here indicates the start address of the chunk of D1 [k] in “10000.ilvt”.
  • step S48 the controller 251 designates “10000.ilvt” (ref_to_D1-B_interleaved_file_name), and reads the chunk of Base view video and the chunk of D1 view video through the UDF file system from the address determined in step S47. .
  • the read Base view video chunk and D1 view video chunk are supplied to the separation unit 281 of the decoder unit 256.
  • step S49 the separation unit 281 sets the supplied data to “00001.clpi” (ref_to_B_clpi_file_name) chunk_map () and “00003.clpi” (ref topiD1_clpi_file_name) chunk_map ().
  • the data is divided into m2ts file data of “m2ts” and m2ts file data of “00003.m2ts”.
  • the separation unit 281 outputs the data of the “00001.m2ts” m2ts file to the read buffer 282, and outputs the data of the “00003.m2ts” m2ts file to the read buffer 285.
  • the data of the “00001.m2ts” m2ts file stored in the read buffer 282 is supplied to the decoder 290 via the PID filter 283, the ES buffer 284, and the switch 289.
  • the data of the “00003.m2ts” m2ts file stored in the read buffer 285 is supplied to the decoder 290 via the PID filter 286, the switch 287, the ES buffer 288, and the switch 289.
  • step S50 the decoder 290 decodes the packets sequentially supplied from the switch 289.
  • EP_map of Base view video will be described, EP_map is set in the same way for D1 / D2 view video. For example, when an entry point is set for a picture with Base view video, an entry point is also set for the corresponding picture of D1 / D2 view video.
  • the Base view video picture and D1 / D2 view video picture at the same position are the corresponding pictures.
  • FIG. 42 is a diagram showing the structure of an AV stream recorded on the optical disc 202. As shown in FIG.
  • the TS including the Baseview video stream is composed of an integer number of aligned units (Aligned Unit) having a size of 6144 bytes.
  • the Allied unit consists of 32 source packets.
  • the source packet has 192 bytes.
  • One source packet is composed of a 4-byte transport packet extra header (TP_extra header) and a 188-byte transport packet (Transport Packet).
  • the data of Base view video is packetized into MPEG2 PES packets.
  • a PES packet header is added to the data portion of the PES packet to form a PES packet.
  • the PES packet header includes a stream ID that identifies the type of elementary stream transmitted by the PES packet.
  • PES packets are further packetized into transport packets. That is, the PES packet is divided into the payload size of the transport packet, and a transport packet header is added to the payload to form a transport packet.
  • the transport packet header includes a PID that is identification information of data stored in the payload.
  • the source packet is given a source packet number that is incremented by 1 for each source packet, with the beginning of the Clip AV stream being 0, for example.
  • the Allied unit starts from the first byte of the source packet.
  • EP_map is used to search for a data address to start reading data in the Clip AV stream file when the time stamp of the Clip access point is given.
  • EP_map is a list of entry points extracted from the elementary stream and the transport stream.
  • EP_map has address information for searching for an entry point to start decoding in the AV stream.
  • One EP data in the EP_map is composed of a pair of a PTS and an address in the AV stream of the Access Unit corresponding to the PTS.
  • data for one picture is stored in 1 Access Unite.
  • FIG. 43 is a diagram showing an example of a Clip AV stream.
  • the video stream is distinguished for each source packet by the PID included in the header of the transport packet in the source packet.
  • a source packet including the first byte of an IDR (InstantaneousDecodingDefresh) picture among the source packets of the video stream is colored.
  • a square without a color indicates a source packet including data that does not become a random access point or a source packet including data of another stream.
  • the IDR picture is an I picture and is first decoded in the GOP including the IDR picture.
  • all the information related to decoding such as the state of the reference picture buffer, the frame number managed until then, and POC (Picture) Order ⁇ ⁇ Count) are reset.
  • FIG. 44 is a diagram conceptually showing an example of EP_map corresponding to the Clip AV stream of FIG.
  • EP_map is composed of stream_PID, PTS_EP_start, and SPN_EP_start.
  • Stream_PID represents the PID of the transport packet that transmits the video stream.
  • ⁇ PTS_EP_start represents the Access Unite PTS starting from a randomly accessible IDR picture.
  • SPN_EP_start represents the address of the source packet including the first byte of Access Unite referenced by the value of PTS_EP_start.
  • the PID of the video stream is stored in stream_PID, and EP_map_for_one_stream_PID (), which is table information indicating the correspondence between PTS_EP_start and SPN_EP_start, is generated.
  • Such a table is also generated for each video stream multiplexed in the same Clip AV stream.
  • the EP_map including the generated table is stored in the Clip Information file corresponding to the Clip AV stream.
  • FIG. 45 is a diagram showing an example of the data structure of the source packet pointed to by SPN_EP_start.
  • the source packet is configured by adding a 4-byte header to a 188-byte transport packet.
  • the transport packet part includes a header part (TP header) and a payload part.
  • SPN_EP_start represents the source packet number of the source packet including the first byte of Access Unite starting from the IDR picture.
  • Access Unit that is, picture starts from AU delimiter (Access Unit Delimiter).
  • the AU delimiter is followed by SRS and PPS. Thereafter, the head portion or the whole of the slice data of the IDR picture is stored.
  • payload_unit_start_indicator in the TP header of the transport packet being 1 indicates that a new PES packet starts from the payload of this transport packet. Access Unite is started from this source packet.
  • Such EP_map is prepared for each of the Base view video stream and the Dependent view video stream.
  • FIG. 46 is a block diagram illustrating a configuration example of the software production processing unit 301.
  • the video encoder 311 has the same configuration as the MVC encoder 211 of FIG.
  • the video encoder 311 generates a Base ⁇ view ⁇ video stream and a Dependent view video stream by encoding a plurality of video data with H.264 AVC / MVC, and outputs them to the buffer 312.
  • the audio encoder 313 encodes the input audio stream and outputs the obtained data to the buffer 314.
  • An audio stream to be recorded on the disc is input to the audio encoder 313 together with the Base view video and Dependent view video streams.
  • the data encoder 315 encodes the above-described various data other than video and audio, such as a PlayList file, and outputs the data obtained by the encoding to the buffer 316.
  • the data encoder 315 displays a type (FIG. 18) indicating whether the data of the Base view video stream and the data of the D1 / D2 view video stream are recorded on the optical disc in an interleaved state in units of extents (FIG. 18). Set to.
  • the data encoder 315 sets the above-described ilvt file as the PlayList file when the data of the Base view video stream and the data of the D1 / D2 view video stream are recorded on the optical disc in an interleaved state.
  • the ilvt file functions as a virtual file that virtually manages the Base view video stream data and the D1 / D2 view video stream data.
  • the data encoder 315 sets the file name of each Clip Information file of each Clip to a PlayList file, or sets EP_map and chunk_map to each Clip Information file.
  • the multiplexing unit 317 multiplexes video data, audio data, and data other than the stream stored in each buffer together with a synchronization signal, and outputs the multiplexed data to the error correction encoding unit 318.
  • the error correction encoding unit 318 adds an error correction code to the data multiplexed by the multiplexing unit 317.
  • the modulation unit 319 modulates the data supplied from the error correction coding unit 318 and outputs the modulated data.
  • the output of the modulation unit 319 becomes software recorded on the optical disc 202 that can be played back by the playback device 201.
  • a software production processing unit 301 having such a configuration is provided in the recording apparatus.
  • FIG. 47 is a diagram illustrating an example of a configuration including the software production processing unit 301.
  • the recording signal generated by the software production processing unit 301 is subjected to a mastering process in a premastering processing unit 331, and a signal having a format to be recorded on the optical disc 202 is generated.
  • the generated signal is supplied to the master recording unit 333.
  • a master made of glass or the like is prepared, and a recording material made of photoresist or the like is applied thereon. As a result, a recording master is produced.
  • the laser beam is modulated in response to the recording signal supplied from the premastering processing unit 331, and irradiated to the photoresist on the master. Thereby, the photoresist on the master is exposed in accordance with the recording signal. Thereafter, the master is developed and pits appear on the master.
  • the master is subjected to a process such as electroforming, and a metal master in which pits on the glass master are transferred is produced.
  • a metal stamper is further produced from this metal master, and this is used as a molding die.
  • a material such as PMMA (acrylic) or PC (polycarbonate) is injected into the molding die by injection or the like and fixed.
  • PMMA acrylic
  • PC polycarbonate
  • 2P ultraviolet curable resin
  • the pits on the metal stamper can be transferred onto the replica made of resin.
  • a reflective film is formed on the replica by vapor deposition or sputtering.
  • a reflective film is formed on the replica by spin coating.
  • the inner and outer diameters of the disk are processed, and necessary measures such as bonding two disks are performed. Further, after a label is attached or a hub is attached, it is inserted into the cartridge. In this way, the optical disk 202 on which data reproducible by the reproducing apparatus 201 is recorded is completed.
  • the series of processes described above can be executed by hardware or software.
  • a program constituting the software is installed in a computer incorporated in dedicated hardware or a general-purpose personal computer.
  • the program to be installed is provided by being recorded on a removable recording medium. Further, it may be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital broadcasting.
  • 201 playback device 202 optical disc, 203 display device, 211 MVC encoder, 221 H.264 / AVC encoder, 222 H.264 / AVC decoder, 223 Depth calculation unit, 224 Dependent video viewer, 225 multiplexer, 251 controller, 252 disc Drive, 253 memory, 254 local storage, 255 Internet interface, 256 decoder unit, 257 operation input unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

 本発明は、ステレオ画像(3D画像)のコンテンツを適切に再生することができる情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関する。 Base view videoとD1 view videoを使った3D再生が指示された場合、PlayListファイルのinterleaved_file_info()に記述された「10000.ilvt(ref_to_D1-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD1 view videoのチャンクが光ディスクから読み出される。読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部に供給され、再生される。本発明は、BD-ROM規格に対応した再生装置に適用することができる。

Description

情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム
 本発明は、情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関し、特に、記録媒体から、3D(Dimension)画像のコンテンツを適切に再生することができるようにした情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関する。
 例えば、映画等のコンテンツとしては、2次元(2D)画像のコンテンツが主流であるが、最近では、立体視が可能な3次元(3D)画像(グラフィック)のコンテンツが注目を集めている。
 3D画像(以下、ステレオ画像ともいう)の表示の方式としては、種々の方式があるが、いずれの方式を採用する場合であっても、3D画像のデータ量は、2D画像のデータ量よりも大になる。
 また、映画等の、高解像度の画像のコンテンツは、大容量であることもあり、そのような大容量の画像のコンテンツを、データ量の多い3D画像として記録するには、大容量の記録媒体が必要である。
 そのような大容量の記録媒体としては、例えば、BD(Blu-Ray(登録商標))-ROM(Read Only Memory)等のBlu-Ray(登録商標) Disc(以下、BDともいう)がある。
 ここで、フアイル化手段により信号の記録媒体における記録位置をセクタよりも小さい所定単位で指定してフアイル化するようにしたことにより、フアイル化した信号を任意の位置で分割又は結合するような編集処理でも、当該信号の編集対象部分のみをフアイル化するように記録媒体に記録しなおす必要がなく、フアイル管理情報上のみで編集処理することができ、かくして編集処理を格段的に簡易化させ得るフアイル管理装置が提案されている(特許文献1)。
特開平11-195287号公報
 ところで、現行のBDの規格では、3D画像のコンテンツを、BDに、どのように記録し、また、再生するかは、規定されていない。
 しかしながら、3D画像のコンテンツの記録や再生の仕方を、3D画像のコンテンツのオーサリングを行うオーサ(author)に委ねてしまうと、3D画像のコンテンツを適切に再生することができなくなるおそれがある。
 本発明は、このような状況に鑑みてなされたものであり、BD等の記録媒体から、ステレオ画像(3D画像)のコンテンツを適切に再生することができるようにするものである。
 本発明の第1の側面の再生装置は、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出す読み出し手段と、前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離する分離手段とを備える。
 前記チャンクは、前記記録媒体上に連続配置されるソースパケットの集まりであるようにすることができる。
 前記第1の情報ファイルが有する前記チャンクの数と、前記第2の情報ファイルが有する前記チャンクの数は、等しい数であるようにすることができる。
 前記第1の情報ファイルは、さらに、前記第1の多重化ストリームを構成するソースパケットの総数の情報を有し、前記第2の情報ファイルは、さらに、前記第2の多重化ストリームを構成するソースパケットの総数の情報を有するようにすることができる。
 前記第1の情報ファイルが有する前記チャンクの数を(n+1)とし、前記第1の多重化ストリームを構成するチャンクをB[i](i=0~n)、前記第1の多重化ストリームの先頭からk番目のチャンクをB[k]と表し、前記第2の多重化ストリームを構成するチャンクをD[i](i=0~n)、前記第2の多重化ストリームの先頭からk番目のチャンクをD[k]と表し、B[k]の開始パケット番号を、SPN_chunk_start_1[k]と表し、D[k]の開始パケット番号を、SPN_chunk_start_2[k]と表し、前記第1の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets1と表し、前記第2の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets2と表すとき、前記分離手段には、k=0~(n-1)について、B[k]を構成するソースパケットの数を、(SPN_chunk_start_1[k+1] - SPN_chunk_start_1[k])によって計算させ、k=0~(n-1)について、D[k]を構成するソースパケットの数を、(SPN_chunk_start_2[k+1] - SPN_chunk_start_2[k])によって計算させ、B[n]を構成するソースパケットの数を、(number_of_source_packets1 - SPN_chunk_start_1[n])によって計算させ、D[n]を構成するソースパケットの数を、(number_of_source_packets2 - SPN_chunk_start_2[n])によって計算させることができる。
 B[i]とD[i]について、iの値が同じ組のチャンクは同じ再生時間を有するようにすることができる。
 前記読み出し手段による読み出しを制御する制御手段をさらに設けることができる。この場合、前記制御手段には、前記第1の多重化ストリームの情報であり、前記第1の多重化ストリームの中のエントリーポイントの数と、各エントリーポイントについて、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]および位置を表すソースパケット番号であるSPN_EP_start[i]とを有する情報であるEP_mapを読み出させ、指定された再生開始時刻よりも小さく最も近い値を持つPTS_EP_start[m]を検出させ、PTS_EP_start[m]に対応するSPN_EP_start[m]を検出させ、SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start_1[k]とそのkを検出させ、SPN_chunk_start_1[k]とSPN_chunk_start_2[k]の和を、前記インターリーブドファイルの読み出し開始アドレスとして決定させることができる。
 前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamであるようにすることができる。
 本発明の第1の側面の再生方法は、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出し、前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離するステップを含む。
 本発明の第1の側面のプログラムは、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出し、前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離するステップを含む処理をコンピュータに実行させる。
 本発明の第2の側面の情報処理装置は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定する設定手段を備える。
 前記設定手段には、前記再生管理情報ファイルに、前記基本ストリームの再生区間であるクリップに関する情報を記述するクリップ情報ファイルの識別情報と、前記基本ストリームのクリップとともに三次元画像の再生に用いられる前記拡張ストリームのクリップに関する情報を記述する前記クリップ情報ファイルの識別情報とをさらに設定させることができる。
 前記設定手段には、前記基本ストリームの前記クリップ情報ファイルに、前記基本ストリームのエクステントに関する情報を設定し、前記拡張ストリームの前記クリップ情報ファイルに、前記拡張ストリームのエクステントに関する情報を設定させることができる。
 前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamであるようにすることができる。
 本発明の第2の側面の情報処理方法は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定するステップを含む。
 本発明の第2の側面のプログラムは、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定するステップを含む処理をコンピュータに実行させる。
 本発明の第3の側面の再生装置は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させる制御手段を備える。
 前記光ディスクから読み出された前記基本ストリームと前記拡張ストリームとを再生する再生手段をさらに設けることができる。
 前記基本ストリームの再生区間であるクリップに関する情報として、前記基本ストリームのエクステントに関する情報が記述されたクリップ情報ファイルの識別情報と、前記基本ストリームのクリップとともに三次元画像の再生に用いられる前記拡張ストリームのクリップに関する情報として、前記拡張ストリームのエクステントに関する情報が記述された前記クリップ情報ファイルの識別情報とが前記再生管理情報ファイルに設定されている場合、前記制御手段により読み出されたデータを、それぞれの前記クリップ情報ファイルに設定されている前記エクステントに関する情報に基づいて、前記基本ストリームのデータと前記拡張ストリームのデータに分離する分離手段をさらに設けることができる。
 前記エクステントに関する情報は、前記クリップに結び付けられたストリームファイルの中で、それぞれの前記エクステントが開始するソースパケットの番号であるようにすることができる。
 前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamであるようにすることができる。
 本発明の第3の側面の再生方法は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させるステップを含む。
 本発明の第3の側面のプログラムは、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させるステップを含む処理をコンピュータに実行させる。
 本発明の第4の側面の再生装置は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップのデータとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させる制御手段を備える。
 前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamであるようにすることができる。
 本発明の第4の側面の再生方法は、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップのデータとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させるステップを含む。
 本発明の第4の側面のプログラムは、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させるステップを含む処理をコンピュータに実行させる。
 本発明の第1の側面においては、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルが記録媒体から読み出され、前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルが読み出される。また、前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルが読み出され、前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離される。
 本発明の第2の側面においては、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が設定され、前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルが前記再生管理情報ファイルに設定される。
 本発明の第3の側面においては、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとが前記光ディスクから読み出される。
 本発明の第4の側面においては、複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルが参照され、前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータが前記光ディスクから読み出され、前記基本ストリームのクリップのデータとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータが読み出される。
 本発明によれば、ステレオ画像(3D画像)のコンテンツを適切に再生することができる。
本発明を適用した再生装置を含む再生システムの構成例を示す図である。 撮影の例を示す図である。 MVCエンコーダの構成例を示すブロック図である。 参照画像の例を示す図である。 TSの構成例を示す図である。 TSの他の構成例を示す図である。 TSのさらに他の構成例を示す図である。 AVストリームの管理の例を示す図である。 Main PathとSub Pathの構造を示す図である。 光ディスクに記録されるファイルの管理構造の例を示す図である。 PlayListファイルのシンタクスを示す図である。 図11のPlayList()のシンタクスを示す図である。 図12のSubPath()のシンタクスを示す図である。 図13のSubPlayItem(i)のシンタクスを示す図である。 図12のPlayItem()のシンタクスを示す図である。 図15のSTN_table()のシンタクスを示す図である。 3D_PlayListの具体例を示す図である。 typeの意味を示す図である。 SubPath_typeの意味を示す図である。 再生装置の構成例を示すブロック図である。 図20のデコーダ部の構成例を示す図である。 3D_PlayListの例を示す図である。 clpiファイルのシンタクスを示す図である。 図22、図23のデータを用いて行われるファイル管理の概念を示す図である。 図22の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 chunk_map()のシンタクスの例を示す図である。 chunk_map()の具体例を示す図である。 チャンクの分離について示す図である。 3D_PlayListの他の例を示す図である。 clpiファイルのシンタクスを示す図である。 図29、図30のデータを用いて行われるファイル管理の概念を示す図である。 図29の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 3D_PlayListのさらに他の例を示す図である。 clpiファイルのシンタクスを示す図である。 図33、図34のデータを用いて行われるファイル管理の概念を示す図である。 図33の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 図27のchunk_map()の内容をまとめて示す図である。 EP_map()のシンタクスを示す図である。 再生装置のランダムアクセス処理について説明するフローチャートである。 ステップS44,S45の処理により特定される位置の例を示す図である。 ステップS46の処理により特定されるSPN_chunk_start[k]を示す図である。 光ディスク上に記録されたAVストリームの構造を示す図である。 Clip AVストリームの例を示す図である。 EP_mapの例を示す図である。 SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。 ソフト製作処理部の構成例を示すブロック図である。 ソフト製作処理部を含む構成の例を示す図である。
[再生システムの構成例]
 図1は、本発明を適用した再生装置201を含む再生システムの構成例を示す図である。
 図1に示すように、この再生システムは、再生装置201と表示装置203がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置201には、BDなどの光ディスク202が装着される。
 光ディスク202には、視点の数が2つのステレオ画像(3D画像)を表示するために必要なストリームが記録されている。
 各ストリームのデータは、エクステント単位で、インターリーブされた状態で光ディスク202に記録されている。
 再生装置201は、光ディスク202に記録されているストリームの3D再生に対応したプレーヤである。再生装置201は、光ディスク202に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置203に表示させる。音声についても同様に再生装置201により再生され、表示装置203に設けられるスピーカなどから出力される。
 光ディスク202には、3D画像を表示することができるようなストリームが記録されている。ストリームを光ディスク202に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)が採用される。
[H.264 AVC/MVC Profile]
 H.264 AVC/MVCでは、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCを単にMVCという。
 図2は、撮影の例を示す図である。
 図2に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
 図3は、MVCエンコーダの構成例を示すブロック図である。
 図3に示すように、MVCエンコーダ211は、H.264/AVCエンコーダ221、H.264/AVCデコーダ222、Depth算出部223、Dependent view videoエンコーダ224、およびマルチプレクサ225から構成される。
 L画像用のカメラにより撮影された映像#1のストリームはH.264/AVCエンコーダ221とDepth算出部223に入力される。また、R画像用のカメラにより撮影された映像#2のストリームはDepth算出部223とDependent view videoエンコーダ224に入力される。映像#2のストリームがH.264/AVCエンコーダ221とDepth算出部223に入力され、映像#1のストリームがDepth算出部223とDependent view videoエンコーダ224に入力されるようにしてもよい。
 H.264/AVCエンコーダ221は、映像#1のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ221は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ222とマルチプレクサ225に出力する。
 H.264/AVCデコーダ222は、H.264/AVCエンコーダ221から供給されたAVCビデオストリームをデコードし、デコードして得られた映像#1のストリームをDependent view videoエンコーダ224に出力する。
 Depth算出部223は、映像#1のストリームと映像#2のストリームに基づいてDepth(視差)を算出し、算出したDepthのデータをマルチプレクサ225に出力する。
 Dependent view videoエンコーダ224は、H.264/AVCデコーダ222から供給された映像#1のストリームと、外部から入力された映像#2のストリームをエンコードし、Dependent view videoストリームを出力する。
 Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図4に示すように、Dependent view videoには、Base view videoを参照画像とする予測符号化が許されている。例えばL画像をBase view videoとするとともにR画像をDependent view videoとして符号化を行った場合、その結果得られるDependent view videoストリームのデータ量は、Base view videoストリームのデータ量に比較して少なくなる。
 なお、H.264/AVCでの符号化であるから、Base view videoについて時間方向の予測は行われている。また、Dependent view videoについても、view間の予測とともに、時間方向の予測が行われている。Dependent view videoをデコードするには、エンコード時に参照先とした、対応するBase view videoのデコードが先に終了している必要がある。
 Dependent view videoエンコーダ224は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ225に出力する。
 マルチプレクサ225は、H.264/AVCエンコーダ221から供給されたBase view videoストリームと、Depth算出部223から供給されたDependent view videoストリーム(Depthのデータ)と、Dependent view videoエンコーダ224から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは1本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
 マルチプレクサ225は、生成したTS(MPEG2 TS)を出力する。マルチプレクサ225から出力されたTSは、他の管理データとともに記録装置において光ディスク202に記録され、光ディスク202に記録された形で再生装置201に提供される。
 以下、適宜、図3に示すように、2つのDependent view videoのうち、Depth情報からなるDependent view videoをD1 view videoといい、R画像からなるDependent view videoをD2 view videoという。なお、R画像からなるDependent view videoをD1 view videoとして処理し、Depth情報からなるDependent view videoをD2 view videoとして処理するようにすることも可能である。
 また、Base view videoとD1 view videoを用いて行われる3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる3D再生をB-D2再生という。
 再生装置201は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク202から読み出して再生する。
 また、再生装置201は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク202から読み出して再生する。
 さらに、再生装置201は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク202から読み出して再生する。
 Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
[TSの構成例]
 図5は、TSの構成例を示す図である。
 図5のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。このように、Dependent view videoストリームが、Base view videoストリームとともにMain TSに含まれていることもある。
 光ディスク202には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームを含むTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。
 ビデオと同様に3Dでの表示が可能になるように、PG、IGについてもBase viewとDependent viewのそれぞれのストリームが用意されている。
 図6は、TSの他の構成例を示す図である。
 図6のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
 一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
 このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
 図7は、TSのさらに他の構成例を示す図である。
 図7のMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
 一方、Sub TSにはDependent view videoストリームが含まれている。
 このように、Dependent view videoストリームがBase view videoストリームとは別のTSに含まれていることもある。
[アプリケーションフォーマット]
 図8は、再生装置201によるAVストリームの管理の例を示す図である。
 AVストリームの管理は、図8に示すようにPlayListとClipの2つのレイヤを用いて行われる。AVストリームは、光ディスク202だけでなく、再生装置201のローカルストレージに記録されていることもある。
 ここでは、1つのAVストリームとそれに付随する情報であるClip Informationのペアを1つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。
 AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationファイルは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。
 PlayListはAVストリームの再生区間の集まりである。AVストリーム中の1つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。図8に示すように、PlayListは1つまたは複数のPlayItemにより構成される。
 図8の左から1番目のPlayListは2つのPlayItemから構成され、その2つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。
 左から2番目のPlayListは1つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。
 左から3番目のPlayListは2つのPlayItemから構成され、その2つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。
 例えば、左から1番目のPlayListに含まれる左側のPlayItemが再生対象としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を管理するための再生管理情報として用いられる。
 PlayListの中で、1つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。
 また、PlayListの中で、Main Pathに並行して、1つ以上のSubPlayItemの並びによって作られる再生パスをサブパス(Sub Path)という。
 図9は、Main PathとSub Pathの構造を示す図である。
 PlayListは、1つのMain Pathと1つ以上のSub Pathを持つことができる。
 上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。
 図9のPlayListは、3つのPlayItemの並びにより作られる1つのMain Pathと、3つのSub Pathを有している。
 Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。
 図9の例においては、Subpath_id=0のSub Pathには1つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには2つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには1つのSubPlayItemが含まれる。
 1つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム(メイン画像データ)が含まれる。
 また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで(同期して)再生されるオーディオストリームが1つ以上含まれてもよいし、含まれなくてもよい。
 Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ(PG(Presentation Graphic))のストリームが1つ以上含まれてもよいし、含まれなくてもよい。
 Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが1つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。
 1つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される0個以上のオーディオストリーム、0個以上のPGストリーム、および、0個以上のIGストリームが多重化されている。
 また、1つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム(別ストリーム)の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。
 このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開2008-252740号公報、特開2005-348314号公報に記載されている。
[ディレクトリ構造]
 図10は、光ディスク202に記録されるファイルの管理構造の例を示す図である。
 図10に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク202上には1つのrootディレクトリが作成される。rootディレクトリの下が、1つの記録再生システムで管理される範囲となる。
 rootディレクトリの下にはBDMVディレクトリが置かれる。
 BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
 BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
 PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、5桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。図10に示す1つのPlayListファイルには「00000.mpls」のファイル名が設定されている。
 CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、5桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
 図10の3つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
 例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。
 「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。
 「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。
 STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、5桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、5桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
 「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。
 「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。
 「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。
 「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。
 図10に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
[各データのシンタクス]
 図11は、PlayListファイルのシンタクスを示す図である。
 PlayListファイルは、図10のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
 図11のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。
 version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは4桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。“0240”が設定されたPlayListファイルに記述されるPlayListが、後述する3D_PlayListとなる。
 PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。
 PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。
 ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。
 ExtensionData_start_addressの後には、160bitのreserved_for_future_useが含まれる。
 AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
 PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
 PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先(ジャンプポイント)であるマークに関する情報が格納される。
 ExtensionData()には、プライベートデータが挿入できるようになっている。
 図12は、図11のPlayList()のシンタクスを示す図である。
 lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す32ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
 lengthの後には、16ビットのreserved_for_future_useが用意される。
 number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す16ビットのフィールドである。図9の例の場合、PlayItemの数は3である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に0から割り振られる。例えば、図9のPlayItem_id=0,1,2が割り振られる。
 number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す16ビットのフィールドである。図9の例の場合、Sub Pathの数は3である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に0から割り振られる。例えば、図9のSubpath_id=0,1,2が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。
 図13は、図12のSubPath()のシンタクスを示す図である。
 lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す32ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
 lengthの後には、16ビットのreserved_for_future_useが用意される。
 SubPath_typeは、Sub Pathのアプリケーションの種類を示す8ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。
 SubPath_typeの後には、15ビットのreserved_for_future_useが用意される。
 is_repeat_SubPathは、Sub Pathの再生方法を指定する1ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を1回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合(Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など)に利用される。
 Is_repeat_SubPathの後には、8ビットのreserved_for_future_useが用意される。
 number_of_SubPlayItemsは、1つのSub Pathの中にあるSubPlayItemの数(エントリー数)を示す8ビットのフィールドである。例えば、図9のSubPath_id=0のSubPlayItemのnumber_of_SubPlayItemsは1であり、SubPath_id=1のSubPlayItemのnumber_of_SubPlayItemsは2である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem()が参照される。
 図14は、図13のSubPlayItem(i)のシンタクスを示す図である。
 lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す16ビットの符号なし整数である。
 図14のSubPlayItem(i)は、SubPlayItemが1つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。
 SubPlayItemが1つのClipを参照する場合について説明する。
 Clip_Information_file_name[0]は、SubPlayItemが参照するClipのClip Informationファイルの名前を表す。
 Clip_codec_identifier[0]はClipのコーデック方式を表す。Clip_codec_identifier[0]の後にはreserved_for_future_useが含まれる。
 is_multi_Clip_entriesはマルチClipの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。
 ref_to_STC_id[0]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。
 SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。
 sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。
 SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。
 「if(is_multi_Clip_entries==1b」であり、SubPlayItemが複数のClipを参照する場合について説明する。
 num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。
 Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。
 ref_to_STC_id[SubClip_entry_id]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。
 図15は、図12のPlayItem()のシンタクスを示す図である。
 lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す16ビットの符号なし整数である。
 Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むm2tsファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ5桁の数字が含まれる。
 Clip_codec_identifier[0]はClipのコーデック方式を表す。Clip_codec_identifier[0]の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。
 ref_to_STC_id[0]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。
 IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。
 OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。
 STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。
 図16は、図15のSTN_table()のシンタクスを示す図である。
 STN_table()は、PlayItemの属性として設定されている。
 lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す16ビットの符号なし整数である。lengthの後には、16ビットのreserved_for_future_useが用意される。
 number_of_video_stream_entriesは、STN_table()の中でエントリーされる(登録される)、video_stream_idが与えられるストリームの数を表す。
 video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームがこのvideo_stream_idにより特定される。
 Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
 video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。
 number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる1番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。
 number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる2番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。
 number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。
 number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、IGストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
 Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
[PlayListの具体例]
 図17は、3D再生用のPlayListである3D_PlayListの具体例を示す図である。
 説明の便宜上、図17の左側には行数を表す数字と「:」を示している。この数字と「:」は3D_PlayListを構成するものではない。
 2行目のnumber_of_PlayItemsは図12のnumber_of_PlayItemsに対応し、3D_PlayList中のPlayItemの数を表す。2行目から8行目がPlayItemに関する記述になる。すなわち、3行目から8行目が、図12のfor文を用いたPlayItemに記述に対応する。
 5行目のref_to_B_clpi_file_nameは図15のClip_Information_file_name[0]に対応し、Base view videoストリームを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、参照するm2tsファイルと、Base view videoのClipのclpiファイルが特定される。
 6行目のtypeは、Base view videoと、それに関連付けられたD1/D2 view videoのデータの光ディスク202上での配置のタイプを表す。typeは、例えば図15のClip_codec_identifier[0]に続くreserved_for_future_useを用いて設定される。
 図18は、typeの意味を示す図である。
 typeの値が0であることは、Base view video、D1 view video、D2 view videoがインターリーブされていないことを表す。
 この場合、存在するD1/D2 view videoの両方、またはいずれかのパケットが、Base view videoのパケットとともに1本のMPEG2-TSに多重化される。
 typeの値が1であることは、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを表す。
 この場合、B view videoを含む第1のTSと、D1 view videoを含む第2のTSと、D2 view videoを含む第3のTSの3本のTSが、エクステント単位で光ディスク202上にインターリーブされている。
 typeの値が2であることは、Base view videoとD1 view videoがインターリーブされていることを表す。
 この場合、B view videoのパケットを含む第1のTSと、D1 view videoのパケットを含む第2のTSの2本のTSが、エクステント単位で光ディスク202上にインターリーブされている。第1のTSにはD2 view videoのパケットが多重化されていても良い。また、第2のTSには、D2 view videoのパケットが多重化されていても良い。
 typeの値が3であることは、Base view videoとD2 view videoがインターリーブされていることを表す。
 この場合、B view videoのパケットを含む第1のTSと、D2 view videoのパケットを含む第2のTSの2本のTSが、エクステント単位で光ディスク202上にインターリーブされている。第1のTSには、D1 view videoのパケットが多重化されていても良い。また、第2のTSには、D1 view videoのパケットが含まれてはいけない。
 図17の説明に戻り、7行目のSTN_tableは図15のSTN_table()に対応する。図16を参照して説明したように、STN_tableには3D_PlayListにおいて参照する各ストリームのIDが記述される。
 9行目のnumber_of_SubPathsは図12のnumber_of_SubPathsに対応し、3D_PlayList中のSubPathの数を表す。9行目から14行目がSubPathに関する記述になる。すなわち、10行目から14行目が、図12のfor文を用いたSubPathに記述に対応する。
 12行目のSubPath_typeは図13のSubPath_typeに対応し、SubPathの種類を表す。
 図19は、SubPath_typeの意味を示す図である。
 図19に示す各値のうちの主なものについて説明すると、SubPath_typeの値が8であることは、D1 view videoを再生するサブパスであることを表す。
 また、SubPath_typeの値が9であることは、D2 view videoを再生するサブパスであることを表す。
 図17の13行目のref_to_clpi_file_nameは図14のClip_Information_file_name[0]に対応する。
 このSubPathがD1 view videoを再生するものである場合には、ref_to_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、参照するclpiファイルが特定される。
 一方、13行目のref_to_clpi_file_nameは、このSubPathがD2 view videoを再生するものである場合には、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。
 16行目から30行目は、interleaved_file_info()、すなわちilvtファイルに関する記述である。例えば、PlayItem()、SubPath()中のreserved_for_future_useを用いてilvtファイルに関する記述が用意される。
 17行目から22行目は、6行目のtypeの値が1であり、Base view video、D1 view video、D2 view videoが全てインターリーブされている場合に参照する記述である。
 18行目のref_to_D1-B_interleaved_file_nameは、Base view videoとD1 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
 19行目のref_to_D2-B_interleaved_file_nameは、Base view videoとD2 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
 20行目のref_to_D1_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D1 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
 21行目のref_to_D2_clpi_file_nameは、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D2 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
 23行目から26行目は、6行目のtypeの値が2であり、Base view videoとD1 view videoがインターリーブされている場合に参照する記述である。
 24行目のref_to_D1-B_interleaved_file_nameは、Base view videoとD1 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
 25行目のref_to_D1_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D1 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
 27行目から30行目は、6行目のtypeの値が3であり、Base view videoとD2 view videoがインターリーブされている場合に参照する記述になる。
 28行目のref_to_D2-B_interleaved_file_nameは、Base view videoとD2 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
 29行目のref_to_D2_clpi_file_nameは、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D2 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
 このように、3D_PlayListには、データが光ディスク202上でインターリーブされている場合、D1 view video、D2 view videoについても、それらのClip AVストリームに対応するclpiファイルのファイル名を特定可能な情報が記述される。
[再生装置201の構成例]
 図20は、再生装置201の構成例を示すブロック図である。
 コントローラ251は、予め用意されている制御プログラムを実行し、再生装置201の全体の動作を制御する。
 例えば、コントローラ251は、ディスクドライブ252を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ251は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部256に供給させる。
 ディスクドライブ252は、コントローラ251による制御に従って光ディスク202からデータを読み出し、読み出したデータを、コントローラ251、メモリ253、またはデコーダ部256に出力する。
 メモリ253は、コントローラ251が各種の処理を実行する上において必要なデータなどを適宜記憶する。
 ローカルストレージ254は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ254には、サーバ272からダウンロードされたD1/D2 view videoストリームなどが記録される。ローカルストレージ254に記録されているストリームもデコーダ部256に適宜供給される。
 インターネットインタフェース255は、コントローラ251からの制御に従ってネットワーク271を介してサーバ272と通信を行い、サーバ272からダウンロードしたデータをローカルストレージ254に供給する。
 サーバ272からは、光ディスク202に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたD1/D2 view videoストリームを光ディスク202に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク202の内容とは異なる内容の3D再生を実現することが可能になる。D1/D2 view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。
 デコーダ部256は、ディスクドライブ252、またはローカルストレージ254から供給されたストリームをデコードし、得られたビデオ信号を表示装置203に出力する。オーディオ信号も所定の経路を介して表示装置203に出力される。
 操作入力部257は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部257はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ251に供給する。
 図21は、デコーダ部256の構成例を示す図である。
 分離部281は、コントローラ251による制御に従って、ディスクドライブ252から供給されたデータを、Main TSを構成するパケットのデータとSub TSを構成するパケットのデータに分離する。例えば、3D PlayListファイルのSTN_table()に記述されているストリームIDに基づいて光ディスク202から読み出されたTSが分離部281に供給される。
 分離部281は、分離したMain TSを構成するパケットをリードバッファ282に出力して記憶させ、Sub TSを構成するパケットをリードバッファ285に出力して記憶させる。
 また、分離部281は、ローカルストレージ254から供給されたSub TSを構成するパケットをリードバッファ285に出力して記憶させる。
 上述したように、サーバ272からダウンロードされたD1/D2 view videがローカルストレージ254に記憶されている場合がある。光ディスク202に記録されているBase view videoとともに再生することが指示されたとき、Sub TSとしてのD1/D2 view videストリームがローカルストレージ254から読み出され、分離部281に供給される。
 PIDフィルタ283は、リードバッファ282に記憶されているMain TSを構成するパケットを、各パケットに設定されているPIDに基づいて振り分ける。コントローラ251からは、Base view videoを構成するパケットのPID、D1 view videoを構成するパケットのPID、D2 view videoを構成するパケットのPIDがそれぞれ指定される。
 PIDフィルタ283は、Main TSに含まれるBase view videoのパケットをリードバッファ282から読み出し、ESバッファ284に出力して記憶させる。ESバッファ284には、Base view videoのパケットからなるES(Elementary Stream)が記憶される。
 また、PIDフィルタ283は、Main TSにD1/D2 view videのパケットが多重化されている場合、それらのパケットをPIDに基づいて抽出し、スイッチ287に出力する。
 PIDフィルタ286は、Sub TSに含まれるD1/D2 view videのパケットをリードバッファ285から読み出し、スイッチ287に出力する。
 なお、ここではBase view video、D1/D2 view videoのビデオストリームの処理についてだけ説明しているが、図5を参照して説明したように、Main TSにはPGやIGなどのグラフィックスのデータが多重化されていることがある。同様に、図6を参照して説明したように、Sub TSには、D1/D2 view videの他にも、字幕のデータやグラフィックのデータが多重化されていることがある。
 PIDフィルタ283とPIDフィルタ286は、適宜、それらのデータをもPIDに基づいて振り分け、所定の出力先に出力する。図21のPIDフィルタ283とPIDフィルタ286のブロック内に示す出力先の端子(丸)には、グラフィックのデータをデコードするデコーダなどが接続される。
 スイッチ287は、PIDフィルタ283から供給されたD1/D2 view videのパケットをESバッファ288に出力して記憶させる。また、スイッチ287は、PIDフィルタ286から供給されたD1/D2 view videのパケットをESバッファ288に出力して記憶させる。ESバッファ288には、D1/D2 view videoのパケットからなるESが記憶される。
 スイッチ289は、ESバッファ284に記憶されているBase view videoのパケットと、ESバッファ288に記憶されているD1/D2 view videoのパケットのうちの、デコードの対象になるパケットをデコーダ290に出力する。DTS(Decoding Time Stamp)などの時刻情報がBase view videoとD1/D2 view videoのPESパケットに設定されており、その時刻情報に基づいてバッファからの読み出しが行われる。
 ビデオデコーダ290は、スイッチ289から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはD1/D2 view videoのデータを出力する。
[3D_PlayListの例1]
 図22は、3D_PlayListの例を示す図である。
 図22の「00000.mpls」のPlayListファイルに記述されている3D_PlayListは、Base view video、D1 view video、D2 view videoが全てインターリーブされている光ディスク202の再生を管理するPlayListである。すなわち、typeの値は1である。
 図22の例においては、PlayItem()のref_to_B_clpi_file_nameは「00001」である。この記述から、Base view videoのm2tsファイルである「00001.m2ts」を再生する場合には、図10の「00001.clpi」のclpiファイルを参照することが特定される。
 また、SubPath()[1]のSubPath_typeは「9」である。SubPath_typeが「9」であることは、この1つ目のSubPathがD2 view videoを再生するサブパスであることを表す。
 SubPath()[1]のref_to_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
 SubPath()[2]のSubPath_typeは「8」である。SubPath_typeが「8」であることは、この2つ目のSubPathがD1 view videoを再生するサブパスであることを表す。
 SubPath()[2]のref_to_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には図10の「00003.clpi」のclpiファイルを参照することが特定される。
 interleaved_file_info()のref_to_D1-B_interleaved_file_nameは「10000」である。この記述から、D1-B再生を行う場合には図10の「10000.ilvt」のilvtファイルを参照することが特定される。
 また、ref_to_D2-B_interleaved_file_nameは「20000」である。この記述から、D2-B再生を行う場合には図10の「20000.ilvt」のilvtファイルを参照することが特定される。
 ref_to_D1_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には図10の「00003.clpi」のファイルを参照することが特定される。
 ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のファイルを参照することが特定される。
 図23は、図22の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
 図23のAは「00001.clpi」のclpiファイルの例を示す図である。上述したように、「00001.clpi」のclpiファイルは、Base view videoのm2tsファイルである「00001.m2ts」を再生する場合に参照するファイルである。
 number_of_source_packets1は、「00001.m2ts」のm2tsファイルに含まれるソースパケットの数を表す。
 EP_mapは、「00001.m2ts」のm2tsファイルに含まれるTS中のエントリーポイント(EP)の位置情報を表す。
 chunk_map()は、「00001.m2ts」のm2tsファイルに含まれるTSについて、先頭のチャンクから順番に、各チャンクの開始位置を表すSource Packet Number(SPN)を表す。
 チャンクは、1つのTSに属し、光ディスク202上に連続配置されるSource packetの集まりである。ここでは、1つのチャンクが、光ディスク202上に配置される1つのエクステントに相当するものとして説明する。
 chunk_map()が、各チャンクの長さを表すことになる。chunk_map()の具体例については後述する。
 図23のBは「00002.clpi」のclpiファイルの例を示す図である。「00002.clpi」のclpiファイルは、D2 view videoを再生する場合に参照するファイルである。
 図23のCは「00003.clpi」のclpiファイルの例を示す図である。「00003.clpi」のclpiファイルは、D1 view videoを再生する場合に参照するファイルである。図23のB、図23のCの記述内容は図23のAに示すものと同じである。
 図24は、図22、図23のデータを用いて行われるファイル管理の概念を示す図である。
 図24に示すように、ファイル管理は、物理レイヤ、ファイルシステムレイヤ、アプリケーションレイヤの3層構造の形で行われる。図22の3D_PlayList、図23のclpiファイルがアプリケーションレイヤの情報になる。
 物理レイヤは、Base view video、D1 view video、D2 view videoが全てインターリーブされた状態で記録されている光ディスク202のレイヤとなる。
 図24の例においては、D1 view videoのチャンク、D2 view videoのチャンク、Base view videoのチャンクがその順番で配置されている。図24において、「B」の文字を付けているブロックはBase view videoのチャンクを表し、「D1」の文字を付けているブロックはD1 view videoのチャンクを表す。「D2」の文字を付けているブロックはD2 view videoのチャンクを表す。
 このように、Base view video、D1 view video、D2 view videoの各エクステント(チャンク)は、光ディスク202上においてインターリーブ配置されている。インターリーブ配置は、同一種類のストリームのエクステントが隣接しない、周期的な配置を意味する。
 ファイルシステムレイヤにおいては、アプリケーションがファイル名で指定したストリームファイル(m2tsファイル、ilvtファイル)と、光ディスク202上の各チャンクが対応付けられる。ファイルシステムは例えばUDF file systemである。
 図24に示すように、「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
 また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
 「00003.m2ts」のm2tsファイルは、光ディスク202上に配置されたD1 view videoのチャンクから構成される。
 「20000.ilvt」のファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
 「10000.ilvt」のファイルは、光ディスク202上に配置されたD1 view videoのチャンクとBase view videoのチャンクから構成される。
 2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
 また、B-D1再生を行うために、アプリケーションから「10000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D1 view videoのチャンクとBase view videoのチャンクが読み出される。
 B-2D再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例1]
 ここで、図25のフローチャートを参照して、図22の3D_PlayListファイルに従って行われる再生処理について説明する。
 ステップS1において、コントローラ251は、typeの値から、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを確認する。
 この場合、ステップS2において、コントローラ251は、interleaved_file_info()を読みに行く。
 ステップS3において、コントローラ251は、ユーザによる操作などに基づいて、B-D1再生が指示されたか否かを判定する。
 B-D1再生が指示されたとステップS3において判定した場合、ステップS4において、コントローラ251は、interleaved_file_info()に記述された「10000.ilvt」(ref_to_D1-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD1 view videoのチャンクを光ディスク202から読み出させる。
 ディスクドライブ252により読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
 ステップS5において、分離部281は、図23の「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00003.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00003.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。chunk_map()を使って行われるデータの分離については後述する。
 リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。リードバッファ285に記憶された「00003.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
 ステップS6において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする(再生する)。
 一方、ステップS3において、B-D1再生が指示されていない、すなわちB-D2再生が指示されたと判定した場合、ステップS7において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
 ステップS8において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
 その後、「00001.m2ts」のm2tsファイルのデータと「00002.m2ts」のm2tsファイルのデータは、B-D1再生のときと同様にデコーダ290に供給され、ステップS6において再生される。
[chunk_map()を使ったデータの分離]
 図26は、chunk_map()のシンタクスの例を示す図である。
 number_of_chunksは、参照するチャンクの数を表す。number_of_chunks以降には、ここで指定される数だけチャンクの情報が記述される。
 SPN_chunk_start[i]は、例えば先頭のチャンクの開始位置を基準として、その基準の位置から各チャンクの開始位置までのSPN(長さ)を表す。各チャンクの開始位置までのSPNが、先頭のチャンクのものから順に記述される。
 図27は、chunk_map()の具体例を示す図である。
 図27のAは「00001.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
 また、SPN_chunk_start[i]は0,c1,c2,…,cnである。
 1番目の値0は、図28のCに示すように、「00001.m2ts」のm2tsファイルに含まれるBase view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(B[0])の開始位置までのSPNが0であることを表す。
 2番目の値c1は、基準の位置から、2番目のチャンク(B[1])の開始位置までのSPNがc1であることを表す。
 3番目の値c2は、基準の位置から、3番目のチャンク(B[2])の開始位置までのSPNがc2であることを表す。
 n+1番目の値cnは、基準の位置から、最後のチャンクであるn+1番目のチャンク(B[n])の開始位置までのSPNがcnであることを表す。
 図27のBは「00002.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
 また、SPN_chunk_start[i]は0,b1,b2,…,bnである。
 1番目の値0は、図28のBに示すように、「00002.m2ts」のm2tsファイルに含まれるD2 view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(D2[0])の開始位置までのSPNが0であることを表す。
 2番目の値b1は、基準の位置から、2番目のチャンク(D2[1])の開始位置までのSPNがb1であることを表す。
 3番目の値b2は、基準の位置から、3番目のチャンク(D2[2])の開始位置までのSPNがb2であることを表す。
 n+1番目の値bnは、基準の位置から、最後のチャンクであるn+1番目のチャンク(D2[n])の開始位置までのSPNがbnであることを表す。
 図27のCは「00003.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
 また、SPN_chunk_start[i]は0,a1,a2,…,anである。
 1番目の値0は、図28のAに示すように、「00003.m2ts」のm2tsファイルに含まれるD1 view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(D1[0])の開始位置までのSPNが0であることを表す。
 2番目の値a1は、基準の位置から、2番目のチャンク(D1[1])の開始位置までのSPNがa1であることを表す。
 3番目の値a2は、基準の位置から、3番目のチャンク(D1[2])の開始位置までのSPNがa2であることを表す。
 n+1番目の値anは、基準の位置から、最後のチャンクであるn+1番目のチャンク(D1[n])の開始位置までのSPNがanであることを表す。
 D1[i],D2[i],B[i]は、図28のDに示すようにその順番で、光ディスク202上に周期的に配置されている。
 分離部281は、光ディスク202から読み出されたデータがディスクドライブ252から供給された場合、図27の3つのchunk_map()の記述に基づいて、供給されたデータの先頭からa1に相当するSPN分のデータをD1[0]として分離する。
 また、分離部281は、D1[0]の終わりの位置からb1に相当するSPN分のデータをD2[0]として分離し、D2[0]の終わりの位置からc1に相当するSPN分のデータをB[0]として分離する。
 分離部281は、B[0]の終わりの位置からa2-a1に相当するSPN分のデータをD1[1]として分離する。
 分離部281は、D1[1]の終わりの位置からb2-b1に相当するSPN分のデータをD2[1]として分離し、D2[1]の終わりの位置からc2-c1に相当するSPN分のデータをB[1]として分離する。
 なお、分離の対象になるチャンクは、B-D1再生を行う場合にはD1[i],B[i]だけであり、B-D2再生を行う場合にはD2[i],B[i]だけである。
 このように、分離部281によるデータの分離は、chunk_map()に記述される各チャンクの長さの情報を用いて行われる。
 chunk_map()について補足する。
 type=0のとき、ref_to_B_clpi_file_nameにより参照されるclpiファイルについては、chunk_map()はオプショナルとなる(無くても良い)。そして、chunk_map()がある場合、プレーヤはそのchunk_map()を無視しなければならない。
 また、ローカルストレージ254上のm2tsファイルに対応するclpiファイルについては、chunk_map()はオプショナルとなる(無くても良い)。そして、chunk_map()がある場合、プレーヤはそのchunk_map()を無視しなければならない。
 type=1のとき、対応するBase view videoのTS、D1 view videoのTS、D2 view videoのTSの3本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、図28のD1[i],D2[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
 同様に、type=2のとき、対応するBase view videoのTS、D1 view videoのTSの2本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、インターリーブされるD1[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
 type=3のとき、対応するBase view videoのTS、D2 view videoのTSの2本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、インターリーブされるD2[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
[3D_PlayListの例2]
 図29は、3D_PlayListの他の例を示す図である。
 図29の「0000.mpls」のPlayListファイルに記述されている3D_PlayListは、Base view videoとD2 view videoがインターリーブされている光ディスク202の再生を管理するPlayListである。すなわち、typeの値は3である。
 SubPathの記述がD2 view videoを参照するSubPathの記述だけになる点と、interleaved_file_info()の記述が異なる点を除いて、図29の3D_PlayListの記述は図22の記述と同様である。
 すなわち、SubPath()のSubPath_typeは「9」である。SubPath_typeが「9」であることは、このSubPathがD2 view videoを再生するサブパスであることを表す。
 また、ref_to_clpi_file_nameは「00002」である。
 図29のinterleaved_file_info()のref_to_D2-B_interleaved_file_nameは「20000」である。この記述から、D2-B再生を行う場合には図10の「20000.ilvt」のilvtファイルを参照することが特定される。
 また、ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
 図30は、図29の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
 図30のAは、「00001.clpi」のclpiファイルの例を示す図であり、図30のBは、「00002.clpi」のclpiファイルの例を示す図である。いずれのclpiファイルにも、EP_mapと、上述したchunk_map()の記述が含まれる。
 図31は、図29、図30のデータを用いて行われるファイル管理の概念を示す図である。
 図31に示すように、物理レイヤは、Base view videoとD2 view videoがインターリーブされた状態で記録されている光ディスク202のレイヤとなる。
 「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
 また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
 「20000.ilvt」のilvtファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
 2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
 B-D2再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例2]
 図32のフローチャートを参照して、図29の3D_PlayListファイルに従って行われる再生処理について説明する。
 ステップS11において、コントローラ251は、typeの値から、Base view video、D2 view videoがインターリーブされていることを確認する。
 この場合、ステップS12において、コントローラ251は、interleaved_file_info()を読みに行く。
 B-D2再生が指示された場合、ステップS13において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
 ディスクドライブ252により読み出されたBase view videoのチャンクとD2 view videoのチャンクはデコーダ部256の分離部281に供給される。
 ステップS14において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
 リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。一方、リードバッファ285に記憶された「00002.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
 ステップS15において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
[3D_PlayListの例3]
 図33は、3D_PlayListのさらに他の例を示す図である。
 図33の「00000.mpls」のPlayListファイルに記述されている3D_PlayListは、光ディスク202に記録されているBase view video、D2 view videoと、ローカルストレージ254に記録されているD1 view videoの再生を管理するPlayListである。光ディスク202上では、Base view videoとD2 view videoはインターリーブされている。
 光ディスク202上のデータの配置のタイプを表すものであるから、PlayItem()のtypeの値は3である。
 SubPath()[1]のSubPath_typeは「9」である。SubPath_typeが「9」であることは、この1つ目のSubPathがD2 view videoを再生するサブパスであることを表す。
 SubPath()[1]のref_to_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
 SubPath()[2]のSubPath_typeは「8」である。SubPath_typeが「8」であることは、この2つ目のSubPathがD1 view videoを再生するサブパスであることを表す。
 SubPath()[2]のref_to_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には、ローカルストレージ254に記録されている「00003.clpi」のclpiファイルを参照することが特定される。
 この2つ目のSubPathに関する記述は、例えば、D1 view videoがダウンロードされたときに追加される。
 interleaved_file_info()のref_to_D2-B_interleaved_file_nameは「20000」である。この記述から、B-D2再生を行う場合には、図10の「20000.ilvt」のilvtファイルを参照することが特定される。
 また、ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のファイルを参照することが特定される。
 なお、ローカルストレージ254上ではD1 view videoはインターリーブされていないから、D1 view videoに関するilvtファイルは不要である。
 図34は、図33の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
 図34のAは、「00001.clpi」のclpiファイルの例を示す図であり、図34のBは、「00002.clpi」のclpiファイルの例を示す図である。いずれのclpiファイルにも、EP_mapとchunk_map()の記述が含まれる。
 図35は、図33、図34のデータを用いて行われるファイル管理の概念を示す図である。
 図35に示すように、物理レイヤは、Base view videoとD2 view videoがインターリーブされた状態で記録されている光ディスク202と、2番目のSubPathが参照するD1 view videoのファイルが記録されているローカルストレージ254のレイヤとなる。
 図35の例においては、D1 view videoを格納したm2tsファイルのファイル名は「00003.m2ts」である。また、「00003.m2ts」に対応するclpiファイルのファイル名は「00003.clpi」である。
 「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
 また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
 「20000.ilvt」のilvtファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
 2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
 B-D1再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。また、図33の3D_PlayListの2番目のSubPathの記述に従って、「00003.m2ts」を指定して、D1 view videoのm2tsファイルがローカルストレージ254から読み出される。
 B-D2再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例3]
 図36のフローチャートを参照して、図33の3D_PlayListファイルに従って行われる再生処理について説明する。
 ステップS21において、コントローラ251は、typeの値から、Base view video、D2 view videoがインターリーブされていることを確認する。
 この場合、ステップS22において、コントローラ251は、interleaved_file_info()を読みに行く。
 ステップS23において、コントローラ251は、B-D1再生が指示されたか否かを判定する。
 B-D1再生を行う場合、光ディスク202に記録されているデータとローカルストレージ254に記録されているデータが用いられる。一方、B-D2再生を行う場合、光ディスク202に記録されているデータが用いられる。
 ステップS23において、B-D1再生が指示されていない、すなわちB-D2再生が指示されたと判定した場合、ステップS24において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を構成するD2 view videoを含むClipの名前X「00002」(D2 view videoを含むm2tsファイルの名前のうちの拡張子を除いた部分)を取り出す。
 ステップS25において、コントローラ251は、SubPath_type=9(D2-view videoを再生するサブパス)が参照するClipの名前Y「00002」を取り出す。
 ステップS26において、コントローラ251は、YがXと同じであることにより、D2 view videoが「20000.ilvt」に含まれていることを認識する。ここでYがXと異なるとき、D2 view videoを含むClipはローカルストレージ254上にあることになる。
 ステップS27において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
 ディスクドライブ252により読み出されたBase view videoのチャンクとD2 view videoのチャンクはデコーダ部256の分離部281に供給される。
 ステップS28において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
 リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。一方、リードバッファ285に記憶された「00002.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
 ステップS29において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
 一方、B-D1再生が指示されたとステップS23において判定した場合、ステップS30において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を構成するD2 view videoを含むClipの名前X「00002」を取り出す。
 ステップS31において、コントローラ251は、SubPath_type=8(D1-view videoを再生するサブパス)が参照するClipの名前Y「00003」を取り出す。
 ステップS32において、コントローラ251は、Yが「00001.clpi」(ref_to_B_clpi_file_name)のうちの拡張子を除いた部分と異なり、かつ、YがXと異なることにより、D1 view videoのClipがローカルストレージ254上にあることを認識する。ここでYが「00001.clpi」のうちの拡張子を除いた部分と同じであるとき、または、YがXと同じあるとき、D1 view videoは「20000.ilvt」に含まれていることになる。
 ステップS33において、コントローラ251は、「00001.clpi」(ref_to_B_clpi_file_name)のEP_mapを使って、ディスクドライブ252に「00001.m2ts」のm2tsファイルを読み出させる。「00001.clpi」のEP_mapには、「00001.m2ts」のm2tsファイルのデコード開始位置となるエントリポイントの情報が含まれている。
 ステップS34において、コントローラ251は、「00003.clpi」(SubPath()[2]で参照されるファイル)のEP_mapを使って、ローカルストレージ254から「00003.m2ts」のm2tsファイルを読み出す。「00003.clpi」のEP_mapには、「00003.m2ts」のm2tsファイルのデコード開始位置となるエントリポイントの情報が含まれている。
 読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
 光ディスク202から読み出された「00001.m2ts」のm2tsファイルのデータはリードバッファ282に記憶された後、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。
 また、ローカルストレージ254から読み出された「00003.m2ts」のm2tsファイルのデータはリードバッファ285に記憶された後、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
 ステップS29において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
[chunk_map()を利用して「10000.ilvt」をランダムアクセス再生する方法]
 図37は、図27を参照して説明したchunk_map()の内容をまとめて示す図である。
 各clpiファイルのchunk_map()に記述されるSPN_chunk_start(基準の位置からのSPN(長さ))を、縦方向にiをとって並べると図37に示すようなものになる。
 図38は、chunk_map()とともに各clpiファイルに記述されるEP_map()のシンタクスを示す図である。
 EP_map()はランダムアクセスなどを行うときのデコード開始位置を特定するために参照される。
 number_of_EP_entriesはEP(エントリポイント)の数を表す。
 number_of_EP_entries以降の記述が各EPについて用意される。PTS_EP_start[i]はEPのPTSを表し、SPN_EP_start[i]はEPのSPNを表す。このように、EP_mapには、各エントリポイントについてのPTSとSPNが対応付けて登録される。
 図39のフローチャートを参照して、再生装置201の処理について説明する。
 ここでは、図22の3D_PlayListを参照してB-D1再生を行い、ランダムアクセスを行う場合について説明する。
 ステップS41において、コントローラ251は、typeの値から、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを確認する。
 この場合、ステップS42において、コントローラ251は、interleaved_file_info()を読みに行く。
 ステップS43において、コントローラ251は、interleaved_file_info()に記述された「10000.ilvt」(ref_to_D1-B_interleaved_file_name)が読み出しファイルであると判断する。
 「00000.mpls」の3D_PlayListファイルの時刻xから再生を開始する場合、ステップS44において、コントローラ251は、「00001.clpi」(ref_to_B_clpi_file_name)のEP_mapを用いて、xよりも小さく最も近い値を持つPTS_EP_start[m]を見つける。
 ステップS45において、コントローラ251は、PTS_EP_start[m]に対応するSPN_EP_start[m]を取り出す。図38を参照して説明したように、EP_mapにはPTS_EP_start[i]とSPN_EP_start[i]が対応付けて登録されている。
 図40は、ステップS44,S45の処理により特定される位置の例を示す図である。
 図40に示すように、時間軸上の時刻xから再生を開始する場合、xよりも小さく最も近い値を持つPTS_EP_start[m]がステップS44において特定される。また、PTS_EP_start[m]に対応するSPN_EP_start[m]がステップS45において特定される。
 ステップS46において、コントローラ251は、「00001.clpi」のchunk_mapを用いて、SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start[k]を見つける。ステップS46の処理により特定されるSPN_chunk_start[k]を図41に示す。
 ステップS47において、コントローラ251は、「00001.clpi」のchunk_map()のSPN_chunk_start[k]と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()のSPN_chunk_start[k]との和を、「10000.ilvt」の読み出し開始アドレスとして決定する。
 ここで決定される「10000.ilvt」の読み出し開始アドレスは、「10000.ilvt」の中でのD1[k]のチャンクの開始アドレスを示す。
 ステップS48において、コントローラ251は、「10000.ilvt」(ref_to_D1-B_interleaved_file_name)を指定し、ステップS47で決定したアドレスから、UDF file systemを通して、Base view videoのチャンクとD1 view videoのチャンクを読み出させる。
 読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
 ステップS49において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00003.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00003.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
 リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。リードバッファ285に記憶された「00003.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
 ステップS50において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
 ilvtファイルのランダムアクセスは以上のようにして行われる。
[EP_mapについて]
 ここで、EP_mapについて説明する。
 Base view videoのEP_mapについて説明するが、D1/D2 view videoについても、同様にしてEP_mapが設定される。例えば、Base view videoのあるピクチャにエントリポイントが設定された場合、D1/D2 view videoの対応するピクチャにもエントリポイントが設定される。
 それぞれのストリームのピクチャをエンコード順/デコード順、あるいは表示順に並べたときに同じ位置にあるBase view videoのピクチャとD1/D2 view videoのピクチャが、対応するピクチャとなる。
 図42は、光ディスク202上に記録されたAVストリームの構造を示す図である。
 Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
 アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。1つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
 Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
 PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
 なお、ソースパケットには、Clip AVストリームの先頭を例えば0として、ソースパケット毎に1ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第1バイト目から始まる。
 EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
 EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の1つのEPデータは、PTSと、PTSに対応するAccess Uniteの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、1Access Uniteには1ピクチャ分のデータが格納される。
 図43は、Clip AVストリームの例を示す図である。
 図43のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム(Base view videoストリーム)である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
 図43においては、ビデオストリームのソースパケットのうちの、IDR(Instantaneous Decording Refresh)ピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
 IDRピクチャはIピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファの状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
 例えば、PID=xで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
 同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
 図44は、図43のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
 図44に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
 stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
 PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UniteのPTSを表す。
 SPN_EP_startは、PTS_EP_startの値により参照されるAccess Uniteの第1バイト目を含むソースパケットのアドレスを表す。
 ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
 例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
 このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
 図45は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
 上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Uniteの第1バイト目を含むソースパケットのソースパケット番号を表す。
 AVC/H.264においては、Access Uniteすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
 トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が1であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Uniteが開始されることになる。
 このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
[記録装置の構成例]
 図46は、ソフト製作処理部301の構成例を示すブロック図である。
 ビデオエンコーダ311は、図3のMVCエンコーダ211と同様の構成を有している。ビデオエンコーダ311は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ312に出力する。
 オーディオエンコーダ313は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ314に出力する。オーディオエンコーダ313には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
 データエンコーダ315は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ316に出力する。
 例えば、データエンコーダ315は、Base view videoストリームのデータとD1/D2 view videoストリームのデータがエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表すtype(図18)をPlayListファイルに設定する。
 また、データエンコーダ315は、Base view videoストリームのデータとD1/D2 view videoストリームのデータがインターリーブされた状態で光ディスクに記録される場合、上述したilvtファイルをPlayListファイルに設定する。ilvtファイルは、Base view videoストリームのデータとD1/D2 view videoストリームのデータとを仮想的にまとめて管理する仮想ファイルとして機能する。
 さらに、データエンコーダ315は、各ClipのClip Informationファイルのファイル名をPlayListファイルに設定したり、それぞれのClip Informationファイルに、EP_mapやchunk_mapを設定したりする。
 多重化部317は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部318に出力する。
 誤り訂正符号化部318は、エラー訂正用のコードを多重化部317により多重化されたデータに付加する。
 変調部319は、誤り訂正符号化部318から供給されたデータに対して変調を施し、出力する。変調部319の出力は、再生装置201において再生可能な光ディスク202に記録されるソフトウェアとなる。
 このような構成を有するソフト製作処理部301が記録装置に設けられる。
 図47は、ソフト製作処理部301を含む構成の例を示す図である。
 図47に示す構成の一部が記録装置内に設けられることもある。
 ソフト製作処理部301により生成された記録信号はプリマスタリング処理部331においてマスタリング処理が施され、光ディスク202に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部333に供給される。
 記録用原盤製作部332においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
 原盤記録部333において、プリマスタリング処理部331から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
 金属原盤製作部334において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
 成形処理部335において、成形用金型に、インジェクションなどによりPMMA(アクリル)またはPC(ポリカーボネート)などの材料を注入し、固定化させることが行われる。あるいは、金属スタンパ上に2P(紫外線硬化樹脂)などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
 成膜処理部336において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
 後加工処理部337において、このディスクに対して内外径の加工が施され、2枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置201によって再生可能なデータが記録された光ディスク202が完成する。
 上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、汎用のパーソナルコンピュータなどにインストールされる。
 インストールされるプログラムはリムーバブル記録媒体に記録して提供される。また、ローカルエリアネットワーク、インターネット、ディジタル放送といった、有線または無線の伝送媒体を介して提供されるようにしてもよい。
 本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
 201 再生装置, 202 光ディスク, 203 表示装置, 211 MVCエンコーダ, 221 H.264/AVCエンコーダ, 222 H.264/AVCデコーダ, 223 Depth算出部, 224 Dependent view videoエンコーダ, 225 マルチプレクサ, 251 コントローラ, 252 ディスクドライブ, 253 メモリ, 254 ローカルストレージ, 255 インターネットインタフェース, 256 デコーダ部, 257 操作入力部

Claims (27)

  1.  所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出す読み出し手段と、
     前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離する分離手段と
     を備える再生装置。
  2.  前記チャンクは、前記記録媒体上に連続配置されるソースパケットの集まりである
     請求項1に記載の再生装置。
  3.  前記第1の情報ファイルが有する前記チャンクの数と、前記第2の情報ファイルが有する前記チャンクの数は、等しい数である
     請求項2に記載の再生装置。
  4.  前記第1の情報ファイルは、さらに、前記第1の多重化ストリームを構成するソースパケットの総数の情報を有し、
     前記第2の情報ファイルは、さらに、前記第2の多重化ストリームを構成するソースパケットの総数の情報を有する
     請求項3に記載の再生装置。
  5.  前記第1の情報ファイルが有する前記チャンクの数を(n+1)とし、
     前記第1の多重化ストリームを構成するチャンクをB[i](i=0~n)、前記第1の多重化ストリームの先頭からk番目のチャンクをB[k]と表し、
     前記第2の多重化ストリームを構成するチャンクをD[i](i=0~n)、前記第2の多重化ストリームの先頭からk番目のチャンクをD[k]と表し、
     B[k]の開始パケット番号を、SPN_chunk_start_1[k]と表し、
     D[k]の開始パケット番号を、SPN_chunk_start_2[k]と表し、
     前記第1の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets1と表し、
     前記第2の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets2と表すとき、
     前記分離手段は、
     k=0~(n-1)について、B[k]を構成するソースパケットの数を、(SPN_chunk_start_1[k+1] - SPN_chunk_start_1[k])によって計算し、
     k=0~(n-1)について、D[k]を構成するソースパケットの数を、(SPN_chunk_start_2[k+1] - SPN_chunk_start_2[k])によって計算し、
     B[n]を構成するソースパケットの数を、(number_of_source_packets1 - SPN_chunk_start_1[n])によって計算し、
     D[n]を構成するソースパケットの数を、(number_of_source_packets2 - SPN_chunk_start_2[n])によって計算する
     請求項4に記載の再生装置。
  6.  B[i]とD[i]について、iの値が同じ組のチャンクは同じ再生時間を有する
     請求項5に記載の再生装置。
  7.  前記読み出し手段による読み出しを制御する制御手段をさらに備え、
     前記制御手段は、
     前記第1の多重化ストリームの情報であり、前記第1の多重化ストリームの中のエントリーポイントの数と、各エントリーポイントについて、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]および位置を表すソースパケット番号であるSPN_EP_start[i]とを有する情報であるEP_mapを読み出し、
     指定された再生開始時刻よりも小さく最も近い値を持つPTS_EP_start[m]を検出し、
     PTS_EP_start[m]に対応するSPN_EP_start[m]を検出し、
     SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start_1[k]とそのkを検出し、
     SPN_chunk_start_1[k]とSPN_chunk_start_2[k]の和を、前記インターリーブドファイルの読み出し開始アドレスとして決定する
     請求項5に記載の再生装置。
  8.  前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamである
     請求項1に記載の再生装置。
  9.  所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、
     前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、
     前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出し、
     前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離する
     ステップを含む再生方法。
  10.  所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量のチャンク単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、
     前記第1の多重化ストリームの情報であり、前記多重化ストリームを構成するチャンクの数と、各チャンクの前記第1の多重化ストリームの中での開始パケット番号とを有する第1の情報ファイルを読み出し、
     前記第2の多重化ストリームの情報であり、前記第2の多重化ストリームを構成するチャンクの数と、各チャンクの前記第2の多重化ストリームの中での開始パケット番号とを有する第2の情報ファイルを読み出し、
     前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームと前記第2の多重化ストリームに分離する
     ステップを含む処理をコンピュータに実行させるプログラム。
  11.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、
     前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定する設定手段を備える
     情報処理装置。
  12.  前記設定手段は、前記再生管理情報ファイルに、前記基本ストリームの再生区間であるクリップに関する情報を記述するクリップ情報ファイルの識別情報と、前記基本ストリームのクリップとともに三次元画像の再生に用いられる前記拡張ストリームのクリップに関する情報を記述する前記クリップ情報ファイルの識別情報とをさらに設定する
     請求項11に記載の情報処理装置。
  13.  前記設定手段は、前記基本ストリームの前記クリップ情報ファイルに、前記基本ストリームのエクステントに関する情報を設定し、前記拡張ストリームの前記クリップ情報ファイルに、前記拡張ストリームのエクステントに関する情報を設定する
     請求項12に記載の情報処理装置。
  14.  前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamである
     請求項11に記載の情報処理装置。
  15.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、
     前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定する
     ステップを含む情報処理方法。
  16.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報を設定し、
     前記エクステント単位でインターリーブされた状態で記録されている場合、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを前記再生管理情報ファイルに設定する
     ステップを含む処理をコンピュータに実行させるプログラム。
  17.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、
     前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させる制御手段を備える
     再生装置。
  18.  前記光ディスクから読み出された前記基本ストリームと前記拡張ストリームとを再生する再生手段をさらに備える
     請求項17に記載の再生装置。
  19.  前記基本ストリームの再生区間であるクリップに関する情報として、前記基本ストリームのエクステントに関する情報が記述されたクリップ情報ファイルの識別情報と、前記基本ストリームのクリップとともに三次元画像の再生に用いられる前記拡張ストリームのクリップに関する情報として、前記拡張ストリームのエクステントに関する情報が記述された前記クリップ情報ファイルの識別情報とが前記再生管理情報ファイルに設定されている場合、
     前記制御手段により読み出されたデータを、それぞれの前記クリップ情報ファイルに設定されている前記エクステントに関する情報に基づいて、前記基本ストリームのデータと前記拡張ストリームのデータに分離する分離手段をさらに備える
     請求項18に記載の再生装置。
  20.  前記エクステントに関する情報は、前記クリップに結び付けられたストリームファイルの中で、それぞれの前記エクステントが開始するソースパケットの番号である
     請求項19に記載の再生装置。
  21.  前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamである
     請求項17に記載の再生装置。
  22.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、
     前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させる
     ステップを含む再生方法。
  23.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、
     前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルに基づいて、前記基本ストリームと前記拡張ストリームとを前記光ディスクから読み出させる
     ステップを含む処理をコンピュータに実行させるプログラム。
  24.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、
     前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップのデータとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させる制御手段を備える
     再生装置。
  25.  前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamである
     請求項24に記載の再生装置。
  26.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、
     前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップのデータとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させる
     ステップを含む再生方法。
  27.  複数の映像データを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームの再生を管理する再生管理情報ファイルに設定されている、前記基本ストリームのデータと、前記拡張ストリームのデータとが、所定のデータ単位であるエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表す記録状態情報が、前記エクステント単位でインターリーブされた状態で記録されていることを表している場合、前記再生管理情報ファイルに設定されている、前記基本ストリームと前記拡張ストリームとを管理する仮想ファイルを参照し、
     前記再生管理情報ファイルに設定されている、前記仮想ファイルにより管理される前記拡張ストリームの再生区間であるクリップに関する情報が記述されたクリップ情報ファイルの識別情報と、前記光ディスクに記録されている前記拡張ストリームのクリップの前記クリップ情報ファイルの識別情報とが一致しない場合、前記基本ストリームのクリップのデータを前記光ディスクから読み出させ、前記基本ストリームのクリップとともに三次元画像の再生に用いられる拡張ストリームのクリップのデータとして、前記光ディスクとは異なる記録媒体に記録されている拡張ストリームのクリップのデータを読み出させる
     ステップを含む処理をコンピュータに実行させるプログラム。
PCT/JP2010/056078 2009-04-07 2010-04-02 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム WO2010116955A1 (ja)

Priority Applications (13)

Application Number Priority Date Filing Date Title
BRPI1002810A BRPI1002810A2 (pt) 2009-04-07 2010-04-02 dispositivos e método de reprodução, programa que faz um computador executar processamento, e, dispositivo e método de processamento de informação.
AU2010235565A AU2010235565B2 (en) 2009-04-07 2010-04-02 Information processing device, information processing method, reproduction device, reproduction method, and program
PL10761654T PL2288172T3 (pl) 2009-04-07 2010-04-02 Urządzenie do przetwarzania informacji, sposób przetwarzania informacji, urządzenie odtwarzające, sposób odtwarzania i program
RU2010149063/08A RU2523196C2 (ru) 2009-04-07 2010-04-02 Устройство обработки данных, способ обработки данных. воспроизводящее устройство, способ воспроизведения и программа
ES10761654.2T ES2552391T3 (es) 2009-04-07 2010-04-02 Dispositivo de procesamiento de informaciones, método de procesamiento de informaciones, dispositivo de reproducción, método de reproducción y programa
US12/995,305 US8582953B2 (en) 2009-04-07 2010-04-02 Information processing device, information processing method, playing device, playing method, and program
DK10761654.2T DK2288172T3 (en) 2009-04-07 2010-04-02 Device for information processing, method of information processing, reproduction device, reproduction method, and program
MX2010013105A MX2010013105A (es) 2009-04-07 2010-04-02 Dispositivo de registro, metodo de registro, dispositivo de reproduccion, metodo de reproduccion, medio de registro, y programa.
CN201080001711.0A CN102292999B (zh) 2009-04-07 2010-04-02 信息处理设备、信息处理方法、播放设备、播放方法
EP10761654.2A EP2288172B1 (en) 2009-04-07 2010-04-02 Information processing device, information processing method, reproduction device, reproduction method, and program
CA 2724975 CA2724975C (en) 2009-04-07 2010-04-02 Information processing device, information processing method, playing device, playing method, and program
HK12104520A HK1164000A1 (en) 2009-04-07 2012-05-09 Information processing device, information processing method, playing device, and playing method
US13/929,330 US9781402B2 (en) 2009-04-07 2013-06-27 Information processing device, information processing method, playing device, playing method, and program

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2009093159 2009-04-07
JP2009-093159 2009-04-07
JP2010065109A JP4984183B2 (ja) 2009-04-07 2010-03-19 再生装置、再生方法、および記録方法
JP2010-065109 2010-03-19

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US12/995,305 A-371-Of-International US8582953B2 (en) 2009-04-07 2010-04-02 Information processing device, information processing method, playing device, playing method, and program
US13/929,330 Continuation US9781402B2 (en) 2009-04-07 2013-06-27 Information processing device, information processing method, playing device, playing method, and program

Publications (1)

Publication Number Publication Date
WO2010116955A1 true WO2010116955A1 (ja) 2010-10-14

Family

ID=42936239

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/056078 WO2010116955A1 (ja) 2009-04-07 2010-04-02 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム

Country Status (17)

Country Link
US (2) US8582953B2 (ja)
EP (1) EP2288172B1 (ja)
JP (1) JP4984183B2 (ja)
KR (1) KR20120014237A (ja)
CN (4) CN103313071B (ja)
AU (1) AU2010235565B2 (ja)
BR (1) BRPI1002810A2 (ja)
CA (1) CA2724975C (ja)
DK (1) DK2288172T3 (ja)
ES (1) ES2552391T3 (ja)
HK (1) HK1164000A1 (ja)
MX (1) MX2010013105A (ja)
MY (1) MY155528A (ja)
PL (1) PL2288172T3 (ja)
RU (1) RU2523196C2 (ja)
TW (1) TWI444037B (ja)
WO (1) WO2010116955A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761762A (zh) * 2011-04-26 2012-10-31 联发科技股份有限公司 处理视频输入的处理方法与处理装置
WO2013069608A1 (ja) * 2011-11-11 2013-05-16 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4984184B2 (ja) 2009-04-08 2012-07-25 ソニー株式会社 再生装置および再生方法
WO2011118216A1 (ja) * 2010-03-24 2011-09-29 パナソニック株式会社 映像処理装置
US8813116B2 (en) * 2011-04-27 2014-08-19 Morega Systems Inc. Adaptive video server with virtual file system and methods for use therewith
CN104575125B (zh) * 2013-10-10 2017-06-30 北大方正集团有限公司 双音频复读方法和装置
CN103531210B (zh) * 2013-10-16 2017-01-18 广州番禺巨大汽车音响设备有限公司 一种基于音响实现蓝光碟数据读取输出的方法及音响系统
US9819947B2 (en) * 2014-01-02 2017-11-14 Vid Scale, Inc. Methods, apparatus and systems for scalable video coding with mixed interlace and progressive content
CN107465945B (zh) * 2017-09-12 2019-12-03 中广热点云科技有限公司 一种实现iptv播放增强的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11191895A (ja) * 1996-12-04 1999-07-13 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JPH11195287A (ja) 1997-12-27 1999-07-21 Sony Corp フアイル管理装置及びフアイル管理方法
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
JP2008252740A (ja) 2007-03-30 2008-10-16 Sony Corp リモートコマンダおよびコマンド発生方法、再生装置および再生方法、プログラム、並びに、記録媒体
WO2009133714A1 (ja) * 2008-05-01 2009-11-05 パナソニック株式会社 立体視映像を再生するための光ディスク

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
EP2101495B1 (en) 1996-02-28 2012-12-26 Panasonic Corporation High-resolution optical disk for recording stereoscopic video, optical disk reproducing device and optical disk recording device
CN100551013C (zh) * 1997-08-29 2009-10-14 松下电器产业株式会社 光盘、光盘再生装置、光盘记录装置及再生控制信息生成装置
CN1223187C (zh) 1997-08-29 2005-10-12 松下电器产业株式会社 记录高质量图像或标准图像的光盘及其记录和再生装置
US6222837B1 (en) * 1997-09-26 2001-04-24 Lucent Technologies Inc. Internet service via ISDN
JP3948979B2 (ja) * 2002-02-18 2007-07-25 パイオニア株式会社 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
KR100563685B1 (ko) * 2002-02-25 2006-03-28 엘지전자 주식회사 재기록 가능 기록매체의 재생리스트 관리방법
JP3770249B2 (ja) * 2002-07-04 2006-04-26 ソニー株式会社 多重化装置及び方法
CN101118772B (zh) * 2004-08-17 2010-04-14 Lg电子株式会社 配置组合文件结构的方法、以及再现数据的方法和装置
CN101872637B (zh) * 2004-12-01 2013-02-27 松下电器产业株式会社 再现装置和再现方法
US20080056678A1 (en) * 2006-04-18 2008-03-06 Kim Kun S Apparatus for reproducing data, method thereof, apparatus for recording the same, method thereof and recording medium
RU2315439C1 (ru) * 2006-07-03 2008-01-20 Борис Иванович Волков Система объемной видеозаписи и воспроизведения
RU2334370C1 (ru) * 2007-03-23 2008-09-20 Борис Иванович Волков Система стереотелевидения
MY162861A (en) * 2007-09-24 2017-07-31 Koninl Philips Electronics Nv Method and system for encoding a video data signal, encoded video data signal, method and system for decoding a video data signal
AU2009205250B2 (en) * 2008-01-17 2013-02-21 Panasonic Corporation Recording medium on which 3D video is recorded, recording medium for recording 3D video, and reproducing device and method for reproducing 3D video
KR101506217B1 (ko) * 2008-01-31 2015-03-26 삼성전자주식회사 스테레오스코픽 영상의 부분 데이터 구간 재생을 위한스테레오스코픽 영상 데이터스트림 생성 방법과 장치, 및스테레오스코픽 영상의 부분 데이터 구간 재생 방법과 장치
US20090202227A1 (en) * 2008-02-13 2009-08-13 Samsung Electronics Co., Ltd. Method and apparatus for recording data, method and apparatus for reproducing data, and recording medium for recording data
ES2467149T3 (es) 2009-02-19 2014-06-12 Panasonic Corporation Dispositivo de reproducción y medio de grabación
JPWO2010098134A1 (ja) * 2009-02-27 2012-08-30 パナソニック株式会社 記録媒体、再生装置、及び集積回路

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11191895A (ja) * 1996-12-04 1999-07-13 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JPH11195287A (ja) 1997-12-27 1999-07-21 Sony Corp フアイル管理装置及びフアイル管理方法
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
JP2008252740A (ja) 2007-03-30 2008-10-16 Sony Corp リモートコマンダおよびコマンド発生方法、再生装置および再生方法、プログラム、並びに、記録媒体
WO2009133714A1 (ja) * 2008-05-01 2009-11-05 パナソニック株式会社 立体視映像を再生するための光ディスク

Non-Patent Citations (1)

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

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761762A (zh) * 2011-04-26 2012-10-31 联发科技股份有限公司 处理视频输入的处理方法与处理装置
CN102761762B (zh) * 2011-04-26 2014-11-19 联发科技股份有限公司 处理视频输入的处理方法与处理装置
US8908010B2 (en) 2011-04-26 2014-12-09 Mediatek Inc. Method for processing video input by detecting if picture of one view is correctly paired with another picture of another view for specific presentation time and related processing apparatus thereof
WO2013069608A1 (ja) * 2011-11-11 2013-05-16 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US9693033B2 (en) 2011-11-11 2017-06-27 Saturn Licensing Llc Transmitting apparatus, transmitting method, receiving apparatus and receiving method for transmission and reception of image data for stereoscopic display using multiview configuration and container with predetermined format

Also Published As

Publication number Publication date
DK2288172T3 (en) 2015-11-16
CN102292999A (zh) 2011-12-21
HK1164000A1 (en) 2012-09-14
MY155528A (en) 2015-10-30
US20130287367A1 (en) 2013-10-31
KR20120014237A (ko) 2012-02-16
PL2288172T3 (pl) 2016-01-29
EP2288172A4 (en) 2013-07-03
CA2724975A1 (en) 2010-10-14
CN103327354A (zh) 2013-09-25
CA2724975C (en) 2014-02-04
CN102292999B (zh) 2014-05-28
TW201105114A (en) 2011-02-01
RU2010149063A (ru) 2012-06-10
CN103313071B (zh) 2016-01-20
EP2288172B1 (en) 2015-10-14
ES2552391T3 (es) 2015-11-27
CN103327354B (zh) 2015-12-23
AU2010235565B2 (en) 2015-08-13
MX2010013105A (es) 2010-12-21
BRPI1002810A2 (pt) 2016-02-23
TWI444037B (zh) 2014-07-01
CN102655014A (zh) 2012-09-05
JP4984183B2 (ja) 2012-07-25
US8582953B2 (en) 2013-11-12
US9781402B2 (en) 2017-10-03
CN102655014B (zh) 2015-09-09
JP2010263612A (ja) 2010-11-18
EP2288172A1 (en) 2011-02-23
RU2523196C2 (ru) 2014-07-20
US20110116762A1 (en) 2011-05-19
AU2010235565A1 (en) 2010-10-14
CN103313071A (zh) 2013-09-18

Similar Documents

Publication Publication Date Title
JP4993224B2 (ja) 再生装置および再生方法
JP4984183B2 (ja) 再生装置、再生方法、および記録方法
JP5267886B2 (ja) 再生装置、記録媒体、および情報処理方法
JP4962525B2 (ja) 再生装置、再生方法、およびプログラム
JP2010244630A (ja) 情報処理装置、情報処理方法、プログラム、及び、データ構造
JP2010245970A (ja) 再生装置、再生方法、およびプログラム
WO2010150674A1 (ja) 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム
JP4984184B2 (ja) 再生装置および再生方法
JP4984187B2 (ja) 記録方法
JP4984195B2 (ja) 再生装置、再生方法、および記録方法
JP2010244629A (ja) 情報処理装置、情報処理方法、プログラム、および記録媒体
JP4984192B2 (ja) 記録方法
JP4984194B2 (ja) 記録方法
JP4993233B2 (ja) 記録方法
JP4984193B2 (ja) 再生装置、再生方法、および記録方法
JP4993234B2 (ja) 再生装置、再生方法、および記録方法
JP2010244635A (ja) 情報処理装置、情報処理方法、再生装置、再生方法、プログラム、および記録媒体
JP2010245916A (ja) 情報処理装置、情報処理方法、およびプログラム

Legal Events

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

Ref document number: 201080001711.0

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2724975

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20107026769

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 12995305

Country of ref document: US

Ref document number: 2010149063

Country of ref document: RU

Ref document number: 7723/CHENP/2010

Country of ref document: IN

Ref document number: MX/A/2010/013105

Country of ref document: MX

Ref document number: 2010761654

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10761654

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010235565

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2010235565

Country of ref document: AU

Date of ref document: 20100402

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: PI1002810

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20101130