特許 7403957 通信装置、通信方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-15

(45)【発行日】2023-12-25

(54)【発明の名称】通信装置、通信方法及びプログラム

(51)【国際特許分類】

   H04L 49/9057 20220101AFI20231218BHJP

   H04N 21/238 20110101ALI20231218BHJP

   H04N 21/438 20110101ALI20231218BHJP

【ＦＩ】

H04L49/9057

H04N21/238

H04N21/438

【請求項の数】 10

(21)【出願番号】P 2019040425

(22)【出願日】2019-03-06

(65)【公開番号】P2020145573

(43)【公開日】2020-09-10

【審査請求日】2022-03-02

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100109380

【弁理士】

【氏名又は名称】小西 恵

(74)【代理人】

【識別番号】100109036

【弁理士】

【氏名又は名称】永岡 重幸

(72)【発明者】

【氏名】強矢 亨

【審査官】中川 幸洋

(56)【参考文献】

【文献】特開２００６－０８１０３０（ＪＰ，Ａ）

【文献】特開２００６－０５０５０３（ＪＰ，Ａ）

【文献】国際公開第２０１２／０９６３７２（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４９／９０５７

Ｈ０４Ｎ ２１／２３８

Ｈ０４Ｎ ２１／４３８

(57)【特許請求の範囲】

【請求項1】

パケットを送信する通信装置であって、
フレームのデータを所定サイズの複数のデータに分割する分割手段と、
前記分割手段によって分割された複数のデータ夫々に、前記フレームにおけるパケットの順番を示すシーケンスナンバーの情報を付加し、かつ、受信装置において前記フレームのデータを受信するためのバッファサイズを確保させるための、前記フレームのデータの分割数を示す情報を付加して、複数のパケットを生成する生成手段と、
前記生成手段が生成した前記複数のパケットをコネクションレス型の通信により送信する送信手段と、
を備え、
前記複数のパケットを受信する受信装置において、
先頭のパケットのシーケンスナンバーと、夫々のパケットのシーケンスナンバーとに基づいて、前記複数のパケットの夫々が先頭から何番目に位置するかが判定され、前記先頭から何番目に位置するかの値と前記所定サイズとに基づく乗算結果に対応する、前記複数のデータの夫々を格納すべきオフセット量が判定され、
前記バッファサイズは、前記分割数と前記所定サイズとの乗算結果に対応する値に決定されることを特徴とする通信装置。

【請求項2】

前記生成手段は、
前記付加される情報を、前記パケットのヘッダ中に付加する、
ことを特徴とする請求項１に記載の通信装置。

【請求項3】

パケットを受信する通信装置であって、
フレームのデータが所定サイズの複数のデータに分割され、分割された複数のデータ夫々に、前記フレームにおけるパケットの順番を示すシーケンスナンバーの情報を付加し、かつ、前記フレームのデータを受信するためのバッファサイズを確保するための、前記フレームのデータの分割数を示す情報を付加して生成された複数のパケットをコネクションレス型の通信により受信する受信手段と、
前記受信手段が受信した先頭のパケットのシーケンスナンバーと、夫々のパケットのシーケンスナンバーとに基づいて、前記複数のパケットの夫々が前記先頭のパケットから何番目に位置するかを判定し、前記先頭から何番目に位置するかの値と前記所定サイズとに基づく乗算結果に対応する、前記複数のデータの夫々を格納すべきオフセット量を判定する判定手段と、
前記受信手段により受信した前記複数のパケット中の夫々のデータを、再結合用のバッファの前記オフセット量に応じた位置に格納する再結合手段と、
前記分割数と前記所定サイズとの乗算結果に対応する値に基づいて、前記フレームのデータを受信するための前記再結合用のバッファのサイズを確保する確保手段と、
を備えることを特徴とする通信装置。

【請求項4】

前記再結合手段は、
前記複数のパケットの全てが前記受信手段により受信される前に、受信された夫々のパケット中のデータを前記再結合用のバッファの前記オフセット量に応じた位置に格納する、
ことを特徴とする請求項３に記載の通信装置。

【請求項5】

前記再結合手段は、
前記複数のパケットの１つ１つが前記受信手段により受信される毎に、受信された夫々のパケット中のデータを前記再結合用のバッファの前記オフセット量に応じた位置に格納する、
ことを特徴とする請求項４に記載の通信装置。

【請求項6】

前記コネクションレス型の通信のプロトコルは、ＲＴＰ（Ｒｅａｌ－Ｔｉｍｅ Ｔｒａ
ｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）であることを特徴とする請求項１から５のいずれか１項に記載の通信装置。

【請求項7】

前記情報は、ＲＴＰ拡張ヘッダに付加される、
ことを特徴とする請求項１から６のいずれか１項に記載の通信装置。

【請求項8】

パケットを送信する通信方法であって、
フレームのデータを所定サイズの複数のデータに分割するステップと、
前記分割された複数のデータ夫々に、前記フレームにおけるパケットの順番を示すシーケンスナンバーの情報を付加し、かつ、受信装置において前記フレームのデータを受信するためのバッファサイズを確保させるための、前記フレームのデータの分割数を示す情報を付加して、複数のパケットを生成するステップと、
前記生成された前記複数のパケットをコネクションレス型の通信により送信するステップと、
を有し、
前記複数のパケットを受信する受信装置において、
先頭のパケットのシーケンスナンバーと、夫々のパケットのシーケンスナンバーとに基づいて、前記複数のパケットの夫々が先頭から何番目に位置するかが判定され、前記先頭から何番目に位置するかの値と前記所定サイズとに基づく乗算結果に対応する、前記複数のデータの夫々を格納すべきオフセット量が判定され、
前記バッファサイズは、前記分割数と前記所定サイズとの乗算結果に対応する値に決定されることを特徴とする通信方法。

【請求項9】

パケットを受信する通信方法であって、
フレームのデータが所定サイズの複数のデータに分割され、分割された複数のデータ夫々に、前記フレームにおけるパケットの順番を示すシーケンスナンバーの情報を付加し、かつ、前記フレームのデータを受信するためのバッファサイズを確保するための、前記フレームのデータの分割数を示す情報を付加して生成された複数のパケットをコネクションレス型の通信により受信するステップと、
前記受信した先頭のパケットのシーケンスナンバーと、夫々のパケットのシーケンスナンバーとに基づいて、前記複数のパケットの夫々が前記先頭のパケットから何番目に位置するかを判定し、前記先頭から何番目に位置するかの値と前記所定サイズとに基づく乗算結果に対応する、前記複数のデータの夫々を格納すべきオフセット量を判定するステップと、
前記受信した前記複数のパケット中の夫々のデータを、再結合用のバッファの前記オフセット量に応じた位置に格納するステップと、
前記分割数と前記所定サイズとの乗算結果に対応する値に基づいて、前記フレームのデータを受信するための前記再結合用のバッファのサイズを確保するステップと、
を有することを特徴とする通信方法。

【請求項10】

コンピュータを、請求項１から７のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストリーミング配信を行う通信装置、通信方法及びプログラムに関する。

【背景技術】

【0002】

近年、音声や映像等のコンテンツをＲＴＰ（Ｒｅａｌ－Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルでストリーミング配信を行う技術が実用化されている。ＲＴＰは、主に音声データや映像データ等のメディアデータをリアルタイムにデータ転送するためのプロトコルであり、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｅｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）によりＲＦＣ３５５０として定義されている。

【0003】

ＲＴＰを用いてストリーミングを行う場合、送信側ではメディアデータを構成するフレームを分割してパケットに格納して送信し、受信側では分割されたデータを連結してフレームを再結合する必要がある。例えば特許文献１に開示された技術では、データを複数の分割データに分割し、複数の分割データのうちの何番目の分割データであるのかを示す分割データ番号と、複数の分割データの数である分割データ数とを特定するための分割データ情報をパケットに付加する。これにより、装置の処理負荷を削減している。

【0004】

また、ＲＴＰはコネクションレス型の通信プロトコルであるＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の上位プロトコルである。ＵＤＰでは、パケットの到達順序が保証されていない為、パケットを送信した順番と受信した順番が異なる可能性がある。この特性はＲＴＰでも同様である為、受信したパケットからメディアのデータを構成するフレームを再結合する際には、ＲＴＰのヘッダに格納されているシーケンス情報を参照して分割されたデータの順序を並べ直して結合する必要がある。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１６－３９６２９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

ＲＴＰを用いたストリーミングでは、受信したパケットを受信用のバッファ領域に一時的に格納し、１フレーム分のパケットを受信した後、他のバッファ領域に改めてパケットの順番を整えながらコピーすることでフレームのデータを再結合する必要があった。このため、フレームのデータを再結合するためのバッファが必要になる。また、受信用のバッファからデータを再結合用のバッファにコピーする処理の負荷が１フレーム分のパケットを受信した後に集中する。

【0007】

本発明は上述の課題に鑑みて成されたものであり、受信側の装置におけるフレームのデータの再結合の処理負荷を分散させることを目的とする。

【課題を解決するための手段】

【0008】

上記の課題を解決するため、本発明に係る通知装置のある態様によれば、パケットを送信する通信装置であって、フレームのデータを所定サイズの複数のデータに分割する分割手段と、前記分割手段によって分割された複数のデータ夫々に、前記フレームにおけるパケットの順番を示すシーケンスナンバーの情報を付加し、かつ、受信装置において前記フレームのデータを受信するためのバッファサイズを確保させるための、前記フレームのデータの分割数を示す情報を付加して、複数のパケットを生成する生成手段と、前記生成手段が生成した前記複数のパケットをコネクションレス型の通信により送信する送信手段と、を備え、前記複数のパケットを受信する受信装置において、先頭のパケットのシーケンスナンバーと、夫々のパケットのシーケンスナンバーとに基づいて、前記複数のパケットの夫々が先頭から何番目に位置するかが判定され、前記先頭から何番目に位置するかの値と前記所定サイズとに基づく乗算結果に対応する、前記複数のデータの夫々を格納すべきオフセット量が判定され、前記バッファサイズは、前記分割数と前記所定サイズとの乗算結果に対応する値に決定される、通信装置が提供される。

【発明の効果】

【0009】

本発明によれば、受信側の装置におけるフレームのデータの再結合の処理負荷を分散させることができる。

【図面の簡単な説明】

【0010】

【図1】実施形態１における通信システムの構成例を示す図

【図2】実施形態１における送信装置の機能構成例を示すブロック図

【図3】実施形態１における受信装置の機能構成例を示すブロック図

【図4】従来のパケット受信処理を示す説明図

【図5】従来のフレーム再結合処理を示す説明図

【図6】従来のパケット受信からフレーム再結合までの処理を示すフローチャート

【図7】実施形態１におけるＲＴＰパケットの構成例を示す図

【図8】実施形態１におけるパケット受信からフレーム再結合までの処理の例を示す説明図

【図9】実施形態１におけるパケット受信からフレーム再結合までの処理の例を示すフローチャート

【図10】実施形態２におけるＲＴＰパケットの構成例を示す概略図

【図11】実施形態２におけるパケット受信からフレーム再結合までの処理の例を示すフローチャート

【図12】送信装置のハードウェア構成を示すブロック図

【発明を実施するための形態】

【0011】

以下、添付図面を参照して、本発明を実施するための実施形態について詳細に説明する。なお、以下に説明する各実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正または変更されるべきものであり、本発明は以下の実施形態に必ずしも限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の処理については、同じ符号を付して説明する。

【0012】

実施形態１
図１は、実施形態１の通信システムの構成例を示している。
この通信システムは、複数のフレームを含むデータを送信する送信装置１と、送信装置１とネットワーク３を介して接続され送信装置１から送信された複数のフレームを含むデータを受信する受信装置２と備えている。送信装置１及び受信装置２は通信装置の一例である。なお、送信装置１および受信装置２は夫々複数設けてもよい。

【0013】

送信装置１は、例えば、カメラ装置、ビデオカメラ装置、スマートフォン装置、ＰＣ（パーソナルコンピュータ）装置、携帯電話等の動画・静止画・音声等のコンテンツのデータ（メディアデータ）を送信する装置である。なお、送信装置１は、後述の機能を備えるものであれば、この例に限定されない。また、受信装置２は、例えば、スマートフォン装置、ＰＣ、テレビ、携帯電話等の受信したコンテンツの再生・表示、通信、ユーザからの指示の入力等を行う装置であるが、後述の機能を備えるものであれば、この例に限定されない。

【0014】

ネットワーク３は、例えば有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）や無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ ＬＡＮ）等のネットワークで構成される。なお、ネットワーク３は、これに限らず、インターネットや携帯電話通信網等のＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、アドホックネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）等のネットワークで構成してもよい。

【0015】

図２は、送信装置１の機能構成例を示すブロック図である。
送信装置１は、メディアデータを取得するデータ取得部１１と、メディアデータを所定のサイズのデータに分割するフレーム分割部１２と、分割されたデータから送信するパケットを生成するパケット生成部１３とを備えている。また、送信装置１は、生成されたパケットのデータを保持する送信バッファ１４と、送信バッファ１４に保持されているパケットのデータを送信するパケット送信部１５とを備えている。

【0016】

データ取得部１１は、動画、静止画・音声等の符号化されたメディアデータを取得する。フレーム分割部１２は、データ取得部１１が取得し、所定長のフレームのデータとして供給されるメディアデータを、符号化形式等に応じて、所定のサイズ（例えばネットワーク３における通信に適したサイズ）のデータに分割する。

【0017】

パケット生成部１３は、フレーム分割部１２によって分割されたデータに受信側で必要となる情報を含むヘッダを付加してパケットを生成し、送信バッファ１４に格納する。パケット送信部１５は、送信バッファ１４に格納されたパケットのデータをネットワーク３を介して、例えばコネクションレス型のプロトコルであるＲＴＰにより、受信装置２に送信する。このように送信装置１から送信されたパケットは、ネットワーク３を介して受信装置２に供給される。

【0018】

図３は、受信装置２の機能構成例を示すブロック図である。
受信装置２は、ネットワーク３を介して送信装置１からのパケットを受信するパケット受信部２１と、パケット受信部２１が受信したパケットを一時的に保持する受信バッファ２２とを備えている。また、受信装置２は、受信バッファ２２に保持されているパケットを解析するパケット解析部２３と、パケット解析部２３が受信したパケットからフレームのデータを再結合するために用いる再結合バッファ２４とを備えている。

【0019】

上述のＲＴＰでは、例えば図４に示すように、パケットの到達順は保証されないため、従来は受信装置２側で再結合を行ってフレームのデータを再生する必要があった。なお、図４は、送信装置１が、１つのフレームを分割したパケット（１～１０）を順番に送信し、送信した順番とは異なる順番で受信装置２がパケットを受信する状態を示している。

【0020】

受信装置２は、例えば図５に示すように、１フレーム分の複数のパケットを受信した順に受信バッファ（テンポラリ）３１に格納する。１つのフレームを構成する複数のパケットの受信が終了した後、受信装置２は、受信バッファ３１に格納されているパケットを正しい順番に読み出して、フレーム再結合用バッファ３２にコピーすることにより、フレームの再結合を行っていた。

【0021】

図２及び図３に示す各機能部は、ＡＳＩＣ等の専用のハードウェア又はソフトウェアとして通信装置に実装される。ハードウェアとして実装される場合は、各機能部それぞれ又はいくつかをまとめた専用のハードウェアモジュールとして実装可能である。ソフトウェアとして実装される場合には、各機能部を実行するためのプログラムが後述の通信装置の記憶部１２１に記憶され、制御部１２２のプロセッサにより適宜読み出されて実行される。

【0022】

図６は、従来のパケット受信からフレーム再結合までの処理を示すフローチャートである。図中、ＳはＳｔｅｐの略である。
受信装置２は、まず、Ｓ１においてＲＴＰパケットを受信する。Ｓ１における受信処理は、Ｓ２において、１つのフレームを構成するパケットを全て受信したことが検出されるまで繰り返される。受信装置２は、１つのフレームを構成するパケットを全て受信すると、Ｓ３においてフレーム再結合用バッファ３２を予約（確保、獲得）する。フレーム再結合用バッファ３２は、受信した複数のパケットに分割して格納されたフレームのデータを正しい順番に結合し、フレームデータを再結合するために用いるものである。

【0023】

さらに、受信装置２は、Ｓ４において、受信バッファ３１に格納されたパケットのペイロード部分のデータを正しい順番に整列しながらフレーム再結合用バッファ３２にコピーすることによりフレームデータを再結合する。この際、受信装置２はＲＴＰヘッダにあるシーケンスナンバーを参照することにより、ペイロード部分のデータの順番を整列する。

【0024】

このように、従来は、１フレーム分のパケットを受信した後に、全てのペイロード部分のデータをコピーする必要があった。データのコピーは処理負荷が高いため、特にＣＰＵ演算能力等のリソースが十分ではない機器においては、パケット数が多い場合等において、Ｓ４の処理を１フレーム分の処理時間内に実行することができない可能性があった。このため、コンテンツの再生のパフォーマンスが低下する可能性があった。

【0025】

このため、本実施形態では、ペイロード部分のデータのコピーがフレーム再結合時に集中しないようにしている。すなわち、本実施形態では、フレームのデータの再結合の処理負荷を分散させる。

【0026】

（送信パケットの構成）
図７は、本実施形態のパケット生成部１３によって生成されるＲＴＰパケットの構成例を示す図である。
ＲＴＰパケット５０は、パケットの属性等を示すＲＴＰヘッダ５１と、フレーム分割部１２によって分割されたフレームのデータが格納されるペイロード５７とを備えている。ＲＴＰヘッダ５１は、ＲＴＰ拡張ヘッダ５２を備えている。ＲＴＰでは拡張ヘッダを備える場合、ＲＴＰヘッダ５１中の拡張ヘッダの有無を示す識別子“Ｘ”に１が設定される（図中、Ｘ＝１）。

【0027】

本実施形態において、ＲＴＰ拡張ヘッダ５２の拡張ヘッダ識別子５３には、フレームのデータのフレームサイズ５５と分割されたデータ夫々のフレーム内の位置を示すオフセット位置５６の情報が含まれることを示す識別子が格納される。なお、識別子Ｌｅｎｇｔｈ５４は、ＲＴＰ拡張ヘッダ５２に格納しているデータのサイズを３２ｂｉｔのブロックの個数で示すものである。本実施形態では、ＲＴＰ拡張ヘッダ５２に含まれるデータのサイズが、例えば３２ｂｉｔブロック２個分の長さであり、識別子Ｌｅｎｇｔｈ５４には、３２ｂｉｔブロック２個分の長さであることを示す２が格納される。なお、ＲＴＰ拡張ヘッダ５２を利用しない受信装置２では、ＲＴＰ拡張ヘッダ５２のデータは無視される。

【0028】

本実施形態において、フレームサイズ５５は、フレーム分割部１２において分割される前のフレームのサイズであり、ペイロード５７に格納される分割データの分割前のフレームのサイズである。また、オフセット位置５６は、フレーム分割部１２において分割されたときのフレームの先頭からのオフセット位置である。したがって、例えばフレームの先頭の分割データが格納されたパケットの場合、オフセット位置５６にはゼロが設定される。なお、本実施形態において、オフセットの基準となる位置はフレームの先頭としたが、オフセットの基準となる位置は必ずしもフレームの先頭の位置でなくても構わない。

【0029】

（送信装置１の動作）
送信装置１のデータ取得部１１は、送信装置１が備える例えばカメラ・マイク等からのメディアデータ（静止画・動画・音声等）を取得する。フレーム分割部１２は、データ取得部１１が取得したメディアデータを、予め設定された所定のサイズのフレームに分割する。

【0030】

パケット生成部１３は、フレーム分割部１２によって分割されたフレームのデータにＲＴＰヘッダ５１を付与してＲＴＰパケット５０を生成する。この際、パケット生成部１３は、分割前のフレームのサイズ（フレームサイズ５５）と、当該パケットのペイロードに含まれるデータの、分割前のフレームの先頭からのオフセット位置５６等をＲＴＰ拡張ヘッダ５２に格納する。パケット生成部１３が生成したパケットは、順次送信バッファ１４に格納され、パケット送信部１５によって受信装置２に順次送信される。

【0031】

（受信装置２の動作）
図８は、本実施形態におけるパケット受信からフレーム再結合までの処理例を示す説明図である。図８において、パケット（１～１０）は、図４と同ように、１つのフレームを分割したデータを格納したパケットである。

【0032】

本実施形態の受信装置２では、新しいフレームの分割データが格納された最初のパケット（図８のパケット（１））を受信する際に、上述のＲＴＰ拡張ヘッダ５２中の情報に基づいて、１フレーム分のデータを格納可能なフレーム再結合用のバッファ３３を予約する。なお、このフレーム再結合用のバッファ３３は、図３の再結合バッファ２４に相当するものであり、例えば受信装置２が備えるメモリの所定の領域を割り当てる。そして、以降、パケット（２～１０）を受信する毎に、フレーム再結合用のバッファに受信したパケットのペイロードのデータを格納する。したがって、本実施形態では、パケット（１～１０）を全て受信した段階で、改めてペイロードのデータのコピーを行うことなく、フレームの再結合が完了する。

【0033】

図９は、本実施形態におけるパケット受信からフレーム再結合までの処理の例を示すフローチャートである。
受信装置２のパケット解析部２３は、Ｓ１１において、パケット受信部２１がＲＴＰパケットを受信すると、Ｓ１２において、ＲＴＰヘッダのタイムスタンプが、それまでに受信したＲＴＰパケットのタイムスタンプより新しいか否かを判定する。Ｓ１１で受信したＲＴＰパケットのタイムスタンプが新しい場合はＳ１３に進む。ＲＴＰパケット中のタイムスタンプは、フレーム毎に異なる値が設定されており、受信したＲＴＰパケットのタイムスタンプがそれまでに受信したＲＴＰパケットのもより新しければ、それまでに受信していない新しいフレームのパケットを受信したことになる。つまり、パケット解析部２３は、新しいフレームの最初のパケットを受信した場合のみＳ１３に進む。パケット解析部２３は、は、Ｓ１３において、ＲＴＰ拡張ヘッダ５２からフレームサイズ５５を取得し、Ｓ１４において、フレームサイズ５５で指定されたフレームのデータを格納可能なフレーム再結合用バッファ３３を予約する。

【0034】

一方、Ｓ１２において、受信したＲＴＰパケットのタイムスタンプが、それまでに受信したＲＴＰパケットのものより新しくない場合は、既にＳ１３及びＳ１４でフレーム再結合用バッファ３３を予約済みなので、パケット解析部２３は、Ｓ１５に進む。パケット解析部２３は、Ｓ１５において、受信したパケットのＲＴＰ拡張ヘッダ５２からオフセット位置５６を取得する。続くＳ１６において、パケット解析部２３は、既に予約されているフレーム再結合用バッファ３３中のオフセット位置５６で指定された位置に、受信したＲＴＰパケットのペイロードのデータを格納する。

【0035】

パケット解析部２３は、Ｓ１７において、１つのフレームを構成するパケットを全て受信したか判定する。１つのフレームを構成するパケットを全て受信していない場合は、Ｓ１１に戻る。これにより、１つのフレームを構成するＲＴＰパケットを全て受信するまでＳ１１からＳ１６の処理を繰り返す。

【0036】

このように、本実施形態では、１つのフレームを構成する最後のＲＴＰパケットを受信し、当該パケットのペイロードのデータをフレーム再結合用バッファ３３に格納した時点でフレームの再結合が完了する。つまり、本実施形態では、ＲＴＰパケットの受信毎にフレーム再結合処理、すなわちペイロードのデータをフレーム再結合用バッファの適切な位置に格納する処理を行っている。このため、従来のように１つのフレームを構成するＲＴＰパケットを全て受信した後に、全ての受信済みパケットのペイロードのデータをフレーム再結合用バッファにコピーする必要がなくなる。これにより、本実施形態では、フレームのデータを再結合する処理を分散させることができる。

【0037】

なお、図９のＳ１１においてＲＴＰパケットを受信する際に、ペイロードを除くＲＴＰヘッダのみを受信し、Ｓ１６においてペイロードのデータを、ＲＴＰパケットの受信用ソケットから直接、フレーム結合用バッファの所定のオフセット位置に格納してもよい。これにより、受信バッファがフレーム結合用バッファを兼ねることになるので、フレーム再結合の処理負荷を時間軸上で分散させるだけでなく、別途ペイロードのデータをコピーする必要がなくなるため、さらなる処理負荷の軽減（処理の効率化）が可能になる。

【0038】

ところで、ＲＴＰ拡張ヘッダ５２に格納する情報として、フレームサイズ５５は必ずしも必要ではない。つまり、ＲＴＰ拡張ヘッダに格納する情報がオフセット位置５６のみであった場合、図９のＳ１３の処理は省略される。この場合、Ｓ１４で１フレーム分のペイロードを全て格納するのに十分なバッファを用意できれば、以降の処理は問題なく実行できる。

【0039】

すなわち、フレームサイズ５５を取得できた方がバッファとして予約したメモリを無駄なく使用できるので、メモリの使用効率は良くなるが、フレームサイズ５５を取得できなくてもフレームのデータの再結合の処理負荷を分散させることができる。

【0040】

なお、本実施形態では送信装置１と受信装置２との間の通信プロトコルとしてＲＴＰを用いる場合を説明したが、本実施形態で用いる通信プロトコルはＲＴＰに限定されない。例えば、通信プロトコルは、概ねＴＲＰと同様の特性を持つＵＤＰのコネクションレス型のプロトコルでもよい。すなわち、送信された複数のパケットの到達順が保証されないため、ＲＴＰと同様の特性を持つ他の通信プロトコルを用いてもよい。

【0041】

実施形態２
実施形態１では、フレームサイズやオフセット位置をＲＴＰ拡張ヘッダに格納する例について説明したが、本実施形態ではシーケンスナンバーに関する情報をＲＴＰヘッダに格納する例について説明する。

【0042】

図１０は、本実施形態におけるＲＴＰパケットの構成例を示す概略図である。
ＲＴＰパケット８０は、パケットの属性等を示すＲＴＰヘッダ８１と、フレーム分割部１２によって分割されたフレームのデータが格納されるペイロード８７とを備えている。ＲＴＰヘッダ８１は、ＲＴＰ拡張ヘッダ８２を備えており、ＲＴＰ拡張ヘッダ８２には先頭パケットのシーケンスナンバー８３とフレームを構成するパケット数（フレームのデータの分割数）８４が格納されている。先頭パケットのシーケンスナンバー８３は、フレーム分割部１２で分割されたフレームの先頭のデータが格納されたパケットのシーケンスナンバーである。なお、ＲＴＰヘッダ８１には、パケットの順番を示す標準のシーケンスナンバー８５が含まれる。上述のシーケンスナンバーに関する情報には、シーケンスナンバー８５と、パケット数８４が含まれる。フレームを構成するパケット数８４は、フレーム分割部１２で分割された際の分割数が格納される。なお、パケットがフレームを構成する先頭パケットであった場合には、先頭パケットのシーケンスナンバー８３にも当該パケットのシーケンスナンバー８５と同じ値が格納される。

【0043】

図１１は、本実施形態におけるパケット受信からフレーム再結合までの処理例を示すフローチャートである。
図１１において、Ｓ２１～Ｓ２２、Ｓ２６の処理は、実施形態１で説明した図９のＳ１１～Ｓ１２、Ｓ１７の処理と同様のため説明を省略する。以下、実施形態１と異なる部分であるＳ２３からＳ２６までの処理について説明する。

【0044】

Ｓ２３において、受信装置２のパケット解析部２３は、ＲＴＰ拡張ヘッダから先頭パケットのシーケンスナンバー８３とフレームを構成するパケット数８４を取得する。Ｓ２４において、パケット解析部２３は、取得したパケット数８４に基づいて、フレーム再結合用バッファを予約する。このとき、本実施形態では、送信装置１のフレーム分割部１２がフレームを所定のサイズで分割することが可能で、基本的に各フレームを同一サイズで分割することを前提とする。すなわち、受信装置２側では、パケット生成部１３で生成されるＲＴＰパケットは基本的に所定のペイロードサイズに統一されているものとして扱う。

【0045】

したがって、Ｓ２４において、パケット解析部２３は、所定のペイロードサイズにフレームを構成するパケット数８４を乗算したサイズのバッファをフレーム結合用バッファとして予約する。なお、１つのフレームを分割した最後の分割データを格納したパケットのペイロードは分割前のフレームのサイズを所定のペイロードサイズで除算した残りのサイズとなるため、所定のペイロードサイズより小さい値となる。

【0046】

Ｓ２５において、パケット解析部２３は、受信したＲＴＰパケットのＲＴＰヘッダ８１からシーケンスナンバー８５を取得する。先頭パケットのシーケンスナンバー８３と当該パケットのシーケンスナンバー８５から、先頭から何番目に位置するデータなのかが判明するので、所定のペイロードサイズを乗算することで、ペイロードのデータを格納すべきオフセット位置が確定する。例えば、受信したＲＴＰパケットが先頭から３番目に位置する場合、当該パケットの前に２つのパケットが存在するため、受信装置２は、所定のペイロードサイズを２倍した位置を所定のオフセット位置とする。その後、パケット解析部２３は、Ｓ２６において、ペイロードのデータをフレーム結合用バッファのオフセット位置に格納する。

【0047】

以上のように、ペイロードのサイズを所定のサイズに固定すれば、フレーム内でのパケットの順番を知ることでペイロードのデータの格納位置を特定することができる。したがって、実施形態１と同様に、パケットを再結合用のバッファ中の適切な位置に格納することができる。このため、本実施形態では、実施形態１と同様に、フレームのデータを再結合する処理負荷を分散させることができる。

【0048】

（送信装置の構成）
図１２に、上述の実施形態１及び２に係る送信装置１のハードウェア構成を示す。送信装置１は、そのハードウェア構成として、例えば、記憶部１２１、制御部１２２、機能部１２３、入力部１２４、出力部１２５、及び通信部１２６を有する。なお、図１２の構成は一例であり、送信装置１は、図１２に示す構成の一部のみを有してもよいし、図１２に示される以外の構成を有してもよい。

【0049】

記憶部１２１は、ＲＯＭ、ＲＡＭの両方、または、いずれか一方の、１以上のメモリにより構成され、前述の各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。ここで、ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略であり、ＲＡＭはＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略である。なお、記憶部１２１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。

【0050】

制御部１２２は、例えば、ＣＰＵやＭＰＵ等の一つ以上のプロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）等により構成される。ここで、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの頭字語である。制御部１２２は、記憶部１２１に記憶されたプログラムを実行することにより送信装置１の全体を制御する。なお、制御部１２２は、記憶部１２１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により送信装置１の全体を制御するようにしてもよい。

【0051】

また、制御部１２２は、機能部１２３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部１２３は、送信装置１が所定の処理を実行するためのハードウェアである。例えば、送信装置１がカメラである場合、機能部１２３は撮像部であり、撮像処理を行う。機能部１２３が処理するデータは、記憶部１２１に記憶されているデータであってもよいし、後述する通信部１２６を介してＳＴＡと通信したデータであってもよい。

【0052】

入力部１２４は、ユーザからの各種操作の受付を行う。出力部１２５は、ユーザに対して各種出力を行う。ここで、出力部１２５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部１２４と出力部１２５の両方を１つのモジュールで実現するようにしてもよい。
通信部１２６は、有線通信又は無線通信の制御や、ＩＰ通信の制御を行う。送信装置１は通信部１２６を介して、映像データや音声データ等のメディアコンテンツを他の通信装置（受信装置２）と通信する。
なお、受信装置２についても、図１２と同様のハードウェア構成を備えている。

【0053】

（その他の実施形態）
以上、各実施形態を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インターフェイス機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

【0054】

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。ＡＳＩＣはＡｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略である。

【符号の説明】

【0055】

１…送信装置、２…受信装置、３…ネットワーク、１１…データ取得部、１２…フレーム分割部、１３…パケット生成部、１４…送信バッファ、１５…パケット送信部、２１…パケット受信部、２２…受信バッファ、２３…パケット解析部、２４…再結合バッファ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】