JP2004023664A - ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 - Google Patents
ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 Download PDFInfo
- Publication number
- JP2004023664A JP2004023664A JP2002178962A JP2002178962A JP2004023664A JP 2004023664 A JP2004023664 A JP 2004023664A JP 2002178962 A JP2002178962 A JP 2002178962A JP 2002178962 A JP2002178962 A JP 2002178962A JP 2004023664 A JP2004023664 A JP 2004023664A
- Authority
- JP
- Japan
- Prior art keywords
- display
- server
- data distribution
- moving image
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
【課題】画像表示用の複数のストリームデータをクライアントに転送して再生する処理が、少ない待ち時間で行えるようにする。
【解決手段】サーバからクライアントに、画像表示用のストリームを配信する場合に、複数の動画ストリームから構成されるコンテンツをサーバから配信する際には、その複数の動画の表示状態を示す表示レイアウト情報を、予めサーバからクライアントに送信するようにした。表示レイアウト情報がクライアントに届くことで、クライアントが受信したストリームデータを表示させる状態についての各種設定ができる。
【選択図】 図４
【解決手段】サーバからクライアントに、画像表示用のストリームを配信する場合に、複数の動画ストリームから構成されるコンテンツをサーバから配信する際には、その複数の動画の表示状態を示す表示レイアウト情報を、予めサーバからクライアントに送信するようにした。表示レイアウト情報がクライアントに届くことで、クライアントが受信したストリームデータを表示させる状態についての各種設定ができる。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、各種ネットワークを介して動画ストリームデータを配信する配信方法と、その配信に使用されるデータ配信サーバ及びデータ受信装置に関し、特に、複数の動画で構成されるコンテンツを配信する場合の技術に関する。
【０００２】
【従来の技術】
従来、ビデオプログラム、オーディオプログラムなどのストリーミングメディアのデータ（ストリーミングデータ）を、ストリーミングメディアサーバと称されるデータ蓄積装置に蓄積させて、インターネットなどの所定のネットワークを介して接続された端末装置からの要求がある場合に、その蓄積されたストリーミングメディアのデータを、サーバから端末装置に配信して、端末装置でその配信されたストリーミングメディアのデータを再生させることが行われている。サーバからストリーミングメディアのデータの配信を受ける端末装置は、クライアントと称される。
【０００３】
サーバやクライアントを構成する機器は、パーソナルコンピュータ装置などの各種コンピュータ装置を使用して構成されるのが一般的であるが、専用のデータ処理装置やデータ受信装置として構成することも可能である。
【０００４】
ネットワークとしては、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：構内情報通信網）を利用することで、そのＬＡＮが組まれた範囲内の端末装置だけで利用できるように構成することもできるが、例えばインターネットなどの不特定多数の者が利用可能な大規模なネットワークを使用することで、利用者についての制限がなくなる。
【０００５】
【発明が解決しようとする課題】
ところで、クライアント側からの要求で、サーバから動画などのコンテンツの配信を受けて、その配信されたコンテンツを表示させようとした場合には、クライアント側の端末装置で必要な操作をしてから、その端末装置で実際に配信された動画などの再生が始まるまで時間がかかる問題があった。
【０００６】
即ち、クライアントが配信を受けるコンテンツとして、例えば図１２に示すように、時刻ｔ１ でクリップ１の動画の配信を受け、時刻ｔ３ でクリップ２の動画の配信を受けて、それぞれの動画を表示させるコンテンツであるとする。このとき、それぞれのクリップ１，２が時刻ｔ１ ，ｔ３ で受信され始めた後、ある程度のデータ量が伝送された時刻ｔ２ ，ｔ４ になるまで、クライアント側の端末装置内のバッファメモリなどに、各クリップの動画データを蓄積（バッファリング）させる。そして、その蓄積されたデータを表示用などに再生処理して、端末装置に接続されたディスプレイなどに表示させる。クリップ１の動画とクリップ２の動画とが同時に伝送されている間には、例えば図１３に示すように、２つの画像を並べて表示させる。
【０００７】
このようにクライアント側の端末装置内で、配信されたデータをある程度のデータ量バッファリングさせる必要があるので、そのバッファリングさせている間は、再生ができなく、クリップ１については、時刻ｔ１ から時刻ｔ２ までの間が待ち時間となり、クリップ２については、時刻ｔ３ から時刻ｔ４ までの間が待ち時間となってしまう。
【０００８】
この待ち時間は、例えば数秒から数十秒程度必要であり、クライアント側の端末装置を操作しているユーザにとっては、待ち時間が煩わしいものであった。
【０００９】
また、例えば図１２に示すクリック１，クリック２のように、多数のストリームデータを同時に伝送する必要がある場合には、それぞれの伝送ができるビットレートを、サーバ側が選定する必要がある。即ち、クライアントに伝送できる帯域幅を確認した上で、それぞれのストリームデータが伝送できるビットレートをサーバ側で選定する必要がある。ところが、従来のビットレート調整処理では、複数のストリームデータを同時に伝送することについての調整は、基本的に考慮されてなく、例えば図１２に示すような複数のストリームデータの同時伝送がある場合には、後から伝送されるストリームデータによるクライアント側での再生の待ち時間が長く必要になる等の問題があった。
【００１０】
本発明はかかる点に鑑み、画像表示用の複数のストリームデータをクライアントに転送して再生する処理が、少ない待ち時間で行えるようにすることを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、サーバからクライアントに、画像表示用のストリームを配信する場合に、複数の動画ストリームから構成されるコンテンツをサーバから配信する際には、その複数の動画の表示状態を示す表示レイアウト情報を、予めサーバからクライアントに送信するようにしたものである。
【００１２】
本発明によると、クライアントに届いた表示レイアウト情報に基づいて、クライアントが受信したストリームデータを表示させる各種状態を設定できる。例えば、表示させる時刻よりも前に画像表示用のストリームデータをクライアントに送って、その時刻になってから、直ちに表示させるような処理が可能になる。
【００１３】
【発明の実施の形態】
以下、添付図面を参照して、本発明の一実施の形態を説明する。
【００１４】
図１は、本例のシステム構成例を示した図である。ここでは、サーバ１０とクライアント２０とが、所定のネットワーク１を介して接続される構成としてある。サーバ１０は、ストリーミングメディアサーバと称されるデータ蓄積装置であり、コンピュータ装置と、そのコンピュータ装置に接続されたデータ記憶手段を使用して構成される。クライアント２０は、サーバ１０側から転送されたストリーミングメディアを利用（再生）するユーザ側に設置された端末装置であり、例えばパーソナルコンピュータ装置と、そのコンピュータ装置に接続されたディスプレイなどで構成される。
【００１５】
ネットワーク１としては、双方向にデータ通信が可能なネットワークであれば、既存の（或いは提案されている）各種ネットワークが適用可能である。例えば、電話回線，無線通信回線などを使用して、クライアント２０がインターネットにアクセスして、そのインターネットをネットワーク１として利用して、サーバ１０に接続させるようにしても良い。図１では説明を簡単にするために、サーバ１０とクライアント２０を１台ずつで示してあるが、実際にはサーバ１０は複数台のクライアント２０からのアクセスが可能であり、またネットワーク上にはサーバ１０が複数台用意されている場合もある。サーバ１０とクライアント２０との間でのデータ転送に使用されるプロトコルとしては、例えば、ＲＴＳＰ（ＲｅａｌＴｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）と称される、映像や音声などの連続的なメディアをリアルタイムでやり取りする通信プロトコルが適用可能である。
【００１６】
図２は、サーバ１０とクライアント２０の構成例を示した図である。サーバ１０は、中央制御ユニット１１と、インターフェース部１２と、ハードディスクドライブ１３と、処理ブロック１４とを備えて、ハードディスクドライブ１３を、ストリーミングメディアを記憶させるデータ記憶手段として使用する。用意されるストリーミングメディアの容量に応じて、ハードディスクドライブ１３などのデータ記憶手段は増設される。
【００１７】
中央制御ユニット１１は、サーバ１０内の各部の動作を制御する制御手段である。なお、後述するクライアントの認識処理を実行する際には、認識処理を実行する認識処理手段として機能する。
【００１８】
インターフェース部１２は、所定の通信回線を介してネットワーク１側にデータを送出し、またネットワーク１側から得られたデータを受信する処理を行う通信手段として機能するブロックである。
【００１９】
処理ブロック１４は、ハードディスクドライブ１３で読出されたデータを、ネットワーク１上に送出させるデータ構成とする処理などが実行されるデータ処理部であり、中央制御ユニット１１の制御により各種データ処理が実行される。本例の場合には、処理ブロック１４で実行される機能の１つとして、データを暗号化する暗号化手段として使用するようにしてあり、必要によりネットワーク１上に送出させるデータの暗号化処理が行われる。この暗号化処理に必要な鍵については、サーバ１０の中央制御ユニット１１が管理する。
【００２０】
クライアント２０は、通信手段であるインターフェース部２１を介してインターネットに接続可能なパーソナルコンピュータ装置で構成され、中央制御ユニット２２と、ハードディスクドライブ２３と、バッファメモリ２４と、処理ブロック２５とを備える。
【００２１】
インターフェース部２１を介してネットワーク１側からデータを受信した場合には、ハードディスクドライブ２３をデータ蓄積手段として使用する。この場合、処理ブロック２５を使用して、必要なデータ処理が実行される。受信時にクライアント２０内に一時蓄積が必要な場合は、中央制御ユニット２２の制御でバッファメモリ２４を使用する。バッファメモリ２４の代わりに、ハードディスクドライブ２３を使用して一時蓄積させても良い。
【００２２】
処理ブロック２５には、スピーカ２６及びディスプレイ２７が接続してあり、スピーカ２６及びディスプレイ２７を使用したストリーミングメディアの再生処理が行えるようにしてある。即ち、処理ブロック２５でインターフェース部２１が受信したデータ、又はハードディスクドライブ２３やバッファメモリ２４を使用して蓄積されたデータをデコード処理し、そのデコード処理で得られたオーディオ信号をスピーカ２６に供給して出力させ、ビデオ信号をディスプレイ２７に供給して表示させる再生処理が行える。
【００２３】
次に、サーバ１０とクライアント２０でのデータ処理状態について説明する。ここでは、サーバ１０が蓄積するコンテンツとして、複数の動画像を表示させるコンテンツとし、その複数の動画ストリームを有するコンテンツをサーバ１０からクライアント２０に配信する場合の処理について説明する。動画ストリームには、動画を表示させるビデオ信号だけでなく、音声データやその他のデータが付随する場合もある。或いは、音声データなどの他のデータについては、動画ストリームとは別のストリームとして送られる場合もある。
【００２４】
まず、図３を参照してサーバ１０での処理について説明する。サーバ１０の中央制御ユニット１１は、ネットワーク１を介していずれかのクライアント２０から、コンテンツの再生要求があるか否か判断し（ステップＳ１１）、再生要求があるまで待機する。再生要求があると、その再生要求があったコンテンツが、複数の動画ストリームを有するコンテンツであるか否か判断し（ステップＳ１２）、複数の動画ストリームを有しないコンテンツ（即ち１つの動画ストリームだけを有するコンテンツ、或いは動画がないコンテンツ）である場合には、そのコンテンツに適した伝送処理を行う。この複数の動画ストリームを有しないコンテンツの伝送処理については、従来から行われている処理がそのまま適用すれば良い。
【００２５】
そして、ステップＳ１２で複数の動画ストリームを有するコンテンツであると判断した場合には、サーバ１０の中央制御ユニット１１は、再生要求のあったクライアントへの配信に利用できる伝送帯域幅を確認する（ステップＳ１３）。そして、その伝送帯域幅の中に、最初にクライアント側で再生させる必要のある動画ストリームの伝送に使用する帯域（即ちそれぞれの動画ストリームの伝送ビットレートの選定）を設定する（ステップＳ１４）。例えば、このときのコンテンツとして、２つの動画ストリームを最初に再生させる必要があるとき、用意された伝送帯域幅の内で、その２つの動画ストリームを同時に伝送できるビットレートを選定する。
【００２６】
なお、それぞれのビットレートの選定時には、それぞれの動画ストリームをクライアント側のディスプレイに表示させる表示サイズ（拡大縮小率）に応じて、それぞれの動画ストリームを配信する際のビットレートを調整して設定する。例えば、拡大して表示させる動画のストリームについては、高いビットレートを設定し、縮小して表示させる動画のストリームについては、低いビットレートを設定する。
【００２７】
図３のフローチャートの説明に戻ると、ステップＳ１４での各動画ストリームの帯域設定を行った後に、この場合のコンテンツとして、後から再生を開始させる動画ストリームがあるか否か判断する（ステップＳ１５）。ここで、後から再生させる動画ストリームがある場合には、現在動画ストリームの伝送帯域を割当てた状態で、クライアントへの配信に利用できる伝送帯域幅の中に、空き帯域があるか否か判断する（ステップＳ１６）。この判断で、空き帯域がないと判断した場合には、最初にクライアント側で再生させる動画ストリームを伝送する際のビットレートを下げて、配信に利用できる伝送帯域幅の中に空き帯域を作成する（ステップＳ１７）。例えば、そのときに伝送する必要のある複数の動画ストリームを、均等に数％ずつ低下させる。但し、ビットレートについては、最小値を定義しておき、その最小値以下のビットレートでは伝送しないようにして、極端に小さなビットレートでの配信を防止するようにしても良い。
【００２８】
ステップＳ１６の判断で空き帯域がある場合、及びステップＳ１７の処理で空き帯域を作成した場合には、その空き帯域を使用して、後から再生させる動画ストリームの送信を行うように、その動画ストリームの伝送タイミング及び伝送ビットレートを設定する（ステップＳ１８）。
【００２９】
そして、このときのコンテンツをクライアント側で表示させるために必要な表示レイアウト情報を、クライアント側に送る（ステップＳ１９）。この表示レイアウト情報は、サーバ側に予め蓄積されたデータを、単にクライアント側に送るだけでも良いが、サーバ１０内の中央制御ユニット１１が作成するようにしても良い。
【００３０】
その後、ステップＳ１４，Ｓ１７，Ｓ１８で設定した各動画ストリームの伝送タイミングと伝送ビットレートで、各動画ストリームの配信を開始させる（ステップＳ２０）。
【００３１】
なお、各動画ストリームの送信開始は、後述する図８に示したように、クライアント側からのそれぞれの動画ストリームの配信要求に基づいて行うようにしても良い。複数の動画ストリームの配信要求が同時期にある場合に、図３のフローチャートに示した処理を行うようにしても良い。
【００３２】
ここで、表示レイアウト情報の例を、図４に示す。この例は、５つの動画ストリームで構成されるコンテンツの例であり、画像番号１，２，３‥‥とそれぞれの動画ストリーム毎に番号を付与してある。各画像番号毎に、各動画ストリームが格納されたアドレス情報であるＵＲＩと、画面上での表示位置と、画面上での表示サイズを決める拡大縮小率と、表示開始時刻と、表示終了時刻と、表示終了後処理と、再生継続のデータとが用意してある。
【００３３】
図４では、画面上での表示位置のデータは、画面上の基準となる位置からの水平方向及び垂直方向の距離などで示してある。拡大縮小率については、基準となる表示サイズに対して、何％で表示させるのかを示してある。表示開始時刻と表示終了時刻は、コンテンツの再生開始を基準として、その基準時刻からの経過時間で、該当する動画の表示を開始する時刻と、終了する時刻を示してある。表示終了後処理については、例えば値が０のとき、その動画の表示領域を消し、値が１のとき、その動画の表示領域を残すことを指示する。再生継続については、例えば値が０のとき、そのコンテンツの再生を継続し、値が１のとき、そのコンテンツの再生を継続させないことを指示する。
【００３４】
また、表示レイアウト情報を、ＲＴＣＰのプロトコルに則って記述した場合には、例えば図５に示すようになる。
【００３５】
このような表示レイアウト情報をクライアント側に送ることで、その表示レイアウト情報に基づいて、そのコンテンツを構成する動画の再生状態が設定できるようになる。
【００３６】
なお、サーバからコンテンツの配信を開始させた後、クライアント側の端末での処理能力に応じて、動画ストリームのデータの出力状態を調整するようにしても良い。図６はこの場合の一例を示したフローチャートである。ここでは、図３のフローチャートのステップＳ１８で空き帯域を利用して、後から再生させる動画ストリームの送出を開始させた後に、クライアント２０内のバッファメモリ２４でのデータ蓄積状態に応じて、データの送出を制御する例である。まず、サーバ１０内の中央制御ユニット１１は、クライアント側のバッファメモリ２４に空きがあるか否か判断する（ステップＳ２１）。この判断は、例えばバッファメモリに空きがなくなったときに、クライアント側からサーバに何らかの信号を送るようにしたり、或いは、サーバ側からクライアント側に、バッファメモリの空きに関するデータを返送する指令をようにしても良い。
【００３７】
ここで空きがあると判断した場合には、空き帯域を利用した現在の送信を継続させる。そして、空き帯域がない状況であると判断した場合には、空き帯域を利用したサーバからの動画ストリームの送信を停止させる（ステップＳ２２）。その後、サーバ１０内の中央制御ユニット１１は、クライアント側のバッファメモリ２４に所定量以上の空きが発生したか否か判断する（ステップＳ２３）。ここで、空きが発生するまでそのままで待機し、空きが発生した場合には、空き帯域を利用したサーバからの動画ストリームの送信を再開させる（ステップＳ２４）。動画ストリームの送信を再開した場合には、ステップＳ２１の判断に戻る。
【００３８】
このようにして、クライアント側のバッファメモリに蓄積させることが可能な場合にだけ、サーバから空き帯域を利用して送るようにしても良い。
【００３９】
次に、クライアント側でのコンテンツ再生時の処理を、図７のフローチャートを参照して説明する。まずクライアント２０の中央制御ユニット２２は、ユーザの操作によるコンテンツ再生操作があるか否か判断する（ステップＳ３１）。コンテンツ再生操作がない場合には、再生操作があるまで待機する。そして、再生操作がある場合には、該当するコンテンツを要求する指示を、サーバに行う（ステップＳ３２）。このコンテンツ要求を行った後に、サーバから表示レイアウト情報を受信するまで待機し（ステップＳ３３）、表示レイアウト情報を受信した後に、動画ストリームのデータをインターフェース部２１で受信するまで待機する（ステップＳ３４）。
【００４０】
動画ストリームのデータを受信した後には、その時に配信される動画ストリームデータの中で、直ぐに再生しないストリームデータの受信があるか否か判断する（ステップＳ３５）。このとき配信される動画ストリームデータが、直ぐに再生させるストリームデータだけである場合には、ステップＳ３９に移って、そのときの表示レイアウト情報に基づいて、各動画ストリームの表示画面を構成させる再生処理を実行させる。
【００４１】
ステップＳ３５で、直ぐに再生しないストリームデータの受信があると判断した場合には、該当するストリームデータをバッファメモリ２４に格納させる（ステップＳ３６）。そして、バッファメモリ２４の記憶容量に空きがあるか否か判断し（ステップＳ３７）、空きがある場合にはステップＳ３９の再生処理に移り、空きがない場合にはステップＳ３８に移って、バッファ空きなしをサーバ側に通知する処理を行ってから、ステップＳ３９の再生処理に移る。
【００４２】
次に、サーバとクライアントとの間でのデータ伝送状態の一例を、図８を参照して説明する。この図８の例では、複数の動画ストリームで構成されるコンテンツのサーバからの配信は、それぞれの動画ストリーム毎にクライアントからの要求で実行される例としてある。
【００４３】
まずクライアントからはコンテンツの要求に相当するコンテンツ取得リクエストを行う（ステップＳ１０１）。このコンテンツ取得リクエストを受信したサーバでは、そのコンテンツの配信が可能である場合に、コンテンツレイアウト情報を、クライアント側に送る（ステップＳ１０２）。
【００４４】
その後、そのコンテンツレイアウト情報に基づいて、必要な動画ストリームの配信を要求する開始リクエストをクライアントからサーバに送る。即ち、例えばここでの動画ストリームとして、クリップ１，クリップ２，クリップ３の３つの動画で構成されていた場合、最初にクリップ１，クリップ２だけの再生が必要であっても、クリップ１の配信開始要求（ステップＳ１０３）と、クリップ２の配信開始要求（ステップＳ１０４）と、クリップ３の配信開始要求（ステップＳ１０５）とを行う。これらの要求があると、サーバからは、それぞれの動画ストリームの再生が開始される（ステップＳ１０６，Ｓ１０７，Ｓ１０８）。ここでは、ステップＳ１０８でのクリップ３の動画ストリームの配信が、直ぐに再生しない動画ストリームのデータの配信であり、クライアント側ではバッファメモリなどに蓄積させる。
【００４５】
このようにして、動画データの配信を行うことで、クライアント側の端末では、表示レイアウト情報に基づいてスムーズに動画を表示させる再生処理が行え、クライアント側での待ち時間を無くすことが可能になる。即ち、例えば従来例として図１２に示した、クリップ２のバッファリングに要する時刻ｔ３からｔ４までの待ち時間が本例の場合にはなくなり、クライアント側の端末でのスムーズな動画表示が行える。
【００４６】
図９は、特定のコンテンツによる表示の変化例を示した図である。この例では、最初の状態では、表示例ａで示すように、クリップ１，クリップ２，クリップ３，クリップ４の４つの動画を表示させる。その後、再生開始の時刻ｔ０を基準としてある時刻ｔａになると、表示例ｂで示すように、クリップ１の位置にクリップ５の動画を表示させて、クリップ２，クリップ３，クリップ４についてはそのまま表示を継続させる。さらに、時刻ｔｂになると、表示例ｃで示すように、クリップ２とクリップ３の表示を消して、クリップ５を拡大表示し、クリップ４を同じサイズで継続表示させる。
【００４７】
この図９に示すような表示形態のコンテンツがある場合、本例の場合には、図１０に示すような伝送状態が設定される。即ち、サーバとクライアントとの間で用意された伝送帯域幅を利用して、最初に表示させる必要のあるクリップ１，クリップ２，クリップ３，クリップ４の動画ストリームの配信を配信開始時ｔ０から行う。このとき、伝送帯域内に空き帯域が確保できる場合には、その空き帯域を利用して、クリップ５の動画ストリームの配信についても開始させる。
【００４８】
そして、クリップ１の再生が終了する時刻ｔａになると、クリップ１の動画ストリームのデータの配信を終了させ、例えば空いた帯域を利用して、クリップ５の動画ストリームを配信させるビットレートを高くする。或いは、他のクリップ２，クリップ３，クリップ４のビットレートを高くしても良い。さらに時刻ｔｂになると、クリップ４とクリップ５の動画ストリームの配信だけになる。
【００４９】
このように配信されることで、例えば時刻ｔａになった段階で、既にクライアントを構成する端末装置のバッファメモリには、クリップ５の動画ストリームのデータがある程度蓄積されているので、その蓄積されたデータを利用して、直ちにクリップ５の動画を表示させた表示例ｂに示す状態に移ることができ、さらに時刻ｔｂになった段階で、直ちに表示例ｃに示す状態に移ることができる。なお、クリップ５のように、途中で表示サイズが変更される動画ストリームについては、表示レイアウト情報で、表示サイズが可変であることを示し、変更される時刻と、変更前のサイズ及び変更後のサイズを示すことで、動画を連続してスムーズに表示できるようになる。
【００５０】
なお、図１０に示した伝送例では、途中から始まる動画ストリームのデータ（クリップ５のデータ）を、データ配信時の最初から伝送させる例としたが、少なくとも時刻ｔａよりも前のバッファリングが十分にできる時刻からクリップ５のデータを配信させれば良い。
【００５１】
また、動画の表示サイズの変化に連続して、サーバから配信される動画ストリームのビットレートを変化させて、それぞれのサイズでの良好な動画表示を行えるようにしても良い。このビットレートの変更は、サーバでの判断で自動的に行うようにしても良いが、表示レイアウト情報などをクライアント側で判断して、クライアント側からの要求でビットレートを変更させるようにしても良い。また、拡大のためにビットレートを増やす余裕がないと判断した場合には、拡大させる必要がある場合でも、ビットレートを変化させないようにしても良い。
【００５２】
また、ここまでの説明では、同一のコンテンツ内での変化について説明したが、例えばコンテンツ１からコンテンツ２に変化するような場合に、その２つのコンテンツの間で、同じ動画ストリームを再生させる場合に、その同じ動画が連続して表示される再生が行われるようにしても良い。例えば図１１に示すように、コンテンツ１として、クリップ１〜９の９個の動画を表示させるインデックス画像のような表示形態とし、コンテンツ２として、その中の特定のクリップ（ここではクリップ１）の動画を拡大表示させる表示形態とする。
【００５３】
このような場合に、コンテンツ１からコンテンツ２への変化をクライアントからサーバに指示したとき、コンテンツ１とコンテンツ２で同じ動画のクリップの存在をサーバ側で検出したとき、サーバ内で作成されるコンテンツ２の表示レイアウト情報では、コンテンツ１で途中まで再生させた動画の続きを再生させる情報とする。
【００５４】
このような表示レイアウト情報を作成してクライアントに送ることで、途中でコンテンツの変更があっても、再生途中の動画の続きが再生されるようになり、スムーズな再生が行われるようになる。表示レイアウト情報で途中からの再生を行う処理を行わない場合には、コンテンツ１からコンテンツ２への変更時に、再度クリップ１の動画が最初から表示されることになり、同じ動画が繰り返し再生されることになって、煩わしい表示形態となってしまうが、本例の場合にはこのような問題を回避できる。
【００５５】
なお、上述した実施の形態では、サーバ１０及びクライアント２０は、コンピュータ装置を利用して構成した例としてあるが、専用のデータ蓄積装置やデータ受信・再生装置として構成しても良い。
【００５６】
また、上述した実施の形態で示した表示レイアウト情報については一例を示したものであり、その他のデータ構成による表示レイアウト情報としても良い。即ち、例えば、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻などを示すようにしたが、少なくともいずれか１つの情報を表示レイアウト情報で示すようにすれば良い。或いは、その他の情報を表示レイアウト情報に付加するようにしても良い。
【００５７】
また、上述した実施の形態では、インターネットを利用したネットワークで伝送を行う例について説明したが、その他のネットワークを使用しても良い。例えば、サーバとクライアントとの間での指示やレスポンスの伝送については、インターネットのようなネットワークを使用して、サーバからクライアントへのストリーミングメディアのデータの伝送については、そのメディアデータ伝送用に用意された専用の伝送路を使用しても良い。
【００５８】
【発明の効果】
本発明によると、クライアントに届いた表示レイアウト情報に基づいて、クライアントが受信したストリームデータを表示させる各種状態を設定でき、クライアント側の端末で良好に動画ストリームを表示できるようになる。
【００５９】
この場合、表示レイアウト情報は、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻の少なくともいずれか１つの情報が含まれていることで、これらの表示に関する項目をサーバ側から適切に制御して、クライアント側の端末で動画を表示できるようになる。
【００６０】
また、表示レイアウト情報で示される複数の動画ストリームの内の、少なくとも１つの動画ストリームを、その動画ストリームの表示開始時刻よりも前に、サーバからクライアントに配信するようにしたことで、その表示開始時刻よりも前にクライアントが受信した動画ストリームを蓄積させて、表示レイアウト情報で示される表示開始時刻になってから表示させるようにすることで、表示が開始される時刻になると、待ち時間なく直ちに該当する動画ストリームを表示させることが可能になる。
【００６１】
また、表示レイアウト情報で示される拡大縮小率に応じて、各動画ストリームを配信する際のビットレートを調整することで、例えば複数の動画ストリームを同時に送って、比較的小さいサイズで同時に縮小表示するような場合に、それぞれのビットレートを小さくし、拡大表示する必要のある動画ストリームについては、ビットレートを大きくすることで、クライアント側の端末で良好に動画ストリームを表示させることが可能になる。
【００６２】
また、コンテンツが変更される場合に、その変更の前後で、特定の動画ストリームを連続して表示させる表示レイアウト情報を作成することで、コンテンツが変更された場合であっても、特定の動画ストリームを連続して表示させることが可能になり、同じ動画がコンテンツの変化時に繰り返し再生されるような無駄を無くすことができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態によるシステム構成例を示した説明図である。
【図２】本発明の一実施の形態による機器構成例を示したブロック図である。
【図３】本発明の一実施の形態によるサーバでの配信開始までの処理例を示したフローチャートである。
【図４】本発明の一実施の形態による表示レイアウト情報の一例を示した説明図である。
【図５】本発明の一実施の形態による表示レイアウト情報をＲＴＣＰのプロトコルに則って記述した一例を示した説明図である。
【図６】本発明の一実施の形態によるサーバでの配信開始後の処理例を示したフローチャートである。
【図７】本発明の一実施の形態によるクライアントでの処理例を示したフローチャートである。
【図８】本発明の一実施の形態によるサーバとクライアントとの間での伝送例を示した説明図である。
【図９】本発明の一実施の形態による表示変化例を示した説明図である。
【図１０】本発明の一実施の形態による伝送例を示した説明図である。
【図１１】本発明の他の実施の形態による表示変化例を示した説明図である。
【図１２】従来の複数のストリームデータの伝送例を示した説明図である。
【図１３】複数の画像データを受信して表示させた例を示した説明図である。
【符号の説明】
１…ネットワーク、１０…サーバ、１１…中央制御ユニット、１２…インターフェース部、１３…ハードディスクドライブ、１４…処理ブロック、２０…クライアント、２１…インターフェース部、２２…中央制御ユニット、２３…ハードディスクドライブ、２４…バッファメモリ、２５…処理ブロック、２６…スピーカ、２７…ディスプレイ
【発明の属する技術分野】
本発明は、各種ネットワークを介して動画ストリームデータを配信する配信方法と、その配信に使用されるデータ配信サーバ及びデータ受信装置に関し、特に、複数の動画で構成されるコンテンツを配信する場合の技術に関する。
【０００２】
【従来の技術】
従来、ビデオプログラム、オーディオプログラムなどのストリーミングメディアのデータ（ストリーミングデータ）を、ストリーミングメディアサーバと称されるデータ蓄積装置に蓄積させて、インターネットなどの所定のネットワークを介して接続された端末装置からの要求がある場合に、その蓄積されたストリーミングメディアのデータを、サーバから端末装置に配信して、端末装置でその配信されたストリーミングメディアのデータを再生させることが行われている。サーバからストリーミングメディアのデータの配信を受ける端末装置は、クライアントと称される。
【０００３】
サーバやクライアントを構成する機器は、パーソナルコンピュータ装置などの各種コンピュータ装置を使用して構成されるのが一般的であるが、専用のデータ処理装置やデータ受信装置として構成することも可能である。
【０００４】
ネットワークとしては、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：構内情報通信網）を利用することで、そのＬＡＮが組まれた範囲内の端末装置だけで利用できるように構成することもできるが、例えばインターネットなどの不特定多数の者が利用可能な大規模なネットワークを使用することで、利用者についての制限がなくなる。
【０００５】
【発明が解決しようとする課題】
ところで、クライアント側からの要求で、サーバから動画などのコンテンツの配信を受けて、その配信されたコンテンツを表示させようとした場合には、クライアント側の端末装置で必要な操作をしてから、その端末装置で実際に配信された動画などの再生が始まるまで時間がかかる問題があった。
【０００６】
即ち、クライアントが配信を受けるコンテンツとして、例えば図１２に示すように、時刻ｔ１ でクリップ１の動画の配信を受け、時刻ｔ３ でクリップ２の動画の配信を受けて、それぞれの動画を表示させるコンテンツであるとする。このとき、それぞれのクリップ１，２が時刻ｔ１ ，ｔ３ で受信され始めた後、ある程度のデータ量が伝送された時刻ｔ２ ，ｔ４ になるまで、クライアント側の端末装置内のバッファメモリなどに、各クリップの動画データを蓄積（バッファリング）させる。そして、その蓄積されたデータを表示用などに再生処理して、端末装置に接続されたディスプレイなどに表示させる。クリップ１の動画とクリップ２の動画とが同時に伝送されている間には、例えば図１３に示すように、２つの画像を並べて表示させる。
【０００７】
このようにクライアント側の端末装置内で、配信されたデータをある程度のデータ量バッファリングさせる必要があるので、そのバッファリングさせている間は、再生ができなく、クリップ１については、時刻ｔ１ から時刻ｔ２ までの間が待ち時間となり、クリップ２については、時刻ｔ３ から時刻ｔ４ までの間が待ち時間となってしまう。
【０００８】
この待ち時間は、例えば数秒から数十秒程度必要であり、クライアント側の端末装置を操作しているユーザにとっては、待ち時間が煩わしいものであった。
【０００９】
また、例えば図１２に示すクリック１，クリック２のように、多数のストリームデータを同時に伝送する必要がある場合には、それぞれの伝送ができるビットレートを、サーバ側が選定する必要がある。即ち、クライアントに伝送できる帯域幅を確認した上で、それぞれのストリームデータが伝送できるビットレートをサーバ側で選定する必要がある。ところが、従来のビットレート調整処理では、複数のストリームデータを同時に伝送することについての調整は、基本的に考慮されてなく、例えば図１２に示すような複数のストリームデータの同時伝送がある場合には、後から伝送されるストリームデータによるクライアント側での再生の待ち時間が長く必要になる等の問題があった。
【００１０】
本発明はかかる点に鑑み、画像表示用の複数のストリームデータをクライアントに転送して再生する処理が、少ない待ち時間で行えるようにすることを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、サーバからクライアントに、画像表示用のストリームを配信する場合に、複数の動画ストリームから構成されるコンテンツをサーバから配信する際には、その複数の動画の表示状態を示す表示レイアウト情報を、予めサーバからクライアントに送信するようにしたものである。
【００１２】
本発明によると、クライアントに届いた表示レイアウト情報に基づいて、クライアントが受信したストリームデータを表示させる各種状態を設定できる。例えば、表示させる時刻よりも前に画像表示用のストリームデータをクライアントに送って、その時刻になってから、直ちに表示させるような処理が可能になる。
【００１３】
【発明の実施の形態】
以下、添付図面を参照して、本発明の一実施の形態を説明する。
【００１４】
図１は、本例のシステム構成例を示した図である。ここでは、サーバ１０とクライアント２０とが、所定のネットワーク１を介して接続される構成としてある。サーバ１０は、ストリーミングメディアサーバと称されるデータ蓄積装置であり、コンピュータ装置と、そのコンピュータ装置に接続されたデータ記憶手段を使用して構成される。クライアント２０は、サーバ１０側から転送されたストリーミングメディアを利用（再生）するユーザ側に設置された端末装置であり、例えばパーソナルコンピュータ装置と、そのコンピュータ装置に接続されたディスプレイなどで構成される。
【００１５】
ネットワーク１としては、双方向にデータ通信が可能なネットワークであれば、既存の（或いは提案されている）各種ネットワークが適用可能である。例えば、電話回線，無線通信回線などを使用して、クライアント２０がインターネットにアクセスして、そのインターネットをネットワーク１として利用して、サーバ１０に接続させるようにしても良い。図１では説明を簡単にするために、サーバ１０とクライアント２０を１台ずつで示してあるが、実際にはサーバ１０は複数台のクライアント２０からのアクセスが可能であり、またネットワーク上にはサーバ１０が複数台用意されている場合もある。サーバ１０とクライアント２０との間でのデータ転送に使用されるプロトコルとしては、例えば、ＲＴＳＰ（ＲｅａｌＴｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）と称される、映像や音声などの連続的なメディアをリアルタイムでやり取りする通信プロトコルが適用可能である。
【００１６】
図２は、サーバ１０とクライアント２０の構成例を示した図である。サーバ１０は、中央制御ユニット１１と、インターフェース部１２と、ハードディスクドライブ１３と、処理ブロック１４とを備えて、ハードディスクドライブ１３を、ストリーミングメディアを記憶させるデータ記憶手段として使用する。用意されるストリーミングメディアの容量に応じて、ハードディスクドライブ１３などのデータ記憶手段は増設される。
【００１７】
中央制御ユニット１１は、サーバ１０内の各部の動作を制御する制御手段である。なお、後述するクライアントの認識処理を実行する際には、認識処理を実行する認識処理手段として機能する。
【００１８】
インターフェース部１２は、所定の通信回線を介してネットワーク１側にデータを送出し、またネットワーク１側から得られたデータを受信する処理を行う通信手段として機能するブロックである。
【００１９】
処理ブロック１４は、ハードディスクドライブ１３で読出されたデータを、ネットワーク１上に送出させるデータ構成とする処理などが実行されるデータ処理部であり、中央制御ユニット１１の制御により各種データ処理が実行される。本例の場合には、処理ブロック１４で実行される機能の１つとして、データを暗号化する暗号化手段として使用するようにしてあり、必要によりネットワーク１上に送出させるデータの暗号化処理が行われる。この暗号化処理に必要な鍵については、サーバ１０の中央制御ユニット１１が管理する。
【００２０】
クライアント２０は、通信手段であるインターフェース部２１を介してインターネットに接続可能なパーソナルコンピュータ装置で構成され、中央制御ユニット２２と、ハードディスクドライブ２３と、バッファメモリ２４と、処理ブロック２５とを備える。
【００２１】
インターフェース部２１を介してネットワーク１側からデータを受信した場合には、ハードディスクドライブ２３をデータ蓄積手段として使用する。この場合、処理ブロック２５を使用して、必要なデータ処理が実行される。受信時にクライアント２０内に一時蓄積が必要な場合は、中央制御ユニット２２の制御でバッファメモリ２４を使用する。バッファメモリ２４の代わりに、ハードディスクドライブ２３を使用して一時蓄積させても良い。
【００２２】
処理ブロック２５には、スピーカ２６及びディスプレイ２７が接続してあり、スピーカ２６及びディスプレイ２７を使用したストリーミングメディアの再生処理が行えるようにしてある。即ち、処理ブロック２５でインターフェース部２１が受信したデータ、又はハードディスクドライブ２３やバッファメモリ２４を使用して蓄積されたデータをデコード処理し、そのデコード処理で得られたオーディオ信号をスピーカ２６に供給して出力させ、ビデオ信号をディスプレイ２７に供給して表示させる再生処理が行える。
【００２３】
次に、サーバ１０とクライアント２０でのデータ処理状態について説明する。ここでは、サーバ１０が蓄積するコンテンツとして、複数の動画像を表示させるコンテンツとし、その複数の動画ストリームを有するコンテンツをサーバ１０からクライアント２０に配信する場合の処理について説明する。動画ストリームには、動画を表示させるビデオ信号だけでなく、音声データやその他のデータが付随する場合もある。或いは、音声データなどの他のデータについては、動画ストリームとは別のストリームとして送られる場合もある。
【００２４】
まず、図３を参照してサーバ１０での処理について説明する。サーバ１０の中央制御ユニット１１は、ネットワーク１を介していずれかのクライアント２０から、コンテンツの再生要求があるか否か判断し（ステップＳ１１）、再生要求があるまで待機する。再生要求があると、その再生要求があったコンテンツが、複数の動画ストリームを有するコンテンツであるか否か判断し（ステップＳ１２）、複数の動画ストリームを有しないコンテンツ（即ち１つの動画ストリームだけを有するコンテンツ、或いは動画がないコンテンツ）である場合には、そのコンテンツに適した伝送処理を行う。この複数の動画ストリームを有しないコンテンツの伝送処理については、従来から行われている処理がそのまま適用すれば良い。
【００２５】
そして、ステップＳ１２で複数の動画ストリームを有するコンテンツであると判断した場合には、サーバ１０の中央制御ユニット１１は、再生要求のあったクライアントへの配信に利用できる伝送帯域幅を確認する（ステップＳ１３）。そして、その伝送帯域幅の中に、最初にクライアント側で再生させる必要のある動画ストリームの伝送に使用する帯域（即ちそれぞれの動画ストリームの伝送ビットレートの選定）を設定する（ステップＳ１４）。例えば、このときのコンテンツとして、２つの動画ストリームを最初に再生させる必要があるとき、用意された伝送帯域幅の内で、その２つの動画ストリームを同時に伝送できるビットレートを選定する。
【００２６】
なお、それぞれのビットレートの選定時には、それぞれの動画ストリームをクライアント側のディスプレイに表示させる表示サイズ（拡大縮小率）に応じて、それぞれの動画ストリームを配信する際のビットレートを調整して設定する。例えば、拡大して表示させる動画のストリームについては、高いビットレートを設定し、縮小して表示させる動画のストリームについては、低いビットレートを設定する。
【００２７】
図３のフローチャートの説明に戻ると、ステップＳ１４での各動画ストリームの帯域設定を行った後に、この場合のコンテンツとして、後から再生を開始させる動画ストリームがあるか否か判断する（ステップＳ１５）。ここで、後から再生させる動画ストリームがある場合には、現在動画ストリームの伝送帯域を割当てた状態で、クライアントへの配信に利用できる伝送帯域幅の中に、空き帯域があるか否か判断する（ステップＳ１６）。この判断で、空き帯域がないと判断した場合には、最初にクライアント側で再生させる動画ストリームを伝送する際のビットレートを下げて、配信に利用できる伝送帯域幅の中に空き帯域を作成する（ステップＳ１７）。例えば、そのときに伝送する必要のある複数の動画ストリームを、均等に数％ずつ低下させる。但し、ビットレートについては、最小値を定義しておき、その最小値以下のビットレートでは伝送しないようにして、極端に小さなビットレートでの配信を防止するようにしても良い。
【００２８】
ステップＳ１６の判断で空き帯域がある場合、及びステップＳ１７の処理で空き帯域を作成した場合には、その空き帯域を使用して、後から再生させる動画ストリームの送信を行うように、その動画ストリームの伝送タイミング及び伝送ビットレートを設定する（ステップＳ１８）。
【００２９】
そして、このときのコンテンツをクライアント側で表示させるために必要な表示レイアウト情報を、クライアント側に送る（ステップＳ１９）。この表示レイアウト情報は、サーバ側に予め蓄積されたデータを、単にクライアント側に送るだけでも良いが、サーバ１０内の中央制御ユニット１１が作成するようにしても良い。
【００３０】
その後、ステップＳ１４，Ｓ１７，Ｓ１８で設定した各動画ストリームの伝送タイミングと伝送ビットレートで、各動画ストリームの配信を開始させる（ステップＳ２０）。
【００３１】
なお、各動画ストリームの送信開始は、後述する図８に示したように、クライアント側からのそれぞれの動画ストリームの配信要求に基づいて行うようにしても良い。複数の動画ストリームの配信要求が同時期にある場合に、図３のフローチャートに示した処理を行うようにしても良い。
【００３２】
ここで、表示レイアウト情報の例を、図４に示す。この例は、５つの動画ストリームで構成されるコンテンツの例であり、画像番号１，２，３‥‥とそれぞれの動画ストリーム毎に番号を付与してある。各画像番号毎に、各動画ストリームが格納されたアドレス情報であるＵＲＩと、画面上での表示位置と、画面上での表示サイズを決める拡大縮小率と、表示開始時刻と、表示終了時刻と、表示終了後処理と、再生継続のデータとが用意してある。
【００３３】
図４では、画面上での表示位置のデータは、画面上の基準となる位置からの水平方向及び垂直方向の距離などで示してある。拡大縮小率については、基準となる表示サイズに対して、何％で表示させるのかを示してある。表示開始時刻と表示終了時刻は、コンテンツの再生開始を基準として、その基準時刻からの経過時間で、該当する動画の表示を開始する時刻と、終了する時刻を示してある。表示終了後処理については、例えば値が０のとき、その動画の表示領域を消し、値が１のとき、その動画の表示領域を残すことを指示する。再生継続については、例えば値が０のとき、そのコンテンツの再生を継続し、値が１のとき、そのコンテンツの再生を継続させないことを指示する。
【００３４】
また、表示レイアウト情報を、ＲＴＣＰのプロトコルに則って記述した場合には、例えば図５に示すようになる。
【００３５】
このような表示レイアウト情報をクライアント側に送ることで、その表示レイアウト情報に基づいて、そのコンテンツを構成する動画の再生状態が設定できるようになる。
【００３６】
なお、サーバからコンテンツの配信を開始させた後、クライアント側の端末での処理能力に応じて、動画ストリームのデータの出力状態を調整するようにしても良い。図６はこの場合の一例を示したフローチャートである。ここでは、図３のフローチャートのステップＳ１８で空き帯域を利用して、後から再生させる動画ストリームの送出を開始させた後に、クライアント２０内のバッファメモリ２４でのデータ蓄積状態に応じて、データの送出を制御する例である。まず、サーバ１０内の中央制御ユニット１１は、クライアント側のバッファメモリ２４に空きがあるか否か判断する（ステップＳ２１）。この判断は、例えばバッファメモリに空きがなくなったときに、クライアント側からサーバに何らかの信号を送るようにしたり、或いは、サーバ側からクライアント側に、バッファメモリの空きに関するデータを返送する指令をようにしても良い。
【００３７】
ここで空きがあると判断した場合には、空き帯域を利用した現在の送信を継続させる。そして、空き帯域がない状況であると判断した場合には、空き帯域を利用したサーバからの動画ストリームの送信を停止させる（ステップＳ２２）。その後、サーバ１０内の中央制御ユニット１１は、クライアント側のバッファメモリ２４に所定量以上の空きが発生したか否か判断する（ステップＳ２３）。ここで、空きが発生するまでそのままで待機し、空きが発生した場合には、空き帯域を利用したサーバからの動画ストリームの送信を再開させる（ステップＳ２４）。動画ストリームの送信を再開した場合には、ステップＳ２１の判断に戻る。
【００３８】
このようにして、クライアント側のバッファメモリに蓄積させることが可能な場合にだけ、サーバから空き帯域を利用して送るようにしても良い。
【００３９】
次に、クライアント側でのコンテンツ再生時の処理を、図７のフローチャートを参照して説明する。まずクライアント２０の中央制御ユニット２２は、ユーザの操作によるコンテンツ再生操作があるか否か判断する（ステップＳ３１）。コンテンツ再生操作がない場合には、再生操作があるまで待機する。そして、再生操作がある場合には、該当するコンテンツを要求する指示を、サーバに行う（ステップＳ３２）。このコンテンツ要求を行った後に、サーバから表示レイアウト情報を受信するまで待機し（ステップＳ３３）、表示レイアウト情報を受信した後に、動画ストリームのデータをインターフェース部２１で受信するまで待機する（ステップＳ３４）。
【００４０】
動画ストリームのデータを受信した後には、その時に配信される動画ストリームデータの中で、直ぐに再生しないストリームデータの受信があるか否か判断する（ステップＳ３５）。このとき配信される動画ストリームデータが、直ぐに再生させるストリームデータだけである場合には、ステップＳ３９に移って、そのときの表示レイアウト情報に基づいて、各動画ストリームの表示画面を構成させる再生処理を実行させる。
【００４１】
ステップＳ３５で、直ぐに再生しないストリームデータの受信があると判断した場合には、該当するストリームデータをバッファメモリ２４に格納させる（ステップＳ３６）。そして、バッファメモリ２４の記憶容量に空きがあるか否か判断し（ステップＳ３７）、空きがある場合にはステップＳ３９の再生処理に移り、空きがない場合にはステップＳ３８に移って、バッファ空きなしをサーバ側に通知する処理を行ってから、ステップＳ３９の再生処理に移る。
【００４２】
次に、サーバとクライアントとの間でのデータ伝送状態の一例を、図８を参照して説明する。この図８の例では、複数の動画ストリームで構成されるコンテンツのサーバからの配信は、それぞれの動画ストリーム毎にクライアントからの要求で実行される例としてある。
【００４３】
まずクライアントからはコンテンツの要求に相当するコンテンツ取得リクエストを行う（ステップＳ１０１）。このコンテンツ取得リクエストを受信したサーバでは、そのコンテンツの配信が可能である場合に、コンテンツレイアウト情報を、クライアント側に送る（ステップＳ１０２）。
【００４４】
その後、そのコンテンツレイアウト情報に基づいて、必要な動画ストリームの配信を要求する開始リクエストをクライアントからサーバに送る。即ち、例えばここでの動画ストリームとして、クリップ１，クリップ２，クリップ３の３つの動画で構成されていた場合、最初にクリップ１，クリップ２だけの再生が必要であっても、クリップ１の配信開始要求（ステップＳ１０３）と、クリップ２の配信開始要求（ステップＳ１０４）と、クリップ３の配信開始要求（ステップＳ１０５）とを行う。これらの要求があると、サーバからは、それぞれの動画ストリームの再生が開始される（ステップＳ１０６，Ｓ１０７，Ｓ１０８）。ここでは、ステップＳ１０８でのクリップ３の動画ストリームの配信が、直ぐに再生しない動画ストリームのデータの配信であり、クライアント側ではバッファメモリなどに蓄積させる。
【００４５】
このようにして、動画データの配信を行うことで、クライアント側の端末では、表示レイアウト情報に基づいてスムーズに動画を表示させる再生処理が行え、クライアント側での待ち時間を無くすことが可能になる。即ち、例えば従来例として図１２に示した、クリップ２のバッファリングに要する時刻ｔ３からｔ４までの待ち時間が本例の場合にはなくなり、クライアント側の端末でのスムーズな動画表示が行える。
【００４６】
図９は、特定のコンテンツによる表示の変化例を示した図である。この例では、最初の状態では、表示例ａで示すように、クリップ１，クリップ２，クリップ３，クリップ４の４つの動画を表示させる。その後、再生開始の時刻ｔ０を基準としてある時刻ｔａになると、表示例ｂで示すように、クリップ１の位置にクリップ５の動画を表示させて、クリップ２，クリップ３，クリップ４についてはそのまま表示を継続させる。さらに、時刻ｔｂになると、表示例ｃで示すように、クリップ２とクリップ３の表示を消して、クリップ５を拡大表示し、クリップ４を同じサイズで継続表示させる。
【００４７】
この図９に示すような表示形態のコンテンツがある場合、本例の場合には、図１０に示すような伝送状態が設定される。即ち、サーバとクライアントとの間で用意された伝送帯域幅を利用して、最初に表示させる必要のあるクリップ１，クリップ２，クリップ３，クリップ４の動画ストリームの配信を配信開始時ｔ０から行う。このとき、伝送帯域内に空き帯域が確保できる場合には、その空き帯域を利用して、クリップ５の動画ストリームの配信についても開始させる。
【００４８】
そして、クリップ１の再生が終了する時刻ｔａになると、クリップ１の動画ストリームのデータの配信を終了させ、例えば空いた帯域を利用して、クリップ５の動画ストリームを配信させるビットレートを高くする。或いは、他のクリップ２，クリップ３，クリップ４のビットレートを高くしても良い。さらに時刻ｔｂになると、クリップ４とクリップ５の動画ストリームの配信だけになる。
【００４９】
このように配信されることで、例えば時刻ｔａになった段階で、既にクライアントを構成する端末装置のバッファメモリには、クリップ５の動画ストリームのデータがある程度蓄積されているので、その蓄積されたデータを利用して、直ちにクリップ５の動画を表示させた表示例ｂに示す状態に移ることができ、さらに時刻ｔｂになった段階で、直ちに表示例ｃに示す状態に移ることができる。なお、クリップ５のように、途中で表示サイズが変更される動画ストリームについては、表示レイアウト情報で、表示サイズが可変であることを示し、変更される時刻と、変更前のサイズ及び変更後のサイズを示すことで、動画を連続してスムーズに表示できるようになる。
【００５０】
なお、図１０に示した伝送例では、途中から始まる動画ストリームのデータ（クリップ５のデータ）を、データ配信時の最初から伝送させる例としたが、少なくとも時刻ｔａよりも前のバッファリングが十分にできる時刻からクリップ５のデータを配信させれば良い。
【００５１】
また、動画の表示サイズの変化に連続して、サーバから配信される動画ストリームのビットレートを変化させて、それぞれのサイズでの良好な動画表示を行えるようにしても良い。このビットレートの変更は、サーバでの判断で自動的に行うようにしても良いが、表示レイアウト情報などをクライアント側で判断して、クライアント側からの要求でビットレートを変更させるようにしても良い。また、拡大のためにビットレートを増やす余裕がないと判断した場合には、拡大させる必要がある場合でも、ビットレートを変化させないようにしても良い。
【００５２】
また、ここまでの説明では、同一のコンテンツ内での変化について説明したが、例えばコンテンツ１からコンテンツ２に変化するような場合に、その２つのコンテンツの間で、同じ動画ストリームを再生させる場合に、その同じ動画が連続して表示される再生が行われるようにしても良い。例えば図１１に示すように、コンテンツ１として、クリップ１〜９の９個の動画を表示させるインデックス画像のような表示形態とし、コンテンツ２として、その中の特定のクリップ（ここではクリップ１）の動画を拡大表示させる表示形態とする。
【００５３】
このような場合に、コンテンツ１からコンテンツ２への変化をクライアントからサーバに指示したとき、コンテンツ１とコンテンツ２で同じ動画のクリップの存在をサーバ側で検出したとき、サーバ内で作成されるコンテンツ２の表示レイアウト情報では、コンテンツ１で途中まで再生させた動画の続きを再生させる情報とする。
【００５４】
このような表示レイアウト情報を作成してクライアントに送ることで、途中でコンテンツの変更があっても、再生途中の動画の続きが再生されるようになり、スムーズな再生が行われるようになる。表示レイアウト情報で途中からの再生を行う処理を行わない場合には、コンテンツ１からコンテンツ２への変更時に、再度クリップ１の動画が最初から表示されることになり、同じ動画が繰り返し再生されることになって、煩わしい表示形態となってしまうが、本例の場合にはこのような問題を回避できる。
【００５５】
なお、上述した実施の形態では、サーバ１０及びクライアント２０は、コンピュータ装置を利用して構成した例としてあるが、専用のデータ蓄積装置やデータ受信・再生装置として構成しても良い。
【００５６】
また、上述した実施の形態で示した表示レイアウト情報については一例を示したものであり、その他のデータ構成による表示レイアウト情報としても良い。即ち、例えば、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻などを示すようにしたが、少なくともいずれか１つの情報を表示レイアウト情報で示すようにすれば良い。或いは、その他の情報を表示レイアウト情報に付加するようにしても良い。
【００５７】
また、上述した実施の形態では、インターネットを利用したネットワークで伝送を行う例について説明したが、その他のネットワークを使用しても良い。例えば、サーバとクライアントとの間での指示やレスポンスの伝送については、インターネットのようなネットワークを使用して、サーバからクライアントへのストリーミングメディアのデータの伝送については、そのメディアデータ伝送用に用意された専用の伝送路を使用しても良い。
【００５８】
【発明の効果】
本発明によると、クライアントに届いた表示レイアウト情報に基づいて、クライアントが受信したストリームデータを表示させる各種状態を設定でき、クライアント側の端末で良好に動画ストリームを表示できるようになる。
【００５９】
この場合、表示レイアウト情報は、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻の少なくともいずれか１つの情報が含まれていることで、これらの表示に関する項目をサーバ側から適切に制御して、クライアント側の端末で動画を表示できるようになる。
【００６０】
また、表示レイアウト情報で示される複数の動画ストリームの内の、少なくとも１つの動画ストリームを、その動画ストリームの表示開始時刻よりも前に、サーバからクライアントに配信するようにしたことで、その表示開始時刻よりも前にクライアントが受信した動画ストリームを蓄積させて、表示レイアウト情報で示される表示開始時刻になってから表示させるようにすることで、表示が開始される時刻になると、待ち時間なく直ちに該当する動画ストリームを表示させることが可能になる。
【００６１】
また、表示レイアウト情報で示される拡大縮小率に応じて、各動画ストリームを配信する際のビットレートを調整することで、例えば複数の動画ストリームを同時に送って、比較的小さいサイズで同時に縮小表示するような場合に、それぞれのビットレートを小さくし、拡大表示する必要のある動画ストリームについては、ビットレートを大きくすることで、クライアント側の端末で良好に動画ストリームを表示させることが可能になる。
【００６２】
また、コンテンツが変更される場合に、その変更の前後で、特定の動画ストリームを連続して表示させる表示レイアウト情報を作成することで、コンテンツが変更された場合であっても、特定の動画ストリームを連続して表示させることが可能になり、同じ動画がコンテンツの変化時に繰り返し再生されるような無駄を無くすことができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態によるシステム構成例を示した説明図である。
【図２】本発明の一実施の形態による機器構成例を示したブロック図である。
【図３】本発明の一実施の形態によるサーバでの配信開始までの処理例を示したフローチャートである。
【図４】本発明の一実施の形態による表示レイアウト情報の一例を示した説明図である。
【図５】本発明の一実施の形態による表示レイアウト情報をＲＴＣＰのプロトコルに則って記述した一例を示した説明図である。
【図６】本発明の一実施の形態によるサーバでの配信開始後の処理例を示したフローチャートである。
【図７】本発明の一実施の形態によるクライアントでの処理例を示したフローチャートである。
【図８】本発明の一実施の形態によるサーバとクライアントとの間での伝送例を示した説明図である。
【図９】本発明の一実施の形態による表示変化例を示した説明図である。
【図１０】本発明の一実施の形態による伝送例を示した説明図である。
【図１１】本発明の他の実施の形態による表示変化例を示した説明図である。
【図１２】従来の複数のストリームデータの伝送例を示した説明図である。
【図１３】複数の画像データを受信して表示させた例を示した説明図である。
【符号の説明】
１…ネットワーク、１０…サーバ、１１…中央制御ユニット、１２…インターフェース部、１３…ハードディスクドライブ、１４…処理ブロック、２０…クライアント、２１…インターフェース部、２２…中央制御ユニット、２３…ハードディスクドライブ、２４…バッファメモリ、２５…処理ブロック、２６…スピーカ、２７…ディスプレイ
Claims (13)
- サーバからクライアントに、画像表示用のストリームを配信するストリーミングデータ配信方法において、
複数の動画ストリームから構成されるコンテンツをサーバから配信する際に、その複数の動画の表示状態を示す表示レイアウト情報を、予めサーバからクライアントに送信するようにした
ストリーミングデータ配信方法。 - 請求項１記載のストリーミングデータ配信方法において、
上記表示レイアウト情報は、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻の少なくともいずれか１つの情報が含まれている
ストリーミングデータ配信方法。 - 請求項１記載のストリーミングデータ配信方法において、
上記表示レイアウト情報で示される複数の動画ストリームの内の、少なくとも１つの動画ストリームを、その動画ストリームの表示開始時刻よりも前に、上記サーバからクライアントに配信するようにした
ストリーミングデータ配信方法。 - 請求項１記載のストリーミングデータ配信方法において、
上記表示レイアウト情報で示される拡大縮小率に応じて、各動画ストリームを配信する際のビットレートを調整する
ストリーミングデータ配信方法。 - 請求項１記載のストリーミングデータ配信方法において、
上記コンテンツが変更される場合に、その変更の前後で、特定の動画ストリームを連続して表示させる表示レイアウト情報を作成する
ストリーミングデータ配信方法。 - 複数の動画ストリームから構成されるコンテンツを保持するコンテンツ保持手段と、
所定のネットワークを介して接続されたクライアントと通信を行う通信手段と、
上記コンテンツ保持手段が保持したコンテンツを上記通信手段から配信させる際に、そのコンテンツを構成する複数の動画の表示状態を示す表示レイアウト情報を、上記通信手段からクライアントに送る制御を行う制御手段とを備えた
データ配信サーバ。 - 請求項６記載のデータ配信サーバにおいて、
上記制御手段の制御で送られる表示レイアウト情報は、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻の少なくともいずれか１つの情報が含まれている
データ配信サーバ。 - 請求項６記載のデータ配信サーバにおいて、
上記制御手段は、表示レイアウト情報で示される複数の動画ストリームの内の、少なくとも１つの動画ストリームを、その動画ストリームの表示開始時刻よりも前に、上記コンテンツ保持手段から読出して上記通信手段から送信させる
データ配信サーバ。 - 請求項６記載のデータ配信サーバにおいて、
上記制御手段は、上記コンテンツ保持手段が保持した各動画ストリームの上記通信手段から送出させるビットレートを、上記表示レイアウト情報で示される拡大縮小率に応じて調整させる
データ配信サーバ。 - 請求項６記載のデータ配信サーバにおいて、
上記制御手段は、コンテンツが変更される場合に、その変更の前後で、特定の動画ストリームを連続して表示させる表示レイアウト情報を作成して上記通信手段から送出させる制御を行う
データ配信サーバ。 - 所定のネットワークを介して接続されたサーバと通信を行う通信手段と、
上記通信手段が受信した動画ストリームのデータを蓄積する蓄積手段と、
上記蓄積手段に蓄積された動画ストリームのデータを再生させる再生手段と、
上記通信手段がサーバから受信した表示レイアウト情報に基づいて、上記再生手段で複数の動画の表示状態を設定する制御手段とを備えた
データ受信装置。 - 請求項１１記載のデータ受信装置において、
上記通信手段が受信した表示レイアウト情報に基づいて、上記制御手段は、コンテンツを構成する各動画の表示位置、拡大縮小率、表示開始時刻、表示終了時刻の少なくともいずれか１つの制御を行う
データ受信装置。 - 請求項１１記載のデータ受信装置において、
上記制御手段は、上記通信手段が受信して上記蓄積手段に既に蓄積された動画ストリームのデータを、表示レイアウト情報で示される再生開始時刻に、上記再生手段で再生させる制御を行う
データ受信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002178962A JP2004023664A (ja) | 2002-06-19 | 2002-06-19 | ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002178962A JP2004023664A (ja) | 2002-06-19 | 2002-06-19 | ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004023664A true JP2004023664A (ja) | 2004-01-22 |
Family
ID=31176533
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002178962A Pending JP2004023664A (ja) | 2002-06-19 | 2002-06-19 | ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004023664A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2005086009A1 (ja) * | 2004-03-02 | 2008-01-24 | 三菱電機株式会社 | メディア配信装置及びメディア受信装置 |
| JP2010034899A (ja) * | 2008-07-29 | 2010-02-12 | Canon Inc | ストリームデータ処理装置、ストリームデータ処理方法、及びストリームデータ処理プログラム |
| JP2010239312A (ja) * | 2009-03-30 | 2010-10-21 | Fujitsu Ltd | ネットワーク監視制御装置及び監視制御方法 |
| US8564501B2 (en) | 2004-03-31 | 2013-10-22 | Seiko Epson Corporation | Image display system |
-
2002
- 2002-06-19 JP JP2002178962A patent/JP2004023664A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2005086009A1 (ja) * | 2004-03-02 | 2008-01-24 | 三菱電機株式会社 | メディア配信装置及びメディア受信装置 |
| JP4510005B2 (ja) * | 2004-03-02 | 2010-07-21 | 三菱電機株式会社 | メディア配信装置及びメディア受信装置 |
| US8564501B2 (en) | 2004-03-31 | 2013-10-22 | Seiko Epson Corporation | Image display system |
| JP2010034899A (ja) * | 2008-07-29 | 2010-02-12 | Canon Inc | ストリームデータ処理装置、ストリームデータ処理方法、及びストリームデータ処理プログラム |
| JP2010239312A (ja) * | 2009-03-30 | 2010-10-21 | Fujitsu Ltd | ネットワーク監視制御装置及び監視制御方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100456924B1 (ko) | 미디어-온-디맨드 시스템과 미디어-온-디맨드 시스템내의미디어에 구성가능 액세스를 제공하는 방법과 머신판독가능 저장 장치 | |
| JP4510005B2 (ja) | メディア配信装置及びメディア受信装置 | |
| US7518992B2 (en) | Interactive data transmission system having staged servers | |
| CA2623835C (en) | Content delivery system and method, and server apparatus and receiving apparatus used in this content delivery system | |
| US7051110B2 (en) | Data reception/playback method and apparatus and data transmission method and apparatus for providing playback control functions | |
| US8775655B2 (en) | System and method for presenting streaming media content | |
| KR20020035571A (ko) | 서버 또는 유저로부터 다른 유저로의 ｖｏｄ | |
| JP2001527709A (ja) | ビデオをオン・デマンドでレンダリングするｖｃｒに似た機能 | |
| JP2002335509A (ja) | デジタルコンテンツの配信方法およびシステム | |
| JP2007080161A (ja) | データ配信システム、部分コンテンツ格納サーバ、応答高速化方法、及びプログラム | |
| JP2003006085A (ja) | コンテンツ配信システムとそのコンテンツ配信方法、及びコンテンツ配信プログラム | |
| JP2009033760A (ja) | 瞬時のメディア・オン・デマンド | |
| WO2017154406A1 (ja) | 広告配信サーバ、番組配信サーバ及び再生端末、並びに映像配信システム | |
| KR101352917B1 (ko) | 비디오 콘텐츠를 동적으로 수신하여 오디오 콘텐츠와 동기화하여 재생하는 방법 및 시스템 | |
| JP2007274318A (ja) | 放送コンテンツ再生システム及び放送コンテンツ再生方法 | |
| WO2013185547A1 (zh) | 一种缓存服务器的服务方法、缓存服务器及系统 | |
| JP2005094769A (ja) | マルチメディアコンテンツの高速ダウンロードサービス装置及びその方法 | |
| JP2004159212A (ja) | 映像コンテンツ配信装置及び方法 | |
| JP2001242876A (ja) | データ受信再生方法、データ受信再生装置、データ送信方法、およびデータ送信装置 | |
| US20130132579A1 (en) | Method and apparatus for random access to multimedia content in wireless communication system | |
| JP2008160301A (ja) | コンテンツ配信装置、ネットワーク端末及びコンテンツ配信システム | |
| JP2006203887A (ja) | Ｖｏｄシステム及びｖｏｄシステムの再構成方法 | |
| JP2004023664A (ja) | ストリーミングデータ配信方法、データ配信サーバ及びデータ受信装置 | |
| WO2010057391A1 (zh) | 一种流媒体播放控制方法、设备及系统 | |
| JP2004104704A (ja) | 映像再生装置、映像再生方法、プログラム |