(57)【要約】  メディアデータを検索するための例示的なデバイスは、回路に実装され、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送ることと、を行うように構成された１つまたは複数のプロセッサを含む。
2019523600.tif 000002
【特許請求の範囲】
【請求項１】
メディアデータを検索する方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を備える、方法。
【請求項２】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、請求項１に記載の方法。
【請求項３】
前記チャンクのうちの前記１つのための前記識別子を決定することは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを備える、請求項１に記載の方法。
【請求項４】
前記チャンクのうちの前記１つのための前記識別子を決定することは、階層型アドレッシング方式に従って前記識別子を決定することを備える、請求項１に記載の方法。
【請求項５】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項４に記載の方法。
【請求項６】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５に記載の方法。
【請求項７】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項５に記載の方法。
【請求項８】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項７に記載の方法。
【請求項９】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５に記載の方法。
【請求項１０】
前記要求を送ることは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを備える、請求項１に記載の方法。
【請求項１１】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記方法は、ＵＲＬテンプレートに従って前記ＵＲＬを決定することをさらに備える、請求項１に記載の方法。
【請求項１２】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項１に記載の方法。
【請求項１３】
前記識別子を決定することは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを備える、請求項１に記載の方法。
【請求項１４】
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することをさらに備える、請求項１に記載の方法。
【請求項１５】
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
をさらに備える、請求項１に記載の方法。
【請求項１６】
メディアデータを検索するためのデバイスであって、前記デバイスは、回路に実装され、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行うように構成された１つまたは複数のプロセッサを備える、デバイス。
【請求項１７】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、請求項１６に記載のデバイス。
【請求項１８】
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することのように構成される、請求項１６に記載のデバイス。
【請求項１９】
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記識別子を決定するように構成される、請求項１６に記載のデバイス。
【請求項２０】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項１９に記載のデバイス。
【請求項２１】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項２０に記載のデバイス。
【請求項２２】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項２０に記載のデバイス。
【請求項２３】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項２２に記載のデバイス。
【請求項２４】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項２０に記載のデバイス。
【請求項２５】
前記要求を送るために、前記１つまたは複数のプロセッサは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送るように構成される、請求項１６に記載のデバイス。
【請求項２６】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記１つまたは複数のプロセッサは、ＵＲＬテンプレートに従って前記ＵＲＬを決定するようにさらに構成される、請求項１６に記載のデバイス。
【請求項２７】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項１６に記載のデバイス。
【請求項２８】
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定するように構成される、請求項１６に記載のデバイス。
【請求項２９】
前記１つまたは複数のプロセッサは、前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定するようにさらに構成される、請求項１６に記載のデバイス。
【請求項３０】
前記１つまたは複数のプロセッサは、
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を行うようにさらに構成される、請求項１６に記載のデバイス。
【請求項３１】
メディアデータを検索するためのデバイスであって、前記デバイスは、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定するための手段と、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送るための手段と
を備える、デバイス。
【請求項３２】
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行わせる、コンピュータ可読記憶媒体。
【請求項３３】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３４】
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３５】
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、階層型アドレッシング方式に従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３６】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項３５に記載のコンピュータ可読記憶媒体。
【請求項３７】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３８】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３９】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項３８に記載のコンピュータ可読記憶媒体。
【請求項４０】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項４１】
前記要求を送ることを前記プロセッサに行わせる前記命令は、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４２】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、ＵＲＬテンプレートに従って前記ＵＲＬを決定することを前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４３】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４４】
前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４５】
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することを前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４６】
前記マニフェストファイルからの前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４７】
メディアデータを送る方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を備える、方法。
【請求項４８】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、請求項４７に記載の方法。
【請求項４９】
前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための$Number$テンプレートを定義するデータを送ることをさらに備える、請求項４７に記載の方法。
【請求項５０】
階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、階層型アドレッシング方式を定義するデータを送ることをさらに備える、請求項４７に記載の方法。
【請求項５１】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項５０に記載の方法。
【請求項５２】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５１に記載の方法。
【請求項５３】
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項５１に記載の方法。
【請求項５４】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５１に記載の方法。
【請求項５５】
メディアデータを送るためのサーバデバイスであって、前記サーバデバイスは、
マニフェストファイルと前記メディアデータとを記憶するように構成されたメモリと、
回路に実装され、
前記メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むように前記マニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を行うように構成された１つまたは複数のプロセッサと
を備える、サーバデバイス。
【請求項５６】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、請求項５５に記載のデバイス。
【請求項５７】
前記１つまたは複数のプロセッサは、前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送るように構成される、請求項５５に記載のデバイス。
【請求項５８】
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送るように構成される、請求項５５に記載のデバイス。
【請求項５９】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項５８に記載のデバイス。
【請求項６０】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５９に記載のデバイス。
【請求項６１】
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項５９に記載のデバイス。
【請求項６２】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５９に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]  本願は、その内容全体が参照により本明細書に組み込まれた、２０１６年７月２８日付で出願された米国仮特許出願第６２／３６８，０９９号の利益を主張する。
【０００２】
[0002]  本開示は、符号化されたメディアデータの搬送に関する。
【背景技術】
【０００３】
[0003]  デジタルビデオ性能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲーム機、セルラまたは衛星無線電話、ビデオ電話会議デバイスなどを含む、幅広いデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ）、ＩＴＵ−Ｔ Ｈ．２６５（高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれる）、およびこのような規格の拡張によって定義される規格において説明されるもののようなビデオ圧縮技法を実装する。
【０００４】
[0004]  ビデオデータが符号化された後に、そのビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、ＡＶＣなどの国際標準化機構（ＩＳＯ：International Organization for Standardization）ベースメディアファイルフォーマットおよびその拡張のような、様々な規格のうちのいずれかに準拠するビデオファイルにアセンブルされ得る。
【発明の概要】
【０００５】
[0005]  概して、本開示は、セグメントチャンク（segment chunks）を使用するための技法を説明する。本開示の技法は、例えば、１つのフルセグメント（a full segment）に利用可能なチャンクの数（a number of）をシグナリングすることを含む。本開示の技法はまた、例えば、検索（retrieval）のためにチャンクを要求するための、チャンクをアドレスするアドレッシング方式（addressing scheme）（例えば、ネーミング方式（naming schemes））を含む。
【０００６】
[0006]  一例では、メディアデータを検索する方法は、メディアデータの表現（representation）のセグメントに利用可能なセグメントチャンクの数（a number of segment chunks available for a segment）を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して（independently）検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する（specifying）要求を送ることと、を含む。
【０００７】
[0007]  別の例では、メディアデータを検索するためのデバイスは、回路に実装され、かつ、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送ることと、を行うように構成された１つまたは複数のプロセッサを含む。
【０００８】
[0008]  別の例では、メディアデータを検索するためのデバイスは、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定するための手段と、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送るための手段と、を含む。
【０００９】
[0009]  別の例では、コンピュータ可読記憶媒体は、実行されたとき、プロセッサに、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送ることと、を行わせる命令を記憶する。
【００１０】
[0010]  １つまたは複数の例の詳細が、添付の図面および以下の記述に記載されている。他の特徴、目的、および利点は、その記述および図面から、並びに、特許請求の範囲から明らかになるだろう。
【図面の簡単な説明】
【００１１】
【図１】[0011]  図１は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを図示するブロック図である。
【図２】[0012]  図２は、図１の検索ユニットのコンポーネントの例示的なセットをより詳細に図示するブロック図である。
【図３】[0013]  図３は、例示的なマルチメディアコンテンツの要素を図示する概念図である。
【図４】[0014]  図４は、例示的なビデオファイルの要素を図示するブロック図であり、それは、表現のセグメント（segment of a representation）に対応し得る。
【図５】[0015]  図５は、通常のセグメント提供（regular segment offerings）と、より短い複数のセグメントを用いた提供（offerings with shorter segments）との例を図示する概念図である。
【図６】[0016]  図６は、通常のセグメント提供と、より短い複数のセグメントを用いた提供とを介して利用可能なセグメントのためのユニフォームリソースロケータ（ＵＲＬ）を図示する概念図である。
【図７】[0017]  図７は、本開示の技法によってシグナリングされ得るデータの例示的なセットを図示する概念図である。
【図８】[0018]  図８は、本開示の技法に従った、セグメントのための階層型ナンバリング（hierarchical numbering）を使用するための技法の例を図示する。
【図９】[0019]  図９は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の別の例を図示する。
【図１０】[0020]  図１０は、本開示の技法によるメディアデータを搬送（送信および受信）する（transporting）例示的な方法を図示するフローチャートである。
【発明の詳細な説明】
【００１２】
[0021]  概して、本開示は、セグメントのシーケンス、例えば、従来のセグメントと比較すると比較的短い再生持続時間のデータを含むセグメントを使用するための技法を説明する。すなわち、１つまたは複数のセグメントは、ランダムアクセスポイント（ＲＡＰ：random access point）を欠いている可能性がある（may）。よって、Ｎ秒（または、マイクロ秒、ミリ秒などのような他の時間単位）の再生持続時間のデータを有している単一のセグメント、ＲＡＰを有しかつセグメント利用可能開始時間（ＳＡＳＴ：segment availability start time）に関連付けられている単一の（single）セグメントではなく、Ｎ秒の再生持続時間のデータと、ＲＡＰを含む複数のセグメントのうちの１つのみと、それぞれのＳＡＳＴに関連付けられている複数のセグメントの各々と、を有する複数のセグメントが提供され得る。このようなより短いセグメントを使用することによって、従来の長いセグメントを使用するよりも早く再生を始めることができる。
【００１３】
[0022]  より短いセグメントを使用した解決法（solution）を提供するために、単独で、または組み合わせで、様々なオプションが使用され得る。例えば、セグメントチャンクについてのセグメントタイムラインの間の明確な（accurate）持続時間が通知され（advertised）得る。しかしながら、正確な持続時間を通知することは行き過ぎ（overkill）であり得、多くのマニフェストファイル（例えば、メディアプレゼンテーション記述（ＭＰＤ））更新を必要とし得る。階層型アドレッシング方式が使用され得る。しかしながら、階層型アドレッシング方式を使用するために十分な時間があるか否かは不明である。
【００１４】
[0023]  本開示の技法は、ＩＳＯベースのメディアファイルフォーマット、スケーラブルビデオコーディング（ＳＶＣ）ファイルフォーマット、アドバンストビデオコーディング（ＡＶＣ）ファイルフォーマット、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））ファイルフォーマット、および／またはマルチビュービデオコーディング（ＭＶＣ）ファイルフォーマット、または他の同様のビデオファイルフォーマットのうちの任意のものに従ってカプセル化されたメディアデータに準拠するメディアファイル（ビデオファイルなど）に適用され得る。
【００１５】
[0024]  ＨＴＴＰストリーミングでは、頻繁に使用される動作は、ＨＥＡＤ、ＧＥＴ、および部分的ＧＥＴを含む。ＨＥＡＤ動作は、所与のユニフォームリソースロケータ（ＵＲＬ）またはユニフォームリソースネーム（ＵＲＮ）に関連付けられたファイルのヘッダを、そのＵＲＬまたはＵＲＮに関連付けられたペイロードを検索することなく、検索する。ＧＥＴ動作は、所与のＵＲＬまたはＵＲＮに関連付けられたファイル全体を検索する。部分的ＧＥＴ動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続的バイト数を検索し、ここで、そのバイト数は、受信したバイト範囲に対応する。よって、部分的ＧＥＴ動作が１つまたは複数の個々の動画フラグメントを得ることができるため、動画フラグメントは、ＨＴＴＰストリーミングのために提供され得る。動画フラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在し得る。ＨＴＴＰストリーミングでは、メディアプレゼンテーションは、クライアントにとって（to）アクセス可能なデータの構造化された収集であり得る。クライアントは、ストリーミングサービスをユーザに提示（present）するために、メディアデータ情報を要求およびダウンロードし得る。
【００１６】
[0025]  ＨＴＴＰストリーミングを使用する３ＧＰＰデータのストリーミングの例では、マルチメディアコンテンツのビデオおよび／またはオーディオデータについて複数の表現が存在し得る。以下に説明されるように、異なる表現は、異なるコーディング特性（例えば、ビデオコーディング規格の異なるプロファイルまたはレベル）、異なるコーディング規格またはコーディング規格の拡張（マルチビューおよび／またはスケーラブル拡張などの）、または異なるビットレートに対応し得る。このような表現のマニフェストは、メディアプレゼンテーション記述（ＭＰＤ：Media Presentation Description）データ構造において定義され得る。メディアプレゼンテーションは、ＨＴＴＰストリーミングクライアントデバイスにとってアクセス可能なデータの構造化された収集に対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。メディアプレゼンテーションは、ＭＰＤデータ構造において記述され得、それは、ＭＰＤの更新を含み得る。
【００１７】
[0026]  メディアプレゼンテーションは、１つまたは複数の期間のシーケンス（a sequence of one or more periods）を含み得る。各期間は、次の期間の開始まで、または最後の期間の場合はメディアプレゼンテーションの終了まで、拡張し得る。各期間は、同じメディアコンテンツのための１つまたは複数の表現を含み得る。表現は、オーディオ、ビデオ、タイムドテキスト（timed text）、または他のこのようなデータの、いくつかの（a number of）代替的な符号化されたバージョンのうちの１つであり得る。表現は、符号化の（encoding）タイプによって、例えば、ビデオデータについてのビットレート、解像度、および／またはコーデック、並びに、オーディオデータについてのビットレート、言語、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応しかつ特定の方法で符号化された、符号化オーディオまたはビデオデータの１つの区分（a section）を指すために使用され得る。
【００１８】
[0027]  特定の期間の表現は、その表現が属する適合セット（adaptation set）を示すＭＰＤ中の属性によって示されるグループに割り当てられ得る。同じ適合セット中の表現は、概して、クライアントデバイスが、例えば、帯域幅適合を行うためにこれらの表現間を（between these representations）動的およびシームレスに切り替えることができるという点において、互いに対して代替であると考えられる。例えば、特定の期間のビデオデータの各表現は、対応する期間のためのマルチメディアコンテンツの、ビデオデータまたはオーディオデータなどのメディアデータを提示する復号のために、それら表現のうちのいずれかが選択され得るように、同じ適合セットに割り当てられ得る。１つの期間（one period）内のメディアコンテンツは、存在する場合、グループ０からの１つの表現か、または、いくつかの（some）例では、各非ゼログループからの多くとも１つの表現の組合せか、のいずれかで表現され得る。ある期間（a period）の各表現のためのタイミングデータが、その期間の開始時間に関して表され（be expressed）得る。
【００１９】
[0028]  表現は、１つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含み得るか、または表現の各セグメントは、自己初期化し（self-initializing）得る。存在する場合、初期化セグメントは、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソースネーム（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ）などの識別子によって一意に参照され得る。ＭＰＤは、各セグメントに識別子を提供し得る。いくつかの例では、ＭＰＤはまた、範囲属性（range attribute）の形式でバイト範囲を提供し得、それは、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能なファイル内のセグメントのためのデータに対応し得る。
【００２０】
[0029]  異なるタイプのメディアデータについて実質的に同時な検索のために、異なる表現が選択され得る。例えば、クライアントデバイスは、セグメントを検索するためのオーディオ表現、ビデオ表現、およびタイムドテキスト表現を選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適合を行うために、特定の適合セットを選択し得る。すなわち、クライアントデバイスは、ビデオ表現を含む適合セット、オーディオ表現を含む適合セット、および／またはタイムドテキストを含む適合セット、を選択し得る。代替的に、クライアントデバイスは、あるタイプのメディア（例えば、ビデオ）についての適合セットを選択し得、他のタイプのメディア（例えば、オーディオおよび／またはタイムドテキスト）のための表現を直接選択し得る。
【００２１】
[0030]図１は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム１０を図示するブロック図である。この例では、システム１０は、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０を含む。クライアントデバイス４０およびサーバデバイス６０は、ネットワーク７４によって通信可能に結合され、それはインターネットを備え得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０もまた、ネットワーク７４または別のネットワークによって結合され得るか、または直接、通信的に結合され得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０は、同じデバイスを備え得る。
【００２２】
[0031]  コンテンツ準備デバイス２０は、図１の例では、オーディオソース２２およびビデオソース２４を備える。オーディオソース２２は、例えば、オーディオエンコーダ２６によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオソース２２は、前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザなどのオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース２４は、ビデオエンコーダ２８によって符号化されるべきビデオデータを生成するビデオカメラ、前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス２０は、必ずしも全ての例においてサーバデバイス６０に通信可能に結合されるわけではなく、サーバデバイス６０によって読み出される別個の媒体にマルチメディアコンテンツを記憶し得る。
【００２３】
[0032]  ローオーディオ（Raw audio）およびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオエンコーダ２６および／またはビデオエンコーダ２８によって符号化される前に、デジタル化され得る。オーディオソース２２は、会話の参加者（speaking participant）から、その会話の参加者が話している間オーディオデータを取得し得、ビデオソース２４は、同時に会話の参加者のビデオデータを取得し得る。他の例では、オーディオソース２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、本開示で説明される技法は、ライブの、ストリーミングの、リアルタイムのオーディオおよびビデオデータに、あるいは、アーカイブされた、事前に記録されたオーディオおよびビデオデータに、適用され得る。
【００２４】
[0033]  ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれるビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時に（contemporaneously）オーディオソース２２によってキャプチャされた（または生成された）オーディオデータを含むオーディオフレームである。例えば、会話の参加者が概して話すことによってオーディオデータを生成する間、オーディオソース２２は、オーディオデータをキャプチャし、ビデオソース２４は、同時に、すなわち、オーディオソース２２がオーディオデータをキャプチャしている間に、会話の参加者のビデオデータをキャプチャする。ゆえに、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。従って、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータおよびビデオデータが同時にキャプチャされ、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを備えた状況に対応する。
【００２５】
[0034]  いくつかの例では、オーディオエンコーダ２６は、その符号化オーディオフレームに関するオーディオデータが記録された時間を表現する、各符号化オーディオフレーム中のタイムスタンプを符号化し得、同様に、ビデオエンコーダ２８は、符号化されたビデオフレームに関するビデオデータが記録された時間を表す、各符号化されたビデオフレーム中のタイムスタンプを符号化し得る。このような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ準備デバイス２０は、オーディオエンコーダ２６および／またはビデオエンコーダ２８がタイムスタンプを生成し得る、または、オーディオソース２２およびビデオソース２４がオーディオおよびビデオデータをそれぞれタイムスタンプと関連付けるために使用し得る、内部クロックを含み得る。
【００２６】
[0035]  いくつかの例では、オーディオソース２２は、オーディオエンコーダ２６に、オーディオデータが記録された時間に対応するデータを送り得、ビデオソース２４は、ビデオエンコーダ２８に、ビデオデータが記録された時間に対応するデータを送り得る。いくつかの例では、オーディオエンコーダ２６は、符号化オーディオデータ（encoded audio data）の相対時間的順序（a relative temporal ordering）を示すために、しかしオーディオデータが記録された絶対時間を必ずしも示すことなく、符号化オーディオデータ中のシーケンス識別子を符号化し、同様に、ビデオエンコーダ２８もまた、符号化ビデオデータの相対時間的順序を示すために、シーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、マッピングされ得るか、またはそうでなければ（otherwise）タイムスタンプと互いに関連付けられ（correlated with）得る。
【００２７】
[0036]  オーディオエンコーダ２６は、概して、符号化オーディオデータのストリームを生成し、一方、ビデオエンコーダ２８は、符号化ビデオデータのストリームを生じさせる（produces）。（オーディオであろうとビデオであろうと）データの各個々のストリームは、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、単一の、デジタル的にコーディングされた（場合によっては圧縮された）表現のコンポーネントである。例えば、表現のコーディングされたビデオまたはオーディオ部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内でカプセル化される前に、パケット化されたエレメンタリストリーム（ＰＥＳ：packetized elementary stream）に変換され得る。同じ表現内で、１つのエレメンタリストリームに属するＰＥＳパケットを、他と区別するために、ストリームＩＤが使用され得る。エレメンタリストリームのデータの基本ユニットは、１つのパケット化されたエレメンタリストリーム（ＰＥＳ）パケットである。よって、コーディングされたビデオデータは、概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、１つまたは複数のそれぞれのエレメンタリストリームに対応する。
【００２８】
[0037]  ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣおよび来たる高効率ビデオコーディング（ＨＥＶＣ）規格などの多くのビデオコーディング規格は、エラーのない（error-free）ビットストリームのための、復号処理、セマンティクス（semantics）、およびシンタックスを定義し、それらのうちのいずれも、ある（certain）プロファイルまたはレベルに準拠する。ビデオコーディング規格は通常、エンコーダを指定しないが、エンコーダは、生成されるビットストリームがデコーダに関する規格に準拠することを保証する役割を課せられる（is tasked with）。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、特徴、またはツールのサブセット、およびこれらに適用される制約条件に対応する。Ｈ．２６４規格によって定義されるように、例えば、「プロファイル」は、Ｈ．２６４規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、例えばデコーダメモリおよび計算などのデコーダリソース消費の制限に対応し、それらは、ピクチャの解像度、ビットレート、およびブロック処理レートに関連する。プロファイルは、profile_idc（プロファイルインジケータ）値を用いてシグナリングされ得、一方、レベルは、level_idc（レベルインジケータ）値を用いてシグナリングされ得る。
【００２９】
[0038]  例えば、所与の（given）プロファイルのシンタックスによって課せられる範囲（bounds）内で、復号されたピクチャの指定されたサイズなどのビットストリーム中のシンタックス要素によってとられる（taken）値に応じて、エンコーダおよびデコーダのパフォーマンスにおいて大きな変動を要する（require）ことが未だ（still）あり得ることを、Ｈ．２６４規格は認識している（recognizes）。多くのアプリケーションにおいて、特定のプロファイル内のシンタックスの全ての仮想的な（hypothetical）使用に対処することが可能なデコーダを実装することは実用的でも経済的でもないことを、Ｈ．２６４規格はさらに認識している。従って、Ｈ．２６４規格は、「レベル」を、ビットストリーム中のシンタックス要素の値に課せられた制約条件の指定されたセットと定義している。これらの制約条件は、値に対する単純な制限であり得る。代替的に、これらの制約条件は、（例えば、ピクチャ幅×ピクチャの高さ×１秒あたりに復号されるピクチャの数等の）値の算術的な組合せに対する（on）制約条件の形をとり得る。Ｈ．２６４規格は、個々の実装が、サポートされるプロファイルごとに異なるレベルをサポートし得るとさらに規定している（provides）。
【００３０】
[0039]  プロファイルに適合するデコーダは通常、プロファイルで定義される全ての機能をサポートする。例えば、コーディング機能として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイルではサポートされていないが、Ｈ．２６４／ＡＶＣの他のプロファイルでサポートされている。あるレベルに適合するデコーダは、そのレベルに定義された制限を超えるリソースを必要としない、いかなる（any）ビットストリームも復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈能力（interpretability）に関して役立ち得る。例えば、ビデオ送信の間に、プロファイルおよびレベルの定義のペアが、送信セッション全体について交渉され合意され得る。より具体的には、Ｈ．２６４／ＡＶＣにおいて、レベルは、処理される必要があるマクロブロック数（the number of macroblocks）、復号されたピクチャバッファ（ＤＰＢ：decoded picture buffer）サイズ、コーディングされたピクチャバッファ（ＣＰＢ：coded picture buffer）サイズ、垂直動きベクトル範囲、２つの連続するＭＢあたりの動きベクトルの最大数、およびＢブロックが８×８ピクセルに満たない（less than）サブマクロブロック区分を有することができるか否か、に対する（on）制限を定義し得る。このように、デコーダは、そのデコーダがビットストリームを適切に復号することが可能か否かを決定し得る。
【００３１】
[0040]  図１の例では、コンテンツ準備デバイス２０のカプセル化ユニット３０は、ビデオエンコーダ２８からのコーディングされたビデオデータを備えるエレメンタリストリームと、オーディオエンコーダ２６からのコーディングされたオーディオデータを備えるエレメンタリストリームと、を受信する。いくつかの例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は各々、符号化データから（from）ＰＥＳパケットを形成するためのパケタイザを含み得る。他の例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は各々、符号化データからＰＥＳパケットを形成するためのそれぞれのパケタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化オーディオおよびビデオデータからＰＥＳパケットを形成するためのパケタイザを含み得る。
【００３２】
[0041]  ビデオエンコーダ２８は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格についての様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（例えば、２次元または３次元の再生のための）１つのまたは複数のビューを有する表現、または他のこのような特性などの、様々な特性を有する、および様々なビットレートにおける、マルチメディアコンテンツの異なる表現を生成する（produce）ために、マルチメディアコンテンツのビデオデータを様々な方法で符号化し得る。本開示で使用される場合、表現は、オーディオデータ、ビデオデータ、（例えば字幕のための）テキストデータ、または他のこのようなデータのうちの１つを備え得る。表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するstream_idを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々な表現のビデオファイル（例えば、セグメント）にアセンブルする役割を担う。
【００３３】
[0042]  カプセル化ユニット３０は、オーディオエンコーダ２６およびビデオエンコーダ２８から表現のエレメンタリストリームに関するＰＥＳパケットを受信し、それらＰＥＳパケットから、対応するネットワーク抽象化レイヤ（ＮＡＬ：network abstraction layer）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Advanced Video Coding）の例では、コーディングされたビデオセグメントは、ＮＡＬユニットへと編成され、それらは、ビデオ電話、ストレージ、ブロードキャスト、またはストリーミングなどのアプリケーションをアドレスする「ネットワークフレンドリーな（network-friendly）」ビデオ表現を提供する。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ：Video Coding Layer）ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットに分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含み得、ブロック、マクロブロック、および／またはスライスレベルのデータを含み得る。他のＮＡＬユニットは、非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では通常、プライマリコーディングピクチャとして提示される１つの時間インスタンス（one time instance）においてコーディングされたピクチャは、アクセスユニットに含まれ得、それは、１つまたは複数のＮＡＬユニットを含み得る。
【００３４】
[0043]  非ＶＣＬ ＮＡＬユニットは、とりわけ（among others）、パラメータセットＮＡＬユニットおよびＳＥＩ ＮＡＬユニットを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）中に）シーケンスレベルヘッダ情報、および（ピクチャパラメータセット（ＰＰＳ）中に）頻繁には変化しない（infrequently changing）ピクチャレベルヘッダ情報を含み得る。パラメータセット（例えば、ＰＰＳおよびＳＰＳ）を用いることで、頻繁には変化しない情報は、シーケンスまたはピクチャごとに（for each）繰り返される必要がなく、よってコーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし得、エラー耐性（error resilience）のための冗長な送信の必要が無くなる（avoiding）。帯域外送信の例では、パラメータセットＮＡＬユニットは、ＳＥＩ ＮＡＬユニットなどの他のＮＡＬユニットとは異なるチャネル上で送信され得る。
【００３５】
[0044]  付加拡張情報（ＳＥＩ：Supplemental Enhancement Information）は、ＶＣＬ ＮＡＬユニットからのコーディングされたピクチャサンプルを復号するために必要ではない情報を含み得るが、復号、表示、誤り耐性、および他の目的に関連したプロセスを支援し得る。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニットに含まれ得る。ＳＥＩメッセージは、いくつかの規格仕様書（standard specifications）の規範的（normative）部分であり、従って、規格準拠のデコーダ実装のために必ずしも必須ではない。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージまたはピクチャレベルＳＥＩメッセージであり得る。何らかのシーケンスレベル情報が、ＳＶＣの例におけるスケーラビリティ情報ＳＥＩメッセージ、およびＭＶＣ中でのビュースケーラビリティ情報ＳＥＩメッセージなどのＳＥＩメッセージに含まれ得る。これらの例示的なＳＥＩメッセージは、例えば、動作点の抽出および動作点の特性に関する（on）情報を伝達し得る。加えて、カプセル化ユニット３０は、表現の特性を説明するメディアプレゼンテーション記述子（ＭＰＤ：media presentation descriptor）などのマニフェストファイルを形成し得る。カプセル化ユニット３０は、拡張可能マークアップ言語（ＸＭＬ）に従ってＭＰＤをフォーマットし得る。
【００３６】
[0045]  カプセル化ユニット３０は、出力インターフェース３２へ、マニフェストファイル（例えば、ＭＰＤ）とともに（along with）マルチメディアコンテンツの１つまたは複数の表現についての（for）データを提供し得る。出力インターフェース３２は、ユニバーサルシリアルバス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライタまたはバーナ、磁気またはフラッシュ記憶媒体へのインターフェース、あるいはメディアデータを記憶または送信するための他のインターフェースなどの、記憶媒体に書き込みするためのインターフェースまたはネットワークインターフェースを備え得る。カプセル化ユニット３０は、マルチメディアコンテンツの表現の各々のデータを、出力インターフェース３２に提供し得、それは、そのデータをネットワーク送信または記憶媒体を介してサーバデバイス６０に送り得る。図１の例では、サーバデバイス６０は、それぞれのマニフェストファイル６６および１つまたは複数の表現６８Ａ〜６８Ｎ（表現６８）を各々が含む、様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含む。いくつかの例では、出力インターフェース３２はまた、データをネットワーク７４に直接送り得る。
【００３７】
[0046]  いくつかの例では、表現６８は、適合セットに分けられ得る。すなわち、表現６８の様々なサブセットは、復号されかつ例えばスピーカによって提示されるべきオーディオデータおよび／または表現を用いて（with）表示される（to be displayed）テキストの言語または他の特性を識別し得るテキストタイプ情報、適合セット中の表現に関するシーンの現実世界のカメラの視点（real-world camera perspective）またはカメラアングルを説明し得るカメラアングル情報、特定の視聴者（audiences）に対するコンテンツの適合性を説明するレーティング情報、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントに関するファイルフォーマット、あるいは同様のもの、のような特性の各共通のセット、を含み得る。
【００３８】
[0047]  マニフェストファイル６６は、特定の適合セットのための共通の特性と同様に（as well as）、その適合セットに対応する表現６８のサブセットを示すデータを含み得る。マニフェストファイル６６はまた、適合セットの個々の表現のために、ビットレートなどの個々の特性を表すデータを含み得る。このように、適合セットは、簡略化されたネットワーク帯域幅適合を提供し得る。適合セット中の表現は、マニフェストファイル６６の適合セット要素の子要素（child elements）を使用して示され得る。
【００３９】
[0048]  サーバデバイス６０は、要求処理ユニット７０およびネットワークインターフェース７２を含む。いくつかの例では、サーバデバイス６０は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス６０の特徴のうちの任意のものまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなどのコンテンツ配信ネットワークの他のデバイスにおいて実装され得る。いくつかの例では、コンテンツ配信ネットワークの仲介デバイス（intermediate devices）は、マルチメディアコンテンツ６４のデータをキャッシュし得、サーバデバイス６０のものに実質的に準拠するコンポーネントを含み得る。概して、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送るおよび受信するように構成される。
【００４０】
[0049]  要求処理ユニット７０は、記憶媒体６２のデータのための、クライアントデバイス４０などのクライアントデバイスから（from）ネットワーク要求を受信するように構成される。例えば、要求処理ユニット７０は、１９９９年６月のFielding et alによる「Hypertext Transfer Protocol - HTTP/1. 1」ネットワークワーキンググループ、ＩＥＴＦ、ＲＦＣ ２６１６において説明されているようなハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１を実装し得る。すなわち、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を受信し、それら要求に応答して、マルチメディアコンテンツ６４のデータを提供するように構成され得る。それら要求は、例えばセグメントのＵＲＬを使用して、表現６８のうちの１つの表現のセグメントを指定し得る。いくつかの例では、それら要求はまた、セグメントの１つまたは複数のバイト範囲を指定し得、よって、部分的ＧＥＴ要求を備える。要求処理ユニット７０はさらに、表現６８のうちの１つのセグメントのヘッダデータを提供するためにＨＴＴＰ ＨＥＡＤ要求をサービスするように構成され得る。いずれの場合も、要求処理ユニット７０は、要求されたデータをクライアントデバイス４０などの要求しているデバイスに提供するために、それら要求を処理するように構成され得る。
【００４１】
[0050]  加えてまたは代替として、要求処理ユニット７０は、ｅＭＢＭＳなどのブロードキャストまたはマルチキャストプロトコルを介して、メディアデータを配信するように構成され得る。コンテンツ準備デバイス２０は、説明されたものと実質的に同じ方法でＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用してこれらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット７０は、クライアントデバイス４０から（from）マルチキャストグループ参加要求（multicast group join request）を受信するように構成され得る。すなわち、サーバデバイス６０は、（例えば、ライブイベントのブロードキャストなどの）特定のメディアコンテンツに関連付けられた、クライアントデバイス４０を含むクライアントデバイスに、マルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ：Internet protocol）アドレスを通知し（advertise）得る。クライアントデバイス４０は順に（in turn）、そのマルチキャストグループに参加するための（to）要求をサブミット（submit）し得る。この要求は、マルチキャストグループに関連付けられたＩＰアドレスを宛先とした（destined for）トラフィックを、クライアントデバイス４０などの加入しているクライアントデバイスへとルータが向け（derect）させるように、例えばネットワーク７４を構成するルータなどのネットワーク７４全体に伝播され（be propagated throughout）得る。
【００４２】
[0051]  図１の例に例示されるように、マルチメディアコンテンツ６４は、マニフェストファイル６６を含み、それは、メディアプレゼンテーション記述（ＭＰＤ）に対応し得る。マニフェストファイル６６は、異なる代替の表現６８の記述（例えば、異なる品質を有するビデオサービス）を含み得、その記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現６８の他の記述的特性を含み得る。クライアントデバイス４０は、表現６８のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを検索し得る。
【００４３】
[0052]  具体的には（In particular）、検索ユニット５２は、ビデオデコーダ４８の復号性能とビデオ出力４４のレンダリング性能とを決定するために、クライアントデバイス４０の構成データ（図示せず）を検索し得る。構成データはまた、クライアントデバイス４０のユーザによって選択された言語選好、クライアントデバイス４０のユーザによって設定された深度選好に対応する１つまたは複数のカメラパースペクティブ、および／またはクライアントデバイス４０のユーザによって選択されたレーティング選好のうちの任意のものまたは全てを含み得る。検索ユニット５２は、例えば、ＨＴＴＰ ＧＥＴおよび部分的ＧＥＴ要求をサブミットするように構成されるウェブブラウザまたはメディアクライアントを備え得る。検索ユニット５２は、クライアントデバイス４０の１つまたは複数のプロセッサまたは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例では、検索ユニット５２に関して説明される機能性の全てまたは一部は、ハードウェアにおいて、あるいは、ハードウェア、ソフトウェア、および／またはファームウェアの組合せにおいて実装され得、ここで、必須ハードウェアが、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
【００４４】
[0053]  検索ユニット５２は、クライアントデバイス４０のレンダリング性能（capabilities）および復号を、マニフェストファイル６６の情報によって示される表現６８の特性と比較し得る。検索ユニット５２は初めに、表現６８の特性を決定するためにマニフェストファイル６６の少なくとも一部分を検索し得る。例えば、検索ユニット５２は、１つまたは複数の適合セットの特性を説明するマニフェストファイル６６の一部を要求し得る。検索ユニット５２は、クライアントデバイス４０のレンダリング性能およびコーディングによって満足され得る特性を有する（例えば適合セットなどの）表現６８のサブセットを選択し得る。検索ユニット５２は次に、適合セット中の表現のためのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、および、ネットワーク帯域幅によって満足され得るビットレートを有する表現のうちの１つから（from）セグメントを検索し得る。
【００４５】
[0054]  一般に、より高いビットレートの表現は、より高い品質のビデオ再生をもたらし得、一方、より低いビットレートの表現は、利用可能なネットワーク帯域幅が減少するときに十分な品質のビデオ再生を提供し得る。従って、利用可能なネットワーク帯域幅が比較的高いとき、検索ユニット５２は、比較的高いビットレートの表現から（from）データを検索し得、それに対して（whereas）、利用可能なネットワーク帯域幅が低いとき、検索ユニット５２は、比較的低いビットレートの表現からデータを検索し得る。このように、クライアントデバイス４０は、ネットワーク７４のネットワーク帯域幅の利用可能性を変化することに適応しつつ（while）、ネットワーク７４を介してマルチメディアデータをストリーミングし得る。
【００４６】
[0055]  加えてまたは代替として、検索ユニット５２は、ｅＭＢＭＳまたはＩＰマルチキャストなどのブロードキャストまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。このような例では、検索ユニット５２は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに参加するための要求をサブミットし得る。マルチキャストグループに参加した後に、検索ユニット５２は、さらなる要求がサーバデバイス６０またはコンテンツ準備デバイス２０に出される（issued to）ことなく、マルチキャストグループのデータを受信し得る。検索ユニット５２は、例えば、再生を停止するために（to）、または異なるマルチキャストグループにチャネルを変更するために、そのマルチキャストグループのデータがもはや必要ではないとき、そのマルチキャストグループを離れるための要求（a request to leave）をサブミットし得る。
【００４７】
[0056]  ネットワークインターフェース５４は、選択された表現のセグメントのデータを受信し、それを検索ユニット５２に提供し得、それは順に、非カプセル化（decapsulation）ユニット５０にセグメントを提供し得る。非カプセル化ユニット５０は、構成要素ＰＥＳストリームへとビデオファイルの要素を非カプセル化し、符号化データを検索するためのＰＥＳストリームを非パケット化（depacketize）し、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、符号化データがオーディオストリームの一部であるか、またはビデオストリームの一部であるかに依存して、オーディオデコーダ４６またはビデオデコーダ４８のいずれかに符号化データを送り得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、その復号オーディオデータをオーディオ出力４２に送り、一方、ビデオデコーダ４８は、符号化ビデオデータを復号し、ビデオ出力４４に、ストリームの複数のビューを含み得るその復号ビデオデータを送る。
【００４８】
[0057]  ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、検索ユニット５２、および非カプセル化ユニット５０は各々、適宜（as applicable）、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、離散（discrete）論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせなどの、様々な適切な処理回路の任意のものとして実装され得る。ビデオエンコーダ２８およびビデオデコーダ４８の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのうちのいずれも（either）、組み合わされたビデオエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として一体化され得る。同様に、オーディオエンコーダ２６およびオーディオデコーダ４６の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのいずれも、組み合わせられたＣＯＤＥＣの一部として統合され得る。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、検索ユニット５２、および／または非カプセル化ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラ電話などのワイヤレス通信デバイスを備え得る。
【００４９】
[0058]  クライアントデバイス４０、サーバデバイス６０、および／またはコンテンツ準備デバイス２０は、この開示の技法に従って動作するように構成され得る。例示のために、この開示は、クライアントデバイス４０およびサーバデバイス６０に関するこれらの技法を説明している。しかしながら、サーバデバイス６０の代わりに（またはそれに加えて）、コンテンツ準備デバイス２０が、これらの技法を行うように構成され得ることが理解されるべきである。
【００５０】
[0059]  カプセル化ユニット３０は、ＮＡＬユニットが属するプログラムを識別するヘッダ、並びにペイロード、例えば、ＮＡＬユニットが対応するトランスポートまたはプログラムストリームを説明する（describes）データ、オーディオデータ、あるいは、ビデオデータ、を備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは、サイズが可変のペイロードと１バイトのヘッダを含む。そのペイロード中にビデオデータを含むＮＡＬユニットは、ビデオデータの様々な粒度レベル（granularity levels）を備え得る。例えば、ＮＡＬユニットは、ビデオデータの１つのブロック（a block of）、複数のブロック、ビデオデータの１つのスライス（a slice of）、またはビデオデータの全体のピクチャを備え得る。カプセル化ユニット３０は、エレメンタリストリームのＰＥＳパケットの形式で、ビデオエンコーダ２８から（from）符号化ビデオデータを受信し得る。カプセル化ユニット３０は、対応するプログラムと各エレメンタリストリームを関連付け得る。
【００５１】
[0060]  カプセル化ユニット３０はまた、複数のＮＡＬユニットから（from）アクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレーム、並びに、このようなオーディオデータが利用可能なときにはそのフレームに対応するオーディオデータ、を表現するための１つまたは複数のＮＡＬユニットを備え得る。あるアクセスユニットは、概して、１つの出力時間インスタンスに関する（for）全てのＮＡＬユニット、例えば、１つの時間インスタンスに関する全てのオーディオおよびビデオデータを含む。例えば、各ビューが１秒あたり２０フレームのフレームレート（ｆｐｓ：frames per second）を有する場合、各時間インスタンスは、０．０５秒の時間間隔に対応し得る。この時間間隔の間に、同じアクセスユニット（同じ時間インスタンス）の全てのビューのための特定のフレームが同時にレンダリングされ得る。一例では、あるアクセスユニットは、１つの時間インスタンスにおけるあるコーディングされたピクチャ（a coded picture）を備え得、それは、プライマリコーディングピクチャとして提示され得る。
【００５２】
[0061]  従って、アクセスユニット（an access unit）は、共通の時間的インスタンスの全てのオーディオおよびビデオフレーム、例えば時間Ｘに対応する全てのビューを備え得る。本開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに関する符号化されたピクチャ（またはフレーム）を備え得る。従って、アクセスユニットは、共通の時間的インスタンスの全てのビューコンポーネントを備えるものとして定義され得る。アクセスユニットの復号順序は、出力または表示順序と必ずしも同じである必要はない。
【００５３】
[0062]  メディアプレゼンテーションは、メディアプレゼンテーション記述（ＭＰＤ）を含み得、それは、異なる代替の表現（例えば、異なる品質を有するビデオサービス）の説明を包含し、記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。ＭＰＤは、マニフェストファイル６６などのマニフェストファイルの一例である。クライアントデバイス４０は、様々なプレゼンテーションの動画フラグメント（movie fragments）にどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを検索し得る。動画フラグメントは、ビデオファイルの動画フラグメントボックス（moof box）に位置し得る。
【００５４】
[0063]  （例えば、ＭＰＤを備え得る）マニフェストファイル６６は、表現６８のセグメントの利用可能性を通知し得る。すなわち、ＭＰＤは、表現６８のうちの１つの第１のセグメントが利用可能になるウォールクロック時間（the wall-clock time）を示す情報、並びに、表現６８内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス４０の検索ユニット５２は、特定のセグメントに先行するセグメントの開始時間並びに持続時間に基づいて、各セグメントがいつ利用可能になるかを決定し得る。
【００５５】
[0064]  カプセル化ユニット３０が受信されたデータに基づいてＮＡＬユニットおよび／またはアクセスユニットをビデオファイルへとアセンブルした後に、カプセル化ユニット３０は、出力のために出力インターフェース３２にビデオファイルを渡す。いくつかの例では、カプセル化ユニット３０は、直接クライアントデバイス４０にビデオファイルを送るのではなく、ビデオファイルをローカルに記憶し得るか、または出力インターフェース３２を介してリモートサーバにビデオファイルを送り得る。出力インターフェース３２は、例えば、送信機、トランシーバ、コンピュータ可読媒体にデータを書き込みするためのデバイス、例えば、光学式ドライブ、磁気媒体ドライブ（例えば、フロッピー（登録商標）ドライブ）、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースなどを備え得る。出力インターフェース３２は、ビデオファイルを、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体などのコンピュータ可読媒体に出力する。
【００５６】
[0065]  ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し、検索ユニット５２を介して非カプセル化ユニット５０にＮＡＬユニットまたはアクセスユニットを提供し得る。非カプセル化ユニット５０は、構成要素ＰＥＳストリームへとビデオファイルの要素を非カプセル化し、符号化データを検索するために（to）ＰＥＳストリームを非パケット化し、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、符号化データがオーディオストリームの一部であるか、またはビデオストリームの一部であるか否かに依存して、オーディオデコーダ４６またはビデオデコーダ４８のいずれかに符号化データを送り得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、その復号オーディオデータをオーディオ出力４２に送り、一方、ビデオデコーダ４８は、符号化ビデオデータを復号し、ビデオ出力４４に、ストリームの複数のビューを含み得るその復号ビデオデータを送る。
【００５７】
[0066]  本開示の技法に従って、マニフェストファイル６６は、任意のまたは全ての表現６８のセグメントが利用可能である「チャンク」の数をシグナリングする属性を含むように修正され（be modified）得る。例えば、マニフェストファイル６６は、下記でより詳細に論じられるように、「＠ｋ」属性を含むＭＰＤを表現し得る。さらに、検索ユニット５２および／または要求処理ユニット７０は、セグメントチャンクをアドレスするために、本開示の技法に従って構成され得る。具体的には、アドレッシング方式は、例えばセグメントのチャンクのための単純なナンバリングテンプレート（「$Number$」）、または少なくとも２つの部分を含む階層型アドレッシング方式の使用を含み得る。第１の部分は、対応するセグメントについてのフルセグメント番号、または対応するセグメントのタイミング情報に対応し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第２の部分は、チャンクの通常の識別番号（ordinal numeric identifier）に対応し得る。例えば、階層型アドレッシング方式は、「$Number$. $ChunkNumber$」フォーマットまたは「$Time$. $ChunkNumber$」フォーマットを使用し得る。
【００５８】
[0067]  このように、クライアントデバイス４０は、回路に実装され、かつ、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備え、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送ることと、を行うように構成された１つまたは複数のプロセッサを含む、メディアデータを検索するためのデバイスの例を表現する。
【００５９】
[0068]  図２は、図１の検索ユニット５２のコンポーネントの例示的なセットをより詳細に図示するブロック図である。この例では、検索ユニット５２は、ｅＭＢＭＳミドルウェアユニット１００、ＤＡＳＨクライアント１１０、およびメディアアプリケーション１１２を含む。
【００６０】
[0069]  この例では、ｅＭＢＭＳミドルウェアユニット１００はさらに、ｅＭＢＭＳ受信ユニット１０６、キャッシュ１０４、およびサーバユニット１０２を含む。この例では、ｅＭＢＭＳ受信ユニット１０６は、例えば、http://tools. ietf. org/html/rfc6726で利用可能な、２０１２年１１月のPaila et al.による「FLUTE-File Delivery over Unidirectional Transport」、ネットワークワーキンググループ、ＲＦＣ ６７２６において説明されているような、単一方向の搬送を介するファイル配信（ＦＬＵＴＥ：File Delivery over Unidirectional Transport）に従って、ｅＭＢＭＳを介してデータを受信するように構成される。すなわち、ｅＭＢＭＳ受信ユニット１０６は、ＢＭ−ＳＣとして機能し得るサーバデバイス６０などから、ブロードキャストを介してファイルを受信し得る。
【００６１】
[0070]  ｅＭＢＭＳミドルウェアユニット１００がファイルに関するデータを受信するとき（As）、ｅＭＢＭＳミドルウェアユニットは、その受信したデータをキャッシュ１０４に記憶し得る。キャッシュ１０４は、フラッシュメモリ、ハードディスク、ＲＡＭ、または任意の他の適切な記憶媒体などのコンピュータ可読記憶媒体を備え得る。
【００６２】
[0071]  ローカルサーバユニット１０２は、ＤＡＳＨクライアント１１０のためのサーバとして機能し得る。例えば、ローカルサーバユニット１０２は、ＤＡＳＨクライアント１１０に、ＭＰＤファイルまたは他のマニフェストファイルを提供し得る。ローカルサーバユニット１０２は、ＭＰＤファイル中のセグメントのための利用可能時間、並びに、セグメントが検索されることができるハイパーリンクを通知し得る。これらのハイパーリンクは、（例えば、ＩＰｖ４に関する１２７．０．０．１などの）クライアントデバイス４０に対応するローカルホストアドレスプレフィックス（localhost address prefix）を含み得る。このように、ＤＡＳＨクライアント１１０は、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を使用して、ローカルサーバユニット１０２からセグメントを要求し得る。例えば、リンクhttp://127. 0. 0. 1/rep1/seg3からの利用可能なセグメントについて、ＤＡＳＨクライアント１１０は、http://127. 0. 0. 1/rep1/seg3を求める要求を含むＨＴＴＰ ＧＥＴ要求を構築し得、その要求をローカルサーバユニット１０２にサブミットし得る。ローカルサーバユニット１０２は、このような要求に応答して、要求されたデータをキャッシュ１０４から検索し（retrieve requested data from cache 104）得、そのデータをＤＡＳＨクライアント１１０に提供し得る。
【００６３】
[0072]  ＤＡＳＨクライアント１１０は、本開示のネーミング規定（naming conventions）を使用して、プロキシサーバ１０２から（from）セグメントを要求するために、本開示の技法に従って構成され得る。同じように、ＤＡＳＨクライアント１１０は、プロキシサーバ１０２から受信したマニフェストファイルを使用してセグメントの名前を決定するように構成され得、ここで、マニフェストファイルは、下記でより詳細に説明されるように、例えば「＠ｋ」属性の形式で、フルセグメントごとに利用可能な「チャンク」の数をシグナリングし得る。同様に、プロキシサーバ１０２はまた、本開示の技法に従って構成され得る。
【００６４】
[0073]  例えば、ＤＡＳＨクライアント１１０とプロキシサーバ１０２とは、単純な（simple）$Number$テンプレートを使用してセグメントチャンクに名前を付ける（name）ように構成され得る。代替的に、ＤＡＳＨクライアント１１０とプロキシサーバ１０２とは、２つの部分を含み得る階層型ネーミング（またはアドレッシング）方式に従って、セグメントチャンクに名前を付けるように構成され得る。第１の部分は、対応するセグメントについての（for）フルセグメント番号、または対応するセグメントのタイミング情報に対応し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第２の部分は、特定のフルセグメントのチャンクのための通常の識別子に対応し得る。
【００６５】
[0074]  図３は、例示的なマルチメディアコンテンツの要素を図示する概念図である。マルチメディアコンテンツ１２０は、マルチメディアコンテンツ６４（図１）、または記憶媒体６２中に記憶された別のマルチメディアコンテンツに対応し得る。図３の例では、マルチメディアコンテンツ１２０は、メディアプレゼンテーション記述（ＭＰＤ）１２２と複数の表現１２４Ａ〜１２４Ｎ（表現１２４）とを含む。表現１２４Ａは、オプションのヘッダデータ１２６およびセグメント１２８Ａ〜１２８Ｎ（セグメント１２８）を含み、一方、表現１２４Ｎは、オプションのヘッダデータ１３０およびセグメント１３２Ａ〜１３２Ｎ（セグメント１３２）を含む。文字Ｎは、便宜上、表現１２４の各々における最後の動画フラグメントを指定するために使用される。いくつかの例では、表現１２４間で異なる数の動画フラグメントが存在し得る。
【００６６】
[0075]  ＭＰＤ１２２は、表現１２４とは別個の（separate）データ構造を備え得る。ＭＰＤ１２２は、図１のマニフェストファイル６６に対応し得る。同様に、表現１２４は、図２の表現６８に対応し得る。一般に、ＭＰＤ１２２は、コーディングおよびレンダリング特性、適合セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（例えば、時間的サブシーケンス（temporal sub-sequences）を含む表現を示す情報）および／または（例えば、再生中のメディアコンテンツへの、目標とされる（targeted）通知の挿入のための）遠隔の期間（remote periods）を検索するための情報などの、表現１２４の特性を概して記述するデータを含み得る。
【００６７】
[0076]  ヘッダデータ１２６は、存在するとき、セグメント１２８の特性、例えば、ランダムアクセスポイント（ＲＡＰ、ストリームアクセスポイント（ＳＡＰ）とも呼ばれる）の時間的ロケーション、セグメント１２８のうちのどれがランダムアクセスポイントを含むか、セグメント１２８内の（within）ランダムアクセスポイントに対する（to）バイトオフセット、セグメント１２８のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１２８の他の態様を記述し得る。ヘッダデータ１３０は、存在するとき、セグメント１３２のための同様の特性を記述し得る。加えてまたは代替として、このような特性は、ＭＰＤ１２２内に完全に含まれ得る。
【００６８】
[0077]  セグメント１２８、１３２は、１つまたは複数のコーディングビデオサンプル（coded video samples）を含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント１２８のコーディングビデオサンプルの各々は、同様の特性、例えば、高さ、幅、および帯域幅要件を有し得る。このような特性は、ＭＰＤ１２２のデータによって記述され得るが（though）、このようなデータは図３の例には例示されていない。ＭＰＤ１２２は、本開示に説明される、シグナリングされる情報のうちの任意のものまたは全てを追加して、３ＧＰＰ仕様書によって記述されるような特性を含み得る。
【００６９】
[0078]  セグメント１２８、１３２の各々は、ユニークユニフォームリソースロケータ（ＵＲＬ）に関連付けられ得る。よって、セグメント１２８、１３２の各々は、ＤＡＳＨなどのストリーミングネットワークプロトコルを使用して、独立して検索可能であり得る。このように、クライアントデバイス４０などの宛先デバイスは、セグメント１２８または１３２を検索するために、ＨＴＴＰ ＧＥＴ要求を使用し得る。いくつかの例では、クライアントデバイス４０は、セグメント１２８または１３２の特定のバイト範囲を検索するために、ＨＴＴＰ部分的ＧＥＴ要求を使用し得る。
【００７０】
[0079]  本開示の技法に従って、ＭＰＤ１２２は、特定のセグメントに利用可能なセグメントチャンクの数をシグナリングする属性を含み得る。例えば、下記でより詳細に論じられるように、ＭＰＤ１２２は、「＠ｋ」要素を含み得る。ＭＰＤ１２２は、セグメントチャンクをアドレスする（address）ために使用されるべきネーミング方式（またはアドレッシング方式）をさらにシグナリングし得る。このようなネーミング／アドレッシング方式は、下記でより詳細に論じられるように、通常の情報および／またはタイミング情報に基づき得る。
【００７１】
[0080]  図４は、例示的なビデオファイル１５０の要素を図示するブロック図であり、それは、図３のセグメント１１４、１２４のうちの１つなどの表現のセグメントに対応し得る。セグメント１２８、１３２の各々は、図４の例で図示されているデータの配列に実質的に一致するデータを含み得る。ビデオファイル１５０は、セグメントをカプセル化すると言うことができる（may be said to）。上述したように、ＩＳＯベースのメディアファイルフォーマットおよびその拡張に従ったビデオファイルは、「ボックス（boxes）」と呼ばれる一連のオブジェクトにデータを記憶する。図４の例では、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２、動画（ＭＯＯＶ）ボックス１５４、セグメントインデックス（ｓｉｄｘ）ボックス１６２、動画フラグメント（ＭＯＯＦ）ボックス１６４、および動画フラグメントランダムアクセス（ＭＦＲＡ）ボックス１６６を含む。図４は、ビデオファイルの例を表すが、他のメディアファイルは、ＩＳＯベースのメディアファイルフォーマットおよびその拡張に従った、ビデオファイル１５０のデータと同様に構造化された他のタイプのメディアデータ（例えば、オーディオデータ、タイムドテキストデータ、または同様のもの）を含み得ることが、理解されるべきである。
【００７２】
[0081]  ファイルタイプ（ＦＴＹＰ）ボックス１５２は、概して、ビデオファイル１５０のためのファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０のための最善の使用を記述する規格書（specification）を識別するデータを含み得る。ファイルタイプボックス１５２は、代替的に、ＭＯＯＶボックス１５４、動画フラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に配置され得る。
【００７３】
[0082]  いくつかの例では、ビデオファイル１５０などのセグメントは、ＦＴＹＰボックス１５２の前にＭＰＤ更新ボックス（図示せず）を含み得る。ＭＰＤ更新ボックスは、ビデオファイル１５０を含む表現に対応するＭＰＤが更新されるべきであることを示す情報を、ＭＰＤを更新するための情報とともに含み得る。例えば、ＭＰＤ更新ボックスは、ＭＰＤを更新するために使用されることになるリソースのためのＵＲＩまたはＵＲＬを提供し得る。別の例として、ＭＰＤ更新ボックスは、ＭＰＤを更新するためのデータを含み得る。いくつかの例では、ＭＰＤ更新ボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示されない）の直後に続き（immediately follow）得、ここで、ＳＴＹＰボックスは、ビデオファイル１５０のためのセグメントタイプを定義し得る。図７は、下記でより詳細に説明されるように、ＭＰＤ更新ボックスに関する追加の情報を提供する。
【００７４】
[0083]  ＭＯＯＶボックス１５４は、図４の例では、動画ヘッダ（ＭＶＨＤ）ボックス１５６、トラック（ＴＲＡＫ）ボックス１５８、および１つまたは複数の動画拡張（ＭＶＥＸ）ボックス１６０を含む。概して、ＭＶＨＤボックス１５６は、ビデオファイル１５０の一般的な特性を記述し得る。例えば、ＭＶＨＤボックス１５６は、ビデオファイル１５０が最初に（originally）生成されたのはいつか、ビデオファイル１５０が最後に修正されたのはいつか、ビデオファイル１５０のための時間スケール、ビデオファイル１５０のための再生の持続時間、またはビデオファイル１５０を一般的に記述する他のデータ、を記述するデータを含み得る。
【００７５】
[0084]  ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックのためのデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を記述するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例では、ＴＲＡＫボックス１５８は、コーディングされたビデオピクチャを含み得、一方、他の例では、トラックのコーディングされたビデオピクチャは、動画フラグメント１６４に含まれ得、それは、ＴＲＡＫボックス１５８および／またはｓｉｄｘボックス１６２のデータによって参照され得る。
【００７６】
[0085]  いくつかの例では、ビデオファイル１５０は、１より多くのトラックを含み得る。従って、ＭＯＯＶボックス１５４は、ビデオファイル１５０中のトラックの数（the number of tracks）に等しいいくつかのＴＲＡＫボックス（a number of TRAK boxes）を含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。例えば、ＴＲＡＫボックス１５８は、対応するトラックのための時間的および／または空間的情報を記述し得る。ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様なＴＲＡＫボックスは、カプセル化ユニット３０（図３）がビデオファイル１５０などのビデオファイル中にパラメータセットトラックを含めるとき、パラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットトラックを記述するＴＲＡＫボックス内でパラメータセットトラック中のシーケンスレベルＳＥＩメッセージの存在をシグナリングし得る。
【００７７】
[0086]  ＭＶＥＸボックス１６０は、例えば、もしあれば（if any）、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、ビデオファイル１５０が動画フラグメント１６４を含むことをシグナリングするために、対応する動画フラグメント１６４の特性を記述し得る。ビデオデータをストリーミングすることのコンテキストでは（In the context of streaming video data）、コーディングされたビデオピクチャは、ＭＯＯＶボックス１５４ではなく動画フラグメント１６４に含まれ得る。従って、全てのコーディングされたビデオサンプルは、ＭＯＯＶボックス１５４ではなく、動画フラグメント１６４に含まれ得る。
【００７８】
[0087]  ＭＯＯＶボックス１５４は、ビデオファイル１５０中の動画フラグメント１６４の数に等しいいくつかのＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、動画フラグメント１６４のうちの対応するもの（corresponding one）の特性を記述し得る。例えば、各ＭＶＥＸボックスは、動画フラグメント１６４のうちの対応するもののための時間的な持続時間を記述する動画拡張ヘッダボックス（ＭＥＨＤ）ボックスを含み得る。
【００７９】
[0088]  上記のように、カプセル化ユニット３０は、実際のコーディングされたビデオデータを含まないビデオサンプル中にシーケンスデータセットを記憶し得る。ビデオサンプルは概して、アクセスニットに対応し得、それは、特定の時間インスタンスにおけるコーディングされたピクチャの表現である。ＡＶＣのコンテキストでは、コーディングされたピクチャは、アクセスユニットの全てのピクセルを構築する（construct）ための情報を含む１つまたは複数のＶＣＬ ＮＡＬユニットおよびＳＥＩメッセージなどの他の関連した非ＶＣＬ ＮＡＬユニットを含む。従って、カプセル化ユニット３０は、動画フラグメント１６４のうちの１つに、シーケンスレベルＳＥＩメッセージを含み得る、シーケンスデータセットを含め得る。カプセル化ユニット３０はさらに、動画フラグメント１６４のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内で、動画フラグメント１６４のうちの１つに存在するものとして、シーケンスレベルＳＥＩメッセージおよび／またはシーケンスデータセットの存在をシグナリングし得る。
【００８０】
[0089]  ＳＩＤＸボックス１６２は、ビデオファイル１５０のオプションの要素である。すなわち、３ＧＰＰファイルフォーマット、または他のこのようなファイルフォーマットに準拠するビデオファイルは、必ずしもＳＩＤＸボックス１６２を含まない。３ＧＰＰファイルフォーマットの例に従って、ＳＩＤＸボックスは、セグメント（例えば、ビデオファイル１５０内に含まれるセグメント）のサブセグメント（a sub-segment of a segment(e.g., a segment contained within video file 150）)を識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを「動画フラグメントボックスの後に続き（follow）、および同じトラックについての情報を含む次の動画フラグメントボックスの前に来（precede）なければならない、動画フラグメントボックスによって参照されるデータを含むメディアデータボックスおよび対応するメディアデータボックス（１つまたは複数）（Media Data box(es)））を有する（with）１つまたは複数の連続する動画フラグメントボックスの自己充足型セット（a self-contained set）」と定義する。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが、「ボックスによって記録される（documented）（サブ）セグメントのサブセグメント（subsegments）への参照のシーケンスを含む」ことを示す。参照されるサブセグメントは、プレゼンテーション時間において連続的である。同様に、セグメントインデックスボックス（Segment Index box）によって参照される（referred to by）バイトは、常に（always）セグメント内で連続的である。参照されるサイズは、参照される素材におけるバイトの数のカウントを与える。
【００８１】
[0090]  ＳＩＤＸボックス１６２は概して、ビデオファイル１５０中に含まれるセグメントの１つまたは複数のサブセグメントを表す（representative of）情報を提供する。例えば、このような情報は、サブセグメントが開始および／または終了する再生時間、サブセグメントのためのバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（例えば、ストリームアクセスポイント（ＳＡＰ）から始まる）か否か、ＳＡＰのためのタイプ（例えば、ＳＡＰが瞬時デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャ、クリーンランダムアクセス（ＣＲＡ）ピクチャ、ブロークンリンクアクセス（ＢＬＡ）ピクチャ、または同様のものであるか）、サブセグメント中の（再生時間および／またはバイトオフセットの観点からの）ＳＡＰの位置、および同様のもの、を含み得る。
【００８２】
[0091]  動画フラグメント１６４は、１つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、動画フラグメント１６４は、１つまたは複数のピクチャのグループ（ＧＯＰ：group of pictures）を含み得、それらの各々は、いくつかの（a number of）コーディングされたビデオピクチャ、例えばフレームまたはピクチャを含み得る。加えて、上述したように、動画フラグメント１６４は、いくつかの例では、シーケンスデータセットを含み得る。動画フラグメント１６４の各々は、動画フラグメントヘッダボックス（ＭＦＨＤ、図４には図示されない）を含み得る。ＭＦＨＤボックスは、動画フラグメントのためのシーケンス番号などの対応する動画フラグメントの特性を記述し得る。動画フラグメント１６４は、ビデオファイル１５０に（in）シーケンス番号の順番で含まれ得る。
【００８３】
[0092]  ＭＦＲＡボックス１６６は、ビデオファイル１５０の動画フラグメント１６４内のランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０によってカプセル化されたセグメント内の特定の時間的ロケーション（すなわち、再生時間）への探索（seeks）を実施すること（performing）等の、トリックモードを行うことを支援し得る。ＭＦＲＡボックス１６６は、概して、オプションであり、いくつかの例では、ビデオファイルに含まれる必要はない。同様に、クライアントデバイス４０などのクライアントデバイスは、必ずしも、ビデオファイル１５０のビデオデータを正確に復号および表示するためにＭＦＲＡボックス１６６を参照する必要はない。ＭＦＲＡボックス１６６は、ビデオファイル１５０のトラックの数と等しいか、またはいくつかの例では、ビデオファイル１５０のメディアトラック（例えば、非ヒントトラック）の数と等しい、いくつかのトラックフラグメントランダムアクセス（ＴＦＲＡ）ボックス（図示せず）を含み得る。
【００８４】
[0093]  いくつかの例では、動画フラグメント１６４は、ＩＤＲピクチャなどの１つまたは複数のストリームアクセスポイント（ＳＡＰ）を含み得る。同様に、ＭＦＲＡボックス１６６は、ＳＡＰのビデオファイル１５０内のロケーションのインジケーションを提供し得る。従って、ビデオファイル１５０の時間的サブシーケンスは、ビデオファイル１５０のＳＡＰから形成され得る。時間的サブシーケンスはまた、ＳＡＰに従属する（depend from）Ｂフレームおよび／またはＰフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび／またはスライスは、サブシーケンスの他のフレーム／スライスに依存する時間的サブシーケンスのフレーム／スライスが適切に復号されることができるように、セグメント内に配列され得る。例えば、データの階層配列において、他のデータに関する予測のために使用されるデータもまた、時間的サブシーケンスに含まれ得る。
【００８５】
[0094]  図５は、通常のセグメント提供（regular segment offerings）と、より短い複数のセグメントを用いた提供（offerings with shorter segments）との例を図示する概念図である。すなわち、図５は、通常のセグメント提供１８０例と、より短い複数のセグメントを用いた提供１９０（offering with shorter segments 190）例とを図示する。図５に示されるように、より短いセグメントは、再生開始遅延を低減し得る。
【００８６】
[0095]  通常のセグメント提供１８０のような通常のＤＡＳＨ提供では、セグメント１８２Ａ、１８２Ｂ、１８２Ｃは、切り替え（switching）、ランダムアクセス、および同じ粒度での配信（delivery）を許可するように提供される。セグメント１８２Ａ、１８２Ｂ、１８２Ｃは、ビットストリーム切り替え、例えば、表現間の切り替えを可能にする、それぞれのランダムアクセスポイント（ＲＡＰ）１８４Ａ、１８４Ｂ、１８４Ｃを含む。コンテンツ生成器（例えば、図１のコンテンツ準備デバイス２０）が、パブリッシング（publishing）の前にフルセグメント１８２Ａ、１８２Ｂ、１８２Ｃを生成することが必要であり得るとき（As）、セグメント１８２Ａ、１８２Ｂ、１８２Ｃのためのセグメント利用可能開始時間（ＳＡＳＴ）は、セグメント１８２Ａ、１８２Ｂ、１８２Ｃのフルのそれぞれのもの（full respective one）が生成された時点で（once）のみ、利用可能である。より短い複数のセグメントを用いた提供１９０は、セグメント１９２Ａ〜１９２Ｋを含んでおり、セグメント１９２Ａ、１９２Ｇのみが、それぞれのＲＡＰ１９４Ａ、１９４Ｂを含んでいる。このようなより短いセグメントを用いると、セグメント利用可能性がより早くなることができ、全体的な遅延が低減され得る。
【００８７】
[0096]  しかしながら、通常のセグメント提供１８０およびより短い複数のセグメントを用いた提供１９０の両方について、ＳＡＳＴ並びにセグメントアドレスＵＲＬは、コーディングにおける不要な制限または頻繁なＭＰＤ更新のないコンパクトな方法でＭＰＤにおいてシグナリングされ、生成される必要がある。あるもの（One）は、より短い（smaller）セグメントのためのセグメントタイムラインを用いた明確な持続時間を使用し得る（下記の図６参照）が、これは、場合によっては（possibly）不明瞭なシグナリングおよび複雑なシグナリング、並びに（as well as）多くのＭＰＤ更新をもたらし得る。ビデオ中の予測チェーンのために、正確なプレゼンテーション持続時間（従って、アドレス）は決定されることができない（cannot）。
【００８８】
[0097]  図６は、通常のセグメント提供２００と、より短い複数のセグメントを用いた提供２１０（offering with shorter segments 210）とを介して利用可能なセグメントのためのユニフォームリソースロケータ（ＵＲＬ）アドレスを図示する概念図である。この例では、通常のセグメント提供２００は、セグメント２０２Ａ、２０２Ｂ、２０２Ｃを含んでおり、各々がそれぞれのＲＡＰ２０４Ａ、２０４Ｂ、２０４Ｃを含んでいる。より短い複数のセグメントを用いた提供２１０は、セグメント２１２Ａ〜２１２Ｋを含んでおり、セグメント２１２Ａと２１２Ｇのみが、それぞれ、ＲＡＰ２１４Ａ、２１４Ｂを含んでいる。
【００８９】
[0098]  図６に示されるように、より短いセグメント提供の使用は、より短いセグメントの間のプレゼンテーション持続時間を決定することを困難にし（make presentation durations for shorter segments difficult to determine）、従って、それらセグメントのためのＵＲＬアドレスもまた決定することが困難であり得る。従って、正確なセグメント持続時間を用いた$Time$アドレッシングは、現実的ではない可能性がある（may）。
【００９０】
[0099]  図７は、本開示の技法によってシグナリングされ得るデータの例示的なセットを図示する概念図である。図７は、例示的な通常のセグメント提供２２０と、複数のセグメントシーケンスおよび$Number$属性を用いた提供２３０とを図示する。通常のセグメント提供２２０は、セグメント２２２Ａ、２２２Ｂ、２２２Ｃを含んでおり、各々が、それぞれのＲＡＰ２２４Ａ、２２４Ｂ、２２４Ｃを含んでいる。この例では、複数のセグメントシーケンスおよび$Number$属性を用いた提供２３０は、セグメント２３２Ａ〜２３２Ｐを含んでおり、セグメント２３２Ａ、２３２Ｇ、２３２Ｌは、それぞれのＲＡＰ２３４Ａ、２３４Ｂ、２３４Ｃを含んでいる。
【００９１】
[0100]  本開示の技法は、概して、セグメントシーケンスに含まれるセグメントの数を指定するメディアプレゼンテーション記述（ＭＰＤ）ファイルなどのマニフェストファイルにおける属性をシグナリングすることを含む。例えば、ＭＰＤファイルに関して、「＠ｋ」属性は、ＭＰＤファイル中のセグメントタイムラインのＳ要素に追加され得る。
【００９２】
[0101]  図７の例で示されるように、属性は、複数のセグメントシーケンスおよび$Number$属性を用いた提供２３０のためにシグナリングされる。具体的には、図７における複数のセグメントシーケンスおよび$Number$属性を用いた提供２３０の例では、属性のセットが以下のようにシグナリングされる：media=“http://ab. com/$Time$_$SubNumber$. m4s”, S (t=1000; d=1000; k=6), S (t=2010; d=1000; k=5; r=1)
[0102]  図１のクライアントデバイス４０は、図７に示されるように、$Number$テンプレートを使用することによって、単に（simply）セグメント番号を増加させ得る。すなわち、図１のクライアントデバイス４０は、「１」ずつセグメント番号を増分すること（incrementing）によって、より短いセグメントの各々をアドレスし得る（例えば、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求などの要求において指定し得る）。図７の例では、例えば、通常のセグメント提供２２０のセグメント２２２Ａは、より短い複数のセグメントを用いた提供２３０のセグメント２３２Ａ〜２３２Ｆに対応し、通常のセグメント提供２２０のセグメント２２２Ｂは、より短い複数のセグメントを用いた提供２３０のセグメント２３２Ｇ〜２３２Ｋに対応し、通常のセグメント提供２２０のセグメント２２２Ｃは、より短い複数のセグメントを用いた提供２３０のセグメント２３２Ｌ〜２３２Ｐに対応する。
【００９３】
[0103]  セグメント２３２Ａ〜２３２Ｐは、増分ネーミング方式（incremental naming scheme）に従って名付けられ、ここで、この例では、セグメントの名前は、数に続く（a number followed by）「.m4s.」に対応する。例えば、セグメント２３２Ａは、「2.m4s」と名付けられ、セグメント２３２Ｂは、「3.m4s」と名付けられ、以下同様に繰り返される（and so on）。図１のクライアントデバイス４０（具体的には（in particular）、検索ユニット５２）は、対応するセグメントの名前を使用して、セグメント２３２Ａ〜２３２Ｐのうちの所望の１つ（desired one）のための識別子を指定し得る。例えば、セグメント２３２Ａを検索するために、クライアントデバイス４０は、ＵＲＬ「ab.com/2.m4s」を指定する要求をサーバデバイス６０に送り得る。このセグメントネーミング方式（または、アドレッシング方式）は、ある（certain）使用ケースについては、セグメント番号が単に１ずつ増加するため、うまく機能する（works well）。よって、これは、例えば、ＲＯＵＴＥ（Real-Time Object Delivery over Unidirectional Transport）を用いたＡＴＳＣ（Advanced Television Systems Committee）に関して有効になり得る。この方式はまた、ＤＡＳＨにおけるテンプレート方式（templating scheme）への更新を必要としない。
【００９４】
[0104]  他の使用ケースに関しては、このシンプルな数に基づくシグナリング（simple number based signaling）が、十分ではない可能性がある。その理由は、それが$Time$を用いて、または通常の提供が低レイテンシ提供とともに提供される使用ケースを用いて、機能しないからであり、セグメント番号が枝分かれ（diverge）するからである。これらの議論および$Time$に基づいて、$Number$および$Time$ベースのシグナリングの両方についての階層型ナンバリングが有益であり得る。
【００９５】
[0105]  図８は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の例を図示する。この例では、通常のセグメント提供２４０は、セグメント２４２Ａ、２４２Ｂ、２４２Ｃを含んでおり、その各々がそれぞれのＲＡＰ２４４Ａ、２４４Ｂ、２４４Ｃを含んでいる。複数のセグメントシーケンスを用いた提供２５０は、この例では、階層的に識別されたセグメント、すなわち、セグメント２５２Ａ〜２５２Ｐを含んでおり、およびセグメント２５２Ａ、２５２Ｇ、２５２Ｌは、それぞれのＲＡＰ２５４Ａ、２５４Ｂ、２５４Ｃを含んでいる。
【００９６】
[0106]  図８の例では、より短いセグメント２５２Ａ〜２５２Ｐは、階層型シグナリング方式を使用してアドレスされる。具体的には、図８の例では、通常のセグメント提供２４０のセグメント２４２Ａは、複数のセグメントシーケンスを用いた提供２５０の（この例では、「2_1.m4s」〜「2_6.m4s」と名付けられた）セグメント２５２Ａ〜２５２Ｆに対応し、通常の提供２４０のセグメント２４２Ｂは、複数のセグメントシーケンスを用いた提供２５０の（この例では、「3_1.m4s」〜「3_5.m4s」と名付けられた）セグメント２５２Ｇ〜２５２Ｋに対応し、通常の提供２４０のセグメント２４２Ｃは、複数のセグメントシーケンスを用いた提供２５０の（この例では、「4_1.m4s」〜「4_5.m4s」と名付けられた）セグメント２５２Ｌ〜２５２Ｐに対応する。セグメント２４２Ａ、２４２Ｂ、２４２Ｃは、この例では、それぞれ、「2.m4s」、「3.m4s」、「4.m4s」と名付けられている。このように、ネーミング方式は、セグメント２５２Ａ〜２５２Ｐがセグメント２４２Ａ〜２４２Ｃのうちの対応するものの名前を表す第１の部分と、セグメント２４２Ａ〜２４２Ｃのうちの同じものに対応しているセグメントシーケンス内のセグメント２５２Ａ〜２５２Ｐの相対的順序（relative order）を表す第２の部分と、の２部分形式で（in two-part form）名付けられるという点で、階層的であると言われることができる（can be said to）。
【００９７】
[0107]  よって、通常のセグメント提供２４０のセグメント２４２Ａ〜２４２Ｃの各々は、複数のセグメントシーケンスを用いた提供２５０のうちの１つの対応するセグメントシーケンス（a corresponding segment sequence）を有し得る。セグメント２５２Ａ〜２５２Ｐは、「M_N.m4s」に続く（followed by）ベースＵＲＬを指定するＵＲＬを要求すること（例えば、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を使用すること）によってアドレスされ得、ここで、「Ｍ」はセグメント２４２Ａ〜２４２Ｃのうちの対応するものの名前を表し、「Ｎ」はセグメント２４２Ａ〜２４２Ｃのうちの１つに対応するセグメントシーケンスにおけるセグメントの通常の識別子を表す。よって、セグメント２５２Ｊを検索するために、クライアントデバイス４０は、セグメント２５２Ｊがセグメント２４２Ｂに対応し、およびセグメントシーケンス中の４番目のセグメントであることを決定し得る。従って、クライアントデバイス４０は、セグメント２５２Ｊを検索するために「ab.com/3_4.m4s」を指定する要求を送り得る。
【００９８】
[0108]  このように、階層型シグナリングは、シンプルな切り替えと同様に、単一のＭＰＤにおける異なるサイズのセグメントの配置（deployment）を可能にし得る。このように、階層型シグナリングはまた、セグメントシーケンス中のセグメントのための持続時間の明確なシグナリングの必要性（need）を回避し得る。
【００９９】
[0109]  図９は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の別の例を図示する。この例では、セグメント番号によってセグメントをアドレスするのではなく、持続時間を表す情報によって、通常の提供のセグメントがアクセス可能となり得る。この例では、通常のセグメント提供２６０は、セグメント２６２Ａ〜２６２Ｃを含んでおり、各々がそれぞれのＲＡＰ２６４Ａ、２６４Ｂ、２６４Ｃを含んでいる。セグメント２６２Ａ〜２６２Ｃは、以前のセグメント（earlier segments）の蓄積された持続時間に加えて、それぞれのセグメントの持続時間に従って名付けられる。この例では、セグメント２６２Ａは１０１０の持続時間を有し、セグメント２６２Ｂは１０００の持続時間を有する。さらに、セグメント２６２Ａは、全体で（total）１０００のセグメント持続時間を有する１つまたは複数のセグメントの後に続く（follows）。よって、セグメント２６２Ａは「1000.m4s」と名付けられ、セグメント２６２Ｂは「2010.m4s」（１０００＋１０１０）と名付けられ、セグメント２６２Ｃは「3010.m4ｓ」（２０１０＋１０００）と名付けられる。
【０１００】
[0110]  複数のセグメントシーケンスを用いた提供２７０は、より短い複数のセグメント２７２Ａ〜２７２Ｐを含む。しかしながら、この例では、セグメント２７２Ａ〜２７２Ｐは、持続時間コンポーネントとサブナンバコンポーネントとによってアドレス可能であり得る。持続時間コンポーネントは、上述したように、通常のセグメント提供２６０中のセグメント２６２Ａ〜２６２Ｃのうちの対応するものの名前を表す。サブナンバコンポーネントは、複数のセグメントシーケンスを用いた提供２７０のセグメント２７２Ａ〜２７２Ｐのうちの１つについてのセグメント番号を表し得る。
【０１０１】
[0111]  よって、図９の例では、通常のセグメント提供２６０の（「1000.m4s」と名付けられた）セグメント２６２Ａは、複数のセグメントシーケンスを用いた提供２７０の（それぞれ、「1000_1.m4ｓ」〜「1000_6.m4s」と名付けられた）セグメント２７２Ａ〜２７２Ｆに対応し、通常のセグメント提供２６０の（「2010. m4s」と名付けられた）セグメント２６２Ｂは、複数のセグメントシーケンスを用いた提供２７０の（それぞれ、「2010_1.m4s」〜「2010_5.m4s」と名付けられた）セグメント２７２Ｇ〜２７２Ｋに対応し、通常のセグメント提供２６０の（「3010.m4s」と名付けられた）セグメント２６２Ｃは、複数のセグメントシーケンスを用いた提供２７０の（それぞれ、「3010_1.m4s」〜「3010_5.m4s」と名付けられた）セグメント２７２Ｌ〜２７２Ｐに対応する。
【０１０２】
[0112]  従って、クライアントデバイス４０は、上述したように、これらのセグメントの蓄積された持続時間に基づいて、セグメント２６２Ａ〜２６２Ｃの名前を決定し得る。さらに、クライアントデバイス４０は、セグメント２６２Ａ〜２６２Ｃのうちの対応するものについての名前を決定することによって、セグメント２７２Ａ〜２７２Ｐの名前／識別子を決定し得、そして（then）、セグメント２６２Ａ〜２６２Ｃのうちの１つに対応するセグメントのシーケンス内でセグメント２７２Ａ〜２７２Ｐのうちの１つの位置を決定する。例えば、図１のクライアントデバイス４０は、通常のセグメント提供２６０中の（in）対応するセグメント２６２Ｂの名前が「2010.m4s」であると決定することによって、およびセグメント２７２Ｊがセグメント２６２Ｂに対応するセグメントシーケンス中の４番目のセグメントであると決定することによって、セグメント２７２Ｊに関する名前が「2010_4.m4s」であると決定し得る。従って、要求セグメント２７２Ｊのために、クライアントデバイス４０は、セグメント２７２ＪのＵＲＬとして「ab.com/2010_4.m4s」を指定する部分的ＧＥＴ要求またはＨＴＴＰ ＧＥＴをサブミットし得る。
【０１０３】
[0113]  図９の例の１つの潜在的なアドバンテージは、同じ表現中の次のセグメントシーケンス（例えば、セグメント２６２Ｂに対応するセグメントシーケンス）の最も早いプレゼンテーション時間が、１つの（a）セグメントシーケンス中の全てのメディアセグメントの結合（concatenation）の結果として生じるセグメントの持続時間と、現在のセグメントシーケンス（１０００）の最も早いプレゼンテーションとの和（sum）から導出され得る、ということである。ＩＳＯ ＢＭＦＦのケースでは、これは、セグメントシーケンス中のセグメントのトラックラン（track runs）を合計することによって達成され得る。
【０１０４】
[0114]  このように、クライアントデバイス４０は、第１の部分と第２の部分とを含む２部分形式ネーミング方式を使用して、より短いセグメント提供の複数のセグメントをアドレスし得る。第１の部分は、（図８の例による（per））通常のセグメント提供２４０の対応するセグメント２４２Ａ〜２４２Ｃのセグメント番号または、（図９の例による）通常のセグメント提供２６０の対応するセグメント２６２Ａ〜２６２Ｃについてのタイミング情報を表し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第２の部分は、（図８および図９の例による）シンプルな数的増分（numeric increments）を表し得る。具体的には、２部分ネーミング方式は、それぞれ、「$Number$. $Chunk$」および「$Time$. $Chunk$」と呼ばれ得る。代替的に、２部分ネーミング方式は、それぞれ、「$Number$. $ChunkNumber$」と「$Time$. $ChunkNumber$」と呼ばれ得る。
【０１０５】
[0115]  代替的に、（図１のクライアントデバイス４０、サーバデバイス６０、およびコンテンツ準備デバイス２０などの）ＤＡＳＨを使用するデバイスは、より短いセグメント提供において利用可能なセグメント「チャンク」の数を示す属性（例えば、属性「＠ｋ」）などの、本明細書で説明されるデータを含むマニフェストファイルを処理（例えば、形成または解析および解釈）するために、並びに、上記で言及したマニフェストファイルの属性を使用して本明細書で説明される技法の任意のものまたは全てに従ってセグメントをアドレスするために、本開示の技法を使用するように構成され得る。
【０１０６】
[0116]  ＩＳＯ／ＩＥＣ ２３００９−１で規定されるようなＤＡＳＨの例に関して、ＤＡＳＨのセクション５．３．９．４．４は、下記に示すように修正され得、ここで、開始および終了（begin and end）の追加記号「｜｜＋＞｜｜」と「｜｜＋＜｜｜」とによって囲まれた文（text surrounded）は追加を表現しており、開始および終了の削除記号「−＞」と「｜｜−＜｜｜」とによって囲まれた文は削除を表現しており、他の部分は変わっていない。
【０１０７】
[0117]  ５．３．９．４．４      テンプレートベースのセグメントＵＲＬ構築
[0118]  SegmentTemplate@media属性、SegmentTemplate@index属性、SegmentTemplate@initialization属性、およびSegmentTemplate@bitstreamSwitching属性は、表１６中にリストされた識別子のうちの１つまたは複数を含み得る文字列を各々含む。
【０１０８】
[0119]  各ＵＲＬでは、表１６の（from）識別子は、表１６に定義された置換パラメータ（substitution parameter）によって置き換えられるべきである。識別子マッチングは、大文字と小文字を区別する（case-sensitive）。有効な識別子を含まない（do not enclose）アンエスケープされた＄シンボルをＵＲＬが含む場合、ＵＲＬ形成の結果は、定義されない。この場合、ＤＡＳＨクライアントは表現要素を含む全体を無視し、およびＭＰＤの処理があたかも（as if）この表現要素が存在しなかったかのように継続することが期待される。識別子のフォーマットもまた、表１６で指定されている。
【０１０９】
[0120]  各識別子は、このプロトタイプの後に（following）、ＩＥＥＥ １００３．１−２００８［１０］で定義されるように、printfフォーマットタグにアラインされた追加のフォーマットタグを(with)、「＄」で囲まれた文字内に（within）付加され得る：
[0121]  %0 [width]d
[0122]  幅パラメータ（width parameter）は、表示される（to be printed）文字の最小数を提供する符号なし整数（unsigned integer）である。表示される値がこの数よりも小さい（shorter）場合、結果はゼロで埋められる（padded）ものとする（shall）。値は、結果が大きくなったとしても切り捨てされない。
【０１１０】
[0123]  メディアプレゼンテーションは、置換プロセスの適用が有効なセグメントＵＲＬをもたらすように作成される（authored）ものとする。
【０１１１】
[0124]  識別子外の文字列は、ＲＦＣ ３９８６に従ってＵＲＬ内で許可される文字のみを含むものとする。  
【０１１２】
【表１】
2019523600.tif 000003
【０１１３】
[0125]  ５．３．９．６の変更      セグメントタイムライン（ＳＩＳＳＩ変更｜｜＋＞｜｜６｜｜＋＜｜｜          ｜｜−＞｜｜  ５｜｜−＜｜｜）
[0126]  ５．３．９．６．１      概要
[0127]  SegmentTimeline要素は、表現中の各セグメントに関する（@timescale属性に基づくユニット中の）プレゼンテーション持続時間および最も早いプレゼンテーション時間を表現する。この使用は、@duration属性を提供することに代わるものであり、３つの追加の特徴を提供する。  
・任意のセグメント持続時間の規格（specification）
・持続時間がセグメントのプレゼンテーション持続時間を表す１つのメディアストリームの間の（for）明確な（accurate）セグメント持続時間の規格
・特定の表現中にセグメントデータが存在しないメディアプレゼンテーションタイムラインの不連続性のシグナリング
・セグメントシーケンスをシグナリングするための能力。さらなる詳細については、５．３．９．６．４を参照。セグメントシーケンスは、使用中のプロファイルによって明示的に許可されている場合にのみ、使用されるものとする。
【０１１４】
[0128]  簡潔化のために、この要素のシンタックスは、一定の持続時間を有するセグメントのシーケンスを表現するためのランレングス圧縮を含む。
【０１１５】
[0129]  SegmentTimeline（以下、原文にて太字の箇所に下線を付す）要素は、Ｓ要素のリストを含むものとし、その各々が同一のＭＰＤ持続時間の連続的なセグメントのシーケンスを説明する。Ｓ要素は、ＭＰＤ持続時間を指定する必須＠ｄ属性、任意の（optional）＠ｔ時間属性、および、１をマイナスした、同一のＭＰＤ持続時間を用いた（with）連続的なセグメントの数を指定するオプションの＠ｒ繰り返しカウント属性を含む。@presentationTimeOffsetの値をマイナスした（minus）＠ｔ属性の値は、系列内の（in the series）第１のセグメントのＭＰＤ開始時間を指定する。
【０１１６】
[0130]  存在しない時（when）、＠ｒ属性は、ゼロのデフォルト値（すなわち、系列（series）内の単一のセグメント）を有する。例えば、３の繰り返しカウント（a repeat count of three）は、各々が同じＭＰＤ持続時間を有する４つの連続的なセグメントがあることを意味する。Ｓ要素の＠ｒ属性の値は、次のＳ要素のＳ＠ｔまで、あるいは、それが、期間の終了またはＭＰＤの次の更新まで、SegmentTimeline要素中の最後のＳ要素である場合、＠ｄに示された持続時間が繰り返すことが約束されていることを示す負の値に設定され得、すなわち、それは、全期間の間（for）@duration属性と同じ方法で処理される。任意の＠ｄ値は、MPD@maxSegmentDurationの値を超えないものとする。
【０１１７】
[0131]  SegmentTimeline要素内のＳ要素のテキストの順序は、対応するメディアセグメントのナンバリング（ひいては（and thus）、時間）順序と一致する（match）ものとする。
【０１１８】
[0132]  SegmentTemplateが使用中であり、および$Time$識別子がSegmentTemplate@media中に存在するとき：  
・セグメントインデックス（「sidx」）ボックスが存在する場合、SegmentTimelineの値は、各メディアセグメントの正確なタイミングを記述するものとする。具体的には、これらの値は、セグメントインデックス（「sidx」）ボックスに提供される情報を反映する（reflect）ものとする。すなわち：  ・@timescaleの値は、第１の「sidx」ボックス中のタイムスケールフィールドの値と一致するものとする  
・Ｓ＠ｔの値は、Ｓで説明されるメディアセグメントの第１の「sidx」ボックス中のearliest_presentation_timeの値と一致するものとする  
・Ｓ＠ｄの値は、Ｓで説明されるメディアセグメントの第１の「sidx」ボックス中の全てのSubsegment_durationフィールドの値の和と一致するものとする  
・セグメントインデックス（「sidx」）ボックスが存在しない場合、最も早いプレゼンテーション時間の導出は、メディア内部データに基づくものとする。詳細は、使用中のセグメントフォーマットに従い（depend on）、セグメントフォーマットにおけるさらなる制限が適用され得る  
・メディアセグメントのためのセグメントＵＲＬは、SegmentTimelineから取得された最も早いプレゼンテーション時間によって、$Time$識別子を置き換えることによって取得される  
[0133]  ノート：同じ表現における次のメディアセグメントの最も早いプレゼンテーション時間が、例えば、セグメントインデックスの使用によって、実際のメディアセグメントから導出され得るとき（As）、セグメントＵＲＬは、セグメントタイムラインへの更新を含む更新されたＭＰＤを読み取ることなく（without reading of）生成され得る。
【０１１９】
[0134]  セグメントタイムラインについての属性および要素のセマンティクスが、表１７の５．３．９．６．２に提供されている。セグメントタイムラインのＸＭＬシンタックスが、５．３．９．６．３で提供されている。
【０１２０】
[0135]  ５．３．９．６．２      セマンティクス
【０１２１】
【表２−１】
2019523600.tif 000004
【０１２２】
【表２−２】
2019523600.tif 000005
【０１２３】
[0136]  ５．３．９．６．３      ＸＭＬシンタックス
【０１２４】
【数１】
2019523600.tif 000006
【０１２５】
｜｜＋＞｜｜５．３．９．６．４      セグメントシーケンス
[0137]  セグメントタイムライン中のセグメントシーケンスは、SegmentTimelineのＳ要素中に＠ｋ属性を含むことで（with）シグナリングされ得る。＠ｋは、下記の要件の全てが満たされる場合にのみ、存在するものとする。  
・関連付けられた表現についてのアドレッシング方式が、５．３．９．６．５で定義されるように、$Number$または階層テンプレート化およびサブナンバリングのいずれかでセグメントテンプレートを使用している  
・プロファイルがセグメントシーケンスの使用を明示的に可能にする。
【０１２６】
[0138]  ＠ｋが存在しおよび１よりも大きい場合、それは、＠ｄによって記述されたシーケンスがタイミングは正確だが、＠ｋセグメントを含むことを指定する。
【０１２７】
[0139]  セグメントのＭＰＤ持続時間は、＠ｋの値で除算された＠ｄの値として決定され、ＭＰＤ開始時間、ひいては（and therefore）セグメント利用可能開始時間を決定する。セグメントのＭＰＤ持続時間がセグメントのメディア持続時間と正確に一致する必要はないことに留意されたい。
【０１２８】
[0140]  セグメントシーケンス中の全てのセグメントの連結は、＠ｄの値に従って正確なセグメント持続時間を有するものとする。
【０１２９】
[0141]  ５．３．９．６．５      階層型テンプレートおよびサブナンバリング
[0142]  セグメントテンプレートが$SubNumber$値を含み、およびセグメントシーケンスを有する（with）セグメントタイムラインシグナリングが使用される場合、そして（then）  
・$Time$が存在する場合、$Time$は、セグメントシーケンス中の全てのセグメントについてのセグメントシーケンスの最も早いプレゼンテーション時間と置き換えられる  
・$Number$が存在する場合、$Number$は、セグメントシーケンスの数と、すなわち、セグメントタイムライン中の全てのセグメントシーケンスが単一のセグメントとして扱われるかのように（as）その数と置き換えられる  
・両方のケースでは、$SubNumber$は、セグメントシーケンスのセグメント番号を、シーケンス中の第１のセグメントの数である１と置き換えられる  
[0143]  ノート：同じ表現中の次のセグメントシーケンスの最も早いプレゼンテーション時間は、現在のセグメントシーケンスの最も早いプレゼンテーションと、セグメントシーケンス中の全てのメディアセグメントの連結から生じるセグメントの持続時間との和から導出され得る。ＩＳＯ ＢＭＦＦのケースでは、これは、セグメントシーケンス中のセグメントのトラックランを合計することによって達成され得る。｜｜＋＜｜｜
[0144]  図１０は、本開示の技法によるメディアデータを搬送（送信および受信）する例示的な方法を図示するフローチャートである。図１０の方法は、図１のサーバデバイス６０とクライアントデバイス４０とによって行われているように表現されている。しかしながら、追加のまたは代替のデバイスがこれをまたは同様の方法を行うように構成され得ることが理解されるだろう。例えば、コンテンツ準備デバイス２０は、サーバデバイス６０と連動して、またはそれに変わって、サーバデバイスに起因する（attributed）方法の一部分（portions）を行い得る。
【０１３０】
[0145]  始めに、サーバデバイス６０は、メディアデータのセグメントのチャンクの利用可能性を決定し得る（３００）。例えば、サーバデバイス６０は、メディアデータの表現または適用セットの複数のセグメントの各々の（for）チャンクの数（a number of chunks）を決定し得る。サーバデバイス６０は次に、メディアプレゼンテーション記述（ＭＰＤ）などのマニフェストファイル中の利用可能データを指定し得る（３０２）。例えば、上述したように、サーバデバイス６０は、マニフェストファイルのセグメントタイムライン要素中のＳ要素の「＠ｋ」要素をシグナリングし得る。＠ｋ要素は、セグメントシーケンスに含まれるセグメントの数を表現し得る。このようなセグメントの数は、１つのセグメントのチャンクとして認識され（be understood）得、セグメントシーケンスは、対応するセグメントのためのチャンクのシーケンスに対応し得る。サーバデバイス６０は次に、例えば、マニフェストファイルのためのクライアントデバイス４０からの要求に応答して、クライアントデバイス４０にマニフェストファイルを送り得る（３０４）。
【０１３１】
[0146]  クライアントデバイス４０は、マニフェストファイルを受信し得る（３０６）。クライアントデバイス４０は次に、マニフェストファイルからのチャンク利用可能データを決定し得る（３０８）。例えば、クライアントデバイス４０の検索ユニット５２（図１）は、セグメント中のチャンクの数を決定するために、マニフェストファイルから「＠ｋ」要素を抽出し得る。クライアントデバイス４０は次に、チャンクのための識別子を、その塊（hunks）のための利用可能データを使用して決定し得る（３１０）。例えば、図８および図９に関して上述したように、クライアントデバイス４０は、（上述したように、通常の識別子または持続時間に基づく識別子であり得る）通常のセグメント提供において対応するセグメントの名前を表現する第１の部分と、（同様に、上述したように）セグメントに対応するチャンクのシーケンス中のチャンクの通常の識別子を表現する第２の部分と、のチャンクのための２つの部分の識別子を決定し得る。
【０１３２】
[0147]  検索されるべきチャンクのための識別子を決定した後、クライアントデバイス４０は、チャンクのための識別子を指定する要求を送り得る（３１２）。例えば、クライアントデバイス４０は、要求のためのＵＲＬの一部として、チャンクのための識別子を指定するＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を構築し得る。クライアントデバイス４０は次に、サーバデバイス６０にその要求を送り得る。
【０１３３】
[0148]  サーバデバイス６０は次に、その要求を受信し得る（３１４）。サーバデバイス６０は、例えば、チャンクのためのＵＲＬなどの、要求において指定されるような識別子を使用して、要求されたチャンクを決定し得る（３１６）。サーバデバイス６０は次に、クライアントデバイス４０に、要求されたチャンクを送り得る（３１８）。
【０１３４】
[0149]  クライアントデバイス４０は次に、チャンクを順に（in turn）受信し得（３２０）、チャンクのメディアデータを復号および提示し得る（３２２）。例えば、（代替的に、ファイル処理または構文解析ユニットと呼ばれ得る）非カプセル化ユニット５０は、符号化されたメディアデータをチャンクから抽出し、メディアデータのタイプに依存して、符号化メディアデータをオーディオデコーダ４６またはビデオデコーダ４８に送り得る。オーディオデコーダ４６／ビデオデコーダ４８は、メディアデータを復号し、復号されたメディアデータを、プレゼンテーションのためにオーディオ出力４２／ビデオ出力４４に送り得る。
【０１３５】
[0150]  このように、図１０の方法は、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの１つのための識別子を決定することと、サーバデバイスに、チャンクのうちの１つのための識別子を指定する要求を送ることと、を含む方法の例を表す。
【０１３６】
[0151]  １つまたは複数の例では、記述された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらのあらゆる組み合わせで実装され得る。ソフトウェアにおいて実装される場合、それら機能は、コンピュータ可読媒体上で１つまたは複数の命令またはコードとして記憶あるいは送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの移送を容易にする任意の媒体を含む通信媒体またはデータ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は概して、（１）非一時的な有形のコンピュータ可読記憶媒体または（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明される技法の実装のための命令、コード、および／またはデータ構造を検索するために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【０１３７】
[0152]  限定ではなく例として、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいは、データ構造または命令の形態で所望されるプログラムコードを記憶するために使用されることができ、かつコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的な媒体を含むのではなく、代わりに、非一時的な有形の記憶媒体を対象としていることは理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク（登録商標）およびブルーレイ（登録商標）ディスクを含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組み合わせもまたコンピュータ可読媒体の範囲内に含めるべきである。
【０１３８】
[0153]  命令は、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、あるいは他の同等な集積またはディスクリートロジック回路などの１つまたは複数のプロセッサによって実行され得る。従って、本明細書で使用されるとき、「プロセッサ」という用語は、任意の前述の構造または本明細書で説明された技法の実装に適した任意の他の構造を指し得る。加えて、いくつかの態様では、本明細書で説明された機能性は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に提供され得るか、複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素で十分に実装され得る。
【０１３９】
[0154]  この開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い多様なデバイスまたは装置内に実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネントまたはユニットが説明されたが、それらは、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ、上述したように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられるか、適切なソフトウェアおよび／またはファームウェアと併せて、上述したような１つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。
【０１４０】
[0155]  様々な例が説明された。これらの例および他の例は、以下の請求項の範囲内にある。
【図１】
2019523600.tif 000007
【図２】
2019523600.tif 000008
【図３】
2019523600.tif 000009
【図４】
2019523600.tif 000010
【図５】
2019523600.tif 000011
【図６】
2019523600.tif 000012
【図７】
2019523600.tif 000013
【図８】
2019523600.tif 000014
【図９】
2019523600.tif 000015
【図１０】
2019523600.tif 000016
【手続補正書】
【提出日】平成31年4月9日(2019.4.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディアデータを検索する方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を備える、方法。
【請求項２】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備え、ここにおいて、前記属性は、前記＠ｋ属性を備え、ここにおいて、前記要素は、前記Ｓ要素を備える、請求項１に記載の方法。
【請求項３】
前記チャンクのうちの前記１つのための前記識別子を決定することは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを備える、請求項１に記載の方法。
【請求項４】
前記チャンクのうちの前記１つのための前記識別子を決定することは、階層型アドレッシング方式に従って前記識別子を決定することを備える、請求項１に記載の方法。
【請求項５】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項４に記載の方法。
【請求項６】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５に記載の方法。
【請求項７】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項５に記載の方法。
【請求項８】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項７に記載の方法。
【請求項９】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５に記載の方法。
【請求項１０】
前記要求を送ることは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを備える、請求項１に記載の方法。
【請求項１１】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記方法は、ＵＲＬテンプレートに従って前記ＵＲＬを決定することをさらに備える、請求項１に記載の方法。
【請求項１２】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項１に記載の方法。
【請求項１３】
前記識別子を決定することは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを備える、請求項１に記載の方法。
【請求項１４】
前記セグメントのための前記開始時間、前記セグメントの前記持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルの前記データを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することをさらに備える、請求項１に記載の方法。
【請求項１５】
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
をさらに備える、請求項１に記載の方法。
【請求項１６】
メディアデータを検索するためのデバイスであって、前記デバイスは、回路に実装され、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行うように構成された１つまたは複数のプロセッサを備える、デバイス。
【請求項１７】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備え、ここにおいて、前記属性は、前記＠ｋ属性を備え、ここにおいて、前記要素は、前記Ｓ要素を備える、請求項１６に記載のデバイス。
【請求項１８】
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することのように構成される、請求項１６に記載のデバイス。
【請求項１９】
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記識別子を決定するように構成される、請求項１６に記載のデバイス。
【請求項２０】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項１９に記載のデバイス。
【請求項２１】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項２０に記載のデバイス。
【請求項２２】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項２０に記載のデバイス。
【請求項２３】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項２２に記載のデバイス。
【請求項２４】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項２０に記載のデバイス。
【請求項２５】
前記要求を送るために、前記１つまたは複数のプロセッサは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送るように構成される、請求項１６に記載のデバイス。
【請求項２６】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記１つまたは複数のプロセッサは、ＵＲＬテンプレートに従って前記ＵＲＬを決定するようにさらに構成される、請求項１６に記載のデバイス。
【請求項２７】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項１６に記載のデバイス。
【請求項２８】
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定するように構成される、請求項１６に記載のデバイス。
【請求項２９】
前記１つまたは複数のプロセッサは、前記セグメントのための前記開始時間、前記セグメントの前記持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定するようにさらに構成される、請求項１６に記載のデバイス。
【請求項３０】
前記１つまたは複数のプロセッサは、
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を行うようにさらに構成される、請求項１６に記載のデバイス。
【請求項３１】
メディアデータを検索するためのデバイスであって、前記デバイスは、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定するための手段と、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送るための手段と
を備える、デバイス。
【請求項３２】
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行わせる、コンピュータ可読記憶媒体。
【請求項３３】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備え、ここにおいて、前記属性は、前記＠ｋ属性を備え、ここにおいて、前記要素は、前記Ｓ要素を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３４】
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３５】
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、階層型アドレッシング方式に従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項３６】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項３５に記載のコンピュータ可読記憶媒体。
【請求項３７】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３８】
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３９】
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項３８に記載のコンピュータ可読記憶媒体。
【請求項４０】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項４１】
前記要求を送ることを前記プロセッサに行わせる前記命令は、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４２】
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、ＵＲＬテンプレートに従って前記ＵＲＬを決定することを前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４３】
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４４】
前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４５】
前記セグメントのための前記開始時間、前記セグメントの前記持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することを前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４６】
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を前記プロセッサに行わせる命令をさらに備える、請求項３２に記載のコンピュータ可読記憶媒体。
【請求項４７】
メディアデータを送る方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを生成することと、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を備える、方法。
【請求項４８】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備え、ここにおいて、前記属性は、前記＠ｋ属性を備え、ここにおいて、前記要素は、前記Ｓ要素を備える、請求項４７に記載の方法。
【請求項４９】
前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送ることをさらに備える、請求項４７に記載の方法。
【請求項５０】
階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送ることをさらに備える、請求項４７に記載の方法。
【請求項５１】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項５０に記載の方法。
【請求項５２】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５１に記載の方法。
【請求項５３】
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項５１に記載の方法。
【請求項５４】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５１に記載の方法。
【請求項５５】
メディアデータを送るためのサーバデバイスであって、前記サーバデバイスは、
マニフェストファイルと前記メディアデータとを記憶するように構成されたメモリと、
回路に実装され、
前記メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むように前記マニフェストファイルを生成することと、セグメントチャンクの前記数を示す前記データは、前記マニフェストファイルの要素の属性を備え、前記要素は、前記セグメントの前記セグメントチャンクの連続するシーケンスの開始時間および持続時間を指定し、前記属性は、前記セグメントの前記セグメントチャンクの前記連続するシーケンスに含まれるチャンクの数を指定し、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を行うように構成された１つまたは複数のプロセッサと
を備える、サーバデバイス。
【請求項５６】
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備え、ここにおいて、前記属性は、前記＠ｋ属性を備え、ここにおいて、前記要素は、前記Ｓ要素を備える、請求項５５に記載のデバイス。
【請求項５７】
前記１つまたは複数のプロセッサは、前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送るように構成される、請求項５５に記載のデバイス。
【請求項５８】
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送るように構成される、請求項５５に記載のデバイス。
【請求項５９】
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、請求項５８に記載のデバイス。
【請求項６０】
前記第１の部分は、前記セグメントのための識別番号を指定する、請求項５９に記載のデバイス。
【請求項６１】
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項５９に記載のデバイス。
【請求項６２】
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、請求項５９に記載のデバイス。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１４０
【補正方法】変更
【補正の内容】
【０１４０】
[0155]  様々な例が説明された。これらの例および他の例は、以下の請求項の範囲内にある。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
メディアデータを検索する方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を備える、方法。
［Ｃ２］
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、Ｃ１に記載の方法。
［Ｃ３］
前記チャンクのうちの前記１つのための前記識別子を決定することは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを備える、Ｃ１に記載の方法。
［Ｃ４］
前記チャンクのうちの前記１つのための前記識別子を決定することは、階層型アドレッシング方式に従って前記識別子を決定することを備える、Ｃ１に記載の方法。
［Ｃ５］
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、Ｃ４に記載の方法。
［Ｃ６］
前記第１の部分は、前記セグメントのための識別番号を指定する、Ｃ５に記載の方法。
［Ｃ７］
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、Ｃ５に記載の方法。
［Ｃ８］
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、Ｃ７に記載の方法。
［Ｃ９］
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、Ｃ５に記載の方法。
［Ｃ１０］
前記要求を送ることは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを備える、Ｃ１に記載の方法。
［Ｃ１１］
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記方法は、ＵＲＬテンプレートに従って前記ＵＲＬを決定することをさらに備える、Ｃ１に記載の方法。
［Ｃ１２］
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、Ｃ１に記載の方法。
［Ｃ１３］
前記識別子を決定することは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを備える、Ｃ１に記載の方法。
［Ｃ１４］
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することをさらに備える、Ｃ１に記載の方法。
［Ｃ１５］
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
をさらに備える、Ｃ１に記載の方法。
［Ｃ１６］
メディアデータを検索するためのデバイスであって、前記デバイスは、回路に実装され、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行うように構成された１つまたは複数のプロセッサを備える、デバイス。
［Ｃ１７］
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、Ｃ１６に記載のデバイス。
［Ｃ１８］
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することのように構成される、Ｃ１６に記載のデバイス。
［Ｃ１９］
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記識別子を決定するように構成される、Ｃ１６に記載のデバイス。
［Ｃ２０］
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、Ｃ１９に記載のデバイス。
［Ｃ２１］
前記第１の部分は、前記セグメントのための識別番号を指定する、Ｃ２０に記載のデバイス。
［Ｃ２２］
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、Ｃ２０に記載のデバイス。
［Ｃ２３］
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、Ｃ２２に記載のデバイス。
［Ｃ２４］
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、Ｃ２０に記載のデバイス。
［Ｃ２５］
前記要求を送るために、前記１つまたは複数のプロセッサは、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送るように構成される、Ｃ１６に記載のデバイス。
［Ｃ２６］
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記１つまたは複数のプロセッサは、ＵＲＬテンプレートに従って前記ＵＲＬを決定するようにさらに構成される、Ｃ１６に記載のデバイス。
［Ｃ２７］
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、Ｃ１６に記載のデバイス。
［Ｃ２８］
前記１つまたは複数のプロセッサは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定するように構成される、Ｃ１６に記載のデバイス。
［Ｃ２９］
前記１つまたは複数のプロセッサは、前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定するようにさらに構成される、Ｃ１６に記載のデバイス。
［Ｃ３０］
前記１つまたは複数のプロセッサは、
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を行うようにさらに構成される、Ｃ１６に記載のデバイス。
［Ｃ３１］
メディアデータを検索するためのデバイスであって、前記デバイスは、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定するための手段と、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送るための手段と
を備える、デバイス。
［Ｃ３２］
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの１つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記１つのための前記識別子を指定する要求を送ることと
を行わせる、コンピュータ可読記憶媒体。
［Ｃ３３］
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ３４］
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ３５］
前記チャンクのうちの前記１つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、階層型アドレッシング方式に従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ３６］
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、Ｃ３５に記載のコンピュータ可読記憶媒体。
［Ｃ３７］
前記第１の部分は、前記セグメントのための識別番号を指定する、Ｃ３６に記載のコンピュータ可読記憶媒体。
［Ｃ３８］
前記第１の部分は、前記セグメントのためのタイミング情報を指定する、Ｃ３６に記載のコンピュータ可読記憶媒体。
［Ｃ３９］
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、Ｃ３８に記載のコンピュータ可読記憶媒体。
［Ｃ４０］
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、Ｃ３６に記載のコンピュータ可読記憶媒体。
［Ｃ４１］
前記要求を送ることを前記プロセッサに行わせる前記命令は、ＨＴＴＰ ＧＥＴ要求またはＨＴＴＰ部分的ＧＥＴ要求のうちの１つを送ることを前記プロセッサに行わせる命令を備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４２］
前記セグメントチャンクは、それぞれのＵＲＬを有する複数のセグメントを備えるセグメントシーケンスとして提供され、ＵＲＬテンプレートに従って前記ＵＲＬを決定することを前記プロセッサに行わせる命令をさらに備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４３］
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４４］
前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを前記プロセッサに行わせる命令を備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４５］
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することを前記プロセッサに行わせる命令をさらに備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４６］
前記マニフェストファイルからの前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を前記プロセッサに行わせる命令をさらに備える、Ｃ３２に記載のコンピュータ可読記憶媒体。
［Ｃ４７］
メディアデータを送る方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を備える、方法。
［Ｃ４８］
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、Ｃ４７に記載の方法。
［Ｃ４９］
前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための$Number$テンプレートを定義するデータを送ることをさらに備える、Ｃ４７に記載の方法。
［Ｃ５０］
階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、階層型アドレッシング方式を定義するデータを送ることをさらに備える、Ｃ４７に記載の方法。
［Ｃ５１］
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、Ｃ５０に記載の方法。
［Ｃ５２］
前記第１の部分は、前記セグメントのための識別番号を指定する、Ｃ５１に記載の方法。
［Ｃ５３］
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、Ｃ５１に記載の方法。
［Ｃ５４］
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、Ｃ５１に記載の方法。
［Ｃ５５］
メディアデータを送るためのサーバデバイスであって、前記サーバデバイスは、
マニフェストファイルと前記メディアデータとを記憶するように構成されたメモリと、
回路に実装され、
前記メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むように前記マニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ（ＵＲＬ）を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの１つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された１つを送ることと、
を行うように構成された１つまたは複数のプロセッサと
を備える、サーバデバイス。
［Ｃ５６］
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述（ＭＰＤ）のSegmentTimeline要素のＳ要素に含まれる＠ｋ属性を備える、Ｃ５５に記載のデバイス。
［Ｃ５７］
前記１つまたは複数のプロセッサは、前記チャンクのうちの前記１つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送るように構成される、Ｃ５５に記載のデバイス。
［Ｃ５８］
前記１つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記チャンクのうちの前記１つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送るように構成される、Ｃ５５に記載のデバイス。
［Ｃ５９］
前記階層型アドレッシング方式は、前記識別子のための第１の部分と第２の部分とを指定する、Ｃ５８に記載のデバイス。
［Ｃ６０］
前記第１の部分は、前記セグメントのための識別番号を指定する、Ｃ５９に記載のデバイス。
［Ｃ６１］
前記第１の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、Ｃ５９に記載のデバイス。
［Ｃ６２］
前記第２の部分は、前記チャンクのうちの前記１つの通常の識別子を示す、Ｃ５９に記載のデバイス。
【国際調査報告】
2019523600.tif 000017
2019523600.tif 000018
2019523600.tif 000019