JP6697879B2 - 品質ドリブンストリーミング - Google Patents

Description

本出願は、画像圧縮技術に関する。

本出願は、２０１２年７月１０日に出願された米国仮特許出願第６１／６６９，９８３号明細書、および２０１３年６月１４日に出願された米国仮特許出願第６１／８３５，１０５号の優先権を主張するものであり、それらの内容はこれによって、参照により本明細書に組み込まれる。

ＭＰＥＧ／３ＧＰＰ動的適応ＨＴＴＰストリーミング（ＤＡＳＨ：Dynamic Adaptive HTTP Streaming）標準は、無線および有線ネットワーク上での、ストリーミングコンテンツの帯域幅適応配信（bandwidth-adaptive delivery）の設計に対するフレームワークを定義することがある。しかしながら、ＭＰＥＧ／３ＧＰＰ ＤＡＳＨ標準は、エンコードされたビデオコンテンツの複雑性および品質を感知および適応することに対するメカニズムを提供しないことがある。これは、ネットワーク帯域幅リソースの使用において一定の非効率をもたらすことがあり、および、次善の最適なユーザ経験につながることがある。

ストリーミングコンテンツの配信プロセスの品質ベースの最適化を可能にするためのシステム、方法、および手段が開示される。最適化は、品質ベースの（例えば、品質ドリブン（quality-driven）または品質アウェア（quality-aware）などともまた称されてもよい）切替えの形式を取ってもよい。品質ベースの切替えは、適応ＨＴＴＰベースのストリーミングのフレームワークにおいて有効とされてもよい。クライアントが、それが受信するエンコードされたセグメントの各々の品質に関する情報を有する場合、クライアントは、品質ベースの切替えを有効にしてもよい。セグメント品質に関する情報が、それによってクライアントに通信することができる種々の方法が存在してもよい。そのような通信は、クライアントにおける品質ベースの適応を有効にしてもよい。

ストリーミングクライアントにおける品質ベースの決定を有効にするために、クライアントは、各エンコードされたセグメントの品質に関する情報へのアクセスを有してもよい。品質に関する情報は、エンコードされたセグメントおよび／またはエンコードされたサブセグメントに関する１または複数の品質メトリック（metrics）を含んでもよい。品質に関する情報の追加は、品質に関する情報をマニフェストファイル（manifest file）（例えば、．ｍｄｐファイル）に含むことによって実現されてもよい。例えば、品質に関する情報は、セグメントインデックスファイル（例えば、ＭＰ４またはＭ４Ｓファイル）に記憶されたセグメントインデックスに含まれてよく、および／または、例えば、マニフェストファイルから情報へのリンクを提供することによって、品質に関するセグメント情報が追加のファイルに提供されてもよい。品質に関する情報を受信すると、クライアントは、低ビットレートを有するストリームを要求および／または受信し、それによって、ストリーミングコンテンツの品質を保持しながら帯域幅を節約することができる。例えば、クライアントは、ストリームに対してクライアントにとっての容認可能な品質を有する、低ビットレートストリームを要求および／または受信してもよい。

無線送信／受信ユニット（ＷＴＲＵ）におけるコンテンツ切替えの方法が、複数のストリームとしてエンコードされたコンテンツセグメントに関する品質情報を受信するステップを含んでもよい。コンテンツセグメントは、コンテンツ期間の一部を形成してもよい。コンテンツセグメントのストリームは、ストリームに関連付けられたそれぞれのビットレートおよび品質情報に応じて選択されてもよい。選択されたストリームは、ＷＴＲＵによって要求および／または受信されてもよい。

無線送信／受信ユニット（ＷＴＲＵ）におけるコンテンツ切替えの方法が、複数のストリームとしてエンコードされたコンテンツセグメントに関する品質情報を受信するステップを含んでもよい。コンテンツサブセグメントは、コンテンツ期間の一部を形成することができる、コンテンツセグメントの一部を形成してもよい。コンテンツセグメントのストリームは、ストリームに関連付けられたそれぞれのビットレートおよび品質情報に応じて選択されてもよい。選択されたストリームは、ＷＴＲＵによって要求および／または受信されてもよい。

無線送信／受信ユニット（ＷＴＲＵ）における品質ドリブン切替えの方法であって、方法は、第１のビットレートでコンテンツの第１のストリームを受信するステップを含んでもよい。コンテンツの第１のストリームは、少なくとも品質の閾値レベルを有してもよい。コンテンツの第１のストリームの期間のセグメントに関する品質情報が受信されてもよい。第２のビットレートでのコンテンツの第２のストリームが、受信された品質情報に基づいて判定されてもよい。第２のビットレートは、第１のビットレートよりも低くてもよく、および、コンテンツの第２のストリームは、少なくとも品質の閾値レベルを有してもよい。コンテンツの第２のストリームは、第２のビットレートで要求および／または受信されてもよい。

１または複数の開示される実施形態を実装することができる、例示的な通信システムのシステム図である。 図１Ａで示された通信システム内で使用することができる、例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａで示された通信システム内で使用することができる、例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ａで示された通信システム内で使用することができる、例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図１Ａで示された通信システム内で使用することができる、例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 ビットレートベースのエンコーディングおよび品質ベースのエンコーディングでのＭＯＳ変動（MOS fluctuations）の例を示すグラフである。 ビットレートベースのエンコーディングおよび品質ベースのエンコーディングに対するＭＯＳスコアの例示的な分布を示すグラフである。 適応ＨＴＴＰベースのストリーミングシステムのアーキテクチャの例を示す図である。 品質ベースの適応を使用することによって、ビットレートを削減するための潜在性の例を示す図である。 クライアントバッファフル状態（client buffer fullness states）の例を示す図である。 品質情報が提供されないときのＤＡＳＨストリーミングクライアントの動作のモデルレプレゼンテーション（representation）を示す図である。 品質情報を使用するＤＡＳＨストリーミングクライアントの動作のモデルレプレゼンテーションを示す図である。 ＤＡＳＨプレゼンテーション（DASH presentation）に追加される品質情報トラックの例を示す図である。 ＤＡＳＨセグメント内のｍｄａｔボックスに記憶された品質情報の例を示す図である。 ＤＡＳＨセグメント内のｆｒｅｅまたはｓｋｉｐボックスに記憶された品質情報の例を示す図である。 ＤＡＳＨシステムの高レベルアーキテクチャの例を示す図である。 ＤＡＳＨクライアントモデルの論理コンポーネントの例を示す図である。 ＤＡＳＨメディアプレゼンテーション高レベルデータモデルの例を示す図である。 ３つの異なるタイプのフレームでのエンコードされたビデオストリームの例を示す図である。 ６つの異なるＤＡＳＨプロファイルの例の図である。 ブロックベースビデオエンコーダの例を示すブロック図である。 ブロックベースビデオエンコーダの例を示すブロック図である。

次に、例示的な実施形態の詳細な説明が、種々の図面を参照して説明されることになる。この説明は、考えられる実装の詳細な例を提供するが、詳細は、例示的であり、本出願の範囲を限定するものではないことを意図されることに留意すべきである。

図１Ａは、１または複数の開示される実施形態を実装することができる、例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送、その他などのコンテンツを、複数の無線ユーザに提供する、多重アクセスシステムであってもよい。通信システム１００は、多数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、そのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム１００は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセス方法を採用してもよい。

図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（全体的に、または総称して、ＷＴＲＵ１０２と称されてもよい）と、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５と、コアネットワーク１０６／１０７／１０９と、公衆交換電話ネットワーク（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図していることが認識される。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境で動作および／または通信するように構成された任意のタイプのデバイスであってよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家庭用電化製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースして、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを促進するように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、基地局送受信機（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってよい。基地局１１４ａ、１１４ｂのそれぞれは、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことを理解されるであろう。

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってよく、ＲＡＮ１０３／１０４／１０５はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、および中継ノードなどの、他の基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されてもよい特定の地理的領域内で、無線信号を送信および／または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態において、基地局１１４ａは、例えば、３つの送受信機、例えば、セルのセクタごとに１つの送受信機を含んでもよい。別の実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがって、セルのセクタごとに複数の送受信機を利用してもよい。

基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロウェーブ、赤外線（ＩＲ）、紫外線（ＵＶ）、および可視光など）とすることができる、エアインターフェース１１５／１１６／１１７上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信してもよい。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

特に、上述したように、通信システム１００は、多重アクセスシステムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセススキームを採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５における基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１５／１１６／１１７を確立することができる、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態において、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンス（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立することができる、進化型ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。

他の実施形態において、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（例えば、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅ ｆｏｒ ＧＳＭ（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、ならびに、ビジネス、家庭、車両、およびキャンパスなどの局所化されたエリアにおいて無線接続性を促進するための任意の適切なＲＡＴを利用してもよい。一実施形態において、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態において、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらに別の実施形態において、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、その他）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスすることを要求されなくてもよい。

ＲＡＮ１０３／１０４／１０５は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された任意のタイプのネットワークとすることができる、コアネットワーク１０６／１０７／１０９と通信していてよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、ロケーションベースサービス、プリペイドコーリング、インターネット接続性、およびビデオ配信などを提供してもよく、ならびに／または、ユーザ認証などの高レベルなセキュリティ機能を実施してもよい。図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同一のＲＡＴ、または異なるＲＡＴを採用する他のＲＡＮと、直接的にまたは間接的に通信してもよいことを理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１０３／１０４／１０５に接続されていることに加えて、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。

コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ゲートウェイとしてサービスしてもよい。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける、送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または操作される、有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同一のＲＡＴ、または異なるＲＡＴを採用することができる、１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含んでもよく、例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用することができる基地局１１４ａと、およびＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１３０と、着脱可能メモリ１３２と、電源１３４と、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、上述した要素の任意のサブ組合せを含んでもよいことを理解されるであろう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／または、とりわけ、それらに限定されないが、ベーストランシーバ局（ＢＴＳ）、ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームＮｏｄｅＢ、進化型ホームＮｏｄｅＢ（ｅＮｏｄｅＢ）、ホーム進化型ＮｏｄｅＢ（ＨｅＮＢ）、ホーム進化型ＮｏｄｅＢゲートウェイ、およびプロキシノードなどの、基地局１１４ａおよび１１４ｂが表示することができるノードが、図１Ｂに表され、および本明細書で説明される要素の一部または全部を含んでもよいことを理解される。

プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、およびステートマシンなどであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ１０２が無線環境において動作することを可能にする任意の他の機能性を実施してもよい。プロセッサ１１８は、送受信要素１２２に結合することができる送受信機１２０に結合されてもよい。図１Ｂは、プロセッサ１１８および送受信機１２０を別々のコンポーネントとして示すが、プロセッサ１１８および送受信機１２０は、電子パッケージまたはチップにおいてともに統合されてもよいことを理解されるであろう。

送受信要素１２２は、エアインターフェース１１５／１１６／１１７上で、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態において、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってよい。別の実施形態において、送受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態において、送受信要素１２２は、ＲＦと光信号との両方を送信および受信するように構成されてもよい。送受信要素１２２は、任意の組合せの無線信号を送信および／または受信するように構成されてもよいことを理解されるであろう。

加えて、送受信要素１２２は単一の要素として図１Ｂに示されているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含んでもよい。特に、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態において、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７上で無線信号を送信および受信するための、２以上の送受信要素１２２（例えば、多数のアンテナ）を含んでもよい。

送受信機１２０は、送受信要素１２２によって送信されることになる信号を変調し、および、送受信要素１２２によって受信される信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１０２は、マルチモード能力を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの多数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、ならびに、それらから、ユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８に、ユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの、任意のタイプの適切なメモリからの情報にアクセスし、および、任意のタイプの適切なメモリにデータを記憶してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶装置を含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態において、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などの、物理的にＷＴＲＵ１０２に配置されていないメモリからの情報にアクセスし、およびメモリにデータを記憶してもよい。

プロセッサ１１８は、電源１３４から電力を受信してもよく、ならびに、ＷＴＲＵ１０２における他のコンポーネントに電力を分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２を電力供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）その他）、ソーラセル、および燃料セルなどを含んでもよい。

プロセッサ１１８はまた、ＷＴＲＵ１０２の現在の位置に関して位置情報（例えば、経度および緯度）を提供するように構成することができる、ＧＰＳチップセット１３６に結合されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７上で基地局（例えば、基地局１１４ａ、１１４ｂ）から位置情報を受信し、および／または、２以上の近隣の基地局から受信されている信号のタイミングに基づいて、その場所を判定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、任意の適切な位置判定方法によって位置情報を取得してもよいことを理解されるであろう。

プロセッサ１１８は、他の周辺機器１３８にさらに結合されてよく、周辺機器１３８は、追加の特徴、機能性、および／またはワイヤードもしくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーハンドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。

図Ｃは、実施形態に従った、ＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を採用して、エアインターフェース１１５上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０３はまた、コアネットワーク１０６とも通信してもよい。図１Ｃに示されるように、ＲＡＮ１０３は、エアインターフェース１１５上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機をそれぞれ含むことができる、ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを含んでもよい。ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内で特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、１４２ｂを含んでもよい。ＲＡＮ１０３は、実施形態との整合性を維持しながら、任意の数のＮｏｄｅＢおよびＲＮＣを含んでもよいことを理解されるであろう。

図１Ｃに示されるように、ＮｏｄｅＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してもよい。加えて、ＮｏｄｅＢ１４０ｃは、ＲＮＣ１４２ｂと通信してもよい。ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して、互いに通信してもよい。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されているそれぞれのＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されてもよい。加えて、ＲＮＣ１４２ａ、１４２ｂの各々は、アウタループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化などの他の機能性を実行またはサポートするように構成されてもよい。

図１Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。上述した要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有および／または操作されてもよいことを理解されるであろう。

ＲＡＮ１０３におけるＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク１０６におけるＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上線通信デバイスとの間の通信を促進してもよい。

ＲＡＮ１０３におけるＲＮＣ１４２ａはまた、ＩｕＰＳインターフェースを介して、コアネットワーク１０６におけるＳＧＳＮ１４８に接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間の通信を促進してもよい。

上述したように、コアネットワーク１０６はまた、他のサービスプロバイダによって所有および／または操作される、他の有線または無線ネットワークを含むことができる、ネットワーク１１２に接続されてもよい。

図１Ｄは、実施形態に従った、ＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上述したように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインターフェース１１６上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０７と通信してもよい。

ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含んでもよいが、ＲＡＮ１０４は、実施形態との一貫性を維持しながら、任意の数のｅＮｏｄｅＢを含んでもよいことを理解されるであろう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、エアインターフェース１１６上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機をそれぞれ含んでもよい。一実施形態において、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅＮｏｄｅＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および、ＷＴＲＵ１０２ａから無線信号を受信してもよい。

ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられてもよく、ならびに、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてもよい。図１Ｄに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェース上で互いに通信してもよい。

図１Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２と、サービングゲートウェイ１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６とを含んでもよい。上述した要素の各々は、コアネットワーク１０７の一部として示されているが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有および／または操作されてもよいことを理解されるであろう。

ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよく、および、制御ノードとしてサービスしてもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチの間に特定のサービングゲートウェイを選択することなどの役割を果たしてもよい。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間を切替えるための、制御プレーン機能を提供してもよい。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよい。サービングゲートウェイ１６４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃからのユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ１６４はまた、ｅＮｏｄｅＢ間のハンドオーバの間に、ユーザプレーンをアンカリングすること（anchoring）、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの他の機能を実行してもよい。

サービングゲートウェイ１６４はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間の通信を促進することができる、ＰＤＮゲートウェイ１６６に接続されてもよい。

コアネットワーク１０７は、他のネットワークとの通信を促進してもよい。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上線通信デバイスとの間の通信を促進してもよい。例えば、コアネットワーク１０７は、コアネットワーク１０７と、ＰＳＴＮ１０８との間でインターフェースとしてサービスするＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはＩＰゲートウェイと通信してもよい。加えて、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または操作される、他の無線または無線ネットワークを含むことができる、ネットワーク１１２へのアクセスを提供してもよい。

図１Ｅは、実施形態に従った、ＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を採用して、エアインターフェース１１７上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。以下でさらに議論されるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の異なる機能エンティティの間の通信リンクが、参照ポイントとして定義されてもよい。

図１Ｅに示されるように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含んでもよいが、ＲＡＮ１０５は、実施形態との整合性を維持しながら、任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことを理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５における特定のセル（図示せず）に関連付けられてよく、および、エアインターフェース１１７上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含んでもよい。一実施形態において、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１８０ａ、１８０ｂ、１８０ｃはまた、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ施行などのモビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーションポイントとしてサービスしてもよく、ならびに、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０９へのルーティングなどの役割を果たしてもよい。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＲＡＮ１０５との間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１参照ポイントとして定義されてもよい。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０９との論理インターフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、コアネットワーク１０９との間の論理インターフェースは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理に使用することができるＲ２参照ポイントとして定義されてもよい。

基地局１８０ａ、１８０ｂ、１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を促進するためのプロトコルを含むＲ８参照ポイントとして定義されてもよい。基地局１８０ａ、１８０ｂ、１８０ｃと、ＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６参照ポイントとして定義されてもよい。Ｒ６参照ポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられたモビリティイベントに基づいてモビリティ管理を促進するためのプロトコルを含んでもよい。

図１Ｅに示されるように、ＲＡＮ１０５は、コアネットワーク１０９に接続されてもよい。ＲＡＮ１０５と、コアネットワーク１０９との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を促進するためのプロトコルを含むＲ３参照ポイントとして定義されてもよい。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証、認可、アカウンティング（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含んでもよい。上述した要素の各々は、コアネットワーク１０９の一部として示されているが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有および／または操作されてもよいことを理解されるであろう。

ＭＩＰ−ＨＡは、ＩＰアドレス管理の役割を果たしてもよく、ならびに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮの間、および／または異なるコアネットワークとの間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間の通信を促進してもよい。ＡＡＡサーバ１８６は、ユーザ認証およびユーザサービスをサポートすることの役割を果たしてもよい。ゲートウェイ１８８は、他のネットワークとの対話を促進してもよい。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上線通信デバイスとの間の通信を促進してもよい。加えて、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または操作される、他の有線または無線ネットワークを含むことができるネットワーク１１２へのアクセスを提供してもよい。

図１Ｅには示されていないが、ＲＡＮ１０５は、他のＡＳＮに接続されてもよく、および、コアネットワーク１０９は、他のコアネットワークに接続されてもよいことを理解されるであろう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５と他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる、Ｒ４参照ポイントとして定義されてよい。コアネットワーク１０９と、他のコアネットワークとの間の通信リンクは、ホームコアネットワークと移動先コアネットワークとの間の対話を促進するためのプロトコルを含むことができる、Ｒ５参照ポイントとして定義されてよい。

本明細書で議論される技術は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ１０４、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２によって、部分的にまたは全面的に実行されてもよい。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄによって実行されているビデオストリーミングは、本明細書で議論されるような種々の処理に関与してもよい。

ビデオ配信の品質ベースの最適化を可能にするためのシステム、方法、および手段が開示される。開示される技術は、ＭＰＥＧ／３ＧＰＰ ＤＡＳＨ標準を参照して示されるが、それらに限定されない。例えば、セグメント品質に関する情報をＤＡＳＨクライアントに通信することができる方法が、本明細書で説明されてよい。そのような通信は、クライアントにおける品質ベースの適応を有効にしてもよい。本明細書で説明される技術は、ＭＰＥＧ−ＤＡＳＨ標準に対する拡張として実装されてもよい。

画像圧縮の効果は、例えば、信号を送信するためのビットレートおよび／もしくは帯域幅、ならびに／または、再構築された画像の品質を使用して評価されてもよい。画像／フレームまたはビデオの時間および／またはシーケンスが考慮される場合、各フレームに対するビデオコーデックによって達成することができる、複数のビットレートおよび／または品質特性が存在することがある。

シーケンスに対するレートおよび／または品質パラメータ（例えば、ＰＳＮＲ、ＳＳＩＭ、および／またはＭＯＳ）を報告するために、１または複数のフレームにわたるビットレートおよび／または品質パラメータの平均値が使用されてもよい。例えば、同一の平均スコアを達成するために、例えば、全体的な品質経験への異なる影響を有することがある異なる方法が存在することがあるので、平均値は信頼できないことがある。例えば、エンコーダは、ビデオシーケンスにおける個々のフレームに対する品質とレートとの間で、即時的なトレードオフのバランスを取るために、異なる方策を使用することがある。ビットレートは、このレートを前提として、最良の考えられる（possible）ピクチャ／フレーム品質を達成しながら、所与のターゲットに可能な限り近接して（as close as possible）維持されることがある。この方策は、一定ビットレート（ＣＢＲ）エンコーディング（constant bitrate (CBR) encoding）と称されてもよい。品質は、各フレームに対するそのような品質を達成するのに必要とされる最小の考えられる数のビットを使用しながら、所与のターゲットに近接して維持されてもよい。この方策は、一定品質エンコーディングと称されてもよい。

ビデオコンテンツの変化する複雑性に順応するために、エンコーダは、エンコーダが、レートおよび／または品質がフレームからフレームへと変動することを許容する、一定レートおよび／または一定品質のエンコーディングのバージョンを実装してもよい。例えば、エンコーダは、そのような変動を削減または最小限にするように試みてもよい。そのようなエンコーディングの方策は、それぞれ、ビットレートベースエンコーディングおよび品質ベースエンコーディングと称されてもよい。

図２は、同一のシーケンスのビットレートベースエンコーディングおよび品質ベースエンコーディングでのＭＯＳ変動の例を示すグラフである。図２は、ビデオシーケンスのビットレートベースエンコーディングおよび品質ベースのエンコーディングによって生成されるＭＯＳスコアの例を示す。この例において、品質ベースエンコーディングは、より高いピークビットレート（２．７Ｍｂｐｓ）を利用することができるが、ビットレートベースエンコーディングとおおよそ同一の平均ビットレート（１．８Ｍｂｐｓ）を達成することができる。品質ベースエンコーディングは、より一貫した品質によって特徴付けられてもよい。品質ベースエンコーディングは、ある容認可能なレベル（例えば、フェア（fair））未満に品質が低下する、フレーム／セグメントの少数のインスタンスを有することがある。

図３は、ビットレートベースエンコーディングおよび品質ベースエンコーディングに対するＭＯＳスコアの分布の例である。容認可能なレベル未満の品質低下がないことは、より良好な全体的な品質経験につながることがある。これは、種々の異なるタイプのビジュアルコンテンツおよび再現設定に当てはまることがある。

図４は、適応ＨＴＴＰベースのストリーミングシステム４００の動作の例を示す図である。ストリーミングシステムは、例えば、異なるターゲットレートでエンコードされた複数のストリームを作成することによって、ビデオのレートベースエンコーディングを採用してもよい。クライアントアプリケーションは、１または複数のエンコードされたストリームの間で動的に選択するために使用されてもよい。クライアントによって実装されるストリーム切替えは、例えば、実際には約２〜１０秒であることがある一定の粒度を有することがある。クライアントがエンコードされたストリーム間を切替えることができるポイントは、切替えポイントと称されてもよい。エンコードされたストリーム間でエンコードされたコンテンツの一部は、セグメントと称されてもよい。

ストリーミングセッションの間、ストリーミングクライアントは、１または複数のセグメントの配信のレートを計算してもよい。セグメントの配信のレートは、クライアントに、次のセグメントを受信するために利用可能であるネットワークの帯域幅の推定を与えてもよい。この推定に基づいて、クライアントは、いずれの次のエンコーディング／レートが次のセグメントに使用するかを決定してもよい。これは、クライアントが変化するネットワーク状態に適応することを許容する。例えば、それらに限定はされないがそれらのレートを含む、各エンコードされたストリームに関する高レベルな情報が、マニフェストファイル、またはマルチメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイル（multimedia presentation description (MPD) file）に記憶されてもよい。例えば、ストリーム内のエンコードされたセグメントに対するオフセットおよびタイミング情報は、１または複数のセグメントインデックスファイルに記憶されてもよい。

マニフェストファイルおよび／またはインデックスファイルは、エンコードされたセグメントの各々の品質に関する情報を含まなくてもよい。ストリーミングクライアントは、各セグメントの品質についての情報（knowledge）を有さなくてもよい。この情報なしで、ストリーミングクライアントは、品質ドリブン適応（quality driven adaptation）を実装することが可能でないことがある。これは、ストリーミング配信システムにおいて一定の非効率性をもたらすことがある。例えば、コンテンツをエンコードするのが困難な状況があることがあり、それが、現在のレートで、フェアな品質という結果になることがある。例えば、コンテンツをエンコードするのが容易な状況があることがあり、その場合、品質への影響なしにレートを低くすることは道理にかなう。これの一例が、図５に示される。

図５は、品質ベースの適応（quality-based adaptation）を使用することによって、ビットレートを削減するための潜在性の例を示す図である。図５に示されるように、ビデオは、エンコードするのに容易とすることができる１または複数のセグメントを含んでもよい。そのような例では、より低いレートに切替えることが、一定の上限レベルで品質を保持しながら、帯域幅を節約することができる。適応ＨＴＴＰベースストリーミング（adaptive HTTP-based streaming）のフレームワーク、特に、ＭＰＥＧ／３ＧＰＰ ＤＡＳＨ標準において、そのような品質アウェア（例えば、品質ドリブン）切替えがどのように有効とされてもよいかが、本明細書で説明されてもよい。

ストリーミングクライアントは、例えば、図５に示されるような、一部の品質上限（quality cap）を課してもよい。クライアントは、セグメントに対して達成される１または複数の品質値（例えば、ＰＳＮＲ）を認識してもよい。例えば、次のセグメントが所与の品質ターゲット（例えば、ターゲット３８ｄＢの代わりに４８ｄＢ）以上である１または複数の品質値を達成することをクライアントが判定した場合、クライアントは、所与の品質ターゲットに到達するのに十分なより低いレートで、エンコードを選択してもよい。クライアントは、帯域幅を節約することができ、および／または、配信されているビジュアルコンテンツの品質の一貫性を改善することができる。

ビデオ配信を改善するために、品質情報がＤＡＳＨストリーミングクライアントによって使用されてもよい。クライアントバッファモデルが説明されてよい。図６は、いくつかのクライアントバッファフル状態の例を示す図である。クライアントは、一定の長さ（例えば、１０〜３０秒）のプリロールバッファで動作してもよい。クライアントは、例えば、Ｌｏｗ＿ｂｕｆ６０２およびＨｉｇｈ＿ｂｕｆ６０４などの、１または複数のバッファフル閾値を利用してもよい。Ｌｏｗ＿ｂｕｆ６０２は、そこでクライアントが再バッファリング状態で稼動するリスクになることがある、閾値を意味してもよい。Ｌｏｗ＿ｂｕｆ閾値６０２にあるとき、クライアントは、バッファを補充する（replenish）するために測定を実行してもよい。Ｈｉｇｈ＿ｂｕｆ６０４は、クライアントが切替えおよび／またはスロットリング（throttling）（例えば、最高レートに到達した場合）を考慮するための情報の量を蓄積することができる、閾値を意味してもよい。

図７は、品質情報が提供されないときのＤＡＳＨストリーミングクライアントの動作のモデルレプレゼンテーション７００を示す図である。ＤＡＳＨクライアント動作モデルが説明されてもよい。図７を参照すると、７０２で示されるように、バッファレベルＢｕｆがｌｏｗ＿ｂｕｆ閾値未満であるとき、クライアントは、最低レートレプレゼンテーションを選択して、再バッファリングを回避してもよい。７０４で示されるように、バッファレベルＢｕｆがｌｏｗ＿ｂｕｆ閾値とｈｉｇｈ＿ｂｕｆ閾値との間にあるとき、クライアントは、例えば、利用可能な帯域幅未満である最高レートレプレゼンテーションを選択してもよい。７０６で示されるように、バッファレベルＢｕｆがｈｉｇｈ＿ｂｕｆ閾値よりも大きいとき、クライアントは、最高レートレプレゼンテーションに到達したかをチェックしてもよく、そうである場合、クライアントは、それが既にリアルタイム再生のために十分なデータを有するとき、セグメント負荷の間に（例えば、スロットリング）１または複数の中断（pauses）を導入してもよい。

セグメントごとの品質およびレート情報を使用するクライアント適応モデルが提供されてもよい。図８は、例えば、ビットレートに関わらず、例えば、その品質が閾値ｑｕａｌｉｔｙ＿ｃａｐよりも大きいストリーム／セグメントの選択を回避することができる、品質情報を使用するＤＡＳＨストリーミングクライアントの動作のモデルレプレゼンテーション８００を示す図である。そのような選択は、より帯域幅の使用を控え、および／またはエンドユーザへの体験の品質をより一貫したものとさせる。この品質情報は、例えば、バッファフル情報に加えて使用されてもよい。図８において８０２に示されるように、バッファレベルＢｕｆがｌｏｗ＿ｂｕｆ閾値未満であるとき、クライアントは、最低レートレプレゼンテーションを選択して、再バッファリングを回避してもよい。８０４で示されるように、バッファレベルＢｕｆがｌｏｗ＿ｂｕｆ閾値とｈｉｇｈ＿ｂｕｆ閾値との間にあるとき、クライアントは、例えば、利用可能な帯域幅よりも低く、品質閾値ｑｕａｌｉｔｙ＿ｃａｐを超えない品質を有する、最高レートレプレゼンテーションを選択してもよい。８０６で示されるように、バッファレベルＢｕｆがｂｕｆ＿ｈｉｇｈ閾値よりも大きいとき、クライアントは、最高レートレプレゼンテーションに到達したかをチェックしてもよい。そうである場合、クライアントは、それが既にリアルタイム再生のために十分なデータを有するとき、セグメント負荷の間に（例えば、スロットリング）１または複数の中断を導入してもよい。

ストリーミングクライアントにおいて品質ベースの決定を有効にするために、クライアントは、エンコードされたセグメントの１または複数の品質に関する情報へのアクセスを有してもよい。そのような情報をどのようにＭＰＥＧ−ＤＡＳＨ標準に導入することができるかに関する複数の箇所（places）および複数の方法があってよい。例えば、ＰＳＮＲ、ＳＳＩＭ、ＶＱＭ、ＶＩＦ、Ｊ．３４１、ＭＯＳの１もしくは複数（例えば、任意の許容可能な組合せにおいて）、ならびに／または、別の客観的および／もしくは主観的測定が、追加された品質メトリックとして使用されてもよい。

品質メトリックは、例えば、ＰＳＮＲなどのｄＢスケールを利用してもよい。品質メトリックは、インターバルに、例えば、５レベルＭＯＳスケールに関連付けることができるインターバル［１・・・５］にマッッピングされてもよい。品質値に対するシグナリングは、例えば、追加および拡張を許容することによって、フレキシブルであってもよい。品質値に対するシグナリングは、値範囲にスケーリングすることができるメトリックの通信を許容することができる。例えば、メトリックは、１（最低）から５（最高）などの、ＭＯＳスコアの値範囲にスケーリングされてもよい。品質値に対するシグナリングは、ＰＳＮＲの通信を許容することができる。

品質情報は、粒状（granular）であってもよい。例えば、品質情報は、ＤＡＳＨクライアントが決定を行うことを可能にする、セグメントおよび／またはサブセグメントレベルで定義されてもよい。品質情報は、アクセス可能であってもよい。例えば、ＤＡＳＨクライアントが、前もって、および実際のデータセグメントをロードする前に、品質情報を取り出す（例えば、独立して取り出す）ことができるように、例えば、品質情報は、適応セットにおいてセグメントおよび／またはレプレゼンテーションに対してアクセス可能であってもよい。品質情報は、コンパクトであってもよい。例えば、品質情報のローディングが、ストリーミングクライアントがロードしているデータに関して重大なオーバーヘッドを生じさせないように、品質情報は、コンパクトであってのよい。

エンコードされたセグメントの品質に関する情報を追加するための１つの方法は、ＭＰＤファイルのセグメントリスト部においてタグ（例えば、追加のタグ）を使用することによるものであってもよい。適応セットは、セグメントリストにおいて品質値の存在を示すタグを含んでもよい。そのような宣言の例が、以下に提示される。

独立した品質シーケンス記述子（quality sequence descriptor）が、本明細書で説明されてもよい。品質情報は、例えば、レプレゼンテーションレベルにおいて、別々の記述子として含まれてもよい。この記述子は、品質メトリックを定義してもよく、品質レプレゼンテーションの精度を定義してもよく（例えば、粗いレプレゼンテーションが使用されて、それをよりコンパクトにしてもよい）、および／または、レプレゼンテーションにおいてセグメントに関連付けられた品質値のシーケンスを定義してもよい。

レプレゼンテーションレベルにおける品質情報記述子は、例えば、ＭＰＤがセグメントテンプレート、および／または個々のセグメントファイルへのＵＲＬを使用することができるときのケースでは、各セグメントの実際の圧縮された長さに関する情報を含んでもよい。レプレゼンテーションレベルにおける品質情報記述子は、ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ記述子のケースとして定義されてよく、例えば、品質シグナリング情報に関連付けられた一意の識別子を提供することができる、スキーマユニフォームリソース名（ＵＲＮ）（schema uniform resource name (URN)）を含んでもよい。

品質シーケンス記述子の例示的な実装が、表１において提供される。

エンコードされたセグメントの品質に関する情報を追加する方法は、セグメントインデックス（またはインデックスセグメント）ファイルを使用することであってもよい。セグメントインデックスファイルは、セグメントインデックス情報を含むことができる、ファイル（例えば、特殊化ファイル）を含んでもよく、および／または、ＨＴＴＰサーバ上で．ｍｐｄファイルおよびセグメントファイルとともに記憶されてよい。セグメントインデックスファイルは、．ｍｐ４ファイルのバージョン（例えば、特殊化バージョン）を含んでもよい。セグメントインデックスファイルは、例えば、エンコードされたレプレゼンテーションに対するセグメントインデックス情報を有するＳＴＹＰ．ＳＩＤＸおよび／またはＳＳＩＸタイプボックスを含んでもよい。セグメントインデックスは、インデックス関連ボックス（index-related boxes）がファイルの先頭に位置してよもよいケースで、エンコードされたメディアファイル（例えば、フル．ｍｐ４ファイル）に埋め込まれてもよい。

セグメントインデックスファイルは、例えば、レプレゼンテーションに対するセグメントインデックスを提供するＲｅｐｒｅｓｅｎｔａｔｉｏｎＩｎｄｅｘ要素の存在によって、ＭＰＤファイルから参照されてもよい。セグメントインデックスファイルは、例えば、ＳｅｇｍｅｎｔＬｉｓｔ．ＳｅｇｍｅｎｔＵＲＬ要素における２つの属性、＠ｉｎｄｅｘまたは＠ｉｎｄｅｘＲａｎｇｅの少なくとも１つの存在によって、ＭＰＤファイルから参照されてもよい。セグメントインデックスファイルは、例えば、ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ＠ｉｎｄｅｘ属性の存在によって、ＭＰＤファイルから参照されてもよい。

＠ｉｎｄｅｘＲａｎｇｅ属性が使用されて、メディアセグメント内のインデックスに対してバイト範囲を提供してもよい。これは、メディアセグメントフォーマットによって許可されるときに行われてよい。例えば、＠ｉｎｄｅｘ属性は存在しなくてもよく、および、指定された範囲が、メディアセグメントに対して指定されたバイト範囲内に部分的にまたは完全に存在してもよい。

品質のシグナリングに使用されるセグメントインデックスファイルは、品質情報がインデックスファイルに存在してもよい（例えば、ＭＰＤファイルにおける記述子または属性によって）ことのインジケーション、品質メトリックのタイプの指定（例えば、ＭＰＤに含まれ、および／もしくはセグメントインデックスボックス内に含まれる）、ならびに／または、レプレゼンテーションにおけるセグメントおよび／またはサブセグメントに対する品質値のリストを含んでもよい。品質値のリストは、例えば、ランレングスエンコーディングによって圧縮されてもよい。

品質のシグナリングに使用されるセグメントインデックスファイルは、いくつかの記述要素を含んでもよい。例えば、セグメントインデックスファイルは、例えばＭＰＤファイルにおける記述子または属性を使用して、品質情報がインデックスファイルに存在することを示してもよい。セグメントインデックスファイルは、例えば、ＭＰＤファイルにおける、またはセグメントインデックスボックス内の、品質メトリックのタイプの指定を備えてもよい。セグメントインデックスファイルは、レプレゼンテーションにおける１もしくは複数のセグメントまたはサブセグメントに対する品質値のリストを備えてもよい。このリストは、例えば、ランレングスエンコーディングを使用して圧縮されてもよい。

ＩＳＯＢＭＦＦベースのファイルコンテナに品質パラメータを記憶するために、ボックスが定義されてよい。例えば、以下に一覧化された表２が、ＩＳＯ／ＩＥＣ１４４９６−１２の表１の最後に追加されてよい。

以下の定義を適用することができる。ｑｔｙｐは、ＰＳＮＲ、ＳＳＩＭ、ＭＳ−ＳＳＩＭ、および／またはＶＱＭなどの、品質メトリックのタイプを記述するボックスを示してもよいが、それらに限定されない。ｓｑｌｓは、レプレゼンテーションにおけるセグメントに対する品質メトリックのリストを含むボックスを示してもよい。例示的な構文が、以下に示される。

ｓｓｑｌは、セグメントにおけるサブセグメントに対する品質メトリックのリストを含むボックスを示してもよい。例示的な構文が、以下に示される。

クライアントに、品質情報がインデックスファイルに存在することを示すために、ＭＰＤファイル構文が拡張されて、特別なｑｕａｌｉｔｙＩｎｆｏＰｒｅｓｅｎｔＩｎＩｎｄｅｘＦｉｌｅｓフラグが可能となってもよい。このファイルの使用の例が、以下に示される。

エンコードされたセグメントの品質に関する情報は、それら自体の構文を有する別々のファイルを使用および／または記憶することによって、追加されてもよい。そのようなファイルは、例えば、記述子によって、ＭＰＤファイルにおける対応する適応セットに関連付けられてもよい。そのような記述子の例が、以下に示される。

これは、システム（例えば既存のシステム）での配置およびエンコードされたコンテンツへのパスを提供してもよい。

図９は、ＤＡＳＨプレゼンテーション（DASH presentation）に追加される品質情報トラック９００の例を示す図である。品質情報は、メディアデータコンテナ（ｍｄａｔ）ボックス９０２に埋め込まれてよい。品質情報は、プレゼンテーション内のビデオトラック９０４と共に品質情報トラック９００として、メディアデータコンテナ（ｍｄａｔ）ボックス９０２内に記憶されてもよい。品質情報トラック９００を追加するために、例えば、図９に示されるように、ＤＡＳＨ初期化セグメントは、追加されるトラックをリスト化してもよい。

トラックにおけるメディア情報に対するコンテナ９０６（ｔｒａｋボックス）内では、トラックにおけるメディア情報に対するコンテナ９０８（例えば、ｍｄｉａボックス）は、メディア情報コンテナ９１０（例えば、ｍｉｎｆボックス）を備えてもよい。品質情報トラック９００に対し、メディア情報コンテナ９１０（例えば、ｍｉｎｆボックス）は、ヌルメディアヘッダ（例えば、ｎｍｈｄボックス９１２）タイプを利用してもよい。ｎｍｈｄボックス９１２では、品質情報が提供されてもよく、および、例えば、品質メトリックのタイプ（例えば、ＰＳＮＲ、ＳＳＩＭ、その他）を備えてもよい。品質情報を含むことができるｎｍｈｄボックス９１２に対する構文の例が、以下に提供される。

ｑｕａｌｉｔｙ＿ｍｅｔｒｉｃ＿ｔｙｐｅは、計数（enumeration）であってよい。例えば、０は、ＰＳＮＲを示してもよく、１は、ＳＳＩＭを示してもよい、などである。品質情報トラック９００の存在は、例えば、以下に提供するように、記述ファイルにおいてシグナリングされてもよい。

図１０に示されるように、ｓｉｄｘ（セグメントインデックス）ボックス１００２は、ｍｏｏｆボックス１００４とｍｄａｔボックス１００６のペアへのポインタのリストを含んでもよい。各ペアは、例えば、図１０に示されるようにサブセグメントを表示してもよい。ｍｏｏｆボックス１００４は、ｍｄａｔボックス１００６に存在するトラックをリスト化してもよい。

図１０は、ＤＡＳＨセグメント１００８内のｍｄａｔボックスに記憶された品質情報の例を示す図である。品質情報は、サブセグメントレベルで追加されてもよい。例えば、品質トラック１０１０は、例えば、サブセグメントレベルでのビデオトラックの品質情報を要約することができる、ｍｄａｔボックス１００６において追加されてよい。品質情報は、ｍｄａｔボックス１００６の最初に現れてもよく、それによって、例えば、それを、クライアントによって容易に取り出すことができる。ｍｏｏｆボックス１００４は、品質トラック１０１０の存在を示すことができる、リスト１０１２を備えてもよい。ｍｄａｔボックス１００６における品質情報に対する例示的な構文が、以下に提供されてもよい。

品質情報は、フリースペース（例えば、ｆｒｅｅまたはｓｋｉｐ）ボックスに提供されてもよい。品質に関する情報は、ＭＰＥＧ ＤＡＳＨセグメント内のフリースペース（例えば、ｆｒｅｅまたはｓｋｉｐ）ボックス内に記憶されてもよい。例えば、フリースペースボックスのコンテンツは、プレゼンテーションに影響することなく、関係せず、および／または考慮されなくてもよい。ｆｒｅｅまたはｓｋｉｐボックスは、トップレベルボックス（例えば、Ｍｏｖｉｅ Ｂｏｘ ｍｂｏｘボックスおよび／またはＭｅｄｉａ Ｄａｔａ ｍｄａｔボックスに対するピア）であってもよい。図１１に示されるように、ｆｒｅｅまたはｓｋｉｐボックスは、ＭＰＥＧ ＤＡＳＨセグメント１１０２におけるセグメントインデックスｓｉｄｘボックス１１００の後に、例えば、セグメントの先頭付近などに配置されてもよい。ｍｏｏｆボックス１１０４および／もしくはｍｄａｔボックス１１０６のペアは、サブセグメントを表示してもよく、ならびに／または、ＭＰ４ファイルにおけるｍｏｏｖおよび／もしくはｍｄａｔペアに対応してもよい。ｆｒｅｅおよび／またはｓｋｉｐボックス１１０８は、セグメントの先頭付近に追加されてよく、それによって、例えば、それらは、セグメント全体をフェッチすることに先立ってアクセスされてもよい。

ｆｒｅｅおよび／またはｓｋｉｐボックス１１０８の存在は、例えば、以下に提供されるように、記述ファイルにおいてシグナリングされてもよい。

図１１は、ＤＡＳＨセグメント１１０２内のｆｒｅｅまたはｓｋｉｐボックス１１０８に記憶された品質情報の例を示す図である。例えば、ｆｒｅｅおよび／またはｓｋｉｐボックス１１０８は、セグメントが作成される時間に追加されてよい。ｆｒｅｅおよび／またはｓｋｉｐボックス１１０８が、セグメントが作成された後に追加される場合（例えば、あらかじめ作成されたＤＡＳＨコンテンツにおいて）、ｓｉｄｘのサンプルテーブルで使用されるオフセットが再計算されてよい。

ｆｒｅｅおよび／またはｓｋｉｐボックス１１０８のフォーマットが定義されてもよい。例えば、セグメントインデックスファイルでの使用のために提案されるものと同様の構文が利用されてもよい。例示的な構文が以下に提供される。

本明細書で説明される特徴および要素は、ＨＴＴＰライブストリーミング（ＨＬＳ）および／または他のストリーミングシステムに適用されてもよい。セグメントに対する品質情報のシグナリングは、前もって追加されてよい。この情報は、いずれに要求および／または加入（subscribe）するためのストリームを選択するときに、クライアントによって使用されてもよい。

品質に関する情報の追加は、品質に関する情報をマニフェストファイル（例えば、．ｍｄｐファイル）に含めることによって、品質に関する情報をセグメントインデックスファイル（例えば、ＭＰ４ファイルもしくはＭ４Ｓファイル）に記憶されたセグメントインデックスに含めることによって、ならびに／または、追加のファイルに品質／セグメント情報を提供し、およびＭＰＤファイルからそれへのリンクを提供することによって、実現されてもよい。

動的適応ＨＴＴＰストリーミング（ＤＡＳＨ）は、ＨＴＴＰストリーミングに対するいくつかのアプローチを統合（consolidate）することができる標準である。ＭＰＥＧ ＤＡＳＨは、「３ＧＰ−ＤＡＳＨ」の拡張であってよい。ＤＡＳＨは、無線および有線ネットワークにおける可変帯域幅に対処するために使用されてもよく、ならびにコンテンツプロバイダおよびデバイスによってサポートされてもよい。ＤＡＳＨは、任意のデバイスへの任意のアクセスネットワーク上で、マルチメディアストリーミングサービスを有効にしてもよい。

図１２は、ＤＡＳＨシステム１２００の高レベルアーキテクチャの例を示す図である。ＤＡＳＨシステムは、適切なフォーマットで作成されているライブコンテンツおよび／またはオンデマンドコンテンツを配信することができる、ＨＴＴＰサーバ１２０２のセットとして配置されてもよい。クライアントは、これらのＨＴＴＰサーバから、および／または、コンテンツ分配ネットワーク（ＣＤＮ）１２０４から、直接コンテンツにアクセスしてもよい。ＣＤＮは、それらがコンテンツをキャッシュすることができ、およびネットワークの境界でクライアント付近に位置してもよいことから、多くの数のクライアントが予想される配置に使用されてよい。

ＤＡＳＨでは、ストリーミングセッションは、ＨＴＴＰを使用してセグメントを要求し、および、それらがコンテンツプロバイダおよび／またはＣＤＮ１２０４から受信されるときにそれらを一緒に接合する（splice）ことによって、クライアント１２０６によって制御されてもよい。クライアントは、ネットワーク状態（例えば、パケットエラーレート、遅延ジッタ）およびそれら自体の状態（例えば、バッファフルネス、ユーザ振舞い、選好（preference））に基づいてメディアレートを監視し、例えば継続的に監視し、および調整してもよく、ネットワークからクライアントへとインテリジェンスを効果的に機能させる（move）。

ＤＡＳＨ標準は、インフォマティブ（informative）クライアントモデルと同様であってよい。図１３は、概念的なＤＡＳＨクライアントモデル１３００の論理コンポーネントの例である。ＤＡＳＨアクセスエンジンは、メディアプレゼンテーションディスクリプションファイル（ＭＰＤ）を受信してもよい。ＤＡＳＨアクセスエンジン１３０２は、要求を構築および発行し、ならびにセグメントまたはセグメントの一部を受信してもよい。ＤＡＳＨアクセスエンジン１３０２の出力は、ＭＰＥＧコンテナフォーマット（例えば、ＭＰ４ファイルフォーマットおよび／もしくはＭＰＥＧ−２トランスポートストリーム）における媒体、ならびに／または、媒体の内部タイミング（internal timing）をプレゼンテーションのタイムラインにマッピングすることができるタイミング情報を備えてもよい。エンコードされた媒体のまとまり（chunk）、および／またはタイミング情報の組合せは、コンテンツの正確なレンダリングに対して十分であってもよい。

ＤＡＳＨが、エンコードされたメディアセグメントに課す制約の一部は、デコーディング、後処理、および／または再生が、エンコードされたメディアセグメントの性質に関する情報、および／またはエンコードされたメディアセグメントがどのように配信されたかに関する情報を有さないことがあるメディアエンジン１３０４によって行われてもよい、という仮定に基づいている。メディアエンジン１３０４は、ＤＡＳＨアクセスエンジンによってまとまりで供給される連続メディアファイルを、デコードおよび再生してもよい。

例えば、ＤＡＳＨアクセスエンジン１３０２は、ＪａｖａＳｃｒｉｐｔ（登録商標）を使用してもよく、一方で、メディアエンジン１３０４は、ブラウザ、ブラウザプラグイン（限定はされないが、ＦｌａｓｈまたはＳｉｌｖｅｒｌｉｇｈｔなどの）、および／またはオペレーティングシステムによって提供されてもよい。

図１４は、ＤＡＳＨメディアプレゼンテーションの高レベルデータモデル１４００の例を示す図である。ＤＡＳＨでは、マルチメディアプレゼンテーション１４０２の構成（organization）が、階層データモデルに基づいていてよい。メディアプレゼンテーションディスクリプション（ＭＰＤ）は、ＤＡＳＨメディアプレゼンテーション（例えば、マルチメディアコンテンツ）を作成する期間１４０４のシーケンスを記述してもよい。期間１４０４は、メディアコンテンツのエンコードされたバージョンのセットが利用可能である、メディアコンテンツ期間を表示してもよい。例えば、利用可能なビットレート、言語、および／またはキャプション（caption）のセットは、期間１４０４の間、変化しなくてもよい。

適応セット１４０６は、１または複数のメディアコンテンツコンポーネントの交換可能なエンコードされたバージョンのセットを表示してもよい。例えば、ビデオに対する、一次音声に対する１つ、二次音声に対する１つ、および／またはキャプションに対する１つの、適応セット１４０６があってもよい。多重送信の交換可能なバージョンが単一の適応セット１４０６として記述することができるケースでは、適応セット１４０６が多重化されてもよい。例えば、適応セット１４０６は、期間１４０６に対する、ビデオおよび／または音声を含んでもよい。

レプレゼンテーション１４０８は、１または複数のメディアコンテンツコンポーネントの配信可能なエンコードされたバージョンを記述してもよい。レプレゼンテーション１４０８は、１または複数のメディアストリーム（例えば、多重送信における各メディアコンテンツコンポーネントに対する１つ）を備えてもよい。適応セット１４０６内の単一のレプレゼンテーション１４０８は、含まれるメディアコンテンツコンポーネントをレンダリングするのに十分であってもよい。クライアントは、ネットワーク状態または他の要因を適応させるために、適応セット１４０６内で、１つのレプレゼンテーション１４０８から別のレプレゼンテーション１４０８へと切り替えてもよい。クライアントは、クライアントがサポートしないコーデック、プロファイル、および／またはパラメータを使用するレプレゼンテーション１４０８を考慮しなくてもよい。レプレゼンテーション１４０８内のコンテンツは、固定または可変の長さのセグメント１４１０に、そのうち（in time）分割されてもよい。ＵＲＬは、各セグメント１４１０に対して提供されてもよい。セグメント１４１０は、単一のＨＴＴＰ要求で取り出すことができるデータの最大ユニットであってもよい。

メディアプレゼンテーションディスクリプション（ＭＰＤ）は、ＤＡＳＨクライアントによって使用することができるメタデータを備えたＸＭＬドキュメントであってもよく、適切なＨＴＴＰ−ＵＲＬを構築して、セグメントにアクセスし、および／または、ユーザにストリーミングサービスを提供してもよい。ＭＰＤにおけるベースＵＲＬは、クライアントによって使用されて、メディアプレゼンテーションにおけるセグメントおよび他のリソースへのＨＴＴＰ ＧＥＴ要求を生成してもよい。ＨＴＴＰ部分ＧＥＴ要求が使用されて、バイト範囲を使用することによって（例えば、「Ｒａｎｇｅ」ＨＴＴＰヘッダを介して）セグメントの限定された部分にアクセスしてもよい。代替的なベースＵＲＬが指定されて、位置が利用可能でないケースにおいて、プレゼンテーションへのアクセスを可能にし、マルチメディアストリームの配信に冗長性を提供し、クライアント側の負荷分散および／または並列ダウンロードを可能にしてもよい。

ＭＰＤは、タイプにおいて静的または動的であってもよい。静的なＭＰＤタイプは、メディアプレゼンテーションの間に変化しても、しなくてもよく、および、オンデマンドプレゼンテーションに使用されてもよい。動的なＭＰＤタイプは、メディアプレゼンテーションの間に更新されてもよく、および、ライブプレゼンテーションに使用されてもよい。ＭＰＤが更新されて、各レプレゼンテーションに対するセグメントのリストを拡張し、新たな期間を導入し、および／または、メディアプレゼンテーションを終了してもよい。

ＤＡＳＨでは、異なるメディアコンテンツコンポーネント（例えば、ビデオ、音声）のエンコードされたバージョンは、共通のタイムラインを共有してもよい。メディアコンテンツ内のアクセス単位（access unit）のプレゼンテーション時間は、メディアプレゼンテーションタイムラインと称されてもよい、グローバルな共通プレゼンテーションタイムラインにマッピングされてもよい。このマッピングは、異なるメディアコンポーネントの同期を可能にし、および、同一のメディアコンポーネントの異なるコーディングされたバージョン（例えば、レプレゼンテーション）のシームレスな切り替えを促進することができる。

セグメントは、実際のセグメント化されたメディアストリームを備えてもよい。それらは、切り替え、および／または他のレプレゼンテーションとの同期のプレゼンテーションのために、どのようにメディアストリームをメディアプレゼンテーションタイムラインにマッピングするかに関する情報を含んでもよい。

セグメント可用性タイムライン（Segment Availability Timeline）が、指定されたＨＴＴＰ ＵＲＬにおいて、セグメントの可用性時間をクライアントにシグナリングするのに使用されてもよい。例えば、これらの時間は、実測時間（wall-clock time）で提供されてよい。指定されたＨＴＴＰ ＵＲＬにおいてセグメントにアクセスする前に、クライアントは、実測時間とセグメント可用性時間と比較してもよい。オンデマンドコンテンツに対し、セグメントの可用性時間は、同一であってよい。セグメントが利用可能になると、メディアプレゼンテーションのセグメントは、サーバ上で利用可能であってよい。ＭＰＤは、静的ドキュメントであってもよい。

ライブコンテンツに対し、セグメントの可用性時間は、メディアプレゼンテーションタイムライン（Media Presentation Timeline）におけるセグメントの位置に依存してよい。セグメントは、コンテンツが生成されるときの時間に利用可能となってもよい。ＭＰＤは、周期的に更新されて、プレゼンテーションにおける変化を経時的に反映してもよい。例えば、新たなセグメントに対するセグメントＵＲＬが、ＭＰＤに追加されてもよい。もはや利用可能ではない旧セグメントは、ＭＰＤから除去されてもよい。ＭＰＤを更新することは、セグメントＵＲＬがテンプレートを使用して記述される場合には、省略されてもよい。

セグメントの存続時間は、通常の速度で提示されるときの、セグメントに含まれるメディアの存続時間を表示してもよい。レプリゼンテーション（Representation）におけるセグメントは、同一、またはほぼ同一の存続時間を有してよい。セグメント存続時間は、レプリゼンテーションからレプリゼンテーションへと異なってもよい。ＤＡＳＨプレゼンテーションは、比較的短いセグメント（例えば、数秒）、または全体的なレプリゼンテーションに対する単一セグメントを含む、より長いセグメントで構築されてよい。

ショートセグメントは、ライブコンテンツに適切であってよく（例えば、エンドツーエンドの待ち時間を削減することによって）、およびセグメントレベルでの高い切り替え粒度を可能にする。スモールセグメントは、プレゼンテーションにおけるファイルの数を増大させることがある。ロングセグメントは、プレゼンテーションにおけるファイルの数を削減することによって、キャッシュ性能を改善させることがある。ロングセグメントは、クライアントが、要求サイズを可変（flexible）にすることを可能にする（例えば、バイト範囲要求を使用することによって）。ロングセグメントを使用することは、セグメントインデックスを使用することを含んでもよく、および、ライブイベントにはより適切でないことがある。セグメントは、経時的に拡大されてもよく、またはされなくてもよい。セグメントは、その全体において利用可能にすることができる、完全かつ別個のユニットであってもよい。

セグメントは、サブセグメントにさらに分割されてもよい。各サブセグメントは、整数の完全なアクセス単位を備えてもよい。アクセス単位は、割り当てられたメディアプレゼンテーション時間を有するメディアストリームの単位であってもよい。セグメントがサブセグメントに分割される場合、これらは、セグメントインデックスによって記述されてもよい。セグメントインデックスは、レプレゼンテーションにおけるプレゼンテーション時間範囲と、各サブセグメントによって占有されるセグメントにおける対応するバイト範囲とを提供してもよい。クライアントは、このインデックスを事前にダウンロードし、および、例えば、ＨＴＴＰ部分ＧＥＴ要求を使用して、個々のサブセグメントに対する要求を発行してもよい。セグメントインデックスは、例えば、ファイルの先頭において、メディアセグメントに含まれてもよい。セグメントインデックス情報は、別々のインデックスセグメントにおいて提供されてもよい。

ＤＡＳＨは、例えば、限定はされないが、初期化セグメント、メディアセグメント、インデックスセグメント、および／またはビットストリームスイッチングセグメントを含む、いくつかのタイプのセグメントを定義してもよい。初期化セグメントは、レプレゼンテーションにアクセスするための初期化情報を含んでもよい。初期化セグメントは、割り当てられたプレゼンテーションj巻を有するメディアデータを含んでもよく、または含まなくてもよい。概念上、初期化セグメントは、クライアントによって処理されて、レプレゼンテーションを含むことのメディアセグメントのプレイアウト（play-out）を可能にするための、メディアエンジンを初期化してもよい。

メディアセグメントは、メディアセグメント内で記述され、および／またはレプレゼンテーションの初期化セグメントによって記述されるかのいずれかの、メディアストリームを備えてもよく、およびメディアストリームをカプセル化してもよい。メディアセグメントは、いくつかの完全なアクセス単位を備えてもよく、および、含まれるメディアストリームの各々に対する少なくとも１つのストリームアクセスポイント（ＳＡＰ）を備えてもよい。

インデックスセグメントは、メディアセグメントに関する情報を備えてもよい。インデックスセグメントは、メディアセグメントに対するインデックス情報を備えてもよい。インデックスセグメントは、１または複数のメディアセグメントに対する情報を提供してもよい。インデックスセグメントは、メディアフォーマット固有であってよく、および、詳細は、インデックスセグメントをサポートする各メディアフォーマットに対して定義されてもよい。

ビットストリームスイッチングセグメントは、それが割り当てられるレプレゼンテーションに切り替えるためのデータを備えてもよい。ビットストリームスイッチングセグメントは、メディアフォーマット固有であってよく、および、詳細は、ビットストリームスイッチングセグメントを許可するメディアフォーマットに対して定義されてもよい。１つのビットストリームスイッチングセグメントは、各レプレゼンテーションに対して定義されてもよい。

クライアントは、メディアにおける任意のポイントで、適応セット内のレプリゼンテーションからレプリゼンテーションへと切り替えてもよい。随意の位置における切り替えは、レプリゼンテーション内のコーディング依存性および他の要因のために、複雑であることがある。オーバーラップするデータのダウンロード（例えば、複数のレプリゼンテーションからの同一の期間に対するメディア）は、回避されてもよい。切り替えは、新たなストリームにおいて、ランダムアクセスポイントでより単純であってもよい。ＤＡＳＨは、ストリームアクセスポイント（ＳＡＰ）のコーデック独立の概念（codec-independent concept）を定義し、および種々のタイプのストリームアクセスポイントを識別してもよい。ストリームアクセスポイントタイプは、適応セットのプロパティの１つとして通信されてもよい（例えば、適応セット内のすべてのセグメントが同一のＳＡＰタイプを有することを想定して）。

ストリームアクセスポイント（ＳＡＰ）は、１または複数のメディアストリームのファイルコンテナへのランダムアクセスを可能にしてもよい。ＳＡＰは、その位置から前方に（onward）開始するコンテナに含まれる情報、および／または、コンテナの別の部分もしくは他の部分からの考えられる（possible）初期化データを使用して、識別されたメディアストリームの再生が開始されるのを可能にする、コンテナにおける位置であってよい。初期化データは、外部で利用可能であってもよい。

いくつかのファイルコンテナプロパティが定義されてもよい。Ｔ_SAPは、プレゼンテーション時間、例えば、Ｔ_SAP以上のプレゼンテーション時間を有するメディアストリームのすべてのアクセス単位が、Ｉ_SAPにおいて開始するビットストリームにおけるデータを使用して、およびＩ_SAPよりも前のデータなしで、適正にデコードされるような、メディアストリームのアクセス単位の最早プレゼンテーション時間であってもよい。

Ｉ_SAPは、Ｔ_SAP以上のプレゼンテーション時間を有するメディアストリームのアクセス単位が、Ｉ_SAPにおいて開始するビットストリームデータを使用して、およびＩ_SAPよりも前に開始するデータで、もしくはＩ_SAPよりも前に開始するデータなしで、適正にデコードされるような、ビットストリームにおける位置であってよい。

Ｉ_SAUは、Ｔ_SAP以上のプレゼンテーション時間を有するメディアストリームのアクセス単位が、この最遅アクセス単位、およびデコード順序において続くアクセス単位を使用して、かつデコード順序におけるより早いアクセス単位なしで、適正にデコードされるような、メディアストリーム内のデコード順序における最遅アクセス単位のビットストリームにおける開始位置であってよい。

Ｔ_DECは、Ｉ_SAUにおいて開始するビットストリームにおけるデータを使用して、およびＩ_SAUよりも前に開始するデータで、もしくはＩ_SAUよりも前に開始するデータなしで、適正にデコードすることができる、メディアストリームのアクセス単位の最早プレゼンテーション時間であってもよい。Ｔ_EPTは、ビットストリームにおいて、Ｉ_SAUにおいて開始するメディアストリームのアクセス単位の最早プレゼンテーション時間であってもよい。Ｔ_PTFは、Ｉ_SAUにおいて開始するビットストリームにおけるデコード順序においてメディアストリームの最初のアクセス単位のプレゼンテーション時間であってもよい。

図１５は、パラメータを有するストリームアクセスポイントの例である。図１５は、３つの異なるタイプのフレーム、Ｉ、Ｐ、およびＢでエンコードされたビデオストリーム１５００を示す。Ｐフレームは、デコードされることになる前のＩまたはＰフレームを利用してもよく（例えば、単に利用する）、一方Ｂフレームは、前後のＩおよび／またはＰフレームを利用してもよい。Ｉ、Ｐ、および／もしくはＢフレームにおける送信、デコード、ならびに／またはプレゼンテーション順序は、異なってもよい。

ＳＡＰのタイプは、どのアクセス単位が適正にデコード可能であるか、および／または、プレゼンテーション順序におけるそれらの配列に依存してよい。６つのＳＡＰタイプの例が、本明細書で説明される。Ｔ_EPT＝Ｔ_DEC＝Ｔ_SAP＝Ｔ_PFTである１つのタイプは、「クローズドＧｏＰランダムアクセスポイント」（Closed GoP random access point）として知られるものに対応してもよい。Ｉ_SAPから開始するアクセス単位（デコード順序で）が、適正にデコードされてもよい。結果は、途切れのない（no gap）適正にデコードされたアクセス単位の連続的な時間シーケンスであってもよい。デコード順序における最初のアクセス単位が、プレゼンテーション順序における最初のアクセス単位であってもよい。

別のＳＡＰタイプにおいては、Ｔ_EPT＝Ｔ_DEC＝Ｔ_SAP＜Ｔ_PFTである。このＳＡＰタイプは、Ｉ_SAUから開始するメディアストリームにおけるデコード順序における最初のアクセス単位が、プレゼンテーション順序における最初のアクセス単位でないことがある、「クローズドＧｏＰランダムアクセスポイント」として知られるものに対応してもよい。例えば、最初の２つのフレームは、後方に予測されるＰフレーム（構文的には、Ｈ．２６４および一部の他のコーデックにおいて前方のみＢフレーム（forward-only B-frames）としてコーディングされてもよい）であってよく、および／または、それらはデコードされることになる第３のフレームを必要としてもよく、もしくは必要としなくてもよい。

別のＳＡＰタイプにおいては、Ｔ_EPT＜Ｔ_DEC＝Ｔ_SAP≦Ｔ_PTFである。このＳＡＰタイプは、「オープンＧｏＰランダムアクセスポイント」（Open GoP random access point）として知られるものに対応してもよく、ここでは、適正にデコーディングされないことがあり、および／または、Ｔ_SAP未満のプレゼンテーションタイムを有することがある、Ｉ_SAUに続くデコード順序においていくつかのアクセス単位があってもよい。

別のＳＡＰタイプにおいては、Ｔ_EPT≦Ｔ_PFT＜Ｔ_DEC＝Ｔ_SAPである。このＳＡＰタイプは、「グラジュアルデコーディングリフレッシュ（ＧＤＲ）ランダムアクセスポイント」（Gradual decoding Refresh (GDR) random access point）または「ダーティ」（dirty）ランダムアクセスとして知られるものに対応してもよく、ここでは、適正にデコーディングされないことがあり、および／または、Ｔ_SAPに満たないプレゼンテーションタイムを有することがある、Ｉ_SAUから開始し、およびＩ_SAUに続くデコード順序においていくつかのアクセス単位があってもよい。ＧＤＲの１つの例示的なケースは、イントラＭＢでコーディングされるフレームの一部を有するＮ個のフレーム上で拡張することができる、イントラリフレッシングプロセス８intra refreshing process）であってもよい。オーバーラップしない部分は、Ｎ個のフレームにわたってイントラコーディング（intra coded across N frames）されてもよい。このプロセスは、全フレームがリフレッシュされるまで繰り返されてもよい。

別のＳＡＰタイプにおいては、Ｔ_EPT＝Ｔ_DEC＜Ｔ_SAPである。このＳＡＰタイプは、適正にデコーディングされないことがあり、Ｔ_DECよりも大きいプレゼンテーション時間を有することがあり、および／または、Ｔ_DECがＩ_SAUから開始するアクセス単位の最早プレゼンテーション時間であることがある、Ｉ_SAPから開始するデコード順序において少なくとも１つのアクセス単位があるケースに対応してもよい。

別のＳＡＰタイプにおいては、Ｔ_EPT＜Ｔ_DEC＜Ｔ_SAPである。このＳＡＰタイプは、適正にデコーディングされないことがあり、Ｔ_DECよりも大きいプレゼンテーション時間を有することがあり、および／または、Ｔ_DECがＩ_SAUから開始するアクセス単位の最早プレゼンテーション時間ではないことがある、Ｉ_SAPから開始するデコード順序において少なくとも１つのアクセス単位があるケースに対応してもよい。

ＤＡＳＨのプロファイルは、機能の使用の相互運用性およびシグナリングを可能にするように定義されてもよい。プロファイルは、制限のセットを課してもよい。これらの制限は、メディアプレゼンテーションディスクリプション（ＭＰＤ）文書の機能上、および／またはセグメントフォーマット上にあってもよい。制限は、限定はされないが、メディアコンテンツタイプ、メディアフォーマット、コーデック、および／もしくは保護フォーマット上などのセグメント内の配信されるコンテンツ上、ならびに／または、限定はされないが、ビットレート、セグメント存続時間とサイズ、および／もしくは、水平・垂直ビジュアルプレゼンテーションサイズなどの定量的測定（quantitative measures）上にあってもよい。

例えば、ＤＡＳＨは、図１６に示されるいくつかのプロファイルを定義してもよい。プロファイルは、セグメントに使用されるファイルコンテナのタイプに基づいて、２つのカテゴリに編成されてもよい。３つのプロファイル１６００、１６０２、１６０４は、ＩＳＯベースメディアファイルコンテナを使用してもよく、２つのプロファイル１６０６、１６０８は、ＭＰＥＧ−２トランスポートストリーム（ＴＳ）ベースのファイルコンテナを使用することができ、および１つのプロファイル１６１０は、両方のファイルコンテナタイプをサポートしてもよい。いずれのコンテナタイプも、コーデック独立であってもよい。

オンデマンドプロファイル１６０２のＩＳＯベースメディアファイルフォーマットは、オンデマンドコンテンツに対する基本的なサポートを提供してもよい。オンデマンドプロファイル１６０２の制約は、各レプリゼンテーションが単一セグメントとして提供され、サブセグメントが適応セット内のレプリゼンテーションにわたって調節され、および／または、サブセグメントがストリームアクセスポイントで開始されることであってもよい。オンデマンドプロファイル１６０２は、比較的わずかなコンテンツ管理で、大規模なビデオオンデマンド（ＶｏＤ）ライブラリをサポートしてもよい。オンデマンドプロファイル１６０２は、ＨＴＴＰサーバのスケーラブルかつ効率的な使用を許可してもよく、およびシームレスな切り替えを単純化してもよい。

ＩＳＯベースメディアファイルフォーマットライブプロファイル１６０４は、比較的短い存続時間を有する、ＩＳＯファイルフォーマットの単一ムービーフラグメントからなるセグメントの、ライブエンコーディングおよび／または低待ち時間の配信に対して最適化されてもよい。各ムービーフラグメントは、利用可能なときに要求されてもよい。これは、例えば、テンプレート生成ＵＲＬを使用して実現されてもよい。ＭＰＤ更新に対する要求は、一部のセグメント要求に対して省略されてもよい。セグメントは、それらがセグメント境界上で連結され、ならびにメディアデータにおいて途切れおよび／またはオーバーラップなしにデコーディングされるように、制約されてよい。これは、適応セットにおけるレプリゼンテーションの適応切り替えに関係なくてもよい。このプロファイル１６０４は、非ライブコンテンツを分配するのに使用されてもよい。例えば、ライブメディアプレゼンテーションが終了し、しかし、オンデマンドサービスとして利用可能のままでいるときに、ライブプロファイル１６０４が使用されてもよい。ＩＳＯベースメディアファイルフォーマットメインプロファイル１６００は、ＩＳＯベースメディアファイルフォーマットオンデマンドプロファイル１６０２およびライブプロファイル１６０４のスーパーセットであってもよい。

ＭＰＥＧ−２ ＴＳメインプロファイル１６０６は、ＭＰＥＧ−２トランスポートストリーム（ＴＳ）コンテンツに対するメディアセグメントフォーマットに、わずかな制約を課してもよい。例えば、レプリゼンテーションは多重化されてもよく、そのため、クライアントにおけるメディアストリーム（音声、ビデオ）をバインディングすることは要求されなくてもよい。例えば、セグメントは、整数のＭＰＥＧ−２ＴＳパケットを含んでもよい。例えば、インデキシングおよびセグメント調節が、推奨されてよい。ＨＴＴＰライブストリーミング（ＨＬＳ）コンテンツは、ＨＬＳメディアプレゼンテーション記述（．ｍ３ｕ８）をＤＡＳＨ ＭＰＤに変換することによって、このプロファイル１６０６と統合されてもよい。

ＭＰＥＧ−２ＴＳシンプルプロファイル１６０８は、ＭＰＥＧ−２ＴＳメインプロファイル１６０６のサブセットであってよい。それは、シームレスな切り替えのシンプルな実装を可能にするために、コンテンツのエンコーディングおよび多重化に、より多くの制限を課してもよい。シームレスなスイッチングは、ＩＳＯ／ＩＥＣ１３８１８−１（ＭＰＥＧ−２システム）に準拠するメディアエンジンが、同一の適応セット内の任意のレプリゼンテーションからの連続するセグメントを連結する（concatenate）ことによって生成されたあらゆるビットストリームを再生することを保証することによって、達成されてもよい。フルプロファイル１６１０は、ＩＳＯベースメディアファイルフォーマットメインプロファイル１６００およびＭＰＥＧ−２ＴＳメインプロファイル１６０６のスーパーセットであってよい。

図１７は、ブロックベースのビデオエンコーダ、例えば、ハイブリッドビデオエンコーディングシステムの例を示すブロック図である。入力ビデオ信号１７０２は、ブロックごとに処理されてよい。ビデオブロックユニットは、１６×１６画素を含んでもよい。そのようなブロックユニットは、マクロブロック（ＭＢ）と称されてもよい。高効率ビデオコーディング（ＨＥＶＣ）において、拡大されたブロックサイズ（例えば、「コーディングユニット」またはＣＵと称されてもよい）が使用されて、高分解能（例えば、１０８０ｐ以上）ビデオ信号を効率的に圧縮することができる。ＨＥＶＣにおいて、ＣＵは、最大６４×６４画素（up to 64x64）であってもよい。ＣＵは、別々の予測方法を適用することができる予測ユニット（ＰＵ）に区分されてもよい。

入力ビデオブロック（例えば、ＭＢまたはＣＵ）に対し、空間予測１７６０および／または時間予測１７６２が実行されてもよい。空間予測（例えば、「イントラ予測」）は、同一のビデオピクチャ／スライスにおける既にコーディングされた近傍ブロックからの画素を使用して、現在のビデオブロックを予測してもよい。空間予測は、ビデオ信号における本来の空間冗長性を削減することができる。時間予測（例えば、「インター予測」または「動き補償予測」）は、既にコーディングされたビデオピクチャ（例えば、「参照ピクチャ」と称されてもよい）からの画素を使用して、現在のビデオブロックを予測してもよい。時間予測は、ビデオ信号における本来の時間冗長性を削減することができる。ビデオブロックに対する時間予測信号は、参照ピクチャにおいて現在のブロックとその予測ブロックとの間の動きの量および／または方向を示すことができる、１または複数の動きベクトルによってシグナリングされてもよい。（例えば、Ｈ．２６４／ＡＶＣおよび／またはＨＥＶＣの場合に当てはまることがあるように）多数の参照ピクチャがサポートされる場合、ビデオブロックごとに、その参照ピクチャインデックスが追加的に送信されてもよい。参照インデックスが使用されて、時間予測信号が参照ピクチャストア１７６４（例えば「デコーディングされたピクチャバッファ」またはＤＰＢと称されてもよい）におけるどの参照ピクチャからであるかを識別してもよい。

空間および／または時間予測の後で、エンコーダにおけるモード決定ブロック１７８０は、予測モードを選択してもよい。予測ブロックは、現在のビデオブロック１７１６から減算されてもよい。予測残差は、変換（１７０４）および／または量子化（１７０６）されてもよい。量子化された残差係数は、逆量子化（１７１０）および／または逆変換（１７１２）されて、再構築された残差を形成してもよく、それが予測ブロック１７２６に再度、追加されて、再構築されたビデオブロックを形成してもよい。

限定はされないが、デブロッキングフィルタ、サンプル適応オフセット、および／または適応ループフィルタなどのインループフィルタリングは、それが参照ピクチャストア１７６４に入れられ、および／または、未来のビデオブロックをコード化するために使用される前に、再構築されたビデオブロックに適用されてもよい（１７６６）。出力ビデオビットストリーム１７２０を形成するために、コーディングモード（例えば、インター予測モードまたはイントラ予測モード）、予測モード情報、動き情報、および／または量子化された残差係数が、圧縮および／またはパッキングされるためにエントロピーコーディングユニット１７０８に送信されて、ビットストリームを形成してもよい。

図１８は、ブロックベースのビデオデコーダの例を示すブロック図である。ビデオビットストリーム１８０２は、エントロピデコーディングユニット１８０８で、アンパックおよび／またはエントロピデコーディングされてもよい。コーディングモード、および／または予測情報は、空間予測ユニット１８６０（例えば、イントラコード化される場合）、および／または時間予測ユニット１８６２（例えば、インターコード化される場合）に送信されて、予測ブロックを形成してもよい。インターコード化される場合、予測情報は、予測ブロックサイズ、１もしくは複数の動きベクトル（例えば、動きの方向および量を示すことができる）、ならびに／または、１もしくは複数の参照インデックス（例えば、どの参照ピクチャから予測信号が取得されることになるかを示すことができる）を含んでもよい。

動き補償予測は、時間予測ユニット１８６２によって適用されて、時間予測ブロックを形成してもよい。残差変換係数が、逆量子化ユニット１８１０および逆変換ユニット１８１２に送信されて、残差ブロックを再構築してもよい。予測ブロックおよび残差ブロックは、１８２６で一緒に追加されてもよい。再構築されたブロックは、それが参照ピクチャストア１８６４に記憶される前に、インループフィルタリングを通過してもよい。参照ピクチャストア１８６４における再構築されたビデオは、ディスプレイデバイスを駆動するために使用されてもよい、および／または未来のビデオブロックを予測するために使用されてもよい。

単一レイヤのビデオエンコーダは、単一ビデオシーケンス入力を取り、単一レイヤのデコーダに送信される単一の圧縮されたビットストリームを生成してもよい。ビデオコーデックは、デジタルビデオサービス（例えば、限定はされないが、衛星、ケーブル、および地上送信チャネル上でＴＶ信号を送信することなど）のために、設計されてもよい。異機種環境において展開されるビデオ中心の（centric）アプリケーションで、マルチレイヤのビデオコーディング技術が、ビデオコーディング標準の拡張として展開されて、さまざまなアプリケーションを有効にすることができる。例えば、スケーラブルなビデオコーディング技術が設計されて、２以上のビデオレイヤを取り扱うことができ、そこでは、各レイヤがデコーディングされて、特定の空間分解能、時間分解能、忠実度、および／またはビュー（view）のビデオ信号を再構築してもよい。本明細書で説明される概念のいずれも、例えば、図１７および図１８を参照して説明されるエンコーダおよび／またはデコーダによって実行されてもよい。さらに、単一レイヤのエンコーダおよびデコーダが図１７および図１８を参照して説明されるが、本明細書で説明される概念は、例えば、マルチレイヤまたはスケーラブルなコーディング技術のためのマルチレイヤのエンコーダおよびデコーダを利用してもよい。

上で説明されたプロセスは、コンピュータおよび／またはプロセッサによる実行のためのコンピュータ可読メディアに組み込まれた、コンピュータプログラム、ソフトウェア、および／またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、（有線および／もしくは無線接続上で送信される）電子信号、ならびに／またはコンピュータ可読記憶媒体を含むが、限定はされない。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、限定はされないが内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、磁気光学媒体、ならびに／または、ＣＤ−ＲＯＭディスク、および／もしくはデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、それらに限定はされない。ソフトウェアと関連してプロセッサが使用されて、ＷＴＲＵ、ユーザ装置（ＵＥ）、端末、基地局、ＲＮＣ、および／または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装してもよい。

Claims (14)

1. 無線送信／受信ユニット（ＷＴＲＵ）におけるＨＴＴＰを通じた動的適応ストリーミング（ＤＡＳＨ）コンテンツ切り替えの方法であって、
   前記ＷＴＲＵにおいて、マルチメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルを受信するステップであって、前記ＭＰＤファイルは、複数のストリームとしてエンコードされたコンテンツセグメントに関するビデオ品質メトリック値、および前記ビデオ品質メトリック値の記述を示し、前記コンテンツセグメントは、レプレゼンテーションの一部を形成し、前記ビデオ品質メトリック値は、前記コンテンツセグメントのビデオ品質の絶対的な測定を含み、前記ビデオ品質の前記絶対的な測定は、ピーク信号対雑音比（ＰＳＮＲ）、構造的類似性（ＳＳＩＭ：structural similarity）、ビデオ品質メトリック（ＶＱＭ）、視覚情報忠実度（ＶＩＦ：visual information fidelity）、Ｊ．３４１、または平均オピニオンスコア（ＭＯＳ：mean opinion score）のうちの少なくとも１つを含む、ステップと、
   前記ＷＴＲＵによって、一定ビットレートエンコーディングまたは一定品質エンコーディングのうちの１つに基づいている、前記複数のストリームの前記コンテンツセグメントに関連付けられたそれぞれのビットレートおよびビデオ品質メトリック値に基づいて、前記コンテンツセグメントを選択するステップと、
   前記ＷＴＲＵから、前記選択されたコンテンツセグメントについての要求を送信するステップと、
   前記ＷＴＲＵにおいて、前記選択されたコンテンツセグメントについての前記要求に基づいた、前記選択されたコンテンツセグメントを受信するステップと
   を備えたことを特徴とする方法。
2. 前記コンテンツセグメントを選択するステップは、前に受信されたストリームのビットレートよりも低いビットレートを有し、および少なくとも閾値レベルである前記ストリームに関連付けられたビデオ品質メトリック値を有する、前記コンテンツセグメントを選択するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記ビデオ品質メトリック値は、前記ＭＰＤファイルの１つまたは複数のタグに記憶されることを特徴とする請求項１に記載の方法。
4. 前記ビデオ品質メトリック値は、セグメントインデックスファイルに記憶されることを特徴とする請求項１に記載の方法。
5. 前記セグメントインデックスファイルは、ＭＰ４ファイルまたはＭ４Ｓファイルのうちの少なくとも１つを含むことを特徴とする請求項４に記載の方法。
6. 前記セグメントインデックスファイルは、少なくとも１つのボックスを含む、ＩＳＯＢＭＦＦベースのファイルコンテナを含み、および、セグメント品質パラメータは、前記ＩＳＯＢＭＦＦベースのファイルコンテナの前記少なくとも１つのボックス内に含まれることを特徴とする請求項４に記載の方法。
7. 前記ビデオ品質メトリック値は、前記マルチメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルにおけるフラグを介して、前記ＷＴＲＵにシグナリングされることを特徴とする請求項４に記載の方法。
8. 前記ＭＰＤファイルは、前記ＭＰＤファイルにおける適応セットに関連付けられていることを特徴とする請求項１に記載の方法。
9. 無線送信／受信ユニット（ＷＴＲＵ）におけるコンテンツ切り替えの方法であって、
   前記ＷＴＲＵにおいて、マルチメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルを受信するステップであって、前記ＭＰＤファイルは、複数のストリームとしてエンコードされたコンテンツサブセグメントに関するビデオ品質メトリック値、および前記ビデオ品質メトリック値の記述を示し、前記コンテンツサブセグメントは、レプレゼンテーションの一部を形成するコンテンツセグメントの一部を形成し、前記ビデオ品質メトリック値は、前記コンテンツサブセグメントのビデオ品質の絶対的な測定を含み、前記ビデオ品質の前記絶対的な測定は、ピーク信号対雑音比（ＰＳＮＲ）、構造的類似性（ＳＳＩＭ：structural similarity）、ビデオ品質メトリック（ＶＱＭ）、視覚情報忠実度（ＶＩＦ：visual information fidelity）、Ｊ．３４１、または平均オピニオンスコア（ＭＯＳ：mean opinion score）のうちの少なくとも１つを含む、ステップと、
   一定ビットレートエンコーディングまたは一定品質エンコーディングのうちの１つに基づいている、前記複数のストリームの前記コンテンツサブセグメントに関連付けられたそれぞれのビットレートおよびビデオ品質メトリック値に基づいて、前記コンテンツサブセグメントを選択するステップと、
   前記選択されたコンテンツサブセグメントについての要求を送信するステップと、
   前記選択されたコンテンツサブセグメントについての前記要求に基づいた、前記選択されたコンテンツサブセグメントを受信するステップと
   を備えたことを特徴とする方法。
10. 前記コンテンツサブセグメントを選択するステップは、前に受信されたストリームのビットレートよりも低いビットレートを有し、および少なくとも閾値レベルである前記ストリームに関連付けられたビデオ品質メトリック値を有する、前記コンテンツサブセグメントを選択するステップを含むことを特徴とする請求項９に記載の方法。
11. 前記ビデオ品質メトリック値は、前記ＭＰＤファイルのうちの１または複数のタグに記憶されることを特徴とする請求項９に記載の方法。
12. 前記ＭＰＤファイルは、前記ＭＰＤファイルにおける適応セットに関連付けられていることを特徴とする請求項９に記載の方法。
13. 無線送信／受信ユニット（ＷＴＲＵ）におけるＨＴＴＰを通じた動的適応ストリーミング（ＤＡＳＨ）品質ドリブン切り替えの方法であって、
    前記ＷＴＲＵにおいて、第１のビットレートで、ビデオコンテンツの第１のストリームを受信するステップであって、前記第１のストリームは、少なくとも閾値レベルであるビデオ品質を有している、ステップと、
    前記ＷＴＲＵにおいて、マルチメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルを受信するステップであって、前記ＭＰＤファイルは、前記第１のストリームのレプレゼンテーションのセグメントに関するビデオ品質メトリック値、および前記ビデオ品質メトリック値の記述を含み、前記ビデオ品質メトリック値は、前記セグメントのビデオ品質の絶対的な測定を含み、前記ビデオ品質メトリック値の前記絶対的な測定は、ピーク信号対雑音比（ＰＳＮＲ）、構造的類似性（ＳＳＩＭ：structural similarity）、ビデオ品質メトリック（ＶＱＭ）、視覚情報忠実度（ＶＩＦ：visual information fidelity）、Ｊ．３４１、または平均オピニオンスコア（ＭＯＳ：mean opinion score）のうちの少なくとも１つを含む、ステップと、
    前記ＷＴＲＵにおいて、第２のビットレートで、前記第１のストリームに続く前記ビデオコンテンツのストリームを受信するステップと、
    一定ビットレートエンコーディングまたは一定品質エンコーディングのうちの１つに基づいている、前記受信されたビデオ品質メトリック値に基づいて、前記ストリームの中で第２のストリームのセグメントを決定するステップであって、前記第２のビットレートは、前記第１のビットレートよりも低く、および、前記第２のストリームは、少なくとも前記閾値レベルであるビデオ品質を有している、ステップと
    を備えたことを特徴とする方法。
14. 前記ビデオ品質メトリック値は、前記セグメントのサブセグメントに関連することを特徴とする請求項１３に記載の方法。