JPWO2016056412A1 - 受信装置、受信方法、送信装置、及び、送信方法 - Google Patents
受信装置、受信方法、送信装置、及び、送信方法 Download PDFInfo
- Publication number
- JPWO2016056412A1 JPWO2016056412A1 JP2016553048A JP2016553048A JPWO2016056412A1 JP WO2016056412 A1 JPWO2016056412 A1 JP WO2016056412A1 JP 2016553048 A JP2016553048 A JP 2016553048A JP 2016553048 A JP2016553048 A JP 2016553048A JP WO2016056412 A1 JPWO2016056412 A1 JP WO2016056412A1
- Authority
- JP
- Japan
- Prior art keywords
- service
- metadata
- component
- stream
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/26—Arrangements for switching distribution systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/42—Arrangements for resource management
- H04H20/423—Transmitter side
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/86—Arrangements characterised by the broadcast information itself
- H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
- H04H60/73—Systems specially adapted for using specific information, e.g. geographical or meteorological information using meta-information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H2201/00—Aspects of broadcast communication
- H04H2201/40—Aspects of broadcast communication characterised in that additional data relating to the broadcast data are available via a different channel than the broadcast channel
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本技術は、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できるようにする受信装置、受信方法、送信装置、及び、送信方法に関する。受信装置は、IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得し、第2のメタデータに基づいて、第1のメタデータを取得し、第1のメタデータに基づいて、放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する。本技術は、例えば、テレビ受像機に適用することができる。
Description
本技術は、受信装置、受信方法、送信装置、及び、送信方法に関し、特に、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できるようにした受信装置、受信方法、送信装置、及び、送信方法に関する。
近年、各国では、デジタル放送のサービスが開始されている(例えば、特許文献1参照)。各国のデジタル放送の規格では、伝送方式としてMPEG2-TS(Moving Picture Experts Group phase 2 - Transport Stream)方式が採用されているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
ところで、IP伝送方式を用いて、ビデオやオーディオ、字幕等のコンポーネントを伝送する方式の候補の1つとして、ROUTE(Real-time Object Delivery over Unidirectional Transport)がある。ROUTEは、放送のライブサービス向けに、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
しかしながら、サービス(例えば番組)を構成するコンポーネントをROUTEセッションで伝送する場合における技術方式が確立されておらず、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できるようにしたいという要請があった。
本技術はこのような状況に鑑みてなされたものであり、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できるようにするものである。
本技術の第1の側面の受信装置は、IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得する第1の取得部と、前記第2のメタデータに基づいて、前記第1のメタデータを取得する第2の取得部と、前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部とを備える受信装置である。
本技術の第1の側面の受信装置は、独立した装置であってもよいし、1つの装置を構成している内部ブロックであってもよい。また、本技術の第1の側面の受信方法は、上述した本技術の第1の側面の受信装置に対応する受信方法である。
本技術の第1の側面の受信装置、及び、受信方法においては、IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータが取得され、前記第2のメタデータに基づいて、前記第1のメタデータが取得され、前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生が制御される。
本技術の第2の側面の送信装置は、IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成する生成部と、生成された前記第2のメタデータを送信する送信部とを備える送信装置である。
本技術の第2の側面の送信装置は、独立した装置であってもよいし、1つの装置を構成している内部ブロックであってもよい。本技術の第2の側面の送信方法は、上述した本技術の第2の側面の送信装置に対応する送信方法である。
本技術の第2の側面の送信装置、及び、送信方法においては、IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータが生成され、生成された前記第2のメタデータが送信される。
本技術の第1の側面、及び、第2の側面によれば、サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得できる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
1.システムの構成
2.運用例
(1)運用例1:放送基本サービス選局(固定受信機、ダイレクト選局)
(2)運用例2−1:ハイブリッドサービス選局1(固定受信機、ダイレクト選局)
(3)運用例2−2:ハイブリッドサービス選局2(固定受信機、ダイレクト選局)
(4)運用例3:放送基本サービス選局(モバイル受信機、ESG選局)
(5)運用例4:放送基本サービス選局(固定受信機、ESG選局)
(6)運用例5−1:ロバストサービス選局1(固定受信機、ダイレクト選局)
(7)運用例5−2:ロバストサービス選局2(固定受信機、ダイレクト選局)
3.システムを構成する各装置の構成
4.各装置で実行される処理の流れ
5.シンタックスの例
(1)LLSシグナリングデータ
(2)SCSシグナリングデータ
6.変形例
7.コンピュータの構成
2.運用例
(1)運用例1:放送基本サービス選局(固定受信機、ダイレクト選局)
(2)運用例2−1:ハイブリッドサービス選局1(固定受信機、ダイレクト選局)
(3)運用例2−2:ハイブリッドサービス選局2(固定受信機、ダイレクト選局)
(4)運用例3:放送基本サービス選局(モバイル受信機、ESG選局)
(5)運用例4:放送基本サービス選局(固定受信機、ESG選局)
(6)運用例5−1:ロバストサービス選局1(固定受信機、ダイレクト選局)
(7)運用例5−2:ロバストサービス選局2(固定受信機、ダイレクト選局)
3.システムを構成する各装置の構成
4.各装置で実行される処理の流れ
5.シンタックスの例
(1)LLSシグナリングデータ
(2)SCSシグナリングデータ
6.変形例
7.コンピュータの構成
<1.システムの構成>
(固定受信機が用いられる場合のサービス提供システムの構成例)
図1は、固定受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図1は、固定受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図1において、サービス提供システム1は、固定受信機としての受信装置20Aに対して、サービスの提供を行うシステムである。サービス提供システム1は、送信装置10、受信装置20A、ブロードバンドサーバ30、及び、インターネットサーバ40から構成される。また、受信装置20Aは、インターネット90を介して、ブロードバンドサーバ30及びインターネットサーバ40と相互に接続されている。
送信装置10は、例えば地上デジタルテレビ放送の所定の規格に対応した送信機であって、放送事業者により提供されて放送局に設置される。なお、本技術の実施の形態の地上デジタルテレビ放送の規格としては、例えば、ATSC(Advanced Television Systems Committee standards)等の規格を採用することができる。
送信装置10は、サービス(例えば番組)を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、シグナリングデータとともに、IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波によって送信する。
なお、シグナリングデータには、サービスに依存しないLLS(Low Layer Signaling)シグナリングデータと、サービス単位のSCS(Service Channel Signaling)シグナリングデータの2種類が存在するが、その詳細な内容については後述する。
また、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータは、ROUTEセッションにより伝送される。ROUTEは、放送のライブサービス向けに、FLUTE(RFC6276,5775,5651)を拡張したものである。なお、ROUTEは、FLUTE +(FLUTE plus)やFLUTE enhancementなどと称される場合がある。
ROUTEセッションでは、送信するファイルなどを1つのオブジェクトとして、TOI(Transport Object Identifier)により管理する。また、複数のオブジェクトの集合を1つのセッションとして、TSI(Transport Session Identifier)により管理する。すなわち、ROUTEセッションにおいては、TSIとTOIの2つの識別情報によって特定のファイルを指定することが可能となる。
受信装置20Aは、例えば地上デジタルテレビ放送の所定の規格に対応したテレビ受像機やセットトップボックスなどの固定受信機であって、例えば各ユーザの家庭に設置される。また、受信装置20Aは、通信機能を有しており、インターネット90を介して、ブロードバンドサーバ30又はインターネットサーバ40にアクセスすることができる。ただし、受信装置20Aは必ずしも、通信機能を有している必要はない。
受信装置20Aは、送信装置10から送信されるデジタル放送の放送波を受信して、当該デジタル放送の放送波で伝送されるシグナリングデータを取得する。受信装置20Aは、取得されたシグナリングデータに基づいて、送信装置10から送信されるデジタル放送の放送波で伝送されるサービス(を構成するコンポーネント)のストリームに接続して、そのストリームから得られる映像と音声を再生(出力)する。
ブロードバンドサーバ30は、受信装置20Aからの要求に応じて、サービス(例えば番組)を構成するビデオやオーディオ、字幕等のコンポーネントのストリームを、インターネット90を介してストリーミング配信する。また、ブロードバンドサーバ30は、受信装置20Aからの要求に応じて、シグナリングデータを、インターネット90を介して配信する。
受信装置20Aは、送信装置10又はブロードバンドサーバ30からのシグナリングデータに基づいて、ブロードバンドサーバ30からインターネット90を介してストリーミング配信されるサービス(を構成するコンポーネント)のストリームに接続して、そのストリームから得られる映像と音声を再生(出力)する。
インターネットサーバ40は、受信装置20Aからの要求に応じて、各種の情報を配信するサーバである。例えば、インターネットサーバ40は、緊急警報に関する緊急警報情報を配信するようにすることができる。この場合、受信装置20Aは、インターネットサーバ40にインターネット90を介してアクセスすることで、インターネットサーバ40から緊急警報情報を取得して表示することができる。
(モバイル受信機が用いられる場合のサービス提供システムの構成例)
図2は、モバイル受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図2は、モバイル受信機が用いられる場合のサービス提供システムの構成例を示す図である。
図2において、サービス提供システム2は、モバイル受信機としての受信装置20Bが放送エリアを移動した場合でも、継続的にサービスを提供可能なシステムである。サービス提供システム2は、図1のサービス提供システム1と比べて、受信装置20Aの代わりに、受信装置20Bが設けられ、さらに、中継局50とアクセスポイント60が設けられている。
送信装置10から送信されるデジタル放送の放送波は、中継局50を介して、当該中継局50の放送エリア内の受信装置20Bにより受信される。また、アクセスポイント60は、公衆無線LAN(Local Area Network)のアクセスポイントであって、アクセスポイント60の通信エリア内の受信装置20Bは、アクセスポイント60を介してインターネット90に接続することが可能である。
受信装置20Bは、例えば、スマートフォンや携帯電話機、タブレット型コンピュータ、パーソナルコンピュータ、自動車内で利用される端末などのモバイル受信機であって、例えば地上デジタルテレビ放送の所定の規格に対応している。
受信装置20Bは、アクセスポイント60を介してインターネット90に接続し、ブロードバンドサーバ30から、シグナリングデータを取得する。また、受信装置20Bは、送信装置10から送信されるデジタル放送の放送波を、中継局50を介して受信して、当該デジタル放送の放送波で伝送されるシグナリングデータを取得する。
受信装置20Bは、送信装置10又はブロードバンドサーバ30から取得したシグナリングデータに基づいて、送信装置10又はブロードバンドサーバ30から伝送される、サービス(を構成するコンポーネント)のストリームに接続して、そのストリームから得られる映像と音声を再生(出力)する。
なお、図2においては、説明の都合上、1つの送信装置10と、1つの中継局50が設置された構成を示したが、実際には、1以上の送信装置10と、複数の中継局50が設置され、複数の中継局50による複数の放送エリアを、モバイル受信機としての受信装置20Bが移動することになる。また、受信装置20Bは、アクセスポイント60を介さずに、例えばLTE(Long Term Evolution)等のモバイル系のネットワークを介して、ブロードバンドサーバ30に接続するようにしてもよい。
サービス提供システム1、2は、以上のように構成される。なお、以下の説明では、受信装置20Aと、受信装置20Bを特に区別する必要がない場合には、単に、受信装置20と称して説明する。
(シグナリングデータの例)
図3は、シグナリングデータの例を示す図である。
図3は、シグナリングデータの例を示す図である。
シグナリングデータには、LLS(Low Layer Signaling)ストリームで伝送されるLLSシグナリングデータと、SCS(Service Channel Signaling)ストリームで伝送されるSCSシグナリングデータがある。
LLSシグナリングデータは、サービスに依存しない低レイヤのシグナリングデータであって、IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される。例えば、LLSシグナリングデータとしては、SCD(Service Configuration Description),EAD(Emergency Alerting Description),RRD(Region Rating Description),DCD(Default Component Description)等のLLSメタデータが含まれる。
また、SCSシグナリングデータは、サービス単位のシグナリングデータであって、IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される。例えば、SCSシグナリングデータとしては、USBD(User Service Bundle Description),USD(User Service Description),SDP(Session Description Protocol),MPD(Media Presentation Description),IS(Initialization Segment),LSID(LCT Session Instance Description),ESGc(Electric Service Guide Current),SPD(Service Parameter Description)等のSCSメタデータが含まれる。なお、SCSシグナリングデータは、ROUTEセッションで伝送される。
SCDは、MPEG2-TS方式に対応したID体系によって、ネットワーク内のBBPストリーム構成とサービス構成を示している。また、SCDには、ESGストリームに接続するためのESGブートストラップ情報や、SCSストリームに接続するためのSCブートストラップ情報、SCSシグナリングデータを通信経由で取得するためのSCSブロードバンドロケーション情報などが記述されている。
SCブートストラップ情報には、SCSシグナリングデータを取得するためのIPアドレス、ポート番号、及び、TSIのほか、基本サービスフラグとハイブリッドフラグが指定されている。基本サービスフラグは、LSIDのみで、サービスを構成するコンポーネントを取得できるかどうかを示すフラグである。ハイブリッドフラグは、ブロードバンドサーバ30から配信されるコンポーネントのストリームがあるかどうかを示すフラグである。
ここで、図4には、基本サービスフラグとハイブリッドフラグの組み合わせの例を示している。なお、SCDにおいて、SCブートストラップ情報は、SCBootstrap要素により指定される。また、図中の「@」は、属性を表しており、基本サービスフラグとハイブリッドフラグは、SCBootstrap要素のLSIDBaseService属性とhybrid属性により指定される。なお、SCBootstrap要素の詳細な内容は、図30のSCDのシンタックスを参照して後述する。
図4において、基本サービスフラグとハイブリッドフラグには、1ビットのフラグとして、"TRUE"又は"FALSE"が指定される。すなわち、図4においては、基本サービスフラグとして"TRUE"が指定された場合、ハイブリッドフラグを利用することができない(図中の"N/A")が、ハイブリッドフラグとして"FALSE"が指定されるようにしてもよい。また、基本サービスフラグとして"FALSE"が指定された場合、ハイブリッドフラグには、"FALSE"又は"TRUE"を指定することができる。
具体的には、基本サービスフラグとして"TRUE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一のROUTEセッションにより伝送されることになる。また、サービスを構成するコンポーネントとSCSのストリームは、同一のROUTEセッションにより伝送される。そのため、IPアドレスとポート番号は、SCブートストラップ情報により解決し、ROUTEセッション内の情報は、LSIDにより解決することになる。
また、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一又は複数のROUTEセッションにより伝送されることになる。
ここでは、単一のROUTEセッションで、複数のビデオ、複数のオーディオ、又は複数の字幕など、同一のMIMEタイプのストリームを伝送することが想定されている。あるいは、複数のROUTEセッションで、基本のビデオ及びオーディオと、ロバストオーディオが伝送されることが想定される。また、LSIDは、同一のMIMEタイプの区別がつかないため、複数のROUTEセッションを記述しないので、USBD(USD),MPD,SPDを用いることになる。なお、この場合、ハイブリッドフラグに、"FALSE"が指定されているため、サービスを構成するコンポーネントの中に、通信経由で取得されるコンポーネントが存在しないことになる。
また、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定された場合、サービスを構成するコンポーネントのストリームは、単一又は複数のROUTEセッション、あるいは通信経由で伝送されることになる。
ここでは、単一のROUTEセッションで、複数のビデオ、複数のオーディオ、又は複数の字幕など、同一のMIMEタイプのストリームを伝送することが想定されている。あるいは、複数のROUTEセッションで、基本のビデオ及びオーディオと、ロバストオーディオが伝送されることが想定される。また、この場合、ハイブリッドフラグに、"TRUE"が指定されているため、例えばセカンダリオーディオ等の通信経由で取得されるコンポーネントのストリームを用いることになる。なお、LSIDは、同一のMIMEタイプの区別がつかないため、USBD(USD),MPD,SPDを用いることになる。
なお、SCSブロードバンドロケーション情報には、SCSシグナリングデータの取得先を示すロケーション情報のほか、基本サービスフラグとハイブリッドフラグが指定されるが、これらのフラグの意味は、図4のSCブートストラップ情報に指定されるフラグと同様とされる。また、詳細については、図30を参照して後述するが、SCDにおいて、SCSブロードバンドロケーション情報は、SignalingOverInternet要素により指定され、基本サービスフラグとハイブリッドフラグは、SignalingOverInternet要素のLSIDBaseService属性とhybrid属性により指定される。
このように、基本サービスフラグとハイブリッドフラグは、SCBootstrap要素とSignalingOverInternet要素に設定できる。そして、SCBootstrap要素で指定される基本サービスフラグとハイブリッドフラグは、SCBootstrap要素により指定される、放送ストリームに流れるSCSの属性を示している。また、SignalingOverInternet要素に指定される基本サービスフラグとハイブリッドフラグは、SignalingOverInternet要素により指定される、インターネット90上のブロードバンドサーバ30から取得されるSCSの属性を示している。なお、SCBootstrap要素とSignalingOverInternet要素において、LSIDBaseService属性とhybrid属性を合わせた1つの属性を定義して、その属性に、同様の機能を持たせるようにしてもよい。
図3の説明に戻り、EADは、緊急警報に関する緊急警報情報を含んでいる。RRDは、レーティングに関する情報を含んでいる。DCDは、SCSシグナリングデータに先行して取得される、最小限のサービスの選局を行うための情報である。USBDは、MPD,SDP等のSCSメタデータを参照するための参照情報を含んでいる。なお、USBDは、USDと称される場合がある。SDPは、サービス単位のサービス属性、ストリームの構成情報や属性、フィルタ情報、ロケーション情報などを含んでいる。
MPDは、サービス単位で伝送されるコンポーネントのストリームの再生を管理するための情報であって、セグメントURL(Uniform Resource Locator)などの情報を含んでいる。ISは、ROUTEセッションにおけるメディアセグメント(MS:Media Segment)に対するイニシャライゼーションセグメントである。
なお、USBD,USD,MPD,SPD,ISは、3GPP(Third Generation Partnership Project),MPEG(Moving Picture Expert Group),又はIETF(Internet Engineering Task Force)のいずれかによって規格化されたものを参照するものとする。
LSIDは、FLUTEのFDT(File Delivery Table)をリアルタイムサービス向けに拡張したものであって、ROUTEセッションごとに伝送されるコンポーネントのストリームの管理情報とされる。なお、LSIDは、他のSCSメタデータと異なるROUTEセッションで伝送するようにしてもよい。ESGcは、ESGのカレント情報であって、現在放送中の番組についての情報を伝送するものである。なお、ESGは、OMA(Open Mobile Alliance)によって規格化されている。SPDは、サービスレベルのパラメータが定義される。
なお、SCD等のLLSメタデータと、USBDやLSID等のSCSメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述することができる。
<2.運用例>
(1)運用例1:放送基本サービス選局(固定受信機、ダイレクト選局)
運用例1は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントが放送のみで提供されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
(システムパイプモデル)
図5は、運用例1のシステムパイプモデルを示す図である。
図5は、運用例1のシステムパイプモデルを示す図である。
図5において、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)においては、1つのBBP(Base Band Packet)ストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル(Service Channel)、ESGサービス、及び、NTP(Network Time Protocol)のストリームが伝送されている。
LLSは、サービスに依存しない低レイヤのLLSシグナリングデータを伝送する。LLSシグナリングデータには、例えば、SCD等のLLSメタデータが含まれる。
サービスチャンネル(以下、「サービス」ともいう)は、SCSと、ビデオやオーディオ、字幕等のコンポーネント(Component)から構成される。なお、各サービス(例えば番組)を構成する要素には、共通のIPアドレスが付与されており、このIPアドレスを用いて、サービスごとに、コンポーネントやSCSシグナリングデータなどをパッケージ化することができる。
SCSは、サービス単位のSCSシグナリングデータを伝送する。SCSシグナリングデータには、例えば、USBDやLSID等のSCSメタデータが含まれる。なお、サービスは、UDP/IP(User Datagram Protocol/Internet Protocol)のプロトコルに従って伝送される。ESGサービス(以下、「ESG」ともいう)は、電子サービスガイド(電子番組表)である。NTPは、時刻情報である。
なお、所定の周波数帯域を有する放送波(RF Channel)には、例えば放送事業者ごとに、RFアロケーションID(RF Allocation ID)が割り当てられている。また、各放送波で伝送される1又は複数のBBPストリームには、BBPストリームID(BBP Stream ID)が割り当てられる。さらに、各BBPストリームで伝送される1又は複数のサービスには、サービスID(Service ID)が割り当てられる。
このように、IP伝送方式のID体系としては、MPEG2-TS方式で用いられているネットワークID(Network ID)と、トランスポートストリームID(Transport Stream ID)と、サービスID(Service ID)の組み合わせ(以下、「トリプレット(Triplet)」という)に対応する構成が採用され、このトリプレットによって、ネットワーク内のBBPストリーム構成とサービス構成が示される。
このようなID体系を用いることで、現在広く普及しているMPEG2-TS方式との整合をとることができる。なお、IP伝送方式のID体系では、RFアロケーションIDとBBPストリームIDが、MPEG2-TS方式におけるネットワークIDとトランスポートストリームIDに対応している。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。受信装置20Aにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される(S11)。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCSシグナリングデータを取得するためのSCブートストラップ情報が記述されている。
また、受信装置20Aにおいて、ユーザによりサービスが選局(ダイレクト選局)された場合には、当該サービスのSCブートストラップ情報に従い、SCSシグナリングデータが取得される(S12)。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグ(LSIDBaseService)として"TRUE"が指定され、かつハイブリッドフラグ(hybrid)として"FALSE"が指定されているので、受信装置20Aは、LSIDのみを参照すれば、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる(S13)。
したがって、受信装置20Aは、LSIDを参照して、MIMEタイプに対応したビデオとオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続することができる(S14)。なお、ここでは、ハイブリッドフラグ(hybrid)として"FALSE"が指定されているので、サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在しないことになる。
なお、図5においては、放送経由で伝送されるSCSシグナリングデータとして、LSIDを図示して、LSIDのみを参照して、ビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD(図中の点線で示している)やその他のSCSメタデータが参照されるようにしてもよい。また、LSIDに字幕の情報を追加することで、ビデオやオーディオだけでなく、字幕のストリームに接続されるようにしてもよい。
また、図5においては、LSIDを、他のSCSメタデータとともに、同一のROUTEセッションで伝送する場合を例示しているが、LSIDは、他のSCSメタデータと異なるROUTEセッションで伝送するようにしてもよい。なお、ROUTEセッションにおいて、LSIDのTSIの値は、"0"とされる。
(シーケンス図)
次に、図6を参照して、運用例1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図6において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図6において、時間の方向は、図中の左側から右側の方向とされる。
次に、図6を参照して、運用例1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図6において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図6において、時間の方向は、図中の左側から右側の方向とされる。
図6において、放送局に設置された送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム(BBP Stream)により伝送されている。ただし、サービスを構成するコンポーネント及びSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
図6に示すように、各家庭等に設置された固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAM(Non Volatile RAM)に記録される(S21)。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCSシグナリングデータを取得するためのIPアドレス、ポート番号、及び、TSIが指定されたSCブートストラップ情報が記述されている。
また、サービスIDで識別されるサービスごとのSCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"TRUE"が指定され、かつハイブリッドフラグには、"FALSE"が指定されているので、LSIDに記述された内容のみでコンポーネントの取得先を特定することができ、さらに、コンポーネントが通信経由では配信されていないことを表している。すなわち、この場合、対象のサービスを構成するコンポーネントのストリームは、単一のROUTEセッションで伝送されていることになる。
受信装置20Aは、例えばユーザによりサービス(例えば番組)の選局操作(ダイレクト選局)が行われた場合、NVRAMからSCD(選局情報)を読み出して、当該サービスのSCブートストラップ情報に従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S22)。これにより、受信装置20Aは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる(S23)。
ここでは、SCDの基本サービスフラグによって、LSIDに記述された内容のみでコンポーネントの取得先を特定できることがわかっているので、SCSシグナリングデータとして、LSIDのみを取得すればよいことになる。ただし、受信装置20Aは、必要に応じてSPD等の他のSCSメタデータを取得するようにしてもよい。なお、SCSシグナリングデータは、ROUTEセッションで伝送されているので、LCTヘッダが付加されたLCTパケットに格納されたデータを解析することで、LSID(のファイル)が取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するビデオとオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置20Aは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオとオーディオのストリームに接続する(S24)。これにより、受信装置20Aは、ROUTEセッションで伝送されているビデオデータとオーディオデータを取得することができる(S25)。
なお、ビデオデータとオーディオデータは、ROUTEセッションで伝送されているので、LCTヘッダが付加されたLCTパケットに格納されたセグメントデータ(メディアセグメント)を抽出することで、それらのデータが取得されることになる。
そして、受信装置20Aでは、放送経由で取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ダイレクト選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
以上のように、運用例1では、固定受信機としての受信装置20Aにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"TRUE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているため、ダイレクト選局されたサービスを構成するコンポーネントのストリームは、単一のROUTEセッションで伝送されていることになる。また、LSIDのみを参照すれば、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
すなわち、受信装置20Aは、全てのSCSメタデータを参照することなく、LSIDのみを用いて、所望のコンポーネントを取得することができるので、サービスを構成するコンポーネントがROUTEセッションで伝送されている場合に、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
(2)運用例2−1:ハイブリッドサービス選局1(固定受信機、ダイレクト選局)
運用例2−1は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントが放送と通信のハイブリッドで提供されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
(システムパイプモデル)
図7は、運用例2−1のシステムパイプモデルを示す図である。
図7は、運用例2−1のシステムパイプモデルを示す図である。
図7の運用例2−1においては、図5の運用例1と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、1つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル(サービス)、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ(Primary Video)及びプライマリオーディオ(Primary Audio)のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。
また、運用例2−1においては、ブロードバンドサーバ30により、インターネット90を介してセカンダリオーディオ(Secondary Audio)がストリーミング配信されている。受信装置20Aは、インターネット90を介してブロードバンドサーバ30にアクセスすることで、セカンダリオーディオデータを取得することができる。
すなわち、受信装置20Aにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される(S31)。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が記述されている。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、受信装置20Aは、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできない。また、当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
受信装置20Aにおいて、ユーザによりサービスが選局(ダイレクト選局)された場合には、当該サービスのSCブートストラップ情報に従い、SCSストリームに接続されることで、USBD,MPD,SDP等のSCSメタデータが取得される(S32)。
また、受信装置20Aは、ステップS32の処理で取得されたUSBDを参照して、MPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット90を介してブロードバンドサーバ30にアクセスすることで、ダイレクト選局されたサービスを構成するセカンダリオーディオのストリームに接続することができる(S33,S34)。
また、受信装置20Aは、USBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する(S35,S36)。そして、受信装置20Aは、ステップS36の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる(S37)。
なお、図7においては、放送経由で伝送されるSCSシグナリングデータとして、LSID,USBD,MPD,SDPを図示して、それらのSCSメタデータを参照して、放送と通信経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD(図中の点線で示している)やその他のSCSメタデータが参照されるようにしてもよい。
(シーケンス図)
次に、図8を参照して、運用例2−1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図8において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図8において、時間の方向は、図中の左側から右側の方向とされる。
次に、図8を参照して、運用例2−1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図8において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図8において、時間の方向は、図中の左側から右側の方向とされる。
図8において、送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム(BBP Stream)により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図8において、ブロードバンドサーバ30は、インターネット90を介してセカンダリオーディオデータをストリーミング配信している。
図8に示すように、固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAMに記録される(S41)。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
SCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。すなわち、この場合、対象のサービスを構成するコンポーネントは、単一のROUTEセッションで伝送されているが、コンポーネント(オーディオ)の一部は、通信経由で配信されていることになる。
受信装置20Aは、例えばユーザによりサービスの選局操作(ダイレクト選局)が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCブートストラップ情報に従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S42)。これにより、受信装置20Aは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる(S43)。
なお、SCSシグナリングデータは、ROUTEセッションで伝送されているので、LCTパケットに格納されたデータを解析することで、USBD,MPD,SDP等のSCSメタデータ(のファイル)が取得される。例えば、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用い、MPDやSDP等のSCSメタデータを取得することになるが、それらのSCSメタデータは、同一のSCSストリームで伝送されるので、そこから一括して取得するようにしてもよい。
受信装置20Aは、ステップS43の処理で取得されたMPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット90を介してブロードバンドサーバ30にアクセスする(S44)。これにより、受信装置20Aは、ブロードバンドサーバ30からストリーミング配信される、ダイレクト選局されたサービスを構成するセカンダリオーディオデータを取得することができる(S45)。
また、受信装置20Aは、ステップS43の処理で取得されたSDPに従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S46)。これにより、受信装置20Aは、ROUTEセッションで伝送されているLSIDやSPDを取得することができる(S47)。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。ただし、ここでは、プライマリオーディオ(例えば第1言語)の代わりに、セカンダリオーディオ(例えば第2言語)が再生されるので、プライマリビデオのコンポーネントに関する情報のみが用いられる。
受信装置20Aは、プライマリビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオのストリームに接続する(S48)。これにより、受信装置20Aは、ROUTEセッションで伝送されているプライマリビデオデータを取得することができる(S49)。
そして、受信装置20Aは、放送経由で取得されたプライマリビデオデータと、通信経由で取得されたセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ダイレクト選局されたサービスに対応した番組の映像と音声が再生される。
なお、ここでは、通信経由で取得されたセカンダリオーディオ(例えば第2言語)が再生される例を説明したが、例えば、ユーザにより所定の操作された場合や、受信装置20Aが通信機能を有していない場合などに、放送経由で取得されるプライマリオーディオ(例えば第1言語)が再生されるようにしてもよい。
以上のように、運用例2−1では、固定受信機としての受信装置20Aにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送されるとともに、コンポーネント(オーディオ)の一部は、通信経由で配信されていることになる。また、LSIDのほか、MPD等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置20Aは、SCブートストラップ情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
(3)運用例2−2:ハイブリッドサービス選局2(固定受信機、ダイレクト選局)
運用例2−2は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントが放送と通信のハイブリッドで提供されている場合に、当該サービスがダイレクト選局されたときの他の運用例を表している。
(システムパイプモデル)
図9は、運用例2−2のシステムパイプモデルを示す図である。
図9は、運用例2−2のシステムパイプモデルを示す図である。
図9の運用例2−2においては、図5の運用例1と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、1つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル(サービス)、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ(Primary Video)及びプライマリオーディオ(Primary Audio)のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。
また、運用例2−2においては、運用例2−1と同様に、ブロードバンドサーバ30によって、インターネット90を介してセカンダリオーディオ(Secondary Audio)がストリーミング配信されるとともに、SCSシグナリングデータが配信されている。受信装置20Aは、インターネット90を介してブロードバンドサーバ30にアクセスすることで、セカンダリオーディオデータやSCSシグナリングデータを取得することができる。
すなわち、受信装置20Aにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される(S51)。なお、SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報と、SCSブロードバンドロケーション情報が記述されている。
ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできず、さらに当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
また、SCDのSCSブロードバンドロケーション情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできず、さらに当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在することになる。
受信装置20Aにおいて、ユーザによりサービスが選局(ダイレクト選局)された場合には、当該サービスのSCSブロードバンドロケーション情報に指定されるURI(Uniform Resource Identifier)に従い、インターネット90を介してブロードバンドサーバ30にアクセスすることで、USBD,MPD,SDP等のSCSメタデータが取得される(S52,S53)。
そして、受信装置20Aは、ステップS53の処理で取得されたUSBDを参照して、MPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット90を介してブロードバンドサーバ30にアクセスすることで、ダイレクト選局されたサービスを構成するセカンダリオーディオのストリームに接続することができる(S54)。
また、受信装置20Aは、USBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する(S55,S56)。そして、受信装置20Aは、ステップS56の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる(S57)。
なお、図9においては、放送又は通信経由で伝送されるSCSシグナリングデータとして、LSID,USBD,MPD,SDPを図示して、それらのSCSメタデータを参照して、放送と通信経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD(図中の点線で示している)やその他のSCSメタデータが参照されるようにしてもよい。
(シーケンス図)
次に、図10を参照して、運用例2−2を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図10において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図10において、時間の方向は、図中の左側から右側の方向とされる。
次に、図10を参照して、運用例2−2を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図10において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図10において、時間の方向は、図中の左側から右側の方向とされる。
図10において、送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム(BBP Stream)により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図10において、ブロードバンドサーバ30は、インターネット90を介してセカンダリオーディオデータ及びSCSシグナリングデータを配信している。
図10に示すように、固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、LLSストリームで伝送されているSCDが取得され、NVRAMに記録される(S61)。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報と、SCSブロードバンドロケーション情報が、サービスごとに記述されている。
SCブートストラップ情報には、IPアドレスやポート番号等のほかに、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。すなわち、この場合、対象のサービスを構成するコンポーネントは、単一のROUTEセッションで伝送されているが、コンポーネント(オーディオ)の一部は、通信経由で配信されていることになる。
また、SCSブロードバンドロケーション情報には、SCSシグナリングデータの取得先を示すURIのほかに、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"TRUE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの一部が通信経由でも配信されていることを表している。
受信装置20Aは、例えばユーザによりサービスの選局操作(ダイレクト選局)が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCSブロードバンドロケーション情報のURIに従い、インターネット90を介してブロードバンドサーバ30にアクセスする(S62)。これにより、受信装置20Aは、通信経由でSCSシグナリングデータを取得することができる(S63)。ここでは、SCSシグナリングデータとして、USBD,MPD,SDP等のSCSメタデータ(のファイル)が取得される。
そして、受信装置20Aは、ステップS63の処理で取得されたMPDに記述されたセカンダリオーディオのセグメントURLに従い、インターネット90を介してブロードバンドサーバ30にアクセスする(S64)。これにより、受信装置20Aは、ブロードバンドサーバ30からストリーミング配信される、ダイレクト選局されたサービスを構成するセカンダリオーディオデータを取得することができる(S65)。
また、受信装置20Aは、ステップS63の処理で取得されたSDPに従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S66)。これにより、受信装置20Aでは、ROUTEセッションで伝送されているLSIDやSPDを取得することができる(S67)。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。ただし、ここでは、プライマリオーディオ(例えば第1言語)の代わりに、セカンダリオーディオ(例えば第2言語)が再生されるので、プライマリビデオのコンポーネントに関する情報のみが用いられる。
受信装置20Aは、プライマリビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオのストリームに接続する(S68)。これにより、受信装置20Aは、ROUTEセッションで伝送されているプライマリビデオデータを取得することができる(S69)。
そして、受信装置20Aは、放送経由で取得されたプライマリビデオデータと、通信経由で取得されたセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される。
以上のように、運用例2−2では、固定受信機としての受信装置20Aにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報又はSCSブロードバンドロケーション情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"TRUE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送されるとともに、コンポーネント(オーディオ)の一部は、通信経由で配信されていることになる。また、LSIDのほか、MPD等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置20Aは、SCブートストラップ情報又はSCSブロードバンドロケーション情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。また、運用例2−2では、SCSシグナリングデータが、放送経由のみならず、通信経由でも取得されるので、放送波で伝送されるSCSシグナリングデータのデータ量を少なくして、その利用帯域を少なくすることができる。
なお、運用例2−2の変形例として、SCブートストラップ情報において、基本サービスフラグに"TRUE"、ハイブリッドフラグに"FALSE"がそれぞれ指定され、SCSブロードバンドロケーション情報において、ハイブリッドフラグに"TRUE"が指定されるようにすることで、放送経由で伝送されるSCSシグナリングデータとして、放送経由で伝送されるプライマリビデオデータとプライマリオーディオデータのみを受信するためのSCSシグナリングデータが伝送されていることを示すようにすることができる。また、この場合、SCSブロードバンドロケーション情報のハイブリッドフラグが"TRUE"であることから、通信経由で伝送されているSCSシグナリングデータとして、放送経由で伝送されるプライマリビデオデータとプライマリオーディオデータ、及び、通信経由で伝送されるセカンダリオーディオデータを受信するためのSCSシグナリングデータが伝送されていることを示すことになる。
(4)運用例3:放送基本サービス選局(モバイル受信機、ESG選局)
運用例3は、モバイル受信機としての受信装置20B(図2)において、サービスを構成するコンポーネントが放送(と通信)で提供されている場合に、当該サービスがESG選局されたときの運用例を表している。
(システムパイプモデル)
図11は、運用例3のシステムパイプモデルを示す図である。
図11は、運用例3のシステムパイプモデルを示す図である。
図11の運用例3においては、図5の運用例1と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、1つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル(サービス)、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、プライマリビデオ(Primary Video)及びプライマリオーディオ(Primary Audio)のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置10から送信され、モバイル受信機である受信装置20Bにより受信される。
また、運用例3においては、ブロードバンドサーバ30によって、インターネット90を介してSCSシグナリングデータとESGデータが配信されている。受信装置20Bは、インターネット90を介してブロードバンドサーバ30にアクセスすることで、SCSシグナリングデータやESGデータを取得することができる。
すなわち、受信装置20Bにおいては、ユーザにより所定の操作(例えば電子番組表の取得指示)が行われた場合、あらかじめ取得済みのESGデータの取得先のURLに従い、ブロードバンドサーバ30にアクセスすることで、ESGデータが取得される(S71)。また、受信装置20Bにおいて、ユーザが、ESGデータに対応した電子番組表を利用して、サービスの選局(ESG選局)を行った場合、ESGデータに基づいて、インターネット90を介してブロードバンドサーバ30にアクセスすることで、USBD,MPD,SDP等のSCSメタデータが取得される(S72,S73)。
そして、受信装置20Bは、ステップS73の処理で取得されたUSBDを参照して、SDPに従い、放送波で伝送されているSCSストリームに接続することで、LSIDを取得する(S74,S75)。そして、受信装置20Bは、ステップS75の処理で取得されたLSIDを参照して、MIMEタイプに対応したプライマリビデオとプライマリオーディオのTSIとTOIを用い、ESG選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続することができる(S76)。
なお、図11においては、放送又は通信経由で伝送されるSCSシグナリングデータとして、LSID,USBD,MPD,SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD(図中の点線で示している)やその他のSCSメタデータが参照されるようにしてもよい。
また、図11において、受信装置20Bでは、ESGデータに対応した電子番組表を利用して、サービスの選局(ESG選局)が行われたが、ブロードバンドサーバ30から配信されるサービス視聴用のアプリケーションを介してESGデータを取得して、サービスの選局が行われるようにしてもよい。さらに、図11においては、放送波で伝送されるプライマリビデオとプライマリオーディオのストリームに接続される場合を例示したが、USBDから参照されるMPDを用いることで、ブロードバンドサーバ30から配信されるセカンダリオーディオのストリームに接続されるようにしてもよい。
(シーケンス図)
次に、図12を参照して、運用例3を採用した場合の受信装置20Bにおける具体的な処理の流れを説明する。なお、図12において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Bにおける処理の流れを表している。また、図12において、時間の方向は、図中の左側から右側の方向とされる。
次に、図12を参照して、運用例3を採用した場合の受信装置20Bにおける具体的な処理の流れを説明する。なお、図12において、図中の上側は、送信装置10とブロードバンドサーバ30から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Bにおける処理の流れを表している。また、図12において、時間の方向は、図中の左側から右側の方向とされる。
図12において、送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム(BBP Stream)により伝送されている。ただし、サービスを構成するコンポーネントとしてのプライマリビデオデータ及びプライマリオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
また、図12において、ブロードバンドサーバ30は、インターネット90を介して、ESGデータとSCSシグナリングデータを配信している。なお、ブロードバンドサーバ30は、セカンダリオーディオデータを配信するようにしてもよい。
図12に示すように、モバイル受信機としての受信装置20Bにおいては、アプリケーション(APP)が起動されており、例えば当該アプリケーションにて電子番組表を表示する場合には、インターネット90を介してブロードバンドサーバ30にアクセスし、ESGデータを取得する(S81)。これにより、受信装置20Bにおいては、アプリケーションによって、通信経由で取得されたESGデータに応じた電子番組表が表示される。
ここで、例えばユーザにより電子番組表に基づいたサービスの選局操作(ESG選局)が行われた場合、受信装置20Bは、ESGデータに基づいて、インターネット90を介してブロードバンドサーバ30にアクセスする(S82)。これにより、受信装置20Bは、通信経由でSCSシグナリングデータを取得することができる(S83)。ここでは、ESGデータを用いることで、USBD,MPD,SDP等のSCSメタデータを取得することになる。
また、受信装置20Bは、ステップS83の処理で取得されたSDPに従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S84)。これにより、受信装置20Bでは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる(S85)。ここでは、SCSシグナリングデータとして、LSIDやSPD等のSCSメタデータが取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ESG選局されたサービスを構成するプライマリビデオとプライマリオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置20Bは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているプライマリビデオとプライマリオーディオのストリームに接続する(S86)。これにより、受信装置20Bは、ROUTEセッションで伝送されているプライマリビデオデータとプライマリオーディオデータを取得することができる(S87)。
そして、受信装置20Bでは、放送経由で取得されたプライマリビデオデータとセカンダリオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ESG選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
なお、図12の例では、プライマリビデオデータとセカンダリオーディオデータが両方とも放送経由で取得される場合を説明したが、プライマリオーディオの代わりに、セカンダリオーディオを通信経由で取得する場合には、ステップS83の処理で取得されたMPDのセグメントURLに従い、インターネット90を介してブロードバンドサーバ30にアクセスすることで、セカンダリオーディオデータを取得することができる。
以上のように、運用例3では、モバイル受信機としての受信装置20Bにおいて、サービスがESG選局された場合について説明した。
(5)運用例4:放送基本サービス選局(固定受信機、ESG選局)
運用例4は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントが放送のみで提供されている場合に、当該サービスがESG選局されたときの運用例を表している。
(システムパイプモデル)
図13は、運用例4のシステムパイプモデルを示す図である。
図13は、運用例4のシステムパイプモデルを示す図である。
図13の運用例4においては、図5の運用例1と同様に、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、1つのBBPストリームが伝送されている。また、このBBPストリームでは、LLS、サービスチャンネル(サービス)、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、ビデオ、オーディオ、及び、字幕のコンポーネントから構成される。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。
すなわち、受信装置20Aにおいては、ユーザにより所定の操作が行われた場合、NVRAMから読み出されるSCDのESGブートストラップ情報に従い、ESGストリームで伝送されているESGデータが取得される(S91)。
受信装置20Aにおいて、ユーザがESGデータに対応した電子番組表を利用して、サービスの選局(ESG選局)を行った場合、ESG選局されたサービスに応じて、SCSストリームからUSBDが取得される(S92)。なお、ESG選局されたサービスは、SCDのグローバルユニークサービスID(GUSI)によって、USBDと紐付けられている。また、USBDの参照情報により、MPDやSDP等のSCSメタデータが取得される。
また、受信装置20Aは、USBDを参照して、SDPに従い、SCSストリームに接続することで、LSIDを取得する(S93,S94)。そして、受信装置20Aは、ステップS94の処理で取得されたLSIDを参照して、MIMEタイプに対応したビデオとオーディオのTSIとTOIを用い、ESG選局されたサービスを構成するビデオとオーディオのストリームに接続することができる(S95)。
なお、図13においては、放送経由で伝送されるSCSシグナリングデータとして、LSID,USBD,MPD,SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるビデオとオーディオのストリームに接続する場合を説明したが、必要に応じてSPD(図中の点線で示している)やその他のSCSメタデータが参照されるようにしてもよい。
(シーケンス図)
次に、図14を参照して、運用例4を採用した場合の受信装置20Aの具体的な処理の流れを説明する。なお、図14において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図14において、時間の方向は、図中の左側から右側の方向とされる。
次に、図14を参照して、運用例4を採用した場合の受信装置20Aの具体的な処理の流れを説明する。なお、図14において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図14において、時間の方向は、図中の左側から右側の方向とされる。
図14において、放送局の送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが、BBPストリーム(BBP Stream)により伝送されている。ただし、サービスを構成するコンポーネントとしてのビデオデータ及びオーディオデータ、並びにSCSシグナリングデータは、同一のROUTEセッションで伝送されている。
図14に示すように、固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、LLSで伝送されているSCDが取得され、NVRAMに記録されている。SCDには、物理パラメータとしての周波数やトリプレットのほか、ESGブートストラップ情報が記述されている。
受信装置20Aは、例えばユーザにより電子番組表の表示が指示された場合、NVRAMから読み出されるSCDのESGブートストラップ情報に従い、送信装置10からの放送波で伝送されているESGストリームに接続する(S101)。これにより、受信装置20Aは、ESGストリームで伝送されているESGデータを取得することができる(S102)。
例えばユーザにより電子番組表に基づいたサービスの選局操作(ESG選局)が行われた場合、受信装置20Aは、ESG選局されたサービスに応じたSCSストリームに接続する(S103)。これにより、受信装置20Aは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる(S104)。ここで、ESG選局されたサービスと、USBDは、SCDのグローバルユニークサービスIDにより紐付けられているが、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用いて、MPDやSDP等のSCSメタデータを取得することになる。
また、受信装置20Aは、ステップS104の処理で取得されたSDPに従い、送信装置10からの放送波で伝送されているSCSストリームに接続する(S105)。これにより、受信装置20Aでは、ROUTEセッションで伝送されているSCSシグナリングデータを取得することができる(S106)。ここでは、SCSシグナリングデータとして、LSIDやSPD等のSCSメタデータが取得される。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ESG選局されたサービスを構成するビデオとオーディオのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置20Aは、これらのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッションで伝送されているビデオとオーディオのストリームに接続する(S107)。これにより、受信装置20Aは、ROUTEセッションで伝送されているビデオデータとオーディオデータを取得することができる(S108)。
そして、受信装置20Aは、放送経由で取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、ESG選局されたサービスに対応した番組の映像と音声が再生される。なお、映像と音声の同期再生には、LCTヘッダの拡張領域によって伝送されるNTPのタイムスタンプを用いることができる。また、LCTヘッダの拡張領域に、NTPタイムスタンプが伝送されていない場合には、別の手段として、SCSストリームで伝送されているMPDを取得して、MPDの基準時刻と、DASHセグメントのmoofボックスに格納されるピクチャ単位のデコード時刻と、表示時刻情報から、デコード時刻及び表示時刻を算出するようにすればよい。
以上のように、運用例4では、固定受信機としての受信装置20Aにおいて、サービスがESG選局された場合について説明した。
(6)運用例5−1:ロバストサービス選局1(固定受信機、ダイレクト選局)
運用例5−1は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントが複数のROUTEセッションで伝送されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
(システムパイプモデル)
図15は、運用例5−1のシステムパイプモデルを示す図である。
図15は、運用例5−1のシステムパイプモデルを示す図である。
図15の運用例5−1の放送波の構成は、図5の運用例1の放送波と同様の構成からなるが、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、2つのBBPストリームが伝送されている。
ここでは、一方のBBPストリーム(BBPストリームID="y")では、LLS、サービスチャンネル(サービス)、ESGサービス、及び、NTPのストリームが伝送されている。また、サービスは、SCSシグナリングデータと、ビデオ及びオーディオのコンポーネントから構成される。他方のBBPストリーム(BBPストリームID="ro")では、LSIDと、2つのロバストオーディオ(Robust Audio1,Robust Audio2)のストリームが伝送されている。
このように、運用例5−1では、基本のビデオとオーディオのストリームほかに、品質は落ちるが高ロバストネスなロバストオーディオのストリームが伝送されている。また、ロバストオーディオとしては、強度のレベルの異なるロバストオーディオ1とロバストオーディオ2の2つのストリームが伝送されている。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。
すなわち、受信装置20Aにおいては、初期スキャン処理等により、LLSストリームで伝送されるSCDが取得される(S111)。ここで、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているので、受信装置20Aは、LSIDのみを参照しても、選局されたサービスを構成するビデオとオーディオのストリームに接続するための全ての情報を取得することはできない。また、当該サービスを構成するコンポーネントの中には、通信経由で取得されるコンポーネントが存在しないことになる。
受信装置20Aにおいて、ユーザによりサービスが選局(ダイレクト選局)された場合には、当該サービスのSCブートストラップ情報に従い、一方のBBPストリーム(BBPストリームID="y")で伝送されるSCSストリームに接続されることで、USBD,MPD,SDP等のSCSメタデータが取得される(S112,S113)。
また、受信装置20Aは、USBDを参照して、SDPに従い、他方のBBPストリーム(BBPストリームID="ro")で伝送されているSCSストリームに接続することで、LSIDを取得する(S114,S115)。そして、受信装置20Aは、ステップS115の処理で取得されたLSIDを参照して、MIMEタイプに対応したロバストオーディオ1とロバストオーディオ2のTSIとTOIを用い、ダイレクト選局されたサービスを構成するロバストオーディオ1又はロバストオーディオ2のストリームに接続することができる(S116)。例えば、視聴環境が悪い場合において、基本のビデオとオーディオが視聴できないときには、ロバストオーディオの音声のみを再生するといった運用を行うことができる。
なお、図15においては、放送経由で伝送されるSCSシグナリングデータとして、LSID,USBD,MPD,SDPを図示して、それらのSCSメタデータを参照して、放送経由で伝送されるロバストオーディオのストリームに接続する場合を説明したが、必要に応じてSPDやLSID(図中の点線で示している)、その他のSCSメタデータが参照されるようにしてもよい。
(シーケンス図)
次に、図16を参照して、運用例5−1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図16において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図16において、時間の方向は、図中の左側から右側の方向とされる。
次に、図16を参照して、運用例5−1を採用した場合の受信装置20Aにおける具体的な処理の流れを説明する。なお、図16において、図中の上側は、送信装置10から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図16において、時間の方向は、図中の左側から右側の方向とされる。
図16において、送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、一方のBBPストリーム(以下、「BBPストリーム1」という)で、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、ESGデータ、NTPデータ、並びにLLSシグナリングデータが伝送されている。また、他方のBBPストリーム(以下、「BBPストリーム2」という)で、ロバストオーディオと、LSIDのストリームが伝送されている。
ただし、BBPストリーム1において、ビデオ、オーディオ、及び、SCSシグナリングデータのストリームを伝送するROUTEセッションと、BBPストリーム2において、2つのロバストオーディオ、及び、LSIDを伝送するROUTEセッションとは、異なるROUTEセッションとされる。ここでは、前者を、「ROUTEセッション1」と称し、後者を、「ROUTEセッション2」と称して区別するようにする。
図16に示すように、固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、BBPストリーム1のLLSストリームで伝送されているSCDが取得され、NVRAMに記録される(S121)。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
SCブートストラップ情報には、基本サービスフラグとハイブリッドフラグが指定されている。ここでは、基本サービスフラグには、"FALSE"が指定され、かつハイブリッドフラグには、"FALSE"が指定されているので、LSIDに記述された内容のみではコンポーネントの取得先を特定することができず、さらに、コンポーネントの全てが放送経由で配信されていることを表している。
受信装置20Aは、例えばユーザによりサービスの選局操作(ダイレクト選局)が行われた場合、NVRAMからSCDを読み出して、当該サービスのSCブートストラップ情報に従い、送信装置10からの放送波で伝送されているBBPストリーム1のSCSストリームに接続する(S122)。これにより、受信装置20Aは、ROUTEセッション1で伝送されているSCSシグナリングデータを取得することができる(S123)。ここでは、USBDにはSCSメタデータの参照情報が記述されているので、この参照情報を用いてMPDやSDPが取得される。
また、受信装置20Aは、ステップS123の処理で取得されたSDPに従い、送信装置10からの放送波で伝送されているBBPストリーム2のLSIDストリームに接続する(S124)。これにより、受信装置20Aでは、ROUTEセッション2で伝送されているLSIDを取得することができる(S125)。
LSIDには、MIMEタイプに対応したビデオとオーディオのTSIとTOIが記述されている。すなわち、LSIDを参照することで、ダイレクト選局されたサービスを構成するビデオとロバストオーディオ1のストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIが特定されることになる。
受信装置20Aは、ビデオのIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッション1で伝送されているビデオのストリームに接続する(S126)。これにより、受信装置20Aは、ROUTEセッション1で伝送されているビデオデータを取得することができる(S127)。
また、受信装置20Aは、ロバストオーディオ1のIPアドレス、ポート番号、TSI、及び、TOIに従い、ROUTEセッション2で伝送されているロバストオーディオ1のストリームに接続する(S128)。これにより、受信装置20Aは、ROUTEセッション2で伝送されているロバストオーディオデータを取得することができる(S129)。
そして、受信装置20Aは、ROUTEセッション1から取得されたビデオデータと、ROUTEセッション2から取得されたロバストオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される。
以上のように、運用例5−1では、固定受信機としての受信装置20Aにおいて、サービスがダイレクト選局された場合に、SCDのSCブートストラップ情報には、基本サービスフラグとして"FALSE"が指定され、かつハイブリッドフラグとして"FALSE"が指定されているので、対象のサービスを構成するコンポーネントは、単一又は複数のROUTEセッションで伝送され、コンポーネントの全てが、放送経由で配信されていることになる。また、LSIDのほか、SDP等の他のSCSメタデータを参照することで、ROUTEセッションにおいて、当該サービスを構成するビデオとオーディオのストリームに接続するための全ての情報が得られることになる。
例えば、受信装置20Aは、SCブートストラップ情報の基本サービスフラグとハイブリッドフラグを参照することで、サービスを構成するコンポーネントがROUTEセッションでのみ伝送されているかどうかや、LSIDのみでロケーションを解決できるかどうかなどを、SCSシグナリングデータを取得するよりも先に認識することができるので、当該サービスを構成するコンポーネントを効率よく適切に、かつ容易に取得することができる。
(7)運用例5−2:ロバストサービス選局2(固定受信機、ダイレクト選局)
運用例5−2は、固定受信機としての受信装置20A(図1)において、サービスを構成するコンポーネントとSCSシグナリングデータが、複数のROUTEセッションで伝送されている場合に、当該サービスがダイレクト選局されたときの運用例を表している。
(システムパイプモデル)
図17は、運用例5−2のシステムパイプモデルを示す図である。
図17は、運用例5−2のシステムパイプモデルを示す図である。
図17の運用例5−2の放送波の構成は、図15の運用例5−1の放送波と同様の構成からなり、所定の周波数帯域からなる放送波に対応した物理チャンネル(RF Channel)において、2つのBBPストリームが伝送されているが、サービスチャンネルが、2つのBBPストリームにまたがっている点が異なっている。
ここでは、一方のBBPストリーム(BBPストリームID="X")では、ESGサービス、NTP、LLS、及び、サービスチャンネル(サービス)の一部のストリームが伝送され、他方のBBPストリーム(BBPストリームID="ro")では、LSID、2つのロバストオーディオ、サービスチャンネル(サービス)の一部のストリームが伝送されている。
すなわち、ROUTEセッションとBBPストリームとは独立しており、1つのROUTEセッションを構成する要素が、同一のBBPストリームで伝送される必要はないので、例えば、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータとが、異なるBBPストリームで伝送されるようにしてもよい。例えば、図17においては、ビデオとオーディオのコンポーネントが、一方のBBPストリーム(BBPストリームID="X")で伝送され、SCSシグナリングデータが、他方のBBPストリーム(BBPストリームID="ro")で伝送されている。
この場合、他方のBBPストリーム(BBPストリームID="ro")は、ロバストオーディオを伝送するための高ロバストなパイプとなるので、ビデオとオーディオのデータは高品位を保ちながら、SCSシグナリングデータをより確実に伝送することが可能となる。
例えば、視聴環境が悪い場合において、基本のビデオとオーディオが視聴できないときには、ロバストオーディオの音声のみを再生するといった運用が想定されるが、SCSシグナリングデータが取得できないと、ロバストオーディオの音声を再生することができない。そのため、SCSシグナリングデータを、高ロバストなパイプで伝送することで、そのような視聴環境でもSCSシグナリングデータを取得できるようにして、確実に、ロバストオーディオの再生が行われるようにしている。
以上のような構成からなる放送波が、送信装置10から送信され、固定受信機である受信装置20Aにより受信される。
なお、受信装置20Aにおいては、ステップS131乃至S136の処理が実行され、ダイレクト選局されたサービスを構成するロバストオーディオ1又はロバストオーディオ2に接続されることになるが、その処理の流れは、図15のステップS111乃至S116の処理と同様であるので、ここではその説明は省略するものとする。
<3.システムを構成する各装置の構成>
次に、図18乃至図21を参照して、図1のサービス提供システム1又は図2のサービス提供システム2を構成する各装置の詳細な構成として、送信装置10、受信装置20、及び、ブロードバンドサーバ30の構成について説明する。
(送信装置の構成例)
図18は、本技術を適用した送信装置の一実施の形態の構成を示す図である。
図18は、本技術を適用した送信装置の一実施の形態の構成を示す図である。
図18に示すように、送信装置10は、シグナリング生成部111、シグナリング処理部112、ビデオデータ取得部113、ビデオエンコーダ114、オーディオデータ取得部115、オーディオエンコーダ116、字幕データ取得部117、字幕エンコーダ118、ESG生成部119、ESG処理部120、Mux121、及び、送信部122から構成される。
シグナリング生成部111は、外部のサーバや内蔵するストレージ等から、シグナリングデータを生成するための元データを取得する。シグナリング生成部111は、シグナリングデータの元データを用いて、シグナリングデータを生成し、シグナリング処理部112に供給する。
シグナリング処理部112は、シグナリング生成部111から供給されるシグナリングデータを処理して、Mux121に供給する。ここでは、シグナリングデータとして、SCD等のLLSメタデータからなるLLSシグナリングデータと、USBDやLSID等のSCSメタデータからなるSCSシグナリングデータが生成される。
ビデオデータ取得部113は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ114に供給する。ビデオエンコーダ114は、ビデオデータ取得部113から供給されるビデオデータを、MPEG(Moving Picture Experts Group)等の符号化方式に準拠して符号化し、Mux121に供給する。
オーディオデータ取得部115は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ116に供給する。オーディオエンコーダ116は、オーディオデータ取得部115から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、Mux121に供給する。
字幕データ取得部117は、外部のサーバや内蔵するストレージ等から提供される字幕データを取得し、字幕エンコーダ118に供給する。字幕エンコーダ118は、字幕データ取得部117から供給される字幕データを、MPEG等の符号化方式に準拠して符号化し、Mux121に供給する。
ESG生成部119は、外部のサーバや内蔵するストレージ等から、ESGデータを生成するための元データを取得する。ESG生成部119は、ESGデータの元データを用いて、ESGデータを生成し、ESG処理部120に供給する。ESG処理部120は、ESG生成部119から供給されるESGデータを処理して、Mux121に供給する。
Mux121は、シグナリング処理部112からのシグナリングデータのストリームと、ビデオエンコーダ114からのビデオのストリームと、オーディオエンコーダ116からのオーディオのストリームと、字幕エンコーダ118からの字幕のストリームと、ESG処理部120からのESGデータのストリームを多重化してBBPストリームを生成し、送信部122に供給する。送信部122は、Mux121から供給されるBBPストリームを、IP伝送方式を用いたデジタル放送の放送波(デジタル放送信号)として、アンテナ123を介して送信する。
なお、ビデオやオーディオ等のコンポーネントと、SCSシグナリングデータのストリームは、ROUTEセッションで伝送される。また、ビデオやオーディオ等のコンポーネントのストリームを、ROUTEセッションで伝送する場合には、各コンポーネントのファイルを、ISO BMFFの規定に準じたセグメントごとに分割し、それにより得られるセグメントデータをLCTパケットに格納して伝送することになる。
また、デジタル放送信号において、LLSストリームにより伝送されるLLSシグナリングデータ(例えばSCD等のLLSメタデータ)を格納したLLSパケットのLLSヘッダ、あるいは、SCSストリームにより伝送されるSCSシグナリングデータ(例えばUSBDやLSID等のSCSメタデータ)を格納したLCTパケットのLCTヘッダには、フィルタリング情報を配置することができる。このフィルタリング情報としては、圧縮情報(Compression Scheme)、タイプ情報(Fragment Type)、拡張タイプ情報(Type Extension)、又は、バージョン情報などが配置される。
ここで、圧縮情報には、対象のシグナリングデータの圧縮の有無を示す情報が指定される。タイプ情報には、対象のシグナリングデータのタイプを示す情報が指定される。拡張タイプ情報には、シグナリングデータのタイプごとに設定される拡張されたフィルタリング情報が任意に設定される。バージョン情報には、対象のシグナリングデータのバージョンを示す情報が指定される。これにより、受信装置20では、LLSヘッダ又はLCTヘッダのフィルタリング情報を用い、LLSパケット又はLCTパケットのフィルタリング処理を行うことで、対象のシグナリングデータを取得することができる。
(受信装置の構成例)
図19は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
図19は、本技術を適用した受信装置の一実施の形態の構成を示す図である。
図19に示すように、受信装置20は、チューナ212、Demux213、制御部214、NVRAM215、入力部216、通信部217、Demux218、ビデオデコーダ219、ビデオ出力部220、ディスプレイ221、オーディオデコーダ222、オーディオ出力部223、スピーカ224、及び、字幕デコーダ225から構成される。
チューナ212は、制御部214からの制御に従い、アンテナ211を介して受信したIP伝送方式を用いたデジタル放送の放送波(デジタル放送信号)から、ユーザの選局操作に応じたデジタル放送信号を抽出して復調し、その結果得られるBBPストリームを、Demux213に供給する。
Demux213は、制御部214からの制御に従い、チューナ212から供給されるBBPストリームを、ビデオやオーディオ、字幕のストリームと、シグナリングデータに分離する。Demux213は、ビデオデータをビデオデコーダ219に、オーディオデータをオーディオデコーダ222に、字幕データを字幕デコーダ225に、シグナリングデータを制御部214にそれぞれ供給する。
制御部214は、受信装置20の各部の動作を制御する。また、制御部214は、Demux213又は通信部217から供給されるシグナリングデータに基づいて、放送経由又は通信経由で伝送されるコンポーネントのストリームに接続して、当該コンポーネントの再生を制御するために、各部の動作を制御する。なお、制御部214の詳細な構成については、図20を参照して後述する。
NVRAM215は、不揮発性メモリであって、制御部214からの制御に従い、各種のデータを記録する。入力部216は、ユーザの操作に応じて、操作信号を制御部214に供給する。
通信部217は、制御部214からの制御に従い、インターネット90を介してブロードバンドサーバ30に接続し、コンポーネントのストリームの配信を要求する。通信部217は、インターネット90を介してブロードバンドサーバ30からストリーミング配信されるコンポーネントのストリームを受信して、Demux218に供給する。また、通信部217は、制御部214からの制御に従い、インターネット90を介してブロードバンドサーバ30から、SCSシグナリングデータ又はESGデータを受信し、制御部214に供給する。
Demux218は、制御部214からの制御に従い、通信部217から供給されるコンポーネントのストリームを、ビデオデータと、オーディオデータと、字幕データに分離し、ビデオデータをビデオデコーダ219に、オーディオデータをオーディオデコーダ222に、字幕データを字幕デコーダ225に供給する。
ビデオデコーダ219には、Demux213又はDemux218からビデオデータが供給される。ビデオデコーダ219は、制御部214からの制御に従い、ビデオデータを、MPEG等の復号方式に準拠して復号し、ビデオ出力部220に供給する。ビデオ出力部220は、ビデオデコーダ219から供給されるビデオデータを、ディスプレイ221に出力する。これにより、ディスプレイ221には、例えば番組の映像が表示される。
オーディオデコーダ222には、Demux213又はDemux218からオーディオデータが供給される。オーディオデコーダ222は、制御部214からの制御に従い、オーディオデータを、MPEG等の復号方式に準拠して復号し、オーディオ出力部223に供給する。オーディオ出力部223は、オーディオデコーダ222から供給されるオーディオデータを、スピーカ224に出力する。これにより、スピーカ224からは、例えば番組の映像に対応する音声が出力される。
字幕デコーダ225には、Demux213又はDemux218から字幕データが供給される。字幕デコーダ225は、制御部214からの制御に従い、字幕データを、MPEG等の復号方式に準拠して復号し、ビデオ出力部220に供給する。ビデオ出力部220は、字幕デコーダ225から供給される字幕データを、ビデオデコーダ219から供給されるビデオデータと合成して、ディスプレイ221に出力する。これにより、ディスプレイ221には、例えば番組の映像に重畳された字幕が表示される。
なお、Demux213は、BBPストリームからESGデータが分離された場合には、ESGデータを、制御部214に供給する。制御部214は、Demux213又は通信部217から供給されるESGデータを、ビデオ出力部220に供給することで、ディスプレイ221には、電子番組表が表示される。また、受信装置20は、通信部217等の通信機能を有しない構成とすることもできる。また、受信装置20がセットトップボックス等である場合には、ディスプレイ221やスピーカ224を有しない構成とすることができる。
(制御部の機能的構成例)
図20は、図19の制御部214における、初期スキャン処理、選局処理、フィルタリング処理、及び、通信処理の制御を行う部分の機能的構成例を示す図である。
図20は、図19の制御部214における、初期スキャン処理、選局処理、フィルタリング処理、及び、通信処理の制御を行う部分の機能的構成例を示す図である。
図20において、制御部214は、選局制御部251、フィルタリング制御部252、シグナリング取得部253、シグナリング解析部254、通信制御部255、及び、パケットヘッダ監視部256から構成される。また、シグナリング取得部253は、LLSシグナリング取得部271及びSCSシグナリング取得部272から構成される。
選局制御部251は、チューナ212により実行される選局処理を制御する。フィルタリング制御部252は、Demux213により実行されるフィルタリング処理を制御する。
初期スキャン処理時においては、選局制御部251がチューナ212を制御し、フィルタリング制御部252がDemux213を制御することで、LLSシグナリング取得部271によって、LLSストリームで伝送されるLLSシグナリングデータが取得され、シグナリング解析部254に供給される。シグナリング解析部254は、LLSシグナリング取得部271からのLLSシグナリングデータ(SCD等のLLSメタデータ)を解析して得られる選局情報を、NVRAM215に記録する。
選局制御部251は、ユーザにより選局操作が行われた場合、入力部216からの操作信号に応じて、NVRAM215に記録された選局情報(SCD)を取得する。選局制御部251は、取得された選局情報に基づいて、チューナ212により実行される選局処理を制御する。また、選局制御部251は、選局情報(SCD)に含まれるSCブートストラップ情報を、フィルタリング制御部252に供給する。
フィルタリング制御部252は、選局制御部251から供給されるSCブートストラップ情報に基づいて、Demux213により実行されるフィルタリング処理を制御する。これにより、Demux213では、選局対象のサービスを構成するSCSストリームに接続され、当該ストリームがROUTEセッションで伝送されている場合、LCTパケットからSCSシグナリングデータが抽出される。SCSシグナリング取得部272は、SCSシグナリングデータ(USBD,SDP,MPD,LSID等のSCSメタデータ)を取得して、シグナリング解析部254に供給する。
シグナリング解析部254は、SCSシグナリング取得部272から供給されるSCSシグナリングデータ(USBD,SDP,MPD,LSID等のSCSメタデータ)を解析し、その解析結果を、フィルタリング制御部252又は通信制御部255に供給する。すなわち、シグナリング解析部254は、選局対象のサービスを構成するコンポーネントのストリームの配信経路が放送経由となる場合には、それらのコンポーネントのストリームに接続するためのIPアドレス、ポート番号、TSI、及び、TOIを特定し、フィルタリング制御部252に供給する。また、シグナリング解析部254は、選局対象のサービスを構成するコンポーネントのストリームの配信経路が通信経由となる場合には、それらの取得先の情報(例えばURL)を、通信制御部255に供給する。
フィルタリング制御部252は、シグナリング解析部254から供給されるIPアドレス、ポート番号、TSI、及び、TOIに基づいて、Demux213により実行されるフィルタリング処理を制御する。これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出される。そして、その結果得られるビデオデータは、ビデオデコーダ219に供給され、オーディオデータは、オーディオデコーダ222に供給される。また、字幕データは、字幕デコーダ225に供給される。
通信制御部255は、シグナリング解析部254から供給される取得先の情報(例えばURL)に基づいて、通信部217により実行される通信処理を制御する。これにより、通信部217では、ブロードバンドサーバ30からインターネット90を介してストリーミング配信されるコンポーネントのストリームが受信され、Demux218に供給される。そして、Demux218により、通信部217から供給されるストリームから得られるビデオデータがビデオデコーダ219に、オーディオデータがオーディオデコーダ222に、字幕データが字幕デコーダ225にそれぞれ供給される。なお、ブロードバンドサーバ30からSCSシグナリングデータが配信された場合には、通信部217からのSCSシグナリングデータは、SCSシグナリング取得部272に供給される。
パケットヘッダ監視部256は、Demux213においてBBPストリームにより伝送されるパケットを監視して、監視対象のパケットのヘッダを解析する。パケットヘッダ監視部256は、パケットのヘッダの解析結果に従い、フィルタリング制御部252を制御して、特定の条件を満たしたパケットから得られるLLSメタデータやSCSメタデータが、シグナリング取得部253により取得されるようにする。なお、このフィルタリング処理では、例えば、圧縮情報(Compression Scheme)、タイプ情報(Fragment Type)、拡張タイプ情報(Type Extension)、及び、バージョン情報の少なくとも1つの情報を特定の条件として、フィルタリングが行われる。
(ブロードバンドサーバの構成例)
図21は、本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。
図21は、本技術を適用したブロードバンドサーバの一実施の形態の構成を示す図である。
図21に示すように、ブロードバンドサーバ30は、シグナリング生成部311、シグナリング処理部312、ビデオデータ取得部313、ビデオエンコーダ314、オーディオデータ取得部315、オーディオエンコーダ316、字幕データ取得部317、字幕エンコーダ318、ESG生成部319、ESG処理部320、データ保持部321、通信部322、及び、制御部323から構成される。
シグナリング生成部311は、外部のサーバや内蔵するストレージ等から、SCSシグナリングデータを生成するための元データを取得する。シグナリング生成部311は、SCSシグナリングデータの元データを用いて、SCSシグナリングデータを生成し、シグナリング処理部312に供給する。
シグナリング処理部312は、シグナリング生成部311から供給されるSCSシグナリングデータを処理して、データ保持部321に保持させる。ここでは、SCSシグナリングデータとして、USBDやLSID等のSCSメタデータが生成される。
ビデオデータ取得部313は、外部のサーバや内蔵するストレージ、ビデオカメラ等から提供されるビデオデータを取得し、ビデオエンコーダ314に供給する。ビデオエンコーダ314は、ビデオデータ取得部313から供給されるビデオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部321に保持させる。
オーディオデータ取得部315は、外部のサーバや内蔵するストレージ、マイクロフォン等から提供されるオーディオデータを取得し、オーディオエンコーダ316に供給する。オーディオエンコーダ316は、オーディオデータ取得部315から供給されるオーディオデータを、MPEG等の符号化方式に準拠して符号化し、データ保持部321に保持させる。
字幕データ取得部317は、外部のサーバや内蔵するストレージ等から提供される字幕データを取得し、字幕エンコーダ318に供給する。字幕エンコーダ318は、字幕データ取得部317から供給される字幕データを、MPEG等の符号化方式に準拠して符号化し、データ保持部321に保持させる。
ESG生成部319は、外部のサーバや内蔵するストレージ等から、ESGデータを生成するための元データを取得する。ESG生成部319は、ESGデータの元データを用いて、ESGデータを生成し、ESG処理部320に供給する。ESG処理部320は、ESG生成部319から供給されるESGデータを処理して、データ保持部321に保持させる。
データ保持部321は、制御部323からの制御に従い、シグナリング処理部312からのSCSシグナリングデータ、ビデオエンコーダ314からのビデオデータ、オーディオエンコーダ316からのオーディオデータ、字幕エンコーダ318からの字幕データ、及び、ESG処理部320からのESGデータを保持する。
通信部322は、制御部323からの制御に従い、インターネット90を介して受信装置20と通信を行う。通信部322は、受信装置20からの要求に応じて、データ保持部321に保持されている、SCSシグナリングデータ、ビデオデータ、オーディオデータ、字幕データ、又はESGデータを読み出して、インターネット90を介して、その要求元の受信装置20に送信する。
<4.各装置で実行される処理の流れ>
次に、図22乃至図27のフローチャートを参照して、図1のサービス提供システム1又は図2のサービス提供システム2を構成する各装置で実行される具体的な処理の流れについて説明する。
(送信処理)
まず、図22のフローチャートを参照して、送信装置10により実行される送信処理の流れについて説明する。
まず、図22のフローチャートを参照して、送信装置10により実行される送信処理の流れについて説明する。
ステップS151において、シグナリング生成部111は、シグナリングデータの元データを用いて、シグナリングデータを生成し、シグナリング処理部112に供給する。ステップS152において、シグナリング処理部112は、シグナリング生成部111から供給されるシグナリングデータを処理し、Mux121に供給する。
ここでは、シグナリングデータとして、SCD等のLLSメタデータと、USBDやLSID等のSCSメタデータが生成される。ただし、シグナリングデータは、外部のサーバが生成するようにしてもよい。その場合には、シグナリング生成部111は、外部のサーバから供給されるシグナリングデータをそのまま、シグナリング処理部112に供給する。
ステップS153において、ビデオデータ取得部113、オーディオデータ取得部115、及び、字幕データ取得部117は、外部のサーバ等から、コンポーネントとしてのビデオデータ、オーディオデータ、及び、字幕データを取得し、ビデオエンコーダ114、オーディオエンコーダ116、及び、字幕エンコーダ118に供給する。
ステップS154において、ビデオエンコーダ114、オーディオエンコーダ116、及び、字幕エンコーダ118は、ビデオデータ取得部113、オーディオデータ取得部115、及び、字幕データ取得部117から供給される、コンポーネントとしてのビデオデータ、オーディオデータ、及び、字幕データを、MPEG等の符号化方式に準拠して符号化し、Mux121に供給する。
ステップS155において、Mux121は、シグナリング処理部112からのシグナリングデータと、ビデオエンコーダ114からのビデオのストリームと、オーディオエンコーダ116からのオーディオのストリームと、字幕エンコーダ118からの字幕のストリームを多重化してBBPストリームを生成し、送信部122に供給する。
ステップS156において、送信部122は、Mux121から供給されるBBPストリームをデジタル放送信号として、アンテナ123を介して送信する。ステップS116の処理が終了すると、図22の送信処理は終了する。
なお、図22の送信処理において、ビデオやオーディオ、字幕等のコンポーネントのストリームを、ROUTEセッションで伝送する場合には、各コンポーネントのファイルを、ISO BMFFの規定に準じたセグメントごとに分割し、それにより得られるセグメントデータをLCTパケットに格納して伝送することになる。
さらに、デジタル放送信号において、LLSシグナリングデータ(SCD等のLLSメタデータ)を格納したLLSパケットのLLSヘッダ、あるいは、SCSシグナリングデータ(USBDやLSID等のメタデータ)を格納したLCTパケットのLCTヘッダには、圧縮情報(Compression Scheme)、タイプ情報(Fragment Type)、拡張タイプ情報(Type Extension)、及び、バージョン情報などのフィルタリング情報を配置することができる。
以上、送信処理の流れについて説明した。
(初期スキャン処理)
次に、図23のフローチャートを参照して、受信装置20により実行される初期スキャン処理の流れについて説明する。
次に、図23のフローチャートを参照して、受信装置20により実行される初期スキャン処理の流れについて説明する。
ステップS211においては、制御部214によって、入力部216からの操作信号等が監視され、初期スキャンイベントが発生するまで、待機する。そして、ステップS212において、初期スキャンイベントが発生したと判定された場合、処理は、ステップS213に進められる。
ステップS213において、チューナ212は、選局制御部251からの制御に従い、周波数スキャン処理を行う。ステップS214においては、ステップS213の周波数スキャン処理によって、周波数スキャンが成功したかどうかが判定される。
ステップS214において、周波数スキャンが失敗したと判定された場合、処理は、ステップS213の処理に戻り、再度、周波数スキャン処理が行われる。一方、ステップS214において、周波数スキャン処理に成功したと判定された場合、処理は、ステップS215に進められる。
ステップS215において、Demux213は、フィルタリング制御部252からの制御に従い、チューナ212から供給されるBBPストリームを取得して解析する。ステップS216においては、ステップS215の解析結果に従い、BBPストリームからIPパケットが抽出されたかどうかが判定される。
ステップS216において、IPパケットが抽出されたと判定された場合、処理はステップS217に進められる。ステップS217において、Demux213は、抽出されたIPパケットを破棄する。一方、ステップS216において、IPパケット以外のパケットが抽出されたと判定された場合、処理は、ステップS218に進められる。
ステップS218においては、ステップS215の解析結果に従い、BBPストリームからLLSパケットが抽出されたかどうかが判定される。
ステップS218において、LLSパケット以外のパケットが抽出されたと判定された場合、処理は、ステップS217に進められる。ステップS217において、Demux213は、抽出されたLLSパケット以外のパケットを破棄する。一方、ステップS218において、LLSパケットが抽出されたと判定された場合、処理は、ステップS219に進められる。
ステップS219において、Demux213、及び、制御部214は、LLS取得・記録処理を実行する。このLLS取得・記録処理では、LLSパケットに付加されたLLSヘッダのフィルタリング情報に基づいて、フィルタリング処理が行われ、当該フィルタリング処理により取得されたLLSシグナリングデータ(SCD等のLLSメタデータ)が、選局情報としてNVRAM215に記録される。なお、LLS取得・記録処理の詳細な内容は、図24のフローチャートを参照して後述する。
ステップS217、又は、ステップS219の処理が終了すると、処理は、ステップS220に進められる。ステップS220においては、全周波数帯域のスキャンが完了したかどうかが判定される。
ステップS220において、全周波数帯域のスキャンが未完了であると判定された場合、処理は、ステップS213の処理に戻り、ステップS213以降の処理が繰り返される。これにより、各周波数帯域のスキャン処理が行われ、選局情報が記録される。そして、ステップS220において、全周波数帯域のスキャンが完了したと判定された場合、図23の初期スキャン処理は終了される。
以上、初期スキャン処理の流れについて説明した。
(LLS取得・記録処理)
次に、図24のフローチャートを参照して、図23のステップS219の処理に対応するLLS取得・記録処理の詳細な内容について説明する。
次に、図24のフローチャートを参照して、図23のステップS219の処理に対応するLLS取得・記録処理の詳細な内容について説明する。
ステップS231において、パケットヘッダ監視部256は、Demux213においてBBPストリームにより伝送されるLLSパケットを常に監視して、監視対象のLLSパケットのLLSヘッダを解析する。
ステップS232において、パケットヘッダ監視部256は、ステップS231の解析結果に従い、シグナリングデータ(LLSメタデータ)のタイプが一致するかどうかを判定する。すなわち、LLSパケットのLLSヘッダには、タイプ情報(Fragment Type)が配置されているので、パケットヘッダ監視部256は、例えば、Type="000000"であるタイプ情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかを判定する。
なお、LLSヘッダのタイプ情報(Fragment Type)には、LLSメタデータの種別に応じた値が指定される。例えば、SCDには"000000"、EADには"000001"、RRDには"000010"、DCDには"000011"がそれぞれ指定される。
ステップS232において、シグナリングデータ(LLSメタデータ)のタイプが異なると判定された場合、処理は、ステップS233に進められる。ステップS233において、Demux213は、抽出されたLLSパケットを破棄する。一方、ステップS232において、シグナリングデータ(LLSメタデータ)のタイプが一致すると判定された場合、処理は、ステップS234に進められる。
ステップS234において、パケットヘッダ監視部256は、ステップS231の解析結果に従い、対象のLLSシグナリングデータ(LLSメタデータ)が新規取得であるかどうかを判定する。すなわち、LLSパケットのLLSヘッダには、バージョン情報が配置されているので、パケットヘッダ監視部256は、最新のバージョンとなるバージョン情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかを判定する。
ステップS234において、対象のLLSシグナリングデータ(LLSメタデータ)が取得済みであると判定された場合、処理は、ステップS233に進められる。ステップS233において、Demux213は、抽出されたLLSパケットを破棄する。一方、ステップS234において、対象のLLSシグナリングデータ(LLSメタデータ)が新規取得であると判定された場合、処理は、ステップS235に進められる。
ステップS235においては、パケットヘッダ監視部256は、ステップS231の解析結果に従い、拡張フィルタ情報(Filter_Extension)の処理を行う。すなわち、LLSパケットのLLSヘッダには、拡張タイプ情報が配置されているので、この拡張フィルタ情報の処理では、例えば、対象の地域や緊急度など、あらかじめ定められた特定の条件を満たした拡張フィルタ情報が配置されたLLSヘッダが付加されたLLSパケットが抽出されたかどうかが判定される。
なお、フィルタリング制御部252は、パケットヘッダ監視部256からの制御に従い、Demux213を制御して、監視対象のLLSパケットのフィルタリング処理を行っており、監視対象のLLSパケットのうち、特定の条件を満たしたLLSパケットから得られるLLSシグナリングデータが、LLSシグナリング取得部271により取得される。
ステップS236において、シグナリング解析部254は、LLSシグナリング取得部271により取得されたLLSシグナリングデータ(SCD等のLLSメタデータ)を、NVRAM215に記録する。これにより、NVRAM215には、LLSシグナリングデータ(SCD等のLLSメタデータ)から得られる選局情報が記録されることになる。ステップS233、又は、ステップS236の処理が終了すると、処理は、図23のステップS219の処理に戻り、それ以降の処理が実行される。
以上、LLS取得・記録処理の流れについて説明した。
(選局前処理)
次に、図25のフローチャートを参照して、受信装置20により実行される選局前処理の流れについて説明する。
次に、図25のフローチャートを参照して、受信装置20により実行される選局前処理の流れについて説明する。
ステップS251においては、選局制御部251によって、入力部216からの操作信号等が監視され、サービス選局イベントが発生するまで、待機する。そして、ステップS252において、選局イベントが発生したと判定された場合、処理は、ステップS253に進められる。
ステップS253において、選局制御部251は、選局されたサービスに対応するサービスID(チャンネル番号)を取得する。また、ステップS254において、選局制御部251は、NVRAM215を参照して、選局情報(SCD)が記録され、取得済みであるかどうかを判定する。
ステップS254において、選局情報が取得済みであると判定された場合、処理は、ステップS255に進められる。ステップS255において、選局制御部251は、NVRAM215に記録された選局情報(SCD)を読み出して取得する。
一方、ステップS254において、選局情報が取得済みではないと判定された場合、処理は、ステップS256に進められる。ステップS256においては、Demux213、及び、制御部214によって、図24のLLS取得・記録処理と同様の処理が行われ、LLSストリームから、LLSシグナリングデータ(SCD等のLLSメタデータ)が取得される。これにより、制御部214においては、選局情報(SCD)が取得されることになる(S255)。
ステップS257においては、チューナ212、Demux213、及び、制御部214等によって、ステップS255の処理で取得された選局情報に基づいた選局処理が行われる。なお、選局処理の詳細な内容は、図26及び図27のフローチャートを参照して後述する。
以上、選局前処理の流れについて説明した。
(選局処理)
次に、図26のフローチャートを参照して、図25のステップS257の処理に対応する選局処理の詳細な内容を説明する。
次に、図26のフローチャートを参照して、図25のステップS257の処理に対応する選局処理の詳細な内容を説明する。
ステップS271において、制御部214は、受信装置20が通信機能を有しているかどうかを確認することで、受信装置20が放送のみを受信可能であるかどうかを判定する。ステップS271において、例えば、仮に、受信装置20が、通信部217等の通信機能を有しておらず、放送のみを受信可能であると判定された場合、処理は、ステップS272に進められる。
ステップS272において、シグナリング解析部254は、NVRAM215に記録された選局情報(SCD)を参照して、選局されたサービスのSCブートストラップ情報の基本サービスフラグ(LSIDBaseService要素)に、"TRUE"が指定されているかどうかを判定する。
ステップS272において、基本サービスフラグ(LSIDBaseService要素)に、"TRUE"が指定されていると判定された場合、処理は、ステップS273に進められる。ステップS273において、SCSシグナリング取得部272は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップS273の処理で取得されたLSIDは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
ステップS274において、フィルタリング制御部252は、シグナリング解析部254から供給される解析結果(IPアドレス、ポート番号、TSI、及び、TOI)に基づいて、Demux213により実行されるフィルタリング処理を制御する。
これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得(キャプチャ)される。また、ステップS275においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップS274の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得(キャプチャ)される。
そして、例えば、ステップS274の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図25のステップS252の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される(S280)。
このように、SCブートストラップ情報の基本サービスフラグ(LSIDBaseService要素)として"TRUE"が指定されている場合、全てのSCSメタデータを参照することなく、LSIDのみを用いて、所望のコンポーネントを取得することができる。
一方、ステップS272において、基本サービスフラグ(LSIDBaseService要素)に、"FALSE"が指定されていると判定された場合、処理は、ステップS276に進められる。ステップS276において、SCSシグナリング取得部272は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているUSBD,MPD,SDP等のSCSシグナリングデータを取得する。ステップS276の処理で取得されたSDPは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
ステップS277において、SCSシグナリング取得部272は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップS277の処理で取得されたLSIDは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
ステップS278において、フィルタリング制御部252は、シグナリング解析部254から供給される解析結果(IPアドレス、ポート番号、TSI、及び、TOI)に基づいて、Demux213により実行されるフィルタリング処理を制御する。
これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得(キャプチャ)される。また、ステップS279においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップS278の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得(キャプチャ)される。
そして、例えば、ステップS279の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図25のステップS252の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される(S280)。
このように、SCブートストラップ情報の基本サービスフラグ(LSIDBaseService要素)として"FALSE"が指定されている場合、LSIDに記述された内容のみではコンポーネントの取得先を特定することができないため、LSIDのほか、USBD,MPD,SDP等の他のSCSメタデータを参照して、所望のコンポーネントを取得することになる。ステップS280の処理が終了すると、処理は、図25のステップS257の処理に戻り、それ以降の処理が実行される。
なお、ステップS271において、受信装置20が、放送と通信のハイブリッドに対応していると判定された場合、処理は、ステップS281に進められる。ステップS281においては、放送と通信のハイブリッドに対応した選局処理が行われる。なお、ハイブリッドに対応した選局処理の詳細な内容は、図27のフローチャートを参照して後述する。
以上、選局処理の流れについて説明した。
(ハイブリッドに対応した選局処理)
次に、図27のフローチャートを参照して、図26のステップS281の処理に対応する、ハイブリッドに対応した選局処理の詳細な内容を説明する。
次に、図27のフローチャートを参照して、図26のステップS281の処理に対応する、ハイブリッドに対応した選局処理の詳細な内容を説明する。
ステップS291において、シグナリング解析部254は、NVRAM215に記録された選局情報(SCD)を参照して、選局されたサービスに、SCSブロードバンドロケーション情報(SignalingOverInternet要素)が記述されているかどうかを判定する。
ステップS291において、選局されたサービスに、SCSブロードバンドロケーション情報(SignalingOverInternet要素)が記述されていないと判定された場合、処理は、図26のステップS272の処理に進められ、それ以降の処理が実行される。すなわち、この場合、SCSシグナリングデータが放送のみで提供されることを意味するので、SCブートストラップ情報を用いてSCSシグナリングデータが取得されることになる。
また、ステップS291において、選局されたサービスに、SCSブロードバンドロケーション情報(SignalingOverInternet要素)が記述されていると判定された場合、処理は、ステップS292に進められる。ステップS292において、シグナリング解析部254は、SCSブロードバンドロケーション情報(SignalingOverInternet要素)の基本サービスフラグ(LSIDBaseService要素)に、"TRUE"が指定されているかどうかを判定する。
ステップS292において、基本サービスフラグ(LSIDBaseService要素)に、"TRUE"が指定されていると判定された場合、処理は、ステップS293に進められる。ステップS293において、SCSシグナリング取得部272は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップS293の処理で取得されたLSIDは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
ステップS294において、フィルタリング制御部252は、シグナリング解析部254から供給される解析結果(IPアドレス、ポート番号、TSI、及び、TOI)に基づいて、Demux213により実行されるフィルタリング処理を制御する。
これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得(キャプチャ)される。また、ステップS295においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップS294の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得(キャプチャ)される。
そして、例えば、ステップS294の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図25のステップS252の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される(S304)。
一方、ステップS292において、基本サービスフラグ(LSIDBaseService要素)に、"FALSE"が指定されていると判定された場合、処理は、ステップS296に進められる。ステップS296において、通信制御部255は、シグナリング解析部254からの解析結果(SignalingOverInternet要素のuri属性)に従い、通信部217を制御して、インターネット90を介してブロードバンドサーバ30にアクセスすることで、USBD,MPD,SDP等のSCSシグナリングデータを取得する。
ステップS297において、シグナリング解析部254は、SCSブロードバンドロケーション情報(SignalingOverInternet要素)のハイブリッドフラグ(hybrid属性)に、"TRUE"が指定されているかどうかを判定する。
ステップS297において、ハイブリッドフラグ(hybrid属性)に、"FALSE"が指定されていると判定された場合、処理は、ステップS298に進められる。なお、この場合、ステップS296の処理で取得されたSDPは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
そして、ステップS298において、SCSシグナリング取得部272は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップS298の処理で取得されたLSIDは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。ステップS298の処理が終了すると、処理は、ステップS294に進められる。
ステップS294において、フィルタリング制御部252は、シグナリング解析部254から供給される解析結果(IPアドレス、ポート番号、TSI、及び、TOI)に基づいて、Demux213により実行されるフィルタリング処理を制御する。
これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得(キャプチャ)される。また、ステップS295においては、取得される全てのコンポーネントがキャプチャされたかどうかが判定され、全てのコンポーネントがキャプチャされるまで、ステップS294の処理が繰り返されることで、例えば、選局されたサービスを構成するビデオデータとオーディオデータが取得(キャプチャ)される。
そして、例えば、ステップS294の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図25のステップS252の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される(S304)。
また、ステップS297において、ハイブリッドフラグ(hybrid属性)に、"TRUE"が指定されていると判定された場合、処理は、ステップS299に進められる。ステップS299において、シグナリング解析部254は、例えば、ステップS296の処理で取得されたUSBDやMPDを解析することで、取得するコンポーネントの配信経路が、放送経由であるか、あるいは通信経路であるかを判定する。
ステップS299において、コンポーネントの配信経路が放送経由であると判定された場合、処理は、ステップS300に進められる。なお、この場合、ステップS296の処理で取得されたSDPは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
そして、ステップS300において、シグナリング取得部253は、Demux213により実行されるフィルタリング処理の結果に従い、ROUTEセッションで伝送されているLSIDを取得する。ステップS300の処理で取得されたLSIDは、シグナリング解析部254により解析され、その解析結果が、フィルタリング制御部252に供給される。
ステップS301において、フィルタリング制御部252は、シグナリング解析部254から供給される解析結果(IPアドレス、ポート番号、TSI、及び、TOI)に基づいて、Demux213により実行されるフィルタリング処理を制御する。これにより、Demux213では、LCTパケットのフィルタリング処理が実行され、それにより得られるLCTパケットからセグメントデータが抽出され、選局されたサービスを構成するコンポーネントが取得(キャプチャ)される。
一方、ステップS299において、コンポーネントの配信経路が通信経由であると判定された場合、処理は、ステップS302に進められる。ステップS302において、シグナリング解析部254は、ステップS296の処理で取得されたMPDを解析して、その解析の結果得られるメディアセグメント情報(セグメントURL)を、通信制御部255に供給する。これにより、通信制御部255は、シグナリング解析部254からのメディアセグメント情報(セグメントURL)を取得する。
そして、ステップS301において、通信制御部255は、シグナリング解析部254からのメディアセグメント情報(セグメントURL)に従い、通信部217を制御して、インターネット90を介してブロードバンドサーバ30にアクセスすることで、選局されたサービスを構成するコンポーネントを取得(キャプチャ)する。
ステップS301の処理が終了すると、処理は、ステップS303に進められる。ステップS303においては、取得する全てのコンポーネントがキャプチャされたかどうかが判定される。ステップS303において、全てのコンポーネントがキャプチャされていないと判定された場合、処理は、ステップS299に戻り、それ以降の処理が繰り返される。
すなわち、ステップS299乃至S303の処理が繰り返されることで、放送経由又は通信経由でコンポーネントが取得され、ステップS303において、全てのコンポーネントがキャプチャされたと判定された場合、処理は、ステップS304に進められる。ステップS304においては、例えば、ステップS300又はS302の処理で取得されたビデオデータとオーディオデータが復号され、レンダリング処理等が行われることで、図25のステップS252の処理で選局されたサービスに対応した番組の映像と音声が再生され、サービスの視聴が開始される(S304)。
ステップS304の処理が終了すると、処理は、図26のステップS281の処理に戻り、それ以降の処理が実行される。
以上、ハイブリッドに対応した選局処理の流れについて説明した。
<5.シンタックスの例>
(1)LLSシグナリングデータ
(LLSパケットの構造)
図28は、LLSパケットの構造を示す図である。
図28は、LLSパケットの構造を示す図である。
図28に示すように、BBPパケットは、BBPヘッダとペイロードから構成される。BBPストリームによりIPパケットを伝送する場合には、ペイロードの部分がIPパケットとなる。BBPストリームによりLLSシグナリングデータを伝送する場合には、BBPヘッダの次にLLSシグナリングデータが配置される。LLSシグナリングデータとしては、例えば、XML形式で記述されたSCD等のLLSメタデータが配置される。
BBPヘッダには、2ビットのタイプ情報が含まれており、そのタイプ情報によって、BBPパケットがIPパケットであるか、LLSであるかを区別することができる。また、LLSヘッダは、LLSインデックスとオブジェクトバージョン情報(バージョン情報)から構成される。
図29は、LLSヘッダのLLSインデックスの例を示す図である。
LLSインデックスは、圧縮情報(Compression Scheme)、タイプ情報(Fragment Type)、拡張タイプ情報(Type Extension)が配置される。圧縮情報には、対象のLLSシグナリングデータの圧縮の有無を示す情報が指定される。例えば、"0000"が指定された場合には、非圧縮であることを示し、"0001"が指定された場合には、zip形式で圧縮されていることを示している。
タイプ情報(Fragment Type)には、LLSシグナリングデータのタイプを示す情報が指定される。例えば、SCDには"000000"、EADには"000001"、RRDには"000010"、DCDには"000011"がそれぞれ指定される。拡張タイプ情報には、タイプごとに拡張パラメータを指定することができる。
(SCDのシンタックス)
図30は、XML形式のSCDのシンタックスを示す図である。なお、図30において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシンタックスでも同様とされる。
図30は、XML形式のSCDのシンタックスを示す図である。なお、図30において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。これらの関係は、後述する他のシンタックスでも同様とされる。
図30に示すように、ルート要素としてのSCD要素は、majorProtocolversion属性、minorProtocolversion属性、RFAllocationId属性、name属性、Tuning_RF要素、及び、BBPStream要素の上位要素となる。
majorProtocolversion属性と、minorProtocolversion属性には、プロトコルのバージョン情報が指定される。RFAllocationId属性には、物理チャンネル単位の放送局のRFアロケーションIDが指定される。name属性には、物理チャンネル単位の放送局の名称が指定される。
Tuning_RF要素は、選局に関する情報が指定される。Tuning_RF要素は、frequency属性、及び、Preamble属性の上位要素となる。frequency属性には、所定の帯域を選局するときの周波数が指定される。Preamble属性には、物理層の制御情報が指定される。
BBPStream要素には、1又は複数のBBPストリームに関する情報が指定される。BBPStream要素は、bbpStreamId属性、payloadType属性、name属性、ESGBootstrap要素、ClockReferenceInformation要素、及び、Service要素の上位要素となる。
bbpStreamId属性には、BBPストリームIDが指定される。BBPストリームを複数配置する場合には、このBBPストリームIDにより識別する。payloadType属性には、BBPストリームのペイロードタイプが指定される。このペイロードタイプとしては、例えば、"ipv4","ipv6"などが指定される。"ipv4"は、IPv4(Internet Protocol version 4)であることを示す。"ipv6"は、IPv6(Internet Protocol Version 6)であることを示す。name属性には、BBPストリームの名称が指定される。
ESGBootstrap要素には、ESGブートストラップ情報が指定される。このESGブートストラップ情報によってESGへアクセスすることが可能となる。ESGBootstrap要素は、ESGProvider要素の上位要素となる。ESGProvider要素には、ESGのプロバイダごとに、ESGに関する情報が指定される。ESGProvider要素は、providerName属性、ESGBroadcastLocation要素、及び、ESGBroadbandLocation要素の上位要素となる。
providerName属性には、ESGのプロバイダの名称が指定される。ESGBroadcastLocation要素は、ESGが放送により伝送される場合に、RFAllocationId属性、BBPStreamId属性、及び、ESGServiceId属性により指定されるRFアロケーションID、BBPストリームID、及び、サービスID(トリプレット)によって、ESGサービスを指定する。ESGBroadbandLocation要素は、ESGが通信経由で伝送される場合に、ESGUri属性により、そのESGのファイルにアクセスするためのURIを指定する。
ClockReferenceInformation要素には、時刻情報(例えばNTP)に関する情報が指定される。ClockReferenceInformation要素は、sourceIPAddress属性、destinationIPAddress属性、及び、portNum属性の上位要素となる。sourceIPAddress属性とdestinationIPAddress属性には、時刻情報を伝送する送信元(source)と宛先(destination)のIPアドレスが指定される。portNum属性には、時刻情報を伝送するポート番号が指定される。
Service要素には、1又は複数のサービスに関する情報が指定される。Service要素は、serviceId属性、globalUniqueServiceId属性、serviceType属性、hidden属性、hiddenGuide属性、shortName属性、longName属性、accesControl属性、SourceOrigin要素、SCBootstrap要素、SignalingOverInternet要素、及び、AssociationService要素の上位要素となる。
serviceId属性には、サービスIDが指定される。サービスを複数配置する場合には、このサービスIDにより識別する。globalUniqueServiceId属性には、グローバルユニークサービスIDが指定される。例えば、グローバルユニークサービスIDによって、ESG選局されたサービスと、USBDとを紐付けることができる。
serviceType属性には、サービスのタイプ情報が指定される。このタイプ情報としては、例えば、"continued","scripted"が指定される。"continued"は、ビデオやオーディオのサービス、"scripted"は、NRTサービスをそれぞれ示している。
hidden属性とhiddenGuide属性には、サービスIDにより識別されるサービスが、隠されたサービスであるかどうかが指定される。例えば、これらの属性値として"on"が指定された場合、当該サービスは非表示とされる。また、これらの属性値として"off"が指定された場合、当該サービスは表示される。例えば、hidden属性として"on"が指定された場合、当該サービスは、リモートコントローラの操作により選局できないようになる。また、例えば、hiddenGuide属性として"on"が指定された場合、当該サービスは、ESGには表示されないことになる。
shortName属性とlongName属性には、サービスIDにより識別されるサービスの名称が指定される。ただし、shortName属性では、例えば7文字以内でサービスの名称の名称を指定しなければならない。accesControl属性には、サービスIDにより識別されるサービスが暗号化されているかどうかが指定される。例えば、accesControl属性として"on"が指定された場合には、当該サービスが暗号化されていることを示し、"off"が指定された場合には、当該サービスが暗号化されていないことを示している。
SourceOrigin要素には、サービスを識別するための情報が指定される。SourceOrigin要素は、country属性、originalRFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。country属性には、国コードが指定される。originalRFAllocationId属性には、オリジナルRFアロケーションIDが指定される。オリジナルRFアロケーションIDは、放送ネットワークを識別するためのIDであって、当該サービスの再送信を行う場合でも、同一の値が用いられる。bbpStreamId属性には、BBPストリームIDが指定される。serviceId属性には、サービスIDが指定される。すなわち、国コード、オリジナルRFアロケーションID、BBPストリームID、及び、サービスIDによって、各サービスに対して、固有のIDを割り当てることができる。
SCBootstrap要素には、SCブートストラップ情報が指定される。このSCブートストラップ情報によって、サービスチャンネルへアクセスすることが可能となって、SCSシグナリングデータを取得することができる。SCBootstrap要素は、LSIDBaseService属性、hybrid属性、sourceIPAddress属性、destinationIPAddress属性、portNum属性、及び、tsi属性の上位要素となる。
LSIDBaseService属性には、上述した基本サービスフラグに相当するものであって、LSIDのみで、サービスを構成するコンポーネントのストリームを取得できるかどうかが指定される。また、hybrid属性には、上述したハイブリッドフラグに相当するものであって、通信経由で配信されるコンポーネントのストリームがあるかどうかが指定される。
sourceIPAddress属性とdestinationIPAddress属性には、サービスを伝送する送信元(source)と宛先(destination)のIPアドレスが指定される。portNum属性には、SCSを伝送するポート番号が指定される。tsi属性には、SCSを伝送するROUTEセッションにおけるTSIが指定される。
SignalingOverInternet要素には、SCSブロードバンドロケーション情報が指定される。このSCSブロードバンドロケーション情報によって、通信経由で伝送されるSCSシグナリングデータに関する情報が指定される。SignalingOverInternet要素は、LSIDBaseService属性、hybrid属性、及び、uri属性の上位要素となる。
LSIDBaseService属性には、上述した基本サービスフラグに相当するものであって、LSIDのみで、サービスを構成するコンポーネントのストリームを取得できるかどうかが指定される。また、hybrid属性には、上述したハイブリッドフラグに相当するものであって、通信経由で配信されるコンポーネントのストリームがあるかどうかが指定される。uri属性には、SCSシグナリングデータの取得先を示すURIが指定される。
AssociationService要素には、関連従属サービスに関する情報が指定される。AssociationService要素は、RFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。RFAllocationId属性、bbpStreamId属性、及び、serviceId属性により指定されるRFアロケーションID、BBPストリームID、及び、サービスID(トリプレット)によって、関連従属サービスを指定する。
なお、出現数(Cardinality)であるが、"1"が指定された場合にはその要素又は属性は必ず1つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..n"が指定された場合には、その要素又は属性は1以上指定され、"0..n"が指定された場合には、その要素又は属性を1以上指定するかどうかは任意である。これらの出現数の意味は、後述する他のシンタックスでも同様とされる。
(EADのシンタックス)
図31は、XML形式のEADのシンタックスを示す図である。
図31は、XML形式のEADのシンタックスを示す図である。
図31に示すように、ルート要素としてのEAD要素は、AutomaticTuningService要素、及び、EAMessage要素の上位要素となる。AutomaticTuningService要素は、Wake-up時の自動選局サービスを指定するためのものである。AutomaticTuningService要素は、RFAllocationId属性、bbpStreamId属性、及び、serviceId属性の上位要素となる。
RFAllocationId属性は、自動選局サービスのネットワークIDが指定される。BBPStreamId属性は、自動選局サービスのBBPストリームIDが指定される。serviceId属性は、自動選局サービスのサービスIDが指定される。すなわち、AutomaticTuningService要素が出現した場合、それらの属性が示すトリプレットにより指定されるサービスが選局される。ただし、このトリプレットのうち、RFAllocationId属性とBBPStreamId属性は必須ではなく、例えば、EADと同一のBBPストリームを指定するのであれば、serviceId属性のみを指定すればよいことになる。
EAMessage要素は、緊急警報情報(緊急情報)のメッセージが指定される。EAMessage要素は、eaMessageId属性、eaPriority属性、EAMessageData要素、EAApplication要素、EAService要素、及び、EAWww要素の上位要素となる。
eaMessageId属性は、緊急警報情報(緊急情報)のIDが指定される。eaPriority属性は、緊急警報情報(緊急情報)の優先度が指定される。EAMessageData要素は、緊急警報情報(緊急情報)の字幕情報が指定される。
EAApplication要素は、緊急警報用のアプリケーションに関する情報が指定される。EAApplication要素は、applicationId属性の上位要素となる。applicationId属性は、アプリケーションIDが指定される。
EAService要素は、緊急警報用のNRTサービスに関する情報が指定される。EAService要素は、serviceId属性、及び、serviceType属性の上位要素となる。serviceId属性は、サービスIDが指定される。serviceType属性は、サービスタイプ情報が指定される。このサービスタイプ情報としては、例えば"nrt"が指定される。"nrt"は、NRTサービスであることを示す。
EAWww要素は、緊急情報サイトに関する情報が指定される。EAWww要素は、uri属性の上位要素となる。uri属性には、緊急情報サイトのURIが指定される。
(緊急警報情報の表示例)
図32は、EADによる緊急警報情報の表示例を示す図である。なお、図32において、図中の上側は、送信装置10とインターネットサーバ40から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図32において、時間の方向は、図中の左側から右側の方向とされる。
図32は、EADによる緊急警報情報の表示例を示す図である。なお、図32において、図中の上側は、送信装置10とインターネットサーバ40から伝送されるデータの流れを表し、図中の下側は、それらのデータを処理する受信装置20Aにおける処理の流れを表している。また、図32において、時間の方向は、図中の左側から右側の方向とされる。
図32において、送信装置10は、IP伝送方式を用いたデジタル放送の放送波(RF Channel)を伝送している。この放送波では、一方のBBPストリーム(以下、「BBPストリーム1」という)で、サービス(例えば番組)を構成するコンポーネント及びSCSシグナリングデータ、並びにLLSシグナリングデータが伝送されている。また、他方のBBPストリーム(以下、「BBPストリーム2」という)で、2つのロバストオーディオと、SCSのストリームが伝送されている。
また、インターネットサーバ40は、緊急情報サイトを提供しており、インターネット90を介して緊急警報詳細情報を配信している。
図32に示すように、固定受信機としての受信装置20Aにおいては、初期スキャン処理等によって、BBPストリーム1のLLSストリームで伝送されているSCDが取得され、NVRAMに記録される(S411)。SCDには、物理パラメータとしての周波数やトリプレットのほか、SCブートストラップ情報が、サービスごとに記述されている。
受信装置20Aにおいては、ユーザによりサービスが選局された場合(S412)、当該サービスのSCブートストラップ情報がNVRAMから読み出され、SCブートストラップ情報に従い、送信装置10からの放送波で伝送されているBBPストリーム1のSCSストリームに接続される(S413)。これにより、受信装置20Aは、ROUTEセッション1で伝送されているSCSシグナリングデータを取得することができる(S414)。
受信装置20Aは、ステップS414の処理で取得されたSCSシグナリングデータに従い、送信装置10からの放送波で伝送されているBBPストリーム1のビデオとオーディオのストリームに接続する(S415)。これにより、受信装置20Aは、ROUTEセッション1で伝送されているビデオデータとオーディオデータを取得することができる(S416)。そして、受信装置20Aでは、ROUTEセッション1から取得されたビデオデータとオーディオデータをバッファに一時的に記憶させることで、バッファリング処理を行い、さらにレンダリング処理を行うことで、選局されたサービスに対応した番組の映像と音声が再生される(S417)。
その後、受信装置20Aにおいて、BBPストリーム1のLLSストリームで伝送されているEADが取得された場合(S418)、再生中の番組の映像には、EAD(のEAMessage要素のEAMessageData要素)に対応した緊急警報情報(の字幕情報)が重畳表示される(S419)。
また、受信装置20Aは、ユーザによって、緊急警報詳細情報の表示が指示された場合(S420)、EAD(のEAMessage要素のEAWww要素のuri属性)に指定された緊急情報サイトのURIに従い、インターネット90を介してインターネットサーバ40にアクセスし(S421)、緊急警報詳細情報を取得する(S422)。これにより、受信装置20Aにおいては、緊急情報サイトから取得された緊急警報詳細情報が表示されることになる(S423)。
(RRDのシンタックス)
図33は、XML形式のRRDのシンタックスを示す図である。
図33は、XML形式のRRDのシンタックスを示す図である。
図33に示すように、ルート要素としてのRRD要素は、RatingRegionName要素、RatingRegion要素、TableVersion要素、及び、Dimension要素の上位要素となる。RatingRegionName要素には、レーティングリージョンの名称が指定される。RatingRegion要素は、レーティングリージョンのコードが指定される。このコードとしては、例えば、"us","canada","mexico"などが指定される。TableVersion要素には、RRDのバージョン情報が指定される。
Dimension要素は、RatingDimensionName要素、RatingDimension要素、GraduatedScale要素、及び、DimensionValue要素の上位要素となる。RatingDimensionName要素は、レーティングディメンションの名称が指定される。RatingDimension要素は、レーティングディメンションのコードが指定される。GraduatedScale要素は、スケールが指定される。
DimensionValue要素には、ディメンションの値が指定される。DimensionValue要素は、RatingValueText要素、AbbrevValueText要素、RatingValue要素、及び、RatingTag要素の上位要素となる。これらの属性により、例えば、年齢制限の区分けの仕方などのレーティング情報が指定される。
(DCDのシンタックス)
図34は、XML形式のDCDのシンタックスの例を示す図である。
図34は、XML形式のDCDのシンタックスの例を示す図である。
図34において、ルート要素としてのDCD要素は、Service要素の上位要素となる。Service要素は、serviceID属性、serviceStatus属性、video要素、及び、audio要素の上位要素となる。serviceID属性には、サービスIDが指定される。serviceStatus属性には、サービスIDにより識別されるサービスのステータスに関する情報が指定される。
video要素には、最小限のサービスとしてのビデオのストリームに接続するための情報が指定される。video要素は、mime_type属性、port_number属性、及び、TSI属性の上位要素となる。mime_type属性には、MIMEタイプが指定される。port_number属性には、ポート番号が指定される。TSI属性には、TSIが指定される。
audio要素には、最小限のサービスとしてのオーディオのストリームに接続するための情報が指定される。audio要素は、mime_type属性、port_number属性、及び、TSI属性の上位要素となる。mime_type属性には、MIMEタイプが指定される。port_number属性には、ポート番号が指定される。TSI属性には、TSIが指定される。
なお、図30乃至図34を参照して説明したSCD,EAD,RRD,DCDの各シンタックスは一例であって、他のシンタックスを採用することができる。
(2)SCSシグナリングデータ
(LCTパケットの構造)
図35は、LCTパケットの構造を示す図である。
図35は、LCTパケットの構造を示す図である。
図35に示すように、BBPストリームによりLCTパケットを伝送する場合、BBP,IP,UDP,LCTの各ヘッダがペイロードに付加される。ROUTEセッションによりSCSシグナリングデータを伝送する場合には、LCTヘッダの次に配置されるペイロードに、SCSシグナリングデータが配置される。SCSシグナリングデータとしては、例えば、XML形式のUSBDやLSID等のSCSメタデータが配置される。
LCTヘッダは、SCSインデックス(Signaling Index)とオブジェクトバージョン情報(バージョン情報)から構成される。
図36は、LCTヘッダのSCSインデックスの例を示す図である。
SCSインデックス(Signaling Index)は、圧縮情報(Compression Scheme)、タイプ情報(Fragment Type)、拡張タイプ情報(Type Extension)が配置される。圧縮情報には、対象のSCSシグナリングデータの圧縮の有無を示す情報が指定される。例えば、"0000"が指定された場合には、非圧縮であることを示し、"0001"が指定された場合には、zip形式で圧縮されていることを示している。
タイプ情報(Fragment Type)には、SCSシグナリングデータのタイプを示す情報が指定される。例えば、SCSバンドルには"000000"、USBDには"000001"、SDPには"000010"、SPDには"000011"がそれぞれ指定される。拡張タイプ情報には、タイプごとに拡張パラメータを指定することができる。
(LSIDのシンタックス)
図37は、XML形式のLSIDのシンタックスの例を示す図である。
図37は、XML形式のLSIDのシンタックスの例を示す図である。
図37に示すように、ルート要素としてのLSID要素は、version属性、validFrom属性、expiration属性、及び、TransportSession要素の上位要素となる。version属性には、LSIDのバージョン情報が指定される。validFrom属性には、LSIDの失効期間の開始日時が指定される。expiration属性には、LSIDの失効日時が指定される。
TransportSession要素には、LCTトランスポートのセッション情報が指定される。TransportSession要素は、tsi属性、SourceFlow要素、及び、RepairFlow要素の上位要素となる。tsi属性には、TSIが指定される。SourceFlow要素には、ソースフロー情報が指定される。なお、SourceFlow要素の詳細な構成は、図38を参照して後述する。RepairFlow要素には、リペアフロー情報が指定される。なお、RepairFlow要素の詳細な構成は、図40を参照して後述する。
(SourceFlow要素のシンタックス)
図38は、図37のSourceFlow要素のシンタックスの例を示す図である。
図38は、図37のSourceFlow要素のシンタックスの例を示す図である。
SourceFlow要素には、ソースフロー情報が指定される。図38に示すように、ルート要素としてのSourceFlow要素は、EFDT要素、idRef属性、realtime属性、minBufferSize属性、ApplicationIdentifier要素、及び、PayloadFormat要素の上位要素となる。
EFDT要素は、Extended FDTの略であって、拡張されたFDTに関する情報が指定される。なお、EFDT要素の詳細な構成は、図39を参照して後述する。idRef属性には、EFDT IDが指定される。
realtime属性には、"TRUE"又は"FALSE"が指定され、"TRUE"が指定された場合には、LCT拡張ヘッダに、NTPタイムスタンプを含むことになる。なお、realtime属性のデフォルト値は、"FALSE"とされる。minBufferSize属性には、受信装置20が必要とする最小バッファサイズが指定される。ApplicationIdentifier要素には、アプリケーションとマッピングするIDが指定される。
PayloadFormat要素には、ソースフロー情報のペイロードフォーマットが指定される。PayloadFormat要素は、codePoint属性、deliveryObjectFormat属性、fragmentation属性、deliveryOrder属性、sourceFECPayloadID属性、及び、FECParameters要素の上位要素とされる。
codePoint属性には、コードポイント値が指定される。なお、コードポイント値のデフォルト値は、"0"とされる。deliveryObjectFormat属性には、ペイロードフォーマットが指定される。fragmentation属性には、フラグメンテーションに関する情報が指定される。deliveryOrder属性には、デリバリオーダに関する情報が指定される。sourceFECPayloadID属性には、ソースFECのペイロードIDが指定される。FECParameters要素には、FECパラメータが指定される。
(EFDT要素のシンタックス)
図39は、図38のEFDT要素のシンタックスの例を示す図である。
図39は、図38のEFDT要素のシンタックスの例を示す図である。
EFDT要素には、拡張されたFDTに関する情報が指定される。図39に示すように、ルート要素としてのEFDT要素は、route:idRef属性、route:version属性、route:maxExpiresDelta属性、route:maxTransportSize属性、及び、FileTemplate要素の上位要素となる。
route:idRef属性には、EFDT IDが指定される。route:version属性には、EFDTのバージョン情報が指定される。route:maxExpiresDelta属性には、オブジェクトの伝送後、失効するまでの時間が指定される。route:maxTransportSize属性には、最大転送サイズが指定される。FileTemplate要素には、ファイルテンプレートに関する情報が指定される。
(RepairFlow要素のシンタックス)
図40は、図37のRepairFlow要素のシンタックスの例を示す図である。
図40は、図37のRepairFlow要素のシンタックスの例を示す図である。
RepairFlow要素には、リペアフロー情報が指定される。図40に示すように、ルート要素としてのRepairFlow要素は、FECパラメータが指定されるFECParameters要素の上位要素となる。また、FECParameters要素は、fecEncodingId属性、maximumDelay属性、overhead属性、minBufferSize属性、FECOTI要素、及び、ProtectedObject要素の上位要素となる。
fecEncodingId属性には、FECスキームのIDが指定される。maximumDelay属性には、ソースフロー情報とリペアフロー情報の最大遅延時間が指定される。overhead属性には、オーバーヘッド値が指定される。minBufferSize属性には、受信装置20が必要とする最小バッファサイズが指定される。FECOTI要素には、FECオブジェクトのトランスミッション情報が指定される。ProtectedObject要素には、保護するソースフロー情報に関する情報が指定される。なお、ProtectedObject要素の詳細な構成は、図41を参照して後述する。
(ProtectedObject要素のシンタックス)
図41は、図40のProtectedObject要素のシンタックスの例を示す図である。
図41は、図40のProtectedObject要素のシンタックスの例を示す図である。
ProtectedObject要素には、保護するソースフロー情報に関する情報が指定される。図41に示すように、ルート要素としてのProtectedObject要素は、sessionDescription属性、tsi属性、sourceTOI属性、及び、fecTransportObjectSize属性の上位要素となる。
sessionDescription属性は、ソースフロー情報のセッション情報が指定される。tsi属性には、ソースフロー情報のTSIが指定される。sourceTOI属性には、リペアフロー情報のTOIと一致するデリバリオブジェクトのTOIが指定される。fecTransportObjectSize属性には、FECトランスポートオブジェクトのデフォルトサイズが指定される。
(SPDのシンタックス)
図42は、XML形式のSPDのシンタックスの例を示す図である。
図42は、XML形式のSPDのシンタックスの例を示す図である。
図42に示すように、ルート要素としてのSPD要素は、serviceId属性、spIndicator属性、AlternativeService要素、HybridSignalLocationDescription要素、ContentAdvisoryDescription要素、及び、NRTServiceDescription要素の上位要素となる。
serviceId属性には、サービスIDが指定される。spIndicator属性には、サービスIDにより識別されるサービスごとに、暗号化されているかどうかが指定される。spIndicator属性として"on"が指定された場合には、当該サービスが暗号化されていることを示し、"off"が指定された場合には、当該サービスが暗号化されていないことを示している。
AlternativeService要素には、オルタナティブサービスに関する情報が指定される。AlternativeService要素は、globalUniqueServiceId属性の上位要素となる。globalUniqueServiceId属性には、グローバルユニークサービスIDが指定される。
HybridSignalLocationDescription要素には、通信経由で伝送されるシグナリングデータに関する情報が指定される。なお、HybridSignalLocationDescription要素の詳細な構成は、図43を参照して後述する。
ContentAdvisoryDescription要素には、レーティングリージョンに関する情報が指定される。なお、ContentAdvisoryDescription要素の詳細な構成は、図44を参照して後述する。
NRTServiceDescription要素には、NRTサービスに関する情報が指定される。なお、NRTServiceDescription要素の詳細な構成は、図45を参照して後述する。
(HybridSignalLocationDescription要素のシンタックス)
図43は、図42のHybridSignalLocationDescription要素のシンタックスの例を示す図である。
図43は、図42のHybridSignalLocationDescription要素のシンタックスの例を示す図である。
HybridSignalLocationDescription要素には、通信経由で伝送されるシグナリングデータに関する情報が指定される。図43に示すように、ルート要素としてのHybridSignalLocationDescription要素は、version属性、url属性、及び、hybrid属性の上位要素となる。
version属性には、シグナリングデータのバージョン情報が指定される。url属性には、シグナリングデータの取得先を示すURLが指定される。hybrid属性には、ハイブリッドサービスに対応したシグナリングデータであるかどうかを示す情報が指定される。例えば、hybrid属性として"TRUE"が指定された場合、ハイブリッドサービスに対応していることを表している。また、例えば、hybrid属性として"FALSE"が指定された場合、放送基本サービスに対応していることを表している。
(Content Advisory Description要素のシンタックス)
図44は、図42のContentAdvisoryDescription要素のシンタックスの例を示す図である。
図44は、図42のContentAdvisoryDescription要素のシンタックスの例を示す図である。
ContentAdvisoryDescription要素には、レーティングリージョンに関する情報が指定される。図44に示すように、ルート要素としてのContent Advisory Description要素は、version属性、及び、RatingRegion要素の上位要素となる。version属性には、RRDのバージョン情報が指定される。
RatingRegion要素は、ratingRegionId属性、及び、RatingDimension要素の上位要素となる。ratingRegionId属性には、レーティングリージョンIDが指定される。RatingDimension要素は、dimensionIndex属性、ratingValue属性、及び、ratingTag属性の上位要素となる。これらの属性により、年齢制限の区分けの仕方などのレーティング情報が指定される。
(NRTServiceDescription要素のシンタックス)
図45は、図42のNRTServiceDescription要素のシンタックスの例を示す図である。
図45は、図42のNRTServiceDescription要素のシンタックスの例を示す図である。
NRTServiceDescription要素には、NRTサービスに関する情報が指定される。図45に示すように、ルート要素としてのNRTServiceDescription要素は、ConsumptionModel属性、autoUpdate属性、storageReservarion属性、defaultContentSize属性、ProtocolVersionDescription要素、CapabilityDescription要素、IconDescription要素、ISO639LanguageDescription要素、及び、ReceiverTargetingDescription要素の上位要素となる。
ConsumptionModel属性には、NRTサービスの伝送モードが指定される。この伝送モードとしては、例えば、"B&D","push","portal","triggered"が指定される。"B&D"は、Browse and Downloadの略で、ユーザにより選択されたNRTコンテンツのファイルデータをダウンロードするモードである。"push"は、契約したNRTサービスをプッシュ型で提供するモードである。"portal"は、HTML形式のファイルなどを伝送して直ちに表示するモードである。"triggered"は、アプリケーションを提供するモードである。
autoUpdate属性には、NRTサービスが自動更新されるかどうかが指定される。autoUpdate属性として"on"が指定された場合には、当該NRTサービスが自動更新されることを示し、"off"が指定された場合には、当該NRTサービスが自動更新されないことを示している。storageReservarion属性には、必要とされるストレージの容量が指定される。defaultContentSize属性には、NRTコンテンツ1つ当たりのサイズが指定される。
ProtocolVersionDescription要素には、データのサービスがどのようなサービスであるかを示すための情報が指定される。CapabilityDescription要素には、NRTサービスの提供を受ける受信装置20に要求される機能(キャパビリティ)に関する情報が指定される。
IconDescription要素には、NRTサービスで用いられるアイコンの取得先を示す情報が指定される。ISO639LanguageDescription要素には、NRTサービスの言語コードが指定される。ReceiverTargetingDescription要素には、NRTサービスのターゲット情報が指定される。
(ProtocolVersionDescription要素のシンタックス)
図46は、図45のProtocolVersionDescription要素のシンタックスの例を示す図である。
図46は、図45のProtocolVersionDescription要素のシンタックスの例を示す図である。
Protocol Version Description要素には、データのサービスがどのようなサービスであるかを示すための情報が指定される。図46に示すように、ルート要素としてのProtocol Version Description要素は、protocolIdentifier属性、majorProtocolVersion属性、及び、minorProtocolVersion属性の上位要素となる。
protocolIdentifier属性には、データのサービスのフォーマットのタイプ情報が指定される。このタイプ情報としては、例えば、"A/90","NRT"が指定される。"A/90"は、汎用のデータを伝送する方式であることを示す。また、"NRT"は、NRT(Non-RealTime)により伝送する方式であることを示す。
majorProtocolVersion属性とminorProtocolVersion属性には、データのサービスのバージョンが指定される。majorProtocolVersion属性には、メジャーバージョン、minorProtocolVersion属性には、マイナーバージョンがそれぞれ指定される。
(CapabilityDescription要素のシンタックス)
図47は、図45のCapabilityDescription要素のシンタックスの例を示す図である。
図47は、図45のCapabilityDescription要素のシンタックスの例を示す図である。
Capability Description要素には、NRTサービスの提供を受ける受信装置20に要求される機能(キャパビリティ)に関する情報が指定される。図47に示すように、ルート要素としてのCapability Description要素は、IndivisualCapabilityCodes要素、IndivisualCapabilityString要素、及び、CapabilityOrSets要素の上位要素となる。
IndivisualCapabilityCodes要素は、essentialIndicator属性、capabilityCode属性、及び、formatIdentifier属性の上位要素となる。essentialIndicator属性には、キャパビリティが必須であるかどうかを示す情報が指定される。capabilityCode属性には、あらかじめ定められたキャパビリティのコードが指定される。すなわち、essentialIndicator属性とcapabilityCode属性により、キャパビリティのコードにより指定されるキャパビリティが必須であるかどうかが指定される。formatIdentifier属性には、キャパビリティのコードを任意に指定する場合に、評価すべき機能(キャパビリティ)が指定される。
IndivisualCapabilityString要素は、essentialIndicator属性、capabilityCategoryCode属性、及び、capabilityString属性の上位要素となる。essentialIndicator属性には、キャパビリティが必須であるかどうかを示す情報が指定される。capabilityCategoryCode属性には、キャパビリティのカテゴリごとのコードが指定される。すなわち、essentialIndicator属性とcapabilityCategoryCode属性により、キャパビリティのカテゴリごとのコードにより指定されるキャパビリティが必須であるかどうかが指定される。capabilityString属性には、キャパビリティのカテゴリごとに、評価すべき機能(キャパビリティ)が指定される。
CapabilityOrSets要素は、上述したIndivisualCapabilityCodes要素によるキャパビリティのコードごとの評価と、IndivisualCapabilityString要素によるキャパビリティのカテゴリのコードごとの評価を、OR条件で指定する場合に指定される。したがって、CapabilityOrSets要素は、essentialIndicator属性、CapabilityCodesInSets要素、及び、CapabilityStringsInSets要素の上位要素となるが、essentialIndicator属性は、上述したessentialIndicator属性に対応している。
また、CapabilityCodesInSets要素におけるcapabilityCode属性と、formatIdentifier属性は、上述したIndivisualCapabilityCodes要素におけるcapabilityCode属性と、formatIdentifier属性に対応している。さらに、CapabilityStringsInSets要素におけるcapabilityCategoryCode属性と、capabilityString属性は、上述したIndivisualCapabilityString要素におけるcapabilityCategoryCode属性と、capabilityString属性に対応している。
(IconDescription要素のシンタックス)
図48は、図45のIconDescription要素のシンタックスの例を示す図である。
図48は、図45のIconDescription要素のシンタックスの例を示す図である。
IconDescription要素には、NRTサービスで用いられるアイコンの取得先を示す情報が指定される。図48に示すように、ルート要素としてのIconDescription要素は、content_linkage属性の上位要素となる。content_linkage属性には、アイコンの取得先を示すURLが指定される。
(ISO-639LanguageDescription要素のシンタックス)
図49は、図45のISO-639LanguageDescription要素のシンタックスの例を示す図である。
図49は、図45のISO-639LanguageDescription要素のシンタックスの例を示す図である。
ISO639LanguageDescription要素は、NRTサービスの言語コードが指定される。図49に示すように、ルート要素としてのISO639LanguageDescription要素は、languageCode属性の上位要素となる。languageCode属性には、ISO 639で規定された言語コードが指定される。
(ReceiverTargetingDescription要素のシンタックス)
図50は、図45のReceiverTargetingDescription要素のシンタックスの例を示す図である。
図50は、図45のReceiverTargetingDescription要素のシンタックスの例を示す図である。
ReceiverTargetingDescription要素には、NRTサービスのターゲット情報が指定される。図50に示すように、ルート要素としてのReceiverTargetingDescription要素は、TargetEntry要素の上位要素となる。TargetEntry要素は、geoLocation属性、postalCode属性、及び、demographic category属性の上位要素となる。
geoLocation属性には、NRTサービスのターゲットとなる地理的な位置が指定される。postalCode属性には、NRTサービスのターゲットとなる地域の郵便番号が指定される。demographic category属性は、NRTサービスのターゲットとなるユーザのカテゴリが指定される。このカテゴリとしては、例えば、"males","females","Ages 12-17"が指定される。"males"は、NRTサービスのターゲットが男性であることを示す。"females"は、NRTサービスのターゲットが女性であることを示す。"Ages 12-17"は、NRTサービスのターゲットが12歳から17歳であることを示す。
なお、図37乃至図50を参照して説明したLSID,SPD,及び、SPDのDescription要素の各シンタックスは一例であって、他のシンタックスを採用することができる。
<6.変形例>
上述した説明では、現在策定が進められている米国の次世代放送規格であるATSC3.0において、IP伝送方式を用いたデジタル放送の採用が見込まれているため、地上デジタルテレビ放送の規格として、米国等が採用する方式であるATSCを説明したが、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、地上デジタルテレビ放送に限らず、衛星デジタルテレビ放送やデジタル有線テレビ放送などで採用するようにしてもよい。
また、上述した説明では、シグナリングデータの名称として、Descriptionの略である「D」を用いたが、Tableの略である「T」が用いられる場合がある。例えば、SCD(Service Configuration Description)は、SCT(Service Configuration Table)と記述される場合がある。また、例えば、SPD(Service Parameter Description)は、SPT(Service Parameter Table)と記述される場合がある。ただし、これらの名称の違いは、「Description」と「Table」との形式的な違いであって、各シグナリングデータの実質的な内容が異なるものではない。
さらに、上述した説明では、シグナリングデータがXML等のマークアップ言語により記述される場合における、その要素や属性について説明したが、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。例えば、SCD等に規定されるRFアロケーションID(RF Allocation ID)は、ネットワークID(Network ID)やRFチャンネルID(RF Channel ID)などと称するようにしてもよい。また、例えば、SCDのSCBootstrap要素のLSIDBaseService属性は、LSIDBasicService属性などと記述するようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。
<7.コンピュータの構成>
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図51は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ900において、CPU(Central Processing Unit)901,ROM(Read Only Memory)902,RAM(Random Access Memory)903は、バス904により相互に接続されている。バス904には、さらに、入出力インターフェース905が接続されている。入出力インターフェース905には、入力部906、出力部907、記録部908、通信部909、及び、ドライブ910が接続されている。
入力部906は、キーボード、マウス、マイクロフォンなどよりなる。出力部907は、ディスプレイ、スピーカなどよりなる。記録部908は、ハードディスクや不揮発性のメモリなどよりなる。通信部909は、ネットワークインターフェースなどよりなる。ドライブ910は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア911を駆動する。
以上のように構成されるコンピュータ900では、CPU901が、ROM902や記録部908に記憶されているプログラムを、入出力インターフェース905及びバス904を介して、RAM903にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ900(CPU901)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア911に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ900では、プログラムは、リムーバブルメディア911をドライブ910に装着することにより、入出力インターフェース905を介して、記録部908にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部909で受信し、記録部908にインストールすることができる。その他、プログラムは、ROM902や記録部908に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含む。また、プログラムは、1のコンピュータ(プロセッサ)により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
(1)
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得する第1の取得部と、
前記第2のメタデータに基づいて、前記第1のメタデータを取得する第2の取得部と、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部と
を備える受信装置。
(2)
前記制御部は、前記第1のフラグが、前記第1のメタデータのみで前記サービスを構成するコンポーネントが取得できることを示しており、かつ前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがないことを示している場合、前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
(1)に記載の受信装置。
(3)
前記第2の取得部は、前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがあることを示している場合、前記通信経由で伝送されるコンポーネントのストリームの再生を管理するための第3のメタデータを取得し、
前記制御部は、前記第1のメタデータ及び前記第3のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームと、前記通信経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
(1)に記載の受信装置。
(4)
前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
(1)乃至(3)のいずれかに記載の受信装置。
(5)
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTE(File Delivery over Unidirectional Transport)を拡張したROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送される
(4)に記載の受信装置。
(6)
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBP(Base Band Packet)ストリームで伝送される
(5)に記載の受信装置。
(7)
前記第2の取得部は、放送経由又は通信経由で伝送される前記第1のシグナリングデータを取得する
(4)乃至(6)のいずれかに記載の受信装置。
(8)
前記コンポーネントは、ビデオ、オーディオ、又は字幕であり、
前記サービスは、番組である
(1)乃至(7)のいずれかに記載の受信装置。
(9)
前記第1のメタデータは、LSID(LCT Session Instance Description)であり、
前記第2のメタデータは、SCD(Service Configuration Description)である
(1)乃至(8)のいずれかに記載の受信装置。
(10)
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得し、
前記第2のメタデータに基づいて、前記第1のメタデータを取得し、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
ステップを含む受信方法。
(11)
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成する生成部と、
生成された前記第2のメタデータを送信する送信部と
を備える送信装置。
(12)
前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
(11)に記載の送信装置。
(13)
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
(12)に記載の送信装置。
(14)
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBPストリームで伝送される
(13)に記載の送信装置。
(15)
送信装置の送信方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成し、
生成された前記第2のメタデータを送信する
ステップを含む送信方法。
IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得する第1の取得部と、
前記第2のメタデータに基づいて、前記第1のメタデータを取得する第2の取得部と、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部と
を備える受信装置。
(2)
前記制御部は、前記第1のフラグが、前記第1のメタデータのみで前記サービスを構成するコンポーネントが取得できることを示しており、かつ前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがないことを示している場合、前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
(1)に記載の受信装置。
(3)
前記第2の取得部は、前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがあることを示している場合、前記通信経由で伝送されるコンポーネントのストリームの再生を管理するための第3のメタデータを取得し、
前記制御部は、前記第1のメタデータ及び前記第3のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームと、前記通信経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
(1)に記載の受信装置。
(4)
前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
(1)乃至(3)のいずれかに記載の受信装置。
(5)
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTE(File Delivery over Unidirectional Transport)を拡張したROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送される
(4)に記載の受信装置。
(6)
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBP(Base Band Packet)ストリームで伝送される
(5)に記載の受信装置。
(7)
前記第2の取得部は、放送経由又は通信経由で伝送される前記第1のシグナリングデータを取得する
(4)乃至(6)のいずれかに記載の受信装置。
(8)
前記コンポーネントは、ビデオ、オーディオ、又は字幕であり、
前記サービスは、番組である
(1)乃至(7)のいずれかに記載の受信装置。
(9)
前記第1のメタデータは、LSID(LCT Session Instance Description)であり、
前記第2のメタデータは、SCD(Service Configuration Description)である
(1)乃至(8)のいずれかに記載の受信装置。
(10)
受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得し、
前記第2のメタデータに基づいて、前記第1のメタデータを取得し、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
ステップを含む受信方法。
(11)
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成する生成部と、
生成された前記第2のメタデータを送信する送信部と
を備える送信装置。
(12)
前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
(11)に記載の送信装置。
(13)
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
(12)に記載の送信装置。
(14)
前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBPストリームで伝送される
(13)に記載の送信装置。
(15)
送信装置の送信方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成し、
生成された前記第2のメタデータを送信する
ステップを含む送信方法。
1,2 サービス提供システム, 10 送信装置, 20A,20B,20 受信装置, 30 ブロードバンドサーバ, 40 インターネットサーバ, 50 中継局, 60 アクセスポイント, 90 インターネット, 111 シグナリング生成部, 113 ビデオデータ取得部, 115 オーディオデータ取得部, 117 字幕データ取得部, 122 送信部, 212 チューナ, 214 制御部, 217 通信部, 251 選局制御部, 252 フィルタリング制御部, 253 シグナリング取得部, 254 シグナリング解析部, 255 通信制御部, 256 パケットヘッダ監視部, 271 LLSシグナリング取得部, 272 SCSシグナリング取得部, 311 シグナリング生成部, 313 ビデオデータ取得部, 315 オーディオデータ取得部, 317 字幕データ取得部, 322 通信部, 900 コンピュータ, 901 CPU
Claims (15)
- IP(Internet Protocol)伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得する第1の取得部と、
前記第2のメタデータに基づいて、前記第1のメタデータを取得する第2の取得部と、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する制御部と
を備える受信装置。 - 前記制御部は、前記第1のフラグが、前記第1のメタデータのみで前記サービスを構成するコンポーネントが取得できることを示しており、かつ前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがないことを示している場合、前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
請求項1に記載の受信装置。 - 前記第2の取得部は、前記第2のフラグが、前記通信経由で伝送されるコンポーネントのストリームがあることを示している場合、前記通信経由で伝送されるコンポーネントのストリームの再生を管理するための第3のメタデータを取得し、
前記制御部は、前記第1のメタデータ及び前記第3のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームと、前記通信経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
請求項1に記載の受信装置。 - 前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
請求項1に記載の受信装置。 - 前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTE(File Delivery over Unidirectional Transport)を拡張したROUTE(Real-time Object Delivery over Unidirectional Transport)セッションで伝送される
請求項4に記載の受信装置。 - 前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBP(Base Band Packet)ストリームで伝送される
請求項5に記載の受信装置。 - 前記第2の取得部は、放送経由又は通信経由で伝送される前記第1のシグナリングデータを取得する
請求項4に記載の受信装置。 - 前記コンポーネントは、ビデオ、オーディオ、又は字幕であり、
前記サービスは、番組である
請求項1に記載の受信装置。 - 前記第1のメタデータは、LSID(LCT Session Instance Description)であり、
前記第2のメタデータは、SCD(Service Configuration Description)である
請求項1に記載の受信装置。 - 受信装置の受信方法において、
前記受信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを取得し、
前記第2のメタデータに基づいて、前記第1のメタデータを取得し、
前記第1のメタデータに基づいて、前記放送経由で伝送されるコンポーネントのストリームに接続して、コンポーネントの再生を制御する
ステップを含む受信方法。 - IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成する生成部と、
生成された前記第2のメタデータを送信する送信部と
を備える送信装置。 - 前記第1のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも上位の階層で伝送される第1のシグナリングデータであり、
前記第2のメタデータは、前記IP伝送方式のプロトコルスタックにおけるIP層よりも下位の階層で伝送される第2のシグナリングデータである
請求項11に記載の送信装置。 - 前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータのストリームは、FLUTEを拡張したROUTEセッションで伝送される
請求項12に記載の送信装置。 - 前記サービスは、共通のIPアドレスが付与される、前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータから構成され、
前記放送経由で伝送されるコンポーネントと、前記第1のシグナリングデータとは、異なるBBPストリームで伝送される
請求項13に記載の送信装置。 - 送信装置の送信方法において、
前記送信装置が、
IP伝送方式を用いたデジタル放送の放送波によって放送経由で伝送されるコンポーネントのストリームに関する情報を含む第1のメタデータのみで、サービスを構成するコンポーネントを取得できるかどうかを示す第1のフラグと、前記サービスを構成するコンポーネントのストリームの中に、インターネット上のサーバから通信経由で伝送されるコンポーネントのストリームがあるかどうかを示す第2のフラグとを含む第2のメタデータを生成し、
生成された前記第2のメタデータを送信する
ステップを含む送信方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014209501 | 2014-10-10 | ||
JP2014209501 | 2014-10-10 | ||
PCT/JP2015/077244 WO2016056412A1 (ja) | 2014-10-10 | 2015-09-28 | 受信装置、受信方法、送信装置、及び、送信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2016056412A1 true JPWO2016056412A1 (ja) | 2017-07-20 |
JP6610553B2 JP6610553B2 (ja) | 2019-11-27 |
Family
ID=55653029
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016553048A Expired - Fee Related JP6610553B2 (ja) | 2014-10-10 | 2015-09-28 | 受信装置、受信方法、送信装置、及び、送信方法 |
Country Status (8)
Country | Link |
---|---|
US (3) | US10305949B2 (ja) |
EP (1) | EP3206409B1 (ja) |
JP (1) | JP6610553B2 (ja) |
KR (1) | KR102456991B1 (ja) |
CN (1) | CN105981399B (ja) |
CA (1) | CA2932717C (ja) |
MX (1) | MX366870B (ja) |
WO (1) | WO2016056412A1 (ja) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010021526A2 (en) * | 2008-08-22 | 2010-02-25 | Lg Electronics Inc. | A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver |
JP6579391B2 (ja) * | 2014-07-07 | 2019-09-25 | ソニー株式会社 | 受信装置、受信方法、送信装置、及び、送信方法 |
MX366870B (es) | 2014-10-10 | 2019-07-29 | Sony Corp | Dispositivo de recepción, método de recepción, dispositivo de transmisión, y método de transmisión. |
KR101781884B1 (ko) * | 2014-11-04 | 2017-09-26 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
CN106233692B (zh) * | 2014-11-12 | 2019-09-13 | Lg电子株式会社 | 广播信号发送装置、广播信号接收装置、广播信号发送方法和广播信号接收方法 |
EP3220649A4 (en) * | 2014-11-13 | 2018-06-20 | LG Electronics Inc. | Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method |
EP3232668A4 (en) * | 2014-12-10 | 2018-06-13 | LG Electronics Inc. | Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method |
US10264624B2 (en) | 2014-12-17 | 2019-04-16 | Sony Corporation | Transmission apparatus, transmission method, reception apparatus, and reception method |
EP3249914A4 (en) * | 2015-01-21 | 2018-07-18 | LG Electronics Inc. | Broadcast signal transmission apparatus, broadcast signal receiving apparatus, broadcast signal transmission method, and broadcast signal receiving method |
US10356451B2 (en) | 2015-07-06 | 2019-07-16 | Lg Electronics Inc. | Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method |
CA3082203C (en) * | 2015-10-23 | 2022-11-08 | Sharp Kabushiki Kaisha | Signaling method, receiving method signaling device, and receiving device |
JP2019135806A (ja) * | 2018-02-05 | 2019-08-15 | ソニーセミコンダクタソリューションズ株式会社 | 復調回路、処理回路、処理方法、および処理装置 |
US11159833B2 (en) * | 2018-11-23 | 2021-10-26 | Sony Corporation | Buffer management for storing files of a received packet stream |
US11616822B2 (en) * | 2019-09-30 | 2023-03-28 | Tencent America LLC | Session-based information for dynamic adaptive streaming over HTTP |
US11570509B2 (en) | 2020-01-06 | 2023-01-31 | Tencent America LLC | Session-based information for dynamic adaptive streaming over HTTP |
US11228796B2 (en) * | 2020-01-07 | 2022-01-18 | Tencent America LLC | Pattern addressing for session-based dash operations |
US11363310B2 (en) * | 2020-09-21 | 2022-06-14 | Sony Corporation | ATSC 3.0 hospitality TV system |
US11323778B2 (en) * | 2020-09-23 | 2022-05-03 | Sony Group Corporation | Unified programming guide for content associated with broadcaster and VOD applications |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6630963B1 (en) * | 2001-01-23 | 2003-10-07 | Digeo, Inc. | Synchronizing a video program from a television broadcast with a secondary audio program |
EP2075935A1 (en) * | 2007-12-31 | 2009-07-01 | Motorola, Inc. | A method and apparatus for providing uninterrupted media to a user |
JP5045535B2 (ja) | 2008-04-28 | 2012-10-10 | ソニー株式会社 | 受信装置及び受信方法 |
WO2010021526A2 (en) * | 2008-08-22 | 2010-02-25 | Lg Electronics Inc. | A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver |
CA2743997C (en) * | 2008-11-18 | 2013-06-11 | Lg Electronics Inc. | Method for receiving a broadcast signal |
US8099752B2 (en) * | 2008-12-03 | 2012-01-17 | Sony Corporation | Non-real time services |
US8782725B2 (en) * | 2009-01-15 | 2014-07-15 | Lg Electronics Inc. | Method of processing non-real time service and broadcast receiver |
JP5278059B2 (ja) * | 2009-03-13 | 2013-09-04 | ソニー株式会社 | 情報処理装置及び方法、プログラム、並びに情報処理システム |
US8320823B2 (en) * | 2009-05-04 | 2012-11-27 | Siport, Inc. | Digital radio broadcast transmission using a table of contents |
US8621520B2 (en) * | 2009-05-19 | 2013-12-31 | Qualcomm Incorporated | Delivery of selective content to client applications by mobile broadcast device with content filtering capability |
KR101809957B1 (ko) * | 2010-03-29 | 2017-12-18 | 엘지전자 주식회사 | 비실시간 서비스 처리 방법 및 방송 수신기 |
US20130211567A1 (en) * | 2010-10-12 | 2013-08-15 | Armital Llc | System and method for providing audio content associated with broadcasted multimedia and live entertainment events based on profiling information |
FR2973632A1 (fr) | 2011-03-31 | 2012-10-05 | France Telecom | Procede d'acces a un service, notamment un portail web, par un terminal de restitution d'un flux multimedia |
CA2833762C (en) * | 2011-04-20 | 2016-09-13 | Lg Electronics Inc. | Transmission method for broadcast service, reception method therefor, and reception apparatus therefor |
US9584238B2 (en) * | 2011-06-24 | 2017-02-28 | Nokia Corporation | Accessing service guide information in a digital video broadcast system |
CN102868937A (zh) * | 2011-07-08 | 2013-01-09 | 中兴通讯股份有限公司 | 多媒体数据的传输方法及*** |
JP6071187B2 (ja) | 2011-11-09 | 2017-02-01 | オリンパス株式会社 | 撮像ユニットおよび撮像モジュール |
MX2014008657A (es) * | 2012-01-24 | 2014-10-06 | Sony Corp | Dispositivo de recepcion, metodo de recepcion, programa y sistema de procesamiento de informacion. |
US9942601B2 (en) * | 2013-01-24 | 2018-04-10 | Saturn Licensing Llc | Storing non-real time content |
US9967522B2 (en) | 2013-02-27 | 2018-05-08 | GM Global Technology Operations LLC | Driver monitoring camera system |
CN105009601A (zh) * | 2013-02-27 | 2015-10-28 | 索尼公司 | 信息处理装置和方法、程序和内容供应*** |
US8938033B2 (en) * | 2013-03-15 | 2015-01-20 | Intel Corporation | Enhanced low power active radio reception |
MX366870B (es) | 2014-10-10 | 2019-07-29 | Sony Corp | Dispositivo de recepción, método de recepción, dispositivo de transmisión, y método de transmisión. |
-
2015
- 2015-09-28 MX MX2016007240A patent/MX366870B/es active IP Right Grant
- 2015-09-28 CN CN201580002942.6A patent/CN105981399B/zh active Active
- 2015-09-28 US US15/032,409 patent/US10305949B2/en active Active
- 2015-09-28 JP JP2016553048A patent/JP6610553B2/ja not_active Expired - Fee Related
- 2015-09-28 EP EP15848219.0A patent/EP3206409B1/en active Active
- 2015-09-28 KR KR1020167014497A patent/KR102456991B1/ko active IP Right Grant
- 2015-09-28 CA CA2932717A patent/CA2932717C/en active Active
- 2015-09-28 WO PCT/JP2015/077244 patent/WO2016056412A1/ja active Application Filing
-
2019
- 2019-04-22 US US16/390,803 patent/US10841350B2/en active Active
-
2020
- 2020-10-06 US US17/064,269 patent/US11374993B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
EP3206409B1 (en) | 2024-01-03 |
CN105981399B (zh) | 2020-05-08 |
US10841350B2 (en) | 2020-11-17 |
EP3206409A1 (en) | 2017-08-16 |
US20160248828A1 (en) | 2016-08-25 |
MX2016007240A (es) | 2016-08-11 |
KR20170068408A (ko) | 2017-06-19 |
EP3206409A4 (en) | 2018-05-23 |
JP6610553B2 (ja) | 2019-11-27 |
CN105981399A (zh) | 2016-09-28 |
US10305949B2 (en) | 2019-05-28 |
KR102456991B1 (ko) | 2022-10-21 |
US20210037075A1 (en) | 2021-02-04 |
CA2932717A1 (en) | 2016-04-14 |
US20190297128A1 (en) | 2019-09-26 |
MX366870B (es) | 2019-07-29 |
US11374993B2 (en) | 2022-06-28 |
CA2932717C (en) | 2023-10-10 |
WO2016056412A1 (ja) | 2016-04-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6610553B2 (ja) | 受信装置、受信方法、送信装置、及び、送信方法 | |
KR102332387B1 (ko) | 수신 장치, 수신 방법, 송신 장치 및 송신 방법 | |
KR102484513B1 (ko) | 수신 장치, 수신 방법, 송신 장치, 및, 송신 방법 | |
JP6519586B2 (ja) | 受信装置、受信方法、送信装置、及び、送信方法 | |
KR102384709B1 (ko) | 수신 장치, 수신 방법, 송신 장치, 및 송신 방법 | |
WO2015198872A1 (ja) | 受信装置、受信方法、送信装置、及び、送信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180913 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20191001 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20191014 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6610553 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
LAPS | Cancellation because of no payment of annual fees |