(57)【要約】【課題】インデックス情報に基づき特定の時間位置へのアクセスを容易に行うことを可能とするストリーミングメディアのデータを提供する。【解決手段】  コンピュータにおいて、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成方法において、所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成するステップと、前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成するステップと、を備える。【選択図】図６
2016072858.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータにおいて、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成方法であって、
所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成するステップと、
前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成するステップと、
を有することを特徴とするメディアデータ生成方法。
【請求項２】
前記シングルセグメントのデータは、ＧＯＰのデータを含むことを特徴とする請求項１に記載のメディアデータ生成方法。
【請求項３】
前記シングルセグメントのデータは、映像データ、音声データ、テキストデータのうちのいずれか１つ又は複数を含む
ことを特徴とする請求項１又は２に記載のメディアデータ生成方法。
【請求項４】
前記セグメントファイルは、ＭＰＥＧ‐ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）のセグメント長を有する
ことを特徴とする請求項１ないし３のうちいずれか１項に記載のメディアデータ生成方法。
【請求項５】
前記シングルセグメントのデータを生成する際に、前記コンテンツデータを解析し、当該シングルセグメントの情報を取得し、当該シングルセグメントの情報に基づいてインデックス情報を生成するステップと、
前記インデックス情報及び前記セグメントファイルを含む、ストリーミングメディアの配信パッケージを生成するステップと、
を更に有することを特徴とする請求項１ないし４のうちいずれか１項に記載のメディアデータ生成方法。
【請求項６】
前記シングルセグメントのデータを生成する際に取得された映像データのＩフレームの情報に基づいて、前記インデックス情報を生成する
ことを特徴とする請求項５に記載のメディアデータ生成方法。
【請求項７】
前記シングルセグメントのデータを生成する際に取得された映像データのビットレートの情報に基づいて、インデックス情報を生成する
ことを特徴とする請求項５又は６に記載のメディアデータ生成方法。
【請求項８】
コンピュータにおいて、請求項５ないし７のうちいずれか１項に記載のメディアデータ生成方法により生成された前記セグメントファイルを含むストリーミングメディアのデータを再生する方法であって、
前記インデックス情報を取得するステップと、
前記セグメントファイルを逐一取得するステップと、
当該インデックス情報に含まれる、少なくともシングルセグメントの情報を参照して、前記セグメントファイル中の任意の時間位置からメディアデータを取得し、再生するステップと、
を有することを特徴とするメディアデータ再生方法。
【請求項９】
前記配信パッケージに異なるビットレートのセグメントファイルが含まれる場合において、前記取得したセグメントファイル中の任意の時間位置からビットレートを切り替える
ことを特徴とする請求項８に記載のメディアデータ再生方法。
【請求項１０】
早送り又は巻き戻しの指示を受信した場合に、前記インデックス情報に含まれるＩフレームの情報を参照して、セグメントファイルの中からＩフレームのみを取得して再生する処理を連続的に実行する
ことを特徴とする請求項８又は９に記載のメディアデータ再生方法。
【請求項１１】
ジャンプの指示を受信した場合に、ジャンプ先となる再生位置に対応する、前記インデックス情報に含まれる映像データのＧＯＰの開始位置を参照して、当該ＧＯＰが含まれるセグメントファイル中の当該ＧＯＰのデータから順に連続して再生する
ことを特徴とする請求項８ないし１０のうちいずれか１項に記載のメディアデータ再生方法。
【請求項１２】
インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成装置であって、
所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成する手段と、
前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成する手段と、
を有することを特徴とするメディアデータ生成装置。
【請求項１３】
前記シングルセグメントのデータを生成する際に、前記コンテンツデータを解析し、当該シングルセグメントの情報を取得し、当該シングルセグメントの情報に基づいてインデックス情報を生成する手段と、
前記インデックス情報及び前記セグメントファイルを含む、ストリーミングメディアの配信パッケージを生成する手段と、
を更に有することを特徴とする請求項１２に記載のメディアデータ生成装置。
【請求項１４】
コンピュータを、請求項１２又は１３に記載のメディアデータ生成装置における各手段として機能させるためのプログラム。
【請求項１５】
請求項５ないし７のうちいずれか１項に記載のメディアデータ生成方法により生成された前記セグメントファイルを含むストリーミングメディアのデータを再生するメディアデータ再生装置であって、
前記インデックス情報を取得する手段と、
前記セグメントファイルを逐一取得する手段と、
当該インデックス情報に含まれる、少なくともシングルセグメントの情報を参照して、前記セグメントファイル中の任意の時間位置からメディアデータを取得し、再生する手段と、
を有することを特徴とするメディアデータ再生装置。
【請求項１６】
コンピュータを、請求項１５に記載のメディアデータ再生装置における各手段として機能させるためのプログラム。
【請求項１７】
インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを格納するコンピュータ読み取り可能な記録媒体であって、
所与のコンテンツデータの中から取得された、コンテンツとして再生可能な単位のデータを含むシングルセグメントのデータを連結したデータ構造を有する、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイル
を格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１８】
前記コンテンツデータを解析することにより取得された前記シングルセグメントの情報に基づいて生成されたインデックス情報
を更に格納することを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像や音声等のメディアのデータを配信する技術に関連するものである。
【背景技術】
【０００２】
映像データをストリーミング配信する技術として、ＨＬＳ（ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ）方式やＩＳＯ／ＩＥＣで国際標準化されているＭＰＥＧ−ＤＡＳＨ  （ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）方式がある。これらはどちらも、元の映像データを１０秒程度の細切れのファイル（メディアセグメント）に分割し、再生順序が記載されたプレイリストとともに用いられる。
【０００３】
クライアントとなるプレイヤは、プレイリストを基に細切れのファイルを再生順にサーバから取得するが、この際、サーバ側に複数のビットレートのファイルが用意されていれば、クライアントプレイヤは、ＮＷの状態（主に通信速度）を監視しながら、最適なビットレートの映像データをサーバから取得し再生することで、映像をできるだけ途切れさせることなく再生することが可能となる。以下、これらの技術をＡＢＲ（Ａｄａｐｔｉｖｅ  ＢｉｔＲａｔｅ）技術と呼ぶことにする。
【０００４】
１つ１つの映像データファイルは、プログレッシブダウンロードとして読み込まれる。そのため、映像データを細切れにする場合に、映像データをどの程度の長さ毎に分割するかが１つのポイントとなるが、短く分割しすぎてしまうと、クライアントのサーバアクセスが増大しサーバ側に負荷がかかったり、ファイル数が増大することで、長時間コンテンツなどの場合は特に、ファイルの管理が煩雑になってしまう問題がある。逆に、長い時間で分割をしてしまうと、その１つの細切れファイルのダウンロード途中で通信速度が低下してしまうと、プレイヤ内の映像再生バッファが枯渇してしまい、映像がかくつき、最悪止まるか見えなくなってしまう。そのため、一般的に映像データ分割の長さは１０秒程度とすることが推奨されている。
【０００５】
ここで、ＨＬＳ方式では、一般にＡＢＲを行う際は、映像データのセグメントファイルの長さごとにビットレートの変更要否を判断する。しかし、ＮＷ通信速度は一般に、時々刻々と変化してしまう（特にモバイル環境では顕著）ので、映像データファイルのセグメント長を数秒〜１０秒程度の長さにしたとしても、様々なＮＷ環境下でも映像を途切れさせることなく、かつなるべく高品質に配信することは、ＡＢＲを用いても大変困難である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−２１４７９９号公報
【特許文献２】特開２０１３−２１４８００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＭＰＥＧ−ＤＡＳＨ方式では、セグメントファイル中のある特定の地点を参照可能なインデックスファイルと呼ばれるものが新たに定義されている。このインデックスファイルに、映像中の何枚かのフレームを一かたまりとしたＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）単位（通常、０．５秒〜１秒程度）でアクセス可能とするための情報を書き込むことで、セグメントファイルの長さにとらわれずに、ＡＢＲの制御を行うことが可能となる。
【０００８】
また、インデックスファイルには、ＧＯＰの先頭フレームに位置する、映像にランダムアクセス可能（＝他のフレームに依存せず、このフレームのストリームデータのみでデコード可能）なフレーム情報も記載することで、トリックプレイ（早送り、巻き戻し、ジャンプなどの操作）を行う際に、再生に必要なフレームデータのみをサーバから取得することができ、ＮＷトラフィックを大幅に軽減することが可能となる。
【０００９】
ところで、映像データ配信で用いられる映像データのファイル形式には、多くは地上デジタル放送などで用いられているＭＰＥＧ−２  ＴＳ形式（ＩＳＯ／ＩＥＣ  １３８１８）と、ＰＣでのファイル形式で用いられているＭＰ４形式（ＩＳＯ／ＩＥＣ    １４４９６−１５）などがある。ＨＬＳ方式では映像データのファイル形式としてＭＰＥＧ−２  ＴＳ形式にのみ対応し、ＭＰＥＧ−ＤＡＳＨ方式では、ＭＰＥＧ−２  ＴＳ形式とＭＰ４形式の両方に対応しているが、ＭＰＥＧ−ＤＡＳＨ形式では、ＭＰ４形式を用いることが主流である。
【００１０】
ＭＰＥＧ−２  ＴＳ形式は動画・音声データを固定長のパケットに分割して送受信するための形式であり、もともとメディアをストリーム配信することを想定した方式であるため、例えば、特許文献１、２の技術を適用することで、上述したＡＢＲ制御やトリックプレイを実現することが可能である。
【００１１】
一方、ＭＰ４形式は、コンピュータ等へのファイル格納を主眼としたものであり、ＭＰ４形式のファイルを用いてＭＰＥＧ−ＤＡＳＨ方式のストリーミングを行う場合には以下で説明するような問題がある。
【００１２】
図１に示すように、ＭＰ４形式では、ファイルの構造として、１つのファイルの中で、音声トラックと映像トラックが完全に分離された構造をとり、更に、それぞれのトラックにおけるヘッダ情報と実データも分離された構造となっている。これは、ＭＰ４を細切れに分割してセグメント化した場合も同様である。このファイル構造の場合、次の問題がある。
【００１３】
（１）映像音声が分離された構造のため、ファイルの中身にアクセスする際に、映像と音声と２回に分けてアクセスする必要があり、インデックスファイルにランダムアクセスポイントを記述する際、映像データのポイントと、それに同期する映像データのポイントの２つを記述する必要がある。ＭＰＥＧ−２  ＴＳ形式の場合、映像データと音声データが交互に配置される構成のため、このような問題は生じない。
【００１４】
（２）ＧＯＰ単位にＡＢＲをしようとした際には、ＧＯＰは一般に０．５秒〜１秒程度で構成されるため、この短い時間内に映像データと音声データの両方のアクセスを、同期して行う上では、サーバ側、クライアント側に高いパフォーマンスが要求されてしまい、幅広い端末やサーバ環境での動作に適さない。
【００１５】
ＧＯＰ単位の長さでファイル分割しセグメント化を行えば、これらの問題は解決されうるが、冒頭に述べた通り、サーバアクセスが膨大になる問題、ファイル数が増大し、管理が複雑になる問題が発生してしまい、現実的ではない。
【００１６】
（３）トリックプレイを行う際に用いるＩフレームに相当する情報は、通常用いられるコンテナには識別するための情報がなく、映像データファイル中からＩフレームのみを抽出し表示するようなトリックプレイ動作の実現が難しい問題がある。一般に、ＧＯＰ単位でアクセスすることは可能だが、Ｉフレームのみにアクセスすることは困難である。
【００１７】
なお、上記の問題は、ＭＰ４のファイル形式を用いてＭＰＥＧ−ＤＡＳＨによりストリーミング配信を行う場合に限らずに生じ得る問題である。
【００１８】
本発明は上記の点に鑑みてなされたものであり、インデックス情報に基づき特定の時間位置へのアクセスを容易に行うことを可能とするストリーミングメディアのデータを提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の実施の形態によれば、コンピュータにおいて、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成方法であって、
所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成するステップと、
前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成するステップと、を有することを特徴とするメディアデータ生成方法が提供される。
【発明の効果】
【００２０】
本発明の実施の形態によれば、インデックス情報に基づき特定の時間位置へのアクセスを容易に行うことを可能とするストリーミングメディアのデータを提供することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】ＭＰ４の一般的な構造を示す図である。
【図２】本発明の実施の形態に係るシステム構成の例を示す図である。
【図３】メディアデータ生成装置１００の構成図である。
【図４】メディアデータ配信装置２００の構成図である。
【図５】ユーザ端末３００の構成図である。
【図６】本実施の形態におけるセグメントファイルの構造例を示す図である。
【図７】本実施の形態におけるセグメントファイルの構造例を示す図である。
【図８】セグメントファイルを生成する処理手順例を示すフローチャートである。
【図９】配信パッケージの構造例を示す図である。
【図１０】インデックスファイルの構造例を示す図である。
【図１１】トリックプレイにおける処理手順例１を示すフローチャートである。
【図１２】トリックプレイにおける処理手順例２を示すフローチャートである。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態ではメディアデータ配信方式としてＭＰＥＧ  ＤＡＳＨを用いることとしているが、本発明を適用可能なメディアデータ配信方式はＭＰＥＧ  ＤＡＳＨに限られるわけではない。
【００２３】
本明細書において、ストリーミングによるデータ配信によりユーザ端末（プレイヤ）において再生・出力される映像、音声、文字等を総称して「メディア」と呼び、ストリーミングにより配信されるデータをメディアデータと呼ぶ。また、「ファイル」は「データ」の一形態である。
【００２４】
（システム構成）
図２に、本発明の実施の形態に係るシステムの構成図を示す。図２に示すように、本実施の形態に係るシステムは、メディアデータ配信装置２００及びユーザ端末３００を含む。メディアデータ配信装置２００及びユーザ端末３００はそれぞれネットワーク４００（例：インターネット）に接続されており、相互に通信可能である。
【００２５】
また、図２には、メディアデータ生成装置１００が示されている。メディアデータ生成装置１００は、元となるコンテンツデータからメディアデータを生成し、例えばメディアデータ配信装置２００に対して当該メディアデータを提供する装置である。メディアデータ生成装置１００はネットワーク４００に接続されていてもよいし、ネットワーク４００に接続されていない独立の装置であってもよい。また、メディアデータ配信装置２００にメディアデータ生成装置１００の機能を含めることとしてもよい。
【００２６】
メディアデータ配信装置２００は、ユーザ端末３００からの要求に基づいて、ユーザ端末３００にメディアデータを配信する。ユーザ端末３００はメディアデータ配信装置２００にメディアデータを要求し、メディアデータ配信装置２００からメディアデータを受信し、当該メディアデータの再生を行ってメディアを出力する。
【００２７】
次に、各装置の機能構成を説明する。以下では、構成と機能概要を説明し、詳細な動作例等についてはその後に説明する。
【００２８】
図３に示すように、メディアデータ生成装置１００は、元ファイル入力部１０１、元ファイル格納部１０２、元ファイル解析部１０３、セグメントファイル生成部１０４、セグメントファイル格納部１０５、インデックスファイル生成部１０６、パッケージ生成部１０７を有する。
【００２９】
元ファイル入力部１０１は、セグメントファイル等を生成する対象となるコンテンツの元ファイルを入力し、当該元ファイルを元ファイル格納部１０２に格納する。元ファイル解析部１０３は、元ファイル格納部１０２に格納された元ファイルのデータを解析し、少なくとも、ビットレートの情報、Ｉフレームの情報（バイト位置、時間位置等）、ＧＯＰ単位の情報（バイト位置、時間位置等）等を取得する。解析により得られた情報は、セグメントファイルの生成に利用されるととともに、インデックスファイルの生成を含む配信パッケージの生成にも利用される。
【００３０】
セグメントファイル生成部１０４は、元ファイル解析部１０３による解析結果を利用して、後述するように、マルチセグメント形式のセグメントファイル（の集合）を生成し、セグメントファイル格納部１０５に格納する。また、セグメントファイル格納部１０５には、元ファイル解析部１０３での解析結果も格納されている。インデクスファイル生成部１０６は、当該解析結果を利用して、インデックスファイルを生成する。
【００３１】
パッケージ生成部１０７は、ＭＰＤファイル、インデックスファイル、セグメントファイル等を含む配信パッケージを生成する。なお、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルとは、ストリーミング配信／再生に必要なメディアデータ等の情報が記載されたメタデータを格納したファイルである。
【００３２】
次に、図４を参照してメディアデータ配信装置２００の構成例を説明する。図４に示すように、メディアデータ配信装置２００は、データ配信制御部２０１、セグメントファイル格納部２０２、ＭＰＤファイル格納部２０３を有する。セグメントファイル格納部２０２にはセグメントファイル（の集合）が格納され、ＭＰＤファイル格納部２０３には、ＭＰＤファイル、インデックスファイル等が格納される。データ配信制御部２０１は、セグメントファイルのデータ及びＭＰＤファイル等のデータをユーザ端末３００に配信する。なお、メディアデータ配信装置２００は、例えばＷＷＷサーバにより実現される。
【００３３】
次に、図５を参照してユーザ端末３００の構成例を説明する。なお、ユーザ端末３００を「メディアデータ再生装置」と呼んでもよい。なお、ユーザ端末３００は特定の装置に限定されないが、例えばＰＣ、スマートフォン、タブレット等によりユーザ端末３００が実現される。
【００３４】
図５に示すように、ユーザ端末３００は、ユーザインタフェース部３０１、メディア再生処理部３０２、ＭＰＤファイル格納部３０３、メディアデータ取得部３０４を有する。また、メディアデータ取得部３０４には、メディアデータを一時的に格納するバッファ３０５が備えられる。
【００３５】
ユーザインタフェース部３０１は、ユーザによるユーザ端末３００に対する操作指示を受け付け、その指示内容を各機能部に通知するとともに、再生されたメディアを表示する機能を含む。ユーザインタフェース部３０１はディスプレイ（表示部）と一体化した機能部であってもよいし、ディスプレイ（ユーザインタフェース部３０１の一部）はユーザ端末３００に接続される別の装置であってもよい。
【００３６】
メディア再生処理部３０２は、メディアデータ取得部３０４により取得されたメディアデータの復号を行うことでメディア再生を行い、ユーザインタフェース部３０１に出力する。ＭＰＤファイル格納部３０３にはＭＰＤファイル（インデックスファイルを含む）が格納される。ユーザ端末３００は、ＭＰＤファイルをメディアデータ配信装置２００から取得してもよいし、他の装置（例：メディアデータ生成装置１００）から取得してもよい。
【００３７】
メディアデータ取得部３０４は、ユーザインタフェース部３０１からの指示及びＭＰＤファイルのデータに基づいて、再生すべきメディアデータをメディアデータ配信装置２００に要求し、当該メディアデータをメディアデータ配信装置２００から取得する機能を有する。
【００３８】
本実施の形態に係るメディアデータ生成装置１００、メディアデータ配信装置２００、及びユーザ端末３００はそれぞれ、例えば、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、各装置が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００３９】
また、本実施の形態で説明するマルチセグメント構造のセグメントファイルは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該セグメントファイルとインデックスファイルを含むデータ（配信パッケージ等）についても、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。
【００４０】
（セグメントファイルの構造例）
図６に、本実施の形態に係るセグメントファイルの構造例を示す。当該セグメントファイルは、メディアデータ生成装置１００のセグメントファイル生成部１０４により生成されるものである。
【００４１】
図６に示すように、セグメントファイルの集合をパッケージ（後述する配信パッケージの一部）と呼んでおり、パッケージは初期化セグメントファイル（図中のＡで示す）と、複数のセグメントファイル（１つをＢで示す）を含む。この点は既存のＭＰＥＧ  ＤＡＳＨで規定されている構造と同様である。
【００４２】
本実施の形態では、図６のＣに示すように、各セグメントファイルが、複数のシングルセグメントが連結されたマルチセグメント構造を有する。図６のＤに示すように、各シングルセグメントは、１つのＧＯＰに初期化データが付された構造である。ＧＯＰには、Ｉフレーム、及びＰｏｒＢフレームを含む各フレームのデータと、対応する音声データ（Ｅで示される）が含まれる。当該初期化データは、シングルセグメントを１つのファイルにすると仮定する場合に付加されることが想定される初期化データである。なお、本実施の形態におけるシングルセグメントは実際のファイルではなく、セグメントファイルに格納されたデータである。ユーザ端末３００は、当該初期化データを解釈することで、シングルセグメントにおける符号化データを正常にデコードし、表示することができる。
【００４３】
すなわち、マルチセグメント構造は、ＧＯＰ単位で構成されたセグメント（シングルセグメント構造）を何段にも連結し構造化した構造化セグメントファイル（論理的なファイル）である。マルチセグメント構造では、ファイルの単位としてはあくまでも一般的なセグメントファイルと同様で、数秒〜１０秒程度に分割されたファイルとなる。セグメントファイルの内部構造として、ＧＯＰ単位で更に論理的にセグメントファイル化した構成をとることで、ＧＯＰ単位でのデータアクセスが可能となる。また、各シングルセグメント中の初期化データ部分に、Ｉフレームを識別可能なＢｏｘ情報を付加することで、Ｉフレームのみを抽出するランダムアクセス・トリックプレイも実現可能となる。
【００４４】
当該ＢＯＸ情報は例えばＴｒａｃｋＲｕｎＢｏｘ（ｔｒｕｎ）であり、Ｉフレームの情報として、例えば、圧縮方式、シングルセグメント内のＩフレームの位置（バイト位置）、Ｉフレームの再生時間等を含む。これらの情報により、ユーザ端末３００が、適切にＩフレームのみをデコード可能となる。
【００４５】
なお、ＢＯＸ構造は、ＩＳＯ／ＩＥＣ  １４４９６−１２でＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔとして国際標準化されている構造である。このように国際標準化されている構造を採用することで、幅広いクライアントでの映像再生が保証される。
【００４６】
なお、図６に示す例は、映像データと音声データを含む例であるが、映像データのみ、もしくは音声データのみを含むこととしてもよい。また、字幕テロップ（テキストデータ）を含んでもよい。
【００４７】
図６に示すような映像と音声を同一ファイル内に含む構成の他、音声と映像（または字幕）を別ファイルとして構成することも可能である。この場合の構成例を図７に示す。図７に示すように、この構成では、映像と音声とで、各シングルセグメントのデュレーション（再生時間）と個数が一致するような構成としている。これにより、映像と音声で別々のインデックスファイルとなった場合でも、映像と音声の同期をとることが可能である。
【００４８】
（セグメントファイルの生成手順）
次に、図６に示したような、マルチセグメント構造のセグメントファイルの生成手順を図８を参照して説明する。当該生成手順は図３に示したメディアデータ生成装置１００により実行されるものであり、以下では、当該生成手順をメディアデータ生成装置１００の動作として説明する。
【００４９】
メディアデータ生成装置１００は、所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成し、当該シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成する。より具体的には以下のとおりである。
【００５０】
元ファイル入力部１０１からセグメントファイルの集合を生成する対象となる元ファイルが入力される。当該元ファイルは、映像が符号化されたデータのファイルである。当該ファイルに格納されているデータをコンテンツデータと呼んでもよい。元ファイルが元ファイル格納部１０２に格納されるとともに、元ファイル解析部１０３に読み込まれる。
【００５１】
元ファイル解析部１０３は、入力された元ファイルを解析し、例えば、当該コンテンツデータのビットレートの情報、ファイル中のＧＯＰ単位の情報（バイト位置、時間位置、時間長等）、ＧＯＰ毎の各フレーム（Ｉフレーム、Ｐフレーム、Ｂフレーム）の情報（バイト位置、時間位置、時間長等）等を得る（ステップ１０１）。
【００５２】
ステップ１０１での解析結果は、セグメントファイル生成部１０４に渡されるとともに、セグメントファイル格納部１０５に格納される。
【００５３】
次に、セグメントファイル生成部１０４は、ＧＯＰ単位のデータ毎に、例えば図６に示した構造でシングルセグメント化を行う（ステップ１０２）。つまり、図６の例の場合、ＧＯＰ毎に、初期化データ、各フレームのデータ、及び音声データからなるシングルセグメントを生成する。セグメントファイル生成部１０４は、既にシングルセグメントがある場合は、今回生成したシングルセグメントを、既に生成したシングルセグメントの最後尾に連結する。
【００５４】
本例では、セグメント長を予め定めた時間長にするものとし、ステップ１０３において、連結されたシングルセグメントが、当該セグメント長に達したか否かを判定する。当該セグメント長に達していれば１つのセグメントファイルを出力し、セグメントファイル格納部１０５に格納する（ステップ１０３のＹｅｓ、ステップ１０４）。セグメント長に達していなければ（ステップ１０３のＮｏ）、ステップ１０２のシングルセグメント化・連結を繰り返す。つまり、セグメント長の長さになるまで、シングルセグメント化・連結を繰り返す。
【００５５】
ステップ１０４の後、入力ファイルに未処理データが残っていれば（ステップ１０５のＮｏ）、次のセグメントファイルの生成処理として、ステップ１０２からの処理を繰り返す。入力ファイルの最後に達したら処理を終了する（ステップ１０５のＹｅｓ）。
【００５６】
なお、上記の例では、１シングルセグメントに対応する、コンテンツとして再生可能な単位としてＧＯＰ単位を例に挙げているが、これは例に過ぎず、１シングルセグメントに対応する、コンテンツとして再生可能な単位は、複数ＧＯＰ単位であってもよいし、フレーム単位であってもよい。
【００５７】
（配信パッケージについて）
ＭＰＥＧ  ＤＡＳＨで映像配信を行う場合、配信する映像・音声等メディアのファイルそのもの（セグメントファイルの集合）と、インデックス情報が書かれたインデックスファイルと、配信に関するプレゼンテーション情報が書かれたＭＰＤ  （Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルの３種類のファイルを用意する。なお、ＡＢＲを行う場合は、それぞれビットレートの異なるメディアのファイルを用意する。なお、インデックスファイルは必須ではなく、インデックスファイルがなくてもユーザ端末３００においてメディア再生を行うことができる。
【００５８】
これらの３種類のファイルをまとめて配信パッケージと呼ぶこととする。図９に、配信パッケージの例を示す。図９に示す配信パッケージの構造自体は既存のものである。本実施の形態では、各セグメントファイルがマルチマルチセグメント構造になっている点が従来技術と異なるのである。
【００５９】
ＭＰＤファイルは、番組やコンテンツを構成する１つの単位の「Ｐｅｒｉｏｄ」、映像・音声・字幕等の情報を記述する「ＡｄａｐｔａｔｉｏｎＳｅｔ」、映像・音声のビットレートや解像度等の情報を記述する「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ」、セグメントファイルをに関する情報を記述する「ＳｅｇｍｅｎｔＩｎｆｏ」で構成される。
【００６０】
図９に示すように、「ｐｅｒｉｏｄ」配下の「ＡｄａｐｔａｔｉｏｎＳｅｔ」には、音声と字幕、ビデオの符号化情報が記載されている。また、「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ」には、音声のビットレートや、映像の解像度とビットレートが記述される。なお、音声のビットレートや、映像のビットレート／解像度等をＮＷ状態等によって切換えるＡＢＲを行えるように、それぞれの情報を定義することができる。図９では、「１００Ｍｐｓ」と「５０Ｍｂｐｓ」が示されている。
【００６１】
メディアデータ生成装置１００のパッケージ生成部１０７は、コンテンツデータを解析して得た情報等から、図９に示すような構造を持つ配信パッケージを生成することができる。例えば、配信パッケージ生成は、セグメントファイル生成、インデックスファイル生成に続く処理として実行可能である。すなわち、シングルセグメントのデータを生成する際に、前記コンテンツデータを解析し、当該シングルセグメントの情報を取得し、当該シングルセグメントの情報に基づいてインデックス情報を生成し、当該インデックス情報及び前記セグメントファイルを含む、ストリーミングメディアの配信パッケージを生成する。また、解析結果でビットレート情報を取得することで、ビットレート毎のセグメントファイル、及びビットレート毎のインデックス情報を生成することができる。
【００６２】
（インデックスファイルについて）
次に、マルチセグメント構造を用いた場合のインデックスファイルについて説明する。図１０にインデックスファイルの構成例を示す。当該インデックスファイルは、図３に示したメディアデータ生成装置１００において、セグメントファイル格納部１０５に格納しておいて元ファイルの解析結果を用いて、インデックスファイル生成部１０６により生成されるものである。
【００６３】
図１０に示すように、インデックスファイルは、ファイル先頭から順番に、インデックスファイル自体を表すＳｅｇｍｅｎｔＴｙｐｅ  Ｂｏｘである「ｓｔｙｐ」（１で示す）、複数のセグメントファイル全体のファイルサイズおよびデュレーション情報を格納するＳｅｇｍｅｎｔ  Ｉｎｄｅｘ  Ｂｏｘ「ｓｉｄｘ」（２で示す）、各セグメントファイルごとに、セグメントファイル中のシングルセグメントのインデックス情報（ＧＯＰ単位の情報）を格納したＳｅｇｍｅｎｔ  Ｉｎｄｅｘ  Ｂｏｘ「ｓｉｄｘ」（３で示す）、ＧＯＰ中のＩフレームおよびその他のフレームのインデックス情報を格納したＳｕｂ−Ｓｅｇｍｅｎｔ  Ｉｎｄｅｘ  Ｂｏｘ「ｓｓｉｘ」（４で示す）で構成される。
【００６４】
本実施の形態におけるマルチセグメント構造に基づくインデックスファイルを生成する場合、インデックスファイル生成部１０６は、各セグメントファイル（＝マルチセグメント構造）のインデックス情報を２で示す「ｓｉｄｘ」に格納し、マルチセグメント構造中の各シングルセグメントへのポインタ（インデックス情報）を３で示す「ｓｉｄｘ」に格納する。また、ＧＯＰ中のＩフレームの情報として、シングルセグメントにおける初期化データ中のｔｒｕｎ  ｂｏｘに記載した当該Ｉフレーム情報へのポインタ（インデックス情報）を４で示す「ｓｓｉｘ」に格納する。
【００６５】
例えば、シングルセグメントのインデックス情報には、当該シングルセグメントのセグメントファイル内の時間位置とデータ位置を含む。「時間位置」とは、例えば、当該シングルセグメントの中のＧＯＰのメディアが始まる時間（時刻）と、当該ＧＯＰの再生時間長とからなるものである。これは開始時間及び終了時間からなるものでもよい。また、「データ位置」は、例えば、当該シングルセグメント（及び／又はＧＯＰ）の先頭のバイト位置と、当該シングルセグメント（及び／又はＧＯＰ）のバイト長（サイズ）からなる。また、開始バイト位置及び終了バイト位置からなるものでもよい。各フレームのインデックス情報も同様である。
【００６６】
特にＩフレームに関しては、インデックス情報として、例えば、セグメントファイル中での当該Ｉフレームのバイト位置（１つ手前のＩフレームからの相対位置）、当該Ｉフレームを表示する時刻情報（コンテナに記載のタイムスタンプ）、当該Ｉフレームを含むＧＯＰのサイズ、ＧＯＰの表示時間等の情報を含む。
【００６７】
上記のようなバイト位置情報等をインデックス情報として有することで、ユーザ端末３００は、セグメントファイルのＵＲＬとそのデータ範囲を指定することで、ＨＴＴＰ  ＧＥＴリクエストにより、セグメントファイル中の任意の位置のＧＯＰ（あるいは任意のＩフレーム）のデータを取得して、再生することができる。
【００６８】
例えば、ユーザ端末３００は、インデックス情報をメディアデータ再生装置２００から取得し、所望のコンテンツに対応するセグメントファイルを逐一取得し、当該インデックス情報に含まれる、少なくともシングルセグメントの情報を参照して、前記取得したセグメントファイル中の任意の時間位置からメディアデータを再生することができる。
【００６９】
また、配信パッケージに異なるビットレートのセグメントファイルが含まれる場合において、取得したセグメントファイル中の任意の時間位置からビットレートを切り替えることも可能である。
【００７０】
（トリックプレイの例）
次に、上述したようなマルチセグメント構造を採用した場合におけるトリックプレイの手順の例を説明する。この動作は、図４、図５に示したメディアデータ配信装置２００及びユーザ端末３００により実行される。
【００７１】
以下の各処理手順例の前提として、ユーザ端末３００は、ＭＰＤファイル、インデックスファイルを例えばメディアデータ配信装置２００から取得し、ＭＰＤファイル格納部３０３に格納し、ＭＰＤファイル等の情報に従って順次セグメントファイルを取得することにより所望のメディアを再生しているものとする。
【００７２】
まず、トリックプレイにおける処理手順例１を図１１を参照して説明する。ステップ２０１において、ユーザ端末３００のユーザインタフェース部３０１を介してユーザから早送りまたは巻き戻し操作が要求される。ここでは、Ｎ倍速再生（早送りまたは巻き戻し）とする。
【００７３】
メディア取得部３０４は、インデックスファイルを参照することにより、操作を行った時点の再生位置でのセグメントファイルを特定するとともに、セグメントファイル中のＩフレームを特定し、対象となるセグメントファイルから、ＩフレームのみをＮ枚毎（Ｎ−１毎のＩフレームを飛ばす）にメディアデータ配信装置２００から取得する（ステップ２０２）。なお、Ｉフレームのみを取得する際に、当該Ｉフレームが属するシングルセグメントの初期化データも取得される。当該初期化データが存在することで、メディア再生処理部３０２は正常にＩフレームをデコード（再生）することができる。
【００７４】
メディアデータ取得部３０４により取得されたＩフレームは、メディア再生処理部３０２により再生され、メディア再生処理部３０２は当該Ｉフレームの画像をユーザインタフェース部３０１を介してＧＯＰ時間だけ表示する（ステップ２０３）。当該ＧＯＰ時間は上記初期化データに含まれる。あるいは、インデックスファイルが当該ＧＯＰ時間を含み、インデックスファイルを参照することでＧＯＰ時間だけ表示することとししてもよい。
【００７５】
なお、ストリームによっては、シーンチェンジ対策などでＧＯＰ長（時間）が一定でない特異例もありうるが、この場合は、再生中の標準のＧＯＰ時間に表示時間を調整して表示することとする。
【００７６】
以降、メディアコンテンツの終端および先頭に達するか、ユーザ操作により通常再生状態に切り替わるまで（図１１ではこれらを終了トリガと呼ぶ）、Ｉフレームのダウンロード、再生を繰り返す（ステップ２０４）。
【００７７】
次に、トリックプレイ（ジャンプ）における処理手順例２を図１２を参照して説明する。ステップ３０１のおいて、ユーザインタフェース部３０１に表示されるシークバー等を用いてユーザからジャンプの操作がなされる。
【００７８】
メディアデータ取得部３０４は、操作内容（ジャンプ先のシークバーの位置）に基づいて、ジャンプ先となる再生位置（時間情報）を割り出し、更に、インデックスファイルを参照し、該当する再生位置に相当するセグメントファイル及びセグメントファイル内のＧＯＰ位置（バイト位置）を特定する（ステップ３０２）。
【００７９】
メディアデータ取得部３０４は、ステップ３０２で特定したバイト位置から、セグメントファイルのデータをメディアデータ再生装置２００から取得し、再生する（ステップ３０３）。
【００８０】
すなわち、ジャンプを行う際には、ジャンプ先となる再生位置に対応する、インデックス情報に含まれる映像データのＧＯＰの開始位置を参照して、当該ＧＯＰが含まれるセグメントファイル中の当該ＧＯＰのデータから順に連続して再生する。
【００８１】
（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、コンピュータにおいて、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成方法であって、所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成するステップと、前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成するステップと、を有することを特徴とするメディアデータ生成方法が提供される。
【００８２】
前記シングルセグメントのデータは、例えばＧＯＰのデータを含む。また、前記シングルセグメントのデータは、映像データ、音声データ、テキストデータのうちのいずれか１つ又は複数を含む。前記セグメントファイルは、例えば、ＭＰＥＧ‐ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）のセグメント長を有する。
【００８３】
前記メディアデータ生成方法は、前記シングルセグメントのデータを生成する際に、前記コンテンツデータを解析し、当該シングルセグメントの情報を取得し、当該シングルセグメントの情報に基づいてインデックス情報を生成するステップと、前記インデックス情報及び前記セグメントファイルを含む、ストリーミングメディアの配信パッケージを生成するステップと、を更に有することとしてもよい。
【００８４】
また、前記シングルセグメントのデータを生成する際に取得された映像データのＩフレームの情報に基づいて、前記インデックス情報を生成することとしてもよい。また、前記シングルセグメントのデータを生成する際に取得された映像データのビットレートの情報に基づいて、インデックス情報を生成することとしてもよい。
【００８５】
また、本実施の形態により、コンピュータにおいて、前記メディアデータ生成方法により生成された前記セグメントファイルを含むストリーミングメディアのデータを再生する方法であって、前記インデックス情報を取得するステップと、前記セグメントファイルを逐一取得するステップと、当該インデックス情報に含まれる、少なくともシングルセグメントの情報を参照して、前記セグメントファイル中の任意の時間位置からメディアデータを取得し、再生するステップと、を有することを特徴とするメディアデータ再生方法が提供される。
【００８６】
前記メディアデータ再生方法において、前記配信パッケージに異なるビットレートのセグメントファイルが含まれる場合において、前記取得したセグメントファイル中の任意の時間位置からビットレートを切り替えることとしてもよい。
【００８７】
また、早送り又は巻き戻しの指示を受信した場合に、前記インデックス情報に含まれるＩフレームの情報を参照して、セグメントファイルの中からＩフレームのみを取得して再生する処理を連続的に実行することとしてもよい。また、ジャンプの指示を受信した場合に、ジャンプ先となる再生位置に対応する、前記インデックス情報に含まれる映像データのＧＯＰの開始位置を参照して、当該ＧＯＰが含まれるセグメントファイル中の当該ＧＯＰのデータから順に連続して再生することとしてもよい。
【００８８】
また、本実施の形態により、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを生成するメディアデータ生成装置であって、所与のコンテンツデータの中から、コンテンツとして再生可能な単位のデータを取得し、当該データを用いて、シングルセグメントのデータを生成する手段と、前記シングルセグメントのデータを連結し、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを生成する手段と、を有することを特徴とするメディアデータ生成装置が提供される。
【００８９】
前記メディアデータ生成装置は、前記シングルセグメントのデータを生成する際に、前記コンテンツデータを解析し、当該シングルセグメントの情報を取得し、当該シングルセグメントの情報に基づいてインデックス情報を生成する手段と、前記インデックス情報及び前記セグメントファイルを含む、ストリーミングメディアの配信パッケージを生成する手段と、を更に有することとしてもよい。
【００９０】
また、本実施の形態により、前記メディアデータ生成方法により生成された前記セグメントファイルを含むストリーミングメディアのデータを再生するメディアデータ再生装置であって、前記インデックス情報を取得する手段と、前記セグメントファイルを逐一取得する手段と、当該インデックス情報に含まれる、少なくともシングルセグメントの情報を参照して、前記セグメントファイル中の任意の時間位置からメディアデータを取得し、再生する手段と、を有することを特徴とするメディアデータ再生装置が提供される。
【００９１】
また、本発明の実施の形態により、インデックス情報に基づき特定の時間位置へのアクセスが可能であるストリーミングメディアのデータを格納するコンピュータ読み取り可能な記録媒体であって、所与のコンテンツデータの中から取得された、コンテンツとして再生可能な単位のデータを含むシングルセグメントのデータを連結したデータ構造を有する、ストリーミングメディアのデータとして配信可能な単位のデータであるセグメントファイルを格納したことを特徴とするコンピュータ読み取り可能な記録媒体が提供される。当該コンピュータ読み取り可能な記録媒体は、前記コンテンツデータを解析することにより取得された前記シングルセグメントの情報に基づいて生成されたインデックス情報を更に格納することとしてもよい。
【００９２】
（実施の形態の効果）
本実施の形態で説明したように、配信映像データのファイルとしてマルチセグメント構造を採用することによって、クライアントプレイヤ（例：ユーザ端末３００）は、サーバアクセスへの負荷とＡＢＲの切り替えメリットを勘案しながら、ＧＯＰ単位でデータアクセスをしてもよいし、通常と同様にセグメントファイル単位、もしくはその中間のデータ単位でデータアクセスを行うことが可能となる。インデックスファイルを用いたＧＯＰ単位での高速ＡＢＲに対応しているプレイヤは、ＧＯＰ単位でのＡＢＲを実現可能であるし、インデックスファイルを用いたＧＯＰ単位での高速ＡＢＲに対応していないプレイヤは、通常のセグメントファイル毎のデータ取得で映像再生をすれば良い。
【００９３】
また、ＧＯＰ単位の情報をインデックスファイル中に書き込んでおけば、映像データファイルは必ずしもセグメント化されている必要はなく、１つの映像データファイルと、１つのインデックスファイル、プレイリストのみでの映像データ配信の運用も可能である。
【００９４】
また、ＧＯＰ単位で映像データファイルが論理的に独立に構成されていることから、映像データファイル中のタイムスタンプ情報（ＭＰＥＧ−２  ＴＳ形式ではＰＴＳ、ＭＰ４形式ではＣＴＳ／ＤＴＳ）を用いることで、映像データからのダイジェスト映像生成（カット編集）をＧＯＰ単位で行うことも可能となる。また、カット編集情報を、インデックスファイルに記載することで、元の映像データファイルには手を加えず、ダイジェスト映像プレイリストを作成することが容易に可能となる（かつ、ＭＰＥＧ−ＤＡＳＨでの配信が可能）。このダイジェスト映像プレイリストは、映像のカット点（ｉｎ点−ｏｕｔ点）の情報のみを記載したものであるため、多くのユーザがダイジェスト映像を生成するようなケースにおいても、映像データファイルが増えることにはならないため、サーバリソースの節約が可能となる。
【００９５】
また、映像のＧＯＰ単位でのアクセスが可能であることから、例えばＣＭが配信されている最中は、プレイヤ側でＣＭをスキップするユーザ操作を禁止にするような制御も容易に可能となる。また、ＣＭコンテンツの差し替え処理も容易に実現可能となる。
【００９６】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００９７】
１００  メディアデータ生成装置
２００  メディアデータ配信装置
３００  ユーザ端末
４００  ネットワーク
１０１  元ファイル入力部
１０２  元ファイル格納部
１０３  元ファイル解析部
１０４  セグメントファイル生成部
１０５  セグメントファイル格納部
１０６  インデックスファイル生成部
１０７  パッケージ生成部
２０１  データ配信制御部
２０２  セグメントファイル格納部
２０３  ＭＰＤファイル格納部
３０１  ユーザインタフェース部
３０２  メディア再生処理部
３０３  ＭＰＤファイル格納部
３０４  メディアデータ取得部
３０５  バッファ
【図１】
2016072858.tif 000003
【図２】
2016072858.tif 000004
【図３】
2016072858.tif 000005
【図４】
2016072858.tif 000006
【図５】
2016072858.tif 000007
【図６】
2016072858.tif 000008
【図７】
2016072858.tif 000009
【図８】
2016072858.tif 000010
【図９】
2016072858.tif 000011
【図１０】
2016072858.tif 000012
【図１１】
2016072858.tif 000013
【図１２】
2016072858.tif 000014