JP2004312569A

JP2004312569A - 配信サーバ及び端末装置

Info

Publication number: JP2004312569A
Application number: JP2003105956A
Authority: JP
Inventors: Yasuhiro Akiyama; 靖浩秋山; Junichi Kimura; 淳一木村; Toru Yokoyama; 徹横山
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-04-10
Filing date: 2003-04-10
Publication date: 2004-11-04
Anticipated expiration: 2023-04-10
Also published as: JP4288994B2; US7508760B2; US20040202109A1

Abstract

【課題】無線回線は、その性質上、電波の減衰や反射等、周囲環境の影響を受け易い。このため、映像ストリーミング時にデータ転送速度の変動が頻繁に発生し、受信端末において映像再生の障害となる。
【解決手段】配信サーバは、配信する映像データの中に、映像データの送信開始時刻を示す情報を多重する手段と、受信端末からの要求に応じて映像ビットレート切換える手段を備える。受信端末は、映像データの送信開始時刻を示す情報を使用して受信ビットレートを監視し、その結果に応じて最適な映像ビットレートの送信要求を配信サーバへ通知する手段を備える。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、配信サーバからモバイル端末に向けて符号化された映像データを、無線回線を経由してストリーミングを行う映像配信システムにおいて、モバイル端末における受信状態の監視結果に応じて、配信映像のビットレートを切換える装置およびその方法に関する。
【０００２】
【従来の技術】
近年、ブロードバンド技術の急速な立ち上がりと、携帯電話やＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｃｅ）等のモバイル端末の普及によって、セルラ電話通信網や無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）等の無線インフラを使用した映像ストリーミングサービスが拡大している。無線を使用したストリーミングで問題となるのは、電波受信状態の変動である。受信状態が変動すると、受信エラーが多発するためデータの再送処理が増加する。この影響でストリーミングデータの転送レートが変動し、映像再生が正しく実行できないケースが生じる。特に、受信状態が良好な状態から悪化方向に変換した場合の対応は、重要な課題となる。
【０００３】
映像配信システムにおける電波受信状態に応じた制御方法の従来技術として、電子メールシステムにおいて、受信端末が予め決められた時間間隔で電波の受信状態を監視し、その変化状況に応じて、配信サーバが配信するメールの送信順序を変更する方法がある（例えば、特許文献１参照）。
【０００４】
又、動画伝送装置による伝送方法において、受信端末が受信状態を示す情報を常に配信サーバに通知することで、配信サーバ側でデータ通信速度の制御を実行する方法もある（例えば、特許文献２参照）。
【０００５】
更に、携帯受信端末において、電波の受信状態と、配信映像の内容（スポーツ、ニュース等）を考慮してデータ通信速度の予測し、その予測結果を配信サーバに通知することで、データ通信速度の制御を実行する方法もある（例えば、特許文献３参照）。
【特許文献１】特開２０００−３４９８０８号公報
【特許文献２】特開２００１−６９４８３号公報
【特許文献３】特開２００２−３４４５６０号公報
【発明が解決しようとする課題】
前記の従来の技術に示した、特許文献１，３の方法は、受信端末における電波強度の観測によって受信状態を監視する手法である。しかし、ある１つの基地局に多数の受信端末が集中した場合等では、電波強度とデータ通信速度の関係は必ずしも比例しないケースがある。よってこの方法では、端末側の受信状態を完全に把握することができない。
【０００６】
特許文献２に記載の方法は、受信端末における受信状態を配信サーバが判断するために、受信端末が配信サーバに対して、常時、受信状態に関する情報を送り続ける方式である。このため、映像ストリーミング時は、受信端末が常に送信と受信を実行しなければならないため、回線利用効率が低下するとともに、受信端末の処理負荷が大きくなるという課題がある。
【０００７】
本発明は、上述の課題を解決するためのものであり、映像ストリーミング時に受信端末自身が正確に受信ビットレートを監視する機能を備え、その監視結果に応じて最適な映像ビットレートに切換えることを配信サーバへ要求することで、安定した映像ストリーミングが実行可能な手段を提供することを目的とする。
【０００８】
【課題を解決するための手段】
無線インフラを使用した映像配信システムにおいて、配信サーバには、配信する映像データの中に、映像データの送信開始時刻を示す情報を多重する手段と、受信端末からの要求に応じて映像ビットレート切換える手段を備える。また、受信端末は、映像データの送信開始時刻を示す情報を使用して受信ビットレートを監視し、その結果に応じて最適な映像ビットレートの送信要求を配信サーバへ通知する手段を備える。
【０００９】
【発明の実施の形態】
以下、本発明における映像配信装置および映像受信方法の実施の形態について説明する。
【００１０】
図１は、本発明の受信端末１００の構成を示す図である。
【００１１】
受信端末１００が受ける映像データは、ＭＰＥＧ等の所定の符号化方式で圧縮されたデータであり、配信サーバ２００から無線通信網１１２と中継局１１３を経由して受信端末１００に配信される。
【００１２】
無線通信部１０１は、配信サーバ２００と無線によるデータの送受信を行う。映像データ受信部１０２は、配信サーバ２００から送られる映像データの受信を行う。受信した映像データは、解析部１０３を経由して記憶部１０４に格納する。解析部１０３は、映像データに含まれている監視トリガ情報を抽出して監視トリガ制御部１０９へ通知することと、映像データのデータサイズを受信ビットレート監視部１１０へ通知を行う。監視トリガ情報とは、受信ビットレート監視部１１０が監視動作を開始する時刻を示す情報、又は受信ビットレート監視部が監視動作を開始するトリガとなる情報のことである。記憶部１０４は、映像データの一時的保存のために使用する。再生部１０５は、記憶部１０４から映像データを逐次読み出して伸張処理を行い、伸張後の動画はモニタ１０６に表示し、音声はスピーカ１０７に出力する。基準タイマ１０８は、動画と音声の同期再生の基準となるタイマである。また、基準タイマ１０８は、監視トリガ制御部１０９において、監視トリガ情報に含まれる時刻との比較にも使用する。監視トリガ制御部１０９は、基準タイマ１０８の時刻と監視トリガ情報に示された時刻を比較し、両方の時刻が一致した時に、受信ビットレート監視部１１０に対し、監視動作開始のトリガをかける。受信ビットレート監視部１１０は、監視トリガ制御部１０９からトリガがかけられた時点から受信ビットレートの監視を行う。監視結果が所定のビットレート範囲からずれた場合には、コマンド送信部１１１から配信サーバ２００に対して、映像データのビットレート切換えを要求する。監視結果が所定のビットレート範囲内であれば、配信サーバ２００に対するビットレート切換えは要求しない。コマンド送信部１１１は、配信サーバ２００に対する映像データの配信開始、配信停止および映像ビットレート切換え要求等のコマンドの送信を行う。
【００１３】
図２は、本発明の配信サーバ２００の構成を示す図である。
【００１４】
インターネット等の外部公衆網２１０を経由して送られてくる映像データを、映像データ入力部２０１で受け取り、記憶部２０２に格納する。基準タイマ２０６は、受信端末１００における映像データの再生時に使用する再生時刻情報を生成し、映像データ再構成部２０３に送る。監視トリガ情報作成部２０７は、基準タイマ２０６の時刻情報を参照して、受信端末１００の受信ビットレート監視部１１０が使用する監視トリガ情報を生成し、映像データ再構成部２０３に送る。映像データ再構成部２０３は、基準タイマ２０６からの再生時刻情報と、監視トリガ情報作成部２０７からの監視トリガ情報を、記憶部２０２から読み出した映像データに多重する。多重した映像データは、映像データ送信部２０４により、受信端末１００へ送信する。配信サーバ２００から送信した映像データは、図１でも示した通り、無線通信網１１２と中継局１１３を経由して、受信端末１００に送られる。無線通信部２０５は、受信端末１００と無線によるデータの送受信を行う。コマンド受信部２０８は、受信端末１００から送られた、配信開始、配信停止および映像ビットレート切換え要求等のコマンドを受け付ける。ビットレート切換え制御部２０９は、受信端末１００から映像ビットレート切換え要求コマンドを受信した場合に、現在配信中の映像ビットレートからコマンドに示された映像ビットレートへの切換えを行う。
【００１５】
図３は、映像データの構造を示す図である。
【００１６】
ある一つの映像データは、複数のフラグメント３００が連続している構造となっている。フラグメント３００とは、映像データを所定の再生時間長毎に分割し、各々に再生に必要な制御情報を付加した、あるまとまったデータ単位のことである。分割の基準となる時間長は、任意に設定でき、それぞれが異なる長さを持つものであっても良い。
【００１７】
図３（ａ）に、１つのフラグメント３００の構造を示す。フラグメント３００は、再生映像にオプション的に多重表示するためのテロップ文字列等、ユーザが任意に定義可能な付加情報を格納したｕｕｉｄ（ＵｎｉｖｅｒｓａｌＵｎｉｑｕｅＩｄｅｔｉｆｉｅｒ）（３０１）と、ランダムアクセス制御情報等の再生に必要な情報を格納したヘッダ３０２と、所定の再生時間長の動画と音声データ３０３とで構成する。同図に示した例では、フラグメント内のｕｕｉｄは１個であるが、ユーザ定義情報の個数に応じて複数個用意しても良い。本発明の映像配信方法では、その中のｕｕｉｄの一つに監視トリガ情報を格納する。監視トリガ情報は、受信端末１００において、受信ビットレート測定を開始するためのトリガとして使用する。１つのフラグメントのデータ転送はバースト転送である（詳細は図７で説明）。受信端末１００は、監視トリガ情報を参照することで、バースト転送開始時刻を正確に知ることができ、受信ビットレートの測定制度が向上する。監視トリガ情報は、映像データの送受信に関連する情報であり、映像再生とは直接関係のない情報である。従って、映像再生に関するオプション的な情報を格納することを目的としているｕｕｉｄに挿入するのが望ましい。また、ｕｕｉｄは、システム内で重複しないことが保障されたＩＤを用いて運用される。監視トリガ情報を必要としないシステムは、ＩＤ判別により、監視トリガ情報を無視することが可能であり、不本意な誤動作を防ぐ効果もある。もちろん、ｕｕｉｄ以外のヘッダ等に挿入することも可能である。
【００１８】
図３（ｂ）に、複数のフラグメント３００を連結した構造を示す図である。映像データのフラグメント３００の配置は、先頭から再生時刻順に並べられた構造となる。同図の例では、フラグメントｎ（３０４）が最初に再生され、その次にフラグメントｎ＋１（３０５）が再生される。図３（ａ）で示した通り、各々のフラグメントは、ｕｕｉｄ（３０１）と、ヘッダ（３０２）と、動画と音声データ（３０３）で構成する。
【００１９】
図４は、ｕｕｉｄ（３０１）の構造を示す図である。
【００２０】
ｕｕｉｄは、ユーザが任意に定義可能なデータであり、動画と音声データとは別に映像データに付加される。図４（ａ）に示すように、ｕｕｉｄ（３０１）は、ｕｕｉｄ全体のサイズ４０１と、「ｕｕｉｄ」を表すテキスト文字列（４０２）と、識別ＩＤ（４０３）と、データ部（４０４）で構成する。監視トリガ情報をｕｕｉｄ（３０１）に格納する場合、データ部（４０４）には、受信端末１００における受信ビットレート監視動作の開始を指示するトリガ時刻情報を格納する。図４（ｂ）は、監視トリガ情報を格納したｕｕｉｄ（３０１）の一例を示す図である。同図の例では、ｕｕｉｄサイズ４０５が２８バイトであることを示している。「ｕｕｉｄ」を表すテキスト文字列（４０６）は、ｕｕｉｄの種類を問わず共通であり、このテキスト文字列によりこのデータがｕｕｉｄであることが処理装置に認識される。識別ＩＤ（４０７）は、ｕｕｉｄの種類を認識するためのコードである。同図の例では、「ＴＲＩＧＴＩＭＥ＿０００００００」を表す文字列が監視トリガ情報であることを示すコードであり、受信端末１００は、この文字列を検出して監視トリガ情報を認識する。最後のデータ部に格納された「１２３４５６ｍｓｅｃ」が受信端末１００におけるトリガ時刻を表す情報である。
【００２１】
図５は、配信サーバ２００における監視トリガ情報を格納したｕｕｉｄ生成の概念を示す図である。
【００２２】
同図では、監視トリガ情報を格納したｕｕｉｄをＴＲＩＧｕｕｉｄとして示す。配信時刻Ｔ０（５０８）に配信するフラグメントｎ（５０５）のＴＲＩＧｕｕｉｄ（５０２）には、次のフラグメントｎ＋１（５０６）が配信される予定時刻Ｔ１（５０９）を格納する。同様に、配信時刻Ｔ１（５０９）に配信するフラグメントｎ＋１（５０６）のＴＲＩＧｕｕｉｄ（５０３）には、フラグメントｎ＋２（５０７）が配信される予定時刻Ｔ２（５１０）を格納し、配信時刻Ｔ２（５１０）に配信するフラグメントｎ＋２（５０７）のＴＲＩＧｕｕｉｄ（５０４）には、その後のフラグメントが配信される予定時刻Ｔ３（５１１）を格納する。この様に、ある配信時刻のフラグメントのＴＲＩＧｕｕｉｄには、必ず次に配信するフラグメントの配信予定時刻を格納する。
【００２３】
別の実施例として、ＴＲＩＧｕｕｉｄに同じフラグメントのヘッダ部分または動画と音声のデータ部分の配信予定時刻を格納するようにしても良い。この場合、ＴＲＩＧｕｕｉｄ部分は、受信ビットレート測定の対象外となるが、ＴＲＩＧｕｕｉｄのデータサイズは、後に続く動画と音声のデータ部分に比べて、ごく小さいので特に問題とならない。
【００２４】
さらに別の実施例として、配信サーバ２００と受信端末１００が同一クロックの発信器を内蔵している場合は、時刻情報の代わりに配信予定のクロックカウンタ値をＴＲＩＧｕｕｉｄに格納するようにしても良い。クロックカウンタ値は、起動時からの積算クロック値でも良いし、前回のフラグメント配信からの相対クロック値でも良い。
【００２５】
図６は、受信端末１００における受信ビットレート監視のタイムチャートを示す図である。
【００２６】
１つのフラグメントのデータ転送はバースト転送であるため、そのフラグメントの映像データ再生時間よりは短い時間でデータ転送は完了する。受信端末１００における受信ビットレートは、このバースト転送区間の時間と受信したデータサイズを測定することで計算する。例えば、受信端末１００でフラグメント受信時の処理は図６の様になる。まず、時刻Ｔ０（６１０）からフラグメント１（６１４）を受信し（６００）、監視トリガ情報が格納されているＴＲＩＧｕｕｉｄを解析部（１０３）で解析する（６０１）。このＴＲＩＧｕｕｉｄには、次のフラグメント２の受信時刻Ｔ１（６１１）が格納されている。受信端末１００の監視トリガ制御部１０９は、受信時刻Ｔ１（６１１）に備えて基準タイマ１０８との時刻比較処理を作動させる（６０２）。時刻がＴ１（６１１）に達した時点から配信サーバ２００はフラグメント２（６１５）の配信を開始する。受信端末１００は、時刻Ｔ１（６１１）からフラグメント２（６１５）のデータ受信を行い（６０５）、同時に受信ビットレート測定を開始する（６０３）。また、フラグメント２（６０５）のヘッダには、フラグメントのデータサイズが格納されている。このデータサイズを読み出して、フラグメント２のデータ受信の終了と受信ビットレート測定の終了の検出に使用する。この後のフラグメント２（６１５）とフラグメント３（６１６）のデータ受信時も同様に、フラグメントのデータ受信（６０５）、ＴＲＩＧｕｕｉｄ解析（６０６）、監視トリガのタイマ作動（６０７）、受信ビットレート測定（６０８）、フラグメントサイズ解析（６０９）の順序で実行する。
【００２７】
図７は、映像データ配信の典型的なデータ転送時間とビットレートの関係を示す図である。
【００２８】
図６でも説明した様に、１つのフラグメントのデータ転送はバースト転送であるため、そのフラグメントの映像データ再生時間よりは短い時間でデータ転送は完了する。データ転送の時間は、無線回線の転送周波数で決まる。受信端末１００で映像ビットレートＣＢＲ（７０６）、映像再生時間Ｆｔｓ１秒（７０７）の映像データのフラグメントを受信すると、映像ビットレートＣＢＲ（７０６）よりも高速な受信ビットレートＲＢＲ（７０５）で受信するため、映像再生時間Ｆｔｓ１秒（７０７）よりも短いＢｔｓ１秒（７１０）でデータ受信が完了する。各フラグメント（７０１，７０２，７０３）のサイズと受信ビットレートＲＢＲ（７０５）が一定と仮定すれば、フラグメント受信時間（７１０，７１１，７１２）も一定となる。しかし、実際には、フラグメント毎にフラグメントサイズと受信ビットレートが変動するため、フラグメント受信時間は図７に示すように一定の値とはならない。
【００２９】
図８は、映像ビットレートテーブル８００の一例を示す図である。
【００３０】
映像ビットレートテーブル８００は、配信サーバ２００が配信可能な映像ビットレートＣＢＲ（７０６）の種類を示すテーブルである。同テーブルは、配信サーバ２００と受信端末１００の両方が使用する。
同図の例では、１００ｋｂｐｓ、２００ｋｂｐｓ、３００ｋｂｐｓの３種類の映像ビットレートが配信可能であることを表している。映像ビットレートの設定数は任意で良く、ビットレート値も任意に設定できる。映像ビットレートＣＢＲ（７０６）の種類を識別するために、モード８０１を用いる。同図では、モード０（８０２）が１００ｋｂｐｓ、モード１（８０３）が２００ｋｂｐｓ、モード２（８０４）が３００ｋｂｐｓである。
【００３１】
同一映像において複数個のビットレートを用意する場合、映像の画質、音声の品質、画像サイズ、画像の所定単位あたりの表示枚数等を変更することによって送るべきデータ量を変化させ、ビットレートを変化させることになる。
映像ビットレートテーブル８００は、受信端末１００の受信ビットレート監視部１１０が参照する。同テーブルは、受信端末１００の所定の専用メモリを設けて格納しても良いし、記憶部１０４の一部に格納するようにしても良い。また、配信サーバ２００では、ビットレート切換え制御部２０９が参照する。同テーブルは、受信端末１００と同様に所定の専用メモリに格納しても良いし、記憶部２０２の一部に格納するようにしても良い。
【００３２】
図９は、映像ビットレート切換えポイントテーブル９００の一例を示す図である。
【００３３】
映像ビットレート切換えポイントテーブル９００は、受信端末１００の受信ビットレート監視部１１０で測定した受信ビットレートとの比較するために使用し、配信サーバに対して別の映像ビットレートに切換えるかどうかを判断するために参照するテーブルである。同テーブルは、受信端末１００が使用し、
映像ビットレートのモード９０３毎に、上限ビットレートＵＢＲ（９０１）、下限ビットレートＢＢＲ（９０２）の情報で構成する。モード９０３の種類は、映像ビットレートテーブル８００と一致するように設定する。上限ビットレートＵＢＲ（９０１）と下限ビットレートＢＢＲ（９０２）は、配信サーバ２００が配信するフラグメントサイズと使用する無線回線の転送周波数との性能関係に基づいて設定する。同図の例では、モード１（９０５）を受信中の場合、受信ビットレートが１．８Ｍｂｐｓから２．２Ｍｂｐｓの間ならば、映像ビットレート切換えを行わないことを表している。１．８Ｍｂｐｓを下回った場合はモード０（９０４）に切換え、２．２Ｍｂｐｓを上回った場合はモード２（９０６）に切換える。モード０（９０４）を受信中の場合、受信ビットレートが１．２Ｍｂｐｓを上回らなければ、映像ビットレート切換えを行わないことを表している。１．２Ｍｂｐｓを上回った場合はモード１（９０５）に切換える。同図の例では、モード０（９０４）以下の映像ビットレートは存在しないので、下限ビットレートＢＢＲ（９０２）は設定しない。モード２（９０６）を受信中の場合、受信ビットレートが２．８Ｍｂｐｓを下回らなければ、映像ビットレート切換えを行わないことを表している。２．８Ｍｂｐｓを下回った場合はモード１（９０５）に切換える。同図の例では、モード２（９０６）以上の映像ビットレートは存在しないので、上限ビットレートＵＢＲ（９０１）は設定しない。図９に示す規定以外にも、各モードに対応するビットレートを特定するための情報が記録されれば良い。
【００３４】
映像ビットレート切換えポイントテーブル９００は、受信端末１００の受信ビットレート監視部１１０が参照する。同テーブルは、受信端末１００の所定の専用メモリを設けて格納しても良いし、記憶部１０４の一部に格納するようにしても良い。
【００３５】
図１０は、映像ビットレートテーブル８００および映像ビットレート切換えポイントテーブル９００の使用形態を示す図である。
【００３６】
映像ビットレートテーブル８００は、配信サーバ２００と受信端末１００の両方が使用する。ある配信サーバ１０００と接続関係にある受信端末１（１００１）および受信端末２（１００２）は、配信サーバ１０００が持つ映像ビットレートテーブル１００５と同一内容のテーブル（１００８，１０１０）を持つ。別の実施例として、受信端末１００は、配信サーバ２００へ映像ビットレートを指定する方法として、映像ビットレート値を示すデータを直接送信するようにし、配信サーバは、指定された映像ビットレートに基づいて映像データを再構成するようにしても良い。この場合、配信サーバ２００は、映像ビットレートテーブル８００を使用しなくとも良い。映像ビットレート切換えポイントテーブル９００は、受信端末１００が使用する。同テーブルの内容は、無線回線の転送周波数に依存するため無線網毎に用意する必要がある。例えば、無線網１（１００３）に接続されている受信端末１（１００１）の映像ビットレート切換えポイントテーブル１００９と、無線網２（１００４）に接続されている受信端末２（１００２）の映像ビットレート切換えポイントテーブル１０１１は、モード毎の設定内容が異なる。
【００３７】
これら２つのテーブルは、配信サーバ１０００、受信端末１（１００１）、受信端末２（１００２）に予め設定しておくこともできる。また、受信端末が異なる無線網を移動することも考えられるので、映像データの配信開始前に、配信サーバ１０００から受信端末１００１，１００２へ中継する無線網に対応するテーブルを送信するようにしても良い。データ転送性能の異なる無線網では、転送能力の違いから映像ビットレート切換えポイントが異なるため、テーブルを切換えずに運用すると、誤動作を引き起こす原因となる。従って、ストリーミングを開始する時点、および無線網が切換わった時点でテーブルを送信するようにすれば、映像ビットレート切換えの誤動作を防ぐことができる。
この様にすることで、受信端末１００がデータ転送性能の異なる無線網を移動した場合でも、各々の無線回線に最適なテーブルを用いて映像ビットレート切換えを運用することができる。
【００３８】
図１１は、上位モードへの映像ビットレート切換え動作の一例を示す図である。
【００３９】
受信端末１００が、図８と図９で示した映像ビットレートテーブル８００および映像ビットレート切換えポイントテーブル９００を使用し、モード１の映像データを受信していると仮定する。モード１において映像ビットレートを維持する受信ビットレートＲＢＲ（１１０４）範囲は、１．８Ｍｂｐｓから２．２Ｍｂｐｓである。受信１（１１００）と受信２（１１０１）の受信ビットレートＲＢＲ（１１０４）は２．０Ｍｂｐｓなので、映像ビットレート切換えは行わない。受信３（１１０２）の時点で、受信ビットレートＲＢＲ（１１０４）が２．２Ｍｂｐｓを越えたので、配信サーバ２００に対してモード１からモード２への映像ビットレート切換え１１０５を要求する。これによってサーバがビットレートを切り換え、受信４（１１０３）からは、端末はモード２の映像データを受信することになる。
【００４０】
図８で説明した通り、モード切換え前後の映像ビットレートの差による映像の違いは、映像の画質、音声の品質、画像サイズ、画像の所定単位あたりの表示枚数等である。
【００４１】
図１２は、下位モードへの映像ビットレート切換え動作の一例を示す図である。
【００４２】
図１１と同様に、受信端末１００が、図８と図９で示した映像ビットレートテーブル８００および映像ビットレート切換えポイントテーブル９００を使用し、モード１の映像データを受信していると仮定する。受信１（１２００）と受信２（１２０１）の受信ビットレートＲＢＲ（１２０４）は２．０Ｍｂｐｓなので、映像ビットレート切換えは行わない。受信３（１２０２）の時点で、受信ビットレートＲＢＲ（１２０４）が１．８Ｍｂｐｓを下回ったので、配信サーバ２００に対してモード１からモード０への映像ビットレート切換え１２０５を要求する。受信４（１２０３）からは、モード０の映像データを受信することになる。
【００４３】
図１３は、上位モードへの映像ビットレート切換え動作の別の一例を示す図である。
【００４４】
受信ビットレートが連続して急激に変動する場合、映像ビットレート切換えが多発して、映像データ配信の負荷となる場合が考えられる。この場合は、映像ビットレート切換えを判断する部分に感度を持たせて、切換えの発生回数を減らすように制御しても良い。
【００４５】
同図は、上位モードへの切換える場合に、上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）を設定した例である。上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）とは、受信ビットレートＲＢＲ（１３０５）が何回連続して越えたら映像ビットレート切換えを要求するかを示す数値である。例えば、上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）を３に設定し、モード１の映像データを受信していると仮定する。受信１（１３００）の時点では、受信ビットレートＲＢＲ（１３０５）が２．０Ｍｂｐｓなので、映像ビットレート切換えは行わない。受信２（１３０１）、受信３（１３０２）、受信４（１３０３）において、受信ビットレートＲＢＲ（１３０５）が３回連続して２．０Ｍｂｐｓを越えたので、配信サーバ２００に対してモード１からモード２への映像ビットレート切換え１３０６を要求する。受信５（１３０４）からは、モード２の映像データを受信することになる。上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）は、受信端末１００の受信ビットレート監視部１１０が保持する。上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）の最大値は、記憶部１０４の映像データの蓄積容量に依存する。少なくとも、映像ビットレート切換えを見送る回数（すなわち切換え感度の値）と同等のフラグメントの映像データが、常に再生より先行して記憶部１０４に格納されている必要がある。上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）は、記憶部１０４の容量と、映像ビットレートから導かれる１つのフラグメントのデータサイズの平均値等から計算して、受信端末１００が自動的に設定することができる。また、ユーザが任意に設定するようにしても良い。
【００４６】
図１４は、下位モードへの映像ビットレート切換え動作の別の一例を示す図である。
【００４７】
図１３に示した上昇切換え感度を使用した映像ビットレート切換え方法は、下位モードへの映像ビットレート切換え動作にも適用できる。同図では、下降切換え感度ｄｃ＿ｓｅｎｓｉ（１４０７）を３に設定し、モード１の映像データを受信していると仮定する。受信１（１４００）の時点では、受信ビットレートＲＢＲ（１４０５）が２．０Ｍｂｐｓなので、映像ビットレート切換えは行わない。受信２（１４０１）、受信３（１４０２）、受信４（１４０３）において、受信ビットレートＲＢＲ（１４０５）が３回連続して１．８Ｍｂｐｓを下回ったので、配信サーバ２００に対してモード１からモード０への映像ビットレート切換え１４０６を要求する。受信５（１４０４）からは、モード０の映像データを受信することになる。
【００４８】
下降切換え感度ｄｃ＿ｓｅｎｓｉ（１４０７）は、受信端末１００の受信ビットレート監視部１１０が保持する。また、下降切換え感度ｄｃ＿ｓｅｎｓｉ（１４０７）の設定方法も、上昇切換え感度ｕｃ＿ｓｅｎｓｉ（１３０７）の場合と同様である。
【００４９】
図１５は、配信サーバ２００の動作を示すフローチャートである。
【００５０】
まず、配信サーバ２００の動作を停止するかどうかを判断する（１５００）。動作継続の場合、受信端末１００からコマンド受信があるかどうかを判断する（１５０１）。動作停止の場合、現在映像データ配信中かどうかを判断し（１５１２）、配信中ならば配信を停止（１５１３）して処理を終了する。動作継続において、コマンド受信があった場合は、そのコマンドを解析し（１５０２）、映像ビットレートＣＢＲでの配信開始要求かどうかを判断する（１５０３）。配信開始要求ならば、既に映像データ配信中かどうかを判断する（１５０４）。配信中でなければ、映像ビットレートＣＢＲの映像データ配信を開始する（１５０７）。既に映像データ配信中ならば、配信中の映像ビットレートが要求された映像ビットレートＣＢＲと同じであるかどうかを判断する（１５０５）。映像ビットレートＣＢＲが、配信中の映像ビットレートと同じ場合は、コマンドを無視する。異なっている場合は、コマンドで要求された映像ビットレートＣＢＲに切換えて配信を開始する（１５０６）。処理１５０３で、コマンドが配信開始要求でなければ、続いて、配信停止要求かどうかを判断する（１５０８）。コマンドが配信停止要求であれば、既に停止中かどうかを判断し（１５０９）、停止中でなければ映像データの配信を停止する（１５１０）。既に停止中の場合は、コマンドを無視する。処理１５０８において、コマンドが配信停止要求でない場合は、配信サーバ２００の認識不可能なコマンドであるので、エラー処理を行う（１５１１）。エラー処理の例は、受信端末へコマンドが無効である旨を通知する等である。配信サーバ２００が映像ビットレートを切換える方法として、外部から入力する映像データの中に、予め映像ビットレートテーブル８００に示された複数種類の映像データを全て用意しておき、その中から受信端末１００が指定した映像ビットレートの映像データを選択して配信するようにしても良い。また、配信サーバ２００が外部から入力する映像データが１つの非圧縮の映像データである場合、受信端末１００が指定した映像ビットレートとなる様に、例えば送信するフレーム数等のパラメータを変化させるなどして、所定の方法で変換した映像データを配信しても良い。さらに、配信サーバ２００が外部から入力する映像データが１つの圧縮された映像データである場合、受信端末１００が指定した映像ビットレートとなる様に、所定の方法で再変換した映像データを配信しても良い。
【００５１】
図１６は、配信サーバ２００において、配信映像データに監視トリガ情報を格納したｕｕｉｄを多重する処理を示すフローチャートである。
【００５２】
まず、映像データ入力部２０１により、外部から映像データを入力する（１６００）。次に、映像データ再構成部２０３により、入力した映像データの中から映像ビットレートＣＢＲのフラグメントを抽出する（１６０１）。同時に、監視トリガ情報作成部２０７により、ｕｕｉｄに次のフラグメントの送信開始時刻をセットする（１６０２）。フラグメントがある一定時間毎に構成される場合は、基準タイマ２０６を参照して、今送信しようとしているフラグメントの送信時刻から、１つのフラグメント時刻分を加算して送信開始時刻を設定する。フラグメントの時間間隔が一定でない場合は、今送信しようとしているフラグメントの送信時刻に、今送信しようとしているフラグメントの再生時間を加算して、送信開始時刻を設定する。送信開始時刻は、映像データ再構成部２０３によりｕｕｉｄと抽出フラグメントを多重して（１６０３）、映像データ送信部２０４により、受信端末１００へ配信する（１６０４）。
【００５３】
図１７は、受信端末１００の全体動作を示すフローチャートである。
【００５４】
まず、映像データのストリーミングを開始し（１７００）、基準タイマをセットする（１７０１）。ストリーミング中は、映像データ受信部１０２による映像データの受信（１７０３）と、再生部１０５による再生動作（１７０４）と並行して、受信ビットレート監視部１１０による受信ビットレート制御を実行する（１７０２）。この動作は、ストリーミングが終了するまで繰り返す（１７０５）。
【００５５】
図１８は、受信端末１００における受信ビットレート制御手順を示すフローチャートである。
【００５６】
まず、配信サーバ２００に要求する映像データのモードｎをセットする（１８００）。映像ビットレートテーブル８００により、モードｎから映像ビットレートＣＢＲが決まる。次に、映像ビットレート切換えポイントテーブル９００を参照して上限ビットレートＵＢＲと下限ビットレートＢＢＲを取得し（１８０１）、映像ビットレートＣＢＲの配信開始要求コマンドを配信サーバ２００へ送信する（１８０２）。続いて、ストリーミングを終了するかどうかを判断し（１８０３）、終了する場合は、配信停止要求コマンドを配信サーバへ送信して処理を終了する（１８１４）。ストリーミングを継続する場合は、受信ビットレートＲＢＲの測定を行い（１８０４）、上限ビットレートＵＢＲと下限ビットレートＢＢＲとの比較を行う（１８０５，１８０６）。受信ビットレートＲＢＲが、上限ビットレートＵＢＲと下限ビットレートＢＢＲの範囲内であれば、現在のモードを維持する（１８０７）。モードを維持する場合は、配信サーバ２００に対して要求コマンド送信は行わない。配信サーバが受信端末１００の受信状態記録を保存する等の目的で、現在のモードを維持する場合も、その旨を配信サーバ２００へ通知するようにしても良い。処理１８０５において、受信ビットレートＲＢＲが上限ビットレートＵＢＲを越えている場合は、現在より高い映像ビットレートのモードが指定可能かどうかを判断する（１８０８）。指定可能な場合は、現在の映像ビットレートＣＢＲより高いモードを要求コマンドにセットし（１８０９）、配信サーバ２００へ送信するために処理１８０１へ遷移する。指定不可能な場合は、エラー処理を行う（１８１０）。エラー処理の例は、受信端末１００のモニタに、上位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。ただし、この場合は、受信ビットレートが上昇している方向であることから、エラー処理をスキップしても良い。処理１８０６において、受信ビットレートＲＢＲが下限ビットレートＢＢＲを下回っている場合は、現在より低い映像ビットレートのモードが指定可能かどうかを判断する（１８１１）。指定可能な場合は、現在の映像ビットレートＣＢＲより低いモードを要求コマンドにセットし（１８１２）、配信サーバ２００へ送信するために処理１８０１へ遷移する。指定不可能な場合は、エラー処理を行う（１８１３）。エラー処理の例は、受信端末１００のモニタに、下位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。
【００５７】
図１９は、受信端末１００における上昇切換え感度および下降切換え感度を用いた受信ビットレート制御手順を示すフローチャートである。
【００５８】
まず、受信ビットレートの連続上昇回数を格納するカウンタｕｃと、連続下降回数を格納するカウンタｄｃをゼロにリセットする（１９０１）。次に、上昇切換え感度ｕｃ＿ｓｉｎｓｉと下降切換え感度ｄｃ＿ｓｎｓｉをセットする（１９０２）。同図の例では、両方の感度を３にセットする。続いて、配信サーバ２００に要求する映像データのモードｎをセットする（１９０３）。映像ビットレートテーブル８００により、モードｎから映像ビットレートＣＢＲが決まる。次に、映像ビットレート切換えポイントテーブル９００を参照して上限ビットレートＵＢＲと下限ビットレートＢＢＲを取得し（１９０４）、映像ビットレートＣＢＲの配信開始要求コマンドを配信サーバ２００へ送信する（１９０５）。続いて、ストリーミングを終了するかどうかを判断し（１９０６）、終了する場合は、配信停止要求コマンドを配信サーバへ送信して処理を終了する（１８２５）。ストリーミングを継続する場合は、受信ビットレートＲＢＲの測定を行い（１９０７）、上限ビットレートＵＢＲと下限ビットレートＢＢＲとの比較を行う（１９０８，１９０９）。受信ビットレートＲＢＲが、上限ビットレートＵＢＲと下限ビットレートＢＢＲの範囲内であれば、現在のモードを維持する（１９１０）。処理１９０８において、受信ビットレートＲＢＲが上限ビットレートＵＢＲを越えている場合は、現在より高い映像ビットレートのモードを指定可能かどうかを判断する（１９１１）。指定不可能な場合は、エラー処理を行い（１９１６）、連続上昇回数カウンタｕｃをゼロにリセットする（１９１７）。エラー処理の例は、受信端末１００のモニタに、上位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。ただし、この場合は、受信ビットレートが上昇している方向であることから、エラー処理をスキップしても良い。指定可能な場合は、受信ビットレートＲＢＲと上限ビットレートＵＢＲの比較結果が、前回の比較結果と同じかどうかを判断する（１９１２）。比較結果が異なる場合は、連続上昇回数カウンタｕｃをゼロにリセットする（１９１７）。比較結果が同じ場合は、連続上昇回数カウンタｕｃに１を加算し（１９１４）、上昇切換え感度ｕｃ＿ｓｉｎｓｉと連続上昇回数カウンタｕｃが等しいかどうかを判断する（１９１４）。等しくない場合は、処理１９０６に遷移し通常の処理ループに戻る。等しい場合は、現在の映像ビットレートＣＢＲより高いモードを要求コマンドにセットし（１９１５）、配信サーバ２００へ送信するために処理１９０４へ遷移する。処理１９０９において、受信ビットレートＲＢＲが下限ビットレートＢＢＲを下回っている場合は、現在より低い映像ビットレートのモードを指定可能かどうかを判断する（１９１８）。指定不可能な場合は、エラー処理を行い（１９２３）、連続下降回数カウンタｄｃをゼロにリセットする（１９２４）。エラー処理の例は、受信端末１００のモニタに、下位モードへの映像ビットレート切換えが実行できない旨のメッセージを表示する等である。指定可能な場合は、受信ビットレートＲＢＲと上限ビットレートＢＢＲの比較結果が、前回の比較結果と同じかどうかを判断する（１９１９）。比較結果が異なる場合は、連続下降回数カウンタｄｃをゼロにリセットする（１９２４）。比較結果が同じ場合は、連続下降回数カウンタｄｃに１を加算し（１９２０）、下降切換え感度ｄｃ＿ｓｉｎｓｉと連続下降回数カウンタｄｃが等しいかどうかを判断する（１９２１）。等しくない場合は、処理１９０６に遷移し通常の処理ループに戻る。等しい場合は、現在の映像ビットレートＣＢＲより低いモードを要求コマンドにセットし（１９２２）、配信サーバ２００へ送信するために処理１９０４へ遷移する。
【００５９】
図２０は、受信端末１００における受信ビットレート測定の手順を示すフローチャートである。
【００６０】
まず、受信したフラグメントのｕｕｉｄから監視トリガ時刻を読み出し（２０００）、監視トリガ制御部１０９にセットする（２００１）。同図の例では、監視トリガ時刻をＴＲＧＴとする。基準タイマ時刻と監視トリガ時刻ＴＲＧＴを比較し、一致するまで待機する（２００２）。時刻が一致したら、その時点の基準タイマ時刻ＴＳを読み出す（２００３）。時刻ＴＲＧＴから新たなフラグメントの受信を開始するが、この時、同フラグメントのヘッダからフラグメントサイズＦＳＩＺＥを読み出す（２００４）。続いて、受信中のフラグメントのデータサイズをカウントし（２００５）、カウントがＦＳＩＺＥに達するまで繰り返す（２００６）。カウントがＦＳＩＺＥに達して、フラグメントの受信が完了したら、その時点の基準タイマ時刻ＴＥを読み出す（２００７）。最後に、受信ビットレートＲＢＲを計算する（２００８）。受信ビットレートＲＢＲは、フラグメントサイズＦＳＩＺＥを受信に要した時間（ＴＥ−ＴＳ）で除算した値である。図２０に示した方法は、受信端末１００において、バースト転送中のデータが着信している期間のみを捉えることができる。よって、例えば所定時間を測定する技術と比較して、データが着信していないバースト転送期間外も測定することがないので受信ビットレートの測定精度が向上し、正確な映像ビットレート切換え制御が実施できる。
【００６１】
受信端末１００における映像ビットレート切換え要求のための受信状態の監視方法は、上記の方法に限らず別の方法で実施しても良い。例えば、図５の説明で記載した様に、監視トリガ情報として、フラグメントのヘッダ部分または動画と音声のデータ部分の配信予定時刻を格納するようにしても良い。さらに別の実施例として、配信サーバ２００と受信端末１００が同一クロックの発信器を内蔵している場合は、時刻情報の代わりに配信予定のクロックカウンタ値を、監視トリガ情報として格納するようにしても良い。クロックカウンタ値は、起動時からの積算クロック値でも良いし、前回のフラグメント配信からの相対クロック値でも良い。
【００６２】
図２１は、本発明の配信サーバ２００と受信端末１００を用いた運用形態の一例を示す図である。
【００６３】
同図は、配信サーバ２１００に、ＴＶ放送を受信するためのＴＶ受信機２１０１と、インターネット等の外部公衆網２１０３と、外部公衆網２１０３から入力した映像データおよびＴＶ受信機２１０１で受信したＴＶ番組を所定の変換方法で変換した映像データを記録するための映像記憶装置２１０２と、無線を介してノートＰＣ、ＰＤＡ、携帯電話等のモバイル端末に接続するための送信局Ａ（２１０３）、および送信局Ｂ（２１０４）が接続された構成例である。外部公衆網２１０３やＴＶ受信機２１０１から取り込んだ映像データは、モバイル端末からの要求に応じてリアルタイムに配信を行う。また、外部公衆網２１０３やＴＶ受信機２１０１から取り込んだ映像データを、一旦、映像記憶装置２１０２に蓄積しておき、モバイル端末からの要求に応じて適宜、映像データの配信を行うようにしても良い。送信局Ａ（２１０３）を経由する配信では、ノートＰＣ（２１１０）、ＰＤＡ（２１０９）、携帯電話２１０８等のモバイル端末が直接映像データを受信して視聴する例である。送信局Ｂ（２１０４）を経由する配信では、さらに中継局Ａ（２１０５）、無線公衆網２１０６、中継局Ｂ（２１０７）を経由し、モバイル端末（２１１１，２１１２，２１１３）で映像データを受信して視聴する。また、配信サーバから直接無線公衆網２１０６に出力する配信では、中継局Ｂ（２１０７）を経由し、モバイル端末（２１１１，２１１２，２１１３）で映像データを受信して視聴する。各配信経路においては、送信局、中継局および無線回線網を複数経由して映像データを配信するように構成しても良い。
【００６４】
図２２は、本発明の配信サーバ２００と受信端末１００を用いた典型的な運用形態の例を示す図である。
【００６５】
映像データの配信は、受信端末１００の要求により配信サーバ２２０１から送信され、無線公衆網２２０３と中継局２２０２を経由して、要求元の受信端末１００に到着するように運用される。
【００６６】
ところで、これまでの説明では、受信端末１００の要求に対応した映像ビットレート切換え操作を配信サーバ２２０１で実行するように述べてきたが、映像ビットレート切換え操作を中継局２２０２で実施するようにしても良い。これにより、中継局２２０２は自身がカバーするエリアに存在する受信端末２２００に対してのみ、映像ビットレート切換え制御を実施すればよいことになり、配信側の処理負荷が減少する。また、受信端末１００にとっては、切換え操作に伴うレスポンスが向上するという効果がある。
【００６７】
本発明の方法を適用した映像配信システムの課金形態の例としては、映像ビットレート切換えの有無に関わらず、１つの映像コンテンツ配信毎に定額料金を課金しても良い。また、映像ビットレート切換えの有無に関わらず、再生時間（配信時間）或いは配信データ量によって料金を課金しても良い。さらに、１つの映像コンテンツ配信毎、再生時間（配信時間）或いは配信データ量等、何れの課金条件においても、映像ビットレート切換えの内容を加味した課金としても良い。例えば、映像ビットレートが低い場合は、利用料金を低く加算し、映像ビットレートが高い場合は、利用料金を高く加算する等である。
映像コンテンツ配信毎の定額課金や、再生時間あるいは配信データ量に連動した課金方法等は、配信側における課金管理が容易であり、サービス利用者にとっても利用料金が把握し易いと言うメリットがある。一方、映像ビットレート切換え制御による配信映像や音声の品質は、映像ビットレートが低い場合には低品質傾向、映像ビットレートが高い場合に高品質傾向になる。このことから、映像ビットレート切換えの内容を加味した課金方法は、視聴の印象が課金にも反映されるため、利用料金について利用者の納得が得られ易いというメリットがある。
【００６８】
図２３は、受信端末１００のユーザインターフェースの一例を示す図である。
【００６９】
同図は、ＰＤＡ等のモバイル端末のモニタに表示したＧＵＩ（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ）の例である。ＧＵＩは、動画表示枠２３０９、再生（映像配信開始要求）ボタン２３０１、停止（映像配信停止要求）ボタン２３０２、終了ボタン２３０３、映像ビットレートの自動および手動切換えボタン２３０４、映像ビットレートの手動選択ボタン（２３０５，２３０６，２３０７）、動作状態表示枠２３０８等で構成する。ＧＵＩは、これ以外にも、必要に応じて別の操作ボタンや表示枠を配置しても良い。携帯電話で実装する場合にはこれらの指示ボタンは電話番号入力キーやメニューキー等を用いておこなうように設定しておけば良い。受信端末２３００はアンテナ２３１０を介してサーバから映像等の情報を受け取って、動画表示枠２３０９に逐次表示する。本願発明を適用すればこの動画のビットレートが制御される。映像ビットレート切換え制御は、受信端末２３００が自動的に実行しても良いし、ユーザ自身が手動で切換えるようにしても良い。例えば、自動および手動切換えボタン２３０４を押す毎に、映像ビットレート切換え制御が自動モードと手動モードにトグルで切換わるようにする等である。手動モードの場合は、映像ビットレートの種類に対応した手動選択ボタン（２３０５，２３０６，２３０７）をユーザ自身が押すことによって切換わるようにしても良い。例えば、利用料金に映像ビットレート切換えの内容を加味した課金が適用されているサービスにおいて、ユーザが低料金で視聴したい場合に、低い映像ビットレートを連続して維持することもできる。また、切換え感度を伴う自動切換え制御を実行している場合において、自動による切換え条件に達していない時点であっても、映像品質に対するユーザの好みで自動制御を中断して切換え操作を行うこともできる。一般的に動画や音声の視聴の印象は、ユーザによってバラツキがある。多少の映像品質変動に対して寛容ユーザもいれば、変動に対して敏感なユーザもいる。このため、場合によっては、映像ビットレートを自動で切換えるよりも、手動切換えとすることで、より使い勝手が良いという印象を与えることができる。
インターネット等の有線のみを用いた映像配信においても、回線の運用状態の影響によってデータ転送速度の変動が生じる。しかし、一般的に有線回線は無線回線に比べてデータ転送帯域が遥かに広く、端末側における受信ビットレートの変動はほとんど問題ならないことが多い。一方、無線回線は、国際規格上の制約や通信デバイス性能の制限等から、データ転送帯域を広く確保することが現実的に困難な状況にある。また、無線の性質上、電波の減衰や反射等、周囲環境の影響も受け易いこともあり、データ転送速度の変動が頻繁に発生する。これまで述べてきた本発明の映像配信方法は、この様にデータ転送速度変動が発生し易い無線回線を使用した映像配信システムに適用した場合に、特に有効である。
【００７０】
本発明の映像配信装置が扱う配信データは、動画のみ、または音声のみのデータであっても良い。また、動画や音声以外のデータであってもかまわない。静止画データ、テキストデータ、ＳＧＭＬ（ＳｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄＭａｒｋｕｐＬａｎｇｕａｇｅ）やＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）などのＷｅｂ（ＷｏｒｌｄＷｉｄｅＷｅｂ）用データ等であっても良い。
【００７１】
【発明の効果】
データ転送速度変動が発生し易い無線回線を使用した映像配信システムにおいて、映像ストリーミング時に受信端末自身が正確に受信ビットレートを監視する機能を備え、その監視結果に応じて最適な映像ビットレートに切換えることをサーバへ要求することで、安定した映像ストリーミングが実行可能な手段を提供することが可能となる。
【図面の簡単な説明】
【図１】受信端末の構成を示す図。
【図２】配信サーバの構成を示す図。
【図３】映像データの構造を示す図。
【図４】ｕｕｉｄの構造を示す図。
【図５】監視トリガ情報を格納したｕｕｉｄ生成の概念を示す図。
【図６】受信ビットレート監視のタイムチャート。
【図７】映像データ配信のデータ転送時間とビットレートの関係を示す図。
【図８】映像ビットレートテーブルの一例を示す図。
【図９】映像ビットレート切換えポイントテーブルの一例を示す図。
【図１０】映像ビットレートテーブルおよび映像ビットレート切換えポイントテーブルの使用形態を示す図。
【図１１】上位モードへの映像ビットレート切換え動作の一例を示す図。
【図１２】下位モードへの映像ビットレート切換え動作の一例を示す図。
【図１３】上位モードへの映像ビットレート切換え動作の別の一例を示す図。
【図１４】下位モードへの映像ビットレート切換え動作の別の一例を示す図。
【図１５】配信サーバの動作を示すフローチャート。
【図１６】配信映像データに監視トリガ情報を格納したｕｕｉｄを多重する処理を示すフローチャート。
【図１７】受信端末の全体動作を示すフローチャート。
【図１８】受信ビットレート制御手順を示すフローチャート。
【図１９】上昇切換え感度および下降切換え感度を用いた受信ビットレート制御手順を示すフローチャート。
【図２０】受信ビットレート測定の手順を示すフローチャート。
【図２１】配信サーバと受信端末を用いた運用形態の一例を示す図。
【図２２】配信サーバと受信端末を用いた典型的な運用形態の例を示す図。
【図２３】受信端末のユーザインターフェースの一例を示す図。
【符号の説明】
１００…受信端末、１０１…無線通信部、１０２…映像データ受信部、１０３…解析部、１０４…記憶部、１０５…再生部、１０６…モニタ、１０７…スピーカ、１０８…基準タイマ、１０９…監視トリガ制御部、１１０…受信ビットレート監視部、１１１…コマンド送信部、２００…配信サーバ。

Claims

映像データの入力部と，
映像データ再構成部と，端末に接続される通信部と，
上記端末が受信ビットレート監視を行うための監視トリガ情報を作成する監視トリガ情報作成部とを備え、
上記監視トリガ情報作成部は作成した監視トリガを上記入力部を介して入力された映像データに挿入して上記通信部を介して端末に出力することを特徴とする配信サーバ。
上記映像データを上記端末に送出するビットレート切り換え制御部を有し、
上記通信部が、上記受信端末から映像ビットレート要求コマンドを受信した場合は，上記映像再構成部は、該コマンドの指定する映像ビットレートに切換えて映像データを配信することを特徴とする請求項１記載の配信サーバ。
映像データの入力部と，
端末に接続される通信部と，
上記映像データを上記端末に送出するビットレート切り換え制御部とを有し、
上記ビットレート切り換え制御部は、上記通信部を介して受信したビットレート切り換え情報に基づいて、上記ビットレートを切り換えることを特徴とする配信サーバ。
上記監視トリガとして、配信する上記映像データの拡張部分に，
次に送信するフラグメントの送信開始時刻を挿入することを特徴とする請求項２又は３に記載の配信サーバ。
配信サーバと接続された通信部と，
上記受信された映像データの再生部と，
上記受信された映像データの受信ビットレートを監視する監視部とを有し，
上記監視部は、上記監視される受信ビットレートに基づいて、上記映像データの配信ビットレート切り換え情報を上記通信部を介して送出することを特徴とする端末装置。
上記受信された映像データの解析部をさらに有し、
上記解析部は上記映像データから監視トリガを抽出し、
上記監視部は該監視トリガを用いて該監視を行うことを特徴とする請求項５記載の端末装置。
時刻をカウントするタイマを有し、
上記監視部は、上記タイマの時刻と，上記監視トリガに規定される次に受信するフラグメントの受信開始時刻を比較し，該時刻から受信ビットレートの上記監視を開始すること特徴とする請求項５又は６に記載の端末装置。
上記監視部は、測定した受信ビットレートと、
記録部に記録されるビットレートの切換え条件とを比較し、
該比較の結果に基づいて上記ビットレート切り換え情報を送出することを特徴とする請求項７に記載の端末装置。
上記監視部は、
上記監視トリガに規定される次に受信するフラグメントの受信開始時刻から監視を開始し、
上記映像データに規定されるフラグメントサイズのデータ受信が終わった時点で該監視を終了し、受信ビットレートを算出することを特徴とする請求項７又は８に記載の端末装置。
上記受信された映像データを表示する表示部と、
ユーザからの入力を受けつける入力指示部とをさらに有し、
上記表示部に表示される映像データに関して上記入力指示部を介してビットレート変更の指示を受付け、該指示を上記切り換え情報として送出することを特徴とする請求項５乃至９の何れかに記載の端末装置。