TW201105108A - Playback device, playback method, and program - Google Patents

Abstract

The present invention, for instance in the case of displaying 3D images, can determine which stream from the basic stream or the expansion stream is the stream of left image and then play the 3D content. In the case of the value of view_type equal to 0, those data stored in the DPB (151) and subjected to decoding with base view video packet that has been identified by PID=0 are outputted to L video plane production part (161). The value of view_type equal to 0 implies that the base view video stream is an L view stream. Under this circumstance, the data decoded with dependent view video packet that has been identified by PID with values other than 0 are outputted to R video plane production part (162). This invention can be applied to playback device supporting BD-ROM specification.

Description

201105108 VI. Description of the Invention: [Technical Field] The present invention relates to a playback device, a playback method, and a program, and the present invention relates to, for example, a case where a 3D image is displayed, and the basic stream can be judged. Which of the extended streams is a stream of left images, a playback device, a playback method, and a program for playing 3D content. [Prior Art] As the content of a movie or the like, the content of a two-dimensional image is mainly used, and the content of a stereoscopic image that can realize stereoscopic vision has recently attracted attention. The display of the stereoscopic image requires a dedicated device, and as such a stereoscopic device, there is, for example, an IP (Integral Photography) stereoscopic image system developed by NHK (Nipp〇n Hoso Kyokai, Japan Broadcasting Association). The image data of the stereoscopic image includes a plurality of image data of a plurality of angles of view (image data of images taken from a plurality of angles of view), and the more the number of angles of view and the wider the range of the angle of view, the more various The so-called "all-image TV" of the subject is observed in the direction. The number of views in the stereoscopic image is the smallest. The number of views is a stereoscopic image of 2 k-angles (so-called 3D image). The image data package of the stereoscopic image, including the image observed by the left eye, that is, the left image data, and the image observed by the right eye, that is, the right image data. On the other hand, the content of a high-resolution image such as a movie has a large amount of data. Therefore, recording a large amount of data requires a large-capacity recording medium. M5441.doc 201105108 As such a large-capacity recording medium, there are Blu-Ray (registered BD (Blu-Ray), _R〇M (Read Only Memory) Trademark) Disc (hereinafter also referred to as BD). [Prior Art Document] [Patent Document 1] Japanese Patent Laid-Open Publication No. 2005-348314 [Draft] [Problems to be Solved by the Invention] However, there is no provision in the specification of BD. The image data of the stereoscopic image including the stereoscopic image is recorded in the BD, and the manner in which the playback is performed is not specified. For example, the map of the stereogram includes two data streams of the stream stream of the left image I and the data stream of the right image. Therefore, it is necessary to define a decoder module capable of releasing the two data streams ’ and displaying a stereoscopic image, and installing a decoder based on this model in the playback device. The present invention is completed in the above situation, for example, in the case of displaying an image, it can be determined which of the basic stream and the extended stream - the stream is a stream of the left image - thereby playing 3 d content . [Technical means for solving the problem] The playback apparatus of the present invention includes: an acquisition mechanism that acquires a basic stream disk extended stream obtained by encoding a plurality of image data in a specific encoding manner; and a decoding mechanism The basic stream obtained by the obtaining means and the extended stream are decoded; and (4) means, based on which of the basic stream and the extended stream, the left image is 145441.doc 201105108 The stream or the stream of the right image is switched to the output destination of the poor result of the decoding result generated by the decoding mechanism. The playback device of the present invention can further provide a second generation means for generating a plane of the left image and a second generation means for generating a plane of the right image. In this case, the switching means may output the data of the decoding result of the stream represented by the flag to the left image stream in the basic stream and the extended stream to the first generating means. And outputting the data of the decoding result of another stream to the second generation means. The switching means may be configured to identify, based on the pID, whether the data decoded by the decoding means is the data of the decoding result of the basic stream or the decoding result of the extended stream. The switching mechanism may be configured to identify, according to the identification information of the viewing angle set in the extended stream during encoding, whether the data decoded by the decoding mechanism is the data of the decoding result of the basic stream or the decoding result of the extended stream. data. The switching means can identify the data of the decoding result of the extended stream based on the set identification information of the viewing angle, and identify the data of the decoding result of the stream in which the identification information of the viewing angle is not set as the basic stream. The data of the decoding result. And causing the acquiring means to read the basic stream and the extended stream while reading from the mounted recording medium, and reading out the flag from the recording medium and controlling the basic stream and the above Expanding the playback control information of the streaming play, and causing the switching mechanism to switch the decoding mechanism based on the flag of the playback control information 145441.doc 201105108 read by the obtaining means from the recording medium The output destination of the data that is decoded and selected. And causing the obtaining means to acquire additional information added to any one of the basic stream and the expansion to describe the flag, and y to cause the switching means to be based on the acquisition by the acquiring means The above-described flag described in the force λ switches the output destination of the data of the decoding result generated by the decoding unit. The obtaining means may obtain the flag added to at least one of the basic stream and the extended stream that are broadcasted, and describe the flag: the basic unit that can receive and obtain the transmission by the acquiring means And transmitting, by the stream, the transmission control information for receiving the (four) flag and for controlling the transmission of the basic 'stream and the expanded stream, the switching mechanism may be based on the material control information received by the obtaining mechanism : The above-mentioned flag is used to switch the output destination of the decoding result generated by the decoding unit. The obtaining means may receive and acquire the basic stream and the extended stream transmitted via radio waves, and receive a transfer control tribute describing the flag and controlling the transmission of the basic stream and the extended stream. .乂 明 明 明 态 态 态 态 态 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放 播放'And based on the output destination indicating which of the above-mentioned basic stream and the above-mentioned extended stream is $145441.doc 201105108 w is the stream of the left image or the result. The string-to-flag, switch-coded version=the program is such that the computer executes the base string 2 and the =-stream stream obtained by encoding the complex (4) image data in the following steps: The basic stream and the extended decoding are based on a flag indicating whether the stream is streamed as a left stream or a stream of a right image in the extended stream, and the output of the data of the decoding result is switched. destination. In the aspect t of the present invention, a basic stream and an extended stream obtained by encoding a plurality of image data by a mosquito encoding method are obtained, and the obtained basic stream and the extended stream are decoded 'based on the representation Which one of the above-mentioned basic stream and the above-mentioned extended stream is a stream of a left image or a stream of a right image, and switches the output destination of the data of the decoding result. [Effects of the Invention] According to the present invention, it is possible to judge which of the basic stream and the extended stream is a stream of the left image, for example, in the case of displaying a 3D image, thereby playing the 3D content. [Embodiment] <First Embodiment> [Configuration Example of Playback System] Fig. 1 is a view showing an example of a configuration of a playback system to which a playback device of the present invention is applied. As shown in Figure 1, the '忒 playback system is constructed by HDMI (High 145441.doc 201105108)

A playback device 丨 and a display device 3 are connected to a transmission line or the like of a Defm丨tion Multimedia Interface. The playback device is equipped with a disc 2 such as a BD. In the optical disc 2, a stream necessary for displaying a stereoscopic image having two viewing angles (so-called 3D image) is recorded. The playback device 1 is a player that supports streaming 3D playback recorded on the optical disc 2. The playback device 1 plays the stream recorded on the optical disc 2, and displays the 3D image obtained by the playback in the display device 3 including the television receiver or the like. The sound is also played by the playback device ,, and is output from a speaker or the like provided in the display device 3. As a display method of a 3D image, various methods have been proposed. Here, as the display mode of the 3D image, the following display modes of the type si and the display mode of the type 2 are employed. The type 1 display mode is as follows: the data of the image (L image) observed by the left eye and the image of the image of the right eye (R image) constitute the data of the 3D image. And the L image and the R image are alternately displayed, thereby displaying the 3D image. The display mode of the type 2 is a method of displaying a 3-inch image by displaying an L image and an R image generated using data of a source image which is a source of a 3D image and a material of Depth (depth). . The data of the 3D image used in the display mode of the type 2 includes the data of the source image and the material of the Depth which can generate the L image and the R image by supplying the source image. Type 1 is displayed in such a way that it is required to display the glasses when viewing. The display mode of type 2 is to display the display mode of 3D images without glasses. 145441.doc 201105108 In Disc 2, a stream of 3D images can be displayed regardless of any of Types 1 and 2. As the encoding method for recording such a stream on the optical disc 2, for example, H.264 AVC (Advanced Video Coding)/MVC (Multi-view Video Coding) setting standard can be employed. [H.264 AVC/MVC Profile] In the H.264 AVC/MVC profile standard, an image stream called Base view video is defined, and it is called Dependent view video. The image stream. The H.264 AVC/MVC profile standard is appropriately referred to as MVC as appropriate. Fig. 2 is a view showing an example of photographing. As shown in Fig. 2, the same subject is used for imaging by the camera for the L image and the camera for the R image. The basic stream of the image captured by the camera for the L image and the camera for the R image is input to the MVC encoder. Fig. 3 is a block diagram showing a configuration example of an MVC encoder. As shown in Fig. 3, 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 camera for the L image is input to the H.264/AVC encoder 21 and the Depth calculating unit 23. Further, the stream of video #2 captured by the camera for the R image is input to the Depth calculation unit 23 and the Dependent view video encoder 24. The stream of image #2 can also be input to 145441.doc 201105108 to H.264/AVC encoder 21 and Depth calculation unit 23, and the stream of image #1 can also be input to Depth calculation unit 2: 3 and Dependent view video coding The 24° H.264/AVC encoder 21 encodes the stream of video images into, for example, a 264 AVC/High Pr file video stream. The H 264/AVC encoder outputs the encoded AVC video stream as a Base view stream to the H.264/AVC decoder 22 and the multiplexer 25. The H.264/AVC decoder 22 decodes the AVC video stream supplied from the H.264/AVC encoder 21, and outputs the decoded video #1 stream to the Dependent view video encoder 24.

The Depth calculating unit 23 calculates Depth' based on the stream of the video #丨 and the stream of the video #2, and outputs the calculated data of the Depth to the multiplexer.

The Dependent view video encoder 24 outputs the Dependent view video stream after the stream of the image #1 supplied from the H 264/AVC decoder 22 and the stream input from the external image.

The prediction encoding process of using other streams as reference pictures is not allowed in the Base view video, but as shown in Fig. 4, Dependent Wew vide〇 allows prediction encoding processing using Base View video as a reference picture. For example, when the L image is used as the Base view vide and the R image is encoded as the Dependent view video, the amount of data of the resulting Dependent view Vide0 stream will become less than the amount of data of the Base video stream. Furthermore, since encoding is performed using H.264/AVC, it is necessary to predict the time direction of the Base view video. Also, as far as Dependent yiew 14544 丨.doc -10- 201105108 video is concerned, the prediction of the time direction is also carried out simultaneously with the prediction between Views. If you want to decode the Dependent view video, you must use the Dependent view video encoding as the reference object. The decoding of the WeW vide〇 has ended.

The Dependent view video encoder 24 outputs the Dependent View video stream which is also encoded using the prediction between such views to the multiplexer 25. The multiplexer 25 supplies the Base view video stream supplied from the H.264/AVC encoder 21, the Dependent view vide stream supplied from the Depth calculating unit 23 (data of Depth), and is supplied by the Dependent view vide encoder. The Dependent view video stream multiplexing processing is, for example, MpEG2 TS (Motion Picture Experts Group 2 Transport Stream). There is both a Base view video stream and

The Dependent view video stream multiplex processing is 1 MPEG2 TS 幵 > 'There is also the case where the streams are included in different VIPEG2 TSs. The multiplexer 25 outputs the generated TS (MPEG2 TS). The TS outputted from the multiplexer 25 is recorded in the optical disc 2 together with other management data and supplied to the playback apparatus 1 in the form recorded in the optical disc 2. When it is necessary to distinguish between the display mode of type 1 and the Base view video—and the Dependent view video used, and the display mode of type 2 and Base view video—and use the Dependent view video (Depth), the former is called D1 view video, the latter is called D2 view video ° and 'U5441.doc will be used with Base view video and D1 view video. The 3〇 play in the display mode of 201105108 type 1 is called _play. The 3D playback in the type 2 display mode performed by the ffiBase view video and the D2 view video is referred to as B-D2 playback. The playback device 1 reads the Base view video stream and the D1 view vide stream from the disc 2 for playback when B_D1 playback is performed according to the user's instruction. Further, when the playback device 1 performs B-D2 playback, the Base view video stream and the D2 view video stream are read from the optical disc 2 for playback. Further, when the playback device 1 is playing a normal 2D image, only the Base view video stream is read from the optical disk 2 and played. Since the Base view video stream is an AVC video stream encoded by H.264/AVC, the player supporting the BD format can stream the Base view video and display a 2D image. The following 'mainly describes the situation where the Dependent view video is D1 view video. When it is called Dependent view video only, it means D1 view video. The D2 view video is also recorded on the disc 2 in the same way as the D1 view video, and can be played back. [Configuration Example of TS] FIG. 5 is a view showing a configuration example of TS. In the Main TS (Main Transport Stream) of Figure 5, Base view video, Dependent view video, Primary audio, Base PG (Base Presentation Graphic), Dependent PG (Dependent Presentation Graphic) , according to the expression), Base IG (Base Interactive 145441.doc 12 201105108

The respective streams of Graphic ’ Basic Interactive Graphics and Dependent IG (Dependent Interactive Graphic) are multiplexed. Thus, there is also a case where the Dependent view video stream is included in the Main TS together with the Base view video stream. Main TS and Sub TS (Sub Transport Stream) are recorded on the disc 2. The Main TS system contains at least the TS of the Base view video stream. Sub TS is a TS that contains streams other than the Base view video stream and is used with the Main TS. The following PG and IG are also prepared to have a stream of the Base view and the Dependent view so that 3D display can be performed in the same manner as the video. The plane of the PG and IG B a s e v i e w obtained by decoding each stream is compared with the plane synthesis of the Base view video obtained by decoding the Base view video stream. Similarly, the plane of the Dependent view of PG and IG is combined with the plane of the Dependent view video obtained by stream decoding the Dependent view video. For example, when the Base view video stream is a stream of l images, and the Dependent view video stream is a stream of R images, in the PG and IG, the stream of the Base view also becomes a graph of the image of 1 image. Streaming. also,

The PG stream of the Dependent view and the IG stream become the stream of the image of the ruler image. On the other hand, when the Base view video stream is a stream of R images and the Dependent view video stream is a stream of L images, in the PG and IG, the stream of the Base view also becomes the graph of the R image. Streaming. In addition, the PG stream of the Dependent view and the stream of the stream become a string of L images. 145441.doc 13 201105108 Stream. Fig. 6 is a view showing another configuration example of the TS. In the Main TS of Figure 6, the respective streams of the Base view video and the Dependent view video are multiplexed. On the other hand, in Sub TS, the respective streams of Primary audio, Base PG, Dependent PG, Base IG, and Dependent IG are multiplexed. There is also a case where the video stream is multiplexed into the Main TS in this manner, and the multiplex processing such as PG and IG is processed into the Sub TS. Fig. 7 is a view showing still another example of the configuration of the TS. In the Main TS of FIG. 7A, the respective streams of Base view video, Primary audio, Base PG, Dependent PG, Base IG, and Dependent IG are multiplexed. On the other hand, the Dependent view video stream is included in the Sub TS. As such, the Dependent view video stream and the Base view video stream are sometimes included in different TSs. In the Main TS of FIG. 7B, the respective streams of Base view video, Primary audio, PG, and IG are multiplexed. On the other hand, in Sub TS, the respective streams of Dependent view video, Base PG, Dependent PG, Base IG, and Dependent IG are multiplexed.

The PG 'IG included in Main TS is a stream for 2D playback. The stream contained in the Sub TS is a stream for 3D playback. In this way, the stream of PG and the stream of IG can not be shared in 2D playback and 3D playback. 145441.doc • 14· 201105108 So, Base view video Streaming and Dependent view video Streaming is sometimes included in different MPEG2 TSs. Base view video

The advantages of streaming and Dependent view video streaming in different MPEG2 TS recordings are illustrated. For example, it is assumed that the bit rate of multiplex processing into one MP]EG2 TS is limited. In this case, when both the Base view video stream and the Dependent view video stream are included in the HgIMPEG2 TS, it is necessary to lower the bit rate of each stream in order to satisfy the constraint. As a result, the picture quality is degraded. Since it is included in each MPEG2 TS, there is no need to lower the bit rate without degrading the picture quality. [Application Format] Fig. 8 is a diagram showing an example of management of the streamer of the singularity of the singularity of the singularity of the video device. As shown in FIG. 8, the management of the AV stream is performed using two layers of piayList (playlist) and Clip (segment). The AV stream is recorded not only in the disc 2 but also in the local storage of the playback device. Here, 'one AV stream and C (four) onation (segment information) as information accompanying the AV stream are viewed as objects, and these objects are collectively referred to as Clips, and AV streams are stored. The file is called an AV streaming file. In addition, the broadcast file containing Clip Inf〇rmati〇n is also called the Information File. AV string capture system /. The timeline is expanded, and each access point is specified primarily in the timestamp in PlayLm. The CUp inf〇rmati〇n file is used to search 145441.doc 15 201105108 Find the address where the A V stream should start decoding.

PlayList is a collection of playback intervals of AV streams. The playback interval in the Av stream is called Playltem. PlayItenW^ is represented by the pair of IN (in) and 〇 UT (out) points in the playback interval on the time axis. As shown in Fig. 8, the PlayList includes one or a plurality of PlayItems. The HiIP丨ayList from the left side of Fig. 8 includes, and with the two PlayItems, the first half and the second half of the eight-way stream contained in the Clip on the left side are respectively referred to. The second PlayList includes one PlayItem from the left, and the entire PlayItem is referred to by referring to the entire AV stream included in the Clip on the right side. The third PlayList includes two PlayItems from the left side, and the two PlayItems are used to refer to a part of the AV stream included in the Clip on the left side and a part of the AV stream included in the Clip on the right side. For example, when the PlayItem on the left side included in the first PlayList from the left is designated as the playback target by the disc navigation index program, the first half of the AV stream included in the left Clip referred to by the PlayItem is played. As such, the PlayList will be used as playback management information for managing the playback of the AV stream. In the PlayList, a playback path formed by the arrangement of one or more PlayItems is referred to as a main path. Further, in the PlayList, a play path formed in parallel with the Main Path and arranged by one or more SubPlayltems is referred to as a Sub Path. Figure 9 is a diagram showing the structure of Main Path and Sub Path. 145441.doc •16- 201105108

The PlayList can have one Main Path and more than one Sub Path. The Base view video stream is managed as a stream referenced by the Playltem constituting the Main Path. Further, the Dependent view video stream is managed as a stream referred to by SubPlayltem constituting Sub Path. The PlayList of FIG. 9 has one Main Path and three Sub Paths formed by the arrangement of three Playltems. In the Playltem constituting the Main Path, an ID (Identification) is set in order from the front to the back. Also in Sub Path, the IDs of Subpath_id=0, Subpath_id=l, and Subpath_id=2 are sequentially set from front to back. In the example of FIG. 9, one Sub Path included in Subpath-id=0

SubPlayltem contains 2 SubPlayltems in Sub Path with subpath_id=l. Also, there is one SubPlayltem in the Sub Path of Subpath_id=2. The Clip AV stream referenced by one Playltem includes at least a video stream (main image data). Further, the 'in the Clip AV stream' may include one or more audio streams that are played at the same timing (synchronous) as the video stream included in the Clip AV stream, or may not include the audio stream. In the Clip AV stream, the stream of the subtitle data (pG (Presentation Graphic) of one dot map that is played in synchronization with the video stream included in the clip AV stream may not contain the same. Streaming. In the Chp AV stream, it may contain one or more streams of IG (Interactive Graphic) synchronized with the video stream included in the AV stream file 145441.doc -17-201105108, or may not contain the stream. Streaming. The IG stream is used to display a graphic such as a button operated by a user. In a Clip AV stream referenced by one Playltem, a video stream, zero or more audio streams that are played synchronously with the video stream, zero or more PG streams, and zero or more IG streams It is processed by multiplex. Further, one SubPlayltem refers to a video stream, an audio stream, or a PG stream which is different from the stream (other stream) of the Clip AV stream referred to by Playltem. The management of the AV stream using such PlayList, Playltem, and SubPlayltem is described in Japanese Laid-Open Patent Publication No. 2008-252740, and Japanese Patent Laid-Open No. Hei No. 2005-3483. [Directory Structure] Fig. 10 is a diagram showing an example of a management structure of files recorded on the optical disc 2. As shown in Figure 10, the file is hierarchically managed by a directory structure. Create a root directory on CD 2. Below the root directory is the range managed by a recording playback system. Set the BDMV directory under the root directory. Directly below the BDMV directory, the file named "Index.bdmv" is the index file, and the MovieObject file with the name of "MovieObject.bdmv" is stored. Under the BDMV directory, a BACKUP directory, a PLAYLIST directory, a CLIPINF directory, a STREAM directory, and the like are provided. 145441.doc -18· 201105108 In the PLAYLIST directory, there is a description of the piayList2PlayList file. In each PlayList file, a name in which a 5-digit number and an extension ".mpls" are combined is set. The audit name of "OOOOO.mpls" is set in one PlayList file shown in FIG. The clip informati〇n file is stored in the CLIPINF directory. In each Clip Information file, a name with a combination of 5 digits and the extension ".clpi" is set. In the three Clip lnformati〇n standards in Figure 10, file names of "〇〇〇01_clpi", "〇〇〇〇2.clpi", and r 00003 clpi are set. Hereinafter, the Clip Informati〇n file is appropriately referred to as a clpi file. For example, the "OOOUpi" clpi file is a file that describes the information about the Clip of Base view video. The clpi slot of 00002.clpi is a slot that describes the related resources of the Clip of D2 view video. The clpi slot of 〇〇〇03.clpi is a standard for describing the relevant §fl of the di view video Clip. In the STREAM directory, a streaming file is stored. In each stream file, a name in which a 5-digit number is combined with the extension "m2ts" or a combination of a 5-digit number and an extension "iivt" is set. Hereinafter, the file whose extension ", m2ts" is set is appropriately referred to as a claw file. Also, the file with the extension ".ilvtj" is called the ilvt file. The m2ts file of "〇〇〇〇l_m2ts" is the file for playback, and the Base view video stream is read by specifying the file. Out. The m2ts file of "00002.m2ts" is the file of D2 view video stream 145441.doc -19- 201105108 case "The m2ts file of "00003.m2tSj" is the Dlviewvideo streaming file. The iWt file of "10000_ilvt" is The file for B-D1 playback, and the Base view video stream and the D1 view video stream are read by specifying the right. The ilvt standard of "20000.ilvt" is a file for B-D2 playback, and the Base view video stream and the D2 view video stream are read by specifying the file. In addition to the one shown in Fig. 10, under the BDMV directory, a directory for storing audio stream files is also provided. [Syntax of Each Data] FIG. 11 is a diagram showing the syntax of a PlayList file.

The PlayList file is stored in the PLAYLIST directory of Figure 1 and is filed with the extension ".mpls". The type "ndicator of Fig. 11" indicates the file type of "xxxxx.mpls". The version number is the version number indicating "xxxx.mpls". Version—number contains 4 digits. For example, in the PlayList file for 3D playback, "0240" indicating "3D Spec version" is set.

PlayList_start_address indicates the PlayList() leading address in units of the relative number of bytes from the leading tuple of the PlayList file.

The PlayListMark_start_address is expressed in units of relative bytes from the leading group of the PlayList file, and indicates the I4544I.doc -20· 201105108 leading address before the PlayListMark.

ExtensionData_start_address indicates the leading address of ExtensionData() in units of relative bytes from the leading group of the PlayList file. After ExtensionData_start_address, contains 160 bits (bits) of reserved_for_future_use. In the AppInfoPlayList(), parameters related to the playback control of the piayList, such as a playback restriction, are stored. In PlayList, parameters related to Main Path or Sub Path are stored. The contents of PlayList() will be described below. In the PlayListMark, the tag information of the piayList is stored, that is, the information related to the mark as the jump destination (jump point) in the user operation or command such as the chapter jump. Private assets can be inserted in ExtensionData(). Fig. 12 is a view showing a specific example of the description of the PlayList file. As shown in Fig. 12, a 2D (bit) 3D_PL_type and a 1 bit (bit) view_type are described in the PlayList file. The view_type is described, for example, in AppInfoPlayList() of Fig. 11. 3D_PL_type indicates the kind of PlayList. The view-type indicates whether the Base view video stream played by the PlayList is streamed as an L-picture stream or an R-picture stream. Fig. 13 is a view showing the meaning of the value of 3D_PL_type. The value 00 of the 3D_PL_type indicates that it is a PlayList for 2D playback. I45441.doc 201105108 The value of 01_D_PL_type of 01 indicates that it is a PlayList for B-D1 playback in 3D playback. The value 1 of the 3D_PL_type indicates that it is a PlayList for B-D2 playback in 3D playback. For example, when the value of 3D_PL_type is 01 or 1 3, 3DPlayList information is registered in ExtenstionData() of the PlayList file. For example, the login and Base view video stream and Dependent view video stream read related information from the disc 2 as 3DPlayList information. Figure I4 is a diagram showing the meaning of the value of view_type. The value of view_type is 0. When the 3D playback is performed, the Base view video stream is a stream of L view. In the case of 2D playback, the Base view video stream is represented as an AVC video stream. The value 1 of the view_type indicates that the Base view video stream is a stream of R view. Since the view_type is described in the PlayList file, the playback device 1 can recognize whether the Base view video stream is a stream of L view or a stream of R view. For example, when the video signal is output to the display device 3 via the HDMI transmission line, the playback device 1 is required to distinguish the signal of the L view from the signal of the R view and output the signal. Since the Base view video stream can be identified as a stream of L view or a stream of R view, the playback device 1 can distinguish the signal of the L view from the signal of the R view and output it. Fig. 15 is a view showing the syntax of PlayList() of Fig. 11. 14544 丨.doc •22· 201105108 length is a 32-bit unsigned integer representing the number of bytes from the end of the length of the PlayList(). That is, length represents the number of bytes from the reserved_for_future_use to the end of the PlayList. Prepare 1 6-bit reserved_for_future_use after length. number_of_PlayItems is a 16-bit block that represents the number of Playltems in the PlayList. In the case of the example of Fig. 9, the number of Playltem is 3. The value of Playltem_id is assigned starting from 0 in the order indicated by Playltem() in the PlayList. For example, PlayItem_id = 0, 1, 2 of Fig. 9 is assigned. number_of__SubPaths is a 16-bit field representing the number of Sub Paths in the PlayList. In the case of the example of Fig. 9, the number of Sub Paths is three. The value of SubPath"d is allocated from 0 in the order indicated by SubPath() in the PlayList. For example, Subpath_id = 0, 1, 2 of Fig. 9 is assigned. The following for statement refers to PlayItem() only with the number of Playltem, and only refers to SubPath() with the number of Sub Paths. Fig. 16 is a diagram showing the syntax of SubPath () of Fig. 15. Length is a 32-bit unsigned integer representing the number of bytes from the length of the length of the Sub Path(). That is, length represents the number of bytes from the reserved_for_future_use to the end of the PlayList. After length, prepare a 16-bit reserved_for_future_use.

SubPath_type is an 8-bit block indicating the application type of Sub Path. SubPath_type is used, for example, to indicate that Sub Path is audio, or to point to 145441.doc -23- 201105108, or to subtitles such as text subtitles. After SubPath_type 'prepared for 15 bits reserved for futureuse ° is_repeat_SubPath is a 1-bit field that specifies the playback method of Sub Path, which indicates whether the sub path will be played repeatedly in the playback interval of Main Path, or only once. Sub Path playback "For example, when the Clip referenced by Main Path is different from the playback timing of the Clip referenced by Sub Path (the Main Path is used as the path of the slide show of the still image, and Sub Path is used as the Sub Path. As the path of the audio of BGM (Background Music), etc.). After Is_repeat_SubPath 'Prepare 8 bits reserved_for_future_use 〇 number_of_SubPlayItems is an 8-bit field that represents the number of SubPlayltems (number of logins) in 1 Sub Path. For example, the Sub___PlayItems of SubPlayltem of SubPath-id=0 in Figure 9 is 1, and the number_of_SubPlayItems of SubPlayltem of SubPath_id=l is 2. The following for statement refers to SubPlayItem() only for the number of SubPlayltems. Fig. 17 is a diagram showing the syntax of SubPlayltem(i) of Fig. 16. Length is an unsigned integer of 16 bits from the length field to the last byte of Sub playltem(). The SubPlayltem(i) of Fig. 17 is divided into the case where SubPlayltem refers to one Clip and the case where a plurality of Clips are referred to. The case where SubPlayltem refers to one Clip will be described. 145441.doc • 24- 201105108

Clip_lnformation_file_name[0] represents the clip referenced.

Clip_codec"dentifier[0] is the codec mode of the Clip. Included after Clip_codec_identifier[0] is reserved_for_future—use ° is a multi-Clip-entries indicates whether there is a multi_Clip (multi-segment) login flag. When the flag of is_multi_Clip_entries is established, refer to the syntax when SubPlayltem refers to a plurality of Clips. ref_to_STC"d[0] is information related to the STC (System Time Clock) discontinuity point (the discontinuity of the system time base).

SubPlayltem-IN-time indicates the start position of the Play Path of Sub Path, and SubPlayItem_OUT_time indicates the end position. sync—Playltem”d and sync_start—PTS_of_PlayItem is the time at which the Sub Path starts playing on the timeline of the Main Path.

SubPlayItem_IN_time, SubPlayltemOUTtime, sync_PlayItem"d, sync_start_PTS_of-Playltem are shared by the Clip referenced by SubPlayltem. The case of "if(is_multi_Clip_entries==lb", and SubPlayltem refers to a plurality of Clips. num_of_Clip_entries is the number of Clips that refer to the reference. The number of Clip_Information_file_name[SubClip_entry_id] is specified in addition to Clip_Information. —The number of clips other than file_name[0].

Clip_codec_identifier[SubClip_entry_id] indicates the encoding and decoding method of the Clip. ref_to_STC_"d[SubClip_entry_id] is information related to the STC non-contiguous point (which is a discontinuous point of the I45441.doc -25-201105108 time base). After ref_t〇_STC_ id[SubClip_entry"d], reserved_f〇r_future_use is included. FIG. 18 is a diagram showing the syntax of piayitern() of FIG. Length is an unsigned integer of 16 bits from the length field to the end of Piay [the last byte of the tem〇.

Chp—Information—file_name[0] is the name of the Clip Information file of the Clip referenced by piayItemK. Furthermore, the same five-digit number is included in the name of the file name of the file containing the (3) 仏 卩 档案 file and the Clip lnformati〇n file corresponding thereto.

Clip_codec_identiHer[0] is the codec mode of the clip. After Clip_codec"dentifier[0], contains reserved-f〇r-future-use. After reserved_for_future_use, includes is multi angle, connection_condition ° ref_to_STC"d[0] is the information related to the STC non-contiguous point (non-contiguous point of the system time reference). The IN-time indicates the start position of the Playltem playback interval, and the OUT_time indicates the end position. After the OUT time, UO_mask_table(), playItem_random_access_mode, and still_mode are included in the STN-table() information of the AV stream referenced by the object PlayIten^. Further, the information of the AV stream constituting the SubPlayltem of the Sub path is also included when there is a Sub Path for playing the correlation with the Playltern of the object. 145441.doc •26· 201105108 FIG. 19 is a diagram showing the syntax of STN_table( ) of FIG. 18. STN_table() is set with the properties of Playltem. Length is an unsigned integer of 16 bits representing the number of bytes from the end of the length block to the end of STN_table. After length, prepare 16-bit reserved_for_future_use. The number of video stream entries indicates the number of streams in the STN_table() that are ____entry and provide video_stream_id. Video_stream_id is information used to identify video streams. For example, the Base view video stream is determined by the video_stream_id. The ID of the Dependent view video stream can be defined in STN_table() or by adding a specific value to the ID of the Base view video stream. Video_stream_number is the video stream number that is used for video switching and visible to the user. Number_of_audio_stream_entries is the number of streams representing the first audio stream registered in STN_table() and providing audio_stream"d. Audio_stream"d is used to identify the information of the audio stream, and audio_stream_number is used for the sound switching and the user can see the audio stream number. Number_of_audio_stream2_entries is the number of streams representing the second audio stream registered in STN_table() and providing audio_stream"d2. Audio_stream_id2 is used to identify the information of the audio stream, and audio_stream_number is the audio stream number that is used for sound switching and visible to the user. In this example, the sound played can be switched. 145441.doc -27- 201105108 number_of_PG—txtST_stream_entries is the number of streams that are registered in STN_table() and that provide PG_txtST_stream_id. Among them, the PG stream and the text subtitle file (txtST) of the run-length encoding of the dot matrix subtitle are registered. PG_txtST_stream_id is used to identify the information of the subtitle stream, and PG_txtST_stream_number is used for subtitle switching and the subtitle stream number visible to the user. number_of_IG_stream_entries is the number of streams that are registered in STN_t.able() and that provide IG_stream_id. Among them, there is an IG stream registered. IG_stream_id is used to identify the information of the IG stream, and IG_stream_number is used to switch the graphics stream and the user can see the stream number.

The ID of Main TS and Sub TS is also registered in STN "able(). The stream_ attribute() describes that the above ID is not the basic stream but the content of the ID of the TS. [Configuration Example of Playback Device 1] FIG. 20 is a block diagram showing a configuration example of the playback device 1. The controller 51 executes a control program prepared in advance to control the overall operation of the playback device 1. For example, the controller 51 controls the disk drive 52 to read the PlayList file for 3D playback. Further, the controller 51 reads and supplies the Main TS and the SubTS to the decoding unit 56 based on the ID registered in the STN_table. The disk drive 52 reads data from the optical disk 2 in accordance with the control of the controller 51, and outputs the read data to the controller 51, the memory 53, or the decoding unit 56. 145441.doc -28 - 201105108 Memory 5 3 is appropriate memory control and so on.益5 1 Information required to perform various processes The local storage 54 contains, for example, HDD (Hard to spit, hard disk drive). (4) In the storage unit 54, the record is downloaded by the ship (4):

Dependent view video stream, etc. The stream recorded in the local storage device μ is also appropriately supplied to the decoding unit. 6 » The internet interface 55 communicates with the feeder 72 via the network 71 in accordance with control from the controller 51, and will be served by the feeding device. The data downloaded by the unit 72 is supplied to the local register 54. The information for updating the data recorded in the optical disc 2 is downloaded from the server 72. Can be used by - and make the burden after (4) (10) _ him. The stream is recorded with the Base view vide recorded on the disc 2. Streaming, and realizing 3D playback of content different from the content of Light Seven. After Dependent - the stream is downloaded, the content of the PlayList is also updated appropriately. The β decoding unit 56 decodes the stream shared by the disk drive 52 or the local storage (4), and outputs the obtained video signal to the display. Device 3. The audio signal is also output to the display device 3 via a specific path. The input unit 57 includes a wheeled device such as a button, a button, a touch panel, a scroll wheel, a mouse, or the like, or receives a red line transmitted by a specific remote controller; a receiving unit of the number. The operation input unit 57 The user's operation is detected, and a signal indicating that the detected operation content is not supplied is supplied to the controller 51. Fig. 21 is a view showing a configuration example of the decoding unit 56. In Fig. 21, the video signal processing is performed. In the decoding unit %, the decoding process of the T audio signal is also performed. The result of the decoding process is 145441.doc • 29-201105108. The result of the decoding process is output to the display device via a path (not shown). 3. The PID (Pr〇p〇rti〇nal Intergral Derivative) filter 101 identifies the tS system supplied from the disk drive 52 or the local storage 54 based on the ID of the PID or the stream constituting the packet of the TS or the like. Is Main TS or Sub TS. The PID Transmitter 101 rotates the Main TS to the buffer 1〇2 and outputs the Sub TS to the buffer 103. The PID Transmitter 04 is sequentially read and recorded in the buffer丨Main2 in the Main TS packet, and based on the PID into For example, 'the PID filter 104 outputs the packet constituting the Base view video stream included in the Main TS to the b video buffer 1〇6, and outputs the packet constituting the Dependent view video stream to the switch 1〇7. Further, the PID buffer 104 outputs a packet constituting the Base IG stream included in the Main TS to the parent converter 114' and outputs a packet constituting the Dependent IG stream to the switch 118. The PID multiplexer 104 The packet constituting the Base PG stream included in the Main TS is output to the switch 122' and the packet constituting the Dependent PG stream is output to the switch 126. As explained with reference to Fig. 5, there are Base view video, Dependent view video, Base PG, Dependent PG, Base IG,

The Dependent IG's respective streams are multiplexed in the Main TS. The PID filter 105 sequentially reads the packets of the Sub TS memorized in the buffer 1〇3 and allocates them based on the PID. 145441.doc •30· 201105108 For example, the PID filter 105 outputs a packet constituting a Dependent view video stream included in the Sub TS to the switch 1〇7. Further, the PID filter 105 outputs a packet constituting the Base IG stream included in the Sub TS to the switch 114, and outputs a packet constituting the Dependent IG stream to the switch 118. The PID filter 105 outputs a packet constituting the Base PG stream included in the Sub TS to the switch 122' and outputs a packet constituting the Dependent PG stream to the switch 126. As explained with reference to Fig. 7, there is a case where the Dependent view video stream is included in the Sub TS. Further, as described with reference to Fig. 6, there is a case where each of Base PG, Dependent PG, Base IG, and Dependent IG is subjected to multiplex processing in Sub TS. The switch 107 is configured to be supplied by the PID filter 104 or the PID filter 105.

The Dependent view video stream packet is output to the d video buffer 108. The parent converter 10 9 sequentially reads the packet of the Base view video stored in the B video buffer 106 and the packet of the Dependent view video stored in the D video buffer 1〇8 according to the timing information of the specified decoding timing. . For example, the same time information is set in the packet storing the data of a certain face of the Base view video and the packet storing the data of the Dependent view video corresponding thereto. The switch 109 outputs the packet read by the B video buffer 1〇6 or the D vide〇 buffer 1〇8 to the video decoder! Hey. The video decoder i decodes the packet supplied by the switch 1 〇 9, 145441.doc 201105108 and outputs the data of the Base view video or Dependent view video obtained by decoding to the switch 111. The switch 111 outputs the data obtained by decoding the packet of the Base view video to the B video plane generating unit, and outputs the data obtained by decoding the packet of the Dependent view video to the D video plane generating unit 113. The B video plane generating unit 112 generates a plane of the Base View Vide0 based on the material supplied from the switch U1, and outputs it to the synthesizing unit 13A. The D video plane generating unit 113 generates a plane of the Dependent view video based on the material supplied from the switch U1, and outputs it to the synthesizing unit 130°. The parent converter 114 is supplied by the PID filter 1〇4 or the PID filter 1〇5. The packet constituting the Base IG stream is output to the b ig buffer 115. The B IG decoder 116 decodes the packet constituting the IG stream stored in the B IG buffer 115, and outputs the decoded data to the b button plane generating unit 11 7 . The B IG plane generating unit 117 generates a plane of the Base IG based on the data supplied from the B IG decoder ι6, and outputs it to the combining unit 13A. The switch 118 outputs a packet constituting the Dependent IG stream supplied from the PID buffer 1〇4 or the piD buffer 1〇5 to the D IG buffer ιΐ9. The D IG decoder 120 is configured to be stored in the D IG buffer 119.

The Dependent IG stream packet is decoded, and the decoded data is output to the D IG plane generating unit 121. The D IG plane generating unit 121 generates a plane of Dependents based on the data supplied from the D m decoder 12, and outputs it to the combining unit 13A. ^ J45441.doc •32- 201105108 The switch 122 outputs the packet constituting the Base PG stream supplied by the P_Plug 1〇4 or the piD filter 〇5 to the B pG buffer. The B PG decoder 124 is configured to be stored in the B pG buffer 123.

The packet of the Base PG stream is decoded, and the decoded data is output to the B PG plane generating unit 125. The B PG plane generating unit 125 generates a plane of Base PG based on the information supplied from the B pG decoder 124, and outputs it to the combining unit 13A. The switch 126 will be powered by the pid filter! 〇4 or PID filter 1G5 supply configuration The Dependent PG stream packet is rounded out to the D pG buffer 127. The D PG decoder 128 decodes the packet constituting the Dependent PG stream stored in the D PG buffer 127, and outputs the decoded data to the D PG plane generating unit 129. The D PG plane generating unit 129 generates a plane of the Dependent PG based on the information supplied from the £> PG decoder 128, and outputs it to the synthesizing unit 130. The combining unit 130 is a plane of the Base view video supplied from the b vide〇 plane generating unit 112, a plane supplied by the B IG plane generating unit U7 to π, and a plane of the Base pG supplied from the B PG plane generating unit 125. The specific order is superimposed and combined to generate a plane of the Base view. Further, the combining unit 130 is supplied from the d video plane generating unit 113.

The plane of the Dependent view video, the plane of the Dependent IG supplied from the d IG plane generating unit 121, and the plane of the Dependent PG supplied from the pG plane generating unit 129 are superimposed and combined in a specific order to generate a plane Depend 145441 of the Dependent view. Doc •33- 201105108 The synthesis unit 130 outputs the data of the plane and the plane of the Base view. The video data outputted by the synthesizing unit 130 is output to the display device 3, and 3D display is performed by alternately displaying the plane of Base_ and the plane of the view. [T-STD (Transport stream_System 丁 Μ. -, Transport Stream System Target Decoder) Example] Here, the configuration of the decoder and its surroundings in the configuration shown in Fig. 21 will be described. Fig. 22 is a view showing the configuration of video stream processing. In Fig. 22, the same components as those shown in Fig. 21 are denoted by the same reference numerals. In Fig. 22, there are shown PID filter 1〇4, B Wde〇 buffer 106, switch i〇7, D vide〇 buffer 1〇8, switch ι〇9, video decoding state 110, and DPB (Decoded). Picture Buffer, decoded picture buffer state) 15 1. Although not shown in Fig. 21, dpb 1 5 1 for memorizing decoded picture data is provided after the video decoder. The PID filter 1〇4 outputs the packet of the Base Wew vide〇 stream included in the Main TS to the B video buffer i〇6, and outputs the packet constituting the Dependent view video stream to the switch 1〇7. For example, in the packet constituting the Base view video stream, PID=0 is assigned as a fixed value of the PID. Further, in the packet constituting the Dependent view video stream, a fixed value other than 〇 is assigned as piD. The PID filter 1〇4 outputs a packet described in the header with piD=〇 to the b video buffer 1 〇6 ′ and outputs a packet of piD other than 标 in the header to the switch 107. 145441.doc -34- 201105108 The packets output to the B video buffer 106 are via TB (Transport Buffer s), MB (Multiplexing Buffer)! And remembered in VSBj. The basic stream of Base view video is stored in VSBj. In the switch 107, not only the packet supplied from the PID filter 1〇4 but also the packet constituting the Dependent view video stream extracted from the Sub TS in the pid filter 1〇5 of Fig. 21 is supplied. The switch 107 outputs the packet to the Dvide buffer 〇8 when the packet constituting the Dependent view video stream is supplied from the PID filter 104. Further, when the switch 107 supplies the packet constituting the Dependent view video stream by the PID filter 1〇5, the packet is output to the D Wde buffer 108, and the packet output to the D video buffer 108 is via TB2, MB2. And remembered in 2. In vsb2, the basic data of the Dependent view wde〇 is memorized. The switch 109 sequentially reads out the packet of the Base view video stored in the B video buffer 1〇6iVSBi and the Dependent viewvide〇 stored in the vsBj of the D vide buffer 1〇8, and outputs the packet to the video. Decoder 110. For example, the switch 109 is configured to output a packet of the same time immediately after the packet of the Base view at a certain moment, such as a video packet, and then output the base view video packet of the same time to the video solution WiiQ and then add (four) plus _. The package. For the package containing the data of a certain page of the Base view vide, and 145441.doc •35· 201105108 The package containing the data of the corresponding Dependent view video is 'set with the code of the packet Ensure that the PCR (program clock Reference) is synchronized at the same time. Even if the Base view video stream and the Dependent view video stream are respectively included in different TSs, the same time information is set for the packets storing the corresponding data. The time information is a DTS (Decoding Time Stamp) and a PTS (Presentation Time Stamp), and is set in each PES (Packetized Elementary Stream) packet. That is, when the pictures of the respective streams are arranged in the encoding order/decoding order, the picture of the Base view video and the Dependent view video at the same time will become the corresponding faces. The same DTS is set in the PES packet storing the data of the picture of a certain Base view video and the PES packet storing the picture data of the Dependent view video corresponding to the picture in the decoding order. Further, when the pictures of the respective streams are arranged in the order of display, the face of the Base view video at the same time and the face of the Dependent view video also become the corresponding faces. The same PTS is set in the PES packet storing the header data of a certain Base view video and the pES packet storing the screen data of the Dependent view video corresponding to the screen in the display order.

As described below, the "Group Of Pictures' structure and the Dependent view video streamed in the Base view video stream. GOP 145441.doc •36· 201105108 When the structure is the same structure, the stone is missing.丨g Guang H + Dan T corresponds to the face that corresponds to the display order. When the packet is transmitted in series, the packet of the packet read from the Bvide buffer 1〇6 at a certain timing and the buffer from the D Vide buffer 108 at the next timing are 2 As shown in Fig. 22, the packet 2 read out is the same time. The switch 109 outputs the packet of the Base view video read from the VSBi of the B vide buffer 1〇6 or the Dependent view video read from the vsB2 of the D ν^〇 buffer 1〇8 to The video decoder 110 ° video solution/coder U0 sequentially decodes the packets supplied by the switch 109, and memorizes the decoded Base view video picture data or the Dependent view video data in DpB i 5 1 in. The decoded picture data stored in the DPB 151 is read out from the exchange state 111 at a specific timing. Moreover, the decoded header data stored in the DPB 151 is used for prediction of other pictures by the video decoder 11 。. When the data is transmitted in series, the PTS of the data of the Base view video outputted at a certain timing and the PTS of the data of the Dependent view video outputted at the immediately subsequent timing become the same time.

The Base view video stream and the Dependent view video stream have both the multiplex processing as one as described with reference to FIG. 5 and the like; the case of § is also included in the different Ts as described with reference to FIG. The situation in the middle. Since the decoder module of FIG. 22 is installed, the playback device can also respond to the case where "14544l.doc -37-201105108 view video stream and Dependent view video stream multiplex processing to 1 TS" or respectively In the case of TS, for example, as shown in Fig. 23, if it is assumed that only the H@TS is supplied, it is impossible to cope with the case where the Base view video stream and the Dependent view video stream are respectively included in different TSs. Since the decoder module of FIG. 22 has the same dts, even if the Base view video stream and the Dependent view video stream are included in different TSs, the packet can be supplied to the video decoder 110 at the correct timing. The decoder for the Base view video and the decoder for the Dependent view video can be separately arranged in parallel. In this case, the decoder for the Base view video and the Dependent view video are respectively supplied with the same timing. [Second example] Fig. 24 is a view showing another configuration of processing for video streaming. In Fig. 24, in addition to the configuration of Fig. 22, "there is also an exchange slu". The L video plane generating unit 161 and the R video plane generating unit 162. The pid filter 105 is also shown in the preceding stage of the switch 107. The overlapping description is omitted as appropriate. The L video plane generating unit 161 generates the plane of the L view video. The R video plane generation unit 162 generates a plane of the R view video, and is provided instead of the D video plane generation unit 113 of FIG. 21 . In this example, the switch 111 must recognize and output the video data of the L view and the video data of the R view 14544 丨.doc -38 · 201105108. That is, the parent switch 111 must identify the data obtained by decoding the packet of the Base view video. It is L ▽丨6 which of the video data you and r view. The parental transformer 111 must identify which of the L View and r view data is obtained by decoding the Dependent view video packet. To identify L ” 6 You and Han view use the description with reference to Figure 12 and Figure 14.

VieW_type ° For example, the controller 5 1 outputs the view_type described in the PlayList file to the switch i u . When the value of the view-type is 〇, the switcher will decode the data stored in the DPB151 and output the data from the packet of the Base view Vlde identified by PID=0 to the L video plane generation unit. 161. The value of the 'view-type value as described above indicates that the Base view video stream is a stream of l view. In this case, the switch 丨 丨 will decode the piD identified by 〇

The data obtained by the Dependent view Vide0 packet is output to the r video plane generating unit 162. On the other hand, when the value of VieW_type is the case, the switch lu decodes the data stored in the DPB 151. 11) = The data obtained by the "view Wdeo packet" is output to the R vide plane generation unit 162. The value of the view-type indicates that the base view vide stream is a stream of R view. When it is shaped, the switch i 11 will decode the piD identified by 〇

The data obtained by the Dependent view video packet is output to the [vide〇 plane generating unit 161. 145441.doc • 39· 201105108 The L video plane generation unit 16 1 generates a plane of Lview video based on the material supplied from the switch 111, and outputs it to the synthesizing unit 130. The R video plane generation unit 162 generates a plane of the Rview video based on the data supplied from the switch 111, and outputs it to the synthesizing unit 13A. There is no information (field) indicating whether it is L view or R view in the basic stream of Base view video and Dependent view video encoded in H.264 AVC/MVC. Therefore, since the view_type is set in the PlayList file in advance, the recording apparatus can cause the playback apparatus 1 to identify which one of the L view and the R View is the Base view video stream and the Dependent view video stream, respectively. The playback device 1 can identify which of the L view and the R view streams the Base view video_ stream and the Dependent view video stream respectively, and switch the output destination corresponding to the recognition result. In the planes of the IG and PG, the L "~ and the rule view" are respectively prepared. Since the L view and the R view of the video stream can be distinguished, the playback device 1 can easily perform the plane synthesis of the L view and the R view. As described above, when the video signal is output via the HDMI transmission line, it is required to separately distinguish the signal of the L view from the signal of the R view, and then output the signal, but the playback device 1 can achieve the requirement. The decoding is stored in the DPB 151. The data obtained from the packet of the Base view video and the data obtained by decoding the packet of the Dependent view video can also be based on the view_id without being based on the pid. When encoding with the H.264 AVC/MVC profile standard, the composition is compiled. 145441.doc •40· 201105108 The access unit of the stream of code results sets the view_id. The view_id can be used to identify which view component the unit of view component is. Figure 25 shows the Access Unit. Figure of Figure 25 Access Unit #l is a unit containing the data of the Base view video. Dependent Unit #2 is a unit containing the data of the Dependent view video. The cess unit (the Dependent Unit in the case of the Dependent view) is a unit that collects data such as one screen in such a manner that it can be accessed in units of a picture. By encoding with the H.264 AVC/MVC profile standard, The data of each side of the Base view video and the Dependent view video is stored in the above unit. When encoding with the 264.264 AVC/MVC profile standard, as shown in Dependent Unit#2, for the respective view components Additional MVC header. The MVC header contains view_id. In the case of Figure 25, for Dependent Unit#2, the view component stored in the unit can be identified as Dependent view video 0 according to view_id. As shown in FIG. 25, the MVC header is not attached to the view component stored in Access Unit #1, that is, the Base view video. As described above, the Base view video stream is also used for 2D playback data. To ensure compatibility with it, Base view video is encoded without an MVC header. Or delete the temporarily attached MVC header. The encoding of the recording device will be described below. In the playback device 1, the view component without the MVC header is attached 145441.doc -41 - 201105108 (there is no view) its view"d is 0, and the view component is identified as Base view video. In Dependent view video, set a value other than 0 to view_id when encoding. Thereby, the playback device 1 can identify the Base view video based on the view_id identified as 〇, so that it can be decoded based on the view_id other than the actual setting, and the J Dependent view video ° is decoded in the switch in FIG. The identification of the data received by the packet of the Base view video and the data obtained by decoding the packet of the Dependent view video can also be performed based on such a vie w_id. [Third example] Fig. 26 is a view showing still another configuration of the process of performing video stream. In the example of Fig. 26, the b video plane generating unit 112 is provided instead of the L video plane generating unit 16i of Fig. 24, and the d vide〇 plane generating unit 113 is provided instead of the R video plane generating unit 162. The b video plane generating unit 112 and the D video plane generating unit 113 are provided with a switch 171 in the subsequent stage. Also in the configuration shown in Fig. 26, the output destination of the data is switched based on View_type. The switch 111 outputs the data obtained by decoding the packet of the Base view video among the data stored in the DPB 151 to the B vide 〇 plane generation 邙 112. Further, the parent converter 111 outputs the data obtained by decoding the Dependent view video to the Dvideo plane generating unit 113. As described above, the data obtained by decoding the packet of the Base view video and the packet obtained by decoding the Dependent view video packet, total, and ^ η 1 are identified based on the PID or the view_id in the above manner. I4544I.doc • 42· 201105108 B The video plane generation unit 112 generates a plane of the Baseview video based on the data supplied from the switch lu, and outputs it. The D video plane generation unit 113 generates a plane of the Dependent view video based on the data supplied from the switch lu, and outputs it. The controller 51 supplies the switch 171 with the view_type described in the piayList file. When the value of the view_type is 0, the switch m outputs the plane of the Base view video supplied from the B vide 〇 plane generating unit 112 to the synthesizing unit 130 as the plane of the L view video. The value of the view-type value indicates that the Base view video stream is a stream of L view. Further, in this case, the parent switcher 71 outputs the plane of the Dependent view video supplied from the D video plane generating unit 113 to the synthesizing unit 13 as the plane 0 of the R view video, and on the other hand, the value of the view type. In the case of 1, the switch m outputs the plane of the Dependent view video supplied from the D video plane generating unit 113 to the combining unit 130 as the plane of the L view video. A value of 1 of the view type indicates that the Base view video stream is a stream of R views. Further, in this case, the switch 117 outputs the plane of the Base view video supplied from the B video plane generating unit 至2 to the combining unit 13A as the plane of the R view video. Even in the configuration of Fig. 26, the playback device 1 can recognize L Wew and R view and switch the output destination based on the recognition result. [First example of the planar synthesis model] Fig. 27 is a view showing the configuration of the synthesis unit 13〇 in the configuration shown in Fig. 21 and the I45441.doc-43-201105108 of the preceding stage. In Fig. 27, the same components as those shown in Fig. 21 are denoted by the same reference numerals. To the switch 181, a packet constituting the IG stream included in the Main TS or Sub TS is input. In the packet constituting the IG stream input to the switch 18 1 'contains the packet of the Base view and the Dependent view. To the switch 182, a packet constituting the PG stream included in the Main TS or Sub TS is input. In the packet constituting the PG stream input to the switch 182, the package containing the Base view and the Dependent view are included. As described with reference to FIG. 5 and the like, a stream of a Base view and a Dependent view which are useful for 3D display are also prepared for IG and PG. Since the IG system of the Base view is synthesized and displayed by the Base view video, and the IG of the Dependent view is synthesized and displayed by the Dependent view video, the user can view the video in 3D, and can view the button or the icon in 3D.

In addition, since the PG system of the Base view is displayed in combination with the Base view video, and the PG of the Dependent view is synthesized and displayed by the Dependent Wew vide, the user can view the video in 3D and the text of the subtitle in 3D. The switch 181 outputs the packet constituting the Base IG stream to the b ig decoder 116, and outputs the packet constituting the Dependent IG stream to the D 沁 decoder 120. The switch 181 has the functions of the switch 114 and the switch ι8 of Fig. 21. In Fig. 27, the illustration of each buffer is omitted. The B IG decoder 116 decodes the packet of the stream constituting the Base 圯 145 441.doc • 44 - 201105108 supplied from the switch 181, and rotates the decoded f material to the β π plane generating unit 11 7 . The B IG plane generating unit 117 generates a plane of BaSeIG based on the material supplied from the B m eliminator ii6, and outputs it to the combining unit 13A. The D IG decoder 12() decodes the packet supplied by the switch m in the (4) GG stream, and outputs the decoded data to the defying plane generating unit m. Base IG streaming and Dependent IG streaming can also be decoded by a single decoder. The D IG plane generating unit 121 converts the data supplied by the D tamper 12 to the Dependent IG plane, and outputs it to the composition and 〇. The port parent converter 182 outputs the packet constituting the Base PG stream to the B pG decoder = 4, and outputs the packet constituting the _ café pG stream to the d button decoder 128. The parent converter 182 has the function of the switch ι 22 and the switch 图 of Fig. 21. The deductor decoder 124 decodes the packet constituting the stream stream supplied from the switch 182, and outputs the decoded data to the B π plane generating unit 125. The B PG plane generating unit 125 generates a plane of Base PG based on the resource r'' supplied from the B pG decoder 124, and outputs it to the combining unit 13A. The D PG decoder 128 decodes the packet constituting the Dependent PG string machine supplied from the switch 182, and outputs the decoded data to the D pG plane generating unit 129. Base pG streaming and pG streaming can also be decoded by one decoder. The D PG plane generating unit 129 generates a plane of the Dependent PG based on the material 145441.doc -45 - 201105108 supplied from the d decoder, and outputs it to the synthesizing unit 130 °. The video decoder 110 is paired by the switch 1 9 (Fig. 22, etc.) the supplied packets are sequentially decoded, and the decoded Base view vide data or Dependent view video data is output to the switch uj. The parent converter 111 outputs the data obtained by decoding the packet of the Base view video to the B video plane generating unit 112, and outputs the data obtained by decoding the packet of the Dependent view video to the D vide 〇 plane generating unit 丨丨3. The B video plane generation unit 112 generates a plane of the Base view video based on the data supplied from the switch ln, and outputs it. The D video plane generation unit 3 generates a plane of the Dependent view video based on the data supplied from the switch U1, and outputs it. The combining unit 130 includes the adding units 191 to 194 and the exchanger 195. The addition unit 191 synthesizes the plane of the Dependent PG supplied from the D PG plane generation unit 129 so as to be superimposed on the plane of the Dependent view video supplied from the d video plane generation unit 113, and outputs the synthesis result to the addition unit. 193. Color information conversion processing (CLUT (Color Look Up Table) processing) is performed on the plane of the Dependent PG supplied from the D PG plane generating unit 129 to the adding unit 191. The addition unit 192 synthesizes the plane of the Base PG supplied from the B PG plane generation unit 125 so as to be superimposed on the plane of the Base view video supplied from the B video plane generation unit 112, and outputs the synthesis result to the addition unit. 19 4. The color information conversion processing is performed on the plane of the Base PG supplied from the B P G plane generating unit 12 5 to the adding unit 19 2 or the offset value is used 145441.doc • 46- 201105108 correction processing. The addition unit 193 performs δ on the plane of the Dependent IG supplied from the D IG plane generation unit 121 so as to be superimposed on the synthesis result of the addition unit 191, and outputs the result of the synthesis as a plane of the Dependent view. The color information conversion processing is performed on the plane of the Dependent supplied from the D IG plane generating unit 121 to the adding unit 193. The addition unit 194 combines the planes supplied by the B IG plane generating unit 117 so as to superimpose on the synthesis result generated by the addition unit 192, and outputs the result of the synthesis as a plane of the Base view. The color information conversion processing or the correction processing using the offset value is performed on the plane of the Base IG supplied from the d IG plane generating unit 121 to the adding unit 194. Based on the image of the plane of the Base view generated in the above manner and the plane of the view, the button or icon can be seen in front, and the subtitle text can be seen under the button or icon (in the depth direction) under the subtitle text. Video can be seen. The parent converter 195 outputs the plane of the new plane as the plane of the L view and the plane of the input as the plane of the R view when the value of the View_type is 〇. The switch 195 is supplied to the view_type ° from the controller 5i. The parent converter 195 is based on the value of View_type, and outputs the plane of the Base view as the plane of the R view, and the plane of the view is used as the plane of the L view. Which of the planes supplied is the plane of the Base view or It is the plane of the Dependent view, which is identified based on PID or View_id. 145441.doc •47- 201105108 In this way, the planes of the Base view are played in the playback device 1,

The planes of the Dependent view are combined with each other, the planes of video, IG, and PG. At the stage after the synthesis of all planes of video and IG 'PG, based on view_type, it is judged whether the planes of the Base view are synthesized with each other as L view or R view, and the planes of r Wew and L view are respectively output. Moreover, after the synthesis of all the planes of video, IG, and PG is completed, based on the view_type, it is determined whether the planes of the Dependent view are synthesized with each other as L view or R View, and the planes of the R view are respectively output. The plane of Lview. [Second example] Fig. 28 is a view showing the configuration of the combining unit 130 and its front stage. In the configuration shown in Fig. 28, the same components as those shown in Fig. 27 are denoted by the same reference numerals. In Fig. 28, the configuration of the synthesizing unit 130 is different from that of Fig. 27. Further, the operation of the switch lu is different from the action of the exchanger 111 of Fig. 27. The 1 video plane generating unit 161 is provided instead of the B video plane generating unit 1丨2, and the R video plane generating unit 162 is provided instead of the D vide〇 plane generating unit 113. The repeated description is omitted. The switch 51 and the switch 2〇 j and the parent converter 202 of the synthesizer j 3 are supplied by the controller 51 to the same view-type value. Like the switch 111 of Fig. 24, the switch U1 switches the data obtained by decoding the packet of the Base view video and the output destination of the data obtained by decoding the packet of the Dependent view video based on the view "ype". I4544I.doc •48· 201105108 For example, when the value of view-type is 0, the switch (1) will solve the base view Vide. The data obtained by the packet is output to l ^. When the plane generating unit 161 is (4), the switch (1) outputs the data obtained by decoding the packet of the Dependent View video to R. Planar generating unit i α. On the other hand, when the Vlew_type2 value is i, the switch HI will decode the base view video block m + , and the decoded data will be output to the R video plane generating unit 162 ° in this case, the switch (1) Department, will decode

The data obtained by the Dependent view video packet is output to the l vide 〇 plane generating unit 161. The L video plane generation unit 161 generates a plane of the Lviewvideo based on the data supplied from the switch iu, and rotates it to the synthesizing unit 13A. The R video plane generation unit 162 generates a plane of Rviewvideo based on the data supplied from the switch lu, and outputs it to the synthesizing unit 13A. The synthesizing unit 130 includes a switch 201, a switch 2〇2, and adders 2〇3 to 206. The parent converter 201 switches the plane of the Base IG supplied by the b IG plane generating unit 117 based on the view_type and the D IG. The output destination of the plane of the Dependent IG supplied from the plane generating unit 121. For example, when the value of the view_type is 〇, the switch 2〇1 outputs the plane of the Base IG supplied from the B IG plane generating unit in the plane of the L view to the adding unit 206. In this case, the switch 201 outputs the plane of the Dependent IG supplied from the D IG plane generating unit 121 as a plane of the R view, and outputs it to the adding unit 205. On the other hand, when the value of the view_type is 1, the switch 201 145441.doc -49 - 201105108 sets the plane of the Dependent IG supplied from the D IG plane generating unit 121 as the plane of the L view, and outputs it to the adding unit 2〇. 6. In this case, the switch 201 outputs the plane of the Base IG supplied from the B IG plane generating unit 117 as the plane of the r view to the adding unit 2〇5. The switch 202 switches the plane of the Base PG supplied from the UI plane generating unit 125 and the output destination of the plane of the Dependent PG supplied from the D PG plane generating unit 129 based on the view__type. For example, when the value of the view_type is 〇, the switch 2〇2 outputs the plane of the Base PG supplied from the B PG plane generating unit 125 to the L vieW2 plane, and outputs it to the adding unit 204. In this case, the switch 2〇2 outputs the plane of the Dependent pG supplied from the D PG plane generating unit 129 as the plane of the r view, and outputs it to the adding unit 2〇3. On the other hand, when the value of the view ype is i, the switch 2〇2 outputs the plane of the Dependent PG supplied from the D PG plane generating unit 129 to the plane of the L view, and outputs it to the adding unit 2〇4. In this case, the switch 202 supplies the plane of pG as the plane of the R view to the adder unit 2〇3, which is supplied from the B PG plane generating unit 125. The adder unit 203 supplies the R viewiPG supplied from the switch 202. The plane is superimposed on the flat s of the R Wew Wde 供给 supplied from the R video plane generating unit 162, and the combined result is output to the adding unit 2〇5. The adding unit 204 is supplied by the exchanger 202. L "6] The plane t of pG is superimposed on the L view supplied from the L video plane generating unit 161. The synthesis is performed in a manner above the palpitations, and the synthesis result is output to the addition unit 2〇6. The addition unit 205 is an R that is supplied from the exchanger 2〇1. 6 is synthesized by the plane of 1 (}, t 145441.doc -50 - 201105108 superimposed on the plane of the synthesis result of the addition unit 203' and outputs the synthesis result as the plane of the R view. The addition unit 206 is to be exchanged The plane of the "6 disaster 1" is synthesized in such a manner as to be superimposed on the plane of the synthesis result of the addition unit 204, and the synthesis result is output as the plane of the L view. In this manner, the playback device In the 1st plane, the plane of the Base view and the Dependent view of each of the 〃丨, ig, and PG, before the synthesis with other planes, determine which plane is L view or r view. The combination of the planes of the video, IG, and PG is performed so that the planes of the L view and the plane of the r view are combined with each other. [Configuration Example of Recording Apparatus] FIG. 29 is a block diagram showing a configuration example of the software creation processing unit 301. The video encoder 3 11 has the same configuration as the MVC encoder 11 of Fig. 3. The video encoding 3 11 system] Λ Λ 2 2 6 4 AV C/MV C setting slot standard encoding a plurality of shirt images 'fine Generate Base view video stream Dependent view video stream, and output it to the buffer 3 12. For example, 'depending on the coded code 3 3 series in the encoding, with the same PCR as the standard, set DTS, PTS » ie, video encoder 3 The system sets the same DTS to the PES packet storing the data of a certain Base view video and the PES packet storing the data in the decoding order corresponding to the Dependent view video corresponding to the picture. The encoder 3 11 sets the same PES packet for storing the data of a certain B ase ν iew ν ide 、 and the PES packet storing the data of the Dependent view video corresponding to the screen in the display order, and the setting is the same 145441. Doc •51 · PTS of 201105108. As described below, the video encoder 311 sets the same information as the side of the Base view video corresponding to the decoding order and the side of the Base view vide, as auxiliary information related to decoding. Additional information. Further, as described below, the video encoder 311 sets the same value as the Base view video corresponding to the display order and the Base vide frame. Output order of p〇c display screen (picture Order Count, picture order count) of the value. Further, as will be described later, the video encoder 311 encodes the GOP structure of the Base view yide stream and the G 〇p structure of the Dependent view video stream. The audio encoder 313 encodes the input audio stream and outputs the resultant data to the buffer 314. In the audio encoder 313, the Base view video, the Dependent view Vide0 stream, and the audio stream recorded in the disc are input. Is the data encoder 315 paired? The above various data other than the video and audio of the 13丫1^31 file are encoded and the encoded data is output to the buffer 316. The data encoder 3 1 5 is based on the encoding of the video encoder 3 11

In the PlayList building, a view_type indicating whether the Base view video stream is a stream of L view or a stream of R view is set. Can also be set not to indicate

Base view video stream type, but indicates that the Dependent view video stream is the stream of l view stream or R view stream. Further, the data encoder 3 1 5 sets the following EP_map in Base 145441.doc • 52· 201105108 view video Stream Clip Information Rights and Dependent view video stream Clip Information file. The screen of the Base view video stream set in the EP_map as the decoding start position and the screen of the Dependent view video stream are corresponding screens. The multiplexer 3 1 7 multiplexes the video data, the audio data, and the data other than the stream stored in the respective buffers with the synchronization signal, and outputs the result to the error correction coding unit 3 1 8 . The error correction coding unit 3 18 adds the code for error correction to the data processed by the multiplexer 3丨7. Tune. Inflammation.卩3 1 9 The data supplied from the error correction coding unit 3 18 is subjected to modulation processing and output. The output of the modulation unit 319 becomes a soft body recorded in the optical disc 2 that can be played by the playback device. The software creation processing unit 3〇1 having such a configuration is installed in the recording device. FIG. 30 is a view showing an example of a configuration including the software creation processing unit 3〇1. There is also a case where one of the configurations shown in Fig. 30 is provided in the recording apparatus. The recording signal generated by the software creation processing unit 312 is subjected to the mastering process in the mastering/producing processing unit 331, and generates a signal to be recorded in the format of the optical disk 2. The generated signal is supplied to (4) disc 333. A master disk containing glass or the like is prepared in the recording master disk preparation unit 332, and a recording material containing a photoresist or the like is applied thereon. Thereby, the recording mother 145441.doc -53- 201105108 is created in the master recording unit 3 3 3 , and the oblique signal + λ is applied to the recording signal supplied from the master pre-processing unit 3 3 1 'the laser beam The photoresist that is irradiated onto the master disc after modulation. Thereby, the green _ on the master disc is exposed by the recording signal. After that, the master is developed, so that a pit appears on the master. In the metal mastering unit 334, the master is subjected to electroforming or the like to produce a metal master disk on which the pit on the glass master is transferred. From this metal, a metal stamper is produced and used as a mold. In the molding processing unit 335, a material such as polymethyl methacrylate or polycarbonate is injected into a molding die by an injection method or the like to perform an immobilization treatment. Alternatively, after applying 2p (ultraviolet curing resin) or the like to the metal stamper, it is irradiated with ultraviolet rays to be cured. By &, the machine pit on the metal stamper can be transferred to the copy film containing the resin. In the film formation processing unit 336, a reflection film is formed on the copy film by vapor deposition, sputtering, or the like. Alternatively, a reflective film is formed on the copy film by spin coating. In the subsequent processing unit 337, the inner and outer diameters of the disc are processed, and necessary processes such as laminating two discs are performed. Furthermore, after attaching the label or installing the hub, insert it into the cassette. In this way, the optical disc 2 on which the material which can be played by the playback device 1 is recorded is completed. <Second Embodiment> [Application of H.264 AVC/MVC Profile Video Streaming 1] In the BD-R0M standard which is the standard of the optical disc 2, as described above, by using the H.264 AVC/MVC Profile And to achieve the encoding of 3D images. Further, in the BD-ROM specification, 'the Base view video is streamed to the video stream of the '14544l.doc.54·201105108 view' and the Dependent view video is streamed as the video stream of the R view. Since the Base view video is encoded as a 264.264 AVC/High Profile video stream, even the previous player or the player supporting only 2D playback can play the disc 2 as a disc supporting 3D. That is, the compatibility is ensured. Specifically, even if the decoder does not support the H.264 AVC/MVC profile standard, only the stream of Base view video can be decoded (played). That is, the 'Base View video stream becomes even the current one; the bd player is bound to be able to play the stream. Moreover, since the Base view video stream is commonly used in 2D playback and 3D playback, the load is reduced at the time of production. The producer can create a disc supporting the 3]:) as long as the Dependent view video stream is prepared for the Av stream. Fig. 3 is a view showing an example of the configuration of a 3D video TS generating unit provided in the recording device.

The 3D video TS generation unit of FIG. 31 includes an MVC encoder 401, an MVC header deletion unit 402, and a multiplexer 403. The data of the image #1 of L view and the image of the image of R "6~" taken in the manner described with reference to Fig. 2 are input to the MVC encoder 401. The MVC encoder 401 encodes the data of the image #1 of the L view by H.264/AVC, and outputs the encoded AVC video data as a Base view video stream. Further, the MVC encoder 401 generates a Dependentviewvide stream based on the data of the image #1 of the View and the data of the R view "145441.doc · 55· 201105108 image #2, and outputs it. The Base view vide stream outputted by the MVC encoder 401 is an Access Unit that stores data of each picture of the Base view video. Further, the Dependent view vide stream outputted by the MVC encoder 401 includes a Dependent Unit storing data of each picture of the Dependent view video. Each of the Access Units constituting the Base view video stream and the Dependent Unit constituting the Dependent view video stream include Mvc headers describing the view "d" useful for identifying the stored view c〇mp〇nent. The value of the view_id described in the MVC header of the Dependent view video uses a fixed value of 1 or more. The same is true in the examples of Figs. 32 and 33. That is, the 'MVC encoder 401 is different from the MVC encoder 11 of Fig. 3, and the MVC encoder 401 is generated and output in the form of an MVC: header attached thereto.

Encoder of each stream of Base view video and Dependent view video. The MVC encoder 11 of Fig. 3 applies only the MVC header to the Dependent view video encoded with the η·264 AVC/MVC setting standard. The Base view video stream output from the MVC encoder 401 is supplied to the MVC header deletion unit 402'. The Dependent view video stream is supplied to the multiplexer 403. The MVC header deletion unit 402 will constitute each of the Base view video streams 145441.doc -56· 201105108

The MVC header deletion e Mvc header deletion unit 402 included in the Access Unit outputs a Base view video stream containing the Access Unit after deleting the MVC header to the multiplexer 403. The multiplexer 403 generates a TS including a Base view video stream supplied from the MVC header deleting unit 4〇2 and a Dependent view video stream supplied from the MVC encoder 401, and outputs the TS. In the example of FIG. 31, the TS including the Base view video stream and the TS including the Dependent view video stream are respectively output, but as described above, there are also cases where the TS multiplexing is processed into the same TS and output. . In this way, depending on the installation method, it is also considered to input the images of the L vieW2 image and the R view, and output the MVC encoders of the streams of the Base view video and the Dependent view video with the Mvc header. Further, as shown in Fig. 3, the MVC encoder may include the entire configuration shown in Fig. 31. The configuration shown in Figs. 32 and 33 is also the same. Fig. 3 is a view showing another configuration example of the 3D video TS generating unit provided in the recording device. 333丨(16〇8 generation unit includes a mixing processing unit 411'], an encoder 412, a demultiplexing unit 413, an MVC header deleting unit 414, and a multiplexer 415. The information of the image #1 of the L view and the image of the rule view #2 are input to the mixing processing unit 411. The mixing processing unit 411 arranges the respective screens of the L·view and the respective faces of the R view in the coding order. The Dependent view video is encoded by the corresponding Base view video of the moxibustion test, so the result of sorting in the coding order is that the image of the L view and the R view are alternately arranged. 145441.doc -57- 201105108 Mix The processing unit 4 11 outputs the written and R view screens of the L view arranged in the coding order to the MVC encoder 412. The MVC encoder 412 is supplied by the mixing processing unit 411 with the H.264 AVC/MVC setting tip 'standard pair. Each picture is encoded, and the encoded stream is output to the demultiplexing unit 413. In the stream output by the MVC encoder 412, the Base view video stream and the Dependent view video stream are multiplexed. Base view vid included in the stream output by the MVC encoder 412 The e〇 stream system includes an Access Unit storing data of each picture of the Base view video, and is included in the stream output by the MVC encoder 412.

The Dependent view video stream contains a Dependent unit that stores the data of each screen of the Dependent View video. Each of the Access Units constituting the Base view video stream and the Dependent Unit constituting the Dependent view video stream include a description "d& MVC header that is useful for identifying the stored view c〇mp〇nent. The demultiplexing unit 41 3 performs multiplex processing on the multiplexed processing of the streamed Base view video stream supplied by the MVC encoder 412 and the Dependent view vide〇 stream, and then rotates. The Base view video stream output from the demultiplexing unit 413 is supplied to the Mvc header deleting unit 414, and the Dependent video stream is supplied to the multiplexer 4 i 5 . The MVC header deletion unit 414 deletes the MVC header included in each Access Unit constituting the Base VieW vldeo stream supplied from the demultiplexing unit 413. The MVC header deletion unit 414 will contain Access 145441.doc •58- 201105108 after deleting the mvc header.

The Base view video stream of the Unit is output to the multiplexer 415. The multiplexer 41 5 generates a TS including the Base view video stream supplied from the MVC header deleting unit 414 and the Dependent view video stream supplied from the demultiplexing unit 413, and outputs the TS. Fig. 33 is a view showing still another example of the configuration of the 3D video TS generating unit provided in the recording device. The 3D video TS generating unit of FIG. 33 includes an AVC encoder 421, an MVC encoder 422, and a multiplexer 423. The data of the image #1 of the L view is input to the AVC encoder 421, and the data of the image #2 of the R view is input to the MVC encoder 422. The AVC encoder 421 encodes the image #1 of the L view with H.264/AVC, and outputs the encoded AVC video stream as a Base view video stream to the MVC encoder 422 and the multiplexer 423. The MVC header is not included in each Access Unit constituting the Base view video stream outputted by the AVC coder 421. The MVC encoder 422 decodes the Base view video stream (AVC video stream) supplied from the AVC encoder 421 to generate the data of the image #1 of the L view. Further, the MVC encoder 422 generates a Dependent view video stream based on the decoded image of the L view image #1 and the data of the R view image #2 input from the outside, and outputs the Dependent view video stream to the multiplexer 423. The Dependent Unit constituting the Dependent view video stream output by the MVC encoder 422 includes an MVC header. The multiplexer 423 can generate a TS including the Base view 145441.doc -59 - 201105108 video stream supplied from the AVC encoder 421 and the Dependent view video stream supplied from the MVC encoder 422, and output the TS. The AVC encoder 421 of Fig. 33 has the function of the H.264/AVC encoder 2 1 of Fig. 3, and the MVC encoder 422 has the H.264/AVC decoder 22 of Fig. 3 and

Dependent view video encoder 24 function. Further, the multiplexer 423 has the function of the multiplexer 25 of Fig. 3. The MVC header can be prohibited from storing the data of the Base view video by setting the 3D video TS generating unit having the above configuration in the recording device.

The encoding of the Access Unit. Further, the Dependent Unit storing the data of the Dependent view video may include an MVC header having one or more view-ids. Figure 34 is a diagram showing the configuration of the playback device 1 side in which the Access Unit is decoded. In Fig. 34, 'the switch 1 〇 9 and the video decoder 110 described with reference to Fig. 22 and the like are shown. Access containing Base view video

Unit#l, Dependent with data containing Dependent view video

Unit#2 is read from the buffer and supplied to the switch. Since the encoding is performed with reference to the Base view video, in order to correctly decode the Dependent view video, it is first necessary to decode the corresponding Base view video in advance. In the H.264/MVC profile standard, the decoder side calculates the decoding order of each unit by using the view-id included in the MVC header. Also, in the Base view video, the minimum value is always set to the view_id value when encoding. The decoder can start decoding by including the unit with the smallest MVC standard 145441.doc •60- 201105108, and decode the Base view "^(9) and Dependent view video in the correct order. There is a video decoder ιι〇, which is supplied to the playback device.

Base view " Heart 0 of the "^3 Unit, the encoding of the mvc header is prohibited. Therefore, in the playback device 1, it is stored in the Mvc-free header.

The view component in the Unit is defined to be identified by its own. Thereby, the playback device i can identify the Base view vide based on the view_id identified by the View_id, and can identify the Dependent view vide〇0 based on the view-id other than the actual setting. First, it recognizes that the Access Un pool i, which is set to the viewjd as the minimum value, is output to the video decoder 11 for decoding. Further, after the decoding of Access Unit #1 is completed, the parent converter 109 sets a γ which is a fixed value greater than 0 as a view-id unit.

The Dependent Unit #2 is output to the video decoder 11 for decoding. The Dependent view Wde〇 image stored in Dependent Unit#2 is the same as the one stored in the Base view vide〇 in Access Unit#1. In this way, the MVC header can be prohibited from encoding the Access Unit storing the Base view vide, and the Base video stream recorded in the disc 2 can be streamed in the previous player. Even if it is specified as a condition that can be played back in the previous player, 145441.doc 61 201105108 can also satisfy the condition of the video% video stream of the extended BD_R〇M 3D standard of the BKROM specification. For example, as shown in FIG. 35, when the MVC header is added to the Base video for decoding, the Base view video and the Dependent view 'and the view video from the Base view video are first unplayable in the previous player. For the H 264/AVC decoder loaded by the previous player, the MVC header is undefined. In the case where such undefined data is input, there is a possibility that the undefined data cannot be ignored by the decoder, resulting in failure of processing. Furthermore, in Fig. 35, the viewJd of the Base View video is χ, and the View_id of the Dependent view video is γ larger than x. Moreover, even if the encoding of the MVC header is prohibited, the playback device 1 may first perform decoding of the Base view video by defining the view_id of the Base view video as the UI, and then perform the corresponding Dependent view vide〇. The solution. That is, 'decoding can be performed in the correct order. [Operation 2] About the GOP structure In the H.264/AVC standard, the GOP (Group Of Pictures) structure in the MPEG-2 video standard is not defined. Therefore, in the bd-ROM specification for processing H.264/AVC video stream, the G Ο P structure of Η. 2 6 4 / AV C video stream is defined, thereby realizing random access and the like using the GOP structure. Various functions. In the Base view video stream and the Dependent view video stream 145441.doc -62- 201105108, which is encoded as the 264.264 AVC/MVC profile standard, also with H.264/AVC video stream Again, there is no definition of a GOP structure.

The Base view video stream is H.264/AVC video stream. Therefore, the GOP structure of the Base view video stream has the same structure as the GOP structure of the H.264/AVC video stream defined in the BD-ROM specification. The GOP structure of the Dependent view video stream is also defined in the same structure as the GOP structure of the Base view video stream, that is, the GOP structure of the H.264/AVC video stream defined in the BD-ROM specification. The GOP structure of the H.264/AVC video stream defined in the BD-ROM specification has the following features. 1 · Features of the stream structure (1) Open GOP/Closed GOP structure Fig. 36 is a diagram showing the structure of the Closed GOP. Each of the faces of Fig. 36 constitutes a picture of H.264/AVC video stream. The IDR (Instantaneous Decoding Refresh) is included in the Closed GOP. The IDR picture is I-plane and is decoded first in the GOP containing the IDR picture. In the decoding of the IDR face, all the information related to the decoding of the reference picture buffer (DPB 151 of Fig. 22), the frame number managed so far, or the POC (Picture Order Count) is reset. As shown in Fig. 36, in the current GOP as the Closed GOP, the picture of the previous GOP is prohibited from being referred to in the display order of the current GOP in the display order than the IDR face (backtracking). 145441.doc •63· 201105108 In addition, it is prohibited to refer to the previous GOP screen in the current GOP screen in the display order, which is later than the IDR screen (future). In H.264/AVC, it is also allowed to refer to the picture that is located earlier than the I picture from the P picture that is located after the display order. Figure 37 is a diagram showing the structure of an Open GOP. As shown in FIG. 37, in the current GO:P as the Open GOP, the screen of the current GOP is allowed to be displayed in the order of the non-IDR I (the side of the non-IDR picture) in the display order. The picture of GOP. In addition, it is prohibited to cross the non-IDRI picture in the display order of the current GOP in the display order than the non-IDR I, and refer to the face of the previous GOP. (2) In the Access Unit before the GOP, it is necessary to encode the SPS (Sequence Parameter Set) and the PPS (Picture Parameter Set). The SPS (Sequence Parameter Set) is a header information of a sequence containing information related to the encoding of the entire sequence. When decoding a certain sequence, it is necessary to initially include the SPS of the sequence identification information and the like. PPS (Picture Parameter Set) is the header information of the picture containing the information related to the encoding of the entire face. (3) Up to 30 PPSs can be encoded in the Access Unit before the GOP. When a plurality of PPSs are encoded in the leading Access Unit, the id (pic_parameter_set"d) of each PPS is strictly prohibited. (4) Up to 1 P P S can be encoded in an Access Unit other than the GOP. 145441.doc -64- 201105108 2 · Features of the reference structure (1) The I.P.B screen is required to be a screen composed only of w.p.B slices. (2) It is required to be in the order of display in front of the reference face or face). The face must be encoded in the coding order followed by the above reference picture. a () The length of the reference code (1 or P face) is the same as the display order (same). (4) It is forbidden to refer to the side B from the p-face. (5) In the coding order, when the non-parametric surface (B1) is located in the non-reference surface (4), the display order is also required to be B 1 first. The _ reference B 昼 is not a B-picture of other written essays in which the coding order is not followed. One (6) Refer to the B picture for reference to the reference picture or P昼 in the display order. (7) The non-reference B picture can refer to the reference picture (work or P picture) adjacent to the display order, or the reference B picture. (8) It is required to make the number of consecutive b-faces up to three. 3 _About the maximum frame in the GOP. The characteristics of the block number As shown in Figure 38, the maximum frame in the GOP. The number of blocks is determined by the frame rate of the video. As shown in Fig. 38, for example, when the frame rate is 29 97 frames/sec, the maximum number of turns that can be displayed on the HsG〇p screen is 6〇. Moreover, when the frame rate is 59.94 frames/sec, the maximum number of frames that can be displayed in one GOP face is 6 (^ will also have the GOP structure definition as described above. For the Dependent 145441.doc -65- 201105108 view video stream GOP structure. Also, it is specified that the structure of a GOP of the Base view video stream is consistent with the structure of the corresponding Dependent view video stream GOP as a constraint. 39 shows the Closed GOP structure of the Base view video stream or the Dependent view video stream defined in the above manner. As shown in FIG. 39, in the current GOP as the Closed GOP, the display order of the current GOP is prohibited. The picture of the previous GOP is referred to before the picture of the IDR picture or the anchor face (backtracking). The anchor picture will be described below. Also, the current GOP picture is prohibited from being displayed later than the IDR picture or the anchor picture in the display order (future The picture of the previous GOP is referenced over the IDR picture or the anchor picture. Figure 40 is a diagram showing the Open GOP structure of the Base view video stream or the Dependent view video stream. As shown in Figure 40, As the current GOP of the Open GOP, the picture of the current GOP is allowed to refer to the front side of the previous GOP in the display order than the non-IDR anchor picture (the anchor picture of the non-IDR face). The face of the current GOP is displayed in the order of the non-IDR anchor face in the display order, and the picture of the previous GOP is referenced. The GOP structure can be defined in the above manner, for example, Base view A certain GOP of the video stream, and the GOP of the corresponding Dependent view video stream is the same as the Open GOP or Closed GOP stream 145441.doc • 66- 201105108 structure. Also 'with Base view video The reference structure of the Dependent view video corresponding to the non-reference Β screen may also be consistent with the features of the reference structure, so as to be a non-reference B 。 face. Further, a certain GOP of the Base view video stream, and the corresponding Dependent view video The number of frames and the number of blocks in the stream can also be the same. Thus, the structure of the Dependent view video _ stream can be defined as the same structure as the GOP structure of the Base view video stream. Streaming The GOP should have the same characteristics with each other. Further, even if decoding is performed in the middle of streaming, decoding can be performed without any problem. The decoding from the middle of the stream is performed, for example, at any time for on-demand or random access. When the structure of G Ο P corresponding to each other is different in the manner of different number of frames, there is a case where one of the streams can be played normally, and another stream cannot be played, but the situation can be Take precautions. In the case where the structure of the GOPs corresponding to the streams is decoded as a dissimilar person from the middle of the stream, there is also a problem that the base Wew Wde which is required to decode the video (10) such as _V1deo is not solved. The situation of Shima. In this case, as a result, the Dependent_video screen cannot be decoded, and the display cannot be performed. Also, the Base view vide cannot be output due to the installation method. The possibility of the image 'but the S Hai special bad situation can also be avoided. [EP-map] 145441.doc •67- 201105108 By using the Base Wew video stream and the Dependent view vide stream GOP structure, the decoding start position at random access or on-demand can be set to EP_map. in. EP_map is included in the C丨ip Inf〇rmati〇n file. The following two constraints are defined for the constraint that can be set in the EP_map as the decoding start position. 1. Make the position that can be set in the Depend'ent view video stream, the position of the anchor picture configured next to SubsetSPS, or the position of the IDR face configured by SubsetSps. The anchor picture is a picture specified by the H.264 AVC/MVC profile standard, and is a Dependent view video stream that performs reference coding between views without reference to the time direction. 2. When a certain picture of the Dependent view video stream is used as the decoding start position and set in the EP_map, the corresponding Base view video stream picture is also set as the decoding start position in the EP-map. Fig. 4 is a diagram showing an example of setting a decoding start position in an Ep_map satisfying the above two constraints. In Fig. 41, the picture constituting the Base view video stream and the frame constituting the Dependent view video stream are shown in decoding order.

The face of the Dependent view video stream is represented by the anchor face or the IDR picture. SubsetSPS is included in the Access Unit containing the screen data. In the example of Fig. 41, as shown by the hollow arrow #11, the screen is set as the solution start position in EP_map 145441.doc -68 - 201105108 of the Dependent view video stream. As the base view vide corresponding to the facet p. Picture of streaming picture

Pn is the IDR picture ". As shown by the towel arrow #12, the picture Ρπ as the gamma picture is also set as the decoding start position in the EP_map of the 8 stream stream. Since the instruction of random access or on-demand is received, and the decoding starts from the face I and the picture P", the decoding of the face Ρ π is first performed. Due to the idr screen, the picture Ριι can be decoded without reference to other pictures. When the decoding of the picture Pu ends, the next time the picture is decoded. In the painting! The decoded picture is referenced to the decoded picture ρπ. Because of the anchor screen or IDR screen, as long as the decoding of the face is finished, the decoding of the face Pi can be performed. 0 Then, press the bottom of the Base view Video and the bottom of the Dependent view video. P" The next one, and so on. Since the structure of the corresponding GOP is the same 'and the decoding is started from the corresponding position', the book after the picture set in the Ep_map can be decoded without problems, whether the Base view video or the Dependent View video ’. This allows random access. In Fig. 41, the pupil line arranged on the left side as compared with the dotted line shown in the vertical direction is an undecoded face. Figure 42 is a diagram showing the problem that occurs when the GOP structure of the Dependent view video is not defined. In the example of Fig. 42, the IDR of the Base view video indicated by the color gradation 145441.doc _69· 201105108 The screen is set as the decoding start position in the Ep_map. In the case where the picture from the BaSe view vide is decoded, it is assumed that the picture of the Dependent view vide corresponding to the picture P2 is the picture 卩3丨 and is not the anchor picture. When the G〇p structure is not defined, there is no guarantee that the screen of Dependent who corresponding to the IDR screen of Base view.Wde〇 is an IDR screen or an error screen. In this case, even if the decoding of the picture Pu of the Base view vide is completed, the picture PS1 cannot be decoded. The reference to the time direction is also required for decoding of the picture Pn, but the picture on the left side (before the decoding order is higher) than the dotted line shown in the vertical direction is not decoded. Since the picture P3 cannot be decoded, it is impossible to decode the other side of the Dependent view video of the reference picture P3. This can be avoided by predefining the GOP structure of the Dependent view video stream. The playback device 1 can easily determine the start position of the decoding by setting the decoding start position to the Ep-claw in advance not only for the Base view video but also for the Dependent view video. The playback device is used when only one of the Base View video screens is set as the decoding start position in the EP map. It is necessary to calculate the Dependent view video corresponding to the face of the decoding start position by calculation, which complicates the processing. Even if the corresponding Base view video and Dependent view video have the same DTS/PTS, when the bit rate of the video is different, the bits in the TS cannot be aligned, so the processing becomes 145441. .doc •70· 201105108 Miscellaneous. Figure 43 is a diagram showing the concept of a face search required to perform random access or on-demand playback of an MVC stream including a Base view vide stream and a Dependent view video stream. As shown in Fig. 43, when random access or on-demand is performed, the non-IDR anchor picture or IDR picture ' is searched for and the decoding start position is determined. Here, EP_maP will be described. Description Base view "The decoding start position of the heart is set in the EP map, and the decoding start position of the mouth (3) plus video is also set in the EP_map of the Dependent view video in the same way. Fig. 44 shows the record in A diagram of the structure of the AV stream on the disc 2. The TS system including the Base view video stream includes an integer number of aligning units (AUgned Units) having a size of 6144 bytes. The aligning unit contains 32 source packets ( The s〇urce source packet has i92 bytes. The i source packets contain a 4-bit transport packet extra header (TP_extra header) and a 188-bit transport packet (Transport Packet).

The data of BaSe VUW Video is encapsulated in MPEG2 PES. A pES packet header is added to the data portion of the PES packet to form a pEs packet. The PES packet header contains a stream ID that determines the type of elementary stream that the pES packet is to transmit. The S packet is further encapsulated into a transport packet. #, The packet is determined by the size of the payload of the transport packet, and the payload is added to the payload: the packet header forms a transport packet. The transport packet header contains the identification information of the data stored in the payload of the valid I45441.doc 201105108, ie PID. Furthermore, in the source packet, the Clip AV stream preamble is set to, for example, 0, and each source packet is given a source packet number that is incremented one by one. Again, the alignment unit begins with the first byte of the source packet. The EP_map is used to retrieve the data address of the start of reading of the data in the Clip AV stream file when the time stamp of the access point of the Clip is provided. EP_map is a list of login points extracted from the base stream and the transport stream. The EP_map has address information for retrieving a login point that should start decoding in the AV stream. One EP data in the EP_map is composed of a pair of PTSs and addresses in the AV stream of the Access Unit corresponding to the PTS. In AVC/H.264, data equivalent to one screen is stored in one Access Unit. Fig. 45 is a view showing an example of a Clip AV stream. The Clip AV stream of Fig. 45 is a video stream (Base view vide stream) containing a source packet identified by PID = X. The video stream distinguishes each source packet by the pID contained in the header of the transport packet in the source packet. In Figure 45, the source packet containing the month J leader of the picture in the source packet of the video stream is color-coded. The four corners of the unmarked color represent source packets containing data source packets that are not IW machine access points, or data that contains other streams. For example, 'the source packet number of the random bit (10) of the video stream that is divided by the video stream of PID=X is the source packet number of the χι, the system is located at the time axis of the PAV stream. on. Similarly, the source packet containing the random access IDR header 145441.doc •72· 201105108 is regarded as the source packet of the source packet number X2 and is placed at the location of PTS=pts(x2). on. Fig. 46 is a diagram conceptually showing an example of EP_map corresponding to the Clip AV stream of Fig. 45. As shown in Figure 46, EP_map includes stream_PID, PTS_EP_start, and SPN_EP_star't. stream_PID is the PID of the transport packet that carries the video stream. PTS_EP_start indicates the PTS of the Access Unit starting from the IDR that can be randomly accessed. SPN_EP_start is the address of the source packet containing the first byte of the Access Unit referenced by the value of PTS_EP_start. The PID of the video stream is stored in the stream_PID, and a table representing the PTS_EP_start^·SPN_EP_start^ stomach i% relationship is generated. Each resource tfl is EP_map_for_one_stream_PID() ° For example, the EP_map_for_one_stream_PID of the video stream of PID=x[ In 0, PTS=pts(xl) and source packet number XI, PTS=pts(x2) and source packet number X2, . . . , PTS=pts(xk) and source packet number Xk are respectively correspondingly described. Multiple processing is performed for each video stream of the same Clip AV stream, and such a table is also generated. The EP_map containing the generated table is stored in the Clip Information slot corresponding to the Clip AV stream. Figure 47 is a diagram showing an example of the data structure of the source packet indicated by SPN_EP_start. As mentioned above, the source packet is composed of a 148441.doc •73·201105108 with a 4-bit group header in the transmission packet of the 88-bit tuple. The transport packet portion includes a TP header and a payload portion. spN_Ep_start is the source code packet number of the source packet containing the Access 帛} byte starting from the self-service screen. In AVC/H.264, the Access Unit screen starts with the Au Delimiter (Access Unit Delimiter). Into. The delimiter is followed by SPS and PPS. The slice data of the IDR picture is stored in the leading part or the whole. The value of Payl〇ad_unit_start_indicator at the TP header of the transport packet indicates that a new packet can be started from the 5 source packet starting from the payload of the transport packet. Such an EP_map is prepared separately for the Base view video stream and the Dependent view video stream. Fig. 48 is a diagram showing a sub-table included in the EP_map. As shown in Fig. 48, EP_map is divided into Ep_c〇arse and EP_flne as subtables. The sub-form EP_c〇arse is a table for searching in rough units, and the sub-table EP_fine is a table for searching in more precise units. As shown in Fig. 48, the sub-table EP_fine is a table in which the login pTS_EP-fine is associated with the login SPN_EP_fine. In the sub-table, for each registration, for example, the top is listed as "〇", and the registration number is given in the upward order. In the sub-form EP-fine, the data width of the registration PTS-Ep_fine and the login SPN-EP_fine is 4-bit. The sub-form EP_coarse is a table corresponding to the login ref t〇_Ep_fine"d, the login 145441.doc •74·201105108 PTS_EP_coarse and the login SPN_EP_coarse. The data width of the registration ref_to_EP_fine_id, login PTS_EP_coarse, and login SPN_EP_ coarse is octet. The registration of the sub-form EP_fine includes the bit information of the LSB (Least Significant Bit) side of each of the PTS_EP_start and the login SPN_EP_start. Further, the registration of the sub-form EP_coarse includes the registration number in the table of the MSB (Most Significant Bit) side of the login PTS_EP_start and the login SPN_EP_start, and the sub-table EP_fine corresponding thereto. The registration number is the number of the registration in the sub-form EP_fine of the LSB side bit information extracted from the same data PTS_EP_start. Fig. 49 is a view showing an example of the format of the registered PTS_EP_coarse and the registered PTS_EP_fine. The PTS_EP_start data is registered to a value of 33 bits. If the bit of the MSB is the 32nd bit and the bit of the LSB is the 0th bit, the 14 bits from the 32nd bit to the 19th bit of the registered PTS_EP_start are used in the PTS_EP_coarse. The resolution can be retrieved in the range of 26.5 hours in 5.8 seconds by logging in PTS-EP_coarse. Further, in the PTS_EP_Hne, 11 bits from the 19th to the 9th bits of the PTS_EP_start are registered. The resolution can be retrieved in the range of 5.7 milliseconds to 11.5 seconds by logging in PTS_EP_fine. Furthermore, the 19th bit is commonly used in the login PTS_EP_coarse and the login PTS_EP_fine. Further, nine bits from the 0th bit on the LSB side to the 8th bit are not used. 145441.doc •75- 201105108 Figure 50 is a diagram showing an example of the format of login spN_EP_coarse and login SPN_EP_fine.

The SPN-EP_start data length is 32 bits. If the bit of the MSB is the 31st bit and the bit of the LSB is the third bit, then in the SPN-EP_coarse, the use of the self-registered spN-from the Chuanyuan Yuan to the 0th bit All bits. Further, in the login SPN_EP_fine, 丨7 bits from the registration SPN_Ep--from the 16th bit of (10) to the third bit are used. The manner in which the read start address is determined when random access is performed using EP_coarse and EP_fine will be described later. Regarding the Ep-map, for example, it is also described in Japanese Patent Laid-Open Publication No. Hei. No. Hei. [Usage 3] When decoding, as the value of P〇C (PlctUre Order Count) of the Dependent view video stream, the same value as the value of p〇c of the picture of the corresponding Base view video stream is used. P〇c is a value indicating the display order of the screen specified in the AVC/H.264 standard, and is obtained by calculation at the time of decoding. For example, the value of p〇c below the Base view vide stream is calculated by calculation, and the Base view video stream is output from the decoder in the order indicated by the obtained value. In addition, while outputting the wew vide〇 streaming picture, the corresponding Dependent view vide is outputted. Thereby, the value substantially the same as the value of p〇c of the picture of the Base view vide stream can be used as the value of the POC of the Dependent view vide. 145441.doc •76· 201105108 In addition, SEI (Supplemental) is attached to the data that constitutes the Base view video stream and the Dependent view video stream.

Enhancement Information, supplemental information). The SEI is an additional information defined by H.264/AVC and including auxiliary information related to decoding. In the Picture Timing SEI (picture timing SEI) which is one of the SEIs, the coded Picture Buffer (CPB) is included in the decoding. Time information such as the read time of the buffer, the read time from the DPB, and the like. Further, the SEI includes information on the display time, information on the screen structure, and the like. Fig. 51 is a diagram showing the configuration of an Access Unit. As shown in Fig. 51, the Access Unit of the Base view video including one face data of the Base view video stream has the same configuration as the Dependent Unit of the Dependent view video including the i picture data of the Dependent view video stream. One unit includes a delimiter indicating the boundary of each unit, SPS, PPS, SEI, and picture material. At the time of encoding, the Picture Timing SEI attached to the Base view video stream is used in conjunction with the Picture Timing SEI system attached to the Dependent view video stream. For example, when the encoding order of the Base view video stream is the first one, the Picture Timing SEI indicating that the reading time from the CPB is T1 is attached, and the encoding order of the Dependent view video stream is the first one. A Picture Timing SEI indicating that the readout time from the CPB is T1 is also added to the face. That is, in each of the Base view video Φ stream and the Dependent view video stream 145441.doc -77- 201105108, the Picture Timing S£I with the corresponding sides and the same inner valley is added in the coding order or the decoding order. . Thereby, the playback apparatus 1 can process the view component to which the same picture Timing SEi is attached as the corresponding vjew c〇mp〇nent in the decoding order.

Picture Timing includes the ^ system in the Base view in the basic stream of heart and vieW video, and is referenced by the video decoder 110 in the playback device. The video decoder 110 can identify the corresponding View component based on the resources contained in the basic stream. Further, the video decoder 11 can perform decoding processing in the correct decoding order based on the picture Timing SEI. 々 Since there is no need to refer to the PlayList for recognizing the corresponding view component, it is possible to deal with the problem that the System Layer or the Layer above causes a problem. Also, it is possible to implement a decoder installation that does not depend on the problematic layer. [Composition of Recording Device] Figure 5 2 shows the encoding of the base view vid stream and the Dependent view video according to the above-mentioned application, and the 4 view of the base view vid stream and the Dependent view video. A block diagram of a configuration example of a recording device in a recording medium. In the recording device 501 of Fig. 52, a stream of ~ Wang Feng·Base view video is generated and a stream of D1 view video is generated, and your helmet n ίτ Mj Dependent view video stream. That is, in the recording device 501, T + generation is explained with reference to FIG.

Depth information. As shown in Figure 52

The β if U 501 includes an information generating unit 5, an MVC 145441.doc • 78· 201105108 encoder 512, and a recording unit 513. The information generating unit 511 corresponds to the data encoder 315 of Fig. 29 described above, and the MVC encoder 512 corresponds to the video encoder 311 of Fig. 29. The L image data and the R image data are input to the MVC encoder 512. The information generating unit 5 11 generates a database material, which includes a playlist file and a Clip including an EP_map for Base view video.

Information file, and Clip Information file containing EP-map for Dependent view Wde. The information generating unit 511 generates the database data in accordance with the input of the recording device 5〇1 by the user (content creator). The information generating unit 5 11 outputs the generated database material to the recording unit 5 13 . Further, the information generating unit 511 generates additional information for Base view video such as SPS, PPS, and SEI in Fig. 51 added to each screen of the Base view vide, and SPS and PPS added to each screen of the Dependent view video. Additional information for Dependent view video such as SEI. The additional information for the Base view video generated by the afl generation unit 5 11 and the additional information for the Dependent view video respectively include the picture

Timing SEI. The information generating unit 511 outputs the generated additional information to the MVC encoder 512. The MVC encoder 512 encodes the L image data and the R image data according to the H.264 AVC/MVC profile standard, and generates the data of each frame of the Base view video obtained by encoding the image data, and the code image data. The information of each screen of the obtained Dependent view video. Further, the 'MVC encoder 5 12 generates a Base view video string by adding the additional information for the Base view video generated by the information generating unit 511 to the data of the 14544l.doc • 79- 201105108 of the Base view video. flow. Similarly, the MVC encoder 5 12 generates a Dependent view video stream by adding additional information 'for the Dependent view Video generated by the g-hole generating unit 511' to each of the screens of the Dependent view video. MVC encoder 5 12 will generate the generated Base view video stream with

The Dependent view video stream is output to the recording unit 513. The recording unit 513 records the library material supplied from the information generating unit 511 and the Base view video stream and the Dependent view video supplied from the MVC encoder 512 in a recording medium such as a BD. The recording medium on which the data is recorded by the recording unit 513 is provided, for example, as the optical disc 2 to the playback side. Further, in the recording unit 513, various processes are performed before the Base View video stream and the Dependent view video stream are recorded. For example, the following processing is performed: the Base view video stream and the Dependent view video stream are multiplexed into the same processing, or processed separately with other data into different TS processing; from the Access Unit of the Base view video Delete the processing of the MVC header; split the Base view video stream and the Dependent view video stream into the packetization processing of the source packet. Figure 53 is a block diagram showing an example of the configuration of the MVC encoder 512 of Figure 52. As shown in FIG. 53, the MVC encoder 512 includes a Base view. The heartbeat encoder 521 and the Dependent view video encoder 522. L image data is input to the Base view video encoder 52wDependent view vide〇 In the encoder 522, the R image data is input to the Dependent view vide〇 145441.doc -80- 201105108 encoder 522. The R image data can also be input to the Base View Wde〇 encoder 521 for encoding as a Base view video.

The Base view video encoder 521 encodes L image data in accordance with, for example, the h.264 AVC standard. Further, the Base view video encoder 52 1 adds an additional asset for the Base view video to each of the encoded pictures, and then outputs it as a Base view video stream.

The Dependent view video encoder 522 encodes the r image material in accordance with the L image data' and in accordance with the H.264 AVC/MVC profile standard. Further, the Dependent view video encoder 522 adds the additional information for the Dependent view video to each of the pictures obtained by the encoding, and outputs it as a Dependent view video stream. [Operation of Recording Apparatus] Here, the recording processing of the recording apparatus 501 will be described with reference to the flowchart of Fig. 54. In step S1, the information generating unit 5U generates additional information including the library data of the playlist file and the Clip Information file, and the respective images attached to the respective image data and the R image. The encoding process is performed by the MVC encoder 512 in step S2. The Base view video stream generated by the encoding process and the Dependent view video stream are supplied to the recording unit 53. In step S3, the recording unit 513 causes the recording medium to record the library data generated by the information generating unit 511 and the Base view video stream generated by the MVC encoder 512 and the Dependent view video stream. Thereafter, the process ends. 145441.doc •81 - 201105108 Next, the coding process performed in step S2 of Fig. 54 will be described with reference to the flowchart of Fig. 55. In step S11, the Base view video encoder 521 selects one of the input L images (one frame) as the face of the encoding target. In step S12, the Base view video encoder 521 determines whether or not the L image of the encoding target is encoded as a frame or an IDR picture. It is included in the number of the components that constitute the (a) solid GOP! When the encoding conditions such as the number of screens or the number of faces are used, the face type of the L image to be encoded is determined based on, for example, the position of the screen when arranged in the encoding order. When it is determined in step S12 that the encoding is a facet or an IDR face, then in step S13, the base view video encoder 521 determines the face type of the L image of the encoding target as an I picture or ID]R. Picture. In step S14, the Dependent view video encoder 522 detects one screen of the input R image corresponding to the L image whose screen type is determined in step S13 or the idr plane. As described above, when the respective faces are arranged in the display order and the coding order, the 匕 image and the R image at the same time and at the same position become the corresponding facets. In step S15, the Dependent view video encoder 522 determines the picture type of the detected Chinese image as the Anchor face. On the other hand, in step S12, it is determined that the [image is encoded as an I picture or an IDR face] is not in the step $16, Base

The VleW Vldeo encoder 521 determines the type of the face based on the position of the L image of the encoding object. In step S17, the Dependent view video encoder 522 detects one of the R images input by the 145441.doc • 82·201105108 and the picture type corresponding to the B image determined in step S16. In step S18, the Dependent view video encoder 522 determines the type of the L image output that can be selected as the encoding object, as the face type of the detected R image. In step S19, the Base view video encoder 521 encodes the L image of the encoding target in accordance with the determined face type '. Further, the Dependent view vide encoder 522 encodes the R image detected in step S14 or S17 in accordance with the determined type of face. In step S20, the Base view video encoder 521 adds the additional information to the picture of the encoded Base view video. Further, the Dependent view video encoder 522 attaches additional information to the top ten of the Dependent view video obtained by the stone horse. In step S21, the Base view video encoder 521 determines whether or not the L picture currently selected as the encoding target is the last picture. When it is determined in step S21 that the image currently selected as the encoding target is not the last image, the process returns to the screen of the switching target in step su, and the above processing is repeated. When it is determined in step S21 that the currently selected L picture is the last picture, the process returns to step S2' of Fig. 54 to perform the subsequent processing. By the above processing, the data of the L image and the data of the R image are encoded in such a manner that the encoded Base Wew vide stream and the Dependent view video stream have the same G0P structure. In addition, additional information of the same content may be added to the screen of Base View video and the corresponding Dependent 145441.doc -83 - 201105108 view video. [Configuration of Playback Apparatus] Fig. 56 is a block diagram showing an example of the configuration of a playback apparatus for playing back a recording medium on which data is recorded by the recording apparatus 5〇1. As shown in Fig. 56, the "playback device 5" 2 includes an acquisition unit 53i, a control unit 532, an MVC decoder 533, and an output unit 534. The acquisition unit 531 corresponds to, for example, the disk drive 52 of Fig. 20, and the control unit 532 corresponds to the controller 51 of Fig. 2A. The MVC decoder 533 is configured in correspondence with a portion of the decoding unit 56 of Fig. 20 . The acquisition unit 53 1 reads the data from the recording medium mounted on the playback device 5〇2 by the recording device 501 in accordance with the control of the control unit 532. The acquisition unit 53 1 outputs the library data read from the recording medium to the control unit 532, and outputs the Base view video stream and the Dependent view video stream to the MVC decoder 533. The control unit 523 controls the overall operation of the playback device 502 such as reading of data from the recording medium. For example, the control unit 532 reads the data from the recording medium by the control acquisition unit 53, and obtains the material of the database. Further, when the control unit 531 indicates the playlist for the 3D playback included in the acquired database material (the playlist whose SD-PL_type value is 〇1 in FIG. 13), the playlist is played. The middle · 田 ID ID ID ID ID ID ID ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ ΐ 取得 取得 取得 取得 Depend Depend Depend Depend Depend Depend Depend Depend Depend Depend Depend Depend The second component 532 controls the MVC decoder 533 to decode the Base view video stream and the Dependent view video stream. 145441.doc -84 - 201105108 The MVC decoder 533 is controlled by the control unit 532, and "view video" The stream is decoded by the Dependent view video stream. The MVC decoder 533 outputs the decoded data of the Base view video stream and the Dependent view Vldeo stream to the output unit 534. For example, the MVC decoder 533 follows the View-type (Fig. 14), the data obtained by decoding the Base view vide stream is used as the L image data 'and the data obtained by decoding the Dependent view vide〇 stream is output as the R image data, respectively. The β output unit 534 is to be used by the MVC decoder 533. The supplied L image data and R image data are output to the display 'and the L image and the R image are displayed. Fig. 57 is a block diagram showing a configuration example of the MVC decoder 533. As shown in Fig. 57, the 'MVR decoder 533' The system includes a CPB 541, a decoder 542, and a DPB 543. The CPB 541 includes a B video buffer 106 and a D video buffer 1 〇 8 of Fig. 22. The decoder 542 corresponds to the video decoder 110 'DPB 543 of Fig. 22 The DPB 151 of Fig. 22. Although not shown, a circuit corresponding to the switch 109 of Fig. 22 is provided between the CPB 541 and the decoder 542. The CPB 541 system 5 recalls the Base view video supplied from the picking unit 53 1 The data of the stream and the data of the Dependent view video stream. The data of the Base view video stream stored in the CPB541 is read by the decoder in the data unit constituting the i Access Unit. The Dependent view video memorized in the CPB541 The data of the stream is similarly read by the decoder 542 in the data unit constituting one Dependent Unit. The decoder 542 decodes the data read from the CPB 541 and decodes the Base view video and Dependent view. The data of I45441.doc -85- 201105108 is output to DPB543. DPB543 is the data supplied by decoder 542. The written data of Base view video and Dependent view video stored in DpB543 are decoded by decoding. When the subsequent pictures are sequentially decoded, the decoder 542 makes an appropriate reference. The data stored in each page of the DpB543 is output in accordance with the display time of each picture indicated by the Picture Timing SEI. [Operation of Playback Device] Here, the playback process of the playback device 5〇2 will be described with reference to the flowchart of Fig. 58. Furthermore, in FIG. 58, after the processing of the Base view video stream, the steps are represented by the Dependent view video stream processing, but the Base View Vide0 stream processing and the Dependent Wew Wde stream processing are appropriate. The ground is implemented in parallel. About streaming with Base view vide

The other flowcharts related to the processing of the Dependent view video stream are also the same. In step S31, the acquisition unit 531 reads the data from the δ recorded media installed in the playback device 5〇2. The acquisition unit 531 outputs the read database data to the control unit 532' and outputs the data of the Base view video stream and the Dependent view video stream to the Mvc decoder 533. In step S32, the MVC decoder 533 performs decoding processing. In step S33, the output unit 534 outputs the L image data and the R image data supplied from the MVC decoder 53 3 to the display, and displays the 1 image and the R image. Thereafter, the processing ends. Next, the decoding process performed by 145441.doc -86 - 201105108 in step S32 of Fig. 58 will be described with reference to the flowcharts of Figs. 59 and 60. In step S41, the CPB 541 is a data of the Base view video stream and the Dependent view video stream. The data stored in the CPB 541 is appropriately read by the control unit 53-2. In step S42, the control unit 532 detects the boundary of the Access Unit of the Base view video stream by referring to the information stored in the CPB 541. The detection of the boundary of the Access Unit is performed, for example, by detecting the Access Unit delimiter. The information from the boundary of a certain location to the next boundary becomes the data of one Access Unit. The HiIAccess Unit data contains information on the Base View videoii screen and additional information attached to it. In step S43, the control unit 532 determines whether or not the Picture Timing SEI is encoded (inclusive) in one Access Unit of the view video. When it is determined in step S43 that the Picture Timing SEI is encoded, then In step S44, the control unit 532 reads out the Picture Timing SEI. In step S45, the control unit 532 combines the extracted time (readout time) described in the read picture Timing SEI to make one of the detected boundaries.

The data of the Base vievv video screen in the Access Unit data is supplied from the CPB 541 to the decoder 542. On the other hand, when it is determined in step S43 that the Picture Timing SEI has not been encoded, then in step S46, the control unit 532 combines the system information (DTS) to make the boundary of the Access Un[t The data of the picture of the Base view video is supplied from the cpB 541 to the decoder 542. 145441.doc -87- 201105108 In step S47, the decoder 542 decodes the data supplied from the CPB 541. When decoding the Base view video, refer to the decoded face that is stored in the DPB543 as appropriate. In step S48, the DPB 543 memorizes the data of the Base view video obtained by decoding. In step S49, the control unit 532 calculates and stores the P0C of the decoded Base view video screen. In step S50, the control unit 532 detects the boundary of the Dependent Unit of the Dependent Wew video stream, and detects the Dependent Unit of the Dependent view video stream corresponding to the Access Unit of the Base view video stream in which the boundary is detected in step 842. In step S51, the control unit 532 determines that the boundary is detected.

Dependent view video 1 Dependent Unit Picture

Whether Timing SEI is coded. When it is determined in step S51 that the Picture Timing SEI is encoded, then the control unit 532 reads out the Picture Timing SEI in step S52. In step S53, the control unit 532 combines the extracted time described in the read Picture Timing SEI, so that the data of the Dependent view video in the data of the Dependent Unit in which the boundary is detected is supplied from the CPB541 to the decoding. 542. On the other hand, when it is determined in step S51 that the Picture Timing SEI is not encoded, in step S54, the control unit 523 combines the system information to detect the Dependent view in the data of one Dependent Unit of the boundary. The video screen information is supplied from the CPB 541 to the decoder 542. 145441.doc •88· 201105108 Furthermore, when the decoder for Base view video and the decoder for Dependent view video are respectively set in the MVC decoder 533, the information of the screen of the Dependent view video stored in the CPB541 is With

The data of the Base view video screen is supplied to the decoder for Dependent view video from the timing when the CPB541 is supplied to the decoder for Base Wew video. In step S55, the decoder 542 decodes the material supplied from the CPB 541. For the decoding of the Dependent view video, refer to the picture of the decoded Base view video and the Dependent view video in the DPB543. In step S56, the DPB 543 is stored by decoding.

Information on the Dependent view video. By repeating the above processing, the DPB 543 memorizes the picture of the plurality of Base view videos in which the POC value is calculated, and the corresponding Dependent view video.

The calculation of the p〇c value is not performed after the Dependent view video. In step S57, the control unit 532 causes the screen having the smallest P0C value in the picture of the Base view video stored in the DPB 543 to be output from the dPB 543, and causes the corresponding Dependent view video picture to be output from the DPB 543 at the same timing. The picture output from the DPB 543 is supplied to the output unit 534.

The output of Base View vide〇 is attached to this screen.

The picture Timing SEI case is combined with the display time described in the Picture Tirning SEI. On the other hand, when the picture SEI is not attached, it is combined with the display time i45441.doc -89 - 201105108 indicated by the system information (pTS). In step S58, the control unit 532 determines "_.

Whether the output of all screens of Dependent view video ends. When the control unit 532 determines in step S58 that the output of all the faces has not yet ended, it returns to step S41 and repeats the above processing. When it is determined in step (4) that the output of all the screens has ended, the process returns to step s32 of Fig. 58 to perform the subsequent processing. By the above processing, the G 〇 p structure can be encoded in the same manner, and the W (four) video stream and the Dependent view vide 〇 stream with the same additional information added to each side are decoded. Next, the processing of random access playback by the playback device 502 using £1>-map will be described with reference to the flowchart of Fig. 61. In step S71, the control unit 532 controls the acquisition unit 531 to read the Clip Informati〇n file of each of the Clip of the Base view video stream and the CUp of the Dependent view vide stream. Further, the control unit 532 acquires EP_map for Base view Vide0 and EP_map for Dependent vjew. As described above, EP_map is prepared with an EP map for Base view video and an EP map for Dependent view video. In step S72, the control unit 532 acquires a PTS indicating the start time of the random access playback based on the user's operation or the like. For example, when the self-selected single screen selects a chapter set in the video stream, the PTS of the selected chapter is obtained. In step S73, the control unit 532 determines the source packet number indicated by 145441.doc • 90-201105108 SPN_EP_start corresponding to the acquired playback start time ρτ§ by the EP_map for the Base view video. Further, the control unit 532 reads out the address on the Luncun recording medium on which the source packet identified by the determined source packet number is recorded, and sets it as the start address. For example, based on the 14-bit element on the MSB side of the 32-bit constituting the PTS, the EP_coarse which is the sub-table of the EP-map for Base view video is searched for and 'determines PTS_EP_c〇arse and the corresponding ref_to_EP_fine_id, SPN_EP_coarse . Further, based on the determined ref_to_EP_fine_id, the search is performed for EP_fine, and the registration PTS EP fine corresponding to the u-bit value from the 1st bit on the LSB side is determined. — _ Confirm the source packet number indicated by SPN_EP_coarse corresponding to PTS_EP_fine and read the address of the source packet identified by the source packet sequence number and determine it as the start address. Recording of each source packet The address on the media is determined by a rights system that manages the data recorded on the recording medium. In step S74, the control unit 532 determines the source packet number indicated by the SPN_EP_start corresponding to the obtained pTs of the playback start time by the EP_map of the Dependent view vide. The determination of the source packet number indicated by SPN_EP_start corresponding to pTS is also used to constitute

Dependent view video is used with the subform of EP_map. Further, the control unit 532 reads the address on the recording medium on which the source packet identified by the determined source packet number is recorded, and sets it as the start address. In step S75, the acquisition unit 53 reads the data of each source packet constituting the Base view vide stream from the read address 145441.doc -91 - 201105108 starting address set in step S73. Further, the acquisition unit 531 starts reading the data of each source packet constituting the Dependent view vide stream from the read start address set in step S74. The data of the Base view video stream and the video stream read out are supplied to the MVC decoder 533. The decoding is performed from the playback start position designated by the user by performing the processing described with reference to Figs. 59 and 60. In step S76, the control unit 532 determines whether or not to perform the search, that is, whether or not to instruct random access playback from another position, and when the determination is made, repeats the processing in and after step S71. When it is determined in step S76 that the situation of random play from another position is not indicated, the processing is ended. [Buffer Control Information] As mentioned above, in the Η.264 AVC/MVC profile standard, the base view video stream, which is the base video stream, and the base view video stream, are defined and encoded. The video stream is the Dependent view video stream. In the Η 264 AVC/MVC setting standard, the Base view video stream and the Dependent view video stream are allowed to exist as one video stream, and they are allowed to exist as independent video streams, respectively. Fig. 62A is a diagram showing a state in which a Base view video stream and a Dependent view video stream exist as one video stream. In the example of FIG. 62A, the Base view video stream and the Dependent 145441.doc -92·201105108 view video stream are respectively divided into each specific interval, and are mixed in each interval to form 1 Basic stream. In Fig. 62 A, the section indicated by the "π main B" text indicates the interval of the Base view video stream, and the section marked with the "D" character indicates the interval of the Dependent view video stream. Figure 62B is a diagram showing a state in which a Base view video stream and a Dependent view video stream exist as independent video streams, respectively. In the BD-ROM 3D standard, as shown in Fig. 62B, the Base view video stream and the Dependent view video stream are required to be recorded as separate independent streams, respectively, on the disc. Also, the Base view vide stream is required to be encoded by the H.264/AVC standard. The above limitation is for the BD player that does not support 3D playback to play only the Base view vide stream (melon play). Therefore, in the BD-ROM 3D standard, whether only the Base view video stream encoded with Η 264/Αν€ standard is played, or whether the Base view video stream and the Depen (ient view video stream) are played are required. The recording device side pre-encodes the stream 'to play correctly. The specific taxi must be pre-coded in such a way that no buffer underflow or overflow occurs. In the H.264/AVC standard, in order not to generate a buffer For example, in the bd_r〇m standard, it is assumed that only the decoding of the Base view video stream and the Base Wew video stream are combined with the Dependent view video stream. For the decoding, the buffer control information must be pre-coded in the stream. However, in the playback device supporting the BD-ROM 3D standard, there is a benefit of 145441.doc •93· 201105108 with a decoder for Base view video Do τλ weo _ stream and Dependent view video stream for decoder, and J. Use Base view video with Dependent view video. Use 2 oracles to cry, 隹 . 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 〜 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于The number of decoders is not specified in the quasi-medium. Therefore, in BD-ROM 3D selection Φ, ρ ^ μ knows that whether decoding is performed by one decoder or decoding by two decoders is required. The recording side pre-encodes the buffer control information in the stream and plays it in the positive direction. As described above, the buffer control information is encoded in the recording device as follows: 1. In the Base view Vide0 stream, only the playback is performed.仏% view νί&〇In the case of streaming, the value used to correctly play the above is encoded. 2. In the Dependent view video stream, the Dependent is played by the independent decoder (the decoder for Dependent view video). In the case of the view video stream, the value used to correctly perform the above playback is encoded. 3. In the Dependent view video stream, the Base view video stream and the Dependent view video stream are played together using one decoder. In the case of 'encoding the value used for the above playback correctly. [Specific example of encoding position] In the Base view video stream and Dependent view video stream, encode HR D (Hypothetica I Reference Decoder) parameters and max_dec_frame_buffering are used as buffer control information. 145441.doc -94- 201105108 The HRD parameters contain information indicating the maximum bit rate from the input of the CPB to the damper. It may also include information indicating the maximum bit rate of the input to the CPB, information indicating the buffer size of the CPB, and a flag indicating whether the HRD is a CBR (Constant Bit Rate). Max_dec_frame_buffering is information indicating the maximum number of sheets that can be memorized in the picture (reference picture) in the DPB. Figure 63 is a diagram showing an example of the coding position of the HRD parameters in the Base view video stream. As shown in FIG. 63, the HRD parameters are encoded as one piece of information of the SPS included in each Access Unit constituting the Base view video stream. In the example of FIG. 63, it is encoded as one piece of information of VUI (Video Usability Information) included in the SPS. The HRD parameters in Figure 63 represent the maximum bit rate of the input to the decoder when only the Base view video stream is played. When the bus between the CPB and the decoder is used to transmit only the Base view video stream data, the transfer rate is limited to the bit rate indicated by the HRD parameters. Further, the AUD of Fig. 63 corresponds to the AU delimiter described with reference to Fig. 51, and the Slice corresponds to the data of one screen included in the Access Unit of Fig. 63. Figure 64 is a diagram showing a description format of seq_parameter_set_data() (SPS) when the HRD parameters are encoded at the position shown in Figure 63. As shown in Figure 64, hrd_parameters〇(HRD parameters) is described in vui_parameters()(VUI) in seq_parameter_set_data(). 0 145441.doc -95- 201105108 Figure 6 5 shows the B ase view video string A diagram of an example of the encoding position of max_dec_frame_buffering in the stream. As shown in Fig. 65, max_dec_frame_buffering is also encoded as one of the SPSs included in each Access Unit constituting the Base view video stream. In the example of Fig. 65, it is encoded as one of the VUIs included in the SPS. @ 65 max_dec_frame_buffering#, Base view video The maximum number of pictures that can be memorized in the DPB after streaming. When one DPB is used to memorize the decoded picture of the Base view video stream, the number of pictures stored in the DPB is limited to the number of sheets indicated by max_dec_frame_buffering. Fig. 6 6 is a diagram showing a description format of seq_parameter_set_data() after encoding max_dec_frame_buffering at the position shown in Fig. 65. As shown in Figure 66, max_dec_frame_buffering is described in veq-parameters in seq_parameter_set_data(). Among them. Hereinafter, the HRD parameters encoded in the Base view video stream in the manner shown in Fig. 63 are appropriately referred to as the first HRD parameters. Further, max_dec_frame_buffering encoded in the Base view video stream in the manner shown in Fig. 65 is referred to as a first max_dec_frame_buffering. Fig. 67 is a diagram showing an example of the coding position of the HRD parameters in the Dependent view video stream. As shown in FIG. 67, the HRD parameters are encoded as 1 145441.doc -96-201105108 pieces of SubsetSPS included in each Dependent Unit constituting the Dependent view video stream. In the example of FIG. 67, the HRD parameters encoded as one piece of information of the SPS included in the SubsetSPS are encoded as one piece of information of the SPS, and the Dependent view video is played by the independent decoder to play the Dependent view video stream. The maximum bit rate of the input to the decoder. When the bus between the CPB and the independent decoder is used to transmit only the Dependent view video stream, the transfer rate is limited to the bit rate indicated by HRD parameters. Fig. 68 is a diagram showing the description format of the subset_seq_parameter_set_data() (SubsetSPS) after encoding the HRD parameters as one piece of information of the SPS. SubsetSPS is a description that expands the parameters of the SPS of H.264/AVC, and includes information indicating the dependencies between views. As shown in Fig. 68, hrd_parameters() is described in vui_parameters() in seq_parameter_set_data() in subset_seq_ parameter_set_data(). In the example of Fig. 67, HRD parameters are also encoded as MVC VUI Ext included in SubsetSPS. 1 piece of information. The HRD parameters encoding 1 message of MVC VUI Ext indicates that the maximum bit rate of the input of the solution is calculated by using one decoder to play the Base view video stream and the Dependent view video stream. When the bus between the CPB and a decoder is used for the transmission of the Base view video stream data and the Dependent view video stream data, the transmission rate is limited to the bit rate indicated by the HRD parameters. Fig. 69 is a diagram showing the description format of the subset_seq_parameter_set_data() after encoding the HRD parameters as one of the MVC VUI Ext 145441.doc •97·201105108 information. As shown in Figure 69, hrd_parameters() is described in mvc_vui_parameters_extension() (MVC VUI Ext) in subset-seq_ parameter_set_data(). Hereinafter, the HRD parameters (the left side of Fig. 67) encoded as one piece of information of the SPS in the Dependent view video stream in the manner shown in Fig. 67 are appropriately referred to as the second HRD parameters. Further, the HRD parameters (the right side of Fig. 67) encoded as one piece of information of the MVC VUI Ext in the Dependent view video stream are referred to as the 3rd HRD parameters. Fig. 70 is a diagram showing an example of the coding position of max_dec_frame_buffering in the Dependent view video stream. As shown in Fig. 70, max_dec_frame_buffering is encoded as one piece of SubsetSPS included in each Dependent Unit constituting the Dependent view video stream. In the example of Fig. 70, it is encoded as one piece of information of the SPS included in the SubsetSPS. The max_dec_frame-buffering code of one piece of information encoded as SPS indicates the maximum number of sheets that can be memorized in the DPB after playing the Dependent view video stream with an independent decoder. When one DPB is used to memorize a decoded picture of a Dependent view video stream, the number of sheets stored in the DPB is limited to the number of sheets represented by max_dec_frame_buffering. Figure 71 is a diagram showing the description format of the sub_seq_parameter_set_data() format of max_dec_frame_buffering as one of the SPS information, 145441.doc -98- 201105108. As shown in Fig. 71, max_dec_frame_buffering is described in vui_parameters() in seq_parameter_set_data() in subset_seq_parameter_set_data(). In the example of FIG. 70, the max_dec_frame_buffering code is also encoded as the information of the SEI. The max_dec_frame_buffering means that the Base view video stream and the Dependent view video stream are played together by one decoder. The maximum number of frames that can be memorized in the DPB. When 1 DPB is used for the decoding of the decoded picture of the Base view video stream and the decoded picture of the Dependent view video stream, the number of pictures stored in the DPB is limited to the number of sheets represented by max_dec_frame_buffering. . Fig. 72 is a diagram showing a description format of sei_message() (SEI) after encoding max_dec_frame_buffering as one piece of information of the SEI. As shown in Fig. 72, max_dec_frame_buffering is described in view_scalability_info() (view scalability information SEI) in sei_message(). Hereinafter, the max_dec_frame_buffering (the left side of FIG. 70) which is encoded as one of the SPS in the Dependent view video stream in the manner shown in FIG. 70 is referred to as the second max-dec_frame_buffering °, and will be in the Dependent view video. The max_dec_frame_buffering (on the right side of FIG. 70) of one piece of information encoded as SEI in the stream is referred to as 3max_dec_frame_buffering. 145441.doc -99- 201105108 As described above, in the Base view video stream and the Dependent view video stream, each of the three types of HRD parameters is encoded with dec-frame buffering. [Configuration of Apparatus] The recording apparatus for recording the data including the buffer control information in the BD has the same configuration as that of the recording apparatus 5〇1 shown in Fig. 52. Further, the playback device for playing the data recorded in the BD has the same configuration as the playback device 502 shown in Fig. 56. Hereinafter, the configuration of the recording device and the playback device that use the buffer control information will be described with reference to the configurations of Figs. 5 and 25. Descriptions overlapping with the above description will be omitted as appropriate.

The information generating unit 511 of the recording device 501 generates the database material including the playlist file and the Clip Information file, and generates an additional resource for the Base view video and an additional 5 holes for the Dependent view video. The additional information used in the Base view video includes the 1st hrd parameters and the 1st max_dec_frame_buffering. Further, the additional information for the Dependent view video includes the 2nd and 3rd HRD parameters, and the 2nd and 3rd max_dec_frame_buffering. The information generating unit 5 11 outputs the generated database material to the recording unit 5 13 ' and outputs the additional information to the μVC encoder 5 12 . The MVC encoder 5 12 encodes the L image data and the R image data according to the 264.264 AVC/MVC profile standard, and generates data and codes of the respective frames of the Base view video obtained by encoding the image data. r The data of the Dependent view video obtained from the image data. • 00· 145441.doc 201105108 Further, the MVC encoder 512 generates a Base view by adding an additional asset δΗ* ' to the Base View Wdeo generated by the information generating unit 511 to the data of each of the Base view videos. Video stream. In the Base view video stream, the first HRD parameters are encoded at the position shown in FIG. 63. The first max_dec_frame_buffering is encoded at the position shown in FIG. 65. Similarly, the MVC encoder 512 is used by the Dependent view. A Dependent view video stream is generated by adding additional information for the Dependent view video generated by the information generating unit 5 to the data of each screen of the video. In the Dependent view video stream, the second and third HRD parameters are encoded at the position shown in Fig. 67, and the second and third max_dec_frame_buffering are encoded at the position shown in Fig. 70. The MVC encoder 512 outputs the generated Base vievv video stream and the Dependent view video stream to the recording unit 5 13 . The recording unit 513 records the library data supplied from the information generating unit 511 and the Base view video stream and the Dependent view video supplied from the MVC encoder 512 in the BD. The BD which has recorded the information by the recording unit 513 is supplied to the playback device 5 〇2. The acquisition unit 531 of the playback device 502 reads data from the BD recorded by the recording device 5〇1 and mounted in the playback device 502. The acquisition unit 53 1 outputs the database data read from the BD to the control unit 532, and outputs the Base view video stream and the Dependent view video to the MVC decoder 533. The control unit 532 controls the overall operation of the playback device 145441.doc • 101 - 201105108 502 such as reading of data from the recording medium. For example, when the control unit 532 plays only the Base view video stream, the first HRD parameters and the first max_dec frame-buffering are read from the Base view video stream. The control unit 532 controls the decoding of the Base view video stream by the MVC decoder 533 based on the read resource sfl '. The control unit 532 is configured to stream the Base view video stream and the Dependent view video (3D playback). In the case, when the MVC decoder 533 has one decoder, the third HRD parameters and the third max_dec_frame-buffering are read out from the Dependent view video stream. The control unit 532 controls the Mvc decoder 533 to decode the Base view video stream and the Dependent view video stream based on the read information. The MVC decoder 533 decodes only the Base view video stream or the Base view video stream and the Dependent view video stream according to the control of the control unit 532. The MVC decoder 533 outputs the decoded data to the output unit 534. The output unit 534 outputs the image supplied from the MVC decoder 533 to the display, and displays a 2D image or a 3D image. [Operation of Device] Here, the recording process of the recording device 5〇1 will be described with reference to the flowchart of Fig. 73. In step S101, the information generating unit 511 generates the database material and the additional information including the buffer control information added to the respective writings of the Base view video and the Dependent view video. 145441.doc -102· 201105108 In step S102, the encoding process is performed by the MVC encoder 512. Here, the same processing as that described with reference to Fig. 55 is performed. The buffer control information generated by step 8101 is added to each side of Base vjew video and Dependent view video. Generated by encoding processing

The Base view video stream and the Dependent view video stream are supplied to the recording unit 5 13 . In step S103, the recording unit 513 causes the BD to record the database data generated by the information generating unit 511 and the data generated by the Mvc encoder 512.

Base View video Streaming with Dependent View video. Thereafter, the processing ends. Next, the playback processing of the playback device 5〇2 will be described with reference to the flowchart of Fig. 74. In step S111, the acquisition unit 531 reads data from the BD installed in the playback device 502. The acquisition unit 53 outputs the read database data to the control unit 532, and outputs the data of the Base Wew video stream and the Dependent view video stream to the MVC decoder 533 when, for example, 3D playback is performed. . In step S112, the control unit 532 reads the buffer control information from the stream data read and supplied from the & BD, and sets the parameters in the MVC decoder 533. As described below, the stream as the source of the buffer control information is changed according to the stream read from the BD or according to the configuration of the decoder 533. In step S113, the MVC decoder 533 The decoding process described with reference to FIGS. 59 and 60 is performed in accordance with the parameters set by the control unit 532. 145441.doc 201105108 In step S114, the output unit 534 is an image obtained by decoding the MVC decoder 533. The data is output to the display. The processing is terminated. [Specific example of parameter setting] A specific example of setting the parameters using the buffer control information. Here, 'Enable the input to the decoder after playing only the Base view video stream. The maximum bit rate is 40 Mbps » and 'uses to play with an independent decoder

Dependent view video The maximum bit rate of the input to the Dependent view video decoder is 40 Mbp after streaming. After using the decoder and playing the Base view video stream and the Dependent view video stream, the maximum bit rate of the input to the decoder is 6 〇 Mbps. In this case, in the recording device 501, the values of the first HRD parameters and the values of the second HRD parameters are all coded to represent values of 4 〇 Mbps. As the value of the third HRD parameters, the code represents a value of 60 Mbps. In addition, the maximum number of sheets that can be memorized in the DPB after playing only the Base view video stream is four. The maximum number of sheets that can be memorized in the DPB after playing the Dependent view video stream using an independent decoder is four. The maximum number of sheets that can be memorized in the DPB after playing the Base view video stream and the Dependent view video stream by one decoder is six. In this case, in the recording device 501, the value of the first max_dec_frame-buffering and the value of the second max_dec_frame_buffering are both coded to represent four values. As the value of the third max_dec_frame_buffering, the code represents the value of six sheets. 145441.doc -104· 201105108 FIG. 75 is a diagram showing an example of a case where only the Base view video stream is decoded in the mvc decoder 533 having one decoder. In this case, as shown in FIG. 75, the control unit 532 encodes the code into Base Vlew vide. The 1st hrD parameters in the stream are read out with the 1st max_dec_frame_buffering. Streaming in Base view video

The buffer control information D1 indicated by a diagonal line indicates the first hRD parameters and the first max_dec_frame_buffering. Further, the control unit 532 sets the maximum bit rate of the input from the CPB 541 to the decoder sc to 4 Mbps, and sets it based on the first Hrd parameters. For example, the maximum bit rate is set by ensuring that the bandwidth of the bus bar between the CPB 541 and the decoder 542 is 4 Mbps. Further, the control unit 532 sets the maximum number of pictures that can be stored in the DPB 543 to four sheets and sets them based on the first max_dec_frame_buffering. For example, the maximum number of sheets that can be memorized is set by ensuring that the area of the decoded picture can be memorized in the memory area of the DPB 543. By this, it is conceivable to decode the Base view video stream using one decoder on the recording side. If the Base view video stream is encoded on the recording side in such a manner that decoding is possible within the constraint range, the buffering failure on the playback side can be prevented. Figure 76 is a diagram showing an example of a case where a Base view video stream and a Dependent view video stream are decoded in an MVc decoder 533 having one decoder. In this case, as shown in Fig. 76, the third HRD parameters encoded in the Dependent view video stream and the 145441.doc • 105 - 201105108 3 max_dec_frame_buffering are read by the control unit 532. The buffer control information D2 indicating the slanted line on the Dependent view video stream indicates the second HRD parameters and the second max_dec_frame_buffering. Further, the buffer control 寊§fl D3 indicates that the third HRD parameters and the third max_dec_frame_buffering ° and the maximum bit rate of the input from the CPB 541 to the decoder 542 are 60 Mbps by the control unit 532. Set based on the 3rd HRD parameters. Further, the control unit 532 sets the maximum number of sheets that can be memorized in the DPB 543 to six sheets and sets them based on the third max_dec_frame_buffering. In this way, the decoding of the stream and the Dependent view video stream can be performed on the basis of the assumption that the B a s e v i e w v i d e 〇 stream. If the Base view vide stream and the Dependent view video stream are encoded on the recording side in a manner that can be decoded within the constraint, the buffer failure on the playback side can be prevented. 77 is a block diagram showing another configuration example of the MVC decoder 533. The same components as those shown in Fig. 57 in the configuration shown in Fig. 7 are denoted by the same reference numerals. Repeated descriptions will be omitted as appropriate. In the example of Fig. 77, two decoders of the decoder 542_1 and the decoder 542_2 are provided. The decoder 542-1 is a decoder for Base view vide, and the decoder 542-2 is a solution for Dependent view video. The data of the Base view vide stream in the CPB 541 is read by the decoder 542 1 in the data unit constituting one Access Unit. Further, 145441.doc •106- 201105108 The Dependent view video stream stored in the CPB 541 is read by the decoder 542-2 by the data unit constituting one Dependent Unit. The decoder 542-1 decodes the data read from the CPB 541 and outputs the data of each side of the decoded Base view video to the DPB 543. The decoder 542-2 decodes the data read from the CPB 541 and outputs the data of each picture of the decoded Dependent view video to the DPB 543. In this manner, the case where the MVC decoder 533 has two decoders will be described. Fig. 78 is a diagram showing an example of a case where only the Base view video stream is decoded in the MVC decoder 533 having two decoders. In this case, as shown in Fig. 78, the first HRD parameters and the first max_dec_frame_buffering encoded in the Base view video stream are read by the control unit 532. Further, the control unit 532 sets the maximum bit rate from the CPB 541 to the decoder 542 to 40 Mbps, and sets it based on the first HRD parameters. Further, the control unit 532 sets the maximum number of sheets that can be stored in the DPB 543 to four, and sets them based on the first max_dec_frame_buffering. In Fig. 78, the decoder 542-2 is indicated by a broken line and is not yet processed in the decoder 542-2. Figure 79 is a diagram showing an example of the case of decoding a Base view video stream and a Dependent view video stream in an MVC decoder 533 having two decoders 145441.doc -107 - 201105108. In this case, as shown in FIG. 79, the first HRD parameters encoded in the Base view video stream, the second HRD parameters encoded in the Dependent view video stream, and the third max_dec_frame buffering error are controlled by the control unit. Read out 5 3 2 . Further, the control unit 532 sets the maximum bit rate of the input from the CPB 541 to the decoder 542-1 to 40 Mbps ' and sets it based on the first HRD parameters', and inputs the input from the CPB 541 to the decoder 542-2. The maximum bit rate is 40 Mbps ' and is set based on the second HRD parameters. Further, the control unit 532 causes the maximum number of sheets that can be memorized in the DPB 543 to be six sheets and enters the third max_dec_frame_buffering based on the third max_dec_frame_buffering. The Base view video and the Dependent view video are commonly used. The DPB543 '' is therefore used as the third max-dec_frame buffering as a parameter for setting the maximum number of sheets that can be memorized in the DPB 543. Fig. 80 is a diagram showing another example of the case where the Base view video stream and the Dependent view video stream are decoded in the MVC decoder 533 having two decoders. In the MVC decoder 533 of Fig. 80, the CPB541 and the DPB 543 are also provided with a Base view video user and a Dependent view vide user, respectively. In this case, the first HRD parameters and the first max-dec_frame_buffering coded in the Base viexv video stream are read as shown in Fig. 80 by the control unit 532. Further, the second HRD parameters and the second max_dec_frame_buffering 145441.doc •108-201105108 encoded in the Dependent view vide〇 stream are read by the control unit 532. The control unit 532 sets the maximum bit rate of the CPB541-1 input from the Base view video, that is, the CPB541-1, to the decoder 542-1 to 40 Mbps, and sets it based on the first HRD parameters. Further, the maximum bit rate of the input from the CPB54, which is the CPB for the Dependent view video, to the decoder 542-2 is 40 Mbps, and is set based on the second HRD parameters. Further, the control unit 532 sets the maximum number of sheets that can be stored in the DPB543-1, which is a DPB for Base view video, to four, and sets it based on the first max_dec_frame_buffering. Further, the maximum number of pictures that can be memorized in the DPB of the Dependent view video, that is, the DPB543-2, is four, and is set based on the second max_dec_frame_buffering. Figure 81 is a diagram showing still another example of the case where the Base view video stream and the Dependent view video stream are decoded in the MVC decoder 533 having two decoders. In the MVC decoder 533 of FIG. 81, the CPB is provided with a Base view video user and a Dependent view video user, but the DPB is commonly used in the Base view video and the Dependent view video. In addition, the CPB for the Base view video, that is, the data transfer between the CPB541-1 and the decoder 542-1, and the CPB for the Dependent view video, that is, the data transfer between the CPB541-2 and the decoder 542-2, are via the same bus. get on. In this case, the third HRD parameters and the third max_dec_frame_buffering 14544 编码, doc - 109 - 201105108 encoded in the Dependent view video stream are read by the control unit 532 as shown in Fig. 81. Further, the control unit 532 causes the data transfer between the CPB 544-1 and the decoder 542-1 and the maximum bit of the bus used for data transfer between the CPB 54 1-2 and the decoder 542-2. The rate is 60 Mbps and is set based on the 3rd HRD parameters. Further, the control unit 532' sets the maximum number of pictures that can be stored in the DPB 543 to six sheets and is set based on the third max_dec_frame_buffering. [Verification device] Fig. 82 is a view showing a verification device for verifying whether or not the video stream recorded in bd by the recording device 5〇1 can be correctly played back in the playback device 502. The verification device 551 of Fig. 82 includes a computer. The video stream read from the BD is input to the verification device 551. The first HRD parameters and the first max_dec_frame-buffering are encoded in the Base view video stream input to the verification device 551 as a video stream. In the Dependent view video stream, the second and third HRD parameters are encoded, and the second and third max_dec_frame_buffering are used in the verification device 5, and the specific processing is performed by using a CPU (Central Processing Unit). The program is realized by the control unit 551A. The control unit 551A verifies whether or not the input video stream can be correctly played back in the playback device 502, and outputs the information indicating the verification result. The verification result is displayed, for example, on the display, and is confirmed by the user who authenticates using the verification device 145441.doc • 110· 201105108 551. Further, in the verification device 551, HRD (Hypothetical Reference Decoder) is realized by executing a specific program by the CPU. The HRD system virtually reproduces the MVC decoder 533 of the playback device 502. The functional configuration of the HRD is shown in Fig. 83. As shown in FIG. 83, the HRD 561 includes a CPB 571, a decoder 572, and a DPB 573. CPB571 is the data of the Base view video stream input and the Dependent view video stream input. The data of the Base view video stream stored in the CPB 571 is read by the decoder 572 in units of information constituting one Access Unit. The data of the Dependent view video stream stored in the CPB 571 is similarly read by the decoder 572 in the data unit constituting one Dependent Unit. The decoder 572 decodes the data read from the CPB 571, and outputs the decoded data of each of the Base view video and the Dependent view video to the DPB 573. The DPB 573 is a memory that is supplied by the decoder 573. The information of each of the Base view video and the Dependent view video stored in the DPB 573 is outputted by the display time of each face indicated by the Picture Timing SEI. Explain the specific example of verification. Similarly to the above example, the codes represent values of 40 Mbps, 40 Mbps, and 60 Mbps, respectively, as values of the first, second, and third HRD parameters. Further, the values of 4, 4, and 6 sheets are respectively encoded as the values of the first, second, and 145441.doc -111 - 201105108 3rd max_dec_frame_buffering. Fig. 83 is a diagram showing an example of a case where only the Base view video stream is decoded. In this case, as shown in FIG. 83, the first HRD parameters and the first max dec_frame encoded in the Base view vide stream are read by the control unit 551A. The portion 5 5 1A 'and the maximum bit rate of the input from the CPB 5 71 to the decoder 572 is 4 〇 Mbps ' and is set based on the ith H rd line. Further, the control unit 551A can be memorized in the 〇ρΒ573 The maximum number of sheets of the screen is four sheets and is set based on the first max+dec^frameD buffering. In this state, the control unit 55 1A verifies whether the decoding of the Base view video stream can be correctly performed, and The information indicating the verification result is output. When it is judged that the decoding can be correctly performed, the input Base view vide stream can be based on the first HRD parameters and the first max_dec_frame buffered in the encoding, with reference to FIG. 75 and FIG. 78. Fig. 80 shows the flow of correct playback in the manner described in Fig. 80. Fig. 84 is a diagram showing an example of the case where only the Dependent view video stream is decoded by the decoder for Dependent view video. 'coding The second HRD parameters and the second max_dec_frame_buffering in the Dependent view video string W are read by the control unit 55. The 'from the CPB571 to the decoder 572' is also 'by the control unit 5 5 1A ' The maximum bit rate of the input is 40 Mbps, and is set based on the second HRD parameters 145441.doc • 112· 201105108. Further, the maximum number of pictures that can be memorized in DpB573 is 4 by the control unit 551A. The setting is based on the second max_dec_frame_buffering. In this state, the control unit 551A verifies whether or not the Dependentviewvideo stream can be decoded correctly, and outputs information indicating the result of the verification. When it is judged that the decoding can be performed correctly, The input Dependent view video stream becomes a string that can be correctly played by the decoder using the Dependent view video in the manner described with reference to FIG. 8B based on the second HRD parameters and the second max dec-frame buffering encoded therein. Stream. In addition, Base view video stream is required to decode the Dependent view video stream. The decoded picture data of the Base view video stream is also input to the decoder 572 of FIG. 84 and used for decoding the Dependent view video stream. 85 is a diagram showing an example of a case where a base view video stream and a Dependent view video stream are decoded by one decoder. In this case, as shown in FIG. 85, it is encoded in a Dependent view video stream. The third HRD parameters and the third max_dec_frame_buffering ' are read by the control unit 551A. - By the control unit 551A, the maximum bit rate from the CPB 571 to the decoder 572 is 60 Mbps, and is set based on the third HRD parameters. Further, by the control unit 551A, the number of sheets that can be memorized in the DPB 573 is six sheets, and is set based on the third max_dec_frame_buffering 145441.doc - 113 - 201105108. In this state, the control unit 551A verifies whether or not the Base view video stream and the Dependent vUw Wde〇 stream can be correctly decoded, and outputs information indicating the result of the verification. When it is judged that the decoding can be correctly performed, the input Base view video stream and the Dependent Wew stream become a string that can be correctly played back in the manner described with reference to FIG. 76 based on the third HRD parameters and the third max-dec_frame_buffering. flow. [Location of view_type] In the above, the view-type indicating whether the Base Wew video stream is a stream of L images or a stream of R images will be described in the PlayList, but in the manner described with reference to FIG. It can also be described in other locations. For example, it is also conceivable to process the Base view video stream and the Dependent view video stream to the same D, or to process the different TSs and transmit them via radio waves or the network. In this case, the view_type is described, for example, in PSI (Program Specific Information) as a transmission control information, a bite Base view video stream, or a Dependent view video stream (basic stream). Fig. 86 is a diagram showing an example of a case where view_type is described in a PMT (Program Map Table) included in PSI (Program Specific Information). As shown in Fig. 86, the MVC_video_stream_descriptor() can be redefined as the descriptor (descriptor) for MVC, and the View_type is described in MVC_video_stream 14544 丨.doc 114· 201105108 descript〇r(). Furthermore, for example, the allocation 65 is used as the descriptor_tag value 0 in the playback device 1 that receives the TS, and based on the viewjype value described in the PMT, the multiplex processing is determined to be the Base view Wde in the TS as the L image. The processing described with reference to Figs. 24 and 26 is performed by streaming or streaming the R picture and switching the output destination of the data of the decoding result. The view_type may not be described in the PMT, but the view_type is described in other positions such as the SiT (Selection Information Table). Fig. 87 is a diagram showing an example of the case where the vieW-type is described in the basic stream. As shown in Fig. 87, 'view-type' can also be described in se; [MvC_video_stream" nf()G. As described above, the SEI is attached to the additional information constituting each of the picture data of the Base view video stream and the Dependent view video stream. The SEI containing the view-type is attached to each of at least one of the Base View video stream and the Dependent view video stream. Read the SEI playback device! In the above, based on the view_type value described in sei, it is determined whether the Base view vide stream is a stream of L images or a stream of R images and the output destination of the data of the decoding result is switched. The processing illustrated in Figs. 24 and 26 is as follows. The above series of processing can be performed by hardware or by software. When a series of processing is executed by software, the program constituting the soft 145441.doc -115-201105108 is installed in a computer or a general-purpose personal computer or the like assembled in a dedicated hardware. Figure 88 is a block diagram showing an example of the configuration of a computer hardware that executes the above-described series of processes by a program. CPU (Central Processing Unit) 701 ^ R0M (Read Only Memory) 7〇2, and RAM (Rand〇m Access

Memory, random access memory) 7〇3 are connected to each other by bus bars 7〇4. An input/output interface 7〇5 is further connected to the bus 704. An input unit 7 (10) including a keyboard, a mouse, and the like, and an output unit 7〇7 including a display, a speaker, and the like are connected to the input/output/1 surface 705. Further, a memory unit 〇8 including a hard disk or a non-volatile memory, a communication unit 709 including a network interface, and a drive unit 710 for driving the removable medium 7 连接 are connected to the bus bar 7〇4. In the computer configured as above, cpU7GH|; 'for example, the program stored in the memory unit 7 G 8 is loaded into the RAM 703 via the input output interface 7 q 5 and the bus bar 704 to be burgundy, product, du &gt The hyperthyroidism carries out the above-mentioned series of rules. The program to be bound by the CPU 701 is recorded, for example, in a portable medium, or is provided via a wired or wireless transmission medium such as a regional network, an Internet, or a digital broadcast, and is installed in the storage unit 〇8. Further, the program executed by the computer may be a program that is processed in time series in accordance with the sequence described in the specification, and may be a program that is processed in parallel or at a timing required for calling. The present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the spirit and scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a view showing an example of a configuration of a playback system including a playback device of the present invention. Fig. 2 is a view showing an example of shooting. Fig. 3 is a block diagram showing an example of the configuration of an MVC encoder. Fig. 4 is a view showing an example of a reference image. Fig. 5 is a view showing a configuration example of ts. Fig. 6 is a view showing another configuration example of the TS. 7A and 7B are views showing still another example of the configuration of ts. Fig. 8 is a view showing an example of management of an AV stream. Figure 9 is a diagram showing the structure of Main Path and Sub Path. Fig. 1 is a diagram showing an example of a management structure of a file recorded on a disc. Figure 11 is a diagram showing the syntax of a PlayList file. Figure 12 is a diagram! A diagram of the usage of reserved-f〇r-future-Use in i. Fig. 13 is a view showing the meaning of the value of 3D_PL_type. Fig. 14 is a view showing the meaning of the value of vieW-type. Fig. 15 is a view showing the syntax of the PlayList〇 of Fig. 11; Fig. 16 is a view showing the syntax of SubPath() of Fig. 15. Figure 17 is a diagram showing the syntax of SubPlayltem(i) of Figure 16 . Fig. 18 is a diagram showing the syntax of Playltem() of Fig. 15. Fig. 19 is a view showing the syntax of STN_table() of Fig. 18. 145441.doc -117- 201105108 FIG. 20 is a block diagram showing a configuration example of a playback device. Fig. 21 is a view showing an example of the configuration of a decoding unit of _. Fig. 22 is a view showing the configuration of video stream processing. Fig. 23 is a view showing the configuration of video stream processing. Fig. 24 is a view showing another configuration for performing video stream processing. Fig. 25 is a diagram showing an example of an AccessUnit. Fig. 26 is a view showing another configuration for performing video stream processing. Fig. 27 is a view showing the configuration of the combining unit and its front stage. Fig. 28 is a view showing another circle in which the combining portion and the front portion thereof are constructed. 29 is a block diagram showing a configuration example of a software creation processing unit. Fig. 3 is a view showing each configuration example including a software creation processing unit. Figure η is a view showing an example of the configuration of a 3D vide〇Ts generating unit provided in the recording device. Fig. 32 is a view showing another configuration example of the 3D Wde ts generating unit provided in the recording apparatus. Fig. 33 is a view showing still another example of the configuration of the 3D virtual ts generating unit provided in the recording apparatus. Fig. 34 is a view showing the configuration of the playback device side for decoding Access Unh. Figure 35 is a diagram showing the decoding process. Figure 36 is a diagram showing the structure of a closed GOP. Figure 37 is a diagram showing the structure of the Open GP. Fig. 38 is a view showing the maximum number of frames and columns in the GOP. Figure 39 is a diagram showing the structure of a closed GOP. 145441.doc •118· 201105108 Figure 40 is a diagram showing the structure of the Open GOP. Fig. 41 is a diagram showing an example of a decoding start position set in the EP_map. Figure 42 is a diagram showing the problem that occurs when the GOP structure of the Dependent view video is not defined. Figure 4 3 shows a diagram of the concept of faceted search. Figure 44 is a diagram showing the AV stream structure recorded on a compact disc. Fig. 4 is a diagram showing an example of a Clip AV stream. Fig. 46 is a diagram conceptually showing EP_ma.p corresponding to the Clip AV stream of Fig. 45. Figure 47 is a diagram showing an example of the data structure of the source packet indicated by SPN_EP_start. Fig. 48 is a diagram showing a sub-table included in the EP_map. Fig. 49 is a view showing an example of the format of the registered PTS_EP_coarse and the registered PTS_EP_fine. Fig. 50 is a view showing an example of the format of the login SPN_EP_coarse and the login SPN_EP_fine. Fig. 51 is a view showing the configuration of an Access Unit. Fig. 52 is a block diagram showing an example of the configuration of a recording apparatus. Figure 53 is a block diagram showing an example of the configuration of the MVC encoder of Figure 52. Figure 54 is a flow chart showing the recording process of the recording device. Figure 55 is a flow chart for explaining the encoding process performed in step S2 of Figure 54. Fig. 56 is a block diagram showing an example of the configuration of a playback apparatus. Figure 57 is a block diagram showing an example of the configuration of the MVC decoder of Figure 56. Figure 58 is a flow chart showing the playback processing of the playback device. 145441.doc .119 - 201105108 FIG. 59 is a flow chart for explaining the decoding process performed in step S32 of FIG. Figure 60 is a flow chart showing the decoding process performed in step S32 of Figure 58 following Figure 59. Figure 61 is a flow chart showing the random access playback process of the playback device. 62A and 62B are diagrams showing states of a Base view video stream and a Dependent view video stream. Figure 63 is a diagram showing an example of the coding position of the HRD parameters in the Base view video stream. Fig. 64 is a view showing the format of the description when the HRD parameters are encoded at the position shown in Fig. 63. Fig. 65 is a diagram showing an example of the encoding position of max-dec_frame_buffering in the Base view video stream. Fig. 66 is a view showing a description format when max_dec_frame_buffering is encoded at the position shown in Fig. 65. Fig. 67 is a diagram showing an example of the coding position of the HRD parameters in the Dependent view video stream. Fig. 68 is a diagram showing the description format when the HRD parameters are encoded at the position shown in Fig. 67. Fig. 69 is a view showing another description format when the HRD parameters are encoded at the position shown in Fig. 67. Figure 70 is a diagram showing an example of the encoding position of max_dec frame_buffering in the Dependent view video stream. Fig. 71 is a diagram showing the description format of the frame at the position shown in Fig. 7〇 at the position of the mother max dec 145441.doc -120·201105108 frame_buffering. Figure 72 is a diagram showing other description formats when max_dec frame_buffering is encoded at the position shown in Figure 70. Figure 73 is a flow chart showing the recording process of the recording device. Fig. 74 is a flow chart showing the playback processing of the playback apparatus. Fig. 75 is a view showing an example of parameter setting. Fig. 76 is a view showing another example of parameter setting. Fig. 77 is a block diagram showing another configuration example of the MVC decoder. Fig. 78 is a view showing another example of parameter setting. Fig. 79 is a view showing an example of parameter setting. Fig. 80 is a view showing another example of parameter setting. Fig. 8 is a view showing still another example of parameter setting. Figure 82 is a diagram showing the verification device. Fig. 83 is a view showing the functional configuration of the HRD. Fig. 8 is a diagram showing a verification example. Fig. 85 is a view showing another example of verification. Fig. 86 is a diagram showing a description example of the view_type. Fig. 87 is a view showing another example of the description of the view_type. Figure 88 is a block diagram showing an example of the hardware configuration of a computer. [Description of main component symbols] 1 Playback device 2 Disc 3 Display device 11 MVC encoder 14544I.doc -121 - 201105108 21 22 23 24 25 51 52 53 54 55 56 57 H.264/AVC encoder H.264/AVC decoding Depth calculation department

Dependent view video horological multiplexer controller disk drive memory local storage internet interface decoding operation input section 145441.doc -122-

Claims (1)

201105108 VII. Patent application scope: ι· A playback device, comprising: an acquisition mechanism, which acquires a basic stream and an extended stream obtained by encoding a plurality of image poor materials by a special encoding method; The mechanism 'decodes the above-mentioned basic stream obtained by the above-mentioned value from the server and the extended stream; and the switching mechanism 'based on the representation of the basic stream and the above-mentioned extended stringer - The stream is a stream of the left image or a stream of the right image 'the destination of the data of the decoding result generated by the above decoding mechanism. 2. The playback device of claim 1, further comprising: a second generation mechanism that generates a plane of the left image; and a second generation mechanism that generates a plane of the right image; and the switching mechanism associates the basic stream with The data of the decoding result of the stream represented by the left image stream by the flag is output to the first forming mechanism in the extended stream, and the data of the decoding result of the other stream is output to the above 2 generation agency. 3. The playback device of claim 1, wherein the switching mechanism identifies, based on the PID, whether the data decoded by the decoding mechanism is data of a decoding result of the basic stream or a decoding result of the extended stream. 4. The playback device of claim 1, wherein the switching mechanism identifies the data decoded by the decoding mechanism based on the identification information of the viewing angle set in the extended stream at the time of encoding, and the basic stream is described in the above I45441.doc 201105108 The data of the decoding result or the decoding result of the above extended stream. The playback device of claim 4, wherein the switching mechanism identifies the data of the decoding result of the extended stream based on the set identification information of the view angle, and decodes the stream of the identification information of the view angle not set. The result data is identified as the data of the decoding result of the above basic stream. 6. The playback device of claim 1, wherein the obtaining means reads and acquires the basic stream and the extended stream from the installed recording medium, and reads and describes the flag from the recording medium. Controlling the playback control information based on the streaming and playback of the extended stream, and the switching mechanism is based on the flag described by the playback control information command read from the recording medium by the obtaining mechanism. The output destination of the data of the decoding result generated by the above decoding mechanism is switched. 7. The playback device of claim 1, wherein the upper transmission mechanism acquires an additional asset attached to at least one of the basic stream and the extension and describes the flag, and only the upper switching mechanism It is based on the above-mentioned additional information obtained by the above-mentioned additional information obtained by the pick-up of the field, and the output of the above-mentioned flag, the stomach (4) h, and the secrets generated by the secrets. 8. The playback device of claim 7, wherein the obtaining means obtains, in the stream of the basic stream I45441.doc 201105108, which is broadcasted, and describes at least any of the flag and the extended stream. Additional information. 9. The playback device of claim 1, wherein the obtaining means receives and acquires the transmitted basic stream and the extended stream, and receives the flag describing and controls the basic stream and the extended stream. The transfer control information is transmitted, and the switching means switches the rounding destination of the data of the decoding result generated by the decoding means based on the flag described in the transfer control information received by the obtaining means. 10. The playback device of claim 9, wherein the acquisition mechanism receives and acquires the basic stream and the extended stream transmitted via radio waves, and describes the flag purely and controls the basic stream and The transmission control information of the above-mentioned extended stream transmission. 11. A playback method, comprising the steps of: obtaining a basic stream and an extended stream obtained by encoding a plurality of image data in a specific coding manner, and decoding the obtained basic stream and the extended stream, Based on a flag indicating whether the stream of the basic stream and the extended stream is a stream of a left image or a stream of a right image, a result of the rounding of the result data. ' 12. A program that causes a computer to execute a process comprising the following steps: obtaining a basic stream and an extended stream obtained by encoding a plurality of image data in a specific encoding manner, 145441.doc 201105108 = The basic stream and the extended stream perform data based on a flag switching decoding result indicating whether the stream of the basic stream and the extended stream is a stream of a left image or a stream of a right image. Output destination. 145441.doc