(57)【要約】  本技術は、確実に、コンテンツを再生することができるようにする受信装置、及び、データ処理方法に関する。受信装置は、コンテンツを受信し、コンテンツの送信側から提供される第１の時刻情報と、コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、第２の時刻情報に対応した第１の時刻情報に応じた時間軸で、コンテンツの再生を制御する。本技術は、例えば、ATSC3.0に対応したテレビ受像機に適用することができる。
2017195668.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを受信する受信部と、
前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生を制御する制御部と
を備える受信装置。
【請求項２】
前記コンテンツは、前記コンテンツのデータを伝送する単位であるフレーム単位で伝送され、
前記第１の時刻情報は、前記フレームに含まれ、
前記制御部は、
前記フレームに含まれる前記第１の時刻情報が受信された場合、前記第１の時刻情報が受信されたタイミングに応じた前記第２の時刻情報を取得し、
取得された前記第２の時刻情報を、受信された前記第１の時刻情報と対応付けて、前記時刻対応情報として管理する
請求項１に記載の受信装置。
【請求項３】
前記制御部は、
過去のある時点での第１の時刻情報と第２の時刻情報とを対応付けた前記時刻対応情報を取得し、
その時点での第２の時刻情報を取得し、
前記その時点での第２の時刻情報と、前記過去のある時点での第２の時刻情報と、前記過去のある時点での第１の時刻情報との関係から、その時点での第１の時刻情報を算出し、
算出された前記その時点での第１の時刻情報に基づいて、前記コンテンツの再生を制御する
請求項２に記載の受信装置。
【請求項４】
前記時刻対応情報は、前記過去のある時点での第１の時刻情報が示す時刻と、前記過去のある時点での第２の時刻情報が示す時刻のそれ自体を表した情報、又は前記過去のある時点での第１の時刻情報が示す時刻と、前記過去のある時点での第２の時刻情報が示す時刻との差分の情報である
請求項３に記載の受信装置。
【請求項５】
前記コンテンツは、放送波により配信される放送コンテンツであり、
前記第１の時刻情報は、PTP(Precision Time Protocol)であり、
前記第２の時刻情報は、システム時刻（System Time）である
請求項４に記載の受信装置。
【請求項６】
前記第１の時刻情報は、任意のフレームに含まれ、
前記第１の時刻情報が示す時刻は、当該フレームの先頭の位置の時刻を表している
請求項２に記載の受信装置。
【請求項７】
前記制御部は、
前記コンテンツを再生するためのアプリケーションと、
前記時刻対応情報を管理するためのミドルウェアと
の動作を制御し、
前記ミドルウェアは、前記アプリケーションからの要求に応じて、前記時刻対応情報を提供し、
前記アプリケーションは、前記ミドルウェアから提供される前記時刻対応情報に基づいて、前記コンテンツの再生を制御する
請求項１に記載の受信装置。
【請求項８】
前記フレームは、前記第１の時刻情報を補正するための時刻メタデータを含むプリアンブルを有し、
前記制御部は、前記時刻メタデータに基づいて、前記第１の時刻情報を補正する
請求項２に記載の受信装置。
【請求項９】
前記コンテンツは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠してストリーミング配信され、
前記制御部は、MPD(Media Presentation Description)メタデータに基づいて、前記コンテンツの再生を制御する
請求項１に記載の受信装置。
【請求項１０】
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生を制御する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、及び、データ処理方法に関し、特に、確実に、コンテンツを再生することができるようにした受信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
送信側のサーバから配信されるコンテンツを、受信側のクライアント装置により再生するに際し、送信側と受信側とで時刻情報が共有される場合には、当該時刻情報の同期をとる必要がある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2014-230154号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、クライアント装置の環境によっては、送信側と受信側とで時刻情報を同期することができない場合があり、そのような場合であっても、確実に、コンテンツを再生可能にするための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、確実に、コンテンツを再生することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の一側面の受信装置は、コンテンツを受信する受信部と、前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生を制御する制御部とを備える受信装置である。【０００７】
本技術の一側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の一側面のデータ処理方法は、上述した本技術の一側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の一側面の受信装置、及び、データ処理方法においては、コンテンツが受信され、前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とが対応付けられた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生が制御される。
【発明の効果】
【０００９】
本技術の一側面によれば、確実に、コンテンツを再生することができる。【００１０】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１１】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】本技術のコンテンツ再生制御の概要を説明する図である。
【図３】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図４】L1シグナリングの構成例を示す図である。
【図５】物理層フレームの構成例を示す図である。
【図６】L1基本情報のシンタックスの例を示す図である。
【図７】L1詳細情報のシンタックスの例を示す図である。
【図８】LLSテーブルのシンタックスの例を示す図である。
【図９】SystemTime要素の構成例を示す図である。
【図１０】RFデモジュレータと放送ミドルウェアにより実行される処理の流れを説明する図である。
【図１１】アプリケーションにより実行される処理の流れを説明する図である。
【図１２】ブロードキャスト時刻の算出方法を説明する図である。
【図１３】DASHセグメントの特定方法を説明する図である。
【図１４】アプリケーションと放送ミドルウェア間のメッセージングを説明する図である。
【図１５】GetBroadcastTimeリクエストの定義の例を示す図である。
【図１６】GetBroadcastTimeリクエストのメッセージの例を示す図である。
【図１７】GetBroadcastTimeレスポンスの定義の例を示す図である。
【図１８】GetBroadcastTimeレスポンスのメッセージの例を示す図である。
【図１９】時刻対応情報管理処理の流れを説明するフローチャートである。
【図２０】コンテンツ再生制御処理の流れを説明するフローチャートである。
【図２１】コンテンツ再生処理の流れを説明するフローチャートである。
【図２２】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１３】
１．システムの構成
２．本技術の概要
３．クライアント装置で処理される時刻情報
４．アプリケーションと放送ミドルウェア間のメッセージング
５．クライアント装置で実行される処理の流れ
６．変形例
７．コンピュータの構成
【００１４】
＜１．システムの構成＞
【００１５】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００１６】
図１において、伝送システム１は、放送サーバ１０とクライアント装置２０から構成される。
【００１７】
放送サーバ１０は、テレビ番組やCM等のコンテンツを、伝送路３０を介して送信する送信機である。放送サーバ１０は、コンテンツのビデオやオーディオのデータと、シグナリングを含む放送ストリームを、放送波として送信（一斉同報配信）する。
【００１８】
クライアント装置２０は、放送サーバ１０から伝送路３０を介して送信されてくる、コンテンツを受信する受信機である。クライアント装置２０は、放送サーバ１０からの放送波を受信して、放送ストリームから、コンテンツのビデオやオーディオのデータと、シグナリングを取得し、テレビ番組等のコンテンツの映像や音声を再生する。
【００１９】
伝送システム１においては、例えば、現在策定が進められているATSC(Advanced Television Systems Committee)3.0等の所定の放送規格に準拠したデータ伝送が行われる。また、伝送システム１において、伝送路３０は、地上波放送のほか、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。
【００２０】
ここで、図１の伝送システム１においては、説明を簡単にするために、クライアント装置２０を１つだけ図示しているが、クライアント装置２０は複数設けることができ、放送サーバ１０により送信（一斉同報配信）される放送波は、伝送路３０を介して、異なる場所に設置された複数のクライアント装置２０で同時に受信されることになる。
【００２１】
また、放送サーバ１０も複数設けることができる。複数の放送サーバ１０のそれぞれでは、別個のチャンネル（サービス）としての、例えば、別個の周波数帯域で、放送ストリームを含む放送波を送信し、クライアント装置２０では、複数の放送サーバ１０のそれぞれのチャンネルの中から、放送ストリームを受信するチャンネルを選局することができる。
【００２２】
＜２．本技術の概要＞
【００２３】
ところで、クライアント装置２０が、放送サーバ１０からストリーミング配信されるコンテンツを再生するためには、放送サーバ１０から提供される時刻情報（絶対時刻）を、放送サーバ１０とクライアント装置２０とで共有して、同期をとる必要がある。放送サーバ１０とクライアント装置２０とで共有されなければならない正確な絶対時刻は、ウォールクロック時刻（WallClockTime）とも称される。
【００２４】
この種の時刻の同期方法としては、例えば、放送サーバ１０とクライアント装置２０のそれぞれが、NTP(Network Time Protocol)プロトコル等を利用して、外部のクロックソースから時刻情報を取得することで、時刻の同期をとる方法がある。しかしながら、NTPプロトコルを利用するためには、放送サーバ１０とクライアント装置２０のそれぞれが、ネットワークに接続している必要があり、例えば、クライアント装置２０が、放送配信されるコンテンツを受信する機能しか有していない場合（通信機能を有していない場合）には、NTPプロトコルを利用することはできない。
【００２５】
一方で、クライアント装置２０が、例えば、パーソナルコンピュータやタブレット型端末装置、スマートフォンなどである場合、そこで実行されるアプリケーションからは、システムクロック（システム時刻）を簡単に変更することができない。しかしながら、このような環境でも、コンテンツを再生するためのプレーヤとしてのアプリケーションを実装できるようにしたいという要請がある。
【００２６】
このように、クライアント装置２０において、例えば、NTPプロトコル等を利用できず、さらに、実行中のアプリケーションからシステム時刻を簡単に変更できないような環境でも、放送サーバ１０と時刻情報を共有して、ストリーミング配信されるコンテンツを再生するための提案が要請されている。そこで、本技術では、これらの要請に応えるために、以下に説明する提案を行うものとする。
【００２７】
（本技術のコンテンツ再生制御の概要）
図２は、本技術のコンテンツ再生制御の概要を説明する図である。
【００２８】
図２において、図中左側のサーバ側は、放送サーバ１０により実行される処理を表し、図中の右側のクライアント側は、クライアント装置２０により実行される処理を表している。
【００２９】
放送サーバ１０は、コンテンツのデータを含む物理層フレームを放送波により送信する。詳細は後述するが、物理層フレームは、コンテンツのデータを伝送する単位である。また、放送サーバ１０は、PTPクロックソース１１からPTP(Precision Time Protocol)時刻を取得し、任意の物理層フレームに含めて送信されるようにする。
【００３０】
ここで、PTPは、IEEE 1588-2008で規定されている時刻を表す情報である。例えば、80ビットのPTPは、48ビットの秒フィールドと、32ビットのナノ秒フィールドで構成される。以下の説明では、放送サーバ１０から提供される時刻情報として、PTP時刻（PTP Time）が用いられる場合を説明する。
【００３１】
クライアント装置２０は、RFデモジュレータ１０１、放送ミドルウェア１０２、記憶部１０３、ブラウザ１０４、DASHクライアント１０５、デコーダ１０６、及び出力部１０７を含んで構成される。
【００３２】
RFデモジュレータ１０１は、放送サーバ１０から送信されてくる放送波を受信するアンテナと接続され、放送波で伝送される物理層フレームを抽出する。RFデモジュレータ１０１は、抽出した物理層フレームのうち、任意の物理層フレームからPTP時刻を抽出し、放送ミドルウェア１０２に供給する。
【００３３】
放送ミドルウェア１０２は、RFデモジュレータ１０１によるPTP時刻の抽出と同時（ほぼ同時）に、システムクロックソース２１からシステム時刻（System Time）を取得する。なお、システムクロックソース２１により生成されるシステム時刻は、放送ミドルウェア１０２だけでなく、クライアント装置２０の各部で用いられる。例えば、ブラウザ１０４により実行されるアプリケーション１２１は、システムクロックソース２１からシステム時刻を取得することができる。
【００３４】
放送ミドルウェア１０２は、RFデモジュレータ１０１から供給されるPTP時刻を、ブロードキャスト時刻（Broadcast Time）として、システム時刻と対応付け（ペアリング）し、その結果得られる情報（以下、時刻対応情報という）を、記憶部１０３に記憶する。記憶部１０３は、例えば半導体メモリから構成される。
【００３５】
ここで、ブロードキャスト時刻は、コンテンツの送信側から提供される時刻情報であって、例えば、コンテンツの再生などに用いられる。一方で、システム時刻は、コンテンツの受信側で生成される時刻情報であって、例えば、現在時刻の表示やログ情報の記録などに用いられる。すなわち、時刻対応情報として対応付けられているブロードキャスト時刻とシステム時刻とは、基本的に別の用途で用いられる時刻情報であると言える。
【００３６】
放送ミドルウェア１０２は、ブラウザ１０４により実行されるアプリケーション１２１からGetBroadcastTimeリクエストを受け付けた場合、記憶部１０３から時刻対応情報を読み出し、アプリケーション１２１に対し、GetBroadcastTimeレスポンスとして返答する。すなわち、放送ミドルウェア１０２は、時刻対応情報を管理する管理部としての機能を有している。
【００３７】
ブラウザ１０４は、例えば、HTML5(HyperText Markup Language 5)に対応したブラウザである。ブラウザ１０４は、放送経由又は通信経由で配信されるアプリケーション１２１を取得して実行する。アプリケーション１２１は、放送サーバ１０から配信されるコンテンツに付随するアプリケーションであって、例えば、HTML5等のマークアップ言語やJavaScript（登録商標）などで記述される。また、アプリケーション１２１は、放送サーバ１０から配信されるコンテンツを再生するためのプレーヤとしても機能する。なお、アプリケーション１２１は、クライアント装置２０に、あらかじめ記録されているようにしてもよい。
【００３８】
アプリケーション１２１は、コンテンツの再生の開始時に、放送ミドルウェア１０２に対し、GetBroadcastTimeリクエストを発行する。これにより、アプリケーション１２１は、放送ミドルウェア１０２からのGetBroadcastTimeレスポンスとして、時刻対応情報を取得することができる。
【００３９】
アプリケーション１２１は、放送ミドルウェア１０２からの時刻対応情報に基づいて、システム時刻に対応したブロードキャスト時刻に応じた時間軸で、コンテンツの再生が行われるように、デコードの対象となるデータ（DASHセグメント）の転送を制御する。すなわち、アプリケーション１２１は、コンテンツの再生を制御する再生制御部（プレーヤ）としての機能を有している。
【００４０】
RFデモジュレータ１０１は、物理層フレームに対する復調処理で得られる復調データを、放送ミドルウェア１０２に供給する。放送ミドルウェア１０２は、シグナリングなどに基づいて、RFデモジュレータ１０１から供給される復調データを処理し、その結果得られるデータを、DASHクライアント１０５に供給する。
【００４１】
DASHクライアント１０５は、放送ミドルウェア１０２から供給されるデータ（DASHセグメント）を処理する。DASHクライアント１０５は、アプリケーション１２１からの制御に従い、適切なタイミング（しかるべきタイミング）で、DASHセグメントを、デコーダ１０６に供給する。
【００４２】
デコーダ１０６は、所定の復号方式に従い、DASHクライアント１０５から供給されるDASHセグメントから得られるビデオとオーディオのデータのデコードを行う。ここでは、例えば、HEVC(High Efficiency Video Coding)や、AAC(Advanced Audio Coding)などの復号方式に従ったデコードが行われる。このデコードにより得られたビデオとオーディオのデータは、出力部１０７に供給される。
【００４３】
出力部１０７は、デコーダ１０６から供給されるビデオとオーディオのデータに対し、レンダリングなどの処理を行い、その結果得られるデータを出力する。これにより、クライアント装置２０では、テレビ番組等のコンテンツの映像や音声が再生されることになる。
【００４４】
以上のようにして、クライアント装置２０では、放送サーバ１０からストリーミング配信されるコンテンツの再生が行われる。ただし、クライアント装置２０において、例えば、放送ミドルウェア１０２、ブラウザ１０４、及びアプリケーション１２１は、ソフトウェアとして提供され、CPU（後述する図２２のCPU１００１）が所定のプログラムを実行することで、実現されるようにすることができる。
【００４５】
なお、放送サーバ１０からクライアント装置２０に、時刻情報として、物理層フレームに含まれるPTP時刻を送信する際には、伝送路３０での遅延が生じることになるが、ある場所に存在するクライアント装置２０おいては、この遅延量は一定になるので、対象のクライアント装置２０での遅延量が一定の間隔であり続けさえすれば、特に問題になることはない。
【００４６】
また、以下、放送サーバ１０からクライアント装置２０に提供される時刻情報として、PTP時刻を説明するが、時刻情報としては、PTP時刻に限らず、任意の時刻の情報を用いることができる。例えば、UTC（協定世界時：Coordinated Universal Time）や各タイムゾーンの標準時の時刻であるローカル時刻（LT：Local Time）で規定される時刻の情報、NTP(Network Time Protocol)で規定される時刻の情報、3GPP(Third Generation Partnership Project)で規定されている時刻の情報や、GPS(Global Positioning System)情報に含まれる時刻の情報、その他独自に決定された形式の時刻の情報などを用いることができる。
【００４７】
（本技術のデータ伝送方式）
ところで、ATSC3.0では、伝送方式として、現在広く普及しているMPEG2-TS(Transport Stream)方式ではなく、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【００４８】
また、ATSC3.0では、シグナリングとして、LLS(Link Layer Signaling)シグナリングとSLS(Service Layer Signaling)シグナリングを用いることが想定されている。LLSシグナリングは、SLSシグナリングに先行して取得されるシグナリングであって、LLSシグナリングに含まれる情報に従い、SLSシグナリングが取得される。SLSシグナリングは、サービス単位のシグナリングである。
【００４９】
LLSシグナリングは、SLT(Service List Table)やRRT(Rating Region Table)等のメタデータを含む。SLTメタデータは、サービスの選局に必要な情報（選局情報）など、放送ネットワークにおけるストリームやサービスの構成を示す基本情報を含む。RRTメタデータは、レーティングに関する情報を含む。
【００５０】
SLSシグナリングは、USD(User Service Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。USDメタデータは、他のメタデータの取得先などの情報を含む。ただし、USDは、USBD(User Service Bundle Description)と称されることがある。
【００５１】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTE(Real-time Object Delivery over Unidirectional Transport)プロトコルの制御情報である。なお、ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００５２】
MPDメタデータは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの管理情報である。ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００５３】
このMPEG-DASHの規格では、ビデオやオーディオのファイルの管理情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。そして、前者のマニフェストファイルが、MPD(Media Presentation Description)と称されるのである。また、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００５４】
なお、SLTやRRT等のLLSシグナリングと、SLT，USD，S-TSID，MPD等のSLSシグナリングは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述することができる。
【００５５】
（本技術のプロトコルスタック）
図３は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００５６】
図３において、最も下位の階層は、物理層（PHY(Physical)/MAC(Media Access Control)）とされる。なお、ここでは、データリンク層を、物理層の一部であるとして説明している。また、物理層に隣接する上位の階層は、IP(Internet Protocol)層とされる。IP層は、通信の階層モデルにおけるネットワーク層に相当する層であり、IPアドレスによりIPパケットが識別される。
【００５７】
また、IP層に隣接する上位の階層は、UDP(User Datagram Protocol)層とされる。UDP層は、通信の階層モデルにおけるトランスポート層に相当する層であり、ポート番号によりUDPパケットが識別される。UDP層に隣接する上位の階層は、LLSシグナリングを伝送するLLS層とされる。
【００５８】
図３において、LLS層で伝送されるLLSシグナリングには、選局情報等のほかに、時刻メタデータが含まれる。この時刻メタデータは、うるう秒や夏時間を調整するための補正情報を含む。クライアント装置２０は、LLSシグナリングに含まれる補正情報を用い、PTP時刻等の時刻情報を補正することで、うるう秒や夏時間に対応した時刻情報での処理を行うことができる。
【００５９】
ここで、うるう秒は、TAI（国際原子時）と同期して進むUTCが、地球の自転速度の変化によって世界時（UT1）から長年の間に大きく狂わないように、世界的な協定に基づいてUTCに挿入又は削除される１秒をいう。例えば、UTCやローカル時刻では、うるう秒を調整する必要がある一方で、PTPでは、うるう秒を調整する必要がない。
【００６０】
夏時間（DST：Daylight Saving Time）は、１年のうち、夏を中心とした期間に、太陽の出ている時間帯を有効に利用する目的で、標準時を１時間進める制度、又はその進められた時刻を表す。ただし、一部の地域では、夏時間と通常の時間との差が１時間ではなく、30分などと規定されている場合がある。なお、夏時間は、デイライトセービングタイム（Daylight Saving Time）のほか、サマータイム（Summer Time）とも称される。
【００６１】
また、図３において、物理層で伝送されるL1シグナリングには、復調情報等のほかに、PTP時刻が含まれる。ここで、図４には、L1シグナリングの構成例を示している。L1シグナリングは、物理層において、データを伝送する単位である物理層フレームのプリアンブルに含まれる。また、L1シグナリングとしては、L1基本情報（L1 Basic Signaling）と、L1詳細情報（L1 Detail Signaling）がある。
【００６２】
ここで、L1基本情報とL1詳細情報とを比較すれば、L1基本情報は、200ビット程度のビットから構成されるが、L1詳細情報は、400〜数千ビットから構成される点でそのサイズが異なっている。また、物理層フレームのプリアンブルでは、L1基本情報とL1詳細情報がその順に読み出されるため、L1詳細情報よりもL1基本情報のほうが先に読み出される。さらに、L1基本情報は、L1詳細情報と比べて、よりロバストに伝送される点でも異なっている。
【００６３】
PTP時刻等の時刻情報は、L1シグナリングとしてのL1基本情報又はL1詳細情報に含めることができる。
【００６４】
（物理層フレームの構成）
図５は、物理層フレームの構成例を示す図である。なお、図５において、時間の方向は、図中の左側から右側に向かう方向とされる。
【００６５】
図５において、物理層フレームは、ブートストラップ（Bootstrap）、プリアンブル（Preamble）、及びペイロード（Payload）から構成される。物理層フレームは、ミリ秒単位などの所定のフレーム長で構成される。物理層フレームにおいては、ブートストラップとプリアンブルを取得した後に、その後のペイロードを取得することが可能となる。
【００６６】
なお、ブートストラップは、例えば、DVB-T2(Digital Video Broadcasting - Second Generation Terrestrial)のT2フレームを構成するP1シンボルに対応し、プリアンブルは、例えば、DVB-T2のT2フレームを構成するP2シンボルに対応している。したがって、ブートストラップは、プリアンブルであると言うこともできる。
【００６７】
図５においては、時系列で伝送される複数の物理層フレームのうち、任意の物理層フレームの詳細な構成を示している。例えば、先頭から２番目の物理層フレームのプリアンブルに含まれるL1シグナリングには、PTP時刻が含まれている。このPTP時刻が示す時刻は、点線の矢印Ａで示すように、当該PTP時刻を含むL1シグナリングのプリアンブルを有する物理層フレームの先頭の位置（ブートストラップの先頭の位置）の時刻を表している。
【００６８】
すなわち、先頭から２番目の物理層フレームに含まれるPTP時刻が示す時刻は、２番目の物理層フレームの先頭の位置の時刻である。
【００６９】
なお、ここでは、PTP時刻が示す時刻が、物理層フレームの先頭の位置の時刻である場合を説明したが、PTP時刻が示す時刻は、物理層フレームにおける所定の位置の絶対的な時刻を表すようにすることができる。例えば、PTP時刻が含まれるプリアンブルを有する物理層フレームのブートストラップとプリアンブルとの境界の位置や、プリアンブルの最後の位置など、当該物理層フレームの任意の位置が、PTP時刻が示す時刻により表されるようにすることができる。
【００７０】
（L1基本情報の構成）
図６は、図４のL1基本情報（L1 Basic Signaling）のシンタックスの例を示す図である。
【００７１】
なお、L1基本情報については、下記の非特許文献１の「Table 9.2 L1-Basic Signaling Fields and Syntax」にその詳細な内容が記載されている。そのため、図６のシンタックスには、L1基本情報のうち、特に本技術に関係する部分を抜粋して記述している。
【００７２】
非特許文献１：ATSC Candidate Standard：Physical Layer Protocol (A/322) Doc. S32-230r456 April 2016
【００７３】
2ビットのL1B_content_tagは、コンテンツを識別するタグ値を表している。3ビットのL1B_versionは、L1基本情報のバージョンを表している。1ビットのL1B_slt_flagは、SLT(Service Labeling Table)が存在するかどうかを表している。
【００７４】
2ビットのL1B_time_info_flagは、時刻情報が存在するかどうかを表している。
【００７５】
L1B_time_info_flagとして、"00"が設定された場合、対象の物理層フレームには、時刻情報が含まれていないことを示す。L1B_time_info_flagとして、"01"が設定された場合、対象の物理層フレームには、ミリ秒単位の精度の時刻情報が含まれていることを示す。
【００７６】
L1B_time_info_flagとして、"10"が設定された場合、対象の物理層フレームには、マイクロ秒単位の精度の時刻情報が含まれていることを示す。L1B_time_info_flagとして、"11"が設定された場合、対象の物理層フレームには、ナノ秒単位の時刻情報が含まれていることを示す。
【００７７】
（L1詳細情報の構成）
図７は、図４のL1詳細情報（L1 Detail Signaling）のシンタックスの例を示す図である。
【００７８】
なお、L1詳細情報については、上述した非特許文献１の「Table 9.8 L1-Detail Signaling Fields and Syntax」にその詳細な内容が記載されている。そのため、図７のシンタックスには、L1詳細情報のうち、特に本技術に関係する部分を抜粋して記述している。
【００７９】
4ビットのL1D_versionは、L1詳細情報のバージョンを表している。
【００８０】
3ビットのL1D_num_rfに応じたループには、チャネルボンディング（Channel Bonding）に関するパラメータが配置される。すなわち、19ビットのL1D_rf_frequencyは、チャネルボンディングにより結合されるRFチャネルの周波数を表している。
【００８１】
ここで、図６のL1基本情報において、L1B_time_info_flagとして、"00"以外が設定された場合、時刻情報が存在していることを示しているので、図７のL1詳細情報には、時刻情報として、32ビットのL1D_time_secと、10ビットのL1D_time_msecが配置される。ここで、L1D_time_secは、秒単位（sec）の時刻情報を表している。また、L1D_time_msecは、ミリ秒単位（msec）の時刻情報を表している。
【００８２】
また、L1B_time_info_flagとして、"10"又は"11"が設定された場合には、時刻情報として、10ビットのL1D_time_usecがさらに配置される。ここで、L1D_time_usecは、マイクロ秒単位（usec）の時刻情報を表している。
【００８３】
また、L1B_time_info_flagとして、"11"が設定された場合には、時刻情報として、10ビットのL1D_time_nsecがさらに配置される。ここで、L1D_time_nsecは、ナノ秒単位（nsec）の時刻情報を表している。
【００８４】
このように、L1B_time_info_flagとして、"01"が設定された場合には、ミリ秒単位となるので、L1D_time_sec、及びL1D_time_msecとが配置される。また、L1B_time_info_flagとして、"10"が設定された場合には、マイクロ秒単位となるので、L1D_time_sec、L1D_time_msec、及びL1D_time_usecとが配置される。また、L1B_time_info_flagとして、"11"が設定された場合には、ナノ秒単位となるので、L1D_time_sec、L1D_time_msec、L1D_time_usec、及びL1D_time_nsecが配置される。
【００８５】
（LLSテーブルの構成）
図８は、LLSテーブルのシンタックスの例を示す図である。
【００８６】
なお、LLSテーブルについては、下記の非特許文献２の「Table 6.1 Common Bit Stream Syntax for LLS Tables」にその詳細な内容が記載されている。そのため、図８のシンタックスには、LLSテーブルのうち、特に本技術に関係する部分を抜粋して記述している。
【００８７】
非特許文献２：ATSC Candidate Standard：Signaling, Delivery, Synchronization,and Error Protection (A/331) Doc. S33-174r15 January 2016
【００８８】
8ビットのLLS_table_idは、LLSテーブルのIDを表している。8ビットのprovider_idは、プロバイダのIDを表している。8ビットのLLS_table_versionは、LLSテーブルのバージョンを表している。
【００８９】
LLS_table_idとして、"0x01"が設定された場合、LLSシグナリングとして、SLTメタデータが配置される。LLS_table_idとして、"0x02"が設定された場合、LLSシグナリングとして、RRTメタデータが配置される。
【００９０】
LLS_table_idとして、"0x03"が設定された場合、LLSシグナリングとして、システム時間（SystemTime）が配置される。このシステム時間が、上述の時刻メタデータに相当する。
【００９１】
（SystemTime要素の構成）
図９は、時刻メタデータとしてのSystemTime要素の構成例を示す図である。なお、図９において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【００９２】
SystemTime要素は、currentUtcOffset属性、ptpPrepend属性、leap59属性、leap61属性、utcLocalOffset属性、dsStatus属性、dsDayOfMonth属性、及びdsHour属性の上位要素となる。
【００９３】
currentUtcOffset属性には、PTPとUTCとのオフセットが設定される。ptpPrepend属性には、物理層フレームでは伝送されないPTPの上位の16ビットが設定される。ただし、ここで設定される情報は、2106年以前は不要とされる。
【００９４】
leap59属性には、UTCのうるう秒の削除を表すフラグに応じた値が設定される。leap61属性には、UTCのうるう秒の挿入を表すフラグに応じた値が設定される。
【００９５】
utcLocalOffset属性には、UTCとローカル時刻との差（タイムゾーン）が設定される。dsStatus属性には、夏時間のステータスが設定される。dsDayOfMonth属性には、夏時間の開始と終了の日付が設定される。dsHour属性には、夏時間の開始と終了の時刻が設定される。
【００９６】
なお、図９において、"Use"の項目であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"Data Type"の項目であるが、"unsignedByte"又は"unsignedshort"が指定された場合には、その要素又は属性の値が、整数型であることを示している。"boolean"が指定された場合には、その要素又は属性がブール型であることを示している。"duration"が指定された場合には、時間を表すデータ型であって、ある一定の期間であることを示している。
【００９７】
＜３．クライアント装置で処理される時刻情報＞
【００９８】
（放送ミドルウェアの処理の流れ）
図１０は、RFデモジュレータ１０１と放送ミドルウェア１０２により実行される処理の流れを説明する図である。
【００９９】
図１０において、RFデモジュレータ１０１は、アンテナにより受信された放送波から物理層フレームを抽出し、そのプリアンブルのL1シグナリングからPTP時刻を抽出する（Ｓ１１）。なお、PTP時刻は、任意の物理層フレームに含まれる。
【０１００】
PTP時刻は、RFデモジュレータ１０１から、放送ミドルウェア１０２に供給される。また、放送ミドルウェア１０２は、LLSシグナリングとして伝送される時刻メタデータを、あらかじめ取得して記憶しており、その時刻メタデータを取得する（Ｓ１２）。
【０１０１】
放送ミドルウェア１０２は、RFデモジュレータ１０１から供給されるPTP時刻を、UTC時刻に変換する（Ｓ１３）。また、放送ミドルウェア１０２は、ステップＳ１２の処理で取得された時刻メタデータに基づいて、変換前のPTP時刻又は変換後のUTC時刻を補正する（Ｓ１３）。このようにして補正が施されたUTC時刻が、ブロードキャスト時刻とされる。
【０１０２】
一方で、放送ミドルウェア１０２は、ステップＳ１１の処理で行われる、物理層フレームからのPTP時刻の抽出と同時（ほぼ同時）に、システムクロックを計測し、システム時刻を取得している（Ｓ２１）。なお、このシステム時刻が取得されるタイミングは、RFデモジュレータ１０１による時刻情報の抽出と同時に限らず、他のタイミングであってもよい。
【０１０３】
例えば、復調LSIとして構成されるRFデモジュレータ１０１からの出力は、デマルチプレクサの機能を有するシステムオンチップ（SoC：System on a Chip）に入力されるが、時刻情報をALP(ATSC Link-layer Protocol)パケット等のMAC(Media Access Control)フレームに格納してシステムオンチップに転送する際に、その転送のタイミングでシステム時刻が計測されるようにしてもよい。なお、ALPパケットは、UDPパケットを含むIPパケットを格納するレイヤ２のパケットである。
【０１０４】
放送ミドルウェア１０２は、ステップＳ１３の処理で得られるブロードキャスト時刻（UTC時刻）と、ステップＳ２１の処理で得られるシステム時刻とをペアリングし、その結果得られる時刻対応情報を、記憶部１０３に記憶する（Ｓ２２）。
【０１０５】
この時刻対応情報が記憶されるタイミングとしては、例えば、1〜5秒の間隔など、物理層フレームからPTP時刻が抽出されたタイミングで、抽出されたPTP時刻ごとに、システム時刻とペアリングして、時刻対応情報として記憶することができる。ただし、時刻対応情報を記憶するタイミングとしては、例えば、数時間単位や１日単位など、運用に応じてそのタイミングを変更することができる。また、記憶部１０３においては、基本的には時刻対応情報が上書き保存され、最新の時刻対応情報のみが保持されるようにする。
【０１０６】
その後、放送ミドルウェア１０２は、アプリケーション１２１からGetBroadcastTimeリクエストを受け付けた場合、当該リクエストに応じたGetBroadcastTimeレスポンスを生成する（Ｓ２３，Ｓ２４）。ここで生成されるGetBroadcastTimeレスポンスには、ステップＳ２２の処理で生成された時刻対応情報であって、記憶部１０３から読み出された時刻対応情報が含まれる。
【０１０７】
放送ミドルウェア１０２は、アプリケーション１２１に対し、ステップＳ２４の処理で生成されたGetBroadcastTimeレスポンスを返答する（Ｓ２５）。
【０１０８】
以上、RFデモジュレータ１０１と放送ミドルウェア１０２により実行される処理の流れを説明した。
【０１０９】
（アプリケーションの処理の流れ）
図１１は、アプリケーション１２１により実行される処理の流れを説明する図である。
【０１１０】
図１１において、アプリケーション１２１は、コンテンツの再生の開始時に、放送ミドルウェア１０２に対し、GetBroadcastTimeリクエストを発行する（Ｓ５１）。このGetBroadcastTimeリクエストが発行されると、放送ミドルウェア１０２では、ステップＳ２３乃至Ｓ２５（図１０）が実行され、GetBroadcastTimeレスポンスが返答される。
【０１１１】
アプリケーション１２１は、放送ミドルウェア１０２から返答されるGetBroadcastTimeレスポンスを受け取る（Ｓ５２）。このGetBroadcastTimeレスポンスには、時刻対応情報として、ブロードキャスト時刻とシステム時刻とをペアリングした情報が含まれる。
【０１１２】
ここでは、説明の便宜上、時刻対応情報に含まれる、ブロードキャスト時刻とシステム時刻をそれぞれ、BroadcastTime(1)とSystemTime(1)と称するものとする。すなわち、BroadcastTime(1)とSystemTime(1)は、過去のある時点でのブロードキャスト時刻とシステム時刻との組であるとも言える。アプリケーション１２１は、BroadcastTime(1)とSystemTime(1)を一時的に記憶（保持）する（Ｓ５３）。
【０１１３】
アプリケーション１２１は、Date()関数を実行することで、その時点でのシステム時刻として、SystemTime(2)を取得する（Ｓ５４）。なお、Date()関数は、例えば、JavaScript（登録商標）のAPI(Application Program Interface)として提供される。
【０１１４】
アプリケーション１２１は、ステップＳ５３の処理で一時的に記憶（保持）されたBroadcastTime(1)とSystemTime(1)、及びステップＳ５４の処理で取得されたSystemTime(2)に基づいて、SystemTime(2)に対応するブロードキャスト時刻として、BroadcastTime(2)を算出する（Ｓ５５）。すなわち、BroadcastTime(2)は、その時点でのシステム時刻に対応する、その時点でのブロードキャスト時刻であるとも言える。なお、BroadcastTime(2)の算出方法の詳細は、図１２を参照して後述する。
【０１１５】
アプリケーション１２１は、ステップＳ５５の処理で算出されたBroadcastTime(2)が示す時刻に、デコーダ１０６にかけるべき、DASHセグメントの特定を行う（Ｓ５６）。これにより、適切なタイミングで、DASHクライアント１０５からデコーダ１０６に対し、DASHセグメントが転送され、コンテンツの再生が行われる。なお、DASHセグメントの特定方法の詳細は、図１３を参照して後述する。
【０１１６】
以上、アプリケーション１２１により実行される処理の流れを説明した。
【０１１７】
（ブロードキャスト時刻の算出方法）
図１２は、図１１のステップＳ５５の処理における、ブロードキャスト時刻の算出方法を説明する図である。
【０１１８】
ステップＳ７１において、アプリケーション１２１は、放送ミドルウェア１０２に対し、GetBroadcastTimeリクエストを発行することで、時刻対応情報を取得する。ここでは、時刻対応情報として、過去のある時点でのBroadcastTime(1)とSystemTime(1)とを対応付けた情報が取得される。
【０１１９】
ステップＳ７２において、アプリケーション１２１は、Date()関数を実行することで、SystemTime(2)を取得する。
【０１２０】
ステップＳ７３において、アプリケーション１２１は、ステップＳ７１，Ｓ７２の処理で得られた時刻情報を用い、下記の式（１）を演算することで、BroadcastTime(2)を算出する。これにより、アプリケーション１２１では、その時点でのシステム時刻に対応するブロードキャスト時刻として、SystemTime(2)に対応するBroadcastTime(2)を求めることができる。
【０１２１】
BroadcastTime(2) = (SystemTime(2) - SystemTime(1)) + BroadcastTime(1)      ・・・（１）
【０１２２】
また、アプリケーション１２１では、その後も同様に、任意のタイミングで、Date()関数によりSystemTime(N)が取得され（Ｓ７４）、下記の式（２）が演算されることで、BroadcastTime(N)が算出される（Ｓ７５）。
【０１２３】
BroadcastTime(N) = (SystemTime(N) - SystemTime(1)) + BroadcastTime(1)      ・・・（２）
【０１２４】
（DASHセグメントの特定方法）
図１３は、図１１のステップＳ５６の処理における、DASHセグメントの特定方法を説明する図である。
【０１２５】
アプリケーション１２１では、上述したブロードキャスト時刻の算出方法（例えば、式（１））により算出されたBroadcastTime(2)に基づいて、MPDメタデータにて、BroadcastTime(2)が示すブロードキャスト時刻であらかじめ準備しなければならないDASHセグメントのムビーフラグメント（MF：Movie Fragment）を特定する。つまり、ここで特定されるムビーフラグメントは、適切なタイミングで後段のデコーダ１０６に渡せるように準備を開始すべき、DASHセグメントのムビーフラグメントである。
【０１２６】
ここで、MPDメタデータでは、ルート要素であるMPD要素のavailabilityStartTime属性に、UTC時刻に従ったストリーミング配信の開始時刻が指定される。また、MPDメタデータには、Period要素として、Period(1)，Period(2)，・・・が指定され、それらのPeriod要素には、start属性として、各Period（期間）の開始時刻が指定される。
【０１２７】
すなわち、図１３に示すように、MPDメタデータでは、availabilityStartTime属性で指定される開始時刻（ウォールクロック時間軸上の時刻）と、Period要素で指定される時刻（MPD時間軸上の時刻）との和により、各Periodの先頭の時刻が表される。
【０１２８】
また、MPDメタデータは、Period要素、AdaptationSet要素、及びRepresentation要素が階層構造で記述されている。Period要素は、テレビ番組等のコンテンツの構成を記述する単位となる。AdaptationSet要素又はRepresentation要素は、ビデオやオーディオ、字幕等のそれぞれのストリームごとに利用され、ぞれぞれのストリームの属性を記述できるようになっている。
【０１２９】
具体的には、AdaptationSet要素は、各種のソースからエンコードされたストリームを表している。そして、当該ストリームを、例えばビットレート等のパラメトリックに応じて、クライアント装置２０側で選択させるために、AdaptationSet要素内に、Representation要素を配置して、例えばビットレート等のパラメータが異なる複数の選択肢となるストリームを列挙している。通常、AdaptationSet要素やRepresentation要素は、ビデオやオーディオ、字幕のストリームなど、単一のストリームに対応させている。
【０１３０】
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることが想定される。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISOベースメディアファイルフォーマット（ISO Base Media File Format）の派生フォーマットである。ISOベースメディアファイルフォーマットは、ボックス(Box)と称される木構造から構成される。
【０１３１】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕等のストリームのデータを格納している。なお、このメディアセグメントが、上述のDASHセグメントに相当している。
【０１３２】
図１３において、各メディアセグメント（MS）は、複数のムビーフラグメント（MF：Movie Fragment）から構成される。例えば、メディアセグメントMS-1は、ムビーフラグメントMF-11，MF-12，MF-13から構成される。また、例えば、メディアセグメントMS-2は、ムビーフラグメントMF-21，MF-22，MF-23から構成される。
【０１３３】
各ムビーフラグメントのMoofヘッダには、Bmdt(Base Media Decode Time)が記述されている。Bmdtは、サンプルのデコード開始時間を表している。
【０１３４】
例えば、メディアセグメントMS-1において、ムビーフラグメントMF-11のMoofヘッダには、Bmdt-11が記述される。同様に、ムビーフラグメントMF-12には、そのMoofヘッダにBmdt-12が記述され、ムビーフラグメントMF-13には、そのMoofヘッダにBmdt-13が記述される。
【０１３５】
また、メディアセグメントMS-2において、ムビーフラグメントMF-21のMoofヘッダには、Bmdt-21が記述される。同様に、ムビーフラグメントMF-22には、そのMoofヘッダにBmdt-22が記述され、ムビーフラグメントMF-23には、そのMoofヘッダにBmdt-23が記述される。
【０１３６】
ここで、上述のステップＳ７３の処理（図１２）で算出されたBroadcastTime(2)の示す時刻が、図１３の時間軸上の時刻taとなる場合、アプリケーション１２１は、ムビーフラグメントMF-22を、次のレンダリングの対象とする。そして、アプリケーション１２１は、availabilityStartTime属性で指定される時刻と、Period要素のstart属性で指定される時刻と、ムビーフラグメントMF-22のBmdt-22が示す時刻との和（MPD@availabilityStartTime + MPD/Period@start + Bmdt-22）で得られる時刻（以下、MF-22提示時刻という）に、メディアセグメントMS-2のムビーフラグメントMF-22が再生（出力）されるように制御する。
【０１３７】
具体的には、アプリケーション１２１は、MF-22提示時刻に、メディアセグメントMS-2のムビーフラグメントMF-22が再生されるように、適切なタイミングで、DASHクライアント１０５からデコーダ１０６に対し、メディアセグメントMS-2のムビーフラグメントMF-22が渡されるようにする（転送されるようにする）。
【０１３８】
すなわち、アプリケーション１２１は、BroadcastTime(2) = SystemTime(2)となる時点で、下記の式（３）を演算することで求められるシステム時刻（MF-22提示時刻）に、メディアセグメントMS-2のムビーフラグメントMF-22が再生（出力）されるように、当該ムビーフラグメントMF-22が、デコーダ１０６に渡されるようにする。
【０１３９】
SystemTime(MF-22提示時刻) = (MF-22提示時刻 - BroadcastTime(2)) + SystemTime(2)      ・・・（３）
【０１４０】
なお、ここでは、ブロードキャスト時刻として、BroadcastTime(2)が算出された場合を例示したが、BroadcastTime(2)以降についても同様に処理することで、例えば、MPDメタデータにおいて、BroadcastTime(N)が示すブロードキャスト時刻であらかじめ準備すべきDASHセグメント（メディアセグメント）のムビーフラグメントを特定し、適切なタイミングで、デコーダ１０６に渡すことが可能となる。
【０１４１】
また、ここでは、DASHセグメントの特定方法として、メディアセグメントMS-2のムビーフラグメントMF-22が特定される場合を一例に説明したが、他のムビーフラグメント（MF）についても同様に特定され、適切なタイミングで、後段のデコーダ１０６に渡されることになる。
【０１４２】
＜４．アプリケーションと放送ミドルウェア間のメッセージング＞
【０１４３】
図１４は、アプリケーション１２１と放送ミドルウェア１０２との間のメッセージングを説明する図である。
【０１４４】
上述したように、アプリケーション１２１は、放送ミドルウェア１０２に対し、GetBroadcastTimeリクエストとGetBroadcastTimeレスポンスとをやりとりすることで、時刻対応情報を取得することができる。このGetBroadcastTimeリクエストとGetBroadcastTimeレスポンスのやりとりは、例えば、ウェブソケットとJSON-RPCとを組み合わせることで、実現することができる。
【０１４５】
ウェブソケット（WebSocket）は、W3C(World Wide Web Consortium)とIETF(The Internet Engineering Task Force)により策定された、ウェブサーバとブラウザとの間の通信の規格である。JSON-RPCは、テキストフォーマットの一種であるJSON(JavaScript(登録商標) Object Notation)形式で、RPC(Remote Procedure Call)するためのプロトコルである。
【０１４６】
図１４において、クライアント装置２０には、ソフトウェアとして提供されるウェブソケットサーバが設けられている。アプリケーション１２１と放送ミドルウェア１０２との間で、当該ウェブソケットサーバを介して、コネクションが確立されると、アプリケーション１２１と放送ミドルウェア１０２とは、JSON-RPCを利用して、メッセージをやりとりすることができる。
【０１４７】
ここで、図１４のプロトコルスタックに示したように、概念的には、ウェブソケットの階層は、IP層とHTTP/TCP層の上位の階層とされる。また、JSON-RPCの階層は、ウェブソケットの階層の上位の階層とされる。そして、このようなプロトコルで、アプリケーション１２１と放送ミドルウェア１０２とは、GetBroadcastTimeリクエストとGetBroadcastTimeレスポンスをやりとりすることになる。
【０１４８】
なお、ここでは、アプリケーション１２１と放送ミドルウェア１０２との間のメッセージングのプロトコルとして、ウェブソケットとJSON-RPCとを組み合わせを利用した場合を説明したが、他のプロトコルを利用するようにしてもよい。また、アプリケーション１２１を実行するブラウザ１０４に実装されるAPI(Application Programming Interface)などを利用してメッセージをやりとりするようにしてもよい。要は、アプリケーション１２１と放送ミドルウェア１０２との間で、メッセージをやりとりすることができればよく、その実現方法は任意である。
【０１４９】
（GetBroadcastTimeリクエスト）
図１５は、GetBroadcastTimeリクエストの定義の例を示す図である。
【０１５０】
method，paramsは、JSON-RPCで規定されている。
【０１５１】
methodには、呼び出されるメソッドの名前が設定される。GetBroadcastTimeリクエストの場合、"org.atsc.query.broadcastTime"を記述することで、リクエストの種類が、GetBroadcastTimeリクエストであることを識別できるようにしている。
【０１５２】
paramsには、メソッドの引数（パラメータ）が設定される。GetBroadcastTimeリクエストの場合には、特に、パラメータを設定する必要はない。
【０１５３】
図１６は、GetBroadcastTimeリクエストのメッセージの例を示す図である。このメッセージは、JSON形式で記述されている。JSON形式のオブジェクトは、キーと値のペアをコロン（：）で対にして、これらの対をコンマ（，）で区切ってゼロ個以上列挙し、全体を波括弧（{}）でくくることで表現される。
【０１５４】
図１６のメッセージにおいては、"jsonrpc"であるキーに対し、そのバージョンを示す"2.0"である値が設定されている。すなわち、放送ミドルウェア１０２は、この値を参照して、JSON-RPC 2.0に従ったリクエストとして処理するかどうかを判断することになる。
【０１５５】
"method"であるキーに対し、"org.atsc.query.broadcastTime"が設定されている。すなわち、放送ミドルウェア１０２は、この値を参照して、リクエストの種類が、GetBroadcastTimeリクエストであることを判断することができる。
【０１５６】
"id"であるキーに対し、"37"が設定されている。このidは、リクエストに対するレスポンスの対応をとるための識別情報である。すなわち、放送ミドルウェア１０２は、idが"37"のGetBroadcastTimeリクエストを受け付けた場合には、その返答のGetBroadcastTimeレスポンスに対し、同一のidである"37"を設定することになる。
【０１５７】
（GetBroadcastTimeレスポンス）
図１７は、GetBroadcastTimeレスポンスの定義の例を示す図である。
【０１５８】
resultは、JSON-RPCで規定されている。
【０１５９】
resultには、メソッドの戻り値が設定される。GetBroadcastTimeレスポンスの場合、JSON形式のオブジェクトが設定される。このオブジェクトでは、プロパティとして、"broadcastTime"であるキーに対し、ブロードキャスト時刻の値が設定され、"systemTime"であるキーに対し、システム時刻の値が設定される。ただし、ブロードキャスト時刻とシステム時刻のデータ型は、文字列型（string）とされる。
【０１６０】
また、"required"として、"broadcastTime"と"systemTime"が設定されているが、これは、ブロードキャスト時刻とシステム時刻とを両方とも設定する必要があることを意味する。つまり、ブロードキャスト時刻とシステム時刻のうち、いずれか一方の時刻だけを設定することは許可されない。
【０１６１】
すなわち、この"broadcastTime"と"systemTime"で設定される、ブロードキャスト時刻とシステム時刻との組が、上述した時刻対応情報に相当するものである。ただし、ここでは、ブロードキャスト時刻とシステム時刻との組が定義されているが、例えば、ブロードキャスト時刻とシステム時刻との差分の時刻を示す差分情報など、他の形式の情報が設定されるようにしてもよい。
【０１６２】
なお、図１７においては、ブロードキャスト時刻は、放送ストリームに含まれるウォールクロック時刻であり、システム時刻は、ブロードキャスト時刻を抽出したときの時刻であると定義されている。
【０１６３】
図１８は、GetBroadcastTimeレスポンスのメッセージの例を示す図である。
【０１６４】
図１８のメッセージにおいては、"jsonrpc"であるキーに対し、そのバージョンを示す"2.0"である値が設定されている。すなわち、放送ミドルウェア１０２が、JSON-RPC 2.0に従ったリクエストとして処理したことを示している。
【０１６５】
"result"であるキーに対し、"broadcastTime"と"systemTime"が設定されている。"broadcastTime"であるキーには、"Thu Apr 28 2016 10:31:14 GMT+0900"が設定されている。また、"systemTime"であるキーには、"Thu Apr 28 2016 10:31:28 GMT+0900"が設定されている。
【０１６６】
すなわち、ブロードキャスト時刻として、2016年4月28日（木）10:31:14が設定され、システム時刻として、2016年4月28日（木）10:31:28が設定されている。この時刻の組が、上述した時刻対応情報に相当するのは、先に述べた通りである。また、この例では、ブロードキャスト時刻とシステム時刻との差分は、14秒となるので、この14秒である差分情報を、時刻対応情報としてもよい。
【０１６７】
"id"であるキーに対し、"37"が設定されている。すなわち、放送ミドルウェア１０２は、アプリケーション１２１から受け付けたGetBroadcastTimeリクエストのメッセージのidと同一のidである"37"を、その返答のGetBroadcastTimeレスポンスのメッセージのidに設定したことになる。
【０１６８】
＜５．クライアント装置で実行される処理の流れ＞
【０１６９】
次に、図１９乃至図２１のフローチャートを参照して、クライアント装置２０で実行される処理の流れを説明する。
【０１７０】
（時刻対応情報管理処理）
まず、図１９のフローチャートを参照して、クライアント装置２０により実行される時刻対応情報管理処理の流れを説明する。
【０１７１】
ステップＳ２０１において、RFデモジュレータ１０１は、アンテナを介して、放送サーバ１０から送信されてくる放送波を受信する。
【０１７２】
ステップＳ２０２において、RFデモジュレータ１０１は、ステップＳ２０１の処理で受信された放送波から物理層フレームを抽出する。
【０１７３】
ステップＳ２０３において、RFデモジュレータ１０１は、ステップＳ２０２の処理で抽出された物理層フレームのうち、任意の物理層フレームから、PTP時刻を抽出する。
【０１７４】
ステップＳ２０４において、放送ミドルウェア１０２は、ステップＳ２０３の処理でPTP時刻が抽出されるのと同時（ほぼ同時）に、システムクロックリソース２１からシステム時刻を取得する。
【０１７５】
ステップＳ２０５において、放送ミドルウェア１０２は、ステップＳ２０３の処理で得られたPTP時刻を、ブロードキャスト時刻として、ステップＳ２０４の処理で得られたシステム時刻と対応付けをすることで、時刻対応情報を生成する。
【０１７６】
ステップＳ２０６において、放送ミドルウェア１０２は、ステップＳ２０５の処理で生成された時刻対応情報を、記憶部１０３に記憶する。
【０１７７】
以上、時刻対応情報管理処理の流れを説明した。この時刻対応情報管理処理では、同時（ほぼ同時）に得られるブロードキャスト時刻とシステム時刻から時刻対応情報が生成され、記憶部１０３に記憶される。
【０１７８】
（コンテンツ再生制御処理）
次に、図２０のフローチャートを参照して、コンテンツ再生制御処理の流れを説明する。
【０１７９】
ステップＳ２２１において、アプリケーション１２１は、放送ミドルウェア１０２から、時刻対応情報を取得する。ここでは、アプリケーション１２１が、放送ミドルウェア１０２に対し、GetBroadcastTimeリクエストを発行して、その返答としてのGetBroadcastTimeレスポンスを受け取ることで、時刻対応情報が取得される。
【０１８０】
ただし、ステップＳ２２１の処理で得られる時刻対応情報は、上述した時刻対応情報管理処理（図１９）で、放送ミドルウェア１０２により生成されたものである。
【０１８１】
ステップＳ２２２において、アプリケーション１２１は、その時点でのシステム時刻を取得する。ここでは、アプリケーション１２１は、Date()関数を実行することで、その時点でのシステム時刻（SystemTime(2)）を取得することができる。
【０１８２】
ステップＳ２２３において、アプリケーション１２１は、ステップＳ２２１の処理で得られた時刻対応情報と、ステップＳ２２２の処理で得られたその時点でのシステム時刻に基づいて、その時点でのブロードキャスト時刻を算出する。
【０１８３】
ここで、時刻対応情報には、過去のある時点でのブロードキャスト時刻（BroadcastTime(1)）とシステム時刻（SystemTime(1)）とが対応付けられているので、それに、その時点でのシステム時刻（SystemTime(2)）を加えて、上述した式（１）を演算することで、その時点でのブロードキャスト時刻（BroadcastTime(2)）を求めることができる。
【０１８４】
ステップＳ２２４において、アプリケーション１２１は、ステップＳ２２３の処理で得られたブロードキャスト時刻（BroadcastTime(2)）に応じた特定のタイミングで、特定のDASHセグメント（メディアセグメント）のムビーフラグメントが、デコーダ１０６に転送されるようにする。
【０１８５】
以上、コンテンツ再生制御処理の流れを説明した。このコンテンツ再生制御処理では、アプリケーション１２１により、デコーダ１０６に転送されるDASHセグメント（メディアセグメント）のムビーフラグメントが制御されることで、放送サーバ１０からストリーミング配信されるコンテンツの再生が制御される。
【０１８６】
（コンテンツ再生処理）
最後に、図２１のフローチャートを参照して、コンテンツ再生処理の流れを説明する。
【０１８７】
ステップＳ２４１乃至Ｓ２４２においては、図１９のステップＳ２０１乃至２０２と同様に、RFデモジュレータ１０１によって、受信された放送波から、物理層フレームが抽出される。
【０１８８】
ステップＳ２４３において、放送ミドルウェア１０２は、フィルタリング処理を行う。このフィルタリング処理では、LLSシグナリングやSLSシグナリングに基づいて、物理層フレームに対する復調処理で得られる復調データから、IPパケットやUDPパケットが抽出され、ROUTEセッションで伝送されるDASHセグメントが抽出される。
【０１８９】
ステップＳ２４４において、DASHクライアント１０５は、ステップＳ２４３の処理で得られるDASHセグメントを処理する。ただし、DASHクライアント１０５は、アプリケーション１２１からの制御（図２０のステップＳ２２４の処理）に従い、適切なタイミングで、DASHセグメント（メディアセグメント）のムビーフラグメントが、デコーダ１０６に渡されるようにする。
【０１９０】
ステップＳ２４５において、デコーダ１０６は、ステップＳ２４４の処理で適切なタイミングで転送されてくる、DASHセグメントから得られるビデオとオーディオのデータのデコードを行う。
【０１９１】
ステップＳ２４６において、出力部１０７は、ステップＳ２４５の処理でデコードされたビデオとオーディオのデータに対するレンダリングを行い、その結果得られるデータを出力する。
【０１９２】
以上、コンテンツ再生処理の流れを説明した。このコンテンツ再生処理では、アプリケーション１２１によるコンテンツ再生制御処理（図２０）に従い、放送サーバ１０からストリーミング配信されるコンテンツの再生が行われる。
【０１９３】
これにより、例えば、放送サーバ１０とクライアント装置２０（のアプリケーション１２１）とで、時刻情報を同期することができない場合に、クライアント装置２０において、アプリケーション１２１からシステム時刻を簡単に変更できないときであっても、当該クライアント装置２０は、確実に、放送サーバ１０からストリーミング配信されるコンテンツを再生することができる。
【０１９４】
なお、上述した説明では、時刻対応情報を用いた同期制御として、コンテンツの再生制御を説明したが、例えば、アプリケーション１２１が処理すべきイベントとして、時間同期が必要なイベントが通知された場合には、上述した時刻対応情報を用いた同期制御を用いることで、放送局側が意図する正確な提示制御を行うことができる。
【０１９５】
＜６．変形例＞
【０１９６】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０１９７】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV）等の有線放送などの規格に適用することができる。
【０１９８】
また、上述したシグナリングやパケットなどの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象のシグナリングやパケットなどの実質的な内容が異なるものではない。例えば、ALP(ATSC Link-layer Protocol)パケットは、Genericパケットなどと称される場合がある。
【０１９９】
さらに、アプリケーションは、HTML5等のマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションに限らず、例えば、Java（登録商標）等のプログラミング言語で開発されたアプリケーションであってもよい。また、アプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、OS（Operating System）環境（提示制御環境）などで実行されるようにしてもよい。
【０２００】
また、本技術は、伝送路として、放送網以外の伝送路、すなわち、例えば、インターネットや電話網等の通信回線（通信網）などを利用することを想定して規定されている所定の規格（デジタル放送の規格以外の規格）などにも適用することができる。その場合には、伝送システム１（図１）の伝送路３０として、インターネットや電話網などの通信回線が利用され、放送サーバ１０は、インターネット上に設けられた通信サーバとすることができる。そして、当該通信サーバと、クライアント装置２０とが、伝送路３０（通信回線）を介して双方向の通信を行うことになる。
【０２０１】
＜７．コンピュータの構成＞
【０２０２】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０２０３】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０２０４】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０２０５】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０２０６】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０２０７】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０２０８】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０２０９】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０２１０】
また、本技術は、以下のような構成をとることができる。
【０２１１】
（１）
コンテンツを受信する受信部と、
前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生を制御する制御部と
を備える受信装置。
（２）
前記コンテンツは、前記コンテンツのデータを伝送する単位であるフレーム単位で伝送され、
前記第１の時刻情報は、前記フレームに含まれ、
前記制御部は、
前記フレームに含まれる前記第１の時刻情報が受信された場合、前記第１の時刻情報が受信されたタイミングに応じた前記第２の時刻情報を取得し、
取得された前記第２の時刻情報を、受信された前記第１の時刻情報と対応付けて、前記時刻対応情報として管理する
（１）に記載の受信装置。
（３）
前記制御部は、
過去のある時点での第１の時刻情報と第２の時刻情報とを対応付けた前記時刻対応情報を取得し、
その時点での第２の時刻情報を取得し、
前記その時点での第２の時刻情報と、前記過去のある時点での第２の時刻情報と、前記過去のある時点での第１の時刻情報との関係から、その時点での第１の時刻情報を算出し、
算出された前記その時点での第１の時刻情報に基づいて、前記コンテンツの再生を制御する
（２）に記載の受信装置。
（４）
前記時刻対応情報は、前記過去のある時点での第１の時刻情報が示す時刻と、前記過去のある時点での第２の時刻情報が示す時刻のそれ自体を表した情報、又は前記過去のある時点での第１の時刻情報が示す時刻と、前記過去のある時点での第２の時刻情報が示す時刻との差分の情報である
（３）に記載の受信装置。
（５）
前記コンテンツは、放送波により配信される放送コンテンツであり、
前記第１の時刻情報は、PTP(Precision Time Protocol)であり、
前記第２の時刻情報は、システム時刻（System Time）である
（１）乃至（４）のいずれかに記載の受信装置。
（６）
前記第１の時刻情報は、任意のフレームに含まれ、
前記第１の時刻情報が示す時刻は、当該フレームの先頭の位置の時刻を表している
（２）に記載の受信装置。
（７）
前記制御部は、
前記コンテンツを再生するためのアプリケーションと、
前記時刻対応情報を管理するためのミドルウェアと
の動作を制御し、
前記ミドルウェアは、前記アプリケーションからの要求に応じて、前記時刻対応情報を提供し、
前記アプリケーションは、前記ミドルウェアから提供される前記時刻対応情報に基づいて、前記コンテンツの再生を制御する
（１）乃至（６）のいずれかに記載の受信装置。
（８）
前記フレームは、前記第１の時刻情報を補正するための時刻メタデータを含むプリアンブルを有し、
前記制御部は、前記時刻メタデータに基づいて、前記第１の時刻情報を補正する
（２）に記載の受信装置。
（９）
前記コンテンツは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠してストリーミング配信され、
前記制御部は、MPD(Media Presentation Description)メタデータに基づいて、前記コンテンツの再生を制御する
（１）乃至（８）のいずれかに記載の受信装置。
（１０）
受信装置のデータ処理方法において、
前記受信装置が、
コンテンツを受信し、
前記コンテンツの送信側から提供される第１の時刻情報と、前記コンテンツの受信側で生成される第２の時刻情報とを対応付けた時刻対応情報に基づいて、前記第２の時刻情報に対応した前記第１の時刻情報に応じた時間軸で、前記コンテンツの再生を制御する
ステップを含むデータ処理方法。
【符号の説明】
【０２１２】
１  伝送システム，  １０  放送サーバ，  ２０  クライアント装置，  ３０  伝送路，  １０１  RFデモジュレータ，  １０２  放送ミドルウェア，  １０３  記憶部，  １０４  ブラウザ，  １０５  DASHクライアント，  １０６  デコーダ，  １０７  出力部，  １２１  アプリケーション，  １０００  コンピュータ，  １００１  CPU
【図１】
2017195668.tif 000003
【図２】
2017195668.tif 000004
【図３】
2017195668.tif 000005
【図４】
2017195668.tif 000006
【図５】
2017195668.tif 000007
【図６】
2017195668.tif 000008
【図７】
2017195668.tif 000009
【図８】
2017195668.tif 000010
【図９】
2017195668.tif 000011
【図１０】
2017195668.tif 000012
【図１１】
2017195668.tif 000013
【図１２】
2017195668.tif 000014
【図１３】
2017195668.tif 000015
【図１４】
2017195668.tif 000016
【図１５】
2017195668.tif 000017
【図１６】
2017195668.tif 000018
【図１７】
2017195668.tif 000019
【図１８】
2017195668.tif 000020
【図１９】
2017195668.tif 000021
【図２０】
2017195668.tif 000022
【図２１】
2017195668.tif 000023
【図２２】
2017195668.tif 000024
【国際調査報告】
2017195668.tif 000025
2017195668.tif 000026
2017195668.tif 000027
2017195668.tif 000028