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

JPWO2010038365A1 - 記録媒体、再生装置、システムlsi、再生方法、記録方法、記録媒体再生システム - Google Patents

記録媒体、再生装置、システムlsi、再生方法、記録方法、記録媒体再生システム Download PDF

Info

Publication number
JPWO2010038365A1
JPWO2010038365A1 JP2010502593A JP2010502593A JPWO2010038365A1 JP WO2010038365 A1 JPWO2010038365 A1 JP WO2010038365A1 JP 2010502593 A JP2010502593 A JP 2010502593A JP 2010502593 A JP2010502593 A JP 2010502593A JP WO2010038365 A1 JPWO2010038365 A1 JP WO2010038365A1
Authority
JP
Japan
Prior art keywords
stream
playback
view
file
information
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.)
Granted
Application number
JP2010502593A
Other languages
English (en)
Other versions
JP4564107B2 (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
Application granted granted Critical
Publication of JP4564107B2 publication Critical patent/JP4564107B2/ja
Publication of JPWO2010038365A1 publication Critical patent/JPWO2010038365A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/161Encoding, multiplexing or demultiplexing different image signal components
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/003Details of a display terminal, the details relating to the control arrangement of the display terminal and to the interfaces thereto
    • G09G5/005Adapting incoming signals to the display format of the display terminal
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/003Details of a display terminal, the details relating to the control arrangement of the display terminal and to the interfaces thereto
    • G09G5/006Details of the interface to the display terminal
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G11B20/1251Formatting, e.g. arrangement of data block or words on the record carriers on discs for continuous data, e.g. digitised analog information signals, pulse code modulated [PCM] data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/128Adjusting depth or disparity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/172Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/172Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178Metadata, e.g. disparity information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/172Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/183On-screen display [OSD] information, e.g. subtitles or menus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189Recording image signals; Reproducing recorded image signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30Image reproducers
    • H04N13/332Displays for viewing with the aid of special glasses or head-mounted displays [HMD]
    • H04N13/341Displays for viewing with the aid of special glasses or head-mounted displays [HMD] using temporal multiplexing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • H04N21/42646Internal components of the client ; Characteristics thereof for reading from or writing on a non-volatile solid state storage medium, e.g. DVD, CD-ROM
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432Content retrieval operation from a local storage medium, e.g. hard-disk
    • H04N21/4325Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343Extraction or processing of packetized elementary streams [PES]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347Demultiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia components thereof involving special video data, e.g 3D video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00Aspects of data communication
    • G09G2370/10Use of a protocol of communication by packets in interfaces along the display data pipeline
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00Aspects of data communication
    • G09G2370/12Use of DVI or HDMI protocol in interfaces along the display data pipeline
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/10527Audio or video recording; Data buffering arrangements
    • G11B2020/10537Audio or video recording
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/10527Audio or video recording; Data buffering arrangements
    • G11B2020/10537Audio or video recording
    • G11B2020/10592Audio or video recording specifically adapted for recording or reproducing multichannel signals
    • G11B2020/106113D video data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/12Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G11B2020/1218Formatting, e.g. arrangement of data block or words on the record carriers on discs wherein the formatting concerns a specific area of the disc
    • G11B2020/1224Formatting, e.g. arrangement of data block or words on the record carriers on discs wherein the formatting concerns a specific area of the disc extent, i.e. a set of sectors which numbers form a continuous ascending sequence
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2541Blu-ray discs; Blue laser DVR discs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23602Multiplexing isochronously with the video sync, e.g. according to bit-parallel or bit-serial interface formats, as SDI
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605Creation or processing of packetized elementary streams [PES]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365Multiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/765Interface circuits between an apparatus for recording and another apparatus
    • H04N5/775Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/84Television signal recording using optical recording
    • H04N5/85Television signal recording using optical recording on discs or drums
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806Transformation 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 with processing of the sound signal
    • H04N9/8063Transformation 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 with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal

Landscapes

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

Abstract

記録媒体には、レフトビュービデオストリーム及びライトビュービデオストリームは、インターリーブ形式のトランスポートストリームファイルに変換されて記録されている。インターリーブ形式のトランスポートストリームファイルは、ファイル参照情報と同じ識別番号と、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子とによって特定される。インターリーブ形式のトランスポートストリームファイルを構成するエクステントのうち、ライトビュービデオストリーム又はレフトビュービデオストリームに該当するものは、ファイル参照情報と同じ識別番号と、トランスポートストリームファイルである旨を示す拡張子とによって通常形式のトランスポートストリームファイルとして特定される。

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用ディスクとの2種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置(以下、「2D/3D再生装置」)では、2D映像もしくは3D映像として再生できることが求められる。
3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献1に記載されたものがある。
特許第3935507号公報
立体視再生では、レフトビューのビデオストリーム、ライトビューのビデオストリームを記録媒体に記録して、ユーザに視聴させる必要があるが、これらレフトビュービデオストリーム、ライトビュービデオストリームをどのような形式に変換しておくかが問題になる。一般的な記録形式は、レフトビュービデオストリーム、ライトビュービデオストリームをTSパケットレベルで多重化して、1つのトランスポートストリームとして記録するというものであるが、これでは、レフトビュービデオストリーム、ライトビュービデオストリームに割り当てることができるビットレートが低下してしまう。そのため画質の低下が発生しかねない。
ビットレート低下をさけるには、レフトビュービデオストリーム、ライトビュービデオストリームを別々のトランスポートストリームファイルに格納して、レフトビュービデオストリームを光ディスクから供給し、ライトビュービデオストリームをハードディスクから供給するという考えがある。この場合、光ディスク及びハードディスクの双方からTSパケットを供給することができるので、レフトビュービデオストリーム、ライトビュービデオストリームのそれぞれについて、ある程度のビットレートを確保することができる。しかしこの考えは、レフトビュービデオストリームを光ディスクによって供給し、ライトビュービデオストリームをネットワークから供給して、これらを組み合わせてユーザに再生させるという用途には向いているものの、1つの光ディスクに、レフトビュービデオストリーム、ライトビュービデオストリームを格納することができない。よってこの考えは、レフトビュービデオストリーム、ライトビュービデオストリームを1つの光ディスクに記録して、1つの商品として販売したり、店頭でレンタルするというビジネス形態に向いているとはいえず、映画作品の業界からは、余り歓迎されないと思われる。
ビットレートを確保しながらライトビュービデオストリーム、レフトビュービデオストリームを記録する方法には、いわゆるマルチアングル再生で実現されているように、レフトビュービデオストリーム、ライトビュービデオストリームを1つのインターリーブ形式のトランスポートストリームファイルに変換して、光ディスクに記録するという考えがある。
レフトビュービデオストリーム、ライトビュービデオストリームをインターリーブ形式に変換して1つのトランスポートストリームファイルに格納する格納形式においては、レフトビュービデオストリームを構成するエクステントと、ライトビュービデオストリームを構成するエクステントとで、Arrival Time Stamp(ATS)の値が連続になっていないので、再生時にあたっては、ATSが増えては減り、ATSが増えては減るという不規則な変化を繰り返すことになる。これは、通常のビデオストリームのATSの変化、つまり、ATSが単調増加するという変化とは異なるので、2D再生装置によって、かかるインターリーブ形式のトランスポートストリームファイルが2D再生装置による再生に供された場合は、2D再生装置の正常動作を保障できないという危険性がある。
本発明の目的は、3D再生装置と、2D再生装置との双方で再生されることを保障することができる記録媒体を提供することである。
上記課題を解決するため、本発明にかかる記録媒体は、プレイリスト情報と、ストリームファイルとが記録された記録媒体であって、前記プレイリスト情報は、1つ以上の再生区間情報を含み、
前記再生区間情報は、ビデオストリームを格納した前記ストリームファイルを指定するファイル参照情報を含み、
前記ストリームファイルは、インターリーブされたトランスポートストリームファイルと、通常形式のトランスポートストリームファイルであり、
前記インターリーブされたトランスポートストリームファイルは、レフトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分、及び、ライトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分のそれぞれを、交互に配置することで構成されており、前記ファイル参照情報と同じ識別番号と、インターリーブされている旨を示す拡張子とによって特定され、
前記通常形式のトランスポートストリームファイルは、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームの何れか一方であって、単独再生することができるベースビュービデオストリームを格納しており、前記ファイル参照情報と同じ識別番号と、通常形式である旨を示す拡張子とによって特定されることを特徴とする。
本発明では、インターリーブ形式のトランスポートストリームファイルは、ファイル参照情報と同じ識別番号と、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子とによって特定されるので、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のファイル参照情報と、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子とから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供すれば、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。
そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。
また、インターリーブ形式のトランスポートストリームファイルのエクステントのうち、ベースビュービデオストリームのエクステントは、プレイリスト情報に記述されたファイル参照情報と、通常形式のトランスポートストリームファイルである旨を示す拡張子とを用いることにより、アクセスすることができる。インターリーブ形式のトランスポートストリームファイルとは別に平面視のためのトランスポートストリームを記録しなくても、3D再生装置での立体視、2D再生装置で平面視の双方を実現することができるので、BD-ROM一枚に3Dの映画作品を記録してユーザに供給することが可能になる。インターリーブ形式のトランスポートストリームファイルとは別に、平面視のためのトランスポートストリームファイルを記録する必要がないので、3D映像のための記録媒体と、2Dのための記録媒体とを同梱して販売する必要がなく、3D映像のための記録媒体と、2D映像のための記録媒体とを別々の商品として販売にする必要もない。流通コストや小売店・卸売店における在庫管理コストの増大を招くこともないので、映画作品の業界は、既存の2D映像の映画作品を変わらぬ取り扱いをすることができる。
記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。 ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を表す動画像を描いた図である。 立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。 多層化された光ディスクの内部構成を示す。 ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。 記録方法の処理手順を示すフローチャートである。 PESパケット列に、ビデオストリームがどのように格納され、TSパケット及びソースパケットに変換されるかを示す。 AVクリップがどのように多重化されるかを模式的に示す図である。 記録方法により得られたエクステントの内部構成を示す。 エクステントと、トランスポートストリームファイルとの対応付けを示す図である。 インターリーブ形式のトランスポートストリームファイルと、レフトビューのトランスポートストリームファイルとをカップリングする方法について示している。 AVファイル書込行程の処理手順を示すフローチャートである。 クリップ情報ファイルの内部構成を示す図である。 クリップ情報ファイルにおけるストリーム属性情報を示す図である。 クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。 エントリーマップによるエントリーポイントの登録を示す。 2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。 図17の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。 プレイリスト情報のデータ構造を示す図である。 サブパス情報テーブルの内部構成を示す図である。 レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。 ストリーム選択テーブルを示す。 図17の3Dプレイリストに、レフトビュー/ライトビュー識別情報を書き加えた図である。 レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。 2D/3D再生装置の構成を示している。 システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成を示す図である。 プレーン合成部5bの内部構成を示す図である。 PGプレーンの合成の仕方を示す図である。 オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。 レジスタセット10の内部構成及び再生制御エンジン7bの内部構成を示す図である。 出力モードの選択モデルの状態遷移を示す図である。 Initializationの処理手順を示すフローチャートである。 Procedure when playback condition is changedの処理手順を示すフローチャートである。 ストリーム選択プロシージャの処理手順を示すフローチャートである。 プレイリストの再生手順を示すフローチャートである。 再生制御エンジンの状態が停止中から3Dプレイリストに切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 表示装置300、3D眼鏡400の内部構成を示す図である。 3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。 左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替える場合の、マルチチャネルモードにおける表示内容と、レフトビューの状態と、ライトビューの状態とを示す。 再生装置と、表示装置との接続態様を示す図である。 左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。 ビデオストリームとPGストリームとを組み合わせる場合の、組合せ情報の記述例である。 ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。 複数の3D方式を網羅できるPSRのビットアサインを示す図である。 表示装置が対応している3D再生方式をプレーヤセッティングレジスタに反映させる図である。 インデックステーブルと、ムービーオブジェクトとの関係を示している。 ストリーム選択の処理手順を示すフローチャートである。 記録装置の内部構成を示す図である。
(第1実施形態)
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目は、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、1つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
2つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の2つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
図1(a)は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。本図に示すように、記録媒体の一例であるBD-ROM100、再生装置200は、テレビ300、3D眼鏡400、リモコン500と共にホームシアターシステムを構成し、ユーザによる使用に供される。
BD-ROM100は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置200は、テレビ300と接続され、BD-ROM100を再生する。
テレビ300は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置300は、3D眼鏡400をユーザが着用することで立体視を実現するものだが、表示装置300がレンチキュラー方式のものなら、3D眼鏡400は不要となる。レンチキュラー方式の表示装置300は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
3D眼鏡400は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。 図1(b)は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡400は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図(c)は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
リモコン500は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン500は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
以上が、記録媒体及び再生装置の使用形態についての説明である。
本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。
視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図2は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
図3は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。
本図の第2段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。これらのピクチャデータは、Decode Time Stamp(DTS)に従いデコードされる。第1段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。 本図において、参照ピクチャを持たずに符号化対象ピクチャのみを用いてピクチャ内予測符号化を行うピクチャをIピクチャと呼ぶ。ピクチャとは、フレームおよびフィールドの両者を包含する1つの符号化の単位である。また、既に処理済の1枚のピクチャを参照してピクチャ間予測符号化するピクチャをPピクチャとよび、既に処理済みの2枚のピクチャを同時に参照してピクチャ間予測符号化するピクチャをBピクチャと呼び、Bピクチャの中で他のピクチャから参照されるピクチャをBrピクチャと呼ぶ。また、フレーム構造の場合のフレーム、フィールド構造のフィールドを、ここではビデオアクセスユニットと呼ぶ。
第4段目は、レフトビュービデオストリームの内部構成を示す。このレフトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第3段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。
第5段目は、3D眼鏡400の状態をどのように変化させるかを示す。この第5段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。
例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。
このような視点間の相関特性を利用したビデオ圧縮の方法としては、Multiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共同プロジェクトであるJoint Video Team(JVT)は、2008年7月にMultiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。
そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、“ディペンデントビューストリーム”という。

次に、記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。
図4は、多層化された光ディスクの内部構成を示す。
第1段目は、多層化された光ディスクであるBD-ROMを示し、第2段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域から構成される。これらの第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域は、1つの連続した論理アドレス空間を構成する。
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。この一方、記録層の境界のように、連続的な読み出しが不可能な部分については、論理アドレスが連続していないものとする。
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROM100の場合ではUDF(Universal Disc Format)によって記録される。日常使っているPC(パーソナルコンピュータ)の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。
ファイルシステム上でアクセス可能なファイルのうち、ビデオストリーム及びオーディオストリームを多重化することで得られたAVストリームを格納しているファイルを“AVファイル”という。一方、AVストリーム以外の一般的なデータを格納しているファイルを“非AVファイル”という。
ビデオストリーム、オーディオストリームを始めとするPacktized Elementaryストリーム(PESストリーム)が、TSパケットに変換された上で多重化されているため、AVストリームがトランスポートストリーム形式になっているAVファイルを、「トランスポートストリームファイル」という。
これとは異なり、ビデオストリーム、オーディオストリームを始めとするPESストリームが、パック列に変換された上で多重化されているため、AVストリームがシステムストリーム形式になっているAVファイルを、「システムストリームファイル」という。
BD-ROM、BD-RE、BD-Rに記録されるAVファイルは、前者のトランスポートストリームファイルである。DVD-Video、DVD-RW,DVD-R,DVD-RAMに記録されるAVファイルは、後者のシステムストリームファイルであり、Video Objectとも呼ばれる。
第4段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第5段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。

図5は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。

BDMVディレクトリはBD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる5つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」,「MovieObject.bdmv」の2種類のファイルが配置されている。
「index.bdmv(ファイル名固定)」は、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BD-Jオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納している。インデックステーブルはBD-ROM全体に関する管理情報であり、再生装置へのディスク挿入後に、index.bdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルはBD-ROMに格納されるすべてのタイトル、トップメニュー、FirstPlayといったタイトル構成を定義する最上位層のテーブルである。インデックテーブルには、一般のタイトル、トップメニュータイトル、FirstPlayタイトルから最初に実行されるプログラムファイルが指定されている。BD-ROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにインデックステーブルを参照して、所定のプログラムファイルを実行する。ここで、FirstPlayタイトルとは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるプログラムファイルが設定されている。また、トップメニュータイトルは、リモコンでのユーザ操作で、「メニューに戻る」というようなコマンドが実行されるときに、呼び出されるムービーオブジェクト、BD-Jオブジェクトが指定されている。立体視に関する情報としてIndex.bdmvは、Initial_output_mode情報を有する。このInitial_output_mode情報は、Index.bdmvがロードされた場合に、再生装置の出力モードの初期状態がどうあるべきかを規定する情報であり、制作者サイドが希望する出力モードを、このInitial_output_mode情報に規定しておくことができる。
「MovieObject.bdmv(ファイル名固定)」は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。
「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo[“xxxxx”は可変、拡張子”bdjo”は固定])が存在する。このプログラムファイルは、バイトコードインタプリタであるJava(登録商標)仮想マシンを制御主体とした動作モード(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”は固定])が存在する。
“プレイリスト”とは、AVストリームの時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、複数のAVストリームのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報ファイルは、かかるプレイリストの“型”を定義するプレイリスト情報を格納している。再生制御のためのJava(TM)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(TM)仮想マシンに命じることで、AV再生を開始させることができる。JMF(Java Media Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi [“xxxxx”は可変、拡張子”clpi”は固定])が存在する。
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、トランスポートストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts([“xxxxx”は可変、拡張子”m2ts”は固定])という形式でトランスポートストリームファイルが格納される。
STREAMディレクトリにおけるトランスポートストリームファイルは、AVクリップを格納している。“AVクリップ”とは、AVストリームの“切れ端”のことであり、ビデオストリーム、オーディオストリーム、グラフィクスストリーム等、複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を可能するものをいう。AVクリップは、1秒,5秒,1分等、長短に拘らず、時間軸上において、ある限られた時間の再生を保障するものであれば足りる。
また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に対応するストリームの属性情報を持ち、またAVクリップに関する各種ディスクリプタを持つ。ディスクリプタにはトランスポートストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。
PMTの先頭には、そのPMTに含まれるデータの長さなどを記したPMTヘッダが配置される。その後ろには、AVクリップに関するディスクリプタが複数配置される。前述したコピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、トランスポートストリームファイルに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのPID、ストリームの属性情報(フレームレート、アスペクト比など)が記載されたストリームディスクリプタから構成される。ストリームディスクリプタはAVクリップに存在するストリームの数だけ存在する。
PAT(Program Association Table)は、AVクリップ中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルトランスポートストリームを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルトランスポートストリームを扱うかの如く、AVクリップをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、BD-ROM再生装置との互換性を意図したものである。
またAVクリップのうち、レフトビュービデオストリームの分割部分を格納したパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したパケット等、レフトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を保障するものを、“レフトビューAVクリップ”という。このレフトビューAVクリップが、ベースビュービデオストリームを含んでおり平面視再生を可能とするものなら、当該レフトビューAVクリップは、“2D/レフトビューAVクリップ”と称呼される。尚以降の説明では、特に断らない限り、レフトビュービデオストリームがベースビュービデオストリームであり、レフトビュービデオストリームを含むレフトビューAVクリップは、2D/レフトビューAVクリップであるものとする。
更にAVクリップのうち、ライトビュービデオストリームの分割部分を格納したソースパケット、ライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間の連続再生を保障するものを、“ライトビューAVクリップ”という。
CLIPINFディレクトリに格納されるクリップ情報ファイルとは、レフトビューAVクリップ又はライトビューAVクリップが、どのようなパケットの集合体であるか等、AVクリップの詳細を、個々のAVクリップ毎に示した情報であり、対応するAVクリップの再生に先立ちメモリに読み出され、そのAVクリップの再生が継続している間、再生装置内で参照に供される情報である。
以上が記録媒体の内部構成についての説明である。続いて、図4及び図5に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマッティングレコーディングによる記録方法によっても特定されるものでもある。
図6は、記録方法の処理手順を示すフローチャートである。
ステップS301は、BD-ROMのタイトル構造を決定する行程である。これによりタイトル構造情報が作成される。タイトル構造情報とは、木構造を用いて、BD-ROMにおける再生単位の関係、例えば、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する情報である。具体的にいうと、タイトル構造情報は、制作しようとするBD-ROMの「ディスク名」に対応するノード、そのBD-ROMにおいて、Index.bdmvから再生可能となる「タイトル」に対応するノード、そのタイトルを構成する「ムービーオブジェクト及びBD-Jオブジェクト」に対応するノード、当該ムービーオブジェクト及びBD-Jオブジェクトから再生される「プレイリスト」のノードを規定して、これらノードを、エッジ(辺)で結び付けることで、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する。
ステップS302は、タイトルに利用する動画、音声、静止画、字幕情報のインポートを行う行程である。
ステップS303は、GUIを経由したユーザ操作に従った編集処理をタイトル構造情報に施すことにより、BD-ROMシナリオデータを作成する行程である。ここでBD-ROMシナリオデータとは、AVストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、BD-ROMではインデックステーブル、ムービーオブジェクト、プレイリストとして定義されている情報がシナリオにあたる。BD-ROMシナリオデータには、ストリームを構成する素材情報、再生区間、再生経路を示す情報、メニュー画面配置、メニューからの遷移情報などを含む。
ステップS304は、エンコード行程であり、BD-ROMシナリオデータに基づきエンコードを行って、PESストリームを得る。
ステップS305は、BD-ROMシナリオデータに従った多重化行程であり、この行程によってPESストリームを多重化してAVクリップを得る。
ステップS306では、BD-ROMへの記録のためのデータベースを得る。ここでのデータベースとは、前述のBD-ROMで定義されるインデックステーブル、ムービーオブジェクト、プレイリスト、BD-Jオブジェクトなどの総称である。
ステップS307では、Java(TM)プログラム、多重化行程で得られたAVクリップ、BD-ROMデータベースを入力とし、BD-ROMに準拠したファイルシステムフォーマットでAVファイル,非AVファイルを作成する。
ステップS308は、BD-ROMに記録されるべきデータのうち、非AVファイルの書込行程であり、ステップS309は、AVファイルの書込行程である。
ステップS305の多重化行程は、ビデオストリーム、オーディオストリーム、グラフィクスストリームをPESストリームに変換した上、トランスポートストリームに変換する第1変換行程、トランスポートストリームを構成する個々のTSパケットを、ソースパケットに変換する第2変換行程を含み、動画像、音声、グラフィクスを構成するソースパケット列を、多重化するものである。
ステップS309のAVファイル書き込み行程は、ソースパケット列をAVファイルのエクステントとして、記録媒体の連続領域に書き込むものである。
書き込みの対象となるストリームは、以下の通りである。
・ビデオストリーム
ビデオストリームは映画のプライマリビデオおよびセカンダリビデオを示す。ここでプライマリビデオとはピクチャインピクチャにおいて親画像として表示される通常の映像を示し、セカンダリビデオとは、ピクチャインピクチャにおいて小画面で表示される映像のことである。プライマリビデオには、レフトビュービデオ、ライトビュービデオの2種類があり、セカンダリビデオにも、レフトビュービデオ、ライトビュービデオの2種類がある。
ビデオストリームは、上述したMVCの他、MPEG-2、MPEG-4AVC、または、SMPTE VC-1などの方式を使って符号化記録されている。
・オーディオストリーム
オーディオストリームは、映画の主音声部分を示す。オーディオストリームは、ドルビーAC-3、Dolby Digital Plus、MLP、DTS、DTS-HD、または、リニアPCMのなどの方式で圧縮・符号化記録されている。オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの2種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。
・Presentation Graphicsストリーム
Presentation Graphicsストリーム(PGストリーム)は、映画の字幕や、キャラクタ等、ピクチャと緻密に同期すべきグラフィクスを示すグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。
PGストリームは、PCS(Presentation Control Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(Object Define Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。
WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS(Pallet Define Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
グラフィクスストリームの再生において、グラフィクスデコーダは、ある表示単位に属するODSをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行表示単位に属するODSをデコードすることにより得られたグラフィクスオブジェクトをプレーンメモリに書き込む処理とをパイプラインで実行し、ハードウェアをフル駆動することで、上述したような緻密な同期を実現する。
トランスポートストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。このPGストリームと、textSTストリームとの組みは、BD-ROM規格において、“PGTextSTストリーム”と呼ばれる。
・Interactive Graphicsストリーム
Interactive Graphicsストリーム(IGストリーム)は、リモコンを通じた対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(Interactive Composition Segment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)と呼ばれる機能セグメントからなる。ODS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(Interactive Composition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。インタラクティブグラフィックスストリームは、画面上にGUI部品を配置することにより作成される対話画面を示している。
図7(a)は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目はビデオストリームのビデオフレーム列を示す。第2段目は、PESパケット列を示す。第3段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy1,yy2, yy3, yy4に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS(Presentation Time-Stamp)やピクチャの復号時刻であるDTS(Decoding Time-Stamp)が格納される。

<TSパケット列>
図7(b)は、AVクリップに最終的に書き込まれるTSパケットの形式を示している。第1段目は、TSパケット列を示し、第2段目は、ソースパケット列を示す。第3段目は、AVクリップを示す。
第1段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ4Byteの「TSヘッダ」とデータを格納する184Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第2段目によると、TSパケットには、4ByteのTP_Extra_Headerが付与されて、192Byteのソースパケットに変換された状態で、AVクリップに書き込まれる。TP_Extra_HeaderにはATS(Arrival_Time_Stamp)などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。AVクリップには、第3段目に示すようにソースパケットが並ぶこととなり、AVクリップの先頭からインクリメントする番号はSPN(ソースパケットナンバー)と呼ばれる。
<AVクリップにおける多重化>
図8は、レフトビューAVクリップがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを(第1段目)、それぞれPESパケット列に変換し(第2段目)、ソースパケット列に変換する(第3段目)。同じくレフトビュープレゼンテーショングラフィックスストリームおよびレフトビューインタラクティブグラフィックス(第7段目)を、それぞれPESパケット列に変換し(第6段目)、更にソースパケット列に変換する(第5段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、レフトビューAVクリップが得られることになる。このレフトビューAVクリップは、リードバッファがアンダーフローしないサイズに定められており、記録媒体への記録の対象になる。
Arrival Time Clock(ATC)時間軸において、ATSが連続しているソースパケットの集まりをATCシーケンスといい、System Time Clock(STC)時間軸においてデコードタイムスタンプ(DTS),プレゼンテーションタイムスタンプ(PTS)が連続しているソースパケットの集まりを、STCシーケンスという。
図9は、記録方法により得られたエクステンを示す。第1段目は、AVファイルを構成するエクステントEXT_L[i],EXT_L[i+1],EXT_R[i],EXT_R[i+1]を示す。
第2段目は、各エクステント内に属するソースパケット列を示す。
この第1段目におけるエクステントは、ライトビューAVクリップを構成するソースパケットのグループと、レフトビューAVクリップを構成するソースパケットのグループとを、インターリーブ配置したものである。本図におけるインターリーブ配置とは、ライトビューAVクリップを構成するソースパケット集合と、レフトビューAVクリップを構成するソースパケット集合とが、一個のエクステントとして、"ライトビュー"、"レフトビュー"、"ライトビュー"、"レフトビュー"・・・・・という規則性をもって記録されていることである。
ここで、括弧書きにおける変数i,i+1は、何番目のエクステントとして再生されるかを示す。この記法からすると、変数iによって指示される2つのエクステント、つまり、EXT_L[i],EXT_R[i]は同時に再生され、変数i+1によって指示される2つのエクステント、つまり、EXT_L[i+1],EXT_R[i+1]は同時に再生されることがわかる。
エクステントEXT_L[i]のサイズをSEXT_L[i]と呼び、エクステントEXT_R[i]のサイズをSEXT_R[i]と呼ぶ。
これらSEXT_L、SEXT_Rのサイズをどのように定めるかについて説明する。ここでのエクステントは、再生装置においてライトビュー用リードバッファ、レフトビュー用リードバッファという2つのバッファに交互に読み出されてビデオデコーダに供される。そうすると、SEXT_L、SEXT_Rのサイズは、ライトビュー用リードバッファ及びレフトビュー用リードバッファをバッファフルにする時間を考慮して定める必要がある。つまり、ライトビュー用リードバッファへの転送レートを、Rmax1とすると、

ライトビュー用リードバッファ=Rmax1×"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"

という関係を満たすよう、ライトビュー用リードバッファの容量を定めねばならない。ここでジャンプとは、ディスクシークと同義である。何故なら、BD-ROMにおいて記録に確保できる連続領域は有限であり、レフトビュービデオストリーム及びライトビュービデオストリームは、必ずしも、隣合わせで記録されるとは限らず、飛び飛びの領域に記録されることも有り得るからである。
続いて"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"について考える。レフトビュー用リードバッファにおけるTSパケット蓄積は、Rud-Rmax2という転送レートでなされる。これは、レフトビュー用リードバッファからの出力レートRmax2と、レフトビュー用リードバッファへの入力レートRudとの差分を意味する。そうすると、レフトビュー用リードバッファをフルにする時間は、RB2/(Rud-Rmax2)となる。

レフトビュー用リードバッファにデータを読み出すにあたっては、ライトビューAVクリップからレフトビューAVクリップへのジャンプ時間(Tjump)と、レフトビューAVクリップからライトビューAVクリップへのジャンプ時間(Tjump)とを考慮する必要があるので、
レフトビュー用リードバッファの蓄積には(2×Tjump+RB2/(Rud-Rmax2))という時間が必要になる。
ライトビュー用リードバッファの転送レートをRmax1とすると、上述したレフトビュー用リードバッファの蓄積時間において、Rmax1という転送レートで、ライトビュー用リードバッファ内の全てのソースパケットは出力されねばならないから、ライトビュー用リードバッファのサイズRB1は、

RB1≧Rmax1×[2×Tjump+RB2/(Rud-Rmax2)]

になる。

同様の手順で、レフトビュー用リードバッファの容量RB2を求めると、

RB2≧Rmax2×[2×Tjump+RB1/(Rud-Rmax1)]

になる。
ライトビュー用リードバッファ,レフトビュー用リードバッファのメモリサイズの具体的な値としては、1.5Mbyte以下であり、本実施形態においてエクステントサイズSEXT_R、SEXT_Lは、このライトビュー用リードバッファ,レフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。以上がレフトビューAVクリップ、ライトビューAVクリップの記録のされ方についての説明である。続いて、レフトビューAVクリップ及びライトビューAVクリップの内部構成について説明する。図9の第1段目を参照しながら、エクステントEXT_R[i]、エクステントEXT_L[i]の内部構成について説明する。
エクステントEXT_L[i]は、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはPMTを構成し、0x1001のパケットIDをを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケットはレフトビュービデオストリーム、
0x1220〜123FのパケットIDを有するソースパケットはレフトビューPGストリーム、
0x1420〜143FのパケットIDを有するソースパケットは レフトビューIGストリーム
0x1100から0x111FまでのPIDを有するソースパケットはオーディオストリームを構成する。
エクステントEXT_R[i]は、以下のソースパケットによって構成されている。
Ox1012のTSパケットはライトビュービデオストリームを構成し、Ox1240〜125FのソースパケットはライトビューPGストリームを構成し、Ox1440〜145FのソースパケットはライトビューIGストリームを構成する。
(ボリューム領域におけるエクステントの位置付け)
エクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号(LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号(LBN)を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。
「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261”が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号(LBN)を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位2ビットは、“0”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“1”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“0”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
上述したようなファイルエントリーのアロケーション識別子を参照することで、プレイリスト情報ファイル、クリップ情報ファイル、トランスポートストリームファイル、BD-Jオブジェクトファイル、JARアーカイブファイルを構成するエクステントのアドレスを知得することができる。
本願の主眼となるトランスポートストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
上述したようなAVストリーム、Index.bdmv、JARファイル、BD-Jオブジェクトは、ファイル構造、ディレクトリ構造に従ってBD-ROMに記録されているので、再生装置は、ファイルオープンのためのシステムコールを行うことで、これらをメモリに読み出すことができる。
ファイルオープンとは、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCB(File Control Block)を確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。そして、このファイルオープンにあたって、拡張子がm2tsのトランスポートストリームファイルは、STREAMディレクトリを用いたファイルパスによって特定される。拡張子がssifのトランスポートストリームファイルは、STEAMディレクトリと、SSIFディレクトリとを用いたファイルパスによって特定されることになる。これらは、STEAMディレクトリ、SSIFディレクトリに配置されているからである。
上述したようなファイル構造において、図9に示したエクステントがどのように取り扱われているかについて説明する。
図10は、エクステントと、トランスポートストリームファイルとの対応付けを示す図である。
第1段目は、通常のトランスポートストリーム形式のトランスポートストリームファイルである00001.m2ts,00002.m2tsを示し、第2段目は、ライトビューのエクステント、レフトビューのエクステントを示す。第3段目は、インターリーブ形式のトランスポートストリームファイルである00001.ssifを示す。
破線の矢印h1,h2,h3,h4は、エクステントEXT_L[i],EXT_L[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT_L[i],EXT_L[i+1]は、00001.m2tsのエクステントとして登録されていることがわかる。
矢印h3,h4に示される帰属関係によると、エクステントEXT_R[i],EXT_R[i+1]は、00002.m2tsのエクステントとして登録されていることがわかる。
矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT_R[i],EXT_L[i],EXT_R[i+1],EXT_L[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT_L[i],EXT_L[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この“ssif”という拡張子は、StereoScopic Interleave Fileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。
図11は、対応するレフトビューAVクリップと、ライトビューAVクリップとをカップリングする方法について示している。
同図(a)は、トランスポートストリームファイルが、どのようなエクステントによって構成されているかを示す。
これらのうち、エクステントEXT_L[i],EXT_L[i+1]は、2D映像として再生されるものである。
3D映像を含むBD-ROMであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2DのAVクリップにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。
1つ目の方法は、レフトビューは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のトランスポートストリームファイルは拡張子を変える方法である。同図(b)における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名“00001”によってカップリングされている。
プレイリストはレフトビューのAVクリップしか参照しないため、既存の2D再生装置では2D用のAVクリップしか再生しない。3D対応の再生装置は、プレイリストはレフトビューの入ったAVクリップしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のトランスポートストリームファイルであると判断して、レフトビューとライトビューとを出力する。
2つ目の方法は、フォルダを分ける方法である。レフトビューは既存のフォルダ名(例:STREAM)を持つフォルダ内に格納しておくが、拡張であるライトビューは、3D特有の名前を持つフォルダ(例:SSIF)に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照する際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、レフトビューとライトビューを関連づけることが可能となる。
3つ目の方法は、識別番号によるものである。レフトビューの識別番号が“00001”である場合、ライトビューの識別番号は、このレフトビューの識別番号に“1”を加算した番号、つまり、“0002”という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。この例ではレフトビューの識別番号に“1”を加算したものをライトビューの識別番号としたが、レフトビューの識別番号に、“10000”を加算したものをライトビューの識別番号として採用してもよい。
この例では、既存の2D再生装置が再生する映像はレフトビューであるとして記載しているが、実際はどちらでもよく、また、プレイリスト内にどちらの映像が規定映像として再生されているか識別するための情報があってもよい。
カップリング方式を実現する場合には、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。
以上がAVクリップを格納したトランスポートストリームファイルについての説明である。続いて、上述したようなトランスポートストリームファイルをどのようにして記録媒体に記録するか、つまり、AVファイルをAVデータ領域に書き込むための行程(AVファイル書込行程)の詳細について説明する。
図12は、AVファイル書込行程の処理手順を示すフローチャートである。
ステップS401において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップS402は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップS403〜ステップS408を実行する。確保し得ない場合は、ステップS409で例外処理をした後、記録方法を終了する。
ステップS403〜ステップS408は、ステップS407がNoと判定されるまで、ステップS403〜ステップS406、ステップS408の処理を繰り返すループを構成している。
ステップS403において、空きの連続セクタ領域にレフトビューAVクリップを構成するソースパケット列をSEXT_L[i]だけ書き込み、ステップS404において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。
ステップS405において、空きの連続セクタ領域にライトビューAVクリップを構成するソースパケット列をSEXT_R[i]だけ書き込み、ステップS406において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。
ステップS407は、ループの終了条件を規定するものであり、ライトビューAVクリップ、レフトビューAVクリップに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップS408に移行して、ループを係属する。存在しなければ、ステップS410に移行する。
ステップS408は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップS403に移行し、存在しなければ、ステップS402まで戻る。
ステップS410では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップS411では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップS412では、レフトビューAVクリップ、ライトビューAVクリップのうち、ベースビュービデオストリームを含むもののエクステントの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップS412では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。
以上がAVファイル書込行程についての説明である。続いてクリップ情報ファイルについて説明する。
<クリップ情報ファイル>
図13は、クリップ情報ファイルの内部構成を示す図である。クリップ情報ファイルは、本図に示すようにAVクリップの管理情報であり、AVクリップと1対1に対応している。引き出し線ch1は、クリップ情報ファイルの内部構成をクローズアップして示している。この引出線に示すように、クリップ情報ファイルは、「クリップ情報」と、「ストリーム属性情報」と、「エントリマップテーブル」と、「3Dメタデータ」とから構成される。
クリップ情報は、引出線ch2に示すように「システムレート」、「再生開始時間」、「再生終了時刻」から構成されている。システムレートはAVクリップを構成するTSパケットを、後述するシステムターゲットデコーダのPIDフィルタに転送するための最大転送レートを示す。AVクリップ中に含まれるATSの間隔はシステムレート以下になるように設定されている。再生開始時間はAVクリップの先頭のビデオフレームのPTSであり、再生終了時間はAVクリップの終端のビデオフレームのPTSに1フレーム分の再生間隔を足したものが設定される。
図14は、クリップ情報ファイルにおけるストリーム属性情報を示す図である。
図中の引き出し線ah1は、ストリーム属性情報の内部構成をクローズアップして示している。
この引出線に示すように、PID=0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性情報、PID=0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性情報、PID=0x1100、PID=0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性情報、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性情報というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性情報に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。
図15は、クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。
本図(a)は、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、『エントリマップヘッダ情報』、『エクステント開始タイプ』、『PID=0x1011についてのエントリーマップ』、『PID=0x1012についてのエントリーマップ』、『PID=0x1220についてのエントリーマップ』、『PID=0x1221についてのエントリーマップ』を含む。
『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。
『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。
『PID=0x1011についてのエントリーマップ』、『PID=0x1012についてのエントリーマップ』、『PID=0x1220についてのエントリーマップ』、『PID=0x1221についてのエントリーマップ』は、複数種別のソースパケットによって構成されるPESストリームのそれぞれについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報を“エントリポイント”と呼ぶ。また先頭を“0”として各エントリポイント毎にインクリメントした値をエントリポイント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ピクチャが存在する場合、このフラグはオフに設定される。
同図(b)は、(a)に示した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と対応付けている。
図16は、エントリーマップによるエントリーポイントの登録を示す。第1段目は、STCシーケンスにて規定される時間軸を示す。第2段目は、クリップ情報におけるエントリーマップを示す。第3段目は、STCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうち=n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける=n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち=n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおける=n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するAVクリップのファイル位置を特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。
以上がエントリーマップテーブルについての説明である。続いて、3Dメタデータの詳細について説明する。
3Dメタデータとは、立体視再生に必要となる様々な情報を規定したメタデータ群であり、複数のオフセットエントリーを含む。個々のオフセットエントリーは、複数のPID、複数の表示時刻に対応付けられている。そしてあるPIDのPESストリームを再生する際、そのPESストリームの複数の表示時刻において、どれだけのオフセットを用いて、立体視を実現すべきかをPID毎及び表示時刻毎に規定できるようになっている。
以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
デコーダや表示プレーンの構成が異なるため、2D再生、3D再生の切り替えをシームレスに行うことは困難である。そのため、シームレスな切り替えが発生する可能性があるプレイアイテム同士において、2Dと3Dの切り替えを行うことは難しい。
図17は、2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。混在をなくすことにより、再生装置の再生環境の切り替えを発生させないようにしている。本図のプレイリストは、「メインパス」、1つ以上の「サブパス」から構成される。
「メインパス」は、1つ以上のプレイアイテムから構成される。図中の例では、プレイアイテム#1、#2、#3から構成されていることがわかる。
「サブパス」は、メインパスと一緒に再生される一連の再生経路を示し、プレイリストに登録される順にID(サブパスID)が振られる。サブパスIDは、サブパスを識別するために使われる。サブパスには、メインパスの再生に同期して再生される同期型、メインパスの再生に非同期で再生可能な非同期型があり、そのタイプはサブパスタイプに記される。サブプレイアイテムは、1つ以上のサブプレイアイテム情報から構成される。
また「プレイアイテム」は、ストリーム選択テーブルを含む。ストリーム選択テーブルは、プレイアイテム及びサブプレイアイテムにおいて再生が許可されているエレメンタリストリームのストリーム番号を示す情報である。プレイリスト情報、プレイアイテム情報、サブプレイアイテム情報、ストリーム選択テーブルの詳細については、後の実施形態に説明の場を譲る。
「AVクリップ#1,#2,#3」は、2D映像として再生されるAVクリップであるとともに、3D映像として再生する時にはレフトビューとして再生されるAVクリップである。
「AVクリップ#4,#5,#6」は3D映像として再生する時にはライトビューとして再生されるAVクリップである。
2Dプレイリストのメインパスは、レフトビューAVクリップを格納するAVクリップ#1,#2,#3を符号rf1,2,3に示すように参照している。
3Dプレイリストは、レフトビューAVクリップを符号rf4,rf5,rf5に示すように参照しているプレイアイテムを含むメインパスとともに、ライトビューを格納するためのサブパスが用意されていて、このサブパスが、ライトビューを格納するAVクリップ#4,#5,#6を、符号rf7,8,9に示すように参照している。このサブパスは、メインパスと時間軸上で同期するように設定される。この構造により、2Dプレイリストと3Dプレイリストで、レフトビューが格納されたAVクリップを共有することができ、3Dプレイリストではレフトビューとライトビューを時間軸上で同期させて関連付けることができる。
本図の3Dプレイリスト、2Dプレイリストは何れもプレイアイテム情報#1〜#3が、共通のAVクリップであるAVクリップ#1〜#3を参照しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。
図18は、図17の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図17のプレイリストは、サブパスID=0のサブパスのみを具備していたのに対して、図18のプレイリストにおける2つ目のサブパスは、サブパスID”=1”によって識別されるものであり、AVクリップ#7、#8、#9を参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、AVクリップ群がその角度の数だけ用意されていて、角度ごとにサブパスを設けている。
図18の例では、AVクリップ#1,#2,#3とAVクリップ#4,#5,#6は共にライトビューを格納しているが、右目から被写体を見る角度が異なる。サブパスIDが「0」のサブパスはAVクリップ#4,#5,#6を符号rf7,8,9に示すように参照し、サブパスIDが「1」のサブパスはAVクリップ#7,#8,#9を符号rf10,rf11,rf12に示すように参照する。表示装置の画面の大きさやユーザからの嗜好に基づいて、レフトビューを格納するメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。
この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図18の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。
図19は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、「メインパス情報」、「サブパス情報テーブル」、「エクステンションデータ」、「マーク情報」を含む。
先ず始めに、メインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報#1・・・・#Nから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線mp2によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVクリップの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVクリップの符号化方式を示す『Clip_codec_identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection_condition』と、このPlayItemが対象としているSTC_Sequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO_mask_table』と、『STN_table』と、『レフトビュー/ライトビュー識別情報』と、『multi_clip_entry』とから構成される。
以降、『STN_table』、『レフトビュー/ライトビュー識別情報』、『multi_clip_entry』について説明する。
『STN_table(STream Number_table)』は、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。このSTN_tableは、2D再生のためのものであり、3D再生のためのSTN_tableは別に存在する。
『レフトビュー/ライトビュー識別情報』は、レフトビュービデオストリーム、ライトビュービデオストリームのうち、どちらかベースビュービデオストリームであるかを指定するベースビュービデオストリーム指定情報であり、0ならばレフトビュービデオストリームが、ベースビュービデオストリームであることを示し、1ならばライトビュービデオストリームがライトビュービデオストリームであることを示す。
『connection_condition』は、前方プレイアイテムと接続タイプを示している。プレイアイテムのconnection_conditionが「1」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレス接続が保証されないことを示す。プレイアイテムのconnection_conditionが「5」か「6」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレスに接続されることが保証される。
connection_conditionが「5」の場合は、プレイアイテム間でSTCの連続性が途切れていても良く、つまり、接続前プレイアイテムのAVクリップ終端のビデオ表示時刻よりも、接続後プレイアイテムのAVクリップ先頭のビデオ表示時刻開始時刻は不連続でよい。ただし、接続前プレイアイテムのAVクリップを後述するシステムターゲットデコーダのPIDフィルタに入力した後に続けて、接続後プレイアイテムのAVクリップをシステムターゲットデコーダのPIDフィルタに入力して再生したときに、システムターゲットデコーダのデコードが破綻しないようにAVクリップを作成する必要がある。また接続前プレイアイテムのAVクリップのオーディオの終端フレームと、接続後プレイアイテムのオーディオの先頭フレームは再生時間軸で重ならなければならないなどの制約条件がある。
また、connection_conditionが「6」の場合は、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップを結合したときに1本のAVクリップとして再生できなければならない。つまり、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップ間でSTCは連続し、またATCも連続する。
『Multi_clip_entries』は、プレイアイテムでマルチアングル区間を形成する場合、個々のアングル映像を表すAVクリップがどれであるかを特定するための情報である。
以上がメインパス情報についての説明である。続いて、サブパス情報テーブルの詳細について説明する。
図20は、サブパス情報テーブルの内部構成を示す図である。引き出し線su1は、サブパス情報の内部構成をクローズアップして示している。引出線su1に示すように、サブパス情報テーブルは複数のサブパス情報1,2,3・・・mを含む。これらのサブパス情報は、1つのクラス構造体から派生した複数のインスタンスであり、その内部構成は共通のものなる。引き出し線su2は、Subpath情報の共通の内部構成をクローズアップして示している。この引き出し線に示すように、各Subpath情報は、サブパスの類型を示すSubPath_typeと、1つ以上のサブプレイアイテム情報(・・・サブプレイアイテム情報#1〜VOB#m・・・)とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、サブプレイアイテム情報は、『Clip_information_file_name』、『Clip_codec_identifier』、『ref_to_STC_id[0]』、『SubPlayItem_In_time』、『SubPlayItem_Out_time』、『sync_PlayItem_id』、『sync_start_PTS_of_PlayItem』からなる。以降、SubPlayItemの内部構成について説明する。
『Clip_information_file_name』は、クリップ情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip_codec_identifier』は、AVクリップの符号化方式を示す。
『ref_to_STC_id[0]』は、このSubPlayItemが対象としているSTC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。
『SubPlayItem_Out_time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
『sync_PlayItem_id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem_In_timeは、このsync_PlayItem_idで指定されたPlay Itemの再生時間軸上に存在する。
『sync_start_PTS_of_PlayItem』は、sync_PlayItem_idで指定されたPlay Itemの再生時間軸上において、SubPlayItem_In_timeで指定されたSubPlayItemの始点が、どこに存在するかを45KHzの時間精度で示す。
図21は、レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。本図は、図16をベースとして作図されており、このベースとなる図の第2段目の時間軸に、PlayItemのIn_Time及びOut_Timeを描いている。第1段目の時間軸に、SubPlayItemのIn_Time及びOut_Timeを描いている。第3段目から第5段目は、図16の第3段目から第5段目と同一である。レフトビュー、ライトビューのIピクチャは、時間軸において同じ時点になる。以上がプレイリスト情報のデータ構造についての説明である。
以上がサブパス情報についての説明である。続いて、エントリーマーク情報の詳細について説明する。
エントリマーク情報はプレイアイテムで定義される再生区間内に対して付与することでき、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマークをチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。
以上がエントリーマーク情報についての説明である。続いて、エクステンションデータの詳細について説明する。
エクステンションデータは、2Dプレイリストとは互換がない、3Dプレイリスト特有の拡張部分であり、ここにSTN_table_SS#1〜#Nが格納される。STN_table_SSは、それぞれが複数のプレイアイテム情報のそれぞれに対応していて、3D再生用のストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_table_SSにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。プレイアイテム情報内のSTN_tableと、エクステンションデータ内のSTN_table_SSとを組合せることで、ストリーム選択テーブルが構成されることになる。
続いて、上述したPlayItem情報の内部構成のうち、ストリーム選択テーブルの詳細について説明する。
図22(a)は、ストリーム選択テーブルを示す。ストリーム選択テーブルは、複数のストリームエントリから構成される。このストリームエントリーは、図中の括弧記号“}”に示すように、STN_table内で定義されるものと、STN_table_SS内で定義されるものとがある。
STN_tableのストリームエントリーには、2D出力モードの設定時において、再生可能となる2D用の音声/PG/IGが登録される。そのため、STN_tableの中には、2Dビデオストリームエントリー群、2Dオーディオストリームエントリー群、2DPGストリームエントリー群、2DIGストリームエントリー群が存在しており、これらのストリーム群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。
STN_table_SSのストリームエントリーには、立体視再生モードの設定時において、再生可能となる3D用の音声/PG/IGが登録される。そのため、STN_table_SSの中には、3Dビデオストリームエントリー群、3Dオーディオストリームエントリー群、3DPGストリームエントリー群、3DIGストリームエントリー群、ストリーム組合せ情報が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。
同図(b)は、ストリームエントリーの共通構成を示す図である。本図に示すように、ストリーム選択テーブルにおけるストリームエントリは、『ストリーム選択番号』、『ストリームパス情報』、『ストリーム識別情報』から構成される。
『ストリーム選択番号』は、ストリーム選択テーブルに含まれるストリームエントリ1の先頭から順にインクリメントされる番号であり、再生装置でのストリーム識別のために利用される。
『ストリームパス情報』は、ストリーム識別情報によって示されるストリームが、どのAVクリップに多重化されているかを示す情報であり、例えば”メインパス”であれば、該当するプレイアイテムのAVクリップを示し、”サブパスID=1”であれば、そのサブパスIDが示すサブパスにおいて、該当するプレイアイテムの再生区間に対応するサブプレイアイテムのAVクリップを示す。
『ストリーム識別情報』は、PIDなどの情報であり、参照するAVクリップに多重化されているストリームを示す。また、ストリームエントリには、各ストリームの属性情報も同時に記録されている。ここで属性情報とは、各ストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。
STN_table_SSにおいて、レフトビュービデオストリームのストリームエントリとライトビュービデオストリームのストリームエントリとでは、例えばフレームレートや解像度、ビデオフォーマットなどは同じ値になる。ストリームエントリには、レフトビュービデオストリームなのか、ライトビュービデオストリームなのかが分かるフラグが用意されることがある。
以上がストリーム選択テーブルについての説明である。続いて、レフトビュー/ライトビュー識別情報の詳細について説明する。
ここまでの記載は、レフトビュー用をメインとし、2D表示の場合はレフトビューが表示されることを前提に説明しているが、ライトビューがメインでもよい。プレイリストに左目/ライトビューのどちらがメインであるか、2Dの場合に表示されるかを判別する情報に従い、ベースビュービデオストリームであるものとする。その判別の情報が、レフトビュー/ライトビュー識別情報である。
一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、レフトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すレフトビュー/ライトビュー識別情報をプレイアイテム情報毎に設定できるようにしている。
図23は、図17の3Dプレイリストに、レフトビュー/ライトビュー識別情報を書き加えた図である。この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。
各ストリームとレフトビュー/ライトビューの識別情報は、表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。
また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。
以上がレフトビュー/ライトビュー識別情報についての説明である。このレフトビュー/ライトビュー識別情報は、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。しかし視差画像の内容によっては、このように平面視画像として利用することに向いていないことがある。
以下、平面視画像として利用することに不向きなレフトビュー画像、ライトビュー画像について説明する。
図24は、レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。図中の右下は、映像中の恐竜が、ユーザの目の前にまで迫ってくるような画面効果を狙っている立体視画像を示す。この立体視画像は、その上に記載されているような、L画像、R画像によって構成される。飛び出し効果が大きい立体視画像を構成するL画像、R画像は、飛び出して現れる画像中の対象(本図では恐竜)を、側面から表示するようになっている。これらのうち、レフトビュービデオストリームを、平面視用のビデオストリームとして使用する場合、横長の物体が横たわっているように見えてしまい、おかしなものになる。そこで、2Dモードに設定されている場合、センター画像を表すビデオストリームを指定する、プレイリスト情報をカレントプレイリストとして選ぶようにする。
本図において、00005.mplsは、飛び出し度合が大きいレフトビュービデオストリーム、及び、ライトビュービデオストリームを、メインパス情報及びサブパス情報として指定している。
00003.mplsは、センター画像のビデオストリームをメインパスによって指定している。そして本図左上のムービーオブジェクトは、再生装置における3D再生のケーパビリティ(3D-Capability)に応じて、00005.mpls、00003.mplsのうち、どちらかを選択して再生するよう記述されている(図中のif文)。
以上が記録媒体の実施行為及び記録方法の実施行為についての説明である。続いて、再生装置の詳細について説明する。
図25は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BDドライブ1、リードバッファ2a、リードバッファ2b、スイッチ3、システムターゲットデコーダ4、プレーンメモリセット5a、プレーン合成部5b、HDMI送受信部6、再生制御部7、管理情報メモリ9、レジスタセット10、プログラム実行部11、プログラムメモリ12、HDMVモジュール13、BD-Jプラットフォーム14、ミドルウェア15、モード管理モジュール16、ユーザイベント処理部17、ローカルストレージ18、不揮発メモリ19から構成されている。
BD-ROMドライブ1は、2D再生装置と同様に再生制御部7からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ2aかリードバッファ2bに転送される。
3D映像を再生する際には、再生制御部7からは2D/レフトビューAVクリップとライトビューAVクリップとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BD-ROMドライブ1は、2D/レフトビューAVクリップを構成するエクステントをリードバッファ2aに読み出し、ライトビューAVクリップを構成するエクステントをリードバッファ2bに読み出す。3D映像を再生する際には、2D/レフトビューAVクリップとライトビューAVクリップの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。
リードバッファ2aは、BD-ROMドライブ1が読み込んだ2D/レフトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ2bは、BD-ROMドライブ1が読み込んだライトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
スイッチ3は、リードバッファに対するデータ入力源を、BD-ROMドライブ1又はローカルストレージ18の何れかに切り替えるためのスイッチである。
システムターゲットデコーダ4は、リードバッファ2aに読み出されたソースパケットとリードバッファ2bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。
プレーンメモリセット5aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、インタラクティブグラフィックスプレーン(IGプレーン)、プレゼンテーショングラフィックスプレーン(PGプレーン)といったものがある。
プレーン合成部5bは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンを瞬時に重畳し、TVなどの画面に表示する。この表示にあたってプレーン合成部5は、セカンダリビデオプレーン、PGプレーン、IGプレーンを3Dメタデータを使って左目用と右目用とに交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンと合成する。合成後の映像は、GFXプレーンの重畳処理に転送される。
プレーン合成部5は、IGプレーンにおけるグラフィクスをAPIから指定されたオフセット情報を使って左目と右目用に交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンとセカンダリビデオプレーンとPGプレーンとIGプレーンとが重畳されたイメージを、テレビに出力する。
テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。
HDMI送受信部6は、例えばHDMI規格(HDMI:High Definition Multimedia Interface)に準拠したインターフェイスを含み、再生装置とHDMI接続する装置(この例ではテレビ300)とHDMI規格に準拠するように送受信を行うものであり、ビデオに格納されたピクチャデータと、オーディオデコーダ9によってデコードされた非圧縮のオーディオデータとを、HDMI送受信部6を介してテレビ300に伝送する。テレビ300は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からHDMI送受信部6を介して要求があると、テレビ300は要求された必要な情報(例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報)を再生装置へ返す。このように、HDMI送受信部6を介することで、テレビ300が立体視表示に対応しているかどうかの情報を、テレビ300から取得することができる。
再生制御部7は、再生エンジン7a、再生制御エンジン7bを含み、3Dプレイリストの再生がプログラム実行部11などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムの2D/レフトビューAVクリップを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのライトビューAVクリップを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点から2D/レフトビューAVクリップのエクステントと、ライトビューAVクリップのエクステントとを交互に読み出すようにBD-ROMドライブ1に要求する。再生開始するときには、最初のエクステントをリードバッファ2aか、リードバッファ2bに読みきった後に、リードバッファ2aとリードバッファ2bからシステムターゲットデコーダ4に転送を開始する。また、再生制御部7は、3Dプレイリストを再生する場合は、3D/レフトビューAVクリップに対応するクリップ情報ファイルに含まれる3Dメタデータをプレーン合成部5に通知する。
再生エンジン7aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。
再生制御エンジン7bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。
管理情報メモリ9は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。
再生状態/設定レジスタ(Player Status/Setting Register)セット10は、プレイリストの再生状態を格納する再生状態レジスタ、再生装置におけるコンフィグレーションを示すコンフィグレーション情報を格納する再生設定レジスタ、コンテンツが利用する任意の情報を格納できる汎用レジスタを含む、レジスタの集まりである。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置(時刻)を再生しているかなどの状態を現す。
プレイリストの再生状態が変化した際は、再生制御エンジン14がレジスタセット10に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJavaプラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。

プログラム実行部11は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。(1)再生制御部7に対してプレイリスト再生を命令する。(2)システムターゲットデコーダに対してメニューやゲームのグラフィックスのためのPNG・JPEGを転送して画面に表示する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBD-Jアプリケーションのプログラミング工程によって決まる。
プログラムメモリ12は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BD-Jモードの動作主体であるJavaプラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。また動的シナリオメモリ12は、ヒープメモリを含む。
ヒープメモリは、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である
HDMVモジュール13は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

BD-Jプラットフォーム14は、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アーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ31に格納することにより、BD-Jアプリケーションのロードを行う。
バイトコードインタプリタは、いわゆるJava仮想マシンであり、ヒープメモリに格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
アプリケーションマネージャは、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。以上で、BD-Jプラットフォーム部の内部構成についての説明を終える。
ミドルウェア15は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。
モード管理モジュール16は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モード管理モジュールによるモード管理とは、動的シナリオを、BD-Jプラットフォーム22、HDMVモジュールのどちらに実行させるかという、モジュールの割り当てである。
ユーザイベント処理部17は、リモコンを通じたユーザ操作に応答して、プログラム実行部16や再生制御部7に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部16に依頼する。例えば、リモコンで早送り・巻戻しボタンが押された場合には、再生制御部7に、現在再生しているプレイリストのAVクリップに対する早送り・巻戻し処理の実行を命令する。
ローカルストレージ18は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。
不揮発メモリ19は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット10における記憶内容のバックアップに用いられる。
次に、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成について説明する。図26は、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成を示す図である。本図に示すように、システムターゲットデコーダ4及びプレーンメモリセット5aは、ATCカウンタ21、ソースデパケットタイザ22、PIDフィルタ23、STCカウンタ24、ATCカウンタ25、ソースデパケットタイザ26、PIDフィルタ27、プライマリビデオデコーダ31、レフトビュービデオプレーン32、ライトビュービデオプレーン33、セカンダリビデオデコーダ34、セカンダリビデオプレーン35、PGデコーダ36、PGプレーン37、IGデコーダ38、IGプレーン39、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41、ミキサー42、レンダリングエンジン43、GFXプレーン44から構成される。
ATCカウンタ21は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケットタイザ22は、リードバッファ2aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ23は、ソースデパケッタイザ22から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダ31、セカンダリビデオデコーダ34、IGデコーダ38、PGデコーダ36、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41に転送する。
STCカウンタ24は、System Time Clock(STC)を生成し各デコーダの動作タイミングを調整する。
ATCカウンタ25は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケットタイザ26は、リードバッファ2abにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ27は、ソースデパケッタイザ26から出力されたTSパケットのうち、TSパケットのPIDが、カレントプレイアイテムのストリーム選択テーブルに記載されたPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダに転送する。
プライマリビデオデコーダ31は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをバイトコードインタプリタ32に書き込む。
レフトビュービデオプレーン32は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
ライトビュービデオプレーン33は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
セカンダリビデオデコーダ34は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻(PTS)のタイミングでピクチャをセカンダリビデオプレーンに書き出す。
セカンダリビデオプレーン35は、システムターゲットデコーダ4からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
PGデコーダ36は、ソースデパケタイザから入力される複数のTSパケットからプレゼンテーショングラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスデータを表示時刻(PTS)のタイミングでPGプレーンに書き出す。
PGプレーン37には、プレゼンテーショングラフィックスストリームをデコードすることで得られた非圧縮のグラフィックスオブジェクトが格納される。
IGデコーダ38は、ソースパケタイザから入力される複数のTSパケットからインタラクティブグラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスオブジェクトを表示時刻(PTS)のタイミングでIGプレーンに書き出す。
IGプレーン39には、インタラクティブグラフィックスストリームをデコードすることで得られたグラフィックスデータが格納される。
プライマリオーディオデコーダ40は、プライマリオーディオストリームをデコードする。
セカンダリオーディオデコーダ41は、セカンダリオーディオストリームをデコードする。
ミキサー42は、プライマリオーディオデコーダ40のデコード結果と、セカンダリオーディオデコーダ41のデコード結果とを合成する。
レンダリングエンジン43は、JPEG,PNGなど、BD-Jアプリケーションがメニュー描画に利用するグラフィックスデータをデコードする。
GFXプレーン44は、JPEG,PNGなどのグラフィックスデータがデコードされた後、書き込まれるプレーンメモリである。
次にプライマリビデオデコーダ31の内部構成について説明する。プライマリビデオデコーダ31は、TB51、MB52、EB53、TB54、MB55、EB56、ビデオデコーダ57、バッファスイッチ58、DPB59、ピクチャスイッチ60から構成される。
Transport Buffer(TB)51は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ23から出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)52は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)53は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
Transport Buffer(TB)54は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)55は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)56は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
ビデオデコーダ57は、ビデオエレメンタリストリームの個々のビデオアクセスユニットを所定の復号時刻(DTS)でデコードすることによりフレーム/フィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG2、MPEG4AVC、VC1などがあるため、ストリームの属性に応じて、ビデオデコーダ57のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ57は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ57は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ57は、デコードされたフレーム/フィールド画像をDPB59に転送し、表示時刻(PTS)のタイミングで対応するフレーム/フィールド画像をピクチャスイッチに転送する。
バッファスイッチ58は、ビデオデコーダ57がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB53、EB56のどちらから引き抜くかを決定し、EB53と、EB56とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻(DTS)のタイミングでビデオデコーダ57に転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ57に転送するのが望ましい。
Decoded PIcture Buffer(DPB)59は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ57が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。
ピクチャスイッチ60は、ビデオデコーダ57から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。
図27は、プレーン合成部の内部構成を示す図である。3Dメタデータに基づき、プレーンに格納されている非圧縮ピクチャデータ、グラフィクスデータをクロッピングするクロッピング部61a,b,cと、プログラムAPIに基づきプレーンに格納されている非圧縮グラフィクスデータをクロッピングするクロッピング部61dと、出力内容をレフトビュービデオプレーンと、ライトビュービデオプレーンとで切り替えるスイッチ62と、プレーン同士の合成を行う加算部63、64、65、66とから構成される。
プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ4よりPTSのタイミングで映像データが書き出される。プレーン合成部5は、レフトビュービデオプレーンとライトビュービデオプレーンのうち、PTSのタイミングで映像データが書き出されたほうのプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送される。
これらのプレーンメモリのそれぞれは、レフトビューと、ライトビューとでそれぞれ異なる内容が格納されることで立体視の実現が可能になる。しかし、レフトビューにおける格納内容と、ライトビューにおける格納内容とが同じであっても、プレーンメモリにおける画素の座標を、レフトビューと、ライトビューとでそれぞれ変化させれば擬似的な立体視を実現することができる。上述したようなプレーンメモリのうちPGプレーンは、プレーンメモリにおける画素の座標を変化させることで、立体視を実現している。以下、PGプレーンにおける立体視の実現の仕方について説明する。
図28は、PGプレーンの合成の仕方を示す図である。
プレーン合成の仕方を図28のPGプレーンの例を用いて説明する。プレーン合成部5は、3Dメタデータ内に存在するオフセットエントリーのうち、現在再生されているプレゼンテーショングラフィックスのPIDに対応するものの中から、現在の表示時刻に対応するオフセット値を取得する。そして、プレーン合成部5は、重畳する映像プレーンがレフトビュービデオプレーンの場合はPGプレーンに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後、他のプレーンとの合成に供する(図28上段参照)。
プレーン合成部5は、重畳する映像プレーンがライトビュービデオプレーンの場合は、PGプレーンをオフセット値だけX軸の負の方向をずらし、レフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後に重畳する(図28下段参照)。IGプレーン、セカンダリビデオプレーンも同様に処理を行う。
図29は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクリッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。
以上がプレーン合成についての説明である。続いて、レジスタセット10の内部構成及び再生制御エンジン7bの詳細について説明する。
図30は、レジスタセット10の内部構成及び再生制御エンジン7bの内部構成を示す図である。
本図の左側にはレジスタセット10の内部構成を示している。右側には再生制御エンジン7bの内部構成を示している。
PSRに格納されているこれらの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって適宜参照され、またムービーオブジェクト及びBD-Jアプリケーションによる更新を受ける。このようにPSRの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって参照されるパラメータであるから、システムパラメータとも呼ばれる。
始めに、PSRのうち、代表的なものについて説明する。
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 3D”の設定である。これは、再生装置の接続相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。
PSR24は、“Player Capability for 3D”の設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。
一方、再生制御エンジン7bの内部には、レジスタセット10におけるPSR4,PSR6,PSR21,PSR23,PSR24と、管理情報メモリ9におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部8を備えている。PSR24におけるPlayer Capability for 3Dは、再生装置の3D再生に関する能力全般を意味するものなので、“3D-Capability”と簡単に表記する場合がある。
PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図31に示すように規定されている。
図31は、出力モードの選択モデルの状態遷移を示す図である。この選択モデルには、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になる。
図32は、Initializationの処理手順を示すフローチャートである。
ステップS1は、ディスクアンバウンドのBD-Jアプリケーションが動作中かどうかの判定であり、ステップS2は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、Index.bdmvにおけるInitial_output_mode情報が“立体視出力モード”を示すかどうかの判定である。
ステップS1がYesであれば、ステップS3においてカレントの出力モードを維持する。ステップS1がNo、ステップS2がYesであれば、ステップS4においてPSR22を立体視出力モードに設定する。ステップS1がNo、ステップS2がNoであればステップS5においてPSR22における出力モードを、2D出力モードに設定する。
図33は、Procedure when playback condition is changedの処理手順を示すフローチャートである。ステップS11は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、ステップS13は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、尚且つ、プレイリストにSTN_table_SSが存在するかどうかの判定である。
ステップS11がYesであればステップS12において、カレント出力モードを変化させない。ステップS11がNo、ステップS13がYesであってもカレント出力モードを変化させない(ステップS12)。ステップS11がNo、ステップS13がYesであればカレント出力モードを2D出力モードに変化させる(ステップS14)。
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、“ストリーム選択プロシージャ”と呼ばれる。
図34は、ストリーム選択プロシージャの処理手順を示すフローチャートである。ステップS21は、再生装置の表示方式が2Dであるか否かを判定する判定ステップであり、判定結果がYesであるなら、カレントプレイアイテム情報内の2D用STN_tableをカレントSTN_tableに設定する(ステップS22)。判定結果がNoであるなら、プレイリスト情報のエクステンションデータに存在するSTN_table_SSのうち、カレントプレイアイテム情報に対応するものを、カレントSTN_tableに設定する。以降、ステップS24〜ステップS33の処理を実行する。ステップS24〜ステップS33は、プライマリビデオストリーム、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップS26〜ステップS33の処理を繰り返すものである。ステップS26は、カレントSTN_tableにおける、ストリームxに対応するSTN_tableエントリー数が0であるか否かの判定であり、ステップS27は、カレントストリームにおけるストリームxに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。
ステップS26、ステップS27の何れかがYesであれば、ステップS33においてストリーム番号レジスタに格納されているストリーム番号を維持する。
ステップS26、ステップS27の何れもがNoであれば、カレントSTN_tableに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して(ステップS28)、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する(ステップS29)。
条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する(ステップS30)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレントSTN_tableにおける優先順位が最も高いものを選択する(ステップS31)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む(ステップS32)。
以上の過程を経て出力モードが確定し、またカレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedure when playback condition is changedによって確定した出力モードに応じたものとなる。出力モードに応じた、プレイアイテムの再生手順を図35を参照しながら説明する。
図35は、プレイアイテムの再生手順を示すフローチャートである。
ステップS41は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップS42において、カレントプレイアイテム番号を“1”に初期化した上で、ステップS43〜ステップS48のループに移行する。
このループは、カレントプレイアイテムに対してステップS43〜ステップS46の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップS48)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップS47でYes)。ステップS43〜ステップS46の内容は、以下のものである。
ステップS43において、カレントプレイアイテムのClip_Information_file_nameに記述されている「XXXXX」と、拡張子「m2ts」とで指定されているトランスポートストリームファイルをオープンし、ステップS44において、ビデオストリームのパケットIDに対応するエントリーマップを用いて、カレントPlayItem.In_Time及びカレントPlayItem.Out_TimeをStart_SPN[i]及びEnd_SPN[i]に変換する。
ステップS45では、パケットID[i]のTSパケット[i]をStart_SPN[i]からEnd_SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し、ステップS46において、読出範囲[i]に属するエクステントを連続的に読み出すよう、BD-ROMドライブに指示する。
カレント出力モードが立体視出力モードであれば、ステップS49において、カレントプレイアイテム番号を“1”に初期化した上で、ステップS50〜ステップS60のループに移行する。
このループは、カレントプレイアイテムに対してステップS50〜ステップS58の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップS60)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップS59でYes)。ステップS50〜ステップS58の内容は、以下のものである。
ステップS50において、カレントプレイアイテムのClip_Information_file_nameに記述されている「XXXXX」と、拡張子「ssif」とで指定されているトランスポートストリームファイルをオープンし、ステップS51において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のレフトビュー/ライトビュー識別情報によって指定されているものををベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。
ステップS52において、ベースビュービデオストリームのパケットIDに対応するエントリーマップを用いて、カレントPlayItem.In_Time及びカレントPlayItem.Out_TimeをStart_SPN[i]及びEnd_SPN[i]に変換する。
ステップS53では、ディペンデントビューストリームに対応するSubPlayItemを特定し、ディペンデントビューストリームのパケットID[j]に対応するエントリーマップ[j]を用いて特定されたSubPlayItemIn_Time、SubPlayItemOut_TimeをStart_SPN[j]、End_SPN[j]に変換する(ステップS54)。
パケットID[i]のTSパケット[i]をStart_SPN[i]からEnd_SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップS55)、パケットID[j]のTSパケット[j]をStart_SPN[j]からEnd_SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップS56)。そしてステップS57において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップS58においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。
HDMVモードにおいては、プレイリストの再生が停止していれば、画面には何も現れないが、BD-Jモードでは、プレイリスト再生が停止していても、BD-Jアプリケーションが画面描画を行うことができるので、何等かの画面が表示されている可能性がある。ここでもし、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こる。何故なら、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こるからである。
プレイリストの再生が開始されれば、そのプレイリストが2Dであるか、3D映像であるかに応じて、メニューやグラフィクスを3Dに変換したり、2Dに変換する必要があるので、そこで本実施形態では、ミドルウェアがBD-Jアプリケーションにイベントを出力して、立体視のための画面描画を促すことにしている。
2D映像と3D映像とが切り替わるタイミングを、ディスク上に記録され、再生装置で動作しているプログラムに知らせるための仕組みについて説明する。
図31の状態遷移では、BD-Jタイトルにおいてプレイリストの再生が開始した際、Procedure when playback condition is changedが実行されたが、このBD-Jタイトルの再生中に、プレイリストの再生が開始された場合、何等かの術により、プレイリスト再生の開始をBD-Jアプリケーションに通知せねばならない。この通知をどのようにして行うかを記述したのが図36である。
図36は、再生制御エンジンの状態が“停止中”から“3Dプレイリスト再生中”に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、『停止中→3Dプレイリスト再生→停止中』というように遷移していることがわかる。このうち、停止中から3Dプレイリスト再生に遷移したタイミング、3Dプレイリスト再生から停止中に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、停止中から3Dプレイリスト再生に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンの停止中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これは、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。
次に、再生制御エンジン7bが再生を停止しているのではなく、2Dプレイリストの再生を既に開始しており、その再生の途上で、再生対象となるプレイリストが切り替わるというケースを想定する。図37は、再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、2Dプレイリスト再生→3Dプレイリスト再生→2Dプレイリスト再生というように遷移していることがわかる。このうち、2Dプレイリスト再生から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から2Dプレイリスト再生に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これも、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。
次に、再生制御エンジンによる3Dプレイリストの再生中に、ユーザが字幕切り替え、音声切り替えの操作を再生装置に行ったというケースを想定して、以下を行う。再生対象となるストリームが切り替わることになる。以下、このストリーム切り替えの事例について図38を参照しながら説明する。
図38は、再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、3Dプレイリスト再生であるか、その途中に、ストリーム切替えがなされていることがわかる。このうち、ストリームが別のものに変化したタイミング、及び、ストリームが元のものに戻ったタイミングに、HScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。
プレイアイテムやプレイリスト、あるいは、ユーザーがストリーム切り替えを行ったタイミングであって、3D映像の再生が開始された場合、あるいは、終了した場合に、イベントを上げることにより、2D/3Dが切り替わるタイミングを検出して、適切なメニュー・グラフィクスに切り替えさせる。
以上のように本実施形態によれば、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のClip_Information_file_nameと、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子「ssif」とから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供することで、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。
そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。こうしたオーサリングの手間の低減によって、3D再生可能な映画作品の充実化を図ることができる。
(第2実施形態)
本実施形態では、表示装置300、3D眼鏡400がどのような機能をもち、その内部構成がどのようなものかを図39を参照しながら説明する。
図39(a)は、表示装置300の内部構成を示す図である。本図に示すように、表示装置300は、チューナ71、HDMI送受信部72、メッセージ記憶部73、表示制御部74、表示素子75、無線送信部76から構成される。
チューナ71は、地上波デジタル放送、衛星デジタル放送で送信されたマルチチャネルトランスポートストリームを受信して復調する。この際チューナ71は、複数のチャネルを同時に選局して非圧縮のピクチャを出力することもできる。
HDMI送受信部72は、HDMIを通じて再生装置から送信されてくる非圧縮で合成済みピクチャデータを受信する。
メッセージ記憶部73は、ピクチャに代えて表示すべき警告メッセージを記憶している。
表示制御部74は、チューナ71による復調で得られた非圧縮のピクチャ、HDMIを通じて再生装置から伝送された非圧縮で合成がなされたピクチャを表示に供する。表示にあたって表示制御部74は、1/120秒、1/140秒という時間精度で、表示期間を切り替えることができ、この精度で、例えば1/24秒という表示期間を、1/48秒、1/72秒、1/92秒というように、更に小さい表示期間に細分化することができる。
表示パネル75は、液晶表示素子、プラズマ発光素子、有機EL素子を駆動することで、画素の発光を行うデバイスであり、表示制御部74による制御の下で、非圧縮のピクチャデータの表示を行う。
無線送信部76は、赤外線通信方式、無線LAN方式によって、3D眼鏡400を制御する。具体的には、3Dモード及びマルチチャネルモードのそれぞれにおいて、表示期間の先頭にあたって、3D眼鏡400の状態遷移を促す同期信号を送信する。かかる信号送信によって、レフトビューの期間では透光状態に遷移し、ライトビューの期間では遮光状態に遷移し、レフトビューの期間では改めて透光状態に遷移させるという制御を繰り返す。これにより、図1(b)(c)のような変化を行うことになる。
本実施形態では3Dモードでの処理として、表示制御部74は、1/24秒という表示期間を、1/72秒の時間長をもつ3つの表示期間(表示期間1/3,2/3,3/3)に分割して、この3つの表示期間1/3,2/3,3/3のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/3の表示内容はレフトビュー、2つ目の表示期間2/3の表示内容はライトビュー、そして3つ目の表示期間3/3の内容には警告画面というようにである。これらの期間の先頭において、眼鏡に対して同期信号を送信し、レフトビュー及びライトビューの状態遷移を行わせる。
マルチチャネルモードの処理として、表示装置300は複数のチャネルを、時分割で復調する。そして表示制御部74は、1/24秒という表示期間を、1/24秒の時間長をもつ2つの表示期間(表示期間1/2,2/2)に分割して、この2つの表示期間1/2,2/2のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/2の表示内容はチャネル1、2つ目の表示期間1/2の表示内容はチャネル2というようにである。そして、個々のチャネルの表示期間が到来すれば、そのチャネルの視聴を希望しているユーザの状態を透光状態に遷移させ、他のチャネルの視聴を希望しているユーザの眼鏡の状態を遮光状態に遷移させる。
図39(b)は、3D眼鏡400の内部構成を示す図である。
状態遷移のトリガとなる同期信号を表示装置300から受信する無線受信部81と、液晶シャッタの状態を、透光状態、遮光状態に遷移させる状態制御部82と、液晶シャッタ83、84とを具備する。
眼鏡の動作モードにも、3Dモード、マルチチャネルモードが存在する。
3Dモードにおいて眼鏡は、透光状態、遮光状態のほか、遮断−遮光状態を具備する。遮断−遮光状態は、レフトビュー及びライトビューの双方が閉じている状態である。
マルチチャネルモードにおいて眼鏡は、レフトビュー及びライトビューの双方が開いている透光−透光状態と、レフトビュー及びライトビューの双方が閉じている遮断−遮光状態とに遷移する。
立体視表示を実現する場合、本実施形態では、眼鏡のライトビュー、レフトビューを、単に切り替えるのではなく、3D眼鏡400の装着を促す警告画面を、3D眼鏡を既に装着しているユーザに見せないような配慮が必要になる。警告画面を装着済みユーザに見せないように、3D眼鏡400をどのように制御すべきかを、図40を参照しながら説明する。
図40は、3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のライトビュー、レフトビューの状態を示す。1/24秒のうち、最初の1/72秒の表示期間1/3では、レフトビュー画像が表示装置に表示されていて、眼鏡のレフトビューが透光状態、ライトビューが遮光状態になっている。続く表示期間2/3では、ライトビュー画像が表示装置に表示されていて眼鏡のレフトビューが遮光状態、ライトビューが透光状態になっている。最後の表示期間3/3では、表示装置が眼鏡の装着を促す警告画面になっていて、眼鏡のレフトビュー及びライトビューが遮光状態になっていることがわかる。
1/24秒の表示期間を分割することで得られた3つの1/72秒の表示期間のうち、最後の表示期間3/3において、眼鏡を装着したユーザは、画面に表示されている警告映像を見ることができない。「3D眼鏡をかけてください」と表示すると、3D眼鏡をかけていない人には、3D眼鏡をかけることを促すメッセージが見えるが、すでに3D眼鏡をかけている人には見えないといった、状況に応じたメッセージが表示されることになる。
マルチチャネル表示を実行する場合、表示装置は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替えるという独特の制御を実現する。この独特な制御を図41を参照しながら説明する。
図41は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替える場合の、3Dモードにおける表示内容と、レフトビューの状態と、ライトビューの状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のR、Lの状態を示す。
1/24秒の表示期間のうち、表示期間1/2において、ユーザー1が装着している眼鏡は、透光−透光状態になりユーザ1はチャンネル1(Ch1)を視聴することができる。
ユーザー2が装着している眼鏡は、遮光−遮光状態になりユーザ2はチャンネル1(Ch1)を視聴することができない。
表示期間2/2において、 ユーザー1が装着している眼鏡は、遮光−遮光状態になりユーザ2はチャンネル2(Ch2)を視聴することができない。ユーザー2が装着している眼鏡は、透光−透光状態になりユーザ2はチャンネル2(Ch2)を視聴することができる。このような使い方をすると、1つの画面で、二人がそれぞれ異なるチャンネルを同時に見ることができる
3D眼鏡をすでに装着しているため、眼鏡に内蔵されたイヤフォンを用いれば、映像と音声を完全に独立させることも可能であり、リビングでのチャンネル権争いの回避、1つの画面で対戦ゲームをするなど、応用範囲は広がる。また、ステップを増やすことにより、3チャンネルやさらに多くのチャンネルを1つの画面で見ることが可能となる。
以上のように本実施形態によれば、表示装置を視聴しているユーザが複数人である場合、各ユーザが3D眼鏡400を着用することで、各ユーザは、自分が好きなチャネルを視聴することが可能になる。ユーザの人数分、表示装置を用意しなくてもユーザは好きな番組を見ることができるので、ユーザ宅のリビングを有効に利用することができる。
(第3実施形態)
本実施形態は、再生装置と、表示装置とのネゴシエーションに関する実施形態である。ユーザ宅内におけるホームシアターシステムの構築事情には、それぞれの家庭独特のものがあり、再生装置は、表示装置と接続された際、接続相手となる表示装置とネゴシエーションを行って、どのプレイリストを再生に供するかを切り替える必要がある。
本実施の形態では、3Dに対応したデジタル出力と、旧来の表示装置にも出力できることを考慮したアナログ出力を同時に出力する場合の改良を説明する。
3D映像を格納したBD-ROMであったとしても、旧来から存在して普及台数が多い2D再生装置でも正常に再生されることを考える必要がある。第1実施形態で述べたように、BD-ROM上のプログラムで制御する方法もあるが、プログラムのバグなどにより選択を誤った場合、不適切な映像が再生され視聴者の健康を害したり、過剰な負荷がかかることにより再生装置が壊れてしまう可能性もあるため、不適切な再生が行われない仕組みが必要となる。
2DTVとの接続時について述べる。
そもそも旧来のアナログ方式では3D映像に対応していないため、3D映像は出力できない。再生装置が3D映像再生中は、アナログ出力に「3D映像再生中です。3D対応のディスプレイでご覧ください。」などのメッセージを表示して、ユーザーが誤った端子に接続したり、対応していない表示装置に接続していることを知らせるためのメッセージを表示する。その後、接続されている表示装置が2D表示装置である場合は、自動的に2Dプレイリストに再生を切り替えることが望ましい。
次に、2D表示装置と、3D表示装置とが再生装置に同時に接続されていて、これらの表示装置に映像信号を同時出力するケースについて説明する。再生装置に2D表示装置と3D表示装置が接続されており、同時に出力している場合は、2D表示装置側に3D映像のレフトビューかライトビューのいずれかのみを出力する。
複数の表示装置に、プレイリストの再生結果である映像信号を同時出力する際、レフトビュービデオストリーム、ライトビュービデオストリームのうちどちらを、アナログ用に出力するかを規定する情報を、2D出力優先映像情報という。この情報をプレイリストに予め設けておき、カレントプレイリストにおける2D出力優先映像情報に従い、2D表示装置、3D表示装置に同時に映像信号を出力する。こうすることで、2Dと3D用の映像を同時にデコードしたり、2Dと3D用のプレイリストを独立して扱えなくても、同時に2つの表示装置に出力することが可能となる。
同様にOSD(システム組み込みメニュー)表示を行う際、3D表示装置には3D対応のOSD表示を行うが、アナログ出力のように2Dしか対応しない出力には専用の2D映像、あるいは、レフトビューのみ/ライトビューのみを出力する。
3D用の出力と2D用の出力が困難な場合は、リモコンに副表示部を設け、そちらに表示することが望ましい。
これらのことを図42を参照しながら具体的に説明する。図42は、再生装置と、表示装置との接続態様を示す図である。上側は、アナログ接続される表示装置を示す。左下側に、デジタル接続される3D対応の表示装置300を示し、右下側に、デジタル接続される2D表示装置302を示す。
再生装置が、3D表示装置と、2D表示装置とに同時接続された場合は、これらの表示装置とネゴシエーションを試みる。そして、相手側表示装置との接続がアナログ接続によるものであるため、ネゴシエーションをすることができないことが判明すれば、レフトビュービデオストリーム、レフトビュービデオストリームのうち、2D出力優先映像情報に示されるものを再生する。こうすることで、接続相手たる表示装置とアナログ接続された場合、オーサリング担当者が意図したプレイリストを再生に供することができる。
一方、双方の表示装置との接続がデジタル接続によるものであり、ネゴシエーションが成功した場合は、相手側が3D表示装置であるか、2D表示装置であるかを判定する。ネゴシエーションの結果、相手側が2D表示装置であることが判明すれば、図中の矢印mg1に示すように画面内容の遷移を2D表示装置に行わせる。
矢印mg1は、2D表示装置の画面内容の遷移を示す。デジタル接続の場合、3D映像の再生中です。「3D表示装置で御覧ください]とのメッセージを表示した後、2D映像を表示する。


またネゴシエーションにあたっては、複数のライトビューを切り替える必要がある。複数のライトビューを切り替える理由として、表示装置の画面の大きさの違いがある。左目と右目の間隔は個人の個体差があってもだいたい同じであるが、表示装置は20インチのものもあれば、150インチのものもある。50インチの表示装置を想定して、目と目の間隔6.5センチで作られた映像も、150インチの表示装置では3倍の19.5センチの目の間隔になってしまい、3D映像として認識が難しくなる。そのため、様々なサイズの表示装置でレフトビューとライトビューの差が、6.5センチになるレフトビュー、ライトビューの組みを納めておけば、表示装置に合わせてビデオストリームを選ぶことにより、最適なレフトビュービデオストリーム/ライトビュービデオストリームの組み合わせを選ぶことができる。
表示装置には、150インチ、50インチという様々なサイズがあり、例え左右の画素数が同じでも、これらの表示装置における画面上の距離は違ってくることを図43を参照しながら説明する。
図43は、左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。
左側は、左右のオフセットが異なる、ライトビューピクチャ−と、レフトビューピクチャとの組を示す。
中段は、50インチ表示装置における距離を示し、右側は、150インチ表示装置における距離を示す。左右の差が50画素である場合、50インチ表示装置上での距離は2.0cmとなり、150インチ表示装置上での距離は6.0cmとなる。
左右の差が100画素である場合、50インチ表示装置上での距離は、4.0cmとなり、150インチ表示装置上での距離は12.0cmとなる。
左右の差が150画素である場合、50インチ表示装置上での距離は、6.0cmとなり、150インチ表示装置上での距離は18.0cmとなる。
50インチ表示装置では、6.0cmが最適となり、150インチ表示装置でも、6.0cmが最適となので、3DStream Depth ChangeUO、3DStreamDepthChangeコマンドにより、画面上において表示される距離を調整する。
図43で説明した表示装置の画面サイズを取得する方法を用いて、プログラムが自動的に最適な左目/ライトビューの組み合わせを選択できれば、ユーザーは画面サイズを気にすることなく、最適なストリームが自動選択されることになる。
複数の画面サイズに対応した奥行き感/深度の異なるストリームが複数記録されている場合、ローカルストレージの画素差が異なるストリームを記録媒体に記録しておき、これらのストリームを切り替えるためのUOやコマンドを用いることで、ユーザー自身が奥行き感/深度を選択することも可能である。
以上のように本実施形態によれば、再生装置が表示装置と接続された際、表示装置との関係においてより適切な再生出力が行われることが保障される。

(第4実施形態)
本実施形態は、立体視を行うにあたって、ビデオストリームと共に、どのようなPGストリーム、IGストリームを選択すべきかという改良を実現する。
2D再生装置で再生される映像は2D映像であり、対応する字幕やメニュー画像が3Dである。対して、3D再生装置で再生されるのは3D映像であり、対応する字幕やメニュー画像も3Dであることが望ましい。3D映像に対して、2DのPGやIGが表示された場合、前後関係が意図しないものとなり、ユーザーが正常に空間認識ができず、最悪健康を害してしまうためである。
また、3D再生装置であったとしても、ユーザーが2D映像を選ぶことは自由であるが、その場合、対応する字幕やメニュー画像も自動的に2Dに切り替わるべきである。
2D映像と関連する字幕などの組み合わせ、3D映像と関連する字幕などの組み合わせは、プログラムで選択してもよいが、データとして関連づけておくことにより再生装置が自動的に不適切な組み合わせを排除することが可能となる。その仕組みについて述べる。

3D対応のプレイリストは、第1実施形態で示したように、ストリーム選択テーブルをさらに2D用のSTN_tableと、3D再生用のSTN_table_SSとに分けて管理する。そして2D再生でしか利用しない映像/音声/PG/IGのストリーム登録と、3Dで利用する映像/音声/PG/IGのストリーム登録は異なるエントリー群に登録する。2D映像を選択している場合は、3D用に用意された音声/PG/IGは選択できない。また、同様に3D映像を選択している場合は、2D用に用意された音声/PG/IGは選択できない。
管理テーブルをさらに分割して、レフトビューとライトビュー、それらに関連づけられる字幕/メニュー画像のストリーム登録を別々に管理することもできる。

2D用に作成されたPGストリームと、3D用に作成されたPGストリームとでは、奥行きの有無、位置や角度に違いがあるので、立体視のためのビデオストリームの再生時に、2DPGストリームが選択されて、3Dビデオストリームと共に再生されることは、オーサリング者にとっては何とか避けたいところである。
これを避けるために導入されたのが、STN_table_SSにおけるストリーム組合せ情報である。図44は、ビデオストリームとPGストリームとを組み合わせる場合の、ストリーム組合せ情報の記述例である。
本図(a)に示すように、ストリーム選択テーブルにおけるストリーム組み合わせ情報には、ビデオストリームのストリーム番号=1と、PGストリームのストリーム番号”=1”、2との組み合わせが許容されていることがわかる。
ビデオストリームのストリーム番号=2には、PGストリームのストリーム番号”=1”、2との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=3には、PGストリームのストリーム番号=3、4との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=4には、PGストリームのストリーム番号=3との組み合わせが許容されていることがわかる。
図44(b)は、その組合せ情報にて規定されるビデオストリーム、PGストリーム間で、許容される組合せを模式的に示す。
本図左側のビデオストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるビデオストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるビデオストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるビデオストリームは3D用であることがわかる。
本図左側のPGストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるPGストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるPGストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるPGストリームは3D用であることがわかる。
ビデオストリーム及びPGストリームの間の実線kw1,2,3・・・は、ストリーム組合せ情報によって許容される組合せを模式的に示す。この実線で模式的に示されるように、2Dと3Dの映像/字幕を組み合わせることはできない。また、組み合わせ可能なストリーム通しの場合も意図的に省くことができる。
PGストリームと、ビデオストリームとの組合せはストリーム組合せ情報に予め規定されているので、このストリーム組合せ情報に則して、PGストリームを選択すれば、あるビデオストリームが選択された際、このビデオストリームにとって最適なPGストリームが選択されることが保障されることになる。
図45は、ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。ユーザーがストリームを切り替える時、あるいは、プレイアイテム境界のように、ストリームの構成が変化する可能性がある時に、本図で示すストリーム選択処理が実行され、ビデオストリームとPGストリームは、ストリーム組み合わせ情報に登録された組み合わせに合致させる。
ステップS71において、ビデオストリーム番号を取得し、ステップS72においてPGストリームを取得する。ステップS73は、ビデオストリームと、PGストリームとの組合せが、ストリーム組合せ情報に登録されているかどうかの判定であり、もし登録されていれば、ステップS74においてそのストリーム組合せ情報の通り再生する。登録されていなければ、ステップS75においてストリーム組合せ情報においてビデオストリームとの組合せが登録されている、他のPGストリームを選択し再生する。

(第5実施形態)
第1実施形態の冒頭で述べたように、立体視には様々な原理があり、市場で流通しつつある製品は、様々な3D方式に対応していると考えられる。3Dの再生方式にはいろいろな方式が存在し、また、方式により表示装置側の対応・非対応も異なるため、再生装置のシステムパラメータは複数の方式を表現できる形式が望ましい。ここでは、3Dの再生方式として、2画面のビデオを独立して送る2画面ステレオ再生方式、サイド・バイ・サイド方式、横方向2倍方式、2D+奥行き情報方式などを例に挙げるが、その他、表示装置が対応可能な方式がある場合は、対応する方式の実行の可否を識別できるように、PSRのビットアサインを定める。
図46は、複数の3D方式を網羅できるPSRのビットアサインを示す図である。
本図におけるPSR24は、4ビット(b3,b2,b1,b0)からなり、最上位ビットb3から最下位ビットb0までのそれぞれのビットには、それぞれ対応する3D再生方式が関連づけられている。再生装置がその3D再生方式に対応している場合には、対応するビットが「1」に設定され、対応していない場合には対応するビットが「0」に設定される。PSR24の全ビットが「0」のときは、再生装置は2D再生装置であり、いずれかあるいはいくつかのビットが「1」のときは、対応した方式の2D/3D再生装置であることを示す。
PSR24における最上位ビットb3から最下位ビットb0までのビットは、2画面ステレオ再生、サイド・バイ・サイド方式、横方向2倍方式、2D−奥行き情報方式のそれぞれの3D表示方式をサポートできるかどうかを示す。
2画面ステレオ再生方式は、これまでの実施形態で説明した方式である。
サイド・バイ・サイド方式は、1920×1080という解像度を、960×1080と、960×1080とに分けて、これらのそれぞれに、レフトビュー,ライトビューを表示させる方式をいう。
横方向2倍方式は、1920×1080という解像度を、3840×1080という解像度にして、このうち、1920×1080の解像度の部分にレフトビューを割り当て、1920×1080の解像度の部分にライトビューを割り当てる方式である。
2D−奥行き情報方式は、2D映像と、グレースケール画像とで立体視を実現する方式である。グレースケール画像は、2値化画素からなる。2値化画素の輝度は、2D映像における各画素の奥行きを示す。この2値化画素の輝度に従い、2D映像における各画素の奥行きを作成して、立体視画像を構築する。
プレーヤセッティングレジスタの値をBD-ROM上のBD-Jアプリケーションからアクセスする場合は、再生装置のシステムプロパティとしてアクセスすることも可能である。
表示装置と再生装置が、HDMIのように表示装置の性能・対応方式を再生装置に送信できる伝送方式により接続されている場合、再生装置の性能だけではなく、表示装置の対応方式も鑑みて、PSR24に自動的に設定する。この場合、同じ再生装置でも接続される表示装置によってPSR24の値は変化する。
表示装置の性能を伝送できない場合は、ユーザーが手動で設定することが望ましい。
表示装置から対応方式を取得できる場合は、単純な対応方式の他、表示装置のサイズ、解像度、表示装置の画面から視聴する人までの距離等、3D再生に影響する情報を取得し、PSR24に格納しておくことで、後で説明するプログラムによる最適な再生方式の選択に活用することも可能である。
3Dの対応状況が1ビットで表せないことがででくる。この場合、複数ビットを使うべきである。映像サイズが1920×1080までは対応可能だが、それ以上の解像度の場合はデコーダの性能不足などにより再生できないことが想定される場合、2ビットを利用して非対応を「00b」、1920×1080まで対応を「01b」、それ以上のサイズに対応したものを「10b」などと表現すれば、より細かく対応状況をシステムパラメータを用いて表現することが可能である。
複数の3D方式を網羅できるようにPSR24のビットアサインを規定しておけば、再生装置に接続される表示装置がどのような3D方式のものであっても、表示装置に立体視再生を行わせることができる。図47は、表示装置が対応している3D再生方式を再生装置セッティングレジスタに反映させる図である。これまでに説明した3D再生能力を示す3D-Capabilityのシステムパラメータを利用すると、2D再生装置が,3Dビデオストリームを選択することを禁止する処理も可能である。ユーザー、プログラムあるいは、プレイアイテム先頭において、ビデオストリームを選択する時、選択しようとしているストリームが3Dビデオストリームである場合、プレーヤセッティングレジスタに格納された再生装置の対応3D方式を確認し、ストリーム選択テーブルから選択しようとしているストリームの情報を取得することにより、選択するストリームが再生装置で再生可能か否かが判別できる。
2D再生装置では3D映像を再生できないため、この処理により選択自体が発生せず、不適切な映像が画面に表示されることを防ぐことができる。
前の実施形態で説明した、表示装置が対応している3D方式を自動的に取得する仕組みと組み合わせると、接続されている表示装置が対応した3D方式のストリームか2Dストリームしか選択できないようになり、不適切な映像が画面に表示されることを防ぐことができる。
かかる処理を実現する場合のプログラムの処理内容について説明する。
ユーザからタイトルが選択され、実行されたBDプログラムファイルは、プログラムの中で、再生装置が3D映像再生に対応しているか、対応している場合にユーザが3D映像再生を選択しているかを調べて、再生するプレイリストを切り替える。
3D再生方式を複数想定する場合は、それぞれ対応した方式のプレイリストを準備しておき、再生装置がBD-ROMに格納されたプレイリストに対応している場合は、対応した3Dプレイリストを選択、対応していない場合は、2Dプレイリストを選択する。
FirstPlayタイトルをどのように構成すべきかについて説明する。
FirstPlayタイトルを構成するプレイリスト、つまり、ディスク挿入時にまず最初に再生されるプレイリストは、安全のため必ずどの再生装置でも再生される2D映像で構成すべきである。
BD-ROMに格納されているプログラムはオーサリング側が作成するものであり、複数の3D形式に再生装置が対応している場合、どの3D再生方式を優先的に選択するかは、オーサリング側の意志に依存する。
3Dプレイリストの選択について説明する。
たとえば、3D方式1が2画面ステレオ再生方式、3D方式2がサイド・バイ・サイド方式であり、再生装置がサイド・バイ・サイド方式にのみ対応している場合、プログラムはその再生装置で再生可能であるサイド・バイ・サイド方式の3Dプレイリスト005.MPLSを選択して再生する。
Index.bdmv、プログラムの関係について説明する。
図47に示すように、3D再生方式を再生装置セッティングレジスタに反映させれば、BD-ROMにおけるプログラムを動作させることでオーサリング担当者は、再生装置及び表示装置にとって最適な3D方式を再生装置セッティングレジスタに設定することができる。このような3D再生方式の選択を実現する場合、インデックステーブルと、BDプログラムファイルとは、以下に示すように設定しておく必要がある。
図48はインデックスファイル(Index.bdmv)とプログラムファイルとの関係を示している。
本図左側は、インデックステーブルと、当該インデックステーブルの解読主体であるモード管理モジュール16とを示す。上述したように、インデックステーブルには、FirstPlayタイトル、トップメニュー、タイトル1、2、3のそれぞれに対応するエントリーが存在する。
本図の右側は、再生装置における出力モードの設定に応じて選択的に再生されるべき4つのプレイリストファイルを示す。
4つのプレイリストファイルには、2D映像を再生する経路が記載された00001.mpls、00003.mplsと、3D方式1による再生経路が記載された00004.mplsと、3D方式2による再生経路が記載された00005.mplsとが存在する。
本図の真ん中には、ムービーオブジェクト1,2という2つのムービーオブジェクトが記載されている。
ムービーオブジェクト1は、00001.mplsの再生を命じる。この00001.mplsは、2Dプレイリストを定義するものである。何故なら、FirstPlayタイトルで再生されるべきプレイリストは、何れの出力モードでも必ず再生される必要があるからである。
ムービーオブジェクト2は、PSR24に示される3D-Capabilityが3D方式1であれば、00004.mplsの再生を命じ、3D-Capabilityが3D方式2であれば00005.mplsの再生を命じ、3D-Capabilityが、何れの3D方式にも合致しなければ、00003.mplsの再生を命じる。図中の矢印pp1,pp2,pp3は、ムービーオブジェクトによるプレイリストの再生指示を模式的に示す。
図中の矢印my1,my2は、これらのムービーオブジェクトが、HDMVモジュール13による解読に供されることを示す。HDMVモジュール13が、これらのムービーオブジェクトを実行することで、再生装置におけるCapabilityに応じて、上述したような3つのプレイリストファイルが選択的に再生に供されることがわかる。
ストリーム組合せ情報に、ビデオストリームと組合せることができるPGストリームが予め規定されていれば、ストリーム選択の処理手順は、図49のフローチャートに則したものとなる。
図49は、ストリーム選択の処理手順を示すフローチャートである。ステップS81において、再生装置の対応3D方式を取得し、ステップS82において、ストリーム選択テーブルを取得する。ステップS83では、再生装置が対応する3D方式と、選択しようとするストリームとが合致しているかどうかを判定し、ステップS83の判定結果がYesであるなら、ステップS84において選択を許す。ステップS83の判定結果がNoであるなら、ステップS85において、選択を許可しない。
(第6実施形態)
本実施形態では、第1実施形態で述べた記録方法を実施するための記録装置について説明する。
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。
この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。
リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TS形式のデジタルストリームを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBD-RE,BD-R等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
そして、装置外部から入力されるトランスポートストリームからビデオストリームにおける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上に得ることができる。

以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法を実行する記録装置について説明する。
ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成するというのが、本発明にかかる記録装置の使用形態である。

図50は、記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、ビデオエンコーダ501、素材制作部502、シナリオ生成部503、BDプログラム制作部504、多重化処理部505、フォーマット処理部506により構成される。
ビデオエンコーダ501は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG4-AVCやMPEG2などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部501aに書き込む。ビデオエンコーダ501は、ピクチャ間の相関特性を利用した画像圧縮をするために、8x8や16x16のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。
マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、8ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。
素材制作部502は、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックストリームなどの各ストリームを作成して、オーディオストリーム格納部502a、プレゼンテーショングラフィックスストリーム格納部502b、インタラクティブグラフィックストリーム格納部502cに書き込む。
オーディオストリーム作成にあたって素材制作部502は、非圧縮のLinearPCM音声などをAC3などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部502は、字幕イメージと表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるプレゼンテーショングラフィックスストリームを作成する。素材制作部502は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるインタラクティブグラフィックスストリームを作成する。
シナリオ生成部503は、素材制作部502で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BD-ROMフォーマットでシナリオを作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部503は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第1実施形態1および第2実施形態で説明したデータ構造となる。
BDプログラム制作部504は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ501が出力した奥行き情報を利用することができる。
多重化処理部505は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG2-TS形式のAVクリップを作成する。このとき、AVクリップと対になるクリップ情報ファイルも同時に作成する。
多重化処理部505は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。
フォーマット処理部506は、シナリオ生成部503で生成したBD-ROMシナリオデータと、BDプログラム制作部504で制作したBDプログラムファイル、多重化処理部505で生成したAVクリップやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成する。
また、この時ビデオエンコーダ501が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトは実施の形態1、2で説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。
(マネージドコピーを実現する記録装置としての実施)
記録装置は、マネージドコピーによってデジタルストリームの書き込むものでもよい。
マネージドコピーとは、BD-ROM等の読み出し専用記録媒体に記録されているデジタルストリームやプレイリスト情報、クリップ情報、アプリケーションプログラムを、別の光ディスク(BD-R,BD-RE,DVD-R,DVD-RW,DVD-RAM等)やハードディスク、リムーバブルメディア(SDメモリーカード、メモリースティック、コンパクトフラッシュ(登録商標)、スマートメディア、マルチメディアカード等)などの読み書き可能な記録媒体へコピーする際、サーバと通信を行い、認証が行われ許可された状態においてのみコピー実行可能にする技術である。この技術により、バックアップ回数を制限したり、課金された状態でのみバックアップを許す等の制御を行うことができる。
BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。
マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで“トランスコード”とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、AVクリップ、Clip情報、プレイリスト情報を得る必要がある。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
(立体視方式)
第1実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に24枚の映像を表示させるのに対して、左右の映像合わせて1秒に48枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら2方式に限定するものではない。
表示装置300についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
(3D映像を格納するためのIndex.bdmvのデータ構造)
プレイリストではなくインデックスファイルを、2D再生装置と3D対応再生装置で区別し、2D再生装置では再生開始時に「Index.bdmv」を参照するが、3D再生装置では「Index.3dmv」を選択させるといった方法もとることができる。

(複数ストリームを扱うためのデータ構造)
複数のストリームがある場合、上記のようにサブパス情報を使ってもよいし、マルチアングルのためのmulti_clip_entriesを使ってもよい。multi_clip_entriesを使う場合、表示装置の画面のサイズに合わせてストリームを選択した後は、誤って他の画面サイズ用のストリームに切り替わらないよう、アングル変更のUOを禁止することが望ましい。
(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。
同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
(記録層の構成)
BD-ROMの各記録層には、立体視/平面視共用領域と、立体視専用領域と、平面視専用領域とを設けることが望ましい。
立体視/平面視共用領域は、立体視映像の再生時と平面視映像の再生時との両方でアクセスされる領域であって、ベースビュービデオストリームファイルに属する複数のエクステントと、ディペンデントビューストリームを格納したファイルに属する複数のエクステントとが交互に配置されて記録された連続領域である。
立体視専用領域及び平面視専用領域は、立体視/平面視共用領域に後続しており、記録層の境界直前に存在する。
立体視専用領域は、立体視出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視/平面視共用領域に記録されたベースビュービデオストリームファイルに属するエクステントに後続するエクステントと、立体視/平面視共用領域に記録されたディペンデントビュービデオストリームファイルに属するエクステントに後続するエクステントとが交互に配置されて記録された領域である。
平面視専用領域は、2D出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視専用領域に記録されたベースビュービデオストリームファイルに属するエクステントの複製物が記録された領域である、
(プログラムの実施形態)
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA(登録商標)バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを1つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
(データ構造の記述の仕方)
上述したようなデータ構造のうち、ある決まった型の情報が複数存在するという繰り返し構造は、for文に、制御変数の初期値と、繰り返し条件とを設定することで定義することができる。Do While文を用いてもよい。
また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。この記述には、switch文、case文を用いてもよい。
このように、各実施形態に示したデータ構造は、高級プログラミング言語の文法によって記述することができるので、各実施形態に示したデータ構造は、構文解析、最適化、資源割付、コード生成といった、コンパイラによる翻訳過程を経て、上記プログラムと同様、コンピュータが読み取り可能なコンピュータコードに変換された状態で記録媒体に記録される。こうして、高級プログラミング言語によって記述されたデータ構造は、オブジェクト指向言語においては、クラス構造体のメソッド以外の部分、つまり、クラス構造体における配列型のメンバー変数として扱われ、プログラムの一部をなす。つまり、各実施形態のデータ構造は、コンピュータコードに変換されてコンピュータ読取可能な記録媒体記に記録され、プログラムのメンバー変数となる。こうした扱いがなされるので、これまでに述べたデータ構造は、実質的にはプログラムと同じものである。
(光ディスクの再生)
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及び暗号化タイトルキー)、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能(プログラム)といったものを一意に特定するための情報である。
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、
(1) 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック
(2) 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック
(3) 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック(例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック)
を行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。
上述の(1)〜(3)のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵(デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー)を用いて、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵(暗号化タイトルキーを復号して得られるタイトルキー)を利用してビデオストリームを復号し(デコードし)、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する(デコードする)。
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能(プログラム)などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報(公開鍵本体)を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号(例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等)は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の(1)の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域(第1の記録領域と称す)とは別の記録領域(第2の記録領域と称す)に設けること、およびこの第2の記録領域へのアクセスをするための制御回路を設けるとともに、第2の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
例えば、第2の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第2の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第2の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第2の記録領域に記録されたデータ(例えば半導体メモリ固有の識別番号)へのアクセス要求を発行すると、要求を受けた制御回路は第2の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第1の記録領域に記録するように構成すればよい。
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第2の記録領域に記録されたデータ(例えば半導体メモリ固有の識別番号)へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のX.509仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
また、半導体メモリーカードの第1の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。

(システムLSI)
再生装置の内部構成のうち、システムターゲットデコーダや、再生制御部7、プログラム実行部11等、ロジック素子を中心とした部分は、システムLSIで構成することがことが望ましい。
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置200の中核としての役割を果たす。
かかるシステムLSIは、再生装置200は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。
システムLSIのアーキテクチャは、Uniphierアーキテクチャに準拠させるのが望ましい。
Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。
・データ並列プロセッサDPP
これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。
・命令並列プロセッサIPP
これは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなる「Local Memory Controller」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「Processing Unit部」、複数アプリケーションの並列実行をProcessing Unit部に行わせる「Virtual Multi Processor Unit部」で構成される。
・MPUブロック
これは、ARMコア、外部バスインターフェイス(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(General Purpose Input Output)、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。
・ストリームI/Oブロック
これは、USBインターフェイスやATA Packetインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードリディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。
・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。
・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。
具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。

そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。
回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置200の内部構成図を基に作ることができる。
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUT(Look Up Table)に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。

本実施の形態は、ミドルウェアとシステムLSIに対応するハードウェア、システムLSI以外のハードウェア、ミドルウェアに対するインターフェイスの部分、ミドルウェアとシステムLSIのインターフェイスの部分、ミドルウェアとシステムLSI以外の必要なハードウェアへのインターフェイスの部分、ユーザインターフェースの部分で実現し、これらを組み込んで再生装置を構成したとき、それぞれが連携して動作することにより特有の機能が提供されることになる。
ミドルウェアに対するインターフェイス、および、ミドルウェアとシステムLSIのインターフェイスを適切に定義することにより、再生装置のユーザインターフェース部分、ミドルウェア部分、システムLSI部分をそれぞれ独立して並行開発することができ、より効率よく開発することが可能となる。なお、それぞれのインターフェイスのきり方には、様々な切り方がある。
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなクラスタ#3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ
100 BD-ROM
200 再生装置
300 テレビ
400 3D眼鏡
500 リモコン
1 BDドライブ
2a,b リードバッファ
4 システムターゲットデコーダ
5b プレーンメモリセット
5b プレーン合成部
6 HDMI送受信部
7 再生制御部
9 管理情報メモリ
10 レジスタセット
11 プログラム実行部
12 プログラムメモリ
13 HDMVモジュール
14 BD-Jプラットフォーム
15 ミドルウェア
16 モード管理モジュール
17 ユーザイベント処理部
18 ローカルストレージ
19 不揮発メモリ
23 PIDフィルタ
27 PIDフィルタ
31 プライマリビデオデコーダ
32 レフトビュービデオプレーン
33 ライトビュービデオプレーン
34 セカンダリビデオデコーダ
35 セカンダリビデオプレーン
36 PGデコーダ
37 PGプレーン
38 IGデコーダ
39 IGプレーン
40 プライマリオーディオデコーダ
41 セカンダリオーディオデコーダ
42 ミキサー
本発明は、3D映像及び2D映像の記録技術の技術分野に属する発明である
2D映像とは、表示装置の表示画面をX-Y平面として捉えて、このX-Y平面上の画素にて表現される画像であり、平面視画像とも呼ばれる。
対照的に3D映像とは、表示装置の画面におけるX-Y平面上の画素に、Z軸方向の奥行きを加えた画像である。3D映像は、左目で視聴すべきレフトビュー映像と、右目で視聴すべきライトビュー映像とを共に再生して、これらレフトビュー映像、ライトビュー映像で立体視効果を発揮することにより、ユーザによる視聴に供される。3D映像における画素のうち、正のZ軸座標をもつものをユーザは、表示装置の画面より手前にあると感じ、負のZ軸座標をもつものを、画面より奥に存在すると感じる。
光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置(以下、「2D再生装置」と呼ぶ)との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3D映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの2種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置(以下、「2D/3D再生装置」)では、2D映像もしくは3D映像として再生できることが求められる。
3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献1に記載されたものがある。
特許第3935507号公報
立体視再生では、レフトビューのビデオストリーム、ライトビューのビデオストリームを記録媒体に記録して、ユーザに視聴させる必要があるが、これらレフトビュービデオストリーム、ライトビュービデオストリームをどのような形式に変換しておくかが問題になる。一般的な記録形式は、レフトビュービデオストリーム、ライトビュービデオストリームをTSパケットレベルで多重化して、1つのトランスポートストリームとして記録するというものであるが、これでは、レフトビュービデオストリーム、ライトビュービデオストリームに割り当てることができるビットレートが低下してしまう。そのため画質の低下が発生しかねない。
ビットレート低下をさけるには、レフトビュービデオストリーム、ライトビュービデオストリームを別々のトランスポートストリームファイルに格納して、レフトビュービデオストリームを光ディスクから供給し、ライトビュービデオストリームをハードディスクから供給するという考えがある。この場合、光ディスク及びハードディスクの双方からTSパケットを供給することができるので、レフトビュービデオストリーム、ライトビュービデオストリームのそれぞれについて、ある程度のビットレートを確保することができる。しかしこの考えは、レフトビュービデオストリームを光ディスクによって供給し、ライトビュービデオストリームをネットワークから供給して、これらを組み合わせてユーザに再生させるという用途には向いているものの、1つの光ディスクに、レフトビュービデオストリーム、ライトビュービデオストリームを格納することができない。よってこの考えは、レフトビュービデオストリーム、ライトビュービデオストリームを1つの光ディスクに記録して、1つの商品として販売したり、店頭でレンタルするというビジネス形態に向いているとはいえず、映画作品の業界からは、余り歓迎されないと思われる。
ビットレートを確保しながらライトビュービデオストリーム、レフトビュービデオストリームを記録する方法には、いわゆるマルチアングル再生で実現されているように、レフトビュービデオストリーム、ライトビュービデオストリームを1つのインターリーブ形式のトランスポートストリームファイルに変換して、光ディスクに記録するという考えがある。
レフトビュービデオストリーム、ライトビュービデオストリームをインターリーブ形式に変換して1つのトランスポートストリームファイルに格納する格納形式においては、レフトビュービデオストリームを構成するエクステントと、ライトビュービデオストリームを構成するエクステントとで、Arrival Time Stamp(ATS)の値が連続になっていないので、再生時にあたっては、ATSが増えては減り、ATSが増えては減るという不規則な変化を繰り返すことになる。これは、通常のビデオストリームのATSの変化、つまり、ATSが単調増加するという変化とは異なるので、2D再生装置によって、かかるインターリーブ形式のトランスポートストリームファイルが2D再生装置による再生に供された場合は、2D再生装置の正常動作を保障できないという危険性がある。
本発明の目的は、3D再生装置と、2D再生装置との双方で再生されることを保障することができる記録媒体を提供することである。
上記課題を解決するため、本発明にかかる記録媒体は、プレイリスト情報と、ストリームファイルとが記録された記録媒体であって、前記プレイリスト情報は、1つ以上の再生区間情報を含み、
前記再生区間情報は、ビデオストリームを格納した前記ストリームファイルを指定するファイル参照情報を含み、
前記ストリームファイルは、インターリーブされたトランスポートストリームファイルと、通常形式のトランスポートストリームファイルであり、
前記インターリーブされたトランスポートストリームファイルは、レフトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分、及び、ライトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分のそれぞれを、交互に配置することで構成されており、前記ファイル参照情報と同じ識別番号と、インターリーブされている旨を示す拡張子とによって特定され、
前記通常形式のトランスポートストリームファイルは、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームの何れか一方であって、単独再生することができるベースビュービデオストリームを格納しており、前記ファイル参照情報と同じ識別番号と、通常形式である旨を示す拡張子とによって特定されることを特徴とする。
本発明では、インターリーブ形式のトランスポートストリームファイルは、ファイル参照情報と同じ識別番号と、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子とによって特定されるので、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のファイル参照情報と、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子とから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供すれば、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。
そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。
また、インターリーブ形式のトランスポートストリームファイルのエクステントのうち、ベースビュービデオストリームのエクステントは、プレイリスト情報に記述されたファイル参照情報と、通常形式のトランスポートストリームファイルである旨を示す拡張子とを用いることにより、アクセスすることができる。インターリーブ形式のトランスポートストリームファイルとは別に平面視のためのトランスポートストリームを記録しなくても、3D再生装置での立体視、2D再生装置で平面視の双方を実現することができるので、BD-ROM一枚に3Dの映画作品を記録してユーザに供給することが可能になる。インターリーブ形式のトランスポートストリームファイルとは別に、平面視のためのトランスポートストリームファイルを記録する必要がないので、3D映像のための記録媒体と、2Dのための記録媒体とを同梱して販売する必要がなく、3D映像のための記録媒体と、2D映像のための記録媒体とを別々の商品として販売にする必要もない。流通コストや小売店・卸売店における在庫管理コストの増大を招くこともないので、映画作品の業界は、既存の2D映像の映画作品を変わらぬ取り扱いをすることができる。
記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。 ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を表す動画像を描いた図である。 立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。 多層化された光ディスクの内部構成を示す。 ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。 記録方法の処理手順を示すフローチャートである。 PESパケット列に、ビデオストリームがどのように格納され、TSパケット及びソースパケットに変換されるかを示す。 AVクリップがどのように多重化されるかを模式的に示す図である。 記録方法により得られたエクステントの内部構成を示す。 エクステントと、トランスポートストリームファイルとの対応付けを示す図である。 インターリーブ形式のトランスポートストリームファイルと、レフトビューのトランスポートストリームファイルとをカップリングする方法について示している。 AVファイル書込程の処理手順を示すフローチャートである。 クリップ情報ファイルの内部構成を示す図である。 クリップ情報ファイルにおけるストリーム属性情報を示す図である。 クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。 エントリーマップによるエントリーポイントの登録を示す。 2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。 図17の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。 プレイリスト情報のデータ構造を示す図である。 サブパス情報テーブルの内部構成を示す図である。 レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。 ストリーム選択テーブルを示す。 図17の3Dプレイリストに、レフトビュー/ライトビュー識別情報を書き加えた図である。 レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。 2D/3D再生装置の構成を示している。 システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成を示す図である。 プレーン合成部5bの内部構成を示す図である。 PGプレーンの合成の仕方を示す図である。 オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。 レジスタセット10の内部構成及び再生制御エンジン7bの内部構成を示す図である。 出力モードの選択モデルの状態遷移を示す図である。 Initializationの処理手順を示すフローチャートである。 Procedure when playback condition is changedの処理手順を示すフローチャートである。 ストリーム選択プロシージャの処理手順を示すフローチャートである。 プレイリストの再生手順を示すフローチャートである。 再生制御エンジンの状態が停止中から3Dプレイリストに切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。 表示装置300、3D眼鏡400の内部構成を示す図である。 3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。 左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替える場合の、マルチチャネルモードにおける表示内容と、レフトビューの状態と、ライトビューの状態とを示す。 再生装置と、表示装置との接続態様を示す図である。 左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。 ビデオストリームとPGストリームとを組み合わせる場合の、組合せ情報の記述例である。 ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。 複数の3D方式を網羅できるPSRのビットアサインを示す図である。 表示装置が対応している3D再生方式をプレーヤセッティングレジスタに反映させる図である。 インデックステーブルと、ムービーオブジェクトとの関係を示している。 ストリーム選択の処理手順を示すフローチャートである。 記録装置の内部構成を示す図である。
(第1実施形態)
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目は、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、1つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
2つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の2つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
図1(a)は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。本図に示すように、記録媒体の一例であるBD-ROM100、再生装置200は、テレビ300、3D眼鏡400、リモコン500と共にホームシアターシステムを構成し、ユーザによる使用に供される。
BD-ROM100は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置200は、テレビ300と接続され、BD-ROM100を再生する。
テレビ300は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置300は、3D眼鏡400をユーザが着用することで立体視を実現するものだが、表示装置300がレンチキュラー方式のものなら、3D眼鏡400は不要となる。レンチキュラー方式の表示装置300は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
3D眼鏡400は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。 図1(b)は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡400は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図(c)は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
リモコン500は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン500は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
以上が、記録媒体及び再生装置の使用形態についての説明である。
本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。
視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図2は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
図3は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。
本図の第2段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。これらのピクチャデータは、Decode Time Stamp(DTS)に従いデコードされる。第1段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。 本図において、参照ピクチャを持たずに符号化対象ピクチャのみを用いてピクチャ内予測符号化を行うピクチャをIピクチャと呼ぶ。ピクチャとは、フレームおよびフィールドの両者を包含する1つの符号化の単位である。また、既に処理済の1枚のピクチャを参照してピクチャ間予測符号化するピクチャをPピクチャとよび、既に処理済みの2枚のピクチャを同時に参照してピクチャ間予測符号化するピクチャをBピクチャと呼び、Bピクチャの中で他のピクチャから参照されるピクチャをBrピクチャと呼ぶ。また、フレーム構造の場合のフレーム、フィールド構造のフィールドを、ここではビデオアクセスユニットと呼ぶ。
第4段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第3段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。
第5段目は、3D眼鏡400の状態をどのように変化させるかを示す。この第5段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。
例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。
このような視点間の相関特性を利用したビデオ圧縮の方法としては、Multiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共同プロジェクトであるJoint Video Team(JVT)は、2008年7月にMultiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。
そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、“ディペンデントビューストリーム”という。

次に、記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。
図4は、多層化された光ディスクの内部構成を示す。
第1段目は、多層化された光ディスクであるBD-ROMを示し、第2段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域から構成される。これらの第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域は、1つの連続した論理アドレス空間を構成する。
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。この一方、記録層の境界のように、連続的な読み出しが不可能な部分については、論理アドレスが連続していないものとする。
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROM100の場合ではUDF(Universal Disc Format)によって記録される。日常使っているPC(パーソナルコンピュータ)の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。
ファイルシステム上でアクセス可能なファイルのうち、ビデオストリーム及びオーディオストリームを多重化することで得られたAVストリームを格納しているファイルを“AVファイル”という。一方、AVストリーム以外の一般的なデータを格納しているファイルを“非AVファイル”という。
ビデオストリーム、オーディオストリームを始めとするPacktized Elementaryストリーム(PESストリーム)が、TSパケットに変換された上で多重化されているため、AVストリームがトランスポートストリーム形式になっているAVファイルを、「トランスポートストリームファイル」という。
これとは異なり、ビデオストリーム、オーディオストリームを始めとするPESストリームが、パック列に変換された上で多重化されているため、AVストリームがシステムストリーム形式になっているAVファイルを、「システムストリームファイル」という。
BD-ROM、BD-RE、BD-Rに記録されるAVファイルは、前者のトランスポートストリームファイルである。DVD-Video、DVD-RW,DVD-R,DVD-RAMに記録されるAVファイルは、後者のシステムストリームファイルであり、Video Objectとも呼ばれる。
第4段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第5段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。

図5は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。

BDMVディレクトリはBD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる5つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」,「MovieObject.bdmv」の2種類のファイルが配置されている。
「index.bdmv(ファイル名固定)」は、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BD-Jオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納している。インデックステーブルはBD-ROM全体に関する管理情報であり、再生装置へのディスク挿入後に、index.bdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルはBD-ROMに格納されるすべてのタイトル、トップメニュー、FirstPlayといったタイトル構成を定義する最上位層のテーブルである。インデックテーブルには、一般のタイトル、トップメニュータイトル、FirstPlayタイトルから最初に実行されるプログラムファイルが指定されている。BD-ROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにインデックステーブルを参照して、所定のプログラムファイルを実行する。ここで、FirstPlayタイトルとは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるプログラムファイルが設定されている。また、トップメニュータイトルは、リモコンでのユーザ操作で、「メニューに戻る」というようなコマンドが実行されるときに、呼び出されるムービーオブジェクト、BD-Jオブジェクトが指定されている。立体視に関する情報としてIndex.bdmvは、Initial_output_mode情報を有する。このInitial_output_mode情報は、Index.bdmvがロードされた場合に、再生装置の出力モードの初期状態がどうあるべきかを規定する情報であり、制作者サイドが希望する出力モードを、このInitial_output_mode情報に規定しておくことができる。
「MovieObject.bdmv(ファイル名固定)」は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。
「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo[“xxxxx”は可変、拡張子”bdjo”は固定])が存在する。このプログラムファイルは、バイトコードインタプリタであるJava(登録商標)仮想マシンを制御主体とした動作モード(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”は固定])が存在する。
“プレイリスト”とは、AVストリームの時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、複数のAVストリームのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報ファイルは、かかるプレイリストの“型”を定義するプレイリスト情報を格納している。再生制御のためのJava(TM)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(TM)仮想マシンに命じることで、AV再生を開始させることができる。JMF(Java Media Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi [“xxxxx”は可変、拡張子”clpi”は固定])が存在する。
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、トランスポートストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts([“xxxxx”は可変、拡張子”m2ts”は固定])という形式でトランスポートストリームファイルが格納される。
STREAMディレクトリにおけるトランスポートストリームファイルは、AVクリップを格納している。“AVクリップ”とは、AVストリームの“切れ端”のことであり、ビデオストリーム、オーディオストリーム、グラフィクスストリーム等、複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を可能するものをいう。AVクリップは、1秒,5秒,1分等、長短に拘らず、時間軸上において、ある限られた時間の再生を保障するものであれば足りる。
また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に対応するストリームの属性情報を持ち、またAVクリップに関する各種ディスクリプタを持つ。ディスクリプタにはトランスポートストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。
PMTの先頭には、そのPMTに含まれるデータの長さなどを記したPMTヘッダが配置される。その後ろには、AVクリップに関するディスクリプタが複数配置される。前述したコピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、トランスポートストリームファイルに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのPID、ストリームの属性情報(フレームレート、アスペクト比など)が記載されたストリームディスクリプタから構成される。ストリームディスクリプタはAVクリップに存在するストリームの数だけ存在する。
PAT(Program Association Table)は、AVクリップ中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルトランスポートストリームを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルトランスポートストリームを扱うかの如く、AVクリップをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、BD-ROM再生装置との互換性を意図したものである。
またAVクリップのうち、レフトビュービデオストリームの分割部分を格納したパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したパケット等、レフトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を保障するものを、“レフトビューAVクリップ”という。このレフトビューAVクリップが、ベースビュービデオストリームを含んでおり平面視再生を可能とするものなら、当該レフトビューAVクリップは、“2D/レフトビューAVクリップ”と称呼される。尚以降の説明では、特に断らない限り、レフトビュービデオストリームがベースビュービデオストリームであり、レフトビュービデオストリームを含むレフトビューAVクリップは、2D/レフトビューAVクリップであるものとする。
更にAVクリップのうち、ライトビュービデオストリームの分割部分を格納したソースパケット、ライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間の連続再生を保障するものを、“ライトビューAVクリップ”という。
CLIPINFディレクトリに格納されるクリップ情報ファイルとは、レフトビューAVクリップ又はライトビューAVクリップが、どのようなパケットの集合体であるか等、AVクリップの詳細を、個々のAVクリップ毎に示した情報であり、対応するAVクリップの再生に先立ちメモリに読み出され、そのAVクリップの再生が継続している間、再生装置内で参照に供される情報である。
以上が記録媒体の内部構成についての説明である。続いて、図4及び図5に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマッレコーディングによる記録方法によっても特定されるものでもある。
図6は、記録方法の処理手順を示すフローチャートである。
ステップS301は、BD-ROMのタイトル構造を決定する程である。これによりタイトル構造情報が作成される。タイトル構造情報とは、木構造を用いて、BD-ROMにおける再生単位の関係、例えば、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する情報である。具体的にいうと、タイトル構造情報は、制作しようとするBD-ROMの「ディスク名」に対応するノード、そのBD-ROMにおいて、Index.bdmvから再生可能となる「タイトル」に対応するノード、そのタイトルを構成する「ムービーオブジェクト及びBD-Jオブジェクト」に対応するノード、当該ムービーオブジェクト及びBD-Jオブジェクトから再生される「プレイリスト」のノードを規定して、これらノードを、エッジ(辺)で結び付けることで、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する。
ステップS302は、タイトルに利用する動画、音声、静止画、字幕情報のインポートを行う程である。
ステップS303は、GUIを経由したユーザ操作に従った編集処理をタイトル構造情報に施すことにより、BD-ROMシナリオデータを作成する程である。ここでBD-ROMシナリオデータとは、AVストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、BD-ROMではインデックステーブル、ムービーオブジェクト、プレイリストとして定義されている情報がシナリオにあたる。BD-ROMシナリオデータには、ストリームを構成する素材情報、再生区間、再生経路を示す情報、メニュー画面配置、メニューからの遷移情報などを含む。
ステップS304は、エンコード程であり、BD-ROMシナリオデータに基づきエンコードを行って、PESストリームを得る。
ステップS305は、BD-ROMシナリオデータに従った多重化程であり、この程によってPESストリームを多重化してAVクリップを得る。
ステップS306では、BD-ROMへの記録のためのデータベースを得る。ここでのデータベースとは、前述のBD-ROMで定義されるインデックステーブル、ムービーオブジェクト、プレイリスト、BD-Jオブジェクトなどの総称である。
ステップS307では、Java(TM)プログラム、多重化程で得られたAVクリップ、BD-ROMデータベースを入力とし、BD-ROMに準拠したファイルシステムフォーマットでAVファイル,非AVファイルを作成する。
ステップS308は、BD-ROMに記録されるべきデータのうち、非AVファイルの書込程であり、ステップS309は、AVファイルの書込程である。
ステップS305の多重化程は、ビデオストリーム、オーディオストリーム、グラフィクスストリームをPESストリームに変換した上、トランスポートストリームに変換する第1変換程、トランスポートストリームを構成する個々のTSパケットを、ソースパケットに変換する第2変換程を含み、動画像、音声、グラフィクスを構成するソースパケット列を、多重化するものである。
ステップS309のAVファイル書き込み程は、ソースパケット列をAVファイルのエクステントとして、記録媒体の連続領域に書き込むものである。
書き込みの対象となるストリームは、以下の通りである。
・ビデオストリーム
ビデオストリームは映画のプライマリビデオおよびセカンダリビデオを示す。ここでプライマリビデオとはピクチャインピクチャにおいて親画像として表示される通常の映像を示し、セカンダリビデオとは、ピクチャインピクチャにおいて小画面で表示される映像のことである。プライマリビデオには、レフトビュービデオ、ライトビュービデオの2種類があり、セカンダリビデオにも、レフトビュービデオ、ライトビュービデオの2種類がある。
ビデオストリームは、上述したMVCの他、MPEG-2、MPEG-4AVC、または、SMPTE VC-1などの方式を使って符号化記録されている。
・オーディオストリーム
オーディオストリームは、映画の主音声部分を示す。オーディオストリームは、ドルビーAC-3、Dolby Digital Plus、MLP、DTS、DTS-HD、または、リニアPCMのなどの方式で圧縮・符号化記録されている。オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの2種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。
・Presentation Graphicsストリーム
Presentation Graphicsストリーム(PGストリーム)は、映画の字幕や、キャラクタ等、ピクチャと緻密に同期すべきグラフィクスを示すグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。
PGストリームは、PCS(Presentation Control Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(Object Define Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。
WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS(Pallet Define Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
グラフィクスストリームの再生において、グラフィクスデコーダは、ある表示単位に属するODSをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行表示単位に属するODSをデコードすることにより得られたグラフィクスオブジェクトをプレーンメモリに書き込む処理とをパイプラインで実行し、ハードウェアをフル駆動することで、上述したような緻密な同期を実現する。
トランスポートストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。このPGストリームと、textSTストリームとの組みは、BD-ROM規格において、“PGTextSTストリーム”と呼ばれる。
・Interactive Graphicsストリーム
Interactive Graphicsストリーム(IGストリーム)は、リモコンを通じた対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(Interactive Composition Segment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)と呼ばれる機能セグメントからなる。ODS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(Interactive Composition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。インタラクティブグラフィックスストリームは、画面上にGUI部品を配置することにより作成される対話画面を示している。
図7(a)は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目はビデオストリームのビデオフレーム列を示す。第2段目は、PESパケット列を示す。第3段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy1,yy2, yy3, yy4に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS(Presentation Time-Stamp)やピクチャの復号時刻であるDTS(Decoding Time-Stamp)が格納される。

<TSパケット列>
図7(b)は、AVクリップに最終的に書き込まれるTSパケットの形式を示している。第1段目は、TSパケット列を示し、第2段目は、ソースパケット列を示
第1段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ4Byteの「TSヘッダ」とデータを格納する184Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第2段目によると、TSパケットには、4ByteのTP_Extra_Headerが付与されて、192Byteのソースパケットに変換された状態で、AVクリップに書き込まれる。TP_Extra_HeaderにはATS(Arrival_Time_Stamp)などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。AVクリップには、第3段目に示すようにソースパケットが並ぶこととなり、AVクリップの先頭からインクリメントする番号はSPN(ソースパケットナンバー)と呼ばれる。
<AVクリップにおける多重化>
図8は、レフトビューAVクリップがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを(第1段目)、それぞれPESパケット列に変換し(第2段目)、ソースパケット列に変換する(第3段目)。同じくレフトビュープレゼンテーショングラフィックスストリームおよびレフトビューインタラクティブグラフィックス(第7段目)を、それぞれPESパケット列に変換し(第6段目)、更にソースパケット列に変換する(第5段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、レフトビューAVクリップが得られることになる。このレフトビューAVクリップは、リードバッファがアンダーフローしないサイズに定められており、記録媒体への記録の対象になる。
Arrival Time Clock(ATC)時間軸において、ATSが連続しているソースパケットの集まりをATCシーケンスといい、System Time Clock(STC)時間軸においてデコードタイムスタンプ(DTS),プレゼンテーションタイムスタンプ(PTS)が連続しているソースパケットの集まりを、STCシーケンスという。
図9は、記録方法により得られたエクステンを示す。第1段目は、AVファイルを構成するエクステントEXT_L[i],EXT_L[i+1],EXT_R[i],EXT_R[i+1]を示す。
第2段目は、各エクステント内に属するソースパケット列を示す。
この第1段目におけるエクステントは、ライトビューAVクリップを構成するソースパケットのグループと、レフトビューAVクリップを構成するソースパケットのグループとを、インターリーブ配置したものである。本図におけるインターリーブ配置とは、ライトビューAVクリップを構成するソースパケット集合と、レフトビューAVクリップを構成するソースパケット集合とが、一個のエクステントとして、"ライトビュー"、"レフトビュー"、"ライトビュー"、"レフトビュー"・・・・・という規則性をもって記録されていることである。
ここで、括弧書きにおける変数i,i+1は、何番目のエクステントとして再生されるかを示す。この記法からすると、変数iによって指示される2つのエクステント、つまり、EXT_L[i],EXT_R[i]は同時に再生され、変数i+1によって指示される2つのエクステント、つまり、EXT_L[i+1],EXT_R[i+1]は同時に再生されることがわかる。
エクステントEXT_L[i]のサイズをSEXT_L[i]と呼び、エクステントEXT_R[i]のサイズをSEXT_R[i]と呼ぶ。
これらSEXT_L、SEXT_Rのサイズをどのように定めるかについて説明する。ここでのエクステントは、再生装置においてライトビュー用リードバッファ、レフトビュー用リードバッファという2つのバッファに交互に読み出されてビデオデコーダに供される。そうすると、SEXT_L、SEXT_Rのサイズは、ライトビュー用リードバッファ及びレフトビュー用リードバッファをバッファフルにする時間を考慮して定める必要がある。つまり、ライトビュー用リードバッファへの転送レートを、Rmax1とすると、

ライトビュー用リードバッファ=Rmax1×"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"

という関係を満たすよう、ライトビュー用リードバッファの容量を定めねばならない。ここでジャンプとは、ディスクシークと同義である。何故なら、BD-ROMにおいて記録に確保できる連続領域は有限であり、レフトビュービデオストリーム及びライトビュービデオストリームは、必ずしも、隣合わせで記録されるとは限らず、飛び飛びの領域に記録されることも有り得るからである。
続いて"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"について考える。レフトビュー用リードバッファにおけるTSパケット蓄積は、Rud-Rmax2という転送レートでなされる。これは、レフトビュー用リードバッファからの出力レートRmax2と、レフトビュー用リードバッファへの入力レートRudとの差分を意味する。そうすると、レフトビュー用リードバッファをフルにする時間は、RB2/(Rud-Rmax2)となる。

レフトビュー用リードバッファにデータを読み出すにあたっては、ライトビューAVクリップからレフトビューAVクリップへのジャンプ時間(Tjump)と、レフトビューAVクリップからライトビューAVクリップへのジャンプ時間(Tjump)とを考慮する必要があるので、
レフトビュー用リードバッファの蓄積には(2×Tjump+RB2/(Rud-Rmax2))という時間が必要になる。
ライトビュー用リードバッファの転送レートをRmax1とすると、上述したレフトビュー用リードバッファの蓄積時間において、Rmax1という転送レートで、ライトビュー用リードバッファ内の全てのソースパケットは出力されねばならないから、ライトビュー用リードバッファのサイズRB1は、

RB1≧Rmax1×[2×Tjump+RB2/(Rud-Rmax2)]

になる。

同様の手順で、レフトビュー用リードバッファの容量RB2を求めると、

RB2≧Rmax2×[2×Tjump+RB1/(Rud-Rmax1)]

になる。
ライトビュー用リードバッファ,レフトビュー用リードバッファのメモリサイズの具体的な値としては、1.5Mbyte以下であり、本実施形態においてエクステントサイズSEXT_R、SEXT_Lは、このライトビュー用リードバッファ,レフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。以上がレフトビューAVクリップ、ライトビューAVクリップの記録のされ方についての説明である。続いて、レフトビューAVクリップ及びライトビューAVクリップの内部構成について説明する。図9の第1段目を参照しながら、エクステントEXT_R[i]、エクステントEXT_L[i]の内部構成について説明する。
エクステントEXT_L[i]は、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはProgram_Mapを構成し、0x1001のパケットIDをを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケットはレフトビュービデオストリーム、
0x1220〜123FのパケットIDを有するソースパケットはレフトビューPGストリーム、
0x1420〜143FのパケットIDを有するソースパケットは レフトビューIGストリーム
0x1100から0x111FまでのPIDを有するソースパケットはオーディオストリームを構成する。
エクステントEXT_R[i]は、以下のソースパケットによって構成されている。
Ox1012のTSパケットはライトビュービデオストリームを構成し、Ox1240〜125FのソースパケットはライトビューPGストリームを構成し、Ox1440〜145FのソースパケットはライトビューIGストリームを構成する。
(ボリューム領域におけるエクステントの位置付け)
エクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号(LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号(LBN)を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。
「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261”が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号(LBN)を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位2ビットは、“0”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“1”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“0”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
上述したようなファイルエントリーのアロケーション識別子を参照することで、プレイリスト情報ファイル、クリップ情報ファイル、トランスポートストリームファイル、BD-Jオブジェクトファイル、JARアーカイブファイルを構成するエクステントのアドレスを知得することができる。
本願の主眼となるトランスポートストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
上述したようなAVストリーム、Index.bdmv、JARファイル、BD-Jオブジェクトは、ファイル構造、ディレクトリ構造に従ってBD-ROMに記録されているので、再生装置は、ファイルオープンのためのシステムコールを行うことで、これらをメモリに読み出すことができる。
ファイルオープンとは、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCB(File Control Block)を確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。そして、このファイルオープンにあたって、拡張子がm2tsのトランスポートストリームファイルは、STREAMディレクトリを用いたファイルパスによって特定される。拡張子がssifのトランスポートストリームファイルは、STEAMディレクトリと、SSIFディレクトリとを用いたファイルパスによって特定されることになる。これらは、STEAMディレクトリ、SSIFディレクトリに配置されているからである。
上述したようなファイル構造において、図9に示したエクステントがどのように取り扱われているかについて説明する。
図10は、エクステントと、トランスポートストリームファイルとの対応付けを示す図である。
第1段目は、通常のトランスポートストリーム形式のトランスポートストリームファイルである00001.m2ts,00002.m2tsを示し、第2段目は、ライトビューのエクステント、レフトビューのエクステントを示す。第3段目は、インターリーブ形式のトランスポートストリームファイルである00001.ssifを示す。
破線の矢印h1,h2,h3,h4は、エクステントEXT_R[i],EXT_L[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT_L[i],EXT_L[i+1]は、00001.m2tsのエクステントとして登録されていることがわかる。
矢印h3,h4に示される帰属関係によると、エクステントEXT_R[i],EXT_R[i+1]は、00002.m2tsのエクステントとして登録されていることがわかる。
矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT_R[i],EXT_L[i],EXT_R[i+1],EXT_L[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT_L[i],EXT_L[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この“ssif”という拡張子は、StereoScopic Interleave Fileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。
図11は、対応するレフトビューAVクリップと、ライトビューAVクリップとをカップリングする方法について示している。
同図、トランスポートストリームファイルが、どのようなエクステントによって構成されているかを示す。
これらのうち、エクステントEXT_L[i],EXT_L[i+1]は、2D映像として再生されるものである。
3D映像を含むBD-ROMであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2DのAVクリップにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。
1つ目の方法は、レフトビューは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のトランスポートストリームファイルは拡張子を変える方法である。同図左下における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名“00001”によってカップリングされている。
プレイリストはレフトビューのAVクリップしか参照しないため、既存の2D再生装置では2D用のAVクリップしか再生しない。3D対応の再生装置は、プレイリストはレフトビューの入ったAVクリップしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のトランスポートストリームファイルであると判断して、レフトビューとライトビューとを出力する。
2つ目の方法は、フォルダを分ける方法である。レフトビューは既存のフォルダ名(例:STREAM)を持つフォルダ内に格納しておくが、拡張であるライトビューは、3D特有の名前を持つフォルダ(例:SSIF)に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照する際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、レフトビューとライトビューを関連づけることが可能となる。
3つ目の方法は、識別番号によるものである。レフトビューの識別番号が“00001”である場合、ライトビューの識別番号は、このレフトビューの識別番号に“1”を加算した番号、つまり、“0002”という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。この例ではレフトビューの識別番号に“1”を加算したものをライトビューの識別番号としたが、レフトビューの識別番号に、“10000”を加算したものをライトビューの識別番号として採用してもよい。
この例では、既存の2D再生装置が再生する映像はレフトビューであるとして記載しているが、実際はどちらでもよく、また、プレイリスト内にどちらの映像が規定映像として再生されているか識別するための情報があってもよい。
カップリング方式を実現する場合には、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。
以上がAVクリップを格納したトランスポートストリームファイルについての説明である。続いて、上述したようなトランスポートストリームファイルをどのようにして記録媒体に記録するか、つまり、AVファイルをAVデータ領域に書き込むための程(AVファイル書込程)の詳細について説明する。
図12は、AVファイル書込程の処理手順を示すフローチャートである。
ステップS401において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップS402は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップS403〜ステップS408を実行する。確保し得ない場合は、ステップS409で例外処理をした後、記録方法を終了する。
ステップS403〜ステップS408は、ステップS407がNoと判定されるまで、ステップS403〜ステップS406、ステップS408の処理を繰り返すループを構成している。
ステップS403において、空きの連続セクタ領域にレフトビューAVクリップを構成するソースパケット列をSEXT_L[i]だけ書き込み、ステップS404において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。
ステップS405において、空きの連続セクタ領域にライトビューAVクリップを構成するソースパケット列をSEXT_R[i]だけ書き込み、ステップS406において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。
ステップS407は、ループの終了条件を規定するものであり、ライトビューAVクリップ、レフトビューAVクリップに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップS408に移行して、ループを継続する。存在しなければ、ステップS410に移行する。
ステップS408は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップS403に移行し、存在しなければ、ステップS402まで戻る。
ステップS410では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップS411では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップS412では、レフトビューAVクリップ、ライトビューAVクリップのうち、ベースビュービデオストリームを含むもののエクステントの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップS412では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。
以上がAVファイル書込程についての説明である。続いてクリップ情報ファイルについて説明する。
<クリップ情報ファイル>
図13は、クリップ情報ファイルの内部構成を示す図である。クリップ情報ファイルは、本図に示すようにAVクリップの管理情報であり、AVクリップと1対1に対応している。引き出し線ch1は、クリップ情報ファイルの内部構成をクローズアップして示している。この引出線に示すように、クリップ情報ファイルは、「クリップ情報」と、「ストリーム属性情報」と、「エントリマップテーブル」と、「3Dメタデータ」とから構成される。
クリップ情報は、引出線ch2に示すように「システムレート」、「再生開始時間」、「再生終了時刻」から構成されている。システムレートはAVクリップを構成するTSパケットを、後述するシステムターゲットデコーダのPIDフィルタに転送するための最大転送レートを示す。AVクリップ中に含まれるATSの間隔はシステムレート以下になるように設定されている。再生開始時間はAVクリップの先頭のビデオフレームのPTSであり、再生終了時間はAVクリップの終端のビデオフレームのPTSに1フレーム分の再生間隔を足したものが設定される。
図14は、クリップ情報ファイルにおけるストリーム属性情報を示す図である。
図中の引き出し線ah1は、ストリーム属性情報の内部構成をクローズアップして示している。
この引出線に示すように、PID=0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性情報、PID=0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性情報、PID=0x1100、PID=0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性情報、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性情報というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性情報に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。
図15は、クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。 本図(a)は、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、『エントリマップヘッダ情報』、『エクステント開始タイプ』、『PID=0x1011についてのエントリーマップ』、『PID=0x1012についてのエントリーマップ』、『PID=0x1220についてのエントリーマップ』、『PID=0x1221についてのエントリーマップ』を含む。
『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。
『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。
『PID=0x1011についてのエントリーマップ』、『PID=0x1012についてのエントリーマップ』、『PID=0x1220についてのエントリーマップ』、『PID=0x1221についてのエントリーマップ』は、複数種別のソースパケットによって構成されるPESストリームのそれぞれについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報を“エントリポイント”と呼ぶ。また先頭を“0”として各エントリポイント毎にインクリメントした値をエントリポイント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ピクチャが存在する場合、このフラグはオフに設定される。
同図(b)は、(a)に示した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と対応付けている。
図16は、エントリーマップによるエントリーポイントの登録を示す。第1段目は、STCシーケンスにて規定される時間軸を示す。第2段目は、クリップ情報におけるエントリーマップを示す。第3段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうちSPN=n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける=n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち=n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおける=n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するAVクリップのファイル位置を特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。
以上がエントリーマップテーブルについての説明である。続いて、3Dメタデータの詳細について説明する。
3Dメタデータとは、立体視再生に必要となる様々な情報を規定したメタデータ群であり、複数のオフセットエントリーを含む。個々のオフセットエントリーは、複数のPID、複数の表示時刻に対応付けられている。そしてあるPIDのPESストリームを再生する際、そのPESストリームの複数の表示時刻において、どれだけのオフセットを用いて、立体視を実現すべきかをPID毎及び表示時刻毎に規定できるようになっている。
以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
デコーダや表示プレーンの構成が異なるため、2D再生、3D再生の切り替えをシームレスに行うことは困難である。そのため、シームレスな切り替えが発生する可能性があるプレイアイテム同士において、2Dと3Dの切り替えを行うことは難しい。
図17は、2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。混在をなくすことにより、再生装置の再生環境の切り替えを発生させないようにしている。本図のプレイリストは、「メインパス」、1つ以上の「サブパス」から構成される。
「メインパス」は、1つ以上のプレイアイテムから構成される。図中の例では、プレイアイテム#1、#2、#3から構成されていることがわかる。
「サブパス」は、メインパスと一緒に再生される一連の再生経路を示し、プレイリストに登録される順にID(サブパスID)が振られる。サブパスIDは、サブパスを識別するために使われる。サブパスには、メインパスの再生に同期して再生される同期型、メインパスの再生に非同期で再生可能な非同期型があり、そのタイプはサブパスタイプに記される。サブプレイアイテムは、1つ以上のサブプレイアイテム情報から構成される。
また「プレイアイテム」は、ストリーム選択テーブルを含む。ストリーム選択テーブルは、プレイアイテム及びサブプレイアイテムにおいて再生が許可されているエレメンタリストリームのストリーム番号を示す情報である。プレイリスト情報、プレイアイテム情報、サブプレイアイテム情報、ストリーム選択テーブルの詳細については、後の実施形態に説明の場を譲る。
「AVクリップ#1,#2,#3」は、2D映像として再生されるAVクリップであるとともに、3D映像として再生する時にはレフトビューとして再生されるAVクリップである。
「AVクリップ#4,#5,#6」は3D映像として再生する時にはライトビューとして再生されるAVクリップである。
2Dプレイリストのメインパスは、レフトビューAVクリップを格納するAVクリップ#1,#2,#3を符号rf1,2,3に示すように参照している。
3Dプレイリストは、レフトビューAVクリップを符号rf4,rf5,rf6に示すように参照しているプレイアイテムを含むメインパスとともに、ライトビューを参照するためのサブパスが用意されていて、このサブパスが、ライトビューを格納するAVクリップ#4,#5,#6を、符号rf7,8,9に示すように参照している。このサブパスは、メインパスと時間軸上で同期するように設定される。この構造により、2Dプレイリストと3Dプレイリストで、レフトビューが格納されたAVクリップを共有することができ、3Dプレイリストではレフトビューとライトビューを時間軸上で同期させて関連付けることができる。
本図の3Dプレイリスト、2Dプレイリストは何れもプレイアイテム情報#1〜#3が、共通のAVクリップであるAVクリップ#1〜#3を参照しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。
図18は、図17の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図17のプレイリストは、サブパスID=0のサブパスのみを具備していたのに対して、図18のプレイリストにおける2つ目のサブパスは、サブパスID”=1”によって識別されるものであり、AVクリップ#7、#8、#9を参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、AVクリップ群がその角度の数だけ用意されていて、角度ごとにサブパスを設けている。
図18の例では、AVクリップ#1,#2,#3とAVクリップ#4,#5,#6は共にライトビューを格納しているが、右目から被写体を見る角度が異なる。サブパスIDが「0」のサブパスはAVクリップ#4,#5,#6を符号rf7,8,9に示すように参照し、サブパスIDが「1」のサブパスはAVクリップ#7,#8,#9を符号rf10,rf11,rf12に示すように参照する。表示装置の画面の大きさやユーザからの嗜好に基づいて、レフトビューを格納するメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。
この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図18の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。
図19は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、「メインパス情報」、「サブパス情報テーブル」、「エクステンションデータ」、「マーク情報」を含む。
先ず始めに、メインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報#1・・・・#Nから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線mp2によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVクリップの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVクリップの符号化方式を示す『Clip_codec_identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection_condition』と、このPlayItemが対象としているSTC_Sequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO_mask_table』と、『STN_table』と、『レフトビュー/ライトビュー識別情報』と、『multi_clip_entry』とから構成される。
以降、『STN_table』、『レフトビュー/ライトビュー識別情報』、『multi_clip_entry』について説明する。
『STN_table(STream Number_table)』は、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。このSTN_tableは、2D再生のためのものであり、3D再生のためのSTN_tableは別に存在する。
『レフトビュー/ライトビュー識別情報』は、レフトビュービデオストリーム、ライトビュービデオストリームのうち、どちらかベースビュービデオストリームであるかを指定するベースビュービデオストリーム指定情報であり、0ならばレフトビュービデオストリームが、ベースビュービデオストリームであることを示し、1ならばベースビュービデオストリームがライトビュービデオストリームであることを示す。
『connection_condition』は、前方プレイアイテムと接続タイプを示している。プレイアイテムのconnection_conditionが「1」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレス接続が保証されないことを示す。プレイアイテムのconnection_conditionが「5」か「6」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレスに接続されることが保証される。
connection_conditionが「5」の場合は、プレイアイテム間でSTCの連続性が途切れていても良く、つまり、接続前プレイアイテムのAVクリップ終端のビデオ表示時刻よりも、接続後プレイアイテムのAVクリップ先頭のビデオ表示時刻開始時刻は不連続でよい。ただし、接続前プレイアイテムのAVクリップを後述するシステムターゲットデコーダのPIDフィルタに入力した後に続けて、接続後プレイアイテムのAVクリップをシステムターゲットデコーダのPIDフィルタに入力して再生したときに、システムターゲットデコーダのデコードが破綻しないようにAVクリップを作成する必要がある。また接続前プレイアイテムのAVクリップのオーディオの終端フレームと、接続後プレイアイテムのオーディオの先頭フレームは再生時間軸で重ならなければならないなどの制約条件がある。
また、connection_conditionが「6」の場合は、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップを結合したときに1本のAVクリップとして再生できなければならない。つまり、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップ間でSTCは連続し、またATCも連続する。
『Multi_clip_entries』は、プレイアイテムでマルチアングル区間を形成する場合、個々のアングル映像を表すAVクリップがどれであるかを特定するための情報である。
以上がメインパス情報についての説明である。続いて、サブパス情報テーブルの詳細について説明する。
図20は、サブパス情報テーブルの内部構成を示す図である。引き出し線su1は、サブパス情報の内部構成をクローズアップして示している。引出線su1に示すように、サブパス情報テーブルは複数のサブパス情報1,2,3・・・mを含む。これらのサブパス情報は、1つのクラス構造体から派生した複数のインスタンスであり、その内部構成は共通のものなる。引き出し線su2は、Subpath情報の共通の内部構成をクローズアップして示している。この引き出し線に示すように、各Subpath情報は、サブパスの類型を示すSubPath_typeと、1つ以上のサブプレイアイテム情報(・・・サブプレイアイテム情報#1〜VOB#m・・・)とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、サブプレイアイテム情報は、『Clip_information_file_name』、『Clip_codec_identifier』、『ref_to_STC_id[0]』、『SubPlayItem_In_time』、『SubPlayItem_Out_time』、『sync_PlayItem_id』、『sync_start_PTS_of_PlayItem』からなる。以降、SubPlayItemの内部構成について説明する。
『Clip_information_file_name』は、クリップ情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip_codec_identifier』は、AVクリップの符号化方式を示す。
『ref_to_STC_id[0]』は、このSubPlayItemが対象としているSTC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。
『SubPlayItem_Out_time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
『sync_PlayItem_id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem_In_timeは、このsync_PlayItem_idで指定されたPlay Itemの再生時間軸上に存在する。
『sync_start_PTS_of_PlayItem』は、sync_PlayItem_idで指定されたPlay Itemの再生時間軸上において、SubPlayItem_In_timeで指定されたSubPlayItemの始点が、どこに存在するかを45KHzの時間精度で示す。
図21は、レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。本図は、図16をベースとして作図されており、このベースとなる図の第2段目の時間軸に、PlayItemのIn_Time及びOut_Timeを描いている。第1段目の時間軸に、SubPlayItemのIn_Time及びOut_Timeを描いている。第3段目から第5段目は、図16の第3段目から第5段目と同一である。レフトビュー、ライトビューのIピクチャは、時間軸において同じ時点になる。以上がプレイリスト情報のデータ構造についての説明である。
以上がサブパス情報についての説明である。続いて、エントリーマーク情報の詳細について説明する。
エントリマーク情報はプレイアイテムで定義される再生区間内に対して付与することでき、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマークをチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。
以上がエントリーマーク情報についての説明である。続いて、エクステンションデータの詳細について説明する。
エクステンションデータは、2Dプレイリストとは互換がない、3Dプレイリスト特有の拡張部分であり、ここにSTN_table_SS#1〜#Nが格納される。STN_table_SSは、それぞれが複数のプレイアイテム情報のそれぞれに対応していて、3D再生用のストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_table_SSにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。プレイアイテム情報内のSTN_tableと、エクステンションデータ内のSTN_table_SSとを組合せることで、ストリーム選択テーブルが構成されることになる。
続いて、上述したPlayItem情報の内部構成のうち、ストリーム選択テーブルの詳細について説明する。
図22(a)は、ストリーム選択テーブルを示す。ストリーム選択テーブルは、複数のストリームエントリから構成される。このストリームエントリーは、図中の括弧記号“}”に示すように、STN_table内で定義されるものと、STN_table_SS内で定義されるものとがある。
STN_tableのストリームエントリーには、2D出力モードの設定時において、再生可能となる2D用の音声/PG/IGが登録される。そのため、STN_tableの中には、2Dビデオストリームエントリー群、2Dオーディオストリームエントリー群、2DPGストリームエントリー群、2DIGストリームエントリー群が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。
STN_table_SSのストリームエントリーには、立体視再生モードの設定時において、再生可能となる3D用の音声/PG/IGが登録される。そのため、STN_table_SSの中には、3Dビデオストリームエントリー群、3Dオーディオストリームエントリー群、3DPGストリームエントリー群、3DIGストリームエントリー群、ストリーム組合せ情報が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。
同図(b)は、ストリームエントリーの共通構成を示す図である。本図に示すように、ストリーム選択テーブルにおけるストリームエントリは、『ストリーム選択番号』、『ストリームパス情報』、『ストリーム識別情報』から構成される。
『ストリーム選択番号』は、ストリーム選択テーブルに含まれるストリームエントリ1の先頭から順にインクリメントされる番号であり、再生装置でのストリーム識別のために利用される。
『ストリームパス情報』は、ストリーム識別情報によって示されるストリームが、どのAVクリップに多重化されているかを示す情報であり、例えば”メインパス”であれば、該当するプレイアイテムのAVクリップを示し、”サブパスID=1”であれば、そのサブパスIDが示すサブパスにおいて、該当するプレイアイテムの再生区間に対応するサブプレイアイテムのAVクリップを示す。
『ストリーム識別情報』は、PIDなどの情報であり、参照するAVクリップに多重化されているストリームを示す。また、ストリームエントリには、各ストリームの属性情報も同時に記録されている。ここで属性情報とは、各ストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。
STN_table_SSにおいて、レフトビュービデオストリームのストリームエントリとライトビュービデオストリームのストリームエントリとでは、例えばフレームレートや解像度、ビデオフォーマットなどは同じ値になる。ストリームエントリには、レフトビュービデオストリームなのか、ライトビュービデオストリームなのかが分かるフラグが用意されることがある。
以上がストリーム選択テーブルについての説明である。続いて、レフトビュー/ライトビュー識別情報の詳細について説明する。
ここまでの記載は、レフトビュー用をメインとし、2D表示の場合はレフトビューが表示されることを前提に説明しているが、ライトビューがメインでもよい。プレイリストに左目/ライトビューのどちらがメインであるか、2Dの場合に表示されるかを判別する情報に従い、ベースビュービデオストリームであるものとする。その判別の情報が、レフトビュー/ライトビュー識別情報である。
一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すレフトビュー/ライトビュー識別情報をプレイアイテム情報毎に設定できるようにしている。
図23は、図17の3Dプレイリストに、レフトビュー/ライトビュー識別情報を書き加えた図である。この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。
各ストリームとレフトビュー/ライトビューの識別情報は、表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。
また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。
以上がレフトビュー/ライトビュー識別情報についての説明である。このレフトビュー/ライトビュー識別情報は、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。しかし視差画像の内容によっては、このように平面視画像として利用することに向いていないことがある。
以下、平面視画像として利用することに不向きなレフトビュー画像、ライトビュー画像について説明する。
図24は、レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。図中の右下は、映像中の恐竜が、ユーザの目の前にまで迫ってくるような画面効果を狙っている立体視画像を示す。この立体視画像は、その上に記載されているような、L画像、R画像によって構成される。飛び出し効果が大きい立体視画像を構成するL画像、R画像は、飛び出して現れる画像中の対象(本図では恐竜)を、側面から表示するようになっている。これらのうち、レフトビュービデオストリームを、平面視用のビデオストリームとして使用する場合、横長の物体が横たわっているように見えてしまい、おかしなものになる。そこで、2Dモードに設定されている場合、センター画像を表すビデオストリームを指定する、プレイリスト情報をカレントプレイリストとして選ぶようにする。
本図において、00005.mplsは、飛び出し度合が大きいレフトビュービデオストリーム、及び、ライトビュービデオストリームを、メインパス情報及びサブパス情報として指定している。
00003.mplsは、センター画像のビデオストリームをメインパスによって指定している。そして本図左上のムービーオブジェクトは、再生装置における3D再生のケーパビリティ(3D-Capability)に応じて、00005.mpls、00003.mplsのうち、どちらかを選択して再生するよう記述されている(図中のif文)。
以上が記録媒体の実施行為及び記録方法の実施行為についての説明である。続いて、再生装置の詳細について説明する。
図25は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BD-ROMドライブ1、リードバッファ2a、リードバッファ2b、スイッチ3、システムターゲットデコーダ4、プレーンメモリセット5a、プレーン合成部5b、HDMI送受信部6、再生制御部7、管理情報メモリ9、レジスタセット10、プログラム実行部11、プログラムメモリ12、HDMVモジュール13、BD-Jプラットフォーム14、ミドルウェア15、モード管理モジュール16、ユーザイベント処理部17、ローカルストレージ18、不揮発メモリ19から構成されている。
BD-ROMドライブ1は、2D再生装置と同様に再生制御部7からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ2aかリードバッファ2bに転送される。
3D映像を再生する際には、再生制御部7からは2D/レフトビューAVクリップとライトビューAVクリップとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BD-ROMドライブ1は、2D/レフトビューAVクリップを構成するエクステントをリードバッファ2aに読み出し、ライトビューAVクリップを構成するエクステントをリードバッファ2bに読み出す。3D映像を再生する際には、2D/レフトビューAVクリップとライトビューAVクリップの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。
リードバッファ2aは、BD-ROMドライブ1が読み込んだ2D/レフトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ2bは、BD-ROMドライブ1が読み込んだライトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
スイッチ3は、リードバッファに対するデータ入力源を、BD-ROMドライブ1又はローカルストレージ18の何れかに切り替えるためのスイッチである。
システムターゲットデコーダ4は、リードバッファ2aに読み出されたソースパケットとリードバッファ2bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。
プレーンメモリセット5aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、インタラクティブグラフィックスプレーン(IGプレーン)、プレゼンテーショングラフィックスプレーン(PGプレーン)といったものがある。
プレーン合成部5bは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンを瞬時に重畳し、TVなどの画面に表示する。この表示にあたってプレーン合成部5bは、セカンダリビデオプレーン、PGプレーン、IGプレーンを3Dメタデータを使って左目用と右目用とに交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンと合成する。合成後の映像は、GFXプレーンの重畳処理に転送される。
プレーン合成部5bは、IGプレーンにおけるグラフィクスをAPIから指定されたオフセット情報を使って左目と右目用に交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンとセカンダリビデオプレーンとPGプレーンとIGプレーンとが重畳されたイメージを、テレビに出力する。
テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。
HDMI送受信部6は、例えばHDMI規格(HDMI:High Definition Multimedia Interface)に準拠したインターフェイスを含み、再生装置とHDMI接続する装置(この例ではテレビ300)とHDMI規格に準拠するように送受信を行うものであり、ビデオに格納されたピクチャデータと、オーディオデコーダ9によってデコードされた非圧縮のオーディオデータとを、HDMI送受信部6を介してテレビ300に伝送する。テレビ300は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からHDMI送受信部6を介して要求があると、テレビ300は要求された必要な情報(例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報)を再生装置へ返す。このように、HDMI送受信部6を介することで、テレビ300が立体視表示に対応しているかどうかの情報を、テレビ300から取得することができる。
再生制御部7は、再生エンジン7a、再生制御エンジン7bを含み、3Dプレイリストの再生がプログラム実行部11などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムの2D/レフトビューAVクリップを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのライトビューAVクリップを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点から2D/レフトビューAVクリップのエクステントと、ライトビューAVクリップのエクステントとを交互に読み出すようにBD-ROMドライブ1に要求する。再生開始するときには、最初のエクステントをリードバッファ2aか、リードバッファ2bに読みきった後に、リードバッファ2aとリードバッファ2bからシステムターゲットデコーダ4に転送を開始する。また、再生制御部7は、3Dプレイリストを再生する場合は、2D/レフトビューAVクリップに対応するクリップ情報ファイルに含まれる3Dメタデータをプレーン合成部5に通知する。
再生エンジン7aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。
再生制御エンジン7bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。
管理情報メモリ9は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。
再生状態/設定レジスタ(Player Status/Setting Register)セット10は、プレイリストの再生状態を格納する再生状態レジスタ、再生装置におけるコンフィグレーションを示すコンフィグレーション情報を格納する再生設定レジスタ、コンテンツが利用する任意の情報を格納できる汎用レジスタを含む、レジスタの集まりである。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置(時刻)を再生しているかなどの状態を現す。
プレイリストの再生状態が変化した際は、再生制御エンジン7bがレジスタセット10に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJavaプラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。

プログラム実行部11は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。(1)再生制御部7に対してプレイリスト再生を命令する。(2)システムターゲットデコーダに対してメニューやゲームのグラフィックスのためのPNG・JPEGを転送して画面に表示する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBD-Jアプリケーションのプログラミング工程によって決まる。
プログラムメモリ12は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BD-Jモードの動作主体であるJavaプラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。またプログラムメモリ12は、ヒープメモリを含む。
ヒープメモリは、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である
HDMVモジュール13は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

BD-Jプラットフォーム14は、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アーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ31に格納することにより、BD-Jアプリケーションのロードを行う。
バイトコードインタプリタは、いわゆるJava仮想マシンであり、ヒープメモリに格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
アプリケーションマネージャは、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。以上で、BD-Jプラットフォーム部の内部構成についての説明を終える。
ミドルウェア15は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。
モード管理モジュール16は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モード管理モジュールによるモード管理とは、動的シナリオを、BD-Jプラットフォーム22、HDMVモジュールのどちらに実行させるかという、モジュールの割り当てである。
ユーザイベント処理部17は、リモコンを通じたユーザ操作に応答して、プログラム実行部16や再生制御部7に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部16に依頼する。例えば、リモコンで早送り・巻戻しボタンが押された場合には、再生制御部7に、現在再生しているプレイリストのAVクリップに対する早送り・巻戻し処理の実行を命令する。
ローカルストレージ18は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。
不揮発メモリ19は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット10における記憶内容のバックアップに用いられる。
次に、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成について説明する。図26は、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成を示す図である。本図に示すように、システムターゲットデコーダ4及びプレーンメモリセット5aは、ATCカウンタ21、ソースデパケッイザ22、PIDフィルタ23、STCカウンタ24、ATCカウンタ25、ソースデパケッイザ26、PIDフィルタ27、プライマリビデオデコーダ31、レフトビュービデオプレーン32、ライトビュービデオプレーン33、セカンダリビデオデコーダ34、セカンダリビデオプレーン35、PGデコーダ36、PGプレーン37、IGデコーダ38、IGプレーン39、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41、ミキサー42、レンダリングエンジン43、GFXプレーン44から構成される。
ATCカウンタ21は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケッイザ22は、リードバッファ2aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ23は、ソースデパケッタイザ22から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダ31、セカンダリビデオデコーダ34、IGデコーダ38、PGデコーダ36、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41に転送する。
STCカウンタ24は、System Time Clock(STC)を生成し各デコーダの動作タイミングを調整する。
ATCカウンタ25は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケッイザ26は、リードバッファ2abにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ27は、ソースデパケッタイザ26から出力されたTSパケットのうち、TSパケットのPIDが、カレントプレイアイテムのストリーム選択テーブルに記載されたPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダに転送する。
プライマリビデオデコーダ31は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン32に書き込む。
レフトビュービデオプレーン32は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
ライトビュービデオプレーン33は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
セカンダリビデオデコーダ34は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻(PTS)のタイミングでピクチャをセカンダリビデオプレーンに書き出す。
セカンダリビデオプレーン35は、システムターゲットデコーダ4からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
PGデコーダ36は、ソースデパケタイザから入力される複数のTSパケットからプレゼンテーショングラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスデータを表示時刻(PTS)のタイミングでPGプレーンに書き出す。
PGプレーン37には、プレゼンテーショングラフィックスストリームをデコードすることで得られた非圧縮のグラフィックスオブジェクトが格納される。
IGデコーダ38は、ソースパケタイザから入力される複数のTSパケットからインタラクティブグラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスオブジェクトを表示時刻(PTS)のタイミングでIGプレーンに書き出す。
IGプレーン39には、インタラクティブグラフィックスストリームをデコードすることで得られたグラフィックスデータが格納される。
プライマリオーディオデコーダ40は、プライマリオーディオストリームをデコードする。
セカンダリオーディオデコーダ41は、セカンダリオーディオストリームをデコードする。
ミキサー42は、プライマリオーディオデコーダ40のデコード結果と、セカンダリオーディオデコーダ41のデコード結果とを合成する。
レンダリングエンジン43は、JPEG,PNGなど、BD-Jアプリケーションがメニュー描画に利用するグラフィックスデータをデコードする。
GFXプレーン44は、JPEG,PNGなどのグラフィックスデータがデコードされた後、書き込まれるプレーンメモリである。
次にプライマリビデオデコーダ31の内部構成について説明する。プライマリビデオデコーダ31は、TB51、MB52、EB53、TB54、MB55、EB56、ビデオデコーダ57、バッファスイッチ58、DPB59、ピクチャスイッチ60から構成される。
Transport Buffer(TB)51は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ23から出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)52は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)53は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
Transport Buffer(TB)54は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)55は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)56は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
ビデオデコーダ57は、ビデオエレメンタリストリームの個々のビデオアクセスユニットを所定の復号時刻(DTS)でデコードすることによりフレーム/フィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG2、MPEG4AVC、VC1などがあるため、ストリームの属性に応じて、ビデオデコーダ57のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ57は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ57は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ57は、デコードされたフレーム/フィールド画像をDPB59に転送し、表示時刻(PTS)のタイミングで対応するフレーム/フィールド画像をピクチャスイッチに転送する。
バッファスイッチ58は、ビデオデコーダ57がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB53、EB56のどちらから引き抜くかを決定し、EB53と、EB56とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻(DTS)のタイミングでビデオデコーダ57に転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ57に転送するのが望ましい。
Decoded PIcture Buffer(DPB)59は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ57が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。
ピクチャスイッチ60は、ビデオデコーダ57から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。
図27は、プレーン合成部の内部構成を示す図である。3Dメタデータに基づき、プレーンに格納されている非圧縮ピクチャデータ、グラフィクスデータをクロッピングするクロッピング部61a,b,cと、プログラムAPIに基づきプレーンに格納されている非圧縮グラフィクスデータをクロッピングするクロッピング部61dと、出力内容をレフトビュービデオプレーンと、ライトビュービデオプレーンとで切り替えるスイッチ62と、プレーン同士の合成を行う加算部63、64、65、66とから構成される。
プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ4よりPTSのタイミングで映像データが書き出される。プレーン合成部5bは、レフトビュービデオプレーンとライトビュービデオプレーンのうち、PTSのタイミングで映像データが書き出されたほうのプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送される。
これらのプレーンメモリのそれぞれは、レフトビューと、ライトビューとでそれぞれ異なる内容が格納されることで立体視の実現が可能になる。しかし、レフトビューにおける格納内容と、ライトビューにおける格納内容とが同じであっても、プレーンメモリにおける画素の座標を、レフトビューと、ライトビューとでそれぞれ変化させれば擬似的な立体視を実現することができる。上述したようなプレーンメモリのうちPGプレーンは、プレーンメモリにおける画素の座標を変化させることで、立体視を実現している。以下、PGプレーンにおける立体視の実現の仕方について説明する。
図28は、PGプレーンの合成の仕方を示す図である。
プレーン合成の仕方を図28のPGプレーンの例を用いて説明する。プレーン合成部5は、3Dメタデータ内に存在するオフセットエントリーのうち、現在再生されているプレゼンテーショングラフィックスのPIDに対応するものの中から、現在の表示時刻に対応するオフセット値を取得する。そして、プレーン合成部5は、重畳する映像プレーンがレフトビュービデオプレーンの場合はPGプレーンに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後、他のプレーンとの合成に供する(図28上段参照)。
プレーン合成部5bは、重畳する映像プレーンがライトビュービデオプレーンの場合は、PGプレーンをオフセット値だけX軸の負の方向をずらし、レフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後に重畳する(図28下段参照)。IGプレーン、セカンダリビデオプレーンも同様に処理を行う。
図29は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。
以上がプレーン合成についての説明である。続いて、レジスタセット10の内部構成及び再生制御エンジン7bの詳細について説明する。
図30は、レジスタセット10の内部構成及び再生制御エンジン7bの内部構成を示す図である。
本図の左側にはレジスタセット10の内部構成を示している。右側には再生制御エンジン7bの内部構成を示している。
PSRに格納されているこれらの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって適宜参照され、またムービーオブジェクト及びBD-Jアプリケーションによる更新を受ける。このようにPSRの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって参照されるパラメータであるから、システムパラメータとも呼ばれる。
始めに、PSRのうち、代表的なものについて説明する。
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”の設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。
一方、再生制御エンジン7bの内部には、レジスタセット10におけるPSR4,PSR6,PSR21,PSR23,PSR24と、管理情報メモリ9におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部8を備えている。PSR24におけるPlayer Capability for 3Dは、再生装置の3D再生に関する能力全般を意味するものなので、“3D-Capability”と簡単に表記する場合がある。
PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図31に示すように規定されている。
図31は、出力モードの選択モデルの状態遷移を示す図である。この選択モデルには、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になる。
図32は、Initializationの処理手順を示すフローチャートである。
ステップS1は、ディスクアンバウンドのBD-Jアプリケーションが動作中かどうかの判定であり、ステップS2は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、Index.bdmvにおけるInitial_output_mode情報が“立体視出力モード”を示すかどうかの判定である。
ステップS1がYesであれば、ステップS3においてカレントの出力モードを維持する。ステップS1がNo、ステップS2がYesであれば、ステップS4においてPSR22を立体視出力モードに設定する。ステップS1がNo、ステップS2がNoであればステップS5においてPSR22における出力モードを、2D出力モードに設定する。
図33は、Procedure when playback condition is changedの処理手順を示すフローチャートである。ステップS11は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、ステップS13は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、尚且つ、プレイリストにSTN_table_SSが存在するかどうかの判定である。
ステップS11がYesであればステップS12において、カレント出力モードを変化させない。ステップS11がNo、ステップS13がYesであってもカレント出力モードを変化させない(ステップS12)。ステップS11がNo、ステップS13がNoであればカレント出力モードを2D出力モードに変化させる(ステップS14)。
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、“ストリーム選択プロシージャ”と呼ばれる。
図34は、ストリーム選択プロシージャの処理手順を示すフローチャートである。ステップS21は、再生装置の表示方式が2Dであるか否かを判定する判定ステップであり、判定結果がYesであるなら、カレントプレイアイテム情報内の2D用STN_tableをカレントSTN_tableに設定する(ステップS22)。判定結果がNoであるなら、プレイリスト情報のエクステンションデータに存在するSTN_table_SSのうち、カレントプレイアイテム情報に対応するものを、カレントSTN_tableに設定する。以降、ステップS24〜ステップS33の処理を実行する。ステップS24〜ステップS33は、プライマリビデオストリーム、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップS26〜ステップS33の処理を繰り返すものである。ステップS26は、カレントSTN_tableにおける、ストリームxに対応するSTN_tableエントリー数が0であるか否かの判定であり、ステップS27は、カレントSTN_tableにおけるストリームxに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。
ステップS26、ステップS27の何れかがYesであれば、ステップS33においてストリーム番号レジスタに格納されているストリーム番号を維持する。
ステップS26、ステップS27の何れもがNoであれば、カレントSTN_tableに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して(ステップS28)、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する(ステップS29)。
条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する(ステップS30)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレントSTN_tableにおける優先順位が最も高いものを選択する(ステップS31)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む(ステップS32)。
以上の過程を経て出力モードが確定し、またカレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedure when playback condition is changedによって確定した出力モードに応じたものとなる。出力モードに応じた、プレイアイテムの再生手順を図35を参照しながら説明する。
図35は、プレイアイテムの再生手順を示すフローチャートである。
ステップS41は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップS42において、カレントプレイアイテム番号を“1”に初期化した上で、ステップS43〜ステップS48のループに移行する。
このループは、カレントプレイアイテムに対してステップS43〜ステップS46の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップS48)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップS47でYes)。ステップS43〜ステップS46の内容は、以下のものである。
ステップS43において、カレントプレイアイテムのClip_Information_file_nameに記述されている「XXXXX」と、拡張子「m2ts」とで指定されているトランスポートストリームファイルをオープンし、ステップS44において、ビデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In_Time及びカレントPlayItem.Out_TimeをStart_SPN[i]及びEnd_SPN[i]に変換する。
ステップS45では、パケットID[i]のTSパケット[i]をStart_SPN[i]からEnd_SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し、ステップS46において、読出範囲[i]に属するエクステントを連続的に読み出すよう、BD-ROMドライブに指示する。
カレント出力モードが立体視出力モードであれば、ステップS49において、カレントプレイアイテム番号を“1”に初期化した上で、ステップS50〜ステップS60のループに移行する。
このループは、カレントプレイアイテムに対してステップS50〜ステップS58の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップS60)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップS59でYes)。ステップS50〜ステップS58の内容は、以下のものである。
ステップS50において、カレントプレイアイテムのClip_Information_file_nameに記述されている「XXXXX」と、拡張子「ssif」とで指定されているトランスポートストリームファイルをオープンし、ステップS51において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のレフトビュー/ライトビュー識別情報によって指定されているものををベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。
ステップS52において、ベースビュービデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In_Time及びカレントPlayItem.Out_TimeをStart_SPN[i]及びEnd_SPN[i]に変換する。
ステップS53では、ディペンデントビューストリームに対応するSubPlayItemを特定し、ディペンデントビューストリームのパケットID[j]に対応するエントリーポイント[j]を用いて特定されたSubPlayItemIn_Time、SubPlayItemOut_TimeをStart_SPN[j]、End_SPN[j]に変換する(ステップS54)。
パケットID[i]のTSパケット[i]をStart_SPN[i]からEnd_SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップS55)、パケットID[j]のTSパケット[j]をStart_SPN[j]からEnd_SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップS56)。そしてステップS57において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップS58においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。
HDMVモードにおいては、プレイリストの再生が停止していれば、画面には何も現れないが、BD-Jモードでは、プレイリスト再生が停止していても、BD-Jアプリケーションが画面描画を行うことができるので、何等かの画面が表示されている可能性がある。ここでもし、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こる。何故なら、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こるからである。
プレイリストの再生が開始されれば、そのプレイリストが2Dであるか、3D映像であるかに応じて、メニューやグラフィクスを3Dに変換したり、2Dに変換する必要があるので、そこで本実施形態では、ミドルウェアがBD-Jアプリケーションにイベントを出力して、立体視のための画面描画を促すことにしている。
2D映像と3D映像とが切り替わるタイミングを、ディスク上に記録され、再生装置で動作しているプログラムに知らせるための仕組みについて説明する。
図31の状態遷移では、BD-Jタイトルにおいてプレイリストの再生が開始した際、Procedure when playback condition is changedが実行されたが、このBD-Jタイトルの再生中に、プレイリストの再生が開始された場合、何等かの術により、プレイリスト再生の開始をBD-Jアプリケーションに通知せねばならない。この通知をどのようにして行うかを記述したのが図36である。
図36は、再生制御エンジンの状態が“停止中”から“3Dプレイリスト再生中”に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、『停止中→3Dプレイリスト再生→停止中』というように遷移していることがわかる。このうち、停止中から3Dプレイリスト再生に遷移したタイミング、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から停止中に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンの停止中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これは、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。
次に、再生制御エンジン7bが再生を停止しているのではなく、2Dプレイリストの再生を既に開始しており、その再生の途上で、再生対象となるプレイリストが切り替わるというケースを想定する。図37は、再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、2Dプレイリスト再生→3Dプレイリスト再生→2Dプレイリスト再生というように遷移していることがわかる。このうち、2Dプレイリスト再生から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から2Dプレイリスト再生に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これも、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。
次に、再生制御エンジンによる3Dプレイリストの再生中に、ユーザが字幕切り替え、音声切り替えの操作を再生装置に行ったというケースを想定して、以下を行う。再生対象となるストリームが切り替わることになる。以下、このストリーム切り替えの事例について図38を参照しながら説明する。
図38は、再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第1段目は、BD-Jアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第3段目によると、再生制御エンジンの状態は、3Dプレイリスト再生であるか、その途中に、ストリーム切替えがなされていることがわかる。このうち、ストリームが別のものに変化したタイミング、及び、ストリームが元のものに戻ったタイミングに、HScreenConfigurationイベントが出力されていることがわかる。
第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。
プレイアイテムやプレイリスト、あるいは、ユーザーがストリーム切り替えを行ったタイミングであって、3D映像の再生が開始された場合、あるいは、終了した場合に、イベントを上げることにより、2D/3Dが切り替わるタイミングを検出して、適切なメニュー・グラフィクスに切り替えさせる。
以上のように本実施形態によれば、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のClip_Information_file_nameと、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子「ssif」とから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供することで、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。
そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。こうしたオーサリングの手間の低減によって、3D再生可能な映画作品の充実化を図ることができる。
(第2実施形態)
本実施形態では、表示装置300、3D眼鏡400がどのような機能をもち、その内部構成がどのようなものかを図39を参照しながら説明する。
図39(a)は、表示装置300の内部構成を示す図である。本図に示すように、表示装置300は、チューナ71、HDMI送受信部72、メッセージ記憶部73、表示制御部74、表示素子75、無線送信部76から構成される。
チューナ71は、地上波デジタル放送、衛星デジタル放送で送信されたマルチチャネルトランスポートストリームを受信して復調する。この際チューナ71は、複数のチャネルを同時に選局して非圧縮のピクチャを出力することもできる。
HDMI送受信部72は、HDMIを通じて再生装置から送信されてくる非圧縮で合成済みピクチャデータを受信する。
メッセージ記憶部73は、ピクチャに代えて表示すべき警告メッセージを記憶している。
表示制御部74は、チューナ71による復調で得られた非圧縮のピクチャ、HDMIを通じて再生装置から伝送された非圧縮で合成がなされたピクチャを表示に供する。表示にあたって表示制御部74は、1/120秒、1/140秒という時間精度で、表示期間を切り替えることができ、この精度で、例えば1/24秒という表示期間を、1/48秒、1/72秒、1/92秒というように、更に小さい表示期間に細分化することができる。
表示パネル75は、液晶表示素子、プラズマ発光素子、有機EL素子を駆動することで、画素の発光を行うデバイスであり、表示制御部74による制御の下で、非圧縮のピクチャデータの表示を行う。
無線送信部76は、赤外線通信方式、無線LAN方式によって、3D眼鏡400を制御する。具体的には、3Dモード及びマルチチャネルモードのそれぞれにおいて、表示期間の先頭にあたって、3D眼鏡400の状態遷移を促す同期信号を送信する。かかる信号送信によって、レフトビューの期間では透光状態に遷移し、ライトビューの期間では遮光状態に遷移し、レフトビューの期間では改めて透光状態に遷移させるという制御を繰り返す。これにより、図1(b)(c)のような変化を行うことになる。
本実施形態では3Dモードでの処理として、表示制御部74は、1/24秒という表示期間を、1/72秒の時間長をもつ3つの表示期間(表示期間1/3,2/3,3/3)に分割して、この3つの表示期間1/3,2/3,3/3のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/3の表示内容はレフトビュー、2つ目の表示期間2/3の表示内容はライトビュー、そして3つ目の表示期間3/3の内容には警告画面というようにである。これらの期間の先頭において、眼鏡に対して同期信号を送信し、レフトビュー及びライトビューの状態遷移を行わせる。
マルチチャネルモードの処理として、表示装置300は複数のチャネルを、時分割で復調する。そして表示制御部74は、1/24秒という表示期間を、1/48秒の時間長をもつ2つの表示期間(表示期間1/2,2/2)に分割して、この2つの表示期間1/2,2/2のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/2の表示内容はチャネル1、2つ目の表示期間1/2の表示内容はチャネル2というようにである。そして、個々のチャネルの表示期間が到来すれば、そのチャネルの視聴を希望しているユーザの状態を透光状態に遷移させ、他のチャネルの視聴を希望しているユーザの眼鏡の状態を遮光状態に遷移させる。
図39(b)は、3D眼鏡400の内部構成を示す図である。
状態遷移のトリガとなる同期信号を表示装置300から受信する無線受信部81と、液晶シャッタの状態を、透光状態、遮光状態に遷移させる状態制御部82と、液晶シャッタ83、84とを具備する。
眼鏡の動作モードにも、3Dモード、マルチチャネルモードが存在する。
3Dモードにおいて眼鏡は、透光状態、遮光状態のほか、遮断−遮光状態を具備する。遮断−遮光状態は、レフトビュー及びライトビューの双方が閉じている状態である。
マルチチャネルモードにおいて眼鏡は、レフトビュー及びライトビューの双方が開いている透光−透光状態と、レフトビュー及びライトビューの双方が閉じている遮断−遮光状態とに遷移する。
立体視表示を実現する場合、本実施形態では、眼鏡のライトビュー、レフトビューを、単に切り替えるのではなく、3D眼鏡400の装着を促す警告画面を、3D眼鏡を既に装着しているユーザに見せないような配慮が必要になる。警告画面を装着済みユーザに見せないように、3D眼鏡400をどのように制御すべきかを、図40を参照しながら説明する。
図40は、3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のライトビュー、レフトビューの状態を示す。1/24秒のうち、最初の1/72秒の表示期間1/3では、レフトビュー画像が表示装置に表示されていて、眼鏡のレフトビューが透光状態、ライトビューが遮光状態になっている。続く表示期間2/3では、ライトビュー画像が表示装置に表示されていて眼鏡のレフトビューが遮光状態、ライトビューが透光状態になっている。最後の表示期間3/3では、表示装置が眼鏡の装着を促す警告画面になっていて、眼鏡のレフトビュー及びライトビューが遮光状態になっていることがわかる。
1/24秒の表示期間を分割することで得られた3つの1/72秒の表示期間のうち、最後の表示期間3/3において、眼鏡を装着したユーザは、画面に表示されている警告映像を見ることができない。「3D眼鏡をかけてください」と表示すると、3D眼鏡をかけていない人には、3D眼鏡をかけることを促すメッセージが見えるが、すでに3D眼鏡をかけている人には見えないといった、状況に応じたメッセージが表示されることになる。
マルチチャネル表示を実行する場合、表示装置は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替えるという独特の制御を実現する。この独特な制御を図41を参照しながら説明する。
図41は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替える場合の、3Dモードにおける表示内容と、ユーザ1の状態と、ユーザ2の状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のR、Lの状態を示す。
1/24秒の表示期間のうち、表示期間1/2において、ユーザー1が装着している眼鏡は、透光−透光状態になりユーザ1はチャンネル1(Ch1)を視聴することができる。
ユーザー2が装着している眼鏡は、遮光−遮光状態になりユーザ2はチャンネル1(Ch1)を視聴することができない。
表示期間2/2において、 ユーザー1が装着している眼鏡は、遮光−遮光状態になりユーザ2はチャンネル2(Ch2)を視聴することができない。ユーザー2が装着している眼鏡は、透光−透光状態になりユーザ2はチャンネル2(Ch2)を視聴することができる。このような使い方をすると、1つの画面で、二人がそれぞれ異なるチャンネルを同時に見ることができる
3D眼鏡をすでに装着しているため、眼鏡に内蔵されたイヤフォンを用いれば、映像と音声を完全に独立させることも可能であり、リビングでのチャンネル権争いの回避、1つの画面で対戦ゲームをするなど、応用範囲は広がる。また、ステップを増やすことにより、3チャンネルやさらに多くのチャンネルを1つの画面で見ることが可能となる。
以上のように本実施形態によれば、表示装置を視聴しているユーザが複数人である場合、各ユーザが3D眼鏡400を着用することで、各ユーザは、自分が好きなチャネルを視聴することが可能になる。ユーザの人数分、表示装置を用意しなくてもユーザは好きな番組を見ることができるので、ユーザ宅のリビングを有効に利用することができる。
(第3実施形態)
本実施形態は、再生装置と、表示装置とのネゴシエーションに関する実施形態である。ユーザ宅内におけるホームシアターシステムの構築事情には、それぞれの家庭独特のものがあり、再生装置は、表示装置と接続された際、接続相手となる表示装置とネゴシエーションを行って、どのプレイリストを再生に供するかを切り替える必要がある。
本実施の形態では、3Dに対応したデジタル出力と、旧来の表示装置にも出力できることを考慮したアナログ出力を同時に出力する場合の改良を説明する。
3D映像を格納したBD-ROMであったとしても、旧来から存在して普及台数が多い2D再生装置でも正常に再生されることを考える必要がある。第1実施形態で述べたように、BD-ROM上のプログラムで制御する方法もあるが、プログラムのバグなどにより選択を誤った場合、不適切な映像が再生され視聴者の健康を害したり、過剰な負荷がかかることにより再生装置が壊れてしまう可能性もあるため、不適切な再生が行われない仕組みが必要となる。
2DTVとの接続時について述べる。
そもそも旧来のアナログ方式では3D映像に対応していないため、3D映像は出力できない。再生装置が3D映像再生中は、アナログ出力に「3D映像再生中です。3D対応のディスプレイでご覧ください。」などのメッセージを表示して、ユーザーが誤った端子に接続したり、対応していない表示装置に接続していることを知らせるためのメッセージを表示する。その後、接続されている表示装置が2D表示装置である場合は、自動的に2Dプレイリストに再生を切り替えることが望ましい。
次に、2D表示装置と、3D表示装置とが再生装置に同時に接続されていて、これらの表示装置に映像信号を同時出力するケースについて説明する。再生装置に2D表示装置と3D表示装置が接続されており、同時に出力している場合は、2D表示装置側に3D映像のレフトビューかライトビューのいずれかのみを出力する。
複数の表示装置に、プレイリストの再生結果である映像信号を同時出力する際、レフトビュービデオストリーム、ライトビュービデオストリームのうちどちらを、アナログ用に出力するかを規定する情報を、2D出力優先映像情報という。この情報をプレイリストに予め設けておき、カレントプレイリストにおける2D出力優先映像情報に従い、2D表示装置、3D表示装置に同時に映像信号を出力する。こうすることで、2Dと3D用の映像を同時にデコードしたり、2Dと3D用のプレイリストを独立して扱えなくても、同時に2つの表示装置に出力することが可能となる。
同様にOSD(システム組み込みメニュー)表示を行う際、3D表示装置には3D対応のOSD表示を行うが、アナログ出力のように2Dしか対応しない出力には専用の2D映像、あるいは、レフトビューのみ/ライトビューのみを出力する。
3D用の出力と2D用の出力が困難な場合は、リモコンに副表示部を設け、そちらに表示することが望ましい。
これらのことを図42を参照しながら具体的に説明する。図42は、再生装置と、表示装置との接続態様を示す図である。上側は、アナログ接続される表示装置を示す。左下側に、デジタル接続される3D対応の表示装置300を示し、右下側に、デジタル接続される2D表示装置302を示す。
再生装置が、3D表示装置と、2D表示装置とに同時接続された場合は、これらの表示装置とネゴシエーションを試みる。そして、相手側表示装置との接続がアナログ接続によるものであるため、ネゴシエーションをすることができないことが判明すれば、レフトビュービデオストリーム、レフトビュービデオストリームのうち、2D出力優先映像情報に示されるものを再生する。こうすることで、接続相手たる表示装置とアナログ接続された場合、オーサリング担当者が意図したプレイリストを再生に供することができる。
一方、双方の表示装置との接続がデジタル接続によるものであり、ネゴシエーションが成功した場合は、相手側が3D表示装置であるか、2D表示装置であるかを判定する。ネゴシエーションの結果、相手側が2D表示装置であることが判明すれば、図中の矢印mg1に示すように画面内容の遷移を2D表示装置に行わせる。
矢印mg1は、2D表示装置の画面内容の遷移を示す。デジタル接続の場合、3D映像の再生中です。「3D表示装置で御覧くださいとのメッセージを表示した後、2D映像を表示する。


またネゴシエーションにあたっては、複数のライトビューを切り替える必要がある。複数のライトビューを切り替える理由として、表示装置の画面の大きさの違いがある。左目と右目の間隔は個人の個体差があってもだいたい同じであるが、表示装置は20インチのものもあれば、150インチのものもある。50インチの表示装置を想定して、目と目の間隔6.5センチで作られた映像も、150インチの表示装置では3倍の19.5センチの目の間隔になってしまい、3D映像として認識が難しくなる。そのため、様々なサイズの表示装置でレフトビューとライトビューの差が、6.5センチになるレフトビュー、ライトビューの組みを納めておけば、表示装置に合わせてビデオストリームを選ぶことにより、最適なレフトビュービデオストリーム/ライトビュービデオストリームの組み合わせを選ぶことができる。
表示装置には、150インチ、50インチという様々なサイズがあり、例え左右の画素数が同じでも、これらの表示装置における画面上の距離は違ってくることを図43を参照しながら説明する。
図43は、左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。
左側は、左右のオフセットが異なる、ライトビューピクチャ−と、レフトビューピクチャとの組を示す。
中段は、50インチ表示装置における距離を示し、右側は、150インチ表示装置における距離を示す。左右の差が50画素である場合、50インチ表示装置上での距離は2.0cmとなり、150インチ表示装置上での距離は6.0cmとなる。
左右の差が100画素である場合、50インチ表示装置上での距離は、4.0cmとなり、150インチ表示装置上での距離は12.0cmとなる。
左右の差が150画素である場合、50インチ表示装置上での距離は、6.0cmとなり、150インチ表示装置上での距離は18.0cmとなる。
50インチ表示装置では、6.0cmが最適となり、150インチ表示装置でも、6.0cmが最適となので、3DStream Depth ChangeUO、3DStreamDepthChangeコマンドにより、画面上において表示される距離を調整する。
図43で説明した表示装置の画面サイズを取得する方法を用いて、プログラムが自動的に最適な左目/ライトビューの組み合わせを選択できれば、ユーザーは画面サイズを気にすることなく、最適なストリームが自動選択されることになる。
複数の画面サイズに対応した奥行き感/深度の異なるストリームが複数記録されている場合、ローカルストレージの画素差が異なるストリームを記録媒体に記録しておき、これらのストリームを切り替えるためのUOやコマンドを用いることで、ユーザー自身が奥行き感/深度を選択することも可能である。
以上のように本実施形態によれば、再生装置が表示装置と接続された際、表示装置との関係においてより適切な再生出力が行われることが保障される。

(第4実施形態)
本実施形態は、立体視を行うにあたって、ビデオストリームと共に、どのようなPGストリーム、IGストリームを選択すべきかという改良を実現する。
2D再生装置で再生される映像は2D映像であり、対応する字幕やメニュー画像が2Dである。対して、3D再生装置で再生されるのは3D映像であり、対応する字幕やメニュー画像も3Dであることが望ましい。3D映像に対して、2DのPGやIGが表示された場合、前後関係が意図しないものとなり、ユーザーが正常に空間認識ができず、最悪健康を害してしまうためである。
また、3D再生装置であったとしても、ユーザーが2D映像を選ぶことは自由であるが、その場合、対応する字幕やメニュー画像も自動的に2Dに切り替わるべきである。
2D映像と関連する字幕などの組み合わせ、3D映像と関連する字幕などの組み合わせは、プログラムで選択してもよいが、データとして関連づけておくことにより再生装置が自動的に不適切な組み合わせを排除することが可能となる。その仕組みについて述べる。

3D対応のプレイリストは、第1実施形態で示したように、ストリーム選択テーブルをさらに2D用のSTN_tableと、3D再生用のSTN_table_SSとに分けて管理する。そして2D再生でしか利用しない映像/音声/PG/IGのストリーム登録と、3Dで利用する映像/音声/PG/IGのストリーム登録は異なるエントリー群に登録する。2D映像を選択している場合は、3D用に用意された音声/PG/IGは選択できない。また、同様に3D映像を選択している場合は、2D用に用意された音声/PG/IGは選択できない。
管理テーブルをさらに分割して、レフトビューとライトビュー、それらに関連づけられる字幕/メニュー画像のストリーム登録を別々に管理することもできる。

2D用に作成されたPGストリームと、3D用に作成されたPGストリームとでは、奥行きの有無、位置や角度に違いがあるので、立体視のためのビデオストリームの再生時に、2DPGストリームが選択されて、3Dビデオストリームと共に再生されることは、オーサリング者にとっては何とか避けたいところである。
これを避けるために導入されたのが、STN_table_SSにおけるストリーム組合せ情報である。図44は、ビデオストリームとPGストリームとを組み合わせる場合の、ストリーム組合せ情報の記述例である。
本図(a)に示すように、ストリーム選択テーブルにおけるストリーム組み合わせ情報には、ビデオストリームのストリーム番号=1と、PGストリームのストリーム番号”=1”、2との組み合わせが許容されていることがわかる。
ビデオストリームのストリーム番号=2には、PGストリームのストリーム番号”=1”、2との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=3には、PGストリームのストリーム番号=3、4との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=4には、PGストリームのストリーム番号=3との組み合わせが許容されていることがわかる。
図44(b)は、その組合せ情報にて規定されるビデオストリーム、PGストリーム間で、許容される組合せを模式的に示す。
本図左側のビデオストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるビデオストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるビデオストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるビデオストリームは3D用であることがわかる。
本図側のPGストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるPGストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるPGストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるPGストリームは3D用であることがわかる。
ビデオストリーム及びPGストリームの間の実線kw1,2,3・・・は、ストリーム組合せ情報によって許容される組合せを模式的に示す。この実線で模式的に示されるように、2Dと3Dの映像/字幕を組み合わせることはできない。また、組み合わせ可能なストリーム通しの場合も意図的に省くことができる。
PGストリームと、ビデオストリームとの組合せはストリーム組合せ情報に予め規定されているので、このストリーム組合せ情報に則して、PGストリームを選択すれば、あるビデオストリームが選択された際、このビデオストリームにとって最適なPGストリームが選択されることが保障されることになる。
図45は、ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。ユーザーがストリームを切り替える時、あるいは、プレイアイテム境界のように、ストリームの構成が変化する可能性がある時に、本図で示すストリーム選択処理が実行され、ビデオストリームとPGストリームは、ストリーム組み合わせ情報に登録された組み合わせに合致させる。
ステップS71において、ビデオストリーム番号を取得し、ステップS72においてPGストリームを取得する。ステップS73は、ビデオストリームと、PGストリームとの組合せが、ストリーム組合せ情報に登録されているかどうかの判定であり、もし登録されていれば、ステップS74においてそのストリーム組合せ情報の通り再生する。登録されていなければ、ステップS75においてストリーム組合せ情報においてビデオストリームとの組合せが登録されている、他のPGストリームを選択し再生する。

(第5実施形態)
第1実施形態の冒頭で述べたように、立体視には様々な原理があり、市場で流通しつつある製品は、様々な3D方式に対応していると考えられる。3Dの再生方式にはいろいろな方式が存在し、また、方式により表示装置側の対応・非対応も異なるため、再生装置のシステムパラメータは複数の方式を表現できる形式が望ましい。ここでは、3Dの再生方式として、2画面のビデオを独立して送る2画面ステレオ再生方式、サイド・バイ・サイド方式、横方向2倍方式、2D+奥行き情報方式などを例に挙げるが、その他、表示装置が対応可能な方式がある場合は、対応する方式の実行の可否を識別できるように、PSRのビットアサインを定める。
図46は、複数の3D方式を網羅できるPSRのビットアサインを示す図である。
本図におけるPSR24は、4ビット(b3,b2,b1,b0)からなり、最上位ビットb3から最下位ビットb0までのそれぞれのビットには、それぞれ対応する3D再生方式が関連づけられている。再生装置がその3D再生方式に対応している場合には、対応するビットが「1」に設定され、対応していない場合には対応するビットが「0」に設定される。PSR24の全ビットが「0」のときは、再生装置は2D再生装置であり、いずれかあるいはいくつかのビットが「1」のときは、対応した方式の2D/3D再生装置であることを示す。
PSR24における最上位ビットb3から最下位ビットb0までのビットは、2画面ステレオ再生、サイド・バイ・サイド方式、横方向2倍方式、2D−奥行き情報方式のそれぞれの3D表示方式をサポートできるかどうかを示す。
2画面ステレオ再生方式は、これまでの実施形態で説明した方式である。
サイド・バイ・サイド方式は、1920×1080という解像度を、960×1080と、960×1080とに分けて、これらのそれぞれに、レフトビュー,ライトビューを表示させる方式をいう。
横方向2倍方式は、1920×1080という解像度を、3840×1080という解像度にして、このうち、1920×1080の解像度の部分にレフトビューを割り当て、1920×1080の解像度の部分にライトビューを割り当てる方式である。
2D−奥行き情報方式は、2D映像と、グレースケール画像とで立体視を実現する方式である。グレースケール画像は、2値化画素からなる。2値化画素の輝度は、2D映像における各画素の奥行きを示す。この2値化画素の輝度に従い、2D映像における各画素の奥行きを作成して、立体視画像を構築する。
プレーヤセッティングレジスタの値をBD-ROM上のBD-Jアプリケーションからアクセスする場合は、再生装置のシステムプロパティとしてアクセスすることも可能である。
表示装置と再生装置が、HDMIのように表示装置の性能・対応方式を再生装置に送信できる伝送方式により接続されている場合、再生装置の性能だけではなく、表示装置の対応方式も鑑みて、PSR24に自動的に設定する。この場合、同じ再生装置でも接続される表示装置によってPSR24の値は変化する。
表示装置の性能を伝送できない場合は、ユーザーが手動で設定することが望ましい。
表示装置から対応方式を取得できる場合は、単純な対応方式の他、表示装置のサイズ、解像度、表示装置の画面から視聴する人までの距離等、3D再生に影響する情報を取得し、PSR24に格納しておくことで、後で説明するプログラムによる最適な再生方式の選択に活用することも可能である。
3Dの対応状況が1ビットで表せないことがででくる。この場合、複数ビットを使うべきである。映像サイズが1920×1080までは対応可能だが、それ以上の解像度の場合はデコーダの性能不足などにより再生できないことが想定される場合、2ビットを利用して非対応を「00b」、1920×1080まで対応を「01b」、それ以上のサイズに対応したものを「10b」などと表現すれば、より細かく対応状況をシステムパラメータを用いて表現することが可能である。
複数の3D方式を網羅できるようにPSR24のビットアサインを規定しておけば、再生装置に接続される表示装置がどのような3D方式のものであっても、表示装置に立体視再生を行わせることができる。図47は、表示装置が対応している3D再生方式を再生装置セッティングレジスタに反映させる図である。これまでに説明した3D再生能力を示す3D-Capabilityのシステムパラメータを利用すると、2D再生装置が,3Dビデオストリームを選択することを禁止する処理も可能である。ユーザー、プログラムあるいは、プレイアイテム先頭において、ビデオストリームを選択する時、選択しようとしているストリームが3Dビデオストリームである場合、プレーヤセッティングレジスタに格納された再生装置の対応3D方式を確認し、ストリーム選択テーブルから選択しようとしているストリームの情報を取得することにより、選択するストリームが再生装置で再生可能か否かが判別できる。
2D再生装置では3D映像を再生できないため、この処理により選択自体が発生せず、不適切な映像が画面に表示されることを防ぐことができる。
前の実施形態で説明した、表示装置が対応している3D方式を自動的に取得する仕組みと組み合わせると、接続されている表示装置が対応した3D方式のストリームか2Dストリームしか選択できないようになり、不適切な映像が画面に表示されることを防ぐことができる。
かかる処理を実現する場合のプログラムの処理内容について説明する。
ユーザからタイトルが選択され、実行されたBDプログラムファイルは、プログラムの中で、再生装置が3D映像再生に対応しているか、対応している場合にユーザが3D映像再生を選択しているかを調べて、再生するプレイリストを切り替える。
3D再生方式を複数想定する場合は、それぞれ対応した方式のプレイリストを準備しておき、再生装置がBD-ROMに格納されたプレイリストに対応している場合は、対応した3Dプレイリストを選択、対応していない場合は、2Dプレイリストを選択する。
FirstPlayタイトルをどのように構成すべきかについて説明する。
FirstPlayタイトルを構成するプレイリスト、つまり、ディスク挿入時にまず最初に再生されるプレイリストは、安全のため必ずどの再生装置でも再生される2D映像で構成すべきである。
BD-ROMに格納されているプログラムはオーサリング側が作成するものであり、複数の3D形式に再生装置が対応している場合、どの3D再生方式を優先的に選択するかは、オーサリング側の意志に依存する。
3Dプレイリストの選択について説明する。
たとえば、3D方式1が2画面ステレオ再生方式、3D方式2がサイド・バイ・サイド方式であり、再生装置がサイド・バイ・サイド方式にのみ対応している場合、プログラムはその再生装置で再生可能であるサイド・バイ・サイド方式の3Dプレイリスト005.MPLSを選択して再生する。
Index.bdmv、プログラムの関係について説明する。
図47に示すように、3D再生方式を再生装置セッティングレジスタに反映させれば、BD-ROMにおけるプログラムを動作させることでオーサリング担当者は、再生装置及び表示装置にとって最適な3D方式を再生装置セッティングレジスタに設定することができる。このような3D再生方式の選択を実現する場合、インデックステーブルと、BDプログラムファイルとは、以下に示すように設定しておく必要がある。
図48はインデックスファイル(Index.bdmv)とプログラムファイルとの関係を示している。
本図左側は、インデックステーブルと、当該インデックステーブルの解読主体であるモード管理モジュール16とを示す。上述したように、インデックステーブルには、FirstPlayタイトル、トップメニュー、タイトル1、2、3のそれぞれに対応するエントリーが存在する。
本図の右側は、再生装置における出力モードの設定に応じて選択的に再生されるべき4つのプレイリストファイルを示す。
4つのプレイリストファイルには、2D映像を再生する経路が記載された00001.mpls、00003.mplsと、3D方式1による再生経路が記載された00004.mplsと、3D方式2による再生経路が記載された00005.mplsとが存在する。
本図の真ん中には、ムービーオブジェクト1,2という2つのムービーオブジェクトが記載されている。
ムービーオブジェクト1は、00001.mplsの再生を命じる。この00001.mplsは、2Dプレイリストを定義するものである。何故なら、FirstPlayタイトルで再生されるべきプレイリストは、何れの出力モードでも必ず再生される必要があるからである。
ムービーオブジェクト2は、PSR24に示される3D-Capabilityが3D方式1であれば、00004.mplsの再生を命じ、3D-Capabilityが3D方式2であれば00005.mplsの再生を命じ、3D-Capabilityが、何れの3D方式にも合致しなければ、00003.mplsの再生を命じる。図中の矢印pp1,pp2,pp3は、ムービーオブジェクトによるプレイリストの再生指示を模式的に示す。
図中の矢印my1,my2は、これらのムービーオブジェクトが、HDMVモジュール13による解読に供されることを示す。HDMVモジュール13が、これらのムービーオブジェクトを実行することで、再生装置におけるCapabilityに応じて、上述したような3つのプレイリストファイルが選択的に再生に供されることがわかる。
ストリーム組合せ情報に、ビデオストリームと組合せることができるPGストリームが予め規定されていれば、ストリーム選択の処理手順は、図49のフローチャートに則したものとなる。
図49は、ストリーム選択の処理手順を示すフローチャートである。ステップS81において、再生装置の対応3D方式を取得し、ステップS82において、ストリーム選択テーブルを取得する。ステップS83では、再生装置が対応する3D方式と、選択しようとするストリームとが合致しているかどうかを判定し、ステップS83の判定結果がYesであるなら、ステップS84において選択を許す。ステップS83の判定結果がNoであるなら、ステップS85において、選択を許可しない。
(第6実施形態)
本実施形態では、第1実施形態で述べた記録方法を実施するための記録装置について説明する。
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。
この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。
リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TS形式のデジタルストリームを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBD-RE,BD-R等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
そして、装置外部から入力されるトランスポートストリームからビデオストリームにおける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上に得ることができる。

以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法を実行する記録装置について説明する。
ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成するというのが、本発明にかかる記録装置の使用形態である。

図50は、記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、ビデオエンコーダ501、素材制作部502、シナリオ生成部503、BDプログラム制作部504、多重化処理部505、フォーマット処理部506により構成される。
ビデオエンコーダ501は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG4-AVCやMPEG2などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部501aに書き込む。ビデオエンコーダ501は、ピクチャ間の相関特性を利用した画像圧縮をするために、8x8や16x16のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。
マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、8ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。
素材制作部502は、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックストリームなどの各ストリームを作成して、オーディオストリーム格納部502a、インタラクティブグラフィクスストリーム格納部502b、プレゼンテーショングラフィックストリーム格納部502cに書き込む。
オーディオストリーム作成にあたって素材制作部502は、非圧縮のLinearPCM音声などをAC3などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部502は、字幕イメージと表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるプレゼンテーショングラフィックスストリームを作成する。素材制作部502は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるインタラクティブグラフィックスストリームを作成する。
シナリオ生成部503は、素材制作部502で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BD-ROMフォーマットでシナリオを作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部503は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第1実施形態1および第2実施形態で説明したデータ構造となる。
BDプログラム制作部504は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ501が出力した奥行き情報を利用することができる。
多重化処理部505は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG2-TS形式のAVクリップを作成する。このとき、AVクリップと対になるクリップ情報ファイルも同時に作成する。
多重化処理部505は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。
フォーマット処理部506は、シナリオ生成部503で生成したBD-ROMシナリオデータと、BDプログラム制作部504で制作したBDプログラムファイル、多重化処理部505で生成したAVクリップやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成する。
また、この時ビデオエンコーダ501が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトは実施の形態1、2で説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。
(マネージドコピーを実現する記録装置としての実施)
記録装置は、マネージドコピーによってデジタルストリームの書き込むものでもよい。
マネージドコピーとは、BD-ROM等の読み出し専用記録媒体に記録されているデジタルストリームやプレイリスト情報、クリップ情報、アプリケーションプログラムを、別の光ディスク(BD-R,BD-RE,DVD-R,DVD-RW,DVD-RAM等)やハードディスク、リムーバブルメディア(SDメモリーカード、メモリースティック、コンパクトフラッシュ(登録商標)、スマートメディア、マルチメディアカード等)などの読み書き可能な記録媒体へコピーする際、サーバと通信を行い、認証が行われ許可された状態においてのみコピー実行可能にする技術である。この技術により、バックアップ回数を制限したり、課金された状態でのみバックアップを許す等の制御を行うことができる。
BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。
マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで“トランスコード”とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、AVクリップ、Clip情報、プレイリスト情報を得る必要がある。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
(立体視方式)
第1実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に24枚の映像を表示させるのに対して、左右の映像合わせて1秒に48枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら2方式に限定するものではない。
表示装置300についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
(3D映像を格納するためのIndex.bdmvのデータ構造)
プレイリストではなくインデックスファイルを、2D再生装置と3D対応再生装置で区別し、2D再生装置では再生開始時に「Index.bdmv」を参照するが、3D再生装置では「Index.3dmv」を選択させるといった方法もとることができる。

(複数ストリームを扱うためのデータ構造)
複数のストリームがある場合、上記のようにサブパス情報を使ってもよいし、マルチアングルのためのmulti_clip_entriesを使ってもよい。multi_clip_entriesを使う場合、表示装置の画面のサイズに合わせてストリームを選択した後は、誤って他の画面サイズ用のストリームに切り替わらないよう、アングル変更のUOを禁止することが望ましい。
(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。
同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
(記録層の構成)
BD-ROMの各記録層には、立体視/平面視共用領域と、立体視専用領域と、平面視専用領域とを設けることが望ましい。
立体視/平面視共用領域は、立体視映像の再生時と平面視映像の再生時との両方でアクセスされる領域であって、ベースビュービデオストリームファイルに属する複数のエクステントと、ディペンデントビューストリームを格納したファイルに属する複数のエクステントとが交互に配置されて記録された連続領域である。
立体視専用領域及び平面視専用領域は、立体視/平面視共用領域に後続しており、記録層の境界直前に存在する。
立体視専用領域は、立体視出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視/平面視共用領域に記録されたベースビュービデオストリームファイルに属するエクステントに後続するエクステントと、立体視/平面視共用領域に記録されたディペンデントビュービデオストリームファイルに属するエクステントに後続するエクステントとが交互に配置されて記録された領域である。
平面視専用領域は、2D出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視専用領域に記録されたベースビュービデオストリームファイルに属するエクステントの複製物が記録された領域である、
(プログラムの実施形態)
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA(登録商標)バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを1つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
(データ構造の記述の仕方)
上述したようなデータ構造のうち、ある決まった型の情報が複数存在するという繰り返し構造は、for文に、制御変数の初期値と、繰り返し条件とを設定することで定義することができる。Do While文を用いてもよい。
また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。この記述には、switch文、case文を用いてもよい。
このように、各実施形態に示したデータ構造は、高級プログラミング言語の文法によって記述することができるので、各実施形態に示したデータ構造は、構文解析、最適化、資源割付、コード生成といった、コンパイラによる翻訳過程を経て、上記プログラムと同様、コンピュータが読み取り可能なコンピュータコードに変換された状態で記録媒体に記録される。こうして、高級プログラミング言語によって記述されたデータ構造は、オブジェクト指向言語においては、クラス構造体のメソッド以外の部分、つまり、クラス構造体における配列型のメンバー変数として扱われ、プログラムの一部をなす。つまり、各実施形態のデータ構造は、コンピュータコードに変換されてコンピュータ読取可能な記録媒体記に記録され、プログラムのメンバー変数となる。こうした扱いがなされるので、これまでに述べたデータ構造は、実質的にはプログラムと同じものである。
(光ディスクの再生)
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及び暗号化タイトルキー)、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能(プログラム)といったものを一意に特定するための情報である。
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、
(1) 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック
(2) 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック
(3) 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック(例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック)
を行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。
上述の(1)〜(3)のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵(デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー)を用いて、暗号化されたデータの解読を行なう。
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵(暗号化タイトルキーを復号して得られるタイトルキー)を利用してビデオストリームを復号し(デコードし)、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する(デコードする)。
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能(プログラム)などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報(公開鍵本体)を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号(例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等)は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の(1)の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域(第1の記録領域と称す)とは別の記録領域(第2の記録領域と称す)に設けること、およびこの第2の記録領域へのアクセスをするための制御回路を設けるとともに、第2の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
例えば、第2の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第2の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第2の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第2の記録領域に記録されたデータ(例えば半導体メモリ固有の識別番号)へのアクセス要求を発行すると、要求を受けた制御回路は第2の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第1の記録領域に記録するように構成すればよい。
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第2の記録領域に記録されたデータ(例えば半導体メモリ固有の識別番号)へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のX.509仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
また、半導体メモリーカードの第1の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。

(システムLSI)
再生装置の内部構成のうち、システムターゲットデコーダや、再生制御部7、プログラム実行部11等、ロジック素子を中心とした部分は、システムLSIで構成することがことが望ましい。
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置200の中核としての役割を果たす。
かかるシステムLSIは、再生装置200は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。
システムLSIのアーキテクチャは、Uniphierアーキテクチャに準拠させるのが望ましい。
Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。
・データ並列プロセッサDPP
これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。
・命令並列プロセッサIPP
これは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなる「Local Memory Controller」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「Processing Unit部」、複数アプリケーションの並列実行をProcessing Unit部に行わせる「Virtual Multi Processor Unit部」で構成される。
・MPUブロック
これは、ARMコア、外部バスインターフェイス(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(General Purpose Input Output)、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。
・ストリームI/Oブロック
これは、USBインターフェイスやATA Packetインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードリディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。
・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。
・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。
具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。

そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。
回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置200の内部構成図を基に作ることができる。
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUT(Look Up Table)に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。

本実施の形態は、ミドルウェアとシステムLSIに対応するハードウェア、システムLSI以外のハードウェア、ミドルウェアに対するインターフェイスの部分、ミドルウェアとシステムLSIのインターフェイスの部分、ミドルウェアとシステムLSI以外の必要なハードウェアへのインターフェイスの部分、ユーザインターフェースの部分で実現し、これらを組み込んで再生装置を構成したとき、それぞれが連携して動作することにより特有の機能が提供されることになる。
ミドルウェアに対するインターフェイス、および、ミドルウェアとシステムLSIのインターフェイスを適切に定義することにより、再生装置のユーザインターフェース部分、ミドルウェア部分、システムLSI部分をそれぞれ独立して並行開発することができ、より効率よく開発することが可能となる。なお、それぞれのインターフェイスのきり方には、様々な切り方がある。
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することな3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ
100 BD-ROM
200 再生装置
300 テレビ
400 3D眼鏡
500 リモコン
1 BDドライブ
2a,b リードバッファ
4 システムターゲットデコーダ
a プレーンメモリセット
5b プレーン合成部
6 HDMI送受信部
7 再生制御部
9 管理情報メモリ
10 レジスタセット
11 プログラム実行部
12 プログラムメモリ
13 HDMVモジュール
14 BD-Jプラットフォーム
15 ミドルウェア
16 モード管理モジュール
17 ユーザイベント処理部
18 ローカルストレージ
19 不揮発メモリ
23 PIDフィルタ
27 PIDフィルタ
31 プライマリビデオデコーダ
32 レフトビュービデオプレーン
33 ライトビュービデオプレーン
34 セカンダリビデオデコーダ
35 セカンダリビデオプレーン
36 PGデコーダ
37 PGプレーン
38 IGデコーダ
39 IGプレーン
40 プライマリオーディオデコーダ
41 セカンダリオーディオデコーダ
42 ミキサー

Claims (17)

  1. プレイリスト情報と、ストリームファイルとが記録された記録媒体であって、
    前記プレイリスト情報は、1つ以上の再生区間情報を含み、
    前記再生区間情報は、
    ビデオストリームを格納した前記ストリームファイルを指定するファイル参照情報を含み、
    前記ストリームファイルは、インターリーブされたトランスポートストリームファイルと、通常形式のトランスポートストリームファイルであり、
    前記インターリーブされたトランスポートストリームファイルは、レフトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分、及び、ライトビュービデオストリームを格納したトランスポートストリームを分割することで得られる複数の分割部分のそれぞれを、交互に配置することで構成されており、前記ファイル参照情報と同じ識別番号と、インターリーブされている旨を示す拡張子とによって特定され、
    前記通常形式のトランスポートストリームファイルは、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームの何れか一方であって、単独再生することができるベースビュービデオストリームを格納しており、前記ファイル参照情報と同じ識別番号と、通常形式である旨を示す拡張子とによって特定される
    ことを特徴とする記録媒体。
  2. 前記記録媒体は、ストリームファイル用ディレクトリと、インターリーブファイル用ディレクトリとを含み、
    前記通常形式のトランスポートストリームファイルは、前記ストリームファイル用ディレクトリに格納され、
    前記インターリーブされたトランスポートストリームファイルは、前記インターリーブファイル用ディレクトリに格納される
    ことを特徴とする請求項1記載の記録媒体。
  3. プレイリスト情報に従い、ビデオストリームを再生する再生装置であって、
    前記プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを記録媒体から読み出す読出手段と、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコーダと、
    自機の出力モードを格納しているモードレジスタと、
    前記モードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力する出力手段とを備え、
    前記読出手段は、
    出力モードが平面視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、トランスポートストリーム形式を示す拡張子とによって特定される通常形式のトランスポートストリームファイルを読み出し、
    出力モードが立体視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、インターリーブされていることを示す拡張子とによって特定されるインターリーブされたトランスポートストリームファイルを読み出す
    ことを特徴とする再生装置。
  4. 前記再生装置は、
    ユーザ設定を示すレジスタと、
    接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタと、
    複数の条件が成立するかどうかを判定して、複数の条件が成立した場合に、出力モードを立体視出力モードに設定する設定手段とを備え、
    前記複数の条件のうち第1条件は、前記ユーザ設定を示すレジスタが、ユーザが立体視再生を希望する旨を示しているという条件であり、
    前記複数の条件のうち第2条件は、前記接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタが、接続されている表示装置が立体視再生に対応していることを示しているという条件であり、
    前記第1条件及び前記第2条件が成立する場合、前記出力モードを立体視出力モードに設定する
    ことを特徴とする請求項3記載の再生装置。
  5. 前記再生装置の動作モードには、コマンドインタプリタが動作主体になる第1モード、バイトコードインタプリタが動作主体になる第2モードがあり、
    第2モードの設定中に、出力モードの切り替えが発生した際、バイトコードインタプリタによって実行されるバイトコードアプリケーションに、イベントを通知する
    ことを特徴とする請求項4記載の再生装置。
  6. プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを記録媒体から読み出すドライブ装置と共に、再生装置に組込むことができるシステムLSIであって、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコーダと、
    自機の出力モードを格納しているモードレジスタと、
    前記モードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力するよう再生装置の制御を行う制御手段とを備え、
    前記制御手段は、
    出力モードが平面視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、トランスポートストリーム形式を示す拡張子とによって特定される通常形式のトランスポートストリームファイルを読み出し、
    出力モードが立体視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、インターリーブされていることを示す拡張子とによって特定されるインターリーブされたトランスポートストリームファイルを読み出すようドライブ装置を制御する
    ことを特徴とするシステムLSI。
  7. 前記システムLSIは、
    ユーザ設定を示すレジスタと、
    接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタとを備え、
    前記制御手段は、複数の条件が成立するかどうかを判定して、複数の条件が成立した場合に、出力モードを立体視出力モードに設定し、
    前記複数の条件のうち第1条件は、前記ユーザ設定を示すレジスタが、ユーザが立体視再生を希望する旨を示しているという条件であり、
    前記複数の条件のうち第2条件は、前記接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタが、接続されている表示装置が立体視再生に対応していることを示しているという条件であり、
    前記第1条件及び前記第2条件が成立する場合、前記出力モードを立体視出力モードに設定する
    ことを特徴とする請求項6記載のシステムLSI。
  8. プレイリスト情報に従い、ビデオストリームを再生する処理をコンピュータ上で実行する再生方法であって、
    前記プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを記録媒体から読み出す読出ステップと、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコードステップと、
    コンピュータにおけるモードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力する出力ステップとを有し、
    前記読出ステップは、
    出力モードが平面視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、トランスポートストリーム形式を示す拡張子とによって特定される通常形式のトランスポートストリームファイルを読み出し、
    出力モードが立体視出力モードである場合、前記プレイリスト情報におけるファイル参照情報と、インターリーブされていることを示す拡張子とによって特定されるインターリーブされたトランスポートストリームファイルを読み出す
    ことを特徴とする再生方法。
  9. 前記コンピュータは、
    ユーザ設定を示すレジスタと、
    接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタとを有し、
    前記再生方法は、
    複数の条件が成立するかどうかを判定して、複数の条件が成立した場合に、出力モードを立体視出力モードに設定する設定ステップを有し、
    前記複数の条件のうち第1条件は、前記ユーザ設定を示すレジスタが、ユーザが立体視再生を希望する旨を示しているという条件であり、
    前記複数の条件のうち第2条件は、前記接続されている表示装置が立体視再生に対応しているか否かを示すケーパビリティレジスタが、接続されている表示装置が立体視再生に対応していることを示しているという条件であり、
    前記第1条件及び前記第2条件が成立する場合、前記出力モードを立体視出力モードに設定する
    ことを特徴とする請求項8記載の再生方法。
  10. プレイリスト情報と、ストリームファイルとが記録された記録媒体であって、
    前記プレイリスト情報は、1つ以上の再生区間情報を含み、
    前記再生区間情報は、
    前記ストリームファイルを指定するファイル参照情報と、
    再生可能なビデオストリームを示すストリーム許可テーブルと、
    ベースビュー指定情報とを含み、
    前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、
    前記ベースビュー指定情報は、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらが、単独で平面視再生を行うことができるベースビュービデオストリームであるかを示す
    ことを特徴とする記録媒体。
  11. プレイリスト情報に従い、ビデオストリームを再生する再生装置であって、
    前記プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを読み出す読出手段と、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコーダと、
    自機の出力モードを格納しているモードレジスタと、
    前記モードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力する出力手段とを備え、
    前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、
    前記ベースビュー指定情報は、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらが、単独で平面視再生を行うことができるベースビュービデオストリームであるかを示し、
    前記デコーダは、
    平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成するピクチャデータのデコードを行う
    ことを特徴とする再生装置。
  12. プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを読み出すドライブと共に、再生装置に組込むことができる集積回路であって、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコーダと、
    自機の出力モードを格納しているモードレジスタと、
    前記モードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力するよう制御を行う制御手段とを備え、
    前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、
    前記ベースビュー指定情報は、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらが、単独で平面視再生を行うことができるベースビュービデオストリームであるかを示し、
    前記デコーダは、
    平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成するピクチャデータのデコードを行う
    ことを特徴とする集積回路。
  13. プレイリスト情報に従い、ビデオストリームを再生する処理をコンピュータ上で実行する再生方法であって、
    前記プレイリスト情報におけるファイル参照情報で特定されるトランスポートストリームファイルを読み出す読出ステップと、
    読み出されたトランスポートストリームファイルに格納されているビデオストリームに含まれる圧縮ピクチャデータの供給を受けてデコードを行い、非圧縮のピクチャデータを得るデコードステップと、
    コンピュータにおけるモードレジスタに格納されている出力モードに従い、デコーダによって得られた非圧縮のピクチャデータを出力する出力ステップとを有し、
    前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、
    前記ベースビュー指定情報は、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらが、単独で平面視再生を行うことができるベースビュービデオストリームであるかを示し、
    前記デコードステップは、
    平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成するピクチャデータのデコードを行う
    ことを特徴とする再生方法。
  14. 立体視用眼鏡を着用したユーザに視聴させるための画像表示を、所定の表示期間内に実行する表示装置であって、
    前記表示期間は、
    ユーザが着用した眼鏡のレフトビューが透光状態になっていて、ライトビューが遮光状態になっている第1表示期間、ユーザが着用した眼鏡のライトビューが透光状態になっていて、レフトビューが遮光状態になっている第2表示期間、ユーザが着用した眼鏡のレフトビュー及びライトビューの双方が遮光状態になっている第3表示期間があり、
    前記第3表示期間における表示内容は、眼鏡を着用していないユーザに対してのメッセージを含む
    ことを特徴とする表示装置。
  15. 表示装置を視聴する際、ユーザが着用する眼鏡であって、
    視聴対象となる表示装置の表示期間は、
    レフトビューが表示される第1表示期間、ライトビューが表示される第2表示期間、眼鏡を装着していないユーザに対してのメッセージが表示される第3表示期間があり、
    前記第3表示期間において、レフトビュー及びライトビューの状態を何れも、遮光状態に設定する
    ことを特徴とする眼鏡。
  16. マルチチャネルの表示を行う表示装置を視聴する際、ユーザが着用する眼鏡であって、
    マルチチャネルのうち、特定のチャネルの表示期間は、その特定チャネルに割り当てられたユーザに割り当てられた眼鏡の状態を透光状態に設定し、
    特定チャネル以外の表示期間は、その特定チャネルに割り当てられたユーザに割り当てられた眼鏡の状態を遮光状態に設定する
    ことを特徴とする眼鏡。
  17. 眼鏡をリモートで制御する表示装置であって、
    マルチチャネルのうち、特定のチャネルの表示期間は、その特定チャネルに割り当てられたユーザに割り当てられた眼鏡の状態を透光状態に設定させ
    特定チャネル以外の表示期間は、その特定チャネルに割り当てられたユーザに割り当てられた眼鏡の状態を遮光状態に設定させる ことを特徴とする表示装置。
JP2010502593A 2008-09-30 2009-09-14 記録媒体、再生装置、システムlsi、再生方法、記録方法、記録媒体再生システム Active JP4564107B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10131608P 2008-09-30 2008-09-30
US61/101,316 2008-09-30
PCT/JP2009/004554 WO2010038365A1 (ja) 2008-09-30 2009-09-14 3d映像に係る記録媒体、再生装置、システムlsi、再生方法、眼鏡、表示装置

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2010040673A Division JP4733772B2 (ja) 2008-09-30 2010-02-25 記録媒体、再生装置、集積回路、再生方法、記録方法、記録媒体再生システム
JP2010040674A Division JP2010213267A (ja) 2008-09-30 2010-02-25 3d映像に係る眼鏡、表示装置

Publications (2)

Publication Number Publication Date
JP4564107B2 JP4564107B2 (ja) 2010-10-20
JPWO2010038365A1 true JPWO2010038365A1 (ja) 2012-02-23

Family

ID=42073150

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2010502593A Active JP4564107B2 (ja) 2008-09-30 2009-09-14 記録媒体、再生装置、システムlsi、再生方法、記録方法、記録媒体再生システム
JP2010040673A Active JP4733772B2 (ja) 2008-09-30 2010-02-25 記録媒体、再生装置、集積回路、再生方法、記録方法、記録媒体再生システム
JP2010040674A Pending JP2010213267A (ja) 2008-09-30 2010-02-25 3d映像に係る眼鏡、表示装置
JP2011217650A Expired - Fee Related JP4923162B2 (ja) 2008-09-30 2011-09-30 受信装置、受信方法

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2010040673A Active JP4733772B2 (ja) 2008-09-30 2010-02-25 記録媒体、再生装置、集積回路、再生方法、記録方法、記録媒体再生システム
JP2010040674A Pending JP2010213267A (ja) 2008-09-30 2010-02-25 3d映像に係る眼鏡、表示装置
JP2011217650A Expired - Fee Related JP4923162B2 (ja) 2008-09-30 2011-09-30 受信装置、受信方法

Country Status (12)

Country Link
US (3) US8089507B2 (ja)
EP (4) EP2395772A3 (ja)
JP (4) JP4564107B2 (ja)
KR (1) KR20110074823A (ja)
CN (2) CN102355590B (ja)
BR (1) BRPI0904620A2 (ja)
CA (1) CA2691727C (ja)
MX (1) MX2010002097A (ja)
MY (1) MY151243A (ja)
RU (1) RU2502214C2 (ja)
TW (1) TW201031207A (ja)
WO (1) WO2010038365A1 (ja)

Families Citing this family (135)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100184509A1 (en) * 2007-06-29 2010-07-22 Sylla Craig J Initializing and authenticating wagering game machines
KR100942142B1 (ko) * 2007-10-11 2010-02-16 한국전자통신연구원 객체기반 오디오 콘텐츠 송수신 방법 및 그 장치
KR20100040640A (ko) 2008-10-10 2010-04-20 엘지전자 주식회사 수신 시스템 및 데이터 처리 방법
KR20100040563A (ko) * 2008-10-10 2010-04-20 삼성전자주식회사 방송 표시장치 및 그의 2차원 영상 표시 방법
EP2348747A4 (en) * 2008-11-18 2013-08-28 Panasonic Corp REPRODUCTION DEVICE, INTEGRATED CIRCUIT, AND REPRODUCTION METHOD WHEREAS SPECIALIZED REPRODUCTION
US8606076B2 (en) * 2008-11-24 2013-12-10 Koninklijke Philips N.V. 3D video reproduction matching the output format to the 3D processing ability of a display
RU2504916C2 (ru) * 2008-12-01 2014-01-20 Шарп Кабусики Кайся Устройство воспроизведения содержимого и носитель записи
US20100186234A1 (en) 2009-01-28 2010-07-29 Yehuda Binder Electric shaver with imaging capability
US20100177162A1 (en) * 2009-01-15 2010-07-15 Charles Macfarlane Method and system for enabling 3d video and image processing using one full resolution video stream and one lower resolution video stream
WO2010084849A1 (ja) * 2009-01-22 2010-07-29 日本電気株式会社 立体映像鑑賞システム、表示システム、光シャッタおよび立体映像鑑賞方法
CN102396236B (zh) 2009-01-28 2015-03-25 Lg电子株式会社 广播接收机及其视频数据处理方法
JP5465523B2 (ja) * 2009-01-29 2014-04-09 三洋電機株式会社 立体画像表示システム
US8284236B2 (en) * 2009-02-19 2012-10-09 Sony Corporation Preventing interference between primary and secondary content in a stereoscopic display
US8723927B2 (en) * 2009-03-31 2014-05-13 Daniel Rosen Subtitling stereographic imagery
JP2010245761A (ja) * 2009-04-03 2010-10-28 Sony Corp 情報処理装置、情報処理方法、及び、プログラム
JP4915457B2 (ja) 2009-04-03 2012-04-11 ソニー株式会社 情報処理装置、情報処理方法、及び、プログラム
JP4962525B2 (ja) 2009-04-08 2012-06-27 ソニー株式会社 再生装置、再生方法、およびプログラム
JP5267886B2 (ja) 2009-04-08 2013-08-21 ソニー株式会社 再生装置、記録媒体、および情報処理方法
JP5407500B2 (ja) * 2009-04-08 2014-02-05 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
JP4984184B2 (ja) * 2009-04-08 2012-07-25 ソニー株式会社 再生装置および再生方法
JP4984194B2 (ja) * 2009-04-08 2012-07-25 ソニー株式会社 記録方法
JP4985807B2 (ja) * 2009-04-15 2012-07-25 ソニー株式会社 再生装置および再生方法
WO2010119549A1 (ja) * 2009-04-16 2010-10-21 株式会社 東芝 コンテンツデータ再生システム、及び記録装置
CN104065945A (zh) * 2009-04-27 2014-09-24 Lg电子株式会社 广播发射机、广播接收机及其3d视频数据处理方法
DE102009019051B4 (de) * 2009-04-28 2011-07-07 Giesecke & Devrient GmbH, 81677 Speichermedium mit Verschlüsselungseinrichtung
JP5400467B2 (ja) * 2009-05-01 2014-01-29 キヤノン株式会社 映像出力装置、その制御方法、及びプログラム
JP2011041249A (ja) * 2009-05-12 2011-02-24 Sony Corp データ構造および記録媒体、並びに、再生装置、再生方法、プログラム、およびプログラム格納媒体
RU2538307C2 (ru) * 2009-05-12 2015-01-10 Сони Корпорейшн Структура данных и носитель данных, воспроизводящее устройство, способ воспроизведения, программа и носитель для хранения программы
BRPI1007695B1 (pt) * 2009-05-18 2021-05-11 Koninklijke Philips N.V. método para prover pontos de entrada para um streaming de dados de vídeo, dispositivo para prover pontos de entrada para um streaming de dados de vídeo, dispositivo para reproduzir dados de vídeo, meio de armazenamento que compreende um sinal que transporta dados de vídeo e método para renderizar dados de vídeo à base de um sinal de um meio de armaznamento
US20110013888A1 (en) * 2009-06-18 2011-01-20 Taiji Sasaki Information recording medium and playback device for playing back 3d images
CN102461184B (zh) * 2009-06-23 2015-03-25 Lg电子株式会社 三维图像提供装置、显示装置及其方法
JP5273478B2 (ja) * 2009-07-07 2013-08-28 ソニー株式会社 映像表示装置および映像表示システム
WO2011019224A2 (ko) * 2009-08-12 2011-02-17 엘지전자 주식회사 3d 상태 정보 진단 방법 및 방송 수신기
JP2011082666A (ja) * 2009-10-05 2011-04-21 Sony Corp 信号伝送方法、信号送信装置及び信号受信装置
JP2011082683A (ja) * 2009-10-05 2011-04-21 Sony Corp 画像処理装置、画像処理方法、及び、プログラム
US20110080948A1 (en) * 2009-10-05 2011-04-07 Xuemin Chen Method and system for 3d video decoding using a tier system framework
JP5588144B2 (ja) * 2009-10-14 2014-09-10 パナソニック株式会社 映像信号処理装置及び映像信号処理方法
JP2011107589A (ja) * 2009-11-20 2011-06-02 Sony Corp 立体表示装置
US9414041B2 (en) * 2009-11-23 2016-08-09 Samsung Electronics Co., Ltd. Method for changing play mode, method for changing display mode, and display apparatus and 3D image providing system using the same
US20110126160A1 (en) * 2009-11-23 2011-05-26 Samsung Electronics Co., Ltd. Method of providing 3d image and 3d display apparatus using the same
JP4723682B2 (ja) * 2009-11-30 2011-07-13 シャープ株式会社 表示制御装置、表示制御方法、表示制御プログラム、コンピュータ読み取り可能な記録媒体、上記表示制御装置を備えた記録再生装置、音声出力装置、及び音声出力装置を備えた記録再生装置
EP2334088A1 (en) * 2009-12-14 2011-06-15 Koninklijke Philips Electronics N.V. Generating a 3D video signal
US20110157302A1 (en) * 2009-12-30 2011-06-30 Ati Technologies Ulc Three-dimensional video display system with multi-stream sending/receiving operation
US9247286B2 (en) 2009-12-31 2016-01-26 Broadcom Corporation Frame formatting supporting mixed two and three dimensional video data communication
US8964013B2 (en) * 2009-12-31 2015-02-24 Broadcom Corporation Display with elastic light manipulator
US8854531B2 (en) 2009-12-31 2014-10-07 Broadcom Corporation Multiple remote controllers that each simultaneously controls a different visual presentation of a 2D/3D display
US8823782B2 (en) 2009-12-31 2014-09-02 Broadcom Corporation Remote control with integrated position, viewer identification and optical and audio test
JP2011146828A (ja) * 2010-01-13 2011-07-28 Sony Corp データ構造、記録装置および記録方法、再生装置および再生方法、並びにプログラム
KR101774318B1 (ko) * 2010-02-10 2017-09-04 엘지전자 주식회사 이미지 디스플레이 방법 및 창치
JP2013080987A (ja) * 2010-02-15 2013-05-02 Panasonic Corp 立体映像表示装置
KR101289269B1 (ko) * 2010-03-23 2013-07-24 한국전자통신연구원 영상 시스템에서 영상 디스플레이 장치 및 방법
JP2011216965A (ja) * 2010-03-31 2011-10-27 Sony Corp 情報処理装置、情報処理方法、再生装置、再生方法、およびプログラム
US11711592B2 (en) 2010-04-06 2023-07-25 Comcast Cable Communications, Llc Distribution of multiple signals of video content independently over a network
US10448083B2 (en) 2010-04-06 2019-10-15 Comcast Cable Communications, Llc Streaming and rendering of 3-dimensional video
JP5577805B2 (ja) * 2010-04-08 2014-08-27 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム
JP5494152B2 (ja) * 2010-04-08 2014-05-14 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム
JP2011223248A (ja) * 2010-04-08 2011-11-04 Sony Corp 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム
KR101435594B1 (ko) * 2010-05-31 2014-08-29 삼성전자주식회사 디스플레이 장치 및 그 디스플레이 방법
JP2011254239A (ja) * 2010-06-01 2011-12-15 Sony Corp 記録装置、再生装置、記録再生システム、記録媒体およびプログラム
US8842170B2 (en) * 2010-06-01 2014-09-23 Intel Corporation Method and apparaus for making intelligent use of active space in frame packing format
CN102280943B (zh) * 2010-06-11 2013-10-16 深圳Tcl新技术有限公司 立体眼镜无线供电系统
TWI533662B (zh) 2010-06-24 2016-05-11 晨星半導體股份有限公司 顯示裝置與相關的眼鏡
JP2012018727A (ja) * 2010-07-08 2012-01-26 Sony Corp 情報処理装置、および情報処理方法、並びにプログラム
JP2012023488A (ja) * 2010-07-13 2012-02-02 Ntt Docomo Inc 画像処理装置、画像処理方法、表示装置及びプログラム
US8688679B2 (en) * 2010-07-20 2014-04-01 Smartek21, Llc Computer-implemented system and method for providing searchable online media content
WO2012011525A1 (ja) * 2010-07-21 2012-01-26 株式会社プランネット・アソシエイツ 三次元ビデオストリームへの映像変換方法
JP5652642B2 (ja) * 2010-08-02 2015-01-14 ソニー株式会社 データ生成装置およびデータ生成方法、データ処理装置およびデータ処理方法
JP2012039337A (ja) * 2010-08-06 2012-02-23 Hitachi Consumer Electronics Co Ltd 映像表示システム及び再生装置
JP5568404B2 (ja) * 2010-08-06 2014-08-06 日立コンシューマエレクトロニクス株式会社 映像表示システム及び再生装置
KR20120017649A (ko) * 2010-08-19 2012-02-29 삼성전자주식회사 디스플레이장치 및 그 제어방법
KR20120020477A (ko) * 2010-08-30 2012-03-08 삼성전자주식회사 입체영상표시장치 및 그 구동 방법
CN103262544A (zh) * 2010-09-10 2013-08-21 青岛海信电器股份有限公司 3d电视界面的显示方法和装置
JP2012080309A (ja) * 2010-10-01 2012-04-19 Hitachi Consumer Electronics Co Ltd コンテンツ受信機
US8941724B2 (en) 2010-10-01 2015-01-27 Hitachi Maxell Ltd. Receiver
JP5730524B2 (ja) * 2010-10-01 2015-06-10 日立マクセル株式会社 受信装置、および、受信方法
JP5550520B2 (ja) * 2010-10-20 2014-07-16 日立コンシューマエレクトロニクス株式会社 再生装置及び再生方法
MX2013004068A (es) * 2010-10-25 2013-05-22 Panasonic Corp Metodo de codificacion, dispositivo de visualizacion, metodo de codificacion.
US8610759B2 (en) * 2010-10-26 2013-12-17 Verizon Patent And Licensing Inc. Methods and systems for presenting adjunct content during a presentation of a media content instance
JP2012100181A (ja) * 2010-11-05 2012-05-24 Hitachi Consumer Electronics Co Ltd 映像出力装置、映像出力方法、受信装置および受信方法
CN102469319A (zh) * 2010-11-10 2012-05-23 康佳集团股份有限公司 三维菜单生成方法及三维显示装置
US20120120050A1 (en) * 2010-11-12 2012-05-17 Nokia Corporation Dual-mode two-dimensional/three-dimensional display
JP5527730B2 (ja) * 2010-11-15 2014-06-25 日立コンシューマエレクトロニクス株式会社 再生装置
US10424274B2 (en) * 2010-11-24 2019-09-24 Ati Technologies Ulc Method and apparatus for providing temporal image processing using multi-stream field information
KR20120058702A (ko) 2010-11-27 2012-06-08 전자부품연구원 디지털 방송에서 서비스 호환 방식 전송 방법
JP5955851B2 (ja) * 2010-12-03 2016-07-20 コーニンクレッカ フィリップス エヌ ヴェKoninklijke Philips N.V. 3d画像データの転送
US9584798B2 (en) 2010-12-09 2017-02-28 Google Technology Holdings LLC Method and apparatus for managing 3D video content
FR2970613B1 (fr) * 2011-01-13 2013-01-18 Alcatel Lucent Procede de fourniture a un observateur de donnees relatives a au moins un utilisateur d'un operateur de telecommunication ou de services internet dans un reseau
US9204123B2 (en) * 2011-01-14 2015-12-01 Comcast Cable Communications, Llc Video content generation
JP2012178783A (ja) * 2011-02-28 2012-09-13 Sony Corp 画像表示システム、表示装置、並びにシャッター眼鏡
US20130336632A1 (en) * 2011-03-11 2013-12-19 Akinobu Watanabe Recording device/method/medium and replaying device/method
WO2012123981A1 (ja) * 2011-03-11 2012-09-20 日立コンシューマエレクトロニクス株式会社 記録装置/方法/媒体、再生装置/方法
JPWO2012127837A1 (ja) * 2011-03-18 2014-07-24 パナソニック株式会社 表示装置、3d眼鏡、及び3d映像視聴システム
JP5452537B2 (ja) * 2011-04-04 2014-03-26 日立コンシューマエレクトロニクス株式会社 映像表示システム及び表示装置
US8681170B2 (en) * 2011-05-05 2014-03-25 Ati Technologies Ulc Apparatus and method for multi-streaming for more than three pixel component values
WO2012160812A1 (ja) * 2011-05-25 2012-11-29 パナソニック株式会社 映像処理装置、送信装置、立体映像視聴システム、映像処理方法、映像処理プログラム及び集積回路
JP5679578B2 (ja) * 2011-08-05 2015-03-04 株式会社ソニー・コンピュータエンタテインメント 画像処理装置
CN103733607B (zh) * 2011-08-10 2015-08-26 富士胶片株式会社 用于检测运动物体的装置和方法
JP5129376B1 (ja) * 2011-08-31 2013-01-30 株式会社東芝 映像処理装置および映像処理方法
US9185398B2 (en) 2011-09-22 2015-11-10 Google Technology Holdings LLC Method and apparatus for providing three-dimensional content
JP2013126048A (ja) * 2011-12-13 2013-06-24 Sony Corp 送信装置、送信方法、受信装置および受信方法
JP4984193B2 (ja) * 2012-02-01 2012-07-25 ソニー株式会社 再生装置、再生方法、および記録方法
US20130243079A1 (en) * 2012-03-19 2013-09-19 Nokia Siemens Networks Oy Storage and processing savings when adapting video bit rate to link speed
EP2830318A4 (en) * 2012-03-23 2015-12-02 Humax Holdings Co Ltd TRANSMISSION METHOD AND HYBRID RECEPTION METHOD FOR SVC VIDEO CONTENT EMPTYED IN MMT
KR20150004318A (ko) * 2012-04-23 2015-01-12 엘지전자 주식회사 3d 서비스를 위한 신호 처리 장치 및 방법
CN102780896A (zh) * 2012-05-31 2012-11-14 新奥特(北京)视频技术有限公司 一种流媒体素材支持3d技术的方法
TWI507032B (zh) * 2012-06-21 2015-11-01 Top Victory Invest Ltd And a display method and a device for preventing the display of the abnormality of the screen display
US20130342689A1 (en) * 2012-06-25 2013-12-26 Intel Corporation Video analytics test system
EP2876878B1 (en) * 2012-07-19 2018-12-12 Sun Patent Trust Image encoding method, image decoding method, image encoding device, and image decoding device
WO2014050447A1 (ja) * 2012-09-27 2014-04-03 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
WO2014054925A1 (en) * 2012-10-04 2014-04-10 Samsung Electronics Co., Ltd. Apparatus for reproducing recording medium and method thereof
JP2013055682A (ja) * 2012-10-31 2013-03-21 Toshiba Corp 映像処理装置および映像処理方法
US9860515B2 (en) * 2012-12-11 2018-01-02 Electronics And Telecommunications Research Institute Apparatus and method for 3D content broadcasting with boundary information
US8872983B2 (en) * 2012-12-27 2014-10-28 Kabushiki Kaisha Toshiba Information processing apparatus and display processing method
US20140212115A1 (en) * 2013-01-31 2014-07-31 Hewlett Packard Development Company, L.P. Optical disc with three-dimensional viewing depth
JP6450064B2 (ja) * 2013-03-18 2019-01-09 任天堂株式会社 情報処理装置、動画データのデータ構造、情報処理システム、動画再生プログラム、および、動画の再生方法。
KR20140120156A (ko) * 2013-04-02 2014-10-13 삼성전자주식회사 사용성이 향상된 모바일 디바이스를 위한 3차원 그래픽 데이터 생성 방법 및 이를 이용한 응용 개발 환경
CA2909006C (en) 2013-04-08 2022-07-26 Thomson Licensing Method for encoding and method for decoding a look-up table and corresponding devices
US9817626B2 (en) 2013-07-25 2017-11-14 Empire Technology Development Llc Composite display with multiple imaging properties
TW201506445A (zh) * 2013-08-01 2015-02-16 Hon Hai Prec Ind Co Ltd 顯示系統及顯示系統的顯示方法
TWI587706B (zh) * 2014-06-04 2017-06-11 佳世達科技股份有限公司 顯示器及其控制方法
EP3118854B1 (en) * 2014-09-10 2019-01-30 Panasonic Intellectual Property Corporation of America Recording medium, playback device, and playback method
JP6471915B2 (ja) * 2014-09-12 2019-02-20 ソニー株式会社 再生装置、再生方法、情報処理装置、情報処理方法、プログラム
US9866757B2 (en) 2014-10-27 2018-01-09 Wichita State University Computer program, system, and method for observation and communication for mobile settings, mobile applications, and wearable mobile devices
CN105573491B (zh) * 2015-11-13 2018-09-07 广东顺德中山大学卡内基梅隆大学国际联合研究院 裸眼3d私隐式虚拟人机交互系统及方法
CN106980579B (zh) 2016-09-30 2020-08-14 阿里巴巴集团控股有限公司 一种图片加载方法及装置
CN108235144B (zh) * 2016-12-22 2021-02-19 阿里巴巴(中国)有限公司 播放内容获取方法、装置及计算设备
CN106791795A (zh) * 2017-01-03 2017-05-31 京东方科技集团股份有限公司 3d视频流的发送方法及发送装置、接收方法及接收装置
CN109729735A (zh) * 2017-08-30 2019-05-07 松下知识产权经营株式会社 记录方法及记录装置
CN107680556B (zh) * 2017-11-03 2019-08-02 深圳市华星光电半导体显示技术有限公司 一种显示器节能方法、装置及显示器
MX2020007074A (es) * 2018-01-12 2020-09-09 Sony Corp Aparato y metodo de procesamiento de informacion.
KR102445544B1 (ko) 2018-04-02 2022-09-21 삼성전자 주식회사 전자장치, 그 제어방법 및 기록매체
US11100119B2 (en) * 2018-05-04 2021-08-24 Sap Se Determining data structures for spatial data based on spatial data statistics
CN110866793A (zh) * 2018-08-27 2020-03-06 阿里健康信息技术有限公司 虚拟对象展示、生成和提供方法
CN110427363B (zh) * 2019-01-11 2023-04-11 中国铁路西安局集团有限公司 基于关系型数据库的铁路信号设备图像信息转换存储方法
JP7242389B2 (ja) 2019-04-11 2023-03-20 株式会社東芝 パケット生成装置および方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004240469A (ja) * 2002-12-13 2004-08-26 Sharp Corp 画像データ作成装置およびそのデータを再生する画像データ再生装置
JP3935507B2 (ja) * 1996-02-28 2007-06-27 松下電器産業株式会社 高解像度および立体映像記録用光ディスク、光ディスク再生装置、光ディスク記録装置
WO2008114595A1 (ja) * 2007-03-22 2008-09-25 Mitsubishi Electric Corporation 映像再生装置および映像再生方法

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5767898A (en) * 1994-06-23 1998-06-16 Sanyo Electric Co., Ltd. Three-dimensional image coding by merger of left and right images
US5661518A (en) * 1994-11-03 1997-08-26 Synthonics Incorporated Methods and apparatus for the creation and transmission of 3-dimensional images
US5612735A (en) * 1995-05-26 1997-03-18 Luncent Technologies Inc. Digital 3D/stereoscopic video compression technique utilizing two disparity estimates
US5619256A (en) * 1995-05-26 1997-04-08 Lucent Technologies Inc. Digital 3D/stereoscopic video compression technique utilizing disparity and motion compensated predictions
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
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
US6111596A (en) * 1995-12-29 2000-08-29 Lucent Technologies Inc. Gain and offset correction for efficient stereoscopic coding and improved display
US5886736A (en) * 1996-10-24 1999-03-23 General Instrument Corporation Synchronization of a stereoscopic video sequence
EP2259584B1 (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
US6188442B1 (en) * 1997-08-01 2001-02-13 International Business Machines Corporation Multiviewer display system for television monitors
JP3931392B2 (ja) * 1997-08-25 2007-06-13 ソニー株式会社 立体画像用ビデオ信号生成装置、立体画像用ビデオ信号送出装置および立体画像用ビデオ信号受信装置
CN1223187C (zh) * 1997-08-29 2005-10-12 松下电器产业株式会社 记录高质量图像或标准图像的光盘及其记录和再生装置
US6043838A (en) * 1997-11-07 2000-03-28 General Instrument Corporation View offset estimation for stereoscopic video coding
US5963371A (en) * 1998-02-04 1999-10-05 Intel Corporation Method of displaying private data to collocated users
US6448952B1 (en) 1999-01-26 2002-09-10 Denso Corporation Stereoscopic image display device
JP2001045524A (ja) * 1999-01-26 2001-02-16 Denso Corp 立体表示装置
US6795863B1 (en) * 1999-08-10 2004-09-21 Intline.Com, Inc. System, device and method for combining streaming video with e-mail
GB0007868D0 (en) 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for editing digital video recordings and recordings made by such methods
US6859840B2 (en) * 2001-01-29 2005-02-22 Kasenna, Inc. Prefix caching for media objects
US20050248561A1 (en) * 2002-04-25 2005-11-10 Norio Ito Multimedia information generation method and multimedia information reproduction device
JP2004128769A (ja) 2002-10-01 2004-04-22 Pioneer Electronic Corp 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
KR100556826B1 (ko) * 2003-04-17 2006-03-10 한국전자통신연구원 Mpeg-4 기반의 양안식 3차원 동영상을 서비스하기 위한 인터넷 방송 시스템 및 그 방법
PL2088779T3 (pl) 2003-07-03 2011-06-30 Panasonic Corp Urządzenie odtwarzające, sposób odtwarzania, nośnik zapisu, urządzenie zapisujące i sposób zapisywania
KR100608051B1 (ko) 2003-07-07 2006-08-02 삼성전자주식회사 멀티앵글 데이터를 기록한 정보저장매체, 그 기록방법 및재생장치
WO2005004147A1 (en) * 2003-07-07 2005-01-13 Samsung Electronics Co., Ltd. Information storage medium storing multi angle data, and recording method and reproducing apparatus thereof
KR20050049924A (ko) 2003-11-24 2005-05-27 엘지전자 주식회사 고밀도 광디스크의 플레이리스트 구성방법, 관리방법 및재생방법과 기록재생장치
KR20050066264A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
JP2005227424A (ja) * 2004-02-12 2005-08-25 Nakagawa Kenkyusho:Kk 表示システム
WO2005112476A1 (en) * 2004-03-08 2005-11-24 Robert Gibson Multi-play theatre
US20050206751A1 (en) * 2004-03-19 2005-09-22 East Kodak Company Digital video system for assembling video sequences
JP2005286366A (ja) 2004-03-26 2005-10-13 Matsushita Electric Ind Co Ltd ファイル分割結合方法、並びに装置
JP4673885B2 (ja) * 2004-03-26 2011-04-20 エルジー エレクトロニクス インコーポレイティド 記録媒体及びテキストサブタイトルストリームの再生方法及びその装置
EP1737228B1 (en) 2004-04-07 2011-11-23 Panasonic Corporation Information recording apparatus and information converting method
JP4617773B2 (ja) 2004-08-23 2011-01-26 ソニー株式会社 記録装置および方法、再生装置および方法、記録媒体、並びにプログラム
US7609947B2 (en) * 2004-09-10 2009-10-27 Panasonic Corporation Method and apparatus for coordinating playback from multiple video sources
JP2006186768A (ja) * 2004-12-28 2006-07-13 Seiko Epson Corp 画像表示装置及び方法
CN102005228B (zh) * 2005-04-07 2013-04-10 松下电器产业株式会社 记录方法和再现装置
KR100813961B1 (ko) * 2005-06-14 2008-03-14 삼성전자주식회사 영상 수신장치
JP4630150B2 (ja) * 2005-07-26 2011-02-09 シャープ株式会社 立体画像記録装置及びプログラム
KR100728009B1 (ko) * 2005-08-22 2007-06-13 삼성전자주식회사 다시점 동영상을 부호화하는 방법 및 장치
JP2007074578A (ja) 2005-09-08 2007-03-22 Casio Comput Co Ltd 画像処理装置、撮影装置、及びプログラム
KR100667823B1 (ko) * 2005-10-13 2007-01-11 삼성전자주식회사 멀티 채널 영상 시스템
BRPI0616745A2 (pt) * 2005-10-19 2011-06-28 Thomson Licensing codificação / decodificação de vìdeo com múltiplas visualizações usando codificação / decodificação de vìdeo escalonável
WO2007067020A1 (en) * 2005-12-09 2007-06-14 Electronics And Telecommunications Research Institute System and method for transmitting/receiving three dimensional video based on digital broadcasting
KR100747598B1 (ko) * 2005-12-09 2007-08-08 한국전자통신연구원 디지털방송 기반의 3차원 입체영상 송수신 시스템 및 그방법
WO2007117485A2 (en) * 2006-04-03 2007-10-18 Sony Computer Entertainment Inc. Screen sharing method and apparatus
US8305488B2 (en) * 2006-05-10 2012-11-06 Universal City Studios Llc Time-sliced multiplexed image display
JP4857895B2 (ja) 2006-05-10 2012-01-18 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
KR100716142B1 (ko) * 2006-09-04 2007-05-11 주식회사 이시티 스테레오스코픽 영상 데이터의 전송 방법
CN101523924B (zh) * 2006-09-28 2011-07-06 皇家飞利浦电子股份有限公司 3d菜单显示
WO2008054100A1 (en) 2006-11-01 2008-05-08 Electronics And Telecommunications Research Institute Method and apparatus for decoding metadata used for playing stereoscopic contents
KR101362941B1 (ko) * 2006-11-01 2014-02-17 한국전자통신연구원 스테레오스코픽 콘텐츠 재생에 이용되는 메타 데이터의복호화 방법 및 장치
DE102006055641B4 (de) 2006-11-22 2013-01-31 Visumotion Gmbh Anordnung und Verfahren zur Aufnahme und Wiedergabe von Bildern einer Szene und/oder eines Objektes
US8717348B2 (en) * 2006-12-22 2014-05-06 Texas Instruments Incorporated System and method for synchronizing a viewing device
JP4289403B2 (ja) * 2007-02-02 2009-07-01 ソニー株式会社 編集装置及び編集方法
US8565584B2 (en) 2007-02-02 2013-10-22 Sony Corporation Editing apparatus and editing method
US8400497B2 (en) * 2007-09-07 2013-03-19 Samsung Electronics Co., Ltd Method and apparatus for generating stereoscopic file
US8384764B2 (en) * 2007-12-20 2013-02-26 Samsung Electronics Co., Ltd. Method and apparatus for generating multiview image data stream and method and apparatus for decoding the same
KR101506217B1 (ko) * 2008-01-31 2015-03-26 삼성전자주식회사 스테레오스코픽 영상의 부분 데이터 구간 재생을 위한스테레오스코픽 영상 데이터스트림 생성 방법과 장치, 및스테레오스코픽 영상의 부분 데이터 구간 재생 방법과 장치

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3935507B2 (ja) * 1996-02-28 2007-06-27 松下電器産業株式会社 高解像度および立体映像記録用光ディスク、光ディスク再生装置、光ディスク記録装置
JP2004240469A (ja) * 2002-12-13 2004-08-26 Sharp Corp 画像データ作成装置およびそのデータを再生する画像データ再生装置
WO2008114595A1 (ja) * 2007-03-22 2008-09-25 Mitsubishi Electric Corporation 映像再生装置および映像再生方法

Also Published As

Publication number Publication date
US20120062711A1 (en) 2012-03-15
CN101911713B (zh) 2014-01-08
MY151243A (en) 2014-04-30
EP2482564A3 (en) 2013-09-25
EP2355533A4 (en) 2013-09-18
CA2691727C (en) 2016-10-04
EP2395770A3 (en) 2013-09-25
JP4923162B2 (ja) 2012-04-25
JP2012044687A (ja) 2012-03-01
JP2010233211A (ja) 2010-10-14
KR20110074823A (ko) 2011-07-04
TW201031207A (en) 2010-08-16
RU2502214C2 (ru) 2013-12-20
EP2395770A2 (en) 2011-12-14
US8089507B2 (en) 2012-01-03
JP4733772B2 (ja) 2011-07-27
EP2355533A1 (en) 2011-08-10
RU2010107209A (ru) 2011-09-10
US20100208042A1 (en) 2010-08-19
CN101911713A (zh) 2010-12-08
MX2010002097A (es) 2010-08-02
CA2691727A1 (en) 2010-03-30
BRPI0904620A2 (pt) 2020-08-18
CN102355590A (zh) 2012-02-15
JP2010213267A (ja) 2010-09-24
CN102355590B (zh) 2014-11-12
JP4564107B2 (ja) 2010-10-20
WO2010038365A1 (ja) 2010-04-08
US20120275765A1 (en) 2012-11-01
EP2482564A2 (en) 2012-08-01
US9344703B2 (en) 2016-05-17
EP2395772A2 (en) 2011-12-14
EP2395772A3 (en) 2013-09-18

Similar Documents

Publication Publication Date Title
JP4564107B2 (ja) 記録媒体、再生装置、システムlsi、再生方法、記録方法、記録媒体再生システム
JP5027952B2 (ja) 受信装置
JP4588118B1 (ja) 記録媒体、再生装置
JP5291026B2 (ja) 3d映像を再生する再生装置、および配信装置
WO2010038409A1 (ja) 再生装置、記録媒体、及び集積回路
WO2010095381A1 (ja) 記録媒体、再生装置、集積回路
WO2010095410A1 (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: 20100706

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: 20100729

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

Free format text: PAYMENT UNTIL: 20130806

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4564107

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150