(57)【要約】【課題】  コンテンツデータを送信する送信装置の負荷にそぐわない送信可否の判定が行われてしまう恐れがあった。【解決手段】  送信装置１０１の受信部１０８は、符号化方式の指定を含むコンテンツデータの要求を受信装置１０２から受信し（Ｓ２０１）、送信可否判定部１０９は、受信した要求に応じてコンテンツデータを送信するか否かを、指定された符号化方式に応じた負荷値を用いて判定し（Ｓ２０４）、送信部１０７は、送信可否判定部１０９による判定結果に応じて、コンテンツデータを符号化して送信する。【選択図】  図２
2013012833.tif 000002
【特許請求の範囲】
【請求項１】
符号化したコンテンツデータを送信する送信装置であって、
符号化方式の指定を含む要求を受信装置から受信する受信手段と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に応じた負荷値を用いて判定する判定手段と、
前記符号化したコンテンツデータを前記判定手段による判定に応じて送信する送信手段とを有することを特徴とする送信装置。
【請求項２】
前記判定手段は、第１の受信装置から受信した第１の要求に応じて第１のコンテンツデータを送信している場合において、第２の受信装置から前記第１のコンテンツデータとは符号化方式が異なる第２の要求を受信すると、前記第１のコンテンツデータの符号化方式に応じた第１の負荷値と、前記第２の要求の符号化方式に応じた第２の負荷値との合計値と閾値との比較に基づいて前記第２の要求に応じたコンテンツデータを送信するか否かを判定することを特徴とする請求項１に記載の送信装置。
【請求項３】
前記受信手段は、映像の符号化方式と解像度の指定を含む要求を前記受信装置から受信し、
前記判定手段は、前記受信した要求に応じて映像コンテンツデータを送信するか否かを、前記指定された符号化方式と解像度に応じた負荷値と、閾値との比較に基づいて判定することを特徴とする請求項１又は２に記載の送信装置。
【請求項４】
前記受信手段は、映像の符号化方式とフレームレートの指定を含む要求を前記受信装置から受信し、
前記判定手段は、前記受信した要求に応じて映像コンテンツデータを送信するか否かを、前記指定された符号化方式とフレームレートに応じた負荷値と、閾値との比較に基づいて判定することを特徴とする請求項１又は２に記載の送信装置。
【請求項５】
前記判定手段は、第１の受信装置から受信した第１の要求に応じて第１のコンテンツデータを送信している場合において、第２の受信装置から前記第１の要求と指定内容が一致する第２の要求を受信すると、前記第１のコンテンツデータの生成に関する負荷値と、前記第１のコンテンツデータの前記第１の受信装置への送信に関する負荷値と、前記第１のコンテンツデータの前記第２の受信装置への送信に関する負荷値との合計値に応じて、前記第２の受信装置に対して、前記第２の要求に応じたコンテンツデータを送信すると判定することを特徴とする請求項１乃至４のうち、いずれか１項に記載の送信装置。
【請求項６】
前記判定手段は、第１の受信装置から受信した第１の要求に応じて第１の映像コンテンツデータを送信している場合において、前記第１の要求に対応する映像コンテンツデータの符号化方式と一致し、フレームレートが前記第１の要求よりも低い第２の要求を第２の受信装置から受信すると、前記第１の映像コンテンツデータの生成に関する負荷値と、前記第１の要求に応じたフレームレートでの前記第１のコンテンツデータの前記第１の受信装置への送信に関する負荷値と、前記第２の要求に応じたフレームレートでの前記第２のコンテンツデータの前記第２の受信装置への送信に関する負荷値との合計値に応じて、前記第２の受信装置に対して、前記第２の要求に応じた映像コンテンツデータを送信すると判定することを特徴とする請求項１乃至４のうちいずれか１項に記載の送信装置。
【請求項７】
複数の符号化方式のそれぞれに対応する負荷値を記憶する記憶手段を有し、
前記判定手段は、前記記憶手段から前記指定された符号化方式に応じた負荷値を取得することを特徴とする請求項１乃至６のうち、いずれか１項に記載の送信装置。
【請求項８】
前記符号化したコンテンツデータのデータ量を計測する計測手段を有し、
前記記憶手段に記憶された負荷値を、前記計測手段により計測されたコンテンツデータのデータ量に基づいて変更する変更手段を有することを特徴とする請求項７に記載の送信装置。
【請求項９】
前記判定手段は、前記受信した要求に応じたコンテンツデータを送信しないと前記負荷値に基づいて判定した場合、前記受信した要求に含まれる指定内容とは異なるコンテンツデータを送信可能であるかを判定し、
前記送信手段は、前記判定手段により送信可能であると判定されたコンテンツデータが存在することを、前記要求を送信した受信装置に通知することを特徴とする請求項１乃至８のうち、いずれか１項に記載の送信装置。
【請求項１０】
符号化したコンテンツデータを送信する送信装置が行う送信制御方法であって、
符号化方式の指定を含む要求を受信装置から受信する受信工程と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に対応する負荷値を用いて判定する判定工程と、
前記符号化したコンテンツデータを前記判定工程による判定に応じて送信する送信工程とを有することを特徴とする送信制御方法。
【請求項１１】
符号化したコンテンツデータを送信するコンピュータに、
符号化方式の指定を含む要求を受信装置から受信する受信手順と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に対応する負荷値を用いて判定する判定手順と、
前記符号化したコンテンツデータを前記判定手順による判定に応じて送信する送信手順とを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを送信する送信装置の制御方法に関する。
【背景技術】
【０００２】
現在、インターネット等のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを用いたメディア伝送が普及している。また、カメラ等で撮影した動画像や音声等のメディアデータをネットワーク経由でリアルタイムに伝送するプロトコルであるＲＴＰ（Ａ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｒｅａｌ−Ｔｉｍｅ  Ａｐｐｌｉｃａｔｉｏｎｓ）が利用されてきている。また、メディアデータを受信するデバイスやネットワーク形態も多岐にわたっており、様々な解像度の映像や異なる符号化形式のメディア伝送が求められている。
メディアデータのリアルタイム伝送においては、データ受信装置における再生時のメディアの品質維持のために、データ送信装置の処理負荷等を考慮して、接続数を制限する必要がある。従来の送信制御方法として、予め固定の最大接続数を設定しておく方法やＣＰＵ使用率等からデータ送信装置の現在の処理負荷を考慮して接続可否を判定する方法が知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１４７３４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、コンテンツデータを送信する送信装置の負荷にそぐわない送信可否の判定が行われてしまう恐れがあった。
すなわち、例えば、受信装置からの要求に応じたコンテンツデータを送信装置が送信できるにも関わらず、当該要求に応じたコンテンツデータを送信しないと判定されてしまう恐れがあった。
【０００５】
また、例えば、受信装置からの要求に応じたコンテンツデータを送信すれば、バッファがオーバーフローしてしまうにも関わらず、当該要求に応じたコンテンツデータを送信すると判定されてしまう恐れがあった。
【０００６】
例えば、一般的に、Ｍｏｔｉｏｎ−ＪＰＥＧとＨ．２６４／ＡＶＣのエンコーダは、同じ解像度・同じフレームレートであれば処理負荷は後者の方が大きく、発生符号量は前者の方が多い。また、同じ符号化方式でも解像度やフレームレートが異なれば処理負荷及び発生符号量は大きく異なる。従って、受信装置の最大接続数を閾値として送信可否の判定を行うと、当該閾値によっては、データを送信できるにも関わらず、送信しないと判定されてしまう場合や、データを送信できないにも関わらず、送信すると判定されてしまう場合があった。
【０００７】
本発明は上述した問題を解決するためになされたものであり、その目的は、送信装置の負荷に、より則した送信可否の判定方法を提供することである。
【課題を解決するための手段】
【０００８】
上記問題点を解決するために、本発明の送信装置は、例えば、以下の構成を有する。すなわち、符号化したコンテンツデータを送信する送信装置であって、符号化方式の指定を含む要求を受信装置から受信する受信手段と、前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に応じた負荷値を用いて判定する判定手段と、前記符号化したコンテンツデータを前記判定手段による判定に応じて送信する送信手段とを有する。
【発明の効果】
【０００９】
以上の構成からなる本発明によれば、送信装置の負荷に、より則した送信可否の判定ができるようになる。
【図面の簡単な説明】
【００１０】
【図１】システムの機能ブロック図
【図２】送信可否判定部１０９の処理の一例を示すフローチャート
【図３】図２のＳ２０３の処理の一例を示すフローチャート
【図４】実施形態の状況説明図
【図５】各メディアの初期負荷値及び負荷係数の一例
【図６】受信装置から新しいメディア要求を受信する場合の処理例
【図７】ＧＯＰ単位のパケット数の推移グラフの一例
【図８】データ形態変更による送信可否判定処理の一例を示すフローチャート
【発明を実施するための形態】
【００１１】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１２】
＜第１の実施形態＞
本実施形態のコンテンツデータ送信システムの構成について、図１の機能ブロック図を参照して説明する。
【００１３】
図１において、送信装置１０１は、コンテンツデータ（コンテンツパケット）を送信する機能を備えている。送信装置１０１は、単一もしくは複数のコンピュータ装置で実現可能である。また、送信装置１０１は、例えば、通信機能を備えたカメラであってもよい。
【００１４】
受信装置１０２は、送信装置１０１が送信したコンテンツデータを受信する機能を備えている。受信装置１０２は、単一もしくは複数のコンピュータで実現可能である。また、受信装置１０２は、例えば、通信機能を備えたストレージ装置やテレビであってもよい。なお、図１では、送信装置１０１及び受信装置１０２がそれぞれ１台ずつ接続されているが、複数台接続させることが可能である。
【００１５】
送信装置１０１と受信装置１０２は、互いに通信可能なようにネットワーク１０３を介して接続されている。
【００１６】
送信装置１０１は、データ入力部１０４、データ符号化部１０５、パケット生成部１０６、送信部１０７、受信部１０８、送信可否判定部１０９、メモリ１１５を含んで構成されている。
【００１７】
受信装置１０２は、要求情報生成部１１０、送信部１１１、受信部１１２、データ復号化部１１３、データ再生部１１４を含んで構成されている。
【００１８】
まず、送信装置１０１の処理の流れを説明する。データ入力部１０４は、コンテンツデータを入力する。本形態では、コンテンツデータが映像データ（映像コンテンツデータ）である場合の例を中心に説明するが、例えば、音声データやテキストデータなど、他の種類であっても良い。データ入力部１０４は、例えば、ビデオカメラ、ネットワークカメラ等の映像センサや、ストレージメディアなどから映像データを入力する。データ入力部１０４は、映像データをデータ符号化部１０５に入力する。
【００１９】
データ符号化部１０５は、データ入力部１０４からのコンテンツデータを符号化方式に従い符号化する。ここで符号化方式とは、例えば、Ｈ．２６４／ＡＶＣやＭｏｔｉｏｎ−ＪＰＥＧである。また、コンテンツデータが音声データであれば、例えば、Ｇ．７１１やＧ．７２６等が挙げられる。ただし、符号化方式は、上記の方式に限らない。データ符号化部１０５により符号化されたコンテンツデータはパケット生成部１０６に渡される。
【００２０】
パケット生成部１０６は、符号化されたコンテンツデータから通信に適したパケット（コンテンツパケット）を生成する。通信プロトコルとしてＲＴＰを用いる場合、一般的には１５００バイト程度のＲＴＰパケットが生成される。生成されたコンテンツパケットは送信部１０７に渡される。送信部１０７は、生成されたコンテンツパケットをネットワーク１０３を介して受信装置１０２へ送信する。
【００２１】
受信部１０８は、受信装置１０２からネットワーク１０３を介してパケットを受信する。受信部１０８が受信するパケットには、コンテンツ要求パケットが含まれる。コンテンツ要求パケットには、受信装置１０２が要求するコンテンツの種別情報が含まれる。コンテンツの種別情報は、例えば、受信装置１０２が送信装置１０１に対して要求するコンテンツデータの符号化方式や映像の解像度、フレームレートなどである。なお、要求するコンテンツデータが音声データであれば、コンテンツの種別情報は、音声の符号化方式やサンプリングレート等の情報である。
【００２２】
なお、コンテンツの種別情報は、コンテンツの種別（例えば解像度）を明確に指定する情報（例えば、３２０ｘ２４０、６４０ｘ４８０）であっても、送信装置１０１がコンテンツの種別を判別できる識別子（例えば、大、中、小）であっても良い。また、コンテンツ要求パケットと、コンテンツの種別情報とが別々のパケットで送信されるようにしても良い。
【００２３】
送信可否判定部１０９は、受信部１０８が受信したコンテンツ要求パケットに含まれるコンテンツの種別情報から、当該コンテンツ要求パケットに対応するコンテンツデータの送信可否を判定する。判定方法の詳細については後述する。
【００２４】
送信可否判定部１０９による判定結果は、送信部１０７によって、判定結果パケットとして受信装置１０２に通知される。判定結果パケットの送信には、例えば、セッション制御プロトコルとしてのＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）やＳＩＰプロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等が用いられるが、それ以外のプロトコルを用いても良い。
【００２５】
次に、受信装置１０２の処理の流れを説明する。要求情報生成部１１０は、受信装置１０２のユーザ入力に基づいて、コンテンツ要求パケットを生成する。コンテンツ要求パケットには、送信装置１０１に要求するコンテンツ（映像データ）の符号化方式、解像度、フレームレートなどを特定するためのコンテンツ種別情報が含まれる。
【００２６】
送信部１１１は、要求情報生成部１１０が生成したコンテンツ要求パケットを送信装置１０１へ送信する。
【００２７】
受信部１１２は、送信装置１０１の送信可否判定部１０９による送信可否の判定結果を示す判定結果パケットや、コンテンツパケットを含む種々のパケットを受信する。
【００２８】
なお、送信部１１１は、送信可否判定部１０９により送信可能であることを示す判定結果パケットを受信部１１２が受信した場合、送信装置１０１に対して、コンテンツデータの伝送要求パケットを送信する。伝送要求パケットの送信プロトコルは先述したＲＴＳＰやＳＩＰでもよいし、それ以外の方式でもよい。
【００２９】
データ復号化部１１３は、受信部１１２で受信したコンテンツパケットを復号化する。復号化したコンテンツデータはデータ再生部１１４に渡される。
データ再生部１１４は、復号化されたコンテンツデータを再生する。
【００３０】
次に、図２を用いて、送信可否判定部１０９における処理の流れを説明する。図２は、送信装置１０１の送信可否判定部１０９による処理の流れを説明するためのフローチャートである。なお、送信装置１０１は、符号化したコンテンツデータを受信装置１０２へ送信する送信装置である。また、本形態の送信装置１０１のＣＰＵは、図２に係る処理を実行するためのプログラムをＲＡＭに読み出して実行する。ただし、図２の処理の少なくとも一部を、専用のハードウェア等で行うようにすることも可能である。
【００３１】
送信可否判定部１０９は、受信部１０８が、受信装置１０２から、コンテンツ要求パケットを受信したと判定すると（Ｓ２０１でＹＥＳ）、Ｓ２０２に進む。なお、コンテンツ要求パケットには、コンテンツの種別情報が含まれる。すなわち、受信部１０８は、Ｓ２０１（受信手順）において、符号化方式と、解像度と、フレームレートの指定を含む要求を受信装置１０２から受信する。ただし、符号化方式と、解像度と、フレームレートのすべてが必ずしも含まれていなくても良い。また、コンテンツ要求パケットとコンテンツの種別情報のパケットが、別々のパケットであっても良い。また、コンテンツの種別情報は、送信装置１０１がコンテンツの種別を決定できる情報であれば良い。また、送信装置１０１は、コンテンツの種別情報を含まないコンテンツ要求パケットを受信した場合、デフォルトの種別のコンテンツを提供するようにしても良い。
送信可否判定部１０９は、現在の総負荷値をメモリ１１５から取得する（Ｓ２０２）。
【００３２】
また、Ｓ２０１で取得したコンテンツ要求パケットに応じたコンテンツデータの生成処理と送信処理に係る負荷値（要求コンテンツ負荷値）を、当該コンテンツ要求パケットに含まれるコンテンツの種別情報から決定する（Ｓ２０３）。Ｓ２０２における現在の総負荷値、及び、Ｓ２０３における要求コンテンツ負荷値の決定方法の詳細は後述する。
【００３３】
そして、送信可否判定部１０９は、Ｓ２０２で取得した現在の総負荷値に、Ｓ２０３で決定した要求コンテンツ負荷値を加算した仮総負荷値と、許容負荷値（閾値）とを比較（Ｓ２０４）する。
【００３４】
そして、送信可否判定部１０９は、仮総負荷値が許容負荷値を上回っていない場合は送信可と判定し（Ｓ２０５）、仮総負荷値が許容負荷値を上回っている場合は送信不可と判定する（Ｓ２０６）。
【００３５】
すなわち、Ｓ２０４（判定手順）において、送信可否判定部１０９は、Ｓ２０１で受信した要求に応じてコンテンツデータを送信するか否かを、指定された符号化方式に応じた負荷値を用いて判定する。そして、Ｓ２０５（送信手順）において、送信部１０７は、データ符号化部１０５が符号化したコンテンツデータを、送信可否判定部１０９による判定に応じて受信装置１０２へ送信する。
【００３６】
Ｓ２０５において、送信可と判定された場合、送信可否判定部１０９は、仮総負荷値が、現在の総負荷値となるように、メモリ１１５内の総負荷値を置き換える。
【００３７】
次に、図３を用いて、Ｓ２０３における要求コンテンツ負荷値の決定処理の流れを説明する。
【００３８】
まず、送信可否判定部１０９は、当該決定処理の出力値としての要求コンテンツ負荷値（例えば、変数ｐとする）を０で初期化する（Ｓ３０１）。
【００３９】
そして、送信可否判定部１０９は、要求されているコンテンツの種別情報を取得する（Ｓ３０２）。コンテンツの種別情報とは、例えば、映像データの符号化方式や、解像度、フレームレートなどの情報である。
【００４０】
そして、送信可否判定部１０９は、コンテンツの種別情報に対応する種別のコンテンツパケットを、すでに送信中であるか否かを判定する（Ｓ３０３）。例えば、図２のＳ２０１で受信装置１０２からコンテンツ要求パケットを受信した時点において、すでに他の受信装置に対して種別が一致するコンテンツパケットを送信していた場合、Ｓ３０３でＮＯと判定される。
【００４１】
コンテンツの種別情報に対応する種別のコンテンツパケットを送信中でないとＳ３０３で判定された場合、送信可否判定部１０９は、要求コンテンツ負荷値ｐに当該コンテンツの種別情報に対応する初期負荷値を加算する（Ｓ３０４）。本形態において、初期負荷値とは、コンテンツパケットの生成処理（符号化処理やパケット生成処理）に関する負荷を示す値である。初期負荷値の詳細については後述する。
【００４２】
また、送信可否判定部１０９は、要求コンテンツ負荷値ｐに当該コンテンツの種別情報に対応する負荷係数を加算する（Ｓ３０５）。本形態において、負荷係数とは、コンテンツパケットの送信に関する負荷を示す値である。負荷係数の詳細については後述する。
【００４３】
そして、送信可否判定部１０９は、受信装置１０２から要求されたすべてのコンテンツ（例えば、映像データと音声データ）に関してＳ３０２〜Ｓ３０５の処理を実行したか否かを判定し（Ｓ３０６）、他のコンテンツの処理が残っている場合は、Ｓ３０２に戻る。
【００４４】
次に、送信装置１０１と受信装置１０２間の全体の制御の流れをより具体的な例を交えて説明する。
【００４５】
図４は、カメラ４０１がインターネット４０２を介して、テレビＡ４０３、テレビＢ４０４、携帯端末Ａ４０５、携帯端末Ｂ４０６に対して、映像データをリアルタイムに伝送している様子を示している。なお、カメラ４０１は、図１の送信装置１０１に対応し、テレビＡ４０３、テレビＢ４０４、携帯端末Ａ４０５、携帯端末Ｂ４０６は、それぞれ、図１の受信装置１０２に対応する。
【００４６】
カメラ４０１のデータ符号化部１０５は、複数のエンコーダを有し、図４では、Ｍｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）４０７及びＨ．２６４／ＡＶＣ（ＶＧＡ）４０８のエンコーダがそれぞれ起動している。カメラ４０１は、撮像により得られた映像データ（コンテンツデータ）を、それぞれの符号化方式で符号化してコンテンツパケットを生成している。また、カメラ４０１の送信部１０７は、各受信装置１０２に対してマルチユニキャストでコンテンツパケットを送信している。
【００４７】
テレビＡ４０３はＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）のフレームレート３０ｆｐｓ（ｆｒａｍｅ／ｓｅｃｏｎｄ）の映像データ４０９を受信している。また、テレビＢ４０４は同じくＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）のフレームレート１０ｆｐｓの映像パケット４１０を受信している。
【００４８】
携帯端末Ａ４０５はＨ．２６４／ＡＶＣ（ＶＧＡ）のフレームレート３０ｆｐｓの映像データ４１１を受信しており、携帯端末Ｂ４０６も同じＨ．２６４／ＡＶＣ（ＶＧＡ）のフレームレート３０ｆｐｓの映像データ４１２を受信している。
【００４９】
図５は、カメラ４０１におけるコンテンツの種別ごとの初期負荷値と負荷係数の例である。図５のテーブルは、カメラ４０１（送信装置１０１）のメモリ１１５に記録されている。なお、本実施形態では、音声データであるＧ．７１１のサンプリングレートは指定できないものとしている。そのため、図５には、映像データの符号化方式、解像度、フレームレートに応じた初期負荷値と負荷係数のみを載せているが、音声データの種別に応じた初期負荷値や負荷係数を載せるようにすることも可能である。
【００５０】
また、図５の「映像データの種別」の欄には、映像データの符号化方式（Ｍｏｔｉｏｎ−ＪＰＥＧとＨ．２６４／ＡＶＣ）と、解像度（ＱＶＧＡとＶＧＡとＳＸＧＡ）の組み合わせが記載されている。なお、図５にも示すように、ＱＶＧＡは３２０ｘ２４０画素、ＶＧＡは６４０ｘ２４０画素、ＳＸＧＡは１２８０ｘ９６０画素を示している。また、図５に示すように、解像度が同じであれば、Ｈ．２６４／ＡＶＣのほうが、Ｍｏｔｉｏｎ−ＪＰＥＧよりも、コンテンツパケットを生成するための負荷は大きい。また、解像度が同じであれば、Ｍｏｔｉｏｎ−ＪＰＥＧのほうが、Ｈ．２６４／ＡＶＣよりも、１フレーム当たりのコンテンツパケットを送信するための負荷は大きい。
【００５１】
図５に示す初期負荷値は、フレームレートが３０ｆｐｓの場合のコンテンツパケットの生成に関する負荷値に対応している。従って、受信装置１０２から要求されるフレームレートが、３０ｆｐｓよりも低い場合は、図５に記載された初期負荷値よりも低い初期負荷値を設定することが可能である。一方、受信装置１０２から要求されるフレームレートが、３０ｆｐｓよりも高い場合は、図５に記載された初期負荷値よりも高い初期負荷値を設定することが可能である。
【００５２】
図５の表に従って図４のカメラ４０１の総負荷値を計算する。
【００５３】
まず、カメラ４０１は、テレビＡ４０３に対してＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）の映像データをフレームレート３０ｆｐｓで送信している。従って、テレビＡ４０３へのコンテンツデータの符号化及びパケット化にかかる初期負荷値２４００と、テレビＡ４０３へのコンテンツパケットの送信負荷に関する負荷係数２４０ｘ３＝７２０が加算される。
【００５４】
また、カメラ４０１は、テレビＢ４０４に対して、テレビＡ４０３と同様のＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）の映像データをフレームレート１０ｆｐｓで送信している。テレビＢ４０４へ送信される映像データの種別と、テレビＡ４０３へ送信される映像データの種別は一致しているため、テレビＢ４０４に対応する初期負荷値は加算されず、１０ｆｐｓの送信負荷に対応する負荷係数２４０が加算される。
【００５５】
また、カメラ４０１は、携帯端末Ａ４０５に対して、Ｈ．２６４／ＡＶＣ（ＶＧＡ）の映像データをフレームレート３０ｆｐｓで送信している。従って、携帯端末Ａ４０５へのコンテンツデータの符号化及びパケット化にかかる初期負荷値１６００と、携帯端末Ａ４０５へのコンテンツパケットの送信負荷に関する負荷係数３０ｘ３＝９０とが加算される。
【００５６】
さらに、カメラ４０１は、携帯端末Ｂ４０６に対して、携帯端末Ａ４０５と同様のＨ．２６４／ＡＶＣ（ＶＧＡ）の映像データをフレームレート３０ｆｐｓで送信している。携帯端末Ａ４０５へ送信される映像データの種別と、携帯端末Ｂ４０６へ送信される映像データの種別は一致しているため、携帯端末Ｂ４０６に対応する初期負荷値は加算されず、３０ｆｐｓの送信負荷に対応する負荷係数９０が加算される。
【００５７】
従って、カメラ４０１の現在の総負荷値は、これらを全て合計した５１４０となる。なお、本形態では、符号化方式と解像度が同じで、フレームレートが異なるコンテンツデータを送信する場合、フレーム間引き処理を行うようにしている。しかし、フレームレートが異なる要求ごとに、別々に符号化及びパケット化をしても良い。その場合は、それぞれに初期負荷値を加算する必要がある。
【００５８】
また、本実施形態におけるカメラ４０１の許容負荷値を６０００とする。この場合において、受信装置１０２から新しいコンテンツ要求パケットを受信したときの処理の例を図６に示す。
【００５９】
図６は、図４の状態から、新たな受信装置１０２に対応するテレビＣ６０１がＭｏｔｉｏｎ−ＪＰＥＧ（ＶＧＡ）１０ｆｐｓをＲＴＳＰプロトコルにより要求する場合を示している。まず、テレビＣ６０１は、ＲＴＳＰのＳＥＴＵＰメッセージ（コンテンツ要求パケット）６０２を用いてカメラ４０１（送信装置１０１）に対してリソースの確保を要求する。ＳＥＴＵＰメッセージ６０２（コンテンツ要求パケット）内のＵＲＬには、カメラ４０１が要求されているコンテンツの種別を識別するための種別情報（ｍ＿ｊｐｅｇ＿ｖｇａ．ａｖｉ）が含まれている。ＳＥＴＵＰメッセージ６０２を受信したカメラ４０１は、ＵＲＬに含まれている種別情報を参照することで、要求されているコンテンツの種別が、Ｍｏｔｉｏｎ−ＪＰＥＧ（ＶＧＡ）１０ｆｐｓであることを識別し、要求コンテンツ負荷値を決定する。要求コンテンツ負荷値の決定は、図２のＳ２０３に対応する。そして、カメラ４０１の送信可否判定部１０９は、要求コンテンツ負荷値と、テレビＡ、Ｂ、及び、携帯端末Ａ、Ｂへ送信しているコンテンツに関する負荷値とを合計することで、仮総負荷値を算出する。
【００６０】
カメラ４０１は、テレビＣ６０１からコンテンツ要求パケットを受信した時点において、Ｍｏｔｉｏｎ−ＪＰＥＧ（ＶＧＡ）のコンテンツパケットを送信していないので、初期負荷値１０００と負荷係数６０とが現在の総負荷値５１４０に加算される。従って、仮総負荷値は、６２００となる。カメラ４０１の許容負荷値は６０００であるため、送信可否判定部１０９は、テレビＣ６０１により要求されたコンテンツパケットは送信不可であると判定する。カメラ４０１の送信可否判定部１０９は、ＲＴＳＰのＲｅｓｐｏｎｓｅ  ｃｏｄｅ：４０６“Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅ”（６０３）（判定結果パケット）をテレビＣ６０１に送信し、コンテンツパケットの送信不可を通知する。判定可否パケットの送信には、ＲＴＳＰ  Ｒｅｓｐｏｎｓｅ  ｃｏｄｅを用いても良いし、ＲＴＳＰを用いなくてもよい。また、本実施形態のカメラ４０１は、ＲＴＳＰのＳＥＴＵＰメッセージの受信時に送信可否を判定しているが、この形態に限らない。例えば、受信装置１０２から要求されるコンテンツデータの種別を送信装置１０１が認識していれば、ＤＥＳＣＲＩＢＥメッセージやＰＬＡＹメッセージの段階で判定することも可能である。
【００６１】
続いて、テレビＣ６０１がＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）１０ｆｐｓを、同じくＲＴＳＰプロトコルによるＳＥＴＵＰメッセージ６０４にて要求した場合の送信可否判定処理について説明する。ＳＥＴＵＰメッセージ６０４（コンテンツ要求パケット）のＵＲＬにはカメラ４０１が要求されているコンテンツの種別を識別するための種別情報（ｍ＿ｊｐｅｇ＿ｓｘｇａ．ａｖｉ）が含まれている。ＳＥＴＵＰメッセージ６０４を受信したカメラ４０１は、ＵＲＬに含まれている種別情報を参照することで、要求されているコンテンツの種別が、Ｍｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）１０ｆｐｓであることを識別できる。そして、カメラ４０１は、要求コンテンツ負荷値を決定し、現在の総負荷値と合計することで、仮総負荷値を決定（算出）する。
【００６２】
テレビＣ６０１が要求するＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）は、すでにテレビＡ４０３及びテレビＢ４０４に送信しているので、初期負荷値は加算されない。従って、仮総負荷値は、現在の総負荷値である５１４０に、テレビＣが要求するフレームレート１０ｆｐｓに応じた負荷係数２４０を加算した５３８０となる。仮総負荷値が許容負荷値６０００を上回らないため、送信可否判定部１０９は、送信可能と判定する。カメラ４０１は、ＲＴＳＰのＲｅｓｐｏｎｓｅ  ｃｏｄｅ：２００“ＯＫ”（６０５）をテレビＣ６０１に送信し、要求されたコンテンツデータが送信可能であることを通知する。
【００６３】
コンテンツデータが送信可能であることを通知されたテレビＣ６０１は、ＲＴＳＰプロトコルによるＰＬＡＹメッセージ６０６によってコンテンツデータの送信開始をカメラ４０１に要求する。テレビＣ６０１に対するコンテンツデータの送信が確定するか開始された時点で、カメラ４０１は、総負荷値を仮総負荷値で更新し、コンテンツデータの種別ごとに接続数を管理するためのカウンタを“１”加算する。更新後の総負荷値は、メモリ１１５に記録される。また、コンテンツデータの送信が停止すると、総負荷値から当該停止したコンテンツデータの負荷係数が減算され、コンテンツデータの種別ごとに接続数を管理するためのカウンタも“１”減算される。カウンタが０になると、当該コンテンツデータの種別の送信先が０になったことを意味し、当該カウントが０になったコンテンツデータの種別に対応する初期負荷値が、総負荷値から減算される。減算後の総負荷値は、メモリ１１５に記録される。
【００６４】
また、上記の説明では、５台の受信装置１０２が存在する場合について説明したが、この数に限らない。別の例として、１台の受信装置１０２（第１の受信装置）に対してコンテンツデータを送信中に、別の１台の受信装置１０２（第２の受信装置）からコンテンツ要求パケットを受信した場合について説明する。
【００６５】
まず、第１の受信装置と第２の受信装置が要求するコンテンツデータの種別が一致する場合について説明する。例えば、第１の受信装置にＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）（第１のコンテンツデータ）の映像データをフレームレート３０ｆｐｓで送信中に、第２の受信装置から、第１のコンテンツデータ（フレームレート３０ｆｐｓ）の要求を受信したとする。このように、第１及び第２の受信装置のそれぞれが要求したコンテンツデータの種別が一致する場合、送信可否判定部１０９は、以下のように第２の受信装置に対する第１のコンテンツデータの送信可否を判定する。すなわち、第１のコンテンツデータの生成に関する負荷値と、第１のコンテンツデータの第１の受信装置への送信に関する負荷値と、第１のコンテンツデータの第２の受信装置への送信に関する負荷値との合計値と許容負荷値との比較に応じて、送信可否を判定する。
【００６６】
次に、第１の受信装置と第２の受信装置が要求するコンテンツデータの種別のうち、符号化方式と解像度が一致し、フレームレートが異なる場合について説明する。例えば、第１の受信装置にＭｏｔｉｏｎ−ＪＰＥＧ（ＳＸＧＡ）（第１のコンテンツデータ）をフレームレート３０ｆｐｓで送信中に、第２の受信装置から、第１のコンテンツデータ（フレームレート１０ｆｐｓ）の要求を受信したとする。この場合、送信可否判定部１０９は、以下のように第２の受信装置に対する第１のコンテンツデータの送信可否を判定する。即ち、送信可否判定部１０９は、第１のコンテンツデータの生成負荷に関する負荷値と、第１のコンテンツデータを３０ｆｐｓで送信する負荷値と、第１のコンテンツデータを１０ｆｐｓで送信する負荷値との合計値と、許容負荷値とに応じて、送信可否を判定する。
【００６７】
以上のように、本実施形態の送信装置１０１は、受信装置１０２から要求されたコンテンツデータの種別（符号化方式や映像の解像度、フレームレート、音声のサンプリングレート等）を考慮して処理負荷を定量化し、送信可否を判定するようにした。これにより、送信装置の負荷をより反映させた送信可否の判定ができるようになる。
【００６８】
なお、本実施形態では、コンテンツパケットの生成負荷に関する負荷値（初期負荷値）と、コンテンツパケットの送信処理に関する負荷値（負荷係数）とを合計して、閾値（許容負荷値）と比較する形態を説明したがこの形態に限らない。例えば、コンテンツパケットを生成するプロセッサと、コンテンツパケットの送信制御をするプロセッサが別のプロセッサである場合、初期負荷値に対する閾値と、負荷係数に対する閾値を別々に保持するようにしても良い。そして、初期負荷値と負荷係数のいずれか一方でも閾値を上回った場合、コンテンツデータの送信不可と判定するようにすることができる。
【００６９】
＜第２の実施形態＞
次に、実施形態２について、実施形態１との差異を中心に説明する。実施形態２では、コンテンツデータの発生符号量を計測することで、コンテンツデータの種別ごとの負荷係数を動的に決定する場合について説明する。
【００７０】
本実施形態では、Ｍｏｔｉｏｎ−ＪＰＥＧ及びＨ．２６５／ＡＶＣのエンコーダを持つカメラ４０１（送信装置１０１）において、Ｍｏｔｉｏｎ−ＪＰＥＧの負荷係数は静的に決定し、Ｈ．２６４／ＡＶＣの負荷係数は動的に決定する場合を例に説明する。
【００７１】
まず、本形態の送信装置１０１の送信可否判定部１０９は、Ｈ．２６４／ＡＶＣにより符号化されたコンテンツデータの符号量（データ量）を計測する。本形態の送信可否判定部１０９は、パケット生成部１０６により生成されたパケット数を、ＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）単位でカウントすることで、コンテンツデータの符号量（データ量）を計測する。なお、ＧＯＰ単位に限らず、他のグループ単位、或いは１秒間等の時間単位でカウントしてもよい。また、生成パケット数ではなく、データ符号化部１０５から出力される符号化データ量を計測することも可能である。
【００７２】
図７は、送信可否判定部１０９による符号量の計測結果の一例である。図７の横軸は時間（ＧＯＰ）、縦軸はＧＯＰごとのパケット数を示している。送信可否判定部１０９は、負荷係数を決定するタイミングであるＣｕｒｒｅｎｔ  ｔｉｍｅ（７０１）から所定期間だけ遡った計測期間Δｔ（７０２）における最大生成パケット数ｍａｘ（７０３）を用いて負荷係数を決定する。なお、負荷係数を決定するタイミングは、コンテンツ要求パケットの受信に応じたタイミングである。送信可否判定部１０９は、最大生成パケット数が多いほど、負荷係数が高くなるように、負荷係数を決定する。
【００７３】
なお、最大生成パケット数ではなく、平均パケット数を用いて負荷係数を決定してもよいし、計測期間を設けずに、送信装置１０１がコンテンツデータの送信を開始してからのパケット数を用いて負荷係数を決定してもよい。また、現在のＧＯＰ（Ｃｕｒｒｅｎｔ  ｔｉｍｅ  ７０１）におけるパケット数のみを用いて負荷係数を決定することも可能である。
【００７４】
送信可否判定部１０９は、計測により得られた最大生成パケット数ｍａｘ（７０３）に、所定のパケット係数を乗算して負荷係数を決定する。パケット係数は、コンテンツデータの種別に関わらず同じ値にしても良いし、種別によって異なる値にしても良い。例えば、動きの有無によって符号量が異なりやすい第１の符号化方式に対応するパケット係数が、動きの有無によって符号量が異なりにくい第２の符号化方式に対応するパケット係数よりも高くなるようにすることも可能である。
【００７５】
すなわち、本形態の送信可否判定部１０９は、図５に示す負荷係数（負荷値）を、計測されたコンテンツデータの符号量（データ量）に基づいて変更する。
【００７６】
また、負荷係数の動的な変更により、総負荷値が許容負荷値を超えてしまう場合がある。本形態の送信装置１０１は、負荷係数の変更により、総負荷値が許容負荷値を超えた場合、すでにコンテンツデータの送信先となっている複数の受信装置１０２のうち、最後に送信先となった受信装置１０２への送信を停止する。
【００７７】
ただし、この形態に限らず、例えば、送信中のコンテンツデータの解像度やフレームレートを落とすことで対応してもよいし、総負荷値が最大負荷値を超えることを許し、特別な対応をしなくてもよい。
【００７８】
以上のように本実施形態では、発生符号量の計測により、負荷係数を動的に決定するようにした。これにより、発生符号量の変動が大きい符号化方式を用いる場合であっても、送信装置の負荷をより反映させた送信可否の判定ができるようになる。
【００７９】
＜第３の実施形態＞
次に、実施形態３について、実施形態１及び２との差異を中心に説明する。実施形態３では、仮総負荷値が最大負荷値を超えた場合に、要求されたコンテンツデータの解像度やフレームレート等のデータ形態を変更することで、コンテンツデータを送信可能か判定する形態について説明する。
【００８０】
本実施形態の送信可否判定部１０９は、図２のＳ２０４において総負荷値に要求コンテンツ負荷値を加算した仮総負荷値が許容負荷値を上回った場合に、ただちに送信不可と判定せず、要求されたコンテンツのデータ形態を変更すれば送信できるかを判定する。そして、送信可否判定部１０９は、データ形態を変更すれば送信できると判定した場合は、変更後のデータ形態の情報を含む送信許可メッセージを受信装置１０２に送信する。
【００８１】
図８は、データ形態を変更することでコンテンツデータを送信できるか否かを判定する処理の一例を示すフローチャートである。なお、本形態の送信装置１０１は、符号化したコンテンツデータを受信装置１０２へ送信する送信装置である。また、本形態の送信装置１０１（カメラ４０１）のＣＰＵは、図８に係る処理を実行するためのプログラムをＲＡＭに読み出して実行する。ただし、図８の処理の少なくとも一部を、専用のハードウェア等で行うようにすることも可能である。
【００８２】
なお、図８の処理は、図２のＳ２０４以降の処理に対応している。すなわち、本形態の送信装置１０１は、Ｓ２０１〜Ｓ２０３までの処理は、実施形態１と同様に行う。
【００８３】
送信可否判定部１０９は、受信装置１０２からのコンテンツ要求パケットに含まれるコンテンツの種別情報から仮総負荷値を決定し、許容負荷値と比較する（Ｓ２０４）。
【００８４】
仮総負荷値が許容負荷値を上回らなければ、送信可と判定し、受信装置１０２に対して送信可能であることを示す判定結果パケットを送信する（Ｓ８０１）。
【００８５】
一方、仮総負荷値が許容負荷値を上回った場合、受信装置１０２から要求されたフレームレートと最低保障フレームレートを比較する（Ｓ８０２）。要求されたフレームレートが最低保障フレームレートを上回る場合は、フレームレートを下げ（Ｓ８０３）、仮総負荷値を再決定する（Ｓ８０４）。本形態の送信装置１０１は、Ｓ８０３において、フレームレートを最低保障フレームレートにまで下げることも可能であるが、一定量だけ下げる。このようにすることで、受信装置１０２からの要求に、より近いフレームレートでコンテンツデータを送信することができる。
【００８６】
Ｓ８０４で仮総負荷値を再決定した場合、Ｓ２０４に戻り、再決定した仮総負荷値と許容負荷値を比較する。Ｓ２０４で仮総負荷値が許容負荷値を上回らなければ、送信可の判定結果と共に、変更後のフレームレートを受信装置１０２に通知する。
【００８７】
Ｓ８０２でフレームレートが最低保障フレームレートであると判定された場合、要求されたコンテンツデータの符号化方式と同種の符号化方式で解像度が低いコンテンツデータが送信中であるか判定する（Ｓ８０５）。
【００８８】
Ｓ８０５で送信中であると判定された場合、当該解像度を下げた場合の負荷値を用いて仮総負荷値を再決定する（Ｓ８０４）。その後、Ｓ２０４に戻り、再決定された仮総負荷値が許容負荷値を上回らなければ、送信可否判定部１０９は、送信可の判定結果と共に、送信可能な映像データの解像度を受信装置１０２に通知する。
【００８９】
一方、Ｓ８０５で送信中でないと判定された場合、送信不可と判定し、受信装置１０２に対して送信不可であることを示す判定結果パケットを送信する（Ｓ８０６）。
【００９０】
このフローチャートはあくまでも一例に過ぎず、例えば、要求されたフレームレートを優先し、フレームレートの比較（Ｓ８０２）よりも先に、より低い解像度での仮総負荷値を再決定（Ｓ８０５）するようにしてもよい。
【００９１】
以上のように本実施形態の送信装置１０１は、受信装置１０２からの要求に応じた仮総負荷値が許容負荷値を上回る場合に、要求されたコンテンツの解像度やフレームレート等のデータ形態を変更して送信可能かを判定する。そして、送信可否判定部１０９は、送信可能であると判定されたコンテンツデータが存在することを、受信装置１０２に通知する。これにより、受信装置１０２からの要求に、より柔軟に対応できるようになる。
【００９２】
なお、上記の各実施形態において、コンテンツが映像データの場合、コンテンツの種別情報が、映像の符号化方式、解像度、フレームレートである場合の例を説明したが、この例に限らない。コンテンツの種別情報として、例えば、映像の圧縮率や画質の設定（高画質・低画質）などを用いることも可能である。
【００９３】
また、例えば、送信装置１０１において、物体検知（人物検知）、動き検知、置き去り検知、持ち去り検知、うろつき検知などのインテリジェント機能を実行させる場合、インテリジェント機能を実行させない場合よりも、送信装置１０１のＣＰＵの負荷がかかる。従って、送信装置１０１が実行するインテリジェント機能の種別に応じた所定の負荷値を、現在の総負荷値に加算して、図２のＳ２０４において許容負荷値と比較するようにすることも可能である。すなわち、送信可否判定部１０９は、送信装置１０１で実行しているインテリジェント機能に応じた負荷値を、受信装置１０２から要求されたコンテンツの種別情報に応じた負荷値に加算する。そして、送信可否判定部１０９は、インテリジェント機能に応じた負荷値が加算された負荷値と、閾値との比較により、当該要求されたコンテンツの送信可否を判定する。
【００９４】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013012833.tif 000003
【図２】
2013012833.tif 000004
【図３】
2013012833.tif 000005
【図４】
2013012833.tif 000006
【図５】
2013012833.tif 000007
【図６】
2013012833.tif 000008
【図７】
2013012833.tif 000009
【図８】
2013012833.tif 000010