JP6903688B2 - サンプルエントリーおよびランダムアクセス - Google Patents

Description

相互参照

[0001]本願は、２０１６年５月２４日に出願された米国仮特許出願第６２／３４０，８８６号の利益を主張し、その全体の内容（contents）が参照により本明細書に組み込まれる。

[0002]本開示は、ビデオビットストリームなどの、メディアビットストリームの記憶およびトランスポート（storage and transport）のためのファイル形式に関連する。

[0003]デジタルビデオ機能（capabilities）は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレイヤ、ビデオゲームデバイス、ビデオゲーム機、セルラ式または衛星無線電話、ビデオテレビ会議デバイス、および同類のものを含む、広範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３またはＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、およびそのような規格の拡張によって定義された規格において説明されるような、ビデオ圧縮技法をインプリメントする。

[0004]ビデオ圧縮技法は、ビデオシーケンスに内在する（inherent in）冗長性を減らすまたは取り除くために、空間予測（spatial prediction）および／または時間予測（temporal prediction）を行う。ブロックベースのビデオコーディングに関して（For）、ビデオフレームまたはスライスは、マクロブロックに区分化され得る。各マクロブロックは、さらに区分化されることができる。イントラコード化された（Ｉ）フレームまたはスライスにおけるマクロブロックは、隣接したマクロブロックに関する空間予測を使用して符号化される。インターコード化された（ＰまたはＢ）フレームまたはスライスにおけるマクロブロックは、同じフレームまたはスライスにおける複数の隣接したマクロブロック（neighboring macroblocks）に関する空間予測、あるいは他の参照フレームに関する時間予測を使用し得る。

[0005]ビデオデータが符号化された後に、ビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構（ＩＳＯ：International Organization for Standardization）ベースメディアファイルフォーマット、および、ＡＶＣファイルフォーマットのような、それの拡張などの、様々な規格のうちのいずれ（any）にも適合するビデオファイルにアセンブルされ得る。

[0006]一般に、本開示は、１つまたは複数のトラックにおいてシングルレイヤまたはマルチレイヤのビットストリームを記憶するファイルに関する便利なランダムアクセス動作（convenient random access operations）をイネーブルするための技法を説明する。本開示は、１つまたは複数のトラックにおいてシングルレイヤまたはマルチレイヤのビットストリームを記憶するファイルに関する、便利なランダムアクセス動作をイネーブルするサンプルエントリー設計上の方法、デバイス、およびコンピュータプログラム製品を提供する。

[0007]１つの例において、ビデオデータを検索する方法は、ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序においてビデオビットストリームにおけるサンプルに先行する、'hev1'または'hev2'であるサンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを備えるサンプルに応答して、サンプルに先行する１つまたは複数の他のサンプルのうちのいずれの（any）ビデオデータを検索することなしに（without）、および復号順序においてビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、サンプルを使用してランダムアクセスを行うためにサンプルを検索することと、を含む。

[0008]別の例において、ビデオデータを検索するためのデバイスは、ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序においてビデオビットストリームにおけるサンプルに先行する、'hev1'または'hev2'であるサンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを備えるサンプルに応答して、サンプルに先行する１つまたは複数の他のサンプルのうちのいずれのビデオデータを検索することなしに、および復号順序においてビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、サンプルを使用してランダムアクセスを行うためにサンプルを検索することと、を行うように構成された１つまたは複数のプロセッサを含む。

[0009]別の例において、ビデオデータを検索するためのデバイスは、ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信するための手段と、サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序においてビデオビットストリームにおけるサンプルに先行する、'hev1'または'hev2'であるサンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを備えるサンプルに応答して、サンプルに先行する１つまたは複数の他のサンプルのうちのいずれのビデオデータを検索することなしに、および復号順序においてビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、サンプルを使用してランダムアクセスを行うためにサンプルを検索するための手段と、を含む。

[0010]別の例において、命令を記憶したコンピュータ可読記憶媒体であって、命令は、実行されると、プロセッサに、ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序においてビデオビットストリームにおけるサンプルに先行する、'hev1'または'hev2'であるサンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを備えるサンプルに応答して、サンプルに先行する１つまたは複数の他のサンプルのうちのいずれのビデオデータを検索することなしに、および復号順序においてビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、サンプルを使用してランダムアクセスを行うためにサンプルを検索することと、を行わせる。

[0011]別の例において、ビデオデータを含むファイルを生成する方法は、複数のトラックのうちの最も低い（lowest）トラック、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶ（carrying）ビデオデータのベースレイヤを含む、が、便利なランダムアクセスがイネーブルされていることを示すサンプルに関するサンプルエントリータイプ値を含むことになる（is to include）ことを決定することに応答して、便利なランダムアクセスがイネーブルされていることを示すために、ビデオデータを含む複数のトラックのその他の（other）トラックの各々のサンプルに関する（for）サンプルエントリータイプ値を設定することと、複数のトラックのトラックに関するサンプルエントリータイプ値が、便利なランダムアクセスがイネーブルされていることを示すように、複数のトラックを含むファイルを生成することと、を含む。

[0012]別の例において、ビデオデータを含むファイルを生成するためのデバイスは、ビデオデータを記憶するように構成されたメモリと、サーキットリー（circuitry）においてインプリメントされ、および、複数のトラックのうちの最も低いトラック、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶビデオデータのベースレイヤを含む、が、便利なランダムアクセスがイネーブルされていることを示すサンプルに関するサンプルエントリータイプ値を含むことになることを決定することに応答して、便利なランダムアクセスがイネーブルされていることを示すために、ビデオデータを含む複数のトラックのその他のトラックの各々のサンプルに関するサンプルエントリータイプ値を設定することと、複数のトラックのトラックに関するサンプルエントリータイプ値が、便利なランダムアクセスがイネーブルされていることを示すように、複数のトラックを含むファイルを生成することとを行うように構成された１つまたは複数のプロセッサとを含む。
[0013]別の例において、ビデオデータを含むファイルを生成するためのデバイスは、複数のトラックのうちの最も低いトラック、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶビデオデータのベースレイヤを含む、が、便利なランダムアクセスがイネーブルされていることを示すサンプルに関するサンプルエントリータイプ値を含むことになることを決定することに応答して、便利なランダムアクセスがイネーブルされていることを示すために、ビデオデータを含む複数のトラックのその他のトラックの各々のサンプルに関するサンプルエントリータイプ値を設定するための手段と、複数のトラックのトラックに関するサンプルエントリータイプ値が、便利なランダムアクセスがイネーブルされていることを示すように、複数のトラックを含むファイルを生成するための手段と、を含む。

[0014]別の例において、コンピュータ可読記憶媒体は、実行されると、プロセッサに、複数のトラックのうちの最も低いトラック、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶビデオデータのベースレイヤを含む、が、便利なランダムアクセスがイネーブルされていることを示すサンプルに関するサンプルエントリータイプ値を含むことになることを決定することに応答して、便利なランダムアクセスがイネーブルされていることを示すために、ビデオデータを含む複数のトラックのその他のトラックの各々のサンプルに関するサンプルエントリータイプ値を設定することと、複数のトラックのトラックに関するサンプルエントリータイプ値が、便利なランダムアクセスがイネーブルされていることを示すように、複数のトラックを含むファイルを生成することと、を行わせる命令を記憶する。

[0015]１つまたは複数の例の詳細は、添付の図面および以下の説明において説明される。他の特徴、目的、および利点は、説明、図面から、および特許請求の範囲から明らかになるであろう。

[0016]図１は、ネットワーク上でメディアデータをストリーミングするための技法をインプリメントする例となるシステムを例示するブロック図である。 [0017]図２は、検索ユニットのコンポーネントの例となるセットを例示するブロック図である。 [0018]図３は、例となるマルチメディアコンテンツの要素を例示する概念図である。 [0019]図４は、例となるビデオファイルの要素を例示するブロック図である。 [0020]図５は、データを処理する例となる技法を例示するフローチャートである。 [0021]図６は、データを処理する例となる技法を例示するフローチャートである。 [0022]図７は、ビデオデータを含むファイルを生成する例となる技法を例示するフローチャートである。

詳細な説明

[0023]一般に、本開示は、１つまたは複数のトラックにおいてシングルレイヤまたはマルチレイヤのビットストリームを記憶するファイルに関する便利なランダムアクセス動作をイネーブルするための技法を説明する。便利なランダムアクセスは、より早い（earlier）サンプルからパラメータセットを探索する（searching）ことおよび／またはフェッチすることを必要とすること（requiring）なしに、ランダムアクセスとして定義され得る。言い換えれば、便利なランダムアクセスは、クライアントデバイスが、より早いサンプルのパラメータセットを探索する（searching for）ことおよび／またはフェッチすることなしに、サンプルおよび後続のサンプルを要求（request）できるとき、ビデオビットストリームのサンプルのためにイネーブルされる。それ故、全ての必要なパラメータセットは、サンプルそれ自体において、またはサンプルに対応するサンプルエントリーにおいてのいずれかに含まれ得る。

[0024]本開示は、１つまたは複数のトラックにおいてシングルレイヤまたはマルチレイヤのビットストリームを記憶するファイルに関する、便利なランダムアクセス動作をイネーブルするサンプルエントリー設計上の方法を説明する。

[0025]ビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、それのＳｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）拡張およびＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）拡張を含むＩＴＵ−Ｔ Ｈ．２６４またはＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣ、および、それのスケーラブルコーディング拡張（すなわち、ｓｃａｌａｂｌｅ ｈｉｇｈ−ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ、ＳＨＶＣ）、マルチビュー拡張（すなわち、ｍｕｌｔｉｖｉｅｗ ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ、ＭＶ−ＨＥＶＣ）、および３Ｄ拡張（すなわち、３Ｄ ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ、３Ｄ−ＨＥＶＣ）を含む、ＩＴＵ−Ｔ Ｈ．２６５およびＩＳＯ／ＩＥＣ２３００８−２としてもまた知られる、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）を含む。

[0026]ファイルフォーマット規格は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ、ＩＳＯ／ＩＥＣ１４４９６−１２）を含み、ＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）、３ＧＰＰ（登録商標）ファイルフォーマット（３ＧＰＰ ＴＳ ２６．２４４）、およびＡＶＣおよびそれの拡張のためのファイルフォーマットならびにＨＥＶＣおよびそれの拡張のためのファイルフォーマットを包含するＩＳＯ／ＩＥＣ１４４９６−１５を含む、ＩＳＯＢＭＦＦから派生した他のフォーマットを含む。ＩＳＯ／ＩＥＣ１４４９６−１２および１４４９６−１５の最新の版の草案文面は、それぞれ、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zipおよびhttp://wg11.sc29.org/doc_end_user/documents/114_San%20Diego/wg11/w15928-v2-w15928.zipにおいて、入手可能である。

[0027]この開示の技法は、ＩＳＯベースメディアファイルフォーマット、Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）ファイルフォーマット、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）ファイルフォーマット、第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project）ファイルフォーマット、および／またはＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ファイルフォーマット、あるいは、他の類似の（similar）ビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに適合するビデオファイルに適用され得る。

[0028]ＨＴＴＰストリーミングにおいて、頻繁に使用される動作は、ＨＥＡＤ、ＧＥＴ、およびパーシャルＧＥＴを含む。ＨＥＡＤ動作は、所与のユニフォームリソースロケータ（ＵＲＬ）またはユニフォームリソースネーム（ＵＲＮ）に関連付けられたファイルのヘッダを、ＵＲＬまたはＵＲＮに関連付けられたペイロードを検索することなく、検索する。ＧＥＴ動作は、所与のＵＲＬまたはＵＲＮに関連付けられた全ファイルを検索する。パーシャルＧＥＴ動作（partial GET operation）は、入力パラメータとしてバイト範囲を受信し、ファイルのバイトの連続数（continuous number）を検索する、ここで、バイトの数は、受信されたバイト範囲に対応する。それ故、ムービーフラグメントは、ＨＴＴＰストリーミングのために提供され得る、なぜなら、パーシャルＧＥＴ動作が、１つまたは複数の個々のムービーフラグメントを得ることができるからである。ムービーフラグメントにおいて、異なるトラックのいくつかの（several）トラックフラグメントがあることができる（can）。ＨＴＴＰストリーミングにおいて、メディアプレゼンテーションは、クライアントにアクセス可能な（accessible）データの構造化された集まり（structured collection）であり得る。クライアントは、ユーザにストリーミングサービスを提示するために、メディアデータ情報を要求しおよびダウンロードし得る。

[0029]ＨＴＴＰストリーミングを使用して、３ＧＰＰデータをストリーミングする例において、マルチメディアコンテンツのビデオおよび／または音声データに関する複数の表現（multiple representations）があり得る。下記に説明されるように、異なる表現は、異なるコーディング特性（例えば、ビデオコーディング規格の異なるプロファイルまたはレベル）、異なるコーディング規格またはコーディング規格の（マルチビュー拡張および／またはスケーラブル拡張などの）拡張、あるいは異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述（ＭＰＤ）データ構造において定義され得る。メディアプレゼンテーションは、ＨＴＴＰストリーミングクライアントデバイスにアクセス可能なデータの構造化された集まりに対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求し（request）およびダウンロードし得る。メディアプレゼンテーションは、ＭＰＤデータ構造において記述され得、それは、ＭＰＤのアップデートを含み得る。

[0030]メディアプレゼンテーションは、一連の（a sequence of）１つまたは複数の期間（Period）を包含し得る。各期間は、次の期間の開始までか、または、最後の期間の場合においては、メディアプレゼンテーションの終わりまで、伸び（extend）得る。各期間は、同じメディアコンテンツに関して１つまたは複数の表現を包含し得る。表現は、音声、ビデオ、タイムドテキスト、または他のそのようなデータの複数の（a number of）代替的な符号化されたバージョンのうちの１つであり得る。表現（representations）は、符号化タイプにより、例えば、ビットレート、解像度、および／または、ビデオデータおよびビットレートに関するコーデック、言語、および／または音声データに関するコーデックにより、異なり得る。ターム（term）表現は、マルチメディアコンテンツの特定の期間に対応する符号化された音声またはビデオデータのセクションに言及するために使用され得（may be used to refer to）、および特定の方法（way）で符号化される。

[0031]特定の期間の表現は、表現が属する適応セット（adaptation set）を示すＭＰＤにおける属性によって示されるグループに割り当てられ得る。同じ適応セットにおける表現は、一般に、クライアントデバイスが、例えば、帯域幅適応（bandwidth adaptation）を行うために、動的に、および継ぎ目なく（seamlessly）、これらの表現間で切り替えることができるという点で、互いに代替であると考えられる。例えば、特定の期間に関するビデオデータの各表現は、それら表現のいずれもが、対応する期間に関するマルチメディアコンテンツのビデオデータまたは音声データなどの、メディアデータを提示するために復号のために選択され得るように、同じ適応セットに割り当てられ得る。１つの期間内のメディアコンテンツは、いくつかの例において、もし存在する場合（if present）、グループ０からの１つの表現、または、各非ゼログループからの多くても１つの表現の組合せのいずれかにより、表現され得る。期間の各表現に関するタイミングデータは、期間の開始時間に対して（relative to）表され得る。

[0032]表現は、１つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含み得るか、または表現の各セグメントは、自己初期化している（self-initializing）可能性がある。初期化セグメントは、存在するとき、表現にアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソースネーム（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ）などの、識別子によって一意的に（uniquely）言及され得る。ＭＰＤは、セグメントごとに識別子を提供し得る。いくつかの例において、ＭＰＤはまた、範囲属性（range attribute）の形態でバイト範囲を提供し得、それは、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能なファイル内のセグメントに関するデータに対応し得る。

[0033]異なる表現は、異なるタイプのメディアデータに実質的に同時の検索のために選択され得る。例えば、クライアントデバイスは、音声表現、ビデオ表現、およびタイムドテキスト表現を、それらからセグメントを検索するために、選択し得る。いくつかの例において、クライアントデバイスは、帯域幅適応を行うための特定の適応セットを選択し得る。つまり、クライアントデバイスは、ビデオ表現、音声表現を含む適応セット、および／またはタイムドテキストを含む適応セットを含む適応セットを選択し得る。代替的に、クライアントデバイスは、ある特定の（certain）タイプのメディア（例えば、ビデオ）に関する適応セットを選択し得、他タイプのメディア（例えば、音声および／またはタイムドテキスト）に関する表現を直接に選択し得る。

[0034]図１は、ネットワーク上でメディアデータをストリーミングするための技法をインプリメントする例となるシステム１０を例示するブロック図である。この例において、システム１０は、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０を含む。クライアントデバイス４０およびサーバデバイス６０は、ネットワーク７４によって通信可能に（communicatively）結合され、それはインターネットを備え得る。いくつかの例において、コンテンツ準備デバイス２０およびサーバデバイス６０はまた、ネットワーク７４または別のネットワークによって結合され得、あるいは直接に通信可能に結合され得る。いくつかの例において、コンテンツ準備デバイス２０およびサーバデバイス６０は、同じデバイスを備え得る。

[0035]コンテンツ準備デバイス２０は、図１の例において、音声ソース２２およびビデオソース２４を備える。音声ソース２２は、例えば、音声エンコーダ２６によって符号化されることになるキャプチャされた音声データを代表する（representative of）電気信号を作り出すマイクロフォンを備え得る。代替的に、音声ソース２２は、事前に記録された音声データを記憶する記憶媒体、コンピュータ化されたシンセサイザーなどの音声データ生成器、または音声データの何らかの他のソースを備え得る。ビデオソース２４は、ビデオエンコーダ２８によって符号化されることになるビデオデータを作り出すビデオカメラ、事前に記録されたビデオデータを用いて符号化された記憶媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの何らかの他のソースを備え得る。コンテンツ準備デバイス２０は、全ての例においてサーバデバイス６０に必ずしも通信可能に結合される必要はないが、サーバデバイス６０によって読み取られ得る別個の媒体へのマルチメディアコンテンツを記憶し得る。

[0036]生音声およびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、音声エンコーダ２６および／またはビデオエンコーダ２８によって符号化される前に、デジタル化され得る。音声ソース２２は、話している参加者（speaking participant）が話している間に話している参加者から音声データを取得し得、ビデオソース２４は、その話している参加者のビデオデータを同時に取得し得る。他の例において、音声ソース２２は、記憶された音声データを備えるコンピュータ可読記憶媒体を備え得、ビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、本開示において説明された技法は、ライブ、ストリーミング、リアルタイム音声およびビデオデータに、またはアーカイブされた、事前記録された音声およびビデオデータに、適用され得る。

[0037]ビデオフレームに対応する音声フレームは、一般に、ビデオフレーム内において包含されるビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時に（contemporaneously）、音声ソース２２によってキャプチャされた（または生成された）音声データを包含する音声フレームである。例えば、話している参加者は、一般に、話すことによって音声データを作り出す（produces）間、音声ソース２２は、音声データをキャプチャし、ビデオソース２４は、同じ時間において、つまり、音声ソース２２が音声データをキャプチャしている間、話している参加者のビデオデータをキャプチャする。故に、音声フレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応する音声フレームは、一般に、音声データおよびビデオデータが同じ時間においてキャプチャされた、および音声フレームおよびビデオフレームが、それぞれ、同じ時間においてキャプチャされた音声データおよびビデオデータを備える、状況に対応する。

[0038]いくつかの例において、音声エンコーダ２６は、符号化された音声フレームに関する音声データが記録された時間を表す各符号化された音声フレームにおけるタイムスタンプを符号化し得、同様に、ビデオエンコーダ２８は、符号化されたビデオフレームに関してビデオデータが記録された時間を表す各符号化されたビデオフレームにおけるタイムスタンプを符号化し得る。そのような例において、ビデオフレームに対応する音声フレームは、タイムスタンプを備える音声フレームおよび同じタイムスタンプを備えるビデオフレームを備え得る。コンテンツ準備デバイス２０は、音声エンコーダ２６および／またはビデオエンコーダ２８が、それからタイムスタンプを生成し得るか、または音声ソース２２およびビデオソース２４が、音声およびビデオデータを、それぞれ、タイムスタンプと関連付けるために使用し得る、内部クロックを含み得る。

[0039]いくつかの例において、音声ソース２２は、音声データが記録された時間に対応する音声エンコーダ２６にデータを送り得、ビデオソース２４は、ビデオデータが記録された時間に対応するビデオエンコーダ２８にデータを送り得る。いくつかの例において、音声エンコーダ２６は、音声データが記録された絶対的な時間を必ずしも示さないが、符号化されたビデオデータの相対的な時間的秩序（relative temporal ordering）を示すために、符号化された音声データにおけるシーケンス識別子を符号化し得、同様に、ビデオエンコーダ２８はまた、符号化されたビデオデータの相対的な時間的秩序を示すためにシーケンス識別子を使用し得る。同様に、いくつかの例において、シーケンス識別子は、マッピングされ得るか、またはそうでなければ、タイムスタンプと相互関係を示す（correlated with）。

[0040]音声エンコーダ２６は、一般に、符号化された音声データのストリームを作り出し、一方で、ビデオエンコーダ２８は、符号化されたビデオデータのストリームを作り出す。（音声であろうがビデオであろうが）データの各個々のストリームは、エレメンタリーストリームと呼ばれ得る。エレメンタリーストリームは、表現の、単一の、デジタルにコード化された（場合により（possibly）圧縮された）コンポーネントである。例えば、表現のコード化されたビデオまたは音声部分は、エレメンタリーストリームであることができる（can）。エレメンタリーストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリーストリーム（ＰＥＳ：packetized elementary stream）に変換され（converted into）得る。同じ表現内で、ストリームＩＤは、１つのエレメンタリーストリームに属するＰＥＳパケットをその他から区別するために使用され得る。エレメンタリーストリームのデータの基本単位は、パケット化されたエレメンタリーストリーム（ＰＥＳ）パケットである。それ故、コード化されたビデオデータは、一般に、エレメンタリービデオストリームに対応する。同様に、音声データは、１つまたは複数のそれぞれのエレメンタリーストリームに対応する。

[0041]ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣおよび今度の（upcoming）Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格のような、多くのビデオコーディング規格は、エラーフリービットストリームに関する、シンタックス、セマンティクス、復号プロセスを定義し、それらのいずれもある特定のプロファイルまたはレベルに適合する。ビデオコーディング規格は、典型的に、エンコーダを特定しないが、エンコーダは、生成されたビットストリームがデコーダに関して規格に準拠していることを保証することが課せられる（tasked with）。ビデオコーディング規格のコンテキストにおいて、「プロファイル（profile）」は、アルゴリズム、特徴、またはツールのサブセット、およびそれらに適応される制約に対応する。Ｈ．２６４規格によって定義されるように、例えば、「プロファイル」は、Ｈ．２６４規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル（level）」は、例えば、デコーダメモリおよび計算などの、デコーダリソース消費の限界（limitations）に対応し、それは、ピクチャ、ビットレート、およびブロック処理レートの解像度に関連する。プロファイルは、profile_idc（プロファイルインジケータ）値を用いてシグナリングされ得、一方で、レベルは、level_idc（レベルインジケータ）値を用いてシグナリングされ得る。

[0042]Ｈ．２６４規格は、例えば、所与のプロファイルのシンタックスによって課せられる限度（bounds）内で、復号されたピクチャの特定されたサイズなどのビットストリームにおけるシンタックス要素によって取られる値に依存して、エンコーダおよびデコーダの性能（performance）において大きな変化（large variation）を必要とすることが未だ可能であることを認めている。Ｈ．２６４規格は、多くのアプリケーションにおいて、特定のプロファイル内のシンタックスの全ての仮説上の（hypothetical）使途に対応する（dealing with）能力があるデコーダをインプリメントすることは実用的（practical）でも経済的（economical）でもないことをさらに認めている（recognizes）。したがって、Ｈ．２６４規格は、ビットストリームにおけるシンタックス要素の値に課せられた制約の規定の（specified）セットとして、「レベル」を定義する。これらの制約は、値についての簡素な制限であり得る。代替的に、これらの制約は、値の算術的な組合せ（例えば、毎秒当たりに復号されたピクチャの数を乗じたピクチャ高さを乗じたピクチャ幅）に対する制約の形態を取り得る。Ｈ．２６４規格は、個々のインプリメンテーションは、サポートされたプロファイルごとに異なるレベルをサポートし得ることをさらに提供する。

[0043]プロファイルに適合するデコーダは、通常（ordinarily）、プロファイルにおいて定義された全ての特長をサポートする。例えば、コーディングの特長として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイルにおいてサポートされていないが、Ｈ．２６４／ＡＶＣの他のプロファイルにおいてサポートされている。レベルに適合するデコーダは、レベルにおいて定義された制限（limitations）を超えるリソースを必要としない任意の（any）ビットストリームを復号する能力があるはずである。プロファイルおよびレベルの定義は、解釈可能性（interpretability）に関して役立ち得る。例えば、ビデオ送信の間、一対のプロファイルおよびレベルの定義は、全ての送信セッションに関して、交渉されおよび合意され得る。さらに具体的には、Ｈ．２６４／ＡＶＣにおいて、レベルは、処理されることが必要であるマクロブロックの数、復号されたピクチャバッファ（ＤＰＢ）サイズ、コード化されたピクチャバッファ（ＣＰＢ）サイズ、垂直動きベクトル範囲、２つの連続するＭＢごとの動きベクトルの最大数、およびＢブロックが８ｘ８画素よりも少ないサブマクロブロック区分を有することができるかどうか、についての制限を定義し得る。このように、デコーダは、デコーダがビットストリームを適切に復号する能力があるかどうかを決定し得る。

[0044]図１の例において、コンテンツ準備デバイス２０のカプセル化ユニット３０は、ビデオエンコーダ２８からコード化されたビデオデータを備えるエレメンタリーストリームおよび音声エンコーダ２６からコード化された音声データを備えるエレメンタリーストリームを受信する。いくつかの例において、ビデオエンコーダ２８および音声エンコーダ２６は、各々、符号化されたデータからＰＥＳパケットを形成するためのパケタイザ（packetizers）を含み得る。他の例において、ビデオエンコーダ２８および音声エンコーダ２６は、各々、符号化されたデータからＰＥＳパケットを形成するためのそれぞれのパケタイザとインターフェースで接続（interface with）し得る。さらに他の例において、カプセル化ユニット３０は、符号化された音声およびビデオデータからのＰＥＳパケットを形成するためのパケタイザを含み得る。

[0045]ビデオエンコーダ２８は、様々な方法において、様々なビットレートにおける、および、画素解像度、フレームレート、様々なコーディング規格への適合、様々なコーディング規格に関する様々なプロファイルおよび／またはプロファイルのレベルへの適合、（例えば、２次元のまたは３次元の再生に関する）１つまたは複数のビューを有する表現、あるいは他のそのような特性などの、様々な特性を有する、マルチメディアコンテンツの異なる表現を作り出すために、マルチメディアコンテンツのビデオデータを符号化し得る。表現は、本開示において使用されるように、音声データ、ビデオデータ、（例えば、字幕（closed captions）に関する）テキストデータ、または他のそのようなデータのうちの１つを備え得る。表現は、音声エレメンタリーストリームまたはビデオエレメンタリーストリームなどの、エレメンタリーストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリーストリームを識別するstream_idを含み得る。カプセル化ユニット３０は、エレメンタリーストリームを様々な表現のビデオファイル（例えば、セグメント）にアセンブルすることを担う。

[0046]カプセル化ユニット３０は、音声エンコーダ２６およびビデオエンコーダ２８からの表現のエレメンタリーストリームに関してＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワーク抽象化レイヤ（ＮＡＬ）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）の例において、コード化されたビデオセグメントは、ＮＡＬユニットとして組織化され（organized into）、それは、ビデオ電話通信、記憶装置、ブロードキャスト、またはストリーミングなどのアプリケーションに対処する「ネットワークフレンドリーな」ビデオ表現を提供する。ＮＡＬユニットは、Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ（ＶＣＬ）ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットに分類（categorized）されることができる。ＶＣＬユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および／またはスライスレベルデータを含み得る。他のＮＡＬユニットは、非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例において、１つの時間インスタンスにおけるコード化されたピクチャは、通常、プライマリにコード化されたピクチャとして提示され、アクセスユニットにおいて包含され得、それは、１つまたは複数のＮＡＬユニットを含み得る。

[0047]非ＶＣＬ ＮＡＬユニットは、とりわけ（among others）、パラメータセットＮＡＬユニットおよびＳＥＩ ＮＡＬユニットを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）において）シーケンスレベルのヘッダ情報および（ピクチャパラメータセット（ＰＰＳ）において）変化する頻度が低い（infrequently changing）ピクチャレベルのヘッダ情報を包含し得る。パラメータセット（例えば、ＰＰＳおよびＳＰＳ）があれば、変化する頻度が低い情報は、シーケンスまたはピクチャごとに繰り返される必要はなく、故に、コーディング効率は、改善され得る。その上、パラメータセットの使用は、重要なヘッダ情報の帯域外送信（out-of-band transmission）をイネーブルし得、誤り耐性（error resilience）のための冗長送信の必要性を避ける。帯域外送信の例において、パラメータセットＮＡＬユニットは、ＳＥＩ ＮＡＬユニットなどの、他のＮＡＬユニットとは異なるチャネル上で、送信され得る。

[0048]付加拡張情報（ＳＥＩ）は、ＶＣＬ ＮＡＬユニットからコード化されたピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、ディスプレイ、誤り耐性、および他の目的に関連する処理において、支援し（assist）得る。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニットにおいて包含され得る。ＳＥＩメッセージは、いくつかの規格仕様の標準的な部分（normative part）であり、それ故、標準準拠のデコーダのインプリメンテーションに対して常に必須であるわけではない（not always mandatory for）。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージまたはピクチャレベルＳＥＩメッセージであり得る。いくつかのシーケンスレベル情報は、ＳＶＣの例における拡張性（scalability）情報ＳＥＩメッセージおよびＭＶＣにおけるビュー拡張性情報ＳＥＩメッセージなどの、ＳＥＩメッセージに包含され得る。これらの例となるＳＥＩメッセージは、例えば、動作点の抽出（extraction）および動作点の特性上で、情報を運び得る。加えて、カプセル化ユニット３０は、表現の特性を記述するメディアプレゼンテーション記述子（ＭＰＤ）などの、マニフェストファイルを形成し得る。カプセル化ユニット３０は、ＸＭＬ（extensible markup language）に従って、ＭＰＤをフォーマットし得る。

[0049]カプセル化ユニット３０は、出力インターフェース３２に、マニフェストファイル（例えば、ＭＰＤ）と共に（along with）、マルチメディアコンテンツの１つまたは複数の表現に関するデータを提供し得る。出力インターフェース３２は、ネットワークインターフェースまたはユニバーサル・シリアル・バス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライタまたはバーナー、磁気のまたはフラッシュの記憶媒体へのインターフェース、またはメディアデータを記憶または送信するための他のインターフェースなどの、記憶媒体に書き込むためのインターフェースを備え得る。カプセル化ユニット３０は、出力インターフェース３２に、マルチメディアコンテンツの表現の各々のデータを提供し得、それは、データをネットワーク送信または記憶媒体を介して、サーバデバイス６０に送り得る。図１の例において、サーバデバイス６０は、様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含み、各々は、それぞれのマニフェストファイル６６および１つまたは複数の表現６８Ａ〜６８Ｎ（表現６８）を含む。いくつかの例において、出力インターフェース３２はまた、データをネットワーク７４に直接に送り得る。

[0050]いくつかの例において、表現６８は、適応セットに分けられ（separated into）得る。つまり、表現６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントに関するファイル形式、表現を用いて表示されることになるテキストの言語または他の特性を、および／または、例えば、スピーカによって、復号されおよび提示されることになる音声データを、識別し得るテキストタイプ情報、適応セットにおける表現のためにシーンのカメラ角度または実世界のカメラの遠近感を記述し得るカメラ角度情報、特定の視聴者（audiences）に関するコンテンツの適合性を説明する評定情報（rating information）、また同種のものなどの、特性のそれぞれの共通のセットを含み得る。

[0051]マニフェストファイル６６は、適応セットに関する共通の特性ならびに（as well as）特定の適応セットに対応する表現６８のサブセットを示すデータを含み得る。マニフェストファイル６６はまた、適応セットの個々の表現に関する、ビットレートなどの、個々の特性を代表するデータを含み得る。このように、適応セットは、簡易化されたネットワーク帯域幅適応を提供し得る。適応セットにおける表現は、マニフェストファイル６６の適応セット要素の子の要素（child elements）を使用して、示され得る。

[0052]サーバデバイス６０は、要求処理ユニット７０およびネットワークインターフェース７２を含む。いくつかの例において、サーバデバイス６０は、複数のネットワークインターフェースを含み得る。その上、サーバデバイス６０の特徴のうちのいずれかのまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなどの、コンテンツデリバリネットワークの他のデバイス上でインプリメントされ得る。いくつかの例において、コンテンツデリバリネットワークの中間デバイスは、マルチメディアコンテンツ６４のデータをキャッシュし（cache）得、サーバデバイス６０のそれらに実質的に適合するコンポ―ネントを含み得る。一般に、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送りおよび受信するように構成される。

[0053]要求処理ユニット７０は、記憶媒体６２のデータに関して、クライアントデバイス４０などの、クライアントデバイスからネットワーク要求を受信するように構成される。例えば、要求処理ユニット７０は、ＲＦＣ２６１６、R. Fielding他による「Hypertext Transfer Protocol - HTTP/1.1」、ネットワークワーキンググループ、ＩＥＴＦ、１９９９年６月、において説明される、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）バージョン１．１をインプリメントし得る。つまり、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴ要求またはパーシャルＧＥＴ要求を受信すること、および要求に応答して、マルチメディアコンテンツ６４のデータを提供することを行うように構成され得る。要求は、例えば、セグメントのＵＲＬを使用して、表現６８のうちの１つのセグメントを特定し得る。いくつかの例において、要求はまた、セグメントの１つまたは複数のバイト幅を特定し得、それ故、パーシャルＧＥＴ要求を備える。要求処理ユニット７０は、表現６８のうちの１つのセグメントのヘッダデータを提供するためのＨＴＴＰ ＨＥＡＤ要求をサービス提供するようにさらに構成され得る。いずれの場合においても、要求処理ユニット７０は、クライアントデバイス４０などの、要求するデバイスに要求されたデータを提供するために要求を処理するように構成され得る。

[0054]追加的にまたは代替的に、要求処理ユニット７０は、ｅＭＢＭＳのような、ブロードキャストまたはマルチキャストプロトコルを介して、メディアデータを配信するように構成され得る。コンテンツ準備デバイス２０は、説明されるのと実質的に同じやり方で、ＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳまたは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用して、これらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット７０は、クライアントデバイス４０からマルチキャストグループ加入要求を受信するように構成され得る。つまり、サーバデバイス６０は、特定のメディアコンテンツ（例えば、ライブイベントのブロードキャスト）に関連付けられた、クライアントデバイス４０を含む、クライアントデバイスに対してマルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ）アドレスを宣伝し（advertise）得る。クライアントデバイス４０は、次に、マルチキャストグループに加入する（join）ための要求を提出し（submit）得る。この要求は、ネットワーク７４を通じて伝搬され得、ルータがマルチキャストグループに関連付けられたＩＰアドレスを目的地とする（destined for）トラフィックを、クライアントデバイス４０などの、契約している（subscribing）クライアントデバイスに向けさせられるように、例えば、ルータがネットワーク７４を作り上げる（making up）。

[0055]図１の例において例示されるように、マルチメディアコンテンツ６４は、マニフェストファイル６６を含み、それは、メディアプレゼンテーション記述（ＭＰＤ）に対応し得る。マニフェストファイル６６は、異なる代替的な表現６８（例えば、異なる性質（qualities）を有するビデオサービス）の記述を包含し得、記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現６８の他の記述的な特性を含み得る。クライアントデバイス４０は、表現６８のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを検索し得る。

[0056]特に、検索ユニット５２は、ビデオデコーダ４８の復号機能およびビデオ出力４４のレンダリング機能を決定するために、クライアントデバイス４０の構成データ（図示せず）を検索し得る。構成データはまた、クライアントデバイス４０のユーザによって選択された言語の選好、クライアントデバイス４０のユーザによって設定される深度選好（depth preferences）に対応する１つまたは複数のカメラの遠近法、および／またはクライアントデバイス４０のユーザによって選択される評定選好（rating preference）、のいずれかのまたは全てを含み得る。検索ユニット５２は、例えば、ＨＴＴＰ ＧＥＴ要求およびパーシャルＧＥＴ要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。検索ユニット５２は、クライアントデバイス４０の１つまたは複数のプロセッサまたは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例において、検索ユニット５２に関して説明される機能性のうちの全てまたは部分は、ハードウェアにおいて、またはハードウェア、ソフトウェア、および／またはファームウェアの組合せにおいてインプリメントされ得、ここで、必須の（requisite）ハードウェアは、ソフトウェアまたはファームウェアに関する命令を実行するために提供され得る。

[0057]検索ユニット５２は、クライアントデバイス４０の復号機能およびレンダリング機能をマニフェストファイル６６の情報によって示される表現６８の特性と比較し得る。検索ユニット５２は、初めに、表現６８の特性を決定するためにマニフェストファイル６６の少なくとも一部分を検索し得る。例えば、検索ユニット５２は、１つまたは複数の適応セットの特性を記述するマニフェストファイル６６の一部分を要求し得る。検索ユニット５２は、クライアントデバイス４０のコーディングおよびレンダリング機能によって満たされることができる特性を有する表現６８のサブセット（例えば、適応セット）を選択し得る。検索ユニット５２は、次いで、適応セットにおける表現に関するビットレートを決定し得、ネットワーク帯域幅の現在に利用可能な量を決定し得、およびネットワーク帯域幅によって満たされることができるビットレートを有する表現のうちの１つからセグメントを検索し得る。

[0058]一般に、より高いビットレート表現は、より高い品質のビデオ再生を生み出し得、一方で、より低いビットレート表現は、利用可能なネットワーク帯域幅が減少するとき、十分な品質のビデオ再生を提供し得る。したがって、利用可能なネットワーク帯域幅が、相対的に高いとき、検索ユニット５２は、相対的に高いビットレート表現からデータを検索し得るのに対して、利用可能なネットワーク帯域幅が低いとき、検索ユニット５２は、相対的に低いビットレート表現からデータを検索し得る。このように、クライアントデバイス４０は、また、ネットワーク７４のネットワーク帯域幅の利用可能性を変化させることにも適応しながら、ネットワーク７４上でマルチメディアデータをストリーミングし得る。

[0059]追加的にまたは代替的に、検索ユニット５２は、ｅＭＢＭＳまたはＩＰマルチキャストのような、ブロードキャストまたはマルチキャストネットワークプロトコルに従って、データを受信するように構成され得る。そのような例において、検索ユニット５２は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加入するための要求を提出し得る。マルチキャストグループに加入した後に、検索ユニット５２は、さらなる要求がサーバデバイス６０またはコンテンツ準備デバイス２０に対して発行される（issued）ことなしに、マルチキャストグループのデータを受信し得る。検索ユニット５２は、例えば、再生を止めるためにまたは異なるマルチキャストグループにチャンネル（channels）を変えるために、そのマルチキャストグループのデータがもはや必要とされないとき、そのマルチキャストグループを出る（leave）ための要求を提出し得る。

[0060]ネットワークインターフェース５４は、選択された表現のセグメントのデータを受信し得および検索ユニット５２に提供し得、それは、今度は、ファイルフォーマット処理ユニット５０にセグメントを提供し得る。ファイルフォーマット処理ユニット５０は、ビデオファイルの要素を構成成分（constituent）ＰＥＳストリームにカプセル解除し（decapsulate）得、符号化されたデータを検索するためにＰＥＳストリームを非パケット化し（depacketize）得、および、例えば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化されたデータが音声またはビデオストリームの部分であるかどうかに依存して、音声デコーダ４６かまたはビデオデコーダ４８かのいずれかに符号化されたデータを送り得る。音声デコーダ４６は、符号化された音声データを復号し、復号された音声データを音声出力４２に送り、一方で、ビデオデコーダ４８は、符号化されたビデオデータを復号し、復号されたビデオデータ、それは、ストリームの複数のビューを含み得る、をビデオ出力４４に送る（sends）。

[0061]ビデオエンコーダ２８、ビデオデコーダ４８、音声エンコーダ２６、音声デコーダ４６、カプセル化ユニット３０、検索ユニット５２、およびファイルフォーマット処理ユニット５０は、各々、該当する場合は（as applicable）、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理サーキットリー、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる（any）組み合わせなどの、様々な適した処理サーキットリーのうちのいずれとしてもインプリメントされ得る。ビデオエンコーダ２８およびビデオデコーダ４８の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのどちらも、組み合わされたビデオエンコーダ／デコーダ（ＣＯＤＥＣ）の部分として統合され得る。同様に、音声エンコーダ２６および音声デコーダ４６の各々は、１つまたは複数のエンコーダまたはデコーダにおいて含まれ得、それらのどちらも、組み合わされたコーデック（ＣＯＤＥＣ）の部分として統合され得る。ビデオエンコーダ２８、ビデオデコーダ４８、音声エンコーダ２６、音声デコーダ４６、カプセル化ユニット３０、検索ユニット５２、および／またはファイルフォーマット処理ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／または、セルラ電話などの、ワイヤレス通信デバイスを備え得る。

[0062]クライアントデバイス４０、サーバデバイス６０、および／またはコンテンツ準備デバイス２０は、本開示の技法に従って、動作するように構成され得る。例の目的のために、本開示は、クライアントデバイス４０およびサーバデバイス６０に関してこれらの技法を説明する。しかしながら、コンテンツ準備デバイス２０は、サーバデバイス６０の代わりに（または、それに加えて）、これらの技法を行うように構成され得ることが理解されるべきである。

[0063]カプセル化ユニット３０は、ペイロード、例えば、音声データ、ビデオデータ、またはＮＡＬユニットが対応するトランスポートまたはプログラムストリームを説明するデータ、だけでなく（as well as）、ＮＡＬユニットが属するプログラムを識別するヘッダを備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣにおいて、ＮＡＬユニットは、１バイトのヘッダおよび可変のサイズのペイロードを含む。それのペイロードにおいてビデオデータを含むＮＡＬユニットは、ビデオデータの様々な粒度（granularity）レベルを備え得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全体のピクチャを備え得る。カプセル化ユニット３０は、エレメンタリーストリームのＰＥＳパケットの形態（form）で、ビデオエンコーダ２８から符号化されたビデオデータを受信し得る。カプセル化ユニット３０は、各エレメンタリーストリームを対応するプログラムと関連付け得る。

[0064]カプセル化ユニット３０はまた、複数のＮＡＬユニットからのアクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレームを表すための１つまたは複数のＮＡＬユニットを備え得、なお、そのフレームに対応する音声データもそのような音声データが利用可能であるとき同様である（as well）。アクセスユニットは、一般に、１つの出力時間インスタンスに関して全てのＮＡＬユニット、例えば、１つの時間インスタンスに関して全ての音声およびビデオデータ、を含む。例えば、各ビューが毎秒２０フレーム（ｆｐｓ）のフレームレートを有する場合、各時間インスタンスは、０．０５秒の時間間隔に対応し得る。この時間間隔の間、同じアクセスユニット（同じ時間インスタンス）の全てのビューに関する特定のフレームは、同時にレンダリングされ得る。１つの例において、アクセスユニットは、１つの時間インスタンスにおいてコード化されたピクチャを備え得、それは、プライマリにコード化されたピクチャとして提示され得る。

[0065]したがって、アクセスユニットは、共通の時間インスタンスの全ての音声およびビデオフレーム、例えば、時間Ｘに対応する全てのビュー、を備え得る。本開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント」と呼ぶ。つまり、ビューコンポーネントは、特定の時間における、特定のビューに関する符号化されたピクチャ（またはフレーム）を備え得る。したがって、アクセスユニットは、共通の時間インスタンスの全てのビューコンポーネントを備えるとして定義され得る。アクセスユニットの復号順序は、出力または表示順序と必ずしも同じである必要はない。

[0066]メディアプレゼンテーションは、メディアプレゼンテーション記述（ＭＰＤ）を含み得、それは、異なる代替的な表現（例えば、異なる性質を有するビデオサービス）の記述を包含し得、記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。ＭＰＤは、マニフェストファイル６６のような、マニフェストファイルの１つの例である。クライアントデバイス４０は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定するためにメディアプレゼンテーションのＭＰＤを検索し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス（moof boxes）に位置づけられ得る。

[0067]（例えば、ＭＰＤを備え得る）マニフェストファイル６６は、表現６８のセグメントの利用可能性を宣伝し得る。つまり、ＭＰＤは、表現６８のうちの１つの第１のセグメントが利用可能になる実測時間（wall-clock time）を示す情報、ならびに表現６８内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス４０の検索ユニット５２は、特定のセグメントに先行するセグメントの持続時間ならびに開始時間に基づいて、各セグメントがいつ利用可能であるかを決定し得る。

[0068]カプセル化ユニット３０が、受信されたデータに基づいて、ＮＡＬユニットおよび／またはアクセスユニットをビデオファイルにアセンブルした後に、カプセル化ユニット３０は、ビデオファイルを出力のために出力インターフェース３２に渡す（passes）。いくつかの例において、カプセル化ユニット３０は、ビデオファイルを局所的に記憶し得るか、または、ビデオファイルをクライアントデバイス４０に直接に送るのではなく（rather than）、ビデオファイルを遠隔サーバに出力インターフェース３２を介して送り得る。出力インターフェース３２は、例えば、送信機、トランシーバ、例えば、光学ドライブ、磁気メディアドライブ（例えば、フロッピー（登録商標）ドライブ）、ユニバーサル・シリアル・バス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースなどの、コンピュータ可読媒体にデータを書き込むためのデバイス、を備え得る。出力インターフェース３２は、ビデオファイルを、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブなどの、コンピュータ可読媒体、または他のコンピュータ可読媒体に出力する。

[0069]ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し得、検索ユニット５２を介して、ファイルフォーマット処理ユニット５０にＮＡＬユニットまたはアクセスユニットを提供し得る。ファイルフォーマット処理ユニット５０は、ビデオファイルの要素を構成成分ＰＥＳストリームにカプセル解除し、符号化されたデータを検索するためにＰＥＳストリームを非パケット化し得、および、例えば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化されたデータが音声またはビデオストリームの部分（part）であるかどうかに依存して、音声デコーダ４６かまたはビデオデコーダ４８かのいずれかに符号化されたデータを送り得る。音声デコーダ４６は、符号化された音声データを復号し、復号された音声データを音声出力４２に送り、一方で、ビデオデコーダ４８が符号化されたビデオデータを復号し、復号されたビデオデータ、それは、ストリームの複数のビューを含み得る、をビデオ出力４４に送る。

[0070]コンテンツ準備デバイス２０（例えば、カプセル化ユニット３０を介して）およびクライアントデバイス４０（例えば、ファイルフォーマット処理ユニット５０を介して）は、ビデオコンテンツをカプセル化および／またはカプセル解除するために、多くのファイル形式のうちの１つまたは複数を利用し得る。ＩＳＯＢＭＦＦは、ＡＶＣファイルフォーマットなどの、多くのコーデックカプセル化フォーマットの、ならびにＭＰＥＧ−４ファイルフォーマット、３ＧＰＰファイルフォーマット（３ＧＰ）、およびＤＶＢファイルフォーマットなどの、多くのマルチメディアコンテナフォーマットの、基礎として（as the basis for）使用される。

[0071]音声およびビデオなどの、連続メディアに加えて、画像などの、静的媒体、ならびにメタデータは、ＩＳＯＢＭＦＦに適合するファイルにおいて記憶されることができる。ＩＳＯＢＭＦＦに従って構造化されたファイルは、ローカルメディアファイルプレイバック、遠隔ファイルのプログレッシブダウンローディング、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）のためのセグメント、ストリーミングされることになるコンテンツおよびそれのパケット化の命令のためのコンテナ（containers）、ならびに受信されたリアルタイムメディアストリームの記録を含む、多くの目的に使用され得る。

[0072]ボックスは、４文字のコード化されたボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ＩＳＯＢＭＦＦにおける基本となる（elementary）シンタックス構造である。ＩＳＯＢＭＦＦファイルは、一連のボックスから成り、ボックスは、他のボックスを包含し得る。ムービーボックス（「moov」）は、ファイルにおいて存在する連続メディアストリームに関するメタデータを包含し、各１つは、トラックとしてファイルにおいて表現される。トラックに関するメタデータは、トラックボックス（「trak」）において同封され、一方で、トラックのメディアコンテンツは、メディアデータボックス（「mdat」）において、または直接に別個の（separate）ファイルにおいて、のいずれかで同封される。トラックのメディアコンテンツは、音声またはビデオアクセスユニットなどの、一連のサンプルから成る。

[0073]ＩＳＯＢＭＦＦは、トラックの以下のタイプ：メディアトラック、それはエレメンタリーメディアストリームを包含する、ヒントトラック、それはメディア送信命令を含むかまたは受信されたパケットストリームを表すかのいずれかである、およびタイムドメタデータトラック、それは時間同期されたメタデータを備える、を規定する。

[0074]最初は記憶のために設計されたが、ＩＳＯＢＭＦＦは、ストリーミング、例えば、プログレッシブダウンロードまたはＤＡＳＨに対して、非常に有益であることを証明した。ストリーミングの目的のために、ＩＳＯＢＭＦＦにおいて定義されたムービーフラグメントが使用されることができる。

[0075]各トラックに関するメタデータは、サンプル記述エントリーのリストを含み、各々は、トラックにおいて使用されるコーディングまたはカプセル化フォーマットおよびそのフォーマットを処理するために必要とされる初期化データを提供する。各サンプルは、トラックのサンプル記述エントリーのうちの１つに関連付けられる。

[0076]ＩＳＯＢＭＦＦは、様々な機構を有するサンプル固有のメタデータを特定することを可能にする。サンプルテーブル（Sample Table）ボックス（「stbl」）内の特定のボックスは、共通の必要性に答えるために（to respond to common needs）標準化された。例えば、シンクサンプル（Sync Sample）ボックス（「stss」）が、トラックのランダムアクセスサンプルをリストするために使用される。サンプルグループ化機構は、ファイルにおいてサンプルグループ記述エントリーとして規定される同じプロパティを共有するサンプルのグループの中への４文字のグループ化タイプに従ったサンプルのマッピングをイネーブルする。様々なグループ化タイプは、ＩＳＯＢＭＦＦにおいて規定されている。

[0077]ＩＳＯＢＭＦＦ仕様は、ＤＡＳＨを伴う使用のためのＳｔｒｅａｍ Ａｃｃｅｓｓ Ｐｏｉｎｔｓ（ＳＡＰ）の６つのタイプを規定する。最初の２つのＳＡＰタイプ（タイプ１および２）は、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおけるＩＤＲピクチャに対応する。第３のＳＡＰタイプ（タイプ３）は、オープンＧＯＰ（open-GOP）ランダムアクセスポイント、故に、ＨＥＶＣにおけるＢＬＡまたはＣＲＡピクチャに対応する（corresponds to open-GOP random access points hence BLA or CRA pictures in HEVC）。第４のＳＡＰタイプ（タイプ４）は、ＧＤＲランダムアクセスポイントに対応する。

[0078]ＩＳＯ／ＩＥＣ１４４９６−１５において、（またサンプルエントリーネームとも呼ばれる）様々なサンプルエントリータイプが規定されている。

[0079]ＨＥＶＣファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５の条項（clause）８）において、サンプルエントリータイプ'hvc1'および'hev1'が規定されている。サンプルエントリータイプ'hev1'に関する制約は、以下のように規定されている：

[0080]サンプルエントリーネームが'hev1'であるとき、以下が適用される。

[0081]サンプルがランダムアクセスポイントである場合、そのサンプルを復号するために必要とされる全てのパラメータセットは、サンプルエントリーにおいて、またはサンプルそれ自体において、のいずれかに含まれるものとする。

[0082]さもなければ（サンプルがランダムアクセスポイントでない）、サンプルを復号するために必要とされる全てのパラメータセットは、サンプルエントリーにおいて、または前のランダムアクセスポイントからサンプルそれ自体までの両端を含むサンプルのうちのいずれかにおいて、のいずれかに含まれるものとする。

[0083]この制約の目的はまた、より早いサンプルからパラメータセットを探索することおよび／またはフェッチすることの必要性なしに、ランダムアクセスポイントであるサンプルからの、便利なランダムアクセスをイネーブルすることである。

[0084]レイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５の条項９）において、サンプルエントリータイプ'hvc2'、'hev2'、'lhv1'および'lhe1'が規定されている。サンプルエントリータイプ'lhe1'に関する制約は、以下のように規定されている：

[0085]サンプルエントリーネームが'lhe1'であるとき、以下が適用される。

[0086]下記の制約は、少なくともいくつかのレイヤにおいてＩＲＡＰピクチャを包含するアクセスユニットからの便利なランダムアクセスをイネーブルするために、（サンプルエントリーにおける）帯域外パラメータセットおよび（サンプルにおける）帯域内（in-band）パラメータセットの配置（placement）に制限を課す。これらの制約があるので、それらサンプルエントリーを用いて初期化して、全てのピクチャがＩＲＡＰピクチャであるアクセスユニットからロールフォワードする（rolls forward）ファイルリーダは、それが必要とする全てのパラメータセットを有するであろう。

[0087]特定のトラックにおける任意の特定のサンプルに関して、別のトラックにおいて時間的に配列された（temporally collocated）サンプルは、この特定のサンプルのものと同じ復号時間を有するもの（the one）として定義される。

[0088]所与のサンプルのＩＲＡＰピクチャ、トラックおよびレイヤに関して、ＩＲＡＰピクチャを復号するために必要とされる各パラメータセットは、以下のうちの１つにおいて含まれるものとする：
ａ．所与のトラックにおける所与のサンプルに適用するサンプルエントリー
ｂ．所与のレイヤの参照レイヤを運ぶトラックの初期サンプルのサンプルエントリー、ここで、初期サンプルは、時間的に配列されたサンプルが参照レイヤのＩＲＡＰピクチャを包含するとき、所与のサンプルの時間的に配列されたサンプルであるか、または参照レイヤのＩＲＡＰピクチャを包含する前のサンプルであるかのいずれかである。
ｃ．場合によりエクストラクタを使用して、所与のサンプルそれ自体
ｄ．存在するとき、場合によりエクストラクタを使用して、所与のレイヤの参照レイヤを運ぶトラックの任意の時間的に配列されたサンプル

[0089]所与のサンプルの非ＩＲＡＰピクチャに関して、トラックおよびレイヤは、そのピクチャを復号するために必要とされる各パラメータセットは、以下のうちの１つにおいて含まれるものとする：
ａ．所与のトラックにおける所与のサンプルに適用するサンプルエントリー
ｂ．所与のレイヤの参照レイヤを運ぶトラックの初期サンプルのサンプルエントリー、ここで、初期サンプルは、時間的に配列されたサンプルが参照レイヤのＩＲＡＰピクチャを包含するとき、所与のサンプルの時間的に配列されたサンプルであるか、または参照レイヤのＩＲＡＰピクチャを包含する前のサンプルであるかのいずれかである。
ｃ．場合によりエクストラクタを使用して、所与のレイヤにおけるＩＲＡＰピクチャを包含する前のサンプルから、所与のサンプルそれ自体までの両端を含む、所与のトラックにおけるサンプルのうちのいずれか
d．存在するとき、場合によりエクストラクタを使用して、所与のレイヤにおいてＩＲＡＰピクチャを包含する前のサンプルの時間的に配列されたサンプルから（since）、所与のサンプルの時間的に配列されたサンプルまで（to）の両端を含む、所与のレイヤの参照レイヤを運ぶトラックにおけるサンプルのうちのいずれか

[0090]この制約の目的もまた、制約の記述の部分として上記に詳細に記述されるように、複数のレイヤを包含するビットストリームを別にすれば（but）、便利なランダムアクセスをイネーブルすることである。

[0091]（下記にコピーされる）ＩＳＯ／ＩＥＣ１４４９６−１５の表１０は、ＨＥＶＣトラックおよびＬ−ＨＥＶＣトラックのためのＬ−ＨＥＶ Ｃツール、構成、およびサンプルエントリーの全ての可能な用途を示す。

[0092]本開示は、（例えば、ＩＳＯ／ＩＥＣ１４４９６−１５の箇条８および９における）ＨＥＶＣおよびＬ−ＨＥＶＣに関するファイルフォーマットにおけるサンプルエントリータイプの現在の設計が様々な問題を提示し得ることを認識する。例えば。

[0093]第１の潜在的な問題を説明するために、ＩＳＯ／ＩＥＣ１４４９６−１５の表１０の行２は、以下のように述べていることに留意されたい。

[0094]一方で、ＩＳＯ／ＩＥＣ１４４９６−１５の表１０の行４は、以下のように述べている。

[0095]サンプルエントリータイプが'hvc1'、'hev1'、'hvc2'、または'hev2'であり、および同じエントリーがＨＥＶＣ構成およびＬ−ＨＥＶＣ構成の両方を包含するとき、トラックは、ベースレイヤおよび１つまたは複数の拡張（enhancement）レイヤの両方のデータを運ぶ。

[0096]しかしながら、複数のレイヤを包含するビットストリームを別にした（but for）便利なランダムアクセスをイネーブルする制約は、サンプルエントリータイプ'lhe1'に関してのみ、規定される。これは、マルチレイヤＬ−ＨＥＶＣビットストリームがサンプルエントリータイプ'hvc1'、'hev1'、'hvc2'、および'hev2'のうちのいずれかを使用して記憶されるとき、便利なランダムアクセスが（より早いサンプルからパラメータセットを探索することおよびフェッチすることを必要とせずに、など）イネーブルされていることを保証しおよび示す方法がないことを意味する。

[0097]本開示の技法は、上記で議論された第１の潜在的な問題に対処する（address）ために使用され得る。特に、１つの例において、複数のレイヤのデータを包含するトラックに関するより早いサンプルからパラメータセットを探索することおよびフェッチすることを必要とせずに、便利なランダムアクセスをイネーブルするための制約は、サンプルエントリーがＨＥＶＣ構成およびＬ−ＨＥＶＣ構成の両方を包含するとき、サンプルエントリータイプ'hev1'および'hev2'に関して規定される。それ故、コンテンツ準備デバイス２０は、より早いサンプルからパラメータセットを探索することおよびフェッチすることが必要とされ（required）ないように、必要なパラメータセットがサンプルエントリーおよび／または'hev1'および'hev2'のサンプルエントリータイプを有するサンプルと一緒に提供されることを確かにし（ensure）得る。同様に、クライアントデバイス４０は、ビデオ復号順序においていずれの前のサンプルのパラメータセットを検索することなしに、サンプルエントリーおよび'hev1'または'hev2'のサンプルエントリータイプを有するサンプルを検索し得およびランダムアクセスを行い得る。

[0098]第２の潜在的な問題を説明するために、ＩＳＯ／ＩＥＣ１４４９６−１５の表１０の行３は、以下のように述べていることに留意されたい。

[0099]サンプルエントリータイプが'hvc2'または'hev2'であり、同じエントリーがＨＥＶＣ構成のみを包含するとき、以下のシナリオのいずれかが起こり得る。（１）トラックは、全体のシングルレイヤＨＥＶＣビットストリームを運び、ここにおいて、ＶＣＬ ＮＡＬユニットは全て、０に等しいnuh_layer_idを有する、およびいくつかのエクストラクタおよび／またはアグリゲータが存在する；または（２）トラックは、そのようなシングルレイヤＨＥＶＣビットストリームのサブセットを運び、サブセットは、（エクストラクタおよび／またはアグリゲータがあるかどうかに関わらず）０よりも大きいTemporalIdのみを有するＶＣＬ ＮＡＬユニットを包含する。

[0100]しかしながら、サンプルエントリータイプ'hvc2'および'hev2'のいずれも、サンプルエントリータイプ'hev1'に関して同様に便利なランダムアクセスをイネーブルすることを強いられて（constrained）いなかった。これは、上記の２つのシナリオに関して、便利なランダムアクセスが（より早いサンプルからパラメータセットを探索することおよびフェッチすることを必要とせずに（without needing of searching and fetch parameter sets from earlier samples））イネーブルされていることを保証しおよび示す方法がないことを意味する。

[0101]本開示はまた、第２の潜在的な問題を解決するために使用され得る技法を説明する。特に、制約は、全体のシングルレイヤＨＥＶＣビットストリームまたはそれのサブセットのみを包含するトラックに関するより早いサンプルからパラメータセットを探索することおよびフェッチすることを必要とせずに、便利なランダムアクセスをイネーブルするために、サンプルエントリーがＨＥＶＣ構成のみを包含するとき、サンプルエントリータイプ'hev2'は使用されることになる（is to be used）ことが規定され得る。それ故、サンプルエントリーがＨＥＶＣ構成のみを包含するとき、コンテンツ準備デバイス２０は、'hev2'のサンプルエントリータイプを特定し得る。同様に、クライアントデバイス４０は、便利なランダムアクセスがサンプルエントリータイプ'hev2'を有するサンプルに関してイネーブルされること、その上、サンプルが、Ｌ−ＨＥＶＣ構成ではなく、ＨＥＶＣ構成のみに従って符号化されたビデオデータを含むことを決定し得る。

[0102]第３の潜在的な問題を説明するために、マルチレイヤＬ−ＨＥＶＣビットストリームの各全体のレイヤが、現在の仕様に従って、別個のトラックにおいて記憶されるとき、ベーストラックがＨＥＶＣ構成のみを有するサンプルエントリータイプ'hev1'を使用すること、および他のトラックがＬ−ＨＥＶＣ構成のみを有するサンプルエントリータイプ'lhv1'を使用することが可能であること、ならびにベーストラックがＨＥＶＣ構成のみを有するサンプルエントリータイプ'hvc1'を使用すること、および他のトラックがＬ−ＨＥＶＣ構成のみを有するサンプルエントリータイプ'lhe1'を使用することもまた可能であること、を留意されたい。

[0103]第１のシナリオにおいて、便利なランダムアクセスはベーストラックに関して示されるが、他のトラックに関しては示されない。第２のシナリオにおいて、便利なランダムアクセスはベーストラックに関して示されないが、他のトラックに関して示される。第１のシナリオに関して、ベーストラックが便利なランダムアクセスをイネーブルするオーバーヘッドを正当化する（justify）のに十分に重要である一方で、拡張レイヤを運ぶトラックに関してより少ないオーバーヘッドのために便利なランダムアクセスを諦めるという妥協がよいトレードオフ（good tradeoff）であると考えられるといった、もっともらしい弁解（plausible excuse）があり得る。しかしながら、第２のシナリオは、拡張レイヤを運ぶトラックに関して便利なランダムアクセスをイネーブルすることが、ベーストラックに関して便利なランダムアクセスをイネーブルすることを効率的に必要とするであろうため（as）、意味をなさず、ベーストラックに関してそれがイネーブルされる場合、正しい（the right）サンプルエントリータイプ、すなわち、'hev1'を使用することによってそれを示さないという道理はない。

[0104]同様に、第３の潜在的な問題はまた、複数の時間サブレイヤを包含するシングルレイヤＨＥＶＣビットストリームが複数のトラックによって運ばれるとき、適用され得、ここで、（それのＶＣＬ ＮＡＬユニットが０に等しいTemporalIdを有する）最も低いサブレイヤを運ぶトラックは、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを使用し、一方（while）、他のトラックが便利なランダムアクセスがイネーブルされていることを示さないサンプルエントリータイプを使用する、または逆もまた同様である。

[0105]本開示の技法はまた、第３の潜在的な問題に対処し得る。特に、制約は、（ＨＥＶＣ、Ｌ−ＨＥＶＣ、またはあらゆる他のコーデックによってコード化された）シングルレイヤまたはマルチレイヤのビットストリームを運ぶ全てのトラックに関して、全てのトラックが便利なランダムアクセスがイネーブルされていることを示す（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う）サンプルエントリータイプを使用するか、または全てのトラックが便利なランダムアクセスがイネーブルされていることを示さない（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う（together with））サンプルエントリータイプを使用するかのいずれかを必要とするように規定され得る。それ故、コンテンツ準備デバイス２０は、シングルレイヤまたはマルチレイヤのビットストリームを運ぶトラックに関して、トラックのうちの全てが便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを使用するか、またはトラックのうちの全てが便利なランダムアクセスがイネーブルされていないことを示すサンプルエントリータイプを使用するかのいずれかを確かにし得る。このように、便利なランダムアクセスがトラックのうちの１つに関してイネーブルされている場合、クライアントデバイス４０は、便利なランダムアクセスがトラックの各々に関してイネーブルされていることを決定し得る。

[0106]代替的に、制約は、（ＨＥＶＣ、Ｌ−ＨＥＶＣ、またはあらゆる他のコーデックによってコード化された）シングルレイヤまたはマルチレイヤのビットストリームを運ぶ全てのトラックに関して、ベースレイヤの（ＶＣＬ ＮＡＬユニットが０に等しいTemporalIdを有する）最も低いサブレイヤを運ぶトラックが、便利なランダムアクセスがイネーブルされていることを示す（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う）サンプルエントリータイプを使用するとき、全ての他のトラックは、便利なランダムアクセスがイネーブルされていることを示す（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う）サンプルエントリータイプを使用するもの（shall）とすることを必要とする（require）ように規定され得る。それ故、コンテンツ準備デバイス２０は、シングルレイヤまたはマルチレイヤのビットストリームを運ぶトラックに関して、ベースレイヤの最も低い時間サブレイヤを運ぶトラックが、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを使用するとき、トラックの全てが便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを使用すること、または代替的に、便利なランダムアクセスが、ベースレイヤの最も低い時間サブレイヤに関してイネーブルされていない場合、トラックのうちのどれもが、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを使用しないこと、を確かにし得る。このように、便利なランダムアクセスが、ベースレイヤの最も低い時間サブレイヤを含むトラックに関してイネーブルされている場合、クライアントデバイス４０は、便利なランダムアクセスがトラックの各々に関してイネーブルされていることを決定し得る。

[0107]クライアントデバイス４０は、様々な方法で便利なランダムアクセスを行うための本開示の技法を使用し得る。例えば、クライアントデバイス４０は、ＤＡＳＨのような、ネットワークストリーミングプロトコルを使用して、サーバデバイス６０からデータを要求することによって便利なランダムアクセスを行い得る。他の例において、クライアントデバイス４０は、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ハードドライブ、フラッシュメモリ、または同種のもののような、固定式コンピュータ可読記憶媒体からメディアデータを検索するために便利なランダムアクセスを行うために、本開示の技法を使用し得る。それ故、図１は、ネットワークベースのストリーミングを含む例を例示するが、本開示の技法が他のシナリオおよびコンテキストにも同様に適用され得ることが理解されるべきである。

[0108]図２は、図１の検索ユニット５２のコンポーネントの例となるセットを、より詳細に例示するブロック図である。この例において、検索ユニット５２は、ｅＭＢＭＳミドルウェアユニット１００、ＤＡＳＨクライアント１１０、およびメディアアプリケーション１１２を含む。

[0109]この例において、ｅＭＢＭＳミドルウェアユニット１００は、ｅＭＢＭＳ受信ユニット１０６、キャッシュ１０４、およびサーバユニット１０２をさらに含む。この例において、ｅＭＢＭＳ受信ユニット１０６は、http://tools.ietf.org/html/rfc6726において入手可能である、T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、ネットワークワーキンググループ、ＲＦＣ６７２６、２０１２年１１月、において説明される、例えば、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）に従って、ｅＭＢＭＳを介してデータを受信するように構成される。つまり、ｅＭＢＭＳ受信ユニット１０６は、例えば、サーバデバイス６０、それは、ＢＭ−ＳＣとして振る舞い得る、からのブロードキャストを介して、ファイルを受信し得る。

[0110]ｅＭＢＭＳミドルウェアユニット１００がファイルに関するデータを受信する時に、ｅＭＢＭＳミドルウェアユニットは、キャッシュ１０４において受信されたデータを記憶し得る。キャッシュ１０４は、フラッシュメモリ、ハードディスク、ＲＡＭ、または任意の他の適した記憶媒体などの、コンピュータ可読記憶媒体を備え得る。

[0111]ローカルサーバユニット１０２は、ＤＡＳＨクライアント１１０のためのサーバとして振る舞い得る。例えば、ローカルサーバユニット１０２は、ＭＰＤファイルまたは他のマニフェストファイルをＤＡＳＨクライアント１１０に提供し得る。ローカルサーバユニット１０２は、ＭＰＤファイルにおけるセグメントに関する利用可能時間（availability times）、ならびに、セグメントが検索されることができるハイパーリンクを宣伝し得る。これらのハイパーリンクは、クライアントデバイス４０（例えば、ＩＰｖ４に関する１２７．０．０．１）に対応するローカルホストアドレスプリフィックスを含み得る。このように、ＤＡＳＨクライアント１１０は、ＨＴＴＰ ＧＥＴまたはパーシャルＧＥＴ要求を使用して、ローカルサーバユニット１０２からセグメントを要求し得る。例えば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、ＤＡＳＨクライアント１１０は、http://127.0.0.1/rep1/seg3を求める要求（request for）を含むＨＴＴＰ ＧＥＴ要求を構築し得、その要求をローカルサーバユニット１０２に提出し得る。ローカルサーバユニット１０２は、キャッシュ１０４から要求されたデータを検索し得、そのような要求に応答して、データをＤＡＳＨクライアント１１０に提供し得る。

[0112]図３は、例となるマルチメディアコンテンツ１２０の要素を例示する概念図である。マルチメディアコンテンツ１２０は、マルチメディアコンテンツ６４（図１）、または記憶媒体６２において記憶された別のマルチメディアコンテンツに対応し得る。図３の例において、マルチメディアコンテンツ１２０は、メディアプレゼンテーション記述（ＭＰＤ）１２２および複数の表現１２４Ａ〜１２４Ｎ（表現１２４）を含む。表現１２４Ａは、随意的な（optional）ヘッダデータ１２６およびセグメント１２８Ａ〜１２８Ｎ（セグメント１２８）を含み、一方で、表現１２４Ｎは、随意的なヘッダデータ１３０およびセグメント１３２Ａ〜１３２Ｎ（セグメント１３２）を含む。文字（letter）Ｎは、便宜上（as a matter of convenience）、表現１２４の各々において、最後のムービーフラグメントを指定するために使用される。いくつかの例において、表現１２４の間で異なる数のムービーフラグメントがあり得る。

[0113]ＭＰＤ１２２は、表現１２４とは別個の（separate from）データ構造を備え得る。ＭＰＤ１２２は、図１のマニフェストファイル６６に対応し得る。同様に、表現１２４は、図２の表現６８に対応し得る。一般に、ＭＰＤ１２２は、一般に、コーディングおよびレンダリング特性、適応セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラ角度情報、評定情報、トリックモード情報（例えば、時間サブシーケンス（temporal sub-sequences）を含む表現を示す情報）、および／または（例えば、再生中の、メディアコンテンツへの的を絞った宣伝の挿入（targeted advertisement insertion)のための）遠隔期間（remote periods）を検索するための情報などの、表現１２４の特性を記述するデータを含み得る。

[0114]ヘッダデータ１２６は、存在するとき、セグメント１２８の特性を記述し得、例えば、（ＲＡＰ、またストリームアクセスポイント（ＳＡＰ）とも呼ばれる）ランダムアクセスポイントの時間的なロケーション（temporal locations）、セグメント１２８のそれは、ランダムアクセスポイント、セグメント１２８内のランダムアクセスポイントへのバイトオフセット、セグメント１２８のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１２８の他の態様を含む。ヘッダデータ１３０は、存在するとき、セグメント１３２に関する類似の特性を記述し得る。追加的にまたは代替的に、そのような特性は、ＭＰＤ１２２内に完全に（fully）含まれ得る。

[0115]セグメント１２８、１３２は、１つまたは複数のコード化されたビデオサンプルを含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント１２８のコード化されたビデオサンプルの各々は、類似の特性、例えば、高さ、幅、および帯域幅の必須要件（requirements）、を有し得る。そのような特性は、ＭＰＤ１２２のデータによって記述され得るが、そのようなデータは、図３の例において例示されていない。ＭＰＤ１２２は、本開示において説明された示唆された（signaled）情報のうちの任意のまたは全てを加えて、３ＧＰＰ仕様書によって説明されるような、特性を含み得る。

[0116]セグメント１２８、１３２の各々は、固有のユニフォームリソースロケータ（ＵＲＬ）に関連付けられ得る。それ故、セグメント１２８、１３２の各々は、ＤＡＳＨのような、ストリーミングネットワークプロトコルを使用して、独立して検索可能であり（retrievable）得る。このように、クライアントデバイス４０などの、宛先デバイスは、セグメント１２８または１３２を検索するためにＨＴＴＰ ＧＥＴ要求を使用し得る。いくつかの例において、クライアントデバイス４０は、セグメント１２８または１３２の特定のバイト範囲を検索するために、ＨＴＴＰパーシャルＧＥＴ要求を使用し得る。

[0117]図４は、例となるビデオファイル１５０の要素を例示するブロック図であり、それは、図３のセグメント１１４、１２４のうちの１つのような、表現のセグメントに対応し得る。セグメント１２８、１３２の各々は、図４の例において例示されるデータの配列（arrangement）に実質的に適合するデータを含み得る。ビデオファイル１５０は、セグメントをカプセル化するように示され（said）得る。上記で説明されるように、ＩＳＯベースメディアファイルフォーマットに従うビデオファイルおよびそれの拡張は、「ボックス」と呼ばれる、一連のオブジェクトに、データを記憶する。図４の例において、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２、ムービー（ＭＯＯＶ）ボックス１５４、セグメントインデックス（ｓｉｄｘ）ボックス１６２、ムービーフラグメント（ＭＯＯＦ）ボックス１６４、およびムービーフラグメントランダムアクセス（ＭＦＲＡ）ボックス１６６を含む。図４は、ビデオファイルの例を表すが、他のメディアファイルが、ＩＳＯベースメディアファイルフォーマットおよびそれの拡張に従って、ビデオファイル１５０のデータと同様に構造化されたメディアデータ（例えば、音声データ、タイムドテキストデータ、または同種のもの）の他のタイプを含み得ることは理解されるべきである。

[0118]ファイルタイプ（ＦＴＹＰ）ボックス１５２は、一般に、ビデオファイル１５０に関するファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０に関する最善の使用（best use）を説明する仕様を識別するデータを含み得る。ファイルタイプボックス１５２は、代替的に、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に、置かれ得る。

[0119]いくつかの例において、ビデオファイル１５０などの、セグメントは、ＦＴＹＰボックス１５２の前に、ＭＰＤアップデートボックス（図示せず）を含み得る。ＭＰＤアップデートボックスは、ビデオファイル１５０を含む表現に対応するＭＰＤが、ＭＰＤを更新するための情報と共に、更新されることになる（is to be updated）ことを示す情報を含み得る。例えば、ＭＰＤアップデートボックスは、ＭＰＤをアップデートするために使用されることになるリソースに関してＵＲＩまたはＵＲＬを提供し得る。別の例として、ＭＰＤアップデートボックスは、ＭＰＤをアップデートするためのデータを含み得る。いくつかの例において、ＭＰＤアップデートボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示せず）に直ちに続き（immediately follow）得、ここで、ＳＴＹＰボックスは、ビデオファイル１５０に関するセグメントタイプを定義し得る。下記にさらに詳細に議論される、図７は、ＭＰＤアップデートボックスに関する追加情報を提供する。

[0120]ＭＯＯＶボックス１５４は、図４の例において、ムービーヘッダ（ＭＶＨＤ）ボックス１５６、トラック（ＴＲＡＫ）ボックス１５８、および１つまたは複数のｍｏｖｉｅ ｅｘｔｅｎｄｓ（ＭＶＥＸ）ボックス１６０を含む。一般に、ＭＶＨＤボックス１５６は、ビデオファイル１５０の一般的な特性を記述し得る。例えば、ＭＶＨＤボックス１５６は、ビデオファイル１５０がいつ最初に（originally）作成されたか、ビデオファイル１５０がいつ最後に修正されたか、ビデオファイル１５０に関する時間尺度（timescale）、ビデオファイル１５０に関する再生の持続時間、を記述するデータ、または一般にビデオファイル１５０を記述する他のデータを含み得る。

[0121]ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックに関するデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を説明するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例において、ＴＲＡＫボックス１５８は、コード化されたビデオピクチャを含み得、一方で、他の例において、トラックのコード化されたビデオピクチャは、ムービーフラグメント１６４において含まれ得、それは、ＴＲＡＫボックス１５８および／またはｓｉｄｘボックス１６２のデータによって言及され得る。

[0122]いくつかの例において、ビデオファイル１５０は、１つより多くのトラックを含み得る。したがって、ＭＯＯＶボックス１５４は、ビデオファイル１５０におけるトラックの数に等しい数のＴＲＡＫボックスを含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。例えば、ＴＲＡＫボックス１５８は、対応するトラックに関する時間的および／または空間的情報を記述し得る。ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様のＴＲＡＫボックスは、カプセル化ユニット３０（図３）が、ビデオファイル１５０などの、ビデオファイルにおいてパラメータセットトラックを含むとき、パラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットラックを記述するＴＲＡＫボックス内のパラメータセットラックにおけるシーケンスレベルのＳＥＩメッセージの存在をシグナリングし得る。

[0123]ＭＶＥＸボックス１６０は、例えば、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、もしあれば（if any）、ビデオファイル１５０がムービーフラグメント１６４を含むことをシグナリングするために、対応するムービーフラグメント１６４の特性を記述し得る。ストリーミングビデオデータのコンテキストにおいて、コード化されたビデオピクチャは、ＭＯＯＶボックス１５４においてではなく、ムービーフラグメント１６４において含まれ得る。したがって、全てのコード化されたビデオサンプルは、ＭＯＯＶボックス１５４においてではなく、ムービーフラグメント１６４において、含まれ得る。

[0124]ＭＯＯＶボックス１５４は、ビデオファイル１５０におけるムービーフラグメント１６４の数に等しい数のＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６４のうちの対応する１つの特性を記述し得る。例えば、各ＭＶＥＸボックスは、ムービーフラグメント１６４のうちの対応する１つに関する時間的な持続時間を記述するｍｏｖｉｅ ｅｘｔｅｎｄｓ ｈｅａｄｅｒ ｂｏｘ（ＭＥＨＤ）ボックスを含み得る。

[0125]上で述べたように、カプセル化ユニット３０は、実際にコード化されたビデオデータを含まないビデオサンプルにおいて、シーケンスデータセットを記憶し得る。ビデオサンプルは、一般に、アクセスユニットに対応し得、それは、特定の時間インスタンスにおけるコード化されたピクチャの表現である。ＡＶＣのコンテキストにおいて、コード化されたピクチャは、アクセスユニットの全ての画素を構築するための情報を包含する１つまたは複数のＶＣＬ ＮＡＬユニット、および、ＳＥＩメッセージのような、他の関連付けられた非ＶＣＬ ＮＡＬユニットを含む。したがって、カプセル化ユニット３０は、ムービーフラグメント１６４のうちの１つにおいて、シーケンスデータセットを含み得、それは、シーケンスレベルＳＥＩメッセージを含み得る。カプセル化ユニット３０は、シーケンスデータセットおよび／またはシーケンスレベルＳＥＩメッセージの存在を、ムービーフラグメント１６４のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内でムービーフラグメント１６４のうちの１つにおいて存在しているとして、さらにシグナリングし得る。

[0126]ＳＩＤＸボックス１６２は、ビデオファイル１５０の随意的な要素である。つまり、３ＧＰＰファイルフォーマットに適合するビデオファイル、またはそのようなファイル形式は、ＳＩＤＸボックス１６２を必ずしも含まない。３ＧＰＰファイルフォーマットの例に従って、ＳＩＤＸボックスは、セグメント（例えば、ビデオファイル１５０内に包含されるセグメント）のサブセグメントを識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを、「対応する（１つまたは複数の）メディアデータボックスを有する１つまたは複数の連続するムービーフラグメントボックスの自己完結型（self-contained）のセットであり、およびムービーフラグメントボックスによって言及される（referenced）データを包含するメディアデータボックスは、そのムービーフラグメントボックスに続かなければならず、および同じトラックについての情報を包含する次のムービーフラグメントボックスに先行しなければならない」と定義する。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが「ボックスによって文書で記録された（documented）（サブ）セグメントのサブセグメントへの一連への言及（references）を包含することを示す。言及されたサブセグメントは、プレゼンテーション時間において、連続的である。同様に、セグメントインデックスボックスによって言及されたバイトは、常にそのセグメント内で連続的である。言及されたサイズは、言及された資料（material）においてバイトの数のカウントを与える。」

[0127]ＳＩＤＸボックス１６２は、一般に、ビデオファイル１５０において含まれるセグメントの１つまたは複数のサブセグメントを代表する情報を提供する。例えば、そのような情報は、サブセグメントが始まりおよび／または終了する再生時間（playback times）、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（例えば、ストリームアクセスポイント（ＳＡＰ）から開始する）かどうか、ＳＡＰに関するタイプ（例えば、ＳＡＰが瞬間デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャであるか、クリーンランダムアクセス（ＣＲＡ）ピクチャであるか、ブロークンリンクアクセス（ＢＬＡ）ピクチャであるか、または同種のものであるか）、サブセグメントにおける（再生時間および／またはバイトオフセットの観点からの）ＳＡＰの位置、および同類のもの、を含み得る。

[0128]ムービーフラグメント１６４は、１つまたは複数のコード化されたビデオピクチャを含み得る。いくつかの例において、ムービーフラグメント１６４は、ピクチャの１つまたは複数のグループ（ＧＯＰ）を含み得、それらの各々は、複数のコード化されたビデオピクチャ、例えば、フレームまたはピクチャ、を含み得る。加えて、上記で説明されるように、ムービーフラグメント１６４は、いくつかの例において、シーケンスデータセットを含み得る。ムービーフラグメント１６４の各々は、ムービーフラグメントヘッダボックス（ＭＦＨＤ、図４において示されない）を含み得る。ＭＦＨＤボックスは、ムービーフラグメントに関するシーケンス番号のような、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント１６４は、ビデオファイル１５０におけるシーケンス番号順に（in order of sequence number）含まれ得る。

[0129]ＭＦＲＡボックス１６６は、ビデオファイル１５０のムービーフラグメント１６４内で、ランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０によってカプセル化されたセグメント内の特定の時間的なロケーション（すなわち、再生時間）への捜索（seeks）を行うなどの、トリックモードを行うことを支援し得る。ＭＦＲＡボックス１６６は、いくつかの例において、一般に、随意的であり、ビデオファイルに含まれることを必要としない。同様に、クライアントデバイス４０のような、クライアントデバイスは、ビデオファイル１５０のビデオデータを正しく復号しおよび表示するためにＭＦＲＡボックス１６６を言及することを必ずしも必要としない。ＭＦＲＡボックス１６６は、ビデオファイル１５０のトラックの数に等しい、またはいくつかの例において、ビデオファイル１５０のメディアトラック（例えば、非ヒントトラック）の数に等しい、複数の（a number of）トラックフラグメントランダムアクセス（ＴＦＲＡ）ボックス（図示せず）を含み得る。

[0130]いくつかの例において、ムービーフラグメント１６４は、ＩＤＲピクチャのような、１つまたは複数のストリームアクセスポイント（ＳＡＰ）を含み得る。同様に、ＭＦＲＡボックス１６６は、ＳＡＰのビデオファイル１５０内のロケーションのインジケーションを提供し得る。したがって、ビデオファイル１５０の時間サブシーケンスは、ビデオファイル１５０のＳＡＰから形成され得る。時間サブシーケンスはまた、ＳＡＰに従属する（depend from）Ｐフレームおよび／またはＢフレームなどの他のピクチャを含み得る。時間サブシーケンスのフレームおよび／またはスライスは、そのサブシーケンスの他のフレーム／スライスに依存する時間サブシーケンスのフレーム／スライスが適切に復号されることができるように、セグメント内で配列され得る。例えば、データの階層的な配列において、他のデータに関する予測のために使用されるデータはまた、時間サブシーケンスに含まれ得る。

[0131]ビデオファイル１５０はまた、この例において、サンプル記述ボックス１６８を包含し得る。特に、サンプル記述ボックス１６８は、この例において、ＴＲＡＫボックス１５８内に含まれる。例となるサンプル記述ボックス１６８は、以下のように定義され得る：

[0132]サンプルエントリーおよびボックスタイプ：'hvc2'、hev2'、'lhv1'、'lhe1'、'lhvC'
・コンテナ：サンプル記述ボックス（'stsd'）
・必須（Mandatory）：'hvc1'、'hev1'、'hvc2'、'hev2'、'lhv1'、または'lhe1'サンプルエントリーが必須である
・量：１つまたは複数のサンプルエントリーが存在し得る

[0133]サンプル記述ボックス１６８に関するこの例となる定義において、サンプルエントリーネームが'lhv1'であるとき、array_completenessのデフォルトおよび必須の値は、パラメータセットの全てのタイプのアレイ（arrays）に関して１であり、全ての他のアレイに関しては０である。サンプルエントリーネームが、'lhe1'のとき、array_completenesのデフォルト値は、全てのアレイに関して０である。

[0134]サンプル記述ボックス１６８についてのこの例となる定義において、サンプルエントリーネームが'hev2'であり、サンプルエントリーがＨＥＶＣ構成のみを包含するとき、サンプルエントリーネーム'hev1'に関して条項８．４．３において規定されたのと同じ制約が、適用する。

[0135]サンプル記述ボックス１６８についてのこの例となる定義において、サンプルエントリーネームが'lhe1'であるとき、またはサンプルエントリーネームが'hev1'または'hev2'であり、およびそのサンプルエントリーが、ＨＥＶＣ構成およびＬ−ＨＥＶＣ構成の両方を包含するとき、以下が適用される。

[0136]下記の例となる制約は、少なくともいくつかのレイヤにおいてＩＲＡＰピクチャを包含するアクセスユニットからの便利なランダムアクセスをイネーブルするために、（サンプルエントリーにおける）帯域外パラメータセットおよび（サンプルにおける）帯域内パラメータセットの配置に制限を課す。これらの制約があるので（With these constraints）、それらサンプルエントリーを用いて初期化して、全てのピクチャがＩＲＡＰピクチャであるアクセスユニットからロールフォワードするファイルリーダは、それが必要とする全てのパラメータセットを有するであろう。

[0137]サンプル記述ボックス１６８についてのこの例となる定義において、特定のトラックにおける任意の特定のサンプルに関して、別のトラックにおいて時間的に配列されたサンプルは、この特定のサンプルのもの（that）と同じ復号時間を有するもの（one）として定義される。

[0138]サンプル記述ボックス１６８についてのこの例となる定義において、所与のサンプルのＩＲＡＰピクチャ、トラックおよびレイヤに関して、ＩＲＡＰピクチャを復号するために必要とされる各パラメータセットは、以下のうちの１つにおいて含まれるものとする（shall）：
ａ．所与のトラックにおける所与のサンプルに適用するサンプルエントリー
ｂ．所与のレイヤの参照レイヤを運ぶトラックの初期サンプルのサンプルエントリー、ここで、初期サンプルは、時間的に配列されたサンプルが参照レイヤのＩＲＡＰピクチャを包含するとき、所与のサンプルの時間的に配列されたサンプルであるか、または参照レイヤのＩＲＡＰピクチャを包含する前のサンプルであるかのいずれかである。
ｃ．場合によりエクストラクタを使用して、所与のサンプルそれ自体
ｄ．存在するとき、場合によりエクストラクタを使用して、所与のレイヤの参照レイヤを運ぶトラックの任意の時間的に配列されたサンプル

[0139]サンプル記述ボックス１６８についてのこの例となる定義において、所与のサンプルの非ＩＲＡＰピクチャ、トラックおよびレイヤに関して、そのピクチャを復号するために必要とされる各パラメータセットは、以下のうちの１つにおいて含まれるものとする：
ａ．所与のトラックにおける所与のサンプルに適用するサンプルエントリー
ｂ．所与のレイヤの参照レイヤを運ぶトラックの初期サンプルのサンプルエントリー、ここで、初期サンプルは、時間的に配列されたサンプルが参照レイヤのＩＲＡＰピクチャを包含するとき、所与のサンプルの時間的に配列されたサンプルであるか、または参照レイヤのＩＲＡＰピクチャを包含する前のサンプルであるかのいずれかである。
ｃ．場合によりエクストラクタを使用して、所与のレイヤにおけるＩＲＡＰピクチャを包含する前のサンプルから、所与のサンプルそれ自体までの両端を含む、所与のトラックにおけるサンプルのうちのいずれか（any of the samples）
d．存在するとき、場合によりエクストラクタを使用して、所与のレイヤにおいてＩＲＡＰピクチャを包含する前のサンプルの時間的に配列されたサンプルから、所与のサンプルの時間的に配列されたサンプルまでの両端を含む、所与のレイヤの参照レイヤを運ぶトラックにおけるサンプルのうちのいずれか

[0140]サンプル記述ボックス１６８についてのこの例となる定義において、１つよりも多くのトラックにおいて運ばれるＨＥＶＣまたはＬ−ＨＥＶＣビットストリームに関して、ベーストラックのサンプルエントリーネームが'hvc1'または'hvc2'であるとき、他のトラックのサンプルエントリーネームは'hvc2'または'lhv1'であるものとし、ベーストラックのサンプルエントリーネームが'hev1'または'hev2'であるとき、他のトラックのサンプルエントリーネームは、'hev2'または'lhe1'であるものとする。ベーストラックは、ネイティブに存在する（natively present）ベースレイヤの最も低い時間サブレイヤ（それのＶＣＬ ＮＡＬユニットは０に等しいTemporalIdを有する）を有するトラックである。

[0141]上記の制約は、この例において、ＨＥＶＣまたはＬ−ＨＥＶＣビットストリームを運ぶ全てのトラック、あるいは、どのトラックでもなく、のいずれか、に関して、イネーブルされることになりおよび示されることになる便利なランダムアクセスを必要とする。

[0142]トラックのサンプルがＨＥＶＣ準拠のベースレイヤを包含する場合、'hvc1'、'hev1'、'hvc2'、または'hev2'サンプルエントリーは、この例において、使用されるものとする。ここで、エントリーは、初めに、ＨＥＶＣ構成ボックスを包含するものとし、場合により、以下で定義されるようにＬ−ＨＥＶＣ構成ボックスによって、後続される。ＨＥＶＣ構成ボックスは、プロファイル、層（Tier）、レベル、および、場合によりまた、HEVCDecoderConfigurationRecordによって定義されるような、ＨＥＶＣ準拠のベースレイヤのパラメータセット、を文書で記録する（documents）。Ｌ−ＨＥＶＣ構成ボックスは、場合により、Ｌ−ＨＥＶＣ構成ボックスにおいて記憶される、LHEVCDecoderConfigurationRecordによって定義されるような、Ｌ−ＨＥＶＣ準拠の拡張レイヤのパラメータセットを文書で記録する。

[0143]トラックのサンプルが、ＨＥＶＣベースレイヤを包含しない場合、サンプルエントリータイプ'lhv1'または'lhe1'は、使用されるものとし、およびサンプルエントリーは、下記に定義されるような、Ｌ−ＨＥＶＣ構成ボックスを包含するものとする。これは、例えば、ＩＳＯ／ＩＥＣ１４４９６−１５において、定義されるような、HEVCDecoderConfigurationRecordを含む。

[0144]図５は、本開示の技法に従って、メディアデータを形成しおよび送る例となる方法を例示するフローチャートである。図５の方法は、例えば、図１のコンテンツ準備デバイス２０、および／または図１のサーバデバイス６０、コンテンツ準備デバイス２０およびサーバデバイス６０にあると考えられる（attributed to）機能性を行うように構成されるデバイス、または同種のものによって行われ得る。説明の目的のために、図５の技法は、コンテンツ準備デバイス２０およびサーバデバイス６０の両方に関して議論される。

[0145]初めに、カプセル化ユニット３０は、例えば、音声エンコーダ２６および／またはビデオエンコーダ２８（２００）から符号化されたメディアデータを受信する。この例において、カプセル化ユニット３０は、様々なサンプルにおけるビデオデータをカプセル化し、それらのうちのいくつかは、ランダムアクセスサンプルを表す。ビデオデータは、ＨＥＶＣまたはＬ−ＨＥＶＣとして符号化され得る。便利なランダムアクセスをイネーブルするために、カプセル化ユニット３０は、'hev1'または'hev2'のサンプルエントリータイプ値をランダムアクセスポイントメディアデータをカプセル化するサンプルに割り当て（２０２）、およびまた、パラメータセットにサンプルエントリーまたはランダムアクセスサンプルを提供する（２０４）。ランダムアクセスポイントは、瞬間デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）フレームに対応し得、それは、イントラ予測（Ｉフレーム）を使用して符号化されたフレームに対応し得る。パラメータセットは、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、および／またはピクチャパラメータセット（ＳＰＳ）のうちのいずれかまたは全てを含み得る。一般に、カプセル化ユニット３０は、便利なランダムアクセスをイネーブルするために、全ての必要なパラメータセットがランダムアクセスサンプルと一緒に（with）、および／またはランダムアクセスサンプルに対応するサンプルエントリーと一緒に、提供されることを確かにし得る。

[0146]カプセル化ユニット３０は、次いで、例えば、ＩＳＯ／ＩＥＣ１４４９６−１５に従い、サンプルおよびパラメータセットを含む、１つまたは複数のファイルを形成し得る（２０６）。特に、カプセル化ユニット３０は、便利なランダムアクセスをイネーブルするために、パラメータセットがサンプルエントリータイプ'hev1'または'hev2'および／またはこれらのサンプルエントリータイプに対応するサンプルと共に（with）含まれるように、ファイルを形成し得る。コンテンツ準備デバイス２０は、次いで、ランダムアクセスサンプルに関するサンプルエントリータイプデータを出力し得る（２０８）。いくつかの例において、この出力は、（１つまたは複数の）ファイルの残り（the rest）と一緒に、デジタル多用途ディスク（ＤＶＤ）またはＢｌｕ−ｒａｙディスクなどの、固定媒体に向けてのものであり得る。他の例において、この出力は、サーバデバイス６０に送られ得、それは、次いで、サンプルエントリータイプデータを、図１のクライアントデバイス４０などの、クライアントデバイスに送り得る。

[0147]図５の例において、サーバデバイス６０は、クライアントデバイス４０にサンプルエントリータイプデータを送り、それは、クライアントデバイス４０に便利なランダムアクセスを行わせる。それ故、図１のサーバデバイス６０の要求処理ユニット７０は、クライアントデバイス４０から、ランダムアクセスサンプル、それに関するサンプルエントリータイプが'hev1'または'hev2'である、への要求を受信する（２１０）。それに応じて、要求処理ユニット７０は、クライアントデバイス４０に、要求されたランダムアクセスサンプルおよびパラメータセット（ＶＰＳ、ＳＰＳ、および／またはＰＰＳ）を送る（２１２）。特に、このデータは、クライアントデバイス４０がランダムアクセスサンプルより早いサンプルのパラメータセットを探索することおよびフェッチすることを必要としないように、パラメータセットがサンプルエントリーデータと一緒にまたはサンプルエントリーデータに対応するサンプルと一緒に置かれるように配列され得る。このように、図５の技法は、クライアントデバイス４０に関して便利なランダムアクセスをイネーブルし得、それにより、サーバデバイス６０およびクライアントデバイス４０に関する処理必須要件（processing requirements）を減らし、便利なランダムアクセスがイネーブルされていない場合と比べてこのデータ交換に関して帯域幅の消費を減らし得、およびクライアントデバイス４０がユーザからメディアデータを要求する入力を受信する時間とクライアントデバイス４０がユーザに要求されたメディアデータを提示することができる時間との間のレイテンシを改善し得る。

[0148]図６は、本開示の技法に従って、ランダムアクセスを行う例となる方法を例示するフローチャートである。例の目的のために、図６の方法は、図１のクライアントデバイス４０に関して説明される。

[0149]この例において、クライアントデバイス４０の検索ユニット５２は、初めに、ランダムアクセスポイントサンプルに関するサンプルエントリータイプデータを要求する（２２０）。例えば、検索ユニット５２は、ＤＡＳＨに従ったサンプルエントリータイプデータに関して、ＨＴＴＰ要求を送り得る。サンプルエントリータイプデータを受信した後に、クライアントデバイス４０のファイルフォーマット処理ユニット５０は、例えば、ＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを含む関連付けられたサンプルに関する、サンプルエントリータイプデータが'hev1'または'hev2'のサンプルエントリータイプを示すことを決定する（２２２）。したがって、クライアントデバイス４０は、サンプルが便利なランダムアクセスに関して使用されることができることを決定し得る。つまり、クライアントデバイス４０は、復号順序においてより早いサンプルのパラメータセットを探索することおよびフェッチすることなしに、サンプル、および、サンプルのメディアデータと一緒にまたはサンプルに関するサンプルエントリーと一緒に、含まれるパラメータセットを検索し得る。この例において、サンプルを含むビデオビットストリームはまた、復号順序においてそのサンプルよりも早い１つまたは複数の他のサンプルを含むことが理解されるべきである。

[0150]それに応じて、クライアントデバイス４０は、サンプルメディアデータおよび対応するパラメータセットを検索する（２２６）。クライアントデバイス４０は、より早いサンプルのパラメータセットを探索することおよびフェッチすることを必要としないが、代わりに（but instead）、検索されたパラメータセットは、便利なランダムアクセスに起因して（due to）、検索されたサンプルのメディアデータを復号するために必要とされる全てのパラメータセットデータを含む。それ故、ファイルフォーマット処理ユニット５０は、検索されたサンプルを含むファイルからビデオデータをカプセル解除し、およびビデオデコーダ４８にカプセル解除されたメディアデータを提供する。ビデオデコーダ４８は、パラメータセットを使用して、ビデオデータを復号し、復号されたビデオデータをビデオ出力４４に提供し、それは、メディアデータを提示する（２２８）。検索ユニット５２は、復号順序において後続の（subsequent）サンプルをさらに要求し得（２３０）、ビデオデコーダ４８は、次いで（then）、後続のサンプルのビデオデータを復号し得、およびビデオ出力４４は、復号されたビデオデータを提示し得る。このプロセスは、対応するメディアプレゼンテーションの終わりまで、またはメディアデータの新しいセットが、例えば、ユーザによって、要求されるまで、継続し得る。

[0151]このように、図６の方法は、ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信すること、サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序においてビデオビットストリームにおけるサンプルに先行する、と、'hev1'または'hev2'であるサンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化されたビデオデータを備えるサンプルに応答して、サンプルに先行する１つまたは複数の他のサンプルのうちのいずれのビデオデータを検索することなしに、および復号順序においてビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、サンプルを使用してランダムアクセスを行うためにサンプルを検索することと、を含む、ビデオデータを処理する方法の例を表す。

[0152]図７は、ビデオデータを含むファイルを生成する例となる技法を例示するフローチャートである。図７の方法は、図１のカプセル化ユニット３０によって行われているとして説明される。しかしながら、一般に、図７の方法は、例えば、サーバデバイス６０のコンポーネントによってなど、他のデバイスによっても同様に、行われ得ることが理解されるべきである。その上、図７の技法は、上記で議論されるような、図５のファイル生成技法と併せて、行われ得る。

[0153]初めに、カプセル化ユニット３０は、符号化されたメディアデータを受信する（２５０）。カプセル化ユニット３０は、例えば、ビデオエンコーダ２８から符号化されたメディアデータを受信し得、それは、ＨＥＶＣ、Ｌ−ＨＥＶＣ、または別のそのようなビデオコーディング規格に従って、メディアデータを符号化し得る。特に、符号化されたメディアデータは、例えば、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、ＳＨＶＣ、または（他のビデオ符号化規格へのレイヤード拡張などの）同種のものに関する、複数のレイヤを含み得る。

[0154]カプセル化ユニット３０は、一般に、複数のトラックの形態で符号化されたメディアデータを含むファイルを生成し得る。カプセル化ユニット３０は、ビデオデータを含む各トラックがマルチレイヤビデオデータの１つまたは複数のレイヤを含むように、ファイルのトラックを形成し得る（２５２）。トラック内の複数のレイヤは、例えば、様々な時間的拡張性レイヤに対応し得る。別個の（distinct）レイヤを含むトラックは、例えば、ＭＶ−ＨＥＶＣまたは３Ｄ−ＨＥＶＣに関する別個の（distinct）ビュー、またはＳＨＶＣに関する異なる拡張性レイヤ（例えば、空間解像度拡張性、ビット深度拡張性、ピーク信号対雑音比（ＰＳＮＲ）拡張性、または同種のもの）に対応し得る。

[0155]図７の例において、カプセル化ユニット３０は、次いで、便利なランダムアクセスをイネーブルするかどうかを決定する（２５４）。例えば、カプセル化ユニット３０は、管理者などの、ユーザから構成データを受信し得る。本開示において提案されている制限に従って、便利なランダムアクセスが複数のトラックの最も低いトラックに関してイネーブルされるとき、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶビデオデータのベースレイヤを含む、カプセル化ユニット３０は、ビデオデータを含む複数のトラックの互いの（each other）トラックに関して、便利なランダムアクセスをイネーブルする（２５６）。代替的に、便利なランダムアクセスが最も低いトラックに関してディセーブルされる（disabled）場合、カプセル化ユニット３０は、複数のトラックのうちのその他のトラック（the other tracks）に関して便利なランダムアクセスをディセーブルする（２５８）。他の例において、カプセル化ユニット３０は、上記で議論された代替的な制約に従って（すなわち、（ＨＥＶＣ、Ｌ−ＨＥＶＣ、またはあらゆる他のコーデックによってコード化された）シングルレイヤまたはマルチレイヤのビットストリームを運ぶ全てのトラックに関して）、便利なランダムアクセスをイネーブルまたはディセーブルし得、ベースレイヤの最も低いサブレイヤ（それのＶＣＬ ＮＡＬユニットが０に等しいTemporalIdを有する）を運ぶトラックが、便利なランダムアクセスがイネーブルされていることを示す（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う）サンプルエントリータイプを使用するとき、全ての他のトラックは、便利なランダムアクセスがイネーブルされていることを示す（ＨＥＶＣ構成および／またはＬ−ＨＥＶＣ構成の存在を伴う）サンプルエントリータイプを使用するものとする。

[0156]カプセル化ユニット３０は、次いで、便利なランダムアクセスがイネーブルされているかどうかを示すサンプルエントリータイプ値を、ビデオデータを含むトラックのサンプルに関するサンプルエントリーに割り当てる（２６０）。例えば、サンプルエントリータイプ値としての'hev1'および'hev2'は、便利なランダムアクセスがビデオデータを含むトラックに関してイネーブルされていることを示し得る。カプセル化ユニット３０はまた、上記で決定されるようなトラックおよびサンプルエントリータイプ値を含むファイルを形成する（２６２）。

[0157]このように、図７の方法は、複数のトラックのうちの最も低いトラック、最も低いトラックはビデオデータの最も低いサブレイヤを運ぶビデオデータのベースレイヤを含む、が、便利なランダムアクセスがイネーブルされていることを示すサンプルに関するサンプルエントリータイプ値を含むことになることを決定することに応答して、便利なランダムアクセスがイネーブルされることを示すために、ビデオデータを含む複数のトラックのその他のトラックの各々のサンプルに関するサンプルエントリータイプ値を設定することと、複数のトラックのトラックに関するサンプルエントリータイプ値が、便利なランダムアクセスがイネーブルされていることを示すように、複数のトラックを含むファイルを生成することと、を含むビデオデータを含むファイルを生成する方法の例を表す。

[0158]１つまたは複数の例において、説明された機能（functions）は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせにおいて、インプリメントされ得る。ソフトウェアにおいてインプリメントされる場合、これら機能は、コンピュータ可読媒体上で１つまたは複数の命令またはコードとして記憶または送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体またはデータ記憶媒体のような有体の媒体に対応する、コンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は、一般に、（１）非一時的である有形のコンピュータ可読記憶媒体、または（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法のインプリメンテーションのための命令、コード、および／またはデータ構造を検索するために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされることができるあらゆる利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。

[0159]制限ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光学ディスクストレージ、磁気ディスクストレージ、または他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態で望ましいプログラムコードを記憶するために使用されることができ、かつ、コンピュータによってアクセスされることができるあらゆる他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ可読媒体と称される。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まないが、代わりとして、非一時的な、有形の記憶媒体に向けられていることは理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスクおよびブルーレイディスクを含み、ここで、ディスク（disk）は、通常磁気的にデータを再生し、一方で、ディスク（disc）は、レーザーを用いて光学的にデータを再生する。上記の組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。

[0160]命令は、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の同等の集積回路またはディスクリート論理サーキットリーのような、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される場合、「プロセッサ」という用語は、前述の構造または本明細書で説明された技法のインプリメンテーションに適した任意の他の構造のいずれかを言及し得る。加えて、いくつかの態様では、本明細書で説明された機能性は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に提供され得るか、または組み合わせられたコーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理素子において十分にインプリメントされ得る。

[0161]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置においてインプリメントされ得る。様々な構成要素、モジュール、またはユニットは、本開示では、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するように説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上記で説明されるように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられ得るか、または適したソフトウェアおよび／またはファームウェアと併せて、上述したような１つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。

[0162]様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲の範囲内にある。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオデータを検索する方法であって、前記方法は、
ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行する、
'hev1'または'hev2'である前記サンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備える前記サンプルに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索することと
を備える、方法。
［Ｃ２］
前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信することをさらに備える、Ｃ１に記載の方法。
［Ｃ３］
前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、Ｃ１に記載の方法。
［Ｃ４］
前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、Ｃ１に記載の方法。
［Ｃ５］
前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、Ｃ４に記載の方法。
［Ｃ６］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記方法は、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定することをさらに備える、Ｃ１に記載の方法。
［Ｃ７］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記方法は、便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定することをさらに備える、Ｃ１に記載の方法。
［Ｃ８］
ビデオデータを検索するためのデバイスであって、前記デバイスは、
ビデオデータを記憶するように構成されたメモリと、
サーキットリーにおいてインプリメントされ、および、
ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行する、
'hev1'または'hev2'である前記サンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備える前記サンプルに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索することと、
前記メモリに前記検索されたサンプルを記憶することと
を行うように構成された１つまたは複数のプロセッサと
を備える、デバイス。
［Ｃ９］
前記プロセッサは、前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信するようにさらに構成される、Ｃ８に記載のデバイス。
［Ｃ１０］
前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、Ｃ８に記載のデバイス。
［Ｃ１１］
前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、Ｃ８に記載のデバイス。
［Ｃ１２］
前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、Ｃ１１に記載のデバイス。
［Ｃ１３］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記プロセッサは、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定するようにさらに構成される、Ｃ８に記載のデバイス。
［Ｃ１４］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記プロセッサは、便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定するように構成される、Ｃ８に記載のデバイス。
［Ｃ１５］
ビデオデータを検索するためのデバイスであって、前記デバイスは、
ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信するための手段と、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行する、
'hev1'または'hev2'である前記サンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備える前記サンプルに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索するための手段と
を備える、デバイス。
［Ｃ１６］
前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信するための手段をさらに備える、Ｃ１５に記載のデバイス。
［Ｃ１７］
前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、Ｃ１５に記載のデバイス。
［Ｃ１８］
前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、Ｃ１５に記載のデバイス。
［Ｃ１９］
前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、Ｃ１８に記載のデバイス。
［Ｃ２０］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定するための手段をさらに備える、Ｃ１５に記載のデバイス。
［Ｃ２１］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定するための手段をさらに備える、Ｃ１５に記載のデバイス。
［Ｃ２２］
命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行する、
'hev1'または'hev2'である前記サンプルエントリータイプおよびＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備える前記サンプルに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索することと
を行わせる、コンピュータ可読記憶媒体。
［Ｃ２３］
前記プロセッサに、前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信させるための命令をさらに備える、Ｃ２２に記載のコンピュータ可読記憶媒体。
［Ｃ２４］
前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、Ｃ２２に記載のコンピュータ可読記憶媒体。
［Ｃ２５］
前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、Ｃ２２に記載のコンピュータ可読記憶媒体。
［Ｃ２６］
前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、Ｃ２５に記載のコンピュータ可読記憶媒体。
［Ｃ２７］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記プロセッサに、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定させるための命令をさらに備える、Ｃ２２に記載のコンピュータ可読記憶媒体。
［Ｃ２８］
前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記プロセッサに、便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定することを行わせる命令をさらに備える、Ｃ２２に記載のコンピュータ可読記憶媒体。

Claims (15)

1. ビデオデータを検索する方法であって、前記方法は、
   ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信することと、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行し、前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含む、
   便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定することと、
   前記サンプルエントリータイプが'hev1'または'hev2'であり、前記サンプルがＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備えることに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索することと
   を備える、方法。
2. 前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信することをさらに備える、請求項１に記載の方法。
3. 前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、請求項１に記載の方法。
4. 前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、請求項１に記載の方法。
5. 前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、請求項４に記載の方法。
6. 前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記方法は、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定することをさらに備える、請求項１に記載の方法。
7. ビデオデータを検索するためのデバイスであって、前記デバイスは、
   ビデオビットストリームのサンプルに関するサンプルエントリータイプを記述するデータを受信するための手段と、前記サンプルエントリータイプは、'hev1'または'hev2'のうちの１つであり、ここにおいて、前記サンプルは、Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）またはレイヤードＨＥＶＣ（Ｌ−ＨＥＶＣ）のうちの１つに従って符号化されたビデオデータを備え、ビデオデータを含む１つまたは複数の他のサンプルは、復号順序において前記ビデオビットストリームにおける前記サンプルに先行し、前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含む、
   便利なランダムアクセスが、最も低い時間サブレイヤを有する前記複数のトラックの前記サブセットのうちの１つに関してイネーブルされていることを決定することに応答して、便利なランダムアクセスが、前記複数のトラックの各々に関してイネーブルされていることを決定するための手段と、
   前記サンプルエントリータイプが'hev1'または'hev2'であり、前記サンプルがＨＥＶＣまたはＬ−ＨＥＶＣのうちの１つに従って符号化された前記ビデオデータを備えることに応答して、前記サンプルに先行する前記１つまたは複数の他のサンプルのうちのいずれの前記ビデオデータを検索することなしに、および復号順序において前記ビデオビットストリームのいずれの前のサンプルのパラメータセットを検索することなしに、前記サンプルを使用してランダムアクセスを行うために前記サンプルを検索するための手段と
   を備える、デバイス。
8. 前記サンプルに対応するサンプルエントリーにおいて、または前記サンプルにおいて、のうちの少なくとも１つにおいて、前記サンプルを記述するパラメータセットを受信するための手段をさらに備える、請求項７に記載のデバイス。
9. 前記サンプルは、ＨＥＶＣに従って、前記ビデオデータを備え、前記サンプルエントリータイプは、'hev2'である、請求項７に記載のデバイス。
10. 前記サンプルの前記ビデオデータは、ファイルのトラックにおいて含まれる、請求項７に記載のデバイス。
11. 前記ファイルは、複数のトラックを含み、前記トラックの各々は、Ｌ−ＨＥＶＣのレイヤに対応する、請求項１０に記載のデバイス。
12. 前記サンプルの前記ビデオデータは、ファイルの複数のトラックのうちの１つのトラックに含まれ、前記複数のトラックは、シングルレイヤまたはマルチレイヤのビデオデータを含む前記複数のトラックのサブセットを含み、前記複数のトラックの前記サブセットのうちの各々が、便利なランダムアクセスがイネーブルされていることを示すサンプルエントリータイプを有するサンプルを含むことを決定するための手段をさらに備える、請求項７に記載のデバイス。
13. 前記デバイスは、ワイヤレス通信デバイスであり、前記ファイルを受信するように構成された受信機をさらに備える、請求項７に記載のデバイス。
14. 前記ワイヤレス通信デバイスは、セルラ電話であり、前記ファイルは、前記受信機によって受信され、およびセルラ通信規格に従って変調される、請求項１３に記載のデバイス。
15. 実行されると、プロセッサに、請求項１乃至６のいずれか１項に従う方法を実行させる命令を有する、コンピュータ可読記憶媒体。

Images