(57)【特許請求の範囲】
【請求項１】
複数のフラグメントで構成される映像データと、前記映像データの受信ビットレート測定を開始するトリガとなる情報である監視トリガ情報と、前記フラグメントのデータサイズ情報とを受信する通信部と、
前記監視トリガ情報と前記データサイズ情報とに基づいて、フラグメント毎に前記受信された映像データの受信ビットレートを算出する監視部と、
前記受信された映像データを再生する再生部とを備え、
前記通信部は、前記監視部が算出した前記受信ビットレートに基づいて生成された前記映像データの配信ビットレート切り換え情報を送出する
ことを特徴とする端末装置。
【請求項２】
前記複数のフラグメントのうち、第一のフラグメントには前記第一のフラグメントの次に受信する第二のフラグメントの受信開始時刻を示す監視トリガ情報が含まれ、前記第二のフラグメントには前記第二のフラグメントのデータサイズ情報が含まれ、
前記監視部は、
前記第二のフラグメントの受信開始時刻を示す前記監視トリガ情報と前記第二のフラグメントのデータサイズ情報とから、前記第二のフラグメントの受信に要する時間を算出し、前記第二のフラグメントのデータサイズ情報と前記第二のフラグメントの受信に要する時間とから、前記受信ビットレートを算出する
ことを特徴とする請求項１に記載の端末装置。
【請求項３】
時刻をカウントするタイマを有し、
前記監視部は、前記タイマの時刻と前記監視トリガ情報とに基づいて前記受信ビットレートの監視を開始する
ことを特徴とする請求項１または２に記載の端末装置。
【請求項４】
前記通信部は、
前記監視部が算出した前記受信ビットレートと記録部に記録されるビットレートの切り換え条件との比較結果に基づいて生成される前記配信ビットレート切り換え情報を送出する
ことを特徴とする請求項１乃至３に記載の端末装置。
【請求項５】
ユーザからの入力を受けつける入力指示部を有し、
前記入力指示部を介して、前記配信ビットレートの切り換えをユーザが手動で行うか、装置が自動で行うかの選択を行う
ことを特徴とする請求項１乃至４記載の端末装置。
【請求項６】
映像データを受信端末に配信する配信サーバであって、
前記映像データの受信ビットレート測定を開始するトリガとなる情報である監視トリガ情報を作成する監視トリガ情報作成部と、
前記映像データと前記映像データのフラグメントごとのデータサイズ情報と前記監視トリガ情報とを、前記映像データの前記フラグメント単位ごとに多重する映像データ再構成部と、
前記多重した映像データを送信する通信部と、
前記映像データと前記映像データのフラグメントごとのデータサイズ情報と前記監視トリガ情報とに基づいて前記受信端末が生成し、送信した配信ビットレート切り換え情報によって配信ビットレート切り換えを行うビットレート切り換え制御部と、
を備えることを特徴とする配信サーバ。
【請求項７】
前記監視トリガ情報として、前記配信する映像データの拡張部分に、次に送信する前記フラグメントの送信開始時刻情報を挿入する
ことを特徴とする請求項６に記載の配信サーバ。
【請求項８】
前記ビットレート切り換え制御部は、
前記通信部が前記受信端末から前記配信ビットレート切り換え要求コマンドを受信した場合、前記映像データの画像サイズを変更することによって前記配信ビットレートを切り換える
ことを特徴とする請求項６または７に記載の配信サーバ。
【請求項９】
前記ビットレート切り換え制御部は、
前記通信部が前記受信端末から前記配信ビットレート切り換え要求コマンドを受信した場合、前記映像データにおける画像の表示枚数を変更することによって前記配信ビットレートを切り換える
ことを特徴とする請求項６または７に記載の配信サーバ。
【請求項１０】
複数のフラグメントで構成される、映像データと、前記映像データの受信ビットレート測定を開始するトリガとなる情報である監視トリガ情報と、前記フラグメントのデータサイズ情報とを受信する受信ステップと、
前記監視トリガ情報と前記データサイズ情報とに基づいて、フラグメント毎に前記受信された映像データの受信ビットレートを算出する算出ステップとを備え、
前記受信ステップにおいて、前記算出ステップで算出した前記受信ビットレートに基づいて生成された前記映像データの配信ビットレート切り換え情報を送出する
ことを特徴とする映像データの受信方法。
【請求項１１】
前記複数のフラグメントのうち、第一のフラグメントには前記第一のフラグメントの次に受信する第二のフラグメントの受信開始時刻を示す監視トリガ情報が含まれ、前記第二のフラグメントには前記第二のフラグメントのデータサイズ情報が含まれ、
前記算出ステップにおいて、
前記第二のフラグメントの受信開始時刻を示す前記監視トリガ情報と前記第二のフラグメントのデータサイズ情報とから、前記第二のフラグメントの受信に要する時間を算出し、前記第二のフラグメントのデータサイズ情報と前記第二のフラグメントの受信に要する時間とから、前記受信ビットレートを算出する
ことを特徴とする請求項１０に記載の映像データの受信方法。
【請求項１２】
前記算出ステップにおいて、
時刻をカウントするタイマが示す時刻と前記監視トリガ情報とに基づいて前記受信ビットレートの監視を開始する
ことを特徴とする請求項１０または１１に記載の映像データの受信方法。
【請求項１３】
前記受信ステップにおいて、
前記監視ステップで算出した前記受信ビットレートと所定のビットレートの切り換え条件との比較結果に基づいて生成される前記配信ビットレート切り換え情報を送出する
ことを特徴とする請求項１０乃至１２に記載の映像データの受信方法。
【請求項１４】
ユーザからの入力を受けつける入力指示ステップと、
前記入力指示ステップにより入力されたユーザからの入力に基づいて、前記配信ビットレートの切り換えをユーザが手動で行うか、装置が自動で行うかを切り換えるステップとをさらに備える
ことを特徴とする請求項１０乃至１３記載の映像データの受信方法。
【請求項１５】
映像データを受信側に送信する送信方法であって、
前記映像データの受信ビットレート測定を開始するトリガとなる情報である監視トリガ情報を作成する監視トリガ情報作成ステップと、
前記映像データと前記映像データのフラグメントごとのデータサイズ情報と前記監視トリガ情報とを、前記映像データの前記フラグメント単位ごとに多重する映像データ再構成ステップと、
前記多重した映像データを送信する送信ステップと、
前記映像データと前記映像データのフラグメントごとのデータサイズ情報と前記監視トリガ情報とに基づいて前記受信側が送信した配信ビットレート切り換え情報を受信するステップと、
前記受信側が送信した配信ビットレート切り換え情報にしたがって配信ビットレート切り換えを行うビットレート切り換え制御ステップと、
を備えることを特徴とする映像データの送信方法。
【請求項１６】
前記映像データ再構成ステップにおいて、
前記監視トリガ情報として、前記配信する映像データの拡張部分に、次に送信する前記フラグメントの送信開始時刻情報を挿入する
ことを特徴とする請求項１５に記載の映像データの送信方法。
【請求項１７】
前記ビットレート切り換え制御ステップにおいて、
前記受信ステップで前記受信側から前記配信ビットレート切り換え要求コマンドを受信した場合、前記ビットレート切り換え制御ステップにおいて前記映像データの画像サイズを変更することによって前記配信ビットレートを切り換える
ことを特徴とする請求項１５または１６に記載の映像データの送信方法。
【請求項１８】
前記ビットレート切り換え制御ステップにおいて、
前記受信ステップで前記受信側から前記配信ビットレート切り換え要求コマンドを受信した場合、前記ビットレート切り換え制御ステップにおいて前記映像データにおける画像の表示枚数を変更することによって前記配信ビットレートを切り換える
ことを特徴とする請求項１５または１６に記載の映像データの送信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、配信サーバからモバイル端末に向けて符号化された映像データを、無線回線を経由してストリーミングを行う映像配信システムにおいて、モバイル端末における受信状態の監視結果に応じて、配信映像のビットレートを切換える装置およびその方法に関する。
【０００２】
【従来の技術】
近年、ブロードバンド技術の急速な立ち上がりと、携帯電話やPDA(Personal Digital Assistance)等のモバイル端末の普及によって、セルラ電話通信網や無線LAN(Local Area Network)等の無線インフラを使用した映像ストリーミングサービスが拡大している。無線を使用したストリーミングで問題となるのは、電波受信状態の変動である。受信状態が変動すると、受信エラーが多発するためデータの再送処理が増加する。この影響でストリーミングデータの転送レートが変動し、映像再生が正しく実行できないケースが生じる。特に、受信状態が良好な状態から悪化方向に変換した場合の対応は、重要な課題となる。
【０００３】
映像配信システムにおける電波受信状態に応じた制御方法の従来技術として、電子メールシステムにおいて、受信端末が予め決められた時間間隔で電波の受信状態を監視し、その変化状況に応じて、配信サーバが配信するメールの送信順序を変更する方法がある（例えば、特許文献１参照）。
【０００４】
又、動画伝送装置による伝送方法において、受信端末が受信状態を示す情報を常に配信サーバに通知することで、配信サーバ側でデータ通信速度の制御を実行する方法もある（例えば、特許文献２参照）。
【０００５】
更に、携帯受信端末において、電波の受信状態と、配信映像の内容(スポーツ、ニュース等)を考慮してデータ通信速度の予測し、その予測結果を配信サーバに通知することで、データ通信速度の制御を実行する方法もある（例えば、特許文献３参照）。
【特許文献１】
特開2000-349808号公報
【特許文献２】
特開2001-69483号公報
【特許文献３】
特開2002-344560号公報
【発明が解決しようとする課題】
前記の従来の技術に示した、特許文献１，３の方法は、受信端末における電波強度の観測によって受信状態を監視する手法である。しかし、ある１つの基地局に多数の受信端末が集中した場合等では、電波強度とデータ通信速度の関係は必ずしも比例しないケースがある。よってこの方法では、端末側の受信状態を完全に把握することができない。
【０００６】
特許文献２に記載の方法は、受信端末における受信状態を配信サーバが判断するために、受信端末が配信サーバに対して、常時、受信状態に関する情報を送り続ける方式である。このため、映像ストリーミング時は、受信端末が常に送信と受信を実行しなければならないため、回線利用効率が低下するとともに、受信端末の処理負荷が大きくなるという課題がある。
【０００７】
本発明は、上述の課題を解決するためのものであり、映像ストリーミング時に受信端末自身が正確に受信ビットレートを監視する機能を備え、その監視結果に応じて最適な映像ビットレートに切換えることを配信サーバへ要求することで、安定した映像ストリーミングが実行可能な手段を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明において、上記の課題を解決するためには、例えば特許請求の範囲に記載されるように構成すればよい。
【０００９】
【発明の実施の形態】
以下、本発明における映像配信装置および映像受信方法の実施の形態について説明する。
【００１０】
図１は、本発明の受信端末100の構成を示す図である。
【００１１】
受信端末100が受ける映像データは、MPEG等の所定の符号化方式で圧縮されたデータであり、配信サーバ200から無線通信網112と中継局113を経由して受信端末100に配信される。
【００１２】
無線通信部101は、配信サーバ200と無線によるデータの送受信を行う。映像データ受信部102は、配信サーバ200から送られる映像データの受信を行う。受信した映像データは、解析部103を経由して記憶部104に格納する。解析部103は、映像データに含まれている監視トリガ情報を抽出して監視トリガ制御部109へ通知することと、映像データのデータサイズを受信ビットレート監視部110へ通知を行う。監視トリガ情報とは、受信ビットレート監視部110が監視動作を開始する時刻を示す情報、又は受信ビットレート監視部が監視動作を開始するトリガとなる情報のことである。記憶部104は、映像データの一時的保存のために使用する。再生部105は、記憶部104から映像データを逐次読み出して伸張処理を行い、伸張後の動画はモニタ106に表示し、音声はスピーカ107に出力する。基準タイマ108は、動画と音声の同期再生の基準となるタイマである。また、基準タイマ108は、監視トリガ制御部109において、監視トリガ情報に含まれる時刻との比較にも使用する。監視トリガ制御部109は、基準タイマ108の時刻と監視トリガ情報に示された時刻を比較し、両方の時刻が一致した時に、受信ビットレート監視部110に対し、監視動作開始のトリガをかける。受信ビットレート監視部110は、監視トリガ制御部109からトリガがかけられた時点から受信ビットレートの監視を行う。監視結果が所定のビットレート範囲からずれた場合には、コマンド送信部111から配信サーバ200に対して、映像データのビットレート切換えを要求する。監視結果が所定のビットレート範囲内であれば、配信サーバ200に対するビットレート切換えは要求しない。コマンド送信部111は、配信サーバ200に対する映像データの配信開始、配信停止および映像ビットレート切換え要求等のコマンドの送信を行う。
【００１３】
図2は、本発明の配信サーバ200の構成を示す図である。
【００１４】
インターネット等の外部公衆網210を経由して送られてくる映像データを、映像データ入力部201で受け取り、記憶部202に格納する。基準タイマ206は、受信端末100における映像データの再生時に使用する再生時刻情報を生成し、映像データ再構成部203に送る。監視トリガ情報作成部207は、基準タイマ206の時刻情報を参照して、受信端末100の受信ビットレート監視部110が使用する監視トリガ情報を生成し、映像データ再構成部203に送る。映像データ再構成部203は、基準タイマ206からの再生時刻情報と、監視トリガ情報作成部207からの監視トリガ情報を、記憶部202から読み出した映像データに多重する。多重した映像データは、映像データ送信部204により、受信端末100へ送信する。配信サーバ200から送信した映像データは、図１でも示した通り、無線通信網112と中継局113を経由して、受信端末100に送られる。無線通信部205は、受信端末100と無線によるデータの送受信を行う。コマンド受信部208は、受信端末100から送られた、配信開始、配信停止および映像ビットレート切換え要求等のコマンドを受け付ける。ビットレート切換え制御部209は、受信端末100から映像ビットレート切換え要求コマンドを受信した場合に、現在配信中の映像ビットレートからコマンドに示された映像ビットレートへの切換えを行う。
【００１５】
図3は、映像データの構造を示す図である。
【００１６】
ある一つの映像データは、複数のフラグメント300が連続している構造となっている。フラグメント300とは、映像データを所定の再生時間長毎に分割し、各々に再生に必要な制御情報を付加した、あるまとまったデータ単位のことである。分割の基準となる時間長は、任意に設定でき、それぞれが異なる長さを持つものであっても良い。
【００１７】
図3(a)に、１つのフラグメント300の構造を示す。フラグメント300は、再生映像にオプション的に多重表示するためのテロップ文字列等、ユーザが任意に定義可能な付加情報を格納したuuid(Universal Unique Idetifier)(301)と、ランダムアクセス制御情報等の再生に必要な情報を格納したヘッダ302と、所定の再生時間長の動画と音声データ303とで構成する。同図に示した例では、フラグメント内のuuidは１個であるが、ユーザ定義情報の個数に応じて複数個用意しても良い。本発明の映像配信方法では、その中のuuidの一つに監視トリガ情報を格納する。監視トリガ情報は、受信端末100において、受信ビットレート測定を開始するためのトリガとして使用する。１つのフラグメントのデータ転送はバースト転送である(詳細は図7で説明)。受信端末100は、監視トリガ情報を参照することで、バースト転送開始時刻を正確に知ることができ、受信ビットレートの測定制度が向上する。監視トリガ情報は、映像データの送受信に関連する情報であり、映像再生とは直接関係のない情報である。従って、映像再生に関するオプション的な情報を格納することを目的としているuuidに挿入するのが望ましい。また、uuidは、システム内で重複しないことが保障されたIDを用いて運用される。監視トリガ情報を必要としないシステムは、ID判別により、監視トリガ情報を無視することが可能であり、不本意な誤動作を防ぐ効果もある。もちろん、uuid以外のヘッダ等に挿入することも可能である。
【００１８】
図3(b)に、複数のフラグメント300を連結した構造を示す図である。映像データのフラグメント300の配置は、先頭から再生時刻順に並べられた構造となる。同図の例では、フラグメントn(304)が最初に再生され、その次にフラグメントn+1(305)が再生される。図3(a)で示した通り、各々のフラグメントは、uuid(301)と、ヘッダ(302)と、動画と音声データ(303)で構成する。
【００１９】
図4は、uuid(301)の構造を示す図である。
【００２０】
uuidは、ユーザが任意に定義可能なデータであり、動画と音声データとは別に映像データに付加される。図4(a)に示すように、uuid(301)は、uuid全体のサイズ401と、「uuid」を表すテキスト文字列(402)と、識別ID(403)と、データ部(404)で構成する。監視トリガ情報をuuid(301)に格納する場合、データ部(404)には、受信端末100における受信ビットレート監視動作の開始を指示するトリガ時刻情報を格納する。図4(b)は、監視トリガ情報を格納したuuid(301)の一例を示す図である。同図の例では、uuidサイズ405が28バイトであることを示している。「uuid」を表すテキスト文字列(406)は、uuidの種類を問わず共通であり、このテキスト文字列によりこのデータがuuidであることが処理装置に認識される。識別ID(407)は、uuidの種類を認識するためのコードである。同図の例では、「TRIGTIME_0000000」を表す文字列が監視トリガ情報であることを示すコードであり、受信端末100は、この文字列を検出して監視トリガ情報を認識する。最後のデータ部に格納された「123456msec」が受信端末100におけるトリガ時刻を表す情報である。
【００２１】
図5は、配信サーバ200における監視トリガ情報を格納したuuid生成の概念を示す図である。
【００２２】
同図では、監視トリガ情報を格納したuuidをTRIGuuidとして示す。配信時刻T0(508)に配信するフラグメントn(505)のTRIGuuid(502)には、次のフラグメントn+1(506)が配信される予定時刻T1(509)を格納する。同様に、配信時刻T1(509)に配信するフラグメントn+1(506)のTRIGuuid(503)には、フラグメントn+2(507)が配信される予定時刻T2(510)を格納し、配信時刻T2(510)に配信するフラグメントn+2(507)のTRIGuuid(504)には、その後のフラグメントが配信される予定時刻T3(511)を格納する。この様に、ある配信時刻のフラグメントのTRIGuuidには、必ず次に配信するフラグメントの配信予定時刻を格納する。
【００２３】
別の実施例として、TRIGuuidに同じフラグメントのヘッダ部分または動画と音声のデータ部分の配信予定時刻を格納するようにしても良い。この場合、TRIGuuid部分は、受信ビットレート測定の対象外となるが、TRIGuuidのデータサイズは、後に続く動画と音声のデータ部分に比べて、ごく小さいので特に問題とならない。
【００２４】
さらに別の実施例として、配信サーバ200と受信端末100が同一クロックの発信器を内蔵している場合は、時刻情報の代わりに配信予定のクロックカウンタ値をTRIGuuidに格納するようにしても良い。クロックカウンタ値は、起動時からの積算クロック値でも良いし、前回のフラグメント配信からの相対クロック値でも良い。
【００２５】
図6は、受信端末100における受信ビットレート監視のタイムチャートを示す図である。
【００２６】
１つのフラグメントのデータ転送はバースト転送であるため、そのフラグメントの映像データ再生時間よりは短い時間でデータ転送は完了する。受信端末100における受信ビットレートは、このバースト転送区間の時間と受信したデータサイズを測定することで計算する。例えば、受信端末100でフラグメント受信時の処理は図６の様になる。まず、時刻T0(610)からフラグメント1(614)を受信し(600)、監視トリガ情報が格納されているTRIGuuidを解析部(103)で解析する(601)。このTRIGuuidには、次のフラグメント2の受信時刻T1(611)が格納されている。受信端末100の監視トリガ制御部109は、受信時刻T1(611)に備えて基準タイマ108との時刻比較処理を作動させる(602)。時刻がT1(611)に達した時点から配信サーバ200はフラグメント2(615)の配信を開始する。受信端末100は、時刻T1(611)からフラグメント2(615)のデータ受信を行い(605)、同時に受信ビットレート測定を開始する(603)。また、フラグメント2(605)のヘッダには、フラグメントのデータサイズが格納されている。このデータサイズを読み出して、フラグメント2のデータ受信の終了と受信ビットレート測定の終了の検出に使用する。この後のフラグメント2(615)とフラグメント3(616)のデータ受信時も同様に、フラグメントのデータ受信(605)、TRIGuuid解析(606)、監視トリガのタイマ作動(607)、受信ビットレート測定(608)、フラグメントサイズ解析(609)の順序で実行する。
【００２７】
図7は、映像データ配信の典型的なデータ転送時間とビットレートの関係を示す図である。
【００２８】
図6でも説明した様に、１つのフラグメントのデータ転送はバースト転送であるため、そのフラグメントの映像データ再生時間よりは短い時間でデータ転送は完了する。データ転送の時間は、無線回線の転送周波数で決まる。受信端末100で映像ビットレートCBR(706)、映像再生時間Fts1秒(707)の映像データのフラグメントを受信すると、映像ビットレートCBR(706)よりも高速な受信ビットレートRBR(705)で受信するため、映像再生時間Fts1秒(707)よりも短いBts1秒(710)でデータ受信が完了する。各フラグメント(701,702,703)のサイズと受信ビットレートRBR(705)が一定と仮定すれば、フラグメント受信時間(710,711,712)も一定となる。しかし、実際には、フラグメント毎にフラグメントサイズと受信ビットレートが変動するため、フラグメント受信時間は図７に示すように一定の値とはならない。
【００２９】
図8は、映像ビットレートテーブル800の一例を示す図である。
【００３０】
映像ビットレートテーブル800は、配信サーバ200が配信可能な映像ビットレートCBR(706)の種類を示すテーブルである。同テーブルは、配信サーバ200と受信端末100の両方が使用する。
同図の例では、100kbps、200kbps、300kbpsの3種類の映像ビットレートが配信可能であることを表している。映像ビットレートの設定数は任意で良く、ビットレート値も任意に設定できる。映像ビットレートCBR(706)の種類を識別するために、モード801を用いる。同図では、モード0(802)が100kbps、モード1(803)が200kbps、モード2(804)が300kbpsである。
【００３１】
同一映像において複数個のビットレートを用意する場合、映像の画質、音声の品質、画像サイズ、画像の所定単位あたりの表示枚数等を変更することによって送るべきデータ量を変化させ、ビットレートを変化させることになる。
映像ビットレートテーブル800は、受信端末100の受信ビットレート監視部110が参照する。同テーブルは、受信端末100の所定の専用メモリを設けて格納しても良いし、記憶部104の一部に格納するようにしても良い。また、配信サーバ200では、ビットレート切換え制御部209が参照する。同テーブルは、受信端末100と同様に所定の専用メモリに格納しても良いし、記憶部202の一部に格納するようにしても良い。
【００３２】
図9は、映像ビットレート切換えポイントテーブル900の一例を示す図である。
【００３３】
映像ビットレート切換えポイントテーブル900は、受信端末100の受信ビットレート監視部110で測定した受信ビットレートとの比較するために使用し、配信サーバに対して別の映像ビットレートに切換えるかどうかを判断するために参照するテーブルである。同テーブルは、受信端末100が使用し、
映像ビットレートのモード903毎に、上限ビットレートUBR(901)、下限ビットレートBBR(902)の情報で構成する。モード903の種類は、映像ビットレートテーブル800と一致するように設定する。上限ビットレートUBR(901)と下限ビットレートBBR(902)は、配信サーバ200が配信するフラグメントサイズと使用する無線回線の転送周波数との性能関係に基づいて設定する。同図の例では、モード1(905)を受信中の場合、受信ビットレートが1.8Mbpsから2.2Mbpsの間ならば、映像ビットレート切換えを行わないことを表している。1.8Mbpsを下回った場合はモード0(904)に切換え、2.2Mbpsを上回った場合はモード2(906)に切換える。モード0(904)を受信中の場合、受信ビットレートが1.2Mbpsを上回らなければ、映像ビットレート切換えを行わないことを表している。1.2Mbpsを上回った場合はモード1(905)に切換える。同図の例では、モード0(904)以下の映像ビットレートは存在しないので、下限ビットレートBBR(902)は設定しない。モード2(906)を受信中の場合、受信ビットレートが2.8Mbpsを下回らなければ、映像ビットレート切換えを行わないことを表している。2.8Mbpsを下回った場合はモード1(905)に切換える。同図の例では、モード2(906)以上の映像ビットレートは存在しないので、上限ビットレートUBR(901)は設定しない。図９に示す規定以外にも、各モードに対応するビットレートを特定するための情報が記録されれば良い。
【００３４】
映像ビットレート切換えポイントテーブル900は、受信端末100の受信ビットレート監視部110が参照する。同テーブルは、受信端末100の所定の専用メモリを設けて格納しても良いし、記憶部104の一部に格納するようにしても良い。
【００３５】
図10は、映像ビットレートテーブル800および映像ビットレート切換えポイントテーブル900の使用形態を示す図である。
【００３６】
映像ビットレートテーブル800は、配信サーバ200と受信端末100の両方が使用する。ある配信サーバ1000と接続関係にある受信端末1(1001)および受信端末2(1002)は、配信サーバ1000が持つ映像ビットレートテーブル1005と同一内容のテーブル(1008,1010)を持つ。別の実施例として、受信端末100は、配信サーバ200へ映像ビットレートを指定する方法として、映像ビットレート値を示すデータを直接送信するようにし、配信サーバは、指定された映像ビットレートに基づいて映像データを再構成するようにしても良い。この場合、配信サーバ200は、映像ビットレートテーブル800を使用しなくとも良い。  映像ビットレート切換えポイントテーブル900は、受信端末100が使用する。同テーブルの内容は、無線回線の転送周波数に依存するため無線網毎に用意する必要がある。例えば、無線網1(1003)に接続されている受信端末1(1001)の映像ビットレート切換えポイントテーブル1009と、無線網2(1004)に接続されている受信端末2(1002)の映像ビットレート切換えポイントテーブル1011は、モード毎の設定内容が異なる。
【００３７】
これら2つのテーブルは、配信サーバ1000、受信端末1(1001)、受信端末2(1002)に予め設定しておくこともできる。また、受信端末が異なる無線網を移動することも考えられるので、映像データの配信開始前に、配信サーバ1000から受信端末1001,1002へ中継する無線網に対応するテーブルを送信するようにしても良い。データ転送性能の異なる無線網では、転送能力の違いから映像ビットレート切換えポイントが異なるため、テーブルを切換えずに運用すると、誤動作を引き起こす原因となる。従って、ストリーミングを開始する時点、および無線網が切換わった時点でテーブルを送信するようにすれば、映像ビットレート切換えの誤動作を防ぐことができる。
この様にすることで、受信端末100がデータ転送性能の異なる無線網を移動した場合でも、各々の無線回線に最適なテーブルを用いて映像ビットレート切換えを運用することができる。
【００３８】
図11は、上位モードへの映像ビットレート切換え動作の一例を示す図である。
【００３９】
受信端末100が、図8と図9で示した映像ビットレートテーブル800および映像ビットレート切換えポイントテーブル900を使用し、モード1の映像データを受信していると仮定する。モード1において映像ビットレートを維持する受信ビットレートRBR(1104)範囲は、1.8Mbpsから2.2Mbpsである。受信1(1100)と受信2(1101)の受信ビットレートRBR(1104)は2.0Mbpsなので、映像ビットレート切換えは行わない。受信3(1102)の時点で、受信ビットレートRBR(1104)が2.2Mbpsを越えたので、配信サーバ200に対してモード1からモード2への映像ビットレート切換え1105を要求する。これによってサーバがビットレートを切り換え、受信4(1103)からは、端末はモード2の映像データを受信することになる。
【００４０】
図8で説明した通り、モード切換え前後の映像ビットレートの差による映像の違いは、映像の画質、音声の品質、画像サイズ、画像の所定単位あたりの表示枚数等である。
【００４１】
図12は、下位モードへの映像ビットレート切換え動作の一例を示す図である。
【００４２】
図11と同様に、受信端末100が、図8と図9で示した映像ビットレートテーブル800および映像ビットレート切換えポイントテーブル900を使用し、モード1の映像データを受信していると仮定する。受信1(1200)と受信2(1201)の受信ビットレートRBR(1204)は2.0Mbpsなので、映像ビットレート切換えは行わない。受信3(1202)の時点で、受信ビットレートRBR(1204)が1.8Mbpsを下回ったので、配信サーバ200に対してモード1からモード0への映像ビットレート切換え1205を要求する。受信4(1203)からは、モード0の映像データを受信することになる。
【００４３】
図13は、上位モードへの映像ビットレート切換え動作の別の一例を示す図である。
【００４４】
受信ビットレートが連続して急激に変動する場合、映像ビットレート切換えが多発して、映像データ配信の負荷となる場合が考えられる。この場合は、映像ビットレート切換えを判断する部分に感度を持たせて、切換えの発生回数を減らすように制御しても良い。
【００４５】
同図は、上位モードへの切換える場合に、上昇切換え感度uc_sensi(1307)を設定した例である。上昇切換え感度uc_sensi(1307)とは、受信ビットレートRBR(1305)が何回連続して越えたら映像ビットレート切換えを要求するかを示す数値である。例えば、上昇切換え感度uc_sensi(1307)を3に設定し、モード1の映像データを受信していると仮定する。受信1(1300)の時点では、受信ビットレートRBR(1305)が2.0Mbpsなので、映像ビットレート切換えは行わない。受信2(1301)、受信3(1302)、受信4(1303)において、受信ビットレートRBR(1305)が3回連続して2.0Mbpsを越えたので、配信サーバ200に対してモード1からモード2への映像ビットレート切換え1306を要求する。受信5(1304)からは、モード2の映像データを受信することになる。上昇切換え感度uc_sensi(1307)は、受信端末100の受信ビットレート監視部110が保持する。上昇切換え感度uc_sensi(1307)の最大値は、記憶部104の映像データの蓄積容量に依存する。少なくとも、映像ビットレート切換えを見送る回数(すなわち切換え感度の値)と同等のフラグメントの映像データが、常に再生より先行して記憶部104に格納されている必要がある。上昇切換え感度uc_sensi(1307)は、記憶部104の容量と、映像ビットレートから導かれる１つのフラグメントのデータサイズの平均値等から計算して、受信端末100が自動的に設定することができる。また、ユーザが任意に設定するようにしても良い。
【００４６】
図14は、下位モードへの映像ビットレート切換え動作の別の一例を示す図である。
【００４７】
図13に示した上昇切換え感度を使用した映像ビットレート切換え方法は、下位モードへの映像ビットレート切換え動作にも適用できる。同図では、下降切換え感度dc_sensi(1407)を3に設定し、モード1の映像データを受信していると仮定する。受信1(1400)の時点では、受信ビットレートRBR(1405)が2.0Mbpsなので、映像ビットレート切換えは行わない。受信2(1401)、受信3(1402)、受信4(1403)において、受信ビットレートRBR(1405)が3回連続して1.8Mbpsを下回ったので、配信サーバ200に対してモード1からモード0への映像ビットレート切換え1406を要求する。受信5(1404)からは、モード0の映像データを受信することになる。
【００４８】
下降切換え感度dc_sensi(1407)は、受信端末100の受信ビットレート監視部110が保持する。また、下降切換え感度dc_sensi(1407)の設定方法も、上昇切換え感度uc_sensi(1307)の場合と同様である。
【００４９】
図15は、配信サーバ200の動作を示すフローチャートである。
【００５０】
まず、配信サーバ200の動作を停止するかどうかを判断する(1500)。動作継続の場合、受信端末100からコマンド受信があるかどうかを判断する(1501)。動作停止の場合、現在映像データ配信中かどうかを判断し(1512)、配信中ならば配信を停止(1513)して処理を終了する。動作継続において、コマンド受信があった場合は、そのコマンドを解析し(1502)、映像ビットレートCBRでの配信開始要求かどうかを判断する(1503)。配信開始要求ならば、既に映像データ配信中かどうかを判断する(1504)。配信中でなければ、映像ビットレートCBRの映像データ配信を開始する(1507)。既に映像データ配信中ならば、配信中の映像ビットレートが要求された映像ビットレートCBRと同じであるかどうかを判断する(1505)。映像ビットレートCBRが、配信中の映像ビットレートと同じ場合は、コマンドを無視する。異なっている場合は、コマンドで要求された映像ビットレートCBRに切換えて配信を開始する(1506)。処理1503で、コマンドが配信開始要求でなければ、続いて、配信停止要求かどうかを判断する(1508)。コマンドが配信停止要求であれば、既に停止中かどうかを判断し(1509)、停止中でなければ映像データの配信を停止する(1510)。既に停止中の場合は、コマンドを無視する。処理1508において、コマンドが配信停止要求でない場合は、配信サーバ200の認識不可能なコマンドであるので、エラー処理を行う(1511)。エラー処理の例は、受信端末へコマンドが無効である旨を通知する等である。配信サーバ200が映像ビットレートを切換える方法として、外部から入力する映像データの中に、予め映像ビットレートテーブル800に示された複数種類の映像データを全て用意しておき、その中から受信端末100が指定した映像ビットレートの映像データを選択して配信するようにしても良い。また、配信サーバ200が外部から入力する映像データが１つの非圧縮の映像データである場合、受信端末100が指定した映像ビットレートとなる様に、例えば送信するフレーム数等のパラメータを変化させるなどして、所定の方法で変換した映像データを配信しても良い。さらに、配信サーバ200が外部から入力する映像データが１つの圧縮された映像データである場合、受信端末100が指定した映像ビットレートとなる様に、所定の方法で再変換した映像データを配信しても良い。
【００５１】
図16は、配信サーバ200において、配信映像データに監視トリガ情報を格納したuuidを多重する処理を示すフローチャートである。
【００５２】
まず、映像データ入力部201により、外部から映像データを入力する(1600)。次に、映像データ再構成部203により、入力した映像データの中から映像ビットレートCBRのフラグメントを抽出する(1601)。同時に、監視トリガ情報作成部207により、uuidに次のフラグメントの送信開始時刻をセットする(1602)。フラグメントがある一定時間毎に構成される場合は、基準タイマ206を参照して、今送信しようとしているフラグメントの送信時刻から、1つのフラグメント時刻分を加算して送信開始時刻を設定する。フラグメントの時間間隔が一定でない場合は、今送信しようとしているフラグメントの送信時刻に、今送信しようとしているフラグメントの再生時間を加算して、送信開始時刻を設定する。送信開始時刻は、映像データ再構成部203によりuuidと抽出フラグメントを多重して(1603)、映像データ送信部204により、受信端末100へ配信する(1604)。
【００５３】
図17は、受信端末100の全体動作を示すフローチャートである。
【００５４】
まず、映像データのストリーミングを開始し(1700)、基準タイマをセットする(1701)。ストリーミング中は、映像データ受信部102による映像データの受信(1703)と、再生部105による再生動作(1704)と並行して、受信ビットレート監視部110による受信ビットレート制御を実行する(1702)。この動作は、ストリーミングが終了するまで繰り返す(1705)。
【００５５】
図18は、受信端末100における受信ビットレート制御手順を示すフローチャートである。
【００５６】
まず、配信サーバ200に要求する映像データのモードnをセットする(1800)。映像ビットレートテーブル800により、モードnから映像ビットレートCBRが決まる。次に、映像ビットレート切換えポイントテーブル900を参照して上限ビットレートUBRと下限ビットレートBBRを取得し(1801)、映像ビットレートCBRの配信開始要求コマンドを配信サーバ200へ送信する(1802)。続いて、ストリーミングを終了するかどうかを判断し(1803)、終了する場合は、配信停止要求コマンドを配信サーバへ送信して処理を終了する(1814)。ストリーミングを継続する場合は、受信ビットレートRBRの測定を行い(1804)、上限ビットレートUBRと下限ビットレートBBRとの比較を行う(1805,1806)。受信ビットレートRBRが、上限ビットレートUBRと下限ビットレートBBRの範囲内であれば、現在のモードを維持する(1807)。モードを維持する場合は、配信サーバ200に対して要求コマンド送信は行わない。配信サーバが受信端末100の受信状態記録を保存する等の目的で、現在のモードを維持する場合も、その旨を配信サーバ200へ通知するようにしても良い。処理1805において、受信ビットレートRBRが上限ビットレートUBRを越えている場合は、現在より高い映像ビットレートのモードが指定可能かどうかを判断する(1808)。指定可能な場合は、現在の映像ビットレートCBRより高いモードを要求コマンドにセットし(1809)、配信サーバ200へ送信するために処理1801へ遷移する。指定不可能な場合は、エラー処理を行う(1810)。エラー処理の例は、受信端末100のモニタに、上位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。ただし、この場合は、受信ビットレートが上昇している方向であることから、エラー処理をスキップしても良い。処理1806において、受信ビットレートRBRが下限ビットレートBBRを下回っている場合は、現在より低い映像ビットレートのモードが指定可能かどうかを判断する(1811)。指定可能な場合は、現在の映像ビットレートCBRより低いモードを要求コマンドにセットし(1812)、配信サーバ200へ送信するために処理1801へ遷移する。指定不可能な場合は、エラー処理を行う(1813)。エラー処理の例は、受信端末100のモニタに、下位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。
【００５７】
図19は、受信端末100における上昇切換え感度および下降切換え感度を用いた受信ビットレート制御手順を示すフローチャートである。
【００５８】
まず、受信ビットレートの連続上昇回数を格納するカウンタucと、連続下降回数を格納するカウンタdcをゼロにリセットする(1901)。次に、上昇切換え感度uc_sinsiと下降切換え感度dc_snsiをセットする(1902)。同図の例では、両方の感度を3にセットする。続いて、配信サーバ200に要求する映像データのモードnをセットする(1903)。映像ビットレートテーブル800により、モードnから映像ビットレートCBRが決まる。次に、映像ビットレート切換えポイントテーブル900を参照して上限ビットレートUBRと下限ビットレートBBRを取得し(1904)、映像ビットレートCBRの配信開始要求コマンドを配信サーバ200へ送信する(1905)。続いて、ストリーミングを終了するかどうかを判断し(1906)、終了する場合は、配信停止要求コマンドを配信サーバへ送信して処理を終了する(1825)。ストリーミングを継続する場合は、受信ビットレートRBRの測定を行い(1907)、上限ビットレートUBRと下限ビットレートBBRとの比較を行う(1908,1909)。受信ビットレートRBRが、上限ビットレートUBRと下限ビットレートBBRの範囲内であれば、現在のモードを維持する(1910)。処理1908において、受信ビットレートRBRが上限ビットレートUBRを越えている場合は、現在より高い映像ビットレートのモードを指定可能かどうかを判断する(1911)。指定不可能な場合は、エラー処理を行い(1916)、連続上昇回数カウンタucをゼロにリセットする(1917)。エラー処理の例は、受信端末100のモニタに、上位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。ただし、この場合は、受信ビットレートが上昇している方向であることから、エラー処理をスキップしても良い。指定可能な場合は、受信ビットレートRBRと上限ビットレートUBRの比較結果が、前回の比較結果と同じかどうかを判断する(1912)。比較結果が異なる場合は、連続上昇回数カウンタucをゼロにリセットする(1917)。比較結果が同じ場合は、連続上昇回数カウンタucに1を加算し(1914)、上昇切換え感度uc_sinsiと連続上昇回数カウンタucが等しいかどうかを判断する(1914)。等しくない場合は、処理1906に遷移し通常の処理ループに戻る。等しい場合は、現在の映像ビットレートCBRより高いモードを要求コマンドにセットし(1915)、配信サーバ200へ送信するために処理1904へ遷移する。処理1909において、受信ビットレートRBRが下限ビットレートBBRを下回っている場合は、現在より低い映像ビットレートのモードを指定可能かどうかを判断する(1918)。指定不可能な場合は、エラー処理を行い(1923)、連続下降回数カウンタdcをゼロにリセットする(1924)。エラー処理の例は、受信端末100のモニタに、下位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。指定可能な場合は、受信ビットレートRBRと上限ビットレートBBRの比較結果が、前回の比較結果と同じかどうかを判断する(1919)。比較結果が異なる場合は、連続下降回数カウンタdcをゼロにリセットする(1924)。比較結果が同じ場合は、連続下降回数カウンタdcに1を加算し(1920)、下降切換え感度dc_sinsiと連続下降回数カウンタdcが等しいかどうかを判断する(1921)。等しくない場合は、処理1906に遷移し通常の処理ループに戻る。等しい場合は、現在の映像ビットレートCBRより低いモードを要求コマンドにセットし(1922)、配信サーバ200へ送信するために処理1904へ遷��する。
【００５９】
図20は、受信端末100における受信ビットレート測定の手順を示すフローチャートである。
【００６０】
まず、受信したフラグメントのuuidから監視トリガ時刻を読み出し(2000)、監視トリガ制御部109にセットする(2001)。同図の例では、監視トリガ時刻をTRGTとする。基準タイマ時刻と監視トリガ時刻TRGTを比較し、一致するまで待機する(2002)。時刻が一致したら、その時点の基準タイマ時刻TSを読み出す(2003)。時刻TRGTから新たなフラグメントの受信を開始するが、この時、同フラグメントのヘッダからフラグメントサイズFSIZEを読み出す(2004)。続いて、受信中のフラグメントのデータサイズをカウントし(2005)、カウントがFSIZEに達するまで繰り返す(2006)。カウントがFSIZEに達して、フラグメントの受信が完了したら、その時点の基準タイマ時刻TEを読み出す(2007)。最後に、受信ビットレートRBRを計算する(2008)。受信ビットレートRBRは、フラグメントサイズFSIZEを受信に要した時間(TE-TS)で除算した値である。図20に示した方法は、受信端末100において、バースト転送中のデータが着信している期間のみを捉えることができる。よって、例えば所定時間を測定する技術と比較して、データが着信していないバースト転送期間外も測定することがないので受信ビットレートの測定精度が向上し、正確な映像ビットレート切換え制御が実施できる。
【００６１】
受信端末100における映像ビットレート切換え要求のための受信状態の監視方法は、上記の方法に限らず別の方法で実施しても良い。例えば、図5の説明で記載した様に、監視トリガ情報として、フラグメントのヘッダ部分または動画と音声のデータ部分の配信予定時刻を格納するようにしても良い。さらに別の実施例として、配信サーバ200と受信端末100が同一クロックの発信器を内蔵している場合は、時刻情報の代わりに配信予定のクロックカウンタ値を、監視トリガ情報として格納するようにしても良い。クロックカウンタ値は、起動時からの積算クロック値でも良いし、前回のフラグメント配信からの相対クロック値でも良い。
【００６２】
図21は、本発明の配信サーバ200と受信端末100を用いた運用形態の一例を示す図である。
【００６３】
同図は、配信サーバ2100に、TV放送を受信するためのTV受信機2101と、インターネット等の外部公衆網2103と、外部公衆網2103から入力した映像データおよびTV受信機2101で受信したTV番組を所定の変換方法で変換した映像データを記録するための映像記憶装置2102と、無線を介してノートPC、PDA、携帯電話等のモバイル端末に接続するための送信局A(2103)、および送信局B(2104)が接続された構成例である。外部公衆網2103やTV受信機2101から取り込んだ映像データは、モバイル端末からの要求に応じてリアルタイムに配信を行う。また、外部公衆網2103やTV受信機2101から取り込んだ映像データを、一旦、映像記憶装置2102に蓄積しておき、モバイル端末からの要求に応じて適宜、映像データの配信を行うようにしても良い。送信局A(2103)を経由する配信では、ノートPC(2110)、PDA(2109)、携帯電話2108等のモバイル端末が直接映像データを受信して視聴する例である。送信局B(2104)を経由する配信では、さらに中継局A(2105)、無線公衆網2106、中継局B(2107)を経由し、モバイル端末(2111,2112,2113)で映像データを受信して視聴する。また、配信サーバから直接無線公衆網2106に出力する配信では、中継局B(2107)を経由し、モバイル端末(2111,2112,2113)で映像データを受信して視聴する。各配信経路においては、送信局、中継局および無線回線網を複数経由して映像データを配信するように構成しても良い。
【００６４】
図22は、本発明の配信サーバ200と受信端末100を用いた典型的な運用形態の例を示す図である。
【００６５】
映像データの配信は、受信端末100の要求により配信サーバ2201から送信され、無線公衆網2203と中継局2202を経由して、要求元の受信端末100に到着するように運用される。
【００６６】
ところで、これまでの説明では、受信端末100の要求に対応した映像ビットレート切換え操作を配信サーバ2201で実行するように述べてきたが、映像ビットレート切換え操作を中継局2202で実施するようにしても良い。これにより、中継局2202は自身がカバーするエリアに存在する受信端末2200に対してのみ、映像ビットレート切換え制御を実施すればよいことになり、配信側の処理負荷が減少する。また、受信端末100にとっては、切換え操作に伴うレスポンスが向上するという効果がある。
【００６７】
本発明の方法を適用した映像配信システムの課金形態の例としては、映像ビットレート切換えの有無に関わらず、1つの映像コンテンツ配信毎に定額料金を課金しても良い。また、映像ビットレート切換えの有無に関わらず、再生時間(配信時間)或いは配信データ量によって料金を課金しても良い。さらに、1つの映像コンテンツ配信毎、再生時間(配信時間)或いは配信データ量等、何れの課金条件においても、映像ビットレート切換えの内容を加味した課金としても良い。例えば、映像ビットレートが低い場合は、利用料金を低く加算し、映像ビットレートが高い場合は、利用料金を高く加算する等である。
映像コンテンツ配信毎の定額課金や、再生時間あるいは配信データ量に連動した課金方法等は、配信側における課金管理が容易であり、サービス利用者にとっても利用料金が把握し易いと言うメリットがある。一方、映像ビットレート切換え制御による配信映像や音声の品質は、映像ビットレートが低い場合には低品質傾向、映像ビットレートが高い場合に高品質傾向になる。このことから、映像ビットレート切換えの内容を加味した課金方法は、視聴の印象が課金にも反映されるため、利用料金について利用者の納得が得られ易いというメリットがある。
【００６８】
図23は、受信端末100のユーザインターフェースの一例を示す図である。
【００６９】
同図は、PDA等のモバイル端末のモニタに表示したGUI(Graphical User Interface)の例である。GUIは、動画表示枠2309、再生(映像配信開始要求)ボタン2301、停止(映像配信停止要求)ボタン2302、終了ボタン2303、映像ビットレートの自動および手動切換えボタン2304、映像ビットレートの手動選択ボタン(2305,2306,2307)、動作状態表示枠2308等で構成する。GUIは、これ以外にも、必要に応じて別の操作ボタンや表示枠を配置しても良い。携帯電話で実装する場合にはこれらの指示ボタンは電話番号入力キーやメニューキー等を用いておこなうように設定しておけば良い。受信端末2300はアンテナ2310を介してサーバから映像等の情報を受け取って、動画表示枠2309に逐次表示する。本願発明を適用すればこの動画のビットレートが制御される。映像ビットレート切換え制御は、受信端末2300が自動的に実行しても良いし、ユーザ自身が手動で切換えるようにしても良い。例えば、自動および手動切換えボタン2304を押す毎に、映像ビットレート切換え制御が自動モードと手動モードにトグルで切換わるようにする等である。手動モードの場合は、映像ビットレートの種類に対応した手動選択ボタン(2305,2306,2307)をユーザ自身が押すことによって切換わるようにしても良い。例えば、利用料金に映像ビットレート切換えの内容を加味した課金が適用されているサービスにおいて、ユーザが低料金で視聴したい場合に、低い映像ビットレートを連続して維持することもできる。また、切換え感度を伴う自動切換え制御を実行している場合において、自動による切換え条件に達していない時点であっても、映像品質に対するユーザの好みで自動制御を中断して切換え操作を行うこともできる。一般的に動画や音声の視聴の印象は、ユーザによってバラツキがある。多少の映像品質変動に対して寛容ユーザもいれば、変動に対して敏感なユーザもいる。このため、場合によっては、映像ビットレートを自動で切換えるよりも、手動切換えとすることで、より使い勝手が良いという印象を与えることができる。
インターネット等の有線のみを用いた映像配信においても、回線の運用状態の影響によってデータ転送速度の変動が生じる。しかし、一般的に有線回線は無線回線に比べてデータ転送帯域が遥かに広く、端末側における受信ビットレートの変動はほとんど問題ならないことが多い。一方、無線回線は、国際規格上の制約や通信デバイス性能の制限等から、データ転送帯域を広く確保することが現実的に困難な状況にある。また、無線の性質上、電波の減衰や反射等、周囲環境の影響も受け易いこともあり、データ転送速度の変動が頻繁に発生する。これまで述べてきた本発明の映像配信方法は、この様にデータ転送速度変動が発生し易い無線回線を使用した映像配信システムに適用した場合に、特に有効である。
【００７０】
本発明の映像配信装置が扱う配信データは、動画のみ、または音声のみのデータであっても良い。また、動画や音声以外のデータであってもかまわない。静止画データ、テキストデータ、SGML(Standard Generalized Markup Language)やHTML(Hyper Text Markup Language)などのWeb(World Wide Web)用データ等であっても良い。
【００７１】
【発明の効果】
データ転送速度変動が発生し易い無線回線を使用した映像配信システムにおいて、映像ストリーミング時に受信端末自身が正確に受信ビットレートを監視する機能を備え、その監視結果に応じて最適な映像ビットレートに切換えることをサーバへ要求することで、安定した映像ストリーミングが実行可能な手段を提供することが可能となる。
【図面の簡単な説明】
【図１】受信端末の構成を示す図。
【図２】配信サーバの構成を示す図。
【図３】映像データの構造を示す図。
【図４】  uuidの構造を示す図。
【図５】監視トリガ情報を格納したuuid生成の概念を示す図。
【図６】受信ビットレート監視のタイムチャート。
【図７】映像データ配信のデータ転送時間とビットレートの関係を示す図。
【図８】映像ビットレートテーブルの一例を示す図。
【図９】映像ビットレート切換えポイントテーブルの一例を示す図。
【図１０】映像ビットレートテーブルおよび映像ビットレート切換えポイントテーブルの使用形態を示す図。
【図１１】上位モードへの映像ビットレート切換え動作の一例を示す図。
【図１２】下位モードへの映像ビットレート切換え動作の一例を示す図。
【図１３】上位モードへの映像ビットレート切換え動作の別の一例を示す図。
【図１４】下位モードへの映像ビットレート切換え動作の別の一例を示す図。
【図１５】配信サーバの動作を示すフローチャート。
【図１６】配信映像データに監視トリガ情報を格納したuuidを多重する処理を示すフローチャート。
【図１７】受信端末の全体動作を示すフローチャート。
【図１８】受信ビットレート制御手順を示すフローチャート。
【図１９】上昇切換え感度および下降切換え感度を用いた受信ビットレート制御手順を示すフローチャート。
【図２０】受信ビットレート測定の手順を示すフローチャート。
【図２１】配信サーバと受信端末を用いた運用形態の一例を示す図。
【図２２】配信サーバと受信端末を用いた典型的な運用形態の例を示す図。
【図２３】受信端末のユーザインターフェースの一例を示す図。
【符号の説明】
100…受信端末、101…無線通信部、102…映像データ受信部、103…解析部、104…記憶部、105…再生部、106…モニタ、107…スピーカ、108…基準タイマ、109…監視トリガ制御部、110…受信ビットレート監視部、111…コマンド送信部、200…配信サーバ。
【図１】
0004288994.tif 000002
【図２】
0004288994.tif 000003
【図３】
0004288994.tif 000004
【図４】
0004288994.tif 000005
【図５】
0004288994.tif 000006
【図６】
0004288994.tif 000007
【図７】
0004288994.tif 000008
【図８】
0004288994.tif 000009
【図９】
0004288994.tif 000010
【図１０】
0004288994.tif 000011
【図１１】
0004288994.tif 000012
【図１２】
0004288994.tif 000013
【図１３】
0004288994.tif 000014
【図１４】
0004288994.tif 000015
【図１５】
0004288994.tif 000016
【図１６】
0004288994.tif 000017
【図１７】
0004288994.tif 000018
【図１８】
0004288994.tif 000019
【図１９】
0004288994.tif 000020
【図２０】
0004288994.tif 000021
【図２１】
0004288994.tif 000022
【図２２】
0004288994.tif 000023
【図２３】
0004288994.tif 000024