(57)【特許請求の範囲】
【請求項１】
文書(y.mpd)からの少なくとも第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)を介してアクセス可能な、少なくとも1つのデータセグメント(0.mpv4v, 180180.mp4v)を含むマルチメディアコンテンツ(y)を記述する前記文書(y.mpd)を生成する方法であって、少なくとも1つのユニバーサルアドレスジェネレータルール(URLParameterTemplate)を前記文書(y.mpd)に書き込む、少なくとも1つのステップを含み、前記ジェネレータルールが、
前記第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)と、
前記コンテンツを記述する前記文書(y.mpd)のユニバーサルアドレス(HTTP://x.com/y.mp4v?s=abd)に関連付けられる、少なくとも1つのパラメータ(s=abd)とから、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/0.mp4v?s=abd)を生成することに適していることを特徴とする方法。
【請求項２】
前記ユニバーサルアドレスジェネレータルール(URLParameterTemplate)が、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/1.mp4v?s=abd)を生成するために考慮される必要がある、取得された前記パラメータ(署名)を指定することを特徴とする、請求項1に記載の記述文書(y.mpd)を生成する方法。
【請求項３】
前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/1.mp4v?s=abd)を生成するために、前記アドレスジェネレータルールが、取得されたパラメータが考慮される必要がある順序を示すことを特徴とする、請求項1に記載の記述文書(y.mpd)を生成する方法。
【請求項４】
コンテンツを記述する文書(y.mpd)を介してアクセス可能な、少なくとも1つのデータセグメント(0.mp4v, 180180.mp4v)を含むマルチメディアコンテンツ(y)にアクセスする方法であって、前記セグメントへの前記アクセスが、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/y1.mp4v?s=abd)を介して行われ、前記アクセス方法が、
前記コンテンツを記述する前記文書(y.mpd)を取得して、その文書から、セグメントの少なくとも第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)が生成される(E2)ステップ(E1、E11)と、
前記コンテンツを記述する前記文書(y.mpd)のユニバーサルアドレス(HTTP://x.com/y.mpd?s=abd)に関連付けられる、少なくとも1つのパラメータ(s=abd)を取得するステップと、
前記コンテンツを記述する前記文書(y.mpd)内の少なくとも1つのアドレスジェネレータルール(URLParameterTemplate)を読み出すステップと、
前記アドレスジェネレータルール(URLParameterTemplate)、前記セグメントの第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)、および取得された前記パラメータ(s=abd)に応じて、前記セグメントの前記第2のユニバーサルアドレス(HTTP://x.com/video/y1.mp4v?s=abd)を生成するステップ(E3)とを備えることを特徴とする方法。
【請求項５】
文書(y.mpd)からの少なくとも第1のユニバーサルアドレス(HTTP://x.com/video/1.mp4v)を介してアクセス可能な、少なくとも1つのデータセグメント(0.mp4v, 180180.mp4v)を含むマルチメディアコンテンツ(y)を記述する文書(y.mpd)を生成することに適したマルチメディアコンテンツサーバであって、少なくとも1つのユニバーサルアドレスジェネレータルール(URLParameterTemplate)を前記文書(y.mpd)に書き込むためのモジュールを含み、前記ジェネレータルールが、前記第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)、および前記コンテンツを記述する前記文書(y.mpd)のユニバーサルアドレス(HTTP://x.com/y.mpd?s=abd)に関連付けられる、少なくとも1つのパラメータ(s=abd)に基づいて、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/0.mp4v?s=abd)を生成することに適している、マルチメディアコンテンツサーバ。
【請求項６】
コンテンツを記述する文書(y.mpd)を介してアクセス可能な、少なくとも1つのデータセグメント(0.mp4v, 180180.mp4v)を含むマルチメディアコンテンツ(y)にアクセスすることに適した端末であって、前記アクセスが、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/y1.mp4v?s=abd)を介して行われ、前記端末が、
前記コンテンツを記述する前記文書(y.mpd)を取得するためのモジュールであって、その文書から、セグメントの少なくとも第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)が生成されるモジュールと、
前記コンテンツを記述する前記文書(y.mpd)のユニバーサルアドレス(HTTP://x.com/y.mp4v?s=abd)に関連付けられる、少なくとも1つのパラメータ(s=abd)を取得するためのモジュールと、
前記コンテンツを記述する前記文書(y.mpd)内の少なくとも1つのアドレスジェネレータルール(URLParameterTemplate)を読み出すためのモジュールと、
前記アドレスジェネレータルール(URLParameterTemplate)、前記セグメントの前記第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)、および取得された前記パラメータ(s=abd)に応じて、前記セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/y1.mp4v?s=abd)を生成するためのモジュールとを備えることを特徴とする、端末。
【請求項７】
プロセッサによってプログラムが実行されると、請求項1に記載のマルチメディアコンテンツを記述する文書を生成する方法を実行するためのコード命令を含む、コンピュータプログラム。
【請求項８】
プロセッサによってプログラムが実行されると、請求項4に記載のマルチメディアコンテンツにアクセスする方法を実行するためのコード命令を含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアコンテンツ通信に関する。
【０００２】
「マルチメディアコンテンツ」という用語は、任意のオーディオまたはビデオコンテンツ、あるいは、より一般的には、他の任意のデジタルコンテンツを意味するために使用される。
【０００３】
より具体的には、本発明は、ネットワークを介してマルチメディアコンテンツを送受信すること、特に、ネットワークを介してマルチメディアコンテンツを継続的にダウンロードすることに関し、これは「ストリーミング」としても知られている。
【０００４】
より具体的には、本発明は、コンテンツのユニバーサルアドレスを使用する通信に関する。
【０００５】
具体的には、本発明は、ユニバーサルリソース識別子(URI)としても知られるユニバーサルアドレスを用いてマルチメディアコンテンツにアクセスするために、遠隔通信ネットワークを介して通信することができる、任意のクライアント端末(以下では単に「端末」と呼ばれる)に適用される。
【背景技術】
【０００６】
マルチメディアコンテンツにアクセスするために、一般的に、クライアント端末はユニバーサルアドレスまたはURIを用いる。そのようなアドレスは、コンテンツへのアクセスと、それを消費するための関連プロトコルについての表示とを提供する(例として、コンテンツがビデオコンテンツである場合、「消費する(consuming)」という用語は「閲覧する(viewing)」を意味するために使用される)。URIは、物理的または抽象的資源を識別する文字列であり、インターネットエンジニアリングタスクフォース(IETF)によって発行された標準のセットの構文、具体的には、その標準RFC3986(標準:ユニバーサルリソース識別子(URI):共通構文)に準拠している。そのようなユニバーサルアドレスは、たとえば、以下の形式dvb://content1、rtsp://content2、HTTP://content3、ftp://content4、等を有してよい。
【０００７】
マルチメディアコンテンツへのアクセスは、直接でもよく(単一のURIを使用して、単一の要求によってトリガされる)、間接でもよく、その場合は、URIが、第2の要求を介してサービスにアクセスすることを可能にするパラメータを提供する。従来の例は、ビデオオンデマンドサービスである。第1のステップは、端末が、ハイパーテキスト転送プロトコル(HTTP)、すなわち、インターネットネットワーク、特にウェブのために開発されたクライアント-サーバ通信プロトコルを使用することによって、サービスにアクセスするためのパラメータを記述する文書(セッション記述プロトコル(SDP))をダウンロードすることで構成され、第2のステップでは、サービスが実際に開始し、すなわち、クライアント端末が、文書(この例では、SDP)内で提供された情報を使用することによって、ビデオを受信して表示することができる。文書は、コンピュータファイルでもよく、特定のアドレスでアクセス可能なコンテンツを記述するデータセットでもよい点に注意されたい。以下で、文脈に応じて、「記述ファイル(description file)」または「文書(document)」という用語が使用されている。サービスへのこのタイプのアクセスは、サーバの存在を必要としてもよく(具体的には、ポイントツーポイント、または「ユニキャスト」通信のために)、サーバの存在を必要としなくてもよい(「ブロードキャスト」または「マルチキャスト」タイプのポイントツーマルチポイント通信のために)点に注意されたい。具体的には、HTTPプロトコルは、ポイントツーポイント(または「ユニキャスト」)タイプのプロトコルであり、その結果、「HTTPクライアント」と呼ばれるクライアントの要求を処理するために、サーバが存在することを含意する。
【０００８】
HTTPプロトコルの文脈では、クライアントとサーバとの間でデータを交換するために、「アダプティブストリーミング」タイプの技法を用いるのが一般的である。このタイプの技法によって、具体的には、たとえばクライアント端末とコンテンツサーバとの間の接続を介して利用可能な帯域幅の変動を考慮しながら、良好なユーザ体験を提供することが可能になる。従来は、たとえば異なるデータレートに対応する同じビデオについて、様々な品質が符号化され得る。各データレートは、それ自体が時間セグメント(コンテンツ「フラグメント」として知られる)にさらに分割される。これらの様々なデータレートの記述、セグメント化の記述、およびコンテンツフラグメントの記述が、サービスプラットフォームによってクライアント端末にとって利用可能になる。したがって、完全なコンテンツにアクセスするために、複数のセグメントに対応する多数のURIアドレスを知ることが必要である。
【０００９】
ストリーミングにおけるそのようなコンテンツの配信を容易にするために、たとえば、Microsoft Smooth Streaming、Apple HLS、Adobe Http Dynamic Streaming、あるいはMPEG DASH標準等の独自の解決策などのいくつかの解決策があり、それを以下で説明する。これらの方法は、1つまたは複数の中間記述ファイルをクライアントに送信することを提案し、そのファイルは文書、マニフェスト、または実際に資源と呼ばれる場合もあり、それらはマルチメディアコンテンツの異なる品質への様々なセグメントのアドレスを含む。
【００１０】
例として、MPEG DASH(dynamic adaptive streaming over httpの略、ISO/IEC標準2309-1:2012(E))は、インターネットを介するストリーミングマルチメディアコンテンツ専用のISO/IEC標準化団体からの標準である。それは、具体的には、ネットワークに接続された周辺機器(テレビ、タブレット等)が、HTTPプロトコルを使用してマルチメディアコンテンツを消費することを可能にする。MPEG DASH標準に準拠し、サーバに送信される、クライアントからのHTTP要求は、たとえばユニバーサルリソースロケータ(URL)タイプのユニバーサルアドレスまたはURIを含み、URLは、インターネットネットワークを介してマルチメディアコンテンツへのアクセスを与えるURIの特定の例である。したがって、MPEG DASHの場合、コンテンツへのアクセスは、従来2つの段階で行われる。
【００１１】
1) 一般的に、メディアプレゼンテーション記述(MPD)として知られる、マルチメディアコンテンツのメディアセグメントのアドレスを特に含むファイルをダウンロードすることによって、記述文書を取得する。このダウンローディングは、従来はHTTP URLを使用して行われるが、他の何らかのプロトコルを記述するユニバーサルアドレス(URI)(たとえば、ftp://mydescriptionfile)を使用して行うこともできる。
【００１２】
2) 一般的に、記述文書内のコンテンツアドレスを使用してダウンロードすることによって、メディアセグメントを取得する。このダウンローディングは、従来はHTTP URLを介して行われるが、他の何らかのプロトコルを記述するユニバーサルアドレス(URI)(たとえば、dvb://mycontentsegment)を介して行うこともできる。
【００１３】
ある状況では、コンテンツは特定の制約を受ける場合がある。たとえば、コンテンツへのアクセスを保護することができ、この保護は端末が識別されていると仮定し、そのような識別はユーザに応じて当然変化し、ユーザの権利がチェックされたと仮定し、その権利は継時的にさらに変化し得る。ユーザの権利の識別およびチェックは、従来はサービスプラットフォームによって実行され、以下でURIパラメータと呼ばれる、URIユニバーサルアドレスに関連付けられる1つまたは複数のパラメータによって、結果が配信サーバに送信される。
【００１４】
これらの特定のパラメータを、記述ファイル内に記述されたすべてのコンテンツ要求の中の、端末からのデマンドと関連付けるために、そのような環境下で、システムが、端末からのデマンドと同じ数の文書または記述ファイルを生成することが必要であり、それは複雑であり、サービスプラットフォームまたは配信サーバに負担をかける。
【００１５】
本発明は、従来技術の欠点を示さない解決策を提供する。
【先行技術文献】
【非特許文献】
【００１６】
【非特許文献１】RFC3986
【非特許文献２】ISO/IEC標準2309-1:2012(E)
【非特許文献３】IETF RFC 4566
【発明の概要】
【課題を解決するための手段】
【００１７】
この目的のために、機能面では、本発明は、前記文書からの少なくとも第1のユニバーサルアドレスを介してアクセス可能な、少なくとも1つのデータセグメントを含むマルチメディアコンテンツを記述する文書を生成する方法を提供し、文書を生成する前記方法は、少なくとも1つのユニバーサルアドレスジェネレータルールを文書に書き込む、少なくとも1つのステップを含み、
前記ジェネレータルールが、第1のユニバーサルアドレスと、コンテンツを記述する文書のユニバーサルアドレスに関連付けられる、少なくとも1つのパラメータとから、セグメントの第2のユニバーサルアドレスを生成することに適していることを特徴とする。
【００１８】
したがって、本発明では、マルチメディアコンテンツのセグメントの第2のアドレスまたは最終アドレスに、1つまたは複数のパーソナライズされたパラメータを導入するための準備をすることが可能である。生成されたセグメントアドレスは、セグメントの第1のアドレスよりも完全であり、具体的には、生成されたセグメントアドレスは、クライアントごとに特定の記述文書を生成することによってのみパーソナライズすることができる従来技術の第1のアドレスとは異なり、マルチメディアコンテンツを要求したクライアントに関連付けられるパラメータを含み得る。
【００１９】
記述文書のユニバーサルアドレスに関連付けられるパラメータ(URIパラメータ)は、一般的に、当然各クライアントに固有の認証パラメータである。したがって、本発明は、すべてのクライアントのためのコンテンツについての単一の記述文書(マニフェスト、記述ファイル等)の生成と、同時に、記述文書のアドレスに非常に簡単に関連付けられるパラメータで、コンテンツセグメントのアドレスをパーソナライズすることとを可能にする利点を提供する。
【００２０】
本発明の特定の実装形態では、上述のように記述文書を生成する方法は、ユニバーサルアドレスジェネレータルールが、セグメントの第2のユニバーサルアドレスを生成するために考慮される必要がある、取得されたパラメータを指定することも特徴とする。
【００２１】
したがって、この実装形態では、セグメントの第2のアドレスまたは最終アドレスを生成する際に考慮されるべきユニバーサルアドレスパラメータを明示的に名付けることが可能である。一般的に、これは、署名、日付等の、セグメントの最終アドレスに挿入されるべき、または渡されるべき、URIパラメータを指定する記述文書を含む。したがって、特定のURLパラメータを優先すること、または他の特定のパラメータを考慮しないことを決定することが可能である。
【００２２】
本発明の第2の特定の実装形態では、それを上記の実装形態の代わりに、またはそれとともに、実装することができ、上述の方法は、アドレスジェネレータルールが、セグメントの第2のユニバーサルアドレスを生成するために、取得されたパラメータが考慮される必要がある順序を示すこともさらに特徴とする。
【００２３】
本発明のこの実装形態によって、セグメントの最終アドレスを生成するために考慮されるべきURLパラメータを自動的かつ暗黙的に考慮することが可能になる。ジェネレータルールで指定された順序は、たとえば、サーバの観点から見たパラメータの重要性の順序でよい。本発明によれば、これはある機械から別の機械で変えられてもよい。なぜなら、そのような状況下では記述ファイルのコンテンツ(ルール)を変更すれば十分であるからである。
【００２４】
別の機能面では、本発明は、コンテンツを記述する文書を介してアクセス可能な、少なくとも1つのデータセグメントを含むマルチメディアコンテンツにアクセスする方法を提供し、セグメントへの前記アクセスは、セグメントの第2のユニバーサルアドレスを介して行われ、前記アクセス方法は、
コンテンツを記述する文書を取得して、その文書から、セグメントの少なくとも第1のユニバーサルアドレスが生成されるステップと、
コンテンツを記述する文書のユニバーサルアドレスに関連付けられる、少なくとも1つのパラメータを取得するステップと、
コンテンツを記述する文書内の少なくとも1つのアドレスジェネレータルールを読み出すステップと、
アドレスジェネレータルール、セグメントのユニバーサルアドレス、および取得されたパラメータに応じて、セグメントの第2のユニバーサルアドレスを生成するステップとを備えることを特徴とする。
【００２５】
記述文書と、記述文書のユニバーサルアドレスに関連付けられるパラメータとがわかっているので、クライアントは、消費されるべきマルチメディアコンテンツセグメントのアドレス内にそれらのパラメータのうちの1つまたは複数を含むために、ルールを適用することができる。したがって、セグメントのために生成された第2のアドレス、または最終アドレスは、第1のアドレスよりも完全であり、具体的には、クライアントに関連付けられるパラメータ、一般的には当然クライアントに固有の認証パラメータを導入することによって、コンテンツのセグメントへのアクセスをパーソナライズすることを可能にする。したがって、文書のアドレスで簡単に渡されるパラメータに応じてコンテンツセグメントのアドレスをパーソナライズすることが可能なので、本発明は、すべてのクライアントに単一の文書(マニフェスト、記述ファイル等)を提案するという利点を提供する。
【００２６】
また、物質面では、本発明は、前記文書からの第1のユニバーサルアドレスを介してアクセス可能な、少なくとも1つのデータセグメントを含むマルチメディアコンテンツを記述する文書を生成することに適したマルチメディアコンテンツサーバを提供し、前記コンテンツサーバは、少なくとも1つのユニバーサルアドレスジェネレータルールを文書に書き込むためのモジュールを含み、前記ジェネレータルールが、第1のユニバーサルアドレス、ユニバーサルアドレスジェネレータルール、およびコンテンツを記述する文書のユニバーサルアドレスに関連付けられる、少なくとも1つのパラメータに基づいて、セグメントの第2のユニバーサルアドレスを生成することに適している。
【００２７】
また、別の物質面では、本発明は、コンテンツを記述する文書を介してアクセス可能な、少なくとも1つのデータセグメントを含むマルチメディアコンテンツにアクセスすることに適した端末を提供し、前記アクセスは、セグメントの第2のユニバーサルアドレスを介して行われ、前記端末は、
コンテンツを記述する文書を取得するためのモジュールであって、その文書から、セグメントの少なくとも第1のユニバーサルアドレスが生成されるモジュールと、
コンテンツを記述する文書のユニバーサルアドレスに関連付けられる、少なくとも1つのパラメータを取得するためのモジュールと、
コンテンツを記述する文書内の少なくとも1つのアドレスジェネレータルールを読み出すためのモジュールと、
アドレスジェネレータルール、セグメントの第1のユニバーサルアドレス、および取得されたパラメータに応じて、セグメントの第2のユニバーサルアドレスを生成するためのモジュールとを備えることを特徴とする。
【００２８】
別の物質面では、本発明は、プロセッサによってプログラムが実行されると、上述のように、マルチメディアコンテンツを記述する文書を生成する方法を実行するためのコード命令を含む、コンピュータプログラムを提供する。
【００２９】
別の物質面では、本発明は、プロセッサによってプログラムが実行されると、上述のように、マルチメディアコンテンツにアクセスする方法を実行するためのコード命令を含む、コンピュータプログラムも提供する。
【００３０】
本発明の物質面は、機能面の方法によってもたらされる利点と少なくとも同じ利点を提供する。
【００３１】
本発明は、添付の図面を参照して、例として与えられる以下の説明を読めば、より良く理解することができる。
【図面の簡単な説明】
【００３２】
【図１】従来技術における、インターネットを介してHTTPプロトコルを使用することに基づく、ストリーミングアーキテクチャを示す図である。
【図２】本発明の実装形態における、インターネットを介してHTTPプロトコルを使用することに基づく、ストリーミングアーキテクチャを示す図である。
【図３】本発明の実装形態におけるタイミング図である。
【図４】本発明の実装形態の変形を示す図である。
【発明を実施するための形態】
【００３３】
図1は、従来技術における、インターネットタイプのネットワークを介してHTTPプロトコルを使用することに基づく、ストリーミングアーキテクチャを示している。従来、クライアント端末(1)は、1つまたは複数の媒体(オーディオ、ビデオ等)で構成されたマルチメディアコンテンツをダウンロードするために、コンテンツサーバ(8)との通信に入ろうとする。
【００３４】
以下の例では、上記で説明したように、関連するストリーミングコンテキストは、MPEG DASH標準を使用する。
【００３５】
端末(1)は、マルチメディアコンテンツ記述文書(y)のアドレス(ここではURLであるが、より一般的には、URIタイプのユニバーサルアドレス)を取得するために、サービスプラットフォーム(3)に問い合わせることによって開始する。以下では、この文書はMPDタイプのファイル(y.mpd)である。
【００３６】
サービスプラットフォーム(3)は、端末にMPDファイルのアドレスを提供することによって応答し、この例では、これは、サイト「x.com」からダウンロード(またはストリーミング)することができるMPDタイプのファイルyを表す、URL「HTTP://x.com/y.mpd」である。
【００３７】
サービスプラットフォーム(3)は、クライアントが使用するために、一定数のパラメータをURIに追加することができる。URIの共通構文を記述するIETF標準RFC3986によれば、これらのパラメータは「?」記号によって導入される。パラメータをURIに挿入するための、この機構についてのさらなる詳細については、当業者はRFC3986を参照するべきである。たとえば、認証に関連付けられる配信コンテンツの文脈において、サービスプラットフォームは、URIに認証トークンを追加することができ、この例では、トークンは文字列「s=abd」によって表され、コンテンツ配信プラットフォームによって使用される、クライアントについての認証パラメータである。したがって、記述ファイルを求める要求に応じて、クライアントは、
・ファイル自体のユニバーサルアドレス(HTTP://x.com/y.mpd)と、
・認証パラメータ(abd)と
を備える、URL「HTTP://x.com/y.mpd?s=abd」を受信する。
【００３８】
このURIに基づいて、コンテンツサーバ(8)から記述文書(4)をダウンロードすることができ、パラメータabdは、サーバがクライアントを認証することを可能にする。
【００３９】
MPEG/DASH標準に準拠するMPDファイルの例を以下に記載する。具体的には、第1のユニバーサルアドレスを生成するために役立つ、本発明の文脈における適切なフィールドは、イタリック体で示されている。
【００４０】
【表１】
0006277194.tif 000002
【００４１】
MPDファイルは、本明細書では「第1の」ユニバーサルアドレスと呼ばれるマルチメディアコンテンツアドレスを、それらを本発明の文脈において生成された、本明細書では「第2の」ユニバーサルアドレスと呼ばれるアドレスと区別するために生成することを可能にする。第1のアドレスは、MPEG/DASH標準の従来技術に従って、
・直接的に(セグメントのURLがファイル内で直接指定される)、または、
・メディアセグメントURL構築するための処理を介して間接的に、
のいずれかで生成することができる。
【００４２】
この構築は、上述のRFC3986に記載されるユニバーサルアドレス(URI)を解決する前に、機構を使用する。クライアント端末は、メディアセグメントの第1のユニバーサルアドレス(URLまたはURI)を構築するために、特定のフィールドを解釈して、それらを適切に修正しなければならない。
【００４３】
URIのこの解決は、MPDの階層において様々なレベルに存在し得る、要素BaseURLを使用して実行される。
【００４４】
この例では、URLは、「BaseURL」(「HTTP://x.com/」および「video/」)と「SegmentTemplate」の2つのフィールドを用いて構築される。
【００４５】
MPEG/DASH標準によって指定される「SegmentTemplate」は、様々な識別子に基づいて中間URIアドレスを構築するための共通方法であり、この例では、以下の通りである:
・$時間$:メディアセグメントの開始時に、時間によって置換される。この時間は、この例では新しいセグメントの開始ごとに180180のオフセットを指定する、「SegmentTemplate」回線によって提供される。
・$数$:所望のメディアセグメントの順序番号によって置換される。および、
・$帯域幅$:ターゲットにされた表示の「帯域幅」属性の値によって置換される。
【００４６】
したがって、この例では500キロビット/秒(kbps)の品質(または、データレート)の最初の2つのビデオセグメントへのアクセスを与える最初の2つのURLは、以下の通りである:
1.HTTP://x.com/video500000/0.mp4v、および、
2.HTTP://x.com/video500000/180180.mp4v。
【００４７】
したがって、現在、MPEG DASHは、一定数のパラメータを含む、メディアセグメントの第1のアドレス(URLまたはURI)が生成されることを可能にする機構を提案する。この機構は、URLパラメータが、コンテンツにアクセスしようとするすべてのクライアントに共通である限り、十分である。一方、クライアントに応じてこれらのパラメータをパーソナライズする(従来は、アクセスまたは権利を認証してチェックするために)ことが所望される場合、唯一の解決策は、各クライアントに固有のMPD記述ファイルを生成することである。その方法は、クライアントごとにオンザフライで記述文書を構築することを必要とするので、コストが高い(コンテンツ配信プラットフォーム上の時間および資源に関して)。
【００４８】
それが、本発明が、本明細書では第1のユニバーサルアドレスから区別するために第2のユニバーサルアドレスと呼ばれる、および、たとえばクライアント端末に関連し得る一定数のパラメータを含み得る、セグメントアドレス(URI)を自動的に生成することを提案する理由である。この例では、MPDファイルのURLのパラメータ(s=abd)として指定されるセキュリティパラメータが、セグメントの第2のアドレスを生成する際に導入されるか、渡される。したがって、従来技術を使用して生成することができる第1のアドレスに加えて、これらの第2のアドレスは、パーソナライズされたセキュリティパラメータを含む。言い換えれば、第2のセグメントアドレスは、たとえそれらが単一のMPD記述ファイルから生成されていても、各クライアント端末に適合される。
【００４９】
当然、コンテンツを要求する際、およびコンテンツ要求に関連付けられるセグメント(たとえば、オーディオセグメント)が1つしかなく、したがって記述ファイルを介する間接性がない時に、URLパラメータ(上述のトークンなど)を渡すことがすでに知られている。しかしながら、コンテンツが記述ファイルを介してのみアクセス可能である場合、現在、要求ごとに特定のファイルを生成すること以外に、パラメータをそれぞれのセグメントに渡すためのどのような解決策も存在しない。
【００５０】
図2は、本発明によるストリーミングシステムの原理を示している。
【００５１】
サービスプラットフォーム(3)から記述ファイル(y.mpd)のユニバーサルアドレスを要求して受信する第1のステップと、コンテンツプラットフォーム(8)から記述ファイル自体を要求して受信するステップは、図1を参照して記述されるものと同一である。
【００５２】
それにもかかわらず、後続のステップの間、本発明は、記述ファイルのURLアドレスに関連付けられるパラメータ(ここでは、以前サービスプラットフォームによってURLパラメータとして送信されたトークン「s=abd」)が、クライアントによって、図3を参照してより詳細に記載される方法を使用して、メディアセグメントを求める各要求に挿入されることを可能にする。
【００５３】
したがって、この例では、500kbpsの品質の最初の2つのビデオセグメントにアクセスするための最初の2つのURLは以下のようになる:
1. HTTP://x.com/video500000/0.mp4v?s=abd; and
2. HTTP://x.com/video500000/180180.mp4v?s=abd.
【００５４】
したがって、図1を参照して記述した従来技術と比較して、本発明の2つの利点が明らかにわかる:
・この新しい方法を用いて、サーバが、各メディアセグメントを検証するために、URL内にあるトークンを使用することが可能である。各メディアセグメントのトークンが有効である場合、サーバは、実際にメディアセグメントを配信する。各メディアセグメントのトークンが有効ではない場合、ダウンロードが失敗する。したがって、機構は過去に比べてより安全である。
・さらに、各クライアントは、クライアントが事前に記述ファイルのURL内で受信したパラメータを渡すことによって、コンテンツの様々なセグメントへのアクセスをパーソナライズすることができるので、もはやクライアントごとに記述ファイル(y.mpd)を生成する必要がない。
【００５５】
図3は、本発明の機構の様々なステップを示すタイミング図の形式である。
【００５６】
図3は、以下で修正されるように、ファイルy.MPDの交換および使用に基づいている(イタリック体で示されるフィールドは、本発明による新しいフィールドである)。
【００５７】
新しいフィールドURLParametersは、本発明の継承機構がアクティブであることを指定する。当然、他の変形が可能である。具体的には、このフィールドはオプションであると考えることができ、その存在または不在が、クライアント端末上にあるXMLファイルの存在の解析モジュールによってテストされる。不在である場合、デフォルトで、それをパラメータに関連付けることができる。
【００５８】
新しいフィールドURLParameterTemplateは、生成されるべき(URL、URI)メディアセグメントアドレスにパラメータを渡すために役立つ。フィールドURLParameterTemplateは、具体的には、各メディアセグメントにおいて、ファイルのどのフィールドが再使用されるべきかを指定する。この例では、「トークン」フィールドだけが再使用されるべきであるが、より多数のパラメータを再使用することを想定することも当然可能である。このフィールドはオプションであると考えることができ、その存在または不在が、クライアント端末上にあるXMLファイルの存在の解析モジュールによってテストされる。不在である場合、同様に、デフォルトでそれをパラメータに関連付けることができる。
【００５９】
ステップE1の間、端末1が、記述ファイルy.mpdを要求し、そのファイルは、ステップE10の間に、コンテンツサーバ(8)によってそこに送信される。
【００６０】
ステップE2の間、端末1が、コンテンツセグメントの第1のユニバーサルアドレス(HTTP://x.com/video/0.mp4v)を生成する。
【００６１】
ステップE3の間、端末1が、記述ファイルアドレスのパラメータとしてそこに送信された認証パラメータ「s=abd」を、記述ファイル内で読まれる(URLParameterTemplate)ルールに準拠するセグメントの第2のアドレスに挿入することによって、セグメントの第2のユニバーサルアドレス(HTTP://x.com/video/0.mp4v?s=abd)を生成する。
【００６２】
ステップE4の間、端末1が、サーバが認証パラメータ(s=abd)を検証した後、ステップE12の間にコンテンツサーバによってそこに送信されたセグメントを要求するために、この第2のユニバーサルアドレスを使用する。次いで、端末1は、オプションのステップE5の間にコンテンツを消費することができる。
【００６３】
テストステップE6は、端末1が、処理するためのコンテンツセグメントが残っている限り、別のコンテンツセグメントについてE3〜E5を繰り返すことを可能にする。
【００６４】
【表２】
0006277194.tif 000003
【００６５】
この第1の例では、セグメントの第2のユニバーサルアドレスを生成するために渡される必要があるパラメータが、ルールにおいて明示的に言及される。「署名」パラメータを渡すために、ファイルに構文例が与えられる:
<URLParameterTemplate parameters="?$signature$"/>
【００６６】
変形例では、第2のユニバーサルアドレスを生成するために渡されるべきパラメータは、たとえば、渡されるべき第1のパラメータが数字2、次に数字1、その次に数字3であることを意味する以下の構文を使用して、それらの順序で言及される:
<URLParameterTemplate = "2 1 3">
【００６７】
図4を参照して記述される別の変形例では、文脈は、もはやHTTPを介するストリーミングすることによる配信コンテンツの文脈ではないが、リアルタイムプロトコル(RTP)を介してストリーミングすることの文脈であり、リアルタイムストリーミングプロトコル(RTSP)によってチェックする。RTSPによってチェックされるビデオオンデマンド(VOD)サービスでは、ビデオセッションオンデマンドの確立が、ダウンローディングの第1のステップを介して、セッションの開始を可能にする情報を渡す。一般的に、この第1のステップは、以下の表に示されるように、具体的には、VODセッションのためにどのプロトコルが使用されるべきか、コンテンツの特性(データレート、ビデオおよびオーディオコーデック)等を記述することを可能にする、SDPプロトコル(IETF RFC 4566)に依存する。この情報は、ファイル(「sdp」ファイルと呼ばれる)の以前のダウンローディングを介して回復されて、続いてクライアント端末とサーバとの間にストリーミングセッションを設定するために使用され得る。
【００６８】
【表３】
0006277194.tif 000004
【００６９】
図4に示されるように、本発明は、このアプリケーションコンテキストに直接適用することができる。
【００７０】
端末1が、SDP記述ファイルを取得したと仮定する。
【００７１】
次いで、SDPファイルのダウンロードを求める要求の間に使用されるパラメータが、セッションが確立されることを可能にする要求を構築するために使用される。特に、パラメータ「device=laptop」が、SDPファイルのユニバーサルアドレスに添付されて、rtspプロトコルを使用してオーディオセグメントを回復するために渡される。メディアセグメント要求は、以下の形式をとる:
rtsp://movie.example.com/ost.wav&device=laptop
【００７２】
表2の例と同じように、本発明がアクティブにされることを可能にするこのSDPファイルに新しいシグナリングを挿入することが適切である。
【００７３】
当然、上述の実装形態は純粋に非限定的な表示として与えられ、それによって本発明の範囲を逸脱することなしに、当業者によって多数の修正形態を容易に適用することができる。
【符号の説明】
【００７４】
1  端末
3  サービスプラットフォーム
4  記述文書
8  コンテンツプラットフォーム
【図１】
0006277194.tif 000005
【図２】
0006277194.tif 000006
【図３】
0006277194.tif 000007
【図４】
0006277194.tif 000008