JP2005191735A - 圧縮データ送信装置、圧縮データ送信システム、圧縮データ送信方法及びプログラム - Google Patents

Abstract

【課題】コネクションレス型の通信プロトコルを利用して映像等の圧縮データを送信した場合に、映像の途切れ等ができるだけ生じないようにする。
【解決手段】本発明の圧縮データ送信装置は、コネクションレス型の通信プロトコルを利用して圧縮データを送信する圧縮データ送信装置であって、所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信する送信単位データ送信手段と、分割された送信単位データ毎に、再送の要否を示す再送要否データを生成する再送要否データ生成手段とを有する。
【選択図】図６

Description

本発明は、圧縮データ送信装置、圧縮データ送信システム、圧縮データ送信方法及びプログラムに関し、特に、コネクションレス型の通信プロトコルを利用して圧縮データを送信する圧縮データ送信装置、圧縮データ送信システム、圧縮データ送信方法及びプログラムに関する。

従来より、映像等のコンテンツデータを通信ラインを介して送信する技術が広く利用されている。映像あるいは音声のコンテンツデータは、データ圧縮されて、センタ装置等から通信ラインを介して端末装置へ配信される。その映像等のデータが配信される場合、主に２つの方法が利用されている。
１つは、通信プロトコルにおいて、データリンク層及び物理層にイーサネット（Ｒ）等を含む例えばＩＥＥＥ８０２．３を用い、そしてネットワーク層にＩＰを用いた場合、トランスポート層にTCP（Transmission Control Protocol）を用いる方法である。この方法は、TCPは、コネクション型の転送プロトコルであり、通信路を確保してからデータ通信を行うため、データの転送の信頼性が高い。特に、TCPは、データの再送フロー制御機能及び転送途中での配送遅延によるパケットの順序の逆転を補正する順序制御機能を含んでいる点で、データの転送の信頼性が高い。

しかし、TCPは、機能が豊富な反面、その豊富な機能を実現するために転送速度が遅く、リアルタイム処理には不向きであり、さらに、プロトコルヘッダのデータ長も、Ipv4の場合２０バイト（オプション付きで２４バイト）と、長いため、オーバヘッドが大きいという問題がある。

もう１つは、リアルタイム性を重視したデータ転送を行う場合に、通信プロトコルにおいて、トランスポート層にUDP（User Datagram Protocol）を用いる方法である。UDPは、コネクションレス型の転送プロトコルであり、再送フロー制御機能及び順序制御機能を有していないが、ＵＤＰのプロトコルヘッダのデータ長は８バイトであり、TCPに比べて小さい。

従って、映像又は音声のコンテンツをリアルタイムで配信する場合は、通常は、UDPを用いたデータ転送が行われる。代表的なデータ配信は、アプリケーション層にRTP（Realtime Transport Protocol）／RTCP（RTP Control Protocol）を用いたストリーミング配信である（例えば、特許文献１参照）。しかし、このUDPとRTPを用いた場合は、データ抜けは、監視できるが、データの再送制御は行われない。
特開2003-163916号公報（段落番号００３４）

しかし、映像等のデータを、UDP等のコネクションレス型の通信プロトコルを用いたデータ送信方法で配信した場合、全く再送制御が行われないので、受信装置において、圧縮データが解凍されて再生される映像等に、映像あるいは音声の途切れ、バズ音が生じてしまうことがある。映像の途切れ等は、視聴者に認識され検知されてしまうため、視聴者にとっては、高品位の映像等が提供されているとは感じられない。

本発明は、コネクションレス型の通信プロトコルを利用して映像等の圧縮データを送信する場合に、映像の途切れ等ができるだけ生じないようにするための圧縮データ送信装置を提供することを目的とする。

本発明の圧縮データ送信装置は、コネクションレス型の通信プロトコルを利用して圧縮データを送信する圧縮データ送信装置であって、所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信する送信単位データ送信手段と、分割された送信単位データ毎に、再送の要否を示す再送要否データを生成する再送要否データ生成手段とを有する。

本発明によれば、コネクションレス型の通信プロトコルを利用して映像等の圧縮データを送信した場合に、映像の途切れ等ができるだけ生じないようにすることができる。

以下、図面を参照して本発明の実施の形態を説明する。

（第１の実施の形態）
まず、図１に基づき、本実施の形態に係わる圧縮データ送信システムの構成を説明する。図１は、本実施の形態に係わる圧縮データ送信システムの構成を示す構成図である。

図１に示される圧縮データ送受信システムは、例えば、屋内の、ある部屋に設置されたコンテンツサーバ１から送信された映像等のコンテンツを、他の部屋に設置されたクライアント２においてユーザが視聴するためのシステムである。この圧縮データ送信システムにおいて、センタ装置であるコンテンツサーバ１は、映像等のコンテンツデータが記録された記憶装置を有し、無線LANの通信によって、端末装置であるクライアント２とデータ通信を行う。コンテンツサーバ１は、コンテンツのデータとしては圧縮されたデータ形式でクライアント２へ送信し、クライアント２においてその圧縮データを解凍して映像等の再生が行われる。なお、クライアント２は、テレビ受像機の機能も有する端末装置である。

また、本実施の形態では、サーバ１からクライアント２へ送信されるデータは、MPEG（Moving Picture Expert Group）2のデータ圧縮方式で圧縮されたデータ、特にMPEG2-TS(Transport Stream)形式のデータとして説明しているが、MPEG2-PS(Program Stream)形式及びMPEG４等の他の圧縮方式による形式でもよい。

なお、コンテンツサーバ１は、例えば、DVD（Digital Versatile Disk）等のデータを記憶装置にストアし、後述するような無線通信によってそのストアされたデータをテレビ受像機等のクライアント２へ送信する装置であってもよい。

また、クライアント２がテレビ受像機である場合、コンテンツサーバ１は、テレビ受像機に対する、いわゆるセットトップボックスであってもよい。その場合、そのセットトップボックスが、コンテンツサーバ装置として、テレビ受像機に無線通信によって圧縮データを送信する。さらに、そのセットトップボックスに対して、他のコンテンツサーバから、圧縮データを送信するようにしてもよく、その場合、そのセットトップボックスがクライアント２であり、他のコンテンツサーバがサーバとなって、無線通信によって圧縮データを送信する。

図２は、コンテンツサーバ１及びクライアント２のブロック構成を示すブロック図である。

図２に示すように、コンテンツサーバ（以下、単にサーバという）１とクライアント２は、無線ＬＡＮのネットワーク３を介して接続されている。サーバ１は、中央処理装置（以下、CPUという）１１と、ハードディスク等の記憶装置１２と、読み出し専用メモリ（以下、ROMという）１３と、ランダムアクセスメモリ（以下、RAMという）１４と、ネットワークインターフェース（以下、I/Fと略す）１５とを有する。CPU１１、ROM１２及びRAM１３は、それぞれデータバス１６に接続され、相互にデータの授受ができるようになっている。CPU１１と記憶装置１２とは、別途接続され、相互にデータの授受ができるようになっている。CPU１１は、ネットワークI/F１５を介して、クライアント２とデータ通信を行うことができる。

クライアント２は、CPU２１と、ROM２２と、RAM２３と、ネットワークI/F２４とを有する。CPU２１、ROM２２及びRAM２３は、それぞれデータバス２５に接続され、相互にデータの授受ができるようになっている。CPU２１は、ネットワークI/F２４を介して、サーバ１とデータ通信を行うことができる。クライアント２は、さらに、デジタルテレビ放送受信用のアンテナ２６と、そのアンテナ２６で受信した信号を処理するチューナ２７と、チューナ２７からのデータをデコードするMPEG2デコーダ２８と、MPEG2デコーダ２８がデコード時に使用するメモリ２９と、MPEG２デコーダ２８においてデコードされた映像等を画面上に映し出すディスプレイ３０とを含む。

MPEG2デコーダ２８は、チューナ２７からの受信データだけでなく、CPU２１からの、ネットワークI/F２４を介して受信したサーバ１からの受信データも、デコードするが、本実施の形態では、サーバ１からの映像等のデータを、ネットワーク３を介して受信してディスプレイへの表示等を行う点に特徴があるので、アンテナ２６によってデジタルテレビ放送を受信する部分の機能についての説明は省略する。

サーバ１の記憶装置１２には、映像及び音声のコンテンツデータがMPEG2のデータ圧縮形式で、ストアされている。
図３は、記憶装置１２にストアされているコンテンツデータを説明するための図である。MPEG2の形式で圧縮された映画等のコンテンツデータが、所定のデータ単位に分割されて、記憶されている。図３に示すように、あるコンテンツ４１が、所定のデータ単位に、具体的には、ここでは、所定の通信プロトコルにおけるアプリケーション層であるRTPプロトコルのデータ転送単位に、分割されて、ｎ個のパケットデータ４１−１、４１−２、４１−３、・・４１−ｎとして、記憶装置１２にストアされている。各パケットデータには、パケット番号が付けられており、後述するように、サーバ１及びクライアント２は、送信あるいは受信されたパケットデータを、パケット番号によって識別することができる。

図３に示すようなデータの分割は、CPU１１によって、ROM１３にストアされたプログラムをRAM１２に読み出して実行することによって行われる。例えば、DVD等に記憶された圧縮データ、あるいはインターネット等を介して受信して記憶装置１２に記憶された圧縮データに対して、そのプログラムを実行することによって、分割されたパケットデータが生成される。

図４は、サーバ１とクライアント２の間で行われる通信のプロトコルスタックを示す図である。データリンク層５１にIEEE802.3を、ネットワーク層５２にIPを、トランスポート層５３にUDPを、アプリケーション層５４にRTP/RTCPを利用している。IEEE802.3を利用して、IPプロトコルの通信を行い、そのIPプロトコルを利用して、UDPプロトコルの通信を行い、UDPプロトコルを利用して、RTP/RTCPプロトコルの通信を行い、RTP/RTCPプロトコルを利用して通信が行われるように、通信プロトコルは多層化されている。物理層では、無線通信を行う回路が利用される。

図５は、MPEG2のTSパケット（以下、MPEG2-TSパケットという）を上述した多層化された通信プロトコルを利用して、サーバ１からクライアント２へ送信するときのデータ構造を説明するための図である。

図５に示すように、複数のMPEG2のTSパケットデータ６３は、映像（Video）PES（Packetized Elementary Stream）パケット６１と音声（Audio）PESパケット６２を含む。映像PES（Packetized Elementary Stream）パケット６１と音声PESパケット６２の各PESパケットは、パケットスタートコードプリフィックス部（Packet start code prefix）と、ストリーム識別子部（stream id）と、PESパケット長部（PES packet length）と、オプションPESヘッダ部（Optional PES header）と、PESパケットデータバイト部（PES packet data bytes）からなる。

１つのMPEG2-TSパケット６３は、ヘッダ部とペイロード部からなり、ペイロード部には、PESパケット６１又は６２のデータが含まれる。１つのMPEG2-TSパケット６３は、例えば１８８バイト長である。
RTPパケット６５は、ヘッダ部（RTP header）とペイロード部（RTP Payload）からなり、ペイロード部には、転送単位データ６４が含まれる。転送単位データ６４は、パケットスタートコードプリフィックス部（Packet start code prefix）と、パケット番号部（packet number）と、パケット長部（Packet length）と、オプションヘッダ部（Optional header）と、ペイロード部からなる。

この転送単位データ６４のペイロード部には、所定の数、ここでは４つ、のMPEG2-TSパケット６３が含まれており、例えば、７５２バイト、すなわち１８８バイトの４倍のバイト長である。

UDPパケット６６は、ヘッダ部（UDP header）とペイロード部（UDP Payload）からなり、ペイロード部には、RTPパケット６５が含まれている。

さらに、IPパケット６７は、ヘッダ部（IP header）とペイロード部（IP Payload）からなり、ペイロード部には、UDPパケット６６が含まれている。

ここでは、４つのMPEG2-TSパケットを、処理単位である１つの転送単位として、RTPプロトコル、UDPプロトコル、及びIPプロトコルによって送信して、RTPプロトコルのレベルにおいて、すなわちRTPプロトコルの転送単位データ毎に、後述する転送データの抜けのチェックが行われる。

言い換えれば、サーバ１には、コンテンツ４１の圧縮データが、４つのMPEG2-TSパケットデータを１つの転送単位データとして、複数のパケットデータに分割して、記憶装置１２にストアされ、上述した構成を有する通信プロトコルを利用することによって、各転送単位データが、サーバ１からクライアント２へネットワークI/F１５から送信される。従って、CPU１１、記憶装置１２及びネットワークI/F１５が、送信単位データ送信手段を構成する。CPU２１及びネットワークI/F２４が、送信単位データ受信手段を構成する。

このコンテンツ４１の圧縮データは、４つのMPEG2-TSパケットデータを１つの転送単位データとして、ｎ個のパケットデータに分割されるが、サーバ１は、パケットデータを生成するとき、あるいは生成した後に、各パケットデータに、所定のデータが含まれているかをチェックし、そのパケット番号毎に、その所定のデータの有無を示すデータを含むデータ内容テーブルを生成する。サーバ１は、そのデータ内容テーブルと所定の参照テーブルとに基づいて、再送管理テーブルを生成する。

図６は、その再送管理テーブルを生成する手順を説明するための図である。データ内容テーブル７１は、パケット番号部と、データの内容を示す内容部とからなるテーブルデータである。各パケットデータ毎に、所定のデータが含まれているか否か、ここでは、例えば、MPEG2-TSパケットのシーケンスヘッダ、音声、Iピクチャ、Bピクチャ及びPピクチャの中のいずれかのデータが含まれているかが、内容部に記述される。例えば、図６において、パケット番号０のパケットデータは、シーケンスヘッダを含み、パケット番号１０００のパケットデータは、Bピクチャを含むことを示している。

このデータ内容テーブル７１と、所定の参照テーブルとしての再送要否参照テーブル７２とに基づいて、再送管理テーブル７３が生成される。再送要否参照テーブル７２は、データの内容に応じて、再送フラグを再送が必要である旨を示す「１」にするか、再送が不要である旨を示す「０」にするかを決定するための参照テーブルである。再送管理テーブル７３は、各パケット毎に決定された再送フラグを含むテーブルである。サーバ１は、再送要否参照テーブル７２を参照しながら、データ内容テーブル７１から、再送管理テーブル７３を生成する。

再送要否参照テーブル７２の内容は、パケットデータの転送単位データが、MPEG2の映像等の再生において、映像の途切れ等が生じる虞の度合いに応じて、すなわち映像又は音声の再生に大きな影響のあるデータを含む場合には、再送が必要であるとして、再送フラグが「１」に予めセットされ、再生に大きな影響のあるデータを含まない場合には、再送が不要であるとして、再送フラグが「０」に予めセットされるように、設定される。従って、MPEG2のシーケンスヘッダ、Iピクチャ等の、そのデータが抜けると、再生に大きな影響のあるデータについては、再送フラグが「１」に設定されている。

図７は、サーバ１が、その再送管理テーブル７３を生成する処理の流れの例を示すフローチャートである。なお、以下に説明する図７及び図９の処理は、ROM１３にプログラムとしてストアされており、CPU１１がそのプログラムをRAM１４に読み出すことによって、実行され、図８の処理は、ROM２２にプログラムとしてストアされており、CPU２１がそのプログラムをRAM２３に読み出すことによって、実行される。

まず、サーバ１のCPU１１は、データ内容テーブル７１から、パケット番号順に各パケット番号の内容部のデータを取得する（ステップ（以下、Sと略す）1）。CPU１１は、再送要否参照テーブル７２を参照して、取得した内容部のデータが再送フラグを「１」にすべきデータを含むか否かを判断する（S2）。取得した内容部のデータが再送フラグを「１」にすべきデータを含む場合は、S2でYESとなって、CPU１１は、そのパケット番号に対応する再送管理テーブル７３の再送フラグを、「１」とする。取得した内容部のデータが再送フラグを「０」にすべきデータを含む場合は、S2でNOとなって、CPU１１は、そのパケット番号に対応する再送管理テーブル７３の再送フラグを、「０」とする。

S3及びS4の処理の後は、CPU１１は、データ内容テーブル７１の全てのパケット番号の内容部のデータについてチェックしたか否かを判断する（S5）。全てのパケット番号の内容部のデータについてチェックしていないときは、処理は、S1に戻る。全てのパケット番号の内容部のデータについてチェックし終わったときは、処理は、終了する。図７の処理が、再送要否データ生成手段を構成する。

サーバ１は、以上のようにして、再送管理テーブル７３を生成し、記憶装置１２あるいはRAM１４にストアし、この再送管理テーブル７３を利用して、後述する再送要求があったときに、再送要求のあった転送単位のパケットデータを再送するか否かを判断する。

以上で、サーバ１の記憶装置１２には、図３に示すような複数のパケットデータからなるコンテンツ４１のデータと、再送管理テーブル７３とがストアされている状態にある。このような状態において、例えば、ユーザがクライアント２のリモコン（図示せず）等を操作して、クライアント２のディスプレイ３０でコンテンツ４１の映像を観たい旨のコマンド信号がクライアント２へ供給されると、クライアント２は、コンテンツ４１の圧縮データの送信要求データをサーバ１へ送信する。サーバ１は、その送信要求データに応じて、コンテンツ４１のデータをクライアント２へ送信する。このとき、コンテンツ４１は、分割されたパケットデータとして送信される。

サーバ１は、この送信管理テーブル７３を生成した後に、上述したUDPプロトコルを利用して、コンテンツ４１のデータをクライアント２へ送信する。

送信されたパケットデータは、クライアント２においてネットワークI/F２４を介して受信され、クライアント２のCPU２１は、受信されたパケットデータに抜けがないかをチェックする。受信されたパケットデータに抜けがあれば、CPU２１は、抜けたパケットデータの再送要求を、サーバ１へ送信する。

図８は、クライアント２において、受信したパケットデータに抜けがあるか否かをチェックし、抜けがあったときに再送要求を行う処理の流れの例を示すフローチャートである。

クライアント２のネットワークI/F２４では、受信したパケットデータをCPU２１へ供給する。CPU２１は、所定の数のパケットデータ毎に、パケットデータに抜けがあるか否かをチェックする（S11）。そして、受信したパケットデータに抜けがあるか否かを判断し（S12）、抜けが有る場合は、S12でYESとなって、CPU２１は、抜けたパケットデータのパケット番号と共にそのパケットデータの再送要求を、サーバ１へ送信する（S13）。受信したパケットデータに抜けがない場合は、S12でNOとなって、CPU２１は、処理は何もしない。図８の処理は、所定の数のパケットデータ毎に実行される。図８において、S11がデータ抜け判断手段を構成し、S12及びS13が再送要求手段を構成する。

図９は、サーバ１において、クライアント２から再送要求があったときに、再送要求のあったデータを送信する処理の流れの例を示すフローチャートである。

図９の処理は、サーバ１がクライアント２から再送要求を受信すると実行される。再送要求を受信すると、CPU１１は、再送要求に係るパケットデータが、再送の必要なデータか否かを、再送管理データ７３に基づいて、判断する（S21）。再送要求に係るパケットデータが、再送の必要なデータであるか否かの判断は、再送管理データ７３において、再送要求に係るパケットデータのパケット番号について、再送フラグが「１」となっているか否かによって判断することができる。

再送要求に係るパケットデータが、再送の必要なデータである場合は、S21でYESとなって、再送要求のあった転送単位のパケットデータを再送する（S22）。再送要求に係るパケットデータが、再送の必要なデータでない場合は、S21でNOとなって、再送要求のあった転送単位のパケットデータは、再送しない旨のメッセージデータを送信する（S23）。図９の処理が、送信単位データ再送手段を構成する。

なお、S23では、再送しない旨のメッセージデータを送信しているが、何も送信しないようにしてもよい。その場合、クライアント２から再送要求が複数回送信されることがあるかもしれないが、MPEG2デコーダ２８におけるデコード処理が終了したものについては、再送要求されないようにすれば、必要以上の回数の再送要求がクライアント２からサーバ１へ送信されることはない。

図１０は、図８と図９の処理によってどのようなデータがサーバ１とクライアント２の間で送受信されるかの例を説明するための図である。

図１０は、クライアント２が、予め決められた数のパケットデータ毎にパケットデータの抜けの有無をチェックし、サーバ１から送信されたパケットデータのうち、パケット番号「４」のデータがクライアント２へ送信できなかった場合を示している。その場合、クライアント２は、サーバ１へパケット番号が「４」のパケットデータを再送するように、サーバ１へ再送要求を送信する。サーバ１は、再送管理テーブル７３を参照して、再送の要否を判断し、再送が必要な場合は、そのデータをクライアント２へ再送し、再送が必要でない場合は、その旨を示すメッセージをクライアント２へ送信する。

以上のように、本実施の形態によれば、サーバ１では、再送要求のあった転送単位のパケットデータについて、再送管理テーブル７３に基づいて再送が必要であるか否かを判断し、再送が必要な転送単位のパケットデータについてのみ、クライアント２へ再送する。このとき、再送管理テーブル７３には、映像の途切れ等が生じる虞のある、すなわち映像又は音声の再生に大きな影響のあるデータを含む場合には、再送が行われるようにするための再送フラグが設定されているので、クライアント２において、映像等の途切れ、バズ音などが少ないコンテンツの再生が行われるので、ユーザは、高品位の映像等を視聴することができる。

本実施の形態における図３におけるパケットデータは、図４におけるRTPの転送単位データであるが、通信プロトコルにおいてRTP以上のアプリケーション層に対応する転送単位データであってもよい。

（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。第２の実施の形態に係る圧縮データ送信システムの構成は、第１の実施の形態と略同一の構成であるので、同一の構成要素については、同一の符号を付してその詳細な説明は省略し、異なる点を主に説明する。

第１の実施の形態では、抜けのあったパケットデータの再送の要否は、サーバ１によって判断されていたが、第２の実施の形態では、クライアント２によって判断される点が異なる。

第２の実施の形態では、サーバ１が再送管理テーブル７３を生成すると、その再送管理テーブル７３のデータを、クライアント２へ、コネクション型の転送プロトコル、例えばTCPプロトコルを用いて送信する。TCPプロトコルはコネクション型の転送プロトコルであるので、TCPプロトコルの有する再送フロー制御等によって、再送管理テーブル７３のデータは、クライアント２へ確実に送信される。CPU１１、記憶装置１２及びネットワークI/F１５が、参照テーブルである再送管理データを送信する参照テーブル送信手段を構成する
クライアント２側において、ユーザが、上述したようにリモコン等を操作して、コンテンツ４１の送信要求をサーバ１へ送信すると、サーバ１は、コネクションレス型の通信プロトコルであるUDPプロトコルを利用して、クライアント２へコンテンツ１のデータを送信する。

クライアント２は、受信したパケットデータに抜けがあるか否かをチェックし、抜けがあれば、その抜けのあったパケットデータが再送が必要な転送単位のパケットデータであるか否かを、TCPプロトコルによって前もって受信して得ている再送管理テーブルデータ７３に基づいて判断する。そして、再送が必要なパケットデータであるときは、クライアント２は、サーバ１へ再送要求を行う。

図１１は、クライアント２において、受信したパケットデータに抜けがあるか否かをチェックし、抜けがあったときに再送要求が必要な否かを判断して、再送要求を行う処理の流れの例を示すフローチャートである。なお、以下に説明する図１１の処理は、ROM２２にプログラムとしてストアされており、CPU２１がそのプログラムをRAM２３に読み出すことによって、実行される。

クライアント２のネットワークI/F２４では、受信したパケットデータをCPU２１へ供給する。CPU２１は、所定の数のパケットデータ毎に、パケットデータに抜けがあるか否かをチェックする（S31）。そして、受信したパケットデータに抜けがあるか否かを判断し（S32）、抜けが有る場合は、S32でYESとなって、CPU２１は、抜けたパケットデータが再送の必要があるか否かを判断する（S33）。抜けたパケットデータが再送の必要があるか否かの判断は、受信した再送管理テーブル７３に基づいて判断される。具体的には、抜けたパケットデータのパケット番号に対応する再送フラグが「１」であるか否かによって、再送の要否が判断され、再送フラグが「１」であれば、S33でYESとなって、クライアント２は、抜けたパケットデータのパケット番号と共にそのパケットデータの再送要求を、サーバ１へ送信する（S34）。

また、受信したパケットデータに抜けが無い場合、及び受信したパケットデータに抜けがあっても再送フラグが「１」でない場合は、S34の処理は実行しないで処理は、終了する。図１１の処理も、所定の数の受信したパケットデータ毎に実行される。

そして、サーバ１は、再送要求をクライアント２から受信すると、再送要求に係る転送単位のパケットデータをUDPプロトコルを利用して再送する。

図１２は、図１１の処理によってどのようなデータがサーバ１とクライアント２の間で送受信されるかの例を説明するための図である。

図１２は、サーバ１から送信されたパケットデータのうち、パケット番号「４」のデータがクライアント２へ送信できなかった場合を示している。クライアント２は、予め決められた数のパケットデータ毎に、パケットデータの抜けの有無をチェックし、さらに、抜けたパケットデータが再送が必要か否かを判断し、再送が必要なパケットデータのみ、サーバ１へ再送要求を行う場合を示している。すなわち、クライアント２は、サーバ１へ抜けた全てのパケットデータの再送要求を行うのではなく、再送管理テーブル７３を参照して再送が必要なパケットデータのみ、コネクションレス型の通信プロトコルであるUDPプロトコルを利用して、再送要求を行う。ここでは、パケット番号が「４」のパケットデータに係る再送フラグは「１」であるので、パケット番号が「４」のパケットデータを再送するように、サーバ１へ再送要求を送信する。再送が必要でない場合は、クライアント２は、再送要求をサーバ１へ送信しない。

以上のように、本実施の形態によれば、クライアント２は、転送単位のパケットデータについて、再送管理テーブル７３に基づいて再送が必要であるか否かを判断し、再送が必要な転送単位のパケットデータについてのみ、サーバ１へ再送要求を行う。従って、再送管理テーブル７３には、映像の途切れ等が生じる虞のある、すなわち映像又は音声の再生に大きな影響のあるデータを含む場合には、再送が行われるようにするための再送フラグが設定されているので、第１の実施の形態と同様に、クライアント２において、映像等の途切れ、バズ音などが少ないコンテンツの再生が行われるので、ユーザは、高品位の映像等を視聴することができる。

以上説明した第１及び第２の実施の形態によれば、コネクションレス型の通信プロトコルを利用して映像等の圧縮データを送信する場合に、出来るだけ映像の途切れ等が生じないようにするための圧縮データ送信装置を実現することができる。

なお、上述した２つの実施の形態における再送管理テーブル７３の再送フラグは、再送の要否を「１」又は「０」の２つの状態を有していたが、再送管理テーブル７３の再送フラグは、圧縮データの映像又は音声の再生への影響の度合いに応じた優先度のレベルを示すフラグあるいはコードのデータであってもよい。

上述したように、MPEG2システムでは、映像のビットストリームデータには、３種類のピクチャがあり、それぞれIピクチャ、Pピクチャ及びBピクチャと呼ばれている。フレーム内の情報のみで、圧縮符号化が行われるIピクチャが最も符号量が多く、過去のフレームを利用して圧縮を行うPピクチャ、過去と未来の双方向フレームを利用して圧縮を行うBピクチャの順に符号量が少なくなる。従って、クライアント２からの再送要求において、どこまでサーバ１が応えるかに応じて、転送エラー時のコンテンツの再生品位が決定される。

すなわち、再生品位を決める映像等の情報に優先順位をつけ、その優先順位に従って再送要求あるいは再送するように、サーバ１とクライアント２との間で予め取り決めておく。例えば、レベル１として音声データは再送し、レベル２としてレベル１に加えてピクチャヘッダ情報を再送し、レベル３としてレベル２に加えてIピクチャを再送し、レベル４としてレベル３に加えてPピクチャを再送する、等々の複数のレベルを設定する。そして、サーバ１とクライアント２は、どのレベルで再送あるいは再送要求をするかを予め決定し、その決定されたレベルに応じて、再送要否参照テーブルを設定して、再送管理テーブルを生成する。その再送管理テーブルに基づいて、再送又は再送要求がされることによって、予め決定した優先順位に応じた再生品位の映像が再生されることになる。

次に、この優先度の具体的な別の例を説明する。図１３は、そのような優先度のレベルを示すフラグ有する再送管理テーブルを生成する手順を説明するための図である。上述したように、データ内容テーブル７１は、パケット番号部と、データの内容を示す内容部とからなるテーブルデータである。このデータ内容テーブル７１と再送要否参照テーブル９２とに基づいて、再送管理テーブル９３が生成される。再送要否参照テーブル９２は、データの内容に応じて、再送フラグを再送が必要である旨を示す「２」にするか、ネットワーク３のトラフィックに予め決められた閾値以上の余裕があるときは再送する旨を示す「１」にするか、あるいは再送が不要である旨を示す「０」にするかを決定するための参照テーブルである。再送管理テーブル９３は、各パケット毎に決定された、優先度レベルを有する再送フラグを含むテーブルである。サーバ１は、再送要否参照テーブル９２を参照しながら、データ内容テーブル７１から、再送管理テーブル９３を生成する。

この再送要否参照テーブル９２の内容は、パケットデータに含まれる転送単位データが、MPEG2の映像再生において、映像の途切れ等が生じる虞のある、すなわち映像又は音声の再生に大きな影響のあるデータを含む場合には、再送が必要であるとして、再送フラグが「２」に予めセットされ、再送が必要であるが、トラフィックに余裕があるときは再送が必要であるとして、再送フラグが「１」に予めセットされ、再生に大きな影響のあるデータを含まない場合には、再送が不要であるとして、再送フラグが「０」に予めセットされるように、設定される。従って、MPEG2のシーケンスヘッダ、Iピクチャ等の、そのデータが抜けると、再生に大きな影響のあるデータについては、再送フラグが「２」に設定されている。

トラフィックに予め決められた閾値以上の余裕があるか否かを判断するために、トラフィックモニタが、第１の実施の形態の場合はサーバ１に、第２の実施の形態であればクライアント２に設けられる。そして、第１の実施の形態の場合は、サーバ１は、再送要求のあったパケットデータに係る再送フラグが、「２」のときはそのパケットデータを再送し、「０」のときはそのパケットデータを再送しないが、「１」のときはトラフィックモニタからのトラフィックの状態が、予め決められた閾値以上の余裕があるときはそのパケットデータを再送する。

第２の実施の形態の場合は、クライアント２は、抜けたパケットデータに係る再送フラグが、「２」のときはそのパケットデータの再送要求を送信し、「０」のときはそのパケットデータの再送要求を送信しないが、「１」のときはトラフィックモニタからのトラフィックの状態が、予め決められた閾値以上の余裕があるときはそのパケットデータの再送要求を送信する。

以上のように、再送するパケットデータの優先度を、再送管理テーブルに設定することによって、その優先度に応じて、抜けたパケットデータの再送が行われるようにすることができる。

さらに、なお、上述した２つの実施の形態では、屋内等のサーバからコンテンツの圧縮データが、クライアントに送信される例であるが、クライアントとサーバが、インターネットを介して接続されているような場合であっても、本発明は適用できるものである。図１４は、インターネットを介してサーバとクライアントが接続されているシステムを示す構成図である。図１４に示すように、コンテンツのデータを蓄積しているサーバ１０１と、クライアント１０２が、インターネット１０３を介して、上述したようなコネクションレス型の通信プロトコルを利用して接続されている。これらのサーバ１０１とクライアント１０２は、第１又は第２の実施の形態において説明したような再送管理テーブルに基づいて、再送要求を行う。

以上のように、本発明の実施の形態によれば、コネクションレス型の通信プロトコルを利用して映像等の圧縮データを送信した場合に、映像の途切れ等ができるだけ生じないようにすることができる。

なお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明の圧縮データ送信システムを実現することができる。

本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明は、家庭内の通信環境だけでなく、家庭内以外の他の通信環境においても適用できるものである。

本発明の第１の実施の形態に係わる圧縮データ送信システムの構成を示す構成図である。 本発明の第１の実施の形態に係わるコンテンツサーバ及びクライアントのブロック構成を示すブロック図である。 記憶装置にストアされているコンテンツデータを説明するための図である。 サーバとクライアントの間で行われる通信のプロトコルスタックを示す図である。 多層化された通信プロトコルを利用して、サーバからクライアントへ送信するときのデータ構造を説明するための図である。 再送管理テーブルを生成する手順を説明するための図である。 サーバが、再送管理テーブルを生成する処理の流れの例を示すフローチャートである。 クライアントにおいて、受信したパケットデータに抜けがあるか否かをチェックし、抜けがあったときに再送要求を行う処理の流れの例を示すフローチャートである。 サーバにおいて、クライアントから再送要求があったときに、再送要求のあったデータを送信する処理の流れの例を示すフローチャートである。 図８と図９の処理によってどのようなデータがサーバとクライアントの間で送受信されるかの例を説明するための図である。 本発明の第２の実施の形態に係わる再送要求を行う処理の流れの例を示すフローチャートである。 図１１の処理によってどのようなデータがサーバとクライアントの間で送受信されるかの例を説明するための図である。 優先度のレベルを示すフラグ有する再送管理テーブルを生成する手順を説明するための図である。 インターネットを介してサーバとクライアントが接続されているシステムを示す構成図である。

符号の説明

１、１０１ サーバ、２、１０２ クライアント、３ ネットワーク、４１ コンテンツデータ、７１ データ内容テーブル、７２、９２ 参照テーブル、７３，９３ 再送管理テーブル
代理人 弁理士 伊 藤 進

Claims (8)

1. コネクションレス型の通信プロトコルを利用して圧縮データを送信する圧縮データ送信装置であって、
   所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信する送信単位データ送信手段と、
   分割された送信単位データ毎に、再送の要否を示す再送要否データを生成する再送要否データ生成手段と、
   を有することを特徴とする圧縮データ送信装置。
2. 前記送信単位は、前記コネクションレス型の通信プロトコルにおける転送パケットの単位であることを特徴とする請求項１に記載の圧縮データ送信装置。
3. さらに、送信した前記送信単位データについて再送要求を受信すると、再送要求に係る前記送信単位データを再送する送信単位データ再送手段とを有することを特徴とする請求項１又は請求項２に記載の圧縮データ送信装置。
4. 前記再送要否データ生成手段は、前記圧縮データの映像又は音声の再生への影響の度合いに応じて再送の要否が予め設定された参照テーブルに基づいて、前記再送要否データを生成することを特徴とする請求項１から請求項３のいずれかに記載の圧縮データ送信装置。
5. 前記参照テーブルに設定される前記再送の要否に係るデータは、前記影響の度合いに応じた優先度のデータであることを特徴とする請求項４に記載の圧縮データ送信装置。
6. センタ装置からコネクションレス型の通信プロトコルを利用して圧縮データを端末装置へ送信する圧縮データ送信システムであって、
   前記センタ装置は、
   所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信する送信単位データ送信手段と、
   分割された送信単位データ毎に、再送の要否を示す再送要否データを生成する再送要否データ生成手段と、
   を有し、
   前記端末装置は、
   前記センタ装置から送信された前記送信単位データを受信する送信単位データ受信手段と、
   受信した前記送信単位データに抜けがあるか否かを判断するデータ抜け判断手段と、
   データに抜けがあったときに、前記センタ装置へ再送要求を送信する再送要求送信手段と、
   を有することを特徴とする圧縮データ送信システム。
7. センタ装置からコネクションレス型の通信プロトコルを利用して圧縮データを端末装置へ送信する圧縮データ送信方法であって、
   前記センタ装置は、
   所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信し、
   分割された送信単位データ毎に、再送の要否を示す再送要否データを生成し、
   前記端末装置は、
   前記センタ装置から送信された前記送信単位データを受信し、
   受信した前記送信単位データに抜けがあるか否かを判断し、
   データに抜けがあったときに、前記センタ装置へ再送要求を送信することを特徴とする圧縮データ送信方法。
8. センタ装置からコネクションレス型の通信プロトコルを利用して圧縮データを端末装置へ送信する圧縮データ送信方法を実現するためのプログラムであって、
   前記センタ装置が、所定の送信単位の送信単位データに分割された前記圧縮データを前記通信プロトコルを利用して送信し、分割された送信単位データ毎に、再送の要否を示す再送要否データを生成する機能と、
   前記端末装置が、前記センタ装置から送信された前記送信単位データを受信し、受信した前記送信単位データに抜けがあるか否かを判断し、データに抜けがあったときに、前記センタ装置へ再送要求を送信する機能と、
   を実現するためのプログラム。
   

Images