(57)【要約】【課題】  ストリーミング配信システムにおけるユーザの切り替え指示の際にストリームの切り替え時間遅れをできるだけ少なくして映像や音声を切り替えて表示することが可能なストリーミングの切り替えを実現するクライアント端末、ストリーミングサーバ、ストリーミング切り替えシステム及びストリーミング切り替え方法を提供する。【解決手段】  ストリーミング切り替えシステム１００は、ストリーミングサーバ４００及びクライアント端末３００等より構成され、ストリーミングサーバ４００は、緊急送信識別付加手段２３、映像切り替え手段２４、音声切り替え手段２５、ストリーム切り替え要求受信手段３２、送信管理手段３３、パケット未処理期間検出手段３４等を備え、クライアント端末３００は、入力手段３１０、コンテンツ属性解析手段３２０、切り替え選択判定手段３３０、ストリーム切り替え再生手段３４０、再生手段３５０等を備えている。【選択図】      図１
2005328268.tif 000002
【特許請求の範囲】
【請求項１】
再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、前記再生中のストリームの現在の再生時刻を検出する再生時刻検出手段と、
前記ストリーム切り替え要求に前記検出した再生時刻を付加し、前記再生中のストリームの配信元に送信するストリーム切り替え要求送信手段と、
前記配信元より受信するパケットから緊急送信識別を検出する緊急送信識別検出手段と、
前記緊急送信識別を有するパケットを抽出して格納する緊急バッファ手段と、
前記配信元より先行して受信したパケットに優先して緊急バッファ手段内の前記緊急送信識別を有するパケットを再生する再生手段
とを備えることを特徴とするクライアント端末。
【請求項２】
ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される前記再生中のストリームの現在の再生時刻を基に、前記要求元にパケット送信済みで且つ前記要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段と、
前記未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段と、
前記緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで前記要求元に送信するストリーム送信手段
とを備えることを特徴とするストリーミングサーバ。
【請求項３】
ストリーミング配信されるコンテンツを保持するストリーミングサーバと、前記コンテンツをストリーミング再生するクライアント端末とを有するストリーミング切り替えシステムであって、
再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、前記再生中のストリームの現在の再生時刻を検出する再生時刻検出手段と、
前記ストリーム切り替え要求に前記検出した再生時刻を付加し、前記ストリーミングサーバに送信するストリーム切り替え要求送信手段と、
ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される前記再生中のストリームの現在の再生時刻を基に、前記要求元にパケット送信済みで且つ前記要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段と、
前記未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段と、
前記緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで前記クライアント端末に送信するストリーム送信手段と、
前記ストリーミングサーバより受信するパケットから前記緊急送信識別を検出する緊急送信識別検出手段と、
前記緊急送信識別を有するパケットを抽出して格納する緊急バッファ手段と、
前記ストリーミングサーバより先行して受信したパケットに優先して前記緊急バッファ手段内の前記緊急送信識別を有するパケットを再生する再生手段
とを備えることを特徴とするストリーミング切り替えシステム。
【請求項４】
ストリーミング配信されるコンテンツを保持するストリーミングサーバと、前記コンテンツをストリーミング再生するクライアント端末とを有するストリーミング切り替えシステムであって、
再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、前記再生中のストリームの現在の再生時刻を検出する再生時刻検出手段と、
前記ストリーム切り替え要求に前記検出した再生時刻を付加し、前記ストリーミングサーバに送信するストリーム切り替え要求送信手段と、
ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される前記再生中のストリームの現在の再生時刻を基に、前記要求元にパケット送信済みで且つ前記要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段と、
前記未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段と、
前記緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで前記クライアント端末に送信するストリーム送信手段と、
前記ストリーミングサーバより受信するパケットから前記緊急送信識別を検出する緊急送信識別検出手段と、
前記緊急送信識別を有するパケットを抽出し、前記配信元より先行して受信されたパケットの上に上書きする緊急パケット上書き手段と、
前記上書きされた前記緊急送信識別を有するパケットを再生する再生手段
とを備えることを特徴とするストリーミング切り替えシステム。
【請求項５】
ストリーミングサーバより配信されるコンテンツをクライアント端末がストリーミング再生する際に、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、前記再生中のストリームの現在の再生時刻を検出するステップと、
前記ストリーム切り替え要求に前記検出した再生時刻を付加し、前記ストリーミングサーバに送信するステップと、
ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される前記再生中のストリームの現在の再生時刻を基に、前記要求元にパケット送信済みで且つ前記要求元にて未だストリーム再生されていない未処理期間を検出するステップと、
前記未処理期間に相当するストリームに緊急送信識別を付加するステップと、
前記緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで前記クライアント端末に送信するステップと、
前記ストリーミングサーバより受信するパケットから前記緊急送信識別を検出するステップと、
前記緊急送信識別を有するパケットを抽出して緊急バッファに格納するステップと、
前記ストリーミングサーバより先行して受信したパケットに優先して前記緊急バッファ内の前記緊急送信識別を有するパケットを再生するステップ
とを備えることを特徴とするストリーミング切り替え方法。
【請求項６】
ストリーミングサーバより配信されるコンテンツをクライアント端末がストリーミング再生する際に、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、前記再生中のストリームの現在の再生時刻を検出するステップと、
前記ストリーム切り替え要求に前記検出した再生時刻を付加し、前記ストリーミングサーバに送信するステップと、
ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される前記再生中のストリームの現在の再生時刻を基に、前記要求元にパケット送信済みで且つ前記要求元にて未だストリーム再生されていない未処理期間を検出するステップと、
前記未処理期間に相当するストリームに緊急送信識別を付加するステップと、
前記緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで前記クライアント端末に送信するステップと、
前記ストリーミングサーバより受信するパケットから前記緊急送信識別を検出するステップと、
前記緊急送信識別を有するパケットを抽出し、前記配信元より先行して受信されたパケットの上に上書きするステップと、
前記上書きされた前記緊急送信識別を有するパケットを再生するステップ
とを備えることを特徴とするストリーミング切り替え方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットを介して映像や音声のデジタルコンテンツをストリーミング配信する技術に関し、特に映像や音声のストリームをユーザの要求に応じて動的に切り替えてシームレスに再生を行うクライアント端末、ストリーミングサーバ、ストリーミング切り替えシステム及びストリーミング切り替え方法に関する。
【背景技術】
【０００２】
インターネットを経由して圧縮された映像や音声のデジタルコンテンツをストリーム配信するシステムにおいて、ストリーム配信サーバとストリームを受信するクライアント端末間のネットワーク環境が不安定な為、ストリーミングのパケット遅延やパケット再送などの現象が発生することがある。コンテンツを視聴しているユーザにとってこの現象は映像や音声の途切れとなって現れる。そこでこの現象を少なくするためにクライアント端末において受信したストリームを２秒〜５秒程度の時間に相当するバッファリングを行い、バッファリングされた最も古いパケットから順に映像と音声のデコードを行って表示する手法が存在する。
【０００３】
更に、このようなバッファリング方式を用いてストリーミングを行っている最中にユーザが見たいアングルや聞きたい音声チャンネルの切り替えが可能なサービスを提供するストリーミング配信システムも存在する（特許文献１参照。）。
【特許文献１】特開２００２−１１８５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、ストリーミングを行っている最中に、ユーザの見たいアングルや聞きたい音声チャンネルの切り替えが可能なサービスを提供する場合、従来のストリーミング配信システムでは、ユーザからストリームの切り替え指示を受けストリーミングサーバ側で直ちに現在送信しているストリームから送信要求のあったストリームへ送信内容を切り替えても、これを受信したクライアント端末では数秒のバッファリングを行っているのでユーザが切り替え指示を出してから実際にデコードされて表示される映像や音声が切り替わるのは、バッファリングに相当する２秒〜５秒後となっていた。つまり、切り替えが実施されるまでに数秒から数十秒時間待たなければならず、実際に見たいシーンを見逃したりするという問題があった。
【０００５】
本発明は上記の問題点に鑑みてなされたものであり、ストリーミング配信システムにおけるユーザの切り替え指示の際にストリームの切り替え時間遅れをできるだけ少なくして映像や音声を切り替えて表示することが可能なストリーミングの切り替えを実現するクライアント端末、ストリーミングサーバ、ストリーミング切り替えシステム及びストリーミング切り替え方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した従来の技術の課題を解決するため、本発明の第１の特徴は、[イ]再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、再生中のストリームの現在の再生時刻を検出する再生時刻検出手段（５１）と、[ロ]ストリーム切り替え要求に検出した再生時刻を付加し、再生中のストリームの配信元に送信するストリーム切り替え要求送信手段（５３）と、[ハ]配信元より受信するパケットから緊急送信識別を検出する緊急送信識別検出手段（４３）と、[ニ]緊急送信識別を有するパケットを抽出して格納する緊急バッファ手段（４５）と、[ホ]配信元より先行して受信したパケットに優先して緊急バッファ手段（４５）内の緊急送信識別を有するパケットを再生する再生手段（３５０）とを備えるクライアント端末であることを要旨とする。
【０００７】
本発明の第２の特徴は、[イ]ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される再生中のストリームの現在の再生時刻を基に、要求元にパケット送信済みで且つ要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段（４１０）と、[ロ]未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段（２３）と、[ハ]緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートで要求元に送信するストリーム送信手段（２７）とを備えるストリーミングサーバであることを要旨とする。
【０００８】
本発明の第３の特徴は、[イ]ストリーミング配信されるコンテンツを保持するストリーミングサーバと、コンテンツをストリーミング再生するクライアント端末とを有するストリーミング切り替えシステムであって、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、再生中のストリームの現在の再生時刻を検出する再生時刻検出手段（５１）と、[ロ]ストリーム切り替え要求に検出した再生時刻を付加し、ストリーミングサーバに送信するストリーム切り替え要求送信手段（５３）と、[ハ]ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される再生中のストリームの現在の再生時刻を基に、要求元にパケット送信済みで且つ要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段（４１０）と、[ニ]未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段（２３）と、[ホ]緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートでクライアント端末に送信するストリーム送信手段（２７）と、[ヘ]ストリーミングサーバより受信するパケットから緊急送信識別を検出する緊急送信識別検出手段（４３）と、[ト]緊急送信識別を有するパケットを抽出して格納する緊急バッファ手段（４５）と、[チ]ストリーミングサーバより先行して受信したパケットに優先して緊急バッファ手段（４５）内の緊急送信識別を有するパケットを再生する再生手段（３５０）とを備えるストリーミング切り替えシステムであることを要旨とする。
【０００９】
本発明の第４の特徴は、[イ]ストリーミング配信されるコンテンツを保持するストリーミングサーバと、コンテンツをストリーミング再生するクライアント端末とを有するストリーミング切り替えシステムであって、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、再生中のストリームの現在の再生時刻を検出する再生時刻検出手段（５１）と、[ロ]ストリーム切り替え要求に検出した再生時刻を付加し、ストリーミングサーバに送信するストリーム切り替え要求送信手段（５３）と、[ハ]ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される再生中のストリームの現在の再生時刻を基に、要求元にパケット送信済みで且つ要求元にて未だストリーム再生されていない未処理期間を検出するパケット未処理期間検出手段（４１０）と、[ニ]未処理期間に相当するストリームに緊急送信識別を付加する緊急送信識別付加手段（２３）と、[ホ]緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートでクライアント端末に送信するストリーム送信手段（２７）と、[ヘ]ストリーミングサーバより受信するパケットから緊急送信識別を検出する緊急送信識別検出手段（４３）と、[ト]緊急送信識別を有するパケットを抽出し、配信元より先行して受信されたパケットの上に上書きする緊急パケット上書き手段（４５ａ）と、[チ]上書きされた緊急送信識別を有するパケットを再生する再生手段（３５０）とを備えるストリーミング切り替えシステムであることを要旨とする。
【００１０】
本発明の第５の特徴は、［イ］ストリーミングサーバより配信されるコンテンツをクライアント端末がストリーミング再生する際に、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、再生中のストリームの現在の再生時刻を検出するステップと、［ロ］ストリーム切り替え要求に検出した再生時刻を付加し、ストリーミングサーバに送信するステップと、［ハ］ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される再生中のストリームの現在の再生時刻を基に、要求元にパケット送信済みで且つ要求元にて未だストリーム再生されていない未処理期間を検出するステップと、［ニ］未処理期間に相当するストリームに緊急送信識別を付加するステップと、［ホ］緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートでクライアント端末に送信するステップと、［ヘ］ストリーミングサーバより受信するパケットから緊急送信識別を検出するステップと、［ト］緊急送信識別を有するパケットを抽出して緊急バッファ（４５）に格納するステップと、［チ］ストリーミングサーバより先行して受信したパケットに優先して緊急バッファ（４５）内の緊急送信識別を有するパケットを再生するステップとを備えるストリーミング切り替え方法であることを要旨とする。
【００１１】
本発明の第６の特徴は、［イ］ストリーミングサーバより配信されるコンテンツをクライアント端末がストリーミング再生する際に、再生中のストリームを切り替える為のストリーム切り替え要求が発生すると、再生中のストリームの現在の再生時刻を検出するステップと、［ロ］ストリーム切り替え要求に検出した再生時刻を付加し、ストリーミングサーバに送信するステップと、［ハ］ストリーム配信の要求元より受信する再生中ストリームを切り替えるストリーム切り替え要求に付加される再生中のストリームの現在の再生時刻を基に、要求元にパケット送信済みで且つ要求元にて未だストリーム再生されていない未処理期間を検出するステップと、［ニ］未処理期間に相当するストリームに緊急送信識別を付加するステップと、［ホ］緊急送信識別が付加されたパケットを通常の配信レートと比して高いレートでクライアント端末に送信するステップと、［ヘ］ストリーミングサーバより受信するパケットから緊急送信識別を検出するステップと、［ト］緊急送信識別を有するパケットを抽出し、配信元より先行して受信されたパケットの上に上書きするステップと、［チ］上書きされた緊急送信識別を有するパケットを再生するステップとを備えるストリーミング切り替え方法であることを要旨とする。
【発明の効果】
【００１２】
本発明のクライアント端末、ストリーミングサーバ、ストリーミング切り替えシステム及びストリーミング切り替え方法によると、ストリーミング配信において、ユーザの切り替え指示を受けた際、映像や音声のストリーム切り替えの時間遅れの少ないシームレス切り替えが可能となる。この為、インタラクティブ性の高いコンテンツのストリーミング配信サービスを実現できる。又、通信帯域を増やすことなく、ストリーム切り替えの時間遅れの少ない多チャンネルのシームレス切り替えが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態に係るクライアント端末、ストリーミングサーバ、ストリーミング切り替えシステム及びストリーミング切り替え方法について説明する。尚、本発明の実施の形態において使用される機器及び手法等は、一例であり、本発明はこれらに限定されるものでないことは勿論である。
【００１４】
伝送方式について説明すると、インターネットを使って映像や音声のストリームをリアルタイムに伝送するためには、ＲＴＰ（リアルタイムトランスポートプロトコル）が規定されている。低いビットレートでも劣化が少なく品質の高い画質や音質の圧縮方式であるＭＰＥＧ４（ムービングピクチャエキスパートグループフェーズ４）のストリームをＲＴＰ伝送するための規格はＩＥＴＦ（インターネットエンジニアリングタスクフォース）のＲＦＣ３０１６(ＲＴＰペイロードフォーマットfor ＭＰＥＧ４オーディオ／ビジュアルストリーム)として標準化されている。再生制御するためのコマンドセットなどはＲＦＣ２３２６で規定されている。本発明ではこれらの伝送方式を用いたストリーム配信サーバとクライアント端末の例として説明している。しかし映像や音声の圧縮方式、伝送プロトコル、再生制御のプロトコルなどこれに限定されるものではない。
【００１５】
以下の説明においては、音声ストリームの切り替えについて主に説明しているが、ストリームの切り替えは音声に限定されるものでなく、映像やその他ストリームにも適応可能である。又、以下においては、映像と音声のストリームをそれぞれ別のチャンネルとしてストリーム配信サーバとクライアント端末間で伝送する。これに加え再生制御コマンドの送受信も映像や音声のチャンネルと独立したチャンネルとして伝送する。
【００１６】
（ストリーム切り替えシステム）
本発明の第１の実施の形態に係るストリーム切り替えシステム１００は、図１に示すように、ストリーミング配信サーバ５００と、ストリーミング映像の配信を要求して、取得したストリーミング映像を再生するクライアント端末３００等より構成され、各々の装置はインターネット６００を介して通信可能となっている。
【００１７】
ストリーミング配信サーバ５００は、ユーザの認証やコンテンツのリストを提示するアプリケーションサーバ２００及びクライアントの要求により映像や音声のストリーミングを行うストリーミングサーバ４００を備える。
【００１８】
アプリケーションサーバ２００は、コンテンツ属性提示手段２１０及びコンテンツ提示手段２２０等を備えている。コンテンツ属性提示手段２１０は、クライアント端末３００へ提供するコンテンツリストが複数のストリーム属性を提示するようコンテンツ属性を付加する。コンテンツ提示手段２２０は、ストリーミングで提供可能なコンテンツのタイムテーブルや視聴価格などのリストを動的に生成されたＨＴＭＬ（ハイパーテキストマークアップランゲッジ）ページとしてユーザに提示する。この他、アプリケーションサーバ２００は、会員登録、ユーザ識別、課金処理などのアクセス制御を行う。
【００１９】
ストリーミングサーバ４００は、ストリーム切り替え送信手段４１０及びストリーミング記憶装置４２０を備えている。ストリーム切り替え送信手段４１０は再生中のストリームを切り替えるための要求をクライアント端末３００から受信し、送信するストリームを切り替えてクライアント端末３００に送信するための手段であり、図２に示すように、映像パケット生成手段２１、音声パケット生成手段２２、緊急送信識別付加手段２３、映像切り替え手段２４、音声切り替え手段２５、映像ストリーム送信手段２６、音声ストリーム送信手段２７、再生制御コマンド受信手段３１、ストリーム切り替え要求受信手段３２、送信管理手段３３、パケット未処理期間検出手段３４等を備えている。
【００２０】
映像パケット生成手段２１は、ストリーミング記憶装置４２０内の映像データより映像パケットを生成する。音声パケット生成手段２２は、ストリーミング記憶装置４２０内の音声データより音声パケットを生成する。緊急送信識別付加手段２３は、重複して送信するパケットに、判別するための緊急送信識別を示す属性を付加する。映像切り替え手段２４は、緊急送信識別が付加されたパケットを送信する際に、通常の映像パケットから緊急パケットに切り替える。音声切り替え手段２５は、緊急送信識別が付加されたパケットを送信する際に、通常の音声パケットから緊急パケットに切り替える。
【００２１】
映像ストリーム送信手段２６は、映像ストリームを、映像送信ポート２８を介して、要求元のクライアント端末３００に送信する。音声ストリーム送信手段２７は、音声ストリームを、音声送信ポート２９を介して、要求元のクライアント端末３００に送信する。再生制御コマンド受信手段３１は、制御ポート３０を介して、クライアント端末３００より映像ストリーム又は音声ストリームの再生を制御するコマンドを受信する。
【００２２】
ストリーム切り替え要求受信手段３２は、クライアント端末３００からのストリーム切り替え要求を受信する。送信管理手段３３は、クライアント端末３００からストリーム切り替え要求メッセージを受信すると、クライアント端末３００へ送信を行った最後の音声ストリームの再生位置を確認しそのタイムスタンプを取得する。パケット未処理期間検出手段３４は、パケット送信済みでかつクライアント端末３００で未だ再生されていない期間を検出する。
【００２３】
クライアント端末３００は、アプリケーションサーバ２００から受信するコンテンツリストから視聴するストリームを選択し、ストリーミングサーバ４００に再生ストリームの送信指示を出し、受信したストリームを再生する。クライアント端末３００は、入力手段３１０、コンテンツ属性解析手段３２０、切り替え選択判定手段３３０、ストリーム切り替え再生手段３４０、再生手段３５０、映像音声表示手段３６０等を備えている。
【００２４】
入力手段３１０は、ユーザによるストリーム切り替えをナビゲーションするためにＧＵＩ画面に表示されるストリームの説明と共に、ストリームを切り替えるための選択ボタン等である。この入力はキーボード、マウス等により行なわれる。ストリーム切り替えナビゲーション画面の例を図３に示す。本発明の第１の実施の形態の場合は２種類の音声Ａと音声Ｂを切り替えを行う例を示しているので音声Ａと音声Ｂの２つのボタンが入力手段３１０としてＧＵＩに配置されている。ユーザがマウスで音声Ａあるいは音声Ｂのボタンをクリックすることでストリームの切り替えメッセージが発生する。なお第１の実施の形態では、音声が３つ以上のストリームから選択的なストリーム切り替えが可能であり、また音声に限らず映像でも切り替えが可能である。
【００２５】
切り替え選択判定手段３３０は、入力手段３１０より切り替えメッセージを受信すると、現在再生中の音声若しくは現在未再生の音声のどちらが選択されたかを判断し、現在再生中でない音声が選択された場合はストリーム切り替え再生手段３４０にこれを伝達する。
【００２６】
ストリーム切り替え再生手段３４０は、再生制御メッセージを用いてストリーミングサーバにストリーミング切り替え要求を送信する手段であり、図４に示すように、映像ストリーム受信手段４１、音声ストリーム受信手段４２、緊急送信識別検出手段４３、映像受信バッファ４４、緊急バッファ４５、音声受信バッファ４６、映像切り替え手段４７、音声切り替え手段４８、映像デコーダ４９、音声デコーダ５０、再生時刻検出手段５１、再生管理手段５２、ストリーム切り替え要求送信手段５３、再生制御コマンド手段５４等を備えている。
【００２７】
映像ストリーム受信手段４１は、ストリーミングサーバ４００より送られてくる映像ストリームを映像受信ポート５５を介して受信する。音声ストリーム受信手段４２は、ストリーミングサーバ４００より送られてくる音声ストリームを音声受信ポート５６を介して受信する。緊急送信識別検出手段４３は、音声ストリームに付加されている緊急送信識別を検出する。
【００２８】
映像受信バッファ４４は、受信した映像ストリームを記憶する。緊急バッファ４５は、緊急送信識別が付加されているパケットを抽出して記憶する。音声受信バッファ４６は、受信した音声ストリームを記憶する。映像切り替え手段４７は、現在再生中の映像を切り替え要求のあった映像に切り替える。音声切り替え手段４８は、現在再生中の映像を切り替え要求のあった音声に切り替える。
【００２９】
映像デコーダ４９は、MPEG4方式で圧縮された映像のデコードを行う。音声デコーダ５０は、MPEG4方式で圧縮された音声のデコードを行う。再生時刻検出手段５１は、ストリーム切り替え要求のあったメディアの現在の再生時刻を検出する。再生管理手段５２は、ストリーム再生の管理を行い、入力手段３１０等より入力されたユーザの再生に関する要求を管理する。
【００３０】
ストリーム切り替え要求送信手段５３は、制御ポート５７を介して、ストリーミングサーバ４００に対しストリームの切り替え要求を送信する。再生制御コマンド手段５４は、制御ポート５７を介して、ストリーミングサーバ４００に対し映像ストリーム又は音声ストリームの再生を制御するコマンドを送信する。
【００３１】
切り替え選択判定手段３３０は、コンテンツ属性解析手段３２０のコンテンツ属性解析結果に従い、映像ストリーム又は音声ストリームの切り替えを行なう。
【００３２】
コンテンツ属性解析手段３２０は、アプリケーションサーバ２００から提供されるコンテンツリストに示されている複数のストリーム属性を解析し、コンテンツが複数の映像アングルや複数の音声チャンネルをインタラクティブに切り替え可能であることを判定する。
【００３３】
再生手段３５０は、映像ストリームや音声ストリームの再生処理を行う。
【００３４】
映像音声表示手段３６０は、映像ストリームや音声ストリームの再生状況をＧＵＩ画面として表示する。
【００３５】
切り替え要求メッセージの一例を図５に示す。ストリーミングの再生制御メッセージはＲＦＣ２３２６で標準化されているＲＴＳＰ（リアルタイムストリーミングプロトコル）に従って例示している。切り替えて再生を行うストリームのメディア識別情報はＡＮＮＯＵＮＣＥコマンドによってクライアント端末３００からストリーミングサーバ４００に送信される。ＡＮＮＯＵＮＣＥコマンドのセッション記述ブロックの具体例を説明する。まず切り替えて再生を行うストリームのメディア識別は音声の場合m=audio、映像の場合m=videoで指定する。メディア識別を指定する最後のフィールドにはPayload-Typeを指定する。図５では音声のPayload-Typeを９６として例示している。同時に音声のどのトラックを切り替えて再生するかを識別するためにメディアＵＲＬを指定する。図５ではa=controlの後にメディアＵＲＬを指定する。また切り替え対象となる音声Ａストリームの現在再生時刻をサーバに伝えるために、クライアント端末３００の現在時刻をタイムスタンプ形式でa=rtptimeフィールドで指定する。切り替え要求メッセージをＲＴＳＰプロトコルで説明したが、ＨＴＴＰプロトコルを用いてセッション記述によってクライアント端末３００からストリーミングサーバに伝達することも可能である。ＨＴＴＰプロトコルによって切り替え要求メッセージを送信する場合は再生制御のＲＴＳＰプロトコル用とは別にＨＴＴＰプロトコル用のポートおよびメッセージの送受信手段がサーバおよびクライアント端末３００に必要である。なおストリーム切り替え要求のプロトコルは上記の例に限定されることはなく、様々なネットワークプロトコルを用いて行なわれて構わない。
【００３６】
（ストリーム切り替え方法）
次にストリーム切り替えシステム１００の全体動作について図６のシーケンス図を用いて説明する。
【００３７】
（ａ）ステップＳ１０１において、先ずクライアント端末３００は、ストリーミング配信サーバ５００のアプリケーションサーバ２００が提供するコンテンツページへ、インターネット６００を介して、アクセスする。図１のコンテンツ提示手段２２０はこのアクセスに対し、提供可能なコンテンツを提示する。ステップＳ１０２において、クライアント端末３００は、提示されたコンテンツ内より、再生するコンテンツを指定して再生指示を出す。
【００３８】
（ｂ）ステップＳ１０３において、ストリーミングサーバ４００のストリーム切り替え送信手段４１０は、要求元のクライアント端末３００に対し指定されたコンテンツのストリーミング配信を開始する。ストリーミングの送信開始時点において映像ストリームと、クライアントから明示的に音声のストリーム切り替え要求が無い場合の既定値である音声Aストリームが配信される。
【００３９】
（ｃ）ステップＳ１０４において、音声Ａを別の音声Ｂに切り替えたいとの要求が図１のクライアント端末３００の入力手段３１０を介して行なわれると、ストリーム切り替え再生手段３４０は、このストリーム切り替え要求をストリーミングサーバ４００に送信する。尚、ストリーム切り替え要求には現在再生時刻やトラックＩＤが付加される。このストリーム切り替え要求を図２のストリーム切り替え要求受信手段３２が受信する。この受信後、ストリーム切り替え送信手段４１０が、新たな音声Ｂを、緊急送信識別を有する緊急ストリームとして可能な限り高い配信レートでクライアント端末３００に送信する。
【００４０】
（ｄ）ステップＳ１０６においては、切り替え要求に従ったストリームがクライアント端末３００に送られてくるとこれをストリーム切り替え再生手段３４０が受信する。図４の緊急送信識別検出手段４３がこのストリームに緊急送信識別が付加されているかを検出し、緊急送信識別が付加されている場合、音声切り替え手段４８により所定のストリームの切り替えを行い、図２の映像デコーダ４９及び音声デコーダ５０により映像と音声のデコードが行われる。デコードされた結果は図１の映像音声表示手段３６０に送られる。又、再生手段３５０が、映像及び音声ストリームの再生を行う。
【００４１】
（ｄ）ステップＳ１０７においては、クライアント端末３００よりストリーム再生の停止コマンドが入力手段３１０を介して入力されると、ストリーミング配信サーバ５００はストリーム配信を停止する。
【００４２】
次に、ステップＳ１０５のストリーム切り替えの際のストリーミング配信サーバ５００の動作について、図７のフローチャートを参照して詳細に説明する。
【００４３】
（ａ）ステップＳ２０１において、図２のストリーミングサーバ４００のストリーム切り替え受信手段３２が、映像及び音声Ａのストリーム配信中に、クライアント端末３００より音声Ｂへのストリーム切り替え要求を受信する。するとステップＳ２０２において、図２の送信管理手段３３はストリーミングサーバ４００がクライアント端末３００へ送信を行った最後の音声Ａストリームの再生位置を確認し、そのタイムスタンプｔ１４(図８参照)を取得する。
【００４４】
（ｂ）ステップＳ２０３においては、受信したストリーム切り替え要求メッセージにはクライアント端末３００の現在時刻がタイムスタンプ形式で記載されているので、送信管理手段３３はクライアント端末３００がこれから再生を行うべき音声Ａストリームのタイムスタンプｔ１１（図８参照）を確認する。
【００４５】
（ｃ）ステップＳ２０４においては、ストリームの切り替え要求を受けた後に音声切り替え手段２５がストリームを切り替えて、音声ストリーム送信手段２７が再生すべき音声Ｂストリームのパケットを送信する。この際、すでにクライアント端末３００の音声受信バッファにバッファリングされていると想定される音声Ａストリームのｔ１１からｔ１４のタイムスタンプに該当する音声Ｂストリームのパケットを重複して送信した後に、ｔ１５以降の音声Ｂストリームを連続して送信する。この時、重複して送信するパケットを判別するために、これらのパケットには緊急送信識別を示す属性が付加される。この緊急送信識別の付加は、先ずパケット未処理期間検出手段３４が、パケット送信済みでかつクライアント端末３００で未だ再生されていない期間を検出する。ステップＳ２０３で取得したｔ１１からステップＳ２０２で取得したｔ１４までの期間をパケット未処理期間として判断する。この検出結果を基に、緊急送信識別付加手段２３が、パケット未処理期間に相当する切り替え後のストリームに緊急送信識別を付加する。図９はストリームパケットをＵＤＰ（ユーザデータグラムプロトコル）で伝送するためのパケット構造である。圧縮された映像および音声のデータはＲＴＰペイロードに格納される。この中のストリーム属性を示すＲＴＰヘッダーの詳細なデータ構造を図１０に示す。映像および音声の時刻情報はタイムスタンプ形式で図１０のTimeStamp領域に記載される。通常、音声と映像は各々異なるクロックレートを基準としたタイムスタンプが用いられる。音声の切り替えの場合、クライアントの現在の再生時刻は音声のタイムスタンプによって表現される。
【００４６】
緊急送信識別の属性をこのＲＴＰヘッダーの拡張領域に設けることで、重複して送信されるパケットを判別することが可能となる。あるいはPayload-Typeを使って緊急送信識別パケットとして判別することもできる。例えば
音声のストリームのPayload-Type = 96
映像のストリームのPayload-Type = 97
と指定して映像と音声のストリーム再生が行われるが、これに加えて緊急送信識別パケットを判別するためのPayload-Typeを以下のようにクライアント端末３００とストリーミングサーバ４００間で事前に決めておくことで緊急送信識別パケットの判別が可能となる。
【００４７】
音声の緊急パケット識別  Payload-Type = 98
映像の緊急パケット識別  Payload-Type = 99
これらのストリーム配信サーバ５００とクライアント端末３００で送受信されるストリームの属性の取り決めはＲＴＳＰプロトコルのDESCRIBEメソッドで指定する。
【００４８】
緊急送信識別を持つパケットは図１１のタイミングでストリーミングサーバ４００からクライアント端末３００に送信される。通常の再生において音声のビットレートは映像のビットレートに比べて低いので音声のパケットは映像に比べてパケット送信率は低く設定されている。しかしストリーム切り替えを行う場合には、緊急送信識別パケットをできるだけ早く届けるために、可能な限り高い配信レートで音声Ｂストリームのｔ１１からｔ１４までの緊急送信識別パケットをクライアント端末３００に送信する。緊急送信識別パケットの送信が終わると後続の音声Ｂストリームｔ１５からは通常のレートで配信される。
【００４９】
なおストリーミング送信を行う映像、音声Ａ、音声Ｂのストリームは１つのファイルにチャンク構成を持って格納されている。データブロックの単位をチャンクと呼ぶ。各々のストリームの属性や、可変長である圧縮ビットストリームに対してストリーム切り替え要求があると即座にタイムスタンプによる時間位置に該当するファイル上の位置をポイントするためのサーチ情報などはコンテンツのオーサリング時に生成されメタ情報としてファイルの先頭に格納されている。第１の実施の形態においては、ＭＰＥＧ４-ＳＹＳＴＥＭ規格（ＩＳＯ/ＩＥＣ１４４９６）やアップル社のクイックタイムファイルフォーマット等のファイルをストリーミングサーバ４００のコンテンツファイル形式として説明する。しかしこれに限定されるものではないことは勿論である。
【００５０】
次に、ステップＳ１０５において送信されたストリームを受信し、切り替え再生するクライアント端末３００の動作について図１２のフローチャートを参照して詳細に説明する。
【００５１】
（ａ）ステップＳ３０１においては、図４のクライアント端末３００の映像ストリーム受信手段４１及び音声ストリーム受信手段４２が各々ストリームを受信する。このうち、緊急送信識別検出手段４３が、緊急送信識別が付加されたパケット、つまり図１１の緊急パケットｔ１１からｔ１４の音声Ｂストリームを検出する。これらの緊急パケットは、一秒程度の少量バッファリングにて、緊急バッファ４５に蓄積される。緊急送信識別パケットは前述したように高い配信レートでクライアント端末３００に送信されるので緊急バッファに少量のパケットが溜まった時点で再生が可能な状態となる。
【００５２】
クライアント端末３００からサーバに送信されたストリームの切り替え要求メッセージにはメッセージ送信時点のクライアント端末３００の現在時刻がタイムスタンプ形式で記載されているので、緊急バッファに蓄積された緊急送信識別パケットの先頭はこのタイムスタンプを持った音声Ｂストリームとなる。緊急バッファに蓄積される緊急パケットと通常の音声受信バッファのパケットの状態の１つの例を図１３に示す。これは切り替え要求メッセージに応答して高速に緊急パケットがクライアント端末３００に送信されて緊急バッファに蓄積された状態である。
【００５３】
（ｂ）次にステップＳ３０２においては、音声Ａから音声Ｂへストリームを切り替えるために図４の音声デコーダ５０へ送信するパケットを音声受信バッファ４６から緊急バッファ４５へ切り替える。切り替えが完了すると、ステップＳ３０３において、音声受信バッファ４６に蓄積されているｔ１１からｔ１４のタイムスタンプを持った音声Ａのパケットは廃棄される。
【００５４】
（ｃ）緊急バッファ４５のパケットがすべて再生が完了すると、ステップＳ３０４において、続けて音声受信バッファ４６に蓄積されているｔ１５以降の音声Ｂストリームのパケットを順次音声デコーダ５０に送り、再生を継続する。
【００５５】
尚、切り替え要求メッセージの送信に要する時間と、切り替え要求を受けてストリーミングサーバが実際に音声Ｂストリームを送信してこれがクライアント端末３００の緊急バッファに届くまでの時間を合わせた時間遅れが発生することがある。この時間遅れが大きい場合について図１４を用いて説明する。このような時間遅れの状態に対応するため、緊急バッファ４５のパケットの再生準備が整った時点で改めてクライアント端末３００の最新の時刻を調べてこれに該当するタイムスタンプを持つ音声Ｂストリームのパケットから順にデコーダに送ることが必要となる。図１４ではすでに時刻t１２までの再生が終了しているので、次にデコーダに送るパケットは時刻ｔ１３に該当する緊急パケットである。音声受信バッファに蓄積されている音声Ａのパケットｔ１３とｔ１４は廃棄される。また再生時刻が過ぎた緊急パケットｔ１１とｔ１２に該当するパケットも廃棄される。
【００５６】
緊急パケットは通常の音声パケットに比べて高いレートでストリーミングサーバから送信されてくるので、最初の緊急パケットを受信した時点で直ぐに音声Ａから音声Ｂへストリーム切り替えを行うと一番短い時間遅れでストリーム切り替えが実現できる。これはストリーミング配信サーバ５００とクライアント端末３００間の伝送帯域に十分な余裕がある時に有効である。しかし、ストリーミング配信サーバ５００とクライアント端末３００間の伝送帯域にあまり余裕がない場合には、ストリーム切り替え後のパケットのバッファ量が少ないまま推移する可能性がある。これを防ぐために緊急パケットをある指定した量だけ緊急バッファ４５に蓄積してから切り替えの処理を進めることでバッファ量を適切に保つことができる。ただし、最初の緊急パケットを受信してからストリーム切り替えを行うまでに、緊急パケットを蓄積するバッファ量を通常のパケット蓄積時間に比較して少なくする必要があり、これにより切り替えによる遅延を短くすることが可能である。
【００５７】
このように第１の実施の形態によると、ストリーミング配信サーバ５００のストリーム切り替え送信手段４１０およびクライアント端末３００のストリーム切り替え再生手段３４０によってストリーム切り替えの時間遅延が少ないシームレスなストリーム切り替えを実現することができる。
【００５８】
（変更例）
上記のストリーム切り替えにおいては、ＵＤＰ伝送を用いたストリーム切り替えについて説明されているが、映像と音声を同一チャンネルに多重化して伝送するＲＴＰ over ＴＣＰ伝送によっても同様の効果を得ることができる。
【００５９】
複数のＲＴＰストリームの多重化は、例えばＲＦＣ２３２６（１０．２）「エンベデッド（インターリーブド）バイナリデータ」で規定されている。この規格ではＲＴＰ映像や音声のＲＴＰパケットをＴＣＰ（トランスミッションコントロールプロトコル）パケットに多重化する方法が示されている。
【００６０】
多重伝送ストリームのストリーム切り替え送信を行うストリーミングサーバ４００のストリーム切り替え送信手段４１０ａの内部構成を図１５に示す。ストリーム切り替え送信手段４１０ａでは、図２のＵＤＰ伝送を用いるストリーム切り替えと比較して、映像パケット生成手段２１や音声パケット生成手段２２にて生成された映像や音声のパケットは、緊急送信識別付加手段２３で緊急送信識別が付加され、更に映像切り替え手段２４や音声切り替え手段２５で切り替えられ、映像や音声を同一のＴＣＰパケットに多重化するストリーム多重化手段３５によって多重化される。ストリーム送信手段３６はＴＣＰパケットを送信する。
【００６１】
ＴＣＰパケットの基本構成を図２２に示す。映像と音声が多重化されたパケット例を図２３に示す。緊急送信識別の属性の指定は図１０のＲＴＰヘッダー構成と同じである。
【００６２】
ＴＣＰパケットに映像や音声を多重化する時に何のＲＴＰパケットが多重化されているかを明示するために図２２に示すようにＲＴＰヘッダーの前にチャンネル識別を挿入する。ストリームの送信を開始する前にサーバからクライアントに対してストリーム毎に制御コマンドであるＳＥＴＵＰメソッドが送信されるが、このＳＥＴＵＰメソッドにストリームに対応するチャンネル識別値をクライアントに伝達しておくことでＲＴＰパケットの種別を判定できる。
【００６３】
チャンネル識別するためのＳＥＴＵＰメソッド応答の例を図２４に示す。
Transport: rtp/avp/tcp;interleaved=0-1
の最後の数字の組がチャンネル識別値である。最初の０がＲＴＰパケットのチャンネル識別である。
【００６４】
また多重伝送ストリームのストリーム切り替え再生を行うクライアント端末３００ａの内部構成を図１６に示す。クライアント端末３００ａでは、図４のクライアント端末３００の映像ストリーム受信手段４１及び音声ストリーム受信手段４２の代わりに、ストリーム受信手段５８及び多重化ストリーム抽出手段５９を使用する。ストリーム受信ポート６０はＴＣＰパケットを待ち受けるポートであり、受信したＴＣＰパケットをストリーム受信手段５８で受信してクライアントアプリケーションにデータ送信する。音声および映像のＲＴＰパケットがＴＣＰパケットとして多重化されているので多重化ストリーム抽出手段５９でこれを抽出する。抽出に際してはチャンネル識別情報を用いて音声か映像のパケットかを識別する。またＲＴＰヘッダーに付加される緊急識別の情報を用いて通常のパケットか緊急パケットかを識別する。この結果多重化ストリーム抽出手段５９から各々適切な受信バッファにパケットを選別して送ることができる。
【００６５】
さらに、１つのチャンネルで伝送される多重化された映像と音声のストリームの送信タイミングを図１７に示す。第１の実施の形態で説明したように、映像と音声の圧縮データでは、映像のビットレートの方が高いので、図１７で実際に送信される映像パケット容量は音声パケットに比べて大きくなる。このように図１７は、ストリーム切り替え要求を受けて送信される緊急送信識別の属性を付加されたパケットは通常の配信レートより高いレートで配信されることを示している。
【００６６】
この他にも、例えばＨＴＴＰに多重化することも可能である。また、この変更例では映像と音声のストリームだけを１つのＴＣＰチャンネルに多重化する例を説明しているが、ＲＦＣ２３２６に示されるように再生制御コマンドやそのコマンド応答をＲＴＰパケットと共にＴＣＰプロトコルに多重化することも可能である。
【００６７】
（第２の実施の形態）
第１の実施の形態においては、緊急パケットを緊急バッファ４５に保持していたが、緊急パケットは、緊急パケットを受信する際に、順次バッファ内に上書きしていってもよい。以下、緊急パケットをバッファに上書きするストリーム切り替えシステム１００ｂについて説明する。
【００６８】
本発明の第２の実施に係るクライアント端末３００ａのストリーム切り替え再生手段３４０ａは、図１８に示すように、映像ストリーム受信手段４１、音声ストリーム受信手段４２、緊急送信識別検出手段４３、映像受信バッファ４４、緊急パケット上書き手段４５ａ、音声受信バッファ４６、映像デコーダ４９、音声デコーダ５０、再生時刻検出手段５１、再生管理手段５２、ストリーム切り替え要求送信手段５３、再生制御コマンド手段５４等を備えている。緊急パケット上書き手段４５ａは、緊急パケットを映像受信バッファ４４若しくは音声受信バッファ４６に上書きする。以下の装置については、第１の実施の形態と同様である為説明を省略する。
【００６９】
第２の実施の形態に係るクライアント端末３００ａが送信されたストリームを受信して切り替え再生する際に、緊急パケットを上書きする動作について図１９のフローチャートを用いて説明する。
【００７０】
（ａ）先ずステップＳ４０１において、クライアント端末３００ａでは、図１８の緊急送信識別検出手段４３が、緊急送信識別の属性を持った緊急パケットを検出し、その緊急パケットのタイムスタンプを調べる。すでに音声受信バッファ４６に蓄積されている音声パケットから、緊急パケットと同一のタイムスタンプを持つパケットがあるかを判断し、同一タイムスタンプを有するパケットが音声受信バッファ４６に存在した場合には、図１６の緊急パケット上書き手段４５ａがその同一タイムスタンプを有するパケットを緊急パケットで図２０に示すように上書きする。
【００７１】
（ｂ）ステップＳ４０２において、音声受信バッファ４６内の上書きされた緊急パケットは音声デコーダ５０に送信される。音声デコーダ５０はこの緊急パケットをデコードし、ステップＳ４０３において、再生手段３５０は、映像と緊急パケットより生成される音声Ｂをストリーム再生する。
【００７２】
第１の実施の形態で説明したように、ストリーム切り替え要求をストリーミングサーバ４００に送信してから実際に緊急パケットを受信するまでの時間差が大きい場合、受信した緊急パケットのタイムスタンプに該当する切り替え前の音声Ａのパケットがすでにデコーダに送られて再生処理が終わっていることもあるが、このような場合は緊急パケットは受信バッファに上書きされることなく廃棄される。
【００７３】
緊急パケットは第１の実施の形態で説明したように、通常の音声パケットの送信レートと比べて十分に高いレートでストリーミングサーバから送信される。この結果、音声のデコード処理のレートよりも緊急パケットを受信するレートが高いので、緊急パケットで上書きされたことによる音声受信バッファのバッファ量の低下も直ぐに解消される。
【００７４】
ストリーミングサーバ４００とクライアント端末３００ａの伝送帯域の余裕があまり無い場合、ストリームを切り替えることによる一時的なバッファ量の低下が継続することも考えられる。そのため、ストリーミングサーバ４００から緊急パケットとして送信する緊急パケットの最初のパケットの時刻を遅らせることで、クライアント端末３００ａのバッファ低下を防止することができる。この例を図２１に示す。ストリーム切り替え要求に記載されたクライアント端末３００ａの現在時刻から、時刻ｔ１１に相当する音声Ｂパケットを先頭にして緊急パケットとして送信すると、時間遅れが最小となるストリーム切り替えが可能であるが、これを時間的余裕を持って、時刻ｔ１２のパケットから送信することでバッファ量の低下を起こさず、時間遅れの少ないストリーム切り替えが実現できる。
【図面の簡単な説明】
【００７５】
【図１】本発明の第１の実施の形態に係るストリーミング配信システムの全体構成図である。
【図２】本発明の第１の実施の形態に係るストリーミングサーバの内部構成を示す構成図である。
【図３】クライアント端末のストリーム切り替え入力画面図である。
【図４】本発明の第１の実施の形態に係るクライアント端末の内部構成を示す構成図である。
【図５】ストリーム切り替え要求コマンドの一例を示す図である。
【図６】本発明の第１の実施の形態に係るストリーミング配信システムの動作を示すシーケンス図である。
【図７】本発明の第１の実施の形態に係るストリーミングサーバの動作を示すフローチャートである。
【図８】切り替えするストリームの送信順序を示す図である。
【図９】本発明の第１の実施の形態におけるパケットの構成を示す図である。
【図１０】ＲＴＰヘッダー部分のデータ構成図である。
【図１１】切り替えするストリームの送信タイミングを示す図である。
【図１２】本発明の第１の実施の形態に係るクライアント端末の動作を示すフローチャートである。
【図１３】クライアント端末における受信パケットの再構成の一例を示す図である。
【図１４】クライアント端末における受信パケットの再構成の一例を示す図である。
【図１５】本発明の第１の実施の形態の変更例に係るストリーミングサーバの内部構成を示す構成図である。
【図１６】本発明の第１の実施の形態の変更例に係るクライアント端末の内部構成を示す構成図である。
【図１７】多重化されたストリームの送信タイミングを示す図である。
【図１８】本発明の第２の実施の形態に係るクライアント端末の内部構成を示す構成図である。
【図１９】本発明の第２の実施の形態に係るクライアント端末のストリーム切り替え動作を示すフローチャートである。
【図２０】本発明の第２の実施の形態に係るクライアント端末の緊急パケットの上書き処理を模式的に説明する模式図である。
【図２１】本発明の第２の実施の形態に係るクライアント端末の送信時間遅れのある緊急パケットの上書き処理を模式的に説明する模式図である。
【図２２】ＴＣＰパケットの構成を示す図である。
【図２３】映像及び音声が多重化されたパケットの構成を示す図である。
【図２４】チャンネル識別の為のＳＥＴＵＰメソッド応答のコードを示す図である。
【符号の説明】
【００７６】
２１…映像パケット生成手段
２２…音声パケット生成手段
２３…緊急送信識別付加手段
２４…映像切り替え手段
２５…音声切り替え手段
２６…映像ストリーム送信手段
２７…音声ストリーム送信手段
２８…映像送信ポート
２９…音声送信ポート
３０…制御ポート
３１…再生制御コマンド受信手段
３２…要求送信手段
３３…送信管理手段
３４…パケット未処理期間検出手段
３５…ストリーム多重化手段
３６…ストリーム送信手段
３７…ストリーム送信ポート
４１…映像ストリーム受信手段
４２…音声ストリーム受信手段
４３…緊急送信識別検出手段
４４…映像受信バッファ
４５…緊急バッファ
４５ａ…緊急パケット上書き手段
４６…音声受信バッファ
４７…映像切り替え手段
４８…音声切り替え手段
４９…映像デコーダ
５０…音声デコーダ
５１…再生時刻検出手段
５２…再生管理手段
５３…要求送信手段
５４…再生制御コマンド手段
５５…ストリーム受信手段
５５…映像受信ポート
５６…音声受信ポート
５７…制御ポート
５８…ストリーム受信手段
５９…多重化ストリーム抽出手段
６０…ストリーム受信ポート
１００，１００ｂ…ストリーム切り替えシステム
２００…アプリケーションサーバ
２１０…コンテンツ属性提示手段
２２０…コンテンツ提示手段
３００，３００ａ…クライアント端末
３１０…入力手段
３２０…コンテンツ属性解析手段
３３０…選択判定手段
３４０，３４０ａ…ストリーム切り替え再生手段
３５０…再生手段
３６０…映像音声表示手段
４００…ストリーミングサーバ
４１０，４１０ａ…ストリーム切り替え送信手段
４２０…ストリーミング記憶装置
５００…ストリーミング配信サーバ
６００…インターネット
【図１】
2005328268.tif 000003
【図２】
2005328268.tif 000004
【図３】
2005328268.tif 000005
【図４】
2005328268.tif 000006
【図５】
2005328268.tif 000007
【図６】
2005328268.tif 000008
【図７】
2005328268.tif 000009
【図８】
2005328268.tif 000010
【図９】
2005328268.tif 000011
【図１０】
2005328268.tif 000012
【図１１】
2005328268.tif 000013
【図１２】
2005328268.tif 000014
【図１３】
2005328268.tif 000015
【図１４】
2005328268.tif 000016
【図１５】
2005328268.tif 000017
【図１６】
2005328268.tif 000018
【図１７】
2005328268.tif 000019
【図１８】
2005328268.tif 000020
【図１９】
2005328268.tif 000021
【図２０】
2005328268.tif 000022
【図２１】
2005328268.tif 000023
【図２２】
2005328268.tif 000024
【図２３】
2005328268.tif 000025
【図２４】
2005328268.tif 000026