JP4414460B2 - 記録媒体、再生装置、記録方法、再生方法 - Google Patents

記録媒体、再生装置、記録方法、再生方法 Download PDF

Info

Publication number
JP4414460B2
JP4414460B2 JP2007512969A JP2007512969A JP4414460B2 JP 4414460 B2 JP4414460 B2 JP 4414460B2 JP 2007512969 A JP2007512969 A JP 2007512969A JP 2007512969 A JP2007512969 A JP 2007512969A JP 4414460 B2 JP4414460 B2 JP 4414460B2
Authority
JP
Japan
Prior art keywords
stream
time
packet
information
main
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.)
Active
Application number
JP2007512969A
Other languages
English (en)
Other versions
JPWO2006109716A1 (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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37086991&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP4414460(B2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2006109716A1 publication Critical patent/JPWO2006109716A1/ja
Application granted granted Critical
Publication of JP4414460B2 publication Critical patent/JP4414460B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/30—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording
    • G11B27/3027—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on the same track as the main recording used signal is digitally coded
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2508—Magnetic discs
    • G11B2220/2516—Hard disks
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/40—Combinations of multiple record carriers
    • G11B2220/45—Hierarchical combination of record carriers, e.g. HDD for fast access, optical discs for long term storage or tapes for backup
    • G11B2220/455—Hierarchical combination of record carriers, e.g. HDD for fast access, optical discs for long term storage or tapes for backup said record carriers being in one device and being used as primary and secondary/backup media, e.g. HDD-DVD combo device, or as source and target media, e.g. PC and portable player
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/87—Regeneration of colour television signals
    • H04N9/8715—Regeneration of colour television signals involving the mixing of the reproduced video signal with a non-recorded signal, e.g. a text signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)

Description

本発明は、Out-of-MUXフレームワークの技術分野に属する発明である。
Out-of-MUXフレームワークとは、BD-ROM等のリードオンリー型の記録媒体に記録されているデジタルストリームと、リライタブル型の記録媒体である、ローカルストレージに記録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生させる技術である。
ここでBD-ROMに記録されているデジタルストリームが、映画作品の本編を構成するものであり、ローカルストレージに記録されているデジタルストリームが、映画監督のコメンタリを構成する場合、上述したOut-of-MUXフレームワークを実現することにより、BD-ROM上の本編と、ローカルストレージ上のコメンタリとを再生に供して、BD-ROMの内容拡充を図ることができる。尚、リードオンリー型記録媒体の先行技術としては、以下の特許文献に記載されているものがある。
特願平８ー８３４７８号公報
ところで上述したOut-of-MUXフレームワークでは、BD-ROMに記録されたストリームと、ローカルストレージに記録されたストリームとを同時に読み出して、それらのストリームを構成するTSパケットを、デコーダに供給せねばならない。このデコーダへの供給にどれだけの帯域が必要であるかを検討すると、これらBD-ROMからの供給ビットレートが48Mbps、ローカルストレージからの供給ビットレートが48Mbpsである場合、ワーストケースにおいて、96Mbit(48Mbit＋48Mbit)ものデータ供給が、上述した同時読み出しの期間内において発生する可能性がある。かかるワーストケースの発生が考えられるなら、96MbpsというビットレートでTSパケットを供給できるよう装置内の帯域を上げねばならない。またそれが不可能であるならば、デコーダ内に大きなバッファを設けておき、当該供給が一時点に集中しないように、TSパケットの先読みをデコーダに行わせる必要がある。しかし上述した同時読み出しの期間が、短ければいざしらず、2時間という映画再生のオーダであれば、バッファの容量が不足し、充分な先読みが行えない。
充分な先読みが行えないため、先読みのためのバッファにアンダーフローが生じると、ビデオ又はオーディオの欠落が発生するため再生品質が著しく低下する。かといって、高いビットレートでのデータ供給が必要になるなら、再生装置の低価格化を大きく妨げる結果となる。
本発明の目的は、高い帯域を必要とせずとも、別々の記録媒体から供給されたデジタルストリームを、デコーダに供給することができる、記録媒体を提供することである。
上記目的を達成するため、本発明にかかる記録媒体は、プレイリスト情報が記録された記録媒体であって、前記プレイリスト情報は、メインパス情報、サブパス情報を含み、前記メインパス情報は、複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、前記サブパス情報は、複数デジタルストリームの残りのうち1つのデジタルストリームを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、前記メインパス情報はストリームテーブルを含み、前記ストリームテーブルは、メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、ストリームテーブルは、複数のストリームエントリーを含み、各ストリームエントリーには、前記エレメンタリストリームを構成するTSパケットであって、同時再生が許可されているもののパケット識別子が記載されており、前記メインストリーム及びサブストリームは、TSパケット列であり、各TSパケットにはアライバルタイムスタンプが付加されており、複数のTSパケットであってストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを構成するものの単位時間当たりの総データサイズは、48Mビット以下であり、単位時間当たりの総データサイズは、アライバルタイムクロック時間軸上において、１秒の時間幅をもつ確認枠であるウィンドゥによって囲まれる範囲内で算出され、当該ウィンドゥの開始点が、アライバルタイムクロック時間軸における何れの時点に存在したとしても、ウィンドゥによって囲まれる範囲内の総データサイズが48Mビット以下になっていることを特徴としている。
ストリームテーブルにおいて再生が許可されている複数エレメンタリストリームの単位時間当たりの総データサイズは、所定値以下であり、ワーストケースにおいても、単位時間当たりに転送すべきTSパケットの量は、所定の上限値を上回ることはない。
例えば単位時間が1秒であり、所定の上限値が48Mbitである場合、ストリームの同時読み出しのため、TSパケットの供給量が局所的に96Mbitにまであがったとしても、“1秒当たりのビット量が48Mbit以下”に制限されるため、ワーストケースにあたる96Mbitのデータ供給量は、0.5秒以上継続することはない。
ストリームの再生時間軸上のどの時点においても「ワーストケースが0.5秒以上継続しない」との保障があるので、96Mbit×0.5秒のサイズのTSパケットを、常に先読みしてデコーダに供給するように、再生装置を構成しておけば、デコーダ内のバッファのアンダーフローを回避することができる。
「96Mbit×0.5秒」を上限値とした先読みにより、アンダーフローを生じさせることなく、TSパケットを安定的にデコーダに供給することができるので、Out-of-MUXフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。 バンド幅を高めるなくことなく、BD-ROMのみを対象としたような再生装置において、Out-of-MUXフレームワークを実現することができるので、Out-of-MUXフレームワークを実現するような再生装置を、低価格で、市場に供給することができる。
また「1秒当たり48Mbps以下」との制限があるので、再生装置は、上述したような“常に先読みを行う”という単純な制御を実行していれば、ワーストケースとなるデータ供給が発生したとしてもアンダーフローの発生を避けることができる。ワーストケースとなるデータ供給がいつ発生するかを予測する予測処理等の実装を省略することができるので、再生装置を、容易に開発することができる。
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ローカルストレージ２００である。ローカルストレージ２００は、再生装置３００、テレビ４００、AVアンプ５００、スピーカ６００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。
以降、BD-ROM１００、ローカルストレージ２００、再生装置３００について説明を行う。
BD-ROM１００は、映画作品が記録された記録媒体である。
ローカルストレージ２００は、再生装置に組み込まれ、映画配給者のサーバから配信されたコンテンツの受け皿として利用されるハードディスクである。
再生装置３００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。また、映画配給者のサーバ７００から、ネットワークを通じてダウンロードしたコンテンツを、ローカルストレージ２００に格納し、こうしてローカルストレージ２００に記録されたコンテンツと、BD-ROM１００に記録されたコンテンツと組み合わせて、BD-ROM１００のコンテンツを拡張/更新を行うことができる。BD-ROM１００の記録内容に、ローカルストレージ２００の記録内容を組み合わせて、BD-ROM１００に記録されていないデータを、恰も、記録されているように扱う技術を“バーチャルパッケージ”という。
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ファイルシステム上における改良で実現することができる。
＜BD-ROMの概要＞
図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。この第1段目においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
このBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリと呼ばれる3つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls)がある。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts)がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図３は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts)は、AVClipを格納している。AVClipはMPEG2-TransportStream形式のデジタルストリームである。このデジタルストリームは、デジタル化された映像、デジタル化された音声を(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１段目、下２段目)、TSパケットに変換して(下３段目)、これらを多重化することで構成される。
以降、これらのビデオストリーム、オーディオストリーム、PGストリーム、IGストリームについて説明する。

＜ビデオストリーム＞
ビデオストリームは、映画作品の動画像を構成するストリームであり、SD画像、HD画像であるピクチャデータから構成される。ビデオストリームには、VC-1のビデオストリーム、MPEG4-AVCのビデオストリーム、MPEG2-Videoのビデオストリームといった形式が存在する。MPEG4-AVCのビデオストリームでは、IDRピクチャ,Iピクチャ,Pピクチャ,Bピクチャに、PTS、DTSといったタイムスタンプが付され、このピクチャの単位で、再生制御がなされる。このように、PTS、DTSが付されて、再生制御の単位となる、ビデオストリームの一単位を“VideoPresentation Unit”という。

＜オーディオストリーム＞
オーディオストリームは、映画作品の音声を表すストリームであり、LPCMオーディオストリーム、DTS-HDオーディオストリーム、DD/DD+オーディオストリームやDD/MLPオーディオストリームといった形式が存在する。オーディオストリームにおけるオーディオフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディオストリームの一単位を“AudioPresentation Unit”という。

＜PGストリーム＞
PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。PGストリームは、PCS(PresentationControl Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(ObjectDefine Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。
WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS(PalletDefine Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(PresentationControl Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、ColorChange、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
＜IGストリーム＞
IGストリームは、対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(InteractiveComposition Segment)、PDS(Palette Difinition Segment)、ODS(Object DefinitionSegment)と呼ばれる機能セグメントからなる。ODS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(PaletteDifinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(InteractiveComposition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。
ここでAVClipは、1つ以上の“STC＿Sequence”から構成される。“STC＿Sequence”とは、AVストリームのシステム基準時刻であるSTC(SystemTime Clock)の不連続点(system time-base discontinuity)が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR(ProgramClock Reference)を運ぶPCRパケットの不連続情報(discontinuity＿indicator)がONである点である。
図４は、PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目は、ビデオストリームを示し、第3段目はオーディオストリームを示す。第2段目は、PESパケット列を示す。本図の矢印yy1,yy2,yy3,yy4に示すように、ビデオストリームにおける複数のVideoPresentation UnitであるIDR、Bピクチャ、Pピクチャは、複数に分割され、個々の分割部分が、PESパケットのペイロード(図中のV＃1,V＃2,V＃3,V＃4)に格納されることがわかる。またオーディオストリームを構成するAudioPresentation Unitであるオーディオフレームは、矢印aa1,aa2に示すように、個々のPESパケットのペイロード(図中のA＃1,A＃2)に格納されていることがわかる。
図５は、ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示している。下段は、ビデオストリームと、オーディオストリームとを格納した複数のPESパケット(図中のV＃1,V＃2,V＃3,V＃4,A＃1,A＃2)を示す。ビデオストリーム及びオーディオストリームは、別個のPESパケットに格納されることが本図からわかる。上段は、下段のPESパケットを格納したプログラムストリーム及びトランスポートストリームを示す。プログラムストリームに多重化される場合、PESパケットは、１パックに収められる。トランスポートストリームに多重化される場合、PESパケットは分割され、個々の分割部分は、複数のTSパケットのペイロードに格納される。BD-ROMにおける格納方式は、前者のプログラムストリームではなく、後者のトランスポートストリームのものとなる。図５ではそのようになっていないが、トランスポートストリームに使われるビデオPESパケットは１つのフレーム、もしくはペアとなる２つのフィールドを格納するのが一般的である。
図６は、トランスポートストリームの詳細を示す図である。本図における第1段目は、MPEG２トランスポートストリームを構成する複数のTSパケット列であり、第2段目はTSパケットの内部構成を示す。この第2段目に示すように、１つのTSパケットは、“ヘッダ”と、“適用フィールド（adaptationfield）”と、“ペイロード”とから構成される。引き出し線th1は、TSパケットヘッダの構成をクローズアップしている。このこの引き出し線に示すように、TSパケットヘッダには、PESパケットの先頭を格納していることを示す「ユニット開始表示（payload＿unit＿start＿indicator）」、トランスポートストリームに多重化されるエレメンタリストリームの種別を示す「PID（PacketIdentifier）」、TSパケットに適用フィールドが存在しているか否かを示す「適用フィールド制御」などが存在する。
引き出し線th2は、適用フィールドの内部構成をクローズアップしている。適用フィールドはTSパケットヘッダの適用フィールド制御が“1”に設定されている場合に、TSパケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、エントリーポイントであることを示す「ランダムアクセス表示（random＿access＿indicator）」、T-STD（TransportSystem Target Decoder）のSTC（System Time Clock）を与える「PCR（Program Clock Reference）」などが、この適用フィールドに格納される。
図７は、PAT、PMTパケットの内部構成を示す図である。これらのパケットは、トランスポートストリームのプログラム構成を記述するものである。
本図における引き出し線hm1は、トランスポートストリームに存在するPID=0のTSパケットの構成をクローズアップしている。かかるTSパケットは、PAT（ProgramAssociation Table）パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。PATパケットのPIDは常に“0”である。PATパケットには、PAS（ProgramAssociation Section）が格納される。引き出し線hm2は、PASの内部構成をクローズアップしている。この引き出し線に示すようにPASは、program＿number(番組番号)と、programmap table(PMTのPID)とを対応付けて示している。引き出し線hm3は、トランスポートストリームに存在するPID=0x100のTSパケットの構成をクローズアップしている。かかるTSパケットは、PMTパケットと呼ばれる。引き出し線hm4に示すように、PMTパケットのPMSは、そのPMSに対応する番組に含まれるストリーム種別を示す「stream＿type」と、そのストリームのPIDである「elementary＿PID」とを含む。本図の例では、番組番号＃1の番組は、PID=0x100のPMTを有しており、PID=0x200と0x201とを有するMPEG２ビデオと、ADTSオーディオとが、この番組番号＃1の番組を構成していることがわかる。このようにして、常にPID=0であるPATからPMTのPIDを取得し、このPMTのPIDからPMTパケットを取得して、PMSを参照することで、トランスポートストリーム中の番組と、その構成ストリームのPIDやストリームタイプとを知得することができる。
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図８は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS＿extra＿header(図中のハッチング部)、が付されて、192バイト長のSourceパケットになる。このTS＿extra＿headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival＿Time＿Stampを含む。ATSヘッダをTSパケットごとに付与してストリームを形成する理由は、TSパケットごとにデコーダ（STD）への入力時刻を与えるためである。デジタル放送ではトランスポートストリームは固定ビットレートとして扱われる。そのため、NULLパケットと呼ばれるダミーのTSパケットを多重化して固定ビットレートとしたトランスポートストリームを放送している。光ディスクのような限られた記録容量の記録媒体にストリームを記録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である。そのためBD-ROMではNULLパケットを記録することはしない。そして、可変ビットレートの記録方式に対応するため、個々のTSパケットにATSを付与した上でトランスポートストリームを記録する。このATSを用いることで、TSパケットごとにデコーダ入力時刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降、ATSヘッダとTSパケットの１組をソースパケット（SourcePacket）と呼ぶ。
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC＿Sequence”を構成する。“ATC＿Sequence”とは、Sourceパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、連続性が存在するSourceパケット列を“ATC＿Sequence”という。
かかるATC＿SequenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳextent以上のデータ長を有する。
AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentを検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Ｔjump＝Ｔaccess+Ｔoverhead
で与えられる。

Ｔaccessは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時間である。

BD-ROMから読み出されたTSパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Rudというビットレートで行われ、ECCブロックにおけるセクタ数をSeccとした場合、
Ｔoverheadは、

Ｔoverhead≦(2×Secc×8)／Rud＝20m秒
という計算で与えられる。

BD-ROMから読み出されたTSパケットは、Sourceパケットの状態でリードバッファに格納された上、TS＿Recording＿rateという転送レートで、デコーダに供給される。
TS＿Recording＿rateという転送レートでの、デコーダへのTSパケット供給が跡絶えさせないためには、Ｔjumpの間、リードバッファからデコーダへのTSパケット出力が継続している必要がある。ここでリードバッファからの出力は、TSパケットではなく、Sourceパケットの状態でなされるので、TSパケットのSourceパケットとのサイズ比を192/188とした場合、Ｔjumpの間、(192/188×TS＿Recording＿rate)という転送レートにより、リードバッファからのSourceパケット出力が継続している必要がある。

従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Ｂoccupied≧(Tjump/1000×8)×((192/188)×TS＿Recording＿rate)
となる。

リードバッファへの入力レートはRud、リードバッファからの出力レートはTS＿Recording＿rate×(192/188)であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、(Rud−TS＿Recording＿rate×(192/188))になる。
このＢoccupiedを、リードバッファに蓄積するのに要する時間Txは、

Tx＝Ｂoccupied/(Rud−TS＿Recording＿rate×(192/188))
になる。

BD-ROMからの読み出しには、この時間TxにおいてRudでのTSパケット入力を継続する必要があるので、AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentは、

Ｓextent＝Rud×Tx
＝Rud×Ｂoccupied/(Rud−TS＿Recording＿rate×(192/188))
≧Rud×(Tjump/1000×8)×((192/188)×TS＿Recording＿rate)
/(Rud−TS＿Recording＿rate×(192/188))

≧(Rud×Tjump/1000×8)×
×TS＿Recording＿rate×192/(Rud×188−TS＿Recording＿rate×192)
になる。
よって
Ｓextent≧
(Tjump×Rud/1000×8)×
（TS＿Recording＿rate×192/(Rud×188−TS＿Recording＿rate×192))

になる。

AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさないように算出されたＳextent以上のデータ長をもつことにより、AVClipを構成する各ファイルエクステントが、BD-ROM上において離散的に位置されたとしても、再生時においてデコーダへのTSパケット供給が途絶えさせることなく、連続的に読み出されることになる。
上述したファイルエクステントは、Sourceパケット32個集めたアラインドユニット（Aligned Unit、6KByteのデータサイズ）を最小単位として構成されている。したがって、BDでのストリームファイル（XXXXX.AVClip）のファイルサイズは常に6KByteの倍数となる。

図９は、Aligned Unitの内部構成を示す図である。Aligned Unitは、32個のSourceパケットから構成され、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。BD-ROMにおけるセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAlignedUnitの単位でBD-ROMをアクセスする限り、32個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。BD-ROMに記録され、高画質なビデオストリームが多重化されているAVClipを、以下“MainClip”と呼ぶ。これに対し、ローカルストレージに記録され、MainClipと同時に再生されるAVClipを、“SubClip”とよぶ。
BD-ROMに記録されているMainClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々のエレメンタリストリームに対応するものである。MainClipを多重分離することで得られるパーシャルトランスポートストリームであって、1つのエレメンタリストリームに対応するものを“プライマリTS”という。

＜BD-ROMの構成その２.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.clpi)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図１０は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、

i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』からなる。
ClipInfoには、このClip情報が参照するAVClipのアプリケーションタイプ（application＿type）がある。かかるClipInfoを参照することで、アプリケーションタイプによってMainClipかSubClipかや、動画を含んでいるのか静止画(スライドショー)を含んでいるのかなどが識別できる。またClipInfoには、上述したTS＿recording＿rateが記述されている。
Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。
Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramSequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSD画像からHD画像に変化している点等をいう。

続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP＿map＿for＿one＿stream＿PID(EP＿map＿for＿one＿stream＿PID[0]〜EP＿map＿for＿one＿stream＿PID[Ne-1])からなる。これらEP＿map＿for＿one＿stream＿PIDは、AVClipに属する個々のエレメンタリストリームについてのEP＿mapである。EP＿mapは、1つのエレメンタリストリーム上において、AccessUnitが存在するエントリー位置のパケット番号(SPN＿EP＿start)を、エントリー時刻(PTS＿EP＿start)と対応づけて示す情報である。図中の引き出し線cu3は、EP＿map＿for＿one＿stream＿PIDの内部構成をクローズアップしている。
これによると、EP＿map＿for＿one＿stream＿PIDは、Nc個のEP＿High(EP＿High(0)〜EP＿High(Nc-1))と、Nf個のEP＿Low(EP＿Low(0)〜EP＿Low(Nf-1))とからなることがわかる。ここでEP＿Highは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN＿EP＿start及びPTS＿EP＿startの上位ビットを表す役割をもち、EP＿Lowは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN＿EP＿start及びPTS＿EP＿startの下位ビットを示す役割をもつ。
図中の引き出し線cu4は、EP＿Highの内部構成をクローズアップしている。この引き出し線に示すように、EP＿High(i)は、EP＿Lowに対する参照値である『ref＿to＿EP＿Low＿id[i]』と、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS＿EP＿High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN＿EP＿High[i]』とからなる。ここでiとは、任意のEP＿Highを識別するための識別子である。
図中の引き出し線cu5は、EP＿Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP＿Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is＿angle＿change＿point(EP＿Low＿id)』と、対応するAccessUnitのサイズを示す『I＿end＿position＿offset(EP＿Low＿id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS＿EP＿Low(EP＿Low＿id)』と、対応するAccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN＿EP＿Low(EP＿Low＿id)』とからなる。ここでEP＿Low＿idとは、任意のEP＿Lowを識別するための識別子である。

＜Clip情報の説明その２.EP＿map＞
以下、具体例を通じて、EP＿mapについて説明する。図１１は、映画のビデオストリームに対するEP＿map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP＿mapの設定を示す。
第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP＿mapは、t1〜t7をエントリー時刻(PTS＿EP＿start)として示し、これに対応づけてエントリー位置(SPN＿EP＿start)を示すよう、設定される。

＜PlayList情報＞
続いて、PlayList情報について説明する。拡張子“mpls”が付与されたファイル(00001.mpls)は、PlayList(PL)情報を格納したファイルである。
図１２は、PlayList情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())を含む。
＜PlayList情報の説明その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip＿Information＿file＿name』と、AVClipの符号化方式を示す『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』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem＿random＿access＿flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still＿mode』と、『STN＿table』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『In＿time』、再生区間の終点を示す時間情報『Out＿time』の組みであり、再生経路情報とは、この『In＿time』及び『Out＿time』の組みから構成される。
図１３は、AVClipと、PlayList情報との関係を示す図である。第1段目は、PlayList情報がもつ時間軸(PlayList時間軸)を示す。第2段目から第5段目は、EP＿mapにて参照されているビデオストリームを示す。
PlayList情報は、PlayItem情報＃1,＃2という2つのPlayItem情報を含んでおり、これらPlayItem情報＃1,＃2のIn＿time,Out＿timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。
以上が、BD-ROM１００についての説明である。
＜ローカルストレージ２００＞
続いて、本発明にかかる記録媒体である、ローカルストレージ２００について説明する。図１４は、ローカルストレージ２００の内部構成を示す図である。本図に示すように、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。
本図の第４段目にローカルストレージ２００を示し、第３段目にローカルストレージ２００上のトラックを示す。本図のトラックは、ローカルストレージ２００の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてローカルストレージ２００の応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第1段目のようになる。
本図のディレクトリ構造においてROOTディレクトリの配下には、「organization＃1」というサブディレクトリがあり、その配下に、「disc＃1」というサブディレクトリがある。ディレクトリ「organization＃1」とは、映画作品の特定のプロバイダに割り当てられたディレクトリである。「disc＃1」は、そのプロバイダが提供したBD-ROMのそれぞれに割り当てられたディレクトリである。
特定のプロバイダに対応するディレクトリに、各BD-ROMに対応するディレクトリを設けることにより、各BD-ROMについてのダウンロードデータが個別に格納される。このサブディレクトリの配下に、BD-ROMに格納されていたのと同様、PlayList情報(00002.mpls)、Clip情報(00003.clpi,00004.clpi)、AVClip(00003.m2ts,00004.m2ts)が格納されている。
続いて、ローカルストレージ２００の構成要素となる、PlayList情報、Clip情報、AVClipについての説明する。
＜ローカルストレージ２００の構成その１.AVClip＞
ローカルストレージ２００上のAVClip(00003.m2ts,00004.m2ts)は、SubClipを構成する。このSubClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。SubClipを多重分離することで得られるパーシャルトランスポートストリームを“セカンダリTS”という。かかるセカンダリTSは、Out＿of＿MUXアプリケーションを構成するものである。以降、Out＿of＿MUXアプリケーションについて説明する。

（Out-of-MUXアプリケーション）
Out-of-MUXアプリケーションとは、例えば、BD-ROM上のプライマリTSと、ネットワークなどを介して取得して、ローカルストレージに記録されたセカンダリTSの２つのTSを同時に再生選択することで、この２本のTS間で様々なエレメンタリストリームの組み合わせを可能とするアプリケーションである。
図１５は、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ装置、ローカルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPIDFilterを示す。そして本図におけるプライマリTS(Video1,Audio1(English),Audio2(Spanish),PG1(EnglishSubtitle),IG1(English Menu))、セカンダリTS(Audio2(Japanese),Audio3(Korean),PG2(JapaneseSubtitle),PG3(Korean Subtitle),IG2(Japanese Menu),IG3(Korean Menu))は、それぞれBD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio1）とスペイン語（Audio 2）しか記録されていないため、日本語吹き替えなどをこのディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供する日本語吹き替え（Audio2）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、日本語吹き替え音声（Audio 2）と、日本語字幕（PG 2）と、日本語メニュー画面（IG2）とを、デコーダに送り込むことができる。こうすることでユーザーは、日本語吹き替え音声（Audio 2）と、日本語字幕（PG 2）とを、日本語メニュー画面（IG2）から選択して、映像(Video1)と共に再生することができる。
Out-of-MUXアプリケーションは、同時に再生される２つのTSの中に格納されたエレメンタリストリームの種別ごとに１つまで（言い換えれば、プライマリTSとセカンダリTSに格納されているビデオ１本、オーディオ１本、字幕１本、メニュー１本まで）という制限下で、ユーザーが自由に、音声及び字幕を選択することができる。
全てのBD-ROM再生装置はプライマリTS単体をデコードできる能力は持つが、２つのTSを同時にデコードする能力はない。したがって、Out-of-MUXアプリケーションを制限なく導入した場合には、ハードウェアの大規模化や、ソフトウェアを多く追加せざるを得なくなり、BD-ROM再生装置のコストアップに繋がる。そのため、Out-of-MUXアプリケーションの実現にあたっては、プライマリTSだけをデコードできるリソース上で、Out＿of＿MUXのアプリケーションを実現することができるかどうかどうかが鍵となる。
エレメンタリストリームの種別ごとに１つまで、再生を許可するという制限は、プライマリTSのエレメンタリストリームをセカンダリTSのエレメンタリストリームで「入れ換える」と考えればよい。そのようにすることで、１本のTSをデコードするリソース上で、Out＿of＿MUXアプリケーションを実現することができ、デコーダ側のコストアップを抑制することができる。本図の例では、プライマリTSのオーディオ、字幕（PG）、メニュー（IG）ストリームをセカンダリTSのそれらと入れ換えている。
セカンダリTSは、上述したようなローカルストレージである内蔵HDDの他、フラッシュメモリや一次記憶メモリ、ネットワーク越しのHDDや直接ネットワークを介したストリーミングなどから入力されることもある。説明の便宜上、セカンダリTSは、図１に示したような内蔵型のHDDから供給されるものとする。

＜ローカルストレージ２００の構成その２.Clip情報＞
ローカルストレージ上に存在するClip情報(00003.clpi,00004.clpi)は、基本的には、BD-ROMに記録されているものと同じデータ構造をもつ。ここでローカルストレージ上のClip情報のTS＿Recording＿Rateは、BD-ROMからのAVClip読み出しと同じビットレートに設定されている。つまりSubClipのClip情報に記述されたTS＿Recording＿Rateと、MainClipのClip情報に記述されたTS＿Recording ＿Rateとは同一である。仮に、MainClipのTS＿Recording ＿Rateの値と、SubClipのTS＿Recording＿Rateとが異なると、夫々のSource De-packetizerから、バッファに送り込むまでのデータレートがどちらのTSを送り込むかによって異なることになり、Out-of-MUXアプリケーションは１つの入力TSと仮定できるという仮定が成り立たなくなる。
また、２つのTS間で再生されるべきエレメンタリストリームは、自在に選択されるので、プライマリTSのオーディオが選択されればSourceDe-packetizerからデコーダ内のバッファまでが、プライマリTS用のビットレートに設定され、セカンダリTSのオーディオが選択されるとSource De-packetizerからデコーダ内のバッファまでが、セカンダリTSのためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑になってしまうからである。

＜ローカルストレージ２００の構成その２.PlayList情報＞
続いて、ローカルストレージ２００上のPlayList情報について説明する。拡張子“mpls”が付与されたファイル(00002.mpls)は、MainPath、Subpathと呼ばれる2種類の再生経路を束ねたものをPlaylist(PL)として定義する情報である。図１６は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())と、Subpathを定義するSubpath情報(Subpath())とからなる。かかるPlayList情報の内部構成、及び、PlayItem情報の内部構成は、BD-ROMのものと同じであり、説明を省略する。以降、Subpath情報について説明する。

＜PlayList情報の説明その１.Subpath情報＞
MainPathが、主映像たるMainClipに定義される再生経路であるのに対し、Subpathは、MainPathと同期すべきSubClipに対して定義される再生経路である。
図１７は、Subpath情報の内部構成をクローズアップして示す図である。本図における矢印hc0に示すようにSubpath情報は、SubClipの類型を示すSubPath＿typeと、1つ以上のSubPlayItem情報(・・・SubPlayItem()・・・)とを含む。
図中の引き出し線hc1は、SubPlayItem情報の構成をクローズアップしている。SubPlayItem情報は、図中の矢印hc1に示すように『Clip＿information＿file＿name』、『Clip＿codec＿identifier』、『SP＿connection＿condition』、『ref＿to＿STC＿id[0]』、『SubPlayItem＿In＿time』、『SubPlayItem＿Out＿time』、『sync＿PlayItem＿id』、『sync＿start＿PTS＿of＿PlayItem』からなる。
『Clip＿information＿file＿name』は、Clip情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip＿codec＿identifier』は、AVClipの符号化方式を示す。
『SP＿connection＿condition』は、このSubPlayItem(カレントSubPlayItem)と、その1つ前のSubPlayItem(previousSubPlayItem)との接続状態を示す。
『ref＿to＿STC＿id[0]』は、このPlayItemが対象としているSTC＿Sequenceを一意に示す。
『SubPlayItem＿In＿time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。
『SubPlayItem＿Out＿time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
『sync＿PlayItem＿id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem＿In＿timeは、このsync＿PlayItem＿idで指定されたPlayItemの再生時間軸上に存在する。
『sync＿start＿PTS＿of＿PlayItem』は、sync＿PlayItem＿idで指定されたPlay Itemの再生時間軸上において、SubPlayItem＿In＿timeで指定されたSubPlayItemの始点が、どこに存在するかを示す。
＜SubPath情報についての詳細その２.三者の関係＞
ここでの三者とは、ローカルストレージ２００上のSubClip、ローカルストレージ２００上のPlayList情報、BD-ROM上のMainClipの三者をいう。
図１８は、ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。本図において第1段目は、ローカルストレージ２００上に存在するSubClipを示す。この第1段目に示すように、ローカルストレージ２００上のSubClip内のセカンダリTSには、オーディオストリーム、PGストリーム、IGストリームといった種別がある。これらのうち何れかが、SubPathとして同期再生に供されることになる。
第2段目は、PlayList情報により定義される2つの時間軸を示す。第2段目のうち下側の時間軸は、PlayItem情報により定義されるPlayList時間軸を示し、上側の時間軸はSubPlayItemにより定義されるSubPlayItem時間軸を示す。
本図に示すように、SubPlayItem情報のSubPlayItem＿Clip＿information＿file＿nameは、SubClipを格納した.m2tsファイルのうち、どれを再生区間の対象として選ぶかという、SubClip選択の役割を果たしていることがわかる。
そしてSubPlayItem.IN＿time、SubPlayItem.Out＿timeは、SubClip上の、再生区間の始点及び終点を定義するという役割を果たしていることがわかる。
矢印Sync＿PlayItem＿Idは、どのPlayItemとの同期を意図しているかという同期指定の役割を果たし、sync＿start＿PTS＿of＿PlayItemは、PlayList時間軸上におけるSubPlayItem＿In＿timeの位置を決める役割を果たす。
以上が、SubPath情報についての説明である。
＜STN＿table＞
このローカルストレージ２００上のPlayList情報において特徴的であるのは、STN＿Tableである。以降、ローカルストレージ２００上のPlayList情報について説明する。
STN＿tableは、PlayItem情報のClip＿Information＿file＿nameで指定されているMainClipに多重化された複数エレメンタリストリーム、及び、SubPlayItem情報のClip＿Information＿file＿nameで指定されたSubClipに多重化されている複数エレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示すテーブルである。PlayList情報におけるSTN＿Tableにおいて、同時に再生することが許可されている複数エレメンタリストリームは、いわゆる“システムストリーム”を構成することになる。
具体的にいうとSTN＿tableは、MainClipに多重化されている複数エレメンタリストリーム、SubClipに多重化されているエレメンタリストリームのそれぞれについてのStream＿entryを、Stream＿attributeと対応付けることで構成される。
図１９（ａ）は、STN＿tableの内部構成を示す図である。本図に示すようにSTN＿tableは、STN＿tableにおけるentryと、attributeとの組み(entry-attribute)を複数含み、これらentry−attributeの組みの個数(number＿of＿video＿stream＿entries,number＿of＿audio＿stream＿entries,number＿of＿PG＿stream＿entries,number＿of＿IG＿stream＿entries)を示すデータ構造になっている。
entry-attributeの組みは、図中の括弧記号”｛”に示すように、Play Itemにおいて再生可能なビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのそれぞれに対応している。

entry−attributeの詳細について説明する。
図１９（ｂ）は、ビデオストリームに対応したStream＿attributeを示す図である。
ビデオストリームにおけるStream＿attributeは、ビデオストリームの表示方式を示す『Video＿format』と、ビデオストリームの表示周波数を示す『frame＿rate』等を含む。
図１９（ｃ）は、オーディオストリームに対応したStream＿attributeを示す図である。
オーディオストリームにおけるStream＿attributeは、オーディオストリームの符号化方式を示す『stream＿coding＿type』と、対応するオーディオストリームのチャネル構成を示す『audio＿presentation＿type』と、対応するオーディオストリームのサンプリング周波数を示す対応する『Sampling＿frequency』と、オーディオストリームの言語属性を示す『audio＿languagecode』からなる。
図１９（ｄ）は、ビデオストリームにおけるStream＿entryを示す図である。本図に示すように、ビデオストリームのStream＿entryは、ビデオストリームの多重分離に用いられるPIDを示す「ref＿to＿Stream＿PID＿of＿Main＿Clip」を含む。
MainClipにて多重化されているオーディオストリーム、IGストリーム、PGストリームのStream＿attributeは、この図１９（ｄ）の形式になっている。
＜再生が許可されているエレメンタリストリームのデータ量制限＞
STN＿tableは、BD-ROMから読み出されるエレメンタリストリーム、ローカルストレージから読み出されるエレメンタリストリームのうち、再生が許可されているものを示すが、かかるSTN＿tableが、無制限に、エレメンタリストリームの再生を許可しているとなると、デコーダシステムの破綻を招く恐れがある。
その理由は、以下の通りである。MPEG2のデコーダシステム標準によると、1つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせるための基本原則である。一方、BD-ROMにおけるストリームの再生が許可されると共に、ローカルストレージにおけるストリームの再生が許可されており、BD-ROMからのAVClip再生と、ローカルストレージからのAVClip再生とを同時に実行する場合、BD-ROMからのTSパケットと、ローカルストレージからのTSパケットとにオーバーラップが生じてしまう。
そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課している。
デコードエレメンタリストリームとは、STN＿tableにおいて再生が許可されていて、一緒に再生するため、選択されたビデオストリーム、オーディオストリーム、PGストリーム、IGストリームである。デコードエレメンタリストリームには、ローカルストレージからの読み出されるものと、BD-ROMから読み出されるものの両者がある。
デコードエレメンタリストリームに課される制限とは、STN＿tableにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないAVClip(MainClip,SubClip)を構成するTSパケット(DecodingTSパケット)の、1秒当たりのビット量は48Mbit以下になるというものである。
この1秒という単位時間は、“Window”と呼ばれ、ATC Sequenceの時間軸上の任意の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのような1秒の期間においても、この48Mbit以下という条件を満たす必要がある。
図２０は、BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。本図の第1段目は、BD-ROMから読み出された複数のTSパケット、第3段目は、ローカルストレージから読み出された複数のTSパケットを示す。これら第1段目、第3段目のTSパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構成するTSパケット(DecodingTSパケット)である。本図における第2段目は、第1段目に示したDecoding TSパケット、第3段目に示したDecoding TSパケットのうち、1秒という期間に属すものを示す。上述したように、MPEG2のデコーダシステム標準によると、1つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。しかし、本図によると、ATC時間軸において、TSパケット間のオーバーラップrp1,rp2,rp3が発生していることがわかる。このように、Windowという単位時間において、TSパケット動作のオーバーラップが許容されているのである。しかし、MPEG2のデコーダシステム標準にはない別の要件が課されている。それが上述した、1Window当たり48Mbit以下という制限である。第4段目は、この第2段目に示す、DecodingTSパケットが満たすべき条件を数式で表している。この数式の意味は、上述したDecoding TSパケットの個数を、ビット数に換算した値(TSパケットのバイト数である188をかけ、ビット数8で表した値)が、48Mbit以下になるというものである。
任意の1秒という期間において、Decoding TSパケットに以上のような条件を課すのが、本実施形態におけるビット量の制限である。Out＿of＿MUXアプリケーションのためのオーサリング時には、Sourceパケット列において、かかるWindowを、1パケットずつシフトさせつつ、1秒という期間内の、DecodingTSパケットのビット数が、48Mbit以下という制限を満たすかどうかをチェックする。もし、制限を満たせば、次のTSパケットにWindowをシフトさせ、制限を満たさねば、BD-ROM規格に違反していると断定する。そして、かかるシフトを繰り返した結果、WindowのOut＿Timeが、最後のSourceパケットに達すれば、当該Sourceパケットは、BD-ROM規格に整合しているとの判定を下す。
＜Windowのシフト＞
TSパケットのそれぞれには、27MHzの時間精度をもつATSが付与されている。ATC時間軸上の座標は、1/27,000,000秒という時間精度をもつが、このATC時間軸上の各座標に、ATSが存在するとは限らない。ATC時間軸には、ATSがまったく存在しない期間や、ATSが存在する期間が不規則に現れる。ATSの出現にバラツキがあるので、Windowをシフトするにあたって、In＿Timeから1秒後にATSが存在しない場合、WindowのOut＿Timeをどのように調整するかが問題になる。
WindowのOut＿Timeは、原則としてIn＿Timeの1秒として設定される。ここでATC時間軸において、In＿Timeの1秒後にあたる座標にATSが存在すれば、In＿Time＋1秒の座標を、Out＿Timeとする。もしIn＿Timeの1秒後にあたる座標にATSが存在しなければ、In＿Time＋1秒以降であって、ATSが初めて現れるATC時間軸の座標を、Out＿Timeとする。ATSの空白期間を考慮しながらOut＿Timeを調整しつつ、Windowをシフトしてゆくので、Windowがシフトする度に、異なるビット値が算出される。In＿Timeを1TSパケットずつシフトしてゆき、これに伴いOut＿Timeを調整することで、ATC時間軸におけるビット値の遷移を緻密に計算してゆくことができる。
図２１は、Windowのシフトを示す図である。（ａ）〜（ｄ）のそれぞれのうち、上段はベリファイの対象となるSourceパケット列を示し、下段は、WindowのIn＿Time、Out＿Timeを示す。同図（ａ）では、WindowのIn＿Timeは、Sourceパケット＃iを指定している。このWindowのIn＿Timeから1秒後に存在するTSパケット＃jが、WindowのOut＿Timeに設定される。
同図（ｂ）では、WindowのIn＿Timeは、Sourceパケット＃i+1を指定している。一方、このWindowのIn＿Timeから1秒後において、Sourceパケット＃j+1にあたる座標には、SourceパケットのATSが存在しない。この（ｂ）におけるWindowのOut＿Timeは、TSパケット＃jを越えたものになるが、TSパケット＃jの直後に、Sourceパケットが存在しないため、（ｂ）のWindowにおけるビットレートは、（ａ）のWindowにおけるビットレートより少なくなってしまう。これでは、（ｂ）のWindowは、チェックに値しなくなる。そこで、Out＿Timeの調整により、WindowのIn＿Timeから1秒以降に初めて現れるTSパケット＃j+2を、WindowのOut＿Timeにする。Out＿Timeをこのように設定すれば、（ｂ）のWindowは、チェックに値するものとなる。
同図（ｃ）では、WindowのIn＿Timeは、Sourceパケット＃i+2を指定している。一方、このWindowのIn＿Timeから1秒後には、Sourceパケット＃j+2が位置している。この（ｃ）のWindowは、TSパケットの数が、（ｂ）のWindowにおける数と変わらず、チェックに値しない。故に、この（ｃ）では、チェックが行われず、更にWindowのIn＿Timeを進める。
同図（ｄ）では、WindowのIn＿Timeは、Sourceパケット＃i+3を指定している。一方、このWindow＿In＿Timeから1秒後において、Sourceパケット＃j+3にあたる位置には、Sourceパケットが存在しない。そこで上述したようなOut＿Timeの調整を行い、WindowのIn＿Timeから1秒以降に初めて現れるTSパケット＃j+4を、WindowのOut＿Timeとする。こうすることで、Window内のTSパケット数は、（ｂ）と違うものとなり、チェックに値する。
以上のようなWindowシフトを伴う、ビット量チェックをオーサリング時に実行することで、ローカルストレージ及びBD-ROMからTSパケットが読み出され、デコーダに供給されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。
以上のWindowシフトによる保障を、図２２〜図２６の具体例を参照しながら説明する。
図２２の第1段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。横軸は時間軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、BD-ROM及びローカルストレージからの読み出し時のビット量は、破線の曲線のように推移する。
図２２の第2段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのうち、デコーダに供給されるものの合計のデータ量を示す。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量は、STN＿tableで許可されたストリームに属するTSパケットの合計量となる。ワーストケースにおいては、合計の転送量が96Mbit近くになり、このデータ量のTSパケットが供給されると考えられる。グラフの時間軸を、７つのWindowに分割して、個々のWindowにおける供給量と、Window毎の転送許容量とを対比する。
図２２の第3段目は、この図２２の第2段目におけるグラフを1秒という期間で区切ったものであり、図２３（ａ）（ｂ）は、各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。Windowにおける転送許容量は、1秒当たり48Mbitであり、0.5秒に換算すれば96Mbitとなる。図中のパターンpn1のハッチングは、デコーダへのデータ供給量を示す。図中のパターンpn2のハッチングは、Window毎の転送許容量を示す。パターンpn1のハッチングが付された部分の面積が、何れのWindowにおいても、パターンpn2のハッチングが付された部分の面積以下になっている。これは、BD-ROM及びローカルストレージからのデータ供給量が、どのWindowにおいても、Windowにおける転送許容量以下に抑えられていることを意味する。
ATC時間軸上のどの時点においても、1秒当たりのデコーダへの転送許容量は、48Mbit以下になるので、たとえ局所的に、デコーダへの転送許容量が96Mbit近くになったとしても、48Mbit＝96Mbit×0.5秒の計算により、かかる96Mbitでの転送が0.5秒継続することはありえない。従ってデコーダが、このピークが到来する前に、BD-ROM、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダーフロー又はオーバーフローが生じることはない。
Windowにおける転送許容量、つまり、1秒当たり48Mbitという数値は、MPEGに準拠したデコーダが、バッファに先読みできる数値を、目安にして定めたものである。バッファに先読みできるデータ量が、もっと大きい場合は、1秒当たりのデータ量を更に大きくしたり、またWindowの時間長を更に長くすることができる。このことから、本発明にかかる数値範囲は、1秒当たり48Mbitというものに、限定されるべきでない。
以上が、STN＿tableにおいて再生が許可されているセカンダリTSにおけるデータ量制限についての説明である。

＜connection＿condition情報、sp＿connection＿condition情報の設定＞
次に、Out＿of＿MUXアプリケーションを実現する場合の、PlayItemにおけるconnection＿condition情報、及び、SubPlayItemにおけるsp＿connection＿condition情報の設定について説明する。connection＿condition情報のフィールドの値、sp＿connection＿condition情報のフィールドの値は“1”,“5”,“6”の値を取る事ができ、それぞれ以下のような意味を持つ。
connection＿condition=1(CC=1)： このPlayItem(カレントPlayItem)と直前のPlayItem(previousPlayItem)とはシームレス接続される保証がない。つまり、フリーズして再生が途切れることが許容された接続形態（ノンシームレス接続）である。
connection＿condition=5(CC=5)： カレントPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームと、previousPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームとがシームレス接続される保証がある。一方、MainClipに多重化されているオーディオストリームについてはこの限りではない。
connection＿condition=6(CC=6)： カレントPlayItemとpreviousPlayItemに属するそれぞれのTSストリームは論理的に連続であり（時間軸が連続しており、符号化方式も連続している）、オーディオストリーム、ビデオストリームともにシームレス接続される保証がある。

SubPlayItem＃n内に記述されたsp＿connection＿condition情報は、次のように定義ができる。
sp＿connection＿condition情報(SP＿CC=1)： このSubPlayItem(カレントSubPlayItem)と直前のSubPlayItem(previousSubPlayItem)とはシームレス接続される保証がない
sp＿connection＿condition情報(SP＿CC=5)：カレントSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームと、previousSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームとがシームレス接続される保証がある。一方、SubClipに多重化されているオーディオストリームについてはこの限りではない。
sp＿connection＿condition情報(SP＿CC=6)： カレントSubPlayItemと、previousSubPlayItemとに属するそれぞれのTSストリームは論理的に連続しており（時間軸が連続しており、符号化方式も連続している）、シームレス接続される保証がある。
Out＿of＿MUXアプリケーションを実現するPlayItemに対して設定されるべきSubPlayItemは、SubPlayItem内のビデオストリームやオーディオストリーム、またはPGストリームやIGストリームがPlayItem内にあったとしても不整合を起こさないようにすべきである。そのため、全く同一の接続条件となる。つまりPlayItem＃１、PlayItem＃２がCC=１で接続されるならば、それに対応するSubPlayItem＃１、SubPlayItem＃２もCC=１で接続される。同様に、PlayItem＃１、PlayItem＃２がCC=５で接続されるならば、それに対応するSubPlayItem＃１、SubPlayItem＃２もCC=５の条件を満たしながら接続される。

以下、図２４、図２５、図２６を参照しながら、Out＿of＿MUXアプリケーションを構成するPlayItem、SubPlayItemのIn＿Time、Out＿Timeの関係と、connection＿condition情報の詳細について説明する。
＜In＿Time、Out＿Timeの関係＞
図２４は、Out＿of＿MUXを構成するPlayItem、SubPlayItemの接続状態を示す図である。本図における第1段目は、SubClip時間軸であり、第2段目、第3段目は、SubPlayItem時間軸、PlayList時間軸である。第4段目は、MainClip時間軸である。本図において、PlayItem側のconnection＿condition情報が“＝5”である場合、SubPlayItem側のconnection＿condition情報も、SP＿CC＝5になる。
図２５は、図２４に示した、PlayItemのconnection＿condition情報、SubPlayItemのsp＿connection＿condition情報が“＝5”に設定されている場合の、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとの関係を示す図である。第1段目、第4段目は図２４と同じである。図２４に示した2つのPlayItem(PlayItem情報＃1、PlayItem情報＃2)のうち、PlayItem情報＃1のIn＿Timeは、時刻t1を表し、Out＿Timeは、時刻t2を表す。PlayItem情報＃2のIn＿Timeは時刻t3、PlayItem情報＃2のOut＿Timeは、時刻t4を表す。
PlayItem側の接続状態がCC＝5に設定されていると、SubPlayItemにおけるSync＿Start＿Pts＿of＿PlayItemは、PlayItemのIn＿Timeと同じ時点を示す。そしてSubPlayItemにおけるIn＿Time、Out＿Timeは、PlayItemのIn＿Time、Out＿Timeと同じ時刻を表す。このように、PlayItemのconnection＿condition情報が“＝5”である場合、SubPlayItemのsp＿connection＿condition情報も“＝5”に設定され、尚且つ、PlayItemのIn＿Time、Out＿Timeは、SubPlayItemのIn＿Time、Out＿Timeと同一時点を表す。
PlayItemのIn＿Time、Out＿Time、SubPlayItemのIn＿Time、Out＿Timeは、それぞれVideo PresentationUnit、Audio Presentation UnitのPTSを参照している。PlayItemのIn＿Time、Out＿Timeと、SubPlayItemのIn＿Time、Out＿Timeとが一致しているということは、PlayItemのIn＿Time、Out＿Timeで参照されるVideoPresentation Unit、Audio Presentation UnitのPTS値が、SubPlayItemのIn＿Time、Out＿Timeで参照されるVideoPresentation Unit、Audio Presentation UnitのPTS値と同じであることを意味する。そうすると、プライマリTS、セカンダリTSは、時間長が同じで、オーサリング時においてVideoPresentation Unit、Audio Presentation UnitのPTSが、同じになるよう、エンコードされる必要がある。このようにプライマリTS、セカンダリTSを作成しておくことも、CC＝5、SP＿CC=5を実現するにあたっての条件になる。
＜同期再生するにあたって、参照すべきSTC値＞
図２６は、PlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値を示す。第2段目、第3段目は、前図に示したものと同じである。第1段目は、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第4段目も、PlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第1段目における横軸は時間軸であり、縦軸は時間軸上の各時点におけるSTC値を表す。第1段目におけるSTC値は、SubPlayItem情報＃1のIn＿TimeからOut＿Timeまでの期間における単調増加zk1と、SubPlayItem情報＃2のIn＿TimeからOut＿Timeまでの期間における単調増加zk2とからなる。第4段目におけるSTC値は、PlayItem情報＃1のIn＿TimeからOut＿Timeまでの期間における単調増加zk3と、PlayItem情報＃2のIn＿TimeからOut＿Timeまでの期間における単調増加zk4とからなる。
PlayItemのIn＿Timeは、SubPlayItemのIn＿Timeと同じ時点を表すので、上述したグラフにおいて、STCの初期値は同じであり、途中の時点においても同じなる。つまり、PlayItemのIn＿TimeからOut＿Timeまでに存在する任意の時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC2(i)は、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する同じ時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC1(i)と同じになる。STC値が同じであると、装置内のSTCカウンタは、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置における制御が簡略化される。
仮に、上述した図２５、図２６の制限に反し、１つのPlayItemに対して2つ以上のSubPlayItemを準備した場合、そのSubPlayItemの境界において、映像や音声が途切れてしまい、PlayItemの途中で再生が一時停止するなどの不便が生じる。また、Out-of-MUXアプリケーションにおいて、プライマリTSをセカンダリTSに入れ換えるという処理を実現する場合、この入れ替えの前後で、STC時間軸を切り替える必要があるので、再生装置における同期制御が複雑化する。一方、PlayItem、もしくはSubPlayItemのIn＿Time、Out＿Timeを共に、一連続なSTC時間軸に定義した場合、上述したような途切れやトランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、１つのPlayItemに対して同一の開始点、同一の終了点をSubPlayItemにもたせるのである。
＜In＿Time、Out＿Timeの誤差＞
ここでPlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとの一致は、完全に一致していることを要求するのではなく、多少の誤差を許容する趣旨である。このIn＿Time、Out＿Time間の誤差について説明する。
PlayItemのIn＿Time、Out＿TimeとなるSTC時刻は、PlayItemがビデオフレームに対して設定される。これに対し、SubPlayItemではオーディオフレームに対して設定されることとなる。何故なら、SubPlayItemは、コメンタリが主用途でビデオストリームが多重化されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションユニットの再生時間長の違いから、開始/終了時刻が合わない。したがって、最低でも、1フレーム未満の誤差を認める必要がある。PlayItem＃nとSubPlayItem＃nの開始/終了時刻に関して、どちらも同一のSTC時間軸に対して、

| (PlayItem＃n.Out-PlayItem＃n.In) - (SubPlayItem＃n.Out＿time-SubPlayItem＃n.In＿time)| ≦ PlayItem＃nの中で最小の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間 ≦ 1/60秒

としても規定する。上記左辺の値は、PlayItem＃nの中で最大の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間（≦1/25秒）としても良いし、１秒以下などとしても良い。

以上が、PlayItem、SubPlayItemにおけるIn＿Time、Out＿Timeの関係についての説明である。
次に、connection＿condition情報、sp＿connection＿condition情報について詳しく説明する。CC＝5、SP＿CC=5の条件を満たすには、AVストリームのレベル、トランスポートストリームのレベル、VideoPresentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要がある。

＜AVストリームのレベル＞
Current PlayItemのconnection＿condition情報、及び、sp＿connection＿condition情報が“5”に設定されていることは、PreviousPlayItemで再生されるAVストリームの終了点と、Current PlayItemで再生されるAVストリームの開始点との間に、“Clean Break”が存在することを意味する。
Clean Breakを実現するには、Previous PlayItemで再生されるAVClipと、Current PlayItemで再生されるAVストリームとが、以下の要件を満たさねばならない。

(1)Previous PlayItemで指定されているMainClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccessUnitが、Previous PlayItemのOut＿Time以降から排除されていること。
同様に、Previous SubPlayItemで指定されているSubClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccessUnitが、Previous SubPlayItemのOut＿Time以降から排除されていること。

(2)Current PlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、CurrentPlayItemのIn＿Timeの前から取り除かれていること。そして、MainClipの最初のAudio Presentation Unitが、STC時間軸のIn＿Timeで再生されるSampleを含んでいること。
同様に、Current SubPlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、CurrentSubPlayItemのIn＿Timeの前から取り除かれていること。そして、SubClipの最初のAudio Presentation Unitが、STC時間軸のIn＿Timeで再生されるSampleを含んでいること。

(3)Previous PlayItemにて指定されるMainClipを構成する全てのSourceパケットが、Current PlayItemにて指定されるMainClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
同様に、Previous SubPlayItemにて指定されるSubClipの全データが、Current SubPlayItemにて指定されるSubClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
以上が、AVストリームにおいて満たすべき条件についての説明である。続いて、トランスポートストリームのレベルにおいて満たすべき条件について説明する。

＜トランスポートストリームのレベル＞
ここでCC＝5においてシームレス接続の対象となる2つのプライマリTSを、プライマリTS1、プライマリTS2と呼ぶ。SP＿CC=5においてシームレス接続の対象となる2つのプライマリTSを、セカンダリTS１、セカンダリTS２と呼ぶ。
図２７は、previousPlayItem、previousSubPlayItemにて参照されているAVClip、カレントPlayItem、カレントSubPlayItemにて参照されているAVClipにおいて、TS1、TS2がどのように特定されるかを示す図である。本図における第4段目は、プライマリTS1、プライマリTS2を示し、第3段目は、previousPlayItem側のMainClip1、カレントPlayItem側のMainClip2を示す。第1段目は、セカンダリTS１、セカンダリTS２を示し、第2段目は、previousSubPlayItem側のSubClip1、カレントSubPlayItem側のSubClip2を示す。
プライマリTS１は、MainClip1において、ハッチングが付されたデータから構成される。MainClip1におけるハッチングが付されたデータは、PreviousPlayItemにおけるIn＿Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In＿Timeが参照しているVideoPresentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、MainClip1の最後のパケットで終わる。
プライマリTS２は、MainClip2においてハッチングが付されたデータから構成される。MainClip2においてハッチングが付されたデータは、MainClip2の最初のSourceパケットから始まる。そしてMainClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、CurrentPlayItemのOut＿Timeで参照されるVideo Presentation Unit,Audio Presentation Unitの末尾に位置するSourceパケットである。
セカンダリTS１は、SubClip1において、ハッチングが付されたデータから構成される。SubClip1におけるハッチングが付されたデータは、previousSubPlayItemにおけるIn＿Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In＿Timeが参照しているVideoPresentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、SubClip1の最後のパケットで終わる。
セカンダリTS２は、SubClip2においてハッチングが付されたデータから構成される。SubClip2においてハッチングが付されたデータは、SubClip2の最初のSourceパケットから始まる。そしてSubClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、カレントSubPlayItemのOut＿Timeで参照されるVideoPresentation Unit,Audio Presentation Unitの末尾に位置するSourceパケットである。
以上の説明から、CC＝5、SP＿CC=5において、接続すべき2つのトランスポートストリームが、MainClip、SubClip内に、どのように配置されるかがわかる。previousPlayItem側のMainClipは、previousPlayItemのOut＿Timeで参照されるVideoPresentation Unit、Audio Presentation Unitで終わっていなければならず、カレントPlayItem側のMainClipも、カレントPlayItemのIn＿Timeで参照されるVideoPresentation Unit、Audio Presentation Unitで始まらなければならない。この関係は、previousSubPlayItemの同様であり、previousSubPlayItem側のSubClipは、previousSubPlayItemのOut＿Timeで参照されるAudioPresentation Unitで終わっていなければならず、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのIn＿Timeで参照されるAudioPresentation Unitで始まらなければならない。これは上述したように、previousSubPlayItemのOut＿Timeから参照されるVideoPresentation Unit、Audio Presentation Unit以降に、余分なAudio Presentation Unitは存在してはならないからである。一方、previousSubPlayItem側のSubClipは、previousSubPlayItemのIn＿Timeで参照されるAudioPresentation Unitで始まる必要はなく、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのOut＿Timeで参照されるAudioPresentation Unitで終わる必要はない。
以上の図２４、図２７から、プライマリTS、セカンダリTSは、同じ時間長に構成され、Video Presentation Unit、AudioPresentation UnitのPTS値が同一値になるように作成されねばならない。更にpreviousPlayItem側のMainClip、previousPlayItem側のSubClipは、Out＿TimeにあたるVideoPresentation Unit、Audio Presentation Unitで終わるよう、多重化されねばならず、カレントPlayItem側のMainClip、カレントPlayItem側のSubClipは、In＿TimeにあたるVideoPresentation Unit、Audio Presentation Unitで開始するよう、多重化されねばならない。
そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
・TS1とTS2におけるプログラム数が1つであること
・ビデオストリームの数が1つであること
・オーディオストリーム数が同じであること
・Previous PlayItemにおけるSTN＿tableと、Current PlayItemにおけるSTN＿tableとは同じ内容になること
・個々のPlayItemにおけるトランスポートストリームの再生期間は3秒
以上が、CC＝5、SP＿CC=5で2つのストリームを接続するにあたってトランスポートストリームのレベルで満たすべき条件である。続いて、VideoPresentation Unit、Audio Presentation Unitのレベルで満たすべき条件について説明する。

＜Video Presentation Unit、Audio Presentation Unitのレベル＞
CC＝5とは、本来、別々である筈のプライマリTS1たるビデオストリームの最後のVideo Presentation Unitの開始時刻と、プライマリTS2たるビデオストリームの最初のVideoPresentation Unitの終了時刻とを一致させることをいう。Video Presentation Unitの終了時刻・開始時刻を一致させようとすると、かかるVideoPresentation Unitと同期再生すべきAudio Presentation Unitの扱いが問題になる。何故なら、ビデオと、オーディオとではサンプリング周波数が異なり、VideoPresentation Unit、Audio Presentation Unitの時間長は一致しないからである。
図２８は、CC＝5、及び、SP＿CC＝5の詳細を示す図である。第1段目〜第3段目は、SubPlayItemにおけるconnection＿conditionを示し、第4段目〜第7段目は、PlayItemにおけるsp＿connection＿conditionを示す。第4段目は、TS1、TS2における複数のVideoPresentation Unitを示し、第5段目は、TS1におけるAudio Presentation Unit、TS2におけるAudioPresentation Unitを示す。第6段目は、MainClipにおけるSTCの値を示す。第7段目は、MainClipにおけSourceパケット列を示す。
本図において、ハッチングが付されているのは、TS1側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットであり、ハッチングが付されていないのは、TS2側のVideoPresentation Unit、Audio Presentation Unit、Sourceパケットである。
本図においてCC＝5とは、Video Presentation Unit境界を一致させるものの(第4段目)、MainClipのATCにおいてギャップがあり(第7段目)、MainClipのAudioPresentation Unitでオーバラップが存在する(第5段目)状態をいう。SP＿CC=5とは、SubClipのATCにおいてギャップがあり(第1段目)、SubClipのAudioPresentation Unitでオーバラップが存在する(第2段目)状態をいう。
上述したVideo Presentation Unitの境界とは、TS1側から見ればと、第4段目における最後のVideo Presentation Unitの終了点PTS1(1stEnd)+Tppにあたり、TS2側から見れば、第4段目におけるVideoPresentation Unitの開始点PTS2(2ndSTART)にあたる。
TS1のうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5a、TS2のうち、時点T4に一致するAudioPresentation Unitの開始点をT3aとした場合、MainClipにおけるオーバラップは、Audio Presentation UnitはT3aからT5aにまでとなる。
また本図において、SubClipのAudio Presentation Unitは、MainClipのAudio Presentation Unitより長くなっている。これは、SubClipにおけるオーディオストリームはネットワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、そのためAudioPresentation Unit1つ当たりの時間長が長くなるからである。この第1段目におけるSourceパケット列においても、第7段目同様のギャップが存在し、第2段目におけるAudioPresentation Unitにおいても、第4段目と同様のオーバーラップが存在している。SubClipのTS1におけるAudio PresentationUnitのうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5b、SubClipのTS2におけるAudioPresentation Unitのうち、時点T4に一致するAudio Presentation Unitの開始点をT3bとした場合、オーバラップはT3bからT5bまでとなる。
この図から、CC＝5、SP＿CC=5を実現するには、Video Presentation Unit、Audio Presentation Unit、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。
(1)TS1におけるオーディオストリームの最後のAudio Presentation Unitは、previousPlayItem、previousSubPlayItemにて指定されるTS1における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。
(2)TS2におけるオーディオストリームの、最初のAudio Presentation Unitは、カレントPlayItem、カレントSubPlayItemにて指定されるTS2の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。
(3)接続点のAudio Presentation Unit列において、ギャップが存在しない。これは接続点において、Audio PresentationUnit列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、2つのオーディオフレーム再生期間より短い大きさでなければならない。
(4)TS2の最初のパケットは、PATを含み、1つ以上のPMTがその直後に後続してもよい。PMTがTSパケットのペイロードより大きければ、PMTは、2パケット以上になることもある。PMTを格納したTSパケットには、PCRやSITが存在してもよい。
＜In＿Time、Out＿TimeとVideo Presentation Unitとの関係＞
図２９は、previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudioPresentation Unitと、STC時間軸との関係を示す図である。第1段目は、previousPlayItemが参照しているTS1に帰属する複数のVideoPresentation Unitと、カレントPlayItemが参照しているTS2に帰属する複数のVideo Presentation Unitとを示し、第2段目はpreviousSubPlayItemが参照しているタイムスタンプに帰属している複数のAudioPresentation Unitと、カレントSubPlayItemが参照しているTS2に帰属する複数のAudio Presentation Unitとを示す。第3段目は、previousSubPlayItemのTS1におけるSTC時間軸と、カレントSubPlayItemのTS2におけるSTC時間軸とを示す。第2段目に示すTS1におけるAudioPresentation Unit、TS2におけるAudio Presentation Unitのうち、TS2に属するAudio PresentationUnitの開始点T3bから、TS2に該当するAudio Presentation Unitの終了時刻T5bまでがオーバラップになるのは、図２８に示した通りである。そしてカレントSubPlayItemのIn＿Time、previousSubPlayItemのOut＿Timeは、それぞれ、VideoPresentation Unitの境界である時点T4を指定している。カレントPlayItemのIn＿Time、SubPlayItemのOut＿Timeもまた、VideoPresentation Unitの境界である時点T4を指定しているので、PlayItemのIn＿Time、Out＿Timeは、SubPlayItemのIn＿Time、Out＿Timeと一致していることになる。このようにpreviousSubPlayItemのIn＿Time、カレントSubPlayItemのOut＿Timeは、BD-ROMとは異なる記録媒体に記録されているにも拘らず、MainClipにおけるVideoPresentation Unitの境界と一致しており、更にまた、previousPlayItemのOut＿Time、カレントPlayItemのIn＿Timeと一致していることがわかる。
以上がVideo Presentation Unit、Audio Presentation Unitレベルの条件についての詳細である。

＜エレメンタリストリームのレベル＞
次に、CC＝5、SP＿CC=5実現のための、エレメンタリストリームレベルでの符号化条件について説明する。
個々のエレメンタリストリームのレベルでは、以下の符号化条件を満たす必要がある。
(1)ビデオストリーム
・シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、
・シームレス接続の直前のビデオストリームは、sequence＿end＿code(MPEG-2 Video時)、end＿of＿sequence＿rbsp(MPEG-4AVC時)で完了すること、

(2)オーディオストリーム
・同一のPIDをもつオーディオストリームの符号化方式が変わらないこと、
サンプリング周波数や量子化ビット数、チャンネル数などが変わらないこと、

(3)PGストリーム
a)TS1及びTS2におけるPGストリームの数が同一である。
b)TS1におけるPGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c)TS1における最後のPCSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut＿Timeにあたる再生時刻より早い時点を示す。
d)TS2のPGストリームは、Epoch Start,Epoch ContinueタイプのDisplay Setから始まらねばならない。
e)TS2における最初のPCSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn＿Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f)TS2からのSourceパケットが続く、TS1からのSourceパケットの取り出しは、同じシステム時間軸の、STC1、STC2として定義することができ、これらのDTS値/PTS値には重複が存在しない。

(4)IGストリーム
a)TS1及びTS2におけるIGストリームの数が同一である。
b)TS1におけるIGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c)TS1における最後のICSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut＿Timeにあたる再生時刻より早い時点を示す。
d)TS2のIGストリームは、Epoch Start,Epoch ContinueタイプのDisplay Setから始まらねばならない。
e)TS2における最初のICSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn＿Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f)TS2からのSourceパケットが続く、TS1からのSourceパケットの取り出しは、同じシステム時間軸の、STC1、STC2として定義することができ、これらのDTS値/PTS値には重複が存在しない。

previousPlayItemと、カレントPlayItemとをCC＝5で接続し、previousSubPlayItemと、カレントSubPlayItemとをSP＿CC=5で接続するには、以上のAVストリームのレベル、トランスポートストリームのレベル、VideoPresentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならない。
以上がローカルストレージ２００の構成たるPlayList情報についての説明である。
以上で本発明にかかる記録媒体についての説明を終える。続いて本発明に係る再生装置について説明する。
図３０は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１a、リードバッファ１b,c、ATCカウンタ２a,c,SourceDepacketizer２b,d、ATCカウンタ２c,d、STCカウンタ３a,c、PID Filter３b,d、ビデオデコーダ４、TransportBuffer(TB)４a、Multiplexed Buffer(MB)４b、Coded Picture Buffer(CPB)４c、ビデオデコーダ４d、Re-orderBuffer４e、スィッチ４f、ビデオプレーン５、オーディオデコーダ９、Transport Buffer６、Elementary Buffer７、デコーダ８、スイッチ１０a,b,c,d、InteractiveGraphicsデコーダ１１、Transport Buffer(TB)１１a、Coded Data Buffer(CDB)１１b、StreamGraphics Processor(SGP)１１c、Object Buffer１１d、Composition Buffer１１e、GraphicsController１１f、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、TransportBuffer(TB)１３a、Coded Data Buffer(CDB)１３b、Stream Graphics Processor(SGP)１３c、ObjectBuffer１３d、Composition Buffer１３e、Graphics Controller１３f、Presentation Graphicsプレーン１４、Transport Buffer１５a、Elementary Buffer１５b、デコーダ１５c、Transport Buffer１６a、ElementaryBuffer１６b、デコーダ１６c、合成部１７、メモリ２１、コントローラ２２、PSRセット２３、PID変換部２４、ネットワーク部２５、操作受付部２６、ローカルストレージ２００から構成される。
BD-ROMドライブ１aは、BD-ROMのローディング／イジェクトを行い、BD-ROMディスクに対するアクセスを実行する。
リードバッファ(RB)１bは、BD-ROMから読み出されたSourceパケット列を蓄積する。
リードバッファ(RB)１cは、LastPlayタイトルからから読み出されたSourceパケット列を蓄積する。
ATC Counter２aは、プライマリTSを構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ２bにATCを出力してゆく。
ソースデパケッタイザ(Source De-packetizer)２bは、プライマリTSを構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、各TSパケットのATSに応じてデコーダへの入力時刻を調整する。具体的には、ATCCounter２aが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS＿Recording＿Rateで、そのTSパケットだけをPIDFilter３bに転送する。
ATC Counter２cは、セカンダリTSを構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ２dにATCを出力してゆく。
ソースデパケッタイザ(Source De-packetizer)２dは、セカンダリTSを構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、ATSに応じてデコーダへの入力時刻を調整する。具体的には、ATCCounter２cが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS＿Recording＿Rateで、そのTSパケットだけをPIDFilter３dに転送する。
STC Counter３aは、プライマリTSのPCRによってリセットされ、STCを出力する。
PID Filter３bは、MainClip用の多重分離部であり、ソースデパケッタイザ２bから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ９、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。各デコーダは、PID Filter３bを経由したエレメンタリストリームを受け取って、プライマリTSのPCR（STC１時間軸）に従いデコードから再生の処理を行う。このようにPIDFilter３bを通過して各デコーダに入力されるエレメンタリストリームは、プライマリTSのPCRに従って、デコード及び再生に供されることになる。
STC Counter３cは、セカンダリTSのPCRによってリセットされ、STCを出力する。PIDフィルタ３dは、このSTCを参照して、多重分離を行う。
PID Filter３dは、SubClip用の多重分離部であり、ソースデパケッタイザ２dから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々オーディオデコーダ９、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。このようにPID Filter３dを通過して各デコーダに入力されるエレメンタリストリームは、セカンダリTSのPCRに従って、デコード及び再生に供されることになる。
記録媒体の説明で述べたように、PlayItemにおけるIn＿Time、Out＿Timeは、SubPlayItemにおけるIn＿Time、Out＿Timeと一致しているので、ATCCounter２aとATC Counter２cとが同一の値（時刻）を刻めば、プライマリTSとセカンダリTSの両方の時間軸が揃うことになり、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSを１本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表すATC時間軸と、デコーダ基準時間軸を表すSTC時間軸とを同期させることができる。
ATC時間軸の同期により、上述した2つのSource De-packetizerは、それぞれ、BD-ROMからから読み出されたSourceパケット、ローカルストレージからから読み出されたSourceパケットを処理することができる。
STC時間軸の同期により、STC Counter３a,cは、同一の時刻を計時すれば、２つのTSを１つのTSとして処理することができる。再生装置におけるデコーダは、１つのSTC時間軸で動くため、通常のプライマリTSだけの再生時と変わることなく、STC時間の管理を共通化することができる。ビデオデコーダ４、IGデコーダ１１、PGデコーダ１３、システムデコーダ１５c,１６c、オーディオデコーダ９の全てが同一のSTC時間軸で動かせることは、再生装置開発の観点からすると、BD-ROMの再生のみを行う通常の再生装置と、制御が一切変わらないため望ましい制限となる。更にオーサリング時においては、1つのTSの入力タイミングを制御して、バッファ状態を観測すればよいので、オーサリング時の検証も容易になる。
ビデオデコーダ４は、PID Filter３bから出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込むものであり、TransportBuffer４a、Multiplexed Buffer４b、Elementary Buffer４c、デコーダ４d、Re-order Buffer４e、スィッチ４fから構成される。
Transport Buffer(TB)４aは、ビデオストリームに帰属するTSパケットがPID Filter３bから出力された際、一旦蓄積されるバッファである。
Multiplexed Buffer(MB)４bは、Transport Buffer４aからElementary Buffer４cにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。
Elementary Buffer(EB)４cは、符号化状態にあるピクチャ(Iピクチャ、Bピクチャ、Pピクチャ)が格納されるバッファである。
デコーダ(DEC.)４dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の復号時刻（DTS）ごとにデコードすることにより複数フレーム画像を得て、ビデオプレーン５に書き込む。
Re-order Buffer４eは、復号されたピクチャの順序を、符号化順序から表示順序に入れ替えるためのバッファである。
スィッチ４fは、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。
オーディオデコーダ９は、Transport Buffer６、Elementary Buffer７、デコーダ８から構成され、オーディオストリームのデコードを行う。
Transport Buffer６は、PID Filter３bから出力されたTSパケットを、先入れ先だし式に格納して、オーディオデコーダ８に供する。
Elementary Buffer７は、PID Filter３bから出力されたTSパケットのうち再生されるべきオーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８に供する。
デコーダ８は、Transport Buffer６に格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
スイッチ１０aは、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットのどちらかを、選択的にビデオデコーダ４に供給する。
スイッチ１０bは、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットのどちらかを、選択的にInteractiveGraphicsデコーダ１１に供給する。
スイッチ１０cは、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのどちらかを、選択的にPresentationGraphicsデコーダ１３に供給する。
Interactive Graphics(IG)デコーダ１１は、BD-ROM１００又はローカルストレージ２００から読み出されたIGストリームをデコードして、非圧縮グラフィクスをIGプレーン１２に書き込むものであり、TransportBuffer(TB)１１a、Coded Data Buffer(CDB)１１b、Stream Graphics Processor(SGP)１１c、ObjectBuffer１１d、Composition Buffer１１e、Graphics Controller(Ctrl)１１fから構成される。
Transport Buffer(TB)１１aは、IGストリームに帰属するTSパケットが一旦蓄積されるバッファである。
Coded Data Buffer(CDB)１１bは、IGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)１１cは、グラフィクスデータを格納したPESパケットをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer１１dに書き込む。
Object Buffer１１dは、Stream Graphics Processor１１cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer１１eは、グラフィクスデータ描画のための制御情報が配置されるメモリである。
Graphics Controller(Ctrl)１１fは、Composition Buffer１１eに配置された制御情報を解読して、解読結果に基づく制御をする。
Interactive Graphics(IG)プレーン１２は、IGデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。
Presentation Graphics(PG)デコーダ１３は、BD-ROM又はローカルストレージ２００から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentationGraphicsプレーン１４に書き込む。PGデコーダ１３は、Transport Buffer(TB)１３a、Coded Data Buffer(CDB)１３b、StreamGraphics Processor(SGP)１３c、Object Buffer(OB)１３d、Composition Buffer(CB)１３e、GraphicsController(Ctrl)１３fから構成される。
Transport Buffer(TB)１３aは、PGストリームに帰属するTSパケットがPIDフィルタ４から出力された際、一旦蓄積されるバッファである。
Coded Data Buffer(CDB)１３bは、PGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)１３cは、グラフィクスデータを格納したPESパケット(ODS)をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer１３dに書き込む。
Object Buffer(OB)１３dは、Stream Graphics Processor１３cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer(CB)１３eは、グラフィクスデータ描画のための制御情報(PCS)が配置されるメモリである。
Graphics Controller(Ctrl)１３fは、Composition Buffer１３eに配置されたPCSを解読して、解読結果に基づく制御をする。
Presentation Graphics(PG)プレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
システムデコーダ１５は、セカンダリTSにおけるシステム制御パケット(PATやPMT)を処理しデコーダ全体を制御する。
Transport Buffer１５aは、プライマリTSに存在するシステム制御パケット(PATやPMT)を格納する。
Elementary Buffer１５bは、システム制御パケットをデコーダ１５cに供する。
デコーダ１５cは、Elementary Buffer１５bに格納されたシステム制御パケットを、デコードする。
Transport Buffer１６aは、セカンダリTSに存在するシステム制御パケットを格納する。
Elementary Buffer１６bは、セカンダリTSにおけるシステム制御パケットをデコーダ１６cに供する。
デコーダ１６cは、Elementary Buffer１６bに格納されたシステム制御パケットを、デコードする。
メモリ２１は、カレントのPlayList情報やカレントのClip情報を格納しておくためのメモリである。カレントPlayList情報とは、BD-ROMに記録されている複数PlayList情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROM/ローカルストレージに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。
コントローラ２２は、プレイリスト再生(カレントPlayList情報に従った再生制御のことである）を実行することで、BD-ROMの再生制御を実現する。また上述のようなATS、STCの制御も行なう。この制御にあたってコントローラ２２は、1秒という時間的範囲において、BD-ROM、ローカルストレージ内のSourceパケットを、デコーダ内のバッファに先読みしておく。このような先読みを行うのは、上述したウィンドゥの制限により、アンダーフロー又はオーバーフローが生じないとの保障があるからである。
PSRセット２３は、再生装置に内蔵されるレジスタであり、64個のPlayer Setting/Status Register(PSR)と、4096個のGeneralPurpose Register（GPR)とからなる。Player Setting/Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
PID変換部２４は、PSRセット２３に格納されているオーディオストリーム、オーディオストリームのストリーム番号を、STN＿Tableに基づき、PID参照値に変換して、変換結果たるPID参照値をPIDFilter３b、PID Filter３dに指示する。
ネットワーク部２５は、本再生装置における通信機能を実現するものであり、URL指定が与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードを実行する。
操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作を示すUser Operation情報をコントローラ２２に通知する。
以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ２２の実装について説明する。コントローラ２２は、図３１、図３２に示したフローチャートの処理手順をCPUに実行させるプログラムを作成して命令ROMに書き込み、CPUに供することで再生装置に実装することができる。
図３１は、PlayList情報に基づく再生手順のフローチャートである。本フローチャートは、PlayList情報を構成する.mplsファイルを読み込み(ステップＳ１１)、PlayList情報における先頭のPlayItemをカレントPlayItemにした上で(ステップＳ１２)、このカレントPlayItemに対して、ステップＳ１３〜ステップＳ２５の処理を繰り返すループ構造になっている。このループ構造は、ステップＳ２３を終了条件としたものであり、カレントPlayItemのIn＿Timeに対応するAccessUnitから、カレントPlayItemのOut＿Timeに対応するAccess Unitまでを読み出しをBD-ROMドライブに命じ(ステップＳ１３)、カレントPlayItemにpreviousPlayItemが存在するか否かを判定して(ステップＳ１４)、判定結果に応じて、ステップＳ１５の処理、ステップＳ１６〜ステップＳ２１の処理を選択的に実行する。具体的には、カレントPlayItemにpreviousPlayItemがなければ(ステップＳ１４でNo)、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ１５)。
カレントPlayItemにpreviousPlayItemがあれば(ステップＳ１４でYes)、カレントPlayItemがCC＝5であるか否かを判定し(ステップＳ１６)、CC＝5であるなら(ステップＳ１６でYes)、ステップＳ１７〜ステップＳ２０の処理を行う。
上述したpreviousPlayItemが存在する場合、プライマリTSにおけるATC＿Sequenceが切り替わることになる。この切替において、ATC＿delta1と呼ばれるプライマリTSのためのオフセット値を算出し(ステップＳ１７)、それまでのATC＿SequenceにおけるATC値(ATC1)に、ATC＿delta1を加算することにより、新しいATC＿SequenceのATC値(ATC2)を得る(ステップＳ１８)。
また、上述した、previousPlayItemが存在する場合、プライマリTSにおけるSTC＿Sequenceが切り替わることになる。この切り替えにおいて、STC＿delta1と呼ばれるオフセット値を求めて(ステップＳ１９)、それまでのSTC＿SequenceにおけるSTC値(STC1)に、STC＿delta1を加算することにより(ステップＳ２０)、新しいSTC＿SequenceのSTC値(STC2)を求める。
そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ２１）。カレントPlayItemがCC＝5でないなら、CC=1、CC=6の処理を行う。
ステップＳ１５、ステップＳ１６〜ステップＳ２１のどちらかの処理を実行すればステップＳ２５の処理を実行する。ステップＳ２５は、カレントPlayItemと同期再生すべきSubPlayItemが存在するかどうかをサーチする処理である。ここでSubPath情報を構成する各SubPlayItemは、Sync＿PlayItem＿Idという情報を有しており、カレントPlayItemと同期再生すべきSubPlayItemは、このSync＿PlayItem＿Idが、カレントPlayItemに設定されている。そこでステップＳ２５では、カレントPlayItemをSync＿PlayItem＿Idに指定したSubPlayItemが、SubPath情報を構成する複数のSubPlayItemの中に存在するかどうかをサーチする。
もし存在しない場合、ステップＳ２２に移行する。ステップＳ２２は、AVClip時間軸における現在の再生時点(カレントPTM(PresentationTiMe))がカレントPlayItemのOut＿Timeに到達したかどうかを判定する(ステップＳ２２) 。到達すれば、ステップＳ２３に移行する。ステップＳ２３は、カレントPlayItemがPlayList情報における最後のPlayItemになったか否かの判定であり、最後のPlayItemでなければ、PlayList情報における次のPlayItemを、カレントPlayItemにして(ステップＳ２４）、ステップＳ１３に移行する。以上の処理により、PlayList情報における全てのPlayItemに対して、ステップＳ１３〜ステップＳ２４の処理が施されることになる。
図３２は、SubPlayItemにおけるシームレス接続を示すフローチャートである。
ステップＳ２５においてカレントPlayItemをSync＿PlayItem＿Idに指定したSubPlayItemが存在すると判定された場合、そのSubPlayItemをカレントSubPlayItemに設定して(ステップＳ３１)、SubPlayItemのIn＿Timeに相当するAccessUnitから、Out＿Timeに相当するAccess Unitまでの読み出しをローカルストレージ２００に命じる(ステップＳ３２)。そしてカレントPlayItemにPreviousSubPlayItemが存在するか否かを判定して(ステップＳ３３)、判定結果に応じて、ステップＳ３４、ステップＳ３５の処理、ステップＳ３６〜ステップＳ４１の処理を選択的に実行する。具体的には、カレントPlayItemにPreviousSubPlayItemがなければ(ステップＳ３３でNo)、カレントPTMが、Sync＿Start＿Pts＿of＿PlayItemに到達するのを待ち(ステップＳ３４)、到達すれば、SubPlayItem＿In＿TimeからSubPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ３５)。
カレントPlayItemにPrevious SubPlayItemがあれば(ステップＳ３３でYes)、カレントPlayItemがSP＿CC=5であるか否かを判定し(ステップＳ３６)、SP＿CC=5であるなら(ステップＳ３６でYes)、ステップＳ３７〜ステップＳ４１の処理を行う。
上述した、previousPlayItemが存在する場合、ATC＿Sequenceが切り替わることになる。この切替において、ATC＿delta2と呼ばれるセカンダリTSのためのオフセット値を算出し(ステップＳ３７)、それまでのATC＿SequenceにおけるATC値(ATC1)に、ATC＿delta2を加算することにより、新しいATC＿SequenceのATC値(ATC2)を得る(ステップＳ３８)。
ATC＿deltaとは、これまで読み出されているトランスポートストリーム(TS1)の最後のTSパケットの入力時点T1から、新たに読み出されたトランスポートストリーム(TS2)の最初のTSパケットの入力時点T2までのオフセット値をいい、“ATC＿delta≧N1/TS＿recording＿rate”という計算式で与えられる。ここでN1は、TS1の最後のビデオPESパケットに後続する、TSパケットのパケット数である。
また、上述した、previousPlayItemが存在する場合、STC＿Sequenceも切り替わることになる。この切り替えにおいて、STC＿delta2を求めて(ステップＳ３９)、それまでのSTC＿SequenceにおけるSTC値(STC1)に、STC＿delta2を加算することにより(ステップＳ４０)、新しいSTC＿SequenceのSTC値(STC2)を求める。
先行STC＿Sequenceにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STC＿Sequenceにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、CC＝5では、PTS1(1stEND)＋Tppの時刻と、PTS2(2ndSTART)の時刻とを一致させる必要があるから、STC＿delta2は、

STC＿delta2＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)

との計算式から算出される。

そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ４１）。
コントローラ２２は、上述したように、STCの変更処理を行うが、再生装置の一般的な実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。フリーラン状態とは、デコーダがSTCとの同期制御を行っていない状態をいう。その後、STC時間軸が設定できる状態まで、STCが復帰すれば、デコーダは、フリーラン状態から、STCとの同期制御へと移行する。一方、ステップＳ３６においてカレントPlayItemがCC＝5でないと判定されたなら(ステップＳ３６でNo)、CC=1、CC=6の処理を行う。
以上のように本実施形態によれば、Windowと呼ばれる1秒当たりの転送許容量は、48Mbit以下に制限されているので、この1秒という期間において、転送許容量が局所的に96Mbitまであがったとしても、96Mbit×0.5秒のサイズのTSパケットを、デコーダに先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローすることはない。デジタルストリームにおけるどの期間であっても、データ量は「96Mbit×0.5秒」以下であり、アンダーフロー又はオーバーフローが生じることなく、TSパケットを供給することができるので、ビデオ又はオーディオの欠落を避けることができる。これによりOut-of-MUXフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。
また、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとが一致していて、PlayItem側の接続状態がCC＝5であるなら、SubPlayItem側の接続状態もSP＿CC=5になるので、PlayItemが切り替えられたとしても、多重分離部を再設定することなく、PlayItemからPlayItemへの切り替えと、SubPlayItemからSubPlayItemへの切り替えとを同時に実行することができる。多重分離部が参照するSTC時間軸を同期させつつ、PlayList情報に基づく再生処理を進行させてゆくことができる。
(第２実施形態)
本実施形態では、先の実施形態で述べた、BD-ROMの製作について、詳しく説明する。先の実施形態に係るBD-ROMは、以下の工程を順次実行することにより、作ることができる。 ＜BD-ROMの記録工程＞
先ず初めに、BD-ROMをどのような筋書きで再生させるかを決めるかを企画して(企画工程)、動画収録、音声収録等の素材作成を行い(素材作成工程)、企画工程において作成された筋書きから、ボリューム構成情報を作成する(シナリオ作成工程)。
ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る(素材エンコード工程)。その後、複数のエレメンタリストリームの多重化を行う(多重化工程)。
こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、BD-ROMの応用層フォーマットに適合させる作業を行い、BD-ROMのボリューム領域に記録すべきデータの全体像(一般にボリュームデータという)を得る(フォーマッティング工程)。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、BD-ROM規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、Clip情報,PlayList情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のfor文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、if文を用いて定義することができる。
こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う(エミュレーション工程)。このエミュレーション工程では、BD-ROMプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、BD-ROMを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。
以上の工程を経て、各実施形態に示した記録媒体(BD-ROM)を作ることができる。
＜追加コンテンツの作成工程＞
映画作品を、BD-ROMコンテンツと、追加コンテンツとで構成する場合は、上述した企画工程からフォーマッティング工程までを実行する。そうして、1つのボリュームデータを構成するAVClip、Clip情報、PlayList情報が得られれば、これらのうち、既にBD-ROMにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバプログラム等で1つのファイルにまとめる。こうした処理を経て、追加コンテンツが得られれば、かかる追加コンテンツをWWWサーバーに供し、再生装置からの要求に応じて、再生装置に送出する。
先の実施形態で述べたベリファイは、AVClip、Clip情報、PlayList情報が完成し、PlayList情報内のSTN＿tableにより、再生すべきエレメンタリストリームが確定した段階、つまり、フォーマッティング工程で実行される。以降、かかるアプリケーションフォーマットを作成するオーサリングシステムについて説明する。
＜オーサリングシステム＞
図３３は、第２実施形態にかかるオーサリングシステムの内部構成を示す図である。本図に示すようにオーサリングシステムは、入力装置５１、エンコード装置５２、サーバ装置５３、素材ストレージ５４、BD構成情報ストレージ５５、クライアント装置５６〜５８、マルチプレクサ６０、BDシナリオコンバータ６１、フォーマッタ６２、Verifier６３から構成される。
入力装置５１は、HD画像、SD画像が収められたビデオカセットを装填し、このビデオカセットを再生して再生信号をエンコード装置５２に出力する。
エンコード装置５２は、入力装置５１から出力された再生信号をエンコードして、ビデオストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得られたエレメンタリストリームは、LANを通じてサーバ装置５３に出力され、サーバ装置５３内の素材ストレージ５４に書き込まれる。
サーバ装置５３は、素材ストレージ５４、BD構成情報ストレージ５５という2つのドライブ装置からなる。
素材ストレージ５４は、サーバ装置５３の内蔵ディスク装置であり、エンコード装置５２のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ５４は、HDstreamディレクトリ、SDstreamディレクトリといった2つのディレクトリをもち、HD画像をエンコードすることにより得られたエレメンタリストリームはHDstreamディレクトリに書き込まれる。
BD構成情報ストレージ５５は、BDボリューム構成情報が格納されるドライブ装置である。
マルチプレクサ６０は、素材ストレージ５４内のHDstreamディレクトリ、SDstreamディレクトリに格納されているエレメンタリストリームのうち、BDボリューム構成情報により指定されているものを読み出し、これをBDボリューム構成情報に従い多重化することで、多重化ストリームであるAVClipを得る。
BDシナリオコンバータ６１は、BD構成情報ストレージ５５に格納されているBDボリューム構成情報をBD-ROMアプリケーションフォーマットに変換することによりBDシナリオを得る。
フォーマッタ６２は、マルチプレクサ６０によりえられたClip、BDシナリオコンバータ６１により得られたBDシナリオを、BD-ROMの応用層フォーマットに適応させる。こうして適応されらBDシナリオから、BD-ROMの原盤や、ローカルストレージに格納されるべきダウンロード用コンテンツが得られる。
ベリファイ部６３は、シナリオコンバータ６１が生成したPlayList情報内のSTN＿tableを参照して、マルチプレクサ６０が得たBD-ROM用のプライマリTS、ローカルストレージ用のセカンダリTSが、Out＿of＿MUXアプリケーションを実現するため制限を満たすかどうかを判定する。
以上が、オーサリングシステムの内部構成である。以降、オーサリングシステムおけるベリファイ部６３の実装について説明する。
＜ベリファイ部６３実装のための処理手順＞
ベリファイ部６３は、図３４、図３５に示したフローチャートの処理手順をCPUに実行させるプログラムを作成して命令ROMに書き込み、CPUに供することでオーサリングシステム内に実装することができる。
図３４は、プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。本フローチャートは、ステップＳ１において、Sourceパケット列における最初のSourceパケットのATSを、カレントWindowのIn＿Timeに設定した上で、ステップＳ２〜ステップＳ７の処理を繰り返すループ構造を有している。このループ構造は、カレントWindowのIn＿Timeから1秒以降に存在するATSを、カレントWindowのOut＿Timeに設定して(ステップＳ２)、カレントWindowのIn＿TimeからOut＿Timeまでに存在するTSパケット数をカウントし(ステップＳ３)、In＿TimeからカレントWindowにおけるビット数を算出して(ステップＳ４)、そのビット値が48Mbit以下であるかを判定する処理(ステップＳ５)を、ステップＳ６がYesと判定されるまで繰り返すものである。このステップＳ６は、カレントWindowのOut＿Timeが、ATC時間軸における最後のSourceパケットに到達したかどうかの判定であり、もしステップＳ６がNoであるなら、Sourceパケット列における次のATSを、カレントWindowのIn＿Timeにして(ステップＳ７)、ステップＳ２〜ステップＳ６の処理を繰り返す。どれかのWindowで、ステップＳ５がNoと判定されたなら、BD-ROM規格に違反していると判定される(ステップＳ９)。全てのWindowでステップＳ５がYesと判定され、ステップＳ６がYesと判定されたなら、BD-ROM規格に適合していると判定される(ステップＳ８)。
プライマリTS、セカンダリTSは、以上のベリファイを経ているので、プライマリTS、セカンダリTSがそれぞれBD-ROM、ローカルストレージから供給される場合でも、上述したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのそれぞれに、同種のエレメンタリストリームが複数存在する場合、図３５の手順で、ベリファイを行うのが望ましい。図３５に示すベリファイ手順は、図３４におけるステップＳ３〜ステップＳ４を、ステップＳ８１〜ステップＳ８３に置き換えたものである。
このステップＳ８１〜ステップＳ８３は、カレントWindowが1つ決定される度に、STN＿tableにおいて、再生が許可されているエレメンタリストリームを構成するTSパケットのうち、カレントWindowに属するもののビットレートを、エレメンタリストリーム毎に算出して(ステップＳ８１)、複数のビデオストリーム、複数のオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び(ステップＳ８２)、ビデオストリームのビットレートの最大値、オーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して(ステップＳ８３)、その合計量が48Mbit以下であるかを判定する(ステップＳ５)ものである。
同種のエレメンタリストリームは、Out＿of＿MUXアプリケーションでは、必ず排他的に選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下の通りである。
(1)WindowのIn＿Timeが指し示すTSパケットの先頭
(2)WindowのIn＿Timeが指し示すTSパケットの終了
(3)WindowのOut＿Timeが指し示すTSパケットの先頭
(4)WindowのOut＿Timeが指し示すTSパケットの終了

かかる箇所におけるビット量を重点的にチェックすることで、オーサリングでのベリファイ作業を、より簡略化することができる。
以上のように本実施形態によれば、セカンダリTSの再生を許可したSTN＿tableを作成した際、そのSTN＿tableに基づく再生処理で、アンダーフロー又はオーバーフローが生じるかどうかを、オーサリングの段階で、あらかじめ検証しておくことができる。
(第３実施形態)
本実施形態は、PlayItem間、SubPlayItem間の接続に、CC=6という新たな類型を設ける実施形態である。
CC=6とは、Progressive PlayList情報を構成する複数のPlayItem情報間の接続状態を規定する。ProgressivePlayList情報とは、ストリーミングを前提にして再生されるべき複数のAVClipを、1つの再生経路として指定してゆくためのプレイリスト情報である。
＜Progressive PlayList情報＞
Progressive PlayList情報は、ダウンロード/ストリーミングするセカンダリTSを細切れのファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウンロードを待たずに、再生を開始することができる利便がある。
ストリーミングを前提にしたコンテンツは、短い長さの多くのAVClipにて規定されているので、Progressive PlayList情報は、これら複数AVClipのそれぞれに対応する、多くのPlayItem情報から構成される。一方、細かい単位に分割されたAVClipは、ストリーミングのために分割されたのであって、STC、ATCに不連続点が存在している訳ではない。そのため、CC＝5ではない別の状態として、かかるAVClip間の接続状態を規定しておく必要がある。こうして規定された接続状態を、CC=6という。

＜CC=6において満たすべき条件＞
CC=6である場合、2つのPlayItemから指定されるTS1、TS2と、2つのSubPlayItemから指定されるTS1、TS2とは、以下の条件を満たす必要がある。
1)TS2におけるビデオストリームは、GOPから始まらなければならない。
2)TS2のオーディオストリームと同じPIDをもつTS1のオーディオストリームとにおいて、接続点におけるAudio Presentation Unit列に、ギャップが存在しない。
TS1のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そして、TS2における同じPIDをもつオーディオストリームは、不完全なAudioPresentation Unitから始まってもよい。複数のPlayItem、複数のSubPlayItemに基づき、これらのTS1、TS2を再生させてゆけば、2つのAudioPresentation Unitから、1つの完結したAudio Presentation Unitが得られる。
CC=6では実際にはストリームが連続しているため、CC=５の時のようなビデオだけがシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするようなことはなく、全てのエレメンタリストリームがシームレスに接続される。

以上のようにCC=6は、論理的に連続しているストリームを、ストリーミングの都合から、複数の部分に分割した場合の分割境界を意味する。ただし、BD-ROMに記録されるべきストリームは32個のSourceパケットから構成される必要があるので、１つのSubPlayItemを構成する１つのストリームファイルは、全て、6KByteの倍数になっている必要がある。
＜CC=6の詳細＞
図３６は、CC=6の詳細な説明を示す図である。第1段目は、１本の連続したATC/STC時間を有し、符号化方式も連続しているストリームを格納したファイル(20000.m2ts)を示す。第2段目は、3つのストリームを格納した格納した3つのファイル(20001.m2ts,20002.m2t,20003.m2ts)を示す。これらの3つのファイルは、第1段目における1本のストリームを、アラインドユニット（6KByte）単位で区切ることで得られた、3つのプライマリTSを格納している。
図３７は、PlayItemとSubPlayItemの相関を示した図である。第1段目は、PlayList情報における3つのPlayItem(PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3)を示す。これら3つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC＝1に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC＝5に設定されている。第2段目は、PlayList情報における3つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3)を示す。これら3つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC＝1に設定され、SubPlayItem＃2、SubPlayItem＃3間は、CC＝5に設定されている。第3段目は、ProgressivePlayList情報における9つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9)を示す。これら9つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はCC=1に設定され、SubPlayItem＃6、SubPlayItem＃7間は、CC＝5に設定され、それ以外は、CC=6に設定されている。Progressive PlayListのSubPlayItemは、CC=6で接続されるが、PlayItemがCC=１、CC=５で接続されるタイミングでは、PlayItemと同様にCC=１、CC=５の条件を満たしながら接続される。
以上のように本実施形態によれば、PlayItem、SubPlayItemにおける接続状態に、CC=6という新たな類型を導入することで、ProgressivePlayList情報を構成するAVClipを短く区切って、ストリームングで供給するという処理を実現することができる。

(第４実施形態)
第１実施形態では、各Windowにおけるビット量を、どのように制限するかについて説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えばよいかを提案する。
＜ビデオ＋オーディオの多重化＞
図３８は、プライマリTSを構成するオーディオが、セカンダリTSを構成するオーディオに入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
図３８は、ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的に示す図である。第1段目は、プライマリTSを示す。プライマリTSはV、A1、A2（ビデオ１本、オーディオ２本）を格納したTSパケットである。これらのTSパケットは、２種類３本のエレメンタリストリームを多重化して得たものである。
第2段目は、セカンダリTSを示す。セカンダリTSは、１種類２本のオーディオA３、A４を格納したTSパケットからなる。これらセカンダリTSのTSパケットが多重化される時間帯p3は、デコーダへの入力時間軸を示すATC時間軸上で、プライマリTSのオーディオパケットが多重化された時間帯p1と、プライマリTSを構成するTSパケットが転送されてない時間帯p2とからなる。
このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されてもデコードすべきエレメンタリストリームのビットレートの和がプライマリTSの許容最大ビットレート（４８Mbps）を超えない保証ができる。図３８の上述した一例は、一番簡単な例で、セカンダリTSにオーディオしかない場合である。
＜ビデオ＋オーディオ＋PGストリーム＋IGストリームの多重化＞
図３９は、オーディオに加えて、字幕（PGストリーム）やメニュー（IGストリーム）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
本図において、セカンダリTSのパケットの転送が許可される時間帯k3は、
1) プライマリTSにおける同種のパケットの転送時間帯k1
2) プライマリTSの無転送時間帯k2
の和である。
セカンダリTSに格納されている他ストリーム種別（Video、IG、PG等）についても上記1)、2)のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類のストリームの転送時間帯でセカンダリTS内に多重化が可能か判断され、これで不足する場合には、2)のプライマリTSの無転送時間帯を利用して多重化されることが効率的である。
＜マルチプレクサ６０の処理＞
本実施形態にかかるマルチプレクサ６０の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ６０は、デコーダモデルにおいて、プライマリTSを再生する際のバッファ状態をシミュレートし、プライマリTSにおける各パケットの転送時間帯や、プライマリTSの無転送時間帯を検出する。これらの時間帯を検出すれば、セカンダリTSを構成する各PESパケットが、同種のパケットの転送時間帯や、無転送時間帯に転送されるよう、セカンダリTSを構成する各PESパケットをTSパケットに変換して、各TSパケットに、かかるATSを付す。こうして付されたATSは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリTSを構成する各PESパケットは、図３９に示したように、プライマリTSにおける同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。
＜DVDによる供給＞
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム形式ではなく、プログラムストリーム形式にする場合、マルチプレクサ６０は、エレメンタリストリームを構成するPESパケットを、パックに変換して、各パックのTSヘッダにSCR(SystemClock Reference)を付す。こうして付されたSCRも、ATS同様、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリPS(ローカルストレージから供給されるプログラムストリーム)を構成する各PESパケットは、図３９に示したように、プライマリPS(BD-ROMから供給されるプログラムストリーム)における同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレージから供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種のパケットの転送時間帯や、無転送時間帯を、パック（PESパケット）という大きな時間単位で表現するので、オーサリング時における負担は格段に小さく、実現が容易となる。これは、DVD再生装置において、Out＿of＿MUXアプリケーションを実現するにあたっての、利点となる。
以上のように本実施形態によれば、プライマリTSにおける同種のパケットの転送期間、プライマリTSにおける無転送期間を、セカンダリTSを構成するパケットの入力期間に選び多重化を行うので、第１実施形態に示したビット量制限を満たしやすくなる。かかる多重化を第２実施形態に示したオーサリングシステム上で実現することにより、Out＿of＿MUXアプリケーションを実現するような映画作品を製作しやすくなる。これにより、再生時のオーバフローが生じないような保障をオーサリングの段階で、容易に行うことができる。

（第５実施形態）
本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本アプリケーションは、1つの種別につき、1つのエレメンタリストリームというOut＿of＿MUXの規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシングアプリケーションはプライマリTSにあたるオーディオストリームと、セカンダリTSにあたるオーディオストリームとを同時に選択し、プライマリTSの音声とセカンダリTSの音声の２つの音声を同時にデコードする点が例外となる。
図４０は、オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ１a、ローカルストレージ２００、ネットワーク部２５を左側に示し、各デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPIDFilterを示す。そして本図におけるプライマリTS(Video1,Audio1(English),Audio2(Spanish),PG1(EnglishSubtitle),IG1(English Menu))、セカンダリTS(Audio3(Commentary),PG2(JapaneseSubtitle),PG3(Korean Subtitle),PG4(Chinese Subtitle),IG2(English Menu))は、それぞれBD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio1）とスペイン語（Audio 2）しか記録されていないため、映画監督のコメンタリ音声は、このディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供するAudio3(Commnetary）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、英語音声（Audio 1）と、Audio 3(Commentry）とを、デコーダに送り込むことができる。これらの英語音声（Audio1）と、Audio 3(Commentry）とを、デコーダがミキシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像(Video1)と共に再生させることができる。
Out-of-MUXアプリケーションとの相違は２つのオーディオストリームを同時にデコードする点のみである。如何なるプライマリTSに対しても、ディスク発売後に監督のコメンタリ音声を付加するなどといったことが想定されるため、プライマリTSへのビットレート制限などは好ましくなく、Out-of-MUXと同様にセカンダリTSへの制限を導入する。オーディオミキシングでは、各エレメンタリストリーム（ビデオ、オーディオ、字幕、メニュー）に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソースを2つ必須とする。
＜プライマリ、セカンダリオーディオストリームの構成＞
オーディオミキシングアプリケーションを実現するにあたって、プライマリTSにおける属することになるオーディオストリームを、プライマリオーディオストリームといい、セカンダリTSに属することになるオーディオストリームをセカンダリオーディオストリームという。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて説明する。
プライマリオーディオストリームは、32本存在し、それらは0x1100から0x111FまでのPIDをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリーム同様、32本存在し、0x1A00から0x1A1FまでのPIDをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカンダリオーディオストリームのオーディオフレームに、“ダウンミキシング情報”と、“ゲイン制御情報”とからなるメタデータを含む点である。
“ダウンミキシング情報”は、ダウンミキシングのための情報である。ダウンミキシングとは、音声の再生チャネル数を符号化チャンネル数よりも少なくする変換であり、ダウンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、このダウンミキシングを再生装置に行わせる。5.1chの音声ストリームを2chで再生することなどがダウンミキシングの一例である。
“ゲイン制御情報”とは、プライマリオーディオストリーム側の音声出力時のゲインを上げ下げする情報であるが、ここでは下げるだけでよい。このようにセカンダリオーディオストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出力をリアルタイムに下げることができる。PrimaryオーディオとSecondaryオーディオを重畳する場合には、あらかじめミキシングされるPrimaryオーディオとSecondaryオーディオの対が分かっているため、2本のオーディオのゲインをリアルタイムに制御する必要は無く、Primaryオーディオのゲインだけを下げてSecondaryオーディオのゲインはそのままにミキシング(重畳)することで十分である。かかるメタデータを配置することで、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避けることができる。以上が、本実施形態におけるオーディオストリームについての説明である。続いて、本実施形態におけるPlayList情報における改良について説明する。
＜オーディオミキシングアプリケーションを実現するためのSTN＿table＞
同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、本実施形態におけるPlayList情報には、再生が許可されている複数プライマリオーディオストリーム、複数セカンダリオーディオストリームの組合せが、各PlayItemのSTN＿tableに示されている。
以降、本実施形態におけるSTN＿tableについて説明する。オーディオミキシングアプリケーションを実現するため、STN＿tableには、セカンダリオーディオストリームにおけるStream＿entryと、Stream＿attributeとの組みが、プライマリオーディオストリームにおけるStream＿entryと、Stream＿attributeとの組みとは別に存在する。そして、セカンダリオーディオストリームにおけるStream＿entryと、Stream＿attributeとの組みが、Comb＿info＿Secondary＿audio＿Primary＿audioと対応付けられている。
（Comb＿info＿Secondary＿audio＿Primary＿audio）
Comb＿info＿Secondary＿audio＿Primary＿audioは、そのセカンダリオーディオストリームの再生出力をミキシングすることができる1つ以上のプライマリオーディオストリームを一意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ以外の属性を有しているようなプライマリオーディオストリームの再生時においてのみ、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミキシングの可否を、オーサリング時に設定しておくことができる。
（sp＿connection＿condition情報）
またPlayList情報において、SubPlayItemのsp＿connection＿condition情報は、PlayItem情報のconnection＿condition情報と同じ値に設定される。よってPlayItem情報のconnection＿condition情報が“＝5”であるなら、SubPlayItem情報のsp＿connection＿condition情報もSP＿CC=5に設定される。またSubPlayItem情報のIn＿Time、Out＿Timeは、PlayItem情報のIn＿Time、Out＿Timeと同じ時点を指し示す。
以上が本実施形態における記録媒体の改良である。続いて本実施形態に係る再生装置の内部構成について説明する。
＜再生装置の内部構成＞
図４１は、第５実施形態に係る再生装置の内部構成を示す図である。本図に示すように、TB６、EB７、オーディオデコーダ８は、Audio Mixing Processor（点線で囲まれた部分）に置き換えられている。このAudio Mixing Processorは、プライマリTSとセカンダリTSから２本の音声ストリームを入力し、同時にデコードしてミキシングするものである。その他の構成はOut-of-MUXアプリケーションを実現するための内部構成と同様である。以降、Audio Mixing Processorについて説明する。Audio Mixing Processorは、TransportBuffer６a、６b、EB７a、７b、プリロードバッファ７c、オーディオデコーダ８a、８b、ミキサ９a、９bから構成される。
Transport Buffer６aは、PID Filter３bから出力された、オーディオストリームのPIDを有するTSパケットを、先入れ先だし式に格納して、オーディオデコーダ８aに供する。
Transport Buffer６bは、PID Filter３dから出力された、オーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８bに供する。
EB７aは、バッファ６aに格納されたTSパケットを変換することで得られる、PESパケットを格納するバッファである。
EB７bは、バッファ６aに格納されたTSパケットを変換することで得られる、PESパケットを格納するバッファである。
プリロードバッファ７cは、BD-ROM/ローカルストレージから読み出されたファイルsound.bdmvをプリロードしておくためのメモリである。ファイルsound.bdmvとは、メニューに対する操作に出力すべきオーディオデータを格納したファイルである。
オーディオデコーダ８aは、プライマリTSを構成するPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
オーディオデコーダ８bは、セカンダリTSを構成するPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
ミキサ９aは、オーディオデコーダ８aから出力されるLPCM状態のデジタルオーディオと、オーディオデコーダ８bから出力されるLPCM状態のデジタルオーディオとをミキシングする。
ミキサ９bは、ミキサ９aから出力されるLPCM状態のデジタルオーディオと、バッファ７cに格納されているサウンドデータとをミキシングする。このサウンドミキサ９bによるミキシングは、クリック音の発音を意図したようなナビゲーションコマンドを、コントローラ２２が解読することでなされる。
以上が、本実施形態にかかる再生装置についての説明である。
＜オーディオミキシングアプリケーションに対するベリファイ＞
上述したように、オーディオミキシングアプリケーションはプライマリオーディオストリーム、セカンダリオーディオストリームから構成されるので、第２実施形態に示したようなベリファイは、プライマリオーディオストリーム、セカンダリオーディオストリームが同時に読み出された場合を想定して実行される。具体的にいうと、MainClip、SubClipが基準としているATC時間軸において、1ずつWindowを、シフトさせてゆく。このシフトの手順は、図３５のフローチャートに示したものと同じである。そしてATSに示されるATC時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が48Mbit以下であるかを判定する。48Mbitを越えていれば、BD-ROM規格に違反していると判定結果を下す。
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマリオーディオストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに供給する場合でも、1秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、オーディオミキシングアプリケーションを、効率的に作成することができる。そのため、オーディオミキシングアプリケーションを実現するような追加コンテンツを、ローカルストレージにダウンロードして、ローカルストレージからデコーダに供給するという供給態様が可能になるので、BD-ROMの出荷後に、コメンタリを追加するような供給法を容易に実現することができる。
（第６実施形態）
第１実施形態では、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとを一致させることで、PlayItem間の接続点、及び、SubPlayItemの接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この接続点の一致を要求せず、ある程度の時間差を認める。
この時間差を認める場合、別の制限が必要になる。PlayItem、SubPlayItem間のシームレス接続において、上述したSTCの変更処理を行うが、この変更処理は、デコーダがフリーラン状態にある場合になされる。この場合、シームレス接続ではSTCが復帰するまで、デコーダは、同期制御に移ることができないので、STC変更を伴うシームレス接続は実装の都合上、頻繁には受け入れられない。したがって、PlayItemとSubPlayItemの両方において連続するCC=５の接続点は所定の時間間隔（例えば3秒程度)を置いて起こるように制限されるべきである。
図４２は、オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。図４２の第1段目は、PlayList情報における3つのPlayItem(PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3)を示す。これら3つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC=1に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC＝5に設定されている。図４２の第2段目は、PlayList情報における3つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3)を示す。これら3つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC=1に設定され、SubPlayItem＃2、SubPlayItem＃3間は、SP＿CC＝5に設定されている。図４２の第3段目は、ProgressivePlayList情報における9つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9)を示す。これら9つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はSP＿CC=1に設定され、SubPlayItem＃4、SubPlayItem＃5間は、SP＿CC=5に設定され、それ以外は、SC=6に設定されている。
本図において、第2段目のSubPlayItem＃3の開始は、第1段目におけるPlayItem＃3の開始点より3秒前である。同様に、第3段目のSubPlayItem＃5の開始点は、第1段目におけるPlayItem＃3の開始点より3秒前である。
PlayItemと、SubPlayItemとのSTC時間軸切り替えのための時間間隔は、3秒になっているので、STC時間軸の変更が頻繁になり過ぎることはない。
またCC=１のタイミングはPlayItemに合わせてSP＿CC=１で接続される。これはCC=１のノンシームレス接続時にSubPlayItemだけが再生を連続して継続した場合に、PlayItemとSubPlayItemの同期再生がずれていくことを防ぐためでもある。
PlayItemの途中でSubPlayItemをSP＿CC=５で接続するという接続形態は、一枚のディスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。
図４３の第1段目は、劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す。このPlayList情報のうち、PlayItem＃１、PlayItem＃２、PlayItem＃４から構成されるがディレクターズカットであり、PlayItem＃１、PlayItem＃３、PlayItem＃４から構成されるのが劇場公開版である。このように、PlayItem＃１とPlayItem＃４はどちらのバージョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えることができる。図４３の第2段目は、同図の第1段目におけるPlayItem＃１、PlayItem＃２、PlayItem＃４に対応するコメンタリを1つのSubPlayItemとして定義し、PlayItem＃１、PlayItem＃３、PlayItem＃４に対応するコメンタリとを、別のSubPlayItemとして定義する一例を示す。この場合、2つのSubPlayItemのそれぞれにおいて、PlayItem情報＃1、PlayItem情報＃4に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。
図４３の第3段目は、PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3、PlayItem情報＃4のそれぞれに対応するSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3、SubPlayItem＃4)を定義する一例を示す。そしてSubPlayItem＃1と、SubPlayItem＃2及びSubPlayItem＃3との間、SubPlayItem＃2及びSubPlayItem＃3と、SubPlayItem＃4との間は、CC＝5で接続するものとする。これらの接続点は、PlayItemにおける接続点と、3秒の時間間隔を設ける。つまりPlayItem＃１が終わる3秒前にコメンタリの方はSubPlayItem＃２とSubPlayItem＃３にCC=５（もしくはCC=6）を使って分岐させている。
また、PlayItem＃２、PlayItem＃３が終わった3秒後にCC=５（もしくはCC=6）を使ってSubPlayItem＃４に分岐している。SubPlayItem＃２とSubPlayItem＃３の開始、及び、SubPlayItem＃４の開始は、PlayItem＃２とPlayItem＃３の開始、及び、PlayItem＃４の開始から、3秒の時間間隔を置いている。以上の時間間隔を置くことにより、STC時間軸の変更が頻繁になり過ぎることはない。
厳密には、CC=５は、SubPlayItem＃３からSubPlayItem＃４への復帰の時だけ（ATC/STC時間軸がリセットされるシームレス接続）必要であり、その他はCC=6で代用が可能である。
以上のように本実施形態によれば、PlayItemのIn＿Time、Out＿Timeと、SubPlayItemのIn＿Time、Out＿Timeとが一致していないので、ATCCounter２aと２c、およびSTC Counter３aとSTC Counter３cの同期は不要となり、再生装置の設計の余地を広げることができる。
(第７実施形態)
第６実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリームをBD-ROM、ローカルストレージから同時に読み出しデコーダに供給する場合、プライマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象としたが、本実施形態では、Picturein Picture(PiP)再生アプリケーションを実現する場合におけるビット量制限について説明する。
PiP再生とは、PlayList情報のMainPath情報により、動画像を構成するMainClipが指定されており、PlayList情報のSubPlayItem情報により、別の動画像を構成するSubClipが指定されている場合、前者の動画像(PrimaryVideo)と、後者の動画像(Secondary Video)とを、同じ画面内に表示するこという。ここでPrimary VideoはHD画像から構成され、SecondaryVideoはSD画像から構成される。HD画像は、1920×1080という解像度を有し、フィルム素材同様、3750（もしくは3753か3754）クロックのフレーム間隔を有する。SD画像は、720×480という解像度を有し、NTSC素材同様、1501クロックの表示間隔、又は、PAL素材同様、1800クロックのフレーム間隔を有する。
SD画像の解像度は、HD画像の解像度の約1/4程度なので、HD画像たるPrimary Videoと、SD画像たるSecondary Videoとを同じ画面上に表示すると、SecondaryVideoは、Primary Videoに対し、約1/4程度の大きさになる。
ここでSecondary Videoは、監督や出演者のみが登場している動画像であり、Primary Videoにおける映像内容を指さすような演技を行っているものとする。かかる動画像がSecondaryVideoであるなら、かかるSecondary Videoの映像内容を、Primary Videoの映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や出演者が指さして、解説しているような、楽しい画面演出を実現することができる。
＜本実施形態におけるPlayList情報＞
Secondary Videoのためのビデオストリーム(セカンダリビデオストリーム)は、PlayList情報のSubPath情報における複数のSubPlayItem情報にて指定される。かかるSubPlayItem情報には、PiP＿Position、PiP＿Sizeという情報要素が新規に追加される。
“PiP＿Position”は、Primary Video再生のための画面プレーン上のX座標、Y座標を用いて、Secondary Videoの再生映像が配置されるべき位置を示す。
“PiP＿Size”は、Secondary Video再生映像の縦サイズ、横サイズを示す。
また、本実施形態においてSubPlayItemのsp＿connection＿condition情報が“=5”に設定されているということは、カレントSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームと、previousSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームとがシームレス接続される保証があることを意味する。かかるSubPlayItemのsp＿connection＿condition情報は、PlayItem情報のconnection＿condition情報と同じ値に設定されるので、PlayItem情報のconnection＿condition情報が“＝5”であるなら、SubPlayItem情報のsp＿connection＿condition情報も“＝5”に設定されねばならない。つまりPlayItem側のプライマリビデオストリームがシームレス接続されるなら、SubPlayItem側のセカンダリビデオストリームもシームレス接続されねばならない。またSubPlayItem情報のIn＿Time、Out＿Timeは、PlayItem情報のIn＿Time、Out＿Timeと同じ時点を指し示さねばならない。
以上が、本実施形態における記録媒体の改良である。
＜本実施形態における再生装置の改良＞
続いて、再生装置の改良について説明する。Secondary Videoストリームのデコードを行うべく、本実施形態に係る再生装置のハードウェア構成には、ビデオストリームをデコードするための構成要素がもう一組、追加されている。ここでビデオストリームをデコードするための構成要素とは、TransportBuffer、Multiplexed Buffer、Elementary Buffer、デコーダ、Videoプレーンであり、これらはセカンダリビデオストリームをデコードする。その他、本実施形態に係る再生装置には、以下のScaller、合成部が追加されている。
Scallerは、SubPlayItem情報のPiP＿Sizeに示される縦・横の大きさに基づき、Secondary Videoプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、Scallerによりされた拡大又は縮小された再生映像と、ビデオデコーダにより得られた再生映像とを合成することでPiP再生を実現する。合成部によるPrimaryVideoの再生映像と、Secondary Videoの再生映像との合成は、SubPlayItem情報にて規定されている、PiP＿Positionに従ってなされる。こうすることにより、PrimaryVideoの再生映像と、Secondary Videoの再生映像とが合成された合成映像が再生されることになる。この合成部による合成では、クロマキー合成、レイヤ合成等が可能であり、SecondaryVideoにおける背景を取り除き、人物部分を抜き出した上で、Primary Videoの再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置についての説明である。
＜PiPアプリケーションに対するベリファイ＞
PiP再生の実現にあたって、プライマリTSたるビデオストリーム(プライマリビデオストリーム)、セカンダリTSたるビデオストリーム(セカンダリビデオストリーム)を同時に読み出し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリームを、ビット量を制限するためのベリファイの対象とする。
具体的にいうとATC時間軸においてWindowをシフトさせた際、ATSに示されるATC時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が48Mbit以下であるかを判定する。
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応するデコーダに供給する場合でも、1秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、PiPアプリケーションを、効率的に作成することができる。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的
であり、実施する者の主観によることは留意されたい。
(In＿Time、Out＿Time)
図２７では、TS1の最後のVideo Presentation UnitをpreviousPlayItemのOut＿Timeとして選び、TS2の最初のVideoPresentation UnitをpreviousPlayItem、previousSubPlayItemのIn＿Timeとして選んだが、TS1の途中のVideoPresentation UnitをpreviousPlayItemのOut＿Timeとして選び、TS2の途中のVideo Presentation UnitをカレントPlayItem、カレントSubPlayItemのIn＿Timeとして選んでもよい。この場合、PlayItem、カレントSubPlayItemは、シームレスに接続することができず、CC=1,SP＿CC=1として接続せねばならない。
(PlayList情報全体)
2つのPlayItem間をCC＝5で接続しようとする場合、1つのPlayList情報に属する全てのPlayItem情報、全てのSubPlayItem情報は、CC＝5として接続せねばならない。
(デコーダへのデータ供給量)
Out＿of＿MUXにおいて、デコーダへのデータ供給量は必ずしも大きくなる訳ではない。例えば、プライマリオーディオストリームがMainClipであり、CBRのDD(DolbyDigital)と、VBRのMLPとから構成されていて、このMLPが、ローカルストレージから供給されたCBRのDDに置き換えられるものとする。この場合、デコーダへのデータ供給量はかえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。
(再生時間差)
CC＝5、SP＿CC=5を実現するにあたって、１つのPlayItemの中での各ビデオストリーム/オーディオストリームの再生時間差も小さいことが望ましい。この差もビデオ１フレーム分（1/60〜1/25秒）としても良いし、１秒以下などとしても良いし、全体の再生時間に対する割合（１％以下など）であっても良いし、これら２つを組み合わせたものであっても良い。１つのSubPlayItemの中での各ビデオ/オーディオエレメンタリストリームの再生時間差も同様である。
１つのPIDに、2つのエレメンタリストリームを格納するケースにおいては、同一PIDで格納される２つのストリームの再生時間長の差は、どちらか再生時間が短いストリームの方の最小再生単位（１フレーム）の再生時間長未満であることが望ましい。かかるケースに該当するのは、Dolby Digital（AC-3）と、MLP（MeridianLossless Packing）とが、1つのエレメンタリストリームに格納されて、BD-ROMに記録される場合である。
(追加コンテンツに対する処理)
ローカルストレージ２００にダウンロードされた追加コンテンツは、何ヶ月、何年か経過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
（PIDの代用）
オーディオミキシングアプリケーションの実現時において、プライマリオーディオストリーム、セカンダリオーディオストリームの区別にPIDを用いたが、MPEG2-PSを使う場合には、PESパケットヘッダのstream＿idをそれぞれ異なるものにするのが望ましい。
またプライマリオーディオストリーム、セカンダリオーディオストリームは、２つの音声ストリームが１つのデマルチプレクサでも弁別可能なように、システムストリームレベルにおいて区別されていればよい。もしくは、２つのストリームを１つに束ねる前に、片方の
PIDを重複しないように付け替えておくだけでもよい。
（プリロード）
クリック音のためのオーディオデータ（ファイルsound.bdmv）のプリロードは、BD-ROMのローディング時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、機器の応答性を高めAVClip再生が途切れにくくすることができる。
(Java（登録商標）プラットフォーム)
各実施形態にかかる再生装置に、JAVA（登録商標）2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、GloballyExecutable MHP specification(GEM1.0.2)for package media targetsとをフル実装することでJava（登録商標）プラットフォームを構成し、BD-Jアプリケーションを再生装置に実行させてもよい。そしてこのアプリケーションの実行にあたって、Out＿of＿MUXフレームワークを再生装置に実行させてもよい。
（タイトル）
BD-ROMの装填やユーザ操作、装置の状態に応じてタイトルを選択する“モジュールマネージャ”を再生装置に設けるのが望ましい。BD-ROM再生装置内のデコーダは、この“モジュールマネージャ”によるタイトル選択に応じて、プレイリスト情報に基づくAVClipの再生を行う。
アプリケーションマネージャは、“モジュールマネージャ”がタイトルの選択を行った際、前のタイトルに対応するアプリケーション管理テーブル(AMT)と、カレントタイトルに対応するAMTとを用いてシグナリングを実行する。このシグナリングは、前のタイトルに対応するAMTには記載されているが、カレントタイトルに対応するAMTには記載されていないアプリケーションの動作を終了させ、前のタイトルに対応するAMTには記載されておらず、カレントタイトルに対応するAMTには記載されているアプリケーションの動作を開始させるという制御を行う。
(ローカルストレージ内のディレクトリ構成)
各実施形態に示したローカルストレージ内の各領域は、BD-ROMにおけるディスクルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、このBD-ROMを作成した作成者が、ルート認証局から配布を受けたルート証明書を、BD-ROMに割り当てたものである。ディスクルート証明書はたとえばX.509の形式で符号されている。X.509の仕様は国際電信電話諮問委員会より発行されており、CCITTRecommendation X.509 (1988), "The Directory - AuthenticationFramework"に記載されている。
また、BD-ROM、ローカルストレージの記録内容は、Advancend Access Content System(AACS)にて暗号化され、署名情報が付されて、利用権限が、パーミッションファイルに規定されているのが望ましい。
（実装すべきパッケージ）
BD-ROM再生装置を、Java（登録商標）プラットフォームとして実施するにあたっては、以下のBD-J Extentionを再生装置に実装するのが望ましい。BD-JExtentionは、GEM[1.0.2]を越えた機能を、Java（登録商標）プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-JExtentionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java（登録商標） Media FrameWorkに追加すべき、特殊機能を提供する。アングル、音声、字幕の選択についての制御が、このパッケージに追加される。
・org.bluray.ti
このパッケージは、GEM[1.0.2]における“サービス”を“タイトル”にマップして動作するためのAPIや、BD-ROMからタイトル情報を問い合わせる機構や新たなタイトルを選択する機構を含む。
・org.bluray.application
このパッケージは、アプリケーションの生存区間を管理するためのAPIを含む。また、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問い合わせるAPIを含む。
・org.bluray.ui
このパッケージは、BD-ROMに特化されたキーイベントのための定数を定義し、映像再生との同期を実現するようなクラスを含む。
・org.bluray.vfs
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、BD-ROMに記録されたコンテンツ(on-discコンテンツ)と、BD-ROMに記録されていないLocalStorage上のコンテンツ(off-discコンテンツ)とをバインドする機構(Binding Scheme)を提供する。
Binding Schemeとは、BD-ROM上のコンテンツ(AVClip、字幕、BD-Jアプリケーション)と、Local Storage上の関連コンテンツとを関連付けるものである。このBindingSchemeは、コンテンツの所在に拘らず、シームレス再生を実現する。
（Virtual Package）
Virtual Packageを生成させるような処理をBD-ROM再生装置に行わせてもよい。これは、再生装置がVirtual Package情報を生成することでなされる。VirtualPackage情報とは、BD-ROMにおけるボリューム管理情報を拡張した情報である。ここでボリューム管理情報は、ある記録媒体上に存在するディレクトリ−ファイル構造を規定する情報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管理情報とからなる。VirtualPackage情報とは、BD-ROMのディレクトリ−ファイル構造を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、BD-ROMにおけるディレクトリ−ファイル構造の拡張を図ったものである。
(制御手順の実現)
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。
・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。
本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
本発明に係るプログラムは、以下のようにして使用することができる。本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム(BIOS)や、様々なミドルウェア(オペレーションシステム)と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。
再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム(BIOS)が命令ROMに組み込まれており、様々なミドルウェア(オペレーションシステム)が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、再生装置に設けられている。この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、1つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、1つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。
ハードディスクモデルの再生装置では、本発明のプログラムを1つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。

(コントローラ２２)
コントローラ２２は、一個のシステムLSIとして実現することができる。
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
システムLSIにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。
各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。
具体的な実装については、SoC実装やSiP実装を用いることが望ましい。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(Systemin Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
さらに、各記録再生装置の構成要素の一部又は全てを1つのチップとして構成してもよい。集積回路化は、上述したSoC実装,SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（FieldProgrammable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
本発明に係る記録媒体の、使用行為についての形態を示す図である。 BD-ROMの内部構成を示す図である。 拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。 PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示す図である。 ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示す図である。 トランスポートストリームの詳細を示す図である。 PAT、PMTパケットの内部構成を示す図である。 AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。 Aligned Unitの内部構成を示す図である。 Clip情報の内部構成を示す図である。 映画のビデオストリームに対するEP＿map設定を示す図である。 PlayList情報のデータ構造を示す図である。 AVClipと、PlayList情報との関係を示す図である。 ローカルストレージ２００の内部構成を示す図である。 Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSがBD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。 PlayList情報のデータ構造を示す図である。 Subpath情報の内部構成をクローズアップして示す図である。 ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。 （ａ）STN＿tableの内部構成を示す図である。 （ｂ）ビデオストリームに対応したStream＿attributeを示す図である。 （ｃ）オーディオストリームに対応したStream＿attributeを示す図である。 （ｄ）ビデオストリームにおけるStream＿entryを示す図である。 BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。 （ａ）〜（ｄ）Windowのシフトを示す図である。 BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。 （ａ）（ｂ）各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。 Out＿of＿MUXアプリケーションを構成するPlayItem、SubPlayItemの接続状態を示す図である。 図２４に示した、PlayItemのconnection＿condition情報、SubPlayItemのsp＿connection＿condition情報が“＝5”に設定されている場合の、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとの関係を示す図である。 PlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値を示す。 previousPlayItemにて参照されているMainClip、カレントPlayItemにて参照されているSubClipにおいて、TS1、TS2がどのように特定されるかを示す図である。 CC＝5、及び、SP＿CC＝5の詳細を示す図である。 previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudioPresentation Unitと、STC時間軸との関係を示す図である。 本発明に係る再生装置の内部構成を示す図である。 PlayList情報に基づく再生手順のフローチャートである。 SubPlayItemにおけるシームレス接続を示すフローチャートである。 第２実施形態にかかるオーサリングシステムの内部構成を示す図である。 プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。 同種のエレメンタリストリームが複数存在する場合の、プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。 CC=6の詳細な説明を示す図である。 PlayItemとSubPlayItemの相関を示した図である。 ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的に示す図である。 オーディオに加えて、字幕（PG）やメニュー（IG）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。 オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。 第５実施形態に係る再生装置の内部構成を示す図である。 オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。 劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す図である。
符号の説明
１a BD-ROMドライブ
１b,c リードバッファ
１b,a,c ATCカウンタ
２a,d Source Depacketizer
２c,d ATCカウンタ
３a,c STCカウンタ
３b,d PID Filter
４ ビデオデコーダ
５ ビデオプレーン
６ Transport Buffer
７ Elementary Buffer
８ オーディオデコーダ
１０a,b,c,d スイッチ
１１ Interactive Graphicsデコーダ
１２ Interactive Graphicsプレーン
１３ Presentation Graphicsデコーダ
１４ Presentation Graphicsプレーン
１７ 合成部
２１ メモリ
２２ コントローラ
２３ PSRセット
２４ PID変換部
２５ ネットワーク部
２６ 操作受付部
１００ BD-ROM
２００ ローカルストレージ
３００ 再生装置
４００ テレビ
５００ AVアンプ

Claims (11)

  1. プレイリスト情報が記録された記録媒体であって、
    前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
    前記メインパス情報は、
    複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
    前記サブパス情報は、
    複数デジタルストリームの残りのうち1つのデジタルストリームを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
    前記メインパス情報はストリームテーブルを含み、
    前記ストリームテーブルは、
    メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
    ストリームテーブルは、複数のストリームエントリーを含み、各ストリームエントリーには、前記エレメンタリストリームを構成するTSパケットであって、同時再生が許可されているもののパケット識別子が記載されており、
    前記メインストリーム及びサブストリームは、TSパケット列であり、各TSパケットにはアライバルタイムスタンプが付加されており、
    複数のTSパケットであってストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを構成するものの単位時間当たりの総データサイズは、48Mビット以下であり、
    単位時間当たりの総データサイズは、アライバルタイムクロック時間軸上において、１秒の時間幅をもつ確認枠であるウィンドゥによって囲まれる範囲内で算出され、当該ウィンドゥの開始点が、アライバルタイムクロック時間軸における何れの時点に存在したとしても、ウィンドゥによって囲まれる範囲内の総データサイズが48Mビット以下になっている
    ことを特徴とする記録媒体。
  2. 前記サブストリームを構成するTSパケットに付加されたアライバルタイムスタンプと、前記メインストリームを構成するTSパケットに付加されたアライバルタイムスタンプとは、アライバルタイムクロック時間軸において、オーバーラップが生じている
    ことを特徴とする請求項１記載の記録媒体。
  3. 前記メインストリーム及びサブストリームは、ビットレートのベリファイを、複数のアライバルタイムスタンプで示される各座標上で実行した上で、記録されており、
    前記ベリファイは、
    メインストリーム及びサブストリームを構成するTSパケットのうち、最初のものに付加されたアライバルタイムスタンプの時刻に、ウィンドゥの始点が存在する状態を初期状態とし、
    メインストリーム及びサブストリームを構成するTSパケットのうち、最後のものに付加されたアライバルタイムスタンプの時刻に、ウィンドゥの終点が到達した状態を最終状態として、
    初期状態から最終状態になるまで、ウィンドゥの始点及び終点の座標を複数のアライバルタイムスタンプで示される各座標上で移動させてゆき、その移動の度に、このウィンドゥ内に包含されるTSパケットサイズの総和が、４８Ｍビット以下になることを確認するという作業である、請求項１記載の記録媒体。
  4. TSパケットサイズの総和は、ストリーム番号テーブルにおいて同時再生が許可されているそれぞれのエレメンタリストリームから、TSパケットの最大ビットレートを選び、選ばれた最大ビットレートを合計することで算出される
    ことを特徴とする請求項１記載の記録媒体。
  5. プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生装置であって、
    前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
    前記メインパス情報は、
    複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
    前記サブパス情報は、
    複数デジタルストリームの残りのうち1つのデジタルストリームを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
    前記メインパス情報はストリームテーブルを含み、
    前記ストリームテーブルは、
    メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
    前記ストリームテーブルは、複数のストリームエントリーを含み、各ストリームエントリーには、前記エレメンタリストリームを構成するTSパケットであって、同時再生が許可されているもののパケット識別子が記載されており、
    前記メインストリーム及びサブストリームは、TSパケット列であり、各TSパケットにはアライバルタイムスタンプが付加されており、
    第１記録媒体に記録されているメインストリームのうち、主たる再生区間に対応する部分を構成するTSパケットを、メインパス情報に従って読み出す第１読出部と、
    第２記録媒体に記録されているサブストリームのうち、従たる再生区間に対応する部分を構成するTSパケットを、サブパス情報に従って読み出す第２読出部と、
    第１読出部及び第２読出部によって読み出されたTSパケットのうち、プレイリスト情報におけるストリーム番号テーブルで再生許可されているものを選んで、選ばれたTSパケットを第１デコーダ及び第２デコーダに出力する第１及び第２フィルタ部と、
    第１読出部及び第２読出部から第１及び第２フィルタ部へのTSパケット出力を、各TSパケットに付加されたアライバルタイムスタンプに示される時点に実行する第１及び第２ソースデパケッタイザとを備え、
    複数のTSパケットであって、ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを構成するものの単位時間当たりの総データサイズは、48Mビット以下であり、
    単位時間当たりの総データサイズは、アライバルタイムクロック時間軸上において、１秒の時間幅をもつ確認枠であるウィンドゥによって囲まれる範囲内で算出され、当該ウィンドゥの開始点が、アライバルタイムクロック時間軸における何れの時点に存在したとしても、ウィンドゥによって囲まれる範囲内の総データサイズが48Mビット以下になっている
    ことを特徴とする再生装置。
  6. 第１記録媒体は、読出専用の光ディスクであり、第２記録媒体は、書換可能な記録媒体であり、
    前記サブストリームは、プレイリスト情報と共に、書換可能な記録媒体の所定の領域に記録されており、
    前記所定の領域とは、読出専用型の光ディスクとの組合せで、仮想的なパッケージを構築するために、読出専用型の光ディスクと関連付けられた領域であり、
    前記第１読出部及び第２読出部は、読出専用の記録媒体からのTSパケットの読み出しと、書換可能な記録媒体からのTSパケットの読み出しとを同時に実行する
    ことを特徴とする請求項５記載の再生装置。
  7. サブストリームを構成するTSパケットに付加されたアライバルタイムスタンプと、メインストリームを構成するTSパケットに付加されたアライバルタイムスタンプとは、アライバルタイムクロック時間軸において、オーバーラップが生じており、
    第１及び第２ソースデパケッタイザから第１及び第２フィルタ部へのTSパケットの出力は、アライバルタイムスタンプに示される時間軸上の座標に基づきなされる
    ことを特徴とする請求項５記載の再生装置。
  8. 前記メインストリーム及びサブストリームは、ビットレートのベリファイ作業を、複数のアライバルタイムスタンプで示される各座標上で実行した上で、記録されており、
    前記ベリファイは、
    メインストリーム及びサブストリームを構成するTSパケットのうち、最初のものに付加されたアライバルタイムスタンプに示される時刻に、ウィンドゥの始点が存在する状態を初期状態とし、
    メインストリーム及びサブストリームを構成するTSパケットのうち、最後のものに付加されたアライバルタイムスタンプに示される時刻に、ウィンドゥの終点が到達した状態を最終状態として、
    初期状態から最終状態になるまで、ウィンドゥの始点及び終点を、複数のアライバルタイムスタンプで示される各座標に移動させてゆき、その移動の度に、このウィンドゥ内に包含されるTSパケットサイズの総和が、４８Ｍビット以下になることを確認するという作業である、請求項５記載の再生装置。
  9. TSパケットサイズの総和は、ストリーム番号テーブルにおいて同時再生が許可されているそれぞれのエレメンタリストリームから、TSパケットの最大ビットレートを選び、選ばれた最大ビットレートを合計することで算出される
    ことを特徴とする請求項５記載の再生装置。
  10. アプリケーションデータを記録媒体に記録する記録方法であって、
    アプリケーションデータを生成するステップ、
    アプリケーションデータが書き込まれた記録媒体を得るステップを備え、
    アプリケーションデータは、プレイリスト情報と、デジタルストリームとを含み、
    前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
    前記メインパス情報は、
    複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
    前記サブパス情報は、
    複数デジタルストリームの残りのうち1つのデジタルストリームを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
    前記メインパス情報はストリームテーブルを含み、
    前記ストリームテーブルは、
    メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
    前記ストリームテーブルは、複数のストリームエントリーを含み、各ストリームエントリーには、前記エレメンタリストリームを構成するTSパケットであって、同時再生が許可されているもののパケット識別子が記載されており、
    前記メインストリーム及びサブストリームは、TSパケット列であり、各TSパケットにはアライバルタイムスタンプが付加されており、
    複数のTSパケットであって、ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを構成するものの単位時間当たりの総データサイズは、48Mビット以下であり、
    単位時間当たりの総データサイズは、アライバルタイムクロック時間軸上において、１秒の時間幅をもつ確認枠であるウィンドゥによって囲まれる範囲内で算出され、当該ウィンドゥの開始点が、アライバルタイムクロック時間軸における何れの時点に存在したとしても、ウィンドゥによって囲まれる範囲内の総データサイズが48Mビット以下になっている
    ことを特徴とする記録方法。
  11. プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生方法であって、
    前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
    前記メインパス情報は、
    複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
    前記サブパス情報は、
    複数デジタルストリームの残りのうち1つのデジタルストリームを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
    前記メインパス情報はストリームテーブルを含み、
    前記ストリームテーブルは、
    メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
    前記ストリームテーブルは、複数のストリームエントリーを含み、各ストリームエントリーには、前記エレメンタリストリームを構成するTSパケットであって、同時再生が許可されているもののパケット識別子が記載されており、
    前記メインストリーム及びサブストリームは、TSパケット列であり、各TSパケットにはアライバルタイムスタンプが付加されており、
    第１記録媒体に記録されているメインストリームのうち、主たる再生区間に対応する部分を構成するTSパケットを、メインパス情報に従って読み出す第１読出ステップと、
    第２記録媒体に記録されているサブストリームのうち、従たる再生区間に対応する部分を構成するTSパケットを、サブパス情報に従って読み出す第２読出ステップと、
    第１読出ステップ及び第２読出ステップによって読み出されたTSパケットのうち、プレイリスト情報におけるストリーム番号テーブルで再生許可されているものを選んで、選ばれたTSパケットを第１デコードステップ及び第２デコードステップに出力する第１及び第２フィルタステップと、
    第１読出ステップ及び第２読出ステップからのTSパケット出力を、各TSパケットに付加されたアライバルタイムスタンプに示される時点に実行する第１及び第２ソースデパケッタイズステップとを備え、
    複数のTSパケットであって、ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを構成するものの単位時間当たりの総データサイズは、48Mビット以下であり、
    単位時間当たりの総データサイズは、アライバルタイムクロック時間軸上において、１秒の時間幅をもつ確認枠であるウィンドゥによって囲まれる範囲内で算出され、当該ウィンドゥの開始点が、アライバルタイムクロック時間軸における何れの時点に存在したとしても、ウィンドゥによって囲まれる範囲内の総データサイズが48Mビット以下になっている
    ことを特徴とする再生方法。
JP2007512969A 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法 Active JP4414460B2 (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
JP2005111427 2005-04-07
JP2005111428 2005-04-07
JP2005111429 2005-04-07
JP2005111425 2005-04-07
JP2005111428 2005-04-07
JP2005111427 2005-04-07
JP2005111426 2005-04-07
JP2005111425 2005-04-07
JP2005111429 2005-04-07
JP2005111426 2005-04-07
PCT/JP2006/307441 WO2006109716A1 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法

Publications (2)

Publication Number Publication Date
JPWO2006109716A1 JPWO2006109716A1 (ja) 2008-11-13
JP4414460B2 true JP4414460B2 (ja) 2010-02-10

Family

ID=37086991

Family Applications (5)

Application Number Title Priority Date Filing Date
JP2007512969A Active JP4414460B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法、再生方法
JP2007512970A Active JP4676492B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法
JP2007512971A Active JP4676493B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法
JP2010241824A Expired - Fee Related JP4944237B2 (ja) 2005-04-07 2010-10-28 記録媒体、再生装置、記録方法
JP2010241823A Expired - Fee Related JP4774469B2 (ja) 2005-04-07 2010-10-28 記録媒体、再生装置、記録方法

Family Applications After (4)

Application Number Title Priority Date Filing Date
JP2007512970A Active JP4676492B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法
JP2007512971A Active JP4676493B2 (ja) 2005-04-07 2006-04-07 記録媒体、再生装置、記録方法
JP2010241824A Expired - Fee Related JP4944237B2 (ja) 2005-04-07 2010-10-28 記録媒体、再生装置、記録方法
JP2010241823A Expired - Fee Related JP4774469B2 (ja) 2005-04-07 2010-10-28 記録媒体、再生装置、記録方法

Country Status (9)

Country Link
US (5) US7991270B2 (ja)
EP (3) EP1873773B1 (ja)
JP (5) JP4414460B2 (ja)
KR (1) KR101268327B1 (ja)
CN (2) CN102005228B (ja)
BR (1) BRPI0607028A2 (ja)
CA (1) CA2602713C (ja)
TW (1) TWI393124B (ja)
WO (3) WO2006109717A1 (ja)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102005228B (zh) * 2005-04-07 2013-04-10 松下电器产业株式会社 记录方法和再现装置
US20070250323A1 (en) * 2006-04-21 2007-10-25 Ivan Dimkovic Apparatus and Method for Encoding and Decoding Plurality of Digital Data Sets
JP4779797B2 (ja) 2006-05-10 2011-09-28 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4552889B2 (ja) * 2006-05-10 2010-09-29 ソニー株式会社 記録装置、記録方法および記録プログラム、ならびに、撮像装置および撮像方法
JP4690965B2 (ja) * 2006-08-11 2011-06-01 株式会社東芝 データ記録再生装置
KR101034832B1 (ko) * 2006-11-16 2011-05-17 후지쯔 세미컨덕터 가부시키가이샤 Ｇｏｐ간 관리 장치
JP2008199527A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
JP2008199528A (ja) * 2007-02-15 2008-08-28 Sony Corp 情報処理装置および情報処理方法、プログラム、並びに、プログラム格納媒体
JP4321628B2 (ja) 2007-05-31 2009-08-26 ソニー株式会社 記憶装置、記憶方法および記憶プログラム、ならびに、データ処理装置、データ処理方法およびデータ処理プログラム
JP4750759B2 (ja) * 2007-06-25 2011-08-17 パナソニック株式会社 映像音声再生装置
KR100933003B1 (ko) * 2008-06-20 2009-12-21 드리머 Ｂｄ-ｊ 기반 채널 서비스 제공 방법 및 이를 실현시키기위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체
RU2502214C2 (ru) * 2008-09-30 2013-12-20 Панасоник Корпорэйшн Носитель записи, устройство воспроизведения, системная бис, способ воспроизведения, очки и устройство отображения для трехмерных изображений
JP4574748B2 (ja) * 2009-02-19 2010-11-04 パナソニック株式会社 記録媒体、再生装置、記録方法、記録媒体再生システム
CA2762385C (en) * 2009-05-18 2018-11-20 Koninklijke Philips Electronics N.V. Entry points for 3d trickplay
CN102227915B (zh) * 2009-05-25 2015-01-14 松下电器产业株式会社 再生装置、集成电路、再生方法
US8332529B1 (en) * 2009-05-29 2012-12-11 Adobe Systems Incorporated Media content including introduced code
JP4984181B2 (ja) * 2009-06-22 2012-07-25 ソニー株式会社 再生装置および再生方法
MX2011002003A (es) * 2009-07-10 2011-03-29 Panasonic Corp Medio de grabacion, dispositivo de reproduccion y circuito integrado.
US9131203B2 (en) 2009-09-30 2015-09-08 Sharp Kabushiki Kaisha Information recording medium, reproduction method and recording method using information recording medium, information recording/reproduction device, and 3D conversion unit and information recording device
JP2011151784A (ja) * 2009-12-25 2011-08-04 Panasonic Corp 動画像多重化装置、映像音声記録装置及び動画像多重化方法
KR20120028546A (ko) * 2010-09-15 2012-03-23 삼성전자주식회사 전송 스트림에 대한 트릭 모드 제어 방법 및 이를 수행하는 전송 스트림 전송 장치
US8989280B2 (en) * 2011-06-30 2015-03-24 Cable Television Laboratories, Inc. Frame identification
US20130084053A1 (en) * 2011-10-04 2013-04-04 Utc Fire & Security Corporation System to merge multiple recorded video timelines
US20130336379A1 (en) * 2012-06-13 2013-12-19 Divx, Llc System and Methods for Encoding Live Multimedia Content with Synchronized Resampled Audio Data
KR20140029991A (ko) * 2012-08-31 2014-03-11 삼성전자주식회사 프로그래시브 플레이리스트 재생 장치 및 재생 방법, 기록 장치 및 기록 방법, 이를 위한 정보저장매체
EP2946469B1 (en) 2013-01-21 2017-03-15 Dolby Laboratories Licensing Corporation System and method for optimizing loudness and dynamic range across different playback devices
US9883136B2 (en) 2013-04-30 2018-01-30 Dolby Laboratories Licensing Corporation System and method of outputting multi-lingual audio and associated audio from a single container
TWM487509U (zh) * 2013-06-19 2014-10-01 杜比實驗室特許公司 音訊處理設備及電子裝置
US10095468B2 (en) 2013-09-12 2018-10-09 Dolby Laboratories Licensing Corporation Dynamic range control for a wide variety of playback environments
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US20200210855A1 (en) * 2018-12-28 2020-07-02 Robert Bosch Gmbh Domain knowledge injection into semi-crowdsourced unstructured data summarization for diagnosis and repair
US11947696B2 (en) * 2021-07-16 2024-04-02 EMC IP Holding Company LLC File system content obfuscation in high security environments

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0385972A (ja) 1989-08-30 1991-04-11 Toshiba Corp ディジタル撮像方法及びその装置
US5448440A (en) 1994-06-16 1995-09-05 Minnesota Mining And Manufacturing Company Data storage device with roller lubricant that provides excellent drag force characteristics
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
JP2002093125A (ja) * 1997-09-17 2002-03-29 Matsushita Electric Ind Co Ltd 光ディスク、ビデオデータ編集装置、編集プログラムを記録したコンピュータ読み取り可能な記録媒体、光ディスクの再生装置、再生プログラムを記録したコンピュータ読み取り可能な記録媒体
CN1309252C (zh) 1997-09-17 2007-04-04 松下电器产业株式会社 将视频数据记录在光盘的设备和方法
JP3997367B2 (ja) * 1998-04-30 2007-10-24 ソニー株式会社 記録再生装置および方法、並びに記録媒体
ES2273523T3 (es) 1998-12-14 2007-05-01 Koninklijke Philips Electronics N.V. Soporte de grabacion y aparato y metodo para reproducir un soporte de grabacion, y metodo de fabricacion de un soporte de grabacion.
US7236687B2 (en) 2000-04-21 2007-06-26 Sony Corporation Information processing apparatus and method, program, and recording medium
JP4682434B2 (ja) * 2000-04-21 2011-05-11 ソニー株式会社 情報処理装置および方法、記録媒体、並びにプログラム
EP1198133A4 (en) 2000-04-21 2004-10-06 Sony Corp INFORMATION PROCESSING DEVICE AND METHOD, PROGRAM AND RECORDED MEDIUM
WO2001082611A1 (fr) * 2000-04-21 2001-11-01 Sony Corporation Procede et appareil de traitement d'informations, support enregistre, et programme
RU2270485C2 (ru) 2001-03-08 2006-02-20 Сони Корпорейшн Устройство записи данных (варианты), способ записи данных (варианты), носитель записи (варианты), устройство воспроизведения данных (варианты), способ воспроизведения данных (варианты), устройство редактирования данных (варианты), способ редактирования данных (варианты)
WO2003085972A1 (fr) 2002-04-10 2003-10-16 Sony Corporation Dispositif d'enregistrement de donnees, support de memoire de programme et programme
KR100582953B1 (ko) * 2002-06-05 2006-05-23 엘지전자 주식회사 기록매체의 기록 스트림 관리방법
CN101197168A (zh) 2002-08-30 2008-06-11 富士通株式会社 存储装置
JP4348920B2 (ja) 2002-09-24 2009-10-21 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体
AU2003268656A1 (en) 2002-09-25 2004-04-19 Matsushita Electric Industrial Co., Ltd. Reproduction device, optical disc, recording medium, program, and reproduction method
JP3717880B2 (ja) 2002-10-01 2005-11-16 パイオニア株式会社 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
EP1408505A1 (en) 2002-10-11 2004-04-14 Deutsche Thomson-Brandt Gmbh Method and apparatus for synchronizing data streams containing audio, video and/or other data
US7929825B2 (en) * 2002-11-28 2011-04-19 Panasonic Corporation Data processing device
MY141419A (en) * 2003-01-20 2010-04-30 Lg Electronics Inc Recording medium having data structure for managing reproduction of still pictures recorded thereon and recording and reproducing methods and apparatuses
KR100920655B1 (ko) * 2003-03-03 2009-10-09 엘지전자 주식회사 고밀도 광디스크의 스틸 픽처 관리방법
JP3657946B2 (ja) 2003-03-25 2005-06-08 株式会社東芝 情報記録媒体、情報記録／再生方法、および情報記録／再生装置
EP1677532B1 (en) * 2003-06-18 2011-08-31 Panasonic Corporation Playback apparatus, recording medium, program, and playback method
EP2068563B1 (en) * 2003-06-30 2010-11-10 Panasonic Corporation Recording medium, reproduction device, recording method, program, and reproduction method
WO2005015907A1 (ja) 2003-08-08 2005-02-17 Matsushita Electric Industrial Co., Ltd. データ処理装置及びデータ処理方法
KR20050036277A (ko) * 2003-10-15 2005-04-20 엘지전자 주식회사 고밀도 광디스크의 네비게이션 정보 관리방법
KR20050066264A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
EP1728251A1 (en) * 2004-03-17 2006-12-06 LG Electronics, Inc. Recording medium, method, and apparatus for reproducing text subtitle streams
RU2376659C2 (ru) * 2004-03-26 2009-12-20 ЭлДжи ЭЛЕКТРОНИКС ИНК. Носитель записи и способ и устройство для воспроизведения потока текстовых субтитров, записанного на носителе записи
EP2270805A3 (en) * 2004-07-22 2011-01-26 Panasonic Corporation Playback apparatus for performing application-synchronized playback
EP1787297A1 (en) 2004-08-17 2007-05-23 LG Electronics Inc. Method and apparatus of reproducing data recorded on recording medium and local storage
CN102005228B (zh) * 2005-04-07 2013-04-10 松下电器产业株式会社 记录方法和再现装置

Also Published As

Publication number Publication date
WO2006109718A1 (ja) 2006-10-19
CA2602713C (en) 2014-05-13
CN102034513A (zh) 2011-04-27
CN102005228B (zh) 2013-04-10
CN102034513B (zh) 2013-04-17
US7991270B2 (en) 2011-08-02
EP1873775A4 (en) 2009-10-14
US20090154904A1 (en) 2009-06-18
US20090097821A1 (en) 2009-04-16
JP4774469B2 (ja) 2011-09-14
US8059942B2 (en) 2011-11-15
EP1873773B1 (en) 2011-11-30
EP1873773A4 (en) 2009-10-14
EP1873776B1 (en) 2011-11-30
US20120002943A1 (en) 2012-01-05
WO2006109716A1 (ja) 2006-10-19
JPWO2006109718A1 (ja) 2008-11-13
US20090185791A1 (en) 2009-07-23
TWI393124B (zh) 2013-04-11
CN102005228A (zh) 2011-04-06
JP4676492B2 (ja) 2011-04-27
JP4944237B2 (ja) 2012-05-30
WO2006109717A1 (ja) 2006-10-19
US8548298B2 (en) 2013-10-01
EP1873773A1 (en) 2008-01-02
JP4676493B2 (ja) 2011-04-27
US8116613B2 (en) 2012-02-14
TW200703250A (en) 2007-01-16
US20120106926A1 (en) 2012-05-03
JPWO2006109717A1 (ja) 2008-11-13
BRPI0607028A2 (pt) 2009-07-28
EP1873776A1 (en) 2008-01-02
JP2011081897A (ja) 2011-04-21
JPWO2006109716A1 (ja) 2008-11-13
JP2011090771A (ja) 2011-05-06
EP1873775A1 (en) 2008-01-02
KR20070121813A (ko) 2007-12-27
KR101268327B1 (ko) 2013-05-28
EP1873776A4 (en) 2009-09-30
CA2602713A1 (en) 2006-10-19

Similar Documents

Publication Publication Date Title
JP4414460B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4268661B2 (ja) 再生装置、プログラム、再生方法、記録方法。
US7844355B2 (en) Stream reproduction device and stream supply device
CN101156209B (zh) 记录媒体、再现装置、记录方法、再现方法
JPWO2007119765A1 (ja) 記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム
RU2415483C2 (ru) Устройство воспроизведения

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090406

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090406

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20090701

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20090730

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090811

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091005

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

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

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

Free format text: PAYMENT UNTIL: 20121127

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4414460

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20131127

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20131127

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20141127

Year of fee payment: 5