JP4022567B2 - 再生装置,集積回路,プログラム,再生方法 - Google Patents

再生装置,集積回路,プログラム,再生方法 Download PDF

Info

Publication number
JP4022567B2
JP4022567B2 JP2007129191A JP2007129191A JP4022567B2 JP 4022567 B2 JP4022567 B2 JP 4022567B2 JP 2007129191 A JP2007129191 A JP 2007129191A JP 2007129191 A JP2007129191 A JP 2007129191A JP 4022567 B2 JP4022567 B2 JP 4022567B2
Authority
JP
Japan
Prior art keywords
graphics
time
decoding
button
graphics data
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
JP2007129191A
Other languages
English (en)
Other versions
JP2007282260A (ja
Inventor
ジョセフ マクロッサン
智之 岡田
和寛 持永
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JP2007282260A publication Critical patent/JP2007282260A/ja
Application granted granted Critical
Publication of JP4022567B2 publication Critical patent/JP4022567B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; 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/30Indexing; 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/3027Indexing; 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
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; 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/30Indexing; 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/3027Indexing; 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
    • G11B27/3036Time code signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/84Television signal recording using optical recording
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/84Television signal recording using optical recording
    • H04N5/85Television signal recording using optical recording on discs or drums
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor
    • H04N5/92Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2541Blu-ray discs; Blue laser DVR discs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/78Television signal recording using magnetic recording
    • H04N5/782Television signal recording using magnetic recording on tape
    • H04N5/783Adaptations for reproducing at a rate different from the recording rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal

Description

BD-ROM等の記録媒体を再生する再生装置に関し、グラフィクス表示により字幕表示や対話表示を実現する技術に関する。
グラフィクスによる字幕表示は、登場人物の台詞を世界中のあらゆる地域に居住する人々に伝えるという重要な使命をもつ。字幕表示を実現する先行技術には、ETSI EN 300 743標準規格(ETSI:European Telecommunication Standards Institute)における字幕付けアプリケーションがある。字幕付けアプリケーションとは、グラフィクスによる字幕表示を伴いながら、再生されるビデオストリームである。ここで字幕にあたるグラフィクスは、MPEG2規格のデータストリームとして実現される。このデータストリームは、PESパケットの配列であり、個々のPESパケットはPTS(Presentation Time Stamp)をもっている。ETSI EN 300 743標準規格は、このPTSを用いて、字幕付けアプリケーションにおける字幕表示のタイミングを規定している。これによりビデオストリームのあるピクチャが表示されるタイミングで、グラフィクスを表示するという動画−グラフィクス間の同期が確立されることになる。これらの技術を記載した文献には、以下の非特許文献に掲げたものがある。
"Digital Video Broadcasting(DVB) Subtitling systems;Final draft ETSI EN 300 743"ETSI STANDARDS,EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE,SOPHIA-ANTIPO,FR
ところで、BD-ROMによる字幕付けアプリケーションの供給にあたっては、グラフィクスの解像度を更に高めたいとのニーズがある。具体的な数値を挙げれば、1920×1080というレベルにまで、解像度を向上したいと要請されている。しかしこのような高画質化を実現しようとすると、再生時のデコード負荷が膨大なものになる。
一方、ETSI EN 300 743標準規格に規定されているのは、PTSで示される時点にデコードを行い、即表示するという再生制御である。これをBD-ROMに応用しようとすると、再生装置においては、表示時点の直前において膨大なデコード負荷が集中することになる。かかる集中があると、再生装置のハードウェア・ソフトウェアの能力を高いレベルに設定することがグラフィクス表示の必須の条件になってしまう。かかる条件が必須になることは、再生装置の製造コストの高騰化を招き、再生装置の普及を阻害する。
本発明の目的は、製造コストの高騰化を避けつつも、グラフィクス表示の高画質化を図ることができる再生装置を提供することである。
上記目的を達成するため、本発明に係る再生装置は、動画ストリーム、グラフィクスストリームが多重化されたデジタルストリームについての再生装置であって、動画ストリームをデコードして動画像を得るビデオデコーダと、グラフィクスを、動画像に合成して表示させるグラフィクスデコーダとを備え、グラフィクスストリームは、複数パケットからなるパケット列であり、パケットには、グラフィクスデータを格納したデータパケットと、制御情報を格納した制御パケットとがあり、前記グラフィクスデコーダは、動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するプロセッサと、制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させるコントローラと、圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、再生装置は、オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
前記グラフィクスデータの個数は2つであり、制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、前記グラフィクスデータは2つであり、所定の値とは、期間Xと、期間Yとの和であり、期間Xは、画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和(a)、及び、2つのグラフィクスデータのデコードに要する総時間(b) のうち長いものであり、期間Yは、デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、前記コントローラは、メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行うことを特徴としている。
再生時間軸においてデコードが行われる期間の終期が、プレゼンテーションタイムスタンプのタイムスタンプに示される。グラフィクスの表示は、制御パケットに付加されたプレゼンテーションタイムスタンプの値により規定されるので、本発明では、「デコードはされたが表示はされていない状態」、つまり、非圧縮のグラフィクスがバッファリングされている状態を、再生時間軸上に定義することができる。
かかるバッファリング時期の定義により、膨大なデコード負荷の一点集中を回避することができる。またデコードを行うためのハードウェア資源の利用が、他の処理と競合したとしても、バッファリング時期を設けて、グラフィクスのデコード時期を変化させることができるので、かかる競合を回避することができる。
ここで、上述した目的達成にあたって、バッファリングの考えを導入すると、再生装置の開発に携わる技術者は、どの程度の規模で、メモリを実装すれば、正常動作を保証できるのかの判断に迷う。また字幕付けアプリケーションを製作する技術者も、自らが製作する字幕付けアプリケーションが、再生装置により確実に再生されるのかどうかという不安を抱く。何故なら、このバッファリングのためのメモリ占有量は、再生時間軸における再生進行に伴い、時間的な変遷を遂げるためである。メモリ占有量の時間的遷移が未知数のままになり、これを調整する術はないので、再生装置開発に携わる技術者や、字幕製作に携わる技術者の不安を払拭することはできない。
この問題を解決するため、御パケットは更に、デコードタイムスタンプを有しており、デコードタイムスタンプの値は、デジタルストリームの再生時間軸におけるメモリ管理の開始時点、及び、当該制御情報をメモリに読み出すタイミングとを示している。制御パケットのデコードタイムスタンプは、メモリ管理の始まりを示すので、これを参照すれば、再生時間軸上のどの時点で、デコーダモデルにおける各種バッファをフラッシュすればよいかを知得することができる。このフラッシュ時点をメモリ管理の起算点として考えれば、制御情報を格納するバッファや、デコード前のグラフィクスを格納するバッファ、デコード後のグラフィクスを格納するバッファの占有量の時間的変移が把握し易くなる。そしてこのデコードタイムスタンプの値を変化させることで、バッファ状態の時間的遷移を調整することができる。かかる調整により、再生装置側バッファのオーバーフローを回避することができるので、再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
また時間的変移の把握や調整が簡易になるので、オーサリングで得られたグラフィクスストリームが、BD-ROM規格が想定するデコーダモデルの制約を満たすかどうかの検証も容易になる。オーサリング担当者は、自身が作成したグラフィクスの正常動作の確信を得た上で、オーサリング作業を進めることができる。
BD-ROMのデコーダモデルを想定する場合、本発明の実施には更なる構成要件が必要となる。ここでBD-ROMのデコーダモデルにおいてグラフィクスのデコード主体(プロセッサ)は、グラフィクスのアップデートの制御主体(コントローラ)と別々の構成要素になっている。デコード主体と、アップデート制御の主体とを別々に設けておくのは、グラフィクスが字幕である場合、グラフィクスを徐々に表示したり、消したりするような高度なアップデートを実行するためである。アップデートの制御主体がデコード主体とは別であると、プロセッサ−コントローラ間の密なる連携が重要になる。何故なら、プロセッサがグラフィクスデータのデコードを完了した後、コントローラが遅滞なくアップデートを実行せねばならないからである。
プロセッサによるデコード完了をどのようにコントローラに通知するかは、装置におけるプロセッサ、コントローラの実装による。プロセッサ、コントローラがプログラムとして実装されている場合は、プロセス間通信でかかる通知はなされる。別々のハードウェア要素として実装されている場合は割込信号でかかる通知はなされる。かかる通知にタイムラグがどれだけ存在するかも、装置における実装による。そうすると、上述した通知のタイムラグが大きい実装であれば、グラフィクスのアップデートを動画の表示レートと同期させることができないケースが出現する。
これを避けるため、前記制御パケットのプレゼンテーションタイムスタンプの値は、制御パケットのデコードタイムスタンプの値に所定の値を足し合わせた値であり、所定の値は、画面クリアに要する時間、及び、グラフィクスデータのデコードに要する時間のうち長い方と、画面へのグラフィクスデータへの書き込みに要する時間とに基づき設定している
デコード終了時刻は、データパケットのプレゼンテーションタイムスタンプに示されており、制御パケットのプレゼンテーションタイムスタンプは、デコード終了時刻に所定の期間を足し合わせた時刻を示しているので、コントローラはプレゼンテーションタイムスタンプを参照しさえすれば、たとえプロセッサからグラフィクスデータのデコード完了の通知を受けなくても、適切なタイミングで、アップデートを実行することができる。かかるアップデートの実行により、再生装置における実装がどのようなものであろうと、動画の表示レートと同期したアップデートを保障することができる。
装置におけるプロセッサ−コントローラの実装を画一化することなく、プロセッサ−コントローラ間の密なる連携を実現することができるので、装置設計の自由度を守ることができ、装置の低コスト化を促進することができる。
(第1実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図1は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図1において、本発明に係る記録媒体は、BD-ROM100である。このBD-ROM100は、再生装置200、テレビ300、リモコン400により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、BD-ROMの応用層に対する改良により実施することができる。図2は、BD-ROMの構成を示す図である。
本図の第4段目にBD-ROMを示し、第3段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第1段目のようになる。本図に示すようにBD-ROMには、ROOTディレクトリの下にBDMVディレクトリがあり、BDMVディレクトリの配下には、AVClipを格納したファイル(XXX.M2TS)、AVClipの管理情報を格納したファイル(XXX.CLPI),AVClipにおける論理的な再生経路(PL)を定義したファイル(YYY.MPLS)が存在する。本図に示すようなアプリケーションフォーマットを作成することにより、本発明に係る記録媒体は生産される。尚、XXX.M2TS、XXX.CLPI,YYY.MPLSといったファイルが、それぞれ複数存在する場合は、BDMVディレクトリの配下に、STREAMディレクトリ、CLIPINFディレクトリ、PLAYLISTディレクトリという3つのディレクトリを設け、STREAMディレクトリにXXX.M2TSと同じ種別のファイルを、CLIPINFディレクトリにXXX.CLPIと同じ種別のファイルを、PLAYLISTディレクトリにYYY.MPLSと同じ種別のファイルを格納することが望ましい。
このアプリケーションフォーマットにおけるAVClip(XXX.M2TS)について説明する。
AVClip(XXX.M2TS)は、MPEG-TS(Transport Stream)形式のデジタルストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、プレゼンテーショングラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、プレゼンテーショングラフィクスストリームは、映画の字幕をそれぞれ示している。図3は、AVClipがどのように構成されているかを模式的に示す図である。
AVClipは(中段)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(上1段目)、PESパケット列に変換し(上2段目)、更にTSパケットに変換し(上3段目)、同じくプレゼンテーショングラフィクスストリーム(下1段目)を、PESパケット列に変換し(下2段目)、更にTSパケットに変換して(下3段目)、これらを多重化することで構成される。
本図において多重されるプレゼンテーショングラフィクスストリームは1つであるが、BD-ROMが多言語対応型である場合、その言語毎のプレゼンテーショングラフィクスストリームがAVClipに多重される。かかる過程を経て生成されたAVClipは、通常のコンピュータファイル同様、複数のエクステントに分割され、BD-ROM上の領域に記録される。
続いてプレゼンテーショングラフィクスストリームについて説明する。図4(a)は、プレゼンテーショングラフィクスストリームの構成を示す図である。第1段目は、AVClipを構成するTSパケット列を示す。第2段目は、グラフィクスストリームを構成するPESパケット列を示す。第2段目におけるPESパケット列は、第1段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。
第3段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、PCS(Presentation Composition Segment)、WDS(Window Defeine Segment)、PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、PCSは、画面構成セグメントと呼ばれ、WDS,PDS,ODS,ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。
図4(b)は、機能セグメントを変換することで得られるPESパケットを示す図である。図4(b)に示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。
これら様々な種別の機能セグメントは、図5のような論理構造を構築する。図5は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第3段目に機能セグメントを、第2段目にDisplay Setを、第1段目にEpochをそれぞれ示す。
第2段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線は、第3段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。
第1段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう(※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。)。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像−グラフィクスの同期は保証されない。
Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図6は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当は」「ウソだった」「あなたが」「ずっと」「すきだった」のうち、3つの字幕「本当は」「ウソだった」「あなたが」は画面の下側に、「ずっと」「すきだった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplay Setについて説明する。
図5における破線hk1,2は、第2段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。Epoch Start,Acquisition Point,Normal Caseという一連のDSは、第1段目のEpochを構成していることがわかる。『Epoch Start』、『Acquisition Point』、『Normal Case』、『Epoch Continue』は、DSの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。
『Epoch Start』は、”新表示”という表示効果をもたらすDSであり、新たなEpochの開始を示す。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。Epoch Startは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、”表示リフレッシュ”という表示効果をもたらすDisplay Setであり、先行するEpoch Startと全く同じDisplay Setをいう。Acquisition PointたるDSは、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、Acquisition PointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。
Acquisition PointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisition Pointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
『Normal Case』は、”表示アップデート”という表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvの字幕は、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、PCSのみのDSv、又は、PCSのみのDSvを設けてこのDSvをNormal CaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。一方、Normal CaseのDSは、差分にすぎないので、Normal Case単独では画面構成は行えない。
『Epoch Continue』とは、AVClipの境界において、Epochが連続していることを示す。1つのDSnのComposition StateがEpoch Continueに設定されていれば、たとえDSnが、その直前に位置するDSn-1と異なるAVClip上に存在していたとしても、同じEpochに属することになる。これらDSn,DSn-1は、同じEpochに帰属するので、たとえこれら2つのDS間で、AVClipの分岐が発生したとしても、グラフィックスプレーン、オブジェクトバッファのフラッシュは発生しない。
続いてDefinition Segment(ODS,WDS,PDS)について説明する。
『Object_Definition_Segment』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。BD-ROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BD-ROMでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。画素の色にあたっては、一画素当たりのインデックス値(赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値))のビット長が8ビットになっており、これによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。グラフィクスオブジェクトによる字幕は、透明色の背景に、文字列を配置することで描画される。
ODSによるグラフィクスオブジェクトの定義は、図7(a)に示すようなデータ構造をもってなされる。ODSは、図7(a)に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_in_sequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
『object_id』は、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する。グラフィクスストリームのEpochには、同じIDをもつODSが複数含まれる。同じIDをもつ複数のODSは縦横のサイズが同じであり、オブジェクトバッファの共通の領域が割り当てられる。同じIDをもつ複数ODSのうち1つが、この領域に読み出されれば、オブジェクトバッファにおけるODSは、同じIDをもつ後続のODSにより上書きされる。このように、ビデオストリームの再生進行に伴い、オブジェクトバッファ上のODSが、同じ識別子をもつ後続のODSにて上書きされることにより、ODSにおける絵柄は、時間的な変遷を遂げる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
『last_in_sequence_flag』、『object_data_fragment』について説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject_data_fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last_in_sequence_flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。
『Palette Difinition Segment(PDS)』は、色変換用のパレットを定義する情報である。PDSのデータ構造を図7(b)に示す。図7(b)に示すようにPDSは、自身がPDSであることを示す『segment_type』、PDSのデータ長を示す『segment_length』、このPDSに含まれるパレットを一意に識別する『pallet_id』、EpochにおけるEpochのPDSのバージョンを示す『pallet_version_number』、各エントリーについての情報『pallet_entry』からなる。『pallet_entry』は、各エントリーにおける赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値)を示す。
続いてWDSについて説明する。
『window_definition_segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”window”と呼ばれ、このWDSで定義される。図8(a)は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window_horizontal_position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window_vertical_position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window_width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。
window_horizontal_position、window_vertical_position、window_width、window_heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンの内部領域においてウィンドゥは、縦:video_height、横:video_widthという二次元状の大きさをもつ。
window_horizontal_positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0〜video_width-1の値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0〜video_height-1の値をとる。
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0〜video_width-window_horizontal_position-1の値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので0〜video_height-window_vertical_position-1の値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
続いて『END of Display Set Segment』について説明する。END of Display Set Segmentは、Display Setの伝送の終わりを示す指標であり、Display Setにおける機能セグメントのうち、最後のODSの直後に配置される。この END of Display SetSegmentの内部構成は、自身が END of Display SetSegmentであることを示す『segment_type』と、当該機能セグメントのデータ長を示す『segment_length』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
以上がODS、PDS、WDS、ENDについての説明である。続いてPCSについて説明する。
PCSは、対話的な画面を構成する機能セグメントである。PCSは、図8(b)に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id』と、『composition_object(1)〜(m)』とから構成される。
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、Epoch Startであるかを示す。
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、PalletOnly Displey Updateに用いられるべきパレットを示す。
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Set内の、個々のウィンドゥをどのように制御するかを示す情報である。図8(b)の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id』、『window_id』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
『object_id』は、composition_object(i)に対応するウィンドゥ内に存在するODSの識別子を示す。
『window_id』は、本PCSにおいて、グラフィクスオブジェクトに割り当てられるべきウィンドゥを示す。1つのウィンドゥには最大2つのグラフィクスオブジェクトが割り当てられる。
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_address』、『object_cropping_width』、『object_cropping_height』からなる。
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_address』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
『object_cropping_width』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。続いてPCSの具体的な記述について説明する。この具体例は、図6に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとは』『ウソだった』『あなたが』というように徐々に表示させるというものである。図9は、かかる字幕表示を実現するための記述例である。本図におけるEpochは、DS1(Epoch Start)、DS2(Normal Case)、DS3(Normal Case)を有する。DS1は、字幕の表示枠となるwindowを定義するWDS、台詞『ほんとは ウソだった あなたが』を表すODS、1つ目のPCSを備える。DS2(Normal Case)は、2つ目のPCSを有する。DS3(Normal Case)は3つ目のPCSを有する。
次に個々のPCSをどのように記述するかについて説明する。Display Setに属するWDS、PCSの記述例を図10〜図12に示す。図10は、DS1におけるPCSの記述例を示す図である。
図10において、WDSのwindow_horizontal_position、window_vertical_positionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、window_width,window_heightは、ウィンドゥの表示枠の横幅、縦幅を示す。
図10におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_positionは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして基準点からobject_cropping_width、object_cropping_heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてobject_horizontal_position,object_vertical_positionを基準点(左上)とした破線の範囲cp1に配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
図11は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図10と同じなので説明を省略する。クロップ情報の記述は、図10と異なる。図11におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。あなたが』のうち、『ウソだった』の左上座標を示し、object_cropping_height,object_cropping_widthは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
図12は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図10と同じなので説明を省略する。クロップ情報の記述は、図10と異なる。図12におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。あなたが』のうち、『あなたが』の左上座標を示し、object_cropping_height,object_cropping_widthは、『あなたが』の横幅、縦幅を示す。こうすることにより、『あなたが』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。
DS1,2,3のPCSを以上のように記述することで、字幕の表示効果を実現することができる。その他の表示効果を実現するにあたっての、PCSの記述作法について説明する。
先ず初めにCut-In/Outの記述作法について説明する。図13は、時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。
本図におけるwindow(x,y,u.v)におけるx,yは、window_vertical_position、window_horizontal_positionの値であり、u,vは、window_width、window_heightの値を示す。また本図のCropping Rectangle(a,b,c,d)におけるa,bは、object_cropping_vertical_position、object_cropping_horizontal_positionの値であり、c,dはobject_cropping_width、object_cropping_heightの値である。本図の再生時間軸の時点t11,t12,t13には、DS11,DS12,DS13が存在している。
時点t11に存在するDS11は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS#0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS#0、PDS#0、字幕「Credit:」を表すODS#0、ENDを有する。
時点t12に存在しているDS12は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle#0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS#1を含む。
時点t13に存在しているDS13は、Composition_StateがNormal Caseであり、クロップされたグラフィクスオブジェクトを消すよう、object_cropped_flagが0に設定されたPCS#2を含む(No Cropping Rectangle Visible)。
以上のDisplay Setにより、t11では字幕「Credit:」は非表示になっているが、t12で表示され、t13で再び非表示になる。これによりCut-In/Cut-Outという表示効果が実現される。
続いてFade-In/Outという表示効果を実現する際の、Display Setの記述作法について説明する。図14は、時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。本図の時点t21,t22,t23,t24には、DS21,DS22,DS23,DS24が存在している。
時点t21に存在するDS21は、Composition_StateがEpoch Startに設定され、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle#0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS#0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS#0、PDS#0、字幕「Fin」を表すODS#0、ENDを有する。
時点t22に存在しているDS22は、Composition_StateがNormal CaseであるPCS#1と、PDS#1とを含む。このPDS#1は、PDS#0と同じ色彩の赤色差、青色差を示しておりながら、高い輝度値をもっているものとする。
時点t23に存在しているDS23は、Composition_StateがNormal CaseであるPCS#3と,PDS#2と,ENDとを含む。このPDS#2は、PDS#0と同じ色彩の赤色差、青色差を示しておりながら、低い輝度値をもっているものとする。
時点t24に存在するDS24は、Composition_StateがNormal Caseに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS、ENDを有する。
これら一連のDisplay Setは、1つ前のDisplay Setと異なるPDSを指定しているため、Epoch内の複数PCSにおいて表示されるグラフィクスオブジェクトは、徐々に輝度値が高められたり、弱められることになる。これによりFade-In/Outという表示効果の実現が可能になる。
続いてScrollingの記述作法について説明する。図15は、時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。本図における表記は、図13の一例に準ずる。
AVClip再生時間軸の時点t31に存在するDS31は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS#0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS#0、PDS#0、字幕「Credit: Company」を表すODS#0、ENDを有する。
時点t32に存在するDS32は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle#0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window#0(0,0))という手順を示すPCS#1を含む。オブジェクトバッファにおいて(0,0)から横600×縦400の範囲には、「Credit:」「Company」という2段表記の字幕のうち「Credit:」が存在するので、この「Credit:」がグラフィックスプレーンに出現することになる。
時点t33に存在するDS33は、Composition_StateがNormal Caseであり、オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲を切り出し(Cropping Rectangle#0(0,100,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window#0(0,0))という手順を示すPCS#2を含む。オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲には、「Credit:」「Company」という2段表記の字幕のうち、「Credit:」の下半分と、「Company」の上半分とが存在するので、これらの部分がグラフィックスプレーンに出現することになる。
時点t34に存在するDS34は、Composition_StateがNormal Caseであり、オブジェクトバッファの座標(0,200)から横600×縦400の範囲を切り出し(Cropping Rectangle#0(0,200,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window#0(0,0))という手順を示すPCS#3を含む。オブジェクトバッファ上の座標(0,200)から横600×縦400の範囲には、「Credit:」「Company」という2段表記の字幕のうち、「Company」が存在するので、2段表記の字幕のうち「Company」の部分が画面上に現れることになる。以上のPCSの記述により、「Credit:」「Company」という2段表記の字幕の下スクロールがなされることになる。
続いてWipe-In/Outの記述作法について説明する。図16は、時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。本図における表記は、図13の一例に準ずる。
本図の時点t51に存在するDS51は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS#0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS#0、PDS#0、字幕「Fin」を表すODS#0、ENDを有する。
時点t52に存在するDS52は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle#0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window#0(0,0))という手順を示すPCS#1を含む。(0,0)から横600,縦400の範囲には、「Fin」という字幕が存在するので、この「Fin」がグラフィックスプレーンに出現することになる。
時点t53に存在するDS53は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(200,0)から縦400×横400の範囲でクロップを行い(Cropping Rectangle#0(200,0,400,400))、座標(200,0)を基準にして、表示を行わせるPCS#2を含む(on window#0(200,0))。そうすると、(200,0)〜(400,400)が表示範囲内になり、(0,0)〜(199,400)は、非表示範囲になる。
時点t54に存在するDS54は、Composition_StateがNormal Caseであり、オブジェクトバッファにおけるグラフィクスオブジェクトの(400,0)から横200×縦400の範囲でクロップを行い(Cropping Rectangle#0(400,0,200,400))、座標(400,0)を基準にして、ウィンドゥの表示を行わせる(on window#0(400,0))PCS#3を含む。そうすると、(0,0)〜(399,400)は、非表示範囲になる。
グラフィックスプレーンの非表示範囲が広がるに伴い、表示範囲が狭まるのでWipe-In/Outが実現されることになる。
このようにPCSの記述次第でCut-In/Out,Fade-In/Out,Wipe-In/Out,Scrollというような多様な表示効果を実現することができるので、字幕描画に様々な工夫を凝らすことができる。
かかる表示効果実現にあたっての制約について説明する。図13〜図16の表示効果のうち、Scrollingの実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。図15のt32−t33間で考えれば、Scrollingの実現のためには、t32における「Credit:」なるグラフィクスオブジェクトをグラフィックスプレーンから消し去るというウィンドゥクリアと、「Credit:」の下半分、「Company」の上半分をグラフィックスプレーンに書き込むというウィンドゥ再描画とをt32−t33の時間間隔で実現せねばならない。この時間間隔がビデオフレームの時間間隔である場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートをRcとすると、ワーストケースでは、この転送レートRcでウィンドゥクリアと、ウィンドゥ再描画とを行わねばならない。そうするとウィンドゥクリア、ウィンドゥ再描画のそれぞれをRcの半分の転送レート(Rc/2)で実現せねばならない。
これらウィンドゥクリア−ウィンドゥ再描画をビデオフレームと同期させるには、
ウィンドゥサイズ×フレームレート≒Rc/2
を満たす必要がある。このフレームレートが29.97であるなら、
Rcは、ウィンドゥサイズ×2×29.97になる。
字幕の表示にあたっては、グラフィックスプレーン全体に対し、最低でも25%〜33%程度の大きさが必要となる。ここでグラフィックスプレーンの総画素数は1920×1080であり、一画素当たりのインデックスのビット長を8ビットとすると、グラフィックスプレーンの総容量は2Mバイト(≒1920×1080×8)になる。
この総容量の1/4をウィンドゥサイズとすると、500kバイト(=2Mバイト/4)になる。これを上述した式に代入してRcを導けば、Rcは256Mbps(500Kバイト×2×29.97)と算出することができる。
この25%〜33%という大きさであれば、256Mbpsという転送レートで字幕の表示を行っている限り、如何なる表示効果を実現する場合であっても、動画との同期を維持することができる。
仮に、ウィンドゥクリア及び再描画のレートがビデオフレームのフレームレートの1/2,1/4でよいなら、Rcがたとえ同じであってもウィンドゥサイズを2倍,4倍にすることができる。以上がwindowの大きさについての説明である。続いて、windowの位置、範囲について説明する。上述したように、Epochにおいてウィンドゥの位置、範囲は一貫している。
Epochにおいてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
図17は、ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。グラフィクスオブジェクトが4つ存在する場合、エッジの数は8つになるのでグラフィクスオブジェクトが2つ存在する場合と比べると、エッジの数は2倍になっている。
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が2つまでであると、最悪4つのオーバーヘッドが発生すると見込んで転送レートを設定すればよいので、ミニマムスタンダードたる転送レートを数値化し易くなる。
以上がウィンドゥについての説明である。続いてこれらPCS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplay Setから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。Display Set内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplay Setの割り当てである。
先ず、ODSに付加されたDTS、PTSにより、どのような同期制御がなされるかについて説明する。
DTSは、ODSのデコードを開始すべき時間を90KHzの時間精度で示しており、PTSはデコード終了時刻を示す。
ODSのデコードは、瞬時には完了せず、時間的な長さをもっている。このデコード期間の開始点・終了点を明らかにしたいとの要望から、ODSについてのDTS、PTSはデコード開始時刻、デコード終了時刻を示している。
PTSの値はデッドラインであるので、PTSに示される時刻までにODSのデコードがなされて、非圧縮状態のグラフィックオブジェクトが、再生装置上のオブジェクトバッファに得られなければならない。
DSnに属する任意のODSjのデコード開始時刻は、90KHzの時間精度でDTS(DSn[ODS])に示されるので、これにデコードを要する最長時間を加えた時刻が、Display SetのODSjのデコード終了時刻になる。
ODSjのサイズを”SIZE(DSn[ODSj])”、ODSのデコードレートを”Rd”とすると、デコードに要する最長時間(秒)は、”SIZE(DSn[ODSj])//Rd”になる。ここで”//”は、小数点以下切り上げの割り算を示す演算子である。
この最長時間を90KHzの時間精度に変換し、ODSjのDTSに加算することにより、PTSで示されるべきデコード終了時刻(90KHz)は算出される。
DSnに属するODSjのPTSを、数式で表すと、以下の式のようになる。
PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)
そして互いに隣接する2つのODS(ODSj,ODSj+1)との間では、以下の関係を満たす必要がある。
PTS(DSn[ODSj])≦DTS(DSn[ODSj+1])
続いてPCSのDTS、PTSの設定について説明する。
PCSは、DSnにおける最初のODS(ODS1)のデコード開始時点(DTS(DSn[ODS1]))以前、及び、DSnにおける最初のPDS(PDS1)が有効になる時点(PTS(DSn[PDS1]))以前に、再生装置上のバッファにロードされねばならない。よって以下の式の関係を満たす値に、設定されねばならない。
DTS(DSn[PCS])≦DTS(DSn[ODS1])
DTS(DSn[PCS])≦PTS(DSn[PDS1])
そしてDSnにおけるPCSのPTSは、以下の数式から算出される。
PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)
ここでdecodeduration(DSn)は、PCSのアップデートに用いられる全グラフィクスオブジェクトのデコード時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本DSn.PCSnの画面合成に用いられるオブジェクトをDSn.PCSn.OBJ[j]とした場合、decodeduration(DSn)は、ウィンドゥクリアに要する時間(i)、DSn.PCSn.OBJのデコード期間(ii)、DSn.PCSn.OBJの書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
decode_durationの計算は、図18のプログラムに基づき行われる。また図19、図20(a)(b)は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図19のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図19のステップS1)。PLANEINITIALIZATINTIME関数(図20(a))は、Display Setを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図19のステップS1では、DSn,DSnPCS.OBJ[0],decode_durtationを引数に設定して、この関数を呼び出す。
続いて図20(a)を参照しながらPLANEINITIALIZATINTIME関数について説明する。図20(a)においてinitialize_durationとは、PLANEINITIALIZATINTIME関数の戻り値を示す変数である。
図20のステップS2は、DSnのPCSにおけるcomposition_stateがEpoch Startかどうかにより、処理を切り換えるif文である。もしcomposition_stateがEpoch Startであるなら(図18のDSn.PCS.composition_state==EPOCH_START、ステップS2=Yes)、グラフィックスプレーンのクリアに要する時間をinitialize_durationに設定する(ステップS3)。
オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、グラフィックスプレーンの総サイズをvideo_width*video_heightとすると、クリアに要する時間(秒)は、「video_width*video_height//256,000,000」になる。これに、90.000Hzを乗じPTSの時間精度で表現すれば、グラフィックスプレーンのクリアに要する時間は「90000×video_width*video_height//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。
もしcomposition_stateがEpoch Startでないなら(ステップS2=No)、WDSにて定義されるwindow[i]のクリアに要する時間をinitialize_durationに加えるという処理を全てのwindowについて繰り返す(ステップS4)。オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、WDSに属するウィンドゥ[i]の総サイズをΣSIZE(WDS.WIN[i])とすると、クリアに要する時間(秒)は、「ΣSIZE(WDS.WIN[i])//256,000,000」になる。これに、90.000Hzを乗じPTSの時間精度で表現すれば、WDSに属する全ウィンドゥのクリアに要する時間は「90000×ΣSIZE(WDS.WIN[i]))//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。以上がPLANEINITIALIZATINTIME関数である。
図19のステップS5は、DSnに属するグラフィクスオブジェクトの数が2であるか、1であるかで処理を切り換えるものであり(図18のif(DSn.PCS.num_of_object==2),if(DSn.PCS.num_of_object==1))、もし”1”であるなら(ステップS5=1)、グラフィクスオブジェクトのデコードを行うための待ち時間をdecode_durationに加える(ステップS6)。この待ち時間の算出は、WAIT関数の呼出(図18のdecode_duration +=WAIT(DSn,DSn.PCS.OBJ[0],decode_duration))で実現される。この関数呼出にあたっての引数はDSn,DSn.PCS.OBJ[0],decode_durationであり、待ち時間を示すwait_durationが戻り値として返される。
図20(b)は、WAIT関数の処理手順を示すフローチャートである。
このWAIT関数においてcurrent_durationとは、呼出元のdecode_durationが設定される。object_define_ready_timeは、Display Setのグラフィクスオブジェクト[i]のPTSが設定される変数である。
current_timeとは、DSnのPCSのDTSに、current_durationを足した値が設定される変数である。このcurrent_timeよりobject_define_ready_timeが大きい場合(ステップS7がYes、if(current_time < object_define_ready_time))、戻り値たるwait_durationは、object_define_ready_timeとcurrent_timeとの差分が設定されることになる(ステップS8、wait_duration += object_define_ready_time - current_time)。以上がWait関数である。ステップS6においてdecode_durationには、このwait関数の戻り値と、window再描画に必要な時間を足し合わせた時間(90,000*(SIZE(DSn.WDS.WIN[0]))//256,000,000)が設定されることになる。
以上はDSnのグラフィクスオブジェクトが1つである場合の処理である。図19のステップS5は、グラフィクスオブジェクトの数が2であるかどうかを判定している。DSnのグラフィクスオブジェクトが2以上であれば(図18のif(DSn.PCS.num_of_object==2))、PCSにおけるOBJ[0]を引数として、wait関数を呼び出し、その戻り値をdecode_durationに加算する(ステップS10)。
続くステップS11は、DSnのOBJ[0]が属するwindowが、グラフィクスオブジェクト[1]が属するwindowと同一かどうかの判定であり(if(DSn.PCS.OBJ[0].window_id == DSn.PCS.OBJ[1].window_id)、もし同一であるなら、OBJ[1]を引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップS12)。OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップS13)。
もし属するwindowが異なるなら(ステップS11で”異なる”)、OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップS15)。OBJ[1]を引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップS16)。その後、OBJ[1]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[1].window_id)//256,000,000)をdecode_durationに加える(ステップS17)。
以上のアルゴリズムにより、Decode_Durationは算出される。このPCSのPTSが、具体的にどのように設定されるかについて説明する。
図21(a)は、1つのwindowに1つのODSが存在するケースを想定した図である。図21(b)(c)は、図18で引用した各数値の時間的な前後関係を示すタイミングチャートである。本チャートには3つの段があり、これらの段のうち、”グラフィックスプレーンアクセス”の段、”ODSデコード”の段は、再生時にパラレルになされる2つの処理を示す。上述したアルゴリズムは、これらの2つの処理のパラレル実行を想定している。
グラフィックスプレーンアクセスは、クリア期間(1)、書き込み期間(3)からなる。このクリア期間(1)は、グラフィックスプレーン全体のクリアに要する期間(90,000×(グラフィックスプレーンのサイズ//256,000,000))、グラフィックスプレーンにおける全windowのクリアに要する時間(Σ(90,000×(window[i]のサイズ//256,000,000)))のどちらかを意味する。
書き込み期間(3)は、window全体描画に要する期間(90,000×(windowサイズ//256,000,000))を意味する。
一方、デコード期間(2)は、ODSのDTSからPTSまでに示される期間を意味する。 これらクリア期間(1)〜書き込み期間(3)は、クリアすべき範囲、デコードすべきODSのサイズ、グラフィックスプレーンに書き込むべきグラフィクスオブジェクトのサイズにより変化し得る。本図では、説明の簡略化のため、ODSのデコード期間(2)の始点は、クリア期間(1)の始点と同一であると仮定している。
図21(b)はデコード期間(2)が長くなるケースであり、Decode_Durationはデコード期間(2)+書き込み期間(3)になる。
図21(c)は、クリア期間(1)が長くなるケースであり、Decode_Durationはクリア期間(1)+書き込み期間(3)の期間がDecode_Durationになる。
図22(a)〜(c)は、1つのwindowに2つのODSが存在するケースを想定した図である。本図(b)(c)におけるデコード期間(2)は、2つのグラフィクスのデコードに要する期間の総和を意味する。グラフィクス書込期間(3)も、2つのグラフィクスをグラフィックスプレーンに書き込む期間の総和を意味する。ODSが2つになっているものの、図21と同様に考えればDecode_Durationを算出することができる。2つのODSをデコードするためのデコード期間(2)が長い場合は、図22(b)に示すようにDecode_Durationはデコード期間(2)+書き込み期間(3)に算出されることになる。
クリア期間(1)が長い場合は、図22(c)に示すように、Decode_Durationはクリア期間(1)+書き込み期間(3)となる。
図23(a)は、2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定している。この場合でもクリア期間(1)が、2つのODSをデコードするための総デコード期間(2)よリ長い場合、Decode_Durationはクリア期間(1)+書き込み期間(3)になる。問題は、クリア期間(1)がデコード期間(2)より短くなるケースである。この場合デコード期間(2)の経過を待たずに、1つ目のwindowへの書き込みは可能になる。そのためクリア期間(1)+書き込み期間(3)、デコード期間(2)+書き込み期間(3)の長さにはならない。ここで1つ目のODSのデコードに要する期間を書込期間(31)、2つ目のODSのデコードに要する期間を書込期間(32)とする。図23(b)は、デコード期間(2)がクリア期間(1)+書込期間(31)より長くなるケースを示す。この場合Decode_Durationは、デコード期間(2)+書込期間(32)になる。
図23(c)は、クリア期間(1)+書込期間(31)がデコード期間(2)より長くなるケースを示す。この場合Decode_Durationはクリア期間(1)+書込期間(31)+書込期間(32)になる。
グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またwindowのサイズ、ODSのサイズ、個数もオーサリングの段階で判明しているので、これらからDecode_Durationがクリア期間(1)+書き込み期間(3)、デコード期間(2)+書き込み期間(3)、デコード期間(2)+書込期間(32)、クリア期間(1)+書込期間(31)+書込期間(32)のどれかになる。こうしたDecode_Duration算出を基にPCSのPTSを設定すれば、ピクチャデータとの同期表示を高い時間精度で実現することができる。このような高精度な同期制御は、windowを定義し、クリア・再描画する範囲を、このwindowに限定することで成り立っているので、オーサリングの環境に、このwindowの概念を導入したことの意義は大きい。
続いてDSnにおけるWDSのDTS、PTSの設定について説明する。WDSのDTSは、以下の数式を満たすように設定すればよい。
DTS(DSn[WDS])≧DTS(DSn[PCS])
一方、DSnにおけるWDSのPTSは、グラフィックスプレーンに対する書き込みを開始すべきデッドラインを示す。グラフィックスプレーンへの書き込みは、ウィンドゥだけで足りるので、PCSのPTSに示される時刻から、WDSの書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。WDSの総サイズをΣSIZE(WDS.WIN[i])とすれば、これのクリア及び再描画に要する時間は、『ΣSIZE(WDS.WIN[i])//256,000,000』になる。そして、これを90.000KHzの時間精度で表現すると『90000×ΣSIZE(WDS.WIN[i])//256,000,000』になる。
故に以下の数式から、WDSのPTSを算出すればよい。
PTS(DSn[WDS])=PTS(DSn[PCS])-90000×ΣSIZE(WDS.WIN[i])//256,000,000
このWDSに示されるPTSはデッドラインなので、これより早い時点からグラフィックスプレーンの書き込みを開始してもよい。つまり図23に示すように、2つのウィンドゥのうち、1つのウィンドゥに表示させるべきODSのデコードが完了したなら、その時点からデコードにより得られたグラフィクスオブジェクトの書き込みを開始してもよい。
このようにWDSに付加されたDTS、PTSを用いてAVClipの再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上が再生時間軸に対するDisplay Setの割り当てについての説明である。
Display Setに対するDTS、PTSの設定について、図24〜図25の具体例を交えながら説明する。図24は、4回のグラフィックスプレーンへの書き込みにより字幕を表示することを想定した具体例である。この具体例は、2つの字幕『what is blu-ray』、『blu-ray is everywhere』を1つずつ表示させるというアップデートを想定している。図24は、本具体例が想定しているアップデートの、時間的変遷がどのようなものであるかを示す図である。時点t1では『what』までを表示し、続く時点t2では『what is』まで、時点t3では『what is blu-ray』全体を表示させる。字幕の全貌を明らかにした上で時点t4において別の字幕『blu-ray is everywhere』を表示させるのである。
図25(a)は、かかるアップデートを実現するため、記述された4つのDisplay Setを示す図である。DS1は、時点t1におけるアップデートを制御するPCS1.2と、彩色のためのPDS1と、字幕『what is blu-ray』に相当するODS1と、DS1の終了コードであるENDとからなる。
DS2は、時点t2におけるアップデートを制御するPCS1.2と、ENDとからなる。DS3は、時点t3におけるアップデートを制御するPCS1.3と、ENDとからなる。DS4は、時点t2のアップデートを制御するためのPCS2と、色変換のためのPDS2と、字幕『blu-ray is everywhere』に相当するODS2と、ENDとからなる。
これら4つのDisplay Setに属する各機能セグメントのDTS、PTSをどのように設定するかを、図25(b)のタイミングチャートを参照して説明する。
このタイミングチャートの再生時間軸は、図24の再生時間軸と同じものである。このタイミングチャートにおいて、PTS(PCS1.1)、PTS(PCS1.2)、PTS(PCS1.3)、PTS(PCS2)は、それぞれ『what』の表示時点t1,『what is』の表示時点t2,『what is blu-ray』の表示時点t3,『blu-ray is everywhere』の表示時点t4を示すよう設定される。これは、それぞれの字幕の表示時点において各PCSに記述された制御(Cropなど)を実行する必要があるからである。
PTS(ODS1),PTS(ODS2)は、PTS(PCS1.1)及びPTS(PCS2)の時点からDecode_Durationを差し引いた時点を示すよう設定されている。PTS(PCS)は、数式PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)を満たすよう設定する必要があるからである。
図25(b)では、時点t4より手前の時点t5を示すよう、PTS(ODS2)は設定されており、時点t1より手前の時点t0を示すよう、PTS(ODS1)は設定されている。DTS(ODS1),DTS(ODS2)は、PTS(ODS1)及びPTS(ODS2)の時点からデコード期間を差し引いた時点を示すよう設定されている。DTS(ODS)は、数式PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)を満たすよう設定する必要があるからである。図25(b)では、時点t5より手前の時点t0を示すよう、PTS(ODS2)は設定されており、時点t0より手前の時点を示すよう、PTS(ODS1)は設定されている。
ここでDTS(ODS2)=PTS(ODS1)の関係が満たされことがわかる。これにより再生装置の実装によっては、ODS1がオブジェクトバッファに読み出された後、このオブジェクトバッファ上のODS1を上書きする形で、ODS2を読み出すことができる。あるODSのPTSを、先に表示すべきODSのPTSに設定しておけば、古いODSを上書きする形で、新しいODSをメモリに読み出すという動作を再生装置が行うことにより、小メモリ規模での再生処理を実現することができる。かかる再生処理の実現により、再生装置におけるメモリ規模の選択の幅は広がる。
PCS1.1のDTSは、DTS(PCS1.1)=DTS(ODS1)になるように設定されている。これは、PCS1.1のDTS値は、DTS(ODS1)により示される時点以前であるなら、どの時点でもよいからである。
ODS1のPTS値、ODS2のDTS値、PCS1.2、PCS1.3、PCS2のPTS値は、PTS(ODS1)=DTS(ODS2)=PTS(PCS1.2)=PTS(PCS1.3)=DTS(PCS2)の関係を満たすよう、何れも時点t0に設定されている。
これは、PCS1.2、PCS1.3のDTS値は、PTS(PCS1.2)、PTS(PCS1.3)以前であれば、どの時点でもよく、またPCS2のDTS値も、DTS(PCS2)以前であれば、どの時点でもよいという自由度があるからである。これにより、複数のPCSをまとめて読み出しておき、前のPCSによるアップデートの実行が終われば続くPCSによるアップデートを即座に実行することができる。
PCSのDTS・PTS、ODSのDTS・PCSは、上述の数式で示したような不等号の関係さえ最低限満たせばよいので、DTS(ODS2)=PTS(ODS1)になるように設定したり、PTS(ODS1)=DTS(ODS2)=PTS(PCS1.2)=PTS(PCS1.3)=DTS(PCS2)になるように設定することも可能になる。こうしたタイムスタンプの設定により、デコード負荷が発生する期間やバッファの占有量が増える期間を、調整することができる。かかる調整が可能になるので、再生時になしえる再生制御の幅が広がり、オーサリングを行う技術者及び再生装置を製造する技術者にとってのメリットは大きい。これで、DTS,PTS設定の具体例の説明を終える。
以上説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-ray Disc Prerecording Formatに規定された構文に従い、クラス構造体を記述することで、BD-ROM上のこれらのデータ構造を得ることができる。 以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図26は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置、マイコンシステムという3つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BDドライブ1、Read Buffer2、PIDフィルタ3、Transport Buffer4a,b,c、周辺回路4d、ビデオデコーダ5、ビデオプレーン6、オーディオデコーダ7、グラフィクスプレーン8、CLUT部9、加算器10、グラフィクスデコーダ12、Coded Data Buffer13、周辺回路13a、Stream Graphics Processor14、Object Buffer15、Composition Buffer16、Graphical Controller17から構成される。
BD-ROMドライブ1は、BD-ROMのローディング/リード/イジェクトを行い、BD-ROMに対するアクセスを実行する。
Read Buffer2は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
PIDフィルタ3は、Read Buffer2から出力される複数TSパケットに対してフィルタリングを施す。PIDフィルタ3によるフィルタリングは、TSパケットのうち、所望のPIDをもつもののみをTransport Buffer4a,b,cに書き込むことでなされる。PIDフィルタ3によるフィルタリングでは、バッファリングは必要ではない。従って、PIDフィルタ3に入力されたTSパケットは、時間遅延なく、Transport Buffer4a,b,cに書き込まれる。
Transport Buffer4a,b,cは、PIDフィルタ3から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。このTransport Buffer4a,b,cからTSパケットが取り出される速度を速度Rxとする
周辺回路4dは、Transport Buffer4a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCoded Data Buffer13に格納される。
ビデオデコーダ5は、PIDフィルタ3から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン6に書き込む。
ビデオプレーン6は、動画用のプレーンメモリである。
オーディオデコーダ7は、PIDフィルタ3から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
グラフィクスプレーン8は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
CLUT部9は、グラフィクスプレーン8に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
加算器10は、CLUT部9により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン6に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
グラフィクスデコーダ12は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン8に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。このグラフィクスデコーダ12は、Coded Data Buffer13、周辺回路13a、Stream Graphics Processor14、Object Buffer15、Composition Buffer16、Graphical Controller17から構成される。
Coded Data Buffer13は、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、Transport Buffer4a,b,cに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS/DTSは、PESパケットと対応付けて格納される。
周辺回路13aは、Coded Data Buffer13−Stream Graphics Processor14間の転送、Coded Data Buffer13−Composition Buffer16間の転送を実現するワイヤロジックである。この転送処理において現在時点がODSのDTSに示される時刻になれば、ODSを、Coded Data Buffer13からStream Graphics Processor14に転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをComposition Buffer16に転送するという処理を行う。
Stream Graphics Processor14は、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObject Buffer15に書き込む。このStream Graphics Processor14によるデコードは、ODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。上述したグラフィックオブジェクトのデコードレートRdは、このStream Graphics Processor14の出力レートである。
Object Buffer15は、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor14のデコードにより得られたグラフィクスオブジェクトが配置される。Object Buffer15は、グラフィクスプレーン8の2倍/4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン8の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
Composition Buffer16は、PCS、PDSが配置されるメモリである。
Graphical Controller17は、Composition Buffer16に配置されたPCSを解読して、PCSに基づく制御をする。この制御の実行タイミングは、PCSに付加されたPTSの値に基づく。以上が再生装置の構成要素である。
続いて、PIDフィルタ3、Transport Buffer4a,b,c、グラフィクスプレーン8、CLUT部9、Coded Data Buffer13〜Graphical Controller17を構成するための、転送レート、バッファサイズの推奨値について説明する。図27は、書込レートRx,Rc,Rd、グラフィクスプレーン8、Coded Data Buffer13、Object Buffer15、Composition Buffer16のサイズを示す図である。
Object Buffer15−グラフィクスプレーン8間の転送レートRcは、本装置において最も高い転送レートであり、ウィンドゥサイズ、フレームレートから256Mbps(=500Kバイト×29.97×2)と算出される。
Stream Graphics Processor14−Object Buffer15間の転送レートRd(Pixel Decoding Rate)は、Rcとは異なり、ビデオフレームの周期によるアップデートは要求されずRcの1/2,1/4でよい。故に128Mbps,64Mbpsになる。
Transport Buffer4a,b,c−Coded Data Buffer13間のTransport Buffer LeakレートRxは、圧縮状態たるODSの転送レートである。従ってTransport Buffer Leakレートは、Rdに圧縮率を乗じた転送レートでよい。ODSの圧縮率を25%と仮定すれば、16Mbps(=64Mbps×25%)で足りる。
この図に示す転送レート、バッファ規模はあくまでもミニマムスタンダードであり、これより大きい値での実装を否定している訳ではない。
以上のように構成された再生装置において、各構成要素はパイプライン式にデコード処理を行うことができる。
図28は、再生装置によるパイプライン処理を示すタイミングチャートである。第5段目は、BD-ROMにおけるDisplay Setを示し、第4段目は、Coded Data Buffer13へのPCS、WDS、PDS、ODSの読出期間を示す。第3段目は、Stream Graphics Processor14による各ODSのデコード期間を、第2段目はComposition Buffer16の格納内容を、第1段目はGraphical Controller17の処理内容を示す。
ODS1,2に付与されたDTS(デコード開始時刻)は、図中のt31,t32の時点を示している。デコード開始時刻がDTSに規定されているので、各ODSは、自身のDTSに示される時刻までにCoded Data Buffer13に読み出されなければならない。そのためODS1の読み出しは、Coded Data Buffer13へのODS1のデコード期間dp1の直前までに完了している。Coded Data Buffer13へのODS2の読み出しは、ODS2のデコード期間dp2の直前までに完了している。
一方、ODS1,2に付与されたPTS(デコード終了時刻)は、図中のt32,t33の時点を示している。Stream Graphics Processor14によるODS1のデコードはt32までに完了し、ODS2のデコードは、t33に示される時刻までに完了する。以上のように、Stream Graphics Processor14は、各ODSのDTSに示される時刻までに、ODSをCoded Data Buffer13に読み出し、Coded Data Buffer13に読み出されたODSを、各ODSのPTSに示される時刻までに、デコードしてObject Buffer15に書き込む。
本図の第1段目における期間cd1は、Graphics Controller17がグラフィクスプレーン8をクリアするのに要する期間である。また期間td1は、Object Buffer15上にえられたグラフィクスオブジェクトを、グラフィクスプレーン8に書き込むのに要する期間である。WDSのPTSは、この書き込みの開始にあたってのデッドラインを示し、PCSのPTSはこの書き込みの終了時点及び表示タイミングを示す。このPCSのPTSに示される時点になれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン8上に得られることになる。この非圧縮グラフィクスの色変換をCLUT部9に行わせ、ビデオプレーン6に格納されている非圧縮ピクチャとの合成を加算器10に行わせれば、合成画像が得られることになる。
グラフィクスデコーダ12において、Graphics Controller17がグラフィクスプレーン8のクリアを実行している間においても、Stream Graphics Processor14のデコードは継続して行われる。以上のようなパイプライン処理により、グラフィクスの表示を迅速に実施することができる。
図28では、グラフィックスプレーンのクリアが、ODSのデコードより早く終わる場合を想定したが、図29は、ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。この場合、ODSのデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
再生装置におけるバッファ占有量の時間的遷移について図30を参照しながら説明する。図30は、図26におけるCompositionバッファ16、Object Buffer15、Coded Dataバッファ13、グラフィクスプレーン8の時間的遷移を示すタイミングチャートである。本図は、第1段目から第4段目までに、グラフィクスプレーン8、Object Buffer15、Coded Dataバッファ13、Compositionバッファ16における占有量の時間的遷移を示している。この占有量の時間的遷移は、横軸を時間軸とし、縦軸を占有量とした折れ線グラフの表記で表現している。
図30の第4段目は、Compositionバッファ16における占有量の時間的遷移を示す。本図に示すようにCompositionバッファ16の時間的遷移は、Coded Dataバッファ13から出力されPCSが格納されることによる単調増加vf0を含む。
第3段目は、Coded Dataバッファ13における占有量の時間的遷移を示す。本図に示すようにCoded Dataバッファ13の時間的遷移は、ODSが格納されることによる単調増加Vf1,Vf2と、格納されたODSが順次Stream Graphicsプロセッサ14により取り出されることによる単調減少Vg1,Vg2とを含む。単調増加Vf1,Vf2の傾きは、Transportバッファ4a,b,cからCoded Dataバッファ13への出力レートRxに基づき、単調減少Vg1,Vg2の傾きは、Stream Graphicsプロセッサ14によるデコードであり、瞬時に実行される。つまりODSに対するデコードは瞬時に行われ、Stream Graphicsプロセッサ14は、デコードにより得られた非圧縮グラフィクスを保持する。Stream Graphicsプロセッサ14からObject Buffer15への伝送路の書込レートは128Mbpsであるため、この書込レートにより、Object Buffer15の占有量は増加する。
第2段目は、Object Buffer15における占有量の時間的遷移を示す。本図に示すようにObject Buffer15の時間的遷移は、Stream Graphicsプロセッサ14から出力されたODSが格納されることによる単調増加Vh1,Vh2を含む。単調増加Vh1,Vh2の傾きは、Stream Graphicsプロセッサ14からObject Buffer15への転送レートRcに基づく。第3段目の単調減少が生じる期間及びの第2段目の単調増加が生ずる期間が、デコード期間である。このデコード期間の始期は、ODSのDTSに示されており、デコード期間の終期は、ODSのPTSに示されている。このODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer15に格納されれば、ODSに対するデコードは完了したことになる。ODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer15に格納されることが、必須の要件であり、このデコード期間における単調増加、単調減少はどのようなものであってもよい。
第1段目は、グラフィクスプレーン8における占有量の時間的遷移を示す。本図に示すようにグラフィクスプレーン8の時間的遷移は、Object Buffer15から出力されたデコード済みODSが格納されることによる単調増加Vf3を含む。単調増加Vf3の傾きは、Object Buffer15からグラフィクスプレーン8への転送レートRdに基づく。この単調増加の終期は、ODSのPTSに示されている。
ODSに付与されたDTS、PTS、ICSに付与されたDTS、PTS、そして図27に示した各バッファのサイズ、転送レートを用いれば、本図のようなグラフを作図することにより、BD-ROMにて供給すべきAVClipの再生時において、各バッファの状態がどのように変化するかが、オーサリングの段階で明らかになる。
このバッファ状態の遷移は、DTS、PTSに示される値を書き換えることで、調整することが可能なので、再生装置側のデコーダのスペックを越えるような復号負荷の発生を回避したり、再生にあたってのバッファオーバーフローの回避することができる。そのため再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
以上が再生装置の内部構成である。続いて制御部20及びグラフィクスデコーダ12を、どのようにして実装するかについて説明する。制御部20は、図31の処理手順を行うプログラムを作成し、汎用CPUに実行させることにより実装可能である。以降、図31を参照しながら、制御部20の処理手順について説明する。
図31は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(PCS,WDS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップS21〜S24、ステップS27〜S31の処理を全てのSegmentKについて繰り返すループ構造を有している(ステップS25、ステップS26)。
ステップS21は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップS27、ステップS28の判定を行う。
ステップS22は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップS23に移行し、1であるならステップS24に移行する。無視フラグが1であれば(ステップS22でYes)、ステップS23においてSegmentKをCoded Data Buffer13にロードする。
無視フラグが0に設定されていれば(ステップS22がNo)、ステップS24においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップS22がNoになって、無視されることになる(ステップS24)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップS27〜S31、S34、S35は、この無視フラグを設定する処理である。
ステップS27は、PCSにおけるComposition_stateがAcquisition Pointであるか否かの判定である。SegmentKがAcquisition Pointであるなら、ステップS28に移行し、SegmentKがもしEpoch StartかNormal Caseであるなら、ステップS31に移行する。
ステップS28は、先行するDSがグラフィクスデコーダ12内のどれかのバッファ(Coded Data Buffer13、Stream Graphicsプロセッサ14、Object Buffer15、Composition Buffer16)に存在するかどうかの判定であり、ステップS27がYesである場合に実行される。グラフィクスデコーダ12内にDSが存在しないケースとは、頭出しがなされたケースをいう。この場合、Acquisition PointたるDSから、表示を開始せねばならないので、ステップS30に移行する(ステップS28でNo)。
ステップS30は、無視フラグを0に設定し、ステップS22に移行する。
グラフィクスデコーダ12内にDSが存在するケースとは、通常再生がなされたケースをいう。この場合、ステップS29に移行する(ステップS28でYes)。ステップS29は、無視フラグを1に設定し、ステップS22に移行する。
ステップS31は、PCSにおけるComposition_stateがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップS34に移行する。SegmentKがEpoch Startであるなら、ステップS30において無視フラグを0に設定する。 ステップS34は、ステップS28と同じであり、先行するDSがグラフィクスデコーダ12内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップS30)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップS35)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ12に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
DSが、図32のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図32の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、Composition_stateがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図31のフローチャートの対象となる。ステップS27においてComposition_stateはAcquisition Pointと判定されるが、先行するDSはCoded Data Buffer13上に存在しないため、無視フラグは0に設定され、このDS10が図33の矢印md1に示すように再生装置のCoded Data Buffer13にロードされる。一方、頭出し位置がDS10の存在位置より後である場合(図32の矢印am2)、DS20は、Normal CaseのDisplay Setであり、先行するDS20はCoded Data Buffer13に存在しないので、このDisplay Setは、無視されることになる(図33の矢印md2)。
図34のように通常再生が行われた場合のDS1,10,20のロードは、図34に示すものとなる。3つのDSのうち、PCSのComposition_stateがEpoch StartであるDS1は、そのままCoded Data Buffer13にロードされるが(ステップS23)、PCSのComposition_stateがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップS29)、これを構成する機能セグメントはCoded Data Buffer13にロードされず無視される(図35の矢印rd2,ステップS24)。またDS20については、PCSのComposition_stateはNormal Caseなので、Coded Data Buffer13にロードされる(図35の矢印rd3)。
続いてGraphical Controller17の処理手順について説明する。図36〜図38は、Graphical Controller17の処理手順を示すフローチャートである。
ステップS41〜ステップS44は、本フローチャートのメインルーチンであり、ステップS41〜ステップS44に規定した何れかの事象の成立を待つ。
ステップS41は、現在の再生時点がPCSのPTS時刻になっているか否かの判定であり、もしなっていれば、ステップS45〜ステップS53の処理を行う。
ステップS45は、PCSのcomposition_stateが、Epoch_Startであるか否かの判定であり、もしEpoch Startであるなら、ステップS46においてグラフィクスプレーン8を全クリアする。それ以外であるなら、ステップS47においてWDSのwindow_horizontal_position、window_vertival_position、window_width、window_heightに示されるwindowをクリアする。
ステップS48は、ステップS46又はステップS47でのクリア後の実行されるステップであり、任意のODSxのPTS時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン8全体のクリアにあたっては、そのクリア時間に長時間を費するので、あるODS(ODSx)のデコードが既に完了していることもある。ステップS48はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかのODSのデコード時刻を経過しているなら、ステップS49〜ステップS51を実行する。ステップS49は、object_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップS50)。
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいて object_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップS51)。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
ステップS52は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン8に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして(ステップS53)、ステップS49に移行する。これにより、別のODSに対しても、ステップS49〜S51の処理が繰り返し行われる。
次に図37を参照して、ステップS42、ステップS54〜ステップS59について説明する。
ステップS42は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップS54においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップS55〜ステップS59のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップS57〜ステップS59を実行するというものである。ステップS57は、object_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップS58)。
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいて object_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップS59)。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
ステップS44は、現在の再生時点がPCSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップS60においてPallet_update_flagが1を示しているか否かを判定する。もし1を示しているなら、pallet_idに示されるPDSをCLUT部に設定する(ステップS61)。0を示しているなら、ステップS61をスキップする。
その後、グラフィクスプレーン8におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する(ステップS62)。
次に図38を参照して、ステップS43、ステップS64〜ステップS66について説明する。
ステップS43は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップS63においてウィンドゥが2つであるか否かを判定し、もし1つであれば、メインルーチンにリターンする。ウィンドゥが2つであるなら、ステップS64〜ステップS66を行う。ステップS64は、object_crop_flagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする(ステップS65)。
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいて object_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップS66)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
以上、DSnに属するPCSのDTS,PTS,ODSのDTS、PTSの設定について説明したが、PDSのDTS、PTS、ENDのDTS、PTSについては説明していない。先ず、DSnに属する各PDSのDTS,PTSの設定について説明する。
DSnに属する各PDSは、PCSがComposition Buffer16にロードされる時点(DTS(DSn[PCS]))から、最初のODSのデコード開始時点(DTS(DSn[ODS1]))までに、CLUT部9において、有効になればよい。このことからDSnに属する各PDS(PDS1〜PDSlast)のPTS値は、以下の関係を満たす値に、設定されねばならない。
DTS(DSn[PCS])≦PTS(DSn[PDS1])
PTS(DSn[PDSj])≦PTS(DSn[PDSj+1])≦PTS(DSn[PDSlast])
PTS(DSn[PDSlast])≦DTS(DSn[ODS1])
尚、PDSにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
以上の関係を満たすようDTS、PDSが設定された場合、再生装置のパイプラインにおいてこれらDTS、PTSがどのような役割をもつかについて説明する。図39はPDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。この図39は、図28をベースにして作図されている。図39において第1段目は、CLUT部9へのPDS設定を示している。以降の段は、図28の第1〜第5段目と同じである。PDS1〜lastのCLUT部9への設定は、ODS1のデコード開始と同時になされる(矢印up2,up3)。
続いてDSnに属するEND of Display SetSegmentのPTSの設定について説明する。DSnに属するENDは、DSnの終わりを示すものだから、ODS2のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2(ODSlast)のPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定されねばならない。
PTS(DSn[END]) = PTS(DSn[ODSlast])
DSn,DSn+1に属するPCSとの関係で考えれば、DSnにおけるPCSは、最初のODS(ODS1)のロード時刻以前に、Composition Buffer16にロードされるから、ENDのPTSは、DSnに属するPCSのロード時刻(DTS(DSn[PCS]))以降、DSn+1に属するPCSのロード時刻(DTS(DSn+1[PCS]))以前でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
DTS(DSn[PCS])≦PTS(DSn[END])≦DTS(DSn+1[PCS])
一方、最初のODS(ODS1)のロード時刻は、最後のPDS(PDSlast)のロード時刻以前であるから、ENDのPTS(PTS(DSn[END]))は、DSnに属するPDSのロード時刻以降(PTS(DSn[PDSlast]))でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
PTS(DSn[PDSlast])≦PTS(DSn[END])
続いて再生装置のパイプラインにおいて、ENDのPTSが、どのような意味合いをなすのかについて説明する。図40は、再生装置のパイプライン動作時における、ENDの意味合いを示す図である。本図は、図28の第2段目以降をベースに作図しており、第2段以降の意味合いは図28と同一である。また本図では、DSn,DSn+1という2つのDisplay Setを描いている。DSnにおいてODSlastになるのは、A-ODSsの最後のODSnであるので、ENDのPTSは、このODSnのPTSを示すよう設定されている。そして、このENDのPTSに示される時点は、DSn+1のPCSのDTSにより示される時点より早いものになっている。
このENDのPTSにより、再生時にあたっては、DSnについてのODSのロードが、どの時点で完了するのかを知得することができる。
尚、ENDにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
以上のように本実施形態によれば、グラフィックスプレーンの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。グラフィックスプレーンの25%〜33%など、ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。グラフィックスプレーンのうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
グラフィックスプレーンの1/4等、グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、再生装置は、256Mbps等、ある決まった転送レートでグラフィックスプレーンの書き込みを行いさえすれば、ピクチャとの同期を実現することができる。
同期保証が容易になるので、高い解像度での字幕表示を多くの再生装置において実現することができる。
(第2実施形態)
第1実施形態は、専ら、字幕として表示されるためのグラフィクスについて説明した。これに対し第2実施形態は、対話的に表示されるグラフィクスについての実施形態する。
本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。第2実施形態に係る記録媒体も、第1実施形態同様、BD-ROMの応用層に対する改良により実施することができる。図41は、第2実施形態に係るAVClipがどのように構成されているかを模式的に示す図である。
AVClipは(中段)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(上1段目)、PESパケット列に変換し(上2段目)、更にTSパケットに変換し(上3段目)、同じくインタラクティブグラフィクスストリーム(下1段目)を、PESパケット列に変換し(下2段目)、更にTSパケットに変換して(下3段目)、これらを多重化することで構成される。
続いてインタラクティブグラフィクスストリームについて説明する。インタラクティブグラフィクスストリームには、PCSの代わりにICS(Interactive Composition Segment)があり、WDSは存在しない。PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントが存在する点は、プレゼンテーショングラフィクスストリームと同じである。
これらの機能セグメントにより定義される対話画面は、画面上にGUI部品を配置することにより作成される対話画面である。図42(a)は、インタラクティブグラフィクスストリームにより実現される対話画面を示す図である。この対話画面は、ボタンA〜ボタンDという4つのGUI部品を含む。インタラクティブグラフィクスストリームによる対話性とは、これらのGUI部品(ボタン)の状態をユーザ操作に応じて変化させることをいう。GUI部品(ボタン)における状態には、図42(a)に示すノーマル状態bt1、セレクテッド状態bt2、アクティブ状態bt3といったものがある。ノーマル状態とは、単に表示されているに過ぎない状態である。これに対しセレクテッド状態とは、ユーザ操作によりフォーカスが当てられているが、確定に至っていない状態をいう。アクティブ状態とは、確定に至った状態をいう。これらのボタンの状態は、第1実施形態に示したリモコン400のキーの押下により、変化させることができる。
図42(b)は、対話画面に対する操作をユーザから受け付けるためのリモコン400におけるキーを示す図である。本図に示すようにリモコン400は、MoveUpキー、MoveDownキー、MoveRightキー、MoveLeftキーが設けられている。
MoveUpキーは、対話画面においてあるボタンがセレクテッド状態である場合、このボタンより上にあるボタンをセレクテッド状態に設定するためのキーである。MoveDownキーは、このボタンより下にあるボタンをセレクテッド状態に設定するためのキー、MoveRightキーは、このボタンより右にあるボタンをセレクテッド状態に設定するためのキー、MoveLeftキーは、このボタンより左にあるボタンをセレクテッド状態に設定するためのキーである。
Activatedキーは、セレクテッド状態にあるボタンをアクティブ状態(アクティベート)するためのキーである。「0」〜「9」の数値キーは、該当する数値が割り当てられたボタンをセレクテッド状態にするキーである。「+10」キーとは、これまで入力された数値に10をプラスするという操作を受け付けるキーである。尚、「0」キー、「+10」キーは、何れも2桁以上の数値の入力を受け付けるものなので、「0」キー、「+10」キーは、どちらかが具備されていればよい。
ノーマル状態、セレクテッド状態、アクティブ状態といった各状態は、複数の非圧縮状態のグラフィクスから構成される。ボタンの各状態を表現する個々の非圧縮グラフィクスを”グラフィクスオブジェクト”という。あるボタンの1つの状態を、複数の非圧縮グラフィクスで表現しているのは、各ボタンの1つの状態をアニメーション表示することを念頭に置いているからである。
以上が本実施形態が想定している対話画面についての説明である。続いて本実施形態におけるDefinition Segment(ODS、PDS)の改良について説明する。ODS、PDSは、第1実施形態と同様のデータ構造を有している。差違は、ODSについての『object_ID』にある。第2実施形態におけるODSは、複数ODSにより定義される複数グラフィックスオブジェクトを用いてアニメーションを構成する。そしてアニメーションを構成するにあたって、一連のODSに、連番たる『object_ID』を付加する。以上がODS、PDSについての説明である。
続いてICSについて説明する。Interactive Composition Segmentは、対話的な画面を構成する機能セグメントである。Interactive Composition Segmentは、図43に示すデータ構造で構成される。本図に示すようにICSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『command_update_flag』と、『Composition_timeout_PTS』と、『Selection_timeout_PTS』と、『UO_Mask_Table』と、『animation_frame_rate_code』と、『default_selected_button_number』と、『default_activated_button_number』と、『ボタン情報群(button info(1)(2)(3)・・・・)』とからなる。
『Composition_Number』は、ICSが属するDSにおいて、Updateがなされることを示す0から15までの数値である。
『composition_state』は、本ICSから始まるDSが、Normal Caseであるか、Acquisition
Pointであるか、Epoch Startであるかを示す。
『command_update_flag』は、本ICS内のボタンコマンドは、前のICSから変化しているかを否かを示す。例えば、あるICSが属するDSが、Acquisition Pointであれば、このICSは、原則1つ前のICSと同じ内容になる。しかしcommand_update_flagをオンに設定しておけば、1つ前のICSと違うボタンコマンドをICSに設定しておくことができる。本フラグは、グラフィックスオブジェクトは流用するが、コマンドは変更したい場合に有効となる。
『Composition_timeout_PTS』は、ボタンによる対話画面の終了時刻を記述する。終了時刻において対話画面の表示は、もはや有効ではなく表示されない。Composition_timeout_PTSは、動画データにおける再生時間軸の時間精度で記述しておくことが好ましい。
『Selection_Time_out_PTS』は、有効なボタン選択期間の終了時点を記述する。Selection_Time_out_PTSの時点において、Default_activated_button_numberにより特定されるボタンがアクティベートされる。Selection_Time_out_PTSは、Composition_timeout_PTSの時間と等しいかそれより短い。Selection_Time_out_PTSはビデオフレームの時間精度で記述される。
『UO_Mask_Table』は、ICSに対応するDisplay Setにおけるユーザ操作の許可/不許可を示す。このマスクフィールドが不許可に設定されていれば、再生装置に対するユーザ操作は無効になる。
『animation_frame_rate_code』は、アニメーション型ボタンに適用すべきフレームレートを記述する。アニメーションフレームレートは、本フィールドの値を用いて、ビデオフレームレートを割ることにより与えられる。本フィールドが00なら、各ボタンのグラフィクスオブジェクトを定義するODSのうち、Start_Object_id_xxxにて特定されるもののみが表示され、アニメーションされない。
『default_selected_button_number』は、対話画面の表示が始まったとき、デフォルトとしてセレクテッド状態に設定すべきボタン番号を指示する。本フィールドが”0”であれば、再生装置のレジスタに格納されたボタン番号のボタンが自動的にアクティブ状態に設定される。もしこのフィールドが非ゼロであれば、このフィールドは、有効なボタンの値を意味する。
『default_activated_button_number』は、Selection_Time_out_PTSにより定義された時間の前に、ユーザがどのボタンもアクティブ状態にしなかったとき、自動的にアクティブ状態に設定されるボタンを示す。default_activated_button_numberが”FF”であれば、Selection_Time_out_PTSにより定義される時刻において、現在セレクテッド状態にあるボタンが自動的に選択される。このdefault_activated_button_numberが00であれば、自動選択はなされない。00,FF以外の値であれば本フィールドは、有効なボタン番号として解釈される。
『ボタン情報(Button_info)』は、対話画面において合成される各ボタンを定義する情報である。図中の引き出し線hp1はICSにより制御されるi番目のボタンについてのボタン情報iの内部構成をクローズアップしている。以降、ボタン情報iを構成する情報要素について説明する。
『button_number』は、ボタンiを、ICSにおいて一意に識別する数値である。
『numerically_selectable_flag』は、ボタンiの数値選択を許可するか否かを示すフラグである。
『auto_action_flag』は、ボタンiを自動的にアクティブ状態にするかどうかを示す。auto_action_flagがオン(ビット値1)に設定されれば、ボタンiは、セレクテッド状態になる代わりにアクティブ状態になる。auto_action_flagがオフ(ビット値0)に設定されれば、ボタンiは、選択されたとしてもセレクテッド状態になるにすぎない。
『object_horizontal_position』、『object_vertical_position』は、対話画面におけるボタンiの左上画素の水平位置、垂直位置を示す。
『upper_button_number』は、ボタンiがセレクテッド状態である場合においてMOVEUPキーが押下された場合、ボタンiの代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタンiの番号が設定されていれば、MOVEUPキーの押下は無視される。
『lower_button_number』,『left_button_number』,『right_button_number』は、ボタンiがセレクテッド状態である場合においてMOVE Down キー,MOVE Left キー,MOVE Right キーが押下された場合、ボタンiの押下の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタンiの番号が設定されていれば、これらのキーの押下は無視される。
『start_object_id_normal』は、ノーマル状態のボタンiをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのstart_object_id_normalに記述される。
『end_object_id_normal』は、ノーマル状態のボタンiをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのend_object_id_normalに記述される。このEnd_object_id_normalに示されるIDが、start_object_id_normalに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタンiの絵柄になる。
『repeated_normal_flag』は、ノーマル状態にあるボタンiのアニメーション表示を反復継続させるかどうかを示す。
『start_object_id_selected』は、セレクテッド状態のボタンiをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのstart_object_id_selectedに記述される。
『end_object_id_selected』は、セレクト状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのend_object_id_selectedに記述される。
このEnd_object_id_selectedに示されるIDが、start_object_id_selectdに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタンiの絵柄になる。
『repeat_selected_flag』は、セレクテッド状態にあるボタンiのアニメーション表示を、反復継続するかどうかを示す。start_object_id_selectedと、end_object_id_selectedとが同じ値になるなら、本フィールド00に設定される。
『start_object_id_activated』は、アクティブ状態のボタンiをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのstart_object_id_activatedに記述される。
『end_object_id_activated』は、アクティブ状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのend_object_id_activatedに記述される。
続いてボタンコマンドについて説明する。
『ボタンコマンド(button_command)』は、ボタンiがアクティブ状態になれば、実行されるコマンドである。
以上がICSの内部構成である。ICSによる対話制御の具体例について以下説明する。本具体例は、図44のようなODS、ICSを想定している。図44は、あるDSnに含まれるODSと、ICSとの関係を示す図である。このDSnには、ODS11〜19,21〜29,31〜39,41〜49が含まれているものとする。これらのODSのうち、ODS11〜19は、ボタンAの各状態を描いたものであり、ODS21〜29は、ボタンBの各状態を描いたもの、ODS31〜39は、ボタンCの各状態を描いたもの、ODS41〜49は、ボタンDの各状態を描いたものとする(図中の括弧}を参照)。そしてICSにおけるbutton_info(1),(2),(3),(4)にて、これらのボタンA〜ボタンDの状態制御が記述されているものとする(図中の矢印bh1,2,3,4参照)。
このICSによる制御の実行タイミングが、図45に示す動画のうち、任意のピクチャデータpt1の表示タイミングであれば、ボタンA〜ボタンDからなる対話画面tm1が、このピクチャデータpt1に合成(gs1)されて表示されることになる(gs2)。動画の中身に併せて、複数ボタンからなる対話画面が表示されるので、ICSによりボタンを用いたリアルな演出が可能になる。
図47に示すボタンA〜ボタンDの状態遷移を実行する場合のICSの記述例を図46に示す。図47における矢印hh1,hh2は、button info(1)のneighbor_info()による状態遷移を象徴的に表現している。button info(1)のneighbor_info()におけるlower_button_numberは、ボタンCに設定されているため、ボタンAがセレクテッド状態になっている状態で、MOVEDownキー押下のUOが発生すれば(図47のup1)、ボタンCがセレクテッド状態になる(図47のsj1)。button info(1)のneighbor_info()におけるright_button_numberは、ボタンBに設定されているため、ボタンAがセレクテッド状態になっている状態で、MOVERightキー押下のUOが発生すれば(図47のup2)、ボタンBがセレクテッド状態になる(図47のsj2)。
図47における矢印hh3は、button info(3)のneighbor_info()による状態遷移の制御を示す。button info(3)のneighbor_info()におけるupper_button_numberは、ボタンAに設定されているため、ボタンCがセレクテッド状態になっている状態で(up3)、MOVEUpキー押下のUOが発生すれば、ボタンAがセレクテッド状態に戻る。
続いてボタンA〜ボタンDの絵柄について説明する。ODS11,21,31,41が図48に示す絵柄であるものとする。そしてボタンAに割り当てられたODS11〜19は、図49のような絵柄であるものとする。ICSにおけるbutton_info(1)のnormal_state_info()におけるstart_object_id_normal,end_object_id_normalは、ODS11〜13を指定しているため、ボタンAのノーマル状態は、ODS11〜13によるアニメーションで表現される。またbutton_info(1)のselected_state_info()におけるstart_object_id_selected,end_object_id_selectedは、ODS14〜16を指定しているため、ボタンAのセレクテッド状態は、ODS14〜16で表現される。ユーザがこのボタンAをセレクテッド状態にすることにより、ボタンAの絵柄たる肖像は、ODS11〜13によるものから、ODS14〜16によるものへと変化する。ここでnormal_state_info()、selected_state_info()におけるrepeat_normal_flag,repeat_select_flagを1にしておけば、ODS11〜13によるアニメーション、ODS14〜16によるアニメーションは、図中の「→(A)」,「(A)→」,「→(B)」,「(B)→」,に示すように、アニメーション表示は反復継続する。
アニメーション描画が可能な複数ODSが、ボタンA〜ボタンDに割り当てられており、これらによる制御がICSに記述されていれば、ユーザ操作に併せてキャラクタの表情が変わるような、リアルなボタンの状態制御を実現することができる。
続いてDisplay SetにおけるODSの順序について説明する。Display Setに属するODSは、ボタンの1つの状態を表すようICSにて指定されていることは、上述した通りである。ODSは、こうした指定、つまり、ボタンのどの状態を示すかという指定に応じて、Display Setにおける順序が決められる。
詳しくいうとDisplay SetにおいてODSは、ノーマル状態を表すもの(1)、セレクテッド状態を表すもの(2)、アクティブ状態を示すもの(3)というように、同じ状態を表すもの同士がグループ化される。このボタンの1つの状態を表すグループをbutton-stateグループという。そしてこれらbutton-stateグループを、ノーマル状態→セレクテッド状態→アクティブ状態というように並べる。このようにボタンのどの状態を表すかに応じて、ODSの順序を決めるというのが、Display SetにおけるODSの順序である。
図50は、Display Setに属するODSの順序を示す図である。本図の第2段目に、Display Setにおける3つのbutton-stateグループを示す。本図においてノーマル状態を描くODSの集合(ODSs for Normal state)、ボタンのセレクテッド状態を描くODSの集合(ODSs for Selected state)、ボタンのアクティブ状態を描くODSの集合(ODSs for Actioned state)が示されている。そしてこれらbutton-stateグループの順序は、ノーマル状態→セレクテッド状態→アクティブ状態というように並べられている。これはODSのうち、対話画面の初期表示を構成するものを早く読み出させ、アップデート後の画面表示を構成するものの読み出しを後にするという配慮である。
図50の第1段目は、これらbutton-stateグループにより描かれるグラフィクスオブジェクトAn,Bn,Cn,Dn,As,Bs,Cs,Ds,Aa,Ba,Ca,Daを示す。本図におけるAn,Bn,Cn,Dnにおける添字nは各ボタンのノーマル状態を表し、As,Bs,Cs,Dsにおける添字sは各ボタンのセレクテッド状態を表す。Aa,Ba,Ca,Daにおける添字aは各ボタンのアクティブ状態を表す。図50の第2段目は、第1段目のグラフィクスオブジェクトが属するbutton-stateグループを示す。尚、本図におけるODS1〜ODSnという表記は、「1」,「n」というような同じ番号が付されているが、これらN-ODSs,S-ODSs,A-ODSsに属するODSは別々のものである。以降、同様の表記の図は同じ意味であるとする。
図51は、図50のbutton-stateグループが配置された対話画面における状態遷移を示す図である。
本図における対話画面は、”初期表示”、”1stユーザアクションによる更新表示”、”2ndユーザアクションによる更新表示”という複数の状態をもつ。図中の矢印は、状態遷移のトリガとなるユーザアクションを表す。この図を参照すると、4つのボタンA,B,C,Dはそれぞれノーマル状態、セレクテッド状態、アクティブ状態という状態をもっている。このうち初期表示に必要なのは、3つのノーマル状態を描くグラフィクスオブジェクトと、1つのセレクテッド状態を描くグラフィクスオブジェクトであることがわかる。
デフォルトセレクテッドボタンが未確定であり、ボタンA〜ボタンDのうち、どのボタンがセレクテッド状態になるかが動的に変わる場合であっても、各ボタンのノーマル状態、セレクテッド状態を表すグラフィクスオブジェクトのデコードが完了すれば、初期表示を実現することができる。このことを意識して、本実施形態では、各状態に対応するbutton-stateグループを、図50の第2段目に示すようにノーマル状態→セレクテッド状態→アクティブ状態の順に配列している。かかる配列により、アクティブ状態を構成するODSの読み出しやデコードが未完であっても、初期表示を実現することができ、Display Setの読み出し開始から初期表示の完了までの期間を短くすることができる。
続いて図48、図49に示したODSを、どのような順序で配列させるかについて説明する。図52は、Display SetにおけるODSの順序を示す図である。本図においてODSs for Normal stateは、ODS11〜13,ODS21〜23,ODS31〜33,ODS41〜43から構成されている。またODSs for Selected stateは、ODS14〜16,ODS24〜26,ODS34〜36,ODS44〜46から構成され、ODSs for Actioned stateは、ODS17〜19,ODS27〜29,ODS37〜39,ODS47〜49から構成されている。ODS11〜13は、図49に示したような、キャラクターの表情変化を描くものであり、ODS21〜23,ODS31〜33,ODS41〜43も同様なので、これらのODSを先頭のbutton-stateグループに配置することにより、Display Setの読み出しの途中であっても、初期表示の準備を整えることができる。これによりアニメーションを取り入れた対話画面を、遅滞なく実行することができる。
続いて複数のボタン状態からの多重参照されるODSの順序について説明する。多重参照とは、あるODSについてのobject_idがICSにおける2以上のnormal_state_info,selected_state_info,activated_state_infoにより指定されていることをいう。かかる多重参照を行えば、あるボタンのノーマル状態を描くグラフィクスオブジェクトを用いて、他のボタンのセレクテッド状態を描くことができ、グラフィクスオブジェクトの絵柄を共用することができる。かかる共用により、ODSの数を少なくすることができる。多重参照されるODSについては、どのbutton-stateグループに属するかが問題になる。
つまりあるボタンのノーマル状態と、別のボタンのセレクテッド状態とが1つのODSで描かれている場合、このODSは、ノーマル状態に対応するbutton-stateグループに属するか、セレクテッド状態に対応するbutton-stateグループに属するかが問題となる。
この場合ODSは、複数状態のうち、最も早く出現する状態に対応するbutton-stateグループだけ1回のみ配置される。
あるODSがノーマル状態、セレクテッド状態で多重参照されるなら、ノーマル状態に対応するbutton-stateグループ(N-ODSs)にこのODSは配置され、セレクテッド状態に対応するbutton-stateグループ(S-ODSs)には配置されない。また別のODSがセレクテッド状態、アクティブ状態で多重参照されるなら、セレクテッド状態に対応するbutton-stateグループ(S-ODSs)にこのODSは配置され、アクティブ状態に対応するbutton-stateグループ(A-ODSs)には配置されない。このように多重参照されるODSは、最も早く出現する状態に対応するbutton-stateグループ内に一回だけ配置される。以上が多重参照されるODSの順序についての説明である。
S-ODSsにおける、ODSの順序について説明する。S-ODSsにおいて、どのODSが先頭に位置するかは、デフォルトセレクテッドボタンが静的に確定しているか、動的であるかによって違う。静的に確定したデフォルトセレクテッドボタンとは、ICSにおけるdefault_selected_button_numberに00以外の有効な値が設定され、この値で指示されるボタンのことをいう。default_selected_button_numberが有効な値を示しており、尚且つデフォルトセレクテッドボタンを表すODSが、N-ODSsに無い場合は、デフォルトセレクテッドボタンを表すODSが、S-ODSsの先頭に配置される。
default_selected_button_numberが値00を示している場合、デフォルトでセレクテッド状態に設定されるボタンは、再生装置側の状態によって動的に変化する。
値0を示すよう、default_selected_button_numberを設定しておくのは、例えば、Display Setが多重されているAVClipが、複数再生経路の合流点になっているようなケースである。先行する複数再生経路がそれぞれ第1、第2、第3章であり、合流点にあたるDisplay Setが第1章、第2章、第3章に対応するボタンを表示させるものである場合、default_selected_button_numberにおいて、デフォルトでセレクテッド状態とすべきボタンを決めてしまうのは、おかしい。
第1章からの到達時には第2章にあたるボタン、第2章からの到達時には第3章にあたるボタン、第3章からの到達時には第4章にあたるボタンというように、このDisplay Setに到達するまでに、先行する複数再生経路のうち、どの再生経路を経由するかによって、セレクテッド状態とすべきボタンを変化させるのが理想的である。先行する再生経路によって、セレクテッド状態とすべきボタンが変わるようなケースにおいて、default_selected_button_numberは無効を示すよう、0に設定される。どの再生経路を経由するかによって、セレクテッド状態とすべきボタンを変化するから、特定のODSをbutton-stateグループの先頭に配置するというような配慮は行わない。
図53は、default_selected_button_numberが”=0”である場合と、”=ボタンB”である場合とでS-ODSsにおいてODSの並びがどのように変わるかを示す図である。本図において破線ss1は、default_selected_button_numberがボタンBを示している場合に、S-ODSsにおけるODSの配列がどのようになるかを示しており、破線ss2は、default_selected_button_numberが=0を示している場合に、S-ODSsにおけるODSの配列がどのようになるかを示している。この図の表記からもわかるように、default_selected_button_numberがボタンBを示している場合、ボタンBのセレクテッド状態を示すODSBsがS-ODSsの先頭に配され、その他のボタンのODSは、後回しにされている。一方、default_selected_button_numberが”=0”である場合、ボタンAのセレクテッド状態を表すODSAsが先頭に配置されている。このようにdefault_selected_button_numberが有効かどうかは、S-ODSs内の順序に大きな変動をもたらす。
以上がODSの順序についての説明である。続いてこれらICS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。ODSについてのDTS、PTSは、第1実施形態に示した数式に基づき設定すればよい。ICSにおけるDTS、PTSは、第1実施形態に示したものとは違ったものになる。以降ICSの、DTS値、PTS値について説明する。
ICSのPTSは、Epoch開始直後であればDSnの初期表示を構成するODSのうち、デコード時刻が最も遅いODSのPTS値(1)、グラフィクスプレーンのクリアに要する時間(2)、ODSのデコードにより得られたグラフィクスオブジェクトをグラフィクスプレーンに書き込む書込時間(3)を足した値以降に設定される。一方Acquisition Pointであれば、ODSのPTS値(1)にプレーン書込期間(3)を足した値(ODSのPTS値(1)+プレーン書込期間(3))以降に設定される。
ICSにおいてdefault_selected_button_numberが指定されている場合は、全てのボタンのノーマル状態を描画するODSのデコードと、デフォルトボタンのセレクテッド状態を描画するODSのデコードさえ完了すれば、初期表示を行うことができる。初期表示における複数ボタンのセレクテッド状態を描画するODSを、S-ODSsと呼び、そのうちデコード時刻が最も早いもの(この場合、デフォルトボタンを描画するもの)をS-ODSsfirstと呼ぶ。このS-ODSsfirstのPTS値を、デコード時刻が最も遅いODSのPTS値として、ICSのPTSの基準に用いる。
ICSにおいてdefault_selected_button_numberが指定されていない場合は、どのボタンがセレクテッド状態になるかわからないから、全ボタンのノーマル状態、セレクテッド状態を描画する準備が整なわないと、初期表示の準備が完了しない。初期表示における複数ボタンのセレクテッド状態を描画するS-ODSsのうち、デコード時刻が最も遅いものをS-ODSslastと呼ぶ。このS-ODSslastのPTS値を、デコード時刻が最も遅いODSのPTS値として、ICSのPTSの基準値に用いる。
S-ODSsfirstのデコード終了時刻をPTS(DSn[S-ODSsfirst])とすると、PTS(DSn[ICS])は、PTS(DSn[S-ODSsfirst])に、グラフィクスプレーンのクリアに要する時間(2)、ODSのデコードにより得られたグラフィクスオブジェクトをグラフィクスプレーンに書き込む書込時間(3)を足した値になる。
グラフィックスプレーン内において描画可能な矩形領域の横幅をvideo_width,縦幅をvideo_heightとし、グラフィックスプレーンへの書込レートを128Mbpsとすると、グラフィックスプレーンのクリアに要する時間は、8×video_width×video_height//128,000,000と表現される。これを90KHzの時間精度で表現すれば、グラフィックスプレーンのクリア時間(2)は90,000×(8×video_width×video_height//128,000,000)になる。
ICSに含まれる全ボタン情報により、指定されるグラフィックスオブジェクトの総サイズをΣSIZE(DSn[ICS.BUTTON[i]])とし、グラフィックスプレーンへの書込レートを128Mbpsとすると、グラフィックスプレーンへの書き込みに要する時間は、ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000と表現される。これを90KHzの時間精度で表現すれば、グラフィックスプレーンのクリア時間(2)は90,000×(ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000)になる。
ここでΣSIZE(DSn[ICS.BUTTON[i]])は、各ボタンを表すグラフィクスオブジェクトのうち、最初に表示されるもののサイズの総和を意味する。このΣSIZE(DSn[ICS.BUTTON[i]])はデフォルトセレクテッドボタンが確定している場合と、動的に変わる場合とで、違う値になる。デフォルトセレクテッドボタンが静的に確定している場合、ΣSIZE(DSn[ICS.BUTTON[i]])は、デフォルトセレクテッドボタンのセレクテッド状態を表す複数ODSのうち最初に表示されるもの、デフォルトセレクテッドボタン以外のボタンのノーマル状態を表す複数ODSのうち、最初に表示されるものの総和になる。
続いてデフォルトセレクテッドボタンが動的に変わる場合、どのボタンがデフォルトセレクテッドボタンになるかはわからないから、書き込み時間が最も長くなるケースを想定しせねばならない。ここで、任意のボタンxのノーマル状態における最初の一枚を表すグラフィクスオブジェクト(ODSn1)、及び、ボタンxのセレクテッド状態における最初の一枚を表すグラフィクスオブジェクト(ODSs1)のうち、サイズが大きいもの(Max(ODSn1,ODSs1))を、1つのボタンxにおいて最初に表示すべきグラフィクスオブジェクトと考える。
このMax(ODSn1,ODSs1)を、全てのボタンについて足し合わせた結果が、ΣSIZE(DSn[ICS.BUTTON[i]])になる。
図54(a)(b)は、N-ODSsにボタンA〜Dを構成する複数ODSが含まれており、S-ODSsにボタンA〜Dを構成する複数ODSが含まれている場合、ΣSIZE(DSn[ICS.BUTTON[i]])がどのような値になるかを示す図である。ここでdefault_selected_button_numberが有効な値を示している場合、ΣSIZE(DSn[ICS.BUTTON[i]])は太い枠で示す4つのODSのサイズの総和となる。”As1”は、ボタンAのセレクテッド状態を表す複数のODSのうち最初に表示されるODSである。”Bn1”,”Cn1”,”Dn1”は、ボタンB〜ボタンDのノーマル状態を表す複数のODSのうち最初に表示されるODSを示す。これらのサイズをsize()で表すと、ΣSIZE(DSn[ICS.BUTTON[i]]) は、size(As1)+size(Bn1)+size(Cn1)+size(Dn1)になる。
一方、default_selected_button_numberが”=0”であるなら、An1,As1のうち大きいODS、Bn1,Bs1のうち大きいODS、Cn1,Cs1のうち大きいODS、Dn1,Ds1のうち大きいODSの和がΣSIZE(DSn[ICS.BUTTON[i]])になる。故にΣSIZE(DSn[ICS.BUTTON[i]])は、
ΣSIZE(DSn[ICS.BUTTON[i]])
= max(size(An1),size(As1))+max(size(Bn1),size(Bs1))
+max(size(Cn1),size(Cs1))+max(size(Dn1),size(Ds1))
になる。
以上の数式を用いることにより、Epoch Start開始直後のPTS(DSn[ICS])は、以下の数式のように表現される。
PTS(DSn[ICS])≧PTS(DSn[S-ODSsfirst])
+90,000×(8×video_width×video_height//128,000,000)
+90,000×(ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000)
一方、default_selected_button_numberが無効である場合、PTS(DSn[S-ODSsfirst])をPTS(DSn[S-ODSslast])に置き換えればよい。つまり算出式は、以下の通りになる。
PTS(DSn[ICS])≧PTS(DSn[S-ODSslast])
+90,000×(8×video_width×video_height//128,000,000)
+90,000×(ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000)
以上のようにしてPTS、DTSを設定することにより、同期表示を実現する場合の一例を図55に示す。本図において動画における任意のピクチャデータpy1の表示タイミングで、ボタンを表示させる場合を想定する。この場合、ICSのPTS値は、このピクチャデータの表示時点になるよう設定せねばならない。
そしてICSのPTSから、画面のクリア期間cd1、グラフィクスオブジェクトの転送期間td1を差し引いた時刻に、DSnの初期表示を構成するODSのうち、デコード時刻が最も遅いODSのデコードが完了せねばならないから、図中の時点(1)に、ODSのPTS値が設定しなければならない。更に、ODSのデコードには期間dd1を要するから、このPTSより期間dd1だけ早い時点に、このODSのDTS値を設定せねばならない。
図55において、動画と合成されるODSは1つだけであり、単純化されたケースを想定している。動画と合成されるべき対話画面の初期表示が、複数のODSで実現される場合、ICSのPTS及びDTS、ODSのPTS、DTSは図56のように設定せねばならない。
図56は、対話画面の初期表示が複数ODSにて構成され、デフォルトセレクテッドボタンが静的に確定している場合のDTS、PTSの設定を示す図である。初期表示を実現するODSのうち、デコードが最も遅いS-ODSsfirstのデコードが図中の期間dd1の経過時に終了するなら、このS-ODSsfirstのPTS(DSn[S-ODSsfirst])は、期間dd1の経過時を示すよう設定される。
更に、初期表示の実現には、画面クリアを行い、デコードされたグラフィクスオブジェクトを転送せねばならないから、このPTS(DSn[S-ODSsfirst])の値に画面クリアに要する期間(90,000×(8×video_width×video_height//128,000,000))、デコードされたグラフィクスオブジェクトの転送期間(90,000×(ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000))を足した時点以降を、ICSのPTS(DSn[ICS])として設定せねばならない。
図57は、対話画面の初期表示が複数ODSにて構成され、デフォルトセレクテッドボタンが未定である場合のDTS、PTSの設定を示す図である。初期表示を実現するS-ODSsのうち、デコードが最も遅いS-ODSslastのデコードが図中の期間dd2の経過時に終了するなら、このS-ODSslastのPTS(DSn[S-ODSslast])は、期間dd2の経過時を示すように設定される。
更に、初期表示の実現には、画面クリアを行い、デコードされたグラフィクスオブジェクトを転送せねばならないから、このPTS(DSn[S-ODSslast])の値に画面クリアに要する期間(90,000×(8×video_width×video_height//128,000,000))、デコードされたグラフィクスオブジェクトの転送期間(90,000×(ΣSIZE(DSn[ICS.BUTTON[i]])//128,000,000))を足した時点以降を、ICSのPTS(DSn[ICS])として設定せねばならない。以上がICSによる同期制御である。
尚、ICSのPTSによる同期制御は、再生時間軸上のあるタイミングでボタンを表示するという制御のみならず、再生時間軸上のある期間でPopupメニューの表示を可能とする制御を含む。Popupメニューとは、リモコン400に設けられたメニューキーの押下でPopup表示されるメニューであり、このPopup表示が、AVClipにおけるあるピクチャデータの表示タイミングで可能になることも、ICSのPTSによる同期制御である。Popupメニューを構成するODSは、ボタンを構成するODSと同様、ODSのデコードが完了し、デコードにより得られたグラフィックスオブジェクトがグラフィックスプレーンに書き込まれる。このグラフィックスプレーンへの書き込みが完了していなければ、ユーザからのメニューコールに応ずることはできない。そこでPopupメニューの同期表示にあたって、ICSのPTSに、Popup表示が可能になる時刻を示しておくのである。
以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。第2実施形態に係る再生装置の内部構成は、第1実施形態に示したものと略同一になる。そしてこれらの構成において、Object Buffer15、Graphicalコントローラ17に改良が加えられている。以下、Object Buffer15、Graphicalコントローラ17の改良について説明する。
第2実施形態に係るObject Buffer15には、Stream Graphicsプロセッサ14のデコードにより得られたグラフィクスオブジェクトであって、対話画面を構成するためのボタンが配置される。図58は、Object Buffer15の格納内容をグラフィクスプレーン8と対比して示す図である。この格納内容は、図48、図49に示した具体例のODSが、Object Buffer15に書き込まれる場合を想定している。図48、図49の具体例は、4つのボタンのアニメーションを、36個のODS(ODS11〜49)により実現するものであったが、このアニメーションの全てのコマを表すODSが、このObject Buffer15に格納される。一方グラフィクスプレーン8には、このObject Buffer15に格納された個々のODSの表示位置が規定されれる。この表示位置は、各ボタン情報のButton_horizontal_position、Button_vertical_positionにより定義されるものであり、Object Buffer15に格納されている複数ODSのそれぞれを、1コマずつ転送してグラフィクスプレーン8の表示位置に書き込んでゆくことにより、アニメーションは実現される。
第2実施形態に係るGraphicsコントローラ17は、Compositionバッファ16に配置されたICSを解読して、ICSに基づく制御をする。この制御の実行タイミングは、ICSに付加されたPTSの値に基づく。このGraphicsコントローラ17のうち、重要なものは対話画面の初期表示時、更新時における書込処理である。以降、Graphicsコントローラ17による対話画面の初期表示時、更新時における書込処理を、図59を参照しながら説明する。図59は、初期表示時におけるGraphicsコントローラ17の処理を示す図である。本図に示すように、ボタンAにおけるボタン情報のButton_horizontal_position、Button_vertical_positionに規定される表示位置に、ボタンAのS-ODSsに属するODSを書き込み、ボタンB,C,Dにおけるボタン情報のButton_horizontal_position、Button_vertical_positionに規定される表示位置に、ボタンB,C,DのN-ODSsに属するODSを書き込むようGraphicsコントローラ17は制御を行う(図中の矢印w1,w2,w3,w4は、この書き込みを象徴的に示す)。この書き込みにより、図51に示した初期表示を作成することができる。ここで注目すべきは、対話画面の初期表示にあたっては、全てのODSが必要ではなく、デフォルトセレクテッドボタンのS-ODSsに属するODS、それ以外のボタンのN-ODSsに属するODSさえObject Buffer15に存在すれば、対話画面の初期表示は完了する点である。このことから、Object Buffer15に格納されるべき複数ODSのうち、デフォルトセレクテッドボタンのS-ODSsに属するODS、それ以外のボタンのN-ODSsに属するODSのデコードさえ完了すれば、Graphicsコントローラ17は対話画面の初期表示のための書き込みを開始することができる。
図60は、1stUserAction(MoveRight)による対話画面更新時におけるGraphicsコントローラ17の処理を示す図である。本図に示すように、ボタンBのボタン情報におけるボタン情報のButton_horizontal_position、Button_vertical_positionに規定される表示位置に、ボタンBのS-ODSsに属するODSを書き込み、ボタンAのボタン情報におけるボタン情報のButton_horizontal_position、Button_vertical_positionに規定される表示位置に、ボタンAのN-ODSsに属するODSを書き込むようGraphicsコントローラ17は制御を行う(図中の矢印w5,w6,w7,w8は、この書き込みを象徴的に示す)。この書き込みにより、図51に示したような状態遷移を実現することができる。ボタンC,Dは対話画面の初期表示時と同じくノーマル状態のままであるが、アニメーションを継続するため、グラフィクスプレーン8への書き込みが継続してなされている。
同じく、1stUserActionが、MoveDown,Activatedである場合の、対話画面更新時におけるGraphicsコントローラ17の処理を図61、図62に示す。対話画面更新にあたっては、デフォルトセレクテッドボタン以外のボタンについてのS-ODSsや、A-ODSsも必要になり、全てのODSがObject Buffer15に格納されていることが望まれる。以上がGraphicsコントローラ17の処理内容である。
以上のように構成された再生装置において、各構成要素は第1実施形態同様、パイプライン式にデコード処理を行う。
図63は、再生装置によるパイプライン処理を示すタイミングチャートである。第4段目は、BD-ROMにおけるDisplay Setを示し、第3段目は、Coded Dataバッファ13へのICS、PDS、ODSの読出期間を示す。第2段目は、Stream Graphicsプロセッサ14による各ODSのデコード期間を示す。第1段目は、Graphicsコントローラ17による処理期間を示す。各ODSのデコード開始時刻は、図中のDTS11,DTS12,DTS13に示されている。Coded Dataバッファ13へのN-ODSsに属する最初のODS(N-ODSs[ODS1])の格納はDTS11までに完了し、Coded Dataバッファ13へのN-ODSsに属する最後のODS(N-ODSs[ODSn])の格納は、DTS12に示される時刻までに完了する。このように各ODSは、自身のDTSに示される時刻までにCoded Dataバッファ13への読み出しが完了している。
一方、各ODSのデコード終了時刻は、図中のPTS11,PTS12,PTS13に示されている。Stream
Graphicsプロセッサ14によるN-ODSs(ODS1)のデコードはPTS11までに完了し、N-ODSs(ODSn)のデコードは、PTS12に示される時刻までに完了する。以上のように、各ODSのDTSに示される時刻までに、ODSをCoded Dataバッファ13に読み出し、Coded Dataバッファ13に読み出されたODSを、各ODSのPTSに示される時刻までに、デコードしてObject Buffer15に書き込む。これらの処理を、1つのStream Graphicsプロセッサ14は、パイプライン式に行う。
デフォルトセレクテッドボタンが静的に確定している場合、対話画面の初期表示に必要なグラフィクスオブジェクトがObject Buffer15上で全て揃うのは、ノーマル状態に対応するbutton-stateグループ、セレクテッド状態に対応するbutton-stateグループの先頭ODSのデコードが完了した時点である。本図でいえば、PTS13に示される時点で、対話画面の初期表示に必要なグラフィクスオブジェクトは全て揃う。
本図の第1段目における期間cd1は、Graphicsコントローラ17がグラフィクスプレーン8をクリアするのに要する期間である。また期間td1は、Object Buffer15上にえられたグラフィクスオブジェクトのうち、対話画面の最初の一枚を構成するグラフィクスオブジェクトを、グラフィクスプレーン8に書き込むのに要する期間である。グラフィクスプレーン8における書込先は、ICSにおけるbutton_horizontal_position,button_vertical_positionに示されている場所である。つまりODSのPTS13の値に、画面クリアの期間cd1と、デコードにより得られたグラフィクスオブジェクトの書込期間td1とを足し合わせれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン8上に得られることになる。この非圧縮グラフィクスの色変換をCLUT部9に行わせ、ビデオプレーン6に格納されている非圧縮ピクチャとの合成を加算器10に行わせれば、合成画像が得られることになる。
Display Setに含まれる全てのODSをデコードした上で初期表示を行う場合と比較すると、セレクテッド状態に対応するbutton-stateグループ、アクティブ状態に対応するbutton-stateグループのデコード完了を待つことなく、初期表示は可能になるので、図中の期間hy1だけ、初期表示の実行は早められることになる。
尚、本図におけるODS1〜ODSnという表記は、「1」,「n」というような同じ番号が付されているが、これらN-ODSs,S-ODSs,A-ODSsに属するODSは別々のものである。以降、同様の表記の図は同じ意味であるとする。
グラフィクスデコーダ12において、Graphicsコントローラ17がグラフィクスプレーン8のクリアやグラフィクスプレーン8への書き込みを実行している間においても、Stream Graphicsプロセッサ14のデコードは継続して行われる(第2段目のODSnのデコード期間,ODS1のデコード期間,ODSnのデコード期間n,)。Graphicsコントローラ17によるグラフィクスプレーン8のクリアやグラフィクスプレーン8への書き込みが行われている間に、残りのODSに対するデコードは、継続してなされるので、残りのODSのデコードは早く完了する。残りのODSのデコードが早く完了することにより対話画面を更新するための準備は早く整うので、これら残りのODSを用いた対話画面更新も、ユーザ操作に即応することができる。以上のようなパイプライン処理により、対話画面の初期表示、更新の双方を迅速に実施することができる。
図63ではデフォルトセレクテッドボタンが静的に確定している場合を想定したが、図64は、デフォルトセレクテッドボタンが動的に変わる場合の、再生装置によるパイプライン処理を示すタイミングチャートである。デフォルトセレクテッドボタンが動的に変わる場合、button-stateグループに属する全てのODSをデコードして、グラフィクスオブジェクトをグラフィクスプレーン8に得れば、初期表示に必要なグラフィクスオブジェクトは全て揃う。Display Setに含まれる全てのODSをデコードした上で初期表示を行う場合と比較すると、アクティブ状態に対応するbutton-stateグループのデコード完了を待つことなく、初期表示は可能になる。そのため図中の期間hy2だけ、初期表示の実行は早められることになる。
図65は、グラフィクスプレーン8、Object Buffer15、Coded Dataバッファ13、Compositionバッファ16における占有量の時間的遷移を示すタイミングチャートである。本図における占有量の表記は、図30に準ずる。第2実施形態では、N-ODSs,S-ODSs,A-ODSsを構成するODSがデコードの対象になっているため、第2段目、第3段目に示される単調増加、単調減少の数が増えている。これ以外は、図30と同一である。ODSに付与されたDTS、PTS、ICSに付与されたDTS、PTS、そして図27に示した各バッファのサイズ、転送レートを用いれば、第1実施形態と同様、図65に示したようなグラフを作図することにより、BD-ROMにて供給すべきAVClipの再生時において、各バッファの状態がどのように変化するかが、オーサリングの段階で明らかになる。このバッファ状態の遷移は、DTS、PTSに示される値を書き換えることで、調整することが可能なので、再生装置側のデコーダのスペックを越えるような復号負荷の発生を回避したり、再生にあたってのバッファオーバーフローの回避することが本実施形態でも可能になる。そのため再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
以上が、第2実施形態に係る再生装置のパイプライン動作である。続いて第2実施形態に係る再生装置を実現するためのソフトウェアに対する改良について説明する。
図66は、機能セグメントのロード処理の処理手順を示すフローチャートである。本図は、図31のフローチャートをベースにして作図している。図31との差違は、ステップS29以降に、ステップS36、ステップS37を追加した点である。
ステップS36は、command_update_flagが1であるか否かの判定である。もし1であるなら(ステップS36でYes)、ボタン情報のボタンコマンドのみをCoded Dataバッファ13にロードし、それ以外を無視する(ステップS37)。もし0であるなら、ステップS22に移行する。これによりAcquisition Pointを示すICSは無視されることになる(ステップS24)。
DSが、図67のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図67の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、Segment_TypeがEpoch_Startであり、Command_update_flagが0に設定され、LinkPL(PL#5)というボタンコマンドを含む。
DS10は、DS1のduplicateであり、Segment_TypeはAcquision Point、Command_update_flagが0に設定され、LinkPL(PL#5)というボタンコマンドを含む。
DS20は、DS1のInheritであり、Segment_TypeはAcquision Pointになっている。DS1から変化があるのはボタンコマンドであり(LinkPL(PL#10))、これを示すべくCommand_update_flagが1に設定されている。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しms1が行われたものとする。この場合、頭出し位置に最も近いDS10が、図66のフローチャートの対象となる。ステップS27においてComposition_stateはAcquisition
Pointと判定されるが、先行するDSはグラフィクスデコーダ12内に存在しないため、無視フラグは0に設定され、このDS10が再生装置のCoded Dataバッファ13にロードされる(図68のhs1)。一方、Display Setの存在位置より後から頭出しが行われた場合(ms2)、Display Set10に後続するDisplay Set20(図68のhs2)がCoded Dataバッファ13に読み出される。
図69のように通常再生が行われた場合のDS1,10,20のロードは、図70に示すものとなる。3つのDSのうち、ICSのSegment_TypeがEpoch StartであるDS1は、そのままCoded Dataバッファ13にロードされるが(ステップS23)、ICSのSegment_TypeがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップS29)、これを構成する機能セグメントはCoded Dataバッファ13にロードされず無視される(ステップS24)。またDS20については、ICSのSegment_TypeはAcquisition Pointであるが、Command_update_flagが1に設定されているので、ステップS36がYesになり、ボタンコマンドのみがロードされて、Coded Dataバッファ13上のDSのうち、ICS内のボタンコマンドのみをこれに置き換えられる(ステップS37)。しかし無視フラグは依然として1を示しているので、このボタンコマンド以外は、ロードされることなく無視される。
DSによる表示内容は同じであるが、DS20への到達時には、ボタンコマンドは、DSのLinkPL(#5)からLinkPL(#10)に置き換えられている。かかる置き換えにより、再生進行に伴い、ボタンコマンドの内容が変化するという制御が可能になる。 続いてGraphicsコントローラ17の処理手順について説明する。図71はGraphicsコントローラ17の処理手順のうち、メインルーチンにあたる処理を描いたフローチャートである。本フローチャートは、タイムスタンプ同期処理(ステップS35)、アニメーション表示処理(ステップS36)、UO処理(ステップS37)という3つの処理を繰り返し実行するというものである。Graphicalコントローラ17の処理手順は、第1実施形態の図36〜図38に示したものから、図71〜図78に示すものへと大きく変化している。
図72は、タイムスタンプによる同期制御の処理手順を示すフローチャートである。本フローチャートは、ステップS41、S43〜ステップS47の何れかの事象が成立しているかどうかを判定し、もしどれかの事象が成立すれば、該当する処理を実行してメインルーチンにリターンするというサブルーチンを構成する。
ステップS41は、現在の再生時点がS-ODSsfirstのPTSに示される時刻であるか、S-ODSslastのPTSに示される時刻であるかの判定であり、もしそうであるなら、ステップS42において期間αを算出する。期間αとは、グラフィクスプレーンのクリアに要する時間(2)、ODSのデコードにより得られたグラフィクスオブジェクトをグラフィクスプレーンに書き込む書込時間(3)を足し合わせた期間である。
ステップS42においてGraphicalコントローラ17は、ICSのSegment_Typeを参照し、もしSegment_TypeがEpoch Startなら、プレーンクリア期間(2)+プレーン書込期間(3)をαとする。Acquisition Pointならプレーン書込期間(3)をαとする。またプレーン書込期間(3)の算出にあたっては、default_selected_button_numberが有効な値であれば図54(a)の計算で、default_selected_button_numberが=0であれば図54(b)の計算で算出する。こうして期間αを算出した後、ループ処理にリターンする。
ステップS43は、現在の再生時点がICSのPTS-αに示される時刻であるかの判定であり、もしそうであれば、グラフィクスプレーン8への書き込み処理を行って(ステップS51)、メインルーチンにリターンする。
ステップS45は、現在の再生時点がICSのPTSであるかの判定である。もしそうであれば、グラフィクスプレーン8の格納内容の出力を開始させる。この格納内容の出力先は、CLUT部9であり、CLUT部9により色変換がなされた上で、対話画面はビデオプレーン6の格納内容と合成される。これにより初期表示が実行される(ステップS52)。そして変数animation(p)(p=1,2,3・・・n)を0を設定して(ステップS53)、メインルーチンにリターンする。ここで変数animation(p)とは、ボタン(p)のアニメーション表示を実行するにあたって、今何コマ目を表示しているかを示すグローバル変数(複数フローチャートにわたって有効になる変数)である。ステップS53では、全てのボタンについてのボタン(p)が、0に設定されることになる。
ステップS46、ステップS47は、ICSに記述された時間情報に現在の再生時点が到達したかどうかの判定である。
ステップS46は、現在の再生時点がselection_TimeOut_PTSに示される時刻であるかの判定であり、もしそうであれば、defaut_activated_button_numberで指定されるボタンをアクティベートする処理を行い、メインルーチンにリターンする(ステップS54)。
ステップS47は、現在の再生時点がComposition_TimeOut_PTSであるかの判定であり、もしそうであれば、画面クリアを行ってメインルーチンにリターンする(ステップS55)。以上がタイムスタンプによる同期処理である。この同期処理において、ステップS51、ステップS54の処理手順は、サブルーチン化されている。ステップS51のサブルーチンの処理手順を、図73を参照しながら説明する。
図73は、メニューの初期表示をグラフィクスプレーン8へ書き込む処理の処理手順を示すフローチャートである。ステップS64は、ICSにおけるSegment_typeがEpoch Startであるか否かの判定であり、もしEpoch StartであればステップS65においてグラフィクスプレーン8をクリアしてから、ステップS66〜ステップS73の処理を行う。グラフィクスプレーン8のクリアに要する期間が、図56、図57の期間cd1である。もしEpoch StartでなければステップS65をスキップしてステップS66〜ステップS73の処理を行う。
ステップS66〜ステップS73は、ICSにおける各ボタン情報について繰り返されるループ処理を形成している(ステップS66、ステップS67)。本ループ処理において処理対象になるべきボタン情報をボタン情報(p)という。
ステップS67は、default_selected_button_numberによる指定が有効であるか否かの判定であり、ステップS68は、button_info(p)はdefault_selected_button_numberにより指定されたデフォルトセレクテッドボタンに対応するボタン情報であるかの判定である。
デフォルトセレクテッドボタンに対応するボタン情報でないなら、button_info(p)のnormal_state_infoに指定されているstart_object_id_normalのグラフィクスオブジェクトを、グラフィクスオブジェクト(p)としてObject Buffer15から特定する(ステップS69)。
デフォルトセレクテッドボタンに対応するボタン情報であるなら、button_info(p)のselected_state_infoに指定されているstart_object_id_selectedのグラフィクスオブジェクトを、グラフィクスオブジェクト(p)としてObject Buffer15から特定して(ステップS70)、ボタン(p)をカレントボタンにする(ステップS71)。カレントボタンとは、現在表示中の対話画面において、セレクテッド状態になっているボタンであり、再生装置はこのカレントボタンの識別子を、PSR(10)として格納している。
ステップS69、ステップS70を経ることでグラフィクスオブジェクト(p)が特定されれば、button_info(p)のbutton_horizontal_position,button_vertical_positionに示されるグラフィクスプレーン8上の位置に、グラフィクスオブジェクト(p)を書き込む(ステップS72)。かかる処理をICSにおける各ボタン情報について繰り返せば、各ボタンの状態を表す複数グラフィクスオブジェクトのうち、最初のグラフィクスオブジェクトがグラフィクスプレーン8上に書き込まれることになる。Object Buffer15上の少なくとも初期表示に必要なグラフィクスオブジェクトについて、かかる処理を実行するのに要する期間が、図56、図57の期間td1である。以上がステップS51の詳細である。
default_selected_button_numberが”=0”であり、デフォルトセレクテッドボタンが動的に変わる場合は、ステップS67がNoになり、ステップS73においてbutton_info(p)は、カレントボタンに対応するbutton_infoであるか否かを判定する。もしそうであれば、ステップS70に、異なるならステップS69に移行する。
続いてステップS54のサブルーチンの処理手順を、図74を参照しながら説明する。
図74は、デフォルトセレクテッドボタンのオートアクティベートの処理手順を示すフローチャートである。先ずdefault_activated__button_numberが0であるか,FFであるかどうかを判定し(ステップS75)、00であれば何の処理も行わずメインルーチンにリターンする。FFであれば、カレントボタンiをアクティブ状態に遷移する(ステップS77)。そしてカレントボタンiに対応する変数animation(i)を0に設定してメインルーチンにリターンする(ステップS78)。
00でも、FFでもなければ、default_activated__button_numberで指定されるボタンをカレントボタンとし(ステップS76)、カレントボタンiをアクティブ状態に遷移し(ステップS77)、カレントボタンiに対応する変数animation(i)を0に設定してメインルーチンにリターンする(ステップS78)。
以上の処理により、セレクテッド状態のボタンは、所定時間の経過時においてアクティブ状態に遷移させられることになる。以上が、図74のフローチャートの全容である。
続いて、メニューにおけるアニメーション(ステップS36)について説明する。図75は、アニメーション表示の処理手順を示すフローチャートである。
ここで初期表示は、各button_infoのnormal_state_infoにおけるstart_object_id_normal、selected_state_infoにおけるstart_object_id_selectedで指定されているグラフィクスオブジェクトを、グラフィクスプレーン8に書き込まれることにより実現した。アニメーションとは、ステップS35〜ステップS37のループ処理が一巡する度に、各ボタンにおける任意のコマ(qコマ目にあるグラフィクスオブジェクト)をこのグラフィクスプレーン8に上書する処理である。この更新は、button_infoのnormal_state_info、selected_state_infoで指定されているグラフィクスオブジェクトを、一枚ずつグラフィクスプレーン8に書き込んでメインルーチンにリターンすることでなされる。ここで変数qとは、各ボタン情報のbutton_infoのnormal_state_info、selected_state_infoで指定されている個々のグラフィクスオブジェクトを指定するための変数である。
このアニメーション表示を実現するための処理を、図75を参照しながら説明する。尚本フローチャートは、記述の簡略化を期するため、ICSのrepeat_normal_flag、repeat_selected_flagが繰り返し要と設定されているとの前提で作図している。
ステップS80は初期表示が済んでいるか否かの判定であり、もし済んでいなけれ何の処理も行わずにリターンする。もし済んでいればステップS81〜ステップS93の処理を実行する。ステップS81〜ステップS93は、ICSにおける各button_infoについて、ステップS83〜ステップS93の処理を繰り返すというループ処理を構成している(ステップS81、ステップS82)。
ステップS83は、button_info(p)に対応する変数animation(p)を変数qに設定する。こうして、変数qは、button_info(p)に対応する、現在のコマ数を示すことになる。
ステップS84は、button_info(p)が、現在セレクテッド状態にあるボタン(カレントボタン)に対応するbutton_infoであるか否かの判定である。
カレントボタン以外のボタンならば、button_info(p).normal_state_infoにおけるstart_object_id_normalに変数qを足した識別子をID(q)とする(ステップS85)。
カレントボタンに対応するボタンであれば、ステップS86の判定を行う。
ステップS86は、カレントボタンがアクティブ状態であるかの判定であり、もしそうであれば、ステップS87においてbutton_info(p).actioned_state_infoにおけるstart_object_id_actionedに変数qを足した識別子をID(q)とする。そしてbutton_info(p)に含まれるボタンコマンドのうち、1つを実行する(ステップS88)。
カレントボタンがアクティブ状態でなければ、button_info(p).selected_state_infoにおけるstart_object_id_selectedに変数qを足した識別子をID(q)とする(ステップS89)。
こうしてID(q)が決まれば、Object Buffer15に存在する、ID(q)を有するグラフィクスオブジェクト(p)を、button_info(p)のbutton_horizontal_position,button_vertical_positionに示されるGraphics Plane8上の位置に書き込む(ステップS90)。
以上のループ処理により、カレントボタンのセレクテッド状態(若しくはアクティブ状態)及びその他のボタンのノーマル状態を構成する複数グラフィクスオブジェクトのうち、q枚目のものがグラフィクスプレーン8に書き込まれることになる。
ステップS91は、start_object_id_normal+qがend_object_id_normalに達したか否かの判定であり、もし達しないなら変数qをインクリメントした値を変数animation(p)に設定する(ステップS92)。もし達したなら変数animation(p)を0に初期化する(ステップS93)。以上の処理は、ICSにおける全てのbutton_infoについて繰り返される(ステップS81、ステップS82)。全てのbutton_infoについて、処理がなされれば、メインルーチンにリターンする。
以上のステップS80〜ステップS93により対話画面における各ボタンの絵柄は、ステップS35〜ステップS37が一巡する度に新たなグラフィクスオブジェクトに更新される。ステップS35〜ステップS37の処理が何度も反復されれば、いわゆるアニメーションが可能になる。アニメーションにあたって、グラフィクスオブジェクト一コマの表示間隔は、animation_frame_rate_codeに示される値になるようにGraphicsコントローラ17は時間調整を行う。
尚、ステップS88においてbutton_info(p)に含まれるボタンコマンドを1つずつ実行したが、アクティブ状態に対応するグラフィクスオブジェクトを一通り表示した後に、button_info(p)に含まれるボタンコマンドをまとめて実行してもよい。以上でアニメーション表示処理についての説明を終わる。続いてメインルーチンのステップS37におけるUO処理の処理手順について図76を参照しながら説明する。
図76は、UO処理の処理手順を示すフローチャートである。本フローチャートは、ステップS100〜ステップS103の何れかの事象が成立しているかどうかを判定し、もしどれかの事象が成立すれば、該当する処理を実行してメインルーチンにリターンする。ステップS100は、UOmaskTableが"1"に設定されているかどうかの判定であり、もしに設定されていれば、何の処理も行わずに、メインルーチンにリターンする。
ステップS101は、MoveUP/Down/Left/Rightキーが押下されたかどうかの判定であり、もしこれらのキーが押下されれば、カレントボタンを変更して(ステップS104)、カレントボタンのauto_action_flagが01かどうかを判定する(ステップS108)。もし違うならメインルーチンにリターンする。もしそうであるなら、ステップS105に移行する。
ステップS102は、activatedキーが押下されたかどうかの判定であり、もしそうであれば、カレントボタンiをアクティブ状態に遷移する(ステップS105)。その後、変数animation(i)を0に設定する(ステップS106)。
ステップS103は、数値入力であるかどうかの判定であり、もし数値入力であれば、数値入力処理を行って(ステップS107)、メインルーチンにリターンする。図76の処理手順のうち、ステップS104、ステップS107はサブルーチン化されている。このサブルーチンの処理手順を示したのが図77、図78である。以降これらのフローチャートについて説明する。
図77は、カレントボタンの変更処理の処理手順を示すフローチャートである。先ず初めに、カレントボタンのneighbor_infoにおけるupper_button_number,lower_button_number,left_button_number,right_button_numberのうち、押下されたキーに対応するものを特定する(ステップS110)。
そしてカレントボタンをボタンiとし、新たにカレントボタンになるボタンをボタンjとする(ステップS111)。ステップS112は、ステップS111で特定されたボタンjが、ボタンiと一致しているかどうかの判定である。もし一致していれば、何の処理も行わずにメインルーチンにリターンする。もし一致しなければ、ボタンjをカレントボタンにして(ステップS113)、変数animation(i),変数animation(j)を0に設定した上でメインルーチンにリターンする(ステップS114)。
図78は、数値入力処理の処理手順を示すフローチャートである。入力された数値に合致するbutton_numberを有したButton info.jが存在するかどうかの判定を行い(ステップS121)、Button info.jにおけるnumerically_selectable_flagは1であるかどうかの判定を行う(ステップS122)。ステップS121及びステップS122がYesなら、カレントボタンをノーマル状態に遷移させ、ボタンjをカレントボタンにして(ステップS123)、変数animation(i),変数animation(j)を0に設定した上で(ステップS124)、Button info.jのauto_action_flagは1であるかを判定する(ステップS125)。1でないならメインルーチンにリターンする。
1であるなら、ステップS126においてカレントボタンをアクティブ状態に遷移した上でメインルーチンにリターンする。
ステップS121〜S122のどちらかがNoなら、そのままメインルーチンにリターンする。
以上が同期表示を行う場合のGraphicsコントローラ17の処理手順である。Popup表示のように、ユーザ操作をトリガとした対話画面表示を行う場合、Stream Graphicsプロセッサ14、Graphicsコントローラ17は以下のような処理を行う。つまり、同期表示の場合と同様の処理を行う。これにより、グラフィクスプレーン8にはグラフィックスオブジェクトが得られる。このようにグラフィックスオブジェクトを得た後、現在の再生時点が、ICSに付加されたPTSに示される時点を経過するのを待つ。そしてこの再生時点の経過後、UOコントローラ18がメニューコールを示すUOを受け付れば、グラフィクスプレーン8に格納されたグラフィックスオブジェクトを合成させるよう、CLUT部9に出力する。UOに同期して、かかる出力を行えば、メニューコールの押下に応じたPopup表示を実現することができる。
以上、DSnに属するICSのPTS,ODSのDTS、PTSの設定について説明したが、ICSのDTSや、PDSのDTS、PTS、ENDのDTS、PTSについては説明していない。以下、これらのタイムスタンプについて説明する。第2実施形態ではWDSは存在しないので、ICSは、DSnにおける最初のODS(ODS1)のデコード開始時点(DTS(DSn[ODS1]))以前、及び、DSnにおける最初のPDS(PDS1)が有効になる時点(PTS(DSn[PDS1]))以前に、Compositionバッファ16にロードされねばならない。よって以下の式の関係を満たす値に、設定されねばならない。
DTS(DSn[ICS])≦DTS(DSn[ODS1])
DTS(DSn[ICS])≦PTS(DSn[PDS1])
続いてDSnに属する各PDSのDTS,PTSの設定について説明する。
DSnに属する各PDSは、ICSがCompositionバッファ16にロードされる時点(DTS(DSn[ICS]))から、最初のODSのデコード開始時点(DTS(DSn[ODS1]))までに、CLUT部9において、有効になればよい。このことからDSnに属する各PDS(PDS1〜PDSlast)のPTS値は、以下の関係を満たす値に、設定されねばならない。
DTS(DSn[ICS])≦PTS(DSn[PDS1])
PTS(DSn[PDSj])≦PTS(DSn[PDSj+1])≦PTS(DSn[PDSlast])
PTS(DSn[PDSlast])≦DTS(DSn[ODS1])
続いてDSnに属するEND of Display SetSegmentのPTSの設定について説明する。DSnに属するENDは、DSnの終わりを示すものだから、DSnに属する最後のODS(ODSlast)のデコード終了時刻を示せばよい。このデコード終了時刻は、ODSlastのPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定されねばならない。
PTS(DSn[END]) = PTS(DSn[ODSlast])
DSn,DSn+1に属するICSとの関係で考えれば、DSnにおけるICSは、最初のODS(ODS1)のロード時刻以前に、Compositionバッファ16にロードされるから、ENDのPTSは、DSnに属するICSのロード時刻(DTS(DSn[ICS]))以降、DSn+1に属するICSのロード時刻(DTS(DSn+1[ICS]))以前でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
DTS(DSn[ICS])≦PTS(DSn[END])≦DTS(DSn+1[ICS])
一方、最初のODS(ODS1)のロード時刻は、最後のPDS(PDSlast)のロード時刻以後であるから、ENDのPTS(PTS(DSn[END]))は、DSnに属するPDSのロード時刻以降(PTS(DSn[PDSlast]))でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
PTS(DSn[PDSlast])≦PTS(DSn[END])
DTS,PTSが設定されたICS,PDS,ODSをAVClipに組み込んでおくので、ある動画の一コマが画面に現れたタイミングに、特定の処理を再生装置に実行させるという対話制御、つまり動画内容と緻密に同期した対話制御の記述に便利である。またICS,PDS,ODSは、AVClip自身に多重化されているので、再生制御を行いたい区間が数百個であっても、それらに対応するICS,PDS,ODSの全てをメモリに格納しておく必要はない。ICS,PDS,ODSはビデオパケットと共にBD-ROMから読み出されるので、現在再生すべき動画区間に対応するICS,PDS,ODSをメモリに常駐させ、この動画区間の再生が終われば、ICS,PDS,ODSをメモリから削除して、次の動画区間に対応するICS,PDS,ODSをメモリに格納すればよい。ICS,PDS,ODSは、AVClipに多重化されるので、たとえICS,PDS,ODSの数が数百個になってもメモリの搭載量を必要最低限にすることができる。
以上のように本実施形態によれば、アニメーションを実現するためのODSが360枚存在しており、ボタン部材が3つの状態をもっている場合、ODSは、120枚+120枚+120枚というように、3つのbutton-stateグループにグルーピングされる。そして個々のbutton-stateグループは、早く現れる状態に対応するもの程、前に置かれ、遅く現れる状態に対応するもの程、後に置かれる。このため、再生時にあたって、早く現れる状態に対応するbutton-stateグループの再生装置へのロードは早く行われ、遅く現れる状態に対応するbutton-stateグループのロードは、後回しにされる。早く現れる状態に対応するbutton-stateグループのロードは早い時期になされるので、360枚のものODSの読み出し/デコードは未完であっても、全体の約1/3〜2/3のODSの読み出し/デコードが完了していれば、初期表示のための準備は整う。全体の約1/3〜2/3のODSの読み出し/デコードの完了時点で、初期表示のための処理を開始させることができるので、たとえ読み出し/デコードすべきODSが大量にあっても、初期表示の実行は遅滞することはない。このため、アニメーションを伴った楽しい対話画面の表示を、迅速に実行することができる。
(第3実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図79は、第1実施形態に示したPCSを作成するための製造工程を示す図である。
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程S201、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程S202、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程S203を含む。
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップS204〜ステップS210を含む。
ステップS204において制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを記述し、ステップS205では、制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを機能セグメントに変換する。そしてステップS206において同期したいピクチャが出現するタイミングに基づき、PCSのPTSを設定し、ステップS207では、PTS[PCS]の値に基づき、DTS[ODS],PTS[ODS]を設定する。ステップS208において、DTS[ODS]の値に基づき、DTS[PCS],PTS[PDS],DTS[WDS],PTS[WDS]を設定し、ステップS209では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップS210では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップS211において各機能セグメントのDTS、PTSを書き換える。もし満たすならステップS212においてグラフィクスストリームを生成し、ステップS213においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してAVClipを得る。以降、AVClipをBD-ROMのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
以上が、第1実施形態に係る記録媒体の製造工程である。第2実施形態に係る記録媒体の製造工程は、図80に示すものとなる。図79と比較すると、図80は、ステップS204〜ステップS208が、ステップS304〜ステップS308に置き換えられている。
以降ステップS304〜ステップS308について説明する。ステップS304において制御情報、パレット定義情報、グラフィクスを記述し、ステップS305において、制御情報、パレット定義情報、グラフィクスを機能セグメントに変換する。ステップS306では、同期したいピクチャが出現するタイミングに基づき、ICSのPTSを設定する。そしてステップS307では、PTS[ICS]の値に基づき、DTS[ODS],PTS[ODS]を設定し、ステップS308においてDTS[ODS]の値に基づき、DTS[ICS],PTS[PDS]を設定する。
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
(A)全ての実施形態では、本発明に係る記録媒体をBD-ROMとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ(登録商標)カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレキシブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバブルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。
(B)全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムLSI(集積回路)のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、第1実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第1実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、第1実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
(E)BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arrival_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”Aligned Unit”という。
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、Aligned Unitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArribval_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
(F)各実施形態におけるデジタルストリームは、BD-ROM規格のAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(Video Object)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。
(G)各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ/デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ/デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
(H)第1実施形態〜第2実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いている。デコードを実現する装置構成を、字幕−グラフィックスオブジェクト間で共通化する目的で、字幕と同じ圧縮・伸長方式をグラフィックスオブジェクトに採用している。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはPNGデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
(I)PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
(J)PCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBD-ROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
(K)第1実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25%に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。
(L)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
(M)グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、商標を構成するような図形,文字,色彩の組合せや、国の紋章,旗章,記章,国家が採用する監督/証明用の公の記号・印章、政府間国際機関の紋章,旗章,記章,特定商品の原産地表示を含んでいてもよい。
(N)第1実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
(O)各実施形態におけるAVClipは、映画作品を構成するものであったが、AVClipはカラオケを実現するものであってもよい、そしてこの場合、PCSは歌の進行に応じて、字幕の色を変えるという表示効果を実現してもよい。
(P)複数再生経路の合流点においてデフォルトセレクテッドボタンが変わるようなケースでは、複数再生経路のそれぞれの経由時に、固有の値を再生装置側のレジスタに設定するよう、動的シナリオにおいて再生制御を記述しておくことが望ましい。そして、そのレジスタの設定値に応じたボタンをセレクテッド状態に設定するよう再生手順を記述しておけば、どの再生経路を経由するかによって、セレクテッド状態とすべきボタンを変化させることができる。
本発明に係る生装置は、表示効果を伴う字幕表示やアニメーションを伴う対話表示を実現することができるので、より付加価値が高い映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
本発明に係る記録媒体の、使用行為についての形態を示す図である。 BD-ROMの構成を示す図である。 AVClipがどのように構成されているかを模式的に示す図である。 (a)プレゼンテーショングラフィクスストリームの構成を示す図である。 (b)機能セグメントを変換することで得られるPESパケットを示す図である。 様々な種別の機能セグメントにて構成される論理構造を示す図である。 字幕の表示位置と、Epochとの関係を示す図である。 (a)ODSによるグラフィクスオブジェクトの定義を示す図である。 (b)PDSのデータ構造を示す図である。 (a)WDSのデータ構造を示す図である。 (b)PCSのデータ構造で構成される。 字幕表示を実現するためのDisplay Setの記述例である。 DS1におけるWDS、PCSの記述例を示す図である。 DS2におけるPCSの記述例を示す図である。 DS3におけるPCSの記述例を示す図である。 時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。 時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。 時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。 時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。 ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。 decode_durationの計算アルゴリズムの一例を示す図である。 図18のプログラムのアルゴリズムを図式化したフローチャートである。 (a)(b)図18のプログラムのアルゴリズムを図式化したフローチャートである。 (a)1つのwindowに1つのODSが存在するケースを想定した図である。 (b)(c)図18で引用した各数値の時間的な前後関係を示すタイミングチャートである。 (a)1つのwindowに2つのODSが存在するケースを想定した図である。 (b)(c)図18で引用した各数値の時間的な前後関係を示すタイミングチャートである。 (a)2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定したタイミングチャートである。 (b)デコード期間(2)がクリア期間(1)+書込期間(31)より長くなるケースを示すタイミングチャートである。 (c)クリア期間(1)+書込期間(31)がデコード期間(2)より長くなるケースを示すタイミングチャートである。 アップデートの、時間的変遷の具体例を示す図である。 (a)図24に示したアップデートを実現するため、記述された4つのDisplay Setを示す図である。 (b)図25(a)におけるDisplay Setに属する各機能セグメントのDTS、PTSがどのように設定されているかを示すタイミングチャートである。 本発明に係る再生装置の内部構成を示す図である。 書込レートRx,Rc,Rd、グラフィクスプレーン8、Coded Data Buffer13、Object Buffer15、Composition Buffer16のサイズを示す図である。 再生装置によるパイプライン処理を示すタイミングチャートである。 ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。 機能セグメントのロード処理の処理手順を示すフローチャートである。 多重化の一例を示す図である。 DS10が再生装置のCoded Data Buffer13にロードされる様子を示す図である。 通常再生が行われる場合を示す図である。 図33のように通常再生が行われた場合のDS1,10,20のロードを示す図である。 Graphical Controller17の処理手順を示すフローチャートである。 Graphical Controller17の処理手順を示すフローチャートである。 Graphical Controller17の処理手順を示すフローチャートである。 PDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。 再生装置のパイプライン動作時における、ENDの意味合いを示す図である。 第2実施形態に係る再生装置の内部構成を示す図である。 ダブルバッファによるグラフィックスプレーン読み出し/書き込みを模式的に示す図である。 (a)(b)第2実施形態に係る対話画面についての説明図である。 Interactive Composition Segmentのデータ構造を示す図である。 あるDSnに含まれるODSと、ICSとの関係を示す図である。 任意のピクチャデータpt1の表示タイミングにおける画面合成を示す図である。 ICSにおけるボタン情報の設定例を示す図である。 ボタンA〜ボタンDの状態遷移を示す図である。 ODS11,21,31,41の絵柄の一例を示す図である。 ボタンA用のODS11〜19の絵柄の一例を示す図である。 Display Setに属するODSの順序及びbutton-stateグループを示す図である。 図50のbutton-stateグループが配置された対話画面における状態遷移を示す図である。 Display SetにおけるODSの順序を示す図である。 default_selected_button_numberが”=0”である場合と、”=ボタンB”である場合とでS-ODSsにおいてODSの並びがどのように変わるかを示す図である。 (a)(b)N-ODSsにボタンA〜Dを構成する複数ODSが含まれており、S-ODSsにボタンA〜Dを構成する複数ODSが含まれている場合、ΣSIZE(DSn[ICS.BUTTON[i]])がどのような値になるかを示す図である。 ICSによる同期表示時のタイミングを示す図である。 対話画面の初期表示が複数ODSにて構成され、default_selected_button_numberが有効である場合のDTS、PTSの設定を示す図である。 対話画面の初期表示が複数ODSにて構成され、default_selected_button_numberが無効である場合のDTS、PTSの設定を示す図である。 Object Buffer15の格納内容をグラフィクスプレーン8と対比して示す図である。 初期表示時におけるGraphicsコントローラ17の処理を示す図である。 1stUserAction(MoveRight)による対話画面更新時におけるGraphicsコントローラ17の処理を示す図である。 1stUserAction(MoveDown)による対話画面更新時におけるGraphicsコントローラ17の処理を示す図である。 1stUserAction(Activated)による対話画面更新時におけるGraphicsコントローラ17の処理を示す図である。 再生装置によるパイプライン処理を示すタイミングチャートである。 デフォルトセレクテッドボタンが動的に変わる場合の、再生装置によるパイプライン処理を示すタイミングチャートである。 Compositionバッファ16、Object Buffer15、Coded Dataバッファ13、グラフィクスプレーン8における占有量の時間的遷移を示すタイミングチャートである。 Segmentのロード処理の処理手順を示すフローチャートである。 多重化の一例を示す図である。 DS10が再生装置のCoded Dataバッファ13にロードされる様子を示す図である。 通常再生が行われる場合を示す図である。 図69のように通常再生が行われた場合のDS1,10,20のロードを示す図である。 Graphicsコントローラ17の処理手順のうち、メインルーチンにあたる処理を描いたフローチャートである。 タイムスタンプによる同期制御の処理手順を示すフローチャートである。 グラフィクスプレーン8の書込処理の処理手順を示すフローチャートである。 デフォルトセレクテッドボタンのオートアクティベートの処理手順を示すフローチャートである。 アニメーション表示の処理手順を示すフローチャートである。 UO処理の処理手順を示すフローチャートである。 カレントボタンの変更処理の処理手順を示すフローチャートである。 数値入力処理の処理手順を示すフローチャートである。 第1実施形態に示したPCSが記録されたBD-ROMを製造するための製造工程を示す図である。 第2実施形態に示したICSが記録されたBD-ROMを製造するための製造工程を示す図である。
符号の説明
1 BDドライブ
2 Read Buffer
3 PIDフィルタ
4a,b,c、Transport Buffer
4d 周辺回路
5 ビデオデコーダ
6 ビデオプレーン
7 オーディオデコーダ
8 グラフィクスプレーン
9 CLUT部
10 加算器
12 グラフィクスデコーダ
13 Coded Data Buffer
13a 周辺回路
14 Stream Graphics Processor
15 Object Buffer
16 Composition Buffer
17 Graphical Controller
100 BD-ROM
200 再生装置
300 テレビ
400 リモコン

Claims (5)

  1. 動画ストリーム、グラフィクスストリームが多重化されたデジタルストリームについての再生装置であって、
    動画ストリームをデコードして動画像を得るビデオデコーダと、
    グラフィクスを、動画像に合成して表示させるグラフィクスデコーダとを備え、
    グラフィクスストリームは、複数パケットからなるパケット列であり、
    パケットには、グラフィクスデータを格納したデータパケットと、制御情報を格納した制御パケットとがあり、
    前記グラフィクスデコーダは、
    動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するプロセッサと、
    制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させるコントローラと、
    圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、
    プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、
    再生装置は、オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
    前記グラフィクスデータの個数は2つであり、
    制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、
    前記グラフィクスデータは2つであり、
    所定の値とは、期間Xと、期間Yとの和であり、
    期間Xは、
    画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和(a)、及び、
    2つのグラフィクスデータのデコードに要する総時間(b) のうち長いものであり、
    期間Yは、デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、
    前記コントローラは、
    メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行う
    ことを特徴とする再生装置。
  2. 動画ストリーム、グラフィクスストリームが多重化されたデジタルストリームについての再生装置に用いられる集積回路であって、
    動画ストリームをデコードして動画像を得るビデオデコーダと、
    グラフィクスを、動画像に合成して表示させるグラフィクスデコーダとを備え、
    グラフィクスストリームは、複数パケットからなるパケット列であり、
    パケットには、グラフィクスデータを格納したデータパケットと、制御情報を格納した制御パケットとがあり、
    前記グラフィクスデコーダは、
    動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するプロセッサと、
    制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させるコントローラと、
    圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、
    プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、
    前記再生装置は、オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
    前記グラフィクスデータの個数は2つであり、
    制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、
    前記グラフィクスデータは2つであり、
    所定の値とは、期間Xと、期間Yとの和であり、
    期間Xは、
    画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和(a)、及び、
    2つのグラフィクスデータのデコードに要する総時間(b) のうち長いものであり、
    期間Yは、デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、
    前記コントローラは、
    メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行う
    ことを特徴とする集積回路。
  3. 動画ストリーム、グラフィクスストリームが多重化されたデジタルストリームについての再生をコンピュータに実行させるプログラムであって、
    動画ストリームをデコードして動画像を得る処理をコンピュータに行わせるコードと、
    グラフィクスを、動画像に合成して表示させる処理をコンピュータに行わせるコードとを備え、
    グラフィクスストリームは、複数パケットからなるパケット列であり、
    パケットには、グラフィクスデータを格納したデータパケットと、制御情報を格納した制御パケットとがあり、
    前記グラフィクスを動画像に合成して表示させるコードは、
    動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するデコード処理と、
    制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させる制御処理とをコンピュータに実行させ、
    前記コンピュータにおけるデコーダ回路は、
    圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、
    プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、
    前記コンピュータは、オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
    前記グラフィクスデータの個数は2つであり、
    制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、
    前記グラフィクスデータは2つであり、
    所定の値とは、期間Xと、期間Yとの和であり、
    期間Xは、
    画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和(a)、及び、
    2つのグラフィクスデータのデコードに要する総時間(b) のうち長いものであり、
    期間Yは、デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、
    前記制御処理は、
    メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行う
    ことを特徴とするプログラム。
  4. 動画ストリーム、グラフィクスストリームが多重化されたデジタルストリームについての再生をコンピュータ上で実現する再生方法であって、
    動画ストリームをデコードして動画像を得る処理、
    グラフィクスを、動画像に合成して表示させる処理を備え、
    前記グラフィクスを動画像に合成して表示させる処理は、
    動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するデコード処理と、
    制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させる制御処理とを含み、
    前記コンピュータにおけるデコーダ回路は、
    圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、
    プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、
    前記コンピュータは、オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
    前記グラフィクスデータの個数は2つであり、
    制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、
    前記グラフィクスデータは2つであり、
    所定の値とは、期間Xと、期間Yとの和であり、
    期間Xは、
    画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和(a)、及び、
    2つのグラフィクスデータのデコードに要する総時間(b) のうち長いものであり、
    期間Yは、デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、
    前記制御処理は、
    メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行う
    ことを特徴とする再生方法。
  5. デジタルストリームが記録されている記録媒体と前記記録媒体を再生する再生装置とを備えた記録媒体再生システムであって、
    前記記録媒体は、
    デジタルストリームが記録されており、
    デジタルストリームは、グラフィクスストリームと動画ストリームとを多重したものであり、グラフィクスストリームは、複数パケットからなるパケット列であり、
    グラフィクスストリームを構成するパケットには、グラフィクスデータを格納したデータパケットと、制御情報を格納した制御パケットとがあり、
    データパケットのタイムスタンプの値は、グラフィクスデータのデコードタイミングを示し、
    前記制御情報は、メモリ管理の始まりである旨を示すタイプ情報を有しており、
    制御パケットは、プレゼンテーションタイムスタンプと、デコードタイムスタンプとを有しており、
    プレゼンテーションタイムスタンプの値は、デコードされたグラフィクスデータを、動画ストリームに合成して表示させるタイミングを示し、
    前記デコードタイムスタンプの値は、デジタルストリームの再生時間軸におけるメモリ管理の開始時点、及び、当該制御情報をメモリに読み出すタイミングを示し、
    前記グラフィクスデータの個数は2つであり、
    制御パケットのプレゼンテーションタイムスタンプ値は、制御パケットのデコードタイムスタンプ値に所定の値を足し合わせた値であり、
    所定の値とは、期間Xと、期間Yとの和であり、
    期間Xは、
    画面クリアに要する時間と、デコードされた1つ目のグラフィクスデータの書き込みに要する時間との和、及び、
    2つのグラフィクスデータのデコードに要する総時間のうち長いものであり、
    期間Yは、
    デコードされた2つ目のグラフィクスデータの画面への書き込みに要する時間を足し合わせた時間であり、
    前記再生装置は、
    前記記録媒体に記録されている動画ストリームをデコードして動画像を得るビデオデコーダと、
    前記記録媒体に記録されているグラフィクスストリームを、動画像に合成して表示させるグラフィクスデコーダとを備え、
    前記グラフィクスデコーダは、
    動画ストリームの現在の再生時点が、グラフィクスデータを格納したパケットのデコードタイムスタンプに示される時点に達すれば、グラフィクスデータのデコードを開始し、同パケットのプレゼンテーションタイムスタンプの値に示される時点に達すれば、グラフィクスデータのデコードを終了するプロセッサと、
    制御パケットのプレゼンテーションタイムスタンプに従い、デコードされたグラフィクスデータを、動画ストリームに合成して表示させるコントローラと、
    圧縮状態のグラフィクスデータを格納するコーデッドデータバッファと、
    プロセッサのデコードにより得られた非圧縮状態のグラフィクスデータを格納するオブジェクトバッファとを備え、
    前記再生装置は、
    前記オブジェクトバッファに格納された非圧縮状態のグラフィクスデータのうち、表示に供されるべきものを格納するグラフィックスプレーンを備え、
    前記コントローラは、
    メモリ管理の始まりである旨を示すタイプ情報が制御情報に含まれているか否かを判定し、含まれている場合、動画ストリームの現在の再生時点が、制御パケットのデコードタイムスタンプの値に到達した段階で、コーデッドデータバッファ、オブジェクトバッファ、グラフィックスプレーンをクリアすることでメモリ管理を開始して、制御パケットから制御情報を読み出し、現在の再生時点が、制御パケットのプレゼンテーションタイムスタンプの値になれば、グラフィックスプレーンの格納内容の表示を行う
    ことを特徴とする記録媒体再生システム。
JP2007129191A 2003-07-03 2007-05-15 再生装置,集積回路,プログラム,再生方法 Active JP4022567B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US48520703P 2003-07-03 2003-07-03

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006516863A Division JP3993626B2 (ja) 2003-07-03 2004-07-05 再生装置,集積回路,プログラム,再生方法

Publications (2)

Publication Number Publication Date
JP2007282260A JP2007282260A (ja) 2007-10-25
JP4022567B2 true JP4022567B2 (ja) 2007-12-19

Family

ID=33564048

Family Applications (8)

Application Number Title Priority Date Filing Date
JP2006516863A Active JP3993626B2 (ja) 2003-07-03 2004-07-05 再生装置,集積回路,プログラム,再生方法
JP2006283107A Expired - Fee Related JP4048220B2 (ja) 2003-07-03 2006-10-17 再生装置,集積回路,プログラム,再生方法、記録媒体再生システム
JP2007129190A Active JP4283860B2 (ja) 2003-07-03 2007-05-15 再生装置、再生方法、記録装置、記録方法
JP2007129191A Active JP4022567B2 (ja) 2003-07-03 2007-05-15 再生装置,集積回路,プログラム,再生方法
JP2008279457A Expired - Fee Related JP4774431B2 (ja) 2003-07-03 2008-10-30 再生装置,再生方法,記録媒体,記録装置,記録方法
JP2008279456A Active JP4287500B2 (ja) 2003-07-03 2008-10-30 再生装置、再生方法、記録装置、記録方法
JP2009118704A Expired - Fee Related JP5059805B2 (ja) 2003-07-03 2009-05-15 再生装置、再生方法、記録装置、記録方法、再生プログラム
JP2009118702A Expired - Fee Related JP4990932B2 (ja) 2003-07-03 2009-05-15 再生装置、再生方法、記録装置、記録方法、再生プログラム、集積回路

Family Applications Before (3)

Application Number Title Priority Date Filing Date
JP2006516863A Active JP3993626B2 (ja) 2003-07-03 2004-07-05 再生装置,集積回路,プログラム,再生方法
JP2006283107A Expired - Fee Related JP4048220B2 (ja) 2003-07-03 2006-10-17 再生装置,集積回路,プログラム,再生方法、記録媒体再生システム
JP2007129190A Active JP4283860B2 (ja) 2003-07-03 2007-05-15 再生装置、再生方法、記録装置、記録方法

Family Applications After (4)

Application Number Title Priority Date Filing Date
JP2008279457A Expired - Fee Related JP4774431B2 (ja) 2003-07-03 2008-10-30 再生装置,再生方法,記録媒体,記録装置,記録方法
JP2008279456A Active JP4287500B2 (ja) 2003-07-03 2008-10-30 再生装置、再生方法、記録装置、記録方法
JP2009118704A Expired - Fee Related JP5059805B2 (ja) 2003-07-03 2009-05-15 再生装置、再生方法、記録装置、記録方法、再生プログラム
JP2009118702A Expired - Fee Related JP4990932B2 (ja) 2003-07-03 2009-05-15 再生装置、再生方法、記録装置、記録方法、再生プログラム、集積回路

Country Status (16)

Country Link
US (3) US8280230B2 (ja)
EP (6) EP2259582B1 (ja)
JP (8) JP3993626B2 (ja)
KR (2) KR101036991B1 (ja)
CN (6) CN101729914B (ja)
AT (4) ATE493844T1 (ja)
AU (2) AU2004300623C1 (ja)
CA (1) CA2528585C (ja)
DE (4) DE602004014042D1 (ja)
ES (2) ES2356582T3 (ja)
PL (2) PL1940166T3 (ja)
PT (2) PT2088779E (ja)
RU (2) RU2477574C2 (ja)
TW (2) TWI359408B (ja)
WO (1) WO2005004478A1 (ja)
ZA (1) ZA200509946B (ja)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8737810B2 (en) 2002-11-15 2014-05-27 Thomson Licensing Method and apparatus for cropping of subtitle elements
JP3878650B2 (ja) 2003-02-28 2007-02-07 松下電器産業株式会社 記録媒体、再生装置、記録方法、プログラム、再生方法。
EP2068563B1 (en) 2003-06-30 2010-11-10 Panasonic Corporation Recording medium, reproduction device, recording method, program, and reproduction method
KR20050012328A (ko) * 2003-07-25 2005-02-02 엘지전자 주식회사 고밀도 광디스크의 프레젠테이션 그래픽 데이터 관리 및재생방법과 그에 따른 고밀도 광디스크
TWI279788B (en) * 2003-07-24 2007-04-21 Lg Electronics Inc Recording medium having a data structure for managing reproduction of text subtitle data recorded thereon and recording and reproducing methods and apparatuses
KR20050035678A (ko) * 2003-10-14 2005-04-19 엘지전자 주식회사 광디스크 장치의 부가 데이터 재생방법 및 장치와, 이를위한 광디스크
KR20050036277A (ko) * 2003-10-15 2005-04-20 엘지전자 주식회사 고밀도 광디스크의 네비게이션 정보 관리방법
CN100550178C (zh) * 2003-11-12 2009-10-14 松下电器产业株式会社 再现装置和方法以及记录方法
KR20050072256A (ko) * 2004-01-06 2005-07-11 엘지전자 주식회사 고밀도 광디스크의 메뉴 사운드 구성방법 및 재생방법과기록재생장치
WO2005069615A1 (ja) 2004-01-13 2005-07-28 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、記録方法、プログラム、再生方法
US20080002947A1 (en) * 2004-02-06 2008-01-03 Wataru Ikeda Recording medium, reproduction device, program and reproduction method
US8391672B2 (en) * 2004-02-06 2013-03-05 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
KR100561417B1 (ko) * 2004-02-09 2006-03-16 삼성전자주식회사 Av 데이터의 재생상태를 전환할 수 있는 인터랙티브그래픽 스트림을 기록한 정보저장매체, 그 재생방법 및 장치
KR20050089353A (ko) * 2004-03-04 2005-09-08 엘지전자 주식회사 고밀도 광디스크와 그에 따른 데이터 파일 구성 방법 및재생 방법과 장치
JP4496170B2 (ja) 2004-02-17 2010-07-07 パナソニック株式会社 記録方法、再生装置、プログラム、再生方法
JP2007529821A (ja) * 2004-03-15 2007-10-25 トムソン ライセンシング 効率的なビデオのリサンプリング方法
WO2005088635A1 (en) * 2004-03-18 2005-09-22 Lg Electronics Inc. Recording medium and method and apparatus for reproducing text subtitle stream recorded on the recording medium
US7756398B2 (en) 2004-03-26 2010-07-13 Lg Electronics, Inc. Recording medium and method and apparatus for reproducing text subtitle stream for updating palette information
BRPI0509231A (pt) 2004-03-26 2007-09-04 Lg Electronics Inc meio de gravação, método e aparelho para reproduzir fluxos de subtìtulo de texto
DE602005017824D1 (de) * 2004-06-02 2009-12-31 Panasonic Corp Aufzeichnugsmedium, Wiedergabegerät, Programm und Verfahren zur Wiedergabe
JP4692950B2 (ja) * 2004-06-11 2011-06-01 ソニー株式会社 データ処理装置およびデータ処理方法、プログラムおよびプログラム記録媒体、並びにデータ記録媒体
US8000580B2 (en) 2004-11-12 2011-08-16 Panasonic Corporation Recording medium, playback apparatus and method, recording method, and computer-readable program
WO2006095933A1 (en) * 2005-03-08 2006-09-14 Samsung Electronics Co., Ltd. An storage medium including data structure for reproducing interactive graphic streams supporting multiple languages seamlessly, apparatus and method therefor
US9167220B2 (en) * 2005-04-26 2015-10-20 Thomson Licensing Synchronized stream packing
WO2007013378A1 (ja) * 2005-07-27 2007-02-01 Matsushita Electric Industrial Co., Ltd. 情報記録媒体、記録装置、および記録方法
US20080238938A1 (en) * 2005-08-29 2008-10-02 Eklund Don Effects for interactive graphic data in disc authoring
US20090196356A1 (en) * 2005-09-14 2009-08-06 Mitsunori Houki Multi-stream decoder apparatus
US20070218444A1 (en) * 2006-03-02 2007-09-20 David Konetski System and method for presenting karaoke audio features from an optical medium
US20070206929A1 (en) * 2006-03-02 2007-09-06 David Konetski System and method for presenting karaoke audio and video features from an optical medium
JP5001584B2 (ja) 2006-06-06 2012-08-15 ソニー株式会社 オーサリング装置、オーサリング方法、オーサリングプログラム、記録装置、記録方法および記録プログラム、検証装置、検証方法および検証プログラム、ならびに、記録媒体の製造装置および製造方法
US7895560B2 (en) * 2006-10-02 2011-02-22 William Stuart Lovell Continuous flow instant logic binary circuitry actively structured by code-generated pass transistor interconnects
US7852339B2 (en) * 2006-10-23 2010-12-14 Intel Corporation Video composition optimization by the identification of transparent and opaque regions
KR101512988B1 (ko) 2007-12-26 2015-04-17 코닌클리케 필립스 엔.브이. 그래픽 오브젝트를 중첩하기 위한 이미지 프로세서
JP4518194B2 (ja) * 2008-06-10 2010-08-04 ソニー株式会社 生成装置、生成方法、及び、プログラム
CA2691727C (en) 2008-09-30 2016-10-04 Panasonic Corporation Recording medium, playback device, system lsi, playback method, glasses, and display device for 3d images
JP4985807B2 (ja) * 2009-04-15 2012-07-25 ソニー株式会社 再生装置および再生方法
CN102362504B (zh) * 2009-09-25 2014-07-09 松下电器产业株式会社 记录方法及再现装置
US8521006B2 (en) * 2010-05-06 2013-08-27 Intel Corporation Boundary detection in media streams
US9160960B2 (en) * 2010-12-02 2015-10-13 Microsoft Technology Licensing, Llc Video preview based browsing user interface
EP2597876A1 (en) * 2011-11-24 2013-05-29 Koninklijke Philips Electronics N.V. Interlaced 3D video
KR20140031758A (ko) * 2012-09-05 2014-03-13 삼성전자주식회사 포인팅 디바이스를 이용하여 aⅴ 데이터의 메뉴를 제어하기 위한 인터랙티브 그래픽 데이터를 기록한 정보저장매체, 그 재생방법 및 장치
US9813325B2 (en) * 2012-12-27 2017-11-07 Comcast Cable Communications, Llc Information stream management
GB2556612B (en) * 2016-04-18 2022-03-09 Grass Valley Ltd Monitoring audio-visual content with captions
GB2557194A (en) * 2016-11-29 2018-06-20 Sony Corp A decoder, encoder, computer program and method

Family Cites Families (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US540460A (en) * 1895-06-04 Piston for air-engines
EP0576749B1 (en) 1992-06-30 1999-06-02 Discovision Associates Data pipeline system
GB9405914D0 (en) 1994-03-24 1994-05-11 Discovision Ass Video decompression
DE1073767B (de) * 1958-02-27 1960-01-21 Fa. Carl Zeiss, Heidenheim/Brenz Unsymmetrisches photographisches Objektiv
US4918624A (en) * 1988-02-05 1990-04-17 The United States Of America As Represented By The United States Department Of Energy Vector generator scan converter
JPH05502539A (ja) 1990-09-19 1993-04-28 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 主データファイル及び制御ファイルが記録された記録担体、その記録方法及び装置、及びその読取装置
US6034674A (en) 1992-06-30 2000-03-07 Discovision Associates Buffer manager
US6047112A (en) 1992-06-30 2000-04-04 Discovision Associates Technique for initiating processing of a data stream of encoded video information
US6263422B1 (en) 1992-06-30 2001-07-17 Discovision Associates Pipeline processing machine with interactive stages operable in response to tokens and system and methods relating thereto
US6112017A (en) 1992-06-30 2000-08-29 Discovision Associates Pipeline processing machine having a plurality of reconfigurable processing stages interconnected by a two-wire interface bus
US5784631A (en) 1992-06-30 1998-07-21 Discovision Associates Huffman decoder
US7095783B1 (en) 1992-06-30 2006-08-22 Discovision Associates Multistandard video decoder and decompression system for processing encoded bit streams including start codes and methods relating thereto
US6330665B1 (en) 1992-06-30 2001-12-11 Discovision Associates Video parser
US6079009A (en) 1992-06-30 2000-06-20 Discovision Associates Coding standard token in a system compromising a plurality of pipeline stages
US5809270A (en) 1992-06-30 1998-09-15 Discovision Associates Inverse quantizer
US6067417A (en) 1992-06-30 2000-05-23 Discovision Associates Picture start token
US5768561A (en) 1992-06-30 1998-06-16 Discovision Associates Tokens-based adaptive video processing arrangement
US6417859B1 (en) 1992-06-30 2002-07-09 Discovision Associates Method and apparatus for displaying video data
JPH06121263A (ja) 1992-10-08 1994-04-28 Sony Corp 映像信号の記録方法
JPH06275054A (ja) * 1993-03-24 1994-09-30 Kyocera Corp Cd−gのグラフィックデータ再生処理方法
DE69407471T2 (de) 1993-04-19 1998-06-18 Koninkl Philips Electronics Nv BiCMOS Gegentaktleistungstreiber mit geringer Phasenverschiebung
US5699544A (en) 1993-06-24 1997-12-16 Discovision Associates Method and apparatus for using a fixed width word for addressing variable width data
US5829007A (en) 1993-06-24 1998-10-27 Discovision Associates Technique for implementing a swing buffer in a memory array
US5805914A (en) 1993-06-24 1998-09-08 Discovision Associates Data pipeline system and data encoding method
US5861894A (en) 1993-06-24 1999-01-19 Discovision Associates Buffer manager
ATE179293T1 (de) 1993-08-20 1999-05-15 Thomson Consumer Electronics Fernsehbildunterschrift-system fur anwendung mit komprimierter numerischer fernseh-ubertragung
CA2145365C (en) 1994-03-24 1999-04-27 Anthony M. Jones Method for accessing banks of dram
CA2145379C (en) 1994-03-24 1999-06-08 William P. Robbins Method and apparatus for addressing memory
CA2145361C (en) 1994-03-24 1999-09-07 Martin William Sotheran Buffer manager
JP2931755B2 (ja) 1994-04-14 1999-08-09 株式会社東芝 データ再生装置、データエンコード装置、データエンコード方法及びデータ再生システム
US5771075A (en) * 1994-12-08 1998-06-23 Lg Electronics Inc. Audio/video synchronizer
US5930450A (en) * 1995-02-28 1999-07-27 Kabushiki Kaisha Toshiba Recording medium, apparatus and method of recording data on the same, and apparatus and method of reproducing data from the recording medium
CA2173812C (en) * 1995-04-11 2000-02-08 Shinichi Kikuchi Recording medium, recording apparatus and recording method for recording data into recording medium, and reproducing apparatus and reproduction method for reproducing data from recording medium
US6119213A (en) 1995-06-07 2000-09-12 Discovision Associates Method for addressing data having variable data width using a fixed number of bits for address and width defining fields
TW293981B (ja) * 1995-07-21 1996-12-21 Philips Electronics Nv
US20020044757A1 (en) * 1995-08-04 2002-04-18 Sony Corporation Information carrier, device for reading and device for providing the information carrier and method of transmitting picture information
JP3356768B2 (ja) * 1995-08-21 2002-12-16 松下電器産業株式会社 記録方法、再生装置
EP0788094A4 (en) * 1995-08-21 1998-06-24 Matsushita Electric Ind Co Ltd MULTIMEDIA OPTICAL DISK WHICH CAN COMPLETELY GENERATE UNEXPECTED SCENES THROUGH INTERACTIVE CONTROL, THEIR PLAYBACK DEVICE AND PLAYBACK METHOD
MY115648A (en) 1995-08-23 2003-08-30 Sony Corp Encoding/decoding fields of predetermined field polarity apparatus and method
MX9801212A (es) * 1995-09-29 1998-04-30 Matsushita Electric Ind Co Ltd Metodo y dispositivo para grabar y reproducir una corriente de bits intercalada sobre y desde un medio.
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
US6567612B2 (en) * 1996-04-05 2003-05-20 Pioneer Electronic Corporation Information record medium, apparatus for recording the same and apparatus for reproducing the same
JPH09282848A (ja) * 1996-04-05 1997-10-31 Pioneer Electron Corp 情報記録媒体並びにその記録装置及び再生装置
WO1998021722A1 (fr) * 1996-11-13 1998-05-22 Matsushita Electric Industrial Co., Ltd. Appareil et procede de generation de train de bits pour memoire a disque d'enregistrement de donnees permettant une reproduction continue de plusieurs pieces de donnees-images et support d'enregistrement sur lequel est enregistre un programme applique a l'appareil de generation
JP4416846B2 (ja) * 1997-08-22 2010-02-17 ソニー株式会社 メニュー制御用データを記録したコンピュータ読み取り可能な記録媒体ならびにメニュー制御方法および装置
US5929857A (en) * 1997-09-10 1999-07-27 Oak Technology, Inc. Method and apparatus for dynamically constructing a graphic user interface from a DVD data stream
JP3185863B2 (ja) * 1997-09-22 2001-07-11 日本電気株式会社 データ多重化方法および装置
KR100526218B1 (ko) 1997-12-15 2005-11-04 마츠시타 덴끼 산교 가부시키가이샤 광디스크, 기록장치, 기록 프로그램을 저장하는 컴퓨터 판독가능 저장매체 및 기록방법
JP3407287B2 (ja) 1997-12-22 2003-05-19 日本電気株式会社 符号化復号システム
EP0940986B1 (en) * 1998-03-02 2011-02-16 Panasonic Corporation Method and system downloading a desired portion of a continuous medium with a raised precision
IL132964A (en) * 1998-03-19 2004-08-31 Koninkl Philips Electronics Nv A transmitter that transmits a digital information signal alternately in an encrypted and unencrypted manner
JP2000100073A (ja) * 1998-09-28 2000-04-07 Sony Corp 記録装置および方法、再生装置および方法、記録媒体、並びに提供媒体
CN1897146A (zh) 1998-10-12 2007-01-17 松下电器产业株式会社 信息记录介质及用于记录或再现数据的装置和方法
JP2000152179A (ja) * 1998-11-17 2000-05-30 Pioneer Electronic Corp 映像データ再生方法、映像データ再生装置、映像データ記録方法及び映像データ記録装置
ID24586A (id) 1998-12-21 2000-07-27 Matsushita Electric Ind Co Ltd Perangkat dan metode penyelarasan waktu dengan menggunakan modul basis waktu dan resolusi peningkatan waktu
WO2000042773A1 (en) 1999-01-19 2000-07-20 Sony Electronics Inc. System and method for implementing interactive video
JP3805985B2 (ja) * 1999-02-18 2006-08-09 株式会社東芝 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
EP1035735A3 (en) * 1999-03-12 2007-09-05 Kabushiki Kaisha Toshiba Moving image coding and decoding apparatus optimised for the application of the Real Time Protocol (RTP)
US7099561B1 (en) * 1999-08-20 2006-08-29 Thomson Licensing User interface and processing system for digital video, audio and ancillary data
US8024767B1 (en) * 1999-09-14 2011-09-20 Ati Technologies Ulc Method and apparatus for receiving digital video signals
NZ518774A (en) * 1999-10-22 2004-09-24 Activesky Inc An object oriented video system
GB0007870D0 (en) * 2000-03-31 2000-05-17 Koninkl Philips Electronics Nv Methods and apparatus for making and replauing digital video recordings, and recordings made by such methods
KR100364733B1 (ko) * 2000-07-18 2002-12-16 엘지전자 주식회사 디지털 티브이의 아날로그/디지털 오에스디 제어장치
DK2172938T3 (da) * 2001-03-08 2013-07-22 Sony Corp Anordning og fremgangsmåde til gengivelse af data
JP3656248B2 (ja) 2001-10-09 2005-06-08 ソニー株式会社 ビデオ信号記録装置および方法、ビデオ信号再生装置および方法、記録媒体、プログラム、並びにデータ構造
TW200300928A (en) 2001-11-30 2003-06-16 Sony Corportion Information processing method and apparatus, program storage medium, program and information recording medium
JP3878650B2 (ja) 2003-02-28 2007-02-07 松下電器産業株式会社 記録媒体、再生装置、記録方法、プログラム、再生方法。
KR20050004339A (ko) 2003-07-02 2005-01-12 엘지전자 주식회사 고밀도 광디스크의 그래픽 데이터 관리방법 및 그에 따른고밀도 광디스크

Also Published As

Publication number Publication date
KR20100134799A (ko) 2010-12-23
CN101790066B (zh) 2012-07-04
TW201203228A (en) 2012-01-16
RU2008108075A (ru) 2009-09-10
CN101729915A (zh) 2010-06-09
US20090214175A1 (en) 2009-08-27
EP2259583A1 (en) 2010-12-08
EP2259582A1 (en) 2010-12-08
CN101790066A (zh) 2010-07-28
AU2004300623C1 (en) 2010-04-29
EP2259583B1 (en) 2012-05-30
US8369690B2 (en) 2013-02-05
JP2007097197A (ja) 2007-04-12
EP1814327B1 (en) 2008-05-21
CN101729914B (zh) 2013-05-08
PL1940166T3 (pl) 2011-05-31
US8280230B2 (en) 2012-10-02
TW200509082A (en) 2005-03-01
PL2088779T3 (pl) 2011-06-30
EP1645122A1 (en) 2006-04-12
TWI359408B (en) 2012-03-01
EP1940166B1 (en) 2010-12-29
CN101740076A (zh) 2010-06-16
JP2009099256A (ja) 2009-05-07
EP2259582B1 (en) 2012-05-30
JP4990932B2 (ja) 2012-08-01
JP4774431B2 (ja) 2011-09-14
ATE396587T1 (de) 2008-06-15
EP1940166A1 (en) 2008-07-02
AU2004300623B2 (en) 2009-10-01
EP1814327A1 (en) 2007-08-01
ATE493844T1 (de) 2011-01-15
EP1645122B1 (en) 2007-09-12
JP2009100479A (ja) 2009-05-07
JP3993626B2 (ja) 2007-10-17
EP2088779A1 (en) 2009-08-12
DE602004030960D1 (de) 2011-02-17
ES2356582T3 (es) 2011-04-11
JP4287500B2 (ja) 2009-07-01
CA2528585C (en) 2013-03-12
DE602004030836D1 (de) 2011-02-10
CN100579194C (zh) 2010-01-06
JP4048220B2 (ja) 2008-02-20
CA2528585A1 (en) 2005-01-13
US8682146B2 (en) 2014-03-25
JP4283860B2 (ja) 2009-06-24
WO2005004478A1 (en) 2005-01-13
US20060153532A1 (en) 2006-07-13
JP2007521737A (ja) 2007-08-02
CN101740077A (zh) 2010-06-16
ATE494731T1 (de) 2011-01-15
DE602004014042D1 (de) 2008-07-03
RU2477574C2 (ru) 2013-03-10
DE602004008922T2 (de) 2008-01-17
CN1817034A (zh) 2006-08-09
RU2329611C2 (ru) 2008-07-20
TWI460720B (zh) 2014-11-11
US20090220211A1 (en) 2009-09-03
PT2088779E (pt) 2011-03-07
CN101729915B (zh) 2013-09-25
JP2009268114A (ja) 2009-11-12
CN101740076B (zh) 2013-03-06
DE602004008922D1 (de) 2007-10-25
AU2009243537B2 (en) 2011-09-29
PT1940166E (pt) 2011-02-07
EP2088779B1 (en) 2011-01-05
ZA200509946B (en) 2007-05-30
JP2009268112A (ja) 2009-11-12
ES2356590T3 (es) 2011-04-11
KR101036991B1 (ko) 2011-05-25
JP2007282260A (ja) 2007-10-25
AU2009243537A1 (en) 2009-12-24
RU2006103074A (ru) 2006-06-10
JP5059805B2 (ja) 2012-10-31
ATE373387T1 (de) 2007-09-15
KR20060027367A (ko) 2006-03-27
AU2004300623A1 (en) 2005-01-13
JP2007267408A (ja) 2007-10-11
KR101051821B1 (ko) 2011-07-25
CN101740077B (zh) 2015-06-17
CN101729914A (zh) 2010-06-09

Similar Documents

Publication Publication Date Title
JP4022567B2 (ja) 再生装置,集積回路,プログラム,再生方法
JP4245652B2 (ja) 再生装置、記録方法、再生方法
JP4027401B2 (ja) 記録方法
JP4351228B2 (ja) システムlsi

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070724

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070810

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20071001

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

Free format text: PAYMENT UNTIL: 20101005

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4022567

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

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20121005

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20131005

Year of fee payment: 6