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

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

Info

Publication number
WO2010150674A1
WO2010150674A1 PCT/JP2010/060014 JP2010060014W WO2010150674A1 WO 2010150674 A1 WO2010150674 A1 WO 2010150674A1 JP 2010060014 W JP2010060014 W JP 2010060014W WO 2010150674 A1 WO2010150674 A1 WO 2010150674A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
information
file
video stream
field
Prior art date
Application number
PCT/JP2010/060014
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
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to BRPI1004339A priority Critical patent/BRPI1004339A2/pt
Priority to RU2011106492/08A priority patent/RU2530347C2/ru
Priority to EP10791992.0A priority patent/EP2309763B1/en
Priority to CA2732023A priority patent/CA2732023C/en
Priority to MX2011001760A priority patent/MX2011001760A/es
Priority to US13/059,194 priority patent/US9454996B2/en
Priority to CN201080002327.2A priority patent/CN102124747B/zh
Priority to MYPI2011000697A priority patent/MY181831A/en
Publication of WO2010150674A1 publication Critical patent/WO2010150674A1/ja
Priority to HK12100395.7A priority patent/HK1160314A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/3027—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording used signal is digitally coded
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189—Recording image signals; Reproducing recorded image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H04N5/77—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television camera
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8211—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a sound signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8233—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a character code signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction

Definitions

  • 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, an information processing method, a playback device, and a program capable of appropriately playing back 3D image content.
  • the present invention relates to a playback method and a program.
  • 3D (3D) image content that can be viewed stereoscopically has attracted attention.
  • various methods for displaying 3D images such as a method for alternately displaying left-eye images and right-eye images. Regardless of which method is used, the amount of 3D image data Is larger than the data amount of the 2D image.
  • a large-capacity recording medium is required to record high-resolution content such as movies as 3D images with a large amount of data.
  • Such a large-capacity recording medium includes, for example, Blu-Ray (registered trademark) Disc (hereinafter referred to as BD as appropriate) such as BD-ROM.
  • Blu-Ray (registered trademark) Disc hereinafter referred to as BD as appropriate
  • BD-ROM Blu-Ray (registered trademark) Disc
  • 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 makes it possible to appropriately reproduce 3D image content from a recording medium such as a BD.
  • An information processing apparatus includes a first field defined in an extension field of a PlayList that is information for controlling content reproduction, a field that describes information related to a sub reproduction path, and a stream
  • the second field which is a field in which information relating to the number is described, is used to refer to the extension stream among the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method.
  • the base stream and the extension stream are a Base view Depend video stream and a Dependent view video stream generated by encoding a video stream by an H.264 AVC / MVC encoding method, respectively, and the setting Means for specifying the sub playback path includes information indicating that the type of the sub playback path is a path referring to the stream of the Dependent view ⁇ video, and attribute information of the stream of the Dependent ⁇ view video.
  • the file name of a certain clip information file can be set in the first field.
  • the base stream and the extension stream are a Base view Depend video stream and a Dependent view video stream generated by encoding a video stream by an H.264 AVC / MVC encoding method, respectively, and the setting The means can set the ID of the sub reproduction path as information specifying the sub reproduction path and the PID of the transport packet of the DependentDependview video stream in the second field.
  • An information processing method includes a first field defined in an extension field of a PlayList that is information for controlling content reproduction, a field that describes information related to a sub reproduction path, and a stream
  • the second field which is a field in which information relating to the number is described, is used to refer to the extension stream among the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method. Setting information for designating a sub reproduction path to be performed and information for designating the PID of the transport packet of the extension stream.
  • the program according to one aspect of the present invention relates to a first field that is defined in an extension field of a PlayList that is information for controlling reproduction of content and is a field in which information related to a sub reproduction path is described, and a stream number.
  • a sub that refers to the extended stream
  • a computer is caused to execute a process including a step of setting information specifying a reproduction path and information specifying a PID of a transport packet of the extension stream.
  • a playback apparatus includes a first field defined in an extension field of PlayList, which is information for controlling playback of content, and a field in which information relating to a sub playback path is described, and a stream The extension stream of the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method set in the second field that is a field in which information on the number is described Control means for controlling reproduction of the extended stream based on information designating a sub reproduction path to be referred to and information designating PID of the transport packet of the extended stream.
  • the base stream and the extension stream are a Base view video stream and a Dependent view video stream generated by encoding a video stream by an H.264 H AVC / MVC encoding method, respectively, and the control
  • the means controls the playback of the Dependent view video stream, and the main playback path refers to the Base view video stream set in a field describing information on the main playback path in the PlayList.
  • the playback control of the Base view video stream performed based on the information specifying the PID of the transport packet of the Base view video stream.
  • a playback method includes a first field defined in an extension field of a PlayList that is information for controlling content playback, a field that describes information related to a sub playback path, and a stream.
  • the extension stream of the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method set in the second field that is a field in which information on the number is described
  • a step of controlling reproduction of the extended stream based on information designating a sub reproduction path to be referred to and information designating PID of a transport packet of the extended stream.
  • a program includes a first field defined in an extension field of PlayList, which is information for controlling reproduction of content, and a field in which information relating to a sub reproduction path is described, and a stream number Reference is made to the extension stream of the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method set in the second field that is a field in which information on the information is described And causing the computer to execute processing including a step of controlling reproduction of the extended stream based on information designating the sub reproduction path to be performed and information designating PID of the transport packet of the extended stream.
  • a first field defined in an extension field of PlayList which is information for controlling playback of content, is a field describing information related to a sub playback path, and information related to a stream number.
  • Sub-playback that refers to the extension stream of the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method using the second field that is a field in which the extension stream is described
  • Information specifying the path and information specifying the PID of the transport packet of the extension stream are set.
  • a first field which is a field in which information related to a sub playback path is defined, defined in an extension field of a PlayList that is information for controlling content playback, and a stream number Reference is made to the extension stream of the basic stream and the extension stream generated by encoding the video stream by a predetermined encoding method set in the second field that is a field in which information is described.
  • the reproduction of the extension stream is controlled based on the information specifying the sub playback path and the information specifying the PID of the transport packet of the extension stream.
  • 3D image content can be appropriately reproduced.
  • FIG. 1 It is a figure which shows the structural example of the reproduction
  • FIG. 24 is a flowchart for describing playback processing performed in accordance with the PlayList file of FIG. 23.
  • FIG. It is a figure which shows the syntax of chunk_map (). It is a figure which shows the specific example of chunk_map (). It is a figure which shows the example of separation of data. It is a figure which shows the syntax of EP_map ().
  • FIG. 32 is a flowchart for describing playback processing performed according to the PlayList file of FIG. 31.
  • FIG. It is a figure which shows the further another example of a PlayList file. It is a figure which shows the syntax of a clpi file. It is a figure which shows the concept of file management.
  • FIG. 35 is a flowchart for describing playback processing performed according to the PlayList file of FIG. 34.
  • FIG. It is a figure which shows the example of a PlayList file. It is a figure which shows the syntax of a clpi file.
  • FIG. 1 is a diagram showing a configuration example of a reproduction system including a reproduction apparatus 1 to which the present invention is applied.
  • This playback system is configured by connecting the playback device 1 and the display device 3 with an HDMI (High Definition Multimedia Interface) cable or the like.
  • the reproducing apparatus 1 is loaded with an optical disc 2 such as a BD-ROM, which is a BD standard optical disc.
  • a stream necessary for displaying a 3D image having two viewpoints is recorded.
  • H.264 ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ AVC Advanced ⁇ ⁇ ⁇ ⁇ ⁇ Video ⁇ ⁇ ⁇ Coding
  • MVC Multi-view Video coding
  • the playback device 1 is a player that supports 3D playback of a stream recorded on the optical disc 2.
  • the playback device 1 plays back a stream recorded on the optical disc 2 and displays a 3D image obtained by playback on the display device 3 including a television receiver.
  • the sound is reproduced by the reproducing apparatus 1 and output from a speaker or the like provided in the display apparatus 3.
  • the playback apparatus 1 supports 2D playback in the same way as a conventional BD player.
  • 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 with an L image (left viewpoint) camera and an R (right viewpoint) image camera on the same subject.
  • 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 includes an H.264 / AVC encoder 11, an H.264 / AVC decoder 12, a dependent video encoder 13, and a multiplexer 14.
  • the L image stream shot by the L image camera is input to the H.264 / AVC encoder 11. Also, the stream of the R image captured by the R image camera is input to the Dependent view video encoder 13.
  • the H.264 / AVC encoder 11 encodes the L image stream, for example, as an H.264 AVC / High Profile video stream.
  • the H.264 / AVC encoder 11 outputs the AVC video stream obtained by encoding to the H.264 / AVC decoder 12 and the multiplexer 14 as a Base view video stream.
  • the H.264 / AVC decoder 12 decodes the AVC video stream supplied from the H.264 / AVC encoder 11 and outputs the L image stream obtained by decoding to the Dependent view video encoder 13.
  • the Dependent view13 video encoder 13 encodes the L image stream supplied from the H.264 / AVC decoder 12 and the R image stream input from the outside, and outputs a Dependent view 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 13 outputs to the multiplexer 14 the Dependent view ⁇ ⁇ video stream obtained by encoding using such prediction between views.
  • the multiplexer 14 multiplexes the Baseview video stream supplied from the H.264 / AVC encoder 11 and the Dependent view video stream supplied from the Dependent view video encoder 13 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 14 outputs the generated TS (MPEG2 TS).
  • the TS output from the multiplexer 14 is recorded on the optical disc 2 in the recording device together with other management data, and provided to the reproducing device 1.
  • the L image is encoded as Base view video and the R image is encoded as Dependent view ⁇ video by the MVC method.
  • the R image is encoded as Base view video and the L image is encoded as Dependent view video. You may do it.
  • the L image is encoded as Base view video and the R image is encoded as Dependent view video will be described.
  • the playback device 1 When the 3D playback is performed according to a user instruction or the like, the playback device 1 reads the Base ⁇ view ⁇ video stream and the Dependent view video stream from the optical disc 2 and plays back.
  • the playback device 1 reads only the Base view video stream from the optical disc 2 and plays it back. Since 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 recorded on the optical disc 2.
  • 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 that is one TS together with the Base view video stream.
  • Main TS is a TS including at least Base view video stream.
  • Sub-TS is a TS that includes a stream other than the Base-view video stream and is used together with the Main TS during playback.
  • Sub TS is appropriately recorded on the optical disc 2.
  • PG Presentation Graphics
  • IG Interactive Graphics
  • Base view and Dependent view streams are prepared so that 3D display is possible as with video. .
  • FIG. 6 is a diagram showing another configuration example of the TS recorded on the optical disc 2.
  • 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 view video stream may be included in a different TS from the Base view video stream.
  • the respective TS files are interleaved and recorded on the optical disc 2.
  • FIG. 7 is a diagram illustrating an arrangement example of the TS file including the Base view video stream (L video stream) and the TS file including the Dependent view video stream (R video stream) on the optical disc 2.
  • the TS file including the L video stream and the TS file including the R video stream are arranged in an interleaved manner so as to be alternately arranged for each predetermined data unit, and are recorded on the optical disc 2.
  • a collection of source packets belonging to one TS file and continuously arranged on the optical disc 2 is called a chunk.
  • each block indicated by the letter “R” and a number represents a chunk of R video
  • each block indicated by a letter “L” and a number represents a chunk of L video.
  • R [0], L [0], R [1], L [1], R [2], L [2], R [3], L [3], R [4] , L [4], R [5], L [5],... are read from the optical disc 2 in this order, and L [0], R [0], L [1], R [1], L [ 2], R [2], L [3], R [3], L [4], R [4], L [5], R [5],.
  • L ⁇ video referenced at the time of encoding needs to be decoded first.
  • R video chunks and L video chunks with the same numbers are data required for playback at the same time, and are used as a set during 3D playback.
  • the L video data for the playback time from time t1 to t2 is divided as chunk L [1], and the L video data for the playback time from time t2 to the playback end time Is divided as chunk L [2].
  • the R video data necessary for the playback time from the playback start time to time t1 is divided into chunks R [0].
  • R ⁇ ⁇ video data for the playback time from time t1 to t2 is divided as chunk R [1]
  • the chunks obtained by dividing in this way are arranged so that the chunks with the same numbers are arranged in the order of the R video chunk and the L video chunk, and are recorded on the optical disc 2.
  • the TS file is recorded on the optical disc 2 without being interleaved.
  • FIG. 8 is a diagram showing an example of an AV stream management structure by the playback apparatus 1.
  • the AV stream management is performed using two layers, PlayList and Clip, as shown in FIG.
  • the AV stream may be recorded not in the optical disc 2 but in the local storage of the playback device 1.
  • the Clip is composed of an AV stream that is a TS obtained by multiplexing video data and audio data, and corresponding Clip Information (Clip Information including attribute information regarding the AV stream).
  • the AV stream is developed on the time axis, and each access point is mainly designated in the PlayList with a time stamp. Clip Information is used to find the address where decoding in the AV stream 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.
  • 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 control information for controlling playback of the AV stream.
  • a playback path created by an array of one or more PlayItems in a PlayList is called a main path.
  • a playback path composed of an array of one or more SubPlayItems in parallel with the Main Path is called a sub path (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 L video stream is referred to by PlayItems constituting Main Path.
  • the R video stream is referred to by SubPlayItems that make up Sub Path (Sub Path in Extension () described later).
  • the PlayList in FIG. 9 has one Main path and three Sub paths composed of a sequence of three PlayItems. IDs are set in order from the top of the PlayItems constituting the main path. An ID is also set for each Sub-Path.
  • AV stream management using PlayList, PlayItem, and SubPlayItem is described in, for example, Japanese Patent Application Laid-Open 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 2.
  • files are managed hierarchically by a directory structure.
  • One root directory is created on the optical disc 2.
  • Under the root directory is a range managed by one recording / reproducing system.
  • BDMV directory is placed under the root directory. Immediately under the BDMV 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.
  • PLAYLIST directory CLIPINF directory, STREAM directory, etc. are provided under the BDMV directory.
  • PlayList file that is a file describing a PlayList is stored.
  • Each PlayList file has a name that is a combination of a 5-digit number and an extension “.mpls”.
  • the file name “00000.mpls” is set.
  • a Clip Information file which is a file describing Clip Information, is stored.
  • Each Clip Information file is set with a name combining a five-digit number and the extension “.clpi”.
  • the file names “00001.clpi” and “00002.clpi” are set in the two Clip Information files in FIG. 10, respectively.
  • the Clip Information file is referred to as a clpi file as appropriate.
  • the clpi file “00001.clpi” is a file in which information about the corresponding L video stream is described
  • the clpi file “00002.clpi” is a file in which information about the corresponding R video stream is described.
  • 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 referred to as an m2ts file
  • a file with the extension “.ilvt” is referred to as an ilvt file.
  • the m2ts file of“ 00001.m2ts ” is the L video stream file
  • the m2ts file of“ 00002.m2ts ” is the R video stream file.
  • the “00001.ilvt” ilvt file is a file for managing 3D playback and managing the L2 video stream m2ts file and the R2 video stream m2ts file when they are interleaved. Therefore, when the L video stream and the R video stream are included in one TS and their m2ts files are not interleaved, the ilvt file is not recorded on the optical disc 2.
  • a directory for storing audio stream files is also provided under the BDMV directory.
  • the file name of the m2ts file that constitutes the clip related to L video is “00001.m2ts”, and the file name of the clpi file is “00001.clpi”. Further, the file name of the m2ts file constituting the Clip relating to R video is “00002.m2ts”, and the file name of the clpi file is “00002.clpi”. The same number is included in the file name of the m2ts file and the file name of the clpi file constituting one Clip.
  • the file name of the ilvt file includes “00001”, which is the same as the 5-digit number included in the file name of the m2ts file and the file name of the clpi file that make up the clip related to L video.
  • the file name of the ilvt file that is specified when performing 3D playback can be specified from the file name of the clpi file that constitutes the Clip related to L video.
  • FIG. 11 is a diagram illustrating the syntax of the PlayList file.
  • a number indicating the number of rows and “:” are shown on the left side of FIG.
  • the number representing the number of lines and “:” do not constitute a PlayList.
  • the main description of the PlayList will be described, and detailed description thereof will be omitted. Details are described in, for example, Blu-ray Disc Read Only Format part3.
  • Yyyy.mpls in the first line represents the file name of this PlayList file.
  • the PlayList file is roughly composed of fields of AppInfoPlayList (), PlayList (), PlayListMark (), and ExtensionData ().
  • PlayListMark () on the fourth line information related to a mark that is a jump destination by a user operation commanding a chapter jump or the like or a command is described.
  • AppInfoPlayList () includes MVC_flag, which is a 1-bit flag indicating whether or not information related to MVC playback (3D playback) is included in the PlayList. Note that MVC_flag may be included in a stream such as a video stream instead of being included in the PlayList.
  • FIG. 12 is a diagram showing the meaning of MVC_flag.
  • MVC_flag 1 indicates that information related to 3D playback is included in the PlayList.
  • AppInfoPlayList includes information on the type of PlayList such as whether it is a PlayList for performing random playback.
  • the 12th to 25th lines are PlayList () fields.
  • the number_of_PlayItems on the 13th line represents the number of PlayItems in the PlayList. In the example of FIG. 9, the number of PlayItems is 3.
  • the value of PlayItem_id is assigned from 0 in the order in which PlayItem () appears in the PlayList. In the for statement on the 15th to 19th lines, PlayItem () is referred to by the number of PlayItems.
  • the number_of_SubPaths on the 14th line represents the number of Sub-Paths in PlayList ().
  • the number of Sub-Paths is 3.
  • the value of SubPath_id is assigned from 0 in the order in which SubPath () appears in PlayList ().
  • SubPath () is referred to by the number of Sub Paths.
  • Lines 26 to 33 are descriptions of PlayItem () included in PlayList ().
  • Clip_Information_file_name on line 27 represents the name of the Clip clpi file including the AV stream referred to by PlayItem.
  • MVC_file_type on the 28th line is 2-bit data having a valid value when the value of MVC_flag is 1, and represents the file type of the supply source of each of the L video stream and the R video stream.
  • FIG. 13 is a diagram showing the meaning of MVC_file_type.
  • the value of MVC_file_type being 0 indicates that the L video stream and the R video stream are included in one TS, and the m2ts file that manages the TS is indicated by Clip_Information_file_name. To express.
  • Clip_Information_file_name also indicates the file name of the corresponding m2ts file that constitutes the same Clip as the clpi file in which the file name is set.
  • An MVC_file_type value of 1 means that the L2 video stream m2ts file (first TS file) indicated by Clip_Information_file_name and the R2 video stream m2ts file (second TS file) are interleaved on the optical disc 2. Represents that In this case, the L video stream and the R video stream are included in different TSs.
  • MVC_file_type 2 indicates that either or both of the m2ts file of the L video stream and the m2ts file of the R video stream indicated by Clip_Information_file_name are recorded in the local storage in the playback apparatus 1.
  • the value 3 of MVC_file_type is a reserved value.
  • IN_time on the 30th line represents the start position of the playback section of PlayItem
  • OUT_time on the 31st line represents the end position
  • the STN_table () on line 32 contains AV stream information referenced by PlayItem.
  • the AV stream information referred to by PlayItem includes the stream number (ID) and the PID of the transport packet constituting the L video stream.
  • the 34th to 40th lines are the description of SubPath () included in PlayList ().
  • the SubPath () in the 34th to 40th lines includes information related to video data other than R ⁇ video and information related to audio data that are reproduced together with the AV stream referred to by PlayItem.
  • the SubPath_type on the 35th line is 8-bit data indicating the type of Sub-Path.
  • FIG. 14 is a diagram showing the meaning of SubPath_type.
  • Lines 41 to 45 are the description of SubPlayItem () included in SubPath ().
  • Clip_Information_file_name on the 42nd line represents the name of the clpi file of the Clip referred to by SubPlayItem.
  • the SubPlayItem_IN_time on the 43rd line represents the start position of the playback section of the SubPlayItem
  • the SubPlayItem_OUT_time on the 44th line represents the end position
  • ExtensionData which is an extension field.
  • SubPath_entries_extension () and STN_table_extension () are described in ExtensionData ().
  • SubPath_entries_extension () and STN_table_extension () include information on the R video stream used for 3D playback together with the L video stream referenced by PlayItem.
  • the R video stream is managed as a stream referenced by SubPath.
  • the information about the R video stream is not described in the field of SubPath () (34th line in FIG. 11), but the field of ExtensionData (). Described in
  • ExtensionData Information related to the R video stream is described as ExtensionData (), and such a problem occurs when a player that supports 3D playback reads it only when performing 3D playback. It becomes possible to prevent.
  • FIG. 15 is a diagram illustrating an example of the syntax of SubPath_entries_extension () included in ExtensionData ().
  • “Number_of_SubPath_extensions” is 16-bit data representing the number of SubPath_extensions, that is, the number of SubPath_extension () appearing in SubPath_entries_extension (). In the for statement following number_of_SubPath_extensions, SubPath_extension () is referred to by the number of SubPaths.
  • the SubPath referring to the R video stream also has the same ID as the normal SubPath referring to video data and audio data other than R video, in which information is described in the SubPath () on the 34th line in FIG. Allocated.
  • FIG. 16 is a diagram illustrating an example of the syntax of SubPath_extension () in FIG.
  • “Length” is 32-bit data indicating the number of bytes from immediately after the length field to the end of SubPath_extension ().
  • SubPath_type_extension is an extension of SubPath_type, and is 8-bit data indicating the type of SubPath in which information is described in SubPath_extension ().
  • FIG. 17 is a diagram illustrating the meaning of SubPath_type_extension.
  • the values 0 to 7 of SubPath_type_extension represent the same meaning as the meanings of 0 to 7 of SubPath_type in FIG. 14, respectively.
  • number_of_SubPlayItems is 8-bit data indicating the number of SubPlayItems in SubPath_extension ().
  • SubPlayItem () is referred to by the number of SubPlayItems.
  • SubPlayItem () in SubPath_extension () is the same as the description of SubPlayItem () shown from the 41st line to the 45th line in FIG.
  • SubPlayItem () in SubPath_extension () includes Clip_Information_file_name indicating the file name of the clpi file included in the same Clip as the R video stream referenced by SubPlayItem. Further, SubPlayItem_IN_time representing the start position of the playback section and SubPlayItem_OUT_time representing the end position are included.
  • FIG. 18 is a diagram illustrating an example of the syntax of STN_table_extension () included in ExtensionData ().
  • the STN_table (the 32nd line in FIG. 11) includes the PIDs of transport packets constituting the L video stream referenced by the PlayItem.
  • STN_table_extension () includes the PIDs of transport packets constituting the R video stream referenced by SubPath (SubPath_extension).
  • STN_table_extension following length indicating the length of STN_table_extension (), stream_entry () and stream_attributes (), which is attribute information of the R video stream, are provided as information about the R video stream. included.
  • FIG. 19 is a diagram illustrating an example of the syntax of stream_entry ().
  • stream_entry () includes a type that is 8-bit information following length indicating the length of stream_entry ().
  • the value of type being 1 indicates that the R video stream is included in one TS together with the L video stream referenced by PlayItem. Further, the value of type of 2 at least indicates that the R video stream is included in a different TS from the L video stream referenced by PlayItem.
  • ref_to_stream_PID_of_mainClip represents the PID of the transport packet included in one TS together with the L video stream and constituting the R video stream.
  • ref_to_SubPath_id represents the ID of SubPath (SubPath_extension) that refers to the R video stream.
  • ref_to_stream_PID_of_subClip represents the PID of the transport packet that constitutes the R video stream referenced by the SubPath identified by ref_to_SubPath_id.
  • each PlayItem () includes IN_time indicating the start position of the PlayItem playback section and OUT_time indicating the end position (lines 30 and 31 in FIG. 11).
  • SubPlayItem () in SubPath_extension () includes SubPlayItem_IN_time representing the start position of the playback section and SubPlayItem_OUT_time representing the end position for each SubPlayItem constituting the SubPath referring to the R video stream. included.
  • the start position and end position of the PlayItem and the start position and end position of the SubPlayItem referring to the R video stream associated with the L video stream referenced by the PlayItem are the same position.
  • ExtensionData which is an extension field
  • SubPath which is a field describing information about SubPath, as SubPath_extension (), and also relates to the stream number (STream (Number).
  • STN_table which is a field in which information is described, is defined as STN_table_extension ().
  • FIG. 21 is a block diagram illustrating a configuration example of the playback device 1.
  • the controller 31 executes a control program prepared in advance and controls the overall operation of the playback device 1.
  • the disk drive 32 reads data from the optical disk 2 under the control of the controller 31 and outputs the read data to the controller 31, the memory 33, or the decoding unit 36.
  • the memory 33 appropriately stores data necessary for the controller 31 to execute various processes.
  • the local storage 34 is composed of an HDD (Hard Disk Drive), for example.
  • an R video stream downloaded from the server 22 is recorded.
  • the stream recorded in the local storage 34 is also supplied to the decoding unit 36 as appropriate.
  • the Internet interface 35 communicates with the server 22 via the network 21 in accordance with control from the controller 31 and supplies data downloaded from the server 22 to the local storage 34.
  • data for updating the data recorded on the optical disc 2 is downloaded.
  • it is also possible to perform 3D playback of content by using the downloaded R video stream together with the L video stream recorded on the optical disc 2.
  • the decoding unit 36 decodes the stream supplied from the disk drive 32 or the local storage 34 and outputs the obtained video signal to the display device 3. An audio signal is also output to the display device 3 via a predetermined path.
  • the operation input unit 37 includes an input device such as a button, a key, a touch panel, 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 37 detects a user operation and supplies a signal representing the content of the detected operation to the controller 31.
  • FIG. 22 is a diagram illustrating a configuration example of the decoding unit 36.
  • the separation unit 51 separates the data supplied from the disk drive 32 into Main TS data and Sub TS data according to control by the controller 31.
  • the separation unit 51 outputs and stores the separated Main TS data to the read buffer 52, and outputs and stores the Sub TS data to the read buffer 55. Further, the separation unit 51 outputs and stores the Sub-TS data supplied from the local storage 34 to the read buffer 55.
  • the PID filter 53 sorts the Main TS transport packet composed of the data stored in the read buffer 52 based on the PID. From the controller 31, based on the STID_table () of the PlayList (line 32 in FIG. 11), the PID of the transport packet constituting the L video stream, and the ref_to_stream_PID_of_mainClip (FIG. 19) of the STN_table_extension () The specified PID of the transport packet constituting the R video stream is specified.
  • the PID filter 53 reads the transport packet of the L video stream from the read buffer 52, outputs it to the ES buffer 54, and stores it.
  • the ES buffer 54 stores an L (video) ES (Elementary Stream).
  • the PID filter 53 extracts the transport packet of the R video stream based on the PID, and outputs the transport packet to the switch 57.
  • the PID filter 56 reads the transport packet of the R video stream included in the Sub TS from the read buffer 55 and outputs it to the switch 57.
  • the controller 31 designates the PID of the transport packet constituting the R video stream, which is specified based on ref_to_stream_PID_of_subClip (FIG. 19) of STN_table_extension ().
  • graphics data such as PG and IG may be multiplexed in the Main TS.
  • graphics data such as PG and IG may be multiplexed in Sub TS.
  • the PID filter 53 and the PID filter 56 appropriately sort out 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 53 and the PID filter 56 in FIG.
  • the switch 57 outputs the transport packet of the R video stream included in the Main TS supplied from the PID filter 53 to the ES buffer 58 and stores it. Also, the switch 57 outputs the transport packet of the R video stream supplied from the PID filter 56 and included in the Sub video TS to the ES buffer 58 to be stored.
  • the ES buffer 58 stores the ES of R video.
  • the switch 59 outputs, to the decoder 60, a packet to be decoded among the L video packet stored in the ES buffer 54 and the R video packet stored in the ES buffer 58.
  • Time information such as DTS (Decoding Time Stamp) is set in the PES packet of L video and R video, and reading from the buffer is performed based on the time information.
  • the decoder 60 decodes the packet supplied from the switch 59 and outputs a video signal of L video or R video obtained by decoding.
  • FIG. 23 is a diagram illustrating a specific example of the PlayList file.
  • FIG. 23 shows a part of the information shown in FIG. The same applies to a specific example of a PlayList file to be described later.
  • the PlayList file in FIG. 23 is a PlayList file that controls 3D playback when the L video stream and the R video stream are included in different TSs, and these TS files are interleaved and recorded on the optical disc 2.
  • the Clip_Information_file_name of PlayItem () is “00001”. From this description, the clpi file constituting the clip of L video is specified. Further, the start position and end position of the PlayItem playback section are specified from IN_time and OUT_time of PlayItem (), respectively, and the PID of the transport packet constituting the L video stream is specified from STN_table ().
  • ExtensionData information related to the SubPath referring to the R video stream is described.
  • SubPath_extension 8 is set, which represents a SubPath referring to the R video stream.
  • the Clip_Information_file_name of SubPlayItem () of ExtensionData () is “00002”. From this description, the clpi file constituting the clip of R video is specified. Also, the start position and end position of the playback section of SubPlayItem are specified from SubPlayItem_IN_time and SubPlayItem_OUT_time of SubPlayItem ().
  • the type value of STN_table_extension () is 2.
  • FIG. 24 is a diagram showing the syntax of the clpi file.
  • FIG. 24A shows an example of a clpi file “00001.clpi”.
  • Numberer_of_source_packets1 represents the number of source packets included in the m0000 file of “00001.m2ts”.
  • EP_map contains the location information of the entry point (EP) set in the TS included in the m2ts file of “00001.m2ts”.
  • the chunk_map () contains the location information of each chunk of the “00001.m2ts” m2ts file.
  • the position of each chunk is represented by, for example, Source Packet Number (SPN).
  • SPN Source Packet Number
  • FIG. 24B shows an example of a clpi file “00002.clpi”.
  • the "00002.clpi" clpi file also contains number_of_source_packets2, EP_map, and chunk_map () that represent the number of source packets contained in the "00002.m2ts" m2ts file, as well as the "00001.clpi” clpi file It is.
  • FIG. 25 is a diagram showing the concept of file management.
  • management of files that are interleaved and recorded on the optical disc 2 is performed in a three-layer structure of a physical layer, a file system layer, and an application layer.
  • the PlayList file in FIG. 23 and the clpi file in FIG. 24 become application layer information handled by an application that manages content reproduction.
  • the physical layer is the layer of the optical disc 2 on which the m2ts file of the L video stream and the m2ts file of the R video stream are recorded by being interleaved.
  • the stream file (m2ts file, ilvt file) designated by the application is associated with the position on the optical disc 2 of the extent constituting each stream file.
  • the file system is, for example, UDF file system.
  • “Extent” refers to a collection of data continuously arranged on the optical disc 2 among all data managed by a specific file.
  • L [0] and L [1] are extents.
  • an m2ts file of “00001.m2ts” is designated by the application as a read file, the positions of L [0] and L [1] on the optical disc 2 are specified by UDF file system and read by the disc drive 32 .
  • R [0] and R [1] are extents.
  • the positions of R [0] and R [1] on the optical disk 2 are specified by UDF file system and read by the disk drive 32. .
  • R [0], L [0], R [1], and L [1] are one extent.
  • an ilvt file of “00001.ilvt” is specified by the application as a read file, the position of R [0], L [0], R [1], L [1] on the optical disk 2 is specified by UDF file system And read by the disk drive 32.
  • the controller 31 (an application that is executed in the controller 31 and manages content playback) starts 3D playback in response to an operation performed on the operation unit 37 by the user.
  • step S1 the controller 31 specifies the PID of the transport packet of Main TS that constitutes the L video stream from the description of STN_table ().
  • step S3 the controller 31 specifies the file name of the clpi file corresponding to the m2ts file of the Main TS including the L video stream as “00001.clpi” from the Clip_Information_file_name in PlayItem ().
  • step S5 the controller 31 includes the same five characters as the number (00001) included in the file name of the file constituting the clip of L video in the file name, and the extension is “00001.ilvt” ilvt file. Is identified.
  • the file name of the ilvt file includes the same numbers as the numbers included in the names of the m2ts file and the clpi file that make up the clip of L video.
  • step S6 the controller 31 uses “00001.ilvt” specified in step S3 as a read file, and causes the disk drive 32 to read from the optical disk 2 through the UDF file system.
  • the data of the L video stream and the R video stream read by the disk drive 32 as the data of the “00001.ilvt” ilvt file is supplied to the separation unit 51 of the decoding unit 36.
  • the EP_map includes position information such as the number of a source packet that specifies the position of each EP.
  • step S7 the controller 31 controls the separation unit 51 to read from the optical disc 2 based on chunk_map () of the clpi file “00001.clpi” and chunk_map () of the clpi file “00002.clpi”. Data is separated into L video and R video data.
  • the data of the L video stream separated by the separating unit 51 is output to the read buffer 52, and the data of the R video stream is output to the read buffer 55.
  • Data separation performed using chunk_map () will be described later.
  • the data of the L video stream stored in the read buffer 52 is extracted by the PID filter 53 based on the PID specified in step S1 of the transport packet, and supplied to the decoder 60 via the ES buffer 54 and the switch 59.
  • the data of the R video stream stored in the read buffer 55 is extracted by the PID filter 56 based on the PID specified in step S2 of the transport packet, and is decoded through the switch 57, ES buffer 58, and switch 59. 60.
  • step S8 the decoder 60 decodes (reproduces) the packets sequentially supplied from the switch 59.
  • 3D playback is performed as described above when the L video stream and the R video stream are included in different TSs, and those TS files are interleaved and recorded on the optical disc 2.
  • FIG. 27 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 (Source Packet Number) (length) from the reference position to the start position of each chunk with reference to the start position of the first chunk. The SPN at the start position of each chunk is described in order from the first chunk.
  • FIG. 28 is a diagram showing a specific example of a clpi file including chunk_map ().
  • 28A shows a clpi file of “00001.clpi” and number_of_source_packets is “number_of_source_packets1”. Also, number_of_chunks of chunk_map () is n + 1, and SPN_chunk_start [i] is 0, a1, a2,.
  • the first value 0 of SPN_chunk_start [i] is based on the start position of the first chunk of the “00001.m2ts” m2ts file.
  • the SPN up to the start position of L [0] is 0.
  • the second value a1 indicates that the SPN from the reference position to the start position of the second chunk L [1] is a1.
  • the third value a2 indicates that the SPN from the reference position to the start position of the third chunk L [2] is a2.
  • n + 1th value an indicates that the SPN from the reference position to the start position of L [n] that is the last chunk is an.
  • B in FIG. 28 is a diagram showing a clpi file of “00002.clpi”, and number_of_source_packets is “number_of_source_packets2”. Further, number_of_chunks of chunk_map () is n + 1, and SPN_chunk_start [i] is 0, b1, b2,..., Bn.
  • the first value 0 of SPN_chunk_start [i] is based on the start position of the first chunk of the “00002.m2ts” m2ts file, and the first chunk from the reference position.
  • the SPN up to the start position of R [0] is 0.
  • the second value b1 represents that the SPN from the reference position to the start position of the second chunk R [1] is b1.
  • the third value b2 represents that the SPN from the reference position to the start position of R [2] that is the third chunk is b2.
  • the n + 1th value bn represents that the SPN from the reference position to the start position of R [n] that is the last chunk is bn.
  • the separation unit 51 corresponds to b1 from the beginning of the supplied data based on the description of two chunk_map () as shown in the lower part of FIG. Separate SPN data as R [0].
  • the separation unit 51 receives R [0], L [0], R [1], L [1],. ] And L [n] in this order.
  • the separating unit 51 separates SPN data corresponding to a1 from the end position of R [0] as L [0], and SPN parts corresponding to b2-b1 from the end position of L [0]. Are separated as R [1].
  • the separation unit 51 separates SPN data corresponding to a2-a1 as L [1] from the end position of R [1].
  • the separation unit 51 has an SPN amount corresponding to a value obtained by subtracting the value of bn from the value of number_of_source_packets2 described in the clpi file “00002.clpi”. Separate data as R [n].
  • the separation unit 51 obtains SPN data corresponding to a value obtained by subtracting the value of an from the value of number_of_source_packets1 described in the clpi file of “00001.clpi” from the end position of R [n]. As separate.
  • the separation of data by the separation unit 51 is performed using information on the length of each chunk described in chunk_map ().
  • chunk_map () is optional (may or may not be present).
  • a player who has read a PlayList in which a value other than 1 is set in MVC_file_type must ignore the chunk_map () if the chunk_map () is in the PlayList.
  • MVC_file_type 1
  • the two corresponding streams of the L video stream and the R video stream are each divided into the same number of chunks.
  • R [i] and L [i] to be interleaved the chunk of the L video stream and the chunk of the L video stream having the same value of the subscript i have the same playback time.
  • FIG. 30 is a diagram showing the syntax of EP_map () described in the clpi file.
  • EP_map () is referred to specify the decoding start position when performing random access.
  • number_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.
  • the PTS and SPN for each entry point are registered in the EP_map in association with each other.
  • a read start address is specified based on PTS_EP_start [i] and SPN_EP_start [i] of the designated EP, and the file is read.
  • FIG. 31A is a diagram showing another specific example of the PlayList file.
  • 31A is a PlayList that controls 3D playback when the L video stream and the R video stream are included in the same TS. That is, the m2ts file of the L video stream and the m2ts file of the R video stream are not interleaved on the optical disc 2.
  • the Clip_Information_file_name of PlayItem () is “00001”. From this description, the clpi file constituting the clip of L video is specified. Further, the start position and end position of the PlayItem playback section are specified from IN_time and OUT_time of PlayItem (), respectively, and the PID of the transport packet constituting the L video stream is specified from STN_table ().
  • the PID of the transport packet constituting the R video stream is specified from STN_table_extension () of ExtensionData ().
  • the value of type of STN_table_extension () is 1.
  • FIG. 31B shows the syntax of the “00001.clpi” clpi file.
  • the clpi file of “00001.clpi” includes EP_map.
  • a value other than 1 is set in MVC_file_type, and in this example, chunk_map () is not included in the clpi file.
  • FIG. 32 is a diagram showing the concept of file management performed based on the file of FIG.
  • one TS including the L video stream and the R video stream is managed by an m2ts file of “00001.m2ts”.
  • the recording position of the “00001.m2ts” m2ts file is specified by the UDF file system and read by the disk drive 32.
  • the transport packets constituting the L video stream and the R video stream included in the read "00001.m2ts” m2ts file are separated based on the PID.
  • step S21 the controller 31 specifies the PID of the transport packet of Main TS that constitutes the L video stream from the description of STN_table ().
  • step S22 the controller 31 specifies the PID of the transport packet of Main TS that constitutes the R video stream from the description of STN_table_extension ().
  • step S23 the controller 31 specifies the file name of the clpi file corresponding to the m2ts file including the L video stream and the R video stream as “00001.clpi” from Clip_Information_file_name in PlayItem ().
  • step S24 the controller 31 reads “00001.m2ts” as a read file, and causes the disk drive 32 to read from the optical disk 2 through the UDF file system.
  • the data of the “00001.m2ts” m2ts file read by the disk drive 32 is supplied to the read buffer 52 via the separator 51 and stored therein.
  • the transport packet of the L video stream is extracted by the PID filter 53 based on the PID specified in step S21.
  • the extracted transport packet data is supplied to the decoder 60 via the ES buffer 54 and the switch 59.
  • the transport packet of the R video stream is extracted from the data stored in the read buffer 52 by the PID filter 53 based on the PID specified in step S22.
  • the extracted transport packet data is supplied to the decoder 60 via the switch 57, ES buffer 58, and switch 59.
  • step S25 the decoder 60 decodes (reproduces) the packets sequentially supplied from the switch 59.
  • 3D playback when the L video stream and the R video stream are included in the same TS is performed as described above.
  • FIG. 34 is a diagram showing still another specific example of the PlayList file.
  • the PlayList file in FIG. 34 is a PlayList that controls 3D playback when a TS including a L video stream is recorded on the optical disc 2 and a TS including a R video stream is recorded in the local storage 34.
  • the PlayList recorded on the optical disc 2 is updated by adding information about the R video stream, recorded in the local storage 34 and managed by the controller 31. .
  • the Clip_Information_file_name of PlayItem () is “00001”. From this description, the clpi file constituting the clip of L video is specified. Further, the start position and end position of the PlayItem playback section are specified from IN_time and OUT_time of PlayItem (), respectively, and the PID of the transport packet constituting the L video stream is specified from STN_table ().
  • the Clip_Information_file_name of SubPlayItem () of ExtensionData () is “00003”. From this description, the clpi file constituting the clip of R video is specified. The clpi file of “00003.clpi” is also downloaded from the server 22 together with the m2ts file of “00003.m2ts”, which is the corresponding R video stream file, and stored in the local storage 34.
  • the start position and end position of the playback section of SubPlayItem are specified from SubPlayItem_IN_time and SubPlayItem_OUT_time of SubPlayItem () of ExtensionData ().
  • the type value of STN_table_extension () is 2.
  • FIG. 35 is a diagram showing the syntax of the clpi file.
  • FIG. 35A shows an example of a clpi file “00001.clpi”.
  • the clpi file of “00001.clpi” includes EP_map.
  • B of FIG. 35 is a diagram illustrating an example of a clpi file of “00003.clpi”.
  • the EP_map is also included in the clpi file “00003.clpi”.
  • the EP_map included in the clpi file of “00001.clpi” and the EP_map included in the clpi file of “00003.clpi” contain EP information set at the same time based on the start time t0 of the content. included.
  • the position of the video stream is the same time position on the time axis with respect to time t0.
  • FIG. 36 is a diagram showing the concept of file management performed using the files of FIGS. 34 and 35.
  • the TS including the L video stream recorded on the optical disc 2 is managed by an m2ts file of “00001.m2ts”. Also, the TS including the R video stream recorded in the local storage 34 is managed by the m2ts file “00003.m2ts”.
  • the data recorded on BD and the data recorded on local storage are merged with, for example, UDF file system that manages data recorded on BD and file system that manages data recorded on local storage Managed by a virtual file system.
  • UDF file system that manages data recorded on BD
  • file system that manages data recorded on local storage Managed by a virtual file system.
  • a player with a built-in local storage generates such a virtual file system and manages the data recorded on the BD and the data recorded on the local storage.
  • an m2ts file of “00001.m2ts” is designated by the application, it is specified by the virtual file system that the m2ts file of “00001.m2ts” is recorded at a predetermined position on the optical disk 2, and the disk drive 32 Is read.
  • the virtual file system identifies and reads out that the m2ts file of “00003.m2ts” is recorded at a predetermined position in the local storage 34. .
  • step S41 the controller 31 specifies the PID of the Transport packet of Main TS that constitutes the L video stream from the description of STN_table ().
  • step S43 the controller 31 specifies the file name of the clpi file corresponding to the m2ts file of the Main TS including the L video stream as “00001.clpi” from the Clip_Information_file_name in PlayItem ().
  • step S45 the controller 31 reads “00001.m2ts” as a read file, and causes the disk drive 32 to read from the optical disk 2 through the virtual file system.
  • step S46 the controller 31 reads “00003.m2ts” as a read file and reads it from the local storage 34 through the virtual file system.
  • the data of the “00001.m2ts” m2ts file read by the disk drive 32 is supplied to the read buffer 52 via the separation unit 51 and stored therein.
  • the data of the L ⁇ ⁇ ⁇ video stream stored in the read buffer 52 is extracted by the PID filter 53 based on the PID specified in step S41, and supplied to the decoder 60 via the ES buffer 54 and the switch 59.
  • the data of the “00003.m2ts” m2ts file read from the local storage 34 is supplied to the read buffer 55 via the separation unit 51 and stored therein.
  • the R video stream data stored in the read buffer 55 is extracted by the PID filter 56 based on the PID specified in step S42 for the transport packet, and is decoded by the switch 57, the ES buffer 58, and the switch 59. 60.
  • step S47 the decoder 60 decodes (reproduces) the packets sequentially supplied from the switch 59.
  • 3D playback is performed as described above when the TS including the L video stream is recorded on the optical disc 2 and the TS including the R video stream is recorded in the local storage 34.
  • the player that performs 2D playback reads only the description related to 2D playback from the PlayList file and performs processing.
  • ExtensionData which is information that is referenced when the R video stream is reproduced
  • the playback device 1 that performs 2D playback specifies the file name of the clpi file corresponding to the m2ts file including the L video stream as “00001.clpi” from Clip_Information_file_name in PlayItem (). Further, the playback device 1 identifies the PID of the transport packet that constitutes the L video stream from the description of STN_table ().
  • the playback device 1 reads the “00001.m2ts” m2ts file from the optical disc 2 through the UDF file system, and thereafter performs the same processing as when the L video stream is read. That is, the data of the L ⁇ video stream temporarily stored in the read buffer 52 is supplied to the decoder 60 via the PID filter 53, the ES buffer 54, and the switch 59 and reproduced. Since the data output from the playback device 1 is only the data of the L video stream, the display device 3 displays a 2D image based on the data of the L video stream.
  • the PlayList file described with reference to FIG. 23 or the like is used when 2D playback is performed on a playback device that supports 3D playback, or when 2D playback is performed on a playback device that does not support 3D playback. Will also be a usable file. Thus, it is not necessary to prepare a player for 3D playback and a player not compatible with 3D playback, and the compatibility of the PlayList file and the optical disc 2 on which it is recorded is ensured. It becomes possible.
  • FIG. 40 is a block diagram illustrating a configuration example of the software production processing unit 101.
  • the video encoder 111 has the same configuration as the MVC encoder of FIG.
  • the video encoder 111 encodes a plurality of video data with H.264.AVC / MVC to generate an L video stream and an R video stream, and outputs them to the buffer 112.
  • the audio encoder 113 encodes the input audio stream and outputs the obtained data to the buffer 114.
  • An audio stream to be recorded on the disc is input to the audio encoder 113 together with the L video stream and the R video stream.
  • the data encoder 115 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 116. For example, the data encoder 115 sets the above-described SubPath_entries_extension (FIG. 15), STN_table_extension (FIG. 18), MVC_flag (FIG. 12), and MVC_file_type (FIG. 13), and generates a PlayList file as described with reference to FIG. To do.
  • the multiplexing unit 117 multiplexes the video data, audio data, and data other than the stream stored in each buffer together with the synchronization signal, and outputs the multiplexed data to the error correction encoding unit 118.
  • the error correction encoding unit 118 adds an error correction code to the data multiplexed by the multiplexing unit 117.
  • the modulation unit 119 modulates the data supplied from the error correction coding unit 118 and outputs it.
  • the output of the modulation unit 119 is software recorded on the optical disc 2 that can be played back by the playback device 1.
  • a software production processing unit 101 having such a configuration is provided in the recording apparatus.
  • FIG. 41 is a diagram illustrating an example of a configuration including the software production processing unit 101.
  • the recording signal generated by the software production processing unit 101 is subjected to a mastering process in the premastering processing unit 131, and a signal having a format to be recorded on the optical disc 2 is generated.
  • the generated signal is supplied to the master recording unit 133.
  • 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 131, and irradiated to the photoresist on the master.
  • the photoresist on the master is exposed corresponding to the recording signal.
  • the master is developed and pits appear on the master.
  • the metal master production section 134 a process such as electroforming is performed on the master, 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.
  • 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. In this way, the above-described optical disc 2 on which data reproducible by the reproducing apparatus 1 is recorded is completed.
  • FIG. 42 is a block diagram showing an example of the hardware configuration of a computer that executes the above-described series of processing by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 155 is further connected to the bus 154.
  • the input / output interface 155 is connected to an input unit 156 composed of a keyboard, a mouse, etc., and an output unit 157 composed of a display, a speaker, and the like.
  • the input / output interface 155 is connected to a storage unit 158 made up of a hard disk, a non-volatile memory, etc., a communication unit 159 made up of a network interface, etc., and a drive 160 that drives the removable media 161.
  • the CPU 151 loads the program stored in the storage unit 158 to the RAM 153 via the input / output interface 155 and the bus 154 and executes it, thereby executing the above-described series of processing. Is done.
  • the program executed by the CPU 151 is recorded on the removable medium 161 or provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital broadcasting, and is installed in the storage unit 158.
  • the program executed by the computer may be a program that is processed in time series in the order described in this specification, or in parallel or at a necessary timing such as when a call is made. It may be a program for processing.
  • 1 playback device 2 optical disk, 3 display device, 11 H.264 / AVC encoder, 12 H.264 / AVC decoder, 13 Dependent view video encoder, 14 multiplexer, 31 controller, 32 disk drive, 33 memory, 34 local storage, 35 Internet interface, 36 decoding section, 37 operation input section

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)

Abstract

　本発明は、3D画像のコンテンツを適切に再生することができるようにすることができる情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関する。 光ディスク２には、H.264 AVC/MVCの符号化方式によって生成されたBase view videoストリーム（L画像）とDependent view videoストリーム（R画像）、および、再生を制御する情報であるPlayListが記録される。PlayListに設定されているMVC_flagの値が、3D再生に関する情報が含まれていることを表している場合、PlayListのExtensionData()の記述も参照されて3D再生が行われる。ExtensionData()のフィールドにはDependent view videoストリームの再生に関する情報が記述されている。本発明は、Blu-Ray（登録商標） Discのプレーヤに適用することができる。

Description

情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム
　本発明は、情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関し、特に、3D画像のコンテンツを適切に再生することができるようにした情報処理装置、情報処理方法、再生装置、再生方法、およびプログラムに関する。
　近年、立体視が可能な３次元（3D）画像のコンテンツが注目を集めている。3D画像の表示の方式としては、左目用の画像と右目用の画像を交互に表示させる方式などの種々の方式があるが、いずれの方式を採用する場合であっても、3D画像のデータ量は、2D画像のデータ量よりも大きくなる。
　映画等の高解像度のコンテンツを、データ量の多い3D画像として記録するには大容量の記録媒体が必要である。
　そのような大容量の記録媒体としては、例えば、BD-ROM等のBlu-Ray（登録商標） Disc（以下、適宜、BDという）がある。
特開平１１－１９５２８７号公報
　ところで、現行のBDの規格では、3D画像のコンテンツを、BDに、どのように記録し、また、再生するかは規定されていない。
　3D画像のコンテンツの記録や再生の仕方を、3D画像のコンテンツのオーサリングを行うオーサ(author)に委ねてしまうと、3D画像のコンテンツを適切に再生することができなくなるおそれがある。
　従って、3D画像のコンテンツの記録や再生の仕方を規定しておく必要がある。また、互換性を確保し、従来の2D再生用のプレーヤにおいても少なくとも2D画像での再生が可能になるように、3D画像のコンテンツの記録や再生の仕方を規定しておく必要がある。
　本発明は、このような状況に鑑みてなされたものであり、BD等の記録媒体から、3D画像のコンテンツを適切に再生することができるようにするものである。
　本発明の一側面の情報処理装置は、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定する設定手段を備える。
　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、前記設定手段には、前記サブ再生パスを指定する情報として、前記サブ再生パスの種類が、前記Dependent view videoのストリームを参照するパスであることを表す情報と、前記Dependent view videoのストリームの属性情報であるクリップ情報のファイルのファイル名とを、前記第１のフィールドに設定させることができる。
　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、前記設定手段には、前記サブ再生パスを指定する情報としての前記サブ再生パスのIDと、前記Dependent view videoのストリームのトランスポートパケットのPIDとを、前記第２のフィールドに設定させることができる。
　本発明の一側面の情報処理方法は、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定するステップを含む。
　本発明の一側面のプログラムは、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定するステップを含む処理をコンピュータに実行させる。
　本発明の他の側面の再生装置は、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御する制御手段を備える。
　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、前記制御手段には、前記Dependent view videoのストリームの再生を制御することを、前記PlayListの中のメイン再生パスに関する情報が記述されるフィールドに設定された、前記Base view videoのストリームを参照するメイン再生パスを指定する情報と、前記Base view videoのストリームのトランスポートパケットのPIDを指定する情報とに基づいて行われる前記Base view videoのストリームの再生の制御とともに行わせることができる。
　本発明の他の側面の再生方法は、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御するステップを含む。
　本発明の他の側面のプログラムは、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御するステップを含む処理をコンピュータに実行させる。
　本発明の一側面においては、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とが設定される。
　本発明の他の側面においては、コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生が制御される。
　本発明によれば、3D画像のコンテンツを適切に再生することができる。
本発明を適用した再生装置を含む再生システムの構成例を示す図である。 撮影の例を示す図である。 MVCエンコーダの構成例を示すブロック図である。 画像の参照の例を示す図である。 TSの構成例を示す図である。 TSの他の構成例を示す図である。 光ディスク上のデータの配置の例を示す図である。 AVストリームの管理構造の例を示す図である。 Main PathとSub Pathの構造を示す図である。 光ディスクに記録されるファイルの管理構造の例を示す図である。 PlayListファイルのシンタクスを示す図である。 MVC_flagの意味を示す図である。 MVC_file_typeの意味を示す図である。 SubPath_typeの意味を示す図である。 SubPath_entries_extention()のシンタクスを示す図である。 SubPath_extention()のシンタクスを示す図である。 SubPath_type_extentionの意味を示す図である。 STN_table_extention()のシンタクスを示す図である。 stream_entry()のシンタクスを示す図である。 PlayItemとSubPlayItemの関係を示す図である。 再生装置の構成例を示すブロック図である。 デコード部の構成例を示す図である。 PlayListファイルの具体例を示す図である。 clpiファイルのシンタクスを示す図である。 ファイル管理の概念を示す図である。 図２３のPlayListファイルに従って行われる再生処理について説明するフローチャートである。 chunk_map()のシンタクスを示す図である。 chunk_map()の具体例を示す図である。 データの分離の例を示す図である。 EP_map()のシンタクスを示す図である。 PlayListファイルの他の例を示す図である。 ファイル管理の概念を示す図である。 図３１のPlayListファイルに従って行われる再生処理について説明するフローチャートである。 PlayListファイルのさらに他の例を示す図である。 clpiファイルのシンタクスを示す図である。 ファイル管理の概念を示す図である。 図３４のPlayListファイルに従って行われる再生処理について説明するフローチャートである。 PlayListファイルの例を示す図である。 clpiファイルのシンタクスを示す図である。 ソフト製作処理部の構成例を示すブロック図である。 ソフト製作処理部を含む構成の例を示す図である。 コンピュータの構成例を示すブロック図である。
　［再生システムの構成例］
　図１は、本発明を適用した再生装置１を含む再生システムの構成例を示す図である。
　この再生システムは、再生装置１と表示装置３がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置１には、BD-ROMなどの、BD規格の光ディスクである光ディスク２が装着される。
　光ディスク２には、視点の数が２つの3D画像を表示するために必要なストリームが記録されている。ストリームを光ディスク２に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)が採用される。
　再生装置１は、光ディスク２に記録されているストリームの3D再生に対応したプレーヤである。再生装置１は、光ディスク２に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置３に表示させる。音声についても同様に再生装置１により再生され、表示装置３に設けられるスピーカなどから出力される。なお、再生装置１は、従来のBDプレーヤと同様に2D再生にも対応している。
［H.264 AVC/MVC Profile］
　H.264 AVC/MVCでは、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCを単にMVCという。
　図２は、撮影の例を示す図である。
　図２に示すように、同じ被写体を対象として、L画像（左視点）用のカメラとR（右視点）画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
　図３は、MVCエンコーダの構成例を示すブロック図である。
　図３に示すように、MVCエンコーダは、H.264/AVCエンコーダ１１、H.264/AVCデコーダ１２、Dependent view videoエンコーダ１３、およびマルチプレクサ１４から構成される。
　L画像用のカメラにより撮影されたL画像のストリームはH.264/AVCエンコーダ１１に入力される。また、R画像用のカメラにより撮影されたR画像のストリームはDependent view videoエンコーダ１３に入力される。
　H.264/AVCエンコーダ１１は、L画像のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ１１は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ１２とマルチプレクサ１４に出力する。
　H.264/AVCデコーダ１２は、H.264/AVCエンコーダ１１から供給されたAVCビデオストリームをデコードし、デコードして得られたL画像のストリームをDependent view videoエンコーダ１３に出力する。
　Dependent view videoエンコーダ１３は、H.264/AVCデコーダ１２から供給されたL画像のストリームと、外部から入力されたR画像のストリームをエンコードし、Dependent view videoストリームを出力する。
　Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図４に示すように、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エンコーダ１３は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ１４に出力する。
　マルチプレクサ１４は、H.264/AVCエンコーダ１１から供給されたBase view videoストリームと、Dependent view videoエンコーダ１３から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは１本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
　マルチプレクサ１４は、生成したTS（MPEG2 TS）を出力する。マルチプレクサ１４から出力されたTSは、他の管理データとともに記録装置において光ディスク２に記録され、再生装置１に提供される。
　この例においては、L画像をBase view video、R画像をDependent view videoとしてMVC方式で符号化するものとしたが、反対に、R画像をBase view video、L画像をDependent view videoとして符号化するようにしてもよい。以下、L画像をBase view video、R画像をDependent view videoとして符号化した場合について説明する。
　再生装置１は、ユーザによる指示などに応じて3D再生を行う場合、Base view videoストリームとDependent view videoストリームを光ディスク２から読み出して再生する。
　また、再生装置１は、2D再生を行う場合、Base view videoストリームだけを光ディスク２から読み出して再生する。Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
［TSの構成例］
　図５は、光ディスク２に記録されているTSの構成例を示す図である。
　図５のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。このように、Dependent view videoストリームが、Base view videoストリームとともに１本のTSであるMain TSに含まれていることもある。
　Main TSは、少なくともBase view videoストリームを含むTSである。これに対して、Sub TSは、Base view videoストリーム以外のストリームを含み、再生時にMain TSとともに用いられるTSである。光ディスク２には、Main TSの他に、Sub TSも適宜記録される。
　ビデオと同様に3Dでの表示が可能になるように、字幕などのPG(Presentation Graphics)、メニュー画面などのIG(Interactive Graphics)についても、Base viewとDependent viewのそれぞれのストリームが用意されている。
　図６は、光ディスク２に記録されているTSの他の構成例を示す図である。
　図６の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に含まれていることもある。
　図６に示すようにBase view videoストリームとDependent view videoストリームがそれぞれ別のTSに含まれている場合、それぞれのTSファイルは、インターリーブされて光ディスク２に記録される。
　図７は、Base view videoストリーム（L videoストリーム）を含むTSファイルとDependent view videoストリーム（R videoストリーム）を含むTSファイルの光ディスク２における配置の例を示す図である。
　図７に示すように、L videoストリームを含むTSファイルとR videoストリームを含むTSファイルは、所定のデータ単位毎に交互に並ぶようにインターリーブ配置され、光ディスク２に記録される。1つのTSファイルに属し、光ディスク２上に連続配置されるソースパケットの集まりをチャンクという。
　図７において、「R」の文字と数字を付して示すそれぞれのブロックはR videoのチャンクを表し、「L」の文字と数字を付して示すそれぞれのブロックはL videoのチャンクを表す。
　3D再生時、例えば、R[0],L[0],R[1],L[1],R[2],L[2],R[3],L[3],R[4],L[4],R[5],L[5],・・・の順に光ディスク２から読み出され、L[0],R[0],L[1],R[1],L[2],R[2],L[3],R[3],L[4],R[4],L[5],R[5],・・・の順にデコードされる。上述したように、R videoをデコードするには、エンコード時に参照したL videoが先にデコードされている必要がある。同じ数字が付されているR videoのチャンクとL videoのチャンクは、同じ時間の再生に必要なデータであり、3D再生時にセットで用いられる。
　すなわち、説明を簡単にするため、コンテンツの再生時間全体を３等分する場合を考える。コンテンツの再生時間全体を３等分する時刻を、再生の開始時刻を0として、時系列順に、t1，t2と表すと、再生の開始時刻から時刻t1までの再生時間に必要な分のL videoのデータが、チャンクL[0]として分割される。
　また、時刻t1からt2までの再生時間に必要な分のL videoのデータが、チャンクL[1]として分割され、時刻t2から再生の終了時刻までの再生時間に必要な分のL videoのデータが、チャンクL[2]として分割される。
　R videoストリームについても同様に、再生の開始時刻から時刻t1までの再生時間に必要な分のR videoのデータが、チャンクR[0]として分割される。
　また、時刻t1からt2までの再生時間に必要な分のR videoのデータが、チャンクR[1]として分割され、時刻t2から再生の終了時刻までの再生時間に必要な分のR videoのデータが、チャンクR[2]として分割される。
　このようにして分割して得られた各チャンクは、同じ数字が付されたチャンク同士が、R videoのチャンク、L videoのチャンクの順になるように配置され、光ディスク２に記録される。なお、図５に示すように、L videoストリームとR videoストリームがともに１本のTSに含まれている場合、そのTSファイルはインターリーブされずに光ディスク２に記録される。
［AVストリームの管理構造］
　図８は、再生装置１によるAVストリームの管理構造の例を示す図である。
　AVストリームの管理は、図８に示すようにPlayListとClipの２つのレイヤを用いて行われる。AVストリームは、光ディスク２ではなく、再生装置１のローカルストレージに記録されていることもある。Clipは、ビデオデータやオーディオデータが多重化されることによって得られたTSであるAVストリームと、対応するClip Information（そのAVストリームに関する属性情報を含むClip Information）とから構成される。
　AVストリームは時間軸上に展開され、各アクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。
　PlayListはAVストリームの再生区間の集まりである。AVストリーム中の１つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。PlayListは１つまたは複数のPlayItemにより構成される。
　図８の左から１番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。
　左から２番目のPlayListは１つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。
　左から３番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。
　例えば、左から１番目のPlayListに含まれる左側のPlayItemが再生対象としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を制御するための再生制御情報として用いられる。
　PlayListの中で、１つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。
　また、PlayListの中で、Main Pathに並行して、１つ以上のSubPlayItemの並びによって構成される再生パスをサブパス（Sub Path）という。
　図９は、Main PathとSub Pathの構造を示す図である。
　PlayListは、１つのMain Pathと１つ以上のSub Pathを持つことができる。上述したL videoストリームは、Main Pathを構成するPlayItemにより参照される。また、R videoストリームは、Sub Path（後述するExtension()内のSub Path）を構成するSubPlayItemにより参照される。
　図９のPlayListは、３つのPlayItemの並びにより構成される１つのMain Pathと、３つのSub Pathを有している。Main Pathを構成するPlayItemには、先頭から順にそれぞれIDが設定される。Sub PathにもそれぞれIDが設定される。
　図９の例においては、Subpath_id=0のSub Pathには１つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには２つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには１つのSubPlayItemが含まれる。
　あるPlayItemが参照するAVストリームと、そのPlayItemと時間帯が重複する再生区間を指定するSubPlayItemが参照するAVストリームは同期して再生される。PlayList、PlayItem、SubPlayItemを用いたAVストリームの管理については、例えば、特開２００８－２５２７４０号公報、特開２００５－３４８３１４号公報に記載されている。
［ディレクトリ構造］
　図１０は、光ディスク２に記録されるファイルの管理構造の例を示す図である。
　図１０に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク２上には１つのrootディレクトリが作成される。rootディレクトリの下が、１つの記録再生システムで管理される範囲となる。
　rootディレクトリの下にはBDMVディレクトリが置かれる。BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
　BDMVディレクトリの下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
　PLAYLISTディレクトリには、PlayListを記述したファイルであるPlayListファイルが格納される。各PlayListファイルには、５桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。図１０に示すPlayListファイルには「00000.mpls」のファイル名が設定されている。
　CLIPINFディレクトリにはClip Informationを記述したファイルであるClip Informationファイルが格納される。各Clip Informationファイルには、５桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
　図１０の２つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
　「00001.clpi」のclpiファイルは、対応するL videoストリームに関する情報が記述されたファイルであり、「00002.clpi」のclpiファイルは、対応するR videoストリームに関する情報が記述されたファイルである。
　STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、５桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、５桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルといい、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
　「00001.m2ts」のm2tsファイルはL videoストリームのファイルであり、「00002.m2ts」のm2tsファイルはR videoストリームのファイルである。
　「00001.ilvt」のilvtファイルは、L videoストリームのm2tsファイルとR videoストリームのm2tsファイルがインターリーブされている場合に、それらのストリームを管理し、3D再生を行うためのファイルである。従って、L videoストリームとR videoストリームが１本のTSに含まれ、それらのm2tsファイルがインターリーブされていない場合、ilvtファイルは光ディスク２に記録されない。
　図１０に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
　図１０の例においては、L videoに関するClipを構成するm2tsファイルのファイル名は「00001.m2ts」、clpiファイルのファイル名は「00001.clpi」である。また、R videoに関するClipを構成するm2tsファイルのファイル名は「00002.m2ts」、clpiファイルのファイル名は「00002.clpi」である。１つのClipを構成するm2tsファイルのファイル名とclpiファイルのファイル名には同じ数字が含まれる。
　ilvtファイルのファイル名には、L videoに関するClipを構成するm2tsファイルのファイル名とclpiファイルのファイル名にそれぞれ含まれる５桁の数字と同じ、「00001」が含まれる。これにより、L videoに関するClipを構成するclpiファイルのファイル名から、3D再生を行うときに指定するilvtファイルのファイル名を特定することが可能になる。
［各データのシンタクス］
　図１１は、PlayListファイルのシンタクスを示す図である。
　説明の便宜上、図１１の左側には行数を表す数字と「：」を示している。行数を表す数字と「：」はPlayListを構成するものではない。なお、ここでは、PlayListの主な記述について説明するものとし、詳細な説明は省略する。詳細については、例えばBlu-ray Disc Read Only Format part3に記載されている。
　１行目のyyyyy.mplsは、このPlayListファイルのファイル名を表す。
　２行目乃至５行目に示すように、PlayListファイルには、大きく分けて、AppInfoPlayList()、PlayList()、PlayListMark()、ExtensionData()のフィールドから構成される。４行目のPlayListMark()には、チャプタジャンプなどを指令するユーザ操作、またはコマンドなどによるジャンプ先であるマークに関する情報が記述される。
　７行目乃至１１行目がAppInfoPlayList()のフィールドである。AppInfoPlayList()には、９行目に示すように、PlayList中にMVC再生（3D再生）に関する情報が含まれるか否かを表す１ビットのフラグであるMVC_flagが含まれる。なお、PlayListの中に含まれるのではなく、ビデオストリームなどのストリームの中にMVC_flagが含まれるようにしてもよい。
　図１２は、MVC_flagの意味を示す図である。
　図１２に示すように、MVC_flagの値が0であることは、PlayList中に3D再生に関する情報が含まれていないことを表す。すなわち、MVC_flag=0が設定されたPlayListが記録されている光ディスクは3D再生に非対応のディスクということになる。
　MVC_flagの値が1であることは、PlayList中に3D再生に関する情報が含まれていることを表す。
　AppInfoPlayList()には、MVC_flagの他に、ランダム再生を行うためのPlayListであるかなどの、PlayListの種類に関する情報が含まれる。
　１２行目乃至２５行目がPlayList()のフィールドである。１３行目のnumber_of_PlayItemsは、PlayListの中にあるPlayItemの数を表す。図９の例の場合、PlayItemの数は3である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順に0から割り振られる。１５行目乃至１９行目のfor文では、PlayItemの数だけPlayItem()が参照される。
　１４行目のnumber_of_SubPathsは、PlayList()の中にあるSub Pathの数を表す。図９の例の場合、Sub Pathの数は3である。SubPath_idの値は、PlayList()の中でSubPath()が現れる順に0から割り振られる。２０行目乃至２４行目のfor文では、Sub Pathの数だけSubPath()が参照される。
　２６行目乃至３３行目が、PlayList()に含まれるPlayItem()の記述になる。２７行目のClip_Information_file_nameは、PlayItemが参照するAVストリームを含むClipのclpiファイルの名前を表す。
　２８行目のMVC_file_typeは、MVC_flagの値が1であるときに有効な値を持つ２ビットのデータであり、L videoストリームとR videoストリームのそれぞれの供給元のファイルのタイプを表す。
　図１３は、MVC_file_typeの意味を示す図である。
　図１３に示すように、MVC_file_typeの値が0であることは、L videoストリームとR videoストリームが１本のTSに含まれており、そのTSを管理するm2tsファイルが、Clip_Information_file_nameにより示されることを表す。
　上述したように、あるClipを構成するm2tsファイルのファイル名とclpiファイルのファイル名には同じ数字が含まれる。Clip_Information_file_nameは、そのファイル名が設定されたclpiファイルと同じClipを構成する、対応するm2tsファイルのファイル名も示すことになる。
　MVC_file_typeの値が1であることは、Clip_Information_file_nameが示すL videoストリームのm2tsファイル（第１のTSファイル）と、R videoストリームのm2tsファイル（第２のTSファイル）が、光ディスク２上でインターリーブされていることを表す。この場合、L videoストリームとR videoストリームはそれぞれ異なるTSに含まれることになる。
　MVC_file_typeの値が2であることは、Clip_Information_file_nameが示すL videoストリームのm2tsファイルと、R videoストリームのm2tsファイルの両方、または片方が、再生装置１内のローカルストレージに記録されていることを表す。
　MVC_file_typeの値の3はリザーブ値である。
　図１１の説明に戻り、３０行目のIN_timeはPlayItemの再生区間の開始位置を表し、３１行目のOUT_timeは終了位置を表す。
　３２行目のSTN_table()には、PlayItemが参照するAVストリームの情報が含まれる。例えば、PlayItemが参照するAVストリームの情報として、ストリーム番号（ID）、L videoストリームを構成するトランスポートパケットのPIDが含まれる。
　３４行目乃至４０行目が、PlayList()に含まれるSubPath()の記述になる。３４行目乃至４０行目のSubPath()には、PlayItemが参照するAVストリームとともに再生される、R video以外のビデオデータに関する情報やオーディオデータに関する情報が含まれる。
　３５行目のSubPath_typeは、Sub Pathの種類を表す８ビットのデータである。
　図１４は、SubPath_typeの意味を示す図である。
　図１４に示すように、2から7の値によってSubPathの種類が表される。例えば、SubPath_type=2は、スライドショー（Browsable slideshow）再生時に用いられるオーディオデータのSubPathであることを表し、SubPath_type=3は、インタラクティブメニューの表示時のデータのSubPathであることを表す。
　図１１の３６行目のnumber_of_SubPlayItemsは、１つのSub Path()の中にあるSubPlayItemの数（エントリー数）を示す８ビットのデータである。例えば、図９のSubPath_id=0のSubPlayItemのnumber_of_SubPlayItemsは1であり、SubPath_id=1のSubPlayItemのnumber_of_SubPlayItemsは2である。３７行目乃至３９行目のfor文では、SubPlayItemの数だけ、SubPlayItem()が参照される。
　４１行目乃至４５行目が、SubPath()に含まれるSubPlayItem()の記述になる。４２行目のClip_Information_file_nameは、SubPlayItemが参照するClipのclpiファイルの名前を表す。
　４３行目のSubPlayItem_IN_timeはSubPlayItemの再生区間の開始位置を表し、４４行目のSubPlayItem_OUT_timeは終了位置を表す。
　４６行目乃至４９行目が、拡張フィールドであるExtensionData()になる。
　MVC_flagの値が1であるとき、ExtensionData()の中に、SubPath_entries_extension()とSTN_table_extension()が記述される。SubPath_entries_extension()とSTN_table_extension()には、PlayItemが参照するL videoストリームとともに3D再生に用いられる、R videoストリームに関する情報が含まれる。
　R videoストリームはSubPathが参照するストリームとして管理されるが、このように、R videoストリームに関する情報はSubPath()（図１１の３４行目）のフィールドには記述されずに、ExtensionData()のフィールドに記述される。
　R videoストリームに関する情報をSubPath()のフィールドに記述しておいた場合、その記述を3D再生に非対応のプレーヤが読み込んだときに不具合が生じるおそれがある。R videoストリームに関する情報をExtensionData()として記述しておき、その記述については、3D再生に対応したプレーヤが、3D再生を行うときにだけ読み込むようにしておくことにより、そのような不具合が生じるのを防ぐことが可能になる。
　図１５は、ExtensionData()に含まれるSubPath_entries_extension()のシンタクスの例を示す図である。
　number_of_SubPath_extensionsは、SubPath_extensionの数、すなわち、SubPath_entries_extension()の中に現れるSubPath_extension()の数を表す１６ビットのデータである。number_of_SubPath_extensionsに続くfor文では、SubPathの数だけ、SubPath_extension()が参照される。
　ここで、R videoストリームを参照するSubPathにも、図１１の３４行目のSubPath()に情報が記述される、R video以外のビデオデータやオーディオデータを参照する通常のSubPathと同様にIDが割り振られる。
　図１５のfor文に示すように、R videoストリームを参照するSubPathのIDは、図１１の１４行目のnumber_of_SubPathsの値と同じ値から開始され、SubPath_extension()が参照される毎に１ずつインクリメントされる。例えば、図９に示すように通常のSubPathの数が3であり、number_of_SubPaths=3である場合、number_of_SubPath_extensionsが2であるとすると、1つ目のSubPathのIDには3が割り振られ、2つ目のSubPathのIDには4が割り振られる。
　図１６は、図１５のSubPath_extension()のシンタクスの例を示す図である。
　lengthは、lengthのフィールドの直後からSubPath_extension()の最後までのバイト数を示す３２ビットのデータである。
　SubPath_type_extensionは、SubPath_typeを拡張させたものであり、SubPath_extension()に情報が記述されるSubPathの種類を表す８ビットのデータである。
　図１７は、SubPath_type_extensionの意味を示す図である。
　図１７に示すように、SubPath_type_extensionの値の0から7は、それぞれ、図１４のSubPath_typeの0から7の意味と同じ意味を表す。
　SubPath_type_extensionの値の8は、SubPath_type_extension=8が設定されたSubPathがR videoストリームを参照するSubPathであることを表す。また、参照するR videoストリームのm2tsファイルが、PlayItemが参照するL videoストリームのm2tsファイルとは別のファイルであることを表す。
　図１６の説明に戻り、number_of_SubPlayItemsは、SubPath_extension()の中にあるSubPlayItemの数を示す８ビットのデータである。number_of_SubPlayItemsに続くfor文では、SubPlayItemの数だけ、SubPlayItem()が参照される。
　SubPath_extension()の中のSubPlayItem()の記述は、図１１の４１行目から４５行目に示すSubPlayItem()の記述と同じ記述である。
　すなわち、SubPath_extension()の中のSubPlayItem()には、SubPlayItemが参照するR videoストリームと同じClipに含まれるclpiファイルのファイル名を示すClip_Information_file_nameが含まれる。また、再生区間の開始位置を表すSubPlayItem_IN_timeと、終了位置を表すSubPlayItem_OUT_timeが含まれる。
　図１８は、ExtensionData()に含まれるSTN_table_extension()のシンタクスの例を示す図である。
　上述したように、STN_table（図１１の３２行目）には、PlayItemが参照するL videoストリームを構成するトランスポートパケットのPIDが含まれる。これに対して、STN_table_extension()には、SubPath（SubPath_extension）が参照するR videoストリームを構成するトランスポートパケットのPIDが含まれる。
　図１８に示すように、STN_table_extension()には、STN_table_extension()の長さを表すlengthに続いて、R videoストリームに関する情報として、stream_entry()と、R videoストリームの属性情報であるstream_attributes()が含まれる。
　図１９は、stream_entry()のシンタクスの例を示す図である。
　図１９に示すように、stream_entry()には、stream_entry()の長さを表すlengthに続いて、８ビットの情報であるtypeが含まれる。
　例えば、typeの値が1であることは、R videoストリームが、PlayItemが参照するL videoストリームとともに１本のTSに含まれることを表す。また、typeの値が2であることは、R videoストリームが、PlayItemが参照するL videoストリームとは別のTSに含まれることを少なくとも表す。
　typeの値が1である場合、ref_to_stream_PID_of_mainClipが参照される。ref_to_stream_PID_of_mainClipは、L videoストリームとともに１本のTSに含まれる、R videoストリームを構成するトランスポートパケットのPIDを表す。
　typeの値が2である場合、ref_to_SubPath_id、ref_to_subClip_entry_id、ref_to_stream_PID_of_subClipが参照される。３つの情報のうちのref_to_SubPath_idは、R videoストリームを参照するSubPath（SubPath_extension）のIDを表す。また、ref_to_stream_PID_of_subClipは、ref_to_SubPath_idにより識別されるSubPathが参照するR videoストリームを構成するトランスポートパケットのPIDを表す。
　図２０は、R videoストリームを参照する、SubPath_type_extention=8が設定されたSubPathと、そのSubPathがPlayListにおいて関連付けられている、L videoストリームを参照するMainPathの関係を示す図である。
　上述したように、各PlayItem()には、PlayItemの再生区間の開始位置を表すIN_timeと終了位置を表すOUT_timeが含まれる（図１１の３０行目、３１行目）。
　また、上述したように、SubPath_extension()の中のSubPlayItem()には、R videoストリームを参照するSubPathを構成するそれぞれのSubPlayItemについて、再生区間の開始位置を表すSubPlayItem_IN_timeと、終了位置を表すSubPlayItem_OUT_timeが含まれる。
　図２０に示すように、PlayItemの開始位置、終了位置と、そのPlayItemが参照するL videoストリームに関連付けられたR videoストリームを参照するSubPlayItemの開始位置、終了位置は、それぞれ同じ位置になる。
　例えば、PlayItem_id=0が割り振られたPlayItemのIN_timeとOUT_timeは、それぞれ、PlayItem_id=0が割り振られたPlayItemに関連付けられたSubPlayItem#0のSubPlayItem_IN_time、SubPlayItem_OUT_timeと一致する。
　以上のように、PlayListには、拡張フィールドであるExtensionData()の中に、SubPathに関する情報が記述されるフィールドであるSubPath()がSubPath_extension()として定義され、また、ストリーム番号（STream Number）に関する情報が記述されるフィールドであるSTN_table()がSTN_table_extension()として定義されている。
［再生装置１の構成例］
　図２１は、再生装置１の構成例を示すブロック図である。
　コントローラ３１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
　ディスクドライブ３２は、コントローラ３１による制御に従って光ディスク２からデータを読み出し、読み出したデータを、コントローラ３１、メモリ３３、またはデコード部３６に出力する。
　メモリ３３は、コントローラ３１が各種の処理を実行する上において必要なデータなどを適宜記憶する。
　ローカルストレージ３４は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ３４には、サーバ２２からダウンロードされたR videoストリームなどが記録される。ローカルストレージ３４に記録されているストリームもデコード部３６に適宜供給される。
　インターネットインタフェース３５は、コントローラ３１からの制御に従ってネットワーク２１を介してサーバ２２と通信を行い、サーバ２２からダウンロードしたデータをローカルストレージ３４に供給する。
　サーバ２２からは、光ディスク２に記録されているデータをアップデートさせるデータがダウンロードされる。後述するように、ダウンロードしたR videoストリームを光ディスク２に記録されているL videoストリームと併せて用いることでコンテンツの3D再生を行うことも可能とされている。
　デコード部３６は、ディスクドライブ３２、またはローカルストレージ３４から供給されたストリームをデコードし、得られたビデオ信号を表示装置３に出力する。オーディオ信号も所定の経路を介して表示装置３に出力される。
　操作入力部３７は、ボタン、キー、タッチパネル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部３７はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ３１に供給する。
　図２２は、デコード部３６の構成例を示す図である。
　分離部５１は、ディスクドライブ３２から供給されたデータを、コントローラ３１による制御に従って、Main TSのデータとSub TSのデータに分離する。
　分離部５１は、分離したMain TSのデータをリードバッファ５２に出力して記憶させ、Sub TSのデータをリードバッファ５５に出力して記憶させる。また、分離部５１は、ローカルストレージ３４から供給されたSub TSのデータをリードバッファ５５に出力して記憶させる。
　PIDフィルタ５３は、リードバッファ５２に記憶されているデータから構成されるMain TSのトランスポートパケットをPIDに基づいて振り分ける。コントローラ３１からは、PlayListのSTN_table()（図１１の３２行目）に基づいて特定された、L videoストリームを構成するトランスポートパケットのPIDと、STN_table_extension()のref_to_stream_PID_of_mainClip（図１９）に基づいて特定された、R videoストリームを構成するトランスポートパケットのPIDが指定される。
　PIDフィルタ５３は、L videoストリームのトランスポートパケットをリードバッファ５２から読み出し、ESバッファ５４に出力して記憶させる。ESバッファ５４には、L videoのES(Elementary Stream)が記憶される。
　また、PIDフィルタ５３は、L videoストリームとともにR videoストリームがMain TSに多重化されている場合、R videoストリームのトランスポートパケットをPIDに基づいて抽出し、スイッチ５７に出力する。
　PIDフィルタ５６は、Sub TSに含まれるR videoストリームのトランスポートパケットをリードバッファ５５から読み出し、スイッチ５７に出力する。コントローラ３１からは、STN_table_extension()のref_to_stream_PID_of_subClip（図１９）に基づいて特定された、R videoストリームを構成するトランスポートパケットのPIDが指定される。
　ここでは、L video、R videoストリームの処理について説明しているが、図５を参照して説明したように、PGやIGなどのグラフィックスのデータがMain TSに多重化されていることがある。同様に、Sub TSにも、PGやIGなどのグラフィックスのデータが多重化されていることがある。
　PIDフィルタ５３とPIDフィルタ５６は、適宜、それらのデータをもPIDに基づいて振り分け、所定の出力先に出力する。図２２のPIDフィルタ５３とPIDフィルタ５６のブロック内に示す出力先の端子（丸）には、グラフィックのデータをデコードするデコーダなどが接続される。
　スイッチ５７は、PIDフィルタ５３から供給された、Main TSに含まれていたR videoストリームのトランスポートパケットをESバッファ５８に出力して記憶させる。また、スイッチ５７は、PIDフィルタ５６から供給された、Sub TSに含まれていたR videoストリームのトランスポートパケットをESバッファ５８に出力して記憶させる。ESバッファ５８には、R videoのESが記憶される。
　スイッチ５９は、ESバッファ５４に記憶されているL videoのパケットと、ESバッファ５８に記憶されているR videoのパケットのうちの、デコードの対象になるパケットをデコーダ６０に出力する。DTS(Decoding Time Stamp)などの時刻情報がL videoとR videoのPESパケットに設定されており、その時刻情報に基づいてバッファからの読み出しが行われる。
　デコーダ６０は、スイッチ５９から供給されたパケットをデコードし、デコードすることによって得られたL video、またはR videoのビデオ信号を出力する。
［PlayListファイルの具体例１］
　図２３は、PlayListファイルの具体例を示す図である。
　図２３には、図１１等に示す情報のうちの一部の情報を示している。後述するPlayListファイルの具体例についても同様である。
　図２３のPlayListファイルは、L videoストリームとR videoストリームがそれぞれ別のTSに含まれ、それらのTSファイルがインターリーブされて光ディスク２に記録されている場合の3D再生を制御するPlayListファイルである。
　すなわち、図２３のAppInfoPlayList()に示すようにMVC_flag=1であり、かつ、PlayItem()に示すようにMVC_file_type=1である。
　PlayItem()のClip_Information_file_nameは「00001」である。この記述から、L videoのClipを構成するclpiファイルが特定される。また、PlayItem()のIN_timeとOUT_timeから、PlayItemの再生区間の開始位置と終了位置がそれぞれ特定され、STN_table()から、L videoストリームを構成するトランスポートパケットのPIDが特定される。
　ExtensionData()には、R videoストリームを参照するSubPathに関する情報が記述される。この例においては、通常のSubPathの数が0（number_of_SubPaths（図１１の１４行目）の値が0）とされており、R videoストリームを参照するSubPathには、SubPath_id=0が割り当てられる。SubPath_extension()中には、R videoストリームを参照するSubPathであることを表すSubPath_type_extension=8が設定される。
　ExtensionData()のSubPlayItem()のClip_Information_file_nameは「00002」である。この記述から、R videoのClipを構成するclpiファイルが特定される。また、SubPlayItem()のSubPlayItem_IN_timeとSubPlayItem_OUT_timeから、SubPlayItemの再生区間の開始位置と終了位置がそれぞれ特定される。
　STN_table_extension()から、R videoストリームを参照するSubPathのIDが0であること（ref_to_SubPath_id=0）と、R videoストリームを構成するトランスポートパケットのPID（ref_to_R_video_PID）が特定される。この例の場合、STN_table_extension()のtypeの値は2となる。
　図２４は、clpiファイルのシンタクスを示す図である。
　図２４のＡは「00001.clpi」のclpiファイルの例を示す図である。
　number_of_source_packets1は、「00001.m2ts」のm2tsファイルに含まれるソースパケットの数を表す。
　EP_mapには、「00001.m2ts」のm2tsファイルに含まれるTSに設定されたエントリーポイント(EP)の位置情報が含まれる。
　chunk_map()には、「00001.m2ts」のm2tsファイルの各チャンクの位置情報が含まれる。各チャンクの位置は、例えばSource Packet Number（SPN）により表される。chunk_map()の具体例については後述する。
　図２４のＢは「00002.clpi」のclpiファイルの例を示す図である。
　「00002.clpi」のclpiファイルにも、「00001.clpi」のclpiファイルと同様に、「00002.m2ts」のm2tsファイルに含まれるソースパケットの数を表すnumber_of_source_packets2、EP_map、およびchunk_map()が含まれる。
　図２５は、ファイル管理の概念を示す図である。
　図２５に示すように、インターリーブされて光ディスク２に記録されているファイルの管理は、物理レイヤ、ファイルシステムレイヤ、アプリケーションレイヤの３層構造の形で行われる。図２３のPlayListファイル、図２４のclpiファイルは、コンテンツの再生を管理するアプリケーションが扱うアプリケーションレイヤの情報になる。
　物理レイヤは、L videoストリームのm2tsファイルとR videoストリームのm2tsファイルがインターリーブされて記録されている光ディスク２のレイヤとなる。
　ファイルシステムレイヤにおいては、アプリケーションが指定したストリームファイル（m2tsファイル、ilvtファイル）と、各ストリームファイルを構成するエクステントの光ディスク２上の位置が対応付けられる。ファイルシステムは例えばUDF file systemである。
　エクステントは、特定のファイルにより管理されるデータ全体のうち、連続して光ディスク２上に配置されるデータのそれぞれの集まりをいう。
　すなわち、図２５の例の場合、「00001.m2ts」のm2tsファイルにおいては、L[0],L[1]がそれぞれエクステントとなる。「00001.m2ts」のm2tsファイルが読み出しファイルとしてアプリケーションにより指定された場合、L[0],L[1]のそれぞれの光ディスク２上の位置がUDF file systemにより特定され、ディスクドライブ３２により読み出される。
　「00002.m2ts」のm2tsファイルにおいては、R[0],R[1]がそれぞれエクステントとなる。「00002.m2ts」のm2tsファイルが読み出しファイルとしてアプリケーションにより指定された場合、R[0],R[1]のそれぞれの光ディスク２上の位置がUDF file systemにより特定され、ディスクドライブ３２により読み出される。
　「00001.ilvt」のilvtファイルにおいては、R[0],L[0],R[1],L[1]全体が１つのエクステントとなる。「00001.ilvt」のilvtファイルが読み出しファイルとしてアプリケーションにより指定された場合、R[0],L[0],R[1],L[1]の光ディスク２上の位置がUDF file systemにより特定され、ディスクドライブ３２により読み出される。
［動作例１］
　ここで、図２６のフローチャートを参照して、図２３のPlayListファイルに従って行われる3D再生の処理について説明する。
　MVC_flag=1である場合、コントローラ３１（コントローラ３１において実行される、コンテンツの再生を管理するアプリケーション）は、操作部３７に対して行われたユーザによる操作に応じて3D再生を開始する。
　ステップＳ１において、コントローラ３１は、STN_table()の記述から、L videoストリームを構成する、Main TSのトランスポートパケットのPIDを特定する。
　ステップＳ２において、コントローラ３１は、STN_table_extension()の記述から、R videoストリームを参照するSubPathのSubPath_idの値であるref_to_SubPath_id=0を特定し、また、R videoストリームを構成する、Sub TSのトランスポートパケットのPIDを特定する。
　ステップＳ３において、コントローラ３１は、PlayItem()の中のClip_Information_file_nameから、L videoストリームを含むMain TSのm2tsファイルに対応するclpiファイルのファイル名を「00001.clpi」として特定する。
　ステップＳ４において、コントローラ３１は、SubPath_entries_extension()の中でSubPath_id=0を持つ、SubPath_type=8が設定されたSubPathのSubPlayItem()の中のClip_Information_file_nameから、R videoストリームを含むm2tsファイルに対応するclpiファイルのファイル名を「00002.clpi」として特定する。
　ステップＳ５において、コントローラ３１は、L videoのClipを構成するファイルのファイル名に含まれる数字（00001）と同じ５文字をファイル名に含み、拡張子がilvtである「00001.ilvt」のilvtファイルを特定する。上述したように、ilvtファイルのファイル名には、L videoのClipを構成するm2tsファイル、clpiファイルの名前に含まれる数字と同じ数字が含まれる。
　ステップＳ６において、コントローラ３１は、ステップＳ３で特定した「00001.ilvt」を読み出しファイルとし、UDF file systemを通して、ディスクドライブ３２に光ディスク２から読み出させる。「00001.ilvt」のilvtファイルのデータとしてディスクドライブ３２により読み出されたL videoストリームとR videoストリームのデータは、デコード部３６の分離部５１に供給される。
　なお、ランダムアクセスなどが指定されたことにより、EP_mapに含まれる所定のEPからデコードを開始する場合、読み出しファイルのデータのうちの、そのEP以降のデータが読み出される。EP_mapには、各EPの位置を指定するソースパケットの番号などの位置情報が含まれる。
　ステップＳ７において、コントローラ３１は、分離部５１を制御し、「00001.clpi」のclpiファイルのchunk_map()と「00002.clpi」のclpiファイルのchunk_map()に基づいて、光ディスク２から読み出されたデータを、L videoとR videoのデータに分離させる。
　分離部５１により分離されたL videoストリームのデータはリードバッファ５２に出力され、R videoストリームのデータはリードバッファ５５に出力される。chunk_map()を使って行われるデータの分離については後述する。
　リードバッファ５２に記憶されたL videoストリームのデータは、そのトランスポートパケットがステップＳ１において特定されたPIDに基づいてPIDフィルタ５３により抽出され、ESバッファ５４、スイッチ５９を介してデコーダ６０に供給される。リードバッファ５５に記憶されたR videoストリームのデータは、そのトランスポートパケットがステップＳ２において特定されたPIDに基づいてPIDフィルタ５６により抽出され、スイッチ５７、ESバッファ５８、およびスイッチ５９を介してデコーダ６０に供給される。
　ステップＳ８において、デコーダ６０は、スイッチ５９から順次供給されるパケットをデコードする（再生する）。
　L videoストリームとR videoストリームがそれぞれ別のTSに含まれ、それらのTSファイルがインターリーブされて光ディスク２に記録されている場合の3D再生は以上のようにして行われる。
［chunk_map()を使ったデータの分離］
　図２７は、chunk_map()のシンタクスの例を示す図である。
　number_of_chunksは、参照するチャンクの数を表す。number_of_chunks以降には、ここで指定される数だけチャンクの情報が記述される。
　SPN_chunk_start[i]は、例えば先頭のチャンクの開始位置を基準として、その基準の位置から各チャンクの開始位置までのSPN(Source Packet Number)（長さ）を表す。各チャンクの開始位置のSPNが、先頭のチャンクのものから順に記述される。
　図２８は、chunk_map()を含む、clpiファイルの具体例を示す図である。
　図２８のＡは「00001.clpi」のclpiファイルを示す図であり、number_of_source_packetsは「number_of_source_packets1」とされている。また、chunk_map()のnumber_of_chunksはn+1であり、SPN_chunk_start[i]は0,a1,a2,…,anである。
　SPN_chunk_start[i]の１番目の値0は、図２９の中段に示すように、「00001.m2ts」のm2tsファイルの先頭のチャンクの開始位置を基準として、その基準の位置から、１番目のチャンクであるL[0]の開始位置までのSPNが0であることを表す。
　２番目の値a1は、基準の位置から、２番目のチャンクであるL[1]の開始位置までのSPNがa1であることを表す。
　３番目の値a2は、基準の位置から、３番目のチャンクであるL[2]の開始位置までのSPNがa2であることを表す。
　n+1番目の値anは、基準の位置から、最後のチャンクであるL[n]の開始位置までのSPNがanであることを表す。
　図２８のＢは「00002.clpi」のclpiファイルを示す図であり、number_of_source_packetsは「number_of_source_packets2」とされている。また、chunk_map()のnumber_of_chunksはn+1であり、SPN_chunk_start[i]は0,b1,b2,…,bnである。
　SPN_chunk_start[i]の１番目の値0は、図２９の上段に示すように、「00002.m2ts」のm2tsファイルの先頭のチャンクの開始位置を基準として、その基準の位置から、１番目のチャンクであるR[0]の開始位置までのSPNが0であることを表す。
　２番目の値b1は、基準の位置から、２番目のチャンクであるR[1]の開始位置までのSPNがb1であることを表す。
　３番目の値b2は、基準の位置から、３番目のチャンクであるR[2]の開始位置までのSPNがb2であることを表す。
　n+1番目の値bnは、基準の位置から、最後のチャンクであるR[n]の開始位置までのSPNがbnであることを表す。
　分離部５１は、光ディスク２から読み出されたデータが供給された場合、図２９の下段に示すように、２つのchunk_map()の記述に基づいて、供給されたデータの先頭からb1に相当するSPN分のデータをR[0]として分離する。「00001.ilvt」のilvtファイルが読み出しファイルとして指定された場合、分離部５１には、R[0],L[0],R[1],L[1],・・・,R[n],L[n]の順に各データが供給される。
　また、分離部５１は、R[0]の終わりの位置からa1に相当するSPN分のデータをL[0]として分離し、L[0]の終わりの位置からb2-b1に相当するSPN分のデータをR[1]として分離する。分離部５１は、R[1]の終わりの位置からa2-a1に相当するSPN分のデータをL[1]として分離する。
　同様にして、分離部５１は、L[n-1]の終わりの位置から、「00002.clpi」のclpiファイルに記述されるnumber_of_source_packets2の値からbnの値を減算した値に相当するSPN分のデータをR[n]として分離する。分離部５１は、R[n]の終わりの位置から、「00001.clpi」のclpiファイルに記述されるnumber_of_source_packets1の値からanの値を減算した値に相当するSPN分のデータをL[n]として分離する。
　このように、分離部５１によるデータの分離は、chunk_map()に記述される各チャンクの長さの情報を用いて行われる。
　なお、1以外の値がMVC_file_typeに設定されているとき、chunk_map()はオプショナル(あっても無くても良い)となる。1以外の値がMVC_file_typeに設定されたPlayListを読み込んだプレーヤは、chunk_map()がPlayList中にある場合には、そのchunk_map()を無視しなければならない。
　MVC_file_type=1のとき、L videoストリームとR videoストリームの対応する2つのストリームは、それぞれ同じ数のチャンクに分割される。インターリーブされるR[i],L[i]について、添え字iの値が同じL videoストリームのチャンクとL videoストリームのチャンクは、同じ再生時間を持つ。
　図３０は、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が対応付けて登録される。EPが指定されたとき、指定されたEPのPTS_EP_start[i]とSPN_EP_start[i]に基づいて読み出し開始アドレスが特定され、ファイルの読み出しが行われる。
［PlayListファイルの具体例２］
　図３１のＡは、PlayListファイルの他の具体例を示す図である。
　図３１のＡのPlayListは、L videoストリームとR videoストリームが同じTSに含まれる場合の3D再生を制御するPlayListである。すなわち、L videoストリームのm2tsファイルとR videoストリームのm2tsファイルは、光ディスク２上でインターリーブされていない。
　この場合、図３１のＡのAppInfoPlayList()に示すようにMVC_flag=1であり、かつ、PlayItem()に示すようにMVC_file_type=0である。
　PlayItem()のClip_Information_file_nameは「00001」である。この記述から、L videoのClipを構成するclpiファイルが特定される。また、PlayItem()のIN_timeとOUT_timeから、PlayItemの再生区間の開始位置と終了位置がそれぞれ特定され、STN_table()から、L videoストリームを構成するトランスポートパケットのPIDが特定される。
　ExtensionData()のSTN_table_extension()から、R videoストリームを構成するトランスポートパケットのPIDが特定される。この例の場合、STN_table_extension()のtypeの値は1となる。
　図３１のＢは、「00001.clpi」のclpiファイルのシンタクスを示す図である。
　図３１のＢに示すように、「00001.clpi」のclpiファイルにはEP_mapが含まれる。1以外の値がMVC_file_typeに設定されており、この例においては、clpiファイルにchunk_map()が含まれていない。
　図３２は、図３１のファイルに基づいて行われるファイル管理の概念を示す図である。
　図３２に示すように、L videoストリームとR videoストリームを含む１本のTSは、「00001.m2ts」のm2tsファイルによって管理される。
　「00001.m2ts」のm2tsファイルが読み出しファイルとしてアプリケーションにより指定された場合、「00001.m2ts」のm2tsファイルの記録位置がUDF file systemにより特定され、ディスクドライブ３２により読み出される。読み出された「00001.m2ts」のm2tsファイルに含まれるL videoストリームとR videoストリームを構成するそれぞれのトランスポートパケットは、PIDに基づいて、それぞれ分離される。
［動作例２］
　図３３のフローチャートを参照して、図３１のPlayListファイルに従って行われる3D再生の処理について説明する。
　ステップＳ２１において、コントローラ３１は、STN_table()の記述から、L videoストリームを構成する、Main TSのトランスポートパケットのPIDを特定する。
　ステップＳ２２において、コントローラ３１は、STN_table_extension()の記述から、R videoストリームを構成する、Main TSのトランスポートパケットのPIDを特定する。
　ステップＳ２３において、コントローラ３１は、PlayItem()の中のClip_Information_file_nameから、L videoストリームとR videoストリームを含むm2tsファイルに対応するclpiファイルのファイル名を「00001.clpi」として特定する。MVC_flag=1であり、かつ、MVC_file_type=0であることにより、１本のMain TSにL videoストリームとR videoストリームが含まれていることは特定されている。
　ステップＳ２４において、コントローラ３１は、「00001.m2ts」を読み出しファイルとし、UDF file systemを通して、ディスクドライブ３２に光ディスク２から読み出させる。ディスクドライブ３２により読み出された、「00001.m2ts」のm2tsファイルのデータは、分離部５１を介してリードバッファ５２に供給され、記憶される。
　リードバッファ５２に記憶されたデータの中から、ステップＳ２１において特定されたPIDに基づいて、L videoストリームのトランスポートパケットがPIDフィルタ５３により抽出される。抽出されたトランスポートパケットのデータは、ESバッファ５４、スイッチ５９を介してデコーダ６０に供給される。
　また、リードバッファ５２に記憶されたデータの中から、ステップＳ２２において特定されたPIDに基づいて、R videoストリームのトランスポートパケットがPIDフィルタ５３により抽出される。抽出されたトランスポートパケットのデータは、スイッチ５７、ESバッファ５８、スイッチ５９を介してデコーダ６０に供給される。
　ステップＳ２５において、デコーダ６０は、スイッチ５９から順次供給されるパケットをデコードする（再生する）。
　L videoストリームとR videoストリームが同じTSに含まれる場合の3D再生は以上のようにして行われる。
［PlayListファイルの具体例３］
　図３４は、PlayListファイルのさらに他の具体例を示す図である。
　図３４のPlayListファイルは、L videoストリームを含むTSが光ディスク２に記録され、R videoストリームを含むTSがローカルストレージ３４に記録されている場合の3D再生を制御するPlayListである。例えば、サーバ２２からR videoストリームがダウンロードされたとき、光ディスク２に記録されているPlayListはR videoストリームに関する情報を追加するようにして更新され、ローカルストレージ３４に記録してコントローラ３１により管理される。
　図３４のAppInfoPlayList()に示すようにMVC_flag=1であり、かつ、PlayItem()に示すようにMVC_file_type=2である。
　PlayItem()のClip_Information_file_nameは「00001」である。この記述から、L videoのClipを構成するclpiファイルが特定される。また、PlayItem()のIN_timeとOUT_timeから、PlayItemの再生区間の開始位置と終了位置がそれぞれ特定され、STN_table()から、L videoストリームを構成するトランスポートパケットのPIDが特定される。
　ExtensionData()には、R videoストリームを参照するSubPathに関する情報が記述される。この例においても、通常のSubPathの数が0（number_of_SubPaths（図１１の１４行目）の値が0）とされており、R videoストリームを参照するSubPathには、SubPath_id=0が割り当てられる。図３４に示すように、SubPath_extension()中には、R videoストリームを参照するSubPathであることを表すSubPath_type_extension=8が設定される。
　ExtensionData()のSubPlayItem()のClip_Information_file_nameは「00003」である。この記述から、R videoのClipを構成するclpiファイルが特定される。「00003.clpi」のclpiファイルも、対応するR videoストリームのファイルである「00003.m2ts」のm2tsファイルとともにサーバ２２からダウンロードされ、ローカルストレージ３４に記憶されている。
　また、ExtensionData()のSubPlayItem()のSubPlayItem_IN_timeとSubPlayItem_OUT_timeから、SubPlayItemの再生区間の開始位置と終了位置がそれぞれ特定される。STN_table_extension()から、R videoストリームを参照するSubPathのIDが0であること（ref_to_SubPath_id=0）と、R videoストリームを構成するトランスポートパケットのPID（ref_to_R_video_PID）が特定される。この例の場合、STN_table_extension()のtypeの値は2となる。
　図３５は、clpiファイルのシンタクスを示す図である。
　図３５のＡは「00001.clpi」のclpiファイルの例を示す図である。図３５のＡに示すように、「00001.clpi」のclpiファイルにはEP_mapが含まれる。図３５のＢは「00003.clpi」のclpiファイルの例を示す図である。図３５のＢに示すように、「00003.clpi」のclpiファイルにもEP_mapが含まれる。
　例えば、「00001.clpi」のclpiファイルに含まれるEP_mapと「00003.clpi」のclpiファイルに含まれるEP_mapには、コンテンツの先頭の時刻t0を基準としてそれぞれ同じ時刻に設定されたEPの情報が含まれる。「00001.clpi」のclpiファイルに含まれるEP_mapを使用して再生が開始されるL videoストリームの位置と、「00003.clpi」のclpiファイルに含まれるEP_mapを使用して再生が開始されるR videoストリームの位置は、時刻t0を基準とした時間軸上では同じ時刻の位置になる。
　図３６は、図３４と図３５のファイルを用いて行われるファイル管理の概念を示す図である。
　図３６に示すように、光ディスク２に記録されたL videoストリームを含むTSは、「00001.m2ts」のm2tsファイルによって管理される。また、ローカルストレージ３４に記録されたR videoストリームを含むTSは、「00003.m2ts」のm2tsファイルによって管理される。
　BDにおいては、BDに記録されたデータとローカルストレージに記録されたデータは、BDに記録されたデータを管理する例えばUDF file systemと、ローカルストレージに記録されたデータを管理するファイルシステムとをマージした仮想的なファイルシステムによって管理される。ローカルストレージを内蔵したプレーヤは、そのような仮想的なファイルシステムを生成し、BDに記録されたデータとローカルストレージに記録されたデータを管理する。
　読み出し対象とするファイルがアプリケーションにより指定された場合、そのファイルがBDに記録されているのか、またはローカルストレージに記録されているのかと、記録メディア上の記録位置を示すアドレスが仮想ファイルシステムにより特定され、特定された記録メディアの、特定されたアドレスからファイルが読み出される。
　例えば、「00001.m2ts」のm2tsファイルがアプリケーションにより指定された場合、「00001.m2ts」のm2tsファイルが光ディスク２の所定の位置に記録されていることが仮想ファイルシステムにより特定され、ディスクドライブ３２により読み出される。
　また、「00003.m2ts」のm2tsファイルがアプリケーションにより指定された場合、「00003.m2ts」のm2tsファイルがローカルストレージ３４の所定の位置に記録されていることが仮想ファイルシステムにより特定され、読み出される。
［動作例３］
　図３７のフローチャートを参照して、図３４のPlayListファイルに従って行われる3D再生の処理について説明する。
　ステップＳ４１において、コントローラ３１は、STN_table()の記述から、L videoストリームを構成する、Main TSのトランスポートパケットのPIDを特定する。
　ステップＳ４２において、コントローラ３１は、STN_table_extension()の記述から、R videoストリームを参照するSubPathのSubPath_idの値であるref_to_SubPath_id=0を特定し、また、R videoストリームを構成するトランスポートパケットのPIDを特定する。
　ステップＳ４３において、コントローラ３１は、PlayItem()の中のClip_Information_file_nameから、L videoストリームを含むMain TSのm2tsファイルに対応するclpiファイルのファイル名を「00001.clpi」として特定する。
　ステップＳ４４において、コントローラ３１は、SubPath_entries_extension()の中でSubPath_id=0を持つ、SubPath_type=8が設定されたSubPathのSubPlayItem()の中のClip_Information_file_nameから、R videoストリームを含むm2tsファイルに対応するclpiファイルのファイル名を「00003.clpi」として特定する。
　ステップＳ４５において、コントローラ３１は、「00001.m2ts」を読み出しファイルとし、仮想ファイルシステムを通して、ディスクドライブ３２に光ディスク２から読み出させる。
　ステップＳ４６において、コントローラ３１は、「00003.m2ts」を読み出しファイルとし、仮想ファイルシステムを通して、ローカルストレージ３４から読み出す。
　ディスクドライブ３２により読み出された「00001.m2ts」のm2tsファイルのデータは、分離部５１を介してリードバッファ５２に供給され、記憶される。リードバッファ５２に記憶されたL videoストリームのデータは、そのトランスポートパケットがステップＳ４１において特定されたPIDに基づいてPIDフィルタ５３により抽出され、ESバッファ５４、スイッチ５９を介してデコーダ６０に供給される。
　一方、ローカルストレージ３４から読み出された「00003.m2ts」のm2tsファイルのデータは、分離部５１を介してリードバッファ５５に供給され、記憶される。リードバッファ５５に記憶されたR videoストリームのデータは、そのトランスポートパケットがステップＳ４２において特定されたPIDに基づいてPIDフィルタ５６により抽出され、スイッチ５７、ESバッファ５８、およびスイッチ５９を介してデコーダ６０に供給される。
　ステップＳ４７において、デコーダ６０は、スイッチ５９から順次供給されるパケットをデコードする（再生する）。
　L videoストリームを含むTSが光ディスク２に記録され、R videoストリームを含むTSがローカルストレージ３４に記録されている場合の3D再生は以上のようにして行われる。
［2D再生を行う場合の動作］
　以上のようなPlayListファイルに従って、光ディスク２に記録されているコンテンツを2D再生する場合の動作について説明する。
　ここでは、L videoストリームとR videoストリームがそれぞれ別のTSに含まれ、それらのm2tsファイルがインターリーブされて光ディスク２に記録されているものとする。光ディスク２上のデータの配置は図２５に示す配置になる。2D再生は、図２３のPlayListファイルに従って行われる。
　この場合、2D再生を行うプレーヤは、2D再生と関係のある記述だけをPlayListファイルから読み込んで処理を行う。
　図２３のPlayListファイルの記述うちの、読み込みの対象になる記述を図３８に下線を付して示す。図３８に示すように、R videoストリームの再生時に参照される情報であるExtensionData()の記述は読み込まれない。
　また、図２４のＡのclpiファイルの記述うちの、読み込みの対象になる記述を図３９のＡに下線を付して示す。図３９のＡに示すように、R videoストリームの再生時に参照される情報であるchunk_map()は読み込まれない。また、図３９のＢに示すように、「00002.clpi」のclpiファイルはその全体が読み込まれない。
　一連の処理について説明すると、2D再生を行う再生装置１は、PlayItem()の中のClip_Information_file_nameから、L videoストリームを含むm2tsファイルに対応するclpiファイルのファイル名を「00001.clpi」として特定する。また、再生装置１は、STN_table()の記述から、L videoストリームを構成するトランスポートパケットのPIDを特定する。
　再生装置１は、UDF file systemを通して、「00001.m2ts」のm2tsファイルを光ディスク２から読み出し、以降、L videoストリームを読み出したときと同様の処理を行う。すなわち、リードバッファ５２に一時的に記憶されたL videoストリームのデータは、PIDフィルタ５３、ESバッファ５４、スイッチ５９を介してデコーダ６０に供給され、再生される。再生装置１から出力されるデータはL videoストリームのデータだけであるから、表示装置３においては、L videoストリームのデータに基づいて2D画像が表示される。
　このように、図２３等を参照して説明したPlayListファイルは、3D再生に対応した再生装置において2D再生を行う場合にも、あるいは、3D再生に非対応の再生装置において2D再生を行う場合にも、利用可能なファイルとなる。これにより、3D再生に対応した再生装置用のものと、3D再生に非対応の再生装置用のものとをそれぞれ用意する必要がなく、PlayListファイルやそれを記録した光ディスク２の互換性を確保することが可能になる。
［記録装置の構成例］
　図４０は、ソフト製作処理部１０１の構成例を示すブロック図である。
　ビデオエンコーダ１１１は、図３のMVCエンコーダと同様の構成を有している。ビデオエンコーダ１１１は、複数の映像データをH.264 AVC/MVCでエンコードすることによってL videoストリームとR videoストリームを生成し、バッファ１１２に出力する。
　オーディオエンコーダ１１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ１１４に出力する。オーディオエンコーダ１１３には、L videoストリーム、R videoストリームとともにディスクに記録させるオーディオストリームが入力される。
　データエンコーダ１１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ１１６に出力する。例えば、データエンコーダ１１５は、上述したSubPath_entries_extension（図１５）やSTN_table_extension（図１８）やMVC_flag（図１２）やMVC_file_type（図１３）を設定し、図１１を参照して説明したようなPlayListファイルを生成する。
　多重化部１１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部１１８に出力する。
　誤り訂正符号化部１１８は、エラー訂正用のコードを多重化部１１７により多重化されたデータに付加する。
　変調部１１９は、誤り訂正符号化部１１８から供給されたデータに対して変調を施し、出力する。変調部１１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウエアとなる。
　このような構成を有するソフト製作処理部１０１が記録装置に設けられる。
　図４１は、ソフト製作処理部１０１を含む構成の例を示す図である。
　図４１に示す構成の一部が記録装置内に設けられることもある。
　ソフト製作処理部１０１により生成された記録信号はプリマスタリング処理部１３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部１３３に供給される。
　記録用原盤製作部１３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
　原盤記録部１３３において、プリマスタリング処理部１３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
　金属原盤製作部１３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
　成形処理部１３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
　成膜処理部１３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
　後加工処理部１３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。このようにして、再生装置１によって再生可能なデータが記録された上述した光ディスク２が完成する。
［コンピュータの構成例］
　上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
　図４２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
　CPU(Central Processing Unit)１５１、ROM(Read Only Memory)１５２、RAM(Random Access Memory)１５３は、バス１５４により相互に接続されている。
　バス１５４には、さらに、入出力インタフェース１５５が接続されている。入出力インタフェース１５５には、キーボード、マウスなどよりなる入力部１５６、ディスプレイ、スピーカなどよりなる出力部１５７が接続される。また、入出力インタフェース１５５には、ハードディスクや不揮発性のメモリなどよりなる記憶部１５８、ネットワークインタフェースなどよりなる通信部１５９、リムーバブルメディア１６１を駆動するドライブ１６０が接続される。
　以上のように構成されるコンピュータでは、CPU１５１が、例えば、記憶部１５８に記憶されているプログラムを入出力インタフェース１５５及びバス１５４を介してRAM１５３にロードして実行することにより、上述した一連の処理が行われる。
　CPU１５１が実行するプログラムは、例えばリムーバブルメディア１６１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部１５８にインストールされる。
　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
　１　再生装置，　２　光ディスク，　３　表示装置，　１１　H.264/AVCエンコーダ，　１２　H.264/AVCデコーダ，　１３　Dependent view videoエンコーダ，　１４　マルチプレクサ，　３１　コントローラ，　３２　ディスクドライブ，　３３　メモリ，　３４　ローカルストレージ，　３５　インターネットインタフェース，　３６　デコード部，　３７　操作入力部

Claims (9)

  1. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定する設定手段を備える
    　情報処理装置。
  2. 　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、
    　前記設定手段は、前記サブ再生パスを指定する情報として、前記サブ再生パスの種類が、前記Dependent view videoのストリームを参照するパスであることを表す情報と、前記Dependent view videoのストリームの属性情報であるクリップ情報のファイルのファイル名とを、前記第１のフィールドに設定する
    　請求項１に記載の情報処理装置。
  3. 　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、
    　前記設定手段は、前記サブ再生パスを指定する情報としての前記サブ再生パスのIDと、前記Dependent view videoのストリームのトランスポートパケットのPIDとを、前記第２のフィールドに設定する
    　請求項１に記載の情報処理装置。
  4. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定する
    　ステップを含む情報処理方法。
  5. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドを用いて、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とを設定する
    　ステップを含む処理をコンピュータに実行させるプログラム。
  6. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御する制御手段を備える
    　再生装置。
  7. 　前記基本ストリームと前記拡張ストリームは、それぞれ、H.264 AVC/MVCの符号化方式によってビデオストリームが符号化されることによって生成されたBase view videoのストリームとDependent view videoのストリームであり、
    　前記制御手段は、前記Dependent view videoのストリームの再生を制御することを、前記PlayListの中のメイン再生パスに関する情報が記述されるフィールドに設定された、前記Base view videoのストリームを参照するメイン再生パスを指定する情報と、前記Base view videoのストリームのトランスポートパケットのPIDを指定する情報とに基づいて行われる前記Base view videoのストリームの再生の制御とともに行う
    　請求項６に記載の再生装置。
  8. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御する
    　ステップを含む再生方法。
  9. 　コンテンツの再生を制御する情報であるPlayListの拡張フィールドの中に定義された、サブ再生パスに関する情報が記述されるフィールドである第１のフィールドと、ストリーム番号に関する情報が記述されるフィールドである第２のフィールドに設定された、所定の符号化方式でビデオストリームが符号化されることによって生成された基本ストリームと拡張ストリームのうちの、前記拡張ストリームを参照するサブ再生パスを指定する情報と、前記拡張ストリームのトランスポートパケットのPIDを指定する情報とに基づいて、前記拡張ストリームの再生を制御する
    　ステップを含む処理をコンピュータに実行させるプログラム。
PCT/JP2010/060014 2009-06-22 2010-06-14 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム WO2010150674A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
BRPI1004339A BRPI1004339A2 (pt) 2009-06-22 2010-06-14 aparelho e método de processamento de informação, programa, e, aparelho e método de reprodução
RU2011106492/08A RU2530347C2 (ru) 2009-06-22 2010-06-14 Устройство обработки информации, способ обработки информации, устройство воспроизведения, способ воспроизведения и программа
EP10791992.0A EP2309763B1 (en) 2009-06-22 2010-06-14 Information processing device, information processing method, playback device, playback method, and program
CA2732023A CA2732023C (en) 2009-06-22 2010-06-14 Information processing apparatus, information processing method, playback apparatus, playback method, and program
MX2011001760A MX2011001760A (es) 2009-06-22 2010-06-14 Aparato de procesamiento de informacion, metodo de procesamiento de informacion, aparato de reproduccion, metodo de reproduccion, y programa.
US13/059,194 US9454996B2 (en) 2009-06-22 2010-06-14 Information processing apparatus, information processing method, playback apparatus, playback method, and program
CN201080002327.2A CN102124747B (zh) 2009-06-22 2010-06-14 信息处理装置、信息处理方法、重放装置、重放方法
MYPI2011000697A MY181831A (en) 2009-06-22 2010-06-14 Information processing device, information processing method, playback device, playback method, and program
HK12100395.7A HK1160314A1 (zh) 2009-06-22 2012-01-13 信息處理裝置、信息處理方法、重放裝置、重放方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2009-147768 2009-06-22
JP2009147768 2009-06-22
JP2010-039040 2010-02-24
JP2010039040A JP4984181B2 (ja) 2009-06-22 2010-02-24 再生装置および再生方法

Publications (1)

Publication Number Publication Date
WO2010150674A1 true WO2010150674A1 (ja) 2010-12-29

Family

ID=43386445

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/060014 WO2010150674A1 (ja) 2009-06-22 2010-06-14 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム

Country Status (14)

Country Link
US (1) US9454996B2 (ja)
EP (1) EP2309763B1 (ja)
JP (1) JP4984181B2 (ja)
KR (1) KR20120111908A (ja)
CN (4) CN103079080A (ja)
BR (1) BRPI1004339A2 (ja)
CA (1) CA2732023C (ja)
HK (1) HK1160314A1 (ja)
MX (1) MX2011001760A (ja)
MY (1) MY181831A (ja)
RU (1) RU2530347C2 (ja)
SG (2) SG186639A1 (ja)
TW (1) TWI450573B (ja)
WO (1) WO2010150674A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012147350A1 (ja) * 2011-04-28 2012-11-01 パナソニック株式会社 高画質化に関わる記録媒体、再生装置、記録装置、符号化方法、復号化方法
EP2557803A1 (en) * 2010-04-08 2013-02-13 Sony Corporation Information processing device, information recording medium, information processing method, and program

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5355606B2 (ja) * 2011-03-03 2013-11-27 日本電信電話株式会社 ステレオ動画像符号化方法、装置およびプログラム
JP2013058287A (ja) * 2011-09-09 2013-03-28 Hitachi Consumer Electronics Co Ltd 記録装置／方法／媒体、再生装置／方法
MX353125B (es) 2013-06-20 2017-12-20 Sony Corp Dispositivo de reproducción, método de reproducción, y medio de registro.
GB2516825B (en) * 2013-07-23 2015-11-25 Canon Kk Method, device, and computer program for encapsulating partitioned timed media data using a generic signaling for coding dependencies
TWI683307B (zh) * 2014-09-08 2020-01-21 日商新力股份有限公司 資訊處理裝置，資訊記錄媒體及資訊處理方法以及程式

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 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
WO2006009305A1 (en) * 2004-07-22 2006-01-26 Matsushita Electric Industrial Co., Ltd. Playback apparatus for performing application-synchronized playback
JP2008252740A (ja) 2007-03-30 2008-10-16 Sony Corp リモートコマンダおよびコマンド発生方法、再生装置および再生方法、プログラム、並びに、記録媒体
WO2009133714A1 (ja) * 2008-05-01 2009-11-05 パナソニック株式会社 立体視映像を再生するための光ディスク

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1286327C (zh) * 1996-02-28 2006-11-22 松下电器产业株式会社 光盘重放装置及光盘记录装置
DE69841532D1 (de) 1997-08-29 2010-04-15 Panasonic Corp Optische Platte mit hierarchisch codiertem digitalen Videosignal, Wiedergabevorrichtung und Aufnahmevorrichtung für die optische Platte
EP1145566A1 (en) * 1999-10-21 2001-10-17 Koninklijke Philips Electronics N.V. Playback apparatus and method for playback of a record carrier
RU2273109C2 (ru) * 2000-09-07 2006-03-27 Сони Корпорейшн Способ и устройство обработки информации, программа и носитель записи
JP3925218B2 (ja) * 2002-01-30 2007-06-06 ソニー株式会社 ストリーミングシステム及びストリーミング方法、ストリーミングサーバ及びデータ配信方法、クライアント端末及びデータ復号方法、並びにプログラム及び記録媒体
CN1578984B (zh) 2002-09-05 2010-08-25 Lg电子株式会社 一种记录和再现方法及装置
JP2005115487A (ja) * 2003-10-03 2005-04-28 Sharp Corp 記録再生装置及びファイルアクセス方法
KR100585966B1 (ko) * 2004-05-21 2006-06-01 한국전자통신연구원 3차원 입체 영상 부가 데이터를 이용한 3차원 입체 디지털방송 송/수신 장치 및 그 방법
JP2006004486A (ja) * 2004-06-16 2006-01-05 Toshiba Corp 情報記録媒体及び情報再生装置
CN101640059B (zh) * 2004-07-22 2012-06-20 松下电器产业株式会社 用于执行应用程序同步重放的重放装置
EP1782424A1 (en) 2004-08-17 2007-05-09 LG Electronics Inc. Method and apparatus of reproducing data recorded on recording medium and local storage
CN101027726A (zh) * 2004-08-17 2007-08-29 Lg电子株式会社 再现记录介质和本地存储上所记录的数据的方法和装置
US7609947B2 (en) 2004-09-10 2009-10-27 Panasonic Corporation Method and apparatus for coordinating playback from multiple video sources
EP1710799B1 (en) * 2005-02-01 2012-06-20 Panasonic Corporation Reproduction apparatus
CN101006506B (zh) * 2005-02-18 2010-05-26 松下电器产业株式会社 流再现装置、流供给装置
RU2411572C2 (ru) * 2005-03-18 2011-02-10 Сони Корпорейшн Устройство обработки информации, способ обработки информации и компьютерная программа
JP4676493B2 (ja) * 2005-04-07 2011-04-27 パナソニック株式会社 記録媒体、再生装置、記録方法
JP2009505327A (ja) * 2005-08-22 2009-02-05 エルジー エレクトロニクス インコーポレーテッド 記録媒体、データ再生方法及び再生装置並びにデータ記録方法及び記録装置
JP4923751B2 (ja) * 2005-08-30 2012-04-25 ソニー株式会社 再生装置、並びに記録媒体及びその製造方法
JP4765733B2 (ja) * 2006-04-06 2011-09-07 ソニー株式会社 記録装置、記録方法および記録プログラム
JP4337849B2 (ja) * 2006-07-26 2009-09-30 ソニー株式会社 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP4957142B2 (ja) * 2006-09-21 2012-06-20 ソニー株式会社 再生装置、再生方法および再生プログラム
US8193114B2 (en) * 2006-11-15 2012-06-05 Basf Catalysts Llc Catalysts for dual oxidation of ammonia and carbon monoxide with low to no NOx formation
JP4321628B2 (ja) * 2007-05-31 2009-08-26 ソニー株式会社 記憶装置、記憶方法および記憶プログラム、ならびに、データ処理装置、データ処理方法およびデータ処理プログラム
WO2010052857A1 (ja) * 2008-11-06 2010-05-14 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
EP2416581A4 (en) * 2009-03-30 2014-03-12 Panasonic Corp RECORDING MEDIUM, PLAYING DEVICE AND INTEGRATED CIRCUIT

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 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
WO2006009305A1 (en) * 2004-07-22 2006-01-26 Matsushita Electric Industrial Co., Ltd. Playback apparatus for performing application-synchronized playback
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 EP2309763A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2557803A1 (en) * 2010-04-08 2013-02-13 Sony Corporation Information processing device, information recording medium, information processing method, and program
EP2557803A4 (en) * 2010-04-08 2014-07-16 Sony Corp INFORMATION PROCESSING DEVICE, INFORMATION RECORDING MEDIUM, INFORMATION PROCESSING METHOD, AND PROGRAM
WO2012147350A1 (ja) * 2011-04-28 2012-11-01 パナソニック株式会社 高画質化に関わる記録媒体、再生装置、記録装置、符号化方法、復号化方法
US9392246B2 (en) 2011-04-28 2016-07-12 Panasonic Intellectual Property Management Co., Ltd. Recording medium, playback device, recording device, encoding method, and decoding method related to higher image quality

Also Published As

Publication number Publication date
CN103079045A (zh) 2013-05-01
CN102124747A (zh) 2011-07-13
CA2732023C (en) 2017-12-19
EP2309763A1 (en) 2011-04-13
JP2011030187A (ja) 2011-02-10
EP2309763B1 (en) 2015-03-11
SG186639A1 (en) 2013-01-30
CN103079046A (zh) 2013-05-01
JP4984181B2 (ja) 2012-07-25
CA2732023A1 (en) 2010-12-29
RU2011106492A (ru) 2012-08-27
CN103079080A (zh) 2013-05-01
SG186640A1 (en) 2013-01-30
RU2530347C2 (ru) 2014-10-10
TW201132111A (en) 2011-09-16
CN102124747B (zh) 2016-07-06
KR20120111908A (ko) 2012-10-11
CN103079046B (zh) 2015-07-01
BRPI1004339A2 (pt) 2016-03-15
MY181831A (en) 2021-01-08
TWI450573B (zh) 2014-08-21
HK1160314A1 (zh) 2012-08-10
US9454996B2 (en) 2016-09-27
US20110145432A1 (en) 2011-06-16
MX2011001760A (es) 2011-03-28
EP2309763A4 (en) 2013-03-13

Similar Documents

Publication Publication Date Title
JP4984183B2 (ja) 再生装置、再生方法、および記録方法
JP4984181B2 (ja) 再生装置および再生方法
JP2010244630A (ja) 情報処理装置、情報処理方法、プログラム、及び、データ構造
JP4984184B2 (ja) 再生装置および再生方法
JP4984187B2 (ja) 記録方法
JP4985895B2 (ja) 再生装置、再生方法、および記録方法
JP4984194B2 (ja) 記録方法
JP2010244629A (ja) 情報処理装置、情報処理方法、プログラム、および記録媒体
JP2010244635A (ja) 情報処理装置、情報処理方法、再生装置、再生方法、プログラム、および記録媒体
JP2010245916A (ja) 情報処理装置、情報処理方法、およびプログラム
JP2012124925A (ja) 記録方法
JP2012120233A (ja) 再生装置、再生方法、および記録方法

Legal Events

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

Ref document number: 201080002327.2

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2732023

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2010791992

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20117003377

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13059194

Country of ref document: US

Ref document number: 1118/DELNP/2011

Country of ref document: IN

Ref document number: MX/A/2011/001760

Country of ref document: MX

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

Ref document number: 10791992

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011106492

Country of ref document: RU

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: PI1004339

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20110215