JP2005328269A - クライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システム - Google Patents

Abstract

【課題】 ストリームの切り替え時間遅れをできるだけ少なくして映像や音声を切り替えて再生し表示することが可能なクライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システムを提案する。
【解決手段】 ストリーミング切り替え配信システム１００は、ストリーミングサーバ４００及びクライアント端末３００等より構成され、ストリーミングサーバ４００は、受信バッファ、パケット生成手段及び制御コマンド解析手段等より成るストリーム切り替え送信手段４１０と送信するコンテンツを格納するストリーミング記憶装置４２０等をそなえ、クライアント端末３００は、入力手段３１０、コンテンツ属性解析手段３２０、コンテンツ選択手段３３０及び再生ストリームの送信指示を出しストリームを受信するストリーム切り替え受信手段３４０等を備えている。
【選択図】 図１

Description

本発明は映像や音声のデジタルコンテンツを、インターネットを介してストリーミング配信する技術に関し、特に映像や音声のストリームをユーザの要求に応じて動的に切り替えてシームレスに再生を行うクライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システム技術に関する。

インターネットを経由して圧縮された映像や音声のデジタルコンテンツをストリーム配信するシステムがある。このストリーム配信システムでは、配信するストリーミングサーバと受信するクライアント端末間のネットワーク環境が不安定な為ストリーミングのパケット遅延やパケット再送などの現象が発生することがある。コンテンツを視聴しているユーザにとってこの現象は映像や音声の途切れとなって現れる。

そこでこの現象を少なくするためにクライアント端末において受信したストリームの２秒〜５秒程度に相当するパケットをバッファリングし、バッファリングされた内の最も古いパケットから順に映像と音声のデコードを行って表示するという手法が採られている。

このようなバッファリング方式を用いてストリーミングを行っている最中にユーザが見たいアングルや聞きたい音声チャンネルの切り替えが可能なサービスを提供するストリーミング配信システムが開示されている（特許文献１参照。）。
特開２００２−１１８５９２号公報

しかしながら、従来のストリーミング配信システムを用いて、ストリーミングを行っている最中にユーザの要求するアングルや音声チャンネルの切り替えを行なうサービスを提供する場合、ユーザからストリームの切り替え指示を受けるとストリーミングサーバ側では直ちに現在送信しているストリームから送信要求のあったストリームへ送信するストリームを切り替える。しかし、これを受信したクライアントでは数秒のバッファリングを行っているのでユーザが切り替え指示を出してから実際にデコードされて表示される映像や音声が切り替わるのはバッファリングに相当する時間、つまり２秒〜５秒後となってしまい、実際に見たいシーンを見逃したり、切り替えが実施されるまでいくらかの時間待たなければならないという課題があった。

本発明は上記の問題点に鑑みてなされたものであり、ストリーミング配信システムにおいてユーザの切り替え指示を受けるとストリームの切り替え時間遅れをできるだけ少なくして映像や音声を切り替えて再生し表示することが可能なクライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システムを提案することを目的とする。

上述した従来の技術の課題を解決するため、本発明の第１の特徴は、[イ]ストリーミングサーバより配信されるストリームを再生するクライアント端末であって、ストリーム選択画面上の入力ポインタがストリーム選択の決定をする入力手段（３１０）近辺の指定領域内に位置することを検出してストリーム切り替え準備の開始を判定する切り替え準備判定手段（４３）と、[ロ]ストリームを格納する受信バッファ内のバッファ蓄積量を検出するバッファ蓄積量検出手段（５７）と、[ハ]切り替え準備判定手段（４３）によってストリームの切り替え準備の開始が判定された場合、バッファ蓄積量検出手段で検出したバッファ蓄積量に関する情報をストリーム切り替え準備の開始を伝える情報に付加して制御コマンドを生成する制御コマンド生成手段（４６）とを備え、制御コマンドを前記ストリーミングサーバ側へ送信するクライアント端末であることを要旨とする。

更に本発明の第１の特徴は、[ニ]切り替え準備判定手段（４３）は、入力ポインタが指定領域外に退避したことを検出してストリーム切り替え準備の終了を判断し、制御コマンド生成手段（４６）は、切り替え準備判定手段（４３）によりストリームの切り替え準備の終了が判定された場合にはバッファ蓄積量に関する情報をストリーム切り替え準備の終了を伝える情報に付加し、ストリーム選択決定の入力手段（３１０）によりストリームの切り替えが確定した場合にはバッファ蓄積量に関する情報をストリーム切り替え要求する情報に付加することを加えてもよい。

本発明の第２の特徴は、[イ]ストリームを再生するクライアント端末に対しストリームを配信するストリーミングサーバであって、クライアント端末よりストリーム切り替え準備の開始情報を受信すると、クライアント端末へのストリームの送信を停止する送信停止期間を算出し、送信停止期間はストリームの送信停止を行うストリーム送信管理手段（３１）を備えるストリーミングサーバであることを要旨とする。

更に本発明の第２の特徴は、[ロ]ストリーム送信管理手段（３１）は、クライアント端末より受信するストリーム切り替え要求に基づいて、クライアント端末の受信バッファを所望の蓄積量に復帰させるに必要なストリームを配信する際の送信レートを算出する送信レート算出手段（３１ｂ）を備えることを加えてもよい。

本発明の第３の特徴は、[イ]ストリームを配信するストリーミングサーバと、配信するストリームを受信して再生するクライアント端末を含むストリーミング切り替え配信システムであって、ストリーム選択画面上の入力ポインタがストリーム選択の決定をする入力手段（３１０）近辺の指定領域内に位置することを検出してストリーム切り替え準備の開始を判定する切り替え準備判定手段（４３）、ストリームを格納する受信バッファ内のバッファ蓄積量を検出するバッファ蓄積量検出手段（５７）及び切り替え準備判定手段（４３）によってストリームの切り替え準備の開始が判定された場合、バッファ蓄積量検出手段（５７）で検出したバッファ蓄積量に関する情報をストリーム切り替え準備の開始を伝える情報に付加して制御コマンドを生成する制御コマンド生成手段（４６）とを備え、制御コマンドをストリーミングサーバ側へ送信するクライアント端末と、[ロ]クライアント端末よりストリーム切り替え準備の開始情報を受信すると、クライアント端末へのストリームの送信を停止する送信停止期間を算出し、送信停止期間はストリームの送信停止を行うストリーム送信管理手段（３１）を備えるストリーミングサーバとを備えるストリーム切り替え配信システムであることを要旨とする。

更に本発明の第３の特徴は、[ハ]切り替え準備判定手段（４３）は、入力ポインタが指定領域外に退避したことを検出してストリーム切り替え準備の終了を判断し、[ニ]制御コマンド生成手段（４６）は、切り替え準備判定手段（４３）によりストリームの切り替え準備の終了が判定された場合にはバッファ蓄積量をストリーミングサーバに送信するためのストリーム切り替え準備の終了を伝える情報に付加し、ストリーム選択決定の入力手段（３１０）によりストリームの切り替えが確定した場合にはバッファ蓄積量に関する情報をストリーム切り替え要求する情報に付加し、[ホ]ストリーム送信管理手段（３１）は、クライアント端末より受信するストリーム切り替え要求に基づいて、クライアント端末の受信バッファを所望の蓄積量に復帰させるに必要なストリームを配信する際の送信レートを算出することを加えてもよい。

本発明のクライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システムによると、ユーザ入力であるマウス位置やキーボードのフォーカスを監視することでストリームの切り替えを予測し、送信するストリームの送信レートを制御して受信バッファの蓄積量が少なくなるように制御することができる。これにより、ストリーム切り替えが実行された時にバッファ蓄積による切り替えの時間遅れが少ないシームレス切り替えが可能となる。また切り替えが行われた後、あるいは切り替え予想が終了した後に、蓄積量が低下した受信バッファを通常のバッファ量に速やかに復帰するように制御することによってネットワーク変動に影響されない安定したストリーミングが実現できる。

また、ストリーミングサーバは切り替えが予想される唯一１本のストリームのみを切り替え準備のために用意しておく構成となるので、ストリーミングサーバのＣＰＵやメモリの資源が節約できる。これは多数のストリームを切り替えて配信するシステムやサービスに特に有効である。

以下、本発明の実施の形態に係るクライアント端末、ストリーミングサーバ及びストリーミング切り替え配信システムについて説明する。尚、本発明の実施の形態において使用される機器及び手法等は、一例であり、本発明はこれらに限定されるものでないことは勿論である。

伝送方式について説明すると、インターネットを使って映像や音声のストリームをリアルタイムに伝送するためには、ＲＴＰ（リアルタイムトランスポートプロトコル）が規定されている。低いビットレートでも劣化が少なく品質の高い画質や音質の圧縮方式であるＭＰＥＧ４（ムービングピクチャエキスパートグループフェーズ４）のストリームをＲＴＰ伝送するための規格はＩＥＴＦ（インターネットエンジニアリングタスクフォース）のＲＦＣ３０１６(ＲＴＰペイロードフォーマット for ＭＰＥＧ４オーディオ／ビジュアルストリーム)として標準化されている。再生制御するためのコマンドセットなどはＲＦＣ２３２６で規定されている。本発明ではこれらの伝送方式を用いたストリーム配信サーバとクライアント端末の例として説明している。しかし映像や音声の圧縮方式、伝送プロトコル、再生制御のプロトコルなどこれに限定されるものではない。

以下の説明においては、音声ストリームの切り替えについて主に説明しているが、ストリームの切り替えは音声に限定されるものでなく、映像やその他ストリームにも適応可能である。又、以下においては、映像と音声のストリームをそれぞれ別のチャンネルとしてストリーム配信サーバとクライアント端末間で伝送する。これに加え再生制御コマンドの送受信も映像や音声のチャンネルと独立したチャンネルとして伝送する。

（ストリーム切り替えシステム）
本発明の実施の形態に係るストリーム切り替え配信システム１００は、図１に示すように、ストリーミング配信サーバ５００と、ストリーミング映像の配信を要求して、取得したストリーミング映像を再生するクライアント端末３００等より構成され、各々の装置はインターネット６００を介して通信可能となっている。

ストリーミング配信サーバ５００は、ユーザの認証やコンテンツのリストを提示するアプリケーションサーバ２００及びクライアント端末の要求により映像や音声のストリーミングを行うストリーミングサーバ４００を備える。

アプリケーションサーバ２００は、コンテンツリスト提示手段２１０及びコンテンツ属性提示手段２２０等を備えている。コンテンツリスト提示手段２１０は、ストリーミングで提供可能なコンテンツのタイムテーブルや視聴価格などのリストを動的に生成されたＨＴＭＬ（ハイパーテキストマークアップランゲッジ）ページとしてユーザに提示する。コンテンツ属性提示手段２２０は、クライアント端末３００へ提供するコンテンツリストにコンテンツ属性を付加する。コンテンツが複数の映像アングルや音声チャンネルを提示可能な場合、コンテンツ属性に記述される。この他、アプリケーションサーバ２００は、会員登録、ユーザ識別、課金処理などのアクセス制御を行う。

ストリーミングサーバ４００は、ストリーム切り替え送信手段４１０及び送信するコンテンツを記憶するストリーミング記憶装置４２０を備えている。ストリーム切り替え送信手段４１０は再生中のストリームを切り替えるための要求をクライアント端末３００から受信し、送信するストリームを切り替えてクライアント端末３００に送信するための手段であり、図２に示すように、音声１バッファ２２、音声２バッファ２１、切り替え手段２３、音声パケット生成手段２４、音声ストリーム送信手段２５、映像バッファ２６、映像パケット生成手段２７、映像ストリーム送信手段２８、制御コマンド受信手段２９、制御コマンド解析手段３０及びストリーム送信管理手段３１等を備える。

音声１バッファ２２及び音声２バッファ２１はストリーミング記憶装置４２０より送信される音声チャンクを格納する。ＭＰＥＧ４ファイルフォーマットでは音声や映像のデータブロックの単位をチャンクと呼ぶ。映像バッファ２６は、ストリーミング記憶装置４２０より送信される映像チャンクを格納する。映像パケット生成手段２７は、ストリーミング記憶装置４２０内の映像データより映像パケットを生成する。音声パケット生成手段２４は、ストリーミング記憶装置４２０内の音声データより音声パケットを生成する。切り替え手段２３は、ユーザより音声の切り替え要求を受信した際に、音声を切り替える。

映像ストリーム送信手段２８は、映像ストリームを要求元のクライアント端末３００に送信する。音声ストリーム送信手段２５は、音声ストリームを要求元のクライアント端末３００に送信する。制御コマンド受信手段２９は、クライアント端末３００より映像ストリーム又は音声ストリームの再生を制御するコマンドを受信する。制御コマンド解析手段３０は、クライアント端末より指示のあった制御要求を解析する。

ストリーム送信管理手段３１は、クライアント端末３００へ送信を行った最新の音声パケットの時刻情報であるタイムスタンプを常に記憶する。送信停止期間算出手段３１ａはストリームの送信停止期間を算出する。送信レート算出手段３１ｂは、ストリームの送信レートを算出する。

クライアント端末３００は、アプリケーションサーバ２００から受信するコンテンツリストから視聴するストリームを選択し、ストリーミングサーバ４００に再生ストリームの送信指示を出し、受信したストリームを再生する。クライアント端末３００は、入力手段３１０、コンテンツ属性解析手段３２０、コンテンツ選択手段３３０、ストリーム切り替え再生手段３４０及び再生手段３５０等を備えている。

入力手段３１０は、ユーザによるストリーム切り替えをナビゲーションするためにＧＵＩ（グラフィカルユーザインタフェース）画面に表示されるストリーム再生を切り替えるための選択ボタン又はストリームを再生させる為の入力ボタン等であり、キーボード、マウス等を介して行なわれる。これはマウス等の入力ポインタを移動させてクリックしたり、キーボードの矢印キーで選択可能な候補を上下させて切り替えたい音声を選択し、エンターキーで選択の確定を行ってもよい。ストリーム切り替えナビゲーション画面の例を図３に示す。本発明の実施の形態では、４種類の音声切り替え（音声１〜音声４）を行う為４種類のストリーム切り替えボタンがＧＵＩに配置されている。ユーザが音声１〜音声４等のボタンを選択することでストリームの切り替えメッセージが発生する。なお選択可能な音声の種類の数はこれに限られず、音声に限らず映像でも同様に切り替えは可能である。上記はパソコンの入力装置の例として説明したが、テレビのような家電タイプの装置であればリモコンのアップダウンキーで選択候補を選び、確定キーで選択の確定を行う。

コンテンツ選択手段３３０は、アプリケーションサーバ２００より提示されるコンテンツリストより、ＧＵＩ画面上の入力等によって、ユーザに再生を要望するコンテンツの選択を促す。再生手段３５０は、映像ストリームや音声ストリームの再生処理を行う。

ストリーム切り替え再生手段３４０は、再生制御メッセージを用いてストリーミング切り替え要求を生成し、ストリーミングサーバに送信する手段であり、図４に示すように、映像ストリーム受信手段５１、音声ストリーム受信手段５２、映像受信バッファ５３、音声受信バッファ５４、映像デコーダ５５、音声デコーダ５６、バッファ蓄積量検出手段５７、領域検出手段４１、選択検出手段４２、切り替え準備判定手段４３、切り替え判定手段４４、再生管理手段４５、制御コマンド生成手段４６及び制御コマンド送信手段４７等を備えている。

映像ストリーム受信手段５１は、ストリーミングサーバ４００より送られてくる映像ストリームを受信する。音声ストリーム受信手段５２は、ストリーミングサーバ４００より送られてくる音声ストリームを受信する。映像受信バッファ５３は、受信した映像パケットを記憶する。音声受信バッファ５４は、受信した音声パケットを記憶する。映像デコーダ５５は、MPEG4方式で圧縮された映像のデコードを行なう。音声デコーダ５６はMPEG4方式で圧縮された音声のデコードを行なう。バッファ蓄積量検出手段５７は、映像受信バッファ５３若しくは音声受信バッファ５４のパケット蓄積量を検出する。

領域検出手段４１は、ユーザがマウス等を動かすことにより、入力ポインタがストリーム選択画面の指定領域に入ったことを検出する。選択検出手段４２は、ストリーム選択画面上の指定領域にて、ユーザがマウス等をクリックしたことにより、映像又は音声が選択されたことを検出する。切り替え準備判定手段４３は、領域検出手段４１によって検出した入力ポインタの位置情報を参照してストリームの切り替え準備の開始およびストリームの切り替え準備の終了を判定する。切り替え判定手段４４は、ストリーム選択画面の指定領域内のストリーム選択ボタンがマウス等によりクリック等されたことを検出し、切り替え要求が発生したことを判定する。再生管理手段４５は、ストリーム再生の開始、停止等の制御を行なう。

コンテンツ属性解析手段３２０は、アプリケーションサーバ２００から提供されるコンテンツリストに示されているストリーム属性を解析し、コンテンツが複数の映像アングルや複数の音声チャンネルをインタラクティブに切り替え可能であることを判定する。

制御コマンド生成手段４６は、ストリーム再生の開始、停止、切り替え等の要求が発生した際に、これらの要求の制御コマンドを生成する。制御コマンド送信手段４７は、映像ストリーム又は音声ストリームの再生を制御するコマンドをストリーミングサーバ４００に対して送信する。尚、切り替え準備判定手段４３によりストリームの切り替え準備の開始が判定された場合には、音声受信バッファ５４若しくは映像受信バッファ５３の蓄積量をストリーム再生の制御コマンドに付加して送信する。

ここで、制御コマンドの１つであるストリーム切り替え要求メッセージの例を図５に示す。ストリーミングの再生制御メッセージはＲＦＣ２３２６で標準化されているＲＴＳＰ（リアルタイムストリーミングプロトコル）に従って例示した。切り替えて再生を行うストリームのメディア識別情報をＡＮＮＯＵＮＣＥコマンドを用いてクライアント端末３００からストリーミングサーバ４００に送信する。

ＡＮＮＯＵＮＣＥコマンドのセッション記述ブロックの具体例を説明する。まず切り替えて再生を行うストリームのメディア識別は音声の場合m=audio、映像の場合m=videoで指定する。メディア識別を指定する最後のフィールドにはPayload-Typeを指定する。図５では音声のPayload-Typeを９６として例示している。同時に音声のどのトラックを切り替えて再生するかを識別するためにメディアＵＲＬを指定する。図５ではa=controlの後にメディアＵＲＬを指定する。ＡＮＮＯＵＮＣＥコマンドで伝達するメッセージの機能要求を指定するためにa=modeの後に機能要求を指定する。ストリーム切り替え要求の場合はchangeを指定する。更に、切り替え対象となるメディア、例えば実施の形態においては音声データの音声受信バッファ５４のバッファ蓄積量をバイト単位でa=bufferの後に記述する。このバッファ蓄積量の値の取り扱いについては後述する。

切り替え要求メッセージをＲＴＳＰプロトコルのＡＮＮＯＵＮＣＥコマンドの例で説明したが、これはＡＮＮＯＵＮＣＥコマンドに限定されることはない。さらにＨＴＴＰプロトコルを用いてセッション記述によってクライアント端末からストリーミングサーバに伝達することも可能である。ＨＴＴＰプロトコルによって切り替え要求メッセージを送信する場合は再生制御のＲＴＳＰプロトコル用とは別にＨＴＴＰプロトコル用のポートおよびメッセージの送受信手段がサーバおよびクライアント端末に必要である。尚、ストリーム切り替え要求のプロトコルはこれらに限定されないことは勿論である。

（ストリーム切り替え方法）
次にストリーム切り替え配信システム１００の全体動作について図６のシーケンス図を用いて説明する。

（ａ）ステップＳ１０１において、先ずクライアント端末３００は、ストリーミング配信サーバ５００のアプリケーションサーバ２００が提供するコンテンツページへ、インターネット６００を介して、アクセスする。図１のコンテンツリスト提示手段２１０はこのアクセスに対し、提供可能なコンテンツリストを提示する。ステップＳ１０２において、クライアント端末３００は、提示されたコンテンツ内より、再生するコンテンツを指定して再生指示を出す。

（ｂ）ステップＳ１０３において、ストリーミングサーバ４００のストリーム切り替え送信手段４１０は、要求元のクライアント端末３００に対し指定されたコンテンツのストリーミング配信を開始する。配信されるストリームは映像ストリームと明示的に音声チャンネルの指定が無い場合の既定値である音声１のストリームである。

（ｃ）ステップＳ１０４においては、クライアント端末３００が音声１から音声２へのストリーム切り替え準備の情報を伝える情報を図３の入力手段３１０を介して取得する。ストリーム切り替え準備の開始を伝える情報について説明する。通常、ストリーム切り替えを確定するためには図７に示すように入力ポインタを選択ボタンの白丸の領域（○）にポイントしてクリックする。白丸の領域に入力ポインタが置かれてクリックされると切り替え選択が確定したことを表示するために白丸は黒丸（●）等に変更される。この選択の確定ボタンである丸領域（○）の周辺に点線で囲んだ長方形の領域を図８のように設け、この４つの領域を切り替え選択の動作予測を行うための指定領域として設定する。この指定領域に入力ポインタが置かれたことを検出するために、図４のストリーム切り替え再生手段３４０の領域検出手段４１は、入力ポインタのＧＵＩ画面上のＸＹ座標をセンシングして、指定領域のＸＹ座標と比較し、指定領域に入力ポインタが位置したことを検出する。指定領域に入力ポインタが位置したことを検出するとこれを切り替え準備判定手段４３に割り込み等の方法で伝達する。切り替え準備判定手段４３では選択予想されるストリームが現在再生中のストリームでない場合、制御コマンド生成手段４６にこれを伝える。もし現在音声２を再生中であり、入力ポインタが音声２の指定領域に置かれた場合、ここで音声２の選択確定がなされても音声の切り替え制御は必要ないので、制御コマンド生成手段４６への伝達は行われない。

現在音声１を再生中で、音声２の指定領域に入力ポインタが位置した場合、バッファ蓄積量検出手段５７は切り替えが行われるメディアが音声か映像かを判断し、音声の場合であれば音声受信バッファ５４に蓄積されている音声ストリームの蓄積量を検出する。制御コマンド生成手段４６は、図９のストリーム切り替え準備の開始を伝える制御コマンドに、検出された音声バッファの蓄積量（バイト単位）を付加して制御コマンドを生成する。a=mode:preset_startで切り替え準備の開始を指定し、バッファ蓄積量をバイト単位でa=buffer:32000にて指定する。これは３２Ｋバイトのバッファ蓄積量の例である。制御コマンド送信手段４７はこの制御コマンドをストリーミングサーバ４００に送信する。

（ｄ）ステップＳ１０５において、ストリーム切り替えの準備を開始する情報を受信したストリーミングサーバ４００では、送信停止期間算出手段３１ａがストリーム送信停止期間を算出する。ストリーム送信管理手段３１は、算出結果を基にクライアント端末３００に対する音声１のストリームを一時停止し、クライアント端末３００の音声受信バッファ５４のパケット蓄積量を最小にさせる。ストリーミングサーバ４００は、現在送信中の音声１の音声データに加え、切り替えが予想される音声２の音声データをストリーミング記憶装置４２０より読み出して、音声２バッファ２１にバッファリングして切り替え送信の準備をする。

（ｅ）音声２への切り替えボタンが押されるとステップＳ１０６において、クライアント端末３００にて、音声２へのストリーム切り替え要求が発生する。すると図４の制御コマンド生成手段４６は音声ストリーム切り替え要求の制御コマンドをストリーミングサーバ４００に送信する。

（ｆ）ステップＳ１０７において、図４のストリーミングサーバ４００の制御コマンド受信手段２９は音声ストリーム切り替え要求の制御コマンドを受信し、制御コマンド解析手段３０がこれを解析する。解析結果はストリーム送信管理手段３１に渡される。ストリーム送信管理手段３１は送信レートの算出を行い、算出結果を音声ストリーム送信手段２５に引き渡す。音声ストリーム送信手段２５はこの算出結果にしたがって、音声２のストリームを、ストリーム切り替え期間となる一定時間だけ高レートにてクライアント端末３００に送信する。

ストリーム切り替えを行う場合、既に図２の音声２バッファ２１に用意されている音声２データに直ちに切り替えてクライアント端末３００に送信するようにする。

クライアント端末３００では切り替え準備の開始を受信した結果、音声受信バッファ５４のバッファ蓄積量が予め最小値に設定されている為、ストリーム切り替え遅延は最小限に抑えられ、ストリームの切り替えはシームレスに実行される。

ステップＳ１０８にて、ストリーム切り替え期間が終了すると、音声２のストリームを通常のレートにてクライアント端末３００に継続して送信する。

（ｇ）ステップＳ１０９においては、クライアント端末３００よりストリーム再生の停止コマンドが入力手段３１０を介して入力されると、ストリーミング配信サーバ５００はストリーム配信を停止する。

（ストリーミングサーバの動作）
次に、ステップＳ１０５のストリーム切り替え準備処理及びＳ１０７のストリーム切り替えの際のストリーミング配信サーバ５００の動作について、図１０のフローチャートを参照して詳細に説明する。

（ａ）ステップＳ２０１において、図２のストリーミングサーバ４００の制御コマンド受信手段２９が、映像及び音声１のストリーム配信中に、クライアント端末３００より音声２へのストリーム切り替え準備の開始を伝える制御コマンドを受信する。

（ｂ）ステップＳ２０２では、ストリーミングサーバ４００は、クライアント端末３００へ対するストリーミング送信の切り替え準備を行なう。制御コマンドには切り替え可能性のある唯一のストリーム（音声２）が指定されている為、音声１のストリームを音声１バッファ２２を用いて送信すると同時に、音声２のストリームを音声２バッファ２１に準備する。

（ｃ）ステップＳ２０３では、図２の送信停止期間算出手段３１ａが、音声１のストリーム送信停止期間を算出する。このストリーム送信停止期間算出処理については後述する。ステップＳ２０４では、図１１に示すように、算出されたストリーム送信停止期間（ｔ１〜ｔ２）、音声１の送信を一時停止する。ストリーム送信を停止した結果クライアント端末３００の音声受信バッファ５４が最小値となると、ステップＳ２０５では、通常の送信レートで映像と音声１を送信する。再度、通常の送信レートでストリームを配信されても、クライアント端末３００では映像及び音声１の再生が行われている為、音声受信バッファ５４は図１１の最小値を保っている。

（ｄ）ステップＳ２０６では、ストリーム切り替え準備中にクライアント端末３００よりストリーム切り替え準備の終了を伝える情報を受信したかを判断する。ストリーム切り替え準備の終了を伝える情報を受信した場合はステップＳ２１１へ進むが、ストリーム切り替え準備の終了を伝える情報を受信しない場合はステップＳ２０７へ進みストリーム切り替え要求を受信したかを判断する。ここでストリーム切り替え要求を受信した場合はステップＳ２０８へ進むが、トリーム切り替え要求を受信しなかった場合はＳ２０６のステップに戻り、ストリーム切り替え準備の終了を伝える情報またはストリーム切り替え要求のいずれかを受信するまでこれを繰り返す。

（ｅ）ステップＳ２０７において、一定の待ち時間の後、クライアント端末３００からストリーム切り替えの制御コマンドを受信すると、図２のストリーム送信管理手段３１はクライアント端末３００へ送信を行った最新の音声ストリームの再生位置を確認しその時刻情報（タイムスタンプ）を取得する。映像および音声の時刻情報はタイムスタンプ形式で表現されてサーバ内部で処理される。またストリーム送信されるＲＴＰパケットにもそのパケットの時刻情報としてタイムスタンプを付加して送信される。通常、音声と映像は各々異なるクロックレートを基準としたタイムスタンプが用いられる。クライアントにおいては受信したＲＴＰパケットに付加されているタイムスタンプの情報を用いて現在の再生時刻を計測する。

そして取得した時刻情報の後続に該当する切り替え後の音声ストリームを読み出して送信パケットを構成して送信する。音声や映像のコンテンツはフレーム単位で構成されるので、フレーム単位でストリームの切り替えが行われる。映像のフレームは１／３０秒の１画面を構成する画像である。音声の場合は例えば１０２４オーディオサンプルを１つにまとめたデータ構造である。図１２（ａ）はストリームパケットをＵＤＰ（ユーザデータグラムプロトコル）で伝送するためのパケット構造である。ＲＴＰ（リアルタイムトランスポートプロトコル）パケットで伝送する場合、図１２（ｂ）のＲＴＰヘッダーのPayloadTypeで映像と音声を識別する。また映像や音声の再生時刻はＲＴＰヘッダーのTimeStampフィールドに記述される。圧縮された映像や音声のデータはＲＴＰペイロードにおかれる。

（ｆ）ステップＳ２０８では、切り替え手段２３がストリームの切り替えを行なう。なおストリーミング送信を行う映像、音声１〜音声４のストリームは、図２に示すように、１つのファイルにチャンク構成を持って格納されている。各々のストリームの属性や、可変長である圧縮ビットストリームに対してストリーム切り替え要求があると即座に再生中のタイムスタンプに該当するファイル上の位置をポイントするためのサーチ情報などはコンテンツのオーサリング時に生成されメタ情報としてファイルの先頭に格納されている。本発明の実施の形態ではＭＰＥＧ４−ＳＹＳＴＥＭ規格（ＩＳＯ／ＩＥＣ １４４９６）やアップル社のＱｕｉｃｋＴｉｍｅファイルフォーマットなどのファイルをストリーミングサーバ４００のコンテンツファイル形式として用いた例について説明されているが、この形式に限定されるものではない。

（ｇ）ステップＳ２０９においては、音声ストリーム送信手段２５が、図１３に示すような送信順序でクライアント端末３００にパケットを送信する。音声２は一定期間（ｔ１４〜ｔ１８）は、クライアント端末３００の音声受信バッファ５４の蓄積量を最大値に戻す為、通常よりも高いレートで送信される。これにより音声受信バッファ５４の蓄積量は、図１１に示すように切替実施時（ｔ３）から最大値（ｔ４）に復帰する。尚、この送信方法については後述する。

（ｈ）ステップＳ２１０では、再び通常の送信レート（図１３のｔ１９参照）にて音声２のストリームを送信する。

（ｉ）ステップＳ２１１では、音声の切り替えが行なわれない為、クライアント端末３００の音声受信バッファ５４を図１４の切り替え予想のキャンセル（ｔ３）後から最大値（ｔ４）に戻す。この為通常より高レートにて音声１をストリーミング送信する。尚、この送信方法については後述する。

（ｊ）ステップＳ２１２では、再び通常の送信レートにて音声１のストリームを送信する。

次にステップＳ２０３のストリーム送信停止期間の算出手法について図１５のフローチャートを用いて説明する。

（ａ）ステップＳ３０１においては、送信停止期間算出手段３１ａが、送信平均レートを取得する。尚、一例として音声ストリームの平均配信レートは「１２８Kbps=16KByte/Sec」として説明する。

（ｂ）ステップＳ３０２においては、クライアントのバッファ蓄積量を取得する。ストリーム切り替え準備の開始を伝える情報にはクライアント端末３００の音声の受信バッファの蓄積量が記述されている。例えば、１２８Kbpsの２チャンネルの圧縮音声の場合、クライアント端末３００において２秒のバッファリングをすると３２Kバイトのバッファ蓄積量となる。図９のストリーム切り替え準備の開始を伝える情報の制御コマンドでは「a=buffer:32000」として記述されている。

（ｃ）ステップＳ３０３においては、クライアントのバッファの最小値を設定する。例えばクライアント端末のバッファ蓄積量を０．５秒に設定すればストリーム切り替えの遅延が０．５秒に短縮される結果となる。平均送信レートが16KByte/Secの場合、０．５秒のバッファ量は８KByteに相当する。

（ｄ）ステップＳ３０４においては送信停止期間を算出する。音声のストリームを一定のインターバルでコンスタントに配信サーバから送出する状況を想定すると、クライアント端末の３２Kバイトのバッファ蓄積量を１／４の８Kバイトに減らすためには本来は２４Kバイトの音声ストリームを送るべき期間に渡ってストリームの送信を停止すればよい。音声ストリームの平均配信レートは１２８Kbps=16KByte/Secなので、24K／16K=1.5秒がストリーム送信停止の期間である。

１２８Kbpsつまり16Kバイト／秒で送っているので、１.５秒間の期間だけストリーム送信を停止すると16Kバイト×1.5秒＝２４Kバイトの音声データが送信されない。よって、クライアント端末３００の受信バッファは３２Kバイト−２４Kバイト＝８Kバイトのバッファ蓄積量で推移することになる。

上記のストリーム停止期間が終了すると直ちに通常の配信レートで音声を送信する。ストリーミングサーバ４００とクライアント端末３００のインターネットの環境が安定している場合や、社内ＬＡＮ等の安定したネットワーク環境の場合はバッファ蓄積量を０．２５秒に減らしてストリーム切り替えの遅延が０．２５秒となるように設定することも可能である。受信バッファの最小値は上述の０．５秒または０．２５秒に限定されるものではなく、ネットワーク環境の安定性と遅延が許容される範囲で任意に設定可能である。クライアント端末３００の環境設定の項目として高／中／低などのバッファ量の最小値の選択肢を提示し、クライアント端末３００を操作するユーザに選択してもらうのが好適である。例えば、高＝１秒＝１６Kバイト、中＝０．５秒＝８Kバイト、低＝０．２５秒＝４Kバイトという最小値の設定となる。ここで設定されたバッファの最小値をストリーミングサーバ４００に送信する制御コマンドに、例えば、「a=minimum_buffre:8000」のように付加することによってストリーミングサーバ４００から送信するストリームのきめ細かな制御が可能となる。

次にステップＳ２０９のストリーム送信管理手段３１が受信バッファ蓄積量を最大値に戻す際の手法について図１６のフローチャートを参照して説明する。以下の説明では、音声受信バッファ５４の蓄積量の最大値を２秒として説明するがこのバッファ最大値に限定されるものではない。尚、この処理はストリーム切り替え準備の開始によってバッファの蓄積量を最小にした後、ストリーム切り替えが実際に行われた場合、およびストリーム切り替えが行われることなく、ストリーム切り替え準備の終了となった場合に実施される。

（ａ）ステップ４０１では図２の送信レート算出手段３１ｂが送信平均レートを取得する。送信するコンテンツのメタ情報に映像と音声の平均送信レートが記載されているのでこの情報を用いて映像と音声の送信速度が制御される。本実施例の場合、音声の配信レートの平均は１６Kバイト／秒である。

（ｂ）ステップＳ４０２では、送信レート算出手段３１ｂがクライアント端末３００のバッファ蓄積量を取得する。音声のバッファ蓄積量を付加したストリーム切り替え要求の制御コマンドには、図５のように、「a=buffer:8000」として８Kバイトのバッファ蓄積量が記述されている。

（ｃ）ステップＳ４０３では、クライアント端末３００のバッファ最大値を設定する。例えば、１２８Kbps＝16Kバイト／秒の音声ストリームの場合、受信バッファの最大値である２秒のデータに相当するバッファ蓄積量は１６Ｋバイト×２秒＝３２Kバイトである。

（ｄ）ステップＳ４０４では、送信レート算出手段３１ｂがバッファ不足容量を算出する。現在のバッファ蓄積量８Ｋバイトから最大値のバッファ蓄積量３２Ｋバイトに復帰するためには、３２K−８K＝２４Kバイトの音声データを通常の送信データに加算して送信する必要があることがわかる。

（ｅ）ステップＳ４０５では、平均レートより高いレートで送信を行う期間の開始時刻として現在の時刻をｔ１として記憶する。同時に高いレートで送信を行う期間に送信する総送信データ数Ｆを「０」に初期化する。

（ｆ）ステップＳ４０６では、１パケットのストリームを実際に送信する。ここで送信済みのデータ数をＸと定義する。Ｓ４０７において、目標送信バイト数Ｄを「送信平均レートＡ＊（現在時刻−切り替え予測時刻ｔ１）＋バッファ不足量Ｅ」とし、高レートでの送信を開始した時刻ｔ１からの総送信データ数Ｆを「Ｆ＋送信済みデータ数Ｘ」として、目標送信バイト数と総送信データ数の算出を行なう。

通常の送信レートは１６Kバイト／秒なので２４Kバイトのデータを余分に送るためには、切り替え確定後の最初の３秒間は１６K+８K＝２４Kバイトのデータを送ることに相当する。あるいは１６K＋４Kバイト＝２０Kバイトのデータを６秒間送る方法でもよい。しかしながら送信スケジュールは送信帯域の余裕度に左右される結果となり、当然ながらネットワーク環境によって余裕度は動的に変化するので、ここでは切り替え確定後Ｎ秒間はできるだけ高いレートで音声ストリームを送信して、１６Kバイト×Ｎ秒＋２４Kバイトのデータが転送できた時点で通常の送信レートである１６Kバイトに復帰するようにする。

（ｇ）最後にステップＳ４０７で目標送信バイト数Ｄの送信が完了するとこの処理を終了する。

（クライアント端末の動作）
次に、クライアント端末３００がステップＳ１０４においてストリーム切り替え準備の開始を検出する動作と、ステップＳ１０６にてストリーム切り替え要求を検出し送信する動作について図１７のフローチャートを用いて詳細に説明する。

（ａ）先ず、ステップＳ５０１において、クライアント端末３００がストリーム切り替え準備の開始を検出すると、ストリーミングサーバ４００にストリーム切り替え準備の開始を伝える制御コマンドを送信する。するとストリーミングサーバ４００はストリーム送信停止期間に渡って音声１のストリーム送信を停止する為、図１１，図１４のように音声受信バッファ５４の蓄積量が最小値まで減少する。

（ｂ）ステップＳ５０２では、領域検出手段４１が図１８のように入力ポインタが音声２の指定領域の外に移動しているか否かを検出する。指定領域の外に移動した場合ステップＳ５０８へ進み、指定領域の外に移動していない場合ステップＳ５０３へ進む。

（ｃ）ステップＳ５０３では、入力ポインタが音声２の指定領域内にある際に、音声２のボタンが入力手段３１０より入力され、音声の切り替えが確定したことを選択検出手段４２が検出する。音声の切り替えの確定が検出されなかった場合はＳ５０２に戻る。以降、Ｓ５０２とＳ５０３を遷移して確定が決定するまで繰り返す。

ステップＳ５０４でサーバに送信するストリームの切り替え要求に付加するために現在の音声受信バッファ５４の蓄積量を取得する。ステップＳ５０５では先に取得した音声バッファの蓄積量をストリームの切り替え要求に付加して制御コマンドを生成してサーバに送信する。このコマンドを受けてサーバから送られてくる音声ストリームは音声１から音声２に切り替わる。音声２に切り替わった後は一定期間に渡って音声２のストリームが高いレートで送信されてくるのでＳ５０７において減少した音声のバッファが通常の蓄積量に復帰する。

（ｄ）ステップＳ５０８では、指定領域の中に位置した入力ポインタがストリーム切り替えの確定選択をすることなく指定領域の外に移動した場合、配信システムの安定性を確保するために、切り替え準備判定手段４３は、音声受信バッファ５４を最大値に復帰する制御を行なう。先ず、制御コマンド生成手段４６に切り替え準備の終了を伝達し、バッファ蓄積量検出手段５７が現在の音声受信バッファ５４のバッファ蓄積量を検出する。ステップＳ５０９において、制御コマンド生成手段４６が、切り替え準備の終了を伝える情報にバッファ蓄積量を付加した制御コマンドを生成する。この制御コマンドは図１９に示すように、切り替え準備の終了を「a=mode:preset_end」で指定し、バッファ蓄積量をバイト単位で「a=buffer:8000」と指定する。これはバッファ蓄積量が８Ｋバイトの例である。制御コマンド送信手段４７はこの制御コマンドをストリーミングサーバ４００に送信する。

（ｅ）ステップＳ５１０においては、音声ストリーム受信手段５２がストリーミングサーバ４００より通常より高いレートで音声１のデータを受信し、音声受信バッファ５４の蓄積量は図１４の最大値ｔ４に復帰する。

本提案のストリーム切り替え配信システムはインターネットを使った映像や音声をストリーミングで配信するコンテンツ配信システムやサービスに適用可能である。特に、ユーザの切り替え操作で動的に音声や映像のストリーム切り替えて再生するインタラクティブ性の高いコンテンツの配信システムやサービスに利用することができる。

本発明の実施の形態に係るストリーミング切り替え配信システムの全体構成図である。 本発明の実施の形態に係るストリーミングサーバの内部構成を示す構成図である。 クライアント端末のストリーム切り替え入力画面図である。 本発明の実施の形態に係るクライアント端末の内部構成を示す構成図である。 ストリーム切り替え要求コマンドの一例を示す図である。 本発明の実施の形態に係るストリーミング切り替え配信システムの動作を示すシーケンス図である。 選択確定の際の入力画面を示す画面図である。 指定領域の画面を示す画面図である。 ストリーム切り替え準備の開始を伝える制御コマンドの一例を示す図である。 本発明の実施の形態に係るストリーミングサーバの動作を示すフローチャートである。 ストリーム切り替えを実施した時の受信バッファの推移を示す図である。 パケットのデータ構成を示す図である。 切り替えが確定した時のパケット送信のタイミングを示す図である。 ストリーム切り替えが発生しなかった場合のクライアント端末の受信バッファの推移を示す図である。 ストリーム送信停止期間の算出ステップを示すフローチャートである。 クライアント端末の受信バッファの蓄積量を最大値に復帰するための配信サーバの送信制御の処理フローである。 本発明の実施の形態に係るクライアント端末の動作を示すフローチャートである。 指定領域の外に入力ポインタが退避した場合を示す図である。 ストリーム切り替え準備の終了を伝える制御コマンドである。

符号の説明

２１…音声２バッファ
２２…音声１バッファ
２３…切り替え手段
２４…音声パケット生成手段
２５…音声ストリーム送信手段
２６…映像バッファ
２７…映像パケット生成手段
２８…映像ストリーム送信手段
２９…制御コマンド受信手段
３０…制御コマンド解析手段
３１…ストリーム送信管理手段
３１ａ…送信停止期間算出手段
３１ｂ…送信レート算出手段
４１…領域検出手段
４２…選択検出手段
４３…準備判定手段
４４…判定手段
４５…再生管理手段
４６…制御コマンド生成手段
４７…制御コマンド送信手段
５１…映像ストリーム受信手段
５２…音声ストリーム受信手段
５３…映像受信バッファ
５４…音声受信バッファ
５５…映像デコーダ
５６…音声デコーダ
５７…バッファ蓄積量検出手段
１００…ストリーム切り替え配信システム
２００…アプリケーションサーバ
２１０…コンテンツリスト提示手段
２２０…コンテンツ属性提示手段
３００…クライアント端末
３１０…入力手段
３２０…コンテンツ属性解析手段
３３０…コンテンツ選択手段
３４０…ストリーム切り替え再生手段
３５０…再生手段
４００…ストリーミングサーバ
４１０…ストリーム切り替え送信手段
４２０…ストリーミング記憶装置
５００…ストリーミング配信サーバ
６００…インターネット

Claims (6)

1. ストリーミングサーバより配信されるストリームを再生するクライアント端末であって、
   ストリーム選択画面上の入力ポインタがストリーム選択決定の入力手段近辺の指定領域内に位置することを検出してストリーム切り替え準備の開始を判定する切り替え準備判定手段と、
   前記ストリームを格納する受信バッファ内のバッファ蓄積量を検出するバッファ蓄積量検出手段と、
   前記切り替え準備判定手段によってストリームの切り替え準備の開始が判定された場合、前記バッファ蓄積量検出手段で検出した前記バッファ蓄積量に関する情報をストリーム切り替え準備の開始を伝える情報に付加して制御コマンドを生成する制御コマンド生成手段とを備え、
   前記制御コマンドを前記ストリーミングサーバ側へ送信する
   ことを特徴とするクライアント端末。
2. 前記切り替え準備判定手段は、前記入力ポインタが前記指定領域外に退避したことを検出してストリーム切り替え準備の終了を判断し、
   前記制御コマンド生成手段は、
   前記切り替え準備判定手段により前記ストリームの切り替え準備の終了が判定された場合には前記バッファ蓄積量に関する情報をストリーム切り替え準備の終了を伝える情報に付加し、
   前記ストリーム選択決定の入力手段によりストリームの切り替えが確定した場合には前記バッファ蓄積量に関する情報をストリーム切り替え要求する情報に付加する
   ことを特徴とする請求項１に記載のクライアント端末。
3. ストリームを再生するクライアント端末に対し前記ストリームを配信するストリーミングサーバであって、
   前記クライアント端末よりストリーム切り替え準備の開始情報を受信すると、前記クライアント端末への前記ストリームの送信を停止する送信停止期間を算出し、前記送信停止期間はストリームの送信停止を行うストリーム送信管理手段を備えることを特徴とするストリーミングサーバ。
4. 前記ストリーム送信管理手段は、前記クライアント端末より受信するストリーム切り替え要求に基づいて、前記クライアント端末の受信バッファを所望の蓄積量に復帰させるに必要な前記ストリームを配信する際の送信レートを算出する送信レート算出手段を更に備えることを特徴とする請求項３に記載のストリーミングサーバ。
5. ストリームを配信するストリーミングサーバと、前記ストリームを受信して再生するクライアント端末を含むストリーミング切り替え配信システムであって、
   ストリーム選択画面上の入力ポインタがストリーム選択決定の入力手段近辺の指定領域内に位置することを検出してストリーム切り替え準備の開始を判定する切り替え準備判定手段、前記ストリームを格納する受信バッファ内のバッファ蓄積量を検出するバッファ蓄積量検出手段及び前記切り替え準備判定手段によってストリームの切り替え準備の開始が判定された場合、前記バッファ蓄積量検出手段で検出した前記バッファ蓄積量に関する情報をストリーム切り替え準備の開始を伝える情報に付加して制御コマンドを生成する制御コマンド生成手段とを備え、前記制御コマンドを前記ストリーミングサーバ側へ送信するクライアント端末と、
   前記クライアント端末よりストリーム切り替え準備の開始情報を受信すると、前記クライアント端末への前記ストリームの送信を停止する送信停止期間を算出し、前記送信停止期間はストリームの送信停止を行うストリーム送信管理手段を備えるストリーミングサーバ
   とを備えることを特徴とするストリーム切り替え配信システム。
6. 前記切り替え準備判定手段は、前記入力ポインタが前記指定領域外に退避したことを検出してストリーム切り替え準備の終了を判断し、
   前記制御コマンド生成手段は、前記切り替え準備判定手段により前記ストリームの切り替え準備の終了が判定された場合には前記バッファ蓄積量を前記ストリーミングサーバに送信するためのストリーム切り替え準備の終了を伝える情報に付加し、前記ストリーム選択決定の入力手段によりストリームの切り替えが確定した場合には前記バッファ蓄積量に関する情報をストリーム切り替え要求する情報に付加し、
   前記ストリーム送信管理手段は、前記クライアント端末より受信するストリーム切り替え要求に基づいて、前記クライアント端末の受信バッファを所望の蓄積量に復帰させるに必要な前記ストリームを配信する際の送信レートを算出する
   ことを更に備えることを特徴とする請求項５に記載のストリーム切り替え配信システム。
   
   

Images