JP6964436B2 - 映像記録装置及び映像再生装置 - Google Patents

Description

本発明は映像記録再生装置に関する。

近年、映像圧縮技術または放送波の変調技術の進歩に伴い、各国で新しいテレビ放送方式の導入が検討されている。新しい方式によって、伝送効率が向上する。このため、これまでと同じ電波帯域を用いて、より高品質な映像を放送することが可能になる。また、これまでと同じ品質の映像を、より狭い電波帯域で放送することも可能である。新しい方式の導入に伴い、ネットワークとの連携が検討されている。また、受信機に蓄積されて動作するアプリケーションまたはコンテンツなども検討されている。

テレビ放送を録画する方式は、通常のテレビ放送方式と密接に関係している。新しいテレビ放送方式が採用された場合には、新しいテレビ放送方式の番組を、そのまま録画することはできない。そのため、テレビ放送方式が変更される際には、録画方式も新しい放送方式に対応した方式に変更する必要がある。

特に、可換型記録メディアを使用する場合には，他の再生装置との互換性も含めて考慮する必要がある。可換型記録メディアは、例えば、ＤＶＤ（登録商標：Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）またはブルーレイディスク（登録商標：ＢＬＵ−ＲＡＹ ＤＩＳＣ）などである。

現在採用されている録画方式では、新しいテレビ放送方式をそのまま記録することは困難である。このため、新しいテレビ放送方式に対応した録画方式が必要となっている。

例えば、特許文献１には、ＢＤＡＶ方式を用いたテレビ放送の記録方式、大容量になる記録データを分割記録する方法および大容量になる記録データにアクセスする方法が記載されている。また、圧縮された映像データと音声データとを、ＭＰＥＧ２ＴＳに格納して記録する方法が記載されている。また、ＭＰＥＧ２ＴＳで送信されたテレビ放送を受信して、ＭＰＥＧ２ＴＳの形式で記録する方法が記載されている。

ＷＯ２００６／０３０７６７（００２１段〜０１０５段、図１〜図２１）

しかしながら、特許文献１に記載された記録方式では、ＭＰＥＧ２ＴＳ形式のコンテナフォーマットのみに対応しており、新しいテレビ放送方式で採用予定であるＭＭＴ形式の放送を記録することが出来ない。

本発明は、これらの問題を鑑みて、ＭＭＴ形式の放送を記録する方法を提供するものである。

本発明に係る映像記録再生装置は、放送波を受け取るチューナー・復調部と、前記放送波の多重化ストリームの多重化を解除する多重化解除部と、前記多重化ストリームの多重化が解除された圧縮データを伸長するデコード部と、前記デコード部で伸長されたデータから記録するための映像データまたは制御情報を収集する記録再生制御部とを備え、ＭＭＴ形式を用いた前記放送波に含まれた映像データを記録する際に、パケットデータを結合した映像データとして記録することを特徴とする。

この発明に係る映像記録装置は、コンテナフォーマットにおける多重化方式としてＭＭＴが用いられた多重化データストリームであって、少なくとも映像データを含むアセットデータのストリームと、制御情報である少なくとも１つのＭＰＴデータとを含む多重化データストリームに含まれる各種データを、ランダムアクセス可能に記録する映像記録装置であって、前記多重化データストリームに含まれる各種データであって、前記アセットデータと、前記ＭＰＴデータとを含む各種データをひとまとまりのストリームデータとして記録するとともに、前記映像データの第１の映像時刻と、前記第１の映像時刻に対応する、記録先の前記ストリームデータ内の前記ＭＰＴデータの位置とを対応付けて記録することを特徴とする。

実施の形態１に係る映像記録再生装置１００の構成図である。 多重化解除手順を説明する図である。 データの論理構造を示した図である。 ＴＬＶパケットを結合して記録した場合の模式図である。 パケットの選択と時間の同期とを説明する概念図である。 ＭＭＴＰ方式でのＭＰＵタイムスタンプ記述子を用いた同期方式を説明する図である。 タイムテーブルを作成する手順を示すフローチャートである。 フレーム単位の時刻で検索できるタイムテーブルを示す図である。 ＭＭＴＰ方式でのＭＰＵタイムスタンプ記述子を用いた同期方式を説明する図である。 ＢＭＦＦとしてストリームデータを記録した場合の説明図である。 実施の形態２に係るＭＭＴＰ方式でのＭＰＴによる多重化解除の説明図である。 タイムテーブルと映像データの関係の説明図である。 ＭＭＴＰ方式でのＭＰＴデータ構造の例である。 映像を中心に考えた場合のアライメントの説明図である。 実施の形態３に係る映像ストリームの模式図である。 画像の分割を示した図である。 画像の分割を示した図である。 分割スライスセグメントに対応したタイムテーブルの図である。 タイムテーブルの各項目とデータ上との対応を示す図である。 早送り再生の説明図である。 変形例１に係る早送り再生の説明図である。 画像の更新の順番の説明図である。 画像の更新の順番の説明図である。 変形例２に係るタイムテーブルの図である。 早送り再生の説明図である。

テレビ放送の楽しみ方の１つとして、テレビ放送の番組を録画（記録）して、後日、再生して視聴することは、従来から行われてきた。録画の楽しみ方は、大きく分けて２種類ある。１つは、「タイムシフト」と呼ばれるものである。タイムシフトは、放送が行われている時間に番組を視聴することができない場合に、番組を録画しておき、後で番組を再生するものである。他は、「アーカイブ」と呼ばれるものである。アーカイブは、番組を録画して、保管しておくものである。そのため、録画した番組を、いつでも見ることができる。

タイムシフトを利用する場合には、番組を録画した後に、短期間で利用が終了する事が多い。一方、アーカイブを利用する場合には、番組を録画した後に、長期間保存して利用されることが多い。

テレビ放送以外にも、利用者自身が撮影した映像を記録することも行われている。家庭用ビデオカメラなどで撮影された映像データを、光ディスク又はハードディスク等に記録して保管する。

最近では、ネットワークなどで収集した映像を記録することもある。また、家庭での録画以外にも、美術館、博物館またはデジタル・サイネージにおいても、録画された映像が使用されている。「デジタル・サイネージ」とは、表示と通信とにデジタル技術を活用して、平面ディスプレイ又はプロジェクタなどによって、映像または情報を表示する広告媒体である。

映画などの市販コンテンツとしては、コンテンツを記録した読み出し専用のＤＶＤまたはブルーレイディスクなどがある。最近では、パッケージ入りの光ディスクの他に、ネットワーク経由でダウンロードを行うコンテンツのサービスも増えている。

放送されたコンテンツを記録するフォーマットと、市販されているコンテンツの記録フォーマットとは、異なることがある。たとえば、ブルーレイディスクの場合には、２種類のフォーマットを規定している。第１に、ＢＤＡＶは、放送されたコンテンツの記録用フォーマットである。ＢＤＡＶは、放送波をそのまま記録することができる。第２に、ＢＤＭＶは、市販されているコンテンツ向けのフォーマットである。ＢＤＭＶは、高度な再生制御機能を持っている。また、ＡＶＣＨＤは、カメラ等で用いられるＨＤＤまたはメモリーカードなどに映像を記録する場合に用いられている。ＡＶＣＨＤは、ＢＤＭＶを基にして変更が加えられている。

テレビ放送では、従来方式の４倍の解像度を持つ４Ｋ映像に対応したウルトラハイビジョン方式の導入が予定されている。また、さらに高品質な８Ｋ映像の放送も検討されている。同様に、北米地域または欧州地域でも、それぞれ現在の放送方式を拡張する形で、新しいテレビ放送方式の導入が検討されている。

地域ごとに差異はあるが、従来のテレビ放送方式は、映像圧縮方式としてＭＰＥＧ２またはＡＶＣ（ｈ．２６４）を採用している。また、従来のテレビ放送方式は、多重化方式としてＭＰＥＧ２ＴＳを採用していた。ＭＰＥＧ２ＴＳは、放送という単一の伝送路を前提としており、映像または音声などを放送局が１つにまとめて送る形となっている。ＭＰＥＧ２ＴＳでは伝送単位として同期マーク付きの固定長パケット方式が採用されている。そのため、録画方式でもＭＰＥＧ２ＴＳを記録する方式が採用されることが多い。

一方、新しいテレビ放送方式では、映像圧縮方式としてＭＰＥＧ２、ＡＶＣまたはＨＥＶＣ（ｈ．２６５）を取り入れる規格が多い。ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）は、同一の画質で比べた場合には、圧縮効率がＭＰＥＧ２の４倍であり、ＡＶＣの２倍である。ＨＥＶＣは、高画質化または狭帯域化を目指す新しいテレビ放送方式に必要な圧縮技術である。

また、新しいテレビ放送方式では、ネットワーク技術との整合性を重視している。そのため、新しいテレビ放送方式では、多重化方式として、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）の採用が検討されている。ＭＭＴは、複数の伝送路で情報を提供できる方式で、映像または音声などを別々に伝送し、受信機がそれらを選択して受信できる。また、ＭＭＴは、可変長パケットを採用している。また、受信状況に応じて、再生する映像ストリームを変更する方式も検討されている。

上述のように、現在採用されている録画方式では、新しいテレビ放送方式をそのまま記録することは困難である。このため、新しいテレビ放送方式に対応した録画方式が必要となっている。

ここで、新しく記録方式を作る場合には、いくつかのアプローチが考えられる。

第１に、新しい放送方式を完全に従来方式の映像に変換して記録する方法である。この場合には、記録方式の変更は必要なく、従来の再生装置との互換もとれる。しかし、高画質などの新しい方式のメリットを受けることはできない。

第２に、従来の録画方式をできるだけ踏襲して、テレビ放送の情報の中心となる映像と音声とを新しい方式に変換して記録する方法である。この場合には、映像と音声とに関しては、新しい方式のメリットを受けることができる。しかし、字幕またはデータ放送などを楽しむことはできない。

第３に、新しい放送方式の番組データをそのまま記録する方式である。ネットワークサービスなど外部に依存する部分を除けば、新しい方式のメリットの多くを利用することができる。

実施の形態１．
図１は、実施の形態１に係る映像記録再生装置１００の構成図である。

録画再生装置１００は、チューナー・復調部１１と多重化解除部２１および記録再生制御部４１を備えている。なお、以下の実施の形態では、録画再生装置として説明するが、再生部分を含まない録画装置とすることができる。

録画再生装置１００は、映像デコード部３２、音声デコード部３１、字幕デコード・レンダリング部３３またはデータ放送・ＥＰＧ処理部３４を備える。なお、デコード部は、映像デコード部３２、音声デコード部３１、字幕デコード・レンダリング部３３またはデータ放送・ＥＰＧ処理部３４を含む。

また、録画再生装置１００は、内蔵記録装置５１または光ディスクドライブ５２を備えることができる。

また、録画再生装置１００は、外部入力部１２またはネットワーク部１３を備えることができる。外部入力部１２およびネットワーク部１３は、外部からの信号入力を受け取る機能を有している。また、チューナー・復調部１１も、外部からの信号入力を受け取る機能を有している。

＜録画再生装置１００の構成＞
チューナー・復調部１１は、放送波Ｂａを受け取る。そして、チューナー・復調部１１は、受け取った放送波Ｂａを復調する。外部入力部１２は、外部の装置Ｅｉからデータを受け取る。外部の装置は、例えば、ビデオカメラなどの録画装置である。なお、「データ」は、映像データ、音声データ、字幕データ、データ放送のデータまたは制御情報などを含む。

ネットワーク部１３は、ネットワークＮｅからデータを受け取る。ネットワークＮｅは、例えば、複数のコンピュータまたは電子機器などを繋いで、信号、データまたは情報をやりとりすることができるコンピュータネットワークまたは通信ネットワークである。

多重化解除部２１は、多重化ストリームＳｍの多重化を解除する。つまり、多重化解除部２１は、多重化ストリームＳｍから、各種のデータを分けて取り出す。

音声デコード部３１は、圧縮された音声データを伸長する。音声デコード部３１は、エレメンタリーストリームＳｅに含まれる圧縮された音声データを伸長する。

映像デコード部３２は、圧縮された映像データを伸長する。映像デコード部３２は、エレメンタリーストリームＳｅに含まれる圧縮された映像データを伸長する。

字幕デコード・レンダリング部３３は、圧縮された字幕データを伸長する。字幕デコード・レンダリング部３３は、エレメンタリーストリームＳｅに含まれる圧縮された字幕データを伸長する。

データ放送・ＥＰＧ処理部３４は、圧縮されたデータ放送のデータを伸長する。データ放送・ＥＰＧ処理部３４は、エレメンタリーストリームＳｅに含まれる圧縮されたデータ放送のデータを伸長する。

記録再生制御部４１は、記録用の映像データ、音声データまたは制御情報などを収集する。記録再生制御部４１は、収集したデータを記録用のデータフォーマットに変換する。

内蔵記録装置５１は、録画再生装置１００に備えられた記録装置である。内蔵記録装置５１は、例えば、ハードディスクドライブ、揮発性メモリまたは不揮発性メモリ等である。

光ディスクドライブ５２は、光ディスク５３にデータを記録する。また、光ディスクドライブ５２は、光ディスク５３からデータを読み出す。光ディスク５３は、例えば、ブルーレイディスクまたはＤＶＤなどである。

＜データを記録しない場合のデータ処理の流れ＞
まず、放送番組を記録せずに、テレビに表示する場合の流れを説明する。つまり、放送波を一例として、放送波の受信から映像および音声の出力までについて説明する。テレビは、図１では、表示装置Ｄｄおよび音響装置Ｅｓである。

外部からの入力信号としては、アンテナで受信された放送波Ｂａ、ビデオカメラ（外部装置Ｅｉ）などからの映像信号、映像再生装置等からの映像信号またはネットワークＮｅからの映像データ等がある。利用者は、リモコン（リモート・コントローラー）または操作ボタンなどを用いて、入力部を選択する。入力部は、チューナー・復調部１１、外部入力部１２またはネットワーク部１３等である。リモコンは、利用者が操作する遠隔操作機器のことである。

また、放送波Ｂａの場合には、放送局または番組などが設定される。また、ネットワークＮｅの場合には、データ取得先またはデータへのアクセス情報などが設定される。なお、利用者の視聴したい映像サービスまたは利用者の記録したい映像サービスは、特定されているものとする。また、利用者の視聴したい映像サービスまたは利用者の記録したい映像サービスは、受信できる状態になっているものとする。

アンテナ等で受信した放送波Ｂａは、チューナー・復調部１１に入力される。チューナー・復調部１１は、放送波Ｂａの中から指定された放送局の電波を取り出す。そして、チューナー・復調部１１は、規定された復調方式で、放送波Ｂａを復調する。そして、チューナー・復調部１１は、放送波Ｂａからデジタルデータを取り出す。

ここで、取り出されたデジタルデータは、映像データ、音声データ、字幕データまたは制御情報などを多重化した多重化ストリームＳｍである。また、複数の番組を、まとめて１つの多重化ストリームＳｍに格納することもある。

なお、「ストリーム」とは、時間の流れを持ったデータまたは時間的な流れを持った形で伝送されるデータを表わす。例えば、ストリームは、映像データの場合は、映像ストリームであり、音声データの場合は、音声ストリームである。また、その他には、字幕ストリーム、多重化ストリーム、受信ストリーム、データストリームなどが挙げられる。

多重化ストリームＳｍは、チューナー・復調部１１で取り出される。チューナー・復調部１１で取り出された多重化ストリームＳｍは、多重化解除部２１に送られる。多重化解除部２１は、多重化ストリームＳｍから、各種のデータまたは各種の制御情報などを分けて取り出す。データは、例えば、番組を直接構成するデータである。データは、例えば、映像ストリーム、音声ストリームまたは字幕ストリームなどである。データは、例えば、多重化ストリームＳｍに格納されたデータ放送用のプログラムまたはデータである。

多重化を解除された各種のデータ（エレメンタリーストリームＳｅ）は、圧縮されたデータである。

映像ストリームは、圧縮された映像データである。映像デコード部３２は、圧縮された映像データを伸長する。伸長された映像データは、表示装置Ｄｄなどから映像として出力される。表示装置Ｄｄは、例えば、テレビなどである。

同様に、音声ストリームは、圧縮された音声データである。音声デコード部３１は、圧縮された音声データを伸長する。伸長された音声データは、音響装置Ｅｓから音声として出力される。音響装置Ｅｓは、例えば、テレビなどである。

表示装置Ｄｄまたは音響装置Ｅｓから出力される際に、映像データＤｉ_１と音声データＤｓとは、バッファリングと同期とが行われる（図示せず）。これによって、映像と音声とにずれが生じない。映像データと音声データとの出力のタイミングは、制御情報またはシステムクロック等から指定されたタイミングまたは算出されたタイミングである。

字幕ストリームは、圧縮された字幕データである。字幕デコード・レンダリング部３３は、圧縮された字幕データを伸長する。字幕デコード・レンダリング部３３は、伸長された字幕データを解釈する。字幕デコード・レンダリング部３３は、解釈された字幕データを映像化する。映像化された字幕データは、指定されたタイミングで映像データまたは音声データと合成される。合成された字幕データは、表示装置Ｄｄなどから映像として出力される。

データ放送のストリームは、圧縮されたデータである。データ放送・ＥＰＧ処理部３４は、圧縮されたデータ放送のデータを伸長する。データ放送・ＥＰＧ処理部３４は、指定されたタイミングで、伸長された映像データと伸長された音声データとを合成する。合成された映像データおよび音声データは、テレビなどから映像および音声として出力される。

録画再生装置１００は、このようにして受信した放送波Ｂａを、同期の取れた映像および音声として出力する。

＜データの記録＞
次に、この映像データを記録することを考える。

記録再生制御部４１は、前述の放送波Ｂａの受信から映像の表示までの流れの中で、記録用の映像データ、音声データまたは制御情報などを収集する。収集されたデータは、記録用のデータフォーマットに変換される。記録用のデータフォーマットに変換されたデータは、内蔵記録装置５１または光ディスクドライブ５２を通じて光ディスク５３等に記録される。

記録再生制御部４１が映像データまたは音声データを取り出す位置は、様々な組み合わせが考えられる。しかし、説明を容易にするために、次の（Ａ）から（Ｃ）の３つ経路に単純化して説明する。３つ経路は、（Ａ）多重化ストリームＳｍの状態での取り出し、（Ｂ）多重化が解除されたエレメンタリーストリームＳｅの状態での取り出し及び（Ｃ）映像音声が伸長された状態（映像データＤｉ_１）での取り出しである。

なお、以下においては、（Ａ）と（Ｂ）とに関して説明する。

≪（Ａ−１）多重化ストリームＳｍの状態でのデータの記録（１）≫
多重化ストリームの状態でのデータ取り出しとブルーレイディスク（光ディスク５３）への記録とを考える。データは、図１中の（Ａ）の経路を使って取り出される。

例えば、日本方式の従来の放送方式の場合には、チューナー・復調部１１から取り出される多重化ストリームＳｍは、ＭＰＥＧ２ＴＳの多重化ストリーム内にＭＰＥＧ２形式で圧縮された映像信号が格納された形のデータである。

ＭＰＥＧ２ＴＳの放送用ストリームは、１９２バイトサイズの固定長パケットを採用している。また、このパケットを受信順に結合することによって、記録フォーマット用のデータファイルを作成することができる。このようにして作成されたデータファイルをストリームファイルと呼ぶ。

実際に放送されているストリームには、複数の番組が多重化されている。その中から目的の番組を取り出す過程が必要となる。しかし、ここでは、その説明を省略する。

まず、ブルーレイディスクのＢＤＡＶフォーマットの場合を説明する。

ブルーレイディスクのＢＤＡＶフォーマットの場合には、ストリームファイルの他に、クリップファイル、プレイリストファイルまたはインフォファイルなどが必要である。クリップファイルは、ストリームファイル内のデータにアクセスするための詳細情報を記録したファイルである。プレイリストファイルは、時系列の情報を管理する。時系列の情報は、例えば、一つの番組の開始点、終了点または再生ストリームの切り替えなどの情報である。インフォファイルは、再生可能な番組リストなどディスク全体の情報を管理する。

これらの情報は、ストリーム内の管理情報、利用者の設定した予約情報またはチューナー・復調部１１から得られる管理情報などから作成される。これらに関しては、例えば、特許文献１に詳しく書かれている。

次に、日本の新しい放送方式の場合を説明する。

これは、例えば、放送サービス高度化推進協会の「高度高帯域衛星デジタル放送 運用規定１．１版 ＮＥＸＴＶＦ ＴＲ−００４」（２０１６年３月３０日発行、第一部・第二編・第５章、２−３１〜２−４０ページ、図５−１）に記載されている。

この方式は、４Ｋおよび８Ｋの高解像度映像に対応している。また、この方式は、色域および輝度域拡大に対応している。この方式は、映像圧縮方式として、ＨＥＶＣを採用している。また、この方式は、多重化方式として、ＭＭＴとＴＬＶとを組み合わせて採用している。

ＭＭＴおよびＴＬＶは、ネットワークで用いられているＩＰパケットとの整合性を考えて設計されている。ＴＬＶは、ＩＰパケットの放送波を用いた伝送方式である。ＭＭＴは、ＩＰパケットを用いて映像データを転送する方式およびそのデータ形式を規定している。ＩＰパケットは、可変長パケットを採用している。このため、ＭＭＴおよびＴＬＶも可変長パケットを採用している。

図２を用いてこの方式での多重化解除手順を説明する。図２は、多重化解除手順を説明する図である。

図２において、横方向は、データの受信の順番を示している。つまり、横軸Ｈａ方向には、受信された順番にデータが並べられている。受信した順番に左から右に記載してある。また、縦軸Ｖａ方向は、データの処理の流れを示している。つまり、縦軸Ｖａ方向には、パケット解析によるデータの取り出しの順番が示されている。縦軸Ｖａ_１の範囲では、多重化ストリームＳｍの多重化を解除している。縦軸Ｖａ_２の範囲では、エレメンタリーストリームＳｅの多重化を解除している。

ＴＬＶパケットのデータは、放送波Ｂａの復調によって得られる。ＴＬＶパケットは、放送に関する情報を含んでいる。放送に関する情報は、例えば、放送の識別子、チャンネル、放送局名、ＩＰアドレス、ポート番号または使用する電波の情報などである。「使用する電波」とは、地上波、ＢＳ放送またはＣＳ放送などである。「使用する電波の情報」とは、放送の形態、変調方式、周波数、偏向方向または旋回方向などである。

ペイロードは、データ伝送におけるデータ部分を指す。つまり、ペイロードは、伝送されるデータ全体のうち、伝送処理のための管理情報を除いたものにあたる。管理情報は、例えば、ヘッダまたはメタデータなどである。

また、ＴＬＶ（Ｔｙｐｅ−Ｌｅｎｇｔｈ−Ｖａｌｕｅ）は、情報の種類、長さおよび値をまとめて表現するフォーマットである。ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）は、ＩＰの上位プロトコルのトランスポート層で動作するプロトコルである。ＵＤＰは、ネットワーク層のＩＰとセッション層以上のプロトコルの橋渡しをするかたちで動作する。ＭＭＴＰ（登録商標）は、マルチメディア多重化伝送プロトコルである。

チューナー・復調部１１は、放送局の情報、ＩＰアドレスの情報またはポート番号の情報をＴＬＶパケットから取り出す。チューナー・復調部１１は、ＩＰアドレスの情報を用いて、必要なＩＰパケットを取り出す。次に、チューナー・復調部１１は、ポート番号の情報を用いてＵＤＰパケットを取り出す。

この時点で、チューナー・復調部１１は、放送局から送られてきた放送波Ｂａの多重化を解除している。そして、チューナー・復調部１１は、ＵＤＰパケットのデータを取り出している。チューナー・復調部１１は、ＵＤＰパケットからＵＤＰヘッダを取り除く。そして、チューナー・復調部１１は、ＵＤＰパケットからＵＤＰペイロードを取り出す。これによって、チューナー・復調部１１は、ＵＤＰパケットからＭＭＴＰパケットを取り出すことができる。

日本の新しい放送規格では、１つのＭＭＴＰパケットは、１つのＵＤＰ／ＩＰパケットに格納されている。さらに、１つのＵＤＰ／ＩＰパケットは、１つのＴＬＶパケットに格納されている。そのため、制御用データを分離した後のＭＭＴＰを伝送しているパケットでは、ＭＭＴＰパケットは、ＴＬＶパケットから単純にＴＬＶヘッダ、ＩＰヘッダおよびＵＤＰヘッダを取り除くことによって取り出される。

ＭＭＴＰパケットとして取り出された時点で、放送局から送られてきた放送波Ｂａの多重化は解除されている。しかし、放送波Ｂａは、複数の番組をまとめた一連のＭＭＴＰパケットとして多重化されていることもある。その場合には、目的の番組だけを取り出すために、まず、制御情報を取り出して、その制御情報の記載に従って、ＭＭＴＰパケットを選択して取り出す。

ＭＭＴＰパケットとして送られてくる制御信号の１つにＰＬＴ（Ｐａｃｋａｇｅ Ｌｉｓｔ Ｔａｂｌｅ）がある。全ての情報が放送波で送信されてくる場合には、ＰＬＴの中の「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」によって指定された「ｐａｃｋｅｔ＿ｉｄ」を参照する。この「ｐａｃｋｅｔ＿ｉｄ」を用いて、ＭＭＴＰパケットをフィルタリングする。これによって、目的とする番組の管理情報を含むＭＭＴＰパケットを選択することができる。「目的とする番組」とは、視聴する予定の番組である。

ネットワークから番組の管理情報を取得する場合には、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」に記載されているＩＰアドレスおよびポート番号が指定される。または、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」によって、ＵＲＬによる番組の取得先が指定される。

次に、選択されたＭＭＴＰパケットからＭＰＴ（ＭＭＴ＿Ｐａｃｋａｇｅ＿Ｔａｂｌｅ）を含むデータを取り出す。ＭＰＴには、目的とする番組を構成する映像、音声または字幕などのアセットの組合せと取得先とが記述されている。それぞれのアセットの取得先は、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」によって、「ｐａｃｋｅｔ＿ｉｄ」またはネットワーク情報で示されている。ここで、ネットワーク情報は、ＩＰアドレス、ポート番号またはＵＲＬである。

このようにして、ＰＬＴで示された制御データと、ＭＰＴで示された番組を構成するアセットとを、例えば、「ｐａｃｋｅｔ＿ｉｄ」でフィルタリングする。これよって、目的とする番組のＭＭＴＰパケットを取り出すことができる。

ＴＬＶパケットからＭＭＴＰパケットまたはＭＭＴＰペイロードを取りだす過程で、１つのパケットに着目する。パケットヘッダは、取り除かれる。しかし、パケット内のデータは変化しない。ところが、実際には、制御情報と各段階でのパケットヘッダの内容とから、パケットの取捨選択と分類とが行われている。

［標準フォーマットを用いないで記録する場合］
番組を記録する方法の１つとして、例えば、受信した放送のパケットを、そのまま記録する方法を説明する。

図４は、ＴＬＶパケットを結合して記録した場合の模式図である。

図４に示す例では、ＴＬＶパケットの時点で、放送局から送られてきた多重化ストリームＳｍの多重化を解除している。番組のＴＬＶパケットは、そのまま結合されている。結合されたＴＬＶパケットは、ファイルを構成している。

図４中に、ＴＬＶパケットＴＰ−０，ＴＰ−１，ＴＰ−２，ＴＰ−３を示している。「−０」などは、ＴＬＶパケットＴＰの受信の順番を表わしている。例えば、ＴＬＶパケットＴＰ−０は、最初に受信したＴＬＶパケットＴＰである。横軸Ｈａは、受信の順番を表わしている。

最初に受信したＴＬＶパケットＴＰ−０の後ろには、ＴＬＶパケットＴＰ−０の後に受信したＴＬＶパケットＴＰ−１，ＴＰ−２，ＴＰ−３が結合している。そして、結合されたＴＬＶパケットＴＰ−０，ＴＰ−１，ＴＰ−２，ＴＰ−３は記録される。ＴＬＶパケットＴＰは、可変長パケットを採用している。

データをパケット単位で受信するため、受信時点で、パケットの先頭は明確である。しかし、他のパケットと結合して、１つのファイルを作成した場合には、それぞれのパケットの先頭位置を判別する必要がある。

第１の方法は、記録する時点で、パケットの先頭位置のリストを、管理用ファイルＡｆとして作成する方法である。

これは、パケットを記録する時点では、パケットのファイル内での先頭位置が判明するためである。この場合には、パケット番号などと関連付けてパケットの先頭位置のリストを作成しても良い。

第２の方法は、ファイルの先頭からデータを読み込み、先頭のデータＨｍがあった場合には、ＴＬＶパケットＴＰの先頭と判断する。そして、ＴＬＶパケットＴＰが結合したデータを読み込む。

ＴＬＶパケットＴＰには、パケットの先頭を識別するために、最初の１バイトには、固定値「０ｘ７Ｆ」が格納されている。そして、先頭バイトの後ろには、パケット種別を表す１バイトのデータが格納されている。そして、その後ろには、データ長を示す２バイトのデータが格納されている。

ここで、ＴＬＶパケットＴＰの先頭のデータＨｍは、固定値「０ｘ７Ｆ」である。

固定値「０ｘ７Ｆ」（先頭のデータＨｍ）が読み込まれれば、直前に読み込まれたデータを、ＴＬＶパケットＴＰとして解釈して処理を行う。

固定値「０ｘ７Ｆ」は、特別な値ではない。固定値「０ｘ７Ｆ」は、データ中にも存在している。そのため、間違った位置から読み込む可能性がある。この場合でも、ＴＬＶパケットＴＰのデータとしての矛盾の有無を確認する。または、データ長のデータを読み込んだ後に、次のデータの先頭が毎回固定値「０ｘ７Ｆ」になっているか否かを確認する。これらによって、正しいデータの区切りで、パケットを読み込むことができる。

この例では、ＴＬＶパケットを記録する方法を示した。しかし、他にも、ＵＤＰ／ＩＰパケットを記録する方法も採用できる。また、ＭＭＴＰパケットを、そのまま記録する方法なども採用できる。

しかし、ＴＬＶパケットを選んだ理由は、ＴＬＶパケットの先頭に識別用の固定バイトが用意されていて、パケットの識別が比較的に容易だからである。

他のパケットを記録する方法では、識別のためのマークが挿入されていない場合がある。そこで、識別子を独自に挿入する手法も採用できる。また、ＵＤＰ／ＩＰパケットの場合には、例えば、ＩＰアドレス情報を用いて識別のためのマークとする方法も採用できる。ＩＰアドレス情報は、同じ番組中では変化しない。

≪（Ａ−２）多重化ストリームＳｍの状態でのデータの記録（２）≫
ＭＰＴは、ＭＭＴＰパケットに格納されて伝送される。ＭＰＴは、制御情報を含んでいる。多重化解除部２１は、ＭＰＴに記載された情報に基づいて、パケットを振り分ける。ＭＰＴに記載された情報は、例えば、ＭＭＴＰヘッダに含まれるパケットＩＤ情報である。これによって、多重化解除部２１は、映像情報または音声情報などを個別に取り出すことができる。そして、多重化解除部２１は、多重化ストリームＳｍの多重化を解除することができる。

ＭＦＵは、ＭＭＴＰパケットに格納されている。複数のＭＦＵが１つのＭＭＴＰパケットに格納されている場合がある。また、１つのＭＦＵが１つのＭＭＴＰパケットに格納されている場合がある。そして、１つのＭＦＵが複数のＭＭＴＰパケットに格納されている場合がある。

ＭＭＴＰに含まれる映像データのＭＦＵまたは音声データのＭＦＵは、アクセスユニット（以下、ＡＵと示す。）またはＮＡＬユニットと呼ばれる処理単位になっている。そして、ＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニットは、ＡＵをさらに細かく分割したデータである。

ＭＦＵに直接映像データを格納する場合には、ＡＵを格納する場合とＮＡＬユニットを格納する場合とが定義されている。しかし、日本の新しい放送方式では、ＮＡＬユニットで格納する方式を採用している。そのため、以降の説明ではＮＡＬユニットとして格納されているものとして説明する。

図２では、ＮＡＬユニットを直接ＭＦＵに格納した場合を示している。ＮＡＬユニットには、映像データのみを含んだＶＣＬ−ＮＡＬユニットと、映像データを含まず管理情報を格納した非ＶＣＬ−ＮＡＬユニットとがある（ＶＣＬ：Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ）。

非ＶＣＬ−ＮＡＬユニットは、ＮＡＬヘッダを取り除くと、制御情報が得られる。

ＶＣＬ−ＮＡＬユニットは、ＮＡＬヘッダを取り除くと、分割された映像データが取り出される。これらの分割された映像データを結合することによって、１フレーム分の圧縮された映像データとなる

通常、ＮＡＬユニットは１フレーム分の管理情報と映像データとを含む複数のＮＡＬユニットを一式として扱い、ＡＵと呼ばれている。多重化解除部２１は、映像データの場合には、ＡＵは、映像データを含んでいる。そして、多重化解除部２１は、ＥＳ（エレメンタリーストリーム）を再構築することができる。

映像データのＡＵは、基本的には、１フレーム分の映像単位である。１フレーム分の映像単位は、ピクチャを表現する単位である。映像装置では、このピクチャを時系列的に順次切り替えながら表示することで動画として表示している。しかし、前後のフレームとの依存関係で、いくつかの種類がある。

１つは、Ｉピクチャと呼ばれるものである。Ｉピクチャは、このデータ単独で、１枚のピクチャを再現できる。

他には、ＰピクチャまたはＢピクチャと呼ばれるものである。これらのデータは、他のピクチャに依存している。そのため、ＰピクチャおよびＢピクチャは、単独では１枚のピクチャを再現できない。ＰピクチャおよびＢピクチャは、他のピクチャを参照することによって、ピクチャを再現できる。Ｐピクチャは、１枚の他のピクチャを参照する。Ｂピクチャは、２枚の他のピクチャを参照する。

テレビ放送または映像記録再生装置などでは、番組の途中からの視聴できることが求められている。また、テレビ放送または映像記録再生装置などでは、ランダムアクセスできることが求められている。そのため、参照するピクチャが広範囲であると都合が悪い。

そこで、ある程度の時間またはフレーム枚数を一式として扱う。この一式のデータの中で、参照するピクチャが完結するように定められてある。

この一式のデータは、ＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）と呼ばれている。ＧＯＰは、少なくとも１つのＩピクチャを含んでいる。番組の途中から視聴する際には、取得したストリームデータが映像を再現できない不完全な位置から始まっている場合でも、次のＧＯＰの始まりからは映像を再現して表示することができる。

例えば、日本の新しい放送方式は、２Ｋ放送では０．５秒を目途に、また、４Ｋ放送では１秒を目途に、ＧＯＰを作成するよう求めている。これによって、テレビの電源投入した際に、または、チャンネルを切り替えた際にも、１秒から２秒で、映像を表示できる。

なお、映像が画面の全体で入れ替わる場合には、切り替わりの前後でＧＯＰを分けた方が、効率が良い。例えば、圧縮率または画像再生などの効率が向上する。画面の全体で入れ替わる場合には、例えば、シーンの切り替わりなどである。そのため、ＧＯＰ長は、固定した値ではなく、柔軟に運用される。つまり、状況に応じて、ＧＯＰ長は、変更される。

なお、通信またはネット配信では、日本の新しい放送方式よりも長い単位のＧＯＰが使用されることもある。

記録された映像を再生する際には、表示したいフレームを含むＧＯＰの先頭から映像にアクセスする。これによって、スムーズなランダムアクセスが可能になる。また、早送りなどの際には、ＧＯＰごとにＩピクチャのみを表示することができる。ＧＯＰは、動画として再生できる映像データの一固まりの単位である。また、ＧＯＰは、再生が可能な位置を示す単位である。また、ＧＯＰは、ランダムアクセスが可能な位置を示す単位である。

放送波Ｂａを受信する際には、ＰＬＴ（Ｐａｃｋａｇｅ Ｌｉｓｔ Ｔａｂｌｅ）を受信する。ＰＬＴは、ＭＭＴＰパケットとして送られてくる制御信号の１つである。

全ての情報が放送波Ｂａで送られてくる場合には、ＰＬＴ内の「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」で指定された「ｐａｃｋｅｔ＿ｉｄ」を参照する。そして、この「ｐａｃｋｅｔ＿ｉｄ」でＭＭＴＰパケットをフィルタリングする。これによって、目的とする番組の管理情報を含むＭＭＴＰパケットを選択することができる。

ネットワークＮｅから番組の管理情報を取得する場合には、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」に記載されているＩＰアドレスとポート番号とによって番組の取得先が指定される。または、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」に記載されているＵＲＬによって番組の取得先が指定される。

次に、選択したＭＭＴＰパケットの中から、ＭＰＴ（ＭＭＴ＿Ｐａｃｋａｇｅ＿Ｔａｂｌｅ）を含むデータを選択する。ＭＰＴには、番組を構成する映像、音声または字幕などのアセットの組合せと取得先とが記述されている。それぞれのアセットの取得先は、「ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ」に記載されている「ｐａｃｋｅｔ＿ｉｄ」またはネットワーク情報に示されている。ネットワーク情報は、ＩＰアドレスとポート番号とである。または、ネットワーク情報は、ＵＲＬである。

また、それぞれの映像、音声または字幕などの時間で同期する必要のあるアセットに関しては、アセットごとにＭＰＵタイムスタンプ記述子とＭＰＵ拡張タイムスタンプ記述子とが定義されている。

アセットなどの取得先としては、放送波Ｂａに含まれて送られてくる場合と、ネットワークＮｅから取得する場合とが定められている。しかし、説明の簡略化のため、以降では放送波Ｂａに含まれて送られてくる場合を一例として説明する。

新しい日本の放送方式では、映像データと音声データとに関しては、ＭＦＵに直接ＮＡＬユニットを格納して送出する方式を採用している。また、新しい日本の放送方式では、「ＲＡＰ_ｆｌａｇ」の付加されたＭＭＴＰパケットから次の「ＲＡＰ_ｆｌａｇ」の付加されたＭＭＴＰパケットの直前までを、１つのデータの集まりとして取り扱われる。そして、その１つのデータの集まりは、ＭＰＵとして取り扱われる。「ＲＡＰ_ｆｌａｇ」は、ランダムアクセス可能なデータの開始点を示す。

これらは、ＭＭＴＰパケットの「ＲＡＰ＿ｆｌａｇ」の有無の調査によって、同一ＭＰＵに属していることを識別できる。または、これらは、ＭＭＴＰパケットの「ＭＰＵ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ」によって、同一ＭＰＵに属していることを識別できる。この用法でのＭＰＵを、ここでは、仮に「ストリーム伝送単位ＭＰＵ」と呼ぶ。

この「ストリーム伝送単位ＭＰＵ」は、ランダムアクセス可能なデータを先頭としている。このため、映像の観点から考えると、ＧＯＰ単位になっている。つまり、「ストリーム伝送単位ＭＰＵ」は、ＭＭＴＰの観点からは１ＧＯＰを構成するＭＭＴＰパケットの集まりと考えることができる。

前述のＭＰＵタイムスタンプ記述子とＭＰＵ拡張タイムスタンプ記述子とは、この「ストリーム伝送単位ＭＰＵ」に関連付けて、同期する時間の情報を与えている。

ＭＰＵタイムスタンプ記述子には、映像または音声などのＭＰＵで、それぞれのＭＰＵの中で最初に再生されるタイミングがＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）形式の時刻で示されている。ＮＴＰは、コンピュータに内蔵されているシステムクロックを、ネットワークを介して、コンピュータどうしの時刻を正しく同期させるためのプロトコルである。

ＭＰＵ拡張タイムスタンプ記述子には、それぞれのＭＰＵの中のＡＵ（映像の場合はフレーム）ごとに、再生されるタイミングがＭＰＵ内での相対的な時間として記述されている。ＭＰＵ内での相対的な時間は、ＡＵ内での先頭からの差分または直前のＡＵからの差分などである。「差分」とは、２つの値の差のことである。例えば、ここでは、２つの値は時刻である。

これらの記述によって、映像、音声または字幕などの組合せを指定することができる。そして、映像、音声または字幕などの時間的な同期を取りながら再生することができる。

テレビ放送では、ＰＬＴおよびＭＰＴは、テレビの電源を入れた後に、短時間で番組を表示できるために、比較的に短い周期で再送されている。新しい日本の放送方式案の場合には、ＰＬＴおよびＭＰＴは、１００ｍｓごとに送られる。

これまで、ＴＬＶパケット、ＴＣＰパケットおよびＭＭＴＰパケットを結合したファイルを記録する方法を説明した。または、ＴＬＶパケット、ＵＤＰパケットおよびＭＭＴＰパケットを結合したファイルを記録する方法を説明した。

しかし、このままでは、再生時刻の情報またはランダムアクセス可能な位置を示す情報などが、ファイル内の各所に分散して記録される。これは、情報へのアクセスにとっては、適していない。また、同じ情報が何度も記録されるため冗長である。

この情報が分散して記録されることは、放送では、どの時点から番組の受信を開始しても、短時間で情報をそろえて、表示を開始する必要があるからである。このため、ストリーム中の各所に分散して情報を持たせている。また、放送では、記録およびランダムアクセスを考慮する必要がないためである。

記録した番組を視聴する際には、頭出し、シーンの検索または編集による映像間の接続などが行われる。そのためランダムアクセスが必要となる。そこで、ランダムアクセスに必要な情報を、情報の記録時または情報の記録後に、独自に作成する。

図５、図６および図７を用いて、ランダムアクセスのためのデータ生成について説明する。

ここでは、ＭＭＴＰパケット結合したファイルとして映像または音声などを含む映像データを作成する例を説明する。しかし、ＴＬＶまたはＵＤＰ／ＩＰパケットを使用する場合も同様である。

図５は、パケットの選択と時間の同期とを説明する概念図である。四角で表わしたものが、ＭＭＴＰパケットである。

図５において、横方向は、データの受信の順番を示している。つまり、横軸Ｈａ方向には、受信された順番にデータが並べられている。受信した順番に左から右に記載してある。

映像のＭＭＴＰパケットの「Ｒ」と記載されているパケットは、「ＲＡＰ＿ｆｌａｇ」が設定されている。そして、ＧＯＰの先頭を含んでいる。

図５中において、ＭＰＴから引き出されている矢印は、このＭＰＴのＭＰＵタイムスタンプ記述子でそれぞれどのＭＰＵの再生時刻を決めている関係を表している。

例えば、最初に現れるＭＰＴ−０は、映像アセットとして、「ｐａｃｋｅｔ＿ＩＤ」を指定する。図５では、一例として、ＭＰＴ−０は、ＭＰＵ−ｖ０とＭＰＵ−ｖ１との再生タイムスタンプを指定している。ＭＰＵは、複数のＭＭＴＰパケットで構成されている。

また、同じＭＰＴ−０は、音声アセットとして「ｐａｃｋｅｔ＿ＩＤ」を指定する。図５では、一例として、ＭＰＴ−０は、ＭＰＵ−ａ０とＭＰＵ−ａ１との再生タイムスタンプを指定している。なお、音声のＭＰＵは、１つのＭＭＴＰパケットに１つとは限らない。また、音声のＭＰＵは、映像のＭＰＵと同頻度で出現するとも限らない。しかし、作図上、１つのＭＭＴＰパケットに１つの音声ＭＰＵとしている。また、映像のＭＰＵの出現頻度と音声のＭＰＵの出現頻度とを同程度として描画している。

図５中では、音声、映像および制御情報の３つの流れが書いてある。しかし、実際には、録画再生装置１００は、１つのデータの流れとして混在した状態で受信している。

このような異なる種類の情報を、一つのデータとして混在させている状態を多重化されているという。多重化された状態から、「ｐａｃｋｅｔ＿ＩＤ」、各種のフラグまたは各種の識別子などを用いて、目的とするデータの流れ（ストリーム）を抽出して、分離することができる。「ｐａｃｋｅｔ＿ＩＤ」、各種のフラグまたは各種の識別子などは、それぞれのＭＭＴＰパケット付加されている。多重化されたデータから目的のデータを取り出すことを多重化の解除という。

対象とする番組の多重化されたデータの中から、ＭＰＴを含むＭＭＴＰパケットを抽出する。そして、ＭＭＴＰパケットからＭＰＴを取り出す。ＭＰＴには、番組を構成する各種アセットのリストとその取得方法とが格納されている。

例えば、映像の種類とそのデータを格納している「ｐａｃｋｅｔ＿ＩＤ」とを知ることができる。また、音声の種類とそのデータを格納している「ｐａｃｋｅｔ＿ＩＤ」とを知ることができる。これらの「ｐａｃｋｅｔ＿ＩＤ」で、受信したＭＭＴＰパケットを選択し、または、分類する。これらによって、番組を構成する映像データまたは音声データを個別に取出すことができる。つまり、多重化を解除できる。

コンテナフォーマットの目的の一つは、このように、異なるデータを一組にまとめて多重化して取り扱いやすくするものである。コンテナフォーマットは、例えば、ＭＭＴまたはＭＰＥＧ２ＴＳなどである。

図５では、受信したストリームデータをＭＰＴストリーム、映像ストリームおよび音声ストリームの３つのストリームに分けている。

コンテナフォーマットのもう一つの目的は、タイミングを合わせてこれらのデータを再生することである。つまり、コンテナフォーマットのもう一つの目的は、これらのデータを同期して再生することである。

図５では、ＭＰＴ−０を受信すると、この番組を構成する映像または音声などのアセット情報を得ることができる。さらに、これらのアセットごとにタイムスタンプ情報が記載されている。タイムスタンプ情報は、映像の表示または音声の再生などのタイミングを示す情報である。タイムスタンプ情報は、ＭＰＴ内に記載されている。タイムスタンプ情報は、アセットごとの「ストリーム伝送単位ＭＰＵ」の番号に対しての再生時刻である。

例えば、映像に対しては、ＭＰＴ−０に、ＭＰＵ−ｖ０の最初のフレームの再生時刻およびＭＰＵ−ｖ１の最初のフレームの再生時刻が記載されている。また、ＭＰＴ−１に、ＭＰＵ−ｖ１およびＭＰＵ−ｖ２のそれぞれの最初のフレームの再生時刻が記載されている。

音声に対しても、同様に、ＭＰＴ−０に、ＭＰＵ−ａ０の再生時刻およびＭＰＵ−ａ１の再生時刻が記載されている。また、ＭＰＴ−１に、ＭＰＵ−ａ１再生時刻およびＭＰＵ−ａ２の提示時刻が記載されている。

ここでは、説明のために、アセットごとに「ストリーム伝送単位ＭＰＵ」の２つ分のタイムスタンプを持っているものとして説明した。しかし、実際には、さらに多くのタイムスタンプを持たせることもできる。

このようにして、ＭＰＵによって「ストリーム伝送単位ＭＰＵ」の再生時刻を指定することができる。そして、映像と音声とを同期して再生することができる。ここでは説明しなかったが、字幕に関しても同様である。

これらの情報を記録する場合について、図６を用いて説明する。図６は、ＭＭＴＰ方式でのＭＰＵタイムスタンプ記述子を用いた同期方式を説明する図である。図６には、アセットデーブル、タイムテーブルおよびデータファイルが記載されている。データファイルの上側は、データの先頭である。

データファイルには、番組を構成するＭＭＴＰパケットが順次記録される。単純に、ＭＭＴＰパケットを受信順に記録した場合には、映像データ、音声データまたは制御情報等が混在した状態で記録される。ここでは、説明のために「ストリーム伝送単位ＭＰＵ」ごとにまとめた形で記載している。

例えば、「ＭＰＴ−０」は、ＭＰＴである。そして、受け取られた順番が付されている。「ＭＰＴ−０」の順番は、「０」であるため、最初に受け取られたことを示している。

例えば、「ＭＰＵ−ｖ０」は、ビデオストリームとして選択されたＭＭＴＰパケットである。ＭＭＴＰパケットは、ＭＭＴＰパケットを複数まとめたＭＰＵとして扱っている。そして、受け取られた順番が付されている。「ＭＰＵ−ｖ０」の順番は、「０」であるため、最初に受け取られたことを示している。

例えば、「ＭＰＵ−ａ０」は、音声ストリームとして選択されたＭＭＴＰパケットである。音声のＭＰＵは、１つのＭＭＴＰパケットに１つとは限らない。また、音声のＭＰＵは、映像のＭＰＵと同頻度で出現するとも限らない。しかし、説明を簡単にするため、音声のＭＰＵが映像のＭＰＵと同じ頻度で発生するとしている。また、音声のＭＰＵは、１つのＭＭＴＰパケットに１つとしている。

データファイル中の「Ｒ」と記載されているパケットは、「ＲＡＰ＿ｆｌａｇ」が設定されている。そして、ＧＯＰの先頭を含んでいる。そのため、このパケットからデータを読み始めることによって、効率よく映像を再生できる。

また、不完全なデータを破棄することが低減される。映像データは、ＧＯＰを構成している。このため、先頭のＩピクチャ部分のデータを取り損ねると後続の何十枚かのピクチャは映像として再現できない。ＧＯＰの先頭のデータを取り損ねた場合には、読み取ったデータを破棄しながら、次のＧＯＰ先頭が来るのを待つ。このような、データの破棄を低減することができる。このようなデータの破棄は、頭出しまたはランダムアクセス時に、表示の遅延となる。このため、データの破棄の低減によって、スムーズな再生が可能になる。

前述の通り、このように記録したデータファイルは、ランダムアクセスを行うには適していない。

第１には、映像データは可変長データである。このため、目的とする映像を再生するためのデータがどこに存在するのかを特定することができない。第２には、「ＲＡＰ＿ｆｌａｇ」が設定されているパケットを直接呼び出すことができない。

そこで、ランダムアクセス用の検索テーブルを用意する。

図６のアセットテーブルには、「ｐａｃｋｅｔ＿ｉｄ」を格納しておく。「ｐａｃｋｅｔ＿ｉｄ」を用いて、データファイル内のＭＭＴＰパケットから必要なアセットを取りだすことができる。

タイムテーブルには、「ＲＡＰ＿ｆｌａｇ」を含むパケットのファイル内での記録位置を格納する。そして、このパケットを含む「ストリーム伝送単位ＭＰＵ」の指定された再生時間を格納する。そして、これらの情報を再生時間の時系列順に並べておく。

アセットテーブルおよびタイムテーブルの内容は、例えば、ＭＰＴに記載されている情報と記録再生装置１００に記録される際の情報とから作成することができる。

時刻を決めて再生を行う場合について説明する。

例えば、図６において、時刻「０：０：１．００」からの映像を表示する場合には、まず、タイムテーブルの時刻を検索する。そして、時刻が一致する欄からファイル上の位置である「２５００００００」を読み出す。

そこで、データファイルの位置「２５００００００」から、データを読み込む。そして、データの再生処理を行う。これによって、指定された位置から、データを再生することができる。

データファイルは、映像データ、音声データまたはその他のデータがパケット単位で混在した状態である。しかし、アセットテーブルまたはＭＰＴを参照して、パケットの分類を行うことによって、映像データまたは音声データ等を分離して再生することが可能である。

再生を開始したい時刻と同一の時刻が、タイムテーブルに無い場合もある。この場合には、タイムテーブルに記載されている時刻から、再生を開始したい時刻に近いものを選び、そこからデータを再生する。

例えは、再生開始時刻として「０：０：１．７０」が指定された場合には、タイムテーブルに記載されている「０：０：１．５０」と「０：０：２．００」とのうち、指定された時刻に近い「０：０：１．５０」を選ぶ。そして、データファイル上の位置「３３００００００」からデータを再生する。

データファイル上の位置は、例えば、ファイル先頭からのバイト単位での位置である。または、データファイル上の位置は、例えば、ブロック単位での位置である。または、データファイル上の位置は、例えば、セクタ単位での位置である。

特殊再生の場合について説明する。特殊再生は、例えば、早送りまたは巻き戻しなどである。例えば、早送りの場合には、タイムテーブルを順に読み出し、指定された位置からファイルを読み出す。そして、１フレーム分のデータを再生した時点で、次の時刻の位置に移る。これによって、早送りでデータを再生できる。

図７は、タイムテーブルを作成する手順を示すフローチャートである。

日本の放送方式では、ＭＰＴは１００ｍｓごとに再送される。１ＧＯＰが０．５秒であれば、その間にＭＰＴを５回受信する。１ＧＯＰは、一つの「ストリーム伝送単位ＭＰＵ」である。

また、１つのＭＰＴの１つのアセットにタイムスタンプを１５個格納することが許されている。つまり、タイムスタンプは重複して送出されている。

ステップＳ７００１において、ストリームデータを受信する際に、ＭＭＴＰパケットを取り出す。そして、ＭＭＴＰパケットがＭＰＴを含む場合には、タイムスタンプ処理を実施する。

ステップＳ７００２において、ＭＭＴＰパケットからＭＰＴを取り出す。そして、アセットごとの「ストリーム伝送単位ＭＰＵ」のシーケンス番号とタイムスタンプ情報との組合せを取り出す。

ステップＳ７００３において、タイムスタンプ情報の重複を取り除く。前述のように、タイムスタンプ情報は重複して送出されているためである。この時点で、「ストリーム伝送単位ＭＰＵ」のシーケンス番号と再生時刻を示すタイムスタンプのリストとが得られる。

このフローチャートには含まれていないが、並行して映像データまたは音声データを含むＭＭＴＰパケットは、順次、データファイルとして内蔵記憶装置５１または光ディスク５３に記録される。そして、データファイル上の位置は記録時に判明する。

ステップＳ７００４において、「ＲＡＰ＿ｆｌａｇ」が設定されているＭＭＴＰパケットを記録する際に、このパケットのファイル上での位置と、このＭＭＴＰパケットが属する「ストリーム伝送単位ＭＰＵ」のシーケンス番号とを取り出す。タイムスタンプのリストの中で、同じ「ストリーム伝送単位ＭＰＵ」のシーケンス番号を持つタイムスタンプ情報に、ファイル上に記録した位置の情報を追加する。

ステップＳ７００５において、これらの処理が終了したか否かを確認する。処理が終了していない場合には、「ｎｏ」を選択して、ステップＳ７００１に進む。処理が終了した場合には、「ｙｅｓ」を選択して、ステップＳ７００６に進む。

ステップＳ７００６において、内蔵記憶装置５１または光ディスク５３に作成したデータを書き込む。

このようにして、タイムテーブルを作成することができる。

ここでは、ＧＯＰごとに設定されているＭＰＵタイムスタンプ記述子のタイムスタンプ情報を使って、ランダムアクセスを実現している。ＧＯＰは、「ストリーム伝送単位ＭＰＵ」である。そのため、データの再生を開始できる位置は、ＧＯＰ単位となる。つまり、０．５秒または１秒などの単位でしか再生位置を指定できない。例えば、時間指定による頭出し、早送りまたは巻き戻し等の場合には、この程度の精度で十分である。

しかし、内蔵記憶装置５１または光ディスク５３などに記録した後に、編集などを行う場合には、ＧＯＰ単位での位置指定では不十分である。例えば、同一番組の別の位置どうしを組み合わせ連続して再生する場合、または、別の番組どうしを組み合わせ連続して再生する場合などである。このような組み合せによって、お気に入りシーン集などを作成することができる。

そこで、ＭＰＴ内のＭＰＵ拡張タイムスタンプ記述子を利用する。

図８は、フレーム単位の時刻で検索できるタイムテーブルを示す図である。

図８に示したタイムテーブルは、通常のタイムテーブルを拡張して、フレーム単位の時刻で検索できるようにしたタイムテーブルである。図８に示すタイムテーブルは、再生時刻、ファイル上のデータの位置およびＡＵ番号の情報を持つ。

ＡＵ番号は、同一の「ストリーム伝送単位ＭＰＵ」に属するデータの中の何番目のＡＵであるかを示す。映像データの場合には、ＡＵはピクチャに相当する。しかし、デコードの効率のために、ＧＯＰ内でのＡＵの並びの順は、ピクチャの表示順とは必ずしも一致していない。

このタイムテーブルでは、再生時刻の順番で並べられている。このため、ＡＵ番号は、前後している。つまり、ＡＵ番号は、順番に並んでいない。

ＭＰＵ拡張タイムスタンプ記述子には、それぞれの「ストリーム伝送単位ＭＰＵ」内のＡＵに対して、最初に表示されるＡＵからの差分で再生時刻が与えられている。または、ＭＰＵ拡張タイムスタンプ記述子には、それぞれの「ストリーム伝送単位ＭＰＵ」内のＡＵに対して、再生時刻の間隔が与えられている。

そこで、ＭＰＵタイムスタンプ記述子の再生時刻と、ＭＰＵ拡張タイムスタンプ記述子の差分時刻から各ＡＵの再生時刻を算出することが出来る。または、ＭＰＵタイムスタンプ記述子の再生時刻と、ＭＰＵ拡張タイムスタンプ記述子の再生時刻の間隔とから各ＡＵの再生時刻を算出することが出来る。

なお、図８では、説明のために、一例として、１００分の１秒単位で記載してある。

ＭＰＵ拡張タイムスタンプ記述子の中では、タイムスケール（ｔｉｍｅｓｃａｌｅ）として、１秒を分割する数を定義している。そして、各ＡＵの再生時刻は、このタイムスケールを用いて表記する。映像で使用されるフレームレートは、毎秒６０枚または毎秒２４枚である。そして、１フレームを秒の小数単位で表記しようとすると、割り切れず、誤差が発生する。このため、タイムスケールを用いる。そこで、タイムテーブルのフレーム単位での時刻欄に、このタイムスケールを用いた値を採用することもできる。

ＧＯＰの途中からデータの再生を開始したい場合でも、デコードは必ずＧＯＰの先頭から行う。そのため、データの読み込み開始位置は、同一の「ストリーム伝送単位ＭＰＵ」内では同一となる。

このタイムテーブルを使ってデータの再生する場合の一例を説明する。

時刻「００：００：０１．０４」を指定して検索した場合には、この時刻に相当するピクチャは存在しない。このため、直前のピクチャとなる「００：００：０１．０３」のピクチャから再生を行う。

タイムテーブルを参照すると、このピクチャは、ファイル上の位置「２５００００００」から始まる「ストリーム伝送単位ＭＰＵ」のＡＵ番号２のＡＵである。つまり、このピクチャのＡＵは、３番目のＡＵである。

そこで、ファイル上の位置「２５００００００」から読み出しを開始すると共に、デコードを開始する。１番目のＡＵのデコードが完了して、ピクチャのデータが作成される。この後に、この作成されたピクチャを表示しない。そして、差分情報しか持たない後続のＡＵのデコードを行う。そして、３番目のＡＵのデコードが完了した後に、この３番目のＡＵの映像から再生を開始する。このようにして、ＧＯＰの途中からデータ（映像）の再生を行うことができる。

この例では、詳細な情報を持つタイムテーブルを１つ用いて再生するようにした。しかし、例えば、前述の早送り再生の場合などでは、必ずしも効率の良い方法とはいえない。そこで、標準のタイムテーブルと詳細なタイムテーブルとの２段階で検索を行う方法を取ることもできる。

日本の新しい放送方式では、ＭＰＵ拡張タイムスタンプ記述子は、ＡＵ間の再生間隔を指定している。その間隔は、６０分の１秒または１２０分の１秒である。この間隔は可変である。しかし、番組内では同一フレームレートを用いている。そのため、詳細なタイムテーブルを用いずに、計算によって各フレームの再生時刻を求めることが出来る。

この場合には、図６に示した「ストリーム伝送単位ＭＰＵ」ごとのタイムテーブルを利用して検索する。そして、再生を開始したい時刻を含む「ストリーム伝送単位ＭＰＵ」を特定する。そして、この再生時刻と再生を開始したい時刻との差を求める。この時刻の差とフレームレートとから、この「ストリーム伝送単位ＭＰＵ」内の表示順で、何枚目のピクチャであるのかを求めることが出来る。

指定された時刻にフレームがない場合には、表示の順番で指定時刻の直前のフレーム、または直後のフレームとする。つまり、指定時刻の直前のフレーム、または直後のフレームを採用する。

前述のように、ＡＵの並び順とピクチャの再生時刻の順番とが異なる。しかし、「ストリーム伝送単位ＭＰＵ」の先頭からデコードを開始する。そして、算出された再生の順番を持つピクチャのデコードが完了する。デコードが完了したピクチャから再生を開始する。これによって、ピクチャ単位の精度での頭出しを行うことが出来る。

ここで、説明したタイムテーブルを別ファイルとして作成して録画を行った場合には、番組内容を記録するデータファイルにタイムスタンプを記録する必要はない。

ＭＰＴは、タイムスタンプ以外の制御情報を含んでいる。例えば、ＭＰＴは、アセット情報などを含んでいる。タイムスタンプは、例えば、ＭＰＵタイムスタンプ記述子またはＭＰＵ拡張タイムスタンプ記述子などである。つまり、ＭＰＴは、ＭＰＵタイムスタンプ記述子またはＭＰＵ拡張タイムスタンプ記述子以外にも、アセット情報などのタイムスタンプ以外の制御情報を含んでいる。

しかし、これらの情報は、番組の途中で変更される性格のものではない。このため、別ファイルなどで１箇所に記録しておくことで、ＭＰＴそのものは記録を省略することが出来る。例えば、図６では、アセットテーブルとして管理情報（Ｐａｃｋｅｔ＿ｉｄ）を保持している。

ＭＰＴが単独でＭＭＴＰパケットに格納されている場合には、データファイルにＭＭＴＰパケットを記録する際に、ＭＰＴを格納したＭＭＴＰパケットを記録する必要がなくなる。

ＭＰＴが他の管理情報と一緒にＭＭＴＰパケットに格納されている場合には、ＭＰＴを除いた管理情報でＭＭＴＰパケットを再構成する。そして、再構成されたＭＭＴＰパケットを記録することが出来る。

ＭＰＵタイムスタンプ記述子またはＭＰＵ拡張タイムスタンプ記述子は、放送時には重複度の高いデータである。このため、省略することが出来れば、記録するデータサイズを小さくすることが可能となる。

前述では、ＭＰＴを記録する必要はないとした。しかし、ＭＰＴを映像ストリームまたは音声ストリームなどのストリームを含むＭＭＴＰパケットと一緒に記録しておいた方が便利なこともある。

例えば、多重化解除部２１とデコード部３１，３２，３３，３４とが一体となったＬＳＩを用いてデコード処理を行う場合には、ＭＰＴを含んだデータを多重化解除部２１に入力することで、多重化解除、デコードおよび同期処理を一括して行うことができる。

また、フレーム単位の頭出しを行う場合にも、「ストリーム伝送単位ＭＰＵ」の前または先頭にＭＰＴがあれば、このＭＰＴを参照して、再生を開始する前に、フレーム単位での再生時刻を求めて頭出しを行うことが出来る。ＭＰＴは、「ストリーム伝送単位ＭＰＵ」の先頭付近にあってもよい。

この場合にも、テレビ局から送信されてきたＭＰＴの全てを記録する必要はない。ＭＰＴの一部だけを記録することで処理することも出来る。

図９は、ＭＭＴＰ方式でのＭＰＵタイムスタンプ記述子を用いた同期方式を説明する図である。図９では、「ストリーム伝送単位ＭＰＵ」の直前にＭＰＴを格納している。タイムテーブルには、「ストリーム伝送単位ＭＰＵ」の先頭の位置ではなく、このＭＰＴの位置を示している。

従来のブルーレイディスクの記録方式では、これらのタイムテーブルに相当する情報としてクリップファイル内に「ＥＰ＿ｍａｐ」を格納していた。しかし、「ＥＰ＿ｍａｐ」は、固定長パケットとパケットごとのタイムスタンプを持つＭＰＥＧ２ＴＳを前提とした構造になっている。そのため、そのままではＭＭＴのデータに適用できない。

そこで、前述のタイムテーブルを「ＥＰ＿ｍａｐ」の代わりに使用する。これによって、ＭＭＴのデータをブルーレイディスクに記録した際に、データアクセスを容易にすることができる。

この例では、ＭＭＴＰパケットを結合して記録する説明を行った。しかし、ＴＬＶパケット、ＩＰパケットまたはＵＤＰパケットのそれぞれの状態で、パケットを結合して記録することもできる。また、タイムテーブルを拡張して、アセットごとに記録することも可能である。つまり、映像データまたは音声データの読み出し開始位置を検索できるようにする。そして、ＭＦＵの羅列としてデータを結合して記録する。

［標準フォーマットを用いて記録する場合］
ＭＭＴでは、前述のように伝送フォーマットとは別に、蓄積フォーマットが規定されている。ＭＭＴの蓄積フォーマットでは、ＢＭＦＦ（ＩＳＯ／ＩＥＣ １４４９６−１２ ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）形式をベースに、データを格納する。この場合には、データのレイアウトは、図３に示された論理構造をしている。図３は、データの論理構造を示した図である。

このデータの塊は、ＭＰＵと呼ばれている。このＭＰＵは前述の「ストリーム伝送単位ＭＰＵ」とは異なるものである。ここでは、仮に「番組蓄積用ＭＰＵ」と呼ぶ。「番組蓄積用ＭＰＵ」は、通常ファイルとして格納され、管理されている。

図３の論理構造を用いて「番組蓄積用ＭＰＵ」の構造を説明する。

ＭＰＵメタデータは、ファイルの管理データ、アセット情報、各種パラメーターまたはヒント情報などを含んでいる。アセット情報は、映像データと音声データとの組み合わせなどを管理する情報である。各種パラメーターは、デコーダーの動作モード等を設定するためのパラメーターである。ヒント情報は、ＭＰＵファイルに格納されたＭＦＵからＭＭＴＰパケットを再構成するための情報である。

ムービーフラグメントメタデータは、再生時間で区切られた映像データまたは音声データなどにアクセスするための情報である。また、ムービーフラグメントメタデータは、映像データまたは音声データなどを再生するための情報である。

実際の映像データおよび音声データは、ＭＦＵの羅列として格納されている。１つのムービーフラグメントメタデータとそれによって管理される一塊のＭＦＵとは、まとめてムービーフラグメントと呼ばれている。一般的には、複数のムービーフラグメントで１つのコンテンツを構成している。ネットワークストリーミング等では、一般的には、１フラグメントは１０秒から１５秒で構成されている。

ＭＰＵメタデータおよびムービーフラグメントメタデータが放送波Ｂａ等で送られてくる場合には、これらを利用してＭＰＵを構成することができる。ＰＬＴ、ＭＰＴ、その他の制御情報またはＭＦＵを取り出すまでの各種ヘッダ情報は、冗長になるため、記録する必要はない。

一方、新しい日本の放送方式案では、ＭＰＵメタデータおよびムービーフラグメントメタデータは、放送時に送出されない。そのため、ＰＬＴ情報、ＭＰＴ情報および各種のヘッダ情報を組み合わせて、独自にＭＰＵメタデータ等を作成する。

光ディスク５３への記録にも、上記の蓄積フォーマットを使用することを考える。光ディスク５３では、物理的に連続して格納されたデータを比較的高速に読み出すことが可能である。しかし、光ディスク５３上の直径方向に離れた位置にあるデータを読み出す場合には、ヘッドシークを伴うため、データを読み出しに時間を要する。つまり、光ディスク５３では、前後して使用される可能性の高いデータを、連続した領域またはディスク５３上の近い位置に配置した方が、効率よくデータを読み出すことが可能になる。

図３に示された論理構造そのままのデータ配置で、データを記録すると、ＭＰＵメタデータ、ムービーフラグメントメタデータおよびＭＦＵが、物理的な配置として分散して格納される。ＭＰＵメタデータは、再生に必要なデータである。ＭＦＵは、映像データを格納している。このため、光ディスクの特性上、図３に示された論理構造のままのデータ配置は、不利なデータ配置となる。

多くのファイルシステムでは、蓄積されるデータの論理構造と物理配置とを別々に管理することができる。ブルーレイディスクで採用しているＵＤＦも同様である。

そこで、論理構造は規格通りとして、物理配置では、ＭＰＵメタデータとムービーフラグメントデータとをまとめて記録する。

図３の物理配置に示したデータ構造は、光ディスク上の物理的なデータ配置として、管理情報をまとめて配置した例である。このようなデータ配置とすることで、ＭＰＵメタデータとムービーフラグメントメタデータとを一度に読み込むことが可能となる。

なお、「データ構造」は、ここでは、ファイルシステムよりも上位からみた構造を示している。例えば、論理的なデータ構造、ディレクトリまたは１つのファイル内でのデータの並びなどである。一方、「データ配置」は、ファイルシステムよりも下位から見た配置を示している。例えば、物理的なデータのレイアウトなどである。ファイル名とファイル名とで結び付けられたブロック、または、データのつながりを示すブロック同士のリンク情報などで構成されている。この場合には、ブロックは、ディスク上の物理的な位置と結びついて管理されているデータの集合である。ファイルシステムによっては、他の名称が用いられる事もある。

そして、図３の物理配置に示したデータ配置は、ヘッドシーク回数を減らす。そして、図３の物理配置に示したデータ配置は、再生を開始する際にかかる時間およびランダムアクセスの際にかかる時間を短くすることができる。

また、論理構造と物理配置とを分けて考えることはせずに、単純に管理情報のコピーを別ファイルにもたせることも考えられる。図３に示した追加クリップファイルは、そのような場合の一例である。この場合には、例えば、ランダムアクセスを容易にするための追加情報等を、ファイルに追加することも可能である。

これまで示した例では、フラグメントを用いたデータ構造の例で説明した。しかし、フラグメント単位での送出を想定しない場合には、ムービーフラグメントメタデータをもたないデータ構造での記録も可能である。

ＢＭＦＦによるファイルフォーマットでは、管理情報とストリームデータとは、同一ファイルにまとめて記録されている。一方、従来のブルーレイディスクの記録方式では、管理情報とストリームデータとは、分けて管理されていた。

これは、管理情報をまとめて読み込み、再生するデータにあわせて機器を設定した後に、ストリームデータの再生を行うことが、光ディスクの機器に適しているためである。管理情報とストリーム情報とは、光ディスク上では、領域を分けて記録されている。また、管理データは光ディスクの損傷に備えて、光ディスク上に２重に記録して、バックアップデータとしているためでもある。このバックアップデータは、光ディスク上の離れた位置に記録されている。

ＢＭＦＦにおける管理データは、ブルーレイディスクでは、主にクリップファイルで管理されている情報である。そこで、ＢＭＦＦとして記録する際に、番組の管理データ部分をファイルシステム上の別ファイルから参照する。つまり、見かけ上、番組の管理データ部分を別のファイルとすることができる。

図１０は、ＢＭＦＦとしてストリームデータを記録した場合の説明図である。

図１０に示したのは、ＢＭＦＦとしてストリームデータを記録した場合の例である。

物理的な配置としては、管理データは、光ディスク５３上の管理データ領域に記録される。ストリームデータ部分は、光ディスク５３上のストリームデータ領域に記録される。

ストリームファイルとして、このデータにアクセスする際には、ファイルシステムが管理データ部分とストリームデータ部分とを関連付けて、論理的に１つのＢＭＦＦファイルとして見えるようにする。

一方、ブルーレイディスクの管理データであるクリップファイルとしてこのデータにアクセスする際には、ＢＭＦＦファイルの管理データ部分のみをファイルとして見えるようにする。クリップファイルは、ブルーレイディスクの管理データである。

このような配置とすることによって、ＭＭＴの標準記録フォーマットとしてＢＭＦＦ形式のファイルを作成することができる。また、ブルーレイディスクの管理方法とも整合性のあるデータ形式とすることができる。

このようにして、ＢＭＦＦとして記録されたデータのヘッダ部分を、別のファイルとして参照できるようにすると、光ディスク５３上でのデータ管理においても有利になる。また、管理データのバックアップデータの作成も容易になる。

例えば、ＰＣなどで映像データを取り出す際には、ＢＭＦＦファイルをコピーすれば管理情報とストリームデータとの両方を含むＢＭＦＦファイルとしてコピーできる。一方、光ディスク内の管理情報のバックアップを作成する際には、ＢＭＦＦＣＬＩＰファイルからコピーを作成すれば、バックアップの必要な管理データ部分のみのデータがコピーできる。

また、管理データとストリームデータとを分けて保管している光ディスクのフォーマットに合わせて、ＢＭＦＦの管理データ部分を光ディスク５３の他の管理データを格納している領域に格納できる。このため、再生を準備する際のヘッドシーク量を減らすことが出来る。

≪（Ｂ）多重化が解除されたエレメンタリーストリームＳｅの状態でのデータの記録≫
前述の例では、受け取ったデータに対して、部分的に多重化を解除ながら、蓄積用フォーマットに変換する方法について説明した。受け取ったデータは、放送波Ｂａ、外部装置ＥｉまたはネットワークＮｅなどから受け取ったデータである。

しかし、多重化解除部２１がハードウェアとして作られている場合などには、映像または音声などに分離されたＥＳ（Ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）の状態で取り出して、記録することができる。なお、ＥＳは、図１ではエレメンタリーストリームＳｅとして示されている。

ＥＳは、圧縮された映像データのストリームまたは音声データのストリームである。ＥＳは単位ごとに区切られるが、ここで「単位」は、処理する上で意味のある単位である。この単位は、例えば、映像データの場合にはピクチャあるいはＮＡＬである。また、この単位は、例えば、音声データの場合にはブロックである。

以下において、映像記録フォーマットは、ＩＳＯ ＢＭＦＦを例に取って説明する。

ＢＭＦＦにおいて、多重化された状態でデータを記録する方式では、時間の流れを持ったデータを管理するデータをトラックと呼ぶ。

前述の多重化が解除されていない状態で記録する方式では、トラックは１つである。これは、例えば、映像データと音声データとが多重化された状態であるため、時間の流れを持ったデータは、多重化ストリームＳｍの１つである。多重化ストリームＳｍは、ＭＦＵの羅列として表現されている。

一方、エレメンタリーストリームＳｅの状態では、例えば、映像データと音声データとは分離されたＥＳストリームデータとして存在する。そのため、映像データのトラックと音声データのトラックとを個別に作成する。映像データのトラックと音声データのトラックとは、データファイル上の管理データを格納する領域に記録される。そして、映像データと音声データとは、メディアデータを格納する領域に格納される。

それぞれのトラックは、再生時刻を示している。また、それぞれのトラックは、再生時刻に対応したメディアデータを格納する領域の位置を示している。メディアデータは、映像データまたは音声データなどである。

そして、映像データと音声データとは、時間的に同期を取った状態で関係付けがされる。また、字幕なども、同様に、表示タイミングを含めて関係付けがされている。

新しい日本の放送方式案では、ＭＭＴＰパケットのＭＴＰ内に、番組内で使用される映像、音声または字幕などの組合せが示されている。また、ＭＭＴＰパケットのＭＴＰ内に、映像、音声または字幕などの表示タイミングまたは再生タイミングが示されている。また、ＭＭＴＰパケットのＭＴＰ内に、映像、音声または字幕などのデータの格納位置が示されている。

番組を構成する（データ放送の部品等）データファイルなどをＭＭＴで送る場合には、１つのファイルを１つのＭＰＵに格納する。このＭＰＵを「データ要素ＭＰＵ」と呼ぶ。そして、この１つの「データ要素ＭＰＵ」を分割して、ＭＦＵとしてＭＭＴＰで送付する。この場合には、ＭＰＵヘッダまたはＭＰＵメタデータも同時に送付される。

また、映像または音声などのストリームデータでは、オーバーヘッドを回避するために、データ要素ＭＰＵを使用しない。その代わりに、ＡＵまたはＮＡＬを直接ＭＦＵに入れてＭＭＴＰで送付する。

しかし、新しい日本の放送方式案の時間管理では、ランダムアクセスフラグの単位でＭＰＵを構成することになっている。時間の指定は、ＭＰＵに対して行う。このため、１つのＧＯＰで０．５秒から１秒の単位であれば、時間指定の単位として問題はない。この場合には、ＭＰＵヘッダまたはＭＰＵメタデータ等は送付されない。このランダムアクセスフラグを区切りとした一式のＭＭＴＰパケットの集合を、前述の通り、ここでは、仮に「ストリーム伝送単位ＭＰＵ」と呼んでいる。

また、多重化されたデータを受信して、ファイルに記録する。このファイルに記録する際に用いられるデータ構造もＭＰＵである。例えば、ファイルに記録する際に、番組全体で１つのＭＰＵとすることができる。この用法でのＭＰＵを、ここでは、仮に「番組蓄積用ＭＰＵ」と呼ぶ。また、ストリーム伝送単位ＭＰＵ単位で記録することもできる。この場合には、ＭＰＵのファイルの数が膨大になる。また、ストリーム伝送単位ＭＰＵを束ねてＭＰＵに格納することもできる。このストリーム伝送単位ＭＰＵを束ねたＭＰＵを、ここでは、仮に「番組蓄積用ＭＰＵ」と呼ぶ。

日本の新しい放送方式の場合には、ＧＯＰ単位で「ストリーム伝送単位ＭＰＵ」を構成している。ＭＰＴ内の「ＭＰＵタイムスタンプ記述子」によって、先頭のフレームの表示時刻が指定されている。ここでの時刻は、ＮＴＰ時刻である。「拡張タイムスタンプ記述子」によって、ＧＯＰ内の後続のフレームの表示時刻が指定されている。後続のフレームの表示時刻は、先頭のフレームの表示時刻からの差で示される。

多重化が解除されエレメンタリーストリームＳｅが取り出された状態ではＭＰＴが取り除かれている。そのため、ＭＰＴとその他の制御情報とを組み合わせて、トラックなどの管理情報を作成して、記録する必要がある。トラックは、時間の流れを持ったデータの管理情報である。時間の流れを持ったデータは、例えば、映像データまたは音声データなどである。トラックは、データの種類、再生時刻または実際のデータの記録位置へのポインタなどを含んでいる。これらのデータは、前述のタイムテーブルの作成と同様の手順で作成することが出来る。

トラックでは、細かな時間単位でデータの取り出し位置を指定することが出来る。そのため、再生時間の順番またはデコード時間の順番に、映像データと音声データとを混在させて並べることが出来る。このような構造を取ることによって、同時に再生する必要のある映像データと音声データとを、ヘッドシークを抑えて取り出すことができる。

このようにして、ＭＭＴで送出された番組を、ＢＭＦＦ形式のファイルとして記録することが出来る。

実施の形態２．
実施の形態２では、ＭＭＴＰパケットを順次記録する。ＭＭＴＰパケットは、受信した放送を番組レベルで選別したものである。

１つの送信機から送信されるデータは、複数の放送局の複数の番組を多重化できるように作られている。そのため、ユーザーが特定の番組を視聴し、または録画する場合には、放送局のレベルでの分離と、番組のレベルでの分離とが必要となる。

ここでは、番組のレベルまでの分離が完了しており、録画の対象となる１つの番組を構成するＭＭＴＰが順次取り出されて、記録されているものとする。この状態は、部分的にデータの多重化が解除されている状態である。つまり、番組の単位までは多重化が解除されている。しかし、番組を構成する個々の映像、音声、字幕ストリームまたは制御データは多重化されている。

図１１は、ＭＭＴＰ方式でのＭＰＴによる多重化の解除を説明する説明図である。図１２は、タイムテーブルと映像データの関係を説明する説明図である。図１３は、ＭＭＴＰ方式でのＭＰＴデータの構造の例を説明する図である。図１４は、映像を中心に考えた場合のアライメントを説明する説明図である。

図１１に示したＭＭＴストリームは、番組を構成するＭＭＴＰパケット列の例である。このＭＭＴストリームでは、例えば、映像、音声および字幕などが、それぞれ一本ずつ多重化されている。実際の放送では、複数の映像、音声および字幕などが多重化されることもある。

映像、音声および字幕などは、番組を構成する要素である。これらの番組を構成する要素をアセットと呼ぶ。ＭＭＴストリームは、ＭＭＴＰパケットの単位で多重化されている。このため、ＭＭＴストリームには、サービスインフォメーションのパケットとアセットデータのパケットとが混在している。

サービスインフォメーションのパケットは、多重化ストリームのための制御信号である。サービスインフォメーションは、例えば、映像、音声または字幕を分離するための制御情報である。また、サービスインフォメーションは、映像、音声および字幕を同期して再生するための制御情報である。そして、サービスインフォメーションは、各アセットの名称を表示するための情報である。

アセットデータのパケットは、例えば、映像、音声および字幕のアセットを構成する。実施の形態２では、記録媒体の上にこれらのパケットを順次記録する。ここでは、簡単のため、ファイルとしてＭＭＴストリームを構成するこれらのパケットを順次記録することとする。

図１１に示すように、ＭＭＴストリームは、制御パケットＳＩ（ＭＰＴ）、映像パケットＶ、映像パケットＶ（ＲＡＰ）、音声パケットＡおよび字幕パケットＴを含んでいる。制御パケットＳＩ（ＭＰＴ）は、でＭＰＴの付いている制御パケットである。制御パケットＳＩ（ＭＰＴ）は、サービスインフォメーションの一種である。映像パケットＶ（ＲＡＰ）は、ＲＡＰフラグの付いている映像パケットである。

実際には、制御パケットＳＩとして多くの種類のものが送信されている。しかし、ここでは、説明を容易にするために、ＭＰＴに注目して記載してある。ＭＰＴは、放送規格では約１００ｍｓ間隔で定期的に送信することになっている。

ＭＭＴストリームを先頭から順次再生する場合には、ＭＭＴストリームを記録したファイルの先頭からデータを順次取り出す。そして、順次、ＭＭＴストリームを多重化解除部２１に送り込むことで、データの再生を行うことができる。例えば、図１に示す多重化ストリームＳｍとして多重化解除部２１に入力する。

多重化解除部２１は、受け取ったデータを順次解析する。多重化解除部２１は、ＭＰＴを含むデータパケットを受け取ると、ＭＰＴの記述にから多重化解除および映像を表示するタイミング等に用いる情報を取り出す。そして、多重化解除部２１は、多重化解除部２１およびデコード部３１，３２，３３，３４の設定を行う。

図１３に、ＭＰＴに記述されているデータの一例を示す。図１３に示すデータは、ＡＲＩＢ規格ＳＴＤ−Ｂ６０に基づいている。例えば、ＭＰＴには、複数のアセットを取りだすための情報が記述されている。各アセットは、ＭＭＴ内の識別情報によって、データを取得するための情報とデータを分離するための情報とを得る。ＭＭＴ内の識別情報は、例えば、ロケーション情報（ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（））である。

また、図１３では省略してあるが、コンポーネント記述子の情報から各アセットのストリームの詳細情報を得ることができる。この情報を基に、図１１に示したように、多重化されている各種ストリームを分離して、再生する。

放送を記録する場合にも、図１１のＭＭＴストリームのデータは、ファイルに順次記録される。そして、ＭＭＴストリームのデータは、ファイルの先頭から順次取出されて再生される。この場合には、必ずしも、ＭＭＴパケットそのものである必要はない。ＭＭＴパケットの内部のデータが取り出された状態で記録されてもよい。また、逆に、ＩＰパケットの状態またはＴＬＶパケットの状態で記録されてもよい。

次に、ランダムアクセスを考える。ここでは、一例として、時刻指定ジャンプを説明する。しかし、チャプターサーチおよび早送り巻き戻しなどでも同様である。

図１２を用いてランダムアクセスの動作について説明する。タイムテーブルＴＭは、番組上の時刻情報と、その時刻情報に対応する再生位置とを対応付けるデータである。再生位置は、ここでは、ＭＭＴストリームのデータを記録したファイルの先頭からのオフセットとして説明する。しかし、再生位置として、セクタアドレスまたはブロックアドレスなどが用いられることもある。

このタイムテーブルＴＭを用いて、時刻に対応した再生位置からデータを取り出して再生する。これによって、時刻指定ジャンプを行うことができる。つまり、時刻を指定した再生を行うことができる。

通常、映像データはＧＯＰ単位で構成されている。ＧＯＰは、例えば、０．５秒から１秒間程度の映像をまとめて圧縮したものである。ＧＯＰは、例えば、数十枚の画像を含んでいる。１つのＧＯＰは、１枚から複数枚の完全な画像と、数十枚の差分画像とを含んでいる。ＧＯＰは、圧縮された差分画像を含んでいるため効率が良い。

また、表示される順番とデコードされる順番とは、必ずしも対応していない。そのため、ＧＯＰの途中から再生したい場合でも、必ずＧＯＰ先頭からデータをデコードする必要がある。そのため、ＭＭＴＰパケットでは、ＧＯＰの先頭に、ＲＡＰフラグを付けることができる。ＲＡＰフラグは、ランダムアクセスが可能であることを示すフラグである。図１２では、このＲＡＰフラグの付いているパケットの位置を、ＧＯＰの先頭としてタイムテーブルに格納している。そして、これによって、ランダムアクセスを実現している。

１枚の画像データから完全な画像を再現できる画像データをＩピクチャと呼ぶ。Ｉピクチャは、１つのＧＯＰ内に必ず１つ存在する。しかし、１つのＧＯＰ内に複数のＩピクチャが存在することもある。Ｉピクチャのうち、他の画像との依存関係から、ＧＯＰ内で最初にデコードされるＩピクチャはＩＲＡＰと呼ばれている。このＩピクチャから再生することで、後続の画像データを正しく表示できる。

ＭＭＴＰパケットのＲＡＰフラグは、ＩＲＡＰの画像データの先頭パケットまたは制御パケットに付けられている。１つのＩピクチャとの差分データで構成された画像データはＰピクチャと呼ばれている。参照先のＩピクチャと、Ｐピクチャの画像データとを合成することで、このＰピクチャの画像を再現できる。複数の他の画像を参照して画像を再現できる画像データをＢピクチャと呼ぶ。

映像データと同様に、音声データでも一つのかたまりのデータの先頭の概念が存在する。そして、音声データの先頭にＲＡＰフラグが付けられている。しかし、説明を単純にするために、ここでは映像データのＧＯＰの区切りで音声データパケットも区切る。

図１２に示すランダムアクセスの動作を、図１１に示すパケットレベルでの読み出しに対応して考えてみる。

タイムテーブルＴＭから再生位置の情報を取出す。そして、図１１のＭＭＴストリームの位置Ｐ_１からパケットを取り出して再生を行う。位置Ｐ_１は、最初の映像パケットＶ（ＲＡＰ）の位置である。この時点では、ＭＰＴ情報が取得できていない。そのため、映像、音声および字幕などアセット単位での分離を行うことができない。

順次読み出しが行われて位置Ｐ_２で制御パケットＳＩ（ＭＰＴ）が読み出される。これによって、アセットを分離するためのパラメーターが取得される。つまり、映像、音声および字幕などを分離することができる。

この時、位置Ｐ_１から位置Ｐ_２までのデータが分離できず、結果として読まれなかった場合には、ＧＯＰの先頭のデータが失われることになる。そして、このＧＯＰをデコードすることができない。

位置Ｐ_３以降は、位置Ｐ_２で既に取得済みのＭＰＴ情報があるためデコードが可能となる。位置Ｐ_３は、位置Ｐ_１の次のＧＯＰの先頭である。そのため、本来、再生を開始したいＧＯＰからではなく、次のＧＯＰから再生されることがある。

同一の番組内でのチャプターサーチまたは早送り等の場合において、再生に使用していたＭＰＴのアセット情報がジャンプ先のＭＰＴのアセット情報と一致する場合には、ジャンプ先の先頭である位置Ｐ_１から始まるＧＯＰから再生することが可能である。しかし、コマーシャル（ＣＭ）または番組の変更などを挟んで番組を再生する場合には、ジャンプ前のＭＰＴとジャンプ後のＭＰＴとでアセットが同一である保証はない。または、録画済みの異なる番組を繋いだ編集がされている場合には、ジャンプ前のＭＰＴとジャンプ後のＭＰＴとでアセットが同一である保証はない。

また、アセットの変更が行われる場合には、放送規格案は、実際のデータが再生される０．５秒前からＭＰＴを更新するように求めている。これは、例えば、アセットを分離するためのフィルタの設定などには時間がかかる。また、音声が切り替わる時のミュート処理などには時間がかかる。また、映像が切り替わる時のミュート処理などには時間がかかる。これらのために、実際のデータが切り替わる直前のタイミングでＭＰＴを変更しても、フィルタの切り替え又はミュート等を行うための処理が間に合わない可能性があるためである。

これは、ランダムアクセスの時も同様である。ジャンプ先ですぐにＭＰＴを取得することができても処理系の切り替えが間に合わず、最初のＧＯＰを正しく表示できない可能性がある。または、データの切り替えに必要な時間を確保するために、表示を遅延させる必要がある。ここで、「処理系」とは、例えば、多重化解除部２１およびデコード部３１，３２，３３，３４等である。

そこで、この実施の形態２では、図１２に示したように、まず、ＭＰＴの情報をタイムテーブルＴＭ内に格納する。そして、時刻を指定してジャンプをする時には、ＭＰＴの情報を多重化解除部２１およびデコード部３１，３２，３３，３４に設定する。その後、再生を開始する位置のデータを読み出す。

このようにすることで、シークなどのデータの読み出しの準備と並行して、処理系（多重化解除部２１およびデコード部３１，３２，３３，３４等）の切り替えを行うことがでる。そして、データの切り替えに必要な時間を短縮することができる。

この例では、ＭＰＴそのものをタイムテーブルＴＭに格納している。他の方法として、ＭＰＴ内に記載されているアセットを分離するための情報と、ＧＯＰの表示開始の時刻とを、タイムテーブルＴＭに格納する。ＧＯＰの表示を開始する時刻をタイムテーブルＴＭの時刻として使用することもできる。このように、アセット情報を取出してタイムテーブルＴＭに格納する方法がある。

また、他の方法として、別のテーブルにＭＰＴまたはアセット情報を記録する。そして、タイムテーブルＴＭには該当するＭＰＴ情報またはアセット情報への参照を持たせる方法がある。また、参照ではなく、同一の時刻で検索できる別のタイムテーブルを用意して、そちらにＭＰＴまたはアセット情報を記録する方法がある。ＭＰＴには複数ＧＯＰの表示開始の時刻が格納されている。これらの一部またはすべてをタイムテーブルＴＭに格納しても良い。

同様に、ＨＤＲパラメーター等によってテレビの制御を変更する場合でも、バックライトの輝度の変更または液晶の駆動電圧の設定変更に時間がかかる場合がある。その場合には、ＨＤＲパラメーター等をタイムテーブルＴＭに格納する。これによって、事前にテレビの制御を行うことが可能となる。図１２では、タイムテーブルＴＭのメタデータ領域が、これらのパラメーターを格納する領域の一例として示されている。

特殊再生を行う場合には、ＧＯＰ内でＩＲＡＰ画像（ＩＲＡＰピクチャ）のみを再生して、他の画像を表示しない場合がある。特殊再生は、例えば、早送りまたは巻き戻し等である。ＩＲＡＰ画像は、デコードの順番で最初の画像である。また、ＩＲＡＰ画像は、データ配置の順番でもＧＯＰの先頭に置かれる。つまり、ＩＲＡＰ画像は、ＧＯＰの先頭に位置している。また、ＩＲＡＰ画像は、他の画像に依存しない。このため、ＩＲＡＰ画像は、単独でデコード可能である。この場合には、ＩＲＡＰ画像の位置は、タイムテーブルＴＭから読み取れる。

しかし、効率よく読み飛ばすためには、ＩＲＡＰ画像の末尾がわかる方が便利である。そこで、ＩＲＡＰ画像のサイズまたはＩＲＡＰ画像の末尾をタイムテーブルＴＭに格納する。これによって、効率よく特殊再生を行うことができる。図１２では、タイムテーブルＴＭのＩＲＡＰサイズ欄がこのデータを格納する領域の一例として示されている。

映像を構成する画像データがスライスとして記録されている場合には、スライス単位でデータにアクセスできた方が良い場合がある。「スライス」とは、画像データがデコード可能な状態で分割されていることである。特殊再生用として考えた場合には、例えば、ＧＯＰ内のＩＲＡＰ画像の特定のスライスのみを再生して、他のスライスを表示しない方法がある。特殊再生は、例えば、早送りまたは巻き戻しなどである。

この場合には、ＧＯＰの先頭にあるＩＲＡＰ画像のデータとスライスとの各々の位置およびサイズをタイムテーブルＴＭに格納するこれによって、効率よく特殊再生を行うこと可能となる。図１２では図示していないが、例えば、タイムテーブルＴＭのＩＲＡＰサイズ欄を拡張して、このデータを格納することができる。

早送り、巻き戻しをなめらかに行うために、ＩＲＡＰ画像に加えて、ＧＯＰに含まれている非ＩＲＡＰのＩピクチャまたは非ＩＲＡＰのＰピクチャを表示することもある。この場合には、ＩピクチャおよびＰピクチャの各々の開始位置、サイズまたは末尾の位置をタイムテーブルＴＭに格納する。これによって、効率よく特殊再生を行うことが可能となる。

図１２では図示していないが、例えば、タイムテーブルＴＭのＩＲＡＰサイズ欄を拡張して、これらのデータを格納することができる。または、別途、Ｉピクチャ用またはＰピクチャ用の位置、サイズまたは末尾の位置を示すテーブルを用意する。そして、タイムテーブルＴＭには、このテーブルへの参照を格納することもできる。

次に、ＨＤＤまたは光ディスク等のディスクデバイスに、この実施の形態２でのＭＭＴストリームを格納することを考える。

多くのディスクフォーマットでは、固定サイズのデータブロックをアクセス単位としている。このアクセス単位は、セクタ、ブロック、クラスタまたはページ等と呼ばれている。ここでは、単に「ブロック」と呼ぶ。例えば、ブルーレイディスク規格では６１４４Ｂｙｔｅをアラインドユニット（Ａｌｉｇｎｅｄ Ｕｎｉｔ）と呼び、１つの記録単位として取り扱う。また、ブルーレイディスク規格およびＵＤＦ規格では、１ブロック２０４８Ｂｙｔｅが良く使われる。ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）は、光ディスク用のファイルシステムである。

ランダムアクセスを行う場合には、データの境界をこのブロックに合わせることで効率よくアクセスする事ができる。また、ディスクデバイスの構造だけでなく、例えば、暗号化の単位としてブロックサイズが決められることもある。この場合でも、アクセスの単位としてブロック境界に合わせてデータにアクセスできると効率が良い。このようなアクセス効率などを考慮してデータのサイズまたはデータを格納する位置を決めることをアライメントと呼ぶ。

トランスポートストリーム（ＴＳ）を記録する場合には、３２個のＴＳパケットが接続されて、６１４４Ｂｙｔｅのデータとなる。ＴＳパケットは、１９２Ｂｙｔｅである。これによって、ＵＤＦの３つのブロックに効率よく記録できる。ＵＤＦの１つのブロックは、２０４８Ｂｙｔｅである。ＭＭＴＰパケットは、可変長パケットである。このため、単純にパケットの数でブロックの境界に合わせることができない。

図１２で示したように、ランダムアクセスを行う場合には、ＧＯＰの先頭へのアクセスを効率的に行うことが望ましい。しかし、ＧＯＰ内のどの画像から再生する場合でも、ＧＯＰの先頭からデータを読み出す必要がある。そこで、ＧＯＰ単位でブロックの境界に合わせて記録することを考える。

図１４（Ａ）に、ＧＯＰをデータアクセスの単位として、ＧＯＰの先頭がブロックサイズの整数倍になるようにしたＭＭＴストリームを記録したファイルの一例を示す。

図１４（Ａ）は、ＭＭＴストリームを記録したファイルのデータの一部を示している。図１４（Ａ）の左側がファイル前方に、右側がファイル後方に対応している。ＭＭＴストリームのパケットは、例えば、図１４（Ａ）の左側から右側に向けて順次記録されている。図１４（Ａ）は記録されているデータの一部のみを記載している。実際には、このデータ構造が多数繰り返して記録されている。

図１４（Ａ）中の符号Ｂｂはブロック境界を示している。また、「ｎ１」、「ｎ２」、「ｎ３」、「ｎ４」、「ｎ５」および「ｎｍ」は整数を示している。「ｍ」は正の整数である。「×」は乗算を示している。そのため、「ブロック×ｎ」は、データがブロックサイズの整数倍になっている事を示している。

ＧＯＰの先頭がブロックの境界となるようにアライメントする場合には、ＧＯＰのデータサイズが必ずしもブロックサイズの整数倍とならない。このため、図１４中のパディング（Ｐａｄ）を用いる。「パディング」とは、データをアライメントするために、意図的に無効領域を作ることである。パディングにはいくつかの方式がある。例えば、１つとして、無効を示すデータを記録する方式である。また、他には、ＯＳまたはファイルシステムが無効なデータ領域を管理する方式などがある。

図１４（Ａ）の例では、ＧＯＰ単位でブロックにアライメントしている。このため、ＧＯＰ単位でのランダムアクセスを効率よく行うことができる。なお、この例では、映像データについてのみ説明を行っている。しかし、実際には、図１１に示すように、映像データ、音声データおよび字幕データなどが多重化され混在している。

そのため、映像データの区切り位置でストリームデータを分割した場合には、映像以外の音声データまたは字幕データに関しては、適切な区切り位置で分割されるとは限らない。そのため、ランダムアクセス時に音声または字幕が遅れて再生される可能性がある。通常、音声または字幕の再生が遅れても、映像とのずれが発生しなければ問題とならない。このため、ここでは、映像の区切り位置を基に、他のデータも一固まりのデータとして取り扱う。

図１４（Ｂ）は、画像単位でアライメントしたＭＭＴストリームを記録したファイルの一例を示す。図１４（Ｂ）では、ピクチャ（ＡＵ）とパディングとの組み合わせがブロックの整数倍となっている。この場合には、画像単位でのアクセスが必要な時に効率が良い。

ＡＵは、圧縮データの意味のある固まりの1種である。画像（ピクチャ）データの場合には、１枚分の画像である。つまり、ＡＵは、ＩＲＡＰピクチャ、Ｉピクチャ、ＰピクチャまたはＢピクチャのいずれかになる。

この図１４（Ｂ）では、画像の単位ですべてのアライメントを行った。しかし、ランダムアクセスの時に重要になるのはＩＲＡＰピクチャである。ＩＲＡＰピクチャは、ＧＯＰの先頭に置かれる。そのため、ＩＲＡＰピクチャとそれ以外のピクチャをまとめたものとの２つに分けてアライメントを行うこともできる。

図１４（Ｃ）に、ＩＲＡＰピクチャの先頭、Ｉピクチャの先頭およびＰピクチャの先頭をブロック境界にアライメントを行った。図１４（Ｃ）は、Ｉピクチャを「Ｉ」と示し、Ｐピクチャを「Ｐ」と示し、Ｂピクチャを「Ｂ」と示す。早送りまたは巻き戻しなどの場合に、ＩＲＡＰピクチャだけではなく、ＩピクチャまたはＰピクチャ等を利用する場合に効率が良い。この図１４（Ｃ）では、ＩＲＡＰピクチャの先頭、Ｐピクチャの先頭または非ＩＲＡＰのＩピクチャの先頭でアライメントを行っている。しかし、Ｐピクチャ先頭またはＩピクチャ先頭でのアライメントを省略しても良い。

図１４（Ｄ）に、スライス単位でアクセスすることを考えてアライメントを設定したＭＭＴストリームを記録したファイルの一例を示す。映像がスライス構成となっている場合には、スライス単位でのアクセスを効率よく行うことができる。

図１４（Ｄ）で、画像（ピクチャ）データの最初には、非ＶＣＬデータが記載されている。非ＶＣＬデータは、ＡＵＤ、ＶＰＳまたはＳＰＳなどのパラメーター類である。後続のスライス＃１からスライス＃４は、ＶＣＬデータである。ＶＣＬデータは、圧縮された画像データである。

スライス単位でデコードを行う際にも、非ＶＣＬデータは各々のスライスをデコードする際に必要となる。例えば、スライス＃２をデコードする際には、非ＶＣＬデータとスライス＃２のデータとを組み合わせてデコードする。そのため、ここでは非ＶＣＬデータと、スライス＃１からスライス＃４とでそれぞれアライメントを行っている。

実際には、非ＶＣＬデータは各スライスと比べて非常に小さいことが多い。また、スライス＃１のデコードを行う前には、非ＶＣＬデータを必要とする。このことから、非ＶＣＬデータとスライス＃１とをまとめてアライメントを行うことも考えられる。

スライス単位でのアライメントは、必ずしも全てのピクチャで行う必要はない。例えば、ＩＲＡＰピクチャのみをスライス単位でのアライメントに用いることも考えられる。なぜなら、ＩＲＡＰピクチャは、サイズの大きく、ランダムアクセスに用いられるからである。

ＭＭＴＰパケット単位でアライメントする方法も考えられる。ＭＭＴＰパケットは、規格によってデータ量が異なる。例えば、放送規格案でのＭＭＴＰパケットの最大値は、約１５００Ｂｙｔｅである。

例えば、２０４８Ｂｙｔｅブロックを想定してアライメントを行った場合には、全データ量に占めるパディングの量が大きくなる。そして、記録効率が悪くなる。

一方、パケット単位でのアクセスは効率よく行える。つまり、ＭＭＴＰパケット単位でのアライメントは、パケット単位でのデータ加工が必要となる場合などの一時的なデータの格納に適している。パケット単位でのデータ加工は、例えば、記録再生時または編集時などに行われる。

タイムテーブルＴＭおよびアライメントを用いることによって、時刻を指定したデータの再生を効率よく行うことができる。

ブルーレイディスクでは、この実施の形態２のタイムテーブルＴＭに相当する仕組みとして対応表（ＥＰマップ、ＥＰ＿ｍａｐ）を持っている。このＥＰマップは、再生位置をシステムクロックとＴＳパケットの位置とで示している。再生位置は、ＰＴＳ（表示開始の時刻）とそのデータとを読み出すための位置である。

ＥＰマップは、時刻を指定したジャンプ、ランダムアクセスまたはプレイリストによる再生などに用いられている。ランダムアクセスは、例えば、早送りまたは巻き戻しなどである。プレイリストは、ストリームの再生部分と再生順とを決めたリストである。

ブルーレイディスクのＥＰマップでは、時刻および再生位置のデータ形式がＭＭＴの場合とは異なっている。しかし、時刻を指定して再生位置のデータを取得する仕組みはこの実施の形態２で説明したタイムテーブルＴＭを用いる場合と同じ考え方である。

タイムテーブルＴＭをＥＰマップと類似の構造とすることによって、これら再生の仕組みを大幅に変更することなく、ブルーレイディスクにＭＭＴ形式の放送を記録し再生することができる。

例えば、ＭＭＴの再生の時刻形式は、放送時の絶対時刻（世界時刻）である。一方、ブルーレイディスクのＥＰマップでは、内部クロックを用いた相対時刻である。そこで、タイムテーブルＴＭの時刻の表記を相対時刻の表記に換算する。または、絶対時刻と相対時刻との換算用のデータを別途持たせる。または、ブルーレイディスクで使用する再生の時刻情報を、絶対時刻の形式に変更する。

実施の形態３．
日本の新しい放送方式では、多重化方式およびエンコード方式が変更されている。また、日本の新しい放送方式では、伝送レートも引きあげられている。例えば、ＡＲＩＢ ＴＲ Ｂ−３９によると、４Ｋ放送では３５Ｍｂｐｓの伝送レートが想定され、８Ｋ放送では１００Ｍｂｐｓの伝送レートが想定されている。

一方、現在市販されているＢＤＸＬ（登録商標）のディスクでは、光ディスクの伝送レートは、１４０Ｍｂｐｓ前後である。

そのため、８Ｋ放送を録画したディスクを再生する場合には、通常の再生では問題がなく、再生可能である。しかし、８Ｋ放送を録画したディスクで早送りなどの特殊再生を行うと、１コマ分の画像を表示するのに時間がかかってしまうという問題がある。

特開２０００−１２５２５９には、記録媒体の記録領域を所定のデータサイズに分割し、記録時にストリームを解読して、Ｉピクチャであることを表すＰＣＴ(ピクチャタイプコード)を含むＴＳパケットを、セクタの先頭から記録すると共に、そのセクタの先頭アドレスを示すポインタを、記録媒体上に設けたテーブルに登録する。そして、この様に記録した記録媒体を用いた早送り、早戻し等の特殊再生動作は、ポインタテーブルからポインタアドレスを読み出し、そのポインタが示すセクタから一枚のＩピクチャのみを再生し、その後次々とポインタが示すセクタを順次再生することが記載されている。

このように、早送りなど特殊再生を行う際には、Ｉピクチャのみを再生する方法が取られる事が多い。Ｉピクチャは、映像ストリームのランダムアクセスポイントにある。早送り速度に応じて、通常の早送り（ＦＦ、Ｆａｓｔ Ｆｏｗａｒｄ）では、全てのＩピクチャを表示する。また、２倍速の早送り（ＦＦ×２）では、Ｉピクチャを１つ飛ばしで表示する。また、３倍速の早送り（ＦＦ×３）では、Ｉピクチャを２つ飛ばしで表示する。このようにして、早送り時の再生速度の調整を行う。

しかしながら、ＧＯＰ内でのＩピクチャの比率が大きい場合には、Ｉピクチャの読み出しに時間がかかり、画像（Ｉピクチャ）の更新間隔が長くなる。

実施の形態３に係る映像再生装置は、特殊再生の際に、Ｉピクチャの読み出し時間を短くし、画像（Ｉピクチャ）の更新間隔を短くすることができる。

従来の早送り再生では、再生可能なＩピクチャのディスク上の位置をテーブルで管理している。そして、そのテーブルを用いて、順次、Ｉピクチャのデータを読み出している。

光ディスクでは、読み出し位置を変更する際には、ヘッドの移動に時間が必要である。このヘッドの移動時間をシークタイムと呼ぶ。

画面上での早送り画像の更新間隔は、次の式１ようになる。
更新間隔 ＝ シークタイム＋Ｉピクチャデータの読み出し時間＋デコード時間 ・・・（１）

そのため、ＧＯＰ内でのＩピクチャの比率が大きい場合には、Ｉピクチャの読み出しに時間がかかり、画像（Ｉピクチャ）の更新間隔が長くなる。４Ｋ／８Ｋ放送では、圧縮効率の良いＨＥＶＣ圧縮方式を採用している。そのため、従来の画像圧縮方式よりもＩピクチャの比率が大きい。

また、映像ストリームのデータレートとディスクからの最高読み出し速度との差が少ない場合にも、Ｉピクチャの読み出し時間が長くなり、画像の更新間隔が長くなる。例えば、１００Ｍｂｐｓの放送ストリームを最高読み出し速度１４０Ｍｂｐｓの光ディスクから読み出す場合には、１．４倍の速度でしか読み出す事ができない。

このように、４Ｋ／８Ｋ映像を光ディスクに記録した場合には、特殊再生時の画像の更新間隔が従来よりも長くなる。その一方で、放送を記録した映像の再生時には、早送りなど特殊再生の操作が行われる事が多い。そして、利用者が目的のシーンを特定する際には、画像の更新間隔は短い方が望ましい。

そのため、画像の更新間隔が長いと、利用者が早送りを使ってシーンを検索する際に、目的のシーンを見つける事が難しくなってしまう。

この実施の形態３では、早送り再生などの特殊再生の際に、目的のシーンを見つける事が容易で、操作性の良い映像再生装置を提供する事を目的としている。

利用者の観点から早送り時の画像の更新間隔について整理する。例えば、本来の再生時間が１００秒の映像を１０秒で再生する早送りを考える。ここでは仮に１０倍速早送りと呼ぶ。

通常、利用者は早送り中の映像を確認して、目的のシーンが現れた時点で早送り解除する。つまり、通常の再生速度に戻す。早送り再生の時には、表示される映像は間欠的な映像となる。しかし、表示されるシーンを利用者が認識するには、時間的な情報の欠落は少ない方が容易である。また、早送り操作が終了した後、早送りが解除されて通常再生に戻る位置のずれも少なくできる。

例えば、１０倍速早送りに対して考える。早送り中の画像の更新間隔が１秒であれば、通常の再生時間の１０秒に対して１コマ表示される。これに対して、早送り中の画像の更新間隔が０．５秒であれば、通常の再生時間の５秒に対して１コマが表示される。

早送り再生の際に、利用者が目的のシーンを見つけるためには、通常の再生時間当たりから抜き出されるコマ（画像）数が多い方が有利である。このように、早送り再生時に、多くの画像を表示することによって、操作性を向上させる事ができる。つまり、更新間隔を短くすることによって、操作性を向上させる事ができる。

４Ｋ／８Ｋ放送では、分割デコードを想定して、複数のスライスセグメントを持ったストリーム形式を規定している。

例えば、１つの画像を４分割する場合には、縦と横とに２分割（以下、田の字型ともよぶ。）して４分割の画像を作成する。または、１つの画像を縦方向に４分割（以下目の字型ともよぶ。）する。そして、それぞれのスライスセグメント単位で、独立してデコードできるようになっている。これは、２Ｋ用のデコーダーを４つ用いて４Ｋ映像のデコードを行い、４Ｋ用のデコーダーを４つ用いて８Ｋ映像のデコードを行えるようにするための配慮である。

これらの複数のスライスセグメントを持つ放送ストリームを光ディスクに記録した場合には、スライスセグメント単位でデータを読む出す事が出来れば、一部のスライスセグメントだけを再生することが可能である。

これを特殊再生時に使用すれば、更新される画像は通常の再生で表示されている画像の一部になる。しかし、式（１）の「Ｉピクチャデータの読み出し時間」を４分の１にすることができる。そして、特殊再生時の画像の更新間隔を短縮することができる。

図１５は、実施の形態３に係る映像ストリームの模式図である。

多重化方式としてはＴＳ方式およびＭＭＴ方式の両方が考えられる。しかし、図１５では、固有のヘッダ情報などを省略している。また、パディング等も省略している。

放送の場合には、１つのＧＯＰは約６０フレーム（画像またはピクチャ）まで含む事ができる。そして、１つのＧＯＰの中に、少なくとも１つのＩピクチャを含む。特に、デコードの際に開始点となるＩピクチャはＩＲＡＰピクチャ（ＩＲＡＰ画像）と呼ばれる。そして、データ順では、通常、ＩＲＡＰピクチャはＧＯＰの先頭に配置されている。

Ｉピクチャ（ＩＲＡＰピクチャを含む）、ＢピクチャおよびＰピクチャは、それぞれフレーム（画像またはピクチャ）を表す。

Ｉピクチャは、単独でデコード可能な独立した画像を示す。一方、ＢピクチャおよびＰピクチャは、他の画像に依存している。ＢピクチャおよびＰピクチャは、他の画像との差分データである。このため、ＢピクチャおよびＰピクチャは、単独ではデコードすることができない。

ＧＯＰは、ＧＯＰの中で画像間の依存関係が完結している。つまり、ＧＯＰ内のすべての画像は、デコード可能となるデータのセットを構成している。

１つの画像が複数のスライスセグメントで構成されている場合には、それぞれの画像はパラメータセットと複数のスライスセグメントとで構成されている。パラメータセットと１つのスライスセグメントとを組み合わせる事で、スライスセグメントはデコード可能な単位となる。図１５では、ＩＲＡＰピクチャのみスライスセグメントの構造で記載している。しかし、ＢピクチャおよびＰピクチャも、同様の構造を取ることができる。

デコーダーを４つ用いて並列でデコードする場合には、スライスセグメントごとにデータを取り出す。そして、それぞれのデータにパラメータセットを追加する。その後、それぞれのデータを個々のデコーダーに与える事によって、１つの画像を分割された状態でデコードすることができる。画像を表示する際には、個別にデコードされた画像を結合し、１つの画像にして表示する。

図１６には、縦横に４分割（田の字型）した例を示す。画像の左上には、スライス＃１の画像が表示されている。画像の右上には、スライス＃２の画像が表示されている。画像の左下には、スライス＃３の画像が表示されている。画像の右下には、スライス＃４の画像が表示されている。

図１７には、縦方向に４分割（目の字型）した例を示す。画像の上から１番上には、スライス＃１の画像が表示されている。画像の上から２番目には、スライス＃２の画像が表示されている。画像の上から３番目には、スライス＃３の画像が表示されている。画像の上から４番目には、スライス＃４の画像が表示されている。

なお、分割されていない映像ストリームの場合には、１つのピクチャデータ内にスライスセグメントが１つだけ存在している。

このような分割されたスライスセグメント構造を持った映像ストリームでの特殊再生を考える。

前述の通り、操作性を向上させるためには、表示画像の更新間隔を短くする必要がある。従来では、Ｉピクチャ全体のデータを読み込み、Ｉピクチャ全体を表示していた。しかし、Ｉピクチャの第１スライスセグメント（スライスセグメント＃１）のデータのみを読み込み、Ｉピクチャの第１スライスセグメント（スライスセグメント＃１）のみを表示する事を考える。

図１８は、分割スライスセグメントの単位での読み出しに対応したタイムテーブル（ＴＭＳ）の一例である。図１９は、タイムテーブル（ＴＭＳ）の各項目とデータ上との対応を示している。映像ストリームを記録する際に、映像ストリームの解析を行う。そして、時刻情報またはデータ区切り位置の情報などを取出してタイムテーブル（ＴＭＳ）を作成する。

なお、タイムテーブルとして符号ＴＭと符号ＴＭＳとの２種類を用いている。分割スライスセグメントに対応したタイムテーブルを符号ＴＭと区別して符号ＴＭＳを用いている。タイムテーブルは、映像ストリームと一緒に記録メディアに記録される。記録メディアは、例えば、光ディスクなどである。

タイムテーブル（ＴＭＳ）の各項目について説明する。

「時刻」は、各時刻の行が示すＧＯＰの表示時刻である。時刻は、システムクロック形式の時刻情報、ｎｔｐ形式の時刻情報またはストリームの先頭からの差分時間などの形で記録されている。時間を指定して再生を開始する場合には、この時刻欄を検索し、指定時間の近傍のデータから再生を開始する。

なお、「時刻」は、ここではＧＯＰの表示時刻とした。１つのＧＯＰには、通常、複数の画像が含まれている。そして、それぞれの画像の表示時刻があるため、ＧＯＰには表示時刻が複数存在する。ＧＯＰの表示時刻としてタイムテーブルに記録する場合には、ＧＯＰ内での表示の順番で先頭になる画像の表示時刻を使用することができる。または、デコードの順番で先頭になる画像の表示時刻を使用することができる。この場合には、先頭になる画像は、ＩＲＡＰピクチャになる。

また、タイムテーブルに格納する「時刻」は、必ずしも、画像の表示時刻に一致する必要はない。例えば、画像の表示時刻そのものではなく、精度を落とした時刻情報または他のデータに対する時刻情報などを用いることができる。これらは、例えば、再生装置のシステムクロックの精度、データアクセスとの関係またはタイムテーブルに格納可能なデータ長などが考慮される。

「ＩＲＡＰ開始位置」は、ＩＲＡＰピクチャの格納位置である。ＩＲＡＰピクチャの格納位置は、ＧＯＰのランダムアクセスポイントとなる。ＩＲＡＰピクチャの格納位置は、通常、ＧＯＰの開始位置と同一となる。「ＩＲＡＰ終了位置」は、ＩＲＡＰピクチャ全体のデータ末尾を示す。ＩＲＡＰ開始位置からＩＲＡＰ終了位置までのデータを読み出すことによって、ＩＲＡＰピクチャをデコードできるデータがそろう。

「＃２開始位置」は、２つ目のスライスセグメント（スライス＃２）の開始位置を示す。また、「＃２開始位置」は、１つ目のスライスセグメント（スライス＃１）の終了位置を示す。「＃３開始位置」は、３つ目のスライスセグメント（スライス＃３）の開始位置を示す。また、「＃３開始位置」は、２つ目のスライスセグメント（スライス＃２）の終了位置を示す。「＃４開始位置」は、４つ目のスライスセグメント（スライス＃４）の開始位置を示す。また、「＃４開始位置」は、３つ目のスライスセグメント（スライス＃３）の終了位置を示す。「＃４終了位置」は、４つ目のスライスセグメント（スライス＃４）の終了位置を表す。通常、この位置はＩＲＡＰピクチャの終了位置と同じである。

「パラメータセット」には、ＩＲＡＰピクチャのデータのパラメータセットが格納されている。パラメータセットには、例えば、ＡＵＤ（Ａｃｃｅｓｓ Ｕｎｉｔ Ｄｅｌｉｍｉｔｅｒ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）またはＥＯＳ（Ｅｎｄ ｏｆ Ｓｔｒｅａｍ）などが含まれている。

図１９に示したタイムテーブル（ＴＭＳ）では、スライスセグメントの終了位置を格納している。例えば、ＩＲＡＰピクチャの終了位置とスライス＃４の終了位置とである。しかし、終了位置の代わりにデータサイズをテーブルに格納し利用する方法を取ることもできる。

開始位置および終了位置は、データの先頭からのバイト位置またはブロック位置などの形で記録されている。また、多重化方式にＴＳを採用している場合には、開始位置および終了位置は、ＴＳパケットの位置などの形で記録されている。開始位置および終了位置は、データを読み出すのに必要な位置として記録されている。

セグメントのデータ位置を示す情報に関しては、ＧＯＰの先頭からの相対位置とすることができる。これによって、位置情報のデータサイズを小さくする事が出来る。

光ディスクでは、ある程度まとまったデータ単位でデータの読み込みを行う。このため、位置に関しては必ずしも厳密である必要はない。位置を示す単位を大きくして、位置情報のデータ量を削減することも可能である。

この例では、単一のタイムテーブルにスライスセグメントに関する情報も記録している。しかし、スライスセグメント情報を別のテーブルに格納することも可能である。この場合には、タイムスタンプ情報またはテーブル内でのエントリー位置などで、同一のＧＯＰおよびＩＲＡＰピクチャに関する情報を取り出せるようにしておく。

パラメータセットを、さらに別テーブルに格納する方法も考えられる。なぜなら、パラメータセットは、位置情報に比べるとサイズが大きいからである。また、パラメータセットは、画像によってデータ長が変化するからである。

Ｉピクチャのスライスセグメント＃１のみを用いて早送り再生を行う場合には、タイムテーブルで必要な情報は時刻、ＩＲＡＰ開始位置および＃２開始位置である。この場合には、＃２開始位置はスライスセグメント＃１の終了位置として利用される。

図２０を用いてスライスセグメント＃１のみを用いた早送り再生の説明を行う。ＧＯＰ（０１）からＧＯＰ（０６）までは、ストリームデータである。本来、ストリームデータは一続きのデータファイルである。しかし、説明を容易にするため、ＧＯＰ単位で行を変えて表わしている。ＴＭＳは、前述のタイムテーブルである。ＴＭＳ（タイムテーブル）は、時刻情報と画像データの位置を対応付けている。

なお、ＩＲＡＰ開始位置と＃１開始位置とは、同じ値としてタイムテーブル上で兼用している。必要な値は、スライス＃１の開始位置と終了位置である。ＩＲＡＰ開始位置を＃１開始位置とみなし、＃２開始位置を＃１終了位置とみなしている。

早送り再生の場合には、タイムテーブルのエントリーを順次読み出す。それぞれのＧＯＰのＩＲＡＰ開始位置と＃２開始位置とから、このＧＯＰのＩピクチャの１つ目のスライスセグメントのデータを読み出す。そして、このデータをデコードし、画面に表示する。ＩＲＡＰ開始位置は、スライスセグメント＃１の開始位置である。＃２開始位置は、スライスセグメント＃１の終了位置である。

これを繰り返す事によって、早送り再生を行うことができる。この場合には、Ｉピクチャを全て表示する場合に比べて、読み出しデータ量が４分の１になっている。このため、早送り再生時の画像の更新間隔を短くする事ができる。

この例の場合には、表示が更新されるのは画面の一部である。つまり、１つ目のスライスセグメントの位置の画像のみ表示される。縦横４分割（田の字型）の場合には、例えば、画像の左上の４分の１の領域である。縦方向４分割（目の字型）の場合には、画像の上部４分の１の領域である。他の部分は更新されないまま残る。または、他の部分は表示されない状態である。

利用者が早送り操作を行う場合には、目的のシーンを判別できればよい。そのため、画面全体が見える事よりも、更新間隔の短い方が操作性を考慮すると良い場合も多い。

また、同じ方法で、１つ目のスライスセグメントと２つ目のスライスセグメントの２つとを表示する。このようにすれば、画面の半分を表示して早送りを行うこともできる。

さらに、高速で早送り再生を行う場合には、表示するＧＯＰを間引きして再生することができる。つまり、ＧＯＰを１つ飛ばし又は２つ飛ばし等で表示する。

早送り再生の操作では、リモコンの早送りボタンを複数回押す事で早送り速度を調整する事が出来るものが多い。従来のＩピクチャ全体を表示する早送りと組み合わせて使う場合には、リモコンボタンを押す回数によって表示方式を選択することができる。

例えば、ボタンを１回押すと、全てのＧＯＰのＩピクチャの全体を表示して早送り再生を行う。ボタンを２回押すと、全てのＧＯＰのＩピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。ボタンを３回押すと、ＧＯＰを１つ飛ばしして、Ｉピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。ボタンを４回押すと、ＧＯＰを２つ飛ばしして、Ｉピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。

放送ストリームが複数のスライスセグメントを持たない場合には、この方法を使うことができない。しかし、放送を記録する際に、再圧縮またはフォーマット変換を行うことも多い。その際に、複数のスライスセグメントを持つＨＥＶＣ映像ストリームとして再構成する事も可能である。放送以外の外部入力の映像を記録する場合でも、同様に、複数のスライスセグメントを持つＨＥＶＣ映像ストリームとして圧縮データを作成する事で、この方法による特殊再生を行う事ができる。

＜変形例１＞
これまでの説明では、早送りなど特殊再生時に画像の一部のみの更新でも良いとした。しかし、画像の全体が更新された方が目的のシーンを見つけやすいことも考えられる。そこで、読み出すデータは一部スライスセグメント分としながら、画像の全体を更新する方法を考える。

図２１は、早送り再生の説明図である。この例では、タイムテーブル（ＴＭＳ）の中の全てのスライスの位置情報を利用している。

早送り再生の場合には、タイムテーブルのエントリーを順次読み出す。最初のＧＯＰのＩＲＡＰ開始位置と＃２開始位置とから、このＧＯＰのＩピクチャの１つ目のスライスセグメントのデータを読み出す。ＩＲＡＰ開始位置は、スライスセグメント＃１の開始位置である。＃２開始位置は、スライスセグメント＃１の終了位置である。このデータをデコードして、画面のスライスセグメント＃１の位置に表示する。図２１では、画面のスライスセグメント＃１の位置は、画面の左上である。

次のＧＯＰの＃２開始位置と＃３開始位置とから、このＧＯＰのＩピクチャの２つ目のスライスセグメントのデータを読み出す。＃２開始位置は、スライスセグメント＃２の開始位置である。＃３開始位置は、スライスセグメント＃２の終了位置である。このデータをデコードして、画面のスライスセグメント＃２の位置に表示する。

この時、スライスセグメント＃２のデコードには、このピクチャのパラメータセット（ＰＳ）のデータが必要になる。パラメータセット（ＰＳ）は、ピクチャ先頭に配置されている。つまり、パラメータセット（ＰＳ）は、スライスセグメント＃１の前に配置されている。このため、パラメータセット（ＰＳ）をスライスセグメント＃１と同時に読み込む場合には、１度に読み込める。しかし、パラメータセット（ＰＳ）とスライスセグメント＃２とを読み込む場合には、２回の読み込みが発生する。

光ディスクの読み出し動作では、読み出し位置の変更に時間がかかる。そのため、この時の読み込み動作としては次の３つの方法が考えられる

１つ目の方法は、パラメータセット（ＰＳ）とスライスセグメント＃２との２回の読み込み動作を行う。２つ目の方法は、パラメータセット（ＰＳ）、スライスセグメント＃１およびスライスセグメント＃２を一度に読み込む。３つ目の方法は、パラメータセット（ＰＳ）とスライスセグメント＃２のデータとを使用する。そして、タイムテーブルを作成する時に、Ｉピクチャのデコードに必要なパラメータセット（ＰＳ）のデータのコピーをタイムテーブルに格納する。

この説明では、３つ目の方法を説明している。つまり、タイムテーブル内にパラメータセット（ＰＳ）のデータのコピーが格納されているものとして説明している。この場合には、タイムテーブルに格納されていたパラメータセット（ＰＳ）のデータとスライスセグメント＃２のデータとをデコーダーに入力して、デコードを行う。

次のＧＯＰでは、同様にスライスセグメント＃３のデータを取り出し、画面上のスライスセグメント＃３の位置の画像を更新する。図２１では、画面上のスライスセグメント＃３の位置は、画面の左下である。

このように画像の更新のたびに、表示するスライスセグメントをずらしていく事によって、一回の更新では画像の一部の更新ではあっても、数回の画像の更新によって画面全体を更新することができる。画面の位置によって、異なる時刻の画像が表示される。スライスセグメントごとに、異なる時刻の画像が表示される。しかし、一部分の画像の表示に比べると、シーンの把握が容易になる。つまり、より操作性の良い特殊再生を実現することができる。

この説明では、１つのスライスセグメントで画像の更新を行った。しかし、１つのＧＯＰで複数のスライスセグメントの画像を更新することができる。例えば、画像の半分ずつを交互に更新する事もできる。

上記の説明では、スライス番号の順にスライス＃１、スライス＃２、スライス＃３、スライス＃４の順番で画像の更新を行った。画像の更新は、必ずしもスライス番号の順である必要はない。再生時に任意の順番とすることができる。

図２２に画像の更新の順番の例を示す。図２２（１）は、スライス＃１、スライス＃２、スライス＃３、スライス＃４の順で画像を更新する例である。図２２（２）は、スライス＃１、スライス＃２、スライス＃４、スライス＃３の順で画像を更新する例である。図２２（２）は、時計回りで画像を更新している。図２２（３）は、スライス＃１、スライス＃４、スライス＃３、スライス＃２の順で画像を更新する例である。図２２（４）は、スライス＃１、スライス＃３、スライス＃４、スライス＃２の順で画像を更新する例である。図２２（４）は、反時計回りで画像を更新している。

再生の時に表示するスライスセグメントを選択できる場合には、早送り再生時と巻き戻し再生時とで、画像を更新する順番を逆にすることもできる。例えば、早送りの場合には、図２２（２）の時計回りとし、巻き戻しの場合には、図２２（４）の反時計回りとする。このように、早送りと巻き戻しとで画像の更新の順番を逆にすることによって、早送りの操作と巻き戻しの操作とを繰り返した場合でも、現在の状態の把握が容易になり、操作性が向上する。

図２３は、縦方向に４分割（目の字型）の場合の例である。この場合にも、画像の更新の順番を逆にすることで、早送りと巻き戻しとの把握が容易になる。例えば、早送りをスライス＃１からスライス４に向けて更新する（図２３（１））。そして、巻き戻しをスライス＃４からスライス１に向けて更新する（図２３（２））。

＜変形例２＞
前記の説明では、タイムテーブルに全てのスライスセグメントへの読み出し位置情報を格納していた。タイムテーブルのサイズを小さくするために、一部のスライスセグメントの読み出し位置情報だけを記録する方法も考えられる。

図２４では、１つのスライスセグメントの読み出し位置情報を格納したタイムテーブル（ＴＭＳ）を示している。

この例では、タイムテーブルの各時刻に対応するスライスセグメントの読み出し位置の情報を格納している。例えば、ＧＯＰ（０１）とＧＯＰ（０５）とに対応する行には、スライスセグメント＃１の読み出し位置情報が格納されている。図２３では、例えば、ＧＯＰ（０１）の情報はタイムテーブルの１行目に記載されている。また、ＧＯＰ（０５）の情報はタイムテーブルの５行目に記載されている。

ストリームを記録する際に、記録するＧＯＰを順次カウントする。そして、このＧＯＰのカウント値を１つの画像中のスライスセグメント数で割った余り（剰余）を取る。図２４では、１つの画像中のスライスセグメント数は４である。この値（剰余）に１を足した値をスライスセグメントの値とする。そして、そのスライスセグメントの位置をタイムテーブルに記録する。

この例では、各時刻のスライス開始位置とスライス終了位置とには情報が記載されている。スライスの順番は、スライス＃１、スライス＃２、スライス＃３、スライス＃４の順番である。なお、図２４では記載を省略しているが、ＩＲＡＰ開始位置およびＩＲＡＰ終了位置なども記録する。他の特殊再生または従来のＩＲＡＰ画像全体の表示との互換のためである。

このタイムテーブルを用いて早送りなどの特殊再生を行う場合には、ＧＯＰを飛ばさずに早送りを行うと、画面全体が更新される。また、例えば、ＧＯＰを１つずつ飛ばして再生すると、スライス＃１とスライス＃３とが更新される。また、例えば、ＧＯＰを３つずつ飛ばしで再生すると、スライス＃１が更新される。

早送りの倍速にかかわらず、画像の全体を更新するためには、タイムテーブルに読み出し位置情報を格納する際に、乱数または疑似乱数などを用いてスライスセグメントを選択することもできる。この場合には、画面上で更新されるスライスセグメントは不規則である。しかし、早送りの倍数などによらず、画像全体を更新することができる。

疑似乱数の生成手段としては、例えば、Ｍ系列を用いた線形帰還シフトレジスタなどが挙げられる。

Ｍ系列を用いた疑似乱数生成では、値数および回数を指定して、各値の出現確率が一様で指定回数の間に周期性の無いデータ列を生成することができる。値数は、例えば、１から４の４値である。回数は、例えば、１０００回である。

例えば、これらの疑似乱数の生成手段を用いてタイムテーブルを作成すれば、タイムテーブルの中で同じパターンの繰り返しが発生しないように、スライスセグメントを選択することができる。これによって、早送りの倍速を変更した場合でも、特定のスライスセグメントだけが更新されることを防ぐことができる。必ずしも、タイムテーブルの全体で同じパターンの繰り返しを無くす必要はない。十分に長い周期で同じパターンを繰り返せば、実用上問題は無い。十分に長い周期は、例えば、１０００行程度である。

タイムテーブル全体で周期性が発生しないように、この疑似乱数の回数を選択する。しかし、疑似乱数の周期性を長く設定すると演算量が多くなる。そして、乱数のデータ列として予め与える場合でも、データ量が多くなる。

早送りの操作または巻き戻しの操作の際には、主にスキップ量の少ない早送りまたは巻き戻しが利用される。例えば、ＧＯＰのスキップを行わないか、１から数十程度のＧＯＰのスキップを行う。そのため、疑似乱数の周期を短く設定することができる。

一例として、１０００行程度の周期性を持つタイムテーブルを挙げた。９９９のＧＯＰをスキップした時に、一部の画像のみが更新されるという問題が発生する。しかし、９９９のＧＯＰをスキップした時の早送り再生と巻き戻し再生とは、あまり利用されない。また、９９９のＧＯＰをスキップする場合に代わって、１０００のＧＯＰをスキップすることを採用しても、利用者から見た早送りの倍速は、ほとんど変わらない。このため、容易に回避できる。

ＧＯＰの長さの平均を０．５秒とすると、２時間の映像は１４４００個のＧＯＰで構成される。そして、１０００行の周期性は、２時間の映像で１５回程度発生することになる。周期性が問題になるのは、２時間映像を１５コマで再生する早送りの時である。通常は、このような高速の早送りの操作は行われない。

この場合の疑似乱数列を事前に、計算済み乱数表として制御プログラムに与える場合の乱数表のサイズを見積もる。値数が４値で、回数が１０００回の乱数列を、１つを２ビットで表現する。この場合には、全体で２５０バイトのサイズとなる。疑似乱数の周期性の長さは、操作性と装置実装との関係で設定することができる。

＜変形例３＞
これまでの例では、スライスセグメントの表示位置を変更する場合には、タイムテーブルにスライスセグメントの読み出し位置および終了位置を格納していた。また、必要な場合には、タイムテーブルにパラメータセット（ＰＳ）を格納していた。そのため、タイムテーブルのデータが大きくなる。また、パラメータセット（ＰＳ）とスライスセグメントとの２回の読み出しが発生する。

映像ストリームの記録の際に、スライスセグメントの順序を入れ替えることによって、これらの余分な作業を回避し、効率のよい特殊再生を行うことができる。

図２５は、早送り再生の説明図である。図２４と同様にＧＯＰ（０１）からＧＯＰ（０６）は、ストリームデータである。本来、一続きのデータファイルであるが、説明を容易にするために、ＧＯＰ単位で行を変えて表わしている。

図２５のストリームでは、それぞれのＧＯＰの先頭にあるＩＲＡＰピクチャごとに、スライスセグメントの格納順を変更している。ここで、スライスセグメントの番号は、画面上の表示位置を示している。この表示位置に表示されるスライスセグメントの番号を、ストリームデータ上の番号として示している。

図２５では、一例として、次のようにデータを配置している。ＧＯＰ（０１）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃１を配置している。ＧＯＰ（０２）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃２を配置している。ＧＯＰ（０３）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃３を配置している。ＧＯＰ（０４）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃４を配置している。ＧＯＰ（０５）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃１を配置している。ＧＯＰ（０６）には、ＩＲＡＰピクチャの先頭にスライスセグメント＃２を配置している。

これまでの説明では、データ分割の観点から、単にスライスセグメントとして説明してきた。しかし、表示位置も含めた管理は、ＨＥＶＣ規格のスライスセグメントの他に、タイルも用いて実現されている。そのため、タイムテーブルのスライスセグメントの格納位置を入れ替える場合には、必要に応じて、各スライスセグメントのスライスヘッダ情報およびタイル情報などを修正して、整合性を取る必要がある。タイル情報は、パラメータセットに含まれている。

早送り再生時の手順は、図２０を用いた説明と同一である。図２０を用いた説明は、スライスセグメント＃１のみの再生を行う場合である。ただし、図２５の例では、先頭に置かれるスライスセグメントが入れ替えられている。このため、画像の更新がされるスライスセグメントが変化し、画面の全体が更新される。

単純な順序で先頭に配置されたスライスセグメントを選択する場合には、早送りの倍速によって一部のスライスセグメントの画像だけが更新される。そこで、前述の乱数または疑似乱数などを用いる方式で、先頭に配置するスライスセグメントを決定することができる。

このように、記録時のスライスセグメントの順番を入れ替える事によって、早送り及び巻き戻し等の特殊再生によるシーンサーチの操作性を向上する事が可能である。

これまで、スライスセグメントとして４分割を例にして説明をしてきた。これは、日本の４Ｋ／８Ｋ放送で採用されているためである。

実際には、放送の録画時または光ディスクへの記録時に、再圧縮またはフォーマット変換などを行うこともある。この場合には、４分割だけでなく、スライスセグメント分割の形式を自由に変更することができる。

例えば、１つの画像を３×３の９分割にすることもできる。この場合には、中心のセグメントのみを特殊再生で更新することも考えられる。なぜなら、中心のセグメントには重要な情報が含まれる可能性が高いからである。また、単純に２分割のスライスセグメントとすることができる。２つのセグメントを交互に更新することで特殊再生を行うこともできる。

また、光ディスクの例で説明したが、ハードディスクドライブ（ＨＤＤ）またはＳＳＤ（ｓｏｌｉｄ ｓｔａｔｅ ｄｒｉｖｅ）など、他の記憶デバイスでも同様の効果が得られる。

ネットワークなど伝送帯域で制限があり、データ転送の遅延が大きい場合でも、特殊再生時のデータ転送量を抑制し、操作性を向上させることも可能である。

なお、以上のように本発明の実施の形態について説明したが、本発明はこれらの実施の形態に限るものではない。

１００ 映像記録再生装置、 １１ チューナー・復調部、 １２ 外部入力部、 １３ ネットワーク部、 ２１ 多重化解除部、 ３１ 音声デコード部、 ３２ 映像デコード部、 ３３ 字幕デコード・レンダリング部、 ３４ データ放送・ＥＰＧ処理部、 ４１ 記録再生制御部、 ５１ 内蔵記録装置、 ５２ 光ディスクドライブ、 ５３ 光ディスク、 Ａｆ 管理用ファイル、 Ｈｍ 先頭のデータ、 Ｂａ 放送波、 Ｓｍ 多重化ストリーム、 Ｓｅ エレメンタリーストリーム、 Ｄｓ 音声データ、 Ｄｉ_０，Ｄｉ_１ 映像データ、 Ｄｃ 字幕データ、 Ｄｂ データ放送のデータ、 Ｄｄ 表示装置、 Ｅｓ 音響装置、 Ｅｉ 外部装置、 Ｎｅ ネットワーク、 Ｈａ 横軸、 Ｖａ_１，Ｖａ_２ 縦軸、 Ｐ１，Ｐ２，Ｐ３ 位置、 Ｐａｄ パディング、 ＳＩ（ＭＰＴ） 制御パケット、 ＴＰ ＴＬＶパケット、 ＴＭ，ＴＭＳ タイムテーブル、 Ｖ 映像パケット、 Ｖ（ＲＡＰ） 映像パケット。

Claims (6)

1. コンテナフォーマットにおける多重化方式としてＭＭＴが用いられた多重化データストリームであって、少なくとも映像データを含むアセットデータのストリームと、制御情報である少なくとも１つのＭＰＴデータとを含む多重化データストリームに含まれる各種データを、ランダムアクセス可能に記録する映像記録装置であって、
   前記多重化データストリームに含まれる各種データであって、前記アセットデータと、前記ＭＰＴデータとを含む各種データをひとまとまりのストリームデータとして記録するとともに、
   前記映像データの第１の映像時刻と、前記第１の映像時刻に対応する、記録先の前記ストリームデータ内の前記ＭＰＴデータの位置とを対応付けて記録すること
   を特徴とする映像記録装置。
2. 前記映像データの第２の映像時刻と、前記第２の映像時刻に対応する前記映像データの開始位置とを対応付けて記憶すること
   を特徴とする請求項１に記載の映像記録装置。
3. 前記第１の映像時刻が、前記第２の映像時刻よりも早い場合には、前記ＭＰＴデータの位置は、前記映像データの開始位置よりも前を示していること
   を特徴とする請求項２に記載の映像記録装置。
4. コンテナフォーマットにおける多重化方式としてＭＭＴが用いられた多重化データストリームであって、少なくとも映像データを含むアセットデータのストリームと、制御情報である少なくとも１つのＭＰＴデータとを含む多重化データストリームに含まれる各種データであって、前記アセットデータと、前記ＭＰＴデータとを含む各種データがひとまとまりのストリームデータとして記録されるとともに、前記映像データの第１の映像時刻と、前記第１の映像時刻に対応する、記録先の前記ストリームデータ内の前記ＭＰＴデータの位置とが対応付けられて記録された記録媒体から、再生したい映像時刻に応じて、前記第１の映像時刻に対応する前記ＭＰＴデータを取得し、
   取得された前記ＭＰＴデータを用いて、前記再生したい映像時刻に応じて、記録先の前記ストリームデータ内における前記映像データの再生処理を行うこと
   を特徴とする映像再生装置。
5. 前記記録媒体には、前記映像データの第２の映像時刻と、前記第２の映像時刻に対応する映像データの開始位置とが対応付けて記録されており、
   前記再生したい映像時刻に応じて、前記記録媒体から前記第１の映像時刻に対応する前記ＭＰＴデータを取得して、
   前記取得されたＭＰＴデータを用いて、前記再生したい映像時刻に応じて、前記第２の映像時刻に対応する開始時刻から前記映像データの再生処理を行うこと
   を特徴とする請求項４に記載の映像再生装置。
6. 前記再生したい映像時刻よりも前の時刻である前記第１の映像時刻に対応付けられている前記ＭＰＴデータを取得して、前記取得されたＭＰＴデータを用いて、前記記録媒体において、前記取得されたＭＰＴデータよりも後の位置に記録されている前記第２の映像時刻に対応する開始位置から前記映像データの再生を開始すること
   を特徴とする請求項５に記載の映像再生装置。

Images