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

Abstract

【課題】 複数の異なるフレームレートで動画データを送信している場合のフレームレートの変更方法によっては、フレームレートが低くなりすぎてしまう恐れがあった。
【解決手段】 送信装置１００の負荷取得部１０５は、送信装置１００の負荷を取得し（Ｓ２０１）、フレームレート制御部１０３は、第１のフレームレートと、第１のフレームレートよりも低い第２のフレームレートとで動画データを送信中に、第１及び第２のフレームレートを下げる場合、第１のフレームレートと第１のフレームレートを下げた後の第１の変更フレームレートとの差が、第２のフレームレートと第２のフレームレートを下げた後の第２の変更フレームレートとの差よりも大きくなるように、負荷状態に応じて第１及び第２のフレームレートを下げる（Ｓ２０６）。
【選択図】 図１

Description

本発明は、動画データの送信方法に関する。

近年、ネットワークカメラやビデオ会議システムなど、ネットワークを介して動画データをリアルタイムに送受信するストリーミング技術が実用化されている。
特許文献１には、動画データを送信する際に、ネットワークの伝送速度に応じてフレーム間引きをすることが記載されている。

特開２００３−３０９８４７号公報

しかしながら、複数の異なるフレームレートで動画データを送信している場合のフレームレートの変更方法によっては、特定の動画データの品質が低くなりすぎてしまう恐れがあった。

例えば、動画データを、第１のクライアントへ１秒間に６０フレームのフレームレート（６０ｆｐｓ）で送信し、第２のクライアントへ１０ｆｐｓで送信しているときに、送信装置の処理負荷が閾値を超えた場合について説明する。この場合、各クライアントへ送信する動画データのフレームレートをそれぞれ半分にすると、第２のクライアントへ送信される動画データのフレームレートが５ｆｐｓとなってしまい、動画の内容がわからなくなってしまう恐れがあった。

また、例えば、あるクライアントへ第１の動画データを６０ｆｐｓ、第２の動画データを１０ｆｐｓで送信しているときに、送信装置の処理負荷に応じて、フレームレートをそれぞれ半分にすると、第２の動画データのフレームレートが低くなりすぎてしまった。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、複数の異なるフレームレートで動画データを送信している場合のフレームレートの変更によって、特定の動画データの品質が低くなりすぎる可能性を低減することである。

上記の問題点を解決するために、本発明の送信装置は、例えば以下の構成を有する。すなわち、複数の異なるフレームレートで動画データを送信する送信装置であって、前記送信装置の状態情報を取得する取得手段と、第１のフレームレートと、前記第１のフレームレートよりも低い第２のフレームレートとで動画データを送信中に、前記第１及び第２のフレームレートを下げる場合、前記第１のフレームレートと第１のフレームレートを下げた後の第１の変更フレームレートとの割合が、前記第２のフレームレートと第２のフレームレートを下げた後の第２の変更フレームレートとの割合よりも大きくなるように、前記状態情報に応じて前記第１及び第２のフレームレートを下げる変更手段とを有する。

本発明によれば、複数の異なるフレームレートで動画データを送信している場合のフレームレートの変更によって、特定の動画データの品質が低くなりすぎてしまう可能性を低減できる。

送信装置１００の機能構成例を示すブロック図 送信装置１００の処理を説明するためのフローチャート 実施形態のシステム構成例を示す図 ＣＰＵ負荷とフレームレートの関係を説明するための図 送信装置５００の機能構成例を示すブロック図 送信装置５００の処理を説明するためのフローチャート

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

＜第１の実施形態＞
図１は、本発明の実施形態に係る送信装置１００の機能構成例を示すブロック図である。なお、本形態の送信装置１００は、複数の異なるフレームレートで動画データを送信する送信装置である。
図１に示すように、本実施形態の送信装置１００は、動画符号化部１０２、フレームレート制御部１０３、パケット生成部１０４、負荷取得部１０５、バッファ１０６、通信インタフェース１０７を備える。また、送信装置１００は、映像を入力する映像入力装置１０１、及び伝送路１０８に接続される。
映像入力装置１０１は、受信装置へ送信すべき動画データを入力する装置である。映像入力装置１０１は、例えば、ビデオカメラやＷｅｂカメラなどである。ただし、映像入力装置１０１が送信装置１００と一体となっていても良い。
つまり、送信装置１００は、パーソナルコンピュータ、ワークステーション、ノートブックＰＣ、コンピュータを内蔵した各種家電装置、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどの機器、或いはこれらの組み合わせにより実現可能である。

伝送路１０８は、各種ネットワークに代表される伝送路であり、本実施形態においては、動画データを始めとする各種パケットを送受信するためのネットワークである。送受信されるデータはバッファ１０６において一時的に記憶される。

動画符号化部１０２は、上述の映像入力装置１０１から入力された動画データをＭｏｔｉｏｎ−ＪＰＥＧ方式により圧縮符号化する。動画データは、そのまま送信するにはデータ量が多いため、送信前に圧縮符号化される。なお、動画符号化部の符号化方式は、Ｍｏｔｉｏｎ−ＪＰＥＧ方式に限らない。動画符号化部１０２は、圧縮符号化した動画データをフレーム単位でパケット生成部１０４へ入力する。
パケット生成部１０４は、動画符号化部１０２から入力された動画データをパケット化し、バッファ１０６へ記憶させる。本実施形態では、動画データの符号化方式としてＭｏｔｉｏｎ−ＪＰＥＧを用い、符号化動画データの転送プロトコルとしてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用いる。従ってパケット生成部１０４は、Ｍｏｔｉｏｎ−ＪＰＥＧで符号化された動画データのＲＴＰペイロードフォーマットを規定しているＩＥＴＦ ＲＦＣ２４３５に従って符号化動画データをパケット化する。

フレームレート制御部１０３は、動画データのフレームレートを制御すると共に、制御後のフレームレートに基づいてバッファ１０６内の動画パケットを読み出して受信装置へ送信する。フレームレート制御部１０３によるフレームレートの制御方法については後述する。

次に、本実施形態の送信装置１００によるフレームレート制御処理の詳細について、図２を用いて説明する。図２は、本実施形態に係る送信装置１００におけるフレームレート制御処理を説明するためのフローチャートである。なお、本形態の送信装置１００は、複数の異なるフレームレートで動画データを送信する送信装置である。また、本形態の送信装置１００は、図２の処理を実行するためのプログラムをＣＰＵが読み出して実行することにより、図２の処理を実現する。ただし、図２の処理の少なくとも一部を専用のハードウェアで行うようにすることも可能である。また、本形態の送信装置１００は、受信装置に対して動画データの送信を開始するタイミングで図２の処理を開始する。

本形態の送信装置１００は、図３に示すように、複数の受信装置（３０１〜３０３）へ動画データを送信する。図３に示すように、送信装置１００は、受信装置３０１に対して３０ｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃ）、受信装置３０２に対して１５ｆｐｓ、受信装置３０３に対して１０ｆｐｓで動画データを送信する。本形態の送信装置１００は、異なる動画データを異なるフレームレートで複数の受信装置へ送信する。ただし、各受信装置へ送信される動画データは、映像入力装置１０１からの同一の入力内容に基づく動画データであっても良い。

負荷取得部１０５は、送信装置１００の現在の処理負荷を取得する（Ｓ２０１）。負荷取得部１０５は、例えば、複数の動画データの送信処理を含む複数の処理を行う処理部（ＣＰＵ）の処理負荷を状態情報として取得する。

ただし、この例に限らず、負荷取得部１０５は、映像入力装置１０１からの動画データの入力時刻と当該動画データのパケットの送信時刻との時間差や、動画データの入力時刻と動画パケットの生成時刻との時間差を現在の処理負荷として取得することも可能である。また、負荷取得部１０５は、動画パケットの生成時刻と送信時刻の時間差を現在の処理負荷として取得することも可能である。これらの時間差は、送信装置１００による処理時間に対応する。本形態では、取得された時間差が大きいほど、現在の処理負荷が大きいと判定される。

なお、送信装置１００は、ＣＰＵの負荷や時間差の情報を組み合わせて、現在の処理負荷を判定することも可能である。また、送信装置１００のＣＰＵの負荷は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）などから取得することができる。また、送信装置１００の処理負荷に限らず、バッファ１０６に記憶された送信待ちの動画データのデータ量や、フレーム数などを取得するようにしても良い。すなわち、Ｓ２０１（取得手順）において、送信装置１００の負荷取得部１０５は、送信装置１００の状態情報（処理負荷の情報や、バッファ１０６の状況など）を取得する。なお、以下の説明では、状態情報として処理負荷を取得する例を中心に説明する。

本形態の負荷取得部１０５は、現在の処理負荷を定期的に取得する。ただし、処理負荷を、例えば、エラーパケットの増加や、新規の動画データの送信開始や、既存の動画データの送信終了に応じて取得するようにしても良い。

フレームレート制御部１０３は、各受信装置に送信している動画データのフレームレートの値を取得する（Ｓ２０２）。第１及び第２及び第３の受信装置へ動画データを送信している場合、フレームレート制御部１０３は、まず、第１の受信装置へ送信している動画データの初期フレームレートと現在のフレームレートを取得する。初期フレームレートは、ＲＴＰパケット（動画パケット）送信前に、送信装置と受信装置との間で、ＲＴＳＰ、ＳＤＰ、ＳＩＰ、ＳＯＡＰ等の制御用プロトコルを利用して通信することにより、予め決定されたフレームレートの値である。なお、ＲＴＳＰはＲｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ、ＳＤＰはＳｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌである。また、ＳＩＰはＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＯＡＰはＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌである。

また、現在のフレームレートは、後述するフレームレートの制御が行われていなければ、初期フレームレートと同値である。第１の受信装置へ送信されている動画データのフレームレートと初期フレームレートがＳ２０２で取得されると、Ｓ２０３へ進む。
フレームレート制御部１０３は、Ｓ２０１において負荷取得部１０５が取得した処理負荷が、閾値以上か否かを判定する（Ｓ２０３）。閾値は任意の値を設定することが可能であるが、本実施形態の送信装置１００は、例えばＣＰＵ負荷８０％を閾値とする。

ただし、８０％に限らない。また、例えば、動画データの入力時刻と当該動画データのパケットの送信時刻の差（１００ミリ秒）を閾値として設定することも可能である。また、例えば、動画データのパケットの生成時刻と送信時刻との時間差（３０ミリ秒）を閾値として設定することも可能である。さらに、現在の処理負荷が閾値以上であるか否かを、上記の複数の閾値の組み合わせに基づいて判定するようにしても良い。

Ｓ２０３で処理負荷が閾値以上であると判定された場合、フレームレート制御部１０３は、Ｓ２０２で取得された現在のフレームレートが閾値以上か否かを判定する（Ｓ２０４）。閾値は任意の値にすることが可能であるが、本実施形態の送信装置１００は、１１ｆｐｓを閾値とする。

Ｓ２０４で現在のフレームレートが閾値未満であると判定された場合、Ｓ２０８に進み、閾値以上であると判定された場合、Ｓ２０６へ進む。
Ｓ２０６において、フレームレート制御部１０３は、フレームレートを下げる処理を行う。すなわち、フレームレート制御部１０３は、Ｓ２０２で取得された現在のフレームレートが１１ｆｐｓ以上であり、Ｓ２０３で処理負荷が所定の負荷に達したと判定されると、フレームレートを下げる処理を行う。

また、上述のように、処理負荷は、ＣＰＵの負荷に限らず、例えば、映像入力装置１０１からの動画データの入力時刻から当該動画データのパケットの送信時刻までの時間差などであっても良い。すなわち、フレームレート制御部１０３は、動画データの入力時刻と送信時刻との時間差が所定値に達すると、Ｓ２０６の処理を実行するようにすることも可能である。

また、Ｓ２０１で取得される状態情報は、処理負荷に限らず、例えば、バッファ１０６に記憶される送信待ちの動画データのフレーム数やデータ量であっても良い。すなわち、フレームレート制御部１０３は、バッファ１０６に記憶される送信待ちの動画データのフレーム数やデータ量の少なくとも一方が所定値に達すると、Ｓ２０６の処理を実行するようにすることも可能である。

本形態のフレームレート制御部１０３は、現在のフレームレートが高いほど、より大きい割合でフレームレートが下がるように、変更後のフレームレートを決定する。例えば、フレームレート制御部１０３は、現在のフレームレートが３０ｆｐｓの場合、変更後のフレームレートが１５ｆｐｓになり、現在のフレームレートが１５ｆｐｓの場合、変更後のフレームレートが１０ｆｐｓとなるようにフレームレートを制御する。

すなわち、フレームレート制御部１０３は、３０ｆｐｓと１５ｆｐｓとで動画データを送信中に、これらのフレームレートを送信装置１００の処理負荷に応じて下げる場合、Ｓ２０６（変更手順）において、以下のようにフレームレートを変更する。すなわち、フレームレート制御部１０３は、変更前（３０ｆｐｓ）と、変更後の変更フレームレート（１５ｆｐｓ）との割合（−１／２）が、変更前（１５ｆｐｓ）と、変更後の変更フレームレート（１０ｆｐｓ）との割合（−１／３）よりも大きくなるようにフレームレートを変更する。

なお、本形態の動画符号化部１０２は、Ｓ２０６でフレームレートが下げられても、フレームレートを下げる前と同じフレームレートで動画データの符号化を行い、パケット生成部１０４は、下げられたフレームレートで動画パケットを生成する。本形態の動画符号化部１０２は、専用のハードウェアで動画の符号化処理を行う。

一方、フレームレート制御部１０３は、Ｓ２０２で取得された現在のフレームレートが１１ｆｐｓよりも低い場合、Ｓ２０３で処理負荷が閾値以上であると判定されても、フレームレートの変更を行わない。

Ｓ２０６でフレームレートを下げる処理を行った後、又は、Ｓ２０４でフレームレートが閾値（１１ｆｐｓ）未満であると判定された場合、フレームレート制御部１０３は、すべての動画データについて、Ｓ２０２からＳ２０７の処理を完了したか判定する（Ｓ２０８）。Ｓ２０８で完了していないと判定された場合はＳ２０２へ戻り、完了したと判定された場合は図２の処理を終了する。Ｓ２０２へ戻った場合、第２の受信装置３０２に関する初期フレームレートと現在のフレームレートが取得され、Ｓ２０３以下の処理が行われる。

本形態では、図２の処理を終了後、所定時間が経過すると、再び図２の処理が開始される。ただし、所定時間経過後に限らず、例えば、エラーパケットの増加や、新規の動画データの送信開始や、既存の動画データの送信終了に応じて、図２の処理を開始するようにしても良い。
Ｓ２０３において、送信装置１００の処理負荷が閾値未満であると判定された場合、フレームレート制御部１０３は、Ｓ２０２で取得された現在のフレームレートが、初期フレームレートよりも低いか否かを判定する（Ｓ２０５）。
Ｓ２０５で現在のフレームレートが初期フレームレートよりも低いと判定された場合、初期フレームレートを上限として、現在のフレームレートを上げる処理を行う（Ｓ２０７）。例えば、初期フレームレートが３０ｆｐｓであったにもかかわらず、送信装置１００の処理負荷に応じて１５ｆｐｓに下げられ、その後、処理負荷が閾値よりも低くなった場合、現在のフレームレートを、３０ｆｐｓを上限として回復させる。

すなわち、フレームレート制御部１０３は、状態情報（処理負荷やバッファ１０６の状況）に応じて、複数の変更フレームレートのそれぞれを初期フレームレートに変更する。

なお、上記の例において、１５ｆｐｓのフレームレートをどこまで上げるかは、現在の処理負荷に基づいて決定することができる。また、フレームレートを下げるか否かを判定するための閾値と、フレームレートを回復させるか否かを判定するための閾値は、別の値にすることが可能である。すなわち、フレームレートを下げるか否かの判定のための処理負荷の閾値（ＣＰＵ負荷８０％）を、フレームレートを回復するか否かの判定のための処理負荷の閾値（ＣＰＵ負荷６０％）よりも高くすることで、フレームレートの変更頻度を少なくすることができる。なお、本形態の動画符号化部１０２は、Ｓ２０７でフレームレートが上がっても、フレームレートが上がる前と同じフレームレートで動画データの符号化を行う。このようにすることで、動画符号化部１０２でのフレームレートの変更頻度を少なくすることができる。

Ｓ２０５でフレームレートが下げられていない（初期フレームレートと現在のフレームレートが同値）と判定された場合、Ｓ２０８へ進む。

次に、本実施形態のシステム全体の処理について、図３及び図４を用いて説明する。

図３は、本実施形態の送信装置１００と、複数の受信装置（３０１〜３０３）の接続形態の一例を示す図である。送信装置１００と第１の受信装置３０１及び第２の受信装置３０２、第３の受信装置３０３は、ネットワーク３０４（図１では伝送路１０８に相当）を介して相互に接続されている。

また、各受信装置へ送信する動画像の解像度は、全てＶＧＡ（６４０ｘ４８０ピクセル）であるとする。初期フレームレートはそれぞれ、第１の受信装置３０１が３０ｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃ）、第２の受信装置３０２が１５ｆｐｓ、第３の受信装置３０３が１０ｆｐｓであるとする。また、本実施形態では、フレームレートの閾値として１１ｆｐｓが設定されているものとする。

図４は、送信装置１００において、負荷取得部１０５により取得されるＣＰＵ負荷と、第１〜第３の受信装置（３０１〜３０３）へ送信される動画データのフレームレートとの関係を時間経過と共に示す図である。
図４の４０１は、送信装置１００の負荷取得部１０５により取得されるＣＰＵ負荷を時間経過と共に示す図である。本実施形態では、ＣＰＵ負荷の閾値として８０％が設定されているものとする。また、時刻０から時刻ｔ１までの期間のＣＰＵ負荷はｃ１、時刻ｔ１から時刻ｔ２までの期間のＣＰＵ負荷はｃ３、時刻ｔ２から時刻ｔ３までの期間のＣＰＵ負荷はｃ４、時刻ｔ３以降のＣＰＵ負荷はｃ２であり、ｃ１＜ｃ２＜ｃ３＜８０（％）＜ｃ４とする。

また、図４の４０２〜４０４は、第１の受信装置３０１〜第３の受信装置のそれぞれへ送信される動画データのフレームレートの変化を時間経過と共に示している。
まず時刻０に、第１の受信装置３０１への動画データの送信が開始される。ここでＣＰＵ負荷はｃ１であり、閾値の８０％未満である。従って、フレームレートは初期値の３０ｆｐｓのままで第１の受信装置３０１へ動画データが送信される。
続いて時刻ｔ１に、第２の受信装置３０２への動画データの送信が開始される。これによりＣＰＵ負荷がｃ１からｃ３となるが、依然として閾値の８０％未満である。従って、第１の受信装置３０１のフレームレートは初期値の３０ｆｐｓのまま、第２の受信装置３０２のフレームレートも初期値の１５ｆｐｓのままで動画データが送信される。

さらに時刻ｔ２に、第３の受信装置３０３への動画データの送信が開始される。これによりＣＰＵ負荷がｃ３からｃ４となり、閾値の８０％以上となる。
その後時刻ｔ３に、フレームレートを下げるためのフレームレート制御が行われる。時刻ｔ２から時刻ｔ３までの期間は、負荷取得部１０５がＣＰＵ負荷を取得してからフレームレート制御部１０３がフレームレートを下げるまでに要する時間である。フレームレートの制御の結果、第１の受信装置３０１のフレームレートは３０ｆｐｓから半分の１５ｆｐｓへ減少し、第２の受信装置３０２のフレームレートは１５ｆｐｓから２／３の１０ｆｐｓへ減少する。このように、本形態のフレームレート制御部１０３は、送信装置１００の処理負荷が閾値以上となった時点において高いフレームレートであるほど、大きい割合でフレームレートが下がるように、変更後のフレームレートを決定する。

なお、第３の受信装置３０３のフレームレートは１０ｆｐｓであり、閾値（１１ｆｐｓ）未満であるため変更されない。すなわち、フレームレート制御部１０３は、第１の受信装置３０１と第２の受信装置３０２へ送信する動画データのフレームレートを下げる場合において、第３の受信装置３０３へ送信する動画データのフレームレートを下げない。上記のようなフレームレートの制御により、送信装置１００のＣＰＵ負荷は、ｃ４からｃ２へと減少し、閾値の８０％未満となる。

以上のように、送信装置１００のフレームレート制御部１０３は、送信中の動画データのフレームレートを下げる場合、下げる前のフレームレートが高いほど、より大きい割合でフレームレートが下がるように、変更後のフレームレートを決定する。このようにすることで、複数の異なるフレームレートで動画データを送信している場合において、フレームレートの制御により、特定の動画データのフレームレートが過度に下がりすぎてしまう可能性を低減できる。

なお、実施形態では、複数の受信装置に異なるフレームレートで動画データを送信する例を中心に説明したが、１つの受信装置に異なるフレームレートで動画データを送信する場合にも、本発明は適用可能である。

また、上記の説明では、図２のＳ２０２で、現在のフレームレートと、対応する初期フレームレートの組を１つ、取得する例について説明したが、送信中の現在のフレームレートと初期フレームレートの組をすべてＳ２０２で取得するようにしても良い。この場合、Ｓ２０３で処理負荷が閾値以上と判定され、Ｓ２０２で取得された複数の現在のフレームレートのうち、１つ以上のフレームレートが閾値以上の場合、フレームレート制御部１０３は、Ｓ２０６でフレームレートを下げるためのフレームレート制御を行う。

また、フレームレート制御部１０３は、第１の初期フレームレートの変更後の第１の変更フレームレートと、第２の初期フレームレートの変更後の第２の変更フレームレートが同じ場合に、さらにフレームレートを下げる場合、以下のように制御する。すなわち、フレームレート制御部１０３は、第１の変更フレームレートの変更後の第３の変更フレームレートよりも、第２の変更フレームレートの変更後の第４の変更フレームレートが低くなるように、フレームレートを制御する。ただし、第１の初期フレームレートは第２の初期フレームレートより高い。このようにすることで、現在のフレームレートが、複数の受信装置間で同じ場合は、よりユーザの要求に近いフレームレートに制御することができる。

また、送信中の動画データの解像度に基づいて、フレームレートを制御するようにしても良い。例えば、図３に示したような例において、第１の受信装置３０１へ送信している動画データの解像度がＱｕａｄ−ＶＧＡ（１２８０ｘ９６０ピクセル）の場合は、１５ｆｐｓよりもさらにフレームレートが下がるようにしても良い。そして、第２の受信装置３０２へ送信される動画データ（ＶＧＡサイズ）のフレームレートは、１５ｆｐｓよりも高くすることができる。このようにすることで、特定の動画データの品質が低くなりすぎてしまう可能性を低減できる。解像度を用いたフレームレートの制御の詳細は、第２の実施形態で述べる。

＜第２の実施形態＞
次に第２の実施形態について、第１の実施形態との差異を中心に説明する。
本実施形態では、送信する動画データの解像度が異なる場合の実施形態について説明する。

図５は、第２の実施形態の送信装置５００の機能構成例を示すブロック図である。図５に示すように、本実施形態の送信装置５００は、第１の動画符号化部５０１、第２の動画符号化部５０２、第１のパケット生成部５０３、第２のパケット生成部５０４を備える。同図において、図１と同じ部分には同じ番号を付与している。

第１の動画符号化部５０１は、映像入力装置１０１から入力された動画データを、Ｑｕａｄ−ＶＧＡ（１２８０ｘ９６０ピクセル）のＭｏｔｉｏｎ−ＪＰＥＧ方式により圧縮符号化する。第１の動画符号化部５０１は、圧縮符号化した動画データをフレーム単位で第１のパケット生成部５０３へ入力する。

また第２の動画符号化部５０２は、映像入力装置１０１から入力された動画データを、ＶＧＡ（６４０ｘ４８０ピクセル）のＭｏｔｉｏｎ−ＪＰＥＧ方式により圧縮符号化する。第２の動画符号化部５０２は、圧縮符号化した動画データをフレーム単位で第２のパケット生成部５０４へ入力する。

第１のパケット生成部５０３と第２のパケット生成部５０４は、第１の動画符号化部５０１及び第２の動画符号化部５０２から各々入力された動画データをパケット化し、バッファ１０６へ記憶させる。本実施形態の第１のパケット生成部５０３と第２のパケット生成部５０４は、第１の実施形態のパケット生成部１０４と同様に、ＲＴＰペイロードフォーマットを規定しているＩＥＴＦ ＲＦＣ２４３５に従って符号化動画データをパケット化するものとする。

次に、本実施形態の送信装置１００によるフレームレート制御処理の詳細について、図６を用いて説明する。図６は、本実施形態の送信装置５００におけるフレームレート制御処理を説明するためのフローチャートである。なお、本形態の送信装置５００は、複数の異なるフレームレートで動画データを送信する送信装置である。また、本形態の送信装置５００は、図６の処理を実行するためのプログラムをＣＰＵが読み出して実行することにより、図６の処理を実現する。

ただし、図６の処理の少なくとも一部を専用のハードウェアで行うようにすることも可能である。また、本形態の送信装置５００は、受信装置に対して動画データの送信を開始するタイミングで図６の処理を開始する。なお、本形態では、第１の受信装置に対してＱｕａｄ−ＶＧＡの動画データを送信し、第２の受信装置に対してＶＧＡの動画データを送信しているものとする。

まず負荷取得部１０５は、送信装置５００の現在の状態情報を取得する（Ｓ６０１）。状態情報は、第１の実施形態と同様に、送信装置１００の処理負荷や、バッファ１０６に記憶されている送信待ちの動画データのデータ量やフレーム数に関する情報である。なお、以下では、状態情報として、送信装置１００の処理負荷を用いる例を中心に説明する。

フレームレート制御部１０３は、各受信装置に送信する動画データの解像度とフレームレートの値を取得する（Ｓ６０２）。本実施形態では、第１の受信装置へＱｕａｄ−ＶＧＡの動画データを送信し、第２の受信装置へＶＧＡの動画データを送信している。また、フレームレートの取得方法については第１の実施形態と同様である。

Ｓ６０３〜Ｓ６０５、Ｓ６０７の処理は、第１の実施形態のＳ２０３〜ステップＳ２０５、Ｓ２０７の処理に対応する。
Ｓ６０２で取得された現在のフレームレートが閾値以上であるとＳ６０４で判定された場合、フレームレート制御部１０３は、当該フレームレートで送信している動画データの解像度がＱｕａｄ−ＶＧＡであるか否かを判定する（Ｓ６０６）。解像度がＱｕａｄ−ＶＧＡであると判定された場合、Ｓ６０８へ進み、解像度がＱｕａｄ−ＶＧＡでない（ＶＧＡである）と判定された場合、Ｓ６０９へ進む。
Ｓ６０６で解像度がＱｕａｄ−ＶＧＡと判定された場合、フレームレート制御部１０３は、Ｑｕａｄ−ＶＧＡの動画データのフレームレートを下げる（Ｓ６０８）。すなわち、本形態のフレームレート制御部１０３は、送信装置５００の処理負荷が閾値以上となった場合、所定解像度（Ｑｕａｄ−ＶＧＡ）以上の動画データのフレームレートを下げる。一方、フレームレート制御部１０３は、処理負荷が閾値以上となっても、所定解像度未満（ＶＧＡ）の動画データのフレームレートを下げない。所定解像度の例は、Ｑｕａｄ−ＶＧＡに限らない。

なお、本形態の第１の動画符号化部５０１は、Ｓ６０８でフレームレートを下げても、フレームレートを下げる前と同じフレームレートで動画データの符号化を行い、第１のパケット生成部５０３は、下げられたフレームレートで動画パケットの生成を行う。本形態の第１の動画符号化部５０１と第２の動画符号化部５０２は、専用のハードウェアで動画の符号化処理を行う。

フレームレート制御部１０３は、送信中のすべての動画データについて、Ｓ６０２からＳ６０８の処理を完了したか判定し（Ｓ６０９）、完了していないと判定された場合はＳ６０２に戻る。

一方、Ｓ６０９ですべての動画データについての処理が完了したと判定された場合、図６の処理を終了する。本形態では、図６の処理を終了後、所定時間が経過すると、再び図６の処理が開始される。ただし、所定時間経過後に限らず、例えば、エラーパケットの増加や、新規の動画データの送信開始や、既存の動画データの送信終了に応じて、図６の処理を開始するようにしても良い。

以上のように、送信装置５００のフレームレート制御部１０３は、送信装置５００の処理負荷に応じて、所定解像度以上の動画データのフレームレートを下げる。このようにすることで、フレームレートの制御により、特定の動画データの品質が過度に下がりすぎてしまう可能性を低減できる。

なお、本形態では、送信装置５００の処理負荷が所定値以上になると、所定解像度以上の動画データのフレームレートを下げ、所定解像度以下の動画データのフレームレートを下げない例について説明したが、この形態に限らない。例えば、送信中の動画データの解像度に応じて、フレームレートの低減量を決定するようにしても良い。

例えば、第１の受信装置にＱｕａｄ−ＶＧＡの動画データを３０ｆｐｓで送信し、第２の受信装置にＶＧＡの動画データを３０ｆｐｓで送信しているときに、送信装置５００の処理負荷が閾値以上になった場合、以下のようにフレームレートを制御できる。すなわち送信装置５００は、第１の受信装置へ送信する動画データのフレームレートを１５ｆｐｓに下げ、その後の処理負荷に応じて、第２の受信装置へ送信する動画データのフレームレートを２０ｆｐｓに下げることができる。なお、処理負荷の代わりに、ほかの状態情報（例えばバッファ１０６に記憶されている送信待ち動画データのフレーム数やデータ量）を用いても良い。

このように、解像度が高い動画データほど、より大きい割合でフレームレートが下がるように、フレームレートを制御することで、特定の動画データの品質が下がりすぎてしまう可能性を低減できる。

上記の実施形態では、送信装置１００が動画データの符号化処理を行う機能を有していたが、動画符号化部１０２と送信装置１００が別々の装置であっても良い。

また、前述の実施形態では、データ転送プロトコルとしてＲＴＰを用いたが、データ転送プロトコルとしてはＲＴＰに限らずＯＳＩ参照モデルの同一レイヤーの他のプロトコルまたは別レイヤーの他のプロトコルを用いる事が可能である。

以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。

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

Claims (10)

1. 複数の異なるフレームレートで動画データを送信する送信装置であって、
   前記送信装置の状態情報を取得する取得手段と、
   第１のフレームレートと、前記第１のフレームレートよりも低い第２のフレームレートとで動画データを送信中に、前記第１及び第２のフレームレートを下げる場合、
   前記第１のフレームレートと第１のフレームレートを下げた後の第１の変更フレームレートとの割合が、前記第２のフレームレートと第２のフレームレートを下げた後の第２の変更フレームレートとの割合よりも大きくなるように、前記状態情報に応じて前記第１及び第２のフレームレートを下げる変更手段とを有することを特徴とする送信装置。
2. 前記取得手段は、前記第１及び第２の動画データの送信処理を含む複数の処理を行う処理部の処理負荷を状態情報として取得し、
   前記変更手段は、前記処理部の処理負荷が所定の負荷に達すると前記第１及び第２のフレームレートを下げることを特徴とする請求項１に記載の送信装置。
3. 送信すべき動画データを入力する入力手段を有し、
   前記取得手段は、前記入力手段が前記動画データを入力してから前記動画データを送信するまでの時間に関する処理時間を状態情報として取得し、
   前記変更手段は、前記処理時間が所定の時間に達すると前記第１及び第２のフレームレートを下げることを特徴とする請求項１又は２に記載の送信装置。
4. 送信待ちの動画データを記憶する記憶手段を有し、
   前記取得手段は、前記送信待ちの動画データのフレーム数、及び、前記送信待ちの動画データのデータ量のうち、少なくとも一方を状態情報として取得し、
   前記変更手段は、前記取得されたフレーム数、及び、前記取得されたデータ量のうち、少なくとも一方が所定値に達すると、前記第１及び第２のフレームレートを下げることを特徴とする請求項１乃至３のうち、いずれか１項に記載の送信装置。
5. 前記変更手段は、前記第１のフレームレートと、前記第２のフレームレートと、更に、前記第２のフレームレートよりも低い第３のフレームレートで動画データを送信している場合、前記第１及び第２のフレームレートを変更する際に、前記第３のフレームレートが所定のフレームレートよりも低い場合、前記第３のフレームレートを下げないことを特徴とする請求項１乃至４のうち、いずれか１項に記載の送信装置。
6. 前記第１の変更フレームレートと前記第２の変更フレームレートが同じフレームレートで、前記変更の後に取得された状態情報に応じて前記第１及び第２の変更フレームレートを更に下げる場合、前記第１の変更フレームレートの変更後の第３の変更フレームレートよりも、前記第２の変更フレームレートの変更後の第４の変更フレームレートのほうが低くなるように、前記第１の変更フレームレートと前記第２の変更フレームレートを下げることを特徴とする請求項１乃至５のうち、いずれか１項に記載の送信装置。
7. 前記変更手段は、前記状態情報に応じて、前記第１の変更フレームレートを前記変更前の前記第１のフレームレートに変更し、前記第２の変更フレームレートを前記変更前の前記第２のフレームレートに変更することを特徴とする請求項１乃至６のうち、いずれか１項に記載の送信装置。
8. 前記変更手段は、第１の解像度の動画データを第１のフレームレートで、前記第１の解像度よりも低い第２の解像度の動画データを前記第２のフレームレートで送信中に、前記第１及び第２のフレームレートを下げる場合、前記第１の解像度に対応する前記第１のフレームレートを前記状態情報に応じて前記第１の変更フレームレートに下げ、下げた後に取得された状態情報に応じて前記第２のフレームレートを前記第２の変更フレームレートに下げることを特徴とする請求項１乃至７のうち、いずれか１項に記載の送信装置。
9. 複数の異なるフレームレートで動画データを送信する送信装置が行う送信方法であって、
   前記送信装置の状態情報を取得する取得工程と、
   第１のフレームレートと、前記第１のフレームレートよりも低い第２のフレームレートとで動画データを送信中に、前記第１及び第２のフレームレートを下げる場合、
   前記第１のフレームレートと第１のフレームレートを下げた後の第１の変更フレームレートとの割合が、前記第２のフレームレートと第２のフレームレートを下げた後の第２の変更フレームレートとの割合よりも大きくなるように、前記状態情報に応じて前記第１及び第２のフレームレートを下げる変更工程とを有することを特徴とする送信方法。
10. 複数の異なるフレームレートで動画データを送信するコンピュータに、
    前記送信装置の状態情報を取得する取得手順と、
    第１のフレームレートと、前記第１のフレームレートよりも低い第２のフレームレートとで動画データを送信中に、前記第１及び第２のフレームレートを下げる場合、
    前記第１のフレームレートと第１のフレームレートを下げた後の第１の変更フレームレートとの割合が、前記第２のフレームレートと第２のフレームレートを下げた後の第２の変更フレームレートとの割合よりも大きくなるように、前記状態情報に応じて前記第１及び第２のフレームレートを下げる変更手順とを実行させることを特徴とするプログラム。

Images