(57)【特許請求の範囲】
【請求項１】
メディア・コンテンツ・アイテムの少なくとも２つのレプレゼンテーションが利用可能なメディア・ストリーミング・システムにおいて使用される装置（５００、６００）であって、
ストリーミング・アプリケーションによって使用される、前記メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するように構成されるプロセッサ（５０４、６０４）を備え、
前記プロセッサは、前記ストリーミング・アプリケーションによって使用される新たなセグメントと関連する処理能力の変更を信号伝達する第１の関数を実行するように構成され、
前記新たなセグメントは、前のセグメントとは異なるレプレゼンテーションに対応し、
前記第１の関数の第１の引数は、前記新たなセグメントの新たな処理能力であり、
前記第１の関数の第２の引数は、使用される前記新たなセグメントの位置情報であり、
前記プロセッサは、さらに、（１）前のセグメントとは異なるコンテンツのレプレゼンテーションに対応する、再生される新たなセグメントと、（２）ともに再生される一連のダウンロード・セグメントである、前記新たなセグメントを含む新たな期間と、に関連して、処理能力の変更を信号伝達する第２の関数を前記新たな期間として再生されるダウンロードセグメントの新たなリストを受信した直後に実行することを特徴とする装置。
【請求項２】
前記プロセッサは、第１の関数が実行されると、イベントを生成するように構成されることを特徴とする請求項１に記載の装置。
【請求項３】
前記第２の関数の第１の引数は、前記新たな期間の前記セグメントに関連する処理能力のリストであり、
前記第２の関数の第２の引数は、前記新たなセグメントが再生される位置情報を示すことを特徴とする請求項１に記載の装置。
【請求項４】
前記プロセッサは、さらに、前記第２の関数が実行されると、イベントを生成するように構成されることを特徴とする請求項１に記載の装置。
【請求項５】
前記プロセッサは、さらに、前記コンテンツの利用可能な代替のレプレゼンテーションに対応する計算された処理能力のリストを提供するように構成されることを特徴とする請求項１に記載の装置。
【請求項６】
前記プロセッサは、さらに、再生しながら、提示される選択されたレプレゼンテーションに対する処理能力を提供するように構成されることを特徴とする請求項１に記載の装置。
【請求項７】
前記プロセッサは、提示されるレプレゼンテーションに対する最大処理能力を提供するようにさらに構成されることを特徴とする請求項１に記載の装置。
【請求項８】
前記プロセッサは、提示されるレプレゼンテーションに対する設定された最小処理能力を提供するようにさらに構成されることを特徴とする請求項１に記載の装置。
【請求項９】
現在のプレゼンテーション方法の変更を要求するために、ブール値を返す手続きを実行するように構成されることを特徴とする請求項１に記載の装置。
【請求項１０】
前記現在のプレゼンテーション方法の変更が成功すると、前記返されるブール値は”ｔｒｕｅ”であることを特徴とする請求項９に記載の装置。
【請求項１１】
前記手続きの第１の引数は最大許容処理能力であり、前記第２の引数は最小許容処理能力であり、
前記要求は、前記最大許容処理能力と前記最小許容処理能力の間を維持するレプレゼンテーションに利用可能なレプレゼンテーションを制限することを特徴とする請求項９に記載の装置。
【請求項１２】
前記最大許容処理能力が前記最小許容処理能力よりも大きくない場合、前記返されるブール値は”ｆａｌｓｅ”であることを特徴とする請求項１１に記載の装置。
【請求項１３】
前記プロセッサは、前記コンテンツの利用可能な代替のレプレゼンテーションに対応する計算された処理能力のリストを提供するようにさらに構成され、
前記利用可能なレプレゼンテーションが前記最小許容処理能力と前記最大許容処理能力との間の範囲にない場合には、前記返されるブール値は”ｆａｌｓｅ”であることを特徴とする請求項１１に記載の装置。
【請求項１４】
前記第１の引数又は前記第２の引数が指定されない場合、前記要求は、前記最小許容処理能力を上回るか、又は、前記最大許容処理能力を下回るレプレゼンテーションに、利用可能なレプレゼンテーションを限定することを特徴とする請求項１１に記載の装置。
【請求項１５】
前記プロセッサは、ＯＩＰＦドキュメントの２０１０年１０月発行のバージョン２によって定義されるような環境で動作するように構成されることを特徴とする請求項１に記載の装置。
【請求項１６】
少なくとも２つのメディア・コンテンツ・アイテムが利用可能なストリーミング・システムにおいてストリーミング・アプリケーションと通信においてプロセッサによって実行される方法（８００）であって、
前記ストリーミング・アプリケーションによって使用される、前記メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するステップ（Ｓ８１０）と、
前記生成した信号を前記ストリーミング・アプリケーションへ送信するステップ（Ｓ８２０）と
を含み、
信号を生成する前記ステップは、前記ストリーミング・アプリケーションによって使用される新たなセグメントと関連する処理能力の変更を信号伝達する第１の関数を実行し、
前記新たなセグメントは、前のセグメントとは異なるレプレゼンテーションに対応し、
前記第１の関数の第１の引数は、前記新たなセグメントの新たな処理能力であり、
前記第１の関数の第２の引数は、使用される前記新たなセグメントの位置情報であり、
前記プロセッサは、さらに、（１）前のセグメントとは異なるコンテンツのレプレゼンテーションに対応する、再生される新たなセグメントと、（２）ともに再生される一連のダウンロード・セグメントである、前記新たなセグメントを含む新たな期間と、に関連して、処理能力の変更を信号伝達する第２の関数を前記新たな期間として再生されるダウンロードセグメントの新たなリストを受信した直後に実行することを特徴とする方法。
【請求項１７】
プロセッサに方法（８００）を実行させるための、該プロセッサで実行可能なコードを一時的ではなく記憶するコンピュータで読取可能な記憶媒体（３４０）であって、
ストリーミング・アプリケーションによって使用される、メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するステップ（Ｓ８１０）と、
前記生成した信号を前記ストリーミング・アプリケーションへ送信するステップ（Ｓ８２０）と
を含み、
信号を生成する前記ステップは、前記ストリーミング・アプリケーションによって使用される新たなセグメントと関連する処理能力の変更を信号伝達する第１の関数を実行し、
前記新たなセグメントは、前のセグメントとは異なるレプレゼンテーションに対応し、
前記第１の関数の第１の引数は、前記新たなセグメントの新たな処理能力であり、
前記第１の関数の第２の引数は、使用される前記新たなセグメントの位置情報であり、
前記プロセッサは、さらに、（１）前のセグメントとは異なるコンテンツのレプレゼンテーションに対応する、再生される新たなセグメントと、（２）ともに再生される一連のダウンロード・セグメントである、前記新たなセグメントを含む新たな期間と、に関連して、処理能力の変更を信号伝達する第２の関数を前記新たな期間として再生されるダウンロードセグメントの新たなリストを受信した直後に実行することを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にストリームコンテンツのセグメントのレプレゼンテーションの変更に関連する情報をクライアントに提供するために使用される方法及び装置に関連するものである。
【背景技術】
【０００２】
メディア、特に動画のハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミングは、最近、アダプタビリティ及びライブコンテンツを可能にするシンプル・プログレッシブ・ダウンロードを上回る発展をしている。動画をインターネットで閲覧するのに現在有力な方法であるプログレッシブ・ダウンロードにおいては、クライアントコンピュータ又はソフトウェアアプリケーションは、サーバによって管理されている大きなファイルをダウンロード（フェッチ）し、ダウンロードと並行でダウンロードしたコンテンツを再生する。ＨＴＴＰストリーミングは、メディアコンテンツ（即ち、ファイル）を、コンテンツの小さい時間間隔（例えば、コンテンツ再生の１０秒）にそれぞれが対応する複数のセグメントに分割することに基づいている。クライアントには、複数のセグメントのリストを含むマニフェストファイルと、どこからダウンロードしたかを示す情報（例えば、ＵＲＬアドレス）とともに提供され、これにより、クライアントはセグメントごとにダウンロードすることができる。
【０００３】
ＨＴＴＰストリーミングの一例は、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって、例えば、３ＧＰＰ技術仕様書（ＴＳ）２６．２３４及び３ＧＰＰ  ＴＳ２６．２４４の現行のバージョンにおいて定義されている適応ＨＴＴＰストリーミングである。３ＧＰＰ適応ＨＴＴＰストリーミングのカウンタパートは、バージョン２．０仕様書のオープン・インターネット・プロトコル・テレビジョン・フォーラム（ＯＩＰＦ）の現行のバージョンで定義されている。
【０００４】
上記指定されたプロトコルが実行されるシステムのアーキテクチャが、例えば、３ＧＰＰ  ＴＳ２３．２２８  Ｖ８．４．０、ＩＰマルチメディアサブシステム（ＩＭＳ）ステージ２（リリース８）２００８年３月と、ＴＳ２３．２２８の他の現行バージョンとして定義されている。ＩＭＳは、Ｒ．Ｎｏｌｄｕｓ等”ＩＭＳネットワークにおけるマルチアクセス”、エリクソン監修、Ｎｏ．２、８１−８６ページ（２００８）、Ｕ．Ｏｌｓｓｏｎ等”通信サービス−ＩＭＳサービス成長への鍵”、エリクソン監修、Ｎｏ．１、８−１３ページ（２００８）、Ｐ．Ａｒｂｅｒｇ等”ＩＰＴＶ用のネットワーク・インフラストラクチャ”、エリクソン監修、Ｎｏ．３、７９−８３（２００７）において説明されている。ＩＭＳベースのＩＰＴＶへのアプローチは、Ｍ．Ｃｅｄｅｒｅｖａｌｌ等”オープンＩＰＴＶフォーラム−オープンＩＰＴＶスタンダードへ”、エリクソン監修、Ｎｏ．３、７４−７８ページ、及び、Ｔ．Ｃａｇｅｎｉｕｓ等”ＴＶエクスペリエンスの発展：いつでも、どこでも、どの装置でも”エリクソン監修、Ｎｏ．３、１０７−１１１ページ（２００６）に説明されている。
【０００５】
モバイル電話機、セットトップボックス（ＳＴＢ）、ＳＴＢ機能を有するＴＶなどのユーザ機器（ＵＥ）は、多くの方法、有線（イーサネット、ケーブルモデム、デジタル加入者ライン等）、無線（３ＧＰＰ仕様のセルラ無線機、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６等）の両方でＩＭＳを通じてオファーされたサービスへアクセスすることができる。一般に、ＩＰＴＶは、一連のＩＰデータパケットとして符号化されるマルチメディアストリームを受信して表示するシステムに対して使用される用語である。そのようなシステムにおけるＩＰＴＶシステム及びメディアブックマークは、Ｎ．Ｍｉｔｒａ等によって特許文献１に説明されている。
【０００６】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）及びリアルタイム・トランスポート・プロトコル（ＲＴＰ）などのプロトコルに基づくストリーミングサーバとは対照的に、上述したストリーミング・コンテンツのＩＰＴＶ方法において、スタンダード・ウェブ・プロトコル（ＨＴＴＰなどの）を介してダウンロードされた大きなコンテンツファイルは、異なる複数のセグメント／ファイルへ分割される。このタイプのプロトコルは、サーバにおける特定の状態又はキャッシュが必要とされるため、”キャッシュフレンドリ”、又は、コンテンツ分散ネットワーク（ＣＤＮ）フレンドリと考えられている。これらの方法は、時間間隔やセグメントにおける変更を許容することによってフレキシビリティを強化している。例えば、広告セグメントは、１期間（３ＧＰＰ仕様書において”ピリオド（ｐｅｒｉｏｄ）”と称される。）の間にコンテンツを変更することによって挿入され、その後、次のインターバルでマニフェストファイルに従ってレギュラーコンテンツに返される。
【０００７】
また、適応は、時間間隔におけるコンテンツの複数のバージョン（３ＧＰＰ仕様書において”レプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）”と称される。）を提供することによって達成され、これにより、クライアントはクライアントのリソース（所定のネットワーク性能／ダウンロード時間）及びプレファランスに最も適したバージョンをダウンロードするように選択することができる。さらに、国際公開第２０１０／１１１２６１号パンフレットは動的な速度適応を行うストリーミング・メディア・システムを開示している。
【０００８】
ここで説明するメディアプレイヤは、フルスクリーンプレイヤか、又は、例えば新ＨＴＭＬ５ビデオ要素を用いるアプリケーション若しくはブラウザに実装されるかのいずれでもよい。アプリケーション・プログラム・インタフェース（ＡＰＩ）はネイティブＡＰＩ又はＪａｖａｓｃｒｉｐｔＡＰＩの何れであってもよい。
【０００９】
従来のシステムにおいて、クライアントは、複数の機能のセットと、ダウンロードやダウンロードしたメディアの再生に関連する変数とを含むインタフェースからの情報を受信する。ＯＩＰＦバージョン２、ｖｏｌ．５、セクション７．１４．９において、以下のプロパティ及び方法が、ＣＥＡ−２０１４−Ａの現行バージョンのセクション５．７．１に定義されるように音声及び動画オブジェクトでサポートされている。
＜function OnReadyToPlay（）＞
当該ファンクションは現在の再生位置の後の再生を開始／継続するために十分な量（ＯＩＴＦによって決定される）のメディアがバッファされると呼び出される。
当該ファンクションは引数なしで呼び出される。
このイベントは、状態４（バッファリング）と状態１（再生）との間の状態移行が発生したときに生成される（ＳＨＡＬＬ）。当該イベントはまた、状態２（停止）中に、再生を開始するのに十分なデータがバッファリングされると生成される（ＳＨＡＬＬ）。
【００１０】
ここでＯＩＴＦは、ＩＰＴＶサービスをオファーするネットワーク内に存在するブロックとしてファンクション・アーキテクチャ仕様書に定義されている。ＯＩＴＦは、ネットワークにおいてＩＰＴＶサービスにアクセスするために必要となる機能を提供する。ＯＩＰＦ、バージョン２、ｖｏｌ．５、セクション７．１４．９から生成されたこれらの定義において、大文字で記載された用語（例えば、ＳＨＡＬＬ）は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）（インターネット及びインターネット接続システムの作業に適用可能なメソッド、動作、リサーチ、イノベイションを説明する。）によって１９９７年３月に発行されたＲＦＣ２１１９”要件レベルを示すＲＦＣに使用されるキーワード”に従って解釈される。ＯＩＰＦ、バージョン２、ｖｏｌ．５、セクション７．１４．９のプロパティ及びメソッド法の説明は、以下に続ける。
＜Boolean  readyToPlay＞
当該プロパティは、現在の再生位置の後の再生を開始／継続するために十分な量（ＯＩＴＦによって決定される）のメディアがバッファされたか否かを検査するために使用される。
十分なデータがバッファされていればｔｒｕｅが返される。十分なデータがバッファされていなければｆａｌｓｅが返される。
＜Integer getAvailablePlayTime(Boolean  fromPlayPosition)＞
説明：どのくらいの量のコンテンツが再生可能かを返す。
引数ｆｒｏｍＰｌａｙＰｏｓｉｔｉｏｎがｖａｌｕｅ  ｔｒｕｅであれば、当該メソッドは、現在の再生位置の後に再生するためのバッファにおいて利用可能なミリ秒でのデータ量を返す。
引数ｆｒｏｍＰｌａｙＰｏｓｉｔｉｏｎがｖａｌｕｅ  ｆａｌｓｅであれば、当該メソッドは、ミリ秒でのトータルのバッファ長（即ち、現在の再生位置の前後におけるバッファ内の利用可能な全てのデータを含む。）を返す。
引数：ｆｒｏｍＰｌａｙＰｏｓｉｔｉｏｎは、利用可能な再生時間が、現在の再生位置から計算されたか、又は、バッファの開始位置から計算されたかを示す。
＜Boolean setBuffferingStrategy(String name)＞
説明：バッファリング方法（ストラテジー）を変更するリクエスト。引数名称として有効な値を以下に示す：
”ｓｕｓｔａｉｎｅｄ＿ｐｌａｙｂａｃｋ”：これはデフォルトの方法を示す。ここで、着信ビデオストリームは、できる限りデータのバッファリングエラー又はロスト・フレームを抑えて格納される。これは、ｏｎＲｅａｄｙＴｏＰｌａｙイベントをトリガとするバッファリング閾値がネットワーク・スループットの変化に対応する十分な大きさに選択されることを意味する。
”ｌｏｗ＿ｌａｔｅｎｃｙ”：これは、着信ビデオストリームがコンテンツの受信とコンテンツの実際の再生との間の遅延を可能な限り抑えてバッファリングされる方法である。これは、ｏｎＲｅａｄｙＴｏＰｌａｙイベントをトリガとするバッファリング閾値がコンテンツ受信後に可能な限りすぐに当該コンテンツを再生するためにバッファ領域が十分に小さくされていることを意味する。
当該メソッドが呼ばれない場合のデフォルト方法は”ｓｕｓｔａｉｎｅｄ＿ｐｌａｙｂａｃｋ”となる。
当該メソッドは、再生状態１（再生）を含む、任意の再生状態中に呼ばれる。
当該メソッドは、バッファリング方法が所望のバッファリング方法へ変更されると、ｔｒｕｅを返す。バッファリング方法の変更が失敗すると、当該メソッドは、ｆａｌｓｅを返す。
ＯＩＴＦが２つのモード間で区別されない場合は当該メソッドはｆａｌｓｅを返す。
【００１１】
さらに、ｏｎＲｅａｄｙＴｏＰｌａｙイベントが実行されると、対応ドキュメント・オブジェクト・レベル２イベントＳＨＡＬＬ（worldwise web consortium-w3c-currentドキュメントで定義される）が以下の方法で生成される。
＜Intrinsicイベント＞  ＜対応DOM2イベント＞  ＜DOM2イベントプロパティ＞
onReadyToPlay         ReadyToPlay           Bubbles:No
Cancelable:No
Context  info:None。
【００１２】
これらのＤＯＭ２エベント（Ｗ３Ｃ”ドキュメント・オブジェクト・モデル（ＤＯＭ）レベル２イベント”、バージョン１、２０００で定義される）は、イベントターゲットに直接送られ、バブルやキャプチャは行われない。アプリケーションはバブリングフェーズやキャプチャリングフェーズ中にそれらのイベントを受信するべきでない。ＤＯＭ２イベントハンドラＳＨＡＬＬを使用するアプリケーションは、ＣＥＡ−２０１４Ａ／Ｖコントロールオブジェクト上で、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（）メソッド（Ｗ３Ｃ”スケーラブル・ベクタ・グラフィック・タイニー１．２仕様書”の現行のバージョンで説明される。）を呼び出す。ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒの第３パラメータ（即ち、”ｕｓｅｒＣａｐｔｕｒｅ”）は無視される。
【００１３】
プログレッシブ・ダウンロードを使用するいくつかのメディアプレイヤ（例えば、一般的なＹｏｕＴｕｂｅプレイヤ）は、現在の再生時間ポイント有するタイムラインと、どのくらいのコンテンツがダウンロードされたか（つまり、バファリングされた）を示すバッファリング・ポイントを有する進捗バーとを表示する。タイムライン及び進捗バーが同等の時間を示す場合は重なって表示されうる。メディアプレイヤは一般的に所定量のコンテンツがダウンロードされれバッファリングされた後にコンテンツの再生を開始する。その後、プレイヤは、コンテンツを再生しつつ並行でダウンロードを継続する。現在の再生時間ポイントがバッファリング・ポイントに到達すると（即ち、ダウンロードされた全てのコンテンツが再生されると）、プレイヤは、十分な量のコンテンツ（例えば、数秒の量の再生コンテンツ）がダウンロードされバッファリングされるまで中断する。タイムラインと進捗バーが表示されるときに視覚的に認識可能なこのような状況は従来のメディアプレイヤにおいてよく知られた課題である。
【００１４】
既存の適用ストリーミング・ソリューションは、中断のない再生エクスペリエンスを提供する一方で、ネットワーク性能が変化すれば、品質も変化する。これらの適応ストリーミング・ソリューションは、スポーツイベントなどのライブコンテンツ用のプログレッシブ・ダウンロードと代えるためによく使用される。さらに、モバイルデバイス用のサードパーティアプリケーションは、コンテンツがライブであるか否かに関係なく、所定期間（例えば、１０分）より長い全ての動画コンテンツに対して適応ストリーミング・ソリューションを使用する。
【００１５】
従来のマルチメディア・プレイヤは、中断が無く、一定の品質を維持するストリーミングを提供することができない。図１は、従来のシステムにおける再生処理能力（即ち、時間間隔ごとの処理能力）の段階的な変化を示す図である。図１においてデータはｔ＝０からｔ１と記載されたタイミングまでバッファリングされる。再生処理能力データの多くの変化が図１に示すようにｔ２、ｔ３、ｔ４等で発生している。
【００１６】
しかし、とりわけビデオ・オン・デマンドにおいては、エンドユーザ（視聴者）又はアプリケーション開発者は、品質は変化しないもののあまり長いデータはバッファリングされないプログレッシブ・ダウンロードのユーザエクスペリエンスを望んでいる。
【００１７】
さらに、エンドユーザ／開発者は、（従来のマルチメディアプレイヤでは提供されていない）ビットレートでの上限（処理能力）を設定できることを望んでおり、特に、エンドユーザがトラフィック量に依存してトラフィック料を支払う場合に望まれている。
【００１８】
従来のメディアプレイヤによって提供されないその他の要望される機能は、現在のメディアプレイヤの品質（処理能力又はビットレート）の指標を提供している。例えば、コンテンツに重なり、現在のビットレート（又は処理能力）を示すビットレート（又は、処理能力）メータのプレゼンス及びその段階的な変化は、エンドユーザに、品質の変化がネットワークの変化に起因する場合やメディアプレイヤ又はサーバ固有の問題に起因する場合を理解させることができる。ダウンロード及び再生の少なくとも一方に関連する情報と制御はより安定したユーザエクスペリエンスを導き、有料サービスには非常に重要なことである。
【００１９】
したがって、上述した問題や従来のメディアプレイヤの欠点を克服する方法及び装置が提供されることが望まれている。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】国際公開第２０１０／０１６８３６号
【発明の概要】
【発明が解決しようとする課題】
【００２１】
本発明は、上述の問題に鑑みて成されたものであり、その目的は処理能力の制御が可能なメディアプレイヤ又はダウンロードマネージャ（即ち、制御サーバ）に実装される装置を提供し、これにより、メディア・ストリーミング・システムの少なくとも２つのレプリゼンテイションでメディアコンテンツアイテムをストリーミングする際の品質又は処理能力／品質範囲を提供する。これは、プログレッシブ・ダウンロードと代えられる適応ストリーミング・ソリューションを使用することを可能にする。ストリーミングに使用されるセグメントの処理能力／品質が変化する際に、信号を生成する（即ち、イベントを提供する）ことによって、より安定した視聴エクスペリエンスをエンドユーザに与えることができる。
【課題を解決するための手段】
【００２２】
一実施例によれば、メディア・コンテンツ・アイテムの少なくとも２つのレプレゼンテーションが利用可能なメディア・ストリーミング・システムにおいて使用される装置であって、ストリーミング・アプリケーションによって使用される、前記メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するように構成されるプロセッサを備えることを特徴とする。
【００２３】
他の実施例によれば、少なくとも２つのメディア・コンテンツ・アイテムが利用可能なストリーミング・システムにおいてストリーミング・アプリケーションと通信においてプロセッサによって実行される方法であって、前記ストリーミング・アプリケーションによって使用される、前記メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するステップと、前記生成した信号を前記ストリーミング・アプリケーションへ送信するステップとを含むことを特徴とする。
【００２４】
プロセッサに方法を実行させるための、該プロセッサで実行可能なコードを一時的ではなく記憶するコンピュータで読取可能な記憶媒体であって、前記ストリーミング・アプリケーションによって使用される、前記メディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するステップと、前記生成した信号を前記ストリーミング・アプリケーションへ送信するステップとを含むことを特徴とする。
【図面の簡単な説明】
【００２５】
明細書に添付の図面は１つ以上の実施形態を示し、対応する記載とともにそれらの実施形態を説明する。
【図１】従来の適応ストリーミング・プレイヤでストリーム・コンテンツを再生するために使用される処理能力の段階的な変化を示すグラフである。
【図２】ストリームコンテンツをダウンロードし、バッファリングして再生するために使用されるビットレート又は処理能力の段階的な変化を示すグラフである。
【図３】一実施形態に係るメディア・ストリーミング・システムの構成を示す図である。
【図４】一実施形態に係るメディア・プレイヤのための再生処理能力（即ち、時間間隔ごとの処理能力）の段階的な変化を示す図である。
【図５】一実施形態に係るユーザ機器のブロック図である。
【図６】一実施形態に係るメディア・プログラム・コンテンツを提供するＩＰＴＶアプリケーション・プラットフォーム（ＩＡＰ）又は制御サーバのブロック図である。
【図７】メディア・ストリーミング・システムに格納された異なるレプリゼンテイションを示す図である。
【図８】一実施形態に係るメディアのストリーミングに関連する情報を提供するための方法のフォローチャートである。
【発明を実施するための形態】
【００２６】
以下では、一実施形態について添付の図面を参照しながら説明する。異なる図面における同一の参照符号は、同一の又は類似の要素を示す。以下の詳細な説明は、本発明を限定する意図はない。その代り、本発明の範囲は添付の特許請求の範囲で定義される。メディアをストリーミングするための技術やシステムの構成について以下の実施形態で簡潔に説明する。しかしながら、実施形態での説明はそれらのシステムに限定するわけではなく、他の既存のシステムに適用されうる。
【００２７】
明細書を通じて参照される「一実施形態」又は「本実施形態」は、実施形態に関連して説明される特有の機能、構造、又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。このように、明細書の中で使用される「一実施形態において」又は「本実施形態において」とのフレーズは、必ずしも全てが同一の実施形態を参照していることを示しているわけではない。さらに、特有の機能、構造、又は特性は１つ以上の実施形態に任意の適切な方法で組み込まれてもよい。
【００２８】
単に図示するだけで限定を目的としない図２は、適応ＨＴＴＰストリーミング・セッション用のビットレート又は処理能力（bandwidth）の段階的な変化（即ち、時間関数として）表すグラフである。ストリーミング・セッションは、各期間が複数のセグメントを有する２つの期間、期間１、期間２を含む。再バッファリングにおけるブレイクは、複数の期間の間のみで発生する。データはまずダウンロードされ、バファリングされ（点線１００）、その後再生される（実線２００）。期間は一般的に複数のセグメントを有する。
【００２９】
期間１は、ダウンロードされ、図２のｔ＝０（プロットした時間間隔の開始位置）からｔ＝ｔ４までバファリングされる。期間２は、ダウンロードされ、ｔ４のタイミングからメディアプレイヤへのバッファリングが開始される。期間１は、ｔ１とｔ６の間で再生され、一方期間２は、ｔ６から再生が開始される。このように、データはｔ１までダウンロードとバッファリングのみが行われる。ｔ１後に期間１の再生が開始される一方で、再生されるデータのダウンロードとバッファリングは継続される。ダウンロードに使用される処理能力が再生に使用される処理能力よりも小さい場合（例えば、ｔ２とｔ３の間、ｔ５とｔ６の間）には、再生ポイントとバッファリングポイントとの距離（時間内における例えば再生のタイムラインとダウンロードの進捗バーとの重なり）が減少する。逆に言えば、ダウンロードに使用される処理能力が再生に使用される処理能力（例えば、ｔ１とｔ２の間、ｔ３とｔ５の間）よりも大きい場合、再生ポイントとダウンロードポイントとの間の距離は増加する。
【００３０】
各期間は、異なる処理能力を有し、かつ異なる複数のレプレゼンテーションに対応する、異なる時間間隔に対応する複数のセグメントを含む。同一のセグメントにおける利用可能な複数のレプレゼンテーションは、１つ以上の特徴に関して異なってもよい。例えば、複数のレプレゼンテーションは異なる処理能力を有してもよく、異なる言語に対応してもよい（英語、中国語等）。プレゼンテーション（即ち、ダウンロードされ再生される）の一部となるいずれかのレプレゼンテーションがクライアントの好み（例えば、処理能力又は言語）に基づいて決定されてもよい。
【００３１】
図２においては、ダウンロードされるコンテンツの処理能力を点線で示し、実線は再生されるコンテンツの処理能力を示す。期間１には４つの異なる処理能力が存在し（隣接するセグメントが同一の処理能力を使用する場合でも異なるセグメントに対応する）、期間２には２つの異なる処理能力が存在する。
【００３２】
図２に関連して、本実施形態に係る装置は、ＩＰＴＶアプリケーション・プラットフォームに実装されか、メディア・プログラム・コンテンツを提供するための制御サーバに実装されるか、又は、分割されたハードウェア・エンティティであってもよく、メディアプレイヤ（又は、ＩＰＴＶアプリケーション・プラットフォームで実行するストリーミング・アプリケーション）に対して、ｔ１、ｔ２、ｔ３、ｔ５、ｔ６で処理能力変更イベントを通知するか、ｔ４で期間２のダウンロードの開始を通知するかの少なくとも一方を行う。
【００３３】
図３は、一実施形態に係るメディア・ストリーミング・システム３００の構成を示す。システ３００は、有線又は無線を介したメディアプレイヤ３２０へのデータ（即ち、メディアコンテンツ）のダウンロードを管理するように構成される制御サーバ３１０を含む。例えば、制御サーバ３１０は、マニフェスト・ファイルを準備してもよい。当該データは、バッファ３３５にバッファリングされてもよく、メディアプレイヤ３２０で実行されるメディア・ストリーミング・アプリケーション３２５によって再生されてもよい。装置３３０は、ストリームデータの処理速に関連する情報を合成し、当該情報をメディア・ストリーミング・アプリケーションに通知する。ソフトウェア又はソフトウェアとハードウェアとの組み合わせから構成される装置３３０は、メディア・プレイヤ３２０、制御サーバ３１０に実装されるか、又はインターネット等のネットワークを介してデータをストリーミングするために使用されるスタンドアロンの装置であってもよい。さらに、装置３３０は、当該装置によって取り出され、かつ、当該装置がストリームデータの処理能力に関連する情報を合成するか又はメディア・ストリーミング・アプリケーション３２５に情報を通知するトリガとなるプログラム（即ち、実行可能なコード）を格納する一過性でないメモリを含むか又は接続されてもよい。
【００３４】
他の実施形態によれば、装置（例えば、図３の３３０）は、クライアントが最小の処理能力パラメータと最大の処理能力パラメータを通知することを可能にすることができる。図４は、一実施形態に係るメディア・プレイヤのための再生処理能力の段階的な変化（即ち、時間間隔ごとの処理能力）を示すグラフである。ここで、メディアプレイヤは、クライアントから受信した最初の処理能力パラメータと最大の処理能力パラメータに従って動作する。図１の状況と比較すると、ここでは安定した再生動作（即ち、最小と最大との間の狭い範囲での再生処理能力）が達成されている。利用可能な処理能力が最小と最大の範囲外となると、再バファリングによる中断（例えば、ｔ２とｔ３との間）が発生する。しかしながら、それらの再バッファリングによる中断は、より長い初期バッファリング期間によって避けられてもよい（例えば、０とｔ１との間）。ローカルに記憶する場合、又は、データが後に使用されるためにダウンロードされる場合には、品質を制御する能力は、短い初期バッファリング期間よりも非常に重要になりえる。
【００３５】
このように、様々な実施形態に係るメディアプレイヤ又はダウンロードマネージャの実施形態は、処理能力／品質変化に関連する情報を生成して使用するか、特定の処理能力内で再生するように構成するかの少なくとも一方によって、エンドユーザの視点でのエクスペリエンス安定性を強化することができる。それらの方法及び装置はモバイル無線ネットワークなどの電子通信の多くの種別に使用されうる。
【００３６】
単に図示するだけで限定を目的としない図５は、種々の実施形態に係る適応メディアストリーミングに関連する方法を実行する、モバイル電話機、セットトップボックス（ＳＴＢ）コンピュータなどのユーザ機器（ＵＥ）５００のブロック図である。ＵＥ５００は、１つ以上のＩＰＴＶネットワークエンティティと電子信号を交換するのに適したトランシーバ５０２を含む。それらの電子信号によって伝達される情報は、プロセッサ５０４によって扱われる。当該プロセッサ５０４は、上述したＵＥ５００の動作を実行するために１つ以上のサブプロセッサを含み、１つ以上のソフトウェア・モジュールと、例えばブラウザとＩＰＴＶ端末機能（ＩＴＦ）を含むアプリケーションとを実行する。ＵＥ５００へのユーザ入力は、キーパッド、リモートコントローラ、又は他のデバイス５０６を通じて提供され、ユーザへ提示する情報は、ディスプレイ５０８へ提供される。ディスプレイがタッチスクリーン機能を有している場合、ユーザ入力はディスプレイを通じて提供されうる。ソフトウェア・アプリケーションは、適切なアプリケーションメモリ５１０に格納され、ＵＥは適切なメモリ５１２に所望の情報をダウンロードするか又はキャッシュするかの少なくとも一方を行う。ＵＥ５００は、コンピュータマイクロフォンなどの他のコンポーネントをＵＥ５００へ接続するために使用されるインタフェース５１４を含んでもよい。実行可能なコードに基づき、プロセッサ５０４は、適切なレクエスト、レスポンスメッセージを形成し、それらをトランシーバ５０２を介してネットワークに送出し、ネットワークから受信されたメッセージと情報に従って実行する。そのような実行は、上述の方法を含むことができる。
【００３７】
図６は、一実施形態に係るメディア・プログラム・コンテンツを提供するＩＰＴＶアプリケーション・プラットフォーム（ＩＡＰ）６００又は制御サーバのブロック図である。ＩＡＰ６００は、１つ以上のＩＰＴＶネットワーク・エンティティと電子信号を交換するのに適したトランシーバ６０２を含む。それらの信号によって伝達される情報は、プロセッサ６０４によって扱われる。当該プロセッサ６０４は、１つ以上のサブプロセッサを含み、１つ以上のソフトウェア・モジュールと、ＩＰＡ６００の動作を実行するアプリケーションと適切なメモリ６０６と連携して実行する。ＩＰＡ６００は、ネットワークにおいてデータベースサーバとして動作するように構成される。キーパッド／ディスプレイ６０８は、通常はユーザ入力／出力には必要とされないが、そのようなインタフェースは、管理機能用に提供されうる。プロセッサ６０４によって実行されるソフトウェアアプリケーションは、適切なアプリケーションメモリ６１０に格納されてもよい。
【００３８】
種々の実施形態に係る方法は、追加的に、かつ、ＯＩＰＦ、バージョン２、ｖｏｌ．５、セクション７．１４．９に定義された、メディアコンテンツのダウンロード及び再生に関連する機能、方法、イベントとして同一の環境内で動作するように実装されうる。ＨＴＴＰ適応ストリーミングは、ストリーミング・アプリケーション（例えば、ＩＰＴＶアプリケーション・プラットフォーム）を実行する端末、又は、ダウンロード若しくは再生されるメディアコンテンツのセグメントから次にダウンロード若しくは再生されるセグメントへの移行に関連する処理能力の変更に関連する情報を構成する制御サーバによって実行されるスクリプト（例えば、Ｄｅｃｌａｒａｔｉｖｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ−ＤＡＥ−ａｐｐｌｉｃａｔｉｏｎ）用に提供される。Ｄｅｃｌａｒａｔｉｖｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｅｎｖｉｒｏｎｍｅｎｔ（ＤＡＥ）アプリケーションは、エンドユーザに情報を搬送する。追加の手順は、
・（ストリーミングが開始されるとすぐに）利用可能な再生品質のリストを可能とし、
・ストリーミング中に現在の品質及びスピード（ビットレート、処理能力）を監視し、
・プレゼンテーションの変更に基づいて品質が変化した際のイベントを監視し、
・頻繁にシフトが発生した場合に特有のレベルでの品質を固定することを可能にする。
【００３９】
メディア・ストリーミング・システムにおいて、メディア・コンテンツ・アイテムの複数のレプレゼンテーションを利用可能とすることができる。レプレゼンテーションは、図７に示されるように、異なるビットレート（又は処理能力）を有する、一時的に調整され、かつ、独立して符号化された複数のセグメントに分割され、異なる位置に格納することができる。少なくとも１つのセグメントは、ストリーミング・アプリケーションで利用可能とされる各タイム・セグメント用にダウンロードされる。例えば、レプレゼンテーション１のセグメント１、レプレゼンテーション２のセグメント２、及び、レプレゼンテーション３のセグメント３は、ストリーミング・アプリケーションによって使用される（即ち、提示されるか又は再生される。）。ストリーミング・アプリケーションは、一時的なシーケンスにおいてメディア・コンテンツ・アイテムのセグメントを使用する（例えば、再生する。）が、隣接するセグメントは異なるレプレゼンテーションに属してもよい。複数のセグメントは、期間と名付けられたグループで使用され、各期間は１つ以上のダウンロードセグメントを含む。
【００４０】
一実施形態によれば、メディア・ストリーミング・システム（図３の３００など）で使用される装置（図５の５００又は図６の６００など）は、ストリーミング・アプリケーションによって使用される（例えば、再生される）メディア・コンテンツ・アイテムの一連のセグメントにおいてレプレゼンテーションの変更が発生すると信号を生成するように構成されるプロセッサ（図５の５０４又は図６の６０４）を有する。装置は、メディアプレイヤ３２０を含んでもよく、ストリーミング・アプリケーションはプロセッサ又は他のプロセッサ上で実行されてもよい。しかしながら、当該装置は、制御サーバ３１０の一部であってもよく、中間ノードに配置されてもよい。
【００４１】
プロセッサは、使用される新たなセグメントに関連する処理能力の変更を信号伝達する（第１の）関数を実行する。当該新たなセグメントは、前のセグメントとは異なるコンテンツのレプレゼンテーションに対応する。当該関数は、引数として、新たなセグメントの新たな処理能力と、新たなセグメントが使用される位置情報とを含んでもよい。例えば、図２で説明すると、そのような関数はｔ１、ｔ２、ｔ３、ｔ５、ｔ６で実行されうる。
【００４２】
本実施形態において、上記関数は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜function onRepresentationChange()＞
当該関数は、ストリームがレプレゼンテーションを変更する際に呼び出され、処理能力が修正される。処理能力は、ＨＴＴＰ適応ストリーミング・マニフェストのレプレゼンテーション要素における処理能力属性に関連する。
ストリームの変化はプレゼンテーションの変更に関連し、ストリームがどのようにバッファリングされるかは必ずしも関連しない。なお、異なる品質を表示する複数のストリームがバッファされてもいいため、処理能力の変更を示すことは信頼できない。
指定される関数は、以下で定義する２つの引数、処理能力及び位置情報とともに呼び出される。
・Ｓｔｒｉｎｇ  ｂａｎｄｗｉｄｔｈ−新たなレプレゼンテーションと関連する処理能力。
・Ｓｔｒｉｎｇ  ｐｏｓｉｔｉｏｎ−新たなレプレゼンテーションへの移行が発生する位置情報。当該値は再生位置プロパティと同等であってもよい。
【００４３】
さらに、プロセッサは、（１）前のセグメントから異なるコンテンツレプレゼンテーションに対応する、使用される新たなセグメントと、（２）使用セグメントとともに使用される一連のダウンロードセグメントである新たな期間、に関連する、処理能力の変更を信号伝達する他の（第２の）関数を実行するように構成されてもよい。第２の関数は、新たな期間に使用されるダウンロード・セグメントの新たなリストが受信された直後に実行されてもよい。例えば、図２で説明すると、当該関数はｔ４の後に実行される。当該関数は、引数として、（１）新たな期間のセグメントに関連する処理能力のリストと、（２）新たなセグメントが使用される位置情報とを有してもよい。
【００４４】
本実施形態において、上述の関数は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜function onPeriodChange()＞
当該関数は、期間を変更する際に呼び出され、レプレゼンテーション及び関連する処理能力が修正される。当該処理能力は、ＨＴＴＰ適応ストリーミング・マニフェストのレプレゼンテーション要素における処理能力属性に関連する。
当該関数は、ストリームのバッファリングやプレゼンテーションの変更の前にＯＩＴＦによって新たなマニフェストがダウンロードされるとすぐに呼び出される。関数が呼び出されると、選択された最大レプレゼンテーション及び最小レプレゼンテーションをを修正することができる。
指定される関数は、以下で定義する２つの引数、処理能力及び位置情報とともに呼び出される。
・Ｓｔｒｉｎｇ  ｂａｎｄｗｉｄｔｈ−新たなレプレゼンテーションにおける新たな期間と関連する処理能力のリスト。
・Ｓｔｒｉｎｇ  ｐｏｓｉｔｉｏｎ−新たなレプレゼンテーションへの移行が発生する位置情報。
【００４５】
第２の関数（ＯｎＰｅｒｉｏｄＣｈａｎｇｅとして実装される）と上述した第１の関数（ＯｎＲｅｐｒｅｓｅｎｔａｔｉｏｎＣｈａｎｇｅとして実装される）との間には重大な差異が存在する。第１の関数（ＯｎＲｅｐｒｅｓｅｎｔａｔｉｏｎＣｈａｎｇｅ）が提示されるセグメント参照するのに対して、第２の関数（ＯｎＰｅｒｉｏｄＣｈａｎｇｅ）はセグメントがバッファリングされる前にとなる。第１の関数はセグメントがダウンロードされた状況で実行されるが、プレイヤは既にダウンロードされたセグメントを提示する（例えば、再生する）前にはバッファ（期間）は満たされていない。第１のコマンドが実行されると、プレイヤは異なる解像度（例えば低い）でセグメントのダウンロードを開始する。これにより、プレイヤは同一のセグメントの２つのバージョンをバッファリングすることになる。一方、第２の関数は、セグメントをダウンロードしストリーミングするための資源を節約する結果となるため望ましい結果を得ることができる。
【００４６】
プロセッサは、メディアコンテンツアイテムの利用可能な代替のレプレゼンテーションに対応する計算された処理能力のリストを提供する手順を実行するように構成してもよい。本実施形態において、上述の関数は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜Readonly Number availableRepresentations[ ]＞
ＨＴＴＰ適応ストリーミングのレプレゼンテーションの処理能力属性に従って計算された処理能力のリストを返す。
【００４７】
プロセッサは、使用される選択されたレプレゼンテーションに対する処理能力を提供する手順を実行するように構成されてもよい。本実施形態において、上述の手順は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜Readonly  Integer  currentRepresentation＞
提示されるＨＴＴＰ適応ストリーミングの選択されたレプレゼンテーションに対する現在の処理能力を返す。当該処理能力は、再生状態１（ｐｌａｙｉｎｇ）においてのみ利用可能であり、他の状態においては当該値は定義されない。
現在の速度を取得するために、プロパティｐｌａｙｓｐｅｅｄを参照する。
【００４８】
プロセッサは、現在使用されているレプレゼンテーションに対する最大又は最小の処理能力を返す手順を実行するように構成されてもよい。いくつかの実施形態において、上述の手順は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜Readonly  Integer  maxRepresentation＞
提示されるＨＴＴＰ適応ストリーミングの選択されたレプレゼンテーションに対して設定された最大の処理能力を返す。
＜Readonly  Integer  minRepresentation＞
提示されるＨＴＴＰ適応ストリーミングの選択されたレプレゼンテーションに対して設定された最小の処理能力を返す。
【００４９】
プロセッサは、現在のプレゼンテーション方法の変更を要求する（即ち、潜在的トリガ）ために、ブール値（Ｂｏｏｌｅａｎ  Ｖａｌｕｅ）を返す手順を実行するように構成されてもよい。上記手順は、（引数で）使用される最大許容処理能力と最小許容処理能力との間を維持するレプレゼンテーションのみを要求する。現在のプレゼンテーション方法の変更が成功すると、返されるブール値は”ｔｒｕｅ”となる。最大許容処理能力が最小許容処理能力より大きくなければ、返されるブール値は”ｆａｌｓｅ”となる。利用可能なレプレゼンテーションが最小許容処理能力と最大許容処理能力との間の範囲にない場合、返されるブール値は”ｆａｌｓｅ”となる。任意の利用可能なレプレゼンテーションが処理能力の範囲にあるかどうかを判定するために、プロセッサは、追加の代替のレプレゼンテーションに対応する計算された処理能力のリストを返す手順を使用してもよい。当該手順は、ストリーミング状態に関わらず（例えば、バッファリング、継続した使用又は再生、中断等）、任意のタイミングで実行されてもよい。本実施形態において、上述の手順は、ＣＥＡ−２０１４−Ａのセクション５．７．１で定義されるように音声オブジェクトと動画オブジェクトをサポートするＯＩＰＦバージョン２、ｖｏｌ５、セクション７．１４．９の拡張機能である。
＜Boolean setRepresentationStrategy（Integer maxBandwidth、  Integer  minBandwidth）＞
説明：利用可能なレプレゼンテーションに対するＨＴＴＰ適応ストリーミング・プレゼンテーション方法を変更するように要求する。指示される処理能力は、許容される最大及び最小の処理能力を示す。上限及び下限以外のレプレゼンテーションは制限される。
この方法は再生状態１（ｐｌａｙｉｎｇ）を含む、任意の再生状態中に呼び出される。この方法は、方法の変更が成功するとｔｒｕｅを返す。バッファリング方法の変更が成功しなければｆａｌｓｅを返す。
ｍａｘＢａｎｄｗｉｄｔｈの値は、ｍｉｎＢａｎｄｗｉｄｔｈの値よりも大きく、それ以外の場合はｆａｌｓｅを返す。ｍａｘＢａｎｄｗｉｄｔｈからｍｉｎＢａｎｄｗｉｄｔｈの処理能力までの間の範囲は、プロパティａｖａｉｌａｂｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎの少なくとも１つの値を許容し、そうでなければ当該方法はｆａｌｓｅを返す。
ＨＡＳ期間を変更し、新たな利用可能なレプレゼンテーションを有する新たなレプレゼンテーションが設定されたレプレゼンテーション方法の範囲内にない場合には、最大及び最小の処理能力が定義されずリセットされる。このようなことが発生しないように、最大及びい最小の処理能力の少なくとも一方は、ｏｎＰｅｒｉｏｄＣｈａｎｇｅ関数が呼び出されると、即座に修正されなければならない。
引数：ｍａｘＢａｎｄｗｉｄｔｈ：最大処理能力はＨＡＳのプレゼンテーションに対して許容される。値が設定されていない場合はＯＩＴＦによって限度が設定される。
引数：ｍｉｎＢａｎｄｗｉｄｔｈ：最小処理能力はＨＡＳのプレゼンテーションに対して許容される。値が設定されていない場合はＯＩＴＦによって限度が設定される。
【００５０】
引数ｍａｘＢａｎｄｗｉｄｔｈ、及びｍｉｎＢａｎｄｗｉｄｔｈの１つが指定されていなければ、最大処理能力又は最小処理能力のそれぞれが適用されないことを意味する。
【００５１】
さらに、ＯＩＰＦ及びＣＥＡ−２０１４−Ａのコンテキストにおいて、固有の以下のイベントに対して、対応ＤＯＭレベル２イベントは下記の方法で生成される。
＜Intrinsicイベント＞  ＜対応DOM2イベント＞  ＜DOM2イベントプロパティ＞
OnRepresentationChange  RepresentationChange  Bubbles:No
Cancelable:No
Context  info:None
OnPeriodChange          PeriodChange          Bubbles:No
Cancelable:No
Context  info:None。
【００５２】
これらのＤＯＭ２イベントは、イベントターゲットに直接送られ、バブルやキャプチャは行われない。アプリケーションはバブリングフェーズやキャプチャリングフェーズ中にそれらのイベントを受信するべきでない。
【００５３】
図８は、装置（図３の３３０に対応する、図５の５０４、図６の６０４など）の一部であり、ストリーミング・システム（図３の３００）においてストリーミング・アプリケーション（図３の３２５など）と通信するプロセッサ（図５の５０４又は図６の６０４など）によって実行される方法８００のフローチャートである。ストリーミング・システムにおいて、メディア・コンテンツ・アイテムの少なくとも２つのレプレゼンテーションが利用可能である。方法８００は、ストリーミング・アプリケーションによって使用されるメディア・コンテンツ・アイテムの一連のセグメントにおいて、レプレゼンテーション及び処理能力の変更が発生すると、信号を生成するＳ８１０を含む。方法８００は、さらに、Ｓ８２０において、ストリーミング・アプリケーションへ生成された信号を送信するステップを有する。当該方法は、プロセッサによって実行されるプログラムとして、コンピュータで読取可能な媒体（３４０）に格納される。
【００５４】
開示される例示の実施形態は、ストリーミング・コンテンツに関連する戦略的な決定に関する情報をストリーミング・クライアントに提供する方法及び装置を提供する。この決定は、本発明を限定することを意図しないことが理解されるべきである。一方、例示の実施形態は、以下の特許請求の範囲によって定義されるように本発明の精神及び範囲に含まれる、代替の、変形の、同等のものをカバーすることを意図する。さらに、例示の実施形態の詳細な説明において、請求した発明の包括的な理解を提供するために多数の特定の説明が記載されている。しかしながら、そのような特定の説明ではなく、種々の実施形態が実行されてもよいことを当業者には理解されるであろう。
【００５５】
当業者には理解されるように、例示の実施形態は、無線通信デバイス、方法、又はコンピュータプログラムに実装されてもよい。本発明の例示の実施形態における機能や要素は、実施形態においては特有の組み合わせで説明したが、各機能や各要素は、本実施形態において他の機能や他の要素なしで使用されてもいし、ここで説明した他の機能や他の要素との、又は、他の機能や他の要素なしでの、種々の組み合わせで使用されてもよい。本発明において提供する方法及びフローチャートは、特有のプログラマブル・コンピュータ又はプロセッサによって実行される、コンピュータで読取可能な記憶媒体に実装されるコンピュータプログラム、ソフトウェア、又はファームウェアとして実現されてもよい。
【図１】
0005889311.tif 000002
【図２】
0005889311.tif 000003
【図３】
0005889311.tif 000004
【図４】
0005889311.tif 000005
【図５】
0005889311.tif 000006
【図６】
0005889311.tif 000007
【図７】
0005889311.tif 000008
【図８】
0005889311.tif 000009