Nothing Special   »   [go: up one dir, main page]

JP5027952B2 - 受信装置 - Google Patents

受信装置 Download PDF

Info

Publication number
JP5027952B2
JP5027952B2 JP2012092048A JP2012092048A JP5027952B2 JP 5027952 B2 JP5027952 B2 JP 5027952B2 JP 2012092048 A JP2012092048 A JP 2012092048A JP 2012092048 A JP2012092048 A JP 2012092048A JP 5027952 B2 JP5027952 B2 JP 5027952B2
Authority
JP
Japan
Prior art keywords
stream
file
view
information
plane
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012092048A
Other languages
English (en)
Other versions
JP2012178847A (ja
Inventor
航 池田
智輝 小川
泰治 佐々木
洋 矢羽田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2012092048A priority Critical patent/JP5027952B2/ja
Publication of JP2012178847A publication Critical patent/JP2012178847A/ja
Application granted granted Critical
Publication of JP5027952B2 publication Critical patent/JP5027952B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N13/356—Image reproducers having separate monoscopic and stereoscopic modes
    • H04N13/359—Switching between monoscopic and stereoscopic modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8233—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a character code signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/183—On-screen display [OSD] information, e.g. subtitles or menus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189—Recording image signals; Reproducing recorded image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365—Multiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42646—Internal components of the client ; Characteristics thereof for reading from or writing on a non-volatile solid state storage medium, e.g. DVD, CD-ROM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432—Content retrieval operation from a local storage medium, e.g. hard-disk
    • H04N21/4325—Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347—Demultiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4884—Data services, e.g. news ticker for displaying subtitles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Library & Information Science (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)

Description

本発明は、3D映像及び2D映像の再生技術の技術分野に属する発明である
2D映像とは、表示装置の表示画面をX-Y平面として捉えて、このX-Y平面上の画素にて表現される画像であり、平面視画像とも呼ばれる。
対照的に3D映像とは、表示装置の画面におけるX-Y平面上の画素に、Z軸方向の奥行きを加えた画像である。3D映像は、左目で視聴すべきレフトビュー映像と、右目で視聴すべきライトビュー映像とを共に再生して、これらレフトビュー映像、ライトビュー映像で立体視効果を発揮することにより、ユーザによる視聴に供される。3D映像における画素のうち、正のZ軸座標をもつものをユーザは、表示装置の画面より手前にあると感じ、負のZ軸座標をもつものを、画面より奥に存在すると感じる。
光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置（以下、「2D再生装置」と呼ぶ）との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3D映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの２種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置（以下、「2D/3D再生装置」）では、2D映像も
しくは3D映像として再生できることが求められる。
3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献１に記載されたものがある。
特許第３９３５５０７号公報
立体視のためのレフトビュー、ライトビューの映像は、3Dカメラで撮影することにより得たものである。この3Dカメラは、2つのレンズが、人間の両眼視差に応じた間隔だけ隔
てられて存在する。かかるレンズを介して撮影されたレフトビュー映像及びライトビュー映像は、交互再生されることにより人間の両眼視差を作り出すことができる。
しかし字幕やメニューは、3Dカメラによる撮影行為で作成されるのではなく、撮影が終了した後のオーサリングの行程で作成されるものであり、これらは立体視映像を見ながら後付けで作される。この際、立体視再生時において、字幕やメニューがどのように見えるかを考えながら、レフトビュー、ライトビューそれぞれについて、字幕やメニューを作成することはオーサリングスタッフにとって多大な労力であり、字幕／メニュー付きの立体視コンテンツの制作にあたっては、その作成作業を効率化することが要望されている。また、動画像がどれだけ手前に見えるかは、各フレーム期間毎に、時々刻々と変化するので、字幕やメニューの奥行きを固定化すると、字幕やメニューが、映像中の人物像とが位置的に重なることが多いに有り得る。酷い時にはメニューの矩形枠等が人物に突刺さって見え、ユーザの失笑を買うことも考えられるで、このようなおかしな立体視映像が再生されることを避けるには、やはりオーサリングの手間を惜しむことはできない。
本発明の目的は、オーサリングの手間を増大させることなく、品位が高い立体視映像を再生することができる受信装置を提供することである。
上記課題を解決することができる受信装置は、放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
前記データは、メインビュービデオストリームと、サブビュービデオストリームと、グラフィクスストリームとを含み、
前記メインビュービデオストリームは、立体視映像のメインビューを構成するピクチャデータを含み、
前記サブビュービデオストリームは、立体視映像のサブビューを構成するピクチャデータと、メタデータとを含み、
前記グラフィクスストリームは、グラフィクスデータを含み、
前記メタデータは、前記グラフィクスデータに対して水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する、オフセット制御を規定する制御情報であり、
前記メインビュービデオストリーム及び前記サブビュービデオストリームをデコードすることにより、メインビューを構成するピクチャデータ及びサブビューを構成するピクチャデータを得るビデオデコーダと、
前記グラフィクスストリームをデコードすることにより、グラフィクスデータを得るグラフィクスデコーダと、
前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと、前記グラフィクスデータとを合成する合成部と、
を備え、
前記合成部は、前記制御情報に基づいて、前記グラフィクスデータに対して、水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する
ことを特徴とする。
グラフィクスストリームにおける制御情報は、受信装置がワンプレーンで動作する場合におけるオフセット制御を規定するので、左右の字幕やメニューが存在しなくても、字幕やメニューが1つさえあれば、立体視の再生が可能になる。メインビュー、サブビューのそれぞれについて字幕やメニューを作成するという手間が軽減されるばかりか、受信装置におけるプレーンメモリのためのメモリ規模が、ワンプレーンであっても、立体視再生を実現することができるので、オーサリングの効率化と、再生装置の低コスト化の両立を実現することができる。
記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。 ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。 立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。 1plane＋Offsetモードにおいて、プレーンメモリのレイヤモデルに対してどのようなオフセット制御がなされるかを示す。 図４におけるオフセット制御によって、どのような立体視映像が再生されるかを示す。 1plane＋Offsetモードにおける立体視の実現の仕方を示す。 1plane＋Offsetモードのための制御情報を具備したディペンデントビューストリームの内部構成を示す。 ユーザデータコンテナの内部構成を示す図である。 オフセットメタデータを記述するためのシンタックスを示す。 正と負のプレーンオフセットの見え方の違いの一例を示す図である。 横軸を時間軸とし、縦軸を、Plane＿offset＿value[j]としたグラフである。 横軸を時間軸とし、縦軸をPlane＿offset＿value[j]としたグラフである。 offset＿sequence＿id＝１、２、３、４のオフセットシーケンスによって、どのような奥行きが定義されるかの一例を示す。 第１実施形態に係る記録媒体における内部構成を示す。 PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示す。 メインTSがどのように多重化されるかを模式的に示す図である。 メインTS及びサブTSの内部構成を示す。 プレイリスト情報の内部構成を示す。 基本ストリーム選択テーブルの一例を示す。 拡張ストリーム選択テーブルの内部構成を示す。 拡張ストリーム選択テーブルにおけるストリーム登録列を示す。 基本ストリーム選択テーブル、拡張ストリーム選択テーブルによりメインTS、サブTSからどのようなESが多重分離されるかを示す。 図２２のような多重分離がなされる場合、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。 モードにおけるストリーム番号の割り当て変化を示す。 オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。 再生装置の内部構成を示す。 結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。 結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。 再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す。 プレイリスト再生手順を示す。 ストリーム選択プロシージャの処理手順を示す。 ストリーム番号に対応するパケット識別子の出力処理の手順を示す。 PGプレーンシフトの処理手順を示すフローチャートである。 テキスト字幕ストリームが再生対象である場合のPGプレーンシフトの処理手順を示すフローチャートである。 IGプレーンのプレーンシフトを示すフローチャートである。 STN＿table＿SSのFixed＿offset＿during＿Popupがオンである場合のIGプレーンのプレーンシフトの処理手順を示すフローチャートである。 エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。 立体視インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。 立体視インターリーブドストリームファイル、ファイル2D、ファイルベースの相互関係を示す。 2Dプレイリスト、3Dプレイリストを示す。 図４３の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。 ベースビューインディケータを示す。 プレイリスト情報によるストリームファイルの読み込み手順を示す。 クリップ情報ファイルの内部構成を示す図である。 エクステントスタートポイント情報のシンタックスを示す。 クリップ情報ファイルにおけるエントリーマップテーブルを示す。 プログラム情報におけるストリーム属性情報を示す。 エントリーマップによるエントリーポイントの登録を示す。 立体視インターリーブドストリームファイル構成するデータブロックからATCシーケンスがどのように復元されるかを示す。 ATCシーケンスの復元を示す図である。 ATCシーケンス復元手順を示す。 多重分離部及びビデオデコーダの内部構成を示す。 PGストリームのグラフィクスデコーダの内部構成を示す。 テキスト字幕デコーダの内部構成を示す。 IGデコーダのデコーダモデルを示す。 デコーダモデルの出力を合成し、3D-LR方式で出力するための回路構成を示す。 デコーダモデルの出力を合成し、1plane＋Offsetモード方式で出力するための回路構成を示している。 多層化された光ディスクの内部構成を示す。 ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。 記録媒体の記録方法を示す。 オーサリング行程の処理手順を示すフローチャートである。 AVファイル書込工程の処理手順を示す。 記録装置の内部構成を示す。 2D/3D再生装置の構成を示している。 システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す。 レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図である。 出力モードの選択モデルの状態遷移を示す。 Initializationの処理手順を示す。 Procedure when playback condition is changedの処理手順を示す。 3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。 マクロブロックの奥行きと、シフト制御のためのパラメータとの関係を示す。 ビデオストリームのエンコードとパラレルに実行される、オフセットシーケンスの定義手順を示すフローチャートである。 字幕ストリームにおけるウィンドゥ定義セグメント、制御情報を示す図である。 DSにおけるPCSの記述例を示す図である。 composition＿object内の3d＿graphics＿offsetを用いた補間を施す場合と、補間を施さない場合とで、オフセットが時間的にどのように変化するかを示す。 画面の分割領域毎のオフセットから構成されるオフセットシーケンスを示す。 画面内の物体の奥行きと、オフセットとの関係を示す。 再生装置のうち、ビデオデコーダ、ベースビュービデオプレーン、ディペンデントビュービデオプレーンメモリ、PG/IGプレーンを示す。 グラフィクスプレーンの内容と、オフセットとの関連性を示す。 デプスビュー方式の一例を示す。 3D-Depthモードで生成される立体視画像を示す。 3D-Depthモードを実現するための記録媒体の構成例を示す。 ディレクトリ名とファイル拡張子により、2Dと3Dの場合に再生するストリームファイルを区別する仕組み、また、LR形式とDepth形式で再生するストリームファイルを区別する仕組みを示す。 エレメンタリバッファのサイズ情報を含むプレイアイテム情報を示す。 奥行き情報が追加された3Dメタデータを示す。 2D/3D再生装置を集積回路を用いて実現した構成例である。 ストリーム処理部の代表的な構成を示す機能ブロック図である。 切替部がDMACであった場合の切替部６５３周辺の概念図である。 AV出力部の代表的な構成を示す機能ブロック図である。 AV出力部もしくは再生装置のデータ出力部分を詳細に示した構成例である。 画像重畳処理における、メモリと各プレーンとの関係を示した図である。 画像重畳部における画像重畳処理の概念図である。 画像重畳部における画像重畳処理の概念図である。 画像重畳部における画像重畳処理の概念図である。 画像重畳部における画像重畳処理の概念図である。 集積回路における制御バス及びデータバスの配置を示した図である。 集積回路における制御バス及びデータバスの配置を示した図である。 再生装置における動作手順を簡単に示したフローチャートである。 再生装置における動作手順を詳細に示したフローチャートである。 ベースビュービデオストリームのクリップ情報におけるエクステントスタートポイント情報の一例と、ディペンデントビューストリームのクリップ情報におけるエクステントスタートポイント情報の一例を示す。 ATCシーケンス１、２における任意のデータブロックのソースパケット番号を説明するための図である。
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目とでは、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、１つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が
必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法であ
る。
上記の何れの方式においても、立体視映像は、少なくとも2つの視点映像から構成され
る。視点映像とは、何等かの偏向性をもった映像のことであり、少なくとも2つの視点映
像は、メインビュー映像と、サブビュー映像とから構成される。そしてメインビュー、サブビューがそれぞれ、ビデオストリームによって記録媒体から供給される場合、記録媒体には、メインビューを供給するビデオストリームであるメインビュービデオストリーム、サブビューを供給するビデオストリームであるサブビュービデオストリームが記録される。以降の説明で登場する記録媒体は、これらのメインビュービデオストリーム、サブビュービデオストリームを好適に記録するためのものである。
また本願明細書における再生装置は、上述したメインビュービデオストリーム、サブビュービデオストリームを再生するため、2D再生モード、3D再生モードという2つの再生モ
ードを具備しており、これらの相互切り替えを可能とする2D/3D再生装置(プレーヤ)であ
る。
図１は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。同図（ａ）に示すように、記録媒体の一例である記録媒体１００、再生装置２００は、テレビ３００、3D眼鏡４００、リモコン５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、表示装置３００と接続され、記録媒体１００を再生する。
表示装置３００はテレビであり、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置３００は、3D眼鏡４００をユーザが着用することで立体視を実現するものだが、表示装置３００がレンチキュラー方式のものなら、3D眼鏡４００は不要となる。レンチキュラー方式の表示装置３００は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
3D眼鏡４００は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。 同図（ｂ）は、左目用映像の表示時を示す。画面上
に左目用の映像が表示されている瞬間において、前述の3D眼鏡４００は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図（ｃ）は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
リモコン５００は、AV再生のための操作項目を受け付けるための機器である。またリモコン５００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かか
る操作受け付けのため、リモコン５００は、GUIを構成するメニューを呼び出すメニュー
キー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成
するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のもの
にもどってゆくための戻りキー、数値キーを備える。
図１のホームシアターシステムにおいて、3D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを“3D出力モード”という。2D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを“2D出力モード”という。
以上が、記録媒体及び再生装置の使用形態についての説明である。
（第１実施形態）
第１実施形態の特徴は、立体視再生を実現するためのメインビュービデオストリーム、サブビュービデオストリームの組みを記録媒体１００に記録して再生装置２００に供給するにあたって、サブビュービデオストリーム内のメタデータに、オフセット制御を規定する制御情報を組込む点である。
ここでのオフセット制御とは、グラフィクスプレーンにおける水平座標の右方向及び左方向にオフセットを与えて、メインビューを構成するピクチャデータが描画されるメインビュービデオプレーン及びサブビューを構成するピクチャデータが描画されるサブビュービデオプレーンと合成することをいう。
更に、上記シフト制御のための制御情報は、前記オフセット値を示す情報及び前記オフセット方向を規定する情報を、複数フレームにおける各フレームに対応付けて規定するパラメータシーケンスとして機能する。
以降の説明において、メインビュー及びサブビューは、視差画像方式を実現するものとする。視差画像方式(3D-LRモードという)は、右目に入る映像と、左目に入る映像とを各
々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図２は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画
像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという
。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。視点間の相関特性を利用したビデオ圧縮の方法としては、Multiview Video Coding（MVC）と呼ばれるMPEG-４ AVC/H.２６４の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共
同プロジェクトであるJoint Video Team（JVT）は、２００８年7月にMultiview Video Coding（MVC）と呼ばれるMPEG-４ AVC/H.２６４の修正規格の策定を完了した。MVCは、
複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。
そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュ
ービデオストリームのうち、単体で復号化が可能になるものを“ベースビュービデオスト
リーム”という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、後述するベースビューインディケータによって定まる。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、“ディペンデントビュービデオストリーム”という。
視点間の相関性に基いて圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームであって、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、プレイアイテム情報内のベースビューインディケータによって定まる。
現状における立体視映像の符号化は、このMVC方式によるものが最良であると考えられ
るので、以降の説明では、“メインビュービデオストリーム”が“ベースビュービデオストリーム”であり、“サブビュービデオストリーム”が“ディペンデントビュービデオストリーム”であるとして説明を行う。
MVCビデオストリームの基礎となるMPEG4-AVC形式のビデオストリームについて説明する。
MVCビデオストリームは、GOP構造を有しており、クローズドGOP、オープンGOPから構成される。クローズドGOPは、IDRピクチャと、このIDRピクチャに続くBピクチャと、Pピク
チャとから構成される。オープンGOPは、Non-IDR Iピクチャと、Non-IDR Iピクチャに続
くBピクチャと、Pピクチャとから構成される。
Non-IDR Iピクチャ、Pピクチャ、Bピクチャは、他のピクチャとのフレーム相関性に基
づき圧縮符号化されている。Bピクチャとは、Bidirectionally predictive(B)形式のスライスデータからなるピクチャをいい、Pピクチャとは、Predictive(P)形式のスライスデータからなるピクチャをいう。Bピクチャには、refrenceB(Br)ピクチャと、nonrefrenceB(B)ピクチャとがある。
クローズドGOPは、IDRピクチャが先頭に配置される。表示順序においてIDRピクチャは
先頭にならないが、IDRピクチャ以外の他のピクチャ(Bピクチャ，Pピクチャ)は、クロー
ズドGOPより前のGOPに存在するピクチャと依存関係をもつことはできない。このようにクローズドGOPは、依存関係を完結させる役割をもつ。

次にGOPの内部構成について説明する。オープンGOP、クローズドGOPにおける個々のピ
クチャデータは、H.264符号化方式におけるビデオアクセスユニット構造を有している。
ビデオアクセスユニットと、ピクチャとの関係は、１ビデオアクセスユニット ＝ １ピクチャである。またBD-ROMでは、１PESパケット ＝ １フレームに制限されている。つま
り、動画がフレーム構造であれば、１PESパケット ＝ １ピクチャであり、フィールド構
造である場合、１PESパケット＝２ピクチャとなる。これらのことから、PESパケットは、ピクチャを、１対１の比率で格納している。
図３は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。
本図の第２段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれてい
る。これらのピクチャデータは、Decode Time Stamp(DTS)に従いデコードされる。第１段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。
第４段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これ
らのピクチャデータは、DTSに従いデコードされる。第３段目は、右目画像を示す。そう
してデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。
第５段目は、3D眼鏡４００の状態をどのように変化させるかを示す。この第５段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
本図において、例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビ
ュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを１／４８秒の表示周期において、“Ｂ”ー“Ｄ”ー“Ｂ”ー“Ｄ”というように交互で出力するモードを、“B−Dプレゼンテーションモード”という。
ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを交互に出力するのではなく、再生モードを3Dモードに維持したまま、同じビデオフレームを2回以上繰り返し出力するという処理を行う再生タイプを、B−B
プレゼンテーションモードという。B−Bプレゼンテーションモードでは、単独再生可能なベースビュービデオストリームのビデオフレームのみが“Ｂ”−“Ｂ”−“Ｂ”−“Ｂ”というように繰り返し出力される。
以上のB−Dプレゼンテーションモード、B−Bプレゼンテーションモードが、再生装置の再生モードの基本となるが、これらのモード以外にも、再生装置には、1plane＋Offsetモードという再生モードが存在する。
1plane＋Offsetモード(3D-Offsetモードともいう)は、プレーンメモリの後段にシフト
部を組込んで、シフト部を機能させることで立体視を実現する再生モードである。プレーンオフセット部は、レフトビュー期間及びライトビュー期間のそれぞれにおいて、プレーンメモリにおけるライン単位の画素の座標を、左方向又は右方向にシフトさせ、右目視線及び左目視線の結像点を手前方向、又は、奥行方向に変位させることで奥行き感を変化させる。具体的には、レフトビュー期間で左方向、ライトビュー期間で右方向に、画素座標を変化させれば、両目の視線の結像点は手前になり、レフトビュー期間で右方向、ライトビュー期間で左方向に、画素座標を変化させれば、両目の視線の結像点は手前になる。
かかるプレーンシフトでは、立体視のためのプレーンメモリが1プレーンで足りるので
、簡易に立体視映像を作り出すのに最適である。このプレーンシフトでは、平面的な映像が手前に来たり、奥に引込んだりするという立体視映像を産み出すに過ぎないから、メニューや字幕の立体視効果には適しているものの、キャラクターや物体の立体視効果の実現にはやや物足りない。キャラクターの顔のくぼみや凹凸等が再現できないからである。
1plane＋Offsetモードをサポートする場合、再生装置の構成は以下の通りになる。グラ
フィクスの再生のため、再生装置にはプレーンメモリと、CLUT部、合成部が存在しており、このCLUT部、合成部の間にプレーンシフト部が組み入れられる。そして、シフト部は、ディペンデントビュービデオストリームのアクセスユニット構造に組込まれたオフセットシーケンスにおけるオフセットを用いて、上述したような画素の座標変化を実現する。こうすることで、1plane＋Offsetモードにおける画素の飛び出度合は、MVCビデオストリー
ムと緻密に同期したものになる。この1plane＋Offsetモードの中には、1plane＋Zero Offsetモードがある。1plane＋Zero Offsetモードは、ポップアップメニューがオンである場合、オフセット値をゼロにして、ポップアップメニューだけに立体視効果を与える表示モードである。
オフセットシーケンスによるシフト制御の対象となるプレーンメモリは、所定のレイヤモデルを構成する複数のプレーンメモリである。プレーンメモリとは、ESをデコードすることで得られた一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオデコーダ、PGデコーダ、IGデコーダのデコードによって得られた1画面分
の画素データを格納する。
所定のレイヤモデルは、ベースビュービデオプレーン及びディペンデントビュービデオプレーンの階層、PGプレーンの階層、IG/BD-Jプレーンの階層から構成され、各階層のプ
レーンメモリの格納内容を、ベースビュービデオプレーン→PGプレーン→IG/BD-Jプレー
ンの順にレイヤ合成することを意図したものである。
上記レイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメ
モリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。以下、各階層のプレー
ンメモリについて述べる。
ベースビュービデオプレーンは、ベースビュービデオストリームを構成するビューコンポーネントをデコードすることで得られる一画面分の画素データを格納することができるプレーンメモリである。ディペンデントビュービデオプレーンは、ディペンデントビュービデオストリームを構成するビューコンポーネントをデコードすることで得られる一画面分の画素データを格納することができるプレーンメモリである。
プレゼンテーショングラフィクス(PG)プレーンとは、パイプライン式で動作するグラフィクスデコーダが、デコード処理を行うことで得られたグラフィクスの格納に用いられるプレーンメモリである。IG/BD-Jプレーンとは、ある動作モードでは、IGプレーンとして
機能し、別の動作モードでは、BD-Jプレーンとして機能するプレーンメモリである。インタラクティブグラフィクス(IG)プレーンとは、対話的な処理を前提にして動作するグラフィクスデコーダが、デコードを行うことで得られたグラフィクスの格納に用いられるプレーンメモリである。BD-Jプレーンは、オブジェクト指向プログラミング言語のアプリケーションが描画処理を行うことで得た描画イメージグラフィクスの格納に用いることができるプレーンメモリである。IGプレーンとBD-Jプレーンとは排他的なものであり、何れか一方が利用されている場合、他方は利用されないため、IGプレーンとBD-Jプレーンとでは1
つのプレーンメモリを兼用している。
上記レイヤモデルにおいて、ビデオプレーンについては、ベースビュー用のビデオプレーンと、ディペンデントビュー用のビデオプレーンとが存在するものの、IG/BD-Jプレー
ン、PGプレーンについては、ベースビュー用、ディペンデントビュー用のそれぞれについて、プレーンメモリが存在する訳ではない。よってIG/BD-Jプレーン、PGプレーンがシフ
ト制御の対象になる。
図４は、1plane＋Offsetモードにおいて、プレーンメモリのレイヤモデルに対してどのようなオフセット制御がなされるかを示す。本図におけるプレーンメモリのレイヤモデルは、IGプレーン、PGプレーン、ビデオプレーン、バックグラウンドプレーンから構成される。
本図（ａ）に示すように、ベースビュー期間においてPGプレーン及びIGプレーンは、左方向にシフトされる。この際、左方向シフト後のPGプレーンは、右側に透明領域が追加され、左側の端部が切り取られる。同じく左方向シフト後のIGプレーンは、右側に透明領域が追加され、左側の端部が切り取れる。
本図（ｂ）に示すように、ディペンデントビュー期間において、PGプレーン及びIGプレーンは、右方向にシフトされる。この際、右方向シフト後のPGプレーンは、左側に透明領域が追加され、右側の端部が切り取られる。同じく右方向シフト後のIGプレーンは、左側に透明領域が追加され、右側の端部が切り取られる。

図５は、図４におけるオフセット制御によって、どのような立体視映像が再生されるかを示す。IGプレーンの格納内容が、前チャプターへのスキップと、次チャプターへのスキップとを受け付けるGUI部品であり、PGプレーンの格納内容が『Dinos』という表題を示す字幕文字である場合、上述したような1plane＋Offsetモード時のオフセット制御によって、IGプレーン、PGプレーンの格納内容は、それぞれ（ａ）（ｂ）のものとなる。
（ａ）は、左シフト時のIGプレーンの格納内容と、右シフト時のIGプレーンの格納内容とを示す。（ｂ）は、左シフト時のPGプレーンの格納内容と、右シフト時のPGプレーンの格納内容とを示す。このようにオフセット制御がなされれば、（ｃ）のような立体視映像が再生されることになる。この（ｃ）の立体視映像では、図２に示した恐竜に、GUIと、
字幕とが合成されるので、現状のBD-ROMコンテンツでなされているような字幕、GUIを伴
う映画コンテンツが、立体視映像として再生されることになる。
図６は、1plane＋Offsetモードにおける立体視の実現の仕方を示す。
1plane＋Offsetモードにおいて、レフトビュービデオを出力する場合、PGプレーンと呼ばれるプレーンメモリに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後、他のプレーンとの合成に供する（図６（ａ）参照）。
ライトビュービデオを出力する場合、プレーンメモリをオフセット値だけX軸の負の方
向をずらし、レフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後にプレーンとの合成に供する（図６（ｂ）参照）。
図６（ｃ）は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクロッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である(図６（ｄ）参照)。
図７は、1plane＋Offsetモードのための制御情報を具備したディペンデントビューストリームの内部構成を示す。第１段目は、複数のGOPであり、第２段目は、GOPを構成する複数のビデオアクセスユニットを示す。これらのビデオアクセスユニットは、ビューコンポーネントに該当するもので、GOPにおける個々の表示フレーム(図中のFrame(1)〜Frame(nu
mber＿of＿displayed＿frames＿in＿GOP))において表示される。
第３段目は、ビデオアクセスユニットの内部構成を示す。ビデオアクセスユニットは、ビデオアクセスユニットデリミター、シーケンスパラメータセット、ピクチャパラメータセット、MVCスケーラブルネスティングSEIメッセージ、ファーズトビューコンポーネント、シーケンス終端コード、ストリーム終端コードを配列することにより構成される。そしてこのMVCスケーラブルネスティングSEIメッセージの中に、ユーザデータコンテナが存在する。
図８は、ユーザデータコンテナの内部構成を示す図である。
同図（ａ）は、ユーザデータコンテナの内部構成を示す。ユーザデータコンテナは、アンレジスタードユーザデータ(未登録ユーザデータ)のことであり、クローズドキャプション情報、GOP構造マップ、オフセットメタデータという3つの種類がある。これらの種類は、コンテナ中のtype＿indeicatorに明示される。
同図（ｂ）は、オフセットメタデータを示す。オフセットメタデータは、PGプレーン、IGプレーン、BD-Jプレーンのためのシーケンスリストであり、立体視再生モードにおいてプレゼンテーショングラフィクス＿テキスト字幕、IG/BD-Jプレーンが1plane＋Offsetモ
ードで再生されている間におけるオフセット設定に用いられる。具体的には、ピクチャデータと合成すべきグラフィクスを、1plane＋Offsetモードで再生する場合におけるPGプレーン、IGプレーン、BD-Jプレーンに対するオフセット制御を示す。
メタデータは、ディペンデントビューアクセスユニットの符号化順序における各GOPの
先頭のビデオコンポーネントのMVCスケーラブルネスティングSEIメッセージに格納されねばならない。MVCスケーラブルネスティングSEIメッセージを含むNALユニットは、メタデ
ータのユーザデータコンテナ以外の他のデータを含んでいてはならない。
同図（ｂ）は、オフセットメタデータ(Offset＿metadata)の内部構成を示す。
フレームレート(frame＿rate)は、オフセットメタデータを含むアクセスユニットのフレームレートを記述する。
プレゼンテーションタイムスタンプ(PTS)は、GOPにおける最初のフレームレートを90KHzで記述する。
オフセットシーケンスナンバー(number＿of＿offset＿sequence)は、０から３２までの範
囲で、シーケンス数を記述する。
表示フレームナンバーインGOP(number＿of＿displayed＿frames＿in＿GOP)は、メタデータが含まれるGOPにおける表示フレーム数を示す。
number＿of＿sequence個のオフセットシーケンス(offset＿sequence[1]〜offset＿sequence[number＿of＿sequence]))は、ビデオストリームにおける個々のGOPに対応するオフセット
シーケンスの集まりである。
同図（ｃ）は、オフセットシーケンスの内部構成を示す。オフセットシーケンスは、前記グラフィクスを、グループオブピクチャに属する各ピクチャデータと合成する場合における制御パラメータを、グループオブピクチャにおけるフレーム期間毎に示すパラメータシーケンスであり、number＿of＿displayed＿frames＿in＿GOPに示される個数の制御パラメー
タから構成される。この制御パラメータは、プレーンオフセット方向情報と、プレーンオフセット値とから構成される。
プレーンオフセット方向情報(Plane＿offset＿direction)は、プレーンにおけるオフセ
ット方向を指示する。値“０”でフロント設定、つまり、プレーンメモリは、TVと視聴者との間に存在し、レフトビュー期間においてプレーンは右方向に、ライトビュー期間においてプレーンは左方向にシフトされる。
値＝１でビハインド設定、つまり、プレーンメモリは、TV又はスクリーンの背後に存在し、レフトビュー期間においてプレーンは左方向に、ライトビュー期間においてプレーンは右方向にシフトされる。プレーンオフセット方向情報がフロント設定を示す場合、3次
元座標系における制御パラメータのZ軸座標は、正の座標になる。プレーンオフセット方
向情報がビハインド設定を示す場合、3次元座標系における制御パラメータのZ軸座標は、負の座標になる。
プレーンオフセット値(Plane＿offset＿value)は、グラフィクスを構成する画素の水平方向の変位量の指定であり、プレーンのオフセット値を画素単位で指示する。
図９は、オフセットメタデータを記述するためのシンタックスを示す。offset＿sequence＿idを制御変数としたfor文は、number＿of＿offset＿sequence個のoffset＿sequenceを定義
する。
iを制御変数としたfor文は、Plane＿offset＿directionと、Plane＿offset＿valueとの組みを、number＿of＿displayed＿frame＿in＿GOPだけ定義する。このようなfor文を用いることで
、上述したようなオフセットシーケンスは定義されることになる。
図１０は、正と負のプレーンオフセットの見え方の違いの一例を示す図である。同図（ａ）（ｂ）において、手前の方は、ライトビュー出力時にシフトしたシフト後のグラフィクスプレーンを用いて出力されるライトビュー用のグラフィクスイメージを示す。奥の方は、レフトビュー出力時にシフトしたシフト後のグラフィクスプレーンを用いて出力されるレフトビュー用のグラフィクスイメージを示す。
本図（ａ）は、プレーンオフセットの符号が正（レフトビュー用のグラフィクスイメージを右方向へずらし、ライトビュー用のグラフィクスイメージを左方向へずらす）である場合を示す。プレーンオフセットが正の値であると、レフトビュー出力時の字幕がライトビュー出力時の字幕より右の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより手前にくるので、字幕も手前に見えるようになる。
本図（ｂ）は、プレーンオフセットの符号が負である場合を示す。負の値であると、図１４に示したように、レフトビュー出力時の字幕がライトビューの出力時の字幕より左の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより奥にゆくので、字幕も奥に見えるようになる。
以上で、プレーンオフセットの正と負の切り替えによって、字幕が表示画面の位置よりも飛び出るか奥にゆくかを変化する方法についての説明を終える。
＜オフセットシーケンスの技術的意義＞
オフセットシーケンスは、上記データ構造を具備することにより、ビデオストリーム時間軸における各フレーム毎にグラフィクスの奥行きを定義することができるので、何れ1
つのオフセットシーケンスを用いることで、任意のフレーム時間tから、そのフレーム時
間に対応する奥行きzを導出する関数Ｚ(t)を定義することができる。この関数Ｚ(t)が、
フレーム時刻tに対して奥行きを線形的に変化させるものなら、再生装置は、かかる関数
Ｚ(t)に対応するオフセットシーケンスを、1plane＋Offsetモードに用いることで、再生
進行に伴いグラフィクスの奥行きを線形的に変化させることができる。また関数Ｚ(t)が
、フレーム時刻tに対して奥行きを、指数的に変化させるものなら、再生装置は、かかる
関数Ｚ(t)に対応するオフセットシーケンスを、1plane＋Offsetモードに用いることで、
再生進行に伴いグラフィクスの奥行きを指数的に変化させることができる。ビデオストリーム時間軸における再生時点の進行に伴い、リアルタイムに奥行きを変化させることができるので、リアリティに富んだグラフィクスの立体視再生を実現することができる。
図１１は、横軸を時間軸とし、縦軸を、Plane＿offset＿value[j]としたグラフである。
横軸における時間軸は、ディペンデントビューアクセスユニットを構成する個々のGOPが
一個の時間単位になっている。縦軸のうち正の方向は、Plane＿offset＿direction[j]が0である場合のPlane＿offset＿value[j]を示し、縦軸のうち負の方向は、Plane＿offset＿direction[j]が1である場合のPlane＿offset＿value[j]を示す。そしてグラフ中の曲線、直線は、offset＿sequence＿id＝１,２,３,４のオフセットシーケンスによるPlane＿offset＿direction[j]の時間的変位を示す。これらのうちoffset＿sequence＿id＝１,４のオフセットシーケ
ンスは、時間軸に対して、線形的に変化する奥行きを定義する線形関数のオフセットシーケンスであり、offset＿sequence＿id＝２,３のオフセットシーケンスは、時間軸に対して
、放物線状に変化する奥行きを定義する放物線関数のオフセットシーケンスである。
図１２は、横軸を時間軸とし、縦軸をPlane＿offset＿value[j]としたグラフである。横
軸における時間軸は、ディペンデントビューアクセスユニットのGOPにおける個々のフレ
ームが一個の時間単位になっている。よって、図１１に示したoffset＿sequence＿id＝１,
２,３のオフセットシーケンスは、フレームの時間精度で表現すれば、フレーム期間毎に
離散的な値になっていることがわかる。各オフセットシーケンスは、1秒当りに24個の離
散的な奥行きを定義することができるので、１秒当りに24回の時間精度をもって、各オフセットシーケンスによる奥行きを変化させることができる。よって本編の動画像による立体視映像と比較して遜色がない、リアリティの高い奥行き変化で、３次元座標系におけるグラフィクスのZ座標を変化させることができる。
また、メタデータは複数のオフセットシーケンスを格納することができるので、複数のオフセットシーケンス1,2,3,4・・・・nを用いることにより、奥行きの時間的な変化が互いに異なる複数の奥行き関数Ｚ1(t),Ｚ2(t),Ｚ3(t),Ｚ4(t)・・・・・Ｚn(t)を定義でき
る。ここで、奥行き関数Ｚ1(t)が、変数tに応じて奥行きを変化させる１次関数であり、
Ｚ2(t)が二次関数、Ｚ3(t)が三次関数、Ｚ4(t)が四次関数、Ｚn(t)がn次関数というよう
に、複数のオフセットシーケンス1,2,3,4・・・・nを用いれば、奥行きと、フレーム時間との相関性が異なる複数の奥行き関数を定義することができる。
再生装置による動作にあたって、複数のオフセットシーケンス1,2,3,4・・・・nの何れかを選択するという動作を行えば、再生装置の状態変化や、ユーザからの要求に応じて、複数の奥行き関数Ｚ1(t),Ｚ2(t),Ｚ3(t),Ｚ4(t)・・・・・Ｚn(t)の中から最適なものを
選び、1plane＋Offsetモードに用いることができる。こうすることで、1plane＋Offsetモードにおけるグラフィクスの奥行きの変化の仕方に、様々なバリエーションをもたせることができる。
本実施形態で定義される複数のオフセットシーケンスは、それぞれ奥行きの時間的変化が異なる表示位置を規定するので、再生装置において所定のストリーム選択プロシージャを実行して、複数のオフセットシーケンスのうち、最適なものを選択することにより、適切な位置にグラフィクスを配置させることができる。
以上が第１技術的意義についての説明である。続いて、第２の技術的意義の詳細について説明する。
第２の技術的意義としては、画面中の移動体におけるそれぞれの部位に応じた奥行きを定義できる点である。図２に示した恐竜の骨格において、頭、胴体、脚、尻尾のそれぞれの部位ではその奥行きが自ずと異なる。更に、動画像において、これら頭、胴体、脚、尻
尾のそれぞれの部位の奥行きは、時間的に遷移するので、これらの頭、胴体、脚、尻尾のそれぞれの部位の丁度手前の位置の奥行きを示すような制御パラメータを、GOPの各フレ
ーム毎に明示できるよう、メタデータにおいては、オフセットシーケンスを複数定義できるようなデータ構造を有している。
図１３は、offset＿sequence＿id＝１、２、３、４のオフセットシーケンスによって、どのような奥行きが定義されるかの一例を示す。
ここでoffset＿sequence＿id＝１、２のオフセットシーケンスは、ユーザと恐竜との間に字幕／メニューを配置するための適切な奥行きを指定するものであり、offset＿sequence＿id＝３、４のオフセットシーケンスが、恐竜の後ろに字幕／メニューを配置するための適切な奥行きを指定するものである。そしてこれらのうち、offset＿sequence＿id＝１のオフセットシーケンスは、ユーザの近くに奥行きを定義し、offset＿sequence＿id＝２のオフセットシーケンスは、恐竜の手前の奥行きを定義する。offset＿sequence＿id＝３のオフセットシーケンスは、恐竜の足元に沿った奥行きを定義するものであり、offset＿sequence＿id＝４のオフセットシーケンスは、恐竜よりもかなり後ろに字幕／メニューを配置するための適切な奥行きを指定するものである。
立体物の頭、胴体、脚、尻尾のそれぞれの部位の丁度手前の位置の奥行きを示すような制御パラメータを定義することができ、また、この制御パラメータの時間的変位をGOPの
各フレーム毎に定義することができるので、図９のシンタックスで定義されるデータ構造を用いれば、緻密で高精度な1plane＋Offsetモードでのシフト制御を実現することができる。
図中の恐竜が画面内で動き回るものであり、字幕／メニューの適切な奥行きが、時々刻々と変化する場合でも、オフセットシーケンスの何れかを指定することにより、恐竜の適切な位置に、字幕／メニューの配置することができる。
以上が第２の技術的特徴についての説明である。
図１４は、第１実施形態に係る記録媒体における内部構成を示す。本図（ａ）に示すように、第１実施形態に係る記録媒体には、「インデックステーブルファイル」、「動作モードオブジェクトのプログラムファイル」、「プレイリスト情報ファイル」、「ストリーム情報ファイル」、「ストリームファイル」が記録されている。
＜インデックステーブルファイル＞
インデックステーブルファイルは記録媒体全体に関する管理情報であり、再生装置への記録媒体挿入後に、インデックステーブルファイルが最初に読み出されることで、再生装置において記録媒体が一意に認識される。
インデックステーブルファイルは、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。映画作品と、タイトルとの関係は、映画作品と、それの複数バージョンとの関係である。つまり1つのバージョンしかないような映画作品は、「映画作品＝タイト
ル」という関係になる。映画作品に、劇場公開版、ディレクターズカット版、TV放映版等、複数のバージョンがある場合、映画作品における個々のバージョンが1つのタイトルに
なる。
ここで、タイトル番号レジスタにおけるタイトル番号は、０、１〜９９９、不定値(0xFFFF)という番号がある。タイトル番号０は、トップメニュータイトルのタイトル番号であ
る。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値(0xFFFF)のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。
インデックステーブルは、各タイトル番号のそれぞれに対応したエントリー(インデッ
クステーブルエントリー)を有し、個々のインデックステーブルエントリーに、動作モー
ドを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。インデックステーブルエントリーは、以下の共通のデータ構造で定義される。この共通のデータ構造は、『オブジェクトタイプ』と、『ムービーオブジェクトレファレンス』と、『オブジェクトファイル名情報』とを含む。『オブジェクトタイプ』は、該当するタイトルに関付けられている動作モードオブジェクトが、MovieオブジェクトであるかBD-Jオブジェクトであるかを示す。『オブジェクト
ファイル名情報』は、タイトルに関連付けられたBD-J オブジェクトのファイル名を示す
。『ムービーオブジェクトレファレンス』は、タイトルに関連付けられたムービーオブジェクトの識別子を示す。
再生装置においてタイトル番号レジスタの値は、記録媒体の装填後、不定値0xFFFF→１〜９９９→０というように変化する。このタイトル番号の変化は、記録媒体の装填時に、ファーストプレイタイトルの再生を開始し、ファーストプレイタイトルの再生後、１から999までのタイトル番号レジスタのタイトル番号で指示されるタイトルの再生を行い、タ
イトル番号で指示されるタイトルの再生が終了すれば、トップメニュータイトルを再生してユーザによる選択待ちを行うというものである。１〜９９９のタイトル番号をもつタイトルのうち、タイトル番号レジスタに格納されているタイトル番号と、同じタイトル番号をもつものが、現在の再生対象、つまりカレントタイトルになる。タイトル番号レジスタにどのような番号を設定するかは、トップメニュータイトルに対するユーザ操作や、プログラムによるタイトル番号レジスタの設定によって決定される。
＜動作モードオブジェクトのプログラムファイル＞
動作モードオブジェクトのプログラムファイルは、再生装置の動作モードを規定するプログラムである動作モードオブジェクトを格納している。動作モードオブジェクトには、コマンドによって記述されたものと、オブジェクト指向のコンパイラ言語によって記述されたものがある。前者の動作モードオブジェクトは、コマンドベースの動作モードにおいて、複数のナビゲーションコマンドをバッチジョブとして再生装置に供給し、これらナビゲーションコマンドに基づき再生装置を動作させる。このコマンドベースの動作モードを、“HDMVモード”と呼ぶ。
後者の動作モードオブジェクトは、オブジェクト指向型のコンパイラ言語ベースの動作モードにおいて、クラス構造体のインスタンスを再生装置に供給し、このインスタンスに基づき再生装置を動作させる。クラス構造体のインスタンスには、Java(登録商標)アプリケーションを用いることができる。オブジェクト指向型コンパイラ言語ベースの動作モードを、“BD-Jモード”と呼ぶ。
＜プレイリスト情報ファイル＞
プレイリスト情報ファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。“プレイリスト”とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの“型”を定義する。プレイリスト情報によって定義される再生経路は、いわゆる“マル
チパス”である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。メインパスは1本であるのに対して、サブパスは、複数本定義することができ、これら複
数のサブパスは、サブパスIDと呼ばれる識別子によって識別される。かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。BD-Jモードでは、再生制御のためのJava(登録商標)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(登録商標)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMF(JavaMedia Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マ
シンのヒープメモリ上に生成される実際のデータのことである。HDMVモードでは、プレイリストによる再生を命じるナビゲーションコマンドを再生装置に実行させることで、再生を開始することができる。再生装置には、カレントのプレイリスト情報の番号を格納するプレイリスト番号レジスタを含み、複数のプレイリスト情報のうち、このプレイリスト番号レジスタに格納されているものが、現在の再生対象になる。
＜ストリーム情報ファイル＞
ストリーム情報ファイルは、ストリームファイルのそれぞれと一対一の割合で存在するクリップ情報ファイルであり、ストリームファイル内に存在するソースパケット列がどのようなATCシーケンスを構成するか、それらのATCシーケンス内にどのようなSTCシーケン
スが組込まれているのか、ATCシーケンスがどのようなTSであるのかを示す。
ストリーム情報ファイルは、ストリームファイルの中身を明らかにするものなので、ストリームファイル内のTSを再生しようとする場合、そのストリームファイルに対応するストリーム情報ファイルを予めメモリに読み出しておく必要がある。つまり、ストリームファイル再生にあたっては、予めストリーム情報ファイルをメモリに読み出すという前置主義が採用される。このような前置主義を採用しているのは以下の理由による。ストリームファイルに格納されるTSは、欧州デジタル放送規格と互換性があるデータ構造になっているが、放送番組として扱うためのPMT、PCR、PATといった情報はストリーム内に存在する
ため、これらを再生する度に取り出すのは賢明ではない。ストリームを再生する度に、低速な記録媒体をアクセスしてTSを構成するパケットを読み出し、そのTSパケットのペイロードを解析するという処理が必要になるからである。そこで、TSを構成するペイロードの中身を解析することなく、TSの諸元を把握できるよう、TSを格納したストリームファイルと一対一の比率でストリーム情報ファイルを設けておき、ストリーム再生に先立ち、ストリーム情報ファイルをメモリに読み出すことにしている。
＜ストリームファイル＞
ストリームファイルは、１又複数のソースパケット列を格納している。ソースパケットとは、２ビットのコピーパーミッションインディケータと、３０ビットのATS（到着時刻
：Arrival Time Stamp）とから構成される４バイトのTP＿Extra＿Headerが付加されたTSパケットである。TP＿Extra＿HeaderにおけるATSは、実時間伝送が行われ、等時性が確保された状態での伝送における到達時刻をいう。
これらのソースパケット列のうち、アライバルタイムクロック(ATC)時間軸において、
タイムスタンプが連続している複数のソースパケットから構成されているものを“ATCシ
ーケンス”と呼ぶ。“ATCシーケンス”とは、ソースパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(no arrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival＿Time＿Stamp
が参照しているArrival＿Time＿Clockに、連続性が存在するソースパケット列を“ATCシ
ーケンス”という。ATCシーケンスは、ATCのタイムスタンプが連続しているソースパケッ
ト列であるから、再生装置のアライバルタイムクロックを計時するクロックカウンタが計時を行っている間、ATCシーケンスを構成する各ソースパケットは、連続的なソースパケ
ットデパケッタイジング処理、及び、連続的なパケットフィルタリング処理に供されることになる。
ATCシーケンスがソースパケットの配列であるのに対し、STC時間軸におけるタイムスタンプが連続しているTSパケットの配列をSTCシーケンスという。“STCシーケンス”とは、TSパケットの配列であって、TSのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)をもたないものをいう。STCの不連続点とは、デ
コーダがSTCを得るために参照するPCR(Program Clock Reference)を運ぶPCRパケットの不連続情報(discontinuity＿indicator)がONである点である。STCシーケンスは、STCのタイムスタンプが連続しているTSパケット列であるから、再生装置のシステムタイムクロックを計時するクロックカウンタが計時を行っている間、STCシーケンスを構成する各TSパケ
ットは、再生装置内に存在するデコーダの連続的なデコード処理に供されることになる。
ストリームファイルにおけるメインTS、サブTSは、ストリームファイルに対応するストリーム情報ファイル内のクリップ情報によって、1つの“AVストリームの切れ端”つまり
、“AVクリップ”として管理されている
またストリームファイルに格納されるパケット列は、複数種別のPESストリームを管理
・制御するための情報として、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)を具備している。
PCR(Program＿Clock＿Reference)は、ATSの時間軸であるATC（Arrival Time Clock）とPTS・DTSの時間軸であるSTC（System Time Clock）の同期を取るために、そのPCRパ
ケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。
PMT(Program＿map＿table)は、ストリームファイル中に含まれる映像・音声・グラフィクスなどの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、またTSに関する各種ディスクリプタを持つ。ディスクリプタにはストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。
PAT（Program Association Table）は、TS中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルTSを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルTSを扱うかの如く、TSをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、記録媒体再生装置との互換性を意図したものである。TSのうち、マルチパスの基軸となるものを“メインTS”という。またサブパスの基軸となるものを“サブTS”という。
図１４（ｂ）は、メインTSの内部構成を示し、同図（ｃ）は、サブTSの内部構成を示す。同図（ｂ）に示すように、メインTSは、１本のベースビュービデオストリームと、３２本のベースビューPGストリーム、３２本のベースビューIGストリーム、３２本のオーディオストリームを含むものとする。同図（ｃ）に示すように、サブTSは、１本のディペンデントビュービデオストリームと、３２本のディペンデントビューPGストリーム、３２本のディペンデントビューIGストリームを含むものとする。
次に、TSの内部構成について説明する。
図１５は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳し
く示している。本図（ａ）における第１段目はビデオストリームのビデオフレーム列を示
す。第２段目は、PESパケット列を示す。第３段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy１,yy２, yy３, yy４に示すように、
ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ
、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PES
パケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS（Presentation Time-Stamp）やピクチャの復号時刻であるDTS（Decoding Time-Stamp）が格納される。
＜TSパケット列＞
図１５（ｂ）は、TSを構成するTSパケットの形式を示している。第１段目は、TSパケット列を示し、第２段目は、ソースパケット列を示す。
第１段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ４Byteの「TSヘッダ」とデータを格納する１８４Byteの「TSペイロード」に分かれる固定長の
パケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第２段目によると、TSパケットには、４ByteのTP＿Extra＿Headerが付与されて、１９
２Byteのソースパケットに変換された状態で、TSを構成する。TP＿Extra＿HeaderにはATS（Arrival＿Time＿Stamp）などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。TSには、第３段目に示すようにソースパケットが並ぶこととなり、TSの先頭からインクリメントする番号はSPN（ソースパケット番号）と呼ばれる。
＜TSにおける多重化＞
図１６は、メインTSがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを(第１段目)、それぞれPESパ
ケット列に変換し(第２段目)、ソースパケット列に変換する(第３段目)。同じくレフトビューPGストリームおよびレフトビューインタラクティブグラフィクス(第７段目)を、それぞれPESパケット列に変換し(第６段目)、更にソースパケット列に変換する(第５段目)。
こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、
メインTSが得られることになる。
・TSに多重化されるエレメンタリストリーム
これらのTSに多重化されるエレメンタリストリーム(ES)は、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームがある。
・ビデオストリーム
ベースビューとなるビデオストリームは、ピクチャインピクチャアプリケーションにおけるプライマリビデオストリームを構成する。ピクチャインピクチャアプリケーションは、このプライマリビデオストリームの他、セカンダリビデオストリームから構成される。プライマリビデオストリームとは、ピクチャインピクチャアプリケーションにおいて親画面となるピクチャデータから構成されるビデオストリームである。対照的に、セカンダリビデオストリームとは、ピクチャインピクチャにおいて子画面として、親画面の一部にはめ込まれるピクチャデータから構成されるビデオストリームである。
プライマリビデオストリームを構成するピクチャデータと、セカンダリビデオストリームを構成するピクチャデータとはデコード後、別々のプレーンメモリに格納される。セカンダリビデオストリームを構成するピクチャデータを格納するプレーンメモリの前段には
、セカンダリビデオストリームを構成するピクチャデータのスケーリング変更及び表示座標の位置決めを行う構成要素(Scalling&Positioning)が存在する。
・オーディオストリーム
オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの２種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。セカンダリオーディオストリームは、このミキシングのためのダウンサンプリングのための情報、ゲイン制御のための情報が存在する。
・プレゼンテーショングラフィクスストリーム(PGストリーム)
PGストリームは、デコーダにパイプラインを採用することで、映像との緻密な同期を実現することができ、字幕表示に適したグラフィクスストリームであり、2DPGストリームと、立体視PGストリームという2つの種類がある。立体視PGストリームには、レフトビューPGストリーム及びライトビューPGストリームという二種類のものがある。レフトビューPG
ストリーム及びライトビューPGストリームのうち、ベースビューインディケータによって指定されているものがベースビューPGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューPGストリームになる。
2DPGストリームの他に、立体視PGストリームを設けるのは、PGストリームが字幕文字を表す場合、2Dで表示される真正面から見た字幕文字と、3D-LRモードで左目用に表示され
るグラフィクスと、右目用に表示される字幕文字とは異なるものにする必要からである。そのため、2D再生の場合は正面から見たグラフィクスストリームを１本、3D-LRモード用
にはレフトビューPGストリーム、ライトビューPGストリームの計２本を表示する。同様に、深度情報を用いる3D-Depthモードの場合は、正面から見た映像と深度情報を示すグレースケールストリームを再生する。2D+offset（2D互換ストリーム）と、3D-LRストリームとは、混在させてはならない。
2DPGストリームは最大３２本、ベースビューPGストリームの最大３２本、ディペンデントビューPGストリームも最大３２本定義することができる。これらのPGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのPGストリームのうち、所望のものが再生に供されることになる。
レフトビューPGストリーム、ライトビューPGストリームは、互いに言語属性は一致させておき、ユーザーが表示方式を切り替えても、同じ内容の字幕が表示されるようにする。前提として、2D字幕と3D字幕とは1対1に対応し、2Dでしかない字幕、及び、3Dでしかない字幕を設けてはならないない。切り替え時のユーザー混乱を防止するためである。こうすることにより、1つのストリーム番号で、2D/3Dそれぞれの表示モードに対応するストリームが選択されることになる。この場合、1つのストリーム番号で言語属性などは同じにな
り、2DとLRの字幕の内容は同じになる。
パイプラインによるデコード動作の実現により、動画像との緻密な同期を実現するので、PGストリームの用途は字幕のような文字再生に限定されない。映画作品のマスコットキャラクタを表示して、これを動画像と同期させつつ動作させるなど、緻密な同期が必要なグラフィクス再生であれば、どのようなものも、PGストリームによる再生対象として、採用することができる。
ストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの
他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。
PGストリーム、テキスト字幕ストリームは、これらの種類が区別されることなく、同じストリーム種別であるとして、これらPGストリーム及びテキスト字幕ストリームは、同じストリーム登録列に登録される。そして、ストリーム選択のプロシージャを実行するにあたって、ストリーム登録列におけるストリーム登録の順位に従い、再生されるべきPGストリーム又はテキスト字幕ストリームが定まる。PGストリーム、テキスト字幕ストリームは、ストリーム種が区別されることなく、ストリーム選択のプロシージャに供されるのでこれらPGストリーム及びテキスト字幕ストリームを1つのストリーム種別、つまり、“PG＿
テキスト字幕ストリーム(略して、字幕ストリームと呼ぶ場合もある)”という種別で扱う。
2D用のPG＿テキスト字幕ストリームは、1plane＋Offsetモードにおいて再生される。以降の説明では、2DPG＿テキスト字幕ストリームを、1plane＋OffsetPG＿テキスト字幕ストリームであるとして説明する。
・インタラクティブグラフィクス(IG)ストリーム
IGストリームは、対話操作の情報を具備することで、ビデオストリームの再生進行に伴ってメニューを表示したり、またユーザ操作に従いポップアップメニューを表示することができるグラフィクスストリームである。
IGストリームもPGストリームと同様、2DIGストリームと、立体視IGストリームという2
つの種類がある。立体視IGストリームには、レフトビューIGストリーム及びライトビューIGストリームという二種類のものがある。レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームのうち、ベースビューインディケータによって指定されているものがベースビューIGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューIGストリームになる。 2DIGストリームは最大３２本、IGストリームは最大３２本、ディペンデントビューIGストリームも最大３２本定義することができる。これらのIGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのIGストリームのうち、所望のものが再生に供されることになる。
IGストリームの制御情報(対話制御セグメントという)は、ユーザインターフェイスモデルを規定する情報(User＿interface＿model)をもっており、オーサリング者は、このユーザインターフェイスモデル情報を設定することで、ビデオストリームの再生進行に伴ってメニューを表示するか(Alwaysオンという)、ユーザ操作に従いポップアップメニューを表示するか(ポップアップメニューオン)の何れかを指定することができる。
IGストリームが対話操作の情報をもつ意義は以下の通りである。Java（登録商標）仮想マシンがアプリケーションからの要求に応じてプレイリスト再生の開始を再生制御の主体である再生制御エンジンに指示する場合、Java仮想マシンは、再生制御エンジンに再生を命じた後、プレイリスト再生を開始した旨のレスポンスをアプリケーションに返す。つまり、再生制御エンジンによるプレイリスト再生が継続している間、Java仮想マシンは、実行終了待ちにはならない。何故なら、Java仮想マシンは、いわゆるイベントドリブン型の動作主体であり、再生制御エンジンがプレイリストの再生を行っている間も、動作を行うことができるからである。
一方、HDMVモードにおいて、コマンドインタプリタが、プレイリスト再生を再生制御エンジンに命じる場合、プレイリスト再生が終了するまで、そのプレイリスト再生の実行終
了待ちとなる。再生制御エンジンによる再生が継続している間、コマンド実行部は、対話的な処理を実行することはできない。このコマンドインタプリタの代わりに、グラフィクスデコーダが対話的な動作を行う。グラフィクスデコーダに対話的な動作を行わせるため、IGストリームには、ボタン部材を用いた対話的な操作を規定する制御情報が組込まれている。
・各ストリーム種別において許容される表示モード
3D表示モードのどれが許容されるかは、ストリーム種別によって異なる。プライマリビデオストリームの3D表示モードには、B−Dプレゼンテーションモード、B−Bプレゼンテーションモードといった2つの再生モードが許容される。プライマリビデオストリームにお
いて、B−Bプレゼンテーションモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、“立体視B−D再生タイプ”という。B−Bプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、立体視B−B再生タイプという。
PGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。PGストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオン
になっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるPGストリームの類型を、“立体視再生タイプ”という。1plane＋Offsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Offsetタ
イプという。1plane＋Zero Offsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Zero Offsetタイプという。
テキスト字幕ストリームの3D表示モードには、1plane＋Offsetモード、1plane＋Zero Offsetモードといった2つの再生モードが許容される。テキスト字幕ストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオンになってい
る場合のみである。
IGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。IGストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオン
になっている場合のみである。以降の説明では、特に断らない限り3D再生モード実行時には、ピクチャインピクチャは使用できないものとする。ピクチャインピクチャ及び3D再生モードは、何れも非圧縮のピクチャデータを格納するためのビデオプレーンを2つ必要と
するからである。また特に断らない限り、3D再生モードでは、サウンドミキシングも使用できないものとする。
続いて、メインTS及びサブTSの内部構成について説明する。図１７は、メインTS及びサブTSの内部構成を示す。
同図（ａ）は、メインTSの内部構成を示す。メインTSは、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはProgram＿Map＿Tableを構成し、0x1001
のパケットIDを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケット列は、プライマリビデオストリームを構成する。
0x1200から0x121FのパケットIDを有するソースパケット列までは、３２本の2DPGストリ
ームを構成する。
0x1400から0x141FのパケットIDを有するソースパケット列までは ３２本の2DIGストリ
ームを構成する。
0x1100のパケット識別子を有するソースパケット列から、0x111Fのパケット識別子を有するソースパケット列までは、プライマリオーディオストリームを構成する。
これらのソースパケットのパケット識別子を多重分離部に指示することにより、メインTSに多重化されている複数のESのうち、所望のものを分離してデコーダに供することができる。
図（ｂ）は、サブTSの内部構成を示す。サブTSは、以下のソースパケットによって構成されている。
Ox1012のパケット識別子を有するソースパケット列は、ディペンデントビュービデオストリームを構成する。
0x1220のパケット識別子を有するソースパケット列から0x123FのパケットIDを有するソースパケット列までは、３２本のベースビューPGストリームを構成する。
Ox1240のパケット識別子を有するソースパケット列から0x125Fのパケット識別子を有するソースパケット列までは、３２本のディペンデントビューPGストリームを構成する。
0x1420のパケット識別子を有するソースパケット列から0x143FのパケットIDを有するソースパケット列までは ３２本のベースビューIGストリームを構成する。
Ox1440のパケット識別子を有するソースパケット列から0x145Fのパケット識別子を有するソースパケット列は、３２本のディペンデントビューIGストリームを構成する。
以上がストリームファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
上述したようなマルチパスを定義するため、図１８のような内部構成を有する。本図は、プレイリスト情報の内部構成を示す。同図（ａ）に示すようにプレイリスト情報は、「メインパス情報」、「サブパス情報」、「プレイリストマーク情報」、「エクステンションデータ」を含む。以下、これらの構成要素について説明する。
１）メインパス情報は、１つ以上の主たる再生区間情報から構成される。図１８（ｂ）は、メインパス情報、及び、サブパス情報の内部構成を示す図であり、本図に示すように、メインパス情報は、１つ以上の主たる再生区間情報から構成される。サブパス情報は、１つ以上の従たる再生区間情報から構成される。
主たる再生区間情報はプレイアイテム情報と呼ばれ、TSの再生時間軸のうち、In＿Timeとなる時点と、Out＿Timeとなる時点の組みを1つ以上定義することにより、論理的な再生区間を定義する情報である。再生装置には、カレントのプレイアイテムの番号を格納するプレイアイテム番号レジスタを含み、複数のプレイリスト情報のうち、このプレイアイテム番号レジスタに格納されているものが、現在の再生対象になる。
図１８（ｃ）は、プレイアイテム情報の内部構成を示す。本図に示すように、「ストリーム参照情報」、「インタイムアウトタイム情報」、「接続状態情報」、「基本ストリーム選択テーブル」を含む。
ストリーム参照情報は、プレイアイテムを構成するトランスポートストリームを“AVクリップ”として管理しているクリップ情報ファイルを示す「クリップ情報ファイルネーム情報(clip＿information＿file＿name)」、そのTSにおける符号化方式を示す「クリップ
符号化方式識別子(Clip＿codec＿indentifier)」、当該TSのSTCシーケンスにおいて、イ
ンタイム及びアウトタイムが設定されているSTCシーケンスがどれであるかを示す「STC識別子レファレンス(STC＿ID＿referrence)」を含む。
再生区間であるプレイアイテムは、プレイアイテム情報−クリップ情報−AVクリップという階層構造を有しており、AVクリップ及びクリップ情報の組みと、プレイアイテム情報との比率については、１対多の関係にして、1つのAVクリップを複数のプレイアイテム情
報から多重参照することができる。よって、あるタイトルのために作成されたAVクリップをバンクフィルムとして採用し、これを複数のプレイアイテム情報から参照することで、映画作品のバリエーションを効率良く作成することができる(尚、バンクフィルムとは、
映画業界の用語であり、複数のシーンで使いまわしされる映像内容のことである)。
バンクフィルムとなるAVクリップが多くのプレイアイテム情報から参照されるとなると、参照されるプレイアイテム情報毎に、バンクフィルムのうち、再生させるべき区間を変化させたいという要望がでてくる。参照されるプレイアイテム情報毎に、バンクフィルムの再生させるべき区間を、変化させるという目的のため、プレイアイテム情報には、上述したIn＿Time、Out＿Timeが存在し、ストリーム再生時間軸の任意の時点を再生区間の開始
点、終了点として使用できるようになっている。
またバンクフィルムとなるAVクリップが多くのプレイアイテム情報から参照されるとなると、参照されるプレイアイテム情報毎に、使用する音声や字幕、メニューを変化させたいという要望がでてくる。このように、参照されるプレイアイテム情報毎に、使用する音声や字幕、メニューを変化させるという目的のため、プレイアイテム情報には、上述したストリーム選択テーブルが存在する。このストリーム選択テーブルを用いれば、メインパスとなるプレイアイテム情報から参照されるAVクリップに多重化されているエレメンタリストリーム、サブパスとなるサブプレイアイテム情報から参照されるAVクリップに多重化されているエレメンタリストリームのうち、バンクシーンの引用先にとって最適なもののみの再生を許可することができる。
以上がプレイアイテム情報についての説明である。
２）従たる再生区間情報は、サブパス情報と呼ばれ、複数のサブプレイアイテム情報から構成される。図１８（ｄ）は、サブプレイアイテムの内部構成を示す。本図に示すように、サブプレイアイテム情報は、STCシーケンスの時間軸にインタイムと、アウトタイム
との組みを規定することで、サブパスを構成する再生区間を定義する情報であり、「ストリーム参照情報」、「インタイムアウトタイム情報」、「シンクロプレイアイテムレファレンス」、「シンクロ開始時刻情報」を含む。
『ストリーム参照情報』は、プレイアイテム情報と同様、『クリップ情報ファイルネーム情報』『クリップ符号化方式識別子』、『STC識別子レファレンス』を含む。
『インタイムアウトタイム情報(SubPlayItem＿In＿Time,SubPlayItem＿Out＿Time)』は、STCシーケンス時間軸における、サブプレイアイテムの始点と、STCシーケンス時間軸上における、サブプレイアイテムの終点とを示す。
「シンクロプレイアイテムレファレンス(Sync＿PlayItem＿Id)」は、プレイアイテムのうち、本サブプレイアイテムが同期すべきものを一意に指定する情報である。サブプレイアイテムインタイムは、この同期プレイアイテム参照子で指定されたプレイアイテムの再生時間軸上に存在する。
「シンクロ開始時刻情報(Sync＿Start＿PTS＿of＿PlayItem)」は、同期プレイアイテム参照子で指定されたプレイアイテムのSTCシーケンスの時間軸のうち、サブプレイアイテムイ
ンタイムで指定されたサブプレイアイテムの始点が、どの時点に写像されるかを示す
３）プレイリストマーク情報は、再生区間固有のマークポイントを定義する情報であり、再生区間を示す参照子と、デジタルストリームの時間軸において、マークポイントが何処にあるかを示すタイムスタンプと、マークポイントの属性を示す属性情報とを含み、
前記属性情報は、プレイリストマーク情報により定義されたマークポイントが、リンクポイントであるか、エントリーマークであるかを示す。
リンクポイントは、リンクコマンドによるリンクが可能であるが、チャプタースキップ操作がユーザによりなされた場合の選択対象にはならないマークポイントである。
エントリーマークは、リンクコマンドによるリンクが可能であり、尚且つチャプタースキップ操作がユーザによりなされた場合の選択対象になるマークポイントである。
IGストリームのボタン情報内に組込まれたリンクコマンドは、プレイリストマーク情報を介した間接参照の形式で頭出し位置を指定している。

＜基本ストリーム選択テーブル(STreamNumber＿table)＞
前記基本ストリーム選択テーブルは、プレイリストを構成する複数のプレイアイテムのうち、その基本ストリーム選択テーブルを包含しているのものがカレントプレイアイテムになった際、マルチパスのメインパスにて参照されているAVクリップに多重化されているES、及び、マルチパスのサブパスにて参照されているAVクリップに多重化されているESのうち、どれの再生を許可するかを、複数のストリーム種別毎に規定するテーブルである。ここでのストリーム種別とは、ピクチャインピクチャにおけるプライマリビデオストリーム、ピクチャインピクチャにおけるセカンダリビデオストリーム、サウンドミキシングにおけるプライマリオーディオストリーム、サウンドミキシングにおけるセカンダリオーディオストリーム、PG＿テキスト字幕ストリーム、インタラクティブグラフィクストリームといった種別をいい、基本ストリーム選択テーブルは、これらのストリーム種別毎に、再生を許可すべきストリームを登録することができる。具体的には、基本ストリーム選択テーブルは、ストリーム登録の配列から構成される。ここでストリーム登録とは、基本ストリーム選択テーブルが帰属しているプレイアイテムがカレントプレイアイテムになった際、再生を許可すべきESがどのようなストリームであるかを、そのストリーム番号に対応付けて示すものであり、ストリーム登録は、論理的なストリーム番号に、ストリームエントリー及びストリーム属性の組合せを対応付けるというデータ構造になっている。
ストリーム登録におけるストリーム番号は、１、２、３というような整数値で表現され、ストリーム番号の最大数は、対応するストリーム種別のストリーム本数となる。
再生装置には、このストリーム種別毎に、ストリーム番号レジスタが存在しており、ここに格納されたストリーム番号で指示されるESが、現在再生対象になっているES、つまりカレントストリームになる。
このストリームエントリー内に、再生すべきESのパケット識別子が記述される。ストリームエントリー内に、再生すべきESのパケット識別子を記述することができるので、ストリーム登録におけるストリーム番号を再生装置のストリーム番号レジスタに格納し、ストリーム登録におけるストリームエントリー内のパケット識別子に基づいて再生装置のPID
フィルタにパケットフィルタリングを再生装置に実行させる。こうすることで、基本ストリーム選択テーブルにおいて再生が許可されたESのTSパケットがデコーダに出力され、ESの再生がなされることになる。
基本ストリーム選択テーブルにおけるこれらのストリーム登録は、ストリーム番号の順序に従って並べられており、ストリーム番号の順序に基づくストリーム登録の順位は、“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一
致する”の条件を満たすストリームが複数存在する場合、ストリーム登録列におけるストリーム番号の順位によって、選択対象となるストリームが決定される。
こうすることで、基本ストリーム選択テーブルにおけるストリーム登録の中に、再生装置が再生できないものが存在する場合、かかるストリームは再生から除外されることになり、また、“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”との条件を満たすストリームが複数存在する場合は、それらのうちどれを優先的に選択すべきかという指針をオーサリング者は再生装置に伝えることができる。
“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”の条件を満たすストリームが存在するかどうかという判定や、“再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”との条件を満たすストリームのうちどれを選択するかという選択手順は、ストリーム選択プロシージャと呼ばれる。ストリーム選択プロシージャは、カレントプレイアイテムが新しいものに切り替った際、また、ユーザからストリーム切り替えが要求された際、実行される。
カレントプレイアイテムが新しいものに切り替わる等、再生装置の状態変化が生じた際、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を“状態変化時に実行すべきプロシージャ”という。ストリーム番号レジスタは、ストリーム種別毎に存在するから、上記プロシージャは、ストリーム種別ごとに実行されることになる。
ストリーム切り替え要求がユーザによってなされた場合、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を“ストリーム変化が要求された際のプロシージャ”という。
BD-ROMが装填された際、ストリーム番号レジスタをストリーム登録列における初期値に設定しておくとの手順を、“初期化”という。
基本ストリーム選択テーブルにおけるストリーム登録列は、サブプレイアイテム情報によって指定されているストリームと、プレイアイテム情報によって指定されているストリームとに一律に優先順序を付与しているので、ビデオストリームとは多重化されていないストリームであっても、サブプレイアイテム情報によって指定されていれば、ビデオストリームと同期再生すべきストリームの選択にあたっての選択の対象となる。
そして、サブプレイアイテム情報にて指定されたストリームを再生装置が再生することができ、尚且つ、サブプレイアイテム情報にて指定されたストリームの優先順序がビデオストリームと多重化されたグラフィクスストリームの優先順序よりも高い場合は、ビデオストリームと多重化されたストリームの代わりに、サブプレイアイテム情報にて指定されたストリームを再生に供することができる。

図１９は、基本ストリーム選択テーブルの一例を示す。同図（ａ）は、ストリーム種別に、プライマリビデオストリーム、セカンダリビデオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリームといった種別が存在する場合に、基本ストリーム選択テーブルに設けられる複数のストリーム登録列を示す。同図（ｂ）は、基本ストリーム選択テーブルにより、メインTS,サブTSから、どのよ
うなESが分離されるかを示す。同図左側は、メインTS、サブTSを示し、真ん中は、基本ストリーム選択テーブルと、多重分離部とを示す。右側は、基本ストリーム選択テーブルに基づき分離されるプライマリビデオストリーム、プライマリオーディオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリー
ムを示す。
続いて、エクステンションデータの詳細について説明する。
プレイリストがピクチャインピクチャアプリケーションを構成する場合、ピクチャインピクチャメタデータは、プレイリストファイルにおけるエクステンションデータのデータブロックに格納されねばならない。MVCビデオストリームをプレイリスト情報が参照する
場合、拡張ストリーム選択テーブルは、プレイリスト情報ファイルのエクステンションデータにおけるデータブロックに格納されねばならない。
ディスク上のMVCビデオストリームや立体視IGストリーム再生メニューにおけるMVCビデオストリームをプレイリスト情報が参照する場合、サブパス情報の拡張情報（サブパスブロックエクステンション）は、プレイリスト情報ファイルにおけるエクステンションデータのデータブロックに格納されねねばならない。
プレイリスト情報におけるエクステンションデータのその他の目的は、保留されている。
2D再生装置は、プレイリストファイルにおけるエクステンションデータに遭遇した際、未知のエクステンションデータを無視せねばならない。
＜拡張ストリーム選択テーブル(STreamNumber＿table＿StereoScopic(SS))＞
前記拡張ストリーム選択テーブルは、立体視再生モードにおいてのみ、ストリーム選択テーブルと共に使用されるストリーム選択テーブルであり、プレイアイテムの再生や、これに関連するサブパスが再生されている際、選択することができるESを定義する。
前記拡張ストリーム選択テーブルは、立体視再生モードにおいてのみ再生を許可すべきESを示し、ストリーム登録列を含む。ストリーム登録列における個々のストリーム登録情報は、ストリーム番号と、そのストリーム番号に対応するストリームエントリーと、ストリーム属性とを含む。拡張ストリーム選択テーブルは、立体視再生モード固有の拡張を意味するので、各プレイアイテム情報に拡張ストリーム選択テーブル(STN＿table＿SS)が関連付けられているプレイリストを“3Dプレイリスト”という。
拡張ストリーム選択テーブルにおけるストリームエントリーは、再生装置が立体視再生モードに設定されている場合において、対応するストリーム番号が再生装置におけるストリーム番号レジスタに設定された際、再生装置が多重分離に用いるべきパケット識別子を示す。ここで、基本ストリーム選択テーブルとの違いは、拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象にならない点である。つまり、基本ストリーム選択テーブルにおけるストリーム登録列におけるストリーム登録情報は、個々のESの優先順序と解釈され、何れかのストリーム登録情報内のストリーム番号が、ストリーム番号レジスタに書き込まれる。しかし拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象とはならず、拡張ストリーム選択テーブルにおけるストリーム登録情報は、何れかのストリーム番号がストリーム番号レジスタに格納された際、そのストリーム番号に対応するストリームエントリー及びストリーム属性を取り出すという目的のみに用いられる。
2D再生モードから3D再生モードへと再生モードが切り替った際、対象となるストリーム選択テーブルが、基本ストリーム選択テーブルから拡張ストリーム選択テーブルに切り替ったために、ストリーム選択プロシージャを実行したとなると、ストリーム番号の同一性を維持することができず、強いては、言語属性の同一性も失われる可能性がある。
2D再生モードから3D再生モードへの切り替え時に、言語属性を始めとするストリーム属
性の同一性を維持するため、拡張ストリーム選択テーブルの用途を、上記のものにも留めている。
前記拡張ストリーム選択テーブルは、ディペンデントビュービデオストリームのストリーム登録列、PGストリームのストリーム登録列、IGストリームのストリーム登録列から構成される。
拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択テーブルにおける同じストリーム種別のストリーム登録列に結合される。この結合は、ストリーム選択テーブルにおけるプライマリビデオストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるディペンデントビュービデオストリームのストリーム登録列を結合し、ストリーム選択テーブルにおけるPGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録列を結合し、IGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録列を結合することでなされる。
上記の結合がなされれば、結合後のストリーム選択テーブルのうち、基本ストリーム選択テーブルにおけるストリーム登録列に対して上記プロシージャが実行される。
図２０は、拡張ストリーム選択テーブルの内部構成を示す。拡張ストリーム選択テーブルは、拡張ストリーム選択テーブルの全体長(length)、ポップアップ期間固定オフセット(Fixed＿offset＿during＿Popup)、各プレイアイテムにおけるそれぞれのストリーム種別に対応するストリーム登録列から構成される。
ここでプレイアイテム＃1〜＃NというN個のプレイアイテムが存在する場合、プレイア
イテム＃1〜＃Nのそれぞれに対応するストリーム登録列が、拡張ストリーム選択テーブルに設けられる。各プレイアイテムに対応するストリーム登録列は、ディペンデントビューストリーム登録列、PGストリーム登録列、IGストリーム登録列である。
『Fixed＿offset＿during＿Popup』は、ポップアップ期間固定オフセットであり、IGストリームによるポップアップメニューがオンに設定されている場合、ビデオやPG＿テキスト字幕ストリームの再生タイプを制御する。この『Fixed＿offset＿during＿Popup』フィールドは、IGストリームにおけるuser＿interface＿modelフィールドがオン、つまり、ポップアップメニューのユーザインターフェイスがオンに設定されている場合、オンに設定される。IGストリームにおけるuser＿interface＿modelフィールドがオフ、つまり、AlwaysONのユーザインターフェイスに設定されている場合、オフに設定される。
ポップアップ期間固定オフセット”=0”、つまり、IGストリームのユーザインターフェイスにおいてポップアップメニューがオフに設定されている場合、ビデオストリームはB
−Dプレゼンテーションモードとなる。立体視PGストリームは、立体視再生タイプになる
。1plane＋Offsetモードの再生時において、PG＿テキスト字幕ストリームは、1plane＋Offsetモードになる。
ポップアップ期間固定オフセット“１”、つまり、IGストリームのポップアップメニューがオンである場合、ビデオストリームはB−Bプレゼンテーションモードとなる。立体視PGストリームは、1plane＋Offsetモードになり、1plane＋Offset用のPGストリームは、1plane＋Zero offset再生タイプとして再生される。
1plane＋OffsetモードにおいてPG＿テキスト字幕ストリームは、1plane＋Zero offset
になる。
『オフセットシーケンス本数情報(図中のnumber＿of＿offset＿sequence)』は、ディペ
ンデントビューストリームにおけるオフセットシーケンスの個数を示す。
拡張ストリーム選択テーブルにおけるこの値は、ディペンデントビューストリームに含まれるオフセットシーケンスの個数と同じになる。
図２１は、拡張ストリーム選択テーブルにおけるストリーム登録列を示す。
図２１（ａ）は、ディペンデントビュービデオストリームのストリーム登録列の内部構成を示す。ディペンデントビューストリームのストリーム登録列は、v(x)個のSS＿dependet＿view＿blockから構成される。ここで、v(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているプライマリビデオストリームの本数である。図中の引き出し線は、ディペンデントビューストリームのストリーム登録列の内部構成をクローズアップして示している。引出線に示すように、SS＿dependet＿view＿blockは、ストリーム番号と、ストリームエントリーと、ストリーム属性と、number＿of＿offset＿sequenceとから構成される。
ストリームエントリーは、ディペンデントビュービデオストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビュービデオストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイ
ルにおけるディペンデントビュービデオストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
『ストリーム属性』は、ディペンデントビュービデオストリームの言語属性を含む。
『number＿of＿offset＿sequence』は、ディペンデントビュービデオストリーム内に存在するオフセットの本数を示す。
図２１（ａ）においてディペンデントビュービデオストリームのストリーム登録列は、データ構造上、複数のディペンデントビュービデオストリームについてのストリーム登録情報を設けるものになっている。通常、ベースビュービデオストリームの本数は1つであ
るから、ディペンデントビュービデオストリームにおけるストリーム登録情報の個数も唯一つになる。
図２１（ｂ）は、PGストリームのストリーム登録列の内部構成を示す。PGストリームのストリーム登録列は、P(x)個のストリーム登録情報から構成される。ここで、P(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているPGストリームの本数である。
図中の引き出し線は、ストリーム登録列の共通の内部構成をクローズアップして示している。
『PGtextST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリームオフセッ
トシーケンスレファレンス情報であり、1plane＋OffsetモードのPG＿テキスト字幕ストリームについてのオフセットシーケンスを指示する。
オフセットメタデータは、ディペンデントビュービデオストリームのアクセスユニットによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋Offsetモードタイプのプレゼンテーショングラフィクス(PG)プレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。
『is＿SS＿PG』は、PGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する立体視プレゼンテーショングラフィクス存否フラグである。立体視PGストリームにおける構造が存在しない場合、このフィールドは0に設定されねばならない。立体視PGス
トリームにおける構造が存在する場合、このフィールドは1に設定されねばならない。
『stream＿entry＿for＿base＿view』は、ベースビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおける
ベースビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む
。
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該スト
リームファイルにおけるディペンデントビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報に
おけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューPGストリームを格納しているストリームファイルを改めて読み出さねばならない。
『stream＿attribute』は、ベースビューPGストリーム及びディペンデントPGストリー
ムの言語属性を含む。
『SS＿PG＿textST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリーム用
のオフセットシーケンスを参照するためのレファレンス情報であり、PG＿テキスト字幕ストリームのためのオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットをPGプレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。
図２１（ｃ）は、IGストリームのストリーム登録列の内部構成を示す。IGストリームのストリーム登録列は、I(x)個のストリーム登録情報から構成される。ここで、I(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているIGストリームの本数である。図中の引き出し線は、ストリーム登録列の共通の内部構成を
クローズアップして示している。
『IG＿offset＿sequence＿id＿ref』は、インタラクティブグラフィクスオフセットシ
ーケンスレファレンスであり、1plane＋OffsetモードのIGストリームのシーケンスIDのレファレンスである。この値は、オフセットシーケンスに定義されているオフセットシーケンスIDを指示する。上述したように、オフセットメタデータは、ディペンデントビュービデオストリームによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋OffsetモードタイプのIGストリームに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はインタラクティブグラフィクススプレーンに、このオフセットを適用しない。
『IG＿Plane＿offset＿direction＿during＿BB＿video』は、B−Bプレゼンテーション
モードにおいてポップアップメニューのユーザインターフェイスで、IGストリームが再生
されている間、1plane＋Offsetモードにおけるインタラクティブグラフィクス(IG)プレーンにおけるオフセット方向を指示する。
値“０”でフロント設定、つまり、プレーンメモリは、TVと視聴者との間に存在し、レフトビュー期間においてプレーンは右方向に、ライトビュー期間においてプレーンは左方向にシフトされる。
値＝１でビハインド設定、つまり、プレーンメモリは、TV又はスクリーンの背後に存在し、レフトプレーンは左方向に、ライトプレーンは右方向にシフトされる。
『IG＿Plane＿offset＿value＿during＿BB＿video』は、B−Bプレゼンテーションモー
ドでポップアップメニューのユーザインターフェイスによってIGストリームが再生されている間、1plane＋OffsetモードにおけるIGプレーンのオフセット値を画素単位で指示する。
『is＿SS＿IG』は、立体視インタラクティブグラフィクス存否フラグであり、IGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する。立体視IGストリームのデータ構造が存在しない場合、このフィールドは値0に設定されねばならない。再生が許
可されているIGストリームが立体視IGストリームである場合、このフィールドは、値1に
設定されねばならない。
『stream＿entry＿for＿base＿view』は、ベースビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおける
ベースビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む
。
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該スト
リームファイルにおけるディペンデントビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報に
おけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューIGストリームを格納しているストリームファイルを改めて読み出さねばならない。
『stream＿attribute』は、ベースビューIGストリーム及びディペンデントIGストリー
ムの言語属性を含む。
『SS＿IG＿offset＿sequence＿id＿ref』は、立体視タイプのIGストリームのためのオ
フセットシーケンスIDのレファレンスであり、ディペンデントビュービデオストリームのオフセットメタデータにおけるオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットを立体視タイプのIGプレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はIGプレーンに、このオフセットを適用しない。
PG＿テキスト字幕ストリーム用のオフセットシーケンスのレファレンス情報及びIGスト
リーム用のオフセットシーケンスのレファレンス情報は、ストリーム番号に対応付けて、ストリーム登録情報に記載されているため、装置状態の変化時やストリーム変更要求の発生時にストリーム選択プロシージャが実行され、装置側の言語設定に応じたストリーム番号がストリーム番号レジスタに設定された場合、その新たなストリーム番号に対応したレファレンスによって指示されるオフセットシーケンスが、ビデオデコーダからシフト部に供給されることになる。こうすることで、再生装置における言語設定に応じた、最適なオフセットシーケンスがシフト部に供給されるので、1plane＋Offsetモードにおけるグラフィクスの奥行きを、再生装置の言語設定に応じた最適なものにすることができる。
拡張ストリーム選択テーブルにおける制限について説明する。
立体視ディペンデントビューブロックにおけるストリームエントリーは、プレイリストにおいて変化してはならない。
立体視ディペンデントビューブロックにおけるストリームエントリーのタイプがサブパスによって使用されるESタイプ（ストリームタイプ＝２）であれば、サブパスIDレファレンスと、サブクリップエントリーIDレファレンス(ref＿to＿subclip＿entry＿id)とはプレイ
リストにおいて変化しない。
ストリームエントリー、ベースビューのためのストリームエントリー、ディペンデントビューのためのストリームエントリーのタイプとして許されるESのタイプは、プレイアイテムによって使用されるAVクリップ内のES (ストリームタイプ＝１)、サブパスによって使用されるAVクリップ内のES(ストリームタイプ＝２)の2つタイプのみである。
立体視ディペンデントビューブロックにおけるストリーム属性のストリーム符号化方式は、“0x20”に設定される。
図２２は、基本ストリーム選択テーブル、拡張ストリーム選択テーブルによりメインTS、サブTSからどのようなESが多重分離されるかを示す。
本図の真ん中には、多重分離部を示し、その上側には基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとの組みを示す。左側にはメインTS、サブTS、右側には、多重分離されるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリーム、プライマリオーディオストリームを示す。
図２３は、図２２のような多重分離がなされる場合、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。本図の真ん中に基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを示す。
基本ストリーム選択テーブルの左側は、再生装置においてカレントストリームのストリーム番号を格納するストリーム番号レジスタを示す。基本ストリーム選択テーブルの右側は、再生装置における言語設定を示す。拡張ストリーム選択テーブルの下側は、多重分離部を示す。矢印ｈ１は、PGストリームの言語設定と、基本ストリーム選択テーブルにおけるPGストリームのストリーム登録情報Ｘにおける言語属性との一致を模式的に示す。矢印ｈ２は、PGストリームのストリーム番号レジスタへの、ストリーム番号Ｘの設定を模式的に示す。
矢印ｈ３は、IGストリームの言語設定と、基本ストリーム選択テーブルにおけるIGストリームのストリーム登録情報Ｙにおける言語属性との一致を模式的に示す。矢印ｈ４は、IGストリームのストリーム番号レジスタへの、ストリーム番号Ｙの設定を模式的に示す。
本図のストリーム番号の設定は、基本ストリーム選択テーブルに対するストリーム選択プロシージャの結果に応じて、多重分離に供されるPGストリーム、IGストリームが定まること象徴的に示している。
矢印PD1は、拡張ストリーム選択テーブル内のSS＿dependent＿view＿blockにおけるス
トリームエントリーに記述されているパケット識別子の出力を模式的に示す。この出力によって多重分離部における多重分離がなされて、ディペンデントビュービデオストリームが出力される。
矢印PD2は、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録情報
のストリームエントリーのうち、ストリーム番号Ｘに対応するもののパケット識別子の出力を模式的に示す。矢印Ｘ１は、矢印PD1のパケット識別子出力が、ストリーム番号レジ
スタに対するカレントストリーム番号Ｘの設定と連動していることを示す。
矢印PD3は、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録情報
のストリームエントリーのうち、ストリーム番号Ｙに対応するもののパケット識別子の出力を模式的に示す。矢印Ｙ１は、矢印PD3のパケット識別子出力が、ストリーム番号レジ
スタに対するカレントストリーム番号Ｙの設定と連動していることを示す。
ここでの連動とは、基本ストリーム選択テーブルにおけるPG,IGストリームのストリー
ム登録列に記述されたストリーム番号のうち、ストリーム番号Ｘ,Ｙが、カレントのPG,IGストリーム番号としてストリーム番号レジスタに設定されたことに、拡張ストリーム選択テーブルに記載されたパケット識別子の出力が連動していることを意味する。
この出力によって多重分離部における多重分離がなされて、PG,IGストリームが出力さ
れる。
図２４は、モードにおけるストリーム番号の割り当て変化を示す。
縦欄は、ビデオストリーム＃1というストリーム番号、オーディオストリーム＃1、＃2
というストリーム番号、PGストリーム＃1、＃2というストリーム番号を示している。
左側の破線枠にのみ囲まれるESは、2D再生モードにおいてのみ、多重分離の対象になるESである。
右側の破線枠にのみ囲まれるESは、3D再生モードにおいて多重分離の対象になるESを示す。
左側及び右側の破線枠の双方に囲まれるESは、3D再生モードにおいて多重分離の対象になるESを示す。
ビデオストリーム＃1のストリーム番号だけに着目すると、2Dビデオストリームは、左
右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。この2Dビデオストリームは、レフトビュービデオストリームである。しかし、ライトビュービデオストリームは、右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。
オーディオストリーム＃1、オーディオストリーム＃2のストリーム番号に着目すると、オーディオストリームは、左右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。
PGストリーム＃1、PGストリーム＃2のストリーム番号に着目すると、2DPGストリームは、左側の破線枠のみに囲まれるので、2D再生モードのみで再生対象になっていることがわ
かる。ベースビューPGストリーム、ディペンデントビューPGストリームは右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。IGストリームも同様である。
以上より、3D再生モードにおいてビデオストリームというストリーム種別では、ディペンデントビュービデオストリームが再生対象として加わることがわかる。
また3D再生モードにおいてPGストリームというストリーム種別では、再生対象が、2DPGストリームから、ベースビューPGストリーム及びディペンデントビューPGストリームに置き換わっていることがわかる。
前記拡張ストリーム選択テーブルは、オブジェクト指向型コンパイラ言語を用いて、図１９のような記述を行い、コンパイルに供することで作成することができる。図２５は、オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。
PlayItem＿idを制御変数とするfor文は、Fixed＿offset＿during＿Popup、ディペンデ
ントビューストリームのストリーム登録列、PG＿テキスト字幕ストリームのストリーム登録列、IGストリームのストリーム登録列の記述を、プレイアイテムの個数だけ繰り返すループを構成する。
primary＿video＿stream＿idを制御変数とするfor文は、ディペンデントビューストリ
ームのストリーム登録列を定義するものであり、ディペンデントビューストリームのストリーム登録列は、number＿of＿primary＿video＿stream＿entriesだけ、stream＿entry,stream＿attribute,number＿of＿offset＿sequenceからなるSS＿dependent＿view＿block
を記述することで定義される。
PG＿textST＿stream＿idを制御変数とするfor文は、PG＿テキスト字幕ストリームのス
トリーム登録列を定義するものであり、number＿of＿PG＿textST＿stream＿number＿entriesだけ、PG＿text＿offset＿sequence＿id＿ref、is＿SS＿PGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿PGを制御変数としたif文は、is＿SS＿PGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿PGが1bdである場合のみ、ストリーム登録列に追加される。is＿SS＿PGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。
IG＿stream＿idを制御変数とするfor文は、IGストリームのストリーム登録列を定義す
るものであり、number＿of＿IG＿stream＿entriesだけ、IG＿offset＿sequence＿id＿ref、IG＿plane＿offset＿direction＿during＿BB＿video、IG＿plane＿offset＿value＿during＿BB＿video、is＿SS＿IGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿IGを制御変数としたif文は、is＿SS＿IGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿IGが1bdである場合のみ、ストリ
ーム登録列に追加される。is＿SS＿IGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。
以上が記録媒体についての説明である。続いて、再生装置の詳細について説明する。
図２６は、再生装置の内部構成を示す。本図に示すように再生装置は、読出部２０１、
メモリ２０２、プレーヤ番号レジスタ２０３、デコーダ２０４、多重分離部２０５、プレーンメモリセット２０６、シフト部２０７、レイヤ合成部２０８、送受信部２０９、再生制御部２１０、出力モードレジスタ２１１、コンフィグレーションメモリ２１２から構成される。本図の内部構成は、課題解決手段を具備した再生装置を実施するための必要最低限の構成要素を記述したに過ぎない。より詳細な内部構成については、後段の実施形態に説明の場を譲る。
読出部２０１は、記録媒体からインデックステーブル、動作モードオブジェクトのプログラムファイル、プレイリスト情報ファイル、ストリーム情報ファイル、ストリームファイルを読み出す。
メモリ２０２は、プレイリスト情報に含まれる基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを結合することで得られた結合ストリーム登録列を格納する。
ストリーム種別毎のプレーヤ番号レジスタ２０３は、ビデオストリームのストリーム番号を格納するビデオストリーム番号レジスタ、PGストリームのストリーム番号を格納するPGストリーム番号レジスタ、IGストリームのストリーム番号を格納するIGストリーム番号レジスタ、オーディオストリーム番号を格納するオーディオストリーム番号レジスタを含む。
ストリーム種別毎のデコーダ２０４は、ビデオデコーダ、PGデコーダ、IGデコーダ、オーディオデコーダから構成される。
多重分離部２０５は、パケットフィルタリングを実行するPIDフィルタを備え、記録媒
体から読み出された複数のソースパケット内のTSパケットのうち、結合ストリーム登録列に記載されたパケット識別子によって指示されているものを分離して、各デコーダに出力する。
プレーンメモリセット２０６は、複数のプレーンメモリから構成される。
これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。
シフト部２０７は、画素の座標のシフトを実行する。
レイヤ合成部２０８は、複数のプレーンメモリにおけるレイヤ合成を行う。
送受信部２０９は、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、相互認証フェーズと、ネゴシエーションフェーズを経て、データ伝送フェーズに移行し、データ伝送を行う。
このネゴシエーションフェーズは、相手側機器のケーパビリティ(デコード能力、再生
能力、表示周波数を含む)を把握して、プレーヤ設定レジスタに設定しておき、以降の伝
送のための伝送方式を定めるものである。これらの相互認証フェーズ、ネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮・平文形式の画素データを、表示装置における水平同期期間に従い表示装置に高い転送レートで転送する。一方、表示装置における水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置(表示装置のみならずアンプ、スピーカを含む)に、非圧縮・平文形式のオーディオデータを転送する。こうすることで、表示装置、アンプ、スピーカといった機器は、非圧縮・平文形式のピクチャデータ、非圧縮・平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮・暗号化形式のまま伝送することができる。
再生制御部２１０は、読出部２０１を制御して、記録媒体からのインデックステーブル、動作モードオブジェクト、プレイリスト情報、クリップ情報、ストリームファイルを記録媒体から読み出すとともに、記録媒体から読み出されたプレイリスト情報、クリップ情報に基づく再生制御を実行する。ストリームファイルの読み出しにあたっては、時間軸の任意の時点に相当するソースパケットを、ストリームファイルから読み出すというランダムアクセスを実現することができる。
出力モードレジスタ２１１は、再生モードを記憶している。
コンフィグレーションメモリ２１２は、各プレーンメモリのモードケーパビリティと、カレントモードとを記憶する不揮発性メモリであり、再生装置の製造主体によって、その記憶内容が設定される。モードケーパビリティとは、ビデオプレーン、PGプレーン、IGプレーンといった複数のプレーンメモリのそれぞれが、上述したような再生モードのそれぞれを処理することができるか否かを示す。再生モードを処理できるかどうかは、プレーンメモリに対応するストリーム種別が何であるか、また、その再生モードを処理するためのハードウェア構成が再生装置に存在するか否かによって決まる。
カレントモードは、複数のプレーンメモリのそれぞれが、複数の再生モードのうち、どれに設定されているかを示す。
以上が再生装置についての説明である。続いて、本実施形態に係る再生装置による多重分離処理の詳細について説明する。
図２７は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
同図（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ス
トリーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。
基本ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム
番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけ
るストリーム属性は、英語、日本語、中国語の言語属性を有している。
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリー
ム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報にお
けるストリーム属性は、英語、日本語、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa1、a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号レジスタへの
ストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この
際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、基本ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
同図（ｃ）は、言語設定が中国語であり、出力モードがB−Dプレゼンテーションモードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号レジスタに対するストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。
図２８は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ストリ
ーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。基本
ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号
“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけるス
トリーム属性は、何れかも中国語の言語属性を有している。
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリー
ム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報にお
けるストリーム属性も、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa1,a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝“１”がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで
、基本ストリーム選択テーブルにおけるストリーム番号“１”のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
同図（ｃ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号“１”のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号“１”のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号“１”のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。
図２９は、再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のディペンデントビューストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、ディペンデントビュービデオストリームを構成するTSパケット、ベースビューPGストリームを構成するTSパケット、ディペンデントビューPGストリームを構成するTSパケット、ベースビューIGストリームを構成するTSパケット、ディペンデントビューIGストリームを構成するTSパケットがデコーダに出力されることがわかる。
図３０は、再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、シフト部との間の矢印は、拡張ストリーム選択テーブルにおけるPGストリームに対応するストリーム登録列におけるオフセットレファレンス、及び、拡張ストリーム選択テーブルにおけるIGストリームに対応するストリーム登録列におけるオフセットレファレンスが1plane＋Offsetモードにおいて参照されていることを示す。
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オ
ーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
ビデオデコーダと、シフト部との矢印は、上述したようなオフセットレファレンスに基づき、ディペンデントビュービデオストリームにおけるオフセットがPGストリームについてのシフト部、IGストリームについてのシフト部に供給されていることを示す。
図３１は、再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
図３２は、再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、基本ストリーム選択テーブルのストリーム登録列におけるストリームエントリーによって指示されているTSパケットが各デコーダに出力されているかを示す。
以上の再生制御は、図３３から図３５までのフローチャートに示される処理手順をオブジェクト指向型コンパイラ言語で記述してコンピュータに実行させることで実現することができる。
図３３は、プレイリスト再生手順を示す。本フローチャートは、ステップＳ１においてカレントプレイアイテム番号を１に設定した後、ステップＳ２〜ステップＳ６の処理を繰り返すループを構成する。このループでは、ストリーム選択プロシージャによりストリーム番号を決定して(ステップＳ２)、ストリーム番号に対応するESを格納したストリームファイルをオープンしてソースパケット列を読み出し(ステップＳ３)、読み出されたソースパケット列のうち、ストリーム番号に対応しているものの多重分離を指示し(ステップＳ
４)、読み出されたソースパケットをプレイアイテムのインタイムからアウトタイムまで
、サブプレイアイテムのインタイムからアウトタイムまで再生するようデコーダに命じる(ステップＳ５)という処理を、カレントプレイアイテム番号が最終番号になるまで繰り返
すものである。ここで最終番号でなければ(ステップＳ６でNo)、カレントプレイアイテム番号がインクリメントされて、ステップＳ２に移行する。最終番号であれば、処理を終了する(ステップＳ６でYes)。
図３４は、ストリーム選択プロシージャの処理手順を示す。
本フローチャートでは、カレントプレイアイテム情報内の基本ストリーム選択テーブルをカレント基本ストリーム選択テーブルに設定する(ステップＳ７)。そして、ステップＳ８〜ステップＳ１７のループを実行する。ステップＳ８〜ステップＳ１７は、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップＳ１０〜ステップＳ１７の処理を繰り返すものである。ステップＳ１０は、カレント基本ストリーム選択テーブルにおける、ストリームｘに対応する基本ストリーム選択テーブルエントリー数が0であるか否かの判定であ
り、ステップＳ１１は、カレントストリームにおけるストリームｘに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。
ステップＳ１０、ステップＳ１１の何れかがYesであれば、ステップＳ１７においてス
トリーム番号レジスタに格納されているストリーム番号を維持する。
ステップＳ１０、ステップＳ１１の何れもがNoであれば、カレント基本ストリーム選択テーブルに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定
して(ステップＳ１２)、満たすと判定された条件の組合せが同一となるPESストリームが
複数存在するか否かを判定する(ステップＳ１３)。
条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを
選択する(ステップＳ１４)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレント基本ストリーム選択テーブルにおける優先順位が最も高いものを選択する(ステップＳ１５)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号
レジスタに書き込む(ステップＳ１６)。
以上の過程を経て、カレントプレイアイテムにおいて再生すべきPESストリームが確定
すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedure when playback condition is changedによって確定した出力モードに応じたものとなる。
図３５は、ストリーム番号に対応するパケット識別子の出力処理の手順を示す。ステップＳ１７、ステップＳ１８の判定ステップを実行する構造になっている。ステップＳ１７は、カレントの出力モードが2D再生モードであるか否かの判定であり、もし2D再生モードであれば、ステップＳ３８において、基本ストリーム選択テーブルにおけるストリーム登録列のうち、カレントストリーム番号に対応するストリーム登録情報のストリームエントリーに基づく多重分離を多重分離部に指示する。
ステップＳ１８は、拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであるか否かの判定である。ステップＳ１７がNo、ステップＳ１８がNoであれば、ステップＳ１９〜ステップＳ３０を実行する。
ステップＳ１７〜ステップＳ３０は、ビデオストリームを立体視B−Dタイプに設定してビデオプレーンをB−Dプレゼンテーションモードに設定し(ステップＳ１９)、SS＿dependent＿View＿blockにおけるストリームエントリーのパケット識別子に基づく多重分離を指
示して(ステップＳ２０)、ステップＳ２１〜ステップＳ２６の処理を実行する。
ステップＳ２１は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ２２において、PGストリームを立体視再生タイプに設定して、PGプレーンをB−Dプレゼンテーションモードにし(ステ
ップＳ２３)、カレントPGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示す
る。
is＿ss＿PGがオフであれば、PGストリームを1plane＋Offset再生タイプに設定して、PGプレーンを、1plane＋Offsetモードに設定し(ステップＳ２４)、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示される
オフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ
２５)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ２６)。
ステップＳ２７は、カレントIGストリームのストリーム登録情報におけるis＿ss＿IGがオンであるか否かの判定であり、オンであれば、ステップＳ２８において、カレントIGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示する。
is＿ss＿IGがオフであれば、カレントIGストリームのストリーム登録情報におけるSS＿IG＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビ
ュービデオストリームから取得し(ステップＳ２９)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３０)。
拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであれば、ステップＳ１７がNo、ステップＳ１８がYesになって、ステップＳ３１〜ステップＳ３７を実行
する。
ステップＳ３１〜ステップＳ３７は、ビデオストリームを立体視B−Bタイプに設定して、ビデオプレーンをB−Bプレゼンテーションモードに設定し(ステップＳ３１)、ステップＳ３２〜ステップＳ３７の処理を実行する。
ステップＳ３２は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ３３において、PGストリームを1plane＋Offsetモードタイプに設定して、PGプレーンを1plane＋Offsetモードに設定し、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリー
ムから取得し(ステップＳ３４)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３５)。その後、ステップＳ３７に移行する。
is＿ss＿PGがオフであれば、ステップＳ３６においてPGストリームを1plane＋Zero Offsetモードタイプに設定して、PGプレーンを1plane＋Zero Offsetモードに設定する。その後、ステップＳ３７に移行する
ステップＳ３７では、カレントIGストリームのストリーム登録列におけるIG＿Plane＿offset＿direction＿during＿BB＿videoによって示される方向に対して、ストリーム登録
列におけるIG＿Plane＿offset＿value＿during＿BB＿videoによって示される量だけ、プ
レーンシフトを実行する。以上の処理により、Fixed＿offset＿during＿Popupがオンの設定時には、平面的な動画像に、立体的な字幕やメニューが合成された立体視映像を再生に
供することができる。
図３６は、PGプレーンシフトの処理手順を示すフローチャートである。
ステップS６０は、PGであるか、テキスト字幕であるかの判定である。PGストリームで
あれば、ステップS６１〜ステップS７４のループに移行する。この二重ループは、変数i
、jを0で初期化して(ステップS６１)、カレントストリームのPG＿textST＿offset＿sequence＿id＿refで指示されるoffset＿sequence＿idを有するオフセットシーケンスのうち、GOP(i)
のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]をビデオデコーダから取得し(
ステップS６２)、GOP(i)のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]を用いてプレーンシフトを実行するという処理を繰り返すものである。この変数iを用いたルー
プの終了条件は、ステップS６９において変数iがnumber＿of＿offset＿sequenceになったと
判定されることであり、この条件が満たされるまで、ステップS７０変数iがインクリメントされて、ステップS６２に戻るとの処理が繰り返される。
ステップS６３〜ステップS６８のループは、GOPのフレームにおけるベースビューの水
平表示期間が開始されるのを待ち(ステップS６３)、開始されれば、ステップS６４においてフレーム(ｊ)のピクチャデータにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]の画素数だけシフトして、その後、GOPのフレームにおけるディペンデントビューの水平表示期間が開始されるのを待ち(ステップS６５)、開始されれば、フレーム(ｊ)のピクチャデータにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは反対の方向に、Plane＿offset＿value[j]の画素数だけシフトするという処理を繰り返すものである。この変数ｊを用いたループの終了条件は、ステップS６７において変数ｊがnumber＿of＿displayed＿frame＿in＿GOPにな
ったと判定されることであり、この条件が満たされるまで、ステップS７８において変数
ｊがインクリメントされて、ステップS６３に戻るとの処理が繰り返される。
図３７は、テキスト字幕ストリームが再生対象である場合のPGプレーンシフトの処理手順を示すフローチャートである。本図の処理構造は、図のものと基本的に同一だが、ステップS６４がステップS７１、ステップS７２に、ステップS６５がステップS７３に置き換
えられている。
ステップS７１は、フレームに用いるべきオフセットのPGプレーンにおける描画領域毎
の補間値を取得する。ステップS７２は、PGプレーンにおける各描画領域の画素を、Ｘ軸
のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]＋補間値の画素数だけシフトさせる。
ステップS７３は、PGプレーンにおける各描画領域の画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは逆の方向に、Plane＿offset＿value[j]＋補間値の画素数だけ
シフトさせる。
図３８は、IGプレーンのプレーンシフトを示すフローチャートである。本図の処理構造は、図３６のものと基本的に同一だが、ステップS６０がステップS７４に置き換えられ、ステップS６２がステップS７５に置き換えられ、ステップS６４がステップS７６に置き換えられ、ステップS６６がステップS７７に置き換えられている点が異なる。
ステップS７４は、STN＿table＿SSのFixed＿offset＿during＿Popupがオンかどうかの判定であり、NoであればステップS６１に、YesであればステップS７８に移行する。
ステップS７５は、カレントストリームのSS＿IG＿offset＿sequence＿id＿refで指示されるoffset＿sequence＿idを有するオフセットシーケンスのうち、GOP(i)のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]をビデオデコーダから取得する。
ステップS７６は、IGプレーンにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]の画素数だけシフトする。
ステップS７７は、IGプレーンにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは反対の方向に、Plane＿offset＿value[j]の画素数だけシフトす
る
図３９は、STN＿table＿SSのFixed＿offset＿during＿Popupがオンである場合のIGプレーン
のプレーンシフトの処理手順を示すフローチャートである。本図に示される処理構造は、図のものと基本的に同一だが、ステップS６２がステップS７８に置き換えられ、ステップS６４がステップS７９に、ステップS６６がステップS８０に置き換えられている点が異なる。
ステップS７８は、STN＿table＿SSのカレントストリームにおけるIG＿plane＿offset＿direction＿during＿BB＿video、IG＿plane＿offset＿value＿during＿BB＿videoを取得する。
ステップS７９は、IGプレーンにおける各ラインの画素を、Ｘ軸のIG＿plane＿offset＿direction＿during＿BB＿videoに示される方向に、IG＿plane＿offset＿value＿during＿BB＿videoの
画素数だけシフトする。
ステップS８０は、IGプレーンにおける各ラインの画素を、Ｘ軸のIG＿plane＿offset＿direction＿during＿BB＿videoに示される方向とは逆の方向に、IG＿plane＿offset＿value＿during＿BB＿videoの画素数だけシフトする。
以上のように本実施形態によれば、1plane＋Offsetモードの制御のための制御情報の置き場所が、ディペンデントビューストリーム内に規定されているので、3Dカメラが撮影の際に得た奥行きの情報や、ビデオストリームを生成するためのエンコーダがエンコードの過程で得た視差の情報に基づき制御情報を生成して、ディペンデントビュービデオストリーム内にメタデータとして組み入れることで、1plane＋Offsetモードにおけるオフセット制御のための制御情報は簡易に生成されることになる。そうすればオーサリング行程での作業は、大きく省略されることになる。制御情報は、1plane＋Offsetモードにおけるオフセット制御を規定するので、左右の字幕やメニューが存在しなくても、字幕やメニューが1つさえあれば、立体視の再生が可能になる。レフトビュー、ライトビューのそれぞれに
ついて字幕やメニューを作成するという手間が軽減されるばかりか、再生装置におけるプレーンメモリのためのメモリ規模が、ワンプレーンであっても、立体視再生を実現することができるので、オーサリングの効率化と、再生装置の低コスト化の両立を実現することができる。
(第２実施形態)
第１実施形態では、ディペンデントビューデータブロックを構成するサブTSをサブクリップエントリーIDレファレンスから参照していたため、サブTSがメインTSと分離して記録されている場合、2D再生モードから3D再生モードへの切替え時において、サブTSの読み出しが発生し、AV再生のシームレス性が損なわれる恐れがある。そこで本実施形態は、メインTSと、サブTSとが共に再生装置に読み込まれることを保障する改良を提案する。具体的には、メインTS、サブTSをインターリーブ化して、2TSを1ファイルとして記録することを提案する。
前提事項として、UDFファイルシステムにおけるファイルについて簡単に説明する。UDFにおけるファイルは、ファイルエントリーによって管理されている複数のエクステントから構成される。「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケ
ーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261”が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号（LBN）を含む。アロケーション記述子
は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位２ビットは、“０”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“１”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“０”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
上述したようなファイルエントリーのアロケーション識別子を参照することで、ストリームファイルを構成するエクステントのアドレスを知得することができる。
次に、本実施形態で想定されているファイルの種別について説明する。
＜立体視インターリーブドストリームファイル(FileSS)＞
立体視インターリーブドストリームファイル(FileSS)は、2TSをインターリーブ形式に
したストリームファイル(2TSインターリーブファイル)であり、５桁の整数値と、立体視
再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。立体視インターリーブドストリームファイルは、エクステントSS[n]から構成され、
エクステントSS[n](EXTSS[n])は、インデックス番号nによって特定される。インデックス番号nは、立体視インターリーブドストリームファイルの先頭から1つずつインクリメントされる番号である。
エクステントSS[n]は、ディペンデントビューデータブロックと、ベースビューデータ
ブロックとの組みとして構成される。
エクステントSS[n]を構成するベースビューデータブロック、ディペンデントビューデ
ータブロックは、ファイル2D、ファイルベース、ファイルディペンデントからのクロスレファレンスの対象となる。クロスレファレンスとは、記録媒体に記録された1つのデータ
客体を、複数のファイルのエクステントとして、ファイルエントリーに登録しておくことをいう。本実施形態では、ファイル2Dのファイルエントリー、ファイルベースのファイルエントリー、ファイルディペンデントのファイルエントリーに、ベースビューデータブロック、ディペンデントビューデータブロックの先頭アドレス及び連続長が登録されることになる。
＜ファイルベース(FileBase)＞
ファイルベース(FileBase)は、ファイル2Dに対応するクリップ情報におけるエクステントスタートポイント情報によって指示されるメインTSを“格納している”とされる仮想的なストリームファイルであり、少なくとも1つのエクステント1[i](EXT1[i]と呼ぶ)によって構成される。エクステント1[i]は、ファイルベースにおけるi番目のエクステントであ
り、iは、エクステントのインデックス番号であり、ファイルベースの先頭を0としてインクリメントされる。ファイルベースは、2TSファイルである立体視インターリーブドスト
リームファイルを、1TSファイルとして扱うための仮想的なストリームファイルであり、
そのファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
実際の読み出しにあたって、ファイルベースは、この立体視インターリーブドストリー
ムファイルのファイル名を用いてファイルオープンを行うことで特定される。具体的にいうと再生装置のミドルウェアは、立体視インターリーブドストリームファイルのファイル名を用いたファイルオープンがコールされた場合、ファイルベースのエクステントを特定するファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする。立体視インターリーブドストリームファイルは、“1TSのみを包含している”とみなす
ことができ、2TSの立体視インターリーブドストリームファイルを1TSのファイルベースとして記録媒体から読み出すことができる。
B−Bプレゼンテーションモードにおいて、ベースビューデータブロックのみを読み出したい場合は、このファイルベースを構成するエクステントのみが読み出しの対象になる。B−BプレゼンテーションモードからB−Dプレゼンテーションモードへのモード変更があったとしても、読出範囲を、ファイルベースを構成するエクステントの記録範囲から、立体視インターリーブドストリームファイルを構成するエクステントの記録領域に拡大すれば、ベースビューデータブロック、ディペンデントビューデータブロックの双方を読み出すことができるから、ファイル読み出しの効率性を低下させることはない。
＜ファイルディペンデント(FileDependent)＞
ファイルディペンデント(FileDependent)は、サブTSを“格納している”とされるスト
リームファイルであり、エクステント2[i](EXT2[i])によって構成される。EXT2[i]は、ファイルディペンデントにおけるi番目のエクステントであり、iは、エクステントのインデックス番号であり、ファイルディペンデントの先頭を0としてインクリメントされる。フ
ァイルベースは、2TSファイルである立体視インターリーブドストリームファイルを、サ
ブTSを格納した1TSファイルとして扱うための仮想的なストリームファイルであり、その
ファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
ディペンデントビュービデオストリームは、立体視インターリーブドストリームファイルのファイル名である5桁番号に、1を加算した番号がファイル名として付与される。このファイル名を用いてアクセスされる。記録媒体には、ダミーファイルが記録されていて、ディペンデントビュービデオストリームの識別番号である、「１を加算した番号」がこのダミーファイルに付与される。ダミーファイルとは、ファイル名のみが存在していて、実体であるエクステントが存在しないファイルであり、ディペンデントビュービデオストリームは、このダミーファイルに格納されるとして扱われる。
＜ファイル2D(File2D)＞
ファイル2Dは、2D再生モードにおいて再生されるメインTSを格納している1TSのストリ
ームファイルであり、エクステント2Dから構成される。ファイル2Dは、５桁の整数値と、立体視再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。
以下、ファイル２Ｄ／ファイルベース、ファイルディペンデントの相互関係について説明する。図４０は、エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。
第１段目は、ファイル2D／ファイルベース、ファイルディペンデントである00001.m2ts,00002.m2tsを示し、第２段目は、ベースビューデータブロックを格納したエクステント
、ディペンデントビューデータブロックを格納したエクステントを示す。第３段目は、立体視インターリーブドストリームファイルである00001.ssifを示す。
破線の矢印h1,h2,h3,h4は、エクステントEXT1[i],EXT2[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関
係によると、エクステントEXT1[i],EXT1[i+1]は、ファイルベースである00001.m2tsのエ
クステントとして登録されていることがわかる。
矢印h3,h4に示される帰属関係によると、エクステントEXT2[i],EXT2[i+1]は、ファイルディペンデントである00002.m2tsのエクステントとして登録されていることがわかる。
矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT1[i],EXT2[i],EXT1[i+1],EXT2[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT1[i],EXT1[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この“ssif”という拡張子は、StereoScopic Interleave Fileの頭文字をとったものであり、立体視再生のため、インター
リーブ形式になっていることを示す。
図４１は、立体視インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。
同図（ａ）の第３段目は、インターリーブドストリームファイルの内部構成を示す。ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のそれぞれと、ディ
ペンデントビューデータブロックを格納したエクステントEXT2[1],EXT2[2]のそれぞれと
が交互配置されることで構成される。
第１段目は、ファイル2D及びファイルベースの内部構成を示す。ファイル2D／ファイルベースは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のみか
ら構成されている。ファイル2Dのファイル名は、インターリーブドストリームファイルのファイル名が同一だが、拡張子が異なる。
第２段目は、ファイディペンデントの内部構成を示す。ファイディペンデントは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ディペンデントビューデータブロックを格納するエクステントEXT2[1],EXT2[2],EXT2[2]のみ
から構成されている。ファイルディペンデントのファイル名は、インターリーブドストリームファイルのファイル名に1を加算したものになっており、また拡張子が異なる。
3D映像を含む光ディスクであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2Dストリームにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。
１つ目の方法は、上述したようなプレイリスト情報の参照、つまり、メインTSは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のストリームファイルは拡張子を変える方法である。同図（ｂ）における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名“00001”によって
カップリングされている。
プレイリストは、メインTSのAVクリップしか参照しないため、既存の2D再生装置ではファイル２Ｄしか再生しない。3D対応の再生装置は、プレイリストはメインTSの入ったファイル２Ｄしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のストリームファイルであると判断して、メインTSと、サブTSとを出力する。
２つ目の方法は、フォルダを分ける方法である。メインTSは既存のフォルダ名（例：STREAM）を持つフォルダ内に格納しておくが、サブTSは、3D特有の名前を持つフォルダ（例：SSIF）に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照す
る際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、メインTSと、サブTSとを関連づけることが可能となる。
３つ目の方法は、識別番号によるものである。ファイル２Ｄ／ファイルベースの識別番号が“００００１”である場合、ファイルディペンデントの識別番号は、同図（ｃ）に示すようにこのレフトビューの識別番号に“１”を加算した番号、つまり、“０００２”という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。しかし記録媒体のファイルシステムにおいて、上述のルールで命名されたファイルディペンデントは、あくまでも実体のないダミーファイルとして扱われる。これは、ファイルディペンデントの実体は、立体視インターリーブドストリームファイルに過ぎないとの理由による。
こうして関連付けられたファイル名を、基本ストリーム選択テーブルにおけるストリーム登録情報、及び、拡張ストリーム選択テーブルにおけるストリーム登録情報におけるストリームエントリーのサブクリップエントリーIDレファレンス(ref＿to＿subclip＿entry＿id)に記述しておく。一方、再生装置については、サブクリップエントリーIDレファレンス
に記述された識別番号に“1”を加算した識別番号のファイル名は、ダミーファイルのフ
ァイル名であると認証して、ファイルディペンデントを仮想的にオープンする処理を実行する。こうすれば、ストリーム選択プロシージャにおいて、上述したような関連付けがなされたファイルディペンデントが確実に記録媒体から読み出されることになる。
以上が、ファイル２Ｄ、ファイルベース、ファイルディペンデントについての説明である。
以下、データブロックの詳細について説明する。
＜ベースビューデータブロック＞
ベースビューデータブロック(B[i])は、メインTSのi番目のデータブロックである。こ
こで、メインTSとは、カレントプレイアイテム情報のクリップ情報ファイル名情報(クリ
ップ情報ファイルネーム情報)を通じて、メインパスの基軸として指定されているTSであ
る。B[i]の“i”は、ファイルベースの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
ベースビューデータブロックには、ファイルベースと、ファイル2Dとで共通化されるものと、ファイルベースと、ファイル2Dとで共通化されていないものとがある。
ファイル2D及びファイルベースで共通化されるベースビューデータブロック、及び、ファイル2D固有のベースビューデータブロックは、ファイル2Dのエクステントになるものであり、再生装置におけるバッファアンダーフローを生じさせない長さに設定されている。そしてその先頭のセクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されている。
ファイル2Dと共通化されていないファイルベース固有のベースビューデータブロックは、ファイル2Dのエクステントにはならないから、再生装置におけるシングルバッファをアンダーフローを生じさせない長さに設定されている訳ではない。より小さいサイズ、つまり、再生装置におけるダブルバッファをアンダーフローさせない長さに設定されている。
またファイルベース固有のベースビューデータブロックは、その先頭セクタアドレスが
ファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ベースビューデータブロックにおける先頭ソースパケットのソースパケットが、メインTSに対応するクリップ情報ファイルのクリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ファイルベース固有のベースビューデータブロックの先頭セクタアドレスは、立体視インターリーブドストリームファイルのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
レフトビューがベースビューである場合、ベースビューデータブロックは、レフトビュービデオストリームの分割部分を格納したソースパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)等、2D再生及びレフトビュー再生のための複数種別のPESストリームの分割部分を格納したソースパケットの集合体である。このベースビューデータブロックを構成するパケットは、ATC,STC,SPNが連続しており、ある一定期間のシー
ムレスなAV再生を保障する。
＜ディペンデントビューデータブロック＞
ディペンデントビューデータブロック(D[i])は、サブTSのi番目のデータブロックであ
る。サブTSとは、カレントプレイアイテム情報に対応する拡張ストリーム選択テーブルのストリーム登録列におけるストリームエントリーにおいて、サブパスの基軸として指定されているTSである。D[i]の“i”は、ファイルディペンデントの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
ディペンデントビューデータブロックは、ファイルディペンデントのエクステントになるものであり、再生装置におけるダブルバッファのアンダーフローを生じさせない長さに設定されている。
また、記録媒体の連続領域上で、ディペンデントビューデータブロックは、同じ再生時間で再生されるべきベースビューデータブロックより手前に配置される。そのため、立体視インターリーブドストリームファイルの読み出し時にあたって、ディペンデントビューデータブロックは、必ずベースビューデータブロックより先に読み出されることになる。
ディペンデントビューデータブロックは、ファイル2Dと共通化されていないので、その先頭セクタアドレスが、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ディペンデントビューデータブロックにおける先頭ソースパケットのソースパケットが、クリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ディペンデントビューデータブロックの先頭セクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
ディペンデントビューがライトビューである場合、ディペンデントビューデータブロックは、ライトビュービデオストリームの分割部分を格納したソースパケット、レフトビュー及びライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したソ
ースパケットの集合体である。これらのパケットはATC,STC,SPNが連続しており、ある一
定期間の連続再生を保障する。連続するベースビューデータブロックとディペンデントビューデータブロックとでは、ベースビューデータブロックを構成する複数のソースパケッ
トのATS・SPN、及び、ディペンデントビューデータブロックを構成する複数のソースパケットのATS・SPNは、何れも同じ値になっている。従って、ベースビューデータブロックを構成する複数のソースパケット、及び、ディペンデントビューデータブロックを構成する複数のソースパケットは、同じATC時刻に、PIDフィルタに到達することになる。
＜エクステントの類型＞
上述したように、ファイル2Dのエクステントには、ファイルベースのエクステントと共通のものと、ファイルベースと共通ではないものとがある。
ファイル2Dのエクステントが、B[0]、B[1]、B[2]、B[3]2D、B[4]2Dから構成され、ファイルベースのエクステントがB[0]、B[1]、B[2]、B[3]ss、B[4]ssから構成されるものとする。B[0]、B[1]、B[2]は、ファイルベースと共通化されているベースビューデータブロックである。B[3]2D、B[4]2Dは、ファイルベースと共通化されていない、ファイル2D固有のベースビューデータブロックである。
またB[3]ss、B[4]ssは、ファイル2Dと共通化されていない、ファイルベース固有のベースビューデータブロックである。
B[3]2Dにおけるデータと、B[3]ssのデータとは、bit-for-bitの同一性を有する。B[4]2Dにおけるデータと、B[4]ssのデータとは、bit-for-bitの同一性を有する。
これらのファイル2DにおけるデータブロックB[2]、B[3]2D、B[4]2Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステント（ビッグエクステント）を構成する。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、立体視インターリーブドストリームファイルを2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。
ファイル2D及びファイルベースは、エクステントが一部異なっているものの、同一性を有しているので、これらファイル2D及びファイルベースを併せて、“ファイル2D／ファイルベース”という。
＜ロングジャンプ＞
一般論だが、記録媒体に光ディスクを採用する場合、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。
ジャンプには、光ディスクの回転速度を上下させる操作の他に、トラックジャンプ及びフォーカスジャンプがある。トラックジャンプは、光ピックアップをディスクの半径方向に移動させる操作をいう。フォーカスジャンプは、光ディスクが多層ディスクであるとき、光ピックアップの焦点を一つの記録層から別の記録層へ移動させる操作をいう。これらのジャンプは一般にシーク時間が長く、かつ、ジャンプによって読み出しがスキップされるセクタ数が大きいので、特に「ロングジャンプ」という。ジャンプ期間中、光ピックアップによる読み出し操作は停止する。
ジャンプ期間中、読み出し操作がスキップされる部分の長さを「ジャンプ距離」という。ジャンプ距離は通常、その部分のセクタ数で表される。上記のロングジャンプは具体的には、ジャンプ距離が所定の閾値を超えるジャンプとして定義される。その閾値は、例えばBD-ROMの規格では、ディスクの種類及びドライブの読み出し処理に関する性能により、４００００セクタに規定されている。
ロングジャンプを生じさせる場所の代表的なものとしては、記録層の境界の他、プレイ
アイテム間の１対ｎの多重接続が存在する場所がある。
ここで、1対nのプレイアイテムの多重接続を行う場合、ｎ個のプレイアイテムを構成するn個のTSのうち1つ目のものは、その直前のプレイアイテムを構成するTSの直後に配置することができる。しかし2つ目以降のものは、その直前のプレイアイテムを構成するTSの
直後に配置することができない。１対nの多重接続が存在する場合において、直前のプレ
イアイテムから、ｎ個のプレイアイテムの２個目以降のプレイアイテムへとジャンプする場合、そのジャンプは、1つ以上のTSの記録領域を読み飛ばす必要があるので、１対ｎの
プレイアイテムの多重接続が存在する場所では、ロングジャンプが生じることになる。
＜各モードの再生経路＞
2D再生モードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイル2Dのエクステントから構成される。
B−Dプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照される立体視インターリーブドストリームファイルのエクステントから構成される。
B−Bプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイルベースのエクステントから構成される。
これらの3つのモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファ
イルネーム情報に記述されているファイル名を、ファイル2Dのファイル名として用いてファイルオープンを行うか、ファイルベースのファイル名として用いてファイルオープンを行うか、立体視インターリーブドストリームファイルのファイル名として用いてファイルオープンを行うかで切り替えられる。このような再生経路の切り替えは、カレントプレイリストやカレントプレイアイテムの変動を招かないので、再生モードの変更時のシームレス性を維持することができる。
よって再生装置は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報に基づき立体視インターリーブドストリームファイル、ファイルベース、ファイル2Dの何れかをオープンすることにより、それぞれの再生モードに適合したデータブロックを記録媒体から読み出すことができる。
＜EXT2D、EXT1[n]、EXT2[n]、の具体的な値＞
EXT2Dの下限値は、2D再生モードの再生時、各ベースビューデータブロックから次のベ
ースビューデータブロックまでのジャンプ期間中において、再生装置におけるリードバッファのバッファアンダーフローを生じないように決定される。
ｎ番目のベースビューデータブロックから(n+1)番目のベースビューデータブロックま
でのジャンプが時間Tjump2D(n)を要し、各ベースビューデータブロックが,リードバッフ
ァに速度Rud2Dで読み出され、かつ、リードバッファからビデオデコーダへ前記ベースビ
ューデータブロックが平均速度Rbext2Dで転送されるとき、EXT2Dの下限値は以下の条件１の式で表される。
＜条件１＞
EXT2Dの下限値 ≧（Rud2D×Rbext2D）/(Rud2D−Rbext2D)×Tjump2D（n）
ベースビューデータブロックB[n]ssに対応するエクステントをEXT1[n]であるものとす
る。この場合、EXT1[n]の下限値は、B−Dプレゼンテーションモードの再生時、各ベース
ビューデータブロックから次のディペンデントビューデータブロックまでのジャンプ期間
と、当該ディペンデントビューデータブロックから次のベースビューデータブロックまでのジャンプ期間とを通して、ダブルバッファのアンダーフローを生じさせないように決定される。
ここでのダブルバッファは、リードバッファ１、リードバッファ２から構成されるものとする。リードバッファ１は、2D再生装置のリードバッファと同一物である。
B−Dプレゼンテーションモードの再生において、n番目のベースビューデータブロック
からp番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n)を要し、ｐ番目のディペンデントビューデータブロックから（n+1）番目のベースビューデー
タブロックまでのジャンプが時間TBjump3D(n)を要するものとする。
そして各ベースビューデータブロックがリードバッファ１へ速度Rud3Dで読み出され、
各ディペンデントビューデータブロックがリードバッファ２へ速度Rud3Dで読み出され、
かつ、リードバッファ１からビデオデコーダへ前記ベースビューデータブロックが平均速度Rbext3Dで転送されるとき、EXT1[n]の下限値は、以下の条件２の式で表される。ビックエクステントの連続長は、この下限値、又は、この下限値を上回る値に設定される。
＜条件２＞
EXT1[n]の下限値 ≧（Rud3D×Rbext3D）/(Rud3D−Rbext3D)
×(TFjump3D（n）＋EXT2[n]/(Rud3D＋TBjump3D(n)))

EXT2の下限値は、B−Dプレゼンテーションモードの再生時、各ディペンデントビューエクステントから次のベースビューエクステントまでのジャンプ期間と、当該ベースビューエクステントから次のディペンデントビューエクステントまでのジャンプ期間とを通して再生装置におけるダブルバッファにアンダーフローを生じさせないように決定されている。
（n+1）番目のベースビューデータブロックから（p+1）番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n+1)を要し、かつ、リードバッファ２から
デコーダへ前記ディペンデントビューストリームファイルが平均速度Rdext3Dで転送され
るとき、EXT2[n]の下限値は以下の条件３の式で表される。
＜条件３＞
EXT2[n]の下限値 ≧（Rud3D×Rbext3D）/(Rud3D−Rdext3D)
×(TBjump3D（n）＋EXT1[n+1]/(Rud3D＋TFjump3D(n+1)))

＜EXTSSの具体的な値＞
あるエクステントの読み出しから、次のエクステントへのジャンプにあたって、そのジャンプの直前のバッファ占有量は、充分なものでなければならない。そうすると、立体視インターリーブドストリームファイルの読み出し時にあたってリードバッファは、1つの
エクステントによって充填される必要があり、バッファアンダーフローの発生を避けねばならない。
しかしEXTSSは、エクステントからエクステントへのジャンプ期間Tjumpだけではなく、Ｔdiffに基づき定める必要がある。ここでTdiffは、EXTssにおけるディペンデントビューデータブロックのプリロードと、EXTssnextにおけるディペンデントビューデータブロッ
クのプリロードとに伴う遅延時間を意味する。以下にTdiffの意味合いについて解説する
と、立体視インターリーブドストリームファイルの読み出しにあたって、先頭のディペンデントビューデータブロックをプリロードしている間は再生を開始することはできない。
EXTssでは、このディペンデントビューデータブロックのプリロードに要する期間だけ
再生が遅れるから、EXTssにおいて先頭のディペンデントビューのデータブロックのプリ
ロードに要する時間は、再生がその分遅れてしまうという“遅延期間”となる。
逆にEXTssnextにおいては、EXTssからEXTssnextへのジャンプの直後に、先頭のディペ
ンデントビューデータブロックのプリロードが行われるから、その間だけビデオデコーダの再生開始が遅れてもよいことになる。つまりEXTssnextの再生にあたって、先頭のディ
ペンデントビューデータブロックのプリロードが行われる期間は、ビデオデコーダ再生開始が猶予される“猶予期間”となる。
以上を踏まえるとTdiffは、ディペンデントビューデータブロックの猶予期間から遅延
期間を引いた値として導かれることになる。具体的には、以下の式を満たすように算出される。

Tdiff=ceil[((Ｓ1stEXT1[i]EXTSSnext]−Ｓ1stEXT1[i]EXTSS)x1000x8)/Rud72]
ここでＴdiffは、Ｓ1stEXT2[i]EXTssの読出期間と、Ｓ1stEXT2[i]EXTssnextの読出期間との差分を意味し、Ｓ1stEXT2[i]EXTssは、EXTssの最初に位置するEXT2[i]のサイズであ
り、Ｓ1stEXT2[i]EXTssNEXTは、EXTssNEXTの最初に位置するEXT2[i]のサイズである。EXTssnextは、立体視インターリーブドストリームファイルにおけるエクステントであって、EXTssの直後に位置し、EXTssとシームレスに再生されるものである。

このTdiffと、EXTssnextへのジャンプ時間(Ｔjump)とを用いれば、各エクステントにおける平均ビットレートに基づく最小エクステントサイズであるSextssは、以下の条件４を満たす値として算出される。
＜条件４＞
SextSS[Byte]≧ceil[(Tjump＋Tdiff×Rud72)/(1000×8))×(Rextss×192)/(Rud72×188−Rextss×192)]

ここで、Rud72は、立体視再生モードにおけるBD-ROMドライブからのデータレートであ
る。
Rextssは、EXTssの平均ビットレートであり、以下の式から導かれる。
Ｒextss＝ceil[Ｎsp×188×8/(ATCDextss/27000000)]
ATCDextss＝ATCstart＿extssnext −ATCstart＿extss
ATCDextss＝ATClast＿extss − ATCstart＿extss + ceil(27000000x188x8/min(Rts1,Rts2))
ATCDextssは、EXTssのATC期間である。
ATCstart＿EXTSSは、EXTssにおけるソースパケット列のATCフィールドによって指示される最小のATC値である。
ATCstart＿EXTssnextは、EXTssnextにおけるソースパケット列のATCフィールドによって指示される最小のATC値である。
ATClast＿EXTSSは、EXTssにおけるソースパケット列のATCフィールドによって指示され
る最大のATC値である。
Ｎspは、メインTS、サブTSにおけるソースパケットであって、ATCDexssの範囲内にあるATCに対応するATC値をもつものの個数である。
Ｒts1は、メインTSにおけるTSレコーディングレートの値であり、その最大値は、48Ｍbpsである。
Ｒts2は、サブTSにおけるTSレコーディングレートの値であり、その最大値は、48Ｍbpsである。
2つのプレイアイテムを連続的に再生存在する場合、EXTssは、Previousプレイアイテム(プレイアイテム１)によって使用されるATCシーケンスの最初のデータバイトを含む。
・EXTssは、条件４において定義された最小エクステントサイズ以上のサイズをもつ。
・EXTssがPreviousプレイアイテムにて使用されるATCシーケンスの最初のデータバイトである場合、Previousプレイアイテムのコネクションコンディション情報は、＝５(プレ
イアイテムの境界でクリーンブレークを伴う接続処理)、＝６(プレイアイテムの境界がGOPのバウンダリと一致する接続処理)に設定されない。この場合、EXTssのサイズを満たさ
なくてもよい。

EXTssは、カレントプレイアイテム（プレイアイテム２）によって使用されるATCシーケンスのデータバイトを含む。
・EXTssは、条件４において定義された最小エクステントサイズ以上のサイズをもつ。
・EXTssがプレイアイテム２にて使用されるATCシーケンスの最後のデータバイトである場合、プレイアイテム２のコネクションコンディション情報は、＝５、＝６に設定されない。この場合、EXTssのサイズを満たさなくてもよい。
図４２は、立体視インターリーブドストリームファイル、ファイル2D、ファイルベースの相互関係を示す。第１段目はファイル2Dを示し、第２段目は記録媒体上のデータブロック、第３段目は立体視インターリーブドストリームファイル、第４段目はファイルベース、第５段目はファイルディペンデントを示す。
第２段目におけるデータブロックは、上述したD[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ss,B[3]2D,B[4]2Dである。そして矢印ex1,ex2,ex3,ex4は、データブロックのうち、B[1],B[2],B[3]2D,B[4]2Dがファイル2Dのエクステントを構成しているという帰属関係を
示す。
矢印ex5,ex6は、データブロックのうち、D[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ssが立体視インターリーブドストリームファイルのエクステントを構成しているという帰属関係を示す。
第４段目は、この立体視インターリーブドストリームファイルを構成するデータブロックのうち、B[1],B[2],B[3]ss,B[4]ssがファイルベースのエクステントとなり、第５段目
は、立体視インターリーブドストリームファイルを構成するデータブロックのうち、D[1],D[2],D[3],D[4]がファイルディペンデントのエクステントになることを示す。
図４３は、2Dプレイリスト、3Dプレイリストを示す。第１段目は、2Dプレイリスト情報であり、第２段目は、ベーズデータブロック、第３段目は、3Dプレイリスト、第４段目は、ディペンデントビューデータブロックを示す。
矢印rf1,rf2,rf3は、2Dプレイリスト情報のプレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名00001と、拡張子m2tsとを組合せることに
よる再生経路を示す。この場合、データブロックB[1],B[2],B[3]2Dによってベースビュー側の再生経路が構成される。
矢印rf4,rf5,rf6,rf7は、3Dプレイリスト情報のプレイアイテム情報により指定される
再生経路を示す。この場合、B[1],B[2],B[3]ss,B[4]ssを用いてベースビュー側の再生経
路が構成される。
矢印rf8,rf9,rf10,rf11は、3Dプレイリスト情報のサブプレイアイテム情報により指定
される再生経路を示す。この場合、D[1],D[2],D[3],D[4]を用いてディペンデントビュー
側の再生経路が構成される。これらのプレイアイテム情報、サブプレイアイテム情報により指定される再生経路を構成するデータブロックは、プレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名と、拡張子ssifとを組合せてファ
イルオープンを行うことで読み出すことができる。
本図の3Dプレイリストにおけるクリップ情報ファイルネーム情報、2Dプレイリスにおけるクリップ情報ファイルネーム情報は、共通のファイル名を記述しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するよ
うなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つの
プレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。
立体視インターリーブドストリームファイルにメインTS、サブTSを格納する場合、２Ｄプレイリストのプレイアイテム情報におけるclip＿information＿file＿nameは、ファイル２Ｄのファイル名を記述する。３Ｄプレイリストのプレイアイテム情報におけるclip＿information＿file＿nameは、ファイルベースのファイル名を記述する。ファイルベースは、仮想的なファイルであり、そのファイル名は、立体視インターリーブドストリームファイルと同じものなので、立体視インターリーブドストリームファイルのファイル名をプレイアイテム情報におけるclip＿information＿file＿nameに記述しておけばよい。拡張ストリーム選択テーブルのストリーム登録情報におけるref＿to＿subclip＿entry＿idは、ファイルディペ
ンデントのファイル名を記述する。ファイルディペンデントのファイル名は、立体視インターリーブドストリームファイルの識別番号に、１を加算したものである。
図４４は、図４３の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す
。図４３のプレイリストは、サブパスID＝“１”のサブパスのみを具備していたのに対して、図４４のプレイリストにおける2つ目のサブパスは、サブパスID＝“２”によって識
別されるものであり、別のデータブロックを参照している。2以上のサブパス情報を設け
ることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、ライトビューを構成するデータブロックがその角度の数だけ用意されていて、角度ごとにサブパスを設けている。
ベースビューデータブロックから構成されるメインTSによって規定されるメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。
この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが
2D出力モードのときは2Dプレイリストとして機能することになる。図４３の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生
装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。
以降、ベースビュービデオストリームの指定の仕方について説明する。
一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すベースビューインディケータをプレイアイテム情報毎に設定できるようにしている。レフトビュービデオストリーム及びライトビュービデオストリームのうちどちらをベースビュービデオストリームとするか、レフトビューPGストリーム及びライトビューPGストリームのうちどちらをベースビューPGストリームとするか、レフトビューIGストリーム及びライトビューIGストリームのうちどちらをベースビューIGストリームとするかは、このプレイアイテム情報毎のベースビューインディケータによって指示される。
上述したように、ディペンデントビューデータブロックは、必ずベースビューデータブロックに先行して配置されるとの規則性をもつので、このベースビューインディケータを参照すれば、ライトビューを再生するためのソースパケット、レフトビューを再生するためのソースパケットのどちらが、先に再生装置に供給されるかを知得することができる。
この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。
図４５（ａ）は、図４３の3Dプレイリストに、ベースビューインディケータを書き加えた図である。
図４５（ｂ）は、オブジェクト指向プログラミング言語によるベースビューインディケータの記述を示す。本図は、PlayItemを定義する構造体において、ベースビューインディケータをどのように記述するかという記述例である。本図に示すように、“0”の即値を
指定することで、レフトビュービデオストリームをベースビュービデオストリームとして指定することができ、“1”の即値を指定することで、レフトビュービデオストリームを
ベースビュービデオストリームとして指定することができる。
表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別
するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。
また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。以上がベースビューインディケータについての説明である。このベースビューインディケータは、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。
図４６は、プレイアイテムの再生手順を示す。
ステップＳ４１は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップＳ４３〜ステップＳ４６を実行する。
ステップＳ４３において、カレントプレイアイテムのClip＿Information＿file＿name
に記述されている「XXXXX」と、拡張子「m2ts」とで指定されているストリームファイル
をオープンし、ステップＳ４４において、ビデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿Time
をStart＿SPN[i]及びEnd＿SPN[i]に変換する。
ステップＳ４５では、パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し、ステップＳ４６におい
て、読出範囲[i]に属するエクステントを連続的に読み出すよう、記録媒体のドライブに
指示する。
カレント出力モードが立体視出力モードであれば、ステップＳ５０〜ステップＳ６０のループに移行する。
ステップＳ５０において、カレントプレイアイテムのClip＿Information＿file＿name
に記述されている「XXXXX」と、拡張子「ssif」とで指定されているストリームファイル
をオープンし、ステップＳ５１において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のベースビューインディケータによって指定されているものをベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。
ステップＳ５２において、ベースビュービデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿Time
をStart＿SPN[i]及びEnd＿SPN[i]に変換する。
ステップＳ５３では、ディペンデントビューストリームに対応するSubPlayItemを特定
し、ディペンデントビューストリームのパケットID[j]に対応するエントリーポイント[j]を用いて特定されたSubPlayItemIn＿Time、SubPlayItemOut＿TimeをStart＿SPN[j]、End
＿SPN[j]に変換する(ステップＳ５４)。
パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップＳ５５)、パケットID[j]のTSパケット[j]をStart＿SPN[j]からEnd＿SPN[j]まで読み出すための読出範囲に属するエクステント
を特定する(ステップＳ５６)。そしてステップＳ５７において読出範囲[i],[j]に属する
エクステントをアドレスの昇順にソートして、ステップＳ５８においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライ
ブに指示する。その後、ソースパケット列が読み出されれば、ステップＳ５９においてベースビューのATCシーケンス、ディペンデントビューのATCシーケンスをそれぞれ復元して、ベースビュー用のPIDフィルタ、ディペンデントビュー用のPIDフィルタに送り込む。
以上のように本実施形態によれば、ベースビューデータブロックと、ディペンデントビューデータブロックとを1つの立体視インターリーブドストリームファイルに格納しつつ
も、これらをデコーダに供給する際、ベースビュー用のATCシーケンスと、ディペンデン
トビュー用のATCシーケンスとを復元するので、デコーダ側では、立体視インターリーブ
ドストリームファイルを通常のストリームファイルと同様に取り扱うことができる。よって、ベースビュービデオストリーム、ディペンデントビュービデオストリームの格納方式
に、積極的に立体視インターリーブドストリームファイルを取り入れることができる。
(第３実施形態)
本実施形態では、クリップ情報ファイルの詳細について説明する。
図４７は、クリップ情報ファイルの内部構成を示す。
同図（ａ）は、2Dのクリップ情報ファイル、同図（ｂ）は、3D用のクリップ情報ファイルを示す。これらのクリップ情報ファイルは、『クリップ情報』、『シーケンス情報』、『プログラム情報』、『特徴点情報』を含む。
『クリップ情報』は、ストリームファイルに格納されているソースパケット列のそれぞれが、どのようなAVクリップであるかをATCシーケンス毎に示す情報であり、対応するAV
クリップによって構成されるアプリケーションが、ムービー、スライドショー等、どのような類型に属するか(アプリケーションタイプ)、対応するAVクリップがどのようなストリームの類型に属するか(ストリームタイプ)、AVクリップにおけるTSパケットの転送レート(TSレコーディングレート)、前のAVクリップを構成するATCシーケンスとのATCの差分(ATCデルタ)、符号化に用いた符号化方式の識別子を含む。
『シーケンス情報』は、ストリームファイルに格納されている1又は複数のソースパケ
ット列がどのようなATCシーケンスであるかを示す情報(ATCシーケンス情報)をATCシーケ
ンス毎に示す構成になっている。ATCシーケンス情報は、ATCの開始点たるソースパケットがどこに存在するかをソースパケット番号で示す情報、STCシーケンス識別子ーATCシーケンス識別子間のオフセットと、複数のSTCシーケンスのそれぞれについてのSTCシーケンス情報とを含む。STCシーケンス情報は、そのSTCシーケンスにおけるPCRを格納しているソ
ースパケットのパケット番号、そのATCシーケンスのうち、どこにSTCシーケンスの開始点たるソースパケットが存在するかを示す情報、STCシーケンスにおける再生開始時刻、再
生終了時刻を含む。
『プログラム情報』は、クリップ情報ファイルによって“AVクリップ”であるとして管理されているメインTS、サブTSのプログラム構成を示す情報であり、AVクリップがどのようなESを多重化したものであるかを示す。具体的には、AVクリップに多重化されているESがどのようなパケット識別子を有しているか、どのような符号化方式であるかを示す。ビデオストリームが、MPEG2-video,MPEG4-AVC等のうち、どの符号化方式を用いて圧縮符号
化されているかは、このプログラム情報内に明示される。
『特徴点情報』は、AVクリップに多重化されている複数のESの特徴点がどこに存在するかを、ES毎に示す情報である。ES毎の特徴点を示す情報は、エントリーマップと呼ばれる。
何が特徴点になるかは、ストリームの種別毎に異なる。ベースビュービデオストリーム、ディペンデントビュービデオストリームの場合は、オープンGOP、クローズドGOPの先頭に位置するIピクチャのアクセスユニットデリッミターが特徴点となる。オーディオスト
リームの場合は、１秒置き等、一定期間置きに存在するオーディオフレームの先頭位置を示すアクセスユニットデリッミターが特徴点となり、PGストリーム、IGストリームの場合は、グラフィクスストリームのディスプレイセットのうち、表示に必要な全ての機能セグメントを具備したもの(エポックスタートのディスプレイセット、アクジッションポイン
トのディスプレイセット)の先頭位置を示すアクセスユニットデリッミターが特徴点とな
る。
また特徴点をどのように表すかは、ATCシーケンス、STCシーケンスのそれぞれで異なる
。ATCシーケンスにおいて特徴点は、ソースパケット番号で表現される。STCシーケンスにおいては、同じ特徴点が、STC時間軸における時点を示すPTSを用いて表現される。
上記違いに鑑みES毎のエントリーマップは、複数のエントリーポイントから構成されている。具体的にいうと、エントリーマップを構成する個々のエントリーポイントは、ATC
シーケンスにおける特徴点の所在を示すソースパケット番号が、STCシーケンスにおける
特徴点の所在を示すPTSと対応付けられており、その特徴点へのアングル切り替えが可能
であるか否かを示すフラグ(is＿angle＿changeフラグ)を具備している。マルチアングル
区間を構成するインターリーブユニットの先頭に位置するソースパケットは、アングル切り替えが可能になっているため、インターリーブユニットの先頭ソースパケットを差すエントリーポイントのis＿angle＿changeフラグは、必ずオンに設定される。また、インタ
ーリーブユニットの先頭ソースパケットを差すエントリーポイントは、エントリーポイントによって、プレイアイテム情報におけるIn＿Timeと対応付けられている。
ES毎のエントリーマップは、これらストリーム種別毎の特徴点のソースパケット番号を、PTSに対応付けて示しているので、このエントリーマップを参照することで、STCシーケンスにおける任意の時点から、その時点に最も近いES毎の特徴点の所在を示すソースパケット番号を導くことができる。
以上が2D用のクリップ情報ファイルについての説明である。続いて、3D用のクリップ情報ファイルの詳細について説明する。3D用のクリップ情報ファイルは、図４７（ｂ）の内部構成になっていて、通常のクリップ情報(管理情報)である「ファイル２Ｄ用のクリップ情報」の他に、ファイルディペンデント用のクリップ情報である「クリップディペンデント情報(ベースビュー管理情報)」、ファイルベース用のクリップ情報である「クリップベース情報(ベースビュー管理情報)」が存在する。これは以下の理由による。第２実施形態で述べたように、立体視インターリーブドストリームファイルと、通常のストリームファイルとの混同を避けるため、立体視インターリーブドストリームファイルは、ストリームファイルとは異なるディレクトリに格納される。そのため立体視インターリーブドストリームファイルには、クリップ情報ファイルを対応付けることができない。そこで、クリップディペンデント情報、及び、クリップベース情報は、ファイル２Ｄに対応するクリップ情報ファイルに格納されることになる。
2D用のクリップ情報と、クリップベース情報及びクリップディペンデント情報との違いは、クリップベース情報及びクリップディペンデント情報の内部に、エクステントスタートポイント列を含むメタデータが存在する点である。
図４７（ｂ）において、クリップディペンデント情報は、エクステントスタートポイント列を含み、クリップベース情報も、エクステントスタートポイント列を含む。クリップディペンデント情報内に存在するエクステントスタートポイント列は、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルディペンデントを構成する複数のエクステントの先頭のソースパケット番号を示す。
クリップベース情報内に存在するエクステントスタートポイント列も、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルベースを構成する複数のエクステントの先頭のソースパケット番号を示す。
これらのエクステントスタートポイント情報が存在することの技術的意義について述べる。
ストリームファイルに格納されているTSは、本来は、1つのTSであり、ATCシーケンスも1つのみである。よって、クリップ情報ファイルのシーケンス情報を参照しただけでは、
分割部分の先頭がどこであるかを判別することはできない。一方、分割部分の先頭はエクステントの先頭でもあるので、ファイルエントリやエクステント記述子といったファイルシステムの情報を参照すれば、分割部分の先頭がどこであるかを知ることができるが、ファイルシステムの情報はミドルウェアで管理されている情報であるため、アプリケーションからこのエクステントの情報を参照するのは困難を極める。そこで、本実施形態では、エクステントスタートポイント情報を用いて、エクステントが何パケット目であるかをクリップ情報内に示させるようにしている。
図１０３は、ベースビュークリップ情報におけるエクステントスタートポイント情報の一例と、ディペンデントビュークリップ情報におけるエクステントスタートポイント情報の一例を示す。（ａ）は、ベースビュークリップ情報のエクステントスタートポイント情報と、ディペンデントビュークリップ情報のエクステントスタートポイント情報とを示す。
（ｂ)は、ATCシーケンス1を構成するベースビューデータブロックB[0],B[1],B[2]・・
・・B[n]、ATCシーケンス2を構成するディペンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]を示す。（ｃ）は、ディペンデントビューデータブロックのソースパケット数、ベースビューデータブロックのソースパケット数を示す。
（ｄ）は、立体視インターリーブドストリームファイルに包含される複数のデータブロックを示す。
同図（ｂ）に示すように、ATCシーケンス2が、ディペンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]から構成されるとすると、ATCシーケンス２における、ディペ
ンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]の相対ソースパケット数である0,b1,b2,b3,b4・・・bnがファイルディペンデントのエクステントスタートポイント情
報のSPN＿extent＿startに記載される。
ATCシーケンス1が、ベースビューデータブロックB[0],B[1],B[2]・・・・B[n]によって構成されるとすると、ベースビューデータブロックの相対ソースパケット数である0,a1,a2,a3,a4・・・anが、ファイルベースのエクステントスタートポイント情報のSPN＿extent＿startに記載される。
同図（ｃ）は、立体視インターリーブドストリームファイルにおける任意のディペンデントビューデータブロックD[x]、任意のベースビューデータブロックb[x]のソースパケット数である。ディペンデントビューデータブロックD[x]の先頭ソースパケット番号がbxであり、ディペンデントビューデータブロックD[x+1]の先頭ソースパケット番号がbx+1である場合、D[x]を構成するソースパケット数は、ｂx+1−ｂxになる。
同じく、ベースビューデータブロックB[x]の先頭ソースパケット番号がａxであり、ベ
ースビューデータブロックB[x+1]の先頭ソースパケット番号がａx+1である場合、B[n]を
構成するソースパケット数は、ａx+1−ａxになる。
立体視インターリーブドストリームファイルにおける最後のベースビューデータブロックB[n]の先頭ソースパケット番号がanであり、ATCシーケンス１におけるソースパケット
の個数がnumber＿of＿source＿packet1である場合、B[n]を構成するソースパケット数は、number＿of＿source＿packet1-anになる。
立体視インターリーブドストリームファイルにおける最後のディペンデントビューデータブロックD[n]の先頭ソースパケット番号がbnであり、ATCシーケンス２におけるソース
パケットの個数がnumber＿of＿source＿packet2である場合、D[n]を構成するソースパケット
数は、number＿of＿source＿packet2-bnになる。
そうすると、ディペンデントビューデータブロックの先頭ソースパケット番号、ベースビューデータブロックの先頭ソースパケット番号は、（ｄ）に示す通りになる。
立体視インターリーブドストリームファイルにおいて、D[0]の先頭SPNは“0”、B[0]の先頭SPNは“b1”になる。
D[1]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケ
ット数a1との和になるから“b1+a1”になる。
B[1]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケ
ット数a1と、先行するD[1]のソースパケット数b2-b1との和になるから“b2+a1(=b1+a1+b2-b1)”になる。
D[2]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケ
ット数a1と、先行するD[1]のソースパケット数b2-b1と、B[1]のソースパケット数a2-a1との和になるから“b2+a2(=b1+a1+b2-b1+a2-a1)”になる。
B[2]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケ
ット数a1と、先行するD[1]のソースパケット数b2-b1と、B[1]のソースパケット数a2-a1と、D[2]のソースパケット数b3-b2との和になるから“b3+a2(=b1+a1+b2-b1+a2-a1+b3-b2)”になる。
図１０４は、ATCシーケンス１、２における任意のデータブロックのソースパケット番号
を説明するための図である。
同図（ａ）のATCシーケンス２において、bxのソースパケット番号に存在するD[x]の立体
視インターリーブドストリームファイルにおけるソースパケット番号を求める場合を考える。この場合、D[x]の先頭ソースパケット番号は、D[0],B[0],D[1],B[1],D[2],B[2]・・
・・D[x-1],B[x-1]の相対ソースパケット数のソースパケット数の総和になるから、同図
（ｂ）に示すように“bx+ax”になる。
同図（ａ）のATCシーケンス１において、axのソースパケット番号に存在するB[x]の立
体視インターリーブドストリームファイルにおけるソースパケット番号を求める場合を考える。この場合、同図（ｂ）に示すように、B[x]の先頭ソースパケット番号は、D[0],B[0],D[1],B[1],D[2],B[2]・・・・D[x-1],B[x-1],D[x]の相対ソースパケット数のソースパ
ケット数の総和になるから、“ｂx+1＋ａx”になる。
同図（ｃ）は、上記ベースビューデータブロックをエクステントとするファイルベースと、上記ディペンデントビューデータブロックをエクステントとするファイルディペンデントとを示す。
B[x]にあたるファイルベースのエクステントであるEXT1[x]の先頭LBN及び連続長、及び、D[x]にあたるファイルディペンデントのエクステントであるEXT2[x]の先頭LBN及び連続長は以下のように求められる。
D[x]の先頭ソースパケット番号からLBNを求めるには、（(ｂx+ａx)*192/2048)という計算でソースパケットをLBNに変換する。同じく、Ｂ[x]の先頭ソースパケット番号からLBN
を求めるには、（(ｂx+1＋ａx)*192/2048)という計算でソースパケットをLBNに変換する
。ここで“192”は、ソースパケットサイズをバイト数で表したものであり、“2048”は
、セクタサイズ(論理ブロックサイズ)をバイト数で表したものである。これらのLBNに最
も近い、立体視インターリーブドストリームファイルのエクステントのLBNは、上記変換
によって得られたLBNを、関数SSIF＿LBN(file＿offset) の引数であるfile＿offsetに用いる
ことで算出される。関数SSIF＿LBNは、file＿offsetから、SSIFのアロケーション既述子を
たどって、file＿offsetに該当するLBNを返す関数である。
こうすることで、EXT2[x]の先頭LBNは、SSIF＿LBN((ｂx＋ａx)*192/2048)になり、EXT1[x]の先頭LBNは、SSIF＿LBN((ｂx+1＋ａx)*192/2048)になる。
一方、EXT2[x]の連続長は、(SSIF＿LBN((ｂx+1＋ａx)*192/2048)−SSIF＿LBN((ｂx＋ａx)*192/2048))になる。EXT1[x]の連続長は、(SSIF＿LBN((ｂx+1＋ａx+1)*192/2048)−SSIF＿LBN((ｂx+1＋ａx)*192/2048))になる。これらの先頭LBN及び連続長を示すファイルエント
リーをメモリ上で生成すれば、ファイルベース、ファイルディペンデントを仮想的に得ることができる。
図４８は、エクステントスタートポイント情報のシンタックスを示す。number＿of＿extent＿unitsは、ATS区間が同一のExtent Blockの数を示す。
extent＿idを制御変数としたfor文は、base/dependent＿view＿extent＿start＿address、interleaved＿base/dependent＿view＿extent＿start＿address [extent＿id]を、number＿of＿extents＿unitだけ定義するものである。
base/dependent＿view＿extent＿start＿address [extent＿id] は、LR別ファイル形式の各Extentのスタートアドレスを示す。interleaved＿base/dependent＿view＿extent＿start＿address [extent＿id] は、LR 1ファイル形式の各Extentのスタートアドレスを示す。これらのうち、base＿biew＿extent＿start＿address [extent＿id]は、ファイル先頭からの相対アドレスを示す。この相対アドレスは192byte(SPN)単位であり、32bitで768GBまで対応可能である。これは、EP＿mapを使った再生開始アドレス探索のため、SPN単位の方が判定が容易に
なるからである。Extentは6KBアラインしているため、6KB単位でもよい。6KB=192byte*32のため、5bitシフトで対応可能になる。そして、エクステントスタートポイント情報の構成要素であって、ソースパケット番号によってエクステントの先頭アドレスを表現するものを“SPN＿extent＿start”という。
図４９は、クリップ情報ファイルにおけるエントリーマップテーブルを示す。 本図（ａ）は、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップ
テーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、『エントリマップヘッダ情報』、『エクステント開始タイプ』、『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』を含む。
『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエ
ントリポイント数などの情報が格納される。
『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。
『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』は、複数種別のソースパケットによって構成されるPESストリームのそれぞ
れについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報を"エントリポイント"と呼ぶ。また先頭を"０"として各エントリポイント毎にインクリメントした値をエントリポイントID（以下EP＿ID）と呼ぶ。このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するソースパケット位置を特定することが出来るようになる。例えば、早送り・巻戻しの特殊再生
の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。また、エントリマップ
はAVクリップ内に多重化される各ビデオストリーム毎に作られ、PIDで管理される。
引き出し線eh2は、PID＝1011のエントリーマップの内部構成をクローズアップして示している。EP＿ID=0に対応するエントリーポイント、EP＿ID=1に対応するエントリーポイント、EP＿ID=2に対応するエントリーポイント、EP＿ID=3に対応するエントリーポイントから構成される。EP＿ID=0に対応するエントリーポイントは、オンに設定されたis＿angle
＿changeフラグと、SPN=3と、PTS=80000との対応付けを示す。EP＿ID=1に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=1500と、PTS=270000との対応付けを示す。
EP＿ID=2に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラ
グと、SPN=3200と、PTS=360000との対応付けを示す。EP＿ID=3に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=4800と、PTS=450000との対
応付けを示す。is＿angle＿changeフラグは、そのエントリーポイントから独立して復号
することができるか否かを示すフラグである。ビデオストリームがMVC又はMPEG4-AVCで符号化されており、エントリーポイントにIDRピクチャが存在する場合、このフラグはオン
に設定される。エントリーポイントにNon-IDRピクチャが存在する場合、このフラグはオ
フに設定される。
同図（ｂ）は、（ａ）に示したPID=1011のTSパケットに対応するエントリーマップ内の複数のエントリーマップによって、どのソースパケットを指示されるかを示す。EP＿ID=0に対応するエントリーマップは、SPN=3を指し示しており、このソースパケット番号をPTS=80000と対応付けている。EP＿ID=1に対応するエントリーマップは、SPN=1500を指し示しており、このソースパケット番号をPTS=270000に対応付けている。
EP＿ID=2に対応するエントリーマップは、SPN=3200のソースパケットを指し示しており、このソースパケット番号をPTS=360000に対応付けている。EP＿ID=3に対応するエントリーマップは、SPN=4800のソースパケットを指し示しおり、このソースパケット番号をPTS=450000と対応付けている。
図５０は、プログラム情報におけるストリーム属性情報を示す。
図中の引き出し線ah1は、ストリーム属性の内部構成をクローズアップして示している
。
この引出線に示すように、PID＝0x1011のTSパケットによって構成されるレフトビュー
ビデオストリームのストリーム属性、PID＝0x1012のTSパケットによって構成されるライ
トビュービデオストリームのストリーム属性、PID＝0x1100、PID＝0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性、PID=0x1220,0x1221のTSパケ
ットによって構成されるPGストリームのストリーム属性というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのスト
リーム属性に示されている。この引出線ah1に示すように、AVクリップに含まれる各スト
リームについての属性情報が、PID毎に登録される。
図５１は、エントリーマップによるエントリーポイントの登録を示す。第１段目は、SCシーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、クリップディペンデント情報におけるエクステントスタートポイント情報、及び、クリップベース情報におけるエクステントスタートポイント情報を示す。第４段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマッ
プが、ATCシーケンスのうち＝n1のソースパケットを指定している場合、このエントリー
マップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける＝n1からのランダムアクセスを再生装置に実
行させることができる。またエントリーマップが、ATCシーケンスのうち＝n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおけ
る＝n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生装置はビデオストリームの時間軸上の任意の地点に対応するソースパケットを特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生する
ことによりAVクリップを解析することなく効率的に処理を行うことが出来る。
また第３段目における、クリップディペンデント情報におけるエクステントスタートポイント[i]、クリップベース情報におけるエクステントスタートポイント[j]は、第４段目において、ディペンデントビュービデオストリームを構成するエクステント、ベースビュービデオストリームを構成するエクステントの先頭ソースパケット番号がどれであるかを示す。
これにより、クリップディペンデント情報におけるエクステントスタートポイント[i]
で示されるソースパケットから、クリップベース情報のエクステント[j]によって示され
るソースパケットの直前のソースパケットまでを読み出せば、ディペンデントビュービデオストリームを構成するソースパケット列のみを抽出することができる。
クリップベース情報におけるエクステントスタートポイント[j]で示されるソースパケ
ットから、クリップディペンデント情報におけるエクステント[i+1]によって示されるソ
ースパケットの直前のソースパケットまでを読み出せば、ベースビュービデオストリームを構成するソースパケット列のみを抽出することができる。
そして、ベースビュービデオストリームを構成するソースパケット同士、ディペンデントビュービデオストリームを構成するソースパケット同士を統合すれば、ベースビュービデオストリーを構成するATCシーケンス、ディペンデントビュービデオストリームを構成
するATCシーケンスを復元することができる。
図５２は、立体視インターリーブドストリームファイル構成するデータブロックからATCシーケンスがどのように復元されるかを示す。
第４段目は、立体視インターリーブドストリームファイルを構成する複数のデータブロックを示し、第３段目は、メインTS、サブTSに多重化されるソースパケット列を示す。
第２段目は、ディペンデントビューを構成するSTCシーケンス２、エントリーマップ、
ディペンデントビューを構成するATCシーケンス２の組みを示し、第１段目は、ベースビ
ューを構成するSTCシーケンス１、エントリーマップ、ベースビューを構成するATCシーケンス１の組みを示す。第３段目から第２段目、第１段目への矢印は、立体視インターリーブドストリームファイルにインターリーブ化されている2つのTS(メインTS、サブTS)のデ
ータブロックからATCシーケンス１、ATCシーケンス２が復元されることを模式的に示す。これらのATCシーケンスは、クリップ情報におけるエントリーマップによって、STCシーケンスとの対応がとられる。
以上が本実施形態に係る記録媒体についての説明である。続いて、再生装置の詳細について説明する。
本実施形態における再生装置の読出部は、2つの記録媒体からのソースパケット入力を
受け付ける構成になっており、2つの記録媒体のそれぞれをアクセスするための2つのドライブ、これら2つのドライブから入力されたソースパケットを一旦格納してデコーダに出
力するための2つのリードバッファを含む。そして、2つのドライブと、2つのリードバッ
ファとの間に、ATCシーケンス復元部が存在する。このATCシーケンス復元部は、1つの記
録媒体から読み出されたインターリーブドストリームファイル内のソースパケットから、ベースビューを構成するATCシーケンスと、ディペンデントビューストリームを構成するATCシーケンスとを分離し、2つのリードバッファのそれぞれに書き込むものである。こう
することで再生装置は、ベースビュービデオストリームを構成するATCシーケンス、ディ
ペンデントビューストリームを構成するATCシーケンスがそれぞれ別々の記録媒体から読
み出されたかのように処理することができる。図５３（ａ）は、ATCシーケンス復元部を
具備した読出部の内部構成を示す。上述したように、2つのドライブと、2つのリードバッファとの間にATCシーケンス復元部が介在している。図中の矢印B0は、1つのドライブからのソースパケット入力を象徴的に示したものであり、矢印B1は、ベースビュービデオストリームを構成するATCシーケンス１の書き込み、矢印D1は、ディペンデントビューストリ
ームを構成するATCシーケンス２の書き込みを模式的に示す。
図５３（ｂ）は、ATCシーケンス復元部によって得られた2つのATCシーケンスが、どの
ように取り扱われるかを示す。図中の真ん中に多重分離部内に存在するPIDフィルタを示
す。左側は、ATCシーケンス復元部によって得られた2つのATCシーケンスを示す。右側は
、これらの2つのATCシーケンスを多重分離することで得られるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリームを示す。これらの2つのPIDフィルタによる多重分離は、第１実施形態に示した基本ストリーム選択テーブル、拡張ストリーム選択テーブルによる。このATCシーケンス復元部は
、図５４の処理をハードウェア資源に実行させるプログラムを作成することで実現される。図５４は、ATCシーケンス復元手順を示す。
ステップＳ９１は、ベースビュー用のATCシーケンスをATCシーケンス１とし、ディペンデントビュー用のATCシーケンスをATCシーケンス２とする。ステップＳ９２では、変数x
を1に初期化する。この変数xは、ディペンデントビューデータブロック、ベースビューデータブロックを指示する。以降、ステップＳ９４〜ステップＳ９６のループを繰り返す。
変数xによって指示されるソースパケット番号bxが、ベースビューデータブロックの最
後の数値nによって指示されるソースパケット番号bnであるか否かを判定し(ステップＳ９３)、もしそうでなければ、ソースパケット番号ｂx＋ａxによって指示されるソースパケ
ット(ｂx＋ａx)から、ｂx+1＋ａxによって指示されるソースパケット(ｂx+1＋ａx)の直前のパケットまでをATCシーケンス２に追加し(ステップＳ９４)、ソースパケット(ｂx+1＋
ａx)からソースパケット(ｂx+1＋ａx+1)の直前のパケットまでをATCシーケンス１に追加
して(ステップＳ９５)、変数xをインクリメントする(ステップＳ９６)という処理を、ス
テップＳ９３がYesと判定されるまで繰り返す。
ステップＳ９３がYesと判定されれば、ソースパケット番号ｂnから(number＿of＿source＿packet2-ｂn)個のソースパケットをATCシーケンス２に追加し(ステップＳ９７)、ソース
パケット番号ａnから(number＿of＿source＿packet1-ａn)個のソースパケットをATCシーケンス１に追加する(ステップＳ９８)。
以上のように、ATCシーケンス１、２が復元されれば、ベースビューデータブロックの
先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイ
ルベースを仮想的にオープンする(ステップＳ９９)。同様に、ディペンデントビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成
して、ファイルディペンデントを仮想的にオープンする(ステップＳ１００)。
＜ファイルベースをオープンすることの技術的意義＞
ここで任意の時点からのランダムアクセスを行う際、ストリームファイル内のセクタサーチを行う必要がある。セクタサーチとは、任意の時点からのランダムアクセスを行う際、その時点に対応するソースパケットのソースパケット番号を特定して、そのソースパケット番号のソースパケットを含むセクタから、ファイルリードを行うという処理である。
立体視インターリーブドストリームファイルは、一個のエクステントが大きいため、セクタサーチの探索範囲が広く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定に、かなりの処理時間を要することがある。
これは、インターリーブストリームファイルは、ベースビュービデオストリームを構成するデータブロック、ディペンデントビューストリームを構成するデータブロックがインターリーブ配置されて一本の長いエクステントを構成しており、インターリーブストリームファイルのファイルエントリーのアロケーション記述子は、その長いエクステントの先頭アドレスを示しているに過ぎないとの理由による。
これに対してファイルベースは、長さが短い複数のエクステントから構成されており、個々のエクステントの先頭アドレスがアロケーション記述子に示されているため、セクタサーチにあたっての探索範囲が狭く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定が、短時間で完了する。
つまり、ベースビュービデオストリームを構成するデータブロックが、ファイルベースのエクステントとして管理されており、データブロックの先頭アドレスが、ファイルベースに対応するファイルエントリーにおけるアロケーション記述子に明記されているので、ランダムアクセス位置を包含しているエクステントの先頭アドレスから、セクタサーチを開始すれば、早期にランダムアクセス位置となるソースパケットを含むセクタにまで到達することができる。
このようにベースビュービデオストリームを構成するデータブロックを、ファイルベースのエクステントとして管理し、各エクステントの先頭アドレス及び連続長を、ファイルベースについてのファイルエントリーのアロケーション記述子に示しておくことにより、ベースビュービデオストリームにおける任意の時点からのランダムアクセスが高速になる。
具体的なセクタサーチの手順は以下のものになる。ベースビュービデオストリームに対応するエントリーマップを用いることにより、任意の時点に対応するランダムアクセス位置であるソースパケット番号を導き出す。
次に、ベースビュービデオストリームに対応するクリップ情報内のエクステントスタートポインティング情報を用いることにより、ランダムアクセス位置となるソースパケット番号を包含しているエクステントがどれであるかを特定する。
更に、ファイルベースに対応するファイルエントリーのアロケーション記述子を参照すれば、ランダムアクセス位置となるソースパケット番号を包含しているエクステントの先頭セクタアドレスを特定することができる。その先頭セクタアドレスにファイルポインタを設定して、ファイルリードを行い、読み出されたソースパケットに対するパケット解析を実行することで、ランダムアクセス位置となるソースパケット番号のソースパケットを特定する。そして特定されたソースパケット番号のソースパケットを読み出す。これによ
り、メインTSに対するランダムアクセスが効率的に実行されることになる。サブTSも同様である。
以上のように本実施形態によれば、エクステントスタートポイント情報に基づき、インターリーブドストリームファイルにおけるベースビュービデオストリームのエクステント、ディペンデントビュービデオストリームのエクステントをエクステントスタートポイント情報に基づき整列した上で多重分離部、デコーダに供するので、デコーダやプログラムは、ベースビュービデオストリームを格納したファイルベースディペンデントビュービデオストリームを格納したファイルディペンデントという2つのファイルが記録媒体に仮想
的に存在するものとして扱うことができる。
立体視のためのベースビュービデオストリーム、ディペンデントビュービデオストリームをインターリーブストリームファイルとして記録媒体しつつも、ベースビュービデオストリーム及びディペンデントビュービデオストリームの単体アクセスを可能にせしめるので、再生装置の処理の効率性を向上させることができる。
尚、エクステントスタートポイント情報は、１バイト単位で、エクステントの先頭を示しても良いが、エクステントがECCブロックのような固定長の読み取りブロックサイズに
アラインする場合は、固定長単位で指定することが望ましい。こうすることでアドレスを識別するために必要な情報量を抑えることも可能である。

(第４実施形態)
本実施形態では、多重分離部、デコーダ、プレーンメモリのハードウェアスケールについて説明する。
本実施形態における多重分離部は、ソースパケットデパケッタイザー、PIDフイルタと
の組みを1つ以上含む。このソースパケットデパケッタイザー、PIDフイルタの組みは、ストリーム入力の系統数に応じた数だけ存在する。
図５５は、多重分離部及びビデオデコーダの内部構成を示す。
同図（ａ）は、多重分離部のデコーダモデルを示す。多重分離部 (Source De-packetizer and PID filter)の組みは2つになる。これは、多重分離部が本来、2つの記録媒体からの2系統のストリーム入力を処理する構成になっているからである。2D再生モードでは、2つの記録媒体からのストリーム入力を処理することができるが、3D再生モードでは、LとR、2DとDepthという2系統のストリーム入力を処理することになる。
同図（ａ）に示すように、多重分離部は、ソースデパケッタイザ２２、PIDフィルタ２
３、ソースデパケッタイザ２７、PIDフィルタ２８から構成される。
ソースデパケッタイザ２２は、リードバッファ２aにソースパケットが蓄えられた場合
、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ２３は、ソースデパケッタイザ２２から出力されたTSパケットのうち、TS
パケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デ
コーダに出力する。
ソースデパケッタイザ２６は、リードバッファ２bにソースパケットが蓄えられた場合
、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、A
Vクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整す
る。
PIDフィルタ２７は、ソースデパケッタイザ２６から出力されたTSパケットのうち、TS
パケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デ
コーダに出力する。
次にプライマリビデオデコーダ３１の内部構成について説明する。
図５５（ｂ）は、プライマリビデオデコーダの内部構成を示す。プライマリビデオデコーダ３１は、TB５１、MB５２、EB５３、TB５４、MB５５、EB５６、デコーダコア５７、バッファスイッチ５８、DPB５９、ピクチャスイッチ６０から構成される。
Transport Buffer(TB)５１は、レフトビュービデオストリームを含むTSパケットがPID
フィルタ２３から出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)５２は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される
際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)５３は、符号化状態にあるビデオアクセスユニットが格納され
るバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
Transport Buffer(TB)５４は、ライトビュービデオストリームを含むTSパケットがPID
フィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)５５は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される
際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)５６は、符号化状態にあるビデオアクセスユニットが格納され
るバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
デコーダコア５７は、ビデオストリームの個々のビデオアクセスユニットを所定の復号時刻（DTS）でデコードすることによりフレーム/フィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG２、MPEG４AVC、VC１などが
あるため、ストリームの属性に応じて、ビデオデコーダ５７のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ５７は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ５７は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ５７は、デコードされたフレーム/フィールド画像をDPB５９に転送し、表示時刻（PTS）のタイミングで対応
するフレーム/フィールド画像をピクチャスイッチに転送する。
バッファスイッチ５８は、ビデオデコーダ５７がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB５３、EB５６のどちらから引き抜くかを決定し、EB５３と、EB５６とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻（DTS）のタイミングでビデオデコーダ５７に
転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間
軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒
しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ５７に
転送するのが望ましい。
Decoded PIcture Buffer(DPB)５９は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ５７が、ピクチャ間予測符号化されたPピ
クチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードさ
れたピクチャを参照するために利用する。
ピクチャスイッチ６０は、ビデオデコーダ５７から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオ
プレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。
モード切り替え時におけるビデオスデコーダの動作について述べる。LR方式の場合はL
側の出力だけに切り替えれ2D表示になり、Depth方式の場合は、深度情報の処理をやめ、
深度情報を付加しなけれ2D映像に切り替えることができる。ただし、LR方式とDepth方式
は必要とするデータが異なるため、相互の切り替えを行う際には、デコードするストリームの再選択が必要となる。
次に、再生装置におけるデコーダ及びプレーンメモリの規模について説明する。
装置構成が、１デコーダになるか、２デコーダになるか、１プレーンになるか、２プレーンになるかは、ストリーム種別と、立体視方式との組合せによって変わる。
3D-LR方式を採用する場合、MVCビデオストリームが再生対象であれば、１デコーダ＋２プレーン構成になる。
3D-Depth方式を採用する場合も、１デコーダ＋２プレーン構成になり、視差画像生成器が必要になる。これはプライマリビデオストリーム、セカンダリビデオストリームでも同様である。
MVCビデオストリームにおいて装置構成が1デコーダになるのは、個々の圧縮ピクチャデータのマクロブロックの動き補償を実現するにあたって、非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータを参照画像として利用するからである。デコーデッドピクチャバッファに、参照画像となる非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータが格納される。
以上がビデオデコーダ、ビデオプレーンについての説明である。
PGストリームにおける再生装置の構成は、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。3D-LR方式、3D-Depth方式を採用する場合、２デコーダ＋
２プレーン構成になる。
同じく、IGストリームにおける再生装置構成は、3D-LR方式を採用する場合、２デコー
ダ＋２プレーン構成になる。一方、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。
テキスト字幕ストリームにおける再生装置構成では3D-LR方式が存在せず、1plane＋Offsetモードである場合、１デコーダ＋１プレーン構成になる。3D-Depth方式である場合、
１デコーダ＋２プレーン構成になる。
次に、PGストリームの内部構成と、PGストリームをデコードするPGデコーダの内部構成
とについて説明する。
レフトビューPGストリーム、ライトビューPGストリームは、何れも複数のディスプレイセットを含む。ディスプレイセットとは、一個の画面表示を構成する機能セグメントの集まりのことである。機能セグメントは、約2KバイトのPESパケットのペイロードに格納さ
れてデコーダに供給され、DTS、PTSを用いて、再生制御がなされる処理単位のことである。
ディスプレイセットには、以下の類型がある。
Ａ.エポックスタートのディスプレイセット
エポックスタートのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンをリセットして、メモリ管理を開始させる機能セグメントの集まりであり、画面構成に必要な機能セグメントを全て含んでいる。
Ｂ.ノーマルケースのディスプレイセット
ノーマルケースのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理を継続したまま画面構成を行うディスプレイセットであり、先行するディスプレイセットからの差分となる機能セグメントを含んでいる。
Ｃ.アクジッションポイントのディスプレイセット
アクジッションポイントのディスプレイセットとは、画面構成に必要な機能セグメントを全て含むディスプレイセットであるが、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理をリセットさせないディスプレイセットである。このアクジッションポイントのディスプレイセットには、前のディスプレイセットとは異なる内容の機能セグメントが存在してもよい。
Ｄ.エポックコンティニューのディスプレイセット
エポックコンティニューのディスプレイセットとは、PGストリームの再生を許可しているプレイアイテムと、その直前のプレイアイテムとの接続形態が、クリーンブレークを伴うシームレス接続(CC=5)である場合、再生装置におけるコンポジションバッファ、コードデータバッファ、オブジェクトバッファ、グラフィクスプレーンにおけるメモリ管理を、そのまま継続させる旨を示す。この際、オブジェクトバッファ、グラフィクスプレーン上に得られたグラフィクスオブジェクトは、廃棄されることなく、オブジェクトバッファ、グラフィクスプレーン上で存続する。
レフトビューと、ライトビューとでは、STCシーケンスにおける再生時間軸の同一時点
に、これらのディスプレイセットの始点・終点が割り当てられている。そして、レフトビューPGストリームと、ライトビューPGストリームとでは、時間軸上の同じ時点に存在するディスプレイセットの類型は、同一になっている。つまりレフトビュー側のディスプレイセットがエポックスタートのディスプレイセットであるなら、STCシーケンスの時間軸に
おいて同じ時点のライトビュー側のディスプレイセットは、エポックスタートのディスプレイセットになる。
また、レフトビュー側のディスプレイセットがアクジッションポイントのディスプレイセットであるなら、STCシーケンスの時間軸において同じ時点のライトビュー側のアクジ
ッションポイントのディスプレイセットも、エポックスタートのディスプレイセットになる。
各ディスプレイセットは、複数の機能セグメントを含む。この複数の機能セグメントに
は以下のものがある。
(1)オブジェクト定義セグメント
オブジェクト定義セグメントは、グラフィクスオブジェクトを定義する機能セグメントである。グラフィクス定義セグメントは、コード値と、そのコード値のランレングスとを用いることで、グラフィクスオブジェクトを定義している。
(2)パレット定義セグメント
パレット定義セグメントは、各コード値と、輝度、赤色差・青色差との対応関係を示したパレットデータを含む。レフトビューグラフィクスストリームのパレット定義セグメントと、ライトビューグラフィクスストリームのパレット定義セグメントとでは、コード値と、輝度及び色差との対応関係が同一の内容に設定されている。
(3)ウィンドゥ定義セグメント
ウィンドゥ定義セグメントは、非圧縮のグラフィクスオブジェクトを画面上に展開するためのプレーンメモリにおいて、ウィンドゥと呼ばれる矩形枠を定義する機能セグメントである。グラフィクスオブジェクトの描画は、このプレーンメモリの内部で制限されており、このウィンドゥの外部では、グラフィクスオブジェクトの描画は行えない。
プレーンメモリの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
(4)画面構成セグメント
画面構成セグメントは、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントであり、グラフィクスデコーダにおけるコンポジションコントローラに対する複数の制御項目を含む。画面構成セグメントは、グラフィクスストリームにおけるディスプレイセットの詳細を規定すると共に、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントである。かかる画面構成には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、画面構成セグメントによる画面構成を
伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
(5)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグ
メントである。再生装置は、画面構成セグメントからこのエンドセグメントまでが、1つ
のディスプレイセットを構成する機能セグメントであるとして解釈する。
PGストリームにおいてディスプレイセットの開始時点は、画面構成セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、画面構成セグメントを格納したPESパケットのPTSによって特定される。
レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームは、パケッタイズドエレメンタリストリーム(PES)であり、画面構成セグメントは、PESパケットに格納され、画面構成セグメントを格納したPESパケットのPTSは、画面構成セグメントが属するディスプレイセットによる表示を何時実行するかを示す。
画面構成セグメントを格納したPESパケットのPTSの値は、レフトビュービデオストリームと、ライトビュービデオストリームとで同一の内容になっている。
・PGデコーダのデコーダモデル
PGデコーダは、PGストリームから読み出されう機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するためのトランスポートバッファが存在する。
グラフィクスデコーダの後段には、グラフィクスプレーンと、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換するCLUT部と、プレーンシフトのためのシフト部とが存在する。
PGストリームにおけるパイプラインは、グラフィクスデコーダあるディスプレイセットに属するオブジェクト定義セグメントをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行するディスプレイセットに属するオブジェクト定義セグメントをデコードすることにより得られたグラフィクスオブジェクトをオブジェクトバッファからプレーンメモリに書き込む処理とを同時に実行することでなされる。
図５６は、PGストリームのグラフィクスデコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモード方式で表示するためのデコーダモデルである。同図（ｂ）は、LR方式のデータを表示する場合のデコーダモデルである。
本図において、グラフィクスデコーダの本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲っている。
同図（ａ）では、グラフィクスデコーダは１デコーダ構成になっており、グラフィクスプレーンも1プレーン構成になっている。しかしグラフィクスプレーンの出力が、レフト
ビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
同図（ｂ）では、トランスポートバッファ−グラフィクスデコーダ−グラフィクスプレーン−CLUT部が2組み存在していて、レフトビューストリーム、ライトビューストリーム
をそれぞれ独立に処理することができる。
オフセットシーケンスはディペンデントビュービデオストリームに含まれているので、プレーンオフセット形式では、グラフィクスデコーダは１デコーダ構成になり、この1つ
のグラフィクスデコーダの出力が、レフトビューとライトビューとに切り替えられる。
PGデコーダの2D/3D切り替え時の動作は以下の通りである。
１.1plane＋Offsetモードと2Dモードとの相互切り替え時は、シームレスに切り替えら
れる。これは、Offsetを無効化することでなされる。
２.3D-LRモードと、2Dモードとでは、PID切り替えが伴うため、一端字幕が消える。こ
れはストリーム切り替えと同じである。
３.3D-LRモードとLモードとでは、L（BaseView側）のみの表示に切り替える。シームレスに切り替え可能だが、表示位置が偏る可能性がある。
3D-Depthモードと、2Dモードとでは、2D表示中もバックグラウンドで、グレースケールに示される深度情報をデコードして、レフトビューのグラフィクスオブジェクト、ライトビューのグラフィクスオブジェクトを生成しておけば、グラフィクスオブジェクトの切り替えをシームレスに行うことができる。
PGデコーダでモード切り替えを実行する場合、Depthモード、1plane＋Offsetモードか
ら2Dモードへの切り替えが容易である。しかし3D-LR方式の場合、立体視のグラフィクス
オブジェクトと、2Dのグラフィクスオブジェクトとは異なるため、切り替え時に処理するPGストリームの変更が必要となり、次のPGストリームが供給されるまでグラフィクスオブジェクトが表示されない可能性が生じる。
グラフィクスオブジェクトが表示されない期間を設けたくない場合には、正面から見る2Dグラフィクスオブジェクトではなく、ベースビューのグラフィクスオブジェクトのみに切り替えることも可能である。この場合すこし左に偏った映像に見える可能性が残る。立体視PGを2DPGに切り替える場合、どちらの方法を用いるか、管理データに設定しておくことも可能である。

・テキスト字幕デコーダのデコーダモデル
テキスト字幕ストリームは、複数の字幕記述データから構成される。
テキスト字幕デコーダは、字幕記述データから、テキストコードと、制御情報とを分離する「字幕プロセッサ」と、字幕記述データから分離されたテキストコードを格納する「管理情報バッファ」と、フォントデータを用いて、管理情報バッファ内のテキストコードをビットマップに展開する「テキストレンダー」と、展開により得られたビットマップを格納する「オブジェクトバッファ」と、字幕記述データから分離された制御情報を用いて、時間軸に沿ったテキスト字幕再生の制御を実行する「描画制御部」とを含む。
テキスト字幕デコーダの前段には、フォントデータのプリロードを行う「フォントプリロードバッファ」、テキスト字幕ストリームを構成するTSパケットの入力速度を調整する「TSバッファ」、プレイアイテムの再生に先立ち、テキスト字幕ストリームをプリロードしておくための「字幕プリロードバッファ」が存在する。
グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのためのシフト部が存在する。
図５７は、テキスト字幕デコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモードにおけるテキスト字幕デコーダのデコーダモデルを示し、同図（ｂ）は、3D-LR方式
におけるテキスト字幕デコーダのデコーダモデルを示す。本図において、テキスト字幕デコーダ本体にあたる部分は黒枠で囲こみ、テキスト字幕デコーダ後段にあたる部分は一点鎖線で囲んでいる。テキスト字幕デコーダ前段にあたる部分は、破線枠で囲んでいる。
同図（ａ）では、グラフィクスプレーンの出力が、レフトビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
同図（ｂ）では、レフトビュー用のグラフィクスプレーンと、ライトビュー用のグラフ
ィクスプレーンとが存在していて、テキスト字幕デコーダによって展開されたビットマップを、これらのそれぞれのグラフィクスプレーンに書き込む。3D-LR方式のテキスト字幕
デコーダでは、カラーパレット情報が拡張されており、字幕用の文字/背景/縁取り3色に
加え、Depth用に3色追加されている。そして、レンダリングエンジンが字幕を描画することができる。
テキスト字幕ストリームは、PGストリームと異なり、グラフィクスデータをビットマップとして送るのではなく、フォントデータと文字コードを送ることにより、レンダリングエンジンで字幕を生成するから、字幕の立体視は、1plane＋Offsetモードによって実現する。テキスト字幕を1plane＋Offsetモードで表示する場合、モードの切り替えは、フォントセットの切り替えか、レンダリング方式の切り替えによってなされる。L/Rフォントセ
ットやOpenGLフォントセットを定義することでモード切り替えを行う方法もある。レンダリングエンジンが3D表示を行う事も可能である。
3D-LRモードでは、ベースビューと、ディペンデントビューとで独立したフォントセッ
トやOpenGLフォントセットを定義することで立体視再生を実現する。また、レンダリングエンジンが3Dフォントを描画することで立体視再生を実現してもよい。
3D-Depthモードの場合は、深度映像をレンダリングエンジンで生成する。
以上がテキスト字幕ストリーム及びテキスト字幕デコーダについての説明である。続いて、IGストリームの内部構成と、IGデコーダの構成とについて説明する。
・IGストリーム
レフトビューIGストリーム、ライトビューIGストリームは何れも複数のディスプレイセットを含み、各ディスプレイセットは、複数の機能セグメントを含む。ディスプレイセットには、PGストリームと同様、エポックスタートのディスプレイセット、ノーマルケースのディスプレイセット、アクジッションポイントのディスプレイセット、エポックコンティニューのディスプレイセットが存在する
これらのディスプレイセットに属する複数の機能セグメントには以下の種類がある。
(1)オブジェクト定義セグメント
このオブジェクト定義セグメントは、PGストリームのものと同じである但しIGストリームのグラフィクスオブジェクトは、ページのインエフェクト、アウトエフェクト、ボタン部材のノーマル状態、セレクテッド状態、アクティブ状態を定義するものである。オブジェクト定義セグメントは、ボタン部材の同じ状態を定義するもの同士、同じエフェクト映像を構成するもの同士、グループ化されている。同じ状態を定義するオブジェクト定義セグメントを寄せ集めたグループをグラフィクスデータ集合という。
(2)パレット定義セグメント
パレット定義セグメントは、PGストリームのものと同じである。
(3)対話制御セグメント
対話制御セグメントは、複数のページ情報を含み、複数のページ情報は、マルチページメニューの画面構成を規定する情報であり、各ページ情報は、エフェクトシーケンスと、複数のボタン情報と、パレット識別子の参照値とを含む。
ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。
エフェクトシーケンスは、グラフィクスオブジェクトを用いて、ページ情報に対応する
ページの表示に先立ち再生されるインエフェクト、又は、当該ページの表示後に再生されるアウトエフェクトを構成するものであり、エフェクト情報を含む。
エフェクト情報は、インエフェクト又はアウトエフェクトを再生するにあたっての個々の画面構成を規定する情報であり、グラフィクスプレーン上のウィンドゥ定義セグメントで定義されたウィンドゥ（部分領域）においてどのような画面構成を実行すべきかを規定する画面構成オブジェクトと、同領域における次の画面構成との時間間隔を示すエフェクト期間情報とを含む。
エフェクトシーケンスにおける画面構成オブジェクトは、PGストリームの画面構成セグメントと同じような制御内容を規定する。オブジェクト定義セグメントのうち、前記インエフェクトに用いられるグラフィクスオブジェクトを定義するものは、グラフィクスデータ列において、ボタン部材に用いられるグラフィクスオブジェクトを定義するオブジェクト定義セグメントより前に配置されている。
ページ情報における各ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。前記ボタン情報はセットボタンページコマンドを含み、セットボタンページコマンドは、対応するボタン部材がアクティブ状態になった際、ファーストページ以外の他のページを、カレントページとして設定する処理を再生装置に行わせるコマンドである。
IGストリームの再生時において、プレーンシフトにおけるオフセットをページ毎に変更させたい場合は、ボタン情報にオフセットを変更するナビゲーションコマンド組込んでおき、該当するボタン情報において、ナビゲーションコマンドのオートアクティベートを規定しておく。これにより、IGストリームのストリーム登録情報に規定されているオフセットの値や方向を自動的に変更できるようにする。
(4)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグ
メントである。対話制御セグメントからこのエンドセグメントまでが、1つのディスプレ
イセットを構成する機能セグメントであるとして解釈される。
レフトビューグラフィクスストリームと、ライトビューグラフィクスストリームとにおいて、同一となる対話制御セグメントの制御項目には、ボタン近接情報、セレクションタイムアウトタイムスタンプ、ユーザタイムアウトディレーション、コンポジションタイムアウト情報がある。
１.ボタン近接情報
ボタン近接情報は、あるボタンがセレクテッド状態になっていて、上下左右方向の何れかを指示するキー操作があった場合、どのボタンをセレクテッド状態にすべきかを指定する情報である。
２.セレクションタイムアウトタイムスタンプ
セレクションタイムアウトタイムスタンプは、カレントページにおけるボタン部材を自動的にアクティベートして、セットボタンページコマンドを再生装置に実行させるためのタイムアウト時間を示す。
３.ユーザタイムアウトディレーション
ユーザタイムアウトディレーションは、カレントページをファーストページに戻して、
ファーストページのみが表示されている状態にするためのタイムアウト時間を示す。
４.コンポジションタイムアウト情報
コンポジションタイムアウト情報は、対話制御セグメントによる対話的な画面表示を終了させる時間を示す。IGストリームにおいてディスプレイセットの開始時点は、対話制御セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、対話制御セグメントのコンポジションタイムアウト時刻によって特定される。レフトビュー、ライトビューでは、これらのDTSと、コンポジションタイムアウト時刻とは同
一時点に設定される。
・IGデコーダのデコーダモデル
IGデコーダは、IGストリームから読み出されう機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するための「トランスポートバッファ」が存在する。

グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのための「シフト部」とが存在する。
図５８は、IGデコーダのデコーダモデルを示す。本図では、IGデコーダ本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲んでいる。IGデコーダ前段にあたる部分は、破線枠で囲んでいる。
図５８（ａ）は、2D形式のIGストリームを1plane＋Offsetモード方式によってLR形式で表示するためのデコーダモデルである。同図（ｂ）は、IGストリームのデコーダモデルであるが、LR方式のデータを表示する場合のデコーダモデルである。
これらのデコーダでは、メニューグラフィクスの深度情報をプログラムから制御するために、システムパラメータの値をオフセットに反映するための回路を含んでいる。
同図（ｂ）は、2デコーダモデルであり、コマンドによりoffset値の変更が可能になる
。よってメニューの深度情報をコマンドで変えることができる。Offset値は左右異なる値も与えられる。一方、Depth方式の場合、Offsetは無効になる。
グラフィクスデコーダにおけるコンポジションコントローラは、対話画面に存在するボタン部材のうち、カレントボタンになるものを、セレクテッド状態に対応するグラフィクスデータ集合のグラフィクスデータを用いて表示し、それ以外のボタン部材を、ノーマル状態に対応するグラフィクスデータ集合を用いて表示することで、対話画面の初期表示を実現する。
上下左右の４方向の何れかを指定する旨のユーザ操作があった場合、カレントボタンの周辺に位置するノーマル状態のボタン部材のうち、ユーザ操作により指定された方向に存
在するものの番号をボタン番号レジスタに書き込み、当該書き込みによって、新たにカレントボタンになったボタン部材をノーマル状態からセレクテッド状態に変化させる。
対話画面においてセレクテッド状態になっているボタン部材をアクティブ状態に変化させる旨のユーザ操作があった場合、当該アクティブ状態を構成するグラフィクスデータをグラフィクスデータ集合から取り出して表示に供することで対話画面の更新を実現する。
これらの対話画面の更新は、レフトビュー、ライトビューで共通に実行にする必要があるので、２デコーダモデルにおいて、コンポジションコントローラを、レフトビュー用のグラフィクスデコーダと、ライトビュー用のグラフィクスデコーダとで共通化することが望ましい。
この場合、立体視IGストリームにおけるレフトビュー・ライトビューのナビゲーションコマンドは同一化し、3D用と2D用のグラフィクスオブジェクトのボタン構成を同一にすることで、相互切り替えを実現する。
2DIGストリームと、立体視IGストリームとでは、ナビゲーションコマンドおよびボタン情報の属性・数などが同じであれば、グラフィクスオブジェクトの表示のみの切り替えが可能となる。3D-LRモードからL画像のみへの切り替えでは、再ロードなしに切り替え可能だが、表示位置が偏る可能性がある。どちらを採用するかのタイトル制作者の意図をフラグに示させておき、このフラグに基づき再生装置が切り替えを行うことが望ましい。
以下に、モード切り替え時における留意事項をまとめた。
・1plane＋Offsetモードと、2Dモードとの切り替えにおいては再ロードは発生しない。これはIGストリームのロードは必要ではなく、Offsetの無効化のみとなるからである。
・3D-LRモードと、2Dモードとの切り替えにおいて、ストリームが異なるため、再ロー
ドが発生する。
・ 3D-Depthと2Dとの間では、プリロード時に深度情報のデコードが完了していれば再ロードは発生しない。
・AV再生開始前にメモリに読み込むというプリロードモデルが採用されていたとしても、2Dモード/3Dモードの切り替えに伴い、IGストリームの再ロードが発生すれば、シーム
レス再生は保証されないケースが生じる。
以上がIGストリーム及びIGデコーダについての説明である。続いて、プレーンメモリの詳細について説明する。
1plane＋Offsetモード方式におけるプレーンメモリ構成について説明する。
プレーンメモリのレイヤ合成は、プレーンメモリのレイヤモデルにおいて、階層間のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける階層間の全ての組合せに対して実行することでなされる。合成部２０８によるレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリ
に格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
階層間の重畳は、ある階層に位置するプレーンメモリのライン単位の画素値に透過率αを重みとして乗じるとともに、その下位階層に位置するプレーンメモリのライン単位の画素値に（１−透過率α）という重みを乗じて これら輝度の重み付けがなされた画素値同
士を加算し、加算結果を、その階層におけるライン単位の画素の画素値とする処理である。この階層間の重畳を、レイヤモデルの隣接する2つ階層に位置するライン単位の画素同
士で繰り返し実行することにより、上記レイヤ合成は実現される。
プレーンメモリ後段は、上述したようなCLUT部、シフト部の他、レイヤ合成を実現するため、個々の画素値に等価率を乗算するための乗算部、画素同士の加算を行うための加算部、セカンダリビデオの位置決め・スケーリング変更を行うためのScalling&Positioning部を含む
図５９は、デコーダモデルの出力を合成し、3D-LR方式で出力するための回路構成を示
す。プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、２組み存在していることがわかる。また、プレーンメモリ後段にあたる部位も、２組み存在していることがわかる。
レイヤモデル、プレーンメモリ後段が2組み存在することにより、3D-LR方式におけるプレーンメモリ構成は、プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのそれぞれが、レフトビュー用と、ライトビュー用とに別れていて、これらのプレーンメモリの出力をレイヤ合成を、レフトビュー、ライトビューのそれぞれについて実行するようになっている。
セカンダリビデオプレーンでは、プライマリビデオストリームと同様に、セカンダリビデオストリームを3D-LRモードや3D-Depthモードで表示することが可能である。また、PG
ストリームのように2D映像にオフセットを与えて、平面の映像を手前に浮き出させて表示することも可能である。
図６０は、これらのデコーダモデルの出力を合成し、1plane＋Offsetモード方式で出力するための回路構成を示している。
レフトビュー用のプライマリビデオプレーン、ライトビュー用のプライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、１組みだけが存在していることがわかる。また、プレーンメモリ後段にあたる部位は、２組み存在している。
1plane＋Offsetモード方式では、プライマリビデオプレーンは、レフトビューのものと、ライトビューのものとが準備されている。セカンダリビデオプレーン、PGプレーン、IGプレーンについては、レフトビュー、ライトビューのそれぞれに別れておらず、レフトビュー、ライトビューで共通の１枚のプレーンメモリのみが存在する。そして、これらのレフトビュー出力、ライトビュー出力のそれぞれに対して上述したようなレイヤ合成がなされるようになっている。
再生装置は、B−Dプレゼンテーションモード、1plane＋Offsetモードの双方をサポートにする必要があるので、再生装置のハードウェア構成としては、基本的に2デコーダ＋2プレーンの構成になっていて、1plane＋Offsetモード、2D再生モードに再生装置が切り替った際、１デコーダ＋１プレーンの組みのうち一方を無効化して、１デコーダ＋１プレーン構成になる。
3D再生モードから2D再生モードへの切り替えが生じ再生装置の構成が、2デコーダ＋2プレーン構成から1デコーダ＋1プレーン構成に変化した場合、多重分離の対象は、Ｌ画像を構成するTSパケットのみとなる。そうすると、3D眼鏡を通じてＬ画像、Ｒ画像を視聴して
いたユーザは、3D再生モードから2D再生モードに切り替った途端、Ｌ画像しか見えなくなる。
この場合、両目によるTVの視聴が、片目によるTVの視聴に切り替わることになり、目の負担が大きくなって、悪寒を覚えるユーザも出てくる。そこで本実施形態では、切り替った場合、PIDフィルタの対象を、Ｌ画像を構成するTSパケット、Ｒ画像を構成するTSパケ
ットから、Ｌ画像を構成するTSパケットに切り替えると共に、グラフィクスデコーダにおけるメモリ管理をリセットする。そして、切り替えにおいて、上述したような悪寒を請じさせることがないよう、字幕を一旦消去することにする。
以上のように本実施形態によれば、デコーダ構成を2デコーダ構成から1デコーダ構成に切り替える際、プレーンメモリにおける字幕を一旦リセットするので、両目によるTVの視聴が、片目によるTVの視聴に切り替わることによる目の負担をやわらげることができる。
(第５実施形態)
本実施形態では、これまでの実施形態で説明した記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。
これまでの実施形態で説明した記録媒体は、多層化された光ディスクであるBD-ROMディスク、BD-ROMディスクと再生互換性があるようなBD-REディスク、BD-Rディスク、AVC-HD
メディアとして作成することができる。
図６１は、多層化された光ディスクの内部構成を示す。
第１段目は、多層化された光ディスクの一例であるBD-ROMを示し、第２段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領
域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域から構成される。これらの第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域は、1つ
の連続した論理アドレス空間を構成する。
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで、BD-ROMのような読み込み専用ディスクの場合には、基本的に論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。ただし、記録層の境界においては、論理アドレスが連続していたとしても連続的な読み出しはできない。そのため、層境界の論理アドレスは、予め記録装置に登録されているものとする。
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROMの場合ではUDF（Universal Disc Format）によって記録される。日常使っているPC（パーソナルコンピュータ）の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造で
ハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。
第４段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第５段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。
図６２は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。
BDMVディレクトリはBD-ROMで扱うTSや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディ
レクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と
呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」，「MovieObject.bdmv」の２種類のファイルが配置されている。
「index.bdmv(ファイル名固定)」は、インデックステーブルを格納している。
「MovieObject.bdmv（ファイル名固定）」は、1つ以上のムービーオブジェクトを格納
している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。
「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo[“xxxxx”は可変、拡張子”bdjo”は固定])が存在する。このプログラムファイルは、BD-Jモードにおいて、再生装置が行うべき制御手順を規定するBDーJオブジェクトを格納している。このBDーJオブジェクトは、「アプリケーション管理テーブル」を含む。BD-Jオブ
ジェクト内の「アプリケーション管理テーブル」は、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。アプリケーション管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定する『アプリケーション識別子』と、『制御コード』とを含む。アプリケーション管理テーブルにより生存区間が規定されるBD-Jアプリケーションを、特に『BD-Jアプリケーション』という。制御コードは、AutoRunに設定され
た場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、
他のアプリケーションからのコールを待って、起動すべき旨を示す。一方、BD-Jアプリケーションの中には、タイトルが終了したとしても、その動作が終了しないアプリケーションがある。かかるアプリケーションを、“タイトルアンバウンダリアプリケーション”という。
このJava（登録商標）アプリケーションの実体にあたるのが、BDMVディレクトリ配下のJARディレクトリに格納されたJava（登録商標）アーカイブファイル(YYYYY.jar)である。

アプリケーションは例えばJava（登録商標）アプリケーションであり、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる
。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。
「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls[“xxxxx”は可変、拡張子”mpls”は固定])が存在する。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.
clpi [“xxxxx”は可変、拡張子”clpi”は固定])が存在する。
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、ストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts([“xxxxx”は可変、拡張子”m2ts”は固定])という形
式でストリームファイルが格納される。
上述したようなファイルは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクト
リ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、
ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述
子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリーについての説明である。続いて、ディレク
トリファイルの詳細について説明する。
「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリ
のファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。
「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
本願の主眼となるストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
以上が記録媒体の内部構成についての説明である。続いて、図６１及び図６２に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディス
ク、半導体メモリカードに記録する。
この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたTSであってもよいし、記録装置がデジタル入力したTSをパーシャル化することで得られるTSであってもよい。リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TSを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAV
クリップファイルに格納してBD-RE,BD-R等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップのストリームファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
そして、装置外部から入力されるTSからビデオストリームにおけるGOPの先頭位置が検
出されるか、エンコーダによってビデオストリームのGOPが生成されれば、記録装置の制
御部は、このGOPにおいて、先頭に位置するイントラピクチャのPTSと、このGOPの先頭部
分を格納したソースパケットのパケット番号とを取得して、このPTS及びパケット番号の
組みを、EP＿PTSエントリー及びEP＿SPNエントリーの組みとして、クリップ情報ファイルのエントリーマップに追記する。以降、GOPが生成される度に、EP＿PTSエントリー及びEP＿SPNエントリーの組みを、クリップ情報ファイルのエントリーマップに追記してゆく。
この際、GOPの先頭がIDRピクチャである場合は、“オン”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。GOPの先頭がIDR
ピクチャでなければ場合は、“オフ”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。
また、クリップ情報ファイルにおけるストリームの属性情報については、記録されるべきストリームの属性に従い設定する。以上のようにしてAVクリップ、クリップ情報が生成されてBD-RE,BD-Rに書き込まれれば、このクリップ情報内のエントリーマップを介して、再生経路を定義するプレイリスト情報を生成し、BD-RE,BD-Rに書き込む。このような処理を、リアルタイムレコーディング技術において実行することで、AVクリップ−クリップ情報−プレイリスト情報という階層構造をBD-RE,BD-R上に得ることができる。
以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法について説明する。
プレフォーマットレコーディングによる記録方法は、オーサリング行程を含むような光ディスクの製造方法となる。
図６３は、光ディスクの記録方法を示す。同図（ａ）は、プレフォーマットレコーディングによる記録方法を示すフローチャートであり光ディスクの製造方法の処理手順を示す。光ディスクの製造方法は、オーサリングステップ、署名ステップ、メディア鍵取得ステップ、メディア鍵暗号ステップ、物理フォーマットステップ、識別子埋め込みステップ、マスタリングステップ、レプリケーションステップを含む。
オーサリングステップS２０１は、光ディスクのボリューム領域の全体像を表すビット
ストリームを作成する。
署名ステップS２０２は、光ディスクの製造にあたってAACS LAに対して署名要求を行う。具体的には、ビットストリームの一ステップを抜き出し、AACS LAに送付する。ここでAACS LAは、次世代のデジタル家電機器における著作物保護技術に関するライセンスを管理する団体である。オーサリング装置を用いて光ディスクのオーサリングを行うオーサリングサイト、及び、マスタリング装置を用いてマスタリングを実行するマスタリングサイトは、AACS LAよりライセンスの提供を受ける。また、メディア鍵、無効化情報を管理する
。そして、AACS LAより署名されたビットストリームの一部分を取得する。
メディア鍵取得ステップS２０３は、AACS LAからメディア鍵を取得する。メディア鍵は、常に固有のものが使用されるわけではなく、これまで製造された光ディスクの枚数が一定枚数まで達すると新しいものに更新される。メディア鍵を更新することにより、特定のメーカーや機器を排除することができ、万が一暗号鍵が破られたとしても、無効化情報を用いることでそれ自体を無効化することができる。
メディア鍵暗号化ステップS２０４は、メディア鍵取得ステップにより取得したメディ
ア鍵を用いて、ビットストリームの暗号化に用いた鍵を暗号化する。
物理フォーマットステップS２０５は、ビットストリームに対して物理フォーマットを
実行する。
識別子埋込みステップS２０６は、光ディスクに収録されるビットストリームに、一般
の機器では検出することができない一意の識別子を電子透かしとして埋め込む。これにより、不正なマスタリングによる海賊版の量産を防ぐことができる。
マスタリングステップS２０７は、光ディスクの原盤を作製する。まず、ガラス基板上
にフォトレジスト層を形成し、当該フォトレジスト層に対して、所望するグルーブやピッ
トに対応するようにレーザ光を照射して露光し、現像処理を施す。このグルーブやピットは、8ー16変調されたビットストリームの各ビット値を表すものである。その後、このよ
うなレーザカッティングによってグルーブやピットに対応した凹凸が形成されたフォトレジストを元にして、光ディスクの原盤を作製する。
レプリケーションステップS２０８は、光ディスクの原盤を用いて、その複製である光
ディスクを大量生産する。
図６５（ｂ）は、光ディスクを大量生産するのではなく、一般ユーザがPCを使って、BD-R,BD-RE等に、これまでの実施形態で述べた各種ファイルを記録する場合のプリフォーマットレコーディングによる記録方法の処理手順を示す。同図（ａ）と比較すると、同図（ｂ）による記録方法では、物理フォーマット(ステップ２０５)、マスタリング(ステップS２０７)、レプリケーション(ステップS２０８)が存在せず、代わりに、各ファイルの書き込み行程(ステップS２０９)が存在する。
次にオーサリング行程について説明する。
図６４は、オーサリング行程の処理手順を示すフローチャートである。
ステップS１０１において、メインTS及びサブTSについてのリールセットを定義する。
“リール”とは、エレメンタリストリームの素材となるデータを格納したファイルであり、オーサリングシステムでは、ローカルネットワーク上のドライブ上に存在する。3Dカメラによって撮影されたL画像やR画像、撮影時に録音された音声や、その後のアフレコで収録された音声、言語毎の字幕、メニューをデータ化したものが、これらリールに該当する。“リールセット”とは、1つのTSに多重化されるべきエレメンタリストリームの集合を
表した、素材ファイルへのリンク群である。ここでは、メインTS、サブTSのそれぞれについてリールセットが定義される。
ステップS１０２において、プレイアイテム、サブプレイアイテムの原型を定義し、プ
レイアイテム、サブプレイアイテムの再生順序を定義することでメインパス、サブパスの原型を定義する。プレイアイテムの原型の定義は、平面視再生モードにおいて、そのプレイアイテムで再生を許可すべきリールの指定と、In＿Time／Out＿Timeとの指定を、GUIを通じて受け付けることでなされる。サブプレイアイテムの原型の定義は、立体視再生モードにおいて、そのサブプレイアイテムに対応するプレイアイテムで再生を許可すべきリールの指定と、In＿Time／Out＿Timeとの指定を、GUIを通じて受け付けることでなされる。
再生を許可すべきリールの指定は、リールセットにおける素材ファイルのリンクのうち、再生を許可すべきものをチェックボックスでチェックするというGUIで構成される。こ
の際、各リールに対応付けて数値入力欄を表示する。そして、この数値入力欄によって、各リールについての優先順位を受け付け、これをリールに対応する優先順位とする。以上の再生を許可すべきリールの設定と、優先順位の設定とからストリーム選択テーブル、拡張ストリーム選択テーブルが生成されることになる。
In＿Time及びOut＿Timeの指定は、GUI上で、ベースビュービデオストリーム又はディペンデントビュービデオストリームの時間軸を図形化して表示し、図形化された時間軸において、スライドバーを移動させて、そのスライドバーの位置設定をユーザから受け付けるという処理を記録装置が実行することでなされる。
プレイアイテム、サブプレイアイテムの再生順序の定義は、GUI上でプレイアイテムのIn＿Timeにおけるピクチャをサムネール化して表示し、このサムネールに対して、再生順序を設定するという操作を記録装置がユーザから受け付けることでなされる。
ステップS１０３では、リールセットにて指定された素材ファイルをエンコードするこ
とにより、複数のエレメンタリストリームを得る。これらの複数のエレメンタリストリームは、ベースビュービデオストリーム、ディペンデントビュービデオストリームと、これらベースビュービデオストリーム、ディペンデントビュービデオストリームと多重化されるべきオーディオストリーム、PGストリーム、IGストリームがある。
ステップS１０４では、エンコードで得られたエレメンタリストリームのうち、ベース
ビュービデオストリームと同じリールセットに属する同じするものを、当該ベースビュービデオストリームと多重化することで、1つのメインTSを得る。
ステップS１０５では、エンコードで得られたエレメンタリストリームのうち、ディペ
ンデントビュービデオストリームと同じリールセットに属するものを、当該ディペンデントビュービデオストリームと多重化することで、1つのサブTSを得る。
ステップS１０６では、エンコード及び多重化時に設定されたパラメータを元に、クリ
ップ情報ファイルの原型を生成する。
ステップS１０７では、プレイアイテムの原型を元にプレイアイテム情報、サブプレイ
アイテム情報を生成し、これらのプレイアイテム情報、サブプレイアイテム情報に再生順序を定義することで、メインパス情報、サブパス情報を生成して、プレイリスト情報を定義する。
プレイアイテム情報の作成においては、メインTSに多重化されたエレメンタリストリームのうち、プレイアイテムの基本構造において平面視再生モードで再生すべきと規定されたものを再生可能に設定すべく、プレイアイテム情報内にストリーム選択テーブルを生成する。また、ベースビュービデオストリームにおける再生区間を規定するため、上述の編集作業で規定されたIn＿Time、Out＿Timeをプレイアイテム情報に記載する。
サブプレイアイテム情報の作成においては、サブTSに多重化されたエレメンタリストリームのうち、プレイアイテムの基本構造において立体視再生モードで再生すべきと規定されたものを再生可能に設定すべく、プレイリスト情報のエクステンションデータ内に拡張ストリーム選択テーブルを生成する。プレイアイテム情報、サブプレイアイテム情報は、クリップ情報ファイル内の情報を元に定義されるからクリップ情報ファイルの原型を元にして設定される。
ステップS１０８では、メインTS、サブTS、クリップ情報ファイルの原型、プレイリス
ト情報の原型を、所定のアプリケーションフォーマットに従ったディレクトリーファイル群に変換する。
以上の過程を得て、メインTS、サブTS、クリップ情報、プレイアイテム情報、サブプレイアイテム情報が生成されれば、メインTS、サブTSをそれぞれ独立したストリームファイルに変換し、クリップ情報をクリップ情報ファイルに変換し、プレイアイテム情報及びサブプレイアイテム情報をプレイリスト情報ファイルに変換することで、記録媒体に記録されるべき一連のファイルセットを得る。
線形関数、放物線関数の関数式から、各フレーム毎の奥行きを算出する場合、ビデオストリームのフレーム時刻から、フレーム時刻毎の奥行きを導く関数を、記録装置のアプリケーションプログラムインターフェイスに定義しておき、この関数に、ベースビュービデオストリームのフレーム時刻を与えて、各フレーム時刻毎の奥行きを算出する。そして、算出されたそれぞれの奥行きを、プレーンオフセット値、オフセット方向情報に変換する。
その後、ビデオストリームのエンコード行程の実行にあたって、上記変換で得たプレーンオフセット値、オフセット方向情報を、各GOPのメタデータに記載すれば、オフセット
シーケンスは、エンコードの過程で作成しておくことができる。
図６５は、AVファイル書込工程の処理手順を示す。リアルタイムレコーディングによる記録方法や、マスタリング、レプリケーションを伴い記録方法の実施では、AVファイルの書き込みを、本図のフローチャートによって実現する。
ステップＳ４０１において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップＳ４０２は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップＳ４０３において、空きの連続セクタ領域にディペンデントビューデータブロックを構成するソースパケット列をEXT2[i]だけ書
き込み、その後、ステップＳ４０４〜ステップＳ４０８を実行する。確保し得ない場合は、ステップＳ４０９で例外処理をした後、記録方法を終了する。
ステップＳ４０４〜ステップＳ４０８は、ステップＳ４０７がNoと判定されるまで、ステップＳ４０４〜ステップＳ４０６、ステップＳ４０８の処理を繰り返すループを構成している。
ステップＳ４０５は、空きの連続セクタ領域に、ベースビューデータブロックを構成するソースパケット列をEXT1[i]だけ書き込む。ステップＳ４０６は、ソースパケット列が
書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。これに伴い、書き込まれたソースパケット列の先頭ソースパケット番号を指し示すエクステントスタートポイント情報を、クリップベース情報、クリップディペンデント情報内のメタデータに追記する。
ステップＳ４０７は、ループの終了条件を規定するものであり、ベースビューデータブロック、ディペンデントビューデータブロックに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップＳ４０８に移行して、ループを継続する。存在しなければ、ステップＳ４１０に移行する。
ステップＳ４０８は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップＳ４０３に移行し、存在しなければ、ステップＳ４０２まで戻る。
ステップＳ４１０では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップＳ４１１では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップＳ４１２では、ファイル2Dで固有となるベースビューデータブロックの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップＳ４１３では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。
ステップＳ４０４は、EXTSS＋EXT2Dの範囲内に、ロングジャンプの発生地点が存在するかどうかの判定である。ここでのロングジャンプの発生地点は、層境界であるものとする。EXTSS＋EXT2Dの範囲内に層境界が存在する場合、ステップＳ４２０において、ベースビューデータブロックを複製して、ベースビューデータブロックB[i]ssと、ベースビューデータブロックB[i]2Dとをロングジャンプ発生地点の直前までに書き込み、その後、ステップＳ４０６に移行する。これらが、ファイル2Dのエクステント、ファイルベースのエクステントになる。
次に、オーサリングステップの作業に用いられる記録装置について説明する。ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリン
グスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成して、マスタリングサイトに引き渡すための記録媒体に記録するというのが、本発明にかかる記録装置の使用形態である。
図６６は、記録装置の内部構成を示す。本図に示すように、記録装置は、ビデオエンコーダ５０１、素材制作部５０２、シナリオ生成部５０３、BDプログラム制作部５０４、多重化処理部５０５、フォーマット処理部５０６により構成される。
ビデオエンコーダ５０１は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG４-AVCやMPEG２などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部５０１aに書き込む。ビデオエンコーダ５０１は、ピクチャ間の相関特性を利用した画像圧縮を
するために、８x８や１６x１６のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。
マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、８ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。
素材制作部５０２は、オーディオストリーム、PGストリーム、IGストリームなどの各ストリームを作成して、オーディオストリーム格納部５０２a、IGストリーム格納部５０２b、PGストリーム格納部５０２cに書き込む。
オーディオストリーム作成にあたって素材制作部５０２は、非圧縮のLinearPCM音声な
どをAC３などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部５０２は、字幕イメージと表示タイミング、およびフェードイン/フェ
ードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるPGストリームを作成する。素材制作部５０２は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるIGストリームを作成する。
シナリオ生成部５０３は、素材制作部５０２で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BD-ROMフォーマットでシナリオ
を作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部５０３は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第１実施形態１および
第２実施形態で説明したデータ構造となる。
BDプログラム制作部５０４は、GUI等のユーザインターフェースを通じて、ユーザから
の要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するため
に、ビデオエンコーダ５０１が出力した奥行き情報を利用することができる。
多重化処理部５０５は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG２-TS形式のAVクリップを作成する。このとき、AVク
リップと対になるクリップ情報ファイルも同時に作成する。
多重化処理部５０５は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。
フォーマット処理部５０６は、シナリオ生成部５０３で生成したBD-ROMシナリオデータと、BDプログラム制作部５０４で制作したBDプログラムファイル、多重化処理部５０５で生成したAVクリップやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフ
ォーマットでディスクイメージを作成して、ディスクイメージを表すビットストリームをBD-ROMビットストリーム格納部５０７に書き込む。
また、この時ビデオエンコーダ５０１が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトはこれまでに説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。
(第６実施形態)
本実施形態では、これまでの実施形態で説明した再生装置の機能を統合した、2D/3D再
生装置の内部構成について説明する。
図６７は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BD-ROMドライブ１、リードバッファ２a、リードバッファ２b、スイッチ３、システムターゲットデコーダ４、プレーンメモリセット５a、プレーン合成部５b、HDMI送受信部６、再生制御部７、管理情報メモリ９、レジスタセット１０、プログラム実行部１１、プログラムメモリ１２、HDMVモジュール１３、BD-Jプラットフォーム１４、ミドルウェア１５、モード管理モジュール１６、ユーザイベント処理部１７、ローカルストレージ１８、不揮発メモリ１９から構成されている。
BD-ROMドライブ１は、2D再生装置と同様に再生制御部７からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ２aかリードバッファ２bに転送される。
3D映像を再生する際には、再生制御部７からはベースビューデータブロックとディペンデントビューデータブロックとをエクステント単位で交互に読み出す旨を指示する読出要
求が送られる。BD-ROMドライブ１は、ベースビューデータブロックを構成するエクステントをリードバッファ２aに読み出し、ディペンデントビューデータブロックを構成するエ
クステントをリードバッファ２bに読み出す。3D映像を再生する際には、ベースビューデ
ータブロックとディペンデントビューデータブロックの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。
リードバッファ２aは、BD-ROMドライブ１が読み込んだベースビューデータブロックの
データを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ２bは、BD-ROMドライブ１が読み込んだディペンデントビューデータブ
ロックのデータを格納するデュアルポートメモリ等で構成されたバッファである。
スイッチ３は、リードバッファに対するデータ入力源を、BD-ROMドライブ１又はローカルストレージ１８の何れかに切り替えるためのスイッチである。
システムターゲットデコーダ４は、リードバッファ２aに読み出されたソースパケット
とリードバッファ２bに読み出されたソースパケットに対して多重分離処理を行いストリ
ームのデコード処理を行う。
プレーンメモリセット５aは、複数のプレーンメモリから構成される。プレーンメモリ
には、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーンといったものがある。
プレーン合成部５bは、これまでの実施形態で説明したプレーン合成を行う。テレビな
どへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。
HDMI送受信部６は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）
において、第１実施形態に述べた認証フェーズ、ネゴシエーションフェーズを実行する。ネゴシエーションフェーズでは、立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報をテレビから受け取ることができる。
再生制御部７は、再生エンジン７a、再生制御エンジン７bを含み、3Dプレイリストの再生がプログラム実行部１１などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムのベースビューデータブロックを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのディペンデントビューデータブロックを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点からベースビューデータブロックのエクステントと、ディペンデントビューデータブロックのエクステントとを交互に読み出すようにBD-ROMドライブ１に要求する。再生開始するときには、最初のエクステントをリードバッファ２aか、リードバ
ッファ２bに読みきった後に、リードバッファ２aとリードバッファ２bからシステムター
ゲットデコーダ４に転送を開始する。
再生エンジン７aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処
理である。
再生制御エンジン７bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモ
ードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。
管理情報メモリ９は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。
再生状態／設定レジスタ(Player Status/Setting Register)セット１０は、これまでの実施形態で述べた再生状態レジスタ、再生設定レジスタの他、プログラムファイルが利用する任意の情報を格納できる汎用レジスタを含む。
プログラム実行部１１は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。（１）再生制御部７に対してプレイリスト再生を命令する。（２）システムターゲットデコーダに対してメニューやゲームのグラフィクスのためのPNG・JPEGを転送して画面に表示
する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBD-Jアプリケーションのプログラミング工程によって決まる。
プログラムメモリ１２は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BD-Jモードの動作主体であるJavaプラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。またプログラムメモリ１２は、ヒープメモリを含む。
ヒープメモリは、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である
HDMVモジュール１３は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモ
ードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述さ
れているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライク
な再生制御を実現することができる。
BD-Jプラットフォーム１４は、BD-Jモードの動作主体であるJavaプラットフォームであり、Java2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsとをフル実装しており、
クラスローダ、バイトコードインタプリタ、アプリケーションマネージャから構成される。
クラスローダは、システムアプリケーションの1つであり、JARアーカイブファイルに存
在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、BD-Jアプリケーションのロードを行う。
バイトコードインタプリタは、いわゆるJava仮想マシンであり、ヒープメモリに格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
アプリケーションマネージャは、システムアプリケーションの1つであり、BD-Jオブジ
ェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。以上で、BD-Jプラットフォーム部の内部構成についての説明を終える。
ミドルウェア１５は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特
有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。
モード管理モジュール１６は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モード管理モジュールによるモード管理とは、動的シナリオを、BD-Jプラットフォーム２２、HDMVモジュールのどちらに実行させるかという、モジュールの割り当てである。
ユーザイベント処理部１７は、リモコンを通じたユーザ操作に応答して、プログラム実行部１６や再生制御部７に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部１６に依頼する。例えば、リモコンで早送り・巻戻しボタンが押された場合には、再生制御部７に、現在再生しているプレイリストのAVクリップに対する早送り・巻戻し処理の実行を命令する。
ローカルストレージ１８は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。
不揮発メモリ１９は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これ
は、レジスタセット１０における記憶内容のバックアップに用いられる。
次に、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成につい
て説明する。図６８は、システムターゲットデコーダ４及びプレーンメモリセット５aの
内部構成を示す。本図に示すように、システムターゲットデコーダ４及びプレーンメモリセット５aは、ATCカウンタ２１、ソースデパケッタイザ２２、PIDフィルタ２３、STCカウンタ２４、ATCカウンタ２５、ソースデパケッタイザ２６、PIDフィルタ２７、プライマリビデオデコーダ３１、レフトビュービデオプレーン３２、ライトビュービデオプレーン３３、セカンダリビデオデコーダ３４、セカンダリビデオプレーン３５、PGデコーダ３６、PGプレーン３７、IGデコーダ３８、IGプレーン３９、プライマリオーディオデコーダ４０、セカンダリオーディオデコーダ４１、ミキサー４２、レンダリングエンジン４３、GFX
プレーン４４から構成される。
プライマリビデオデコーダ３１は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン３２に書き込む。
レフトビュービデオプレーン３２は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
ライトビュービデオプレーン３３は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
セカンダリビデオデコーダ３４は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻（PTS）のタイミング
でピクチャをセカンダリビデオプレーンに書き出す。
セカンダリビデオプレーン３５は、システムターゲットデコーダ４からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
PGデコーダ３６は、ソースデパケタイザから入力される複数のTSパケットからPGストリームを抽出してデコードし、非圧縮のグラフィクスデータを表示時刻（PTS）のタイミン
グでPGプレーンに書き出す。
PGプレーン３７には、PGストリームをデコードすることで得られた非圧縮のグラフィクスオブジェクトが格納される。
IGデコーダ３８は、ソースパケタイザから入力される複数のTSパケットからIGストリームを抽出してデコードし、非圧縮のグラフィクスオブジェクトを表示時刻（PTS）のタイ
ミングでIGプレーンに書き出す。
IGプレーン３９には、IGストリームをデコードすることで得られたグラフィクスデータが格納される。
プライマリオーディオデコーダ４０は、プライマリオーディオストリームをデコードする。
セカンダリオーディオデコーダ４１は、セカンダリオーディオストリームをデコードする。
ミキサー４２は、プライマリオーディオデコーダ４０のデコード結果と、セカンダリオーディオデコーダ４１のデコード結果とを合成する。
レンダリングエンジン４３は、Java2D，OPEN-GLといった基盤ソフトウェアを備え、BD-Jアプリケーションから要求に従ってJPEGデータ／PNGデータのデコードを行い、イメージやウィジェットを得て、IGプレーン及びバックグラウンドグラフィクスプレーンに書き込む。JPEGデータをデコードすることにより得られる画像データは、GUIの壁紙になるもの
であり、バックグラウンドグラフィクスプレーンに着込まれる。PNGデータをデコードす
ることにより得られる画素データは、IGプレーンに書き込まれて、アニメーションを伴うボタン表示を実現することができる。これらJPEGデータ／PNGデータをデコードすること
で得られたイメージやウィジェットは、BD-Jアプリケーションが、タイトル選択や字幕選択、音声選択を受け付けるためのメニューを表示したり、ストリーム再生連動型のゲームを動作させるにあたって、GUI部品を構成するために使われる。その他、BD-Jアプリケー
ションがWWWサイトをアクセスする際、そのWWWサイトのブラウザ画面を構成するために用
いられる。
GFXプレーン４４は、JPEG，PNGなどのグラフィクスデータがデコードされた後、書き込まれるプレーンメモリである。
レンダリングメモリ４５は、レンダリングエンジンによってデコードされるべきPNGデ
ータ、JPEGデータが読み込まれるメモリである。このイメージメモリには、BD-Jアプリケーションが、ライブ再生モードを実行する際、キャッシュ領域が確保される。ライブ再生モードとは、ネットワーク上に存在するWWWサイトのブラウザ画面と、BD-ROMによるスト
リーム再生とを組み合わせるものであり、キャッシュ領域は、ライブ再生モード時における現在のブラウザ画面、及び、直前のブラウザ画面をキャッシュしておくためのキャッシュメモリであり、非圧縮のPNGデータ又は非圧縮のJPEGデータであって、前記ブラウザ画
面を構成するものがここに格納されることになる。
以上のように本実施形態によれば、これまでの実施形態で述べた特徴を包含した記録媒体をBD-ROMとして実現することができ、また、これまでの実施形態で述べた特徴を包含した再生装置をBD-ROM再生装置として実現することができる。
(第７実施形態)
本実施形態では、レジスタセットの詳細について説明する。
レジスタセットは、複数のプレーヤ状態レジスタ、複数のプレーヤ設定レジスタから構成される。個々のプレーヤ状態レジスタ、プレーヤ設定レジスタは何れも語長が３２ビットのレジスタであり、３２ビット長のレジスタのそれぞれにはレジスタ番号が与えられ、このレジスタ番号を用いてアクセスすべきレジスタが特定される。
各レジスタの一語(３２ビット)を構成する各ビットデータのビット位置は、b0〜b31と
呼ばれる。最上位ビットはb31、最下位ビットはb0と呼ぶ。そして、32ビットのうち、bx
ビット目のビット位置からbyビット目のビット位置までのビット範囲は、[bx:by]という
表記で表現される。
所定のレジスタ番号のプレーヤ設定レジスタ／プレーヤ状態レジスタに格納されている32ビット長のビット列であって、任意のビット範囲[bx:by]のものの値は、プログラムが
動作を行うにあたっての動作システムの環境変数(システムパラメータ又はプレーヤ変数
という)として扱われる。再生制御を行うプログラムは、システムプロパティやアプリケ
ーションプログラミングインターフェイス(API)を通じて、システムパラメータを取得す
ることができる。また、特に禁止されていない限り、これらのプレーヤ状態レジスタ、プレーヤ設定レジスタの値をプログラムは書き換えることができる。BD-Jアプリケーションについては、システムパラメータの取得や書き換えについて正当権限が、JARアーカイブ
ファイルにおけるパーミッション管理テーブルによって与えられていることが要件になる。
プレーヤ状態レジスタは、再生装置のMPUが算術演算やビット演算を行う際、その被演
算子となる数値を格納しておくためのハードウェア資源であり、光ディスクが装填された際に初期値が設定され、またカレントプレイアイテムの変更等、再生装置の状態が変化した際に、その格納値の有効性が判定されるレジスタである。この格納値としては、カレントのタイトル番号、カレントのプレイリスト番号、カレントのプレイアイテム番号、カレントのストリーム番号、カレントのチャプター番号等がある。光ディスクの装填時に初期値が格納されるので、この格納値は一時的なものであり、光ディスクがイジェクトされたり、また再生装置の電源が断たれれば、この格納値は有効性を失う。
プレーヤ設定レジスタは、電源対策が施されている点がプレーヤ状態レジスタとは異な
る。電源対策が施されているので、再生装置の電源遮断時において、その格納値が不揮発性のメモリに退避され、再生装置の電源投入時において、その格納値が復帰される。再生装置の製造主体(マニフャクチャ)が再生装置の出荷時に定めた再生装置の各種コンフィグレーションや、ユーザがセットアップ手順に従い設定した各種コンフィグレーション、そして、再生装置がTVシステムやステレオ、アンプ等のホームシアターシステムの機器と接続された際、接続相手となる機器とのネゴシエーションにより判明した相手側機器のケーパビリティがプレーヤ設定レジスタに設定される。
図６９は、レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図であ
る。
本図の左側にはレジスタセット１０の内部構成を示している。右側には再生制御エンジン７bの内部構成を示している。
それぞれのレジスタ番号が割り当てられたプレーヤ状態レジスタ、プレーヤ設定レジスタは、どのようなものであるかを示す。
PSR1は、オーディオストリームのためのストリーム番号レジスタであり、カレントのオーディオストリーム番号を格納する。
PSR2は、PGストリームのためのストリーム番号レジスタであり、カレントのPGストリーム番号を格納する。
PSR4は、1〜100の値に設定されることで、カレントのタイトル番号を示す。
PSR5は、1〜999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、カレントプレイリストの番号を示す。
PSR7は、0〜255の値に設定されることで、カレントプレイアイテムの番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM)を示す。以上がPSRについての説明である。
PSR10は、IGストリームのためのストリーム番号レジスタであり、カレントのIGストリ
ーム番号を格納する。
PSR21は、ユーザが、立体視再生を実行することを意図しているかどうかを示す。
PSR22は、出力モード値を示す。
PSR23は、“Display Capability for video”の設定である。これは、再生装置の接続
相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。
PSR24は、“Player Capability for 3D”の設定である。これは、再生装置に立体視再
生を実行する能力が存在するかどうかを示す。
一方、再生制御エンジン７bの内部には、レジスタセット１０におけるPSR4,PSR6,PSR21,PSR23と、管理情報メモリ９におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部８を備えている。PSR24におけるPlayer Capability for 3Dは、再生装置の3D再生
に関する能力全般を意味するものなので、“3D-Capability”と簡単に表記する場合があ
る。
PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図７０に
示すように規定されている。
図７０は、出力モードの選択モデルの状態遷移を示す。この選択モデルには、2つの一
般的な状態が存在する。楕円は、この一般的な状態、つまり、出力モード値がとりうる値である“Invalid”,“valid”を模式的に描いたものである。Invalidは出力モードが無効であり、Validは出力モードが有効である旨を示す。
一般的な状態は、状態遷移が起こらない限り、維持される。状態遷移は、プレイリスト再生の開始、ナビゲーションコマンドやBD-Jアプリケーションにより要求された出力モード変化、BD-Jタイトルへのジャンプがある。状態遷移が発生した際、出力モードプリレファレンスを獲得するためのプロシージャが実行される。
図中の矢印jm1,jm2,jm3・・・・jm12は、状態遷移のトリガとなる事象を模式的に示す
。本図における状態遷移には、以下のものがある。
『Load a disc』とは、BD-ROMが装填されたという状態を意味する。
『Start Presentation』とは、HDMVモードにおいて、プレイリストの再生開始(start Playlist playback)を意味する。BD-Jモードにおいては、BD-Jタイトルへの分岐を意味す
る。何故なら、BD-Jモードにおいては、BD-Jタイトルに分岐した場合、必ずしも、プレイリストの再生が開始されるとは限らないからである。
『Jump to BD-J title』は、BD-Jタイトルへの分岐を意味する。具体的には、インデックステーブルにおいて、BD-Jアプリケーションに対応付けられたタイトル(BD-Jタイトル)がカレントタイトルになることをいう。
『Start Playlist Playback』は、何等かのプレイリストを意味するプレイリスト番号
が、PSRに設定されて、プレイリスト情報が、カレントプレイリスト情報としてメモリに
読み出されることをいう。
『Change Output Mode』とは、BD-JアプリケーションがAPIをコールすることで、出力
モードを変化することをいう。
『Terminate presentation』とは、HDMVモードの場合は、プレイリストの再生が終了することをいい、BD-Jモードの場合は、BD-Jタイトルからインデックステーブルにおいてムービーオブジェクトに対応付けられたタイトル(HDMVタイトル)へとジャンプすることをいう。
ディスクがロードされた際、出力モードの状態は、一時的な状態“Initialization”に遷移る。出力モードセレクションの状態は、一時的に“Initialization state”に遷移した後、invalid stateに遷移する。
Output Mode Selectionの状態は、再生開始(Start Presentation)がアクティブになる
まで、Invalidに維持される。HDMVモードにおいて“Start Presentation”は、プレイリ
ストの再生が開始されたことを意味する。BD-JモードにおいてStart Presentation”は、BD-Jタイトルの再生が開始され、BD-Jアプリケーションが何等かの動作を開始したことを意味する。必ずしも、プレイリストの再生が開始されたことを意味するとは限らない。
Start Presentationがアクティブになった際、出力モードは、一時的な状態である“Procedure when playback condition is changed”に遷移する。
出力モードは、Procedure when playback condition is changedの結果に従ってValid
に遷移する。出力モードが有効であって、Start Presentationが終了すれば、状態はInvalidに遷移する。
ムービーオブジェクトにおけるナビゲーションコマンドは、コンテンツプロバイダが出力モードプリレファレンスに設定するために、プレイリスト再生の開始に先立ち、実行さ
れねばならない。ムービーオブジェクトにおけるナビゲーションコマンドが実行された際、このモデルでは、Invalidになる。
図７１は、Initializationの処理手順を示す。
ステップＳ５０１は、ディスクアンバウンドのBD-Jアプリケーションが動作中かどうかの判定であり、ステップＳ５０２は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、Index.bdmvにおけるInitial＿output＿mode情報が“立体視出
力モード”を示すかどうかの判定である。
ステップＳ５０１がYesであれば、ステップＳ５０３においてカレントの出力モードを
維持する。ステップＳ５０１がNo、ステップＳ５０２がYesであれば、ステップＳ４にお
いてPSR22を立体視出力モードに設定する。ステップＳ５０１がNo、ステップＳ５０２がNoであればステップＳ５においてPSR22における出力モードを、2D出力モードに設定する。
図７２は、Procedure when playback condition is changedの処理手順を示す。ステップＳ５１１は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、
ステップＳ５１３は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、尚且つ、プレイリストに拡張ストリーム選択テーブルが存在するかどうかの判定である。
ステップＳ５１１がYesであればステップＳ５１２において、カレント出力モードを変
化させない。ステップＳ５１１がNo、ステップＳ５１３がYesであってもカレント出力モ
ードを変化させない(ステップＳ５１２)。ステップＳ５１１がNo、ステップＳ５１３がNoであればカレント出力モードを2D出力モードに変化させる(ステップＳ５１４)。
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで
規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選
択の手順は、“ストリーム選択プロシージャ”と呼ばれる。
以下、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインについて説明する。3D再生モードの実現のために用いられているレジスタは、２１番、２２番、２３番、２４番のレジスタであり、これらのレジスタにおけるビットアサインを示したのが図７３である。図７３は、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。
同図（ａ）は、PSR21のビットアサインを示す。本図において、最下位ビットb0が、出
力モードプリレファレンスであり、0bに設定されることで、2D出力モードである旨を示し、1bに設定されることで、立体視出力モードである旨を示す。ナビゲーションコマンドやBD-JアプリケーションはこのPSR21の値を書き換えることはできない。
同図（ｂ）は、PSR22のビットアサインを示す。
PSR22におけるb0は、カレントの出力モードを表す。出力モードが変化すれば、再生装
置におけるビデオ出力は、対応して変化しなければならない。出力モードの値は、選択モデルによって制御されねばならない。
同図（ｃ）は、PSR23のビットアサインを示す。本図に示すようにPSR23におけるb0は、接続されたTVシステムにおける立体視表示ケーパビリティを示す。具体的には、“０”に
設定されることで、接続されたTVシステムが、立体視再生インケーパブルである旨を示し、“１”に設定されることで、立体視再生ケーパブルであるかを示す。
表示装置とネゴシエーションを行う何等かのインターフェイスが再生装置においてサポートされている場合、再生が開始する前に、これらの値は自動的に設定される。これらの値が自動的に設定されない場合、ユーザによって設定される。
同図（ｄ）は、PSR24のビットアサインを示す。本図に示すようにPSR24におけるb0は、再生装置おける立体視表示ケーパビリティを示す。立体視表示ケーパビリティは、０に設定されることで、立体視再生タイプがインケーパブルである旨を示し、１に設定されることで、ケーパブルであるかを示す。
以上のように本実施形態によれば、再生装置の状態変化やユーザからのストリーム切り替え要求があったとしても、出力モードの有効性を保つことができる。
(第８実施形態)
第１実施形態では、サブビュービデオストリームのメタデータに、オフセット制御を規定する情報を組み込んだが、本実施形態では、グラフィクスストリーム内のメタデータに、オフセット制御を規定する制御情報を組み込む。オフセット制御のための制御情報は、グラフィクスプレーンにおける水平座標の右方向及び左方向にオフセットを与えて、メインビューを構成するピクチャデータが描画されるメインビュービデオプレーン及びサブビューを構成するピクチャデータが描画されるサブビュービデオプレーンと合成する。
以降、シフト制御のためのパラメータと、このパラメータを補間するためのデータとについて説明する。
図７４は、マクロブロックの奥行きと、シフト制御のためのパラメータとの関係を示す。
図２のL画像、R画像を表すピクチャデータは、同図（ａ）のマクロブロック、同図（ｂ）のマクロブロックから構成されているものとする。これらの本図における四角枠が、一個のマクロブロックを表す。そして、ハッチングが付されたマクロブロックは、Ｌ画像、Ｒ画像を構成するマクロブロックのうち、立体物が占有しているものを示す。
同図（ｃ）は、上記、Ｌ画像、Ｒ画像から得られる立体物であり、図２に示したものと同じである。図（ｄ）は、図（ａ）（ｂ）のマクロブロックによって現された立体物である。図（ａ）（ｂ）のマクロブロックは、Ｌ画像と、Ｒ画像との間の相関性に基づく奥行きをもつので、この奥行きに従い、マクロブロックをZ軸方向に配置すれば、図（ｄ）の
ようになる。これらのマクロブロックは、立体物である恐竜の頭、胴体、手足、尻尾の奥行きをもつので、図（ｅ）のように、シフト制御に用いるべき奥行きを規定する。つまり、立体視に対応するマクロブロックがもつ奥行きに対して、Z軸方向においてαだけ偏位
した位置を、シフト制御で用いるべき奥行きとする。こうすることで、恐竜の頭部の手前でグラフィクスを表示するための奥行き、胴体の手前でグラフィクスを表示するための奥行き、手足の手前でグラフィクスを表示するための奥行き、尻尾の手前でグラフィクスを表示するための奥行きを規定することができる。
これら4つの奥行きを4つのオフセットシーケンスとして定義すれば、1plane＋Offsetモードにおいて、グラフィクスを表示させるための奥行きとして、恐竜の頭、胴体、手足、尻尾の何れかを適切に選択することができる。
MPEG4-MVCの符号化では、Ｌ画像、Ｒ画像の相関性を用いて符号化がなされるので、Ｌ
画像を構成するマクロブロックと、Ｒ画像を構成するマクロブロックとの動きベクトルが
生成される。この動きベクトルを用いれば、マクロブロック毎の奥行きを検出することができ、このマクロブロック毎の奥行きから、マクロブロックのそれぞれに対応したシフト制御パラメータを得ることができる。
かかるオフセットシーケンスの生成は、ビデオストリームのエンコードと並行して、オフセットシーケンスの定義手順を実行することでなされる。図７５は、ビデオストリームのエンコードとパラレルに実行される、オフセットシーケンスの定義手順を示すフローチャートである。
ステップS１１０はGOPのエンコードが開始されたかどうかの判定であり、開始されれば、ステップS１１１において、GOPにおける先頭ビデオアクセスユニットの先頭のMVCスケ
ーラブルネスティングSEIメッセージに、先頭ビデオアクセスユニットのピクチャ中の移
動体の個々のマクロブロックに対応するオフセットシーケンスを生成する。これは、X軸
方向のシフト幅、Z軸方向のシフト方向といった1plane＋Offsetモードのための制御パラ
メータを、先頭ビデオアクセスユニットのピクチャデータを構成する個々のマクロブロックに対応して生成するためである。
ステップS１１２は、GOPに属するＬ画像、Ｒ画像のエンコードがなされる度に、画面中の移動体の動きベクトルがマクロブロック単位で算出されたかどうかの判定である。動きベクトルが算出されれば、奥行き情報を算出する。本実施形態では、奥行き情報を、ステップS１１３において、マクロブロック毎の動きベクトルの水平方向のスカラ値をシフト
幅に変換し、マクロブロック毎の動きベクトルの移動方向の水平成分をシフト方向に変換するという簡易な処理で算出する。こうすることで、フレーム期間毎のシフト幅、シフト方向のおおよその値を求める。
ステップS１１４において、フレーム期間のマクロブロック毎に得られたシフト幅に、Z軸方向の偏位量を加算する。これは、上記変換の元となる水平方向のスカラ値は、マクロブロックに対応する立体物の奥行きのそのものの奥行きを示しているので、かかる偏位量を加算しておくことで、立体物のやや手前の奥行きを1plane＋Offsetモードにおけるシフト幅として明示するするためである。
ステップS１１５において、偏位量が加算された各フレームのマクロブロック毎のシフ
ト幅と、シフト方向とを新たなPlane＿offset＿direction、Plane＿offset＿valueとして、各オフセットシーケンスに追記する。
ステップS１１６は、ビデオストリームにおけるGOPのエンコードが継続しているかどうかの判定であり、継続していればステップＳ１１２に戻る。エンコードが継続している限り、上記オフセットシーケンスへのPlane＿offset＿direction、Plane＿offset＿valueの追加が継続することになる。
GOPのエンコードが終了すれば、そのGOPに対するビデオアクセスユニットにおけるオフセットメタデータの生成を終え、ステップS１１０に戻る。
尚、3Dカメラの撮影の際、また、ベースビュービデオストリーム及びディペンデントビュービデオストリームのエンコードの際、これらマクロブロック毎のシフト幅、シフト方向をGOP毎にデータベース化しておき、このシフト幅、シフト方向に適切な変換を施して
、GOP先頭にあたるアクセスユニット内のMVCスケーラブルネスティングSEIメッセージに
格納すれば、複数の奥行きを定義するような複数のオフセットシーケンスを定義することができる。尚、MPEG4-MVCのコーディックを3Dカメラが具備している場合、3Dカメラにお
いて、上記オフセットシーケンスの定義を実行すべきである。
以上が、1plane＋Offsetモードにおけるシフト制御のパラメータの作り方である。次に、こうした過程で生成された制御パラメータを補間する補間パラメータについて説明する。このような補間パラメータは、字幕ストリームの内部のメタデータに存在する。

図７６は、字幕ストリームにおけるウィンドゥ定義セグメント、制御情報を示す図である。
『ウィンドゥ定義セグメント』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンに
おけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は"window"と呼ばれ、このWDSで定義される。図７６（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window＿id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window＿horizontal＿position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window＿vertical＿position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window＿width』と、グラフィックスプレーンにおける縦幅を示す『window＿height』とを用いて表現され
る。
window＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプ
レーンの内部領域であり、このグラフィックスプレーンの内部領域においてウィンドゥは、縦:video＿height、横:video＿widthという二次元状の大きさをもつ。
window＿horizontal＿positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0〜video＿width-1の値をとり、window＿vertical＿positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0〜video＿height-1の値をと
る。
window＿widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0〜video＿width-window＿horizontal＿position-1の値をとり、window＿heightは、グラフィックスプレーンにおける縦幅であるので0〜video＿height-window＿vertical＿position-1の値をとる。
WDSのwindow＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightにより、グラフィックプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャーが表示されている期間において、ピクチャー内の絵柄の邪魔にならないように、ピクチャー上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャーの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
図７６（ｂ）は1Plane+offset用にフィールドを追加したPCS(Presentation Composition Segment)の構造を示している。
本図に示すようにPCSは、『segment＿type』と、『segment＿length』と、『composition＿number』と、『composition＿state』と、『pallet＿update＿flag』と、『pallet＿id＿ref
』と、『number＿of＿composition＿object』to,『composition＿object(1)〜(m)』とから構
成される。
『composition＿number』は、0から65535までの数値を用いてDisplay Setにおけるグラ
フィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition＿numberは設定される。
『composition＿state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、Acquisition Pointであるか、Epoch Startであるかを示す。
『pallet＿update＿flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに
切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれ
ば、本フィールドは"1"に設定される。
以降の『3d＿graphics＿offset＿direction』、『3d＿graphics＿offset』は、グラフィクスストリームにおけるメタデータである。
『3d＿graphics＿offset＿direction』は左右のどちらにOffset分ずらすかの方向を決めるためのフィールドである。
『3d＿graphics＿offset』は、左右の方向に具体的にどれだけ動かすかを決めるためにフィールドである。
『pallet＿id＿ref』は、PalletOnly Displey Updateに用いられるべきパレットを示す。
『composition＿object(1)・・・(n)』は、このPCSが属するDisplay Set内で表示すべきObjcetをどのように制御するかを示す情報である。同図の破線co1は、任意のcomposition＿object(i)の内部構成をクローズアップしている。この破線co1に示すように、composition＿object (i)は、『object＿id＿ref』、『window＿id＿ref』、『object＿cropped＿flag』、『forced＿on＿flag』、『object＿horizontal＿position』、『object＿vertical＿position』、『cropping＿rectangle情報(1)(2)・・・・・(n)』からなる。
『object＿id＿ref』は、composition＿object (i)に対応する参照すべきODSの識別子を示す。
『window＿id＿ref』は、本PCSにおいて、グラフィクスオブジェクトに割り当てられるべきウィンドゥを示す。1つのウィンドゥには最大2つのグラフィクスオブジェクトが割り当てられる。
『object＿cropped＿flag』は、オブジェクトバッファにおいてクロップされたグラフィ
クスオブジェクトを表示するか、クロップしないグラフィクスオブジェクト表示するかを切り換えるフラグである。"1"と設定された場合、オブジェクトバッファにおいてクロッ
プされたグラフィクスオブジェクトが表示され、"0"と設定された場合、グラフィクスオ
ブジェクトはクロップされることなく表示される。『forced＿on＿flag』は、プレーヤーの設定で字幕がOFFになっている際でも強制的に表示されるべき字幕を示すグラフィクスオ
ブジェクトの場合に1になる。
『object＿horizontal＿position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object＿vertical＿position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping＿rectangle情報(1)(2)・・・・・(n)』は、『object＿cropped＿flag』が1に
設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping＿rectangl
e情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping＿rectangle情報(i)は、『object＿cropping＿horizontal＿position』、『object＿cropping＿vertical＿address』、『object＿cropping＿width』、『object＿cropping＿height』からなる。
『object＿cropping＿horizontal＿position』は、グラフィックスプレーンにおけるクロ
ップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における"Region"に相当する。
『object＿cropping＿vertical＿address』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
『object＿cropping＿width』は、グラフィックスプレーンにおけるクロップ矩形の横幅
を示す。
『object＿cropping＿height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。
3d＿graphics＿offsetで示される単位は、画面上の1画素(ピクセル)単位で左右にずらす
量として定義してもよいし、3d＿graphics＿offsetを定義するビット数を節約するために、例えば2画素(ピクセル)単位で動かす量としても良い。
例えば、3d＿graphics＿offset＿directionが1ビットのフィールドとして構成され、0の時に字幕がディスプレイから手前に飛び出る方向（つまりGraphics Planeを左目用Video Planeに重ねる場合には、右方向にOffset分ずらしてGraphics Planeを重畳）にOffsetを与
え、1の場合には画面から奥行き方向にへこむ方向にOffsetを与えるようにする。また、3d＿graphics＿offsetが6ビットあるとすると、左右のVideo Planeに対して重畳するOffset
は、左右方向に各64ピクセル(Offsetが1画素単位での移動量を示す場合) 動かすことができる。
この時、左右方向に64ピクセルで十分な３Ｄ字幕（飛び出し）が得られないので、このフィールドの値は、ディペンデントビューストリームにおけるオフセットシーケンスとの補間値として用いる。具体的にいうと、composition＿object内のオフセットは、ディペンデントビューストリーム内のオフセットシーケンスと組合せて用いられる補間値であり、描画領域における字幕を表示するにあたって、ディペンデントビューストリームのオフセットシーケンスに示されるオフセットをどの程度補間すればよいかという補間値を示す。
次に個々のPCSをどのように記述するかについて説明する。Display Setに属するWDS、PCSの記述例を図７７（ａ）〜（ｃ）に示す。図７７は、DS1におけるPCSの記述例を示す図である。
図７７（ａ）において、WDSのwindow＿horizontal＿position、window＿vertical＿positionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、window＿width,window＿heightは、ウィンドゥの表示枠の横幅、縦幅を示す。
図７７（ａ）におけるクロップ情報のobject＿cropping＿horizontal＿position,object＿cropping＿vertical＿positionは、オブジェクトバッファにおけるグラフィクスオブジェク
トの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして
基準点からobject＿cropping＿width、object＿cropping＿heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィッ
クスプレーンの座標系においてobject＿horizontal＿position、object＿vertical＿position
を基準点(左上)とした破線の範囲cp1に配置される。こうすることにより、『本当は』が
グラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
図７７（ｂ）は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は
、（ａ）と同じなので説明を省略する。クロップ情報の記述は、（ａ）と異なる。図７７（ｂ）におけるクロップ情報のobject＿cropping＿horizontal＿position、object＿cropping＿vertical＿positionは、オブジェクトバッファ上の字幕『本当はウソだった。あなたが』のうち、『ウソだった』の左上座標を示し、object＿cropping＿height、object＿cropping＿widthは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』が
グラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
図７７（ｃ）は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は
、図７７（ａ）と同じなので説明を省略する。クロップ情報の記述は、図７７（ａ）と異なる。図７７（ｃ）におけるクロップ情報のobject＿cropping＿horizontal＿position、object＿cropping＿vertical＿position,は、オブジェクトバッファ上の字幕『本当はウソだっ
た。あなたが』のうち、『あなたが』の左上座標を示し、object＿cropping＿height、object＿cropping＿widthは、『あなたが』の横幅、縦幅を示す。こうすることにより、『あな
たが』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。
DS1,2,3のPCSを以上のように記述することで、字幕の表示効果を実現することができる。
図７８は、composition＿object内の3d＿graphics＿offsetを用いた補間を施す場合と、補間を施さない場合とで、オフセットが時間的にどのように変化するかを示す。実線は、composition＿object内の3d＿graphics＿offsetを用いて補間を施した場合におけるオフセットの時間的変化を示し、破線は、composition＿object内の3d＿graphics＿offsetを用いた補間を施さない場合におけるオフセットの時間的変化を示す。
グラフィクスプレーンにおいて描画領域が2つあり、これらのうち、1つ目の領域に台詞を表示し、2つ目の領域に、監督のコメンタリを表示させたい場合がある。そして、コメ
ンタリについては、台詞よりも奥手に配置して、字幕の立体感を出したいような場合、2
つ目の領域について、補間値を設定すれば、コメンタリの奥行きを深くすることができる。
プレーンシフトはライン単位になされるので、1つのラインに複数の描画領域を定義で
きないようなルールを設けるか、または、1つのラインに複数の描画ラインを設ける場合
、オフセットの値を同じ値に設定するというルールを設けるべきである。

（第９実施形態）
本実施形態は、ビデオオフセット情報が、画面を分割することで得られたそれぞれの領域のオフセット値を持つという改良に関する。
図７９は、画面の分割領域毎のオフセットから構成されるオフセットシーケンスを示す。同図左は、９個のオフセットから構成されるオフセットシーケンスである。同図右は、オフセットシーケンスにおける個々のオフセットが、９分割された画面のうち、どの部分に該当するかを示す。Offset＿１は左上、Offset＿２は左、Offset＿３は左下、Offset＿４は上、Offset＿５は中心、Offset＿６は下、Offset＿７は右上、Offset＿８は右、Offset＿９は
右下の領域のオフセット値を表す。これらのOffset値はビデオストリームの各フレームのビデオの奥行き情報から決定される。
図８０は、画面内の物体の奥行きと、オフセットとの関係を示す。同図の左側は、ピクチャデータの一例を示し、右側は、９分割のオフセットシーケンスを示す。左側において、円形の物体は奥に引っ込んでおり、三角の物体は前に飛び出ているものとする。
この場合、円形の物体が含まれる領域に対応するオフセット１は、その値は小さい。
三角の物体が含まれる領域に対応するオフセット５、６、８、９は、その値が大きく設定されている。このようにオフセット情報は、各フレームごとのシーンに含まれる物体の奥行きを元に作成される。
次に、３D再生装置について説明する。３D再生装置の構成の基本部分は、これまでの実施の形態で説明した３D映像を再生する３D再生装置と同じであるため、拡張または異なる部分を中心に説明する。
図８１は、再生装置のうち、ビデオデコーダ、ベースビュービデオプレーン、ディペンデントビュービデオプレーン、PG/IGプレーンを示す。
まず、３D映像ビデオデコーダは、２D/左目映像プレーンにPTSのタイミングでフレームの復号画像を書き出すと同じタイミングで、そのフレームに含まれるビデオオフセット情報をプレーン合成部に通知する。
また、ビデオオフセット情報の９分割の領域のオフセットの中で、どのオフセットの最大値をプレーンずらしに使うかを示すための情報が、プレーヤ変数のうち、SPRM（２５）に格納される。SPRM（２５）は、Offset＿１， Offset＿２， Offset＿３， Offset＿４，
Offset＿５， Offset＿６， Offset＿７， Offset＿８， Offset＿９のうち、どの値が
最大値であるかを示す。
SPRM（２５）は、BDプログラムファイルのプログラムを実行時にコマンドやAPIなどで
セットされる。SPRM（２５）は例えば９ビットの情報があり、それぞれの１ビットが各オフセット値が有効/無効を示す。
プレーン合成部は、３D映像ビデオデコーダから転送されるビデオオフセット情報とSPRM（２５）の値から利用するオフセット値の最大値をとることでプレーンをずらす値を決
め、プレーンずらし&クロッピング処理を行ってプレーンメモリとの重畳を行う。
同図の例では各オフセットの値が、Offset＿１=-３， Offset＿２=-３， Offset＿３=-
１， Offset＿４=-２， Offset＿５=３， Offset＿６=５， Offset＿７=１， Offset＿８=４， Offset＿９=５となっている。SPRM（２５）には、Offset＿１とOffst＿４とOffset＿
７が有効で、これらの最大値をプレーンずらしに使うように設定されている。
シフト部は、ビデオオフセット情報の中から、SPRM（２５）で有効とされるOffset＿１
とOffset＿４とOffset＿７の中から最大値を計算して（この場合はMAX（-３，-２，１）=１）、プレーンずらし&クロッピング処理を実行し、映像プレーンとの重畳を行う。
このような構成にすることによりビデオストリームの中にビデオオフセット情報を入れることにより、３D再生装置が持つメモリサイズを削減できる。
＜オフセットの適用＞
SPRM（２５）には、有効な９分割のオフセット値を指し示す情報だけでなく、ベースのオフセット値を格納しても良い。そして、プレーン合成部は、９分割内の有効なオフセッ
ト値の最大値を出した後に、そのベースのオフセット値を加算しても良い。例えば、９分割内の有効なオフセット値が３で、ベースのオフセット値が２であれば、プレーンをずらすオフセット値を３+２の５としても良い。
＜ウィンドゥの適用＞
本実施の形態では、SPRM（２５）を使って、９分割の内の有効なオフセット値を決めるとしたが、グラフィックスプレーンに含まれるグラフィックスの矩形領域を元に有効なオフセット値を決めるてもよい。
図８２は、グラフィクスプレーンの内容と、オフセットとの関連性を示す。
例えば、表示すべきグラフィックスのグラフィックスイメージが、同図下段の円形であれば、有効なオフセット値は、Offset＿５＆Offset＿６＆Offset＿８＆Offset＿９となる。これはIG/PGなどのグラフィクスだけでなく、クローズドキャプションなどの情報を３D再生する場合も同じである。
＜オフセット情報の位置＞
ビデオオフセット情報は、フレームごとに格納されるのではなく、GOP先頭のみに格納
されるとしても良い。また、GOP先頭のアクセスユニットにGOPに含まれるフレーム分のビデオオフセット情報が格納されていても良い。
なお、ビデオオフセット情報は、ビデオエンコード時に左目画像と右目画像の動きベクトルの違いから算出しても良い。
＜変更＞
ビデオオフセット情報は、各フレームごとのシーンに含まれる物体の奥行きから算出する場合には、奥行き情報が奥行きが激しく変化する場合に、グラフィックスの奥行き間も激しく変化してしまうため、フレーム間でローパスフィルタを通すようにして値を設定しても良い。
＜プレーンメモリ毎の適用＞
本実施の形態では、ビデオオフセット情報を、ビデオの画面を９分割した値でセットしたが、プレーンごとのオフセット値を持つとしても良い。この場合、プレーン合成部はプレーンに応じて、オフセット値を変えて、プレーンずらし&クロッピングを行う。
＜格納位置＞
本実施の形態では２D/左目映像ビデオストリームにオフセット値を格納するとして説明したが、右目映像ビデオストリームの方に格納していてもよいのはいうまでもない。

(第１０実施形態)
本実施形態では、Ｌ画像、Ｒ画像を用いて立体視効果を実現する3D-LR方式の他、2D画
像と、深度情報とを用いて立体視効果を実現する3D-Depth方式を導入する。
3D-Depth方式とは、ビデオデコーダの後段に、視差映像生成器を組み入れて、ビデオストリームにおける個々のピクチャデータと、このピクチャデータにおける個々の画素の深度情報とからレフトビューピクチャデータ、ライトビューピクチャデータを作り出させるモードである。
この深度情報は、画素の深度を濃淡で表すグレースケールのピクチャデータ(深度情報
ピクチャデータと呼ばれる)として構成することができる。
図８３は、デプスビュー方式の一例を示す。同図（ａ）は、2D画像であり、同図（ｂ）は、（ａ）に示した2Dに対して作成されたグレースケールを示す。グレースケールは、輝
度成分のみの画素によって表現される。グレースケールの画素のうち、輝度が高いもの程(白いもの程)、奥行きが浅く、輝度が低いもの程(黒いもの程)、奥行きが深いことを示す。同図（ｃ）、（ｄ）は、グレースケールを用いることで生成される左目映像、右目映像を示す。図８４は、3D-Depthモードで生成される立体視画像を示す。2Dの各フレーム毎に、左目映像、右目映像を生成すれば、ゴーグルを通じて左目映像、右目映像を見ることで、ユーザは立体視を楽しむことができる。
3D-Depth方式では、2D再生可能なビデオストリームがベースビュービデオストリームになる。グレースケールのピクチャデータから構成されるビデオストリームが、ディペンデントビュービデオストリームになる。
3D-Depthモードと、3D-LRモードとでは、ベースビュービデオストリームは共通化する
ことができるため、ベースビュービデオストリームに組合せるべきビデオストリームを変化させれば、3D-LRモード、3D-Depthモードの映像を生成することができる。データ管理
構造からこれらの組み合わせを扱い、プレーヤおよび接続されているテレビ側の特性に合わせて、表示方法を切り替える。3D-Depthモードは、再生装置に専用のハードウェアが必要であるので、特に断らない限り、本明細書で述べる記録媒体、再生装置は、3D-Depthモードに対応しないものとする。
図８５は、3D-Depthモードを実現するための記録媒体の構成例を示す。同図（ａ）は、3D-Depthモードに対応したディレクトリとファイルを示す。
3D再生用のベースビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、BASEサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
3D再生用LR形式のディペンデントビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、LRサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
3D再生用Depth形式のベースビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、DEPTHサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
同様に、LR形式で再生する際に必要なストリームファイルのストリーム管理情報は、CLIPINFディレクトリ以下に、LRサブディレクトリを作成して格納し、2D再生用の管理と区
別する。
Depth形式で再生する際に必要なストリームファイルのストリーム管理情報は、CLIPINFディレクトリ以下に、DEPTHサブディレクトリを作成して格納し、2D再生用の管理と区別
する。ファイルの形式により、拡張子も変化させる。
１つのストリームファイルだけで再生できるファイルは、2D再生用のストリームファイルと同じ拡張子を利用する。
ベースビュービデオストリームを含まず、単体では再生できず（ビデオをデコードできず）、ベースビュービデオストリームを含むストリームファイルとともに再生しなければデコードできないファイルは“.３dts”などと拡張子を分けて区別する。
ベースビュービデオストリームとディペンデントビュービデオストリームがインタリーブ配置されており、単純にファイル先頭から連続に読み込んでも再生できない形式のファイルは、.ilts（interleaved TS）などと拡張子を分けて区別する。
同図（ｂ）は、3D-Depthモードに対応するための拡張ストリーム選択テーブルのシンタックスを示している。同図（ｂ）のシンタックスでは、stream＿entry()に、type=4とい
う類型が追加されている。type=4の場合は、3D用のファイルを指定するref＿to＿stream
＿PID＿of＿3DClipを含む。
LR＿dependent＿view＿ES＿availability、LR＿interleaved＿file＿availability、Depth＿dependent＿view＿ES＿availability、Depth＿interleaved＿file＿availabilityは、Out-of-MUXを利用したディペンデントビュービデオストリームを供給する場合、インターリーブ形式のファイルは不要となることを示すフラグである。
3D＿base＿view＿block()は、必ず存在するブロックであり、2D用と3D用とで参照する
エクステントが異なる場合は、type=4のストリームエントリーにより、STREAM/BASE/xxxxx.m2tsを参照する。
2D用と、3D用とで参照するエクステントが同一である場合、或は1TSの場合は、type=1
のストリームエントリーにより、STREAM/xxxxx.m2tsを参照する。
LR＿dependent＿view＿ES＿availabilityがオンに設定されている場合、type=4のスト
リームエントリーを用いてSTREAM/LR/xxxxx.3dtsを指定する。LRインタリーブファイルを利用する場合は、STREAM/LR/xxxxx.iltsを指定する。
Depth＿dependent＿view＿ES＿availabilityがオンに設定されており、2D用と3D用とで参照するエクステントが異なる場合、type=4のストリームエントリーを用いてSTREAM/DEPTH/xxxxx.3dtsを指定する。Depthインタリーブファイルを利用する場合は、STREAM/DEPTH/xxxxx.iltsを指定する。
図８６は、プレイアイテムと、ストリームとの対応関係を示す。同図の左側の第１列は、図８５（ｂ）によって記述された拡張ストリーム選択テーブルを含むプレイアイテムであり、その隣の第２列は、図８５（ａ）のストリームファイル内のTSである。第３列は、様々なタイプの再生装置を示し、第４列は、その再生装置によって参照されるクリップ情報ファイルを示す。
図中の左側のプレイアイテムの中には、クリップ情報ファイルネーム(clip＿file＿name)、ストリーム選択テーブル(STN＿table)、3D-Depth方式に対応することができる拡張スト
リーム選択テーブル(STN＿table＿extention)が存在する。ストリーム選択テーブル、拡張
ストリーム選択テーブルの中の小枠は、ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録情報のストリームエントリーが、どのような類型であるかを示す。ストリーム選択テーブルにおけるストリームエントリーの類型はType＝１になっている。
対照的に、拡張ストリーム選択テーブルにおけるベースビュービデオストリームのストリームエントリー(Base view stream)、3D-LR形式のディペンデントビュービデオストリ
ームのストリームエントリー(LR dependent view stream)、3D-LR形式の立体視インター
リーブドストリームのストリームエントリー(LR interleaved stream)、3D-Depth形式の
ディペンデントビュービデオストリームのストリームエントリー(Depth dependent view stream)、3D-Depth形式の立体視インターリーブドストリームのストリームエントリー(Depth interleaved stream)は、何れもType=4になっている。
第２列における一番上の段は、立体視インターリーブドストリームファイル(00001.ssif)の内部構成を示す。枠内の“Ｄ”,“Ｒ”,“Ｌ”,“Ｌ2D”のうち、“Ｄ”は、Depth形
式ベースビュービデオストリームのエクステント、“Ｒ”は、ライトビュービデオストリームのエクステント、“Ｌ”は、レフトビュービデオストリームのエクステント、“Ｌ2D”は、レフトビュービデオストリームのエクステントのうち、2D再生用のものを示す。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/00001.m2tsの
ファイルパスでストリームファイルが、2Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｌ”,“Ｌ2D”が2D
プレーヤによって参照される。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/BASE/00001.m2tsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによっ
て参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｌ”,“Ｌ3D”が3Dプレーヤによって参照される。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/LR/00001.3dtsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによって
参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｒ”,“Ｒ”,“Ｒ”が3Dプレーヤによって参照される。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/LR/00001.iltsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによって
参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｒ”,“Ｌ”,“Ｒ”,“Ｌ3D”が3Dプレーヤによって参照される。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/DEPTH/00001.3dtsのファイルパスでストリームファイルが、3D-Depthモードで再生を行う3Dプレーヤに
よって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｄ”,“Ｄ”,“Ｄ”が3Dプレーヤによって参照される。
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/DEPTH/00001.iltsのファイルパスでストリームファイルが、3D-Depthモードで再生を行う3Dプレーヤに
よって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｄ”,“Ｌ”,“Ｄ”,“Ｌ3D”“Ｌ”が3Dプレーヤによって参照される。
第４列によると、CLIPINF/00001.clpiは、2Dプレーヤ、3D-LR再生を行う3Dプレーヤ、Depth再生を行う3Dプレーヤによって参照されていることがわかる。CLIPINF/LR/00001.clpiは、3D-LR再生を行う3Dプレーヤによって参照されていることがわかる。CLIPINF/DEPTH/00001.clpiは、Depth再生を行う3Dプレーヤによって参照されていることがわかる。
以上のように、ストリームエントリーがtype=4である場合、再生する3Dタイプ（LR形式、Depth形式）と、プレーヤの対応ファイル形式（base/dependent別ファイル形式、1ファイル形式）より、読み込むべきストリームファイルを判定する。
2D用ストリームファイルと、3D用ストリームファイルとで同一エクステントのクロスリンクを実現している場合、ベースビューストリームのtype=1のストリームエントリーに設定することにより、2D用ストリームファイルと同一のストリームファイルを参照することができる。1TSに多重化する場合、ベースビュービデオストリーム、ディペンデントビュ
ーストリームのストリームタイプをいずれもtype=1のストリームエントリーとして、2D用ストリームファイルとおなじファイルを参照することができる。
(第１１実施形態）
本実施の形態では、本発明にかかる３D再生装置に必要なビデオの復号化に必要なバッ
ファサイズを削減するためのデータ構造および３D再生装置について説明する。
先の実施形態に示したように、３D映像ビデオデコーダは、２D/レフトビュービデオス
トリームの符号化状態によるビデオアクセスユニットが格納されるバッファとしてEB(1)
、ライトビュービデオストリームの符号化状態によるビデオアクセスユニットが格納されるバッファとしてEB(2）を持つ。
このバッファサイズは、MPEG-４ AVC規格においてはCPBにあたり、所定の規格に応じ
て設定されるが、一般的にはビットレートの大きさに応じて設定される値である。ビットレートが大きくなれば必要なバッファサイズも多く必要であり、ビットレートが小さくなれば必要なバッファサイズも少なくてよい。ここでいうビットレートはMBからEBへの転送レートであり、MPEG-４ AVC規格でいえば、HRDパラメタータに格納されるBitRateを意味する。
例えば、２D/レフトビュービデオストリームのビットレートが４０Mbpsの場合に必要なバッファサイズが４MBであるとすれば、同じ符号化方式で符号化されたビットストリームにおいては、３０Mbpsに必要なバッファサイズは４MB×３０Mbps/４０Mbps=３MBになる。
ここで、２D/レフトビュービデオストリームとライトビュービデオストリームの合計のビットレートは、ドライブからの転送レートなどから固定値として規定される。ここではビデオストリームの合計のビットレートは６０Mbpsであるとする。
この場合、合計のビットレートが６０Mbpsとすると、２D/レフトビュービデオストリームのビットレートが４０Mbpsであれば、ライトビュービデオストリームのビットレートは２０Mbpsとなる。また、２D/レフトビュービデオストリームのビットレートが３０Mbpsであれば、ライトビュービデオストリームのビットレートは３０Mbpsとなる。
この場合、ビットレートの最大値を考えてみると、２D/レフトビュービデオストリームの最大ビットレートは４０Mbps、ライトビュービデオストリームの最大ビットレートは３０Mbpsとなる。各ビットレートの最大値からEBのサイズを定義すると、２D/レフトビュービデオストリーム用のEB(1)は４MB×４０Mbps/４０Mbps=４MB、ライトビュービデオスト
リーム用のEB(2）は４MB×３０Mbps/４０Mbps=３MBとなる。このように定義すれば、３D
再生装置が、４MB+３MB=７MBのバッファを格納し、各ビデオストリームがここで定義されるバッファサイズでアンダーフローやオーバーフローしないように作成されていれば、３D映像の再生を保証できることになる。
しかし、２D/レフトビュービデオストリームとライトビュービデオストリームのビットレートの合計は６０Mbpsであるため、２D/レフトビュービデオストリームの最大ビットレート=４０Mbpsとライトビュービデオストリームの最大ビットレート=３０Mbpsの組み合わせは存在しない。そのため、３D再生装置のためにそれぞれのビットレートの最大値から
バッファサイズを決定した場合（４MB+３MB）には、必要以上に大きなバッファサイズを
つむことになってしまう。
そこで、３D再生装置が、必要最低限のEB(1)、EB(2）のバッファサイズを積むためのデータ構造および３D再生装置について説明する。
まず、データ構造について説明する。
データ構造の基本部分は、これまでの実施の形態で説明した３D映像を格納するための
データ構造と同じであるため、拡張または異なる部分を中心に説明する。
本実施の形態におけるデータ構造は、プレイアイテムの構造が図８７に示す構造になっていおり、EB(1)サイズとEB(2）サイズのフィールドが追加されている点が異なる。 図
８７は、エレメンタリバッファのサイズ情報を含むプレイアイテム情報を示す。
EB(1)サイズは、プレイアイテムから参照される２D/レフトビュービデオストリームを
デコードするために必要なEB(1)のサイズ情報が格納される。
EB(2）サイズは、上記プレイアイテムと同時に再生されるライトビュービデオストリームをデコードするために必要なEB(2）のサイズ情報が格納される。
ここでEB(1)サイズとEB(2）サイズの合計サイズは、２D/レフトビュービデオストリー
ムとライトビュービデオストリームの合計ビットレートから決定される。例えば、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートが６０Mbpsの場合には、４MB×６０Mbps/４０Mbps=６MBとなる。
また、プレイアイテムから参照される２D/レフトビュービデオストリームは、EB(1)サ
イズで定義されるバッファでアンダーフロー、オーバフローしないでデコードできるように作成されており、プレイアイテムと同時に再生されるライトビュービデオストリームは、EB(2)サイズで定義されるバッファでアンダーフロー、オーバフローしないでデコード
できるように作成されている。
次に、３D再生装置について説明する。
３D再生装置の構成の基本部分は、これまでの実施の形態で説明した３D映像を再生する３D再生装置と同じであるため、拡張または異なる部分を中心に説明する。
本実施の形態における３D再生装置は、再生するプレイアイテムに応じて、３D映像ビデオデコーダ内のベースビュー用のEB、ディペンデントビュー用のEBのサイズ（メモリの割り当てサイズ）を変更する点が異なる。
再生制御部は、プレイアイテムの再生を行う前に、プレイアイテムに含まれるEB(1)サ
イズとEB(2）サイズの情報を取得し、システムターゲットデコーダに通知し、システムターゲットデコーダは、３D映像ビデオデコーダのEB(1)とEB(2）のサイズを変更する。再生制御部は、EB(1)と、EB(2）のサイズの変更が完了した後に、該当プレイアイテムの再生
を開始する。
３D再生装置がプレイアイテム＃1を３D映像として再生する場合には、プレイアイテム
＃1から参照される２D/レフトビュービデオストリームと、プレイアイテム＃1と同時に再生されるライトビュービデオストリームを特定して再生処理を行うが、３D再生装置はプ
レイアイテム＃1に含まれるEB(1)サイズとEB(2）サイズより、システムターゲットデコーダ内の映像ビデオデコーダのEB(1)と、EB(2）とのサイズを変更する。この例では、EB(1)サイズを４MB、EB(2）サイズを２MBと設定し、ビデオストリームの再生を行う。プレイアイテム＃2を再生する場合も同様に、３D再生装置はプレイアイテム＃2に含まれるEB(1)サイズとEB(2）サイズより、システムターゲットデコーダ内の映像ビデオデコーダのEB(1)
と、EB(2）のサイズを変更する。この例では、EB(1)サイズを３MB、EB(2）サイズを３MB
と設定し、ビデオストリームの再生を行う。
このような構成にすることにより、３D再生装置に必要なEB(1)とEB(2）のサイズをビデオストリームのビットレートに応じて適宜制御できるため、必要なバッファサイズを、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートから定義することが可能となる。これにより、それぞれのビットレートの最大値で定義したバッファサイズを持つ場合に比べて、必要なEB(1)とEB(2）の合計バッファサイズを削減
することができる。
尚、プレイアイテム間でシームレス接続が行われる場合にバッファサイズが変更されると、プレイアイテム間の遷移で、どちらかのEBのサイズが小さくなると、シームレス接続の保証ができなくなる可能性があるため、これを禁止しても良い。つまり、コネクションコンディションが５、６のプレイアイテムにおいては、EB(1)サイズとEB(2）サイズの値
は設定できない、もしくは無視されるとしてもよい。また、コネクションコンディションが５、６のプレイアイテムにおいては、EB(1)サイズとEB(2）サイズの値は、前のプレイ
アイテムのEB(1)サイズ、EB(2）サイズと同じ値になっていなければならないとしても良
い。
また、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートは固定的に決まるため、EB(1)サイズのフィールドだけが存在し、EB(2）サイズ
は、EBの合計バッファサイズ-EB(1)サイズとして算出できるとしてもよい。
更に、EB(1)サイズとEB(2）サイズのフィールドは、バッファサイズを算出できればよ
い。例えばビデオストリームのビットレートが書いてあり、これから算出しても良いし、EB(1)サイズとEB(2）サイズの組み合わせがテーブルとして定義されていて、そのIDを設
定しても良い。
(第１２実施形態)
本実施形態は、クリップ情報における3Dメタデータに、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームの２Ｄイメージに奥行き情報を追加する改良に関する。
図８８は、奥行き情報が追加された3Dメタデータを示す。3Dメタデータは、同図上段に示すように、AVストリーム内に含まれるプレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームのPID毎に、3D映
像の表示時刻を示すPTSと、ライトビューレフトビューのピクセルのずれを示すオフセッ
ト値が記載されたテーブル情報である。オフセット値はＸ軸方向へのピクセル数であり、マイナス値も許される。ここではテーブルの１つの行で示される対となるPTSとオフセッ
ト値の情報をオフセットエントリと呼ぶことにする。オフセットエントリの有効区間は、該当オフセットエントリのPTSから次のオフセットエントリのPTSまでである。例えば、オフセットエントリ＃１のPTSが１８００００で、オフセットエントリ＃２のPTSが２７００００である場合は、オフセットエントリ＃１のオフセット値は１８００００から２７００００まで有効となる。再生装置のプレーン合成部は、この情報値に基づき、PGプレーン、IGプレーン、副映像プレーンを左右にオフセット値をずらしながらプレーン合成をする。これによって、視差画像をつくり出すことができ、２次元映像に対して立体的な奥行きを付加することができる。
なお、ここでは3DメタデータはPID毎に設定されるとしたが、例えば各プレーンごとに
設定できても良い。これにより2D/3D再生装置の3Dメタデータの解析処理を簡素化できる
。なお、2D/3D再生装置の合成処理の性能を踏まえて、オフセットエントリの間隔に例え
ば１秒以上とするなどのように制約をつけても良い。
ビデオストリーム属性情報について説明する。3D-LRモードにおいては、2D/ベースビュービデオストリームのPIDが0x1011のビデオストリーム属性情報のコーデック、フレーム
レート、アスペクト比、解像度と、対応するライトビューAVストリームのPIDが0x1012の
ビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度は一致しなければならない。また、3D-Depthモードにおいては、2D/ベースビュービデオストリ
ームのPIDが0x1011のビデオストリーム属性情報のコーデック、フレームレート、アスペ
クト比、解像度と、対応するデプスマップAVストリームのPIDが0x1013のビデオストリー
ム属性情報のコーデック、フレームレート、アスペクト比、解像度は一致しなければならない。コーデックが同じでない場合にはビデオストリーム間での参照関係が成り立たず、また、ディスプレイに同期して3D映像として再生するためにはフレームレート、アスペクト比、解像度を一致しなければユーザに違和感を与えてしまうためである。
また、ライトビューAVストリームのビデオストリーム属性情報に、ビデオストリームが2D/ベースビュービデオストリームを参照するビデオストリームであることを示すフラグ
を入れても良い。また、参照先のAVストリームの情報を含めておいても良い。このような構成にすることにより、作成されたデータが規定のフォーマットどおりに作られているかを検証するツールが、ビデオストリームの対応関係を判断することができる。
2D/ベースビュービデオストリームのクリップ情報ファイルには、2D/レフトビュービデオストリームのエントリマップが格納される。2D/レフトビュービデオストリームの各エ
ントリポイントには、2D/レフトビュービデオストリームのGOP先頭のＩピクチャのPTSとSPNが登録される。同様に、ライトビュービデオストリームのクリップ情報ファイルには、ライトビュービデオストリームのエントリマップが格納される。ライトビュービデオストリームの各エントリポイントには、ライトビュービデオストリームのライトビューGOP先
頭のピクチャのPTSとSPNが登録される。
（第１３実施形態）
本実施形態では、前述の実施形態において説明された構造のデータを再生する再生装置に関して、集積回路６０３を用いて実現した構成例について説明する。
媒体IF部６０１は、媒体からデータを受信して（読み出して）、集積回路６０３に転送する。なお媒体IF部６０１は、前述の実施形態において説明した構造のデータを媒体から受信する。媒体IF部６０１は、例えば、媒体が光ディスクやハードディスクの場合はディスクドライブ、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波の場合はCANチューナーやSiチューナー、媒体がイーサネット（登録商標）、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。
メモリ６０２は、媒体から受信した（読み出した）データを一旦格納したり、集積回路６０３における処理途中のデータを一時的に格納するメモリで、例えばSDRAM(Synchronous Dynamic Random Access Memory)、Rx SDRAM(Double-Date-Ratex Synchronous Dynamic Random Access Memory;x=1,2,3・・・)等が用いられる。なおメモリ６０２は、任意の個
数備えていればよく、必要に応じて単数でも複数でも構わない。
集積回路６０３は、媒体IF部６０１から転送されたデータに対して映像・音声処理を施すシステムLSIで、主制御部６０６、ストリーム処理部６０５、信号処理部６０７、メモ
リ制御部６０９、AV出力部６０８等から構成される。
主制御部６０６は、タイマ機能や割り込み機能を有するプロセッサコアを有し、プロセッサコアはプログラムメモリ等に格納されたプログラムに従って、集積回路６０３全体の制御を行う。なお、プログラムメモリ等には、予めOS等の基本ソフトが格納されている。
ストリーム処理部６０５は、主制御部６０６の制御の下、媒体から媒体IF部６０１経由で転送されたデータを受信し、集積回路６０３内のデータバスを経由してメモリ６０２に格納したり、受信したデータを映像系データ（ビデオ／グラフィクス（PG,IG））、音声
系データに分離する。前述したとおり媒体上ではレフトビュービデオストリームを含む2D/L用のAVクリップとライトビュービデオストリームを含むR用のAVクリップが、幾つかの
エクステントに分割された状態で交互に配置されている。従って、主制御部６０６は、集積回路６０３がレフトビューストリームを含む左目用データを受信した場合は、メモリ６０２の第１の領域にデータが格納されるように、ライトビュービデオストリームを含む右目用データを受信した場合は、メモリ６０２の第２の領域にデータが格納されるように制御する。ここで、左目用データは左目用エクステントに属しており、右目用データは右目用エクステントに属している。なお、メモリ６０２における第１、第２の領域は単一のメモリが論理的に領域分割されたものでもよいし、物理的に異なるメモリでもよい。また、本実施形態においては、レフトビュービデオストリームを含む左目用データをメインビューデータ、ライトビュービデオストリームを含む右目用データをサブビューデータとして説明を続けるが、右目用データがメインビューデータ、左目用データがサブビューデータであっても構わない。
信号処理部６０７は、主制御部６０６の制御の下、ストリーム処理部６０５が分離した映像系データ、音声系データに対し、適切な方式でデコードする。映像系データは、MPEG-2、MPEG-4 AVC、MPEG4-MVC、SMPTE VC-1などの方式を使って符号化記録されており、ま
た音声系データは、ドルビーAC-3、Dolby Digital Plus、MLP、DTS、DTS-HD、リニアPCM
などの方式で圧縮・符号化記録されているので、信号処理部６０７はこれらに対応した方式でデコードする。なお、信号処理部６０７のモデルは、例えば第９実施形態の図６５における各種デコーダがそれに当たる。
メモリ制御部６０９は、集積回路６０３内の各機能ブロックからメモリ６０２へのアクセスを調停する。
AV出力部６０８は、主制御部６０６の制御の下、信号処理部６０７においてデコードされた映像系データを重畳したり、映像系データのフォーマット変換等をして集積回路６０３外へ出力する。
図９０は、ストリーム処理部６０５の代表的な構成を示す機能ブロック図である。ストリーム処理部６０５は、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３等を備える。
デバイス・ストリームIF部６５１は、媒体IF部６０１と集積回路６０３間のデータ転送用インターフェースであり、例えば、媒体が光ディスクやハードディスクの場合はSATA(Serial Advanced Technology Attachment)、ATAPI(Advanced Technology Attachment Packet Interface)、PATA(Parallel Advanced Technology Attachment)、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波などの場合はチ
ューナーIF、媒体がイーサネット(登録商標)、無線LAN、無線公衆回線等のネットワーク
の場合は、ネットワークIF、等である。なお、媒体の種類によっては、デバイス・ストリームIF部６５１が媒体IF部６０１の機能の一部を肩代わりしても構わないし、媒体IF部６０１が集積回路６０３に内蔵されていても構わない。
多重分離部６５２は、媒体から転送された映像・音声を含む再生データを映像系データと音声系データに分離する。前述の各エクステントは、映像・音声・PG（字幕）・IG（メニュー）等の各ソースパケットから構成されており（但し、サブビューデータは音声を含まない場合もある）、各ソースパケットに含まれているPID（識別子）に従って、映像系
・音声系の各TSパケットに分離され、信号処理部６０７に転送される。処理済のデータは、直接もしくは一旦メモリ６０２に格納された後、信号処理部６０７に転送される。なお、多重分離部６５２のモデルは、例えば第９実施形態の図６５におけるソースデパケタイザ、PIDフィルタがそれに当たる。
切替部６５３は、デバイス・ストリームIF部６５１が左目用データを受信した時はメモ
リ６０２の第１の領域に格納されるように、右目用データを受信した時はメモリ６０２の第２の領域に格納されるように、出力先（格納先）を切り替える。ここで、切替部６５３は例えばDMAC(Direct Memory A１０１ess Controller)である。図９１は切替部６５３がDMACであった場合の切替部６５３周辺の概念図である。DMACは、主制御部６０６の制御の
下、デバイス・ストリームIF部が受信したデータとそのデータ格納先アドレスをメモリ制御部６０９に対して送信する。具体的には、デバイス・ストリームIF部が左目用データを受信した時はアドレス１（第１の格納領域）を、右目用データを受信した時はアドレス２（第２の格納領域）をメモリ制御部６０９に送信することで、受信データによってその出力先（格納先）を切り替えている。メモリ制御部６０９は、DMACから送られてきた格納先アドレスに従ってメモリ６０２にデータを格納する。なお、主制御部６０６の代わりに切替部６５３を制御する専用の回路を設けても構わない。
ここでは、ストリーム処理部６０５の代表的な構成として、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３について説明したが、受信した暗号化データや鍵データ等を復号する暗号エンジン部、媒体〜再生装置間の機器認証プロトコル等の実行制御や秘密鍵を保持するセキュア管理部、ダイレクトメモリアクセス用のコントローラ等を更に備えていてもよい。これまでは媒体から受信したデータをメモリ６０２に格納する際に、切替部６５３が左目用データ・右目用データかによって格納先を切り替える場合について説明してきたが、媒体から受信したデータを一旦メモリ６０２に格納した後に、多重分離部６５２へデータを転送する際に、左目用データ・右目用データを振り分けてもよい。
図９２は、AV出力部６０８の代表的な構成を示す機能ブロック図である。AV出力部６０８は、画像重畳部６８１と、ビデオ出力フォーマット変換部６８２、オーディオ・ビデオ出力IF部６８３等を備える。
画像重畳部６８１は、デコードされた映像系のデータを重畳する。具体的には、レフトビュービデオデータもしくはライトビュービデオデータと、PG（字幕）、IG（メニュー）をピクチャ単位で重畳する。画像重畳部６８１のモデルは、例えば第１１実施形態、図９２などである。
画像重畳部６８１は、レフトビュープレーンとグラフィクスプレーン、ライトビュープレーンとグラフィクスプレーンとを重畳する。図９４は画像重畳処理におけるメモリ６０２と各プレーンとの関係を示した図である。メモリ６０２には、デコード済みのデータで、各プレーンに描画されるデータを格納する領域（レフトビューに対応するプレーンデータ格納領域、ライトビューに対応するプレーンデータ格納領域、グラフィクスに対応するプレーンデータ格納領域）を備える。ここで、プレーンはメモリ６０２中の領域であることもあれば、仮想的な空間であることもある。メモリ６０２は、更に画像重畳後のデータを格納する画像重畳後データ格納領域を備える。
図９５、図９６は画像重畳の概念図である。ここでは簡単のために、グラフィクスプレーンは一枚であり、レフトビュープレーンと重畳する際は、グラフィクスプレーンに+Xのオフセットを与えて、ライトビュープレーンと重畳する際は、-Xのオフセットを与えて重畳処理を行う、ワンプレーンオフセットモードを前提として説明する。なお、グラフィックスプレーンをレフトビュー重畳用、ライトビュー重畳用の二枚用意し、それぞれにオフセット値を与えて、重畳処理を行っても構わない。図９５においては、グラフィクスプレーンを紙面上右へoffset値だけ平行移動させたものをレフトビュープレーンと、図９６においては、グラフィクスプレーンを紙面上左へoffset値だけ平行移動させたものをライトビュープレーンと重畳する。この時、図示しているように紙面上左右方向の座標が同じで対応する画素同士を重畳し、重畳後のデータをメモリ６０２の画像重畳後データ格納領域
に格納する。なお、グラフィクスプレーンのoffset値は、前述のとおりライトビュービデオストリーム（サブビュービデオストリーム）もしくは、PLAYLISTに含まれている。図９７は、画像重畳の別の方法を示した概念図で、メモリ６０２は更に、オフセット済みグラフィクスに対応するプレーンデータ格納領域（レフトビュー重畳用、ライトビュー重畳用）を備え、予めレフトビュープレーン、ライトビュープレーンと重畳されるデータをメモリ６０２に用意しておき、画像重畳部６８１がメモリ６０２から必要なデータを読み込んで重畳し、重畳後のデータをメモリ６０２の画像重畳後データ格納領域に格納するというものである。また図９８は、テキスト字幕（PG/IGとは別）の重畳に関する概念図である
。テキスト字幕は、前述のとおりテキスト字幕ストリームに多重化されており、グラフィクスプレーンに描画されて重畳されるが、レフトビュープレーン重畳時とライトビュー重畳時とはそれぞれオフセット値分だけずらして描画したものを、レフトビュープレーン、ライトビュープレーンと重畳する。なお、図９８に示しているとおりメモリ６０２は更にテキスト字幕に対応するプレーンデータ格納領域を備えている。
ビデオ出力フォーマット変換部６８２は、デコードされた映像系データに対して、拡大または縮小するリサイズ処理、走査方式をプログレッシブ方式及びインターレース方式の一方から他方に変換するＩＰ変換処理、ノイズを除去するノイズリダクション処理、フレームレートを変換するフレームレート変換処理などを必要に応じて行う。
オーディオ・ビデオ出力IF部６８３は、画像重畳やフォーマット変換された映像系データとデコードされた音声系データとに対して、データ送信形式に合わせてエンコード等を行う。なお、後述するようにオーディオ・ビデオ出力IF部６８３は、一部集積回路６０３外に備えられても構わない。
図９３は、AV出力部６０８もしくは再生装置のデータ出力部分を、より詳細に示した構成例である。本実施の形態における集積回路６０３及び再生装置は、複数の映像系データ、音声系データのデータ送信形式に対応している。図９２におけるオーディオ・ビデオ出力IF部６８３は、アナログビデオ出力IF部６８３a、アナログオーディオ出力IF部６８３c、デジタルオーディオ・出力IF部６８３bに対応する。
アナログビデオ出力IF部６８３aは、画像重畳処理や出力フォーマット変換処理された
映像系データを、アナログ映像信号形式に変換・エンコードし、出力する。例えば、NTSC、PAL、SECAMの３方式のいずれかに対応したコンポジットビデオエンコーダー、Ｓ映像信号（Y/C分離）用エンコーダー、コンポーネント映像信号用エンコーダーや、DAC（D/Aコ
ンバータ）等がそれに当たる。
デジタルオーディオ・ビデオ出力IF部６８３bは、デコードされた音声系データと画像
重畳処理や出力フォーマット変換された映像系データを一体化、更に暗号化した後、データ送信規格に合わせてエンコードし、出力する。例えば、HDMI(High−Definition Multimedia InterFace)等がそれに当たる。
アナログオーディオ出力IF部６８３cは、デコードされた音声系データをD/A変換しアナログ音声データを出力するオーディオDAC等がそれに当たる。
これら映像系データ及び音声系データの送信形式は、表示装置・スピーカー６０４側がサポートしているデータ受信装置（データ入力端子）に依存して切り替えたり、またユーザーの選択によって送信形式を切り替えることが可能である。更に、単一の送信形式だけではなく、並行して複数の送信形式にて同一のコンテンツに対応したデータを送信することも可能である。
ここでは、AV出力部６０８の代表的な構成として、画像重畳部６８１、ビデオ出力フォ
ーマット変換部６８２、オーディオ・ビデオ出力IF部６８３について説明したが、フィルタ処理、画面合成、曲線描画、３Ｄ表示等のグラフィックス処理を行うグラフッィクスエンジン部等を更に備えていてもよい。
以上が、本実施の形態における再生装置の構成についての説明である。なお、前述の集積回路６０３に含まれる各機能ブロックは全てが内蔵されていなくても良いし、逆に図８９のメモリ６０２が集積回路６０３に内蔵されていてもよい。また、本実施形態においては、主制御部６０６と信号処理部６０７は異なる機能ブロックとして説明してきたが、主制御部６０６が信号処理部６０７の処理の一部を行っても構わない。
また、集積回路６０３における制御バスやデータバスの経路は、各処理ブロックの処理手順や処理内容によって任意に配置されるが、例えば図９９のように、各処理ブロックどうしを直接結ぶようにデータバスを配置してもよいし、図１００のように各処理ブロックどうしをメモリ６０２（メモリ制御部６０９）を介して結ぶようにデータバスを配置してもよい。
また、集積回路６０３は、複数のチップを一つのパッケージに封止し、見かけ上一つのLSIにしたマルチチップ・モジュールであっても構わない。
また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサ
を利用してもよい。
次に、以上のように構成された再生装置の動作について説明する。
図１０１は、媒体からデータを受信し（読み出し）、デコードした後に、映像信号及び音声信号として出力する再生動作手順を簡単に示すフローチャートである。
Ｓ６０１：媒体からデータを受信する（読み出す）（媒体IF部６０１、ストリーム処理部６０５）。
Ｓ６０２：Ｓ６０１において受信された（読み出された）データを各種データ（映像系データ・音声系データ）に分離する（ストリーム処理部６０５）。
Ｓ６０３：Ｓ６０２において分離された各種データを適切な形式でデコードする（信号処理部６０７）。
Ｓ６０４：Ｓ６０３においてデコード処理された各種データのうち、映像系のものについて重畳処理を行う（AV出力部６０８）。
Ｓ６０５：Ｓ６０２〜Ｓ６０４において処理された映像系データ及び音声系データを出力する（AV出力部６０８）。
図１０２は、より詳細に再生動作手順を示したフローチャートである。各動作・処理は、主制御部６０６の制御の下、行われる。
Ｓ７０１：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている再生されるデータ以外の、データを再生するために必要なデータ（PLAYLIST、CLIPINF等）を受信し（読み出し）、メモリ６０２に格納する（
媒体IF部６０１、デバイスIF部６５１、メモリ制御部６０９、メモリ６０２）。
Ｓ７０２：主制御部６０６は、受信されたCLIPINFに含まれるストリーム属性情報から
、媒体に格納されている映像データ及び音声データの圧縮形式を認識し、対応するデコード処理ができるように信号処理部６０７の初期化を行う（主制御部６０６）。
Ｓ７０３：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている映像・音声など再生されるデータを受信し（読み出し）、切替部６５３、メモリ制御部６０９を経由してメモリ６０２に格納する。なお、データはエクステント単位で受信し（読み出され）、左目用データを受信した（読み出した）時は第１の領域へ、右目用データを受信した（読み出した）時は第２の領域へ格納されるよう、主制御部６０６が切替部６５３を制御し、切替部６５３がデータの出力先（格納先）を切り替える（媒体IF部６０１、デバイスIF部５１、主制御部６０６、切替部６５３、メモリ制御部６０９、メモリ６０２）。
Ｓ７０４：メモリ６０２に格納されたデータは、ストリーム処理部６０５の多重分離部６５２に転送され、多重分離部６５２はストリームデータを構成するソースパケットに含まれるPIDに従って映像系（主映像、副映像、PG（字幕）、IG（メニュー））、音声系（
音声、副音声）のいずれであるか認識し、TSパケット単位で信号処理部６０７の対応する各デコーダへ転送する。（多重分離部６５２）。
Ｓ７０５：信号処理部６０７の各デコーダは、転送されてきたTSパケットに対して、適切な方式でデコード処理を行う（信号処理部６０７）。
Ｓ７０６：信号処理部６０７においてデコードされた映像系データのうち、レフトビュービデオストリーム及びライトビュービデオストリームに対応するデータを、表示装置４に合わせてリサイズする（ビデオ出力フォーマット変換部６８２）。
Ｓ７０７：Ｓ７０６においてリサイズされたビデオストリームと、PG（字幕）・IG（メニュー）とが重畳される（画像重畳部６８１）。
Ｓ７０８：Ｓ７０７において重畳された映像データに対して、走査方式の変換であるＩＰ変換を行う（ビデオ出力フォーマット変換部６８２）。
Ｓ７０９：これまでの処理を行った映像系データ及び音声系データに対して、表示装置・スピーカー６０４のデータ出力方式、もしくは表示装置・スピーカー６０４へのデータ送信方式に従って、エンコードやD/A変換等を行う。例えば、映像系データ・音声系デー
タをそれぞれ、アナログまたはデジタル出力に対応するために処理を行う。映像系データのアナログ出力としては、コンポジット映像信号やＳ映像信号やコンポーネント映像信号等をサポートしている。また映像系・音声系データのデジタル出力は、HDMIをサポートしている（オーディオ・ビデオ出力IF部６８３）。
Ｓ１１０：Ｓ７０９において処理された映像系データ及び音声系データを、表示装置・スピーカー６０４に送信、出力する（オーディオ・ビデオ出力IF部６８３、表示装置・スピーカー６０４）。
以上が、本実施の形態における再生装置の動作手順の説明である。なお、処理ごとに処理結果をメモリ６０２に一旦格納しても構わない。また、本動作手順では、ビデオ出力フォーマット変換部６８２においてリサイズ処理及びIP変換処理を行う場合について説明したが、必要に応じて処理を省略しても構わないし、また他の処理（ノイズリダクション処理、フレームレート変換処理等）を行っても構わない。更に、可能なものについては処理手順を変更しても構わない。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
（複数のオフセットシーケンスの割り当て）
複数のオフセットシーケンスのそれぞれに、画像のマクロブロック毎の奥行きを格納するというのは一例に過ぎない。
また、それぞれが＋１０又は−１０ずつ異なる奥行きを示す奥行き情報を、各オフセットシーケンスのプレーンオフセット方向情報、及び、プレーンオフセットシフト値として設定してもよい。
(ファイル同士の対応付け)
第３実施形態において、識別情報を用いた対応付けの具体例ではレフトビューの識別番号に"１"を加算したものをライトビューの識別番号とした。しかし、レフトビューの識別番号に、"１００００"を加算したものをライトビューの識別番号として採用してもよい。
ファイル名によるカップリング方式でファイルの対応付けてを実現する場合、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。
Depth方式のためのグレースケールのように、１本では立体視映像を再生できないスト
リームに関しては、誤って機器がそのファイルを単体で再生しないように拡張子を変えて区別する。単体では再生できないファイルを識別するため3D対応ファイルを既存機器からDLNA(Digital Living Network Alliance)を介して参照する場合などのユーザー混乱を防
止する。ファイル番号を同一にし、拡張子を区別することで、ファイル名だけでペアリング情報を表現することも可能になる。
(立体視方式)
第１実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実
施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。
TV３００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。
同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上
のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラ
ムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
（光ディスクの再生）
BD-ROMドライブは、半導体レーザ、コリメートレンズ、ビームスプリッタ、対物レンズ、集光レンズ、光検出器を有する光学ヘッドを備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。
集光された光ビームは、光ディスク上で反射/回折され、対物レンズ、ビームスプリッ
タ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、再生信号を生成する。
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明
をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。
（半導体メモリカード記録装置及び再生装置の実施形態）
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。
BD-ROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。
例えば、BD-ROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。
以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
半導体メモリカード再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。
一方、BD-ROMには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するMKB（メディアキーブロック））と、暗号化されたデ
ータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びMKBに
対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、MKB、及び暗
号化タイトルキーは対になっており、さらにBD-ROM上の通常コピーできない領域（BCAと
呼ばれる領域）に書き込まれた識別子（例えばボリュームID）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、MKB及びボリュームID
を元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。
装填されたBD-ROMを再生装置において再生する場合、例えばBD-ROM内の暗号化タイトルキー、MKBと対になっている（または対応する）デバイスキーが再生装置内になければ、
暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵（タイトルキー）は、鍵自体が暗号化されて（暗号化タイトルキー）BD-ROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵
を導き出すことができないからである。
逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しけ
れば、例えば上述の暗号解読に必要な鍵（デバイスキー、MKB及びボリュームIDを元に、
暗号化タイトルキーを復号して得られるタイトルキー）を用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。
以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリ
ー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。
半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを
介してデータを読み出すように構成すればよい。
より詳細には、再生装置のスロットに半導体メモリーカードが挿入されると、半導体メモリーカードI/Fを経由して再生装置と半導体メモリーカードが電気的に接続される。半
導体メモリーカードに記録されたデータは半導体メモリーカードI/Fを介して読み出すよ
うに構成すれば良い。
(受信装置としての実施形態)
各実施形態で説明した再生装置は、本実施の形態で説明をしたデータに相応するデータ（配信データ）を電子配信サービスの配信サーバから受信し、半導体メモリカードに記録する端末装置としても実現することができる。
かかる端末装置は、各実施形態で説明した再生装置がそのような動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDカードを例に説明をする。
再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバへ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報（例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等）をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。
この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。
例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。
生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相
当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモ
リー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。
次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。
次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）
、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、（１） 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メ
モリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック（２） 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一
致するかのチェック（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づ
いて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。
上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリ
ー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用い
て、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号（例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等）は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の（１）の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域（第１の記録領域と称す）とは別の記録領域（第２の記録領域と称す）に設けること、およびこの第２の記録領域へのアクセスをするための制御回路を設けるとともに、第２の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
例えば、第２の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第２の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第２の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第２の
記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行すると、要求を受けた制御回路は第２の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第１の記録領域に記録するように構成すればよい。
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第
２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のX.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなく3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ
１００ 記録媒体
２００ 再生装置
３００ 表示装置
４００ 3D眼鏡
５００ リモコン

Claims (3)

  1. 放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
    前記データは、メインビュービデオストリームと、サブビュービデオストリームと、グラフィクスストリームとを含み、
    前記メインビュービデオストリームは、立体視映像のメインビューを構成するピクチャデータを含み、
    前記サブビュービデオストリームは、立体視映像のサブビューを構成するピクチャデータと、メタデータとを含み、
    前記グラフィクスストリームは、グラフィクスデータを含み、
    前記メタデータは、前記グラフィクスデータに対して水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する、オフセット制御を規定する制御情報であり、
    前記メインビュービデオストリーム及び前記サブビュービデオストリームをデコードすることにより、メインビューを構成するピクチャデータ及びサブビューを構成するピクチャデータを得るビデオデコーダと、
    前記グラフィクスストリームをデコードすることにより、グラフィクスデータを得るグラフィクスデコーダと、
    前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと、前記グラフィクスデータとを合成する合成部と、
    を備え、
    前記合成部は、前記制御情報に基づいて、前記グラフィクスデータに対して、水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する
    ことを特徴とする受信装置。
  2. 前記制御情報は、
    前記グラフィクスデータのオフセット方向を規定する情報をさらに含み、
    前記合成部は、前記制御情報に基づいて、前記グラフィクスデータに対して、水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する
    ことを特徴とする請求項１記載の受信装置。
  3. 前記メインビュービデオストリームにおけるピクチャデータ及び前記サブビュービデオストリームにおけるピクチャデータは、それぞれ複数のグループオブピクチャを構成し、前記複数のグループオブピクチャにおける各グループオブピクチャは、それぞれ複数のフレームを構成し、前記複数のフレームにおける各フレームに対応する制御情報を、パラメータシーケンスとして有し、
    前記合成部は、前記パラメータシーケンスにおける個々の制御情報に基づいて、前記グラフィクスデータに対して、水平座標の右方向及び左方向のオフセットを与えて、それぞれ前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータと合成する
    ことを特徴とする請求項２記載の受信装置。
JP2012092048A 2009-02-19 2012-04-13 受信装置 Expired - Fee Related JP5027952B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012092048A JP5027952B2 (ja) 2009-02-19 2012-04-13 受信装置

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2009037225 2009-02-19
JP2009037225 2009-02-19
JP2009066885 2009-03-18
JP2009066885 2009-03-18
JP2012092048A JP5027952B2 (ja) 2009-02-19 2012-04-13 受信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2010249396A Division JP5416073B2 (ja) 2009-02-19 2010-11-08 半導体集積回路

Publications (2)

Publication Number Publication Date
JP2012178847A JP2012178847A (ja) 2012-09-13
JP5027952B2 true JP5027952B2 (ja) 2012-09-19

Family

ID=42633700

Family Applications (8)

Application Number Title Priority Date Filing Date
JP2010524691A Active JP4588120B2 (ja) 2009-02-19 2010-02-15 再生装置、記録方法、記録媒体再生システム
JP2010158640A Active JP4629805B2 (ja) 2009-02-19 2010-07-13 再生装置、記録方法、記録媒体再生システム
JP2010158642A Expired - Fee Related JP4654320B2 (ja) 2009-02-19 2010-07-13 集積回路
JP2010158641A Active JP4634534B2 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010249396A Expired - Fee Related JP5416073B2 (ja) 2009-02-19 2010-11-08 半導体集積回路
JP2012092048A Expired - Fee Related JP5027952B2 (ja) 2009-02-19 2012-04-13 受信装置
JP2012092049A Expired - Fee Related JP5027953B2 (ja) 2009-02-19 2012-04-13 受信装置
JP2012098956A Expired - Fee Related JP5038543B2 (ja) 2009-02-19 2012-04-24 受信装置

Family Applications Before (5)

Application Number Title Priority Date Filing Date
JP2010524691A Active JP4588120B2 (ja) 2009-02-19 2010-02-15 再生装置、記録方法、記録媒体再生システム
JP2010158640A Active JP4629805B2 (ja) 2009-02-19 2010-07-13 再生装置、記録方法、記録媒体再生システム
JP2010158642A Expired - Fee Related JP4654320B2 (ja) 2009-02-19 2010-07-13 集積回路
JP2010158641A Active JP4634534B2 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010249396A Expired - Fee Related JP5416073B2 (ja) 2009-02-19 2010-11-08 半導体集積回路

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2012092049A Expired - Fee Related JP5027953B2 (ja) 2009-02-19 2012-04-13 受信装置
JP2012098956A Expired - Fee Related JP5038543B2 (ja) 2009-02-19 2012-04-24 受信装置

Country Status (14)

Country Link
US (3) US8712215B2 (ja)
EP (6) EP2521364B1 (ja)
JP (8) JP4588120B2 (ja)
KR (1) KR20110126518A (ja)
CN (6) CN102685515B (ja)
AU (1) AU2010216963A1 (ja)
BR (1) BRPI1001265A2 (ja)
DK (1) DK2521364T3 (ja)
ES (3) ES2467149T3 (ja)
MX (1) MX2010011683A (ja)
RU (1) RU2522304C2 (ja)
TW (1) TW201123841A (ja)
WO (1) WO2010095411A1 (ja)
ZA (3) ZA201007461B (ja)

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201027978A (en) * 2008-09-30 2010-07-16 Panasonic Corp Recording medium on which 3D video is recorded, playback apparatus for playing back 3D video, and system LSI
JP4984183B2 (ja) 2009-04-07 2012-07-25 ソニー株式会社 再生装置、再生方法、および記録方法
JP2010244630A (ja) * 2009-04-07 2010-10-28 Sony Corp 情報処理装置、情報処理方法、プログラム、及び、データ構造
JP4985895B2 (ja) * 2009-04-07 2012-07-25 ソニー株式会社 再生装置、再生方法、および記録方法
JP5267886B2 (ja) * 2009-04-08 2013-08-21 ソニー株式会社 再生装置、記録媒体、および情報処理方法
JP2010268431A (ja) * 2009-04-15 2010-11-25 Sony Corp データ構造、記録媒体、再生装置および再生方法、並びにプログラム
JP4985887B2 (ja) * 2009-04-15 2012-07-25 ソニー株式会社 記録方法
JP4985807B2 (ja) * 2009-04-15 2012-07-25 ソニー株式会社 再生装置および再生方法
RU2538307C2 (ru) * 2009-05-12 2015-01-10 Сони Корпорейшн Структура данных и носитель данных, воспроизводящее устройство, способ воспроизведения, программа и носитель для хранения программы
JP2011041249A (ja) * 2009-05-12 2011-02-24 Sony Corp データ構造および記録媒体、並びに、再生装置、再生方法、プログラム、およびプログラム格納媒体
EP2434769B1 (en) * 2009-05-19 2016-08-10 Panasonic Intellectual Property Management Co., Ltd. Recording method and playback method
JP2011107589A (ja) * 2009-11-20 2011-06-02 Sony Corp 立体表示装置
CN102812711B (zh) * 2010-02-25 2016-11-02 汤姆森特许公司 利用视差估计和视差时间变化限制的立体字幕加载
US8817072B2 (en) * 2010-03-12 2014-08-26 Sony Corporation Disparity data transport and signaling
JP5604173B2 (ja) * 2010-04-30 2014-10-08 三洋電機株式会社 再生装置、表示装置、記録装置及び格納媒体
KR20120017228A (ko) * 2010-08-18 2012-02-28 엘지전자 주식회사 이동 단말기 및 상기 이동 단말기의 영상 표시 방법
KR102000618B1 (ko) * 2010-09-13 2019-10-21 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨 부가기능의 관리
JP5594045B2 (ja) * 2010-10-14 2014-09-24 ソニー株式会社 再生装置、再生方法、プログラム、および記録媒体
JP2012099986A (ja) * 2010-10-29 2012-05-24 Sony Corp 立体画像データ送信装置、立体画像データ送信方法、立体画像データ受信装置および立体画像データ受信方法
JP2012100102A (ja) * 2010-11-02 2012-05-24 Sony Corp 立体画像データ送信装置、立体画像データ送信方法、立体画像データ受信装置および立体画像データ受信方法
US20120120050A1 (en) * 2010-11-12 2012-05-17 Nokia Corporation Dual-mode two-dimensional/three-dimensional display
US8705946B2 (en) 2010-11-19 2014-04-22 Sony Corporation 3D authoring tool ensuring no buffer underrun upon jumps
KR101831775B1 (ko) * 2010-12-07 2018-02-26 삼성전자주식회사 멀티미디어 컨텐츠를 송수신하는 송신 장치 및 수신 장치와, 그 재생 방법
CN103348694A (zh) 2010-12-07 2013-10-09 三星电子株式会社 发送用于构成内容的数据的发射机、接收和处理该数据的接收机及其方法
JP2012151663A (ja) * 2011-01-19 2012-08-09 Toshiba Corp 立体音響生成装置及び立体音響生成方法
JP5685969B2 (ja) * 2011-02-15 2015-03-18 ソニー株式会社 表示制御方法、表示制御装置
US20120236114A1 (en) * 2011-03-18 2012-09-20 Te-Hao Chang Depth information generator for generating depth information output by only processing part of received images having different views, and related depth information generating method and depth adjusting apparatus thereof
BR112013027226A2 (pt) 2011-04-28 2016-12-27 Panasonic Corp dispositivo de processamento de vídeo e método de processamento de vídeo
US20120293636A1 (en) * 2011-05-19 2012-11-22 Comcast Cable Communications, Llc Automatic 3-Dimensional Z-Axis Settings
WO2012160812A1 (ja) * 2011-05-25 2012-11-29 パナソニック株式会社 映像処理装置、送信装置、立体映像視聴システム、映像処理方法、映像処理プログラム及び集積回路
JP5957768B2 (ja) * 2011-08-24 2016-07-27 パナソニックＩｐマネジメント株式会社 記録媒体、再生装置、記録装置、及び記録方法
KR20130024504A (ko) * 2011-08-31 2013-03-08 삼성전기주식회사 삼차원 카메라 시스템 및 주시각 조정 방법
KR101287786B1 (ko) * 2011-09-22 2013-07-18 엘지전자 주식회사 3차원 입체영상 표시 방법 및 그를 이용한 영상 표시 장치
CN102427542B (zh) * 2011-09-28 2014-07-30 深圳超多维光电子有限公司 一种立体图像处理方法、图像处理装置和相应的终端设备
CN103931200A (zh) * 2011-11-14 2014-07-16 摩托罗拉移动有限责任公司 Mvc立体视图与用于3dtv的左或右眼显示器的关联
US8762452B2 (en) 2011-12-19 2014-06-24 Ericsson Television Inc. Virtualization in adaptive stream creation and delivery
CN103609106A (zh) * 2012-01-18 2014-02-26 松下电器产业株式会社 发送装置、影像显示装置、发送方法、影像处理方法、影像处理程序以及集成电路
KR101699367B1 (ko) * 2012-05-16 2017-02-14 한국전자통신연구원 3ｄｔｖ 다중화 방법 및 그 장치
US9936196B2 (en) 2012-10-30 2018-04-03 Qualcomm Incorporated Target output layers in video coding
WO2015017314A1 (en) * 2013-07-30 2015-02-05 Dolby Laboratories Licensing Corporation System and methods for generating scene stabilized metadata
US9716885B2 (en) * 2013-07-31 2017-07-25 Empire Technology Development Llc Encoding scheme
US9648348B2 (en) * 2013-10-23 2017-05-09 Qualcomm Incorporated Multi-layer video file format designs
US9503705B2 (en) * 2013-12-12 2016-11-22 Lenovo (Singapore) Pte. Ltd. Stereoscopic image generation
US10298546B2 (en) * 2014-03-07 2019-05-21 Toshiba Memory Corporation Asymmetrical encryption of storage system to protect copyright and personal information
US10750198B2 (en) 2014-05-22 2020-08-18 Qualcomm Incorporated Maximum palette parameters in palette-based video coding
US9674099B2 (en) * 2014-09-25 2017-06-06 Microsoft Technology Licensing, Llc Network classification for applications
EP3248377B1 (en) * 2015-02-16 2022-05-04 HFI Innovation Inc. Method and apparatus for palette predictor initialization for palette coding in video and image compression
CN106296781B (zh) * 2015-05-27 2020-09-22 深圳超多维科技有限公司 特效图像生成方法及电子设备
EP3099081B1 (en) * 2015-05-28 2020-04-29 Samsung Electronics Co., Ltd. Display apparatus and control method thereof
US9520002B1 (en) * 2015-06-24 2016-12-13 Microsoft Technology Licensing, Llc Virtual place-located anchor
US10334218B2 (en) * 2015-06-25 2019-06-25 Mitsubishi Electric Corporation Video reproduction device and video reproduction method
US11095869B2 (en) 2015-09-22 2021-08-17 Fyusion, Inc. System and method for generating combined embedded multi-view interactive digital media representations
US11006095B2 (en) 2015-07-15 2021-05-11 Fyusion, Inc. Drone based capture of a multi-view interactive digital media
US10147211B2 (en) 2015-07-15 2018-12-04 Fyusion, Inc. Artificially rendering images using viewpoint interpolation and extrapolation
US10242474B2 (en) 2015-07-15 2019-03-26 Fyusion, Inc. Artificially rendering images using viewpoint interpolation and extrapolation
US10222932B2 (en) 2015-07-15 2019-03-05 Fyusion, Inc. Virtual reality environment based manipulation of multilayered multi-view interactive digital media representations
US11783864B2 (en) * 2015-09-22 2023-10-10 Fyusion, Inc. Integration of audio into a multi-view interactive digital media representation
US9507241B1 (en) 2015-11-17 2016-11-29 Lenovo (Singapore) Pte, Ltd. Adjustable camera field of view
CN105635620A (zh) * 2016-01-18 2016-06-01 北京优祥智恒科技有限公司 一种支持音频透传sdi输出的装置和方法
CN108476341B (zh) * 2016-01-26 2021-06-25 索尼公司 接收设备、接收方法和发送设备
US11202017B2 (en) 2016-10-06 2021-12-14 Fyusion, Inc. Live style transfer on a mobile device
GB2558236B (en) 2016-12-22 2021-03-31 Apical Ltd Image data comprising encoded image data and additional data for modification of image
CN106791795A (zh) * 2017-01-03 2017-05-31 京东方科技集团股份有限公司 3d视频流的发送方法及发送装置、接收方法及接收装置
US10437879B2 (en) 2017-01-18 2019-10-08 Fyusion, Inc. Visual search using multi-view interactive digital media representations
US10313651B2 (en) 2017-05-22 2019-06-04 Fyusion, Inc. Snapshots at predefined intervals or angles
US11069147B2 (en) 2017-06-26 2021-07-20 Fyusion, Inc. Modification of multi-view interactive digital media representation
CN107231516A (zh) * 2017-07-27 2017-10-03 重庆万建电子工程有限责任公司重庆第分公司 带刮灰结构的半球型摄像机
US10592747B2 (en) 2018-04-26 2020-03-17 Fyusion, Inc. Method and apparatus for 3-D auto tagging
FR3086831A1 (fr) * 2018-10-01 2020-04-03 Orange Codage et decodage d'une video omnidirectionnelle
WO2020071632A1 (ko) * 2018-10-02 2020-04-09 엘지전자 주식회사 360 비디오 시스템에서 오버레이 처리 방법 및 그 장치
US11347788B2 (en) * 2019-01-16 2022-05-31 Toyota Research Institute, Inc. Systems and methods for generating a requested image view
CN110231905B (zh) * 2019-05-07 2021-02-09 华为技术有限公司 一种截屏方法及电子设备
CN111626049B (zh) * 2020-05-27 2022-12-16 深圳市雅阅科技有限公司 多媒体信息的标题修正方法、装置、电子设备及存储介质
TWI790600B (zh) * 2021-04-21 2023-01-21 宏芯科技股份有限公司 區域式視訊影像插補裝置及其方法

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR930010608A (ko) * 1991-11-04 1993-06-22 이승 카 메 라
US6052100A (en) 1994-03-16 2000-04-18 The United States Of America Represented By The Secertary Of The Navy Computer controlled three-dimensional volumetric display
US6484266B2 (en) * 1995-09-29 2002-11-19 Matsushita Electric Industrial Co., Ltd. Method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
TW436777B (en) * 1995-09-29 2001-05-28 Matsushita Electric Ind Co Ltd A method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
EP2299702B1 (en) 1996-02-28 2013-12-11 Panasonic Corporation High-resulution optocal disk for recording stereoscopic video, optical disk reproducing device and optical disk recording device
EP2268015B1 (en) * 1996-12-04 2013-10-16 Panasonic Corporation Optical disk for high resolution and three dimensional video recording, optical disk reproduction apparatus, and optical disk recording apparatus
JPH10234058A (ja) * 1997-02-18 1998-09-02 Ikegami Tsushinki Co Ltd 立体映像への文字付加装置及びその装置を備えたカラオケ装置
US6925250B1 (en) * 1997-08-29 2005-08-02 Matsushita Electric Industrial Co., Ltd. Optical disc for recording high resolution and normal image, optical disc player, optical disc recorder, and playback control information generator
JPH11289555A (ja) 1998-04-02 1999-10-19 Toshiba Corp 立体映像表示装置
US6956964B2 (en) * 2001-11-08 2005-10-18 Silicon Intergrated Systems Corp. Apparatus for producing real-time anaglyphs
WO2003092303A1 (en) * 2002-04-25 2003-11-06 Sharp Kabushiki Kaisha Multimedia information generation method and multimedia information reproduction device
JP2004104742A (ja) * 2002-09-11 2004-04-02 Remedia:Kk 立体映像データの発生方法と装置
JP2004274125A (ja) * 2003-03-05 2004-09-30 Sony Corp 画像処理装置および方法
US20060176295A1 (en) 2003-05-30 2006-08-10 Lattice Technology, Inc. 3-Dimensional graphics data display device
JP4988340B2 (ja) * 2003-07-07 2012-08-01 サムスン エレクトロニクス カンパニー リミテッド マルチアングルデータを記録した情報記録媒体、その記録方法及び再生装置
JP3746506B2 (ja) * 2004-03-08 2006-02-15 一成 江良 立体視化パラメータ埋込装置及び立体視画像再生装置
EP1863031B1 (en) * 2004-06-18 2011-01-05 Panasonic Corporation Reproduction device, program, and reproduction method
US7609947B2 (en) * 2004-09-10 2009-10-27 Panasonic Corporation Method and apparatus for coordinating playback from multiple video sources
KR100657322B1 (ko) * 2005-07-02 2006-12-14 삼성전자주식회사 로컬 3차원 비디오를 구현하기 위한 인코딩/디코딩 방법 및장치
JP4476905B2 (ja) * 2005-08-31 2010-06-09 株式会社東芝 立体表示画像データの構造、立体表示画像データの記録方法、表示再生方法、記録プログラム、および表示再生プログラム
JP5213064B2 (ja) * 2006-03-29 2013-06-19 トムソン ライセンシング マルチビュービデオ符号化方法及びその装置
WO2008038205A2 (en) * 2006-09-28 2008-04-03 Koninklijke Philips Electronics N.V. 3 menu display
WO2008044191A2 (en) * 2006-10-11 2008-04-17 Koninklijke Philips Electronics N.V. Creating three dimensional graphics data
JP4930320B2 (ja) * 2006-11-30 2012-05-16 ソニー株式会社 再生方法及び装置、プログラム並びに記録媒体
WO2008114595A1 (ja) * 2007-03-22 2008-09-25 Mitsubishi Electric Corporation 映像再生装置および映像再生方法
JP2008244835A (ja) 2007-03-27 2008-10-09 Toshiba Corp 立体表示装置および立体画像表示方法
JP2009135686A (ja) * 2007-11-29 2009-06-18 Mitsubishi Electric Corp 立体映像記録方法、立体映像記録媒体、立体映像再生方法、立体映像記録装置、立体映像再生装置
WO2010032399A1 (ja) * 2008-09-18 2010-03-25 パナソニック株式会社 立体視映像再生装置、及び立体視映像表示装置

Also Published As

Publication number Publication date
MX2010011683A (es) 2010-11-30
CN102685515A (zh) 2012-09-19
US20120287127A1 (en) 2012-11-15
EP2521366B1 (en) 2014-09-17
US20110033170A1 (en) 2011-02-10
CN102685514A (zh) 2012-09-19
CN102833572A (zh) 2012-12-19
ZA201106913B (en) 2012-05-30
JP4588120B2 (ja) 2010-11-24
BRPI1001265A2 (pt) 2016-02-16
CN102017641B (zh) 2012-08-22
TW201123841A (en) 2011-07-01
JP5038543B2 (ja) 2012-10-03
US8712215B2 (en) 2014-04-29
JP4629805B2 (ja) 2011-02-09
EP2521365B1 (en) 2014-05-14
EP2521364A1 (en) 2012-11-07
EP2521363B1 (en) 2014-05-14
JP2011097595A (ja) 2011-05-12
CN102790902B (zh) 2014-04-30
US8705935B2 (en) 2014-04-22
JP2010288289A (ja) 2010-12-24
JP2012178847A (ja) 2012-09-13
JP2010288290A (ja) 2010-12-24
EP2521367B1 (en) 2014-05-14
ZA201007461B (en) 2012-01-25
RU2010144544A (ru) 2013-03-27
CN102833573A (zh) 2012-12-19
JP5027953B2 (ja) 2012-09-19
EP2521366A1 (en) 2012-11-07
DK2521364T3 (da) 2014-10-20
EP2521363A1 (en) 2012-11-07
RU2522304C2 (ru) 2014-07-10
US20120293614A1 (en) 2012-11-22
JP5416073B2 (ja) 2014-02-12
CN102685515B (zh) 2013-11-20
EP2400773B1 (en) 2013-11-20
WO2010095411A1 (ja) 2010-08-26
CN102017641A (zh) 2011-04-13
JP2010246157A (ja) 2010-10-28
JP2012157069A (ja) 2012-08-16
ES2491067T3 (es) 2014-09-05
CN102833573B (zh) 2013-09-25
CN102790902A (zh) 2012-11-21
KR20110126518A (ko) 2011-11-23
AU2010216963A1 (en) 2010-08-26
JP2012178848A (ja) 2012-09-13
ES2467149T3 (es) 2014-06-12
JP4634534B2 (ja) 2011-02-16
EP2400773A4 (en) 2012-11-07
CN102833572B (zh) 2013-09-25
CN102685514B (zh) 2014-02-19
ES2439316T3 (es) 2014-01-22
EP2521367A1 (en) 2012-11-07
EP2521364B1 (en) 2014-07-23
JP4654320B2 (ja) 2011-03-16
EP2400773A1 (en) 2011-12-28
EP2521365A1 (en) 2012-11-07
JPWO2010095411A1 (ja) 2012-08-23
ZA201106914B (en) 2012-05-30

Similar Documents

Publication Publication Date Title
JP5027953B2 (ja) 受信装置
JP4701312B2 (ja) 記録媒体、再生装置、記録方法、記録媒体再生システム
JP4564107B2 (ja) 記録媒体、再生装置、システムｌｓｉ、再生方法、記録方法、記録媒体再生システム
JP4733785B2 (ja) ３ｄ映像を再生するための情報記録媒体、記録媒体の記録方法、再生装置、及び記録媒体再生システム
WO2010095410A1 (ja) 記録媒体、再生装置、集積回路
WO2010095381A1 (ja) 記録媒体、再生装置、集積回路

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120529

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120622

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150629

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5027952

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees