特許 6545804 オーバージエアブロードキャストメディアデータに関するセッション記述情報

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6545804

(24)【登録日】2019年6月28日

(45)【発行日】2019年7月17日

(54)【発明の名称】オーバージエアブロードキャストメディアデータに関するセッション記述情報

(51)【国際特許分類】

   H04N 21/434 20110101AFI20190705BHJP

   H04N 21/84 20110101ALI20190705BHJP

   H04N 21/438 20110101ALI20190705BHJP

   G06F 13/00 20060101ALI20190705BHJP

【ＦＩ】

   H04N21/434

   H04N21/84

   H04N21/438

   G06F13/00 353C

   G06F13/00 520B

   G06F13/00 540B

【請求項の数】15

【全頁数】39

(21)【出願番号】特願2017-535781(P2017-535781)

(86)(22)【出願日】2016年1月7日

(65)【公表番号】特表2018-509022(P2018-509022A)

(43)【公表日】2018年3月29日

(86)【国際出願番号】US2016012422

(87)【国際公開番号】WO2016112157

(87)【国際公開日】20160714

【審査請求日】2018年12月21日

(31)【優先権主張番号】62/101,236

(32)【優先日】2015年1月8日

(33)【優先権主張国】US

(31)【優先権主張番号】14/989,540

(32)【優先日】2016年1月6日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507364838

【氏名又は名称】クアルコム，インコーポレイテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100163522

【弁理士】

【氏名又は名称】黒田 晋平

(72)【発明者】

【氏名】チャールズ・ヌン・ロー

(72)【発明者】

【氏名】トーマス・ストックハマー

(72)【発明者】

【氏名】マイケル・ジョージ・ルビー

(72)【発明者】

【氏名】カルロス・マルセロ・ディアス・パゾス

(72)【発明者】

【氏名】ジュン・ワン

【審査官】 富樫 明

(56)【参考文献】

【文献】 米国特許出願公開第２０１４／０１９９０４４（ＵＳ，Ａ１）

【文献】 国際公開第２０１１／１６１７３９（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１３／００３９２７８（ＵＳ，Ａ１）

【文献】 特開２０１４−２３９２７８（ＪＰ，Ａ）

【文献】 特表２００８−５３０８３５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００−２１／８５８

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

メディアデータを受信する方法であって、オーバージエア(OTA)ブロードキャストミドルウェアユニットによって、
複数のセッションに関する集約セッション記述データを受信するステップであって、前記セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、前記セッションの各々が、OTAブロードキャストの一部として送信され、前記集約セッション記述データを受信するステップは、
対応するユーザサービス記述(USD)要素を参照する識別子要素を受信するステップと、
前記複数のセッションに対応するブロードキャストストリームを識別する1つまたは複数のブロードキャストストリーム識別子要素を受信するステップと、
前記ブロードキャストストリームの送信側のIPアドレスを指定する1つまたは複数の送信側IPアドレス要素を受信するステップと、
前記ブロードキャストストリームの宛先のIPアドレスを指定する1つまたは複数の宛先IPアドレス要素を受信するステップと、
前記ブロードキャストストリームに関する宛先ポートを指定する1つまたは複数のポート要素を受信するステップと、
前記ブロードキャストストリーム内の物理レイヤパイプ(PLP)に関する識別子を指定する1つまたは複数のPLP ID要素を受信するステップと、
前記ブロードキャストストリームに関するソースフローまたはリペアフローの関連するトランスポートセッション識別子(TSI)を指定する1つまたは複数のTSI要素を受信するステップと、
前記複数のセッションに関する最高ビット転送速度を指定する1つまたは複数の帯域幅要素を受信するステップと、
前記複数のセッションに関する開始時間を指定する1つまたは複数の開始時間要素を受信するステップと、
前記複数のセッションに関する終了時間を指定する1つまたは複数の終了時間要素を受信するステップと、
を備える、受信するステップと、
前記集約セッション記述データに基づいて前記OTAブロードキャストから前記メディアデータの少なくとも一部を抽出するステップと、
を含む、方法。

【請求項2】

前記集約セッション記述データを受信するステップは、
前記OTAブロードキャストの前記メディアデータに対してアウトオブバンドで前記集約セッション記述データを受信するステップと、
メタデータによって記述される前記メディアデータを伝送する前記複数のセッションに対してアウトオブバンドで前記メタデータを受信するステップと、
の内の1つを含む、請求項1に記載の方法。

【請求項3】

前記集約セッション記述データは、前記複数のセッションの各々に関する、ファイル配信オーバー単方向トランスポート(FLUTE)に定義されたファイル配信テーブル(FDT)のデータを含む拡張ファイル配信テーブル(EFDT)データ
を含む、請求項1に記載の方法。

【請求項4】

前記受信するステップは、高速情報チャネル(FIC)データを受信するステップを含み、
前記抽出するステップは、
前記FICデータに対応する階層化コーディングトランスポート(LCT)データを判定するステップであって、前記LCTデータが前記OTAブロードキャストに含められる、ステップと、
前記LCTデータに関連するサービスレイヤシグナリング(SLS)フラグメントを判定するステップと、
前記SLSフラグメントのユーザサービス記述(USD)データを判定するステップと、
前記USDに対応するメディアプレゼンテーション記述(MPD)を判定するステップと、
前記MPDから得た要求された表現に関する表現識別情報を判定するステップと、
前記USDに対応する階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)フラグメントを判定するステップと、
前記表現識別情報を使用して、前記LSIDフラグメントから得た前記要求された表現に関するセッション記述を判定するステップと、
前記判定されたセッション記述を使用して、前記要求された表現に関するメディアデータを前記OTAブロードキャストから抽出するステップと、
を含む、請求項1に記載の方法。

【請求項5】

前記抽出されたメディアデータをキャッシュするステップと、
動的適応ストリーミングオーバーHTTP(DASH)に従って前記メディアデータを求める要求をDASHクライアントから受信するステップと、
前記要求に応答して、前記要求されたメディアデータを前記DASHクライアントに送るステップと、
をさらに含む、請求項1に記載の方法。

【請求項6】

前記OTAブロードキャストミドルウェアユニットおよび前記DASHクライアントは、共通クライアントデバイス内に含められる、
請求項5に記載の方法。

【請求項7】

前記受信するステップは、下位レイヤシグナリング(LLS)ストリームから情報を取り出すステップを含み、
前記抽出するステップは、
前記LLSストリームからの情報を使用してサービスレイヤシグナリング(SLS)ストリームに同調するステップと、
ユーザサービスバンドル記述(USBD)フラグメント、階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)フラグメント、メディアプレゼンテーション記述(MPD)フラグメント、およびScheduleフラグメントを前記SLSストリームから取り出すステップと、
前記USBDフラグメント、前記LSIDフラグメント、前記MPDフラグメント、および前記Scheduleフラグメントを使用してサービス構成要素を選択するステップと、
それぞれのリアルタイムオブジェクト配信オーバー単方向トランスポート(ROUTE)/LCTセッション上のサービス構成要素ストリームに同調するステップと、
それぞれの前記サービス構成要素ストリームからメディアデータを抽出するステップと、
を含む、請求項1に記載の方法。

【請求項8】

前記集約セッション記述データを受信するステップは、1つまたは複数のソースフロー要素を受信するステップをさらに含み、前記ソースフロー要素を受信するステップは、
各リアルタイム要素が前記複数のセッションに関するバイナリ値を有する1つまたは複数のリアルタイム要素を受信するステップと、
前記複数のセッションのうちの1つに関する前記リアルタイム要素が真の値を有するとき、前記複数のセッションのうちの1つの前記セッションのレシーバのトランスポートバッファに関するバッファサイズを記述する最小バッファサイズ要素を受信するステップと、
を含む、請求項1に記載の方法。

【請求項9】

前記集約セッション記述データを受信するステップは、前記複数のセッションのうちの1つに関する拡張ファイル配信テーブル(EFDT)要素を受信するステップをさらに含み、前記EFDT要素を受信するステップは、
前記EFDTに関する識別子を指定する識別子要素を受信するステップと、
前記EFDTのバージョンを指定するバージョン要素を受信するステップと、
前記複数のセッションのうちの1つにおけるオブジェクトに関する最長満了時間を指定するmaxExpiresDelta要素を受信するステップと、
前記EFDTによって記述される任意のオブジェクトの最大トランスポートサイズを指定するmaxTransportSize要素を受信するステップと、
前記複数のセッションのうちの1つのファイルに関するファイルユニフォームリソースロケータ(URL)またはファイルテンプレートを指定するファイルテンプレート要素を受信するステップと、
を含む、請求項1に記載の方法。

【請求項10】

前記集約セッション記述データを受信するステップは、ペイロード要素を受信するステップをさらに含み、前記ペイロード要素を受信するステップは、
前記ペイロード要素に使用されるCodePoint値を指定するCodePoint要素を受信するステップと、
前記ペイロード要素に関するペイロードフォーマットを指定する配信フォーマット識別子要素を受信するステップと、
任意、特定用途向け(サンプルベース)、または特定用途向け(ボックスの集合)を示す値を有するフラグメンテーション要素を受信するステップと、
任意、順序どおりの配信、またはメディアサンプルの順序どおりの配信およびムービーフラグメントボックスの前を示す値を有する配信順序要素を受信するステップと、
ソース前方誤り訂正(FEC)ペイロード識別子要素を受信するステップであって、前記FECペイロード識別子要素は、
ソースFECペイロード識別子が存在せず、配信オブジェクト全体が対応するパケットに含められることと、
前記ソースFECペイロード識別子が32ビット値であり、前記配信オブジェクトに関する開始オフセットを表すことと、
FECパラメータ要素が、前記ソースFECペイロード識別子に関するフォーマットを定義することと、
のうちの1つを示す値を有する、前記ソースFECペイロード識別子要素を受信するステップと、
を含む、請求項1に記載の方法。

【請求項11】

前記複数のセッションのうちの1つに関連するFEC方式のパラメータを定義する前記FECパラメータ要素を受信するステップをさらに含む、
請求項10に記載の方法。

【請求項12】

前記集約セッション記述データを受信するステップは、リペアフロー要素を受信するステップをさらに含み、前記リペアフロー要素を受信するステップは、
1つまたは複数の前方誤り訂正(FEC)パラメータを受信するステップであって、
ソースフローにおける任意のソースパケットと対応するリペアフローとの間の最長配信遅延を指定する最長遅延要素と、
オーバーヘッドをパーセンテージ値として指定するオーバーヘッド要素と、
必要なバッファサイズを指定する最小バッファ要素と、
のうちの1つまたは複数を受信するステップを含む、1つまたは複数のFECパラメータを受信するステップと、
1つまたは複数のFECオブジェクト送信情報(FECOTI)要素を受信するステップと、
前記リペアフロー要素に対応するリペアフローによって保護されるソースフローを指定する保護オブジェクト要素を受信するステップと、
を含む、請求項1に記載の方法。

【請求項13】

前記保護オブジェクト要素を受信するステップは、
前記ソースフローに関するセッション記述情報を指定するセッション記述要素を受信するステップと、
前記ソースフローに関するトランスポートセッション識別子(TSI)を指定するTSI要素を受信するステップと、
前記リペアフローに含められる送信オブジェクト識別子(TOI)に対応する配信オブジェクトのTOIを指定するソースTOI要素を受信するステップと、
各FECトランスポートオブジェクトのデフォルトサイズを指定するFECトランスポートオブジェクトサイズ要素をシンボル単位で受信するステップと、
を含む、請求項12に記載の方法。

【請求項14】

メディアデータを受信するためのデバイスであって、
オーバージエア(OTA)ブロードキャストデータを受信するように構成されたインターフェースと、
OTAブロードキャストミドルウェアユニットを備えるプロセッサであって、前記OTAブロードキャストミドルウェアユニットが、
前記インターフェースを介して、複数のセッションに関する集約セッション記述データを受信することであって、前記セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、前記セッションの各々が、OTAブロードキャストの一部として送信され、前記集約セッション記述データと、前記集約セッション記述データによって記述されるブロードキャストサービスの前記メディアコンテンツとを受信するために、前記OTAブロードキャストミドルウェアユニットが、
対応するユーザサービス記述(USD)要素を参照する識別子要素を受信することと、
前記複数のセッションに対応するブロードキャストストリームを識別する1つまたは複数のブロードキャストストリーム識別子要素を受信することと、
前記ブロードキャストストリームの送信側のIPアドレスを指定する1つまたは複数の送信側IPアドレス要素を受信することと、
前記ブロードキャストストリームの宛先のIPアドレスを指定する1つまたは複数の宛先IPアドレス要素を受信することと、
前記ブロードキャストストリームに関する宛先ポートを指定する1つまたは複数のポート要素を受信することと、
前記ブロードキャストストリーム内の物理レイヤパイプ(PLP)に関する識別子を指定する1つまたは複数のPLP ID要素を受信することと、
前記ブロードキャストストリームに関するソースフローまたはリペアフローの関連するトランスポートセッション識別子(TSI)を指定する1つまたは複数のTSI要素を受信することと、
前記複数のセッションに関する最高ビット転送速度を指定する1つまたは複数の帯域幅要素を受信することと、
前記複数のセッションに関する開始時間を指定する1つまたは複数の開始時間要素を受信することと、
前記複数のセッションに関する終了時間を指定する1つまたは複数の終了時間要素を受信することと、を行うように構成される、受信することと、
前記集約セッション記述データに基づいて前記OTAブロードキャストから前記メディアデータの少なくとも一部を抽出することと、
を行うように構成される、プロセッサと、
を備える、デバイス。

【請求項15】

命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令は、実行されたときに、メディアデータを受信するためのデバイスのプロセッサに、
複数のセッションに関する集約セッション記述データを受信することであって、前記セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、前記セッションの各々が、オーバージエア(OTA)ブロードキャストの一部として送信され、前記集約セッション記述データをプロセッサに受信することを行わせる前記命令が、前記プロセッサに、
対応するユーザサービス記述(USD)要素を参照する識別子要素を受信することと、
前記複数のセッションに対応するブロードキャストストリームを識別する1つまたは複数のブロードキャストストリーム識別子要素を受信することと、
前記ブロードキャストストリームの送信側のIPアドレスを指定する1つまたは複数の送信側IPアドレス要素を受信することと、
前記ブロードキャストストリームの宛先のIPアドレスを指定する1つまたは複数の宛先IPアドレス要素を受信することと、
前記ブロードキャストストリームに関する宛先ポートを指定する1つまたは複数のポート要素を受信することと、
前記ブロードキャストストリーム内の物理レイヤパイプ(PLP)に関する識別子を指定する1つまたは複数のPLP ID要素を受信することと、
前記ブロードキャストストリームに関するソースフローまたはリペアフローの関連するトランスポートセッション識別子(TSI)を指定する1つまたは複数のTSI要素を受信することと、
前記複数のセッションに関する最高ビット転送速度を指定する1つまたは複数の帯域幅要素を受信することと、
前記複数のセッションに関する開始時間を指定する1つまたは複数の開始時間要素を受信することと、
前記複数のセッションに関する終了時間を指定する1つまたは複数の終了時間要素を受信することと、
を行わせる命令を含む、受信することと、
前記集約セッション記述データに基づいて前記OTAブロードキャストから前記メディアデータの少なくとも一部を抽出することと、
を行わせる非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、その内容全体が参照により本明細書に組み込まれる、2015年1月8日に出願した米国仮出願第62/101,236号の利益を主張するものである。

【0002】

本開示は、符号化されたビデオデータの記憶およびトランスポートに関する。

【背景技術】

【0003】

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンスドビデオコーディング(AVC)、ITU-T H.265(「高効率ビデオコーディング」または「HEVC」とも呼ばれる)によって定められた規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。

【0004】

ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ビデオデータは、符号化された後、送信できるようにパケット化される場合がある。ビデオデータは、AVCのような、国際標準化機構(ISO)ベースメディアファイルフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、アセンブルされる場合がある。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Internet Engineering Task Force、RFC6726、2012年11月

【発明の概要】

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

【0006】

一般に、本開示の技法は、オーバージエア(OTA)ブロードキャストされたメディアデータの複数のセッションに関する集約セッション記述情報のシグナリングに関する。すなわち、セッションの各々が共通メディアコンテンツに関係するメディアをトランスポートする場合があり、セッションの各々がOTAブロードキャストの一部として送信される場合がある。共通メディアコンテンツは、たとえば、動的適応ストリーミングオーバーHTTP(DASH)による多重化された表現のセットに対応する場合がある。すなわち、各セッションは、異なる1つの表現のメディアデータをトランスポートする場合がある。集約セッション記述情報は概して、セッションの各々を記述する場合がある。たとえば、集約セッション記述情報は、ファイル配信テーブル(FDT)およびセッション記述プロトコル(SDP)ファイルと概念的に類似したデータを含んでもよい。

【0007】

一例では、メディアデータを受信する方法が、オーバージエア(OTA)ブロードキャストミドルウェアユニットによって実施され、複数のセッションに関する集約セッション記述データを受信するステップであって、セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、セッションの各々が、OTAブロードキャストの一部として送信される、受信するステップと、集約セッション記述データに基づいてOTAブロードキャストからメディアデータの少なくとも一部を抽出するステップとを含む。

【0008】

別の例では、メディアデータを受信するためのデバイスが、オーバージエア(OTA)ブロードキャストデータを受信するように構成されたインターフェースと、複数のセッションに関する集約セッション記述データをインターフェースを介して受信することであって、セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、セッションの各々が、OTAブロードキャストの一部として送信される、受信することと、集約セッション記述データに基づいてOTAブロードキャストからメディアデータの少なくとも一部を抽出することとを行うように構成されたOTAブロードキャストミドルウェアユニットを備えるプロセッサとを含む。

【0009】

別の例では、メディアデータを受信するためのデバイスが、複数のセッションに関する集約セッション記述データを受信するための手段であって、セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、セッションの各々が、OTAブロードキャストの一部として送信される手段と、集約セッション記述データに基づいてOTAブロードキャストからメディアデータの少なくとも一部を抽出するための手段とを含む。

【0010】

別の例では、非一時的コンピュータ可読記憶媒体に命令が記憶されており、命令が、実行されたときに、メディアデータを受信するためのデバイスのプロセッサに、複数のセッションに関する集約セッション記述データをインターフェースを介して受信することであって、セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、セッションの各々が、オーバージエア(OTA)ブロードキャストの一部として送信される、受信することと、集約セッション記述データに基づいてOTAブロードキャストからメディアデータの少なくとも一部を抽出することとを行わせる。

【0011】

1つまたは複数の例の詳細が、以下の添付の図面および説明に記載されている。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。

【図面の簡単な説明】

【0012】

【図1】オーバージエア(OTA)ブロードキャストを介してメディアデータをストリーミングするための技法を実施する例示的なシステムを示すブロック図である。

【図2】図1の受信ユニットの構成要素の例示的なセットをより詳細に示すブロック図である。

【図3】例示的なマルチディアコンテンツの要素を示す概念図である。

【図4】サービスのバンドルに与えられるメタデータを表す例示的な構成要素結合図を示すブロック図である。

【図5】本開示の技法に従って交換されるメタデータを表す例示的な構成要素結合図を示すブロック図である。

【図6A】例示的な階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)スキーマを示す概念図である。

【図6B】例示的な階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)スキーマを示す概念図である。

【図6C】例示的な階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)スキーマを示す概念図である。

【図7】ハイレベルサービスを発見しハイレベルサービスにアクセスするための例示的なプロセスを示す流れ図である。

【図8】本開示の技法によるパイプモデルの例を示す概略図である。

【図9】本開示の技法によるパイプモデルの例を示す概略図である。

【図10】本開示の技法によるパイプモデルの例を示す概略図である。

【図11】図5のサービスレイヤシグナリング(SLS)データモデルごとの詳細サービス発見プロセスの例を示すフロー制御図である。

【図12】例示的なベアラモデルおよび識別情報を示す概念図である。

【図13】図12のベアラモデルおよび識別情報の追加の詳細を示す概念図である。

【図14】サービス/構成要素、ROUTEセッション/(LCT)トランスポートセッションモデルおよび識別情報を示す概念図である。

【図15】本開示の技法による、アウトオブバンド集約セッション記述データを使用してオーバージエア(OTA)ブロードキャストからメディアデータを取り出すための例示的な方法を示すフローチャートである。

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

【0013】

概して、本開示は、ATSC次世代ブロードキャストテレビジョン(NGBT)とも呼ばれるATSC3.0による新型テレビジョンシステム委員会(ATSC)ブロードキャストなどのオーバージエア(OTA)ブロードキャストサービス、デジタルビデオブロードキャスティング(DVB)、統合サービスデジタル放送(ISDB)、およびデジタル地上波マルチメディア放送(DTMB)などの、他のそのようなOTAブロードキャストサービスを使用してメディアデータをブロードキャストする際のサービスデータのシグナリングおよびサービス発見ブートストラッピングに関する技法を説明する。OTAブロードキャストは、リアルタイムオブジェクト配信オーバー単方向トランスポート(ROUTE)プロトコルの技法を利用してもよい。OTAブロードキャストは、インターネットプロトコル(IP)ベースのブロードキャストサービス配信を指定し、いわゆる「サービスレイヤ」(正式にはATSC3.0において「管理およびプロトコル」レイヤと呼ばれる)の一部として提案された、第3世代パートナーシッププロジェクト(3GPP)マルチメディアブロードキャストマルチキャストサービス(MBMS)に関して定義されたユーザサービス記述(USD)/サービス告知フレームワークに基づく(たとえば、ユーザサービス記述(USD)/サービス告知フレームワークをモデルとする)ROUTEプロトコルおよび拡張可能マークアップ言語(XML)ベースのサービスシグナリングを使用する場合がある。メディアデータは、動的適応ストリーミングオーバーHTTP(DASH)に従ってフォーマットされてもよく、それによって、DASHセグメントがOTAブロードキャストの一部として伝送される。本開示では、数ある技法の中で、例示的なサービスレイヤシグナリングデータモデル、例示的なサービス発見ブートストラッピングプロセス、およびネットワークチャネル化モデルについて説明する。

【0014】

本開示では、単独で実装されてもあるいは任意の組合せにおいて実装されてもよい様々な技法について説明する。上述のように、いくつかの例では、本開示の技法は、ROUTEプロトコルを利用する場合があるOTAブロードキャストを使用して、ストリーミングセグメント、たとえば、DASHセグメントをトランスポートするときに実施されてもよい。本開示の技法は、複数のセッションに関するセッション記述プロトコル(SDP)情報を集約された単一のフラグメントとして送ることを含む。すなわち、以前の技法ではセッションごとに個々のSDPフラグメントを送った場合もあるが、本開示では、(共通メディアコンテンツに関係する)複数のセッションについて単一のフラグメントを送るための技法について説明する。共通メディアコンテンツは同じプログラムに関して同じメディアコンテンツ、たとえば、関係するオーディオオーディオ、ビデオ、および/または時限テキストメディアデータを単独で含むかまたは任意の組合せとして含む多重化されたDASH表現に対応する場合がある。単一のフラグメントは、以下においてより詳細に説明するように、階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)フラグメントを含んでもよい。したがって、同じメディアコンテンツに関係するセッションごとに個々のセッション記述情報を送る必要はない。関連するメディアコンテンツに関する複数のセッションが、たとえば、マルチビューコンテンツに関する複数のビュー、ならびに1つまたは複数のオーディオ表現および/または(たとえば、クローズドキャプション用の)時限テキスト、あるいは他のそのようなデータを含んでもよい。したがって、いくつかの例では、LSIDフラグメントは、ビュー、オーディオ、および時限テキスト表現に関するセッション情報を記述してもよい。

【0015】

別の例として、本開示では、ファイル記述子をアウトオブバンドで送るための技法について説明する。たとえば、ファイル配信テーブル(FDT)はLSIDフラグメントに含められても(すなわち、LSIDフラグメント内で伝送されても)よく、FDTは、対応するメディアデータとは別の通信において配信されても(すなわち、LSIDフラグメント外で伝送されても、あるいはLSIDを伝送する通信セッションまたは通信チャネルとは別の通信セッションまたは通信チャネルにおいて配信されても)よい。FDT全体またはFDTの一部は、対応するメディアデータとは別に配信されてもよい。このようにして、FDTをインバンドで(すなわち、対応するメディアデータと同じビットストリームおよび/または通信の一部として)配信する場合と比較してエラーレジリエンシーが改善される場合がある。

【0016】

本開示におけるインバンドFDTまたはアウトオブバンドFDTのいずれかのコンテンツは、(RFC6726に記載された)公称FDTに含められない追加のファイル記述子を含む場合があるので、本開示におけるそのようなFDTオブジェクトは正式には、拡張FDTまたはEFDTと呼ばれる。

【0017】

DASHでは、頻繁に使用される動作には、HEAD、GETおよび部分GETが含まれる。HEAD動作は、URLまたはURNと関連付けられたペイロードを取り出さずに、所与のユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)と関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、HTTPストリーミングに動画フラグメントが利用されてもよい。動画フラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在してもよい。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントがアクセス可能なデータの構造化された集合体であってもよい。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示してもよい。

【0018】

DASHの例では、マルチメディアコンテンツのビデオデータおよび/またはオーディオデータに関する複数の表現が存在してもよい。以下で説明するように、それぞれに異なる表現は、それぞれに異なるコーディング特性(たとえば、ビデオコーディング規格のそれぞれに異なるプロファイルまたはレベル)、それぞれに異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、またはそれぞれに異なるビットレートに対応する場合がある。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造において定義されてもよい。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応する場合がある。DASHクライアントは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示してもよい。メディアプレゼンテーションは、MPDの更新を含む場合があるMPDデータ構造で記述されてもよい。

【0019】

メディアプレゼンテーションは、1つまたは複数の周期のシーケンスを含んでもよい。周期は、MPDにおける周期要素によって定義されてもよい。各周期は、MPDにおける属性startを有してもよい。MPDは、周期ごとにstart属性とavailableStartTime属性とを含んでもよい。

【0020】

各周期は、同じメディアコンテンツのための1つまたは複数の表現を含んでもよい。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の周期に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用される場合がある。

【0021】

ある特定の周期の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられてもよい。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の周期のビデオデータの各表現は、同じ適応セットに割り当てられてもよいので、表現のうちのいずれもが、対応する周期のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択されてもよい。いくつかの例では、1つの周期内のメディアコンテンツは、グループ0が存在する場合にはグループ0からの1つの表現によって表されてもよく、あるいは各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表されてもよい。ある周期の各表現のタイミングデータは、周期の開始時間に対して表されてもよい。

【0022】

表現は1つまたは複数のセグメントを含んでもよい。各表現が初期化セグメントを含んでもよく、または表現の各セグメントが自己初期化するものであってもよい。初期化セグメントは、それが存在する場合、表現にアクセスするための初期化情報を含んでもよい。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照されてもよい。MPDは、各セグメントのための識別子を構成してもよい。いくつかの例では、MPDは、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに相当する場合があるrange属性の形式で、バイト範囲を提示してもよい。

【0023】

それぞれに異なるタイプのメディアデータに対して実質的に同時に取出しを行うためにそれぞれに異なる表現が選択されてもよい。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。

【0024】

図1は、オーバージエア(OTA)ブロードキャストを介してメディアデータをストリーミングするための技法を実施する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ作成デバイス20と、ブロードキャストソースデバイス60と、ブロードキャストユニット74と、クライアントデバイス40とを含む。ブロードキャストソースデバイス60は、たとえば、テレビジョンネットワークオフィス、ケーブルテレビジョンオフィスなどを備えてもよい。ブロードキャストユニット74は、たとえば、衛星、ケーブルテレビジョン分散ハブ、アンテナなどを備えてもよい。図1の例には単一のブロードキャストユニット74しか示されていないが、ブロードキャストソースデバイス60とクライアントデバイス40との間に複数の中間デバイスが位置してもよいことを理解されたい。いくつかの例では、コンテンツ作成デバイス20およびサーバデバイス60は、コンピュータベースのネットワークによって結合されてもよく、あるいは直接通信可能に結合されてもよい。代替的に、コンテンツ作成デバイス20は、ハードディスク、フラッシュドライブ、CD、DVD、ブルーレイディスクなどのコンピュータ可読記憶媒体を配布することによってブロードキャストソースデバイス60にマルチメディアコンテンツを供給してもよい。いくつかの例では、コンテンツ作成デバイス20およびブロードキャストソースデバイス60は、同じデバイスを構成してもよい。

【0025】

図1の例では、コンテンツ作成デバイス20は、オーディオソース22とビデオソース24とを備える。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備えてもよい。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備えてもよい。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備えてもよい。コンテンツ作成デバイス20は、すべての例でブロードキャストソースデバイス60に必ずしも通信可能に結合されるとは限らず、ブロードキャストソースデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶してもよい。

【0026】

生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含んでもよい。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化されてもよい。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を備えてもよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を備えてもよい。このようにして、本開示において説明する技法は、ライブオーディオデータおよびビデオデータ、ストリーミングオーディオデータおよびビデオデータ、リアルタイムオーディオデータおよびビデオデータに適用されてもよく、あるいは保管されたオーディオデータおよびビデオデータ、以前に記録されたオーディオデータおよびビデオデータに適用されてもよい。

【0027】

ビデオフレームに対応するオーディオフレームは一般に、ビデオフレーム内に含められるビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを含むオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応する場合がある。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。

【0028】

いくつかの例では、オーディオエンコーダ26は、符号化された各オーディオフレームにおいて、符号化されたオーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプを符号化してもよく、同様に、ビデオエンコーダ28は、符号化された各ビデオフレームにおいて、符号化されたビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプを符号化してもよい。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含んでもよい。コンテンツ作成デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成する場合がある内部クロック、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用する場合がある内部クロックを含んでもよい。

【0029】

いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に相当するデータをオーディオエンコーダ26に送ってもよく、ビデオソース24は、ビデオデータが記録された時間に相当するデータをビデオエンコーダ28に送ってもよい。いくつかの例では、オーディオエンコーダ26は、符号化されたオーディオデータにおいて、符号化されたオーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化してもよく、同様に、ビデオエンコーダ28も、符号化されたビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用してもよい。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。

【0030】

オーディオエンコーダ26は一般に、符号化されたオーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化されたビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の、デジタル的にコーディングされた(場合によっては、圧縮された)単一の構成要素である。たとえば、表現のコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであってもよい。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コーディングされたビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。

【0031】

図1の例では、コンテンツ作成デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコーディングされたビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコーディングされたオーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのパケタイザを含む場合がある。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26の各々は、符号化されたデータからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化されたオーディオデータおよび符号化されたビデオデータからPESパケットを形成するためのパケタイザを含む場合がある。

【0032】

ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、様々なビットレートであり、かつ/あるいは、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数のビューを有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有するマルチメディアコンテンツの様々な表現を生成してもよい。本開示において使用される表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含んでもよい。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含んでもよい。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含んでもよい。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームをアセンブルする役割を担う。

【0033】

カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。加えて、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述(MPD)などのマニフェストファイルを形成してもよい。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。

【0034】

カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを出力インターフェース32に与えてもよい。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体への書込みのためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターまたはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含んでもよい。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に与えてもよく、出力インターフェース32は、ネットワーク送信媒体または記憶媒体を介してブロードキャストソースデバイス60にデータを送ってもよい。図1の例では、ブロードキャストソースデバイス60は、それぞれのマニフェストファイル66と1つまたは複数の表現68A〜68N(表現68)とをそれぞれが含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はブロードキャストユニット74にデータを直接送ってもよい。

【0035】

いくつかの例では、表現68は、適応セットへと分割されてもよい。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を識別する場合があるテキストタイプ情報、カメラの角度または適応セット内の表現のシーンの現実世界のカメラの視野を表す場合があるカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報のような、特性のそれぞれの共通のセットを含んでもよい。

【0036】

マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、ならびに適応セットの共通の特性を含んでもよい。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含んでもよい。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にする場合がある。適応セット内の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示されてもよい。

【0037】

ブロードキャストソースデバイス60は出力インターフェース72を含む。ブロードキャストソースデバイス60は、出力インターフェース72を介してブロードキャストユニット74にマルチメディアコンテンツを供給する。

【0038】

図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応する場合があるマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含んでもよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含んでもよい。クライアントデバイス40は、メディアプレゼンテーションMPDを取り出し、表現68のセグメントにどのようにアクセスするかを判定してもよい。

【0039】

特に、受信ユニット52は、OTAブロードキャストミドルウェアユニットとメディアプレーヤクライアントの両方を含んでもよい。OTAブロードキャストミドルウェアユニットはメディアプレーヤクライアント用のプロキシサーバとして働いてもよく、このプロキシサーバは、たとえば動的適応ストリーミングオーバーHTTP(DASH)に従って、ネットワークプロトコルを介してメディアデータを取り出すように構成されてもよい。すなわち、メディアクライアントはDASHクライアントを備えてもよい。したがって、メディアクライアントは、ビデオデコーダ48の復号能力とビデオ出力44のレンダリング能力とを判定するために、クライアントデバイス40の構成データ(図示せず)を取り出してもよい。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深度の選好に対応する1つまたは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含んでもよい。メディアクライアントは、HTTP GET要求および部分GET要求をOTAブロードキャストミドルウェアユニットにサブミットするように構成されてもよい。受信ユニット52のいくつかの態様は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令として実装されてもよい。すなわち、受信ユニット52に関して説明した機能の部分は、ハードウェアとして実装されてもよく、あるいはハードウェア、ソフトウェア、および/またはファームウェアの組合せとして実装されてもよく、この場合、必要なハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために設けられてもよい。

【0040】

受信ユニット52のメディアプレーヤクライアントは、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較してもよい。メディアプレーヤクライアントは、最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定してもよい。たとえば、メディアプレーヤクライアントは、1つまたは複数の適応セットの特性を記述するマニフェストファイル66の部分を要求する場合がある。メディアプレーヤクライアントは、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たすことのできる特性を有する表現68のサブセット(たとえば、適応セット)を選択してもよい。メディアプレーヤクライアントは、次いで、適応セット内の表現に対するビットレートを判定し、ネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満たすことのできるビットレートを有する表現のうちの1つからセグメントを取り出してもよい。

【0041】

上述のように、受信ユニット52は、OTAブロードキャストミドルウェアユニットを含んでもよい。OTAブロードキャストミドルウェアユニットは、たとえばATSCに従ってOTAブロードキャスト信号を受信するように構成されてもよい。さらに、OTAブロードキャストミドルウェアユニットは、受信されたメディアデータをローカルにキャッシュし、受信ユニット52のメディアプレーヤクライアントからのデータに関するネットワーク要求に応答するネットワークプロキシサーバを実装してもよい。

【0042】

受信ユニット52は、受信されたセグメントをカプセル化解除ユニット50に供給する。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部であるかビデオストリームの一部であるかに応じて、符号化されたデータをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ってもよい。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送り、一方でビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含む場合がある復号されたビデオデータを、ビデオ出力44に送る。

【0043】

ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、受信ユニット52、およびカプセル化解除ユニット50の各々は、必要に応じて、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路のいずれかとして実装されてもよい。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、これらのいずれもが、複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合されてもよい。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、これらのいずれもが、複合コーデックの一部として統合されてもよい。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、受信ユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話のようなワイヤレス通信デバイスを含んでもよい。

【0044】

クライアントデバイス40、ブロードキャストソースデバイス60、および/またはコンテンツ作成デバイス20は、本開示の技法に従って動作するように構成されてもよい。例として、本開示は、クライアントデバイス40およびブロードキャストソースデバイス60に関するこれらの技法について説明する。しかしながら、コンテンツ作成デバイス20は、ブロードキャストソースデバイス60の代わりに(または、ブロードキャストソースデバイス60に加えて)これらの技法を実行するように構成されてもよいことを理解されたい。

【0045】

カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームを記述するデータを特定するヘッダを含むNALユニットを形成してもよい。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含み得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含んでもよい。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。

【0046】

カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットをアセンブルしてもよい。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含んでもよい。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが毎秒20フレーム(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応する場合がある。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされてもよい。一例では、アクセスユニットは、コーディングされた一次ピクチャとして提示される場合がある、1つの時間インスタンス内のコーディングされたピクチャを含んでもよい。

【0047】

したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時間Xに対応するすべてのビューを含んでもよい。本開示はまた、特定のビューの符号化されたピクチャを「ビュー構成要素」と呼ぶ。すなわち、ビュー構成要素は、特定の時間における特定のビューに対する符号化されたピクチャ(または、フレーム)を含んでもよい。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビュー構成要素を含むものとして定義されてもよい。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。

【0048】

メディアプレゼンテーションは、それぞれに異なる代替表現(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含む場合があるメディアプレゼンテーション記述(MPD)を含んでもよく、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含んでもよい。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションの動画フラグメントにどのようにアクセスするかを判定してもよい。動画フラグメントは、ビデオファイルの動画フラグメントボックス(ムーフボックス(moof box))内に配置されてもよい。

【0049】

マニフェストファイル66(たとえば、MPDを含んでもよい)は、表現68のセグメントの利用可能性を通知してもよい。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含んでもよい。このようにして、クライアントデバイス40の受信ユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントがいつ利用可能になるかを判定してもよい。

【0050】

カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルにアセンブルした後、カプセル化ユニット30は、ビデオファイルを出力できるように出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送るのではなく、ビデオファイルをローカルに記憶してもよく、あるいはビデオファイルを、出力インターフェース32を介してブロードキャストソースデバイス60などのリモートソースに送ってもよい。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえばオプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピードライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含んでもよい。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体34にビデオファイルを出力する。

【0051】

受信ユニット52は、ブロードキャストユニット74から受信されたブロードキャスト信号からNALユニットまたはアクセスユニットを抽出し、NALユニットまたはアクセスユニットを受信ユニット52に供給し、受信ユニット52はNALユニットをカプセル化解除ユニット50に配信してもよい。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部であるかビデオストリームの一部であるかに応じて、符号化されたデータをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ってもよい。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送り、一方でビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含む場合がある復号されたビデオデータを、ビデオ出力44に送る。

【0052】

図1には明示的に示されていないが、クライアントデバイス40はメディアアプリケーションをさらに含んでもよい。メディアアプリケーションは、および/あるいはオーディオデコーダ46、ビデオデコーダ48、カプセル化解除ユニット50、および/または受信ユニット52のいずれかの機能のすべてを実行してもあるいは一部を実行してもよい。たとえば、メディアアプリケーションは、受信ユニット52の一部を形成してもあるいは受信ユニット52から分離されてもよい。メディアアプリケーションは、上述の機能に加えて、クライアントデバイス40に、グラフィカルユーザインターフェース(GUI)などのユーザインターフェースをユーザに対して提示させ、映画またはその他のプログラムコンテンツなどのマルチメディアデータの選択を可能にしてもよい。メディアアプリケーションは、選択されたコンテンツを受信ユニット52に対して表示し、上述のように、受信ユニット52に、選択されたプログラムコンテンツのメディアデータを受信させてもよい。メディアアプリケーションはスタンドアロンソフトウェアであってもよい。

【0053】

さらに、本開示の技法によれば、受信ユニット52は、対応するメディアデータに対してアウトオブバンドでオブジェクト/ファイル記述子(たとえば、ファイル配信テーブル(FDT)または実質的に同様のデータ)を受信してもよい。FDTは、tools.ietf.org/html/rfc6726において利用可能な、Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Internet Engineering Task Force、RFC6726、2012年11月に準拠してもよい。追加または代替として、受信ユニット52は、同じメディアコンテンツに関係する複数のセッションに関する集約セッション記述情報を含む単一のフラグメント(たとえば、LSIDフラグメント)を受信してもよい。同様に、出力インターフェース32、72は、オブジェクト/ファイル記述子をアウトオブバンドで送り、ならびに/あるいは複数のセッションに関する集約セッション記述情報含む単一のフラグメントを送るように構成されてもよい。これらおよび他の技法について、たとえば、以下の図4〜図15に関して、より詳細に説明する。

【0054】

図2は、図1の受信ユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、受信ユニット52は、OTAミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。

【0055】

OTAミドルウェアユニット100は、OTAブロードキャスト受信ユニット106と、キャッシュ104と、プロキシサーバ102とをさらに含む。この例では、OTAブロードキャスト受信ユニット106は、OTAブロードキャストを介し、たとえば、新型テレビジョンシステム委員会(ATSC)ブロードキャストを介してデータを受信するように構成される。すなわち、OTAブロードキャスト受信ユニット106は、たとえば、ブロードキャストソースデバイス60からのブロードキャストを介してファイルを受信してもよい。

【0056】

OTAミドルウェアユニット100は、ファイルに関するデータを受信すると、受信したデータをキャッシュ104内に記憶してもよい。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体など、コンピュータ可読記憶媒体を含んでもよい。

【0057】

プロキシサーバ102は、DASHクライアント110に関するプロキシサーバとして機能してもよい。たとえば、プロキシサーバ102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に供給してもよい。プロキシサーバ102は、MPDファイル内、ならびにセグメントを取り出すことができるハイパーリンク内のセグメントに関する利用可能性時間を通知してもよい。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GET要求または部分GET要求を使用して、プロキシサーバ102にセグメントを要求してもよい。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を作成し、その要求をプロキシサーバ102にサブミットしてもよい。プロキシサーバ102は、キャッシュ104から要求されたデータを取り出し、そのような要求に応答して、そのデータをDASHクライアント110に与えてもよい。

【0058】

DASHクライアント110は、セグメントを受信した後、セグメントのデータをメディアアプリケーション112に渡してもよい。DASHクライアント110は、たとえば、メディアデータのセグメントからの抽出、および/またはメディアアプリケーション112によって使用できないデータの破棄を行うようにセグメントを処理してもよい。いくつかの例では、DASHクライアント110は、ウェブブラウザの拡張機能として実装されてもよく、メディアアプリケーション112は、ビデオおよび/または音楽再生アプリケーションとして実装されてもよい。

【0059】

本開示の技法によれば、以下においてより詳細に説明するように、OTAブロードキャスト受信ユニット106は、OTAブロードキャストの一部として共通メディアコンテンツに関係するメディアデータをトランスポートする複数のセッションに関する集約セッション記述データを受信してもよい。OTAブロードキャスト受信ユニット106は、集約セッション記述データに基づいてOTAブロードキャストからメディアデータを抽出し、抽出されたメディアデータをキャッシュ104に記憶してもよい。OTAブロードキャスト受信ユニット106は、たとえば、DASHクライアント110および/またはメディアアプリケーション112に有用なメディアデータのサブセットを抽出してもよい。たとえば、クライアントデバイス40に関する構成データが、クライアントデバイスが3次元(3D)ビデオデータを表示できないことを示す場合、OTAブロードキャスト受信ユニット106は、OTAブロードキャストから3Dビデオデータを抽出することを避け、その代わりに、OTAブロードキャストから2次元ビデオデータを抽出してもよい。

【0060】

図3は、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、またはメモリ62に記憶された別のマルチメディアコンテンツに対応する場合がある。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)124と複数の表現130〜140とを含む。表現130は、オプションのヘッダデータ132およびセグメント134A〜134N(セグメント134)を含み、一方で表現140は、オプションのヘッダデータ142およびセグメント144A〜144N(セグメント144)を含む。文字Nが、便宜的に、表現130、140の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現130、140の間に、様々な数の動画フラグメントが存在してもよい。

【0061】

MPD124は、表現130〜140とは別個のデータ構造を含んでもよい。MPD124は、図1のマニフェストファイル66に対応する場合がある。同様に、表現130〜140は、図1の表現68に対応する場合がある。一般に、MPD124は、コーディング特性およびレンダリング特性、適応セット、MPD124が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/またはリモート周期を検索するための情報(たとえば、再生中のメディアコンテンツへのターゲット広告の挿入)のような、表現130〜140の特性を一般に表すデータを含んでもよい。

【0062】

ヘッダデータ132は、存在する場合、セグメント134の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間ロケーション、セグメント134のいずれがランダムアクセスポイントを含むか、セグメント134内のランダムアクセスポイントに対するバイトオフセット、セグメント134のユニフォームリソースロケータ(URL)、またはセグメント134の他の側面を記述してもよい。ヘッダデータ142は、存在する場合、セグメント144の同様の特性を記述してもよい。追加または代替として、そのような特性はMPD124内に完全に含められてもよい。

【0063】

セグメント134、144は、コーディングされた1つまたは複数のビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含んでもよい。セグメント134のコーディングされたビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD124のデータによって記述されてもよいが、そのようなデータは図3の例には示されていない。MPD124は、本開示において説明するシグナリングされた情報のいずれかまたはすべてとともに、3GPP仕様に記載されたような特性を含んでもよい。

【0064】

セグメント134、144の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられてもよい。したがって、セグメント134、144の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、別個に取出し可能であってもよい。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント134または144を取り出してもよい。いくつかの例では、受信ユニット52のメディアプレーヤクライアントは、HTTP部分GET要求を使用して、セグメント134または144の特定のバイト範囲を取り出してもよい。

【0065】

本開示の技法によれば、MPD124のデータは、いくつかの例では、複数のセッションに関する集約セッション記述データに含められてもよく、集約セッション記述データは、複数のセッションのメディアデータに対してアウトオブバンドで送られてもよい。代替的に、MPD124のデータがセッションとともにインバンドで送られてもよい。複数のセッションの各々は、それぞれの表現130〜140に関するメディアデータを含んでもよい。

【0066】

図4は、たとえば、複数のマルチキャストIP通信チャネル/セッションを介して配信される、サービスのバンドルに与えられるシグナリングメタデータを表す例示的な構成要素結合図を示すブロック図である。図4は、図5との比較対照を目的として示されている。図4に表されているデータは一般に、従来の技法を使用して複数のチャネル/セッションに関して送信される。すなわち、セッションごとに、図4の技法に従ってセッション記述が送られる。図4は、例示的なマルチメディアブロードキャストマルチキャストサービス(MBMS)データモデルを表す。

【0067】

図5は、本開示の技法に従って、ブロードキャストソースデバイス60およびクライアントデバイス40から配信されるサービスのバンドルに関するシグナリングメタデータを表す例示的な構成要素結合図を示すブロック図である。図5は、サービスレイヤシグナリング(SLS)データモデルを表す。図5に示されているように、図4示されているようにセッションごとに別々に複数のセッション記述(たとえば、セッション記述プロトコル(SDP)データ)を送るのではなく、単一階層化コーディングトランスポート(LCT)セッションインスタンス記述(LSID)フラグメント150が複数のセッションに関して送信される。LSIDフラグメント150は、複数のセッションの各々に関するデータを含む。LSIDフラグメント150は、本開示の技法に従って複数のセッションに関する集約セッション記述データの例を表す。

【0068】

metadataEnvelope.item@metadataURIによって識別されることがあるLSIDフラグメント150を参照するuserServiceDescription@lsidURI属性が与えられる場合がある。

【0069】

MPDおよび初期化セグメント(IS)は対応するメディアデータとインバンドで配信されるので、mediaPresentationDescriptionならびに関連するオブジェクトメディアプレゼンテーション記述および初期化セグメント記述はオプションである。しかしながら、本開示の技法によれば、LSIDは、ブロードキャストユニット74によってメディアデータからアウトオブバンドでクライアントデバイス40に配信されてもよい。

【0070】

上述のように、LSIDフラグメント150は、複数のセッションを記述するデータを含んでもよい。たとえば、様々なセッションの各々は、ビデオデータ、オーディオデータ、時限テキストデータなどを含む場合がある対応するエレメンタリストリームのデータを配信してもよい。

【0071】

このようにして、LSIDフラグメント150は、図4に示すように、所与のユーザサービスに関するセッション記述フラグメントを交換してもよい。セッション記述フラグメントは、図4に示すようにdeliveryMethodインスタンスによって参照される場合がある。LSIDフラグメント150は、対応するサービスに属するすべてのROUTE/LCTセッションに関する集約されたSDP情報を含んでもよい。deliveryMethod要素は、子要素bcAppSvcおよびucAppSvcに関して保持され、これらの子要素のbasePattern(s)は、要求された表現のトランスポートモードを(表現のセグメントURLによって)判定するのに使用されてもよい。

【0072】

LSIDフラグメント150は、ユーザにとって重要なサービスに関してDASHクライアントによって選択される表現を伝送するLCTセッション(およびそのセッションパラメータ)を明確に識別するために表現IDなどの、ソースフローごとの適切なApplicationIdentifier値を含んでもよい。MPDが、メタデータフラグメントとして(たとえば、集約セッション記述データ内において)伝送されるかそれともメディアセグメントとインバンドで配信されるかにかかわらず、LSIDとMPDとの間に1対1の関連付けがあってもよい。

【0073】

関連配信プロシージャ記述(ADPD)とLSIDフラグメント150との間の論理関連付けは次のように行われてもよい。LSIDごとに、LSIDによって記述されるLCTセッション上で伝送されるコンテンツに関して、関連配信プロシージャ記述内に、ファイルリペア(FR)プロシージャおよび受信報告(PR)プロシージャを記述する0個のADPD、1個のADPD、または複数のADPDが存在してもよい(LSIDによって記述されるLCTセッションのサブセットに別個のADPDが適用される多重ケース)。したがって、LSIDからADPDへの1対0...N関係があってもよい。各ADPDインスタンスが1つまたは複数のLSIDインスタンスに適用されてもよく、したがって、ADPDからLSIDへの1対1...N関係があってもよい。

【0074】

図5の例示的なSLSデータモデルは、図4のMBMSデータモデルとのいくつかの類似点を有する。図5の例では、図4の例と同様に、ユーザサービスバンドル記述(USBD)フラグメントは、利用可能なユーザサービスの発見に関するトップレベルメタデータフラグメントであり、サービス取得を可能にするために他のメタデータフラグメントを参照する。図5のデータモデルはまた、多くの既存のユーザサービス記述(USD)フラグメント、たとえば、USBD、ADPD、Schedule、ならびに場合によってはMPDおよび/またはISを再使用する。

【0075】

しかし、図5の例示的なSLSデータモデルと図4の例との間にはいくつかの違いがある。たとえば、図5のSLSデータモデルはLSIDフラグメント150を導入し、LSIDフラグメント150は、単一のユーザサービスのコンテンツ構成要素が配信されるすべてのALC/LCTセッションに関するコンテンツ、配信フォーマット、前方誤り訂正(FEC)機構、およびアクセス情報を記述する。LSIDフラグメント150は、サービスの各LCTセッション上で伝送される配信オブジェクト/オブジェクトフローへのアクセスを可能にするためのセッション情報を含む。LSIDフラグメント150はまた、埋込みFDTパラメータを含むか、またはソースプロトコルがファイルモードにおいて動作するときにFDTパラメータを参照する。LSIDフラグメント150は、配信オブジェクトまたはオブジェクトフローの受信を識別し管理するための他の情報を含んでもよい。

【0076】

さらに、図4の例のいくつかのフラグメントは、図5のSLSデータモデルから省略されている。たとえば、セッション記述フラグメントが省略される。その代わりにセッション記述フラグメントの機能がLSIDフラグメント150(ATSCへのROUTEサブミッションでは本来指定されていない追加のパラメータを含む場合がある)に組み込まれる。FECリペアストリーム記述も省略される。その理由は、FECリペアストリーム記述の機能がLSIDによって実現される場合があるからである。セキュリティ記述は、ATSC3.0には適用できず、他のOTAブロードキャスト規格には適用できない場合がある。フィルタ記述は、基本サービスアクセスには必要とされないが、いくつかの例では、たとえば、個別化または要件のターゲッティングをサポートするために保持されてもよい。MPDおよび/またはISフラグメントも、メディアセグメント自体とインバンドで配信される可能性が高いので、SLSデータモデルではオプションである場合がある。

【0077】

さらに、同等のUSDフラグメントに対するプロファイル/制約がある場合がある。たとえば、ADPDは、ファイルリペア機能のみを含む場合があるが、受信報告機能も消費量報告機能も含まない。

【0078】

LSIDフラグメント150が与えられた場合、(LSIDフラグメント150には存在しない場合がある)セッション開始時間および終了時間などのLCTセッションに関するいくつかのSDPパラメータが保持されてもよい。複数のROUTEセッションにおいてサービス構成要素が伝送される場合があるので、送信側IPアドレス、宛先IPアドレス、およびUDPポート番号が保持される場合もある。LCTセッションの受信に必要なバッファサイズの割振りに関してSDP帯域幅修飾子がレシーバに有用である場合があるので、SDP帯域幅修飾子を使用するデータ転送速度が保持される場合もある。そのようなデータは、LSIDフラグメント150または別のフラグメントにおいて単独でシグナリングされるかあるいは任意の組合せとしてシグナリングされてもよい。

【0079】

しかし、セッションにおけるチャネルの数は不要である(デフォルト値は1に等しい)。TSIは、LSIDフラグメント150によって与えられる場合があるので不要である。プロトコルIDのデフォルト値はROUTE/UDPであるのでプロトコルIDを省略することが可能である。メディアタイプおよびフォーマットリストは、MPDにおいて与えられる情報と重複し、したがって、省略されてもよい。そのようなMBMS固有のデータがATSCなどのOTAブロードキャストとは無関係であるので、メディアごとのMBMSのモードは不要である。FEC機能および関連パラメータは、LSIDフラグメント150においてシグナリングされ、したがって、省略されてもよい。さらに、メディアデータごとのサービス言語は、MPDの@langパラメータと重複するので省略されてもよい。

【0080】

図6A〜図6Cは、LSIDフラグメント150に関する例示的なLSIDスキーマを示す概略図である。以下のTable 1(表1)は、図6A〜図6CのLSIDスキーマに従ってLSIDに含められる場合があるデータの一例である。

【0081】

【表1A】

【0082】

【表1B】

【0083】

【表1C】

【0084】

【表1D】

【0085】

【表1E】

【0086】

凡例:
属性に関して: M=必須、O=オプション、OD=デフォルト値についてはオプション、CM=条件付きで必須。しかし、実施形態によっては、必要に応じて、上記の「M」または「CM」が付された属性が省略されてもよいことが諒解されよう。
要素に関して: <minOccurs>…<maxOccurs> (N=無制限)
要素は太字であり、属性は太字以外であり、@の後に続く。

【0087】

LSIDフラグメント150は、図6A〜図6Cの例に従って、Table 1(表1)のデータのうちのいずれかまたはすべてを含んでもよい。クライアントデバイス40の受信ユニット52のOTAブロードキャスト受信ユニット106はLSIDフラグメント150を受信してもよい。したがって、OTAブロードキャスト受信ユニット106は、対応するユーザサービス記述(USD)識別子要素を参照する識別子要素と、複数のセッションに対応するブロードキャストストリームを識別する1つまたは複数のブロードキャストストリーム識別子要素と、ブロードキャストストリームの送信側に関するIPアドレスを指定する1つまたは複数の送信側IPアドレス要素と、ブロードキャストストリームの宛先に関するIPアドレスを指定する1つまたは複数の宛先IPアドレス要素と、ブロードキャストストリームに関する宛先ポートを指定する1つまたは複数のポート要素と、ブロードキャストストリーム内の物理レイヤパケット(PLP)に関する識別子を指定する1つまたは複数のPLP ID要素と、ブロードキャストストリームの関連するソースフローまたはリペアフローのトランスポートセッション識別子(TSI)を指定する1つまたは複数のTSI要素と、複数のセッションに関する最高ビット転送速度を指定する1つまたは複数の帯域幅要素と、複数のセッションに関する開始時間を指定する1つまたは複数の開始時間要素と、複数のセッションに関する終了時間を指定する1つまたは複数の終了時間要素とを受信してもよい。

【0088】

同様に、OTAブロードキャスト受信ユニット106は、各々が複数のセッションに関するバイナリ値を有する1つまたは複数のリアルタイム要素と、複数のセッションのうちの1つのセッションに関するリアルタイム要素が真の値を有するときに、複数のセッションのうちのこのセッションのレシーバのトランスポートバッファに関するバッファサイズを記述する最小バッファサイズ要素とを受信することを含め、1つまたは複数のソースフロー要素を受信してもよい。

【0089】

同様に、OTAブロードキャスト受信ユニット106は、複数のセッションのうちの1つに関する拡張ファイル配信テーブル(EFDT)要素を受信してもよく、この受信は、EFDTに関する識別子を指定する識別子要素と、EFDTのバージョンを指定するバージョン要素と、複数のセッションのうちの1つにおけるオブジェクトに関する最長満了時間を指定するmaxExpiresDelta要素と、EFDTによって記述される任意のオブジェクトの最大トランスポートサイズを指定するmaxTransportSize要素と、複数のセッションのうちの1つのセッションのファイルに関するファイルユニフォームリソースロケータ(URL)またはファイルテンプレートを指定するファイルテンプレート要素とを受信することを含む場合がある。

【0090】

さらに、OTAブロードキャスト受信ユニット106は、ペイロード要素に使用されるコードポイント値を指定するコードポイント要素と、ペイロード要素に関するペイロードフォーマットを指定する配信フォーマット識別子要素と、任意、特定用途向け(サンプルベース)、または特定用途向け(ボックスの集合)を示す値を有するフラグメンテーション要素と、任意、順序どおりの配信、またはメディアサンプルの順序どおりの配信およびムービーフラグメントボックスの前を示す値を有する配信順序要素と、ソースFEC識別子要素が存在せず、配信オブジェクト全体が対応するパケット内に含められること、ソースFECペイロード識別子が32ビット値であり、配信オブジェクトに関する開始オフセットを表すこと、またはFECパラメータ要素がソースFECペイロード識別子に関するフォーマットを定義することのうちの1つを示す値を有するソース前方誤り訂正(FEC)ペイロード識別子要素とを受信することを含め、ペイロード要素を受信してもよい。

【0091】

さらに、OTAブロードキャスト受信ユニット106は、ソースフロー内の任意のソースパケットと対応するリペアフローとの間の最長配信遅延を指定する最長遅延要素、オーバーヘッドをパーセンテージ値として指定するオーバーヘッド要素、または必要なバッファサイズを指定する最小バッファ要素を含む1つまたは複数の前方誤り訂正(FEC)パラメータと、1つまたは複数のFECオブジェクト送信情報(FECOTI)要素と、リペアフロー要素に対応するリペアフローによって保護されるソースフローを指定する保護オブジェクト要素とを受信することを含め、リペアフロー要素を受信してもよい。

【0092】

図7は、ハイレベルサービスを発見しハイレベルサービスにアクセスするための例示的なプロセスを示す流れ図である。詳細には、図7は、データの様々なレイヤと、データがサービス発見を実行するように処理される場合がある一般的な順序とを示す。最初に(1)、レシーバ(受信ユニット52など)が、下位レイヤシグナリング(LLS)ストリームから高速の発見および取得を行うのに必要な基本的な情報を事前に記憶する。ユーザ対話(たとえば、直接的な同調)が生じると、レシーバは、図7に示すLLS情報を使用することによってサービスレイヤシグナリング(SLS)ストリームに同調し、次いでSLS(たとえば、ストリーミングサービスアクセスに関するUSBDフラグメント、LSIDフラグメント、MPDフラグメント、およびScheduleフラグメント)を取得して適切なサービス構成要素を選択する(2)。レシーバは次いで、ROUTE/LCTセッション上のサービス構成要素ストリームに同調し、構成要素ストリームのメディアデータを取得しレンダリングする(3)。下位レイヤシグナリング(LLS)は、論理高速情報チャネル(FIC)およびサービス構成記述(SCD)データを含んでもよく、これらのデータはまとまって、アクセス可能なすべてのアクセスとそのチャネル名、チャネル番号などのリストを作成するためのレシーバによる高速チャネルスキャニングを可能にし、レシーバがサービスごとにSLSを発見するためのブートストラップ情報を供給する。

【0093】

図8〜図10は、本開示の技法によるパイプモデルの例を示す概略図である。概して、図8〜図10では、様々な「パイプ」が他のパイプ内にカプセル化される。最上位レイヤのパイプはBroadcastStreamであり、これは無線周波数チャネルである。図8および図9では、単一のBoadcastStreamが物理レイヤにおいてベースバンドパケット(PLP)ストリームをカプセル化する。図10では、複数のBroadcastStreamがそれぞれのストリームをカプセル化する。図8の例では、(共通IPアドレスを有する)サービスチャネル全体が単一のPLPストリーム内にカプセル化され、一方、図9の例では、サービスチャネルが複数のPLPストリームにわたる。さらに、図10では、サービスチャネルが複数のPLPストリームおよびBroadcastStreamにわたってもよい。

【0094】

サービスチャネルは、論理ブロードキャストベアラとして、複数のLCTセッションを含み、LCTセッションの各々が、連続的なメディアストリームを伝送し、たとえば、ビデオストリーム、オーディオストリーム、および/または時限テキスト/クローズドキャプション(CC)ストリーム、あるいはテキストファイルまたは静止画像などの個別メディアのうちの1つまたは複数を任意の組合せとして伝送してもよい。サービスチャネルにおけるLCTセッションの1つは、(LSIDを含む)SLSメタデータフラグメントの配信専用になる。図8の例では、メディアストリームのすべてが単一の物理レイヤパイプ(PLP)ストリーム内に含められ、図9の例では、様々なメディアストリームがそれぞれに異なるサービスチャネルの一部として送信されてもよい。さらに、図10では、様々なメディアストリームが、複数のPLPストリームおよび同様に複数のBroadcastStreamにわたる同じサービスチャネルの一部として送信されてもよい。

【0095】

図8〜図10の例ではまた、高速情報チャネル(FIC)データおよびサービス構成記述(SCD)データがそれぞれ、BroadcastStreamおよびPLPストリーム内にカプセル化される。代替として、FICとSCDは(オプションで)、PLPストリーム内にまとめてカプセル化される。実装形態は、これらのオプションのうちのいずれを利用してもよく、あるいはこのデータが他の場所でカプセル化されてもよい。

【0096】

図11は、図5のSLSデータモデルごとの詳細サービス発見プロセスの例を示すフロー制御図である。最初に、受信ユニット52は、スキャニングフェーズにおいてFICデータを取得し、FICデータを使用してLCTチャネルを識別し、サービスレイヤシグナリングデータ、すなわち、オンエアストリームからの(tsi-0およびtoi-sls-bundle)データおよび対応するSLSフラグメントを伝送するLCTチャネルおよびトランスポートオブジェクトを識別する(1)。受信ユニット52は次いで、SLSフラグメントを使用してTSI(tsi-0) TOI(toi-sls-bundle)を識別する(2)。受信ユニット52は次いで、ユーザサービス記述(USD)フラグメントにアクセスし、次に関連するMPDフラグメント、LSIDフラグメント、およびScheduleフラグメントにアクセスするために、SLSバンドルに関するデフォルトTSI(TSI=0)および事前に割り振られたTOI値(TOI=「toi-sls-bundle」)上で伝送されるサービスシグナリングデータを取得する(3)。これらの表現に関するMPD整合識別子において識別されるビデオおよびオーディオコンテンツの要求される表現に関する識別子はLSIDフラグメント150内に存在してもよい。したがって、受信ユニット52は、要求された表現に関するLSID情報を使用してオンエアストリーム、たとえば、オーディオセグメントおよびビデオセグメント内の対応するメディアデータを識別する(4)。

【0097】

したがって、受信ユニット52のOTAブロードキャスト受信ユニット106は、図11のプロセスを使用して要求されたメディアデータ(たとえば、ビデオ表現、オーディオ表現、および/または時限テキスト/CC表現)を識別してもよい。OTAブロードキャスト受信ユニット106は、要求された表現のメディアデータを、後でDASHクライアント110からの要求に応答してプロキシサーバ102によって抽出できるようにキャッシュ104にキャッシュしてもよい。

【0098】

図12は、例示的なベアラモデルおよび識別情報を示す概念図である。「ブロードキャストストリーム」は、「トランスポートストリーム」または「RF-割振り」と実質的に同様である。ブロードキャストストリーム(BS)は、「AreaID + FrequencyID」にマップされるBSIDによって識別されてもよい。BSの一意性は、何らかの機関、たとえば、連邦通信委員会(FCC)によって保証されていると仮定される。

【0099】

各物理レイヤパイプ(PLP)は、「MBMSベアラ」、すなわち、差別化されたサービス品質パイプが得られるように一意の変調およびコーディング方式(MCS)が適用される論理ブロードキャストチャネルリソースに類似している。PLPは、対応するBSの範囲内であるPLPIDによって識別されてもよい。

【0100】

図13は、図12のベアラモデルおよび識別情報の追加の詳細を示す概念図である。図13に示すように、BSIDは「AreaID + FrequencyID」にマップされてもよい。PLPは、対応するBSの範囲内で一意である。

【0101】

図14は、サービス/構成要素、ROUTEセッション/(LCT)トランスポートセッションモデルおよび識別情報の例を示す概念図である。

【0102】

図15は、アウトオブバンド集約セッション記述データを使用してオーバージエア(OTA)ブロードキャストからメディアデータを取り出すための例示的な方法を示すフローチャートである。図15の方法については、図3のOTAブロードキャストミドルウェアユニット100によって実施されるものとして説明する。しかしながら、他のデバイスがこの方法または同様の方法を実行するように構成される場合があることを理解されたい。

【0103】

この例では、OTAブロードキャストミドルウェアユニット100は、アウトオブバンド集約セッション記述データを受信する(200)。集約セッション記述データは、たとえばそれぞれの複数の複数の表現に関するそれぞれのメディアデータをトランスポートする、たとえば複数のセッションの形をしたメディアデータのOTAブロードキャストに対して「アウトオブバンド」である。言い換えれば、OTAブロードキャストミドルウェアユニット100は、集約セッション記述データをOTAブロードキャストのメディアデータとは別に受信する。集約セッション記述データは、LSIDフラグメントまたは同様の情報を含む他のデータユニットに適合してもよい。たとえば、集約セッション記述データは上記のTable 1(表1)に適合してもよい。さらに、集約セッション記述データは、複数のセッションに関するFLUTEのFDTに類似しているが、公称FDTには含められない追加のファイル記述子を含む場合があるEFDTデータを含んでもよい。OTAブロードキャストミドルウェアユニット100は、メディアデータを含むOTAブロードキャストも受信する(202)。

【0104】

OTAブロードキャストミドルウェアユニット100は、集約セッション記述データを使用して、受信されたOTAブロードキャストからメディアデータの少なくとも一部を抽出する(204)。たとえば、OTAブロードキャストミドルウェアユニット100は、図7に関して上記において説明したプロセスを使用してメディアデータを抽出してもよい。OTAブロードキャストミドルウェアユニット100は、たとえば、クライアントデバイス40および/またはユーザ入力によってサポートされるコーディング特性および/またはレンダリング特性に基づいて、メディアデータのすべてを抽出してもよく、あるいはクライアントデバイス40によって使用することのできるメディアデータの部分のみを抽出してもよい。

【0105】

OTAブロードキャストミドルウェアユニット100は、メディアデータを抽出した後、抽出されたメディアデータをキャッシュ104にキャッシュしてもよい(206)。OTAブロードキャストミドルウェアユニット100はその後、たとえばDASHクライアント110からメディアデータを求める要求を受信する場合がある(208)。OTAブロードキャストミドルウェアユニット100は、要求に応答して、要求されたメディアデータをキャッシュ104から、たとえばDASHクライアント110に配信してもよい(210)。図15には示されていないが、OTAブロードキャストミドルウェアユニット100が、1つまたは複数のMPDなどの1つまたは複数のマニフェストファイルをDASHクライアント110にさらに配信してもよく、それによって、DASHクライアント110が、メディアデータを求める要求を作成してOTAブロードキャストミドルウェアユニット100にサブミットできることを理解されたい。さらに、DASHクライアント110は、複数のそれぞれのセグメントのデータを取り出すためにOTAブロードキャストミドルウェアユニット100に複数の要求(たとえば、HTTP GET要求または部分GET要求)をサブミットしてもよい。

【0106】

このようにして、図15の方法は、OTAブロードキャストミドルウェアユニットによって、複数のセッションに関する集約セッション記述データを受信することであって、セッションの各々が、共通メディアコンテンツに関係するメディアデータをトランスポートし、セッションの各々が、OTAブロードキャストの一部として送信される、受信することと、集約セッション記述データに基づいてOTAブロードキャストからメディアデータの少なくとも一部を抽出することとを含む方法の一例を表す。

【0107】

1つまたは複数の例では、前述の機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せとして実装されてもよい。ソフトウェアとして実装される場合、機能は、1つもしくは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信されてもよく、かつハードウェアに基づく処理ユニットによって実行されてもよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、概して、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明した技法を実装するための命令、コード、および/またはデータ構造を取り出すために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスすることのできる任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含んでもよい。

【0108】

限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または命令またはデータ構造の形式の所望のプログラムコードを記憶するために使用できるとともに、コンピュータによってアクセスできる任意の他の媒体を備えることが可能である。また、いかなる接続も厳密にはコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、一方、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲に含まれるべきである。

【0109】

命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは離散論理回路のような、1つまたは複数のプロセッサによって実行されてもよい。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指す場合がある。さらに、いくつかの態様では、本明細書で説明する機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に与えられてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素に完全に実装されてもよい。

【0110】

本開示の技法は、ワイヤレス送受話器、集積回路(IC)、または1組のIC(たとえば、チップセット)を含む、多種様々なデバイスもしくは装置において実施されてもよい。本開示では、開示される技法を実行するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットについて説明したが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上述のように、様々なユニットは、コーデックハードウェアユニットとして結合されてもよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、上述のような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって構成されてもよい。

【0111】

種々の例について説明した。これらの例および他の例は以下の特許請求の範囲内に入る。

【符号の説明】

【0112】

10 システム
20 コンテンツ作成デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
34 コンピュータ可読媒体
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 受信ユニット
60 ブロードキャストソースデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68、68A〜68N 表現
72 出力インターフェース
74 ブロードキャストユニット
100 OTAブロードキャストミドルウェア
102 プロキシサーバ
104 キャッシュ
106 OTAブロードキャスト受信ユニット
110 ASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
124 メディアプレゼンテーション記述
130 表現
132 ヘッダデータ
134、134A〜134N セグメント
140 表現
142 ヘッドデータ
144、144A〜144N セグメント
150 LSIDフラグメント

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図6C】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】