(57)【要約】  【課題】  テキストデータの基本修飾データのセットを効率的に伝送するデータ構造と、このデータ構造に基づくテキストデータを受信・再生する手段の提供。  【解決手段】  テキストデータ分離手段１は、完全基本修飾データおよび差分基本修飾データのセットを受信してテキストデータ保持手段２に格納し、エントリ復元手段５は、テキストデータ保持手段２に格納された差分基本修飾データに付与されたフラグ値と、完全基本修飾データを参照して、完全な基本修飾データのセットを復元し、エントリ保持手段６に格納する。【選択図】  図１
2005038550.tif 000002
【特許請求の範囲】
【請求項１】
テキストデータをパケット多重化したデータを受信してテキストデータを分離するデータ分離手段と、
前記分離したテキストデータを格納するテキストデータ保持手段と、
前記テキストデータ保持手段に格納されたテキストデータの復号や表示の属性に関するテーブルデータを読み出し、テーブルデータを復元する復元手段と、
前記復元したテーブルデータを保持するテーブルデータ保持手段と、
前記テキストデータと前記復元されたテーブルデータを用いてテキストデータを復号する復号手段と、
前記復号したテキストデータを表示する表示手段と、
を備えたデータ再生装置であって、
前記復元手段は、テーブルデータの個々の要素データを全て記録した完全テーブルデータと、完全テーブルデータと異なる値を持つ要素データを記録した差分テーブルデータとを入力し、前記差分テーブルデータを、前記完全テーブルデータを参照して、第２の完全テーブルデータを復元することを特徴とする、
データ再生装置。
【請求項２】
前記復元手段は、前記差分テーブルデータが記録している要素データの種類を識別するためのフラグを参照しながら前記第２の完全テーブルデータを復元することを特徴とする、
請求項１に記載のデータ再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像や音声と同期再生が可能な文字データが多重化されたデータ中からテキストデータを分離し、復号して表示するデータ再生装置に関するものである。
【背景技術】
【０００２】
従来のデータ再生装置としては、テキストデータの基本修飾情報であるサンプルディスクリプションを３ＧＰＰ規格（ＴＳ２６．２３４）規格で規格化されているデータ構造のまま受信するものがあった（例えば、特願２００２−２９５４２３号（以下、文献１という）参照）。以下、サンプルディスクリプションのデータ構造とデータサイズ、およびサンプルディスクリプションとテキストデータの関係について、説明する。
【０００３】
［サンプルディスクリプションのデータ構造とデータサイズ］
サンプルディスクリプションの構造は、３ＧＰＰ規格ＴＳ２６．２３４に規定されている。図７にサンプルディスクリプションの構造を示す。
【０００４】
図７（ａ）は、サンプルディスクリプションの全体構造を示している。サンプルディスクリプション（ａ）は、エントリの個数を示すＥＮＴ＿ＣＯＵＮＴ（７００）と、ＥＮＴ＿ＣＯＵＮＴ（７００）に示された個数のエントリＥＮＴ＿＃１〜ＥＮＴ＿＃Ｎ（７０１〜７０Ｎ）で構成される。
【０００５】
各エントリは（ｂ）のように複数のデータフィールドからなる。エントリのデータサイズ（単位はバイト）が、ＥＮＴ＿ＳＩＺＥ（７０１ａ）で示される。エントリのデータタイプを示すＥＮＴ＿ＴＹＰＥ（７０１ｂ）は、３ＧＰＰ規格ＴＳ２６．２３４において「ｔｘ３ｇ」という文字列に固定されている。続く２つのフィールドＲＳＶ＿６（７０１ｃ）、ＤＲＥＦ＿ＩＤＸ（７０１ｄ）もゼロに固定されている。なお、ＥＮＴ＿ＳＩＺＥ（７０１ａ）からＤＲＥＦ＿ＩＤＸ（７０１ｄ）までのサイズは１６バイトである。
【０００６】
ＤＩＳＰ＿ＦＬＧ（７０１ｅ）は、主に表示する文字データのスクロール方法に関するものであり、（ｃ）に示すように複数のフィールドに再分割される。スクロールインする場合、ＳＣＲＯＬＬ＿ＩＮ（７０１ｅ１）をセットし、スクロールアウトする場合、ＳＣＲＯＬＬ＿ＯＵＴ（７０１ｅ２）をセットする。スクロールイン・スクロールアウトの場合、７０１ｅ１と７０１ｅ２の両方をセットする。ＳＣＲＯＬＬ＿ＤＩＲＥＣＴＩＯＮ（７０１ｅ３）はスクロールの方向を示すものである。種類としては、左から右、右から左、上から下、下から上等がある。また、歌詞の文字色を歌の進行に合わせて変化させるカラオケの場合に使用するＣＯＮＴ＿ＫＡＲＡＯＫＥ（７０１ｅ４）や、文字データを縦書きする場合にセットするＷＲＴ＿ＶＥＲＴＩＣＡＬＬＹ（７０１ｅ５）等のフィールドもある。ＤＩＳＰ＿ＦＬＧ（７０１ｅ）のサイズは４バイトである。
【０００７】
文字データの寄せ位置に関する指定はＨ＿ＪＵＳＴ（７０１ｆ）、Ｖ＿ＪＵＳＴ（７０１ｇ）によってなされる。寄せ位置の種類としては、右寄せ、左寄せ、上寄せ、下寄せ、中央揃えなどがある。ＢＧ＿ＣＯＬＯＲ（７０１ｈ）は、文字データの表示領域の背景色を指定するものであり、図示しないが赤、緑、青、透明度をそれぞれ０〜２５５の範囲で設定される。ＴＢＯＸ（７０１ｉ）は、文字データの表示領域を指示するものであり、図示しないが上端、下端、左端、右端をそれぞれ０〜６５５３５の範囲で設定される。なお、Ｈ＿ＪＵＳＴ（７０１ｆ）からＴＢＯＸ（７０１ｉ）までのデータサイズは合計１４バイトである。
【０００８】
ＳＴＹＬＥ（７０１ｊ）は、表示する文字の属性に関するものであり、（ｄ）に示すように複数のフィールドに再分割される。Ｓ＿ＣＨＡＲ（７０１ｊ１）、Ｅ＿ＣＨＡＲ（７０１ｊ２）はゼロに固定されている。文字のフォント名に対するポインタであるＦＯＮＴ＿ＩＤ（７０１ｊ３）、文字を太字、斜体で表示するかどうか、また下線をつけるかどうかなどを指示するＦＡＣＥ＿ＳＴＹＬＥ＿ＦＬＧＳ（７０１ｊ４）、文字のサイズを指定するＦＯＮＴ＿ＳＩＺＥ（７０１ｊ５）、文字の色を指定するＴＥＸＴ＿ＣＯＬＯＲ（７０１ｊ６）から構成され、全体で１２バイトのデータサイズとなる。
【０００９】
ＦＯＮＴ＿ＴＢＬ（７０１ｋ）は、フォント名を記述するテーブルである。データサイズは可変であるが、例えば、一般的なフォント名の１つとして「Ｓｅｒｉｆ」というフォント名のみ指定した場合、ＦＯＮＴ＿ＴＢＬ（７０１ｋ）のサイズは１８バイトとなる。
【００１０】
１つのエントリのサイズは、ＦＯＮＴ＿ＴＢＬ（７０１ｋ）を除き、４６バイトとなる。上述したように、ＦＯＮＴ＿ＴＢＬ（７０１ｋ）が「Ｓｅｒｉｆ」のみを指定している場合は、ＦＯＮＴ＿ＴＢＬ（７０１ｋ）のサイズは１８バイトとなるため、この場合、エントリ（ａ）の合計サイズは、６４バイトとなる。
【００１１】
［テキストデータとサンプルディスクリプションの関係］
３ＧＰＰ規格ＴＳ２６．２３４によって規定されるテキストデータと、サンプルディスクリプション（ａ）の関係を図８に示す。図８の例は、エントリの数は３の例である。テキストデータは、複数のテキストサンプルＴＳＰＬ＿＃１〜ＴＳＰＬ＿＃Ｎで構成される。各テキストサンプルには、表示開始時間と表示終了時間を与えられており、規格化された方法によって、各テキストサンプルに対してサンプルディスクリプションの各エントリＥＮＴ＿＃１〜ＥＮＴ＿＃３と関連づけられている。図８に示すテキストデータの場合、第１番目のエントリＥＮＴ＿＃１は、ＴＳＰＬ＿＃１とＴＳＰＬ＿＃４に関連付けられ、第２番目のエントリＥＮＴ＿＃２は、ＴＳＰＬ＿＃２とＴＳＰＬ＿＃Ｎに関連付けられ、第３番目のエントリＥＮＴ＿＃３は、ＴＳＰＬ＿＃３に関連付けられている。ＥＮＴ＿＃１に関連づけられたテキストサンプル（ＴＳＰＬ＿＃１とＴＳＰＬ＿＃４）はスクロールイン、中央揃えで表示される。ＥＮＴ＿＃２に関連づけられたテキストサンプル（ＴＳＰＬ＿＃２とＴＳＰＬ＿＃Ｎ）はスクロールしないが、中央揃えで表示される。ＥＮＴ＿＃３に関連付けられたテキストサンプル（ＴＳＰＬ＿＃３）はスクロールイン、左寄せで表示される。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
文献１に開示されたデータ構造（文献１における図１、１１２）、データ再生装置（文献１における図１６）によれば、サンプルディスクリプションを３ＧＰＰ規格で規格化されたデータ構造で受信し、再生する。各テキストサンプルに対して異なるサンプルディスクリプションを指定することもできるため、サンプルディスクリプションの数が数十〜数百個に達することがあり得る。サンプルディスクリプションを、テキストサンプルの受信に先立って受信する場合（アウトバンド伝送）、テキストサンプルの受信と並列してサンプルディスクリプションの受信も行う場合（インバンド伝送）のそれぞれの伝送方式において、サンプルディスクリプションの個数の増加により、以下のような問題を生ずる。
【００１３】
まず、アウトバンド伝送における問題を説明する。文献１において、サンプルディスクリプションをＰＭＴあるいはＰＳＩプライベートセクションにてカルーセル方式で繰り返し伝送することが開示されている（文献１［第２実施形態］）。この場合、エントリ数が増加することでデータ量が多くなると、ＰＭＴあるいはＰＳＩプライベートセクションに含まれるサンプルディスクリプションのデータを全て受信完了するまでの所要時間が増大する。一例として、ＰＳＩプライベートセクションでサンプルディスクリプションを伝送する場合を具体的に考察する。もしエントリが１つで、エントリサイズが６４バイトの場合、プライベートセクションのサイズも、たかだか１００バイトとなる。ＴＳパケットのサイズは１８８バイトであり、１００バイトのプライベートセクションは１個のＴＳパケットで十分に伝送可能である。プライベートセクションを含むＴＳパケットを０．１秒毎に１回の割合で伝送する場合、０．１秒毎にサンプルディスクリプション全体（つまり１つのエントリ）が繰り返し伝送されていることになる。したがって、サンプルディスクリプションの受信には０．１秒しか要しない。しかし、エントリの数が１００個の場合、サンプルディスクリプション全体のサイズは６４００バイトとなり、約４０個のＴＳパケットが必要となる。プライベートセクションを含むＴＳパケットを０．１秒に１つの割合で伝送すると、サンプルディスクリプション全体を受信完了するまでに４秒必要となる。したがって、テキストデータの受信あるいは再生を開始するまでに、４秒の初期遅延時間が発生してしまう。初期遅延時間を短くするために、プライベートセクションのＴＳパケットを伝送する割合を上げることは可能であるが、先の例で１個の場合と同等の初期遅延時間を達成するには、４０倍の帯域幅が必要となり、非効率的である。なお、放送のような配信アプリケーションでは、受信側はランダムな時間に受信を開始するため、サンプルディスクリプションは、内容に変化がなくとも繰り返し伝送する必要がある。
【００１４】
次に、インバンド伝送における問題を説明する。文献１において、サンプルディスクリプションをＰＥＳパケット中でテキストサンプルと同一のパケットで伝送することが開示されている（文献１［第１実施形態］）。各ＰＥＳパケットに、完全なサンプルディスクリプションを伝送する場合、エントリの数に比例してデータサイズが増大する。テキストサンプルのサイズは、含まれる文字数等に依存するため一概には言えないが、数十バイト程度と考えられる。１エントリのサイズは上述したように６４バイト程度になるため、ＰＥＳパケット中におけるエントリとテキストサンプルのデータ量の比は、場合によっては同等あるいはエントリの方が大きくなることも考えられる。これは、テキストデータ全体（サンプルディスクリプションとテキストサンプルの両方）の伝送に必要な帯域幅の増大となる。
【００１５】
以上を鑑み、テキストデータの基本修飾データであるサンプルディスクリプションを効率的に伝送するデータ構造と、このデータ構造に基づくテキストデータを受信・再生する手段を提供することを本発明の課題とする。
【課題を解決するための手段】
【００１６】
前記課題を解決するため、第１の本発明におけるデータ再生装置は、テキストデータをパケット多重化したデータを受信してテキストデータを分離するデータ分離手段と、分離したテキストデータを格納するテキストデータ保持手段と、テキストデータ保持手段に格納されたテキストデータの復号や表示の属性に関するテーブルデータを読み出し、テーブルデータを復元する復元手段と、復元したテーブルデータを保持するテーブルデータ保持手段と、テキストデータと復元されたテーブルデータを用いてテキストデータを復号する復号手段と、復号したテキストデータを表示する表示手段とを備えたデータ再生装置であって、復元手段は、テーブルデータの個々の要素データを全て記録した完全テーブルデータと、完全テーブルデータと異なる値を持つ要素データを記録した差分テーブルデータとを入力し、差分テーブルデータを、完全テーブルデータを参照して、第２の完全テーブルデータを復元するものである。
【００１７】
また、第２の本発明におけるデータ再生装置では、復元手段は、差分テーブルデータが記録している要素データの種類を識別するためのフラグを参照しながら第２の完全テーブルデータを復元するものである。
【発明の効果】
【００１８】
第１の本発明におけるデータ再生装置は、テキストデータをパケット多重化したデータを受信してテキストデータを分離するデータ分離手段と、分離したテキストデータを格納するテキストデータ保持手段と、テキストデータ保持手段に格納されたテキストデータの復号や表示の属性に関するテーブルデータを読み出し、テーブルデータを復元する復元手段と、復元したテーブルデータを保持するテーブルデータ保持手段と、テキストデータと復元されたテーブルデータを用いてテキストデータを復号する復号手段と、復号したテキストデータを表示する表示手段とを備えたデータ再生装置であって、復元手段は、テーブルデータの個々の要素データを全て記録した完全テーブルデータと、完全テーブルデータと異なる値を持つ要素データを記録した差分テーブルデータを入力し、差分テーブルデータを、完全テーブルデータを参照して、第２の完全テーブルデータを復元する。このため、サンプルディスクリプションの情報を一切失うことなく、少ないデータ量（例えば１／２以下のデータ量）で受信できるという効果が得られる。これによって、従来より帯域幅の狭い伝送路でもデータの受信が可能、あるいは伝送路の混雑の緩和、受信データ量の減少によるデータ再生装置における消費電力の削減等の効果がある。
【００１９】
また、第２の本発明におけるデータ再生装置では、復元手段は、差分テーブルデータが記録している要素データの種類を識別するためのフラグを参照しながら第２の完全テーブルデータを復元する。このため、差分テーブルデータに記録された情報を容易に識別し、完全テーブルデータを確実に復元することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００２１】
（実施の形態１）
本実施の形態１では、エントリの送信に要するデータ量を削減するため、１パケットに含まれるエントリの１個に対してのみ完全な情報を含み、他のエントリはその差分データのみを含むデータを受信し、全てのエントリに対して完全な情報を復元し、テキストデータを復号・再生するデータ再生装置について、説明する。
【００２２】
図１は、本発明の実施の形態１であるデータ再生装置の動作を説明するための機能ブロック図である。データ再生装置は、テキストデータ分離手段１、テキストデータ保持手段２、テキストデータ復号手段３、表示手段４、エントリ復元手段５、エントリ保持手段６で構成される。
【００２３】
テキストデータ分離手段１は、ＭＰＥＧ−２規格によって規定されるトランスポートストリーム（以下ＴＳと呼ぶ）を入力し、テキストデータを伝送するＴＳパケットを分離し、ＴＳパケットに含まれるパケタイズドエレメンタリストリーム（以下ＰＥＳと呼ぶ）データをテキストデータ保持手段２に格納する。エントリ復元手段５は、テキストデータ保持手段２に格納されたＰＥＳデータから、サンプルディスクリプションを読み出し、差分符号化されたエントリから完全な情報を持つエントリを復元し、エントリ保持手段６に格納する。テキストデータ復号手段３は、各テキストサンプルに付随するサイド情報を参照しながら、１つのテキストサンプルデータを読み出し、サイド情報に含まれる参照先インデックス番号と一致するエントリデータを、エントリ保持手段６より読み出し、エントリデータを用いてテキストデータを復号する。表示手段４は、復号されたテキストデータを表示する。
【００２４】
次に、エントリ復元手段５の動作について、詳細に説明する。
【００２５】
図２（ａ）は、テキストデータ保持手段２に格納されたサンプルディスクリプションを示している。サンプルディスクリプション（ａ）は、エントリの個数を示すＥＮＴ＿ＣＯＵＮＴ（１００）およびエントリＥＮＴ＿＃１〜ＥＮＴ＿＃Ｎ（１０１〜１０３）で構成される。ＥＮＴ＿＃１（１０１）は、第１番目のエントリを示し、ＥＮＴ＿＃２（１０２）は第２番目のエントリを示す。ＥＮＴ＿＃１（１０１）は、完全なエントリとして、図７の７０１ｅ〜７０１ｋを情報として持っている。一方、第２番目以降のエントリＥＮＴ＿＃２〜ＥＮＴ＿＃Ｎ（１０２〜１０３）は、ＥＮＴ＿＃１（１０１）に対する差分情報を伝送する不完全なエントリである。全てのエントリに共通するデータ構造を図２（ｂ）に示す。エントリは、ＩＮＤＥＸ（１０４）、ＭＡＳＫ（１０５）、ＡＴＴＲ（１０６）からなる。ＩＮＤＥＸ（１０４）は、このエントリに関連付けられた番号である。ＭＡＳＫ（１０５）は、図２（ｃ）に示すようなデータ構造であり、１バイトあるいは２バイトのサイズを持つ。（ｃ）の第１バイトは必ず存在し、それぞれ１ビットデータであるＲＳＶ＿１ＢＩＴ、Ｍ＿ＤＩＳＰ＿ＦＬＧ（１０５ｅ）、Ｍ＿Ｈ＿ＪＵＳＴ（１０５ｆ）、Ｍ＿Ｖ＿ＪＵＳＴ（１０５ｇ）、Ｍ＿ＢＧ＿ＣＯＬＯＲ（１０５ｈ）、Ｍ＿ＴＢＯＸ（１０５ｉ）、Ｍ＿ＳＴＹＬＥ（１０５ｊ）、Ｍ＿ＦＯＮＴ＿ＴＢＬ（１０５ｋ）で構成される。（ｃ）の第２バイトは、Ｍ＿ＳＴＹＬＥ（１０５ｊ）の値が１である場合のみ存在し、４ビットデータであるＲＳＶ＿４ＢＩＴ、それぞれ１ビットデータであるＭ＿ＦＯＮＴ＿ＩＤ（１０５ｊ３）、Ｍ＿ＦＡＣＥ＿ＳＴＹＬＥ＿ＦＬＧＳ（１０５ｊ４）、Ｍ＿ＦＯＮＴ＿ＳＩＺＥ（１０５ｊ５）、Ｍ＿ＴＥＸＴ＿ＣＯＬＯＲ（１０５ｊ６）で構成される。ＡＴＴＲ（１０６）は、図２（ｄ）に示すデータ構造であり、ＤＩＳＰ＿ＦＬＧ（１０６ｅ）、Ｈ＿ＪＵＳＴ（１０６ｆ）、Ｖ＿ＪＵＳＴ（１０６ｇ）、ＢＧ＿ＣＯＬＯＲ（１０６ｈ）、ＴＢＯＸ（１０６ｉ）、ＦＯＮＴ＿ＩＤ（１０６ｊ３）、ＦＡＣＥ＿ＳＴＹＬＥ＿ＦＬＧＳ（１０６ｊ４）、ＦＯＮＴ＿ＳＩＺＥ（１０６ｊ５）、ＴＥＸＴ＿ＣＯＬＯＲ（１０６ｊ６）、ＦＯＮＴ＿ＴＢＬ（１０６ｋ）の内、少なくとも１つ以上で構成される。ＡＴＴＲ（１０６）におけるこれらのデータ（１０６ｅ〜１０６ｋ）の有無は、ＭＡＳＫ（１０５）の値によって決定される。例えば、Ｍ＿ＤＩＳＰ＿ＦＬＧ（１０５ｅ）が１の場合、ＤＩＳＰ＿ＦＬＧ（１０６ｅ）が存在し、０の場合存在しない。Ｍ＿ＳＴＹＬＥ（１０５ｊ）が０の場合、ＦＯＮＴ＿ＩＤ〜ＴＥＸＴ＿ＣＯＬＯＲ（１０６ｊ３〜１０６ｊ６）は存在しない。Ｍ＿ＳＴＹＬＥ（１０５ｊ）が１の場合、ＭＡＳＫ（１０５）の第２バイトにおけるＭ＿ＦＯＮＴ＿ＩＤ〜Ｍ＿ＴＥＸＴ＿ＣＯＬＯＲ（１０５ｊ３〜１０５ｊ６）の値が、ＦＯＮＴ＿ＩＤ〜ＴＥＸＴ＿ＣＯＬＯＲ（１０６ｊ３〜１０６ｊ６）の有無を決定する。例えば、Ｍ＿ＦＯＮＴ＿ＩＤ（１０５ｊ３）が１の場合、ＦＯＮＴ＿ＩＤ（１０６ｊ３）が存在し、０の場合存在しない。
【００２６】
図３は、一例として、ＥＮＴ＿ＣＯＵＮＴ（１００）が４（つまりエントリの数が４）の場合のＭＡＳＫ（１０５）の各１ビットフィールドの値を示す。第１番目のエントリＥＮＴ＿＃１においては、全フィールド（１０５ｅ〜１０５ｋ、１０５ｊ３〜１０５ｊ６）は１に設定される。したがって、ＡＴＴＲ＿＃１には、全てのエントリ情報（１０６ｅ〜１０６ｋ、１０６ｊ３〜１０６ｊ６）を含んでいることを示している。一方、ＥＮＴ＿＃２は、Ｍ＿ＤＩＳＰ＿ＦＬＧ（１０５ｅ）のみ１で、他は全て０である。Ｍ＿ＳＴＹＬＥ（１０５ｊ）が０のため、ＭＡＳＫ（１０５）の第２バイトが存在しないため、第２バイトで指定されるＭ＿ＦＯＮＴ＿ＩＤ〜Ｍ＿ＴＥＸＴ＿ＣＯＬＯＲ（１０５ｊ３〜１０５ｊ６）は存在しない。よって、ＡＴＴＲ＿＃２は、ＤＩＳＰ＿ＦＬＧ（１０６ｅ）のみを含んでいる。また、ＥＮＴ＿＃３は、Ｍ＿ＳＴＹＬＥ（１０５ｊ）が１であるため、ＭＡＳＫ（１０５）の第２バイトが存在する。ここではＭ＿ＴＥＸＴ＿ＣＯＬＯＲ（１０５ｊ６）のみ１である。したがって、対応するＡＴＴＲ＿＃３は、ＴＥＸＴ＿ＣＯＬＯＲ（１０６ｊ６）のみを含んでいる。さらに、ＥＮＴ＿＃４は、Ｍ＿ＤＩＳＰ＿ＦＬＧ（１０５ｅ）およびＭ＿ＴＢＯＸ（１０５ｉ）の２つが１、他が０である。したがって、対応するＡＴＴＲ＿＃４は、ＤＩＳＰ＿ＦＬＧ（１０６ｅ）およびＴＢＯＸ（１０６ｉ）を含んでいる。ＡＴＴＲ＿＃２〜ＡＴＴＲ＿＃４に含まれていない情報は、全て第１番目のエントリであるＥＮＴ＿＃１と同値と考える。図３の例では、４つのエントリが占めるデータ量の合計は、（３０＋ａ＋４＋４＋１２）＝（５０＋ａ）バイトとなる。一方、従来例のように完全なエントリとして伝送した場合、４×（３０＋ａ）＝（１２０＋４×ａ）バイトとなる。ＦＯＮＴ＿ＴＢＬが「Ｓｅｒｉｆ」というフォント名のみを含むテーブルであった場合、ａ＝１８バイトとなる。したがって、図３の例では、（５０＋１８）＝６８バイトで４つのエントリを受信できるのに対し、従来例では、（１２０＋４×１８）＝１９２バイトを受信する必要がある。つまり、本実施の形態１のデータ再生装置は、約６５％削減されたデータ量で、従来と同等の情報を受信できると言える。
【００２７】
エントリ復元手段５は、図２、図３で説明したようなサンプルディスクリプションのデータを入力し、差分値のみを含むエントリから、完全な情報を含むエントリを復元し、エントリ保持手段６に格納する。この動作を図４に示すフローチャートを用いて説明する。
【００２８】
図４は、エントリ復元手段５の動作を説明するためのフローチャートである。サンプルディスクリプションに含まれる各エントリに対し、ステップＳ１０１〜Ｓ１１５を繰り返し実行する。以下、各ステップについて説明する。
【００２９】
Ｓ１０１：  ｗｐｏｓは、エントリ保持手段６におけるポインタを示す変数である。第ｉ番目のエントリデータを格納するための領域の先頭アドレスをｗｐｏｓに設定する。
【００３０】
Ｓ１０２：  テキストデータ保持手段２に格納されているサンプルディスクリプションの、第ｉ番目のエントリＥＮＴ＿＃ｉのＩＮＤＥＸを読み込み、エントリ保持手段６のｗｐｏｓが示す位置に書き込む。書き込んだ後、ポインタを更新する。例えば、ＩＮＤＥＸのサイズが２バイトであれば、更新によって、ｗｐｏｓは２バイト移動する。
【００３１】
Ｓ１０３：  第ｉ番目のエントリのＭＡＳＫの第１バイトを読み込む。
【００３２】
Ｓ１０４：  ＭＡＳＫの第１バイトを解析し、Ｍ＿ＳＴＹＬＥが１の場合、さらに第２バイトを読み込む。一方、Ｍ＿ＳＴＹＬＥが０の場合、第２バイトが存在しないが、ここでは以降の処理を簡単に行うため、０の場合はＭ＿ＦＯＮＴ＿ＩＤ、Ｍ＿ＦＡＣＥ＿ＳＴＹＬＥ＿ＦＬＧＳ、Ｍ＿ＦＯＮＴ＿ＳＩＺＥ、Ｍ＿ＴＥＸＴ＿ＣＯＬＯＲの値をそれぞれ０にセットする。
【００３３】
以降のステップＳ１０５〜Ｓ１１５は、対象となるＭＡＳＫのフィールド値と設定するアトリビュートの値が異なる以外は、同一の処理を繰り返しているに過ぎないので、Ｓ１０５についてのみ説明する。
【００３４】
Ｓ１０５：  ＭＡＳＫ中のＭ＿ＤＩＳＰ＿ＦＬＧが１の場合、ＥＮＴ＿＃ｉのＤＩＳＰ＿ＦＬＧをテキストデータ保持手段２から読み込み、エントリ保持手段６のｗｐｏｓが示すアドレス（ＥＮＴ＿＃ｉのＤＩＳＰ＿ＦＬＧが格納されるエントリ保持手段６上の位置）に書き込む。一方、Ｍ＿ＤＩＳＰ＿ＦＬＧが０の場合、ＥＮＴ＿＃ｉのＤＩＳＰ＿ＦＬＧはＥＮＴ＿＃１のＤＩＳＰ＿ＦＬＧと同値である。したがって、ＥＮＴ＿＃１のＤＩＳＰ＿ＦＬＧを読み込み、ｗｐｏｓが示すアドレスに書き込む。その後、ｗｐｏｓを更新する。ＤＩＳＰ＿ＦＬＧのサイズは４バイトであるから、更新によって、ｗｐｏｓも４バイト移動する。
【００３５】
Ｓ１０６〜Ｓ１１５：  以降のステップは、対象となるＭＡＳＫのフィールド値と設定するアトリビュートの値が異なる以外は、Ｓ１０５と同じ処理の繰り返しであるため、説明を省略する。
【００３６】
以上のような処理を行うエントリ復元手段５によって、エントリ保持手段６には、各エントリが完全な情報を含むように格納される。
【００３７】
テキストデータ復号手段３、表示手段４は、テキストデータ保持手段２に格納されたテキストサンプルに付随するサイド情報中に指定されたインデックス番号と一致する、エントリ保持手段６に格納されたエントリを参照し、テキストデータを復号、表示する。図５（ａ）は、エントリ保持手段６に格納されたエントリ、（ｂ）はテキストデータ保持手段２に格納されたテキストデータの例を示している。エントリ保持手段６には４つのエントリ（ＥＮＴ＿＃１〜ＥＮＴ＿＃４）が、エントリ復元手段５により復元され、格納されている。各エントリのＩＮＤＥＸの値は、それぞれ２、４、３、１である。一方、テキストデータ保持手段２には５つのテキストデータ（ＳＰＬ＿＃１〜ＳＰＬ＿＃５）が格納されている。各テキストデータのインデックスＳＩＤＸの値は、それぞれ２、４、３、１、２である。したがって、ＳＰＬ＿＃１に示すテキストデータの復号・表示には、ＥＮＴ＿＃１が参照され、ＳＰＬ＿＃２に示すテキストデータの復号・表示には、ＥＮＴ＿＃２が参照される。
【００３８】
以上、本発明の実施の形態１であるデータ再生装置について説明した。
【００３９】
なお、本発明の実施の形態１では、データ再生装置は、エントリ復元手段５で復元したデータを一旦エントリ保持手段６に格納し、テキストデータ復号手段３において読み出す構成としたが、この構成に限るものではない。例えばエントリ保持手段６を省略し、エントリ復元手段５によって復元されたエントリを直接テキストデータ復号手段３に入力するような構成にしてもよい。
【００４０】
また、本発明の実施の形態１において、テキストデータ分離手段１は、テキストデータを多重化したＰＥＳを分離、テキストデータ保持手段２に格納することとしたが、テキストデータの全て、あるいは一部は、ＰＳＩセクション形式で受信し、テキストデータ保持手段２に格納しても良い。例えば、サンプルディスクリプションは、ＰＳＩセクション形式で受信し、テキストサンプル及びそれに付随するサイド情報は、ＰＥＳで受信することが可能である。この場合でも、エントリ復元手段５は、テキストデータ保持手段２に格納されたＰＳＩセクション形式で包まれたサンプルディスクリプションを読み出し、上述した動作に従って、差分値だけが指示されたエントリデータを完全なエントリデータに復元し、エントリ保持手段６に格納することが可能である。
【００４１】
また、サンプルディスクリプションの一例として、図２（ａ）のデータ構造を示したが、これに限定するものではない。ＴＳにおいて伝送されるサンプルディスクリプションとテキストサンプルの順序の例を図６に示す。図６（ａ）に示すように、１個以上のＴＳパケットから１個のテキストデータを含むＰＥＳパケット６０１が生成される。ＰＥＳパケット６０１内のデータ構造の一例としては、６０１ａに示すように、ＰＥＳヘッダに続いて、サンプルディスクリプション中のエントリの個数を示すＥＮＴ＿ＣＯＵＮＴ、サンプルディスクリプション（完全なエントリと差分エントリからなる）、そしてエントリに対応するテキストサンプルが続く。別の一例としては、６０１ｂに示すように、ＰＥＳヘッダ、ＥＮＴ＿ＣＯＵＮＴの後、エントリＥＮＴ＿＃ＮとテキストサンプルＳＰＬ＿＃Ｎが交互に出現する。この場合、エントリは、直後にあるテキストサンプルに参照されるという規則があってもよい。つまり、ＥＮＴ＿＃１はＳＰＬ＿＃１から参照され、ＥＮＴ＿＃２はＳＰＬ＿＃２から参照される。この規則が適用されている場合、エントリ、テキストサンプルのそれぞれから、参照に使用する識別子（ＩＮＤＥＸ）は必須ではないことから、ＩＮＤＥＸはＥＮＴ＿＃ＮやＳＰＬ＿＃Ｎから削除されてもよい。さらに、６０１ｂの場合、テキストサンプルＳＰＬ＿＃Ｎ中に、テキストサンプルデータのサイズを示すデータフィールドが含まれていればＥＮＴ＿ＣＯＵＮＴはなくても良い。エントリのサイズは図２に示すように、ＭＡＳＫフィールドを解析することによって知ることができる。
【００４２】
また、本発明の実施の形態１では、図２で示したＥＮＴ＿ＣＯＵＮＴはエントリの個数を示すこととして説明したが、これに限るものではない。例えば、ＥＮＴ＿ＣＯＵＮＴに代えて、続くエントリＥＮＴ＿＃１〜ＥＮＴ＿＃Ｎのサイズの合計を示すデータフィールドを設けてもよい。また、ＥＮＴ＿ＣＯＵＮＴやエントリの合計サイズを示す代わりに、各エントリの先頭に、各エントリのサイズを示すデータフィールドを設けても良い。
【００４３】
また、本発明の実施の形態１では、サンプルディスクリプションの第１番目のエントリは、図３に示したように完全なエントリを記述するとしたが、これに限定されるものではない。例えば、全てのエントリにおけるデフォルト値となるＤＩＳＰ＿ＦＬＧ〜ＦＯＮＴ＿ＴＢＬの値をＰＳＩセクション形式のデータで受信し、ＰＥＳパケットでは、ＰＳＩセクション形式で伝送されたデフォルト値からの差分を記述したエントリを受信するようにしても良い。
【００４４】
また、本発明の実施の形態１で説明した、図２（ｃ）に示したＭＡＳＫフィールドのデータ構造は一例であり、フィールドの並び順やデータサイズは一例を示しているに過ぎない。ＭＡＳＫフィールドは１バイトあるいは２バイトのデータフィールドであり、１バイトであるか２バイトであるかは、Ｍ＿ＳＴＹＬＥ（１０５ｊ）の値で決定されるものとしたが、これに限るものではない。例えば、Ｍ＿ＳＴＹＬＥ（１０５ｊ）が１の場合、ＡＴＴＲ（１０６）は必ずＳＴＹＬＥの全データフィールド（図７（ｄ）に示す）を含んでいることとし、ＭＡＳＫは常に１バイト（ＲＳＶ＿１ＢＩＴ〜Ｍ＿ＦＯＮＴ＿ＴＢＬ（１０５ｋ）のみ存在する）としても良い。
【００４５】
さらに、本発明の実施の形態１では、入力する多重化データをＭＰＥＧ−２規格で規定されたＴＳであることとして説明したが、これに限るものではない。例えば、同じくＭＰＥＧ−２規格で規定されるプログラムストリーム（ＰＳ）、ＩＴＵ−Ｔで規格化されたＨ．３２４、あるいはＩＥＴＦで規格化されるリアルタイム・トランスポート・プロトコル（ＲＴＰ）やセッション・ディスクリプション・プロトコル（ＳＤＰ）等を使用したものであっても良い。なお、ＲＴＰの場合、エントリのデフォルト値をＳＤＰで受信し、ＲＴＰでは差分値を受信するようにしても良い。また、テキストサンプルやサンプルディスクリプションのデータをＭＰＥＧ−４の同期レイヤ（シンクレイヤ、ＳＬ）やオブジェクトディスクリプタ等でパケット化した上で、ＴＳやＰＳ、ＲＴＰやＳＤＰなどの伝送プロトコルを用いて伝送されたものであっても良い。
【００４６】
また、実施の形態１では、データ再生装置としてハードウェアで実現したが、上記実施の形態１で説明したテキストデータ分離手段１、エントリ復元手段５、テキストデータ復号手段３は、中央演算処理装置（ＣＰＵ）やデジタル信号処理装置（ＤＳＰ）等の上で動作するソフトウェア・プログラムとして実現しても良い。テキストデータ保持手段２、エントリ保持手段６は、上記ＣＰＵやＤＳＰの内部メモリあるいは外部メモリを使用できる。表示手段４は、具体的には携帯端末のディスプレイ、車載ディスプレイ、あるいはテレビ放送やインターネット放送の受信端末のディスプレイ等が考えられる。なお、本データ再生装置をソフトウェア・プログラムで実現することによって、磁気ディスクや光ディスク、磁気メモリカード等にプログラムを格納し、プログラムを各種機器にインストールし、本発明の実施の形態１で説明したテキストデータの処理動作を実行することが可能となる。
【産業上の利用可能性】
【００４７】
本発明のデータ再生装置は、携帯電話端末、携帯情報端末（ＰＤＡ）等として有用である。また、車搭載型を含むテレビ放送やインターネット放送の再生装置等としても適用が可能である。
【図面の簡単な説明】
【００４８】
【図１】本発明の実施の形態１におけるデータ再生装置の動作を説明するための機能ブロック図。
【図２】本発明の実施の形態１におけるデータ再生装置の受信データ（部分）の一例を示す図。
【図３】本発明の実施の形態１におけるデータ再生装置の受信データの内容の一例を示す図。
【図４】本発明の実施の形態１におけるデータ再生装置のエントリ復元手段の動作の一例を示す図。
【図５】本発明の実施の形態１におけるデータ再生装置のエントリ保持手段とテキストデータ保持手段の内容の一例を示す図。
【図６】本発明の実施の形態１におけるデータ再生装置の受信データの構造の一例を示す図。
【図７】従来のデータ再生装置における受信データ（部分）を示す図。
【図８】テキストサンプルとエントリの関係を示す図。
【符号の説明】
【００４９】
１  テキストデータ分離手段
２  テキストデータ保持手段
３  テキストデータ復号手段
４  表示手段
５  エントリ復元手段
６  エントリ保持手段
【図１】
2005038550.tif 000003
【図２】
2005038550.tif 000004
【図３】
2005038550.tif 000005
【図４】
2005038550.tif 000006
【図５】
2005038550.tif 000007
【図６】
2005038550.tif 000008
【図７】
2005038550.tif 000009
【図８】
2005038550.tif 000010