(57)【特許請求の範囲】
【請求項１】
ＨＴＴＰクライアントにメディアコンテンツのストリームを送信する装置であって、
前記メディアコンテンツのストリームの入力コンテンツを複数のセグメントファイルにセグメント化するセグメンタと、 
前記複数のセグメントファイルを順次に第１のファイルとしてマッピングするセグメントリストを生成するコントローラであって、前記セグメントリスト内のエントリはセグメントの先頭を含み、前記セグメントの先頭は前記第１のファイルにおける前記セグメントファイルの最初の位置のオフセットであり、前記コントローラは、前記複数のセグメントファイルのうちの少なくとも１つが利用可能であるとき、前記第１のファイルを送信または提供せずに前記複数のセグメントファイルを前記ＨＴＴＰクライアントに送信し、前記複数のセグメントファイルは、前記第１のファイル内で前記セグメントの先頭によりマッピングされたようにＨＴＴＰチャンクにより送信され、前記複数のセグメントファイルは、連続したストリームを認識する前記ＨＴＴＰクライアントに透過的である、前記コントローラと、
を含む、前記装置。
【請求項２】
前記コントローラは、前記セグメントリストを保持する、請求項１記載の装置。
【請求項３】
前記複数のセグメントファイルを、その利用可能性について監視するイベントモニタをさらに含む、請求項１記載の装置。
【請求項４】
前記複数のセグメントファイルを記憶する記憶装置をさらに含み、前記イベントモニタは、前記記憶装置を監視することにより前記複数のセグメントファイルを監視する、請求項３記載の装置。
【請求項５】
前記記憶装置から前記複数のセグメントファイルのうちの少なくとも１つを除去するセグメントリムーバをさらに含む、請求項４記載の装置。
【請求項６】
前記セグメントリムーバは、前記複数のセグメントファイルの全長がしきい値を超える場合、前記記憶装置から古いセグメントファイルを除去する、請求項５記載の装置。
【請求項７】
前記コントローラは、ＨＴＴＰチャンク形式転送エンコーディングを介して前記複数のセグメントファイルを送信する、請求項１記載の装置。
【請求項８】
前記ＨＴＴＰチャンク形式転送エンコーディングにおけるチャンクは、前記複数のセグメントファイルのうちの少なくとも１つから得たコンテンツを含む、請求項７記載の装置。
【請求項９】
前記複数のセグメントファイルの各々は少なくとも１つのサブセグメントを含み、前記セグメンタは前記少なくとも１つのサブセグメントを生成することにより前記複数のセグメントファイルの各々を生成する、請求項１記載の装置。
【請求項１０】
前記コントローラは、前記複数のセグメントファイルの各々の前記少なくとも１つのサブセグメントを送信することにより前記複数のセグメントファイルを送信する、請求項９記載の装置。
【請求項１１】
ＨＴＴＰクライアントへメディアコンテンツのストリームを送信するための、メディアサーバが実行する方法であって、
前記メディアコンテンツのストリームの入力コンテンツを複数のセグメントファイルにセグメント化するステップと、
前記セグメントファイルを順次に第1のファイルとしてマッピングするセグメントリストを生成するステップであって、前記セグメントリスト内のエントリはセグメントの先頭を含み、前記セグメントの先頭は前記第１のファイルにおける前記セグメントファイルの最初の位置のオフセットである、前記生成するステップと、 
前記複数のセグメントファイルのうちの少なくとも１つが利用可能であるとき、前記第１のファイルを送信または提供せずに前記複数のセグメントファイルを前記ＨＴＴＰクライアントへ送信するステップであって、前記複数のセグメントファイルは、前記第１のファイル内で前記複数のセグメントの先頭によりマッピングされたようにＨＴＴＰチャンクにより送信され、前記複数のセグメントファイルは、連続したストリームを認識する前記ＨＴＴＰクライアントに透過的である、前記送信するステップと、
を含む、前記方法。
【請求項１２】
前記セグメントリストを保持するステップをさらに含む、請求項１１記載の方法。
【請求項１３】
前記複数のセグメントファイルを、その利用可能性について監視するステップをさらに含む、請求項１１記載の方法。
【請求項１４】
前記複数のセグメントファイルを記憶装置に記憶するステップをさらに含み、前記監視するステップは、前記記憶装置を監視することにより実行される、請求項１３記載の方法。
【請求項１５】
前記複数のセグメントファイルのうちの少なくとも１つを前記記憶装置から除去するステップをさらに含む、請求項１４記載の方法。
【請求項１６】
前記除去するステップは、前記複数のセグメントファイルの全長がしきい値を超える場合に、前記記憶装置から古いセグメントファイルを除去する、請求項１５記載の方法。
【請求項１７】
前記複数のセグメントファイルがＨＴＴＰチャンク形式転送エンコーディングを介して送信される、請求項１１記載の方法。
【請求項１８】
前記ＨＴＴＰチャンク形式転送エンコーディングにおけるチャンクが、前記複数のセグメントファイルのうちの少なくとも１つから得たコンテンツを含む、請求項１７記載の方法。
【請求項１９】
前記複数のセグメントファイルの各々は少なくとも１つのサブセグメントを含み、前記複数のセグメントファイルの各々は前記少なくとも１つのサブセグメントを生成することにより生成される、請求項１１記載の方法。
【請求項２０】
前記複数のセグメントファイルは、前記複数のセグメントファイルの各々の前記少なくとも１つのサブセグメントを送信することにより送信される、請求項１９記載の方法。
【請求項２１】
前記ＨＴＴＰクライアントの要求によりストリーミングするコンテンツを検索するステップをさらに含む、請求項１１記載の方法。
【請求項２２】
前記コントローラは、前記ＨＴＴＰクライアントの要求によりストリーミングするコンテンツを検索する機能をさらに実行する、請求項１記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、メディアコンテンツの送信に関する。より具体的には、本発明は、通常のＨＴＴＰプロトコルを介してライブメディアコンテンツを送信することに関する。
【背景技術】
【０００２】
ワイドエリアネットワーク並びにローカルエリアネットワークを介した映像コンテンツの配信が拡大し続けている。リアルタイムでメディアを配信及び再生すると（ストリーミングとしてよく知られている）、ネットワークに大きな負荷がかかると共にコンテンツを配信及び受信するために使用される機器にも大きな負担がかかる。
【０００３】
データの配信を管理するための１つの周知の方法は、信号符号化の一部として配信チャンクキングを使用することである。チャンク形式転送エンコーディング（ｃｈｕｎｋｅｄ  ｔｒａｎｓｆｅｒ  ｅｎｃｏｄｉｎｇ）は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）におけるデータ転送メカニズムであり、これによりＨＴＴＰデータを確実にサービス（例えば、ウェブサーバ）とエンドクライアント装置で実行されるクライアントアプリケーション（例えば、ウェブブラウザ）との間で配信することができる。チャンク形式エンコーディングは、一連のチャンクとしてメッセージの本文を転送するために、当該メッセージの本文を変更・修正し（各チャンクは独自のサイズインジケータを備える）、その後にエンティティヘッダフィールドを含むオプションのトレーラが続く。このメカニズムによれば、メッセージ本文全体のサイズを送信前に知らなくても、配信を行うことができる。これは、メッセージのデータペイロードを小さな部分（チャンク）に分割して、各チャンクと共にそのサイズを送信することによってなされる。データ転送は、長さゼロの最後のチャンクで終了する。
【０００４】
チャンク形式転送エンコーディングは、映像コンテンツ配信にも適用することができる。ＨＴＴＰ１．１チャンキング方法を使用するほとんどのサーバは、単に、ストリームの先端（通常、メモリ内のバッファに格納されている）を送出している。いくつかの実装例では、メモリ内バッファの代わりにファイルを使用し、追加のライブコンテンツの獲得のためにファイルが大きくなると、ファイルの終わりからの読み取りのループに移行するだけである。これらアプローチの利点は、実装が非常に単純で簡単であることである。このアプローチは適切な大きさにすることができ、堅牢である。
【０００５】
しかし、チャンク形式転送エンコーディングを使用して映像コンテンツをセグメント化すると、特に受信装置において、動作の非効率性が増大する可能性がある。例えば、上記の技術を用いてメディアストリーム内を検索することは、単にストリームの先端をストリーミングするよりも複雑である。さらに、サーバがメディアファイルバッファの先頭のライブトランケーション（ｌｉｖｅ  ｔｒｕｎｃａｔｉｏｎ）を可能にする特別なファイルシステムを使用しない限り、ファイルは無限に大きくなり続け、ライブコンテンツが継続的に供給される間に、ファイルのサイズを小さくすることができない。従って、ＨＴＴＰプロトコルを介して効率的にライブストリームを送信するための改良されたメカニズムが必要とされている。
【０００６】
アップル社は、ＨＴＴＰライブストリーミングと呼ばれるシステムを導入した。このシステムは、セグメントで音声及び映像をストリーミングする。サーバはメディアストリームをセグメントに分解し、各セグメントを個別に送出する。これは、先端（ｌｅａｄｉｎｇ  ｅｄｇｅ）からストリーミングする技術に比較して利点を有する。しかし、アップル社の技術では、クライアントは、セグメントのプレイリストを保持し、当該セグメントを連続的なストリームにする必要がある。このような要件によって、アップル社のライブストリーミングのクライアントは既存の通常のＨＴＴＰのクライアントとの互換性がない特別なクライアントになる。
【０００７】
本発明は、通常のＨＴＴＰプロトコルを介してメディアサーバからクライアントへメディアのライブストリームを送信する際の課題を解決する。
【発明の概要】
【０００８】
本発明は、ＨＴＴＰクライアントにライブストリームを送る方法及び装置に関する。
【０００９】
本発明の１つの態様によれば、ＨＴＴＰクライアントにライブストリームを送る装置が提供される。この装置は、セグメンタ（セグメント化手段）とコントローラとを備える。セグメンタは、ライブストリームの受信コンテンツを複数のセグメントファイルにセグメント化する。複数のセグメントファイルの少なくとも１つが利用可能であるとき、コントローラはＨＴＴＰクライアントに複数のセグメントファイルを送信する。
【００１０】
本発明の別の態様によれば、ＨＴＴＰクライアントにライブストリームを送る方法が提供される。この方法は、ライブストリームの受信コンテンツを複数のセグメントファイルにセグメント化するステップと、複数のセグメントファイルの少なくとも１つが利用可能であるとき、ＨＴＴＰクライアントに複数のセグメントファイルを送るステップとを含む。
【図面の簡単な説明】
【００１１】
本発明の原理・技術思想は、以下の例示的な図面に基づいて、より良く理解することができる。
【図１】図１は、本発明に係るライブストリームを送るためのメディアストリーミングサーバのブロック図である。
【図２】図２は、本発明に係るライブストリームを送るためのプロセスのフローチャートである。
【図３】図３は、本発明に係るライブストリームを送るためのプロセスの好ましい実装例を示す図である。
【図４】図４は仮想ファイルへのセグメントファイルのマッピングを示す図である。
【図５】図５は受信装置の実施形態のブロック図である。
【図６】図６は本発明の技術思想が使用され得るタッチパネルディスプレイまたはリモートタブレットを示す図である。
【発明を実施するための形態】
【００１２】
図１は、本発明に係るライブストリームを送るためのメディアストリーミングサーバ１００のブロック図を示す。当該メディアストリーミングサーバは、例えば、ＭＰＥＧトランスポートストリーム等の入力ライブストリームのコンテンツを複数のセグメントファイルにセグメント化するセグメンタ１１０を有する。当該セグメント化は、当業者に知られている既存のセグメンタプラグイン（ｓｅｇｍｅｎｔｅｒ  ｐｌｕｇ−ｉｎｓ）または他の方法を用いて行うことができる。
【００１３】
メディアストリームサーバはコントローラ１３０をさらに有する。コントローラは、通常のＨＴＴＰクライアントからのライブストリームのリクエストを受け取り、当該リクエストを処理し、リクエストされたライブストリームをクライアントに送る。ライブストリームは複数のセグメントファイルにセグメント化されているので、コントローラは、ライブストリームの１つ以上のセグメントファイルが利用可能な場合（すなわちライブストリームの１つ以上のセグメントファイルがメディアストリーミングサーバによって受信され処理される場合）、ストリームを送る。コントローラの１つの実装例は、ＨＴＴＰシンク（ｓｉｎｋ）を使用してなされる。ＨＴＴＰシンクは、当業者にはＧＳｔｒｅａｍｅｒコンポーネントとして知られているものであり、基本的にはＨＴＴＰクライアント（複数可）にメディアセグメントを送るＨＴＴＰサーバである。
【００１４】
本発明の１つの実施形態では、図４に示されるように、セグメントファイルが仮想ファイル内にマッピングされるので、クライアントにはライブストリームが１つの連続したファイルのように見える。図４では、セグメントＳｐｔｓ＿ｒｅｃ００１、Ｓｐｔｓ＿ｒｅｃ００２、Ｓｐｔｓ＿ｒｅｃ００３等の各々が、セグメントファイルであり、約１０秒の長さを有する。マッピングは、仮想ファイル内における各セグメントファイルの先頭のオフセットを記録することによって行うことができる。例えば、Ｓｐｔｓ＿ｒｅｃ００２の場合、仮想ファイル内におけるオフセットは９３４３６１バイトであり、これは、セグメントファイルＳｐｔｓ＿ｒｅｃ００２が仮想ファイル内のセグメントファイルＳｐｔｓ＿ｒｅｃ００１の直後にあることを示している。このような仮想ファイルを使用すると、セグメント化は、クライアントに透過的である。クライアントは、ストリームが１つの連続したファイルであるかのように、ライブストリームを受信し、または当該ライブストリームに検索等の他の操作を行う。１つの実装例では、仮想マッピングは、各要素が下記のような好ましい構造を有しているリンクリスト（ｌｉｎｋｅｄ  ｌｉｓｔ）などのデータ構造により実現される。
【００１５】
struct segment_file:
{ 
segment_filename;//file name of the segment file
segment_start;//the offset within the virtual file
segment_length;//length of the segment file
}
この構造を使用することによって、セグメントリストを構築して、マッピング処理を実現することができる。本発明の１つの実施形態では、セグメントリストは、コントローラ１３０によって保持される。
【００１６】
１つの実施形態では、コントローラ１３０は、イベントモニタ１４０からセグメントファイルの利用可能性を通知される。イベントモニタ１４０は、セグメントファイルを監視する。１つ以上のセグメントファイルがセグメンタ１１０によって生成されているなら、イベントモニタ１４０はコントローラ１３０に通知を送る。その後、コントローラ１３０はセグメントリストを更新し、生成されたセグメントファイルを取り出して、クライアントからのリクエストに応じてクライアントに当該セグメントファイルを送る。非限定的な例においては、セグメントファイルは、セグメンタ１１０により生成された後、記憶装置１２０に格納される。イベントモニタ１４０は、セグメントファイルにおける全ての変化を監視するために記憶装置１２０を監視する。１つの実装例では、非同期ファイルシステムのイベントシステム（例えば、アイノティファイ（ｉｎｏｔｉｆｙ））がイベントモニタとして使用される。アイノティファイは、ファイルシステムへ変更を通知するためにファイルシステムを拡張し、アプリケーションに当該変更を報告するように動作するリナックスカーネルサブシステムである。
【００１７】
本実施形態の利点は、メディアストリームからの古いセグメントファイルを記憶媒体から除去／削除して、当該記憶媒体が時間経過に伴い一杯になるのを防ぐことができることである。例えば、２ＧＢのファイルサイズ制限をサポートする任意のタイプのファイルシステムは、このサーバで使用することができる。従って、図１に示されたメディアストリーミングサーバ１００は、記憶媒体からセグメントファイルを除去／削除するセグメントリムーバ（図示せず）をさらに含むことができる。セグメントを除去するアルゴリズムは以下のように動作する。現在のセグメントリストＬｓｅｇｍｅｎｔ＿ｌｉｓｔのコンテンツの全長が計算される（長さＬｓｅｇｍｅｎｔ＿ｍｏｓｔ＿ｒｅｃｅｎｔの最も新しいセグメントを含む）。セグメントリストコンテンツの所望の長さＬｄｅｓｉｒｅｄはユーザによって設定される。もし最も新しいセグメントの長さを引いたセグメントリストの全長が所望の長さの特定の部分を超えるなら、セグメントリスト内の最も古いセグメントは１度に１つずつ除去される。１つの実施形態では、３＊（Ｌｓｅｇｍｅｎｔ＿ｌｉｓｔ−Ｌｓｅｇｍｅｎｔ＿ｍｏｓｔ＿ｒｅｃｅｎｔ）＞Ｌｄｅｓｉｒｅｄならば、最も古いセグメントが除去される。セグメントリストの所望の長さは、ユーザによって指定することができるパラメータである。Ｌｄｅｓｉｒｅｄの値の例は、２４０秒のコンテンツである。Ｌｄｅｓｉｒｅｄの値の他の例は１３０ＭＢである。
【００１８】
図２は、本発明の１つの実施形態に係るライブストリーム送信プロセスのフローチャートである。ステップ２１０において、クライアントからのライブメディアストリームのリクエストが受信される。その後、ライブメディアストリームは、ステップ２２０においてセグメント化される。一方で、セグメント化のためのイベントのウォッチングが設定され、セグメントファイルの生成をモニタリングする。長さ変更またはファイル名変更などのセグメントファイルにおける変更があると、セグメントファイルのセット全体を記録して当該セグメントファイルを１つの仮想連続ファイルにマッピングするセグメントリストが、ステップ２３０で更新／保持される。セグメントリストが空であるかどうかを、判定ステップ２５０で判断する。イエスである（空である）なら、プロセスはステップ２３０に戻り、セグメントファイルからの更新を待つ。セグメントリスト内に少なくとも１つのエントリがあれば、プロセスはステップ２６０に移行してセグメントリスト内の次のセグメントファイルを送出する。ＨＴＴＰチャンク形式転送エンコーディングは、１つのセグメントファイルを送出するために使用することができる。次いで、セグメントリストへのポインタは、ステップ２７０において次のセグメントファイルに移動される。プロセスはステップ２５０に戻り、送信のために利用できるセグメントファイルがさらに存在するかを判断する。本出願のどこかで説明されているように、記憶媒体内のスペースを節約するために、古いセグメントファイルはステップ２４０で除去されても良く、セグメントリストはステップ２３０でそれに応じて更新される。
【００１９】
以下の記載は、本発明に係るライブメディア送信システムを含むメディアストリーミングサーバを動作させるための好適で詳細なプロセスをまとめたものである。このプロセスによれば、通常のＨＴＴＰ１．１クライアントがネットワークからのライブメディアストリームの再生をサポートすることができる。当該プロセスは、ライブメディアストリームをセグメント化する能力を備えており、複数のセグメントファイルが実際に１つの連続したデータバッファの如く見えるように当該複数のセグメントファイルを提供するステップを含み、もし古いセグメントファイルがプロセス内の削除アルゴリズムによって削除対象としてマークされると、セグメントファイルを提供するステップの後に古いセグメントファイルの削除が行われる。このプロセスは、図１に示すメディアストリーミングサーバによって、または同じ機能を実現する他のシステムのセットアップによって、実行することができる。当該プロセスはさらに下記のステップによって定義される。
【００２０】
１．クライアントはセグメンタ１１０（メディアストリーミングサーバ１００内にある）を起動するライブストリームを指す公知のＵＲＬに接続して、当該ライブメディアストリームを所定時間長のセグメントファイルに分解することをトリガする。セグメントファイルのサイズ（即ち、時間長）は、送信遅延とセグメント管理オーバーヘッドとの間の所望のトレードオフに応じて変えることができ、例えば１０秒とすることができる。
【００２１】
２．非同期ファイルシステムイベントシステムまたはイベントモニタ（例えば、アイノティファイ）を使用して、セグメントファイルが書き込まれるディレクトリに対して、イベントウォッチングを設定する。これにより、いつ各セグメントファイルが修正されたかをウォッチングする。
【００２２】
３．セグメントファイルが変更されたときにイベントシステムまたはイベントモニタは信号を送信する。尚、セグメントファイルについて設定された長さや時間に到達するまで、セグメンタは当該セグメントファイル用の複数のサブセグメントを書き込むことにより、セグメントファイルを生成する。複数のサブセグメントの集合がセグメントファイルを形成する。従って、セグメントファイルの修正は、新しいセグメントファイルの作成または１つセグメントファイル内における１つ以上のサブセグメントの追加／更新によって行われる可能性がある。この時点で、セグメントファイルの名称とフルファイルパス（ｆｕｌｌ  ｆｉｌｅ  ｐａｔｈ）が、当該セグメントファイルの始点及び長さと共に記録される。これが当該ストリームからの最初のセグメントファイルである場合、始点はゼロになり、長さはセグメントファイルの現在のサイズになる。同一セグメントファイル内の連続する各修正イベントについては、開始オフセットが１＋前回のセグメントファイルの始点＋前のセグメントファイルの長さとなる。このセグメントファイルは、セグメントリストの最後に追加される。もしセグメントのファイル名が変わるなら（それは新しいセグメント・ファイルが作成されていることを意味する）、セグメントリストに追加された前のエントリは、その時点における全体のセグメントリストについては最後のセグメントファイルであるとしてフラグが立てられなければならない。セグメンタの実装例において、セグメントの長さは、セグメントファイルの全長に達するまで（この時点で新しいセグメントファイルが開始する）ｘｋｂｐｓ（すなわち、１つのサブセグメント）毎に更新される。尚、ｘが小さい場合（つまり、サブセグメントがより小さい場合）、より多くのオーバーヘッドを要するが、セグメントファイルに対するよりタイムリーなアップデートを提供する。極端な場合には、ｘはセグメントファイルの全長に等しい。つまり、セグメントファイルは１つのサブセグメントのみから構成される。
【００２３】
４．次のステップは、セグメントリストが少なくとも１つのエントリを有するまで待つことである。１つの実装例では、メディアストリーミングサーバ内の他のスレッドが生成されて、１つのセグメントファイルがセグメンタから作成されるのを待つ。このスレッドがセグメントファイルの利用可能状態を認識すると、当該スレッドはメインスレッドに信号を送り、当該セグメントファイルがＨＴＴＰクライアントに送信されるように処理する。
【００２４】
５．セグメントリストの最初のエントリが検査される。１つのエントリがセグメントリストに追加されていると、セグメントファイルは、ローカル記憶媒体からの読み込みのために開かれる必要がある。リスト内にセグメントファイルがない場合、プロセスは、少なくとも１つの生成されかつ検査に利用できるセグメントファイルができるまで、待機しなければならない。
【００２５】
６．その後、検査対象の（検査中の）セグメントファイルが読み出され、サーバが、ＨＴＴＰチャンク形式転送エンコーディングを介して、事前定義されたチャンクサイズＳｃでセグメントファイルを送出する。チャンクサイズＳｃはオーバーヘッドと送信遅延との間のトレードオフに基づいて決定される。例として、Ｓｃとして１２８キロバイトが、クライアントに送られる適切なチャンクサイズである。
【００２６】
７．セグメントファイルの長さがチャンクサイズＳｃより大きい場合、サーバは再度ファイルのＳｃを記憶媒体から読み出し、当該Ｓｃをクライアントに送信する。
【００２７】
８．セグメントリスト内の現在のセグメントファイルの位置を示すポインタが１だけインクリメントされ、次のセグメントファイルが検査される。
【００２８】
９．現在のセグメントファイルの一部がクライアントに送られると、論理ストリームまたは仮想ファイル内の位置インジケータは、以前の位置の値と、現在のセグメントファイルのためにクライアントに送られたバイトの総数との合計値に設定される必要がある。
【００２９】
１０．セッションが終了するまでプロセスを繰り返す。メディアソースが配信を終了したとき、または、クライアントがＨＴＴＰサーバから切断したとき、セッションを終了することができる。
【００３０】
別の実施形態では、ステップ６〜９は、セグメントファイル内の各サブセグメントに対して実行される。つまり、セグメントファイルの１つのサブセグメントが読み出され、ＨＴＴＰチャンク形式転送エンコーディングを介して送出される。論理ストリームまたは仮想ファイル内の位置インジケータは、各サブセグメント毎に更新される。セグメントファイル内の全てのサブセグメントが処理されるまで、上記のステップが繰り返される。
【００３１】
上述したプロセスは、例示的な一実施形態であることに留意することが重要である。異なるプロセスを採用する場合は、上記ステップのうちの１つ以上を省略することができるし、上記していない追加のステップをさらに含んでもよい。また、上記のステップのうちの１つ以上は、上記プロセスの重要で有利な特徴を基本的に変更せずに、組み合わせたり並列的に実行されてもよい。
【００３２】
図３は図２に示された実施形態の実装例を示している。この実装例は、メモリ制御、管理、セグメントファイルのマッピング及びセグメントリスト管理の特徴を含む。
【００３３】
１．ＨＴＴＰチャンキングモードでウェブサーバを起動する（ステップ３１０）。
【００３４】
２．ウェブルートディレクトリのＩＮ＿ＣＬＯＳＥ＿ＷＲＩＴＥのアイノティファイファイルシステムイベントをリッスンする（ステップ３２０）。書き込み用に開いたファイルが閉じられたときにＩＮ＿ＣＬＯＳＥ＿ＷＲＩＴＥのイベントが送られる。
【００３５】
３．セグメントファイル名及びセグメントファイル長のマップがセグメント化ツールから生成されると、当該セグメントファイル名及びセグメントファイル長のマップをセグメントリストとして保持する（ステップ３３０）。
【００３６】
４．クライアントから「範囲：バイト＝０−」のような範囲ヘッダ付きのリクエストを待ち（ステップ３４０。クライアントは、この範囲ヘッダを指定することにより、ウェブサーバがセグメントの配信のためにＨＴＴＰ１．１チャンク形式モードを使用することを指定する）、第１のセグメントファイルの設定可能なチャンクサイズＳｃをＨＴＴＰクライアントに提供する（ステップ３５０）。Ｓｃの例示的な値は１２８Ｋバイトである。
【００３７】
５．「範囲：バイト＝１２３８９０９８−」のような範囲ヘッダ付きのリクエストをクライアントから待ち（ステップ３４０）、当該範囲ヘッダで指定したバイトオフセットから開始する設定可能なチャンクサイズをクライアントに提供する（ステップ３５０）。当該オフセットは、この例では、１２３８９０９８である。尚、１つのチャンクは、２つの異なるセグメントファイルにまたがることができ、ステップ３で述べたマップ内のルックアップが必要になる。
【００３８】
６．いくつのセグメントがセグメントリストに保持されるべきかを設定するプロパティを定義する。本明細書において説明した方法で、ハードディスク及びセグメントリストから残りのセグメントファイルを除去する（ステップ３６０）。
【００３９】
同じライブストリームを要求する複数のクライアントが存在する場合、異なるクライアントに対して異なるポインタが採用されて、ストリーム内に各クライアントのバージョンの現在位置を記録する。
【００４０】
複数のプログラム入力がある（すなわち、複数のライブストリームがある）場合、複数のセグメントが使用され得る（各プログラムに１つのセグメントが使用される）。異なる実施形態では、１つ以上のセグメントが複数のライブストリームの間で共有される。１つの記憶装置を複数のライブストリームの間で共有することができるが、異なるプログラムのために異なるディレクトリを設定する必要がある。ファイルシステムイベントモニタは、各ディレクトリをウォッチングするように設定されなければならない。コントローラは異なるライブストリームに対する複数のリクエストに対応するため、複数のスレッド／プログラムを取り扱うように構成される。
【００４１】
実施形態は、既存の技術と同様な方法で、例えば、所望の表示時間等に関して、コンテンツ内を検索するクライアントをサポートする（但し、検索の実行の仕方は異なる）。本実施形態では、ライブメディアストリームは記憶媒体上でセグメントファイルに分割される。開示されたプロセスは、各セグメントファイルのバイト境界の知識を用いて検索機能を使用することにより、クライアントにメディアストリームの論理表示を示すことができる。メディアストリームは異なるファイルに分割されているが、クライアント装置は実質的に当該メディアストリームが連続的であると知覚する。換言すると、ストリームが公知の数の既存セグメントファイルにセグメント化されかつ未知の数のセグメントファイルにその後セグメント化されるとしても、サーバに実装されるアルゴリズムを使用すると、各クライアントには、ストリームが１つの連続したファイルであるかのように見える。
【００４２】
図５は受信装置の実施形態のブロック図を示す。当該受信装置は、ゲートウェイ装置、モデム、セットトップボックス、または他の類似の通信装置の一部として含めることができる。図示された装置は、音響装置または表示装置等の他のシステムに組み込むこともできる。いずれの場合も、システムを完全に動作させるために必要ないくつかのコンポーネントは、当業者には周知であるので、簡潔さのために示していない。
【００４３】
図５に示された装置においては、コンテンツは入力信号受信部５１０によって受信される。入力信号受信部は、数個の可能性のあるネットワーク（例えば、無線、有線（ケーブル）、衛星、イーサネット（登録商標）、ファイバ、電話回線網）の１つを介して提供される信号を受信、復調及び復号するために用いられる数個の公知の受信回路の１つであってよい。所望の入力信号は、制御インタフェースまたはタッチパネルインタフェースを介して提供されるユーザ入力に基づいて、入力信号受信部により選択され取得することができる。タッチパネルインタフェースは、タッチスクリーンデバイスのためのインタフェースを含むことができる。タッチパネルインタフェースは、携帯電話、タブレット、マウス、ハイエンドリモートデバイス等にインタフェースするように採用することができる。
【００４４】
復号された出力信号は、入力ストリーム処理部５２０に提供される。入力ストリーム処理部は最終信号選択及び処理を行い、これはコンテンツストリームの音声コンテンツから映像コンテンツを分離することを含む。音声コンテンツは音声処理部５３０に提供されて、受信されたフォーマット（例えば、圧縮デジタル信号）をアナログ波形信号に変換する。アナログ波形信号は、音声インタフェース５４０に供給され、さらに表示装置若しくは音声アンプに供給される。代替構成では、音声インタフェースは、高品位マルチメディアインタフェース（ＨＤＭＩ（登録商標））ケーブルまたはその代わりとなる音声インタフェース（例えば、ソニー／フィリップスデジタルインタコネクトフォーマット（ＳＰＤＩＦ）を介して、音声出力装置または表示装置にデジタル信号を提供することができる。音声インタフェースは、もう１つのスピーカセットを駆動するための増幅器を含んでもよい。さらに、音声処理部は、音声信号を記憶するために必要な任意の変換を行う。
【００４５】
入力ストリーム処理部からの映像出力が映像処理部５５０に提供される。映像信号は複数のフォーマットの１つであってよい。映像処理部は、入力信号フォーマットに基づいて映像コンテンツの必要な変換を提供する。また、映像処理部は、映像信号を記憶するための必要な変換を行う。
【００４６】
記憶装置５６０は入力部で受信された音声及び映像コンテンツを記憶する。記憶装置は、その後、コントローラの制御の下に、ユーザインタフェース及び/またはタッチパネルインタフェース５８５から受け取ったコマンド（例えば、早送り（ＦＦ）及び巻き戻し（ＲＥＷ）等のナビゲーション命令）に基づき、コンテンツの取り出し（検索）と再生を行うことができる。記憶装置は、ハードディスクドライブ、１つ以上の大容量集積電子メモリ（例えば、スタティックＲＡＭ（ＳＲＡＭ）またはダイナミックＲＡＭ（ＤＲＡＭ））であってもよいし、交換可能な光学ディスク記憶システム（例えば、コンパクトディスク（ＣＤ）ドライブまたはデジタルビデオディスク（ＤＶＤ）ドライブ）であってもよい。
【００４７】
映像処理部からの変換された映像信号（入力部から供給された映像信号または記憶装置から供給された映像信号）は、ディスプレイインタフェース５７０に提供される。また、当該ディスプレイインタフェースは、テレビ、コンピュータまたはディスプレイモニタ等の表示装置に表示信号を提供する。ディスプレイインタフェースは、例えば赤−緑−青（ＲＧＢ）等のアナログ信号インタフェースでもよいし、ＨＤＭＩ等のデジタルインタフェースでもよい。
【００４８】
コントローラ５８０は、入力ストリーム処理部５２０、音声処理部５３０、映像処理部５５０、記憶装置５６０、及びユーザインタフェース５９０を含む、受信装置のコンポーネントのいくつかにバスを介して相互接続される。コントローラは、入力ストリーム信号を記憶装置に記憶できる信号にまたは表示用の信号に変換する変換処理を管理する。また、コントローラは、記憶されたコンテンツの取り出し及び再生を管理する。
【００４９】
さらに、コントローラは、コントローラ用の情報及び命令コードを記憶するために、制御メモリ５９５（例えば、ＲＡＭ、ＳＲＡＭ、ＤＲＡＭ、ＲＯＭ、プログラマブルＲＯＭ（ＰＲＯＭ）、フラッシュメモリ、電子的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電子的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）等の揮発性メモリまたは不揮発性メモリ）に接続されている。制御メモリは、受信装置を動作させる制御装置により実行される命令を記憶すると共に、メイン装置（例えば、ゲートウェイ、セットトップボックス）により実行される命令も記憶することができる。操作に使用されるソフトウェアコンポーネント及びソフトウェアインタフェースは、コントローラによって実行されてもよい。さらに、いくつかの操作は、通信インタフェースを介してソフトウェアコードの通信により転送され、例えば、後述するタッチパネル装置等の外部装置によって実行されてもよい。また、制御メモリは、コンテンツを含むグラフィック要素等の要素のデータベースを格納することができる。さらに、制御メモリの実装は、単一のメモリ装置、または、代替例として、通信可能に接続または相互に結合して１つの共有メモリまたは共通メモリを形成する複数のメモリ回路等の、いくつかの可能な実施形態を含んでもよい。加えて、メモリは、バス通信回路の部分等の、より大きな回路内の他の回路構成に含めることができる。
【００５０】
本発明の開示に係るユーザインタフェースプロセスは、早送り、巻き戻し等の機能を表現するために用いることができる入力装置を採用している。これを可能にするために、図６に示されているタッチパネル装置またはリモートタブレットは、ユーザインタフェース及び/または図５に示されている受信装置のタッチパネルインタフェースを介して、インタフェースすることができる。タッチパネル装置は、手の動き、又はジェスチャ、及び動作に基づくセットトップボックスまたは受信装置の操作を、当該パネルを介して当該セットトップボックスまたは他の制御装置のための命令に翻訳することができる。
【００５１】
図５の受信装置に関して説明された回路及び機能の幾つかは、タッチパネル装置に存在してもよいことに留意することが重要である。１つの実施形態では、タッチパネルは、単にディスプレイをナビゲートするためのナビゲーションツールとして機能してもよい。他の実施形態では、タッチパネルは、さらに、ユーザがコンテンツの表示を介してナビゲーションとより直接的に対話できるようにする表示装置として機能する。タッチパネル装置は、例えば、フロントパネルディスプレイ又はアレイの一部として、セットトップボックス自体に統合されてもよい。また、タッチパネル装置は、起動ボタン等のより従来の制御機能を含むリモート制御装置の一部として含まれてもよい。
【００５２】
セットトップボックスまたはゲートウェイの一部として図５で説明した受信装置と、図６で説明したリモートタブレットもしくはタッチパネルディスプレイとの間の通信インタフェースは、ローカルエリアネットワーク内で動作するクライアントサーバ型のプロトコルを含むことができる。例えば、メディアコンテンツ（例えば、映像、音声）はＨＴＴＰ１．１標準を介してクライアント（例えば、タッチパネル装置）とサーバ（例えば、セットトップボックスまたはゲートウェイ）との間で転送することができる。また、サーバは、上述したように、２つ以上のクライアント（例えば、第２のセットトップボックス、シン（ｔｈｉｎ）クライアント装置等）へのメディア配信を同時にサポートすることができる。
【００５３】
上記の実施形態は、非常に手軽なものであり、ローカルサーバ（例えば、セットトップボックス、ゲートウェイ等）とローカルクライアント（例えば、リモート装置、タブレット等）との間で上記のようなローカルエリアネットワークで動作させることができる。本発明の技術思想は広域ネットワークにおいても使用できるように、拡張することができる。例えば、プロセスは、ユーザの家庭内の複数のクライアント装置（クライアント装置のセット）とウェブサービスを利用したインターネットサービスで使用できるように適合させることが容易にできる。
【００５４】
本明細書において本発明の好適な実施形態を詳細に説明してきたが、本発明はこれら実施形態に限定されるものではなく、その他の変更及び変形が特許請求の範囲によって定義された本発明の範囲から逸脱することなく当業者によってなされ得る。 
本発明は以下の態様を含む。
（付記１）
ＨＴＴＰクライアントにライブストリームを送信する装置であって、
前記ライブストリームの入力コンテンツを複数のセグメントファイルにセグメント化するセグメンタと、 
前記複数のセグメントファイルの少なくとも１つが利用可能であるとき、前記複数のセグメントファイルを前記ＨＴＴＰクライアントに送信するコントローラと、
を含む、前記装置。
（付記２）
前記コントローラは、前記複数のセグメントファイルを仮想ファイルにマッピングするセグメントリストを保持する、付記１記載の装置。
（付記３）
前記複数のセグメントファイルを、その利用可能性について監視するイベントモニタをさらに含む、付記１記載の装置。
（付記４）
前記複数のセグメントファイルを記憶する記憶装置をさらに含み、前記イベントモニタは、前記記憶装置を監視することによって前記複数のセグメントファイルを監視する、付記３記載の装置。
（付記５）
前記記憶装置から前記複数のセグメントファイルの少なくとも１つを除去するセグメントリムーバをさらに含む、付記４記載の装置。
（付記６）
前記セグメントリムーバは、前記複数のセグメントファイルの全長がしきい値を超える場合、前記記憶装置から古いセグメントファイルを除去する、付記５記載の装置。
（付記７）
前記コントローラは、ＨＴＴＰチャンク形式転送エンコーディングを介して前記複数のセグメントファイルを送信する、付記１記載の装置。
（付記８）
前記ＨＴＴＰチャンク形式転送エンコードにおけるチャンクは、前記複数のセグメントファイルの少なくとも１つから得たコンテンツを含む、付記１記載の装置。
（付記９）
前記複数のセグメントファイルの各々は少なくとも１つのサブセグメントを含み、前記セグメンタは前記少なくとも１つのサブセグメントを生成することによって前記複数のセグメントファイルの各々を生成する、付記１記載の装置。
（付記１０）
前記コントローラは、前記複数のセグメントファイルの各々の前記少なくとも１つのサブセグメントを送信することによって前記複数のセグメントファイルを送信する、付記９記載の装置。
（付記１１）
ＨＴＴＰクライアントへライブストリームを送信する方法であって、
前記ライブストリームの入力コンテンツを複数のセグメントファイルにセグメント化するステップと、 
前記複数のセグメントファイルの少なくとも１つが利用可能であるとき、前記複数のセグメントファイルを前記ＨＴＴＰクライアントへ送信するステップと、
を含む、前記方法。
（付記１２）
前記複数のセグメントファイルを仮想ファイルにマッピングするセグメントリストを保持するステップをさらに含むことを特徴とする付記１１記載の方法。
（付記１３）
前記複数のセグメントファイルを、その利用可能性について監視するステップをさらに含む、付記１１記載の方法。
（付記１４）
前記複数のセグメントファイルを記憶装置に記憶するステップをさらに含み、前記監視するステップは、前記記憶装置を監視することによって実行される、付記１３記載の方法。
（付記１５）
前記複数のセグメントファイルの少なくとも１つを前記記憶装置から除去するステップをさらに含む、付記１４記載の方法。
（付記１６）
前記除去するステップは、前記複数のセグメントファイルの全長がしきい値を超える場合に、前記記憶装置から古いセグメントファイルを除去する、付記１５記載の方法。
（付記１７）
前記複数のセグメントファイルがＨＴＴＰチャンク形式転送エンコーディングを介して送信される、付記１１記載の方法。
（付記１８）
前記ＨＴＴＰチャンク形式転送エンコーディングにおけるチャンクが、前記複数のセグメントファイルの少なくとも１つから得たコンテンツを含む、付記１７記載の方法。
（付記１９）
前記複数のセグメントファイルの各々は少なくとも１つのサブセグメントを含み、前記複数のセグメントファイルの各々は前記少なくとも１つのサブセグメントを生成することによって生成される、付記１１記載の方法。
（付記２０）
前記複数のセグメントファイルは、前記複数のセグメントファイルの各々の前記少なくとも１つのサブセグメントを送信することにより送信される、付記１９記載の方法。
【図１】
0006030572.tif 000002
【図２】
0006030572.tif 000003
【図３】
0006030572.tif 000004
【図４】
0006030572.tif 000005
【図５】
0006030572.tif 000006
【図６】
0006030572.tif 000007