JP4379779B2 - 映像配信方式 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は映像配信装置に関し、特にメディアデータをサーバから送信し、クライアントにおいてネットワーク経由で該メディアデータを受信し再生する映像配信方式に関する。また、本発明は、ネットワークでの伝送速度が変動する場合に好適な映像配信方式に関する。
【０００２】
【従来の技術】
従来、複数のビットレートで作成した同一内容のコンテンツを予めサーバに蓄積しておき、サーバが、受信端末、例えば携帯電話からの指示に従ってビットレートを切り替えて配信する技術が知られている。この従来技術では、受信端末は、受信の最初からビットレートを指示することに加えて、受信の途中でビットレートを変更する指示をすることも可能であった。受信端末には、例えば受信するビットレートをサーバに指示するボタンが設けられており、ユーザが該ボタンを操作することにより、サーバに受信するビットレートを指示することが可能であった。そして、ユーザが例えば受信画像の一部に対して品質の良い画像を受信したいと思う場合には、該ボタンを操作して、ビットレートを大きくする指示をするのが可能であった。なお、上記の従来技術に関連する公知文献として、例えば、２００２年８月発表の２００２年映像情報メディア学会年次大会の１１−６“携帯電話ビデオストリーミングシステム設計に関する一検討”や、同１１−７“ＴＣＰビデオストリーミングにおける動的符号化レート制御の検討”がある。
【０００３】
しかしながら、上記の従来技術は、受信端末で、手動でビットレートを選択する制御しかできなかったため、回線の通信の事情に適合した最適なビットレートを選択することができないという問題があった。このため、本発明者らは、自動的に最適なビットレートを選択するように制御できる動画像符号化ビットレート選択方式を発明し特許出願した（特願２００２−３３５０３５号）。
【発明が解決しようとする課題】
【０００４】
前記の特許出願は、クライアントが、ネットワークのスループットの状況と自バッファの蓄積状況を勘案して、次に受信したいメディアデータのビットレートを選択し、時間単位に区切られたメディアデータ（フラグメント）の受信完了時に、前記ビットレートのフラグメントをサーバに要求するものである。
【０００５】
しかし、前記の特許出願のものでは、メディアデータのビットレートを変更できるタイミングは、フラグメントの受信完了時だけである。ネットワークのスループットが想定したものとあっていれば問題はないが、例えば、無線通信においてトンネルに入るなど、急激にスループットが低下する場合には、クライアントの受信バッファがアンダーフローする。フラグメントの受信途中のスループットが低下した時点で、該アンダーフローが起きる可能性を予見できるに拘わらず、メディアデータのビットレートを変更するにはフラグメントの受信完了を待つしかないという問題があった。また、このため、受信バッファにアンダーフローが起きた後も、正常な受信を回復するのに時間がかかるという問題もあった。
【０００６】
本発明の目的は、前記した従来技術の問題点を解消し、受信バッファがアンダーフローする可能性を予見し、効果的にその対策を講じることができる映像配信方式を提供することにある。
【０００７】
【課題を解決するための手段】
前記した目的を達成するために、本発明は、複数種類の符号化ビットレートの連続メディアデータ間で切替可能なように同期ポイントをもった動画像データ群から、同期ポイントまでの受信が終了する度に単一の符号化ビットレートを選択し、動画像データの送受信をする映像配信方式であって、該動画像データを伝送する網の伝送スループットを測定する手段と、前記動画像データの受信中に、受信バッファがアンダーフローする可能性があり、かつ低ビットレートに切り替えた方が次の同期ポイントまでの受信が早く終わるか否かを、前記伝送スループットを用いて判断する手段と、該判断が肯定の場合、前記同期ポイント間のデータ（以下、フラグメントと呼ぶ）の受信途中で受信を中止し、低ビットレートのフラグメントを要求する手段と、該低ビットレートのフラグメントを受信する手段とを具備した点に特徴がある。
【０００８】
この特徴によれば、受信バッファにアンダーフローが起きると予想されたときには、受信中のフラグメントの受信終了を待たずに、低ビットレートのデータの送信を要求でき、送信側ではこの要求に応じて即座に要求された低ビットレートのデータの送信を実行するので、受信バッファがアンダーフローを起こすのを極力防止できるようになる。また、アンダーフローを起こした場合でも、その回復を早期に行えるようになる。
【０００９】
【発明の実施の形態】
以下に、図面を参照して、本発明を詳細に説明する。図１は、本発明が適用されるシステムの概略の構成図を示す。
【００１０】
図示されているように、該システムは、動画像コンテンツの送信側であるサーバ１と、網（ネットワーク）２例えば携帯電話網と、携帯電話、ＰＤＡ等の受信端末（クライアント）３とから構成されている。サーバ１は、周知のように図示されていない有線の情報ネットワークに接続されている。
【００１１】
サーバ１の画像データ蓄積装置１１には、同一内容の画像データあるいはメディアデータを複数のビットレートで作成した複数のファイルが蓄積されている。メディアデータは、図２に示されているように、同一内容を複数の離散的なビットレートｃ［ｎ］（ｎ＝０，１，２，・・・）、例えばビットレートｃ［０］のビットストリームＡと、ビットレートｃ［１］のビットストリームＢで形成されており、各ビットストリームには定期的に同期ポイントａ１，ａ２，ａ３，・・・；ｂ１，ｂ２，ｂ３，・・・が設定されている。このビットレートｃ［ｎ］は、前記受信端末３に予め通知されている。
【００１２】
前記同期ポイントは、T間隔、例えば１０秒間隔で設定されている。該同期ポイントでは、この箇所において、異なるビットレート間でデータの切替が可能である。なお、以下では、該同期ポイント間のデータ単位を、“フラグメント”と呼ぶことにする。
【００１３】
該画像データ蓄積装置１１は、配信用のプログラムであるＣＧＩ（commom gateway interface）プログラム１２によりアクセスされ、該ＣＧＩプログラム１２から要求されたビットレートのファイルを提供する。
【００１４】
一方、受信端末３は、受信データを一時的に蓄積する受信バッファ３１と、最適なビットレートを決定し、該ビットレートを網２を介してサーバ１に通知するコントローラ３２と、該バッファ３１の蓄積量が所定量以上になった時点で受信バッファ３１からデータを読み出しビデオ復号を開始するデコーダ３３を備えている。
【００１５】
次に、本発明の一実施形態を説明する。図３(a)、(b)、(c)は本実施形態の動作を説明するメディアデータのタイミングチャートであり、横軸は時間（ｔ）を示す。
【００１６】
図３(a)はこの実施形態の受信データと再生データの関係を示す。この実施形態では、受信端末３はメディアビットレートｃでメディアデータ５２を受信し、デコーダ３３は受信中のフラグメントより１つ前のフラグメントのデータ５１を再生する、すなわち、第ｎフラグメントのメディアデータ５２を受信中に、第（ｎ−１）フラグメントのメディアデータ５１を再生するものとする。
【００１７】
次に、本実施形態の前記コントローラ３２の動作を、図４のフローチャートを参照して説明する。ステップＳ１では、第ｎフラグメントのメディアデータを受信する。ステップＳ２では、ネットワーク２のスループット（伝送スループット）ｖを推定する。ステップＳ３では、該スループットｖを用いて、▲１▼受信バッファ３１がアンダーフローする可能性があり、かつ▲２▼メディアビットレートを最低レートｃ０に切り替えた方が受信が早く終わるか否かの判断をする。この判断は具体的には、例えば下記の（１）、（２）式で行われる。
２×Ｔ−ｔｐ＜ｃ×（Ｔ−ｔｒ）／ｖ ・・・（１）
ｃ×（Ｔ−ｔｒ）／ｖ＞ｃ０×Ｔ／ｖ＋ＴＣＰ再接続時間 ・・・（２）
ここに、Ｔはフラグメント継続時間、ｔｐは第（ｎ−１）フラグメントの再生中の箇所（時間）、ｔｒは第ｎフラグメントの受信中の箇所（時間）（図３(a)参照）、ｃは第ｎフラグメントの受信中のメディアデータ５２のビットレートである。
【００１８】
前記（１）式は前記▲１▼を判定する式であり、（２）式は前記▲２▼を判定する式である。該（１）および（２）式が満足されると、前記ステップＳ３の判断は肯定になり、いずれか一方の式でも満足されないと該判断は否定になる。
【００１９】
ステップＳ３の判断が否定の時には、ステップＳ６次いでステップＳ１に進み第ｎフラグメントのメディアデータの受信が続行される。一方、ステップＳ３の判断が肯定になると、ステップＳ４に進んで、即座にＴＣＰコネクションを切断する。または、サーバへ中止コマンドを送出する。これにより、第ｎフラグメントのメディアデータの受信が、受信途中で停止する。
【００２０】
ステップＳ５では、図３(b)に示されているように、第ｎフラグメントのデータ５３を、最低のビットレートｃ０で送出することをサーバ１に要求する。サーバ１はこの要求があると、受信端末３が受信中止を認識しなくても、要求された新しいビットレートのフラグメントを送信開始する。次いで、ステップＳ１に戻り、第ｎフラグメントのデータをビットレートｃ０で最初から受信する。以下、前記と同じ動作が行われる。
【００２１】
以上の動作の結果、ステップＳ６の判断が肯定になると、ステップＳ７に進んで最後のフラグメントを受信したか否かの判断がなされる。この判断が否定の時にはｎが１インクリメントされてステップＳ１に戻り、第（ｎ＋１）フラグメントの受信が行われる。ステップＳ７の判断が肯定になると、前記した一連の動作は終了する。
【００２２】
受信端末３のデコーダ３３の再生動作は、前記のようにして第ｎフラグメントのデータが受信途中で中断され、該第ｎフラグメントのビットレートｃ０のデータがその最初から再受信されても、第（ｎ−１）フラグメントの再生を続ける。該第ｎフラグメントのビットレートｃ０のデータは、第（ｎ−１）フラグメントの再生中はバックグランドで再生しておき、該第（ｎ−１）フラグメントの再生が終わると、新しく到着した第ｎフラグメントのビットレートｃ０のデータ５３に切り替えられる（図３(b)参照）。これにより、メディアデータを連続して再生すると共に、受信バッファがアンダーフローするのを極力防止できるようになる。
【００２３】
なお、該再生動作の変形例として、ビットレートｃのデータ５２を受信済みの箇所、すなわち第ｎフラグメントのｔｒまで再生し、それと並行してビットレートｃ０のメディアデータをバックグランドで復号しておき、該箇所ｔｒで再生を切り替えるようにしてもよい。
【００２４】
以上のように、本実施形態によれば、第ｎフラグメントの受信途中で受信バッファにアンダーフローが起きる可能性が出た場合、該第ｎフラグメントの受信終了を待つことなく該可能性が発生した時点で受信を中断し、最低のビットレートｃ０で送信するようサーバに要求できるので、早期に対策を講じることができるようになり、該アンダーフローの発生を極力防止できるようになる。また、受信データの再生も、滞りなく行うことができる。
【００２５】
前記コントローラ３２の他の動作例を、図５を参照して説明する。図５において、図４と同じ動作には同じステップ番号が付されており、説明を省略する。ステップＳ３の判断が肯定になった場合には、ステップＳ４に進んで即座にＴＣＰコネクションを切断、または中止コマンドを送出し、ステップＳ１１に進んで、図３(c)に示されているように、第（ｎ＋１）フラグメントのデータ５４を、最低のビットレートｃ０で送出するよう要求する。サーバ１はこの要求があると、受信端末３が受信中止を認識しなくても、要求された新しいビットレートのフラグメントを送信開始する。ステップＳ１２では、第（ｎ＋１）フラグメントのデータ５４をビットレートｃ０で受信する。ステップＳ１３では、第（ｎ＋１）フラグメントの受信が終了したか否かの判断を行い、この判断が否定の時にはステップＳ１に戻って該ビットレートｃ０での受信を続行する。一方、前記ステップＳ３の判断が否定の時にはステップＳ１４に進んで第ｎフラグメントの受信を続行する。
【００２６】
以上のように、この動作例では、前記ステップＳ３の判断が肯定になった時には、第ｎフラグメントの受信を即座に中断し、第（ｎ＋１）フラグメントから、ビットレートｃ０で受信を再開する。
【００２７】
この場合の前記デコーダ３３の再生動作は、第ｎフラグメントのｔｒまで再生し、画像をフリーズさせ、第（ｎ＋１）フラグメントのデータを所定の量までバッファリングしてから、第（ｎ＋１）フラグメントの再生を開始する（図３(c)参照）。
【００２８】
この実施形態によれば、受信バッファがアンダーフローする可能性が起きた場合は、画像表示を強制的にフリーズさせ、その後、第（ｎ＋１）フラグメントのビットレートｃ０の受信データが所定量まで受信バッファに蓄積された後に復号・再生を再開するようにしているので、復号・再生の制御が簡単になると共に、受信バッファがアンダーフローした後の回復が早くなる。
【００２９】
なお、動画像データを伝送する網（ネットワーク）の伝送スループットｖがフラグメントデータの最低ビットレートｃ０よりも大幅に（すなわち、予め定められた値以上）低いときには、前記ステップＳ３の判断をすることなく受信を中止し、最低ビットレートｃ０送信を要求するのが良い。
【００３０】
次に、本発明の第２実施形態を説明する。図６(a)、(b)、(c)は、該実施形態の動作を示すタイミングチャートを示す。図６(a)から明らかなように、この実施形態は、受信中の第ｎフラグメントのメディアデータ６１を後追いしながら該データ６１を再生する場合（再生データ６２）の例である。
【００３１】
該第２実施形態における前記コントローラ３２の動作は、前記ステップＳ３の判定式を除き、図４または図５と同じである。すなわち、(ア)図４と同様に、ステップＳ４でＴＣＰコネクションを切断または中止コマンドを送出すると、第ｎフラグメントをビットレートｃ０で要求する。あるいは、(イ)図５と同様に、ステップＳ４でＴＣＰコネクションを切断または中止コマンドを送出すると、第（ｎ＋１）フラグメントをビットレートｃ０で要求する。
【００３２】
前記（１）および（２）式に代わる判定式は、下記の判定式（（３）式、（４）式）である。
Ｔ−ｔｐ＜ｃ×（Ｔ−ｔｒ）／ｖ ・・・（３）
ｃ×（Ｔ−ｔｒ）／ｖ＞ｃ０×Ｔ／ｖ＋ＴＣＰ再接続時間 ・・・（４）
該（３）および（４）式が共に満足されるとき、ステップＳ３の判断は肯定になり、いずれか一方の式でも満足されないときには、該判断は否定になる。
【００３３】
次に、前記デコーダ３３の再生動作を説明する。前記(ア)の場合は、デコーダ３３は第ｎフラグメントの再生を続け、受信済みの所ｔｒまで再生する。それと並行してビットレートｃ０のメディアデータの復号を行っておき、ｔｒの所で、ビットレートｃのメディアデータからｃ０のメディアデータに切り替える（図６(b)参照）。
【００３４】
前記(イ)の場合は、第ｎフラグメントの再生をｔｒまで行い、画像をフリーズさせ、第（ｎ＋１）フラグメントのデータを所定の量までバッファリングしてから、第（ｎ＋１）フラグメントの再生を開始する（図６(c)参照）。
【００３５】
以上のように、本実施形態によれば、第ｎフラグメントのデータを受信し、かつ同じフラグメントを後追いしながら再生する場合においても、第ｎフラグメントの受信途中で受信バッファにアンダーフローが起きる可能性が出た場合、該受信を即座に中断し、最低のビットレートｃ０で送信するようサーバに要求できるので、該アンダーフローの発生を極力防止できるようになる。また、受信データの再生も、滞りなく行うことができる。
【００３６】
また、前記(イ)の場合は、受信バッファがアンダーフローする可能性が起きた場合は、画像を強制的にフリーズさせるものであるが、ビットレートｃのデータの受信を速やかに中断し、その後ビットレートｃ０のデータを受信し、該受信データが所定量まで受信バッファに蓄積された所で復号・再生を再開するので、再生の回復が早くなる。
【００３７】
次に、本発明の第３実施形態を説明する。この実施形態は、サーバ１が随時、すなわちフラグメントの途中からでも、ビットレートの異なるデータに切り替えて読み出せるようにされている場合の例である。
【００３８】
この実施形態におけるコントローラ３２の動作の要部を、図７のフローチャートを参照して説明する。図７において、図４と同じ動作には同じステップ番号を付して説明を省略する。ステップＳ４のＴＣＰコネクションを切断または中止コマンドを送出する処理が終わると、ステップＳ２１では、第ｎフラグメントの途中箇所（図３または図６のｔｒ）を指定して、最低ビットレートｃ０で送信要求する。ステップＳ２２では、受信端末３は該途中箇所ｔｒからビットレートｃ０で受信する。
【００３９】
この実施形態の再生動作は、第ｎフラグメントの途中箇所ｔｒまではビットレートｃで受信したデータを再生し、該箇所ｔｒからは最低ビットレートｃ０で受信したデータを再生する。
【００４０】
この実施形態によれば、第ｎフラグメントの受信途中で受信バッファにアンダーフローが起きる可能性が出た場合、該受信を中断し、中断箇所から最低のビットレートｃ０で送信するようサーバに要求できるので、受信データに無駄が生じずまたアンダーフローの発生を極力防止できるようになる。また、受信データの再生も、中断したりフリーズしたりすることなく、連続的に行うことができるようになる。
【００４１】
以上の各実施形態では、受信バッファがアンダーフローする可能性が生じた時には、最低のビットレートｃ０の要求をするようにしたが、本発明はこれに限定されることなく、アンダーフローを起こさないビットレートであれば、どのビットレートを要求するようにしても良い。この場合のビットレートｃ’は、前記第１実施形態の場合は、前記（１）式に代えて下記の（５）式を、また第２実施形態の場合は、前記（３）式に代えて下記の（６）式を満たすものを選択すれば良い。
２×Ｔ−ｔｐ＜ｃ’×Ｔ／ｖ ・・・（５）
Ｔ−ｔｐ＜ｃ’×Ｔ／ｖ ・・・（６）
【００４２】
この変形例によれば、受信バッファのアンダーフローするのを防止できると共に、最低のビットレートｃ０のデータより画質の良好なメディアデータを受信することができる。
【００４３】
本発明は、携帯電話やＰＤＡ向けの映像配信、ＰＣ向けのインターネット映像配信等に適用することができる。
【００４４】
【発明の効果】
以上の説明から明らかなように、請求項１、２の発明によれば、受信バッファにアンダーフローが起きると予想されたときには、受信中のフラグメントの受信終了を待たずに、低ビットレートのデータの送信を要求できるので、受信バッファがアンダーフローを起こすのを極力防止できるようになる。また、アンダーフローを起こした場合でも、その回復を早期に行えるようになる。
【００４５】
また、請求項３の発明によれば、映像フリーズを起こさないで、低ビットレートの再生画像に移行できるようになる。請求項４の発明によれば、映像フリーズを強制的に起こし次の受信フラグメントの先頭から受信するので、簡単な制御で低ビットレートの再生画像に移行できるようになる。また、アンダーフローを起こした場合でも、その回復を早期に行えるようになる。
【００４６】
また、請求項５の発明によれば、フラグメントの途中からでもビットレートを低ビットレートに切り替えることができるようになる。請求項６の発明によれば、フラグメントの途中で、低ビットレートの受信に切り替え、かつ再生できるようになる。
【００４７】
また、請求項７の発明によれば、受信バッファのアンダーフローを極力防止できるようになる。請求項８の発明によれば、できるだけ良好な画質を保持した状態で、受信バッファのアンダーフローを極力防止できるようになる。請求項９の発明によれば、網の伝送スループットが大幅に低下した場合に早期に対策を講じることができ、受信バッファのアンダーフローを防止、または該アンダーフローが起きた場合には早期に回復できるようになる。さらに、請求項１０の発明によれば、送信側は早期に要求された低ビットレートのデータを伝送できるようになる。
【図面の簡単な説明】
【図１】 本発明の映像配信方式に好適な送受信システムの概略の構成を示すブロック図である。
【図２】 ビットストリームの構成を示す図である。
【図３】 フラグメントの受信および再生を示す第１の実施形態のタイミングチャートである。
【図４】 第１実施形態の動作を示すフローチャートである。
【図５】 第１実施形態の他の動作例を示すフローチャートである。
【図６】 フラグメントの受信および再生を示す第２の実施形態のタイミングチャートである。
【図７】 第３実施形態の動作を示すフローチャートである。
【符号の説明】
１・・・サーバ、２・・・網、３・・・受信端末、１１・・・画像データ蓄積装置、１２・・・ＣＧＩプログラム、３１・・・受信バッファ、３２・・・コントローラ、３３・・・デコーダ。

Claims (9)

1. 複数種類の符号化ビットレートの連続メディアデータ間で切替可能なように同期ポイントをもった動画像データ群から、同期ポイントまでの受信が終了する度に単一の符号化ビットレートを選択し、動画像データの送受信をする映像配信方式であって、
   該動画像データを伝送する網の伝送スループットを測定する手段と、
   前記動画像データの受信中に、受信バッファがアンダーフローする可能性があり、かつ低ビットレートに切り替えた方が次の同期ポイントまでの受信が早く終わるか否かを、前記伝送スループットを用いて判断する手段と、
   該判断が肯定の場合、前記同期ポイント間のデータ（以下、フラグメントと呼ぶ）の受信途中で受信を中止し、低ビットレートのフラグメントを要求する手段と、
   該低ビットレートのフラグメントを受信する手段とを具備したことを特徴とする映像配信方式。
2. 請求項１に記載の映像配信方式において、
   前記低ビットレートのフラグメントを要求する手段は、受信中のフラグメントと同一のフラグメントまたは次のフラグメントの低ビットレートを要求することを特徴とする映像配信方式。
3. 請求項２に記載の映像配信方式において、
   前記低ビットレートのフラグメントを要求する手段が、受信中のフラグメントと同一のフラグメントを要求した場合には、受信済みのフラグメントまたは受信中のデータの再生を行うと同時に、新たに受信した低ビットレートのデータをバックグランドで再生を行い、前記受信済みのフラグメントまたは前記受信中止時点までの受信データの再生が終わった時点で、該新たに受信した低ビットレートのデータの再生に切り替えることを特徴とする映像配信方式。
4. 請求項２に記載の映像配信方式において、
   前記低ビットレートのフラグメントを要求する手段が、受信中のフラグメントの次のフラグメントの低ビットレートを要求した場合には、受信済の所まで再生を継続し、データがなくなった所でフリーズし、次のフラグメントのデータから再生を開始することを特徴とする映像配信方式。
5. 複数種類の符号化ビットレートの連続メディアデータ間で切替可能なように同期ポイントをもった動画像データ群から、随時単一の符号化ビットレートを選択し、動画像データの送受信をする映像配信方式であって、
   該動画像データを伝送する網の伝送スループットを測定する手段と、
   前記動画像データの受信中に、受信バッファがアンダーフローする可能性があり、かつ低ビットレートに切り替えた方が次の同期ポイントまでの受信が早く終わるか否かを、前記伝送スループットを用いて判断する手段と、
   該判断が肯定の場合、前記同期ポイント間のデータの受信途中で受信を中止し、該中止したデータに続く低ビットレートのデータを要求する手段と、
   該低ビットレートのデータを受信する手段とを具備したことを特徴とする映像配信方式。
6. 請求項５に記載の映像配信方式において、
   前記受信中のデータを前記受信途中まで再生し、続いて受信した該中止したデータに続く低ビットレートのデータを再生することを特徴とする映像配信方式。
7. 請求項１ないし６のいずれかに記載の映像配信方式において、
   前記低ビットレートが最低ビットレートであることを特徴とする映像配信方式。
8. 請求項１ないし６のいずれかに記載の映像配信方式において、
   前記低ビットレートが、前記受信バッファがアンダーフローを起こさないと予想されるビットレートであることを特徴とする映像配信方式。
9. 請求項１ないし８のいずれかに記載の映像配信方式において、
   前記動画像の送信側は、前記受信中止を認識しない状態にあっても、要求された新しいビットレートのデータを送信開始することを特徴とする映像配信方式。

Images