JP2016123097A - 配信サーバ、配信方法、配信プログラム、及び配信システム - Google Patents

配信サーバ、配信方法、配信プログラム、及び配信システム Download PDF

Info

Publication number
JP2016123097A
JP2016123097A JP2015249289A JP2015249289A JP2016123097A JP 2016123097 A JP2016123097 A JP 2016123097A JP 2015249289 A JP2015249289 A JP 2015249289A JP 2015249289 A JP2015249289 A JP 2015249289A JP 2016123097 A JP2016123097 A JP 2016123097A
Authority
JP
Japan
Prior art keywords
time
content
input
division
division 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
Application number
JP2015249289A
Other languages
English (en)
Inventor
誠 五味
Makoto Gomi
誠 五味
朋博 宮崎
Tomohiro Miyazaki
朋博 宮崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oki Electric Industry Co Ltd
Original Assignee
Oki Electric Industry Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Oki Electric Industry Co Ltd filed Critical Oki Electric Industry Co Ltd
Publication of JP2016123097A publication Critical patent/JP2016123097A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】各時分割コンテンツの入力開始から再生開始までの遅延時間を低減する。
【解決手段】時分割コンテンツ（Segment２６）のURLが記載されたPlay_List２７と時分割コンテンツとを格納する記憶装置２２と、時分割コンテンツを記憶装置に逐次格納するときに、入力予定の時分割コンテンツのURLをPlay_List２７に追記するアップロード処理部２３ａと、映像視聴端末３０からPlay_List２７の送信要求を受信した場合、追記したPlay_List２７を映像視聴端末３０に返信し、追記されたURLの時分割コンテンツの配信要求を受信した場合、該配信要求を受信した時分割コンテンツの格納開始前は、時分割コンテンツの配信を保留し、追記されたURLの時分割コンテンツの格納開始を確認してから、配信要求に応答して、格納された時分割コンテンツを映像視聴端末３０に配信するダウンロード処理部２４とを備える。
【選択図】図２

Description

本発明は、配信サーバ、配信方法、配信プログラム、及び配信システムに関し、例えば、ネットワーク経由で、映像データや音声データ等のライブメディアコンテンツを端末に逐次配信する技術に関する。
例えば、金融機関や交通機関は、早くから監視カメラを用いた映像監視システムを、犯罪抑止や犯罪実証のために利用している。通常、監視カメラによって撮影されたライブ映像は、通信ネットワークを使って管理サーバに送信され、端末で逐次視聴するようにされている。
非特許文献１は、ビデオカメラで撮影中のライブ映像（コンテンツ）をインターネット接続でサーバからクライアント（受信端末）に配信する方法の一つを開示している。この方法は、カメラ等で撮影してエンコードしたライブ映像データについて、短時間毎に分割されたデータファイルを、クライアントがサーバからファイルを順番にダウンロードしてライブ映像を再生するものである。また、クライアントは、サーバが生成したインデックスファイルを受信し、インデックスファイル（Play_List）に順番に記述されたＵＲＬ（Uniform_Resource_Locator）に逐次アクセスする。
また、特許文献１は、各Segmentを、さらにSub_Segmentに分け、最も新しいSub_Segmentから再生することにより、遅延を低減する技術を開示している。
特開2013-38766号公報
「HTTPライブストリーミングの概要」第１０頁、インターネット<URL:https://developer.apple.com/jp/devcenter/ios/library/documentation/StreamingMediaGuide.pdf>
非特許文献１の方法は、クライアント（受信端末）が複数の短い映像コンテンツ（以下、Segmentという）を連続して再生することにより、一つのコンテンツを再生するものであり、各Segmentファイルを生成し、ダウンロード、再生という手順を踏んでいる。このため、非特許文献１の方法は、ライブ遅延が大きくなるという問題があり、遅延を低減するための工夫が考えられている。例えば、バッファリング時間を最小限にしたり、一つのSegmentが完成する前（０秒目のデータ生成が始まった時点）から、アップロードを始めたり、アップロードされるSegmentのサーバでの受信が始まり次第、端末からダウンロード可能としたりしている。このような工夫を行った配信サーバでも、以下の問題点が発生し得る。
図１３は、比較例のコンテンツ配信システムのシーケンス図である。比較例の詳細は、後記するが、ここでは概要を説明する。比較例のコンテンツ配信システムは、映像送信端末１０がライブ映像等のコンテンツを逐次分割し、分割された時分割コンテンツ（Segment）を配信サーバ２０ｄに逐次、アップロードし、配信サーバ２０ｄがアップロードされたSegmentを記憶装置に逐次格納し、格納場所を示すURLをPlay_Listに追記するように構成されている。また、比較例のコンテンツ配信システムは、配信サーバ２０ｄが、映像視聴端末３０からPlay_Listの送信要求を受信したときに、追記されたPlay_Listを映像視聴端末３０に送信し、映像視聴端末３０からSegmentの配信要求を受信したときに、指定されたURLのSegmentを映像視聴端末３０に配信するように構成されている。
例えばライブ映像の配信の場合、映像視聴端末３０は、Play_Listに記述された最新のURLのSegmentを配信サーバ２０ｄに配信要求し、該最新のURLのSegmentの受信が完了したら、再び、Play_Listの送信要求を行い、次のSegmentのURLが追記されたPlay_Listを受信するように構成されている。
また、図１４は、配信サーバ２０ｄがＮ番目のSegment（以下、Segment[N]とする）をアップロード（入力）し終え、Segment[N+1]のアップロードの途中、６秒目まで進んでいる配信状態を示している（ここで、各Segmentの時間幅は１０秒とする）。
この６秒目まで進んでいる時、映像視聴端末３０は、Play_Listを取得すると、Segment[N+1]までのURLを取得することができる。このため、映像視聴端末３０は、ライブ映像を低遅延再生する場合は、直近のURLであるSegment[N+1]を選択して、ダウンロードを開始することになる。しかしながら、映像視聴端末３０は、ネットワーク速度が十分にあれば、アップロード位置である６秒目までを短時間で取得（入力、ダウンロード）できるものの、映像視聴端末３０は、Videoデータの再生を各Segment（各時分割セグメント）の先頭から始める必要がある。そのため、映像視聴端末３０において、Segment[N+2]のアップロード開始の時刻から、再生開始までに時間差が発生し、再生遅延の時間は６秒となる（図１３参照）。また、Segment[N+3]以降も同様に再生遅延が発生し、再生遅延の時間は６秒である。
ここで、Videoデータの再生速度は自由が効かないことに注意する必要がある。つまり、１０秒のVideoデータは１０秒かけて再生される必要があり、次回以降のSegment[N+2]，・・・の再生開始も、Segment[N+1]の再生終了時点から連続的に再生されるので、６秒の再生遅延が発生する。ここで、再生遅延は、Segment[N+1]の６秒目から再生を始められれば無くなるが、映像視聴端末３０は、Videoデータをキーフレームからしか再生することができず、キーフレームである０秒目から再生を開始せざるを得ない。そのため、再生遅延は発生する。
なお、映像視聴端末３０は、何らかの方法で遅延を検出して、遅延している分を早送りすれば、遅延を回復することは可能である。しかし、映像視聴端末３０は、遅延を回復するための特別な機能を必要とする。また、特許文献１の方法を採用する場合でも、映像視聴端末３０は、０秒目から６秒目までの間に存在する最も新しいSub_Segmentのキーフレームから再生を開始せざるを得ない。ある程度の再生遅延は低減されるものの、最も新しいSub_Segmentのキーフレーム位置に対応する時間と６秒目の差分の再生遅延は発生する。特許文献１の方法を採用した映像視聴端末３０は、この再生遅延の発生メカニズムを回避することができていない。
そこで、本発明は、各時分割コンテンツの入力開始から再生開始までの遅延時間を低減することができる配信サーバ、配信方法、配信プログラム、及び配信システムを提供することを目的とする。
前記課題を解決するため、第１の本発明は、コンテンツが時分割された時分割コンテンツ（例えば、Segment）を入力（受信を含む）し、入力された時分割コンテンツを再生する再生端末（例えば、映像視聴端末３０）に出力する配信サーバ（２０）であって、前記時分割コンテンツのロケーション識別情報（例えば、URL）が記載されたファイル（例えば、プレイリスト，MPDファイル）と前記時分割コンテンツとを格納する記憶装置（２２）と、前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記する入力処理部（例えば、アップロード処理部２３ａ、入力処理部２３ｂ）と、コンテンツの配信要求を受信したときに、前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始前であるならば、当該時分割コンテンツの配信を保留し、前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始させているならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理部（ダウンロード処理部２４）とを備えることを特徴とする。なお、（ ）内の記載は例示であり、（ ）内の記載に限定されるものではない。
この配信サーバは、端末から入力予定の時分割コンテンツの配信要求を受信した場合、配信を保留し、該入力予定の時分割コンテンツが格納開始されてから端末に配信を行うので、配信要求から再生開始タイミングまでの遅延が発生しない。
第２の本発明は、コンテンツが時分割された時分割コンテンツを逐次入力し、入力された時分割コンテンツを再生する再生端末に逐次配信する配信サーバであって、前記入力された時分割コンテンツと該入力された時分割コンテンツのロケーション識別情報が記載されたインデックスファイルとを格納する記憶装置と、前記再生端末からインデックスファイルの送信要求を受信すると、入力予定の時分割コンテンツに対応するロケーション識別情報を前記インデックスファイルに追記して、追記されたインデックスファイルを前記再生端末に送信するインデックスファイル処理部と、ロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、当該ロケーション識別情報に対応する時分割コンテンツの格納開始前は、当該時分割コンテンツの配信を保留し、当該ロケーション識別情報に対応する時分割コンテンツの格納開始を確認してから、前記配信要求に応答して、当該時分割コンテンツを前記再生端末に配信する配信処理部とを備えることを特徴とする配信サーバである。
第３の本発明は、コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力し、前記時分割コンテンツのロケーション識別情報が記載されたファイルと前記時分割コンテンツとを格納する記憶装置を備える配信サーバのコンピュータに実行させる配信プログラムであって、前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記する入力処理過程と、コンテンツの配信要求を受信したときに、前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始前であるならば、当該時分割コンテンツの出力を保留し、前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理過程とを実行させることを特徴とする配信プログラムである。
第４の本発明は、コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力する配信システムであって、入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１サーバと、前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２サーバと、を備えることを特徴とする配信システムである。
第５の本発明は、コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力する配信システムの配信方法であって、入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１処理ステップと、前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２処理ステップと、を備えることを特徴とする配信方法である。
第６の本発明は、コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力するコンピュータに実行させる配信プログラムであって、前記コンピュータを、入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１処理手段、前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２処理手段、として機能させるための配信プログラムである。
第７の発明は、コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する配信サーバであって、前記時分割コンテンツとロケーション識別情報とを対比して記載したリストと前記時分割コンテンツとを格納する記憶装置と、前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記リストに追記する入力処理部と、前記コンテンツの配信要求を受信したときは、前記入力処理部が入力する時分割コンテンツの出力を保留し、前記配信要求受信後、前記入力処理部で次の時分割コンテンツの入力が開始したならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理部とを備えることを特徴とする。
第８の発明は、KeyFrameを有するコンテンツを入力し、該入力されたコンテンツを再生する再生端末に出力する配信サーバであって、前記KeyFrameの位置情報が記載されたリストと前記コンテンツとを格納する記憶装置と、前記入力されたKeyFrameコンテンツについて前記記憶装置に格納することを開始すると、当該コンテンツのKeyFrameの位置情報を前記リストに追記する入力処理部と、前記コンテンツの配信要求を受信したときは、前記入力処理部が入力するコンテンツの出力を保留し、前記配信要求受信後、前記入力処理部で次のKeyFrameの入力が開始したならば、当該KeyFrameからのコンテンツについて前記再生端末に出力することを開始する出力処理部とを備えることを特徴とする。
本発明によれば、各時分割コンテンツの入力開始から再生開始までの遅延時間を低減することができる。
本発明の第１実施形態であるコンテンツ配信システムの全体構成図である。 本発明の第１実施形態である映像送信端末、配信サーバ、及び映像視聴端末の機能ブロック図である。 プレイリストの一例を示す図である。 配信サーバの機能であるアップロード処理部の動作を示すフローチャートである。 （ａ）は配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。 配信サーバの機能であるエラー処理部の動作を示すフローチャートである。 本発明の第１実施形態であるコンテンツ配信システムのシーケンス図である。 本発明の第１実施形態である配信サーバによるセグメントの配信状態を示す図である。 本発明の第２実施形態である配信サーバ、及び映像視聴端末の内部構成図である。 本発明の第３実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。 本発明の第４，５実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。 本発明の第４実施形態である配信サーバの機能であるアップロード処理部の動作を示すフローチャートである。 （ａ）は本発明の第４実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。 本発明の第４実施形態であるコンテンツ配信システムのシーケンス図である。 （ａ）は本発明の第５実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。 本発明の第５実施形態であるコンテンツ配信システムのシーケンス図である。 本発明の第６実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。 本発明の第６実施形態である配信サーバの機能であるアップロード処理部の動作を示すフローチャートである。 （ａ）は本発明の第６実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。 本発明の第６実施形態であるコンテンツ配信システムのシーケンス図である。 本発明の第７実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。 本発明の第７実施形態の他の利用形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。 比較例のアップロード処理部の動作を示すフローチャートである。 比較例のダウンロード処理部の動作を示すフローチャートである。 比較例のコンテンツ配信システムのシーケンス図である。 比較例の配信サーバによるセグメントの配信状態を示す図である。
以下、図面を参照して、本発明の実施の形態（以下、「本実施形態」と称する）につき詳細に説明する。なお、各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。
(第１実施形態)
（構成の説明）
≪コンテンツ配信システム１≫
図１は、本発明の第１実施形態であるコンテンツ配信システムの全体構成図である。
コンテンツ配信システム１は、映像送信端末１０と、コンテンツ配信装置としての配信サーバ２０（２０ａ）と、複数の再生端末としての映像視聴端末３０（３０ａ，３０ｂ，３０ｃ，３０ｄ，・・・）とを備える。配信サーバ２０は、ネットワークＮＷ１を介して映像視聴端末３０のそれぞれと通信可能に接続され、ネットワークＮＷ２を介して映像送信端末１０と接続されている。
コンテンツ配信システム１は、ライブ映像（コンテンツ）をストリーミング配信するためのプロトコルであるＨＬＳ（HTTP_Live_Streaming）を前提としている。そのため、コンテンツ配信システム１は、ライブ映像を短い時間で分割したセグメント（Segment）として取り扱う。なお、詳細は後記するが、コンテンツ配信システム１は、後記する比較例の配信方法と比較して「Play_List」を更新するタイミングや「Segment」の配信を開始するタイミングなどに特徴がある。
（映像送信端末１０）
映像送信端末１０は、ビデオカメラ１１を外部に接続し、接続されたビデオカメラ１１で逐次撮像されたライブ映像やライブ音声を含むライブコンテンツを、ネットワークＮＷ２を介して配信サーバ２０ａに送信（アップロード）する端末装置である。ここで、ビデオカメラ１１は、リアルタイムに映像データや音声データを生成するVideo_Sourceである。
（映像視聴端末３０）
映像視聴端末３０は、通信機能を備えたコンピュータであり、ファイル化（Segment化）されたライブコンテンツ（映像データや音声データ）を再生して、映像を表示パネル３７（図２参照）に表示させ、音声を発音させる再生端末である。映像視聴端末３０は、例えば、スマートフォン（smartphone）等の携帯通信端末や、タブレット型コンピュータ等の携帯情報端末等の無線で通信を行うコンピュータである。また、据え置き型のデスクトップパソコン（desktop_personal_computer）等の有線で通信を行うコンピュータであってもよい。複数の映像視聴端末３０ａ，３０ｂ，３０ｃ，３０ｄ，・・・は、ブラウザを介して同一のコンテンツをほぼ同時に視聴することができる。
（配信サーバ２０ａ）
配信サーバ２０ａは、ネットワークＮＷ２を介して接続された映像視聴端末１０からSegment化された映像データがアップロードされるのを受信する。また、配信サーバ２０ａは、ネットワークＮＷ１を介して接続された映像視聴端末３０からアップロードされた映像データの配信要求を受け、対応する映像データを映像視聴端末３０に配信する。配信サーバ２０ａの詳細な構成については後記する。
（ネットワークＮＷ１，ＮＷ２）
ネットワークＮＷ１は、映像視聴端末３０のそれぞれと配信サーバ２０ａとを接続し、ネットワークＮＷ２は、映像送信端末１０と配信サーバ２０ａとを接続するコンピュータネットワークである。ネットワークＮＷ１，ＮＷ２は、例えば、有線／無線ＬＡＮ（Local_Area_Network）やＷＡＮ（Wide_Area_Network）等を介して、インターネットプロトコル（Internet_Protocol）技術を利用して相互接続する。
図２は、映像送信端末、コンテンツ配信装置、及び映像視聴端末の機能ブロック図である。以下、映像送信端末１０、コンテンツ配信装置２０ａ、及び映像視聴端末３０の順に、内部構成を説明する。
（映像送信端末１０の内部構成）
映像送信端末１０は、ビデオカメラ１１を外部に接続し、Video_Encoder１２と、TS_Muxer１３と、Segmenter１４と、HTTP_Client１５との機能を実現する。映像送信端末１０は、非特許文献１におけるサーバコンポーネントの役割を果たすものである。
Video_Encoder１２は、ビデオカメラ１１で撮像したライブコンテンツをVideo_Stream （例えば、H.264）にエンコードする。TS_Muxer１３は、このVideo_StreamをMPEG2_Transport_Stream（以下、ＴＳという。）に結合（Mux）する。この TS_Muxer１３では、Video_Streamの他、Audio_Streamやその他のデータを結合して一つのＴＳにするのが一般的である。Segmenter１４は、ＴＳを適切な短い時間（本実施形態では、例えば１０秒）に区切って複数のファイルを生成する。Segmenter１４が生成する各々のファイルを、Segmentと呼ぶ。Segmentは、先頭がキーフレームから始まり、それ単独でも再生が可能な、短い時間幅のＴＳファイルである。HTTP_Client１５は、Segmenter１４が生成したファイルを、逐次、HTTP_PUTリクエストにより配信サーバ２０ａにアップロードする。
（配信サーバ２０ａの内部構成）
配信サーバ２０ａは、制御部２５（２５ａ）と記憶装置２２とを備え、制御部２５ａはプログラムを実行することにより、HTTP_Server２１と入力処理部としてのアップロード処理部２３（２３ａ）と出力処理部としてのダウンロード処理部２４（２４ａ）とエラー処理部２８（２８ａ）との機能を実現する。
記憶装置２２は、コンテンツを時系列的に分割した複数のSegment２６と、複数のSegment２６に対応する１つのPlay_List２７とを格納する。
HTTP_Server２１は、非特許文献１におけるディストリビューションコンポーネントの役割を果たす。具体的には、HTTP_Server２１は、ＨＴＴＰ（Hypertext_Transfer_Protocol、ハイパーテキスト・トランスファー・プロトコル）を用いて映像送信端末１０、及び映像視聴端末３０との間でSegmentに分割されたライブコンテンツやこれに関連する情報を送受信する。
アップロード処理部２３ａは、非特許文献１におけるディストリビューションコンポーネントの役割を果たす。具体的には、アップロード処理部２３ａは、映像送信端末１０から受信（アップロード）したSegmentを記憶装置２２に保存する（以下、Ｎ番目にアップロードされたSegmentをSegment[N]と呼ぶ）。これにより、記憶装置２２には、ライブコンテンツを構成する複数のSegment２６（Segment[N]，Segment[N+1]，Segment[N+2]，・・・）が格納される。
また、アップロード処理部２３ａは、アップロードを開始したSegment（ここでは、Segment[N]とする）の次にアップロードする予定のSegment（ここでは、Segment[N+1]とする）を格納する位置を、Segment[N]のアップロードの完了する前（最適なタイミングはアップロードの開始直後）にPlay_List２７に追記する。これにより、Play_List２７には、時間順にSegment[N]のURL（Uniform_Resource_Locator、ユニフォームリソースロケータ）が列記されることになる。ここで、URLは、リソースの識別情報であるURI（Uniform_Resource_Identifier、ユニフォーム・リソース・アイデンティファイア）において、リソースの「場所」を識別するものである。
アップロード処理部２３ａにより更新されたプレイリストの例を図３に示す。Play_List２７は、HLS(HTTP_Live_Streaming)における拡張子「.m3u8」のインデックスファイルであり、ここでは、時系列的にSegment[N]，Segment[N+1]，Segment[N+2]のURLが列記されている。コンテンツとしてのライブ映像の配信を想定した場合、Segment[N+1]のアップロードを行っている最中であり、最新のSegment[N+2]のアップロードは開始されていない状態となる。なお、「#EXTM3U」はヘッダであり、「#EXTINF:10」はSegmentにおける時間の長さが１０秒であることを意味する拡張情報である。なお、Segmentの配列でカウントされるセグメント番号をインデックスという。
ダウンロード処理部２４ａは、非特許文献１におけるディストリビューションコンポーネントの役割を果たす。具体的には、ダウンロード処理部２４ａは、映像視聴端末３０からPlay_List２７の送信要求を受信し、その送信要求に従い、記憶装置２２に存在するPlay_List２７を映像視聴端末３０に返信する。また、配信サーバ２０ａは、映像視聴端末３０から受信したコンテンツ（Segment２６）の配信要求を受信し、その送信要求に従い、記憶装置２２に存在するSegment２６について配信し、Segment２６を配信する。ここで、ライブ映像の配信のときには、映像視聴端末３０は、Play_List２７に記載された最新のSegment（アップロード開始前のSegment）のURLを指定するようになっている。
エラー処理部２８ａは、通信障害、過大な処理時間の経過や、端末の異常情報等が発生したときに、映像送信端末１０や映像視聴端末３０にエラーを返信する割り込み処理を実行するものである。
（映像視聴端末３０の内部構成）
映像視聴端末３０は、制御部３８と表示パネル３７とを備え、制御部３８は、ＣＰＵがプログラムを実行することにより、HTTP_Client３１と主制御部３２とTS_Demuxer３３とVideo_Decoder３４とRenderer３５とブラウザ３６との機能を実現する。映像視聴端末３０は、ＨＬＳでのクライアントコンポーネントの役割を果たすものである。
HTTP_Client３１は、配信サーバ２０ａが送信したファイルを受信する。つまり、HTTP_Client３１は、HTTP_GETリクエストにより配信サーバ２０ａに対して、Play_List２７やSegment２６の要求を行い、Play_List２７やSegment２６を受信する。なお、HTTP_Client３１は、映像の安定化のためにデータをバッファリングするが、ライブ映像の受信のときには、バッファ時間を最小限に設定している。主制御部３２は、複数のSegmentからなるコンテンツのダウンロードを制御するものである。主制御部３２の動作については後記する。
TS_Demuxer３３は、受信したSegmentから音声データ等を分離して、Video_Streamを取り出す。また、TS_Demuxer３３は、取り出したVideo_StreamをVideo_Decoder３４に入力する。Video_Decoder３４は、符号化されたVideo_Streamを元のデータ（画像や画面の内容を指示するデータの集まり(数値や数式のパラメータ、描画ルールを記述したものなど)）に戻す。Renderer３５は、Video_Decoder３４の出力データを処理して、具体的な映像データや画像データを生成する。なお、映像送信端末１０が、Video_Stream以外のAudio_Stream等のデータを結合（Mux）している場合は、それらのデータも適切に処理される。ブラウザ３６は、Renderer３５が再生したデータの映像や画像を表示パネル３７に表示させる。表示パネル３７は、ＬＣＤ(Liquid_Crystal_Display)等により構成され、映像や画像を表示する。
（アップロード処理部２３ａの動作）
図４は、配信サーバの機能であるアップロード処理部の動作を示すフローチャートであり、このルーチンは映像送信端末１０と接続されることにより起動する。
最初に、アップロード処理部２３ａは、変数iをi=-1に設定して（Ｓ１１）、最初に受信されるべきSegment[i+1]のURLをPlay_List２７に記述する（つまり、Segment[-1+1]＝Segment[0]のURLを記述する。）（Ｓ１２）。実際に、Segmentがアップロードされる前にURLが必要となるので、Segment[0]のURLは、特定の規則に従った予測可能な文字列である必要がある。
次に、アップロード処理部２３ａは、実際に映像送信端末１０からアップロードの要求（例えば、HTTP_PUTリクエスト）があるまで待つ（Ｓ１３）。
アップロード処理部２３ａは、Play_List２７に記述される最新のSegment（次のSegment）のアップロードを開始すると（Ｓ１４）、変数「i」を「i+1」に更新して（Ｓ１５）、記憶装置２２にSegment[i]の生成を開始する（Ｓ１６）。ここで、ファイル生成時においては、アップロードの開始状態なので、Segment[i]のファイル長は実質的にゼロである。
また、アップロード処理部２３ａは、Segment[i]の生成の開始に伴い（Ｓ１６）、ダウンロード処理部２４に対してシグナルを送る。このシグナルは、Segment[i]の生成を開始した事を示すものであり、これによりSegment[i]のダウンロードが可能になる。つまり、本実施形態では、アップロード処理部２３ａは、Segmentのアップロードの前にSegmentのURLをPlay_List２７に記述するので、実際のSegment[i]のアップロードの開始を知らせるものである。また、アップロード処理部２３は、Play_List２７に、Segment[i+1]のURLを追記する（Ｓ１７）。これにより、Play_List２７には、次に入力される予定のSegmentのURLが追記される。
そして、逐次、Segment[i]のデータがアップロードされてくるので、アップロード処理部２３は、このデータを記憶装置２２のSegment[i]に追記（格納）する（Ｓ１８）。アップロード処理部２３ａは、Segment[i]の全てのデータのアップロード、及び書き込みが完了すると、映像送信端末１０に対して完了のレスポンス（具体的には、HTTP_Status_200_OK）を返す（Ｓ１９）。そして、アップロード処理部２３は、Ｓ１３に戻り、次のSegmentのアップロード要求（HTTP_PUTリクエスト）を待ち、以上の動作を繰り返す。
なお、ライブ映像終了時には、映像送信端末１０から終了を指示するHTTP_PUTリクエストが送られてくるので、アップロード処理部２３は、これを受信し、Play_List２７に、終了マークを付ける。また、この終了の指示は、ダウンロード処理部２４ａにも送信される。
（ダウンロード処理部２４ａの動作）
図５（ａ）は、配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、図５（ｂ）は、映像視聴端末の主制御部の動作を示すフローチャートである。図５（ａ）（ｂ）を用いて、配信サーバ２０ａが映像視聴端末３０にライブ映像データを配信する配信処理について説明する。
まず、映像視聴端末３０の主制御部３２は、HTTP_Client３１に指示し、HTTP_GETリクエストにより配信サーバ２０ａからPlay_List２７を取得することについて要求する（Ｓ３１）。これにより、配信サーバ２０ａは、Play_List２７を映像視聴端末３０に送信する（Ｓ２１）。このとき、映像送信端末１０がSegment[i-1]をアップロード中の場合、アップロード側フローの処理に従って、Play_List２７にはSegment[i]までのURLが記述されている。
次に、主制御部３２は、再生開始Segmentを選択し、選択されたSegment番号を変数「i」とする（Ｓ３２）。特に、本実施形態のライブ映像配信では、主制御部３２は、Play_List２７に列挙されている複数のSegmentから最新のSegmentを選択することにし、この選択された最新のSegmentをSegment[i]とする。
次に、主制御部３２は、HTTP_Client３１にHTTP_GETリクエストの指示を行い、配信サーバ２０ａに対して最新のSegment[i]のダウンロード要求（配信要求）を送信する（Ｓ３３）。配信サーバ２０ａのダウンロード処理部２４は、映像視聴端末３０からSegment[i]のダウンロード要求を受信する（Ｓ２２）。
しかしながら、ダウンロード処理部２４は、Play_List２７に記述される最新のSegment[i]は、まだアップロードが始まっていないので、ダウンロード要求に対して、何も応答を返さないで保留する（従来の配信サーバであれば、そのSegment[i]は記憶装置２２に存在しないので、配信サーバから再生端末に対してHTTP_Status_404_Not_Found等のエラーを返すことになる。）。つまり、ダウンロード処理部２４は、記憶装置２２にSegment[i]が生成されるまで待機し（Ｓ２３）、アップロード処理部２３ａから、Segment[i]が記憶装置２２に生成されたことを示すシグナル（図４のＳ１６参照）の受信することによりSegment[i]の生成が開始されたことを検出する（Ｓ２４）。
そして、ダウンロード処理部２４は、アップロード処理部２３からシグナルを受けた後、映像視聴端末３０に対してレスポンス（例えば、HTTP_Status_200_OK）を返す（Ｓ２５）。そして、ダウンロード処理部２４は、逐次、記憶装置２２に書き込まれてくるSegment[i]のデータを、記憶装置２２から読み出しつつ、読み出されたSegment[i]のデータを映像視聴端末３０に対してダウンロードさせる（Ｓ２６）。そして、Segment[i]のダウンロードが完了する（Ｓ２７）。
映像視聴端末３０は、配信サーバ２０ａからHTTP_GETリクエストに対する応答（HTTP_Status_200_OK）が返り（Ｓ３４）、次いで、Segment[i]のデータが逐次ダウンロードされてくるので、主制御部３２がダウンロードされたSegment[i]のデータをTS_Demuxer３３に入力する（Ｓ３５）。このとき、一般的に、映像視聴端末３０は、映像の安定化のためにデータをバッファリングするが、それを最小限の時間にする。
主制御部３２は、Segment[i]のデータの全ての処理を行い、TS_Demuxer３３に入力し終わったら（Ｓ３６）、Play_List２７にSegment[i+1]のURLが記述されているか否かを判定する（Ｓ３７）。もし、Play_List２７にSegment[i+1]のURLが含まれていない場合（Ｓ３７でＮｏ）、主制御部３２は、Play_List２７の取得を、Segment[i+1]のURLが含まれるまで繰り返す。つまり、主制御部３２は、配信サーバ２０ａの記憶装置２２に次のSegmentのURLが追記されるまでPlay_List２７の取得を繰り返す（Ｓ３８）。
一方、主制御部３２は、Play_List２７にSegment[i+1]のURLが記述されていれば（Ｓ３７でＹｅｓ）、変数「i」を「i+1」に１つインクリメントして（Ｓ３９）、処理をＳ３３に戻す。そして、主制御部３２は、配信サーバ２０ａに対してSegment[i]のダウンロード要求（配信要求）を送信する。
（過去のコンテンツ再生）
映像視聴端末３０は、Play_List２７の送信要求後のライブ映像のみならず、既録のコンテンツを含んで再生することができる。図５（ｂ）の主制御部３２のフローチャートを用いて、既録のコンテンツを含んだライブ映像の再生について説明する。
映像視聴端末３０は、Play_List２７の送信要求を配信サーバ２０に行い、Play_List２７を取得する（Ｓ３１）。そして、映像視聴端末３０は、Play_List２７を用いて、再生開始セグメントの選択を行う（Ｓ３２）。配信サーバ２０から送信されるPlay_List２７は、既録のコンテンツを含んで、ライブ画面の次のSegmentのURLまで列挙されている。このため、操作者は、表示パネルのタッチスイッチ等を介して任意のSegment[i]を再生開始セグメントとして選択する。映像視聴端末３０は、選択されたSegment[i]の配信要求（例えば、HTTP_GET）を行い（Ｓ３３）、HTTP_GETに対して配信サーバ２０から応答（200_OK）が返ってきたら（Ｓ３４）、Segment[i]のダウンロードを行い、Segment[i]をTS_Demuxer３３に入力する（Ｓ３５）。
そして、映像視聴端末３０は、Segment[i]の全ての処理を終えると（Ｓ３６）、既録のコンテンツの場合は、Play_List２７に、次のSegment[i+1]のURLがあるので（Ｓ３７でＹｅｓ）、変数「i」を「i+1」に１つインクリメントして（Ｓ３９）、次のSegment[i]の配信要求を行う（Ｓ３３）。これらの処理を繰り返して、最新画面（ライブ画面）になると、映像視聴端末３０は、Play_List２７にSegment[i+1]のURLがなくなるので（Ｓ３７でＮｏ）、Play_List２７を取得する（Ｓ３８）。この取得したPlay_List２７には、新しい画面のSegment[i+1]のURLが追記されているので、Ｓ３７でＹｅｓと判定され、Ｓ３９を介して、Ｓ３３でSegment[i]の配信要求を行う。
図６は、配信サーバの機能であるエラー処理部の動作を示すフローチャートである。
このフローは、通信障害、過大な処理時間の経過や、端末の異常情報等のエラーが発生したときに、割込みにより実行される。ここで過大な処理時間の経過と見なす時間は、少なくともSegment２６の時間幅よりも十分に長い時間である必要がある。
エラー処理部２８ａ（図２参照）は、前記したエラーが発生したときに、エラーを映像送信端末１０や映像視聴端末３０に送信し（Ｓ２９）、エラー処理が終了する。
（効果の説明）
図７は、本発明の第１実施形態であるコンテンツ配信システムのシーケンス図である。図７のシーケンス図、及び図４，５のフローチャートを用いて、コンテンツ配信システム１の全体の動作を説明する。
配信サーバ２０ａは、映像送信端末１０からライブ映像コンテンツを時分割した時分割コンテンツ（・・・, Segment[N]，Segment[N+1]，Segment[N+2]，・・・）を逐次アップロードし、アップロードされた時分割コンテンツを記憶装置２２に逐次格納する。
配信サーバ２０ａは、Segment[N]を格納し終わり、Segment[N+1]のファイルを生成するときに（Ｓ１６）、Segment[N+1]の次に入力される予定のSegmentであるSegment[N+2]のURLをPlay_List２７に追記する（Ｓ１７）。
配信サーバ２０ａのアップロード処理部２３ａがSegment[N+1]をアップロードしているときに（Ｓ１８）、ダウンロード処理部２４は、Play_List２７の送信要求（HTTP_GETリクエスト（Ｔ１））を映像視聴端末３０から受信すると、Segment[N+2]のURLが記述されたPlay_List２７を映像視聴端末３０に送信するとする（Ｓ２１）。
ここで、配信サーバ２０ａのアップロード処理部２３ａがSegment[N+1]をアップロードしているときに（Ｓ１８）、映像視聴端末３０は、Segment[N+2]の配信要求（HTTP_GETリクエスト（Ｔ２））を配信サーバ２０ａに送信する（Ｓ３３）。
そして、ダウンロード処理部２４は、Segment[N+2]の配信要求（例えば、HTTP_GETリクエスト）を映像視聴端末３０から受信すると（Ｓ２２）、HTTP_Status_404_Not_Found等のエラーの返信をせず、Segment[N+2]の配信を待機して（Ｓ２３）、Segment[N+2]が記憶装置２２に生成されてから（Ｓ２４）、応答（例えば、200_OK（Ｔ３））を映像視聴端末３０に返す（Ｓ２５）。
配信サーバ２０ａは、アップロード処理部２３ａがSegment[N+3]のURLをPlay_List２７に追記し（Ｓ１７）、Segment[N+2]を受信しつつ記憶装置２２に格納する。この記憶装置２２への格納とほぼ同時進行して、ダウンロード処理部２４は、記憶装置２２からSegment[N+2]を読み出して映像視聴端末３０にダウンロードさせる（Ｓ２６）。
図８は、本発明の第１実施形態である配信サーバによるセグメントの配信状態を示す図であり、映像送信端末１０がSegment[N+1]の６秒目までをアップロードしているときの状態を実線で示している。また、Segment[N+1]の６秒目以降と、次にアップロードされる予定のSegment[N+2]を破線で示している。そして、このとき映像視聴端末３０が再生を開始すると、Segment[N+2] から再生を始めることを示している。なお、各Segmentの時間幅は10秒とする。
再び、図７に戻り、配信サーバ２０ａは、Segment[N+2]のファイルを記憶装置２２に生成してから（Ｓ２４）、応答（例えば、200_OK（Ｔ３））を映像視聴端末３０に返すので（Ｓ２５）、記憶装置２２への格納とほぼ同時進行して映像視聴端末３０での再生が行われる。つまり、映像送信端末１０がSegment[N+2]の先頭をアップロードし始めるタイミングと、映像視聴端末３０がSegment[N+2]の先頭を再生し始めるタイミングとの時間差が極めて小さくなる。また、映像視聴端末３０は、極短時間のバッファリングのみをして、再生を開始することにより、映像送信端末１０が直前に送信したデータが、映像視聴端末３０で直ぐに再生される状態になり、低遅延再生が実現される。
映像視聴端末３０は、Segment[N+2]をTS_Demuxer３３に入力し（Ｓ３５）、Video_Decoder３４、Renderer３５、ブラウザ３６を介して、表示パネル３７に映像を表示する。映像視聴端末３０は、Segment[N+2]を全て処理すると（Ｓ３６）、Play_List２７の送信要求（HTTP_GET）を配信サーバ２０ａに行い、Segment[N+3]のURLが追記されたPlay_List２７を取得する（Ｓ３８）。そして、映像視聴端末３０は、Segment[N+3]の配信要求（HTTP_GET）を配信サーバ２０ａに行い（Ｓ３３）、これら処理（Ｓ３３〜Ｓ３９）を繰り返す。
このように、本実施形態のコンテンツ配信システム１は、配信サーバ２０のみの工夫により、映像視聴端末３０の再生開始のタイミングをコントロールしている。このため、映像視聴端末３０は、従来のHLS再生クライアントを使うことができる。なお、本実施形態は、配信サーバ２０ａが応答を保留するだけ、映像視聴端末３０がSegmentの配信要求を出してから実際に再生を開始するまでの時間が長くなるので、Segmentの長さを適切に設定するのがよい。
（第２実施形態）
第１実施形態では、映像送信端末１０と配信サーバ２０とを分離し、映像送信端末１０からHTTP_PUTリクエストにより、Segmentが配信サーバ２０ａにアップロードされるとしたが、配信サーバ２０に、映像送信端末１０を介することなく、直接ビデオカメラを接続することができる。
図９は、本発明の第２実施形態である配信サーバ、及び映像視聴端末の内部構成図である。ここで、映像視聴端末３０は、図２の内部構成図と同一である。
配信サーバ２０ｂは、直接、ビデオカメラ１１を接続し、配信サーバ２０ｂの内部に、映像送信端末１０（図２）の機能である、Video_Encoder１２、TS_Muxer１３、Segmenter１４を実装している。また、映像送信端末１０のアップロード処理部２３は、入力処理部２３ｂに変更されている。入力処理部２３ｂは、HTTP_Server２１を介することなく、直接、Segmenter１４からSegmentの入力を受け付ける。つまり、制御部２５ｂは、プログラムを実行することにより、Video_Encoder１２、TS_Muxer１３、Segmenter１４、入力処理部２３ｂダウンロード処理部２４、HTTP_Server２１、エラー処理部２８ａの機能を実現している。
（第３実施形態）
第１実施形態は、配信サーバ２０ａの制御部２５ａをアップロード処理部２３ａとダウンロード処理部２４ａとして機能させたが、制御部をPlay_List２７を生成処理する機能部とSegment２６を配信する機能部として実現させることができる。
図１０は、本発明の第３実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。
制御部２５ｃは、プログラムを実行することにより、HTTP_Server２１とエラー処理部２８ａとインデックスファイル処理部２９ａと配信処理部２９ｂとの機能を実現する。
インデックスファイル処理部２９ａは、映像視聴端末３０からPlay_List２７の送信要求を受信した場合、受信予定（記憶装置２２に格納予定でもある。）のSegment２６のURLをPlay_List２７に追記して、追記されたPlay_List２７を映像視聴端末３０に返信する。
配信処理部２９ｂは、追記されたURLのSegment２６の配信要求を受信した場合、その配信要求を受信したSegment２６の受信開始前は、Segment２６の配信を保留し、Play_List２７に追記されたURLのSegment２６の受信開始を確認してから、配信要求に応答して、受信されたSegment２６を映像視聴端末３０に配信する。
（第４実施形態）
前記各実施形態のコンテンツ配信システムは、ＨＬＳのプロトコルを前提にし、映像視聴端末３０が配信サーバ２０に対して、コマンド「HTTP_GET」を逐次送信していたが、映像視聴端末３０が再生開始を配信サーバ２０に指示するのみで、コンテンツのダウンロードを行うこともできる。
図１１は、本発明の第４実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。ここで、ビデオカメラ１１、映像送信端末１０、及び映像視聴端末３０は、前記各実施形態のものと同一であり、配信サーバ２０が配信サーバ２０ｄ（２０ｄａ）に変更されている。
本実施形態の配信サーバ２０ｄは、第１実施形態の配信サーバ２０ａ（図２）に対して、Play_List２７がSegment_List４１に変更されている点が主な相違点である。また、配信サーバ２０ｄは、制御部２５ａが制御部２５ｄに変更され、アップロード処理部２３ａがアップロード処理部２３ｄに変更され、ダウンロード処理部２４ａがダウンロード処理部２４ｄ（２４ｄａ）に変更され、エラー処理部２８ａがエラー処理部２８ｂに変更されている点でも相違する。
Segment_List４１は、Segment[i]のURLを記載するリストであり、受信（アップロード）時であって、Segment[i]が生成されたときにURLが追記される。エラー処理部２８ｂは、過大な処理時間の経過や、通信障害、端末の異常情報等が発生したときに機能するものである。本実施形態では、コマンド「HTTP_GET」の逐次送受信を行わないので、エラー処理部２８ｂは、Segment２６の時間幅よりも十分に長い時間経過したときにエラーと判定する必要がない。
図１２は、本発明の第４実施形態である配信サーバの機能であるアップロード処理部の動作を示すフローチャートである。
アップロード処理部２３ｄは、第１実施形態のアップロード処理部２３ａ（図４）に対して、「Play_List」（Ｓ１２，Ｓ１７）を「Segment_List」（Ｓ６２，Ｓ６７）に変更している点で相違する。つまり、アップロード処理部２３ｄは、Segment_List４１にSegment[0]のURLを記述し（Ｓ６２）、アップロード要求が行われ(Ｓ６３)、次のSegment[0]のアップロードを開始したときに（Ｓ６４）、Segment[0]を記憶装置２２に生成する（Ｓ６６）。また、アップロード処理部２３ｄは、Segment_List４１にSegment[0]のURLを追記し（Ｓ６７）、Segment[0]を受信しつつ、記憶装置２２に追記する（Ｓ６８）。つまり、アップロード処理部２３ｄは、Segment[i]の受信を開始する前に、Segment_List４１にSegment[i+1]のURLを追記する。そして、アップロード処理部２３ｄは、アップロード完了まで、Segment[i]の受信、書き込みを繰り返す。
図１３（ａ）は本発明の第４実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、図１３（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。
ダウンロード処理部２４ｄ（２４ｄａ）は、Segment_List４１から最新のSegmentを取得し、それをSegment[N]とする（Ｓ７１）。ダウンロード処理部２４ｄａは、変数ｉをＮに設定する（Ｓ７２）。映像視聴端末３０の主制御部３２は、HTTP_Client３１（図１１）を介して、対象ファイルについての配信要求（HTTP_GET）を行う（Ｓ９１）。ダウンロード処理部２４ｄａは、映像視聴端末３０からの対象ファイルのダウンロード要求を受信する（Ｓ７３）。ダウンロード処理部２４ｄａは、映像視聴端末３０にレスポンス（200_OK）を返す（Ｓ７５）。映像視聴端末３０の主制御部３２は、配信要求（Ｓ９１）に対する応答を受信する（Ｓ９３）。
ダウンロード処理部２４ｄａは、変数iを１つ増加する演算（i=i+1）を行い（Ｓ７６）、Segment[i]が記憶装置２２に生成されるまで待機する（Ｓ７７）。ダウンロード処理部２４ｄａは、アップロード処理部２３ｄからSegment[i]が記憶装置２２に生成されたことを示すシグナルの受信により（Ｓ７８）、Segment[i]=Segment[N+1]を記憶装置２２から読み出しつつ、映像視聴端末３０にダウンロードさせ（Ｓ８１）、Segment[i] =Segment[N+1]のダウンロードが完了する（Ｓ８１）。
ここで、ダウンロード処理部２４ｄａは、Segment[N+1]を映像視聴端末３２ｄにダウンロードさせてもHTTP_Server２１の接続を切らない。
Ｓ８１のとき、映像視聴端末３０の主制御部３２は、Segment[i]をTS_Demuxer３３（図２）に入力し（Ｓ９４）、Segment[i]を全て処理するまでＳ９４の処理を繰り返す（Ｓ９５）。つまり、ダウンロード処理部２４ｄａは、Segment[N+2]がアップロードされるのを待ち、それがアップロードされると、引き続きSegment[N+2]を返す。このとき、HTTP上では、Segment[N+1]にSegment[N+2]が連結されるようになる。そして、Segment[N+3]、Segment[N+4]・・・も同様に行われる。ダウンロード処理部２４ｄａは、Segment_List４１の最後のSegmentを返して、かつ、Segment_List４１に終了マークが書き込まれていれば、HTTP接続を閉じる。このようにすると、映像視聴端末３０は、Segmentとして認識することができないが、Segment[N+1]に対応するデータから始まる、一連のＴＳデータがHTTPにより取得できることになる。
図１４は、本発明の第４実施形態であるコンテンツ配信システムのシーケンス図である。
図１４のシーケンス図は、図７のシーケンス図に比較して、映像視聴端末３０から配信サーバ２０ｄａに配信要求（HTTP_GET）を行うと、直ちに返信（200_OK）が行われる点で相違する。また、図７のシーケンス図は、Segment[N+1],Segment[N+2],・・・の送受信（ダウンロード）終了後、200_OKの返信、及びHTTP_GETの配信要求を逐次行っていたが、図１４のシーケンス図では、Segment[N+1],Segment[N+2],・・・の送受信（ダウンロード）終了後、返信（200_OK）、及び配信要求（HTTP_GET）を逐次行っていない点でも相違する。
以上説明したように、本実施形態の配信サーバ２０ｄａは、ダウンロード処理部２４ｄａは、映像視聴端末３０からのライブ映像取得要求（HTTP_GET）に対して、現在アップロードしているSegment[N]から返しはじめるのではなく、接続をいったん保留して、Segment[N+1]がアップロードされ始めるタイミングでアップロード処理部２３（図１１，１２）が発生する通知を受けてからSegment[N+1]を映像視聴端末３０に対して返し始める。これにより、映像送信端末１０ａがSegment[N+1]の先頭をアップロードし始めるタイミングと、映像視聴端末３０がSegment[N+1]の先頭をダウンロードし始めるタイミングとの時間差が極めて小さくなる。
さらに、映像視聴端末３０が極短時間のバッファリングのみを行い、再生を開始することにより、映像送信端末１０ａが直前に送信したデータは、映像視聴端末３０で直ぐに再生される状態になる。つまり、本実施形態の配信システム１（図１）は、低遅延再生が実現される。また、本実施形態の配信システム１は、配信サーバ２０ｄのみの工夫により、映像視聴端末３０の再生開始のタイミングをコントロールしている。このため、映像視聴端末３０は従来と同様の再生クライアントを使うことができる。
（第５実施形態）
前記第４実施形態の配信サーバ２０ｄａは、映像視聴端末３０から配信要求(HTTP_GET)を受信すると、直ちに、返信（200_OK）を行い、次のSegment[N+1]が記憶装置２２に生成されるまで、待機していたが、配信要求(HTTP_GET)を受信し、次のSegment[N+1]が記憶装置２２に生成されてから、返信（200_OK）を行うこともできる。
図１５（ａ）は本発明の第５実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、図１５（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。なお、アップロード処理部２３ｄの動作は、図１２のフローチャートと同一である。また、本実施形態の配信システムの構成図は、図１１と同様であり、配信サーバ２０ｄａが、配信サーバ２０ｄｂに変更され、ダウンロード処理部２４ｄａがダウンロード処理部２４ｄｂに変更されている。
ダウンロード処理部２４（２４ｄｂ）は、Segment_List４１（図１１）から最新のSegmentを取得し、それをSegment[N]とする（Ｓ７１）。ダウンロード処理部２４ｄｂは、変数ｉをＮに設定する（Ｓ７２）。映像視聴端末３０の主制御部３２は、HTTP_Client３１（図２）を介して、対象ファイルについての配信要求（HTTP_GET）を行う（Ｓ９１）。そして、ダウンロード処理部２４ｄｂは、映像視聴端末３０からの対象ファイルのダウンロード要求を受信する（Ｓ７３）。
次に、ダウンロード処理部２４ｄｂは、変数iを１つ増加する演算（i=i+1）を行い（Ｓ７６）、Segment[i]が記憶装置２２に生成されるまで待機する（Ｓ７７）。そして、ダウンロード処理部２４ｄｂは、アップロード処理部２３ｄからSegment[i]が記憶装置２２に生成されたことを示すシグナルを受信し、Segment[i]が記憶装置２２に生成されたと認識する（Ｓ７８）。次に、ダウンロード処理部２４ｄｂは、変数iが(N+1)になっているか否かの判定を行う（Ｓ７９）。
変数iが(N+1)になっていれば（Ｓ７９でＹｅｓ）、ダウンロード処理部２４ｄｂは、映像視聴端末３０にレスポンス（200_OK）を返す（Ｓ８０）。つまり、映像視聴端末３０の主制御部３２は、配信要求（Ｓ９１）に対する応答を受信することになる（Ｓ９３）。
ダウンロード処理部２４ｄｂは、映像視聴端末３０にレスポンス（200_OK）を返したり（Ｓ８０）、Ｓ７９の判定で、変数iが(N+1)になっていたりしなければ（Ｓ７９でＮｏ）、Segment[i]を記憶装置２２から読み出しつつ、映像視聴端末３０にダウンロードさせ（Ｓ８１）、Segment[i]のダウンロードが完了する（Ｓ８２）。ここで、映像視聴端末３０の主制御部３２は、Segment[i]をTS_Demuxer３３（図２）に入力しつつ（Ｓ９４）、Segment[i]を全て処理するまでＳ９４の処理に戻す（Ｓ９５）。ここで、ダウンロードは、Segmentのアップロードに合わせて、長時間続くものであるので、映像視聴端末３０は、ダウンロード、Demux、デコード、及び再生を平行して実行するストリーミング再生を行う必要がある。
図１６は、本発明の第５実施形態であるコンテンツ配信システムのシーケンス図である。
図１６のシーケンス図は、図１４のシーケンス図に比較して、Segment[N+1]のダウンロード直前にHTTP_GETに対する応答（200_OK）が実行されている点で相違する。
（第６実施形態）
前記１，２，３実施形態のコンテンツ配信システムは、ＨＬＳのプロトコルを前提にしていたが、ＴＳ（MPEG2_Transport_Stream）を前提にすることができる。このため、本実施形態の映像送信端末１０は、配信サーバ２０に対して、セグメントに分割した送信を行わない。
図１７は、本発明の第６実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。
本実施形態の映像送信端末１０ｅは、前記各実施形態の映像送信端末１０ａ（図２）に比較して、Segmenter１４が削除されている点で相違する。また、本実施形態の配信サーバ２０ｅの制御部２５ｅは、配信サーバ２０ａの制御部２５ａ（図２）に比較して、ＴＳ解析部４４を備え、エラー処理部２８ａがエラー処理部２８ｂに変更されている点で相違する。また、本実施形態の配信サーバ２０ｅの記憶装置２２は、配信サーバ２０ａの記憶装置２２（図２）に比較して、Segment２６の代わりに、ＴＳファイル４２を格納し、Play_List２７の代わりにKeyFrame_List４３を格納している点で相違する。
ＴＳファイル４２は、複数のKeyFrame（I-Picture）を有するコンテンツのファイルである。ここで、任意のKeyFrameから次のKeyFrameの前までのデータは、一般的には、GOP（Groupe Of Picture）を意味する。このGOPは、最低１つのI-Pictureを含む複数のPictureからなるデータ集合のことであるが、ここでは、１つのI-Pictureが先頭に配置されているものとする。
ＴＳ解析部４４は、ＴＳファイル４２を受信したときに、KeyFrameの位置（例えば、ファイルの先頭からのbyte数）を解析するものである。KeyFrame_List４３は、KeyFrameの位置が記載されたテーブルであり、KeyFrameを受信する毎に、その位置情報が追記される。
図１８は、本発明の第６実施形態である配信サーバの機能であるアップロード処理部の動作を示すフローチャートである。
アップロード処理部２３ｅは、変数iをi=0に設定し（Ｓ１０１）、受信する「ＴＳ」を追記していくＴＳファイルを記憶装置２２に生成する（Ｓ１０２）。そして、アップロード処理部２３ｅは、映像送信端末１０が送信する「ＴＳ」の断片を受信すると（Ｓ１０３）、ＴＳ解析部４４に「ＴＳ」の解析を行わせる（Ｓ１０４）。ここでの「ＴＳ」の断片とは、１回の受信で受信できたByte単位のデータであり、TSフォーマット上の何らかの単位を意味しない。
アップロード処理部２３ｅは、ＴＳ解析部４４の解析結果により、KeyFrame を発見したか否かを判別する（Ｓ１０５）。KeyFrame を発見したのであれば（Ｓ１０５でＹｅｓ）、アップロード処理部２３ｅは、KeyFrame List４３にKeyFrame[i]（=KeyFrame[0]）の位置を追記する（Ｓ１０６）。このとき、アップロード処理部２３ｅは、ダウンロード処理部２４ｄにシグナルを送信する。次いで、アップロード処理部２３ｅは、変数iを１増加させ、i=i+1に設定する（Ｓ１０７）。
Ｓ１０５において、KeyFrameを発見しなかった場合（Ｓ１０５でＮｏ）、あるいは、Ｓ１０８の処理後、アップロード処理部２３ｅは、受信した「ＴＳ」の断片をＴＳファイル４２に追記する（Ｓ１０８）。
そして、アップロード処理部２３ｅは、Ｓ１０３の処理に戻り、次の「ＴＳ」の断片の受信を待ち、同様の処理を繰り返す。つまり、アップロード処理部２３ｅは、この処理を繰り返すことにより、KeyFrame[2]，KeyFrame[3]，・・・の位置の解析、KeyFrame_List４３への追記（Ｓ１０６）、及びコンテンツの追記（Ｓ１０８）を繰り返す。なお、アップロード処理部２３ｅは、アップロードリクエスト（HTTP_PUT）が終了したときにアップロードを終了する。
図１９（ａ）は本発明の第６実施形態である配信サーバの機能であるダウンロード処理部の動作を示すフローチャートであり、図１９（ｂ）は映像視聴端末の主制御部の動作を示すフローチャートである。
ダウンロード処理部２４ｅは、KeyFrame_List４３から最新のKeyFrameを調べる。（Ｓ１１１）。そして、ダウンロード処理部２４ｅは、最新のKeyFrameがN番目のKeyFrameであれば、変数iをi=Nに設定する（Ｓ１１２）。
ダウンロード処理部２４ｅは、映像視聴端末３０から対象ファイルについて配信要求（HTTP_GET）を受信する（Ｓ１１３）。このとき、映像視聴端末３０の主制御部３２は、HTTP_Client３１（図１７）を介して、配信要求を配信サーバ２０ｅ（図１７）に送信している。そして、ダウンロード処理部２４ｅは、変数iを１つ増加し、i=i+1に設定し（Ｓ１１４）、ＴＳファイル４２にKeyFrame[i]＝KeyFrame[N+1]の生成が開始されるまで待機する（Ｓ１１５）。さらに、アップロード処理部２３ｅからのシグナル受信により、ＴＳファイル４２にKeyFrame[i]から始まるコンテンツ（例えば、GOP[N+1]（図２０参照））が追記される（Ｓ１１６）。
ダウンロード処理部２４ｅは、映像視聴端末３０に応答（200_OK）を返し（Ｓ１１８）、KeyFrame_List４３に記述されたKeyFrame[i]=KeyFrame[N+1]から始まるコンテンツをＴＳファイル４２から読み出しつつ、映像視聴端末３０にダウンロードさせる（Ｓ１１９）。
このとき、映像視聴端末３０の制御部３２は、Ｓ２２０の配信要求（HTTP_GET）に対する配信サーバ２０からの応答（200_OK）を受信し（Ｓ２２２）、コンテンツをTS_Demuxer３３に入力し（Ｓ２２３）、再生を行う。そして、ダウンロード処理部２４ｅは、KeyFrame_List４３に記述された KeyFrame[N+1]から始まるコンテンツのダウンロードが完了する。
映像視聴端末３０の制御部３２は、 KeyFrame[N+1]から始まるコンテンツを全て処理し終えたら、ダウンロードが完了する（Ｓ２２４）。
これらの処理により、KeyFrame[N+1]以上のコンテンツのダウンロードが行われる。
図２０は、本発明の第６実施形態であるコンテンツ配信システムのシーケンス図である。
本実施形態の配信システムのシーケンス図は、図７のシーケンス図に比較して、映像送信端末１０と配信サーバ２０との間の送受信が、Segment[N]，Segment[N+1]，・・・の送受信からKeyFrame[N]，KeyFrame[N+1]，KeyFrame[N+2]，・・・から始まるコンテンツのＴＳ送信になり、HTTP_PUTリクエストやHTTP_STATUS_200_OKレスポンスが削除されている点で相違する。
また、映像視聴端末３０が配信サーバ２０ｅに行う配信要求（HTTP_GETリクエスト）は、「Segmentの配信要求」ではなく、再生を行う「対象ファイルの配信要求」（Ｔ１，Ｔ２）である。また、映像視聴端末３０は、配信サーバ２０ｅに対して行う２回目以降の配信要求（HTTP_GETリクエスト）、及びこの配信終了を示すレスポンスが削除されている。
つまり、配信サーバ２０ｅは、コンテンツを映像送信端末１０ｅからＴＳ受信するときに、KeyFrameの位置の解析を逐次行い、解析を行ったKeyFrame（KeyFrame[N]，KeyFrame[N+1]，KeyFrame[N+2]，・・・）から始まるコンテンツ（例えば、GOP[N]，GOP[N+1]，GOP[N+2]，・・・）を記憶装置２２のＴＳファイル４２に追記する。言い換えれば、映像送信端末１０ｅは、配信サーバ２０ｅに対して、KeyFrame[N]，KeyFrame[N+1]，KeyFrame[N+2]，・・・から始まるコンテンツのＴＳ送信（配信，アップロード）を逐次行っているように見える。なお、配信サーバ２０ｅは、KeyFrame[N]，KeyFrame[N+1]，KeyFrame[N+2]，・・・から始まるコンテンツのＴＳ受信（アップロード）終了毎に、映像送信端末１０ｅに対して「ＴＳ受信完了通知」をそれぞれ行っている。
一方、映像視聴端末３０は、配信サーバ２０ｅに対して、対象ファイルの配信要求（HTTP_GET）を行う。配信サーバ２０ｅは、対象ファイルの配信要求がKeyFrame[N]の受信時であれば、その受信完了まで待機し、次のKeyFrame[N+1]の受信時に、200_OKレスポンスを映像視聴端末３０に送信する。映像視聴端末３０は、200_OKレスポンスの受信により、KeyFrame[N+1]，KeyFrame[N+2]，・・・から始まるコンテンツの受信（ダウンロード）及び再生を逐次行う。
以上説明したように、本実施形態の配信サーバ２０ｅは、映像視聴端末３０からのライブ映像取得要求（HTTP_GET）に対して、現在の最新のKeyFrameから返しはじめるのではなく、接続をいったん保留して、KeyFrame[N+1]が検出されるタイミングでアップロード処理部２３ｅが出力する通知を待ち、その通知を受けてからKeyFrame[N+1]で示される位置からＴＳファイルを返し始める。これにより、映像送信端末１０ｅがKeyFrame[N+1]に対応するデータをアップロードし始めるタイミングと、映像視聴端末３０がKeyFrame[N+1]に対応するデータをダウンロードし始めるタイミングとの時間差が極めて小さくなる。
さらに、映像視聴端末３０は、極短時間のバッファリングのみをして、再生を開始することにより、映像送信端末１０ｅが直前に送信したデータが、映像視聴端末３０で直ぐに再生される状態になる。つまり、本実施形態の配信システム１は、低遅延再生が実現される。
（第７実施形態）
図２１は、本発明の第７実施形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。
配信サーバ２０ｆ（図２１）は、配信サーバ２０ｅ（図１７）に比較して、ビデオカメラ１１、及び映像送信端末１０ｅが削除されており、配信サーバ２０ｆにVideo_Source１６が接続されている点で相違する。このため、配信サーバ２０ｆは、Video_Source１６がVideo_Encoder１２、TS_Muxer１３、及びSegmenter１４を介して、映像信号を入力する入力処理部２３ｂを備えている点でも相違する。また、配信サーバ２０ｆは、Segmenter１４の出力が入力処理部２３ｂの入力に接続されており、HTTP_Client１５、及びHTTP_Server２１を介していない点でも相違する。
Video_Source１６は、ビデオコンテンツが格納されたＤＶＤ（Digital_Versatile_Disc）やＨＤＤ(Hard_Disk_Drive)等であり、MPEGデータを出力する。Video_Encoder１２、TS_Muxer１３は、第１実施形態で説明しているので、説明を省略する。Segmenter１４は、TS_Muxer１３が出力した映像信号をKeyFrame（I-Picture）から始まるコンテンツ毎に分割する点で、第１実施形態と相違する。
入力処理部２３ｂは、分割されたKeyFrameから始まるコンテンツを連結しつつＴＳファイル４２に格納する。また、入力処理部２３ｂは、それぞれのKeyFrameデータのKeyFrameの位置が記載されるKeyFrame_List４３を記憶装置２２に生成し、KeyFrameが入力される毎にKeyFrameの位置を追記する。
ダウンロード処理部２４ａは、KeyFrame_List４３の位置情報に基づいて、記憶装置２２のＴＳファイル４２からKeyFrameから始まるコンテンツ毎に読み出して、読み出したコンテンツをHTTP_Server２１に引き渡す。
図２２は、本発明の第７実施形態の他の利用形態である映像送信端末、配信サーバ、及び映像視聴端末の内部構成図である。
配信サーバ２０ｇは、配信サーバ２０ｆ（図２１）に比較して、Segmenter１４が削除され、TS_Muxer１３が出力するＴＳ信号(KeyFrameから始まるコンテンツ)が入力処理部２３ｂに入力されている。また、配信サーバ２０ｇは、入力処理部２３ｂに接続されるＴＳ解析部４４を備え、ＴＳ解析部４４がKeyFrameから始まるコンテンツ毎にKeyFrameの位置を解析する。
（比較例）
図２３は、比較例のアップロード処理部の動作を示すフローチャートであり、図２４は、比較例のダウンロード処理部の動作を示すフローチャートである。同一符号を付したものは、前記実施形態と同様の装置であり、同様の処理を実行する。図２３，２４は、第１実施形態の動作を示すフローチャートである図４、及び図５（ａ）と比較するための図である。この比較例では、配信サーバ２０ａは、配信サーバ２０ｆ（図２５参照）に変更されているが、映像視聴端末３０の内部構成は、前記第１実施形態の内部構成と同一である。
図２３のアップロード処理部２３ｆの動作を示すフローチャートは、図４と比較して、Ｓ１２に相当するものが無く、Ｓ１７の「Play_ListにSegment[i+1]を追記する。」がＳ４７では、「Play_ListにSegment[i]を追記する。」に変更されている。つまり、Ｓ４６において、Segment[-1+1]＝Segment[0]が生成されると、Ｓ４７において、Play_List２７に、Ｓ４８で受信と同時に格納されるSegment[0]のURLがPlay_List２７に追記される。そのため、作成されていないSegmentのURLがPlay_List２７に追記されることがないので、図４に示すように、ダウンロード処理部に対してシグナル信号を送信しなくても、HTTP_Status_404_Not_Found等のエラーとなることがない。
図２４のダウンロード処理部２４ｆのフローチャートは、図５（ａ）と比較して、Ｓ２３，Ｓ２４に相当する処理が無い。つまり、ダウンロード処理部２４ｄは、Play_List２７の送信要求を映像視聴端末３０から受信すると、Ｓ４８で格納中のSegment[i]のURLが追記されたPlay_List２７を映像視聴端末３０に送信する（Ｓ５１）。ダウンロード処理部２４ｄは、映像視聴端末３０からSegment[i]のダウンロード要求（配信要求）を受信すると（Ｓ５２）、待機することなく直ちに、映像視聴端末３０にレスポンス（200_OK）を返し（Ｓ５５）、Segment[i]を記憶装置２２から読み出しつつ、映像視聴端末３０にダウンロードさせる（Ｓ５６）。そして、映像視聴端末３０は、ダウンロードしたSegment[i]を表示パネル３７に表示させる。
ここで、ダウンロード処理部２４ｆは、待機することなく直ちに、映像視聴端末３０にレスポンス（200_OK）を返すので、直ちにSegment[i]の最初（０秒目）から読み出すことになる。ダウンロード処理部２４ｄは、Segment[i]の全てをダウンロードしたら、処理が完了する（Ｓ５７）。
図２５は、比較例のコンテンツ配信システムのシーケンス図である。
以下、図２３，２４のフローチャートを参照しつつ、コンテンツ配信システムのシーケンスを説明する。
配信サーバ２０ｆは、Sement[N+1]をアップロードしているときに（Ｓ４８）、映像視聴端末３０からPlay_List２７の送信要求（HTTP_GET）を受信すると、Segment[N+1]までのURLが記述されたPlay_List２７を映像視聴端末３０に送信する（Ｓ５１）。
そして、配信サーバ２０ａがSegment[N+1]をアップロードしているときに（Ｓ４８）、映像視聴端末３０は、Segment[N+1]の配信要求（例えば、HTTP_GETリクエスト（Ｔ４））を配信サーバ２０ｄに送信する。これにより、配信サーバ２０ｄは、レスポンス（例えば、200_OK（Ｔ５））を直ちに映像視聴端末３０に返し（Ｓ５５）、記憶装置２２からSegment[N+1]を読み出して映像視聴端末３０にダウンロードさせ（Ｓ５６）、ダウンロードが完了する（Ｓ５７）。そして、映像視聴端末３０は、Segment[N+1]の配信要求に対するレスポンス（200_OK（Ｔ５））の受信により、Segment[N+1]を受信しつつ、これを再生する。
このSegment[N+1]のダウンロード、及び再生は、Segment[N+1]の最初（０秒目）から実行される。つまり、ダウンロードは、ネットワーク速度が十分であれば、アップロードされている部分を短時間で取得できるものの、Videoデータは各Segmentの先頭から再生を始める必要があるため、Segment[N+2]のアップロード時間に入っても、Segment[N+1]の再生が継続している。
したがって、Segment[N+2]のアップロード時間に入っても、Segment[N+1]の再生が継続しており、Segment[N+1]の再生時間からSegment[N+1]の配信要求とSegment[N+2]のアップロード開始との間の時間を減算した時間の再生遅延が発生する。つまり、Segment[N+2]のアップロード開始から再生開始までの遅延時間Ｔが発生する。また、この再生遅延は、Segment[N+3]以降も継続する。
図２６は、比較例の配信サーバによるセグメントの配信状態を示す図であり、映像送信端末１０がＮ番目のSegment[N]をアップロードし終え、Segment[N+1]の６秒目までをアップロードしているときの状態を実線で示している。比較例の配信サーバ２０ｄ、及び映像視聴端末３０は、Segment[N+1]の最初（０秒目）からダウンロード、及び再生を行う。なお、各Segmentの時間幅は１０秒とする。
一方、第１実施形態では、図７、及び図８を用いて説明したように、配信サーバ２０ａがSegment[N+2]のダウンロード処理を開始したときに、映像視聴端末３０は、Segment[N+2]の最初（０秒目）から再生を開始するので、遅延時間Ｔ（図２５）が生じない。
（変形例）
本発明は前記した実施形態に限定されるものではなく、例えば以下のような種々の変形が可能である。
（１）前記第１実施形態のコンテンツ配信システム１は、映像送信端末１０で生成される TS には、Videoが存在することを前提にしているが、Audioのみのデータの場合も有効な場合がある。その場合、映像視聴端末３０は、Audioのみのコンテンツを再生する端末となるが、常にSegmentの先頭から再生する場合は、本発明の課題と同様の課題が発生するため、本発明を適用できる。
（２）前記第１実施形態は、ＨＬＳを前提としていた。しかしながら、本発明の前提となるプロトコルはＨＬＳに限定されるものではない。
（３）前記実施形態は、アップロード処理部、及びダウンロード処理部を配信サーバに備えるように構成したが、アップロード処理部をアップロードサーバとし、ダウンロード処理部をダウンロードサーバとして別個独立したサーバとすることもできる。この場合のコンテンツ配信システムは、アップロード処理部がダウンロード処理部に送信するシグナル（図４のＳ１６、図５のＳ２４）はネットワークを介して送信することになる。
（４）前記実施形態は、ＨＬＳを前提としたものであり、アダプティブストリーミングを適用することができる。つまり、映像視聴端末３０は、Play_List２７に列挙された複数のバリエーション（ビットレート値に応じたいくつかのバリエーション）で用意されたファイル（ＴＳファイル）から、映像視聴端末３０と配信サーバ２０との間の通信速度に基づき最適なバリエーションのSegmentファイル（ファイルが記憶された場所を示すURL）を選び、配信サーバ２０に配信要求する。これにより、配信サーバ２０から選択したバリエーションのSegmentファイルをダウンロードすることができる。
ここで、映像視聴端末３０は、映像視聴端末３０と配信サーバ２０との間の通信速度が比較的速い場合は、高ビットレート値の高データ転送レートファイル（例えば、高画質な映像ファイル）を配信要求する。一方、通信速度が比較的遅い場合は、映像視聴端末３０は、低ビットレート値の低データ転送レートファイル（例えば、低画質な映像ファイル）を配信要求する。
（５）前記第４，５実施形態の配信サーバ２０ｄは、記憶装置２２にSegment[i]の生成を、アップロード処理部２３ｄからダウンロード処理部２４ｄまで、通知していたが（Ｓ６６（図１２）、Ｓ７８（図１３，図１５））、ダウンロード処理部２４ｄが、アップロード処理部１３ｄからの通知を待つ代わりに、短い時間（例えば、１００ｍ秒）待機して、Segment の生成を確認することを繰り返させてもよい。
１ コンテンツ配信システム
１０，１０ａ，１０ｅ 映像送信端末
１１ ビデオカメラ
１２ Video_Encoder
１３ TS_Muxer
１４ Segmenter
１５ HTTP_Client
１６ Video_Source
２０，２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｄａ，２０ｄｂ，２０e，２０ｆ 配信サーバ
２１ HTTP_Server
２２ 記憶装置
２３，２３ａ アップロード処理部（入力処理部）
２３ｂ，２３ｄ 入力処理部（アップロードサーバ）
２４，２４ａ，２４ｂ，２４ｃ，２４ｄ ダウンロード処理部（出力処理部、ダウンロードサーバ）
２５，２５ａ，２５ｂ，２５ｃ，３８ 制御部
２６ Segment（時分割コンテンツ）
２７ Play_List（インデックスファイル）
２８，２８ａ，２８ｂ エラー処理部
２９ａ インデックスファイル処理部
２９ｂ 配信処理部
３０ 映像視聴端末（再生端末）
３１ HTTP_Client
３２ 主制御部
３３ TS_Demuxer
３４ Video_Decoder
３５ Renderer
３６ ブラウザ
３７ 表示パネル
４１ Segment_List
４２ ＴＳファイル
４３ KeyFrame_List
４４ ＴＳ解析部２５
ＮＷ１，ＮＷ２ ネットワーク

Claims (19)

  1. コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する配信サーバであって、
    前記時分割コンテンツのロケーション識別情報が記載されたファイルと前記時分割コンテンツとを格納する記憶装置と、
    前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記する入力処理部と、
    前記コンテンツの配信要求を受信したときに、
    前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始前であるならば、当該時分割コンテンツの出力を保留し、
    前記入力処理部で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理部と
    を備えることを特徴とする配信サーバ。
  2. 請求項１に記載の配信サーバであって、
    前記出力処理部は、前記再生端末から前記ファイルの送信要求を受信すると、前記記憶装置に格納される当該ファイルを前記再生端末に送信し、
    前記配信要求は、前記ファイルにおけるロケーション識別情報に対応する時分割コンテンツの配信要求である
    ことを特徴とする配信サーバ。
  3. 請求項２に記載の配信サーバであって、
    前記出力処理部は、前記記憶装置に格納中の時分割コンテンツの配信要求を受信してから、所定時間経過するまでは、前記再生端末へのエラーの送信を保留することを特徴とする配信サーバ。
  4. 請求項２に記載の配信サーバであって、
    前記出力処理部は、前記入力処理部で前記ロケーション識別情報に対応する時分割コンテンツの格納開始前であるならば、前記配信要求に対する応答を前記再生端末に送信することを特徴とする配信サーバ。
  5. 請求項２に記載の配信サーバであって、
    前記入力処理部は、前記入力処理部で前記ロケーション識別情報に対応する時分割コンテンツの格納が開始されているならば、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記することを特徴とする配信サーバ。
  6. 請求項２に記載の配信サーバであって、
    前記出力処理部は、前記配信要求を受信すると、最新の時分割コンテンツのロケーション識別情報が追記されたファイルを前記再生端末に送信することを特徴とする配信サーバ。
  7. 請求項２に記載の配信サーバであって、
    前記入力処理部は、前記時分割コンテンツを逐次送信する送信端末に接続されており、前記送信された時分割コンテンツを逐次アップロードすることを特徴とする配信サーバ。
  8. コンテンツが時分割された時分割コンテンツを逐次入力し、入力された時分割コンテンツを再生する再生端末に逐次配信する配信サーバであって、
    前記入力された時分割コンテンツと該入力された時分割コンテンツのロケーション識別情報が記載されたインデックスファイルとを格納する記憶装置と、
    前記再生端末からインデックスファイルの送信要求を受信すると、入力予定の時分割コンテンツに対応するロケーション識別情報を前記インデックスファイルに追記して、追記されたインデックスファイルを前記再生端末に送信するインデックスファイル処理部と、
    ロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、
    当該ロケーション識別情報に対応する時分割コンテンツの格納開始前は、当該時分割コンテンツの配信を保留し、
    当該ロケーション識別情報に対応する時分割コンテンツの格納開始を確認してから、前記配信要求に応答して、当該時分割コンテンツを前記再生端末に配信する配信処理部とを備えることを特徴とする配信サーバ。
  9. コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する配信サーバであって、
    前記時分割コンテンツとロケーション識別情報とを対比して記載したリストと前記時分割コンテンツとを格納する記憶装置と、
    前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記リストに追記する入力処理部と、
    前記コンテンツの配信要求を受信したときは、
    前記入力処理部が入力する時分割コンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理部で次の時分割コンテンツの入力が開始したならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理部と
    を備えることを特徴とする配信サーバ。
  10. KeyFrameを有するコンテンツを入力し、該入力されたコンテンツを再生する再生端末に出力する配信サーバであって、
    前記KeyFrameの位置情報が記載されたリストと前記コンテンツとを格納する記憶装置と、
    前記入力されたコンテンツについて前記記憶装置に格納することを開始すると、当該コンテンツのKeyFrameの位置情報を前記リストに追記する入力処理部と、
    前記コンテンツの配信要求を受信したときは、
    前記入力処理部が入力するコンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理部で次のKeyFrameの入力が開始したならば、当該KeyFrameからのコンテンツについて前記再生端末に出力することを開始する出力処理部と
    を備えることを特徴とする配信サーバ。
  11. 請求項１０に記載の配信サーバであって、
    前記出力処理部は、前記次のKeyFrameの入力の開始により行われる当該次のKeyFrameからのコンテンツ出力を逐次繰り返す
    ことを特徴とする配信サーバ。
  12. コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する入出力部と、前記時分割コンテンツのロケーション識別情報が記載されたファイル、及び前記時分割コンテンツを格納する記憶装置とを備える配信サーバが実行する配信方法であって、
    前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記する入力処理過程と、
    コンテンツの配信要求を受信したときに、
    前記入力処理過程で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始前であるならば、当該時分割コンテンツの出力を保留し、
    前記入力処理過程で当該ロケーション識別情報に対応する時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理過程と
    を実行することを特徴とする配信方法。
  13. コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する入出力部と、前記時分割コンテンツのロケーション識別情報とを対比して記載したリスト、及び前記時分割コンテンツを格納する記憶装置とを備える配信サーバが実行する配信方法であって、
    前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記リストに追記する入力処理過程と、
    前記コンテンツの配信要求を受信して、
    前記入力処理過程で入力される時分割コンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理過程で次の時分割コンテンツの入力が開始したならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理過程と
    を実行することを特徴とする配信方法。
  14. KeyFrameを有するコンテンツを入力し、該入力されたコンテンツを再生する再生端末に出力する入出力部と、前記KeyFrameの位置情報が記載されたリスト、及び前記コンテンツを格納する記憶装置とを備える配信サーバが実行する配信方法であって、
    前記入力されたコンテンツについて前記記憶装置に格納することを開始すると、当該コンテンツのKeyFrameの位置情報を前記リストに追記する入力処理過程と、
    前記コンテンツの配信要求を受信したときは、
    前記入力処理過程で入力されるコンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理過程で次のKeyFrameの入力が開始したならば、当該KeyFrameからのコンテンツについて前記再生端末に出力することを開始する出力処理過程と
    を実行することを特徴とする配信方法。
  15. コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力する配信システムであって、
    入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１サーバと、
    前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、
    前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２サーバと、
    を備えることを特徴とする配信システム。
  16. コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力する配信システムの配信方法であって、
    入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１処理ステップと、
    前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、
    前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２処理ステップと、
    を備えることを特徴とする配信方法。
  17. コンテンツが時分割された時分割コンテンツを入力し、受信された時分割コンテンツを記憶装置に格納し、該格納された時分割コンテンツを再生する再生端末に出力するコンピュータに実行させる配信プログラムであって、
    前記コンピュータを、
    入力予定の時分割コンテンツに対応するロケーション識別情報をファイルに追記して、追記されたロケーション識別情報に対応する前記時分割コンテンツを格納する第１処理手段、
    前記追記されたロケーション識別情報に対応する時分割コンテンツの配信要求を受信して、
    前記時分割コンテンツの格納が開始されたならば、当該時分割コンテンツについて前記再生端末に出力することを開始する第２処理手段、
    として機能させるための配信プログラム。
  18. コンテンツが時分割された時分割コンテンツを入力し、入力された時分割コンテンツを再生する再生端末に出力する入出力部と、前記時分割コンテンツとロケーション識別情報とを対比して記載したリスト、及び前記時分割コンテンツを格納する記憶装置とを備える配信サーバのコンピュータに実行させる配信プログラムであって、
    前記入力された時分割コンテンツについて前記記憶装置に格納することを開始すると、当該時分割コンテンツの次に入力予定の時分割コンテンツに対応するロケーション識別情報を前記ファイルに追記する入力処理過程と、
    前記コンテンツの配信要求を受信して、
    前記入力処理過程で入力する時分割コンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理過程で次の時分割コンテンツの入力が開始したならば、当該時分割コンテンツについて前記再生端末に出力することを開始する出力処理過程と
    を実行させることを特徴とする配信プログラム。
  19. KeyFrameを有するコンテンツを入力し、該入力されたコンテンツを再生する再生端末に出力する入出力部と、前記KeyFrameの位置情報が記載されたリスト、及び前記コンテンツを格納する記憶装置とを備える配信サーバのコンピュータに実行させる配信プログラムであって、
    前記入力されたコンテンツについて前記記憶装置に格納することを開始すると、当該コンテンツのKeyFrameの位置情報を前記リストに追記する入力処理過程と、
    前記コンテンツの配信要求を受信したときは、
    前記入力処理過程で入力されるコンテンツの出力を保留し、
    前記配信要求受信後、前記入力処理過程で次のKeyFrameの入力が開始したならば、当該KeyFrameからのコンテンツについて前記再生端末に出力することを開始する出力処理過程と
    を実行させることを特徴とする配信プログラム。
JP2015249289A 2014-12-24 2015-12-22 配信サーバ、配信方法、配信プログラム、及び配信システム Pending JP2016123097A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014260902 2014-12-24
JP2014260902 2014-12-24

Publications (1)

Publication Number Publication Date
JP2016123097A true JP2016123097A (ja) 2016-07-07

Family

ID=56329069

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015249289A Pending JP2016123097A (ja) 2014-12-24 2015-12-22 配信サーバ、配信方法、配信プログラム、及び配信システム

Country Status (1)

Country Link
JP (1) JP2016123097A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018113568A (ja) * 2017-01-11 2018-07-19 キヤノン株式会社 送信装置、送信方法、およびプログラム

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013021574A (ja) * 2011-07-12 2013-01-31 Sharp Corp 生成装置、配信サーバ、生成方法、再生装置、再生方法、再生システム、生成プログラム、再生プログラム、記録媒体およびデータ構造
JP2013505685A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド 協力的並行ｈｔｔｐ及び前方誤り訂正を用いた拡張ブロック−要求ストリーミング
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
WO2014010445A1 (ja) * 2012-07-10 2014-01-16 シャープ株式会社 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、データ構造、制御プログラムおよび記録媒体
JP2014116805A (ja) * 2012-12-10 2014-06-26 Canon Inc 撮像装置及び情報処理装置及びそれらの制御方法、並びに、映像処理システム
WO2014105491A1 (en) * 2012-12-28 2014-07-03 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (http) requests
JP2014131143A (ja) * 2012-12-28 2014-07-10 Canon Inc 送信装置、送信方法、及びプログラム

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013505685A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド 協力的並行ｈｔｔｐ及び前方誤り訂正を用いた拡張ブロック−要求ストリーミング
JP2013021574A (ja) * 2011-07-12 2013-01-31 Sharp Corp 生成装置、配信サーバ、生成方法、再生装置、再生方法、再生システム、生成プログラム、再生プログラム、記録媒体およびデータ構造
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
WO2014010445A1 (ja) * 2012-07-10 2014-01-16 シャープ株式会社 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、データ構造、制御プログラムおよび記録媒体
JP2014116805A (ja) * 2012-12-10 2014-06-26 Canon Inc 撮像装置及び情報処理装置及びそれらの制御方法、並びに、映像処理システム
WO2014105491A1 (en) * 2012-12-28 2014-07-03 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (http) requests
JP2014131143A (ja) * 2012-12-28 2014-07-10 Canon Inc 送信装置、送信方法、及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018113568A (ja) * 2017-01-11 2018-07-19 キヤノン株式会社 送信装置、送信方法、およびプログラム

Similar Documents

Publication Publication Date Title
JP6404505B2 (ja) メディアコンテンツをクライアントデバイスにストリーミングするための方法および装置
US12537866B2 (en) Segment ladder transitioning in adaptive streaming
US9317188B2 (en) Devices and methods for providing navigation images associated with adaptive bit rate video content
TWI643502B (zh) 內容重製系統、內容重製裝置、程式、內容重製方法、及提供內容伺服器
US9191725B2 (en) Method and apparatus for streaming video
US8665963B2 (en) Communication terminal, content reproduction method, content reproduction program, and content reproduction system for distributing and reproducing video contents with reduced stress
US12088859B2 (en) System and method for converting adaptive stream to downloadable media
WO2013008867A1 (ja) 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
KR101863598B1 (ko) 스트리밍 서비스를 위한 클라이언트의 동작 방법
JP7356018B2 (ja) 情報処理プログラム、情報処理方法および情報処理装置
JP6397341B2 (ja) 受信装置、バッファ管理方法、及びプログラム
JP6535273B2 (ja) 受信装置、セグメント取得方法、及びプログラム
JP2016123097A (ja) 配信サーバ、配信方法、配信プログラム、及び配信システム
JP6294527B2 (ja) 送信装置、送信方法、再生装置、及び再生方法
JP2012222530A (ja) 受信装置及び方法、並びにプログラム
JP2014093733A (ja) 映像配信装置、映像再生装置、映像配信プログラム及び映像再生プログラム
JP6071358B2 (ja) 画像処理装置、画像処理方法、プログラム
JP2016015534A (ja) 情報処理装置および方法
US20260129086A1 (en) Segment ladder transitioning in adaptive streaming
JP2016015533A (ja) 情報処理装置および方法
JP7834441B2 (ja) リアルタイムライブストリーミングで遅延を最小化するための方法、サーバ、およびコンピュータ読み取り可能な記録媒体
JP7577462B2 (ja) 動画再生装置および動画再生方法
JP2024040912A (ja) 情報処理装置、受信装置、情報処理方法、及びプログラム
WO2016002497A1 (ja) 情報処理装置および方法、配信システム、並びにプログラム

Legal Events

Date Code Title Description
RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20160425

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180815

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190228

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190517

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20191008