(57)【要約】【課題】増設コストをかけることなく、ライブコンテンツを格納したＭＰ４ファイルを実時間に対して低遅延で受信し、リアルタイムでの再生を実現することができるデータ受信方法を提供する。【解決手段】第２リクエスト作成部３０６において、ＭＰ４ファイルの初期ヘッダと最新のフラグメントの取得を配信サーバに要求するリクエストを作成し、リクエスト送信部３０３において、データ取得リクエストを、ＨＴＴＰによって配信サーバに送信し、レスポンス受信部３０４において、送信したデータ取得リクエストに対する応答であり、ＭＰ４ファイルの初期ヘッダと最新のフラグメントとを含むレスポンスを、配信サーバからＨＴＴＰによって受信する。【選択図】        図２
2005086362.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続されたサーバ装置から受信するデータ受信方法であって、
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、
前記データ取得リクエストを、ＨＴＴＰ(Hypertext Transfer Protocol)によって前記サーバ装置に送信するリクエスト送信ステップと、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとを含む
ことを特徴とするデータ受信方法。
【請求項２】
前記データ受信方法は、さらに、
前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を前記サーバ装置に要求するサイズ情報取得リクエストを作成するサイズ情報取得リクエスト作成ステップと、
前記サイズ情報取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するサイズ情報取得リクエスト送信ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを前記サーバ装置からＨＴＴＰによって受信するサイズ情報レスポンス受信ステップとを含み、
前記リクエスト作成ステップにおいて、前記サイズ情報レスポンス受信ステップにおいて受信した前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて、前記データ取得リクエストを作成する
ことを特徴とする請求項１記載のデータ受信方法。
【請求項３】
前記リクエスト作成ステップにおいて、ＨＴＴＰの拡張部に前記共通ヘッダおよび前記最新パケットの配信を要求する旨の情報を記述することによって前記データ取得リクエストを作成する
ことを特徴とする請求項１記載のデータ受信方法。
【請求項４】
前記リクエスト作成ステップにおいて、前記共通ヘッダの配信を要求する第１データ取得リクエストと、前記最新パケットの配信を要求する第２データ取得リクエストとを作成し、  前記リクエスト送信ステップにおいて、前記第１データ取得リクエストと、前記第２データ取得リクエストとを独立してＨＴＴＰによって前記サーバ装置に送信し、
前記リクエスト受信ステップにおいて、前記第１データ取得リクエストに対する応答として、前記共通ヘッダを含む第１レスポンスと、前記第２データ取得リクエストに対する応答として、前記最新パケットを含む第２レスポンスとをＨＴＴＰによって受信する
ことを特徴とする請求項１〜３のいずれか１項に記載のデータ受信方法。
【請求項５】
前記データ受信方法は、さらに、
前記パケットに含まれるデータを受信して再生する際の再生開始時間が、前記ファイルを実時間で再生した際の当該パケットの再生開始時間に対して所定の閾値以上遅延する場合に、時間的に不連続となるパケットの受信を行なうか、時間的に連続するパケットの受信を行なうかの選択を受け付けるスキップ受信選択受付ステップを含み、
前記リクエスト作成ステップにおいて、前記スキップ受信選択受付ステップにおける選択結果を示す情報を記述したデータ取得リクエストを作成する
ことを特徴とする請求項１〜４のいずれか１項に記載のデータ受信方法。
【請求項６】
前記データ受信方法は、さらに、
前記スキップ受信選択受付ステップにおいて、時間的に不連続となるパケットの受信を行なう選択を受け付けた場合に、不連続となった箇所を表示するスキップ発生表示ステップを含む
ことを特徴とする請求項５記載のデータ受信方法。
【請求項７】
前記データ受信方法は、さらに、
１つ以上のパケット毎に作成された前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を取得する同期情報取得ステップと、
前記同期情報取得ステップにおいて取得した同期情報を用いて、前記メディアデータを再生する同期再生ステップとを含む
ことを特徴とする請求項１〜６のいずれか１項に記載のデータ受信方法。
【請求項８】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続された端末装置に送信するデータ送信方法であって、
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信ステップと、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成ステップと、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信ステップと
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップとを含む
ことを特徴とするデータ送信方法。
【請求項９】
前記データ送信方法は、さらに、
前記レスポンス送信ステップにおいて送信されるパケットに含まれる前記データの再生開始時間が、前記ファイルを実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得ステップと、
前記遅延時間取得ステップにおいて取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定ステップと、
前記遅延判定ステップにおいて、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定ステップとを含み、
前記レスポンス作成ステップにおいて、前記スキップ決定ステップにおける決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、
前記レスポンス送信ステップにおいて、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信する
ことを特徴とする請求項８記載のデータ送信方法。
【請求項１０】
コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化方法であって、
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、
前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとを含む
ことを特徴とするデータ多重化方法。
【請求項１１】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続されたサーバ装置から受信するデータ受信装置であって、
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成手段と、
前記データ取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するリクエスト送信手段と、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信手段とを備える
ことを特徴とするデータ受信装置。
【請求項１２】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続された端末装置に送信するデータ送信装置であって、
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信手段と、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成手段と、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成手段と、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信手段と
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信手段と、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定手段と、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定手段が決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成手段と、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信手段とを備える
ことを特徴とするデータ送信装置。
【請求項１３】
前記データ送信装置は、さらに、
前記レスポンス送信手段が送信するパケットに含まれる前記データの再生開始時間が、前記ファイルを実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得手段と、
前記遅延時間取得手段が取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定手段と、
前記遅延判定手段が、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定手段とを備え、
前記レスポンス作成手段は、前記スキップ決定手段の決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、
前記レスポンス送信手段は、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信する
ことを特徴とする請求項１２記載のデータ送信装置。
【請求項１４】
コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化装置であって、
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成手段と、
前記同期情報作成手段が作成した同期情報を含むファイルを作成するファイル作成手段とを備える
ことを特徴とするデータ多重化装置。
【請求項１５】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続されたサーバ装置から受信するデータ受信装置のためのプログラムであって、
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、
前記データ取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するリクエスト送信ステップと、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１６】
コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続された端末装置に送信するデータ送信装置のためのプログラムであって、
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信ステップと、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成ステップと、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信ステップと
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップとをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１７】
コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化装置のためのプログラムであって、
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、
前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項１８】
コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化装置と、前記ファイルをネットワークで接続されたデータ受信装置に送信するデータ送信装置と、前記ファイルをネットワークで接続されたデータ送信装置から受信するデータ受信装置とを備えるストリーミング配信システムであって、
前記データ多重化装置は、
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成手段と、
前記同期情報作成手段が作成した同期情報を含むファイルを作成するファイル作成手段とを備え、
前記データ受信装置は、
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記データ送信装置に要求するデータ取得リクエストを作成するリクエスト作成手段と、
前記データ取得リクエストを、ＨＴＴＰによって前記データ送信装置に送信するリクエスト送信手段と、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記データ送信装置からＨＴＴＰによって受信するレスポンス受信手段と、
前記同期情報を用いて、前記メディアデータを再生する同期再生手段とを備え、
前記データ送信装置は、
前記データ受信装置から前記データ取得リクエストを受信するリクエスト受信手段と、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定手段と、
前記データ取得リクエストに対する応答として、前記レスポンスを作成するレスポンス作成手段と、
前記レスポンスを、ＨＴＴＰによって前記データ受信装置に送信するレスポンス送信手段とを備える
ことを特徴とするストリーミング配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画像データや音声データ等のメディアデータの多重化方法、多重化したデータの送信方法および多重化したデータの受信方法に関し、特に、ライブストリーミング再生を行なうためのデータ多重化方法、データ送信方法およびデータ受信方法に関する。
【背景技術】
【０００２】
近年、通信ネットワークの大容量化および伝送技術の進歩により、インターネット上で、動画、音声、テキスト、あるいは、静止画等のマルチメディアコンテンツを含む動画像ファイルをパーソナルコンピュータに配信する動画配信サービスの普及が著しい。また、携帯端末等のいわゆる第３世代の移動体通信システムの規格の標準化を図ることを目的とする国際標準化団体3GPP(Third Generation Partnership Project)で、無線による動画配信に関する規格としてTS26.234(Transparent end-to-end packet switched streaming service)が定められる等の動きも見られ、動画配信サービスは、携帯電話機やＰＤＡ等の移動体通信端末への提供の拡大も見込まれている。
【０００３】
動画配信サービスにおいて、動画像ファイルを配信する際には、まず、多重化装置において、動画、静止画、音声およびテキスト等のメディアデータを取り込んで、メディアデータの再生に必要なヘッダ情報とメディアデータの実体データとを多重化して動画像ファイルデータを作成することが必要となるが、この動画像ファイルデータの多重化ファイルフォーマットとして、ＭＰ４ファイルフォーマットが注目されている。
【０００４】
このＭＰ４ファイルフォーマットは、国際標準化団体であるISO/IEC(International Standardization Organization/International Engineering Consortium) JTC1/SC29/WG 11において標準化が進められている多重化ファイルフォーマットであり、上記3GPPのTS26.234でも採用されていることから、広く普及するものと予想されている。
ここで、ＭＰ４ファイルのデータ構造について説明する。なお、このＭＰ４ファイルのデータ構造については、非特許文献１に開示されている。
【０００５】
ＭＰ４ファイルは、ボックスと呼ばれるオブジェクト単位でヘッダ情報やメディアデータの実体データが格納されており、複数のボックスを階層的に配列することによって構成される。
【０００６】
図２２は、ＭＰ４ファイルを構成するボックスの構造を説明するための図である。
ボックス９０１は、ボックス９０１のヘッダ情報が格納されるボックスヘッダ部９０２と、ボックス９０１に含まれるデータ（例えば、そのボックスの下の階層のボックスや情報を記述するためのフィールド等）が格納されるボックスデータ格納部９０３とから構成される。
【０００７】
このボックスヘッダ部９０２は、ボックスサイズ９０４、ボックスタイプ９０５、バージョン９０６、フラグ９０７のフィールドを有している。
ボックスサイズ９０４は、このフィールドに割り当てられたバイトサイズも含めてボックス９０１全体のサイズ情報が記述されるフィールドである。
ボックスタイプ９０５は、ボックス９０１の種別を識別するための識別子が記述されるフィールドである。この識別子は、通常４つのアルファベット文字列によって表される。なお、以下、本明細書中において、この識別子によって各ボックスを示す場合がある。
【０００８】
バージョン９０６は、ボックス９０１のバージョンを示すバージョン番号が記述されるフィールドであり、フラグ９０７は、ボックス９０１毎に設定されるフラグ情報が記述されるフィールドである。このバージョン９０６とフラグ９０７は、全てのボックス９０１に必須のフィールドではないので、これらのフィールドを有しないボックス９０１も存在しうる。
【０００９】
このような構造のボックス９０１が複数連なって構成されるＭＰ４ファイルは、ファイルの構成に不可欠な基本部と、必要に応じて使用される拡張部とに大別することができる。まず、ＭＰ４ファイルの基本部について説明する。
図２３は、従来のＭＰ４ファイルの基本部を説明するための図である。
ＭＰ４ファイル９１０の基本部９１１は、ファイルヘッダ部９１２とファイルデータ部９１３とから構成される。
【００１０】
ファイルヘッダ部９１２は、ファイル全体のヘッダ情報、例えば、動画像（ビデオ）データの圧縮符号化方式等の情報が格納される部分であり、ファイルタイプボックス９１４とムービーボックス９１５とから構成される。
ファイルタイプボックス９１４は、"ｆｔｙｐ"の識別子で識別されるボックスであり、ＭＰ４ファイルを識別するための情報が格納される。ＭＰ４ファイルにどのようなメディアデータを格納するかについて、また、どのような圧縮符号化方式を用いた動画像（ビデオ）データや音声（オーディオ）データ等を格納するかについては、標準化団体やサービス事業者が独自に規定することができるため、ＭＰ４ファイルがどの規定に従って作成されたものであるかを識別するための情報を、このファイルタイプボックス９１４に格納する。
【００１１】
ムービーボックス９１５は、"ｍｏｏｖ"の識別子で識別されるボックスであり、ファイルデータ部９１３に格納される実体データのヘッダ情報、例えば、表示時間長等の情報が格納される。また、このムービーボックス９１５には、ビデオトラックやオーディオトラック等、トラック毎のヘッダ情報が格納されている。なお、ここにいうトラックとは、ＭＰ４ファイル９１０に含まれる各メディアのサンプルデータ全体を意味し、動画像や音声やテキスト等のトラックは、それぞれビデオトラック、オーディオトラックやテキストトラック等と称される。また、ＭＰ４ファイル９１０内に同一メディアのデータが複数存在する場合は、同一メディアに対して複数のトラックが存在することになる。具体的に説明すると、例えば、ＭＰ４ファイル９１０内に２種類の動画像データが含まれている場合、２つのビデオトラックが存在することになる。
【００１２】
ファイルデータ部９１３は、"ｍｄａｔ"の識別子で識別されるムービーデータボックス９１６によって構成される。なお、このファイルデータ部９１３の代わりに、このＭＰ４ファイル９１０とは異なる外部のファイルを参照することもできる。このように、外部のファイルを参照する場合には、ＭＰ４ファイル９１０の基本部９１１は、ファイルヘッダ部９１２のみから構成されることになる。本明細書では、この外部ファイルの参照をする場合ではなく、ＭＰ４ファイル９１０内に実体データを含む場合について説明する。
【００１３】
ムービーデータボックス９１６は、サンプルと称される単位でメディアデータの実体データを格納するボックスである。このサンプルとは、ＭＰ４ファイルにおける最小のアクセス単位であり、MPEG(Moving Picture Experts Group)-4 Visualの圧縮符号化方式によって符号化したビデオデータのVOP(Video Object Plane)やオーディオデータのフレームに相当するものである。
【００１４】
ＭＰ４ファイルフォーマットの標準化当初、ＭＰ４ファイル９１０は、上記基本部９１１のみから構成されていた。しかし、基本部９１１のみから構成されるＭＰ４ファイル９１０では、全てのヘッダ情報が格納されるムービーボックス９１５が、コンテンツ全体の符号化データが揃うまで作成されないので、コンサート中継やスポーツ中継等のライブコンテンツの配信、いわゆるライブストリーミングを実現することができないという問題があった。また、ライブコンテンツの時間長に比例してムービーボックス９１５のサイズが増大するため、ライブコンテンツが長時間になればなる程、ムービーボックス９１５のダウンロードに要する時間が長くなり、ストリーミング再生時における初期遅延時間が増大するという問題があった。
【００１５】
このように、標準化当初のＭＰ４ファイルフォーマットには、ストリーミング再生への適用が難しい等の問題があり、ＭＰ４ファイルフォーマットは、ヘッダボックスとデータボックスとの組が複数連なる拡張部の使用を加える改良がなされている。
【００１６】
図２４は、従来における拡張部を含むＭＰ４ファイルの構造を示す図である。
図２４に示すように、上記改良が加えられたＭＰ４ファイル９２０は、基本部９１１と拡張部９２１とから構成される。この拡張部９２１を含むＭＰ４ファイル９２０では、全てのメディアデータを拡張部９２１に格納することができるので、ＭＰ４ファイル基本部９１１のムービーデータボックス９１６を省略することとしてもよい。
【００１７】
拡張部９２１は、所定の単位で区切られたパケット９２２が複数連なって構成される。
このパケット９２２は、ムービーフラグメントボックス９２３とムービーデータボックス９１６とが一対となって構成され、ムービーフラグメントとも称される（以下、本明細書では、「フラグメント」と略記する。）
ムービーデータボックス９１６は、上記区切られた所定の単位でトラック毎のサンプルを格納し、ムービーフラグメントボックス９２３は、このムービーデータボックス９１６に対応するヘッダ情報を格納するためのボックスであり、"ｍｏｏｆ"という識別子によって識別される。
【００１８】
なお、このとき、ＭＰ４ファイル９２０の基本部９１１のムービーデータボックス９１６を省略した場合、基本部９１１のムービーボックス９１５には、コンテンツ全体に共通のヘッダ情報、例えば、コンテンツ全体の再生時間長や符号化方式等が格納されることになる。また、ＭＰ４ファイル９２０の基本部９１１のムービーデータボックス９１６を省略せずにコンテンツの先頭部分のデータが格納されている場合、基本部９１１のムービーボックス９１５には、コンテンツ全体に共通のヘッダ情報と、そのデータのサンプル単位のヘッダ情報が格納されることになる。本明細書では、ＭＰ４ファイル基本部９１１のムービーデータボックス９１６は省略され、基本部９１１のムービーボックス９１５には、上記共通のヘッダ情報のみが格納されていることとする。さらに、各フラグメントは、フラグメントに含まれる各メディアの先頭サンプルの再生開始時間が揃うように作成されているものとする。具体的には、オーディオデータやビデオデータ、あるいは、テキストデータのサンプルのうち、互いの再生開始時間が最も近いサンプルをフラグメントの先頭サンプルとして格納する。
【００１９】
このようなＭＰ４ファイルの改良によって、ビデオデータやオーディオデータを取り込んで符号化するエンコーダは、コンテンツ全体の符号化データが揃わなくても、所定の単位分の符号化データが揃った段階でフラグメントを生成することができ、また、ライブコンテンツを格納したＭＰ４ファイルをクライアント端末に配信するサーバは、フラグメント単位でＭＰ４ファイルをクライアント端末に配信することができるようになるので、ストリーミング再生を実現することが可能となっている。
【００２０】
また、サーバとクライアント端末とのデータのやり取りについては、通信プロトコルの規定に則る必要があるが、音声や映像をストリーミング再生するためのプロトコルとして、ＲＴＰ(Real-time Transport Protocol)やＵＤＰ(User Datagram Protocol)などの通信プロトコルが従来から用いられている。
【非特許文献１】ISO/IEC JTC1/SC29/WG11 MPEG、N5295「Proposed Revised Common Text Multimedia File Format Specification」、2002年10月24日
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、上記の改良が加えられたＭＰ４ファイルにおいても、受信側のクライアント端末は、ファイルの先頭に位置するフラグメントからしかデータを取得することができないので、例えば、ライブコンテンツの途中から受信を開始する場合であっても、ライブコンテンツの最初から再生しなければならず、ライブコンテンツを実時間で再生することができないという問題がある。図を用いて詳しく説明する。
【００２２】
図２５は、従来におけるＭＰ４ファイルによるライブストリーミング時における問題点を説明するための図である。
エンコーダ９３０は、ビデオカメラ等であり、コンサートの映像および音声を記録して、ビデオデータとオーディオデータとを符号化および多重化することによって生成したＭＰ４ファイルのフラグメントを順次配信サーバ９４０に転送する。ここで、エンコーダ９３０から配信サーバ９４０に転送される最新のフラグメントをフラグメントＮとしておく。また、ＭＰ４ファイルのファイルタイプボックスとムービーボックスとを併せて初期ヘッダと称することにする。
【００２３】
この時点で、クライアント端末９５０が、配信サーバ９４０にライブコンテンツの配信要求を送信すると、配信サーバ９４０は、初期ヘッダとＭＰ４ファイルの先頭のフラグメントをクライアント端末９５０に配信するので、クライアント端末９５０が再生するデータは、ライブコンテンツの実時間のデータに対して遅延してしまうことになり、ライブコンテンツをリアルタイムで再生することができない。
【００２４】
また、配信サーバ９４０とクライアント端末９５０とを接続するネットワークの輻輳などで、ライブコンテンツのデータを実時間で配信することができない場合にも、クライアント端末９５０が再生するデータと、ライブコンテンツの実時間のデータとの間に遅延が生じてしまうという問題がある。
【００２５】
さらに、ＲＴＰによる通信はリアルタイム性に優れるというメリットがあるものの、配信サーバおよびクライアント端末が共にＲＴＰに対応していなければならず、ＲＴＰに対応させるための増設コストがかかるという問題が生じうる。また、ＲＴＰでは、データが相手方に届くことは保証されないので、信頼性が低く、パケットロス対策などの品質制御機構が必要となるという問題もある。
【００２６】
そこで、本発明は、上記問題点に鑑みなされたものであり、増設コストをかけることなく、ライブコンテンツを格納したＭＰ４ファイルを実時間に対して低遅延で受信し、リアルタイムでの再生を実現することができるデータ受信方法を提供することを第１の目的とする。
また、本発明は、ネットワークの通信状態にかかわらず、リアルタイム性を維持してＭＰ４ファイルを低遅延で送信することができるデータ送信方法を提供することを第２の目的とする。
【００２７】
さらに、本発明は、ライブコンテンツを格納したＭＰ４ファイルを低遅延で送受信する場合に、ライブコンテンツを構成する複数のメディア間の同期再生を実現することができるデータ多重化方法を提供することを第３の目的とする。
【課題を解決するための手段】
【００２８】
上記第１の目的を達成するために、本発明に係るデータ受信方法は、コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続されたサーバ装置から受信するデータ受信方法であって、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、前記データ取得リクエストを、ＨＴＴＰ(Hypertext Transfer Protocol)によって前記サーバ装置に送信するリクエスト送信ステップと、前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとを含むことを特徴とする。これによって、既存のＨＴＴＰを用いて、最新のフラグメントから受信を開始することができるので、増設コストをかけずに、ライブコンテンツの実時間に対して低遅延でデータを受信することが可能となる。
【００２９】
また、上記第２の目的を達成するために、本発明に係るデータ送信方法は、コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続された端末装置に送信するデータ送信方法であって、前記端末装置から前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップと、送信されるパケットに含まれる前記データの再生開始時間が、実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得ステップと、前記遅延時間取得ステップにおいて取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定ステップと、前記遅延判定ステップにおいて、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定ステップとを含み、前記レスポンス作成ステップにおいて、前記スキップ決定ステップにおける決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、前記レスポンス送信ステップにおいて、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信することを特徴とする。これによって、ネットワークの通信状態が悪い場合でも、最新のフラグメントまでスキップすることができるので、リアルタイム性を維持してＭＰ４ファイルを低遅延で送信することができるようになる。
【００３０】
さらに、上記第３の目的を達成するために、本発明に係るデータ多重化方法は、コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化方法であって、１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとを含むことを特徴とする。これによって、ライブストリーミング再生時においても同期情報を参照することができるので、同期再生を担保することができる。
【００３１】
なお、本発明は、このようなデータ多重化方法、データ受信方法およびデータ送信方法として実現することができるだけでなく、このようなデータ多重化方法等に含まれる特徴的なステップを手段として備えたデータ多重化装置等として実現したり、また、それぞれの特徴的な全てのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
【発明の効果】
【００３２】
以上のように、本発明によれば、ライブコンテンツの実時間に対する遅延を生じさせずに、ＭＰ４ファイルのデータを取得することができるので、ライブコンテンツの途中から受信を開始する場合であっても、リアルタイム再生を実現することができるという効果が奏される。また、既存のＨＴＴＰを用いることができるので、サーバ装置や端末装置の増設コストが不要という効果もある。さらに、通信状態が悪い場合であっても、リアルタイム再生を維持することができ、ライブコンテンツを構成するメディア間の同期再生をも担保することができる。
【発明を実施するための最良の形態】
【００３３】
以下、本発明を実施するための最良の形態について詳細に説明する。
（実施の形態１）
まず、本発明の実施の形態１に係るライブストリーミングシステムについて説明する。
図１は、本発明の実施の形態１に係るライブストリーミングシステムの全体構成を示す図である。
【００３４】
このライブストリーミングシステムは、コンサート中継やスポーツ中継などのライブコンテンツをリアルタイムで配信する画像配信システムであり、コンサート等の映像や音声を記録して、ビデオデータとオーディオデータとを符号化および多重化するエンコーダ１０と、エンコーダ１０から多重化されたデータを取得して、蓄積させる配信サーバ２０と、配信サーバ２０からＨＴＴＰを用いてライブコンテンツのデータを受信するクライアント端末３０とから構成される。
【００３５】
ライブストリーミングシステムを構成するこれらの装置について、以下詳しく説明する。
図２は、クライアント端末３０の構成を示すブロック図である。
クライアント端末３０は、配信サーバ２０からライブコンテンツを格納したＭＰ４ファイルをリアルタイムで受信するデータ受信装置であり、具体的には、動画像再生機能付きの携帯電話機や、パーソナルコンピュータ、ＰＤＡ(Personal Digital Assistant)等である。そして、このクライアント端末３０は、コンテンツＵＲＬ取得部３０１、第１リクエスト作成部３０２、リクエスト送信部３０３、レスポンス受信部３０４、第１レスポンス解析部３０５、第２リクエスト作成部３０６、第２レスポンス解析部３０７、受信データメモリ３０８、フラグメント受信完了判定部３０９、多重化データ分離部３１０、ヘッダ解析部３１１、サンプルデータ取得部３１２および復号表示部３１３を備える。
【００３６】
コンテンツＵＲＬ取得部３０１は、ユーザが再生を所望するライブコンテンツのＵＲＬ(Uniform Resource Locator)の入力を受け付けて第１リクエスト作成部３０２および第２リクエスト作成部３０６に出力する処理部である。なお、ここで、コンテンツへのアクセスのためにＵＲＬを用いているが、コンテンツにアクセスするための情報であれば、ＵＲＬ以外の情報であってもよい。
【００３７】
第１リクエスト作成部３０２は、ＨＴＴＰを用いて、ＭＰ４ファイルの初期ヘッダおよび各フラグメントのサイズ情報の取得を配信サーバに要求するサイズ情報取得リクエストのコマンドを作成する処理部である。
リクエスト送信部３０３は、第１リクエスト作成部３０２および第２リクエスト作成部３０６が作成したリクエストを、ＨＴＴＰにより配信サーバ２０に送信する通信インターフェースである。
【００３８】
レスポンス受信部３０４は、リクエスト送信部３０３から送信されたリクエストに対する配信サーバ２０からの返信、すなわち、レスポンスをＨＴＴＰにより受信する通信インターフェースであり、第１リクエスト作成部３０２が作成したリクエストに対するレスポンスを第１レスポンス解析部３０５に出力し、第２リクエスト作成部３０６が作成したリクエストに対するレスポンスを第２レスポンス解析部３０７に出力する。
【００３９】
第１レスポンス解析部３０５は、レスポンス受信部３０４からサイズ情報取得リクエストに対するレスポンスであるサイズ情報レスポンスを取得して、第２リクエスト作成部３０６に、そのレスポンスのエンティティボディに含まれる初期ヘッダおよび各フラグメントのサイズ情報と、リクエスト作成命令を出力する処理部である。また、第１レスポンス解析部３０５は、各フラグメントのサイズ情報をフラグメント受信完了判定部３０９にも出力する。
【００４０】
第２リクエスト作成部３０６は、第１レスポンス解析部３０５から出力されるリクエスト作成命令を取得すると、第１レスポンス解析部３０５から出力される初期ヘッダおよび各フラグメントのサイズ情報に基づいて、ライブコンテンツを格納するＭＰ４ファイルの初期ヘッダおよび最新のフラグメントデータの取得を配信サーバ２０に要求する初期ヘッダ・フラグメント取得リクエストのコマンドを作成する処理部である。
【００４１】
第２レスポンス解析部３０７は、レスポンス受信部３０４から初期ヘッダ・フラグメント取得リクエストに対するレスポンスである初期ヘッダ・フラグメントレスポンスを取得して、そのレスポンスのエンティティボディに含まれる初期ヘッダや最新フラグメントのデータ、および以降のフラグメントデータを受信データメモリ３０８に蓄積させる処理部である。なお、ここでは、初期ヘッダや最新フラグメントのデータは、レスポンスのエンティティボディに含まれることとしているが、エンティティボディに限られず、レスポンスの一部として含まれていればよい。
【００４２】
受信データメモリ３０８は、受信した初期ヘッダやフラグメントデータを一時的に保持するキャッシュメモリやＲＡＭ（Random Access Memory）等である。
フラグメント受信完了判定部３０９は、第１レスポンス解析部３０５から取得した初期ヘッダおよびフラグメントのサイズ情報に基づいて、受信データメモリ３０８をチェックして初期ヘッダおよびフラグメントデータの受信が完了したか否かを判定する処理部であり、初期ヘッダおよびフラグメントデータの受信完了を判定すると、多重化データ分離部３１０に初期ヘッダおよびフラグメントデータの受信完了を知らせる情報と、そのサイズ情報とを含むフラグメント受信完了信号を出力する。なお、ここで、フラグメント受信完了判定部３０９は、フラグメントデータを構成するｍｏｏｆおよびｍｄａｔのヘッダに含まれるサイズ情報や、別途フラグメントに格納されたフラグメントのサイズ情報などを用いたり、そのフラグメントデータの次のフラグメントデータの受信開始を検知したりすることによって、フラグメントデータの受信完了を判定することとしてもよい。
【００４３】
多重化データ分離部３１０は、フラグメント受信完了判定部３０９からフラグメント受信完了信号を取得すると、サイズ情報に基づいて受信データメモリ３０８から受信が完了した初期ヘッダとフラグメントデータとを読み出して逆多重化する処理部である。なお、ここで、多重化データ分離部３１０は、フラグメントデータの全てを受信していなくても、ｍｏｏｆと、ｍｄａｔの先頭部分とを受信すれば再生を開始することとしてもよい。この場合、フラグメント受信完了判定部３０９で、予め定められた再生時間長分、あるいは、サイズ分のサンプルデータの受信完了等を基準として、ｍｄａｔのデータをどれだけ受信すれば復号および再生処理を開始するかを決定しておき、そのルールに従って多重化データ分離部３１０にフラグメント受信完了信号を出力することになる。
【００４４】
ヘッダ解析部３１１は、多重化データ分離部３１０によって逆多重化された初期ヘッダとフラグメントデータのうちヘッダ部分（ｍｏｏｆ）とを解析して、メディアデータの符号化レートやコンテンツの再生時間長等、メディアデータの解析に必要なメディア情報を取得する処理部である。
サンプル取得部３１２は、ヘッダ解析部３１１からサンプルのサイズや受信データメモリ３０８におけるサンプルの格納位置を取得して、取得した情報に基づいてサンプルの実体データ（サンプルデータ）を読み出して、復号表示部３１３に出力する処理部である。
【００４５】
復号表示部３１３は、ヘッダ解析部３１１が出力するサンプルの再生時間を取得し、その再生時間に従って、サンプル取得部３１２が出力するサンプルデータを復号化して、データを再生しディスプレイ等の表示装置に出力する処理部である。
図３は、配信サーバ２０の構成を示すブロック図である。
配信サーバ２０は、エンコーダ１０から取得した多重化データを蓄積させ、クライアント端末３０からのリクエストに応じて、ライブコンテンツを格納したＭＰ４ファイルをリアルタイムでクライアント端末３０に送信するデータ送信装置であり、具体的には、Ｗｅｂサーバ装置等である。そして、この配信サーバ２０は、多重化データ受信部２０１、多重化データ蓄積部２０２、リクエスト受信部２０３、リクエスト解析部２０４、サイズ情報取得部２０５、送信データ制御部２０６、送信データメモリ２０７およびレスポンス送信部２０８を備える。
【００４６】
多重化データ受信部２０１は、エンコーダ１０から多重化データを取得する通信インターフェースであり、取得した多重化データを順次、多重化データ蓄積部２０２に蓄積させる。
多重化データ蓄積部２０２は、多重化データ受信部２０１が受信した多重化データを一時的に保持するキャッシュメモリやＲＡＭ等である。
【００４７】
リクエスト受信部２０３は、クライアント端末３０から送信されたリクエストをＨＴＴＰにより受信する通信インターフェースであり、受信したリクエストをリクエスト解析部２０４に出力する。
リクエスト解析部２０４は、リクエスト受信部２０３から出力されたリクエストを解析する処理部であり、サイズ情報取得リクエストを解析すると、初期ヘッダと各フラグメントデータのサイズ情報の取得を指示するサイズ情報取得指示をサイズ情報取得部２０５に出力し、初期ヘッダ・フラグメント取得リクエストを解析すると、リクエスト中で指定されたデータの送信開始を指示する送信開始指示を送信データ制御部２０６に出力する。また、リクエスト解析部２０４は、クライアント端末３０から送信された接続の終了を要求する接続終了リクエストをリクエスト受信部２０３を介して取得し解析すると、接続を終了する旨のレスポンスの送信指示（接続終了指示）をレスポンス送信部２０８に出力する。
【００４８】
サイズ情報取得部２０５は、リクエスト解析部２０４から出力されるサイズ情報取得指示に基づいて、多重化データ蓄積部２０２に保持されている初期ヘッダおよびフラグメントデータを読み出して、それらのサイズ情報を取得する処理部であり、取得したサイズ情報、すなわち、初期ヘッダサイズおよびフラグメントサイズを送信データ制御部２０６に出力する。
【００４９】
送信データ制御部２０６は、リクエスト解析部２０４から出力される送信開始指示に基づいて、送信するデータをＨＴＴＰの送信単位であるｃｈｕｎｋ（チャンク）毎にまとめる処理部である。送信データ制御部２０６は、リクエスト解析部２０４から出力される送信開始指示がサイズ情報取得リクエストに基づくものである場合には、サイズ情報取得部２０５から出力されるサイズ情報を１ｃｈｕｎｋにまとめて送信するデータを送信データメモリ２０７に蓄積させ、レスポンス送信部２０８にそのｃｈｕｎｋの送信を指示するｃｈｕｎｋデータ送信指示を出力する。また、リクエスト解析部２０４から出力される送信開始指示が初期ヘッダ・フラグメント取得リクエストに基づくものである場合には、多重化データ蓄積部２０２に保持されている初期ヘッダやフラグメントデータを読み出して、１ｃｈｕｎｋにまとめて送信データを送信データメモリ２０７に蓄積させ、レスポンス送信部２０８にそのｃｈｕｎｋの送信を指示するｃｈｕｎｋデータ送信指示を出力する。なお、初期ヘッダおよびフラグメントデータについては、送信データメモリ２０７を介さずに、多重化データ蓄積部２０２から、直接レスポンス送信部２０８に入力することとしてもよい。
【００５０】
ここで、１ｃｈｕｎｋに複数のフラグメントデータを格納する、あるいは、１つのフラグメントデータを分割して複数のｃｈｕｎｋに格納することも可能であるが、１フラグメントを複数のｃｈｕｎｋに格納するとオーバーヘッドが増加しうるので、１ｃｈｕｎｋに１つのフラグメントデータを格納するのが望ましい。また、初期ヘッダとフラグメントデータとを同時に取得を求める初期ヘッダ・フラグメント取得リクエストに対しては、１ｃｈｕｎｋに初期ヘッダとフラグメントデータとを含めてもよいし、１ｃｈｕｎｋに初期ヘッダを含めて、他の１ｃｈｕｎｋにフラグメントデータを含めることとしてもよい。
【００５１】
送信データメモリ２０７は、送信データ制御部２０６から出力される送信データを一時的に保持するキャッシュメモリやＲＡＭ等である。
レスポンス送信部２０８は、送信データ制御部２０６から出力されるｃｈｕｎｋデータ送信指示に基づいて、送信データメモリ２０７に保持されている送信データを読み出し、その送信データをエンティティボディに含むレスポンスをＨＴＴＰによりクライアント端末３０に送信する通信インターフェースである。また、レスポンス送信部２０８は、リクエスト解析部２０４から出力される接続終了指示を取得すると、接続の終了を示すレスポンスをＨＴＴＰによりクライアント端末３０に送信する。
【００５２】
図４は、エンコーダ１０の構成を示すブロック図である。
エンコーダ１０は、コンサート等の映像や音声を記録して、ビデオデータとオーディオデータとを符号化および多重化する多重化装置であり、具体的には、デジタルビデオカメラ等である。そして、このエンコーダ１０は、ビデオ符号化部１０１、ビデオデータ蓄積部１０２、オーディオ符号化部１０３、オーディオデータ蓄積部１０４、パケット作成命令部１０５、パケットヘッダ作成部１０６、パケットサイズ判定部１０７、サイズ調整部１０８、パケットデータ作成部１０９およびパケット結合部１１０を備える。
【００５３】
ビデオ符号化部１０１は、ビデオデータを取り込んで、ＭＰＥＧ−４  Ｖｉｓｕａｌ等の符号化方式により符号化する処理部であり、符号化したビデオデータを順次、ビデオデータ蓄積部１０２に蓄積させる。このビデオ符号化部１０１は、全てのフラグメントのサイズが予め設定されている設定フラグメントサイズと等しくなるように、単位時間当たりの最大データ量が予め設定されている範囲以下となるように符号化を行なう。具体的には、フラグメントの時間長が２ｓであり、ビットレートが６４０００ｂｐｓである場合には、０ｓ−２ｓ、２ｓ−４ｓ、４ｓ−６ｓ・・・の各フラグメントのデータ量が、１２８０００ｂｉｔ（２×６４０００）以下となるように符号化を行なう。
【００５４】
ビデオデータ蓄積部１０２は、符号化後のビデオデータを一時的に保持するキャッシュメモリやＲＡＭ等である。
オーディオ符号化部１０３は、オーディオデータを取り込んで、ＭＰＥＧ−４  ＡＡＣ等の符号化方式により符号化する処理部であり、符号化したオーディオデータを順次、オーディオデータ蓄積部１０４に蓄積させる。このオーディオ符号化部１０３もビデオ符号化部１０１と同様に、全てのフラグメントのサイズが設定フラグメントサイズと等しくなるように、単位時間当たりの最大データ量が予め設定されている範囲以下となるように符号化を行なう。ここで、ビデオおよびオーディオフラグメントにおける設定フラグメントサイズ決定時には、まず、ビデオおよびオーディオのフレームレートが一定であるか、また、オーディオのサンプルサイズが一定であるか等に基づいて、作成されるｍｏｏｆのサイズを見積もる。そして、ｍｄａｔのサイズについては、ビデオおよびオーディオのビットレートから見積もり、ｍｏｏｆとｍｄａｔのサイズの和を設定フラグメントとする。なお、見積もられたｍｏｏｆとｍｄａｔのサイズ和よりも大きいサイズを、設定フラグメントサイズとしてもよい。
【００５５】
オーディオデータ蓄積部１０４は、符号化後のオーディオデータを一時的に保持するキャッシュメモリやＲＡＭ等である。
パケット作成命令部１０５は、予め定められたフラグメントの時間長に基づいて、ビデオデータ蓄積部１０２とオーディオデータ蓄積部１０４とをチェックして、その時間長分のビデオデータおよびオーディオデータの符号化が完了したか否かを判定する処理部である。なお、符号化されたビデオデータおよびオーディオデータのサイズにより、符号化の完了を判定することとしてもよい。このパケット作成命令部１０５は、所定の時間長分のビデオデータおよびオーディオデータの符号化完了を判定する毎に、パケットヘッダ作成部１０６にパケットヘッダ部、すなわちｍｏｏｆの作成を指示するパケット作成開始信号を出力する。
【００５６】
パケットヘッダ作成部１０６は、パケット（フラグメント）のヘッダ情報が格納されるｍｏｏｆを作成する処理部であり、ＣＰＵやメモリによって実現される。パケットヘッダ作成部１０６は、パケット作成命令部１０５から出力されるパケット作成開始信号を取得すると、ビデオデータ蓄積部１０２に保持されている符号化済みのビデオデータのヘッダ情報（ビデオヘッダ情報）を読み出し、また、オーディオデータ蓄積部１０４に保持されている符号化済みのオーディオデータのヘッダ情報（オーディオヘッダ情報）を読み出してｍｏｏｆを作成し、パケット結合部１１０に出力する。なお、ビデオヘッダ情報には、ビデオサンプルのサイズ、再生時間長およびイントラフレームであるか否かを示す情報が含まれ、さらに、双方向予測を用いたビデオサンプルの場合には、復号時間と表示時間の差分情報も含まれる。そして、オーディオヘッダ情報には、オーディオサンプルのサイズおよび再生時間長を示す情報が含まれている。
【００５７】
また、パケットヘッダ作成部１０６は、フラグメントに含まれるビデオサンプルおよびオーディオサンプルの実体データが、ビデオデータ蓄積部１０２およびオーディオデータ蓄積部１０４のどこに格納されているかを示すポインタ情報や、サンプルのサイズを示すサンプルサイズ情報や、パケットデータ部（ｍｄａｔ）の作成を指示する信号が含まれるｍｄａｔ情報をパケットデータ作成部１０９に出力する。
【００５８】
さらに、このパケットヘッダ作成部１０６は、ｍｏｏｆのサイズおよびｍｏｏｆ内のサンプルサイズ情報からパケットデータ部（ｍｄａｔ）のサイズを取得し、ｍｏｏｆとｍｄａｔのサイズの和をフラグメントサイズとして、パケットサイズ判定部１０７に出力する。
パケットサイズ判定部１０７は、パケットヘッダ作成部１０６から出力されるフラグメントサイズが、設定フラグメントサイズと一致するか否かを判定する処理部であり、一致していない場合には、その差分を示すサイズ差分情報をサイズ調整部１０８に出力する。なお、フラグメントサイズと設定フラグメントサイズとが一致している場合には、差分が０であることを示すサイズ差分情報をサイズ調整部１０８に出力する。
【００５９】
サイズ調整部１０８は、パケットサイズ判定部１０７から出力されるサイズ差分情報に基づいて、全てのフラグメントのサイズを統一するためにフラグメントのサイズを調整する処理部であり、フラグメントサイズと設定フラグメントサイズとの差分を示すサイズ差分情報を取得した場合には、その差分と等しいバイトサイズのパディングデータを含むフリーボックスを作成して、作成したフリーボックスをｍｏｏｆとｍｄａｔの後ろに追加する旨の指示であるフリーボックス情報とともにパケット結合部１１０に出力する。ここで、フリーボックスの最小サイズは８バイトであるため、設定フラグメントサイズの計算時、あるいは、ビデオデータおよびオーディオデータの符号化時に、作成されるフラグメントサイズが設定フラグメントサイズと同一、あるいは、８バイト以上小さくなるように処理する必要がある。一方、サイズ調整部１０８は、差分が０であることを示すサイズ差分情報を取得した場合には、フリーボックスを作成せずに、フリーボックスの追加が発生しないことを示すフリーボックス情報をパケット結合部１１０に出力する。
【００６０】
パケットデータ作成部１０９は、フラグメントの実体データが格納されるｍｄａｔを作成する処理部であり、ＣＰＵやメモリによって実現される。
このパケットデータ作成部１０９は、パケットヘッダ作成部１０６からｍｄａｔ情報を取得すると、ｍｄａｔ情報に含まれるポインタ情報とサンプルサイズ情報とに基づいて、ビデオデータ蓄積部１０２からフラグメントに含まれるビデオサンプルの実体データ（ビデオフラグメントデータ）を読み出し、オーディオデータ蓄積部１０４からフラグメントに含まれるオーディオサンプルの実体データ（オーディオフラグメントデータ）を読み出してｍｄａｔを作成し、パケット結合部１１４に出力する。
【００６１】
パケット結合部１１０は、ｍｏｏｆとｍｄａｔとを結合させて、または、ｍｏｏｆとｍｄａｔを結合させた後ろにフリーボックスを追加して、フラグメントを作成する処理部であり、ＣＰＵやメモリによって実現される。このパケット結合部１１４は、パケットヘッダ作成部１０６からｍｏｏｆを取得し、パケットデータ作成部１０９からｍｄａｔを取得して、ｍｏｏｆとｍｄａｔとを結合させる。ここで、パケット結合部１１０は、サイズ調整部１０８からフリーボックスを追加する旨のフリーボックス情報を取得すると、サイズ調整部１０９からフリーボックスを取得して、ｍｏｏｆとｍｄａｔの後ろに追加してフラグメントを作成する。一方、パケット結合部１１０は、フリーボックスの追加が発生しないことを示すフリーボックス情報を取得すると、結合させたｍｏｏｆとｍｄａｔとをフラグメントとして取り扱う。そして、パケット結合部１１０は、このようにして作成したフラグメントを多重化データとして、順次配信サーバ２０に転送する。なお、ここで、フリーボックスは、ｍｏｏｆとｍｄａｔの間に挟んで、あるいは、ｍｏｏｆの前に配置することとしてもよい。
【００６２】
このような構成を備えた各装置は、ライブストリーミングシステムにおいて次のように動作する。
図５は、ライブストリーミングシステムにおける各装置間の通信シーケンス図である。
まず、エンコーダ１０は、ライブコンテンツの録画を開始するにあたって、初期ヘッダを作成し（Ｓ１０）、作成した初期ヘッダを配信サーバ２０に転送する（Ｓ１２）。
【００６３】
初期ヘッダを配信サーバ２０に転送すると、エンコーダ１０は、ライブコンテンツを構成するビデオデータとオーディオデータとを取得して（Ｓ１４）、符号化処理を開始する（Ｓ１６）。
エンコーダ１０は、所定のデータ量のビデオデータおよびオーディオデータの符号化を終えると、多重化して最初のフラグメント１を作成して、配信サーバ２０に転送する（Ｓ１８）。その後、エンコーダ１０は、所定のデータ量のビデオデータおよびオーディオデータの符号化を終える度に、多重化してフラグメント２、フラグメント３というように、順次作成したフラグメントを配信サーバ２０に転送する。
【００６４】
ここで、クライアント端末３０に、ユーザからのライブコンテンツのＵＲＬの入力があると、クライアント端末３０は、サイズ情報取得リクエストを作成して（Ｓ２０）、配信サーバ２０にＨＴＴＰにより送信する（Ｓ２２）。
配信サーバ２０は、サイズ情報取得リクエストを受信すると、そのリクエストに対するレスポンスのエンティティボディにサイズ情報を含めてクライアント端末３０にＨＴＴＰにより送信する（Ｓ２４）。
【００６５】
続いて、クライアント端末３０は、受信したレスポンスのエンティティボディに含まれるサイズ情報を参照して、初期ヘッダおよび最新のフラグメントの取得を要求するリクエストを作成し（Ｓ２６）、作成した初期ヘッダ・最新フラグメント取得リクエストを配信サーバ２０に送信する（Ｓ２８）。
配信サーバ２０は、初期ヘッダ・最新フラグメント取得リクエストを受信すると、送信可能な最新のフラグメントを判定する（Ｓ３０）。本図では、送信可能となっている、すなわち、配信サーバ３０に蓄積されている最新のフラグメントは、フラグメントＮであることから、配信サーバ３０は、初期ヘッダ・最新フラグメント取得リクエストに対するレスポンスのエンティティボディに初期ヘッダとフラグメントＮとを含めてクライアント端末３０に送信する（Ｓ３２）。
【００６６】
そして、クライアント端末３０は、受信した初期ヘッダとフラグメントＮに含まれるｍｏｏｆとを解析して、フラグメントＮのｍｄａｔに格納されている実体データを逆多重化して、ディスプレイ等の表示装置に再生出力する（Ｓ３４）。
その後、ＭＰ４ファイルを構成する最後のフラグメントに至るまで、配信サーバ２０は、エンコーダ１０から、フラグメント（Ｎ＋１）、フラグメント（Ｎ＋２）というように順次転送されるフラグメントをクライアント端末３０にＨＴＴＰを用いて送信し、クライアント端末３０は、受信したフラグメントを再生出力して、ライブコンテンツのストリーミング再生を行なう。
【００６７】
ここで、配信サーバ２０とクライアント端末３０間のＨＴＴＰを用いたリクエストおよびレスポンスの送受信について説明する。
図６は、ＨＴＴＰを用いた配信サーバ２０とクライアント端末３０間の通信シーケンスの第１例を示す図である。
まず、クライアント端末３０は、サイズ情報取得リクエストを配信サーバ２０に送信する（Ｓ４０）。ここで送信されるサイズ情報取得リクエストには、リクエストがデータの取得を要求するものであることを示すメソッド(GET)と、取得要求の対象となるファイルのＵＲＬ（http://…/….mp4）と、サイズ情報の取得であることを示すＨＴＴＰの拡張部(&size#1 &size#2)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
【００６８】
配信サーバ２０は、サイズ情報取得リクエストを受信すると、リクエストが成功したことをクライアント端末３０に通知するレスポンスをクライアント端末３０に送信する（Ｓ４２）。ここで送信されるレスポンスには、ＨＴＴＰのバージョン(HTTP/1.1)と、リクエストの成功を示すステータスコード(200)と、そのステータスコードの意味(OK)とが含まれている。
【００６９】
そして、リクエストの成功をクライアント端末３０に通知するレスポンスを送信した後、配信サーバ２０は、エンティティボディに初期ヘッダのサイズ情報と、１フラグメントのサイズ情報とを含めたレスポンスをクライアント端末３０に送信する（Ｓ４４）。
クライアント端末３０は、初期ヘッダおよびフラグメントのサイズ情報を取得すると、そのサイズ情報に基づいて、初期ヘッダ・最新フラグメント取得リクエストを配信サーバ２０に送信する（Ｓ４６）。ここで送信される初期ヘッダ・最新フラグメント取得リクエストには、先に述べたサイズ情報取得リクエストと同様に、メソッド(GET)、ＵＲＬ（http://…/….mp4）およびＨＴＴＰバージョン(HTTP/1.1)に加えて、リクエストヘッダフィールドが含まれており、このリクエストヘッダフィールドにデータの取得範囲(:Range byte=0-999,-15000)が記述されている。本図では、初期ヘッダのサイズが１０００バイトであり、１フラグメントのサイズが１５０００バイトである場合の初期ヘッダ・最新フラグメント取得リクエストを示している。ここで、"−１５０００"としているのは、ファイルの終端から、１５０００バイト分、遡った位置にあるデータの取得を意味している。また、本実施の形態１のエンコーダ１０では、サイズが一定となるように各フラグメントは生成されているので、一旦受信を中断した後に、同一のコンテンツの受信を再開する際などにも、各フラグメントのサイズ情報を取得するためのリクエストおよびレスポンスの送受信を行なう必要がない。なお、フラグメントのサイズ情報を取得する代わりに、最新フラグメントのファイル先頭からのバイト位置を取得することとしてもよい。このとき、最新フラグメント取得リクエストにおいては、取得したバイト位置のフラグメントデータから送信開始することを要求する。ただし、受信中断後に同一コンテンツの受信を再開する際などには、毎回バイト位置情報が必要となる。
【００７０】
その後、配信サーバ２０は、初期ヘッダ・最新フラグメント取得リクエストを受信すると、サイズ情報取得リクエストの場合と同様に、リクエストが成功したことをクライアント端末３０に通知するレスポンスをクライアント端末３０に送信する（Ｓ４８）。
そして、リクエストの成功をクライアント端末３０に通知するレスポンスを送信した後、配信サーバ２０は、エンティティボディに初期ヘッダと、最新のフラグメントであるフラグメントＮとを含めたレスポンスをクライアント端末３０に送信し（Ｓ５０）、送信の中断を要求するリクエストの受信、あるいは、クライアント端末３０の電波受信状況が悪化して配信サーバ２０との接続が切断されること等がない限り、ＭＰ４ファイルの終端のフラグメントに至るまで、フラグメントの送信を続ける（Ｓ５２）。このとき、配信サーバ２０は、送信データを任意の大きさのｃｈｕｎｋに分け、そのｃｈｕｎｋの大きさが記述されたヘッダをつけて送信するｃｈｕｎｋ形式エンコーディング方式により、初期ヘッダやフラグメントデータをクライアント端末３０に送信する。なお、このｃｈｕｎｋ形式エンコーディング方式では、ｃｈｕｎｋサイズが０であるｃｈｕｎｋを送信することによって、配信サーバ２０は、送信が終了したことをクライアント端末３０にシグナリングする。
【００７１】
このように本実施の形態１に係るライブストリーミングシステムによれば、ライブコンテンツの途中からストリーミング再生を開始する場合であっても、クライアント端末３０は、初期ヘッダと、ライブコンテンツの最新部分のデータを含むフラグメントから受信を開始することができるので、ライブコンテンツを、実時間に対して低遅延で受信してリアルタイムで再生することができるようになる。
【００７２】
ここで、ライブコンテンツの最新部分のデータを含むフラグメント、すなわち、最新フラグメントとは、厳密に最新のものである必要はなく、例えば、最新フラグメントの１つ前、或いは、２つ前のフラグメント等を意味するものであってもよい。
また、上記実施の形態１では、クライアント端末３０は、配信サーバ２０から初期ヘッダおよびフラグメントのサイズ情報を取得し、そのサイズ情報に基づいて、初期ヘッダおよび最新フラグメントを取得するためのリクエストを送信することとしているが、サイズ情報の取得を要求するリクエストを行なうことなく、初期ヘッダと最新フラグメントを取得することとしてもよい。
【００７３】
このような場合における配信サーバ２０とクライアント端末３０間のＨＴＴＰを用いたリクエストおよびレスポンスの送受信は、以下のようになる。
図７は、ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第２例を示す図である。
まず、クライアント端末３０は、初期ヘッダを取得するためのリクエストを配信サーバ２０に送信する（Ｓ６０）。ここで送信されるリクエストには、リクエストがデータの取得を要求するものであることを示すメソッド(GET)と、取得要求の対象となるファイルのＵＲＬ（http://…/….mp4）と、初期ヘッダの取得要求であることを示すＨＴＴＰの拡張部(&init)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
【００７４】
配信サーバ２０は、この初期ヘッダ取得リクエストを受信すると、上記の場合と同様に、リクエスト成功レスポンスをクライアント端末３０に送信する（Ｓ６２）。
そして、配信サーバ２０は、リクエスト成功レスポンスを送信した後、初期ヘッダ取得リクエストのＨＴＴＰの拡張部(&init)から、そのリクエストが初期ヘッダの取得要求であることを識別し、エンティティボディに初期ヘッダを含めたレスポンスをクライアント端末３０に送信する（Ｓ６４）。
【００７５】
続いて、クライアント端末３０は、最新フラグメントを取得するためのリクエストを配信サーバ２０に送信する（Ｓ６６）。ここで送信されるリクエストには、先に述べた初期ヘッダ取得リクエストと同様に、メソッド(GET)と、ＵＲＬ（http://…/….mp4）と、最新フラグメントの取得要求であることを示すＨＴＴＰの拡張部(&frag)と、ＨＴＴＰバージョン(HTTP/1.1)とが含まれている。
【００７６】
配信サーバ２０は、この最新フラグメント取得リクエストを受信すると、上記の場合と同様に、リクエスト成功レスポンスをクライアント端末３０に送信する（Ｓ６８）。
そして、配信サーバ２０は、リクエスト成功レスポンスを送信した後、最新フラグメント取得リクエストのＨＴＴＰの拡張部(&frag)から、そのリクエストが最新フラグメントの取得要求であることを識別し、エンティティボディに最新フラグメントを含めたレスポンスをクライアント端末３０に送信し（Ｓ７０）、送信の中断を要求するリクエストの受信等がない限り、ＭＰ４ファイルの終端のフラグメントに至るまで、フラグメントの送信を続ける（Ｓ７２）。
【００７７】
このように、配信サーバ２０に、ＨＴＴＰの拡張部を解析する機能を持たせることによって、サイズ情報の取得を要求するリクエストとそのリクエストに対するレスポンスを行なわなくても、初期ヘッダと最新フラグメントを取得することができるようになる。また、本方法では、各フラグメントのサイズを一定とすることなしに、受信中断後に再開する際などにも、サイズ情報の取得を要求するリクエストとそのリクエストに対するレスポンスを省略することができる。
【００７８】
また、上記では、配信サーバ２０には、コンテンツの先頭フラグメントから最新フラグメントまでの全てのフラグメントがＭＰ４ファイルとして蓄積されていることとしたが、初期ヘッダおよび最新フラグメントのみを蓄積することとしてもよい。
ここで、初期ヘッダと最新フラグメントにそれぞれ異なるＵＲＬを持たせれば、初期ヘッダと最新フラグメントのＵＲＬに対してＧＥＴ要求を行なうことにより、クライアント端末３０はコンテンツ受信を開始することができる。また、配信サーバ２０では、クライアント端末３０に対してフラグメントデータの送信が開始されると、以降は最新フラグメントを順次送信することとする。この方式によれば、ＨＴＴＰの拡張は不要となる。
【００７９】
なお、配信サーバ２０においては、全てのフラグメントデータが揃った完全なＭＰ４ファイルを別途蓄積しておき、クライアント端末３０は、再送要求などを行なう際に、完全なＭＰ４ファイルに対してデータ取得要求を行なうこととしてもよい。
【００８０】
（実施の形態２）
次に、本発明の実施の形態２に係るライブストリーミングシステムについて説明する。
本実施の形態２に係るライブストリーミングシステムは、大枠の構成を上記実施の形態１と同一とするが、配信サーバの構成において異なる。以下、この異なる点を中心に説明する。なお、上記実施の形態１と同一の構成要素については、同一の符号を付し、その説明を省略する。
図８は、本実施の形態２に係るライブストリーミングシステムにおける配信サーバの構成を示すブロック図である。
【００８１】
この配信サーバ２０ａは、遅延判定部２１１を備えており、送信データ制御部２１６およびレスポンス送信部２１８における機能の点で、上記実施の形態１における配信サーバ２０と異なる。
遅延判定部２１１は、配信サーバ２０ａが、クライアント端末３０からコンテンツの受信要求を受けて、クライアント端末３０に向けて最初のフラグメント（ここでは、フラグメントＮとしておく。）の送信を開始してからの経過時間を計測するタイマーを有しており、この経過時間と、次に送信される予定であるフラグメントの直前のフラグメントまでの再生時間長の総和（ここでは、ｓｕｍ＿ｄｕｒａｔｉｏｎとしておく。）との差分値を、フラグメント送信時における遅延時間として計算する処理部である。この遅延判定部２１１は、レスポンス送信部２１８からフラグメントＮの送信開始を示す送信開始信号を取得することにより、経過時間の計測を開始し、また、送信データ制御部２１６から随時、各フラグメントの再生時間長を取得して、実際に送信したフラグメントではなくコンテンツを格納したＭＰ４ファイル内に含まれる全てのフラグメントの再生時間長を加算することにより、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。ここで、遅延時間の計算は、次に送信するフラグメントを決定する直前に行なうこととするが、一定の周期で遅延時間を計算することとしてもよい。
【００８２】
そして、この遅延判定部２１１は、計算した遅延時間が所定の閾値以下であるか否かを判定し、所定の閾値より遅延時間が大きくなると、現在送信中のフラグメントに続く送信予定のフラグメントをスキップすることを指示するスキップ指示を送信データ制御部２１６に出力する。
【００８３】
具体的には、遅延判定部２１１は、以下のような手順で、スキップの有無を判定する。
まず、遅延判定部２１１は、送信データ制御部２１６から各フラグメントの再生時間長を取得し、次に送信する予定のフラグメントをｉ番目のフラグメントであると仮定して、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。
そして、計測した経過時間からｓｕｍ＿ｄｕｒａｔｉｏｎを減算した値、すなわち、両者の差分値（遅延時間）が、所定の閾値より大きいか否かを判定する。
ここで、遅延時間が所定の閾値以下であれば、スキップを行なわないことを決定し、送信データ制御部２１６にスキップが発生しないことを通知する信号を出力する。
【００８４】
一方、遅延時間が所定の閾値より大きい場合は、送信データ制御部２１６からｉ番目のフラグメントの再生時間長を取得し、次に送信する予定のフラグメントをｉ＋１番目のフラグメントであると仮定して、ｓｕｍ＿ｄｕｒａｔｉｏｎの値を更新する。
【００８５】
そして、経過時間から更新されたｓｕｍ＿ｄｕｒａｔｉｏｎを減算して、遅延時間を更新し、再び、所定の閾値より大きいか否かを判定し、遅延時間が所定の閾値以下になるまで、このｓｕｍ＿ｄｕｒａｔｉｏｎの更新を繰り返す。
ここで、次に送信する予定のフラグメントをｉ＋ｎ番目のフラグメントと仮定した時に、遅延時間が所定の閾値以下となった場合、遅延判定部２１１は、ｉ＋（ｎ−１）番目までのフラグメントをスキップする旨のスキップ指示を送信データ制御部２１６に出力する。
【００８６】
このような手順で、遅延判定部２１１は、スキップの有無を判定する。
なお、クライアント端末３０において、受信したフラグメントの遅延時間情報を取得して配信サーバ２０ａに通知し、配信サーバ２０ａにおいては、通知された遅延時間情報に基づいてスキップを判定することとしてもよい。このとき、全フラグメントの再生時間長を一定にしておき、予め定められた規則に従って設定されたフラグメントのシーケンス番号をもとに、クライアント端末３０において、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。また、フラグメントに含まれる各メディアの先頭サンプルの再生開始時間を、フラグメント内に格納する等してクライアント端末３０に通知することにより、クライアント端末３０でｓｕｍ＿ｄｕｒａｔｉｏｎを計算してもよい。なお、クライアント端末３０における、フラグメントのデータを受信して再生する際の再生開始時間と、ＭＰ４ファイルを実時間で再生した際の当該パケットの再生開始時間との差分値に基づいていれば、上記以外の方法で遅延時間を計算することとしてもよい。
【００８７】
送信データ制御部２１６は、遅延判定部２１１から出力されるスキップ指示に基づいて、送信する予定であったフラグメントをスキップして、スキップ後のフラグメントを１ｃｈｕｎｋにまとめて送信データを作成し、送信データメモリ２０７に蓄積させる。なお、遅延判定部２１１からスキップが発生しないことを通知する信号を取得した場合には、スキップをせずに、送信する予定のフラグメントを１ｃｈｕｎｋにまとめて送信データを作成し、送信データメモリ２０７に蓄積させる。
【００８８】
また、送信データ制御部２１６は、レスポンス送信部２１８からｃｈｕｎｋの送信が完了したことを示す送信完了信号を取得してから、次に送信すべきｃｈｕｎｋデータの送信指示をレスポンス送信部２１８に出力する。ここで、１ｃｈｕｎｋに複数のフラグメントデータを格納し、配信サーバ２０ａにおいてｃｈｕｎｋ単位で送信管理を行なうとすれば、遅延時間によりスキップを判定する際の粒度が荒くなるので、上記実施の形態１と同様に、１ｃｈｕｎｋに１つのフラグメントデータを格納することによって、遅延時間によりスキップを判定する際の粒度が荒くなることを防止することができる。
【００８９】
このような構成を備えた配信サーバ２０ａを有するライブストリーミングシステムは、以下のように動作する。
図９は、実施の形態２に係るライブストリーミングシステムにおける各装置間の通信シーケンス図である。本図では、上記実施の形態１におけるサイズ情報取得リクエストの送信や、サイズ情報取得リクエストに対するレスポンス等が既に行なわれ、ライブストリーミング再生が行なわれている状況から説明する。
【００９０】
まず、上記実施の形態１と同様に、エンコーダ１０は、ライブコンテンツを構成するビデオデータやオーディオデータを取り込んで（Ｓ１００）、符号化および多重化して配信サーバ２０ａに順次フラグメントを転送し（Ｓ１０２）、配信サーバ２０ａは、フラグメントをクライアント端末３０にＨＴＴＰを用いて送信して（Ｓ１０４）、クライアント端末３０は、ＨＴＴＰを用いて受信したフラグメントを再生出力する（Ｓ１０６）。
【００９１】
ここで、配信サーバ２０ａからクライアント端末３０にフラグメントを送信する伝送路に輻輳等が生じたり、クライアント端末３０の受信状況が悪化したりすると、配信サーバ２０ａからクライアント端末３０へのフラグメントの送信時間（本図に示すｄｌ＿ｔｉｍｅ）が長くなる（Ｓ１０８）。
この間、配信サーバ２０ａは、エンコーダ１０から順次転送されてくるフラグメントを蓄積させていく。
【００９２】
ここで、フラグメント（Ｎ＋２）をスキップせずに送信するためには、フラグメント（Ｎ＋１）の送信を、図中のｄｌ＿ｌｉｍｉｔで示す時間内に完了しなければならないとする。実際には、フラグメント（Ｎ＋１）の送信には、図中のｄｌ#ｔｉｍｅで示す時間がかかったために、フラグメント（Ｎ＋２）がスキップされる。
そして、配信サーバ２０ａは、スキップ後の最新フラグメント（Ｎ＋３）をクライアント端末３０にＨＴＴＰを用いて送信し（Ｓ１１２）、クライアント端末３０は、ＨＴＴＰを用いて受信したフラグメント（Ｎ＋３）を再生出力する（Ｓ１１４）。
【００９３】
その後、上記実施の形態１と同様に、ＭＰ４ファイルを構成する最後のフラグメントに至るまで、配信サーバ２０ａは、エンコーダ１０から、フラグメント（Ｎ＋４）、フラグメント（Ｎ＋５）というように順次転送されるフラグメントをクライアント端末３０にＨＴＴＰを用いて送信し、クライアント端末３０は、受信したフラグメントを再生出力して、ライブコンテンツのストリーミング再生を行なう。
【００９４】
このように、本実施の形態２に係るライブストリーミングシステムによれば、ネットワークの輻輳や受信状態の悪化などによって、実時間でデータを伝送しきれず、受信端末側の受信データとライブデータとの間に時間的なギャップが発生する場合であっても、以後のフラグメントをスキップして送信するので、受信端末側におけるリアルタイム再生を担保することができる。
【００９５】
なお、本実施の形態２では、フラグメントのスキップを行なう場合には、再生されるフラグメントが時間的に不連続となることもあるので、設定によってスキップをしないモードとスキップを行なうモードとに分けてデータの取得を可能とするようにしてもよい。この場合、例えば、フラグメントを取得する際のリクエストを拡張して、そのＨＴＴＰ拡張部に、スキップをしないモードでデータ取得を要求する旨を示す情報（&No-Skip）を含めて配信サーバ２０ａに送信し、配信サーバ２０ａは、この情報が含まれているリクエストを受信した場合には、スキップ判定を行なわない等とすればよい。あるいは、端末側でコンテンツ取得用に複数のＵＲＬを選択できるようにしておき、コンテンツの受信をリクエストするＵＲＬに依存して、スキップあり／なし、のいずれのモードで受信するかを選択できるようにしてもよい。
【００９６】
（実施の形態３）
続いて、本発明の実施の形態３に係るライブストリーミングシステムについて説明する。
上記実施の形態１では、最新のフラグメントからの再生を可能として、低遅延でのライブストリーミング再生を実現することについて説明した。また、上記実施の形態２では、伝送路における輻輳が発生した場合等でも、最新のフラグメントまで以後のフラグメントをスキップすることを可能として、リアルタイム再生を実現することについて説明した。
上記いずれの実施の形態においても、ＭＰ４ファイルの途中のフラグメントから再生を開始または再開することとなるが、再生開始位置となるフラグメントの先頭に格納されているビデオサンプルとオーディオサンプルとの同期がずれてしまうおそれがある。
【００９７】
本実施の形態３に係るライブストリーミングシステムは、上記実施の形態１および２で説明した内容に加えて、ビデオデータとオーディオデータとの同期再生をも担保するライブストリーミングシステムである。
そのため、本実施の形態３に係るライブストリーミングシステムは、大枠の構成を上記実施の形態１および２と同一とするが、エンコーダおよびクライアント端末の構成において相違点を有する。以下、この相違点を中心に説明する。なお、上記実施の形態１および２と同一の構成要素については、同一の符号を付し、その説明を省略する。
【００９８】
図１０は、本実施の形態３に係るライブストリーミングシステムにおけるエンコーダの一部構成を示すブロック図である。
図１０に示すように、本実施の形態３に係るライブストリーミングシステムを構成するエンコーダは、パケットヘッダ作成部１０６ａにその特徴を有している。
このパケットヘッダ作成部１０６ａは、ビデオヘッダ情報解析部１２１と、オーディオヘッダ情報解析部１２２と、同期情報決定部１２３と、同期情報格納ボックス作成部１２４と、ヘッダ情報作成部１２５とを備える。
【００９９】
ビデオヘッダ情報解析部１２１は、ビデオデータ蓄積部１０２からビデオヘッダ情報を読み出して解析する処理部であり、フラグメントに格納するビデオサンプル毎の再生時間長を記述したテーブルを同期情報決定部１２３に出力し、また、ビデオサンプルのサンプルサイズやビデオデータ蓄積部１０２におけるサンプルの格納位置等をヘッダ情報作成部１２５に出力する。
【０１００】
オーディオヘッダ情報解析部１２２は、オーディオデータ蓄積部１０４からオーディオヘッダ情報を読み出して解析する処理部であり、フラグメントに格納するオーディオサンプル毎の再生時間長を記述したテーブルを同期情報決定部１２３に出力し、また、オーディオサンプルのサンプルサイズやオーディオデータ蓄積部１０４におけるサンプルの格納位置等をヘッダ情報作成部１２５に出力する。
【０１０１】
同期情報決定部１２３は、ビデオヘッダ情報解析部１２１から出力されるビデオ再生時間長テーブルと、オーディオヘッダ情報解析部１２２から出力されるオーディオ再生時間長テーブルとを用いて、ビデオとオーディオの同期再生のための情報を作成する処理部である。ここで、ビデオとオーディオの同期再生のための情報としては、フラグメントに格納する先頭のビデオサンプルの表示時刻（ｖ＿ｐｔｓ）およびフラグメントに格納する先頭のオーディオサンプルの表示時刻（ａ＿ｐｔｓ）を用いることができる。なお、このｖ＿ｐｔｓおよびａ＿ｐｔｓは、各再生時間長テーブルに記述されているサンプルの再生時間長の総和をフラグメント毎に加算し更新することによって得ることができる。なお、ビデオヘッダ情報解析部１２１およびオーディオヘッダ情報解析部１２２から、それぞれビデオおよびオーディオのフラグメントにおける先頭サンプルの再生開始時間を直接取得することとしてもよい。
【０１０２】
そして、同期情報決定部１２３は、作成したｖ＿ｐｔｓおよびａ＿ｐｔｓを同期情報格納ボックス作成部１２４に出力する。
同期情報格納ボックス作成部１２４は、同期情報決定部１２３において作成した同期情報をＭＰ４ファイルのボックス構造に変換して、同期情報格納ボックス（以下、「ムービーフラグメントシンクロボックス」または「ｍｆｓｙ」と称する。）を作成する処理部である。この同期情報格納ボックス作成部１２４は、ｖ＿ｐｔｓおよびａ＿ｐｔｓ毎にムービーフラグメントシンクロボックスを作成して、ヘッダ情報作成部１２５に出力する。
【０１０３】
図１１は、ムービーフラグメントシンクロボックスのシンタックスの例を示す図である。
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅのフィールドには、フラグメントの先頭サンプルの再生開始時間が記述される。
また、ｔｒａｃｋ＿ＩＤのフィールドには、ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅフィールドにより、フラグメントの先頭サンプルの再生開始時間長が提供されるトラックのＩＤ（トラックヘッダボックスに示される各トラック固有のＩＤ番号）が記述される。
【０１０４】
そして、ヘッダ情報作成部１２５は、ビデオヘッダ情報解析部１２１から出力されるビデオサンプルのサンプルサイズ等と、オーディオヘッダ情報解析部１２２から出力されるオーディオサンプルのサンプルサイズ等と、同期情報格納ボックス作成部１２４から出力されるｍｆｓｙとを用いて、ｍｏｏｆを作成する処理部である。このヘッダ情報作成部１２５は、ｍｏｏｆ直下のボックスデータ格納部にｍｆｓｙを格納してｍｏｏｆを作成し、作成したｍｏｏｆをパケット結合部１１０に出力する。また、ヘッダ情報作成部１２５は、ｍｄａｔ情報をパケットデータ作成部１０９に出力する。
【０１０５】
なお、ここで、パケットヘッダ作成部１０６ａは、ヘッダ情報作成部１２５において、ｍｏｏｆ直下のボックスデータ格納部にｍｆｓｙを格納するのではなく、同期情報格納ボックス作成部１２４において、ｍｆｓｙと、ｍｆｓｙをｍｏｏｆとｍｄａｔの間に位置させるようにフラグメントの結合を指示するｍｆｓｙ配置情報をパケット結合部１１０に出力する構成としてもよい。また、ｍｆｓｙをトラックフラグメントボックス（ｔｒａｆ）の直下に配置して、トラック単位の情報を示すこととしてもよい。このとき、ｅｎｔｒｙ＿ｃｏｕｎｔおよびｔｒａｃｋ＿ＩＤのフィールドは不要となる。また、ｍｆｓｙは、予め定められたルールに基づいて、特定のフラグメントにのみ格納することとしてもよい。
【０１０６】
図１２は、実施の形態３に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
上記のパケットヘッダ作成部１０６ａを備えたエンコーダによって作成されたＭＰ４ファイルのフラグメントを再生するため、図１２に示すように、本実施の形態３に係るクライアント端末は、第２レスポンス解析部３０７ａやヘッダ解析部３１１ａ等にその特徴を有している。
【０１０７】
第２レスポンス解析部３０７ａは、同期情報設定フラグメント判定部３２１を備える。この同期情報設定フラグメント判定部３２１は、レスポンス受信部３０４から出力される初期ヘッダ・フラグメントレスポンスのエンティティボディに含まれるフラグメントが、同期情報を用いて再生するフラグメントであるか否かを判定する処理部である。そして、同期情報設定フラグメント判定部３２１は、レスポンス受信部３０４から取得したフラグメントが、ＭＰ４ファイルの途中から受信を開始した際の先頭のフラグメントであるか否か、或いは、スキップ直後のフラグメントであるか否かを判定し、これら同期情報を用いて再生することが必要なフラグメントである場合に、ｍｆｓｙをｍｏｏｆから分離して解析することを指示する同期フラグを、ｍｆｓｙ分離解析部３２３に出力する。
【０１０８】
ヘッダ解析部３１１ａは、ｔｒａｆ分離解析部３２２と、ｍｆｓｙ分離解析部３２３とを備える。
ｔｒａｆ分離解析部３２２は、ｍｏｏｆに含まれるトラックフラグメントボックス（ｔｒａｆ）を分離して解析する処理部である。ここで、ｔｒａｆとは、トラック毎のヘッダ情報が格納されるボックスである。また、トラックとは、ライブコンテンツを構成する各メディアのサンプルデータ全体を意味し、動画像や音声やテキスト等のトラックは、それぞれビデオトラック、オーディオトラックやテキストトラック等と称される。
【０１０９】
すなわち、このｔｒａｆ分離解析部３２２は、ビデオトラックのｔｒａｆとオーディオトラックのｔｒａｆとを分離して解析し、その解析結果をサンプルデータ取得部３１２や復号表示部３１３ａに出力する。
ｍｆｓｙ分離解析部３２３は、同期情報設定フラグメント判定部３２１から出力される同期フラグを取得した場合に、ｍｏｏｆに含まれるｍｆｓｙを分離して解析する処理部である。このｍｆｓｙ分離解析部３２３は、その解析結果としてｖ＿ｐｔｓおよびａ＿ｐｔｓを復号表示部３１３ａに出力する。
【０１１０】
そして、復号表示部３１３ａは、ｔｒａｆ分離解析部３２２が出力するサンプルの再生時間と、ｍｆｓｙ分離解析部３２３が出力するｖ＿ｐｔｓおよびａ＿ｐｔｓとを取得し、その再生時間と同期情報とを用いて、サンプル取得部３１２が出力するサンプルデータを復号化して、データを再生出力する。具体的には、ｖ＿ｐｔｓがａ＿ｐｔｓよりも大きい場合には、その差分値の分だけ、ビデオの再生開始時間をオーディオの再生開始時間に対して遅延させる。ａ＿ｐｔｓがｖ＿ｐｔｓよりも大きい場合にも同様に、その差分値の分だけ、オーディオの再生開始時間をビデオの再生開始時間に対して遅延させる。
【０１１１】
このように構成されるエンコーダおよびクライアント端末を有する本実施の形態３のライブストリーミングシステムによれば、各フラグメントに先頭ビデオサンプルと先頭オーディオサンプルとの同期再生に関する情報を格納するので、ＭＰ４ファイルの途中のフラグメントから再生を開始する場合でも、ビデオとオーディオ間の同期再生を担保することができる。
【０１１２】
（実施の形態４：記録・再送要求）
さらに続いて、本発明の実施の形態４に係るライブストリーミングシステムについて説明する。
【０１１３】
上記実施の形態１〜３では、主にライブコンテンツのストリーミングによるリアルタイム再生について説明したが、本実施の形態４に係るライブストリーミングシステムは、上記実施の形態１〜３で説明した内容に加えて、クライアント端末側でライブコンテンツのデータを記録することができるライブストリーミングシステムである。
そのため、本実施の形態４に係るライブストリーミングシステムは、上記実施の形態１〜３の構成と略共通するが、クライアント端末の構成において相違点を有する。以下、この相違点を中心に説明する。なお、上記実施の形態１〜３と同一の構成要素については、同一の符号を付し、その説明を省略する。
【０１１４】
図１３は、本実施の形態４に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
図１３に示すように、本実施の形態４に係るライブストリーミングシステムを構成するクライアント端末は、上記実施の形態１〜３のクライアント端末に加えて、さらに、ユーザ指示入力部３３１と、フラグメント記録制御部３３２と、記録部分フラグメント格納部３３３とを備える。
【０１１５】
ユーザ指示入力部３３１は、ライブコンテンツの記録開始や記録終了等、ユーザからの指示の入力を受け付ける入力インターフェースであり、具体的には、携帯電話機のキーボタンや、パーソナルコンピュータのキーボードやマウス等である。このユーザ指示入力部３３１は、ユーザからライブコンテンツの記録開始指示の入力を受け付けると、フラグメント記録制御部３３２に、フラグメントの記録の開始を指示する記録指示を出力する。
【０１１６】
フラグメント記録制御部３３２は、ユーザ指示入力部３３１からの記録指示やフラグメント受信完了判定部３０９ａからの受信完了信号に基づいて、どのフラグメントから記録を開始するかを決定する処理部であり、受信完了信号を取得してからの経過時間を計測するタイマーを内部に備える。
このフラグメント記録制御部３３２は、記録指示を取得すると、タイマーによって計測した受信完了信号を取得してからの経過時間が、予め定められた値（この値を"Ｔ1"とする。）を経過しているか否かによって、記録を開始するフラグメントを決定する。具体的な詳しい説明については、後述する。
【０１１７】
また、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから初期ヘッダと、記録開始フラグメントのフラグメントデータを読み出して、記録部分フラグメント格納部３３３に格納し、ユーザ指示入力部３３１から記録の終了を指示する記録終了指示を取得するまで、記録開始フラグメント以降のフラグメントデータを記録部分フラグメントデータとして、記録部分フラグメント格納部３３３に格納していく。
【０１１８】
記録部分フラグメント格納部３３３は、記録部分フラグメントデータを格納するためのハードディスク、ＣＤ−ＲやＤＶＤ−ＲＡＭ等の記憶媒体である。
また、受信データメモリ３０８ａは、所定の容量を有しており、受信中のフラグメントの直前のフラグメントデータを保持している。
このような構成を備えたクライアント端末の記録動作について説明する。
【０１１９】
図１４は、クライアント端末における記録動作処理のフロー図である。
まず、ユーザ指示入力部３３１は、ユーザからの記録開始指示の入力を受け付けると（Ｓ２００）、フラグメント記録制御部３３２に記録指示を出力する。
次に、フラグメント記録制御部３３２は、ユーザ指示入力部３３１から記録指示を取得すると、タイマーによって計測した受信完了信号を取得してからの経過時間が、予め定められた値Ｔ1を経過しているか否かを判定する（Ｓ２０２）。
【０１２０】
ここで、経過時間がＴ1を超えている場合（Ｓ２０２のＹｅｓ）、フラグメント記録制御部３３２は、現在受信中のフラグメントを記録開始フラグメントとし、現在受信中のフラグメントの先頭から記録を開始する（Ｓ２０４）。
一方、経過時間がＴ1を超えていない場合（Ｓ２０２のＮｏ）、フラグメント記録制御部３３２は、現在受信中のフラグメントの１つ前に受信を完了したフラグメントを記録開始フラグメントとし、そのフラグメントの先頭から記録を開始する（Ｓ２０６）。
【０１２１】
その後、フラグメント記録制御部３３２は、ユーザ指示入力部３３１から記録終了指示を取得するまで、受信データメモリ３０８ａから各フラグメントのデータを読み出して、記録部分フラグメントデータを記録部分フラグメント格納部３３３に格納する動作を繰り返し（Ｓ２０８）、記録終了指示を取得すると、記録中のフラグメントの記録完了後に、記録動作を終了する。
【０１２２】
このように、ユーザからの記録開始指示を行なった時が、受信完了信号を取得してから所定の閾値Ｔ1以上経過しているか否かで、記録開始フラグメントを現在受信中のフラグメントか現在受信中のフラグメントの直前のフラグメントに決定することによって、ユーザが記録を所望する部分のデータを取りこぼすことなく、確実に記録することができるようになる。
【０１２３】
より具体的に詳しく説明すると、ユーザは、再生中の映像を見て記録開始を所望した場合、記録開始指示を入力した段階では、先の映像データを含むフラグメントの再生が終了して、次のフラグメントの再生が始まっていることがありうる。そのため、例えば、１フラグメントの再生時間長が５ｓであれば、閾値Ｔ1を３ｓに設定しておき、閾値Ｔ1を経過する前に記録開始指示の入力があれば、現在再生中のフラグメントの直前のフラグメントから記録を開始し、閾値Ｔ1を経過した後に記録開始指示の入力があれば、現在再生中のフラグメントから記録を開始することによって、ユーザの所望する映像データの部分を取りこぼすことなく記録することができる。
【０１２４】
なお、閾値Ｔ1を経過する前に記録開始指示の入力があった場合の記録開始フラグメントは、現在再生中のフラグメントの直前のフラグメントに限らず、現在再生中のフラグメントの２つ前、３つ前等のフラグメントであってもよく、受信データメモリ３０８ａの容量に応じて適宜調整することができるようにしてもよい。
このように、本実施の形態４に係るライブストリーミングシステムによれば、ユーザが記録開始の指示を行なったタイミングに応じて記録を開始するフラグメントを変更するので、ユーザが記録を所望するデータ部分を確実に記録することができる。
【０１２５】
（第１変形例）
次に、本発明の実施の形態４の第１変形例について説明する。
まず、本実施の形態４の第１変形例に係るライブストリーミングシステムを構成するクライアント端末について、図を参照しながら説明する。
【０１２６】
図１５は、第１変形例に係るクライアント端末の一部構成を示すブロック図である。
図１５に示すように、この第１変形例に係るクライアント端末は、ユーザ指示入力部３３１ａと、フラグメント記録制御部３３２ａと、記録箇所情報メモリ３４１と、再生区間判定部３４２と、第２リクエスト作成部３０６ａとを備えている。
ユーザ指示入力部３３１ａは、記録指示や記録終了指示をフラグメント記録制御部３３２ａに出力するとともに、記録した箇所をライブストリーミング再生の終了後に改めて再生することを指示する再生指示を再生区間判定部３４２に出力する。
【０１２７】
フラグメント記録制御部３３２ａは、記録指示を取得すると、受信完了信号の取得からの経過時間が、閾値Ｔ1を経過しているか否かで、記録を開始するフラグメントを決定する。ここで、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから、ＭＰ４ファイルのファイル名と、記録開始フラグメントのシーケンス番号（ファイルの先頭のフラグメントから各フラグメントに昇順で割り当てられる番号であり、ｍｏｏｆ直下のムービーフラグメントヘッダボックスに格納される。）とを読み出す。
【０１２８】
そして、フラグメント記録制御部３３２ａは、記録終了指示を取得するまで、記録開始フラグメント以降のフラグメントのシーケンス番号を順次読み出し、記録終了指示を取得またはファイルの終端に到達すると、最後に記録するフラグメント（記録終了フラグメント）のシーケンス番号を読み出して、先に読み出したファイル名と、記録開始フラグメントおよび記録終了フラグメントのシーケンス番号を記録箇所情報として記録箇所情報メモリ３４１に格納する。また、シーケンス番号が循環した際には、循環した回数を同時記録しておく等して、記録した最終フラグメントを判別することとする。なお、ここでは、シーケンス番号の増分が一定である等、予め定められたルールに基づいてシーケンス番号が設定されていることを前提としている。シーケンス番号がランダムに設定される際には、記録したフラグメントのシーケンス番号を全て記録箇所情報メモリ３４１に格納する。
【０１２９】
記録箇所情報メモリ３４１は、記録箇所情報を格納するためのメモリやハードディスク等である。
再生区間判定部３４２は、ユーザ指示入力部３３１ａから出力される再生指示を取得すると、記録箇所情報メモリ３４１を参照して記録箇所情報を読み出して、記録箇所を判定し、その記録箇所の再生に必要なフラグメントの再送を要求する再送リクエスト作成指示を第２リクエスト作成部３０６ａに出力する処理部である。
【０１３０】
第２リクエスト作成部３０６ａは、再生区間判定部３４２から再送リクエスト作成指示を取得すると、先に読み出したファイル名と、記録開始フラグメントおよび記録終了フラグメントのシーケンス番号とに基づいて、再送リクエストを作成してリクエスト送信部３０３に出力する。
クライアント端末をこのような構成とすることで、記録部分のフラグメントの実体データそのものを保持せずに、ファイル名と、記録開始箇所および記録終了箇所のシーケンス番号とを記録しておき、改めて再生する際に、これらの情報を用いて実体データの再送を要求して再生することができるので、携帯電話機やＰＤＡ等のように、メモリの容量が少ない携帯型の端末装置に適したものとなる。
【０１３１】
（第２変形例）
次に、本実施の形態４の第２変形例に係るライブストリーミングシステムを構成するクライアント端末について説明する。
図１６は、第２変形例に係るクライアント端末の一部構成を示すブロック図である。
図１６に示すように、この第２変形例に係るクライアント端末は、ユーザ指示入力部３３１ｂと、フラグメント記録制御部３３２ｂと、記録部分フラグメント格納部３３３と、スキップ判定部３５１と、再送リクエスト作成部３５２と、復号表示部３１３ｂとを備えている。
【０１３２】
ユーザ指示入力部３３１ｂは、記録指示や記録終了指示をフラグメント記録制御部３３２ｂに出力するとともに、ライブストリーミング再生時にフラグメントのスキップが発生している場合等、受信していないフラグメントのデータの再送を要求する再送リクエスト作成指示を再送リクエスト作成部３５２に出力する。
フラグメント記録制御部３３２ｂは、記録指示を取得すると、受信完了信号の取得からの経過時間が、閾値Ｔ1を経過しているか否かで、記録を開始するフラグメントを決定する。ここで、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから、初期ヘッダと、記録開始フラグメントのフラグメントデータを読み出して、スキップ判定部３５１に出力し、記録終了指示を取得するまで、順次記録開始フラグメント以降のフラグメントデータをスキップ判定部３５１に出力する。
【０１３３】
スキップ判定部３５１は、フラグメント記録制御部３３２ｂから順次出力されるフラグメントデータを取得して、フラグメントのスキップの有無を判定し、スキップが発生している場合に、スキップの発生している箇所を示すスキップ情報を再送リクエスト作成部３５２に出力するとともに、取得したフラグメントデータを記録部分フラグメント格納部３３３に格納する処理部である。
【０１３４】
このスキップ判定部３５１は、記録開始フラグメントから順番に各フラグメントのシーケンス番号の増分をカウントすることによって、フラグメントのスキップの有無を判定する。すなわち、フラグメントのシーケンス番号が予め定められている規定に従って増加していない場合には、スキップの発生であると判定する。図を用いて、より具体的に説明する。
【０１３５】
図１７（ａ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第１例を説明するための図である。
スキップ判定部３５１は、記録開始フラグメント（本図では、フラグメント５）からＭＰ４ファイル４００を構成する各フラグメントを順次取得し、各フラグメントのシーケンス番号（ＳＮ）の増分をカウントする。ここで、スキップ判定部３５１は、シーケンス番号６のフラグメント６に続いて、シーケンス番号８のフラグメント８を取得すると、シーケンス番号７のフラグメント（図中破線で示す箇所）がスキップされていると判定する。
【０１３６】
なお、スキップ判定部３５１がスキップの有無を判定する際には、シーケンス番号以外の要素を用いることもできる。すなわち、各フラグメントにＭＰ４ファイルの先頭からの絶対アドレス値を持たせて、それぞれのフラグメントの先頭に、この絶対アドレス値の情報を記述し、絶対アドレス値の増分をカウントすることによってスキップの有無を判定することもできる。図を用いて、より具体的に説明する。
【０１３７】
図１７（ｂ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第２例を説明するための図である。
スキップ判定部３５１は、記録開始フラグメント（本図では、フラグメント５）からＭＰ４ファイル５００を構成する各フラグメントを順次取得し、各フラグメントの先頭に記述されている絶対アドレス値の増分をカウントする。ここで、絶対アドレス値の増分は、１フラグメントあたり２０００バイトであり、スキップ判定部３５１は、絶対アドレス値２００００バイトのフラグメント６に続いて、絶対アドレス値２４０００バイトのフラグメント８を取得すると、絶対アドレス値２２０００バイトのフラグメント（図中破線で示す箇所）がスキップされていると判定する。
【０１３８】
また、このスキップ判定部３５１は、スキップの発生を判定すると、スキップが発生した箇所を示すスキップ箇所表示情報を復号表示部３１３ｂに出力する。
そして、復号表示部３１３ｂは、スキップ判定部３５１からスキップ箇所表示情報を取得すると、この情報を用いて、スキップが発生した箇所を画像、音声またはテキストによって明示して再生出力する。
【０１３９】
図１８は、スキップが発生した場合におけるクライアント端末の画面表示例である。
携帯電話機であるクライアント端末３０ａの液晶表示部に、コンサート中継の映像が表示されている。ここで、現在の再生位置および再生済み箇所が画面中下方のバーに示されている。このバーで、ライブコンテンツの途中から再生を開始しているために、受信および再生されていない先頭部分を破線で示し、また、スキップが発生したために、受信および再生されていない箇所を点線で示すことによって、データ未受信の箇所を明示している。なお、この図は、表示の一例にすぎず、再生済みの箇所を緑色のバーで示し、スキップ発生箇所を赤色のバーで示す等の色分け表示によって明示する等してもよい。
【０１４０】
再送リクエスト作成部３５２は、ユーザ指示入力部３３１ｂから再送リクエスト作成指示を取得すると、スキップ判定部３５１から出力されるスキップ情報に基づいて、スキップされたフラグメントデータの再送を要求する再送リクエストを作成し、リクエスト送信部３０３に出力する処理部である。
その後、リクエスト送信部３０３は、再送リクエスト作成部３５２から出力される再送リクエストをＨＴＴＰを用いて配信サーバ２０ａに送信する。
【０１４１】
図１９（ａ）は、ＨＴＴＰを用いた配信サーバ２０ａとクライアント端末３０ａ間の通信シーケンスの第１例を示す図である。
図１９（ａ）に示すように、まず、クライアント端末３０ａは、再送リクエストを配信サーバ２０ａに送信する（Ｓ３００）。ここで、送信される再送リクエストには、メソッド(GET)と、ファイルのＵＲＬ（http://…/….mp4）と、シーケンス番号１から４までのフラグメントの取得であることを示すＨＴＴＰ拡張部(SN=1-4)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
【０１４２】
配信サーバ２０ａは、再送リクエストを受信すると、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３０２）、続いて、エンティティボディにシーケンス番号１から４までのフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３０４）。
クライアント端末３０ａは、同様に、シーケンス番号７のフラグメントの送信を求める再送リクエストを配信サーバ２０ａに送信する（Ｓ３０６）。
【０１４３】
配信サーバ２０ａは、その再送リクエストを受信すると、こちらも同様に、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３０８）、続いて、エンティティボディにシーケンス番号７のフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３１０）。
一方、絶対アドレス値の増分をカウントすることによってスキップの有無を判定する場合の通信シーケンスは、図１９（ｂ）のようになる。
【０１４４】
まず、クライアント端末３０ａは、再送リクエストを配信サーバ２０ａに送信する（Ｓ３２０）。ここで、送信される再送リクエストには、先に述べた再送リクエストと同様に、メソッド(GET)、ファイルのＵＲＬ（http://…/….mp4）およびＨＴＴＰのバージョン(HTTP/1.1)の他、リクエストヘッダフィールドが含まれており、このリクエストヘッダフィールドにデータの取得範囲(:Range byte=10000-17999)が記述されている。
【０１４５】
配信サーバ２０ａは、再送リクエストを受信すると、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３２２）、続いて、エンティティボディに１００００バイトから１７９９９バイト分のフラグメントデータ、すなわち、図１７（ｂ）で示したＭＰ４ファイルでいえば、フラグメント１〜４までのフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３２４）。
【０１４６】
クライアント端末３０ａは、同様に、絶対アドレス値が２２０００バイトの値を有するフラグメントの送信を求める再送リクエストを配信サーバ２０ａに送信する（Ｓ３２６）。この場合も、リクエストヘッダフィールドに、データの取得範囲(Range byte=22000-23999)が記述される。
配信サーバ２０ａは、その再送リクエストを受信すると、こちらも同様に、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３２８）、続いて、エンティティボディに２２０００バイトから２３９９９バイト分のフラグメントデータ、すなわち、図１７（ｂ）で示したＭＰ４ファイルでいえば、フラグメント７のフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３３０）。ここでは、再送リクエストはコンテンツのストリーミング視聴終了後に行なうが、ストリーミング視聴中に再送リクエストを発行することとしてもよい。なお、上記ではスキップ発生時について述べたが、伝送路においてフラグメントデータが欠落した際にも同様の処理を適用することができる。
【０１４７】
以上説明したようなクライアント端末の構成とすることで、上記実施の形態１〜３で説明したリアルタイム再生を実現するライブストリーミングシステムのように、フラグメントのスキップの発生等によってフラグメントデータが欠落する場合でも、欠落したフラグメントデータの再送を要求して、全てのフラグメントデータを揃えて記録することができるようになる。
【０１４８】
（第３変形例）
さらに、本実施の形態４の第３変形例に係るライブストリーミングシステムを構成するクライアント端末について説明する。
図２０は、第３変形例に係るクライアント端末の一部構成を示すブロック図である。
図２０に示すように、この第３変形例に係るクライアント端末は、上記第２変形例のクライアント端末の構成と比較して、スタッフィング部３６１を備えている点で異なる。以下、この異なる点を中心に説明する。
【０１４９】
スキップ判定部３５１ａは、フラグメント記録制御部３３２ｂからフラグメントデータを取得して、フラグメントのスキップの有無を判定し、スキップが発生している箇所を示すスキップ情報をスタッフィング部３６１に出力するとともに、取得したフラグメントデータを記録部分フラグメント格納部３３３ａに格納する。
スタッフィング部３６１は、スキップ判定部３５１から出力されるスキップ情報に基づいて、記録開始フラグメント以前のフラグメントやスキップされたフラグメント等、未受信のデータ箇所を埋めるため、その箇所と同一サイズのフリーボックスからなるスタッフィングデータを作成して、記録部分フラグメント格納部３３３ａに格納する処理部である。スキップされたフラグメントのサイズは、フラグメントのサイズを一定にしておく、あるいは、各フラグメントの開始アドレスを示す情報をフラグメント内に格納しておくことにより取得する。
【０１５０】
また、このスタッフィング部３６１は、作成したスタッフィングデータが、どのシーケンス番号のフラグメントを埋めているかを示すスタッフィング情報を再送リクエスト作成部３５２ａに出力する。
再送リクエスト作成部３５２ａは、ユーザ指示入力部３３１ｂから出力される再送リクエスト作成指示を取得すると、スタッフィング部３６１から出力されるスタッフィング情報に基づいて、スタッフィングデータで埋められているフラグメントデータの再送を要求する再送リクエストを作成し、リクエスト送信部３０３に出力する。
【０１５１】
その後、リクエスト送信部３０３は、再送リクエストをＨＴＴＰを用いて配信サーバ２０ａに送信する。そして、クライアント端末が、配信サーバ２０ａからその再送リクエストに対するレスポンスのエンティティボディに含まれるフラグメントデータを取得すると、スキップ判定部３５１ａは、受信データメモリ３０８ａやフラグメント記録制御部３３２ｂを経由して取得したフラグメントデータを、スタッフィングデータと置換して記録部分フラグメント格納部３３３ａに格納する。このスタッフィングデータと置換する様子を、図を用いて説明する。ここで、上記第２変形例と同様に、記録開始フラグメントがシーケンス番号５のフラグメント５であり、シーケンス番号７のフラグメント７がスキップされているとする。
【０１５２】
図２１は、スタッフィングデータを用いた場合におけるＭＰ４ファイルの構造を説明するための図である。
まず、ライブストリーミング再生の終了段階では、スキップ判定部３５１ａが、順次受信したフラグメントデータを記録部分フラグメント格納部３３３ａに格納し、スキップの発生等によって受信していないフラグメントデータについては、スタッフィング部３６１がそのフラグメントデータを埋めるための、同じバイトサイズ分のフリーボックス６０１および６０２を作成して、記録部分フラグメント格納部３３３ａに格納するので、ＭＰ４ファイル６００が記録部分フラグメント格納部３３３ａに格納されることになる。
【０１５３】
ここで、ユーザ指示入力部３３１ｂから再送リクエスト作成部３５２ａに再送リクエスト作成指示が出力されると、配信サーバ２０ａに再送リクエストがＨＴＴＰを用いて送信され、配信サーバ２０ａから、その再送リクエストに対するレスポンスとして、エンティティボディにシーケンス番号１〜４のフラグメントデータ６０３とシーケンス番号７のフラグメントデータ６０４とが含まれたレスポンスが返ってくる。
【０１５４】
スキップ判定部３５１ａは、受信データメモリ３０８ａやフラグメント記録制御部３３２ｂを経由して、このフラグメントデータ６０３を取得すると、記録部分フラグメント格納部３３３ａに格納されているＭＰ４ファイル６００のフリーボックス６０１の部分に、フラグメントデータ６０３を上書きする。同様にして、スキップ判定部３５１ａは、記録部分フラグメント格納部３３３ａに格納されているＭＰ４ファイル６００のフリーボックス６０２の部分に、フラグメントデータ６０４を上書きする。
【０１５５】
このようにして、最終的には、記録部分フラグメント格納部３３３ａに、欠落したフラグメントのないＭＰ４ファイル６１０が格納されることになる。
このようにクライアント端末を構成することで、フラグメントのスキップの発生等によってフラグメントデータが欠落している箇所に、欠落したフラグメントデータ分のスタッフィングデータを作成しておくことができる。そして、送信要求により全てのフラグメントデータを揃えて記録する際には、このスタッフィングデータに取得したフラグメントデータを置き換えればよく、既に記録済みのフラグメントデータの格納領域を書き換える必要がなくなり、ＭＰ４ファイルの再構成時の処理負担を軽減することができる。
【０１５６】
以上、本発明に係るデータ多重化方法、データ送信方法およびデータ受信方法について各実施の形態および変形例に基づき説明したが、本発明は、これらの実施の形態や変形例に限定されるものではない。
例えば、上記各実施の形態では、ビデオデータの符号化方式として、ＭＰＥＧ−４  Ｖｉｓｕａｌを例示しているが、ＭＰＥＧ−４  ＡＶＣ(Advanced Video Coding)やＨ．２６３等のその他の動画像圧縮符号化方式を用いてもよい。なお、ＭＰＥＧ−４  ＡＶＣやＨ．２６３の符号化データでは、１ピクチャが１サンプルに相当することになる。
【０１５７】
同様に、オーディオデータの符号化方式として、ＭＰＥＧ−４  ＡＡＣを例示しているが、ＡＭＲやＧ．７２６等のその他の音声圧縮符号化方式を用いてもよい。
また、上記各実施の形態では、ビデオデータとオーディオデータとを用いて説明しているが、テキストデータ等を排除する趣旨でないことはいうまでもない。
さらに、上記実施の形態３において、ビデオサンプルとオーディオサンプルとの同期を図るための同期情報として、ビデオサンプルおよびオーディオサンプルの表示時刻を用いているが、ビデオサンプルの表示開始時間とオーディオサンプルの表示開始時間との差分値を用いることとしてもよい。
【０１５８】
なお、上記各実施の形態において使用するＭＰ４ファイルでは、基本部のムービーデータボックスを省略することとしたが、コンテンツのサムネイル画像や、コンテンツの紹介映像などを基本部のムービーデータボックスに格納し、初期ヘッダ情報と合わせてクライアント端末に送信することとしてもよい。クライアント端末では、コンテンツの再生開始前に自動的に、あるいは、ユーザの指示や端末設定に応じて選択的に、基本部のムービーデータボックスに格納されたデータを再生する。
【産業上の利用可能性】
【０１５９】
本発明に係るデータ多重化方法、データ受信方法およびデータ送信方法は、コンサート中継やスポーツ中継等のライブコンテンツを配信する画像配信システム等に適用することができ、特に、ＭＰ４ファイルをＨＴＴＰを用いてリアルタイム配信するライブストリーミングシステム等に好適である。
【図面の簡単な説明】
【０１６０】
【図１】本発明の実施の形態１に係るライブストリーミングシステムの全体構成図である。
【図２】ライブストリーミングシステムにおけるクライアント端末の構成を示すブロック図である。
【図３】ライブストリーミングシステムにおける配信サーバの構成を示すブロック図である。
【図４】ライブストリーミングシステムにおけるエンコーダの構成を示すブロック図である。
【図５】ライブストリーミングシステムにおける各装置間の通信シーケンス図である。
【図６】ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第１例を示す図である。
【図７】ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第２例を示す図である。
【図８】実施の形態２に係るライブストリーミングシステムにおける配信サーバの構成を示すブロック図である。
【図９】実施の形態２に係るライブストリーミングシステムにおける各装置間の通信シーケンス図である。
【図１０】実施の形態３に係るライブストリーミングシステムにおけるエンコーダの一部構成を示すブロック図である。
【図１１】ムービーフラグメントシンクロボックスのシンタックスの例を示す図である。
【図１２】実施の形態３に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
【図１３】実施の形態４に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
【図１４】クライアント端末における記録動作処理のフロー図である。
【図１５】第１変形例に係るクライアント端末の一部構成を示すブロック図である。
【図１６】第２変形例に係るクライアント端末の一部構成を示すブロック図である。
【図１７】（ａ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第１例を説明するための図であり、（ｂ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第２例を説明するための図である。
【図１８】スキップが発生した場合におけるクライアント端末の画面表示例である。
【図１９】（ａ）は、ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第１例を示す図であり、（ｂ）は、ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第２例を示す図である。
【図２０】第３変形例に係るクライアント端末の一部構成を示すブロック図である。
【図２１】スタッフィングデータを用いた場合におけるＭＰ４ファイルの構造を説明するための図である。
【図２２】ＭＰ４ファイルを構成するボックスの構造を説明するための図である。
【図２３】従来のＭＰ４ファイルの基本部を説明するための図である。
【図２４】従来における拡張部を含むＭＰ４ファイルの構造を示す図である。
【図２５】従来におけるライブストリーミングシステムの問題点を説明するための図である。
【符号の説明】
【０１６１】
１０、９３０    エンコーダ
２０、２０ａ、９４０    配信サーバ
３０、３０ａ、９５０    クライアント端末
１０１    ビデオ符号化部
１０２    ビデオデータ蓄積部
１０３    オーディオ符号化部
１０４    オーディオデータ蓄積部
１０５    パケット作成命令部
１０６、１０６ａ    パケットヘッダ作成部
１０７    パケットサイズ判定部
１０８    サイズ調整部
１０９    パケットデータ作成部
１１０    パケット結合部
１２１    ビデオヘッダ情報解析部
１２２    オーディオヘッダ情報解析部
１２３    同期情報決定部
１２４    同期情報格納ボックス作成部
１２５    ヘッダ情報作成部
２０１    多重化データ受信部
２０２    多重化データ蓄積部
２０３    リクエスト受信部
２０４    リクエスト解析部
２０５    サイズ情報取得部
２０６、２１６    送信データ制御部
２０７    送信データメモリ
２０８、２１８    レスポンス送信部
２１１    遅延判定部
３０１    コンテンツＵＲＬ取得部
３０２    第１リクエスト作成部
３０３    リクエスト送信部
３０４    レスポンス受信部
３０５    第１レスポンス解析部
３０６、３０６ａ    第２リクエスト作成部
３０７、３０７ａ    第２レスポンス解析部
３０８、３０８ａ    受信データメモリ
３０９、３０９ａ    フラグメント受信完了判定部
３１０、３１０ａ    多重化データ分離部
３１１、３１１ａ    ヘッダ解析部
３１２    サンプルデータ取得部
３１３、３１３ａ、３１３ｂ    復号表示部
３２１    同期情報設定フラグメント判定部
３２２    ｔｒａｆ分離解析部
３２３    ｍｆｓｙ分離解析部
３３１、３３１ａ、３３１ｂ    ユーザ指示入力部
３３２、３３２ａ、３３２ｂ    フラグメント記録制御部
３３３、３３３ａ    記録部分フラグメント格納部
３４１    記録箇所情報メモリ
３４２    再生区間判定部
３５１、３５１ａ    スキップ判定部
３５２、３５２ａ    再送リクエスト作成部
３６１    スタッフィング部
４００、５００、６００、６１０、９１０、９２０    ＭＰ４ファイル
６０１、６０２    フリーボックス
６０３、６０４    フラグメントデータ
９０１    ボックス
９０２    ボックスヘッダ部
９０３    ボックスデータ格納部
９０４    ボックスサイズ
９０５    ボックスタイプ
９０６    バージョン
９０７    フラグ
９１１    基本部
９１２    ファイルヘッダ部
９１３    ファイルデータ部
９１４    ファイルタイプボックス
９１５    ムービーボックス
９１６    ムービーデータボックス
９２１    拡張部
９２２    ムービーフラグメント
９２３    ムービーフラグメントボックス
【図１】
2005086362.tif 000003
【図２】
2005086362.tif 000004
【図３】
2005086362.tif 000005
【図４】
2005086362.tif 000006
【図５】
2005086362.tif 000007
【図６】
2005086362.tif 000008
【図７】
2005086362.tif 000009
【図８】
2005086362.tif 000010
【図９】
2005086362.tif 000011
【図１０】
2005086362.tif 000012
【図１１】
2005086362.tif 000013
【図１２】
2005086362.tif 000014
【図１３】
2005086362.tif 000015
【図１４】
2005086362.tif 000016
【図１５】
2005086362.tif 000017
【図１６】
2005086362.tif 000018
【図１７】
2005086362.tif 000019
【図１８】
2005086362.tif 000020
【図１９】
2005086362.tif 000021
【図２０】
2005086362.tif 000022
【図２１】
2005086362.tif 000023
【図２２】
2005086362.tif 000024
【図２３】
2005086362.tif 000025
【図２４】
2005086362.tif 000026
【図２５】
2005086362.tif 000027