JPWO2014010501A1 - 再生装置、再生方法、配信装置、配信方法、配信プログラム、再生プログラム、記録媒体およびメタデータ - Google Patents

Abstract

本発明の再生装置（２００）は、ライブ放送番組を構成する短い時間長の多数のセグメントを録画再生用に長い時間長の少数のセグメントに変換して記憶部（２５０）に記録するセグメント変換部（２４０）と、多数のセグメントの各再生用情報を含む制御情報を、少数のセグメントの各再生用情報を含む制御情報に変換する制御情報変換部（２３０）と、を備えている。本発明により、コンテンツを録画再生用に適切に処理することができる。

Description

本発明は、コンテンツを再生する再生装置、再生方法および再生プログラムに関する。また、本発明は、コンテンツを配信する配信装置、配信方法および配信プログラムに関する。さらに、本発明は、再生プログラムまたは配信プログラムが記録されている記録媒体、並びに、コンテンツを再生するために必要なメタデータに関する。

近年、インターネットに対する需要が急速に高まるにしたがって、動画コンテンツを鑑賞するユーザが増えてきている。

このような状況を踏まえ、動画コンテンツをストリーミング配信するための様々な技術が開発されているが、そのうちのひとつに、ＭＰＥＧ（Moving Picture Experts Group）のＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)が挙げられる。

ＤＡＳＨでは、ＭＰＤ（Media Presentation Description）データと、ＭＰＤデータにMPEG-2 TSストリームあるいはMP4ファイルとして示されるメディアセグメントの２つのフォーマットが規定されている。メディアセグメントは、動画コンテンツが時分割された、ＨＴＴＰ伝送の伝送単位である。また、ＭＰＤデータは、ストリーミング配信の制御メタデータであり、メディアセグメントをサーバにリクエストするための情報や、動画コンテンツがライブ配信されるコンテンツ（ライブコンテンツ）であるかＶＯＤコンテンツであるかを示す情報を含んでいる。

配信装置は、ライブカメラによる撮影映像をライブ配信している間、多数のメディアセグメントを再生装置に配信するが、当然ながら、メディアセグメントの生成を完了するまで、そのメディアセグメントを再生装置のリクエストを受けて配信可能な状態にすることができない。また、配信装置から再生装置にメディアセグメントが到達するまでにはある程度の伝送時間が必要である。

したがって、例えば、メディアセグメントの時間長が５秒である場合、配信装置はライブカメラで撮影を開始してから５秒後に最初のメディアセグメントを配信可能にするため、再生装置は、常に、ライブカメラによる５秒以上前の撮影映像をライブ再生することになる。

このようなタイムラグの問題を抑制するため、ライブ配信されるコンテンツを構成する各メディアセグメントの時間長は短めに定められる。

ところで、再生装置は、ライブ配信中のコンテンツを録画し、録画済みのそのコンテンツをライブ配信終了後に再生することがある。

また、配信装置は、ライブ配信中のコンテンツを自装置あるいは２次配信装置内に記録しておいた上で、記録したコンテンツをライブ配信終了後にＶＯＤ配信することがある。

前述のタイムラグの問題からライブコンテンツを構成するメディアセグメントの数が多くなる分、全メディアセグメントのヘッダ部分のデータ量の合計はメディアセグメントの数が少ない場合に比べて大きくなる。また、メディアセグメントの数（すなわち、ファイルの数）が多くなると、コンテンツが占有する「ディスク上のサイズ」も、メディアセグメントの数が少ない場合に比べて大きくなり易い。そのため、タイムラグが略問題にならないＶＯＤコンテンツまたは録画コンテンツのデータとして、従来のようにライブコンテンツのデータをそのまま用いる場合、無駄に大きな記憶領域が占有されてしまうという問題がある。

また、MPDデータによるHTTP配信の場合、メディアセグメントの数が多いと、その分だけメディアセグメントをリクエストするメッセージの発行頻度が高くなるため、リクエストメッセージ、応答メッセージの生成や送受信にかかる処理負荷が増えるとの問題もある。

本発明は上記課題に鑑みて成されたものであり、その主な目的は、コンテンツをＶＯＤ配信用または録画再生用に適切に処理可能な配信装置、および、コンテンツを録画再生用に適切に録画可能な再生装置を実現することにある。

本発明に係る再生装置は、上記課題を解決するために、複数の時分割データに時分割されて配信されるコンテンツを記録して、再生する再生装置において、上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得手段と、上記複数の時分割データの全部または一部を、異なる個数の時分割データに変換する第１変換手段と、
第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、
第１のメタデータに基づき、配信された上記複数の時分割データをそのまま再生し、第２のメタデータに基づき上記異なる個数の時分割データを記録して再生する再生手段と、を備えている、ことが望ましい。ここで、第１のメタデータは、コンテンツ自体に含まれていてもよいし、コンテンツとは別個のデータであってもよい。また、上記複数の時分割データの各々にヘッダ部が設けられている場合、第１のメタデータは、その一部ずつが各ヘッダ部に分散して含まれていてもよい。すなわち、各時分割データのヘッダ部に該時分割データに関する再生用情報が含まれていてもよい。

上記の構成によれば、本発明に係る再生装置は、時分割データの長さが長すぎる場合には時分割データの長さを短くし（時分割データの個数を多くし）、時分割データの長さが短すぎる場合には時分割データの長さを長くすることができる。ここで、時分割データの長さが長すぎるケースとしては、例えば、時分割データのファイル１つあたりのサイズが大きすぎて、時分割データのファイルが断片化されて記録されてしまうケースが挙げられる。この場合、再生時の時分割データの再生効率が落ちてしまう。一方、時分割データの長さが短すぎるケースとしては、例えば、時分割データの個数（ファイル数）があまりにも多いために、各ファイルのシークに時間がかかり再生効率が落ちてしまうケースが挙げられる。

したがって、本発明に係る再生装置は、コンテンツを録画再生用に適切に（再生時の再生効率を落とさずに）録画可能であるという効果を奏する。

本発明に係る再生方法は、上記課題を解決するために、複数の時分割データに時分割されて配信されるコンテンツを記録して再生する再生装置の再生方法において、上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得工程と、上記複数の時分割データの全部または一部を異なる個数の時分割データに変換する第１変換工程と、第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換工程と、第１のメタデータに基づき上記複数の時分割データをそのまま再生し、第２のメタデータに基づき上記異なる個数の時分割データを記録して再生する再生工程と、を含んでいる、ことを特徴としている。

上記の構成によれば、本発明に係る再生方法は、本発明に係る再生装置と同様の作用効果を奏する。

本発明に係る配信装置は、上記課題を解決するために、コンテンツが時分割された複数の時分割データを異なる個数の時分割データに変換する第１変換手段と、上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信手段と、第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信手段と、を備えている、ことを特徴としている。

上記の構成によれば、本発明に係る配信装置は、上記複数の時分割データを、異なる個数（より少数またはより多数）の時分割データに変換する。

上記複数の時分割データをより少数の時分割データに変換する場合には以下の利点がある。

上記複数の時分割データを構成する時分割データの個数よりも少ない個数の時分割データからなるより少数の時分割データに変換する。したがって、上記時分割 データのデータ構造が所定のヘッダ長のヘッダ情報を含むようなデータ構造になっている場合、上記より少数の時分割データの総データ量は、上記複数の時分割データの総データ量よりも少なくなる。さらに、ファイルシステムの種類に応じて定まる、上記より少数の時分割データが占有する記録媒体上のサイズは、時分割データのデータ構造とは無関係に、上記複数の時分割データが占有する記録媒体上のサイズよりも通常小さくなる。

したがって、本発明に係る配信装置は、コンテンツを録画再生用により効率良く記録できる。

一方、上記複数の時分割データをより多数の時分割データに変換する場合には以下の利点がある。上記複数の時分割データをより多数の時分割データに変換する場合、変換後の各時分割データの長さはより短くなる。したがって、配信装置が再生装置からコンテンツの再生要求を受け付けてから、１個目の時分割データを再生装置に配信するまでのタイムラグが小さくなる。

したがって、本発明に係る配信装置は、コンテンツをより低遅延でＶＯＤ配信できる。

以上のように、本発明に係る配信装置は、コンテンツをＶＯＤ配信用または録画再生用に適切に処理できるという効果を奏する。

本発明に係る配信装置は、上記課題を解決するために、複数の時分割データに時分割されて配信されるコンテンツを記録し配信する配信装置において、上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得手段と、上記複数の時分割データの全部または一部を、異なる個数の時分割データに変換する第１変換手段と、第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、第２のメタデータを配信するとともに、上記異なる個数の時分割データを記録して配信する配信手段と、を備えている、ことを特徴としている。

上記の構成によっても、本発明に係る配信装置は、コンテンツをＶＯＤ配信用または録画再生用に適切に処理できるという効果を奏する。

本発明に係る配信方法は、上記課題を解決するために、コンテンツが時分割された複数の時分割データを、異なる個数の時分割データに変換する第１変換工程と、上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信工程と、第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換工程と、第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信工程と、を含んでいる、ことを特徴としている。

上記の構成によれば、本発明に係る配信方法は、本発明に係る配信装置と同様の作用効果を奏する。

本発明に係る再生装置は、上記コンテンツは上記複数の時分割データに時分割されてライブ配信されるコンテンツであり、上記再生手段は、第１のメタデータに基づいて、上記複数の時分割データをライブ再生する、ことが望ましい。

上記の構成によれば、本発明に係る再生装置は、ライブ配信されるコンテンツを録画再生用に適切に録画できるというさらなる効果を奏する。

さらに、本発明に係る再生装置は、上記第１変換手段は、上記複数の時分割データの全部または一部を、より少数の時分割データに変換する、ことが望ましい。

上記の構成によれば、本発明に係る再生装置は、上記より少数の時分割データを再生するための再生用情報が示された第２のメタデータに基づいて、上記より少数の時分割データを記録して再生する。

また、上記の構成によれば、本発明に係る再生装置は、上記複数の時分割データの全部または一部を、上記全部または一部を構成する時分割データの個数よりも少ない個数の時分割データからなるより少数の時分割データに変換する。したがって、上記時分割データのデータ構造が所定のヘッダ長のヘッダ情報を含むようなデータ構造になっている場合、上記より少数の時分割データの総データ量は、上記複数の時分割データの全部または一部の総データ量よりも少なくなる。さらに、ファイルシステムの種類に応じて定まる、上記より少数の時分割データが占有する記録媒体上のサイズは、時分割データのデータ構造とは無関係に、上記複数の時分割データが占有する記録媒体上のサイズよりも通常小さくなる。

以上のことから、本発明に係る再生装置は、ライブ配信（通信によるライブ配信、または、ライブ放送）されるコンテンツを録画再生用により効率良く（すなわち、空き容量の消費をより抑えて）録画できるというさらなる効果を奏する。

本発明に係る再生装置では、上記第１変換手段が、上記全部または一部をグループ分けしながら各グループについて該グループの時分割データ群を統合することで、上記複数の時分割データを上記より少数の時分割データに変換する、ことが望ましい。

本発明に係る再生装置では、上記第１変換手段は、上記全部または一部を一定個数ずつのグループに分類する、ことが望ましい。

上記一定個数は、上記より少数の時分割データを構成する各時分割データの先頭位置がランダムアクセスポイントになるような個数である、ことが望ましい。

上記の構成によれば、本発明に係る再生装置は、上記より少数の時分割データのうちどの時分割データからも録画再生を開始することができるというさらなる効果を奏する。

また、本発明に係る再生装置では、第１のメタデータには上記全部または一部を構成する各時分割データの時間長である第１の時間長と上記より少数の時分割データを構成する各時分割データの時間長であって第１の時間長の整数倍である第２の時間長とが示されており、上記一定個数は、第１の時間長および上記第２の時間長により第１のメタデータに非明示的に示されている、ことが望ましい。

また、本発明に係る再生装置では、上記一定個数は、第１のメタデータに明示的に示されている、ことが望ましい。

また、本発明に係る再生装置では、第１のメタデータには上記一部を特定するための特定情報が示されており、上記第１変換手段が、上記特定情報に基づいて特定した上記複数の時分割データの一部を、上記より少数の時分割データに変換する、ことが望ましい。

また、本発明に係る再生装置では、上記特定情報は、上記複数の時分割データの一部を構成する時系列順で先頭の時分割データの識別子であり、上記複数の時分割データを構成する各時分割データの再生用情報には、該時分割データの識別子が含まれている、ことが望ましい。

本発明に係る再生装置では、第１のメタデータに示されている上記識別子が、上記取得手段が第１のメタデータを取得するタイミングにおいて未だ配信されていない先頭の時分割データの識別子になっている、ことが望ましい。

上記の構成によれば、本発明に係る再生装置は、コンテンツのライブ配信の途中からライブ再生を開始した場合、第１のメタデータを、すでに配信が終わっている（すなわち、再生装置が取得できない）時分割データに関する再生用情報を含まない第２のメタデータに変換する。

したがって、本発明に係る再生装置は、取得できなかった時分割データを録画再生しようとする無駄な処理を行うことなく、上記コンテンツを録画再生することができる、というさらなる効果を奏する。

なお、本発明に係る再生装置または配信装置としてコンピュータを動作させるプログラムであって、コンピュータを上記再生装置または配信装置の各手段として 機能させることを特徴とするプログラム、および、そのようなプログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。

さらに、複数の時分割データに時分割されてライブ配信されるコンテンツに関するメタデータであって、上記複数の時分割データの全部または一部を一定個数ずつのグループに分類し、上記一定個数の時分割データをグループ毎に統合するための統合情報と、上記全部または一部を構成する各時分割データに関する再生用情報と、が示されているメタデータも本発明の範疇に含まれる。

以上のように、本発明に係る再生装置は、コンテンツを録画再生用に適切に録画可能であるという効果を奏する。

また、本発明に係る配信装置は、コンテンツをＶＯＤ配信用または録画再生用に適切に処理可能であるという効果を奏する。

図１は、本発明の一実施形態に係る配信システムの要部構成を示した図である。 図２は、図１の配信システムで取り扱うメタデータの一例を示した図である。 図３は、図１の配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に示した図である。 図４は、図１の配信システムの動作を示すフローチャート図である。 図５は、図１の配信システムの変形例に係る配信システムで取り扱うメタデータの一例を示した図である。 図６は、図１の配信システムの変形例に係る配信システムで取り扱うメタデータの一例を示した図である。 図７は、図１の配信システムの変形例に係る配信システムで取り扱うメタデータの一例を示した図である。 図８は、図１の配信システムの変形例に係る配信システムで取り扱うメタデータの一例を示した図である。 図９は、本発明の別の一実施形態に係る配信システムの要部構成を示した図である。 図１０は、本発明の別の一実施形態に係る配信システムの要部構成を示した図である。 図１１は、図１０の配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に例示した図である。 図１２は、図１０の配信システムの変形例に係る配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に例示した図である。 図１３は、図１０の配信システムの変形例に係る配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に例示した図である。 図１４は、図１０の配信システムの変形例に係る配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に例示した図である。 図１５は、図１０の配信システムの変形例に係る配信システムにおける、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に例示した図である。 図１６は、図１０の配信システムで取り扱うメタデータの一例を示した図である。 図１７は、統合前のライブ配信用のメディアセグメント群におけるＲＡＰ（ランダムアクセスポイント）と統合後の録画再生用のメディアセグメントにおけるＲＡＰとを示した図である。 図１８は、ある時刻に記憶部に保存されている、ライブ配信用および録画再生用の一方または両方のメディアセグメント群を模式的に示した図である。 図１９は、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとについて、そのデータ構造の詳細を模式的に示した図である。 図２０は、本発明の別の一実施形態に係る配信システムの要部構成を示した図である。 図２１は、制御情報に記述された配信期間毎に、あるいはメディアセグメント毎に、メディアセグメントが統合処理実行の通知の記述を備えるか否か（この記述によって統合処理の実行の有無を判断可能か）を示す識別子を含む制御情報の例を示した図である。 図２２は、メディアセグメントが備えるメタデータボックスの一例を示した図である。 図２３は、メディアセグメントが備えるメタデータボックスの別の一例を示した図である。 図２４は、メディアセグメントが統合処理実行の通知の記述を備えるか否かを示す識別子、及び、同処理の不実行を許すか否かを示す識別子を含む、制御情報の例を示した図である。 図２５は、差分制御情報を利用する際の、メディアセグメントが備えるメタデータボックスの一例を示した図である。

〔実施形態１〕
本発明の一実施形態に係る配信システムについて図１〜図８を参照しながら以下に説明する。

本実施形態に係る配信システムでは、配信装置が通信によりライブカメラの番組映像をライブ配信し、再生装置が、配信された番組映像をライブ再生する。番組映像は複数のメディアセグメントで構成されており、各メディアセグメントは番組映像を時分割したものである。

本実施形態では、再生装置がライブ再生中の番組映像を効率的な録画方式で録画する。具体的には、ライブ配信用のメディアセグメントを一定個数受信する度 に、その一定個数のメディアセグメントを単一のメディアセグメントに統合して、記録する。したがって、再生装置の記憶容量を無駄に浪費することなく、録画された番組映像をライブ配信後に再生できる。

本実施形態では、番組映像を取得し、再生するために必要な制御情報を配信装置が再生装置に配信し、再生装置は、配信を受けた制御情報に基づいてその番組映像を取得し、再生するようになっている。なお、本発明は様々な規格や運用技術に適用可能であり、本発明をＭＰＥＧが規定する伝送規格であるＭＭＴ（MPEG Media Transport）に適用した場合にはＭＭＴで規定されている構成情報（CI：Composition Information）が制御情報に該当する。また、本発明をＭＰＥＧ−ＤＡＳＨ（MPEG's Dynamic Adaptive Streaming over HTTP）に適用した場合には、ＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤ（Media Presentation Data）が制御情報に該当する。

以下、本実施形態に係る配信システムの要部構成について図１〜図３を参照しながら説明する。図１は、本実施形態に係る配信システムを構成する配信装置および再生装置の要部構成を示した図である。また、図２は本実施形態に係る配信システムが取り扱う制御情報を模式的に示した図であり、図３は統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に示した図である。

図１に示すように、本実施形態に係る配信システムは、配信装置１００および再生装置２００を含んでいる。

（配信装置１００）
図１に示すように、配信装置１００は、記憶部１１０、制御情報更新部１２０、配信制御部１３０、送信部１４０およびセグメント生成部１５０を備えている。

（記憶部１１０）
記憶部１１０はデータを保存可能な記録媒体であり、記憶部１１０には番組映像をライブ配信するための制御情報が保存されている。

（セグメント生成部１５０）
セグメント生成部１５０は、ライブカメラからの映像が入力されている間、一定期間が経過する度に、その期間内の映像のみを映像情報として含むメディアセグメントの生成を完了して、その次のメディアセグメントの生成を開始する。

記憶部１１０に保存されたライブ配信のための制御情報には、セグメント生成部１５０で順次生成されるメディアセグメントの取得先と、それらの取得タイミングとが予め記載されている。

（制御情報更新部１２０）
制御情報更新部１２０は、記憶部１１０の制御情報を読み出して、ライブ配信用のメディアセグメント群を録画再生用のメディアセグメントに変換するためのセグメント変換用情報を制御情報に付加することで、制御情報を更新する。

例えば、制御情報更新部１２０は、記憶部１１０から読み出した図２の制御情報４ａに、変換後のメディアセグメントの時間長（３０秒）を表すagg_seg_dur属性を付加することで、制御情報４ａを制御情報５ａに更新する。

（配信制御部１３０）
配信制御部１３０は、送信部１４０を介して、セグメント変換用情報が付加された制御情報を配信する。制御情報には、セグメント生成部１５０で順次生成されるメディアセグメントの取得先と、それらの取得タイミングとが記載されており、再生装置は、制御情報に記載されたそれらの情報を使ってメディアセグメントをリクエストする。配信制御部１３０は、ライブ配信用のメディアセグメントが供給されるたびに、それを配信可能に設定し、再生装置からのリクエストに応じて送信部１４０を介してそのメディアセグメントを配信する。

（送信部１４０）
送信部１４０は、メディアセグメントおよび制御情報を通信路に乗せて送出する。

（再生装置２００）
図１に示すように、再生装置２００は、受信部２１０、再生部２２０、制御情報変換部２３０、セグメント変換部２４０および記憶部２５０を備えている。

（受信部２１０）
受信部２１０は、通信路を通じて番組映像等（具体的には、番組映像を取得および再生するための制御情報、および、番組映像を構成するメディアセグメント群）を受信するチューナである。

（再生部２２０）
再生部２２０は、制御情報に基づいて取得された番組映像を再生する。具体的には、番組映像をライブ配信するための制御情報に基づいてその取得された番組映像をライブ再生し、また、番組映像を録画再生するための制御情報に基づいて録画済みのその番組映像を録画再生する。

（制御情報変換部２３０）
制御情報変換部２３０は、セグメント変換用情報を含むライブ配信用の制御情報（特許請求の範囲の「第１のメタデータ」に対応）を、録画再生用の制御情報（特許請求の範囲の「第２のメタデータ」に対応）に変換して、記憶部２５０に記録する。

例えば、図２および図３に示すように、制御情報変換部２３０は、図２の制御情報５ａに含まれている、ライブ配信用のメディアセグメントの時間長（１０秒）を示すseg_dur属性と、録画再生用のメディアセグメントの時間長（３０秒）を表すagg_seg_dur属性と、に基づいて、３（＝３０秒÷１０秒）個のメディアセグメント（＃ｓ１〜＃ｓ３）に関する３つのseg要素（特許請求の範囲の「再生用情報」に対応）を、統合後の単一のメディアセグメント（＃ａｓ１）のseg要素に変換する。idが“ｓ４”以降のメディアセグメントについても同様である。また、制御情報変換部２３０は、seg_dur属性の値を元の値（１０秒）からagg_seg_dur属性に記載された値（３０秒）に置き換え、agg_seg_dur属性を削除する。結果として、制御情報変換部２３０は、図２の制御情報５ａを制御情報６ａに更新することになる。

（セグメント変換部２４０）
セグメント変換部２４０は、セグメント変換用情報（特許請求の範囲の「一定個数」を示す情報、および、特許請求の範囲の「統合情報」に対応）を含むライブ配信用の制御情報に基づいて、ライブ配信用のメディアセグメント（特許請求の範囲の「時分割データ」に対応）が一定個数だけ供給される度に、その一定個数のメディアセグメントを単一のメディアセグメントに変換する。

例えば、セグメント変換部２４０は、図２の制御情報５ａに含まれている、seg_dur属性と、agg_seg_dur属性と、に基づいて、ライブ配信用のメディアセグメントが３（＝３０秒÷１０秒）個供給される度に、その３個のメディアセグメントを録画再生用の単一のメディアセグメントに統合する。

セグメント変換部２４０は、変換後の単一のメディアセグメントを、そのメディアセグメントを構成要素とする番組映像を再生するための制御情報に関連付けて記憶部２５０に記録する。

（記憶部２５０）
記憶部２５０はデータを保存可能な記録媒体（本実施形態ではハードディスク）であり、番組映像のライブ配信後には記憶部２５０に、番組映像を録画再生するための制御情報と、番組映像を構成する録画再生用のメディアセグメント群と、が保存される。

以上、本実施形態に係る配信システムに含まれる配信装置１００および再生装置２００の構成について概略的に説明した。

（配信システムの動作）
次に、本実施形態に係る配信システムの動作について図２〜図４を参照しながら以下に説明する。なお、前提として、配信装置１００の記憶部１１０には、これ からライブ配信しようとする番組（以下、「対象番組」とも称する）の番組映像を配信および再生するための制御情報が保存されているものとする。

図４は、本実施形態に係る配信システムが対象番組の番組映像のライブ配信を開始してからライブ再生を終えるまでの動作を示すフローチャート図である。

図４に示すように、最初に、制御情報更新部１２０は、ライブ配信用の制御情報を記憶部１１０から読み出してセグメント変換用情報を付加し（Ｓ１）、更新後の制御情報を配信制御部１３０に供給する。

次に、制御情報更新部１２０は、送信部１４０を介して、更新後の制御情報を配信する（Ｓ２）。

なお、制御情報の更新（Ｓ１）及び更新後の制御情報の配信（Ｓ２）は、ライブ配信の開始に先立って行われる。ライブ配信の開始時刻になると、再生装置２００はメディアセグメントのリクエストを配信装置１００に送信する。

更新後の制御情報を受信した再生装置２００の受信部２１０は、受信した制御情報を再生部２２０、制御情報変換部２３０およびセグメント変換部２４０に供給する（Ｓ３）。

制御情報を受け取った制御情報変換部２３０は、制御情報をライブ配信用の制御情報から録画再生用の制御情報に変換し、記憶部２５０に記録する（Ｓ４）。

ライブ配信の開始時刻になると、配信装置１００のセグメント生成部１５０はメディアセグメントの生成を開始する。なお、ライブ配信の開始時刻には、配信するライブカメラ映像の生成を開始する時刻を指す場合（メディアセグメントの配信開始はその時刻より後になる）と、最初のメディアセグメントの生成が完了してメディアセグメントを配信する時刻を指す場合の２通りに解釈し得るが、本実施形態では前者の時刻のことを「ライブ配信の開始時刻」と称している。

その後、直近のＳ５の処理を行ってから（最初にＳ５の処理を行う場合にはライブ配信の開始時点から）一定期間が経過すると、配信装置１００のセグメント生成部１５０は、その期間内の映像のみを映像情報として含むメディアセグメントの生成を完了する。そして、メディアセグメントを受け取った配信制御部１３０は、再生装置２００からのリクエストに従い、送信部１４０を介して、メディアセグメントを配信する（Ｓ５）。

メディアセグメントを受信した再生装置２００の受信部２１０は、受信したメディアセグメントを再生部２２０およびセグメント変換部２４０に供給する（Ｓ６）。

再生部２２０は、Ｓ３で受け取ったライブ配信用の制御情報に基づいて、Ｓ６で受け取ったメディアセグメントをライブ再生する（Ｓ７）。

一方、セグメント変換部２４０は、直近のステップＳ８の処理時点以降にＮ（図２の例では、Ｎ＝３（３０秒÷１０秒））個のメディアセグメントを受け取ったが否かを判定する（Ｓ８）。

セグメント変換部２４０が直近のステップＳ８の処理時点以降にまだＮ個のメディアセグメントを受け取っていないと判定した場合には、セグメント変換部２４０は、直近のＳ６で供給されたメディアセグメントを記憶部２５０に記録する。そして、配信システムはステップＳ１０の処理に進む。

一方、セグメント変換部２４０は、直近のステップＳ８の処理時点以降にＮ個のメディアセグメントを受け取ったと判定した場合には、Ｓ３で受け取ったライブ配信用の制御情報に含まれているセグメント変換用情報に基づいて、直近のＳ６で供給されたメディアセグメントと記憶部２５０に記録済みの残りのＮ−１個のメディアセグメントとを録画再生用の単一のメディアセグメントに統合する（Ｓ９）。図２および図３の例に則して言えば、セグメント変換部２４０は、３個のメディアセグメント（＃ｓ１〜＃ｓ３）を単一のメディアセグメント（＃ａｓ１）に統合する。より具体的には、ｉ回目のステップＳ９の場合、録画再生用の制御情報における上からｉ個目のseg要素に対応するメディアセグメントを指し示す情報が統合後のi個目の単一のメディアセグメントを指すようにした上で、３個のメディアセグメントを単一のメディアセグメントに統合する。Ｓ９の処理の後、Ｓ１０の処理に進む。

Ｓ１０において、セグメント変換部２４０は、対象番組の映像を構成する最後のセグメントについてＳ８の判定処理を行ったか否かを判定する。セグメント変換部２４０が最後のセグメントについてＳ８の判定処理を行っていないと判定した場合、配信システムはＳ５の処理に戻る。

一方、セグメント変換部２４０が最後のセグメントについてＳ８の判定処理を行ったと判定した場合、配信システムは処理を終了する。

以上、ライブ配信を開始してからライブ再生が完了するまでの配信システムの動作について説明を行った。

なお、以上の説明からわかるように、対象番組が６０分の番組であってライブ配信用のメディアセグメントの時間長が１０秒である場合、配信装置は、３６０個のライブ配信用のメディアセグメントを配信することになる。そして、録画再生用のメディアセグメントの時間長が３０秒である場合、上記の動作の結果として、再生装置２００の記憶部２５０には１２０個の録画再生用のメディアセグメントが保存されることになる。また、記憶部２５０には、１２０個の録画再生用のメディアセグメントを順次再生するための録画再生用の制御情報が保存されることになる。

そして、再生装置２００は、対象番組の録画再生の指示を操作部（図示せず）を介して受け取った場合、まず、記憶部２５０から録画再生用の制御情報を読み出し、録画再生用の制御情報に基づいて、録画再生用のメディアセグメント群を順次読み出して再生することになる。

（再生装置２００の利点）
以上の説明を要約すると以下の通りである。

すなわち、再生装置２００は、３６０個のメディアセグメントに時分割されてライブ配信される６０分の番組コンテンツをその番組コンテンツを再生するための制御情報に基づいて再生する。

再生装置２００のセグメント変換部２４０は、３６０個のメディアセグメントを３個ずつのグループに分類し、各グループについて３個のメディアセグメントを統合することで、３６０個のメディアセグメントを時間長が３倍である１２０個のメディアセグメントに統合する。

また、再生装置２００の制御情報変換部２３０は、３６０個の各メディアセグメントに関する再生用情報（メディアセグメントのid等）と、統合前後の各メディアセグメントの時間長（それぞれ「１０秒」および「３０秒」）とが示されたライブ配信用の制御情報を、録画再生用の１２０個の各時分割データに関する再生用情報が示された制御情報に変換する。

そして、再生装置２００の再生部２２０は、ライブ配信用の制御情報に基づき３６０個のメディアセグメントをライブ再生し、録画再生用の制御情報に基づき１２０個のメディアセグメントを録画再生する。

上記の構成によって、再生装置２００の記憶部２５０には、録画再生用の時間長が３０秒であるメディアセグメントが１２０個保存されることになる。これに関し、時間長が３０秒である１２０個のメディアセグメントにおける実データ部の総データ量（番組映像のデータ量）は、時間長が１０秒である３６０個のメディアセグメントにおける実データ部の総データ量と変わらない。一方、ヘッダ部のヘッダ長が固定長である場合、１２０個のメディアセグメントにおけるヘッダ部の総データ量は、３６０個のメディアセグメントにおけるヘッダ部の総データ量の３分の１になる。

また、時間長が３０秒である１２０個のメディアセグメントの各ファイルが占有する「ディスク上のサイズ」は、時間長が１０秒である３６０個のメディアセグメントの各ファイルが占有する「ディスク上のサイズ」よりも一般的に小さくなる。

したがって、再生装置２００は、ライブ配信される番組コンテンツを録画再生用に従来よりも効率良く録画できるという効果を奏する。

（配信システムの変形例１）
実施形態１に係る配信システムの変形例１について図３および図５を参照して説明する。図５は、変形例１に係る配信システムが取り扱う制御情報を模式的に示した図である。

変形例１に係る配信システムは、上述の配信システムとは、制御情報更新部、セグメント変換部および制御情報変換部の動作が異なっている。

すなわち、配信装置側では、制御情報更新部が、単一のメディアセグメントに統合されるメディアセグメントの個数を示すagg_seg_num属性を付与することで、記憶部１１０のライブ配信用の制御情報を更新する。例えば、制御情報更新部は、図５の制御情報４ｂを図５の制御情報５ｂに更新する。

また、再生装置側では、制御情報変換部は、ライブ配信用の制御情報に含まれているagg_seg_num属性の属性値に基づいて、ライブ配信用の制御情報を録画再生用の制御情報に更新する。例えば、図３および図５に示すように、制御情報変換部はagg_seg_num属性の属性値に基づいて、３個のメディアセグメント（＃ｓ１〜＃ｓ３）に関する３つのseg要素を、統合後の単一のメディアセグメント（＃ａｓ１）のseg要素に変換する。idが“ｓ４”以降のメディアセグメントについても同様である。また、制御情報変換部は、agg_seg_num属性を削除する。結果として、制御情報変換部２３０は、図５の制御情報５ｂを制御情報６ｂに変換することになる。

さらに、セグメント変換部は、供給される制御情報に含まれている、agg_seg_num属性の属性値に基づいて、その属性値に等しい個数のライブ配信用のメディアセグメントが供給される度に、それらのメディアセグメントを録画再生用の単一のメディアセグメントに統合する。例えば、セグメント変換部は、図５の制御情報５ｂに含まれている、agg_seg_num属性の属性値“３”に基づいて、図３の３個のメディアセグメント（＃ｓ１〜＃ｓ３）を図３の単一のメディアセグメント（＃ａｓ１）に統合する。

（配信システムの変形例２）
実施形態１に係る配信システムの変形例２について図６を参照して説明する。図６は、変形例２に係る配信システムが取り扱う制御情報を模式的に示した図である。

変形例２に係る配信システムは、変形例１に係る配信システムとは、制御情報更新部、配信制御部、受信部、セグメント変換部および制御情報変換部の動作が異なっている。

すなわち、配信装置側では、制御情報更新部が、単一のメディアセグメントに統合されるメディアセグメントの個数を示すagg_seg_num属性に加え、セグメント生成部１５０が現在生成しているメディアセグメント（すなわち、制御情報更新部の処理のタイミングで未だ配信されていない先頭のメディアセグメント）の直後にある、単一のメディアセグメントに統合可能なメディアセグメントグループの先頭セグメントのidの値を属性値とするagg_point属性（特許請求の範囲の「特定情報」「識別子」に対応）を付与することで、記憶部１１０のライブ配信用の制御情報を更新する。現在生成しているメディアセグメントが単一のメディアセグメントに統合可能なメディアセグメントグループの先頭セグメントであれば、そのidの値を使う。例えば、制御情報更新部は、図６の制御情報４ｂを図６の制御情報５ｃに更新する。

この例は、既に配信が開始されているライブ配信サービスに途中から新たに再生装置が参加し、再生装置が途中からライブ配信の受信を開始することを想定している。再生装置は任意のタイミングでライブ配信サービスに参加できるため、参加時点以降に配信されるメディアセグメントのseg要素のみを含んだ制御情報では、制御情報の先頭のseg要素に対応するセグメントが単一のメディアセグメントに統合可能なメディアセグメントグループの先頭セグメントであるとは限らない。このため、配信装置は、新たな再生装置からのライブ配信要求を受け付けると、記憶部１１０の制御情報に更新処理を施す。即ち、参加時点以降に配信されるメディアセグメントのseg要素のみを含む制御情報に変換するとともに、単一のメディアセグメントに統合可能なメディアセグメントグループの先頭セグメントを示す情報を付加する。配信制御部は、制御情報更新部による更新後の制御情報を、送信部１４０を介して新たに参加した再生装置に送信する。

また、再生装置側では、受信部が、制御情報を受信し、制御情報を再生部２２０、制御情報変換部およびセグメント変換部に供給する。そして、制御情報変換部は、供給されたライブ配信用の制御情報に含まれているagg_seg_num属性およびagg_point属性の各属性値に基づいて、ライブ配信用の制御情報を録画再生用の制御情報に更新する。具体的には、agg_point属性の属性値と等しい値のidが付与されているメディアセグメントおよび以降のメディアセグメントからなる一群のメディアセグメントを、agg_seg_num属性の属性値に等しい個数ずつのグループに分ける。そして、グループ毎に、そのグループの全メディアセグメントに関するseg要素群を、単一のメディアセグメントのseg要素に変換する。図６は、idが“ｓ３”のメディアセグメントが生成されている時刻から配信に参加しライブ配信を開始した例を示している。例えば、図６に示すように、制御情報変換部は、agg_seg_num属性の属性値“３”とagg_point属性の属性値“ｓ４”とに基づいて、３個のメディアセグメント（＃ｓ４〜＃ｓ６）に関する３つのseg要素を、統合後の単一のメディアセグメント（＃ａｓ２）のseg要素に変換する。idが“ｓ７”以降のメディアセグメントについても同様である。また、制御情報変換部は、agg_seg_num属性およびagg_point属性を制御情報から削除する。結果として、制御情報変換部２３０は、図６の制御情報５ｃを制御情報６ｃに変換することになる。

さらに、セグメント変換部は、供給されたライブ配信用の制御情報に含まれているagg_seg_num属性およびagg_point属性の各属性値に基づいて、agg_seg_num属性の属性値に等しい個数のメディアセグメントを受信するたびに、それらのメディアセグメントを録画再生用の単一のメディアセグメントに統合する。例えば、図６の制御情報５ｃに含まれている、agg_seg_num属性の属性値“３”とagg_point属性の属性値“ｓ４”とに基づいて、３個のメディアセグメント（＃ｓ４〜＃ｓ６）を図３の単一のメディアセグメント（＃ａｓ２）に統合する。

本変形例では、番組のライブ配信中に再生装置がその番組の受信を開始するようなケースにおいても、再生装置は、一定個数のメディアセグメントを受信する度に、それらのメディアセグメントを単一のメディアセグメントに統合できる。また、このケースで再生装置が生成する録画再生用の制御情報には、受信を開始した時点からの（図６の例では“ｓ３”以降の）メディアセグメントの情報のみが含まれ、再生装置が番組の受信を開始する時点ですでに配信された（図６の例では“ｓ３”より前の）メディアセグメントの情報は含まれていない。したがって、本変形例に係る再生装置は、録画再生する際に、記憶部１１０に保存されている統合処理しないメディアセグメント“ｓ３”及び統合処理したメディアセグメント“ａｓ２”、“ａｓ３”、・・・を用いて、受信を開始した時点からの映像を再生できる、という利点があると言える。

本変形例ではagg_point属性の値をseg要素のidの値としたが、これに限らず、時刻による指定なども可能である。また、本変形例ではagg_point属性とagg_seg_num属性と組合せた例を示したが、セグメント長さを示すseg_dur属性、agg_seg_dur属性との組合せも可能であることは言うまでもない。

（配信システムの変形例３）
実施形態１に係る配信システムの変形例３について図３および図７を参照して説明する。図７は、変形例３に係る配信システムが取り扱う制御情報を模式的に示した図である。

変形例３に係る配信システムは、変形例１に係る配信システムとは、制御情報更新部、セグメント変換部および制御情報変換部の動作が異なっている。

すなわち、配信装置側では、制御情報更新部が、一緒に統合される各メディアセグメント（例えば、３つのメディアセグメントの各々）のseg要素に、統合後のメディアセグメントに付与するidの値を属性値とするagg属性を付与することで、記憶部１１０のライブ配信用の制御情報を更新する。例えば、制御情報更新部は、図７の制御情報４ｂを図７の制御情報５ｄに更新する。

また、再生装置側では、制御情報変換部は、ライブ再生用の制御情報に含まれているagg属性の属性値に基づいて、ライブ配信用の制御情報を録画再生用の制御情報に更新する。具体的には、agg属性の属性値が同一であるseg要素群を単一のseg要素に変換する。制御情報変換部は、例えば、図３および図７に示すように、agg属性の属性値に基づいて、３個のメディアセグメント（＃ｓ１〜＃ｓ３）に関する３つのseg要素を、統合後の単一のメディアセグメント（＃ａｓ１）のseg要素に変換する。idが“ｓ４”以降のメディアセグメントについても同様である。結果として、制御情報変換部２３０は、図７の制御情報５ｄを制御情報６ｂに変換することになる。

さらに、セグメント変換部は、図５の制御情報５ｄを参照し、agg属性の属性値として同一の属性値を持つ３つのseg要素に対応する３個のライブ配信用のメディアセグメントが供給される度に、その３個のメディアセグメントを録画再生用の単一のメディアセグメントに統合する。例えば、セグメント変換部は、図３の３個のメディアセグメント（＃ｓ１〜＃ｓ３）を図３の単一のメディアセグメント（＃ａｓ１）に統合する。

本変形例では、agg属性の値として統合後のメディアセグメントのidの値（“as1”など）を記述している。このようにすることで制御情報変換時のidの割当が容易となる。無論、統合するメディアセグメントのagg属性には同一の値が記述されていればよく、値は上記に限らない。また、統合するメディアセグメントのagg属性の値の一部に同一の記述があるといった構成も可能である。例えば、id=“as1-1”、id=“as1-2”、id=“as1-3”が付された３つのメディアセグメントをid=“as1”のセグメントに統合するとしてもよい。

図７の制御情報４ｂおよび制御情報６ｂはそれぞれ、ライブ配信用の制御情報、ＶＯＤ配信用（録画再生用）の制御情報と解釈される。このため、制御情報４ｂおよび制御情報６ｂのControl要素タグがそれらを示す情報を更に持つとしてもよい。具体的には、制御情報４ｂのControl要素タグを<Control profile=“Live”>、制御情報６ｂのControl要素タグを<Control profile=“onDemand”>としてもよい。

（配信システムの変形例４） 実施形態１に係る配信システムの変形例４について図３および図８を参照して説明する。図８は、変形例４に係る配信システムが取り扱う制御情報を模式的に示した図である。

変形例４に係る配信システムは、変形例１に係る配信システムとは、制御情報更新部、セグメント変換部、制御情報変換部および再生部の動作が異なっている。

すなわち、配信装置側では、制御情報更新部が、一緒に統合されるメディアセグメント群に対応するseg要素群の各々を、そのseg要素群の各seg要素を下位の要素とするseg要素であって統合後のメディアセグメントに付与するidの値をid属性の属性値とするseg要素（以下、「上位のseg要素」とも称する）に更新することで、記憶部１１０のライブ配信用の制御情報を、ライブ配信および録画再生兼用の制御情報に更新する。例えば、制御情報更新部は、図８の制御情報４ｂを図８の制御情報５ｅに更新する。

また、再生装置側では、制御情報変換部は、更新後の制御情報に含まれている上位のseg要素の各記述をそのまま残し、上位のseg要素に含まれる下位のseg要素の記述を削除することで、ライブ配信および録画再生兼用の制御情報を録画再生専用の制御情報に変換する。例えば、制御情報変換部は、図８の制御情報５ｅを制御情報６ｂに変換することになる。但し、ライブ配信および録画再生兼用の制御情報でも録画再生用のセグメントは再生できるため、録画再生専用の制御情報への変換処理は必須ではない。

さらに、セグメント変換部は、供給された制御情報に含まれている上位のseg要素の各々について、そのseg要素の下位にあるseg要素群に対応するライブ配信用の一群のメディアセグメントが供給されるたびに、その一群のメディアセグメントを録画再生用の単一のメディアセグメントに統合する。例えば、図８の制御情報５ｅが供給され、id属性の属性値がそれぞれ“ｓ１”〜“ｓ３”である図３の３つのメディアセグメント（＃ｓ１〜＃ｓ３）が供給されると、３つメディアセグメントを単一のメディアセグメント（＃ａｓ１）に統合する。

再生部は、供給された制御情報に基づいて、ライブ配信用のメディアセグメント群をライブ再生する。具体的には、制御情報に記述されたseg要素のうち、上位のseg要素を参照せずに下位のseg要素のみを参照することでライブ配信用のメディアセグメント群をライブ再生する。

変形例４に係る配信システムにおいては、再生装置が制御情報変換部を備えていなくともよい。この場合、再生部は、録画再生の際に、ライブ配信および録画再生兼用の制御情報を記憶部２５０から読み出すとともに、録画再生用のメディアセグメント群を記憶部２５０から読み出して再生すればよい。具体的には、制御情報に記述されたseg要素のうち、下位のseg要素を参照せずに上位のseg要素のみを参照することで録画再生用のメディアセグメント群を再生すればよい。

〔実施形態２〕
本発明の別の一実施形態について、図９を参照して説明する。図９は、本実施形態に係る配信システムを構成する配信装置および再生装置の要部構成を示した図である。

本実施形態に係る配信システムでは、１次配信装置が通信によりライブカメラの番組映像を２次配信装置（プロキシサーバ）に配信し、２次配信装置はライブカメラの番組映像を、ライブ配信の要求を１次配信装置に送信した再生装置に向けてライブ配信する。なお、本実施形態では特に説明しないが、再生装置へのライブ配信を２次配信装置経由とせずに、１次配信装置が２次配信装置と再生装置とにそれぞれ番組映像をライブ配信するといった構成も当然可能である。

また、２次配信装置は、ライブカメラの番組映像をＶＯＤ配信に適した記録方式で記録し、ＶＯＤ配信の要求を出した再生装置に向けて番組映像をＶＯＤ配信する。

図９に示すように、本実施形態に係る配信システムは、１次配信装置１００’、再生装置２００’および２次配信装置３００を含んでいる。

（１次配信装置１００’）
図９に示すように、１次配信装置１００’は、記憶部１１０、制御情報更新部１２０、配信制御部１３０’、通信部１４０’およびセグメント生成部１５０を備えている。このうち、記憶部１１０、制御情報更新部１２０、およびセグメント生成部１５０については、実施形態１で説明したので、ここでは説明を省略する。

（配信制御部１３０’）
配信制御部１３０’は、再生装置２００’からライブ配信の要求を受け付けると、ライブ配信用の制御情報、および、ライブ配信用のメディアセグメントを２次配信装置３００に送信する。送信されたライブ配信用の制御情報およびメディアセグメントは、そのまま２次配信装置３００の通信部３１０を介して再生装置２００’へ配信される。なお、１次配信装置１００’から２次配信装置３００への配信は必ずしも再生装置２００’からのライブ配信の要求をトリガとする必要はなく、例えば、サービス提供者が別途設定した任意の時点で予め配信を開始するといった構成でもよい。

（通信部１４０’）
通信部１４０’は、メディアセグメントおよび制御情報を送信する通信インタフェースである。

（再生装置２００’）
図９に示すように、再生装置２００’は、通信部２１０’および再生部２２０を備えている。再生部２２０については、実施形態１で説明したので、ここでは説明を省略する。

（通信部２１０’）
通信部２１０’は、番組のライブ配信およびＶＯＤ配信の要求を送信したり、メディアセグメントおよび制御情報を受信したりするための通信インタフェースである。

（２次配信装置３００）
図９に示すように、２次配信装置３００は、通信部３１０、制御情報変換部３２０、セグメント変換部３３０、記憶部３４０および配信制御部３５０を備えている。制御情報変換部３２０、セグメント変換部３３０および記憶部３４０は、それぞれ、実施形態１で図１と共に説明した制御情報変換部２３０、セグメント変換部２４０および記憶部２５０と同一のものであるので、ここでは説明を省略する。なお、実施形態１では、セグメント変換部３３０で変換された後の制御情報を録画再生用の制御情報と呼称していたが、本実施形態の制御情報変換部３２０で形成される変換後の制御情報は、利用の用途がＶＯＤ再生であることからＶＯＤ再生用の制御情報と呼称する。録画再生用の制御情報とＶＯＤ再生用の制御情報とは記述される情報の内容自体は同一のものである。

（通信部３１０）
通信部３１０は、ライブ番組の番組映像等（具体的には、番組映像を取得および再生するための制御情報、および、番組映像を構成するメディアセグメント群）を送受信する通信インタフェースである。

（配信制御３５０）
配信制御部３５０は、ライブ配信用の制御情報を受信した場合に、制御情報を再生装置２００に配信する（通信部３１０に、１次配信装置１００’から受け取ったライブ配信用の制御情報をそのまま再生装置２００’に配信するよう指示する）とともに制御情報変換部３２０およびセグメント変換部３３０に供給する。また、配信制御部３５０は、ライブ配信用のメディアセグメントを受信した場合に、メディアセグメントを再生装置２００に配信する（通信部３１０に、１次配信装置１００’から受け取ったライブ配信用のメディアセグメントをそのまま再生装置２００’に配信するよう指示する）とともにセグメント変換部３３０に供給する。

また、配信制御部３５０は、ＶＯＤ配信の要求を再生装置２００’から受け付けた場合に、ＶＯＤ配信用の制御情報を記憶部３４０から読み出して再生装置２００’に配信するとともに、ＶＯＤ配信用のメディアセグメント群を記憶部３４０から順次読み出して再生装置２００’に配信する。

以上、本実施形態に係る配信システムに含まれる１次配信装置１００’、再生装置２００’および２次配信装置３００の構成について概略的に説明した。

（配信システムの動作）
ライブ配信の要求を１次配信装置１００’が再生装置２００’から受信してからの配信システムの動作について、図４を参照しながら、簡単に説明する。

最初に、１次配信装置１００’は、配信装置１００と同様にＳ１の処理を行った後、更新後のライブ配信用の制御情報を２次配信装置３００に送信する（この処理は、Ｓ２における送信先を２次配信装置３００に置き換えたものに相当する）。

２次配信装置３００の配信制御部３５０は、通信部３１０が受信したライブ配信用の制御情報を、再生装置２００’に送信するとともに制御情報変換部３２０およびセグメント変換部３３０に供給する（この処理はＳ３における再生部への供給を再生装置２００’への送信に置き換えたものに相当する）。

制御情報が供給された制御情報変換部３２０は、制御情報変換部２３０と同様にＳ４の処理を行う。

その後、配信システムは、１次配信装置１００’がセグメントの生成を完了するたびに、以降のＳ１０までの処理を繰り返す。

すなわち、１次配信装置１００’は、生成したセグメントを２次配信装置３００に送信し（この処理は、Ｓ５における送信先を２次配信装置３００に置き換えたものに相当する）、２次配信装置３００の配信制御部３５０は、通信部３１０が受信したセグメントを再生装置２００’に送信するとともにセグメント変換部３３０に供給する（この処理は、Ｓ６における再生部への供給を再生装置２００’への送信に置き換えたものに相当する）。

そして、再生装置２００’では、通信部２１０’が受信したセグメントを再生部２２０が再生する（Ｓ７）。

一方、２次配信装置３００では、セグメント変換部３３０がセグメント変換部２４０と同様にＳ８〜Ｓ１０の処理を行う。

以上、ライブ配信を開始してからライブ再生が完了するまでの配信システムの動作について説明を行った。

なお、以上の説明からわかるように、対象番組が６０分の番組であってライブ配信用のメディアセグメントの時間長が１０秒である場合、１次配信装置１００’は、２次配信装置３００を経由して３６０個のライブ配信用のメディアセグメントを再生装置２００’に配信することになる。そして、録画再生およびＶＯＤ再生用のメディアセグメントの時間長が３０秒である場合、上記の動作の結果として、２次配信装置３００’の記憶部３４０には１２０個の録画再生およびＶＯＤ再生用のメディアセグメントが保存されることになる。また、記憶部３４０には、１２０個の録画再生およびＶＯＤ再生用のメディアセグメントを順次再生するための録画再生およびＶＯＤ再生用の制御情報が保存されることになる。

その後、再生装置２００’は、対象番組のＶＯＤ配信を受ける旨の指示を操作部（図示せず）を介して受け取った場合、再生装置２００’は、２次配信装置３００にＶＯＤ配信を要求する。そして、再生装置２００’は、２次配信装置３００から、録画再生およびＶＯＤ再生用の制御情報を受信するとともに、録画再生およびＶＯＤ再生用のメディアセグメント群を順次受信する。再生装置２００’は、受信した制御情報に基づいて、メディアセグメント群を受信しながら順次再生する。

（２次配信装置３００の利点）
２次配信装置３００のセグメント変換部３３０は、例えば、６０分のライブ番組の番組コンテンツが時分割された３６０個のメディアセグメントを３個ずつのグループに分類し、各グループについて３個のメディアセグメント（時分割データ）を統合することで、時間長が１０秒である３６０個のメディアセグメントを時間長が３０秒である１２０個のメディアセグメントに変換する。

また、２次配信装置３００の配信制御部３５０は、３６０個のメディアセグメントの各々に関する再生用情報（seg要素）と、単一のグループに分類すべきメディアセグメントの個数である「３」とが示されたライブ配信用の制御情報を再生装置２００’に配信するとともに、３６０個のメディアセグメントを再生装置２００’にライブ配信する。なお、先に述べたとおり、この処理は、２次配信装置３００を介さず、１次配信装置と再生装置との間で行われてもよい。

そして、２次配信装置３００の制御情報変換部３２０は、ライブ再生用の制御情報を、１２０個のメディアセグメントの各々に関する再生用情報（seg要素）が示されたＶＯＤ再生用の制御情報に変換する。さらに、配信制御部３５０は、ＶＯＤ再生用の制御情報を再生装置２００’に配信するとともに、１２０個のメディアセグメントを再生装置２００’にＶＯＤ配信する。

上記の構成によって、２次配信装置３００の記憶部３４０には、ライブ配信用のメディアセグメントより時間長が３倍長いＶＯＤ配信用のメディアセグメントが１２０個保存されることになる。

したがって、実施形態１の（再生装置２００の利点）での説明からわかるように、２次配信装置３００は、ライブ配信される番組コンテンツをＶＯＤ配信用に従来よりも効率良く記録できるという効果を奏する。

さらに、再生装置２００’から２次配信装置３００へメディアセグメントのＶＯＤ配信を要求するリクエストの数は、ライブ配信時にメディアセグメントのライブ配信を要求したリクエストの数（３６０回）の３分の１である１２０回に低減されるという効果を奏する。

なお、制御情報更新部１２０を、実施形態１で説明した変形例１に係る配信装置の制御情報更新部に置き換えるとともに、制御情報変換部３２０、セグメント変換部３３０を、変形例１に係る再生装置の制御情報変換部およびセグメント変換部に置き換えても良い。実施形態１で説明した変形例２〜４についても同様である。また、再生部２２０を、実施形態１で説明した変形例４に係る再生装置の再生部に置き換えても良い。

〔実施形態３〕
本発明のさらに別の一実施形態に係る配信システムについて図１０および図１１を参照しながら以下に説明する。図１０は、本実施形態に係る配信システムを構成する配信装置および再生装置の要部構成を示した図である。また、図１１は、統合前のライブ配信用のメディアセグメント群と統合後の録画再生用のメディアセグメントとを模式的に示した図である。

本実施形態に係る配信システムは、実施形態１に係る配信システムと同様に、配信装置が通信によりライブカメラの番組映像をライブ配信し、再生装置が、配信された番組映像をライブ再生し、且つ、再生装置がライブ再生中の番組映像を効率的な録画方式で録画する。

一方、本実施形態に係る配信システムは、配信装置がセグメント変換用情報を制御情報ではなくメディアセグメントのヘッダ部に付加する点で、実施形態１に係る配信システムとは異なっている。

以下、本実施形態に係る配信システムの要部構成について図１０を参照しながら説明する。

図１０に示すように、本実施形態に係る配信システムは、配信装置１００ａおよび再生装置２００ａを含んでいる。

（配信装置１００ａ）
図１０に示すように、配信装置１００ａは、記憶部１１０、制御情報読出部１２５、配信制御部１３０、送信部１４０、セグメント生成部１５０およびセグメント変換情報付加部１６０を備えている。記憶部１１０および送信部１４０については、実施形態１で説明したので、ここでは説明を省略する。

（制御情報読出部１２５）
制御情報読出部１２５は、記憶部１１０に保存されている、番組映像をライブ配信およびライブ再生するための制御情報を読み出して、配信制御部１３０に供給する。

（配信制御部１３０）
配信制御部１３０は、送信部１４０を介して、ライブ配信用の制御情報を配信する。また、配信制御部１３０は、ライブ配信用のメディアセグメントが供給されるたびに、送信部１４０を介して、セグメント変換用情報をヘッダ部に含むそのメディアセグメントを配信する。

（セグメント生成部１５０）
セグメント生成部１５０は、ライブカメラからの映像が入力されている間、一定期間が経過する度に、その期間内の映像のみを映像情報として含むメディアセグメントの生成を完了して、その次のメディアセグメントの生成を開始する。

（セグメント変換情報付加部１６０）
セグメント変換情報付加部１６０は、メディアセグメントが供給される度に、そのメディアセグメントのヘッダ部にセグメント変換用情報を付加する。具体的には、一緒に統合される一群のメディアセグメントの各々について、そのメディアセグメントが供給される度に、そのメディアセグメントのヘッダ部に変数aggを付加する。各メディアセグメントのヘッダ部に付加する変数aggの値は同じ値であり、統合後のメディアセグメントのヘッダ部に含まれことになる変数idの値と同じ値である。

例えば、セグメント変換情報付加部１６０は、図１１に示すように、一緒に統合される３つのメディアセグメント＃ｓ１〜＃ｓ３の各ヘッダ部に“ａｓ１”の値を持つ変数aggを付加する。

なお、本実施形態の以下の説明では、説明を簡便にするために、メディアセグメントのヘッダ部に付された変数agg、idと、制御情報のseg要素に付された変数idとは同じ値をとる変数であるものとし、変数idの値を、各々のメディアセグメントを特定する情報としてやり取りされる情報であるものとした。実際には、メディアセグメントのヘッダ部に付された変数idと制御情報のseg要素に付される変数idとは独立したものであり、その場合には、メディアセグメントを指し示すURI情報などを、メディアセグメントを特定する情報としてやり取りすることで、同様の動作が実行される。

（再生装置２００ａ）
図１０に示すように、再生装置２００ａは、受信部２１０、再生部２２０、制御情報変換部２３０ａ、セグメント変換情報解析部２３５、セグメント変換部２４０ａおよび記憶部２５０を備えている。受信部２１０、再生部２２０および記憶部２５０については、実施形態１で説明したので、ここでは説明を省略する。

（セグメント変換情報解析部２３５）
セグメント変換情報解析部２３５は、受信部２１０から順次供給されてくる各セグメントのヘッダ部（変数agg）を解析して、一緒に統合すべき一群のメディアセグメントを特定し、特定した一群のメディアセグメントのid、および、統合後のメディアセグメントのid（即ち変数aggの値）を制御情報変換部２３０ａおよびセグメント変換部２４０ａに供給する。

例えば、３つのメディアセグメント＃ｓ１〜＃ｓ３の各ヘッダ部に変数aggの値として“ａｓ１”が含まれており、４つ目のメディアセグメント＃ｓ４のヘッダ部に変数aggの値として“ａｓ２”が含まれていることを確認した場合には、以下の処理を行う。すなわち、３つのメディアセグメント＃ｓ１〜＃ｓ３の各ヘッダ部の変数idの値（“ｓ１”〜“ｓ３”）と、３つのメディアセグメント＃ｓ１〜＃ｓ３のヘッダ部に共通して含まれている変数aggの値（“ａｓ１”）とを、制御情報変換部２３０ａおよびセグメント変換部２４０ａに供給する。

（制御情報変換部２３０ａ）
制御情報変換部２３０ａは、ライブ配信用の制御情報を、録画再生用の制御情報に変換して、記憶部２５０に記録する。この際、変換には、セグメント変換情報解析部２３５から供給された情報を使う。

例えば、３つのメディアセグメント＃ｓ１〜＃ｓ３の各ヘッダ部の変数idの値（“ｓ１”〜“ｓ３”）と、３つのメディアセグメント＃ｓ１〜＃ｓ３のヘッダ部に共通して含まれている変数aggの値（“ａｓ１”）とが供給されたとき、図７の制御情報４ｂのidが“ｓ１”〜“ｓ３”の３つのseg要素を統合し、idが“ａｓ１”の１つのseg要素に統合した同図の制御情報６ｂに変換する（つまり、実施形態１の変形例３では制御情報中に書かれていたセグメント変換用情報aggが、本実施形態ではメディアセグメントのヘッダ部に書かれている）。

（セグメント変換部２４０ａ）
セグメント変換部２４０ａは、セグメント変換情報解析部２３５から、同じaggの値を持ったライブ配信用のメディアセグメントのidが供給される度に、それらのidに対応したメディアセグメントを単一のメディアセグメントに変換する。そして、セグメント変換情報解析部２３５から供給されたaggの値を統合後のメディアセグメントに設定する。

例えば、セグメント変換部２４０ａは、３つの変数idの値（“ｓ１”〜“ｓ３”）と、変数aggの値（“ａｓ１”）とを受け取ると、図１１に示すように、ライブ配信用の３つのメディアセグメント＃ｓ１〜＃ｓ３を録画再生用の単一のメディアセグメント＃ａｓ１に統合する。

セグメント変換部２４０ａは、統合後の単一のメディアセグメントを、そのメディアセグメントを構成要素とする番組映像に対応する、セグメント変換部２４０ａで変換された録画再生用の制御情報に関連付けて記憶部２５０に記録する。

以上、本実施形態に係る配信システムに含まれる配信装置１００ａおよび再生装置２００ａの構成について概略的に説明した。

（配信システムの動作）
次に、本実施形態に係る配信システムの動作について以下に説明する。なお、前提として、配信装置１００ａの記憶部１１０には、対象番組の番組映像をライブ配信するための制御情報が保存されているものとする。

ライブ配信の開始時刻に先立って、制御情報読出部１２５は、ライブ配信用の制御情報を記憶部１１０から読み出して、配信制御部１３０に供給する。

次に、配信制御部１３０は、送信部１４０を介して、ライブ配信用の制御情報を配信する。

制御情報を受信した再生装置２００ａの受信部２１０は、受信した制御情報を再生部２２０、制御情報変換部２３０ａに供給する。

その後、ライブ配信の開始時刻になると、配信システムは、配信装置１００ａがメディアセグメントの生成を開始し、メディアセグメントの生成を完了するたびに、以降の処理を繰り返す。

すなわち、セグメント生成部１５０はメディアセグメントの生成を完了すると、メディアセグメントをセグメント変換情報付加部１６０に供給する。

セグメント変換情報付加部１６０は、供給されたメディアセグメントにセグメント変換用情報を付加する。具体的には、一緒に統合される他の１つ以上のメディアセグメントのaggの値と同じ値のaggを、供給されたセグメントのヘッダ部に付加する。

そして、セグメント変換用情報が付与されたメディアセグメントをセグメント変換情報付加部１６０から受け取った配信制御部１３０は、再生装置２００ａからのリクエストに応じ、送信部１４０を介して、メディアセグメントを配信する。

メディアセグメントを受信した再生装置２００ａの受信部２１０は、受信したメディアセグメントを再生部２２０とセグメント変換情報解析部２３５に供給する。

再生部２２０は、ライブ配信用の制御情報とメディアセグメントとを使って映像をライブ再生する。

セグメント変換情報解析部２３５は、供給されたメディアセグメントのaggの値がその前に供給されたメディアセグメントのaggの値と異なっているか否かを判定する。

セグメント変換情報解析部２３５は、異なっていないと判定した場合には供給されたメディアセグメントをセグメント変換部２４０ａに供給する。一方、異なっていると判定した場合には、供給されたメディアセグメントをセグメント変換部２４０ａに供給すると共に、直近で供給された同一値のaggをヘッダ部に含む一群のメディアセグメントの各idの値と、各メディアセグメントで同一であるaggの値と、を制御情報変換部２３０ａおよびセグメント変換部２４０ａに供給する。

制御情報変換部２３０ａは、セグメント変換情報解析部２３５から受け取った各idの値と、aggの値とに基づいて、記憶部２５０の制御情報を更新する。例えば、記憶部２５０に図７の制御情報４ｂが記録されており、各idの値として“ｓ１”〜“ｓ３”を受け取り、aggの値として“ａｓ１”を受け取った場合、制御情報４ｂの上から３つのseg要素を図７の制御情報６ｂの上から１つ目のseg要素に更新する。

一方、セグメント変換部２４０ａは、セグメント変換情報解析部２３５から受け取った各idの値と、aggの値とに基づいて、既に受け取っているライブ配信用の上記一群のメディアセグメントを録画再生用の単一のメディアセグメントに更新する。例えば、各idの値として“ｓ１”〜“ｓ３”を受け取り、aggの値として“ａｓ１”を受け取った場合、既に受け取っているライブ配信用の３つのメディアセグメント＃ｓ１〜＃ｓ３を録画再生用の単一のメディアセグメント＃ａｓ１に統合する。そして、セグメント変換部２４０ａは、統合後のメディアセグメント＃ａｓ１を記憶部２５０に保存する。

再生部２２０は、記憶部２５０に保存された録画再生用の制御情報と録画再生用のメディアセグメントとを使って録画後の映像を再生する。

配信システムは、配信装置１００ａがセグメントの生成を完了するたびに、以上の処理を繰り返すことで、記憶部２５０内に録画再生用の制御情報と録画再生用のメディアセグメント群とを保存することになる。

そして、再生装置２００ａは、対象番組の録画再生の指示を操作部（図示せず）を介して受け取った場合、まず、記憶部２５０から録画再生用の制御情報を読み出し、録画再生用の制御情報に基づいて、録画再生用のメディアセグメント群を順次読み出して再生することになる。

したがって、本実施形態に係る再生装置２００ａも、実施形態１に係る再生装置２００と同様の効果を奏することになる。

（配信システムの変形例１）
実施形態３に係る配信システムの変形例１について図１２を参照して説明する。図１２は、変形例１に係る配信システムにおいて、配信装置が再生装置に配信する統合前のライブ配信用のメディアセグメント群と、統合後のメディアセグメントと、を模式的に示した図である。

変形例１に係る配信システムは、上述の配信システムとは、セグメント変換情報付加部、セグメント変換情報解析部、制御情報変換部、セグメント変換部および再生部の動作が異なっている。

変形例１に係る配信システムでは、セグメント変換情報付加部は、各メディアセグメントに連続番号であるseq_numを付与する。セグメント変換情報付加部は、一緒に統合される連続する一群のメディアセグメントについて、先頭のメディアセグメントに値が“１”であるagg_s/e_flagを付与し、末尾のメディアセグメントに値が“２”であるagg_s/e_flagを付与し、その他のメディアセグメントに値が“０”であるagg_s/e_flagを付与する。即ち、agg_s/e_flagは、agg_s/e_flagが添付されたメディアセグメントが、統合される連続する一群のメディアセグメントの先頭あるいは末尾のセグメントであることを示すフラグである。

セグメント変換情報解析部は、供給されたメディアセグメントをセグメント変換部２４０ａに供給する。また、セグメント変換情報解析部は、供給されたメディアセグメントのagg_s/e_flagの値が“０”“１”“２”のいずれであるかを判定する。

通信路経由では、配信されるメディアセグメントが配信装置の配信順に再生装置に到着するとは限らない。そのため、セグメント変換情報解析部は、agg_s/e_flagの値が“１”であるメディアセグメントとagg_s/e_flagの値が“２”であるメディアセグメントとが判定された時点でその間のメディアセグメントがすべて揃っているかをそれらのseq_numの値とagg_s/e_flagの値が“０”のメディアセグメントのseq_numの値とを使って確認する。そして、すべて揃っていると判断された時点で、agg_s/e_flagの値“１”のメディアセグメントとagg_s/e_flagの値“２”のメディアセグメントの各seq_numの値を制御情報変換部およびセグメント変換部に供給する。

制御情報変換部は、供給されたagg_s/e_flagの値“１”のメディアセグメントのseq_numの値を、agg_s/e_flagの値“１”のメディアセグメントから値“２”のメディアセグメントまでのメディアセグメントの個数（即ち、供給されたseq_numの間の個数）で割った商を求め、この商を、統合後のメディアセグメントに関するseg要素のid属性の属性値にすることを決定する。例えば、seq_numの値として“３ｔ”と“３ｔ＋２”とが供給された場合、統合後のメディアセグメントに関するseg要素のid属性の属性値を“ｔ”にすることを決定する。そして、記憶部２５０の制御情報に含まれている上記一群のメディアセグメントに関するseg要素群を、統合後のメディアセグメントに関するseg要素に更新する。

セグメント変換部は、供給された各seq_numの値に基づいて、対応する一群のメディアセグメントを録画再生用の単一のメディアセグメントに統合して記憶部２５０に記録する。例えば、seq_numの値として“３ｔ”と“３ｔ＋２”とが供給された場合、seq_numの値が“３ｔ”、“３ｔ＋１”、“３ｔ＋２”の一群のメディアセグメントを録画再生用の単一のメディアセグメントに統合し、統合後のメディアセグメントのヘッダ部に含まれるseq_numの値を“t”とする。なお、ｔの値は、制御情報変換部と同様の方法で求める。

再生部は、制御情報内のseg要素を上から順に読み出す。そして、seg要素の読み出した順に、seg要素のid属性の属性値に等しい値のseq_numをヘッダ部に含むメディアセグメントを読み出して再生する。

（配信システムの変形例２）
実施形態３に係る配信システムの変形例２について図１３を参照して説明する。図１３は、変形例２に係る配信システムにおいて、配信装置が再生装置に配信する統合前のライブ配信用のメディアセグメント群と、統合後のメディアセグメントと、を模式的に示した図である。

変形例２に係る配信システムは、変形例１に係る配信システムとは、セグメント変換情報付加部、セグメント変換情報解析部、セグメント変換部および制御情報変換部の動作が異なっている。

変形例２に係る配信システムでは、セグメント変換情報付加部は、各メディアセグメントに連続番号であるseq_numを付与する。セグメント変換情報付加部は、一緒に統合される連続する一群のメディアセグメントについて、末尾のメディアセグメントに値が“１”であるagg_en_flagを付与し、その他のメディアセグメントに値が“０”であるagg_en_flagを付与する。即ち、agg_en_flagは、agg_en_flagが添付されたメディアセグメントが、統合される連続する一群のメディアセグメントのうち末尾のセグメントであることを示すフラグである。

セグメント変換情報解析部は、供給されたメディアセグメントをセグメント変換部に供給する。また、セグメント変換情報解析部は、供給されたメディアセグメントのagg_en_flagの値が“０”“１”のいずれであるかを判定する。

変形例１で示したのと同様、通信路経由では、配信されるメディアセグメントが配信装置の配信順に再生装置に到着するとは限らない。本変形例２では、agg_en_flagの値が“１”であると判定した場合に直近で同じく値“１”であると判定したメディアセグメントとseq_numの値を比較し、新しく判定したメディアセグメントが正しく後のseq_numの値となっているかを判定する。次に、その間のメディアセグメントが揃っているかをagg_en_flagの値“０”のメディアセグメントのseq_numの値を使って判断する。そして、揃っていると判断されたら、agg_en_flagの値“１”のメディアセグメントのseq_numの値を制御情報変換部およびセグメント変換部に供給する。

セグメント変換部は、新しくagg_en_flagの値“１”のメディアセグメントのseq_numの値を受け取ると、その値と、既に取得している直前のagg_en_flagの値“１”のメディアセグメントのseq_numの値とを使って、直前のagg_en_flagの値“１”のメディアセグメントの次のメディアセグメントから、新しく受け取ったseq_numの指すagg_en_flagの値“１”のメディアセグメントまでの一群のメディアセグメントを統合する。

制御情報変換部は、新しくagg_en_flagの値“１”のメディアセグメントのseq_numの値を受け取ると、その値と、既に取得している直前のagg_en_flagの値“１”のメディアセグメントのseq_numの値とを使って、直前のagg_en_flagの値“１”のメディアセグメントの次のメディアセグメントから、新しく受け取ったseq_numの指すagg_en_flagの値“１”のメディアセグメントまでの一群のメディアセグメントに対応するseg要素を１つのseg要素に統合する。

（配信システムの変形例３）
実施形態３に係る配信システムの変形例３について図１４を参照して説明する。図１４は、変形例３に係る配信システムにおいて、配信装置が再生装置に配信する統合前のライブ配信用のメディアセグメント群と、統合後のメディアセグメントと、を模式的に示した図である。

変形例３に係る配信システムは、変形例１に係る配信システムとは、セグメント変換情報付加部、セグメント変換情報解析部、セグメント変換部および制御情報変換部の動作が異なっている。

変形例３に係る配信システムでは、セグメント変換情報付加部は、各メディアセグメントに連続番号であるseq_numを付与する。セグメント変換情報付加部は、一緒に統合される連続する一群のメディアセグメントについて、先頭のメディアセグメントに値が“１”であるagg_st_flagを付与し、その他のメディアセグメントに値が“０”であるagg_st_flagを付与する。即ち、agg_st_flagは、agg_st_flagが添付されたメディアセグメントが、統合される連続する一群のメディアセグメントのうち先頭のセグメントであることを示すフラグである。

セグメント変換情報解析部は、供給されたメディアセグメントをセグメント変換部に供給する。また、セグメント変換情報解析部は、供給されたメディアセグメントのagg_st_flagの値が“０”“１”のいずれであるかを判定する。

セグメント変換情報解析部は、“１”であると判定した場合、直近で同じく値“１”であると判定したメディアセグメントとseq_numの値を比較し、新しく判定したメディアセグメントが正しく後のseq_numの値となっているかを判定する。次に、その間のメディアセグメントが揃っているかをagg_st_flagの値“０”のメディアセグメントのseq_numの値を使って判断し、揃っていると判断されたら、agg_st_flagの値“１”のメディアセグメントのseq_numの値を制御情報変換部およびセグメント変換部に供給する。

セグメント変換部は、新しくagg_st_flagの値“１”のメディアセグメントのseq_numの値を受け取ると、その値と、既に取得している直前のagg_st_flagの値“１”のメディアセグメントのseq_numの値とを使って、直前のagg_st_flagの値“１”のメディアセグメントから、新しく受け取ったseq_numの指すagg_st_flagの値“１”のメディアセグメントの直前のメディアセグメントまでの一群のメディアセグメントを統合する。

制御情報変換部は、新しくagg_st_flagの値“１”のメディアセグメントのseq_numの値を受け取ると、その値と、既に取得している直前のagg_st_flagの値“１”のメディアセグメントのseq_numの値とを使って、直前のagg_st_flagの値“１”のメディアセグメントから、新しく受け取ったseq_numの指すagg_st_flagの値“１”のメディアセグメントの直前のメディアセグメントまでの一群のメディアセグメントに対応するseg要素を１つのseg要素に統合する。

（配信システムの変形例４）
変形例２のagg_en_flagを、統合する残りのメディアセグメント数を示す属性値agg_rest_numに置き換えても、同様の処理が可能である。図１５にメディアセグメントの例を示す。agg_rest_num＝“0”がagg_en_frag=“1”と実質的に等価となる。

なお、制御情報変換部２３０ａまたは変形例１〜４の各制御情報変換部は、ライブ配信用の制御情報を、ライブ配信および録画再生兼用の制御情報に変換してもよい。

例えば、図７の制御情報４ｂを図１６（ａ）の制御情報５ｆに更新してもよいし、図１６（ｂ）の制御情報５ｇに更新してもよい。制御情報５ｆにおけるseg要素のprofile属性は、その属性値が“onDemand”である場合には録画再生時にだけそのseg要素を参照すべきであることを示し、その属性値が“Live”である場合にはライブ再生時にだけそのseg要素を参照すべきであることを示している。なお、制御情報５ｆにおいて属性値が“Live”であるprofile属性は省略してもよいが、この場合、再生部は、profile属性が含まれていないseg要素はライブ再生時にだけ参照することになる。

また、制御情報５ｇは、Control要素に、下位のseg要素のprofile属性がとり得る値を規定するprofile属性が記述された例を示している。Control要素のprofile属性の属性値が“Live onDemand”の２値である場合、seg要素のprofile属性は、その属性値が“１”である場合には“onDemand”を表し、録画再生時にだけそのseg要素を参照すべきであることを示す。一方、その属性値が“０”である場合には“Live”を表し、ライブ再生時にだけそのseg要素を参照すべきであることを示す。なお、制御情報５ｇにおいて属性値が“０”であるprofile属性は省略してもよいが、この場合、再生部は、profile属性が含まれていないseg要素はライブ再生時にだけ参照することになる。

無論、図１６に示した制御情報は実施形態１あるいは実施形態２においても利用可能である。

（付記事項１）
実施形態１のステップＳ８およびステップＳ９におけるＮの値は、配信装置１００において予め定められていてもよいし、配信装置１００を用いる番組提供者が操作部（図示せず）を介して入力した値に基づく値であってもよい。すなわち、属性agg_seg_durの属性値である「３０s」や属性agg_seg_numの属性値である「３」等の値は、配信装置１００において予め定められていてもよいし、配信装置１００を用いる番組提供者が操作部（図示せず）を介して入力した値であってもよい。無論、「３０s」や「３」等の値は一例であり、これに限らない。

実施形態１における“ａｓ１”“ａｓ２”等の値は、配信装置１００または再生装置２００で予め決められた規則に従って付与される値であってもよい。

実施形態１の変形例３において、制御情報更新部１２０が連続した何個のseg要素に同一値の変数aggを付加するかは、配信装置１００において予め定められていてもよいし、配信装置１００を用いる番組提供者が操作部（図示せず）を介して入力した値に基づく値であってもよい。さらに、個数は固定ではなく、統合するメディアセグメント毎に異なる個数をとるようにしてもよい。この場合には、実施形態１のステップＳ８およびステップＳ９におけるＮの値も統合するメディアセグメント毎に異なることになる。

実施形態３において、セグメント変換情報付加部１６０が、連続した何個のメディアセグメントに同一値の変数aggを付加するかは、配信装置１００ａにおいて予め定められていてもよいし、配信装置１００ａを用いる番組提供者が操作部（図示せず）を介して入力した値に基づく値であってもよい。さらに、個数は固定ではなく、統合するメディアセグメント毎に異なる個数をとるようにしてもよい。

また、各メディアセグメントのidの値は連続番号ではなく、メディアセグメントの生成を開始または完了した時刻を示す時刻値であってもよい。また、映像のタイトルと連続番号とを連結(concatenate)させた複合型の値をとることも可能である。

実施形態３の変形例２、３において、agg_en_flag、agg_st_flagは“０”、“１”の値をとるフラグでなく、それ自体を、統合するセグメントのうち末尾のセグメント、統合するセグメントのうち先頭のセグメントを示す識別子とすることも可能である。すなわち、agg_en_flagが付されたメディアセグメントは統合するセグメントの末尾のセグメントであることを表し、その他のメディアセグメントには識別子agg_en_flagが付されない、といった構成としてもよい。

（付記事項２）
実施形態１のステップＳ８およびステップＳ９におけるＮの値は、統合後の各メディアセグメントの先頭位置がランダムアクセスポイントとなるような値であることが望ましい。

すなわち、例えば、ライブ配信用のメディアセグメントの長さが１０秒であって、２５秒ごとにランダムアクセスポイントが配置されている番組コンテンツを配信する場合、配信装置１００の制御情報更新部１２０は、属性値が“５”（２５と１０の最小公倍数を１０で割った商）である属性agg_seg_numを記憶部１１０の制御情報に付加することで、制御情報を更新してもよい。

この場合、図１７に示したように、再生装置２００は、ライブ配信用のメディアセグメントＳを５個受信するたびに、その５個のメディアセグメントＳを録画再生用の単一のメディアセグメントＡＳに統合することになる。そして、図１７に示したように、録画再生用の各メディアセグメントＡＳの先頭位置はランダムアクセスポイント（図中における「ＲＡＰ」）になる。

あるいは、ランダムアクセスポイント（RAP）がセグメントの先頭位置にあるかをセグメントの情報を使って判定し、先頭位置にRAPのある長さ小のセグメントを起点として長さ大のセグメントを形成する、といった変換を行うことも可能である。即ち、先頭位置にRAPのある長さ小のセグメントから、先頭位置にRAPのある次の長さ小のセグメントの直前のセグメントまでを統合し、長さ大のセグメントを形成する。この場合、長さ小の各セグメントのヘッダに、RAPの有無あるいはRAPの位置を示した情報が付加されているものとし、これを用いて、単一のメディアセグメントに統合すべき一群のコンポーネントを特定するものとしてもよい。即ち、このRAPの有無あるいはRAPの位置を示した情報を、セグメント変換用情報として用いることができる。

コンテンツデータ（メディアセグメント）中のランダムアクセス可能な位置はコンテンツ生成者が知るため、ランダムアクセス位置から始まる長さ大のメディアセグメントの設定などは提供者側、即ち配信装置から送る方が適している。配信装置から必要な情報を送ることにより、再生装置あるいは２次配信装置で特別な解析を行うことなく、メディアセグメントの統合が可能となる。

また、長さ小の複数セグメントをまとめて長さ大の１つのセグメントが構成できるように提供者側が予め小セグメントを分割している場合がある。この場合にも、必要最小限の変換情報を通知することで容易に変換が可能となる。

（付記事項３）
配信装置１００および１次配信装置１００’にセグメント変換部および制御情報変換部を備えてもよい。すなわち、番組コンテンツのライブ配信中、セグメント変換部は、配信制御部がライブ配信用のメディアセグメントをＮ個配信するたびに、そのＮ個のメディアセグメントを単一のメディアセグメントに統合して記憶部１１０に記録してもよい。そして、制御情報変換部は、番組コンテンツのライブ配信中、制御情報更新部による更新後の制御情報を録画再生用の制御情報に変換してもよい。

即ち、これは、実施形態２における２次配信装置３００の機能を、１次配信装置１００’が兼ねるといった構成にあたり、配信装置１００および１次配信装置１００’が、さかのぼって再生済のシーンをタイムシフト配信およびタイムシフト再生するなど特殊再生可能なサービスを提供することを想定した構成であると言える。配信済のシーンをさかのぼってタイムシフト配信するためには、ランダムアクセス可能な長さ大のメディアセグメントへの変換をプロバイダサーバ（配信装置１００および１次配信装置１００’）が行い、それらを保持しておく必要があるからである。

配信装置１００および１次配信装置１００’にセグメント変換部および制御情報変換部を備える構成についてより具体的に説明すると以下の通りである。

セグメント変換部は、メディアセグメントを配信するたびに、そのメディアセグメントを記憶部１１０に記録する。そして、セグメント変換部は、メディアセグメントをＮ個記憶部１１０に記録するたびに、直近で記憶部１１０に記録されたそのＮ個のメディアセグメントを記憶部１１０から読み出して、単一のメディアセグメントに統合する。これにより、セグメント変換部は、記憶部１１０のＮ個のメディアセグメントを単一のメディアセグメントに更新する。

例えば、Ｎの値が５であって、配信制御部が最初の３つのメディアセグメントＳを配信した時点では、図１８に示すように、記憶部１１０にはライブ配信用のメディアセグメントＳが３つ保存される。

その後、配信制御部が５つ目のライブ配信用のメディアセグメントＳを配信した時点で、記憶部１１０に保存されている最初の５つのメディアセグメントＳは録画配信用の単一のメディアセグメントＡＳに更新される。なお、更新が完了した時点で、記憶部１１０に保存されていた５つのメディアセグメントＳは記憶部１１０から削除される（図中点線の矩形が削除されたメディアセグメントＳに該当する）。

さらに、配信制御部が８つ目のライブ配信用のメディアセグメントＳを配信した時点で、記憶部１１０には、録画再生用のメディアセグメントＡＳが１つ、ライブ配信用のメディアセグメントＳが（６つ目〜８つ目のメディアセグメント）３つ保存される。

さらにその後、配信制御部が１０個目のライブ配信用のメディアセグメントＳを配信した時点で、記憶部１１０の６つ目〜１０個目の５つのメディアセグメントＳは録画配信用の単一のメディアセグメントＡＳに更新され、記憶部１１０には録画配信用のメディアセグメントＡＳが２つ保存されることになる。更新が完了した時点で、６つ目〜１０個目の５つのメディアセグメントＳは記憶部１１０から削除される。

その結果、ライブ配信の終了時点で記憶部１１０には、コンテンツを構成する録画配信用の全メディアセグメントが保存されていることになる。

したがって、配信装置１００および１次配信装置１００’は、記憶部１１０の記憶領域を無駄に消費することなく、過去にライブ配信したコンテンツを録画配信することができる。

なお、配信装置は、セグメントの変換と共に制御情報変換部で制御情報を更新し配信するが、既に配信された過去の制御情報を使ってリクエストする再生装置のために、一定期間、ライブ配信用のメディアセグメントと録画配信用のメディアセグメントを配信装置内に共存させておくといった仕様も可能である。このような仕様は、制御情報の更新が定期的にしか行われないような場合に特に有用である。また、配信の途中では、制御情報にライブ配信用のメディアセグメントと録画配信用のメディアセグメントの情報が混在するため、制御情報に記述されたメディアセグメントが録画配信用に統合された後のメディアセグメントであることを示す属性情報（例えばaggregated属性）あるいは識別子をメディアセグメントの記述（seg要素）に追加することも可能である。これは統合前のメディアセグメントにagg属性が付加されていることと実質的には同じだが、以下のように実現される機能が異なるため、特に別記する。即ち、この属性情報あるいは識別子は、過去の制御情報に基づくライブ配信用のメディアセグメント群を統合した録画配信用のメディアセグメントが配信装置に存在していることを示し、再生装置は、過去の制御情報を使って（過去の制御情報を保持）、統合前のライブ配信用メディアセグメント群をリクエストしてもよいし、更新された制御情報を使って（過去の制御情報を破棄）、統合後の録画配信用のメディアセグメントをリクエストしてもよい。本処理は、例えば、配信済みのメディアセグメントのタイムシフト再生を行う際に適用することができる。

また、制御情報に上記属性情報あるいは識別子を記述することに加えて、統合が行われた際に送信中のＨＴＴＰレスポンスメッセージのヘッダ部に、統合が行われたことを示す情報を付加してもよい。例えば、Content-Typeヘッダにおけるメディアタイプのパラメータとして付加することが可能である。これにより、再生装置は、更新された制御情報の取得前に、統合が行われたことをタイムリーに知ることができる。

（付記事項４）
ライブ配信用の各メディアセグメントのデータ構造、および、各メディアセグメントを統合した録画再生用のメディアセグメントのデータ構造について簡単に触れておく。

図１９は、これらのメディアセグメントのデータ構造を模式的に示した図である。

図１９に示したように、ライブ再生用のメディアセグメントも録画再生用のメディアセグメントも、ヘッダ部（符号ｆ１、ｍ１、ｓ１等で示された部分）とメディアデータ部（符号ｍｄ１、ｍｄ２、ｍｄ３等で示された部分）とで構成されている。

符号ｆ１〜ｆ３、ｆ６で示されるftyp(File Type Box)はセグメントファイルの種別やバージョン情報等を含んでいる。また、符号ｍ１〜ｍ３、ｍ６で示されるmoov（Movie Box）は、セグメントの基準時刻やトラックの情報等を含んでいる。さらに、符号ｓ１〜ｓ３、ｓ６で示されるsidx（Segment Index Box）は、ランダムアクセスポイントに関する情報を含んでいる。

また、moof（Movie Fragment Box）は、メディアセグメントを構成するムービーフラグメントに関するメタ情報を含んでおり、mdat（Media Data Box）は、メディアセグメントを構成するムービーフラグメントの映像データを含んでいる。

次に、ライブ配信用の連続する一群のメディアセグメントを録画再生用の単一のメディアセグメントに統合する統合処理について以下により具体的に説明する。

セグメント変換部は、ヘッダ部については、各録画再生用のメディアセグメントのftyp（ｆ１〜ｆ３）を削除し、録画再生用のメディアセグメントのftyp（ｆ６）を生成して添付する。また、各メディアセグメントのmoov（ｍ１〜ｍ３）の内容を統合したmoov（m６）を形成し、録画再生用のメディアセグメントのmoovとする。同様に、各メディアセグメントのsidx（ｓ１〜ｓ３）の内容を統合したsidx（ｓ６）を形成し、録画再生用のメディアセグメントのsidxとする。

一方、セグメント変換部は、配信された一群のメディアセグメントのmoofおよびmdatの対を配信された順に先頭から並べることで、録画再生用のメディアセグメントのメディアデータ部を生成する。

上記の処理により、セグメント変換部は、例えば、図１９の矢印の上方に模式的に示した３つのメディアセグメントを図１９の矢印の下方に模式的に示した単一のメディアセグメントに統合することになる。すなわち、セグメント変換部は、最初に配信されたメディアセグメントのメディアデータ部の内容ｍｄ１が先頭に配置され、最後に配信されたメディアセグメントのメディアデータ部の内容ｍｄ３が末尾に配置され、２番目に配信されたメディアセグメントのメディアデータ部の内容ｍｄ３が先頭と末尾との間に配置されるようなメディアデータ部を生成することになる。

なお、セグメント変換部は、供給された各メディアセグメントのsidxを参照し、ランダムアクセスポイントが先頭位置にあることを示すsidxを含むライブ配信用のメディアセグメントから同様のメディアセグメントが次に供給されるまでの間のメディアセグメントを統合することが望ましい。

（付記事項５）
本発明は、実施形態２に係る配信システムの特徴部分と実施形態３に係る配信システムの特徴部分とを組み合わせた形態で実施できる。例えば、本発明は、図２０に示したような１次配信装置１００ｂ、２次配信装置（プロキシサーバ）３００ａおよび再生装置２００’を含む配信システムとして実現できる。

すなわち、１次配信装置１００ｂは、実施形態２に係る１次配信装置１００’と同様に、ライブカメラの番組映像を２次配信装置３００ａに配信し、２次配信装置３００ａは、実施形態２に係る２次配信装置３００と同様に、ライブカメラの番組映像を、ライブ配信の要求を１次配信装置１００ｂに送信した再生装置２００’に向けてライブ配信する。また、２次配信装置３００ａは、実施形態２に係る２次配信装置３００と同様に、ライブカメラの番組映像をＶＯＤ配信に適した記録方式で記録し、ＶＯＤ配信の要求を出した再生装置に向けて番組映像をＶＯＤ配信する。

そして、１次配信装置１００ｂでは、実施形態３に係る配信装置１００ａと同様に、セグメント変換情報付加部１６０が、セグメント変換情報をメディアセグメントのヘッダ部に付加する。

この配信システムについての詳細な説明は省略することにする。図２０を見るとわかるように、１次配信装置１００ｂ、２次配信装置３００ａおよび再生装置２００’を構成する各部については実施形態１〜３のいずれかで説明しているので、当業者であれば、詳細な説明がなくともこの配信システムの構成を理解できるであろう。

また、実施形態１〜３の説明に接した当業者であれば、この配信システムの動作も自ずと理解できるであろう。なお、制御情報変換部３２０ａおよびセグメント変換部３３０ａは、それぞれ、制御情報変換部２３０ａおよびセグメント変換部２４０ａと同一であることを付け加えておく。

なお、セグメント変換情報付加部１６０を、実施形態３で説明した変形例１に係る配信装置のセグメント変換情報付加部に置き換えるとともに、制御情報変換部３２０ａ、セグメント変換情報解析部３２５、セグメント変換部３３０ａおよび再生部２２０を、それぞれ、変形例１に係る再生装置の制御情報変換部、セグメント変換情報解析部、セグメント変換部および再生部に置き換えても良い。実施形態３で説明した変形例２〜４についても同様である。

（付記事項６）
本発明の各実施形態では、単一のメディアセグメントに変換する一群のメディアセグメントを再生装置あるいは２次配信装置が取得完了した時点で、セグメントの変換処理及び制御情報の変換処理を行うものとしていた。これと異なり、統合処理のタイミングを示す情報を別途得ることで、セグメントの変換処理及び制御情報の変換処理を行ってもよい。一群のメディアセグメントの受信を完了し次第統合するのでなく、統合のタイミングを別途指示する実施の形態は、受信後もライブ配信用にある程度の期間、長さ小のメディアセグメントを保持しておくといった用途を想定するものである。

セグメント変換部２４０が、ライブ配信用の一群のセグメントを録画再生用の単一のメディアセグメントに統合する統合処理のタイミングとしては、以下のタイミングが考えられる。

例えば、配信制御部１３０は、セグメント変換部２４０に変換のタイミングを指示するコマンドを、定期的に（例えば、３０秒毎に）、または、ライブ配信用の全メディアセグメントを配信し終えた後に再生装置２００に送信し、セグメント変換部２４０は、再生装置２００がコマンドを受信したタイミングで統合処理を行ってもよい。

また、記憶部１１０のライブ配信用の制御情報に、統合処理を行うタイミングを示す時刻情報が記録されていてもよく、セグメント変換部２４０は、供給された制御情報内に記録されている時刻情報に応じたタイミングで統合処理を行ってもよい。

また、セグメント変換情報付加部１６０は、規定のタイミング毎に、セグメント生成部１５０から供給されるメディアセグメントのヘッダ部またはメタデータボックスの中に、統合処理を行うべき旨を示す情報を付加してもよい。そして、セグメント変換部２４０は、そのような情報を含むメディアセグメントが供給されたタイミングで統合処理を行っても良い。

セグメント変換情報付加部１６０は実施形態３の図１０、付記事項５の図２０にしか示されていないが、実施形態１の図１のセグメント生成部１５０、実施形態２の図９のセグメント生成部１５０がメディアセグメントを生成時に、メディアセグメントのヘッダ部またはメタデータボックスに統合処理を行うべき旨を示す情報を付加してもよい。

具体的には、セグメント変換情報付加部１６０あるいはセグメント生成部１５０は、セグメント変換用情報を通知する専用のメタデータボックスSegment Aggregation Box（このボックスはメディアセグメントのヘッダ部に置かれる）を生成するとし、これに、実施形態３の配信システムの例および変形例１〜４で示したagg、seq_num、agg_s/e_frag、agg_en_frag、agg_st_frag、agg_rest_numのいずれか利用するものを記載するものとする。これと合せて、Segment Aggregation Boxに、統合処理を指示するトリガフラグagg triggerを記載する。

セグメント変換部２４０は、供給されたメディアセグメントのヘッダ部のagg triggerの値が“0”であればまだ統合処理をせずにそのメディアセグメントを記憶部に記録する。一方、ヘッダ部のagg triggerの値が“1”であればその時点で未だ統合処理の対象となっていない記憶部のメディアセグメント群の統合処理を実行する。

また、agg trigger自体を識別子としてもよい。セグメント変換部２４０は、供給されたメディアセグメントのヘッダ部にagg triggerが無ければまだ統合処理をせずにそのメディアセグメントを記憶部に記録してもよい。そして、供給されたメディアセグメントのヘッダ部にagg triggerが付いていた時点で未だ統合処理の対象となっていない記憶部のメディアセグメント群の統合処理を実行してもよい。

さらに、既に説明している通り、前述のagg_en_frag、agg_st_fragは統合するメディアセグメントの末尾のメディアセグメント、先頭のメディアセグメントを示す情報であり、これ自体が統合処理の実行を指示するフラグとして扱ってもよい。即ち、agg_en_frag=“1”は受け取ったメディアセグメントまでを統合することを指示する情報であると解釈できるし、agg_st_frag=“1”は受け取ったメディアフラグメントの直前のメディアフラグメントまでを統合することを指示する情報であると解釈できる。

Segment Aggregation Boxは、図１９のftyp、moov、sidxボックスなどと並列にセグメントのヘッダ部に置かれる専用のメタデータボックスである。Segment Aggregation Boxは例えばsegaボックスなどとして図示される。このような専用のメタデータボックスを使わず、統合処理を行うべき旨を示す情報を既存のボックスに加えて通知する構成も可能である。例えば、既存のftypボックスのcompatible_brands要素（４バイトのリスト）のとり得る値として、統合処理を指示する値‘sagg’を設定してもよい。

この場合、セグメント変換部２４０は、供給されたメディアセグメントのftypボックスのcompatible_brands要素に値‘sagg’がない場合にはまだ統合処理をせずにそのメディアセグメントを記憶部に記録してもよい。そして、供給されたメディアセグメントのftypボックスのcompatible_brands要素に値‘sagg’がある場合には、未だ統合処理の対象となっていない記憶部のメディアセグメント群の統合処理を実行してもよい。

また、例えば本発明をＭＰＥＧ―ＤＡＳＨに適用する場合、配信制御部１３０は、メディアセグメント（またはその一部であるムービーフラグメント）を含むHTTPレスポンスメッセージを繰り返し生成して配信することになる。この場合、配信制御部１３０は、規定のタイミング毎に、統合処理を行うべき旨を示す情報（統合処理のタイミング情報）をHTTPレスポンスメッセージのヘッダ部に付加し、統合処理のタイミング情報を含むＨＴＴＰレスポンスメッセージを配信してもよい。そして、セグメント変換部２４０は、再生装置がそのようなタイミング情報を含むＨＴＴＰデータを受信したタイミングで統合処理を行っても良い。

また、ＨＴＴＰレスポンスメッセージが個々のメディアセグメントを格納したものであることから、実施形態３ではセグメント変換情報付加部がメディアセグメントのヘッダ部に付加したセグメント変換用情報を、配信制御部がメディアセグメントのヘッダ部でなくＨＴＴＰレスポンスメッセージのヘッダ部に付加することも可能である。例えば、配信制御部は、Content-Typeヘッダにおけるメディアタイプのパラメータとしてセグメント変換用情報を付加することが可能である。ＨＴＴＰレスポンスメッセージのヘッダ部にセグメント変換情報を付加して配信する配信装置も、実施形態３に係る配信システムの配信装置１００ａと同一の効果を奏する。

なお、ここまでの説明では、統合処理のタイミングを示した情報を、独立したコマンド、ライブ配信用の制御情報、メディアセグメントのヘッダ部またはメタデータボックス、ＨＴＴＰレスポンスメッセージのヘッダ部、のいずれかに記録し通知するとした。

ところで、番組映像を取得・再生するための制御情報は、配信の開始時に、あるいは配信の間に定期的に取得する情報であり、高々数回しか配信されないのに対し、配信されるメディアセグメントの数は一般に大きい。このため、メディアセグメントのヘッダ部（またはメタデータボックス）を常に監視し、統合処理実行の通知の有無を常に判断することは、受信時の再生装置の処理負荷となる。特に、配信サービスによって予め、配信期間毎に、あるいはメディアセグメント毎に、メディアセグメントによる統合処理実行の通知を行わないことが明らかであるような場合、上記の判断処理は不要となる。

このような非効率な処理が発生する状況を回避する手段として、制御情報に記述された配信期間毎に、あるいはメディアセグメント毎に、メディアセグメントが統合処理実行の通知の記述を備えるか否か（この記述によって統合処理の実行の有無を判断可能か）、を示した識別子を制御情報に記述し、この識別子により一部の判断処理を省略可能としてもよい。即ち、制御情報に記述されたこの識別子でメディアセグメントに統合処理実行の通知の記述が備わることが示された場合のみ、メディアセグメントのヘッダ部あるいはメタデータボックスから統合処理実行の通知の記述を読み出す。こうすることで、配信全体の処理効率を向上することができる。

図２１に上記識別子を含む制御情報の例を示す。図２１中、“inband_event_signal=“aggregate””が、統合処理実行の通知の記述がメディアセグメントにあることを示す識別子である。図２１（ａ）は制御情報全体に対してメディアセグメントに（即ちセグメントｓ１〜ｓ６の全てに）統合処理実行の通知の記述があることを示した例、図２１（ｂ）は階層的に書かれたメディアセグメントのグループに対してグループに属するメディアセグメントに（即ちセグメントｓ１〜ｓ３に）統合処理実行の通知の記述があることを示した例、図２１（ｃ）は個々のメディアセグメントに対してメディアセグメントに（即ちセグメントｓ２、ｓ３に）統合処理実行の通知の記述があることを示した例である。

また、再生装置あるいは２次配信装置、即ち受信側装置がセグメントの変換処理を行うのでなく、付記事項３に示したように、配信装置あるいは１次配信装置、即ち配信側装置がセグメントの変換処理を行う実施形態であるとき、上記で説明したメディアセグメントのヘッダ部あるいはメタデータボックスに格納される統合処理実行の通知の記述、及び通知の記述の存在を示す制御情報に含める上記識別子を、配信側装置で統合処理が実行されたことを実行のタイミングで受信側装置に伝えるための通知、及びその通知の記述をメディアセグメントが備えるか否かを示す識別子、として実施することも可能である。

なお、付記事項３で同じく既に説明した通り、配信装置あるいは１次配信装置、即ち配信側装置がセグメントの変換処理及び制御情報の変換処理を行い配信する、といった実施形態は、配信・再生済のシーンをさかのぼってタイムシフト配信およびタイムシフト再生させるなど、特殊再生サービスを受信側装置に提供することを目的としたものである。このことから、特殊再生のサービスを利用しない再生装置あるいは２次配信装置、即ち受信側装置では、配信側装置から上記の通知を受け取っても自身の制御情報を更新しない、といった選択を可能としてもよい。これにより、一部の特殊再生サービスを利用しない受信側装置は制御情報の更新処理を省略でき、結果として、特殊再生サービスを利用しない受信側装置は、特殊再生サービスを利用する受信側装置と異なる制御情報を保持することとなる。

配信側装置からみた場合、このような受信側装置で保持される制御情報の食い違いは管理可能であることが望ましい。即ち、上記した特殊再生サービスを付加するための制御情報の更新であれば、受信側装置が更新するか否かを自由に選択可能である（受信側装置での取捨選択を許す）とする。一方、通信環境の変化等により現在の配信装置を別の装置に切り替える（配信元サーバのアドレスを変更する）ための制御情報の更新では、全ての受信側装置に等しく制御情報の更新を行わせる必要がある。この場合、配信側装置は受信側装置の制御情報が更新されたことを前提に以降の配信を行うものであり、制御情報を更新しなかった受信側装置は継続してメディアセグメントの受信を行うことができなくなる。このため、上記通知を行う配信側装置は、上記通知と共に、受信側装置で制御情報の更新をしないことを許すか否かを示す情報を配信する構成としてもよい。

図２２は、セグメント変換用情報を通知するメタデータボックスSegment Aggregation Boxに、上記受信側装置での制御情報の更新不実行を許すか否かを示す識別子を入れた記述例である。図２２中、“essentiality”がその識別子にあたる。“essentiality”は０、１の２値（true、falseの２値）をとり得るものとし、０（false）は更新不実行を許可、１（true）は更新不実行を禁止する（即ち受信側装置での更新を必須とする）ことを表す。無論、セグメント統合を含む様々なイベントを通知する汎用のメタデータボックスEvent Message Boxを定義し、Event Message Boxが上記の識別子“essentiality”を備えるとしてもよい。

図２２中、“type”は、このメタデータボックスの種別、即ちこのメタデータボックスが通知する通知情報の種別を表す。Segment Aggregation Boxの場合には、例えば、実施形態３で示したagg、seq_num、agg_s/e_frag、agg_en_frag、agg_st_frag、agg_rest_numのいずれが格納されているかが配信形式の種別として記載される。あるいは、タイムシフト専用、タイムシフト＋トリック再生用、といった用途を示す情報が文字情報として記載されてもよい。また、“type”の取り得る値を予め定義し、1、2、3といった数値インデックスとして記載することも可能である。

更に、汎用のメタデータボックスEvent Message Boxを考慮すれば、“type”には、“Segment Concatenation”（セグメント統合）、“Server Change”（サーバ切替え）、といった情報が文字情報あるいは数値インデックスとして記載される。

“data[]”は、このメタデータボックスで伝送される各種の通知情報を実際に格納するためのデータフィールドである。“data[]”のデータ形式は“type”の値によって一意に決定される。例えば、SegmentAggregationBoxの場合には、実施形態３及び付記事項６で説明した各種のセグメント変換用情報がこのフィールドに記載される。また、付記事項６で示したトリガフラグagg triggerもこのフィールドに記載される。

なお、通知する内容によって制御情報を更新しないことを許可するか否かが一意に決定される場合に、通知内容の種別を表す情報が通知に含まれて、上記許可の情報を兼ねるとしてもよい。即ち、図２２の場合、メタデータボックスが“essentiality”を備えず、“type”が制御情報の更新不実行の許可情報を兼ねるとしてもよい。

また更に、上記の通知を、一部の受信側装置のみが受けられる付加価値サービスとして提供することも想定される。この場合、上記セグメント統合の通知（配信側でセグメントの統合処理が実行されたことを伝える通知）は、特定の受信側装置にのみ向けて発行されるものであってもよい。即ち、一部の付加価値サービスを受けられる受信側装置、それを扱うユーザのみが通知を受け取り、対応した更新後の制御情報を受け取って付加価値サービスを享受する。この場合にも、サービスを利用する受信側装置とサービスを利用しない受信側装置とでは異なる制御情報を保持することとなる。

配信側装置からみた場合、当然、受信側装置で保持される制御情報のこのような食い違いは管理可能とする。即ち、特定のユーザには必ず更新させ、残りのユーザには更新させないといった動作・処理を配信側装置が管理可能とする。このような管理は、受信側装置毎に通知内容を変更する（受け取り不可な受信側装置にはそもそも通知しない）、または、受け取り可能な配信先（受信側装置）の情報を通知の中に記述することによって実現される。後者に関する記述例を図２３に示す。

図２３は、メタデータボックスSegment Aggregation Boxに、この通知を受け取り可能な配信先の情報を記述するとした記述例である。図２３中、“registered_number”、“registered_user_id[]”が上記配信先情報にあたる。“registered_number”には登録されている配信先の登録数が、“registered_user_id[]”には登録された配信先それぞれのユーザID情報（例えば受信機IPアドレス）が（登録数分のリストとして）記載される。無論、イベントを通知する汎用のメタデータボックスEvent Message Boxを定義し、Event Message Boxが“registered_number”、“registered_user_id[]”を備えるとしてもよい。なお、“type”、“data[]”、“essentiality”などについては、図２２で行った説明と同様の説明が図２３にも当てはまる。

また、セグメントそれぞれがイベント通知用のメタデータボックスを備えるのでなく、各セグメントのメタデータボックスをまとめたイベント通知用のデータストリームを別途規定し、セグメントと別に（例えばセグメントのメディアストリームと多重化して）配信する、といった実施形態も想定可能である。この場合に、イベント通知用データストリームがヘッダ部に上記許可情報“essentiality”、配信先情報“registered_number”、“registered_user_id[]”を備えて、これら情報がデータストリームに含まれる通知イベントのそれぞれに対して適用されるといった構成も可能である。

また、図２１で説明した、メディアセグメントにイベント（図２１の場合は統合処理実行）の通知が含まれるか否かを示す識別子を記述した制御情報に、上記許可情報“essentiality”を記述し、各セグメントのメタデータボックスに記述された許可情報“essentiality”と組み合わせて利用することも可能である。あるいは、同じく制御情報に上記許可情報“essentiality”及び配信先情報“registered_number”、“registered_user_id[]”を記述し、各セグメントのメタデータボックスに記述されたそれらと組み合わせて利用することも可能である。

図２４は、図２１（ｂ）に許可情報“essentiality”を加えた記述例である。

図２４では、メディアセグメントのグループａｓ１に対して“essentiality=“１””、即ちイベントの不実行禁止（図２４の場合は統合処理の不実行禁止）が明示されている。この場合、セグメントグループａｓ１に含まれる全てのセグメントｓ１、ｓ２、ｓ３に対してイベントの不実行禁止と解釈される。従って各セグメントｓ１、ｓ２、ｓ３のメディアセグメントデータのメタデータボックスに“essentiality”を記述する必要は無い（あるいは記述は無視される）。

メディアセグメントのグループａｓ１に対して“essentiality=“０””と明示された場合、セグメントグループａｓ１に含まれる全てのセグメントｓ１、ｓ２、ｓ３に対してイベントの不実行許可がデフォルト値と解釈される。各セグメントｓ１、ｓ２、ｓ３のメディアセグメントデータのメタデータボックスに“essentiality”の記述が無ければ、それぞれはデフォルト値、即ちイベントの不実行許可と解釈される。一方、メディアセグメントｓ３のメタデータボックスにのみ“essentiality”の記述（“essentiality=“１””の記述）があれば、セグメントｓ３のイベントのみ不実行禁止と解釈される。

このように、制御情報に記述された許可情報“essentiality=“１””が優先されるため、通知するイベントを適当な種別に分け、不実行禁止のイベントについては制御情報で一括明記することにより、実行不実行の判定処理が簡略化可能となる。なお、図２４の例にはイベントの種別“inband_event_signal”と許可情報“essentiality”とが一組しか記載されていないが、複数イベントをリスト記述し、それぞれに対して“essentiality”を記述することも可能である。

上記の説明では識別子“essentiality”を０、１の２値としたが、それ以外の多値とすることも可能である。例えば、
０：イベントの不実行許可
１：イベントの不実行禁止、但し端末がイベント未対応であれば不実行許可且つイベント発行元への通知不要
２：イベントの不実行禁止、但し端末がイベント未対応であれば不実行許可且つイベント発行元へ通知要
３：イベントの不実行禁止、且つ端末がイベント未対応等実行不可なら実行停止しイベント発行元へ通知
といった値をとることが可能である。既に説明したように、ここではライブ配信用セグメントから録画再生用セグメントへの変換を通知するイベントの例としている。そして、録画再生用セグメントは特殊再生サービス等に利用される。上記４値の“essentiality”のうち、“essentiality=“０””は、これまでの説明の通り、受信側装置が任意にそのイベントを受け取って特殊再生するか否かを選択可能とすることを示すものである。“essentiality=“１””は、特殊再生に未対応の受信側装置は許容した上で、特殊再生に対応した受信側装置であれば必ずイベントを解釈することを明示したものである。“essentiality=“２””は、同じく特殊再生に未対応の受信側装置を許容した上で、特殊再生に対応した受信側装置であれば必ずイベントを解釈することを明示したものであるが、更に、未対応の受信側装置はイベント発行元への応答を必須とし、発行元で配信状態を把握することを可能とするものである。“essentiality=“３””は、特殊再生に未対応の受信側装置を明示的に禁止するものである。

（付記事項６−１）
制御情報を変換処理した際、変換は制御情報全体に及ぶ場合もあるし、制御情報の一部に限定される場合もある。付記事項３に示した、ライブ配信に合わせて順次メディアセグメント及び制御情報を配信側で変換処理するケースでは、所定数のメディアセグメントＳがライブ配信される都度、制御情報に対して、ライブ配信済メディアセグメントＳの記述の削除と録画配信用メディアセグメントＡＳの記述の追加（即ちメディアセグメントＳからメディアセグメントＡＳへ記述を置換）を行うが、その他の記述内容については変更がない。更に、付記事項３に示した配信側がセグメントと制御情報の変換処理を共に行うケースでは、変換後の制御情報を受信側装置にその都度配信するため、配信時の制御情報のサイズが大きくなるとそのサイズが無視できない。その際、制御情報の記述内容が殆ど変わらないのであれば、記述内容が変わらない制御情報を繰り返し送ることは明らかに冗長であり、データ伝送効率から言っても非効率である。

このため、制御情報の差分をとり、差分情報のみを差分制御情報として送ることが考えられる。

差分制御情報とは、例えば付記事項３の場合、削除するメディアセグメントＳが制御情報の何番目のメディアセグメントであるかを示した位置情報と、削除を示すコマンド“delete”の組合せによって、差分制御情報を構成する。同じく、追加するメディアセグメントＡＳの要素記述情報と、制御情報の何番目のメディアセグメントとして追加するかを示した位置情報、追加を示すコマンド“add”の組合せによって、差分制御情報を構成する。あるいは、何番目から何番目までのメディアセグメントＳを１つのメディアセグメントＡＳに置換するかを示す情報として、メディアセグメントＡＳの要素記述情報、何番目から何番目までといった位置情報、及び置換を示すコマンド“replace”の組合せによって、差分制御情報を構成する。このような記述形式の差分制御情報は、制御情報の構造に依存するため、構造型（“structural”）差分制御情報と呼ぶ。

あるいは、付記事項３の場合に、制御情報を一つの文書と捉え、何行目から何行目までのメディアセグメントＳの記述を削除し、何行目にメディアセグメントＡＳの記述を加える、といった差分制御情報の記述も可能である。このような記述形式の差分制御情報は、文書型（“textual”）差分制御情報と呼ぶ。

また、実施形態１で制御情報に加えたセグメント変換用情報を独立した情報として制御情報と別個に扱えるようにした時、このセグメント変換用情報を（セグメント変換用の情報であると共に）制御情報更新のための差分制御情報と捉えることもできる。実施形態３でメディアセグメントのヘッダ部に加えたセグメント変換用情報、付記事項６でメディアセグメントヘッダ部のメタデータボックスSegment Aggregation Boxに格納されるセグメント変換用情報が、そのような差分制御情報の例である。即ち、セグメントの変換処理を配信側で行うケースであっても、それらを制御情報更新のための差分制御情報として配信側に送ることが想定される。それらは、配信側、受信側で共通に解釈されることによって、制御情報の変換、更新を可能とする。このような記述形式の差分制御情報を、解釈型（“analytic”）差分制御情報と呼ぶ。

付記事項３のケースは本来、配信側装置がメディアセグメントの変換処理と制御情報の変換処理を共に行い、受信側装置は、付記事項６に示した通知（セグメント変換を通知するメディアセグメントのメタデータボックスSegment Aggregation Box）を受け取ったとき、新たに制御情報を要求し、新たな制御情報を受け取り、新たな制御情報で新たにメディアセグメントを要求する。このとき、上記に示したように、配信側装置、受信側装置からなる配信システムが差分制御情報を配信可能なシステムであり、差分制御情報から受信側装置で制御情報を更新可能である場合（元の制御情報と差分制御情報とから新たな制御情報が形成可能である場合）、配信される制御情報が、完全な（“complete”）制御情報か、差分の（“delta”）制御情報か、を示す識別子“isDelta”を通知（セグメント変換を通知するメディアセグメントのメタデータボックスSegment Aggregation Box）に追加し、配信される制御情報を識別する。“isDelta”が０のとき完全（“complete”）であるとし、“isDelta”が１のとき差分（“delta”）であるとする。

差分制御情報は、制御情報の変更部分だけをまとめた小サイズのデータである。このことから、メディアセグメントのヘッダあるいはメタデータボックスで差分制御情報があることを通知し、通知受信後に要求して差分制御情報を得る以外に、差分制御情報自体をヘッダあるいはメタデータボックスに格納しセグメントのデータと共に配信することも想定可能である。その場合、差分制御情報を別途配信する（“exclude”）か、差分制御情報が同梱されている（“include”）かを示した識別子“isInband”をヘッダあるいはメタデータボックスに追加し、差分制御情報が同梱されているか否かを識別する。“isInband”が０のとき別途配信（“exclude”）とし、“isInband”が１のとき同梱配信（“include”）であるとする。

図２５は差分識別子“isDelta”、同梱識別子“isInband”を含むメタデータボックスSegment Aggregation Boxの例である。配信される制御情報は、完全か差分か、同梱か否か、によって以下のようにまとめられる。

isDelta=“0”, isInband=“0”：
完全な(“complete”)制御情報、且つ、セグメント受信後に要求し別途配信（“exclude”）
isDelta=“0”, isInband=“1”：
完全な(“complete”)制御情報、且つ、セグメントデータに同梱し配信（“include”）
isDelta=“1”, isInband=“0”：
差分(“delta”)制御情報、且つ、セグメント受信後に要求し別途配信（“exclude”）
isDelta=“1”, isInband=“1”：
差分(“delta”)制御情報、且つ、セグメントデータに同梱し配信（“include”）

またこのとき、配信される差分制御情報がどの制御情報に対する差分情報であるかを示す情報を添付してもよい。対象の制御情報を示す情報としては、制御情報自身のid情報や、制御情報の配信された時刻を示す配信時刻情報などが利用できる。なお、差分制御情報により更新された制御情報には、差分制御情報の配信時刻が付加されるものとする。

差分制御情報をメディアセグメントのヘッダあるいはメタデータボックスに格納して配信する特殊なケースとして、配信する差分制御情報を更に複数の部分差分制御情報に分割し、複数のメディアセグメントに格納して小分け配信することも考えられる。受信側装置は、複数のメディアセグメントのヘッダあるいはメタデータボックスから得られた複数の部分差分制御情報から差分制御情報を形成し、制御情報を更新する。このとき、差分制御情報を識別する情報、例えばID情報と共に、部分差分制御情報の通し番号と分割数とをヘッダあるいはメタデータボックスに含めて送ることで、受信側装置は差分制御情報の形成、制御情報の更新を可能とする。この時、分割した部分差分制御情報の配信時刻には、元の差分制御情報の配信時刻が付加される。

部分差分制御情報による配信例を図２５を使って説明すると、次のようである。ID情報“id”には分割数を含む値、例えば“ａｂｃｄｅ−５”といった値を記述する。“５”が分割数を表し、このID値は全ての部分差分制御情報に共通に与えられる。そして、同梱識別子“isInband”に通し番号の値、即ち“１”から“５”を記述する。このため、図２５の“isInband”は、０から６３の値を取り得る６ビットの変数としている。つまり、同梱識別子“isInband”は“０”が別送を表し、“１”から“６３”が同梱且つ通し番号を表す識別子である。

なお、制御情報のサイズ自体が大きくないならば、制御情報自体をメディアセグメントのヘッダあるいはメタデータボックスに格納して配信することも可能である。その場合、上記同様に、配信する制御情報を複数の部分制御情報に分割し、複数のセグメントに格納して小分け配信することも当然考えられる。受信側装置は、複数のメディアセグメントから得られた複数の部分制御情報から制御情報を形成する。このとき、制御情報を識別する情報、例えばID情報と共に、部分制御情報の通し番号と分割数とをヘッダあるいはメタデータボックスに含めて送ることで制御情報の形成を可能とするのは、上記と同様である。また同様に、分割した部分制御情報の配信時刻には、元の制御情報の配信時刻が付加されるものとする。

なお、上記したように、複数の異なる差分制御情報の記述形式（“structural”、“textual”、“analytic”）があり、複数の異なる記述形式の差分制御情報が利用可能なシステムであれば、完全か差分かを識別する識別子と共に、差分制御情報の記述形式を示す形式情報を同じく通知するメタデータボックスに追加し、配信される差分制御情報を識別可能としてもよい。無論、完全か差分かを示す識別子といずれの差分形式かを示す形式情報を兼ねる識別情報を規定し上記ボックスに追加してもよい。

これを図２５を使って説明すると次のようである。差分識別子“isDelta”が“０”から“３”の４値をとるものとし、“１”が構造型（“structural”）差分制御情報を、“２”が文書型（“textual”）差分制御情報を、“３”が解釈型（“analytic”）差分制御情報を表すものとする。“０”は完全な（“complete”）制御情報を表す。このため、図２５の“isDelta”は、０から３の値を取り得る２ビットの変数としている。つまり、差分識別子“isDetla”は“０”が完全な制御情報を表し、“１”から“３”が差分制御情報且つその記述形式を表す識別子となる。

なお、制御情報が完全か差分かは、制御情報の種別の１つと捉えることも可能である。即ち、制御情報の種別情報が差分識別子を兼ねることも可能である。同様に、制御情報あるいは差分制御情報がメディアセグメントのヘッダあるいはメタデータボックスに同梱されるか、別途配信かを、制御情報の種別の１つと捉えることも可能である。即ち、制御情報の種別情報が同梱識別子を兼ねることも可能である。言い換えると、制御情報が何のイベントを示すものであるか、完全か差分か、同梱か別送か、を全て識別可能な種別情報を定義し、制御情報に添付して利用することも可能である。

差分制御情報（あるいは制御情報）が同梱されているか否かは、例えばメタデータボックスのサイズを知ることによっても検知可能である。即ち、メタデータボックスのサイズ情報等が同梱識別子を兼ねることも可能である。また、同梱識別子をデータフィールドdata[]に含めて通知するとしてもよい。特に、制御情報が完全か差分かが制御情報の種別情報として通知される場合に、同梱識別子をデータフィールドdata[]に含めて通知するとしてもよい。

付記事項６で説明したのと同様に、差分制御情報を配信する場合にも、制御情報の更新を受信側装置で取捨選択可能とすることが適用可能である。その場合に、メタデータボックスSegment Aggregation Boxに、受信側装置での制御情報の更新不実行を許すか否かを示す識別子“essentiality”を加える。

但し、付記事項６の制御情報全体を受信し更新する場合と異なり、差分制御情報による更新では、更新履歴の管理が必要となる。即ち、受信側装置による更新不実行を許容する場合、差分制御情報の対象となる制御情報が以前に更新を実行した制御情報か、差分制御情報による更新をスキップした制御情報かによって、新たな差分制御情報が処理できない可能性が生じるためである。

これを解決する単純な方法としては、差分制御情報の対象となる制御情報の識別情報をメタデータボックスSegment Aggregation Boxに記述し、受信側装置が既に保持している制御情報がメタデータボックスに記述された識別情報と合致しない場合には制御情報全体を要求しなおす、といった手段がある。制御情報の識別情報としては、id情報あるいは制御情報（差分制御情報）の配信時刻情報が用いられる。このとき、差分制御情報の更新対象となる制御情報が複数可であるなら、それぞれの識別情報をリスト記述する。例えば、０時に最初の制御情報が配信され、１時、２時、３時に差分制御情報が配信されたとき、３時に配信される差分制御情報が、０時の制御情報、０時の制御情報＋１時の差分制御情報から成る制御情報、０時の制御情報＋１時の差分制御情報＋２時の差分制御情報から成る制御情報、に適用可能なら、３時の差分制御情報に添付する識別情報として配信時刻０時、１時、２時をリスト記述する。

但し、上記の例からも容易に想像できるように、上記の例では途中の１時の差分制御情報が抜けた０時の制御情報＋２時の差分制御情報から成る制御情報があったとき、これを管理できない。あるいは識別情報を、組合せを示す、０時、０時＋１時、０時＋１時＋２時、０時＋２時、のように表せば管理可能となるが、これでは全ての組合せを考慮しなければならず、更新の回数（差分制御情報の数）が増えるとおよそ現実的でない。受信側装置でも同じく制御情報の版管理が必要となり、適当でない。

そこで、可能な管理方法としては以下のものがある。

受信側装置は、制御情報の版を、制御情報（差分制御情報）の配信時刻と、過去に受け取った差分制御情報を適用し更新したか否かを示した０、１のレジスタカウンタによって管理する。

完全な制御情報を受け取った時、レジスタカウンタをオール０にリセットする。

差分制御情報を受け取り、差分制御情報を適用し制御情報を更新するか否かを判断後、レジスタカウンタを１段大きい方へシフトする。更新するか否かの判断については後述する。即ち、レジスタ１の値をレジスタ２へ、レジスタ２の値をレジスタ３へシフトする。その後、受け取った差分制御情報を適用して制御情報を更新したならレジスタ１のカウンタを０にセットし、更新しないならレジスタ１のカウンタを１にセットする。

配信側装置は、差分制御情報を送る際、この差分制御情報を適用するために過去に必須な差分制御情報があれば、その差分制御情報に対応した順番位置を１としたマスクを、該当の制御情報の配信時刻と共にメタデータボックスに記述し、受信側装置に送る。即ち、配信時刻Ｔで識別される制御情報について、２個前の差分制御情報が必須であるなら、０１のマスクを送る。

そして、受信側装置は、受け取ったマスクとレジスタカウンタ値の列との論理積をとり、積の値が１であれば必要な差分制御情報が現在の制御情報に含まれていないと判断し、新たに完全な制御情報を要求する構成とする。但し、更新不実行を許すかを示す識別子“essentiality”が立っていなければ、完全な制御情報を要求せず、レジスタに適用不実行を登録して処理を継続可とする。積の値が０であれば、識別子“essentiality”の値に従って更新するか否かを選択し、レジスタに登録の上、処理を継続する。

例えば、配信時刻Ｔで識別される制御情報について、１個前、２個前の差分制御情報が適用されているのであれば、１個目、２個目のレジスタカウンタは００と登録されている。従って、上記０１のマスクとの論理積は０となり、そのまま差分制御情報を適用する。１個前の差分制御情報が適用されず、２個前の差分制御情報が適用されているのであれば、１個目、２個目のレジスタカウンタは１０と登録されている。上記０１のマスクとの論理積は０となり、同じくそのまま差分制御情報を適用する。一方、１個前の差分制御情報が適用され、２個前の差分制御情報が適用されていない場合には、１個目、２個目のレジスタカウンタは０１と登録されている。上記０１のマスクとの論理積は１となり、必要な差分制御情報が適用されていない制御情報であることが判るため、完全な制御情報を要求し直す。

管理可能なレジスタカウンタ数を超えてしまった場合には、完全な制御情報を要求する。こうすることで、制御情報の版が管理可能である。

あるいは、上記の不具合を解消するために、制御情報の管理に一定の制限を加えることで不具合を解消するように構成してもよい。例えば、以下の条件を付加する。途中に抜けがあった場合、後の更新に影響しない場合のみ、新たな差分制御情報の適用を可能とする。上記の場合、０時＋２時でも３時の差分制御情報が適用可能であり、０時＋１時＋２時と０時＋２時の区別が不要な場合に限り、許可するものとする。

なお、差分制御情報を配信する場合、特に、メタデータボックスに差分制御情報を格納してセグメントと同時に配信する場合、差分制御情報には更新される制御情報の要素のみが格納されているため、差分制御情報から制御情報更新の種別を知ることが可能である。このため、メタデータボックスに種別情報“type”を格納する代わりに、差分制御情報の要素情報をみることで更新の実行／不実行を選択することも可能である。即ち、差分制御情報に含まれる更新する要素の種別が、種別情報を兼ねる構成である。

（付記事項７）
上記の各実施形態では、ライブカメラで生成されたライブ配信用の一群のメディアセグメントを録画再生用の単一のメディアセグメントに統合することについて説明した。これとは反対に、録画再生用（蓄積用）の（蓄積効率が高い）メディアセグメントを記録した配信装置、２次配信装置、あるいは再生装置から、遅延（この場合、ＶＯＤ配信要求からの遅延）の少ないＶＯＤ配信を行うために、ＶＯＤ配信を行う各装置を以下のように構成することもできる。すなわち、ＶＯＤ配信を行う各装置を、既に記録されている録画再生用（蓄積用）の単一のメディアセグメントを低遅延ＶＯＤ配信用のより時間長が短い複数のメディアセグメントに時分割するための情報を付加する、といった構成にすることもできる。

具体的には、制御情報更新部は、制御情報内のControl要素に、div_seg_dur属性（時分割後の各セグメントの時間長を示す属性）を付加してもよい。例えば、制御情報内の<Control seg_dur=“30s”>というタグ文字列を<Control seg_dur=“30s”div_seg_dur=“10s”>というタグ文字列に更新してもよい。

セグメント変換部は、更新後の制御情報に基づいて、蓄積用の時間長が長い１つのメディアセグメント（上記の例では時間長が３０秒である１つのメディアセグメント）を、時間長がより短い低遅延ＶＯＤ配信用の複数のメディアセグメント（上記の例では時間長が１０秒である３つのメディアセグメント）に時分割してもよい。

そして、制御情報変換部は、配信装置から送信された制御情報を、時間長がより短い各メディアセグメントに関するseg要素を含むような制御情報に更新してもよい。

（付記事項８）
本実施形態ではいずれも、時間長が短いメディアセグメントをライブ配信用のメディアセグメント、時間長が長いメディアセグメントを録画再生用・ＶＯＤ配信用のメディアセグメントとして、配信装置、２次配信装置、再生装置の機能および動作の説明を行った。しかしながら、時間長と配信用途とが一対一に対応付けられるものでないことは明らかである。例えば、時間長が短いメディアセグメントを極低遅延のライブ配信用メディアセグメントとし、時間長が長いメディアセグメントを、遅延を許容する一般ライブ配信用メディアセグメントと捉えても差し支えない。低遅延ライブ配信用メディアセグメントを一般ライブ配信用メディアセグメントに変換する構成も本願発明の範疇に含まれる。

〔ソフトウェアによる実現例〕
最後に、配信装置、１次配信装置、２次配信装置、再生装置の各ブロック、特に、再生部２２０、制御情報変換部２３０（３２０）、セグメント変換部２４０（３３０）、配信制御部３５０等のブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。

後者の場合、配信装置および再生装置は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである、各配信装置および再生装置の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記各配信装置および再生装置に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。

上記記録媒体としては、一時的でない有形の媒体（non-transitory tangible medium）、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクや ＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスク ＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ（登録商標）／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。

また、上記各配信装置および再生装置を通信ネットワークと接続可能に構成し、上記プログラムコードを、通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

本発明は、コンテンツを配信する配信サーバやコンテンツを再生するプレーヤ、テレビ受信機、ラジオ受信機、ゲーム機等に好適に利用できる。

１００、１００ａ 配信装置
１００’、１００ｂ １次配信装置
１１０ 記憶部
１２０ 制御情報更新部
１３０ 配信制御部
１４０ 送信部
１４０’ 通信部
１５０ セグメント生成部
２００、２００’ 再生装置
２１０ 受信部（取得手段）
２１０’ 通信部
２２０ 再生部（再生手段）
２３０ 制御情報変換部（第２変換手段）
２４０ セグメント変換部（第１変換手段）
２５０ 記憶部
３００、３００ａ ２次配信装置
３１０ 通信部
３２０ 制御情報変換部（第２変換手段）
３３０ セグメント変換部（第１変換手段）
３４０ 記憶部
３５０ 配信制御部（第１配信手段、第２配信手段）

Claims (24)

1. コンテンツが時分割された複数の時分割データを異なる個数の時分割データに変換する第１変換手段と、
   上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信手段と、
   第１のメタデータを、上記異なる個数の時分割データの各々に関する再生用情報が示された第２のメタデータに変換する第２変換手段と、
   第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信手段と、を備え、
   上記第１配信手段は、上記複数の時分割データと共に、上記複数の時分割データを上記異なる個数の時分割データに変換したことを示す通知情報を配信する、ことを特徴とする配信装置。
2. 複数の時分割データに時分割されて配信されるコンテンツを再生する再生装置において、
   複数の時分割データと、上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを取得すると共に、上記複数の時分割データを異なる個数の時分割データに変換したことを示す通知情報を取得する第１取得手段と、
   上記異なる個数の時分割データと、上記異なる個数の時分割データの各々に関する再生用情報が示された第２のメタデータを取得する第２取得手段と、
   上記通知情報を受け取る前には、第１のメタデータに基づき、配信された上記複数の時分割データを再生し、上記通知情報を受け取った後には、第２のメタデータに基づき配信された上記異なる個数の時分割データを再生する再生手段とを備えている、ことを特徴とする再生装置。
3. コンテンツが時分割された複数の時分割データを、異なる個数の時分割データに変換する第１変換工程と、
   上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信工程と、
   第１のメタデータを、上記異なる個数の時分割データの各々に関する再生用情報が示された第２のメタデータに変換する第２変換工程と、
   第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信工程と、を含み、
   上記第１配信工程は、上記複数の時分割データと共に、上記複数の時分割データを上記異なる個数の時分割データに変換したことを示す通知情報を配信する、ことを特徴とする配信方法。
4. 複数の時分割データに時分割されて配信されるコンテンツを再生する再生装置の再生方法において、
   複数の時分割データと、上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを取得すると共に、上記複数の時分割データを異なる個数の時分割データに変換したことを示す通知情報を取得する第１取得工程と、
   上記異なる個数の時分割データと、上記異なる個数の時分割データの各々に関する再生用情報が示された第２のメタデータを取得する第２取得工程と、
   上記通知情報を受け取る前には、第１のメタデータに基づき上記複数の時分割データを再生し、上記通知情報を受け取った後には、第２のメタデータに基づき上記異なる個数の時分割データを再生する再生工程と、を含んでいる、ことを特徴とする再生方法。
5. 複数の時分割データに時分割されて配信されるコンテンツを記録して、再生する再生装置において、
   上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得手段と、
   上記複数の時分割データの全部または一部を、異なる個数の時分割データに変換する第１変換手段と、
   第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、
   第１のメタデータに基づき、配信された上記複数の時分割データをそのまま再生し、第２のメタデータに基づき上記異なる個数の時分割データを記録して再生する再生手段と、を備えている、ことを特徴とする再生装置。
6. 上記コンテンツは上記複数の時分割データに時分割されてライブ配信されるコンテンツであり、
   上記再生手段は、第１のメタデータに基づいて、上記複数の時分割データをライブ再生する、ことを特徴とする請求項５に記載の再生装置。
7. 上記第１変換手段は、上記複数の時分割データの全部または一部を、より少数の時分割データに変換する、ことを特徴とする請求項５または６に記載の再生装置。
8. 上記第１変換手段は、上記全部または一部をグループ分けしながら各グループについて該グループの時分割データ群を統合することで、上記複数の時分割データを上記より少数の時分割データに変換する、ことを特徴とする、請求項７に記載の再生装置。
9. 上記第１変換手段は、上記全部または一部を一定個数ずつのグループにグループ分けする、ことを特徴とする、請求項８に記載の再生装置。
10. 上記一定個数は、上記より少数の時分割データを構成する各時分割データの先頭位置がランダムアクセスポイントになるような個数である、ことを特徴とする請求項９に記載の再生装置。
11. 第１のメタデータには上記全部または一部を構成する各時分割データの時間長である第１の時間長と上記より少数の時分割データを構成する各時分割データの時間長であって第１の時間長の整数倍である第２の時間長とが示されており、
    上記一定個数は、第１の時間長および上記第２の時間長により第１のメタデータに非明示的に示されている、ことを特徴とする請求項９または１０に記載の再生装置。
12. 上記一定個数は、第１のメタデータに明示的に示されている、ことを特徴とする請求項９または１０に記載の再生装置。
13. 第１のメタデータには上記一部を特定するための特定情報が示されており、
    上記第１変換手段は、上記特定情報に基づいて特定した上記複数の時分割データの一部を、上記より少数の時分割データに変換する、ことを特徴とする請求項５から１２のいずれか１項に記載の再生装置。
14. 上記特定情報は、上記複数の時分割データの一部を構成する時系列順で先頭の時分割データの識別子であり、
    上記複数の時分割データを構成する各時分割データの再生用情報には、該時分割データの識別子が含まれている、ことを特徴とする請求項１３に記載の再生装置。
15. 第１のメタデータに示されている上記識別子は、上記取得手段が第１のメタデータを取得するタイミングにおいて未だ配信されていない先頭の時分割データの識別子になっている、ことを特徴とする請求項１４に記載の再生装置。
16. コンテンツが時分割された複数の時分割データを異なる個数の時分割データに変換する第１変換手段と、
    上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信手段と、
    第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、
    第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信手段と、を備えている、ことを特徴とする配信装置。
17. 複数の時分割データに時分割されて配信されるコンテンツを記録し配信する配信装置において、
    上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得手段と、
    上記複数の時分割データの全部または一部を、異なる個数の時分割データに変換する第１変換手段と、
    第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換手段と、
    第２のメタデータを配信するとともに、上記異なる個数の時分割データを記録して配信する配信手段と、を備えている、ことを特徴とする配信装置。
18. 複数の時分割データに時分割されて配信されるコンテンツを記録して再生する再生装置の再生方法において、
    上記複数の時分割データを構成する各時分割データに関する再生用情報が示された第１のメタデータを取得する取得工程と、
    上記複数の時分割データの全部または一部を異なる個数の時分割データに変換する第１変換工程と、
    第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換工程と、
    第１のメタデータに基づき上記複数の時分割データをそのまま再生し、第２のメタデータに基づき上記異なる個数の時分割データを記録して再生する再生工程と、を含んでいる、ことを特徴とする再生方法。
19. コンテンツが時分割された複数の時分割データを、異なる個数の時分割データに変換する第１変換工程と、
    上記複数の時分割データの各々に関する再生用情報が示された第１のメタデータを配信するともに、上記複数の時分割データを配信する第１配信工程と、
    第１のメタデータを、上記異なる個数の時分割データを構成する各時分割データに関する再生用情報が示された第２のメタデータに変換する第２変換工程と、
    第２のメタデータを配信するとともに、上記異なる個数の時分割データを配信する第２配信工程と、を含んでいる、ことを特徴とする配信方法。
20. 請求項２、または請求項５から１５のいずれか１項に記載の再生装置としてコンピュータを動作させる再生プログラムであって、コンピュータを上記各手段として機能させるための再生プログラム。
21. 請求項２０に記載の再生プログラムが記録されているコンピュータ読み取り可能な記録媒体。
22. 請求項１、請求項１６または１７のいずれか１項に記載の配信装置としてコンピュータを動作させる配信プログラムであって、コンピュータを上記各手段として機能させるための配信プログラム。
23. 請求項２２に記載の配信プログラムが記録されているコンピュータ読み取り可能な記録媒体。
24. 複数の時分割データに時分割されてライブ配信されるコンテンツに関するメタデータであって、
    上記複数の時分割データの全部または一部を一定個数ずつのグループに分類し、各グループについて該グループの時分割データ群を統合するための統合情報と、
    上記全部または一部を構成する各時分割データに関する再生用情報と、が示されているメタデータ。

Images