特表2016-522621(P2016-522621A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ホアウェイ・テクノロジーズ・カンパニー・リミテッドの特許一覧
特表2016-522621ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス
<>
  • 特表2016522621-ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス 図000003
  • 特表2016522621-ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス 図000004
  • 特表2016522621-ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス 図000005
  • 特表2016522621-ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス 図000006
  • 特表2016522621-ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】特表2016-522621(P2016-522621A)
(43)【公表日】2016年7月28日
(54)【発明の名称】ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス
(51)【国際特許分類】
   H04N 21/235 20110101AFI20160701BHJP
   G06F 13/00 20060101ALI20160701BHJP
【FI】
   H04N21/235
   G06F13/00 550A
【審査請求】有
【予備審査請求】未請求
【全頁数】21
(21)【出願番号】特願2016-512118(P2016-512118)
(86)(22)【出願日】2014年7月15日
(85)【翻訳文提出日】2015年10月30日
(86)【国際出願番号】US2014046698
(87)【国際公開番号】WO2015009723
(87)【国際公開日】20150122
(31)【優先権主張番号】61/846,412
(32)【優先日】2013年7月15日
(33)【優先権主張国】US
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
(71)【出願人】
【識別番号】504161984
【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド
(74)【代理人】
【識別番号】100146835
【弁理士】
【氏名又は名称】佐伯 義文
(74)【代理人】
【識別番号】100140534
【弁理士】
【氏名又は名称】木内 敬二
(72)【発明者】
【氏名】アレクサンダー・ギラディ
(72)【発明者】
【氏名】シン・ワン
【テーマコード(参考)】
5B084
5C164
【Fターム(参考)】
5B084AA01
5B084AA12
5B084AB04
5B084AB07
5B084AB30
5B084AB31
5B084BA03
5B084BB04
5B084CB02
5B084CB04
5B084CB05
5B084CB22
5B084CE06
5B084CE08
5B084CE13
5B084CF12
5B084DB01
5B084DC02
5B084DC13
5B084DC17
5C164FA06
5C164MB01S
5C164SB08P
5C164SC28S
5C164TB13S
(57)【要約】
ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル(HTTP)(DASH)を実行するネットワークにおける、クライアントによるデリファレンスの方法は、更新されたメディアプレゼンテーション記述(MPD)を取り出すようにクライアントに指示するメッセージとクライアントが更新されたMPDを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第1区間を受信するステップと、更新されたMPDを取り出すステップと、更新されたMPD中のリンクをデリファレンスするステップとを有し、ここで、リンクは、更新されたMPDに記述されたストリーミングコンテンツの第2区間でストリーミングされるべきコンテンツの場所を示し、クライアントは、最小バッファ時間の2倍の長さである、ストリーミングコンテンツの第1区間の終了よりも前の時点で、デリファレンスを実行する。
【特許請求の範囲】
【請求項1】
ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル(HTTP)(DASH)を実行するシステムにおけるコンテンツストリーミングの方法であって、
システム要素により、更新されたメディアプレゼンテーション記述(MPD)の存在を通知するメッセージを含んだストリーミングコンテンツの第1区間を準備するステップと、
ストリーミングコンテンツの前記第1区間をクライアントに転送するステップと、
ストリーミングコンテンツの前記第1区間を介して前記メッセージが転送された後に、前記更新されたMPDを前記クライアントに転送するステップと
を有する方法。
【請求項2】
前記第1区間が、複数のセグメントを含み、
ストリーミングコンテンツの前記第1区間で転送される最後のセグメントに前記メッセージを含ませるステップをさらに有する、請求項1に記載の方法。
【請求項3】
前記更新されたMPDを入手可能な場所を示す指示子を前記メッセージに含ませるステップをさらに有する、請求項1に記載の方法。
【請求項4】
前記更新されたMPDが、前記クライアントが現在利用可能なMPDには記述されていないストリーミングコンテンツの第2区間中のコンテンツの記述を含む、請求項1に記載の方法。
【請求項5】
前記更新されたMPDが、ストリーミングコンテンツの前記第1区間の転送の終了の実質的直後に、ストリーミングコンテンツの前記第2区間が始まることを示す、請求項4に記載の方法。
【請求項6】
前記更新されたMPDが、リモートエンティティを参照するリンクを含み、
前記リモートエンティティは、前記クライアントへのコンテンツストリームに動的に挿入されるべきストリーミングコンテンツの前記第2区間の記述を含む、請求項4に記載の方法。
【請求項7】
前記リンクが、拡張可能なマークアップ言語(XML)リンク付け言語(XLink)リンクである、請求項6に記載の方法。
【請求項8】
前記XLinkリンクが、ストリーミングコンテンツの前記第1区間の終了よりも前の時点でデリファレンスされる、請求項7に記載の方法。
【請求項9】
ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル(HTTP)(DASH)を実行するシステムにおける、クライアントによるデリファレンスの方法であって、
更新されたメディアプレゼンテーション記述(MPD)を取り出すようにクライアントに指示するメッセージと前記クライアントが前記更新されたMPDを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第1区間を受信するステップと、
前記更新されたMPDを取り出すステップと、
前記更新されたMPD中のリンクをデリファレンスするステップと
を有し、
前記リンクは、前記クライアントへのコンテンツストリームに動的に挿入されるべきストリーミングコンテンツの第2区間の記述を含んだリモートエンティティを参照し、
前記クライアントは、ストリーミングコンテンツの前記第1区間の終了よりも前の時点で、前記デリファレンスするステップを実行する、方法。
【請求項10】
前記リンクが、拡張可能なマークアップ言語(XML)リンク付け言語(XLink)リンクである、請求項9に記載の方法。
【請求項11】
前記更新されたMPDよりも前に、初期MPDを受信するステップをさらに有し、
前記更新されたMPDに記述されたストリーミングコンテンツの前記第2区間は、前記初期MPDには記述されていない、請求項9に記載の方法。
【請求項12】
前記更新されたMPDが、ストリーミングコンテンツの前記第1区間の終了の実質的直後に、ストリーミングコンテンツの前記第2区間が始まることを示す、請求項9に記載の方法。
【請求項13】
アダプティブストリーミングコンテンツへのリンクの動的なジャストインタイムデリファレンスを実行する方法であって、
動的なマルチ区間デリファレンス手続きと静的なジャストインタイムデリファレンス手続きとの組合せに従うステップを有し、
コンテンツを記述するメディアプレゼンテーション記述(MPD)は、リモート区間要素を含み、
前記MPDの更新が、MPD妥当性期限満了イベントによってトリガされ、
前記動的なジャストインタイムデリファレンスへの準拠が、@Profiles属性によって通知される、方法。
【請求項14】
Period@xlink:actuate="onRequest"であり、かつデリファレンスがPeriodStartよりも最大で2×MPD@minBufferTime(MBT)秒前に実行される場合、第1結果区間は、妥当な区間であり、
リモート要素エンティティが2つ以上の区間要素を含む場合、前記区間要素は、リモート要素である、請求項13に記載の方法。
【請求項15】
前記MPDが、複数のリモート区間を含み、
前記複数のリモート区間のうちのいくつかは、デフォルトのコンテンツを有し、
前記複数のリモート区間のうちのいくつかは、複数の区間要素に分解され、
Period@xlink:actuate="onRequest"である場合、挿入されたコンテンツのダウンロードに与えられる時間が不十分なことに起因するエラーを回避するために、MPDの更新及びXLinkのリゾルブが、PeriodStartよりも前に完了する、請求項13に記載の方法。
【請求項16】
Pmが、主コンテンツを伝送する区間であり、
Piが、Pmの直後に挿入されるコンテンツを伝送するリモート区間であり、
Tが、区間Pmの有効期間 = PeriodStart(Pi) - PeriodStart(Pm)であり、
MBTが、MPD@minBufferTimeであり、
Piのデリファレンスが、時間T - 2×MBTで実行される、請求項15に記載の方法。
【請求項17】
時間T - 1×MBTまでに応答が無かった場合、デリファレンスが失敗に終わる、請求項16に記載の方法。
【請求項18】
@schemeIdUri="urn:mpeg:dash:event:2012"を有するAdaptationSet.InbandEventStream要素を使用して、インバンドMPD妥当性期限満了イベントの存在が通知される、請求項13に記載の方法。
【請求項19】
セグメントSR1(i)が、N個のリプレゼンテーションを含んだアダプテーションセット内のリプレゼンテーションR1のi番目のセグメントであるとき、
セグメントSR0(i)が「emsg」ボックスを含む場合、「emsg」ボックスは、セグメントSRN(i)でも伝送され、
選択されたリプレゼンテーションに関わらず、アダプテーションセットに基づくメディアが再生されるときには、すべての「emsg」ボックスが読み取られ、
1つのセグメント中には、最大でも1つの「emsg」ボックスしか存在しない
よう、「emsg」ボックスが調整される、請求項13に記載の方法。
【請求項20】
マルチ区間MPD内の同一のアセットの部分を識別するために、AssetIdentifier記述子が使用され、
異なるアセットに対しては、一意に定まる識別子(ID)が使用される、請求項13に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、Alexander Giladiによって2013年7月15日付けで出願された「Just-in-Time Dereferencing of Remote Elements in Dynamic Adaptive Streaming over Hypertext Transfer Protocol」と題した米国仮特許出願第61/846,412号に対する優先権を主張するものである。引用により、上記米国出願の全内容が本明細書に組み込まれる。
【背景技術】
【0002】
ビデオコンテンツ、オーディオコンテンツ、又はその他のコンテンツは、インターネットを介してコンテンツサーバから1つ又は複数のクライアントにストリーミングされ得る。いくつかのケースでは、ストリーミングされるコンテンツは、ストリーミングされるよりもいくらか前の時点でサーバに格納され得る。別のケース、例えば、ライブスポーツイベントのストリーミングでは、サーバは、記録デバイスからコンテンツを受信するのとほぼ同時に、当該コンテンツをストリーミングし得る。クライアントが、コンテンツをメモリロケーションに保存し、コンテンツの全体を受信し終えた後に、当該コンテンツを再生し得るといった、コンテンツを単純にダウンロードする場合とは異なり、コンテンツを受信するクライアントは、サーバからコンテンツを受信するのとほぼ同時に、当該コンテンツを再生し得る。
【発明の概要】
【課題を解決するための手段】
【0003】
一態様において、本開示は、ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル(Hypertext Transfer Protocol,HTTP)(Dynamic Adaptive Streaming over Hypertext Transfer Protocol,DASH)を実行するネットワークにおけるデータストリーミングの方法を含む。この方法は、ネットワーク要素により、更新されたメディアプレゼンテーション記述(Media Presentation Description,MPD)を取り出すようにクライアントに指示するメッセージを含んだストリーミングコンテンツの第1区間を準備するステップと、ストリーミングコンテンツの第1区間をクライアントに転送するステップとを有する。
【0004】
別の態様において、本開示は、DASHを実行するネットワークにおける、クライアントによるデリファレンスの方法を含む。この方法は、更新されたMPDを取り出すようにクライアントに指示するメッセージとクライアントが更新されたMPDを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第1区間を受信するステップと、更新されたMPDを取り出すステップと、更新されたMPD中のリンクをデリファレンスするステップとを有し、ここで、リンクは、更新されたMPDに記述されたストリーミングコンテンツの第2区間でストリーミングされるべきコンテンツの場所を示し、クライアントは、最小バッファ時間の2倍の長さである、ストリーミングコンテンツの第1区間の終了よりも前の時点で、デリファレンスを実行する。
【0005】
別の態様において、本開示は、アダプティブストリーミングコンテンツへのリンクの動的なジャストインタイムデリファレンスを実行する方法を含む。この方法は、動的なマルチ区間デリファレンス手続きと静的なジャストインタイムデリファレンス手続きとの組合せに従うステップを有し、ここで、コンテンツを記述するMPDは、リモート区間要素を含み、MPDの更新は、MPD妥当性期限満了(Validity Expiration)イベントによってトリガされ、動的なジャストインタイムデリファレンスに準拠することは、値http://dashif.org/guidelines/adin/dynamic#jitを有した@profiles属性によって通知される。
【0006】
これらの又はその他の特徴は、添付の図面及び特許請求の範囲を参照する以下の発明の詳細な説明からより明確に理解されよう。
【0007】
この開示のより完全な理解のために、添付の図面及び発明の詳細な説明に関連して、以下の簡単な説明への参照がなされる。図中、同様の符号は、同様の要素を示す。
【図面の簡単な説明】
【0008】
図1】本開示の一実施形態によるアダプティブストリーミングビデオコンテンツ配信システムの概略図である。
図2】本開示の一実施形態によるネットワーク要素の概略図である。
図3】本開示の一実施形態によるアダプティブストリーミングビデオコンテンツ配信システムにおける更新されたマニフェスト文書の配信の概略図である。
図4】本開示の一実施形態によるアダプティブストリーミングデリファレンスシステムの概略図である。
図5】本開示の一実施形態によるアダプティブストリーミングシステムにおけるデータストリーミングのための方法を示すフロー図である。
【発明を実施するための形態】
【0009】
最初に、以下では、1つ又は複数の実施形態の例示的な実装形態が提供されるが、開示されるシステム及び/又は方法は、それが既知であるか否か又は現存するか否かによらない、任意の数の技術を用いて実装されてよい、ということを理解されたい。本開示は、示された又は記載された設計例及び実装例を含む、以下に示される例示的な実装形態、図面、及び技術に限定することを意図せず、添付の特許請求の範囲内及びその均等物の全範囲内で修正がなされてよい。
【0010】
アダプティブストリーミングは、インターネット帯域幅に対して増大する要望を満たすためのメカニズムとして提案された。アダプティブストリーミングにおいて、インターネットを介してストリーミングされるデータには、複数の異なるバージョンが存在し、これらは、リプレゼンテーションと称され得る。各バージョンは、異なるサイズに圧縮されて、異なるレートで転送され得る。所与の時間に所与のクライアントにストリーミングされるバージョンは、その時間のネットワークコンディション、クライアントの能力、及び/又はその他の要素に基づいて、クライアントによって適応的に選択され得る。ビデオコンテンツは、複数の時間区間でストリーミングされ得、このとき、例えば、第1区間は、主コンテンツの第1部分を含み、第2区間は、広告を含み、かつ第3区間は、主コンテンツの第2部分を含む。クライアントがビデオコンテンツのストリーミングを要求するとき、コンテンツサーバは、クライアントに、クライアントが区間の各々に対するコンテンツを取り出し得る場所を示す複数のURL(Uniform Resource Locator)を含んだマニフェスト文書を送信し得る。
【0011】
開示されるものは、クライアントが現在利用可能なマニフェストには記述されていない新たな区間の記述を含んだ更新されたマニフェストを取り出すようにクライアントに指示するメッセージを、ビデオコンテンツサーバが、ストリーミングされるビデオコンテンツのセグメントに挿入し得るメカニズムである。更新されたマニフェストは、新たな区間がメッセージの転送の後に始まることを示してよい。また、更新されたマニフェストは、新たな区間で再生される、広告などのコンテンツの場所への参照を含んでもよい。いくつかのケースでは、新たな区間は、動的な区間であってよい。換言すれば、新たな区間の開始時間は、クライアントが現在利用可能なマニフェストが準備された時点では不明であってよい。新たな区間の開始時間が分かったとき、そのような時間は、更新されたマニフェストに含められてよい。また、開示される実施形態は、新たな区間中のコンテンツへのリンクがデリファレンスされるべき時間を指定してもよい。
【0012】
図1は、アダプティブストリーミングビデオコンテンツ配信システム100の一実施形態の概略図である。複数の異なる技術及びプロトコルがビデオストリーミングのために使用可能であり、複数のタイプのアダプティブビデオフォーマットが存在し得る。以下の説明では、DASH(Dynamic Adaptive Streaming over Hypertext Transfer Protocol(HTTP))として知られるコンテンツ配信プラットホームに焦点を合わせるが、同様の考察が他のビデオコンテンツ配信プラットホームになされ得ることを理解されたい。システム100は、1つ又は複数のDASHメディアプレゼンテーションを保持し得るサーバ110又は同様の構成要素を含み得る。メディアプレゼンテーションは、映画、テレビ番組、又は録画されたスポーツイベントなどの1つのビデオコンテンツの複数のバージョンを含み得る。クライアント120は、サーバ110から転送されるビデオコンテンツを受信し得る。
【0013】
サーバ110上の異なるバージョンのビデオコンテンツは、各バージョンのコンテンツが異なる転送レートでクライアント120に転送され得るように構成されてよい複数のデータセグメント140を含み得る。DASHを用いるビデオストリームは、サーバ110からクライアント120への、メディアプレゼンテーション記述(Media Presentation Description,MPD)130と称されるマニフェストの転送から開始されてよい。MPD130は、URLのリストと、セグメント140へのビデオストリームの分解についての記述とを含んでよく、各セグメントは、ビデオストリーム中の特定の時間フレーム及び特定の符号化に対応する。したがって、ビデオは、時間の側面と、レートの側面とで表現され得る。クライアント120は、時間ウィンドウに対応するセグメント140をダウンロードする際に達するスループットを測定し得、次いで、次の時間ウィンドウに対して、適切な転送レート及び関連する符号化を選択し得る。したがって、クライアント120は、クライアント120とサーバ110との間の経路上のチャネル品質の変化に対応し得る。
【0014】
MPD130は、1つ又は複数の区間についての情報を含み得る。各区間は、1つ又は複数のアダプテーションセット150を含み得る。各アダプテーションセット150は、1つ又は複数のリプレゼンテーション160を含み得る。各リプレゼンテーション160は、1つ又は複数のセグメント140を含み得る。区間は、タイミングデータを含んでよく、メディアコンテンツの符号化バージョンの一貫したセット(例えば、変更できない利用可能なビットレート、言語、字幕、サブタイトル等のセット)が利用可能であるコンテンツ区間を表し得る。アダプテーションセット150は、1つ又は複数のメディアコンテンツコンポーネントの相互交換可能な符号化バージョンのセットを表し得る。例えば、第1アダプテーションセット150が、主ビデオコンポーネントを含んでよく、第2アダプテーションセット151が、主オーディオコンポーネントを含んでよく、かつ(図示されていない)第3アダプテーションセットが、字幕を含んでよい。また、アダプテーションセット150は、組み合わされたビデオ及びオーディオなど、複合化コンテンツを含んでもよい。リプレゼンテーション160は、ISO−BMFF(International Organization for Standardization(ISO)Based Media File Format)バージョン又はMPEG−2 TS(Moving Picture Experts Group(MPEG)Version Two Transport System)バージョンなど、1つ又は複数のメディアコンテンツコンポーネントの配信可能な符号化バージョンを記述してよい。リプレゼンテーション160は、例えば、任意のコーデック、暗号、及び/又はメディアコンテンツを表現するためのその他のデータを記述してよい。
【0015】
クライアント120は、ネットワークコンディション、デバイス能力、ユーザ選択、及び/又はその他の要素に基づいて、リプレゼンテーション160とリプレゼンテーション161とを動的に切り替えてよい。そのような動的な切替えは、アダプティブストリーミングと称され得る。各セグメント140は、メディアコンテンツデータを含んでよく、URLに関連付けられてよく、かつ、例えば、HTTP GETリクエストにより、クライアント120によって取り出されてよい。各セグメント140は、予め定められたバイトサイズ(例えば、1000バイト)及び/又はメディアコンテンツの再生時間の間隔(例えば、2又は5秒)を含んでよい。セグメント140は、MPD130を介して知らされるURLを使用してダウンロード可能なデータの個々の最小のアドレス可能ユニットを含んでよい。区間、アダプテーションセット150、リプレゼンテーション160、及び/又はセグメント140は、属性及び要素の観点から記述されてよく、クライアント120によるメディアコンテンツのプレゼンテーションの修正のために、修正が加えられてもよい。
【0016】
図2は、開示されるシステム、方法、及びスキームの1つ又は複数の実施形態を実装するために適し得るネットワーク要素(Network Element,NE)200の一実施形態の概略図である。例えば、NE200は、図1のサーバ110又はクライアント120として動作してよい。NE200は、1つのノードに実装されてよく、又はNE200の機能が複数のノードに実装されてもよい。用語「NE」は、NE200が一例に過ぎない広い範囲のデバイスを包含し得る、ということが当業者には認識されよう。NE200は、説明を明確にすることを目的として、かつ本開示の用途に限定することを意図せずに、特定のNE実施形態又はNE実施形態のクラスに含められる。本開示に記載された少なくともいくつかの特徴及び方法は、NE200などのネットワーク装置又は構成要素として実装されてよい。例えば、本開示の特徴/方法は、ハードウェア、ファームウェア、及び/又はハードウェア上で実行されるように導入されたソフトウェアを用いて実装されてよい。
【0017】
図2に示されるように、NE200は、送信器、受信器、又はそれらの組合せであり得るトランシーバ(Tx/Rx)210を含んでよい。Tx/Rx210は、ダウンストリームエンティティにデータを送信するために、及び/又はダウンストリームエンティティからデータを受信するために、複数のダウンストリームポート220に接続されてよい。また、Tx/Rx210は、アップストリームエンティティにデータを送信するため、及び/又はアップストリームエンティティからデータを受信するための複数のアップストリームポート250に接続されてもよい。プロセッサ230は、データを処理するため、及び/又はどのノードにデータを送信するかを決定するために、Tx/Rx210に接続されてよい。プロセッサ230は、MPDに関して本開示に記載された機能を実行するためのMPDモジュール234を含んでよい。プロセッサ230は、1つ又は複数のマルチコアプロセッサ及び/又はメモリデバイス232を含んでよい。メモリデバイス232は、データストア、バッファ等として機能し得る。プロセッサ230は、汎用プロセッサとして実装されてよく、又は、1つ又は複数のASIC(Application Specific Integrated Circuit)及び/又はDSP(Digital Signal Processor)の一部分であってもよい。ダウンストリームポート220及び/又はアップストリームポート250は、電気的な及び/又は光学的な送信及び/又は受信コンポーネントを含んでよい。
【0018】
NE200に実行可能な命令をプログラム及び/又はロードすることにより、プロセッサ230、MPDモジュール234、Tx/Rx210、メモリ232、ダウンストリームポート220、及び/又はアップストリームポート250のうちの少なくとも1つが変更され、NE200は、本開示によって教示される新規な機能性を有する特定の機械又は装置へと部分的に変わる、ということが理解されよう。コンピュータに実行可能なソフトウェアをロードすることによって実装可能な機能性が、既知の設計規則によってハードウェア実装と可換であることは、電気技術及びソフトウェア技術の分野の基本である。典型的に、ソフトウェアとして実装するかハードウェアとして実装するかの判断は、ソフトウェア領域からハードウェア領域に変換する際に生じる何らかの問題点ではなく、設計の安定性及び生み出されるユニットの数を考慮して決まる。一般に、ハードウェア実装の再設計(リスピン)は、ソフトウェア設計の再設計よりも高価であるので、頻繁な変更の原因となる設計は、ソフトウェアとして実装されることが望ましいと言えよう。一般に、ハードウェア実装で動作する大部分の製品は、ソフトウェア実装よりも安価となり得るので、大量に製造されることが分かっている設計は、ハードウェア、例えば、ASICなどで実行されることが望ましいと言えよう。多くの場合、設計は、ソフトウェア形態で開発され、テストされ、その後、既知の設計規則によって、ソフトウェア命令を有線接続化した特定用途向け集積回路中の均等なハードウェア実装へと変換される。新たなASICによってコントロールされる機械が特定の機械又は装置であるのと同じく、実行可能な命令がプログラム及び/又はロードされた同様のコンピュータは、特定の機械又は装置と見なされてよい。
【0019】
本開示の任意の処理は、コンピュータシステム中のプロセッサ(例えば、コンピュータシステム内部の汎用中央処理ユニット(Central Processing Unit,CPU))にコンピュータプログラムを実行させることによって実施されてよい、ということを理解されたい。この場合、コンピュータプログラム製品は、任意のタイプの非一時的なコンピュータ読み取り可能な媒体を用いて、コンピュータ又はモバイルデバイスに提供できる。コンピュータプログラム製品は、コンピュータ又はネットワークデバイス中の非一時的なコンピュータ読み取り可能な媒体に格納されてよい。非一時的なコンピュータ読み取り可能な媒体は、任意のタイプの有形記憶媒体を含み得る。非一時的なコンピュータ読み取り可能な媒体の例としては、(フロッピー(登録商標)ディスク、磁気テープ、ハードディスクドライブなどの)磁気記憶媒体、(磁気光学ディスクなどの)光磁気記憶媒体、CD−ROM(Compact Disc Read-Only Memory)、CD−R(Compact Disc Recordable)、CD−R/W(Compact Disc Rewritable)、DVD(Digital Versatile Disc)、BD(Blu−ray(登録商標)Disc)、及び(マスクROM、プログラマブルROM(PROM)、イレーサブルPROM、フラッシュROM、RAM(Random Access Memory)などの)半導体メモリがある。また、コンピュータプログラム製品は、任意のタイプの一時的なコンピュータ読み取り可能な媒体を用いて、コンピュータ又はネットワークデバイスに提供されてもよい。一時的なコンピュータ読み取り可能な媒体の例としては、電気信号、光信号、及び電磁波がある。一時的なコンピュータ読み取り可能な媒体は、有線通信回線(例えば、電線又は光ファイバ)又は無線通信回線を介してコンピュータにプログラムを提供できる。
【0020】
先に記載の通り、ビデオコンテンツは、後のストリーミングのために、サーバに格納されてよい。主コンテンツ中に広告が挿入される場合、広告が再生されるべき時間は、コンテンツに対するMPDが準備される時点で知られていてよい。そのような場合、MPDは、主コンテンツの各部分及び各広告の開始時間又は長さを含み得る。例えば、MPDは、既知の開始時間又は既知の長さを有した第1主コンテンツ区間、それに続く、既知の開始時間又は既知の長さを有した区間、それに続く、既知の開始時間又は既知の長さを有した第2主コンテンツ区間を記述してよい。MPDは、各区間で再生されるべきコンテンツの場所を指定するURL、又はそのようなURLを発見し得る場所へのリンクを含んでよい。
【0021】
別のケースでは、コンテンツは、ストリーミングに先立ってサーバに格納されず、その代わりに、コンテンツが記録されるのとほぼ同時にストリーミングされる。そのようなライブストリーミングは、例えば、ライブスポーツイベントのストリーミングに利用され得る。そのような場合、広告が再生される時間は、イベントの開始よりも前には分からず、その代わりに、審判がタイム(time-out)を宣言したときなど、イベントの状況に応じて生じ得る。そのようなイベントよりも前に、広告が現れる区間の開始時間を記述するためにMPDを生成することは不可能であろう。
【0022】
本開示の実施形態は、ストリーミングの開始よりも前には区間の開始時間が分からない場合の、ストリーミングコンテンツへの区間挿入のためのメカニズムを提供する。図3は、広告又はその他の二次コンテンツが、ストリーミングが開始されたときには不明な時間で、コンテンツの主ストリームに挿入され得るシステム300を示す。第1主コンテンツ区間310は、図1のサーバ110などのサーバによって、準備され、転送されてよい。一実施形態において、第1区間310は、複数のセグメント312を含んでよいが、複数のセグメント312は、そのうちの1つを除いて、ビデオ及び/又はオーディオコンテンツなどのストリーミングコンテンツを含んでよい。区間310で転送される最後のセグメント312fは、ビデオ又はオーディオコンテンツでなはく、サーバによって挿入されるメッセージを含んでよい。最後のセグメント312f中のメッセージは、図1のクライアント120と実質的に同一であってよいクライアント320に、更新されたMPD330を取り出すように指示する。メッセージは、更新されたMPD330をどこで発見し得るかをクライアント320に通知するURL又はその他の指示子を含んでよい。
【0023】
更新されたMPD330は、クライアント320が現在利用可能なMPDには記述されていない、新たに挿入された区間340中のコンテンツの記述332を含んでよい。記述332は、主コンテンツの第1区間340の転送の終了のほぼ直後に、挿入された区間340が始まることを示してよい。また、更新されたMPD330は、挿入された区間340で再生されるコンテンツを発見し得る場所を指定するリンク334を含んでもよい。いくつかのケースでは、挿入された区間340で再生されるコンテンツは、広告であり得る。
【0024】
第1主コンテンツ区間310の最後のセグメント312f中のメッセージは、挿入された区間340が終了したときに第2主コンテンツ区間350が始まることを、クライアント320に通知してよい。第1主コンテンツ区間310中の最後のセグメント312fと同様の、第2主コンテンツ区間350中の最後のセグメント352fは、第2主コンテンツ区間350の終了の後に挿入される別の区間に対する別の更新されたMPDを取り出すように、クライアント320に指示するメッセージを含んでよい。このようにして、広告又はその他の二次コンテンツは、ストリーミングの開始前にはそれらが生じる時間が分からない場合でも、ストリーム中の適切な時間で、コンテンツストリームに挿入され得る。
【0025】
いくつかのケースでは、異なる広告が、異なるクライアントをターゲットとし得る。そのような場合、MPDは、所与の時間で再生される1つの広告の対する固定されたURLを含まなくてよい。一実施形態において、挿入された区間340中のコンテンツへの、更新されたMPD330中のリンク334は、異なるクライアントに対し、異なる時間で、異なるURLにデリファレンスされてよい。URLは、異なるクライアントに対する異なる広告/コンテンツを含んだリモートエンティティを指し示してよい。いくつかの実施形態では、更新されたMPD330中のリンク334は、ストリーム可能なコンテンツの記述を含んだリモートエンティティを指し示してよい。例えば、そのようなリンクは、本開示中では、XLinkと称され得る、拡張可能なマークアップ言語(Extensible Markup Language,XML)リンク付け言語リンクであってよい。例えば、クライアント320は、コンテンツストリームに挿入されるべきコンテンツの記述を指し示し得る、更新されたMPD330を受信してよい。クライアント320は、リンクをデリファレンス(間接参照)及び/又はリゾルブ(解決)して、挿入されるコンテンツの記述を取得し、更新されたMPD330に記述を含めてよい。次いで、クライアント320は、解決された記述を利用して、必要に応じて、挿入されたコンテンツを取得する。
【0026】
XLinkは、OnLoadパラメータ又はOnRequestパラメータのいずれかに従って、デリファレンス又はリゾルブされてよい。OnLoadデリファレンスでは、クライアントは、XLinkを含んだMPDがロードされた時点で、XLinkをリゾルブする。動的デリファレンスとしても知られる、OnRequestデリファレンスでは、クライアントは、該クライアントがXLinkを含んだMPDの該当部分を読み取った時点で、XLinkをリゾルブする。図3では、OnRequestデリファレンスが使用されてよい。クライアント320が更新されたMPD330を取り出すとき、XLink334のOnRequestデリファレンスがいつ発生するかは不明であってよい。XLinkのデリファレンスが早すぎる場合、挿入される区間340で再生されるべきコンテンツは、まだダウンロード不可能であり得る。XLinkのデリファレンスが遅すぎる場合、挿入される区間340で再生されるべきコンテンツは、適時に取り出され得ない。
【0027】
一実施形態において、タイミングは、主コンテンツの区間に動的に挿入される区間中のコンテンツを参照するXLinkのOnRequestデリファレンスのために指定される。より具体的には、主コンテンツを伝送する区間として、Pmが定義され得る、Pmの直後に挿入されるコンテンツが伝送される区間として、Piが定義され得る。区間Pmの有効期間(例えば、PeriodStart(Pi) - PeriodStart(Pm))として、Tが定義され得る。ストリーミングシステム300に対する最小バッファ時間として、MBTが定義され得る。一実施形態において、更新されたMPD330を取り出すようにクライアント320に指示するメッセージを含んだセグメント312fは、時間T - 2×MBTで転送される。換言すれば、XLink334は、第1主コンテンツ310の終了よりも前の、最小バッファ時間の2倍の長さの時間で、デリファレンスされ得る。
【0028】
XLinkを有したリモート要素のオンデマンドデリファレンスは、対象とする広告の挿入のために使用されてよく、ユーザに提示すべき広告コンテンツへのリアルタイムでの決定が要求され得る。DASH及びリモート区間要素を使用する広告挿入の実施形態において、デリファレンスシステムは、図4に示されるように機能し得る。図4において、DASHアクセスクライアント410は、対応するDASH MPD中でクライアント410に提供されるHTTP URLを使用して、リモート要素をデリファレンスし得る。このコンテキストにおいて、要素は、区間要素と見なされ得るが、属性@xlink:href及び@xlink:actuateを有した任意のMPD要素は、開示される技術に従ってデリファレンスされ得る。
【0029】
図4に示されるように、区間リゾルバ420、例えば、HTTPサーバは、DASHクライアント410からHTTP GETリクエスト430を受信したとき、広告決定サーバ440にコンタクトしてよい。区間リゾルバ420は、当分野で広く知られた1つ又は複数の適切な通信プロトコル、例えば、VAST(Video Ad Serving Template)及び/又はSCTE(Society of Cable Telecommunications Engineers)規格130を使用して、広告決定サーバ440に広告決定のためのリクエスト450を送信してよい。広告決定サーバ440は、広告決定結果460を区間リゾルバ420に返してよい。広告決定サーバ440は、当分野で広く知られた1つ又は複数の適切な通信プロトコル、例えば、VAST、SCTE130、及び/又はVMAP(Video Multiple Ad Playlist)を使用して、広告決定結果460を区間リゾルバ420に返してよい。区間リゾルバ420は、広告決定結果460を1つ又は複数の区間要素470へと変換してよい。次いで、区間リゾルバ420は、DASHクライアント410からの元のHTTP GETリクエスト430に応答して、区間要素470をDASHクライアント410に送信し得る。
【0030】
DASH規格は、デリファレンスの発生時には指定され得ない。ある値、例えば、@xlink:actuateの値OnLoadは、即時のデリファレンスを要求し得、一方、値OnRequestは、デリファレンスの一定期間の保留を許可し得る。この開示においてデリファレンスを説明するときには、OnRequest値が想定される。
【0031】
XLinkに対する指定は、アプリケーションが、トラバーサルを目的としてトリガされたロード後イベントにおいて、開始リソースから終了リソースにトラバーサルすることを示す。そのようなイベントの例としては、ユーザが、開始リソースの表示物をクリックするとき、又はソフトウェアモジュールが、リダイレクトに先立つカウントダウンを完了させたときであり得る。指定は、ガイダンス又はコンプライアンス規則を提供せずともよく、したがって、早ければMPDがパース(解釈)されるときに、要素をデリファレンスすることを許容し得る。この問題点は、動的なMPD及び/又はジャストインタイムなMPD更新の使用を介して克服され得る。新たなMPDをダウンロードし、MPDをパースし、MPDに含まれたリモート要素をデリファレンスするために十分な時間をDASHクライアントが有し得るので、MPDは、早期にトリガされてよい。
【0032】
動的なMPD及び/又はジャストインタイムなMPD更新の使用は、上手く定義されたタイミングモデルを提供し得る。しかしながら、そのような技術は、トラフィックのオーバヘッドを増大させ得る頻繁なMPD更新を、エンティティに要求し得る。さらに、DASHイベントが使用される場合、広告挿入の機能性を考慮して、メディアのセグメンテーションを実行する必要が生じ得る。MPDパッチイベントが使用されない場合、MPDのフェッチに起因する追加的な遅延を招き得る。MPDパッチイベントが使用される場合、MPDのフェッチに関連する遅延は発生し得ないが、MPDを生成するエンティティとメディアをセグメント化するエンティティとの間の厳格な同期が生じ得る。
【0033】
DASHに対するXLinkタイミングモデルを定義することは、上記の問題点に対処し得る。そのような定義は、元のDASH指定を実施する任意のDASHクライアントが、タイミングモデルを意識せずとも正しく動作できることを必要とし得る。また、そのような解決策は、XLinkとの互換性が保たれていることを必要とし得る。
【0034】
要素がデリファレンスされ得る最も早い時間として、要素可用性開始時間(Element Availability Start Time,EAST)が定義され得、かつMPDがパースされる時間として、MPDパース時間(MPD Parse Time,MPT)が定義され得る。一実施形態において、一般的なDASHクライアントは、EASTよりも前に要求がなされた任意の時間にリモート要素を返すことによって、EAST後の要素をデリファレンスし得る。しかしながら、この手順は、無自覚なクライアントからのリクエストの無限ループを引き起こし得る。代替的な実施形態において、HTTPステータスコード、例えば、3xx、4xx、及び/又は5xx、が、EASTよりも前になされたリクエストの任意のデリファレンスへの応答として返されてよい。無自覚なクライアントは、エラー時にMPDをリロードし得、一例として、5xxエラーコード、例えば、ゲートウェイタイムアウト発生時、無自覚なクライアントは、一旦諦めて、後にリトライし得る。そのような例において、無自覚なクライアントは、エラーを、MPDを無効にするエラーと解釈し得、したがって、新たなMPDのフェッチ及び再パースが要求され得る。一実施形態において、EASTよりも前のデリファレンスに対する繰返しのエラーに起因したMPDをリロードする試みの頻繁な発生による無限ループを回避するために、HTTPサーバは、応答を遅延させてよい。
【0035】
EASTを明示的に通知することも可能である。EASTの明示的な通知は、追加的なオプション属性、例えば、@xlink:availabilityTime、を必要とし得、これは、属性@xlink:hrefを有したすべてのDASH MPD要素に追加され得る。@xlink:availabilityTimeの意味は、@xlink:hrefで指定されたURLが@xlink:availabilityTimeで指定される時間よりも前にリゾルブされ得ないことを示す。@xlink:availabilityTimeは、PeriodStart時間に関連してよい。無自覚なクライアントは、早期のデリファレンスを試み得、そのとき、早期のデリファレンスを回避するために、サーバ側のメソッドが使用されてよい。
【0036】
XLink 1.1は、otherとして知られる、@xlink:actuateのための別の値を許容する。other値は、末尾リソースにトラバースするアプリケーションの挙動がXLink仕様によって拘束されないことを示し得る。そのような場合、アプリケーションは、リンク中の1つ又は複数の別のマークアップ表示を見つけ出して、適切な挙動を決定し得る。無自覚なクライアントは、値otherを無視し得、一方、それに気付くクライアントは、DASH仕様で指定された規則に従い得る。DASH規格は、otherの使用を許容せず、より古いMPDバリデータは、other値を使用する場合に、MPDが妥当でないことを発見する結果となり得る。一実施形態において、otherの使用を許容するために、XLinkのDASHプロファイルが修正されてよい。otherの@xlink:actuate値が@xlink: availabilityTimeと共に使用されるシステムでは、それに気付くクライアントは、EAST後に要素をデリファレンスし得、一方、無自覚なクライアントは、要求された挙動を認識し得ないので、要素を無視し得る。
【0037】
別の実施形態において、DASHクライアント認識のための要件は、プロファイル、例えば、プロファイルURI(Uniform Resource Identifier)、としてMPDで表現されてよい。クライアント認識要件が表現されたプロファイルに準拠するDASHクライアントは、開示されたタイミングモデルに従い得る。
【0038】
図5は、アダプティブストリーミングシステムにおけるデータストリーミングの方法500の一実施形態を示すフロー図である。ブロック510において、ネットワーク要素は、更新されたMPDを取り出すようにクライアントに指示するメッセージを含んだストリーミングコンテンツの第1区間を準備する。ブロック520において、ネットワーク要素は、ストリーミングコンテンツの第1区間をクライアントに転送する。ブロック530において、ネットワーク要素又はネットワーク要素に関連した構成要素は、更新されたMPDを要求するHTTP GETメッセージ又は同様のメッセージをクライアントから受信する。ブロック540において、ネットワーク要素又はネットワーク要素に関連した構成要素は、更新されたMPDをクライアントに転送する。ブロック550において、ネットワーク要素は、ストリーミングコンテンツの第2区間で再生すべき(例えば、コンテンツストリームに挿入された)広告などのコンテンツを含むリモートエンティティを指定するXLinkを含んだHTTP GETメッセージ又は同様のメッセージをクライアントから受信する。ブロック560において、第2区間で再生すべきコンテンツが広告である場合、ネットワーク要素は、広告サーバから広告決定結果を取得する。ブロック570において、ネットワーク要素は、第2区間のコンテンツをクライアントに転送する。
【0039】
以下の参照文献は、引用によって、それらの全内容が本開示に組み込まれる。ISO/IEC 23009-1:2012 Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats、ISO/IEC 23009-1:2012/Cor 1:2013、XML Linking Language (XLink) Version 1.1、W3C Recommendation 06 May 2010、Alex Giladi (ed.), Ad Insertion in DASH: Architectures and Guidelines, July 10, 2013、Giles Godart-Brown, Jeff Goldberg, Rolando Medina, Keith Millar, Advert Insertion using MPEG DASH, v1.0, May 15, 2013、及びAd Insertion in DASH, Architectures and Guidelines, May 9, 2014。
【0040】
説明したように、静的なジャストインタイムデリファレンスに対する相互運用性ポイントは、マルチ区間DASHコンテンツと、Period@xlink:href及びPeriod@xlink:actuateを含んだMPDとを前提とする。XLinkの追加を伴う、スタティックマルチ区間インターオペラビリティポイント(Interoperability Point,IOP)の拡張セットであってもよい。スタティックジャストインタイムIOPへの準拠は、値http://dashif.org/guidelines/adin/static#jitを有した@profiles属性によって通知され得る。
【0041】
コンテンツ作成に関して、マルチ区間MPD内の同一のアセットの部分を識別するために、AssetIdentifier記述子が使用されてよく、よって、記述子は、主コンテンツに対して使用され得る。より良好な追跡及び通知を可能にするために、一意に定まる識別子(ID)が異なるアセットに対して使用されてもよい。故に、挿入されたコンテンツ中のAssetIdentifier記述子を同様に使用することが推奨される。@schemeIdUriの値は、"urn:org:dashif:asset-id:2014"であってよい。@value属性記述子の値は、コンテンツに対するMovieLabs ContentID URNであってよい。アセットのすべての部分に対して同一であってもよい。好適なスキームは、EIDR(Entertainment Identifier Registry)であってよい。区間がマルチ区間アセットの最後の区間である場合、発行者は、いわゆる、一回限り自己完結(one-off self-contained)区間(例えば、広告)を追加してよく、かつAssetIdentifier@id属性の値は、UUID(Universally Unique Identifier)であってよい。後者の処置がなされない場合、繰り返される広告に対するランダムアクセスロジックは、広告のすべての繰り返しの出現を、以前の(複数の)出現の続きと見なし得る。このようにして、広告の第2の出現は、50パーセントから始まるプレイアウトバーを有し得る。AssetIdentifier記述子は、すべてのマルチ区間アセットに対して使用され得る。区間がシングル区間の意味を有する(すなわち、アセットが1つの区間に完全に含まれ、かつその連続性が今後予期されない)場合、発行者は、これらのアセットにアセット識別子を使用しなくてよい。非リモートなAdaptationSet要素を含まない区間、及びゼロ長の区間は、AssetIdentifier記述子を含まずともよい。
【0042】
連続する区間に関して、広告コンテンツは、DASH−AVC(Advanced Video Coding)/264準拠コンテンツであってよい。同一のAssetIdentifierを有する異なるアセット中のコンテンツは、コンテンツ特性(例えば、コーデック、解像度、フレームレート、ビットレート)を保存するように調整されてよい。同一の初期化セグメントを有し、かつDRM(Digital Rights Management)情報の最大共有性を有することが望まれ得る。挿入されたコンテンツは、シームレスな区間遷移を許容するように調整されてよく、例えば、コーデック、解像度、フレームレート等の変更が阻止される。さらに、挿入されたコンテンツの最低ビットレートが主コンテンツの最低ビットレートよりも高くなることはなくてよい。
【0043】
要求されるコンテンツに関して、主コンテンツがISO−BMFF OnDemandプロファイルに準拠する場合、コンテンツは1つのファイルとして格納されると見なされ得る。このコンテンツがマルチ区間として与えられている場合、区間毎のファイルを作成せずともよい。このアセットに対するすべての区間は、同一のBaseURL値と、PeriodStartに等しいメディア時間にそれぞれ対応する、異なるSegmentBase@presentationTimeOffset値とを有し得る。ファイルは、(複数の)「sidx」ボックスを含み得、かつクライアントは、インデックス情報を読み取って、SegmentBase@presentationTimeOffsetの値を考慮したセグメントオフセットを計算し得る。
【0044】
MPDは、複数のリモート区間を含んでよく、そのうちのいくつかは、デフォルトのコンテンツを有してよく、かつそのうちのいくつかは、複数の区間要素に分解されてよい。デリファレンスの後、MPDは、ゼロ長の区間及び/又はリモート区間を含み得る。Period@xlink:actuate="onRequest"である場合、挿入されたコンテンツのダウンロードに与えられる時間が不十分なことに起因する副作用が生じることがないよう、MPDの更新及びXLinkのリゾルブは、十分に早く行われ得る。主コンテンツを伝送する区間を、Pmとし、かつPmの直後に挿入されるコンテンツを伝送するリモート区間を、Piとする。区間Pmの有効期間(すなわち、PeriodStart(Pi) - PeriodStart(Pm))を、Tとする。また、MPD@minBufferTimeを、MBTとする。Piのデリファレンスは、時間T - 2×MBTで実行されなければならない。T - 1×MBTまでに応答が無い場合、クライアントは、デリファレンスの失敗と見なしてよい。
【0045】
動的なマルチ区間デリファレンスに対する相互運用性ポイントは、先に説明した静的なマルチ区間の拡張であり、コンテンツは、DASH MPD妥当性期限満了イベントに依存し、アップストリーム機器(例えば、パッケージャ)が入来キューを検出すると、MPD更新をトリガするという差異を伴う。スタティックジャストインタイムIPOへの準拠は、値http://dashif.org/guidelines/adin/dynamic#multiperiodを有した@profiles属性によって通知され得る。
【0046】
静的なデリファレンスの場合のコンテンツ作成について先に説明したガイドラインは、動的なマルチ区間デリファレンスにも適用されてよい。DASH MPD妥当性期限満了は、メディアセグメントのうちのいくつかで発生することが予期され得る。
【0047】
インバンドMPD妥当性期限満了イベントの存在は、値@schemeIdUri=" urn:mpeg:dash:event:2012"を有したAdaptationSet.InbandEventStream要素を用いて通知され得る。インバンドMPD妥当性期限満了イベントは、ビデオ中に存在し得る。これらのイベントが使用される場合、ビデオアダプテーションセットがそれらを伝送し得る。
【0048】
「emsg」ボックスは、セグメントSR1(i)が、N個のリプレゼンテーションを含んだアダプテーションセット内のリプレゼンテーションRのi番目のセグメントであるとすると、SR0(i)が「emsg」ボックスを含む場合、同一の「emsg」ボックスがセグメントSR2(i)…SRN(i)で伝送されるよう、調整され得る。これは、選択されたリプレゼンテーションに関わらず、アダプテーションセットに基づくメディアが再生される場合に、すべての「emsg」ボックスが読み取られ得ることを意味する。最大で1つの「emsg」ボックスがセグメントに提示され得る。いくつかの「emsg」ボックスがセグメントに提示され得る場合、「emsg」は、最初に現れ得る。
【0049】
タイミングの挙動に関して、主コンテンツを伝送する区間を、Pmとし、かつその直後に挿入されたコンテンツを伝送する区間を、Piとする。区間Pmの有効期間(すなわち、PeriodStart(Pi) - PeriodStart(Pm))を、Tとする。また、MPD@minBufferTimeを、MBTとする。区間Piに追加される、MPD更新をトリガするMPD妥当性期限満了イベントを伝送する「emsg」は、イベント区間時間(Event Period Time,EPT)≦T - 2×MBTのセグメントで伝送されなければならない。
【0050】
動的なジャストインタイムデリファレンスのための相互運用性ポイントは、ダイナミックマルチ区間IOPとスタティックジャストインタイムIOPとの組合せであり得る。MPDは、リモート区間要素を含んでよく(例えば、Period@xlink:href及びPeriod@xlink:actuateが提示されてよく)、MPDの更新は、MPD妥当性期限満了イベントによってトリガされてよい。ダイナミックジャストインタイムIOPへの準拠は、値"http://dashif.org/guidelines/adin/dynamic#jit"を有した@profiles属性によって通知されてよい。
【0051】
静的なデリファレンスの場合及び動的なマルチ区間デリファレンスの場合のコンテンツ作成のための上記のガイドラインは、動的なジャストインタイムデリファレンスにも適用され得る。(a)MPDの更新の要求及び受信と、(b)来たるリモート区間のデリファレンスとを行うために十分な時間がクライアントに与えられるよう、配慮が必要となり得る。
【0052】
Period@xlink:actuate="onRequest"である場合、続いてのデリファレンス、すなわち、PeriodStartよりも最大で2×MBT秒前に実行される場合の、第1結果の区間は、(例えば、デリファレンスの余剰回を必要としない)妥当な区間となり得る。リモート要素入力が2以上の区間要素を含む場合、それらは、リモート要素となってよい。
【0053】
少なくとも1つの実施形態が開示されたが、当技術分野における通常の知識を有する者によってなされる、(複数の)実施形態及び/又は(複数の)実施形態の特徴の変形例、組合せ例、及び/又は修正例は、本開示の範囲内にある。また、(複数の)実施形態の特徴の組合せ、一体化、及び/又は省略の結果として生じる代替形態は、本開示の範囲内にある。数値的な範囲又は限界が明確に指定される場合、そのように明示された範囲又は限界は、明確に指定された範囲又は限界内にある類似した振れ幅の反復範囲又は限界を含む(例えば、「約1から約10」は、2、3、4、…を含み、「0.10を超える」は、0.11、0.12、0.13、…を含む)ということを理解されたい。例えば、下限Rと上限Rと有する数値範囲が開示され、範囲内にある任意の数が具体的に開示される。詳細には、範囲内の以下の数が具体的に開示される。すなわち、R=R+k*(R−R)であり、ここで、kは、1パーセントの増分で1パーセントから100パーセントまでの範囲にある変数であり、例えば、kは、1パーセント、2パーセント、3パーセント、4パーセント、7パーセント、…、70パーセント、71パーセント、72パーセント、…、97パーセント、96パーセント、97パーセント、98パーセント、99パーセント、又は100パーセントである。さらにまた、上記で定義されたような2つの数Rによって定義される数値範囲が具体的に開示される。語「約(about)」の使用は、特に指定しない限り、その後に続く数の10%前後を意味する。特許請求の範囲の任意の要素に関連した、語「選択的に(optionally)」の使用は、当該要素が必要とされること、又は当該要素が必要とされないことを意味し、それら両方の代替例は、特許請求の範囲内にある。「備える、含む、有する(comprise,include,having)」などのより広い意味を有する語の使用は、「からなる、から本質的になる、から実質的になる(consisting of,consisting essentially of,comprised substantially of)」などのより狭い意味を有する語を包含するものと理解されたい。したがって、保護範囲は、以上の詳細な記載によって限定されるのではなく、添付された特許請求の範囲によって定義され、その範囲には、特許請求の範囲の対象物のすべての均等物が含まれる。本開示における参照文献の説明は、それが従来技術であることを認めるものではなく、特に、この出願の優先日よりも後の公開日を有する任意の参照文献も含む。本開示で引用したすべての特許、特許出願、及び刊行物の開示内容は、引用によって、それらが提供する例、手順、又はその他の補足的な詳細の範囲が本明細書に組み込まれる。
【0054】
いくつかの実施形態が本開示において提供されたが、開示されたシステム及び方法は、本開示の精神又は範囲から逸脱することなく、他の多くの特定の形態で実施されてよい、ということを理解されたい。本例は、限定ではなく、例示と見なされるべきものであり、その意図は、本開示で与えられた細部に限定することではない。例えば、さまざまな要素又は構成要素は、別のシステムに組み合わせられるか又は一体化されてよく、又は、ある特徴は、省略されるか又は実装されなくてよい。
【0055】
さらに、さまざまな実施形態において個別に又は分離したものとして説明され、示された技術、システム、及び方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、又は方法に組み合わせられるか又は一体化されてよい。互いが接続される、直接的に接続される、又は通信するものとして示されたか又は説明された他の項目は、それが電気的、機械的、又はその他の態様であるか否かに関わらず、何らかのインタフェース、デバイス、又は中間構成要素を介して、間接的に接続されるか又は通信してよい。その他の変更例、代用例、及び置換例は、当業者によって認識可能であり、本開示の精神及び範囲から逸脱することなく実施され得る。
【符号の説明】
【0056】
100 アダプティブストリーミングビデオコンテンツ配信システム
110 サーバ
120 クライアント
130 メディアプレゼンテーション記述(MPD)
140,141 セグメント
150,151 アダプテーションセット
160,161 リプレゼンテーション
200 ネットワーク要素(NE)
210 トランシーバ(Tx/Rx)
220 ダウンストリームポート
230 プロセッサ
232 メモリ
234 MPDモジュール
250 アップストリームポート
300 ストリーミングシステム
310 第1主コンテンツ区間
312a,312b,312c,312d,312e コンテンツ
312f メッセージ
320 クライアント
330 更新されたMPD
332 挿入された区間の記述
334 挿入されたコンテンツへのXLink
340 挿入された区間
350 第2主コンテンツ区間
352a,352b,352c,352d,352e コンテンツ
352f メッセージ
410 DASHアクセスクライアント
420 区間リゾルバ
430 HTTP GETリクエスト
440 広告決定サーバ
450 広告決定リクエスト
460 広告決定
470 (複数の)区間要素
図1
図2
図3
図4
図5
【国際調査報告】