JP6770000B2 - ＤＡＳＨクライアントＱｏＥメトリックのミドルウェア配信 - Google Patents

Description

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

本開示は、メディアデータの転送に関する。

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

ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。

ビデオ、オーディオおよび時限のテキストデータを含むメディアデータなどのデータは、多様な転送方法において配信され得る。1つのそのような方法は、第3世代パートナーシッププロジェクト(3GPP)ネットワークにおけるマルチメディアブロードキャスト/マルチキャストサービス(MBMS)である。たとえば、MBMSは、関心のあるサービスを単一の配信パイプを使用して多数の加入者に配信することを可能にする。

ビデオクライアントによるエクスペリエンス品質(QoE)報告は、システム内の配信性能をモニタするため、およびエンドユーザの視聴の品質を測定するために重要である。たとえば、MBMSは、それの受信報告フレームワークを介する転送品質およびユーザQoEを測定するための方法を提供する。また、ビデオ配信方法は、エンドデバイス上に2つの異なる報告ポイントを生成するそれらの方法自体の品質測定報告を含み得る。2つのタイプの報告(MBMSおよびビデオクライアントのタイプ)を統合することは、コンテンツ配信性能の複数の側面をカバーする連結報告がサービスプロバイダに容易に利用可能であることを保証するために有益である。

概して、本開示は、動的適応ストリーミングオーバーHTTP(DASH)クライアントエクスペリエンス品質(QoE)メトリックをミドルウェアユニットによって報告サーバに配信することに関する技法を説明する。すなわち、クライアントデバイスは、メディアデータを取り出すためにDASHを実装するDASHクライアント(たとえば、専用ハードウェアユニットなどのクライアントデバイスまたはウェブブラウザ拡張などのソフトウェアモジュール内のユニット)、およびマルチメディアブロードキャスト/マルチキャストサービス(MBMS)または拡張MBMS(eMBMS)などのブロードキャストまたはマルチキャストサービスを使用してメディアデータを受信するミドルウェアユニットを含み得る。また、ミドルウェアユニットは、受信されたメディアデータをキャッシュし、クライアントデバイスからの要求に応答してメディアデータをDASHクライアントに提供するという点で、ミドルウェアユニットは、DASHクライアントに対するプロキシサーバとして働く。その上、ミドルウェアユニットは、DASH QoEメトリック報告をクライアントデバイスから受信し、これらのDASH QoEメトリック報告をDASHクライアントに代わって報告サーバに配信することができる。

一例では、品質測定報告を生成する方法は、クライアントデバイスのミドルウェアユニットによって実行され、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信するステップと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成するステップと、メディアデータの少なくとも一部分をクライアントデバイスのターゲットアプリケーションに配信するステップと、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信するステップと、QoE報告のコンテンツを受信報告サーバに提供するステップとを含む。再び、この例では、受信報告はQoE報告のコンテンツを含むが、他の例では、これらの報告は、個別におよび/または個別の報告サーバに配信される場合がある。

別の例では、品質測定報告を生成するためのデバイスは、デジタル回路を使用して実装された1つまたは複数のハードウェアベースのプロセッサを含み、プロセッサは、メディアデータのためのミドルウェアユニットおよびターゲットアプリケーションを実行するように構成される。ミドルウェアユニットは、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信することと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成することと、メディアデータの少なくとも一部分をクライアントデバイスのターゲットアプリケーションに配信することと、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信することと、QoE報告のコンテンツを受信報告サーバに提供することとを行うように構成される。

別の例では、品質測定報告を生成するためのデバイスは、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信するための手段と、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成するための手段と、メディアデータの少なくとも一部分をデバイスのターゲットアプリケーションに配信するための手段と、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信するための手段と、QoE報告のコンテンツを受信報告サーバに提供するための手段とを含む。

別の例では、コンピュータ可読記憶媒体は命令を記憶しており、その命令は、実行されたとき、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信することと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成することと、メディアデータの少なくとも一部分をクライアントデバイスのターゲットアプリケーションに配信することと、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信することと、QoE報告のコンテンツを受信報告サーバに提供することとをクライアントデバイスのプロセッサに行わせる。

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

従来の報告技法を使用するシステムを示す概念図である。 本開示の技法による例示的なシステムを示す概念図である。 本開示の技法による別の例示的なシステムを示す概念図である。 ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 図4の取出しユニットの構成要素の例示的なセットをより詳細に示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 例示的なビデオファイルの要素を示すブロック図である。 本開示の技法による、DASHのメディアプレゼンテーション記述(MPD)などのマニフェストファイル内に含まれ得る例示的なデータを示す概念図である。 本開示の技法による、関連配信プロシージャ記述(ADPD)に対する例示的な修正を示す概念図である。 本開示の技法による、ADPDに対する代替スキーマを示す概念図である。 本開示の技法の一例を示す概念図である。 並列ユニキャスト/ブロードキャスト受信に対する挙動の一例を示す概念図である。 複数のDASHクライアントに対する挙動の一例を示す概念図である。 本開示の技法による例示的な方法を示すフローチャートである。 本開示の技法による別の例示的な方法を示すフローチャートである。 本開示の技法に従って構成されるサーバデバイスおよびクライアントデバイスの例を示すブロック図である。

概して、本開示は、エクスペリエンス品質(QoE)メトリックを1つまたは複数のサーバに報告するための技法を説明する。具体的には、これらの技法は、クライアントデバイス(ユーザ機器(UE)とも呼ばれる)が、ストリーミングアプリケーションがLTEネットワーク上でコンテンツブロードキャストにアクセスすることを可能にするミドルウェアユニットを含む場合に適用され得る。また、ミドルウェアは、クライアントデバイスによって実行されるストリーミングアプリケーション(ストリーミングアプリケーションは動的適応ストリーミングオーバーHTTP(DASH)クライアントであり得る)に対して役立つブロードキャストコンテンツに対するhttpサーバとして働く。従来、DASHクライアントはQoEメトリックをサーバに報告するが、本開示の技法は、ミドルウェアユニットがDASHクライアントに、QoEメトリックをDASH QoEメトリックサーバに報告することに代わってまたは加えてミドルウェアに報告するように指示することを可能にする。次いで、ミドルウェアは、MBMS受信報告の内部にまたはそれに添付してDASH QoE測定報告を含むことになる。本開示の技法は、概して、QoEメトリックをストリーミングアプリケーションから受信し、QoEメトリックを主として受信報告サーバに、および場合によってはDASH QoEサーバに提供するミドルウェアユニットを対象とする。

図1は、従来の報告技法を使用するシステム100を示す概念図である。この例では、システム100は、ミドルウェアユニットおよびDASHクライアント108の一例であるマルチキャストサービスデバイスクライアント(MSDC)112を含むユーザ機器(UE)106を含む。UE106は、パーソナルコンピュータ、携帯電話、ラップトップ、タブレット、セットトップボックスなどのクライアントデバイスの一例を表す。また、MSDC112は、マルチメディアブロードキャストマルチキャストサービス(MBMS)ミドルウェアユニット、拡張マルチメディアブロードキャストマルチキャストサービス(eMBMS)ミドルウェアユニットと呼ばれることもある。DASHクライアント108

この例では、プロビジョニングサーバおよびブロードキャストマルチキャストサービスセンター(BMSC)104は、サービス告知118をUE106のMSDC112に配信する。たとえば、サービス告知118は、マニフェストファイル(メディアプレゼンテーション記述(MPD)122など)、セッション記述プロトコル(SDP)、および/または関連配信プロシージャ記述(ADPD)を含む。MSDC112の受信報告ユニット114は、サービス告知118内のSPDフラグメント内で指定されるメトリック、およびサービス告知118内のADPDフラグメント内で指示される受信報告に従って受信統計値を収集する。

また、DASH MPD122は、DASHクライアント108が収集すべきメトリックを指定し得る。したがって、DASHクライアント108は、指定されたメトリック(測定値としても記述される)116を収集し、QoEメトリック116をDASH品質メトリック収集サーバ102にアップロードするDASH QoEユニット110を含む。したがって、この例では、2つの異なる収集ポイントがあり、第1のポイント(DASH品質メトリック収集サーバ102)はQoEメトリックに対するものであり、第2のポイント(プロビジョニングサーバおよびBMSC104)はMBMS受信報告メトリック120に対するものである。

図2は、本開示の技法による例示的なシステム100'を示す概念図である。本開示の技法によれば、図2の例におけるUE106'のDASHクライアント108'は、DASH QoEメトリック116'をUE106'のMSDC112'にアップロードする。具体的には、プロビジョニングサーバおよびBMSC104は、この例ではMPDおよびセグメント122'を含むサービス告知118'を送信する。MSDC112'は、MPDおよびセグメント122'をDASHクライアント108に送信する。MPDは、DASH報告指示を含む。本開示の技法によれば、DASH QoE110'は、MPDに従ってDASH QoE116'をMSDC112'に送信する。したがって、MSDC112'は、DASH QoE測定報告116'を収集してよく、受信報告ユニット114'は、(3GPP MBMS規格に従って収集および報告され得る)対応する受信報告120'内にDASH QoE測定報告を含んでよい。

たとえば、MSDC112'は、DASH QoE測定値をMSDC112'によってホストされるHTTPサーバにポストすることを可能にするために、アップロードされるべきメトリックに対するMPDセクションを修正する場合がある。MPDを修正することは、MPD内のセグメントURLをMSDC112'によってホストされるローカルHTTPサーバを指すために、ミドルウェア(たとえば、MSDC112')によってすでに実施されている場合がある。また、MSDC112'は、DASH QoE収集に関連するHTTP POSTコマンドをたとえばDASHクライアント108'から受けるように構成され得る。さらに、MSDC112'は、DASH QoEログファイルを対応する受信報告120'内に埋め込むことができる。この例では、UE106'は、DASH QoE報告をDASH品質メトリック収集サーバ102'に報告する必要はない。代わりに、UE106'は、単に、DASH QoEメトリック116'報告をMBMS受信報告とともにプロビジョニングサーバおよびBMSC104'に提出してよい。その後、BMSC104'は、DASH QoE報告をDASH品質メトリック収集サーバ102'に提出してよい。

図3は、本開示の技法による別の例示的なシステム100''を示す概念図である。概して、この例は、図3の例において、MBMS受信報告120''を有するプロビジョニングサーバおよびBMSC104''に加えて、UE106''がQoE測定値116''をDASH品質メトリック収集サーバ102''に報告することを除いて、図2の例と同様である。すなわち、この例では、プロビジョニングサーバおよびBMSC104は、サービス告知118''をUE106に送信し、UE106のMSDC112''は、MPDおよびセグメント122''を抽出してDASHクライアント108に転送する。DASH QoEユニット110''は、DASH QoEメトリック116''をMSDC112''に報告する。加えて、DASH QoE110''および/またはMSDC112''の一方または両方は、以下でより詳細に説明するように、複製の、プロキシのまたは追加のDASH QoE報告をDASH品質メトリック収集サーバ102に送信する。

QoEメトリックは、メトリックが報告されるサーバに基づいて変化する場合がある。さらに、報告されたメトリックは、この例においてどのDASH規格が使用されるか(たとえば、3GP-DASH対MPEG-DASH)に依存する場合がある。たとえば、3GP-DASHでは、DASHクライアント108は、HTTP要求/応答トランザクションのリスト、表現切替えイベントのリスト、バッファレベル、および/またはプレイリストに加えて、平均スループット、初期プレイアウト遅延、およびMPD情報を報告する場合がある。一方、MPEG-DASHでは、報告されたメトリックは、HTTP要求/応答トランザクションのリスト、表現切替えイベントのリスト、バッファレベル、および/またはプレイリストに加えて、TCP接続のリストを含む場合がある。

3GP-DASH 26.247バージョンd00のセクション10.6は、品質報告プロトコルが、3GP-DASHのセクション10.6.2において規定されるXMLベースの報告フォーマットと3GP-DASHのセクション10.6.3において規定される報告プロトコルとを含むことを指定する。さらに、3GP-DASHは、それのAnnex Jにおいて規定される「application/3gpdash-qoe-report+xml」としてXMLフォーマットQoE報告のMIMEタイプを指定する。

この例では、報告がDASH品質メトリック収集サーバ102''にアップロードされることを、コンテンツプロバイダおよび/または事業者が所望することが仮定されている。したがって、この例では、DASHクライアント108''(具体的にはDASH QoE110'')は報告を直接MSDC112''にポストしてよく(ローカルホストロケーションにポストしてよく)、MSDC112''はその報告をDASH品質メトリック収集サーバ102''に対して複製してよい(複製された代替物を伴う図3の矢印B、プロキシ対象の/複製されたDASH QoE報告116''Bと呼ばれる)。代替として、DASH QoE110''が、DASH QoEメトリックをMSDC112''に直接報告するのではなく、MSDC112''は、測定報告を、DASH品質メトリック収集サーバ102''への途中でインターセプトしてもよい(プロキシ対象の代替物を伴う図3の矢印B、プロキシ対象の/複製されたDASH QoE報告116''Bと呼ばれる)。

追加または代替として、DASHクライアント108''は、1つの報告をMSDC112''に、および別の報告をDASH品質メトリック収集サーバ102''に、複数の報告を発行してもよい(図3の矢印A、複製された/他のDASH QoE報告116''Aと呼ばれる)。報告は、同じかまたは異なる収集およびアップロード指示に基づいて、異なるメトリックに対するものであってよく、または同じメトリックに対するものであってもよい。

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

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

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

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

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

図4は、ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステム130を示すブロック図である。この例では、システム130は、コンテンツ準備デバイス140と、サーバデバイス160と、クライアントデバイス180とを含む。クライアントデバイス180およびサーバデバイス160は、インターネットを含み得るネットワーク174によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス140およびサーバデバイス160も、ネットワーク174または別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス140およびサーバデバイス160は、同じデバイスを含み得る。

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

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

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

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

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

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

ITU-T H.264/AVCおよび来たるべき高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって指定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に対応し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。

たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの指定されたサイズのようなビットストリーム内のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、特定のプロファイル内のシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム内のシンタックス要素の値に課される制約の指定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であってもよい。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとってもよい。個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートしてもよいことを、H.264規格はさらに規定する。

プロファイルに準拠するデコーダは、普通、プロファイル内で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル内で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈可能性のために有用である場合がある。たとえば、ビデオ送信中、プロファイルおよびレベルの定義のペアが、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCの例では、レベルは、処理される必要があるマクロブロックの数、復号されたピクチャバッファ(DPB:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMBあたりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを決定することができる。

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

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

カプセル化ユニット150は、オーディオエンコーダ146およびビデオエンコーダ148からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類されてもよい。VCLユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および/またはスライスレベルのデータを含み得る。他のNALユニットは、非VCL NALユニットであってもよい。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニット内に包含され得る。

非VCL NALユニットは、特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)内に)シーケンスレベルヘッダ情報を包含し、(ピクチャパラメータセット(PPS)内に)頻繁には変化しないピクチャレベルヘッダ情報を包含し得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがって、コーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を有効化することができ、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。

補足エンハンスメント情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに包含され得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおけるビュースケーラビリティ情報SEIメッセージなどのSEIメッセージ内に包含され得る。これらの例示的なSEIメッセージは、たとえば、動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット150は、表現の特性を記述するメディアプレゼンテーション記述(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット150は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。

カプセル化ユニット150は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを出力インターフェース152に与えてもよい。出力インターフェース152は、ネットワークインターフェースもしくはユニバーサルシリアルバス(USB)インターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェースのような記憶媒体へ書き込むためのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを備えてもよい。カプセル化ユニット150は、マルチメディアコンテンツの表現のそれぞれの表現のデータを出力インターフェース152に提供することができ、出力インターフェース152は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス160に送ることができる。図4の例では、サーバデバイス160は、それぞれのマニフェストファイル166と1つまたは複数の表現168A〜168N(表現168)とをそれぞれが含む様々なマルチメディアコンテンツ164を記憶する記憶媒体162を含む。いくつかの例では、出力インターフェース152はネットワーク174にデータを直接送ることもできる。

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

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

サーバデバイス160は、要求処理ユニット170とネットワークインターフェース172とを含む。いくつかの例では、サーバデバイス160は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス160の機能のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ164のデータをキャッシュし、サーバデバイス160の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース172は、ネットワーク174を介してデータを送受信するように構成される。

要求処理ユニット170は、記憶媒体162のデータに対するネットワーク要求をクライアントデバイス180のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット170は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に記述されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット170は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答して、マルチメディアコンテンツ164のデータを提供するように構成されてもよい。要求は、たとえば、セグメントのURLを使用して、表現168のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット170はさらに、表現168のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット170は、要求されたデータをクライアントデバイス180のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。

追加または代替として、要求処理ユニット170は、ブロードキャストまたはeMBMSなどのマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス140は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス160は、これらのセグメントまたはサブセグメントをeMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット170は、クライアントデバイス180からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス160は、マルチキャストグループと関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス180を含む、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)と関連付けられたクライアントデバイスに広告することができる。次に、クライアントデバイス180は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク174、たとえば、ネットワーク174を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス180などの加入側クライアントデバイスに向けさせることができる。

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

特に、取出しユニット192は、クライアントデバイス180の構成データ(図示せず)を取り出して、ビデオデコーダ188の復号能力およびビデオ出力184のレンダリング能力を決定することができる。構成データはまた、クライアントデバイス180のユーザによって選択される言語の選好、クライアントデバイス180のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス180のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット192は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット192は、クライアントデバイス180の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット192に関して説明した機能のすべてまたは一部は、ハードウェア、もしくはハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。

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

概して、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット192は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット192は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス180は、ネットワーク174を介してマルチメディアデータをストリーミングすることができる一方、ネットワーク174の変化するネットワーク帯域幅の利用可能性に適応することもできる。

追加または代替として、取出しユニット192は、ブロードキャスト、またはMBMS、eMBMSまたはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット192は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット192は、マルチキャストグループに参加した後、サーバデバイス160またはコンテンツ準備デバイス140にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット192は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。

本開示の技法によれば、取出しユニット192は、ストリーミングアプリケーション(たとえば、DASHクライアント)およびミドルウェアユニットを含み得る。ミドルウェアユニットは、エクスペリエンス品質(QoE)測定値をDASHクライアントから受信し、QoE測定値をeMBMS受信報告とともに、たとえばサーバデバイス160に配信するように構成され得る。すなわち、クライアントデバイス180は、図2および図3のUE106'、106''に対応してよく、サーバデバイス160は、図2および図3のプロビジョニングサーバおよびBMSC104'、104''に対応してよい。図4に示さないが、いくつかの例では、上記の図3に関して説明したように、システム130は、DASH品質メトリック収集サーバを追加で含んでよく、DASH品質メトリック収集サーバに、DASHクライアントおよび/またはミドルウェアユニットはDASH QoE測定値を報告してよい。

ネットワークインターフェース194は、選択された表現のセグメントのデータを受信し、取出しユニット192に提供することができ、次に、取出しユニット192は、セグメントをカプセル化解除ユニット190に提供することができる。カプセル化解除ユニット190は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ186またはビデオデコーダ188のいずれかに送ることができる。オーディオデコーダ186は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力182に送る一方、ビデオデコーダ188は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力184に送る。

ビデオエンコーダ148、ビデオデコーダ188、オーディオエンコーダ146、オーディオデコーダ186、カプセル化ユニット150、取出しユニット192、要求処理ユニット170、およびカプセル化解除ユニット190は、各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な固定および/またはプログラマブル処理回路のいずれかとして実装され得る。ビデオエンコーダ148およびビデオデコーダ188の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ146およびオーディオデコーダ186の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ148、ビデオデコーダ188、オーディオエンコーダ146、オーディオデコーダ186、カプセル化ユニット150、取出しユニット192、要求処理ユニット170、および/またはカプセル化解除ユニット190を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話のようなワイヤレス通信デバイスを備え得る。

クライアントデバイス180、サーバデバイス160、および/またはコンテンツ準備デバイス140は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス180およびサーバデバイス160に関するこれらの技法について説明する。しかしながら、コンテンツ準備デバイス140は、サーバデバイス160の代わりに(または、加えて)これらの技法を実行するように構成され得ることを理解されたい。

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

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

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

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

マニフェストファイル166(たとえば、MPDを含み得る)は、表現168のセグメントの可用性を広告することができる。すなわち、MPDは、表現168のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現168内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス180の取出しユニット192は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になるときを決定することができる。

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

ネットワークインターフェース194は、ネットワーク174を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット192を介してカプセル化解除ユニット190に提供する。カプセル化解除ユニット190は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ186またはビデオデコーダ188のいずれかに送ることができる。オーディオデコーダ186は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力182に送る一方、ビデオデコーダ188は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力184に送る。

MPDは、収集されるべきメトリックとアップロードパラメータとを含むメトリック要素を含む。アップロードパラメータは、特定のreporting@schemeIdUri値の使用を通して拡張され得る報告要素を含む。3GP-DASH 26.246バージョンd00のセクション10.5は、Reporting@schemeIdUriのために使用されるべきURNが「urn:3GPP:ns:PSS:DASH:QM10」であるべきであることを指定する。また、3GP-DASHは、3GP-DASH品質報告方式に対する方式情報のセマンティクスを次のように規定する。

図5は、図4の取出しユニット192の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット192は、eMBMSミドルウェアユニット200と、DASHクライアント212と、メディアアプリケーション214とを含む。eMBMSミドルウェアユニット200は、概して、図2および図3のMSDC112'、112''に対応し得るのに対して、DASHクライアント212は、図2および図3のDASHクライアント108'、108''に対応し得る。

この例では、eMBMSミドルウェアユニット200は、eMBMS受信ユニット206と、キャッシュ204と、プロキシ/ローカルサーバ202と、受信報告ユニット210とをさらに含む。この例では、eMBMS受信ユニット206は、たとえば、T. Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月(tools.ietf.org/html/rfc6726において入手可能)に記載された単方向伝送によるファイル配信(FLUTE)、または単方向伝送によるリアルタイムオブジェクト配信(ROUTE)プロトコルに従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット206は、たとえば、BM-SCとして機能し得る図4のサーバデバイス160からブロードキャストを介してファイルを受信することができる。

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

プロキシ/ローカルサーバ202は、DASHクライアント212に関するHTTPサーバとして機能してもよい。たとえば、ミドルウェアは、MPDファイルまたは他のマニフェストファイルをDASHクライアント212に対して修正してもよい。ミドルウェア200は、MPDファイル内、ならびにセグメントがローカルに取り出され得るハイパーリンク内のセグメントに関する調整された利用可能時間を通知する。これらのハイパーリンクは、図4のクライアントデバイス180に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント212は、HTTP GET要求または部分GET要求を使用して、ローカルHTTPサーバ202にセグメントを要求してもよい。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント212は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を作成し、その要求をプロキシ/ローカルサーバ202にサブミットしてもよい。プロキシ/ローカルサーバ202は、キャッシュ204から要求されたデータを取り出し、そのような要求に応答して、そのデータをDASHクライアント212に与えてもよい。代替として、eMBMSミドルウェアユニット200は、MPD内のURLを修正する必要はなく、プロキシとして働く。DASHサーバ170を対象とする要求は、eMBMSミドルウェアユニット200によってインターセプトされ、ローカルキャッシュからサービスされる。

本開示の技法によれば、HTTPプロキシ/ローカルサーバ202はまた、DASH QoEメトリック受信ユニット208を含む。DASH QoEメトリック受信ユニット208は、概して、たとえばHTTPポストコマンドを受け取るDASHクライアントからのDASH報告をインターセプトする(プロキシの場合、プロキシ/ローカルサーバ202は報告を随意にDASH測定サーバに送ってよいことに留意されたい)かまたは受信する(ローカルサーバとして働くとき)ように構成される。次いで、報告は受信報告ユニット210に転送され、受信報告ユニット210は、次いで、DASHクライアント212に代わってDASH QoEメトリックをサーバデバイスに報告してよく、および/またはDASH QoE測定報告を受信報告内に含めてよい。たとえば、DASH QoEメトリックは、QoEメトリックをDASHクライアント212から受信してよい。すなわち、プロキシ/ローカルサーバ202は、メディアプレゼンテーション記述(MPD)または他のマニフェストファイルに従ってDASH QoEメトリックを含むDASHクライアント212からHTTP POSTコマンドを受信するように構成され得る。さらに、受信報告ユニット210は、たとえばeMBMSに従って受信を報告する。いくつかの例では、受信報告ユニット210は、DASH QoEメトリックとeMBMS受信報告の両方を含む単一の報告を送信する。他の例では、受信報告ユニット210は、eMBMS受信報告およびDASH QoEメトリックに対する別個の報告を送信する。

DASH QoE測定報告をDASHクライアント212から受信した後、受信報告ユニット210は、eMBMSミドルウェアユニット200がDASHデータをカプセル化するファイルの受信について報告するプロトコルに関する受信報告とともに、DASH QoEメトリックをサーバデバイスに報告してよい。加えて、いくつかの例では、上記の図3に関して説明したように、eMBMSミドルウェアユニット200および/またはDASHクライアント212の一方または両方はまた、DASH QoEメトリックを専用のDASHメトリックサーバに報告するように構成されてよい。

また、サーバデバイス160(図1)は、サービス告知をeMBMSミドルウェアユニット200に配信するBMSC機能を含み得る。この発明の一部として、サービス告知は、所望のDASH QoE測定報告のタイプおよびコンテンツについての指示をさらに含み得る。たとえば、サービス告知の関連配信プロシージャ(ADP)フラグメントは、DASH QoE報告に対する所望のメトリック、ならびに他のパラメータを記述する新しいフィールドおよび要素を含み得る。例示的な実装形態について、以下の図9および図10において後で説明する。より概略的な意味において、DASH QoE収集指示が、他の手段、たとえばOMA DM、構成ファイル、元のMPD自体、または任意の他の手段を介して配信され得る。

次いで、eMBMSミドルウェアユニット200は、上記の指示をDASHクライアント212に伝達し得る。これらの指示を伝達するための1つの方法は、図4のサーバ160から取得されたメトリック収集パラメータを反映するために、ローカルにホストされるMPDをeMBMSミドルウェアユニット200が修正することである(元のMPDが指示を搬送している場合を除く、その場合にはeMBMSミドルウェアユニット200はMPDを修正する必要はない)。

別の例では、eMBMSミドルウェアユニット200は、所望のメトリックまたはメトリックのスーパーセットを収集し、eMBMSミドルウェアユニット200に常に報告するようにMPDを修正し得る。したがって、eMBMSミドルウェアユニット200は、サーバ160によって要求されるセットに対するメトリックを低減し、サーバ160によって要求される確率で報告することができる。

さらに別の例では、サーバ160は、受信報告収集確率(現在のADPフラグメントにおけるsamplingPercentageパラメータ)を含む収集指示に従って受信報告を収集するように、eMBMSミドルウェアユニット200に命令する。したがって、eMBMSミドルウェアユニット200に送信されたDASH QoE収集指示は、独立した収集確率または条件付き収集確率を含むことができる。相対的収集確率は、受信報告が収集されているときのみDASH QoE測定値の条件付き収集を示し、たとえば、受信報告サンプリングパーセンテージパラメータが50%であり、条件付き収集確率のパーセンテージパラメータが同じく50%である場合、受信報告は、セッションの50%に対して収集され、DASH測定報告は、受信報告がアクティブである場合それらのセッションの50%に対して収集される。したがって、DASH QoE測定値に対する収集の絶対確率は、結果として25%となる。

図6は、例示的なマルチメディアコンテンツ220の要素を示す概念図である。マルチメディアコンテンツ220は、マルチメディアコンテンツ164(図4)、または記憶媒体162に記憶された別のマルチメディアコンテンツに対応し得る。図6の例では、マルチメディアコンテンツ220は、メディアプレゼンテーション記述(MPD)222と複数の表現224A〜224N(表現224)とを含む。表現224Aは、任意のヘッダデータ226とセグメント228A〜228N(セグメント228)とを含む一方、表現224Nは、任意のヘッダデータ230とセグメント232A〜232N(セグメント232)とを含む。文字Nが、便宜的に、表現224の各々内の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現224の間に、異なる数の動画フラグメントが存在し得る。

MPD222は、表現224とは別個のデータ構造を含み得る。MPD222は、図4のマニフェストファイル166に対応し得る。同様に、表現224は、図4の表現168に対応する場合がある。一般に、MPD222は、コーディング特性およびレンダリングの特性、適応セット、MPD222が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現224の特性を一般に表す、データを含み得る。

ヘッダデータ226は、存在するとき、セグメント228の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント228のうちのどれがランダムアクセスポイントを含むのか、セグメント228内のランダムアクセスポイントへのバイトオフセット、セグメント228のユニフォームリソースロケータ(URL)、またはセグメント228の他の態様を記述し得る。ヘッダデータ230は、存在する場合、セグメント232の同様の特性を記述することができる。追加または代替として、そのような特性はMPD222内に完全に含まれ得る。

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

セグメント228、232の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント228、232の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、図4のクライアントデバイス180のような宛先デバイスは、HTTP GET要求を使用して、セグメント228または232を取り出すことができる。いくつかの例では、クライアントデバイス180は、HTTP部分GET要求を使用して、セグメント228または232の特定のバイト範囲を取り出すことができる。

本開示の技法によれば、MPD222は、サーバデバイスに報告されるべきメトリックを指定するデータを含み得る。たとえば、MPD222は、以下の図8に関して説明するデータに準拠するデータを含み得る。

図7は、図6のセグメント228、232のうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイル250の要素を示すブロック図である。セグメント228、232の各々は、図7の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル250は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図7の例では、ビデオファイル250は、ファイルタイプ(FTYP)ボックス252と、動画(MOOV)ボックス254と、セグメントインデックス(sidx)ボックス262と動画フラグメント(MOOF)ボックス164と、動画フラグメントランダムアクセス(MFRA)ボックス266とを含む。図7は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従ってビデオファイル250のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、時限のテキストデータなど)を含み得る。

ファイルタイプ(FTYP)ボックス252は一般に、ビデオファイル250のファイルタイプを表す。ファイルタイプボックス252は、ビデオファイル250の最良の使用法を表す仕様を特定するデータを含んでもよい。ファイルタイプボックス252は、代替的には、MOOVボックス254、ムービーフラグメントボックス164、および/またはMFRAボックス266の前に配置され得る。

いくつかの例では、ビデオファイル250などのセグメントは、FTYPボックス252の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル250を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル250のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル250のセグメントタイプを定義し得る。以下でより詳細に論じる図7は、MPD更新ボックスに関する追加の情報を提供する。

MOOVボックス254は、図7の例では、動画ヘッダ(MVHD)ボックス256と、トラック(TRAK)ボックス258と、1つまたは複数の動画延長(MVEX)ボックス260とを含む。一般に、MVHDボックス256は、ビデオファイル250の一般的な特性を表してもよい。たとえば、MVHDボックス256は、ビデオファイル250がいつ最初に作成されたかを表すデータ、ビデオファイル250がいつ最後に修正されたかを表すデータ、ビデオファイル250のタイムスケールを表すデータ、ビデオファイル250の再生の長さを表すデータ、または、ビデオファイル250を全般的に表す他のデータを含んでもよい。

TRAKボックス258は、ビデオファイル250のトラックのデータを含んでもよい。TRAKボックス258は、TRAKボックス258に対応するトラックの特性を記述する、トラックヘッダ(TKHD)ボックスを含んでもよい。いくつかの例では、TRAKボックス258は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは、TRAKボックス258のデータおよび/またはsidxボックス262のデータによって参照され得る動画フラグメント264内に含まれ得る。

いくつかの例では、ビデオファイル250は、2つ以上のトラックを含み得る。したがって、MOOVボックス254は、ビデオファイル250中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス258は、ビデオファイル250の対応するトラックの特性を記述する場合がある。たとえば、TRAKボックス258は、対応するトラックの時間情報および/または空間情報を表す場合がある。MOOVボックス254のTRAKボックス258と同様のTRAKボックスは、カプセル化ユニット150(図6)がビデオファイル250のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を記述してもよい。カプセル化ユニット150は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングしてもよい。

MVEXボックス260は、たとえば、もしあれば、MOOVボックス254内に含まれるビデオデータに加えて、ビデオファイル250がムービーフラグメント264を含むことをシグナリングするために、対応するムービーフラグメント264の特性を記述し得る。ストリーミングビデオデータの文脈では、コード化ビデオピクチャは、MOOVボックス254の中ではなくムービーフラグメント264の中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、MOOVボックス254の中ではなくムービーフラグメント264の中に含まれ得る。

MOOVボックス254は、ビデオファイル250の中のムービーフラグメント264の数に等しい数のMVEXボックス260を含み得る。MVEXボックス260の各々は、ムービーフラグメント264の対応する1つの特性を記述し得る。たとえば、各MVEXボックスは、ムービーフラグメント264の対応する1つの持続時間を記述するムービー延長ヘッダ(MEHD)ボックスを含み得る。

上述したように、図4のカプセル化ユニット150は、実際のコード化ビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶してもよい。ビデオサンプルは、一般に、アクセスユニットに対応してもよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を包含する、1つまたは複数のVCL NALユニットをコード化ピクチャは含む。したがって、カプセル化ユニット150は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、ムービーフラグメント264のうちの1つの中に含み得る。カプセル化ユニット150はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、ムービーフラグメント264の1つに対応するMVEXボックス260の1つの中のムービーフラグメント264の1つの中に存在するものとして、シグナリングすることができる。

SIDXボックス262は、ビデオファイル250の任意の要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス262を含むとは限らない。3GPPファイルフォーマットの例によれば、SIDXボックスは、セグメント(たとえば、ビデオファイル250内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「メディアデータボックスに対応する1つまたは複数の連続するムービーフラグメントボックスの自己完結型セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスが、そのムービーフラグメントボックスに続き、同じトラックについての情報を包含する次のムービーフラグメントボックスに先行する」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を包含する。参照されるサブセグメントは、プレゼンテーション時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照される材料におけるバイトの数のカウントを与える。」ことを示す。

SIDXボックス262は、一般に、ビデオファイル250内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。

ムービーフラグメント264は、1つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント264は、1つまたは複数のピクチャのグループ(GOP)を含んでよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上記で説明したように、ムービーフラグメント264は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント264の各々は、ムービーフラグメントヘッダボックス(MFHD、図7には示されない)を含み得る。MFHDボックスは、ムービーフラグメントのシーケンス番号などの、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント264は、ビデオファイル250の中でシーケンス番号の順番に含まれ得る。

MFRAボックス266は、ビデオファイル250のムービーフラグメント264内のランダムアクセスポイントを記述し得る。これは、ビデオファイル250によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)の探索を実行するなど、トリックモードを実行することを支援し得る。MFRAボックス266は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、図4のクライアントデバイス180のようなクライアントデバイスは、ビデオファイル250のビデオデータを正確に復号し表示するために、MFRAボックス266を必ずしも参照する必要はない。MFRAボックス266は、ビデオファイル250のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでよく、またはいくつかの例では、ビデオファイル250のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでよい。

いくつかの例では、ムービーフラグメント264は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス266は、SPAのビデオファイル250内の位置の指標を提供し得る。したがって、ビデオファイル250の時間的サブシーケンスは、ビデオファイル250のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。

図8は、本開示の技法による、DASHのメディアプレゼンテーション記述(MPD)などのマニフェストファイル内に含まれ得る例示的なデータ280を示す概念図である。この例では、MPDは、MPDtypeボックス内に1つまたは複数のメトリック要素282を含み得る。既存の3GP-DASHは、メトリック要素の1つの発生に対するサポートを制限する。

さらに、MPDは、収集すべきメトリック286を指定する(およびまた、収集パラメータをたとえば丸括弧内に含むことがある)MetricsType 284属性リストを含む。また、MetricsType 284属性リストは、1つまたは複数の報告要素288を含み得る。各報告要素は、3GP-DASHにおいて規定されるユニフォームリソースネーム(URN)であり得るSchemIdURI 290を指定する属性を含み得る。このSchemIdURI 290要素は、拡張要素または別個の名前空間内の属性として追加される構造化データを含み得る。SchemIdURI 290要素の値は、報告すべきサーバの識別子を指定し得る。

その上、MPDは、MetricsType要素に対して0またはそれ以上の範囲要素292を含む。各範囲要素292は、概して、QoEメトリックを収集すべきときを示すデータを含む。範囲要素292が省略される場合、DASHクライアント/ミドルウェアユニットは、メトリックが全セッションに対して収集されるものと決定してよい。この例では、範囲要素292は、開始時間要素289と持続時間要素291とを含む。ライブメディアコンテンツをストリーミングするとき、開始時間要素289は、メディアコンテンツに対する利用可能開始時間に対する開始時間を指定し得る。持続時間要素291は、メトリックが報告されるべきである範囲に対する再生時間内の持続時間を指定し得る。

したがって、メトリック要素282は、MPDルートレベルにおいて規定され得る。報告SchemeIdURI 290の可能な値は、MPEG DASH内で規定されない。概して、SchemeIdURI 290は、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、または他の識別子の値であり得る。3GPPに固有の値は、3GP-DASH 26.247において規定される。属性リスト内の報告要素288の値要素285は、パラメータのリストのために使用される。報告要素288のID要素287は、等価な報告方式を識別し、それによって、複数のそのような要素が同じIDを有する場合、複数の報告schemeIdURIのうちの1つだけが考慮される必要がある。

3GP-DASH 26.247バージョンd00のセクション10.5は、3GP-DASH品質報告方式に対する方式情報のXML(拡張可能マークアップ言語)シンタックスを、次のように指定する。
<?xml version="1.0"?>
<xs:schema targetNamespace="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm"
attributeFormDefault="unqualified"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm">
<xs:annotation>
<xs:appinfo>3GPP DASH Quality Reporting</xs:appinfo>
<xs:documentation xml:lang="en">
このスキーマは、3GP-DASHに対する品質報告方式情報を規定する。
</xs:documentation>
</xs:annotation>
<xs:element name="ThreeGPQualityReporting" type="SimpleQualityReportingType"/>
<xs:complexType name="SimpleQualityReportingType">
<xs:attribute name="apn" type="xs:string" use="optional"/>
<xs:attribute name="format" type="FormatType" use="optional"/>
<xs:attribute name="samplePercentage" type="xs:double" use="optional"/>
<xs:attribute name="reportingServer" type="xs:anyURI" use="required"/>
<xs:attribute name="reportingInterval" type="xs:unsignedInt" use="optional"/>
</xs:complexType>
<xs:simpleType name="FormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="uncompressed" />
<xs:enumeration value="gzip" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

要素「xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm">」は、別個の名前空間を指定する。

上述のように、本開示によるMPDは、複数のメトリック要素の規定を可能にする。2つ以上のメトリック要素が規定される場合、DASHクライアント(たとえば、図5のDASHクライアント212)は、MPDの各メトリック要素に対する固有のメトリック報告を生成し得る。これは、「多くとも1つのメトリック要素がMPD内に存在するものとする」を示す既存の3GP-DASH規格に反する。その上、3GP-DASH規格は、本開示に従って修正されてよく、それによって、その規格は、DASHクライアントがMPDのメトリック要素当たりに1つのメトリック報告を生成することを規定する。

図9は、本開示の技法による、関連配信プロシージャ記述(ADPD)に対する例示的な修正294を示す概念図である。本開示の技法によれば、ADPDに対する修正294は、下記を提供する。
DASH QoE報告が収集されるべきかどうかを示すフラグ296A。
a) 代替として、DASH QoE属性が1つの要素内に追加されてよく、要素が存在する場合、DASH QoE収集はアクティブである。この場合、収集フラグ296Aは不要である。
上記のフラグ296Aが真に設定される場合、いずれかまたはすべての後続の条件付き属性は、修正294の一部として追加され得る。
a) DASH QoEが圧縮されるべきかどうかを示すフラグ296B。
b) 収集すべきメトリック296Cのリスト。
代替として、これらのメトリックは、セッション記述プロトコル(SDP)データ内で指定され得る。
c) DASH QoE収集が受信報告に同期されるべきかどうかを示すフラグ296D。
d) 随意のDASH QoEサンプリングパーセンテージデータ296E。

加えて、ADPDに対する修正294は、MPD内の既存のメトリック情報が廃棄/抑圧されるべきかどうかをミドルウェアに示すフラグ(図示せず)を含み得る。

図10は、本開示の技法による、ADPDに対する代替スキーマを示す概念図である。この例では、ADPDの報告プロシージャタイプ要素300は、追加のDASHQoEProcedure要素302を含む。この追加のDASHQoEProcedure要素302の存在によって、受信報告の一部としてDASHメトリック要素304内で指定されるDASH QoE測定値の収集がトリガされる。図10において円で囲まれるDASHメトリック要素304は、いくつかのメトリックが規定されることを保証することを義務付けられ得る。

上述のように、DASH QoE収集が受信報告に同期されるべきかどうかを示す、DASH QoE Syncフラグ306などのフラグが存在し得る。同期動作は、DASH QoE Syncフラグ306の値に従って次のように規定され得る。
シナリオ1: DASH QoE Syncフラグ306は真に設定され、他のサンプリングパーセンテージはDASH QoEに対して含まれず、RRがアクティブである場合、DASH QoE測定値を収集する。
シナリオ2: DASH QoE Syncフラグ306は真に設定され、条件付きサンプリングパーセンテージ308はDASH QoEに対して含まれる。これは、RRがアクティブである場合、ミドルウェアは、示された条件付き確率に従ってDASH QoE測定値を収集すべきであることを示唆する。
a) 例: 受信報告サンプリングパーセンテージが50%であり、DASH QoEサンプリングパーセンテージが50%であると、時間受信報告の50%が収集され、受信報告が収集されるとき、DASH QoE報告は、時間の50%を収集される(得られる収集の確率は、DASH QoE測定報告に対して25%となる)。
シナリオ3: syncフラグは偽に設定され、サンプリングパーセンテージはDASH QoEに対して含まれる(またはデフォルトは100%である)。これは、RRのアクティビティに無関係に、ミドルウェアは、示された確率においてDASH QoE測定値を収集すべきであることを示唆する。これの代替として、受信報告サーバに配信された受信報告は、DASH QoEメトリックのみを含み得る。

受信報告およびDASH QoE測定報告の統合の例について、以下で説明する。いくつかの例では、eMBMS受信報告およびDASH QoE測定報告は、マルチパート/混合ファイルフォーマットを利用する既存のプロシージャを使用して単一のログファイル内に統合される。

第1の例では、受信報告のコンテンツタイプが、2つのタイプの報告、たとえば受信報告ログファイルに対するテキスト/xmlとDASH報告に対するテキスト/xml-DASHとを区別するために使用され得る。この第1の例によれば、報告は、以下に示すようにフォーマットされ得る。
POST/reporting/reception/ directory
Content-Length: xxx
Content-Type: multipart/mixed; boundary=frontier
Host: w.x.y.z:port
Connection: Keep-Alive
--frontier
Content-Type: text/xml
LOG (eMBMS RR)
--frontier
Content-Type: text/xml-DASH
LOG (DASH QoE Measurement report)
--frontier
など。

第2の例では、同じtext/xmlコンテンツタイプが使用され得る。受信機は、xmlファイルのヘッダ部を介して報告タイプを認識することができる。この第2の例によれば、報告は、以下に示すようにフォーマットされ得る。
POST/reporting/reception/ directory
Content-Length: xxx
Content-Type: multipart/mixed; boundary=frontier
Host: w.x.y.z:port
Connection: UpgradeKeep-Alive
--frontier
Content-Type: text/xml
LOG (eMBMS RR)
--frontier
Content-Type: text/xml
LOG (DASH QoE Measurement report)
--frontier
など。

また別の例では、DASH測定報告が、MBMS受信報告スキーマの新しい要素としてeMBMS受信報告内に埋め込まれ得る。

一例では、Syncフラグがオンであることが仮定される。Syncフラグは常に1(すなわち、オン)に設定されることが推奨され得る。いくつかの実装形態では、syncフラグ属性/要素は、DASH QoE測定値が常にeMBMS受信報告と同期して収集されることを前提として、スキーマの一部ではない。受信報告ポストを介するDASH QoE測定値は、受信報告がアクティブである場合にのみアクティブであり得る。syncフラグオンに対して、統合された受信報告は、eMBMS受信報告のみ、またはeMBMS受信報告およびDASH QoE測定報告の混合を含み得る。

一例では、メトリック属性リストは、ADPD内で与えられる指示のリストを模倣する。SchemeIDURI要素は、次のように満たされ得る。
圧縮フラグ(ADPD圧縮指示に従う)。
サンプリングパーセンテージ(たとえば、ミドルウェアにおいて報告を常に受信するために100%、したがってミドルウェアは、ADPDサンプリングパーセンテージおよびsyncフラグ指示ごとに報告を保持するかまたは廃棄するかを決定することができる)。
URLをポストする(URLは、ミドルウェアHTTPサーバ、たとえば図5のプロキシ/ローカルサーバ202を指すことができる)。
間隔は随意であってよい(より小さくてより頻繁な報告がミドルウェアによって取得されることを保証するためにより小さい間隔に設定されてよく、より頻繁な報告は、DASHクライアントおよび/またはミドルウェアがクラッシュした場合にロバストネスを与え得る)。

一例では、範囲要素は除外されてよく、それによって、全セッションに対してDASH QoE報告は常に存在する。代替として、範囲要素は、QoEメトリックが報告されるべき時間期間を指定するために含まれてよい。

DASHクライアントがDASH QoE測定報告を常に生成し、その報告を次いでミドルウェアにポストするように、ミドルウェアユニット(たとえば、図5のミドルウェアユニット200)は、DASHクライアントに渡されるMPDを修正し得る。しかしながら、ミドルウェアユニットは、受信されたDASH QoEメトリックを報告するかどうかを確率的に判断するように構成され得る。すなわち、DASH QoEメトリックは、ADPD内で指定された確率と同じ確率に従って報告され得る。したがって、いくつかの例では、DASHクライアントからミドルウェアユニットによって受信されたDASH QoE報告は、サーバに報告されることなく廃棄される場合(すなわち、ADPD確率に従って受信を報告すべきでないと決定される場合)がある。

図11Aは、本開示の技法の例示的な性能を示す概念図である。この例では、上記で説明したSyncフラグはオン(すなわち、「真」の値を有する)ことが仮定されている。例示的なプロセスは、以下の通りであり得る。
DASH測定報告は、毎回のDASH閲覧セッションの終わりに生成される。
3GPP eMBMS規格ごとに、eMBMSミドルウェアは、受信/閲覧セッションの終わりにロギング判定を作成する。
eMBMSセッションの終わりに、ミドルウェアは、収集された受信報告ログを有する。
a) ミドルウェアロギング判定はロギングすべきである、と仮定する。ミドルウェアは、マルチパートmimeファイルフォーマットを使用してeMBMS受信報告内に任意の受信されたDASH測定報告を埋め込む。混合マルチパートmimeファイルの形態におけるeMBMS受信報告は、ADPD内で指定されるランダム化期間を使用してアップロードされる。
b) ミドルウェアロギング判定はロギングすべきでない、と仮定する。この場合、ミドルウェアにおいて収集された受信報告は廃棄される。そのセッションのためにDASHクライアントからその後に受信される任意の報告も廃棄される。

代替として、DASH QoE品質報告は、周期的に生成されてよい。これは、DASHクライアントがクラッシュした場合により良い信頼性を与え得る。報告は、依然として、マルチパートmime受信報告ファイル内に埋め込まれてよい。潜在的な問題は、ロギングすることの判定は未だなされておらず、それゆえミドルウェアユニットは、受信報告ロギング判定に基づいて後で報告を廃棄しなければならない場合があることである。

代替例では、Syncフラグがオフであることが仮定される。受信報告ポストによるDASH QoE測定報告は、判定がeMBMS受信報告に対してロギングすべきかどうかに無関係にアクティブであってよい。統合された受信報告は、eMBMS受信報告のみ、eMBMS受信報告およびDASH QoE測定報告の混合、またはDASH QoE測定報告のみを含む場合がある。これは、Syncフラグがオンであるときにアップロードされた受信報告ファイルが3GPP受信報告を常に含む場合と対照的である。

再び図8の例を参照すると、上記で説明したように、Syncフラグがオフであるとき、MPDは、Syncフラグがオンのときと同じであり得る。しかしながら、DASH QoEメトリック報告は、常にDASHクライアントによって収集されてよく、ミドルウェアユニットは、DASH QoEメトリック報告を受信報告に対するログファイル内に含めるかどうかを判定してよい。

図11Bは、本開示の技法による、並列ユニキャスト/ブロードキャスト受信に対する挙動の一例を示す概念図である。ミドルウェアユニット200は、eMBMS上で受信されたクライアントセグメントを登録されたeMBMSをサービスしてよく、eMBMSサービスがもはや利用可能でない場合にユニキャスト(MooD設計)に切り替える。この場合、eMBMSは、サービスがアクティブである場合にセッションの持続時間にわたって受信報告とDASH QoE測定報告とを統合してよい。ミドルウェアユニット200は、UEがユニキャストに切り替えた場合でもFLUTEセッションをアクティブに保持することが期待される。すなわち、ミドルウェアユニット200は、ブロードキャストコンテンツ喪失の期間を通して受信報告を収集することを継続してよい。

図12は、複数のDASHに対する挙動の一例を示す概念図である。たとえば、softAPアーキテクチャの場合、複数のDASHクライアントは、共通のミドルウェアからのeMBMSコンテンツを消費してよい。そのような例では、ミドルウェアは、セッションが終了する間および終了直後まで、すべてのDASH測定報告を収集してよい。ミドルウェアは、すべてのDASH測定報告を共通の受信報告内に埋め込んでよく、共通の受信報告は、(たとえば、DASH測定報告内のclientIDフィールド内に)それぞれのDASHクライアントに対する識別子を指定するステップを含んでよい。

図13は、本開示の技法による例示的な方法を示すフローチャートである。図13の例示的な方法のステップは、図5のミドルウェアユニット200およびクライアントデバイス212によってそれぞれ実行されるように説明される。この方法または類似の方法が、たとえば図2および図3のMSDC112'、112''およびDASHクライアント108'、108''など、ミドルウェアおよびDASHクライアントの他のセットによって実行され得ることを理解されたい。

最初に、ミドルウェアユニット200は、DASH報告要素を含むADPDを受信する(350)。上記で説明したように、DASH報告要素は、DASHメトリックが報告されるべきかどうかを示すフラグ、報告されるべきDASHメトリック、DASHメトリック報告がMBMS受信報告に同期されるべきかどうか、および/またはDASHメトリック報告がMBMS受信報告に同期されない場合のDASH QoEサンプリングパーセンテージのうちの1つまたは複数を含んでよい。

DASHメトリックがMBMS受信報告内に含まれるべきであることをADPDが示すと仮定すると、ミドルウェアユニット200をDASHメトリック報告に対するターゲットとして識別するために、ミドルウェアユニット200はDASH MPDなどのマニフェストファイルを更新してよい(352)。たとえば、ミドルウェアユニット200は、マニフェストファイル内のDASHメトリック受信報告サーバのアドレスとしてローカルホストアドレスを指定してよい。ミドルウェアユニット200は、さらに、マニフェストファイルたとえばDASH MPDを、DASHクライアント212に送信してよい(354)。また、DASHクライアント212は、ミドルウェアユニット200からMPDを受信してよい(356)。

その後、ミドルウェアユニット200は、たとえばMBMSまたはeMBMSのブロードキャストまたはマルチキャストに従ってメディアデータを受信してよい(358)。ミドルウェアユニット200は、たとえばキャッシュ204内で受信されたメディアデータをキャッシュしてよい(360)。次いで、DASHクライアント212は、ミドルウェアユニット200から受信されたメディアデータの全部または一部を要求してよい(362)。その要求に応答して、ミドルウェアユニット200は、要求されたメディアデータをDASHクライアント212に送信してよい(364)。

次いで、DASHクライアント212は、メディアデータを受信してよい(366)。また、DASHクライアント212は、たとえばミドルウェアユニット200から受信されたマニフェストファイルに従って、メディアデータ受信に対するDASHメトリックをミドルウェアユニット200に報告してよい(368)。図13に示していないが、DASHクライアント212はまた、たとえば受信されたメディアデータをメディアアプリケーション214に配信することによって、受信されたメディアデータを処理してよい。

ミドルウェアユニット200は、DASHメトリック報告をDASHクライアント212から受信してよい(370)。たとえば、ミドルウェアユニット200は、DASHメトリックを含むHTTP POSTサブミットをDASHクライアント212から受信してよい。図13の例では、ミドルウェアユニット200は、DASHメトリックを含むMBMS受信報告を生成する(372)。このようにして、ミドルウェアユニット200は、サーバデバイスから受信されたADPDの指示を報告することに従ってメディアデータの受信をカバーし、同じくDASHクライアント212から受信されたDASH QoE報告を含む受信報告を生成してよい。しかしながら、他の例では、ミドルウェアユニット200は、MBMS受信報告とDASH QoE報告とを別々に、いくつかの場合には別々の報告サーバに配信してよい。しかしながら、図13の例では、ミドルウェアユニット200は、DASHクライアント212から受信されたDASHメトリックを含む受信報告を、メディアデータが受信されたメディアサーバに送信する(374)。

一例では、ミドルウェアユニット200は、これら2つの報告を区別するために、異なるマルチパートMIMEタイプをMBMS受信報告およびDASHメトリックに割り当てる。すなわち、ミドルウェアユニット200は、第1のマルチパートMIMEタイプ値をMBMS受信報告に割り当て、第2の異なるマルチパートMIMEタイプ値をDASHメトリックに割り当ててよい。このようにして、ミドルウェアユニット200が受信報告を配信する受信報告サーバは、マルチパートMIMEタイプを使用してMBMS受信報告とDASHメトリックとを区別することができる。

このようにして、図13の方法は、クライアントデバイスのミドルウェアユニットによって実行され、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信するステップと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成するステップと、メディアデータの少なくとも一部分をクライアントデバイスのターゲットアプリケーションに配信するステップと、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信するステップと、QoE報告のコンテンツを受信報告サーバに提供するステップとを含む方法の一例を表す。再び、この例では、受信報告はQoE報告のコンテンツを含むが、他の例では、これらの報告は、個別におよび/または個別の報告サーバに配信され得る。

図14は、本開示の技法による別の例示的な方法を示すフローチャートである。図14の方法はミドルウェアユニット200に関して説明されるが、図2および図3のMSDC112'、112''などの他のデバイスが、この方法または類似の方法を実行するように構成されてもよいことを理解されたい。

初めに、この例では、ミドルウェアユニット200は、たとえばMBMSまたはeMBMSに従ってブロードキャストまたはマルチキャストを介してメディアデータを受信する(380)。図14に示していないが、メディアデータを受信する前に、ミドルウェアユニット200は特定のMBMSまたはeMBMSサービスに加入し得ることを理解されたい。加えて、ミドルウェアユニット200は、いつ受信報告を生成するか、どの情報を受信報告内に含めるかなどの指示を報告するステップを含むADPDを受信し得る。その上、本開示の技法によれば、ADPDは、DASH QoE報告が受信報告内に含まれるべきかまたは別々に提出されるべきかを示すデータを含んでよく、DASH QoE報告が別々に提出されるべきである場合、DASH QoEメトリック報告サーバのネットワークアドレスを含んでよい。

次いでこの例では、ミドルウェアユニット200は、ADPDの受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成する(382)。概して、受信報告は、バックオフ時点およびランダム化期間の後で送信される。この遅延は、ミドルウェアがDASHクライアントによって生成されたDASH QoE測定報告を受信し得ることを保証することになる。いずれの場合にも、受信報告をポストすることは、メディアデータを受信した直後に実行される必要はないが、代わりに以下で説明するように、必要な場合、DASH QoEメトリック報告を受信した後まで遅延されてよい。

また、ミドルウェアユニット200は、ターゲットアプリケーション、たとえば図5のDASHクライアント212などのDASHクライアントにメディアデータを配信する(384)。具体的には、ミドルウェアユニット200は、受信されたメディアデータをたとえばキャッシュ204内にキャッシュしてよく、メディアデータまたはその一部に対する、DASHクライアント212からの要求を待ってもよい。ミドルウェアユニット200は、そのような要求に応答して要求されたメディアデータをDASHクライアント212に送信してよい。要求は、HTTP GET要求または部分GET要求(すなわち、ターゲットURLのバイト範囲を指定するGET要求)を含んでよい。さらに、メディアデータをDASHクライアント212に配信する前に、ミドルウェアユニット200は、MPDなどのマニフェストファイルをDASHクライアント212に送信してよい。マニフェストファイルは、DASH QoEメトリック報告、ならびにメディアファイルに対するURL、メディアファイルが利用可能になるときを示す壁時計時間などの他のマニフェストファイル情報が、ミドルウェアユニット200に配信されるべきであることを示し得る。その上、ミドルウェアユニット200は、DASHクライアント212がDASH QoEメトリック報告を送信すべきサーバとしてミドルウェアユニット200を識別するようにマニフェストファイルを修正し得る。

この例では、メディアデータをターゲットアプリケーションに配信した後、ミドルウェアユニット200は、QoE報告をターゲットアプリケーションから受信する(386)。たとえば、ミドルウェアユニット200は、DASH QoE報告をDASHクライアント212から受信してよい。DASH QoE報告は、HTTP要求/応答トランザクションのリスト、表現切替えイベントのリスト、バッファレベル、TCP接続のリスト、表現切替えイベントのリスト、バッファレベル、および/またはプレイリストに加えて、平均スループット、初期プレイアウト遅延およびMPD情報など、様々な要求されたDASHメトリックに対する値を表すデータを含み得る。

次いで、ミドルウェアユニット200は、DASH QoE報告のコンテンツを、たとえばADPDによって示される受信報告サーバに提供してよい(388)。一例では、ミドルウェアユニット200は、MBMSまたはeMBMS受信報告およびDASH QoE報告のコンテンツを別々に配信してよい。他の例では、ミドルウェアユニット200は、MBMS/eMBMS受信報告およびDASH QoE報告のコンテンツを、たとえば単一のドキュメント(たとえば、単一のファイルまたは他のデータセット)内で一緒に配信してもよい。いくつかの例では、これらの報告が一緒に配信されるとき、ミドルウェアユニット200は、別個のマルチパートMIMEタイプ、たとえばMBMS受信報告に対する第1のマルチパートMIMEタイプおよびDASH QoE報告に対する第2の異なるマルチパートMIMEタイプを使用して報告を識別し得る。

このようにして、図14の方法は、クライアントデバイスのミドルウェアユニットによって実行され、ブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信するステップと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成するステップと、メディアデータの少なくとも一部分をクライアントデバイスのターゲットアプリケーションに配信するステップと、エクスペリエンス品質(QoE)報告をターゲットアプリケーションから受信するステップと、QoE報告のコンテンツを受信報告サーバに提供するステップとを含む方法の一例を表す。再び、この例では、受信報告はQoE報告のコンテンツを含むが、他の例では、これらの報告は、個別におよび/または個別の報告サーバに配信され得る。代替として、ミドルウェアユニット200は、MBMS受信報告とDASH QoE報告とを区別するために別個のXMLヘッダを使用し得る。

図15は、本開示の技法に従って構成されるサーバデバイス400およびクライアントデバイス410の例を示すブロック図である。サーバデバイス400は、図2または図3のプロビジョニングサーバおよびBMSC104、図4のサーバデバイス160および/またはコンテンツ準備デバイス140に対応する場合がある。クライアントデバイス410は、図2または図3のUE106および/または図4のクライアントデバイス180に対応する場合がある。したがって、クライアントデバイス410は、パーソナルコンピュータ、および携帯電話、タブレットもしくはラップトップ、セットトップボックスなどのモバイルデバイスなど、ユーザ機器(UE)の一例を表す。

この例では、クライアントデバイス410は、DASHクライアント412とミドルウェアユニット414とを含む。DASHクライアント412は、図2のDASHクライアント108'、図3のDASHクライアント108''、または図5の取出しユニット192のDASHクライアント212に対応する場合がある。ミドルウェアユニット414は、図2のMSDC112'、図3のMSDC112''、または図5の取出しユニット192のeMBMSミドルウェア200に対応する場合がある。DASHクライアント412は、たとえば、クライアントデバイス410によって実行される、ウェブブラウザへのソフトウェアベースのプラグインを表してよい。

ミドルウェアユニット414およびDASHクライアント412は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装されてもよい。ソフトウェアまたはファームウェアで実装されるとき、コンピュータ可読媒体および1つまたは複数の処理ユニットなどの必要なハードウェアもまた設けられることが予想される。概して、処理ユニットは、1つまたは複数のASIC、DSP、FPGA、マイクロプロセッサなど、固定のまたはプログラム可能なデジタル論理回路を使用して実装される。

本開示の技法によれば、ミドルウェアユニット414は、メディアデータをサーバデバイス400からブロードキャストまたはマルチキャストを介して受信することと、受信された報告指示に従ってメディアデータの受信をカバーする受信報告を生成することと、メディアデータの少なくとも一部分をクライアントデバイス410のDASHクライアント412(この例では、ターゲットアプリケーションの一例を表す)に配信することと、エクスペリエンス品質(QoE)報告をDASHクライアント412から受信することと、QoE報告のコンテンツを受信報告サーバに提供することとを行うように構成され得る。受信報告サーバは、サーバデバイス400または別個のサーバデバイス(図示せず)に対応する場合がある。

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

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

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

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

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

100 システム
102 動的適応ストリーミングオーバーHTTP(DASH)品質メトリック収集サーバ
104 プロビジョニングサーバおよびブロードキャストマルチキャストサービスセンター(BMSC)
106 ユーザ機器(UE)
108 DASHクライアント
110 DASHエクスペリエンス品質(QoE)ユニット
110' DASH QoEユニット
110'' DASH QoEユニット
112 マルチキャストサービスデバイスクライアント(MSDC)
112' MSDC
112'' MSDC
114 受信報告ユニット
114' 受信報告ユニット
114'' 受信報告ユニット(原文に記載なし)
116 DASH QoEメトリック
116' DASH QoEメトリック、DASH QoE測定報告
116'' QoE測定値、DASH QoEメトリック
116''A DASH QoE報告
116''B DASH QoE報告
118 サービス告知
118' サービス告知
118''' サービス告知
120 マルチメディアブロードキャスト/マルチキャストサービス(MBMS)受信報告メトリック
120' 受信報告
120'' MBMS受信報告メトリック
122 メディアプレゼンテーション記述(MPD)、DASH MPD
122' MPDおよびセグメント
122'' MPDおよびセグメント
130 システム
140 コンテンツ準備デバイス
142 オーディオソース
144 ビデオソース
146 オーディオエンコーダ
148 ビデオエンコーダ
150 カプセル化ユニット
152 出力インターフェース
160 サーバデバイス
166 マニフェストファイル
170 DASHサーバ
180 クライアントデバイス
182 オーディオ出力
184 ビデオ出力
186 オーディオデコーダ
188 ビデオデコーダ
190 カプセル化解除ユニット
192 取出しユニット
194 ネットワークインターフェース
160 サーバデバイス
162 記憶媒体
164 マルチメディアコンテンツ
166 マニフェストファイル
168 表現
168A 表現
168N 表現
170 要求処理ユニット
172 ネットワークインターフェース
174 ネットワーク
200 eMBMSミドルウェアユニット
200 拡張MBMS(eMBMS)ミドルウェア
202 プロキシ/ローカルサーバ
204 キャッシュ
206 eMBMS受信ユニット
208 DASH QoEメトリック受信ユニット
210 受信報告ユニット
212 DASHクライアント
214 メディアアプリケーション
220 マルチメディアコンテンツ
222 メディアプレゼンテーション記述(MPD)
224A 表現
224N 表現
226 ヘッダデータ
228 セグメント
228A セグメント
228N セグメント
230 ヘッダデータ
232A セグメント
232N セグメント
250 ビデオファイル
252 ファイルタイプ(FTYP)ボックス
254 動画(MOOV)ボックス
256 動画ヘッダ(MVHD)ボックス
258 トラック(TRAK)ボックス
260 動画延長(MVEX)ボックス
262 セグメントインデックス(sidx)ボックス
264 ムービーフラグメントボックス
266 動画フラグメントランダムアクセス(MFRA)ボックス
280 例示的なデータ
282 メトリック要素
284 MetricsType
286 メトリック
288 報告要素
289 開始時間要素
290 SchemIdURI
291 持続時間要素
292 範囲要素
294 関連配信プロシージャ記述(ADPD)に対する修正
296A フラグ
296B フラグ
296C メトリック
296D フラグ
296E DASH QoEサンプリングパーセンテージデータ
300 ADPDの報告プロシージャタイプ要素
302 DASHQoEProcedure要素
304 DASHメトリック要素
306 DASH QoE Syncフラグ
400 サーバデバイス
410 クライアントデバイス
412 DASHクライアント
414 ミドルウェアユニット

Claims (15)

1. 品質測定報告を生成する方法であって、クライアントデバイスのミドルウェアユニットによって、
   マルチメディアブロードキャスト/マルチキャストサービス(MBMS)または拡張MBMS(eMBMS)に従ってブロードキャストまたはマルチキャストを介してサーバデバイスからメディアデータを受信するステップと、
   受信された報告指示に従って前記メディアデータの前記受信をカバーする受信報告を生成するステップと、
   前記メディアデータの少なくとも一部分を前記クライアントデバイスのターゲットアプリケーションに配信するステップであって、前記ターゲットアプリケーションが、動的適応ストリーミングオーバーHTTP(DASH)クライアントを含み、前記ミドルウェアユニットが、前記DASHクライアントに対するプロキシサーバとして働く、ステップと、
   エクスペリエンス品質(QoE)メトリックを前記ターゲットアプリケーションから受信するステップと、
   前記QoEメトリックを受信報告サーバに提供するステップと
   を含む、方法。
2. 前記受信報告サーバが前記サーバデバイスと同じである、請求項1に記載の方法。
3. 前記ターゲットアプリケーションが前記QoEメトリックを送信すべき宛先アドレスとして前記クライアントデバイスのローカルホストアドレスを前記ターゲットアプリケーションにシグナリングするステップをさらに含む、請求項1に記載の方法。
4. 前記QoEメトリックを受信するステップが、指定されたローカルホストアドレスへの前記QoEメトリックを含むHTTP POSTサブミッションを前記ターゲットアプリケーションから受信するステップを含む、請求項3に記載の方法。
5. 報告されるべき前記QoEメトリックを示すデータを含む前記メディアデータに対するマニフェストファイルを前記ターゲットアプリケーションに送信するステップをさらに含む、請求項1に記載の方法。
6. 前記サーバデバイスに提供されるべき前記QoEメトリックを示す前記データを含むように、前記メディアデータに対する前記マニフェストファイルのオリジナルバージョンを修正するステップをさらに含む、請求項5に記載の方法。
7. 前記サーバデバイスに提供されるべき前記QoEメトリックを示す前記データを前記サーバデバイスから受信するステップをさらに含む、請求項6に記載の方法。
8. 前記マニフェストファイルが複数のメトリック要素を含み、前記複数のメトリック要素の各々が、前記サーバデバイスに提供されるべきそれぞれの属性メトリックを含む、請求項5に記載の方法。
9. 前記QoEメトリックが前記受信報告サーバに報告されるべきであることを示すデータを受信するステップをさらに含む、請求項1に記載の方法。
10. 前記データを受信するステップが、前記QoEメトリックが圧縮されるべきかどうか、報告されるべきQoEメトリックのリスト、QoEメトリックの報告が前記ブロードキャストもしくはマルチキャストに対する受信報告に同期されるべきかどうか、またはQoEメトリックが報告されるべきである条件付き確率を表すDASH QoEサンプリングパーセンテージのうちの少なくとも1つを示すデータを受信するステップをさらに含む、請求項9に記載の方法。
11. 前記データを受信するステップが、関連配信プロシージャ記述(ADPD)内で前記データを受信するステップを含む、請求項9に記載の方法。
12. 前記QoEメトリックを提供するステップが、前記QoEメトリックおよび前記受信報告を含む単一のドキュメントを前記サーバデバイスに送信するステップを含み、前記単一のドキュメントを送信するステップが、
    前記単一のドキュメント内に前記QoEメトリックのマルチパートMIMEタイプに対する第1の値を設定するステップと、
    前記単一のドキュメント内に前記受信報告の前記マルチパートMIMEタイプに対する第2の異なる値を設定するステップと
    を含むか、または
    前記QoEメトリックを提供するステップが、前記QoEメトリックおよび前記受信報告を含む単一のドキュメントを前記サーバデバイスに送信するステップを含み、前記単一のドキュメントを送信するステップが、
    前記単一のドキュメント内に前記QoEメトリックの第1の拡張可能マークアップ言語(XML)ヘッダを設定するステップと、
    前記単一のドキュメント内に前記受信報告の第2の異なるXMLヘッダを設定するステップと
    を含むか、または
    前記ターゲットアプリケーションが第1のターゲットアプリケーションを含み、前記QoEメトリックを受信するステップが第1のQoEメトリックのセットを前記第1のターゲットアプリケーションから受信するステップを含み、前記方法が、
    前記第1のQoEメトリックのセットを含む複数のQoEメトリックを前記第1のターゲットアプリケーションを含む複数のターゲットアプリケーションから受信するステップ
    をさらに含み、
    前記QoEメトリックを提供するステップが、前記複数のQoEメトリックを含む報告を前記受信報告サーバに送信するステップを含む、
    請求項1に記載の方法。
13. すべての受信されたデータについて前記QoEメトリックを報告する旨の命令を前記ターゲットアプリケーションに送信するステップと、
    収集確率に基づいて前記報告のうちの少なくとも一部を廃棄するステップと
    をさらに含む、請求項1に記載の方法。
14. 品質測定報告を生成するためのクライアントデバイスであって、請求項1〜13のいずれか一項に記載のステップを実施するように構成される手段を備える、クライアントデバイス。
15. 実行されたとき、クライアントデバイスのプロセッサに請求項1〜13のいずれか一項に記載のステップを実施させる命令を記憶した、コンピュータ可読記憶媒体。

Images