JP2020010142A - 受信機、放送設備、放送システムおよびプログラム - Google Patents

Abstract

【課題】放送サービスのサービス品質の向上を図る。【解決手段】本発明に係る受信機３０は、第１の伝送路２を介して伝送された、セグメントと、各補完セグメントに共通の共通部と、セグメントに割り当てられたシーケンス番号に応じて予め定められた規則に従い置き換えられる置換部とを含むテンプレートアドレスとを取得し、取得すべきセグメントの損失を検出する放送多重分離部３２と、損失したセグメントに割り当てられたシーケンス番号に基づき、予め定められた規則に従いテンプレートアドレスの置換部を置き換えてリクエストアドレスを生成するリクエストＵＲＬ生成部３３と、生成されたリクエストアドレスを用いて、第２の伝送路３を介して、損失したセグメントに対応する補完セグメントを、ＷＥＢサーバ２０から取得するＨＴＴＰクライアント部３５とを備える。【選択図】図５

Description

本発明は、受信機、放送設備、放送システムおよびプログラムに関する。

従来のデジタル放送で用いられているＭＰＥＧ（Moving Picture Experts Group）−２ ＴＳ（Transport Stream）に代わる新たなメディアトランスポート方式の国際標準規格として、ＭＭＴ（MPEG Media Transport）が策定されている（非特許文献１参照）。また、次世代デジタル放送サービスにおけるＭＭＴの利用方法の規定が規格化されている（非特許文献２参照）。

ＭＭＴでは、映像・音声のコーデックの処理単位をＭＰＵ（Media Processing Unit）と呼び、ＭＰＵのデータ構造をＩＳＯＢＭＦＦ（ISO Base Media File Format）ベースで規定している。ＭＭＴの放送利用を規定した非特許文献２では、映像符号化のイントラフレームを復号順の先頭とするＧＯＰ（Group Of Picture）をＭＰＵとして扱う。また、音声符号データは１つ以上のＡＵ（Access Unit）の集合をＭＰＵとして扱うことができる。ＭＰＵは、ＭＰＵシーケンス番号によって一意に特定することができる。ＭＰＵのＭＰＵシーケンス番号は、そのＭＰＵを伝送するＭＭＴパケットに記載される。ＭＭＴにおけるＭＰＵのように、時間軸上でＧＯＰやＡＵの切れ目を境界とする映像、音声のいずれかまたは双方を含むデータの集まりをセグメントと呼ぶことがある。セグメントが電波など電気信号上のストリームとして伝送されている状態では単にセグメント、また、ディスクなどの保存領域上に名前（格納場所を示す文字列）を持つファイルとして保存されている状態ではセグメントファイルと呼ばれることがある。両者が境界を持つデジタルデータであることに差異はなく、伝送されているものをセグメントファイル、保存されているものを単にセグメントと呼んでも差し支えはない。また、ＭＰＵに割り当てられるＭＰＵシーケンス番号のように、時間方向に加算されていく連続的な番号を与えることでセグメントの識別や整列ができ、このような番号を一般的にシーケンス番号やセグメント番号と呼ぶことがある。

放送波あるいはＩＰ（Internet Protocol）回線を用いた放送型の映像配信は片方向の伝送であるため、ＩＰ上のトランスポート層にはＵＤＰ（User Datagram Protocol）、アプリケーション層には、例えば、ＭＭＴＰ（ＭＭＴ Protocol）が用いられる。また、不特定多数の受信機にパケットを伝送するため、ＩＰ層ではマルチキャストが用いられる。ＵＤＰは、損失パケットの復元機能を有さないため、伝送路上で起こり得るパケット損失の対策として、アプリケーション層でＦＥＣ（Forward Error Correction）が用いられることがある。ＦＥＣは、複数のパケットデータの演算によりパリティデータを生成し、元のパケット列にパリティパケット列を追加して伝送し、受信機のバッファ内でパケットデータとパリティデータとの演算により損失パケットを復元することで、映像の途切れおよび乱れを防ぐ方式の一般的な名称である。

衛星放送、地上放送およびモバイル通信の放送モードであるＭＢＭＳ（Multimedia Broadcast Multicast Service）などの無線電波を用いる映像配信では、受信機の移動などにより電波の受信状況が悪化し、受信電界強度のＣＮ比が所要ＣＮを下回る場合がある。この場合、受信機では、伝送されるパケットを正常に復調することができなくなり、安定したコンテンツの視聴が困難となる。アプリケーション層にＦＥＣを使用している場合であっても、受信状況の悪化によるパケットロス率の上昇や、バースト性の高いパケットロスの発生によりＦＥＣによる訂正能力を超えた場合には、損失パケットを全て復元することはできず、安定したコンテンツの視聴が困難となる。

一般に、物理層に誤り訂正機能を有するデジタル無線伝送方式においては、受信電界強度のＣＮ比が所要ＣＮ以上であればパケット損失は発生せず、所要ＣＮを下回った途端にパケットロスが急激に増加する。そのため、アプリケーション層でＦＥＣを使用したとしても、パケット損失が生じ、かつ、全ての損失パケットを正常に復元することができる受信電界強度の範囲が狭く、期待する効果が得られない場合が考えられる。例えば、正常に受信することができる場所からごくわずかに移動しただけで、物理層の誤り訂正性能の限界とアプリケーション層のＦＥＣ性能の限界とを同時に超えてしまい、安定したコンテンツの視聴が困難になるという現象が起こり得る。そのため、物理層に誤り訂正機能を有するデジタル無線伝送方式では、誤り耐性強化とＦＥＣ付加によるオーバーヘッドの増加とのトレードオフの観点から、物理層の誤り訂正機能に加えてアプリケーション層でもさらにＦＥＣを用いる合理性は低い場合が考えられる。

一方で、ＦＥＣを用いずにパケットロスによる損失パケットを補完するために、ＡＲＱ（Automatic Repeat Request）が使用されることがある。ＡＲＱは、損失したＩＰパケットについて、双方向回線を用いて送信元に再送信をリクエストし、損失したパケットを受信機の入力段のバッファ内で補完することで、映像の途切れおよび乱れを防ぐ方式の一般的な名称である。ＡＲＱを利用するためには、ＦＥＣの場合と異なり、双方向伝送路が必須である。そこで、例えば、本線には片方向伝送路が用いられ、ＡＲＱ用に双方向伝送路が用いられることがある。

ＩＰ回線を用いた映像伝送のプロトコルとして、ＲＴＰ（Realtime Transport Protocol）が用いられる場合がある。ＲＴＰでは、トランスポート層にＵＤＰが用いられ、基本的には片方向伝送路を介した映像伝送が行われるが、付加的な機能として、双方向伝送路を併用したＡＲＱが用いられる場合がある。ＲＴＰを用いた映像伝送におけるＡＲＱでは、ＲＴＰパケット１つごとに１ずつ加算されるシーケンス番号が検査され、シーケンス番号の欠落が検知された場合に、そのシーケンス番号のＲＴＰパケットの再取得が行われる。このようなＡＲＱに対応するＲＴＰ伝送装置が市販製品として存在する。ただし、ＲＴＰパケットを単位として補完データを取得する方式では、製品メーカー独自のＡＲＱプロトコルに対応するＲＴＰ伝送装置が必要であり、一般にＣＤＮ（Contents Delivery Network）と呼ばれるＷＥＢサーバを用いた汎用的なコンテンツ配信基盤を利用することができない。そのため、受信者数の規模が大きい放送サービスにおいて、ＩＰパケット単位でのＡＲＱは、配信設備のコストが高く、実用が困難である。なお、ＭＭＴパケットにもシーケンス番号が割り当てられるため、ＲＴＰと同様にＩＰパケット単位でのＡＲＱの実装は可能であるが、ＲＴＰの場合と同様の理由により放送サービスにおいては実現が困難である。

ISO/IEC 23008-1、"High efficiency coding and media delivery in heterogeneous environments:MPEG media transport" ARIB STD-B60、"デジタル放送におけるＭＭＴによるメディアトランスポート方式"

上述したように、放送サービスにおいて、ＩＰパケットあるいはＭＭＴパケット単位でのＡＲＱは実現が困難であり、パケットロスが生じた場合にも、映像・音声の途切れおよび乱れを防ぎ、サービス品質の向上を図るための技術が求められている。

上記のような問題点に鑑みてなされた本発明の目的は、放送サービスのサービス品質の向上を図ることができる受信機、放送設備、放送システムおよびプログラムを提供することにある。

上記課題を解決するため、本発明に係る受信機は、第１の伝送路を介して放送設備から伝送され、放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられた、セグメントを取得する受信機であって、前記セグメントと、前記セグメントを補完する補完セグメントの格納先を示し、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含むテンプレートアドレスとを取得し、取得すべきセグメントの損失を検出する第１の取得部と、前記第１の取得部により検出された損失したセグメントに割り当てられたシーケンス番号に基づき、前記予め定められた規則に従い前記テンプレートアドレスの置換部を置き換えて、前記損失したセグメントに対応する補完セグメントの格納先を示すリクエストアドレスを生成する生成部と、双方向伝送路である第２の伝送路を介して、前記生成部により生成されたリクエストアドレスを用いて、前記損失したセグメントに対応する補完セグメントを、前記補完セグメントを格納するサーバ装置から取得する第２の取得部と、を備える。

また、本発明に係る受信機において、前記補完セグメントは、複数のビットレートに対応して前記サーバ装置に格納され、前記テンプレートアドレスは、前記複数のビットレートそれぞれに対応して設けられ、前記生成部は、前記損失したセグメントに割り当てられたシーケンス番号に基づき、予め定められた規則に従い、所望のビットレートの補完セグメントに対応するテンプレートアドレスの置換部を置き換えたリクエストアドレスを生成する。

また、本発明に係る受信機において、前記第１の取得部が取得したテンプレートアドレスをキャッシュする記憶部をさらに備え、前記生成部は、前記第１の伝送路を介した放送を受信することができず、前記第１の伝送路を介して伝送される最新のセグメントのシーケンス番号を取得することができない場合、前記記憶部にキャッシュされているテンプレートアドレスの共通部に予め定められた所定の文字列を付加した、最新の補完セグメントのシーケンス番号を記述したファイルの格納先を示すリクエストアドレスを生成し、前記第２の取得部は、前記生成部により生成されたリクエストアドレスを用いて、前記第２の伝送路を介して、前記最新の補完セグメントのシーケンス番号を記述したファイルを前記サーバ装置から取得する。

また、本発明に係る受信機において、前記生成部によるリクエストアドレスの生成の有無に関わらず、前記サーバ装置からファイルを取得するための前処理を予め行う前処理部と、前記第１の伝送路を介した放送の受信品質を測定する受信品質測定部とをさらに備え、前記前処理部は、前記受信品質測定部により測定された受信品質が、所定の閾値を下回ると、前記前処理を行う。

また、上記課題を解決するため、本発明に係る放送設備は、第１の伝送路を介して受信機に放送サービスを提供する放送設備であって、前記放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたセグメントを生成する符号化部と、前記セグメントを補完する補完セグメントを格納し、該格納する補完セグメントを双方向伝送路である第２の伝送路を介して前記受信機に伝送するサーバ装置のアドレス情報に基づき、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含む、前記補完セグメントの格納先を示すテンプレートアドレスを生成する制御情報生成部と、前記セグメントおよび前記テンプレートアドレスを多重化し、前記第１の伝送路を介して放送を行う送信部に出力する多重化部と、を備える。

また、上記課題を解決するため、本発明に係る放送システムは、放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたセグメントを第１の伝送路を介して伝送する放送設備と、前記セグメントを補完する補完セグメントを格納し、該補完セグメントを、双方向伝送路である第２の伝送路を介して伝送するサーバ装置と、前記放送設備から伝送された前記セグメントを取得する受信機と、を備え、前記放送設備は、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含む、前記補完セグメントの格納先を示すテンプレートアドレスを前記第１の伝送路を介して伝送し、前記受信機は、前記第１の伝送路を介して伝送された、前記セグメントおよび前記テンプレートアドレスを取得し、取得すべきセグメントの損失を検出する第１の取得部と、前記第１の取得部により検出された損失したセグメントに割り当てられたシーケンス番号に応じて、前記予め定められた規則に従い前記テンプレートアドレスの置換部を置き換えた、前記損失したセグメントに対応する補完セグメントの格納先を示すリクエストアドレスを生成する生成部と、前記生成部により生成されたリクエストアドレスを用いて、前記第２の伝送路を介して、前記損失したセグメントに対応する補完セグメントを前記サーバ装置から取得する第２の取得部と、を備える。

また、上記課題を解決するため、本発明に係るプログラムは、コンピュータを上記の受信機として機能させることができる。

本発明に係る受信機、放送設備、放送システムおよびプログラムによれば、放送サービスのサービス品質の向上を図ることができる。

本発明の第１の実施形態に係る放送システムの構成例を示す図である。 図１に示す放送設備の構成例を示す図である。 図２に示す制御情報生成装置が生成するＭＰＵセグメント記述子のデータ構造の一例を示す図である。 図１に示す放送設備の他の構成例を示す図である。 図１に示す受信機の構成例を示す図である。 図１に示す受信機の他の構成例を示す図である。 本発明の第２の実施形態に係る受信機の構成例を示す図である。 本発明の第２の実施形態におけるＭＰＵセグメント記述子のデータ構造の一例を示す図である。 本発明の第３の実施形態に係る受信機の構成例を示す図である。 本発明の第４の実施形態に係る受信機の構成例を示す図である。

以下、本発明を実施するための形態について、図面を参照しながら説明する。各図中、同一符号は、同一または同等の構成要素を示している。

（第１の実施形態）
図１は、本発明の第１の実施形態に係る放送システム１の構成例を示す図である。

図１に示す放送システム１は、放送設備１０と、ＷＥＢサーバ２０と、受信機３０とを備える。

放送設備１０は、第１の伝送路２を介してＩＰパケットを伝送し、放送サービスを提供する（放送を行う）。放送設備１０が伝送するＩＰパケットは、放送サービスにおける映像・音声のコーデックの処理単位であるＭＰＵをペイロードに格納したＭＭＴパケットをＩＰパケット化したものである。各ＭＰＵには、そのＭＰＵを一意に特定するシーケンス番号（ＭＰＵシーケンス番号）が割り当てられ、対応するＭＰＵとともに伝送される。したがって、放送設備１０は、放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたＭＰＵを第１の伝送路２を介して伝送する。また、放送設備１０は、ＭＰＵをＷＥＢサーバ２０に出力する。

ＷＥＢサーバ２０は、映像・音声などの配信に用いられる一般的なサーバ装置である。ＷＥＢサーバ２０は、放送設備１０から出力されたＭＰＵを、受信機３０において損失したＭＰＵを補完するための補完ＭＰＵとして格納する。ＷＥＢサーバ２０は、第２の伝送路３を介した通信により、受信機３０からのリクエストに応じて、補完ＭＰＵを受信機３０に送信する。

第１の伝送路２を介した放送は、例えば、無線電波によるデジタル放送、有線によるケーブルテレビ放送、ＦＴＴＨ（Fiber to the Home）回線によるＩＰ放送、モバイル回線によるＭＢＭＳなどである。また、第２の伝送路３は、ＷＥＢサーバ２０と受信機３０とで相互に送受信が可能な双方向伝送路である。第２の伝送路３は、例えば、モバイル回線あるいはＦＴＴＨ回線などをアクセス回線として用いた広域インターネットであってもよいし、特定の通信事業者の管理下にある閉域ネットワークであってもよい。また、以下では、ＭＭＴによって伝送されるＭＰＵを例として説明するが、本発明はこれに限られるものではない。ＭＰＵは、ＭＭＴ規格で定義された用語であるが、ＲＯＵＴＥ（Real-Time Object Delivery over Unidirectional Transport）など、その他のプロトコルを用いて、映像・音声のコーデックの処理単位を識別しながら伝送することも可能である。ＲＯＵＴＥでは、ＭＰＵに相当する映像・音声のコーデックの処理単位はＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）セグメントと呼ばれることがある。以下では、ＭＰＵおよびＤＡＳＨセグメントといった、放送サービスにおける映像・音声のコーデックの処理単位をセグメントと称することがある。また、補完ＭＰＵのような、セグメントを補完するためのファイルを補完セグメントと称することがある。

受信機３０は、第１の伝送路２を介して放送設備１０から伝送されたＩＰパケットを取得し、取得したＩＰパケットからＭＰＵを再構成する。ここで、受信機３０は、受信すべきＭＰＵの損失を検出すると、その損失したＭＰＵに対応する補完ＭＰＵ（損失したＭＰＵを補完するための補完ＭＰＵ）の配信を要求するリクエストを、第２の伝送路３を介してＷＥＢサーバ２０に送信する。受信機３０は、そのリクエストに応じてＷＥＢサーバ２０から第２の伝送路３を介して送信されてきた補完ＭＰＵを受信する。そして、受信機３０は、ＭＰＵおよび補完ＭＰＵをＭＰＵシーケンス番号順に復号して、映像・音声を再生する。

次に、放送設備１０および受信機３０の構成について説明する。なお、ＷＥＢサーバ２０は、映像・音声などの配信に用いられる一般的なサーバ装置であり、その構成は当業者によく知られているため、詳細な説明は省略する。まず、放送設備１０の構成について説明する。

図２は、放送設備１０の構成例を示す図である。図２においては、放送設備１０が、放送電波（無線電波）を用いた放送を行う場合の構成例を示す。

図２に示す放送設備１０は、符号化部としての映像・音声符号化装置１１と、映像・音声コンテンツサーバ１２と、制御情報生成部としての制御情報生成装置１３と、多重化部としての多重化装置１４と、再多重化装置１５と、通信機器１９とを備える。

放送設備１０から放送される番組に関する番組送出情報に基づき、放送される番組の映像・音声信号が映像・音声符号化装置１１に入力される。映像・音声符号化装置１１は、入力された映像・音声信号を所定の処理単位で符号化して生成したＭＰＵを多重化装置１４に出力する。

映像・音声コンテンツサーバ１２は、番組送出情報に基づき、放送される番組のデータ（番組内容データ、字幕データ、データ放送のデータなど）を多重化装置１４に出力する。

制御情報生成装置１３は、番組送出情報に含まれるメタデータ（番組タイトル、番組ＩＤ、放送日時など）と、番組の映像・音声を符号化したＭＰＵを補完する補完ＭＰＵを格納するＷＥＢサーバ２０のアドレス情報であるＵＲＬ（Uniform Resource Locator）情報とが入力される。制御情報生成装置１３は、入力されたメタデータおよびＷＥＢサーバ２０のＵＲＬ情報に基づき、補完ＭＰＵの格納先に関する基本ＵＲＬ情報を記述した制御情報を生成する。以下では、この制御情報をＭＰＵセグメント記述子と称する。

図３は、ＭＰＵセグメント記述子のデータ構造の一例を示す図である。なお、図３においては、補完ＭＰＵのビットレートが複数のビットレート（図３の例では、１０００ｋｂｐｓおよび２０００ｋｂｐｓ）の中から選択可能である例を示している。図３の例では、バイナリデータの構造体を定義しているが、同様の情報を記述したテキストデータを制御情報として伝送することも考えられる。例えば、制御情報の記述に用いられるテキストフォーマットとして、ＸＭＬ（Extensible Markup Language）やＪＳＯＮ（JavaScript (登録商標) Object Notation）などが知られている。

ＭＰＵセグメント記述子で記述される基本ＵＲＬ情報は、補完ＭＰＵの格納先のＵＲＬのテンプレート（テンプレートＵＲＬ（テンプレートアドレス））である。基本ＵＲＬ情報は、すべての補完ＭＰＵに共通の“ｂａｓｅ＿ＵＲＬ”と、補完ＭＰＵのビットレートに応じて異なるセグメントＵＲＬ（“ｓｅｇｍｅｎｔ＿ＵＲＬ”）とを含む。“ｂａｓｅ＿ＵＲＬ”には、補完ＭＰＵを格納するＷＥＢサーバ２０のＵＲＬ（例えば、“http://www.example.com/service1/”）が入力され、“ｓｅｇｍｅｎｔ＿ＵＲＬ”には、補完ＭＰＵのビットレートが１０００ｋｂｐｓである場合には、例えば、“1000kbps_segment/$Number$.m4s”が入力され、補完ＭＰＵのビットレートが２０００ｋｂｐｓである場合には、“2000kbps_segment/$Number$.m4s”が入力される。したがって、図３に示すＭＰＵセグメント記述子は、１０００ｋｂｐｓ用の“http://www.example.com/service1/1000kbps_segment/$Number$.m4s”と、２０００ｋｂｐｓ用の“http://www.example.com/service1/2000kbps_segment/$Number$.m4s”という２つの基本ＵＲＬ情報（テンプレートＵＲＬ）を記述する。このように、テンプレートＵＲＬは、補完ＭＰＵの複数のビットレートそれぞれに対応して設けられる。

補完ＭＰＵのテンプレートＵＲＬのうち、“$Number$”の部分は、補完ＭＰＵのＭＰＵシーケンス番号、すなわち、補完ＭＰＵに対応するＭＰＵのＭＰＵシーケンス番号に応じて予め定められた規則に従い置き換えられる。したがって、テンプレートＵＲＬは、各補完セグメントに共通の共通部（図３の例では、“http://www.example.com/service1/”および“.m4s”）と、セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部（図３の例では、“$Number$”）とを含む。

補完ＭＰＵの格納先のＵＲＬは、各補完ＭＰＵで異なる必要がある。本実施形態においては、テンプレートＵＲＬの置換部を、ＭＰＵシーケンス番号に応じて置き換えることで、各補完ＭＰＵの格納先のＵＲＬを異ならせることができる。

なお、図３においては、補完ＭＰＵのビットレートが複数のビットレートの中から選択可能である例を示しているが、補完ＭＰＵのビットレートは１つだけであってもよい。

図２を再び参照すると、制御情報生成装置１３は、生成した制御情報（ＭＰＵセグメント記述子）を多重化装置１４に出力する。

多重化装置１４は、映像・音声符号化装置１１から出力されたＭＰＵと、映像・音声コンテンツサーバ１２から出力されたデータと、制御情報生成装置１３から出力されたＭＰＵセグメント記述子（基本ＵＲＬ情報）とを多重化してＭＭＴパケットのペイロードに格納し、そのＭＭＴパケットをＩＰパケット化して再多重化装置１５および通信機器１９に出力する。なお、ＭＭＴパケットには、そのＭＭＴパケットに格納されるＭＰＵのＭＰＵシーケンス番号も格納される。

再多重化装置１５は、１または複数の階層それぞれに対応して設けられた多重化装置１４からの出力を１系統に多重化し、ＳＴＬ（Studio to Transmitter Link）回線を介して、送信所設備１６に送信する。

送信所設備１６は、再多重化装置１５から送信されたＩＰパケットを受信し、第１の伝送路２を介して受信機３０に伝送する。送信所設備１６は、放送波変調装置１７と、送信機１８とを備える。

放送波変調装置１７は、再多重化装置１５の出力を変調して放送波を生成し、送信機１８に出力する。送信機１８は、放送波変調装置１７から出力された放送波を第１の伝送路２を介して伝送する。放送波変調装置１７および送信機１８により構成される送信所設備１６は、第１の伝送路２を介して放送を行う送信部に相当する。多重化装置１４から出力されたＩＰパケットは、再多重化装置１５を介して送信所設備１６に入力される。したがって、多重化装置１４は、セグメント（ＭＰＵ）と、基本ＵＲＬ情報に示されるテンプレートアドレス（テンプレートＵＲＬ）とを多重化し、第１の伝送路２を介して放送を行う送信所設備１６（送信部）に出力する多重化部に相当する。

通信機器１９は、多重化装置１４の出力を、ＩＰ回線を介して、ＷＥＢサーバ２０に送信する。通信機器１９は、例えば、スイッチ、ルータ、回線終端装置などである。

図２においては、ＷＥＢサーバ２０が、ＷＥＢサーバ２１と、ＷＥＢサーバ２１とＣＤＮ網を介して接続された複数のＷＥＢサーバ２２とからなる例を示している。ＷＥＢサーバ２１は、放送設備１０から出力されたＭＰＵを格納するオリジンサーバである。したがって、テンプレートＵＲＬの共通部には、ＷＥＢサーバ２１のアドレスが入力される。ＷＥＢサーバ２２は、第２の伝送路３を介して受信機３０と通信を行うエッジサーバである。ＷＥＢサーバ２２は、受信機３０からのリクエストに応じて、ＷＥＢサーバ２１に格納されている補完ＭＰＵを取得し、受信機３０に送信する。なお、ＷＥＢサーバ２１は、放送設備１０に設けられてもよい。

図４は、放送設備１０の他の構成例を示す図である。図４においては、放送設備１０が、５Ｇなどの通信インフラを用いたＩＰ放送を行う場合の構成例である。図４において、図２と同様の構成については同じ符号を付し、説明を省略する。

図４に示す放送設備１０は、図２に示す放送設備１０と比較して、再多重化装置１５を削除して、通信機器１９Ａを追加した点が異なる。

通信機器１９Ａは、多重化装置１４の出力（ＩＰパケット）を、広域通信網である広域バックボーンを介して、複数のヘッドエンド設備１６Ａに送信する。通信機器１９Ａは、例えば、スイッチ、ルータ、回線終端装置などである。

ヘッドエンド設備１６Ａは、通信機器１９Ａから送信されたＩＰパケットを受信し、地域毎の地域アクセス網などのＩＰネットワーク（第１の伝送路２）を介して受信機３０に伝送する。ヘッドエンド設備１６Ａは、放送サービスを提供するエリア内の地域アクセス網ごとに設けられている。ヘッドエンド設備１６Ａは、通信機器１７Ａと、収容装置１８Ａとを備える。

通信機器１７Ａは、通信機器１９Ａから送信されたＩＰパケットを受信し、収容装置１８Ａに出力する。通信機器１７Ａは、例えば、スイッチ、ルータ、回線終端装置などである。収容装置１８Ａは、通信機器１７Ａから出力されたＩＰパケットを、地域アクセス網を介して、受信機３０に伝送する。通信機器１７Ａおよび収容装置１８Ａにより構成されるヘッドエンド設備１６Ａは、第１の伝送路２を介して放送を行う送信部に相当する。多重化装置１４から出力されたＩＰパケットは、再多重化装置１５を介してヘッドエンド設備１６Ａに入力される。したがって、多重化装置１４は、セグメント（ＭＰＵ）と、基本ＵＲＬ情報に示されるテンプレートアドレス（テンプレートＵＲＬ）とを多重化し、第１の伝送路２を介して放送を行うヘッドエンド設備１６Ａ（送信部）に出力する多重化部に相当する。

次に、受信機３０の構成について説明する。

図５は、本実施形態に係る受信機３０の構成例を示す図である。

図５に示す受信機３０は、放送インタフェース部３１と、第１の取得部としての放送多重分離部３２と、生成部としてのリクエストＵＲＬ生成部３３と、通信インタフェース部３４と、第２の取得部としてのＨＴＴＰ（Hypertext Transfer Protocol）クライアント部３５と、通信多重分離部３６と、ＭＰＵバッファ部３７と、映像・音声復号部３８とを備える。

放送インタフェース部３１は、放送設備１０により第１の伝送路２を介して伝送される放送信号を受信するためのインタフェースである。具体的には、放送インタフェース部３１は、放送設備１０から第１の伝送路２を介して伝送された放送信号を受信し、受信した放送信号を復調してＩＰパケットを取得し、放送多重分離部３２に出力する。上述したように、放送設備１０から伝送されるＩＰパケットは、ＭＰＵおよびＭＰＵセグメント記述子などが格納されている。また、ＩＰパケットには、ＭＰＵシーケンス番号も格納されている。

放送多重分離部３２は、放送インタフェース部３１から出力されたＩＰパケットを取得し、取得したＩＰパケットからＭＰＵを再構成する。ここで、放送多重分離部３２は、受信パケット列のパケットシーケンス番号の連続性を確認することで、ＭＰＵの破損の有無を検査する。また、放送多重分離部３２は、再構成したＭＰＵのＭＰＵシーケンス番号の連続性を確認し、ＭＰＵの欠落の有無を検査する。また、放送多重分離部３２は、一定の時間、新たなＭＰＵが再構成されない場合には、放送の受信断を検知する。放送多重分離部３２は、再構成したＭＰＵ単位の映像・音声の符号データをＭＰＵバッファ部３７に出力する。ここで、放送多重分離部３２は、再構成したＭＰＵの破損を検出した場合には、そのＭＰＵについてはＭＰＵバッファ部３７に出力せず、破棄する。

放送多重分離部３２は、ＭＰＵの破損、ＭＰＵの欠落あるいは放送の受信断による受信すべきＭＰＵの損失を検出すると、損失したＭＰＵのＭＰＵシーケンス番号と、ＭＰＵセグメント記述子に記述された基本ＵＲＬ情報（テンプレートＵＲＬ）とをリクエストＵＲＬ生成部３３に出力する。なお、損失したＭＰＵとは、破損したＭＰＵ、欠落したＭＰＵ、あるいは、受信断の直前に取得したＭＰＵの次のＭＰＵシーケンス番号のＭＰＵである。

上述したように、基本ＵＲＬ情報（テンプレートＵＲＬ）は、各補完ＭＰＵに共通の共通部と、ＭＰＵに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部（図３の例では、“$Number$”）とを含む。リクエストＵＲＬ生成部３３は、放送多重分離部３２から出力されたＭＰＵシーケンス番号と、テンプレートＵＲＬとに基づき、損失したＭＰＵに対応する補完ＭＰＵの格納先を示すリクエストＵＲＬ（リクエストアドレス）を生成する。具体的には、リクエストＵＲＬ生成部３３は、放送多重分離部３２から出力されたＭＰＵシーケンス番号に応じて、予め定められた規則に従い、テンプレートＵＲＬの置換部を置き換えてリクエストＵＲＬを生成する。

図３の例では、リクエストＵＲＬ生成部３３は、ビットレートが１０００ｋｂｐｓの補完ＭＰＵを要求する場合、損失したＭＰＵのＭＰＵシーケンス番号に基づき、１０００ｋｂｐｓ用のテンプレートＵＲＬ“http://www.example.com/service1/1000kbps_segment/$Number$.m4s”の置換部である“$Number$”を、予め定められた規則に従い置き換えて、リクエストＵＲＬを生成する。また、リクエストＵＲＬ生成部３３は、ビットレートが２０００ｋｂｐｓの補完ＭＰＵを要求する場合、損失したＭＰＵのＭＰＵシーケンス番号に基づき、２０００ｋｂｐｓ用のテンプレートＵＲＬ“http://www.example.com/service1/2000kbps_segment/$Number$.m4s”の置換部である“$Number$”を、予め定められた規則に従い置き換えて、リクエストＵＲＬを生成する。例えば、取得する補完ＭＰＵのビットレートが１０００ｋｂｐｓであり、ＭＰＵシーケンス番号が１００番である場合、リクエストＵＲＬ生成部３３は、１０００ｋｂｐｓ用のテンプレートＵＲＬ“http://www.example.com/service1/1000kbps_segment/$Number$.m4s”の置換部である“$Number$”を、“100”に置き換えた“http://www.example.com/service1/1000kbps_segment/100.m4s”という文字列をリクエストＵＲＬとして生成する。なお、置換部としては、“$Number$”の他にも、“%d”あるいは“*”など、送信側と受信側とで予め定められた任意の文字列を用いることができる。放送型のサービスにおいては、この置換部として扱う文字列を予め運用仕様として定め、サービスに対応する全ての受信機において既知のものとすることが考えられる。

リクエストＵＲＬ生成部３３は、生成したリクエストＵＲＬをＨＴＴＰクライアント部３５に出力する。

通信インタフェース部３４は、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ、ＵＳＢ（Universal Serial Bus）など種々の通信方式、通信規格に従い、双方向伝送路である第２の伝送路３を介してＷＥＢサーバ２０と通信を行うためのインタフェースである。

ＨＴＴＰクライアント部３５は、リクエストＵＲＬ生成部３３から出力されたリクエストＵＲＬを用いて、通信インタフェース部３４を経由して、双方向伝送路である第２の伝送路３を介して、損失したＭＰＵに対応する補完ＭＰＵをＷＥＢサーバ２０から取得する。

具体的には、ＨＴＴＰクライアント部３５は、リクエストＵＲＬを用いて、損失したＭＰＵに対応する補完ＭＰＵの配信を要求するリクエストを、通信インタフェース部３４を経由して、第２の伝送路３を介して、ＷＥＢサーバ２０に送信する。そして、ＨＴＴＰクライアント部３５は、そのリクエストに応じて第２の伝送路３を介してＷＥＢサーバ２０から送信されてきた補完ＭＰＵを、通信インタフェース部３４を経由して取得する。

ＷＥＢサーバ２０からファイルを取得するためのプロトコルとして、現在では、ＨＴＴＰ／ＴＣＰ（Transmission Control Protocol）あるいはＨＴＴＰＳ（HTTP over Secure Socket）／ＴＣＰの利用が一般的である。ＨＴＴＰクライアント部３５は、例えば、これらのプロトコルを用いて、補完ＭＰＵをＷＥＢサーバ２０から取得する。なお、セキュリティ意識の高まりから、個人情報および機密情報などの秘匿性の高い情報を含まない通信にも、通信内容を暗号化して保護するＨＴＴＰＳが常時使用されることが多くなっている。ＨＴＴＰおよびＴＣＰを改良したプロトコルとして、ＨＴＴＰ２およびＱＵＩＣ（Quick UDP Internet Connections）などが開発され、徐々に利用され始めている。ＱＵＩＣは、ＵＤＰを用いて、低遅延かつ信頼性の高い双方向接続を行うプロトコルである。ＨＴＴＰクライアント部３５は、例えば、ＱＵＩＣとＨＴＴＰ２とを組み合わせて、補完ＭＰＵをＷＥＢサーバ２０から取得してもよい。

ＨＴＴＰクライアント部３５は、取得した補完ＭＰＵを通信多重分離部３６に出力する。

通信多重分離部３６は、ＨＴＴＰクライアント部３５から出力された補完ＭＰＵをＭＰＵバッファ部３７に出力する。具体的には、通信多重分離部３６は、補完ＭＰＵのファイルフォーマットがＩＳＯＢＭＦＦ形式である場合には、ＩＳＯＢＭＦＦ形式のデータ構造から映像・音声の符号データを分離してＭＰＵバッファ部３７に出力する。

ＭＰＵバッファ部３７は、放送多重分離部３２から出力されたＭＰＵ単位の映像・音声の符号データを、ＭＰＵシーケンス番号順に格納し、所定の蓄積時間だけ蓄積した後、格納順に映像・音声復号部３８に出力する。ここで、ＭＰＵバッファ部３７は、通信多重分離部３６から補完ＭＰＵの映像・音声の符号データが出力されると、その補完ＭＰＵに対応するＭＰＵのＭＰＵシーケンス番号の位置に、補完ＭＰＵの映像・音声の符号データを割り込ませ、映像・音声復号部３８に出力する。したがって、映像・音声復号部３８には、取得経路に関係なく、ＭＰＵシーケンス番号の順に整列したＭＰＵ単位の映像・音声の符号化データが入力される。

映像・音声復号部３８は、ＭＰＵバッファ部３７から出力された映像・音声の符号化データを順に復号する。上述したように、映像・音声復号部３８には、ＭＰＵシーケンス番号の順に整列した映像・音声の符号化データが入力されるので、シームレスな復号処理が可能となる。

一般に、ＭＰＵは、概ね一定周期の時間で区切られた映像・音声のデータを含む。そのため、本線信号（第１の伝送路２からの信号）が完全に途絶えた場合にも、ＭＰＵの更新周期で定期的に、第２の伝送路３を介して新しいＭＰＵに対応する補完ＭＰＵを取得することで、放送サービスの視聴が可能となる。例えば、毎秒６０フレームの映像信号において、３２フレームを１つのＭＰＵとする場合、映像のＭＰＵの更新周期はおよそ０．５３３秒となる。一定周期で新しい補完ＭＰＵを取得する以外の方法として、ＭＰＵバッファ部３７内にバッファされるＭＰＵの数が常に一定数になるように、映像・音声復号部３８に１つのＭＰＵを出力したタイミングで新しい補完ＭＰＵをひとつ取得する方法も考えられる。また、映像と音声のＭＰＵの更新周期を互いに異なる時間とする場合、音声のＭＰＵの更新周期には一般に、映像のＭＰＵの更新周期よりも短い時間が用いられる。ＭＰＵをＩＳＯＢＭＦＦ形式のファイルに変換する際には、映像のＭＰＵと音声のＭＰＵとをそれぞれ個別のファイルとして処理することも、１つの映像のＭＰＵと複数の音声のＭＰＵとを多重化して１つのファイルとして処理することも可能である。また、複数の映像のＭＰＵと、複数の音声のＭＰＵとを多重化して１つのファイルとして処理することも可能である。

このように本実施形態においては、放送設備１０は、放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたセグメントを生成する映像・音声符号化装置１１（符号化部）と、セグメントを補完する補完セグメントを格納し、格納する補完セグメントを双方向伝送路である第２の伝送路３を介して受信機３０に伝送するＷＥＢサーバ２０（サーバ装置）のアドレス情報に基づき、各補完セグメントに共通の共通部と、セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含む、補完セグメントの格納先を示すテンプレートアドレス（テンプレートＵＲＬ）を生成する制御情報生成装置１３（制御情報生成部）と、セグメントおよびテンプレートアドレスを多重化し、第１の伝送路２を介して放送を行う送信部（送信所設備１６、ヘッドエンド設備１６Ａ）に出力する多重化装置１４（多重化部）とを備える。

また、受信機３０は、第１の伝送路２を介して伝送された、セグメントと、セグメントを補完する補完セグメントの格納先を示し、各補完セグメントに共通の共通部と、セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含むテンプレートアドレスとを取得し、取得すべきセグメントの損失を検出する放送多重分離部３２（第１の取得部）と、放送多重分離部３２により検出された損失したセグメントに割り当てられたシーケンス番号に基づき、予め定められた規則に従いテンプレートアドレスの置換部を置き換えて、損失したセグメントに対応する補完セグメントの格納先を示すリクエストアドレスを生成するリクエストＵＲＬ生成部３３（生成部）と、生成されたリクエストアドレスを用いて、双方向伝送路である第２の伝送路３を介して、損失したセグメントに対応する補完セグメントをＷＥＢサーバ２０（サーバ装置）から取得するＨＴＴＰクライアント部３５（第２の取得部）と、を備える。

セグメントが損失した場合、損失したセグメントのシーケンス番号に基づき、テンプレートアドレスの置換部を置き換えてリクエストＵＲＬを生成し、そのリクエストＵＲＬを用いて、損失したセグメントに対応する補完セグメントをＷＥＢサーバ２０から取得することで、放送サービスにおいて、映像・音声の途切れおよび乱れを防ぎ、サービス品質の向上を図ることができる。また、セグメントを処理単位とするため、ＩＰパケットあるいはＭＭＴパケットを処理単位とする場合と異なり、ＣＤＮ網のような汎用的なコンテンツ配信基盤を利用して、サービス品質の向上を図ることができる。

なお、本実施形態においては、受信機３０が、第１の伝送路２を介して放送設備１０から伝送された放送信号を受信する放送インタフェース部３１を備える（放送インタフェース部３１を内蔵する）例を用いて説明したが、これに限られるものではない。

図６は、受信機３０の他の構成例を示す図である。

図６に示す受信機３０は、図５に示す受信機３０と比較して、放送インタフェース部３１を削除した点と、通信インタフェース部３４を通信インタフェース部３４ａに変更した点とが異なる。また、図６においては、受信機３０の外部に設けられ、第１の伝送路２を介して放送設備１０から伝送される放送信号を受信し、受信した放送信号を復調してＩＰパケットを取得する放送インタフェース部３１ａが設けられている点が異なる。放送インタフェース部３１ａは、例えば、受信機３０に取り付け可能な外付けチューナである。その他にも、宅内ＬＡＮに接続されて受信機３０にＩＰパケットを中継可能なテレビや単体チューナ、ＬＴＥなどの無線通信基地局に設置され受信機３０にＩＰパケットを中継可能な放送受信設備など、さまざまな形態をとり得る。

通信インタフェース部３４ａは、通信インタフェース部３４と同様に、第２の伝送路３を介してＷＥＢサーバ２０と通信を行う。また、通信インタフェース部３４ａは、有線ＬＡＮ、無線ＬＡＮ、ＵＳＢなど種々の通信方式、通信規格に従い、放送インタフェース部３１ａと通信を行い、放送インタフェース部３１ａからＩＰパケットを取得する。

図６に示すように、受信機３０は、放送インタフェース部３１を内蔵せず、外部の放送インタフェース部３１ａから、放送設備１０から伝送されたＩＰパケットを取得してもよい。

（第２の実施形態）
図７は、本発明の第２の実施形態に係る受信機３０Ａの構成例を示す図である。図７において、図５と同様の構成については同じ符号を付し、説明を省略する。

図７に示す受信機３０Ａは、図５に示す受信機３０と比較して、記憶部としての基本ＵＲＬ情報キャッシュ部４１を追加した点と、リクエストＵＲＬ生成部３３をリクエストＵＲＬ生成部３３Ａに変更した点とが主に異なる。なお、本実施形態においては、放送多重分離部３２は、基本ＵＲＬ情報をリクエストＵＲＬ生成部３３Ａと、基本ＵＲＬ情報キャッシュ部４１とに出力する。

基本ＵＲＬ情報キャッシュ部４１は、放送多重分離部３２から出力された基本ＵＲＬ情報（テンプレートＵＲＬ）をキャッシュする。具体的には、基本ＵＲＬ情報キャッシュ部４１は、最後に放送を受信した際に取得したＭＰＵセグメント記述子から得られた基本ＵＲＬ情報を受信終了後も保持する。

最後の放送の受信終了後、受信機能が再び起動された際に、放送を受信できず、第１の伝送路２を介して伝送される最新のＭＰＵのＭＰＵシーケンス番号を取得することができない場合がある。この場合、受信機３０は、最新のＭＰＵのＭＰＵシーケンス番号が分からないため、最新のＭＰＵに対応する補完ＭＰＵの配信をＷＥＢサーバ２０に要求することができない。

リクエストＵＲＬ生成部３３Ａは、第１の伝送路２を介した放送を受信することができず、第１の伝送路２を介して伝送される最新のＭＰＵのＭＰＵシーケンス番号を取得することができない場合、基本ＵＲＬ情報キャッシュ部４１にキャッシュされた基本ＵＲＬ情報を読み出す。そして、リクエストＵＲＬ生成部３３Ａは、読み出した基本ＵＲＬ情報に基づき、最新の補完ＭＰＵのＭＰＵシーケンス番号を記述したファイルの格納先を示すリクエストＵＲＬを生成する。なお、ＷＥＢサーバ２０は、放送設備１０からのＭＰＵの出力に応じて、最新の補完ＭＰＵのＭＰＵシーケンス番号を記述したファイルを更新し、記憶している。

図８は、本実施形態におけるＭＰＵセグメント記述子のデータ構造の一例を示す図である。

図８に示すように、本実施形態においては、最新の補完ＭＰＵのシーケンス番号を記述したファイルの格納先を指定する“ｓｅｑｕｅｎｃｅ＿ｎｕｍ＿ＵＲＬ”に関する定義が追加されている。

リクエストＵＲＬ生成部３３Ａは、共通部である“Ｂａｓｅ＿ＵＲＬ”に、“ｓｅｑｕｅｎｃｅ＿ｎｕｍ＿ＵＲＬ”として送信側と受信側とで共有されるファイル名（最新の補完ＭＰＵのＭＰＵシーケンス番号を記述したファイルのファイル名）を連結して、リクエストＵＲＬを生成する。具体的には、リクエストＵＲＬ生成部３３Ａは、“Ｂａｓｅ＿ＵＲＬ”（例えば、“http://www.example.com/service1/”）に、“ｓｅｑｕｅｎｃｅ＿ｎｕｍ＿ＵＲＬ”（例えば、“sequence_number”）を連結した“http://www.example.com/service1/ sequence_number”をリクエストＵＲＬとして生成する。図８では、ＭＰＵセグメント記述子に“ｓｅｑｕｅｎｃｅ＿ｎｕｍ＿ＵＲＬ”に関する定義を追加したが、図３の構造を用いて“ｓｅｑｕｅｎｃｅ＿ｎｕｍ＿ＵＲＬ”に相当する文字列を既知のものとすることも考えられる。放送型のサービスにおいては、この文字列を予め運用仕様として定め、サービスに対応する全ての受信機において既知のものとすることが考えられる。

リクエストＵＲＬ生成部３３Ａは、生成したリクエストＵＲＬをＨＴＴＰクライアント部３５に出力する。ＨＴＴＰクライアント部３５は、第１の実施形態と同様に、リクエストＵＲＬにより格納先が示されるファイル（最新の補完ＭＰＵのＭＰＵシーケンス番号を記述したファイル）をＷＥＢサーバ２０から取得する。リクエストＵＲＬ生成部３３Ａは、このファイルを参照し、最新の補完ＭＰＵシーケンス番号の補完ＭＰＵの配信を要求するリクエストＵＲＬを生成する。

なお、本線信号のプロトコルにＭＭＴを用いる場合、テンプレートＵＲＬの伝送方法として、上述したＭＰＵセグメント記述子の他に、MMT_general_location_infoのlocation_type=0x05の構造を用いてもよい。この場合、テンプレートＵＲＬ全体が１つの文字列として伝送される。例えば、“http://www.example.com/service1/1000kbps_segment/$Number$.m4s”が１つの文字列として伝送される。

MMT_general_location_infoでは、複数のロケーションを併記することができる。そのため、ビットレートの異なる複数の補完ＭＰＵの格納先のＵＲＬを併記してもよい。ただし、この場合、受信機３０が所望のビットレートの補完ＭＰＵがどのＵＲＬに格納されるかを判断するために、テンプレートＵＲＬの文字列からビットレートを判断するための、送信側と受信側とで予め既知の規則を設ける必要がある。テンプレートＵＲＬの伝送には、ＭＰＵセグメント記述子およびMMT_general_location_infoの両方が用いられてもよいし、いずれか一方が用いられてもよい。

また、本実施形態においては、受信機３０は、最新の補完ＭＰＵシーケンス番号を記述したファイルを取得し、その後、そのファイルに基づき、最新の補完ＭＰＵシーケンス番号の補完ＭＰＵを取得するためのリクエストＵＲＬを生成する例を用いて説明したが、これに限られるものではない。

例えば、ＷＥＢサーバ２０は、特定のＵＲＬ（例えば、“http://www.example.com/service1/1000kbps_segment/latest.m4s”）により最新の補完ＭＰＵシーケンス番号のＭＰＵを要求するリクエストを受信機３０から受信すると、最新のＭＰＵシーケンス番号の補完ＭＰＵを受信機３０に送信してもよい。こうすることで、ＷＥＢサーバ２０と受信機３０との間の通信を減らすことができる。この場合、ＷＥＢサーバ２０に、最新の補完ＭＰＵシーケンス番号を記述したファイルを参照し、最新のＭＰＵシーケンス番号の補完ＭＰＵを特定して、受信機３０に送信する機能を搭載する必要がある。また、最新のＭＰＵシーケンス番号を取得するためのＵＲＬについて、ＭＰＵセグメント記述子に定義を追加するか、“Ｂａｓｅ＿ＵＲＬ”に追加する文字列をサービスの運用仕様として既知のものとする必要が考えられる。

このように本実施形態においては、受信機３０Ａは、放送多重分離部３２が取得した基本ＵＲＬ情報（テンプレートＵＲＬ）をキャッシュする基本ＵＲＬ情報キャッシュ部４１（記憶部）をさらに備える。リクエストＵＲＬ生成部３３Ａは、第１の伝送路２を介して伝送される最新のセグメントのシーケンス番号を取得することができない場合、テンプレートＵＲＬの共通部に予め定められた所定の文字列を付加した、最新の補完セグメントのシーケンス番号を記述したファイルの格納先を示すリクエストＵＲＬを生成する。また、ＨＴＴＰクライアント部３５は、リクエストＵＲＬ生成部３３Ａにより生成されたリクエストＵＲＬを用いて、第２の伝送路３を介して、最新の補完セグメントのシーケンス番号を示すファイルをＷＥＢサーバ２０から取得する。

こうすることで、第１の伝送路２を介して最新のＭＰＵシーケンス番号を取得することができない場合にも、第２の伝送路３を介して最新の補完ＭＰＵのＭＰＵシーケンス番号を取得することができる。

（第３の実施形態）
図９は、本発明の第３の実施形態に係る受信機３０Ｂの構成例を示す図である。図９において、図５と同様の構成については同じ符号を付し、説明を省略する。

図９に示す受信機３０Ｂは、図５に示す受信機３０と比較して、事前ＤＮＳ（Domain Name System）解決部４２と、事前ＴＣＰ接続部４３とを追加した点が主に異なる。なお、本実施形態においては、放送多重分離部３２は、基本ＵＲＬ情報（テンプレートＵＲＬ）をリクエストＵＲＬ生成部３３と、事前ＤＮＳ解決部４２と、事前ＴＣＰ接続部４３とに出力する。

事前ＤＮＳ解決部４２は、リクエストＵＲＬ生成部３３によるリクエストＵＲＬの生成の有無に関わらず、すなわち、受信品質の低下などによるＭＰＵの損失の有無に関わらず、基本ＵＲＬ情報に示されるＷＥＢサーバ２０のドメイン名を問い合わせる名前解決リクエストを、通信インタフェース部３４を経由して、ＤＮＳサーバ４に送信する。そして、事前ＤＮＳ解決部４２は、名前解決リクエストに応じてＤＮＳサーバ４から取得したドメイン名をＩＰアドレスに変換して保存しておく。例えば、事前ＤＮＳ解決部４２は、“www.example.com”のようなＷＥＢサーバ２０のドメイン名を、「１９２．１６８．１００．１００」、「２００１：：３５」のようなＩＰアドレスに変換する。

事前ＴＣＰ接続部４３は、リクエストＵＲＬ生成部３３によるリクエストＵＲＬの生成の有無に関わらず、すなわち、受信品質の低下などによるＭＰＵの損失の有無に関わらず、基本ＵＲＬ情報に示されるＷＥＢサーバ２０に対してＴＣＰ接続を行い、接続状態を維持する。事前ＴＣＰ接続部４３は、ＷＥＢサーバ２０との接続状態を維持するために、ＴＣＰ接続確立後も継続して定期的な通信を行ってもよい。

事前ＤＮＳ解決部４２によるＤＮＳ名前解決および事前ＴＣＰ接続部４３によるＴＣＰ接続は、受信機３０がＷＥＢサーバ２０からファイルを取得するために必要な前処理である。したがって、事前ＤＮＳ解決部４２および事前ＴＣＰ接続部４３は、リクエストＵＲＬ生成部３３によるリクエストＵＲＬの生成の有無に関わらず、ＷＥＢサーバ２０からファイルを取得するための前処理を予め行う前処理部４４を構成する。

受信機３０のＭＰＵバッファ部３７には、ＷＥＢサーバ２０と受信機３０との通信による補完ＭＰＵの取得における遅延時間の最大値を想定した蓄積時間が必要となる。一般に、ＨＴＴＰあるいはＨＴＴＰＳによるファイル取得では、初めにＷＥＢサーバ２０に接続する際に、ＤＮＳ名前解決、ＴＣＰ接続などの複数の手続きを要する。そのため、ファイル取得の完了までに大きな遅延時間が生じる。

そこで、本実施形態のように、前処理部４４により、リクエストＵＲＬの生成の有無に関わらず、ＷＥＢサーバ２０からファイルを取得するための前処理を予め行うことで、リクエストＵＲＬの生成後、補完ＭＰＵの取得完了までの遅延時間を短くすることができる。その結果、ＭＰＵバッファ部３７の蓄積時間も短くすることができる。

なお、図９においては、受信機３０Ｂは、事前ＤＮＳ解決部４２および事前ＴＣＰ接続部４３の両者を備える例を用いて説明したが、これに限られるものではない。ＴＣＰ接続を行うためにはＤＮＳ名前解決が必要であるため、事前ＴＣＰ接続部４３が事前ＤＮＳ解決部４２を内包していてもよい。また、受信機３０Ｂは、事前ＴＣＰ接続部４３を備えず、事前ＤＮＳ解決部４２だけを備えた構成としてもよい。

また、ＷＥＢサーバ２０からのファイル取得にＨＴＴＰＳが用いられる場合、事前ＴＣＰ接続部４３は、ＳＳＬ（Secure Sockets Layer）あるいはＴＬＳ（Transport Layer Security）の認証処理を行ってもよい。

（第４の実施形態）
図１０は、本発明の第４の実施形態に係る受信機３０Ｃの構成例を示す図である。図１０において、図９と同様の構成については同じ符号を付し、説明を省略する。

図１０に示す受信機３０Ｃは、図９に示す受信機３０Ｂと比較して、受信品質測定部４５を追加した点と、事前ＤＮＳ解決部４２および事前ＴＣＰ接続部４３をそれぞれ、事前ＤＮＳ解決部４２Ｃおよび事前ＴＣＰ接続部４３Ｃに変更した点とが異なる。

受信品質測定部４５は、放送インタフェース部３１による、第１の伝送路２を介した放送設備１０からの放送の受信品質（受信電界強度、受信ＣＮ比など）を測定し、測定結果を示す受信品質情報を事前ＤＮＳ解決部４２Ｃおよび事前ＴＣＰ接続部４３Ｃに出力する。

事前ＤＮＳ解決部４２Ｃは、受信品質測定部４５により測定された受信品質が、放送サービスの視聴に必要な所定の受信品質よりも所定値だけ高い閾値を下回ると、ＤＮＳ名前解決を行う。また、事前ＴＣＰ接続部４３Ｃは、受信品質測定部４５により測定された受信品質が、放送サービスの視聴に必要な所定の受信品質よりも所定値だけ高い閾値を下回ると、ＴＣＰ接続を行う。したがって、事前ＤＮＳ解決部４２Ｃおよび事前ＴＣＰ接続部４３Ｃは、受信品質測定部４５により測定された受信品質が、放送サービスの視聴に必要な所定の受信品質より所定値だけ高い閾値を下回ると、ＷＥＢサーバ２０からファイルを取得するための前処理を予め行う前処理部４４Ｃを構成する。

第３の実施形態のように、リクエストＵＲＬ生成部３３によるリクエストＵＲＬの生成の有無に関わらず無条件にＤＮＳ名前解決およびＴＣＰ接続などの前処理を行う場合、補完ＭＰＵの取得が必要とならなかった場合には、これらの処理は無駄となる。その結果、例えば、受信機３０の消費電力や通信量の増大を招いてしまう。

一方、本実施形態では、測定された受信品質が、放送サービスの視聴に必要な所定の受信品質よりも所定値だけ高い閾値を下回ると、ＤＮＳ名前解決およびＴＣＰ接続などの前処理を行う。そのため、受信品質がある程度低下し、補完ＭＰＵの取得が必要になることが予測される場合に、ＤＮＳ名前解決およびＴＣＰ接続などの前処理を行うことで、受信機３０の消費電力の増大などの無駄の発生を抑制しつつ、リクエストＵＲＬの生成後、補完ＭＰＵの取得完了までの遅延時間を短くすることができる。

上述した各実施形態は適宜、組み合わせることが可能である。例えば、受信機３０Ｂおよび受信機３０Ｃがそれぞれ、基本ＵＲＬ情報キャッシュ部４１およびリクエストＵＲＬ生成部３３Ａを備えていてもよい。また、受信機３０Ａ，受信機３０Ｂおよび受信機３０Ｃがそれぞれ、放送インタフェース部３１を内蔵せず、図６に示すように、放送インタフェース部３１ａが外付けされる構成を有していてもよい。

また、上述した各実施形態において、ＭＰＵバッファ部３７の蓄積時間として、予めＨＴＴＰあるいはＨＴＴＰＳによる補完ＭＰＵの取得に要する遅延時間を想定した固定値を設定することが考えられる。しかしながら、蓄積時間を超える遅延が生じた場合などには、状況に応じて蓄積時間を変化させてもよい。この場合、表示フレームレートを変化させず、一時的なフリーズあるいはフレームドロップを許容する方法、あるいは、表示フレームレートを動的に調整して、フリーズあるいはフレームドロップを起こさずに調整する方法を用いることが考えられる。

ＭＰＵバッファ部３７の蓄積時間を動的に変化させる１つの例として、受信機３０の受信機能の起動時に本線信号（第１の伝送路２を介して伝送される放送信号）を受信することができる場合には、ＭＰＵバッファ部３７の蓄積時間を、補完ＭＰＵの取得を想定した蓄積時間を加えない最短の蓄積時間とし、はじめて補完ＭＰＵの取得が必要となったときに、一時的に音声・映像をフリーズさせて、補完ＭＰＵの取得に要する時間Ｔの分だけ、ＭＰＵバッファ部３７の蓄積時間を拡張するという例が考えられる。一般に、双方向伝送路におけるファイルの取得時間は変動する。そのため、補完ＭＰＵの取得に要する時間Ｔに対して倍率α（≧１）を掛け合わせた、αＴ秒だけＭＰＵバッファ部３７の蓄積時間を拡張することも考えられる。この場合、後続の補完ＭＰＵの取得時間Ｔ’がαＴ以下（Ｔ’≦αＴ）であれば、映像・音声を再びフリーズさせてＭＰＵバッファ部３７の蓄積時間を拡張する必要が無くなる。

また、上述した各実施形態においては、ＷＥＢサーバ２０からの補完ＭＰＵの取得のために双方向伝送路である第２の伝送路３で用いるプロトコルがＨＴＴＰ（Ｓ）／ＴＣＰである例を用いて説明したが、これに限られるものではなく、ＨＴＴＰ２（ＨＴＴＰ ｖｅｒｓｉｏｎ２）／ＴＣＰ、ＨＴＴＰ２／ＱＵＩＣ／ＵＤＰなどのプロトコルを用いてもよい。ＨＴＴＰ２を用いる場合には、ＨＴＴＰクライアント部３５は、ＨＴＴＰ２に従い、ＷＥＢサーバ２０と通信を行うことで、補完ＭＰＵを取得する。また、ＱＵＩＣを用いる場合には、ＴＣＰを用いないため、事前ＴＣＰ接続部４３，４３Ｃは、事前ＱＵＩＣ接続を行う。また、ＱＵＩＣを用いる場合には、事前ＴＣＰ接続部４３，４３Ｃは、ＴＬＳによる認証処理を行ってもよい。ＨＴＴＰ２／ＱＵＩＣ／ＵＤＰを用いる場合、ＨＴＴＰ（Ｓ）／ＴＣＰを用いる場合と比べて、ファイル取得の低遅延化を図ることができるので、ＭＰＵバッファ部３７の蓄積時間を短くし、映像・音声の再生の遅延時間を低減することができる。

以上、受信機３０，３０Ａ，３０Ｂ，３０Ｃについて説明したが、受信機３０，３０Ａ，３０Ｂ，３０Ｃとして機能させるために、コンピュータを用いることも可能である。そのようなコンピュータは、受信機３０，３０Ａ，３０Ｂ，３０Ｃの各機能を実現する処理内容を記述したプログラムを、該コンピュータの記憶部に格納しておき、該コンピュータのＣＰＵによってこのプログラムを読み出して実行させることで実現することができる。

また、プログラムは、コンピュータが読取り可能な記録媒体に記録されていてもよい。このような記録媒体を用いれば、プログラムをコンピュータにインストールすることが可能である。ここで、プログラムが記録された記録媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭなどの記録媒体であってもよい。

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

１ 放送システム
２ 第１の伝送路
３ 第２の伝送路
４ ＤＮＳサーバ
１０ 放送設備
１１ 映像・音声符号化装置（符号化部）
１２ 映像・音声コンテンツサーバ
１３ 制御情報生成装置（制御情報生成部）
１４ 多重化装置（多重化部）
１５ 再多重化装置
１６ 送信所設備（送信部）
１６Ａ ヘッドエンド設備（送信部）
１７ 放送波変調装置
１８ 送信機
１８Ａ 収容装置
１７Ａ，１９，１９Ａ 通信機器
２０，２１，２２ ＷＥＢサーバ（サーバ装置）
３０，３０Ａ，３０Ｂ，３０Ｃ 受信機
３１，３１ａ 放送インタフェース部
３２ 放送多重分離部（第１の取得部）
３３，３３Ａ リクエストＵＲＬ生成部（生成部）
３４，３４ａ 通信インタフェース部
３５ ＨＴＴＰクライアント部（第２の取得部）
３６ 通信多重分離部
３７ ＭＰＵバッファ部
３８ 映像・音声復号部
４１ 基本ＵＲＬ情報キャッシュ部（記憶部）
４２，４２Ｃ 事前ＤＮＳ解決部
４３，４３Ｃ 事前ＴＣＰ接続部
４４，４４Ｃ 前処理部
４５ 受信品質測定部

Claims (7)

1. 第１の伝送路を介して放送設備から伝送され、放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられた、セグメントを取得する受信機であって、
   前記セグメントと、前記セグメントを補完する補完セグメントの格納先を示し、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて予め定められた規則に従い置き換えられる置換部とを含むテンプレートアドレスとを取得し、取得すべきセグメントの損失を検出する第１の取得部と、
   前記第１の取得部により検出された損失したセグメントに割り当てられたシーケンス番号に基づき、前記予め定められた規則に従い前記テンプレートアドレスの置換部を置き換えて、前記損失したセグメントに対応する補完セグメントの格納先を示すリクエストアドレスを生成する生成部と、
   双方向伝送路である第２の伝送路を介して、前記生成部により生成されたリクエストアドレスを用いて、前記補完セグメントを格納するサーバ装置から、前記損失したセグメントに対応する補完セグメントを取得する第２の取得部と、を備えることを特徴とする受信機。
2. 請求項１に記載の受信機において、
   前記補完セグメントは、複数のビットレートに対応して前記サーバ装置に格納され、
   前記テンプレートアドレスは、前記複数のビットレートそれぞれに対応して設けられ、
   前記生成部は、前記損失したセグメントに割り当てられたシーケンス番号に基づき、予め定められた規則に従い、所望のビットレートの補完セグメントに対応するテンプレートアドレスの置換部を置き換えてリクエストアドレスを生成することを特徴とする受信機。
3. 請求項１または２に記載の受信機において、
   前記第１の取得部が取得したテンプレートアドレスをキャッシュする記憶部をさらに備え、
   前記生成部は、前記第１の伝送路を介した放送を受信することができず、前記第１の伝送路を介して伝送される最新のセグメントのシーケンス番号を取得することができない場合、前記記憶部にキャッシュされているテンプレートアドレスの共通部に予め定められた所定の文字列を付加して、最新の補完セグメントのシーケンス番号を記述したファイルの格納先を示すリクエストアドレスを生成し、
   前記第２の取得部は、前記生成部により生成されたリクエストアドレスを用いて、前記第２の伝送路を介して、前記最新の補完セグメントのシーケンス番号を記述したファイルを前記サーバ装置から取得することを特徴とする受信機。
4. 請求項１から３のいずれか一項に記載の受信機において、
   前記生成部によるリクエストアドレスの生成の有無に関わらず、前記サーバ装置からファイルを取得するための前処理を予め行う前処理部と、
   前記第１の伝送路を介した放送の受信品質を測定する受信品質測定部とをさらに備え、
   前記前処理部は、前記受信品質測定部により測定された受信品質が、所定の閾値を下回ると、前記前処理を行うことを特徴とする受信機。
5. 第１の伝送路を介して受信機に放送サービスを提供する放送設備であって、
   前記放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたセグメントを生成する符号化部と、
   前記セグメントを補完する補完セグメントを格納し、該格納する補完セグメントを双方向伝送路である第２の伝送路を介して前記受信機に伝送するサーバ装置のアドレス情報に基づき、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含む、前記補完セグメントの格納先を示すテンプレートアドレスを生成する制御情報生成部と、
   前記セグメントおよび前記テンプレートアドレスを多重化し、前記第１の伝送路を介して放送を行う送信部に出力する多重化部と、を備えることを特徴とする放送設備。
6. 放送サービスにおける映像・音声のコーデックの処理単位であり、シーケンス番号が割り当てられたセグメントを第１の伝送路を介して伝送する放送設備と、
   前記セグメントを補完する補完セグメントを格納し、該補完セグメントを、双方向伝送路である第２の伝送路を介して伝送するサーバ装置と、
   前記放送設備から伝送された前記セグメントを取得する受信機と、を備え、
   前記放送設備は、各補完セグメントに共通の共通部と、前記セグメントに割り当てられたシーケンス番号に応じて、予め定められた規則に従い置き換えられる置換部とを含む、前記補完セグメントの格納先を示すテンプレートアドレスを前記第１の伝送路を介して伝送し、
   前記受信機は、
   前記第１の伝送路を介して伝送された、前記セグメントおよび前記テンプレートアドレスを取得し、取得すべきセグメントの損失を検出する第１の取得部と、
   前記第１の取得部により検出された損失したセグメントに割り当てられたシーケンス番号に基づき、前記予め定められた規則に従い前記テンプレートアドレスの置換部を置き換えて、前記損失したセグメントに対応する補完セグメントの格納先を示すリクエストアドレスを生成する生成部と、
   前記生成部により生成されたリクエストアドレスを用いて、前記第２の伝送路を介して、前記損失したセグメントに対応する補完セグメントを前記サーバ装置から取得する第２の取得部と、を備えることを特徴とする放送システム。
7. コンピュータを、請求項１から４のいずれか一項に記載の受信機として機能させるプログラム。

Images