JP2022550528A - 適応ビットレートマルチキャストのための修復機構 - Google Patents

Abstract

メディアデータを取り出すための例示的なデバイスが、メディアデータを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、パケット損失シグナリング機構を示すデータを受信することと、パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットは、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を行うように構成される。【選択図】図６

Description

優先権の主張

[0001]本出願は、各々の内容全体が参照により本明細書に組み込まれる、２０２０年９月３０日に出願された米国出願第１７／０３９，４４２号、および２０１９年１０月１日に出願された米国仮出願第６２／９０８，９４９号の利益を主張する。

[0002]本開示は、メディアデータのトランスポートに関する。

[0003]デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲のデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するための、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３またはＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ）、（高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれる）ＩＴＵ－Ｔ Ｈ．２６５によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。

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

[0005]概して、本開示は、パケット損失を検出し、損失したメディアデータを取り出すための技法について説明する。特に、本開示の技法によれば、サーバデバイスが、ストリーミングされたメディアビットストリームについてのパケット損失を検出するためにクライアントデバイスによって使用されるべきパケット損失シグナリング機構（mechanism）をシグナリングし得る。パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ユニフォームリソースロケータ（ＵＲＬ）、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの１つまたは複数であり得る。クライアントデバイスは、ストリーミングされたメディアビットストリーム中の損失したパケットを検出するために（１つまたは複数の）パケット損失シグナリング機構を使用し得る。損失したパケットを検出したことに応答して、クライアントデバイスは、損失したパケット中に含まれるメディアデータを含むメディアファイルの一部分（たとえば、セグメント）を指定するバイト範囲要求を使用して、損失したパケットの一部または全部の（some or all）消失したメディアデータを取り出し得る。このようにして、クライアントデバイスは適切なメディアオブジェクトを取得し得、ここで、適切なメディアオブジェクトは、依然として、消失したメディアデータの一部を消失していることがあるが、適切なメディアオブジェクトが適切にパースされ、復号され、提示され得るようにフォーマットされ得る。

[0006]一例では、メディアデータを取り出す方法は、パケット損失シグナリング機構を示すデータを受信することと、パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットは、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を含む。

[0007]別の例では、メディアデータを取り出すためのデバイスは、メディアデータを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、パケット損失シグナリング機構を示すデータを受信することと、パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットが、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を行うように構成される。

[0008]別の例では、命令が記憶されたコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、パケット損失シグナリング機構を示すデータを受信することと、パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットは、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を行わせる。

[0009]別の例では、メディアデータを取り出すためのデバイスが、パケット損失シグナリング機構を示すデータを受信するための手段と、パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出するための手段と、損失したパケットが、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成するための手段と；適切なメディアオブジェクトをメディアアプリケーションに配信するための手段と、を含む。

[0010]別の例では、メディアデータを送出する方法が、パケット損失シグナリング機構を示すデータを送出することと、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出することと、を含む。

[0011]別の例では、メディアデータを送出するためのデバイスが、ビデオデータを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、パケット損失シグナリング機構を示すデータを送出することと、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出することと、を行うように構成される。

[0012]別の例では、命令が記憶されたコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、パケット損失シグナリング機構を示すデータを送出することと、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出することと、を行わせる。

[0013]別の例では、メディアデータを送出するためのデバイスが、パケット損失シグナリング機構を示すデータを送出するための手段と、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出するための手段と；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信するための手段と；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出するための手段と、を含む。

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

[0015]ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図。 [0016]クライアントデバイスの取出しユニットの構成要素の例示的なセットを示すブロック図。 [0017]例示的なマルチメディアコンテンツの要素を示す概念図。 [0018]セグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図。 [0019]本開示の技法による、送出機（sender）と受信機とを含む例示的なシステムを示す概念図。 [0020]本開示の技法による、例示的な方法を示すフローチャート。

[0021]ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７２６において入手可能な、Ｔ．Ｐａｉｌａら、「FLUTE-File Delivery over Unidirectional Transport」、ネットワークワーキンググループ、ＲＦＣ６７２６、２０１２年１１月に記載されている、ファイル配信オーバー単方向トランスポート（ＦＬＵＴＥ：File Delivery over Unidirectional Transport）、およびＲＯＵＴＥのような、単方向コンテンツ配信プロトコルは、マルチキャストプロトコルの様々なレベルでのパケット損失の検出のための様々な機構を指定する。この損失検出は、トランスポートオブジェクト全体がパケットの損失により損失しないように、修復プロシージャをトリガすることを可能にする。修復は、一般に、バイト範囲要求として始動され、したがって、受信機は、そのような要求を始動するために十分な情報を有する必要がある。

[0022]プロシージャは、以下のようなセットアップであり得る。送出機は、損失したパケットを識別し、修復プロシージャを可能にするために、コンテンツ配信プロトコルセットアップにおいて、および個々のパケット中で情報（たとえば、必要とされる情報）を与える。受信機は、その情報を使用して、一般にユニキャストバイト範囲要求によって、その情報を修復するか、あるいは、それらが利用可能でないかもしくは不成功であるか、または遅れている場合、損失は、ＨＴＴＰインターフェースを通してシグナリングされ得るか、のいずれかである。

[0023]損失検出シグナリング機構は、以下を含み得る。最も低いレベルでは、損失したパケットの検出は、トランスポートパケットのヘッダ中で直接シグナリングすることによって可能にされ得る。たとえば、ＲＯＵＴＥでは、オブジェクトならびにオブジェクト内のパケットがシーケンス順序で送出されるモードが使用されるとき、ＬＣＴパケットヘッダ中のｓｔａｒｔ＿ｏｆｆｓｅｔフィールドおよびＢフラグ、ＥＸＴ＿ＴＯＬ ＬＣＴ拡張ヘッダ、ならびにトランスポートオブジェクト識別子（ＴＯＩ）フィールドが使用され得る。ｓｔａｒｔ＿ｏｆｆｓｅｔフィールドは、配信オブジェクトの最初のバイトに対する、現在のパケット中のデータの開始バイト位置を示す。ここで、パケットは、配信オブジェクトの隣接する（複数の）データ部分からなる。したがって、受信機は、最後のパケットのｓｔａｒｔ＿ｏｆｆｓｅｔおよびペイロードのサイズに一致しないｓｔａｒｔ＿ｏｆｆｓｅｔをもつパケットを受信すると、損失したパケットを検出することができる。ｂフラグは、配信オブジェクトの最後のパケット中で設定され得る。これは、（トランスポートオブジェクトの長さをシグナリングする）ＥＸＴ＿ＴＯＬ ＬＣＴヘッダ拡張および／またはＴＯＩフィールドとともに、パケットの損失を検出するために使用され得る。たとえば、設定されたＢフラグをもつパケットを受信することなしでの新しいＴＯＩをもつパケットの受信の開始は、損失したパケットを示し得る。

[0024]修復シグナリング機構は、以下を含み得る。ＲＯＵＴＥでは、上記のように、パケットのｓｔａｒｔ＿ｏｆｆｓｅｔおよびサイズが、配信オブジェクト中の消失したバイト範囲を決定するために使用され得る。したがって、受信されたパケットｉに後続し、受信されたパケットｋに先行する消失したパケットｊの場合、消失したデータのバイト範囲は、「消失したデータバイト範囲＝ｓｔａｒｔ＿ｏｆｆｓｅｔ（ｉ）＋サイズ（ｉ）～ｓｔａｒｔ＿ｏｆｆｓｅｔ（ｋ）－１」である。消失したパケットが配信オブジェクトの最後のパケットである場合、厳密なサイズはこのようにして決定され得ず、受信機は、配信オブジェクトの終了まですべてのバイトを要求しなければならないことになる。

[0025]ＦＬＵＴＥとＲＯＵＴＥの両方が、それぞれ、ファイル配信テーブル（ＦＤＴ）および拡張ＦＤＴ（ＥＦＤＴ）インスタンスのための満了時間機構を与える。これはまた、このＦＤＴまたはＥＦＤＴインスタンスによってシグナリングされたマルチキャストパケットが上記のタイムアウト後に予想されないことがあることを暗黙的にシグナリングする。ＦＤＴ／ＥＦＤＴにおいてＡｌｔｅｒｎａｔｅ－Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ－１要素およびＡｌｔｅｒｎａｔｅ－Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ－２要素をシグナリングすることは、ゲートウェイが、ユニキャストを介して同じオブジェクトにアクセスするためのロケーションを見つけることを可能にする。また、ＦＤＴ／ＥＦＤＴインスタンスにおけるオブジェクトメタデータ満了タイムアウトが、上記で説明されたシグナリングと連携して、またはそれの代わりに、サービス／セッションメタデータシグナリングにおいて制御プレーン中でシグナリングされ得る。制御プレーンは、ユニキャストを介して同じコンテンツのロケーションの再構築を可能にするために基本ＵＲＬを搬送し得る。

[0026]マルチキャストゲートウェイとＤＡＳＨプレーヤとの間のシグナリングは、以下を含み得る。マルチキャストゲートウェイがＤＡＳＨプレーヤへのエラーのないコンテンツの配信を保証することができない場合、そのような場合を扱うために、マルチキャストゲートウェイとＤＡＳＨプレーヤとの間の特殊シグナリングが必要とされ得る。

[0027]ＴＳ２６．３４６、節７．９．２によれば、ストリーミングアプリケーションは部分ファイルを受け付けることができる。ファイルを取り出すためにＨＴＴＰ ＧＥＴ要求を使用するアプリケーションは、新しい３ＧＰＰ（登録商標）定義メディアタイプ「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌ」とともに、ＲＦＣ７２３１において定義されている「受付（Accept）」要求ヘッダを、ＨＴＴＰ ＧＥＴ要求中に含め得る。ファイルを取り出すためにＨＴＴＰ ＧＥＴ要求を使用するアプリケーションは、新しい３ＧＰＰ定義メディアタイプ「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌ」とともに、ＲＦＣ７２３１において定義されている「受付」要求ヘッダを、ＧＥＴ要求中に含め得る。このヘッダを与え、そのような部分ファイル受付要求を発行することによって、アプリケーションは、それが部分ファイル応答を受信することが可能であることをシグナリングする。

[0028]そのような受付ヘッダの使用の一例は、以下の通りである。
Ａｃｃｅｐｔ：＊／＊，ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌ
[0029]この例では、アプリケーションは、それが、応答中のすべてのメディアタイプ、ならびにａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌによって指定された特定の「不完全な」タイプを受け付けることを示す。

[0030]ＭＢＭＳクライアントが、メディアタイプ「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌ」とともに「受付」要求を含む通常ＨＴＴＰ ＧＥＴ要求、すなわち、部分ファイル受付要求を受信し、ＭＢＭＳクライアントが少なくとも１つのバイトをもつ部分ファイルを受信した場合、ＭＢＭＳクライアントは、ＴＳ２６．３４６に従って以下のように定義される部分ファイル応答で応答し得る。

・ 応答コードは２００ ＯＫに設定される
・ Ｃｏｎｔｅｎｔ－Ｔｙｐｅヘッダは、ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ－ｐａｒｔｉａｌに設定されるものとする。

・ メッセージ本文は、マルチパートメッセージ本文であり、ＲＦＣ７２３３、アネックスＡに記載されているｍｕｌｔｉｐａｒｔ／ｂｙｔｅｒａｎｇｅｓメディアタイプと同じフォーマットであり得る。ｍｕｌｔｉｐａｒｔ／ｂｙｔｅｒａｎｇｅｓメディアタイプは、各々が、返されている部分ファイルの（１つまたは複数の）バイト範囲を伝達するための手段としてそれ自体のＣｏｎｔｅｎｔ－ＴｙｐｅフィールドおよびＣｏｎｔｅｎｔ－Ｒａｎｇｅフィールドをもつ、１つまたは複数の本文部分を含む。各Ｃｏｎｔｅｎｔ－Ｔｙｐｅヘッダは、このファイルについてＦＤＴインスタンスにおいて与えられるＣｏｎｔｅｎｔ－Ｔｙｐｅの値に設定される。ファイルのＣｏｎｔｅｎｔ－Ｔｙｐｅに割り当てられたハンドラがファイルにアクセスし得るバイト位置を与える拡張ヘッダ（たとえば、３ｇｐｐ－ａｃｃｅｓｓ－ｐｏｓｉｔｉｏｎ）が追加され得る。値は、存在する場合、ｍｂｍｓ２０１５：ＩｎｄｅｐｅｎｄｅｎｔＵｎｉｔＰｏｓｉｔｉｏｎｓから作成され得る。

・ 中間プロキシが不完全なファイルを記憶し、それを別のアプリケーションにサービスするのを防ぐために、キャッシュディレクティブ（cache directive）が応答中に含められるべきである。そのようなキャッシュディレクティブについての例は、「Ｃａｃｈｅ－Ｃｏｎｔｒｏｌ：ｍａｘ－ａｇｅ＝０」または「Ｃａｃｈｅ－Ｃｏｎｔｒｏｌ：ｎｏ－ｃａｃｈｅ」である。

[0031]ＭＢＭＳクライアントが部分ファイル受付要求を受信し、ＭＢＭＳクライアントがバイトをもたない部分ファイルを受信した（すなわち、ファイルメタデータを記述するＦＤＴインスタンスのみが受信された）場合、ＭＢＭＳクライアントは、以下のように定義される部分ファイル応答で応答し得る。

・ 応答コードは、４１６ Ｒｅｑｕｅｓｔｅｄ Ｒａｎｇｅ Ｎｏｔ Ｓａｔｉｓｆｉａｂｌｅに設定される
・ Ｃｏｎｔｅｎｔ－Ｔｙｐｅヘッダは、このファイルについてＦＤＴインスタンスにおいて与えられるＣｏｎｔｅｎｔ－Ｔｙｐｅの値に設定される。

・ Ｃｏｎｔｅｎｔ－Ｒａｎｇｅはｂｙｔｅｓ ＊／Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈに設定され、Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ属性Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈの値は、このファイルについてＦＤＴインスタンスにおいて与えられる。

[0032]これについての例は、ＴＳ２６．３４６、節７．９．２．３において与えられている。

[0033]本開示の技法は、ＩＳＯベースメディアファイルフォーマット、スケーラブルビデオコーディング（ＳＶＣ）ファイルフォーマット、アドバンストビデオコーディング（ＡＶＣ）ファイルフォーマット、第３世代パートナーシッププロジェクト（３ＧＰＰ）ファイルフォーマット、および／またはマルチビュービデオコーディング（ＭＶＣ）ファイルフォーマット、あるいは他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。

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

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

[0036]メディアプレゼンテーションは、１つまたは複数の期間のシーケンスを含んでいることがある。各期間は、次の期間の開始まで、または最後の期間の場合、メディアプレゼンテーションの終了まで継続し得る。各期間は、同じメディアコンテンツについて１つまたは複数の表現を含んでいることがある。表現は、オーディオ、ビデオ、タイムドテキスト、または他のそのようなデータのいくつかの代替符号化バージョンのうちの１つであり得る。表現は、符号化タイプによって、たとえば、ビデオデータの場合、ビットレート、解像度、および／またはコーデックによって、ならびに、オーディオデータの場合、ビットレート、言語、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された符号化オーディオまたはビデオデータのセクションを指すために使用され得る。

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

[0038]表現は１つまたは複数のセグメントを含み得る。各表現が初期化セグメントを含み得るか、または表現の各セグメントが自己初期化していることがある。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含んでいることがある。概して、初期化セグメントはメディアデータを含んでいない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソースネーム（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ）などの識別子によって一意に参照され得る。ＭＰＤは各セグメントに識別子を与え得る。いくつかの例では、ＭＰＤはまた、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能なファイル内のセグメントのためのデータに対応し得るバイト範囲をｒａｎｇｅ属性の形態で与え得る。

[0039]異なるタイプのメディアデータについての実質的に同時の取出しのために、異なる表現が選択され得る。たとえば、クライアントデバイスが、セグメントをそこから取り出すべきオーディオ表現、ビデオ表現、およびタイムドテキスト表現を選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適応を実施するための特定の適応セットを選択し得る。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および／またはタイムドテキストを含む適応セットを選択し得る。代替的に、クライアントデバイスは、いくつかのタイプのメディア（たとえば、ビデオ）のための適応セットを選択し、他のタイプのメディア（たとえば、オーディオおよび／またはタイムドテキスト）のための表現を直接選択し得る。

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

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

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

[0043]ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれているビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時に、オーディオソース２２によってキャプチャされた（または生成された）オーディオデータを含んでいるオーディオフレームである。たとえば、通話参加者が概して話すことによってオーディオデータを生成する間、オーディオソース２２はオーディオデータをキャプチャし、同時に、すなわちオーディオソース２２がオーディオデータをキャプチャしている間、ビデオソース２４は通話参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータとビデオデータとが同時にキャプチャされた状況、およびオーディオフレームとビデオフレームとが、それぞれ、同時にキャプチャされたオーディオデータとビデオデータとを備える状況に対応する。

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

[0045]いくつかの例では、オーディオソース２２は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ２６に送出し得、ビデオソース２４は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ２８に送出し得る。いくつかの例では、オーディオエンコーダ２６は、必ずしもオーディオデータが記録された絶対時間を示すことなしに、符号化オーディオデータの相対時間的順序を示すために、符号化オーディオデータ中のシーケンス識別子を符号化し得、同様に、ビデオエンコーダ２８も、符号化ビデオデータの相対時間的順序を示すためにシーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、タイムスタンプでマッピングされるか、またはさもなければタイムスタンプと相関させられ得る。

[0046]オーディオエンコーダ２６は概して符号化オーディオデータのストリームを生成し、ビデオエンコーダ２８は符号化ビデオデータのストリームを生成する。データの各個々のストリームは（オーディオかビデオかにかかわらず）エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現のデジタル的にコード化された（場合によっては圧縮された）単一の成分である。たとえば、表現のコード化ビデオまたはオーディオ部分はエレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化エレメンタリストリーム（ＰＥＳ）に変換され得る。同じ表現内では、１つのエレメンタリストリームに属するＰＥＳパケットを他のものから区別するためにストリームＩＤが使用され得る。エレメンタリストリームの基本データ単位はパケット化エレメンタリストリーム（ＰＥＳ）パケットである。したがって、コード化ビデオデータは概してエレメンタリビデオストリームに対応する。同様に、オーディオデータは１つまたは複数のそれぞれのエレメンタリストリームに対応する。

[0047]ＩＴＵ－Ｔ Ｈ．２６４／ＡＶＣおよび来るべき高効率ビデオコーディング（ＨＥＶＣ）規格など、多くのビデオコーディング規格は、シンタックスと、セマンティクスと、エラーのないビットストリームのための復号プロセスとを定義し、これらのいずれも、あるプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般に、エンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダについて規格に準拠することを保証するというタスクを与えられる。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、特徴、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびブロック処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはｐｒｏｆｉｌｅ＿ｉｄｃ（プロファイルインジケータ）値でシグナリングされ得るが、レベルはｌｅｖｅｌ＿ｉｄｃ（レベルインジケータ）値でシグナリングされ得る。

[0048]Ｈ．２６４規格は、たとえば、所与のプロファイルのシンタックスによって課される限界内で、復号ピクチャの指定されたサイズなど、ビットストリーム中のシンタックス要素によってとられる値に応じて、エンコーダおよびデコーダのパフォーマンスの大きい変動を必要とする可能性が依然としてあることを認識している。Ｈ．２６４規格は、多くの適用例において、特定のプロファイル内でシンタックスのすべての仮定的使用に対処することが可能なデコーダを実装することが実際的でもなく、経済的でもないことをさらに認識している。したがって、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に課された制約の指定されたセットとして「レベル」を定義する。これらの制約は、値に関する単純な制限であり得る。代替的に、これらの制約は、値の演算の組合せ（たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数）に関する制約の形態をとり得る。Ｈ．２６４規格は、個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートし得ることをさらに規定する。

[0049]プロファイルに準拠するデコーダは、通常、プロファイル中で定義されたすべての特徴をサポートする。たとえば、コーディング特徴として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイルではサポートされないが、Ｈ．２６４／ＡＶＣの他のプロファイルではサポートされる。レベルに準拠するデコーダは、レベルにおいて定義された制限を超えてリソースを必要としない任意のビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、説明可能性のために役立ち得る。たとえば、ビデオ送信中に、プロファイル定義とレベル定義のペアが全送信セッションについてネゴシエートされ、同意され得る。より具体的には、Ｈ．２６４／ＡＶＣでは、レベルは、処理される必要があるマクロブロックの数に関する制限と、復号ピクチャバッファ（ＤＰＢ）サイズと、コード化ピクチャバッファ（ＣＰＢ）サイズと、垂直動きベクトル範囲と、２つの連続するＭＢごとの動きベクトルの最大数と、Ｂブロックが８×８ピクセル未満のサブマクロブロック区分を有することができるかどうかとを定義し得る。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうかを決定し得る。

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

[0051]ビデオエンコーダ２８は、様々なビットレートにおいて、ならびにピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格のための様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（たとえば、２次元または３次元再生のための）１つまたは複数のビューを有する表現、あるいは他のそのような特性などの様々な特性を用いてマルチメディアコンテンツの異なる表現を生成するために、様々な方法でマルチメディアコンテンツのビデオデータを符号化し得る。本開示で使用される、表現は、オーディオデータ、ビデオデータ、（たとえば、字幕のための）テキストデータ、または他のそのようなデータのうちの１つを備え得る。表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなど、エレメンタリストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するｓｔｒｅａｍ＿ｉｄを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々な表現のビデオファイル（たとえば、セグメント）にアセンブルすることを担う。

[0052]カプセル化ユニット３０は、オーディオエンコーダ２６とビデオエンコーダ２８とから表現のエレメンタリストリームのためのＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを形成する。コード化ビデオセグメントは、ビデオテレフォニー、記憶、ブロードキャスト、またはストリーミングなどのアプリケーションに対処する「ネットワークフレンドリ」なビデオ表現を与える、ＮＡＬユニットに編成され得る。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとに分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含んでいることがあり、ブロック、マクロブロック、および／またはスライスレベルデータを含み得る。他のＮＡＬユニットは非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では、通常は１次コード化ピクチャとして提示される、１つの時間インスタンス中のコード化ピクチャは、１つまたは複数のＮＡＬユニットを含み得るアクセスユニット中に含まれていることがある。

[0053]非ＶＣＬ ＮＡＬユニットは、特に、パラメータセットＮＡＬユニットとＳＥＩ ＮＡＬユニットとを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）中の）シーケンスレベルヘッダ情報と、（ピクチャパラメータセット（ＰＰＳ）中の）まれに変化するピクチャレベルヘッダ情報とを含んでいることがある。パラメータセット（たとえば、ＰＰＳおよびＳＰＳ）がある場合、まれに変化する情報がシーケンスごとまたはピクチャごとに繰り返される必要はなく、したがって、コーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし、誤り耐性のための冗長送信の必要を回避し得る。帯域外送信の例では、ＳＥＩ ＮＡＬユニットなど、他のＮＡＬユニットとは異なるチャネル上でパラメータセットＮＡＬユニットが送信され得る。

[0054]補足エンハンスメント情報（ＳＥＩ）は、ＶＣＬ ＮＡＬユニットからのコード化ピクチャサンプルを復号するためには必要でないが、復号、表示、誤り耐性、および他の目的に関係するプロセスを支援し得る情報を含んでいることがある。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニット中に含まれていることがある。ＳＥＩメッセージは、一部の規格仕様の規範的部分であり、したがって、規格に準拠するデコーダ実装のために常に必須であるとは限らない。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージまたはピクチャレベルＳＥＩメッセージであり得る。ＳＶＣの例におけるスケーラビリティ情報ＳＥＩメッセージ、およびＭＶＣにおけるビュースケーラビリティ情報ＳＥＩメッセージなどのＳＥＩメッセージ中に、何らかのシーケンスレベル情報が含まれていることがある。これらの例示的なＳＥＩメッセージは、たとえば、動作点の抽出およびそれらの動作点の特性に関する情報を伝達し得る。さらに、カプセル化ユニット３０は、表現の特性を記述するメディアプレゼンテーション記述子（ＭＰＤ）など、マニフェストファイルを形成し得る。カプセル化ユニット３０は、拡張可能マークアップ言語（ＸＭＬ）に従ってＭＰＤをフォーマットし得る。

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

[0056]いくつかの例では、表現６８は適応セットに分離され得る。すなわち、表現６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、表現を用いて表示されるべきテキストおよび／または復号され、たとえばスピーカーによって提示されるべきオーディオデータの言語または他の特性を識別し得るテキストタイプ情報、適応セット中の表現のためのシーンのカメラアングルまたは現実世界のカメラパースペクティブを記述し得るカメラアングル情報、特定の視聴者についてのコンテンツ適合性を記述するレーティング情報など、特性のそれぞれの共通セットを含み得る。

[0057]マニフェストファイル６６は、特定の適応セットに対応する表現６８のサブセットを示すデータ、ならびに適応セットについての共通の特性を含み得る。マニフェストファイル６６はまた、ビットレートなど、適応セットの個々の表現についての個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にし得る。適応セット中の表現は、マニフェストファイル６６の適応セット要素の子要素を使用して示され得る。

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

[0059]要求処理ユニット７０は、クライアントデバイス４０などのクライアントデバイスから、記憶媒体６２のデータについてのネットワーク要求を受信するように構成される。たとえば、要求処理ユニット７０は、Ｒ．Ｆｉｅｌｄｉｎｇらによる、ＲＦＣ２６１６、「Hypertext Transfer Protocol - HTTP/1.1」、ネットワークワーキンググループ、ＩＥＴＦ、１９９９年６月に記載されている、ハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１を実装し得る。すなわち、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴ要求または部分ＧＥＴ要求を受信し、これらの要求に応答してマルチメディアコンテンツ６４のデータを与えるように構成され得る。要求は、たとえば、セグメントのＵＲＬを使用して、表現６８のうちの１つのセグメントを指定し得る。いくつかの例では、要求はまた、セグメントの１つまたは複数のバイト範囲を指定し、したがって部分ＧＥＴ要求を備え得る。要求処理ユニット７０は、表現６８のうちの１つのセグメントのヘッダデータを与えるためのＨＴＴＰ ＨＥＡＤ要求をサービスするようにさらに構成され得る。いずれの場合も、要求処理ユニット７０は、要求されたデータをクライアントデバイス４０などの要求元デバイスに与えるために要求を処理するように構成され得る。

[0060]追加または代替として、要求処理ユニット７０は、ｅＭＢＭＳなどのブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ作成デバイス２０は、説明された方法と実質的に同じ方法でＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用して、これらのセグメントまたはサブセグメントを配信し得る。たとえば、要求処理ユニット７０は、クライアントデバイス４０からマルチキャストグループ加入要求を受信するように構成され得る。すなわち、サーバデバイス６０は、マルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ）アドレスを、クライアントデバイス４０を含む、特定のメディアコンテンツ（たとえば、ライブイベントのブロードキャスト）に関連付けられたクライアントデバイスに広告し得る。クライアントデバイス４０は、マルチキャストグループに加入するための要求をサブミットし得る。この要求は、ネットワーク７４、たとえば、ネットワーク７４を構成するルータ全体にわたって伝搬され得、その結果、ルータは、マルチキャストグループに関連付けられたＩＰアドレスに宛てられたトラフィックを、クライアントデバイス４０など、サブスクライブするクライアントデバイスに向けさせられる。

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

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

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

[0064]概して、より高いビットレート表現はより高品質のビデオ再生を生じ得、より低いビットレート表現は、利用可能なネットワーク帯域幅が減少したとき、十分な品質のビデオ再生を与え得る。したがって、利用可能なネットワーク帯域幅が比較的高いとき、取出しユニット５２は比較的高いビットレート表現からデータを取り出し得るが、利用可能なネットワーク帯域幅が低いとき、取出しユニット５２は比較的低いビットレート表現からデータを取り出し得る。このようにして、クライアントデバイス４０は、ネットワーク７４を介してマルチメディアデータをストリーミングしながら、ネットワーク７４の変化するネットワーク帯域幅利用可能性にも適応し得る。

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

[0066]ネットワークインターフェース５４は、選択された表現のセグメントのデータを受信し、取出しユニット５２に与え得、取出しユニット５２は、そのセグメントをカプセル化解除ユニット５０に与え得る。カプセル化解除ユニット５０は、ビデオファイルの要素を構成ＰＥＳストリームにカプセル化解除し、符号化データを取り出すためにＰＥＳストリームをパケット化解除し、たとえば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化データがオーディオストリームの一部であるのかビデオストリームの一部であるのかに応じて、符号化データをオーディオデコーダ４６またはビデオデコーダ４８のいずれかに送出し得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号オーディオデータをオーディオ出力４２に送出し、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力４４に送出する。

[0067]ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、取出しユニット５２、およびカプセル化解除ユニット５０は各々、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な好適な処理回路のいずれかとして実装され得る。ビデオエンコーダ２８およびビデオデコーダ４８の各々は、１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。同様に、オーディオエンコーダ２６およびオーディオデコーダ４６の各々は、１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合コーデックの一部として統合され得る。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、取出しユニット５２、および／またはカプセル化解除ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。

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

[0069]カプセル化ユニット３０は、ＮＡＬユニットが属するプログラムを識別するヘッダ、ならびにペイロード、たとえば、オーディオデータ、ビデオデータ、あるいはＮＡＬユニットが対応するトランスポートまたはプログラムストリームを記述するデータを備える、ＮＡＬユニットを形成し得る。たとえば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは、１バイトのヘッダと、変動するサイズのペイロードとを含む。それのペイロード中にビデオデータを含むＮＡＬユニットは、様々なグラニュラリティレベルのビデオデータを備え得る。たとえば、ＮＡＬユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を備え得る。カプセル化ユニット３０は、エレメンタリストリームのＰＥＳパケットの形態でビデオエンコーダ２８から符号化ビデオデータを受信し得る。カプセル化ユニット３０は、各エレメンタリストリームを対応するプログラムに関連付け得る。

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

[0071]したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオおよびビデオフレーム、たとえば、時間Ｘに対応するすべてのビューを備え得る。本開示はまた、特定のビューの符号化ピクチャを「ビュー構成要素」と呼ぶ。すなわち、ビュー構成要素は、特定の時間における特定のビューのための符号化ピクチャ（またはフレーム）を備え得る。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビュー構成要素を備えるものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示順序と同じである必要があるとは限らない。

[0072]メディアプレゼンテーションは、異なる代替表現（たとえば、異なる品質をもつビデオサービス）の記述を含んでいることがあるメディアプレゼンテーション記述（ＭＰＤ）を含み得、その記述は、たとえば、コーデック情報と、プロファイル値と、レベル値とを含み得る。ＭＰＤは、マニフェストファイル６６などのマニフェストファイルの一例である。クライアントデバイス４０は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスすべきかを決定するためにメディアプレゼンテーションのＭＰＤを取り出し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス（ｍｏｏｆボックス）中にあり得る。

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

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

[0075]ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し、取出しユニット５２を介してＮＡＬユニットまたはアクセスユニットをカプセル化解除ユニット５０に与え得る。カプセル化解除ユニット５０は、ビデオファイルの要素を構成ＰＥＳストリームにカプセル化解除し、符号化データを取り出すためにＰＥＳストリームをパケット化解除し、たとえば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化データがオーディオストリームの一部であるのかビデオストリームの一部であるのかに応じて、符号化データをオーディオデコーダ４６またはビデオデコーダ４８のいずれかに送出し得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号オーディオデータをオーディオ出力４２に送出し、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力４４に送出する。

[0076]本開示の技法によれば、サーバデバイス６０（またはコンテンツ作成デバイス２０）は、クライアントデバイス４０にパケット損失検出機構をシグナリングし得る。たとえば、サーバデバイス６０は、サーバデバイス６０とクライアントデバイス４０との間の制御チャネルを介してパケット損失検出機構をシグナリングし得る。パケット損失検出機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中に設定される特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの１つまたは複数を含み得る。

[0077]クライアントデバイス４０は、次いで、サーバデバイス６０からのブロードキャストまたはマルチキャストストリーム中のパケットが損失したかどうかを決定するために、（１つまたは複数の）シグナリングされたパケット損失検出機構を実施し得る。１つまたは複数のパケットが損失したと決定したことに応答して、取出しユニット５２は、損失したパケットのメディアデータを含むセグメントの（１つまたは複数の）バイト範囲を指定する１つまたは複数のバイト範囲要求（すなわち、ＨＴＴＰ部分Ｇｅｔ要求）を形成し得る。取出しユニット５２は、次いで、ユニキャストプロトコル、たとえばＨＴＴＰを介して、損失したメディアデータを取り出すことを試みるために、これらのバイト範囲要求をサーバデバイス６０にサブミットし得る。

[0078]いくつかの例では、サーバデバイス６０は、パケット間タイムアウト値をシグナリングし得る。クライアントデバイス４０（および特に、取出しユニット５２）は、パケット間タイムアウト値を使用して、パケットが損失したかどうかを決定し得る、たとえば、パケットが、メディアストリームの前のパケットの受信以来、パケット間タイムアウト間隔内に受信されなかった場合。パケット間タイムアウト値は、公称共通メディアアプリケーションフォーマット（ＣＭＡＦ）チャンク持続時間に対応し得る。サーバデバイス６０は、たとえば、ファイル配信テーブル（ＦＤＴ）、拡張ＦＤＴ（ｅＦＤＴ）において、あるいは制御プレーンサービスまたはセッションメタデータ中で、パケット間タイムアウト値をシグナリングし得る。したがって、クライアントデバイス４０は、このデータからパケット間タイムアウト値を抽出し得る。

[0079]損失したメディアデータが受信されたか否かにかかわらず、取出しユニット５２は、カプセル化解除ユニット５０に配信されるべき、および、最終的に、オーディオデコーダ４６および／またはビデオデコーダ４８に配信されるべき適切なメディアオブジェクトを形成し得る。適切なメディアオブジェクトは、概して、カプセル化解除ユニット５０、オーディオデコーダ４６、およびビデオデコーダ４８によってパース可能（parseable）および復号可能であり得る。適切なメディアオブジェクトは、依然として、（１つまたは複数の）損失したパケットのメディアデータの一部を消失していることがあるが、それにもかかわらず、パース可能および復号可能であり得る。

[0080]図２は、図１の取出しユニット５２の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット５２は、ｅＭＢＭＳミドルウェアユニット１００と、ＤＡＳＨクライアント１１０と、メディアアプリケーション１１２とを含む。

[0081]この例では、ｅＭＢＭＳミドルウェアユニット１００は、ｅＭＢＭＳ受信ユニット１０６と、キャッシュ１０４と、プロキシサーバユニット１０２とをさらに含む。この例では、ｅＭＢＭＳ受信ユニット１０６は、たとえば、ＦＬＵＴＥに従って、ｅＭＢＭＳを介してデータを受信するように構成される。すなわち、ｅＭＢＭＳ受信ユニット１０６は、たとえば、ブロードキャスト／マルチキャストサービスセンター（ＢＭ－ＳＣ）として働き得るサーバデバイス６０から、ブロードキャストを介してファイルを受信し得る。

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

[0083]プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０のためのサーバとして働き得る。たとえば、プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０にＭＰＤファイルまたは他のマニフェストファイルを与え得る。プロキシサーバユニット１０２は、ＭＰＤファイル中のセグメントのための利用可能性時間、ならびにセグメントがそこから取り出され得るハイパーリンクを広告し得る。これらのハイパーリンクは、クライアントデバイス４０に対応するローカルホストアドレスプレフィックス（たとえば、ＩＰｖ４についての１２７．０．０．１）を含み得る。このようにして、ＤＡＳＨクライアント１１０は、ＨＴＴＰ ＧＥＴ要求または部分ＧＥＴ要求を使用してプロキシサーバユニット１０２にセグメントを要求し得る。たとえば、リンクｈｔｔｐ：／／１２７．０．０．１／ｒｅｐ１／ｓｅｇ３から入手可能なセグメントの場合、ＤＡＳＨクライアント１１０は、ｈｔｔｐ：／／１２７．０．０．１／ｒｅｐ１／ｓｅｇ３についての要求を含むＨＴＴＰ ＧＥＴ要求を構築し、その要求をプロキシサーバユニット１０２にサブミットし得る。プロキシサーバユニット１０２は、要求されたデータをキャッシュ１０４から取り出し、そのデータを、そのような要求に応答してＤＡＳＨクライアント１１０に与え得る。

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

[0085]ＭＰＤ１２２は、表現１２４とは別個のデータ構造を備え得る。ＭＰＤ１２２は図１のマニフェストファイル６６に対応し得る。同様に、表現１２４は図１の表現６８に対応し得る。概して、ＭＰＤ１２２は、コーディング特性およびレンダリング特性、適応セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（たとえば、時間サブシーケンスを含む表現を示す情報）、ならびに／または（たとえば、再生中のメディアコンテンツへのターゲット広告挿入のための）リモート期間を取り出すための情報など、表現１２４の特性を概して記述するデータを含み得る。

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

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

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

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

[0090]ファイルタイプ（ＦＴＹＰ）ボックス１５２は、概して、ビデオファイル１５０のためのファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０の最良の使用法を記述する仕様を識別するデータを含み得る。ファイルタイプボックス１５２は、代替的に、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に配置され得る。

[0091]いくつかの例では、ビデオファイル１５０など、セグメントは、ＦＴＹＰボックス１５２の前にＭＰＤ更新ボックス（図示せず）を含み得る。ＭＰＤ更新ボックスは、ＭＰＤを更新するための情報とともに、ビデオファイル１５０を含む表現に対応するＭＰＤが更新されるべきであることを示す情報を含み得る。たとえば、ＭＰＤ更新ボックスは、ＭＰＤを更新するために使用されるべきリソースについてのＵＲＩまたはＵＲＬを与え得る。別の例として、ＭＰＤ更新ボックスは、ＭＰＤを更新するためのデータを含み得る。いくつかの例では、ＭＰＤ更新ボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示せず）の直後にくることがあり、ここで、ＳＴＹＰボックスは、ビデオファイル１５０のためのセグメントタイプを定義し得る。

[0092]ＭＯＯＶボックス１５４は、図４の例では、ムービーヘッダ（ＭＶＨＤ）ボックス１５６と、トラック（ＴＲＡＫ）ボックス１５８と、１つまたは複数のムービー拡張（ＭＶＥＸ）ボックス１６０とを含む。概して、ＭＶＨＤボックス１５６はビデオファイル１５０の一般的な特性を記述し得る。たとえば、ＭＶＨＤボックス１５６は、ビデオファイル１５０が最初に作成されたとき、ビデオファイル１５０が最後に変更されたときを記述するデータ、ビデオファイル１５０についての時間スケール、ビデオファイル１５０についての再生の持続時間、またはビデオファイル１５０を概して記述する他のデータを含み得る。

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

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

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

[0096]ＭＯＯＶボックス１５４は、ビデオファイル１５０中のムービーフラグメント１６４の数に等しいいくつかのＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６４のうちの対応する１つの特性を記述し得る。たとえば、各ＭＶＥＸボックスは、ムービーフラグメント１６４のうちの対応する１つについての持続時間を記述するムービー拡張ヘッダボックス（ＭＥＨＤ）ボックスを含み得る。

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

[0098]ＳＩＤＸボックス１６２は、ビデオファイル１５０の随意の要素である。すなわち、３ＧＰＰファイルフォーマット、または他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもＳＩＤＸボックス１６２を含むとは限らない。３ＧＰＰファイルフォーマットの例によれば、ＳＩＤＸボックスは、セグメント（たとえば、ビデオファイル１５０内に含まれているセグメント）のサブセグメントを識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを、「対応する（１つまたは複数の）メディアデータボックスと、ムービーフラグメントボックスによって参照されるデータを含んでいるメディアデータボックスとをもつ、１つまたは複数の連続するムービーフラグメントボックスの独立型セットは、そのムービーフラグメントボックスに後続し、同じトラックに関する情報を含んでいる次のムービーフラグメントボックスに先行しなければならない」と定義している。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが、「ボックスによってドキュメント化される（サブ）セグメントのサブセグメントへの参照のシーケンスを含んでいる。参照されるサブセグメントはプレゼンテーション時間において隣接する。同様に、セグメントインデックスボックスによって参照されるバイトは常にセグメント内で隣接する。参照されるサイズは、参照される材料中のバイト数のカウントを与える」ことを示している。

[0099]ＳＩＤＸボックス１６２は、概して、ビデオファイル１５０中に含まれるセグメントの１つまたは複数のサブセグメントを表す情報を与える。たとえば、そのような情報は、サブセグメントが開始および／または終了する再生時間、サブセグメントについてのバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（たとえば、それで開始する）かどうか、ＳＡＰのためのタイプ（たとえば、ＳＡＰが瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャであるのか、クリーンランダムアクセス（ＣＲＡ）ピクチャであるのか、切断リンクアクセス（ＢＬＡ）ピクチャであるのかなど）、サブセグメント中の（再生時間および／またはバイトオフセットに関する）ＳＡＰの位置などを含み得る。

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

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

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

[0103]図５は、本開示の技法による、送出機と受信機とを含む例示的なシステムを示す概念図である。図５の送出機は、概して、メディアエンコーダ２００と、ＣＭＡＦ／ファイルフォーマット（ＦＦ）パッケージャ２０２と、ＤＡＳＨパッケージャ２０４と、ＲＯＵＴＥ送出機２０６と、ＣＤＮオリジンサーバ２０８とを含む。メディアエンコーダ２００は、オーディオまたはビデオデータなど、メディアデータを符号化する。メディアエンコーダ２００は、図１のオーディオエンコーダ２６またはビデオエンコーダ２８に対応し得る。ＣＭＡＦ／ＦＦパッケージャ２０２とＤＡＳＨパッケージャ２０４とは、図１のカプセル化ユニット３０に対応し得る。ＲＯＵＴＥ送出機２０６およびＣＤＮオリジンサーバ２０８は、図１の要求処理ユニット７０およびサーバデバイス６０に対応し得る。

[0104]図５の受信機は、概して、ＲＯＵＴＥ受信機２１０と、ＤＡＳＨクライアント２１２と、ＣＭＡＦ／ＦＦパーサ２１４と、メディアデコーダ２１６とを含む。ＲＯＵＴＥ受信機２１０およびＤＡＳＨクライアント２１２は、図１の取出しユニット５２に対応し得る。ＣＭＡＦ／ＦＦパーサ２１４は、図１のカプセル化解除ユニット５０に対応し得る。メディアデコーダ２１６は、オーディオデコーダ４６とビデオデコーダ４８とのいずれかまたは両方に対応し得る。

[0105]メディアエンコーダ２００は、符号化メディアデータをＣＭＡＦ／ＦＦパッケージャ２０２に与え、ＣＭＡＦ／ＦＦパッケージャ２０２は、ＣＭＡＦ、およびＩＳＯ ＢＭＦＦまたはそれの拡張など、特定のファイルフォーマットに従って、符号化メディアデータをファイルにフォーマットする。ＣＭＡＦ／ＦＦパッケージャ２０２は、これらのファイル（たとえば、チャンク）をＤＡＳＨパッケージャ２０４に与え、ＤＡＳＨパッケージャ２０４は、ファイル／チャンクをＤＡＳＨセグメントにアグリゲートする。ＤＡＳＨパッケージャ２０４はまた、ファイル／チャンク／セグメントを記述するデータを含む、ＭＰＤなど、マニフェストファイルを形成し得る。さらに、本開示の技法によれば、ＲＯＴＵＥ送出機２０６および／またはＣＤＮオリジンサーバ２０８は、パケット損失を検出するために、たとえば、ＲＯＵＴＥ受信機２１０および／またはＤＡＳＨクライアント２１２によって使用されるべき１つまたは複数のパケット損失検出機構をシグナリングし得る。

[0106]ＤＡＳＨパッケージャ２０４は、ＭＰＤとともに、セグメントをＲＯＵＴＥ送出機２０６およびＣＤＮオリジンサーバ２０８に与える。ＲＯＵＴＥ送出機２０６およびＣＤＮオリジンサーバ２０８は、図１のサーバデバイス６０または図５のＣＤＮ２２０に対応し得る。概して、ＲＯＵＴＥ送出機２０６は、この例では、ＲＯＵＴＥに従ってＲＯＵＴＥ受信機２１０にメディアデータを送出し得る。他の例では、ＦＬＵＴＥなど、他のファイルベース配信プロトコルが、ブロードキャストまたはマルチキャストのために使用され得る。追加または代替として、ＣＤＮオリジンサーバ２０８は、たとえば、ＨＴＴＰに従って、ＲＯＵＴＥ受信機２１０に、および／またはＤＡＳＨクライアント２１２に直接、メディアデータを送出し得る。

[0107]ＲＯＵＴＥ受信機２１０は、図２のｅＭＢＭＳミドルウェアユニット１００など、ミドルウェア中で実装され得る。ＲＯＵＴＥ受信機２１０は、たとえば、図２に示されているキャッシュ１０４中で、受信されたメディアデータをバッファし得る。（図２のＤＡＳＨクライアント１１０に対応し得る）ＤＡＳＨクライアント２１２は、ＨＴＴＰを使用して、キャッシュされたメディアデータをＲＯＵＴＥ受信機２１０から取り出し得る。代替的に、ＤＡＳＨクライアント２１２は、上記で説明されたように、ＨＴＴＰに従って、ＣＤＮオリジンサーバ２０８からメディアデータを直接取り出し得る。

[0108]さらに、本開示の技法によれば、ＲＯＵＴＥ受信機２１０は、たとえば、パケット損失が、たとえばメディアデータのブロードキャストまたはマルチキャストストリーミングセッション中に発生したと決定するために、１つまたは複数のシグナリングされたパケット損失検出機構を使用し得る。応答して、ＲＯＵＴＥ受信機２１０は、パケット損失が発生したことを示すデータをＤＡＳＨクライアント２１２に与え得る。追加または代替として、ＤＡＳＨクライアント２１２は、シグナリングされたパケット損失検出機構のうちの１つまたは複数を使用して、パケット損失が発生したと決定し得る。いずれの場合も、ＤＡＳＨクライアント２１２は、損失したパケット中に含まれるメディアデータに対応するメディアデータをＣＤＮオリジンサーバ２０８から取り出すために、たとえば、ＨＴＴＰ部分Ｇｅｔ要求を使用して、バイト範囲要求を形成し得る。このようにして、図５の受信機は、概して、ブロードキャストまたはマルチキャストを介してメディアデータを受信し得るが、メディアデータの一部が損失したとき、ＤＡＳＨクライアント２１２は、ユニキャスト、たとえばＨＴＴＰを使用して、損失したメディアデータを取り出し得る。

[0109]本開示は、データがどのように分配されるかに関するプロパティをシグナリングするためのＲＯＵＴＥ送出、ならびにメディアデータが部分的に損失していることがある場合、ＲＯＵＴＥ受信機２１０からＤＡＳＨクライアント２１２へのインターフェースに主に焦点を当てる。

[0110]現在のデジタルビデオブロードキャスティング（ＤＶＢ）適応ビットレート（ＡＢＲ）仕様は、低レイテンシモードでのマルチキャスト配信を可能にするが、上記で説明された従来の機構はこの低レイテンシモードのために調整されず、これは、それらの制限を生じる。これらの制限は、特に低レイテンシストリームの場合、再生の望ましくないストール（stall）を引き起こし得る。

[0111]本開示は、以下で説明されるように、従来の技法に関して生じ得るいくつかの問題を認識している。

[0112]ＤＶＢ ＡＢＲ仕様の節１．３および１．４における機構は、早くとも、受信機側における全配信オブジェクトの公称受信持続時間の後にのみ、損失を検出するために動作し得る。たとえば、２秒の公称セグメント持続時間をもつＤＡＳＨ表現をマルチキャストする場合、この検出は、早くとも、オブジェクトの受信の開始から２秒後に起こることになる。これは、パケットの損失により、著しく長い再生ストールにつながり得る。

[0113]ＤＶＢ ＡＢＲ仕様の節１．２の機構は、後続のパケット（損失したパケットの後に受信されたパケット）の受信の後にのみ動作し得る。そのような受信は、一般に、たとえば、パケット受信が突然および長い時間期間の間停止する不良なチャネル状態の下で、長時間遅延される。この場合の下では、受信機は、節１．３および１．４の機構にデフォルト設定される。

[0114]ＤＶＢ ＡＢＲ仕様の節１．２における機構はまた、順序が狂ったパケット配信に対してロバストでない。

[0115]ＤＶＢ ＡＢＲ仕様の節１．５における機構は、完全オブジェクト受信についてのみ定義され、低レイテンシの場合について定義されない。

[0116]したがって全体的に、ＤＶＢ ＡＢＲ仕様の節１．３によれば、従来の機構を使用して、パケット損失の最も早期の検出は、一般に、公称ＤＡＳＨセグメント持続時間程度のものである時間の後に行われる。

[0117]本開示は、上記で説明された問題に対処し得る技法について説明する。ソースデバイス６０およびクライアントデバイス４０など、送出機および受信機は、以下のように、制御チャネル上でデータをシグナリングし得る。

１． セグメントがチャンクで送出されることを制御チャネル中でシグナリングする。チャンクが送出機において完了されると、送出が開始する。これは、２つのパケットを送出することの間の間隔が、せいぜい、ある持続時間であることを示すために、シグナリングを送出することが抽出され得ること（can be abstracted）を意味する（この信号は、チャンク持続時間が決定されたとき、セットアップにおいて追加され得る）。送出間隔は、せいぜい、チャンク持続時間であり得る。

２． ＴＯＩが連続であることを制御チャネル中でシグナリングする。

３． ＴＯＩに割り当てられたオブジェクトの最後のパケットが、パケットヘッダ中に設定された特定のフラグを有することを、制御チャネル上でシグナリングする。

４． 受信されたＦＬＵＴＥ／ＲＯＵＴＥオブジェクトのＴＯＩに基づいて、同じオブジェクトがＨＴＴＰを通してユニキャストにおいて要求され得るＵＲＬの生成を可能にするテンプレート基本ＵＲＬを、制御チャネル中でシグナリングする。

５． パケットが部分である場合でも、それらがアプリケーションクライアントに与えられるまで、パケットについての最大レイテンシをシグナリングする。

６． ＲＯＵＴＥヘッダ、すなわち、チャンク境界上で、バイト範囲レベルでのＩＳＯ ＢＭＦＦ同期ポイントをシグナリングすること。

[0118]図１のクライアントデバイス４０、ＲＯＵＴＥ受信機２１０、または他の受信機は、以下を行うために、シグナリングされた情報を利用し得る。

１． シグナリング機構のうちの１つまたは複数によって十分に早期に、配信時の１つまたはいくつかのパケットの損失を検出する。

２． ＲＯＵＴＥ／ＦＬＵＴＥヘッダ中の情報、すなわち、ＴＯＩおよびｓｔａｒｔ＿ｏｆｆｓｅｔを使用して、消失したデータについての適切なバイト範囲要求を生成する。

３． 時間内に適切なオブジェクトをアプリケーションクライアント（たとえば、図２のＤＡＳＨクライアント１１０またはメディアアプリケーション１１２）に配信する。

ａ． ゲートウェイは、たとえば、ＨＴＴＰ５０４コードを用いて転送を中断し、ＤＡＳＨプレーヤは、そのようなイベントを扱うように対応させられる。または、
ｂ． 応答は、それが部分である場合でも送出される。部分応答は、正しく受信されたオブジェクトのバイト範囲ならびにバイトストリームレベルでの再同期ポイントを含む。

[0119]アプリケーション（たとえば、図２のメディアアプリケーション１１２）は、時間内に受信されたすべての使用可能情報を使用することによって最良の品質を提示するために、この情報を利用し得る。アプリケーションは、再同期ポイントをもつ部分データを受け付け得る。

[0120]チャンク持続時間シグナリングの詳細は、以下を含み得る。トランスポートパケットの損失の早期検出は、パケット間タイムアウトのシグナリングによって可能にされ得る。そのようなタイムアウトは、トランスポートされているストリームの公称ＣＭＡＦチャンク持続時間に従って設定され得る。シグナリングは、マルチキャストトランスポートパケットヘッダ中で、またはマルチキャストオブジェクトメタデータ（ＦＤＴ／ｅＦＤＴ）中で、あるいは制御プレーン（サービス／セッションメタデータ）中で行われ得る。シグナリングは、最大予想パケット到着ジッタを考慮に入れ得る。シグナリングがこれを考慮に入れない場合、受信機実装形態は、それの経験されるパケット受信ジッタを使用し得る。受信機（たとえば、クライアントデバイス４０）は、上記のパケット間タイムアウトの満了時に、再生が最小限にストールされることを保証するために、ユニキャストを介してデータを要求し得る。受信機は、それが要求する必要があるバイト範囲の開始のみを決定し、それがどのくらいのデータを必要とするかを決定しないので、それは、ＨＴＴＰチャンクモード（HTTP chunked mode）を介してデータを得ることがあり、ここで、それは、適度に大きい量のデータ（たとえば、公称セグメントサイズ）を要求し得、マルチキャスト受信が再開すると受信を取り消すことができる。

[0121]このソリューションは、概して、ＣＭＡＦチャンク持続時間程度の持続時間、たとえば、１００～２００ミリ秒以内のパケット損失の検出を可能にし得、それに対して、現況技術は、そのような検出のために約１～２秒かかり得る。そのような早期検出は、早期修復試行をトリガすることを可能にし、そのような場合にストールの持続時間を最小限に抑え得る。

[0122]いくつかの例では、ＤＡＳＨクライアント２１２は、トランスポートパケット損失を修復するためにバイト範囲要求を行い得る。上記で説明されたパケット損失の検出の後に、ＤＡＳＨクライアント２１２は、ユニキャストバイト範囲要求を形成し得る。消失したデータのバイト範囲決定は、上記で説明された。修復データのアドレスを取り出すための機構は、ｗｗｗ．ｄｖｂ．ｏｒｇ／ｒｅｓｏｕｒｃｅｓ／ｒｅｓｔｒｉｃｔｅｄ／ｍｅｍｂｅｒｓ／ｄｏｃｕｍｅｎｔｓ／ＴＭ－ＩＰＩ／ＡＢＲ％２０Ｍｕｌｔｉｃａｓｔ／ＴＭ－ＩＰＩ３６２６ｒ４＿ＡＢＲ－Ｍｕｌｔｉｃａｓｔ－ｔａｓｋｆｏｒｃｅ－－－Ｕｎｉｃａｓｔ－ｒｅｐａｉｒ－ｄｒａｆｔ－ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｄｏｃｘにおいて入手可能な、ＤＶＢワーキングドラフト 節９、ＴＭ－ＩＰＩ３６２６ｒ４：ＡＢＲマルチキャストタスクフォース－ユニキャスト修復ドラフト仕様においてドキュメント化されている。

[0123]ＤＡＳＨクライアント２１２および／またはＲＯＵＴＥ受信機２１０はまた、パケット修復失敗を扱い得る。最終的に、パケット修復試行が失敗するかまたは時間内に完了されない可能性がある。この場合、マルチキャストゲートウェイは、この問題をＤＡＳＨクライアント２１２にシグナリングし得る。この状況に対処するための２つの可能性がある。

１． ゲートウェイは、たとえばＨＴＴＰ５０４コードを用いて転送を中断し、ＤＡＳＨプレーヤは、そのようなイベントを扱うように対応させられる。

２． 追加または代替として、応答は、上記で説明されたように部分ファイルシグナリング機構を使用してパケットが部分的に受信される場合でも送出される。この機構によれば、アプリケーションは、それのＨＴＴＰ ＧＥＴ要求において部分ファイルを受け付けるそれの能力を示す。部分応答は、正しく受信されたオブジェクトのバイト範囲ならびにバイトストリームレベルでの再同期ポイントを含む。

[0124]ＤＡＳＨクライアント２１２および／またはＲＯＵＴＥ受信機２１０はまた、トランスポートオブジェクト損失を扱い得る。１つまたは複数のトランスポートオブジェクトおよびそれらの関連するメタデータ（たとえば、ＦＤＴ）の完全な損失を扱うための１つの機構は、ユニキャスト接続の利用可能性に依拠することである。マルチキャストゲートウェイは、ＨＴＴＰリバースプロキシとして構成され得、たとえば、損失したオブジェクトに対する要求がプレーヤによって行われたとき、そのオブジェクトをフェッチするために、ユニキャスト接続を使用し得る。ゲートウェイは、ユニキャストを介して同じコンテンツを復元するために、上記で説明されたように、要求されたオブジェクトのＵＲＬと、ユニキャストコンテンツロケーションのシグナリングとを使用し得る。

[0125]図６は、本開示の技法による、例示的な方法を示すフローチャートである。図６の方法は、図１のサーバデバイス６０およびクライアントデバイス４０に関して説明される。図５の送出機デバイスおよび受信機デバイスなど、他のデバイスが、このまたは同様の方法を実施するように構成され得る。

[0126]最初に、サーバデバイス６０は、１つまたは複数のパケット損失検出機構（packet loss detection mechanisms）をシグナリングする（２５０）。これらの機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの１つまたは複数を含み得る。クライアントデバイス４０はまた、パケット損失検出機構を表すシグナリングされたデータを受信し得る（２５２）。

[0127]サーバデバイス６０はまた、ストリーミングプロトコルを介してメディアデータを送出し得る（２５４）。たとえば、サーバデバイス６０は、ＦＬＵＴＥ、ＲＯＵＴＥ、あるいは、ＤＶＢなど、他のネットワークまたはオーバージエア（ＯＴＡ）ブロードキャスト規格を介して、メディアデータを送出し得る。クライアントデバイス４０は、次いで、メディアデータの少なくとも一部を受信し得る（２５６）。クライアントデバイス４０は、さらに、（１つまたは複数の）パケット損失検出機構を使用して、１つまたは複数のパケットが損失したかどうかを決定し得る（２５８）。パケットが損失していない（２５８の「いいえ」分岐）場合、クライアントデバイス４０は、メディアオブジェクト、たとえば、オーディオおよび／またはビデオデータを提示すること（２７２）に進み得る。

[0128]一方、少なくとも１つのパケットが損失した（２５８の「はい」分岐）場合、クライアントデバイス４０は、損失したパケット中に含まれたメディアデータと、セグメントにおけるそのパケットのメディアデータの対応する位置とを決定し得る。たとえば、クライアントデバイス４０は、セグメントにおけるメディアデータの開始バイト位置を決定するために、トランスポートオブジェクト識別子（ＴＯＩ）とｓｔａｒｔ＿ｏｆｆｓｅｔとを使用し得る。クライアントデバイス４０は、たとえば、シグナリングされたチャンク持続時間を使用して、損失したパケットのメディアデータの終了バイト位置をさらに決定し得る。クライアントデバイス４０は、次いで、バイト範囲を指定するＨＴＴＰ部分Ｇｅｔ要求など、損失したパケットの損失したメディアデータについてのバイト範囲要求を形成し得る（２６０）。

[0129]クライアントデバイス４０は、次いで、サーバデバイス６０にバイト範囲要求を送出し得る（２６２）。バイト範囲要求を受信したこと（２６４）に応答して、サーバデバイス６０は、たとえば、ＨＴＴＰなど、ユニキャストプロトコルに従って、要求されたバイト範囲をクライアントデバイス４０に送出し得る（２６６）。クライアントデバイス４０は、次いで、要求されたバイト範囲を受信し（２６８）、適切なメディアオブジェクトを形成し得る（２７０）。クライアントデバイス４０は、さらに、メディアオブジェクトを提示し得る（２７２）。

[0130]このようにして、図６の方法は、パケット損失シグナリング機構を示すデータを受信することと、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットが、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を含む、メディアデータを取り出す方法の一例を表す。

[0131]図６の方法はまた、パケット損失シグナリング機構を示すデータを送出することと、パケット損失シグナリング機構が、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイント、のうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出することと、を含む、メディアデータを送出する方法の一例を表す。

[0132]本開示のいくつかの技法は、以下の例において要約される。

[0133]例１：メディアデータを取り出す方法であって、本方法は、パケット損失シグナリング機構を示すデータを受信することと、データが、セグメントがチャンクで送出されること、ＴＯＩが連続であること、ＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つの指示を備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出することと、損失したパケットが、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成することと；適切なメディアオブジェクトをメディアアプリケーションに配信することと、を備える、方法。

[0134]例２：ファイル配信ヘッダがＲＯＵＴＥヘッダまたはＦＬＵＴＥヘッダを備える、例１に記載の方法。

[0135]例３：ファイル配信ヘッダの情報が、ＴＯＩとｓｔａｒｔ＿ｏｆｆｓｅｔ値とを備える、例１および２のいずれかに記載の方法。

[0136]例４：適切なメディアオブジェクトが、消失したメディアデータの少なくとも一部を消失している部分メディアオブジェクトである、例１～３のいずれかに記載の方法。

[0137]例５：適切なメディアオブジェクトを配信することが、メディアオブジェクトについての予想配信時間までに適切なメディアオブジェクトを配信することを備える、例１～４のいずれかに記載の方法。

[0138]例６：パケットの損失を検出することが、シグナリングされたパケット間タイムアウトを使用してパケットの損失を検出することを備える、例１～５のいずれかに記載の方法。

[0139]例７：パケット間タイムアウトが、公称ＣＭＡＦチャンク持続時間に従ってシグナリングされる、例６に記載の方法。

[0140]例８：マルチキャストトランスポートパケットヘッダ、ファイル配信テーブル（ＦＤＴ）または拡張ＦＤＴ（ＥＦＤＴ）におけるマルチキャストオブジェクトメタデータから、あるいは制御プレーンサービスまたはセッションメタデータ中で、チャンク持続時間を決定することをさらに備える、例６および７のいずれかに記載の方法。

[0141]例９：チャンク持続時間シグナリングが最大予想パケット到着ジッタ考慮するかどうかを決定することをさらに備える、例６～８のいずれかに記載の方法。

[0142]例１０：チャンク持続時間シグナリングが最大予想パケット到着ジッタを考慮しないとき、経験されるパケット受信ジッタに従ってチャンク持続時間シグナリングを決定する、例９に記載の方法。

[0143]例１１：バイト範囲要求を生成することが、パケット間タイムアウトの満了後にバイト範囲要求を生成することを備える、例６～１０のいずれかに記載の方法。

[0144]例１２：ユニキャストプロトコルを介してバイト範囲要求をサブミットすることをさらに備える、例１～１１のいずれかに記載の方法。

[0145]例１３：ユニキャストプロトコルがＨＴＴＰを備える、例１２に記載の方法。

[0146]例１４：メディアデータを取り出すためのデバイスであって、本デバイスが、例１～１３のいずれかに記載の方法を実施するための１つまたは複数の手段を備える、デバイス。

[0147]例１５：１つまたは複数の手段が、回路中に実装された１つまたは複数のプロセッサを備える、例１４に記載のデバイス。

[0148]例１６：本デバイスが、集積回路、マイクロプロセッサ、またはワイヤレス通信デバイスのうちの少なくとも１つを備える、例１４に記載のデバイス。

[0149]例１７：実行されたとき、プロセッサに、例１～１３のいずれかに記載の方法を実施させる命令を記憶したコンピュータ可読記憶媒体。

[0150]例１８：メディアデータを取り出すためのデバイスであって、本デバイスは、パケット損失シグナリング機構を示すデータを受信するための手段と、データが、セグメントがチャンクで送出されること、ＴＯＩが連続であること、ＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つの指示を備え；パケット損失シグナリング機構のうちの少なくとも１つを使用してパケットの損失を検出するための手段と、損失したパケットが、消失したメディアデータを含み；ファイル配信ヘッダの情報を使用して、消失したメディアデータについてのバイト範囲要求を生成するための手段と；適切なメディアオブジェクトをメディアアプリケーションに配信するための手段と、を備える、デバイス。

[0151]例１９：メディアデータを送出する方法であって、本方法は、パケット損失シグナリング機構を示すデータを送出することと、データは、セグメントがチャンクで送出されること、ＴＯＩが連続であること、ＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つの指示を備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと、バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出することとを備える、方法。

[0152]例２０：メディアデータを送出するためのデバイスであって、本デバイスが、例１９に記載の方法を実施するための１つまたは複数の手段を備える、デバイス。

[0153]例２１：本デバイスが、集積回路、マイクロプロセッサ、またはワイヤレス通信デバイスのうちの少なくとも１つを備える、例２０に記載のデバイス。

[0154]例２２：実行されたとき、プロセッサに、例１９に記載の方法を実施させる命令を記憶したコンピュータ可読記憶媒体。

[0155]例２３：メディアデータを送出するためのデバイスであって、本デバイスは、パケット損失シグナリング機構を示すデータを送出するための手段と、データは、セグメントがチャンクで送出されること、ＴＯＩが連続であること、ＴＯＩに割り当てられたオブジェクトの最後のパケットが、最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え；ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出するための手段と；損失したパケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信するための手段と；バイト範囲要求に応答して、ユニキャストプロトコルを介してクライアントデバイスにバイト範囲のメディアデータを送出するための手段と、を備えるデバイス。

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

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

[0158]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路など、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、上記の構造、または、本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素で十分に実装され得る。

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

[0160]様々な例が説明された。これらおよび他の例は以下の特許請求の範囲内に入る。

Claims (41)

1. メディアデータを取り出す方法であって、
   パケット損失シグナリング機構を示すデータを受信することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中に設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
   前記パケット損失シグナリング機構のうちの前記少なくとも１つを使用してパケットの損失を検出することと、前記損失したパケットは、消失したメディアデータを含み、
   前記ファイル配信ヘッダの情報を使用して、前記消失したメディアデータについてのバイト範囲要求を生成することと、
   適切なメディアオブジェクトをメディアアプリケーションに配信することと、
   を備える、方法。
2. 前記パケットの前記損失を検出することは、シグナリングされたパケット間タイムアウト値を使用して前記パケットの前記損失を検出することを備える、請求項１に記載の方法。
3. 前記パケット間タイムアウト値は、公称共通メディアアプリケーションフォーマット（ＣＭＡＦ）チャンク持続時間に従ってシグナリングされる、請求項２に記載の方法。
4. マルチキャストトランスポートパケットヘッダ、ファイル配信テーブル（ＦＤＴ）または拡張ＦＤＴ（ＥＦＤＴ）におけるマルチキャストオブジェクトメタデータから、あるいは制御プレーンサービスまたはセッションメタデータ中で、チャンク持続時間を決定することをさらに備える、請求項２に記載の方法。
5. チャンク持続時間シグナリングが最大予想パケット到着ジッタを考慮するかどうかを決定することをさらに備える、請求項２に記載の方法。
6. 前記チャンク持続時間シグナリングが前記最大予想パケット到着ジッタを考慮しないとき、経験されるパケット受信ジッタに従って前記チャンク持続時間シグナリングを決定する、請求項５に記載の方法。
7. 前記バイト範囲要求を生成することは、前記パケット間タイムアウト値の満了後に前記バイト範囲要求を生成することを備える、請求項６に記載の方法。
8. 前記ファイル配信ヘッダはＲＯＵＴＥヘッダまたはＦＬＵＴＥヘッダを備える、請求項１に記載の方法。
9. 前記ファイル配信ヘッダの前記情報は、ＴＯＩとｓｔａｒｔ＿ｏｆｆｓｅｔ値とを備える、請求項１に記載の方法。
10. 前記適切なメディアオブジェクトは、前記消失したメディアデータの少なくとも一部を消失している部分メディアオブジェクトである、請求項１に記載の方法。
11. 前記適切なメディアオブジェクトを配信することは、前記メディアオブジェクトについての予想配信時間までに前記適切なメディアオブジェクトを配信することを備える、請求項１に記載の方法。
12. ユニキャストプロトコルを介して前記バイト範囲要求をサブミットすることをさらに備える、請求項１に記載の方法。
13. 前記ユニキャストプロトコルがＨＴＴＰを備える、請求項１２に記載の方法。
14. メディアデータを取り出すためのデバイスであって、前記デバイスが、
    メディアデータを記憶するように構成されたメモリと、
    回路中に実装された１つまたは複数のプロセッサと、を備え、前記１つまたは複数のプロセッサは、
    パケット損失シグナリング機構を示すデータを受信することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    前記パケット損失シグナリング機構のうちの前記少なくとも１つを使用してパケットの損失を検出することと、前記損失したパケットは、消失したメディアデータを含み、
    前記ファイル配信ヘッダの情報を使用して、前記消失したメディアデータについてのバイト範囲要求を生成することと、
    適切なメディアオブジェクトをメディアアプリケーションに配信することと、
    を行うように構成された、デバイス。
15. 前記１つまたは複数のプロセッサは、シグナリングされたパケット間タイムアウト値を使用して前記パケットの前記損失を検出するように構成された、請求項１４に記載のデバイス。
16. 前記パケット間タイムアウト値は、公称共通メディアアプリケーションフォーマット（ＣＭＡＦ）チャンク持続時間に従ってシグナリングされる、請求項１５に記載のデバイス。
17. 前記１つまたは複数のプロセッサは、マルチキャストトランスポートパケットヘッダ、ファイル配信テーブル（ＦＤＴ）または拡張ＦＤＴ（ＥＦＤＴ）におけるマルチキャストオブジェクトメタデータから、あるいは制御プレーンサービスまたはセッションメタデータ中で、チャンク持続時間を決定するようにさらに構成された、請求項１５に記載のデバイス。
18. 前記１つまたは複数のプロセッサは、チャンク持続時間シグナリングが最大予想パケット到着ジッタを考慮するかどうかを決定するようにさらに構成された、請求項１５に記載のデバイス。
19. 前記ファイル配信ヘッダはＲＯＵＴＥヘッダまたはＦＬＵＴＥヘッダを備える、請求項１４に記載のデバイス。
20. 前記ファイル配信ヘッダの前記情報は、ＴＯＩとｓｔａｒｔ＿ｏｆｆｓｅｔ値とを備える、請求項１４に記載のデバイス。
21. 前記１つまたは複数のプロセッサは、ユニキャストプロトコルを介して前記バイト範囲要求をサブミットするようにさらに構成された、請求項１４に記載のデバイス。
22. 前記デバイスは、
    集積回路、
    マイクロプロセッサ、または
    ワイヤレス通信デバイス、
    のうちの少なくとも１つを備える、請求項１４に記載のデバイス。
23. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
    パケット損失シグナリング機構を示すデータを受信することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    前記パケット損失シグナリング機構のうちの前記少なくとも１つを使用してパケットの損失を検出することと、前記損失したパケットが、消失したメディアデータを含み、
    前記ファイル配信ヘッダの情報を使用して、前記消失したメディアデータについてのバイト範囲要求を生成することと、
    適切なメディアオブジェクトをメディアアプリケーションに配信することと、
    を行わせる、コンピュータ可読記憶媒体。
24. メディアデータを取り出すためのデバイスであって、
    パケット損失シグナリング機構を示すデータを受信するための手段と、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    前記パケット損失シグナリング機構のうちの前記少なくとも１つを使用してパケットの損失を検出するための手段と、前記損失したパケットは、消失したメディアデータを含み、
    前記ファイル配信ヘッダの情報を使用して、前記消失したメディアデータについてのバイト範囲要求を生成するための手段と、
    適切なメディアオブジェクトをメディアアプリケーションに配信するための手段と、
    を備える、デバイス。
25. メディアデータを送出する方法であって、
    パケット損失シグナリング機構を示すデータを送出することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと、
    損失した前記パケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと、
    前記バイト範囲要求に応答して、前記ユニキャストプロトコルを介して前記クライアントデバイスに前記バイト範囲の前記メディアデータを送出することと、
    を備える、方法。
26. パケット損失シグナリング方法を示す前記データを送出することは、パケット間タイムアウト値を表すデータを送出することをさらに備える、請求項２５に記載の方法。
27. 前記パケット間タイムアウト値を表す前記データを送出することは、公称共通メディアアプリケーションフォーマット（ＣＭＡＦ）チャンク持続時間に従って前記パケット間タイムアウト値をシグナリングすることを備える、請求項２６に記載の方法。
28. マルチキャストトランスポートパケットヘッダ、ファイル配信テーブル（ＦＤＴ）または拡張ＦＤＴ（ＥＦＤＴ）におけるマルチキャストオブジェクトメタデータ中で、あるいは制御プレーンサービスまたはセッションメタデータ中で、チャンク持続時間を表すデータをシグナリングすることをさらに備える、請求項２６に記載の方法。
29. 前記ファイル配信ヘッダはＲＯＵＴＥヘッダまたはＦＬＵＴＥヘッダを備える、請求項２５に記載の方法。
30. 前記ファイル配信ヘッダの前記情報は、ＴＯＩとｓｔａｒｔ＿ｏｆｆｓｅｔ値とを備える、請求項２５に記載の方法。
31. 前記ユニキャストプロトコルはＨＴＴＰを備える、請求項２５に記載の方法。
32. メディアデータを送出するためのデバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    回路中に実装された１つまたは複数のプロセッサと、を備え、前記１つまたは複数のプロセッサは、
    パケット損失シグナリング機構を示すデータを送出することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと、
    損失した前記パケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと、
    前記バイト範囲要求に応答して、前記ユニキャストプロトコルを介して前記クライアントデバイスに前記バイト範囲の前記メディアデータを送出することと、
    を行うように構成された、デバイス。
33. 前記１つまたは複数のプロセッサは、パケット間タイムアウト値を表すデータを送出するようにさらに構成された、請求項３２に記載のデバイス。
34. 前記１つまたは複数のプロセッサは、公称共通メディアアプリケーションフォーマット（ＣＭＡＦ）チャンク持続時間に従って前記パケット間タイムアウト値をシグナリングするように構成された、請求項３３に記載のデバイス。
35. 前記１つまたは複数のプロセッサは、マルチキャストトランスポートパケットヘッダ、ファイル配信テーブル（ＦＤＴ）または拡張ＦＤＴ（ＥＦＤＴ）におけるマルチキャストオブジェクトメタデータ中で、あるいは制御プレーンサービスまたはセッションメタデータ中で、チャンク持続時間を表すデータをシグナリングするようにさらに構成された、請求項３３に記載のデバイス。
36. 前記ファイル配信ヘッダはＲＯＵＴＥヘッダまたはＦＬＵＴＥヘッダを備える、請求項３２に記載のデバイス。
37. 前記ファイル配信ヘッダの前記情報は、ＴＯＩとｓｔａｒｔ＿ｏｆｆｓｅｔ値とを備える、請求項３２に記載のデバイス。
38. 前記ユニキャストプロトコルはＨＴＴＰを備える、請求項３２に記載のデバイス。
39. 前記デバイスは、
    集積回路、
    マイクロプロセッサ、または
    ワイヤレス通信デバイス、
    のうちの少なくとも１つを備える、請求項３２に記載のデバイス。
40. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
    パケット損失シグナリング機構を示すデータを送出することと、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出することと、
    損失した前記パケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信することと、
    前記バイト範囲要求に応答して、前記ユニキャストプロトコルを介して前記クライアントデバイスに前記バイト範囲の前記メディアデータを送出することと、
    を行わせる、コンピュータ可読記憶媒体。
41. メディアデータを送出するためのデバイスであって、
    パケット損失シグナリング機構を示すデータを送出するための手段と、前記パケット損失シグナリング機構は、セグメントがチャンクで送出されること、トランスポートオブジェクト識別子（ＴＯＩ）が連続であること、またはＴＯＩに割り当てられたオブジェクトの最後のパケットが、前記最後のパケットのヘッダ中で設定された特定のフラグを有すること、基本ＵＲＬ、最大レイテンシ、またはファイル配信ヘッダ中の同期ポイントのうちの少なくとも１つを備え、
    ブロードキャストまたはマルチキャストプロトコルを介してメディアデータを含む１つまたは複数のパケットを送出するための手段と、
    損失した前記パケットのうちの１つのメディアデータを示すバイト範囲要求を、ユニキャストプロトコルを介してクライアントデバイスから受信するための手段と、
    前記バイト範囲要求に応答して、前記ユニキャストプロトコルを介して前記クライアントデバイスに前記バイト範囲の前記メディアデータを送出するための手段と、
    を備える、デバイス。

Images