JP2006197331A - ストリーミングシステム、インタフェース変換装置、バッファリング方法 - Google Patents

Abstract

【課題】リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムにおいて、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行う。
【解決手段】ネットワークにおいて所定のデータ伝送レートになるように、そのネットワークへの送出前にストリーミングデータのバッファリングを行う。バッファリングの際は、ストリーミングデータのオーバーフロー及びアンダーフローが起きないように、映像及び音声のデータを一定時間まで待ち合わせてバッファリングを行い、データ伝送レートに見合うレートになるよう、一定のデータ量に分割して送出する。映像及び音声のデータを一定時間まで待ち合わせても一定のデータ量に達しない場合はバッファリングできただけのデータを送出する。
【選択図】 図１

Description

本発明はストリーミングシステム、インタフェース変換装置、バッファリング方法に関し、特にインターネットのストリーミング転送プロトコル“ＲＴＰ”（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）で配信される映像及び音声を、ＴＶ電話移動機端末に採用されている３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のオーディオビジュアル通信規格“３Ｇ−３２４Ｍ”を使用して、ＴＶ電話の仕組みでリアルタイムにライブストリーミング配信するシステム、これに用いるインタフェース変換装置、バッファリング方法に関する。

従来の映像ストリーミングシステムでは、映像と音声との到達遅延の揺らぎ、ＲＴＰペイロードサイズの変動を吸収する方法として映像と音声とを再生クライアント側でバッファリングしたり、クライアント側の受信状況に応じ送信側で映像レートを下げるなどのレート制御が一般的である。しかし、ライブコンテンツのストリーミングのようにリアルタイム性が重視される場合はクライアント側でバッファリングすることでリアルタイム性が損なわれる。また、クライアント側でレート制御に対応していない場合は、送信側で映像レートを下げるなどのレート制御技術の適用は困難である。

ＴＶ電話移動機端末向けに６４Ｋｂｐｓなど帯域の狭い伝送路を使ったライブコンテンツのストリーミングにおいては、エンコーダ側では一定時間おしなべて平均で６４Ｋｂｐｓとなっていても、個々の時点を見ると、ストリーミングサーバ側からのＲＴＰパケット到達の揺らぎ、ＲＴＰペイロードサイズの変動により、６４Ｋｂｐｓがコンスタントに保証されているわけではない。

ところで、中継装置にバッファを設け、別のデータを挿入することで所定のビットレートを実現する技術が知られている（例えば、特許文献１参照）。この技術を利用すれば、ビットレートを所望の値にすることができると考えられる。
特開２００３−１５８５４３号公報

一般に、ＴＶ電話移動機端末向けストリーミングでは、移動機端末向け伝送帯域は６４Ｋｂｐｓが保証されており、これに合わせ、ＲＴＰ送信側の映像と音声との到達遅延の揺らぎ、ＲＴＰペイロードサイズの変動に依存しないストリーミングデータのレート制御が必要になる。上述した特許文献１は、パケットを相互通信するための中継装置及び中継方法に関するものであり、同文献に記載されている技術を利用しても、映像と音声との到達遅延の揺らぎ、ＲＴＰペイロードサイズの変動に依存しないストリーミングデータのレート制御を実現することはできない。

本発明は上述した従来技術の問題点を解決するためになされたものであり、その目的は映像と音声の到達遅延の揺らぎ、ＲＴＰペイロードサイズの変動を吸収し、ストリーミング伝送レートを保証することのできるストリーミングシステム、インタフェース変換装置、バッファリング方法を提供することである。

本発明の請求項１によるストリーミングシステムは、リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムであって、前記ネットワークにおいて所定のデータ伝送レートになるように、該ネットワークへの送出前に前記ストリーミングデータのバッファリングを行うバッファリング手段（図１中の映像ストリーミングゲートウェイに対応）を含むことを特徴とする。このようにすれば、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行うことができる。

本発明の請求項２によるストリーミングシステムは、請求項１において、前記バッファリング手段は、ストリーミングデータのオーバーフロー及びアンダーフローが起きないように、映像及び音声のデータを一定時間まで待ち合わせてバッファリングを行い、前記データ伝送レートに見合うレートになるよう、一定のデータ量に分割して送出することを特徴とする。このようにすれば、ストリーミングデータのオーバーフロー及びアンダーフローを防止でき、映像品質の安定したストリーミングを行うことができる。

本発明の請求項３によるストリーミングシステムは、請求項２において、前記バッファリング手段は、前記映像及び音声のデータを一定時間まで待ち合わせても前記一定のデータ量に達しない場合はバッファリングできただけのデータを送出することを特徴とする。このように処理することによって、ストリーミングデータのアンダーフローを防止できる。

本発明の請求項４によるストリーミングシステムは、請求項１から３までのいずれか１項において、前記バッファリング手段から送出されるデータに、バッファリングすべき時間に相当する量のブランクデータを付加する手段を更に含むことを特徴とする。多段でバッファリングすることで所望の帯域をコンスタントに確保することがより確実となり、所定の伝送レートが条件となるＴＶ電話移動機端末上にて映像品質の安定したストリーミングを行うことができる。

本発明の請求項５によるインタフェース変換装置は、リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムに用いるインタフェース変換装置であって、前記ネットワークへの送出前に前記ストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加する手段を含むことを特徴とする。このような装置を用いれば、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行うことができる。

本発明の請求項６によるバッファリング方法は、リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングデータのストリーミング方法であって、前記ネットワークへの送出前に前記ストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加することによって送出タイミングを調整するようにしたことを特徴とする。このような方法を用いれば、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行うことができる。

以上説明したように本発明は、所定のデータ伝送レートになるように、ストリーミングデータのバッファリングを行い、特に多段にバッファリングすることで所定の伝送レート（例えば６４Ｋｂｐｓ）の帯域をコンスタントに確保することがより確実となり、所定の伝送レートが条件となるＴＶ電話移動機端末上にて映像品質の安定したストリーミングを行うことができるという効果がある。
また、バッファリングを行う一定の待ち合わせ時間と一定のデータ量とを調整することにより、リアルタイム性を極力損なわないような、よりきめ細かな映像品質の調整ができるという効果がある。

以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
（実施の形態）
図１は、本発明の実施の形態に係るストリーミングシステムの構成例を示すブロック図である。同図に示されているように、本例のストリーミングシステム１００は、映像及び音声を入力するためのライブカメラ１７０と、ライブカメラ１７０によって入力される映像及び音声について符号化するためのエンコーダ１６０と、エンコーダ１６０によって符号化された後のデータを受けＲＴＰパケットデータとして配信するためのストリーミングサーバ１５０と、ストリーミングサーバ１５０より配信されるデータをＴＶ電話移動機端末向けのストリーミングデータとして変換して送出する映像ストリーミングゲートウェイ１２０と、移動通信ネットワーク２００と、ストリーミングデータを再生するためのＴＶ電話移動機端末１１０とを含んで構成されている。

エンコーダ１６０とストリーミングサーバ１５０との間は、専用線等によって接続される。
ストリーミングサーバ１５０と映像ストリーミングゲートウェイ１２０との間は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって接続される。
映像ストリーミングゲートウェイ１２０は、ゲートウェイ本体装置１４０と、インタフェース変換装置１３０とから構成されている。
移動通信ネットワーク２００は、本例では６４Ｋｂｐｓ回線交換網である。

（システム構成例）
図２は、本発明の実施の形態に係るストリーミングシステムのより詳細な構成を示すブロック図である。同図において、ストリーミングサーバ１５０は、クライアントの認証及び接続処理を行うクライアント認証・接続部１５０ａと、ストリーミングコンテンツの管理を行うストリーミングコンテンツ管理部１５０ｂと、映像及び音声をＲＴＰで配信する処理を行うストリーミングコンテンツＲＴＰ配信部１５０ｃと、クライアントの切断処理を行うクライアント切断制御部１５０ｄとを含んで構成されている。

ゲートウェイ本体装置１４０は、呼の接続処理を行う呼制御（接続）部１４０ａと、ストリーミングサーバとの接続認証処理を行うストリーミングサーバ接続認証部１４０ｂと、ストリーミングコンテンツの選択制御を行うストリーミングコンテンツ選択制御部１４０ｃと、ＲＴＰデータを要求するＲＴＰデータ要求部１４０ｄと、ＲＴＰデータを受信するＲＴＰデータ受信部１４０ｅと、音声と映像との同期処理を行う音声映像同期制御部１４０ｆと、音声及び映像の送出タイミングを制御する音声映像バッファリング・送出制御部１４０ｇと、呼の切断処理を行う呼制御（切断）部１４０ｈと、ストリーミングサーバとの接続の切断処理を行うストリーミングサーバ切断制御部１４０ｉとを含んで構成されている。

インタフェース変換装置１３０は、ＰＲＩ（Ｐｒｉｍａｒｙ Ｒａｔｅ Ｉｎｔｅｒｆａｃｅ）回線の接続処理を行うＰＲＩ回線終端（接続）部１３０ａと、Ｈ．２４５信号の送受信を行うＨ．２４５信号制御部１３０ｂと、音声及び映像の送出タイミングを制御する音声映像バッファリング・送出制御部１３０ｃと、Ｈ．２２３信号の多重・分離・送出を行うＨ．２２３信号多重・分離・送出部１３０ｄと、ＰＲＩ回線の切断処理を行うＰＲＩ回線終端（切断）部１３０ｅとを含んで構成されている。

ＴＶ電話移動機端末１１０は、接続要求を送出する接続要求部１１０ａと、Ｈ．２４５信号の送受信を行うＨ．２４５信号制御部１１０ｂと、Ｈ．２２３信号の多重・分離・受信を行うＨ．２２３信号多重・分離・受信部１１０ｃと、音声及び映像をデコードして表示する処理を行う音声映像デコード表示部１１０ｄと、切断要求を送出する切断要求部１１０ｅとを含んで構成されている。

なお、Ｈ．２４５は、３Ｇ−３２４Ｍにおいて、端末同士がデータの送信や受信に関して、お互いの端末がどのような規格によってデータを交換したらよいかなど能力に関する情報を交換しながら、最適な通信方法を決定するためのネゴエーションを行うためのマルチメディア通信制御プロトコル（ＩＴＵ−Ｔ勧告）である。
Ｈ．２２３は、マルチメディア多重化プロトコルである。Ｈ．２２３では、音声や画像を１本の移動体通信チャネルに多重化して伝送する。

（動作例）
図３〜図６は、本発明の実施の形態に係るストリーミングシステムにおける処理を示すシーケンス図である。以下、これらシーケンス図に沿って、本システムの処理内容を説明する。
図３において、ＴＶ電話移動機端末１１０は、インタフェース変換装置１３０に対し、発信者番号、コンテンツＩＤを指定して接続を要求する（ステップＳ１）。インタフェース変換装置１３０は、ゲートウェイ本体装置１４０に対し、発信者番号、コンテンツＩＤと接続要求を通知する（ステップＳ２）。

ＴＶ電話移動機端末１１０から接続の要求を受けたインタフェース変換装置１３０は、ＴＶ電話移動機端末１１０に対し、接続要求を受けデータリンクレベルの回線接続応答を返す（ステップＳ３）。ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０に対し、発信者番号を用いクライアント認証依頼を行う（ステップＳ４）。ストリーミングサーバ１５０は、ゲートウェイ本体装置１４０に対し、発信者番号を用いクライアント認証を行い、応答を返す（ステップＳ５）。
ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０での認証結果を受け、ＴＶ電話移動機端末１１０に対し、ネットワークレベルの回線接続応答を返す（ステップＳ６）。その後、インタフェース変換装置１３０とＴＶ電話移動機端末１１０との間で、端末能力交換などのネゴシエーションが行われる（ステップＳ７）。

図４に移行し、ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０に対し、受信したコンテンツＩＤに対応するコンテンツＵＲＬを求める（ステップＳ８）。ストリーミングサーバ１５０は、ゲートウェイ本体装置１４０に対し、コンテンツＩＤに対応するコンテンツＵＲＬを返す（ステップＳ９）。ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０に対し、コンテンツに対応するデコード情報を求める（ステップＳ１０）。ストリーミングサーバ１５０は、ライブカメラ１７０に接続されているエンコーダ１６０からコンテンツに対応するデコード情報を取得し、ゲートウェイ本体装置１４０に対して返す（ステップＳ１１）。

ゲートウェイ本体装置１４０は、インタフェース変換装置１３０に対し、コンテンツに対応するデコード情報を通知する（ステップＳ１２）。インタフェース変換装置１３０は、ＴＶ電話移動機端末１１０に対し、デコード情報を使って論理チャネルの確立を要求する（ステップＳ３）。ＴＶ電話移動機端末１１０は、インタフェース変換装置１３０に対し、論理チャネルの確立の応答を行う（ステップＳ１４）。

図５に移行し、ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０に対し、コンテンツストリーミングのためのセッション確立を求める（ステップＳ１５）。ストリーミングサーバ１５０は、ゲートウェイ本体装置１４０に対し、コンテンツストリーミングのためのセッションを確立し応答する（ステップＳ１６）。ゲートウェイ本体装置１４０は、ストリーミングサーバ１５０に対し、コンテンツストリーミングの開始を求める（ステップＳ１７）。

ストリーミングサーバ１５０は、ゲートウェイ本体装置１４０に対し、ライブカメラ１７０に接続されているエンコーダ１６０から取得したコンテンツのストリーミングを開始する（ステップＳ１８）。これにより、映像及び音声のＲＴＰパケットが送出され、ゲートウェイ本体装置１４０は、映像及び音声のＲＴＰパケットを受信する（ステップＳ１９）。

ゲートウェイ本体装置１４０は、同一のタイムスタンプを持つ映像のＲＴＰパケットからペイロードを１ＶＯＰ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｐｌａｎｅ）化し、移動機側で指定する最大サイズでストリーミングデータを移動機に送信する際のデータ単位であるＡＬ−ＳＤＵ（Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）に分割する（ステップＳ２０）。

図６に移行し、ゲートウェイ本体装置１４０は、同一のタイムスタンプを持つ音声のＲＴＰパケットのペイロードを、フレームタイプに応じて切り出し、移動機端末向けフォーマットのＡＭＲ（Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ）フレームへ変換する（ステップＳ２１）。ゲートウェイ本体装置１４０は、分割された映像ＶＯＰ及び音声フレームを各々に対応するタイムスタンプに基づき時系列に配列する（ステップＳ２２）。

ゲートウェイ本体装置１４０は、インタフェース変換装置１３０に対し、６４Ｋｂｐｓに見合うレートになるよう一定時間のバッファリングし一定サイズでインタフェース変換装置１３０へ送信する。このように、ＲＴＰパケットの映像と音声のデータを一定時間まで待ち合わせバッファリングを行い、６４Ｋｂｐｓに見合うレートになるよう、一定のデータ量に分割してインタフェース変換装置へ送出することによって、ストリーミングデータのオーバーフロー（過大）およびアンダーフロー（過小）が起きないようにすることができる。
なお、一定時間待っても一定サイズにならない時は、バッファリングできた分をインタフェース変換装置１３０へ送信する（ステップＳ２３）。このように、一定のデータ量に達しない場合はバッファリングできただけのデータを送出することによって、ストリーミングデータのアンダーフローを防止できる。

インタフェース変換装置１３０は、ゲートウェイ本体装置１４０からの映像及び音声のデータを、回線交換網とのインタフェース用ストリーミングデータに変換する（ステップＳ２４）。インタフェース変換装置１３０は、ＴＶ電話移動機端末１１０に対し、映像及び音声のアンダーフローによる移動機端末側での映像の乱れを更に回避するために、一定時間のバッファリングを行い、変換後のストリーミングデータを回線交換網経由でＴＶ電話移動機端末へ送出する（ステップＳ２５）。このバッファリングは、最初のストリーミングデータの先頭に一定時間分のブランクデータを付加することによって行う。ＴＶ電話移動機端末１１０は、受信したストリーミングデータをデコードして表示する（ステップＳ２６）。
なお、ゲートウェイ本体装置１４０及びインタフェース変換装置１３０における、バッファリングを行う一定の待ち合わせ時間と一定のデータ量は、映像と音声とのリアルタイム性を極力損なわないよう最適な値となるようチューニングして設定する。

（フレーム構成例）
本システムにおいて授受されるフレームの構成例が図７及び図８に示されている。両図には、ＲＴＰパケットの音声・映像データから音声・映像ストリームデータを作成する処理が示されている。
図７において、ストリーミングサーバから送出されたＲＴＰパケットを受信し、ＡＬ−ＳＤＵに分割する。ＲＴＰパケットに付加されているＲＴＰヘッダの内容がペイロードタイプ「ＡＭＲ」、シーケンス番号「２４３７」、タイムスタンプ「０００１００」である場合、ペイロードデータを３つのフレーム１〜３に分割し、音声１−１、１−２、１−３のＡＬ−ＳＤＵとする。本例では音声１−１、１−２、１−３は、いずれも３１ｂｙｔｅである。

また、ＲＴＰパケットに付加されているＲＴＰヘッダの内容がペイロードタイプ「ＭＰＥＧ−４」、シーケンス番号「１５８０」、タイムスタンプ「０００１００」である場合、ペイロードデータを１ＶＯＰ化し、映像１−１のＡＬ−ＳＤＵとする。本例では映像１−１は、２５６ｂｙｔｅである。
さらに、ＲＴＰヘッダの内容がペイロードタイプ「ＭＰＥＧ−４」、シーケンス番号「１６０６」、タイムスタンプ「０００１１０」のＲＴＰパケット、及び、ＲＴＰヘッダの内容がペイロードタイプ「ＭＰＥＧ−４」、シーケンス番号「１６０７」、タイムスタンプ「０００１１０」のＲＴＰパケットに付加されているペイロードデータについて１ＶＯＰ化し、前者については映像１−２及び１−３とし、後者については映像１−４とする。本例では、映像１−２は２００ｂｙｔｅ、映像１−３は５０ｂｙｔｅ、映像１−４は２５６ｂｙｔｅである。

図８において、ＡＬ−ＳＤＵを時系列に並べ替え音声・映像ストリームデータを作成する。音声は２０ｍｓ間隔で、その間に映像データに割り当てる。本例では、同図に示されているように、映像１−１、音声１−１、音声１−２、映像１−２、映像１−３、映像１−４、音声１−３、の順にデータが並んでいる。そして、各データの前には、音声・映像識別ＩＤ、フレーム長、のデータが付加されている。

また、音声・映像ストリームデータを送出する前に、スタッフィングデータを先に送出する。このスタッフィングデータは、音声・映像データが無いときのアイドリングパターンデータである。このスタッフィングデータの付加は、ストリーミングデータを送出するタイミングを遅らせるために行われる処理である。このスタッフィングデータを付加することにより、バッファリングすることと等価の効果が得られる。つまり、インタフェース変換装置１３０においては、映像と音声のデータのアンダーフローによる移動機端末側での映像の乱れを更に回避するために更に一定時間、映像と音声のデータのバッファリングを行っていることになる。そして、このバッファリングは、最初に送出する映像と音声のデータの先頭にバッファリング時間分のブランクデータを付加することで行われる。

本例では、ゲートウェイ本体装置においてバッファリングを行う他に、インタフェース変換装置においてもブランクデータ付加によるバッファリングを行っていることになる。このように、多段にバッファリングすることで、６４Ｋｂｐｓの帯域をコンスタントに確保することがより確実となり、６４Ｋｂｐｓ伝送が条件となるＴＶ電話移動機端末上にて映像品質の安定したストリーミングを行うことができる。
また、バッファリングを行う一定の待ち合わせ時間と一定のデータ量は調整が可能であり、リアルタイム性を極力損なわないような、よりきめ細かな映像品質の調整が可能となる。

（インタフェース変換装置）
以上説明したストリーミングシステムにおいては、以下のようなインタフェース変換装置が用いられている。すなわち、リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムに用いるインタフェース変換装置であって、上記ネットワークへの送出前に上記ストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加する手段を含むインタフェース変換装置が用いられている。このような装置を用いれば、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行うことができる。

（バッファリング方法）
以上説明したストリーミングシステムにおいては、以下のようなバッファリング方法が用いられている。すなわち、リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングデータのストリーミング方法であって、上記ネットワークへの送出前にストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加することによって送出タイミングを調整するようにしたストリーミング方法が用いられている。このような方法を用いれば、所定の伝送レートを実現でき、映像品質の安定したストリーミングを行うことができる。

（まとめ）
上述の如く、本発明によれば、ゲートウェイ本体装置とインタフェース変換装置にて多段でバッファリングすることで６４Ｋｂｐｓの帯域をコンスタントに確保することがより確実となり、６４Ｋｂｐｓ伝送が条件となるＴＶ電話移動機端末上にて映像品質の安定したストリーミングを行うことができる。
また、バッファリングを行う一定の待ち合わせ時間と一定のデータ量は調整が可能であり、リアルタイム性を極力損なわないような、よりきめ細かな映像品質の調整が可能となる。

本発明は、リアルタイムにライブストリーミング配信するシステムに適用することができる。

本発明の実施の形態に係るストリーミングシステムの構成例を示すブロック図である。 本発明の実施の形態に係るストリーミングシステムのより詳細な構成を示すブロック図である。 本発明の実施の形態に係るストリーミングシステムにおける処理を示すシーケンス図である。 本発明の実施の形態に係るストリーミングシステムにおける処理を示すシーケンス図である。 本発明の実施の形態に係るストリーミングシステムにおける処理を示すシーケンス図である。 本発明の実施の形態に係るストリーミングシステムにおける処理を示すシーケンス図である。 本発明の実施の形態に係るストリーミングシステムにおいて授受されるフレームの構成例を示す図である。 本発明の実施の形態に係るストリーミングシステムにおいて授受されるフレームの構成例を示す図である。

符号の説明

１００ ストリーミングシステム
１１０ ＴＶ電話移動機端末
１１０ａ 接続要求部
１１０ｂ Ｈ．２４５信号制御部
１１０ｃ Ｈ．２２３信号多重・分離・受信部
１１０ｄ 音声映像デコード表示部
１１０ｅ 切断要求部
１２０ 映像ストリーミングゲートウェイ
１３０ インタフェース変換装置
１３０ａ ＰＲＩ回線終端（接続）部
１３０ｂ Ｈ．２４５信号制御部
１３０ｃ 音声映像バッファリング・送出制御部
１３０ｄ Ｈ．２２３信号多重・分離・送出部
１３０ｅ ＰＲＩ回線終端（切断）部
１４０ ゲートウェイ本体装置
１４０ａ 呼制御（接続）部
１４０ｂ ストリーミングサーバ接続認証部
１４０ｃ ストリーミングコンテンツ選択制御部
１４０ｄ データ要求部
１４０ｅ データ受信部
１４０ｆ 音声映像同期制御部
１４０ｇ 音声映像バッファリング・送出制御部
１４０ｈ 呼制御（切断）部
１４０ｉ ストリーミングサーバ切断制御部
１５０ ストリーミングサーバ
１５０ａ クライアント認証・接続部
１５０ｂ ストリーミングコンテンツ管理部
１５０ｃ 配信部
１５０ｄ クライアント切断制御部
１６０ エンコーダ
１７０ ライブカメラ
２００ 移動通信ネットワーク

Claims (6)

1. リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムであって、前記ネットワークにおいて所定のデータ伝送レートになるように、該ネットワークへの送出前に前記ストリーミングデータのバッファリングを行うバッファリング手段を含むことを特徴とするストリーミングシステム。
2. 前記バッファリング手段は、ストリーミングデータのオーバーフロー及びアンダーフローが起きないように、映像及び音声のデータを一定時間まで待ち合わせてバッファリングを行い、前記データ伝送レートに見合うレートになるよう、一定のデータ量に分割して送出することを特徴とする請求項１記載のストリーミングシステム。
3. 前記バッファリング手段は、前記映像及び音声のデータを一定時間まで待ち合わせても前記一定のデータ量に達しない場合はバッファリングできただけのデータを送出することを特徴とする請求項２記載のストリーミングシステム。
4. 前記バッファリング手段から送出されるデータに、バッファリングすべき時間に相当する量のブランクデータを付加する手段を更に含むことを特徴とする請求項１から３までのいずれか１項に記載のストリーミングシステム。
5. リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングシステムに用いるインタフェース変換装置であって、前記ネットワークへの送出前に前記ストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加する手段を含むことを特徴とするインタフェース変換装置。
6. リアルタイムに入力される映像及び音声のデータを、ストリーミング転送プロトコルに従ってストリーミングデータとし、ネットワークを介してクライアントに送信するストリーミングデータのストリーミング方法であって、前記ネットワークへの送出前に前記ストリーミングデータに、バッファリングすべき時間に相当する量のブランクデータを付加することによって送出タイミングを調整するようにしたことを特徴とするバッファリング方法。

Images