特開 2024-7248 配信サーバ、受信装置、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024007248

(43)【公開日】2024-01-18

(54)【発明の名称】配信サーバ、受信装置、及びプログラム

(51)【国際特許分類】

   H04N 21/234 20110101AFI20240111BHJP

   H04N 21/44 20110101ALI20240111BHJP

【ＦＩ】

H04N21/234

H04N21/44

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2022108621

(22)【出願日】2022-07-05

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】000004352

【氏名又は名称】日本放送協会

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】230118913

【弁護士】

【氏名又は名称】杉村 光嗣

(74)【代理人】

【識別番号】100161148

【弁理士】

【氏名又は名称】福尾 誠

(72)【発明者】

【氏名】西村 敏

(72)【発明者】

【氏名】福留 大貴

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164MB13S

5C164MB44S

5C164SB01P

5C164SC11S

5C164UB01P

5C164UB41S

5C164YA18

(57)【要約】

【課題】低遅延セグメント形式のストリーミングコンテンツを、低遅延セグメント形式に非対応の受信装置でも再生可能とする。
【解決手段】配信サーバ１０は、イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換するセグメント変換部１４と、セグメントをリクエストする受信装置が低遅延セグメント形式に対応しているか否かを判定する低遅延セグメント形式対応判定部１８と、受信装置が低遅延セグメント形式に対応している場合には低遅延セグメントを送信し、受信装置が低遅延セグメント形式に対応していない場合には通常セグメントを送信するセグメント送信部１９と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数のセグメントから構成されるコンテンツをセグメント毎に受信装置に配信する配信サーバであって、
イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換するセグメント変換部と、
セグメントをリクエストする受信装置が低遅延セグメント形式に対応しているか否かを判定する低遅延セグメント形式対応判定部と、
前記受信装置が低遅延セグメント形式に対応している場合には前記低遅延セグメントを送信し、前記受信装置が低遅延セグメント形式に対応していない場合には前記通常セグメントを送信するセグメント送信部と、
を備える配信サーバ。

【請求項2】

前記セグメント変換部は、受信したチャンクのメタ情報を基に、該チャンクの先頭フレームがイントラフレームであるか否かを判定し、先頭フレームがイントラフレームであるチャンクに、先頭フレームがイントラフレームでない後続のチャンクを結合して、前記通常セグメントを生成する、請求項１に記載の配信サーバ。

【請求項3】

配信サーバから、複数のセグメントから構成されるコンテンツをセグメント毎に受信する受信装置であって、
イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換するセグメント変換部と、
当該受信装置が低遅延セグメント形式に対応しているか否かを判定する低遅延セグメント形式対応判定部と、
当該受信装置が低遅延セグメント形式に対応している場合には前記低遅延セグメントを復号して再生し、当該受信装置が低遅延セグメント形式に対応していない場合には前記通常セグメントを復号して再生する復号・再生部と、
を備える受信装置。

【請求項4】

前記セグメント変換部は、受信したチャンクのメタ情報を基に、該チャンクの先頭フレームがイントラフレームであるか否かを判定し、先頭フレームがイントラフレームであるチャンクに、先頭フレームがイントラフレームでない後続のチャンクを結合して、前記通常セグメントを生成する、請求項３に記載の受信装置。

【請求項5】

コンピュータを、請求項１又は２に記載の配信サーバとして機能させるためのプログラム。

【請求項6】

コンピュータを、請求項３又は４に記載の受信装置として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、配信サーバ、受信装置、及びプログラムに関する。

【背景技術】

【0002】

昨今のインターネットにおけるストリーミング動画配信では、汎用的なＷｅｂサーバによりＨＴＴＰプロトコルを用いてストリーミング配信する方式が主流となっている。このようなＨＴＴＰプロトコルによるストリーミング配信方式（アダプティブストリーミング）の一例としては、国際標準規格のＭＰＥＧ－ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９－１）がある。

【0003】

ＭＰＥＧ－ＤＡＳＨでは、Ｗｅｂサーバに、初期化セグメント、メディアセグメント、及びそれらのＵＲＬや動画コンテンツの属性を記述したマニフェストファイルを用意する。メディアセグメントは、動画コンテンツを一つ又は複数の品質（画面サイズやビットレート等のパラメータ）でエンコードしたストリームをそれぞれ数秒から数十秒程度のファイルに分割したセグメントである。初期化セグメントは、各ストリームの符号化や暗号化等に関する生成パラメータ等、セグメントの提示に必要なメタデータを含む。受信装置は、マニフェストファイルから当該受信装置の画面サイズや伝送路のネットワーク帯域の状態等を考慮して、適時品質を選択して次々とセグメントを受信し、１本の動画コンテンツにつなぎ合わせて再生する（例えば、非特許文献１参照）。

【0004】

セグメントのメディアコンテナ形式としては、ＩＳＯ－ＢＭＦＦ（ISO-Base Media File Format）形式が主に用いられるが、当該形式をベースにセグメントの中にチャンクと呼ばれるより細かい単位が定義されたＣＭＡＦ（Common Media Application Format）が標準化されている（例えば、非特許文献２参照）。

【0005】

図６に、従来のセグメントと、ＣＭＡＦによるセグメント（ＣＭＡＦセグメント）とを比較して示す。ｍｄａｔ（Media Data Box）は、映像、音声等のメディアデータを格納するボックスであり、ｍｏｏｆ（Movie Fragment Box）は直後のｍｄａｔのメタ情報を格納するボックスである。１組のｍｏｏｆ及びｍｄａｔを「チャンク」という。

【0006】

従来のセグメントでは、メディアデータが映像の場合、イントラフレームとそれに続く複数のインターフレームをグループ化したＧＯＰ（Group of Pictures）単位、又は複数ＧＯＰ単位で、セグメント内に１つのチャンクを構成するのが一般的であった。図６では従来のセグメントとして、２ＧＯＰ単位で１つのチャンクを構成する例を示している。一方、ＣＭＡＦセグメントにおいては、１から数フレーム単位で１つのチャンク（ＣＭＡＦチャンク）を構成する。すなわち、ＣＭＡＦセグメントは、複数のＣＭＡＦチャンクにより構成される。図６に示すＣＭＡＦセグメントは、イントラフレームを含むＣＭＡＦチャンクａ，ｃと、イントラフレームを含まないＣＭＡＦチャンクｂ，ｄにより構成される。

【0007】

図６の従来のセグメントでは、ｍｄａｔの最終バイトまでのエンコードが完了するまでセグメントを配信できなかったのに対し、ＣＭＡＦセグメントの形式にすることにより、最初のＣＭＡＦチャンクにおけるｍｄａｔの最終バイトのエンコードが終了した時点から順次セグメントの配信を開始できるため、より低遅延なライブ配信が可能となる（例えば、非特許文献３参照）。

【0008】

また、特許文献１には、メディアコンテナ形式としてＣＭＡＦを適用したＭＭＴ（MPEG Media Transport）ストリームをＣＭＡＦ非適用のＭＭＴに変換することにより、ＣＭＡＦを適用したＭＭＴストリームに非対応の受信機でも再生できるようにする多重信号変換装置が開示されている。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特開２０２１－１９７５８４号公報

【非特許文献】

【0010】

【非特許文献1】平林 光浩, “次世代動画配信技術「ＭＰＥＧ－ＤＡＳＨ」技術概要と標準化・関連技術動向”, 映像情報メディア学会誌， Vol.67, No.2, 2013, p.109-115

【非特許文献2】“ISO/IEC 23000-19:2020 Information technology - Multimedia application format (MPEG-A) - Part 19: Common media application format(CMAF) for segmented media”，International Organization for Standardization，2020年3月

【非特許文献3】Yuhki Hanada, 2018年4月5日, “CMAF と CMAFを使用した低遅延LIVE 配信の実現”, [online], [2022年6月20日検索]， インターネット<URL:https://www.akamai.com/ja/blog/performance/cmaf-cmaf-low-lalatency-live>

【発明の概要】

【発明が解決しようとする課題】

【0011】

動画配信の低遅延化に対する需要の高まりから、ＣＭＡＦ等による低遅延セグメント形式のストリーミング配信が今後ますます普及していくと考えられる。しかしながら、従来のセグメント形式によるストリーミング配信に早くから対応していた装置においては、ｍｄａｔ内にイントラフレームを含まないチャンクを含む低遅延セグメント形式のストリーミング配信の再生に非対応な場合がある。このような低遅延セグメント形式に非対応な受信装置に対しては、従来のセグメント形式によるストリーミング配信を行うことも可能であるが、常に２種類のストリームのエンコードが必要となる。なお、特許文献１に開示された技術も、この課題を解決するものではなかった。

【0012】

かかる事情に鑑みてなされた本発明の目的は、低遅延セグメント形式のストリーミングコンテンツを、低遅延セグメント形式に非対応の受信装置でも再生できるようにする配信サーバ、受信装置、及びプログラムを提供することにある。

【課題を解決するための手段】

【0013】

上記課題を解決するため、一実施形態に係る配信サーバは、複数のセグメントから構成されるコンテンツをセグメント毎に受信装置に配信する配信サーバであって、イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換するセグメント変換部と、セグメントをリクエストする受信装置が低遅延セグメント形式に対応しているか否かを判定する低遅延セグメント形式対応判定部と、前記受信装置が低遅延セグメント形式に対応している場合には前記低遅延セグメントを送信し、前記受信装置が低遅延セグメント形式に対応していない場合には前記通常セグメントを送信するセグメント送信部と、を備える。

【0014】

さらに、一実施形態に係る配信サーバにおいて、前記セグメント変換部は、受信したチャンクのメタ情報を基に、該チャンクの先頭フレームがイントラフレームであるか否かを判定し、先頭フレームがイントラフレームであるチャンクに、先頭フレームがイントラフレームでない後続のチャンクを結合して、前記通常セグメントを生成してもよい。

【0015】

上記課題を解決するため、一実施形態に係る受信装置は、配信サーバから、複数のセグメントから構成されるコンテンツをセグメント毎に受信する受信装置であって、イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換するセグメント変換部と、当該受信装置が低遅延セグメント形式に対応しているか否かを判定する低遅延セグメント形式対応判定部と、当該受信装置が低遅延セグメント形式に対応している場合には前記低遅延セグメントを復号して再生し、当該受信装置が低遅延セグメント形式に対応していない場合には前記通常セグメントを復号して再生する復号・再生部と、を備える。

【0016】

さらに、一実施形態に係る受信装置において、前記セグメント変換部は、受信したチャンクのメタ情報を基に、該チャンクの先頭フレームがイントラフレームであるか否かを判定し、先頭フレームがイントラフレームであるチャンクに、先頭フレームがイントラフレームでない後続のチャンクを結合して、前記通常セグメントを生成してもよい。

【0017】

また、上記課題を解決するため、一実施形態に係るプログラムは、コンピュータを、上記配信サーバとして機能させる。

【0018】

また、上記課題を解決するため、一実施形態に係るプログラムは、コンピュータを、上記受信装置として機能させる。

【発明の効果】

【0019】

本発明によれば、低遅延セグメント形式のストリーミングコンテンツを、低遅延セグメント形式に非対応の受信装置でも再生できるようになる。そのため、後方互換性を確保しつつ、効率的に低遅延配信を実現することが可能となる。

【図面の簡単な説明】

【0020】

【図1】第１の実施形態に係る配信システムの構成例を示すブロック図である。

【図2】第１の実施形態に係る配信サーバの構成例を示すブロック図である。

【図3】第１の実施形態に係る配信サーバにおけるセグメント変換部による処理の一例を示すフローチャートである。

【図4】第２の実施形態に係る配信システムの構成例を示すブロック図である。

【図5】第２の実施形態に係る受信装置の構成例を示すブロック図である。

【図6】従来のセグメントとＣＭＡＦによるセグメントとを比較して示す図である。

【発明を実施するための形態】

【0021】

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

【0022】

本明細書において、「低遅延セグメント」とは、図６に示したＣＭＡＦセグメントのように１から数フレーム単位で１つのチャンクを構成するセグメントであって、イントラフレームを含まないチャンクを有するセグメントのことをいう。また、「通常セグメント」とは、図６に示した従来のセグメントのように１以上のＧＯＰ単位で１つのチャンクを構成するセグメントであって、イントラフレームを含まないチャンクを有さないセグメントのことをいう。

【0023】

＜第１の実施形態＞
（コンテンツ配信システム）
図１は、本発明の第１の実施形態に係るコンテンツ配信システムの構成例を示す図である。図１に示すコンテンツ配信システム１は、配信サーバ１０と、ライブエンコーダ２０と、第１受信装置３０と、第２受信装置４０と、を備える。図１では図面の便宜上、第１受信装置３０及び第２受信装置４０をそれぞれ１つのみ示しているが、コンテンツ配信システム１は第１受信装置３０及び第２受信装置４０をそれぞれ１以上備える。

【0024】

配信サーバ１０及びライブエンコーダ２０は、通信ネットワークＮＷ１を介して接続される。通信ネットワークＮＷ１は、専用のローカルネットワークでもよいし、インターネットでもよい。配信サーバ１０、第１受信装置３０、及び第２受信装置４０は、インターネットなどの通信ネットワークＮＷ２を介して接続される。

【0025】

ライブエンコーダ２０は、入力映像をＣＭＡＦ等の低遅延セグメント形式でエンコードし、エンコードした低遅延セグメントを順次配信サーバ１０に出力する。エンコードは、Ｈ．２６４｜ＭＰＥＧ－４ ＡＶＣ（Advanced Video Coding）、Ｈ．２６５｜ＭＰＥＧ－Ｈ ＨＥＶＣ（High Efficiency Video Coding）といった既存の映像符号化方式により行われる。ライブエンコーダ２０は、例えばセグメント単位でHTTP/1.1 Chunked Transfer Encoding形式により配信サーバ１０とセッションを確立し、チャンク単位で低遅延セグメントを送信する。

【0026】

配信サーバ１０は、複数のセグメントから構成されるコンテンツをセグメント毎に、該セグメントをリクエストする第１受信装置３０及び第２受信装置４０に配信する。

【0027】

第１受信装置３０は、低遅延セグメント形式（ＭＰＥＧ－ＤＡＳＨ等のセグメント型ストリーミング方式）に対応した受信装置であり、配信サーバ１０に順次セグメントをリクエストして取得し、復号・再生する端末である。第１受信装置３０は、配信サーバ１０とはセグメント単位で、例えばHTTP/1.1 Chunked Transfer Encoding形式によりセッションを確立し、チャンク単位でセグメントを受信する。

【0028】

第２受信装置４０は、基本的な構成は第１受信装置３０と共通であるが、低遅延セグメント形式に非対応な受信装置である。すなわち、第２受信装置４０は、イントラフレームを含まないチャンク（例えば、ＣＭＡＦチャンク）の復号・再生に対応していない。

【0029】

（配信サーバ）
次に、配信サーバ１０の詳細について説明する。図２は、配信サーバ１０の構成例を示すブロック図である。図２に示す配信サーバ１０は、第１通信Ｉ／Ｆ１１と、セグメント受信部１２と、低遅延セグメント用バッファ１３と、セグメント変換部１４と、通常セグメント用バッファ１５と、第２通信Ｉ／Ｆ１６と、リクエスト受信部１７と、低遅延セグメント形式対応判定部１８と、セグメント送信部１９と、を備える。なお、通信ネットワークＮＷ１及び通信ネットワークＮＷ２が共通である場合には、第１通信Ｉ／Ｆ１１及び第２通信Ｉ／Ｆ１６は共通であってもよい。

【0030】

セグメント受信部１２は、ライブエンコーダ２０から第１通信Ｉ／Ｆ１１を介して順次低遅延セグメントを受信し、低遅延セグメント用バッファ１３に出力する。ライブエンコーダ２０からは、例えばHTTP/1.1 Chunked Transfer Encoding形式によりセグメント単位でセッションを確立し、チャンク単位で低遅延セグメントを受信する。セグメント受信部１２は、低遅延セグメント用バッファ１３へは、セグメントの受信完了を待たずに、チャンク単位で出力する。また、セグメント変換部１４にも同時にチャンク単位で出力する。

【0031】

セグメント変換部１４は、セグメント受信部１２から入力した低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換し、変換した通常セグメントを通常セグメント用バッファ１５に出力する。

【0032】

セグメント変換部１４は、受信したチャンクのメタ情報を基に、該チャンクの先頭フレームがイントラフレームであるか否かを判定し、先頭フレームがイントラフレームであるチャンクに、先頭フレームがイントラフレームでない後続のチャンクを結合して、通常セグメントを生成する。セグメント変換部１４の処理の詳細については、後述する。

【0033】

リクエスト受信部１７は、第１受信装置３０又は第２受信装置４０から、第２通信Ｉ／Ｆ１６を介してセグメントのリクエストを受信し、当該リクエストに含まれるセグメントのＵＲＬ、及び第１受信装置３０又は第２受信装置４０の端末情報を、低遅延セグメント形式対応判定部１８に通知する。端末情報として、例えばＨＴＴＰリクエストに含まれるＵｓｅｒ－Ａｇｅｎｔ情報を利用可能であるが、端末情報はこれに限定されるものではない。

【0034】

低遅延セグメント形式対応判定部１８は、リクエスト受信部１７から入力した端末情報に基づいて、セグメントをリクエストする受信装置が低遅延セグメント形式に対応しているか否かを判定する。低遅延セグメント形式に対応しているとは、低遅延セグメントを復号・再生できることを意味する。低遅延セグメント形式対応判定部１８は、ブラウザ、ＯＳ、受信装置の機種などに応じた対応リスト（又は非対応リスト）をあらかじめ作成しておき、端末情報に含まれるそれら情報と照合することにより、低遅延セグメント形式に対応しているか否かを判定してもよい。

【0035】

低遅延セグメント形式対応判定部１８は、受信装置が低遅延セグメント形式に対応していると判定した場合には、リクエスト受信部１７から入力したセグメントのＵＲＬに該当する低遅延セグメントを低遅延セグメント用バッファ１３から取得し、セグメント送信部１９に出力する。一方、低遅延セグメント形式対応判定部１８は、受信装置が低遅延セグメント形式に対応していないと判定した場合には、セグメントのＵＲＬに該当する通常セグメントを通常セグメント用バッファ１５から取得し、セグメント送信部１９に出力する。

【0036】

セグメント送信部１９は、低遅延セグメント形式対応判定部１８から入力した低遅延セグメントを第２通信Ｉ／Ｆ１６を介して第１受信装置３０に出力し、低遅延セグメント形式対応判定部１８から入力した通常セグメントを第２通信Ｉ／Ｆ１６を介して第２受信装置４０に出力する。すなわち、セグメント送信部１９は、受信装置が低遅延セグメント形式に対応している場合には低遅延セグメントを送信し、受信装置が低遅延セグメント形式に対応していない場合には通常セグメントを送信する。

【0037】

（セグメント変換方法）
次に、セグメント変換部１４による１セグメント分の低遅延セグメントの変換方法について、図３に示すフローチャートを参照して説明する。ここでは、低遅延セグメントのメディアコンテナ形式はＩＳＯ－ＢＭＦＦ又はＣＭＡＦに従うものとする。

【0038】

ステップＳ００１では、セグメント変換部１４は、セグメント受信部１２から１チャンクを受信する。

【0039】

ステップＳ００２では、セグメント変換部１４は、受信したチャンクのｍｏｏｆボックスを解析し、ｍｄａｔボックスに含まれるメディアデータのメタ情報を取得する。メタ情報には、例えば、先頭フレームのデコード時刻（baseMediaDecodeTime）、チャンク内のフレーム数（sample_count）、フレーム毎の時間長（sample_duration）、データサイズ（sample_size）、フラグ（sample_flag）、及び時刻オフセット値（sample_composition_time_offset）が含まれる。

【0040】

ステップＳ００３では、セグメント変換部１４は、メタ情報を基に受信したチャンクの先頭フレームがイントラフレームであるか否かを判定する。例えば、メタ情報における先頭フレームのsample_flagにおけるsample_depends_on値が２である場合には、先頭フレームがイントラフレームであると判定する。セグメント変換部１４は、先頭フレームがイントラフレームでないと判定した場合には（ステップＳ００３－ＮＯ）、処理をステップＳ００４に進め、先頭フレームがイントラフレームであると判定した場合には（ステップＳ００３－ＹＥＳ）、処理をステップＳ００６に進める。

【0041】

ステップＳ００４では、セグメント変換部１４は、受信したチャンクのメタ情報とｍｄａｔを、セグメント変換部１４内の一次バッファに格納する。なお、一次バッファはセグメント変換部１４の外部にあってもよい。

【0042】

ステップＳ００５では、セグメント変換部１４は、一次バッファに格納したチャンクが１つの低遅延セグメント内の最後のチャンクであるか否かを判定する。格納したチャンクが低遅延セグメントの最後のチャンクでない場合には（ステップＳ００５－ＮＯ）、処理をステップＳ００１に戻し、格納したチャンクが低遅延セグメントの最後のチャンクである場合には（ステップＳ００５－ＹＥＳ）、処理をステップＳ００７に進める。

【0043】

ステップＳ００６では、セグメント変換部１４は、一次バッファにデータが格納されているか否かを確認する。一次バッファにデータが格納されていない場合には（ステップＳ００６－ＮＯ）、処理をステップＳ００４に進め、一次バッファにデータが格納されている場合には（ステップＳ００６－ＹＥＳ）、処理をステップＳ００７に進める。

【0044】

ステップＳ００７では、セグメント変換部１４は、一次バッファに格納されているデータを取り出す。そして、チャンク毎のｍｄａｔに含まれるメディアデータを、一次バッファに格納された順に連結し、ＩＳＯ－ＢＭＦＦ仕様に従って再構成したｍｄａｔを生成する。これにより、イントラフレームを含むｍｄａｔを生成することができる。

【0045】

ステップＳ００８では、セグメント変換部１４は、一次バッファに格納されたチャンク毎のメタ情報を基に、ＩＳＯ－ＢＭＦＦ仕様に従ってｍｄａｔに対応するｍｏｏｆを生成する。

【0046】

ステップＳ００９では、セグメント変換部１４は、生成したｍｏｏｆとｍｄａｔを連結して通常セグメント形式のチャンクを生成し、セグメント変換部１４内の二次バッファに格納する。なお、二次バッファはセグメント変換部１４の外部にあってもよい。

【0047】

ステップＳ０１０では、セグメント変換部１４は、１つの低遅延セグメント内の全てのチャンクの処理が終了したか否かを判定する。低遅延セグメント内の全てのチャンクの処理が終了した場合には（ステップＳ０１０－ＹＥＳ）、処理をステップＳ０１１に進める。低遅延セグメント内に処理が終了していないチャンクがある場合には（Ｓ０１０－ＮＯ）、処理をステップＳ００４に戻し、受信したチャンクのメタ情報とｍｄａｔを一次バッファに格納する。

【0048】

ステップＳ０１１では、セグメント変換部１４は、二次バッファに格納されている通常セグメント形式のチャンクを取り出す。そして、二次バッファに格納された順に結合して通常セグメントを生成して通常セグメント用バッファ１５に出力し、処理を終了する。

【0049】

このように、配信サーバ１０は、ライブエンコーダ２０から出力された低遅延セグメントを通常セグメントに変換したうえで、低遅延セグメント形式に非対応の第２受信装置４０に送信する。そのため、第２受信装置４０においても、復号・再生が可能となる。

【0050】

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。図４は、本発明の第２の実施形態に係るコンテンツ配信システムの構成例を示す図である。図４に示すコンテンツ配信システム２は、配信サーバ１０ａと、ライブエンコーダ２０と、受信装置５０と、を備える。図４では図面の便宜上、受信装置５０を１つのみ示しているが、コンテンツ配信システム２は受信装置５０を１以上備える。なお、配信サーバ１０ａとライブエンコーダ２０は、一体として構成される１つの装置であってもよい。

【0051】

図４では、ライブエンコーダ２０及び配信サーバ１０ａは、通信ネットワークＮＷ１を介して接続される。通信ネットワークＮＷ１は、専用のローカルネットワークでもよいし、インターネットでもよい。配信サーバ１０ａ及び受信装置５０は、インターネットなどの通信ネットワークＮＷ２を介して接続される。

【0052】

ライブエンコーダ２０は、第１の実施形態と同じであり、チャンク単位で低遅延セグメントを配信サーバ１０ａに送信する。

【0053】

配信サーバ１０ａは、ライブエンコーダ２０から受信した低遅延セグメントをバッファリングする。そして、配信サーバ１０ａは、受信装置５０からのセグメントのリクエストに応じて、低遅延セグメントを受信装置５０に配信する。

【0054】

受信装置５０は、ＭＰＥＧ－ＤＡＳＨ等のセグメント型ストリーミング方式に従って、配信サーバ１０ａに順次セグメントをリクエストする。そして、配信サーバ１０ａから、複数のセグメントから構成されるコンテンツをセグメント毎に受信する。

【0055】

（受信装置）
次に、受信装置５０の詳細について説明する。図５は、受信装置５０の構成例を示すブロック図である。図５に示す受信装置５０は、通信Ｉ／Ｆ５１と、セグメントリクエスト部５２と、セグメント受信部５３と、低遅延セグメント形式対応判定部５４と、バッファ５５と、セグメント変換部５６と、復号・再生部５７と、を備える。

【0056】

セグメントリクエスト部５２は、配信サーバ１０ａと、例えばHTTP/1.1 Chunked Transfer Encoding形式によりセグメント単位でセッションを確立し、所望のセグメントのＵＲＬを含むリクエストを配信サーバ１０ａに要求する。

【0057】

セグメント受信部５３は、配信サーバ１０ａから第１通信Ｉ／Ｆ１１を介して所望のセグメントのＵＲＬに対応する低遅延セグメントを受信し、低遅延セグメント形式対応判定部５４に出力する。

【0058】

低遅延セグメント形式対応判定部５４は、受信装置５０における復号・再生部５７が低遅延セグメント形式に対応しているか否かを判定する。例えば、受信装置５０のブラウザ・ＯＳ・端末の機種など基づいて判定してもよい。あるいは、あらかじめ低遅延セグメントをバッファ経由で復号・再生部５７に入力し、エラーとなるか否かを検証し、その結果をもって判定してもよい。

【0059】

低遅延セグメント形式対応判定部５４は、復号・再生部５７が低遅延セグメント形式に対応していると判定した場合は、セグメント受信部５３から入力した低遅延セグメントをバッファ５５に出力する。一方、低遅延セグメント形式対応判定部５４は、復号・再生部５７が低遅延セグメント形式に対応していないと判定した場合は、低遅延セグメントをセグメント変換部５６に出力する。

【0060】

セグメント変換部５６は、第１の実施形態と同様に（図３参照）、イントラフレームを含まないチャンクを有する低遅延セグメントを、全チャンクがイントラフレームを含む通常セグメントに変換し、通常セグメントをバッファ５５に出力する。

【0061】

バッファ５５は、低遅延セグメント形式対応判定部５４から入力したセグメント、又はセグメント変換部５６から入力した通常セグメントを復号・再生部５７に出力する。

【0062】

復号・再生部５７は、バッファ５５から入力した低遅延セグメント又は通常セグメントを復号して再生する。すなわち、復号・再生部５７は、受信装置５０が低遅延セグメント形式に対応している場合には低遅延セグメントを復号して再生し、受信装置５０が低遅延セグメント形式に対応していない場合には通常セグメントを復号して再生する。

【0063】

以上の処理により、受信装置５０は、復号・再生部５７が、低遅延セグメント形式に対応しているか否かに関わらず、配信サーバ１０ａから低遅延セグメントを受信し、再生することが可能となる。

【0064】

なお、セグメント変換部５６は、JavaScript等のソフトウェアとして実装可能である。そのため受信装置５０の出荷の時点で組み込まれている必要はなく、配信サーバ１０ａからのコンテンツの受信に先立って、外部のＷｅｂサイト等から取得して実行することが可能である。よって後方互換性を確保しつつ、効率的に低遅延配信を実現することが可能となる。

【0065】

（プログラム）
上述した配信サーバ１０及び受信装置５０として機能させるために、それぞれプログラム命令を実行可能なコンピュータを用いることも可能である。ここで、コンピュータは、汎用コンピュータ、専用コンピュータ、ワークステーション、ＰＣ（Personal Computer）、電子ノートパッドなどであってもよい。プログラム命令は、必要なタスクを実行するためのプログラムコード、コードセグメントなどであってもよい。

【0066】

コンピュータは、プロセッサと、記憶部と、入力部と、出力部と、通信インターフェースとを備える。プロセッサは、ＣＰＵ(Central Processing Unit)、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＳｏＣ（System on a Chip）などであり、同種又は異種の複数のプロセッサにより構成されてもよい。プロセッサは、記憶部からプログラムを読み出して実行することで、上記各構成の制御及び各種の演算処理を行う。なお、これらの処理内容の少なくとも一部をハードウェアで実現することとしてもよい。

【0067】

プログラムは、コンピュータが読み取り可能な記録媒体に記録されていてもよい。このような記録媒体を用いれば、プログラムをコンピュータにインストールすることが可能である。ここで、プログラムが記録された記録媒体は、非一過性（non-transitory）の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢ（Universal Serial Bus）メモリなどであってもよい。また、このプログラムは、ネットワークを介して外部装置からダウンロードされる形態としてもよい。

【0068】

例えば、配信サーバ１０として機能させるためのプログラムは、低遅延セグメントを通常セグメントに変換するステップと、セグメントをリクエストする受信装置が低遅延セグメント形式に対応しているか否かを判定するステップと、受信装置が低遅延セグメント形式に対応している場合には低遅延セグメントを送信し、受信装置が低遅延セグメント形式に対応していない場合には通常セグメントを送信するステップと、コンピュータに実行させる。

【0069】

例えば、受信装置５０として機能させるためのプログラムは、低遅延セグメントを通常セグメントに変換するステップと、受信装置５０が低遅延セグメント形式に対応しているか否かを判定するステップと、受信装置５０が低遅延セグメント形式に対応している場合には低遅延セグメントを復号して再生し、受信装置５０が低遅延セグメント形式に対応していない場合には通常セグメントを復号して再生するステップと、コンピュータに実行させる。

【0070】

また、上述した配信サーバ１０及び受信装置５０は、それぞれ１つ又は複数の半導体チップにより構成されてもよい。この半導体チップは、配信サーバ１０及び受信装置５０の各機能を実現する処理内容を記述したプログラムを実行するＣＰＵを搭載してもよい。

【0071】

上述の実施形態は代表的な例として説明したが、本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形又は変更が可能である。例えば、実施形態の構成図に記載の複数の構成ブロックを統合したり、１つの構成ブロックを分割したりすることが可能である。

【符号の説明】

【0072】

１，２ コンテンツ配信システム
１０，１０ａ 配信サーバ
１１ 第１通信Ｉ／Ｆ
１６ 第２通信Ｉ／Ｆ
１２ セグメント受信部
１３ 低遅延セグメント用バッファ
１４，５６ セグメント変換部
１５ 通常セグメント用バッファ
１６ 通信Ｉ／Ｆ
１７ リクエスト受信部
１８，５４ 低遅延セグメント形式対応判定部
１９ セグメント送信部
２０ ライブエンコーダ
３０ 第１受信装置
４０ 第２受信装置
５０ 受信装置
５１ 通信Ｉ／Ｆ
５２ セグメントリクエスト部
５３ セグメント受信部
５５ バッファ
５７ 復号・再生部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】