JP6316781B2 - バイト範囲リクエストを使用したビデオデータのネットワークストリーミング - Google Patents

バイト範囲リクエストを使用したビデオデータのネットワークストリーミング Download PDF

Info

Publication number
JP6316781B2
JP6316781B2 JP2015160180A JP2015160180A JP6316781B2 JP 6316781 B2 JP6316781 B2 JP 6316781B2 JP 2015160180 A JP2015160180 A JP 2015160180A JP 2015160180 A JP2015160180 A JP 2015160180A JP 6316781 B2 JP6316781 B2 JP 6316781B2
Authority
JP
Japan
Prior art keywords
request
url
byte range
representation
byte
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015160180A
Other languages
English (en)
Other versions
JP2016028474A (ja
Inventor
トーマス・シュトックハマー
ドナルド・ダブリュ．・ギリーズ
マイケル・ジー．・ルビー
ファティ・ウルピナー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2016028474A publication Critical patent/JP2016028474A/ja
Application granted granted Critical
Publication of JP6316781B2 publication Critical patent/JP6316781B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

優先権の主張
本出願は、その全体が参照により本明細書に組み込まれる、２０１１年４月７日に出願された米国仮出願第６１／４７３，１０５号の利益を主張する。
本開示は、符号化されたマルチメディアデータの記憶およびトランスポートに関する。
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３またはＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。
[0004]ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット、ならびにＭＰ４ファイルフォーマットおよびＡｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）ファイルフォーマットなどのそれの拡張など、様々な規格のいずれかに準拠するビデオファイルにアセンブルされ得る。そのようなパケット化されたビデオデータは、ネットワークストリーミングを使用したコンピュータネットワークを介した送信など、様々な方法でトランスポートされ得る。
[0005]２０００年代半ばに、リアルタイムトランスポートプロトコル（ＲＴＰ）を介したインターネット経由のビデオおよびオーディオトラフィックの増大により、インターネットは大量のネットワークトラフィックで一杯になり始めたが、これらのプロトコルに対する輻輳制御がなかった。これを受けて、企業の情報技術（ＩＴ）管理者は、企業のゲートウェイを詰まらせていたビデオおよびオーディオストリームを含むＲＴＰパケットをブロックするために、自社のファイアウォールをプログラムした。
[0006]ファイアウォールは、ビデオおよびオーディオストリーミングサービスの存在を脅かした。そのため、サービスプロバイダは、ＴＣＰ（より具体的には、ＴＣＰのＨＴＴＰポート）仮想回路を介してコンテンツを提供し始めた。サービスプロバイダはこれを、自社のビデオおよびオーディオトラフィックを有用なＨＴＴＰトラフィックと見せかけるために行った。ＩＴファイアウォール管理者はＨＴＴＰ／ＴＣＰを介したビデオおよびオーディオを容易にブロックすることができなかったため、しばらくの間、ＴＣＰを介したＨＴＴＰ経由のビデオおよびオーディオが隆盛をきわめた。
[0007]最初は、たいていのビデオのダウンロードに「プログレッシブダウンロード」方法が使用された。この機構では、ビデオファイル全体をダウンロードするために、単一のＨＴＴＰ接続および転送が使用される。ユーザは、ダウンロードが発生するのを見て、全ストリーム視聴体験をサポートするのに十分なデータがバッファリングされていると感じたとき、「ＰＬＡＹ」ボタンを押し、ビデオを表示し始める。擬似ストリーミング体験をもたらす十分なデータがダウンロードされると、プレーヤはプレイアウトを自動的に開始することがある。しかしながら、ユーザがビデオをすぐに、特に低容量リンクで見たいと思ったとき、この方法は問題に直面した。別の問題として、変化するワイヤレス環境では、適応ダウンロードが突然、緩慢なペースにシフトダウンして、ビデオの途中で失速することがある。
[0008]２００５年以降、これらの問題に対処しようとする、適応ストリーミングオーバーＨＴＴＰ（Adaptive Streaming over HTTP）を実現するための作業が進行している。適応ストリーミングプロトコルの例には、Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＭＳＳ）、Ａｐｐｌｅ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＡＬＳ）、Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＡＨＤＳ）、および３ＧＰＰ Ｓｔａｎｄａｒｄ、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）がある。 ２０１１年には、（ＭＳＳに基づく）Ｎｅｔｆｌｉｘビデオストリーミングサービスが、夕方のピーク時間に北米のインターネットバックホールの３０％を消費して、顧客の自宅にビデオパケットを配信した。
[0009]適応ストリーミング方法は、ＨＴＭＬウェブページによく似た形でビデオを編成する。たとえば、ＤＡＳＨでは、ビデオを構成する「フラグメント」（サブファイルであり、サブセグメントとも呼ばれる）のすべてを参照するように「ビデオウェブベージ」が定義される。フラグメントは、一般に、リアルタイムビデオまたはオーディオの２秒であり、一般に、ビデオの場合にはＭＰＥＧ Ｉフレーム（本質的に完全なＪＰＥＧ符号化ピクチャ）で始まる。Ｈ．２６４／ＡＶＣでは、そのようなフレームは瞬間デコーダリフレッシュ（ＩＤＲ）フレームと呼ばれる。ＤＡＳＨでは、「ビデオウェブベージ」はメディアプレゼンテーション記述（ＭＰＤ）と呼ばれる。２時間ビデオのＭＰＤは、３６００個のビデオユニフォームリソースロケータ（ＵＲＬ）と３６００個のオーディオＵＲＬとを参照する可能性があり、これらの各々は再生時のメディアの２秒に対応し得る。なお、ビデオが符号化される際のビットレートごとに３６００個のビデオＵＲＬが提供され得ることに留意されたい。
[0010]ＤＡＳＨの１つの改善点として、いくつかの異なるビットレートで同じビデオが記述可能であり、プレーヤはビットレートを（たとえば、２秒ごとに）切り替えることができる。ＭＰＤは概して、表現と呼ばれる、同じビデオの３〜８個の異なるレンダリングを記述する。インターネットが輻輳しているとき、または端末が低容量リンク上にあるとき、低ビットレートフラグメントがフェッチされ得る。インターネットが輻輳してないとき、または端末が高容量リンクを有するとき、高ビットレートフラグメントがフェッチされ得る。一般に、オーディオの場合は単一のオーディオストリームがフェッチされ、ビットレート切替えは生じない。ネットワークまたはリンクの状態が変化したときには、プレーヤはより高いビットレートまたはより低いビットレートでビデオフラグメントをフェッチすることによって適応し得る。プレーヤは一般に、フラグメントの境界で適応する。それによって、プレーヤは、インターネット上の変化する輻輳状態に動的に適応し、ＨＴＴＰを介してオーディオデータとビデオデータの両方をトランスポートすることができる。８個の異なる表現が提供される場合、全部で３６００×８＝２８，８００個のフラグメントがオリジンサーバ上で管理され得ることに留意されたい。
[0011]ＨＴＴＰ ０．９は１９９３年に導入された後、非常に成功したので、インターネットはすぐにＨＴＴＰリクエストで一杯になった。そして１９９７年に、キャッシングを含め、ＲＦＣ２０６８においてＨＴＴＰ１．０が規格化された。ブラウザがオブジェクトをキャッシュし始めただけではなく、研究者も、ＨＴＴＰ１．０における新しいキャッシング特徴を利用するために透過的なＨＴＴＰ Ｐｒｏｘｙ Ｃａｃｈｅデバイスを作り始めた。プロキシキャッシュデバイスはＨＴＴＰ ＧＥＴリクエストを見つけ、概してリクエストを変更せずに転送する。プロキシキャッシュが、ｊｐｅｇピクチャまたは２０分間有効な株価情報などの（コンテンツが長い寿命を有し、キャッシュされ得ることを意味する）約５個のＨＴＴＰ「キャッシング」ヘッダのうちの１つを有するＨＴＴＰ応答に気付いたとき、プロキシキャッシュデバイスはキャッシュ可能な応答を記憶し、同じユーザまたは異なるユーザが後にそのコンテンツをリクエストしたときに、それを再生することができる。ネットワーク管理者は、プロキシキャッシュを通じてすべてのＨＴＴＰトラフィックをルーティングするようにスイッチまたはルータを再プログラムすることができる。
[0012]さらに、（ＲＦＣ２６１６に指定されている）ＨＴＴＰ１．１は、部分ＧＥＴリクエストを規定している。部分ＧＥＴリクエストは、ターゲットＵＲＬを指定する情報のほか、「Ｒａｎｇｅ：」ヘッダと、それに続く、所望のバイト範囲を示す値とを含む。ＨＴＴＰ１．１による規定にもかかわらず、すべてのウェブブラウザが部分ＧＥＴリクエストの使用を実施するとは限らない。その上、ウェブブラウザ（またはクライアントデバイスによって実行される他のアプリケーション）が部分ＧＥＴリクエストを実施するときでも、プロキシサーバ、プロキシキャッシュデバイス、または他のプロキシデバイスなどの中間ネットワークデバイスは、クライアントデバイスによってリクエストされた部分だけではなく、ファイル全体を取り出すように構成されていることが多い。
[0013]プロキシデバイスは通常、ウイルスもしくは他の悪意のあるネットワークトラフィックを検出するためのディープパケット検査、（同じデータについての他のリクエストに応答するための）キャッシング、またはファイル全体の取出しを必要とする他の機能などの、ネットワークトラフィックに対する追加のアクションを実行するように構成される。したがって、そのようなプロキシデバイスは、範囲リクエストを剥ぎ取り、指定されたＵＲＬにおけるファイル全体を取り出し、それによって、取り出されたファイル全体をリクエスト元クライアントデバイスに提供する傾向がある。たとえば、いくつかのウイルススキャニングアルゴリズムは、ファイル全体のスキャニングを必要とし、その場合、ファイル全体をダウンロードする必要がある。しかしながら、（２時間ムービーなどの）比較的大きいマルチメディアファイルの場合、リクエストされたバイト範囲の代わりにファイル全体を取り出すことにより、リクエスト元クライアントデバイスに比較的小さいバイト範囲を送信する際に相当な遅延が生じ得る。
[0014]概して、本開示は、ネットワークを介してメディアデータをストリーミングするためのバイト範囲リクエストをサブミット（submit）することに関する技法について説明する。本開示の技法は、部分ＧＥＴリクエストを使用してバイト範囲リクエストをサブミットするのではなく、ＨＴＴＰ ＧＥＴリクエストのＵＲＬにリクエストされるバイト範囲を指定することを対象とする。このようにして、バイト範囲リクエストが「Ｒａｎｇｅ：」ヘッダを指定する必要はなくなり、それによって、中間プロキシキャッシュデバイスによる望ましくない行動が回避される。すなわち、部分ＧＥＴリクエストを受信したことに応答して、ファイル全体を取り出すように構成されたプロキシキャッシュデバイスは、リクエストされたＵＲＬの部分データを取り出すだけであるはずだ。リクエストされたＵＲＬがバイト範囲を指定している場合、取り出されたデータは、ベースＵＲＬにおけるファイル全体よりもはるかに小さくなるべきである。
[0015]一例では、マルチメディアデータを取り出す方法は、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスへの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出すこととを含む。
[0016]別の例では、マルチメディアデータについての情報を取り出すためのデバイスは、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスへの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出すこととを行うように構成された１つまたは複数のプロセッサを含む。
[0017]別の例では、マルチメディアデータについての情報を取り出すためのデバイスは、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定する手段と、ソースデバイスへの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成する手段と、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出す手段とを含む。
[0018]別の例では、コンピュータプログラム製品は、実行されたときに、マルチメディアデータを取り出すためのデバイスのプロセッサに、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスへの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出すことと、を行わせる命令を備えるコンピュータ可読記憶媒体を含む。
[0019]別の例では、ビデオデータについての情報を送る方法は、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬはマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を含む。
[0020]別の例では、ビデオデータについての情報を送るためのデバイスは、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬはマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を行うように構成された１つまたは複数のプロセッサを備える。
[0021]別の例では、ビデオデータについての情報を送るためのデバイスは、マルチメディアコンテンツのマニフェストファイルを提供する手段と、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信する手段と、リクエストのＵＲＬがマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力する手段と、を含む。
[0022]別の例では、コンピュータプログラム製品は、ビデオデータを提供するためのデバイスのプロセッサに、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬがマルチメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を行わせる命令を備えるコンピュータ可読記憶媒体を含む。
[0023]１つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図。 図１のネットワークの一部を形成するデバイスの例示的なセットを示すブロック図。 様々なコンテンツ配信ネットワーク（ＣＤＮ）を含む例示的なシステムを示すブロック図。 例示的なマルチメディアコンテンツの要素を示す概念図。 マルチメディアコンテンツの表現のセグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図。 ＵＲＬテンプレートデータの指示を提供するための、またクライアントデバイスによってＵＲＬテンプレートデータを使用してバイト範囲リクエストを生成するための例示的な方法を示すフローチャート。 ＵＲＬにバイト範囲を指定するＧＥＴリクエストを生成するための例示的な方法を示すフローチャート。 中間ネットワークデバイスを介してクライアントデバイスとサーバデバイスとの間でＨＴＴＰ ＧＥＴリクエストが交換される例示的な方法を示すフローチャート。 マルチメディアコンテンツのデータの取出し元となるＣＤＮを決定するための例示的な方法を示すフローチャート。
[0033]概して、本開示では、ネットワークを介したオーディオおよびビデオデータなどのマルチメディアデータのストリーミングに関する技法について説明する。本開示の技法は、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：dynamic adaptive streaming over HTTP）と併せて使用され得る。本開示では、ネットワークストリーミングと併せて実行され得る様々な技法について説明し、それらの技法のいずれかまたはすべては単独でまたは任意の組合せで実装され得る。以下でより詳細に説明するように、ネットワークストリーミングを実行する様々なデバイスが本開示の技法を実装するように構成され得る。
[0034]ＤＡＳＨおよびネットワークを介してデータをストリーミングするための同様の技法によれば、（オーディオデータ、ビデオデータ、テキストオーバーレイ、または他のデータをも含み得る、ムービーまたは他のメディアコンテンツなどの）マルチメディアコンテンツは様々な方法で様々な特性を用いて符号化され得る。コンテンツ作成（preparation）デバイスは、同じマルチメディアコンテンツの複数の表現(representation)を形成し得る。各表現は、様々なコーディングおよびレンダリング能力をもつ多種多様なクライアントデバイスによって使用可能なデータを与えるために、コーディングおよびレンダリング特性など、特性の特定のセットに対応し得る。その上、様々なビットレートを有する表現によって帯域幅適応が可能になり得る。すなわち、クライアントデバイスは、現在利用可能である帯域幅の量を決定し、クライアントデバイスのコーディングおよびレンダリング能力とともにその利用可能な帯域幅の量に基づいて表現を選択し得る。
[0035]いくつかの例では、コンテンツ作成デバイスは、ある表現セットが共通の特性のセットを有することを示し得る。コンテンツ作成デバイスは、その場合、セット中の表現が帯域幅適応のために使用され得るように、セット中の表現が適応セットとも呼ばれる適応セットを形成することを示し得る。すなわち、セット中の表現は、ビットレートが異なるが、それ以外は実質的に同じ特性を共有し得る。このようにして、クライアントデバイスは、マルチメディアコンテンツの適応セットについての共通の特性の様々なセットを決定し、クライアントデバイスのコーディングおよびレンダリング能力に基づいて適応セットを選択し得る。次いで、クライアントデバイスは、帯域幅利用可能性に基づいて、選択された適応セット中の表現の間で適応的に切り替わり得る。
[0036]表現についてのデータは、個別のファイルに分離され得る。ファイルの各々は、特定のユニフォームリソースロケータ（ＵＲＬ）によってアドレス指定可能であり得る。クライアントデバイスは、特定のＵＲＬにおけるファイルについてのＧＥＴリクエストを、そのファイルを取り出すためにサブミットすることができる。本開示の技法によれば、クライアントデバイスは、たとえば、対応するサーバデバイスによって提供されたＵＲＬテンプレートに従って、ＵＲＬパス自体に所望のバイト範囲の指示を含めることによって、ＧＥＴリクエストを変更することができる。本開示では、「パス」という用語は、ＨＴＴＰ ａｂｓ＿ｐａｔｈ［ＲＦＣ２６１６］またはＨＴＴＰ ｒｅｌ＿ｐａｔｈ［ＲＦＣ２６１６］［ＲＦＣ２３９６］のいずれかを示し得ることに留意されたい。バイト範囲はサーバデバイスに対し、示されたバイト範囲のみが望ましいことを示す。
[0037]このようにして、本開示の技法は、従来型の部分ＧＥＴリクエストを置き換えることと、あるいは、ＵＲＬ内に、たとえばＵＲＬパス自体に所望のバイト範囲を指定することとを含む。たとえば、表現のＵＲＬアドレス指定可能なファイルの特定のバイト範囲が望ましいと決定すると、クライアントデバイスは、本開示の技法に従ってＵＲＬパス内に所望のバイト範囲を指定することによって、ＵＲＬについてのＧＥＴリクエストを構成することができる。マニフェストファイルクリエータは、このようにしてＵＲＬを構成するためのテンプレートを提供するとともに、テンプレートが必須であるか、それともオプションであるかに関する情報を提供することができる。さらに、プロキシデバイスまたは他の中間ネットワークデバイスが、本開示の技法に従って、受信された部分ＧＥＴリクエストを変更ＵＲＬに変換するように構成され得る。このようにして、部分ＧＥＴリクエストを認識するように構成されたプロキシデバイスが、本開示の技法に従って部分ＧＥＴリクエストを変換して、アップストリームプロキシデバイスが部分ＧＥＴリクエストを完全ＧＥＴリクエストに変更するのを回避することができる。さらに、サーバデバイスは、本開示の技法に従って、部分ＧＥＴリクエストだけに応答するのではなく、変更ＵＲＬにも応答し、ファイルのバイト範囲を指定するような変更ＵＲＬを構成する方法を指定するように構成され得る。
[0038]本開示はまた、いくつかの例では、ＵＲＬ内に明示的に指定されたバイト範囲に関係するメディアコンテンツの特性をシグナリングするための技法を提供する。本開示は、「ＭｕｓｔＵｓｅＲａｎｇｅＵＲＬ」とラべリングされたＭＰＤファイルの部分を形成する列挙された属性を提供する。属性に対応するフィールドの値は、クライアントデバイスがＵＲＬ自体に所望のバイト範囲を指定することができる（または指定しなければならない）かどうかを示す。本開示はまた、「ＡｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓ」とラべリングされたＭＰＤファイルの部分を形成する列挙された属性を提供する。リクエスト可能なバイト範囲が、ＭＰＤファイル内、表現のセグメントインデックス（ＳＩＤＸ）ボックス内に指定されてよく、または指定されなくてもよい。ＡｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓ属性は、クライアントデバイスがＭＰＤファイル、ＳＩＤＸボックス、またはマルチメディアコンテンツの他のデータ構造によって指定されたバイト範囲をリクエストし得るかどうかを示す指示を提供する。
[0039]本開示は、バイト範囲がどのように指定されるかを示すＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅフィールドをさらに提供する。ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅフィールドは、＄ＵＲＬ＄フィールドと、＄ＳｔａｒｔＢｙｔｅ＄フィールドと、＄ＥｎｄＢｙｔｅ＄フィールドとを含むことができ、これらは、同じくバイト範囲を指定する適切に形成された変更ＵＲＬに従って順序付けられ得る。ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅフィールドは、フォワードスラッシュもしくはピリオドまたは他のＡＳＣＩＩシンボルなどの追加の文字をさらに指定することができる。本開示の技法に従って、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅを使用して、クライアントデバイス（またはプロキシデバイス）は（「Ｒａｎｇｅ：」フィールドを含む）部分ＧＥＴリクエストを、「Ｒａｎｇｅ：」フィールドを使用せずにバイト範囲を指定する変更ＵＲＬに変換することができる。
[0040]たとえば、ウェブサーバが、バイト範囲を使用して、または、範囲がＵＲＬに埋め込まれている範囲リクエストにサービングすることによって、マルチメディアコンテンツ（たとえば、ムービー「トロン」）を提供すると仮定する。この例では、ウェブサーバはｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍである。ウェブサーバは、マルチメディアコンテンツ「トロン」についてＭＰＤ（またはマニフェストファイル）において以下の指示を提供することができる。
Figure 0006316781
[0041]この例では、ＭＰＤファイルは、バイト範囲テンプレート（ByteRangeTemplate）がＵＲＬ、続いてスラッシュおよび所望のバイト範囲における開始バイト（StartByte）、続いて別のスラッシュおよび所望のバイト範囲における終了バイト（EndByte）であることを示している。ＭｕｓｔＵｓｅＲａｎｇｅＵＲＬは、バイト範囲テンプレートがオプションであることを示しており、これは、範囲リクエストを含む変更ＵＲＬおよびＨＴＴＰ１．１部分ＧＥＴリクエストにサーバが応答することを意味し、ＡｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓフィールドは、ＭＰＤに明示的に示されたバイト範囲のみが指定を許容されていることを示している。
[0042]この例を続けると、従来型のＵＲＬおよびバイト範囲は、以下の部分ｇｅｔリクエストとしてＨＴＴＰ１．１に従って表され得る。
Figure 0006316781
[0043]本開示の技法によるクライアントデバイス（またはプロキシデバイス）は、上記の部分ＧＥＴリクエストを変更して、以下の変更ＵＲＬを形成することができる。
Figure 0006316781
[0044]概して、クライアントデバイスは、従来型の部分ＧＥＴリクエストを生成するのではなく、この例示的なリクエストを生成することができる。この例では、ＵＲＬは、（例として、マルチメディアコンテンツのＭＰＤに指定されるはずの）所望のバイト範囲を明示的に指定する。
[0045]本開示はまた、ＵＲＬがバイト範囲を含むことを示すＨＴＴＰ用の拡張ヘッダの使用を提案する。これにより、プロキシデバイスは、ＵＲＬがバイト範囲をいつ含めるかを決定することができ、その結果、プロキシデバイスは、リクエストを提供したクライアントデバイスのためにマルチメディアコンテンツのデータをプリフェッチすることができる。
[0046]本開示はまた、コンテンツ配信ネットワーク（ＣＤＮ）またはコンテンツサーバファームを選択するための技法を提供する。いくつかの例では、クライアントデバイスは、ＢａｓｅＵＲＬリクエストの本文に含まれる、リダイレクションＵＲＬへのＰＯＳＴリクエストを出すことができる。リダイレクションサーバデバイスは、ＰＯＳＴを受信し、たとえば、リクエスト元クライアントデバイスの特性、たとえば、クライアントデバイスのロケーションブラウザタイプ、ネットワーク配置、または後述する他の選択基準に基づいて、選択されたＣＤＮに対し、ＢａｓｅＵＲＬに対応するファイルについてのリクエストを出すことができる。他の例では、時刻、往復遅延、ホップカウント、ロケーションなど、選択基準は複数のＣＤＮによって指定され得る。クライアントデバイスは、これらの基準を使用してＣＤＮを選択することができる。選択は、基準に基づいてランダムに、または選択基準に対応するネットワーク特性を測定することによって行われてよく、これらの基準を使用してＣＤＮを確定的に選択し得る。
[0047]概して、本開示の技法を使用して、特にマルチメディアコンテンツの部分（たとえば、フラグメントまたはサブセグメント）をリクエストすることに関して、マルチメディアデータのストリーミングに関係する１つまたは複数の問題を克服することができる。これらの問題は、すべてのブラウザがバイト範囲リクエストを実施するとは限らないことを含む。バイト範囲はＵＲＬ仕様の一部ではなく、実際、「Ｒａｎｇｅ：」ヘッダはＵＲＬから別途送られるオプションのヘッダであるので、ＨＴＭＬウェブページはバイト範囲を参照することができず、したがって、ブラウザはバイト範囲リクエストを実施する必要はない。バイト範囲リクエストを実装するブラウザでは、そのようなブラウザは、ビデオプラグインなどのプラグインがバイト範囲リクエストを出すのを許容しないことがある。この問題は、Ａｄｏｂｅ ＰＤＦ Ｒｅａｄｅｒプラグインのようなブラウザプラグインの設計における１つの問題となっている。ブラウザのプラグインがバイト範囲リクエストを出すことができない場合、ＤＡＳＨプラグインはＭＰＥＧビデオファイルからバイトの範囲をフェッチすることができない。
[0048]さらに、協力元（cooperating）ＣＤＮに対しすべてのＭＰＥＧビデオファイルを配信し、協力元ＣＤＮに対しＨＴＴＰ範囲リクエストを出すことによって一部のＭＰＥＧファイルを取り出すことが可能であり得るが、同じことをプロキシキャッシュデバイスにより行うのはそれほど容易ではない。プロキシキャッシュデバイスは、バイト範囲リクエストを実装することを要求されない。様々なプロキシキャッシュデバイスは、一般に、数百の異なる組織によって管理されており、数十の異なる実装態様があるので、すべてのプロキシキャッシュデバイスがバイト範囲リクエストを実装するのを保証することはできない。ファイル全体でバイト範囲リクエストに応答することは、ＨＴＴＰ１．１では正当である。これは、ブラウザがバイト範囲リクエストを無視すること、またはそれが意図的に行われ得ることが理由であり得る。プロキシキャッシュがウイルススキャナを実装している場合、スキャナは、バイト範囲の結果としてコンテンツを提供する前に、すべてを取り出して、それをウイルススキャンするために、バイト範囲リクエストをファイル全体リクエストに変換することがある。今日の一般的なウェブリクエストは、３個以上のプロキシデバイス（オリジンサーバのプロキシキャッシュ、国内のバックホールプロキシ、現地のＩＳＰプロキシ）を通過することがあり、任意の単一のプロキシデバイス（またはプロキシデバイスのすべて）は、バイト範囲リクエストを無効にするように構成され得る。
[0049]その上、たとえば通常のビデオの２時間に対し生じる一連のバイト範囲リクエストからＭＰＥＧファイルを再構成できるほど高度なプロキシキャッシュデバイスはあまりない。バイト範囲リクエストを出すことができるブラウザがほとんどなく、ブラウザプラグインの一部のみがバイト範囲リクエストを出すことができるときには、ファイル再構成は実施困難である。キャッシュが（ａ）バイト範囲リクエストをまったくキャッシュしないか、または（ｂ）所与のファイルに対する直近のバイト範囲リクエストのみを保持するか、または（ｃ）別個の各バイト範囲リクエストを別個のファイルとして扱う可能性の方がはるかに高い。最後のケースでは、２秒のフラグメントによる１０個のストリームを伴う２時間ムービーの場合、プロキシキャッシュに最大７２，０００個のフラグメントが生じる。この場合、ムービーごとに何千ものフラグメントを管理するオーバーヘッドは、キャッシング上、非常に非効率でやっかいなものなる可能性がある。
[0050]本開示の技法は、ブラウザによってフェッチされるＵＲＬ内でバイト範囲リクエストを出すための、マルチメディアコンテンツ、たとえば、３ＧＰＰ ＤＡＳＨプロトコルによるマルチメディアコンテンツのストリーミングのためのメカニズムを含む。これらの技法はまた、いくつかの例では、バイト範囲がＵＲＬにどのようにマップされ得るかを定義する汎用テンプレートと、テンプレートの使用が必須であるのか、それとも単に許容されている（すなわち、オプションである）のかを表す方法と、ＵＲＬに埋め込まれたバイト範囲があることを示すデータをクライアントデバイスからオリジンサーバおよびプロキシデバイスに提供する方法と、ＢａｓｅＵＲＬおよび／またはＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅＵＲＬについてＣＤＮタイプに基づいてテンプレートを選択する方法とを含む。これら技法のいずれかまたはすべては、単独でまたは組合せで使用され得る。
[0051]メディアコンテンツの表現のセグメントなど、ビデオファイルは、ＩＳＯベースメディアファイルフォーマット、Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）ファイルフォーマット、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）ファイルフォーマット、Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）ファイルフォーマット、および／またはＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ファイルフォーマット、または他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠し得る。
[0052]ＩＳＯベースメディアファイルフォーマットは、メディアの交換、管理、編集、およびプレゼンテーションを可能にする、フレキシブルな、拡張可能なフォーマットでのプレゼンテーションのための、時限メディア情報を含むように設計される。ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２：２００４）は、時間ベースメディアファイルのための一般的な構造を定義するＭＰＥＧ−４ Ｐａｒｔ−１２において規定されている。ＩＳＯベースメディアファイルフォーマットは、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣビデオ圧縮のサポートを定義したＡＶＣファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）、３ＧＰＰファイルフォーマット、ＳＶＣファイルフォーマット、およびＭＶＣファイルフォーマットなどのファミリー中の他のファイルフォーマットのための基礎として使用される。３ＧＰＰファイルフォーマットおよびＭＶＣファイルフォーマットはＡＶＣファイルフォーマットの拡張である。ＩＳＯベースメディアファイルフォーマットは、オーディオビジュアルプレゼンテーションなどのメディアデータの時限シーケンスのためのタイミング、構造、およびメディア情報を含んでいる。ファイル構造はオブジェクト指向であり得る。ファイルは、非常に単純に基本オブジェクトに分解され得、オブジェクトの構造はそれらのタイプから暗示される。
[0053]ＩＳＯベースメディアファイルフォーマット（およびそれの拡張）に準拠するファイルは、「ボックス」と呼ばれる一連のオブジェクトとして形成され得る。ＩＳＯベースメディアファイルフォーマットのデータは、ボックス中に含まれ得、その結果、そのファイル内に他のデータが含まれている必要がなく、そのファイル内のボックスの外部にデータが存在する必要がない。これは、特定のファイルフォーマットによって必要とされる初期シグナチャを含む。「ボックス」は、一意のタイプ識別子と長さとによって定義されるオブジェクト指向ビルディングブロックであり得る。一般に、プレゼンテーションは１つのファイル中に含まれ、メディアプレゼンテーションは独立型（self-contained）である。ムービーコンテナ（ムービーボックス）はメディアのメタデータを含み得、ビデオおよびオーディオフレームは、メディアデータコンテナ中に含まれ得、他のファイル中にあり得る。
[0054]表現（動きシーケンス）は、セグメントと呼ばれることがある、いくつかのファイル中に含まれていることがある。タイミングおよびフレーミング（位置およびサイズ）情報は概してＩＳＯベースメディアファイル中にあり、補助ファイルは本質的に任意のフォーマットを使用し得る。このプレゼンテーションは、プレゼンテーションを含んでいるシステムに対して「ローカル」であり得るか、あるいはネットワークまたは他のストリーム配信メカニズムを介して与えられ得る。
[0055]メディアがストリーミングプロトコルを介して配信されるとき、メディアは、メディアがファイル中で表現される方法から変換される必要があり得る。これの一例は、メディアがリアルタイムトランスポートプロトコル（ＲＴＰ）を介して送信されるときである。ファイルには、たとえば、ビデオの各フレームが、ファイルフォーマットサンプルとして連続して記憶される。ＲＴＰでは、これらのフレームをＲＴＰパケット中に配置するために、使用されるコーデックに固有のパケット化ルールが順守されなければならない。ストリーミングサーバは、そのようなパケット化をランタイムに計算するように構成され得る。しかしながら、ストリーミングサーバを支援するためのサポートがある。
[0056]本開示の技法は、たとえば、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）に従って、ＨＴＴＰストリーミングなどのネットワークストリーミングプロトコルに適用可能であり得る。ＨＴＴＰストリーミングにおいて、頻繁に使用される動作にはＧＥＴおよび部分ＧＥＴがある。ＧＥＴ動作は、所与のユニフォームリソースロケータ（ＵＲＬ）または他の識別子、たとえばＵＲＩに関連するファイル全体を取り出す。部分ＧＥＴ動作は、入力パラメータとしてバイト範囲を受信し、その受信されたバイト範囲に対応するファイルの連続バイト数を取り出す。したがって、部分ＧＥＴ動作は１つまたは複数の個々のムービーフラグメントを得ることができるので、ムービーフラグメントはＨＴＴＰストリーミングのために与えられ得る。ムービーフラグメント中には、異なるトラックのいくつかのトラックフラグメントがあり得ることに留意されたい。ＨＴＴＰストリーミングでは、メディア表現は、クライアントがアクセス可能であるデータの構造化コレクションであり得る。クライアントは、ユーザにストリーミングサービスを提示するためにメディアデータ情報をリクエストし、ダウンロードし得る。
[0057]ＨＴＴＰストリーミングを使用して３ＧＰＰデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび／またはオーディオデータのための複数の表現があり得る。そのような表現のマニフェストがメディアプレゼンテーション記述（ＭＰＤ）データ構造で定義されていることがある。メディア表現は、ＨＴＴＰストリーミングクライアントデバイスがアクセス可能であるデータの構造化コレクションに対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するためにメディアデータ情報をリクエストし、ダウンロードし得る。メディア表現は、ＭＰＤの更新を含み得る、ＭＰＤデータ構造で記述され得る。
[0058]各期間は、同じメディアコンテンツについての１つまたは複数の表現を含み得る。表現は、オーディオまたはビデオデータのいくつかの代替符号化バージョンのうちの１つであり得る。表現は、符号化タイプなど、様々な特性によって異なり得、たとえば、ビデオデータの場合はビットレート、解像度、および／またはコーデックによって、またオーディオデータの場合はビットレート、言語、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された符号化オーディオまたはビデオデータのセクションを指すために使用され得る。
[0059]特定の期間の表現はグループに割り当てられ得、グループはＭＰＤ中のｇｒｏｕｐ属性によって示され得る。同じグループ中の表現は、概して互いに代替として見なされる。たとえば、特定の期間についてのビデオデータの各表現は、それらの表現のいずれかが、対応する期間についてのマルチメディアコンテンツのビデオデータを表示するために復号のために選択され得るように、同じグループに割り当てられ得る。１期間内のメディアコンテンツは、いくつかの例では、存在する場合、グループ０からの１つの表現か、または各非ゼログループからのせいぜい１つの表現の組合せのいずれかによって表され得る。期間の各表現についてのタイミングデータは、期間の開始時間に対して表現され得る。
[0060]表現は１つまたは複数のセグメントを含み得る。各表現は初期化セグメントを含み得るか、または表現の各セグメントは自己初期化していることがある。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含み得る。概して、初期化セグメントはメディアデータを含んでいない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）などの識別子によって一意に参照され得る。ＭＰＤは各セグメントに識別子を与え得る。いくつかの例では、ＭＰＤはまた、ＵＲＬまたはＵＲＩによってアクセス可能なファイル内のセグメントについてのデータに対応し得る、ｒａｎｇｅ属性の形態のバイト範囲を与え得る。
[0061]各表現はまた、１つまたは複数のメディア構成要素を含み得、各メディア構成要素は、オーディオ、ビデオ、および／または（たとえば、字幕用の）時限テキストなど、１つの個々のメディアタイプの符号化バージョンに対応し得る。メディア構成要素は、１つの表現内の連続するメディアセグメントの境界にわたって時間連続的であり得る。それによって、表現は、個々のファイルまたは一連のセグメントに対応することができ、それらの各々は、同じ符号化およびレンダリング特性を含むことができる。
[0062]本開示の技法は、いくつかの例では、１つまたは複数の利益を提供し得る。たとえば、これらの技法により、中間プロキシノードはバイト範囲応答を適切にキャッシュすることが可能になり得る。これらの技法により、プロキシノードがリクエストされたバイト範囲をキャッシュするように構成されておらず、ファイル全体を取り出すように構成されているときでも、プロキシノードはリクエストされたバイト範囲を適切にキャッシュすることができる。そのような適切なキャッシングを可能にするために、ＵＲＬのファイルパス部分にバイト範囲が組み込まれ得る。ファイルパスにバイト範囲を組み込むことによって、まったく同じバイト範囲についての将来のリクエストが（キーとしてＵＲＬファイルパスを使用して）適切に探索されて、キャッシュ「ヒット」を生むことができる。これは、探索が一般にＵＲＬのみで実行される（また、検索キーとして「Ｒａｎｇｅ：」ヘッダを含まない）ことから生じ得る。
[0063]また、これらの技法により、オリジンサーバは、２秒のフラグメントごとに１つのファイルではなく、表現ごとに１つのファイルを使用して（通常は３〜８個ある）ビデオ表現を記憶することができ、同時に、これらのファイルを中間ノードがキャッシュすることができる。これにより、オリジンサーバ上のファイルの数を、９，６００〜２８，８００から３〜８に減らすことができ、オリジンサーバは、ビデオファイルの記憶および取出しにおいて格段に効率的になり得る。
[0064]さらに、これらの技法は、ＨＴＴＰ ＧＥＴリクエストのＵＲＬにバイト範囲を組み込むために使用される方法に従って構成されたキャッシングサーバ（多くの場合、コンテンツ配信プロキシ）に利点をもたらし得る。これらのサーバは、リクエストを認識することができる場合、バイト範囲フラグメントを再アセンブルして、オリジンサーバと同様に、２時間ビデオの場合に３〜８個のファイルを記憶することができる。コンテンツ配信ネットワークが、このカスタムキャッシングおよび取出しポリシーを実現するために、これらの中間プロキシ上に「コンテンツ固有のアプリケーション」を配備することはまれではない。したがって、これは、開かれたインターネットにおける非常に実用的かつ実現可能な利益である。
[0065]その上、これらの技法は、１つのビデオがいくつかの異なるコンテンツ配信ネットワークによってキャッシュされるときに利点をもたらし得る。「コンテンツ固有のアプリケーション」の異なるポリシーまたは異なる属性のために、ＵＲＬ内のバイト範囲リクエストのパターンそのものは、コンテンツ配信ネットワークが異なる場合には異なる必要があり得る。本開示で説明する技法は、容易かつ自然な方法でこれを円滑にすることができ、クライアントデバイスがバイト範囲リクエストを、コンテンツ配信ネットワークが異なる場合には異なる形で埋め込むことを許容し得る。
[0066]図１は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム１０を示すブロック図である。この例では、システム１０は、コンテンツ作成（preparation）デバイス２０と、サーバデバイス６０と、クライアントデバイス４０とを含む。クライアントデバイス４０およびサーバデバイス６０は、インターネットを備え得るネットワーク７４によって通信可能に結合される。いくつかの例では、コンテンツ作成デバイス２０およびサーバデバイス６０も、ネットワーク７４または別のネットワークによって結合されるか、あるいは直接通信可能に結合され得る。いくつかの例では、コンテンツ作成デバイス２０およびサーバデバイス６０は同じデバイスを備え得る。いくつかの例では、コンテンツ作成デバイス２０は、作成されたコンテンツを、サーバデバイス６０を含む複数のサーバデバイスに配信することができる。同様に、いくつかの例では、クライアントデバイス４０は、サーバデバイス６０を含む複数のサーバデバイスと通信することができる。
[0067]以下でより詳細に説明するように、コンテンツ作成デバイス２０、サーバデバイス６０、およびクライアントデバイス４０のいずれかまたはすべては、本開示の対応する技法を実行するように構成され得る。たとえば、サーバデバイス６０および／またはコンテンツ作成デバイス２０は、汎用テンプレートを定義し、たとえばクライアントデバイス４０からのリクエストに応答して、たとえばサーバデバイス６０に対しデータをリクエストするためにＵＲＬにバイト範囲をマップする方法をクライアントデバイス４０に知らせるデータをクライアントデバイス４０に送ることができる。同様に、クライアントデバイス４０は、ＵＲＬからデータを取り出すためのリクエストをサブミットすることができ、この場合、リクエストのＵＲＬは、汎用テンプレートに従ったリクエストされるバイト範囲を含む。その上、サーバデバイス６０および／またはコンテンツ作成デバイス２０は、テンプレートの使用が必須であるか、それともオプションであるかを示す情報をクライアントデバイス４０に提供することができる。
[0068]さらに、クライアントデバイス４０は、（図１に示されていない）中間ネットワークデバイスに対し、ＵＲＬに埋め込まれたバイト範囲があることを中間ネットワークデバイスに知らせるデータを提供することができる。中間ネットワークデバイスは、プロキシデバイス、データをキャッシュまたは検査するように構成されたルータなどを含むことができ、以下でより詳細に説明する図２に示すように、ネットワーク７４内に含まれ得る。さらに、クライアントデバイス４０はマニフェストファイルを使用して、データのリクエスト先となるコンテンツ配信ネットワーク（ＣＤＮ）を選択するための技法を決定することができる。サーバデバイス６０は、ＣＤＮに含まれ得るサーバデバイスの一例を表す。たとえば、以下でより詳細に説明する図４に示すように、他のＣＤＮ内に、他のサーバデバイスまたは中間ネットワークデバイスが含まれ得る。概して、ＣＤＮは一般に、マニフェストファイル（ＨＴＭＬマニフェストファイルであっても、ＤＡＳＨ ＭＰＤであってもよい）を作成するエンティティによって選択され構成される。ＨＴＭＬの場合、ＣＤＮの選択は、ＵＲＬ内のホスト名を変えることによって実現され得る。ＤＡＳＨの場合、本開示の技法に従って、ＵＲＬにおけるホスト名とＣＤＮ ＵＲＬパターン生成との組合せによってＣＤＮが選択され得る。本開示の技法によれば、各ＣＤＮは、ＣＤＮに固有であるＵＲＬ自体の中でバイト範囲リクエストを生成するためのテンプレートを指定することができる。
[0069]コンテンツ作成デバイス２０は、図１の例では、オーディオソース２２とビデオソース２４とを備える。オーディオソース２２は、たとえば、オーディオエンコーダ２６によって符号化されるべき、キャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオソース２２は、前に記録されたオーディオデータを記憶する記憶媒体、コンピュータシンセサイザなどのオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース２４は、ビデオエンコーダ２８によって符号化されるべきビデオデータを生成するビデオカメラ、前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ作成デバイス２０は、必ずしもすべての例においてサーバデバイス６０に通信可能に結合されるとは限らないが、サーバデバイス６０によって読み取られる別個のメディアにマルチメディアコンテンツを記憶し得る。
[0070]未加工オーディオおよびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオエンコーダ２６および／またはビデオエンコーダ２８によって符号化される前にデジタル化され得る。オーディオソース２２は、通話参加者が話している間、通話参加者からオーディオデータを取得し得、同時に、ビデオソース２４は、通話参加者のビデオデータを取得し得る。他の例では、オーディオソース２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このようにして、本開示で説明する技法は、ライブ、ストリーミング、リアルタイムオーディオおよびビデオデータ、またはアーカイブされた、あらかじめ記録されたオーディオおよびビデオデータに適用され得る。
[0071]ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれている、ビデオソース２４によってキャプチャされたビデオデータと同時にオーディオソース２２によってキャプチャされたオーディオデータを含んでいるオーディオフレームである。たとえば、通話参加者が概して話すことによってオーディオデータを生成する間、オーディオソース２２はオーディオデータをキャプチャし、同時に、すなわちオーディオソース２２がオーディオデータをキャプチャしている間、ビデオソース２４は通話参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータとビデオデータとが同時にキャプチャされる状況、およびオーディオフレームとビデオフレームとが、それぞれ、同時にキャプチャされたオーディオデータとビデオデータとを備える状況に対応する。
[0072]オーディオエンコーダ２６は概して符号化オーディオデータのストリームを生成し、ビデオエンコーダ２８は符号化ビデオデータのストリームを生成する。データの各個々のストリームは（オーディオかビデオかにかかわらず）エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現のデジタル的にコード化された（場合によっては圧縮された）単一の構成要素である。たとえば、表現のコード化ビデオまたはオーディオ部分はエレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化エレメンタリストリーム（ＰＥＳ：packetized elementary stream）に変換され得る。同じ表現内では、１つのエレメンタリストリームに属するＰＥＳパケットを他のものから区別するためにストリームＩＤが使用され得る。エレメンタリストリームの基本データ単位はパケット化エレメンタリストリーム（ＰＥＳ）パケットである。したがって、コード化ビデオデータは概してエレメンタリビデオストリームに対応する。同様に、オーディオデータは１つまたは複数のそれぞれのエレメンタリストリームに対応する。
[0073]多くのビデオコーディング規格の場合と同様に、Ｈ．２６４／ＡＶＣは、誤りのないビットストリームのシンタックスと、セマンティクスと、復号プロセスとを定義し、そのいずれかは特定のプロファイルまたはレベルに準拠する。 Ｈ．２６４／ＡＶＣはエンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダの規格に準拠することを保証することを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびマクロブロック（ＭＢ）処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはｐｒｏｆｉｌｅ＿ｉｄｃ（プロファイルインジケータ）値でシグナリングされ得、レベルはｌｅｖｅｌ＿ｉｄｃ（レベルインジケータ）値でシグナリングされ得る。
[0074]Ｈ．２６４規格は、たとえば、所与のプロファイルのシンタックスによって課される限界内で、復号されたピクチャの指定されたサイズなど、ビットストリーム中のシンタックス要素がとる値に応じて、エンコーダおよびデコーダのパフォーマンスの大きい変動を必要とする可能性が依然としてあることを認識している。Ｈ．２６４規格は、多くの適用例において、特定のプロファイル内でシンタックスのすべての仮定的使用を処理することが可能なデコーダを実装することが実際的でもなく、経済的でもないことをさらに認識している。したがって、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に課された制約の指定されたセットとして「レベル」を定義している。これらの制約は、値に関する単純な限界であり得る。代替的に、これらの制約は、値の演算の組合せ（たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数）に関する制約の形態をとり得る。Ｈ．２６４規格は、個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートし得ることをさらに規定している。Ｈ．２６４内のコーディングの様々なプロファイルおよびレベルに対応するように、また今度の高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格などの他のコーディング規格に対応するように、マルチメディアコンテンツの様々な表現が提供され得る。
[0075]プロファイルに準拠するデコーダは、通常、プロファイル中で定義されたすべての機能をサポートする。たとえば、コーディング機能として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイルではサポートされないが、Ｈ．２６４／ＡＶＣの他のプロファイルではサポートされる。特定のレベルに準拠するデコーダは、レベルにおいて定義された制限を超えてリソースを必要としない任意のビットストリームを復号することが可能である必要がある。プロファイルおよびレベルの定義は、解釈可能性のために役立ち得る。たとえば、ビデオ送信中に、プロファイル定義とレベル定義のペアが全送信セッションについてネゴシエートされ、同意され得る。より詳細には、Ｈ．２６４／ＡＶＣでは、レベルは、たとえば、処理される必要があるブロックの数に関する制限と、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）サイズと、コード化ピクチャバッファ（ＣＰＢ：coded picture buffer）サイズと、垂直動きベクトル範囲と、２つの連続するＭＢごとの動きベクトルの最大数と、Ｂブロックが８×８ピクセル未満のサブブロックパーティションを有することができるかどうかとを定義し得る。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうかを決定し得る。
[0076]ＩＴＵ−Ｔ Ｈ．２６１、Ｈ．２６２、Ｈ．２６３、ＭＰＥＧ−１、ＭＰＥＧ−２、Ｈ．２６４／ＭＰＥＧ−４ ｐａｒｔ１０、および今度の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオ圧縮規格は、時間冗長性を低減するために動き補償時間的予測を利用する。ビデオエンコーダ２８などのエンコーダは、動きベクトルに従って現在のコード化ピクチャを予測するために、いくつかの前の（本明細書ではフレームとも呼ぶ）符号化ピクチャからの動き補償予測を使用し得る。典型的なビデオコーディングには３つの主要なピクチャタイプがある。それらは、イントラコード化ピクチャ（「Ｉピクチャ」または「Ｉフレーム」）と、予測ピクチャ（「Ｐピクチャ」または「Ｐフレーム」）と、双方向予測ピクチャ（「Ｂピクチャ」または「Ｂフレーム」）と、である。Ｐピクチャは、時間順序で現在のピクチャの前の参照ピクチャのみを使用し得る。Ｂピクチャでは、Ｂピクチャの各ブロックは、１つまたは２つの参照ピクチャから予測され得る。これらの参照ピクチャは、時間順序で現在のピクチャの前または後に位置し得る。
[0077]パラメータセットは、概して、シーケンスパラメータセット（ＳＰＳ）中のシーケンスレイヤヘッダ情報とピクチャパラメータセット（ＰＰＳ）中のまれに変化するピクチャレイヤヘッダ情報とを含んでいる。パラメータセットがある場合、このまれに変化する情報をシーケンスごとまたはピクチャごとに繰り返す必要はなく、したがってコーディング効率が改善され得る。さらに、パラメータセットの使用はヘッダ情報の帯域外送信を可能にし、誤り耐性を達成するための冗長送信の必要を回避し得る。帯域外送信では、パラメータセットＮＡＬユニットが、他のＮＡＬユニットとは異なるチャネル上で送信される。
[0078]図１の例では、コンテンツ作成デバイス２０のカプセル化ユニット３０は、ビデオエンコーダ２８からコード化ビデオデータを備えるエレメンタリストリームを受信し、オーディオエンコーダ２６からコード化オーディオデータを備えるエレメンタリストリームを受信する。いくつかの例では、ビデオエンコーダ２８およびオーディオエンコーダ２６はそれぞれ、符号化データからＰＥＳパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ２８およびオーディオエンコーダ２６はそれぞれ、符号化データからＰＥＳパケットを形成するためのそれぞれのパケッタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化オーディオデータと符号化ビデオデータとからＰＥＳパケットを形成するためのパケッタイザを含み得る。
[0079]ビデオエンコーダ２８は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格のための様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（たとえば、２次元または３次元再生用の）１つまたは複数のビューを有する表現、あるいは他のそのような特性など、様々なビットレートで、かつ様々な特性を用いてマルチメディアコンテンツの異なる表現を生成するために、様々な方法でマルチメディアコンテンツのビデオデータを符号化し得る。本開示で使用する表現は、オーディオデータとビデオデータ、たとえば、１つまたは複数のオーディオエレメンタリストリームと１つまたは複数のビデオエレメンタリストリームの組合せを備え得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するｓｔｒｅａｍ＿ｉｄを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々な表現のビデオファイルにアセンブルすることを担当する。
[0080]カプセル化ユニット３０は、オーディオエンコーダ２６とビデオエンコーダ２８とから表現のエレメンタリストリームのＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）の例では、コード化ビデオセグメントは、ビデオテレフォニー、ストレージ、ブロードキャスト、またはストリーミングなどの適用例に対処する「ネットワークフレンドリーな」ビデオ表現を与えるＮＡＬユニットに編成される。ＮＡＬユニットは、Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとにカテゴリー分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含み得、ブロック、マクロブロック、および／またはスライスレベルのデータを含み得る。他のＮＡＬユニットは非ＶＣＬ ＮＡＬユニットであり得る。
[0081]カプセル化ユニット３０は、マニフェストファイル（たとえば、ＭＰＤ）とともに、マルチメディアコンテンツの１つまたは複数の表現についてのデータを出力インターフェース３２に供給し得る。出力インターフェース３２は、ユニバーサルシリアルバス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライターまたはバーナーなど、記憶媒体に書き込むためのネットワークインターフェースまたはインターフェース、磁気またはフラッシュ記憶媒体へのインターフェース、あるいはメディアデータを記憶または送信するための他のインターフェースを備え得る。カプセル化ユニット３０は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース３２に供給し得、出力インターフェース３２は、ネットワーク送信、直接送信、または記憶媒体を介してそのデータをサーバデバイス６０に送り得る。図１の例では、サーバデバイス６０は、様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含み、各マルチメディアコンテンツ６４は、それぞれのマニフェストファイル６６と１つまたは複数の表現６８Ａ〜６８Ｎ（表現６８）とを含む。本開示の技法によれば、マニフェストファイル６６の部分は、別々のロケーションに記憶され得、たとえば、記憶媒体６２、または潜在的にプロキシデバイスなどネットワーク７４の別のデバイスの別の記憶媒体のロケーションに記憶され得る。
[0082]いくつかの例では、表現６８は適応セットに分離され得る。すなわち、表現６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、表現を用いて表示されるべきテキストおよび／または復号され、たとえばスピーカーによって提示されるべきオーディオデータの言語または他の特性を識別し得るテキストタイプ情報、適応セット中の表現のためのシーンのカメラアングルまたは現実世界のカメラパースペクティブを記述し得るカメラアングル情報、特定のオーディエンスのコンテンツ適合性を記述するレーティング情報など、特性のそれぞれの共通のセットを含み得る。
[0083]マニフェストファイル６６は、特定の適応セットに対応する表現６８のサブセットを示すデータ、ならびに適応セットについての共通の特性を含み得る。マニフェストファイル６６はまた、ビットレートなど、適応セットの個々の表現についての個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にし得る。適応セット中の表現は、マニフェストファイル６６の適応セット要素の子要素を使用して示され得る。
[0084]サーバデバイス６０は、リクエスト処理ユニット７０とネットワークインターフェース７２とを含む。いくつかの例では、サーバデバイス６０は、ネットワークインターフェース７２を含む複数のネットワークインターフェースを含み得る。さらに、サーバデバイス６０の機能のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなど、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ６４のデータをキャッシュし、サーバデバイス６０の構成要素に実質的に準拠する構成要素を含み得る。概して、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送信および受信するように構成される。
[0085]リクエスト処理ユニット７０は、クライアントデバイス４０などのクライアントデバイスから、記憶媒体７２のデータについてのネットワークリクエストを受信するように構成される。たとえば、リクエスト処理ユニット７０は、Ｒ．Ｆｉｅｌｄｉｎｇらによる、ＲＦＣ２６１６、「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１」、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、ＩＥＴＦ、１９９９年６月に記載されている、ハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１を実装し得る。すなわち、リクエスト処理ユニット７０は、ＨＴＴＰ ＧＥＴリクエストまたは部分ＧＥＴリクエストを受信し、これらのリクエストに応答してマルチメディアコンテンツ６４のデータを与えるように構成され得る。リクエストは、たとえば、セグメントのＵＲＬを使用して、表現６８のうちの１つのセグメントを指定し得る。いくつかの例では、リクエストはまた、セグメントの１つまたは複数のバイト範囲を指定し得る。いくつかの例では、セグメントのバイト範囲は、部分ＧＥＴリクエストを使用して指定され得る。他の例では、本開示の技法によれば、セグメントのバイト範囲は、たとえば汎用テンプレートに従って、セグメントのＵＲＬの一部として指定され得る。
[0086]リクエスト処理ユニット７０はさらに、表現６８のうちの１つのセグメントのヘッダデータを与えるためのＨＴＴＰ ＨＥＡＤリクエストに対応するように構成され得る。いずれの場合も、リクエスト処理ユニット７０は、リクエストされたデータをクライアントデバイス４０などのリクエスト元デバイスに与えるためのリクエストを処理するように構成され得る。さらに、リクエスト処理ユニット７０は、バイト範囲を指定するＵＲＬを構成するためのテンプレートを生成し、テンプレートが必須であるか、それともオプションであるかを示す情報を提供し、任意のバイト範囲が受け入れられるかどうか、またはバイト範囲の特定のセットのみが許容されるかどうかを示す情報を提供するように構成され得る。特定のバイト範囲のみが許容されるとき、リクエスト処理ユニット７０は、許容バイト範囲の指示を提供することができる。
[0087]図１の例に示すように、マルチメディアコンテンツ６４は、メディアプレゼンテーション記述（ＭＰＤ）に対応し得る、マニフェストファイル６６を含む。マニフェストファイル６６は、異なる複数の代替表現６８（たとえば、異なる品質をもつビデオサービス）の記述を含み得、その記述は、たとえば、表現６８のコーデック情報、プロファイル値、レベル値、ビットレート、および他の記述特性を含み得る。クライアントデバイス４０は、どのように表現６８のセグメントにアクセスすべきかを決定するためにメディアプレゼンテーションのＭＰＤを取り出し得る。従来型のＤＡＳＨでは、バイト範囲を指定する２つの方法がある。第１の方法は、個別のフラグメント定義にバイト範囲を明記し、ＭＰＤ ＸＭＬにバイト範囲を記憶することである。第２の方法は、ＭＰＥＧファイル内のＳＩＤＸボックスからバイト範囲情報をフェッチし、ＳＩＤＸバイト範囲情報を使用して、メディアについてのバイト範囲リクエストを出すことである。上述のバイト範囲は、これらの技法または当業者が理解する他の技法のうちのいずれかを使用して指定され得る。
[0088]クライアントデバイス４０のウェブアプリケーション５２はウェブブラウザを備えることができ、そのようなウェブブラウザは、クライアントデバイス４０のハードウェアベースの処理ユニット、またはそのようなウェブブラウザへのプラグインによって実行される。ウェブアプリケーション５２への言及は概して、ウェブアプリケーション、たとえばウェブブラウザ、独立型ビデオプレーヤ、またはウェブブラウザへの再生プラグインを組み込んでいるウェブブラウザのいずれかを含むことを理解されたい。ウェブアプリケーション５２は、クライアントデバイス４０のビデオデコーダ４８の復号能力およびビデオ出力４４のレンダリング能力を決定するためにクライアントデバイス４０の構成（configuration）データ（図示せず）を取り出し得る。
[0089]構成データはまた、クライアントデバイス４０のユーザによって選択された言語選好、クライアントデバイス４０のユーザによって設定された深度選好に対応する１つまたは複数のカメラパースペクティブ（camera perspective）、および／またはクライアントデバイス４０のユーザによって選択されたレーティング選好のうちのいずれかまたはすべてを含み得る。ウェブアプリケーション５２は、たとえば、ＨＴＴＰ ＧＥＴリクエストおよび部分ＧＥＴリクエストをサブミットするように構成されたウェブブラウザまたはメディアクライアントを備え得る。ウェブアプリケーション５２は、クライアントデバイス４０の１つまたは複数のプロセッサまたは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例では、ウェブアプリケーション５２に関して説明する機能のすべてまたは部分が、ハードウェア、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実装され得、ソフトウェアまたはファームウェアの命令を実行するために必須のハードウェアが設けられ得る。
[0090]ウェブアプリケーション５２は、クライアントデバイス４０の復号能力およびレンダリング能力を、マニフェストファイル６６の情報によって示される表現６８の特性と比較し得る。ウェブアプリケーション５２は、初めに、表現６８の特性を決定するためにマニフェストファイル６６の少なくとも一部分を取り出し得る。たとえば、ウェブアプリケーション５２は、１つまたは複数の適応セットの特性を記述するマニフェストファイル６６の一部分をリクエストし得る。ウェブアプリケーション５２は、クライアントデバイス４０のコーディング能力およびレンダリング能力によって満たされ得る特性を有する表現６８のサブセット（たとえば、適応セット）を選択し得る。ウェブアプリケーション５２は、次いで、適応セット中の表現のビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの１つからセグメント（またはバイト範囲）を取り出し得る。
[0091]概して、より高いビットレート表現はより高品質のビデオ再生を生じ得るが、利用可能なネットワーク帯域幅が減少したとき、より低いビットレート表現は十分な品質のビデオ再生を与え得る。したがって、利用可能なネットワーク帯域幅が比較的高いとき、ウェブアプリケーション５２は比較的高いビットレート表現からデータを取り出し得るが、利用可能なネットワーク帯域幅が低いとき、ウェブアプリケーション５２は比較的低いビットレート表現からデータを取り出し得る。このようにして、クライアントデバイス４０は、ネットワーク７４上でマルチメディアデータをストリーミングしながら、ネットワーク７４の変化するネットワーク帯域幅利用可能性にも適応し得る。
[0092]上記のように、いくつかの例では、クライアントデバイス４０は、たとえば、サーバデバイス６０またはコンテンツ配信ネットワークの他のデバイスにユーザ情報を提供し得る。ユーザ情報は、ブラウザクッキーの形態をとってよく、または他の形態をとってもよい。ウェブアプリケーション５２は、たとえば、ユーザ識別子、ユーザ識別子、ユーザ選好、および／またはユーザ人口統計学的情報を収集し、そのようなユーザ情報をサーバデバイス６０に提供し得る。ウェブアプリケーション５２は、次いで、再生中にターゲット広告メディアコンテンツからのデータを、リクエストされたメディアコンテンツのメディアデータ中に挿入するために使用すべき、ターゲット広告メディアコンテンツに関連するマニフェストファイルを受信し得る。このデータは、マニフェストファイルまたはマニフェストサブファイルについてのリクエストの結果として直接受信されることがあり、またはこのデータは、（ユーザ人口統計学的情報および他のターゲット情報を記憶するために使用される、供給されたブラウザクッキーに基づいて）代替のマニフェストファイルまたはサブファイルに対するＨＴＴＰリダイレクトを介して受信されることがある。
[0093]時々、クライアントデバイス４０のユーザは、マルチメディアコンテンツ６４などのマルチメディアコンテンツをリクエストするために、キーボード、マウス、スタイラス、タッチスクリーンインターフェース、ボタン、または他のインターフェースなど、クライアントデバイス４０のユーザインターフェースを使用してウェブアプリケーション５２と対話し得る。ユーザからのリクエストに応答して、ウェブアプリケーション５２は、たとえば、クライアントデバイス４０の復号能力およびレンダリング能力に基づいて、表現６８のうちの１つを選択することができる。表現６８のうちの選択された１つのデータを取り出すために、ウェブアプリケーション５２は、表現６８のうちの選択された１つの特定のバイト範囲を連続的にリクエストすることができる。このようにして、ウェブアプリケーション５２は、１つのリクエストを通じてファイル全体を受信するのではなく、複数のリクエストを通じてファイルの部分を連続的に受信することができる。本開示の技法によれば、ウェブアプリケーション５２は、たとえばテンプレートに従ってバイト範囲を指定するＵＲＬを含むリクエストを形成することができる。
[0094]いくつかの例では、サーバデバイス６０は、クライアントデバイス４０などのクライアントデバイスからのＵＲＬについての汎用テンプレートを指定することができる。そして、クライアントデバイス４０はテンプレートを使用して、ＨＴＴＰ ＧＥＴリクエストのためのＵＲＬを構成することができる。ＤＡＳＨプロトコルでは、ＵＲＬは、各セグメント内にそれらを明記すること、またはＵＲＬＴｅｍｐｌａｔｅを与えること、のいずれかによって形成され、このＵＲＬＴｅｍｐｌａｔｅは、$$、$RepresentationID$、$Index$、$Bandwidth$、または$Time$（ＤＡＳＨの現在のドラフトのＴａｂｌｅ ９により記述されている）などの１つまたは複数の周知のパターンを含むＵＲＬである。ＵＲＬリクエストを行う前に、クライアントデバイス４０は、「＄＄」などのテキスト列、表現ｉｄ、セグメントのインデックスなどを、ＵＲＬＴｅｍｐｌａｔｅに置換して、フェッチされる最終ＵＲＬを生成することができる。本開示は、たとえば、マルチメディアコンテンツ６４のマニフェストファイル６６などの、マルチメディアコンテンツのＭＰＤにおいて、ＤＡＳＨファイルのＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ要素に追加され得るいくつかの追加のＸＭＬフィールドを定義する。
[0095]いくつかの例では、サーバデバイス６０は、汎用テンプレートの用法、たとえば、テンプレートが必須であるか、それともオプションであるかを第１のフィールドに表すデータを提供することができる。たとえば、サーバデバイス６０（またはプロキシデバイス）はクライアントデバイス４０に対し、クライアントデバイス４０がテンプレートを使用することが求められるのか、それとも単に許容されるのかを示す情報を提供することができる。サーバデバイス６０は、テンプレートの用法を示すために、マニフェストファイル６６に要素の値を設定することができる。たとえば、（マニフェストファイル６６の一例を表す）ＭＰＤファイルは「ＭｕｓｔＵｓｅＲａｎｇｅＵＲＬ」と標示されたフィールドを含むことができ、これは３つの値、すなわち、DoNotIncorporateByteRangeIntoUrl(0)、ByteRangeTemplateOptional(1)、またはByteRangeTemplateMandatory(2)、のうちの１つをとり得る。いくつかの例では、サーバデバイス６０が値をゼロに設定した場合、フェッチされたＵＲＬはバイト範囲を含んではならず、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅを使用してはならない。いくつかの例では、サーバデバイス６０はそれ自体の選択で値を１に設定し、ＤＡＳＨプレーヤ（たとえば、ウェブアプリケーション５２）は、通常のバイト範囲リクエストを出すことができ、またはバイト範囲をＵＲＬ自体に埋め込むことができる。いくつかの例では、サーバデバイス６０が値を２に設定した場合、ＤＡＳＨプレーヤはＵＲＬ内でバイト範囲リクエストを出さなければならない。
[0096]本開示によって提供される別のフィールドは列挙属性、「ＡｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓ」であり、これも３つの値のうちの１つをとることができる。第１の値は、ＲａｎｇｅｓＯｎｌｙＦｒｏｍＭＰＤ（０）である。サーバデバイス６０がこの値を指定したとき、ＤＡＳＨプレーヤ（たとえば、ウェブアプリケーション５２）が（表現６８の各々のデータ内に含まれ得る）ＳＩＤＸからのバイト範囲を使用することは許容されない。したがって、ＤＡＳＨプレーヤは、ＤＡＳＨ ＭＰＤ、たとえばマニフェストファイル６６からのバイト範囲を使用することのみに制約され得る。第２の値は、ＲａｎｇｅｓＦｒｏｍＳＩＤＸ（１）である。サーバデバイス６０がこの値を指定したとき、ＤＡＳＨプレーヤは、フラグメントまたはセグメントリクエストを生成するために（同じく、表現６８の各々のセグメント内にデータとして含まれ得る）ＳＩＤＸからのバイト範囲のみを使用することができる。第３の値、ＲａｎｇｅｓＦｒｏｍＡｎｙｗｈｅｒｅ（３）は、ＳＩＤＸまたはＭＰＤを使用する能力、および２つ以上のフラグメントを１つのセグメントリクエストに結合する能力、２つ以上のセグメントを一度にリクエストする能力、またはバイト範囲リクエストにおける１つもしくは複数のセグメントもしくはセグメントの部分についてのリクエストの他の混合を含む、任意のバイト範囲リクエストを許容する。
[0097]本開示によって提供されるさらに別のフィールドは、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅフィールドである。サーバデバイス６０は、このフィールドにデータを提供することができる。本開示の技法によれば、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅは、フィールド＄Ｕｒｌ＄、＄ＳｔａｒｔＢｙｔｅ＄、および＄ＥｎｄＢｙｔｅ＄を含む文字列パターンを指定することができる。さらに、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅは、ＵＲＬベースのバイト範囲リクエストを出すために追加される追加のＡＳＣＩＩ文字を含むことができ、またはＵＲＬＴｅｍｐｌａｔｅ要素の場合のように単一のドル記号を意味するシンボル「＄＄」を含むことができる。クライアントデバイス４０は、ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅの３つのフィールドの各々にデータを代入することができる。具体的には、クライアントデバイス４０は、ＵＲＬ Ｔｅｍｐｌａｔｅフィールドの値に対応する値を＄Ｕｒｌ＄フィールドに代入することができる。クライアントデバイス４０はまた、＄ＳｔａｒｔＢｙｔｅ＄フィールドおよび＄ＥｎｄＢｙｔｅ＄フィールドに、結果として生じるＵＲＬにリクエストされるバイト範囲の開始バイトおよび終了バイトを代入することができる。このようにして、クライアントデバイス４０は、バイト範囲リクエストについての情報を含むＵＲＬを生成することができる。クライアントデバイス４０は、「Ｒａｎｇｅ：」フィールドを内包していないＧＥＴリクエストを介して、この構成されたＵＲＬからデータをフェッチすることができる。すなわち、クライアントデバイス４０は、生成されたＵＲＬを含め、ＧＥＴリクエストをサーバデバイス６０にサブミットすることができる。
[0098]バイト範囲テンプレートの文字列パターンがＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅ属性に記憶されるかどうか、または代わりにそれらがＵＲＬＴｅｍｐｌａｔｅに記憶されるかどうかは重要ではないことを、当業者は理解されたい。ＢｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅおよびＵＲＬＴｅｍｐｌａｔｅ属性におけるテンプレートの文字列パターンの記憶は、例として提示されるにすぎない。概して、これらの文字列パターンは、ロケーションまたはマニフェストファイル中の他の場所のいずれかに記憶され得る。
[0099]これらのフィールドのデータを指定するリクエストの一例は下記のとおりである。この例では、（サーバデバイス６０などの）ウェブサーバが、バイト範囲を使用して、または範囲リクエストに対応することによって（この場合、範囲がＵＲＬに埋め込まれている）、マルチメディアコンテンツ（たとえば、ムービー「トロン」）を分配する。ウェブサーバは、たとえばｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍであり得る。以下に提示するのは、この第１の例の値である。
Figure 0006316781
[0100]この例では、「ｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍ」のウェブサーバは、要素「ＭｕｓｔＵｓｅＲａｎｇｅＵＲＬ」に「１」の値を割り当てることによって、バイト範囲テンプレートがクライアントデバイスにとってオプションであることを示している。すなわち、クライアントデバイス４０は、ＵＲＬテンプレートに従って形成されるＵＲＬの一部としてバイト範囲を指定してよく、またはクライアントデバイス４０は、従来型の部分ＧＥＴリクエストを利用してもよい。クライアントデバイス４０がテンプレートを使用することを選択した場合、クライアントデバイスはＵＲＬ（「ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍ／ＴＲＯＮ／ｓｅｇｍｅｎｔ．＄Ｂａｎｄｗｉｄｔｈ＄．＄Ｉｎｄｅｘ＄」）、その後にスラッシュ「／」、＄ＳｔａｒｔＢｙｔｅ＄の値、別のスラッシュ「／」、そして＄ＥｎｄＢｙｔｅ＄の値についてのリクエストを出す。したがって、クライアントデバイス４０は２つの部分、すなわち、特定の表現およびそのセグメントに対応する基本部分と、リクエストされるバイト範囲の開始バイトおよび終了バイトを指定するバイト範囲部分とを有するＵＲＬを構成することができる。バイト範囲部分は、部分ＧＥＴリクエストにおける「Ｒａｎｇｅ：」ヘッダの機能を基本的に実行し得るが、「Ｒａｎｇｅ：」ヘッダとしてではなく、ＵＲＬパス自体に指定される。当業者にとっては、バイト範囲がＵＲＬパスに指定されるので、ＧＥＴリクエストの結果が、透過的な（または明示的な）ウェブプロキシデバイスのような何らかの中間デバイスによって潜在的にキャッシュ可能であることが明らかであろう。当業者にとっては、キャッシュ可能なリクエストにより、数千さらには数百万のクライアントが同時に同じコンテンツをリクエストできるようにビデオ再生をスケールできることが明白なはずである。当業者にとっては、コンテンツ配信ネットワークが異なる場合には異なり得るテンプレートに従ってバイト範囲が指定されるので、ＵＲＬパス内でのバイト範囲リクエスト（byte-range-within-url-path request）のために、１つの唯一のフォーマットを様々なコンテンツ配信ネットワークに採用させる負担が軽減されることが明らかなはずである。
[0101]その上、この例では、ウェブサーバは、要素「ＡｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓ」に「０」の値を割り当てることによって、ＭＰＤに指定されたバイト範囲のみが指定可能であることを示している。したがって、クライアントデバイスがバイト範囲テンプレートを使用してバイト範囲を指定することを選択しても、部分ＧＥＴリクエストとしてバイト範囲を指定することを選択しても、クライアントデバイスは、ＭＰＤファイルに特定されるバイト範囲を指定することを許容されるにすぎない。
[0102]クライアントデバイスによって実行されるウェブブラウザ（たとえば、クライアントデバイス４０のウェブアプリケーション５２）がバイト範囲リクエストをサポートし、プラグイン用にバイト範囲リクエストをサポートすると仮定すると、ＤＡＳＨプラグインはＨＴＴＰ１．１のＲａｎｇｅ：ヘッダを使用してＢｙｔｅＲａｎｇｅリクエストを出すことができる。セグメントＩＤ＝２７を有する１０００Ｋｂｐｓビットレートのビデオを仮定すると、バイト範囲を指定する従来型の部分ＧＥＴリクエストは次のようになり得る。
Figure 0006316781
[0103]ウェブブラウザにより、そのプラグインがバイト範囲リクエストを出すことができない場合、リクエストは、上記の例によれば、次のようになり得る。
Figure 0006316781
[0104]このようにして、本開示の技法により、（クライアントデバイス４０などの）クライアントデバイスによって実行される（ウェブアプリケーション５２などの）ウェブブラウザプラグインは、関わるブラウザにより、正式なＨＴＴＰ１．０「Ｒａｎｇｅ：」ヘッダをリクエストヘッダにおいて出すことができないときでも、バイト範囲リクエストを出すことができる。同様に、ウェブブラウザプラグインは、たとえば、（中間ネットワークデバイス、たとえばルータなどの）他のネットワークデバイスが部分ＧＥＴリクエストをサポートしないか、または適切に処理しない状況に対処するために、ウェブブラウザがバイト範囲リクエストをサポートしない場合でも、このようにしてバイト範囲リクエストを出すためにこれらの技法を使用することができる。
[0105]ウェブアプリケーション５２によってサーバデバイス６０にサブミットされたリクエストに応答して、ネットワークインターフェース５４は、選択された表現の受信されたセグメントのデータを受信し、ウェブアプリケーション５２に提供することができる。そして、ウェブアプリケーション５２は、セグメントをカプセル化解除ユニット５０に提供することができる。カプセル化解除ユニット５０は、ビデオファイルの要素を構成ＰＥＳストリームにカプセル化解除し、ＰＥＳストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのＰＥＳパケットヘッダによって示される、符号化データがオーディオストリームの一部であるかビデオストリームの一部であるかに応じて、符号化データをオーディオデコーダ４６またはビデオデコーダ４８のいずれかに送り得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号されたオーディオデータをオーディオ出力４２に送り、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力４４に送る。
[0106]ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、ウェブアプリケーション５２、およびカプセル化解除ユニット５０はそれぞれ、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適な処理回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２８およびビデオデコーダ４８の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。同様に、オーディオエンコーダ２６およびオーディオデコーダ４６の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合コーデックの一部として統合され得る。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダオーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、ウェブアプリケーション５２、および／またはカプセル化解除ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
[0107]このようにして、クライアントデバイス４０は、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出すこととを行うように構成された１つまたは複数のプロセッサを含み得る、マルチメディアデータについての情報を取り出すためのデバイスの一例を表す。
[0108]その上、サーバデバイス６０は、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬはマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を行うように構成された１つまたは複数のプロセッサを含み得る、ビデオデータについての情報を送るためのデバイスの一例を表す。
[0109]図２は、図１のネットワーク７４の一部を形成するデバイスの例示的なセットを示すブロック図である。この例では、ネットワーク７４は、ルーティングデバイス８０Ａ、８０Ｂ（ルーティングデバイス８０）とプロキシキャッシュデバイス８２とを含む。ルーティングデバイス８０およびプロキシキャッシュデバイス８２は、ネットワーク７４の一部を形成し得る少数のデバイスを表すことが意図される。スイッチ、ハブ、ゲートウェイ、ファイアウォール、ブリッジ、および他のそのようなデバイスなどの他のネットワークデバイスも、ネットワーク７４内に含まれ得る。その上、サーバデバイス６０とクライアントデバイス４０との間にネットワークパスに沿って追加のネットワークデバイスが提供され得る。
[0110]概して、ルーティングデバイス８０は、ネットワーク７４を介してネットワークデータを交換するための１つまたは複数のルーティングプロトコルを実装する。いくつかの例では、ルーティングデバイス８０は、後述のようにプロキシキャッシュデバイス８２による機能など、プロキシまたはキャッシュ動作を実行するように構成され得る。したがって、いくつかの例では、ルーティングデバイス８０もプロキシデバイスと呼ばれ得る。概して、ルーティングデバイス８０は、ネットワーク７４を介したルートを発見するためにルーティングプロトコルを実行する。そのようなルーティングプロトコルを実行することによって、ルーティングデバイス８０Ｂは、それ自体からルーティングデバイス８０Ａを介してサーバデバイス６０へ至るネットワークルートを発見することができる。
[0111]したがって、ルーティングデバイス８０Ｂは、クライアントデバイス４０からサーバデバイス６０に宛てられた、ＴＣＰ−ＩＰカプセル化ＨＴＴＰ ＧＥＴリクエストなどのネットワーク通信を受信することができる。そのような通信に応答して、ルーティングデバイス８０Ｂは、サーバデバイス６０へのルートを特定し、さらに、ルートがプロキシキャッシュデバイス８２を含むと決定し得る。たとえば、プロキシキャッシュデバイス８２は、ルートに沿った「ネクストホップ」を備えることができ、または１つもしくは複数の追加のネットワークデバイスは、ルーティングデバイス８０Ｂをプロキシキャッシュデバイス８２に通信可能に結合することができる。プロキシキャッシュデバイス８２はまた、通信をルーティングデバイス８０Ａに向けることができ、ルーティングデバイス８０Ａは、通信をサーバデバイス６０に転送することができる。
[0112]プロキシキャッシュデバイス８２は、プロキシキャッシュ機能を実行することができる。ＨＴＴＰプロキシキャッシングはインターネットが動作するために重要である。プロキシキャッシュデバイス８２などのＨＴＴＰプロキシキャッシュデバイスは、ＨＴＴＰプロトコルバージョン（たとえば、ＨＴＴＰ０．９、ＨＴＴＰ１．０、および／またはＨＴＴＰ１．１）のいずれかまたはすべてを実装することができる。その上、プロキシキャッシュデバイス８２などのプロキシキャッシュデバイスは、ＨＴＴＰ ＧＥＴリクエストに現れる一意の「ユニフォームリソースロケータ」（ＵＲＬ）に基づいてコンテンツをキャッシュすることができる。このＵＲＬをキーとして使用して、その後、キャッシュ内でフェッチリクエストを探索することができる。プロキシキャッシュデバイス８２は、本開示の技法に従って、変更ＵＲＬなどのＵＲＬに対応し得る、マルチメディアコンテンツの表現のセグメントまたはサブセグメントをキャッシュするように構成され得る。
[0113]いくつかの例では、コンテンツ配信ネットワーク（ＣＤＮ）がネットワーク７４内に提供されること、またはネットワーク７４に通信可能に結合されることがある。ＣＤＮを提供する会社の例には、Ａｋａｍａｉ、Ｌｅｖｅｌ ３ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、およびＬｉｍｅｌｉｇｈｔがある。ＣＤＮのデバイスは、プロキシキャッシュデバイス８２と同様の機能を実行することができる。ＣＤＮは、ＩＳＰに、また国内のバックホールプロバイダのポータルに、プロキシキャッシュデバイスとまったく同様のデバイスを配置することができる。有料で、ＣＤＮはコンテンツを配信すること、または顧客のコンテンツでプロキシキャッシュデバイスを「事前充填する（pre-fill）」ことができる。次いで顧客は、コンテンツを参照し、ＤＮＳスウィズリング（DNS swizzling）として一般に知られている技法を通じて、スマートネームサーバが、コンテンツについてのリクエストを最寄のローカルＣＤＮキャッシュに向けることができ、それによりウェブページがロードしているときの貴重な往復時間を節約することができる。代替的に、顧客は異なる料金を支払い、コンテンツがキャッシュされるのみで、あらかじめ「事前充填」されてはいないことがある。
[0114]上記で説明したように、ストリーミングネットワークプロトコルは、同じマルチメディアコンテンツの複数の表現を提供することができる。それによって、ＤＡＳＨなどの適応ストリーミングプロトコルは適応を可能にするが、その利益は高いコストを伴うことがある。数十、数百、数千、数百万、またはより多くの数のバイトを表し得るマルチメディアコンテンツが、たとえば、８個の異なるビットレートで符号化され、２秒のセグメントに分割されることがあり、さらに１つまたは複数のオーディオストリーム（たとえば、ステレオまたはＤｏｌｂｙ ５．１）が加わり、これも複数の部分に分割され得る。このようにして、２時間ビデオでは３，６００個以上のフラグメントに１０個のストリームを掛けた結果が生じることがあり、対応するデータはプロキシキャッシュまたはＣＤＮにおいて大量のディレクトリ記憶を消費することがある。
[0115]大量の記憶を回避するために、サーバデバイス６０は、ストリームの各々につき個別のファイル（たとえば、上記の例では１０個のファイル）を受信するように構成され得る。クライアントデバイス４０は、本開示の技法に従って、ＨＴＴＰ ＧＥＴリクエストもしくは部分ＧＥＴリクエスト、またはＧＥＴリクエストのＵＲＬに指定されたバイト範囲リクエストを使用して、セグメントまたはサブセグメントを取り出すことができる。いくつかの例では、ＨＴＴＰプロトコルスタックをクライアントデバイス４０が使用して、バイト範囲リクエストを出すことができる。このようにして、たとえば、３６，０００個のフラグメントからなる一般的なムービーは１０個のファイル、すなわち８個のオーディオおよび２個のビデオにまとめられ（collapsed）得る。本開示の技法によれば、クライアントデバイス４０は、それ自体がバイト範囲を指定するＵＲＬを表すデータを含むＨＴＴＰ ＧＥＴリクエストを使用して、ファイルの特定のバイト範囲を取り出すことができる。
[0116]場合によっては、プロキシデバイスが、「Ｒａｎｇｅ：」ヘッダを適切に処理しないにもかかわらずＨＴＴＰ１．１「Ｒａｎｇｅ：」ヘッダを受信したとき、プロキシデバイスは、ヘッダを無視し、ファイルのリクエストされた部分ではなくファイル全体をフェッチし分配することがある。これは、２時間のＭＰＥＧビデオファイルにとって打撃となることがあり、サイズが数ギガバイトに達し得る。そのようなストリームの途中でレートを切り替えることにより、プロキシキャッシュは、新しいレートに合わせてファイル全体をフェッチし始め、その結果、（キャッシュがコンテンツ応答を送り返し得る早い方の時点である、少なくとも半分のデータがキャッシュに到着する時点まで）遅延が生じる可能性がある。これは、ネットワークストリーミングを実現するために順々にファイルの小規模部分を取り出すという、部分ＧＥＴリクエストの意図した目的を途絶させる。この問題を克服するために、本開示は、バイト範囲リクエストをＵＲＬに透過的に埋め込み、それによって「Ｒａｎｇｅ：」ヘッダリクエストをファイル全体リクエストに変換するプロキシキャッシュを回避するための技法を提供する。その上、本開示はまた、オリジンサーバにバイト範囲リクエストを探すようにシグナリングするための技法を提供する。
[0117]特に、本開示は、バイト範囲リクエストをサポートしない中間プロキシを通じてバイト範囲をシグナリングするための技法を提供する。すなわち、クライアントデバイス４０は、ルーティングデバイス８０およびプロキシキャッシュデバイス８２などの中間ネットワークデバイスによってバイト範囲リクエストが適切に処理されるように、バイト範囲リクエストをサブミットすることができる。上述のように、クライアントデバイス４０によって実行されるウェブアプリケーション５２などのウェブブラウザが、ウェブブラウザがＨＴＴＰ１．１に従ってバイト範囲リクエストを実施しない（またはプラグインが利用するのを許容しない）場合だけではなく、中間デバイスが部分ＧＥＴリクエストをサポートしないか、または適切に処理しないときに範囲リクエストをサブミットするためにも、バイト範囲テンプレートに従ってＵＲＬに範囲リクエストを埋め込むことができる。途中で、バイト範囲がＵＲＬに埋め込まれるので、ルーティングデバイス８０および／またはプロキシキャッシュデバイス８２などのプロキシデバイスは、プロキシデバイスがバイト範囲リクエストを理解しないときでも、部分バイト範囲応答を記憶することができる。したがって、まったく同じバイト範囲を今後フェッチすることにより、プロキシデバイスはデータのバイト範囲をそのキャッシュから正しくフェッチするはずである。
[0118]本開示はまた、ＨＴＴＰ用の新しい「拡張ヘッダ」を提供する。概して、ＨＴＴＰは、ＨＴＴＰ「ＧＥＴ」リクエストにおける、またＨＴＴＰ応答におけるユーザ定義拡張ヘッダを許容する。ＲＦＣ２６１６のＳｅｃｔｉｏｎ７．１において定義されているように、「認識されないヘッダフィールドは、受信者によって無視されるべきであり、透過的プロキシによって転送されなければならない」。これらの拡張ヘッダは、「ＧＥＴ」リクエストにおける拡張ヘッダフィールドに帰着する（reduce to）エンティティヘッダフィールドとして解析される。拡張ヘッダ名は、任意の認識されないＨＴＴＰヘッダ（すなわち、任意のアルファベットトークン）である。拡張ヘッダは、通常はＳＭＴＰメッセージヘッダにおける、ＨＴＴＰによってまだ定義されていない任意のアルファベットトークンであり得るが、ＲＦＣ８２２に定義されているように、ＳＭＴＰのいかなる将来バージョンでもプレフィックス「Ｘ−」は使用されないことが保証される。ＨＴＴＰプロトコル自体は、ＲＦＣ８２２に定義されているヘッダ機構に基づいており、また「Ｘ−」取決めは、一般に転送−変更なし−オリジンサーバへ（forwarded-unchanged-to the origin server）と、返送−クライアントへ−変更なし（forwarded back-to the client-unchanged）である非ＨＴＴＰ拡張ヘッダを識別するために、ＨＴＴＰプロキシにより使用される。
[0119]本開示は、ＨＴＴＰ ＧＥＴリクエストに現れるにすぎない「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」と呼ばれる新しい拡張ヘッダを提供する。プレフィックス「Ｘ−」は、ＨＴＴＰとの将来の衝突を回避するために使用される。プレフィックス「Ｄａｓｈ−」は、ＤＡＳＨクライアントがヘッダを生成していることをシグナリングする。当業者には、このヘッダの正確な名前は重要ではないことは理解されるだろうが、これらの技法は、クライアントデバイスおよびサーバデバイスが拡張ヘッダ用の共通の名前に従って構成されていると仮定する。
[0120]このヘッダは、（ヘッダを解釈するように構成された）中間ノードおよびプロキシデバイスに対し、バイト範囲がＨＴＴＰ ＧＥＴリクエストに含まれることを示す情報を提供する。これにより、オリジンサーバまたはＣＤＮは、ＭＰＥＧファイルを単一のファイルとして記憶することができ、それは、このヘッダを理解する場合、「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」ヘッダを使用して、ＵＲＬに埋め込まれたバイト範囲があると決定することができる。
[0121]したがって、クライアントデバイス４０は、ＧＥＴリクエストのＵＲＬ内に埋め込まれた範囲リクエストにおいて拡張ヘッダを提供することができる。その上、ルーティングデバイス８０および／またはプロキシキャッシュデバイス８２などのプロキシデバイスが、ヘッダを認識するように構成されるとき、プロキシデバイスは、リクエストされたバイト範囲のみを取り出し、クライアントデバイス４０に提供することができる。その上、プロキシキャッシュデバイス８２および／またはルーティングデバイス８０はファイルを、同じファイルについての一連のバイト範囲リクエストから再アセンブルするように構成され得る。一方、ルーティングデバイス８０および／またはプロキシキャッシュデバイス８２などのプロキシデバイスがヘッダを解釈するように構成されていないとき、プロキシデバイスは、ヘッダを含むＧＥＴリクエストをサーバデバイス６０に渡すだけでよい。
[0122]「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」ヘッダはペイロードを有し得る。ペイロードの２つの例について以下で説明する。一例では、ペイロードは空である。バイト範囲の存在がヘッダの存在によってシグナリングされる。バイト範囲は常に、ＨＴＴＰ ＧＥＴ ＵＲＬリクエストの終わりに付加され得る。次いで、オリジンサーバ（たとえば、サーバデバイス６０）またはプロキシデバイス（たとえば、ルーティングデバイス８０もしくはプロキシキャッシュデバイス８２のうちの１つ）は、最後の文字からＵＲＬを検索することができ、（たとえば、ＲＦＣ２６１６におけるバイト範囲リクエスト仕様によって定義されている、文字「０〜９」および「−」および「，」の検索を使用して）最大長のバイト範囲リクエストを推定する。
[0123]次いで、オリジンサーバまたはプロキシデバイスは、いくつかの例では、ＵＲＬからバイト範囲を除去し、（除去されたバイト範囲を有するＵＲＬを使用して）ファイルを開き、必要なバイトをフェッチし、その範囲のバイトをクライアントデバイス４０にサービスすることができる。この設計は、「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」ヘッダを実装しない中間プロキシとの間で後方互換性があり、これらの中間プロキシデバイスは、バイト範囲を正しくキャッシュし、後のリクエスト時に、それをクライアントまたはクライアントプロキシにサービスする。たとえば、プロキシキャッシュデバイス８２は、Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬヘッダを認識し処理するように構成され得る一方、ルーティングデバイス８０Ｂは、Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬヘッダを処理するようには構成されないことがある。それでも、ルーティングデバイス８０Ｂは、このヘッダを含むリクエストをプロキシキャッシュデバイス８２に渡すことができ、プロキシキャッシュデバイス８２は、そのようなリクエストからヘッダを除去し、リクエストされたバイト範囲を取り出し、リクエストされたバイト範囲のデータをキャッシュし、リクエストされたバイト範囲をルーティング８０Ｂ経由でクライアントデバイス４０に提供することができる。プロキシキャッシュデバイス８２は、同じファイルの後続のバイト範囲をキャッシュすることができ、いくつかの例では、一連のそのようなバイト範囲リクエストからファイル全体を再アセンブルすることができる。このようにして、プロキシキャッシュデバイス８２は、リクエストされたバイト範囲のみをクライアントデバイス４０に提供する前にファイル全体をロードすることを回避することができ、そうでなければ、クライアントデバイス４０への送信で著しい遅延を引き起こし得る。
[0124]一方、オリジンサーバ、たとえばサーバデバイス６０は、単一のＭＰＥＧファイルにおいてビデオストリーム全体を維持することができ、より効率的にリクエストに対応し、ＭＰＥＧビデオをより効率的にディスク上または不揮発性（たとえば、ＦＬＡＳＨ）記憶装置内に記憶することができる。たとえば、本開示の技法に従って、以下のリクエストを使用してビデオのバイト範囲を取り出すことができる。
Figure 0006316781
[0125]別の例では、Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬヘッダのペイロードは、ＵＲＬ自体からの実際のバイト範囲リクエスト仕様を含む。したがって、これはユーザ定義「Ｒａｎｇｅ：」ヘッダのような働きをするが、その振る舞いは異なる。サーバデバイス６０などのオリジンサーバは、ペイロードにより「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」ヘッダを解釈し、このヘッダのペイロードをリクエストＵＲＬと照合するように構成され得る。パターン照合を計算することによって、オリジンサーバはバイト範囲指定子をＵＲＬから除去し、新しいＵＲＬを形成することができ、この新しいＵＲＬを使用して、ＭＰＥＧファイル全体をそのディスクまたは不揮発性記憶装置からフェッチする。次いでオリジンサーバは、（やはり、ＲＦＣ２６１６によって指定された同じシンタックスを使用する）バイト範囲仕様を使用して、必要なバイトをＭＰＥＧファイルから抽出することができる。たとえば、本開示の技法に従って、以下のリクエストを使用してビデオのバイト範囲を取り出すことができる。
Figure 0006316781
[0126]次いで、サーバ、プロキシ、またはＣＤＮデバイス（たとえば、サーバデバイス６０、ルーティングデバイス８０、またはプロキシキャッシュデバイス８２のうちの１つ）はこのリクエストをリライトし、たとえば次のように従来型の部分ＧＥＴリクエストとしてリクエストが行われていたかのようにコンテンツを分配することができる。
Figure 0006316781
[0127]ＮＦＳおよびＵＮＩＸ（登録商標）ファイルシステム上では、２つ以上の「／」文字の存在は、単一の「／」文字と同じ扱いを受けることに留意されたい。この技法には多くの利点があり得る。ＨＴＴＰに対するこの改良を実装するように構成されたＣＤＮまたはプロキシデバイスは、単一のＭＰＥＧファイルへのバイト範囲リクエストに対応して、ディスク上の記憶スペースを節約することができる。スマートプロキシキャッシュまたはＣＤＮは、一連のこれらの範囲リクエストからＭＰＥＧファイルを作り上げ、これらの範囲リクエストすべてを単一のキャッシュされたファイルに結合することもできる。たとえば、プロキシキャッシュデバイス８２は、ＭＰＥＧファイル全体、または他のビデオファイルを、たとえばクライアントデバイス４０または他のクライアントデバイスからの複数の連続的なバイト範囲リクエストから構成することができる。
[0128]オリジンサーバによって除去され得るＵＲＬ内のバイト範囲の存在をシグナリングするために、「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」ヘッダに、または別の拡張ヘッダにパターンが指定される場合など、他の可能な実装形態がある。そのような他の実装形態もすべて、本開示の技法を実施するために企図される。
[0129]このようにして、プロキシキャッシュデバイス８２は、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬはマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を行うように構成された１つまたは複数のプロセッサを含み得る、ビデオデータについての情報を送るためのデバイスの一例を表す。
[0130]図３は、様々なコンテンツ配信ネットワーク９２Ａ〜９２Ｎ（ＣＤＮ９２）を含む例示的なシステム９０を示すブロック図である。この例では、コンテンツ作成デバイス２０が、様々な表現によるマルチメディアコンテンツを作成し、１つまたは複数の表現をＣＤＮ９２の各々に提供する。いくつかの例では、ＣＤＮ９２の各々は同じ表現を受信することがあり、他の例では、ＣＤＮ９２は他のＣＤＮ９２とは異なる表現セットを受信することがある。ＣＤＮ９２の各々に、図１および図２に関して説明したサーバデバイス６０と同様のサーバデバイスが提供され得る。代替的に、ＣＤＮ９２の各々に、プロキシまたはキャッシュデバイスが提供され得る。その上、いくつかの例では、ＣＤＮ９２の中には、サーバデバイスを含むものもあれば、プロキシデバイスを含むものもある。「ＣＤＮ」という用語は概して、コンテンツデリバリネットワーク、コンテンツ配信ネットワーク、コンテンツサーバファーム、または他の同様の機能を指すために本開示において使用される。本開示の技法によれば、ＣＤＮ９２の各々は、それぞれのＣＤＮに固有であるバイト範囲を指定するＵＲＬのテンプレートを含むことができる。
[0131]いくつかの例では、ＣＤＮ９２のうちのいくつかは、１日、１週間、１ヵ月、１年のうちのある時間中、または他の時間中のみアクティブである。たとえば、ＣＤＮ９２Ａは、午前および午後の時間中アクティブであることがあり、ＣＤＮ９２Ｂは、夕方および夜の時間中アクティブであることがある。
[0132]本開示は、図３に関して説明するように、たとえば、クライアントデバイス４０によってＣＤＮまたはコンテンツサーバファームを選択するための技法を提供する。ＤＡＳＨ ＭＰＤファイルが、ＤＡＳＨコンテンツについてのリクエストを生成するために使用される一連のＢａｓｅＵＲＬを示すデータを含むと仮定される。その上、各ＢａｓｅＵＲＬは、一意の（ユニークな）ＣＤＮ、たとえばＣＤＮ９２のうちの一意の１つを指すと仮定される。したがって、（クライアントデバイス４０によって実行される）ＤＡＳＨプレーヤは、対応するＢａｓｅＵＲＬを選択することによって適切なＣＤＮを選択するように構成され得る。下記の表１に、選択するために使用され得る一連の５つの選択基準を示す。（追加または代替として）使用され得る他の基準があり、これらの５つは、これらよりもはるかに広範囲の可能な選択基準セットを代表するものである。したがって、表１に示す選択基準に対する追加または代替の選択基準が提供されてよい。
Figure 0006316781
[0133]一例では、クライアントデバイス４０は、リダイレクションサービスを指示するリダイレクションＵＲＬを指定することによって、ＣＤＮ９２のうちの１つを選択することができる。リダイレクションサーバデバイス９４は、リダイレクションサービスを実行する、リダイレクションＵＲＬで利用可能なデバイスを表す。この場合、クライアントデバイス４０は、ＰＯＳＴメッセージをリダイレクションＵＲＬに送って、ＰＯＳＴメッセージをリダイレクションサーバデバイス９４に向けることができる。メッセージの本文において、クライアントデバイス４０は唯一のＢａｓｅＵＲＬを指定することができる。次いでダイレクションサーバデバイス９４は、ＢａｓｅＵＲＬを調べ、ＣＤＮ９２のうちのどれを使用するかを決定し、クライアントデバイス４０に対し、ＨＴＴＰ応答の本文において新しいＢａｓｅＵＲＬを返すことができる。この決定は、ＰＯＳＴ元クライアントデバイスのロケーション（ロケーションプロトコルはクライアントＩＰアドレスをロケーションにマップし得る）、ブラウザタイプ（ＰＯＳＴリクエストに示される）、ネットワーク配置、および／または表１に記載の選択基準のうちのいずれか、あるいは同様の基準などの考えに基づき得る。クライアントデバイス４０は、ＰＯＳＴ方法を使用するのではなく、代わりにＧＥＴ方法（ＧＥＴ方法の本文でコンテンツを送る）を使用することができ、リダイレクションサーバは、ＨＴＴＰ３０１（Ｃｏｎｔｅｎｔ Ｍｏｖｅｄ）または３０７（Ｔｅｍｐｏｒａｒｙ Ｒｅｄｉｒｅｃｔ）応答を使用して、直接的にＣＤＮ上でコンテンツの第１の部分に直接的にクライアントデバイス４０をリダイレクトすることができることに留意されたい。
[0134]場合によっては、クライアントは、ＭＰＤ内のＣＤＮ選択情報に基づいて行動するように構成されないことがあり、そのため、クライアントは、ＢａｓｅＵＲＬをリダイレクションサーバにポスティングし得るだけではなく、選択基準をサーバにポスティングすることもあり、第３に、（ジオロケーション、ホップカウント、ローカル時刻などの）そのローカル情報のすべてまたは一部をリダイレクションサーバデバイス９４にポスティングすることがある。この場合、リダイレクションサーバ９４は、決定プロセス全体を実行し、クライアントデバイス４０によって使用されるべきＢａｓｅＵＲＬを返すことができる。
[0135]さらに、リダイレクションサーバデバイス９４は、クライアントデバイス４０が視聴を希望する特定のマルチメディアコンテンツに依拠し得る情報を分析するように構成され得る。いくつかのビデオタイトルは、必ずしもＣＤＮ９２の各々で入手可能であるとは限らない。たとえば、あるコンテンツは、輸出または著作権の制約により、ある国ではＣＤＮで入手可能ではないこともある。そのようなコンテンツ選択決定は、この例の実施を通じて下され得る。ＤＡＳＨの文脈では、「ＢａｓｅＵＲＬ＠ｒｅｄｉｒｅｃｔｉｏｎＵｒｌ」と命名されたオプションの属性が、ＨＴＴＰを介したそのようなＰＯＳＴリクエストに使用されるＵＲＬを含み得る。
[0136]他の例では、たとえばＢａｓｅＵＲＬ＠ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅと呼ばれる新しいＤＡＳＨ属性が、１つまたは複数の選択属性を示すために使用され得る。すなわち、クライアントデバイス４０は、サーバまたは他のデバイス、たとえばＣＤＮ９２のうちの１つのデバイスまたは別のデバイスから、この属性についてのデータを受信することができる。この属性の内容は、０またはそれよりも大きい数字のリストであり、これは１つまたは複数の選択基準を指定し得る。さらに、いくつかの数字は一連の引数を有し、ＢａｓｅＵＲＬごとに１つの引数を有することがある。これらの例では、リダイレクションＵＲＬは存在する必要がない。その上、ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅを指定する必要がない。すなわち、デフォルトでは、ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅ行動が必要とされる。この場合、クライアントデバイス４０上で実行されているＤＡＳＨプレーヤは、選択基準が、すべてのあり得るＢａｓｅＵＲＬに対して等しく重み付けする「重み付けランダム」であるかのように行動する。ＤＡＳＨプレーヤは、すべてのＢａｓｅＵＲＬの間でランダムかつ均等な選択を行い、そして選択されたＢａｓｅＵＲＬを使用して、すべての将来のリクエストを行うことができる。
[0137]さらに別の例では、ただ１つの選択基準がｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅに現れる。この例では、ＤＡＳＨプレーヤは、単純な選択基準を使用して、たとえば、サーバの負荷を分散するランダム選択によって、時刻によって、最小往復遅延によって、最小ホップカウントによって、かつ／またはロケーション基準を使用して、ＣＤＮ９２のうちの適切な１つを決定する。そしてＤＡＳＨクライアントは、選択されたＢａｓｅＵＲＬを使用して、すべての将来のリクエストを行う。たとえば、＜ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅ＝“１（０．２，０．２，０．３，０．３）”＞の値により、クライアントデバイスによって実行される負荷分散機構は、すべてのあり得るＢａｓｅＵＲＬの中からランダムに選択することができる。ただし、最初の２つのＢａｓｅＵＲＬを選ぶ可能性が２０％、最後の２つのＢａｓｅＵＲＬを選ぶ可能性が３０％ある。ＢａｓｅＵＲＬが選択されると、ＤＡＳＨクライアントは将来のリクエストの際に、選択されたＢａｓｅＵＲＬを再利用し続けることになる。
[0138]さらに別の例では、２つ以上のｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅが指定され得る。たとえば、＜ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅ＝“３，４，２（０〜３５９，３５９〜１４３９，０〜１４３９，１０８０〜１４３９），１（０．２，０．２，０．２，０．４）”＞などの値があり得る。この例では、追加のｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅの存在は、ＤＡＳＨプレーヤが最初に基準３を使用し、次いで基準４を使用し、次いで基準２を使用し、次いで所与の重み付け、すなわち０．２、０．２、０．２および０．４に従って基準１とのつながりを断つべきであることを示している。いくつかのＢａｓｅＵＲＬがすでに除去されている場合、残りの重みは、合計が１．０になるように大きくなり得ることに留意されたい。
[0139]この例について説明するために、４つの潜在的なＢａｓｅＵＲＬ、Ａ、Ｂ、Ｃ、およびＤがあり、これらのＢａｓｅＵＲＬがそれぞれのＣＤＮに対応すると仮定する。たとえば、ＡはＣＤＮ９２Ａに対応することができ、ＢはＣＤＮ９２Ｂに対応することができ、ＣはＣＤＮ９２Ｃに対応することができ、ＤはＣＤＮ９２Ｄに対応することができる。第１に、たとえばｐｉｎｇメッセージを使用して、Ａ、Ｂ、Ｃ、およびＤの各々につき往復遅延（ＲＴＤ）が計算され得る。これは、ＲＴＤが次のようになることを示し得る。Ａ− ２０ｍｓ、Ｂ− ２０ｍｓ、Ｃ− ３３ｍｓ、Ｄ− ４０ｍｓ。次いで、選好度の高いものから順に並べた選択リストは、Ａ、Ｂ、Ｃ、Ｄとなり、ＡおよびＢはともに第１位である。したがって、たとえばインターネット制御メッセージプロトコル（ＩＣＭＰ）ｐｉｎｇメッセージを使用して、Ａ、Ｂ、Ｃ、およびＤの各々につきホップカウントが測定され得る。すなわち、クライアントデバイス４０は、各々につきホップカウントを計算するために、ＣＤＮ９２の各々にＩＣＭＰ ｐｉｎｇメッセージをサブミットすることができる。例として、次のホップカウント値が特定されると仮定する。Ａ− ５ホップ、Ｂ− ３ホップ、Ｃ− １２ホップ、Ｄ− ２０ホップ。次いで、選好度の高いものから順に並べた選択リストは、ＢがＡよりもホップが少ないと決定されるので、Ｂがより望ましく、Ｂ、Ａ、Ｃ、Ｄとなる。
[0140]この例を続けると、時刻がたとえば３：００ｐｍと決定され得る。ＢａｓｅＵＲＬ向けにシグナリングされる時刻値は次のようになる。Ａ− ６ｐｍ〜真夜中、Ｂ− 真夜中〜６ａｍ、Ｃ− ６ａｍ〜真夜中、Ｄ− 終日。この場合、現在時刻が３：００ｐｍであると仮定すると、この例では３：００ｐｍはＡおよびＢの時刻範囲から外れるので、クライアントデバイスはＡとＢとを除去し得る。それによって、最終的選択はＣまたはＤ（たとえば、ＣＤＮ９２Ｃまたは９２Ｄ）となり得る。最小辞書式選択（minimum lexicographic choice）が行われ得、３３ｍｓ＜４０ｍｓであるので、Ｃに対応する
[0141]さらに別の例では、少数のＣＤＮがあり得るが、多数の時刻上の制約、負荷分散重み付け、またはＣＤＮに対する同様の制約があり得る。この例では、Ｎ個のＢａｓｅＵＲＬがある場合、ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅは数個の制約を含み得るが、各制約はＮ個よりも多くの引数を有し得る。（Ｎ＋１）番目の引数はＵＲＬ＃１を指すことがあり、（Ｎ＋２）番目の引数はＵＲＬ＃２を指すことがある、といった具合である。このようにして、Ｎ個よりも多くの引数があるときに、ＢａｓｅＵＲＬは繰り返し得る。この例は、ＢａｓｅＵＲＬの繰り返しを不要にすることによって、記憶スペースを節約することができる。この場合、制約ごとの引数の数が合致するはずである。これは特に、時刻などの制約にとって有用である。
[0142]この例について説明すると、４個のＣＤＮ Ａ、Ｂ、Ｃ、Ｄがあり、時刻に応じて異なる負荷分散制約があり得る。午前には、ＣＤＮ９２Ａおよび９２Ｂが負荷の８０％を、均等に分散された形で受け取ることができるが、夕方には、ＣＤＮ９２Ｃおよび９２Ｄが負荷の７０％を、均等に分散された形で受け取ることができる。制約は次のように記述され得る。＜ｓｅｌｅｃｔｉｏｎＡｔｔｒｉｂｕｔｅ＝“２（０〜７１９，０〜７１９，０〜７１９，０〜７１９，７２０〜１４３９，７２０〜１４３９，７２０〜１４４０，７２０〜１４３９）１（０．４，０．４，０．１，０．１，０．１，０．２，０．３５，０．３５）”＞。
[0143]図４は、例示的なマルチメディアコンテンツ１００の要素を示す概念図である。マルチメディアコンテンツ１００は、マルチメディアコンテンツ６４（図１）、またはメモリ６２に記憶された別のマルチメディアコンテンツに対応し得る。図４の例では、マルチメディアコンテンツ１００は、メディアプレゼンテーション記述（ＭＰＤ）１０２と、複数の表現１１０〜１２０とを含む。表現１１０は、オプションのヘッダデータ１１２とセグメント１１４Ａ〜１１４Ｎ（セグメント１１４）とを含み、表現１２０は、オプションのヘッダデータ１２２とセグメント１２４Ａ〜１２４Ｎ（セグメント１２４）とを含む。文字Ｎは、便宜上、表現１１０、１２０の各々中の最後のムービーフラグメントを指定するために使用する。いくつかの例では、表現１１０と表現１２０との間で異なる数のムービーフラグメントが存在し得る。
[0144]ＭＰＤ１０２は、表現１１０〜１２０とは別のデータ構造を備え得る。ＭＰＤ１０２は図１のマニフェストファイル６６に対応し得る。同様に、表現１１０〜１２０は図１の表現６８に対応し得る。概して、ＭＰＤ１０２は、コーディング特性およびレンダリング特性、適応セット、ＭＰＤ１０２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（たとえば、時間サブシーケンスを含む表現を示す情報）、および／または（たとえば、再生中のメディアコンテンツ中へのターゲット広告挿入のための）リモート期間を取り出すための情報など、表現１１０〜１２０の特性を全体的に記述するデータを含み得る。リモート期間は外部期間と呼ばれることもある。以下でさらに詳細に説明する図４〜図７に、様々な要素がＭＰＤおよび／または（表現のセグメントもしくは表現のヘッダデータ内などの）表現の一方または両方中に含まれるマルチメディアコンテンツの様々な例を示す。図４〜図７のＭＰＤのいずれかまたはすべては、実質的に図４のＭＰＤ１０２に対応し得る。
[0145]本開示の技法によれば、図４のＭＰＤ１０２は、たとえば、バイト範囲についてのＵＲＬテンプレート、テンプレートが必須であるか、それともオプションであるか、およびＣＤＮ選択基準などの情報を指定することができる。本開示の技法によるＭＰＤタイプ仕様の例示的な要素が、以下のようにＸＭＬ擬似コードで提供される。
Figure 0006316781
[0146]このようにして、ＭＰＤ１０２は、マルチメディアコンテンツ１００についてのリダイレクションＵＲＬを示すデータを含むことができる。図３に関して上記で説明したように、ＢａｓｅＵＲＬがＣＤＮ９２のうちの１つにリダイレクトされ得る。すなわち、クライアントデバイス４０は、リダイレクションサーバデバイス９４に対応し得るリダイレクションＵＲＬにＨＴＴＰ ＰＯＳＴをサブミットすることができる。クライアントデバイス４０は応答を、ＢａｓｅＵＲＬに基づいて、マルチメディアコンテンツ１００の表現１１０〜１２０のうちの１つからデータを受信するための新しいＵＲＬを示す情報を応答が含むように、リダイレクションサーバデバイス９４から受信することができる。具体的には、ＢａｓｅＵＲＬは、ＣＤＮ９２のうちの適切な１つを選択するために使用され得る。
[0147]その上、上記の例示的な擬似コードによれば、ＭＰＤ１０２は選択属性を示すデータを含むことができる。上記で説明したように、選択属性は選択基準を表す数字データを含むことができ、これはＢａｓｅＵＲＬについての引数を伴うことも伴わないこともある。したがって、クライアントデバイス４０またはプロキシキャッシュデバイス８２（図２）などのプロキシデバイスは、選択属性のデータを使用して、クライアントデバイス４０がマルチメディアコンテンツ１００についてのデータを取り出す際の元となるＣＤＮ９２（図３）のうちの適切な１つを選択することができる。
[0148]以下のＸＭＬ擬似コードは、ＭＰＤ１０２で提供され得る、デフォルトセグメントアクセス情報についての要素の例示的なセットを提供する。
Figure 0006316781
[0149]以下のＸＭＬ擬似コードは、ＭＰＤ１０２によって提供され得る、セグメントアクセス情報についての要素の例示的なセットを提供する。
Figure 0006316781
[0150]このようにして、ＭＰＤ１０２は、ＵＲＬテンプレートを表すデータを含むことができ、これは、クライアントデバイス４０などのクライアントデバイスが、「Ｒａｎｇｅ：」ヘッダによるのではなくＵＲＬ自体の中でバイト範囲をリクエストするようにＨＴＴＰ ＧＥＴリクエストにＵＲＬを構成し得る方法を指定することができる。したがって、クライアントデバイス４０はＭＰＤ１０２のデータを使用して、「Ｒａｎｇｅ：」ヘッダを使用するのではなくＵＲＬ内にバイト範囲を指定するＨＴＴＰ ＧＥＴリクエストを構成することができる。したがって、リクエストはＨＴＴＰ ＧＥＴリクエストとして構成されるが、このリクエストにより、サーバデバイス６０などのサーバデバイスは、ＵＲＬ自体によって指定されるリクエストされたバイト範囲のみを提供することができる。すなわち、ＵＲＬのすべてのデータを提供するのではなく、サーバデバイス６０は代わりに、ＵＲＬ自体の中でリクエストされたバイト範囲を提供することができる。それにより、サーバデバイス６０は、「Ｒａｎｇｅ：」ヘッダに続くデータを評価する必要はないが、代わりに、リクエストされたバイト範囲をＵＲＬ自体から決定することができる。同様に、プロキシキャッシュデバイス８２は、ＨＴＴＰ ＧＥＴリクエストのＵＲＬを分析し、ＵＲＬ内のリクエストされたバイト範囲をキャッシュしてクライアントデバイス４０に提供する一方で、リクエストされたバイト範囲を同じファイルの先行バイト範囲および／または後続バイト範囲に結び付けるように構成され得る。
[0151]以下のＸＭＬ擬似コードは、ＭＰＤ１０２によって提供され得る、ＳｅｇｍｅｎｔＩｎｆｏおよびＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔに共通するグルーピング属性についての要素の例示的なセットを提供する。ＳｅｇｍｅｎｔＩｎｆｏおよびＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔの例には以下がある。
Figure 0006316781
[0152]以下のＸＭＬ擬似コードは、ＭＰＤ１０２によって提供され得る、セグメントＵＲＬについての要素の例示的なセットを提供する。
Figure 0006316781
[0153]以下のＸＭＬ擬似コードは、ＭＰＤ１０２によって提供され得る、ＵＲＬテンプレートについての要素の例示的なセットを提供する。
Figure 0006316781
[0154]このようにして、ＭＰＤ１０２は、ＵＲＬテンプレートを示す情報を含むことができる。すなわち、要素ｂｙｔｅＲａｎｇｅＴｅｍｐｌａｔｅは、リクエストされるバイト範囲を指定するためのＵＲＬテンプレートのデータを表す。その上、このようにして、ＭＰＤ１０２は、テンプレートの使用が必須であるか、それともオプションであるかを示す情報を含むことができる。すなわち、ｍｕｓｔＵｓｅＲａｎｇｅＵＲＬについてのデータは、クライアントデバイス４０が従来型のＨＴＴＰ部分ＧＥＴリクエストもしくはテンプレートを使用してバイト範囲をリクエストすることを許容されているのかどうか、またはクライアントデバイス４０がテンプレートを使用することを求められているのかどうかを示すことができる。さらに、ａｌｌｏｗｅｄＢｙｔｅＲａｎｇｅｓのデータは、リクエストされ得る特定のバイト範囲、またはバイト範囲に対する制約があるかどうかを示すことができる。
[0155]以下のＸＭＬ擬似コードは、ＭＰＤ１０２によって提供され得る、セグメントリストについての要素の例示的なセットを提供する。
Figure 0006316781
[0156]ヘッダデータ１１２は、存在するとき、セグメント１１４の特性、たとえば、ランダムアクセスポイントの時間ロケーション、どのセグメント１１４がランダムアクセスポイントを含むか、セグメント１１４内のランダムアクセスポイントへのバイトオフセット、セグメント１１４のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１１４の他の態様、を記述し得る。ヘッダデータ１２２は、存在するとき、セグメント１２４についての同様の特性を記述し得る。追加または代替として、そのような特性はＭＰＤ１０２内に完全に含まれ得る。
[0157]セグメント１１４は１つまたは複数のコード化ビデオサンプルを含み、コード化ビデオサンプルの各々はビデオデータのフレームまたはスライスを含み得る。セグメント１１４のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性はＭＰＤ１０２のデータによって記述され得るが、そのようなデータは図４の例に示していない。ＭＰＤ１０２は、本開示において説明するシグナリング情報のいずれかまたはすべてに加えて、３ＧＰＰ仕様に記載されている特性を含み得る。
[0158]セグメント１１４、１２４の各々は、一意のユニフォームリソース識別子（ＵＲＩ）、たとえば、ユニフォームリソースロケータ（ＵＲＬ）に関連し得る。したがって、セグメント１１４、１２４の各々は、ＤＡＳＨなどのストリーミングネットワークプロトコルを使用して独立に取出し可能であり得る。このようにして、クライアントデバイス４０などの宛先デバイスは、セグメント１１４または１２４を取り出すためにＨＴＴＰ Ｇｅｔリクエストを使用し得る。いくつかの例では、クライアントデバイス４０は、セグメント１１４または１２４の特定のバイト範囲を取り出すためにＨＴＴＰ部分ＧＥＴリクエストを使用し得る。
[0159]上記のように、ＭＰＤ１０２は特定のＭＰＤプロファイルに準拠し得る。ＭＰＤ１０２は、ＭＰＤ１０２および／またはマルチメディアコンテンツ１００の多目的インターネットメール拡張（ＭＩＭＥ）タイプを示す情報を含み得る。しかしながら、ＭＩＭＥタイプは、概して、マルチメディアコンテンツを提示するためにどんなコーデックが必要とされるかを示さない。概して、デバイスが、ＭＰＤ１０２など、マルチメディアコンテンツのＭＰＤを取り出すことができる場合、そのデバイスは、ＭＰＤに対応するマルチメディアコンテンツのデータを再生することができると想定される。ただし、この想定は常に安全であるとは限らない。したがって、いくつかの例では、ＭＰＤ１０２は、ＭＰＤ１０２が対応するプロファイルを示す情報を含み得る。
[0160]ＭＰＤが対応し得るプロファイルの数が比較的小さいことがある。プロファイルは、Ｈ．２６４／ＡＶＣがビデオコーディングのためのプロファイルおよびレベルを含む様式と同様に、機能に対処するためのレベルによってサポートされ得る。ＭＰＤプロファイルは、上位プロファイルがすべての下位プロファイルのすべての特徴を含み得るという点で、オニオンシェル化（onion-shelled）され得る。登録機関が様々なプロファイルを登録するための登録プロセスがあり得る。いくつかの例では、クライアントデバイス４０などのクライアントデバイスは、ＭＰＤ１０２によってシグナリングされる表現１１０〜１２０の特性など、ＭＰＤの他のデータを取り出す前に、ＭＰＤ１０２などのＭＰＤのプロファイルを示す情報を取り出すように構成され得る。このようにして、ＭＰＤ１０２へのアクセスが与えられる前にＭＰＤ１０２のプロファイルがシグナリングされ得る。
[0161]プロファイル識別子は、プレーンテキストで（たとえば、プレーンネームとして）、または逆引き（reversed）ドメインネームで与えられ得る。プレーンネームは、３ＧＰＰまたは別の登録機関など、登録機関によって予約され得る。対応するマルチメディアコンテンツが、プロファイルに準拠することと、プロファイルを実装するリーダー（たとえば、クライアントデバイス）に対し、ＭＰＤを読み取り、それが認識したものを解釈し、それが理解しないマテリアルを無視する認可を与えることと、をプロファイルが請求し得るという点で、プロファイルは請求（claim）および認可(permission)と見なされ得る。
[0162]プロファイルは、たとえば、ＭＰＤ１０２の特徴、ネットワークの使用、（１つまたは複数の）メディアフォーマット、使用される（１つまたは複数の）コーデック、保護フォーマット、および／またはビットレート、スクリーンサイズなどの定量的測度などの特性を記述し得る。このようにして、ＭＰＤ１０２のプロファイルは、ＭＰＤ１０２および／またはマルチメディアコンテンツ１００のデータを取り出すためにどのコーデックがサポートされる必要があるかを示す情報を提供し得る。プロファイルは「準拠（conformance）ポイント」と表されることもある。ＭＰＤが準拠するプロファイルはＭＰＤの「Ｐｒｏｆｉｌｅｓ」属性中に示され得る。したがって、クライアントデバイスは、ＭＰＤ１０２の追加のデータを取り出す前に、この「Ｐｒｏｆｉｌｅｓ」属性に関係する情報を含むＭＰＤ１０２の部分を取り出すように構成され得る。代替的に、プロファイルは、ＭＰＤのＭＩＭＥタイプ中のパラメータとして示され得る。たとえば、プロファイル「Ｘ、Ｙ、およびＺ」は以下の様式で、たとえばコンテンツ作成デバイス２０によってシグナリングされ得る。
ｖｉｄｅｏ／ｖｎｄ．ｍｐｅｇ．ｍｏｄ；ｐｒｏｆｉｌｅｓ＝“Ｘ，Ｙ，Ｚ”
[0163]図５は、図４のセグメント１１４、１２４のうちの１つなど、表現のセグメントに対応し得る、例示的なビデオファイル１５０の要素を示すブロック図である。セグメント１１４、１２４の各々は、図５の例に示すデータの構成に実質的に準拠するデータを含み得る。上記で説明したように、ＩＳＯベースメディアファイルフォーマットおよびそれの拡張によるビデオファイルは、データを「ボックス」と呼ばれる一連のオブジェクトに記憶する。図５の例では、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２と、ムービー（ＭＯＯＶ）ボックス１５４と、ムービーフラグメント１６２（ムービーフラグメントボックスとも呼ばれる（ＭＯＯＦ））と、ムービーフラグメントランダムアクセス（ＭＦＲＡ）ボックス１６４とを含む。
[0164]ビデオファイル１５０は全般的に、表現１１０〜１２０（図４）のうちの１つに含まれ得る、マルチメディアコンテンツのセグメントの一例を表す。このようにして、ビデオファイル１５０は、セグメント１１４のうちの１つ、セグメント１２４のうちの１つ、または別の表現のセグメントに対応し得る。本開示の技法によれば、クライアントデバイス４０などのクライアントデバイスは、バイト範囲を指定するＵＲＬを使用して、ムービーフラグメント１６２のサブセットを取り出すようリクエストすることができる。バイト範囲は、ムービーフラグメント１６２のサブシーケンスに対応し得る。同様に、プロキシキャッシュデバイス８２などのプロキシキャッシュデバイスは、特定のバイト範囲を取り出すよう求めるリクエストに応答して、ビデオファイル１５０のデータのすべてを取り出すことができる。他の例では、プロキシキャッシュデバイス８２は、ビデオファイル１５０のバイト範囲についてのリクエストのセットがビデオファイル１５０の全データ量に対応するとの仮定の下で、リクエストのセットを受けて、ビデオファイル１５０をアセンブルすることができる。
[0165]図５の例において、ビデオファイル１５０は１つのセグメントインデックス（ＳＩＤＸ）ボックス１６１を含む。いくつかの例では、ビデオファイル１５０は追加のＳＩＤＸボックスを、たとえばムービーフラグメント１６２の間に含み得る。概して、ＳＩＤＸボックス１６１などのＳＩＤＸボックスは、ムービーフラグメント１６２のうちの１つまたは複数についてのバイト範囲を記述した情報を含む。他の例では、ＳＩＤＸボックス１６１および／または他のＳＩＤＸボックスがＭＯＯＶボックス１５４内に、ＭＯＯＶボックス１５４の後に、ＭＦＲＡボックス１６４の前もしくは後に、またはビデオファイル１５０内の他の場所に提供され得る。
[0166]ファイルタイプ（ＦＴＹＰ）ボックス１５２は、概して、ビデオファイル１５０のファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０の最良の使用を記述する仕様を識別するデータを含み得る。ファイルタイプボックス１５２は、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６２、およびＭＦＲＡボックス１６４の前に配置され得る。
[0167]ＭＯＯＶボックス１５４は、図５の例では、ムービーヘッダ（ＭＶＨＤ）ボックス１５６と、トラック（ＴＲＡＫ）ボックス１５８と、１つまたは複数のムービー拡張（ＭＶＥＸ）ボックス１６０とを含む。概して、ＭＶＨＤボックス１５６はビデオファイル１５０の一般的特性を記述し得る。たとえば、ＭＶＨＤボックス１５６は、ビデオファイル１５０が最初に生成されたとき、ビデオファイル１５０が最後に変更されたときを記述するデータ、ビデオファイル１５０の時間スケール、ビデオファイル１５０の再生の持続時間、またはビデオファイル１５０について一般に記述する他のデータを含み得る。
[0168]ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックについてのデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を記述するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例では、ＴＲＡＫボックス１５８はコード化ビデオピクチャを含み得、他の例では、トラックのコード化ビデオピクチャは、ＴＲＡＫボックス１５８のデータによって参照され得るムービーフラグメント１６２中に含まれ得る。
[0169]いくつかの例では、ビデオファイル１５０は２つ以上のトラックを含み得るが、これはＤＡＳＨプロトコルが機能するのに必要ではない。したがって、ＭＯＯＶボックス１５４は、ビデオファイル１５０中のトラックの数に等しい数のＴＲＡＫボックスを含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。たとえば、ＴＲＡＫボックス１５８は、対応するトラックについての時間および／または空間情報を記述し得る。カプセル化ユニット３０（図１）が、ビデオファイル１５０などのビデオファイル中にパラメータセットトラックを含むとき、ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様のＴＲＡＫボックスはパラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットトラックを記述するＴＲＡＫボックス内のパラメータセットトラック中でシーケンスレベルＳＥＩメッセージの存在をシグナリングし得る。
[0170]ＭＶＥＸボックス１６０は、たとえば、もしあれば、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、ムービーフラグメント１６２をビデオファイル１５０が含むことをシグナリングするように、対応するムービーフラグメント１６２の特性を記述し得る。ビデオデータをストリーミングするコンテキストでは、コード化ビデオピクチャは、ＭＯＯＶボックス１５４ではなくムービーフラグメント１６２中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、ＭＯＯＶボックス１５４ではなくムービーフラグメント１６２中に含まれ得る。
[0171]ＭＯＯＶボックス１５４は、ビデオファイル１５０中のムービーフラグメント１６２の数に等しい数のＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６２のうちの対応する１つの特性を記述し得る。たとえば、各ＭＶＥＸボックスは、ムービーフラグメント１６２のうちの対応する１つについての持続時間を記述するムービー拡張ヘッダボックス（ＭＥＨＤ）ボックスを含み得る。
[0172]上記のように、カプセル化ユニット３０は、シーケンスデータセットを、実際のコード化ビデオデータを含まないビデオサンプルに記憶し得る。ビデオサンプルは、概して、特定の時間インスタンスにおけるコード化ピクチャの表現である、アクセスユニットに対応し得る。ＡＶＣのコンテキストでは、コード化ピクチャは、アクセスユニットのすべてのピクセルを構築するための情報を含んでいる１つまたは複数のＶＣＬ ＮＡＬユニットと、ＳＥＩメッセージなど、他の関連する非ＶＣＬ ＮＡＬユニットとを含む。したがって、カプセル化ユニット３０は、ムービーフラグメント１６２のうちの１つ中に、シーケンスレベルＳＥＩメッセージを含み得る、シーケンスデータセットを含み得る。カプセル化ユニット３０はさらに、シーケンスデータセットおよび／またはシーケンスレベルＳＥＩメッセージの存在を、ムービーフラグメント１６２のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内のムービーフラグメント１６２のうちの１つ中に存在するものとしてシグナリングし得る。
[0173]ムービーフラグメント１６２は１つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント１６２は１つまたは複数のピクチャグループ（ＧＯＰ）を含み得、ピクチャグループの各々は、いくつかのコード化ビデオピクチャ、たとえば、フレームまたはピクチャを含み得る。さらに、上記で説明したように、ムービーフラグメント１６２は、いくつかの例では、シーケンスデータセットを含み得る。ムービーフラグメント１６２の各々は、ムービーフラグメントヘッダボックス（ＭＦＨＤ、図５に図示せず）を含み得る。ＭＦＨＤボックスは、ムービーフラグメントのシーケンス数など、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント１６２はビデオファイル１５０中のシーケンスナンバの順に含まれ得る。
[0174]ＭＦＲＡボックス１６４は、ビデオファイル１５０のムービーフラグメント１６２内のランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０内の特定の時間ロケーションへのシークを実行することなど、トリックモードを実行することを支援し得る。ＭＦＲＡボックス１６４は、概してオプションであり、いくつかの例では、ビデオファイル中に含まれる必要がない。同様に、クライアントデバイス４０などのクライアントデバイスは、ビデオファイル１５０のビデオデータを正しく復号し、表示するために、必ずしもＭＦＲＡボックス１６４を参照する必要がない。ＭＦＲＡボックス１６４は、ビデオファイル１５０のトラックの数に等しいか、またはいくつかの例ではビデオファイル１５０のメディアトラック（たとえば、非ヒントトラック）の数に等しい数のトラックフラグメントランダムアクセス（ＴＦＲＡ）ボックス（図示せず）を含み得る。
[0175]図６は、ＵＲＬテンプレートデータの指示を提供するための、またクライアントデバイスによってＵＲＬテンプレートデータを使用してバイト範囲リクエストを生成するための例示的な方法を示すフローチャートである。図６の方法についてサーバデバイス６０およびクライアントデバイス４０に関して説明するが、他のデバイスが図６の方法の技法と類似の技法を実装し得ることを理解されたい。たとえば、コンテンツ作成デバイス２０、あるいはプロキシキャッシュデバイス８２またはルーティングデバイス８０などのコンテンツ配信ネットワークの１つまたは複数のネットワークデバイスが、サーバデバイス６０による機能の一部または全部を実行し得る。
[0176]図６には示されていないが、いくつかの例では、クライアントデバイス４０は最初に、マルチメディアコンテンツのリクエスト先となるＣＤＮを特定することができる。いくつかの例では、クライアントデバイス４０が、複数のＣＤＮからＣＤＮを選択することができ、他の例では、リダイレクションサーバデバイス９４などのリダイレクションサーバが、ＣＤＮを選択し、選択されたＣＤＮを示す情報をクライアントデバイス４０に提供することができる。したがって、クライアントデバイス４０は、ＣＤＮを選択し、またはＣＤＮの指示を受信して、マルチメディアコンテンツのデータのリクエスト先となるＣＤＮを特定することができる。ＣＤＮを選択するための１つの例示的なプロセスについて、図９に関して以下でさらに詳細に説明する。
[0177]サーバデバイス６０は、適応セットおよびＵＲＬテンプレートデータの指示をクライアントデバイス４０に与え得る（２００）。たとえば、サーバデバイス６０は、ＭＰＤ１０２（図４）をクライアントデバイス４０に与え得る。上記で説明したように、ＭＰＤ１０２は、ＵＲＬテンプレートを表す情報のほか、テンプレートがバイト範囲リクエストにとって必須であるか、それともオプションであるかを表す情報を含み得る。クライアントデバイス４０は、たとえばサーバデバイス６０から受信されたＭＰＤファイルから、適応セット特性を記述した情報を受信することができる（２０２）。同様に、クライアントデバイス４０は、たとえば受信されたＭＰＤファイルから、ＵＲＬテンプレートを記述した情報と、テンプレートの使用がバイト範囲をリクエストする上で必須であるか、それともオプションであるかを記述した情報とを受信することができる。
[0178]クライアントデバイス４０は、次いで、クライアントデバイス４０が、取出し、復号、またはレンダリングを行うことを選択することができないかまたは選択しないであろう適応セットを除去するために、適応セット特性を分析し得る。たとえば、クライアントデバイス４０は、不適切な適応セットを決定するために、復号およびレンダリング能力を適応セットの特性と比較し得る。別の例として、クライアントデバイス４０は、望ましくない適応セットを除去するために、言語、レーティング、および（たとえば、３次元ビデオ再生用に特定のカメラアングルを有する２つ以上のビューによって与えられるような）奥行きの量についてのユーザ選好を比較し得る。クライアントデバイス４０は、次いで、クライアントデバイス４０の復号およびレンダリング能力に少なくとも部分的に基づいて、適切な適応セットを選択し得る（２０４）。
[0179]適応セットを選択した後に、クライアントデバイス４０は、特に適応セットの表現を記述するＭＰＤ部分についてのデータをリクエストし得る。それに応答して、サーバデバイス６０は、選択された適応セットにおいて、個々の表現特性のうち表現ビットレートの指示をクライアントデバイス４０に与え得る（２０６）。たとえば、サーバデバイス６０は、適応セット２６０（図６）のＭＰＤ部分のうちの特定の１つについてのデータをクライアントデバイス４０に送り得る。他の例では、クライアントデバイス４０は、マルチメディアコンテンツについての全ＭＰＤ（たとえば、図５のＭＰＤ２０２）をすでに受信していることがあるが、特に選択された適応セットに対応するＭＰＤの部分を特に分析し得る。このようにして、いくつかの例において、図６のステップ２０６は、ステップ２０２および／またはステップ２０４より前に行われ得る。
[0180]いずれの場合も、表現のビットレートを含む、選択された適応セットの表現に固有の特性を受信した（２０８）後に、クライアントデバイス４０は、ネットワーク帯域幅の現在利用可能な量を決定することができる（２１０）。クライアントデバイス４０は、次いで、選択された表現が、ネットワーク帯域幅の決定された現在利用可能な量によって対応され得るビットレートを有するように、選択された適応セットから表現を選択し得る（２１２）。表現のビットレートは、適応セット中の個々の表現のコーディング特性の例を表す。クライアントデバイス４０は、次いで、ＵＲＬテンプレートを使用して、選択された表現のデータをリクエストし得る（２１４）。
[0181]たとえば、クライアントデバイス４０は、選択された表現のセグメントをリクエストするようにＨＴＴＰ ＧＥＴリクエストを構成することができ、この場合、ＨＴＴＰ
ＧＥＴリクエストにおけるＵＲＬが、リクエストされるデータのバイト範囲を指定する。代替的に、部分ＧＥＴリクエストが許容される（すなわち、ＵＲＬテンプレートの使用がオプションである）と仮定すると、クライアントデバイス４０は、選択された表現のセグメントのバイト範囲を指定するＨＴＴＰ部分ＧＥＴを構成することができる。いくつかの例では、ＵＲＬテンプレートデータは、許容できる特定のバイト範囲をさらに指定することができる。そのような場合、クライアントデバイス４０は、利用可能なバイト範囲のうちの１つを選択することができる。いずれの場合も、クライアントデバイス４０はリクエストをサーバデバイス６０にサブミットし得る。上記のように、他の例では、クライアントデバイス４０は、ＢａｓｅＵＲＬへのリクエストをサブミットすることができ、それにより、リクエストが、サーバデバイスの代わりにリクエストをサービスするプロキシデバイスまたはキャッシュデバイスにより受信され得る。
[0182]図６の例では、サーバデバイス６０は、リクエストを受信し、それに応答して、リクエストされたデータをクライアントデバイス４０に送ることができる（２１６）。たとえば、リクエスト処理ユニット７０は、受信されたリクエストのデータから、クライアントデバイス４０のネットワークアドレス、たとえば、受信されたリクエストのソースインターネットプロトコル（ＩＰ）アドレスおよびソースポート、を決定し得る。リクエスト処理ユニット７０は、リクエストされたデータを含むネットワークパケットを形成し、当該リクエストされたデータを、クライアントデバイス４０へ、たとえば、クライアントデバイス４０の決定されたＩＰアドレスに宛てに送り得る。
[0183]リクエストされたデータを受信した後、クライアントデバイス４０は、受信されたデータを復号し、表示することを開始し得る（２１８）。リクエストされたデータを受信している間、クライアントデバイス４０は、現在利用可能なネットワーク帯域幅を分析することと、ネットワーク帯域幅の現在利用可能な量によって収容され得るビットレートを有する表現からのリクエストをサブミットすることとを続け得る（２１０〜２１４）。ネットワーク帯域幅の量が変化した場合、クライアントデバイス４０は、選択された適応セット中の異なる表現に適応的に切り替わり得る。たとえば、クライアントデバイス４０は、適応セット中の前の表現からリクエストされた最後のセグメントの時間ロケーションに対応する新しい表現中のセグメントを決定し、次いで、新しい表現中のその決定されたセグメント（またはそれの部分）をリクエストし得る。
[0184]このようにして、図６は、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して形成されたＵＲＬを指定するＧＥＴリクエストを出すこととを含む、マルチメディアデータを取り出す方法の一例を表す。
[0185]図６はまた、マルチメディアコンテンツのマニフェストファイルを提供することと、マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、ＵＲＬテンプレートおよびバイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含むようにＵＲＬを形成するためのテンプレートを提供し、ＵＲＬテンプレートおよびバイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、リクエストのＵＲＬはマルメディアコンテンツの表現のバイト範囲を指定し、リクエストに応答して、リクエストのバイト範囲に対応する表現のマルチメディアデータを出力することと、を含む、ビデオデータについての情報を送る方法の一例を表す。
[0186]図７は、ＵＲＬにバイト範囲を指定するＧＥＴリクエストを生成するための例示的な方法を示すフローチャートである。図７の方法は、クライアントデバイス４０などのクライアントデバイスによって実行され得る。破線によるボックスは、オプションのステップを表す。プロキシキャッシュデバイス８２などの中間ネットワークデバイスによって、同様の方法が実行され得る。以下で説明するように、中間ネットワークデバイスによって実行されるときに、本方法に対するいくつかの若干の変更が行われ得る。例として、図７の方法について、クライアントデバイス４０に関して説明する。いくつかの例では、ステップ２３０〜２３４は、図６のステップ２０２および２０４と実質的に同時に実行されることがあり、ステップ２３６〜２４４は、図６のステップ２１４に対応し得る。図６および図７のステップは、必ずしも図示される順番で実行される必要はなく、追加のステップが実行されることがあり、またはいくつかのステップが省略されること、もしくは連続的にではなく並行して実行されることがある。
[0187]最初に、クライアントデバイス４０は、マルチメディアコンテンツについてのＭＰＤファイルに対応する情報を受信し得る（２３０）。ＭＰＤファイルは、ＨＴＴＰ ＧＥＴリクエストのＵＲＬにバイト範囲を埋め込むためのＵＲＬテンプレートを指定する情報を含み得る。たとえば、ＵＲＬテンプレートは、ＵＲＬテンプレートとバイト範囲テンプレートの両方について、次のように指定することができる。
Figure 0006316781
[0188]ＭＰＤファイルは、ＵＲＬテンプレートが必須であるか、それともオプションであるかを示す情報をさらに含むことができる。したがって、クライアントデバイス４０は、いくつかの例では、ＭＰＤファイルのデータの分析に基づいて、ＵＲＬテンプレートが必須であるか、それともオプションであるかを決定することができる（２３２）。同様に、いくつかの例では、ＭＰＤファイルは、リクエストされ得る許容バイト範囲の指示を提供することができ、またはバイト範囲が制約されないことを示すことができる。したがって、いくつかの例では、クライアントデバイス４０はＭＰＤファイルを使用して、許容バイト範囲を決定することができる（２３４）。
[0189]次いでクライアントデバイス４０は、リクエストされるセグメントのバイト範囲を決定することができる（２３６）。たとえば、クライアントデバイス４０が、選択されたマルチメディアコンテンツのデータのストリーミングを始めたばかりである場合、クライアントデバイス４０は、セグメントの順序の第１のバイト範囲をリクエストすることを決定し得る。別の例として、クライアントデバイス４０が前に、セグメントのＮ番目のバイト範囲をリクエストしていた場合、クライアントデバイス４０は、セグメントのＮ＋１番目のバイト範囲をリクエストすることを決定し得る。クライアントデバイス４０はまた、選択された表現についてのベースＵＲＬとセグメント識別子とを特定し得る（２３８）。たとえば、上記で説明したように、ベースＵＲＬは、「ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍ／ＴＲＯＮ／」に対応し、セグメント識別子は、数字、アルファベット、英数字、または現在のセグメントを表す他の値を備え得る。セグメント識別子は、セグメントと、セグメントが内包される選択された表現とを識別することができる。たとえば、セグメント識別子は、選択された表現の帯域幅および／またはインデックスを指定する値のほか、選択された表現のセグメントを指定する値を含む。
[0190]このようにして、ベースＵＲＬおよびセグメント識別子はともに、次のバイト範囲を取り出すためにクライアントデバイス４０が最終的にＨＴＴＰ ＧＥＴリクエストに含めることになる、ＵＲＬの第１の部分を形成し得る。クライアントデバイス４０は、セグメントＩＤと、リクエストされるバイト範囲の識別子とをベースＵＲＬに付加して（２４０）、ＨＴＴＰ ＧＥＴリクエストに含まれるＵＲＬを形成し得る。たとえば、セグメントが「ｓｅｇｍｅｎｔ．１０００．２７」を使用して識別されると仮定し、リクエストされるバイト範囲がバイト４３５２９１〜５６０８２９であると仮定すると、クライアントデバイス４０は、「ｓｅｇｍｅｎｔ．１０００．２７／４３５２９１／５６０８２９」をベースＵＲＬに付加し、この例では次のＵＲＬ、すなわち、「ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍ／ＴＲＯＮ／ｓｅｇｍｅｎｔ．１０００．２７／４３５２９１／５６０８２９」を形成する。このＵＲＬは、ＵＲＬのファイルパス部分に対応する。ＵＲＬの別の部分は、プロトコル、たとえば「ＨＴＴＰ／１．１」、または対応するファイルパスにおいてファイルを取り出すための他のデータを指定することができる。
[0191]次いでクライアントデバイス４０は、構成されたＵＲＬを含むＨＴＴＰ ＧＥＴリクエストを形成し得る（２４２）。たとえば、クライアントデバイス４０は、コマンド「ＧＥＴ」をＵＲＬの前に付加し、「ＨＴＴＰ／１．１」をＵＲＬの後に付加すること、およびマルチメディアコンテンツのホスト、たとえば「ｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍ」を指定することによって、リクエストがＧＥＴリクエストであることを指定する。いくつかの例では、クライアントデバイス４０は、たとえば本開示の拡張ヘッダ「Ｘ−Ｄａｓｈ−Ｂｙｔｅ−Ｒａｎｇｅ−ＵＲＬ」を使用することによって、バイト範囲がＵＲＬに含まれることを示す指示を含むようにリクエストを形成する。このようにして、バイト範囲を指定するＵＲＬを有する構成されたＧＥＴリクエストは、以下に対応し得る。
Figure 0006316781
[0192]次いでクライアントデバイス４０は、形成されたＨＴＴＰ ＧＥＴリクエストをサーバ、たとえばｗｗｗ．ｍｐ４ｐｌａｙｅｒ．ｃｏｍに送り得る（２４４）。上述のように、中間ネットワークデバイスは、図７の方法と同様の方法を実行して、ファイルパス部分にバイト範囲を指定するＵＲＬを含むＨＴＴＰ ＧＥＴリクエストを形成し得る。概して、中間ネットワークデバイスは、サーバデバイスからマルチメディアコンテンツについてのＵＲＬテンプレートを特定するためのＭＰＤファイルを受信し、クライアントデバイスから従来型のＨＴＴＰ部分ＧＥＴリクエストを受信し得る。次いで中間ネットワークデバイスは（バイト範囲テンプレートを含む）ＵＲＬテンプレートを使用して、部分ＧＥＴリクエストによって示されるバイト範囲を指定するＵＲＬをＨＴＴＰ ＧＥＴリクエストが含むように、部分ＧＥＴリクエストからＨＴＴＰ ＧＥＴリクエストを形成し得る。
[0193]このようにして、図７の方法は、マルチメディアデータを取り出すための方法の一例を表す。図７の例示的な方法は、ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、ソースデバイスの要求に従ってファイルとバイト範囲とをユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定するＵＲＬを形成することと、ソースデバイスに対して、形成されたＵＲＬを指定するＧＥＴリクエストを出すことと、を含む。
[0194]図８は、中間ネットワークデバイスを介してクライアントデバイスとサーバデバイスとの間でＨＴＴＰ ＧＥＴリクエストが交換される例示的な方法を示すフローチャートである。この例示的な方法は、クライアントデバイス４０、プロキシキャッシュデバイス８２、およびサーバデバイス６０に関して説明されるが、他のデバイスが同様の方法を実行するように構成され得ることを理解されたい。
[0195]図８の例では、クライアントデバイス４０が、マルチメディアコンテンツの表現を選択する（２５０）。次いでクライアントデバイス４０は、ＨＴＴＰ ＧＥＴリクエストがリクエストのＵＲＬにバイト範囲を指定するように、ＵＲＬテンプレートに従ってＨＴＴＰ ＧＥＴリクエストを形成する（２５２）。ＵＲＬテンプレートは、ＵＲＬのバイト範囲テンプレートについてのデータを含み得る。いくつかの例では、クライアントデバイス４０は、たとえば本開示の拡張ヘッダ「Ｘ−Ｄａｓｈ−Ｂｙｔｅ−Ｒａｎｇｅ−ＵＲＬ」を使用することによって、バイト範囲がＵＲＬに含まれることを示す指示を含むようにリクエストを形成し得る。リクエストを形成した後に、クライアントデバイス４０は、ＨＴＴＰ ＧＥＴリクエストをサーバデバイス６０にサブミットし得る（２５４）。
[0196]図２に示すように、この例では、クライアントデバイス４０とサーバデバイス６０との間のネットワークルート上にプロキシキャッシュデバイス８２がある。したがって、プロキシキャッシュデバイス８２は、クライアントデバイス４０によって出されたリクエストを受信し得る（２５６）。プロキシキャッシュデバイス８２は、リクエストのＵＲＬを分析することによって、リクエストがバイト範囲についてのリクエストであると決定し、サーバデバイス６０にリクエストを転送し得る（２５８）。代替的に、プロキシキャッシュデバイス８２は、拡張ヘッダ「Ｘ−Ｄａｓｈ−Ｂｙｔｅ−Ｒａｎｇｅ−ＵＲＬ」を検出すると、リクエストがバイト範囲についてのリクエストであると決定し得る。サーバデバイス６０は最終的にリクエストを受信し（２６０）、リクエストされたバイト範囲を送り得る（２６２）。すなわち、サーバデバイス６０は、クライアントデバイス４０に対し、マルチメディアコンテンツの表現のそれぞれのセグメントから、リクエストされたバイト範囲に対応するデータを提供する。
[0197]ここでも、クライアントデバイス４０とサーバデバイス６０との間のルート上にプロキシキャッシュデバイス８２が位置することから、プロキシキャッシュデバイス８２は、リクエストされたバイト範囲のデータを受信し得る（２６４）。次いでプロキシキャッシュデバイス８２は受信されたデータを、対応するマルチメディアコンテンツの任意の以前キャッシュされたデータに追加し得る（２６６）。データがまだ受信されていなかった場合、プロキシキャッシュデバイス８２は、マルチメディアコンテンツについての新しい局所的にキャッシュされたデータセットを形成し得る。プロキシキャッシュデバイス８２はまた、マルチメディアコンテンツについての後に受信されたデータを、マルチメディアコンテンツについての現在キャッシュされたデータと結び付けることができる。プロキシキャッシュデバイス８２はまた、クライアントデバイス４０に対しバイト範囲の受信されたデータを送り得る（２６８）。そして、クライアントデバイス４０は、受信されたデータをバッファリングし、復号し、表示し得る（２７０）。
[0198]図７に関して述べたように、いくつかの例では、中間ネットワークデバイスは、部分ＧＥＴリクエストを、バイト範囲を指定するＵＲＬを含むＨＴＴＰ ＧＥＴリクエストに変換するように構成され得る。そうするために、クライアントデバイス４０は、ステップ２５２のＨＴＴＰ ＧＥＴリクエストの代わりに部分ＧＥＴリクエストを作成する。次いでプロキシキャッシュデバイス８２は、たとえばＵＲＬ Ｔｅｍｐｌａｔｅおよびバイト範囲テンプレートに従って、ステップ２５６とステップ２５８との間で、部分ＧＥＴリクエストを変換し得る。代替的に、プロキシキャッシュデバイス８２は、本開示の技法に従って、検出された「Ｒａｎｇｅ：」ヘッダを新しい拡張ヘッダ「Ｘ−Ｄａｓｈ−ＢｙｔｅＲａｎｇｅ−ＵＲＬ」に変換し、部分ＧＥＴリクエストの当初指定されたバイト範囲がこれに続き得る。
[0200]図９は、マルチメディアコンテンツのデータの取出し元となるＣＤＮを特定するための例示的な方法を示すフローチャートである。図９は、１つの例示的な方法を表すにすぎない。上述のように、たとえば、リダイレクションサーバデバイスを使用せずにＣＤＮを選択するための他の方法も可能である。たとえば、クライアントデバイス４０は、リダイレクションサーバデバイスの代わりに選択基準を受信し評価するように構成され得る。例として、図９の方法について、クライアントデバイス４０およびリダイレクションサーバデバイス９４に関して説明する。
[0201]この例では、クライアントデバイス４０がすでにＭＰＤファイルを受信していると仮定すると、クライアントデバイス４０は、ＰＯＳＴメッセージをリダイレクションサーバデバイス９４に送る（３００）。マルチメディアコンテンツについてのＭＰＤファイルは、リダイレクションＵＲＬにリダイレクションサーバデバイス９４のアドレスを指定し得る。したがって、クライアントデバイス４０は、ＰＯＳＴメッセージをリダイレクションＵＲＬに送って、ＰＯＳＴメッセージを最終的にリダイレクションサーバデバイス９４に到達させることができる。
[0202]リダイレクションサーバデバイス９４は、ポストメッセージを受信し得る（３０２）。応答して、リダイレクションサーバデバイス９４は、ＣＤＮを選択するための選択基準を評価すし得る（３０４）。選択基準は、重み付けランダム基準、時刻、クライアントデバイス４０とＣＤＮとの間の往復遅延、クライアントデバイス４０とＣＤＮとの間のホップカウント、クライアントデバイス４０およびＣＤＮのロケーション、または他の基準のいずれかまたはすべてを含み得る。選択基準を評価することによって、リダイレクションサーバデバイス９４は、選択基準からＣＤＮを決定し得る（３０６）。その上、リダイレクションサーバデバイス９４は、ＣＤＮの各々におけるマルチメディアコンテンツについてのベースＵＲＬを表すデータで構成され得る。したがって、リダイレクションサーバデバイス９４は、決定されたＣＤＮについてのベースＵＬＲを決定し得る（３０８）。
[0203]次いでリダイレクションサーバデバイス９４は、決定されたベースＵＲＬをクライアントデバイス４０に送ることができる（３１０）。したがって、クライアントデバイス４０は、受信されたベースＵＲＬを指定し得る、特定のバイト範囲を指定するＨＴＴＰ
ＧＥＴリクエストを形成することができる（３１２）。さらに、クライアントデバイス４０は、新しいベースＵＲＬ（３１４）へのＨＴＴＰ ＧＥＴリクエストを送り、決定されたＣＤＮにＨＴＴＰ ＧＥＴリクエストを送る。すなわち、クライアントデバイス４０は、ベースＵＲＬに対してドメインネームサービス（ＤＮＳ）探索を実行して、ＧＥＴリクエストを出す際の宛先となるＣＤＮのデバイスのＩＰアドレスを決定し、次いで、決定されたＩＰアドレスにＧＥＴリクエストを送り得る。その後、ＣＤＮは、選択されたバイト範囲をもつＧＥＴリクエストに応答し、クライアントデバイス４０は、一連のバイト範囲リクエストを同じＣＤＮにサブミットし続けることができる。
[0204]１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
[0205]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
[0206]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
[0207]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
[0208]様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内にある。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
マルチメディアデータを取り出す方法であって、
ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、
前記ソースデバイスの要求に従って前記ファイルと前記バイト範囲とを、テンプレートに従ってユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定する前記ＵＲＬを形成することと、
前記ソースデバイスに対して前記形成されたＵＲＬを指定するＧＥＴリクエストを出すことと、
を備える方法。
［Ｃ２］
前記マルチメディアコンテンツのマニフェストファイルを受信することをさらに備え、
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定することは、前記複数のバイト範囲から前記表現の前記バイト範囲を選択することを備える、Ｃ１に記載の方法。
［Ｃ３］
セグメントインデックスデータ構造を備える前記表現のデータを受信することをさらに備え、前記セグメントインデックスデータ構造は、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定することは、前記複数のバイト範囲から前記表現の前記バイト範囲を選択することを備える、Ｃ１に記載の方法。
［Ｃ４］
前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、Ｃ１に記載の方法。
［Ｃ５］
前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲のロケーションを示す拡張ヘッダを含めるように前記ＧＥＴリクエストを形成することをさらに備える、Ｃ１に記載の方法。
［Ｃ６］
複数のコンテンツ配信ネットワーク（ＣＤＮ）のうちの１つを選択するための１つまたは複数の選択基準を受信することと、
前記選択基準に基づいて前記複数のＣＤＮから１つのＣＤＮを選択することと、
をさらに備え、
前記ＧＥＴリクエストを出すことは、前記選択されたＣＤＮに対して前記ＧＥＴリクエストを出すことを備え、
前記テンプレートに従って前記ＵＲＬを形成することは、前記選択されたＣＤＮに固有のバイト範囲テンプレートに従って前記ＵＲＬを形成することを備える、Ｃ１に記載の方法。
［Ｃ７］
前記データの取出し元となる複数のコンテンツ配信ネットワーク（ＣＤＮ）のうちの１つを決定するために、リダイレクションＵＲＬにＰＯＳＴメッセージをサブミットすることと、
前記ＰＯＳＴメッセージに応答して、前記複数のＣＤＮのうちの１つについてのベースＵＲＬの指示を受信することと、
をさらに備え、
前記ＵＲＬを形成することは、前記複数のＣＤＮのうちの前記１つについての前記受信されたベースＵＲＬを指定するように前記ＵＲＬを形成することを備え、
前記テンプレートに従って前記ＵＲＬを形成することは、前記選択されたＣＤＮに固有のバイト範囲テンプレートに従って前記ＵＲＬを形成することを備え、
前記ＧＥＴリクエストを出すことは、前記複数のＣＤＮのうちの前記１つに対して前記ＧＥＴリクエストを出すことを備える、Ｃ１に記載の方法。
［Ｃ８］
前記ＰＯＳＴメッセージをサブミットすることは、ジオロケーション情報、ホップカウント、およびローカル時刻のうちの１つまたは複数を含むローカル情報と、ＢａｓｅＵＲＬ、および選択基準のうちの１つまたは複数を示す１つまたは複数のＰＯＳＴメッセージを前記リダイレクションＵＲＬにサブミットすることを備える、Ｃ７に記載の方法。
［Ｃ９］
前記ソースデバイスから前記テンプレートを示す情報を受信することをさらに備える、Ｃ１に記載の方法。
［Ｃ１０］
決定することは、クライアントデバイスによって決定することを備え、
形成することは、前記クライアントデバイスによって形成することを備え、
出すことは、前記クライアントデバイスによって出すことを備える、Ｃ１に記載の方法。
［Ｃ１１］
マルチメディアデータについての情報を受信するためのデバイスであって、
ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定することと、前記ソースデバイスの要求に従って前記ファイルと前記バイト範囲とを、テンプレートに従ってユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定する前記ＵＲＬを形成することと、前記ソースデバイスに対して前記形成されたＵＲＬを指定するＧＥＴリクエストを出すことと、を行うように構成された１つまたは複数のプロセッサを備えるデバイス。
［Ｃ１２］
前記１つまたは複数のプロセッサは、前記マルチメディアコンテンツのマニフェストファイルを受信するようにさらに構成され、前記マニフェストファイルは、前記表現にリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定するために、前記１つまたは複数のプロセッサは、前記複数のバイト範囲から前記表現の前記バイト範囲を選択するように構成される、Ｃ１１に記載のデバイス。
［Ｃ１３］
前記１つまたは複数のプロセッサは、セグメントインデックスデータ構造を備える前記表現のデータを受信するようにさらに構成され、前記セグメントインデックスデータ構造は、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定するために、前記１つまたは複数のプロセッサは、前記複数のバイト範囲から前記表現の前記バイト範囲を選択するように構成される、Ｃ１１に記載のデバイス。
［Ｃ１４］
前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、Ｃ１１に記載のデバイス。
［Ｃ１５］
前記１つまたは複数のプロセッサは、前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲のロケーションを示す拡張ヘッダを含めるように前記ＧＥＴリクエストを形成するようにさらに構成される、Ｃ１１に記載のデバイス。
［Ｃ１６］
前記１つまたは複数のプロセッサは、複数のコンテンツ配信ネットワーク（ＣＤＮ）のうちの１つを選択するための１つまたは複数の選択基準を受信することと、前記選択基準に基づいて前記複数のＣＤＮから１つのＣＤＮを選択することと、前記選択されたＣＤＮに対して前記ＧＥＴリクエストを出すこととを行うようにさらに構成され、前記テンプレートは、前記選択されたＣＤＮに固有のバイト範囲テンプレートを備える、Ｃ１１に記載のデバイス。
［Ｃ１７］
前記デバイスは、
集積回路、
マイクロプロセッサ、および
前記１つまたは複数のプロセッサを含むワイヤレス通信デバイスのうちの少なくとも１つを備える、Ｃ１１に記載のデバイス。
［Ｃ１８］
マルチメディアデータを取り出すためのデバイスであって、
ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定する手段と、
前記ソースデバイスの要求に従って前記ファイルと前記バイト範囲とを、テンプレートに従ってユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定する前記ＵＲＬを形成する手段と、
前記ソースデバイスに対して前記形成されたＵＲＬを指定するＧＥＴリクエストを出す手段と、
を備えるデバイス。
［Ｃ１９］
前記マルチメディアコンテンツのマニフェストファイルを受信する手段をさらに備え、
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定する前記手段は、前記複数のバイト範囲から前記表現の前記バイト範囲を選択する手段を備える、Ｃ１８に記載のデバイス。
［Ｃ２０］
セグメントインデックスデータ構造を備える前記表現のデータを受信する手段をさらに備え、前記セグメントインデックスデータ構造は、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、前記バイト範囲を決定する前記手段は、前記複数のバイト範囲から前記表現の前記バイト範囲を選択する手段を備える、Ｃ１８に記載のデバイス。
［Ｃ２１］
前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、Ｃ１８に記載のデバイス。
［Ｃ２２］
前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲のロケーションを示す拡張ヘッダを含めるように前記ＧＥＴリクエストを形成する手段をさらに備える、Ｃ１８に記載のデバイス。
［Ｃ２３］
複数のコンテンツ配信ネットワーク（ＣＤＮ）のうちの１つを選択するための１つまたは複数の選択基準を受信する手段と、
前記選択基準に基づいて前記複数のＣＤＮから１つのＣＤＮを選択する手段と、をさらに備え、
前記ＧＥＴリクエストを出す前記手段は、前記選択されたＣＤＮに対して前記ＧＥＴリクエストを出す手段を備え、
前記テンプレートに従って前記ＵＲＬを形成する前記手段は、前記選択されたＣＤＮに固有のバイト範囲テンプレートに従って前記ＵＲＬを形成する手段を備える、Ｃ１８に記載のデバイス。
［Ｃ２４］
実行されたときに、マルチメディアデータを取り出すためのデバイスの１つまたは複数のプロセッサに、
ソースデバイスに対してリクエストするマルチメディアコンテンツの表現のファイルのバイト範囲を決定させ、
前記ソースデバイスの要求に従って前記ファイルと前記バイト範囲とを、テンプレートに従ってユニフォームリソースロケータ（ＵＲＬ）のファイルパス部分に指定する前記ＵＲＬを形成させ、
前記ソースデバイスに対して前記形成されたＵＲＬを指定するＧＥＴリクエストを出させる命令を記憶したコンピュータ可読媒体を備えるコンピュータプログラム製品。
［Ｃ２５］
前記プロセッサに、前記マルチメディアコンテンツのマニフェストファイルを受信させる命令をさらに備え、前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定し、
前記プロセッサに、前記バイト範囲を決定させる前記命令は、前記プロセッサに、前記複数のバイト範囲から前記表現の前記バイト範囲を選択させる命令を備える、Ｃ２４に記載のコンピュータプログラム製品。
［Ｃ２６］
前記プロセッサに、セグメントインデックスデータ構造を備える前記表現のデータを受信させる命令をさらに備え、前記セグメントインデックスデータ構造は、前記表現にリクエストされ得る複数のバイト範囲を指定し、
前記プロセッサに、前記バイト範囲を決定させる前記命令は、前記プロセッサに、前記複数のバイト範囲から前記表現の前記バイト範囲を選択させる命令を備える、Ｃ２４に記載のコンピュータプログラム製品。
［Ｃ２７］
前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、Ｃ２４に記載のコンピュータプログラム製品。
［Ｃ２８］
前記プロセッサに、前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲のロケーションを示す拡張ヘッダを含めるように前記ＧＥＴリクエストを形成させる命令をさらに備える、Ｃ２４に記載のコンピュータプログラム製品。
［Ｃ２９］
前記プロセッサに、
複数のコンテンツ配信ネットワーク（ＣＤＮ）のうちの１つを選択するための１つまたは複数の選択基準を受信させ、
前記選択基準に基づいて前記複数のＣＤＮから１つのＣＤＮを選択させる命令をさらに備え、
前記プロセッサに、前記ＧＥＴリクエストを出させる前記命令は、前記プロセッサに、前記選択されたＣＤＮに対して前記ＧＥＴリクエストを出させる命令を備え、
前記プロセッサに、前記テンプレートに従って前記ＵＲＬを形成させる前記命令は、前記プロセッサに、前記選択されたＣＤＮに固有のバイト範囲テンプレートに従って前記ＵＲＬを形成させる命令を備える、Ｃ２４に記載のコンピュータプログラム製品。
［Ｃ３０］
マルチメディアデータについての情報を送る方法であって、
マルチメディアコンテンツのマニフェストファイルを提供することと、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、前記リクエストの前記ＵＲＬは前記マルメディアコンテンツの表現のバイト範囲を指定し、
前記リクエストに応答して、前記リクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力することと、
を備える方法。
［Ｃ３１］
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ３０に記載の方法。
［Ｃ３２］
前記表現に対しリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供することをさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ３０に記載の方法。
［Ｃ３３］
前記リクエスト内で拡張ヘッダを受信することをさらに備え、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬ内の前記バイト範囲のロケーションを示す、Ｃ３０に記載の方法。
［Ｃ３４］
提供することは、サーバデバイスによって提供することを備え、受信することは、前記サーバデバイスによって受信することを備え、出力することは、前記サーバデバイスによって出力することを備える、Ｃ３０に記載の方法。
［Ｃ３５］
提供することは、プロキシキャッシュデバイスによって提供することを備え、受信することは、前記プロキシキャッシュデバイスによって受信することを備え、出力することは、前記プロキシキャッシュデバイスによって出力することを備える、Ｃ３０に記載の方法。
［Ｃ３６］
前記リクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記方法は、
サーバデバイスに対して前記表現の前記バイト範囲をリクエストすることと、
前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュすることと、
前記表現の前記バイト範囲についての第２の異なるリクエストを受信することと、
前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力することと、
をさらに備える、Ｃ３０に記載の方法。
［Ｃ３７］
前記リクエストは第１のリクエストを備え、前記バイト範囲は第１のバイト範囲を備え、前記方法は、
サーバデバイスに対して前記表現の前記第１のバイト範囲をリクエストすることと、
前記サーバデバイスから受信された前記第１のバイト範囲についてのデータをキャッシュすることと、
前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成された第２のＵＲＬを含む第２のリクエストを受信することと、前記第２のリクエストの前記第２のＵＲＬが前記マルチメディアコンテンツの前記表現の第２のバイト範囲を指定し、前記第２のバイト範囲は前記第１のバイト範囲の後に続き、
前記サーバデバイスに対して前記表現の前記第２のバイト範囲をリクエストすることと、
前記第１のバイト範囲についての前記キャッシュされたデータと、前記サーバデバイスから受信された前記第２のバイト範囲についてのデータとを使用して、前記表現のローカルコピーをアセンブルすることと、
をさらに備える、Ｃ３０に記載の方法。
［Ｃ３８］
前記マニフェストファイルは、前記バイト範囲テンプレートがすべてのコンテンツ配信ネットワークにグローバルに適用されることを示す、Ｃ３０に記載の方法。
［Ｃ３９］
前記バイト範囲テンプレートは、複数のバイト範囲テンプレートのうちの１つを備え、前記マニフェストファイルは、前記複数のバイト範囲テンプレートのそれぞれが、複数のコンテンツ配信ネットワークのそれぞれの１つの適用されることを示す、Ｃ３０に記載の方法。
［Ｃ４０］
マルチメディアデータについての情報を送るためのデバイスであって、
マルチメディアコンテンツのマニフェストファイルを提供することと、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、前記リクエストの前記ＵＲＬは前記マルメディアコンテンツの表現のバイト範囲を指定し、
前記リクエストに応答して、前記リクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力することと、
を行うように構成された１つまたは複数のプロセッサを備えるデバイス。
［Ｃ４１］
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ４０に記載のデバイス。
［Ｃ４２］
前記１つまたは複数のプロセッサは、前記表現に対しリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供するように構成され、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ４０に記載のデバイス。
［Ｃ４３］
前記１つまたは複数のプロセッサは、前記リクエスト内で拡張ヘッダを受信するように構成され、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬ内の前記バイト範囲のロケーションを示す、Ｃ４０に記載のデバイス。
［Ｃ４４］
前記デバイスは、サーバデバイスおよびプロキシキャッシュデバイスのうちの少なくとも１つを備える、Ｃ４０に記載のデバイス。
［Ｃ４５］
前記リクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記１つまたは複数のプロセッサは、
サーバデバイスに対して前記表現の前記バイト範囲をリクエストすることと、
前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュすることと、
前記表現の前記バイト範囲についての第２の異なるリクエストを受信することと、
前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力することと、
を行うようにさらに構成される、Ｃ４０に記載のデバイス。
［Ｃ４６］
前記デバイスは、
集積回路、
マイクロプロセッサ、および
前記１つまたは複数のプロセッサを含むワイヤレス通信デバイスのうちの少なくとも１つを備える、Ｃ４０に記載のデバイス。
［Ｃ４７］
マルチメディアデータについての情報を送るためのデバイスであって、
マルチメディアコンテンツのマニフェストファイルを提供する手段と、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信する手段と、前記リクエストの前記ＵＲＬは前記マルメディアコンテンツの表現のバイト範囲を指定し、
前記リクエストに応答して、前記リクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力する手段と、
を備えるデバイス。
［Ｃ４８］
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ４７に記載のデバイス。
［Ｃ４９］
前記表現にリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供する手段をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ４７に記載のデバイス。
［Ｃ５０］
前記リクエスト内で拡張ヘッダを受信する手段をさらに備え、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬ内の前記バイト範囲のロケーションを示す、Ｃ４７に記載のデバイス。
［Ｃ５１］
前記リクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記デバイスは、
サーバデバイスに対して前記表現の前記バイト範囲をリクエストする手段と、
前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュする手段と、
前記表現の前記バイト範囲についての第２の異なるリクエストを受信する手段と、
前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力する手段と、
をさらに備える、Ｃ４７に記載のデバイス。
［Ｃ５２］
実行されたときに、マルチメディアデータを提供するためのデバイスの１つまたは複数のプロセッサに、
マルチメディアコンテンツのマニフェストファイルを提供することと、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内にバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むリクエストを受信することと、前記リクエストの前記ＵＲＬは前記マルメディアコンテンツの表現のバイト範囲を指定し、
前記リクエストに応答して、前記リクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力することと、
を行わせる命令を記憶したコンピュータ可読記憶媒体を備えるコンピュータプログラム製品。
［Ｃ５３］
前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ５２に記載のコンピュータプログラム製品。
［Ｃ５４］
前記プロセッサに、前記表現に対しリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供させる命令をさらに備え、前記リクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、Ｃ５２に記載のコンピュータプログラム製品。
［Ｃ５５］
前記プロセッサに、前記リクエスト内で拡張ヘッダを受信させる命令をさらに備え、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬ内の前記バイト範囲のロケーションを示す、Ｃ５２に記載のコンピュータプログラム製品。
［Ｃ５６］
前記リクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記コンピュータプログラム製品は、前記プロセッサに、
サーバデバイスに対して前記表現の前記バイト範囲をリクエストすることと、
前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュすることと、
前記表現の前記バイト範囲についての第２の異なるリクエストを受信することと、
前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力することと、
を行わせる命令をさらに備える、Ｃ５２に記載のコンピュータプログラム製品。

Claims (51)

  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. 前記デバイスは、
    集積回路、
    マイクロプロセッサ、および
    前記１つまたは複数のプロセッサを含むワイヤレス通信デバイス
    のうちの少なくとも１つを備える、請求項３５に記載のデバイス。
  42. マルチメディアデータについての情報を送るためのデバイスであって、
    マルチメディアコンテンツのマニフェストファイルを提供する手段と、前記マニフェストファイルは、前記マルチメディアコンテンツの特性の異なる複数の表現についての記述を含み、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内に前記複数の表現から選択された１つの表現のファイルについてのバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
    前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むＧＥＴリクエストを受信する手段と、前記ＧＥＴリクエストの前記ＵＲＬは前記マルチメディアコンテンツの前記表現の前記ファイルのバイト範囲を指定し、前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、
    前記ＧＥＴリクエストに応答して、前記ＧＥＴリクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力する手段と、
    を備え、
    前記バイト範囲テンプレートは、複数のコンテンツ配信ネットワークのそれぞれに対応する複数のバイト範囲テンプレートのうちの１つを備える、デバイス。
  43. 前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記ＧＥＴリクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、請求項４２に記載のデバイス。
  44. 前記表現にリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供する手段をさらに備え、前記ＧＥＴリクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、請求項４２に記載のデバイス。
  45. 前記ＧＥＴリクエスト内で拡張ヘッダを受信する手段をさらに備え、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲が埋め込まれていることを示す、請求項４２に記載のデバイス。
  46. 前記ＧＥＴリクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記デバイスは、
    サーバデバイスに対して前記表現の前記バイト範囲をリクエストする手段と、
    前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュする手段と、
    前記表現の前記バイト範囲についての第２の異なるリクエストを受信する手段と、
    前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力する手段と、
    をさらに備える、請求項４２に記載のデバイス。
  47. 実行されたときに、マルチメディアデータを提供するためのデバイスの１つまたは複数のプロセッサに、
    マルチメディアコンテンツのマニフェストファイルを提供することと、前記マニフェストファイルは、前記マルチメディアコンテンツの特性の異なる複数の表現についての記述を含み、前記マニフェストファイルは、ユニフォームリソースロケータ（ＵＲＬ）テンプレートとバイト範囲テンプレートとを指定し、前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートは、ＵＲＬ内に前記複数の表現から選択された１つの表現のファイルのバイト範囲リクエストを含めるように前記ＵＲＬを形成するためのテンプレートを提供し、
    前記ＵＲＬテンプレートおよび前記バイト範囲テンプレートに従って構成されたＵＲＬを含むＧＥＴリクエストを受信することと、前記ＧＥＴリクエストの前記ＵＲＬは前記マルチメディアコンテンツの前記表現の前記ファイルのバイト範囲を指定し、前記ＧＥＴリクエストは「Ｒａｎｇｅ：」ヘッダを含まない、
    前記ＧＥＴリクエストに応答して、前記ＧＥＴリクエストの前記バイト範囲に対応する前記表現のマルチメディアデータを出力することと、
    を行わせる命令を記憶し、
    前記バイト範囲テンプレートは、複数のコンテンツ配信ネットワークのそれぞれに対応する複数のバイト範囲テンプレートのうちの１つを備える、コンピュータ可読記憶媒体。
  48. 前記マニフェストファイルは、前記表現に対しリクエストされ得る複数のバイト範囲を指定する情報をさらに備え、前記ＧＥＴリクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、請求項４７に記載のコンピュータ可読記憶媒体。
  49. 前記プロセッサに、前記表現に対しリクエストされ得る複数のバイト範囲を指定するセグメントインデックスデータ構造を提供させる命令をさらに備え、前記ＧＥＴリクエストの前記ＵＲＬによって指定された前記バイト範囲は、前記複数のバイト範囲のうちの１つを備える、請求項４７に記載のコンピュータ可読記憶媒体。
  50. 前記プロセッサに、前記ＧＥＴリクエスト内で拡張ヘッダを受信させる命令をさらに備え、前記拡張ヘッダは、前記ＧＥＴリクエストの前記ＵＲＬに前記バイト範囲が埋め込まれていることを示す、請求項４７に記載のコンピュータ可読記憶媒体。
  51. 前記ＧＥＴリクエストは、前記マルチメディアコンテンツの前記表現の前記バイト範囲についての第１のリクエストを備え、前記コンピュータ可読記憶媒体は、前記プロセッサに、
    サーバデバイスに対して前記表現の前記バイト範囲をリクエストすることと、
    前記サーバデバイスから受信された前記バイト範囲についてのデータをキャッシュすることと、
    前記表現の前記バイト範囲についての第２の異なるリクエストを受信することと、
    前記第２のリクエストに応答して、前記表現の前記バイト範囲についての前記キャッシュされたデータを出力することと、
    を行わせる命令をさらに備える、請求項４７に記載のコンピュータ可読記憶媒体。
JP2015160180A 2011-04-07 2015-08-14 バイト範囲リクエストを使用したビデオデータのネットワークストリーミング Active JP6316781B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161473105P 2011-04-07 2011-04-07
US61/473,105 2011-04-07
US13/439,556 US8849950B2 (en) 2011-04-07 2012-04-04 Network streaming of video data using byte range requests
US13/439,556 2012-04-04

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2014503995A Division JP2014515144A (ja) 2011-04-07 2012-04-05 バイト範囲リクエストを使用したビデオデータのネットワークストリーミング

Publications (2)

Publication Number Publication Date
JP2016028474A JP2016028474A (ja) 2016-02-25
JP6316781B2 true JP6316781B2 (ja) 2018-04-25

Family

ID=46966958

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2014503995A Withdrawn JP2014515144A (ja) 2011-04-07 2012-04-05 バイト範囲リクエストを使用したビデオデータのネットワークストリーミング
JP2015160180A Active JP6316781B2 (ja) 2011-04-07 2015-08-14 バイト範囲リクエストを使用したビデオデータのネットワークストリーミング

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2014503995A Withdrawn JP2014515144A (ja) 2011-04-07 2012-04-05 バイト範囲リクエストを使用したビデオデータのネットワークストリーミング

Country Status (14)

Country Link
US (1) US8849950B2 (ja)
EP (1) EP2695355B1 (ja)
JP (2) JP2014515144A (ja)
KR (1) KR101548444B1 (ja)
CN (1) CN103460667B (ja)
BR (1) BR112013025351B1 (ja)
DK (1) DK2695355T3 (ja)
ES (1) ES2716274T3 (ja)
HU (1) HUE042019T2 (ja)
PL (1) PL2695355T3 (ja)
PT (1) PT2695355T (ja)
SI (1) SI2695355T1 (ja)
TW (1) TWI465088B (ja)
WO (1) WO2012138895A1 (ja)

Families Citing this family (139)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
EP1999883A4 (en) 2006-03-14 2013-03-06 Divx Llc FEDERATED DIGITAL RIGHTS MANAGEMENT SYSTEM COMPRISING CONFIDENCE SYSTEMS
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
EP4213033A1 (en) 2007-01-05 2023-07-19 DivX, LLC Video distribution system including progressive playback
US8233768B2 (en) 2007-11-16 2012-07-31 Divx, Llc Hierarchical and reduced index structures for multimedia files
US8156089B2 (en) 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
US8099473B2 (en) 2008-12-31 2012-01-17 Apple Inc. Variant streams for real-time or near real-time streaming
US8260877B2 (en) 2008-12-31 2012-09-04 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US8930991B2 (en) * 2009-11-19 2015-01-06 Gregory Philpott System and method for delivering content to mobile devices
WO2011068668A1 (en) 2009-12-04 2011-06-09 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
CN104394487B (zh) * 2010-03-05 2018-02-06 三星电子株式会社 基于文件格式生成和再现自适应流的方法和装置
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
GB201105502D0 (en) 2010-04-01 2011-05-18 Apple Inc Real time or near real time streaming
CN102882845B (zh) 2010-04-07 2016-07-13 苹果公司 实时或准实时流传输
US8880633B2 (en) * 2010-12-17 2014-11-04 Akamai Technologies, Inc. Proxy server with byte-based include interpreter
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US8856283B2 (en) 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming
US8843586B2 (en) * 2011-06-03 2014-09-23 Apple Inc. Playlists for real-time or near real-time streaming
US8812662B2 (en) 2011-06-29 2014-08-19 Sonic Ip, Inc. Systems and methods for estimating available bandwidth and performing initial stream selection when streaming content
US9117221B2 (en) * 2011-06-30 2015-08-25 Flite, Inc. System and method for the transmission of live updates of embeddable units
KR101928910B1 (ko) 2011-08-30 2018-12-14 쏘닉 아이피, 아이엔씨. 복수의 최대 비트레이트 레벨들을 사용하여 인코딩된 비디오를 인코딩하고 스트리밍하기 위한 시스템들 및 방법들
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8806188B2 (en) 2011-08-31 2014-08-12 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming using automatically generated top level index files
US8799647B2 (en) 2011-08-31 2014-08-05 Sonic Ip, Inc. Systems and methods for application identification
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
KR102002165B1 (ko) 2011-09-28 2019-07-25 포토내이션 리미티드 라이트 필드 이미지 파일의 인코딩 및 디코딩을 위한 시스템 및 방법
EP2764432B1 (en) * 2011-10-03 2018-08-01 Affirmed Networks, Inc. Mobile content delivery
US9521439B1 (en) * 2011-10-04 2016-12-13 Cisco Technology, Inc. Systems and methods for correlating multiple TCP sessions for a video transfer
US9832095B2 (en) * 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
US8977704B2 (en) 2011-12-29 2015-03-10 Nokia Corporation Method and apparatus for flexible caching of delivered media
US20130179199A1 (en) 2012-01-06 2013-07-11 Rovi Corp. Systems and methods for granting access to digital content using electronic tickets and ticket tokens
US20130195204A1 (en) * 2012-01-19 2013-08-01 Vid Scale Inc. Methods and Systems for Video Delivery Supporting Adaptation to Viewing Conditions
US9401968B2 (en) * 2012-01-20 2016-07-26 Nokia Techologies Oy Method and apparatus for enabling pre-fetching of media
US9438883B2 (en) 2012-04-09 2016-09-06 Intel Corporation Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content
CA2870801A1 (en) 2012-04-18 2013-10-24 Mdialog Corporation Method and system for inserting content into streaming media at arbitrary time points
EP2834984B1 (en) * 2012-04-27 2016-03-30 Huawei Technologies Co., Ltd. Support for short cryptoperiods in template mode
BR122015005194A2 (pt) 2012-06-28 2019-08-20 Ericsson Ab Método e sistema para inserção de anúncio em entrega de mídia ao vivo over the top
JP6102108B2 (ja) * 2012-07-24 2017-03-29 富士通株式会社 情報処理装置、データ提供方法、及びデータ提供プログラム
EP2859742B1 (en) * 2012-08-06 2020-04-29 Huawei Technologies Co., Ltd. Method for providing a multimedia message service
US9584573B2 (en) 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
US9936267B2 (en) 2012-08-31 2018-04-03 Divx Cf Holdings Llc System and method for decreasing an initial buffering period of an adaptive streaming system
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
EP3073712B1 (en) * 2013-01-16 2019-06-19 Huawei Technologies Co., Ltd. Url parameter insertion and addition in adaptive streaming
US9801054B2 (en) 2013-01-17 2017-10-24 Intel IP Corporation Presence service using IMS based dash service
ES2645101T3 (es) * 2013-01-17 2017-12-04 Intel IP Corporation Autentificación de URL de contenidos para dash
CN108683485B (zh) * 2013-01-17 2021-03-12 苹果公司 Tdd传输的ul/dl帧资源动态配置的方法和装置
EP2932397B1 (en) * 2013-01-18 2017-08-09 Huawei Technologies Co., Ltd. Method and apparatus for performing adaptive streaming on media contents
US9961415B2 (en) 2013-01-24 2018-05-01 Google Llc Method and system for identifying events in a streaming media program
US9420019B2 (en) * 2013-01-28 2016-08-16 The Directv Group, Inc. Method and system for securing content communication in chunks from a content delivery network to a user receiving device
US9832492B2 (en) * 2013-01-29 2017-11-28 Espial Group Inc. Distribution of adaptive bit rate video streaming via hyper-text transfer protocol
US9432426B2 (en) 2013-02-04 2016-08-30 Qualcomm Incorporated Determining available media data for network streaming
EP2765781A1 (en) * 2013-02-07 2014-08-13 Thomson Licensing Method for providing targetable content in images of a video sequence and corresponding device
JP6205765B2 (ja) * 2013-03-12 2017-10-04 沖電気工業株式会社 映像配信装置、映像配信プログラム、映像配信方法及び映像配信システム
US9743326B2 (en) 2013-03-14 2017-08-22 Interdigital Patent Holdings, Inc. Anchor node selection in a distributed mobility management environment
US8984569B2 (en) 2013-03-15 2015-03-17 Echostar Technologies L.L.C. Chunking of multiple track audio for adaptive bit rate streaming
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US9854017B2 (en) * 2013-03-15 2017-12-26 Qualcomm Incorporated Resilience in the presence of missing media segments in dynamic adaptive streaming over HTTP
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9438652B2 (en) 2013-04-15 2016-09-06 Opentv, Inc. Tiered content streaming
SG11201508375VA (en) * 2013-04-19 2015-11-27 Sony Corp Information processing apparatus, content requesting method, and computer program
MX353122B (es) * 2013-04-19 2017-12-20 Sony Corp Dispositivo servidor, dispositivo del cliente, método de distribución de contenidos, y programa de computadora.
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9100687B2 (en) 2013-05-31 2015-08-04 Sonic Ip, Inc. Playback synchronization across playback devices
US9380099B2 (en) 2013-05-31 2016-06-28 Sonic Ip, Inc. Synchronizing multiple over the top streaming clients
US20140372569A1 (en) * 2013-06-14 2014-12-18 Samsung Electronics Co., Ltd. Controlling dash client rate adaptation
US9419845B2 (en) * 2013-06-27 2016-08-16 Cisco Technology, Inc. Dynamic content distribution network selection based on context from transient criteria
JP6444398B2 (ja) 2013-07-03 2018-12-26 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化コンテンツのストリーミング
US8762564B1 (en) * 2013-07-10 2014-06-24 Mdialog Corporation Method and system for dynamically selecting, assembling and inserting content into stream media
CN104427005B (zh) * 2013-08-20 2018-01-02 阿里巴巴集团控股有限公司 在cdn上实现请求精确调度的方法及系统
JP2015043486A (ja) * 2013-08-26 2015-03-05 ソニー株式会社 プロキシサーバ装置、情報処理方法、プログラム、端末装置、およびコンテンツ供給システム
JP2015049650A (ja) * 2013-08-30 2015-03-16 ソニー株式会社 サーバ装置、情報処理方法、プログラム、端末装置、およびコンテンツ供給システム
US10108692B1 (en) * 2013-10-15 2018-10-23 Amazon Technologies, Inc. Data set distribution
US9401944B2 (en) 2013-10-22 2016-07-26 Qualcomm Incorporated Layered adaptive HTTP streaming
US10841353B2 (en) 2013-11-01 2020-11-17 Ericsson Ab System and method for optimizing defragmentation of content in a content delivery network
US20150172347A1 (en) * 2013-12-18 2015-06-18 Johannes P. Schmidt Presentation of content based on playlists
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
US20160330500A1 (en) * 2014-01-10 2016-11-10 Thomson Licensing Method for obtaining network information by a client terminal configured for receiving a multimedia content divided into segments
US10165029B2 (en) * 2014-01-31 2018-12-25 Fastly Inc. Caching and streaming of digital media content subsets
US11477262B2 (en) 2014-02-13 2022-10-18 Koninklijke Kpn N.V. Requesting multiple chunks from a network node on the basis of a single request message
US10902474B2 (en) 2014-03-24 2021-01-26 Qualcomm Incorporated Targeted advertisement insertion for streaming media data
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US9860612B2 (en) * 2014-04-10 2018-01-02 Wowza Media Systems, LLC Manifest generation and segment packetization
US10523723B2 (en) 2014-06-06 2019-12-31 Koninklijke Kpn N.V. Method, system and various components of such a system for selecting a chunk identifier
US10033824B2 (en) * 2014-06-30 2018-07-24 Samsung Electronics Co., Ltd. Cache manifest for efficient peer assisted streaming
US9762937B2 (en) 2014-08-07 2017-09-12 Sonic Ip, Inc. Systems and methods for protecting elementary bitstreams incorporating independently encoded tiles
CA2953031C (en) * 2014-08-26 2023-08-08 Ctera Networks, Ltd. A method and computing device for allowing synchronized access to cloud storage systems based on stub tracking
CN104270646A (zh) * 2014-09-22 2015-01-07 何震宇 一种基于移动流媒体的自适应传输方法和系统
US10084838B2 (en) 2014-10-29 2018-09-25 DLVR, Inc. Generating and using manifest files including content delivery network authentication data
US10142386B2 (en) 2014-10-29 2018-11-27 DLVR, Inc. Determining manifest file data used in adaptive streaming video delivery
US9509742B2 (en) 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
US9813465B2 (en) * 2014-12-19 2017-11-07 Intel Corporation Network proxy for energy efficient video streaming on mobile devices
CN107111477B (zh) 2015-01-06 2021-05-14 帝威视有限公司 用于编码内容和在设备之间共享内容的系统和方法
US10218981B2 (en) * 2015-02-11 2019-02-26 Wowza Media Systems, LLC Clip generation based on multiple encodings of a media stream
US10375444B2 (en) * 2015-02-13 2019-08-06 Performance and Privacy Ireland Limited Partial video pre-fetch
US10298647B2 (en) * 2015-02-26 2019-05-21 Qualcomm Incorporated Delay compensation for broadcast adaptive bitrate streaming
EP3262523B1 (en) 2015-02-27 2019-12-04 DivX, LLC System and method for frame duplication and frame extension in live video encoding and streaming
US10528345B2 (en) * 2015-03-27 2020-01-07 Intel Corporation Instructions and logic to provide atomic range modification operations
US10291681B2 (en) * 2015-06-18 2019-05-14 Ericsson Ab Directory limit based system and method for storing media segments
KR102425517B1 (ko) * 2015-09-04 2022-07-27 삼성전자주식회사 다수 개의 무선 억세스 인터페이스들을 지원하는 이동 통신 시스템에서 데이터 업로드 장치 및 방법
US10257284B2 (en) * 2015-12-30 2019-04-09 Samsung Electronics Co., Ltd. Broadcasting local function templates to proximate mobile computing devices
CN107040505B (zh) * 2016-02-04 2021-01-26 中兴通讯股份有限公司 媒体数据传输方法及装置
US10075292B2 (en) 2016-03-30 2018-09-11 Divx, Llc Systems and methods for quick start-up of playback
CN105959362A (zh) * 2016-04-25 2016-09-21 乐视控股（北京）有限公司 Cdn服务器及其缓存数据的方法
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US10129574B2 (en) 2016-05-24 2018-11-13 Divx, Llc Systems and methods for providing variable speeds in a trick-play mode
US10432690B1 (en) * 2016-06-03 2019-10-01 Amazon Technologies, Inc. Manifest partitioning
US10116719B1 (en) 2016-06-03 2018-10-30 Amazon Technologies, Inc. Customized dash manifest
US10104143B1 (en) * 2016-06-03 2018-10-16 Amazon Technologies, Inc. Manifest segmentation
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
WO2018005666A1 (en) * 2016-06-29 2018-01-04 Amazon Technologies, Inc. Network-accessible data volume modification
US11617019B2 (en) * 2016-07-28 2023-03-28 Qualcomm Incorporated Retrieving and accessing segment chunks for media streaming
KR101863598B1 (ko) * 2016-07-29 2018-06-01 주식회사 에어브로드 스트리밍 서비스를 위한 클라이언트의 동작 방법
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US20180062935A1 (en) * 2016-08-25 2018-03-01 Futurewei Technologies, Inc. Hybrid approach with classification for name resolution and producer selection in icn
KR102381335B1 (ko) * 2016-10-18 2022-03-31 이엑스피웨이 모바일 사용자 장치들에 컨텐츠를 전송하는 방법
US10440085B2 (en) * 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming
US10476943B2 (en) 2016-12-30 2019-11-12 Facebook, Inc. Customizing manifest file for enhancing media streaming
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US10536275B2 (en) * 2017-05-10 2020-01-14 Microsoft Technology Licensing, Llc Verification of downloaded subsets of content
CN107308645B (zh) * 2017-06-07 2018-07-03 浙江无端科技股份有限公司 一种游戏透视外挂检测的方法及游戏客户端
US11252454B2 (en) 2017-06-28 2022-02-15 Telefonaktiebolaget L M Ericsson (Publ) System, devices and methods for providing stream privacy in an ABR OTT media network
CN108234638A (zh) * 2017-12-29 2018-06-29 北京奇虎科技有限公司 一种基于内容分发网络cdn的数据处理方法和装置
CN108449308B (zh) * 2018-01-18 2020-11-27 北京奇艺世纪科技有限公司 识别恶意资源访问的方法及装置
EP3750303B1 (en) * 2018-02-05 2024-04-03 Telefonaktiebolaget LM Ericsson (publ) A method, a user equipment and a computer program product for enabling a dynamic adaptive streaming over http, dash, player to fetch media segments from a network
CN110166502B (zh) * 2018-02-11 2021-06-01 中国移动通信有限公司研究院 数据获取方法、服务提供端、服务使用端及网络功能实体
US10645186B2 (en) * 2018-04-23 2020-05-05 Level 3 Communications, Llc Speculative caching in a content delivery network
CN109194966B (zh) * 2018-08-03 2021-04-27 广州酷狗计算机科技有限公司 Sei消息的有效载荷获取方法、装置和存储介质
US10863211B1 (en) * 2018-11-12 2020-12-08 Amazon Technologies, Inc. Manifest data for server-side media fragment insertion
EP3942437B1 (en) 2019-03-21 2024-01-10 DivX, LLC Systems and methods for multimedia swarms
US11789771B2 (en) 2019-09-28 2023-10-17 Tencent America LLC Method and apparatus for a step-enabled workflow
US11516152B2 (en) * 2019-09-28 2022-11-29 Tencent America LLC First-in first-out function for segmented data stream processing
US11442766B1 (en) * 2020-02-03 2022-09-13 Architecture Technology Corporation Systems and methods for open threat hunt
US11553017B1 (en) 2021-03-09 2023-01-10 Nokia Technologies Oy Timed media HTTP request aggregation
US20220360990A1 (en) * 2021-05-05 2022-11-10 Rohde & Schwarz Gmbh & Co. Kg 4g / 5g core network deep packet inspection system
US20230224523A1 (en) * 2022-01-13 2023-07-13 Mux, Inc. Method for dynamic selection of a content delivery network

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU8903498A (en) * 1997-08-11 1999-03-01 Thomas C. Amon Provider-selected message in response to user request
US6889256B1 (en) * 1999-06-11 2005-05-03 Microsoft Corporation System and method for converting and reconverting between file system requests and access requests of a remote transfer protocol
FI115418B (fi) * 2001-09-20 2005-04-29 Oplayo Oy Adaptiivinen mediavirta
JP4452032B2 (ja) * 2003-04-14 2010-04-21 日本放送協会 コンテンツ提示装置及びコンテンツ提示プログラム
US6728729B1 (en) * 2003-04-25 2004-04-27 Apple Computer, Inc. Accessing media across networks
US20050102371A1 (en) 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US20050254575A1 (en) * 2004-05-12 2005-11-17 Nokia Corporation Multiple interoperability points for scalable media coding and transmission
US20070204115A1 (en) 2006-02-28 2007-08-30 Maven Networks, Inc. Systems and methods for storage shuffling techniques to download content to a file
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US7783773B2 (en) * 2006-07-24 2010-08-24 Microsoft Corporation Glitch-free media streaming
US20100011091A1 (en) * 2008-07-10 2010-01-14 Blackwave Inc. Network Storage
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
EP2417743B1 (en) * 2009-04-09 2019-06-05 Telefonaktiebolaget LM Ericsson (publ) Methods and arrangements for creating and handling media files
US8392598B2 (en) 2009-06-15 2013-03-05 Research In Motion Limited Methods and apparatus to facilitate client controlled sessionless adaptation
US8433814B2 (en) * 2009-07-16 2013-04-30 Netflix, Inc. Digital content distribution system and method
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding

Also Published As

Publication number Publication date
TWI465088B (zh) 2014-12-11
US8849950B2 (en) 2014-09-30
DK2695355T3 (en) 2019-04-01
SI2695355T1 (sl) 2019-05-31
EP2695355B1 (en) 2018-12-19
JP2014515144A (ja) 2014-06-26
JP2016028474A (ja) 2016-02-25
TW201251406A (en) 2012-12-16
US20120259946A1 (en) 2012-10-11
CN103460667A (zh) 2013-12-18
PT2695355T (pt) 2019-04-01
KR20140004218A (ko) 2014-01-10
HUE042019T2 (hu) 2019-06-28
WO2012138895A1 (en) 2012-10-11
ES2716274T3 (es) 2019-06-11
KR101548444B1 (ko) 2015-08-28
PL2695355T3 (pl) 2019-06-28
BR112013025351B1 (pt) 2022-05-17
CN103460667B (zh) 2017-05-31
EP2695355A1 (en) 2014-02-12
BR112013025351A2 (pt) 2016-12-13

Similar Documents

Publication Publication Date Title
JP6316781B2 (ja) バイト範囲リクエストを使用したビデオデータのネットワークストリーミング
JP7142626B2 (ja) メディアストリーミングのためのセグメントチャンクの検索およびアクセス
JP5932070B2 (ja) コード化ビデオデータのネットワークストリーミングのためのメディア表現グループ
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
CN110089122B (zh) 用于检索媒体数据的方法、媒体装置及计算机可读存储媒体
TWI714602B (zh) 超級本文傳輸協定(http)上動態自適應串流(dash)客戶經驗品質度量之中間軟體傳遞
CN107810624A (zh) 用信号发送用于广播的高速缓存的段
CN110832872B (zh) 使用用于文件格式方框的通用描述符处理媒体数据
JP2016154348A (ja) コーディングされたマルチメディアデータのネットワークストリーミング中の表現の切り替え
CN112154672B (zh) 一种检索媒体数据的方法、设备及可读存储介质
US11321516B2 (en) Processing dynamic web content of an ISO BMFF web resource track
US20170041422A1 (en) Method and system for retrieving a content manifest in a network
CN110870282A (zh) 使用网络内容的文件轨处理媒体数据
JP2019525677A (ja) メディアデータストリーミングのためのｓｅｉトラックのシステムレベルシグナリング
van Brandenburg et al. Models for HTTP-adaptive-streaming-aware content distribution network interconnection (CDNI)
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
Anadiotis et al. Information‐centric networking for multimedia, social and peer‐to‐peer communications
Ciubotaru et al. Network communications protocols and services

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161101

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170704

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170927

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180227

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180328

R150 Certificate of patent or registration of utility model

Ref document number: 6316781

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250