JP2013012833A - 送信装置及び送信装置の制御方法 - Google Patents
送信装置及び送信装置の制御方法 Download PDFInfo
- Publication number
- JP2013012833A JP2013012833A JP2011142996A JP2011142996A JP2013012833A JP 2013012833 A JP2013012833 A JP 2013012833A JP 2011142996 A JP2011142996 A JP 2011142996A JP 2011142996 A JP2011142996 A JP 2011142996A JP 2013012833 A JP2013012833 A JP 2013012833A
- Authority
- JP
- Japan
- Prior art keywords
- content data
- transmission
- load value
- request
- receiving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 コンテンツデータを送信する送信装置の負荷にそぐわない送信可否の判定が行われてしまう恐れがあった。
【解決手段】 送信装置101の受信部108は、符号化方式の指定を含むコンテンツデータの要求を受信装置102から受信し(S201)、送信可否判定部109は、受信した要求に応じてコンテンツデータを送信するか否かを、指定された符号化方式に応じた負荷値を用いて判定し(S204)、送信部107は、送信可否判定部109による判定結果に応じて、コンテンツデータを符号化して送信する。
【選択図】 図2
【解決手段】 送信装置101の受信部108は、符号化方式の指定を含むコンテンツデータの要求を受信装置102から受信し(S201)、送信可否判定部109は、受信した要求に応じてコンテンツデータを送信するか否かを、指定された符号化方式に応じた負荷値を用いて判定し(S204)、送信部107は、送信可否判定部109による判定結果に応じて、コンテンツデータを符号化して送信する。
【選択図】 図2
Description
本発明は、データを送信する送信装置の制御方法に関する。
現在、インターネット等のIP(Internet Protocol)ネットワークを用いたメディア伝送が普及している。また、カメラ等で撮影した動画像や音声等のメディアデータをネットワーク経由でリアルタイムに伝送するプロトコルであるRTP(A Transport Protocol for Real−Time Applications)が利用されてきている。また、メディアデータを受信するデバイスやネットワーク形態も多岐にわたっており、様々な解像度の映像や異なる符号化形式のメディア伝送が求められている。
メディアデータのリアルタイム伝送においては、データ受信装置における再生時のメディアの品質維持のために、データ送信装置の処理負荷等を考慮して、接続数を制限する必要がある。従来の送信制御方法として、予め固定の最大接続数を設定しておく方法やCPU使用率等からデータ送信装置の現在の処理負荷を考慮して接続可否を判定する方法が知られている(特許文献1)。
メディアデータのリアルタイム伝送においては、データ受信装置における再生時のメディアの品質維持のために、データ送信装置の処理負荷等を考慮して、接続数を制限する必要がある。従来の送信制御方法として、予め固定の最大接続数を設定しておく方法やCPU使用率等からデータ送信装置の現在の処理負荷を考慮して接続可否を判定する方法が知られている(特許文献1)。
しかしながら、コンテンツデータを送信する送信装置の負荷にそぐわない送信可否の判定が行われてしまう恐れがあった。
すなわち、例えば、受信装置からの要求に応じたコンテンツデータを送信装置が送信できるにも関わらず、当該要求に応じたコンテンツデータを送信しないと判定されてしまう恐れがあった。
すなわち、例えば、受信装置からの要求に応じたコンテンツデータを送信装置が送信できるにも関わらず、当該要求に応じたコンテンツデータを送信しないと判定されてしまう恐れがあった。
また、例えば、受信装置からの要求に応じたコンテンツデータを送信すれば、バッファがオーバーフローしてしまうにも関わらず、当該要求に応じたコンテンツデータを送信すると判定されてしまう恐れがあった。
例えば、一般的に、Motion−JPEGとH.264/AVCのエンコーダは、同じ解像度・同じフレームレートであれば処理負荷は後者の方が大きく、発生符号量は前者の方が多い。また、同じ符号化方式でも解像度やフレームレートが異なれば処理負荷及び発生符号量は大きく異なる。従って、受信装置の最大接続数を閾値として送信可否の判定を行うと、当該閾値によっては、データを送信できるにも関わらず、送信しないと判定されてしまう場合や、データを送信できないにも関わらず、送信すると判定されてしまう場合があった。
本発明は上述した問題を解決するためになされたものであり、その目的は、送信装置の負荷に、より則した送信可否の判定方法を提供することである。
上記問題点を解決するために、本発明の送信装置は、例えば、以下の構成を有する。すなわち、符号化したコンテンツデータを送信する送信装置であって、符号化方式の指定を含む要求を受信装置から受信する受信手段と、前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に応じた負荷値を用いて判定する判定手段と、前記符号化したコンテンツデータを前記判定手段による判定に応じて送信する送信手段とを有する。
以上の構成からなる本発明によれば、送信装置の負荷に、より則した送信可否の判定ができるようになる。
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
<第1の実施形態>
本実施形態のコンテンツデータ送信システムの構成について、図1の機能ブロック図を参照して説明する。
本実施形態のコンテンツデータ送信システムの構成について、図1の機能ブロック図を参照して説明する。
図1において、送信装置101は、コンテンツデータ(コンテンツパケット)を送信する機能を備えている。送信装置101は、単一もしくは複数のコンピュータ装置で実現可能である。また、送信装置101は、例えば、通信機能を備えたカメラであってもよい。
受信装置102は、送信装置101が送信したコンテンツデータを受信する機能を備えている。受信装置102は、単一もしくは複数のコンピュータで実現可能である。また、受信装置102は、例えば、通信機能を備えたストレージ装置やテレビであってもよい。なお、図1では、送信装置101及び受信装置102がそれぞれ1台ずつ接続されているが、複数台接続させることが可能である。
送信装置101と受信装置102は、互いに通信可能なようにネットワーク103を介して接続されている。
送信装置101は、データ入力部104、データ符号化部105、パケット生成部106、送信部107、受信部108、送信可否判定部109、メモリ115を含んで構成されている。
受信装置102は、要求情報生成部110、送信部111、受信部112、データ復号化部113、データ再生部114を含んで構成されている。
まず、送信装置101の処理の流れを説明する。データ入力部104は、コンテンツデータを入力する。本形態では、コンテンツデータが映像データ(映像コンテンツデータ)である場合の例を中心に説明するが、例えば、音声データやテキストデータなど、他の種類であっても良い。データ入力部104は、例えば、ビデオカメラ、ネットワークカメラ等の映像センサや、ストレージメディアなどから映像データを入力する。データ入力部104は、映像データをデータ符号化部105に入力する。
データ符号化部105は、データ入力部104からのコンテンツデータを符号化方式に従い符号化する。ここで符号化方式とは、例えば、H.264/AVCやMotion−JPEGである。また、コンテンツデータが音声データであれば、例えば、G.711やG.726等が挙げられる。ただし、符号化方式は、上記の方式に限らない。データ符号化部105により符号化されたコンテンツデータはパケット生成部106に渡される。
パケット生成部106は、符号化されたコンテンツデータから通信に適したパケット(コンテンツパケット)を生成する。通信プロトコルとしてRTPを用いる場合、一般的には1500バイト程度のRTPパケットが生成される。生成されたコンテンツパケットは送信部107に渡される。送信部107は、生成されたコンテンツパケットをネットワーク103を介して受信装置102へ送信する。
受信部108は、受信装置102からネットワーク103を介してパケットを受信する。受信部108が受信するパケットには、コンテンツ要求パケットが含まれる。コンテンツ要求パケットには、受信装置102が要求するコンテンツの種別情報が含まれる。コンテンツの種別情報は、例えば、受信装置102が送信装置101に対して要求するコンテンツデータの符号化方式や映像の解像度、フレームレートなどである。なお、要求するコンテンツデータが音声データであれば、コンテンツの種別情報は、音声の符号化方式やサンプリングレート等の情報である。
なお、コンテンツの種別情報は、コンテンツの種別(例えば解像度)を明確に指定する情報(例えば、320x240、640x480)であっても、送信装置101がコンテンツの種別を判別できる識別子(例えば、大、中、小)であっても良い。また、コンテンツ要求パケットと、コンテンツの種別情報とが別々のパケットで送信されるようにしても良い。
送信可否判定部109は、受信部108が受信したコンテンツ要求パケットに含まれるコンテンツの種別情報から、当該コンテンツ要求パケットに対応するコンテンツデータの送信可否を判定する。判定方法の詳細については後述する。
送信可否判定部109による判定結果は、送信部107によって、判定結果パケットとして受信装置102に通知される。判定結果パケットの送信には、例えば、セッション制御プロトコルとしてのRTSP(Real Time Streaming Protocol)やSIPプロトコル(Session Initiation Protocol)等が用いられるが、それ以外のプロトコルを用いても良い。
次に、受信装置102の処理の流れを説明する。要求情報生成部110は、受信装置102のユーザ入力に基づいて、コンテンツ要求パケットを生成する。コンテンツ要求パケットには、送信装置101に要求するコンテンツ(映像データ)の符号化方式、解像度、フレームレートなどを特定するためのコンテンツ種別情報が含まれる。
送信部111は、要求情報生成部110が生成したコンテンツ要求パケットを送信装置101へ送信する。
受信部112は、送信装置101の送信可否判定部109による送信可否の判定結果を示す判定結果パケットや、コンテンツパケットを含む種々のパケットを受信する。
なお、送信部111は、送信可否判定部109により送信可能であることを示す判定結果パケットを受信部112が受信した場合、送信装置101に対して、コンテンツデータの伝送要求パケットを送信する。伝送要求パケットの送信プロトコルは先述したRTSPやSIPでもよいし、それ以外の方式でもよい。
データ復号化部113は、受信部112で受信したコンテンツパケットを復号化する。復号化したコンテンツデータはデータ再生部114に渡される。
データ再生部114は、復号化されたコンテンツデータを再生する。
データ再生部114は、復号化されたコンテンツデータを再生する。
次に、図2を用いて、送信可否判定部109における処理の流れを説明する。図2は、送信装置101の送信可否判定部109による処理の流れを説明するためのフローチャートである。なお、送信装置101は、符号化したコンテンツデータを受信装置102へ送信する送信装置である。また、本形態の送信装置101のCPUは、図2に係る処理を実行するためのプログラムをRAMに読み出して実行する。ただし、図2の処理の少なくとも一部を、専用のハードウェア等で行うようにすることも可能である。
送信可否判定部109は、受信部108が、受信装置102から、コンテンツ要求パケットを受信したと判定すると(S201でYES)、S202に進む。なお、コンテンツ要求パケットには、コンテンツの種別情報が含まれる。すなわち、受信部108は、S201(受信手順)において、符号化方式と、解像度と、フレームレートの指定を含む要求を受信装置102から受信する。ただし、符号化方式と、解像度と、フレームレートのすべてが必ずしも含まれていなくても良い。また、コンテンツ要求パケットとコンテンツの種別情報のパケットが、別々のパケットであっても良い。また、コンテンツの種別情報は、送信装置101がコンテンツの種別を決定できる情報であれば良い。また、送信装置101は、コンテンツの種別情報を含まないコンテンツ要求パケットを受信した場合、デフォルトの種別のコンテンツを提供するようにしても良い。
送信可否判定部109は、現在の総負荷値をメモリ115から取得する(S202)。
送信可否判定部109は、現在の総負荷値をメモリ115から取得する(S202)。
また、S201で取得したコンテンツ要求パケットに応じたコンテンツデータの生成処理と送信処理に係る負荷値(要求コンテンツ負荷値)を、当該コンテンツ要求パケットに含まれるコンテンツの種別情報から決定する(S203)。S202における現在の総負荷値、及び、S203における要求コンテンツ負荷値の決定方法の詳細は後述する。
そして、送信可否判定部109は、S202で取得した現在の総負荷値に、S203で決定した要求コンテンツ負荷値を加算した仮総負荷値と、許容負荷値(閾値)とを比較(S204)する。
そして、送信可否判定部109は、仮総負荷値が許容負荷値を上回っていない場合は送信可と判定し(S205)、仮総負荷値が許容負荷値を上回っている場合は送信不可と判定する(S206)。
すなわち、S204(判定手順)において、送信可否判定部109は、S201で受信した要求に応じてコンテンツデータを送信するか否かを、指定された符号化方式に応じた負荷値を用いて判定する。そして、S205(送信手順)において、送信部107は、データ符号化部105が符号化したコンテンツデータを、送信可否判定部109による判定に応じて受信装置102へ送信する。
S205において、送信可と判定された場合、送信可否判定部109は、仮総負荷値が、現在の総負荷値となるように、メモリ115内の総負荷値を置き換える。
次に、図3を用いて、S203における要求コンテンツ負荷値の決定処理の流れを説明する。
まず、送信可否判定部109は、当該決定処理の出力値としての要求コンテンツ負荷値(例えば、変数pとする)を0で初期化する(S301)。
そして、送信可否判定部109は、要求されているコンテンツの種別情報を取得する(S302)。コンテンツの種別情報とは、例えば、映像データの符号化方式や、解像度、フレームレートなどの情報である。
そして、送信可否判定部109は、コンテンツの種別情報に対応する種別のコンテンツパケットを、すでに送信中であるか否かを判定する(S303)。例えば、図2のS201で受信装置102からコンテンツ要求パケットを受信した時点において、すでに他の受信装置に対して種別が一致するコンテンツパケットを送信していた場合、S303でNOと判定される。
コンテンツの種別情報に対応する種別のコンテンツパケットを送信中でないとS303で判定された場合、送信可否判定部109は、要求コンテンツ負荷値pに当該コンテンツの種別情報に対応する初期負荷値を加算する(S304)。本形態において、初期負荷値とは、コンテンツパケットの生成処理(符号化処理やパケット生成処理)に関する負荷を示す値である。初期負荷値の詳細については後述する。
また、送信可否判定部109は、要求コンテンツ負荷値pに当該コンテンツの種別情報に対応する負荷係数を加算する(S305)。本形態において、負荷係数とは、コンテンツパケットの送信に関する負荷を示す値である。負荷係数の詳細については後述する。
そして、送信可否判定部109は、受信装置102から要求されたすべてのコンテンツ(例えば、映像データと音声データ)に関してS302〜S305の処理を実行したか否かを判定し(S306)、他のコンテンツの処理が残っている場合は、S302に戻る。
次に、送信装置101と受信装置102間の全体の制御の流れをより具体的な例を交えて説明する。
図4は、カメラ401がインターネット402を介して、テレビA403、テレビB404、携帯端末A405、携帯端末B406に対して、映像データをリアルタイムに伝送している様子を示している。なお、カメラ401は、図1の送信装置101に対応し、テレビA403、テレビB404、携帯端末A405、携帯端末B406は、それぞれ、図1の受信装置102に対応する。
カメラ401のデータ符号化部105は、複数のエンコーダを有し、図4では、Motion−JPEG(SXGA)407及びH.264/AVC(VGA)408のエンコーダがそれぞれ起動している。カメラ401は、撮像により得られた映像データ(コンテンツデータ)を、それぞれの符号化方式で符号化してコンテンツパケットを生成している。また、カメラ401の送信部107は、各受信装置102に対してマルチユニキャストでコンテンツパケットを送信している。
テレビA403はMotion−JPEG(SXGA)のフレームレート30fps(frame/second)の映像データ409を受信している。また、テレビB404は同じくMotion−JPEG(SXGA)のフレームレート10fpsの映像パケット410を受信している。
携帯端末A405はH.264/AVC(VGA)のフレームレート30fpsの映像データ411を受信しており、携帯端末B406も同じH.264/AVC(VGA)のフレームレート30fpsの映像データ412を受信している。
図5は、カメラ401におけるコンテンツの種別ごとの初期負荷値と負荷係数の例である。図5のテーブルは、カメラ401(送信装置101)のメモリ115に記録されている。なお、本実施形態では、音声データであるG.711のサンプリングレートは指定できないものとしている。そのため、図5には、映像データの符号化方式、解像度、フレームレートに応じた初期負荷値と負荷係数のみを載せているが、音声データの種別に応じた初期負荷値や負荷係数を載せるようにすることも可能である。
また、図5の「映像データの種別」の欄には、映像データの符号化方式(Motion−JPEGとH.264/AVC)と、解像度(QVGAとVGAとSXGA)の組み合わせが記載されている。なお、図5にも示すように、QVGAは320x240画素、VGAは640x240画素、SXGAは1280x960画素を示している。また、図5に示すように、解像度が同じであれば、H.264/AVCのほうが、Motion−JPEGよりも、コンテンツパケットを生成するための負荷は大きい。また、解像度が同じであれば、Motion−JPEGのほうが、H.264/AVCよりも、1フレーム当たりのコンテンツパケットを送信するための負荷は大きい。
図5に示す初期負荷値は、フレームレートが30fpsの場合のコンテンツパケットの生成に関する負荷値に対応している。従って、受信装置102から要求されるフレームレートが、30fpsよりも低い場合は、図5に記載された初期負荷値よりも低い初期負荷値を設定することが可能である。一方、受信装置102から要求されるフレームレートが、30fpsよりも高い場合は、図5に記載された初期負荷値よりも高い初期負荷値を設定することが可能である。
図5の表に従って図4のカメラ401の総負荷値を計算する。
まず、カメラ401は、テレビA403に対してMotion−JPEG(SXGA)の映像データをフレームレート30fpsで送信している。従って、テレビA403へのコンテンツデータの符号化及びパケット化にかかる初期負荷値2400と、テレビA403へのコンテンツパケットの送信負荷に関する負荷係数240x3=720が加算される。
また、カメラ401は、テレビB404に対して、テレビA403と同様のMotion−JPEG(SXGA)の映像データをフレームレート10fpsで送信している。テレビB404へ送信される映像データの種別と、テレビA403へ送信される映像データの種別は一致しているため、テレビB404に対応する初期負荷値は加算されず、10fpsの送信負荷に対応する負荷係数240が加算される。
また、カメラ401は、携帯端末A405に対して、H.264/AVC(VGA)の映像データをフレームレート30fpsで送信している。従って、携帯端末A405へのコンテンツデータの符号化及びパケット化にかかる初期負荷値1600と、携帯端末A405へのコンテンツパケットの送信負荷に関する負荷係数30x3=90とが加算される。
さらに、カメラ401は、携帯端末B406に対して、携帯端末A405と同様のH.264/AVC(VGA)の映像データをフレームレート30fpsで送信している。携帯端末A405へ送信される映像データの種別と、携帯端末B406へ送信される映像データの種別は一致しているため、携帯端末B406に対応する初期負荷値は加算されず、30fpsの送信負荷に対応する負荷係数90が加算される。
従って、カメラ401の現在の総負荷値は、これらを全て合計した5140となる。なお、本形態では、符号化方式と解像度が同じで、フレームレートが異なるコンテンツデータを送信する場合、フレーム間引き処理を行うようにしている。しかし、フレームレートが異なる要求ごとに、別々に符号化及びパケット化をしても良い。その場合は、それぞれに初期負荷値を加算する必要がある。
また、本実施形態におけるカメラ401の許容負荷値を6000とする。この場合において、受信装置102から新しいコンテンツ要求パケットを受信したときの処理の例を図6に示す。
図6は、図4の状態から、新たな受信装置102に対応するテレビC601がMotion−JPEG(VGA)10fpsをRTSPプロトコルにより要求する場合を示している。まず、テレビC601は、RTSPのSETUPメッセージ(コンテンツ要求パケット)602を用いてカメラ401(送信装置101)に対してリソースの確保を要求する。SETUPメッセージ602(コンテンツ要求パケット)内のURLには、カメラ401が要求されているコンテンツの種別を識別するための種別情報(m_jpeg_vga.avi)が含まれている。SETUPメッセージ602を受信したカメラ401は、URLに含まれている種別情報を参照することで、要求されているコンテンツの種別が、Motion−JPEG(VGA)10fpsであることを識別し、要求コンテンツ負荷値を決定する。要求コンテンツ負荷値の決定は、図2のS203に対応する。そして、カメラ401の送信可否判定部109は、要求コンテンツ負荷値と、テレビA、B、及び、携帯端末A、Bへ送信しているコンテンツに関する負荷値とを合計することで、仮総負荷値を算出する。
カメラ401は、テレビC601からコンテンツ要求パケットを受信した時点において、Motion−JPEG(VGA)のコンテンツパケットを送信していないので、初期負荷値1000と負荷係数60とが現在の総負荷値5140に加算される。従って、仮総負荷値は、6200となる。カメラ401の許容負荷値は6000であるため、送信可否判定部109は、テレビC601により要求されたコンテンツパケットは送信不可であると判定する。カメラ401の送信可否判定部109は、RTSPのResponse code:406“Not Acceptable”(603)(判定結果パケット)をテレビC601に送信し、コンテンツパケットの送信不可を通知する。判定可否パケットの送信には、RTSP Response codeを用いても良いし、RTSPを用いなくてもよい。また、本実施形態のカメラ401は、RTSPのSETUPメッセージの受信時に送信可否を判定しているが、この形態に限らない。例えば、受信装置102から要求されるコンテンツデータの種別を送信装置101が認識していれば、DESCRIBEメッセージやPLAYメッセージの段階で判定することも可能である。
続いて、テレビC601がMotion−JPEG(SXGA)10fpsを、同じくRTSPプロトコルによるSETUPメッセージ604にて要求した場合の送信可否判定処理について説明する。SETUPメッセージ604(コンテンツ要求パケット)のURLにはカメラ401が要求されているコンテンツの種別を識別するための種別情報(m_jpeg_sxga.avi)が含まれている。SETUPメッセージ604を受信したカメラ401は、URLに含まれている種別情報を参照することで、要求されているコンテンツの種別が、Motion−JPEG(SXGA)10fpsであることを識別できる。そして、カメラ401は、要求コンテンツ負荷値を決定し、現在の総負荷値と合計することで、仮総負荷値を決定(算出)する。
テレビC601が要求するMotion−JPEG(SXGA)は、すでにテレビA403及びテレビB404に送信しているので、初期負荷値は加算されない。従って、仮総負荷値は、現在の総負荷値である5140に、テレビCが要求するフレームレート10fpsに応じた負荷係数240を加算した5380となる。仮総負荷値が許容負荷値6000を上回らないため、送信可否判定部109は、送信可能と判定する。カメラ401は、RTSPのResponse code:200“OK”(605)をテレビC601に送信し、要求されたコンテンツデータが送信可能であることを通知する。
コンテンツデータが送信可能であることを通知されたテレビC601は、RTSPプロトコルによるPLAYメッセージ606によってコンテンツデータの送信開始をカメラ401に要求する。テレビC601に対するコンテンツデータの送信が確定するか開始された時点で、カメラ401は、総負荷値を仮総負荷値で更新し、コンテンツデータの種別ごとに接続数を管理するためのカウンタを“1”加算する。更新後の総負荷値は、メモリ115に記録される。また、コンテンツデータの送信が停止すると、総負荷値から当該停止したコンテンツデータの負荷係数が減算され、コンテンツデータの種別ごとに接続数を管理するためのカウンタも“1”減算される。カウンタが0になると、当該コンテンツデータの種別の送信先が0になったことを意味し、当該カウントが0になったコンテンツデータの種別に対応する初期負荷値が、総負荷値から減算される。減算後の総負荷値は、メモリ115に記録される。
また、上記の説明では、5台の受信装置102が存在する場合について説明したが、この数に限らない。別の例として、1台の受信装置102(第1の受信装置)に対してコンテンツデータを送信中に、別の1台の受信装置102(第2の受信装置)からコンテンツ要求パケットを受信した場合について説明する。
まず、第1の受信装置と第2の受信装置が要求するコンテンツデータの種別が一致する場合について説明する。例えば、第1の受信装置にMotion−JPEG(SXGA)(第1のコンテンツデータ)の映像データをフレームレート30fpsで送信中に、第2の受信装置から、第1のコンテンツデータ(フレームレート30fps)の要求を受信したとする。このように、第1及び第2の受信装置のそれぞれが要求したコンテンツデータの種別が一致する場合、送信可否判定部109は、以下のように第2の受信装置に対する第1のコンテンツデータの送信可否を判定する。すなわち、第1のコンテンツデータの生成に関する負荷値と、第1のコンテンツデータの第1の受信装置への送信に関する負荷値と、第1のコンテンツデータの第2の受信装置への送信に関する負荷値との合計値と許容負荷値との比較に応じて、送信可否を判定する。
次に、第1の受信装置と第2の受信装置が要求するコンテンツデータの種別のうち、符号化方式と解像度が一致し、フレームレートが異なる場合について説明する。例えば、第1の受信装置にMotion−JPEG(SXGA)(第1のコンテンツデータ)をフレームレート30fpsで送信中に、第2の受信装置から、第1のコンテンツデータ(フレームレート10fps)の要求を受信したとする。この場合、送信可否判定部109は、以下のように第2の受信装置に対する第1のコンテンツデータの送信可否を判定する。即ち、送信可否判定部109は、第1のコンテンツデータの生成負荷に関する負荷値と、第1のコンテンツデータを30fpsで送信する負荷値と、第1のコンテンツデータを10fpsで送信する負荷値との合計値と、許容負荷値とに応じて、送信可否を判定する。
以上のように、本実施形態の送信装置101は、受信装置102から要求されたコンテンツデータの種別(符号化方式や映像の解像度、フレームレート、音声のサンプリングレート等)を考慮して処理負荷を定量化し、送信可否を判定するようにした。これにより、送信装置の負荷をより反映させた送信可否の判定ができるようになる。
なお、本実施形態では、コンテンツパケットの生成負荷に関する負荷値(初期負荷値)と、コンテンツパケットの送信処理に関する負荷値(負荷係数)とを合計して、閾値(許容負荷値)と比較する形態を説明したがこの形態に限らない。例えば、コンテンツパケットを生成するプロセッサと、コンテンツパケットの送信制御をするプロセッサが別のプロセッサである場合、初期負荷値に対する閾値と、負荷係数に対する閾値を別々に保持するようにしても良い。そして、初期負荷値と負荷係数のいずれか一方でも閾値を上回った場合、コンテンツデータの送信不可と判定するようにすることができる。
<第2の実施形態>
次に、実施形態2について、実施形態1との差異を中心に説明する。実施形態2では、コンテンツデータの発生符号量を計測することで、コンテンツデータの種別ごとの負荷係数を動的に決定する場合について説明する。
次に、実施形態2について、実施形態1との差異を中心に説明する。実施形態2では、コンテンツデータの発生符号量を計測することで、コンテンツデータの種別ごとの負荷係数を動的に決定する場合について説明する。
本実施形態では、Motion−JPEG及びH.265/AVCのエンコーダを持つカメラ401(送信装置101)において、Motion−JPEGの負荷係数は静的に決定し、H.264/AVCの負荷係数は動的に決定する場合を例に説明する。
まず、本形態の送信装置101の送信可否判定部109は、H.264/AVCにより符号化されたコンテンツデータの符号量(データ量)を計測する。本形態の送信可否判定部109は、パケット生成部106により生成されたパケット数を、GOP(Group of Pictures)単位でカウントすることで、コンテンツデータの符号量(データ量)を計測する。なお、GOP単位に限らず、他のグループ単位、或いは1秒間等の時間単位でカウントしてもよい。また、生成パケット数ではなく、データ符号化部105から出力される符号化データ量を計測することも可能である。
図7は、送信可否判定部109による符号量の計測結果の一例である。図7の横軸は時間(GOP)、縦軸はGOPごとのパケット数を示している。送信可否判定部109は、負荷係数を決定するタイミングであるCurrent time(701)から所定期間だけ遡った計測期間Δt(702)における最大生成パケット数max(703)を用いて負荷係数を決定する。なお、負荷係数を決定するタイミングは、コンテンツ要求パケットの受信に応じたタイミングである。送信可否判定部109は、最大生成パケット数が多いほど、負荷係数が高くなるように、負荷係数を決定する。
なお、最大生成パケット数ではなく、平均パケット数を用いて負荷係数を決定してもよいし、計測期間を設けずに、送信装置101がコンテンツデータの送信を開始してからのパケット数を用いて負荷係数を決定してもよい。また、現在のGOP(Current time 701)におけるパケット数のみを用いて負荷係数を決定することも可能である。
送信可否判定部109は、計測により得られた最大生成パケット数max(703)に、所定のパケット係数を乗算して負荷係数を決定する。パケット係数は、コンテンツデータの種別に関わらず同じ値にしても良いし、種別によって異なる値にしても良い。例えば、動きの有無によって符号量が異なりやすい第1の符号化方式に対応するパケット係数が、動きの有無によって符号量が異なりにくい第2の符号化方式に対応するパケット係数よりも高くなるようにすることも可能である。
すなわち、本形態の送信可否判定部109は、図5に示す負荷係数(負荷値)を、計測されたコンテンツデータの符号量(データ量)に基づいて変更する。
また、負荷係数の動的な変更により、総負荷値が許容負荷値を超えてしまう場合がある。本形態の送信装置101は、負荷係数の変更により、総負荷値が許容負荷値を超えた場合、すでにコンテンツデータの送信先となっている複数の受信装置102のうち、最後に送信先となった受信装置102への送信を停止する。
ただし、この形態に限らず、例えば、送信中のコンテンツデータの解像度やフレームレートを落とすことで対応してもよいし、総負荷値が最大負荷値を超えることを許し、特別な対応をしなくてもよい。
以上のように本実施形態では、発生符号量の計測により、負荷係数を動的に決定するようにした。これにより、発生符号量の変動が大きい符号化方式を用いる場合であっても、送信装置の負荷をより反映させた送信可否の判定ができるようになる。
<第3の実施形態>
次に、実施形態3について、実施形態1及び2との差異を中心に説明する。実施形態3では、仮総負荷値が最大負荷値を超えた場合に、要求されたコンテンツデータの解像度やフレームレート等のデータ形態を変更することで、コンテンツデータを送信可能か判定する形態について説明する。
次に、実施形態3について、実施形態1及び2との差異を中心に説明する。実施形態3では、仮総負荷値が最大負荷値を超えた場合に、要求されたコンテンツデータの解像度やフレームレート等のデータ形態を変更することで、コンテンツデータを送信可能か判定する形態について説明する。
本実施形態の送信可否判定部109は、図2のS204において総負荷値に要求コンテンツ負荷値を加算した仮総負荷値が許容負荷値を上回った場合に、ただちに送信不可と判定せず、要求されたコンテンツのデータ形態を変更すれば送信できるかを判定する。そして、送信可否判定部109は、データ形態を変更すれば送信できると判定した場合は、変更後のデータ形態の情報を含む送信許可メッセージを受信装置102に送信する。
図8は、データ形態を変更することでコンテンツデータを送信できるか否かを判定する処理の一例を示すフローチャートである。なお、本形態の送信装置101は、符号化したコンテンツデータを受信装置102へ送信する送信装置である。また、本形態の送信装置101(カメラ401)のCPUは、図8に係る処理を実行するためのプログラムをRAMに読み出して実行する。ただし、図8の処理の少なくとも一部を、専用のハードウェア等で行うようにすることも可能である。
なお、図8の処理は、図2のS204以降の処理に対応している。すなわち、本形態の送信装置101は、S201〜S203までの処理は、実施形態1と同様に行う。
送信可否判定部109は、受信装置102からのコンテンツ要求パケットに含まれるコンテンツの種別情報から仮総負荷値を決定し、許容負荷値と比較する(S204)。
仮総負荷値が許容負荷値を上回らなければ、送信可と判定し、受信装置102に対して送信可能であることを示す判定結果パケットを送信する(S801)。
一方、仮総負荷値が許容負荷値を上回った場合、受信装置102から要求されたフレームレートと最低保障フレームレートを比較する(S802)。要求されたフレームレートが最低保障フレームレートを上回る場合は、フレームレートを下げ(S803)、仮総負荷値を再決定する(S804)。本形態の送信装置101は、S803において、フレームレートを最低保障フレームレートにまで下げることも可能であるが、一定量だけ下げる。このようにすることで、受信装置102からの要求に、より近いフレームレートでコンテンツデータを送信することができる。
S804で仮総負荷値を再決定した場合、S204に戻り、再決定した仮総負荷値と許容負荷値を比較する。S204で仮総負荷値が許容負荷値を上回らなければ、送信可の判定結果と共に、変更後のフレームレートを受信装置102に通知する。
S802でフレームレートが最低保障フレームレートであると判定された場合、要求されたコンテンツデータの符号化方式と同種の符号化方式で解像度が低いコンテンツデータが送信中であるか判定する(S805)。
S805で送信中であると判定された場合、当該解像度を下げた場合の負荷値を用いて仮総負荷値を再決定する(S804)。その後、S204に戻り、再決定された仮総負荷値が許容負荷値を上回らなければ、送信可否判定部109は、送信可の判定結果と共に、送信可能な映像データの解像度を受信装置102に通知する。
一方、S805で送信中でないと判定された場合、送信不可と判定し、受信装置102に対して送信不可であることを示す判定結果パケットを送信する(S806)。
このフローチャートはあくまでも一例に過ぎず、例えば、要求されたフレームレートを優先し、フレームレートの比較(S802)よりも先に、より低い解像度での仮総負荷値を再決定(S805)するようにしてもよい。
以上のように本実施形態の送信装置101は、受信装置102からの要求に応じた仮総負荷値が許容負荷値を上回る場合に、要求されたコンテンツの解像度やフレームレート等のデータ形態を変更して送信可能かを判定する。そして、送信可否判定部109は、送信可能であると判定されたコンテンツデータが存在することを、受信装置102に通知する。これにより、受信装置102からの要求に、より柔軟に対応できるようになる。
なお、上記の各実施形態において、コンテンツが映像データの場合、コンテンツの種別情報が、映像の符号化方式、解像度、フレームレートである場合の例を説明したが、この例に限らない。コンテンツの種別情報として、例えば、映像の圧縮率や画質の設定(高画質・低画質)などを用いることも可能である。
また、例えば、送信装置101において、物体検知(人物検知)、動き検知、置き去り検知、持ち去り検知、うろつき検知などのインテリジェント機能を実行させる場合、インテリジェント機能を実行させない場合よりも、送信装置101のCPUの負荷がかかる。従って、送信装置101が実行するインテリジェント機能の種別に応じた所定の負荷値を、現在の総負荷値に加算して、図2のS204において許容負荷値と比較するようにすることも可能である。すなわち、送信可否判定部109は、送信装置101で実行しているインテリジェント機能に応じた負荷値を、受信装置102から要求されたコンテンツの種別情報に応じた負荷値に加算する。そして、送信可否判定部109は、インテリジェント機能に応じた負荷値が加算された負荷値と、閾値との比較により、当該要求されたコンテンツの送信可否を判定する。
<その他の実施形態>
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
Claims (11)
- 符号化したコンテンツデータを送信する送信装置であって、
符号化方式の指定を含む要求を受信装置から受信する受信手段と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に応じた負荷値を用いて判定する判定手段と、
前記符号化したコンテンツデータを前記判定手段による判定に応じて送信する送信手段とを有することを特徴とする送信装置。 - 前記判定手段は、第1の受信装置から受信した第1の要求に応じて第1のコンテンツデータを送信している場合において、第2の受信装置から前記第1のコンテンツデータとは符号化方式が異なる第2の要求を受信すると、前記第1のコンテンツデータの符号化方式に応じた第1の負荷値と、前記第2の要求の符号化方式に応じた第2の負荷値との合計値と閾値との比較に基づいて前記第2の要求に応じたコンテンツデータを送信するか否かを判定することを特徴とする請求項1に記載の送信装置。
- 前記受信手段は、映像の符号化方式と解像度の指定を含む要求を前記受信装置から受信し、
前記判定手段は、前記受信した要求に応じて映像コンテンツデータを送信するか否かを、前記指定された符号化方式と解像度に応じた負荷値と、閾値との比較に基づいて判定することを特徴とする請求項1又は2に記載の送信装置。 - 前記受信手段は、映像の符号化方式とフレームレートの指定を含む要求を前記受信装置から受信し、
前記判定手段は、前記受信した要求に応じて映像コンテンツデータを送信するか否かを、前記指定された符号化方式とフレームレートに応じた負荷値と、閾値との比較に基づいて判定することを特徴とする請求項1又は2に記載の送信装置。 - 前記判定手段は、第1の受信装置から受信した第1の要求に応じて第1のコンテンツデータを送信している場合において、第2の受信装置から前記第1の要求と指定内容が一致する第2の要求を受信すると、前記第1のコンテンツデータの生成に関する負荷値と、前記第1のコンテンツデータの前記第1の受信装置への送信に関する負荷値と、前記第1のコンテンツデータの前記第2の受信装置への送信に関する負荷値との合計値に応じて、前記第2の受信装置に対して、前記第2の要求に応じたコンテンツデータを送信すると判定することを特徴とする請求項1乃至4のうち、いずれか1項に記載の送信装置。
- 前記判定手段は、第1の受信装置から受信した第1の要求に応じて第1の映像コンテンツデータを送信している場合において、前記第1の要求に対応する映像コンテンツデータの符号化方式と一致し、フレームレートが前記第1の要求よりも低い第2の要求を第2の受信装置から受信すると、前記第1の映像コンテンツデータの生成に関する負荷値と、前記第1の要求に応じたフレームレートでの前記第1のコンテンツデータの前記第1の受信装置への送信に関する負荷値と、前記第2の要求に応じたフレームレートでの前記第2のコンテンツデータの前記第2の受信装置への送信に関する負荷値との合計値に応じて、前記第2の受信装置に対して、前記第2の要求に応じた映像コンテンツデータを送信すると判定することを特徴とする請求項1乃至4のうちいずれか1項に記載の送信装置。
- 複数の符号化方式のそれぞれに対応する負荷値を記憶する記憶手段を有し、
前記判定手段は、前記記憶手段から前記指定された符号化方式に応じた負荷値を取得することを特徴とする請求項1乃至6のうち、いずれか1項に記載の送信装置。 - 前記符号化したコンテンツデータのデータ量を計測する計測手段を有し、
前記記憶手段に記憶された負荷値を、前記計測手段により計測されたコンテンツデータのデータ量に基づいて変更する変更手段を有することを特徴とする請求項7に記載の送信装置。 - 前記判定手段は、前記受信した要求に応じたコンテンツデータを送信しないと前記負荷値に基づいて判定した場合、前記受信した要求に含まれる指定内容とは異なるコンテンツデータを送信可能であるかを判定し、
前記送信手段は、前記判定手段により送信可能であると判定されたコンテンツデータが存在することを、前記要求を送信した受信装置に通知することを特徴とする請求項1乃至8のうち、いずれか1項に記載の送信装置。 - 符号化したコンテンツデータを送信する送信装置が行う送信制御方法であって、
符号化方式の指定を含む要求を受信装置から受信する受信工程と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に対応する負荷値を用いて判定する判定工程と、
前記符号化したコンテンツデータを前記判定工程による判定に応じて送信する送信工程とを有することを特徴とする送信制御方法。 - 符号化したコンテンツデータを送信するコンピュータに、
符号化方式の指定を含む要求を受信装置から受信する受信手順と、
前記受信した要求に応じてコンテンツデータを送信するか否かを、前記指定された符号化方式に対応する負荷値を用いて判定する判定手順と、
前記符号化したコンテンツデータを前記判定手順による判定に応じて送信する送信手順とを実行させることを特徴とするプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011142996A JP2013012833A (ja) | 2011-06-28 | 2011-06-28 | 送信装置及び送信装置の制御方法 |
US13/531,926 US20130007206A1 (en) | 2011-06-28 | 2012-06-25 | Transmission apparatus, control method for transmission apparatus, and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011142996A JP2013012833A (ja) | 2011-06-28 | 2011-06-28 | 送信装置及び送信装置の制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2013012833A true JP2013012833A (ja) | 2013-01-17 |
Family
ID=47391775
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011142996A Withdrawn JP2013012833A (ja) | 2011-06-28 | 2011-06-28 | 送信装置及び送信装置の制御方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20130007206A1 (ja) |
JP (1) | JP2013012833A (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10048895B2 (en) | 2013-12-06 | 2018-08-14 | Concurrent Ventures, LLC | System and method for dynamically load balancing storage media devices based on a mid-range performance level |
US8954617B1 (en) * | 2013-12-06 | 2015-02-10 | Concurrent Ventures, LLC | System, method and article of manufacture for monitoring, controlling and improving storage media system performance based on data type |
US9274722B2 (en) | 2013-12-06 | 2016-03-01 | Concurrent Ventures, LLP | System, method and article of manufacture for monitoring, controlling and improving storage media system performance |
US9436404B2 (en) | 2013-12-06 | 2016-09-06 | Concurrent Ventures, LLC | System and method for dynamically load balancing across storage media devices having fast access rates |
US10235096B2 (en) | 2013-12-06 | 2019-03-19 | Concurrent Ventures, LLC | System and method for dynamically load balancing storage media devices based on an average or discounted average sustained performance level |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020138643A1 (en) * | 2000-10-19 | 2002-09-26 | Shin Kang G. | Method and system for controlling network traffic to a network computer |
US20030198199A1 (en) * | 2002-04-17 | 2003-10-23 | Budka Kenneth C. | Method of throttling uplink traffic in a wireless communication system |
US7633969B2 (en) * | 2004-09-10 | 2009-12-15 | Tekelec | Methods, systems, and computer program products for dynamically adjusting load sharing distributions in response to changes in network conditions |
US8214869B2 (en) * | 2005-12-29 | 2012-07-03 | Rovi Guides, Inc. | Systems and methods for managing a status change of a multimedia asset in multimedia delivery systems |
US20070183330A1 (en) * | 2006-02-08 | 2007-08-09 | Metin Salt | Methods, systems, and apparatus for reducing real time data traffic in a multi-layer network |
US8107366B2 (en) * | 2006-08-22 | 2012-01-31 | Embarq Holdings Company, LP | System and method for using centralized network performance tables to manage network communications |
US8516121B1 (en) * | 2008-06-30 | 2013-08-20 | Symantec Corporation | Method and apparatus for optimizing computer network usage to prevent congestion |
US7860100B2 (en) * | 2008-10-01 | 2010-12-28 | Cisco Technology, Inc. | Service path selection in a service network |
US10102301B2 (en) * | 2010-04-01 | 2018-10-16 | Cloudflare, Inc. | Internet-based proxy security services |
US8429282B1 (en) * | 2011-03-22 | 2013-04-23 | Amazon Technologies, Inc. | System and method for avoiding system overload by maintaining an ideal request rate |
US9094262B2 (en) * | 2011-12-30 | 2015-07-28 | Certona Corporation | Fault tolerance and maintaining service response under unanticipated load conditions |
US9013995B2 (en) * | 2012-05-04 | 2015-04-21 | Telefonaktiebolaget L M Ericsson (Publ) | Congestion control in packet data networking |
-
2011
- 2011-06-28 JP JP2011142996A patent/JP2013012833A/ja not_active Withdrawn
-
2012
- 2012-06-25 US US13/531,926 patent/US20130007206A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20130007206A1 (en) | 2013-01-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11412021B2 (en) | Method and device for media streaming between server and client using RTP/RTSP standard protocol | |
US9247276B2 (en) | System and method for progressive delivery of media content | |
KR102077556B1 (ko) | 가상 인트라-프레임을 사용하여 비디오 콘텐츠를 인코딩하기 위한 시스템 및 방법 | |
JP5257367B2 (ja) | 映像配信装置、映像配信システム及び映像配信方法 | |
US20220150514A1 (en) | Dynamic decoder configuration for live transcoding | |
JPWO2011004886A1 (ja) | 配信システムと方法とゲートウェイ装置とプログラム | |
US10785511B1 (en) | Catch-up pacing for video streaming | |
EP3059945A1 (en) | Method and system for video surveillance content adaptation, and central server and device | |
CN108881931B (zh) | 一种数据缓冲方法及网络设备 | |
US20070127437A1 (en) | Medium signal transmission method, reception method, transmission/reception method, and device | |
JP2013012833A (ja) | 送信装置及び送信装置の制御方法 | |
US20160212054A1 (en) | Multiple Protocol Media Streaming | |
US20140226711A1 (en) | System and method for self-adaptive streaming of multimedia content | |
KR102064284B1 (ko) | 실시간 통신을 수행하는 장치, 시스템, 및 방법 | |
US8456532B1 (en) | Internet protocol camera transcode avoidance | |
US20200329388A1 (en) | Miracast Framework Enhancements For Direct Streaming Mode | |
JP5151763B2 (ja) | 映像配信システム、映像配信装置、映像受信装置、映像配信方法、映像受信方法及びプログラム | |
JP6193569B2 (ja) | 受信装置、受信方法、及びプログラム、撮像装置、撮像方法、及びプログラム、送信装置、送信方法、及びプログラム | |
US9049350B2 (en) | Imaging apparatus that transmits media data to reception apparatus, method of processing information, and storage medium | |
JP2012137900A (ja) | 映像出力システム、映像出力方法及びサーバ装置 | |
KR101819193B1 (ko) | 실시간 파일 포맷 변환 스트리밍 서비스 방법 | |
JP2006295601A (ja) | 通信システム、送信装置および方法、受信装置および方法、並びにプログラム | |
JP2007324722A (ja) | 動画像データ配信装置及び動画像データ通信システム | |
US11758241B2 (en) | Method and apparatus for playing back video in accordance with requested video playback time | |
KR102050416B1 (ko) | 네트워크 카메라 장치 및 이의 영상 스트리밍 제공 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20140902 |