JP2017069849A - 映像制御装置、映像配信システムおよび映像制御方法 - Google Patents

Abstract

【課題】ネットワークの帯域変化により適切に対応できる映像制御装置、映像配信システムおよび映像制御方法を提供する。【解決手段】映像制御装置１００は、ネットワーク３００を介して受信した映像データを蓄積する再生バッファ２０８と、再生バッファ２０８から読み出した映像データをデコードするデコーダ２０９と、ネットワーク３００の所定時間後の可用帯域を推定し、推定した所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した目標バッファデータ量と、再生バッファ２０８に蓄積されたデータ量とを用いて、映像データのトランスコード速度と、映像データのエンコードレートを含むエンコードパラメータとを決定する決定部２２０と、決定部２２０が決定したトランスコード速度およびエンコードパラメータを、サーバ装置１００に対して送信する通信部２１０と、を備える。【選択図】図４

Description

本発明は映像を映像変換（トランスコード）する映像制御装置、映像配信システムおよび映像制御方法に関する。

映像配信サーバに蓄積された映像データを、ネットワークを介して、クライアントに配信するシステムでは、クライアントにおいて高品質かつ安定した映像の再生を実現できることが望ましい。インターネットのようなネットワークは、利用可能な帯域（以下、可用帯域とも呼ぶ）が変化する。このため、映像データの配信と並行して、映像配信サーバが、映像データのビットレート（以下、エンコードレートとも呼ぶ）を可用帯域以下に抑えるように映像変換（以下、トランスコードとも呼ぶ）する制御を行っている。

また、ネットワークの可用帯域の変化に合わせて、映像データを指定したエンコードレートでトランスコードするだけでなく、映像をトランスコードする速度（以下、トランスコード速度とも呼ぶ）を調整する技術が提案されている。

特許文献１では、可用帯域が変化する接続を介した映像データの送信において、エンコードレートとトランスコード速度とを調整する技術が開示されている。

特表２０１４−５２９９３１号公報

しかしながら、上述した従来の技術では、ネットワークの帯域変化に適切に対応できていないため、更なる改善が必要とされていた。

そこで、本発明は、ネットワークの帯域変化により適切に対応できる映像制御装置、映像配信システムおよび映像制御方法を提供することを目的とする。

従来の課題を解決するため、本発明の一態様に係る映像制御装置は、サーバ装置から送信された映像データを受信する映像制御装置であって、前記サーバ装置でトランスコードされ、ネットワークを介して受信した前記映像データを蓄積する再生バッファと、前記再生バッファから読み出した前記映像データをデコードするデコーダと、前記ネットワークの所定時間後の可用帯域を推定し、推定した当該所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した当該目標バッファデータ量と、前記再生バッファに蓄積されたデータ量とを用いて、前記再生バッファに蓄積されるデータ量を変化させるパラメータである、前記映像データの単位時間当たりの送信速度に関するトランスコード速度と、前記映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する決定部と、前記決定部が決定した前記トランスコード速度および前記エンコードパラメータを、前記サーバ装置に対して送信する通信部と、を備える。

なお、これらの包括的又は具体的な側面は、システム、装置、方法、記録媒体、又は、コンピュータプログラムで実現されてもよく、システム、装置、方法、記録媒体、および、コンピュータプログラムの任意な組み合わせで実現されてもよい。

本発明に係る映像制御装置、映像配信システムおよび映像制御方法を用いることで、ネットワークの可用帯域の変動を推定してトランスコード速度とエンコードパラメータとを決定することが可能となり、ネットワークの帯域変化により適切に対応できる。

図１は、トランスコード速度を説明するための図である。 図２は、実施の形態１における映像配信システムの構成の一例を示す図である。 図３は、実施の形態１における映像配信サーバの構成の一例を示す図である。 図４は、実施の形態１におけるクライアントの構成の一例を示す図である。 図５は、実施の形態１におけるクライアントが可用帯域の推定を行うための動作の一例を示すフローチャートである。 図６は、実施の形態１におけるクライアントがトランスコード速度とエンコードパラメータとを決定する動作の一例を示すフローチャートである。 図７は、実施の形態２におけるクライアントの構成の一例を示す図である。 図８は、実施の形態２におけるクライアントがトランスコード速度とエンコードパラメータとを決定する動作の一例を示すフローチャートである。 図９は、実施の形態２におけるクライアントが通信環境を確認する動作の一例を示すフローチャートである。

（発明の基礎となった知見）
以下、本発明の基礎となった知見について説明する。

映像配信サーバに蓄積された映像データを、ネットワークを介して、クライアントに配信するシステムでは、クライアントにおいて高品質かつ安定した映像の再生を実現できることが望ましい。

クライアントへの映像データの到着に遅れが発生すると、クライアントでは、デコーダに供給する映像データが枯渇することにより、映像の再生が停止する可能性がある。通常、データの到着の遅延が発生しても映像の再生が停止することを防ぐため、クライアントは、映像データを受信してから再生するまでの間、映像データを一時的に蓄積する再生バッファを備える。しかし、配信する映像データのビットレート（エンコードレート）がネットワークの可用帯域を超えると、映像データの配信の遅延が再生バッファで吸収できないほど大きくなる場合がある。この場合、クライアントは、バッファアンダーフローが発生して、映像の再生の停止を防ぐことができない。特に、インターネットのようなネットワークは、利用可能な帯域（可用帯域）が変化する。

映像データの配信の遅延を再生バッファに蓄積されたデータ量内に収めるために、映像配信サーバは、映像データの配信と並行して、映像データのエンコードレートを可用帯域以下に抑えるように映像変換（トランスコード）を行う制御を行う。従来の方法では、再生バッファに蓄積するデータ量は、映像配信の開始時に決定され、可用帯域の変化に応じて動的に変更することができない。すなわち、再生開始時に設定した再生バッファに蓄積するデータ量が小さい場合、再生途中でネットワークの品質が悪化すると、安定した映像の再生ができなくなる可能性がある。

逆に、再生開始時に設定した再生バッファに蓄積するデータ量が大きい場合、再生途中でネットワークの品質が改善しても、再生開始時に設定した再生バッファに蓄積するデータ量に合わせて映像データのバッファリングが継続される。つまり、映像データのエンコードレートを上昇させることができず、再生開始時と同様の低品質な映像データをそのまま配信することになる。また、クライアントのリソースを無駄に消費するという課題を有している。

以上のような課題を解決し、高品質かつ安定した映像配信を実現するためには、可用帯域の変化に合わせて、映像の再生開始後も再生バッファに蓄積するデータ量およびエンコードレートの双方を調整することのできる機能が必要である。この機能を実現するためには、映像配信サーバにおいて、指定したエンコードレートで映像データをトランスコードできるようにするだけでなく、映像配信サーバにおいて、映像データをトランスコードする速度（トランスコード速度）を変化させる技術が必要である。エンコードレートは、再生バッファに蓄積されるデータ量を変化させるパラメータであり、映像データの１つのフレーム当たりのデータ量に関するパラメータである。例えば、エンコードレートが低い場合、画質は悪くなり、エンコードレートが高い場合、画質は良くなる。また、トランスコード速度は、再生バッファに蓄積されるデータ量を変化させるパラメータであり、映像データの単位時間当たりの送信速度に関するパラメータである。ここで、トランスコード速度について説明する。

図１は、トランスコード速度を説明するための図である。図１の（ａ）は、３０ｆｐｓの映像コンテンツを示す図であり、１秒間に３０個の連続するフレームが並んでいることを示す。図１の（ｂ）は、２倍のトランスコード速度でトランスコードしている状態を示す図である。図１の（ｃ）は、再生バッファに蓄積するデータ量を示す図である。

図１の（ｂ）に示される２倍のトランスコード速度とは、例えば、２倍にする前の元々のトランスコード速度を３０ｆｐｓの映像コンテンツの再生速度と同じ速度とすると、元々の速度は、１秒間に３０フレーム分トランスコードする速度となり、２倍の速度は、１秒間に６０フレーム分トランスコードする速度となる。このように、トランスコード速度を早くすることで、映像配信サーバからクライアントへの映像データの単位時間当たりの送信速度が速くなり、再生バッファに蓄積するデータ量を増やすことができる。

なお、再生バッファに蓄積するデータ量および後述する目標バッファデータ量とは、バッファアンダーフローが発生するまでの時間を意味する。

例えば、ネットワークの状況が悪化し、再生バッファに蓄積するデータ量を増大させなければバッファアンダーフローが発生するような状況では、映像配信サーバは、トランスコード速度が映像の再生速度よりも速くなるように、トランスコードを行う。例えば、映像配信サーバは、図１の（ｂ）に示されるように、２倍の速度でトランスコードを行う。これにより、クライアントが再生するよりも早く、映像データの配信が行われるため、図１の（ｃ）に示されるように再生バッファに蓄積する映像データ量を増やすことができる。具体的には、トランスコード速度を２倍にする前には、再生バッファに蓄積するデータ量は１秒分のデータだったものが、トランスコード速度を２倍にすることで、再生バッファに蓄積するデータ量は２秒分のデータとなる。ただし、トランスコード速度を早くすることで、１つのフレーム当たりのデータ量が低下し（つまり画質が劣化し）、低いエンコードレートのデータが送信されることになる。また、ネットワークの状況が改善し再生バッファに蓄積するデータ量が多すぎる場合には、映像配信サーバは、再生速度よりも遅い速度に、トランスコード速度を設定する。これにより、再生バッファに蓄積するデータ量を削減するとともに可用帯域の範囲内でより高いエンコードレートのデータを送信することが可能となる。

エンコードレートとトランスコード速度とのどちらも変更可能なシステムとしては特許文献１があげられる。

特許文献１に記載の構成において、クライアントは、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＧＥＴリクエストを用いて、分割された映像ストリームをシーケンシャルに取得する。また、トランスコード速度の指定は、ＨＴＴＰセッションの間で、セッション開始時の１回しか行われない。一般的に、無線通信を用いる場合には、可用帯域はセッションの間においても急激に変化する。しかしながら、特許文献１に記載の方法では、ＨＴＴＰセッションの間に可用帯域が例えば急激に減少するような状況において、トランスコード速度を変更し、再生バッファに蓄積するデータ量を増やすことができず、再生バッファに蓄積されたデータが枯渇し、再生が停止してしまう。また、可用帯域の変化を検出する方法についても問題がある。特許文献１に記載の構成におけるネットワークの可用帯域の変化の推定方法は、映像送信サーバにおいてトランスコーダから送信スタックにデータが渡される時間間隔を利用して推定する方法となっている。しかし、この方法では、推定結果が映像送信サーバ側の送信バッファの挙動に影響を受けるため、実際のネットワークの可用帯域を、素早く正確に推定することができない。したがって、可用帯域の変化に応じて正確にトランスコード速度を変更できない。

そこで、本発明の映像制御装置は、サーバ装置から送信された映像データを受信する映像制御装置であって、サーバ装置でトランスコードされ、ネットワークを介して受信した映像データを蓄積する再生バッファと、再生バッファから読み出した映像データをデコードするデコーダと、ネットワークの所定時間後の可用帯域を推定し、推定した所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した目標バッファデータ量と、再生バッファに蓄積されたデータ量とを用いて、再生バッファに蓄積されるデータ量を変化させるパラメータである、映像データの単位時間当たりの送信速度に関するトランスコード速度と、映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する決定部と、決定部が決定したトランスコード速度およびエンコードパラメータを、サーバ装置に対して送信する通信部と、を備える。

これにより、ネットワークの可用帯域の変動を推定して、可用帯域の変動に応じて必要となる目標バッファデータ量と現在再生バッファに蓄積されたデータ量との差に基づいたトランスコード速度とエンコードパラメータとを決定することが可能となる。例えば、目標バッファデータ量と現在の再生バッファに蓄積されたデータ量との差が大きい場合、再生バッファに蓄積されたデータが枯渇しないようにトランスコード速度を速くする。また、目標バッファデータ量と現在の再生バッファに蓄積されたデータ量との差が小さい場合、再生バッファに蓄積されたデータ量に余裕があるため、エンコードレートの高い映像データを再生することができる。このように、本発明の映像制御装置は、ネットワークの帯域変化により適切に対応できる。

また、決定部は、ネットワークの可用帯域を所定のタイミング毎に計測し、計測した所定のタイミング毎の可用帯域の変化を用いて、所定時間後の可用帯域を推定してもよい。

これにより、所定のタイミング毎に計測した可用帯域の変化を用いて、容易にネットワークの可用帯域の変動を推定できる。

また、決定部は、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下の速度を示す低下係数を用いて、所定時間後の可用帯域を推定してもよい。

これにより、所定のタイミング毎に計測した可用帯域の変化に基づく低下係数を用いて、容易にネットワークの可用帯域の変動を推定できる。

また、決定部は、サーバ装置との間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）と低下係数とを用いて、所定時間後の可用帯域を推定してもよい。

これにより、ＲＴＴと低下係数とを用いて、容易にネットワークの可用帯域の変動を推定できる。

また、決定部は、所定時間後の可用帯域と、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下が継続する時間を示す低下継続係数と、サーバ装置との間のＲＴＴとを用いて、目標バッファデータ量を決定してもよい。

これにより、推定した可用帯域と低下継続係数とＲＴＴとを用いて、容易に目標バッファデータ量を決定できる。

また、通信部は、決定部が決定したトランスコード速度を、１回の確立されたコネクションの間に、複数回送信してもよい。

これにより、１回の確立されたコネクションの間に可用帯域が急激に変化するような状況においても、ネットワークの帯域変化により適切に対応できる。

また、さらに、通信部からネットワークの通信環境に関する通信環境情報を取得し、通信環境情報に基づいてネットワークの通信環境の変化が一時的な変化であるか否かを判断する通信環境観測部を有し、決定部は、通信環境観測部が通信環境の変化が一時的な変化であると判断した場合には目標バッファデータ量を変更せず、一時的な変化でないと判断した場合には目標バッファデータ量を変更してもよい。

これにより、一時的なネットワークの変化に対して目標バッファデータ量の制御を行うことが抑制され、再生バッファに蓄積するデータ量を不必要に伸ばす制御が抑制される。したがって、トランスコード速度が不必要に上昇させられることが抑制され、その結果、エンコードレートが不必要に下げられて映像配信の品質が劣化することが抑制される。

また、通信環境観測部は、通信環境情報としてＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）を所定間隔で取得し、ＲＳＳＩが、予め定められた複数の閾値の範囲のうち前回取得したＲＳＳＩと同じ閾値の範囲内にある場合に、通信環境の変化が一時的な変化であると判断してもよい。

これにより、通信環境情報としてＲＳＳＩを取得することで、通信環境の変化が一時的な変化であるか否かを容易に判断できる。

本発明の映像制御方法は、ネットワークを介してサーバ装置から送信された映像データを受信する映像制御装置における映像制御方法であって、映像制御装置は、受信した映像データを蓄積する再生バッファと、再生バッファから読み出した映像データをデコードするデコーダと、を備え、映像制御方法は、記ネットワークの可用帯域を所定のタイミング毎に計測するステップと、計測するステップで計測した所定のタイミング毎の可用帯域の変化を用いて、ネットワークの所定時間後の可用帯域を推定し、推定した所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定するステップと、目標バッファデータ量と再生バッファに蓄積されたデータ量とを用いて、再生バッファに蓄積するデータ量を変化させるパラメータである、映像データの単位時間当たりの送信速度に関するトランスコード速度と、映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定するステップと、トランスコード速度およびエンコードパラメータを、サーバ装置に対して送信するステップと、を含む。

これにより、ネットワークの可用帯域の変動を推定して、可用帯域の変動に応じて必要となる目標バッファデータ量と現在再生バッファに蓄積されたデータ量との差に基づいたトランスコード速度とエンコードパラメータとを決定することが可能となる。したがって、ネットワークの帯域変化により適切に対応できる。

本発明の映像配信システムは、サーバ装置に蓄積された映像データを、ネットワークを介して、クライアントに配信する映像配信システムであって、映像データをトランスコードするトランスコーダと、トランスコーダがトランスコードした映像データを送信する第１の通信部と、第１の通信部が送信した映像データを受信する第２の通信部と、第２の通信部が受信した映像データを蓄積する再生バッファと、再生バッファから読み出した映像データをデコードするデコーダと、ネットワークの所定時間後の可用帯域を推定し、推定した所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した目標バッファデータ量と、再生バッファに蓄積されたデータ量とを用いて、再生バッファに蓄積するデータ量を変化させるパラメータである、映像データの単位時間当たりの送信速度に関するトランスコード速度と、映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する決定部と、を備え、トランスコーダは、決定部が決定したトランスコード速度とエンコードパラメータとを用いて映像データをトランスコードする。

これにより、ネットワークの可用帯域の変動を推定して、可用帯域の変動に応じて必要となる目標バッファデータ量と現在再生バッファに蓄積されたデータ量との差に基づいたトランスコード速度とエンコードパラメータとを決定することが可能となる。したがって、ネットワークの帯域変化により適切に対応できる。

以下、本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
実施の形態１について、図２から図６を用いて説明する。

図２は、実施の形態１における映像配信システム１０の構成の一例を示す図である。具体的には、図２は、映像配信サーバ１００（サーバ装置）とクライアント２００（映像制御装置）との相互の接続関係を示す図である。

映像配信サーバ１００とクライアント２００とは、ネットワーク３００を介して接続している。映像配信サーバ１００は、ネットワーク３００を介して、映像データをクライアント２００に対して送信する。クライアント２００は、ネットワーク３００を介して、映像配信サーバ１００に制御信号を送信する。制御信号の詳細は、後述する。

映像配信サーバ１００は、送信する映像データをネットワーク３００の変化する可用帯域に合わせて粒度の細かい制御を行うため、トランスコーダによって映像データを逐次トランスコードして、クライアント２００に送信する。映像配信サーバ１００は、トランスコードの際に、Ｈ．２６４やＭＰＥＧ２といったエンコードレートの制御が可能な圧縮データ形式を用いる。なお、映像データの形式は、エンコードレートの制御が可能ものであれば何でもよい。

映像配信サーバ１００とクライアント２００とは、互いに送受信する映像データおよび制御信号を、信頼性のあるプロトコル（例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ））を用いて通信する。なお、本実施の形態において、映像データおよび制御信号の通信に用いられるプロトコルは、信頼性が確保されたプロトコルであれば何でもよい。例えば、ファイヤーウォールやＰｒｏｘｙの透過性を満たすためにＨＴＴＰを用いてもよいし、データをチャンク単位で扱えるＷｅｂｓｏｃｋｅｔを用いてもよい。

ネットワーク３００は、インターネット又は無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのベストエフォートネットワークを用いる。なお、ネットワーク３００は、社内ネットワークなどのイントラネットを含んでもよいし、ＷｉＭＡＸ（登録商標）やＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）といった公衆無線を用いてもよい。

まず、映像配信サーバ１００の詳細について図３を用いて説明する。

図３は、実施の形態１における映像配信サーバ１００の構成の一例を示す図である。

映像配信サーバ１００は、エンコードパラメータ指定部１０２、トランスコード速度指定部１０３、映像ソース１０６、トランスコーダ１０７及び第１の通信部１１０を備える。

エンコードパラメータ指定部１０２は、エンコードレートなどを含むエンコードパラメータに関する指示を第１の通信部１１０から通知され、エンコードパラメータをトランスコーダ１０７に指定する。

トランスコード速度指定部１０３は、トランスコーダ１０７の動作速度（トランスコード速度）に関する指示を第１の通信部１１０から通知され、トランスコード速度をトランスコーダ１０７に指定する。

映像ソース１０６は、映像配信サーバ１００が備える記憶部（図示せず）に記憶された映像ソースであって、トランスコーダ１０７に映像データを読み出される。

トランスコーダ１０７は、映像ソース１０６から、映像変換処理前の映像データの読み出しを行い、異なるビットレート（エンコードレート）の映像データへの変換（トランスコード）を行う。トランスコーダ１０７は、変換処理の際に、１つのフレーム当たりのデータ量に関するエンコードレートなどを含むエンコードパラメータがエンコードパラメータ指定部１０２により指定されるとともに、トランスコード速度指定部１０３によりトランスコーダ１０７の動作速度（単位時間当たりの送信速度に関するトランスコード速度）が指定される。これにより、トランスコーダ１０７は、後述する決定部２２０が決定したトランスコード速度とエンコードパラメータとを用いて映像データをトランスコードする。ここで、トランスコーダ１０７の動作速度について説明する。

トランスコーダ１０７の動作速度とは、ある映像コンテンツの一部分を通常再生するために必要な時間を、その一部分をエンコードするために必要な時間で除したものである。具体的には、再生に１０秒かかるコンテンツのエンコードを５秒で完了するようなトランスコーダ１０７の動作速度は、図１の（ｂ）で説明したように、２倍となる。逆に、再生に１０秒かかるコンテンツのトランスコードを２０秒かけて完了するようなトランスコーダ１０７の動作速度は、０．５倍となる。エンコードパラメータおよびトランスコード速度は、クライアント２００からの指示により決定される。

第１の通信部１１０は、ネットワーク３００を介してクライアント２００と映像データおよび制御信号の通信を行う。第１の通信部１１０は、命令受信部１０４と通信スタック１０５とを備える。つまり、第１の通信部１１０は、これらの構成要素に対応し、これらの構成要素の役割を担う。

通信スタック１０５は、制御信号としてエンコードパラメータおよびトランスコード速度に関する指示を、クライアント２００から受信し、命令受信部１０４に通知する。命令受信部１０４は、通知されたエンコードパラメータおよびトランスコード速度に関する指示を、エンコードパラメータ指定部１０２およびトランスコード速度指定部１０３に対して通知する。

そして、トランスコーダ１０７は、エンコードパラメータ指定部１０２及びトランスコード速度指定部１０３に指定されたパラメータで変換処理（トランスコード）した後の映像データを、通信スタック１０５に通知し、通信スタック１０５（第１の通信部１１０）はトランスコーダ１０７がトランスコードした映像データをクライアント２００に送出（送信）する。また、通信スタック１０５は、後述するクライアント２００から受信した帯域推定に利用するプローブパケットに対しての返答機能を有する。

次に、クライアント２００の詳細について、図４を用いて説明する。

図４は、実施の形態１におけるクライアント２００の構成の一例を示す図である。

クライアント２００は、再生バッファ２０８、デコーダ２０９、通信部（第２の通信部）２１０及び決定部２２０を備える。

通信部２１０は、ネットワーク３００を介して映像配信サーバ１００と映像データおよび制御信号の通信を行う。通信部２１０は、通信スタック２０２と命令送信部２０３とを備える。つまり、通信部２１０は、これらの構成要素に対応し、これらの構成要素の役割を担う。

通信スタック２０２（通信部２１０）は、映像配信サーバ１００から配信された（第１の通信部１１０が送信した）映像データを受信する。命令送信部２０３は、後述する決定部２２０から通知されたエンコードパラメータおよびトランスコード速度に関する指示を通信スタック２０２に対して通知する。

再生バッファ２０８は、映像配信サーバ１００でトランスコードされ、ネットワーク３００を介して通信スタック２０２（通信部２１０）が受信した映像データを一時的に蓄積する。

デコーダ２０９は、再生バッファ２０８から読み出した映像データをデコードする。デコーダ２０９は、再生バッファ２０８に一定量の映像データが蓄積されると、映像の再生を開始する。映像の再生が開始されると、デコーダ２０９は、再生バッファ２０８から一定の速度で映像データを読み出し続け、映像の再生が終了するまで映像のデコードを続ける。

決定部２２０は、トランスコード速度決定部２０４、エンコードパラメータ決定部２０５、帯域推定部２０６および目標バッファデータ量決定部２０７を備える。つまり、決定部２２０は、これらの構成要素に対応し、これらの構成要素の役割を担う。決定部２２０は、ネットワーク３００の所定時間後の可用帯域を推定し、推定した所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定する。そして、決定部２２０は、決定した目標バッファデータ量と、再生バッファ２０８に蓄積されたデータ量とを用いて、再生バッファ２０８に蓄積するデータ量を変化させるパラメータである、映像データの単位時間当たりの送信速度に関するトランスコード速度と、映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する。

帯域推定部２０６は、通信スタック２０２によって受信された映像データの受信間隔情報若しくは受信レート、又は、映像配信サーバ１００との間のＲＴＴ等を用いてネットワーク３００の可用帯域を計算する。帯域推定部２０６は、通信部２１０から映像配信サーバ１００の第１の通信部１１０に対して送信したプローブパケットの送信時間と、プローブパケットに対しての返信メッセージの受信時間とから、ＲＴＴを計測する。

ここで、帯域計算の方法について詳細に説明する。クライアント２００から映像配信サーバ１００に対して定期的にプローブパケットを送信し、映像配信サーバ１００側からはそのプローブパケットに呼応する形での応答パケットが返信される。応答パケットは、映像データとは別のパケットであってもよいし、映像ストリームデータのヘッダにメッセージを書き込む方法等により実現してもよい。これにより、プローブパケットを送信してから応答メッセージを受信するまでの間の時間をＲＴＴとして計測することができる。時系列上でＲＴＴが増加している場合にはネットワーク３００の可用帯域に対して配信を行おうとしている映像のエンコードレートが高く、ＲＴＴが低下している場合には可用帯域に対して映像のエンコードレートが低い状態であるということが言える。帯域推定部２０６が計測したＲＴＴの観測値は、ネットワーク３００の可用帯域が配信映像のエンコードレートを下回った場合に直ちに変化するため、アプリケーションからネットワーク３００の可用帯域の変化を瞬時に精度良く観測することができる。

目標バッファデータ量決定部２０７は、帯域推定部２０６で推定されたネットワーク３００の可用帯域、その統計情報、再生バッファ２０８内に蓄積されている映像データの残量情報を利用して現在のネットワーク環境で安定再生に必要な、再生バッファ２０８に蓄積する目標のデータ量（目標バッファデータ量とも呼ぶ）を逐次計算する。

トランスコード速度決定部２０４とエンコードパラメータ決定部２０５とは、再生バッファ２０８内に蓄積された映像データの量を目標バッファデータ量決定部２０７が決定した目標バッファデータ量となるように、トランスコード速度とエンコードパラメータとを決定する。

そして、通信スタック２０２は、映像配信サーバ１００に命令送信部２０３を介して通知された制御信号を送信する。具体的には、通信部２１０（通信スタック２０２）は、決定部２２０が決定したトランスコード速度およびエンコードパラメータを、サーバ装置（映像配信サーバ）１００に対して送信する。

また、映像の配信を開始する際には、クライアント２００を利用するユーザあるいはコンテンツの配信に関する設定ファイルにより最小再生バッファデータ量、最低エンコードレート、最高エンコードレートおよび最高トランスコード速度が予め決定される。最小再生バッファデータ量、最低エンコードレート、最高エンコードレートおよび最高トランスコード速度は、例えばクライアント２００が備える記憶部（図示せず）にそれぞれ保存される。

次に、可用帯域の測定および統計値の計算から目標バッファデータ量の計算を行い、トランスコード速度およびエンコードパラメータを算出するまでの処理について詳細に説明する。

まず、可用帯域の測定および統計値の計算について図５を用いて説明する。

図５は、実施の形態１におけるクライアント２００が可用帯域の推定を行うための動作の一例を示すフローチャートである。

まず、帯域推定部２０６は、タイマにより起動される（ステップＳ３０１）。帯域推定部２０６は、所定のタイミング毎に起動し、図５に示されるステップＳ３０１からステップＳ３０９の処理を所定のタイミング毎に行う。所定のタイミングは、例えば０．１秒毎のタイミングである。

次に、帯域推定部２０６は、映像配信サーバ１００とのＲＴＴの計測データ又は受信レート等から現在のネットワーク３００の可用帯域を計算する（ステップＳ３０２）。本実施の形態では、帯域推定部２０６は、例えば、映像配信サーバ１００とのＲＴＴの計測データから現在のネットワーク３００の可用帯域を計算する。帯域推定部２０６は、ネットワーク３００の可用帯域を上述した所定のタイミング毎に計算する。

次に、帯域推定部２０６は、ステップＳ３０２で所定のタイミング毎に計算している可用帯域のうち、前回計算した可用帯域と今回計算した可用帯域との比較を行い、可用帯域が低下しているか否かを判定する（ステップＳ３０３）。例えば、０．１秒前に計算した可用帯域と今回計算した可用帯域とが比較される。

帯域推定部２０６が、可用帯域が低下していると判定した場合（ステップＳ３０３でＹＥＳ）、ステップＳ３０４の処理が行われる。

帯域推定部２０６は、可用帯域の低下率を計算する（ステップＳ３０４）。可用帯域の低下率は、次式のように表される。

低下率＝（今回計算した可用帯域−前回計算した可用帯域）／（ｉ×サンプリング間隔）

ここで、ｉは正の実数である。

具体的には、サンプリング間隔（所定のタイミング毎の間隔）を０．１秒としｉの値を５とした環境で、前回計算した可用帯域が５Ｍｂｐｓ、今回計算した可用帯域が４Ｍｂｐｓであったとき、低下率は次式のように計算できる。

低下率＝（４Ｍｂｐｓ−５Ｍｂｐｓ）／（５×０．１）＝−２

次に、帯域推定部２０６は、低下時間継続カウンタを更新する（ステップＳ３０５）。低下時間継続カウンタとは、現在の可用帯域の低下がどれだけの期間継続しているかを表す変数であり、次式に基づいて計算できる。

低下時間継続カウンタの値＝前回の低下時間継続カウンタの値＋前回計算時からの差分時間

具体的には、前回の低下時間継続カウンタの値が１．５秒であり、前回計測時からの差分時間（所定のタイミング毎の間隔）が０．１秒であったときには、低下時間継続カウンタの値は１．６秒に更新される。

一方、帯域推定部２０６が、可用帯域が低下していないと判定した場合（ステップＳ３０３でＮＯ）、ステップＳ３０６の処理が行われる。帯域推定部２０６は、可用帯域の低下が起こっていなかったため、低下時間持続カウンタの値をリセットし、帯域の低下率を１にセットする（ステップＳ３０６）。

そして、帯域推定部２０６は、ステップＳ３０４〜ステップＳ３０６で計算された低下率および低下時間継続カウンタの値を用いて低下係数および低下継続係数を更新する（ステップＳ３０７）。低下係数は、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下の速度を示す係数である。具体的には、低下係数は、帯域推定部２０６が可用帯域を計算し、計算した可用帯域を統計処理することにより、１秒間にどのくらいネットワーク３００の可用帯域が低下するかを示す係数であり、ネットワーク３００の不安定さを示す統計値である。低下継続係数は、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下が継続する時間を示す係数である。具体的には、低下継続係数は、可用帯域の低下がどの程度の時間にわたって継続して起こるかを示す係数であり、低下係数と同様にネットワーク３００の不安定さを示す統計値である。低下係数および低下継続係数は、例えばクライアント２００が備える記憶部に記憶され、後述する目標バッファデータ量の決定やトランスコード速度の決定の際に利用される。

低下係数の更新には次式が用いられる。

低下係数の更新値＝前回の低下係数×（１−ｋ）＋低下率×ｋ

また、低下継続係数の更新には次式が用いられる。

低下継続係数の更新値＝前回の低下継続係数×（１−ｋ）＋低下時間継続カウンタの値×ｋ

ここで、ｋは（０＜ｋ＜１）の実数であり、ｋの値を調整することにより過去のネットワーク３００の変動がどの程度低下係数および低下継続係数に影響を与えるかを調整することができる。

具体的には、例えばｋの値を０．１に設定した場合、前回の低下係数が−４で今回の低下率が−２であったとすると、低下係数の更新値は次式のように計算できる。

低下係数の更新値＝（−４）×０．９＋（−２）×０．１＝−３．８

また、例えば低下時間継続カウンタの値が０．５で前回の低下継続係数が１．５であったとすると、低下継続係数の更新値は次式のように計算できる。

低下継続係数の更新値＝１．５×０．９＋０．５×０．１＝１．４

次に、帯域推定部２０６は、今回計算した可用帯域の値を保存する（ステップＳ３０８）。今回計算した可用帯域の値は、例えばクライアント２００が備える記憶部（図示せず）に保存される。また、帯域推定部２０６は、ＲＴＴの計測データを記憶部に記憶する。

そして、クライアント２００が可用帯域の推定を行うための動作は終了する（ステップＳ３０９）。

このように、クライアント２００が可用帯域の推定を行うための動作として、低下係数と低下継続係数とが所定のタイミング毎に更新される。

次に、目標バッファデータ量決定部２０７における目標バッファデータ量の算出手順とトランスコード速度決定部２０４およびエンコードパラメータ決定部２０５におけるエンコードパラメータとトランスコード速度との決定方法について説明する。

図６は、実施の形態１におけるクライアント２００がトランスコード速度とエンコードパラメータとを決定する動作の一例を示すフローチャートである。

まず、目標バッファデータ量決定部２０７、トランスコード速度決定部２０４およびエンコードパラメータ決定部２０５は、タイマにより起動される（ステップＳ４０１）。目標バッファデータ量決定部２０７、トランスコード速度決定部２０４およびエンコードパラメータ決定部２０５は、図５に示される処理とは異なるタイミングで起動される。例えば、図５に示される処理の後に（ステップＳ３０９の後に）、ステップＳ４０１の処理が開始される。

次に、目標バッファデータ量決定部２０７は、記憶部から最新の可用帯域のデータおよび映像配信サーバ１００とのＲＴＴの計測データを取得する（ステップＳ４０２）。最新の可用帯域のデータおよびＲＴＴの計測データは、ステップＳ３０８において保存されたデータである。

次に、目標バッファデータ量決定部２０７は、配信開始の際に予め決定した最低エンコードレートよりもステップＳ４０２において取得した可用帯域の値が大きいか否かを判定する（ステップＳ４０３）。

目標バッファデータ量決定部２０７が、可用帯域が最低エンコードレートよりも大きいと判定した場合（ステップＳ４０３でＹＥＳ）、ステップＳ４０４の処理が行われる。

目標バッファデータ量決定部２０７は、低下係数および低下継続係数を取得する（ステップＳ４０４）。例えば、目標バッファデータ量決定部２０７は、ステップＳ３０７で更新された低下係数および低下継続係数をクライアント２００の記憶部から取得する。

次に、目標バッファデータ量決定部２０７は、目標バッファデータ量を決定する（ステップＳ４０５）。目標バッファデータ量は、理想的にはネットワーク３００の可用帯域が低下して映像データの到着が遅延した場合においても、映像の再生を停止させないためにクライアント２００の再生バッファ２０８が持つべき最低限のデータ量である。すなわち、想定されるネットワーク３００の可用帯域の低下を算出し（つまり所定時間後の可用帯域を推定し）、その際に発生する映像データ到着の遅延を計算することができれば、その遅延の値を目標バッファデータ量とすればよいことがわかる。

まずは、ネットワーク３００の所定時間後の可用帯域の推定方法について説明する。本発明の映像配信システム１０では、映像配信サーバ１００とクライアント２００との間のメッセージングによって可用帯域の推定とトランスコーダ１０７の制御を行う。そのため、ネットワーク３００で可用帯域の変化が発生してから帯域の変化を検知し可用帯域に合わせたエンコードレートにトランスコーダ１０７を制御するまでには所定の時間がかかる。所定の時間は例えば１ＲＴＴとなる。ここで、ステップＳ４０４で取得した低下係数は、１秒間に起こる可用帯域の低下率の統計値であることから、１ＲＴＴの間に発生する可用帯域の想定低下帯域は次式のように計算できる。

想定低下帯域＝最新の可用帯域×（（１−ＲＴＴ）＋低下係数×ＲＴＴ）

ただし想定低下帯域＜０となる場合には、想定低下帯域を０．０１とする。

具体的な例を挙げると、例えば、ステップＳ４０２で取得した最新の可用帯域が４ＭｂｐｓでＲＴＴが０．１秒、低下係数が−３．８のとき想定低下帯域は次式のように計算できる。

想定低下帯域＝４Ｍｂｐｓ×（（１−０．１）−３．８×０．１）≒２．１Ｍｂｐｓ

これにより、所定時間後の可用帯域（１ＲＴＴ後の可用帯域）は４Ｍｂｐｓ−２．１Ｍｂｐｓ＝１．９Ｍｂｐｓと推定される。

なお、ステップＳ４０１からステップＳ４０５における所定時間後の可用帯域の推定までの処理を帯域推定部２０６が行ってもよい。つまり、帯域推定部２０６は、ステップＳ３０１からステップＳ３０９までの処理およびステップＳ４０１からステップＳ４０５における所定時間後の可用帯域の推定までの処理を行ってもよい。さらに言い換えると、帯域推定部２０６および目標バッファデータ量決定部２０７が構成する決定部２２０がステップＳ３０１からステップＳ３０９までの処理およびステップＳ４０１からステップＳ４０５における所定時間後の可用帯域の推定までの処理を行ってもよい。

このように、決定部２２０は、ネットワーク３００の可用帯域を所定のタイミング毎に計測し、所定のタイミング毎の可用帯域の変化を用いて、所定時間後の可用帯域を推定する。具体的には、決定部２２０は、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下の速度を示す低下係数を用いて、所定時間後の可用帯域を推定する。より具体的には、決定部２２０は、サーバ装置（映像配信サーバ１００）との間のＲＴＴと低下係数とを用いて、所定時間後の可用帯域を推定する。

ここで、帯域低下が発生する前のエンコードレートが最新の可用帯域に等しいと仮定した場合、１ＲＴＴの間の可用帯域の低下によって発生する映像データの到着遅延は次式で計算できる。

１ＲＴＴの間に発生する映像データの到着遅延＝（（最新の可用帯域−想定低下帯域）×ＲＴＴ／２）／想定低下帯域

具体例として上述した最新の可用帯域、想定低下帯域およびＲＴＴを用いると、１ＲＴＴの間に発生する映像データの到着遅延は次式のように計算できる。

１ＲＴＴの間に発生する映像データの到着遅延＝（（４Ｍｂｐｓ−２．１Ｍｂｐｓ）×０．１／２）／２．１≒０．０４５．．秒

ここで、ステップＳ４０４において取得した低下継続係数が可用帯域の低下が継続する時間の統計値であることから、低下継続係数を用いると、ネットワーク３００の想定される可用帯域の低下によって発生する映像データの到着遅延、すなわち目標バッファデータ量は次式のように導出することができる。

目標バッファデータ量＝１ＲＴＴの間に発生する映像データの到着遅延／ＲＴＴ×低下継続係数

低下継続係数が３であったとし、１ＲＴＴの間に発生する映像データの到着遅延が上述した０．４５秒とすると、目標バッファデータ量は次式のように計算できる。

目標バッファデータ量＝０．０４５．．／０．１×３≒１．３５秒

このようにして、決定部２２０は、所定時間後の可用帯域と、所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下が継続する時間を示す低下継続係数と、サーバ装置（映像配信サーバ１００）との間のＲＴＴとを用いて、目標バッファデータ量を決定する。

次に、目標バッファデータ量決定部２０７は、再生バッファ２０８に蓄積されたデータ量の計測および取得を行う（ステップＳ４０６）。

次に、トランスコード速度決定部２０４は、トランスコード速度を決定する（ステップＳ４０７）。

次に、エンコードパラメータ決定部２０５は、エンコードパラメータを決定する（ステップＳ４０８）。

ステップ４０７とステップ４０８とでは、目標バッファデータ量および低下係数から、それぞれトランスコード速度およびエンコードパラメータの決定を順に行う。トランスコード速度と再生バッファ２０８のデータ量の増減とは正の相関関係にあり、トランスコード速度を大きくすれば大きくするほど再生バッファ２０８のデータ量を素早く増大させ、目標バッファデータ量に素早く到達することができる。しかし、トランスコード速度、ネットワーク３００の可用帯域および映像のエンコードレートには、ネットワーク３００の可用帯域が十分に活用され、かつ、映像データの到着遅延がない場合には次式の関係にある。

トランスコード速度×エンコードレート＝可用帯域

上式から明らかなように、トランスコード速度が大きくなればなるほど、エンコードレートは小さくしなければならない。すなわち、再生バッファ２０８のデータ量を素早く伸ばすことに注力するあまりトランスコード速度を早くしすぎると、エンコードレートが低くなり低画質な映像を配信することになってしまい配信品質が劣化する。そこで、トランスコード速度とエンコードレートとのトレードオフの関係から最適点を見つけ出す。具体的には、ステップＳ４０５で決定した目標バッファデータ量とステップＳ４０６で取得した現在の再生バッファ２０８に蓄積されたデータ量との間の差、および、ネットワーク３００の不安定さという２つの要素が利用される。すなわち、目標バッファデータ量と現在の再生バッファ２０８に蓄積されたデータ量との差が小さい場合や、ネットワーク３００が比較的安定している場合には、再生バッファ２０８に蓄積するデータ量が目標バッファデータ量へ緩やかに適応するようにトランスコード速度を決定する。また、目標バッファデータ量と現在の再生バッファ２０８に蓄積されたデータ量との差が大きい場合や、ネットワーク３００が不安定な場合には、再生バッファ２０８に蓄積するデータ量が目標バッファデータ量へ速やかに適応するようにトランスコード速度を決定する。ここで、ネットワーク３００の不安定さを示す統計値としてステップＳ４０４で取得した低下係数を利用すると、本実施の形態において、次式を用いて仮のトランスコード速度を決定することができる。ここで、トランスコード速度には許容範囲があり、次式を用いて計算したトランスコード速度が、許容範囲内にないことがあるため、いったん仮のトランスコード速度としている。

仮のトランスコード速度＝１＋（目標バッファデータ量−現在のバッファデータ量）×ｍ×（１．０１−低下係数）

ここでｍは正の実数であり、例えばｍ＝０．１程度の値が用いられる。

目標バッファデータ量を１．５秒、現在のバッファデータ量を１秒、低下係数を−２とし、ｍを０．１としたときの仮のトランスコード速度は次式のように計算できる。

仮のトランスコード速度＝１＋（１．５−１．０）×０．１×（１．０１＋２）≒１．１５

計算した仮のトランスコード速度は、映像の配信を開始する際に予め決定した最高トランスコード速度と比較される。つまり、上述したトランスコード速度の許容範囲は、０から最高トランスコード速度の範囲のことである。

仮のトランスコード速度が最高トランスコード速度よりも大きい場合、トランスコード速度は最高トランスコード速度になる。また、仮のトランスコード速度が０以上、最高トランスコード速度以下の場合、トランスコード速度は計算した仮のトランスコード速度になる。また、仮のトランスコード速度が０より小さい場合、トランスコード速度は０になる。

このように、ステップＳ４０７では、トランスコード速度が決定される。

次に、ステップＳ４０８では、エンコードパラメータの決定が行われる。

まず、エンコードパラメータとして仮のエンコードレートが次式のように決定される。ここで、エンコードレートには許容範囲があり、次式を用いて計算したエンコードレートが、許容範囲内にないことがあるため、いったん仮のエンコードレートとしている。

仮のエンコードレート＝可用帯域／トランスコード速度

計算した仮のエンコードレートは、映像の配信を開始する際に予め決定した最低エンコードレートおよび最高エンコードレートと比較される。つまり、上述したエンコードレートの許容範囲は、最低エンコードレートから最高エンコードレートの範囲のことである。

仮のエンコードレートが最高エンコードレートよりも大きい場合、エンコードレートは最高エンコードレートになる。仮のエンコードレートが最低エンコードレートよりも小さい場合、エンコードレートは最低エンコードレートになる。仮のエンコードレートが最低エンコードレート以上最高エンコードレート以下の場合、エンコードレートは計算した仮のエンコードレートになる。

なお、ステップＳ４０８で決定されるエンコードパラメータはエンコードレートに限らない。例えば、エンコードレートの関数として解像度が、エンコードパラメータとして決定されてもよい。また、トランスコーダ１０７に固有のパラメータが、決定されたトランスコード速度やエンコードレートをもとに、エンコードパラメータとして決定されてもよい。

一方、目標バッファデータ量決定部２０７が、可用帯域が最低エンコードレートよりも小さいと判定した場合（ステップＳ４０３でＮＯ）、ステップＳ４０９の処理が行われる。可用帯域が最低エンコードレートよりも小さい場合に、エンコードレートを映像の配信を開始する際に決定した最低エンコードレートに設定したとしても、リアルタイムエンコーディングを行うと必ず映像データの到着遅延が発生する。また、最低エンコードレートでリアルタイムエンコーディングを行った場合、ネットワーク３００上に滞留する映像データが増大し正確な帯域推定を行うことが困難となる。そこで、ステップＳ４０９およびステップＳ４１０では、ネットワーク３００上にデータが滞留しないようなエンコードパラメータおよびトランスコード速度の決定を行う。

エンコードパラメータ決定部２０５は、エンコードレートを最低エンコードレートに決定する（ステップＳ４０９）。なお、ステップＳ４０８と同様に、解像度等の他のパラメータが、エンコードパラメータとして決定されてもよい。

次に、トランスコード速度決定部２０４は、トランスコード速度を決定する（ステップＳ４１０）。具体的には、次式を用いてトランスコード速度は決定される。

トランスコード速度＝可用帯域／最低エンコードレート

このように、目標バッファデータ量決定部２０７が、可用帯域が最低エンコードレートよりも小さいと判定した場合には、目標バッファデータ量の算出は行われず、ネットワーク３００上にデータが滞留しないようなエンコードパラメータおよびトランスコード速度が決定される。

そして、通信部２１０は、決定部２２０が決定したエンコードパラメータおよびトランスコード速度を映像配信サーバ１００（サーバ装置）に対して送信する（ステップＳ４１１）。

そして、クライアント２００がトランスコード速度とエンコードパラメータとを決定する動作は終了する（ステップＳ４１２）。

なお、ステップＳ４０１からステップＳ４１２の動作は、所定のタイミング毎に繰り返し行われるため、通信部２１０は、決定部２２０が決定したエンコードパラメータおよびトランスコード速度を、１回の確立されたコネクションの間に、複数回送信することになる。

以上、実施の形態１に開示した映像制御装置２００、映像配信システム１０および映像制御方法を用いて、トランスコード速度およびエンコードパラメータの制御を行うことにより、ネットワーク３００の状況により素早く適応した高品質かつ安定した途切れない映像の配信を実現できる。

（実施の形態２）
次に、実施の形態２について、図７から図９を用いて説明する。

実施の形態１においては、映像配信サーバ１００およびクライアント２００間のメッセージングを利用してネットワーク３００の可用帯域を推定し、可用帯域の統計情報である低下係数および低下継続時間を算出・利用することにより、トランスコード速度およびエンコードパラメータを決定し、トランスコーダ１０７に通知する方法について説明した。実施の形態２では、ネットワーク３００の可用帯域の推定情報のみをトランスコード速度およびエンコードパラメータの決定に用いるのではなく、ネットワークインターフェイス等から取得できるより低レイヤの情報を利用することにより、より効率的かつ安定したエンコードパラメータおよびトランスコード速度の制御を行う方法について説明する。

実施の形態１においても説明したように、クライアント２００が持つべき再生バッファ２０８のデータ量は帯域変動が発生する可能性、言い換えればネットワーク３００の不安定さを元に決定される。本発明の対象とする映像配信システム１０のユースケースの一つである家庭内で無線ＬＡＮを使った映像配信を例にとって考えると、ネットワーク３００の状態が変化するパターンは主に二つある。

一つ目のパターンは、クライアント２００の周囲のネットワーク環境が大きく変化し、変化後は変化したままのネットワーク状態が継続するパターンである。想定されるシーンとしては、例えば、クライアント端末（ノートＰＣ又はスマートフォン等）を利用して配信映像を視聴中のユーザが、クライアント端末を持って部屋間を移動するような状況があげられる。この様なシーンでは、ネットワーク３００の状況（例えば受信電力）などが変化したまま維持されることで、ネットワーク３００の不安定さも大きく変化して維持される。そのため、変化したネットワーク環境に対して、クライアント２００側の再生バッファ２０８の最適な目標バッファデータ量を再計算し、その最適な目標バッファデータ量に適応させるような制御を行わなければならない。

一方、二つ目のパターンとしては、クライアント２００の周囲のネットワーク環境が一瞬変化するものの、直ちに元のネットワーク環境に回復する様なパターンがあげられる。具体的に想定されるシーンとしては、クライアント２００と映像配信サーバ１００との間を人が横切ることや、部屋のドアの開閉によって、一瞬（例えば１秒程度）ネットワーク環境が変化し、その後元に戻るような状況があげられる。二つ目のパターンは、一つ目のパターンと異なり、一瞬変化したネットワーク環境は直ちに元のネットワーク環境に戻る。そのため、変化の発生している例えば１秒程度の一瞬の間に目標バッファデータ量を再計算し、再生バッファ２０８に蓄積するデータ量を目標バッファデータ量に近づけるような制御を行おうとすると、実際に再生バッファ２０８に蓄積するデータ量が目標バッファデータ量に適応された時点において、元のネットワーク環境に戻っている。したがって、再度、目標バッファデータ量の制御およびトランスコード速度の制御をやり直さなければならない。このように、一瞬のネットワーク３００の変化に対して目標バッファデータ量の制御を行おうとすると、不必要な制御が発生し、制御が安定しない。さらに、再生バッファ２０８に蓄積するデータ量を不必要に伸ばす制御になるため、トランスコード速度が上昇させられ、その結果、エンコードレートが不必要に下げられて映像配信の品質が劣化するという問題も発生する。

これらの問題を解決するためには、ネットワーク３００の状況の変化が一時的であるか、あるいは恒常的であるかを判断する必要がある。しかし、実施の形態１で説明した帯域推定の方法では、ＲＴＴや受信レートなどのネットワークレイヤよりも上位の観測データしか持たないため、ネットワーク３００の状況の変化が一時的なものであるか否かの判断を行うことは難しい。

そこで、実施の形態２においては、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ以下の情報を用いることにより、直接的にネットワーク３００の状況に関しての情報を取得する。そして、ネットワーク３００の状況に関しての情報を用いてネットワーク３００の状況の変化をパターン分けし、ネットワーク環境が恒常的に変化した場合のみ目標バッファデータ量の再計算の制御とトランスコード速度およびエンコードパラメータの制御とを行う。また、一時的なネットワーク３００の状況の変化が発生した場合には、トランスコード速度およびエンコードパラメータの制御のみを行う。

この手法により、より高品質かつ安定した制御を実現することができる。

図７は、実施の形態２におけるクライアント２００ａの構成の一例を示す図である。

実施の形態２において映像配信サーバ１００は図２に示される構成と同じであるため説明は省略する。

実施の形態２におけるクライアント２００ａは、通信環境観測部２３０をさらに備える点が、実施の形態１におけるクライアント２００と異なる。その他の点は実施の形態１におけるクライアント２００の構成と同様であるため説明は省略する。

通信環境観測部２３０は、通信部２１０からネットワーク３００の通信環境に関する情報を取得し、通信環境情報に基づいてネットワーク３００の通信環境の変化が一時的な変化であるか否かを判断する。そして、通信環境観測部２３０は、決定部２２０（目標バッファデータ量決定部２０７）に対してネットワーク環境の変化が一時的な変化であるか否かの通知を行う。ＭＡＣレイヤの通信手段に無線ＬＡＮを用いる場合には、例えばＲＳＳＩの値が取得される利用される。

以下、実施の形態２としてＭＡＣレイヤの通信手段に無線ＬＡＮを用い、通信環境観測部２３０がＲＳＳＩの値を取得して利用する例を用いて、より具体的に実施の形態２について説明する。

図８は、実施の形態２におけるクライアント２００ａがトランスコード速度とエンコードパラメータとを決定する動作の一例を示すフローチャートである。図８は、ネットワーク３００の通信環境に関する情報を用いた場合の目標バッファデータ量の決定およびトランスコード速度とエンコードレートの決定の処理を示すフローチャートである。図８において、ステップＳ４０１からステップＳ４１２における動作は、実施の形態１におけるものと同じであるため、説明は省略し、ステップＳ５０１からステップＳ５０５の処理を中心に説明する。

目標バッファデータ量決定部２０７が、可用帯域が最低エンコードレートよりも大きいと判定した場合（ステップＳ４０３でＹＥＳ）、ステップＳ５０１の処理が行われる。

通信環境観測部２３０は、ネットワーク３００の通信環境を確認する（ステップＳ５０１）。ステップＳ５０１の処理について図９を用いて詳細に説明する。

図９は、実施の形態２におけるクライアント２００ａが通信環境を確認する動作の一例を示すフローチャートである。図９は、具体的には、通信環境観測部２３０の処理を示すフローチャートである。

目標バッファデータ量決定部２０７が、可用帯域が最低エンコードレートよりも大きいと判定した場合（ステップＳ４０３でＹＥＳ）、通信環境観測部２３０は起動される（ステップＳ６０１）。

次に、通信環境観測部２３０は、通信部２１０を介してＲＳＳＩの値を取得する（ステップＳ６０２）。ステップＳ６０３からステップＳ６０６は、ＲＳＳＩの値からネットワーク環境の変化が一時的か、あるいは恒常的かを判断するための手順である。ここで、ネットワーク環境の変化が一時的か、あるいは恒常的かを判断する方法について説明する。

ネットワーク環境が変化するとき、ＲＳＳＩなどのネットワーク情報も変化すると考えられる。つまり、ネットワーク環境が恒常的に変化する場合にはＲＳＳＩの値の変化も恒常的な変化となり、ネットワーク環境が一時的に変化する場合にはＲＳＳＩの値の変化も一時的な変化となる。すなわち、ＲＳＳＩの変化を時系列に沿って観測することで、ネットワーク環境の変化が一時的であるか恒常的であるかの判断を行える。ここで、ＲＳＳＩの変化が一時的か恒常的かを判定するときに設定する閾値が、当該判定を行うために重要になる。一般的に、クライアント２００ａの前を人が横切る等の状況が発生するとき、人が横切ること等によるネットワーク環境の変化は１秒以内となる。そこで、実施の形態２では、一例として、ネットワーク環境の一時的な変化と判断する閾値を１秒以内のネットワーク３００の変化と規定する。

通信環境観測部２３０は、ＲＳＳＩの１秒移動平均を計算する（ステップＳ６０３）。上述したようにネットワーク環境の一時的な変化と判断する閾値を１秒以内のネットワーク３００の変化と規定したため、ステップＳ６０３では、ＲＳＳＩの直近１秒間の移動平均が計算される。ステップＳ４０１からの処理は所定のタイミング毎に行われるため、可用帯域が最低エンコードレートよりも大きいと判定される場合（ステップＳ４０３でＹＥＳ）、ステップＳ５０１の処理も所定のタイミングで行われる。ここで、所定のタイミングを０．１秒とすると、通信環境観測部２３０は、ＲＳＳＩの値を０．１秒毎に取得し、０．１秒毎に取得したＲＳＳＩの値の１秒移動平均を計算する。以降、ＲＳＳＩの１秒移動平均の値を単にＲＳＳＩとも呼ぶ。

なお、ＲＳＳＩの変化の時系列での閾値を１秒とおいた処理（ＲＳＳＩの直近１秒間の移動平均の計算）が行われるが、ＲＳＳＩが変化したか否かの判定をするためには、ＲＳＳＩの閾値の範囲（レンジ）の設定が必要である。

実施の形態２の一例として、複数の閾値の範囲（レンジ）が予め定められる。予め定められた複数のレンジは、例えば１０ｄＢｍ刻みのレンジと規定する。例えば、０〜−１０ｄＢｍ、−１０〜−２０ｄＢｍ、−２０〜−３０ｄＢｍ、・・・をそれぞれ一つのレンジとする。そして、ＲＳＳＩの計測値が前回（例えば０．１秒前に）取得したＲＳＳＩの計測値と同じ閾値の範囲（レンジ）内にある場合には、通信環境観測部２３０は、通信環境の変化が一時的な変化であると判断する。

通信環境観測部２３０は、ＲＳＳＩの１秒移動平均の値が前回と同じレンジになっているか否か判定する（ステップＳ６０４）。

通信環境観測部２３０が、ＲＳＳＩの１秒移動平均の値が前回と異なるレンジになっていると判定した場合（ステップＳ６０４でＮＯ）、通信環境観測部２３０は、目標バッファデータ量変更フラグをセットする（ステップＳ６０５）。

通信環境観測部２３０が、ＲＳＳＩの１秒移動平均の値が前回と同じレンジになっていると判定した場合（ステップＳ６０４でＹＥＳ）、通信環境観測部２３０は、目標バッファデータ量変更フラグを解除する（ステップＳ６０６）。ステップＳ６０５およびステップＳ６０６で設定された目標バッファデータ量変更フラグは、目標バッファデータ量を変更するか否かの判断に用いられる。

そして、通信環境観測部２３０がネットワーク３００の通信環境を確認する処理は終了し（ステップＳ６０７）、ステップＳ５０２の処理が行われる。

このように、ＲＳＳＩを用いることで、恒常的なネットワーク３００の変化と一時的なネットワーク３００の変化を素早く判断することができる。

次に、目標バッファデータ量決定部２０７は、目標バッファデータ量変更フラグがセットされているか否かを判定する（ステップＳ５０２）。

目標バッファデータ量決定部２０７が、目標バッファデータ量変更フラグがセットされていないと判定した場合（ステップＳ５０２でＮＯ）、目標バッファデータ量決定部２０７は、目標バッファデータ量を前回の目標バッファデータ量のまま維持する（ステップＳ５０３）。これにより、一時的なネットワーク３００の変化に対して目標バッファデータ量の制御を行うことが抑制され、再生バッファ２０８に蓄積するデータ量を不必要に伸ばす制御が抑制される。したがって、トランスコード速度が不必要に上昇させられることが抑制され、その結果、エンコードレートが不必要に下げられて映像配信の品質が劣化することが抑制される。

そして、実施の形態１におけるステップＳ４０６からステップＳ４０８と同じ処理が行われる。具体的には、ステップＳ５０３で維持された目標バッファデータ量およびステップＳ４０６で計測された再生バッファ２０８に蓄積されたデータ量を元にステップＳ４０７およびステップＳ４０８でトランスコード速度とエンコードパラメータが決定される。

一方、目標バッファデータ量決定部２０７が、目標バッファデータ量変更フラグがセットされていると判定した場合（ステップＳ５０２でＹＥＳ）、ステップＳ４０４の処理が行われる。ステップＳ４０４での動作は実施の形態１におけるものと同じであるため説明は省略する。

次に、目標バッファデータ量決定部２０７は、目標バッファデータ量を決定する（ステップＳ５０４）。ステップＳ５０４での目標バッファデータ量の決定については、ステップＳ４０５での処理と異なる。実施の形態１では、次式を用いて目標バッファデータ量を導出した。

目標バッファデータ量＝１ＲＴＴの間に発生する映像データの到着遅延／ＲＴＴ×低下継続係数

しかし、実施の形態２においては、ネットワーク３００の環境情報であるＲＳＳＩのデータが取得されるため、ＲＳＳＩを用いて目標バッファデータ量の補正を行うことができる。一般的に、ＲＳＳＩが−３０ｄＢｍ以上であれば安定した通信を行える。したがって、ＲＳＳＩが−３０ｄＢｍ以上であれば安定したネットワーク状況であると判断することができ、クライアント２００ａの再生バッファ２０８に蓄積するデータ量を少なくしてエンコードレートを上げることができる。一方、ＲＳＳＩが−３０ｄＢｍ以下であれば不安定なネットワーク状況であると判断することができる。したがって、安定した映像の再生を行うためには、クライアント２００ａの再生バッファ２０８に蓄積するデータ量をより多くする必要があるため、より多くの目標バッファデータ量を設定しなければならない。

一例をあげると、ＲＳＳＩを用いて補正した目標バッファデータ量は以下のようにして計算できる。

補正した目標バッファデータ量＝目標バッファデータ量×（１−（３０＋ＲＳＳＩ）／ｎ）

ここで、ｎは正の実数であり、ネットワーク３００において観測されるＲＳＳＩの変化幅に応じて調整される。

より具体的に一例をあげると、ＲＳＳＩが−１０ｄＢｍから−８０ｄＢｍの間で変化するようなネットワーク３００においては、ｎ＝２００に設定する。これにより、例えばＲＳＳＩが−１０ｄＢｍのときには、補正した目標バッファデータ量は次式のように計算できる。

補正した目標バッファデータ量＝目標バッファデータ量×（１−（３０−１０）／２００）＝目標バッファデータ量×０．９

また、例えばＲＳＳＩが−８０ｄＢｍのときには、補正した目標バッファデータ量は次式のように計算できる。

補正した目標バッファデータ量＝目標バッファデータ量×（１−（３０−８０）／２００）＝目標バッファデータ量×１．２５

このように、ＲＳＳＩが大きい場合には、通信環境が安定しているため、目標バッファデータ量が小さくなるように補正され、ＲＳＳＩが小さい場合には、通信環境が不安定なため、目標バッファデータ量が大きくなるように補正される。

次に、ステップＳ４０６の処理が行われるが、ステップＳ４０６での処理は実施の形態１におけるものと同じであるため説明は省略する。

次に、トランスコード速度決定部２０４は、トランスコード速度を決定する（ステップＳ５０５）。ステップＳ５０５でのトランスコード速度の決定については、ステップＳ４０７での処理と異なる。ステップＳ５０５では、補正した目標バッファデータ量が使用される。

ステップＳ５０５では、トランスコード速度の決定にＲＳＳＩを利用する。すなわち、ステップＳ４０７での仮のトランスコード速度の算出を行うための計算式を次式のように置き換える。

仮のトランスコード速度＝１＋（補正した目標バッファデータ量−現在のバッファデータ量）／（ｍ×（１．０１−低下係数））−（ＲＳＳＩ＋３０）／ｎ

ｍ、ｎは、ともに正の実数である。また、例えば、ＲＳＳＩが−１０ｄＢｍから−８０ｄＢｍの間で変化するようなネットワーク３００においては、ｎ＝２００に設定する。さらに、実施の形態１において例示したパラメータ（ｍ＝０．１、目標バッファデータ量＝１．５秒、現在のバッファデータ量＝１秒、低下係数＝−２）を用いる。例えばＲＳＳＩが−１０ｄＢｍのときには、仮のトランスコード速度は次式のように計算できる。

仮のトランスコード速度＝１＋（１．５×０．９−１．０）×０．１×（１．０１＋２）−（−１０＋３０）／２００≒１．０

また、例えばＲＳＳＩが−８０ｄＢｍのときには、仮のトランスコード速度は次式のように計算できる。

仮のトランスコード速度＝１＋（１．５×１．２５−１．０）×０．１×（１．０１＋２）−（−８０＋３０）／２００≒１．５１

そして、実施の形態１で説明したように、仮のトランスコード速度は、最高トランスコード速度と比較され、トランスコード速度が決定される。

このように、ＲＳＳＩが大きい場合には、通信環境が安定しているため、トランスコード速度を早くする必要がなく、ＲＳＳＩが小さい場合には、通信環境が不安定なため、トランスコード速度を早くする必要がある。つまり、ネットワーク環境が良い場合にはよりゆっくりと制御を行うことでより高品質な映像を配信し、不安定なネットワーク環境ではより素早く再生バッファ２０８に蓄積するデータ量を目標値に適合させることで安定して映像を配信することができる。

以上、実施の形態２に開示した映像制御装置、映像配信システムおよび映像制御方法により、ネットワークインターフェイス等から取得できるより低レイヤの情報（例えばＲＳＳＩ）を利用して、より効率的かつ安定したエンコードパラメータとトランスコード速度との制御を行うことができる。

（その他の実施の形態）
以上、本発明の映像制御装置、映像配信システムおよび映像制御方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したもの、及び、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の範囲内に含まれる。

例えば、上記実施の形態では、通信部２１０は、トランスコード速度およびエンコードパラメータに関する指示を、映像配信サーバ１００に送信したが、これに限らない。例えば、通信部２１０は、目標バッファデータ量および再生バッファ２０８に蓄積されたデータ量に関する情報を映像配信サーバ１００に送信してもよい。また、映像配信サーバ１００は、トランスコード速度決定部およびエンコードパラメータ決定部を備えてもよい。これにより、映像配信サーバ１００に備えられたトランスコード速度決定部およびエンコードパラメータ決定部が、通信部２１０から受信した目標バッファデータ量および再生バッファ２０８に蓄積されたデータ量に関する情報に基づいてトランスコード速度およびエンコードパラメータを決定してもよい。つまり、トランスコード速度およびエンコードパラメータは、映像配信サーバ１００側で決定されてもよい。

なお、本発明の包括的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されてもよい。例えば、本発明は、上記映像制御方法をコンピュータに実行させるためのプログラムとして実現されてもよい。また、そのプログラムを示す情報、データ又は信号として実現することもできる。そして、それらプログラム、情報、データ及び信号は、インターネット等の通信ネットワークを介して配信してもよい。

その他、実施の形態に対して当業者が思いつく各種変形を施して得られる形態や、本発明の趣旨を逸脱しない範囲で各実施の形態における構成要素及び機能を任意に組み合わせることで実現される形態も本発明に含まれる。

本発明にかかる映像制御装置は、さまざまなネットワークへの適用性を有し、蓄積型の映像配信システムの制御技術等として有用である。また比較的遅延に対する要求の緩やかなライブストリーミング等の用途にも応用できる。

１０ 映像配信システム
１００ 映像配信サーバ（サーバ装置）
２００、２００ａ クライアント（映像制御装置）
３００ ネットワーク
１０２ エンコードパラメータ指定部
１０３ トランスコード速度指定部
１０４ 命令受信部
１０５、２０２ 通信スタック
１０６ 映像ソース
１０７ トランスコーダ
１１０ 第１の通信部
２０３ 命令送信部
２０４ トランスコード速度決定部
２０５ エンコードパラメータ決定部
２０６ 帯域推定部
２０７ 目標バッファデータ量決定部
２０８ 再生バッファ
２０９ デコーダ
２１０ 通信部（第２の通信部）
２２０ 決定部
２３０ 通信環境観測部

Claims (10)

1. サーバ装置から送信された映像データを受信する映像制御装置であって、
   前記サーバ装置でトランスコードされ、ネットワークを介して受信した前記映像データを蓄積する再生バッファと、
   前記再生バッファから読み出した前記映像データをデコードするデコーダと、
   前記ネットワークの所定時間後の可用帯域を推定し、推定した当該所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した当該目標バッファデータ量と、前記再生バッファに蓄積されたデータ量とを用いて、前記再生バッファに蓄積されるデータ量を変化させるパラメータである、前記映像データの単位時間当たりの送信速度に関するトランスコード速度と、前記映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する決定部と、
   前記決定部が決定した前記トランスコード速度および前記エンコードパラメータを、前記サーバ装置に対して送信する通信部と、を備える
   映像制御装置。
2. 前記決定部は、前記ネットワークの可用帯域を所定のタイミング毎に計測し、計測した当該所定のタイミング毎の可用帯域の変化を用いて、前記所定時間後の可用帯域を推定する
   請求項１に記載の映像制御装置。
3. 前記決定部は、前記所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下の速度を示す低下係数を用いて、前記所定時間後の可用帯域を推定する
   請求項２に記載の映像制御装置。
4. 前記決定部は、前記サーバ装置との間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）と前記低下係数とを用いて、前記所定時間後の可用帯域を推定する
   請求項３に記載の映像制御装置。
5. 前記決定部は、前記所定時間後の可用帯域と、前記所定のタイミング毎の可用帯域の変化に基づく可用帯域の低下が継続する時間を示す低下継続係数と、前記サーバ装置との間のＲＴＴとを用いて、前記目標バッファデータ量を決定する
   請求項２〜４のいずれか１項に記載の映像制御装置。
6. 前記通信部は、前記決定部が決定した前記トランスコード速度を、１回の確立されたコネクションの間に、複数回送信する
   請求項１〜５のいずれか１項に記載の映像制御装置。
7. さらに、前記通信部から前記ネットワークの通信環境に関する通信環境情報を取得し、当該通信環境情報に基づいて当該ネットワークの通信環境の変化が一時的な変化であるか否かを判断する通信環境観測部を有し、
   前記決定部は、前記通信環境観測部が前記通信環境の変化が一時的な変化であると判断した場合には前記目標バッファデータ量を変更せず、一時的な変化でないと判断した場合には前記目標バッファデータ量を変更する
   請求項１〜６のいずれか１項に記載の映像制御装置。
8. 前記通信環境観測部は、前記通信環境情報としてＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）を所定間隔で取得し、前記ＲＳＳＩが、予め定められた複数の閾値の範囲のうち前回取得したＲＳＳＩと同じ閾値の範囲内にある場合に、前記通信環境の変化が一時的な変化であると判断する
   請求項７に記載の映像制御装置。
9. ネットワークを介してサーバ装置から送信された映像データを受信する映像制御装置における映像制御方法であって、
   前記映像制御装置は、受信した前記映像データを蓄積する再生バッファと、前記再生バッファから読み出した前記映像データをデコードするデコーダと、を備え、
   前記映像制御方法は、
   前記ネットワークの可用帯域を所定のタイミング毎に計測するステップと、
   前記計測するステップで計測した前記所定のタイミング毎の可用帯域の変化を用いて、前記ネットワークの所定時間後の可用帯域を推定し、推定した当該所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定するステップと、
   前記目標バッファデータ量と前記再生バッファに蓄積されたデータ量とを用いて、前記再生バッファに蓄積するデータ量を変化させるパラメータである、前記映像データの単位時間当たりの送信速度に関するトランスコード速度と、前記映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定するステップと、
   前記トランスコード速度および前記エンコードパラメータを、前記サーバ装置に対して送信するステップと、を含む
   映像制御方法。
10. サーバ装置に蓄積された映像データを、ネットワークを介して、クライアントに配信する映像配信システムであって、
    前記映像データをトランスコードするトランスコーダと、
    前記トランスコーダがトランスコードした映像データを送信する第１の通信部と、
    前記第１の通信部が送信した前記映像データを受信する第２の通信部と、
    前記第２の通信部が受信した前記映像データを蓄積する再生バッファと、
    前記再生バッファから読み出した前記映像データをデコードするデコーダと、
    前記ネットワークの所定時間後の可用帯域を推定し、推定した当該所定時間後の可用帯域に基づき必要となる目標バッファデータ量を決定し、決定した当該目標バッファデータ量と、前記再生バッファに蓄積されたデータ量とを用いて、前記再生バッファに蓄積するデータ量を変化させるパラメータである、前記映像データの単位時間当たりの送信速度に関するトランスコード速度と、前記映像データの１つのフレーム当たりのデータ量に関するエンコードレートを含むエンコードパラメータとを決定する決定部と、を備え、
    前記トランスコーダは、前記決定部が決定したトランスコード速度とエンコードパラメータとを用いて前記映像データをトランスコードする
    映像配信システム。

Images