JP4984195B2 - 再生装置、再生方法、および記録方法 - Google Patents

再生装置、再生方法、および記録方法 Download PDF

Info

Publication number
JP4984195B2
JP4984195B2 JP2012029503A JP2012029503A JP4984195B2 JP 4984195 B2 JP4984195 B2 JP 4984195B2 JP 2012029503 A JP2012029503 A JP 2012029503A JP 2012029503 A JP2012029503 A JP 2012029503A JP 4984195 B2 JP4984195 B2 JP 4984195B2
Authority
JP
Japan
Prior art keywords
stream
file
chunk
spn
view video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012029503A
Other languages
English (en)
Other versions
JP2012138927A (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.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2012029503A priority Critical patent/JP4984195B2/ja
Publication of JP2012138927A publication Critical patent/JP2012138927A/ja
Application granted granted Critical
Publication of JP4984195B2 publication Critical patent/JP4984195B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Television Signal Processing For Recording (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本発明は、再生装置、再生方法および記録方法に関し、特に、記録媒体から、3D(Dimension)画像のコンテンツを適切に再生することができるようにした再生装置、再生方法および記録方法に関する。
例えば、映画等のコンテンツとしては、2次元(2D)画像のコンテンツが主流であるが、最近では、立体視が可能な3次元(3D)画像(グラフィック)のコンテンツが注目を集めている。
3D画像(以下、ステレオ画像ともいう)の表示の方式としては、種々の方式があるが、いずれの方式を採用する場合であっても、3D画像のデータ量は、2D画像のデータ量よりも大になる。
また、映画等の、高解像度の画像のコンテンツは、大容量であることもあり、そのような大容量の画像のコンテンツを、データ量の多い3D画像として記録するには、大容量の記録媒体が必要である。
そのような大容量の記録媒体としては、例えば、BD(Blu-Ray(登録商標))-ROM(Read Only Memory)等のBlu-Ray(登録商標) Disc(以下、BDともいう)がある。
ここで、フアイル化手段により信号の記録媒体における記録位置をセクタよりも小さい所定単位で指定してフアイル化するようにしたことにより、フアイル化した信号を任意の位置で分割又は結合するような編集処理でも、当該信号の編集対象部分のみをフアイル化するように記録媒体に記録しなおす必要がなく、フアイル管理情報上のみで編集処理することができ、かくして編集処理を格段的に簡易化させ得るフアイル管理装置が提案されている(特許文献1)。
特開平11−195287号公報
ところで、現行のBDの規格では、3D画像のコンテンツを、BDに、どのように記録し、また、再生するかは、規定されていない。
しかしながら、3D画像のコンテンツの記録や再生の仕方を、3D画像のコンテンツのオーサリングを行うオーサ(author)に委ねてしまうと、3D画像のコンテンツを適切に再生することができなくなるおそれがある。
本技術は、このような状況に鑑みてなされたものであり、BD等の記録媒体から、ステレオ画像(3D画像)のコンテンツを適切に再生することができるようにするものである。
本技術の一側面の再生装置は、複数視点のビデオストリームを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量の連続配置されるソースパケットの集まりであるエクステント単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームに付随する情報であり、前記第1の多重化ストリームを構成するソースパケットの総数を表す情報、前記多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第1の多重化ストリームの中での開始パケット番号を表す情報を含む第1の情報ファイルと、前記第2の多重化ストリームに付随する情報であり、前記第2の多重化ストリームを構成するソースパケットの総数を表す情報、前記第2の多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第2の多重化ストリームの中での開始パケット番号を表す情報を含む第2の情報ファイルとを前記記録媒体から読み出す読み出し部と、前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームのエクステントと前記第2の多重化ストリームのエクステントに分離する分離部と、前記読み出し部による読み出しを制御する制御部とを備え、前記第1および第2の情報ファイルに含まれる前記エクステントの数を(n+1)とし、前記第1の多重化ストリームを構成するエクステントをB[i](i=0〜n)、前記第1の多重化ストリームの先頭からk番目のエクステントをB[k]と表し、前記第2の多重化ストリームを構成するエクステントをD[i](i=0〜n)、前記第2の多重化ストリームの先頭からk番目のエクステントをD[k]と表し、B[k]の開始パケット番号を、SPN_chunk_start_1[k]と表し、D[k]の開始パケット番号を、SPN_chunk_start_2[k]と表し、前記第1の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets1と表し、前記第2の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets2と表すとき、前記分離部は、k=0〜(n-1)について、B[k]を構成するソースパケットの数を、(SPN_chunk_start_1[k+1] - SPN_chunk_start_1[k])によって計算し、k=0〜(n-1)について、D[k]を構成するソースパケットの数を、(SPN_chunk_start_2[k+1] - SPN_chunk_start_2[k])によって計算し、B[n]を構成するソースパケットの数を、(number_of_source_packets1 - SPN_chunk_start_1[n])によって計算し、D[n]を構成するソースパケットの数を、(number_of_source_packets2 - SPN_chunk_start_2[n])によって計算して、前記第1の多重化ストリームのエクステントと前記第2の多重化ストリームのエクステントを分離し、前記制御部は、前記第1の情報ファイルにさらに含まれる情報であり、前記第1の多重化ストリーム中のエントリーポイントの数と、各エントリーポイントについての、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]と位置を表すソースパケット番号であるSPN_EP_start[i]とを含む情報であるEP_mapを読み出し、前記EP_mapに基づいて、指定された再生開始時刻よりも前の最も近い値を持つPTS_EP_start[m]を検出し、PTS_EP_start[m]に対応するSPN_EP_start[m]を検出し、SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start_1[k]とそのkを検出し、SPN_chunk_start_1[k]とSPN_chunk_start_2[k]の和を、前記インターリーブドファイルの読み出し開始アドレスとして決定する。
前記第1の情報ファイルが有する前記エクステントの数と、前記第2の情報ファイルが有する前記エクステントの数は、等しい数であるようにすることができる。
B[i]とD[i]について、iの値が同じ組のエクステントは同じ再生時間を有するようにすることができる。
前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamであるようにすることができる。
本技術によれば、ステレオ画像(3D画像)のコンテンツを適切に再生することができる。
本技術を適用した再生装置を含む再生システムの構成例を示す図である。 撮影の例を示す図である。 MVCエンコーダの構成例を示すブロック図である。 参照画像の例を示す図である。 TSの構成例を示す図である。 TSの他の構成例を示す図である。 TSのさらに他の構成例を示す図である。 AVストリームの管理の例を示す図である。 Main PathとSub Pathの構造を示す図である。 光ディスクに記録されるファイルの管理構造の例を示す図である。 PlayListファイルのシンタクスを示す図である。 図11のPlayList()のシンタクスを示す図である。 図12のSubPath()のシンタクスを示す図である。 図13のSubPlayItem(i)のシンタクスを示す図である。 図12のPlayItem()のシンタクスを示す図である。 図15のSTN_table()のシンタクスを示す図である。 3D_PlayListの具体例を示す図である。 typeの意味を示す図である。 SubPath_typeの意味を示す図である。 再生装置の構成例を示すブロック図である。 図20のデコーダ部の構成例を示す図である。 3D_PlayListの例を示す図である。 clpiファイルのシンタクスを示す図である。 図22、図23のデータを用いて行われるファイル管理の概念を示す図である。 図22の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 chunk_map()のシンタクスの例を示す図である。 chunk_map()の具体例を示す図である。 チャンクの分離について示す図である。 3D_PlayListの他の例を示す図である。 clpiファイルのシンタクスを示す図である。 図29、図30のデータを用いて行われるファイル管理の概念を示す図である。 図29の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 3D_PlayListのさらに他の例を示す図である。 clpiファイルのシンタクスを示す図である。 図33、図34のデータを用いて行われるファイル管理の概念を示す図である。 図33の3D_PlayListファイルに従って行われる再生処理について説明するフローチャートである。 図27のchunk_map()の内容をまとめて示す図である。 EP_map()のシンタクスを示す図である。 再生装置のランダムアクセス処理について説明するフローチャートである。 ステップS44,S45の処理により特定される位置の例を示す図である。 ステップS46の処理により特定されるSPN_chunk_start[k]を示す図である。 光ディスク上に記録されたAVストリームの構造を示す図である。 Clip AVストリームの例を示す図である。 EP_mapの例を示す図である。 SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。 ソフト製作処理部の構成例を示すブロック図である。 ソフト製作処理部を含む構成の例を示す図である。
[再生システムの構成例]
図1は、本技術を適用した再生装置201を含む再生システムの構成例を示す図である。
図1に示すように、この再生システムは、再生装置201と表示装置203がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置201には、BDなどの光ディスク202が装着される。
光ディスク202には、視点の数が2つのステレオ画像(3D画像)を表示するために必要なストリームが記録されている。
各ストリームのデータは、エクステント単位で、インターリーブされた状態で光ディスク202に記録されている。
再生装置201は、光ディスク202に記録されているストリームの3D再生に対応したプレーヤである。再生装置201は、光ディスク202に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置203に表示させる。音声についても同様に再生装置201により再生され、表示装置203に設けられるスピーカなどから出力される。
光ディスク202には、3D画像を表示することができるようなストリームが記録されている。ストリームを光ディスク202に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)が採用される。
[H.264 AVC/MVC Profile]
H.264 AVC/MVCでは、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCを単にMVCという。
図2は、撮影の例を示す図である。
図2に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
図3は、MVCエンコーダの構成例を示すブロック図である。
図3に示すように、MVCエンコーダ211は、H.264/AVCエンコーダ221、H.264/AVCデコーダ222、Depth算出部223、Dependent view videoエンコーダ224、およびマルチプレクサ225から構成される。
L画像用のカメラにより撮影された映像#1のストリームはH.264/AVCエンコーダ221とDepth算出部223に入力される。また、R画像用のカメラにより撮影された映像#2のストリームはDepth算出部223とDependent view videoエンコーダ224に入力される。映像#2のストリームがH.264/AVCエンコーダ221とDepth算出部223に入力され、映像#1のストリームがDepth算出部223とDependent view videoエンコーダ224に入力されるようにしてもよい。
H.264/AVCエンコーダ221は、映像#1のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ221は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ222とマルチプレクサ225に出力する。
H.264/AVCデコーダ222は、H.264/AVCエンコーダ221から供給されたAVCビデオストリームをデコードし、デコードして得られた映像#1のストリームをDependent view videoエンコーダ224に出力する。
Depth算出部223は、映像#1のストリームと映像#2のストリームに基づいてDepth(視差)を算出し、算出したDepthのデータをマルチプレクサ225に出力する。
Dependent view videoエンコーダ224は、H.264/AVCデコーダ222から供給された映像#1のストリームと、外部から入力された映像#2のストリームをエンコードし、Dependent view videoストリームを出力する。
Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図4に示すように、Dependent view videoには、Base view videoを参照画像とする予測符号化が許されている。例えばL画像をBase view videoとするとともにR画像をDependent view videoとして符号化を行った場合、その結果得られるDependent view videoストリームのデータ量は、Base view videoストリームのデータ量に比較して少なくなる。
なお、H.264/AVCでの符号化であるから、Base view videoについて時間方向の予測は行われている。また、Dependent view videoについても、view間の予測とともに、時間方向の予測が行われている。Dependent view videoをデコードするには、エンコード時に参照先とした、対応するBase view videoのデコードが先に終了している必要がある。
Dependent view videoエンコーダ224は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ225に出力する。
マルチプレクサ225は、H.264/AVCエンコーダ221から供給されたBase view videoストリームと、Depth算出部223から供給されたDependent view videoストリーム(Depthのデータ)と、Dependent view videoエンコーダ224から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは1本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
マルチプレクサ225は、生成したTS(MPEG2 TS)を出力する。マルチプレクサ225から出力されたTSは、他の管理データとともに記録装置において光ディスク202に記録され、光ディスク202に記録された形で再生装置201に提供される。
以下、適宜、図3に示すように、2つのDependent view videoのうち、Depth情報からなるDependent view videoをD1 view videoといい、R画像からなるDependent view videoをD2 view videoという。なお、R画像からなるDependent view videoをD1 view videoとして処理し、Depth情報からなるDependent view videoをD2 view videoとして処理するようにすることも可能である。
また、Base view videoとD1 view videoを用いて行われる3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる3D再生をB-D2再生という。
再生装置201は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク202から読み出して再生する。
また、再生装置201は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク202から読み出して再生する。
さらに、再生装置201は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク202から読み出して再生する。
Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
[TSの構成例]
図5は、TSの構成例を示す図である。
図5のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
このように、Dependent view videoストリームが、Base view videoストリームとともにMain TSに含まれていることもある。
光ディスク202には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームを含むTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。
ビデオと同様に3Dでの表示が可能になるように、PG、IGについてもBase viewとDependent viewのそれぞれのストリームが用意されている。
図6は、TSの他の構成例を示す図である。
図6のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
図7は、TSのさらに他の構成例を示す図である。
図7のMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
一方、Sub TSにはDependent view videoストリームが含まれている。
このように、Dependent view videoストリームがBase view videoストリームとは別のTSに含まれていることもある。
[アプリケーションフォーマット]
図8は、再生装置201によるAVストリームの管理の例を示す図である。
AVストリームの管理は、図8に示すようにPlayListとClipの2つのレイヤを用いて行われる。AVストリームは、光ディスク202だけでなく、再生装置201のローカルストレージに記録されていることもある。
ここでは、1つのAVストリームとそれに付随する情報であるClip Informationのペアを1つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。
AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationファイルは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。
PlayListはAVストリームの再生区間の集まりである。AVストリーム中の1つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。図8に示すように、PlayListは1つまたは複数のPlayItemにより構成される。
図8の左から1番目のPlayListは2つのPlayItemから構成され、その2つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。
左から2番目のPlayListは1つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。
左から3番目のPlayListは2つのPlayItemから構成され、その2つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。
例えば、左から1番目のPlayListに含まれる左側のPlayItemが再生対象としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を管理するための再生管理情報として用いられる。
PlayListの中で、1つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。
また、PlayListの中で、Main Pathに並行して、1つ以上のSubPlayItemの並びによって作られる再生パスをサブパス(Sub Path)という。
図9は、Main PathとSub Pathの構造を示す図である。
PlayListは、1つのMain Pathと1つ以上のSub Pathを持つことができる。
上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。
図9のPlayListは、3つのPlayItemの並びにより作られる1つのMain Pathと、3つのSub Pathを有している。
Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。
図9の例においては、Subpath_id=0のSub Pathには1つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには2つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには1つのSubPlayItemが含まれる。
1つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム(メイン画像データ)が含まれる。
また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで(同期して)再生されるオーディオストリームが1つ以上含まれてもよいし、含まれなくてもよい。
Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ(PG(Presentation Graphic))のストリームが1つ以上含まれてもよいし、含まれなくてもよい。
Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが1つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。
1つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される0個以上のオーディオストリーム、0個以上のPGストリーム、および、0個以上のIGストリームが多重化されている。
また、1つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム(別ストリーム)の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。
このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開2008−252740号公報、特開2005−348314号公報に記載されている。
[ディレクトリ構造]
図10は、光ディスク202に記録されるファイルの管理構造の例を示す図である。
図10に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク202上には1つのrootディレクトリが作成される。rootディレクトリの下が、1つの記録再生システムで管理される範囲となる。
rootディレクトリの下にはBDMVディレクトリが置かれる。
BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、5桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。
図10に示す1つのPlayListファイルには「00000.mpls」のファイル名が設定されている。
CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、5桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
図10の3つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。
「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。
「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。
STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、5桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、5桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。
「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。
「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。
「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。
図10に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
[各データのシンタクス]
図11は、PlayListファイルのシンタクスを示す図である。
PlayListファイルは、図10のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
図11のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。
version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは4桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。“0240”が設定されたPlayListファイルに記述されるPlayListが、後述する3D_PlayListとなる。
PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。
PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。
ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。
ExtensionData_start_addressの後には、160bitのreserved_for_future_useが含まれる。
AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先(ジャンプポイント)であるマークに関する情報が格納される。
ExtensionData()には、プライベートデータが挿入できるようになっている。
図12は、図11のPlayList()のシンタクスを示す図である。
lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す32ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
lengthの後には、16ビットのreserved_for_future_useが用意される。
number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す16ビットのフィールドである。図9の例の場合、PlayItemの数は3である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に0から割り振られる。例えば、図9のPlayItem_id=0,1,2が割り振られる。
number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す16ビットのフィールドである。図9の例の場合、Sub Pathの数は3である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に0から割り振られる。例えば、図9のSubpath_id=0,1,2が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。
図13は、図12のSubPath()のシンタクスを示す図である。
lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す32ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
lengthの後には、16ビットのreserved_for_future_useが用意される。
SubPath_typeは、Sub Pathのアプリケーションの種類を示す8ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。
SubPath_typeの後には、15ビットのreserved_for_future_useが用意される。
is_repeat_SubPathは、Sub Pathの再生方法を指定する1ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を1回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合(Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など)に利用される。
Is_repeat_SubPathの後には、8ビットのreserved_for_future_useが用意される。
number_of_SubPlayItemsは、1つのSub Pathの中にあるSubPlayItemの数(エントリー数)を示す8ビットのフィールドである。例えば、図9のSubPath_id=0のSubPlayItemのnumber_of_SubPlayItemsは1であり、SubPath_id=1のSubPlayItemのnumber_of_SubPlayItemsは2である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem()が参照される。
図14は、図13のSubPlayItem(i)のシンタクスを示す図である。
lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す16ビットの符号なし整数である。
図14のSubPlayItem(i)は、SubPlayItemが1つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。
SubPlayItemが1つのClipを参照する場合について説明する。
Clip_Information_file_name[0]は、SubPlayItemが参照するClipのClip Informationファイルの名前を表す。
Clip_codec_identifier[0]はClipのコーデック方式を表す。Clip_codec_identifier[0]の後にはreserved_for_future_useが含まれる。
is_multi_Clip_entriesはマルチClipの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。
ref_to_STC_id[0]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。
SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。
sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。
SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。
「if(is_multi_Clip_entries==1b」であり、SubPlayItemが複数のClipを参照する場合について説明する。
num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。
Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。
ref_to_STC_id[SubClip_entry_id]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。
図15は、図12のPlayItem()のシンタクスを示す図である。
lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す16ビットの符号なし整数である。
Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むm2tsファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ5桁の数字が含まれる。
Clip_codec_identifier[0]はClipのコーデック方式を表す。Clip_codec_identifier[0]の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。
ref_to_STC_id[0]はSTC不連続点(システムタイムベースの不連続点)に関する情報である。
IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。
OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。
STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。
図16は、図15のSTN_table()のシンタクスを示す図である。
STN_table()は、PlayItemの属性として設定されている。
lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す16ビットの符号なし整数である。lengthの後には、16ビットのreserved_for_future_useが用意される。
number_of_video_stream_entriesは、STN_table()の中でエントリーされる(登録される)、video_stream_idが与えられるストリームの数を表す。
video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームがこのvideo_stream_idにより特定される。
Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。
number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる1番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。
number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる2番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。
number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。
number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、IGストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
[PlayListの具体例]
図17は、3D再生用のPlayListである3D_PlayListの具体例を示す図である。
説明の便宜上、図17の左側には行数を表す数字と「:」を示している。この数字と「:」は3D_PlayListを構成するものではない。
2行目のnumber_of_PlayItemsは図12のnumber_of_PlayItemsに対応し、3D_PlayList中のPlayItemの数を表す。2行目から8行目がPlayItemに関する記述になる。すなわち、3行目から8行目が、図12のfor文を用いたPlayItemに記述に対応する。
5行目のref_to_B_clpi_file_nameは図15のClip_Information_file_name[0]に対応し、Base view videoストリームを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、参照するm2tsファイルと、Base view videoのClipのclpiファイルが特定される。
6行目のtypeは、Base view videoと、それに関連付けられたD1/D2 view videoのデータの光ディスク202上での配置のタイプを表す。typeは、例えば図15のClip_codec_identifier[0]に続くreserved_for_future_useを用いて設定される。
図18は、typeの意味を示す図である。
typeの値が0であることは、Base view video、D1 view video、D2 view videoがインターリーブされていないことを表す。
この場合、存在するD1/D2 view videoの両方、またはいずれかのパケットが、Base view videoのパケットとともに1本のMPEG2-TSに多重化される。
typeの値が1であることは、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを表す。
この場合、B view videoを含む第1のTSと、D1 view videoを含む第2のTSと、D2 view videoを含む第3のTSの3本のTSが、エクステント単位で光ディスク202上にインターリーブされている。
typeの値が2であることは、Base view videoとD1 view videoがインターリーブされていることを表す。
この場合、B view videoのパケットを含む第1のTSと、D1 view videoのパケットを含む第2のTSの2本のTSが、エクステント単位で光ディスク202上にインターリーブされている。第1のTSにはD2 view videoのパケットが多重化されていても良い。また、第2のTSには、D2 view videoのパケットが多重化されていても良い。
typeの値が3であることは、Base view videoとD2 view videoがインターリーブされていることを表す。
この場合、B view videoのパケットを含む第1のTSと、D2 view videoのパケットを含む第2のTSの2本のTSが、エクステント単位で光ディスク202上にインターリーブされている。第1のTSには、D1 view videoのパケットが多重化されていても良い。また、第2のTSには、D1 view videoのパケットが含まれてはいけない。
図17の説明に戻り、7行目のSTN_tableは図15のSTN_table()に対応する。図16を参照して説明したように、STN_tableには3D_PlayListにおいて参照する各ストリームのIDが記述される。
9行目のnumber_of_SubPathsは図12のnumber_of_SubPathsに対応し、3D_PlayList中のSubPathの数を表す。9行目から14行目がSubPathに関する記述になる。すなわち、10行目から14行目が、図12のfor文を用いたSubPathに記述に対応する。
12行目のSubPath_typeは図13のSubPath_typeに対応し、SubPathの種類を表す。
図19は、SubPath_typeの意味を示す図である。
図19に示す各値のうちの主なものについて説明すると、SubPath_typeの値が8であることは、D1 view videoを再生するサブパスであることを表す。
また、SubPath_typeの値が9であることは、D2 view videoを再生するサブパスであることを表す。
図17の13行目のref_to_clpi_file_nameは図14のClip_Information_file_name[0]に対応する。
このSubPathがD1 view videoを再生するものである場合には、ref_to_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、参照するclpiファイルが特定される。
一方、13行目のref_to_clpi_file_nameは、このSubPathがD2 view videoを再生するものである場合には、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。
16行目から30行目は、interleaved_file_info()、すなわちilvtファイルに関する記述である。例えば、PlayItem()、SubPath()中のreserved_for_future_useを用いてilvtファイルに関する記述が用意される。
17行目から22行目は、6行目のtypeの値が1であり、Base view video、D1 view video、D2 view videoが全てインターリーブされている場合に参照する記述である。
18行目のref_to_D1-B_interleaved_file_nameは、Base view videoとD1 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
19行目のref_to_D2-B_interleaved_file_nameは、Base view videoとD2 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
20行目のref_to_D1_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D1 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
21行目のref_to_D2_clpi_file_nameは、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D2 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
23行目から26行目は、6行目のtypeの値が2であり、Base view videoとD1 view videoがインターリーブされている場合に参照する記述である。
24行目のref_to_D1-B_interleaved_file_nameは、Base view videoとD1 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
25行目のref_to_D1_clpi_file_nameは、D1 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D1 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
27行目から30行目は、6行目のtypeの値が3であり、Base view videoとD2 view videoがインターリーブされている場合に参照する記述になる。
28行目のref_to_D2-B_interleaved_file_nameは、Base view videoとD2 view videoの再生用のilvtファイルのファイル名のうちの、「.ilvt」の拡張子を除いた5桁の数字を表す。
29行目のref_to_D2_clpi_file_nameは、D2 view videを格納したm2tsファイルのファイル名のうちの、「.m2ts」の拡張子を除いた5桁の数字を表す。この記述により、D2 view videのm2tsファイルの再生時に参照するclpiファイルが特定される。
このように、3D_PlayListには、データが光ディスク202上でインターリーブされている場合、D1 view video、D2 view videoについても、それらのClip AVストリームに対応するclpiファイルのファイル名を特定可能な情報が記述される。
[再生装置201の構成例]
図20は、再生装置201の構成例を示すブロック図である。
コントローラ251は、予め用意されている制御プログラムを実行し、再生装置201の全体の動作を制御する。
例えば、コントローラ251は、ディスクドライブ252を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ251は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部256に供給させる。
ディスクドライブ252は、コントローラ251による制御に従って光ディスク202からデータを読み出し、読み出したデータを、コントローラ251、メモリ253、またはデコーダ部256に出力する。
メモリ253は、コントローラ251が各種の処理を実行する上において必要なデータなどを適宜記憶する。
ローカルストレージ254は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ254には、サーバ272からダウンロードされたD1/D2 view videoストリームなどが記録される。ローカルストレージ254に記録されているストリームもデコーダ部256に適宜供給される。
インターネットインタフェース255は、コントローラ251からの制御に従ってネットワーク271を介してサーバ272と通信を行い、サーバ272からダウンロードしたデータをローカルストレージ254に供給する。
サーバ272からは、光ディスク202に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたD1/D2 view videoストリームを光ディスク202に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク202の内容とは異なる内容の3D再生を実現することが可能になる。D1/D2 view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。
デコーダ部256は、ディスクドライブ252、またはローカルストレージ254から供給されたストリームをデコードし、得られたビデオ信号を表示装置203に出力する。
オーディオ信号も所定の経路を介して表示装置203に出力される。
操作入力部257は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部257はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ251に供給する。
図21は、デコーダ部256の構成例を示す図である。
分離部281は、コントローラ251による制御に従って、ディスクドライブ252から供給されたデータを、Main TSを構成するパケットのデータとSub TSを構成するパケットのデータに分離する。例えば、3D PlayListファイルのSTN_table()に記述されているストリームIDに基づいて光ディスク202から読み出されたTSが分離部281に供給される。
分離部281は、分離したMain TSを構成するパケットをリードバッファ282に出力して記憶させ、Sub TSを構成するパケットをリードバッファ285に出力して記憶させる。
また、分離部281は、ローカルストレージ254から供給されたSub TSを構成するパケットをリードバッファ285に出力して記憶させる。
上述したように、サーバ272からダウンロードされたD1/D2 view videがローカルストレージ254に記憶されている場合がある。光ディスク202に記録されているBase view videoとともに再生することが指示されたとき、Sub TSとしてのD1/D2 view videストリームがローカルストレージ254から読み出され、分離部281に供給される。
PIDフィルタ283は、リードバッファ282に記憶されているMain TSを構成するパケットを、各パケットに設定されているPIDに基づいて振り分ける。コントローラ251からは、Base view videoを構成するパケットのPID、D1 view videoを構成するパケットのPID、D2 view videoを構成するパケットのPIDがそれぞれ指定される。
PIDフィルタ283は、Main TSに含まれるBase view videoのパケットをリードバッファ282から読み出し、ESバッファ284に出力して記憶させる。ESバッファ284には、Base view videoのパケットからなるES(Elementary Stream)が記憶される。
また、PIDフィルタ283は、Main TSにD1/D2 view videのパケットが多重化されている場合、それらのパケットをPIDに基づいて抽出し、スイッチ287に出力する。
PIDフィルタ286は、Sub TSに含まれるD1/D2 view videのパケットをリードバッファ285から読み出し、スイッチ287に出力する。
なお、ここではBase view video、D1/D2 view videoのビデオストリームの処理についてだけ説明しているが、図5を参照して説明したように、Main TSにはPGやIGなどのグラフィックスのデータが多重化されていることがある。同様に、図6を参照して説明したように、Sub TSには、D1/D2 view videの他にも、字幕のデータやグラフィックのデータが多重化されていることがある。
PIDフィルタ283とPIDフィルタ286は、適宜、それらのデータをもPIDに基づいて振り分け、所定の出力先に出力する。図21のPIDフィルタ283とPIDフィルタ286のブロック内に示す出力先の端子(丸)には、グラフィックのデータをデコードするデコーダなどが接続される。
スイッチ287は、PIDフィルタ283から供給されたD1/D2 view videのパケットをESバッファ288に出力して記憶させる。また、スイッチ287は、PIDフィルタ286から供給されたD1/D2 view videのパケットをESバッファ288に出力して記憶させる。ESバッファ288には、D1/D2 view videoのパケットからなるESが記憶される。
スイッチ289は、ESバッファ284に記憶されているBase view videoのパケットと、ESバッファ288に記憶されているD1/D2 view videoのパケットのうちの、デコードの対象になるパケットをデコーダ290に出力する。DTS(Decoding Time Stamp)などの時刻情報がBase view videoとD1/D2 view videoのPESパケットに設定されており、その時刻情報に基づいてバッファからの読み出しが行われる。
ビデオデコーダ290は、スイッチ289から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはD1/D2 view videoのデータを出力する。
[3D_PlayListの例1]
図22は、3D_PlayListの例を示す図である。
図22の「00000.mpls」のPlayListファイルに記述されている3D_PlayListは、Base view video、D1 view video、D2 view videoが全てインターリーブされている光ディスク202の再生を管理するPlayListである。すなわち、typeの値は1である。
図22の例においては、PlayItem()のref_to_B_clpi_file_nameは「00001」である。この記述から、Base view videoのm2tsファイルである「00001.m2ts」を再生する場合には、図10の「00001.clpi」のclpiファイルを参照することが特定される。
また、SubPath()[1]のSubPath_typeは「9」である。SubPath_typeが「9」であることは、この1つ目のSubPathがD2 view videoを再生するサブパスであることを表す。
SubPath()[1]のref_to_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
SubPath()[2]のSubPath_typeは「8」である。SubPath_typeが「8」であることは、この2つ目のSubPathがD1 view videoを再生するサブパスであることを表す。
SubPath()[2]のref_to_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には図10の「00003.clpi」のclpiファイルを参照することが特定される。
interleaved_file_info()のref_to_D1-B_interleaved_file_nameは「10000」である。
この記述から、D1-B再生を行う場合には図10の「10000.ilvt」のilvtファイルを参照することが特定される。
また、ref_to_D2-B_interleaved_file_nameは「20000」である。この記述から、D2-B再生を行う場合には図10の「20000.ilvt」のilvtファイルを参照することが特定される。
ref_to_D1_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には図10の「00003.clpi」のファイルを参照することが特定される。
ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のファイルを参照することが特定される。
図23は、図22の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
図23Aは「00001.clpi」のclpiファイルの例を示す図である。上述したように、「00001.clpi」のclpiファイルは、Base view videoのm2tsファイルである「00001.m2ts」を再生する場合に参照するファイルである。
number_of_source_packets1は、「00001.m2ts」のm2tsファイルに含まれるソースパケットの数を表す。
EP_mapは、「00001.m2ts」のm2tsファイルに含まれるTS中のエントリーポイント(EP)の位置情報を表す。
chunk_map()は、「00001.m2ts」のm2tsファイルに含まれるTSについて、先頭のチャンクから順番に、各チャンクの開始位置を表すSource Packet Number(SPN)を表す。
チャンクは、1つのTSに属し、光ディスク202上に連続配置されるSource packetの集まりである。ここでは、1つのチャンクが、光ディスク202上に配置される1つのエクステントに相当するものとして説明する。
chunk_map()が、各チャンクの長さを表すことになる。chunk_map()の具体例については後述する。
図23Bは「00002.clpi」のclpiファイルの例を示す図である。「00002.clpi」のclpiファイルは、D2 view videoを再生する場合に参照するファイルである。
図23Cは「00003.clpi」のclpiファイルの例を示す図である。「00003.clpi」のclpiファイルは、D1 view videoを再生する場合に参照するファイルである。図23B、図23Cの記述内容は図23Aに示すものと同じである。
図24は、図22、図23のデータを用いて行われるファイル管理の概念を示す図である。
図24に示すように、ファイル管理は、物理レイヤ、ファイルシステムレイヤ、アプリケーションレイヤの3層構造の形で行われる。図22の3D_PlayList、図23のclpiファイルがアプリケーションレイヤの情報になる。
物理レイヤは、Base view video、D1 view video、D2 view videoが全てインターリーブされた状態で記録されている光ディスク202のレイヤとなる。
図24の例においては、D1 view videoのチャンク、D2 view videoのチャンク、Base view videoのチャンクがその順番で配置されている。図24において、「B」の文字を付けているブロックはBase view videoのチャンクを表し、「D1」の文字を付けているブロックはD1 view videoのチャンクを表す。「D2」の文字を付けているブロックはD2 view videoのチャンクを表す。
このように、Base view video、D1 view video、D2 view videoの各エクステント(チャンク)は、光ディスク202上においてインターリーブ配置されている。インターリーブ配置は、同一種類のストリームのエクステントが隣接しない、周期的な配置を意味する。
ファイルシステムレイヤにおいては、アプリケーションがファイル名で指定したストリームファイル(m2tsファイル、ilvtファイル)と、光ディスク202上の各チャンクが対応付けられる。ファイルシステムは例えばUDF file systemである。
図24に示すように、「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
「00003.m2ts」のm2tsファイルは、光ディスク202上に配置されたD1 view videoのチャンクから構成される。
「20000.ilvt」のファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
「10000.ilvt」のファイルは、光ディスク202上に配置されたD1 view videoのチャンクとBase view videoのチャンクから構成される。
2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
また、B-D1再生を行うために、アプリケーションから「10000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D1 view videoのチャンクとBase view videoのチャンクが読み出される。
B-2D再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例1]
ここで、図25のフローチャートを参照して、図22の3D_PlayListファイルに従って行われる再生処理について説明する。
ステップS1において、コントローラ251は、typeの値から、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを確認する。
この場合、ステップS2において、コントローラ251は、interleaved_file_info()を読みに行く。
ステップS3において、コントローラ251は、ユーザによる操作などに基づいて、B-D1再生が指示されたか否かを判定する。
B-D1再生が指示されたとステップS3において判定した場合、ステップS4において、コントローラ251は、interleaved_file_info()に記述された「10000.ilvt」(ref_to_D1-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD1 view videoのチャンクを光ディスク202から読み出させる。
ディスクドライブ252により読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
ステップS5において、分離部281は、図23の「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00003.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00003.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。chunk_map()を使って行われるデータの分離については後述する。
リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。リードバッファ285に記憶された「00003.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
ステップS6において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする(再生する)。
一方、ステップS3において、B-D1再生が指示されていない、すなわちB-D2再生が指示されたと判定した場合、ステップS7において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
ステップS8において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
その後、「00001.m2ts」のm2tsファイルのデータと「00002.m2ts」のm2tsファイルのデータは、B-D1再生のときと同様にデコーダ290に供給され、ステップS6において再生される。
[chunk_map()を使ったデータの分離]
図26は、chunk_map()のシンタクスの例を示す図である。
number_of_chunksは、参照するチャンクの数を表す。number_of_chunks以降には、ここで指定される数だけチャンクの情報が記述される。
SPN_chunk_start[i]は、例えば先頭のチャンクの開始位置を基準として、その基準の位置から各チャンクの開始位置までのSPN(長さ)を表す。各チャンクの開始位置までのSPNが、先頭のチャンクのものから順に記述される。
図27は、chunk_map()の具体例を示す図である。
図27Aは「00001.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
また、SPN_chunk_start[i]は0,c1,c2,…,cnである。
1番目の値0は、図28Cに示すように、「00001.m2ts」のm2tsファイルに含まれるBase view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(B[0])の開始位置までのSPNが0であることを表す。
2番目の値c1は、基準の位置から、2番目のチャンク(B[1])の開始位置までのSPNがc1であることを表す。
3番目の値c2は、基準の位置から、3番目のチャンク(B[2])の開始位置までのSPNがc2であることを表す。
n+1番目の値cnは、基準の位置から、最後のチャンクであるn+1番目のチャンク(B[n])の開始位置までのSPNがcnであることを表す。
図27Bは「00002.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
また、SPN_chunk_start[i]は0,b1,b2,…,bnである。
1番目の値0は、図28Bに示すように、「00002.m2ts」のm2tsファイルに含まれるD2 view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(D2[0])の開始位置までのSPNが0であることを表す。
2番目の値b1は、基準の位置から、2番目のチャンク(D2[1])の開始位置までのSPNがb1であることを表す。
3番目の値b2は、基準の位置から、3番目のチャンク(D2[2])の開始位置までのSPNがb2であることを表す。
n+1番目の値bnは、基準の位置から、最後のチャンクであるn+1番目のチャンク(D2[n])の開始位置までのSPNがbnであることを表す。
図27Cは「00003.clpi」のclpiファイルに記述されるchunk_map()であり、number_of_chunksは(n+1)である。
また、SPN_chunk_start[i]は0,a1,a2,…,anである。
1番目の値0は、図28Aに示すように、「00003.m2ts」のm2tsファイルに含まれるD1 view videoの先頭のチャンクの開始位置を基準として、その基準の位置から、1番目のチャンク(D1[0])の開始位置までのSPNが0であることを表す。
2番目の値a1は、基準の位置から、2番目のチャンク(D1[1])の開始位置までのSPNがa1であることを表す。
3番目の値a2は、基準の位置から、3番目のチャンク(D1[2])の開始位置までのSPNがa2であることを表す。
n+1番目の値anは、基準の位置から、最後のチャンクであるn+1番目のチャンク(D1[n])の開始位置までのSPNがanであることを表す。
D1[i],D2[i],B[i]は、図28Dに示すようにその順番で、光ディスク202上に周期的に配置されている。
分離部281は、光ディスク202から読み出されたデータがディスクドライブ252から供給された場合、図27の3つのchunk_map()の記述に基づいて、供給されたデータの先頭からa1に相当するSPN分のデータをD1[0]として分離する。
また、分離部281は、D1[0]の終わりの位置からb1に相当するSPN分のデータをD2[0]として分離し、D2[0]の終わりの位置からc1に相当するSPN分のデータをB[0]として分離する。
分離部281は、B[0]の終わりの位置からa2-a1に相当するSPN分のデータをD1[1]として分離する。
分離部281は、D1[1]の終わりの位置からb2-b1に相当するSPN分のデータをD2[1]として分離し、D2[1]の終わりの位置からc2-c1に相当するSPN分のデータをB[1]として分離する。
なお、分離の対象になるチャンクは、B-D1再生を行う場合にはD1[i],B[i]だけであり、B-D2再生を行う場合にはD2[i],B[i]だけである。
このように、分離部281によるデータの分離は、chunk_map()に記述される各チャンクの長さの情報を用いて行われる。
chunk_map()について補足する。
type=0のとき、ref_to_B_clpi_file_nameにより参照されるclpiファイルについては、chunk_map()はオプショナルとなる(無くても良い)。そして、chunk_map()がある場合、プレーヤはそのchunk_map()を無視しなければならない。
また、ローカルストレージ254上のm2tsファイルに対応するclpiファイルについては、chunk_map()はオプショナルとなる(無くても良い)。そして、chunk_map()がある場合、プレーヤはそのchunk_map()を無視しなければならない。
type=1のとき、対応するBase view videoのTS、D1 view videoのTS、D2 view videoのTSの3本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、図28のD1[i],D2[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
同様に、type=2のとき、対応するBase view videoのTS、D1 view videoのTSの2本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、インターリーブされるD1[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
type=3のとき、対応するBase view videoのTS、D2 view videoのTSの2本のTSは、それぞれ同じ数(n+1)のチャンクに分割される。すなわち、インターリーブされるD2[i],B[i]について、添え字iの値が同じ組のチャンクは、同じ再生時間を持つように分割される。
[3D_PlayListの例2]
図29は、3D_PlayListの他の例を示す図である。
図29の「0000.mpls」のPlayListファイルに記述されている3D_PlayListは、Base view videoとD2 view videoがインターリーブされている光ディスク202の再生を管理するPlayListである。すなわち、typeの値は3である。
SubPathの記述がD2 view videoを参照するSubPathの記述だけになる点と、interleaved_file_info()の記述が異なる点を除いて、図29の3D_PlayListの記述は図22の記述と同様である。
すなわち、SubPath()のSubPath_typeは「9」である。SubPath_typeが「9」であることは、このSubPathがD2 view videoを再生するサブパスであることを表す。
また、ref_to_clpi_file_nameは「00002」である。
図29のinterleaved_file_info()のref_to_D2-B_interleaved_file_nameは「20000」である。この記述から、D2-B再生を行う場合には図10の「20000.ilvt」のilvtファイルを参照することが特定される。
また、ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
図30は、図29の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
図30Aは、「00001.clpi」のclpiファイルの例を示す図であり、図30Bは、「00002.clpi」のclpiファイルの例を示す図である。いずれのclpiファイルにも、EP_mapと、上述したchunk_map()の記述が含まれる。
図31は、図29、図30のデータを用いて行われるファイル管理の概念を示す図である。
図31に示すように、物理レイヤは、Base view videoとD2 view videoがインターリーブされた状態で記録されている光ディスク202のレイヤとなる。
「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
「20000.ilvt」のilvtファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
B-D2再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例2]
図32のフローチャートを参照して、図29の3D_PlayListファイルに従って行われる再生処理について説明する。
ステップS11において、コントローラ251は、typeの値から、Base view video、D2 view videoがインターリーブされていることを確認する。
この場合、ステップS12において、コントローラ251は、interleaved_file_info()を読みに行く。
B-D2再生が指示された場合、ステップS13において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
ディスクドライブ252により読み出されたBase view videoのチャンクとD2 view videoのチャンクはデコーダ部256の分離部281に供給される。
ステップS14において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。一方、リードバッファ285に記憶された「00002.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
ステップS15において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
[3D_PlayListの例3]
図33は、3D_PlayListのさらに他の例を示す図である。
図33の「00000.mpls」のPlayListファイルに記述されている3D_PlayListは、光ディスク202に記録されているBase view video、D2 view videoと、ローカルストレージ254に記録されているD1 view videoの再生を管理するPlayListである。光ディスク202上では、Base view videoとD2 view videoはインターリーブされている。
光ディスク202上のデータの配置のタイプを表すものであるから、PlayItem()のtypeの値は3である。
SubPath()[1]のSubPath_typeは「9」である。SubPath_typeが「9」であることは、この1つ目のSubPathがD2 view videoを再生するサブパスであることを表す。
SubPath()[1]のref_to_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のclpiファイルを参照することが特定される。
SubPath()[2]のSubPath_typeは「8」である。SubPath_typeが「8」であることは、この2つ目のSubPathがD1 view videoを再生するサブパスであることを表す。
SubPath()[2]のref_to_clpi_file_nameは「00003」である。この記述から、D1 view videoを再生する場合には、ローカルストレージ254に記録されている「00003.clpi」のclpiファイルを参照することが特定される。
この2つ目のSubPathに関する記述は、例えば、D1 view videoがダウンロードされたときに追加される。
interleaved_file_info()のref_to_D2-B_interleaved_file_nameは「20000」である。
この記述から、B-D2再生を行う場合には、図10の「20000.ilvt」のilvtファイルを参照することが特定される。
また、ref_to_D2_clpi_file_nameは「00002」である。この記述から、D2 view videoを再生する場合には図10の「00002.clpi」のファイルを参照することが特定される。
なお、ローカルストレージ254上ではD1 view videoはインターリーブされていないから、D1 view videoに関するilvtファイルは不要である。
図34は、図33の3D_PlayListとともに用いられるclpiファイルのシンタクスを示す図である。
図34Aは、「00001.clpi」のclpiファイルの例を示す図であり、図34Bは、「00002.clpi」のclpiファイルの例を示す図である。いずれのclpiファイルにも、EP_mapとchunk_map()の記述が含まれる。
図35は、図33、図34のデータを用いて行われるファイル管理の概念を示す図である。
図35に示すように、物理レイヤは、Base view videoとD2 view videoがインターリーブされた状態で記録されている光ディスク202と、2番目のSubPathが参照するD1 view videoのファイルが記録されているローカルストレージ254のレイヤとなる。
図35の例においては、D1 view videoを格納したm2tsファイルのファイル名は「00003.m2ts」である。また、「00003.m2ts」に対応するclpiファイルのファイル名は「00003.clpi」である。
「00001.m2ts」のm2tsファイルは、光ディスク202上に配置されたBase view videoのチャンクから構成される。
また、「00002.m2ts」のm2tsファイルは、光ディスク202上に配置されたD2 view videoのチャンクから構成される。
「20000.ilvt」のilvtファイルは、光ディスク202上に配置されたD2 view videoのチャンクとBase view videoのチャンクから構成される。
2D再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。
B-D1再生を行うために、アプリケーションから「00001.m2ts」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、Base view videoのチャンクが読み出される。また、図33の3D_PlayListの2番目のSubPathの記述に従って、「00003.m2ts」を指定して、D1 view videoのm2tsファイルがローカルストレージ254から読み出される。
B-D2再生を行うために、アプリケーションから「20000.ilvt」を指定してデータの読み出しが指示された場合、ファイルシステムによる管理に従って、D2 view videoのチャンクとBase view videoのチャンクが読み出される。
[動作例3]
図36のフローチャートを参照して、図33の3D_PlayListファイルに従って行われる再生処理について説明する。
ステップS21において、コントローラ251は、typeの値から、Base view video、D2 view videoがインターリーブされていることを確認する。
この場合、ステップS22において、コントローラ251は、interleaved_file_info()を読みに行く。
ステップS23において、コントローラ251は、B-D1再生が指示されたか否かを判定する。
B-D1再生を行う場合、光ディスク202に記録されているデータとローカルストレージ254に記録されているデータが用いられる。一方、B-D2再生を行う場合、光ディスク202に記録されているデータが用いられる。
ステップS23において、B-D1再生が指示されていない、すなわちB-D2再生が指示されたと判定した場合、ステップS24において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を構成するD2 view videoを含むClipの名前X「00002」(D2 view videoを含むm2tsファイルの名前のうちの拡張子を除いた部分)を取り出す。
ステップS25において、コントローラ251は、SubPath_type=9(D2-view videoを再生するサブパス)が参照するClipの名前Y「00002」を取り出す。
ステップS26において、コントローラ251は、YがXと同じであることにより、D2 view videoが「20000.ilvt」に含まれていることを認識する。ここでYがXと異なるとき、D2 view videoを含むClipはローカルストレージ254上にあることになる。
ステップS27において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を指定し、UDF file systemを通して、Base view videoのチャンクとD2 view videoのチャンクを光ディスク202から読み出させる。
ディスクドライブ252により読み出されたBase view videoのチャンクとD2 view videoのチャンクはデコーダ部256の分離部281に供給される。
ステップS28において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00002.clpi」(ref to D2_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00002.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00002.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。一方、リードバッファ285に記憶された「00002.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
ステップS29において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
一方、B-D1再生が指示されたとステップS23において判定した場合、ステップS30において、コントローラ251は、interleaved_file_info()に記述された「20000.ilvt」(ref_to_D2-B_interleaved_file_name)を構成するD2 view videoを含むClipの名前X「00002」を取り出す。
ステップS31において、コントローラ251は、SubPath_type=8(D1-view videoを再生するサブパス)が参照するClipの名前Y「00003」を取り出す。
ステップS32において、コントローラ251は、Yが「00001.clpi」(ref_to_B_clpi_file_name)のうちの拡張子を除いた部分と異なり、かつ、YがXと異なることにより、D1 view videoのClipがローカルストレージ254上にあることを認識する。ここでYが「00001.clpi」のうちの拡張子を除いた部分と同じであるとき、または、YがXと同じあるとき、D1 view videoは「20000.ilvt」に含まれていることになる。
ステップS33において、コントローラ251は、「00001.clpi」(ref_to_B_clpi_file_name)のEP_mapを使って、ディスクドライブ252に「00001.m2ts」のm2tsファイルを読み出させる。「00001.clpi」のEP_mapには、「00001.m2ts」のm2tsファイルのデコード開始位置となるエントリポイントの情報が含まれている。
ステップS34において、コントローラ251は、「00003.clpi」(SubPath()[2]で参照されるファイル)のEP_mapを使って、ローカルストレージ254から「00003.m2ts」のm2tsファイルを読み出す。「00003.clpi」のEP_mapには、「00003.m2ts」のm2tsファイルのデコード開始位置となるエントリポイントの情報が含まれている。
読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
光ディスク202から読み出された「00001.m2ts」のm2tsファイルのデータはリードバッファ282に記憶された後、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。
また、ローカルストレージ254から読み出された「00003.m2ts」のm2tsファイルのデータはリードバッファ285に記憶された後、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
ステップS29において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
[chunk_map()を利用して「10000.ilvt」をランダムアクセス再生する方法]
図37は、図27を参照して説明したchunk_map()の内容をまとめて示す図である。
各clpiファイルのchunk_map()に記述されるSPN_chunk_start(基準の位置からのSPN(長さ))を、縦方向にiをとって並べると図37に示すようなものになる。
図38は、chunk_map()とともに各clpiファイルに記述されるEP_map()のシンタクスを示す図である。
EP_map()はランダムアクセスなどを行うときのデコード開始位置を特定するために参照される。
number_of_EP_entriesはEP(エントリポイント)の数を表す。
number_of_EP_entries以降の記述が各EPについて用意される。PTS_EP_start[i]はEPのPTSを表し、SPN_EP_start[i]はEPのSPNを表す。このように、EP_mapには、各エントリポイントについてのPTSとSPNが対応付けて登録される。
図39のフローチャートを参照して、再生装置201の処理について説明する。
ここでは、図22の3D_PlayListを参照してB-D1再生を行い、ランダムアクセスを行う場合について説明する。
ステップS41において、コントローラ251は、typeの値から、Base view video、D1 view video、D2 view videoが全てインターリーブされていることを確認する。
この場合、ステップS42において、コントローラ251は、interleaved_file_info()を読みに行く。
ステップS43において、コントローラ251は、interleaved_file_info()に記述された「10000.ilvt」(ref_to_D1-B_interleaved_file_name)が読み出しファイルであると判断する。
「00000.mpls」の3D_PlayListファイルの時刻xから再生を開始する場合、ステップS44において、コントローラ251は、「00001.clpi」(ref_to_B_clpi_file_name)のEP_mapを用いて、xよりも小さく最も近い値を持つPTS_EP_start[m]を見つける。
ステップS45において、コントローラ251は、PTS_EP_start[m]に対応するSPN_EP_start[m]を取り出す。図38を参照して説明したように、EP_mapにはPTS_EP_start[i]とSPN_EP_start[i]が対応付けて登録されている。
図40は、ステップS44,S45の処理により特定される位置の例を示す図である。
図40に示すように、時間軸上の時刻xから再生を開始する場合、xよりも小さく最も近い値を持つPTS_EP_start[m]がステップS44において特定される。また、PTS_EP_start[m]に対応するSPN_EP_start[m]がステップS45において特定される。
ステップS46において、コントローラ251は、「00001.clpi」のchunk_mapを用いて、SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start[k]を見つける。ステップS46の処理により特定されるSPN_chunk_start[k]を図41に示す。
ステップS47において、コントローラ251は、「00001.clpi」のchunk_map()のSPN_chunk_start[k]と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()のSPN_chunk_start[k]との和を、「10000.ilvt」の読み出し開始アドレスとして決定する。
ここで決定される「10000.ilvt」の読み出し開始アドレスは、「10000.ilvt」の中でのD1[k]のチャンクの開始アドレスを示す。
ステップS48において、コントローラ251は、「10000.ilvt」(ref_to_D1-B_interleaved_file_name)を指定し、ステップS47で決定したアドレスから、UDF file systemを通して、Base view videoのチャンクとD1 view videoのチャンクを読み出させる。
読み出されたBase view videoのチャンクとD1 view videoのチャンクはデコーダ部256の分離部281に供給される。
ステップS49において、分離部281は、「00001.clpi」(ref_to_B_clpi_file_name)のchunk_map()と、「00003.clpi」(ref to D1_clpi_file_name)のchunk_map()に基づいて、供給されたデータを、「00001.m2ts」のm2tsファイルのデータと、「00003.m2ts」のm2tsファイルのデータに分離する。分離部281は、「00001.m2ts」のm2tsファイルのデータをリードバッファ282に出力し、「00003.m2ts」のm2tsファイルのデータをリードバッファ285に出力する。
リードバッファ282に記憶された「00001.m2ts」のm2tsファイルのデータは、PIDフィルタ283、ESバッファ284、スイッチ289を介してデコーダ290に供給される。リードバッファ285に記憶された「00003.m2ts」のm2tsファイルのデータは、PIDフィルタ286、スイッチ287、ESバッファ288、およびスイッチ289を介してデコーダ290に供給される。
ステップS50において、デコーダ290は、スイッチ289から順次供給されるパケットをデコードする。
ilvtファイルのランダムアクセスは以上のようにして行われる。
[EP_mapについて]
ここで、EP_mapについて説明する。
Base view videoのEP_mapについて説明するが、D1/D2 view videoについても、同様にしてEP_mapが設定される。例えば、Base view videoのあるピクチャにエントリポイントが設定された場合、D1/D2 view videoの対応するピクチャにもエントリポイントが設定される。
それぞれのストリームのピクチャをエンコード順/デコード順、あるいは表示順に並べたときに同じ位置にあるBase view videoのピクチャとD1/D2 view videoのピクチャが、対応するピクチャとなる。
図42は、光ディスク202上に記録されたAVストリームの構造を示す図である。
Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。1つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
なお、ソースパケットには、Clip AVストリームの先頭を例えば0として、ソースパケット毎に1ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第1バイト目から始まる。
EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の1つのEPデータは、PTSと、PTSに対応するAccess Uniteの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、1Access Uniteには1ピクチャ分のデータが格納される。
図43は、Clip AVストリームの例を示す図である。
図43のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム(Base view videoストリーム)である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
図43においては、ビデオストリームのソースパケットのうちの、IDR(Instantaneous Decording Refresh)ピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
IDRピクチャはIピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファの状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
例えば、PID=xで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
図44は、図43のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
図44に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UniteのPTSを表す。
SPN_EP_startは、PTS_EP_startの値により参照されるAccess Uniteの第1バイト目を含むソースパケットのアドレスを表す。
ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
図45は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Uniteの第1バイト目を含むソースパケットのソースパケット番号を表す。
AVC/H.264においては、Access Uniteすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が1であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Uniteが開始されることになる。
このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
[記録装置の構成例]
図46は、ソフト製作処理部301の構成例を示すブロック図である。
ビデオエンコーダ311は、図3のMVCエンコーダ211と同様の構成を有している。
ビデオエンコーダ311は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ312に出力する。
オーディオエンコーダ313は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ314に出力する。オーディオエンコーダ313には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
データエンコーダ315は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ316に出力する。
例えば、データエンコーダ315は、Base view videoストリームのデータとD1/D2 view videoストリームのデータがエクステント単位でインターリーブされた状態で光ディスクに記録されているのか否かを表すtype(図18)をPlayListファイルに設定する。
また、データエンコーダ315は、Base view videoストリームのデータとD1/D2 view videoストリームのデータがインターリーブされた状態で光ディスクに記録される場合、上述したilvtファイルをPlayListファイルに設定する。ilvtファイルは、Base view videoストリームのデータとD1/D2 view videoストリームのデータとを仮想的にまとめて管理する仮想ファイルとして機能する。
さらに、データエンコーダ315は、各ClipのClip Informationファイルのファイル名をPlayListファイルに設定したり、それぞれのClip Informationファイルに、EP_mapやchunk_mapを設定したりする。
多重化部317は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部318に出力する。
誤り訂正符号化部318は、エラー訂正用のコードを多重化部317により多重化されたデータに付加する。
変調部319は、誤り訂正符号化部318から供給されたデータに対して変調を施し、出力する。変調部319の出力は、再生装置201において再生可能な光ディスク202に記録されるソフトウェアとなる。
このような構成を有するソフト製作処理部301が記録装置に設けられる。
図47は、ソフト製作処理部301を含む構成の例を示す図である。
図47に示す構成の一部が記録装置内に設けられることもある。
ソフト製作処理部301により生成された記録信号はプリマスタリング処理部331においてマスタリング処理が施され、光ディスク202に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部333に供給される。
記録用原盤製作部332においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
原盤記録部333において、プリマスタリング処理部331から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
金属原盤製作部334において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
成形処理部335において、成形用金型に、インジェクションなどによりPMMA(アクリル)またはPC(ポリカーボネート)などの材料を注入し、固定化させることが行われる。
あるいは、金属スタンパ上に2P(紫外線硬化樹脂)などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
成膜処理部336において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
後加工処理部337において、このディスクに対して内外径の加工が施され、2枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置201によって再生可能なデータが記録された光ディスク202が完成する。
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、汎用のパーソナルコンピュータなどにインストールされる。
インストールされるプログラムはリムーバブル記録媒体に記録して提供される。また、ローカルエリアネットワーク、インターネット、ディジタル放送といった、有線または無線の伝送媒体を介して提供されるようにしてもよい。
本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
201 再生装置, 202 光ディスク, 203 表示装置, 211 MVCエンコーダ, 221 H.264/AVCエンコーダ, 222 H.264/AVCデコーダ, 223 Depth算出部, 224 Dependent view videoエンコーダ, 225 マルチプレクサ, 251 コントローラ, 252 ディスクドライブ, 253 メモリ, 254 ローカルストレージ, 255 インターネットインタフェース, 256 デコーダ部, 257 操作入力部

Claims (6)

  1. 複数視点のビデオストリームを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量の連続配置されるソースパケットの集まりであるエクステント単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、前記第1の多重化ストリームに付随する情報であり、前記第1の多重化ストリームを構成するソースパケットの総数を表す情報、前記多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第1の多重化ストリームの中での開始パケット番号を表す情報を含む第1の情報ファイルと、前記第2の多重化ストリームに付随する情報であり、前記第2の多重化ストリームを構成するソースパケットの総数を表す情報、前記第2の多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第2の多重化ストリームの中での開始パケット番号を表す情報を含む第2の情報ファイルとを前記記録媒体から読み出す読み出し部と、
    前記第1の情報ファイルと前記第2の情報ファイルを用いて、前記インターリーブドファイルを前記第1の多重化ストリームのエクステントと前記第2の多重化ストリームのエクステントに分離する分離部と、
    前記読み出し部による読み出しを制御する制御部と
    を備え、
    前記第1および第2の情報ファイルに含まれる前記エクステントの数を(n+1)とし、
    前記第1の多重化ストリームを構成するエクステントをB[i](i=0〜n)、前記第1の多重化ストリームの先頭からk番目のエクステントをB[k]と表し、
    前記第2の多重化ストリームを構成するエクステントをD[i](i=0〜n)、前記第2の多重化ストリームの先頭からk番目のエクステントをD[k]と表し、
    B[k]の開始パケット番号を、SPN_chunk_start_1[k]と表し、
    D[k]の開始パケット番号を、SPN_chunk_start_2[k]と表し、
    前記第1の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets1と表し、
    前記第2の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets2と表すとき、
    前記分離部は、
    k=0〜(n-1)について、B[k]を構成するソースパケットの数を、(SPN_chunk_start_1[k+1] - SPN_chunk_start_1[k])によって計算し、
    k=0〜(n-1)について、D[k]を構成するソースパケットの数を、(SPN_chunk_start_2[k+1] - SPN_chunk_start_2[k])によって計算し、
    B[n]を構成するソースパケットの数を、(number_of_source_packets1 - SPN_chunk_start_1[n])によって計算し、
    D[n]を構成するソースパケットの数を、(number_of_source_packets2 - SPN_chunk_start_2[n])によって計算して、
    前記第1の多重化ストリームのエクステントと前記第2の多重化ストリームのエクステントを分離し、
    前記制御部は、
    前記第1の情報ファイルにさらに含まれる情報であり、前記第1の多重化ストリーム中のエントリーポイントの数と、各エントリーポイントについての、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]と位置を表すソースパケット番号であるSPN_EP_start[i]とを含む情報であるEP_mapを読み出し、
    前記EP_mapに基づいて、指定された再生開始時刻よりも前の最も近い値を持つPTS_EP_start[m]を検出し、
    PTS_EP_start[m]に対応するSPN_EP_start[m]を検出し、
    SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start_1[k]とそのkを検出し、
    SPN_chunk_start_1[k]とSPN_chunk_start_2[k]の和を、前記インターリーブドファイルの読み出し開始アドレスとして決定する
    再生装置。
  2. 前記第1の情報ファイルが有する前記エクステントの数と、前記第2の情報ファイルが有する前記エクステントの数は、等しい数である
    請求項1に記載の再生装置。
  3. B[i]とD[i]について、iの値が同じ組のエクステントは同じ再生時間を有する
    請求項1または2に記載の再生装置。
  4. 前記基本ストリームと前記拡張ストリームは、それぞれ、ビデオストリームがH.264 AVC/MVCで符号化されることによって生成されたBase view video streamとDependent view video streamである
    請求項1乃至3のいずれかに記載の再生装置。
  5. 複数視点のビデオストリームを所定の符号化方式で符号化することによって生成された基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量の連続配置されるソースパケットの集まりであるエクステント単位でインターリーブされているファイルであるインターリーブドファイルを記録媒体から読み出し、
    前記第1の多重化ストリームに付随する情報であり、前記第1の多重化ストリームを構成するソースパケットの総数を表す情報、前記多重化ストリームを構成するエクステントの数を表す情報、各エクステントの前記第1の多重化ストリームの中での開始パケット番号を表す情報、および、前記第1の多重化ストリーム中のエントリーポイントの数と、各エントリーポイントについての、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]と位置を表すソースパケット番号であるSPN_EP_start[i]とを含む情報であるEP_mapを含む第1の情報ファイルと、前記第2の多重化ストリームに付随する情報であり、前記第2の多重化ストリームを構成するソースパケットの総数を表す情報、前記第2の多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第2の多重化ストリームの中での開始パケット番号を表す情報を含む第2の情報ファイルとを前記記録媒体から読み出し、
    前記第1および第2の情報ファイルに含まれる前記エクステントの数を(n+1)とし、前記第1の多重化ストリームを構成するエクステントをB[i](i=0〜n)、前記第1の多重化ストリームの先頭からk番目のエクステントをB[k]と表し、前記第2の多重化ストリームを構成するエクステントをD[i](i=0〜n)、前記第2の多重化ストリームの先頭からk番目のエクステントをD[k]と表し、B[k]の開始パケット番号を、SPN_chunk_start_1[k]と表し、D[k]の開始パケット番号を、SPN_chunk_start_2[k]と表し、前記第1の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets1と表し、前記第2の多重化ストリームを構成するソースパケットの総数を、number_of_source_packets2と表すとき、前記第1の情報ファイルと前記第2の情報ファイルを用いて、k=0〜(n-1)について、B[k]を構成するソースパケットの数を、(SPN_chunk_start_1[k+1] - SPN_chunk_start_1[k])によって計算し、k=0〜(n-1)について、D[k]を構成するソースパケットの数を、(SPN_chunk_start_2[k+1] - SPN_chunk_start_2[k])によって計算し、B[n]を構成するソースパケットの数を、(number_of_source_packets1 - SPN_chunk_start_1[n])によって計算し、D[n]を構成するソースパケットの数を、(number_of_source_packets2 - SPN_chunk_start_2[n])によって計算して、前記インターリーブドファイルを、前記第1の多重化ストリームのエクステントと前記第2の多重化ストリームのエクステントを分離し、
    前記EP_mapに基づいて、指定された再生開始時刻よりも前の最も近い値を持つPTS_EP_start[m]を検出し、PTS_EP_start[m]に対応するSPN_EP_start[m]を検出し、SPN_EP_start[m]より小さく最も近い値をもつSPN_chunk_start_1[k]とそのkを検出し、SPN_chunk_start_1[k]とSPN_chunk_start_2[k]の和を、前記インターリーブドファイルの読み出し開始アドレスとして決定するようにして、前記インターリーブドファイルの読み出しを制御する
    ステップを含む再生方法。
  6. 複数視点のビデオストリームを所定の符号化方式で符号化し、
    符号化することによって生成した基本ストリームと拡張ストリームのうちの前記基本ストリームを含む第1の多重化ストリームと、前記基本ストリームに対応する前記拡張ストリームを含む第2の多重化ストリームとが、所定のデータ量の連続配置されるソースパケットの集まりであるエクステント単位でインターリーブされているファイルであるインターリーブドファイルと、
    前記第1の多重化ストリームに付随する情報であり、前記第1の多重化ストリームを構成するソースパケットの総数を表す情報、前記多重化ストリームを構成するエクステントの数を表す情報、各エクステントの前記第1の多重化ストリームの中での開始パケット番号を表す情報、および、前記第1の多重化ストリーム中のエントリーポイントの数と、各エントリーポイントについての、PTS(Presentation Time Stamp)を表すPTS_EP_start[i]と位置を表すソースパケット番号であるSPN_EP_start[i]とを含む情報であるEP_mapを含む第1の情報ファイルと、
    前記第2の多重化ストリームに付随する情報であり、前記第2の多重化ストリームを構成するソースパケットの総数を表す情報、前記第2の多重化ストリームを構成するエクステントの数を表す情報、および各エクステントの前記第2の多重化ストリームの中での開始パケット番号を表す情報を含む第2の情報ファイルと
    を記録媒体に記録する
    ステップを含む記録方法。
JP2012029503A 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法 Expired - Fee Related JP4984195B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012029503A JP4984195B2 (ja) 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2009093159 2009-04-07
JP2009093159 2009-04-07
JP2012029503A JP4984195B2 (ja) 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2010065109A Division JP4984183B2 (ja) 2009-04-07 2010-03-19 再生装置、再生方法、および記録方法

Publications (2)

Publication Number Publication Date
JP2012138927A JP2012138927A (ja) 2012-07-19
JP4984195B2 true JP4984195B2 (ja) 2012-07-25

Family

ID=46394414

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2012029502A Active JP4985895B2 (ja) 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法
JP2012029503A Expired - Fee Related JP4984195B2 (ja) 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2012029502A Active JP4985895B2 (ja) 2009-04-07 2012-02-14 再生装置、再生方法、および記録方法

Country Status (1)

Country Link
JP (2) JP4985895B2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6222837B1 (en) * 1997-09-26 2001-04-24 Lucent Technologies Inc. Internet service via ISDN
CN102017640B (zh) * 2008-05-01 2012-11-28 松下电器产业株式会社 再现装置、集成电路与再现方法
KR20110126518A (ko) * 2009-02-19 2011-11-23 파나소닉 주식회사 기록매체, 재생장치 및 집적회로
RU2011103190A (ru) * 2009-02-27 2013-04-10 Панасоник Корпорэйшн Носитель записи, устройство воспроизведения и интегральная схема

Also Published As

Publication number Publication date
JP2012138927A (ja) 2012-07-19
JP2012104222A (ja) 2012-05-31
JP4985895B2 (ja) 2012-07-25

Similar Documents

Publication Publication Date Title
JP4993224B2 (ja) 再生装置および再生方法
JP4984183B2 (ja) 再生装置、再生方法、および記録方法
JP4957823B2 (ja) 再生装置および再生方法
JP5267886B2 (ja) 再生装置、記録媒体、および情報処理方法
JP2010263615A (ja) 情報処理装置、情報処理方法、再生装置、再生方法
JP2010244630A (ja) 情報処理装置、情報処理方法、プログラム、及び、データ構造
JP4962525B2 (ja) 再生装置、再生方法、およびプログラム
JP2010245970A (ja) 再生装置、再生方法、およびプログラム
JP4984181B2 (ja) 再生装置および再生方法
JP4984184B2 (ja) 再生装置および再生方法
JP4984195B2 (ja) 再生装置、再生方法、および記録方法
JP4984187B2 (ja) 記録方法
JP2010244629A (ja) 情報処理装置、情報処理方法、プログラム、および記録媒体
JP4984194B2 (ja) 記録方法
JP4993233B2 (ja) 記録方法
JP4984192B2 (ja) 記録方法
JP4984193B2 (ja) 再生装置、再生方法、および記録方法
JP4993234B2 (ja) 再生装置、再生方法、および記録方法
JP4985884B2 (ja) 再生装置、再生方法、および記録方法
JP2010244635A (ja) 情報処理装置、情報処理方法、再生装置、再生方法、プログラム、および記録媒体

Legal Events

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120329

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

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

Free format text: PAYMENT UNTIL: 20150511

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees