JP2005223433A - ストリーミングデータ送信装置およびストリーミングデータ受信装置 - Google Patents

Abstract

【課題】 ＦＥＣ処理が施されたデータが送信されるデータ配信システムにおいて、データ長が前もってわからないストリーミングデータを送信できるようにする。
【解決手段】 ストリーミングデータ送信装置が、ストリーミングデータを複数送信単位分だけバッファリングし、そのバッファリングデータに対してＦＥＣ処理を施し、その結果のデータを送信する。
【選択図】 図３

Description

本発明は、に関する。

従来、データ送信において、受信側の確認応答（ＡＣＫ）の手順を経ずにデータ送信を実行する方式がある。ＩＰ（Ｉｎｔｅｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）上で用いられるＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が、このような方式の典型例である。このような確認応答のないデータ送信においては、送信されるデータの欠落の有無を送信側も受信側も検出できないので、データ通信の信頼性に欠けるという問題がある。

そこで、送信するデータそのものに配信の信頼性を高めるための加工を施す方法が考えられている。例えば特許文献１では、送信するデータにＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）処理を施すことで送信データの冗長性を高め、受信側が一部の送信データを受信できなくとも、残りの受信データから元のデータを復元する技術が開示されている。
特開平２０００―７８１９１号公報

しかし、上記の技術では、あらかじめ決められた長さのデータをＦＥＣ処理するようになっているため、送信できるデータの長さがそのあらかじめ決められた長さを越えることができない。したがって、ストリーミングデータのような、送信するデータの長さがあらかじめわからないデータを送信することができず、上記特許文献１にもそれを解決する方法についての記載がない。

本発明は上記点に鑑み、ＦＥＣ処理が施されたデータが送信されるデータ配信システムにおいて、ストリーミングデータを送信できるようにすることを目的とする。

上記のような課題を解決するための本発明の第１の特徴は、ストリーミングデータ送信装置が、ストリーミングデータを複数送信単位分バッファリングし、そのバッファリングデータに対してＦＥＣ処理を施し、その結果のＦＥＣ化データを送信することである。

このようになっているので、ＦＥＣ処理が施されたデータが送信されるデータ配信システムにおいて、ストリーミングデータが複数送信単位分バッファリングされ、そのバッファリングデータ毎にＦＥＣ処理が施されるので、ストリーミングデータをＦＥＣ処理して送信できるようになる。

なお、「送信単位」とは、例えばフレーム、パケット等のデータ伝送の単位をいう。

また、「複数送信単位分バッファリングする」とは、複数単位分たまるまで記憶することをいう。

また、データの送信を無線により行うことを考慮すると、例えば最終的に受信側にデータを送出する無線基地局の通信可能範囲が離散的に配置されている場合等、受信側が連続的に送信データを受信することができない場合がある。このような場合にも、ストリーミングデータのような時系列的な連続性のあるデータをとぎれなく再生したいという要請がある。

本発明の第２の特徴は、ストリーミングデータ送信装置が、ＦＥＣ化データを、このＦＥＣ化データの元となるバッファリングデータのデータレートより高い伝送容量で無線送信することであり、これによって、受信側が連続的に送信データを受信できないような環境でもストリーミングデータの途切れがない再生を行える場合がある。

なお、「ＦＥＣ化データの元となるバッファリングデータ」とは、当該ＦＥＣ化データがＦＥＣ処理される前のバッファリングデータをいう。

また、データレートとは、バッファリングデータの単位時間の再生のために用いるデータのビット数をいう。

また、本発明の第３の特徴は、送信手段は、それぞれ異なるバッファリングデータを元とする複数のＦＥＣ化データを同時に送信することである。ここで、「バッファリングデータを元とするＦＥＣ化データ」とは、「そのバッファリングデータを前記処理手段がＦＥＣ処理を施した結果であるＦＥＣ化データ」という意味である。

このようになっていることで、一度に１つのバッファリングデータを元とするＦＥＣ化データのみを送信するような場合に比べ、１つのバッファリングデータを元とするＦＥＣ化データを送信できる期間を長くすることができる。

また、本発明の第４の特徴は、送信手段は、ストリーミングデータ受信装置を搭載した車両の走行路に沿った複数の無線セルを構成し、この複数の無線セルから同じＦＥＣ化データを同時に送信し、車両が複数の無線セルのうち１つの無線セルを出てから隣の無線セルに入るまでの期間が、１つのバッファリングデータを元とするＦＥＣ化データを送信し続ける期間から、ストリーミングデータ受信装置が当該バッファリングデータを復元するためのＦＥＣ化データの受信にかかる期間を減算した期間より短いことである。

このようになっているので、車両が無線セルと無線セルの間を走行しているうちにバッファリングデータを復元するのに必要なＦＥＣ化データの受信機会を逃すことを防ぐことができる。なお、「車両が複数の無線セルのうち１つの無線セルを出てから隣の無線セルに入るまでの期間」については、例えば車両の特定の道路における平均速度、あるいは予想最低速度を用いて算出することができる。

また、ストリーミングデータは、動画または音楽のストリーミングデータであってもよいし、繰り返し撮影された静止画が連続するストリーミングデータであってもよい。繰り返し撮影された静止画が連続するストリーミングデータの場合、記憶媒体は、ストリーミングデータを静止画の所定枚数分バッファリングするようになっていると区切りがよい。

また、本発明の第５の特徴は、ＦＥＣ化データに、バッファリングされる順に循環的にバッファリングデータに割り当てられる循環識別符号のうち、当該ＦＥＣ化データの元となるバッファリングデータに割り当てられた循環識別符号が付与されて送信されることである。

このように循環識別符号を用いることで、識別符号は循環的に繰り返し用いられるので、識別符号の枯渇やの識別符号のデータ量の増大によるデータ伝送効率の低下を防ぐことができる。

また、循環識別符号は、複数回進むと元の符号に戻るような循環識別符号において、この複数回は、送信手段が同時送信するＦＥＣ化データの元となるバッファリングデータの数の２倍よりも多くてもよい。

また、バッファリングデータに循環的に割り当てられる循環識別符号の組は、当該ＦＥＣ化データの元となるストリーミングデータの種類毎に異なっていてもよい。

また、本発明の第６の特徴は、ストリーミングデータ受信装置が、上記したようなストリーミングデータ送信装置から送信されたＦＥＣ化データを受信する受信手段と、この受信したＦＥＣ化データから当該ＦＥＣ化データの元となるバッファリングデータを復元する復元手段と、この復元したバッファリングデータのデータレートに基づいて、当該バッファリングデータから成るストリーミングデータを再生するための処理を行う再生制御手段と、を備えることである。

このようなストリーミングデータ受信装置が、上記したようなストリーミングデータ送信装置からのＦＥＣ化データを受信、復元して再生のための処理を行うので、ＦＥＣ処理が施されたデータが送信されるデータ配信システムにおいて、トリーミングデータをＦＥＣ処理して送信できるようになる。

また、復元手段は、ＦＥＣ化データに付与された循環識別符号に基づいて、受信したＦＥＣ化データからＦＥＣ化データの元となるバッファリングデータを復元するようになっていてもよい。

また、復元手段は、並列的に複数の異なるバッファリングデータを復元するため、１度に１つのバッファリングデータを復元する個別復元手段を複数有し、受信したＦＥＣ化データに付与された循環識別符号に基づいて、当該ＦＥＣ化データを前記個別復元手段のいずれか１つに復元させるようになっていてもよい。

また、個別復元手段は、復元したバッファリングデータを共通の記憶媒体に記憶させ、 再生制御手段は、共通の記憶媒体に記憶されたバッファリングデータに記述された時間情報に基づいて、バッファリングデータから成るストリーミングデータを再生するための処理を行うようになっていてもよい。

また、復元手段は、個別復元手段をＭ個有しており、前記個別復元手段のそれぞれが復元しているバッファリングデータに割り当てられた循環識別符号が、それぞれ循環識別符号Ｘないし循環識別符号ＸからＭ−１個先の循環識別符号であるとき、前記循環識別符号ＸからＭ個以上先であり、かつ前記循環識別符号ＸからＭ個前よりも前である識別符号が付与されたＦＥＣ化データを受信手段が受信したとき、循環識別符号Ｘが割り当てられたバッファリングデータの復元を行う個別復元手段の処理をキャンセルさせるようになっていてもよい。

このようにすることで、上記したように先に進んだバッファリングデータを元とするＦＥＣ化データを受信することで、現在のバッファリングデータのＦＥＣ化データを受信することができないとして、その復元をキャンセルすることで、もはや受信できなくなったＦＥＣ化データの復元を個別復元手段が続けてしまうことを防止できる。

また、１度に１つのバッファリングデータを復元するようなストリーミングデータ受信装置においては、受信手段が受信したＦＥＣ化データに付与されている循環識別符号のうち、最も先の循環識別符号が割り当てられたバッファリングデータを復元するようになっていてもよい。このようにすることで、ストリーミングデータ受信装置は、その時の最も最新の、すなわちその時以降の送信期間が最も長い可能性の高いバッファリングデータを元とするＦＥＣ化データを復元することができる。

また、復元手段は、個別復元手段のバッファリングデータの復元を開始してから規定時間経過しても当該バッファリングデータの復元を完了しないとき、当該バッファリングデータを有するストリーミングデータの復元をリセットしてもよい。この規定時間は、ストリーミングデータ送信装置において用いられる循環識別符号が一巡する時間から余裕時間を減算した時間であり、余裕時間は、ストリーミングデータ送信装置において１つのＩＤが用いられてから次のＩＤが用いられるまでの時間の平均値に、個別復号手段の数の２倍を乗算したものである。

このようにすることで、個別復元手段が、循環識別符号が一巡してしまうことで別個のバッファリングデータを元とする同じ循環符号が付与されたＦＥＣ化データを、同じバッファリングデータを元とするＦＥＣ化データであるかのように復元しようとすることを防ぐことができる。

（第１実施形態）
図１に、本発明の第１実施形態に係る情報配信システム１００の構成図を示す。情報配信システム１００は、ストリーミングサーバ１、符号化サーバ２、無線ＬＡＮアクセスポイント４〜６、車両１０に搭載されるストリーミングデータ受信装置１１を有している。

ストリーミングサーバ１によって生成された音楽、画像等のストリーミングデータは、符号化サーバ２によってＦＥＣ処理を施された後、インターネット等の広域ネットワーク３を介して無線ＬＡＮアクセスポイント４〜６からＦＥＣ化データとして送信される。そして、無線ＬＡＮアクセスポイント４〜６の形成する円錐形の無線セル７〜９のいずれかに車両１０が進入すると、ストリーミングデータ受信装置１１は対応する無線ＬＡＮアクセスポイントから当該ＦＥＣ化データを受信し、受信したデータを元にストリーミングデータを復元し、そのストリーミングデータを再生する。

図２に、ストリーミングサーバ１、符号化サーバ２、ストリーミングデータ受信装置１１等の構成図を示す。

ストリーミングサーバ１は、カメラ１２、マイク１３等から継続的に入力され時間的に変化する映像、音楽等の信号を受け、その信号をストリーミングデータに変換し、イーサネット（登録商標）回線５１を介して符号化サーバ２に出力する。ストリーミングデータは、特に送信データのサイズが決められないまま連続的に送出されるデータをいう。ストリーミングデータは、例えばＭＰＥＧ２、リアルオーディオ（登録商標）等の形式で送信されることが多い。本実施形態においては、ストリーミングサーバ１としては、イーサネット（登録商標）回線を通じてインターネットにストリーミングデータを送信する、既存のワークステーション、パーソナルコンピュータで実行されるストリーミングエンコーダを用いることができる。

符号化サーバ２は、ストリーミングサーバ１から受けたストリーミングデータを所定時間分バッファリングし、そのバッファリングしたデータ毎に順次まとめて符号化を行い、その符号化したデータをＵＤＰパケット化し、それを無線ＬＡＮアクセスポイント４〜６を介して無線セル７〜９内に送出する。

このような符号化サーバ２は、受信インターフェース（図２中では受信Ｉ／Ｆと記す）２１、ＣＰＵ２２、ＲＡＭ２３（特許請求の範囲の記憶媒体に相当する）、ＲＯＭ２４および送信インターフェース（図２中では送信Ｉ／Ｆと記す）２５を有している。

受信インターフェース２１は、ストリーミングサーバ１が符号化サーバ２に対して出力したストリーミングデータを受信し、それをＣＰＵ２２が認識できる形式に変換してＣＰＵ２２に出力する。このような機能により、ＣＰＵ２２は、受信インターフェース２１を介してストリーミングサーバ１からデータを受けることができる。

送信インターフェース２５は、ＣＰＵ２２から受けたデータを、広域ネットワーク３の通信プロトコルに適合するように加工し、この加工したデータを無線ＬＡＮアクセスポイント４〜６に送信する。このような機能により、ＣＰＵ２２は、送信インターフェース２５にデータを出力することで、送信インターフェース２５を介して無線ＬＡＮアクセスポイント４〜６にデータを送信することができる。

ＣＰＵ２２は、ＲＯＭ２４からプログラムを読み出して実行し、そのプログラムに記述された処理内容に基づいて動作し、その動作において、ＲＡＭ２３およびＲＯＭ２４から情報を読み出し、ＲＡＭ２３に情報を書き込む。またＣＰＵ２２は、その動作中に受信インターフェース２１を介してストリーミングサーバ１からのストリーミングデータを受け、またこのストリーミングデータを処理した後のＵＤＰパケットを送信インターフェース２５を介して無線ＬＡＮアクセスポイント４〜６に送信する。

無線ＬＡＮアクセスポイント４〜６は、符号化サーバ２から受けたＵＤＰパケットを無線ＬＡＮの規格に従って無線送信する公知の送信装置である。アクセスポイント４〜６は、それぞれが形成する無線セル（送信可能範囲）７〜９が離散的になるよう、道路沿いに配置されている。

ストリーミングデータ受信装置１１は、復号クライアント１４およびプレーヤ１５を有している。

復号クライアント１４は、符号化サーバ２から送信されたＵＤＰパケットを無線ＬＡＮアクセスポイント４〜６を介して受信し、受信したＵＤＰパケットから元のストリーミングデータを復元し、復元したストリーミングデータをイーサネット（登録商標）回線５２を介してプレーヤ１５に出力する。

このような復号クライアント１４は、無線ＬＡＮインターフェース（図２中では無線ＬＡＮＩ／Ｆと記す）４１、ＣＰＵ４２、ＲＡＭ４３、ＲＯＭ４４および送信インターフェース（図２中では送信Ｉ／Ｆと記す）４５を有している。

無線ＬＡＮインターフェース４１は、無線ＬＡＮアクセスポイント４〜６から送信されたＵＤＰパケットを図示しないアンテナを介して受信し、それをＣＰ４２が認識できる形式に変換してＣＰＵ４２に出力する。このような機能により、ＣＰＵ４２は、無線ＬＡＮインターフェース４１を介して無線ＬＡＮアクセスポイント４〜６からデータを受けることができる。

送信インターフェース４５は、ＣＰＵ４２から受けたデータを、インターネットのプロトコルに適合するように加工し、この加工したデータをプレーヤ１５に送信する。このような機能により、ＣＰＵ４２は、送信インターフェース４５にデータを出力することで、送信インターフェース４５を介してプレーヤ１５にデータを送信することができる。

ＣＰＵ４２は、ＲＯＭ４４からプログラムを読み出して実行し、そのプログラムに記述された処理内容に基づいて動作し、その動作において、ＲＡＭ４３およびＲＯＭ４４から情報を読み出し、ＲＡＭ４３に情報を書き込む。またＣＰＵ４２は、その動作中に無線ＬＡＮインターフェース４１を介して無線ＬＡＮアクセスポイント４〜６からのＵＤＰパケットを受け、またこのＵＤＰパケットを復元した後のストリーミングデータを送信インターフェース４５を介してプレーヤ１５に送信する。

プレーヤ１５は、復号クライアント１４の送信インターフェース４５からのストリーミングデータを受け、そのストリーミングデータの再生、すなわちストリーミングデータに記述された映像や音のユーザへの表示を行う。プレーヤ１５としては、インターネット回線を介して受けたストリーミングデータを再生するパーソナルコンピュータ、ワークステーションで実行されるムービープレーヤ等を用いることができる。

図３は、このような構成の情報配信システム１００におけるデータの流れを示す図である。この図を用いて符号化サーバ２のＣＰＵ２２の作動について説明する。

まず、ストリーミングサーバ１は、カメラ１２またはマイク１３から連続的に受けている映像、音楽のデータをＭＰＥＧ等のフォーマットにエンコードする（ステップ１１０）。そしてエンコードされたデータをストリーミングデータとし（ステップ１２０）、符号化サーバ２に出力する。

符号化サーバ２のＣＰＵ２２は、受信インターフェース２１を介してストリーミングデータを受けると、ＲＡＭ２３にそのデータをバッファリングする。バッファリングとは、受信したストリーミングデータを、それがあるデータ量に達するまで追記的にＲＡＭ２３に記憶させることをいう。ここで、あるデータ量とは、複数パケット分である。複数パケット分とは、ストリーミングデータを後にＵＤＰデータとして送信するときに、そのＵＤＰデータが複数となるような、ストリーミングデータの量である。

より詳細には、あるデータ量とは、ストリーミングデータの一定時間分である。一定時間分とは、ストリーミングデータが再生されるときの時間が一定となるようなデータ量をいう。従って、ストリーミングデータのビットレートが可変である場合、一定時間分のストリーミングデータのデータサイズ自体は一定でない。なお、ストリーミングデータには、ストリーミングデータのどの部分をどのタイミングで再生するかを指定するタイムスタンプ（特許請求の範囲の時間情報に相当する）が含まれており、そのタイムスタンプに基づいてストリーミングデータの時間を特定することができる。なお、本明細書では、バッファリングされたデータをバッファリングデータと記す。

ＣＰＵ２２は、上記した所定時間分のデータのバッファリングが完了すると、そのバッファリングデータの１まとまりに対して分割・符号化（ＦＥＣ）・符号化パケット生成の処理を施す（ステップ２２０）。

そして、ＣＰＵ２２は、上記処理が施されたデータを、複数のＵＤＰパケットにまとめ（ステップ２３０）、更にそのＵＤＰパケットを送信インターフェース２５を介して送信する（ステップ２４０）。

なお、分割・符号化（ＦＥＣ）・符号化パケット生成の処理の間にも、ＣＰＵ２２は並行して新たに受信データのバッファリングを行うようになっており、そのバッファリングが完了すれば当該バッファリングデータについてステップ２２０、２３０、２４０の処理を行う。

図４に、このようなＣＰＵ２２のステップ２２０および２３０の処理を説明する図を示す。図４中の各矩形３１０〜３５０は、それぞれＣＰＵ２２で処理されるデータを表している。ステップ２１０の処理によりＲＡＭ２３に記憶された所定時間分のバッファリングデータ３１０は、ステップ２２０の処理によって複数の分割データ３１１〜３１８に等分割される。１つのバッファリングデータ３１０を何個に分割するかは、バッファリングデータのデータサイズに関わらず、あらかじめ決められている。

そして、更にステップ２２０の処理により、この分割データ３１１〜３１８に対して符号化処理が施される。具体的には、分割データ３１１〜３１８のそれぞれを要素とするデータ列に対してＲｅｅｄ−Ｓｏｌｏｍｏｎ符号化行列、Ｔｏｒｎａｄｏ符号化行列、ＬＤＰＣ符号化行列等の公知の符号化行列を作用させる。すると、その結果として符号化パケット３２０〜３３５が生成される。このようにして生成された符号化パケット３２０〜３３５は、元となるバッファリングデータ３１０よりもデータ量が多くなっている。すなわち、バッファリングデータ３１０は符号化によって冗長化されている。このように符号化により冗長化された符号化パケット３２０〜３３５は、その全てを受信せずとも、そのパケットのうち必要な量だけ任意のパケットを受信できれば、受信した符号化パケット３２０〜３３５からそのバッファリングデータ３１０を復元することができる。このような復元のできる冗長化をメタパケット化ともいう。

そして、ステップ２３０の処理により、符号化パケット３２０〜３３５のいくつかをまとめて１つのＵＤＰパケットとする。図４においては、例として２つのＵＤＰパケット３４０、３５０を示すが、実際にはもっと多数のＵＤＰパケットが生成される。生成される多数のＵＤＰパケットは、符号化パケット３２０〜３３５のうち例えばランダムに選んだものを含むようになっていればよい。ＣＰＵ２２はＵＤＰパケット３４０、ＵＤＰパケット３５０を生成する際、それぞれに、符号化パケットに加え、その先頭部分にＩＤ３４１、３５１、および通し番号３４２、３５２の情報を付加する。通し番号３４２、３５２は、元となるバッファリングデータ３１０が同じＵＤＰパケット間で同じ値とならないように、当該ＵＤＰパケットの生成時に付与される番号である。ＩＤ３４１、３４２は、元となるバッファリングデータ３１０を識別することができる符号である。したがって、同じバッファリングデータを元とするＵＤＰパケットは同じＩＤを有している。そして、ＵＤＰパケットが生成される元となるバッファリングデータが新しいものとなる度に、その生成されるＵＤＰパケットに付与されるＩＤも更新される。

このＩＤの更新の順序の具体例を図５に示す。図５に円状に配置された丸印のそれぞれが１つのＩＤを表している。各ＩＤに対応する具体的な値は、当該丸印の近傍に記載された番号である。例えば丸印６１はその値が１０のＩＤである。バッファリングデータが新しいものとなる度に、ＩＤ番号はこの図中の矢印に示されるような時計回りに更新される。すなわち、ＩＤとして１０がＵＤＰデータに付与されている場合、次にバッファリングデータが新しくなると、当該バッファリングデータから生成されるＵＤＰパケットにはＩＤとして１１が付与される。このようにＩＤはバッファリングデータが更新されると共に１０→１１→１２→・・・→１９と更新され、１９の次にはまた１０にもどる。このように、付与されるＩＤは循環的な性質を有する循環識別符号である。

このような循環識別符号をＩＤに用いると
、ストリーミングデータをストリーミングサーバ１から次々に受信し、バッファリングデータが次々に更新されても、ＩＤは循環的に繰り返し用いられるので、ＩＤの枯渇やＩＤの桁数の増大によるデータ伝送効率の低下を防ぐことができる。

また、付与するＩＤの組は、送信するストリーミングデータの内容のカテゴリ毎に異なるようになっていてもよい。図６にＩＤの組と、ストリーミングデータの内容のカテゴリとの対応の一例を示す。この図によれば、時事ニュースのカテゴリに対応するストリーミングデータについては、１０から１９までのＩＤの組を用い、スポーツには２０〜２９のＩＤの組を用い、渋滞情報には３０〜３９のＩＤの組を用い、天気予報には４０〜４９のＩＤの組を用いるようになっている。このように、ＩＤの組毎にストリーミングデータの内容のカテゴリが異なると、データの受信側は、特定のカテゴリのストリーミングデータを再生したいとき、そのカテゴリに対応したＩＤのＵＤＰパケットを選択的に受信すればよいということになる。

なお、符号化サーバ２のＣＰＵは、ＵＤＰパケットとして送信するストリーミングデータの内容がどのカテゴリのものであるかは、ストリーミングデータ内にその情報が埋め込まれており、その埋め込まれた情報を読み出すことで特定するようになっていてもよいし、ストリーミングサーバ１から別途その情報を受けるようになっていてもよい。

図７に、以上のようなＣＰＵ２２の作動によりストリーミングサーバ１からストリーミングデータを受信してＵＤＰパケットを送信する符号化サーバ２、の処理のタイミングを示す。図中、下向きが時間の向きに相当する。

この図においては、ストリーミングサーバ１が１つのストリーミングデータの一部を成す単位である、再生時間の等しいデータＳ_１〜Ｓ_７を、順次連続に送信する。符号化サーバ２はそれを受信し、図３のステップ２１０に相当するＣＰＵ２２のバッファリングにより、この２単位（例えばＳ_１とＳ_２）を一定時間分としてＲＡＭ２３に記憶すると、その時点６２〜６４でステップ２２０、２３０に相当する符号化、ＵＤＰパケット化等の処理を開始し、その処理が終了した時点６５〜６７でステップ２４０の処理によりＵＤＰパケットを送信し始める。

そして、次のバッファリングが終了する時点６３、６４、６８まで、当該ＵＤＰパケットの送信を繰り返し続ける。従って、１つのバッファリングデータを元とするＵＤＰパケットの送信期間は、範囲６９に示すように、符号化、あるバッファリングデータについてのＵＤＰパケット化が終了してから、次のバッファリングデータのバッファリングが終了するまでの期間である。

次に、ストリーミングデータ受信装置１１がこの符号化サーバ２によって送信されたＵＤＰパケットを受信して以後の作動について説明する。図３のデータの流れに示すように、復号クライアント１４においては、符号化サーバ２が送信したＵＤＰパケットが受信され（ステップ４１０）、受信したＵＤＰパケットから符号化パケットが抽出され（ステップ４２０）、更にその符号化パケットから分割データ、バッファリングデータが復元され（ステップ４３０）、さらにそのバッファリングデータがストリーミングデータとしてプレーヤ１５に出力される。

更にプレーヤ１５では、復号クライアント１４から出力されたデータの、ＭＰＥＧ等のデコードが行われ（ステップ５１０）、そのデコードの結果の動画データ、音楽データ等が再生される（ステップ５２０）。

以上のようなデータの流れを実現するために復号クライアント１４のＣＰＵ４２が実行するプログラムの構成を図８に示す。なお、以下に示すプログラム間では、ＲＡＭ４３やＣＰＵ４２中のレジスタを介してデータの授受が行えるようになっている。

ＣＰＵ４２は、受信プログラム８０５、２つの個別復元プログラム８１０、８２０、バッファリングプログラム８３０、ストリーム再生プログラム８４０を並列的に実行する。

受信プログラム８０５は、符号化サーバ２から送信されたＵＤＰパケットを受信し、受信したＵＤＰパケットを適宜個別復元プログラム８１０、個別復元プログラム８２０に渡し、さらに個別復元プログラム８１０、個別復元プログラム８２０の作動を制御するためのプログラムである。この受信プログラム８０５の具体的な作動については後述する。

個別復元プログラム８１０は、ＣＰＵ４２によってそれぞれ並列的に実行されるタイマ−プログラム８１１、符号化パケット抽出プログラム８１２、復号・データ復元プログラム８１３を含んでいる。

タイマ−プログラム８１１を実行することにより、ＣＰＵ４２は、その実行開始からの経過時間を計測し、その計測時間が所定の満了時間（特許請求の範囲の規定時間に相当する）に達すると、タイムアウトイベント発生を示すデータを受信プログラム８０５に渡す。

図９に、符号化パケット抽出プログラム８１２および復号・データ復元プログラム８１３の処理を説明する図を示す。図９中の各矩形３１０〜３５０は、それぞれＣＰＵ４２で処理されるデータを表しており、各矩形に割り当てられた番号は図４において同じ番号が割り振られた矩形と同じものである。ただし、受信されるＵＤＰパケット３４０、３５０および符号化パケット３２０〜３３５の数は、図４の処理において生成された符号化パケットよりも少なくてよい。

符号化パケット抽出プログラム８１２を実行することにより、ＣＰＵ４２は、受信プログラム８０５から渡されたＵＤＰパケット（図９のＵＤＰパケット３４０、３５０に相当する）からＩＤ、通し番号等を除去し、符号化パケット（図９の符号化パケット３２０〜３３５に相当する）を抽出し、その抽出した符号化パケットを符号化パケット抽出プログラム８１２に渡す。

復号・データ復元プログラム８１３を実行することにより、ＣＰＵ４２は、符号化パケット抽出プログラム８１２から符号化パケットを受け、受けた符号化パケットがあらかじめ定められた必要な量に達すると、それらの符号化パケットを復号する。復号は、具体的には、必要量の符号化パケットのそれぞれを要素とするデータ列に、そのデータ列に対応した逆符号化行列を作用させる。すると、その結果として復号データ（図９の分割データ３１１〜３１８に相当する）が生成される。そして、この復号データを結合してバッファリングデータ（図９のバッファリングデータ３１０に相当する）を生成する。さらに、生成したバッファリングデータをバッファリングプログラム８３０に渡し、復号完了イベント発生を示すデータを受信プログラム８０５に渡し、個別復元プログラム８１０の実行を終了する。

なお、ＣＰＵ４２は、受信プログラム８０５の実行において、特定のＩＤを有するＵＤＰパケットの復号予約の処理を行うことに基づいて、個別復元プログラム８１０の実行を開始し、それと同時にタイマ−プログラム８１１、符号化パケット抽出プログラム８１２、復号・データ復元プログラム８１３の実行を開始する。そして、受信プログラム８０５が予約キャンセルの旨のデータを個別復元プログラム８１０に渡すと、ＣＰＵ４２は、個別復元プログラム８１０がこのデータを受けたことに基づいて、タイマ−プログラム８１１、符号化パケット抽出プログラム８１２および復号・データ復元プログラム８１３の実行を、個別復元プログラム８１０と共に終了する。

個別復元プログラム８２０、タイマ−プログラム８２１、符号化パケット抽出プログラム８２２、復号・データ復元プログラム８２３の処理の内容は、それぞれ個別復元プログラム８１０、タイマ−プログラム８１１、タイマ−プログラム８２１および符号化パケット抽出プログラム８２２と同等である。ただし、個別復元プログラム８１０、個別復元プログラム８２０は、それぞれ異なるＩＤを有するＵＤＰパケットの復元を行うようになっている。

なお、図２においては、個別復元プログラムは２つ示されているが、２つ以上の個別復元プログラムがそれぞれ異なるＩＤのＵＤＰパケットを復号するようになっていてもよい。なお、同時に実行する個別復元プログラムの数は予め決まっている。

バッファリングプログラム８３０を実行することで、ＣＰＵ４２は、個別復元プログラム８１０、個別復元プログラム８２０等の、複数の個別復元プログラムから渡された複数のバッファリングデータを、ＲＡＭ４３の共通の領域、すなわちバッファに保存する。

ストリーム再生プログラム８４０を実行することで、ＣＰＵ４２は、上記したバッファに保存された複数のバッファリングデータを読み出し、このバッファリングデータに記述された再生のためのタイムスタンプに基づいたタイミングで、当該バッファリングデータを送信インターフェース４５を介してプレーヤ１５に出力する。

ここで、個別復元プログラム８１０、個別復元プログラム８２０を制御する受信プログラム８０５の処理について具体的に説明する。図１０に、受信プログラム８０５のフローチャートを示す。なお、ＣＰＵ４２は、復号クライアント１４の起動後すぐにこの受信プログラム８０５を実行する。

ＣＰＵ４２は受信プログラム８０５の実行を開始すると、まずステップ９１０で変数Ｆｒの値を“ｆａｌｓｅ”に設定する。この変数Ｆｒは、上述した個別復元プログラムが１つも実行されていない場合は“ｆａｌｓｅ”に、１つでも実行されている場合は“ｔｒｕｅ”になるように設けられた変数である。

次にステップ９１５で、無線ＬＡＮインターフェース４１を介してＵＤＰパケットを１つ受信する。なお、図１０においてステップ９１０以外の処理はループ状になっているが、このループの繰り返しによって、順次ＵＤＰパケットを受信することができる。

次にステップ９２０で、変数Ｆｒが“ｔｒｕｅ”であるか否か、すなわち個別復元プログラムが少なくとも１つ実行されているか否かを判定する。

Ｆｒが“ｆａｌｓｅ”の場合、続いてステップ９２５の処理を実行し、予め定められた数だけ個別復元プログラムの予約の処理を行う。この際、予め定められた数をＭ個とすると、用いるＩＤの組のうち、受信したパケットのＩＤから順にＭ個のＩＤを、予約するＭ個の個別復元プログラムのそれぞれに割り当てる。これによって、Ｍ個の個別復元プログラムの実行が始まる。

ステップ９２５に続いてはステップ９３０で、変数Ｆｒの値を“ｔｒｕｅ”に設定する。

ステップ９２０の判定でＦｒが“ｔｒｕｅ”の場合、続いてステップ９３５で、受信したＵＤＰパケットのＩＤを読み出し、このＩＤが新規に受信すべきＩＤであるか否かを判定する。受信したＵＤＰパケットのＩＤが新規に受信すべきＩＤであるか否かについては、各個別復元プログラムが復元しているバッファリングデータに割り当てられたＩＤが、それぞれＸないしＸからＭ−１個先のＩＤであるとすると、受信したＵＤＰパケットのＩＤが、ＸからＭ個以上先であり、かつＸからＭ個前よりも前のＩＤである場合、新規に受信すべきＩＤであると判定し、それ以外の場合には新規に受信すべきＩＤでないと判定する。

図１１に、この新規に受信すべきＩＤであるか否かの判定について説明する図を示す。この図１１において円状に配置された丸印は、図５に記載した丸印と同様の、循環識別符号としてのＩＤを示しており、そのＩＤの更新順は、図１１の実線矢印の示す通り時計回りである。

図１１においては、Ｍ、すなわち、個別復元プログラムの数は２である。この図は、ステップ９３５の時点で個別復元プログラムがＭ＝２個実行されており、それぞれに図１１中の２重丸印７１、７２で示されるＩＤ（値１２および値１３）が割り当てられている場合を示している。この時点で、既にＩＤが１０、１１のバッファリングデータの復元は終了しているものとする。

この時点で、符号化サーバ２からＩＤが１２または１３のＵＤＰパケットを受信している限りは、そのまま当該ＵＤＰパケットを該当するＩＤが割り当てられた個別復元プログラムに復元させるようにすればよい。しかし、図１１中の点線矢印７３で示す範囲の１４〜１９のＩＤ、すなわち１２（Ｘに相当する）のＩＤからＭ＝２個先のＩＤ以上先であり、かつ１２のＩＤからＭ＋１＝３個前のＩＤ以前であるという条件を満たすＩＤが届いた場合、現在復元しているバッファリングデータの復元を中止して、それよりも先のバッファリングデータを復元することができる。

なお、同時送信数がＭの場合においては、ＸのＩＤから上記したような新規に受信すべきＩＤのＵＤＰパケットが送信された場合には、既にＸおよびＸのＭ−１個先のＩＤのＵＤＰパケットの送信は既に終了していると考えられる。したがって、このような場合に上記の通りＸのＩＤのＵＤＰパケットの復元を中止して新たなＩＤのＵＤＰパケットを復元すれば、もはや送信されないＵＤＰパケットを待ち続けて事実上個別復元プログラムの処理がハングアップしてしまうことを防げる。

ステップ９３５で新規に受信すべきＩＤであると判定した場合、続いてステップ９４０で、現在復号している個別復元プログラムの１つ、より具体的には、当該個別復元プログラムのうち、最も古いＩＤのバッファリングデータを復元しているプログラムにもとづく復元処理を中止させる。具体的には、その１つの個別復元プログラムに、予約キャンセルの旨のデータを渡す。これにより、当該データを受けた個別復元プログラムの実行が終了する。

ステップ９３５で新規に受信すべきＩＤでないと判定した場合、およびステップ９３０、９４０に続いては、ステップ９４５で、イベント発生のデータを個別復元プログラムから渡されているかを確認する。具体的には、前回のループにおけるステップ９４５の処理の後に個別復元プログラムから受けたタイムアウトイベント、復号完了イベントの有無を確認する。

復号完了イベントを受けている場合は、続いてステップ９５０で、次の予約を行う。具体的には、復号完了イベントを渡した個別復元プログラム、および現在実行している個別復元プログラムに割り当てられているＩＤのうち、最も新しいＩＤの次のＩＤのＵＤＰパケットの復号予約の処理を行う。

タイムアウトイベントを受けている場合は、続いてステップ９５５で、現在実行している全ての個別復元プログラムの実行をリセット（中断）させる。具体的には、予約キャンセルの旨のデータを現在実行している個別復元プログラム全てに渡す。すなわち、当該タイムアウトイベントを渡した個別復元プログラムに割り当てられたＩＤのバッファリングデータを有するストリーミングデータ全体の復元をリセットする。そして更にステップ９６０で、変数Ｆｒの値を“ｆａｌｓｅ”にセットする。

また、復号完了イベントもタイムアウトイベントも受けていない場合、およびステップ９５０、９６０に続いては、ループの最初であるステップ９１５の処理を実行する。

なお、複数のタイムアウトイベント、復号完了イベントを一度に受けている場合は、それぞれについて、対応するステップ９５０、９５５、９６０の処理を並列的に行ってもよい。

なお、受信プログラム８０５の処理として、ＣＰＵ４２は、この図１０のフローチャートに記載された処理と並行して、符号化サーバ２から受信したＵＤＰパケットのＩＤを特定し、そのＩＤに割り当てられた個別復元プログラムにそのＵＤＰパケットを渡すようになっている。このようになっていることで、個別復元プログラムは、自己に割り当てられたＩＤのＵＤＰパケットを受けて復元処理に用いることができる。

ここで、個別復元プログラムのタイマープログラムにおける所定の満了時間について説明する。所定の満了時間は、符号化サーバ２において用いられる識別符号が一巡する時間から余裕時間を引いた時間である。

ＩＤが一巡する時間とは、符号化サーバ２において、あるバッファリングデータにＸのＩＤが割り当てられてそのＩＤを有するＵＤＰパケットが送信され始めた時点から、そのバッファリングデータを元とするＵＤＰパケットの送信が終了し、次以降のバッファリングデータに割り当てられるＩＤが更新されていき、当該ＸのＩＤが再度バッファリングデータに割り当てられ、そのＩＤを有するＵＤＰパケットが送信され始める時までの時間をいう。

また、余裕時間とは、符号化サーバ２において１つのＩＤが用いられてから次のＩＤが用いられるまでの時間の平均値に、予め定められた個別復元プログラムの同時実行数の２倍を乗算した時間である。１つのＩＤが用いられてから次のＩＤが用いられるまでの時間とは、あるバッファリングデータにＸのＩＤが割り当てられてそのＩＤを有するＵＤＰパケットが送信され始めた時点から、次のバッファリングデータにＸの次のＩＤが割り当てられ、そのＩＤを有するＵＤＰパケットが送信され始めた時点までの時間をいう。

このようになっていることで、ストリーミングデータ受信装置１１の搭載車両が無線セル７〜９の範囲を大きく外れる等、復号クライアント１４が何らかの原因で符号化サーバ２からのＵＤＰパケットを一切受信できなくなった場合においても、上記した満了時間の経過後に、個別復元プログラムの実行をリセットできる。そして、上記したようにＩＤが一巡する前に満了時間に到達するので、受信が再度可能となった場合に、同一のＩＤで異なるバッファリングデータを元とするＵＤＰパケットを受信する恐れがなくなる。

以上のような受信プログラム８０５の処理により、ＣＰＵ４２は、順次受信したＵＤＰパケットを適宜個別復元プログラム８１０、個別復元プログラム８２０に渡すことで同時に複数のバッファリングデータの復元を行わせる（ステップ９２５）。そして、そのＵＤＰパケットが新規に受信すべきＩＤを有している場合（ステップ９３５）、最も古い復号処理を中止し、当該ＵＤＰパケットによる復号を開始する（ステップ９４０）。

そして、タイムアウトイベントが発生すると、当該ストリーミングデータの復元をリセットし（ステップ９５５）、復号完了イベントが発生すると、次のＩＤのバッファリングデータの復号を予約を行う（ステップ９５０）。

また、タイムアウトイベントが発生するまで、受信したＵＤＰパケットを、そのＵＤＰパケットのＩＤが割り当てられた個別復元プログラムに渡して復号させ続ける。

上記のようなデータ配信システムの作動により、符号化サーバ２が、ストリーミングデータを複数パケット分バッファリングし、そのバッファリングデータに対して符号化を施し、その結果のＵＤＰパケットを送信することである。このようになっているので、符号化処理が施されたデータが送信されるデータ配信システムにおいて、ストリーミングデータが複数パケット分バッファリングされ、そのバッファリングデータ毎に符号化処理が施されるので、ストリーミングデータを符号化処理して送信できるようになる。

なお、符号化サーバ２におけるＵＤＰパケットの送信容量（単位時間あたりの送信データ量）および無線ＬＡＮアクセスポイント４〜６におけるＵＤＰパケットの送信容量を、このＵＤＰパケットの元となるバッファリングデータのデータレートより高い値となっていてもよい。これによって、ストリーミングデータ受信装置１１では、バッファリングデータ自体の再生にかかる時間よりも短い時間で、当該バッファリングデータのＵＤＰパケットを受信することが可能になる。したがって、例えば無線セル７〜９が離散的に廃されている場合等、受信側が連続的に送信データを受信できないような環境でもストリーミングデータの途切れがない再生を行える場合がある。

（第２施形態）
次に、本発明の第２実施形態について説明する。本発明が第１実施形態と異なるのは、符号化サーバ２が複数存在することである。

２つの符号化サーバは、それぞれ同じストリーミングサーバ１から同じストリーミングデータを受信し、受信したデータに対して第１実施形態と同等の処理を行う。ただし、各々の符号化サーバ２は、同じストリーミングデータの異なる部分について、バッファリング、符号化、ＵＤＰパケット化、送信等を行う。具体的には、同じストリーミングデータの、そのデータサイズで等分した各部分に対して、それぞれの符号化サーバ２が順番にバッファリング、符号化、ＵＤＰパケット化、送信等の処理を行う。

例えば、符号化サーバ２が２つある場合、１つのストリーミングデータを、そのデータサイズで等分し、その等分した各部を交互に処理する。具体的には、このストリーミングデータの各部を時間順にＳ_１、Ｓ_２、Ｓ_３、Ｓ_４、Ｓ_５、Ｓ_６・・・とすると、第１の符号化サーバ２はＳ_１、Ｓ_３、Ｓ_５に対して処理を行い、第２の符号化サーバ２はＳ_２、Ｓ_４、Ｓ_６に対して処理を行う。このようなストリーミングデータの割り振りは予め定められており、各符号化サーバ２はその定めに従って、どの部分を処理するかを判断し、ストリーミングデータの不要な部分は受信しない、または受信しても捨てるようになっている。なお、ストリーミングデータの部分の分割は、上記したようにデータサイズで等分されていてもよいし、ストリーミングデータに記録された再生時間のタイムスタンプに基づいて再生時間で等分されてもよい。

図１２に、本実施形態において、ストリーミングサーバ１からストリーミングデータを受信してＵＤＰパケットを送信する２つの符号化サーバ２、の処理のタイミングを示すタイミングチャートである。表示の形式は図７と同僚である。以下、第１の符号化サーバ２を符号化サーバ＃１、第２の符号化サーバ２を符号化サーバ＃２と記す。

図１２においては、ストリーミングサーバ１から、１つのストリーミングデータの等サイズの単位部分であるデータＳ_１、Ｓ_２、Ｓ_３、Ｓ_４、Ｓ_５、Ｓ_６、Ｓ_７・・・がこの順に送信されている。符号化サーバ＃１および符号化サーバ＃２は、このストリーミングデータの２単位部分毎に交互に処理するようにあらかじめ定められている。具体的には、符号化サーバ＃１はＳ_１およびＳ_２のデータを受信し、これらをまとめてバッファリングして図３のステップ２１０〜２４０に示した通りの符号化、ＵＤＰパケット化、送信等の処理を行い、次にＳ_５およびＳ_６に対して同じ符号化、ＵＤＰパケット化、送信等の処理を行う。また、符号化サーバ＃２は、Ｓ_１およびＳ_２のデータを受信し、これらをまとめてバッファリングして図３のステップ２１０〜２４０に示した通りの符号化、ＵＤＰパケット化、送信等の処理を行う。

なお、第１実施形態において図７を用いて説明した通り、符号化サーバ２は、バッファリングデータの符号化、ＵＤＰパケット化が終了してから、次のバッファリングデータのバッファリングが完了するまで、そのＵＤＰパケットを何度も送信し続ける。本実施形態においては、符号化サーバ＃１と符号化サーバ＃２とで交互に処理を行うので、１つのバッファリングデータについてのＵＤＰパケットの送信時間が２倍となる。具体的には、符号化サーバ＃１においては、タイミング７５からタイミング７６までの間、Ｓ_１およびＳ_２のバッファリングデータについてのＵＤＰパケットを送信することになる。また、符号化サーバ＃２においては、タイミング７７からタイミング７８までの間、Ｓ_３およびＳ_４のバッファリングデータについてのＵＤＰパケットを送信することになる。

仮に１つの符号化サーバ＃１でストリーミングデータの全てを処理したなら、符号化サーバ＃１においてＳ３およびＳ４から成るバッファリングデータのバッファリング、符号化、送信処理も行わなければいけなくなり、１つのバッファリングデータについてのＵＤＰパケットの送信時間は半分となってしまう。

このように、複数の符号化サーバが順番に異なるバッファリングデータを送信するようになっているので、１つの符号化サーバにおいては、１つのバッファリングデータについてのＵＤＰパケットを送信し始めてから次のバッファリングデータのバッファリングが完了するまでの時間が延びることになる。

一方、このように複数の符号化サーバの送信データを全て同じ通信路の無線ＬＡＮアクセスポイント４〜６に送信すると、その無線ＬＡＮアクセスポイント４〜６における伝送効率が低下する。しかし、使用する通信路の容量が、ストリーミングデータのデータレート（すなわち単位時間のストリーミングデータの再生のために用いるデータのビット数）に比べて充分大きい場合、この低下はあまり問題とならない。

以下に、簡単な試算により、この効果を説明する。なお、以下の試算では、簡単のために、符号化処理に伴ってバッファリングデータより符号化データの量が増大するという冗長性については考慮しないものとする。

例えば、ストリーミングデータのデータレートが１６０ｋｂｉｔ／ｓ、バッファリングデータのデータ容量が１００ｋｂｙｔｅの場合、ひとつのバッファリングデータには、５秒分のデータが保持される。これを、伝送路の容量が８Ｍｂｉｔ／ｓの通信路で送信する場合、符号化サーバを単独で用いた場合、ひとつのバッファリングデータを受信するために０．１秒かかるが、符号化サーバを２台並列で動作させた本実施形態の場合、０．２秒の時間に伸びる。一方、各々のバッファのデータが送信され続ける時間は、前者の場合Ｔｍ＝５秒であるのに対し、後者の場合はＴｍ’＝１０秒間となる。

以上の試算をまとめると、符号化サーバを単独で用いる場合、受信者は５秒の間に０．１秒間ＵＤＰパケットの受信を行う必要があり、本実施形態では、１０秒の間に０．２秒間のＵＤＰパケットの受信を行えばよい。

このように、１つのバッファリングデータについてのＵＤＰパケットの送信時間が延びると、無線ＬＡＮアクセスポイント６〜８間を走行する車両１０のストリーミングデータ受信装置１１において、ストリーミングデータの再生の欠落の可能性が低減される。図１３および図１４に、ＵＤＰパケットの送信時間が延びることがストリーミングデータの再生の途絶の可能性に与える影響を説明する図を示す。

図１３は、符号化サーバが単独で処理を行う場合における、車両１０の走行とＵＤＰパケットの送信時間との関係を示す図である。また図１４は、本実施形態のように符号化サーバが複数ある場合の車両１０の走行とＵＤＰパケットの送信時間との関係を示す図である。

無線ＬＡＮアクセスポイント４と無線ＬＡＮアクセスポイント５とを連続的に通過する、ストリーミングデータ受信装置１１を搭載した車両１０は、無線セル７、無線セル８に入っている間に、必要な数のＵＤＰパケットを受信する必要がある。一方、１つのバッファリングデータについてのＵＤＰパケットが送信されるのは、図１３の場合においてはＴｍ秒であり、図１４の場合においてはＴｍ秒より長いＴｍ’秒である。

例えば、図１３のように、車両１０が無線セル７を出たときにあるバッファリングデータのＵＤＰパケットの送信が始まり、Ｔｍ秒内に車両１０は次の無線セル８に入れない場合、ストリーミングデータ受信装置１１は当該バッファリングデータを受信することができず、ストリーミングデータのその部分の再生が欠落してしまう。しかし、そのバッファリングデータの送信時間が図１４のＴｍ’のように長い場合、その間に車両１０が無線セル７または無線セル８に入っている可能性は高くなり、もし無線セル７を出てから無線セル８に入るまでの時間よりＴｍ’が長い場合、車両１０はこのＴ‘ｍの時間内に少なくとも１度は無線セルの中に入る。そして、その無線セルの中にいる間、車両１０が必要なＵＤＰパケットを受信するのに必要な時間２００以上当該バッファリングデータのＵＤＰパケットが送信され続ければ、当該バッファリングデータの復元および再生が可能となり、ストリーミングデータの連続受信が可能となる。

このように、符号化サーバを増やして同時に異なるバッファリングデータを送信させるようにすれば、無線セルが離散的な配置になっていても、車両が複数の無線セルのうち１つの無線セルを出てから隣の無線セルに入るまでの期間、すなわち無線セル間の時間が、１つのバッファリングデータを元とするＵＤＰパケットを送信し続ける期間から、復号クライアント１４が当該バッファリングデータを復元するためのＵＤＰパケットの受信にかかる期間を減算した期間より短いようになっていれば、車両１０が無線セルと無線セルの間を走行しているうちにバッファリングデータを復元するのに必要なＵＤＰパケットの受信機会を逃すことを防ぐことができる。

なお、このように、ストリーミングデータの再生の欠落の可能性を離散的な無線セルの間隔を調整することによって低減する事も可能である。すなわち、１つの無線セルから次の無線セルに入るまでの時間内にあるバッファリングデータについてのＵＤＰパケットの送信開始、送信終了が送信が終わってしまわないような距離に、無線ＬＡＮアクセスポイントを配置すればよい。

なお、上記した無線セル間の時間を特定するには、無線セル間の受信不能な領域の距離、および車両の走行速度を特定する必要があるが、一般的な走行車両について再生の欠落を防ぐようにするなら、上記車両の走行速度としては、その道路における車両の平均速度を用いればよいし、また、信頼性を上げ、大半の車両に欠落のない再生を保証するのであれば、その道路において想定される最低の走行速度を用いればよい。

なお、本実施形態の効果が発揮されるためには、上記したように符号化サーバ２が複数存在する必要は必ずしも無く、例えば１つの符号化サーバ２のＣＰＵ４２において、図３のステップ２１０〜２４０の処理を複数分並列的に行うことで、本実施形態と同等の効果が発揮される。すなわち、それぞれ異なるバッファリングデータを元とするＵＤＰパケットを同時に送信するようになっていればよい。

また、本実施形態においては、ＵＤＰパケットに付与するＩＤの組としては、少なくとも、符号化サーバ＃１、＃２が同時送信するバッファリングデータの数の２倍よりも多い回数進むと元に戻るような循環識別符号を用いる。

（第３実施形態）
次に、本発明の第３実施形態について説明する。本実施形態が第２実施形態と異なるのは、符号化サーバ２から送信されるストリーミングデータが動画像や音楽ではなく、連続制止画像であることである。ここで、連続静止画像とは、１つのバッファリングデータには１つまたは複数の静止画像のデータが含まれるようになっているストリーミングデータをいう。本実施形態においては、１つのバッファリングデータには１つの静止画像のデータが含まれている。

また、本実施形態においては、符号化サーバは２つではなく３つあり、それぞれが順番にバッファリングデータとしての１つの静止画像に対してバッファリング、符号化、ＵＤＰパケット化、送信等の処理を行う。

図１５に、このような３つの符号化サーバのＵＤＰパケットの送信タイミングを示す。図中下向きが時間の流れの向きであり、各実線８１、８２、８３が、それぞれ第１、第２、第３の符号化サーバのＵＤＰパケットの送信タイミングを示している。また、各実線上の黒丸が、１つのバッファリングデータについてのＵＤＰパケットの送信開始および送信終了のタイミングを示している。

例えば黒丸８４のタイミングでは、第１の符号化サーバが１のＩＤのバッファリングデータを元とするＵＤＰパケットの繰り返し送信を開始し、黒丸８５のタイミングでは、当該ＵＤＰパケットの送信を終了する。また、黒丸８６のタイミングでは、第２の符号化サーバが５のＩＤのバッファリングデータを元とするＵＤＰパケットの繰り返し送信を開始し、黒丸８７のタイミングでは、当該ＵＤＰパケットの送信を終了する。また、黒丸８８のタイミングでは、第３の符号化サーバが３のＩＤのバッファリングデータを元とするＵＤＰパケットの繰り返し送信を開始し、黒丸８９のタイミングでは、当該ＵＤＰパケットの送信を終了する。なお、本実施形態では、ＩＤの組として、１、２、・・・、９が循環的に用いられる。

ここで、１つのバッファリングデータについてのＵＤＰパケットの送信が開始されてから、同じ符号化サーバにおいて別のバッファリングデータについてのＵＤＰパケットの送信が開始されるまでの時間Ｔｌは、データの受信、復号、再生等の処理が低速なストリーミングデータ受信装置１１が当該バッファリングデータの受信・復号にかかる最長時間となるように、符号化サーバの処理速度、送信タイミング等を設定する。なお、この最長時間とは、ストリーミングデータ受信装置１１が故障している場合等における受信・復号にかかる時間を含めた中での最長時間をいうのではなく、ストリーミングデータ受信装置１１の正常動作において受信・復号にかかる時間のゆれ幅の中の最長時間をいう。

このようにすることで、低速なストリーミングデータ受信装置１１でも、少なくとも３枚に１枚の静止画像を再生することができる。なお、低速なクライアントの作動については後述する。

また、１つのバッファリングデータについてのＵＤＰパケットの送信が開始されてから、次のＩＤのバッファリングデータについてのＵＤＰパケットが他の符号化サーバから送信が開始されるまでの時間Ｔｈは、データの受信、復号、再生等の処理が高速なストリーミングデータ受信装置１１が当該バッファリングデータの受信・復号にかかる最長時間となるように、符号化サーバの処理速度、送信タイミング等を設定する。このようにすることで、高速なストリーミングデータ受信装置１１は、全ての静止画像を再生することができる。なお、高速なストリーミングデータ受信装置１１としては、第１実施形態に示したような、複数の個別復元プログラムを並列で実行する復号クライアント１４を有するストリーミングデータ受信装置１１が考えられる。

ただし、このＵＤＰパケットの送信路である無線ＬＡＮアクセスポイント４〜６は、これら同時期に送信されているＵＤＰパケットを、時分割による細かい送信タイミングの割り振りで無線セル７〜９に送出する。図１６に、時分割による実際の無線ＬＡＮアクセスポイント４〜６におけるＵＤＰパケットの送出タイミングを示す。

図１６においては、図中下向きが時間の向きを示している。中央の縦に繋がった矩形９１〜１０２のぞれぞれは、図１５におけるＴｈの期間を示している。そして、それぞれの矩形９１〜１０２に対応づけられた番号付き矩形は、その期間における時分割の時間スロットであり、その矩形に付された番号は、その時間スロットにおいて送信されるＵＤＰパケットに含まれるＩＤの値である。

例えば、矩形９１の期間は、図１５において第１の符号化サーバからＩＤが１のＵＤＰパケットのみが送信される期間に対応しているので、無線ＬＡＮアクセスポイント４〜６において全ての時間スロットでＩＤが１のＵＤＰパケットが送出される。

また、矩形９２の期間は、図１５において第１の符号化サーバからＩＤが１のＵＤＰパケットが送信され、第２の符号化サーバからＩＤが２のＵＤＰパケットが送信される期間に対応しているので、時間スロットの半分でＩＤが１のＵＤＰパケットが送出され、残りの半分でＩＤが２のＵＤＰパケットが送出される。

また、矩形９３の期間は、図１５において第１の符号化サーバからＩＤが１のＵＤＰパケットが送信され、第２の符号化サーバからＩＤが２のＵＤＰパケットが送信され、第３の符号化サーバからＩＤが３のＵＤＰパケットが送信される期間に対応しているので、時間スロットの１／３でＩＤが１のＵＤＰパケットが送出され、同じく１／３でＩＤが２のＵＤＰパケットが送出され、また同じく１／３でＩＤが３のＵＤＰパケットが送出される。また、送出順は図１６のようにＩＤの順になっていてもよい。

このように、同時期に複数のＩＤについてのＵＤＰパケットが無線ＬＡＮアクセスポイント４〜６送出される場合、それぞれを同じ頻度で時分割送出する。

次に、上記した低速なストリーミングデータ受信装置１１の例として、復号クライアント１４においてＣＰＵ４２が実行する個別復元プログラムの同時実行数が１であるような復号クライアント１４の作動について説明する。この低速の復号クライアント１４が第１実施形態の復号クライアント１４と異なるのは、上記した通り、ＣＰＵ４２が実行する個別復元プログラムの同時実行数が１であること、そして受信プログラム８０５が図１５のフローチャートに示すようなものであることである。以下、図１５のフローチャートを実行するＣＰＵ４２の作動について説明する。

なお、図１５と図１０において同一の符号が付されたステップは、図１０の場合には複数の個別復元プログラムに対する処理であり、図１５においては１つの個別復元プログラムに対する処理であることを除き、互いに同一の処理を行うものであり、ここではその詳細についての説明は省略する。

ステップ９２０Ｆｒが“ｆａｌｓｅ”であると判定した場合、すなわち個別復元プログラムの復号の処理が行われていない場合、続いてステップ５２５の処理を実行する。ステップ５２５では、ＵＤＰパケットを無線ＬＡＮインターフェース４１を介してｍ個受信する。ここでｍ個とは、最新のＵＤＰパケットがどのＩＤのパケットであるかを調べるために受信するサンプル数であり、複数のＩＤのＵＤＰパケットの同時送信数（本実施形態では３）以上の値である。

次にステップ５３０で、受信したＵＤＰパケットの中で最も新しいＩＤを有するものについて、復号予約の処理を行う。これにより、当該ＩＤが割り当てられた個別復元プログラムの実行が開始され、その実行により、受信プログラム８０５から渡された当該ＩＤを有するＵＤＰパケットが必要量に達したときに、復号、復元等の処理を行う。

次にステップ５３５で、変数Ｆｒを“ｔｒｕｅ”に設定する。

ステップ９２０で変数Ｆｒが“ｔｒｕｅ”の場合、およびステップ５３５の次に、ステップ５４５では、イベント発生のデータを個別復元プログラムから渡されているかを確認する。具体的には、前回のステップ９２０〜９６０のループにおけるステップ５４５の処理の後に個別復元プログラムから受けたタイムアウトイベント、復号完了イベントの有無を確認する。

復号完了イベントを受けている場合は、続いてステップ９６０で、変数Ｆｒの値を“ｆａｌｓｅ”とする。

タイムアウトイベントを受けている場合は、図１０の場合と同様、復号処理をリセットし、変数Ｆｒを“ｆａｌｓｅ”にセットする。

また、復号完了イベントもタイムアウトイベントも受けていない場合、およびステップ９６０に続いては、ループの最初であるステップ９１０の処理を実行する。

このような本実施形態の受信プログラム８０５の処理を実行することで、ＣＰＵ４２は、復号が完了した場合、および復号がタイムアウトとなった場合、ステップ９６０でＦｒを“ｆａｌｓｅ”とすることで、再度ステップ５２５〜５３５で、現在受信できるものから最も新しいＵＤＰパケットについて復号、復元の処理を行うことができる。

なお、受信プログラム８０５の処理として、ＣＰＵ４２は、この図１５のフローチャートに記載された処理と並行して、符号化サーバ２からＵＤＰパケットを受信し、その受信したＵＤＰパケットのＩＤを特定し、そのＩＤが現在個別復元プログラムに割り当てられたものなら、個別復元プログラムにそのＵＤＰパケットを渡すようになっている。このようになっていることで、個別復元プログラムは、自己に割り当てられたＩＤのＵＤＰパケットを受けて復元処理に用いることができる。

図１６に、このような、復号が完了またはタイムアウトした場合に次の最も新しいＵＤＰパケットの復号を始める低速なストリーミングデータ受信装置１１が、図１５、図１６に示すような送信を行う符号化サーバからの復元するＵＤＰパケットの順番の一例を示す。図１６中の各丸印が１つのＩＤに対応する。この図の例においては、低速なストリーミングデータ受信装置１１は、１、４、７と、２つ飛ばしでバッファリングデータを受信して復号、復元することになる。従って、再生される静止画像は、２画像飛ばしとなる。

なお、上記した各実施形態において、符号化サーバ２（第２実施形態においては符号化サーバ＃１および＃２）、無線ＬＡＮアクセスポイント４〜６がストリーミングデータ送信装置を構成する。しかし、無線ＬＡＮアクセスポイント４〜６は必ずしもストリーミングデータ送信装置の構成要素となる必要はなく、符号化サーバ２のみがストリーミングデータ送信装置を構成しているような実施形態があってもよい。

また、符号化サーバ２のＣＰＵ２２が、図２のステップ２２０、２３０の処理を実行することで、処理手段として機能する。

また、ＵＤＰパケットが、ＦＥＣ化データに相当する。ただし、ＦＥＣ化データとしては、ＵＤＰパケットである必要はなく。ＦＥＣ処理が実行された後のデータであればどのようなものでもよい。

また、符号化サーバ２（第２実施形態においては符号化サーバ＃１および＃２）の送信インターフェース２５および無線ＬＡＮアクセスポイント４〜６が送信手段に相当する。

また、復号クライアント１４の無線ＬＡＮインターフェース４１が受信手段に相当する。

また、復号クライアント１４のＣＰＵ４２が、受信プログラム８０５、個別復元プログラム８１０、８２０、およびバッファリングプログラム８３０を実行することで、復元手段として機能する。

また、復号クライアント１４のＣＰＵ４２が、ストリーム再生プログラム８４０を実行することで、再生制御手段として機能する。

また、復号クライアント１４のＣＰＵ４２が、個別復元プログラム８１０、８２０のそれぞれを実行することで、それぞれの個別復元手段として機能する。

また、上記した実施形態においては、復号クライアント１４とプレーヤ１５とが別体となっているが、復号クライアント１４とプレーヤ１５とが一体となっており、復号クライアント１４およびプレーヤ１５の処理が同一のＣＰＵにおいて実現されるようになっていてもよい。

また、復号クライアント１４のＲＡＭ４３が、特許請求の範囲の「共通の記憶媒体」に相当する。

本発明の第１実施形態に係る情報配信システムの構成図である。 ストリーミングサーバ１、符号化サーバ２、ストリーミングデータ受信装置１１等の構成図である。 このような情報配信システム１００におけるデータの流れを示す図である。 ＣＰＵ２２のステップ２２０および２３０の処理を説明する図である。 ＵＤＰパケットに付与されるＩＤの更新順の一例を示す図である。 ＩＤの組と、ストリーミングデータの内容のカテゴリとの対応を示す図表である。 ストリーミングサーバ１からストリーミングデータを受信してＵＤＰパケットを送信する符号化サーバ２の処理のタイミングを示すタイミングチャートである。 復号クライアント１４のＣＰＵ４２が実行するプログラムの構成を示す図である。 符号化パケット抽出プログラム８１２、復号・データ復元プログラム８１３の処理を説明する図である。 受信プログラム８０５の処理を示すフローチャートである。 受信したＵＤＰパケットのＩＤが新規に受信すべきＩＤであるか否かの判定について説明する図である。 ストリーミングサーバ１からストリーミングデータを受信してＵＤＰパケットを送信する２つの符号化サーバ＃１、符号化サーバ＃２の処理のタイミングを示すタイミングチャートである。 符号化サーバが単独で処理を行う場合における、車両１０の走行とＵＤＰパケットの送信時間との関係を示す図である。 符号化サーバが複数ある場合の車両１０の走行とＵＤＰパケットの送信時間との関係を示す図である。 第３実施形態における３つの符号化サーバのＵＤＰパケットの送信タイミングを示す図である。 時分割による実際の無線ＬＡＮアクセスポイント４〜６におけるＵＤＰパケットの送出タイミングを示す図である。 低速なストリーミングデータ受信装置１１の受信プログラム８０５の処理を示すフローチャートである。 低速なストリーミングデータ受信装置１１において受信、復号、復元するバッファリングデータのＩＤの順番の一例を示す図である。

符号の説明

１…ストリーミングサーバ、２…符号化サーバ、３…広域ネットワーク、
４〜６…無線ＬＡＮアクセスポイント、７〜９…無線セル、１０…車両、
１１…ストリーミングデータ受信装置、１２…カメラ、１３…マイク、
１４…復号クライアント、１５…プレーヤ、２１…受信インターフェース、
２２…ＣＰＵ、２３…ＲＡＭ、２４…ＲＯＭ、２５…送信インターフェース、
４１…無線ＬＡＮインターフェース、４２…ＣＰＵ、４３…ＲＡＭ、４４…ＲＯＭ、
４５…送信インターフェース、５１…イーサネット（登録商標）回線、５２…イーサネット（登録商標）回線、
１００…情報配信システム、３１０…バッファリングデータ、
３１１〜３１８…分割データ、３２０〜３３５…符号化パケット、
３４０、３５０…ＵＤＰパケット、３４１、３５１…ＩＤ、
３４２、３５２…通し番号、８０５…受信プログラム、８１０…個別復元プログラム、
８１１…タイマ−プログラム、８１２…符号化パケット抽出プログラム、
８１３…復号・データ復元プログラム、８２０…個別復元プログラム、
８２１…タイマ−プログラム。

Claims (16)

1. ストリーミングデータを複数送信単位分バッファリングする記憶媒体と、
   前記記憶媒体が前記バッファリングした複数送信単位分のバッファリングデータに対してＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）処理を施す処理手段と、
   前記処理手段が前記ＦＥＣ処理を施した結果のＦＥＣ化データを、受信したＦＥＣ化データからバッファリングデータを復元するストリーミングデータ受信装置が受信できるよう、送信する送信手段と、を備えたストリーミングデータ送信装置。
2. 前記送信手段は、無線によって前記ＦＥＣ化データを送信し、その送信の伝送容量は、当該ＦＥＣ化データの元となるストリーミングデータのデータレートより大きいことを特徴とする請求項１に記載のストリーミングデータ送信装置。
3. 前記送信手段は、それぞれ異なるバッファリングデータを元とする複数のＦＥＣ化データを同時に送信することを特徴とする請求項１または２に記載のストリーミングデータ送信装置。
4. 前記送信手段は、前記ストリーミングデータ受信装置を搭載した車両の走行路に沿った複数の無線セルを構成し、この複数の無線セルから同じＦＥＣ化データを同時に送信し、
   車両が前記複数の無線セルのうち１つの無線セルを出てから隣の無線セルに入るまでの期間が、１つのバッファリングデータを元とするＦＥＣ化データを送信し続ける期間から、前記ストリーミングデータ受信装置が前記バッファリングデータを復元するための前記ＦＥＣ化データの受信にかかる期間を減算した期間より短いことを特徴とする請求項１ないし３のいずれか１つに記載のストリーミングデータ送信装置。
5. 前記ストリーミングデータは、動画または音楽のストリーミングデータであることを特徴とする請求項１ないし４のいずれか１つに記載のストリーミングデータ送信装置。
6. 前記ストリーミングデータは、繰り返し撮影された静止画が連続するストリーミングデータであり、
   前記記憶媒体は、前記ストリーミングデータを前記静止画の所定枚数分バッファリングすることを特徴とする請求項１ないし５のいずれか１つに記載のストリーミングデータ送信装置。
7. 前記処理手段は、前記ＦＥＣ化データに、バッファリングされる順に循環的にバッファリングデータに割り当てられる循環識別符号のうち、当該ＦＥＣ化データの元となるバッファリングデータに割り当てられた循環識別符号を付与し、
   前記送信手段は、前記循環識別符号が付与されたＦＥＣ化データを送信することを特徴とする請求項１ないし６のいずれか１つに記載のストリーミングデータ送信装置。
8. 前記循環識別符号は、複数回進むと元の符号に戻るような循環識別符号であり、この複数回は、前記送信手段が同時送信するＦＥＣ化データの元となるバッファリングデータの数の２倍よりも多い回数であることを特徴とする請求項７に記載のストリーミングデータ送信装置。
9. 前記バッファリングデータに循環的に割り当てられる循環識別符号の組は、当該ＦＥＣ化データの元となるストリーミングデータの種類毎に異なることを特徴とする請求項７または８に記載のストリーミングデータ送信装置。
10. 請求項１ないし９のいずれか１つに記載のストリーミングデータ送信装置から送信されたＦＥＣ化データを受信する受信手段と、
    前記受信手段が受信したＦＥＣ化データから前記ＦＥＣ化データの元となるバッファリングデータを復元する復元手段と、
    前記復元手段が復元したバッファリングデータのデータレートに基づいて、前記バッファリングデータから成るストリーミングデータを再生するための処理を行う再生制御手段と、を備えたストリーミングデータ受信装置。
11. 前記受信手段は請求項７ないし９のいずれか１つの記載のストリーミングデータ送信装置から送信されたＦＥＣ化データを受信し、
    前記復元手段は、前記ＦＥＣ化データに付与された循環識別符号に基づいて、前記受信したＦＥＣ化データから前記ＦＥＣ化データの元となるバッファリングデータを復元することを特徴とする請求項１０に記載のストリーミングデータ受信装置。
12. 前記復元手段は、並列的に複数の異なるバッファリングデータを復元するため、１度に１つのバッファリングデータを復元する個別復元手段を複数有し、
    前記受信した前記ＦＥＣ化データに付与された循環識別符号に基づいて、当該ＦＥＣ化データを前記個別復元手段のいずれか１つに復元させることを特徴とする請求項１１に記載のストリーミングデータ受信装置。
13. 前記個別復元手段は、復元したバッファリングデータを共通の記憶媒体に記憶させ、
    前記再生制御手段は、前記共通の記憶媒体に記憶されたバッファリングデータに記述された時間情報に基づいて、前記バッファリングデータから成るストリーミングデータを再生するための処理を行うことを特徴とする請求項１２に記載のストリーミングデータ受信装置。
14. 前記復元手段は、前記個別復元手段をＭ個有しており、前記個別復元手段のそれぞれが復元しているバッファリングデータに割り当てられた循環識別符号が、それぞれ循環識別符号Ｘないし循環識別符号ＸからＭ−１個先の循環識別符号であるとき、前記循環識別符号ＸからＭ個以上先であり、かつ前記循環識別符号ＸからM個前よりも前である識別符号が付与されたＦＥＣ化データを前記受信手段が受信したとき、前記循環識別符号Ｘが割り当てられたバッファリングデータの復元を行う個別復元手段の処理をキャンセルさせることを特徴とする請求項１２または１３に記載のストリーミングデータ受信装置。
15. 前記復元手段は、１度に１つのバッファリングデータを復元し、前記受信手段が受信したＦＥＣ化データに付与されている循環識別符号のうち、最も先の循環識別符号が割り当てられたバッファリングデータを復元することを特徴とする請求項１０に記載のストリーミングデータ受信装置。
16. 前記復元手段は、前記個別復元手段のバッファリングデータの復元を開始してから規定時間経過しても当該バッファリングデータの復元を完了しないとき、当該バッファリングデータを有するストリーミングデータの復元をリセットし、
    前記規定時間は、前記ストリーミングデータ送信装置において用いられる循環識別符号が一巡する時間から余裕時間を減算した時間であり、
    前記余裕時間は、前記ストリーミングデータ送信装置において１つのＩＤが用いられてから次のＩＤが用いられるまでの時間の平均値に、前記個別復号手段の数の２倍を乗算したものであることを特徴とする請求項１２ないし１４のいずれか１つに記載のストリーミングデータ受信装置。

Images