JP4561822B2 - コンテンツ受信機 - Google Patents

Description

本発明は、デジタルテレビジョン放送受信機、パーソナルコンピュータ、携帯電話機、携帯情報端末機および携帯電話アダプターに関する。

近年、通信網を介して映像や音声のコンテンツを送受信するストリーミングなどの機能をもつ送信器および受信器が、市場において普及してきている。

以下に従来のコンテンツ送信器について説明する。図７は従来のコンテンツ送信器の構成を示す図である。図１０は従来のコンテンツ送信器と従来のコンテンツ受信器におけるパケット構成の推移を示す図である。図１１は従来のパケットの構成を示す図である。

図７に示すビデオエンコーダー５１は、映像信号を所定の圧縮方式でエンコードして、後段に出力する。図７にはＭＰＥＧ２方式による構成を示している。ビデオエンコーダー５１からの出力はＭＰＥＧ２トランスポートストリームパケット（以下ＭＰＥＧ２−ＴＳＰと略する）で構成される。

システムクロック生成器５４は、２７ＭＨｚのクロックを生成する。ビデオエンコーダー５１が映像信号をエンコードする際に使用するシステムクロックは、この２７ＭＨｚのクロックである。

オーディオエンコーダー５２は、音声信号を、ビデオエンコーダー５１と同様の圧縮方式でエンコードし、ＭＰＥＧ２−ＴＳＰを後段に出力する。データエンコーダー５３は、データ放送やＥＰＧなどのデータをビデオエンコーダー５１と同様の圧縮方式でエンコードし、ＭＰＥＧ２−ＴＳＰを後段に出力する。

ストリーム多重化器５５は、上述の３種のＭＰＥＧ２−ＴＳＰを時間軸上に多重化する。またストリーム多重化器５５は、受信側においてシステムクロックを再生するためのＰＣＲ信号を、システムクロックをカウントした計数値を５０ｍＳ程の周期で定期的に用いて、生成する。そしてストリーム多重化器５５は、ＰＣＲ信号をＭＰＥＧ２−ＴＳＰ化した後に、上述の多重化された信号に更に多重して、ＭＰＥＧ２トランスポートストリーム（以下ＭＰＥＧ２−ＴＳと略す）として後段に出力する。この出力信号を図１０のＳ１１に示す。

図１０は時間軸上におけるパケットの多重の推移を示した図である。図１０の横軸は時間である。しかし、図１０において、各処理における定常的な遅延については無視しており図示していない。Ｓ１１のＶＩＤＥＯ１、ＶＩＤＥＯ２、ＶＩＤＥＯ３、ＡＵＤＩＯ１、ＡＵＤＩＯ２、ＤＡＴＡ１はストリーム多重化器５５により多重化されたパケットである。また、Ｓ１１のＶＩＤＥＯ１、ＶＩＤＥＯ２、ＶＩＤＥＯ３はビデオエンコードされたＭＰＥＧ２−ＴＳＰである。また、Ｓ１１のＡＵＤＩＯ１、ＡＵＤＩＯ２はオーディオエンコードされたＭＰＥＧ２−ＴＳＰである。また、Ｓ１１のＤＡＴＡ１はデータエンコードされたＭＰＥＧ２−ＴＳＰである。ＰＣＲ信号についてはＭＰＥＧ２システムにおいて周知の内容なので説明は省略する。

スクランブラ５６は、ＭＰＥＧ２−ＴＳを所定の暗号方式で暗号化して出力する。ここに示す例はＭＵＬＴＩ２方式の例である。

ＲＴＰパケット化器５８は個々のＭＰＥＧ２−ＴＳＰを一つ以上でカプセル化する。また、ＲＴＰパケット化器５８は、送受信器６１が通信網から提供される基準時刻情報を元に再生するバスクロックをカウントするカウンタを有している。なお、送受信器６１については後述する。そしてＲＴＰパケット化器５８は、そのカウンタ値であるタイムスタン
プと、カプセル化された情報がＭＰＥＧ２−ＴＳＰであることを識別する情報とを含んだヘッダーを出力信号に付加して、後段に出力する。この出力信号を図１０のＳ１２に示す。また、Ｓ１２のＲＴＰはヘッダーである。このタイムスタンプは、受信側でパケット到着時にバスクロックを用いてジッタ−を補正するときに使用する。

ＵＤＰ／ＩＰパケット化器５９は、個々のＲＴＰパケットをＩＰ通信網に送信するためにＩＰデータグラム内に格納する。そして、ＵＤＰ／ＩＰパケット化器５９はこの格納した個々のＲＴＰパケットにＩＰパケットヘッダーを付加してＩＰパケットとして出力する。この出力信号を図１０のＳ１３に示す。また、Ｓ１３のＩＰはＩＰヘッダーなどの通信プロトコルにおけるヘッダーである。ＩＰパケットヘッダーについてはインターネットで周知の内容なので説明は省略する。

イーサネット（登録商標）パケット化器６０は、ＩＰパケットをイーサネット（登録商標）のデータ領域に格納し、イーサネット（登録商標）パケットヘッダーとチェックサムを付加してイーサネット（登録商標）パケットとして出力する。イーサネット（登録商標）パケットヘッダーとチェックサムについてはインターネットで周知の内容なので説明は省略する。

送受信器６１はイーサネット（登録商標）パケットをインターネット網に送信する。そして送受信器６１は前述した基準時刻情報などを受信する。

次に、前述した送信パケット構成について説明する。図１１は従来のパケット構成を示す図である。図１１ではＭＰＥＧ２−ＴＳＰを１０個カプセル化している。そして、ＭＰＥＧ２−ＴＳＰを識別するための情報とパケット到着時に使用するタイムスタンプを含む８バイトのヘッダーを付加している。そして、１８９２バイトのＲＴＰパケット化している。そして、ＲＴＰパケットに８バイトのＵＤＰパケットヘッダーを付加して１９００バイトのＵＤＰパケットとしている。そして、ＵＤＰパケットに２４バイトのＩＰパケットヘッダーを付加して１９２４バイトのＩＰパケット化している。そして、ＩＰパケットに１４バイトのイーサネット（登録商標）ヘッダーと４バイトのチェックサムを付加して１９４２バイトのイーサネット（登録商標）パケット化している。

通信網においては、最大伝播パケット単位であるＭＴＵを制限している場合が多い。そして、送出するパケットデータサイズがＭＴＵをオーバーしている場合は、通信網においてパケットを分割する場合が多い。インターネットではこのような処理をフラグメントと言う。

この従来例では、イーサネット（登録商標）通信網におけるＭＴＵは１５００バイトである。一方、イーサネット（登録商標）パケットのデータ領域のデータサイズはＭＴＵをオーバーしているため通信網でのフラグメントを防止できない。したがって、ヘッダー情報を喪失したパケットが発生する場合がある。このため、フラグメント後に発生したパケットロスやジッタ−の補償を受信側で行うことは困難である。

次に受信側の従来例を説明する。図８はコンテンツ受信器の従来例の構成を示す図である。図９はパケットを受信してデコードするまでの動作を示したフローチャートである。

受信器７１は、インターネット網などの通信網からイーサネット（登録商標）パケットを受信し、後段に出力する。このイーサネット（登録商標）パケットは図１１で示したものである。イーサネット（登録商標）パケット処理器７２は、イーサネット（登録商標）パケット処理器７２当てのイーサネット（登録商標）パケットにイーサネット（登録商標）のプロトコル処理を行い、ＵＤＰ／ＩＰパケットを後段に出力する。この処理を図９のＳＴＥＰ９１に示す。また、この出力信号を図１０のＳ１４に示す。

図１０のＳ１４は、インターネット網を介して受信ＵＤＰ／ＩＰパケットの送受信をした結果、受信ＵＤＰ／ＩＰパケットにジッタ−とパケットロスが発生していることを表している。つまりＶＩＤＥＯ１とＤＡＴＡ１を含むパケットには定常的な遅延より大きな遅延が生じている。ＶＩＤＥＯ３とＡＵＤＩＯ２を含むパケットには定常的な遅延より小さい遅延が生じている。

ここで、図１０を用いて、インターネットのジッターとパケットロスについて説明する。インターネット網における送信側と受信側の間には、定常的な遅延が存在する。全てのパケットがその定常的な遅延を持って伝達されるのが理想的である。そして、この場合にはジッターやパケットロスは発生しない。しかし、実際のインターネット網では、パケットが異なるルートを割り当てられる、パケットの有効時間中にパケットを伝達できない為にパケットがゲートウェイで削除される、パケットが再送される、等が生じるので、ジッターやパケットロスが発生する。Ｓ１４の記載については、定常的な遅延をあえてゼロに表現することで、限られた紙面上ジッターを分かりやすく記している。具体的には、ＶＩＤＥＯ１とＤＡＴＡ１を含むパケットは定常的な遅延より大きな遅延が生じているため、Ｓ１３に比べ遅く（遅れているように）記している。ＶＩＤＥＯ３とＡＵＤＩＯ２を含むパケットは定常的な遅延より小さい遅延が生じているためＳ１３に比べ早く（進んでいるように）記している。

またＶＩＤＥＯ２とＡＵＤＩＯ１を含むパケットはパケットロスとなっている。図８に示すＵＤＰ／ＩＰパケット処理部７３は、ＵＤＰ／ＩＰパケットにＵＤＰ／ＩＰのプロトコル処理を行い、ＲＴＰパケットを出力する。この処理を図９のＳＴＥＰ９２に示す。また、この出力信号を図１０のＳ１５に示す。

以上のイーサネット（登録商標）およびＵＤＰ／ＩＰのプロトコル処理はインターネットで周知であるので説明は省略する。

これらの通信プロトコルは、それぞれのヘッダーにデータ本体のプロトコル処理方法を示す情報を含んでいる。各種プロトコルの処理方法については規格化されており、予めコンテンツ受信器はその処理方法を備える事ができる。従って、コンテンツ受信器は、ヘッダー内のプロトコルを示す情報を解析する事により、ヘッダーを削除した後のデータ本体のプロトコル処理を行うことができる。

ＲＴＰパケット処理器７９は、図１１で示した個々のＲＴＰパケットから個々のＲＴＰパケットのヘッダーを取得する。また、ＲＴＰパケット処理器７９はヘッダー内に含まれている構成データの内容を示す情報を取得する。このデータの内容を示す情報は、格納されているデータのフォーマットタイプを識別するための情報である。なお、ここでは、この情報は前述したＭＰＥＧ２−ＴＳＰであることを識別するための情報である。

また、ＲＴＰパケット処理器７９は、受信器７１において基準時刻情報を用いて再生したバスクロックをカウントするカウンタを備えている。ＲＴＰパケット処理器７９は、このバスクロックをカウントし、カウントした値がヘッダー内のタイムスタンプと一致した場合には、ヘッダーを取り外してＭＰＥＧ２−ＴＳＰを後段に出力する（図９のＳＴＥＰ９３）。そして、ＲＴＰパケット処理器７９は、ＭＰＥＧ２−ＴＳＰがスクランブルされているかを確認する（図９のＳＴＥＰ９４）。ＭＰＥＧ２−ＴＳＰのヘッダーはＭＰＥＧ２−ＴＳＰがスクランブルされているかどうかの情報をスクランブルされる範囲外に持っている。したがって、一旦ＭＰＥＧ２−ＴＳＰを取り出した後にその情報を確認してデスクランブル処理を行うことができる。どの方式を用いるかを受信側と送信側とで予め決めておくこと、または、受信するテーブル情報を受信側で確認して認識すること、これらのこ
とで任意の方式への対応が可能である。

デスクランブラ７４は、ＭＰＥＧ２−ＴＳＰを送信側で定めたスクランブルの方式に対応した方式でデスクランブルして、出力する。この処理を図９のＳＴＥＰ９６に示す。この出力信号を図１０のＳ１７に示す。

ＴＳデコーダー７７はＭＰＥＧ２−ＴＳＰをＡＶデコーダー７８がＡＶデコードできる形態に直して出力する（図９のＳＴＥＰ９７）。ＡＶデコーダー７８は、ＡＶデコーダー７８に入力されたデータをＡＶデコードして出力する（図９のＳＴＥＰ９８）。図９のＳＴＥＰ９３では、バスクロックをカウントした値とヘッダー内のタイムスタンプが一致しなかった場合に、ＴＳデコーダー７７はその差分を検証する （図９のＳＴＥＰ９５） 。その差分が再生制御機（図示せず）内部のバッファーで補償できる範囲であれば、ＴＳデコーダー７７は拡張ＴＳパケットをこのバッファー上で待機させる。その差分がこのバッファーで補償できる範囲を超える場合は、ＴＳデコーダー７７は該当ＴＳパケットを廃棄するよう制御する（図９のＳＴＥＰ９６）。

しかしながら上記のような構成では、通信網において発生するパケットロスを受信側でリアルタイムに補償することができず、パケットロスが発生した場合はデコードエラーとなってしまう。

また、ジッター補正用のＲＴＰのタイムスタンプはコンテンツのエンコードやデコードと無関係のバスクロックのカウントにより生成される。また、そのバスクロックを生成するために使用する基準時刻情報が、デコードを行なう際に要求されるジッター精度に対し充分な精度が無い。また、この基準時刻情報が通信網のジッターの影響を受ける。これらの理由により、受信側でデコードを行なう際のジッター補償精度が不十分となりデコードエラーとなる場合がある。

また、通信パケットのデータ領域のデータサイズが通信網におけるＭＴＵをオーバーし、通信網でのフラグメントを防止できないため、ヘッダー情報を喪失する。これによりフラグメント後に発生したパケットロスやジッタ−の補償を受信側で行うことは困難である。

本発明は、エンコードされたＭＰＥＧ−２ＴＳパケットから構成されるストリームにより形成されるコンテンツをインターフェースから受信し、再生するコンテンツ受信器において、前記コンテンツを受信した後に蓄積する蓄積手段と、ＭＰＥＧシステムクロックを再生するシステムクロック再生手段と、前記システムクロック再生手段の出力するＭＰＥＧシステムクロックを計数し計数値を算出する第１の計数手段と、前記蓄積手段に蓄積された前記コンテンツを再生するデコーダとを備え、前記システムクロック再生手段は、前記デコーダから出力されるＰＣＲ信号と前記第１の計数手段の計数した値とを比較した結果が等しくなるようにＭＰＥＧシステムクロックを再生し、受信するコンテンツを形成する各々のＭＰＥＧ−２ＴＳパケットが、前記ＭＰＥＧ−２ＴＳパケットのエンコード時におけるＭＰＥＧシステムクロックのカウント値を４バイトのタイムスタンプとして付加した拡張ＴＳパケットである場合に、前記蓄積手段に蓄積された各々の前記拡張ＴＳパケットを、前記第１の計数手段の計数値と前記タイムスタンプが所定のオフセット値になるタイミングに前記デコーダへ出力し、さらに前記デコーダからストリームを出力するためのインターフェースとを備え、前記拡張ＴＳパケットから構成されるストリームを伝送パケットとして前記インターフェースを介して外部出力する、ことを特徴とする。

以上のように本発明のコンテンツ受信器によれば、通信網において発生するパケットロスを受信側で補償することができずパケットロスが発生した場合にデコードエラーとなってしまうことを防止でき、デジタルテレビジョン放送受信機、パーソナルコンピュータ、携帯電話機、携帯情報端末機および携帯電話アダプターに有用である。

（実施の形態１）
図１は実施の形態１によるコンテンツ送信器の構成を示す図である。図５は実施の形態１によるコンテンツ送信器と、コンテンツ受信器におけるパケット構成の推移を示す図である。図６は実施の形態１によるパケットの構成を示す図である。

図１において、マイコン１４はコンテンツ送信器の各部の制御を行う。ビデオエンコーダー１は、映像信号を所定の圧縮方式でエンコードして、後段に出力する。本実施の形態ではＭＰＥＧ２方式を例として示しており、エンコーダー１が出力する出力信号はＭＰＥＧ２−ＴＳＰで構成される。システムクロック生成器４は２７ＭＨｚのクロックを生成する。ビデオエンコーダー１が映像信号をエンコードする際に使用するシステムクロックはこの２７ＭＨｚのクロックである。オーディオエンコーダー２は、音声信号をビデオエンコーダー１と同様の圧縮方式でエンコードして、ＭＰＥＧ２−ＴＳＰを後段に出力する。

データエンコーダー３は、データ放送やＥＰＧなどのデータをビデオエンコーダー１と同様の圧縮方式でエンコードして、ＭＰＥＧ２−ＴＳＰを後段に出力する。

ストリーム多重化器４は、上述の３種のＭＰＥＧ２−ＴＳＰを時間軸上に多重化する。また、ストリーム多重化器４は受信側においてシステムクロックを再生するためのＰＣＲ信号を、システムクロックをカウントするカウンタを用いて生成する。

なお、ＭＰＥＧトランスポートシステムにおいて、ＰＣＲ信号は５０ｍＳ程の周期で生成される。そしてストリーム多重化器４はＰＣＲ信号をＭＰＥＧ２−ＴＳＰ化した後に、上述の多重化された信号に更に多重して、ＭＰＥＧ２−ＴＳとして出力する。この出力信号を図５のＳ１に示す。

図５は時間軸上におけるパケットの多重の推移を示した図である。図５の横軸は時間である。しかし、図５において、各処理における定常的な遅延については無視しており図示していない。Ｓ５のＶＩＤＥＯ１、ＶＩＤＥＯ２、ＶＩＤＥＯ３、ＡＵＤＩＯ１、ＡＵＤＩＯ２、ＤＡＴＡ１はストリーム多重化器５により多重化されたパケットである。また、Ｓ１のＶＩＤＥＯ１、ＶＩＤＥＯ２、ＶＩＤＥＯ３はビデオエンコードされたＭＰＥＧ２−ＴＳＰである。また、Ｓ１のＡＵＤＩＯ１、ＡＵＤＩＯ２はオーディオエンコードされたＭＰＥＧ２−ＴＳＰである。また、Ｓ１のＤＡＴＡ１はデータエンコードされたＭＰＥＧ２−ＴＳＰである。ＰＣＲ信号についてはＭＰＥＧ２システムにおいて周知の内容なので説明は省略する。

スクランブラ６は、ＭＰＥＧ２−ＴＳを所定の暗号方式で暗号化して出力する。ここに
示す例はＭＵＬＴＩ２方式の例である。タイムスタンプ付加器７は、システムクロック生成器４が出力するシステムクロックをカウントするカウンタを有している。そして、タイムスタンプ付加器７はそのカウント値をタイムスタンプとしてヘッダーに含め、このヘッダーを個々のＭＰＥＧ２−ＴＳ（この例ではスクランブルされている）に付加して、拡張ＴＳパケットとして後段に出力する。この出力信号を図５のＳ２に示す。また、図５のＴＳはタイムスタンプを含んだヘッダーを示している。受信側では、このタイムスタンプを、システムクロックを求めるためには使用しない。受信側は、送信側におけるパケットの生成タイミングを無視して、蓄積デバイスにパケットを蓄積する。そして、受信側は、蓄積したパケットを再生する際に、送信側でのパケットの生成タイミングを求めるため（ＭＰＥＧ２−ＴＳを再生するため）に、このタイムスタンプを使用する。

なお、このカウンタとＰＣＲ信号を生成するカウンタとは、同じシステムクロックを用いているため同期が取れている。

一方、このカウンタと受信側のカウンタとで同期が取れない場合が考えられる。したがって、受信側で再生する時刻を確保する為に、システムクロックの周波数と、送信する拡張ＴＳパケットの最大速度と、後述する受信側の蓄積デバイス３２の最小限のサイズとを予め決めておく。そして、カウンタが一巡する時間に送信する全拡張ＴＳパケットを蓄積できるようにこのカウンタのビット数を設定する。なお、本実施の形態のように、受信側において一旦コンテンツを形成する拡張ＴＳパケットを全て蓄積した後に再生する例では、十分に蓄積デバイスのサイズは確保されることになるので、受信側で再生する時刻を確保できないという問題は生じない。

またタイムスタンプを付加する際に、ＰＣＲ信号の生成に用いたカウント値と時間的に同期させるように、このカウンタをＰＣＲ信号のカウント値に応じて所定のタイミングで初期化した後にタイムスタンプ化する。または、このカウンタを所定のオフセット時間後に初期化した後にタイムスタンプ化する。こうすることで、受信側においてＰＣＲによるシステムクロック再生用カウンタをＭＰＥＧ２―ＴＳ再生用のカウンタとして用いることもできる。また受信側のカウンタと、このカウンタとの同期をとる事もできる。この場合、このカウンタのビット数を、ＰＣＲ信号を生成するためのカウンタのビット数と合わせておく事が望ましい。こうすることで受信側におけるキャリーオーバーの処理を簡略化することができるからである。

スーパーカプセル化器８は、個々の拡張ＴＳパケットを一つ以上でカプセル化する。また、カプセル化された情報が拡張ＴＳパケットであることを識別する情報と、カプセル内の拡張ＴＳパケットのパケット長と、拡張ＴＳパケット数と、カプセルカウンタ値とを含むヘッダーを出力信号に付加して、スーパーカプセルとして後段に出力する。このスーパーカプセルを図５のＳ３に示す。また、図５のＣＨはヘッダーを示している。このカプセルカウンタ値は、受信側でスーパーカプセルの連続性を確認するためのものである。そして、スーパーカプセル化器８がスーパーカプセルを出力するたびにスーパーカプセル化器８は、このカプセルカウンタ値をカウントアップさせる。

なお、図５ではカプセル化される拡張ＴＳパケットは２つであるが、これは一例を示したに過ぎず、本実施の形態において拡張ＴＳパケットの数を限定するものではない。また、スーパーカプセルでの付加ヘッダー内の情報は、カプセル化されたデータの内容と受信側で連続性を確認するための情報を格納することを目的としており、前述した形式に限定するものではない。例えば、カプセルカウンタ値を拡張ＴＳパケットの計数値として拡張ＴＳパケット数の情報も含めてもよい。または、拡張ＴＳパケットのパケット長および拡張ＴＳパケット数はカプセル化された総データ長であっても良い。また、スーパーカプセル化機８は後段へのスーパーカプセルの出力とともに蓄積バッファー１５にもスーパーカ
プセルを出力する。

蓄積バッファー１５への蓄積制御は、マイコン１４によりリングバッファー方式で行われる。マイコン１４は蓄積バッファー１５のスーパーカプセルを記憶する領域と個々のスーパーカプセルのヘッダー情報を管理する。再送コマンド検出器１３は受信器１２が出力する再送コマンドを検出する。そして、スーパーカプセルの再送制御時には、再送コマンド検出器１３は、再送コマンド内に含まれる再送が必要なスーパーカプセルを指定するための情報（この例では少なくともカプセルカウンタ値）と再送を指示する情報をマイコン１４に出力する。

マイコン１４はカプセルカウンタ値に該当するスーパーカプセルを蓄積バッファー１５から読み出す。その後、マイコン１４はスーパーカプセルを再送するために、ＵＤＰ／ＩＰパケット化器９に出力の制御を行なう。この場合、スーパーカプセルのヘッダー内に再送パケットであることを示す情報を更に付加して出力する場合もある。なおカプセルカウンタ値の計数範囲はスーパーカプセルを送信する速度に対し、送信する通信網での最大遅延時間の２倍（スーパーカプセル送信後再送コマンド受信までの遅延分）を少なくともカバーできるビット数であることが望ましい。また、蓄積バッファーサイズは少なくともスーパーカプセルをカプセルカウンタの計数範囲分蓄積できる量であることが望ましい。また再送コマンドのフォーマットについては受信側と予め取り決めておけば良い。本実施の形態では再送コマンドのフォーマットを特に限定しない。

ＵＤＰ／ＩＰパケット化器９は、個々のスーパーカプセルをＩＰ通信網に送信するためにＩＰデータグラム内に格納し、ＩＰパケットヘッダーを付加してＩＰパケットとして出力する。この出力信号を図５のＳ４に示す。また、Ｓ４のＩＰとはＩＰヘッダーなどの通信プロトコルにおけるヘッダーを示している。ＩＰパケットヘッダーについてはインターネットで周知の内容なので説明は省略する。この例では更にＵＤＰパケット内にＩＰパケットヘッダーを格納しているが本来その必要は無い。また別のプロトコル、例えばＴＣＰパケット内にＩＰパケットヘッダーを格納しても良い。

イーサネット（登録商標）パケット化器１０は、イーサネット（登録商標）パケット化器１０に入力されるＩＰパケットをイーサネット（登録商標）のデータ領域に格納する。また、イーサネット（登録商標）パケット化器１０はＩＰパケットにイーサネット（登録商標）パケットヘッダーとチェックサムを付加してイーサネット（登録商標）パケットとして出力する。イーサネット（登録商標）パケットヘッダーとチェックサムについてはインターネットで周知の内容なので説明は省略する。

送信器１１はイーサネット（登録商標）パケットをインターネット網に送信する。インターネット網では様々な通信事業者が様々な方式で通信網を運営しており、送信器１１と受信器１２はこれら様々な方式に対応するものである。また、その形態や仕様について特に制限はしない。

次に送信パケット構成について説明する。図６は本実施の形態におけるイーサネット（登録商標）パケット構成を示す図である。図６ではＭＰＥＧ２−ＴＳＰにタイムスタンプを含む４バイトのヘッダーを付加した拡張ＴＳパケットを７つカプセル化している。そして、拡張ＴＳパケットを識別するための識別値と、カプセルカウンタ値と、拡張ＴＳパケットサイズと、拡張ＴＳパケット数とを含む８バイトのヘッダーを付加して１３５２バイトのスーパーカプセル化している。そして、スーパーカプセルに８バイトのＵＤＰパケットヘッダーを付加して１３５６バイトのＵＤＰパケットとしている。そして、ＵＤＰパケットに２４バイトのＩＰパケットヘッダーを付加して１３８０バイトのＩＰパケット化している。そして、ＩＰパケットに１４バイトのイーサネット（登録商標）ヘッダーと４バイトのチェッ
クサムを付加して１３９８バイトのイーサネット（登録商標）パケット化している。

通信網では、最大伝播パケット単位であるＭＴＵを制限している場合が多い。そして、送出するパケットデータサイズがＭＴＵをオーバーしている場合は、通信網においてパケットを分割する場合が多い。インターネットではこのような処理をフラグメントと言う。フラグメント後に発生したパケットロスやジッタ−の補償を受信側で行うことは困難である。これは、ヘッダー情報の喪失に原因がある。このため本実施の形態においては、スーパーカプセル内の拡張ＴＳパケット数を７つに設定している。これは、イーサネット（登録商標）通信網におけるＭＴＵ１５００バイトに対しイーサネット（登録商標）パケットのデータ領域のデータサイズがオーバーしないようにするためである。

ＭＰＥＧ２−ＴＳＰのデータサイズは、エンコーダーの仕様により１８８バイト固定である。したがって、拡張ＴＳパケットのデータサイズは１９２バイトとなる。そして、イーサネット（登録商標）通信網におけるＭＴＵ１５００バイトを満たしながらスーパーカプセルに格納できる拡張トランスポートパケット数は最大７つとなる。

このように通信網のＭＴＵに応じてスーパーカプセル内に格納する拡張ＴＳパケット数を設定することで、通信網でのフラグメントを防止する。更に前述したカプセルカウント値を付加することと、再送機能を備えることによりパケットロスの補償を受信側に提供することができる。

なお、通信網はイーサネット（登録商標）を使用するインターネットに限定するものではない。例えばＵＳＢを使用しても良く、携帯電話などの無線通信網などであっても良い。また、ＭＴＵもそれらに応じた値に対応可能である。また圧縮方式はＭＰＥＧ２に限定しない。例えば、ＭＰＥＧ４やその他の方式であっても良い。

次に実施の形態１における受信側の例を説明する。図２は実施の形態１におけるコンテンツ受信器の構成を示す図である。図３は個々のパケットを受信して蓄積するまでの動作例を示したフローチャートである。図４は蓄積後再生する時の動作を示したフローチャートである。

図２において、マイコン２９はコンテンツ受信器の各部の制御を行う。受信器２１は、インターネット網などの通信網から図６に示すイーサネット（登録商標）パケットを受信し出力する。インターネット網では様々な通信事業者が様々な方式で通信網を運営しており、受信器２１と後述する送信器３１はそれらの方式に対応するものである。また、その形態や仕様について特に制限はしない。通信網はイーサネット（登録商標）を使用するインターネットに限定するものではなく、ＵＳＢを使用しても良く、または携帯電話などの無線通信網などであっても良い。

イーサネット（登録商標）パケット処理器２２は、イーサネット（登録商標）パケット処理器２２当てのイーサネット（登録商標）パケットにイーサネット（登録商標）のプロトコル処理を行いＵＤＰ／ＩＰパケットを出力する（この処理を図３のＳＴＥＰ５１に示す。また、この出力信号を図５のＳ５に示す）。

図５のＳ５では、受信ＵＤＰ／ＩＰパケットがインターネット網を介した結果ジッタ−とパケットロスが発生していることを意味している。つまりＶＩＤＥＯ１とＤＡＴＡ１を含むパケットは定常的な遅延より大きな遅延が生じている。また、ＶＩＤＥＯ３とＡＵＤＩＯ２を含むパケットは定常的な遅延より小さい遅延が生じている。また、ＶＩＤＥＯ２とＡＵＤＩＯ１を含むパケットは一旦パケットロスとなり後に再送されている。

ここで、図５を用いてインターネットの場合のジッターとパケットロスについて説明する。インターネット網における送信側と受信側の間には、定常的な遅延が存在する。全てのパケットがその定常的な遅延を持って伝達されるのが理想的であり、その場合はジッターやパケットロスは発生しない。しかしながら、実際のインターネット網では、パケットが異なるルートを割り当てられる、パケットの有効時間中に伝達できない為パケットがゲートウェイで削除される、パケットが再送される、などが生じるので、ジッターやパケットロスが発生する。Ｓ５の記載については、定常的な遅延をあえてゼロに表現することで、限られた紙面上ジッターを分かりやすく記している。具体的には、ＶＩＤＥＯ１とＤＡＴＡ１を含むパケットは定常的な遅延より大きな遅延が生じているため、Ｓ４に比べ遅く（遅れているように）記している。ＶＩＤＥＯ３とＡＵＤＩＯ２を含むパケットは定常的な遅延より小さい遅延が生じているためＳ４に比べ早く（進んでいるように）記している。またＶＩＤＥＯ２とＡＵＤＩＯ１を含むパケットは、一旦パケットロスとなり、後に再送されていることを記している。

図２に示すＵＤＰ／ＩＰパケット処理部２３は、ＵＤＰ／ＩＰパケットにＵＤＰ／ＩＰのプロトコル処理を行い、スーパーカプセルを出力する（この処理を図３のＳＴＥＰ５２に示す。また、この出力信号を図５のＳ６に示す）。

以上のイーサネット（登録商標）およびＵＤＰ／ＩＰのプロトコル処理はインターネットで周知であるので説明は省略する。また、イーサネット（登録商標）パケットやＵＤＰパケット処理はここに記した内容に限定せず、受信パケットの種別や通信網の仕様に応じる。また、他の通信プロトコル処理を行う場合もある。

これらの通信プロトコルにはそれぞれのヘッダーにデータ本体のプロトコル処理方法を示す情報が含まれている。各種プロトコルの処理方法については規格化されており、予めコンテンツ受信器はその処理方法を備える事ができる。従って、コンテンツ受信器は、ヘッダー内のプロトコルを示す情報を解析する事により、ヘッダーを削除した後のデータ本体のプロトコル処理を行うことができる。

カプセル処理機２４は、図６で示した個々のスーパーカプセルから、個々のスーパーカプセルのヘッダーを取得する。また、カプセル処理機２４はこのヘッダー内に含まれている構成データの内容を示す情報をマイコン２９に出力する。このデータの内容を示す情報は、カプセル化されたデータのフォーマットタイプを識別するための情報である（この例では前述した拡張ＴＳパケットであることを識別する情報）。また、このデータの内容を示す情報は、カプセル内の拡張ＴＳパケットのパケット長および拡張ＴＳパケット数を示す情報などもある。拡張ＴＳパケットのパケット長および拡張ＴＳパケット数を示す情報はカプセル化された総データ長であっても良い。

マイコン２９は与えられたデータの内容を示す情報を解釈して、カプセル化されているデータが拡張ＴＳパケットであることを認識する（図３のＳＴＥＰ５３） 。またマイコン
２９は、個々の拡張ＴＳパケットのサイズを認識し、蓄積デバイス３２の蓄積領域を確保する。またマイコン２９は、蓄積制御機２８に対し蓄積パケットサイズの設定や個々の拡張ＴＳパケットを記憶する際のアドレス初期設定など準備を行う（図３のＳＴＥＰ５０）。これらの準備は、最初のスーパーカプセルを入力した時点やデータの内容を示す情報に変更があった事を検出してその場合に行ってもよい。

また、カプセル処理機２４はヘッダーに含まれているカプセルカウンタをモニターして、連続性を確認する（図３のＳＴＥＰ５４）。カプセル処理機２４は個々のスーパーカプセルにおけるカプセルカウンタ値を検出して、不連続点のチェックを行う。カプセル処理機２４が不連続点を検出すればカプセルカウンタの推移により不連続性を検証する（図３の
ＳＴＥＰ６４）。

この不連続性が、カプセルカウンタ値が同じかまたは減少する方向の不連続であれば、カプセル処理機２４は、不連続点以後に検出するカプセルカウンタ値が不連続点直前のカプセルカウンタ値を上回り不連続が解消するまでの間のスーパーカプセルを削除する（図
３のＳＴＥＰ６５）。

この不連続性が、カプセルカウンタ値が増加する方向の不連続であれば、カプセル処理器２４は不連続に該当するスーパーカプセルは削除しない。そして、カプセル処理器２４はマイコン２９に不連続点を検出したことを通知して、カプセル処理器２４が受信できなかったスーパーカプセルに該当するカプセルカウンタ値をマイコン２９に出力する。

また、カプセル処理器２４は、ダミー拡張ＴＳパケットで構成されるダミーヘッダーを備えたダミースーパーカプセルを生成する。そして、カプセル処理器２４は、カプセル処理器２４が受信できなかったスーパーカプセルに該当する時間的スペースにこのダミースーパーカプセルを挿入して後段に出力する（図３でのＳＴＥＰ６６）これは、後段で再送パケット挿入処理を簡略化するためである。

マイコン２９はカプセル処理器２４からの通知を受けて、スーパーカプセルを再送指示するための再送コマンドを出力する。このとき、マイコン２９はこの再送コマンドをカプセル処理器２４が受信できなかったスーパーカプセルに該当するカプセルカウンタ値を用いて生成する（図３のＳＴＥＰ６７）。送信器３１は、イーサネット（登録商標）を使用するインターネット網などの通信網を介して、再送コマンドを送信側に送信する。

送信側が再送したスーパーカプセルはヘッダー内に再送であることを示す情報を含んでいるので、カプセル処理器２４において検出が可能である。したがって、カプセル処理器２４は前述した不連続性の検証対象からこれを除外し、後段にそのまま出力する。（図３のＳＴＥＰ５４）。

マイコン２９はカプセル処理器２４から不連続の通知を受けてから直ちに再送コマンド送信の制御を行わなくても良い。マイコン２９は、カプセル処理器２４に対し検出できなかったスーパーカプセルの受信待機を指示してから所定の時間の間、該当するスーパーカプセルが受信できなかった場合に再送コマンド送信の制御を行う場合もある。受信待機を指示してから所定の時間の間に受信できた場合は、カプセル処理器２４は所定のヘッダー内に再送パケットを示す情報を付加して後段に出力する。これは後段で再送パケットと同様に処理させるためである。誤動作を避けるためには、待機時間はカプセルカウンタ値が一巡する時間より短く、そして通信網におけるパケット到着の最大遅延時間より長いことが望ましい。また、ＳＴＥＰ５４、ＳＴＥＰ６４での不連続性の確認および確認後の処理制御は、カプセル処理器２４とマイコン２９でのソフトウェア処理とのどちらかで行なう。

次に、カプセル処理機２４はマイコン２９の制御によってカプセル化されている拡張ＴＳパケットを分離して出力する。ここでは拡張ＴＳパケットに含まれているＭＰＥＧ２−ＴＳＰがスクランブルされている場合や再送パケットの場合も考慮して、個々のＭＰＥＧ２−ＴＳＰとタイムスタンプが含まれているヘッダーを分離して出力する。マイコン２９はＭＰＥＧ２−ＴＳＰがスクランブルされているかを確認する（図３のＳＴＥＰ５５）。

ＭＰＥＧ２−ＴＳＰのヘッダーはスクランブルされているかどうかの情報をスクランブルされる範囲外に持っている。したがって、マイコン２９は一旦ＭＰＥＧ２−ＴＳＰを取り出した後でその情報を確認して、スクランブルされている範囲に対しデスクランブル処
理を行うことができる。どの方式を用いるかを受信側と送信側とで予め決めておくこと、または、受信するテーブル情報を受信側で確認して認識すること、これらのことで任意の方式への対応が可能である。

デスクランブラ２５は、デスクランブラ２５に入力されたＭＰＥＧ２−ＴＳＰを送信側でのスクランブルに対応した方式でデスクランブルして、後段に出力する。一方、タイムスタンプを含んだヘッダーはタイムスタンプバッファー２６においてデスクランブラ２５の処理時間分遅延させてＭＰＥＧ２−ＴＳＰと時間的な同期を取った後、後段に出力する（図３のＳＴＥＰ５６）。

また、マイコン２９は再送パケットかどうかの確認も行う（図３のＳＴＥＰ６８）。再送パケットはヘッダーに再送パケットを示す情報を有している。したがって、マイコン２９はそれを見て再送パケットかどうかを確認する。再送パケットの場合はタイムスタンプに加え再送パケットであることを示す情報とカプセルカウンタ値を更に付加したヘッダーを生成してタイムスタンプバッファー２６に出力する（図３のＳＴＥＰ６９）。

拡張ＴＳ再生器２７は、ＭＰＥＧ２−ＴＳとヘッダーを結合して拡張ＴＳパケットを再生し、出力する。この処理を図３のＳＴＥＰ５７に示す。また、この出力信号を図５のＳ７に示す。蓄積制御器２８は、通信網における遅延あるいはロスにより再取得した拡張ＴＳパケットかどうかの確認をヘッダー情報によって行う（図３のＳＴＥＰ５８）。再送パケットではない場合は、マイコン２９の制御により蓄積デバイス３２上の管理された領域に順次拡張ＴＳパケットを書き込む（図３のＳＴＥＰ５９）。再送パケットである場合は、ＳＴＥＰ６６においてダミー拡張ＴＳパケットとダミースーパーカプセルを生成する。そして、前もって蓄積済みの対応するダミー拡張ＴＳパケットに再取得した拡張ＴＳパケットを上書きする（図３のＳＴＥＰ６０）。

再送された拡張ＴＳパケットにはカプセルカウンタ値が含まれている。またマイコン２９がカプセルカウンタ値と蓄積デバイス３２のアドレス管理を行っている。これらのことから、この上書き制御は、再送された拡張ＴＳパケットを本来の蓄積領域（ダミー拡張ＴＳパケットを一旦蓄積して確保している領域）に蓄積して、蓄積デバイス３２における連続性を補償する（図５のＳ８）。

図５のＳ８では再送されたＶＩＤＥＯ２とＡＵＤＩＯ１の拡張ＴＳパケットが本来の場所に蓄積されている。また、蓄積デバイス３２では到着時刻や送信側での送信時刻を参照せず記憶するため、各拡張ＴＳパケットを効率よく蓄積できる。

なお蓄積デバイス３２はＨＤＤやＤＶＤなどの如何なる蓄積メディアでも良く、半導体メモリでも良い。また、再送制御を簡略化してジッター補償のみの制御とすれば、蓄積デバイス３２に要求される容量も、後述のカウンタが一巡する時間に受信する全ての拡張ＴＳパケットを蓄積できる範囲に少なくなる。

なお図３のＳＴＥＰ５３においてマイコン２９は拡張ＴＳパケットが格納されていないことを確認する。例えばこれが通常のＭＰＥＧ２−ＴＳＰであった場合には、スクランブルされているかどうかを同様に確認する（図３のＳＴＥＰ６１）。そして、スクランブルされている場合はデスクランブラ２５にてデスクランブルする（図３のＳＴＥＰ６２）。そして、拡張ＴＳ再生機２７でタイムスタンプを含むヘッダーを生成し付加して拡張ＴＳパケット化して出力し（図３のＳＴＥＰ６３）、同様に蓄積デバイス３２に蓄積する。この場合も以後の再生処理は共通化できる。ただし、この場合はジッター補償やパケットロス補償は従来例と同じとなる。

次に、再生時の説明を行う。再生制御機３３は、システムクロックをカウントするカウンタを備えている。再生制御機３３は、このカウンタのカウント値とＴＳデコーダ３４から出力されるＰＣＲ信号とを比較した結果が等しくなるように、システムクロックの周波数を制御する。つまり、既存のＭＰＥＧトランスポートシステムをそのまま使用してシステムクロックを再生することができる。したがって、再生時において、ＭＰＥＧトランスポートシステムのスペックを、既存の技術を用いて容易に満たす事ができる。また、マイコン２９の制御により再生制御機３３は蓄積デバイス３２に記憶されている拡張ＴＳパケットを、このシステムクロックに同期させて順次読み出す（図４のＳＴＥＰ７１）。そして、再生制御機３３は、個々のタイムスタンプと前述したカウンタの計数値とが所定のオフセット値を持って合致するタイミングで（図４のＳＴＥＰ７２）タイムスタンプを含むヘッダーを取り外す。そして、再生制御機３３は個々のＭＰＥＧ２−ＴＳＰを後段に出力する。この処理を図４のＳＴＥＰ７３に示す。また、この出力信号を図５のＳ９に示す。

この段階で、送信側でのＭＰＥＧ２−ＴＳは再生されており、通信網において発生したジッタ−は補償されている。なお、送信側において、ＰＣＲ信号をカウントするカウンタとタイムスタンプをカウントするカウンタとの同期は取られている。したがって、再生制御機３３は、ＰＣＲ信号から求められるこのカウンタの計数値と、タイムスタンプとを比較することができる。

ＴＳデコーダー３４はＭＰＥＧ２−ＴＳＰをＡＶデコーダー３５がＡＶデコードできる形態に直して、出力する。ＡＶデコーダー３５は、ＡＶデコーダー３５に入力されるデータをＡＶデコードして出力する。ＳＴＥＰ７２において、タイムスタンプとシステムクロックカウンタ値が一致しなかった場合は、再生制御機３３はその差分を検証する（図４の
ＳＴＥＰ７５）。そして、その差分が再生制御機３３内部のバッファー（図示せず）でジ
ッター補償できる範囲であれば拡張ＴＳパケットはバッファー上で待機させる。その差分が、再生制御機内部のバッファーでジッター補償できる範囲を超える場合は、該当する拡張ＴＳパケットを廃棄するよう制御する（図４のＳＴＥＰ７６）。

次に受信パケット構成について説明する。図６では、スーパーカプセル内の拡張ＴＳパケット数は７つのイーサネット（登録商標）パケット（１３９８バイト）を受信する例を示している。

データ領域は１３５６バイトのＵＤＰ／ＩＰパケットを有しており、更にそのデータ領域は１３５２バイトのスーパーカプセルを有している。スーパーカプセルにはＭＰＥＧ２−ＴＳＰにタイムスタンプを含む４バイトのヘッダーを付加した拡張ＴＳパケットが７つカプセル化されている。また、スーパーカプセルは拡張ＴＳパケットを識別するための識別値とカプセルカウンタ値と拡張ＴＳパケットサイズと拡張ＴＳパケット数を含む８バイトのヘッダーを有している。

通信網においては、最大伝播パケット単位であるＭＴＵを制限している場合が多い。そして、パケットデータサイズがＭＴＵをオーバーしている場合は、通信網においてパケットを分割する場合が多い。

インターネットではこのような処理をフラグメントと言う。フラグメント後に発生したパケットロスやジッタ−の補償を受信側単独で行うことは困難である。したがって、本実施の形態では、スーパーカプセル内の拡張ＴＳパケット数を７つに設定している。これは、イーサネット（登録商標）通信網におけるＭＴＵ１５００バイトに対しイーサネット（登録商標）パケットのデータ領域のデータサイズがオーバーしないようにするためである。

ＭＰＥＧ２−ＴＳＰのデータサイズは、エンコーダーの仕様により１８８バイト固定で
ある。したがって、拡張ＴＳパケットのデータサイズは１９２バイトとなり、イーサネット（登録商標）通信網におけるＭＴＵ１５００バイトを満たしながらスーパーカプセルに格納できる拡張トランスポートパケット数は最大７つとなる。

このようにフラグメントを防止することで、以上に説明したように、通信網においてパケットロスが発生した場合は個々のスーパーカプセルに付加されているカプセルカウント値を利用してロスパケットの再送を要求する。そして、再送されたパケットを蓄積デバイスに蓄積するときにカプセルカウント値を用いてパケットロスの補償を行う。

また、再生時には個々の拡張ＴＳパケットに含まれる再生用タイムスタンプを用いることで、通信網で発生するジッタ−の補償を、システムクロックの精度で正確に行う。更に、前述したようにコンテンツ送信器とコンテンツ受信器とのデコードのタイミングを制御するジッター補償や再送制御するパケットロス補償の連携制御により、それらの補償を確実に効率良く行う。

なお、通信網はイーサネット（登録商標）を使用するインターネットに限定するものではない。例えば、ＵＳＢや、携帯電話などの無線通信網などであっても良い。また圧縮方式はＭＰＥＧ２に限定しない。例えば、ＭＰＥＧ４やその他の方式であっても良い。

また、再生制御器３３はＭＰＥＧ２―ＴＳＰを、コンテンツ受信器から、バス上に接続されるＡＶデコーダーに出力する場合もある。この場合、再生制御器３３はＩＥＥＥ１３９４インターフェース（図示せず）などの外部出力用インターフェースに接続される。また、ＭＰＥＧ２―ＴＳＰはインターフェースにより定められるアイソクロナスパケットに格納される。

また、ＴＳデコーダー３４をＩＥＥＥ１３９４インターフェース（図示せず）などの外部出力用インターフェースに接続し、ＴＳデコーダー３４の出力を外部のＡＶデコーダーに送信する構成としても良い。この場合、外部出力用インターフェースは、インターフェースの規格により定められるアイソクロナスパケットにＭＰＥＧ２−ＴＳＰを格納して出力する。

（実施の形態２）
図１２は実施の形態２によるコンテンツ送信器の構成を示す図である。図１３は実施の形態２によるＩＥＥＥ１３９４インターフェースの構成を示す図である。図１４は実施の形態２によるコンテンツ受信器でのパケット構成の推移を示す図である。図１５と図１６は実施の形態２によるＩＥＥＥ１３９４インターフェースが送信するパケットの構成を示す図である。

図１２において、インターネット網から受信したパケットを蓄積デバイス３２で蓄積するまでの構成および動作は実施の形態１と同じであるので説明は省略する。読み出し制御器３６は、マイコン２９の指示によって蓄積デバイス３２に蓄積されている拡張ＴＳパケットを、拡張ＴＳパケット読み出しクロック生成器３７が生成する所定の周波数のクロックに同期させて読み出す。その場合、図１４のＳ１０で示すように各拡張ＴＳパケット間に所定の時間間隔を挿入して出力する（図１４のＳ１０）。その間隔は、時間間隔挿入後の拡張ＴＳパケットのビットレートがコンテンツ送信器の拡張ＴＳパケット送出時のビットレート以上になるように、クロック再生器３７のクロック周波数に応じて設定される。

ＩＥＥＥ１３９４インターフェース３８は、ＩＥＥＥ１３９４規格に準拠している。また、ＩＥＥＥ１３９４インターフェース３８は、ＩＥＥＥ１３９４インターフェース３８に入力される拡張ＴＳパケットを、アイソクロナス転送モードで出力する（図１４のＳ１１
）。Ｓ１１において、ＩＳＯとはＩＥＥＥ１３９４インターフェースで付加されるヘッダ
ーである。読み出し制御器３６とＩＥＥＥ１３９４インターフェース３８間の伝送信号は、ＭＰＥＧ２−ＴＳと同様にデータ信号、クロック信号、パケットスタート信号、データイネーブル信号で構成される。また、拡張ＴＳパケットを送信する際に、ＩＥＥＥ１３９４インターフェース３８にはマイコンにより拡張ＴＳパケット情報が設定される。これについて説明する。

図１３はＩＥＥＥ１３９４インターフェース３８の構成を示した図である。ＭＰＥＧ２インターフェース４１には、拡張ＴＳパケットのストリームが入力される。ＤＴＣＰ暗号化回路４２は、ＭＰＥＧ２インターフェース４１から出力された拡張ＴＳパケットにＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）規格に則った著作権保護の為の暗号化を行い、出力する。ヘッダー付加回路４３は、ＤＴＣＰ暗号化を行ったパケットにヘッダーを付加して出力する。このヘッダーはアイソクロナス転送するために必要なヘッダーである。

パケットフォーマット情報付加回路４４には、拡張ＴＳパケットのフォーマットを指定する情報がホストインターフェース４６を介してマイコンから入力される。そして、パケットフォーマット情報付加回路４４は、ヘッダーの所定の位置に、アイソクロナス転送するパケットのデータフォーマットを拡張ＴＳパケットと識別するための情報を書き込む処理を行う。

パケットデータサイズ情報付加回路４５には、拡張ＴＳパケットのデータサイズを指定する情報がホストインターフェース４６を介してマイコンから入力される。そして、パケットデータサイズ情報付加回路４５は、その情報を元にアイソクロナスパケットのデータサイズを算出して決定する。あるいは、パケットデータサイズ情報付加回路４５には、拡張ＴＳパケットを格納するアイソクロナスパケットサイズの情報が、ホストインターフェース４６を介してマイコンから入力される。そして、パケットデータサイズ情報付加回路４５は、ヘッダーの所定の位置にアイソクロナス転送するパケットのデータサイズの情報を書き込む処理を行う。

ここで、拡張ＴＳパケットに対する付加ヘッダーについて説明する。図１５と図１６はＭＰＥＧ２パケットについて規定したＩＥＣ６１８８３−４とは異なるフォーマットである。図１５は拡張ＴＳパケットにアイソクロナスヘッダーのみが付加される例を示した図である。この場合はパケットデータサイズのみを図１５に示すデータ長領域に書き込む。もし、拡張ＴＳパケットのデータサイズが１９２バイトであれば、１９２を３倍した５７６バイトと、アイソクロナスヘッダーとデータＣＲＣの１２バイトとを足した５８８バイトを示すデータを図１５のデータ長領域に書き込む。

図１６は、アイソクロナスヘッダーと共通ヘッダーとを拡張ＴＳパケットに有する例を示した図である。ここでは、パケットデータサイズを図１６のアイソクロナスヘッダーのデータ長領域に書き込み、拡張ＴＳパケットを識別する為の情報を共通ヘッダーのフォーマット領域に書き込む。もし、拡張ＴＳパケットのデータサイズが１９２バイトであれば、Ｒｅｓｅｒｖｅｄ領域の４と１９２を加えた数字を３倍した５８８バイトと、アイソクロナスヘッダーと共通ヘッダーとデータＣＲＣの１６バイトと、Ｒｅｓｅｒｖｅｄの４バイトを足した６０８バイトを示すデータを図１６に示す領域書き込む。Ｒｅｓｅｒｖｅｄ領域は将来の拡張のための領域である。拡張ＴＳパケットを識別する為の情報は現在運用されているデータがあれば、それらを除いた範囲で予めコンテンツ送信側と決定されるデータである。

図１５と図１６は、拡張ＴＳパケットが３パケット格納されているアイソクロナスパケ
ットの例であるが、パケット数は３に限定しない。例えば、このパケット数は４でも２でも１でも良い。また、拡張ＴＳパケットのデータサイズは１９２バイトの例であるが、特に限定しない。例えば、拡張ＴＳパケットのデータサイズは１９６バイトであっても良い。

図１３に示すＩＥＥＥ１３９４アイソクロナスパケット送出回路４７は、ＩＥＥＥ１３９４規格に則ったデータリンク層および物理層のプロトコルを実現する回路で構成されている。また、ＩＥＥＥ１３９４アイソクロナスパケット送出回路４７は、ＩＥＥＥ１３９４アイソクロナスパケット送出回路４７に入力されるヘッダーを付加されたパケットを１３９４バスに送出する。

以上説明したように実施の形態２では、ＩＥＥＥ１３９４インターフェースを介して拡張ＴＳパケットを送信可能となる。また、本実施の形態２におけるコンテンツ受信器において、１３９４バス上に、ＴＳデコーダー（図示せず）およびＡＶデコーダ（図示せず）を別途接続した構成としても実施の形態１で説明した効果を実現できる。

以上のように本発明のコンテンツ受信器によれば、通信網において発生するパケットロスを受信側で補償することができずパケットロスが発生した場合にデコードエラーとなってしまうことを防止でき、デジタルテレビジョン放送受信機、パーソナルコンピュータ、携帯電話機、携帯情報端末機および携帯電話アダプターに有用である。

また、本発明のコンテンツ送信器によれば、受信側において、データを蓄積する際に到着時刻を無視して効率よく蓄積デバイスに蓄積できる。また、再生時には、デコーダーに出力する時刻を示すタイムスタンプを用いてデコーダーの求める精度で再生することができる。これにより、ジッター補償精度がデコードする上で不十分な場合にデコードエラーとなることを防止でき、デジタルテレビジョン放送受信機、パーソナルコンピュータ、携帯電話機、携帯情報端末機および携帯電話アダプターに有用である。

本発明の実施の形態１によるコンテンツ送信器のブロック図 本発明の実施の形態１によるコンテンツ受信器のブロック図 本発明の実施の形態１によるコンテンツ受信器での第一の動作フローチャート 本発明の実施の形態１によるコンテンツ受信器での第二の動作フローチャート 本発明の実施の形態１によるパケット構成の推移を示す図 本発明の実施の形態１によるイーサネット（登録商標）パケット構成を示す図 従来のコンテンツ送信器のブロック図 従来のコンテンツ受信器のブロック図 従来のコンテンツ受信器の動作フローチャート 従来のパケット構成の推移を示す図 従来のパケット構成を示す図 本発明の実施の形態２によるコンテンツ受信器のブロック図 本発明の実施の形態２によるコンテンツ受信器のＩＥＥＥ１３９４インターフェースのブロック図 本発明の実施の形態２によるパケット構成推移を示す図 本発明の実施の形態２による第一のＩＥＥＥ１３９４パケット構成を示す図 本発明の実施の形態２による第二のＩＥＥＥ１３９４パケット構成を示す図

符号の説明

１ ビデオエンコーダー
２ オーディオエンコーダー
３ データエンコーダー
４ システムクロック生成器
５ ストリーム多重器
６ スクランブラ
７ タイムスタンプ付加器
８ スーパーカプセル化器
９ ＵＤＰ／ＩＰパケット化器
１０ イーサネット（登録商標）パケット化器
１１ 送信機
１２ 受信機
１３ 再送コマンド検出器
１４ マイコン
１５ 蓄積バッファー
２１ 受信器
２２ イーサネット（登録商標）パケット処理器
２３ ＵＤＰ／ＩＰパケット処理器
２４ カプセル処理器
２５ デスクランブラ
２６ タイムスタンプバッファー
２７ 拡張ＴＳ再生器
２８ 蓄積制御器
２９ マイコン
３１ 送信器
３２ 蓄積デバイス
３３ 再生制御器
３４ ＴＳデコーダー
３５ ＡＶデコーダー
３６ 読み出し制御器
３７ 拡張ＴＳパケット読み出しクロック生成器
３８ ＩＥＥＥ１３９４インターフェース
４１ ＭＰＥＧ２インターフェース
４２ ＤＴＣＰ暗号化回路
４３ ヘッダー付加回路
４４ パケットフォーマット情報付加回路
４５ パケットデータサイズ情報付加回路
４６ ホストインターフェース
４７ ＩＥＥＥ１３９４パケット送出回路

Claims (1)

1. エンコードされたＭＰＥＧ−２ＴＳパケットから構成されるストリームにより形成されるコンテンツをインターフェースから受信し、再生するコンテンツ受信器において、前記コンテンツを受信した後に蓄積する蓄積手段と、ＭＰＥＧシステムクロックを再生するシステムクロック再生手段と、前記システムクロック再生手段の出力するＭＰＥＧシステムクロックを計数し計数値を算出する第１の計数手段と、前記蓄積手段に蓄積された前記コンテンツを再生するデコーダとを備え、前記システムクロック再生手段は、前記デコーダから出力されるＰＣＲ信号と前記第１の計数手段の計数した値とを比較した結果が等しくなるようにＭＰＥＧシステムクロックを再生し、受信するコンテンツを形成する各々のＭＰＥＧ−２ＴＳパケットが、前記ＭＰＥＧ−２ＴＳパケットのエンコード時におけるＭＰＥＧシステムクロックのカウント値を４バイトのタイムスタンプとして付加した拡張ＴＳパケットである場合に、前記蓄積手段に蓄積された各々の前記拡張ＴＳパケットを、前記第１の計数手段の計数値と前記タイムスタンプが所定のオフセット値になるタイミングに前記デコーダへ出力し、
   さらに前記デコーダからストリームを出力するためのインターフェースとを備え、前記拡張ＴＳパケットから構成されるストリームを伝送パケットとして前記インターフェースを介して外部出力する、ことを特徴とするコンテンツ受信器。

Images