[go: up one dir, main page]

WO2010116998A1 - 記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体 - Google Patents

記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体 Download PDF

Info

Publication number
WO2010116998A1
WO2010116998A1 PCT/JP2010/056237 JP2010056237W WO2010116998A1 WO 2010116998 A1 WO2010116998 A1 WO 2010116998A1 JP 2010056237 W JP2010056237 W JP 2010056237W WO 2010116998 A1 WO2010116998 A1 WO 2010116998A1
Authority
WO
WIPO (PCT)
Prior art keywords
picture
stream
video
data
view video
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2010/056237
Other languages
English (en)
French (fr)
Inventor
しのぶ 服部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to US12/995,639 priority Critical patent/US8792780B2/en
Priority to CN201080001745.XA priority patent/CN102047674B/zh
Priority to HK11111733.6A priority patent/HK1157546B/xx
Priority to EP10761697.1A priority patent/EP2285130A4/en
Publication of WO2010116998A1 publication Critical patent/WO2010116998A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • 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/106—Processing image signals
    • H04N13/156—Mixing image signals
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365—Multiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347—Demultiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H04N9/8045—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 using predictive coding
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs

Definitions

  • the present invention relates to a recording apparatus, a recording method, a reproducing apparatus, a reproducing method, a program, and a recording medium, and in particular, synchronizes a basic stream and an extended stream obtained by encoding a plurality of video data using a predetermined encoding method.
  • the present invention relates to a recording apparatus, a recording method, a reproducing apparatus, a reproducing method, a program, and a recording medium that can be secured.
  • 2D image content is the mainstream content for movies and the like, but recently, stereoscopic image content capable of stereoscopic viewing has attracted attention.
  • a dedicated device is required to display a stereoscopic image.
  • a stereoscopic device for example, there is an IP (Integral Photography) stereoscopic image system developed by NHK (Japan Broadcasting Corporation).
  • Stereoscopic image data consists of image data from a plurality of viewpoints (image data taken from a plurality of viewpoints), and the more viewpoints and the wider the viewpoint, the more the subject can be viewed from various directions. In other words, it is possible to realize a “peek TV” that can be seen.
  • the stereo image having the smallest number of viewpoints is a stereo image having two viewpoints (so-called 3D image).
  • the image data of the stereo image includes left image data that is an image observed with the left eye and right image data that is an image observed with the right eye.
  • the BD standard does not stipulate how image data of a stereoscopic image including a stereo image is recorded and reproduced on the BD.
  • the image data of a stereo image is composed of two data streams: a left image data stream and a right image data stream. For this reason, it is necessary to record these two data streams on the BD so that they can be reproduced while ensuring synchronization.
  • the recording apparatus includes a basic stream and an extended stream obtained by encoding a plurality of video data by a predetermined encoding method in different transport streams and recording the recording medium on the recording medium.
  • a packet that stores data of each of the first picture and the second picture that are in the same position in decoding order among the first picture that constitutes the stream and the second picture that constitutes the extension stream The same DTS based on the same PCR is set, and the same PTS based on the same PCR is set in the packet storing the data of the first picture and the second picture at the same position in the display order. Coding means for setting and coding is provided.
  • the recording method includes a basic stream and an extended stream obtained by encoding a plurality of video data by a predetermined encoding method in different transport streams for recording on a recording medium.
  • a packet that stores data of each of the first picture and the second picture that are in the same position in decoding order among the first picture that constitutes the stream and the second picture that constitutes the extension stream The same DTS based on the same PCR is set, and the same PTS based on the same PCR is set in the packet storing the data of the first picture and the second picture at the same position in the display order. Setting and encoding.
  • the program according to an aspect of the present invention includes the basic stream and the extended stream obtained by encoding a plurality of video data by a predetermined encoding method in a different transport stream and recorded on a recording medium.
  • the computer is caused to execute processing including the step of performing encoding.
  • a recording medium includes a first picture constituting a basic stream and a second picture constituting an extension stream obtained by encoding a plurality of video data by a predetermined encoding method.
  • the same DTS based on the same PCR is set in the packet storing the data of the first picture and the second picture at the same position in the decoding order, and the first picture at the same position in the display order.
  • the basic stream and the extension stream in which the same PTS with the same PCR as the reference is set in the packet storing the data of each of the second picture and the second picture.
  • the program according to another aspect of the present invention acquires a basic stream and an extended stream obtained by encoding a plurality of video data included in different transport streams recorded on a recording medium using a predetermined encoding method. Then, the data of the first picture and the second picture at the same position in the decoding order of the first picture constituting the basic stream and the second picture constituting the extension stream are respectively Packets that are set in the packet to be stored, are decoded based on the same DTS based on the same PCR, and store the data of the first picture and the second picture at the same position in the display order
  • the computer includes a process including a step of outputting the data of the decoding result based on the same PTS based on the same PCR set in To be executed.
  • a basic stream and an extension stream obtained by encoding a plurality of video data included in different transport streams recorded on a recording medium by a predetermined encoding method are acquired.
  • Storing the data of the first picture and the second picture in the same position in the decoding order of the first picture constituting the basic stream and the second picture constituting the extension stream Packets that are set based on the same DTS based on the same PCR and that store the data of the first picture and the second picture that are in the same position in the display order.
  • the decoding result data is output based on the same PTS set with reference to the same PCR.
  • FIG. 12 is a diagram illustrating the syntax of PlayList () in FIG. 11.
  • FIG. 16 is a diagram illustrating the syntax of SubPath () in FIG. 15.
  • FIG. 17 is a diagram illustrating the syntax of SubPlayItem (i) in FIG. 16. [Fig. 16] Fig. 16 is a diagram illustrating the syntax of PlayItem () in Fig. 15. Fig.
  • FIG. 19 is a diagram illustrating the syntax of STN_table () in Fig. 18. It is a block diagram which shows the structural example of the reproducing
  • FIG. 32 is a diagram illustrating still another configuration example of the 3D video TS generation unit provided in the recording device. It is a figure which shows the structure by the side of the reproducing
  • FIG. 46 is a diagram conceptually illustrating an EP_map corresponding to the Clip AV stream of FIG. It is a figure which shows the example of the data structure of the source packet which SPN_EP_start points out. It is a block diagram which shows the structural example of the hardware of a computer.
  • 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.
  • 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. Similarly, the sound is reproduced by the reproducing apparatus 1 and output from a speaker or the like provided in the display apparatus 3.
  • the type 1 display method consists of 3D image data consisting of data for an image observed with the left eye (L image) and data for an image observed with the right eye (R image).
  • 3D images are displayed by alternately displaying.
  • the type 2 display method is a method for displaying a 3D image by displaying an L image and an R image that are generated using the original image data and the depth data, which are the images from which the 3D image is generated. It is. 3D image data used in the type 2 display method includes original image data and depth data that can generate an L image and an R image by giving the original image.
  • the type 1 display method is a display method that requires glasses when viewing.
  • the type 2 display method is a display method in which 3D images can be viewed without glasses.
  • H.264 AVC Advanced Video Coding
  • MVC Multi-view Video coding
  • shooting is performed on the same subject using an L image camera and an R image camera.
  • An elementary stream of video shot by the L image camera and the R image camera is input to the MVC encoder.
  • the MVC encoder 11 includes an H.264 / AVC encoder 21, an H.264 / AVC decoder 22, a Depth calculation unit 23, a dependent view video encoder 24, and a multiplexer 25.
  • the stream of video # 1 captured by the L image camera is input to the H.264 / AVC encoder 21 and the depth calculator 23. Also, the stream of video # 2 captured by the R image camera is input to the Depth calculation unit 23 and the DependentDependview video encoder 24. The stream of video # 2 may be input to the H.264 / AVC encoder 21 and the depth calculation unit 23, and the stream of video # 1 may be input to the depth calculation unit 23 and the dependent video view 24 encoder 24.
  • the H.264 / AVC encoder 21 encodes the video # 1 stream, for example, as an H.264 AVC / High Profile video stream.
  • the H.264 / AVC encoder 21 outputs the AVC video stream obtained by encoding to the H.264 / AVC decoder 22 and the multiplexer 25 as a Base view video stream.
  • the H.264 / AVC decoder 22 decodes the AVC video stream supplied from the H.264 / AVC encoder 21 and outputs the video # 1 stream obtained by decoding to the DependentDependview video encoder 24.
  • the Depth calculation unit 23 calculates Depth based on the stream of video # 1 and the stream of video # 2, and outputs the calculated depth data to the multiplexer 25.
  • the Dependent video video encoder 24 encodes the video # 1 stream supplied from the H.264 / AVC decoder 22 and the video # 2 stream input from the outside, and outputs a Dependent video video stream.
  • Base view ⁇ video does not allow predictive encoding using another stream as a reference image, but as shown in FIG. 4, Dependent view video allows predictive encoding using Base ⁇ ⁇ view video as a reference image.
  • Dependent view video allows predictive encoding using Base ⁇ ⁇ view video as a reference image.
  • the L image is Base view video and the R image is encoded as Dependent view video
  • the data amount of the resulting Dependent view video stream is smaller than the data amount of the Base view video stream .
  • the Dependent view video encoder 24 outputs the Dependent view video stream obtained by encoding using such prediction between views to the multiplexer 25.
  • the multiplexer 25 includes the Base view video stream supplied from the H.264 / AVC encoder 21, the Dependent view video stream (Depth data) supplied from the Depth calculation unit 23, and the Dependent supplied from the Dependent view video encoder 24.
  • the view video stream is multiplexed as, for example, MPEG2 TS.
  • the Base view video stream and the Dependent view video stream may be multiplexed into one MPEG2 TS, or may be included in separate MPEG2 TS.
  • the multiplexer 25 outputs the generated TS (MPEG2 TS).
  • the TS output from the multiplexer 25 is recorded on the optical disc 2 together with other management data in the recording device, and is provided to the reproducing device 1 in a form recorded on the optical disc 2.
  • D1 view video When it is necessary to distinguish between Dependent view video used with Base view video in the Type 1 display method and Dependent view video (Depth) used with Base view video in the Type2 display method, the former is referred to as D1 view video. Good, the latter is called D2 view video.
  • 3D playback in the type 1 display method which is performed using Base video and D1 video
  • B-D1 playback 3D playback in the type 2 display method performed using Base view video and D2 view video.
  • the playback device 1 When the playback apparatus 1 performs B-D1 playback in response to an instruction from the user, the playback device 1 reads the Base view video stream and the D1 view video stream from the optical disc 2 and plays them back.
  • the playback device 1 reads the Base view video stream and D2 view video stream from the optical disc 2 and plays them back.
  • the playback device 1 reads and plays back only the Base view video stream from the optical disc 2 when playing back a normal 2D image.
  • 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.
  • Dependent viewDvideo is D1 view video
  • D1 view video When it is simply Dependent view video, it represents D1 view video.
  • D2 view video is also recorded and reproduced on the optical disc 2 in the same manner as D1 view video.
  • FIG. 5 is a diagram illustrating a configuration example of a TS.
  • Main TS and Sub TS are recorded.
  • the Main TS is a TS including at least the Base view video stream.
  • the Sub-TS is a TS that includes a stream other than the Base-view-video stream and is used together with the Main-TS.
  • ⁇ Streams of Base view and Dependent view are also prepared for PG and IG, which will be described later, so that 3D display is possible as well as video.
  • PG and IG Base view planes obtained by decoding each stream are combined with the Base view video plane obtained by decoding the Base video stream and displayed. Similarly, the Dependent view video plane of PG and IG is combined with the Dependent view video plane obtained by decoding the Dependent view video stream and displayed.
  • the base video view stream is also an R image graphics stream for PG and IG.
  • the PG stream and IG stream of DependentIGview are L image graphics streams.
  • FIG. 6 is a diagram illustrating another configuration example of the TS.
  • each stream of Primary audio, Base PG, Dependent PG, Base IG and Dependent IG is multiplexed in Sub TS.
  • the video stream may be multiplexed on the Main TS, and the PG, IG stream, etc. may be multiplexed on the Sub TS.
  • FIG. 7 is a diagram showing still another configuration example of the TS.
  • the Dependent video stream may be included in a different TS from the Base video stream.
  • each stream of Dependent view video, Base PG, Dependent PG, Base IG, and Dependent IG is multiplexed in Sub TS.
  • FIG. 8 is a diagram illustrating an example of AV stream management performed 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 only on the optical disc 2 but also on the local storage of the playback device 1.
  • a pair of Clip Information which is one AV stream and information accompanying it is considered as one object, and these are collectively called Clip.
  • a file storing an AV stream is referred to as an AV stream file.
  • a file storing ClipCInformation is also called a Clip Information file.
  • the AV stream is developed on the time axis, and the access point of each Clip is mainly designated in the PlayList with a time stamp.
  • the Clip Information file is used for finding an address in the AV stream where decoding should start.
  • PlayList is a collection of AV stream playback sections.
  • One playback section in the AV stream is called PlayItem.
  • PlayItem is represented by a pair of IN point and OUT point of the playback section on the time axis. As shown in FIG. 8, the PlayList is composed of one or a plurality of PlayItems.
  • the first PlayList from the left in FIG. 8 is composed of two PlayItems, and the two PlayItems refer to the first half and the second half of the AV stream included in the left Clip, respectively.
  • the second PlayList from the left is composed of one PlayItem, whereby the entire AV stream included in the right Clip is referenced.
  • the third PlayList from the left is composed of two PlayItems, and the two PlayItems refer to a part of the AV stream included in the left Clip and a part of the AV stream included in the right Clip, respectively. .
  • the PlayList is used as playback management information for managing playback of AV streams.
  • a playback path created by an array of one or more PlayItems in a PlayList is called a main path.
  • a playback path created by arranging one or more SubPlayItems in parallel with the main path is called a sub path.
  • FIG. 9 is a diagram showing the structure of the main path and the sub path.
  • the above-described Base view video stream is managed as a stream that is referenced by PlayItems that constitute Main Path.
  • the Dependent view video stream is managed as a stream that is referenced by the SubPlayItem that constitutes the Sub Path.
  • the PlayItems that make up the Main Path are set with IDs in order from the top.
  • the Clip AV stream referenced by one PlayItem includes at least a video stream (main image data).
  • the Clip AV stream may or may not include one or more audio streams that are played back at the same timing (synchronously) as the video stream included in the Clip AV stream.
  • the Clip AV stream may or may not include one or more bitmap subtitle data (PG (Presentation Graphic)) streams that are played back in synchronization with the video stream included in the Clip AV stream. Also good.
  • PG Presentation Graphic
  • the Clip AV stream may or may not include one or more IG (Interactive Graphic) streams that are played back in synchronization with the video stream included in the Clip AV stream file.
  • the IG stream is used to display graphics such as buttons operated by the user.
  • a video stream and zero or more audio streams, zero or more PG streams, and zero or more IG streams reproduced in synchronization therewith are multiplexed. Yes.
  • one SubPlayItem refers to a video stream, an audio stream, a PG stream, or the like, which is a stream (different stream) different from the Clip AV stream referred to by the PlayItem.
  • Such AV stream management using PlayList, PlayItem, and SubPlayItem is described in, for example, Japanese Unexamined Patent Application Publication Nos. 2008-252740 and 2005-348314.
  • FIG. 10 is a diagram illustrating an example of a management structure of files recorded on the optical disc 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.
  • An Index file that is a file with the name “Index.bdmv” and a MovieObject file that is a file with the name “MovieObject.bdmv” are stored directly under the BDMV directory.
  • BACKUP directory PLAYLIST directory, CLIPINF directory, STREAM directory, etc. are provided under the BDMV directory.
  • the PLAYLIST directory stores a PlayList file that describes the PlayList.
  • Each PlayList file has a name that is a combination of a 5-digit number and an extension “.mpls”. In one PlayList file shown in FIG. 10, a file name “00000.mpls” is set.
  • the Clip Information file is stored in the CLIPINF directory. Each Clip Information file is set with a name combining a five-digit number and the extension “.clpi”.
  • the file names “00001.clpi”, “00002.clpi”, and “00003.clpi” are set in the three Clip information files in FIG.
  • the Clip Information file is referred to as a clpi file as appropriate.
  • the “00001.clpi” clpi file is a file in which information related to the clip of Base view video is described.
  • the "00002.clpi" clpi file is a file that describes information related to the clip of D2 video.
  • the “00003.clpi” clpi file is a file that describes information related to the clip of D1 video.
  • Stream file is stored in STREAM directory.
  • Each stream file is set with a name combining a 5-digit number and an extension “.m2ts”, or a name combining a 5-digit number and an extension “.ilvt”.
  • a file with the extension “.m2ts” is appropriately referred to as an m2ts file.
  • a file with the extension “.ilvt” is called an ilvt file.
  • the m2ts file of“ 00001.m2ts ” is a file for 2D playback. By specifying this file, the Base view video stream is read.
  • the m2ts file of“ 00002.m2ts ” is the file of the D2 view video stream
  • the m2ts file of“ 00003.m2ts ” is the file of the D1 view video stream.
  • a directory for storing audio stream files is also provided under the BDMV directory.
  • FIG. 11 is a diagram illustrating the syntax of the PlayList file.
  • the PlayList file is a file with an extension “.mpls” stored in the PLAYLIST directory of FIG.
  • Version_number represents the version number of “xxxx.mpls”.
  • version_number consists of a 4-digit number. For example, “0240” indicating “3D Spec version” is set in the PlayList file for 3D playback.
  • PlayList_start_address represents the start address of PlayList () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • PlayListMark_start_address represents the start address of PlayListMark () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • ExtensionData_start_address represents the start address of ExtensionData () with the relative number of bytes from the start byte of the PlayList file as a unit.
  • ExtensionData_start_address After the ExtensionData_start_address, a 160-bit reserved_for_future_use is included.
  • AppInfoPlayList stores parameters related to playback control of the PlayList, such as playback restrictions.
  • PlayList parameters related to Main Path and Sub Path are stored. The contents of PlayList () will be described later.
  • PlayListMark stores PlayList mark information, that is, information about a mark that is a jump destination (jump point) in a user operation or command that commands chapter jump or the like.
  • ExtensionData Private data can be inserted into ExtensionData ().
  • FIG. 12 is a diagram showing a specific example of the description of the PlayList file.
  • View_type indicates whether the Base view video stream managed by the PlayList is an L image (L view) stream or an R image (R view) stream.
  • FIG. 13 is a diagram showing the meaning of the value of 3D_PL_type.
  • 3D_PL_type of 00 represents a PlayList for 2D playback.
  • the value 01 of 3D_PL_type represents a PlayList for B-D1 playback out of 3D playback.
  • the value 10 of 3D_PL_type represents a PlayList for B-D2 playback of 3D playback.
  • 3DPlayList information is registered in the ExtensionData () of the PlayList file.
  • 3DPlayList information information regarding reading of the Base view video stream and the Dependent view video stream from the optical disc 2 is registered.
  • FIG. 14 is a diagram illustrating the meaning of the value of the view_type.
  • the value 0 of the view_type indicates that the Base3view video stream is an L view stream when performing 3D playback. When 2D playback is performed, this indicates that the Base view video stream is an AVC video stream.
  • the value 1 of the view_type indicates that the Base view video stream is an R view stream.
  • the playback device 1 can identify whether the Base view video stream is an L view stream or an R view stream.
  • the playback device 1 is required to output the L view signal and the R view signal after distinguishing them from each other.
  • the playback device 1 By making it possible to identify whether the Base view video stream is an L view stream or an R view stream, the playback device 1 outputs the L view signal and the R view signal separately. It becomes possible.
  • FIG. 15 is a diagram showing the syntax of PlayList () in FIG.
  • Length is a 32-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of PlayList (). That is, length represents the number of bytes from reserved_for_future_use to the end of the PlayList.
  • a 16-bit reserved_for_future_use is prepared after the length.
  • FIG. 16 is a diagram showing the syntax of SubPath () in FIG.
  • Length is a 32-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of Sub-Path (). That is, length represents the number of bytes from reserved_for_future_use to the end of the PlayList.
  • a 16-bit reserved_for_future_use is prepared after the length.
  • SubPath_type is an 8-bit field that indicates the type of Sub-Path application.
  • SubPath_type is used, for example, when the type indicates whether Sub-Path is audio, bitmap subtitle, or text subtitle.
  • Is_repeat_SubPath is a 1-bit field that specifies the Sub-Path playback method, and indicates whether the Sub-Path playback is repeated during the Main Path playback or the Sub-Path playback is performed only once. For example, it is used when the playback timing of the Clip referenced by the Main Path differs from that of the Clip referenced by the Sub Path (when using the Main Path as a slideshow path for still images and the Sub Path as background music) The
  • FIG. 17 is a diagram showing the syntax of SubPlayItem (i) in FIG.
  • “Length” is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of SubItemplayItem ().
  • the SubPlayItem (i) in FIG. 17 is described separately when the SubPlayItem refers to one Clip and when it refers to a plurality of Clips.
  • SubPlayItem refers to one Clip.
  • Clip_Information_file_name [0] represents the clip to be referenced.
  • Clip_codec_identifier [0] represents the codec system of Clip. Reserved_for_future_use is included after Clip_codec_identifier [0].
  • Is_multi_Clip_entries is a flag indicating whether or not a multi-clip is registered.
  • is_multi_Clip_entries flag is set, the syntax when SubPlayItem refers to a plurality of Clips is referenced.
  • Ref_to_STC_id [0] is information related to STC discontinuities (system time base discontinuities).
  • SubPlayItem_IN_time represents the start position of the Sub-Path playback section
  • SubPlayItem_OUT_time represents the end position
  • Sync_PlayItem_id and sync_start_PTS_of_PlayItem represent the time at which the Sub-Path starts to play on the Main-Path time axis.
  • SubPlayItem_IN_time, SubPlayItem_OUT_time, sync_PlayItem_id, and sync_start_PTS_of_PlayItem are commonly used in the Clip referred to by SubPlayItem.
  • Num_of_Clip_entries represents the number of clips to be referenced.
  • the number of Clip_Information_file_name [SubClip_entry_id] specifies the number of Clips excluding Clip_Information_file_name [0].
  • Chip_codec_identifier [SubClip_entry_id] represents the codec system of Clip.
  • Ref_to_STC_id [SubClip_entry_id] is information related to STC discontinuity points (system time base discontinuity points). Reserved_for_future_use is included after ref_to_STC_id [SubClip_entry_id].
  • FIG. 18 is a diagram showing the syntax of PlayItem () in FIG.
  • Length is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of PlayItem ().
  • Clip_Information_file_name [0] represents the name of the Clip Information file of the Clip referred to by PlayItem.
  • the file name of the mt2s file including the clip and the file name of the corresponding Clip Information file include the same 5-digit number.
  • Clip_codec_identifier [0] represents the codec system of Clip. Reserved_for_future_use is included after Clip_codec_identifier [0]. is_multi_angle and connection_condition are included after reserved_for_future_use.
  • Ref_to_STC_id [0] is information related to STC discontinuities (system time base discontinuities).
  • IN_time represents the start position of the PlayItem playback section
  • OUT_time represents the end position
  • STN_table () includes AV stream information referenced by the target PlayItem.
  • information on the AV stream that is referenced by the SubPlayItem that constitutes the Sub-Path is also included.
  • FIG. 19 is a diagram illustrating the syntax of STN_table () in FIG.
  • STN_table () is set as an attribute of PlayItem.
  • Length is a 16-bit unsigned integer indicating the number of bytes from immediately after this length field to the end of STN_table (). 16-bit reserved_for_future_use is prepared after the length.
  • Numberer_of_video_stream_entries represents the number of streams to which video_stream_id is given (registered) in STN_table ().
  • Video_stream_id is information for identifying a video stream. For example, a Base view video stream is specified by this video_stream_id.
  • Video_stream_number is a video stream number that is used for video switching and is visible to the user.
  • “Number_of_audio_stream_entries” represents the number of streams of the first audio stream to which audio_stream_id is given, which is entered in STN_table ().
  • the audio_stream_id is information for identifying the audio stream
  • the audio_stream_number is an audio stream number that can be seen by the user used for audio switching.
  • “Number_of_audio_stream2_entries” represents the number of streams of the second audio stream to which audio_stream_id2 is provided, which is entered in STN_table ().
  • the audio_stream_id2 is information for identifying an audio stream
  • the audio_stream_number is an audio stream number that can be seen by the user used for audio switching. In this example, the sound to be reproduced can be switched.
  • “Number_of_PG_txtST_stream_entries” represents the number of streams to which PG_txtST_stream_id is entered in STN_table ().
  • a PG stream obtained by run-length encoding a bitmap subtitle and a text subtitle file (txtST) are entered.
  • PG_txtST_stream_id is information for identifying a subtitle stream
  • PG_txtST_stream_number is a subtitle stream number that can be seen by the user used for subtitle switching.
  • “Number_of_IG_stream_entries” represents the number of streams that are entered in STN_table () and given IG_stream_id. In this, the IG stream is entered.
  • IG_stream_id is information for identifying the IG stream, and
  • IG_stream_number is a graphics stream number that can be seen by the user used for graphics switching.
  • Main TS and Sub TS are also registered in STN_table (). It is described in stream_attribute () that the ID is not the elementary stream but the TS ID.
  • FIG. 20 is a block diagram illustrating a configuration example of the playback device 1.
  • the controller 51 executes a control program prepared in advance and controls the overall operation of the playback device 1.
  • the controller 51 controls the disk drive 52 to read a PlayList file for 3D playback. Further, the controller 51 reads Main TS and SubTS based on the ID registered in the STN_table and supplies them to the decoder unit 56.
  • the disk drive 52 reads data from the optical disk 2 under the control of the controller 51 and outputs the read data to the controller 51, the memory 53, or the decoder unit 56.
  • the memory 53 appropriately stores data necessary for the controller 51 to execute various processes.
  • the local storage 54 is composed of an HDD (Hard Disk Drive), for example.
  • HDD Hard Disk Drive
  • a Dependent view video stream downloaded from the server 72 is recorded.
  • the stream recorded in the local storage 54 is also supplied to the decoder unit 56 as appropriate.
  • the Internet interface 55 communicates with the server 72 via the network 71 according to the control from the controller 51, and supplies the data downloaded from the server 72 to the local storage 54.
  • the decoder unit 56 decodes the stream supplied from the disk drive 52 or the local storage 54 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 57 includes an input device such as a button, a key, a touch panel, a jog dial, and a mouse, and a reception unit that receives a signal such as an infrared ray transmitted from a predetermined remote commander.
  • the operation input unit 57 detects a user operation and supplies a signal representing the content of the detected operation to the controller 51.
  • FIG. 21 is a diagram illustrating a configuration example of the decoder unit 56.
  • FIG. 21 shows a configuration for processing a video signal.
  • the decoder unit 56 also performs audio signal decoding processing.
  • the result of the decoding process performed on the audio signal is output to the display device 3 via a path (not shown).
  • the PID filter 101 identifies whether the TS supplied from the disk drive 52 or the local storage 54 is a Main TS or a Sub TS, based on the PID of a packet constituting the TS, the ID of a stream, or the like.
  • the PID filter 101 outputs Main TS to the buffer 102 and Sub TS to the buffer 103.
  • the PID filter 104 sequentially reads Main TS packets stored in the buffer 102 and distributes them based on the PID.
  • the PID filter 104 outputs a packet constituting the Base video stream included in the Main TS to the B video buffer 106, and outputs a packet constituting the Dependent video stream to the switch 107.
  • the PID filter 104 outputs a packet constituting the Base IG stream included in the Main TS to the switch 114, and outputs a packet constituting the Dependent IG stream to the switch 118.
  • the PID filter 104 outputs a packet constituting the Base PG stream included in the Main TS to the switch 122, and outputs a packet constituting the Dependent PG stream to the switch 126.
  • the Base video, Dependent view video, Base PG, Dependent PG, Base IG, and Dependent IG streams may be multiplexed in the Main TS.
  • the PID filter 105 outputs a packet constituting the Dependent view video stream included in the Sub TS to the switch 107.
  • the switch 107 outputs a packet constituting the Dependent video video stream supplied from the PID filter 104 or the PID filter 105 to the video buffer 108.
  • the switch 109 sequentially reads out the Base video video packet stored in the B video buffer 106 and the Dependent video video packet stored in the D video buffer 108 according to time information that defines the decoding timing. For example, the same time information is set in a packet storing data of a picture with Base view video and a packet storing data of a picture of Dependent view video corresponding thereto.
  • the switch 109 outputs the packet read from the B video buffer 106 or the D video buffer 108 to the video decoder 110.
  • the video decoder 110 decodes the packet supplied from the switch 109, and outputs Base view video or Dependent view video data obtained by decoding to the switch 111.
  • the switch 111 outputs the data obtained by decoding the Base view video packet to the B video plane generation unit 112, and outputs the data obtained by decoding the Dependent view video packet to the D video plane generation unit 113. To do.
  • the D video plane generating unit 113 generates a Dependent video video plane based on the data supplied from the switch 111 and outputs the generated plane to the synthesizing unit 130.
  • the switch 114 outputs a packet constituting the Base IG stream supplied from the PID filter 104 or the PID filter 105 to the B IG buffer 115.
  • the B IG decoder 116 decodes the packets constituting the Base IG stream stored in the B IG buffer 115 and outputs the data obtained by decoding to the B IG plane generation unit 117.
  • the B IG plane generation unit 117 generates a Base IG plane based on the data supplied from the B IG decoder 116, and outputs the generated plane to the synthesis unit 130.
  • the switch 118 outputs a packet constituting the Dependent19IG stream supplied from the PID filter 104 or the PID filter 105 to the D IG buffer 119.
  • the D IG decoder 120 decodes the packets constituting the Dependent IG stream stored in the D IG buffer 119, and outputs the decoded data to the D IG plane generation unit 121.
  • the D IG plane generation unit 121 generates a Dependent IG plane based on the data supplied from the D IG decoder 120 and outputs the generated plane to the synthesis unit 130.
  • the switch 122 outputs a packet constituting the Base PG stream supplied from the PID filter 104 or the PID filter 105 to the B PG buffer 123.
  • the B PG decoder 124 decodes the packets constituting the Base PG stream stored in the B PG buffer 123 and outputs the data obtained by decoding to the B PG plane generation unit 125.
  • the B PG plane generating unit 125 generates a Base PG plane based on the data supplied from the B PG decoder 124 and outputs the generated data to the synthesizing unit 130.
  • the switch 126 outputs the packets constituting the Dependent ⁇ PG stream supplied from the PID filter 104 or the PID filter 105 to the D PG buffer 127.
  • the D PG decoder 128 decodes the packets constituting the Dependent PG stream stored in the D PG buffer 127, and outputs the data obtained by decoding to the D PG plane generation unit 129.
  • the D PG plane generation unit 129 generates a Dependent PG plane based on the data supplied from the D PG decoder 128, and outputs the generated plane to the synthesis unit 130.
  • the combining unit 130 includes the Base ⁇ view video plane supplied from the B video plane generation unit 112, the Base IG plane supplied from the B IG plane generation unit 117, and the Base PG supplied from the B PG plane generation unit 125. Are combined in a predetermined order to generate a Base view plane.
  • the synthesis unit 130 is supplied from the Dependent view ⁇ video plane supplied from the D video plane generation unit 113, the Dependent IG plane supplied from the D IG plane generation unit 121, and the D PG plane generation unit 129. Synthesize Dependent PG planes in a predetermined order to generate a Dependent view plane.
  • the composition unit 130 outputs the data of the Base view plane and the Dependent view plane.
  • the video data output from the synthesizing unit 130 is output to the display device 3, and 3D display is performed by alternately displaying the Base ⁇ ⁇ ⁇ ⁇ view plane and the Dependent view plane.
  • T-STD Transport stream-System. Target Decoder
  • FIG. 22 is a diagram showing a configuration for processing a video stream.
  • FIG. 22 the same components as those shown in FIG. 21 are denoted by the same reference numerals.
  • a PID filter 104 a B video buffer 106, a switch 107, a D ⁇ ⁇ ⁇ ⁇ video buffer 108, a switch 109, a video decoder 110, and a DPB (Decoded Picture Buffer) 151 are shown.
  • a DPB 151 for storing decoded picture data is provided at the subsequent stage of the video decoder 110.
  • the PID filter 104 outputs a packet constituting the Base video stream included in the Main TS to the B video buffer 106 and outputs a packet constituting the Dependent view video stream to the switch 107.
  • PID 0 is assigned as a fixed value of PID to the packets that make up the Base view video stream. Also, a fixed value other than 0 is assigned as a PID to the packets constituting the Dependent view video stream.
  • the packet output to the B video buffer 106 is stored in VSB 1 via TB (Transport Buffer) 1 and MB (Multiplexing Buffer) 1 .
  • VSB 1 stores elementary stream data of Base view video.
  • the switch 107 is supplied not only with the packet output from the PID filter 104 but also with the packet constituting the Dependent view video stream extracted from the Sub TS in the PID filter 105 of FIG.
  • the switch 107 When the packet constituting the Dependent view video stream is supplied from the PID filter 104, the switch 107 outputs it to the D video buffer 108.
  • the switch 107 outputs it to the D video buffer 108.
  • the packet output to the D video buffer 108 is stored in VSB 2 via TB 2 and MB 2 .
  • VSB 2 stores elementary stream data of Dependent view video.
  • the switch 109 outputs the packet of the Base view video and the packet of the Dependent view video at the same time, such as outputting the packet of the Dependent view video at the same time immediately after outputting the packet of the Base view video at a certain time. Subsequently, the data is output to the video decoder 110.
  • the packet that stores the data of the picture with Base view video and the packet that stores the data of the corresponding Dependent view video picture have the same time information that ensures PCR (Program Clock Reference) synchronization at the time of encoding. Is set. Even when the Base view video stream and the Dependent view video stream are included in different TSs, the same time information is set in the packet storing the data of the corresponding picture.
  • PCR Program Clock Reference
  • the picture of Base view video and the picture of Dependent view video that are located at the same time become the corresponding pictures.
  • the same DTS is set for a PES packet that stores picture data of a Base ⁇ ⁇ view video and a PES packet that stores picture data of a Dependent view video corresponding to the picture in decoding order.
  • the picture of Base view video and the picture of Dependent view video located at the same time are also corresponding pictures.
  • the same PTS is set in a PES packet that stores data of a certain Base view video picture and a PES packet that stores data of a Dependent view video picture corresponding to the picture in display order.
  • the picture corresponding to the decoding order is a picture corresponding to the display order.
  • DTS 1 of a packet read from VSB 1 of the B video buffer 106 at a certain timing and DTS of a packet read from VSB 2 of the D video buffer 108 at a timing immediately thereafter. 2 represents the same time as shown in FIG.
  • the switch 109 outputs the Base view video packet read from the VSB 1 of the B video buffer 106 or the Dependent view video packet read from the VSB 2 of the D video buffer 108 to the video decoder 110.
  • the video decoder 110 sequentially decodes the packets supplied from the switch 109, and stores the data of the Base view video picture or the data of the Dependent view video picture obtained by decoding in the DPB 151.
  • the Base view video stream and the Dependent view video stream may be multiplexed into one TS as described with reference to FIG. 5 or the like, and are included in different TSs as described with reference to FIG. May be.
  • the playback device 1 can be used when the Base view video stream and the Dependent view video stream are included in different TSs even if they are multiplexed in one TS. Even if there is, it becomes possible to cope.
  • a decoder for Base view video and a decoder for Dependent view video may be provided in parallel. In this case, packets at the same time are supplied to the Base view video decoder and the Dependent view video decoder at the same timing.
  • FIG. 24 is a diagram illustrating another configuration for processing a video stream.
  • a switch 111 in addition to the configuration of FIG. 22, a switch 111, an L video plane generator 161, and an R video plane generator 162 are shown.
  • a PID filter 105 is also shown in front of the switch 107. The overlapping description will be omitted as appropriate.
  • the L video plane generator 161 generates a L video plane, and is provided in place of the B video plane generator 112 in FIG.
  • the R video plane generator 162 generates a R video plane, and is provided in place of the D video plane generator 113 of FIG.
  • the switch 111 needs to identify and output the L view video data and the R view video data.
  • the switch 111 needs to identify whether the data obtained by decoding the packet of Base view video is the video data of L view or R view.
  • the switch 111 needs to identify whether the data obtained by decoding the Dependent view video packet is L ⁇ ⁇ ⁇ view or R view video data.
  • the view_type described with reference to FIGS. 12 and 14 is used for identifying L ⁇ view and R view.
  • the controller 51 outputs the view_type described in the PlayList file to the switch 111.
  • the view_type value of 0 indicates that the Base view video stream is an L view stream.
  • the switch 111 outputs the data obtained by decoding the Dependent video video packet identified by a PID other than 0 to the R video plane generating unit 162.
  • a view_type value of 1 indicates that the Base view video stream is an R view stream.
  • the switch 111 outputs the data obtained by decoding the Dependent video video packet identified by a PID other than 0 to the L video plane generating unit 161.
  • the L video plane generating unit 161 generates a L video plane based on the data supplied from the switch 111 and outputs the generated plane to the synthesizing unit 130.
  • the R video plane generator 162 generates the R video plane based on the data supplied from the switch 111 and outputs it to the combining unit 130.
  • the recording device can cause the playback device 1 to identify whether the Base view video stream and the Dependent view video stream are L view or R view, respectively. It becomes possible.
  • view_id is set in Access Unit that constitutes the stream of the encoding result. By view_id, it is possible to identify which view component unit each Access Unit is.
  • FIG. 25 is a diagram showing an example of Access Unit.
  • H.264 / AVC / MVC By encoding with H.264 / AVC / MVC, data of each picture of Base view video and Dependent view video is stored in such Access Unit.
  • an MVC header is added to each view component as shown in Access Unit # 2.
  • the MVC header includes view_id.
  • the MVC header is not added to the Base view video which is the view view component stored in Access Unit # 1.
  • the Base view video stream is data used for 2D playback. Therefore, in order to ensure compatibility therewith, no MVC header is added to Base view video during encoding. Alternatively, the MVC header once added is removed. The encoding by the recording device will be described later.
  • the playback device 1 is defined (set) so that the view_component with no MVC header added has its view_id of 0 and the view ⁇ component is recognized as Base view video.
  • a value other than 0 is set as view_id during encoding.
  • the playback device 1 can identify Base view video based on the view_id recognized as 0, and can identify Dependent view video based on a view_id other than 0 that is actually set. .
  • the data obtained by decoding the Base view video packet and the data obtained by decoding the Dependent view video packet are identified based on such view_id. May be.
  • FIG. 26 is a diagram showing still another configuration for processing a video stream.
  • a B video plane generating unit 112 is provided instead of the L video plane generating unit 161 of FIG. 24, and a D video plane generating unit 113 is provided instead of the R video plane generating unit 162.
  • a switch 171 is provided following the B video plane generation unit 112 and the D video plane generation unit 113.
  • the data output destination can be switched based on the view_type.
  • the data obtained by decoding the Base view video packet and the data obtained by decoding the Dependent view video packet are identified based on the PID or view_id as described above.
  • the D video plane generation unit 113 generates and outputs a Dependent video video plane based on the data supplied from the switch 111.
  • the view_type described in the PlayList file is supplied from the controller 51 to the switch 171.
  • the switch 171 When the value of the view_type is 0, the switch 171 outputs the Base view video plane supplied from the B video plane generation unit 112 to the combining unit 130 as the L view video plane.
  • a view_type value of 0 indicates that the Base view video stream is an L view stream.
  • the switch 171 when the value of the view_type is 1, the switch 171 outputs the Dependent view video plane supplied from the D ⁇ ⁇ ⁇ ⁇ video plane generating unit 113 to the combining unit 130 as the L view video plane.
  • a view_type value of 1 indicates that the Base view video stream is an R view stream.
  • the switch 171 outputs the Base view ⁇ ⁇ ⁇ ⁇ video plane supplied from the B video plane generating unit 112 to the synthesizing unit 130 as the R view video plane.
  • the playback device 1 can identify L view and R view and switch the output destination according to the identification result.
  • FIG. 27 is a diagram illustrating the configuration of the combining unit 130 and the preceding stage of the configuration illustrated in FIG.
  • the switch 181 receives a packet constituting the IG stream included in the Main TS or Sub TS.
  • the packets constituting the IG stream input to the switch 181 include Base ⁇ ⁇ view packets and Dependent view packets.
  • the switch 182 receives a packet constituting the PG stream included in the Main TS or Sub TS.
  • the packets constituting the PG stream input to the switch 182 include Base view packets and Dependent view packets.
  • a Base view stream and a Dependent view stream for 3D display are prepared.
  • Base view IG is displayed in combination with Base view video
  • Dependent view IG is displayed in combination with Dependent view video, allowing the user to view not only video but also buttons and icons in 3D. become.
  • Base PG view PG is combined with the Base view video and displayed
  • Dependent view PG is combined with the Dependent view video, so that the user can display not only the video but also the subtitle text in 3D. Will see.
  • the switch 181 outputs a packet constituting the Base IG stream to the B IG decoder 116 and outputs a packet constituting the Dependent IG stream to the D IG decoder 120.
  • the switch 181 has the functions of the switch 114 and the switch 118 in FIG. In FIG. 27, the illustration of each buffer is omitted.
  • the B IG decoder 116 decodes the packets constituting the Base IG stream supplied from the switch 181 and outputs the data obtained by decoding to the B IG plane generation unit 117.
  • the B IG plane generation unit 117 generates a Base IG plane based on the data supplied from the B IG decoder 116, and outputs the generated plane to the synthesis unit 130.
  • the D IG decoder 120 decodes the packets constituting the Dependent IG stream supplied from the switch 181, and outputs the decoded data to the D IG plane generation unit 121.
  • the Base IG stream and Dependent IG stream may be decoded by one decoder.
  • the D IG plane generation unit 121 generates a Dependent IG plane based on the data supplied from the D IG decoder 120 and outputs the generated plane to the synthesis unit 130.
  • the switch 182 outputs a packet constituting the Base PG stream to the B PG decoder 124 and outputs a packet constituting the Dependent PG stream to the D PG decoder 128.
  • the switch 182 has the functions of the switch 122 and the switch 126 in FIG.
  • the B PG decoder 124 decodes the packet constituting the Base PG stream supplied from the switch 182 and outputs the decoded data to the B PG plane generation unit 125.
  • the B PG plane generating unit 125 generates a Base PG plane based on the data supplied from the B PG decoder 124 and outputs the generated data to the synthesizing unit 130.
  • the D PG decoder 128 decodes the packets constituting the Dependent PG stream supplied from the switch 182 and outputs the decoded data to the D PG plane generation unit 129.
  • the Base PG stream and the Dependent PG stream may be decoded by one decoder.
  • the D PG plane generation unit 129 generates a Dependent PG plane based on the data supplied from the D PG decoder 128, and outputs the generated plane to the synthesis unit 130.
  • the video decoder 110 sequentially decodes the packets supplied from the switch 109 (FIG. 22 etc.), and outputs the Base view video data or the Dependent view video data obtained by decoding to the switch 111.
  • the switch 111 outputs the data obtained by decoding the Base view video packet to the B video plane generation unit 112, and outputs the data obtained by decoding the Dependent view video packet to the D video plane generation unit 113. To do.
  • the B video plane generation unit 112 generates a base video video plane based on the data supplied from the switch 111 and outputs the generated plane.
  • the D video plane generation unit 113 generates and outputs a Dependent video video plane based on the data supplied from the switch 111.
  • the combining unit 130 includes adders 191 to 194 and a switch 195.
  • the addition unit 191 combines the Dependent PG plane supplied from the D PG plane generation unit 129 so as to overlap the Dependent view video plane supplied from the D video plane generation unit 113, and adds the combination results To the unit 193.
  • the Dependent PG plane supplied from the D PG plane generator 129 to the adder 191 is subjected to color information conversion processing (CLUT (Color Look Up Table) processing).
  • the addition unit 193 combines the Dependent IG plane supplied from the D IG plane generation unit 121 so as to be superimposed on the synthesis result by the addition unit 191, and outputs the synthesis result as a Dependent view plane.
  • the Dependent IG plane supplied from the D IG plane generation unit 121 to the addition unit 193 is subjected to color information conversion processing.
  • the addition unit 194 combines the Base IG plane supplied from the B IG plane generation unit 117 so as to be superimposed on the synthesis result by the addition unit 192, and outputs the synthesis result as a Base view plane.
  • the Base IG plane supplied from the D IG plane generation unit 121 to the addition unit 194 is subjected to color information conversion processing and correction processing using an offset value.
  • buttons and icons can be seen in the foreground, subtitle text can be seen below (in the depth direction), and video can be seen below The image becomes visible.
  • the switch 195 When the value of the view_type is 0, the switch 195 outputs the Base view plane as the L view plane and outputs the Dependent view plane as the R view plane.
  • the switch 195 is supplied with view_type from the controller 51.
  • the switch 195 when the value of the view_type is 1, the switch 195 outputs the Base view plane as the R ⁇ view plane and outputs the Dependent view plane as the L view plane. Which of the supplied planes is the Base view plane or the Dependent view plane is identified based on the PID and the view_id.
  • the Base view planes, the Dependent view planes, and the video, IG, and PG planes are combined.
  • FIG. 28 is a diagram illustrating the configuration of the combining unit 130 and the preceding stage.
  • the same reference numerals are given to the same components as those shown in FIG.
  • the configuration of the combining unit 130 is different from the configuration of FIG.
  • the operation of the switch 111 is different from the operation of the switch 111 of FIG.
  • An L video plane generation unit 161 is provided instead of the B video plane generation unit 112, and an R video plane generation unit 162 is provided instead of the D video plane generation unit 113.
  • a duplicate description is omitted.
  • the same view_type value is supplied from the controller 51 to the switch 111 and the switch 201 and switch 202 of the synthesis unit 130.
  • the switch 111 switches the output destination of the data obtained by decoding the Base view video packet and the output destination of the data obtained by decoding the Dependent view video packet based on the view_type. .
  • the switch 111 when the value of view_type is 0, the switch 111 outputs the data obtained by decoding the packet of Base view video to the L video plane generating unit 161. In this case, the switch 111 outputs the data obtained by decoding the Dependent view video packet to the R video plane generating unit 162.
  • the switch 111 when the value of the view_type is 1, the switch 111 outputs the data obtained by decoding the packet of Base view video to the R video plane generating unit 162. In this case, the switch 111 outputs the data obtained by decoding the Dependent view video packet to the L video plane generating unit 161.
  • the L video plane generating unit 161 generates a L video plane based on the data supplied from the switch 111 and outputs the generated plane to the synthesizing unit 130.
  • the R video plane generator 162 generates the R video plane based on the data supplied from the switch 111 and outputs it to the combining unit 130.
  • the switch 201 switches the output destinations of the Base IG plane supplied from the B IG plane generation unit 117 and the Dependent IG plane supplied from the D IG plane generation unit 121 based on the view_type.
  • the switch 201 when the value of view_type is 0, the switch 201 outputs the Base IG plane supplied from the B IG plane generation unit 117 to the addition unit 206 as an L view plane. In this case, the switch 201 outputs the Dependent IG plane supplied from the D IG plane generation unit 121 to the addition unit 205 as an R view plane.
  • the switch 201 when the value of the view_type is 1, the switch 201 outputs the Dependent IG plane supplied from the D IG plane generation unit 121 to the addition unit 206 as an L view plane. In this case, the switch 201 outputs the Base IG plane supplied from the B IG plane generation unit 117 to the addition unit 205 as an R view plane.
  • the switch 202 switches the output destinations of the Base PG plane supplied from the B PG plane generation unit 125 and the Dependent PG plane supplied from the D PG plane generation unit 129 based on the view_type.
  • the switch 202 when the value of view_type is 1, the switch 202 outputs the Dependent PG plane supplied from the D PG plane generating unit 129 to the adding unit 204 as an L view plane. In this case, the switch 202 outputs the Base PG plane supplied from the B PG plane generation unit 125 to the adding unit 203 as an R view plane.
  • the addition unit 203 combines the R view PG plane supplied from the switch 202 so as to overlap the R view video plane supplied from the R video plane generation unit 162, and adds the combination result to the addition unit 205. Output to.
  • the adding unit 204 combines the L view PG plane supplied from the switch 202 so as to overlap the L view video plane supplied from the L video plane generating unit 161, and adds the combination result to the adding unit 206. Output to.
  • the addition unit 205 combines the R view IG plane supplied from the switch 201 so as to be superimposed on the synthesis result plane by the addition unit 203, and outputs the synthesis result as the R view plane.
  • the addition unit 206 combines the L view IG plane supplied from the switch 201 so as to be superimposed on the synthesis result plane by the addition unit 204, and outputs the synthesis result as an L view plane.
  • the video, IG, and PG planes are combined so that the L view planes and the R view planes are combined.
  • FIG. 29 is a block diagram illustrating a configuration example of the software production processing unit 301.
  • the video encoder 311 has the same configuration as the MVC encoder 11 of FIG.
  • the video encoder 311 generates a Base ⁇ view ⁇ video stream and a Dependent view video stream by encoding a plurality of video data with H.264 AVC / MVC, and outputs them to the buffer 312.
  • the video encoder 311 sets DTS and PTS based on the same PCR during encoding. That is, the video encoder 311 sets the same DTS in a PES packet that stores data of a certain Base view video picture and a PES packet that stores data of a Dependent view video picture corresponding to the picture in decoding order.
  • the video encoder 311 sets the same PTS in a PES packet that stores picture data of a certain Base view video and a PES packet that stores data of a Dependent view video picture corresponding to the picture in display order.
  • the video encoder 311 sets the same information as additional information, which is auxiliary information related to decoding, in the Base view video picture and the Base view video picture corresponding in decoding order.
  • the video encoder 311 sets the same value as the POC value indicating the output order of the pictures in the Base view video picture and the Base view video picture corresponding to the display order.
  • the video encoder 311 performs encoding so that the GOP structure of the Base view video stream matches the GOP structure of the Dependent view video stream.
  • the audio encoder 313 encodes the input audio stream and outputs the obtained data to the buffer 314.
  • An audio stream to be recorded on the disc is input to the audio encoder 313 together with the Base view video and Dependent view video streams.
  • the data encoder 315 encodes the above-described various data other than video and audio, such as a PlayList file, and outputs the data obtained by the encoding to the buffer 316.
  • the data encoder 315 sets a view_type indicating whether the Base_view video stream is an L view stream or an R view stream in the PlayList file according to the encoding by the video encoder 311. Instead of the type of the Base view video stream, information indicating whether the Dependent view video stream is an L view stream or an R view stream may be set.
  • the data encoder 315 sets EP_map described later in the Clip Information file of the Base view video stream and the Clip Information file of the Dependent view video stream, respectively.
  • the picture of the Base view video stream set in the EP_map as the decoding start position and the picture of the Dependent view video stream become corresponding pictures.
  • the multiplexing unit 317 multiplexes video data, audio data, and data other than the stream stored in each buffer together with a synchronization signal, and outputs the multiplexed data to the error correction encoding unit 318.
  • the error correction encoding unit 318 adds an error correction code to the data multiplexed by the multiplexing unit 317.
  • the modulation unit 319 modulates the data supplied from the error correction coding unit 318 and outputs the modulated data.
  • the output of the modulation unit 319 is software recorded on the optical disc 2 that can be played back by the playback device 1.
  • a software production processing unit 301 having such a configuration is provided in the recording apparatus.
  • FIG. 30 is a diagram illustrating an example of a configuration including the software production processing unit 301.
  • the recording signal generated by the software production processing unit 301 is subjected to a mastering process in the premastering processing unit 331, 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 333.
  • a master made of glass or the like is prepared, and a recording material made of photoresist or the like is applied thereon. As a result, a recording master is produced.
  • the laser beam is modulated in accordance with the recording signal supplied from the premastering processing unit 331, 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 master is subjected to a process such as electroforming, and a metal master in which pits on the glass master are transferred is produced.
  • a metal stamper is further produced from this metal master, and this is used as a molding die.
  • a material such as PMMA (acrylic) or PC (polycarbonate) is injected into the molding die by injection or the like and fixed.
  • PMMA acrylic
  • PC polycarbonate
  • 2P ultraviolet curable resin
  • the pits on the metal stamper can be transferred onto the replica made of resin.
  • a reflective film is formed on the replica by vapor deposition or sputtering.
  • a reflective film is formed on the replica by spin coating.
  • the inner and outer diameters of the disk are processed, and necessary measures such as bonding two disks are performed. Further, after a label is attached or a hub is attached, it is inserted into the cartridge. In this way, the optical disc 2 on which data reproducible by the reproducing apparatus 1 is recorded is completed.
  • the Base video stream is an L video stream
  • the Dependent video video stream is an R video stream.
  • Base view video as an H.264 AVC / High Profile video stream, it becomes possible to play back the optical disc 2, which is a 3D-compatible disc, even in past players and players that support only 2D playback. . That is, it becomes possible to ensure backward compatibility.
  • the Base video stream can be decoded (reproduced) even by a decoder that does not support H.264 AVC / MVC. That is, the Base view video stream is a stream that can always be played back by an existing 2D BD player.
  • 3D-compatible discs can be produced by preparing a Dependent view video stream in addition to the conventional work for the AV stream.
  • FIG. 31 is a diagram illustrating a configuration example of a 3D video TS generation unit provided in the recording apparatus.
  • the 3D video TS generation unit in FIG. 31 includes an MVC encoder 401, an MVC header removal unit 402, and a multiplexer 403. Data of L view video # 1 and data of R view video # 2 captured as described with reference to FIG. 2 are input to the MVC encoder 401.
  • the MVC encoder 401 encodes L view video # 1 data with H.264 / AVC, and outputs the AVC video data obtained by encoding as a Base view video stream. . Also, the MVC encoder 401 generates and outputs a Dependent view video stream based on the data of the L view video # 1 and the data of the R view video # 2.
  • Each Access Unit that constitutes the Base view video stream and each Access Unit that constitutes the Dependent view video stream include an MVC header that describes a view_id for identifying the stored view component.
  • the MVC encoder 401 is an encoder that generates and outputs each stream of Base view video and Dependent view video with an MVC header added.
  • the MVC header is added only to the DependentDependview video encoded by H.264 AVC / MVC.
  • the Base view video stream output from the MVC encoder 401 is supplied to the MVC header removing unit 402, and the Dependent view video stream is supplied to the multiplexer 403.
  • the MVC header removal unit 402 removes the MVC header included in each Access unit that constitutes the Base view video stream.
  • the MVC header removal unit 402 outputs a Base view video stream composed of Access Unit from which the MVC header has been removed to the multiplexer 403.
  • the multiplexer 403 generates and outputs a TS including the Base view video stream supplied from the MVC header removing unit 402 and the Dependent view video stream supplied from the MVC encoder 401.
  • the TS including the Base view video stream and the TS including the Dependent view video stream are output, respectively, but may be multiplexed and output in the same TS as described above.
  • FIG. 31 The entire configuration shown in FIG. 31 can also be included in the MVC encoder as shown in FIG. The same applies to the configurations shown in FIGS. 32 and 33.
  • FIG. 32 is a diagram illustrating another configuration example of the 3D video TS generation unit provided in the recording apparatus.
  • the 32 is composed of a mixing processing unit 411, an MVC encoder 412, a separation unit 413, an MVC header removal unit 414, and a multiplexer 415. Data of L view video # 1 and data of R view video # 2 are input to the mixing processing unit 411.
  • the mixing processing unit 411 arranges each L view picture and each R view picture in the order of encoding. Since each picture of Dependent view video is encoded with reference to the corresponding Base view video picture, the result of arranging in the encoding order is that the L view picture and the R view picture are alternately arranged.
  • the mixing processing unit 411 outputs the L view picture and the R view picture arranged in the encoding order to the MVC encoder 412.
  • the MVC encoder 412 encodes each picture supplied from the mixing processing unit 411 with H.264 AVC / MVC, and outputs the stream obtained by encoding to the separation unit 413.
  • the Base view video stream and the Dependent view video stream are multiplexed.
  • the Base video stream included in the stream output from the MVC encoder 412 is made up of Access Unit storing data of each picture of Base view video. Further, the Dependent view video stream included in the stream output from the MVC encoder 412 includes an Access Unit that stores data of each picture of Dependent view video.
  • Each Access Unit that constitutes the Base view video stream and each Access Unit that constitutes the Dependent view video stream include an MVC header that describes a view_id for identifying the stored view component.
  • the separation unit 413 separates the Base view video stream and the Dependent view video stream multiplexed in the stream supplied from the MVC encoder 412 and outputs them.
  • the Base view video stream output from the separation unit 413 is supplied to the MVC header removal unit 414, and the Dependent view video stream is supplied to the multiplexer 415.
  • the MVC header removing unit 414 removes the MVC header included in each Access Unit constituting the Base view video stream supplied from the separating unit 413.
  • the MVC header removing unit 414 outputs a Base view video stream composed of Access Unit from which the MVC header has been removed to the multiplexer 415.
  • the multiplexer 415 generates and outputs a TS including the Baseview video stream supplied from the MVC header removal unit 414 and the Dependent view video stream supplied from the separation unit 413.
  • FIG. 33 is a diagram illustrating still another configuration example of the 3D video TS generation unit provided in the recording apparatus.
  • the 3D video TS generation unit in FIG. 33 includes an AVC encoder 421, an MVC encoder 422, and a multiplexer 423.
  • the data of L view video # 1 is input to the AVC encoder 421, and the data of R view video # 2 is input to the MVC encoder 422.
  • the AVC encoder 421 encodes the L view video # 1 data with H.264 / AVC, and outputs the AVC video stream obtained by encoding to the MVC encoder 422 and the multiplexer 423 as a Base view video stream.
  • Each Access Unit that configures the Base view video stream output from the AVC encoder 421 does not include an MVC header.
  • the MVC encoder 422 decodes the Base view video stream (AVC video stream) supplied from the AVC encoder 421, and generates L view video # 1 data.
  • the MVC encoder 422 generates a Dependent view video stream based on the data of the L ⁇ view video # 1 obtained by decoding and the data of the R view video # 2 input from the outside, and sends it to the multiplexer 423. Output.
  • Each Access Unit that constitutes the Dependent view video stream output from the MVC encoder 422 includes an MVC header.
  • the multiplexer 423 generates and outputs a TS including the Base view video stream supplied from the AVC encoder 421 and the Dependent view video stream supplied from the MVC encoder 422.
  • the multiplexer 423 has the function of the multiplexer 25 in FIG.
  • FIG. 34 is a diagram showing a configuration on the playback device 1 side that decodes Access Unit.
  • FIG. 34 shows the switch 109 and the video decoder 110 described with reference to FIG. Access Unit # 1 including the data of Base view video and Access Unit # 2 including the data of Dependent view video are read from the buffer and supplied to the switch 109.
  • the decoder side uses the view_id included in the MVC header to calculate the decoding order of each Access IV unit.
  • Base view video defines that the minimum value is always set as the value of view_id at the time of encoding.
  • the decoder can decode Base view video and Dependent view video in the correct order by starting decoding from the Access Unit including the MVC header in which the minimum view_id is set.
  • the playback device 1 is defined to recognize that the view component stored in the Access unit without the MVC header is 0.
  • the playback device 1 can identify Base view video based on the view_id recognized as 0, and can identify Dependent view video based on a view_id other than 0 that is actually set. .
  • the switch 109 in FIG. 34 outputs Access1Unit # 1 recognized that 0, which is the minimum value, is set as the view_id to the video decoder 110 for decoding.
  • the switch 109 outputs Access Unit # 2 in which Y, which is a fixed value larger than 0, is set as the view_id to the video decoder 110 to perform decoding.
  • the picture of Dependent view video stored in Access Unit # 2 is a picture corresponding to the picture of Base view video stored in Access Unit # 1.
  • the Base view video stream recorded on the optical disc 2 can be made a stream that can also be played back by a conventional player. it can.
  • BD-ROM ⁇ ⁇ 3D standard Base view video stream conditions that are extended from the BD-ROM standard, even if the conditions for making a stream that can be played back by conventional players are also determined Can be.
  • the Base view video Will not be reproducible.
  • the MVC header is undefined data. When such undefined data is input, it cannot be ignored by a decoder, and there is a possibility that the processing fails.
  • view_id of Base view video is X
  • view_id of Dependent view video is Y greater than X.
  • the playback device 1 first decodes Base view video, and then The corresponding DependentDependview video can be decoded. That is, decoding can be performed in the correct order.
  • GOP structure The H.264 / AVC standard does not define a GOP (Group Of Pictures) structure in the MPEG-2 video standard.
  • the GOP structure of the H.264 / AVC video stream is defined, and various functions using the GOP structure such as random access are realized.
  • the definition of the GOP structure does not exist in the Base video stream and Dependent view video stream, which are video streams obtained by encoding with H.264 AVC / MVC.
  • Base Base video stream is an H.264 / AVC video stream. Therefore, the GOP structure of the Base view video stream is the same as the GOP structure of the H.264 / AVC video stream defined in the BD-ROM standard.
  • the GOP structure of the Dependent video stream is also defined as the GOP structure of the Base video stream, that is, the same structure as the GOP structure of the H.264 / AVC video stream defined in the BD-ROM standard.
  • the GOP structure of the H.264 / AVC video stream defined in the BD-ROM standard has the following characteristics.
  • FIG. 36 is a diagram showing a closed GOP structure.
  • Each picture in FIG. 36 is a picture constituting an H.264 / AVC video stream.
  • the Closed GOP includes an IDR (Instantaneous Decoding / Refresh) picture.
  • the IDR picture is an I picture and is first decoded in the GOP including the IDR picture.
  • all the information related to decoding such as the state of the reference picture buffer (DPB 151 in FIG. 22), the frame number and POC (Picture Order Count) managed so far, is reset.
  • the previous (past) picture in display order from the IDR picture is prohibited from referring to the previous GOP picture.
  • the pictures that are later in the display order (future) than the IDR pictures are prohibited from referring to the immediately preceding GOP picture beyond the IDR picture.
  • it is allowed to refer to a picture preceding the I picture from a P picture behind the I picture in the display order.
  • FIG. 37 is a diagram showing an Open GOP structure.
  • a picture preceding the non-IDR ⁇ ⁇ ⁇ ⁇ I picture (an I picture that is not an IDR picture) in the current GOP is the previous GOP. It is allowed to refer to the picture.
  • a picture subsequent to the non-IDR I picture in the display order is prohibited from referring to the immediately preceding GOP picture beyond the non-IDR I picture.
  • Up to 1 PPS can be encoded in Access Unit other than the head of GOP.
  • the display order is also required to be B1 before.
  • a non-reference B picture is a B picture that is not referenced by other pictures that follow in the coding order.
  • the non-reference B picture can refer to the reference picture immediately before or after (I ⁇ ⁇ ⁇ ⁇ or P picture) or the reference B picture in the display order.
  • the maximum number of frames / fields in the GOP is defined according to the video frame rate as shown in FIG.
  • the maximum number of fields that can be displayed with a 1 GOP picture is 60.
  • the maximum number of frames that can be displayed with a 1 GOP picture is 60.
  • the GOP structure having the above characteristics is also defined as the GOP structure of the Dependent view video stream.
  • FIG. 39 shows the Closed GOP structure of the Base view video stream or Dependent view video stream defined as described above.
  • the previous (in the past) picture in display order from the IDR picture or the anchor picture refers to the picture of the immediately preceding GOP. It is prohibited.
  • the anchor picture will be described later.
  • an IDR picture or a picture later in the display order than the anchor picture (future) is prohibited from referring to the immediately preceding GOP picture beyond the IDR picture or anchor picture.
  • FIG. 40 is a diagram illustrating an Open GOP structure of a Base view video stream or a Dependent view video stream.
  • a picture preceding the non-IDR anchor picture (an anchor picture that is not an IDR picture) in the current GOP is the previous GOP. It is allowed to refer to the picture.
  • GOP structure for example, whether a GOP with a Base view video stream and a GOP of a corresponding Dependent view video stream is an Open GOP or a Closed GOP. The characteristics of the stream structure will match.
  • the feature of the reference structure of the picture is matched so that the picture of Dependent view video corresponding to the non-reference B picture of Base view video is always a non-reference B picture.
  • the number of frames and the number of fields also match between the GOP with the Base video stream and the GOP of the corresponding Dependent video stream.
  • the GOP structure of the Dependent view video stream as the same structure as the GOP structure of the Base view video stream, it is possible to give the same characteristics to the corresponding GOPs between the streams.
  • decoding from the middle of the stream can be performed without any problem.
  • Decoding from the middle of the stream is performed, for example, during trick play or random access.
  • the Base view ⁇ ⁇ ⁇ video picture necessary for decoding the Dependent view video may not be decoded.
  • the picture of Dependent view video cannot be decoded and 3D display cannot be performed.
  • the Base view video image may not be output, but those disadvantages can also be avoided.
  • EP_map By using the GOP structure of the Base view video stream and the Dependent view video stream, it becomes possible to set the decoding start position at the time of random access or trick play to EP_map.
  • EP_map is included in the Clip Information file.
  • the position that can be set in the Dependent view video stream is the position of an anchor picture arranged subsequent to SubsetSPS or the position of an IDR picture arranged subsequent to SubsetSPS.
  • An anchor picture is a picture defined by H.264 AVC / MVC, and is a picture of a Dependent view video stream that is encoded by making reference between views without reference in the time direction.
  • FIG. 41 is a diagram showing an example of the decoding start position set in the EP_map that satisfies the above two constraints.
  • FIG. 41 the pictures constituting the Base view video stream and the pictures constituting the Dependent view video stream are shown in decoding order.
  • the picture P 1 is set as the decoding start position in the EP_map of the Dependent view video stream, as indicated by the white arrow # 11.
  • a picture P 11 that is a picture of the Base view video stream corresponding to the picture P 1 is an IDR picture. As shown by a white arrow # 12, the picture P 11 is an IDR picture is also set as a decoding start position EP_map of the Base view video stream.
  • the picture P 11 Since random access and trick play are instructed, when decoding is started from the picture P 1 and the picture P 11 , the picture P 11 is first decoded. Since an IDR picture, without reference to other pictures, it is possible to decode the picture P 11.
  • the picture P 1 is decoded.
  • the decoded picture P 11 is referred to for decoding the picture P 1 . Since the picture is an anchor picture or IDR picture, the picture P 1 can be decoded if the picture P 11 has been decoded.
  • decoding is performed in a manner such as a picture next to the picture P 1 of the Base view video, a picture next to the picture P 11 of the Dependent view video, and so on.
  • both the Base view ⁇ ⁇ ⁇ ⁇ video and Dependent view video can be decoded without problems from the picture set in the EP_map. it can. Thereby, random access can be realized.
  • FIG. 42 is a diagram showing a problem that occurs when the GOP structure of Dependent view video is not defined.
  • a picture P 21 is an IDR picture of the Base view video indicated with a color is set to EP_map as a decoding start position.
  • the Base view video picture P 21 starts decoding
  • picture P 31 is a picture of the Dependent view video corresponding to the picture P 21 is not an anchor picture.
  • the GOP structure is not defined, there is no guarantee that the picture of the Dependent view video corresponding to the IDR picture of the Base view video is an IDR picture or an anchor picture.
  • playback device 1 can easily specify the decoding start position.
  • the playback apparatus 1 When only the picture with Base view video is set in EP_map as the decoding start position, the playback apparatus 1 needs to specify the picture of Dependent view video corresponding to the picture at the decoding start position by calculation, It becomes complicated.
  • FIG. 43 is a diagram illustrating the concept of picture search required when performing random access or trick play for an MVC stream including a Base view video stream and a Dependent view video stream.
  • a non-IDR anchor picture or an IDR picture is searched, and a decoding start position is determined.
  • EP_map will be described. Although the case where the decoding start position of Base view video is set in EP_map will be described, the decoding start position of Dependent view video is similarly set in EP_map of Dependent view video.
  • FIG. 44 is a diagram showing the structure of an AV stream recorded on the optical disc 2.
  • the TS including the Baseview video stream is composed of an integer number of aligned units (Aligned Unit) having a size of 6144 bytes.
  • the Allied unit consists of 32 source packets.
  • the source packet has 192 bytes.
  • One source packet is composed of a 4-byte transport packet extra header (TP_extra header) and a 188-byte transport packet (Transport Packet).
  • the data of Base view video is packetized into MPEG2 PES packets.
  • a PES packet header is added to the data portion of the PES packet to form a PES packet.
  • the PES packet header includes a stream ID that identifies the type of elementary stream transmitted by the PES packet.
  • PES packets are further packetized into transport packets. That is, the PES packet is divided into the payload size of the transport packet, and a transport packet header is added to the payload to form a transport packet.
  • the transport packet header includes a PID that is identification information of data stored in the payload.
  • the source packet is given a source packet number that is incremented by 1 for each source packet, with the beginning of the Clip AV stream being 0, for example.
  • the Allied unit starts from the first byte of the source packet.
  • EP_map is used to search for a data address to start reading data in the Clip AV stream file when the time stamp of the Clip access point is given.
  • EP_map is a list of entry points extracted from the elementary stream and the transport stream.
  • EP_map has address information for searching for an entry point to start decoding in the AV stream.
  • One EP data in the EP_map is composed of a pair of a PTS and an address in an AV stream of an Access unit corresponding to the PTS.
  • data for one picture is stored in one Access Unit.
  • FIG. 45 shows an example of a Clip AV stream.
  • the video stream is distinguished for each source packet by the PID included in the header of the transport packet in the source packet.
  • the source packets including the first byte of the IDR picture are colored.
  • a square without a color indicates a source packet including data that does not become a random access point or a source packet including data of another stream.
  • FIG. 46 is a diagram conceptually showing an example of EP_map corresponding to the Clip AV stream of FIG.
  • EP_map is composed of stream_PID, PTS_EP_start, and SPN_EP_start.
  • P PTS_EP_start represents the Access Unit PTS starting from a randomly accessible IDR picture.
  • SPN_EP_start represents the address of the source packet including the first byte of Access Unit referenced by the value of PTS_EP_start.
  • the PID of the video stream is stored in stream_PID, and EP_map_for_one_stream_PID (), which is table information indicating the correspondence between PTS_EP_start and SPN_EP_start, is generated.
  • Such a table is also generated for each video stream multiplexed in the same Clip AV stream.
  • the EP_map including the generated table is stored in the Clip Information file corresponding to the Clip AV stream.
  • FIG. 47 is a diagram showing an example of the data structure of the source packet pointed to by SPN_EP_start.
  • the source packet is configured by adding a 4-byte header to a 188-byte transport packet.
  • the transport packet part includes a header part (TP header) and a payload part.
  • SPN_EP_start represents the source packet number of the source packet including the first byte of Access Unit starting from the IDR picture.
  • Access Unit that is, picture starts from AU delimiter (Access Unit Delimiter).
  • the AU delimiter is followed by SRS and PPS. Thereafter, the head portion or the whole of the slice data of the IDR picture is stored.
  • payload_unit_start_indicator in the TP header of the transport packet being 1 indicates that a new PES packet starts from the payload of this transport packet. Access Unit is started from this source packet.
  • Such EP_map is prepared for each of the Base view video stream and the Dependent view video stream.
  • POC Picture Order Count
  • POC is ⁇ A variable having a value that is non-decreasing with increasing picture position in output order relative to the previous IDR picture in decoding order or relative to the previous picture containing the memory management control It is defined as marks all reference pictures as “unused for reference”.
  • the POC set for the pictures in the Base video stream and the POC set for the pictures in the Dependent video stream are operated in a unified manner.
  • each picture of the Base view video stream and the Dependent view video stream has the same POC between the corresponding pictures in the display order. Is set.
  • the playback device 1 can process view components with the same POC set as corresponding view components in display order.
  • Picture Timing SEI (Supplemental Enhancement Information) is set for each picture constituting the Base view video stream and the Dependent view video stream.
  • SEI is additional information including auxiliary information related to decoding, which is defined by H.264 / AVC.
  • One of the SEIs Picture Timing SEI, includes time information such as a read time from the CPB (Coded Picture Buffer) at the time of encoding and a read time from the DPB at the time of decoding (DPB 151 in FIG. 22). . Also, information on display time, information on picture structure, and the like are included.
  • the Picture Timing SEI set for the pictures in the Base view video stream and the Picture Timing SEI set for the pictures in the Dependent view video stream are operated in a unified manner.
  • T1 is set as the reading time from the CPB in the first picture in the encoding order of the Base view video stream
  • the reading time from the CPB is also set in the first picture in the encoding order of the Dependent view video stream.
  • T1 is set as
  • the playback apparatus 1 can process the view component having the same Picture Timing SEI as the corresponding view component in the decoding order.
  • POC and Picture Timing SEI are included in the elementary streams of Base view video and Dependent view video, and are referenced by the video decoder 110 in the playback apparatus 1.
  • the video decoder 110 can identify the corresponding view component based on the information included in the elementary stream. In addition, the video decoder 110 can perform decoding processing in a correct decoding order based on Picture Timing SEI and so as to be in a correct display order based on POC.
  • the series of processes described above can be executed by hardware or software.
  • a program constituting the software is installed from a program recording medium into a computer incorporated in dedicated hardware or a general-purpose personal computer.
  • FIG. 48 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.
  • the CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 505 is further connected to the bus 504.
  • the input / output interface 505 is connected to an input unit 506 including a keyboard and a mouse, and an output unit 507 including a display and a speaker.
  • a storage unit 508 including a hard disk and a non-volatile memory, a communication unit 509 including a network interface, and a drive 510 that drives a removable medium 511 are connected to the bus 504.
  • the CPU 501 loads the program stored in the storage unit 508 to the RAM 503 via the input / output interface 505 and the bus 504 and executes the program, for example. Is done.
  • the program executed by the CPU 501 is recorded on the removable medium 511 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 508.
  • 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 disc, 3 display device, 11 MVC encoder, 21 H.264 / AVC encoder, 22 H.264 / AVC decoder, 23 Depth calculation unit, 24 Dependent video viewer, 25 multiplexer, 51 controller, 52 disc Drive, 53 memory, 54 local storage, 55 Internet interface, 56 decoder section, 57 operation input section

Landscapes

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

Abstract

　本発明は、BD等の記録媒体に記録される、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームの同期を確保することができるようにすることができる記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体に関する。 Base view videoのあるピクチャのデータを格納したパケットと、対応するDependent view videoのピクチャのデータを格納したパケットには、エンコード時に、PCR同期が確保された同じ時刻情報が設定されている。Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合であっても、対応するピクチャのデータを格納したパケットには同じ時刻情報が設定される。本発明は、BD-ROM規格に対応した再生装置に適用することができる。

Description

記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体
　本発明は、記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体に関し、特に、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームの同期を確保することができるようにした記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体に関する。
　映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
　立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
　立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
　立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
　一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
　そのような大容量の記録媒体としては、BD(Blu-Ray（登録商標）)-ROM(Read Only Memory)等のBlu-Ray（登録商標） Disc（以下、BDともいう）がある（特許文献１を参照）。
特開２００５－３４８３１４号公報
　ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
　例えば、ステレオ画像の画像データは、左画像のデータのストリームと右画像のデータのストリームの２本のデータストリームからなる。このため、この２本のデータストリームを、同期を確保して再生できるようにしてBDに記録しておく必要がある。
　本発明はこのような状況に鑑みてなされたものであり、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと基本ストリームの同期を確保することができるようにするものである。
　本発明の一側面の記録装置は、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行う符号化手段を備える。
　本発明の一側面の記録方法は、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行うステップを含む。
　本発明の一側面のプログラムは、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行うステップを含む処理をコンピュータに実行させる。
　本発明の一側面の記録媒体は、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームを構成する第１のピクチャと拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSが設定され、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSが設定された、前記基本ストリームと前記拡張ストリームが記録されたものである。
　本発明の他の側面の再生装置は、記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力する復号手段を備える。
　本発明の他の側面の再生方法は、記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力するステップを含む。
　本発明の他の側面のプログラムは、記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力するステップを含む処理をコンピュータに実行させる。
　本発明の一側面においては、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSが設定され、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSが設定されて、符号化が行われる。
　本発明の他の側面においては、記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームが取得され、前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号が行われ、表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータが出力される。
　本発明によれば、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームの同期を確保することができる。
本発明を適用した再生装置を含む再生システムの構成例を示す図である。 撮影の例を示す図である。 MVCエンコーダの構成例を示すブロック図である。 参照画像の例を示す図である。 TSの構成例を示す図である。 TSの他の構成例を示す図である。 TSのさらに他の構成例を示す図である。 AVストリームの管理の例を示す図である。 Main PathとSub Pathの構造を示す図である。 光ディスクに記録されるファイルの管理構造の例を示す図である。 PlayListファイルのシンタクスを示す図である。 図１１にあるreserved_for_future_useの使い方の例を示す図である。 3D_PL_typeの値の意味を示す図である。 view_typeの値の意味を示す図である。 図１１のPlayList()のシンタクスを示す図である。 図１５のSubPath()のシンタクスを示す図である。 図１６のSubPlayItem(i)のシンタクスを示す図である。 図１５のPlayItem()のシンタクスを示す図である。 図１８のSTN_table()のシンタクスを示す図である。 再生装置の構成例を示すブロック図である。 図２０のデコーダ部の構成例を示す図である。 ビデオストリームの処理を行う構成を示す図である。 ビデオストリームの処理を行う構成を示す図である。 ビデオストリームの処理を行う他の構成を示す図である。 Access Unitの例を示す図である。 ビデオストリームの処理を行うさらに他の構成を示す図である。 合成部と、その前段の構成を示す図である。 合成部と、その前段の構成を示す他の図である。 ソフト製作処理部の構成例を示すブロック図である。 ソフト製作処理部を含む各構成の例を示す図である。 記録装置に設けられる3D video TS生成部の構成例を示す図である。 記録装置に設けられる3D video TS生成部の他の構成例を示す図である。 記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。 Access Unitをデコードする再生装置側の構成を示す図である。 デコード処理を示す図である。 Close GOP構造を示す図である。 Open GOP構造を示す図である。 GOP内の最大フレーム・フィールド数を示す図である。 Close GOP構造を示す図である。 Open GOP構造を示す図である。 EP_mapに設定されたデコード開始位置の例を示す図である。 Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。 ピクチャサーチの概念を示す図である。 光ディスク上に記録されたAVストリームの構造を示す図である。 Clip AVストリームの例を示す図である。 図４５のClip AVストリームに対応したEP_mapを概念的に示す図である。 SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。 コンピュータのハードウェアの構成例を示すブロック図である。
　＜第１の実施の形態＞
［再生システムの構成例］
　図１は、本発明を適用した再生装置１を含む再生システムの構成例を示す図である。
　図１に示すように、この再生システムは、再生装置１と表示装置３がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置１には、BDなどの光ディスク２が装着される。
　光ディスク２には、視点の数が２つのステレオ画像（いわゆる3D画像）を表示するために必要なストリームが記録されている。
　再生装置１は、光ディスク２に記録されているストリームの3D再生に対応したプレーヤである。再生装置１は、光ディスク２に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置３に表示させる。音声についても同様に再生装置１により再生され、表示装置３に設けられるスピーカなどから出力される。
　3D画像の表示の方式として様々な方式が提案されている。ここでは、3D画像の表示の方式として、以下のタイプ１の表示方式と、タイプ２の表示方式とを採用する。
　タイプ１の表示方式は、3D画像のデータを左眼で観察される画像（L画像）のデータと、右眼で観察される画像（R画像）のデータとで構成し、L画像とR画像を交互に表示することで、3D画像を表示する方式である。
　タイプ２の表示方式は、3D画像を生成する元になる画像である元画像のデータとDepthのデータとを用いて生成されるL画像とR画像を表示することで、3D画像を表示する方式である。タイプ２の表示方式で用いられる3D画像のデータは、元画像のデータと、元画像に与えることによってL画像とR画像を生成することができるDepthのデータとで構成される。
　タイプ１の表示方式は、視聴するときにメガネが必要となる表示方式である。タイプ２の表示方式は、メガネなしで3D画像を視聴できる表示方式である。
　光ディスク２には、タイプ１と２のいずれの表示方式によっても3D画像を表示することができるようなストリームが記録されている。
　そのようなストリームを光ディスク２に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)が採用される。
［H.264 AVC/MVC Profile］
　H.264 AVC/MVCでは、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCを単にMVCという。
　図２は、撮影の例を示す図である。
　図２に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
　図３は、MVCエンコーダの構成例を示すブロック図である。
　図３に示すように、MVCエンコーダ１１は、H.264/AVCエンコーダ２１、H.264/AVCデコーダ２２、Depth算出部２３、Dependent view videoエンコーダ２４、およびマルチプレクサ２５から構成される。
　L画像用のカメラにより撮影された映像＃１のストリームはH.264/AVCエンコーダ２１とDepth算出部２３に入力される。また、R画像用のカメラにより撮影された映像＃２のストリームはDepth算出部２３とDependent view videoエンコーダ２４に入力される。映像＃２のストリームがH.264/AVCエンコーダ２１とDepth算出部２３に入力され、映像＃１のストリームがDepth算出部２３とDependent view videoエンコーダ２４に入力されるようにしてもよい。
　H.264/AVCエンコーダ２１は、映像＃１のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ２１は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ２２とマルチプレクサ２５に出力する。
　H.264/AVCデコーダ２２は、H.264/AVCエンコーダ２１から供給されたAVCビデオストリームをデコードし、デコードして得られた映像＃１のストリームをDependent view videoエンコーダ２４に出力する。
　Depth算出部２３は、映像＃１のストリームと映像＃２のストリームに基づいてDepthを算出し、算出したDepthのデータをマルチプレクサ２５に出力する。
　Dependent view videoエンコーダ２４は、H.264/AVCデコーダ２２から供給された映像＃１のストリームと、外部から入力された映像＃２のストリームをエンコードし、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ストリームと、Depth算出部２３から供給されたDependent view videoストリーム（Depthのデータ）と、Dependent view videoエンコーダ２４から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは１本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
　マルチプレクサ２５は、生成したTS（MPEG2 TS）を出力する。マルチプレクサ２５から出力されたTSは、他の管理データとともに記録装置において光ディスク２に記録され、光ディスク２に記録された形で再生装置１に提供される。
　タイプ１の表示方式においてBase view videoとともに用いられるDependent view videoと、タイプ２の表示方式においてBase view videoとともに用いられるDependent view video（Depth）とを区別する必要がある場合、前者をD1 view videoといい、後者をD2 view videoという。
　また、Base view videoとD1 view videoを用いて行われる、タイプ１の表示方式での3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる、タイプ２の表示方式での3D再生をB-D2再生という。
　再生装置１は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク２から読み出して再生する。
　また、再生装置１は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク２から読み出して再生する。
　さらに、再生装置１は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク２から読み出して再生する。
　Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
　以下、Dependent view videoがD1 view videoである場合について主に説明する。単にDependent view videoというときは、D1 view videoを表すことになる。D2 view videoについても、D1 view videoと同様にして光ディスク２に記録され、再生される。
［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ストリームとともにMain TSに含まれていることもある。
　光ディスク２には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームを含むTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。
　ビデオと同様に3Dでの表示が可能になるように、後述するPG、IGについてもBase viewとDependent viewのそれぞれのストリームが用意されている。
　それぞれのストリームをデコードして得られたPG、IGのBase viewのプレーンは、Base view videoストリームをデコードして得られたBase view videoのプレーンと合成されて表示される。同様に、PG、IGのDependent viewのプレーンは、Dependent view videoストリームをデコードして得られたDependent view videoのプレーンと合成されて表示される。
　例えば、Base view videoストリームがL画像のストリームであり、Dependent view videoストリームがR画像のストリームである場合、PG、IGについても、そのBase viewのストリームはL画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはR画像のグラフィックスのストリームとなる。
　一方、Base view videoストリームがR画像のストリームであり、Dependent view videoストリームがL画像のストリームである場合、PG、IGについても、そのBase viewのストリームはR画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはL画像のグラフィックスのストリームとなる。
　図６は、TSの他の構成例を示す図である。
　図６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
　一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
　このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
　図７は、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に含まれていることもある。
　図７のＢのMain TSにはBase view video、Primary audio、PG、IGのそれぞれのストリームが多重化されている。一方、Sub TSにはDependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
　Main TSに含まれるPG、IGは2D再生用のストリームである。Sub TSに含まれているストリームは3D再生用のストリームである。
　このように、PGのストリームとIGのストリームを2D再生と3D再生において共有しないようにすることも可能である。
　以上のように、Base view videoストリームとDependent view videoストリームが別々のMPEG2 TSに含まれることがある。Base view videoストリームとDependent view videoストリームを別々のMPEG2 TSに含めて記録する場合のメリットについて説明する。
　例えば１本のMPEG2 TSとして多重化できるビットレートが制限されている場合を考える。この場合において、Base view videoストリームとDependent view videoストリームの両方を１本のMPEG2 TSに含めたときには、その制約を満たすために各ストリームのビットレートを下げる必要がある。その結果、画質が落ちてしまうことになる。
　それぞれ異なるMPEG2 TSに含めることによって、ビットレートを下げる必要がなくなり、画質を落とさずに済むことになる。
［アプリケーションフォーマット］
　図８は、再生装置１によるAVストリームの管理の例を示す図である。
　AVストリームの管理は、図８に示すようにPlayListとClipの２つのレイヤを用いて行われる。AVストリームは、光ディスク２だけでなく、再生装置１のローカルストレージに記録されていることもある。
　ここでは、１つのAVストリームとそれに付随する情報であるClip Informationのペアを１つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。
　AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプで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を持つことができる。
　上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。
　図９のPlayListは、３つのPlayItemの並びにより作られる１つのMain Pathと、３つのSub Pathを有している。
　Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。
　図９の例においては、Subpath_id=0のSub Pathには１つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには２つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには１つのSubPlayItemが含まれる。
　１つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム（メイン画像データ）が含まれる。
　また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで（同期して）再生されるオーディオストリームが１つ以上含まれてもよいし、含まれなくてもよい。
　Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ（PG(Presentation Graphic)）のストリームが１つ以上含まれてもよいし、含まれなくてもよい。
　Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが１つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。
　１つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される０個以上のオーディオストリーム、０個以上のPGストリーム、および、０個以上のIGストリームが多重化されている。
　また、１つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム（別ストリーム）の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。
　このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開２００８－２５２７４０号公報、特開２００５－３４８３１４号公報に記載されている。
［ディレクトリ構造］
　図１０は、光ディスク２に記録されるファイルの管理構造の例を示す図である。
　図１０に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク２上には１つのrootディレクトリが作成される。rootディレクトリの下が、１つの記録再生システムで管理される範囲となる。
　rootディレクトリの下にはBDMVディレクトリが置かれる。
　BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
　BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
　PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、５桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。図１０に示す１つのPlayListファイルには「00000.mpls」のファイル名が設定されている。
　CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、５桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
　図１０の３つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
　例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。
　「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。
　「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。
　STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、５桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、５桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
　「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。
　「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。
　「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。
　「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。
　図１０に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
［各データのシンタクス］
　図１１は、PlayListファイルのシンタクスを示す図である。
　PlayListファイルは、図１０のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
　図１１のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。
　version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは４桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。
　PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。
　PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。
　ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。
　ExtensionData_start_addressの後には、１６０bitのreserved_for_future_useが含まれる。
　AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
　PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
　PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。
　ExtensionData()には、プライベートデータが挿入できるようになっている。
　図１２は、PlayListファイルの記述の具体例を示す図である。
　図１２に示すように、PlayListファイルには２bitの3D_PL_typeと１bitのview_typeが記述される。
　3D_PL_typeは、PlayListの種類を表す。
　view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。
　図１３は、3D_PL_typeの値の意味を示す図である。
　3D_PL_typeの値の00は、2D再生用のPlayListであることを表す。
　3D_PL_typeの値の01は、3D再生のうちのB-D1再生用のPlayListであることを表す。
　3D_PL_typeの値の10は、3D再生のうちのB-D2再生用のPlayListであることを表す。
　例えば、3D_PL_typeの値が01か10の場合には、PlayListファイルのExtenstionData()に3DPlayList情報が登録される。例えば、3DPlayList情報として、Base view videoストリームとDependent view videoストリームの光ディスク２からの読み出しに関する情報が登録される。
　図１４は、view_typeの値の意味を示す図である。
　view_typeの値の0は、3D再生を行う場合には、Base view videoストリームがL viewのストリームであることを表す。2D再生を行う場合には、Base view videoストリームがAVCビデオストリームであることを表す。
　view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
　view_typeがPlayListファイルに記述されることにより、再生装置１は、Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することが可能になる。
　例えば、HDMIケーブルを介して表示装置３にビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが再生装置１に要求されるものと考えられる。
　Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することができるようにすることにより、再生装置１は、L viewの信号とR viewの信号を区別して出力することが可能になる。
　図１５は、図１１のPlayList()のシンタクスを示す図である。
　lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
　lengthの後には、１６ビットのreserved_for_future_useが用意される。
　number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す１６ビットのフィールドである。図９の例の場合、PlayItemの数は３である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に０から割り振られる。例えば、図９のPlayItem_id＝０，１，２が割り振られる。
　number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す１６ビットのフィールドである。図９の例の場合、Sub Pathの数は３である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に０から割り振られる。例えば、図９のSubpath_id＝０，１，２が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。
　図１６は、図１５のSubPath()のシンタクスを示す図である。
　lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
　lengthの後には、１６ビットのreserved_for_future_useが用意される。
　SubPath_typeは、Sub Pathのアプリケーションの種類を示す８ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。
　SubPath_typeの後には、１５ビットのreserved_for_future_useが用意される。
　is_repeat_SubPathは、Sub Pathの再生方法を指定する１ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を１回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合（Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など）に利用される。
　Is_repeat_SubPathの後には、８ビットのreserved_for_future_useが用意される。
　number_of_SubPlayItemsは、１つのSub Pathの中にあるSubPlayItemの数（エントリー数）を示す８ビットのフィールドである。例えば、図９のSubPath_id＝０のSubPlayItemのnumber_of_SubPlayItemsは１であり、SubPath_id＝１のSubPlayItemのnumber_of_SubPlayItemsは２である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem（）が参照される。
　図１７は、図１６のSubPlayItem(i)のシンタクスを示す図である。
　lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
　図１７のSubPlayItem(i)は、SubPlayItemが１つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。
　SubPlayItemが１つのClipを参照する場合について説明する。
　Clip_Information_file_name[0]は参照するClipを表す。
　Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。
　is_multi_Clip_entriesはマルチClipの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。
　ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
　SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。
　sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。
　SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。
　「if（is_multi_Clip_entries＝＝１ｂ」であり、SubPlayItemが複数のClipを参照する場合について説明する。
　num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。
　Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。
　ref_to_STC_id[SubClip_entry_id]はSTC不連続点（システムタイムベースの不連続点）に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。
　図１８は、図１５のPlayItem()のシンタクスを示す図である。
　lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
　Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むmt2sファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ５桁の数字が含まれる。
　Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。
　ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
　IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。
　OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。
　STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。
　図１９は、図１８のSTN_table()のシンタクスを示す図である。
　STN_table()は、PlayItemの属性として設定されている。
　lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す１６ビットの符号なし整数である。lengthの後には、１６ビットのreserved_for_future_useが用意される。
　number_of_video_stream_entriesは、STN_table()の中でエントリーされる（登録される）、video_stream_idが与えられるストリームの数を表す。
　video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームがこのvideo_stream_idにより特定される。
　Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
　video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。
　number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる１番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。
　number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる２番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。
　number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。
　number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、IGストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
　Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
［再生装置１の構成例］
　図２０は、再生装置１の構成例を示すブロック図である。
　コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
　例えば、コントローラ５１は、ディスクドライブ５２を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ５１は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部５６に供給させる。
　ディスクドライブ５２は、コントローラ５１による制御に従って光ディスク２からデータを読み出し、読み出したデータを、コントローラ５１、メモリ５３、またはデコーダ部５６に出力する。
　メモリ５３は、コントローラ５１が各種の処理を実行する上において必要なデータなどを適宜記憶する。
　ローカルストレージ５４は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ５４には、サーバ７２からダウンロードされたDependent view videoストリームなどが記録される。ローカルストレージ５４に記録されているストリームもデコーダ部５６に適宜供給される。
　インターネットインタフェース５５は、コントローラ５１からの制御に従ってネットワーク７１を介してサーバ７２と通信を行い、サーバ７２からダウンロードしたデータをローカルストレージ５４に供給する。
　サーバ７２からは、光ディスク２に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたDependent view videoストリームを光ディスク２に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク２の内容とは異なる内容の3D再生を実現することが可能になる。Dependent view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。
　デコーダ部５６は、ディスクドライブ５２、またはローカルストレージ５４から供給されたストリームをデコードし、得られたビデオ信号を表示装置３に出力する。オーディオ信号も所定の経路を介して表示装置３に出力される。
　操作入力部５７は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部５７はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ５１に供給する。
　図２１は、デコーダ部５６の構成例を示す図である。
　図２１においてはビデオ信号の処理を行う構成が示されている。デコーダ部５６においては、オーディオ信号のデコード処理も行われる。オーディオ信号を対象として行われたデコード処理の結果は、図示せぬ経路を介して表示装置３に出力される。
　PIDフィルタ１０１は、ディスクドライブ５２、またはローカルストレージ５４から供給されたTSがMain TSであるかSub TSであるかを、TSを構成するパケットのPIDやストリームのIDなどに基づいて識別する。PIDフィルタ１０１は、Main TSをバッファ１０２に出力し、Sub TSをバッファ１０３に出力する。
　PIDフィルタ１０４は、バッファ１０２に記憶されたMain TSのパケットを順次読み出し、PIDに基づいて振り分ける。
　例えば、PIDフィルタ１０４は、Main TSに含まれているBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
　また、PIDフィルタ１０４は、Main TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
　PIDフィルタ１０４は、Main TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
　図５を参照して説明したように、Base view video、Dependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがMain TSに多重化されていることがある。
　PIDフィルタ１０５は、バッファ１０３に記憶されたSub TSのパケットを順次読み出し、PIDに基づいて振り分ける。
　例えば、PIDフィルタ１０５は、Sub TSに含まれているDependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
　また、PIDフィルタ１０５は、Sub TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
　PIDフィルタ１０５は、Sub TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
　図７を参照して説明したように、Dependent view videoストリームがSub TSに含まれていることがある。また、図６を参照して説明したように、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがSub TSに多重化されていることがある。
　スイッチ１０７は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent view videoストリームを構成するパケットをD videoバッファ１０８に出力する。
　スイッチ１０９は、B videoバッファ１０６に記憶されたBase view videoのパケットと、D videoバッファ１０８に記憶されたDependent view videoのパケットを、デコードのタイミングを規定する時刻情報に従って順次読み出す。Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには例えば同じ時刻情報が設定されている。
　スイッチ１０９は、B videoバッファ１０６、またはD videoバッファ１０８から読み出したパケットをビデオデコーダ１１０に出力する。
　ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはDependent view videoのデータをスイッチ１１１に出力する。
　スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
　B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　スイッチ１１４は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase IGストリームを構成するパケットをB IGバッファ１１５に出力する。
　B IGデコーダ１１６は、B IGバッファ１１５に記憶されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
　B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
　スイッチ１１８は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent IGストリームを構成するパケットをD IGバッファ１１９に出力する。
　D IGデコーダ１２０は、D IGバッファ１１９に記憶されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。
　D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
　スイッチ１２２は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase PGストリームを構成するパケットをB PGバッファ１２３に出力する。
　B PGデコーダ１２４は、B PGバッファ１２３に記憶されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
　B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
　スイッチ１２６は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent PGストリームを構成するパケットをD PGバッファ１２７に出力する。
　D PGデコーダ１２８は、D PGバッファ１２７に記憶されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。
　D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
　合成部１３０は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンと、B IGプレーン生成部１１７から供給されたBase IGのプレーンと、B PGプレーン生成部１２５から供給されたBase PGのプレーンを所定の順番で重ねることによって合成し、Base viewのプレーンを生成する。
　また、合成部１３０は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンと、D IGプレーン生成部１２１から供給されたDependent IGのプレーンと、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを所定の順番で重ねることによって合成し、Dependent viewのプレーンを生成する。
　合成部１３０は、Base viewのプレーンとDependent viewのプレーンのデータを出力する。合成部１３０から出力されたビデオデータは表示装置３に出力され、Base viewのプレーンとDependent viewのプレーンが交互に表示されることによって3D表示が行われる。
［T-STD(Transport stream-System. Target Decoder)の第１の例］
　ここで、図２１に示す構成のうちの、デコーダと、その周辺の構成について説明する。
　図２２は、ビデオストリームの処理を行う構成を示す図である。
　図２２において、図２１に示す構成と同じ構成には同じ符号を付してある。図２２においては、PIDフィルタ１０４、B videoバッファ１０６、スイッチ１０７、D videoバッファ１０８、スイッチ１０９、ビデオデコーダ１１０、およびDPB(Decoded Picture Buffer)１５１が示されている。図２１には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB１５１が設けられる。
　PIDフィルタ１０４は、Main TSに含まれるBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
　例えば、Base view videoストリームを構成するパケットには、PID=0がPIDの固定値として割り当てられている。また、Dependent view videoストリームを構成するパケットには、0以外の固定の値がPIDとして割り当てられている。
　PIDフィルタ１０４は、PID=0がヘッダに記述されているパケットをB videoバッファ１０６に出力し、0以外のPIDがヘッダに記述されているパケットをスイッチ１０７に出力する。
　B videoバッファ１０６に出力されたパケットは、TB(Transport Buffer)1、MB(Multiplexing Buffer)1を介してVSB1に記憶される。VSB1には、Base view videoのエレメンタリストリームのデータが記憶される。
　スイッチ１０７には、PIDフィルタ１０４から出力されたパケットだけでなく、図２１のPIDフィルタ１０５においてSub TSから抽出されたDependent view videoストリームを構成するパケットも供給される。
　スイッチ１０７は、PIDフィルタ１０４からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
　また、スイッチ１０７は、PIDフィルタ１０５からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
　D videoバッファ１０８に出力されたパケットは、TB2、MB2を介してVSB2に記憶される。VSB2には、Dependent view videoのエレメンタリストリームのデータが記憶される。
　スイッチ１０９は、B videoバッファ１０６のVSB1に記憶されたBase view videoのパケットと、D videoバッファ１０８のVSB2に記憶されたDependent view videoのパケットを順次読み出し、ビデオデコーダ１１０に出力する。
　例えば、スイッチ１０９は、ある時刻のBase view videoのパケットを出力した直後にそれと同じ時刻のDependent view videoのパケットを出力するといったように、同じ時刻のBase view videoのパケットとDependent view videoのパケットを続けてビデオデコーダ１１０に出力する。
　Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには、そのエンコード時に、PCR(Program Clock Reference)同期が確保された同じ時刻情報が設定されている。Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合であっても、対応するピクチャのデータを格納したパケットには同じ時刻情報が設定される。
　時刻情報はDTS(Decoding Time Stamp)、PTS(Presentation Time Stamp)であり、各PES(Packetized Elementary Stream)パケットに設定される。
　すなわち、それぞれのストリームのピクチャをエンコード順／デコード順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャが、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じDTSが設定されている。
　また、それぞれのストリームのピクチャを表示順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャも、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じPTSが設定されている。
　後述するようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造が同じ構造である場合、デコード順で対応するピクチャは、表示順でも対応するピクチャになる。
　パケットの転送がシリアルで行われる場合、あるタイミングでB videoバッファ１０６のVSB1から読み出されたパケットのDTS1と、直後のタイミングでD videoバッファ１０８のVSB2から読み出されたパケットのDTS2は、図２２に示すように同じ時刻を表すものになる。
　スイッチ１０９は、B videoバッファ１０６のVSB1から読み出したBase view videoのパケット、または、D videoバッファ１０８のVSB2から読み出したDependent view videoのパケットをビデオデコーダ１１０に出力する。
　ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットを順次デコードし、デコードして得られたBase view videoのピクチャのデータ、または、Dependent view videoのピクチャのデータをDPB１５１に記憶させる。
　DPB１５１に記憶されたデコード済みのピクチャのデータは、所定のタイミングでスイッチ１１１により読み出される。また、DPB１５１に記憶されたデコード済みのピクチャのデータは、他のピクチャの予測にビデオデコーダ１１０により用いられる。
　データの転送がシリアルで行われる場合、あるタイミングで出力されたBase view videoのピクチャのデータのPTSと、直後のタイミングで出力されたDependent view videoのピクチャのデータのPTSは、同じ時刻を表すものになる。
　Base view videoストリームとDependent view videoストリームは図５等を参照して説明したように１本のTSに多重化される場合があるし、図７を参照して説明したようにそれぞれ異なるTSに含まれることがある。
　図２２のデコーダモデルを実装することにより、再生装置１は、Base view videoストリームとDependent view videoストリームが１本のTSに多重化されている場合であっても、それぞれ異なるTSに含まれる場合であっても、対応することが可能になる。
　例えば図２３に示すように１本のTSが供給される状況しか想定されていない場合、Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれる場合などには対応することができない。
　また、図２２のデコーダモデルによれば、同じDTSを持つことから、Base view videoストリームとDependent view videoストリームが異なるTSに含まれる場合であっても、正しいタイミングでビデオデコーダ１１０にパケットを供給することができる。
　Base view video用のデコーダとDependent view video用のデコーダをそれぞれ並列に設けるようにしてもよい。この場合、Base view video用のデコーダとDependent view video用のデコーダには、それぞれ、同じ時刻のパケットが同じタイミングで供給される。
［第２の例］
　図２４は、ビデオストリームの処理を行う他の構成を示す図である。
　図２４においては、図２２の構成に加えて、スイッチ１１１、L videoプレーン生成部１６１、およびR videoプレーン生成部１６２が示されている。また、PIDフィルタ１０５もスイッチ１０７の前段に示されている。重複する説明については適宜省略する。
　L videoプレーン生成部１６１は、L view videoのプレーンを生成するものであり、図２１のB videoプレーン生成部１１２に替えて設けられる。
　R videoプレーン生成部１６２は、R view videoのプレーンを生成するものであり、図２１のD videoプレーン生成部１１３に替えて設けられる。
　この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。
　すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
　また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
　L viewとR viewの識別には、図１２と図１４を参照して説明したview_typeが用いられる。例えば、コントローラ５１は、PlayListファイルに記述されているview_typeをスイッチ１１１に出力する。
　view_typeの値が0である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。上述したように、view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
　この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
　一方、view_typeの値が1である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
　この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
　L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　H.264 AVC/MVCでエンコードされたBase view video、Dependent view videoのエレメンタリストリーム内には、L viewであるのか、またはR viewであるのかを表す情報（フィールド）が存在しない。
　従って、view_typeをPlayListファイルに設定しておくことにより、記録装置は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを再生装置１に識別させることが可能になる。
　再生装置１は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを識別し、識別結果に応じて出力先を切り替えることができる。
　IG、PGのプレーンについてもそれぞれL viewとR viewが用意されている場合、ビデオストリームのL viewとR viewを区別できることにより、再生装置１はL view同士、R view同士のプレーンの合成を容易に行うことができる。
　上述したように、HDMIケーブルを介してビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが要求されるが、再生装置１はその要求に対応することが可能になる。
　DPB１５１に記憶されたBase view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの識別が、PIDではなく、view_idに基づいて行われるようにしてもよい。
　H.264 AVC/MVCでのエンコード時、エンコード結果のストリームを構成するAccess Unitにはview_idが設定される。view_idにより、各Access Unitがどのview componentのユニットであるのかが識別可能になっている。
　図２５は、Access Unitの例を示す図である。
　図２５のAccess Unit＃１はBase view videoのデータを含むユニットである。Access Unit＃２はDependent view videoのデータを含むユニットである。Access Unitはピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。
　H.264 AVC/MVCでのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなAccess Unitに格納される。H.264 AVC/MVCでのエンコード時、Access Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。
　図２５の例の場合、Access Unit＃２については、そのAccess Unitに格納されるview componentがDependent view videoであることをview_idから識別することが可能になる。
　一方、図２５に示すように、Access Unit＃１に格納されたview componentであるBase view videoにはMVCヘッダが付加されていない。
　上述したようにBase view videoストリームは2D再生にも用いられるデータである。従って、それとの互換性を確保するために、Base view videoにはエンコード時にMVCヘッダが付加されない。あるいは、一度付加されたMVCヘッダが除去される。記録装置によるエンコードについては後述する。
　再生装置１には、MVCヘッダが付加されていないview componentについては、そのview_idが0であり、view componentをBase view videoであるとして認識するように定義（設定）されている。Dependent view videoには、0以外の値がview_idとしてエンコード時に設定される。
　これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
　図２４のスイッチ１１１においては、Base view videoのパケットをデコードして得られたデータとDependent view videoのパケットをデコードして得られたデータの識別が、このようなview_idに基づいて行われるようにしてもよい。
［第３の例］
　図２６は、ビデオストリームの処理を行うさらに他の構成を示す図である。
　図２６の例においては、図２４のL videoプレーン生成部１６１に替えてB videoプレーン生成部１１２が設けられ、R videoプレーン生成部１６２に替えてD videoプレーン生成部１１３が設けられている。B videoプレーン生成部１１２とD videoプレーン生成部１１３の後段にはスイッチ１７１が設けられている。図２６に示す構成においても、view_typeに基づいてデータの出力先が切り替えられるようになされている。
　スイッチ１１１は、DPB１５１に記憶されたデータのうち、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力する。また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
　Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータは、上述したようにPID、またはview_idに基づいて識別される。
　B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
　D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
　スイッチ１７１に対しては、PlayListファイルに記述されているview_typeがコントローラ５１から供給されている。
　view_typeの値が0である場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
　また、この場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
　一方、view_typeの値が1である場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
　また、この場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
　図２６の構成によっても、再生装置１は、L viewとR viewを識別し、識別結果に応じて出力先を切り替えることができる。
［プレーン合成モデルの第１の例］
　図２７は、図２１に示す構成のうちの、合成部１３０と、その前段の構成を示す図である。
　図２７においても、図２１に示す構成と同じ構成には同じ符号を付してある。
　スイッチ１８１には、Main TS、またはSub TSに含まれるIGストリームを構成するパケットが入力される。スイッチ１８１に入力されるIGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
　スイッチ１８２には、Main TS、またはSub TSに含まれるPGストリームを構成するパケットが入力される。スイッチ１８２に入力されるPGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
　図５等を参照して説明したように、IG、PGについても、3D表示を行うためのBase viewのストリームとDependent viewのストリームが用意されている。
　Base viewのIGがBase view videoと合成して表示され、Dependent viewのIGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、ボタンやアイコンなどを3Dで見ることになる。
　また、Base viewのPGがBase view videoと合成して表示され、Dependent viewのPGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、字幕のテキストなどを3Dで見ることになる。
　スイッチ１８１は、Base IGストリームを構成するパケットをB IGデコーダ１１６に出力し、Dependent IGストリームを構成するパケットをD IGデコーダ１２０に出力する。スイッチ１８１は、図２１のスイッチ１１４とスイッチ１１８の機能を有する。図２７においては、各バッファの図示を省略している。
　B IGデコーダ１１６は、スイッチ１８１から供給されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
　B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
　D IGデコーダ１２０は、スイッチ１８１から供給されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。Base IGストリームとDependent IGストリームが１つのデコーダによりデコードされるようにしてもよい。
　D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
　スイッチ１８２は、Base PGストリームを構成するパケットをB PGデコーダ１２４に出力し、Dependent PGストリームを構成するパケットをD PGデコーダ１２８に出力する。スイッチ１８２は、図２１のスイッチ１２２とスイッチ１２６の機能を有する。
　B PGデコーダ１２４は、スイッチ１８２から供給されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
　B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
　D PGデコーダ１２８は、スイッチ１８２から供給されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。Base PGストリームとDependent PGストリームが１つのデコーダによりデコードされるようにしてもよい。
　D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
　ビデオデコーダ１１０は、スイッチ１０９（図２２等）から供給されたパケットを順次デコードし、デコードして得られたBase view videoのデータ、または、Dependent view videoのデータをスイッチ１１１に出力する。
　スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
　B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
　D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
　合成部１３０は、加算部１９１乃至１９４、およびスイッチ１９５から構成される。
　加算部１９１は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９３に出力する。D PGプレーン生成部１２９から加算部１９１に供給されるDependent PGのプレーンには、色情報の変換処理（CLUT(Color Look Up Table)処理）が施される。
　加算部１９２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンを、B videoプレーン生成部１１２から供給されたBase view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９４に出力する。B PGプレーン生成部１２５から加算部１９２に供給されるBase PGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
　加算部１９３は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンを、加算部１９１による合成結果の上に重ねるようにして合成し、合成結果をDependent viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９３に供給されるDependent IGのプレーンには、色情報の変換処理が施される。
　加算部１９４は、B IGプレーン生成部１１７から供給されたBase IGのプレーンを、加算部１９２による合成結果の上に重ねるようにして合成し、合成結果をBase viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９４に供給されるBase IGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
　このようにして生成されたBase viewのプレーンとDependent viewのプレーンに基づいて表示される画像は、ボタンやアイコンが前面に見え、その下（奥行き方向）に字幕のテキストが見え、その下にビデオが見えるような画像になる。
　スイッチ１９５は、view_typeの値が0である場合、Base viewのプレーンをL viewのプレーンとして出力し、Dependent viewのプレーンをR viewのプレーンとして出力する。スイッチ１９５にはコントローラ５１からview_typeが供給される。
　また、スイッチ１９５は、view_typeの値が1である場合、Base viewのプレーンをR viewのプレーンとして出力し、Dependent viewのプレーンをL viewのプレーンとして出力する。供給されたプレーンのうちのどのプレーンがBase viewのプレーンであるのかDependent viewのプレーンであるのかは、PIDやview_idに基づいて識別される。
　このように、再生装置１においては、Base viewのプレーン同士、Dependent viewのプレーン同士、video、IG、PGの各プレーンの合成が行われる。
　video、IG、PGの全てのプレーンの合成が終わった段階で、Base viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
　また、video、IG、PGの全てのプレーンの合成が終わった段階で、Dependent viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
［第２の例］
　図２８は、合成部１３０と、その前段の構成を示す図である。
　図２８に示す構成のうち、図２７に示す構成と同じ構成には同じ符号を付してある。図２８においては、合成部１３０の構成が図２７の構成と異なる。また、スイッチ１１１の動作が、図２７のスイッチ１１１の動作と異なる。B videoプレーン生成部１１２に替えてL videoプレーン生成部１６１が設けられ、D videoプレーン生成部１１３に替えてR videoプレーン生成部１６２が設けられている。重複する説明については省略する。
　スイッチ１１１と、合成部１３０のスイッチ２０１およびスイッチ２０２に対しては、同じview_typeの値がコントローラ５１から供給される。
　スイッチ１１１は、図２４のスイッチ１１１と同様に、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの出力先をview_typeに基づいて切り替える。
　例えば、view_typeの値が0である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
　一方、view_typeの値が1である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
　L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
　合成部１３０は、スイッチ２０１、スイッチ２０２、加算部２０３乃至２０６から構成される。
　スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンとD IGプレーン生成部１２１から供給されたDependent IGのプレーンの出力先をview_typeに基づいて切り替える。
　例えば、view_typeの値が0である場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
　一方、view_typeの値が1である場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
　スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンとD PGプレーン生成部１２９から供給されたDependent PGのプレーンの出力先をview_typeに基づいて切り替える。
　例えば、view_typeの値が0である場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
　一方、view_typeの値が1である場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
　加算部２０３は、スイッチ２０２から供給されたR viewのPGのプレーンを、R videoプレーン生成部１６２から供給されたR view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０５に出力する。
　加算部２０４は、スイッチ２０２から供給されたL viewのPGのプレーンを、L videoプレーン生成部１６１から供給されたL view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０６に出力する。
　加算部２０５は、スイッチ２０１から供給されたR viewのIGのプレーンを、加算部２０３による合成結果のプレーンの上に重ねるようにして合成し、合成結果をR viewのプレーンとして出力する。
　加算部２０６は、スイッチ２０１から供給されたL viewのIGのプレーンを、加算部２０４による合成結果のプレーンの上に重ねるようにして合成し、合成結果をL viewのプレーンとして出力する。
　このように、再生装置１においては、video、IG、PGのそれぞれのBase viewのプレーンとDependent viewのプレーンについて、他のプレーンとの合成の前に、いずれのプレーンがL viewであるのか、またはR viewであるのかが判断される。
　その判断が行われた後、L viewのプレーン同士、R viewのプレーン同士を合成するように、video、IG、PGの各プレーンの合成が行われる。
［記録装置の構成例］
　図２９は、ソフト製作処理部３０１の構成例を示すブロック図である。
　ビデオエンコーダ３１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ３１１は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ３１２に出力する。
　例えば、ビデオエンコーダ３１１は、エンコード時、同じPCRを基準としてDTS、PTSを設定する。すなわち、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じDTSを設定する。
　また、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じPTSを設定する。
　ビデオエンコーダ３１１は、後述するように、デコード順で対応するBase view videoのピクチャとBase view videoのピクチャに、復号に関する補助的な情報である付加情報としてそれぞれ同じ情報を設定する。
　さらに、ビデオエンコーダ３１１は、後述するように、表示順で対応するBase view videoのピクチャとBase view videoのピクチャに、ピクチャの出力順を表すPOCの値としてそれぞれ同じ値を設定する。
　また、ビデオエンコーダ３１１は、後述するように、Base view videoストリームのGOP構造とDependent view videoストリームのGOP構造とを一致させるようにしてエンコードを行う。
　オーディオエンコーダ３１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ３１４に出力する。オーディオエンコーダ３１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
　データエンコーダ３１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ３１６に出力する。
　データエンコーダ３１５は、ビデオエンコーダ３１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。Base view videoストリームの種類ではなく、Dependent view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表す情報が設定されるようにしてもよい。
　また、データエンコーダ３１５は、後述するEP_mapを、Base view videoストリームのClip Informationファイルと、Dependent view videoストリームのClip Informationファイルにそれぞれ設定する。デコード開始位置としてEP_mapに設定されたBase view videoストリームのピクチャと、Dependent view videoストリームのピクチャは対応するピクチャになる。
　多重化部３１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部３１８に出力する。
　誤り訂正符号化部３１８は、エラー訂正用のコードを多重化部３１７により多重化されたデータに付加する。
　変調部３１９は、誤り訂正符号化部３１８から供給されたデータに対して変調を施し、出力する。変調部３１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。
　このような構成を有するソフト製作処理部３０１が記録装置に設けられる。
　図３０は、ソフト製作処理部３０１を含む構成の例を示す図である。
　図３０に示す構成の一部が記録装置内に設けられることもある。
　ソフト製作処理部３０１により生成された記録信号はプリマスタリング処理部３３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部３３３に供給される。
　記録用原盤製作部３３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
　原盤記録部３３３において、プリマスタリング処理部３３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
　金属原盤製作部３３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
　成形処理部３３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
　成膜処理部３３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
　後加工処理部３３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。
＜第２の実施の形態＞
［H.264 AVC/MVC Profileビデオストリームの運用１］
　光ディスク２の規格であるBD-ROM規格においては、上述したように、H.264 AVC/MVC Profileを採用することで3D映像の符号化が実現される。
　また、BD-ROM規格においては、Base view videoストリームをL viewの映像のストリームとし、Dependent view videoストリームをR viewの映像のストリームとする。
　Base view videoをH.264 AVC/High Profileビデオストリームとして符号化することにより、過去のプレーヤや2D再生のみに対応したプレーヤにおいても、3D対応のディスクである光ディスク２を再生することが可能になる。すなわち、下位互換性を確保することが可能になる。
　具体的には、Base view videoのストリームのみをH.264 AVC/MVC非対応デコーダにおいてもデコード(再生)可能になる。つまり、Base view videoストリームは、既存の2DのBDプレーヤにおいても必ず再生可能なストリームになる。
　また、Base view videoストリームを、2D再生と3D再生において共通して使用することにより、オーサリング時の負荷の軽減を図ることが可能になる。オーサリング側は、AVストリームに関しては、従来行っていた作業に加えて、Dependent view videoストリームを用意すれば3D対応のディスクを製作することが可能になる。
　図３１は、記録装置に設けられる3D video TS生成部の構成例を示す図である。
　図３１の3D video TS生成部は、MVCエンコーダ４０１、MVCヘッダ除去部４０２、およびマルチプレクサ４０３から構成される。図２を参照して説明したようにして撮影されたL viewの映像＃１のデータと、R viewの映像＃２のデータがMVCエンコーダ４０１に入力される。
　MVCエンコーダ４０１は、図３のMVCエンコーダ１１と同様に、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオデータをBase view videoストリームとして出力する。また、MVCエンコーダ４０１は、L viewの映像＃１のデータとR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、出力する。
　MVCエンコーダ４０１から出力されたBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４０１から出力されたDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
　Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
　Dependent view videoのMVCヘッダに記述されるview_idの値としては、１以上の固定値が用いられる。図３２、図３３の例においても同様である。
　すなわち、MVCエンコーダ４０１は、図３のMVCエンコーダ１１とは異なり、MVCヘッダを付加した形でBase view videoとDependent view videoのそれぞれのストリームを生成し、出力するエンコーダである。図３のMVCエンコーダ１１においては、H.264 AVC/MVCで符号化されたDependent view videoのみにMVCヘッダが付加されている。
　MVCエンコーダ４０１から出力されたBase view videoストリームはMVCヘッダ除去部４０２に供給され、Dependent view videoストリームはマルチプレクサ４０３に供給される。
　MVCヘッダ除去部４０２は、Base view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４０２は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４０３に出力する。
　マルチプレクサ４０３は、MVCヘッダ除去部４０２から供給されたBase view videoストリームと、MVCエンコーダ４０１から供給されたDependent view videoストリームを含むTSを生成し、出力する。図３１の例においては、Base view videoストリームを含むTSとDependent view videoストリームを含むTSがそれぞれ出力されているが、上述したように同じTSに多重化されて出力されることもある。
　このように、実装の仕方によっては、L viewの映像とR viewの映像を入力とし、MVCヘッダ付のBase view videoとDependent view videoのそれぞれのストリームを出力するMVCエンコーダも考えられる。
　なお、図３１に示す構成全体を図３に示すようにMVCエンコーダの中に含めることも可能である。図３２、図３３に示す構成についても同様である。
　図３２は、記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
　図３２の3D video TS生成部は、混合処理部４１１、MVCエンコーダ４１２、分離部４１３、MVCヘッダ除去部４１４、およびマルチプレクサ４１５から構成される。L viewの映像＃１のデータと、R viewの映像＃２のデータが混合処理部４１１に入力される。
　混合処理部４１１は、L viewの各ピクチャとR viewの各ピクチャを符号化順に並べる。Dependent view videoの各ピクチャは対応するBase view videoのピクチャを参照して符号化が行われるから、符号化順に並べた結果は、L viewのピクチャとR viewのピクチャが交互に並ぶものになる。
　混合処理部４１１は、符号化順に並べたL viewのピクチャとR viewのピクチャをMVCエンコーダ４１２に出力する。
　MVCエンコーダ４１２は、混合処理部４１１から供給された各ピクチャをH.264 AVC/MVCで符号化し、符号化して得られたストリームを分離部４１３に出力する。MVCエンコーダ４１２から出力されたストリームには、Base view videoストリームとDependent view videoストリームが多重化されている。
　MVCエンコーダ４１２から出力されたストリームに含まれるBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４１２から出力されたストリームに含まれるDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
　Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
　分離部４１３は、MVCエンコーダ４１２から供給されたストリームに多重化されているBase view videoストリームとDependent view videoストリームを分離し、出力する。分離部４１３から出力されたBase view videoストリームはMVCヘッダ除去部４１４に供給され、Dependent view videoストリームはマルチプレクサ４１５に供給される。
　MVCヘッダ除去部４１４は、分離部４１３から供給されたBase view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４１４は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４１５に出力する。
　マルチプレクサ４１５は、MVCヘッダ除去部４１４から供給されたBase view videoストリームと、分離部４１３から供給されたDependent view videoストリームを含むTSを生成し、出力する。
　図３３は、記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
　図３３の3D video TS生成部は、AVCエンコーダ４２１、MVCエンコーダ４２２、およびマルチプレクサ４２３から構成される。L viewの映像＃１のデータはAVCエンコーダ４２１に入力され、R viewの映像＃２のデータはMVCエンコーダ４２２に入力される。
　AVCエンコーダ４２１は、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオストリームをBase view videoストリームとしてMVCエンコーダ４２２とマルチプレクサ４２３に出力する。AVCエンコーダ４２１から出力されたBase view videoストリームを構成する各Access UnitにはMVCヘッダが含まれていない。
　MVCエンコーダ４２２は、AVCエンコーダ４２１から供給されたBase view videoストリーム（AVCビデオストリーム）をデコードし、L viewの映像＃１のデータを生成する。
　また、MVCエンコーダ４２２は、デコードして得られたL viewの映像＃１のデータと、外部から入力されたR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、マルチプレクサ４２３に出力する。MVCエンコーダ４２２から出力されたDependent view videoストリームを構成する各Access UnitにはMVCヘッダが含まれている。
　マルチプレクサ４２３は、AVCエンコーダ４２１から供給されたBase view videoストリームと、MVCエンコーダ４２２から供給されたDependent view videoストリームを含むTSを生成し、出力する。
　図３３のAVCエンコーダ４２１が図３のH.264/AVCエンコーダ２１の機能を有し、MVCエンコーダ４２２が図３のH.264/AVCデコーダ２２とDependent view videoエンコーダ２４の機能を有することになる。また、マルチプレクサ４２３が図３のマルチプレクサ２５の機能を有することになる。
　このような構成を有する3D video TS生成部を記録装置内に設けることにより、Base view videoのデータを格納するAccess Unitに対するMVCヘッダの符号化を禁止することが可能になる。また、Dependent view videoのデータを格納するAccess Unitに、１以上のview_idが設定されたMVCヘッダが含まれるようにすることができる。
　図３４は、Access Unitをデコードする再生装置１側の構成を示す図である。
　図３４においては、図２２等を参照して説明したスイッチ１０９とビデオデコーダ１１０が示されている。Base view videoのデータを含むAccess Unit＃１と、Dependent view videoのデータを含むAccess Unit＃２がバッファから読み出され、スイッチ１０９に供給される。
　Base view videoを参照して符号化が行われているから、Dependent view videoを正しく復号するには、まず、対応するBase view videoを復号しておくことが必要になる。
　H.264/MVC規格においては、デコーダ側が、MVCヘッダに含まれるview_idを利用して各Access Unitの復号順序を算出するようになされている。また、Base view videoには、そのエンコード時に、常に最小の値をview_idの値として設定することが定められている。デコーダは、最小のview_idが設定されているMVCヘッダを含むAccess Unitから復号を開始することで、Base view videoとDependent view videoを正しい順序で復号することができるようになされている。
　ところで、再生装置１のビデオデコーダ１１０に供給される、Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。
　そこで、再生装置１においては、MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。
　これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
　図３４のスイッチ１０９は、最小の値である0がview_idとして設定されていると認識したAccess Unit＃１をまずビデオデコーダ１１０に出力し、デコードを行わせる。
　また、スイッチ１０９は、Access Unit＃１のデコードが終了した後、0より大きい固定値であるYがview_idとして設定されているAccess Unit＃２をビデオデコーダ１１０に出力し、デコードを行わせる。Access Unit＃２に格納されているDependent view videoのピクチャは、Access Unit＃１に格納されているBase view videoのピクチャに対応するピクチャである。
　このように、Base view videoを格納したAccess Unitに対するMVCヘッダの符号化を禁止することにより、光ディスク２に記録されているBase view videoストリームを、従来のプレーヤにおいても再生可能なストリームとすることができる。
　BD-ROM規格を拡張したBD-ROM 3D規格のBase view videoストリームの条件として、従来のプレーヤにおいても再生可能なストリームとするような条件が決められた場合であっても、その条件を満たすようにすることができる。
　例えば、図３５に示すように、Base view videoとDependent view videoにそれぞれMVCヘッダを付加しておき、Base view videoから先にデコードが行われるようにした場合、そのBase view videoは従来のプレーヤにおいては再生できないものになる。従来のプレーヤが搭載するH.264/AVCデコーダにとっては、MVCヘッダは未定義のデータである。そのような未定義のデータが入力された場合、デコーダによってはそれを無視することができず、処理が破綻するおそれがある。
　なお、図３５においては、Base view videoのview_idはX、Dependent view videoのview_idは、Xより大きいYである。
　また、MVCヘッダの符号化を禁止した場合であっても、Base view videoのview_idを0としてみなすように定義することにより、再生装置１にBase view videoのデコードを先に行わせ、その後に、対応するDependent view videoのデコードを行わせることができる。すなわち、正しい順序でデコードを行わせることが可能になる。
［運用２］
　GOP構造について
　H.264/AVC規格には、MPEG-2ビデオ規格におけるGOP(Group Of Pictures)構造が定義されていない。
　そこで、H.264/AVCビデオストリームを扱うBD-ROM規格においては、H.264/AVCビデオストリームのGOP構造を定義し、ランダムアクセスなどのGOP構造を利用した各種の機能を実現している。
　H.264 AVC/MVCで符号化して得られたビデオストリームであるBase view videoストリームとDependent view videoストリームにも、H.264/AVCビデオストリームと同様にGOP構造の定義が存在しない。
　Base view videoストリームはH.264/AVCビデオストリームである。従って、Base view videoストリームのGOP構造は、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造になる。
　Dependent view videoストリームのGOP構造についても、Base view videoストリームのGOP構造、すなわち、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造として定義する。
　BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造には次のような特徴がある。
　１．ストリーム構造についての特徴
　（１）Open GOP/Closed GOP構造
　図３６は、Closed GOP構造を示す図である。
　図３６の各ピクチャはH.264/AVCビデオストリームを構成するピクチャである。Closed GOPにはIDR(Instantaneous Decoding Refresh)ピクチャが含まれる。
　IDRピクチャはＩピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファ（図２２のDPB１５１）の状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
　図３６に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。
　また、現在GOPのピクチャのうち、IDRピクチャより表示順で後（未来）のピクチャは、IDRピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。H.264/AVCにおいては、表示順でＩピクチャの後ろにあるＰピクチャから、そのＩピクチャより前のピクチャを参照することも許されている。
　図３７は、Open GOP構造を示す図である。
　図３７に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDR Ｉピクチャ（IDRピクチャではないＩピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
　また、現在GOPのピクチャのうち、non-IDR Ｉピクチャより表示順で後のピクチャは、non-IDR Ｉピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
　（２）GOPの先頭のAccess Unitには、SPS、PPSが必ず符号化される。
　SPS(Sequence Parameter Set)は、シーケンス全体の符号化に関する情報を含む、シーケンスのヘッダ情報である。あるシーケンスのデコード時、シーケンスの識別情報などが含まれるSPSが最初に必要になる。PPS(Picture Parameter Set)は、ピクチャ全体の符号化に関する情報を含む、ピクチャのヘッダ情報である。
　（３）GOPの先頭のAccess Unitには、最大30個までのPPSを符号化することができる。複数のPPSを先頭のAccess Unitに符号化した場合には、各PPSのid(pic_parameter_set_id)は一緒であってはならない。
　（４）GOPの先頭以外のAccess Unitには、最大1個までのPPSを符号化することができる。
　２．参照構造についての特徴
　（１）I・P・Bピクチャは、それぞれI・P・Bスライスのみから構成されるピクチャであることが求められる。
　（２）表示順で参照ピクチャ（I or Pピクチャ）の直前のBピクチャは、符号化順では、必ず、その参照ピクチャの直後に符号化されていることが求められる。
　（３）参照ピクチャ（I or Pピクチャ）の符号化順と表示順は維持されること（同じであること）が求められる。
　（４）PピクチャからBピクチャを参照することは禁止される。
　（５）符号化順で、非参照Bピクチャ（B1）が非参照ピクチャ（B2）の前である場合、表示順もB1が前になることが求められる。
　非参照Bピクチャは、符号化順で後ろにある他のピクチャによって参照されないBピクチャである。
　（６）参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）を参照することができる。
　（７）非参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）、又は参照Bピクチャを参照することができる。
　（８）連続するBピクチャの数を最大3枚とすることが求められる。
　３．GOP内の最大フレーム・フィールド数についての特徴
　GOP内の最大フレーム・フィールド数は、図３８に示すようにビデオのフレームレートに応じて規定されている。
　図３８に示すように、例えば、フレームレートが29.97フレーム／秒でインタレース表示を行う場合、1GOPのピクチャで表示させることが可能な最大フィールド数は60である。また、フレームレートが59.94フレーム／秒でプログレッシブ表示を行う場合、1GOPのピクチャで表示させることが可能な最大フレーム数は60である。
　以上のような特徴を有するGOP構造を、Dependent view videoストリームのGOP構造としても定義する。
　また、Base view videoストリームのあるGOPの構造と、対応するDependent view videoストリームのGOPの構造を一致させることを制約として規定する。
　以上のようにして定義したBase view videoストリーム、またはDependent view videoストリームのClosed GOP構造を図３９に示す。
　図３９に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。アンカーピクチャについては後述する。
　また、現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で後（未来）のピクチャは、IDRピクチャ、またはアンカーピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。
　図４０は、Base view videoストリーム、またはDependent view videoストリームのOpen GOP構造を示す図である。
　図４０に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDRアンカーピクチャ（IDRピクチャではないアンカーピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
　また、現在GOPのピクチャのうち、non-IDRアンカーピクチャより表示順で後のピクチャは、non-IDRアンカーピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
　以上のようにしてGOP構造を定義することにより、例えば、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、Open GOPであるのか、Closed GOPであるのかといったようなストリーム構造の特徴が一致することになる。
　また、Base view videoの非参照Bピクチャに対応するDependent view videoのピクチャは必ず非参照Bピクチャになるといったように、ピクチャの参照構造の特徴も一致することになる。
　さらに、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、フレーム数、フィールド数も一致することになる。
　このように、Dependent view videoストリームのGOP構造をBase view videoストリームのGOP構造と同じ構造として定義することにより、ストリーム間の対応するGOP同士に同じ特徴を持たせることが可能になる。
　また、ストリームの途中からデコードを行うような場合でも、問題なくそれを行うことが可能になる。ストリームの途中からのデコードは、例えば、トリックプレイやランダムアクセスのときに行われる。
　フレーム数が異なるといったように、ストリーム間の対応するGOP同士の構造が異なる場合、一方のストリームは正常に再生できるのに他方のストリームが再生できないといったことが生じるおそれがあるが、それを防ぐことができる。
　ストリーム間の対応するGOP同士の構造を異なるものとしてストリームの途中からデコードを開始した場合、Dependent view videoのデコードに必要となるBase view videoのピクチャがデコードされていないといったことが生じるおそれもある。この場合、結果として、Dependent view videoのピクチャをデコードすることができず、3D表示を行うことができなくなる。また、実装の方法によっては、Base view videoの画像も出力できない可能性があるが、それらの不都合も回避することができる。
　EP_mapについて
　Base view videoストリームとDependent view videoストリームのGOP構造を利用することで、ランダムアクセスやトリックプレイ時のデコードの開始位置をEP_mapに設定することが可能になる。EP_mapはClip Informationファイルに含まれる。
　デコード開始位置としてEP_mapに設定可能なピクチャの制約として次の２つの制約を規定する。
　１．Dependent view videoストリームに設定可能な位置を、SubsetSPSに続けて配置されるアンカーピクチャの位置か、SubsetSPSに続けて配置されるIDRピクチャの位置とする。
　アンカーピクチャは、H.264 AVC/MVCで規定されるピクチャであり、時間方向に参照せずに、view間の参照を行って符号化されたDependent view videoストリームのピクチャである。
　２．Dependent view videoストリームのあるピクチャをデコード開始位置としてEP_mapに設定する場合、対応するBase view videoストリームのピクチャも、デコード開始位置としてEP_mapに設定する。
　図４１は、上記２つの制約を満たすEP_mapに設定されたデコード開始位置の例を示す図である。
　図４１においては、Base view videoストリームを構成するピクチャと、Dependent view videoストリームを構成するピクチャをデコード順に示している。
　Dependent view videoストリームのピクチャのうちの色を付けて示すピクチャＰ1は、アンカーピクチャ、またはIDRピクチャである。ピクチャＰ1のデータを含むAccess Unitの直前のAccess UnitにはSubsetSPSが含まれる。
　図４１の例においては、白抜き矢印＃１１で示すように、ピクチャＰ1が、Dependent view videoストリームのEP_mapにデコード開始位置として設定されている。
　ピクチャＰ1に対応するBase view videoストリームのピクチャであるピクチャＰ11はIDRピクチャである。白抜き矢印＃１２で示すように、IDRピクチャであるピクチャＰ11も、Base view videoストリームのEP_mapにデコード開始位置として設定されている。
　ランダムアクセスやトリックプレイが指示されたことから、ピクチャＰ1とピクチャＰ11からデコードを開始する場合、最初に、ピクチャＰ11のデコードが行われる。IDRピクチャであるから、他のピクチャを参照することなく、ピクチャＰ11をデコードすることが可能である。
　ピクチャＰ11のデコードが終了したとき、次に、ピクチャＰ1がデコードされる。ピクチャＰ1のデコードにはデコード済みのピクチャＰ11が参照される。アンカーピクチャ、またはIDRピクチャであるから、ピクチャＰ11のデコードが終了していればピクチャＰ1のデコードは可能である。
　その後、Base view videoのピクチャＰ1の次のピクチャ、Dependent view videoのピクチャＰ11の次のピクチャ、・・・といったようにしてデコードが行われる。
　対応するGOPの構造が同じであり、かつ、対応する位置からデコードが開始されるから、Base view videoについてもDependent view videoについても、EP_mapに設定されたピクチャ以降のピクチャを問題なくデコードすることができる。これによりランダムアクセスを実現することが可能になる。
　図４１の垂直方向に示す点線より左側に並ぶピクチャはデコードされないピクチャになる。
　図４２は、Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
　図４２の例においては、色を付けて示すBase view videoのIDRピクチャであるピクチャＰ21がデコード開始位置としてEP_mapに設定されている。
　Base view videoのピクチャＰ21からデコードを開始する場合において、ピクチャＰ21に対応するDependent view videoのピクチャであるピクチャＰ31がアンカーピクチャではない場合を考える。GOP構造を定義していない場合、Base view videoのIDRピクチャに対応するDependent view videoのピクチャが、IDRピクチャまたはアンカーピクチャであるという保障はない。
　この場合、Base view videoのピクチャＰ21のデコードが終わったときであっても、ピクチャＰ31をデコードすることはできない。ピクチャＰ31のデコードには時間方向の参照も必要になるが、垂直方向に示す点線より左側（デコード順で前）のピクチャはデコードされていない。
　ピクチャＰ31をデコードすることができないことにより、ピクチャＰ31を参照するDependent view videoの他のピクチャもデコードすることができないことになる。
　Dependent view videoストリームのGOP構造を定義しておくことにより、このようなことを回避することができる。
　Base view videoだけでなく、Dependent view videoについてもEP_mapでデコード開始位置を設定しておくことにより、再生装置１はデコードの開始位置を容易に特定することが可能になる。
　Base view videoのあるピクチャだけをデコード開始位置としてEP_mapに設定しておいた場合、再生装置１は、デコード開始位置のピクチャに対応するDependent view videoのピクチャを計算により特定する必要があり、処理が複雑になってしまう。
　たとえ対応するBase view videoとDependent view videoのピクチャ同士が同じDTS/PTSを持っていたとしても、ビデオのビットレートが異なる場合にはTSにおけるバイト配列まで一致させることができないため、この場合に処理が複雑になる。
　図４３は、Base view videoストリームとDependent view videoストリームからなるMVCストリームを対象にしたランダムアクセスやトリックプレイを行う際に必要になるピクチャサーチの概念を示す図である。
　図４３に示すように、ランダムアクセスやトリックプレイを行う際、non-IDRアンカーピクチャかIDRピクチャがサーチされ、デコード開始位置が決定される。
　ここで、EP_mapについて説明する。Base view videoのデコード開始位置をEP_mapに設定する場合について説明するが、Dependent view videoのデコード開始位置についても、同様にしてDependent view video のEP_mapに設定される。
　図４４は、光ディスク２上に記録されたAVストリームの構造を示す図である。
　Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
　アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。１つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
　Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
　PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
　なお、ソースパケットには、Clip AVストリームの先頭を例えば０として、ソースパケット毎に１ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第１バイト目から始まる。
　EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
　EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の１つのEPデータは、PTSと、PTSに対応するAccess Unitの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、１Access Unitには１ピクチャ分のデータが格納される。
　図４５は、Clip AVストリームの例を示す図である。
　図４５のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム（Base view videoストリーム）である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
　図４５においては、ビデオストリームのソースパケットのうちの、IDRピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
　例えば、PID=ｘで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
　同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
　図４６は、図４５のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
　図４６に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
　stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
　PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UnitのPTSを表す。
　SPN_EP_startは、PTS_EP_startの値により参照されるAccess Unitの第１バイト目を含むソースパケットのアドレスを表す。
　ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
　例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
　このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
　図４７は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
　上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Unitの第１バイト目を含むソースパケットのソースパケット番号を表す。
　AVC/H.264においては、Access Unitすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
　トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が１であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Unitが開始されることになる。
　このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
［運用３］
　Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPOC(Picture Order Count)が符号化時に設定されている。POCは、ピクチャの表示順を表す値である。
　AVC/H.264においては、POCは「A variable having a value that is non-decreasing with increasing picture position in output order relative to the previous IDR picture in decoding order or relative to the previous picture containing the memory management control operation that marks all reference pictures as “unused for reference”.」として規定されている。
　符号化時、Base view videoストリームのピクチャに設定するPOCと、Dependent view videoストリームのピクチャに設定するPOCは統一して運用される。
　例えば、Base view videoストリームの表示順で１番目のピクチャにはPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
　また、Dependent view videoストリームの表示順で１番目のピクチャには、Base view videoストリームの１番目のピクチャに設定されるものと同じPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
　上述したようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造は同じであるから、Base view videoストリームとDependent view videoストリームの各ピクチャには、表示順で対応するピクチャ同士、同じPOCが設定される。
　これにより、再生装置１は、同じPOCが設定されているview componentを、表示順で対応するview componentとして処理することが可能になる。
　例えば、再生装置１は、Base view videoストリームのピクチャのうちのPOC=1が設定されているピクチャと、Dependent view videoストリームのピクチャのうちのPOC=1が設定されているピクチャを、対応するピクチャとして処理することができる。
　また、Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPicture Timing SEI(Supplemental Enhancement Information)が設定されている。SEIは、H.264/AVCで規定される、デコードに関する補助的な情報を含む付加情報である。
　SEIのうちの１つであるPicture Timing SEIには、符号化時のCPB(Coded Picture Buffer)からの読み出し時刻、デコード時のDPB（図２２のDPB１５１）からの読み出し時刻などの時刻情報が含まれる。また、表示時刻の情報、ピクチャ構造の情報などが含まれる。
　符号化時、Base view videoストリームのピクチャに設定するPicture Timing SEIと、Dependent view videoストリームのピクチャに設定するPicture Timing SEIは統一して運用される。
　例えば、Base view videoストリームの符号化順で１番目のピクチャにCPBからの読み出し時刻としてT1が設定された場合、Dependent view videoストリームの符号化順で１番目のピクチャにも、CPBからの読み出し時刻としてT1が設定される。
　すなわち、Base view videoストリームとDependent view videoストリームの各ピクチャには、符号化順、または復号順で対応するピクチャ同士、同じ内容のPicture Timing SEIが設定される。
　これにより、再生装置１は、同じPicture Timing SEIが設定されているview componentを、復号順で対応するview componentとして処理することが可能になる。
　POC、Picture Timing SEIは、Base view videoとDependent view videoのエレメンタリストリームに含まれるものであり、再生装置１においてはビデオデコーダ１１０により参照される。
　ビデオデコーダ１１０は、エレメンタリストリームに含まれる情報に基づいて、対応するview componentを識別することが可能になる。また、ビデオデコーダ１１０は、Picture Timing SEIに基づいて正しい復号順で、また、POCに基づいて正しい表示順になるようにデコード処理を行うことが可能になる。
　対応するview componentを識別するためにPlayListなどを参照する必要がないため、System Layerや、それ以上のLayerに問題が起きた場合の対処が可能になる。また、問題が起きたLayerに依存しないデコーダ実装も可能になる。
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
　図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
　CPU(Central Processing Unit)５０１、ROM(Read Only Memory)５０２、RAM(Random Access Memory)５０３は、バス５０４により相互に接続されている。
　バス５０４には、さらに、入出力インタフェース５０５が接続されている。入出力インタフェース５０５には、キーボード、マウスなどよりなる入力部５０６、ディスプレイ、スピーカなどよりなる出力部５０７が接続される。また、バス５０４には、ハードディスクや不揮発性のメモリなどよりなる記憶部５０８、ネットワークインタフェースなどよりなる通信部５０９、リムーバブルメディア５１１を駆動するドライブ５１０が接続される。
　以上のように構成されるコンピュータでは、CPU５０１が、例えば、記憶部５０８に記憶されているプログラムを入出力インタフェース５０５及びバス５０４を介してRAM５０３にロードして実行することにより、上述した一連の処理が行われる。
　CPU５０１が実行するプログラムは、例えばリムーバブルメディア５１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部５０８にインストールされる。
　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
　１　再生装置，　２　光ディスク，　３　表示装置，　１１　MVCエンコーダ，　２１　H.264/AVCエンコーダ，　２２　H.264/AVCデコーダ，　２３　Depth算出部，　２４　Dependent view videoエンコーダ，　２５　マルチプレクサ，　５１　コントローラ，　５２　ディスクドライブ，　５３　メモリ，　５４　ローカルストレージ，　５５　インターネットインタフェース，　５６　デコーダ部，　５７　操作入力部

Claims (7)

  1. 　複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行う符号化手段を備える
    　記録装置。
  2. 　複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行う
    　ステップを含む記録方法。
  3. 　複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームをそれぞれ異なるトランスポートストリームに含めて記録媒体に記録する場合、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSを設定し、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSを設定して、符号化を行うステップを含む
    　処理をコンピュータに実行させるプログラム。
  4. 　複数の映像データを所定の符号化方式で符号化して得られた基本ストリームを構成する第１のピクチャと拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じDTSが設定され、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに、同じPCRを基準とする同じPTSが設定された、
    　前記基本ストリームと前記拡張ストリームが記録された
    　記録媒体。
  5. 　記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力する復号手段を備える
    　再生装置。
  6. 　記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力する
    　ステップを含む再生方法。
  7. 　記録媒体に記録されているそれぞれ異なるトランスポートストリームに含まれる、複数の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームを取得し、
    　前記基本ストリームを構成する第１のピクチャと前記拡張ストリームを構成する第２のピクチャのうちの、復号順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じDTSに基づいて復号を行い、
    　表示順で同じ位置にある前記第１のピクチャと前記第２のピクチャのそれぞれのデータを格納するパケットに設定されている、同じPCRを基準とする同じPTSに基づいて、復号結果のデータを出力する
    　ステップを含む処理をコンピュータに実行させるプログラム。
PCT/JP2010/056237 2009-04-08 2010-04-06 記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体 Ceased WO2010116998A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US12/995,639 US8792780B2 (en) 2009-04-08 2010-04-06 Reproduction and recording apparatus and method for playing back and recording data encoded according to a predetermined standard
CN201080001745.XA CN102047674B (zh) 2009-04-08 2010-04-06 记录设备、记录方法、重放设备、重放方法、程序和记录介质
HK11111733.6A HK1157546B (en) 2009-04-08 2010-04-06 Recording device, recording method, reproduction device, reproduction method, program, and recording medium
EP10761697.1A EP2285130A4 (en) 2009-04-08 2010-04-06 RECORDING DEVICE, RECORDING METHOD, REPRODUCTION DEVICE, PLAYING METHOD, PROGRAM AND RECORDING MEDIUM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-094257 2009-04-08
JP2009094257A JP4993224B2 (ja) 2009-04-08 2009-04-08 再生装置および再生方法

Publications (1)

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

Family

ID=42936281

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/056237 Ceased WO2010116998A1 (ja) 2009-04-08 2010-04-06 記録装置、記録方法、再生装置、再生方法、プログラム、および記録媒体

Country Status (6)

Country Link
US (1) US8792780B2 (ja)
EP (1) EP2285130A4 (ja)
JP (1) JP4993224B2 (ja)
CN (3) CN103079082B (ja)
TW (1) TWI428016B (ja)
WO (1) WO2010116998A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10728443B1 (en) 2019-03-27 2020-07-28 On Time Staffing Inc. Automatic camera angle switching to create combined audiovisual file
CN111953984A (zh) * 2019-05-16 2020-11-17 佳能株式会社 摄像装置及其控制方法和非易失性计算机可读存储介质
US10963841B2 (en) 2019-03-27 2021-03-30 On Time Staffing Inc. Employment candidate empathy scoring system
US11023735B1 (en) 2020-04-02 2021-06-01 On Time Staffing, Inc. Automatic versioning of video presentations
US11127232B2 (en) 2019-11-26 2021-09-21 On Time Staffing Inc. Multi-camera, multi-sensor panel data extraction system and method
US11144882B1 (en) 2020-09-18 2021-10-12 On Time Staffing Inc. Systems and methods for evaluating actions over a computer network and establishing live network connections
US11423071B1 (en) 2021-08-31 2022-08-23 On Time Staffing, Inc. Candidate data ranking method using previously selected candidate data
US11727040B2 (en) 2021-08-06 2023-08-15 On Time Staffing, Inc. Monitoring third-party forum contributions to improve searching through time-to-live data assignments
US11907652B2 (en) 2022-06-02 2024-02-20 On Time Staffing, Inc. User interface and systems for document creation

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4993224B2 (ja) * 2009-04-08 2012-08-08 ソニー株式会社 再生装置および再生方法
WO2010123909A1 (en) 2009-04-20 2010-10-28 Dolby Laboratories Licensing Corporation Directed interpolation and data post-processing
KR101803970B1 (ko) * 2011-03-16 2017-12-28 삼성전자주식회사 컨텐트를 구성하는 장치 및 방법
WO2013074160A1 (en) * 2011-11-14 2013-05-23 General Instrument Corporation Association of mvc stereoscopic views to left or right eye display for 3dtv
KR20140099146A (ko) * 2013-02-01 2014-08-11 한국전자통신연구원 다중 영상 기반 방송 서비스를 위한 다중 영상의 기준 ｐｃｒ 결정 방법 및 그 장치
CN105991586B (zh) * 2015-02-13 2019-04-26 上海交通大学 一种异构网络下的多媒体时钟协调同步方法
CN107872671B (zh) * 2016-09-26 2022-01-14 华为技术有限公司 一种图片编码方法及终端
US10554711B2 (en) * 2016-09-29 2020-02-04 Cisco Technology, Inc. Packet placement for scalable video coding schemes
CN109194985B (zh) * 2018-11-19 2021-03-26 上海高骏精视信息技术有限公司 一种音视频以太网传输方法及其系统

Citations (6)

* 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 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2002027413A (ja) * 2000-07-07 2002-01-25 Sanyo Electric Co Ltd デジタルビデオ再生装置
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
WO2007010779A1 (ja) * 2005-07-15 2007-01-25 Matsushita Electric Industrial Co., Ltd. パケット送信装置
JP2008252740A (ja) 2007-03-30 2008-10-16 Sony Corp リモートコマンダおよびコマンド発生方法、再生装置および再生方法、プログラム、並びに、記録媒体
WO2009090868A1 (ja) * 2008-01-17 2009-07-23 Panasonic Corporation ３ｄ映像が記録された記録媒体、３ｄ映像を記録する記録装置、並びに３ｄ映像を再生する再生装置及び再生方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6246767B1 (en) * 1995-04-03 2001-06-12 Scientific-Atlanta, Inc. Source authentication of download information in a conditional access system
HRP970160A2 (en) * 1996-04-03 1998-02-28 Digco B V Method for providing a secure communication between two devices and application of this method
EP1021048A3 (en) * 1999-01-14 2002-10-02 Kabushiki Kaisha Toshiba Digital video recording system and its recording medium
WO2000055854A1 (en) * 1999-03-17 2000-09-21 Kabushiki Kaisha Toshiba Method for recording stream data and its data structure
EP1134702A3 (en) * 2000-03-14 2003-10-29 Samsung Electronics Co., Ltd. Method for processing nodes in 3D scene and apparatus thereof
GB0007868D0 (en) * 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for editing digital video recordings and recordings made by such methods
JP3789794B2 (ja) * 2001-09-26 2006-06-28 三洋電機株式会社 立体画像処理方法、装置、およびシステム
KR100397511B1 (ko) * 2001-11-21 2003-09-13 한국전자통신연구원 양안식/다시점 3차원 동영상 처리 시스템 및 그 방법
JP2006500718A (ja) * 2002-09-26 2006-01-05 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ 多重ストリーム読み出し装置及び方法
JP4224690B2 (ja) * 2002-12-27 2009-02-18 ソニー株式会社 記録方法、記録装置、再生方法、再生装置および撮像装置
KR100585966B1 (ko) 2004-05-21 2006-06-01 한국전자통신연구원 3차원 입체 영상 부가 데이터를 이용한 3차원 입체 디지털방송 송/수신 장치 및 그 방법
KR100657322B1 (ko) 2005-07-02 2006-12-14 삼성전자주식회사 로컬 3차원 비디오를 구현하기 위한 인코딩/디코딩 방법 및장치
CN101026725B (zh) * 2005-07-15 2010-09-29 索尼株式会社 再现设备及再现方法
CN100583977C (zh) * 2005-09-27 2010-01-20 韩国电子通信研究院 用于高质量视频服务的传送和接收数字多媒体广播的设备
US20090141814A1 (en) * 2006-01-09 2009-06-04 Peng Yin Method and Apparatus for Providing Reduced Resolution Update Mode for Multi-View Video Coding
ZA200805337B (en) * 2006-01-09 2009-11-25 Thomson Licensing Method and apparatus for providing reduced resolution update mode for multiview video coding
US8767836B2 (en) * 2006-03-27 2014-07-01 Nokia Corporation Picture delimiter in scalable video coding
WO2008140190A1 (en) * 2007-05-14 2008-11-20 Samsung Electronics Co, . Ltd. Method and apparatus for encoding and decoding multi-view image
KR20120003794A (ko) * 2009-03-30 2012-01-11 파나소닉 주식회사 기록매체, 재생장치 및 집적회로
JP4993224B2 (ja) * 2009-04-08 2012-08-08 ソニー株式会社 再生装置および再生方法
US8290338B2 (en) * 2009-05-27 2012-10-16 Panasonic Corporation Recording medium, playback device, encoding device, integrated circuit, and playback output device

Patent Citations (6)

* 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 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2002027413A (ja) * 2000-07-07 2002-01-25 Sanyo Electric Co Ltd デジタルビデオ再生装置
JP2005348314A (ja) 2004-06-07 2005-12-15 Sony Corp データ記録装置、方法およびプログラム、データ再生装置、方法およびプログラム、ならびに、記録媒体
WO2007010779A1 (ja) * 2005-07-15 2007-01-25 Matsushita Electric Industrial Co., Ltd. パケット送信装置
JP2008252740A (ja) 2007-03-30 2008-10-16 Sony Corp リモートコマンダおよびコマンド発生方法、再生装置および再生方法、プログラム、並びに、記録媒体
WO2009090868A1 (ja) * 2008-01-17 2009-07-23 Panasonic Corporation ３ｄ映像が記録された記録媒体、３ｄ映像を記録する記録装置、並びに３ｄ映像を再生する再生装置及び再生方法

Non-Patent Citations (1)

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

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11457140B2 (en) 2019-03-27 2022-09-27 On Time Staffing Inc. Automatic camera angle switching in response to low noise audio to create combined audiovisual file
US10963841B2 (en) 2019-03-27 2021-03-30 On Time Staffing Inc. Employment candidate empathy scoring system
US11961044B2 (en) 2019-03-27 2024-04-16 On Time Staffing, Inc. Behavioral data analysis and scoring system
US10728443B1 (en) 2019-03-27 2020-07-28 On Time Staffing Inc. Automatic camera angle switching to create combined audiovisual file
US11863858B2 (en) 2019-03-27 2024-01-02 On Time Staffing Inc. Automatic camera angle switching in response to low noise audio to create combined audiovisual file
CN111953984A (zh) * 2019-05-16 2020-11-17 佳能株式会社 摄像装置及其控制方法和非易失性计算机可读存储介质
US11127232B2 (en) 2019-11-26 2021-09-21 On Time Staffing Inc. Multi-camera, multi-sensor panel data extraction system and method
US11783645B2 (en) 2019-11-26 2023-10-10 On Time Staffing Inc. Multi-camera, multi-sensor panel data extraction system and method
US11184578B2 (en) 2020-04-02 2021-11-23 On Time Staffing, Inc. Audio and video recording and streaming in a three-computer booth
US11636678B2 (en) 2020-04-02 2023-04-25 On Time Staffing Inc. Audio and video recording and streaming in a three-computer booth
US11861904B2 (en) 2020-04-02 2024-01-02 On Time Staffing, Inc. Automatic versioning of video presentations
US11023735B1 (en) 2020-04-02 2021-06-01 On Time Staffing, Inc. Automatic versioning of video presentations
US11720859B2 (en) 2020-09-18 2023-08-08 On Time Staffing Inc. Systems and methods for evaluating actions over a computer network and establishing live network connections
US11144882B1 (en) 2020-09-18 2021-10-12 On Time Staffing Inc. Systems and methods for evaluating actions over a computer network and establishing live network connections
US11727040B2 (en) 2021-08-06 2023-08-15 On Time Staffing, Inc. Monitoring third-party forum contributions to improve searching through time-to-live data assignments
US11966429B2 (en) 2021-08-06 2024-04-23 On Time Staffing Inc. Monitoring third-party forum contributions to improve searching through time-to-live data assignments
US11423071B1 (en) 2021-08-31 2022-08-23 On Time Staffing, Inc. Candidate data ranking method using previously selected candidate data
US11907652B2 (en) 2022-06-02 2024-02-20 On Time Staffing, Inc. User interface and systems for document creation
US12321694B2 (en) 2022-06-02 2025-06-03 On Time Staffing Inc. User interface and systems for document creation

Also Published As

Publication number Publication date
TWI428016B (zh) 2014-02-21
US20120087641A1 (en) 2012-04-12
JP4993224B2 (ja) 2012-08-08
US8792780B2 (en) 2014-07-29
TW201119388A (en) 2011-06-01
CN103079082B (zh) 2016-02-10
CN102047674B (zh) 2016-01-20
JP2010245969A (ja) 2010-10-28
EP2285130A4 (en) 2013-07-03
CN102047674A (zh) 2011-05-04
HK1157546A1 (zh) 2012-06-29
EP2285130A1 (en) 2011-02-16
CN103079082A (zh) 2013-05-01
CN103079081B (zh) 2015-12-02
CN103079081A (zh) 2013-05-01

Similar Documents

Publication Publication Date Title
JP4993224B2 (ja) 再生装置および再生方法
JP5267886B2 (ja) 再生装置、記録媒体、および情報処理方法
JP4957823B2 (ja) 再生装置および再生方法
WO2010116997A1 (ja) 情報処理装置、情報処理方法、再生装置、再生方法、および記録媒体
JP4962525B2 (ja) 再生装置、再生方法、およびプログラム
JP2010245970A (ja) 再生装置、再生方法、およびプログラム
JP4984184B2 (ja) 再生装置および再生方法
JP4984192B2 (ja) 記録方法
JP4993233B2 (ja) 記録方法
JP4984193B2 (ja) 再生装置、再生方法、および記録方法
JP4993234B2 (ja) 再生装置、再生方法、および記録方法
JP4985884B2 (ja) 再生装置、再生方法、および記録方法
JP4993044B2 (ja) 再生装置、再生方法、および記録方法
JP4984194B2 (ja) 記録方法
HK1157546B (en) Recording device, recording method, reproduction device, reproduction method, program, and recording medium

Legal Events

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

Ref document number: 201080001745.X

Country of ref document: CN

REEP Request for entry into the european phase

Ref document number: 2010761697

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2010761697

Country of ref document: EP

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

Ref document number: 10761697

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12995639

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE