(57)【要約】【課題】  ネットワーク帯域の低下によってデータ受信の遅延が生じる場合においても、動画像データを正常に再生させることが可能となるストリーミング配信システムを提供する。【解決手段】  サーバからクライアントにストリーミングデータを送信するストリーミング配信システムは、サーバとクライアントを備える。当該サーバは、ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、ストリーミングデータの前半の位置に組替える組替え部を備える。更に当該サーバは、組替えたストリーミングデータを当該クライアントに送信する送信部を備える。当該クライアントは、受信した独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号する復号部を備える。【選択図】図１
2014187510.tif 000002
【特許請求の範囲】
【請求項１】
サーバからクライアントにストリーミングデータを送信するストリーミング配信システムであって、
前記サーバは、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替える組替え部と、
組替えた前記ストリーミングデータを前記クライアントに送信する送信部と、
を備え、
前記クライアントは、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータを復号する復号部と、
を備えることを特徴とするストリーミング配信システム。
【請求項２】
前記独立再生可能データは、オーディオデータ、ベースレイヤデータ、または、イントラフレームデータの少なくとも何れかの１つを含むことを特徴とする請求項１記載のストリーミング配信システム。
【請求項３】
前記クライアントは、前記独立再生可能データの位置を組替え前の位置に復元する復元部を更に備えることを特徴とする請求項１または請求項２記載のストリーミング配信システム。
【請求項４】
前記サーバは、前記ストリーミングデータを複数のセグメントに分割する分割部を更に備え、
前記組替え部は、前記セグメントに含まれる前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする請求項１ないし請求項３いずれか１項に記載のストリーミング配信システム。
【請求項５】
前記組替え部は、複数の前記独立再生可能データの位置を組替える場合、
前記セグメントの中心付近に位置する前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする請求項４記載のストリーミング配信システム。
【請求項６】
前記組替え部は、複数の前記独立再生可能データを組替える場合であって、前記独立再生可能データに前記オーディオデータが含まれている場合、
前記オーディオデータを、前記ベースレイヤデータ、または、前記イントラフレームデータよりも優先して前記セグメントの前半の位置に組替えること特徴とする請求項４または請求項５記載のストリーミング配信システム。
【請求項７】
前記送信部は、前記クライアントに対して、組替えた前記独立再生可能データの位置を、組替え前の位置に復元させることを指示し、
前記復元部は、前記指示に基づいて受信した前記独立再生可能データの位置を、組替え前の位置に復元することを特徴とする請求項３ないし請求項６の何れか１項に記載のストリーミング配信システム。
【請求項８】
前記分割部は、前記クライアントとのトラフィック状況に基づいて前記ストリーミングデータのエンコードレートを制御して複数の前記セグメントを分割し、
前記受信部は、前記セグメントの全体を所定の制限時間内に受信出来たか否かを判定し、前記セグメントの全体を受信出来ない場合は、前記セグメントの受信を中止し、
前記送信部は、前記エンコードレートを前記トラフィック状況に基づいて制御した前記セグメントを前記クライアントに送信することを特徴とする請求項４ないし請求項７の何れか１項に記載のストリーミング配信システム。
【請求項９】
サーバからクライアントにストリーミングデータを送信するストリーミング配信方法であって、
前記サーバが、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替えし、
組替えた前記ストリーミングデータを前記クライアントに送信し、
前記クライアントが、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータを復号すること
を含むことを特徴とするストリーミング配信方法。
【請求項１０】
サーバからクライアントにストリーミングデータを送信するストリーミング配信プログラムであって、コンピュータに、
前記サーバが、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替えし、
組替えた前記ストリーミングデータを前記クライアントに送信し、
前記クライアントが、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号すること
を実行させることを特徴とするストリーミング配信プログラム。
【請求項１１】
ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替える組替え部と、
組替えた前記ストリーミングデータをクライアントに送信する送信部と、
を備えることを特徴とするストリーミング配信サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、動画像データを分割したセグメントを生成し、当該セグメントに含まれるデータを連続して送受信することでストリーミング配信を実行するストリーミング配信システム、ストリーミング配信方法、ストリーミング配信プログラムおよびストリーミング配信サーバに関する。
【背景技術】
【０００２】
近年、ネットワークの高速化により、移動体端末でもストリーミングを行う事が可能になっている状況である。また、各移動体端末の性能やＰＣ等の固定端末も含めたストリーミングサービスを行う為に、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いた動画像データの送受信を行う技術も提案されている状況にある。ＨＴＴＰを用いたストリーミング技術は、サーバがストリーミングするデータを複数のセグメントに分割ファイル化し、クライアントが要求するファイルを、ＨＴＴＰを用いてクライアントに送信する技術である。クライアントは受信したファイルを連続再生することにより動画像データの視聴を行うことが可能となる。
【０００３】
ＨＴＴＰを使ったストリーミング技術の一つとして、ＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）がある。ＭＰＥＧ−ＤＡＳＨは、ＩＳＯ／ＩＥＣ２３００９−１において標準化が進んでおり、マルチレイヤのストリーミング配信を実現する有力な方式と考えられている。ＭＰＥＧ−ＤＡＳＨは、ネットワーク帯域や端末性能などの問題を、動画像データの解像度やビットレートを動的に切り替える仕組みにより、スムーズなストリーミングの実現を目指すものである。
【０００４】
ＭＰＥＧ−ＤＡＳＨを用いるサーバは、複数レートストリーミングデータを複数セグメントに分割したファイルを予め用意し、クライアントは、ネットワーク帯域や端末性能を、例えばＨＴＴＰ処理の実行される速度（ｄｏｗｎｌｏａｄされるサイズ／ｄｏｗｎｌｏａｄに要した時間）などによりチェックすることで、サーバとクライアント間のストリーミングに用いる動画像データの解像度やビットレートのセグメントファイルを決定する。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＩＳＯ／ＩＥＣ２３００９−１
【発明の開示】
【発明が解決しようとする課題】
【０００６】
移動体クライアントによるストリーミングにおいて、例えば、電車の乗車中にトンネルを通過する場合など、通信が途絶えたり、ネットワーク帯域が大きく低下する場合に、セグメントファイルの一部しか受信出来ない場合がある。例えば、クライアントが、ある任意の時刻のセグメントファイルを要求後、ネットワーク帯域の低下によって当該セグメントファイルの受信が遅れた場合は、受信完了前に当該セグメントファイルの再生開始時刻となり、セグメントファイルに含まれるデータを再生することが出来ずに、再生の途切れが発生する。この様に、ネットワーク帯域が大きく低下する場合などにおいては、セグメントファイルの再生予定時刻になっても、セグメントファイルに含まれるデータの受信が完了せず、再生の途切れが発生する場合がある。
【０００７】
この様に、ストリーミング配信においては、例えば、ネットワーク帯域の低下によって、データの受信の遅延が生じる場合は、ストリーミングが途切れてしまい、正常に動画像データを再生出来ない課題がある。
【０００８】
本発明は、ネットワーク帯域の低下によってデータ受信の遅延が生じる場合においても、動画像データを正常に再生させることが可能となるストリーミング配信システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明が開示するサーバからクライアントにストリーミングデータを送信するストリーミング配信システムは、サーバとクライアントを備える。当該サーバは、ストリーミングデータに含まれる少なくとも１つの独立再生可能データのファイル中の位置を、セグメントファイルの前半の位置に組替える組替え部を備える。更に当該サーバは、組替えたセグメントファイルを当該クライアントに送信する送信部を備える。当該クライアントは、受信したファイルの位置（１ファイルの受信サイズ）に基づき、組替え前の前記ストリーミングデータに復号する復号部を備える。
【００１０】
なお、本発明の目的及び利点は、請求項において特に指摘されたエレメント及び組み合わせにより実現され、かつ達成されるものである。また、上記の一般的な記述及び下記の詳細な記述の何れも、例示的かつ説明的なものであり、請求項のように、本発明を制限するものではないことを理解されたい。
【発明の効果】
【００１１】
本明細書に開示されるストリーミング配信システムでは、ネットワーク帯域の低下によってデータ受信の遅延が生じる場合においても、１セグメントファイル分（未受信分）停止することなく、低品質再生（低フレームレートなどで）を維持できるストリーミング再生を行うことが可能となる。
【図面の簡単な説明】
【００１２】
【図１】一つの実施形態によるストリーミング配信システム１の機能ブロック図である。
【図２】分割部４によりセグメントに分割されたストリーミングデータの概念図である。
【図３】（ａ）は、オーディオデータとビデオデータが多重化された場合の１つのセグメントに格納されるオーディオデータとビデオデータのデータ構造の一例である。（ｂ）は、ビデオデータの符号化にＭＰＥＧ２またはＨ.２６４を用いた場合の、一つのセグメントに格納されるビデオデータのデータ構造の一例である。（ｃ）は、ビデオデータの符号化にＳＶＣ（Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｅｃ）を用いた場合の、一つのセグメントに格納されるビデオデータのデータ構造の一例である。
【図４】（ａ）は、図３（ａ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置を組替えた後のオーディオデータとビデオデータのデータ構造の一例である。（ｂ）は、図３（ｂ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置を組替えた後のビデオデータのデータ構造の一例である。（ｃ）は、図３（ｃ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置を組替えた後のビデオデータのデータ構造の一例である。
【図５】（ａ）は、図３（ａ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のオーディオデータとビデオデータのデータ構造の一例である。（ｂ）は、図３（ｂ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。（ｃ）は、図３（ｃ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。
【図６】（ａ）は、送信部６が送信する図４（ａ）または図５（ａ）に対応する送信セグメントのデータ構造の一例である。（ｂ）は、図６（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である
【図７】（ａ）は、送信部６が送信する図４（ｂ）または図５（ｂ）に対応する送信セグメントのデータ構造の一例である。（ｂ）は、図７（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である。
【図８】（ａ）は、送信部６が送信する図４（ｃ）または図５（ｃ）に対応する送信セグメントのデータ構造の一例である。（ｂ）は、図８（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である。
【図９】ストリーミング配信システム１のサーバ２における送信処理のフローチャートである。
【図１０】ストリーミング配信システム１のクライアント７における受信処理のフローチャートである。
【図１１】一つの実施形態によるストリーミング配信システム１のハードウェア構成図である。
【発明を実施するための形態】
【００１３】
以下に、一つの実施形態によるストリーミング配信システム、ストリーミング配信方法、ストリーミング配信プログラム、ストリーミング配信サーバおよびストリーミング受信クライアントの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【００１４】
（実施例１）
図１は、一つの実施形態によるストリーミング配信システム１の機能ブロック図である。ストリーミング配信システム１は、サーバ２とクライアント７を有する。更に、サーバ２は、符号化部３、分割部４、組替え部５、ならびに送信部６を有する。クライアント７は、受信部８、復元部９ならびに復号部１０を有する。
【００１５】
サーバ２は、例えば、汎用コンピュータである。クライアント７は、例えば、移動体端末である。サーバ２とクライアント７は、ネットワーク１１を介して互いに接続される。サーバ２は、外部装置またはサーバ２の図示しない、例えば、フラッシュメモリ（ｆｌａｓｈ  ｍｅｍｏｒｙ）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶部からストリーミング配信を行う動画像データ（以下、ストリーミングデータと略）を受け取り、符号化部３に出力する。
【００１６】
符号化部３は、例えば、ワイヤードロジックによるハードウェア回路である。また、符号化部３は、サーバ２で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。符号化部３は、ストリーミングデータをサーバ２から受け取る。符号化部３は、任意の符号化手法を用いてストリーミングデータの符号化を行う。符号化部３は、符号化したストリーミングデータを分割部４に出力する。
【００１７】
分割部４は、例えば、ワイヤードロジックによるハードウェア回路である。また、分割部４は、サーバ２で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。分割部４は、符号化されたストリーミングデータを符号化部３から受け取る。分割部４は、符号化されたストリーミングデータを任意の単位のセグメントに分割する。図２は、分割部４によりセグメントに分割されたストリーミングデータの概念図である。図２に示される様に、分割部４は、符号化されたストリーミングデータを任意の単位のセグメントに分割する。また、分割部４は、図２に示す通り、分割された複数のセグメントに対してセグメントＩＤを付与しても良い。なお、１つのセグメントは、例えば、７〜１０秒程度のストリーミングデータとなり、符号化の種別に応じた複数のオーディオデータとビデオデータが格納される。更に、分割部４は、ネットワーク帯域（トラフィック状況と称しても良い）に動的に対応する為、エンコードレートを変化させた複数のセグメントを予め生成し、後述するクライアント７の受信状況に応じて組替え部５に出力するセグメントを選択することも出来る。
【００１８】
図３（ａ）は、オーディオデータとビデオデータが多重化された場合の１つのセグメントに格納されるオーディオデータとビデオデータのデータ構造の一例である。図３（ｂ）は、ビデオデータの符号化にＭＰＥＧ２またはＨ.２６４を用いた場合の、一つのセグメントに格納されるビデオデータのデータ構造の一例である。図３（ｃ）は、ビデオデータの符号化にＳＶＣ（Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｅｃ）を用いた場合の、一つのセグメントに格納されるビデオデータのデータ構造の一例である。なお、図３（ｂ）、図３（ｃ）においてもオーディオデータを含めて多重化させることが可能であるが、図３（ａ）と同様のデータ構造になる為、詳細な説明は省略する。
【００１９】
図３（ａ）においては、オーディオ（Ａｕｄｉｏ）データと、当該オーディオデータに対応するビデオ（Ｖｉｄｅｏ）データが、数周期分繰り返されて１つのセグメントに格納されている。図３（ｂ）においては、イントラフレーム（Ｉｎｔｒａ  Ｆｒａｍｅ）（またはＩフレームと称しても良い）データ、Ｂフレーム（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ  Ｐｒｅｄｉｃｔｉｖｅ  Ｆｒａｍｅ）データとＰフレーム（Ｐｒｅｄｉｃｔｉｖｅ  Ｆｒａｍｅ）データが、数周期分繰り返されて１つのセグメントに格納されている。図３（ｃ）においては、ベースレイヤ（Ｂａｓｅ  Ｌａｙｅｒ）データ、ならびに３層からなるエンハンスメントレイヤ１〜３（Ｅｎｈａｎｃｅｍｅｎｔ  Ｌａｙｅｒ１〜３）データが、数周期分繰り返されて１つのセグメントに格納されている。なお、図３（ａ）ないし図３（ｃ）に示す通り、分割部４は各データに対してデータＩＤを付与しても良い。当該データＩＤは、例えば、ストリーミングデータの時系列に基づく再生順であれば良い。換言すると、図３（ａ）ないし図３（ｃ）における１つのセグメントに含まれる複数のデータは、時間軸でプログレッシブに多重化されている。分割部４は、分割した複数のセグメントを組替え部５に出力する。
【００２０】
図１の組替え部５は、例えば、ワイヤードロジックによるハードウェア回路である。また、組替え部５は、サーバ２で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。組替え部５は、ストリーミングデータが分割されたセグメントを分割部４から受け取る。組替え部５は、各セグメントに含まれる独立再生可能データの位置をセグメントの前半の位置に組替える。ここで、説明の便宜上、オーディオデータ、ベースレイヤデータ、または、イントラフレームデータの少なくとも何れかの１つを独立再生可能データと定義する。当該独立再生可能データは、そのデータ単独でオーディオデータまたはビデオデータを再生することが可能なデータを示す。例えば、独立再生可能データ以外のデータであるＢフレームデータ、Ｐフレームデータ、ならびに、エンハンスメントレイヤ１〜３は、イントラフレームデータまたは、ベースレイヤを参照する必要がある為、独立再生可能データに該当しない。
【００２１】
図４（ａ）は、図３（ａ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置に組替えた後のオーディオデータとビデオデータのデータ構造の一例である。図４（ｂ）は、図３（ｂ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。図４（ｃ）は、図３（ｃ）に示すセグメントに格納される独立再生可能データをセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。
【００２２】
図４（ａ）においては、組替え部５によってオーディオデータがセグメントの前半に組替えられており、ビデオデータの順序は組替えられていない。このデータ構造により、例えば、ネットワーク帯域の低下により、クライアント７が、一つのセグメントファイル全体を受信出来ない場合でも、セグメントファイルの前半に含まれるオーディオデータを優先的に受信している為、オーディオデータを正常に再生出来る確度が格段に向上する。一般的には、ビデオデータに比較して、オーディオデータの方がユーザのストリーミングデータの掌握に対して支配的である為、オーディオデータを途切させることなく、ストリーミングデータを再生出来ることは効果的である。
【００２３】
図４（ｂ）においては、組替え部５によってイントラフレームデータがセグメントの前半に組替えられており、ＢフレームやＰフレームの順序は組替えられていない。このデータ構造において、例えば、ネットワーク帯域の低下により、クライアント７が、一つのセグメントファイル全体を受信出来ない場合でも、セグメントファイルの前半に含まれるイントラフレームを優先的に受信している為、ビデオデータを正常に再生出来る確度が格段に向上する。
【００２４】
図４（ｃ）においては、組替え部５によってベースレイヤデータがセグメントの前半に組替えられており、更に３層からなるエンハンスメントレイヤ１〜３データが、エンハンスメントレイヤ１（１−１〜１−３）、エンハンスメントレイヤ２（２−１〜２−３）、エンハンスメントレイヤ３（３−１〜３−３）の順序に組替えられている。これは、エンハンスメントレイヤ１が最もベースレイヤに対する補強の寄与度が高く、エンハンスメントレイヤ３が最もベースレイヤに対する補強の寄与度が低いことに依る。このデータ構造において、例えば、ネットワーク帯域の低下により、クライアント７が、一つのセグメントファイル全体を受信出来ない場合でも、セグメントファイルの前半に含まれるベースレイヤを優先的に受信している為、ビデオデータを正常に再生出来る確度が格段に向上する。更に、ベースレイヤに対する補強の寄与度が高いエンハンスメントレイヤの順序に組替えられているので、より高品質なビデオデータを正常に再生出来る確度が向上する。
【００２５】
なお、組替え部５は、図４（ａ）ないし図４（ｃ）に示すデータ構造の組替え方法の他に、ストリーミングデータの再生に一層適した組替えを行うことも可能である。具体的には、組替え部５は、１つのセグメントの中で時間的に中心の位置に存在する独立再生可能データの位置を優先してセグメントの前半の位置に組替える。図５（ａ）は、図３（ａ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のオーディオデータとビデオデータのデータ構造の一例である。図５（ｂ）は、図３（ｂ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。図５（ｃ）は、図３（ｃ）に示すセグメントの中心付近に位置する独立再生可能データの位置を、優先的にセグメントの前半の位置に組替えた後のビデオデータのデータ構造の一例である。
【００２６】
図５（ａ）においては、組替え部５によってセグメントの中心付近に位置する独立再生可能ファイルの１つとなるオーディオデータ２が、オーディオデータ１よりも優先してセグメントの前半に組替えられている。また、ビデオデータも各オーディオデータの中心付近に位置するビデオデータ２−２、１−２、３−２のそれぞれが、ビデオデータ２−１、１−１、３−１よりも優先して、セグメントの前半に組替えられている。このデータ構造により、例えば、ネットワーク帯域の低下により、クライアント７が、オーディオデータ２のみを受信した場合においてもセグメントの中心位置のオーディオデータを間延びして再生させることにより、ユーザに対する自然なストリーミング再生を実現させることが可能となる。また、図５（ａ）において、クライアント７が、オーディオデータ２からビデオデータ３−２までを受信した場合においては、ビデオデータ２−２、２−１、３−２を相互に補完することで、ユーザに対する自然なストリーミング再生を実行することが可能となる。
【００２７】
図５（ｂ）においては、組替え部５によってセグメントの中心付近に位置する独立再生可能データの１つとなるイントラフレームデータ２が、イントラフレームデータ１よりも優先してセグメントの前半に組替えられている。また、Ｂ−フレーム２−１、２−２及びＰフレーム２のそれぞれが、Ｂ−フレーム１−１、１−２及びＰフレーム１よりも優先してセグメントの前半に組替えられている。このデータ構造により、例えば、ネットワーク帯域の低下により、クライアント７が、イントラフレームデータ２のみを受信した場合においてもセグメントの中心位置のビデオデータを間延びして再生させることにより、ユーザに対する自然なストリーミング再生を実現させることが可能となる。また、図５（ｂ）において、クライアント７が、イントラフレームデータ２からＢフレームデータ２−２までを受信した場合においては、セグメントの中心付近に位置するビデオデータが優先的に復号され、かつ、イントラフレームデータ２、１、３を相互に補完することで、ユーザに対する自然なストリーミング再生を実行することが可能となる。
【００２８】
図５（ｃ）においては、組替え部５によってセグメントの中心付近に位置する独立再生可能データの１つとなるベースレイヤデータ２が、ベースレイヤデータ１よりも優先してセグメントの前半に組替えられている。また、エンハンスメントレイヤ１〜３のそれぞれにおいて、各エンハンスメントレイヤの中心に位置するエンハンスメントレイヤデータ１−２、２−２、３−２のそれぞれが、エンハンスメントレイヤデータ１−１、２−１、３−１よりも優先してセグメントの前半に組替えられている。このデータ構造により、例えば、ネットワーク帯域の低下により、クライアント７が、ベースレイヤデータ２のみを受信した場合においてもセグメントの中心位置のビデオデータを間延びして再生させることにより、ユーザに対する自然なストリーミング再生を実現させることが可能となる。また、図５（ｃ）において、クライアント７が、ベースレイヤデータ２からエンハンスメントレイヤデータ１−３までを受信した場合においては、ベースレイヤ２、１、３は、エンハンスメントレイヤデータ１−２、１−１、１−３によってそれぞれ補完されて高品質となる。これによって、ユーザに対する自然なストリーミング再生を実行することが可能となる。
【００２９】
組替え部５は、組替えを行った複数のセグメントファイルを送信部６へ出力する。なお、組替え部５は、図４（ａ）ないし図４（ｃ）、ならびに図５（ａ）ないし図５（ｃ）に図示した組替え方法を任意に組み合わせて組替えを実施することが可能である。
【００３０】
図１の送信部６は、例えば、ワイヤードロジックによるハードウェア回路である。また、送信部６は、サーバ２で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。送信部６は、組替えが行われた複数のセグメントファイルを組替え部５から受けとる。送信部６は、当該セグメントファイルを、例えばネットワーク１１を介して受信部８に送信する。なお、送信部６は、例えば、通信プロトコルとしてＨＴＴＰを用いることが出来る
【００３１】
図６（ａ）は、送信部６が送信する図４（ａ）または図５（ａ）に対応する送信セグメントファイルのデータ構造の一例である。図６（ａ）に示すセグメントファイルのデータ構造において、ヘッダの項目には、例えば、図２に示すセグメントのセグメントＩＤ等が格納される。また、当該ヘッダの項目には、組替え部５によって組替えられた各データの位置を、組替え位置に復元させることを、後述する復元部９に対して指示するコマンドが格納されても良い。セグメントの全体サイズの項目には、例えば、一つのセグメントに格納される各データサイズの合計量が格納される。受信データサイズの項目には、例えば、暫定的に０の値が格納される。当該受信データサイズの項目には、クライアント７が受信した１セグメントファイルのデータサイズが、クライアント７自体によって格納される。独立再生可能データサイズの項目には、例えば、１つのセグメントファイルに格納されるオーディオデータサイズの合計量が格納される。当該独立再生可能データサイズと受信データサイズに基づいて、クライアント７はセグメントの再生品質を判断することが可能となる。独立再生可能データの組替え位置情報の項目には、例えば、独立再生可能データの組替え前のセグメントにおける位置などが格納される。
【００３２】
図６（ｂ）は、図６（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である。図６（ｂ）のテーブル６０において、ＩＤの項目は、例えば、図４（ａ）または図５（ａ）のデータ構造に示す各データに付与されるデータＩＤと同一であれば良い。組替え順序は、組替え部５によって組替えられた後の、１つのセグメントの先頭位置の格納順序である。独立再生可能データの組替え前の位置の項目は、例えば、１つのセグメントの先頭位置を０とした場合の組替え前の位置であり、独立再生可能データサイズの項目は、例えば、各独立再生可能データのサイズとなる。図６（ｂ）のテーブル６０に示される各データは、クライアント７が、組替え部５によって組替えられた複数のデータを、組替え前の位置に復元させる為に使用することが出来る。図６（ａ）において、オーディオデータとビデオデータは、例えば、図４（ａ）または図５（ａ）に示す順序に従って格納される。なお、ビデオデータの組替え位置情報は、図６（ｂ）に示す独立再生可能データの組替え位置情報のデータ構造と同様の構成となる為、詳細な説明は省略する。
【００３３】
図７（ａ）は、送信部６が送信する図４（ｂ）または図５（ｂ）に対応する送信セグメントのデータ構造の一例である。図７（ａ）に示すデータ構造において、ヘッダ、セグメントの全体サイズ、受信データサイズ、独立再生可能データサイズ、ならびに独立再生可能データの組替え位置情報の項目は、図６（ａ）のデータ構造と同様の構成となる為、詳細な説明は省略する。また、図７（ｂ）は、図７（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である。図７（ｂ）のテーブル７０においても、図６（ｂ）のテーブル６０のデータ構造と同様の構成となる為、詳細な説明は省略する。図７（ａ）において、イントラフレームデータ、ならびに、ＢフレームデータとＰフレームデータは、例えば、図４（ｂ）または図５（ｂ）に示す順序に従って格納される。なお、Ｂフレーム、Ｐフレームデータの組替え位置情報は、図７（ｂ）に示す独立再生可能データの組替え位置情報のデータ構造と同様の構成となる為、詳細な説明は省略する。
【００３４】
図８（ａ）は、送信部６が送信する図４（ｃ）または図５（ｃ）に対応する送信セグメントのデータ構造の一例である。図８（ａ）に示すデータ構造において、ヘッダ、セグメントの全体サイズ、受信データサイズ、独立再生可能データサイズ、ならびに独立再生可能データの組替え位置情報は、図６（ａ）のデータ構造と同様の構成となる為、詳細な説明は省略する。また、図８（ｂ）は、図８（ａ）に示す独立再生可能データの組替え位置情報のデータ構造の一例である。図８（ｂ）のテーブル８０においても、図６（ｂ）のテーブル６０のデータ構造と同様の構成となる為、詳細な説明は省略する。図８（ａ）において、ベースレイヤデータ、エンハンスメントレイヤ１〜３データは、例えば、図４（ｃ）または図５（ｃ）に示す順序に従って格納される。なお、エンハンスメントレイヤ１〜３データの組替え位置情報は、図６（ａ）に示す独立再生可能データの組替え位置情報のデータ構造と同様の構成となる為、詳細な説明は省略する。なお、送信部６は、図６（ａ）、図７（ａ）、ならびに図８（ａ）に図示したデータ構造を組み合わせた送信セグメントファイルを受信部８に送信しても良い。
【００３５】
図１の受信部８は、例えば、ワイヤードロジックによるハードウェア回路である。また、受信部８は、クライアント７で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。受信部８は、送信部６が送信する複数のセグメントを受信し、受信したデータサイズを、図６（ａ）、図７（ａ）、または図８（ａ）の受信データサイズの項目に対して遂次更新処理を行う。なお、受信部８は、例えば、通信プロトコルとしてＨＴＴＰを用いることが出来る。更に、受信部８による複数のセグメントファイルの受信は、クライアント７のサーバ２に対するストリーミングデータの送信要求に基づくものであっても良い。
【００３６】
また、受信部８は、任意の受信制限時間（例えば１０秒）を定めて当該受信制限時間を経過した場合は、該当セグメントファイルの受信を中断し、次のセグメントファイルの送信要求を行っても良い。例えば、受信部８は、図２におけるセグメント３の受信を開始し、セグメント３全体を受信することなく受信制限時間が経過した場合、セグメント３の受信を中断し、セグメント４の受信を開始する。また、受信部８は、セグメント毎の受信速度を計測し、ネットワーク帯域に応じた解像度やビットレートのセグメントファイルの送信要求をサーバ２に対して実行することも出来る。更に、受信部８は、ネットワーク帯域に応じて受信制限時間を動的に変化させても良い。受信部８は受信した複数のセグメントファイルを復元部９に出力する。
【００３７】
図１の復元部９は、例えば、ワイヤードロジックによるハードウェア回路である。また、復元部９は、クライアント７で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。復元部９は、複数のセグメントを受信部８から受け取る。復元部９は、組替え前のストリーミングデータを復元する。復元部９は、受信部８が更新した、図６（ａ）、図７（ａ）、または図８（ａ）の受信データサイズの項目を参照し、セグメントの全体サイズと独立再生可能データサイズと比較する。復元部９は、受信データサイズがセグメントの全体サイズと同じであれば、１つのセグメントの全体を受信していることを判定することが出来る。復元部９は、受信データサイズが、独立再生可能データサイズ以上かつセグメントの全体サイズ未満であれば、１つのセグメントに含まれる全ての独立再生可能データを受信していることを判定することが出来る。また、復元部９は、受信データサイズが、独立再生可能データサイズ以上かつセグメントの全体サイズ未満の場合、１つのセグメントに含まれる独立再生可能データの一部のみを受信していることを判定することが出来る。復元部９の処理を以下に場合分けして説明する。
【００３８】
「（１）受信データサイズがセグメントの全体サイズと同じ場合」
この場合、受信部８は、１つのセグメントの全体を受信していることを意味する。この為、復元部９は、図６（ａ）、図７（ａ）、または図８（ａ）に示す、独立再生可能データの組替え位置情報、ビデオデータの組替え位置情報、ＢフレームとＰフレームデータの組替え位置情報ならびにエンハンスメントレイヤ１〜３データの組替え位置情報の項目を参照して、各データを組替え前の順序に復元する。復元部９が復元する１つのセグメントのデータ構造は、例えば、図３（ａ）ないし図３（ｃ）に示すデータ構造となる。
【００３９】
「（２）受信データサイズが、独立再生可能データサイズ以上かつセグメントの全体サイズ未満の場合」
この場合、受信部８は、１つのセグメントに含まれる全ての独立再生可能データを受信していることを意味する。この為、復元部９は、図６（ａ）、図７（ａ）、または、図８（ａ）に示す、独立再生可能データの組替え位置情報の項目を参照して、独立再生可能データを組替え前の順序に復元する。なお、独立再生可能データの他に、ビデオデータ、ＢフレームとＰフレームデータならびにエンハンスメントレイヤ１〜３データの一部を受信している場合は、復元部９は、ビデオデータの組替え位置情報、ＢフレームとＰフレームデータの組替え位置情報ならびにエンハンスメントレイヤ１〜３データの組替え位置情報の項目を参照して、各データを組替え前の順序に復元する。なお、復元部９は、受信部８が受信しなかった残りのビデオデータについては、ブランクデータ、独立再生可能データを間延びさせたビデオデータ、または、受信したビデオデータを相互に補完させて生成したビデオデータを代用データとして用いて、各データを組替え前の順序に復元させても良い。
【００４０】
「（３）受信データサイズが、独立再生可能データサイズ未満かつセグメントの全体サイズ未満の場合」
この場合、受信部８は、１つのセグメントに含まれる独立再生可能データの一部のみを受信している。この為、復元部９は、図６（ａ）、図７（ａ）、または図８（ａ）に示す、受信した独立再生可能データの組替え位置情報の項目を参照して、受信した独立再生可能データを組替え前の順序に復元する。復元部９は、受信部８が受信しなかった残りの独立再生可能データについては、以下の処理を行う。独立再生可能データがオーディオデータの場合、復元部９は、例えば、受信したオーディオデータを時間軸上に間延びさせたオーディオデータを、受信しなかったオーディオデータの代用データとして用いて、各データを組替え前の順序に復元させても良い。また、独立再生可能データがビデオデータの場合は、ブランクデータ、受信した独立再生可能データを間延びさせたビデオデータ、または、受信したビデオデータを相互に補完させて生成したビデオデータを代用データとして用いて、各データを組替え前の順序に復元させても良い。
【００４１】
図１の復元部９は、組替え部５が組替えた各データの順序を、組替え前の順序に復元させた複数のセグメントを復号部１０へ遂次出力する。
【００４２】
図１の復号部１０は、例えば、ワイヤードロジックによるハードウェア回路である。また、復号部１０は、クライアント７で実行されるコンピュータプログラムにより実現される機能モジュールであっても良い。復号部１０は、組替え前の順序に復元されたセグメントを復元部９から受け取り、任意の復号手法を用いてセグメントを復号し、ストリーミングデータの再生を遂次実行する。また、復号部１０は、復号部１０が有する図示しないメモリまたはキャッシュにストリーミングデータを一時的に格納しつつ、ストリーミングデータの再生を行うことも可能である。更に、復号部１０は、復元部９を介さずに、複数のセグメントを受信部８から受け取ることも可能である。この場合、復号部１０は、上述の「（１）受信データサイズがセグメントの全体サイズと同じ場合」、「（２）受信データサイズが、独立再生可能データサイズ以上かつセグメントの全体サイズ未満の場合」、「（３）受信データサイズが、独立再生可能データサイズ未満かつセグメントの全体サイズ未満の場合」に示した復元方法の何れかを利用し、各ファイルの順序を組替え前の順序に戻しつつ、復号処理を行っても良い。
【００４３】
なお、ストリーミング配信システム１は、ストリーミング配信システム１が有する各機能部を、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）などの集積回路で構成しても良い。
【００４４】
図９は、ストリーミング配信システム１のサーバ２における送信処理のフローチャートである。サーバ２は、クライアント７からストリーミングデータの送信要求を受信する（ステップＳ９０１）。符号化部３は、ストリーミングデータをサーバ２から受け取る。符号化部３は、任意の符号化手法を用いてストリーミングデータの符号化を行う（ステップＳ９０２）。符号化部３は、符号化したストリーミングデータを分割部４に出力する。分割部４は、符号化されたストリーミングデータを符号化部３から受け取る。分割部４は、符号化されたストリーミングデータを任意の単位のセグメントに分割する（ステップＳ９０３）。なお、となり、符号化の種別に応じた複数の音声データと画像データが格納される。更に、分割部４は、ネットワーク帯域（トラフィック状況と称しても良い）に動的に対応する為、エンコードレートを変化させた複数のセグメントを予め生成し、クライアント７の受信状況に応じて組替え部５に出力するセグメントを選択することも出来る。なお、クライアント７の受信状況は、例えば、ステップＳ９０１で受信する送信要求に含められていれば良い。
【００４５】
組替え部５は、ストリーミングデータが分割されたセグメントを分割部４から受け取る。組替え部５は、各セグメントに含まれる独立再生可能データの位置をセグメントの前半の位置に組替える（ステップＳ９０４）。組替え部５は、組替えを行った複数のセグメントを送信部６へ出力する。なお、組替え部５は、図４（ａ）ないし図４（ｃ）、ならびに図５（ａ）ないし図５（ｃ）に図示した組替え方法を任意に組み合わせて組替えを実施することが可能である。送信部６は、組替えが行われた複数のセグメントを組替え部５から受けとる。送信部６は、当該セグメントを、例えばネットワーク１１を介して受信部８に送信する（Ｓ９０５）。なお、送信部６は、例えば、通信プロトコルとしてＨＴＴＰを用いることが出来る。
【００４６】
送信部６は、ステップＳ９０１で受信する送信要求に基づいた全てのセグメントの送信が完了したか否かは判定する（ステップＳ９０６）。全てのセグメントの送信が完了していない場合（ステップＳ９０６−Ｎｏ）は、送信部６はステップＳ９０１〜Ｓ９０６の処理を繰り返す。全てのセグメントの送信が完了した場合（ステップＳ９０６−Ｙｅｓ）、サーバ２は図９のフローチャートに示す送信処理を完了させる。
【００４７】
図１０は、ストリーミング配信システム１のクライアント７における受信処理のフローチャートである。受信部８は、サーバ２に対してストリーミングデータの送信要求を送信する（ステップＳ１００１）。受信部８は、送信部６が送信する複数のセグメントを受信する（ステップＳ１００２）。なお、受信部８は、例えば、通信プロトコルとしてＨＴＴＰを用いることが出来る。受信部８は、受信したセグメントのデータサイズを、図６（ａ）、図７（ａ）、または図８（ａ）の受信データサイズの項目に対して遂次更新（変更）処理を行う（ステップＳ１００３）。
【００４８】
受信部８は、受信部８が定める任意の受信制限時間（例えば１０秒）が経過したか否かを判定する（ステップＳ１００４）。受信制限時間が経過していない場合（ステップＳ１００４−Ｎｏ）は、受信部８は、ステップＳ１００３ないしＳ１００４の処理を繰り返し実行する。受信制限時間が経過した場合（ステップＳ１００４−Ｙｅｓ）は、受信部８は、受信速度を計測する（ステップＳ１００５）。なお、受信速度は、例えば、受信したデータサイズ／受信時間によって算出することが出来る。次に、復元部９は、セグメントを受信部８から受け取る。復元部９は、受信部８が更新した、図６（ａ）、図７（ａ）、または図８（ａ）の受信データサイズの項目を参照し、セグメントの全体サイズと独立再生可能データサイズと比較する（ステップＳ１００６）。復元部９は、上述の「（１）受信データサイズがセグメントの全体サイズと同じ場合」、「（２）受信データサイズが、独立再生可能データサイズ以上かつセグメントの全体サイズ未満の場合」、「（３）受信データサイズが、独立再生可能データサイズ未満かつセグメントの全体サイズ未満の場合」に示した復元方法の何れかを用いてセグメントに含まれる各データを組替え前の位置に復元する（ステップＳ１００７）。
復元部９は、組替え部５が組替えた各データの順序を、組替え前の順序に復元させた複数のセグメントを復号部１０へ遂次出力する。
【００４９】
復号部１０は、組替え前の順序に復元されたセグメントを復元部９から受け取り、任意の復号手法を用いてセグメントを復号し、ストリーミングデータの再生を遂次実行する（ステップＳ１００８）。クライアント７は、全てのセグメントの受信が完了しているか否かを判断する（ステップＳ１００９）。全てのセグメントの受信が完了していない場合（ステップＳ１００９−Ｎｏ）、クライアント７は、ステップＳ１００１〜Ｓ１００９の処理を繰り返す。なお、ステップＳ１００１において、送信要求にステップＳ１００５で計測した受信速度の情報を含めても良い。また、ステップＳ１００９は、ステップＳ１００５とＳ１００６の間で実行しても良い。全てのセグメントの受信が完了した場合（ステップＳ１００９−Ｙｅｓ）、クライアント７は図１０のフローチャートに示す受信処理を完了させる。
【００５０】
実施例１によるストリーミング配信システム１に依れば、ネットワーク帯域の低下によって受信の遅延が生じる場合においても、ストリーミングデータを正常に再生させることが可能となる。具体的には、従来のストリーミング配信の手法においては、１つのセグメントの全体が受信出来ない場合、ストリーミングデータの再生の途切れが生じる。一方、実施例１においては、１つのセグメントの一部のみを受信した場合においても、再生の途切れを生じさせることなく、受信状況に応じた品質のストリーミングデータを再生させることが可能となる。
【００５１】
なお、従来のストリーミング配信において、サーバはセグメント単位でストリーミングデータを分割せずに時間軸でプログレッシブに多重化している。これは、従来のストリーミング配信においては、クライアントが、１本の長いストリーミングデータの一部を受信する毎に多重分離し再生処理を行っているためである。また、この様なストリーミングデータは、どのデータ部分が受信し難い（受信に失敗する）などの区別はない。以上の理由から、従来のストリーミング配信においては、各データを組替える動機づけは存在し得ない。これは、ストリーミングデータを分割し、セグメント単位で配信するＭＰＥＧ−ＤＡＳＨなどにおいて同様であり、従来のＭＰＥＧ−ＤＡＳＨにおいては、単にストリーミングデータを、セグメントに分割して送信するに留まっていた。ＭＰＥＧ−ＤＡＳＨにおけるストリーミング配信においても、１つのセグメントの一部分しか受信出来なかった場合は、再生の遅延が生じるか、受信エラーと判定して受信した全てのデータが利用出来なくなっていた。一方、実施例１においては、１つのセグメントの一部のみを受信した場合においても、再生の途切れを生じさせることなく、受信状況に応じた品質のストリーミングデータを再生させることが可能となる。
【００５２】
（実施例２）
図１１は、一つの実施形態によるストリーミング配信システム１のハードウェア構成図である。図１１に示す様に、ストリーミング配信システム１は、制御部１２、主記憶部１３、補助記憶部１４、ドライブ装置１５、ネットワークＩ／Ｆ部１７、入力部１８、表示部１９を含む。これら各構成は、バスを介して相互にデータ送受信可能に接続されている。
【００５３】
制御部１２は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部１２は、主記憶部１３や補助記憶部１４に記憶されたプログラムを実行する演算装置であり、入力部１８や外部の記憶装置からデータを受け取り、演算、加工した上で、表示部１９や記憶装置などに出力する。
【００５４】
主記憶部１３は、ＲＯＭ(Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ)やＲＡＭ(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ)などであり、制御部１２が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶または一時保存する記憶装置である。
【００５５】
補助記憶部１４は、ＨＤＤ(Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ)などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。
【００５６】
ドライブ装置１５は、記録媒体１６、例えばフレキシブルディスクからプログラムを読み出し、補助記憶部１４にインストールする。
【００５７】
また、記録媒体１６に、所定のプログラムを格納し、この記録媒体１６に格納されたプログラムはドライブ装置１５を介してストリーミング配信システム１にインストールされる。インストールされた所定のプログラムは、ストリーミング配信システム１により実行可能となる。
【００５８】
ネットワークＩ／Ｆ部１７は、有線及び/又は無線回線などのデータ伝送路により構築されたＬＡＮ(Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ)、ＷＡＮ(Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ)などのネットワークを介して接続された通信機能を有する周辺機器とのインターフェースである。
【００５９】
入力部１８は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、表示部１９の表示画面上でキーの選択等を行うためのマウスやスライスパット等を有する。また、入力部１８は、ユーザが制御部１２に操作指示を与えたり、データを入力したりするためのユーザインターフェースである。
【００６０】
表示部１９は、ＣＲＴ(Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ)やＬＣＤ(Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ)等により構成され、制御部１２から入力される表示データに応じた表示が行われる。
【００６１】
なお、上述したストリーミング配信処理は、コンピュータに実行させるためのプログラムとして実現されてもよい。このプログラムをサーバ等からインストールしてコンピュータに実行させることで、上述したストリーミング配信処理を実現することができる。また、このプログラムを記録媒体１６に記録し、このプログラムが記録された記録媒体１６をコンピュータや携帯端末に読み取らせて、上述したストリーミング配信処理を実現させることも可能である。なお、記録媒体１６は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。
【００６２】
（実施例３）
実施例３においては、ストリーミング配信サーバについて説明する。ストリーミング配信サーバは、図１に示すサーバ２と同様に、符号化部３、分割部４、組替え部５、ならびに送信部６を有する。当該、各機能は実施例１に記載した機能と同等の機能を有する為、詳細な説明は省略する。実施例３におけるストリーミング配信サーバにおいては、ネットワーク帯域の低下によって、クライアントの受信の遅延が生じる場合においても、ストリーミングデータを正常にクライアントに再生させることが可能となる。
【００６３】
（実施例４）
実施例３においては、ストリーミング受信クライアントについて説明する。ストリーミング受信クライアントは、図１に示すクライアント７と同様に、受信部８、復元部９ならびに復号部１０を有する。当該、各機能は実施例１に記載した機能と同等の機能を有する為、詳細な説明は省略する。実施例４におけるトリーミング受信クライアントにおいては、ネットワーク帯域の低下によって受信の遅延が生じる場合においても、ストリーミングデータを正常に再生させることが可能となる。
【００６４】
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。
【００６５】
以上、説明した実施形態に関し、更に以下の付記を開示する。
（付記１）
サーバからクライアントにストリーミングデータを送信するストリーミング配信システムであって、
前記サーバは、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替える組替え部と、
組替えた前記ストリーミングデータを前記クライアントに送信する送信部と、
を備え、
前記クライアントは、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号する復号部と、
を備えることを特徴とするストリーミング配信システム。
（付記２）
前記独立再生可能データは、オーディオデータ、ベースレイヤデータ、または、イントラフレームデータの少なくとも何れかの１つを含むことを特徴とする付記１記載のストリーミング配信システム。
（付記３）
前記クライアントは、前記独立再生可能データの位置を組替え前の位置に復元する復元部を更に備えることを特徴とする付記１または付記２記載のストリーミング配信システム。
（付記４）
前記サーバは、前記ストリーミングデータを複数のセグメントに分割する分割部を更に備え、
前記組替え部は、前記セグメントに含まれる前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする付記１ないし付記３いずれか１項に記載のストリーミング配信システム。
（付記５）
前記組替え部は、複数の前記独立再生可能データの位置を組替える場合、
前記セグメントの中心付近に位置する前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする付記４記載のストリーミング配信システム。
（付記６）
前記組替え部は、複数の前記独立再生可能データを組替える場合であって、前記独立再生可能データに前記オーディオデータが含まれている場合、
前記オーディオデータを、前記ベースレイヤデータ、または、前記イントラフレームデータよりも優先して前記セグメントの前半の位置に組替えることを特徴とする付記４または付記５記載のストリーミング配信システム。
（付記７）
前記送信部は、前記クライアントに対して、組替えた前記独立再生可能データの位置を、組替え前の位置に復元させることを指示し、
前記復元部は、前記指示に基づいて受信した前記独立再生可能データの位置を、組替え前の位置に復元することを特徴とする付記３ないし付記６の何れか１つに記載のストリーミング配信システム。
（付記８）
前記分割部は、前記クライアントとのトラフィック状況に基づいて前記ストリーミングデータのエンコードレートを制御して複数の前記セグメントを分割し、
前記受信部は、前記セグメントの全体を所定の制限時間内に受信出来たか否かを判定し、前記セグメントの全体を受信出来ない場合は、前記セグメントの受信を中止し、
前記送信部は、前記エンコードレートを前記トラフィック状況に基づいて制御した前記セグメントを前記クライアントに送信することを特徴とする付記４ないし付記７の何れか１つに記載のストリーミング配信システム。
（付記９）
サーバからクライアントにストリーミングデータを送信するストリーミング配信方法であって、
前記サーバが、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替えし、
組替えた前記ストリーミングデータを前記クライアントに送信し、
前記クライアントが、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号すること
を含むことを特徴とするストリーミング配信方法。
（付記１０）
前記独立再生可能データは、オーディオデータ、ベースレイヤデータ、または、イントラフレームデータの少なくとも何れかの１つを含むことを特徴とする付記９記載のストリーミング配信方法。
（付記１１）
前記クライアントは、前記独立再生可能データの位置を組替え前の位置に復元することを更に含むことを特徴とする付記９または付記１０記載のストリーミング配信方法。
（付記１２）
前記サーバは、前記ストリーミングデータを複数のセグメントに分割し、
前記組替えすることは、前記セグメントに含まれる前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする付記９ないし付記１１いずれか１つに記載のストリーミング配信方法。
（付記１３）
前記組替えすることは、複数の前記独立再生可能データの位置を組替える場合、
前記セグメントの中心付近に位置する前記独立再生可能データの位置を、前記セグメントの前半の位置に組替えることを特徴とする付記１２記載のストリーミング配信方法。
（付記１４）
前記組替えすることは、複数の前記独立再生可能データを組替える場合であって、前記独立再生可能データに前記オーディオデータが含まれている場合、
前記オーディオデータを、前記ベースレイヤデータ、または、前記イントラフレームデータよりも優先して前記セグメントの前半の位置に組替えること特徴とする付記１２または付記１３記載のストリーミング配信方法。
（付記１５）
前記送信することは、前記クライアントに対して、組替えた前記独立再生可能データの位置を、組替え前の位置に復元させることを指示し、
前記復元することは、前記指示に基づいて受信した前記独立再生可能データの位置を、組替え前の位置に復元することを特徴とする付記１１ないし付記１４の何れか１つに記載のストリーミング配信方法。
（付記１６）
前記分割することは、前記クライアントとのトラフィック状況に基づいて前記ストリーミングデータのエンコードレートを制御して複数の前記セグメントを分割し、
前記受信することは、前記セグメントの全体を所定の制限時間内に受信出来たか否かを判定し、前記セグメントの全体を受信出来ない場合は、前記セグメントの受信を中止し、
前記送信することは、前記エンコードレートを前記トラフィック状況に基づいて制御した前記セグメントを前記クライアントに送信することを特徴とする付記１２ないし付記１５の何れか１つに記載のストリーミング配信方法。
（付記１７）
サーバからクライアントにストリーミングデータを送信するストリーミング配信プログラムであって、コンピュータに、
前記サーバが、
前記ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替えし、
組替えた前記ストリーミングデータを前記クライアントに送信し、
前記クライアントが、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号すること
を実行させることを特徴とするストリーミング配信プログラム。
（付記１８）
ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替える組替え部と、
組替えた前記ストリーミングデータをクライアントに送信する送信部と、
を備えることを特徴とするストリーミング配信サーバ。
（付記１９）
ストリーミングデータに含まれる少なくとも１つの独立再生可能データの位置を、前記ストリーミングデータの前半の位置に組替えられた前記ストリーミングデータを受信する受信部と、
受信した前記独立再生可能データの位置に基づき、組替え前の前記ストリーミングデータに復号する復号部と、
を備えることを特徴とするストリーミング受信クライアント。
【符号の説明】
【００６６】
１    ストリーミング配信システム
２    サーバ
３    符号化部
４    分割部
５    組替え部
６    送信部
７    クライアント
８    受信部
９    復元部
１０  復号部
１１  ネットワーク
【図１】
2014187510.tif 000003
【図２】
2014187510.tif 000004
【図３】
2014187510.tif 000005
【図４】
2014187510.tif 000006
【図５】
2014187510.tif 000007
【図６】
2014187510.tif 000008
【図７】
2014187510.tif 000009
【図８】
2014187510.tif 000010
【図９】
2014187510.tif 000011
【図１０】
2014187510.tif 000012
【図１１】
2014187510.tif 000013