JP6083964B2 - 送信装置、送信方法、及びプログラム - Google Patents

Description

本発明はデータを送信する送信装置、送信方法、及びプログラムに関する。

従来、データをネットワーク経由でリアルタイムに送信するための通信プロトコルとして、ＲＴＰ（Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ，ＲＦＣ３５５０，ＩＥＴＦ）等が知られている。

またデータを符号化する技術として、Ｈ．２６４／ＡＶＣ（ＩＳＯ／ＩＥＣ １４４９６）やＪＰＥＧ（ＩＳＯ／ＩＥＣ １０９１８）等が知られている。

データのリアルタイム送信においては、受信装置におけるリアルタイム性を確保するために、送信装置は遅延無く送信データを送信する必要がある。

しかし、送信データ量が多かったり、ネットワークの帯域が不足していたりすると、データ送信装置の送信処理が滞ってしまう場合がある。送信装置が有する送信バッファに送信データをバッファリングする構成では、送信装置の送信処理が滞ると、送信バッファに送信データが滞留してしまう。送信バッファに送信データが滞留してしまうと、データ受信装置におけるデータ受信のリアルタイム性が確保できなくなってしまう可能性がある。

そこで、送信バッファに送信データが滞留してしまった場合にもリアルタイム性を確保してデータ送信を行うための方法として、送信バッファに滞留している送信データの送信を諦め、バッファ内送信データを破棄して送信しない方法が知られている。

例えば、送信バッファ内の映像データのうち、次に出力される画面内符号化された映像データまでの送信データを破棄して送信しない技術が知られている（例えば、特許文献１）。ここで、画面内符号化された映像データとは、他の映像フレームの映像データを参照せずに符号化された映像データであって、受信装置が他の映像フレームの映像データを参照せずに復号化することができる映像データである。

特開２０１０−２４５８２２号公報

送信バッファに送信データが滞留してしまうと、受信装置におけるデータ受信のリアルタイム性が確保できなくなってしまう可能性がある。

上記課題を解決するための一手段として、本発明の送信装置は以下の構成を備える。

すなわち、映像に係るデータを保持するバッファ手段と、前記データを受信装置へ送信する送信手段と、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを前記送信手段から前記受信装置へ送信させる送信制御を行う送信制御手段とを有し、前記送信制御手段は、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されるときに、第１のフレームを構成する一部のデータが前記送信手段によって前記受信装置に送信済みで残りのデータが前記バッファ手段に保持されているときは、前記残りのデータは前記送信手段から前記受信装置へ送信させる。
また、上記課題を解決するための一手段として、本発明の他の送信装置は以下の構成を備える。
映像に係るデータを保持するバッファ手段と、前記データを受信装置へ送信する送信手段と、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを前記送信手段から前記受信装置へ送信させる送信制御を行う送信制御手段とを有し、前記送信制御手段は、前記バッファ手段に保持されているデータのデータ量が第１の閾値より大きく第２の閾値以下である場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量よりも、前記バッファ手段に保持されているデータのデータ量が前記第２の閾値より大きい場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量が大きくなるように前記送信制御を行う。

本発明によれば、受信装置に配信されるデータのリアルタイム性を高めることができる。

実施例１における送信装置の構成例 実施例１における送信装置の機能ブロック図 実施例１におけるパケット送信処理を示すフローチャート 実施例１におけるキューに保持されたパケットの送信処理を示すフローチャート 実施例１におけるパケット破棄処理を示すフローチャート 実施例１におけるパケット破棄処理の例を示す図 実施例１におけるパケットの構成を示す図 実施例２におけるパケット送信処理を示すフローチャート 実施例２におけるパケット破棄処理を示すフローチャート 実施例３におけるパケット送信処理を示すフローチャート 実施例３におけるパケット第１の破棄処理を示すフローチャート Ｈ．２６４／ＡＶＣ符号化におけるフレーム間参照の例を示す図

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜実施例１＞
本実施例では、カメラ等で撮像した映像のフレームデータを、受信装置にリアルタイムに送信する送信装置について説明する。ここで、フレームデータには、映像データ及びそれに付随するメタデータや音声データが含まれていてもよい。送信装置や受信装置はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などで接続することとしてもよい。

本実施例における送信装置の構成例を図１に示す。制御部１０１は、図１に示した送信装置の各構成の動作を制御する。制御部１０１は例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のプロセッサにより構成される。制御部１０１がプロセッサとして構成される場合、制御部１０１は記憶部１０２に記憶されたプログラムを読み出して実行することにより、図１に示した送信装置の各構成の動作を制御する。

記憶部１０２は、制御部１０１が実行するプログラム等を格納する。記憶部１０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等により構成される。

保持部１０３は、制御部１０１の主メモリ、ワークエリア等として機能する。保持部１０３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等により構成される。また、保持部１０３は、受信装置に送信されていないデータを保持する送信バッファ（キュー）としての役割を有する。本実施例において保持部１０３は、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ）制御により、保持したパケットを出力する。すなわち、保持部１０３は、フレームデータを分割したパケットデータを保持する。

通信部１０４は、ネットワークを介して受信装置との情報の入出力を制御する。ネットワークとして例えば、インターネットや公衆無線、ＬＡＮ等を用いることができる。ネットワークの通信規格や規模、有線、無線は問わない。

撮像部１０５は、被写体の撮像を行う。撮像部１０５は、レンズやＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）などの撮像素子などによって構成される。撮像素子はレンズによって結像された被写体の像を画像信号に変換する。

撮像制御部１０６は、撮像部１０５の撮影方向や画角を制御する。撮像制御部１０６は、例えば、撮像部１０５のパン・チルト・ズーム等の制御を行う。

画像処理部１０７は、撮像部１０５によって撮像され生成された画像信号に対し、画像処理を行う。例えば、画像処理部１０７は、撮像部１０５によって生成されるデータに対し、ホワイトバランス処理、ガンマ処理、ノイズ低減処理等の各種処理を行う。

符号化部１０８は、画像処理部１０７によって画像処理が施されたデータを所定の符号化方式に応じて変換する処理を行う。本実施例では、Ｈ．２６４／ＡＶＣで符号化する例について説明するが、符号化方式は特にこれに限られない。バス１１０は図１に示した各構成を接続し、各種データの転送経路となる。

生成部１０９は、符号化されたデータを複数に分割したデータセグメントを生成する。例えば、生成部１０９は、符号化部１０８によって符号化されたデータから送信プロトコルに応じたパケットを生成する。本実施例では、送信プロトコルとしてＲＴＰ（Ｒｅａｌ‐ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用いる場合について説明する。ただし送信プロトコルはこれに限られない。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等を用いる構成としてもよい。

次に、制御部１０１の機能構成図について図２を用いて説明する。制御部１０１がプロセッサを内蔵する場合、図２の各ブロックに示す各機能は、当該プロセッサが記憶部１０２に記憶されたプログラムを実行することにより実現される。あるいは図２の各ブロックに示す各機能の一部又は全体は、個別のハードウェアにより実現されることとしてもよい。

入力制御部２０１は、映像データや音声データ、メタデータ等のデータを符号化部１０８に入力する制御を行う。符号化制御部２０２は、符号化部１０８を制御して、入力されたデータを符号化させる。生成制御部２０３は、生成部１０９を制御して、符号化されたデータを送信プロトコルに応じてパケット化する。

送信制御部２０４は、生成されたパケットを通信部１０４から受信装置に送信させる。また送信制御部２０４は、管理部２０６の制御に応じて、保持部１０３に保持されたパケットデータを受信装置に送信する制御を行う。保持制御部２０５は、生成されたパケットのうち未送信のパケットを保持部１０３に保持させる制御を行う。

管理部２０６は、保持部１０３に保持したパケットの管理を行う。具体的には、未送信のパケットを、キューとしての保持部１０３にエンキュー（ｅｎｑｕｅｕｅ）したり、キューの先頭パケットをデキュー（ｄｅｑｕｅｕｅ）して通信部１０４に渡したりする。また、管理部２０６は、必要に応じて保持部１０３内のパケットを破棄して送信しないように制御する。

次に、本実施例にかかる送信装置の動作について、図３から図５を用いて説明する。制御部１０１がプロセッサを内蔵する形態では、図３から図５の処理フローは、図３から図５に示す手順を当該プロセッサに実行させるためのプログラムを示す。制御部１０１が内蔵するプロセッサはコンピュータであり、記憶部１０２から読み出したプログラムを実行する。

まず、生成部１０９により生成されたパケット（ｔｈｉｓ）を通信部１０４に入力するまでの処理フローについて図３を用いて説明する。送信制御部２０４の制御により、通信部１０４にパケット（ｔｈｉｓ）が入力される（Ｓ３０１）。通信部１０４にパケットが入力された場合（Ｓ３０１においてＹｅｓの場合）、管理部２０６は、保持部１０３にパケットがバッファリングされているか確認する（Ｓ３０２）。一方、通信部１０４にパケットの入力が無い場合（Ｓ３０１においてＮｏの場合）、処理を終了する。

通信部１０４にパケット（ｔｈｉｓ）が入力され、保持部１０３にパケットが保持されていない場合（Ｓ３０２においてＮｏの場合）、管理部２０６はパケットが受信装置へ送信されるか否かを判定する（Ｓ３０３）。判定方法は特に限定しない。

パケットが受信装置へ送信されない場合として、例えば、ネットワークが輻輳状態にある場合や、受信装置がパケットを受信することができない状態である場合等がある。

送信装置と受信装置とが通信を行うために用いるプロトコルとしてＲＴＰを用いる場合、ラウンドトリップタイムに基づいてネットワークが輻輳状態にあるか判定することができる。ここでラウンドトリップタイムとは、送信装置と受信装置の一方が他方に対してパケットを送信してから、他方の装置からその返答が返ってくるまでの時間のことをいう。ラウンドトリップタイムに基づいてネットワークが輻輳状態にあるか判定する方法として例えば、ＴＦＲＣ（ＴＣＰ Ｆｒｉｅｎｄｌｙ Ｒａｔｅ Ｃｏｎｔｒｏｌ）等の制御が知られている。このような判定の結果に応じて、ステップＳ３０３の判定を行うこととしてもよい。例えば、ネットワークが輻輳状態にあると判定された場合に、パケットが受信装置へ送信されないと判定することができる。

送信装置と受信装置とが通信を行うために用いるプロトコルとしてＴＣＰを用いる場合、送信装置が送信した１又は複数のセグメント（送信単位あたりのデータ）に対する確認応答（Ａｃｋ）を受信装置から受信したことに応じて、次のセグメントが送信される。従って、受信装置から確認応答が受信されない場合、送信装置からパケットが送信されない状態が生じることとなる。そこで、送信装置が送信したデータに対する所定の確認応答を受信装置から受信したかに応じて、ステップＳ３０３の判定を行うこととしてもよい。例えば、受信装置から所定の確認応答が受信されない場合に、パケットが受信装置へ送信されないと判定することができる。

また、ＴＣＰを用いる場合には、受信装置の受信バッファの大きさ（ウィンドウサイズ）を超えるデータ量のデータを一度に受信装置に送信することができない。従って、送信しようとするデータのサイズがウィンドウサイズを超える場合、ウィンドウサイズを超えるパケットデータは受信装置へ送信されない。そこで、送信装置が送信するデータサイズと、受信装置が受信可能なデータサイズとに応じて、ステップＳ３０３の判定を行うこととしてもよい。例えば、送信装置が送信するデータのサイズが、ウィンドウサイズを超える場合に、パケットが受信装置へ送信されないと判定することができる。

パケットが受信装置へ送信されると管理部２０６が判定した場合（Ｓ３０３においてＹｅｓの場合）、送信制御部２０４は通信部１０４を制御して、入力されたパケット（ｔｈｉｓ）を受信装置に送信する処理を行う（Ｓ３０４）。

一方、パケットが受信装置へ送信されないと管理部２０６が判定した場合（Ｓ３０３においてＮｏの場合）、管理部２０６はパケット（ｔｈｉｓ）をキューとしての保持部１０３にエンキューする処理を行う（Ｓ３０５）。

ステップＳ３０２の処理において、キューとしての保持部１０３にパケットが保持されている場合（Ｓ３０２においてＮｏの場合）、送信制御部２０４は、保持部１０３に保持されたパケットの送信処理を行う（Ｓ４００）。すなわち、パケット（ｔｈｉｓ）をキューとしての保持部１０３にエンキューしつつ、キュー内に既に保持されているパケットを先頭から順に受信装置に送信する処理を行う。

ここで、ステップＳ４００における送信処理について図４を用いて説明する。まず、管理部２０６は、パケット（ｔｈｉｓ）が、保持部１０３に保持され、他のフレームを参照せずに符号化されるフレームを構成するパケットのうち先頭のパケットであるか否かを判定する（Ｓ４０１）。他のフレームを参照せずに符号化されるフレームとは、例えば、画面内予測符号化により符号化されたフレームでありＨ．２６４／ＡＶＣ符号化におけるＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）フレームが該当する。また例えば、Ｉフレーム（Ｉｎｔｒａ−ｃｏｄｅｄ Ｆｒａｍｅ）が該当する。他のフレームを参照せずに符号化されるフレームを構成するパケットは、受信装置において、他のフレームのデータを参照せずに復号化することができる。本実施例では、ステップＳ４０１においてパケット（ｔｈｉｓ）が、保持部１０３に保持されたパケットのうち先頭のＩフレームであるか否か判定する例について説明する。

パケット（ｔｈｉｓ）が、保持部１０３に保持され、他のフレームを参照せずに符号化されるフレームを構成するパケットのうち先頭のパケットである場合（Ｓ４０１でＹｅｓの場合）、図５を用いて後述するパケット破棄処理を行う（Ｓ５００）。本実施例にかかるパケット破棄処理は、保持部１０３に保持された複数のパケットデータのうち一部のパケットデータを受信装置に送信しない制御を行う処理である。このようにして、管理部２０６は、フレーム内符号化されたフレームデータの先頭を構成するパケットデータを保持部１０３に保持する場合に、パケット破棄処理を行わせる。

パケット（ｔｈｉｓ）が保持部１０３に保持されたパケットのうち先頭のＩフレームではないと判定された場合（Ｓ４０１でＮｏの場合）、又は、ステップＳ５００の処理を行った場合は、管理部２０６はステップＳ４０２の処理を行う。ステップＳ４０２において管理部２０６はパケット（ｔｈｉｓ）をキューとしての保持部１０３にエンキューする。

次に管理部２０６は、パケット送信が行われるか否かを判定する。判定の方法は図３のステップＳ３０３の処理と同様であり、特に限定しない。

パケット送信が行われると判定した場合（Ｓ４０３においてＹｅｓの場合）、管理部２０６は保持部１０３（キュー）から先頭のパケットを読み出し（デキュー）する（Ｓ４０４）。そして送信制御部２０４は読み出したパケットを受信装置へ送信する（Ｓ４０５）。

続いて管理部２０６は、パケットの読出しにより、キューとしての保持部１０３が空になったか判定する（Ｓ４０６）。キューにパケットが残っている場合（Ｓ４０６においてＮｏの場合）、管理部２０６はステップＳ４０３においてパケットの送信が行われないと判定するまで、ステップＳ４０３からステップＳ４０６の処理を繰り返す。一方、キューにパケットが残っていない場合（Ｓ４０６においてＹｅｓの場合）、管理部２０６はパケット送信処理を終了する。

ステップＳ４０３において、パケット送信が行われないと判定した場合、管理部２０６は、キューに保持されたデータの大きさ（蓄積データサイズ）と予め定めた閾値を比較する（Ｓ４０７）。

蓄積データサイズが閾値を超えている場合（ステップＳ４０７においてＹｅｓの場合）図５を用いて後述するパケット破棄処理（Ｓ５００）を行い、破棄処理後にキュー内パケット送信処理を終了する。このようにして、管理部２０６は、保持部１０３に保持されたパケットデータの大きさが所定の閾値を超える場合に、パケット破棄処理を行わせる。

ステップＳ４０３において、蓄積データサイズと予め定めた閾値を比較する処理に替えて、１つのパケットデータがキューに保持されている時間（保持時間）と閾値とを比較することとしてもよい。保持時間が閾値を超える場合はパケット破棄処理（Ｓ５００）を行い、保持時間が閾値以下である場合には、ステップＳ４０２の処理を行う。このようにして、管理部２０６は、１つのパケットデータが保持部１０３に保持された時間が所定の閾値を超えた場合に、パケット破棄処理を行わせることができる。

次に、上述のＳ５００におけるパケット破棄処理について図５を用いて説明する。管理部２０６は、まず、キュー内の先頭のパケットをパケット（ｎｅｘｔ）として取得する（Ｓ５０１）。ここで、キュー内の先頭のパケットとは、キューに保持されているパケットのうち最初にデキューされるパケットである。

次に、管理部２０６はパケット（ｎｅｘｔ）が取得できたかどうかを判定する（Ｓ５０２）。先頭パケット（ｎｅｘｔ）が取得できた場合、管理部２０６はパケット（ｎｅｘｔ）がフレームの先頭パケットかどうかを判定する（Ｓ５０３）。ここで、フレームの先頭パケットとは、１枚のパケットを構成する複数のパケットのうち、最初にキューからデキューされるパケットである。

パケット（ｎｅｘｔ）がフレームの先頭パケットではない場合（Ｓ５０３においてＮｏの場合）、管理部２０６はキュー内のパケット（ｎｅｘｔ）の次にデキューされるパケットを取得し、取得したパケットを新たなパケット（ｎｅｘｔ）とする（Ｓ５０４）。そして、ステップＳ５０２の処理に戻る。

パケット（ｎｅｘｔ）が先頭パケットである場合（Ｓ５０３においてＹｅｓの場合）、管理部２０６はキュー内のパケット（ｎｅｘｔ）を含む、パケット（ｎｅｘｔ）以降の全パケットを破棄する（Ｓ５０５）。そして、管理部２０６はパケット破棄処理を終了する。

ステップＳ５０２において、キュー内でパケット（ｎｅｘｔ）が取得できない場合（Ｓ５０２でＹｅｓの場合）、キューに保持されたパケットのデータサイズと所定の閾値とを比較する（Ｓ５０６）。ここで、パケット（ｎｅｘｔ）が取得できない場合とは、キュー内の最後のパケットがパケット（ｎｅｘｔ）となっている場合である。すなわち、キュー内のすべてのパケットについてステップＳ５０３の判定処理を行ったが、キュー内のいずれのパケットもフレームの先頭パケットではなかった場合である。ここで、キュー内の最後のパケットとは、キュー内のパケットのうち、最後にデキューされるパケットのことである。

キューに保持されたパケットのデータサイズが所定の閾値を超えている場合（ステップＳ５０６でＹｅｓの場合）、キュー内の全パケットを破棄し（Ｓ５０７）、キュー内パケット破棄処理を終了する。キューに保持されたパケットのデータサイズが閾値以下の場合（Ｓ５０６でＮｏの場合）は、そのままキパケット破棄処理を終了する。

このようにして管理部２０６は、パケット破棄処理において、受信装置に送信した第１のパケットデータにより構成されるフレームデータを構成するパケットデータであって保持部１０３に保持されている第２のパケットデータを受信装置に送信させる。

また、図４のステップＳ４０１において上述のパケット破棄処理を行うことにより、第１のフレームデータの先頭のパケットデータから、第２のフレームデータの先頭のパケットデータの前までのパケットデータを破棄することができる。すなわち、第１のフレームデータの先頭を構成する第３のパケットデータから、第２のフレームデータの先頭を構成する第４のパケットデータの前のパケットデータまでを受信装置に送信しないように制御できる。本実施例において、第４のパケットデータとは、ステップＳ４０１においてＩフレームの先頭パケットであると判定されたパケット（ｔｈｉｓ）である。

図６（ａ）に示した例において、パケットデータ６０１から６０９は、それぞれＨ．２６４／ＡＶＣの符号化方式を用いて符号化された送信データを分割したパケットを示している。

キュー６００に保持される各パケットの構成を図７に示す。パケットデータ７００は、図６に示したパケットデータ６０１から６０９のそれぞれに対応する。パケットデータ７００は、ＲＴＰパケット７０１およびエレメントヘッダ７０４を含む。

ＲＴＰパケット７０１はさらに、ＲＴＰペイロード７０２及びＲＴＰヘッダ７０３を含む。ＲＴＰペイロード７０２は、Ｈ．２６４／ＡＶＣの符号化方式を用いて符号化された映像データを格納する。ＲＴＰヘッダ７０３は、ＲＴＰペイロード７０２に格納された映像データについてのマーカービットやシーケンスナンバー、タイムスタンプ等を格納する。

エレメントヘッダ７０４は、先頭フラグ７０５とＩフレームフラグ７０６を含む。フレーム先頭フラグ７０５は、フレームの先頭パケットであるか否かを示すフラグである。Ｉフレームフラグ７０６は、Ｉフレームを構成するパケットであるか否かを示すフラグである。これらのフラグは、図４を用いて説明したパケット送信処理におけるＳ４０１の処理や、図５を用いて説明したパケット破棄処理におけるステップＳ５０３の処理において用いられる。エレメントヘッダ７０４は、パケットデータ７００がデキューされ、通信部１０４に送られる際に破棄される。

キュー６００にＩフレームの先頭パケットであるパケットデータ６０９がエンキューされる場合の処理について、図６（ａ）を用いて説明する。ここで、図６（ａ）に示す例では、キュー６００にはＰフレーム（１）、Ｐフレーム（２）、Ｐフレーム（３）を構成するパケットが既にエンキューされているものとする。各Ｐフレーム（１）から（３）はそれぞれ１枚のフレームである。さらに、図６（ａ）に示す例では、Ｐフレーム（１）を構成する３枚のパケットデータ６０１、６０２、６０３のうちパケットデータ６０１がデキューされ、受信装置に送信済みであるものとする。

図６（ａ）の例において、パケットデータ６０９がエンキューされようとすると、キュー６００内のパケットの有無が判定される（図３ Ｓ３０２）。キュー６００にパケットが格納されていると判定されると（Ｓ３０２でＮｏ）、図４を用いて説明したパケット送信処理を実行する（図３ Ｓ４００）。

パケット送信処理においては、図４を用いて説明したように、まずエンキューされようとするパケットデータ６０９がＩフレームの先頭パケットであるか否か判定する（図４ Ｓ４０１）。図６（ａ）の例では、入力されたパケットがＩフレームの先頭パケットであると判定され（Ｓ４０１でＹｅｓ）、図５を用いて説明したパケット破棄処理（図４ Ｓ５００）に移行する。本実施例におけるパケット破棄処理は、保持部１０３に保持された複数のパケットデータのうち一部のパケットデータを受信装置に送信しない制御を行う処理である。

図５を用いて説明したパケット破棄処理では、キュー内の先頭パケットから順にパケットを取得し、フレームの先頭パケットを探す。図６（ａ）に示した例では、パケットデータ６０２はＰ（１）フレームの先頭フレームではないので、図５に示したステップＳ５０３においてＮｏに進み、次のパケットデータ６０３がフレームの先頭パケットであるか判断される。同様にして、パケットデータ６０３もＰ（１）フレームの先頭パケットではないので、次のパケットデータ６０４がフレームの先頭パケットであるか判断される。

パケットデータ６０４は図６（ａ）に示すようにＰ（２）フレームの先頭パケットである（図５ Ｓ５０３においてＹｅｓ）。そこで、図５に示したステップＳ５０５の処理に進み、パケットデータ６０４以降のパケットを破棄してパケット破棄処理を終了する。

ここで、パケット破棄処理を行った場合、キュー６００に残ったパケットのＲＴＰヘッダ７０３のシーケンスナンバーを、パケットの破棄数分進めることとしてもよい。パケット破棄処理（図４ Ｓ５００）を終了すると、パケットデータ６０９がエンキューされる（図４ Ｓ４０２）。

パケットデータ６０９がエンキューされた状況を図６（ｂ）に示す。図６（ｂ）の例では、既にフレームの一部（パケットデータ６０１）を送信済みであるＰ（１）を構成するパケット（パケットデータ６０２及びパケットデータ６０３）は破棄されずキュー６００に残る。従って、パケットデータ６０２及びパケットデータ６０３は受信装置に送信される。このようにして、パケット破棄処理を行う場合に、受信装置に送信した第１のパケットデータにより構成されるフレームデータを構成するパケットデータであって保持部１０３に保持されている第２のパケットデータを前記受信装置に送信する制御を行う。

本実施例に示した送信装置によれば、フレームの一部を送信済みである場合には当該フレームを構成するパケットを破棄せず、受信装置に送信することができる。従って、フレームを構成する一部のパケットが送信されず、受信装置に送信されたフレームの映像が乱れてしまうことを防ぐことができる。

また、本実施例に示した送信装置によれば、他のフレームを参照せずに復号化することができるフレーム（例えば、Ｉフレーム）の先頭パケットがエンキューされる場合に、キュー内のパケットの一部又は全部を破棄する（送信しないようにする）制御を行う。
図６の例では、第１のフレームデータＰ（２）の先頭のパケットデータ６０４から、第２のフレームデータの先頭のパケットデータ６０９の前までのパケットデータを破棄することができる。このようにして、新しくエンキューされたパケットデータを速やかに受信装置に送信することができる。従って、受信装置に配信されるデータのリアルタイム性を高めることができる。

本実施例では、既に一部のデータ送信したフレームを構成するパケット（６０２、６０３）に続いて、他のフレームを参照せずに復号化することができるフレームの先頭パケット（６０９）を送信する。従って、破棄処理に伴って、受信装置が復号することができないパケットデータが受信装置に送信されることを防ぐことができる。ここで、破棄処理に伴って、受信装置が復号することができないパケットデータが送信されてしまう場合とは、例えば、受信装置に送信されたパケットデータを復号化する際に参照するパケットデータがパケット破棄処理によって破棄されてしまう場合等がある。

本実施例では、Ｉフレームの先頭パケットがエンキューされる場合、及び、キューの蓄積データサイズが閾値を超えている場合にパケット破棄処理を行う場合について説明したが、これに限られない。Ｉフレームの先頭パケットがエンキューされる場合、又は、キューの蓄積データサイズが閾値を超えている場合のどちらかの場合にパケット破棄処理を行うこととしてもよい。また、上述の場合に限られず、所定のタイミングでパケット破棄処理を行うこととしてもよい。

また本実施例では、パケット破棄処理において、キュー内の最初のフレームの先頭パケットを検出した場合、それ以降のパケットを破棄する例について図５を用いて説明したが、これに限られない。例えば、キューの先頭から任意のフレーム数後のフレームの先頭パケットを検出した場合、それ以降のパケットを破棄するようにしてもよい。

＜実施例２＞
本実施例では、データの復号に際し他のフレームを参照する必要があるか否かの区別がないデータを送信する場合について説明する。例えばＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）による符号化形式を用いて符号化されたデータを送信する場合が含まれる。あるいは、送信される全てのフレームが、他のフレームを参照せずに符号化されたフレーム（例えば、Ｉフレーム）である場合が含まれる。

本実施例にかかる送信装置の構成は、実施例１において図１及び図２を用いて説明した内容と同じであるため説明を省略する。

次に、本実施例における送信装置の動作について、図８及び図９を用いて説明する。制御部１０１がプロセッサを内蔵する形態では、図８及び図９の処理フローは、図８及び図９に示す手順を当該プロセッサに実行させるためのプログラムを示す。制御部１０１が内蔵するプロセッサはコンピュータであり、記憶部１０２から読み出したプログラムを実行する。

まず、本実施例におけるパケット送信処理について図８を用いて説明する。はじめに、管理部２０６はパケット（ｔｈｉｓ）をキューとしての保持部１０３にエンキューする（Ｓ８０１）。

続いて、管理部２０６は、パケットが送信されるか否かの判定を行う（Ｓ８０２）。ステップＳ８０２の判定処理は、実施例１において図３を用いて説明したステップＳ３０３の処理と同様であるので説明を省略する。管理部２０６は、パケットが送信される場合（Ｓ８０２でＹｅｓの場合）、キューの先頭パケットをデキューする（Ｓ８０３）。

ステップＳ８０３において、キューの先頭パケットがデキューされると、管理部２０６はデキューしたパケットがフレームの先頭パケットかどうかを判定する（Ｓ８０４）。

デキューしたパケットがフレームの先頭パケットである場合（Ｓ８０４においてＹｅｓの場合）、管理部２０６はデキューしたパケットのキュー内における滞留時間と予め定めた閾値を比較する（Ｓ８０５）。

ここで、パケットのキュー内滞留時間は、実施例１において図７を用いて説明したエレメントヘッダ７０４にエンキューされた時刻の情報を記録し、現在時刻とエンキューされた時刻との差から算出できる。ただし滞留時間の算出方法はこれに限られない。

デキューしたパケットのキュー内における滞留時間が閾値を超える場合（Ｓ８０５においてＹｅｓの場合）は、デキューしたパケットを破棄する（Ｓ８０８）。そして、デキューしたパケットの破棄後、パケット破棄処理を行ってパケット送信処理を終了する（Ｓ９００）。ステップＳ９００におけるパケット破棄処理は、保持部１０３に保持された複数のパケットデータのうち一部のパケットデータを受信装置に送信しない制御を行う処理である。本実施例におけるパケット破棄処理の詳細については図９を用いて後述する。

デキューしたパケットがフレームの先頭パケットでない場合（Ｓ８０４においてＮｏの場合）、又は、滞留時間が閾値以下である場合（Ｓ８０５においてＮｏの場合）、送信制御部２０４はデキューしたパケットを送信する制御を行う（Ｓ８０６）。パケット送信後、管理部２０６はキューが空かどうかを判定する（Ｓ８０７）。

キューが空である場合（Ｓ８０７においてＹｅｓの場合）、管理部２０６はパケット送信処理を終了する。一方、キューにデータが保持されている場合（Ｓ８０７においてＮｏの場合）、管理部２０６はステップＳ８０２の処理に戻る。

ステップＳ８０２においてパケットの送信が行われないと判定した場合、管理部２０６はキューに保持されたデータのサイズ（蓄積データサイズ）と予め定めた閾値を比較する（Ｓ８０９）。キュー内の蓄積データサイズが閾値を超える場合（Ｓ８０９においてＹｅｓの場合）、パケット破棄処理を行った後、パケット送信処理を終了する（Ｓ９００）。一方、キュー内の蓄積データサイズが閾値以下の場合（Ｓ８０９においてＮｏの場合）、パケット送信処理を終了する。

本実施例における送信処理によれば、キューからフレームの先頭パケットがデキューされた場合であって、当該パケットのキュー内滞留時間が閾値以上である場合に、デキューしたパケットを破棄し、さらにキュー内のパケット破棄処理を行う。このような構成によれば、フレームの先頭パケットからパケットの破棄処理が開始される。すなわち、フレームの一部のデータを送信済である場合には、当該フレームを構成する他のデータを全て送信し終えてからパケットの破棄処理が開始される。このようにして、フレームの一部のデータが送信済みである場合には、当該フレームを構成するパケットを全て送信することができる。したがって、パケットの破棄処理によって、フレーム画像が乱れてしまうことを防ぐことができる。

次に本実施例におけるパケット破棄処理（Ｓ９００）について、図９を用いて説明する。はじめに管理部２０６は、キューが空であるか否かを判定する（Ｓ９０１）。キューが空の場合（Ｓ９０１においてＹｅｓの場合）、管理部２０６はパケット破棄処理を終了する。一方、キューに送信データが保持されている場合（Ｓ９０１においてＮｏの場合）、管理部２０６はキューの先頭パケットを取得する（Ｓ９０２）。

キューの先頭パケットを取得すると、管理部２０６は取得したパケットがフレームの先頭パケットかどうかを判定する（Ｓ９０３）。取得したパケットがフレームの先頭パケットでないと判定した場合（Ｓ９０３においてＮｏの場合）、パケットを破棄する（Ｓ９０６）。一方、取得したパケットが先頭パケットである場合（Ｓ９０３においてＹｅｓの場合）、管理部２０６はパケットのキュー内における滞留時間と予め定めた閾値とを比較する（Ｓ９０４）。ここで、パケットの滞留時間は、例えばステップＳ８０５において説明した方法により算出することができる。

キュー内滞留時間が閾値を超える場合（Ｓ９０４においてＹｅｓの場合）、管理部２０６はパケットを破棄する（Ｓ９０６）。一方、パケットのキュー内における滞留時間が閾値以内である場合（Ｓ９０４においてＮｏの場合）、管理部２０６はキュー内の蓄積データサイズと予め定めた閾値とを比較する（Ｓ９０５）。

キュー内蓄積データサイズが閾値を超える場合（Ｓ９０６においてＹｅｓの場合）、管理部２０６はパケットを破棄する（Ｓ９０６）。一方キュー内の蓄積データサイズが閾値以内である場合（Ｓ９０５においてＮＯの場合）、管理部２０６はパケット破棄処理を終了する。

ステップＳ９０６においてパケットを破棄した後、管理部２０６はステップＳ９０１の処理に戻る。そしてパケット破棄処理を継続する。

本実施例では、パケットのキュー内における滞留時間及びキューに保持されたデータサイズを判定する場合について説明したがこれに限られない。例えば、パケットのキュー内における滞留時間又はキューに保持されたデータサイズのいずれか一方のみ判定することとしてもよい。

以上のようにして、キューの先頭にフレームの先頭パケットがある場合であって、キュー内の滞留時間及び蓄積データサイズが閾値以下となった場合にパケット破棄処理を終了する。すなわち、パケット破棄後、フレームの先頭パケットからパケット送信を開始する。すなわち、フレームを構成するデータの全体を受信装置に送信するようにすることができる。従って、フレームを構成する一部のデータのみが受信装置に送信されることを防ぐことができる。このようにして、パケット破棄処理に伴ってフレームの画像が乱れてしまうことを防ぐことができる。

本実施例にかかる送信装置によれば、パケット破棄処理を開始する場合には、送信済みのデータが構成するフレームについては、そのフレームを構成する全てのデータを送信した後に、パケット破棄処理を開始することができる。また、本実施例にかかる送信装置によれば、パケット破棄処理を行う場合、パケット破棄後、フレームの先頭データから送信が開始されるようにすることができる。このようにして、パケット破棄処理に伴ってフレームの画像が乱れてしまうことを防ぐことができる。

＜実施例３＞
本実施例では、段階的にキュー内パケットを破棄して送信しないように制御する例について説明する。本実施例にかかる送信装置の構成は、実施例１において図１及び図２を用いて説明した内容と同じであるため説明を省略する。

次に、本実施例における送信装置の動作について、図１０及び図１１を用いて説明する。制御部１０１がプロセッサを内蔵する形態では、図１０及び図１１の処理フローは、図１０及び図１１に示す手順を当該プロセッサに実行させるためのプログラムを示す。制御部１０１が内蔵するプロセッサはコンピュータであり、記憶部１０２から読み出したプログラムを実行する。

まず、本実施例にかかるパケット送信処理について図１０を用いて説明する。はじめに、パケット（ｔｈｉｓ）が、他のフレームを参照せずに符号化されたフレーム（例えば、Ｉフレーム）の先頭パケットであるか否かを判定する（Ｓ１００１）。

パケット（ｔｈｉｓ）がＩフレームの先頭パケットである場合（Ｓ１００１においてＹｅｓの場合）、第２の破棄処理（Ｓ５００）を実行する。第２破棄処理の内容について実施例１において図５を用いて説明した内容と同じであるため、説明を省略する。

パケット（ｔｈｉｓ）がＩフレームの先頭パケットではない場合（Ｓ１００１においてＮｏ）の場合、又は、ステップＳ５００の処理を終了した場合、管理部２０６はパケット（ｔｈｉｓ）をキューにエンキューする（Ｓ１００２）。

パケット（ｔｈｉｓ）をエンキューすると、管理部２０６はパケット送信が行われるか否かを判定する（Ｓ１００３）。ステップＳ１００３の判定は図３のステップＳ３０３において説明した内容と同様であるため説明を省略する。

パケットの送信が行われる場合（Ｓ１００３においてＹｅｓの場合）、管理部２０６はキューからパケットをデキューする（Ｓ１００４）。そして、送信制御部２０４はデキューしたパケットを送信する制御を行う（Ｓ１００５）。

ステップＳ１００５においてパケットを送信すると、管理部２０６はキューが空になったか否かを判定する（Ｓ１００６）。キューにデータが保持されている場合（Ｓ１００６においてＮｏの場合）、管理部２０６はステップＳ１００３の処理に戻る。一方、キューにデータが空である場合（Ｓ１００６においてＹｅｓの場合）、管理部２０６はパケット送信処理を終了する。

ステップＳ１００３において、パケットが送信されないと判定した場合、管理部２０６は、キューに保持されたデータの大きさ（蓄積データサイズ）と予め定めた第１の閾値を比較する（Ｓ１００７）。蓄積データサイズが第１の閾値以下である場合（Ｓ１００７においてＮｏの場合）、管理部２０６はパケット送信処理を終了する。

蓄積データサイズが第１の閾値よりも大きい場合（Ｓ１００７においてＹｅｓの場合）、管理部２０６は蓄積データサイズを第２の閾値（ただし第１の閾値＜第２の閾値とする）と比較する（Ｓ１００８）。蓄積データサイズが第２の閾値以下である場合（Ｓ１００８においてＮｏの場合）、管理部２０６は第１のパケット破棄処理を行う（Ｓ１１００）。第１のパケット破棄処理の詳細については、図１１を用いて後述する。蓄積データサイズが第２の閾値よりも大きい場合（Ｓ１００８においてＹｅｓの場合）、管理部２０６は第２のパケット破棄処理を行う（Ｓ５００）。管理部は、第１のパケット破棄処理又は第２のパケット破棄処理を終了すると、パケット送信処理を終了する。ここで、第２のパケット破棄処理において破棄されるパケットのデータ量は、第１のパケット破棄処理において破棄されるパケットのデータ量よりも大きいものとする。

ステップＳ１００７及びステップＳ１００８において、蓄積データサイズと所定の閾値を比較する処理に替えて、１つのパケットデータがキューに保持されている時間（保持時間）と閾値とを比較することとしてもよい。保持時間が第１の閾値より長く第２の閾値（第１の閾値＜第２の閾値）以下である場合には第１のパケット破棄処理を行う。保持時間が第２の閾値より長い場合には第２のパケット破棄処理を行う。

次に、本実施例における第１のパケット破棄処理について、図１１を用いて説明する。まず、管理部２０６はキューの先頭パケットを取得し、パケット（ｎｅｘｔ）とする（Ｓ１１０１）。

次に、管理部２０６はパケット（ｎｅｘｔ）がフレームの先頭パケットであるか否かを判定する（Ｓ１１０２）。パケット（ｎｅｘｔ）がフレームの先頭パケットではない場合（Ｓ１１０２においてＮｏの場合）、管理部２０６はパケット（ｎｅｘｔ）の次のパケットを取得し、新たなパケット（ｎｅｘｔ）とする（Ｓ１１０３）。

ステップＳ１１０３の処理を行うと、管理部２０６は次のパケットを取得できるどうかを判定する（Ｓ１１０４）。すなわち、管理部２０６はキュー内の最後のパケットまで処理を終えたか判定する。

パケット（ｎｅｘｔ）が取得できなかった場合（Ｓ１１０４においてＮｏの場合）、管理部２０６は第１の破棄処理を終了する。すなわち管理部２０６は、キュー内のすべてのパケットをスキャンし終わった場合は第１の破棄処理を終了する。一方、パケット（ｎｅｘｔ）が取得できた場合は、管理部２０６はステップＳ１１０２の処理に戻り、処理を継続する。

ステップＳ１１０２の判定処理において、パケット（ｎｅｘｔ）がフレームの先頭パケットであると判定された場合、管理部２０６は当該フレームが他のフレームから参照されていないフレームであるか否か判定する（Ｓ１１０５）。判定処理は、図７を用いて説明したエレメントヘッダ７０４内に、他のフレームからの参照があることを示すフラグを追加するようにし、フラグの有無で参照の有無を判定するようにすることができる。ただし、判定の方法はこれに限られない。

ここで、他のフレームから参照されていないフレームについて図１２を用いて説明する。
図１２の例では、Ｈ．２６４／ＡＶＣを用いた符号化におけるフレーム間の参照について説明する。

フレーム１２０１から１２０８はそれぞれＨ．２６４／ＡＶＣを用いて符号化されたフレームである。図１２の例では、左方向から右方向へ向かってパケットが送信されるものとする。Ｉフレーム１２０１からＰフレーム１２０７までのフレームは１組のＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）を構成する。

図１２における矢印は符号化時の参照方向であり、フレームの内側に書かれた文字は符号化フレームの種類を示す。ここで、Ｉフレームはフレーム間予測を用いずに符号化されるフレームである。Ｐフレームは前方向予測のみを用いて符号化されるフレームである。Ｂフレームは前方向予測、後方向予測、両方向予測のうちいずれかを選択して符号化されるフレームである。

図１２の例では、Ｉフレーム１２０１は、Ｂフレーム１２０２及びＰフレーム１２０３に参照されている。Ｐフレーム１２０３は、Ｂフレーム１２０２及びＢフレーム１２０４に参照されている。図１２の例では、Ｂフレーム１２０２、１２０４、１２０６が他のフレームから参照されていないフレームとなる。

図１１の処理の説明に戻る。パケット（ｎｅｘｔ）を含むフレームが他のフレームから参照されていないフレームである場合（Ｓ１１０５においてＮｏの場合）、管理部２０６はステップＳ１１０３の処理に進む。一方、パケット（ｎｅｘｔ）を含むフレームが他のフレームから参照されたフレームである場合（Ｓ１１０５においてＹｅｓの場合）、管理部２０６はキューからパケット（ｎｅｘｔ）を破棄する（Ｓ１１０６）。ステップＳ１１０６においてパケット（ｎｅｘｔ）を破棄すると、管理部２０６はキュー内のパケット（ｎｅｘｔ）の次のパケットを取得して、取得したパケットを新たなパケット（ｎｅｘｔ）とする（Ｓ１１０７）。

新たなパケット（ｎｅｘｔ）を設定すると、管理部２０６は新たなパケット（ｎｅｘｔ）がキューから取得可能であるか判断する（Ｓ１１０８）。新たなパケット（ｎｅｘｔ）を取得することができなかった場合、管理部２０６は第１の破棄処理を終了する。すなわち、キューに保持された最後のパケットまで処理を行った場合には第１の破棄処理を終了する。

一方、新たなパケット（ｎｅｘｔ）を取得することができた場合（ステップＳ１１０８においてＮｏの場合）、新たなパケット（ｎｅｘｔ）はフレームの先頭パケットであるか判定する（Ｓ１１０９）。新たなパケット（ｎｅｘｔ）がフレームの先頭パケットではない場合（Ｓ１１０９においてＮｏの場合）、管理部２０６はステップＳ１１０６の処理に戻る。一方、新たなパケット（ｎｅｘｔ）がフレームの先頭パケットであると判定した場合（Ｓ１１０９においてＹｅｓの場合）、ステップＳ１１０５の処理に戻る。

本実施例における第１の破棄処理では、キュー内のパケットの中から、他のフレームから参照されていないフレームを構成するパケットを破棄する。しかし、第１の破棄処理において、これ以外の方法でパケット破棄処理を行うようにしてもよい。例えば、キュー内の後方から任意のフレームを破棄することとしてもよい。また、例えばＪＰＥＧのように他のフレームを参照しない符号化方式で符号化されている場合であれば、キュー内のフレームの中から複数フレーム毎に１フレーム破棄する等の方法で破棄処理を行うこととしてもよい。

本実施例においては、キューに保持されたデータのサイズが第１の閾値よりも大きい場合、さらにキュー内のデータサイズが第１の閾値よりも大きい第２の閾値よりも大きいか判定する。キュー内のデータサイズが第１の閾値より大きく第２の閾値以下である場合は、キューに保持されたパケットのうち、他のフレームから参照されていないフレームを構成するパケットを破棄する。キュー内のデータサイズが第２の閾値よりも大きい場合には、送信済みのデータが含まれるフレームを構成するデータがキュー内に残るようにして、キュー内のデータの破棄処理を行う。

このようにして、本実施例によれば、キューに保持されたデータの大きさに応じて、キューに保持されたデータの破棄を段階的に行うことができる。

＜その他の実施例＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０３ 保持部
１０４ 通信部
２０４ 送信制御部
２０５ 保持制御部
２０６ 管理部

Claims (15)

1. 映像に係るデータを保持するバッファ手段と、
   前記データを受信装置へ送信する送信手段と、
   他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを前記送信手段から前記受信装置へ送信させる送信制御を行う送信制御手段と
   を有し、
   前記送信制御手段は、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されるときに、第１のフレームを構成する一部のデータが前記送信手段によって前記受信装置に送信済みで残りのデータが前記バッファ手段に保持されているときは、前記残りのデータは前記送信手段から前記受信装置へ送信させる
   ことを特徴とする送信装置。
2. 映像に係るデータを保持するバッファ手段と、
   前記データを受信装置へ送信する送信手段と、
   他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを前記送信手段から前記受信装置へ送信させる送信制御を行う送信制御手段と
   を有し、
   前記送信制御手段は、前記バッファ手段に保持されているデータのデータ量が第１の閾値より大きく第２の閾値以下である場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量よりも、前記バッファ手段に保持されているデータのデータ量が前記第２の閾値より大きい場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量が大きくなるように前記送信制御を行う
   ことを特徴とする送信装置。
3. 前記送信制御手段は、前記バッファ手段に保持されているデータのデータ量が前記第２の閾値より大きい場合において、前記送信制御を行う場合、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持される前に前記バッファ手段に保持されていた全てのデータを前記送信手段から前記受信装置へ送信させない
   ことを特徴とする請求項２に記載の送信装置。
4. 前記送信制御手段は、第２のフレームの先頭を構成するデータが前記送信手段から前記受信装置へ送信されずに前記バッファ手段に保持されている場合に、前記送信制御を行う
   ことを特徴とする請求項１〜３のいずれか１項に記載の送信装置。
5. 前記少なくとも一部のデータは、前記第２のフレームのデータである
   ことを特徴とする請求項４記載の送信装置。
6. 前記少なくとも一部のデータは、他のフレームを参照して復号されるフレームのデータである
   ことを特徴とする請求項１〜５のいずれか１項に記載の送信装置。
7. 前記送信制御手段は、前記バッファ手段が保持するデータのデータ量が所定の閾値を超えた状態、ネットワークが輻輳している状態、前記受信装置がデータを受信できない状態、及び、１つのデータが前記バッファ手段に保持されている時間が所定の閾値を超えた状態のうちのいずれかの状態になると、前記送信制御を行う
   ことを特徴とする請求項１〜６のいずれか１項に記載の送信装置。
8. 映像に係るデータを受信装置に送信する送信方法であって、
   前記データをバッファ手段に保持させる保持ステップと、
   他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを送信手段から前記受信装置へ送信させる送信制御を行う送信制御ステップと
   を有し、
   前記送信制御ステップでは、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されるときに、第１のフレームを構成する一部のデータが前記送信手段によって前記受信装置に送信済みで残りのデータが前記バッファ手段に保持されているときは、前記残りのデータは前記送信手段から前記受信装置へ送信させる
   ことを特徴とする送信方法。
9. 映像に係るデータを受信装置に送信する送信方法であって、
   前記データをバッファ手段に保持させる保持ステップと、
   他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持されることに応じて、前記バッファ手段に保持されているデータのうちの少なくとも一部のデータを送信させずに、他のフレームを参照しないで復号されるフレームのデータを送信手段から前記受信装置へ送信させる送信制御を行う送信制御ステップと
   を有し、
   前記送信制御ステップでは、前記バッファ手段に保持されているデータのデータ量が第１の閾値より大きく第２の閾値以下である場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量よりも、前記バッファ手段に保持されているデータのデータ量が前記第２の閾値より大きい場合において前記送信手段から前記受信装置へ送信しないように制御するデータのデータ量が大きくなるように前記送信制御を行う
   ことを特徴とする送信方法。
10. 前記送信制御ステップでは、前記バッファ手段に保持されているデータのデータ量が前記第２の閾値より大きい場合において、前記送信制御を行う場合、他のフレームを参照しないで復号されるフレームのデータが前記バッファ手段に保持される前に前記バッファ手段に保持されていた全てのデータを前記送信手段から前記受信装置へ送信させない
    ことを特徴とする請求項９に記載の送信方法。
11. 前記送信制御ステップでは、第２のフレームの先頭を構成するデータが前記送信手段から前記受信装置へ送信されずに前記バッファ手段に保持されている場合に、前記送信制御を行う
    ことを特徴とする請求項８〜１０のいずれか１項に記載の送信方法。
12. 前記少なくとも一部のデータは、前記第２のフレームのデータである
    ことを特徴とする請求項１１記載の送信方法。
13. 前記少なくとも一部のデータは、他のフレームを参照して復号されるフレームのデータである
    ことを特徴とする請求項８〜１２のいずれか１項に記載の送信方法。
14. 前記送信制御ステップでは、前記バッファ手段が保持するデータのデータ量が所定の閾値を超えた状態、ネットワークが輻輳している状態、前記受信装置がデータを受信できない状態、及び、１つのデータが前記バッファ手段に保持されている時間が所定の閾値を超えた状態のうちのいずれかの状態になると、前記送信制御を行う
    ことを特徴とする請求項８〜１３のいずれか１項に記載の送信方法。
15. コンピュータを、請求項１〜７のいずれか１項に記載の送信制御手段として機能させるためのプログラム。

Images