JP2021530932A - マニフェストなしストリーミングメディアコンテンツを配信するための方法、システム、および媒体 - Google Patents

Abstract

マニフェストなしストリーミングメディアコンテンツを配信するための方法、システム、および媒体が提供される。いくつかの実施形態では、方法は、ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するステップであって、ライブストリームが、複数のフォーマットの各々のための複数のセグメントを含み、複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ステップと、URLに基づいて、ライブストリームの特定のセグメントに対して要求を解決するステップであって、解決するステップが、URLに基づいて、複数のフォーマットから要求に関連付けられたライブストリームのフォーマットを識別するステップと、URLに基づいて、要求に関連付けられたシーケンス番号を識別するステップと、識別されたフォーマットに対応し、識別されたシーケンス番号と一致するシーケンス番号を有する、複数のセグメントのうちのセグメントを識別するステップとを含む、ステップと、特定のセグメントに対応するセグメントファイルをロードするステップと、要求に対する応答において、セグメントファイルをユーザデバイスに返すステップとを含む。

Description

関連出願の相互参照
本出願は、その全体が参照により本明細書に組み込まれる、2018年9月17日に出願された米国仮特許出願第62/732,567号の利益を主張する。

開示される主題は、マニフェストなしストリーミングメディアコンテンツを配信するための方法、システム、および媒体に関する。

デジタルメディアコンテンツ共有およびインターネットネットワーキングの開発により、多くの機能がユーザエクスペリエンスを向上させることができるようになった。たとえば、インターネット上では、コンテンツホスティングウェブサイトおよびコンテンツ共有サービスは、ユーザが、オーディオ/音楽クリップ、ビデオクリップ、およびオーディオコンテンツとビデオコンテンツの組合せを含み得るデジタルメディアコンテンツをアップロード、閲覧、および共有することを可能にする。閲覧者は、プレイバックのためにコンテンツ共有サーバから閲覧デバイスにストリーミングされるメディアコンテンツを閲覧することができる。メディアコンテンツのプレイバックを中断させるバッファリングを防止するために、コンテンツはHTTPライブストリーミング(HLS)などの適応ビットレートプロトコルを用いてストリーミングされ得る。

HLSは様々なコンピューティングデバイス上でのプレイバックのためにウェブサーバからHTTPを介してオーディオおよびビデオをストリーミングするためのネットワークプロトコルであり、ストリーミングコンテンツの品質は閲覧デバイスのネットワーク接続に応じて変化し得る。しかしながら、ストリーミングメディアのための既存のHLSベースの手法は、いくつかの課題に直面している。1つの課題は高いレイテンシである。たとえば、既存のHLSベースの手法は、クライアントデバイスが任意のビデオコンテンツをプレイバックすることができる前に、クライアントデバイスがコンテンツ共有サーバに3回のラウンドトリップを行うことを必要とする。3回のラウンドトリップは、マスタープレイリストをフェッチするためのトリップと、メディアプレイリストのための別のトリップと、初期メディアセグメントのためのさらに別のトリップとを含む。そのような要件は、特にワイヤレスネットワーク上などでラウンドトリップタイム(RTT)が高い状況において、コンテンツプレイバックのレイテンシを大幅に増加させる。

HLSまたは動的適応ストリーミングオーバーHTTP(DASH:Dynamic Adaptive Streaming over HTTP)などのストリーミングメディアプレイバックのための既存の手法も、クライアントによって使用されるメディアプレイヤがストリーム選択をサポートしていないとき、ストリーム選択に対するクライアント制御に欠けている。たとえば、HLSプロトコルを使用してビデオをストリーミングするためにそのようなメディアプレイヤを使用するクライアントは、どのメディアセグメントをフェッチするかおよびいつメディアセグメントをフェッチするかを制御することができない。ストリーミングビデオが複数のビットレートまたは解像度で利用可能である場合、クライアントはマスタープレイリストURLをメディアプレイヤに提供することが必要とされ、マスタープレイリストはすべての利用可能なメディアプレイリストを含み、メディアプレイリストの各々は特定のビットレートまたは解像度におけるストリーミングビデオの表現に対応する。プレイバック中に、メディアプレイヤはプレイバックのためにストリーミングビデオのどの表現を選ぶかを決定する。

さらに、ストリーミングビデオコンテンツプレイバックのための既存の手法は、ライブビデオストリーミングをサポートするのに効率的ではない。ストリーミングメディアのライブプレイバック中に、既存のHLSベースのストリーミングビデオ手法のクライアントは、新しいメディアセグメントに対して数秒ごとにライブプレイリストを再フェッチすることが必要とされる。特に、これらのプロトコルは、クライアントがストリーミングメディアの新しいメディアセグメントを発見するために定期的にダウンロードしなければならないマニフェストファイルを包含する。定期的なマニフェストのダウンロードおよびセグメントサイズは、これらのプロトコルにおけるエンドツーエンドレイテンシ制限の例である。

したがって、マニフェストなしストリーミングメディアコンテンツを配信するための新しい方法、システム、および媒体を提供することが望ましい。

マニフェストなしストリーミングメディアコンテンツを配信するための方法、システム、および媒体が提供される。(「マニフェストなし」ストリーミングメディアコンテンツとは、クライアントがマニフェストファイルをダウンロードすることを必要とせずにストリーミングメディアコンテンツの配信が達成されることを意味する。)

開示される主題のいくつかの実施形態によれば、ライブストリーミングコンテンツを配信するための方法が提供され、方法は、ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するステップであって、ライブストリームが、複数のフォーマットの各々のための複数のセグメントを含み、複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ステップと、要求されたURLに基づいて、ライブストリームの特定のセグメントに対して要求を解決するステップであって、解決するステップが、要求されたURLに基づいて、複数のフォーマットから要求に関連付けられたライブストリームのフォーマットを識別するステップと、要求されたURLに基づいて、要求に関連付けられたシーケンス番号を識別するステップと、識別されたフォーマットに対応し、識別されたシーケンス番号と一致するシーケンス番号を有する、複数のセグメントのうちのセグメントを識別するステップとを含む、ステップと、特定のセグメントに対応するセグメントファイルをロードするステップと、要求に対する応答において、セグメントファイルをユーザデバイスに返すステップとを含む。

いくつかの実施形態では、URLはベースURLを含み、要求に関連付けられたライブストリームのフォーマットは、ベースURLに基づいて複数のフォーマットから識別される。

いくつかの実施形態では、セグメントファイルは、識別されたシーケンス番号を示すメタデータを含む。

いくつかの実施形態では、シーケンス番号は、1つまたは複数のセグメントのプレイバックに利用可能な最も最近のセグメントのための現在のヘッドシーケンス番号を判定することによって識別され、識別されたシーケンス番号は、現在のヘッドシーケンス番号であり、識別されたセグメントは、プレイバックに利用可能な最も最近のセグメントである。

いくつかの実施形態では、シーケンス番号は、URLに基づいて、ロードするのに利用可能な最も最近完成した(most recently complete)セグメントのためのシーケンス番号よりも大きい、要求に関連付けられたシーケンス番号を識別することによって識別される。

いくつかの実施形態では、方法は、セグメントファイルの1つまたは複数の部分が生成されているときに1つまたは複数の部分を反復的にロードするステップと、単一の応答において、生成された1つまたは複数の部分をユーザデバイスに反復的に返すステップとをさらに含む。

開示される主題のいくつかの実施形態によれば、ライブストリーミングコンテンツを配信するためのシステムが提供され、システムは、メモリと、メモリに結合されたハードウェアプロセッサとを備え、ハードウェアプロセッサは、ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信することであって、ライブストリームが、複数のフォーマットの各々のための複数のセグメントを含み、複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ことと、URLに基づいて、ライブストリームの特定のセグメントに対して要求を解決することであって、解決することが、URLに基づいて、複数のフォーマットから要求に関連付けられたライブストリームのフォーマットを識別することと、URLに基づいて、要求に関連付けられたシーケンス番号を識別することと、識別されたフォーマットに対応し、識別されたシーケンス番号と一致するシーケンス番号を有する、複数のセグメントのうちのセグメントを識別することとを含む、ことと、特定のセグメントに対応するセグメントファイルをロードすることと、要求に対する応答において、セグメントファイルをユーザデバイスに返すこととを行うように構成される。

開示される主題のいくつかの実施形態によれば、プロセッサによって実行されると、ライブストリーミングコンテンツを配信するための方法をプロセッサに実施させるコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体が提供され、方法は、ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するステップであって、ライブストリームが、複数のフォーマットの各々のための複数のセグメントを含み、複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ステップと、要求されたURLに基づいて、ライブストリームの特定のセグメントに対して要求を解決するステップであって、解決するステップが、要求されたURLに基づいて、複数のフォーマットから要求に関連付けられたライブストリームのフォーマットを識別するステップと、要求されたURLに基づいて、要求に関連付けられたシーケンス番号を識別するステップと、識別されたフォーマットに対応し、識別されたシーケンス番号と一致するシーケンス番号を有する、複数のセグメントのうちのセグメントを識別するステップとを含む、ステップと、特定のセグメントに対応するセグメントファイルをロードするステップと、要求に対する応答において、セグメントファイルをユーザデバイスに返すステップとを含む。開示される主題のさらなる実施形態によれば、一時的コンピュータ可読媒体または非一時的コンピュータ可読媒体であり得るコンピュータ可読媒体が提供される。コンピュータ可読媒体は、プロセッサによって実行されると、ライブストリーミングコンテンツを配信するための任意の態様または実施形態による方法をプロセッサに実施させるコンピュータ実行可能命令を含む。

開示される主題のいくつかの実施形態によれば、ライブストリーミングコンテンツを配信するためのシステムが提供され、システムは、ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するための手段であって、ライブストリームが、複数のフォーマットの各々のための複数のセグメントを含み、複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、手段と、要求されたURLに基づいて、ライブストリームの特定のセグメントに対して要求を解決するための手段であって、解決するための手段が、要求されたURLに基づいて、複数のフォーマットから要求に関連付けられたライブストリームのフォーマットを識別するための手段と、要求されたURLに基づいて、要求に関連付けられたシーケンス番号を識別するための手段と、識別されたフォーマットに対応し、識別されたシーケンス番号と一致するシーケンス番号を有する、複数のセグメントのうちのセグメントを識別するための手段とを備える、手段と、特定のセグメントに対応するセグメントファイルをロードするための手段と、要求に対する応答において、セグメントファイルをユーザデバイスに返すための手段とを備える。

開示される主題の様々な目的、特徴、および利点は、同様の参照番号が同様の要素を識別する以下の図面に関連して検討されるときに、開示される主題の以下の詳細な説明を参照すると、より完全に諒解され得る。

開示される主題のいくつかの実施形態による、マニフェストなしストリーミングメディアコンテンツを配信するための情報フロー図の一例を示す図である。 開示される主題のいくつかの実施形態による、コンテンツストリームのセグメントに対してURLの要求を解決するためのプロセスの一例を示す図である。 開示される主題のいくつかの実施形態による、コンテンツストリームの一致するセグメントを配信するための情報フロー図の一例を示す図である。 開示される主題のいくつかの実施形態による、コンテンツストリームの履歴の中の指定された時点のためのセグメントを配信するための情報フロー図の一例を示す図である。 開示される主題のいくつかの実施形態による、インクリメンタルストリーミングのための情報フロー図の一例を示す図である。 開示される主題のいくつかの実施形態による、マニフェストなしストリーミングメディアコンテンツを配信するための本明細書で説明される機構の実装に適した例示的なシステムの概略図である。 開示される主題のいくつかの実施形態による、図6のサーバおよび/またはユーザデバイスにおいて使用され得るハードウェアの詳細な例を示す図である。

様々な実施形態によれば、ストリーミングコンテンツを配信するための(方法、システム、および媒体を含むことができる)機構が提供される。いくつかの実施形態では、本明細書で説明される機構は、セグメントファイルとは別のメタデータをキャッシュするためにコンテンツ配信ネットワークレベルにおけるサポートを必要とすることなしに、任意のアプリケーションレベルのメタデータがサポートされることを可能にすることができる。追加または代替として、いくつかの実施形態では、本明細書で説明される機構は、コンテンツストリームの新しいセグメントを発見するためのメタデータおよび/または情報を含む別のマニフェストファイルの定期的な配信を必要とすることなしに、ストリーミングコンテンツの配信を可能にすることができ、それによって、エンドツーエンドレイテンシを低減する。追加または代替として、いくつかの実施形態では、本明細書で説明される機構は、ユーザデバイスがストリームの非ヘッドセグメントにアクセスすることを可能にすることができ、このことは、どのメディアセグメントをフェッチするかの制御を可能にする。

いくつかの実施形態では、本明細書で説明される機構は、ストリーミングコンテンツを配信するために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、図1に関連して以下で説明されるように、コンテンツストリームのプレイバックのためのユニフォームリソースロケータ(URL)を要求するために使用され得る。より具体的な例では、URLは、コンテンツストリームのフォーマットに対応するベースURLを含むことができる。この例を続けると、いくつかの実施形態では、URLはまた、要求に関連付けられたシーケンス番号を示すための1つまたは複数のURLパラメータを含むことができる。

いくつかの実施形態では、コンテンツストリームは、コーデックフォーマット、解像度フォーマット、オーディオフォーマット、ビデオフォーマット、および/または任意の他の適切なフォーマットなどの1つまたは複数のフォーマットにおけるプレイバックのために提供され得る。たとえば、いくつかの実施形態では、1280×720ピクセル解像度でブロードキャスタまたはコンテンツクリエイタによってアップロードされているコンテンツストリームは、720p H.264ビデオ(1280×720ピクセル)、480p H.264ビデオ(854×480ピクセル)、360p H.264ビデオ(640×360ピクセル)、240p H.264ビデオ(426×240ピクセル)、144p H.264ビデオ(256×144ピクセル)、AACオーディオのためのフォーマット、および/または任意の他の適切なフォーマットを有することができる。いくつかの実施形態では、コンテンツストリームは、プレイバックに利用可能なビデオおよび/またはオーディオのフォーマットごとにほぼ一定の持続時間の1つまたは複数のセグメントにセグメント化され得る。いくつかの実施形態では、各セグメントは数秒の持続時間または任意の他の適切な持続時間であり得る。いくつかの実施形態では、コンテンツストリームはライブストリームであり得る。

いくつかの実施形態では、ウェブサーバは、プレイバックに利用可能なコンテンツストリームのフォーマット(たとえば、コーデックフォーマット、解像度フォーマット、オーディオフォーマット、ビデオフォーマット、および/または任意の他の適切なフォーマット)ごとに1つのベースURLを提供することができる。上記の例を続けると、いくつかの実施形態では、ウェブサーバは、720p H.264ビデオ、480p H.264ビデオ、360p H.264ビデオ、240p H.264ビデオ、144p H.264ビデオ、AACオーディオ、および/または任意の他の適切なフォーマットの各々に1つのベースURLを提供することができる。いくつかの実施形態では、ベースURLは、ハイパーテキスト転送プロトコル(HTTP)、ハイパーテキスト転送プロトコルセキュア(HTTPS)プロトコル、クイックUDPインターネット接続(QUIC)プロトコル、および/または任意の他の適切なプロトコルのためのものであり得る。

いくつかの実施形態では、フォーマットごとのベースURLは、そのフォーマットについて動的に決定されたヘッドセグメントファイルを位置決めすることができる。いくつかの実施形態では、ヘッドセグメントは、ロードされるのに利用可能なライブストリームの最も最近のセグメントであり得る。いくつかの実施形態では、ベースURLの要求は、シーケンス番号によって識別された特定のセグメントに対して解決され得、シーケンス番号は、セグメントタイムラインの密な整数インデックスであり得る(「密な」インデックスはインデックス値に対してインデックスエントリが現れるインデックスである)。たとえば、いくつかの実施形態では、ストリームの1番目のセグメントはシーケンス番号0を有することができ、後に続く各セグメントは、1(または任意の他の適切な増分値)だけ増加するそのそれぞれのセグメント番号を有することができる。

いくつかの実施形態では、ユーザデバイスは、要求の中で1つまたは複数のURLパラメータをベースURLに追加することによって、ストリームの非ヘッドセグメントにアクセスすることができる。たとえば、いくつかの実施形態では、特定のコンテンツストリームを識別する「sq」パラメータをベースURLに追加することは、シーケンス番号によってそのストリームの特定のセグメントを位置決めすることができる。この例を続けると、いくつかの実施形態では、「sq=0」をベースURLに追加することは、ベースURLによって識別されたストリームの1番目のセグメントを位置決めすることができ、「sq=1」を追加することは、ストリームの2番目のセグメントを位置決めすることができる、などである。別の例として、いくつかの実施形態では、「headm」パラメータをベースURLに追加することは、ヘッドセグメントの後ろのセグメントの指定された番号である、ストリームのセグメントを位置決めすることができる。この例を続けると、いくつかの実施形態では、「headm=1」をベースURLに追加することは、ヘッドセグメントの直前にあるセグメントを位置決めすることができ、「headm=2」をベースURLに追加することは、ヘッドセグメントの2つ前のセグメントであるセグメントを位置決めすることができる、などである。いくつかの実施形態では、「headm=0」をベースURLに追加することは、いかなる「headm」パラメータも提供しないことと等価であり得る。

いくつかの実施形態では、本明細書で説明される機構は、図1および図2に関連して以下で説明されるように、コンテンツストリームのセグメントに対して要求を解決するために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、図2に関連して以下で説明されるように、URLの要求を受信する、要求に関連付けられたコンテンツストリームのフォーマットを識別する、要求に関連付けられたシーケンス番号を識別する、および/または要求に関連付けられたコンテンツストリームのセグメントを識別するために使用され得る。いくつかの実施形態では、本明細書で説明される機構は、図1に関連して以下で説明されるように、識別されたセグメントに関連付けられたセグメントファイルをロードするおよび/またはセグメントファイルを返すために使用され得る。いくつかの実施形態では、本明細書で説明される機構は、メタデータをセグメントファイルのコンテナフォーマットに埋め込むために使用され得ることに留意されたい。したがって、いくつかの実施形態では、本明細書で説明される機構は、セグメントファイルとは別のメタデータをキャッシュするためにコンテンツ配信ネットワークレベルにおけるサポートを必要とすることなしに、任意のアプリケーションレベルのメタデータがサポートされることを可能にすることができる。加えて、いくつかの実施形態では、本明細書で説明される機構は、コンテンツストリームの新しいセグメントを発見するためのメタデータおよび/または情報を含む別のマニフェストファイルの定期的な配信を必要とすることなしに、ストリーミングコンテンツの配信を可能にすることができ、それによって、エンドツーエンドレイテンシを低減する。

いくつかの実施形態では、本明細書で説明される機構は、コンテンツストリームの一致するセグメントを配信するために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、コンテンツ配信ネットワークから受信されたコンテンツストリームのセグメント間の不一致を検出するために、たとえば、図3に関連して以下で説明されるように、(オーディオセグメントファイルなどの)ストリームのあるファイルのセグメントのためのシーケンス番号と、(ビデオセグメントファイルなどの)ストリームの別のファイルのセグメントのためのシーケンス番号との間の不一致を検出するために使用され得る。いくつかの実施形態では、本明細書で説明される機構は、図3に関連して以下で説明されるように、コンテンツストリームの次のセグメントのための1つもしくは複数のURLを要求するおよび/または1つもしくは複数の対応するセグメントファイルを返すために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、図3に関連して以下で説明されるように、まだ生成されていないセグメントの要求に応答する前に、所定の時間待つために使用され得る。したがって、いくつかの実施形態では、本明細書で説明される機構は、プレイヤアプリケーションが、次のセグメントが存在する前に次のセグメントの要求を出すことを可能にすることができ、それによって、ネットワーク要求レイテンシの寄与を低減および/または排除し、このことはエンドツーエンドレイテンシを低減することができる。

いくつかの実施形態では、本明細書で説明される機構は、コンテンツストリームの履歴の中の指定された時点のためのセグメントを配信するために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、図3に関連して以下で説明されるように、コンテンツストリームのタイムライン表現に関連付けられたユーザ入力および/または任意の他の適切な入力などの、コンテンツストリームの履歴の中の時点を探すための入力を検出するために使用され得る。いくつかの実施形態では、本明細書で説明される機構は、図3に関連して以下で説明されるように、コンテンツストリームの履歴の中の時点に対応するURLを要求する、コンテンツストリームの履歴の中の時点に対応するセグメントに対して要求を解決する、および/またはセグメントに関連付けられたセグメントファイルを返すために使用され得る。いくつかの実施形態では、本明細書で説明される機構は、返されたコンテンツを再生する、および/または要求を反復的に出して履歴の中の所望の時点に近づくために使用され得る。したがって、いくつかの実施形態では、本明細書で説明される機構は、ライブストリームがすでに始まった後にユーザがライブストリームに参加する場合などに、ユーザがライブストリームの履歴部分を閲覧することを可能にすることができる。

いくつかの実施形態では、本明細書で説明される機構は、コンテンツを徐々にストリーミングするために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、まだ生成中であるセグメントに対してURLの要求を解決するおよび/またはそのセグメントのセグメントファイルの部分を反復的に返すために使用され得る。より具体的な例として、いくつかの実施形態では、本明細書で説明される機構は最初に、現在生成されているそのセグメントの一部分を返し、次いで、そのセグメントのデータの残りを、そのデータが生成されているものと同じ応答において徐々に返すために使用され得る。したがって、いくつかの実施形態では、本明細書で説明される機構は、大きいセグメントサイズという効率性の利益を有している間も、低いレイテンシでライブストリームが再生されることを可能にすることができる。

いくつかの実施形態では、本明細書で説明される機構は、コンピュータネットワークコンテンツストリーミングを改善するために使用され得る。たとえば、いくつかの実施形態では、本明細書で説明される機構は、各々がそのフォーマットについて動的に決定されたヘッドセグメントファイルを位置決めするコンテンツストリームのフォーマットごとに、ベースURLのセットを用いてプレイバックを初期化することによって、かつ通常であればマニフェストファイルに含まれることになるメタデータをセグメントファイルに埋め込むことによって、マニフェストファイルの定期的な配信を不要にすることができ、それによって、エンドツーエンドレイテンシを低減する。別の例として、本明細書で説明される機構は、ライブストリームの適応解像度プレイバックをサポートすることができ、ライブストリームの履歴部分のプレイバックを可能にすることができる。さらに別の例として、本明細書で説明される機構は、大きいセグメントサイズという効率性を伴う低いレイテンシでのプレイバックを可能にするために、1つ未満のセグメントのエンドツーエンドレイテンシでストリームを再生することをサポートすることができる。

マニフェストなしストリーミングメディアコンテンツを配信するためのこれらのおよび他の特徴が、図1〜図7に関連してさらに説明される。

図1を参照すると、開示される主題のいくつかの実施形態による、ストリーミングコンテンツを配信するための情報フロー図100の例示的な例が示されている。図示されているように、情報フロー図100のブロックは、図6および図7に示され、図6および図7に関連して以下で説明されるような1つもしくは複数のサーバ、1つもしくは複数のユーザデバイス、および/または任意の他の適切なコンピューティングデバイスなどの、1つまたは複数の適切なコンピューティングデバイスによって実行され得る。

102において、ユーザデバイスは、プレイバック用のURLを要求することができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、コンテンツストリームのプレイバック用のURLを要求することができる。いくつかの実施形態では、URLは、ウェブサーバによって提供され、ストリームのフォーマットに対応するベースURLと、シーケンス番号に対応する「sq」パラメータ、ヘッドセグメントの後ろのセグメントの番号に対応する「headm」パラメータ、および/または任意の他の適切なURLパラメータもしくは情報のうちの1つまたは複数とを含むことができる。以下で説明されるように、いくつかの実施形態では、ユーザデバイスは、たとえば、1つまたは複数のパラメータを要求されたベースURLにアペンドすることができる。

いくつかの実施形態では、コンテンツストリームはライブストリームであり得、1つまたは複数のフォーマット(たとえば、コーデックフォーマット、解像度フォーマット、オーディオフォーマット、ビデオフォーマット、および/または任意の他の適切なフォーマット)で提供され得ることに留意されたい。いくつかの実施形態では、ライブストリームはフォーマットごとに1つまたは複数のセグメントを含むことができ、各セグメントはそれぞれのシーケンス番号を有することができる。

いくつかの実施形態では、ユーザデバイスは、任意の適切なやり方で、プレイバック用のURLを要求することができる。いくつかの実施形態では、ユーザデバイスは、最適なプレイバック解像度、コンテンツストリームの履歴の中の指定された時点、および/または任意の他の適切な要因などの1つまたは複数の要因に基づいてURLを要求することができる。たとえば、いくつかの実施形態では、ユーザデバイスは、現在の利用可能なネットワーク帯域幅、ユーザデバイスのスクリーンサイズ、ユーザデバイスの現在の利用可能なハードウェアリソース、および/または任意の他の適切な基準のうちの1つまたは複数に基づいたインテリジェントプレイバック解像度選択を使用して、適切なフォーマットに対応するベースURLを自動的に要求することができる。追加または代替として、いくつかの実施形態では、ユーザデバイスは、履歴の中の指定された時点を探すことを容易にするために、「sq」パラメータ、「headm」パラメータ、および/または任意の他の適切なURLパラメータなどの1つまたは複数のパラメータを要求されたベースURLにアペンドすることができる。

104において、コンテンツ配信ネットワークは、ストリームの特定のセグメントに対してユーザデバイスからのURLの要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、URLの中に任意の追加のパラメータを含むベースURLなどの任意の適切な情報を使用して、シーケンス番号によって識別された特定のセグメントに対して要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、任意の適切なやり方で、特定のセグメントに対してURLの要求を解決することができる。

たとえば、図2を参照すると、開示される主題のいくつかの実施形態による、コンテンツストリームのセグメントに対してURLの要求を解決するためのプロセス200の例示的な例が示されている。図示されているように、プロセス200のブロックは、図6および図7に示され、図6および図7に関連して以下で説明されるような1つもしくは複数のサーバ、1つもしくは複数のユーザデバイス、および/または任意の他の適切なコンピューティングデバイスなどの、1つまたは複数の適切なコンピューティングデバイスによって実行され得る。いくつかの実施形態では、プロセス200のブロックは、図1のブロック104に関連して実施され得る。

202において、コンテンツ配信ネットワークは、任意の適切なやり方で、ユーザデバイスからのURLの要求を受信することができる。

204において、コンテンツ配信ネットワークは、URLに基づいて、要求に関連付けられたコンテンツストリームのフォーマットを識別することができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、要求されたURLからベースURLに関連付けられたフォーマットを識別することによって、コンテンツストリームの1つまたは複数の利用可能なフォーマットから要求されたフォーマットを判定することができる。

206において、コンテンツ配信ネットワークは、URLに基づいて、要求に関連付けられたシーケンス番号を識別することができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、現在のヘッドシーケンス番号を判定するためにヘッドシーケンス番号のキャッシュをクエリすることなどによって、ヘッドシーケンス番号(またはヘッドセグメントのためのシーケンス番号)に対してベースURLを解決することができる。追加または代替として、いくつかの実施形態では、コンテンツ配信ネットワークは、ヘッドシーケンス番号についてクエリをコンテンツストリームのオリジンサーバに送信することができ、オリジンサーバは、それに応答して、106などにおいて、現在のヘッドシーケンス番号を返すことができる。別の例として、いくつかの実施形態では、コンテンツ配信ネットワークは、URLに含まれる「headm」パラメータおよび/または「sq」パラメータに基づいて、要求に関連付けられたシーケンス番号を識別することができる。

208において、コンテンツ配信ネットワークは、要求に関連付けられたコンテンツストリームのセグメントを識別することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、ベースURLに関連付けられた識別されたフォーマットと一致するフォーマットを有し、かつ要求に関連付けられた識別されたシーケンス番号と一致するシーケンス番号を有するセグメントを識別することができる。

図1に戻って参照すると、108において、コンテンツ配信ネットワークは、要求においてシーケンス番号によって参照される識別されたセグメントに関連付けられたセグメントファイルをロードすることができる。いくつかの実施形態では、コンテンツ配信ネットワークは、任意の適切なやり方で、セグメントファイルをロードすることができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、1つもしくは複数のキャッシュおよび/または任意の他の適切なロケーションからセグメントファイルをロードすることができる。別の例として、いくつかの実施形態では、コンテンツ配信ネットワークは、セグメントファイルについてクエリをコンテンツストリームのオリジンサーバに送信することができ、オリジンサーバは、それに応答して、110などにおいて、要求されたセグメントファイルを返すことができる。いくつかの実施形態では、コンテンツ配信ネットワークは、オリジンサーバへの単一のクエリでヘッドシーケンス番号を解決することができ、ヘッドセグメントのコンテンツをロードすることができる。

いくつかの実施形態では、セグメントファイルは、オーディオコンテンツ、ビデオコンテンツ、ならびに/または任意の他の適切なコンテンツおよび/もしくはデータを含むことができる。いくつかの実施形態では、セグメントファイルは、オーディオまたはビデオコンテナフォーマット内に埋め込まれたアプリケーションレベルのメタデータを含むことができる。いくつかの実施形態では、メタデータは、メディアデコーダによって解釈されない情報を埋め込むためにコンテナフォーマットがサポートする機構を使用して、コンテナフォーマット内に埋め込まれ得る。たとえば、いくつかの実施形態では、コンテナフォーマットがFMP4であるとき、メタデータは「emsg」アトムに埋め込まれ得る。別の例として、いくつかの実施形態では、コンテナフォーマットがWebMであるとき、メタデータはタグ要素に埋め込まれ得る。いくつかの実施形態では、メタデータは任意の適切なコンテナフォーマットのための任意の適切な機構を使用して埋め込まれ得ることに留意されたい。

メタデータは任意の適切な情報を含むことができることにも留意されたい。たとえば、いくつかの実施形態では、メタデータはASCIIキー値ペアを含むことができる。より具体的な例として、いくつかの実施形態では、キー値ペアは「キー:値」の形態とすることができ、改行文字によって区切られ得る。なおより具体的な例として、いくつかの実施形態では、メタデータは、「sq」URLパラメータを使用することなどによって、セグメントファイルが位置決めされ得る、キー「Sequence-Number」とシーケンス番号に等しい値とのキー値ペアを含むことができる。いくつかの実施形態では、キー値ペアはHTTP応答ヘッダと同じ規則に従って符号化され得る。

112において、コンテンツ配信ネットワークは、任意の適切なやり方で、要求されたセグメントファイルをユーザデバイスに返すことができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、セグメントファイルをHTTP応答および/または任意の他の適切なタイプの応答として返すことができる。

114において、ユーザデバイスは、コンテンツ配信ネットワークからセグメントファイルを受信し、セグメントファイルをロードすることができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、プレイバックのためにセグメントファイルからビデオコンテンツおよび/またはオーディオコンテンツを抽出することができる。追加または代替として、プレイヤアプリケーションは、どのセグメントファイルがコンテンツ配信ネットワークによって返されたかを判定するために、セグメントファイルのメタデータからSequence-Numberキーの値を抽出することができる。いくつかの実施形態では、プレイヤアプリケーションは、ベースURLの要求に応答してまたは「headm」パラメータを使用してセグメントファイルをロードするときなど、プレイヤアプリケーションが不確定なシーケンス番号を有するセグメントファイルをロードするときに、どのセグメントファイルが返されたかを判定することができることに留意されたい。

図3を参照すると、開示される主題のいくつかの実施形態による、コンテンツストリームの一致するセグメントを配信するための情報フロー図の例示的な例が示されている。図示されているように、情報フロー図300のブロックは、図6および図7に示され、図6および図7に関連して以下で説明されるような1つもしくは複数のサーバ、1つもしくは複数のユーザデバイス、および/または任意の他の適切なコンピューティングデバイスなどの、1つまたは複数の適切なコンピューティングデバイスによって実行され得る。

302において、ユーザデバイスは、コンテンツ配信ネットワークから受信されたコンテンツストリームのセグメント間の不一致を検出することができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、各セグメントファイルのメタデータからSequence-Numberキーの値を抽出することなどによって、コンテンツ配信ネットワークから受信されたオーディオセグメントファイルのためのシーケンス番号とビデオセグメントファイルのためのシーケンス番号との間の不一致を検出することができる。ユーザデバイスは、任意の適切なやり方で、セグメント間の不一致を検出することができることに留意されたい。

304において、ユーザデバイスは、コンテンツストリームの次のセグメントのための1つまたは複数のURLを要求することができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、次のオーディオセグメントおよび/または次のビデオセグメントの各々について、1を加えたSequence-Numberキーの現在の値に設定された「sq」パラメータを含むベースURLを要求することができる。いくつかの実施形態では、プレイヤアプリケーションは、オーディオセグメントファイルのためのシーケンス番号とビデオセグメントファイルのためのシーケンス番号との間でより大きいシーケンス番号を判定することができ、プレイヤアプリケーションは、「sq」パラメータを、1を加えたより大きいシーケンス番号に設定することができることに留意されたい。ユーザデバイスは、任意の適切なやり方で、URLを要求することができることに留意されたい。

306において、コンテンツ配信ネットワークは、ユーザデバイスからの1つまたは複数のURLの1つまたは複数の要求を受信することができ、コンテンツストリームの次のセグメントに対して要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、図2に関連して上記で説明されたものなどの任意の適切なやり方で、ユーザデバイスからのURLの要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、要求が、ロードするのに利用可能な最新の(latest)セグメントのためのシーケンス番号よりも大きい値に設定された「sq」パラメータを含むと判定することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、次のセグメントについてオリジンサーバをクエリする前におよび/またはユーザデバイスからの要求に応答する前に、次のセグメントが生成されるのを所定の持続時間(たとえば、数秒および/または任意の適切な持続時間)待つことができる。

308において、コンテンツ配信ネットワークは、要求においてシーケンス番号によって参照されるセグメントに関連付けられたセグメントファイルをロードすることができる。いくつかの実施形態では、コンテンツ配信ネットワークは、セグメントファイルについてクエリをコンテンツストリームのオリジンサーバに送信することができ、オリジンサーバは、それに応答して、310などにおいて、要求されたセグメントファイルを返すことができる。いくつかの実施形態では、オリジンサーバは、コンテンツ配信ネットワークからの要求に応答する前に、次のセグメントが生成されるのを所定の持続時間(たとえば、数秒および/または任意の適切な持続時間)待つことができる。

312において、コンテンツ配信ネットワークは、任意の適切なやり方で、要求されたセグメントファイルをユーザデバイスに返すことができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、セグメントファイルをHTTP応答として返すことができる。

314において、ユーザデバイスは、任意の適切なやり方で、コンテンツ配信ネットワークからセグメントファイルを受信することができ、一致するシーケンス番号を有するセグメントファイルをロードすることができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、プレイバックのためにセグメントファイルからビデオコンテンツおよび/またはオーディオコンテンツを抽出することができる。

図4を参照すると、開示される主題のいくつかの実施形態による、コンテンツストリームの履歴の中の指定された時点のためのセグメントを配信するための情報フロー図の例示的な例が示されている。図示されているように、情報フロー図400のブロックは、図6および図7に示され、図6および図7に関連して以下で説明されるような1つもしくは複数のサーバ、1つもしくは複数のユーザデバイス、および/または任意の他の適切なコンピューティングデバイスなどの、1つまたは複数の適切なコンピューティングデバイスによって実行され得る。

402において、ユーザデバイスは、任意の適切なやり方で、コンテンツストリームの履歴の中の時点を探すための入力を検出することができる。たとえば、いくつかの実施形態では、プレイヤアプリケーションは、探すべき履歴の中の時点を指定するためにユーザがコンテンツストリームのタイムラインに対応する視覚表現の一部分を選択したことおよび/または任意の他の適切な入力を検出することができる。

いくつかの実施形態では、オリジンサーバは、コンテンツストリームごとに所定のほぼ一定のセグメント持続時間を使用することができ、したがって、2つのセグメント間の経過ストリーム時間の相対的な差は、コンテンツストリームの所定のセグメント持続時間を乗じたそれらのシーケンス番号値の差にほぼ等しいものであり得ることに留意されたい。たとえば、いくつかの実施形態では、3秒の所定のセグメント持続時間を前提とすると、コンテンツストリームの1番目のセグメントとコンテンツストリームの10番目のセグメントとの間の経過ストリーム時間は、(10×3秒)-(0×3秒)=30秒にほぼ等しいものであり得る。

404において、ユーザデバイスは、任意の適切なやり方で、コンテンツストリームの履歴の中の指定された時点に対応するセグメントのためのURLを要求することができる。たとえば、いくつかの実施形態では、プレイヤアプリケーションは、「sq」パラメータおよび/または任意の他の適切なURLパラメータを使用することなどによって、経過ストリーム時間がコンテンツストリームの履歴の中の指定された時点にほぼ等しいセグメントのためのURLを要求することができる。より具体的な例として、いくつかの実施形態では、3秒の所定のセグメント持続時間およびコンテンツストリームの中での30秒に対応する時点を探すためのユーザ要求を前提とすると、プレイヤアプリケーションは、10の値に設定された「sq」パラメータを使用することによって、10番目のセグメントのためのURLを要求することができる。

406において、コンテンツ配信ネットワークは、いくつかの実施形態では、要求において「sq」パラメータを使用してシーケンス番号によって識別されたものなどのストリームの特定のセグメントに対してユーザデバイスからのURLの要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、図2に関連して上記で説明されたものなどの任意の適切なやり方で、ユーザデバイスからのURLの要求を解決することができる。

408において、コンテンツ配信ネットワークは、要求においてシーケンス番号によって参照されるセグメントに関連付けられたセグメントファイルをロードすることができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、1つもしくは複数のキャッシュ、コンテンツストリームのオリジンサーバ、および/または任意の他の適切なロケーションからセグメントファイルをロードすることができる。

410において、コンテンツ配信ネットワークは、任意の適切なやり方で、要求されたセグメントファイルをユーザデバイスに返すことができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、セグメントファイルをHTTP応答および/または任意の他の適切なタイプの応答として返すことができる。加えて、いくつかの実施形態では、コンテンツ配信ネットワークは、現在のヘッドシーケンス番号、正確な現在の経過ストリーム時間、および/または任意の他の適切な情報を識別するHTTP応答ヘッダを返すことができる。

412において、ユーザデバイスは、コンテンツ配信ネットワークからセグメントファイルを受信し、セグメントファイルをロードすることができる。たとえば、いくつかの実施形態では、プレイヤアプリケーションは、セグメントファイルのメタデータからSequence-Numberキーの値を抽出することによってまたは任意の他の適切なやり方などで、どのセグメントファイルがコンテンツ配信ネットワークによって返されたかおよび/またはシーケンスファイルの経過ストリーム時間を判定することができる。

414において、ユーザデバイスは、返されたセグメントファイルの経過ストリーム時間に基づいて、返されたセグメントファイルを再生するかどうかを判定することができる。たとえば、いくつかの実施形態では、プレイヤアプリケーションは、返されたセグメントの経過ストリーム時間を、コンテンツストリームの履歴の中の指定された時点と比較することができる。返されたセグメントの経過ストリーム時間がコンテンツストリームの履歴の中の指定された時点と一致するとプレイヤアプリケーションが判定した場合、いくつかの実施形態では、プレイヤアプリケーションは、416において、返されたセグメントファイルのコンテンツを再生することができる。返されたセグメントの経過ストリーム時間がコンテンツストリームの履歴の中の指定された時点と一致しないとプレイヤアプリケーションが判定した場合、いくつかの実施形態では、プレイヤアプリケーションは、416において、返されたセグメントファイルの経過ストリーム時間からコンテンツを再生し続けることができるか、またはプレイヤアプリケーションは、要求を反復的に出して所望の経過ストリーム時間に近づくために404に戻ることができる。

いくつかの実施形態では、ユーザデバイスは、416においてコンテンツを再生するときに、410において返された応答ヘッダからの情報を使用することができることに留意されたい。たとえば、いくつかの実施形態では、プレイヤアプリケーションは、プレイヤアプリケーションがコンテンツストリームの履歴部分を再生している間でも、新たに生成されたセグメントを含むタイムラインの視覚表現を延長するために現在のヘッドシーケンス番号および/または正確な現在の経過ストリーム時間を使用することができる。

図5を参照すると、開示される主題のいくつかの実施形態による、インクリメンタルストリーミングのための情報フロー図の例示的な例が示されている。図示されているように、情報フロー図500のブロックは、図6および図7に示され、図6および図7に関連して以下で説明されるような1つもしくは複数のサーバ、1つもしくは複数のユーザデバイス、および/または任意の他の適切なコンピューティングデバイスなどの、1つまたは複数の適切なコンピューティングデバイスによって実行され得る。

502において、ユーザデバイスは、プレイバック用のURLを要求することができる。たとえば、いくつかの実施形態では、ユーザデバイス上で実行されているプレイヤアプリケーションは、ベースURL、0の値に設定された「headm」パラメータ、および/またはまだ生成中であるセグメントのためのシーケンス番号に設定された「sq」パラメータを含むURLを要求することができる。

504において、コンテンツ配信ネットワークは、任意の適切なやり方で、まだ生成中であるセグメントに対してユーザデバイスからのURLの要求を解決することができる。いくつかの実施形態では、コンテンツ配信ネットワークは、図2に関連して上記で説明されたものなどの任意の適切なやり方で、ユーザデバイスからのURLの要求を解決することができる。

506において、コンテンツ配信ネットワークは、任意の適切なやり方で、要求されたセグメントのためのセグメントファイルの部分をロードすることができる。たとえば、いくつかの実施形態では、コンテンツ配信ネットワークは、要求されたセグメントファイルの1つまたは複数の部分についてコンテンツストリームのオリジンサーバをクエリすることができる。

508において、オリジンサーバは、まだ生成中であるセグメントの要求を受信することができ、セグメントの部分が生成されているときにそれらの部分を徐々に返すことができる。たとえば、いくつかの実施形態では、オリジンサーバは最初に、現在生成されているセグメントの一部分をコンテンツ配信ネットワークに返し、次いで、510において、そのセグメントのデータの残りを、データが生成され続けているものと同じ応答において徐々に返すことができる。

いくつかの実施形態では、オリジンサーバおよび/またはコンテンツ配信ネットワークは、不確定なバイト長を有する応答を返すことを可能にする応答エンコーディングを使用してセグメントの生成された部分を返すことができることに留意されたい。たとえば、いくつかの実施形態では、オリジンサーバおよび/またはコンテンツ配信ネットワークは、HTTPプロトコルを使用するときにHTTP応答ヘッダ「transfer-encoding: chunked」によって識別されたものなどのチャンク転送エンコーディングを使用して応答することができる。加えて、いくつかの実施形態では、応答は、インクリメンタルストリーミングをサポートするコンテナフォーマットを使用することができる。たとえば、いくつかの実施形態では、コンテナフォーマットは、オーディオおよび/またはビデオのフレームごとに1つの「moof」アトムを含むことができる。

512において、コンテンツ配信ネットワークは、単一の応答においてセグメントの1つまたは複数の部分がオリジンサーバから受信されるときに、それらの部分をユーザデバイスに返すことができる。

514において、ユーザデバイスは、コンテンツ配信ネットワークからセグメントの部分を受信し、ロードすることができる。

図6を参照すると、開示される主題のいくつかの実施形態に従って使用され得るストリーミングコンテンツを配信するためのハードウェア600の一例が示されている。図示されているように、ハードウェア600は、オリジンサーバ602、サーバ606およびサーバ608などの1つもしくは複数のサーバを含むコンテンツ配信ネットワーク604、通信ネットワーク610、ユーザデバイス614およびユーザデバイス616などの1つもしくは複数のユーザデバイス612、ならびに/またはウェブサーバ618を含むことができる。

オリジンサーバ602は、情報、データ、プログラム、および/または、ストリーミングコンテンツを配信するための任意の他の適切なタイプのコンテンツを記憶するための任意の適切なサーバであり得る。いくつかの実施形態では、オリジンサーバ602は、コンテンツストリームのフォーマットごとに1つまたは複数のセグメントファイルを記憶することができる。いくつかの実施形態では、オリジンサーバ602は、ライブストリームのヘッドセグメントのための現在のヘッドシーケンス番号を記憶することができる。いくつかの実施形態では、オリジンサーバ602は、任意の他の適切なコンテンツまたは情報を記憶することができる。いくつかの実施形態では、オリジンサーバ602は、図1および図3〜図5に関連して上記で説明されたように、ヘッドシーケンス番号を返す、1つもしくは複数のセグメントファイルを返す、および/または、1つもしくは複数のセグメントの1つもしくは複数の部分が生成されるときにそれらの部分を徐々に返すなどの任意の適切な機能を実施することができる。

コンテンツ配信ネットワーク604は、情報、データ、プログラム、および/または、ストリーミングコンテンツを配信するための任意の他の適切なタイプのコンテンツを記憶するための任意の適切なネットワークであり得る。いくつかの実施形態では、本明細書で説明されるようなコンテンツ配信ネットワークは、情報、データ、プログラム、および/または任意の他の適切なタイプのコンテンツを記憶するための任意の適切なサーバであり得る、サーバ606および/またはサーバ608などの1つまたは複数の適切なコンピューティングデバイスによって実装され得ることに留意されたい。たとえば、いくつかの実施形態では、サーバ606および/またはサーバ608は、コンテンツストリームの1つまたは複数のフォーマットのための1つまたは複数のセグメントファイルを記憶することができる。加えて、いくつかの実施形態では、サーバ606および/またはサーバ608は、1つまたは複数のキャッシュなどに、ライブストリームのための1つまたは複数のヘッドシーケンス番号を記憶することができる。いくつかの実施形態では、オリジンサーバ602は、図1〜図5に関連して上記で説明されたように、URLの要求を受信する、コンテンツストリームのセグメントに対して要求を解決する、フォーマットを識別する、シーケンス番号を識別する、セグメントを識別する、セグメントファイルをロードする、1つもしくは複数のセグメントファイルを返す、および/または、1つもしくは複数のセグメントの1つもしくは複数の部分が生成されるときにそれらの部分を徐々に返すなどの任意の適切な機能を実施することができる。

通信ネットワーク610は、いくつかの実施形態では、1つまたは複数のワイヤードおよび/またはワイヤレスネットワークの任意の適切な組合せであり得る。たとえば、通信ネットワーク610は、インターネット、イントラネット、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、ワイヤレスネットワーク、デジタル加入者回線(DSL)ネットワーク、フレームリレーネットワーク、非同期転送モード(ATM)ネットワーク、仮想プライベートネットワーク(VPN)、および/または任意の他の適切な通信ネットワークのうちのいずれか1つまたは複数を含むことができる。いくつかの実施形態では、オリジンサーバ602は、1つまたは複数の通信リンクによって、コンテンツ配信ネットワーク604を介して通信ネットワーク610に接続され得る。いくつかの実施形態では、通信ネットワーク610は、1つまたは複数の通信リンクを介してコンテンツ配信ネットワーク604、ユーザデバイス612、および/またはウェブサーバ618にリンクされ得る。通信リンクは、ネットワークリンク、ダイヤルアップリンク、ワイヤレスリンク、ハードワイヤードリンク、任意の他の適切な通信リンク、またはそのようなリンクの任意の適切な組合せなどの、ユーザデバイス612、オリジンサーバ602、コンテンツ配信ネットワーク604、およびウェブサーバ618の間でデータを通信するのに適した任意の通信リンクであり得る。

ウェブサーバ618は、情報、データ、プログラム、および/または任意の他の適切なタイプのコンテンツを記憶するための任意の適切なサーバであり得る。いくつかの実施形態では、ウェブサーバ618は、図1〜図5に関連して上記で説明されたように、コンテンツストリームの1つまたは複数のフォーマットのための1つまたは複数のベースURLを提供するなどの任意の適切な機能を実施することができる。

ユーザデバイス612は、ストリーミングコンテンツを提示するための任意の1つまたは複数のユーザデバイスを含むことができる。たとえば、いくつかの実施形態では、ユーザデバイス612は、テレビジョン、スピーカ、モバイルフォン、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、車両エンターテインメントシステム、ウェアラブルコンピュータ、および/または任意の他の適切なタイプのユーザデバイスを含むことができる。いくつかの実施形態では、ユーザデバイス612は、メモリに記憶され、ストリーミングコンテンツを提示するためにユーザデバイス612によって実行されるプレイヤアプリケーションを含むことができる。いくつかの実施形態では、ユーザデバイス612は、図1〜図5に関連して上記で説明されたように、プレイバック用のURLを要求する、ストリームの一致しないセグメントを検出する、ストリームの履歴の中の時点を探すための入力を検出する、受信されたセグメントファイルをロードする、および/またはコンテンツを再生するなどの任意の適切な機能を実施することができる。

オリジンサーバ602、サーバ606、サーバ608、およびウェブサーバ618はそれぞれ、1つのデバイスとして図示されているが、オリジンサーバ602、サーバ606、サーバ608、およびウェブサーバ618によって実施される機能は、いくつかの実施形態では、任意の適切な数のデバイスを使用して実施され得る。たとえば、いくつかの実施形態では、オリジンサーバ602、サーバ606、サーバ608、およびウェブサーバ618の各々によって実施される機能を実装するために複数のデバイスが使用され得る。

図を過度に複雑にすることを回避するために2つのユーザデバイス614および616が図6に示されているが、いくつかの実施形態では、任意の適切な数のユーザデバイス、および/または任意の適切なタイプのユーザデバイスが使用され得る。

オリジンサーバ602、サーバ606、サーバ608、ユーザデバイス612、およびウェブサーバ618は、いくつかの実施形態では、任意の適切なハードウェアを使用して実装され得る。たとえば、いくつかの実施形態では、デバイス602、606、608、612、および618は、任意の適切な汎用コンピュータまたは専用コンピュータを使用して実装され得る。たとえば、モバイルフォンは、専用コンピュータを使用して実装されてもよい。任意のそのような汎用コンピュータまたは専用コンピュータは、任意の適切なハードウェアを含むことができる。たとえば、図7の例示的なハードウェア700に図示されているように、そのようなハードウェアは、ハードウェアプロセッサ702と、メモリおよび/またはストレージ704と、入力デバイスコントローラ706と、入力デバイス708と、ディスプレイ/オーディオドライバ710と、ディスプレイおよびオーディオ出力回路712と、通信インターフェース714と、アンテナ716と、バス718とを含むことができる。

ハードウェアプロセッサ702は、いくつかの実施形態では、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、専用論理、および/または、汎用コンピュータもしくは専用コンピュータの機能を制御するための任意の他の適切な回路などの任意の適切なハードウェアプロセッサを含むことができる。いくつかの実施形態では、ハードウェアプロセッサ702は、サーバ606および/またはサーバ608などのサーバのメモリおよび/またはストレージに記憶されたサーバプログラムによって制御され得る。たとえば、いくつかの実施形態では、サーバプログラムは、ハードウェアプロセッサ702に、URLの要求を受信すること、コンテンツストリームのセグメントに対して要求を解決すること、フォーマットを識別すること、シーケンス番号を識別すること、セグメントを識別すること、ヘッドシーケンス番号を返すこと、セグメントファイルロードすること、1つもしくは複数のセグメントファイルを返すこと、1つもしくは複数のセグメントの1つもしくは複数の部分が生成されるときにそれらの部分を徐々に返すこと、コンテンツストリームの1つもしくは複数のフォーマットのための1つもしくは複数のベースURLを提供すること、および/または任意の他の適切な機能を実施することを行わせることができる。いくつかの実施形態では、ハードウェアプロセッサ702は、ユーザデバイス612および/またはユーザデバイス616などのユーザデバイスのメモリおよび/またはストレージに記憶されたプログラムによって制御され得る。たとえば、いくつかの実施形態では、プログラムは、ハードウェアプロセッサ702に、プレイバック用のURLを要求すること、ストリームの一致しないセグメントを検出すること、ストリームの履歴の中の時点を探すための入力を検出すること、受信されたセグメントファイルをロードすること、コンテンツを再生すること、および/または任意の他の適切な機能を実施することを行わせることができる。

メモリおよび/またはストレージ704は、いくつかの実施形態では、プログラム、データ、および/または任意の他の適切な情報を記憶するための任意の適切なメモリおよび/またはストレージであり得る。たとえば、メモリおよび/またはストレージ704は、ランダムアクセスメモリ、読取り専用メモリ、フラッシュメモリ、ハードディスクストレージ、光媒体、および/または任意の他の適切なメモリを含むことができる。

入力デバイスコントローラ706は、いくつかの実施形態では、1つまたは複数の入力デバイス708からの入力を制御し、受信するための任意の適切な回路であり得る。たとえば、入力デバイスコントローラ706は、タッチスクリーンからの、キーボードからの、1つもしくは複数のボタンからの、音声認識回路からの、マイクロフォンからの、カメラからの、光センサからの、加速度計からの、温度センサからの、近接場センサからの、圧力センサからの、エンコーダからの、および/または任意の他のタイプの入力デバイスからの入力を受信するための回路であり得る。

ディスプレイ/オーディオドライバ710は、いくつかの実施形態では、1つまたは複数のディスプレイ/オーディオ出力デバイス712への出力を制御し、駆動するための任意の適切な回路であり得る。たとえば、ディスプレイ/オーディオドライバ710は、タッチスクリーン、フラットパネルディスプレイ、陰極線管ディスプレイ、プロジェクタ、1つもしくは複数のスピーカ、ならびに/または任意の他の適切なディスプレイおよび/もしくは提示デバイスを駆動するための回路であり得る。

通信インターフェース714は、1つまたは複数の通信ネットワーク(たとえば、通信ネットワーク610)とインターフェースするための任意の適切な回路であり得る。たとえば、インターフェース714は、ネットワークインターフェースカード回路、ワイヤレス通信回路、および/または任意の他の適切なタイプの通信ネットワーク回路を含むことができる。

アンテナ716は、いくつかの実施形態では、通信ネットワーク(たとえば、通信ネットワーク610)とワイヤレス通信するための任意の適切な1つまたは複数のアンテナであり得る。いくつかの実施形態では、アンテナ716は省略され得る。

バス718は、いくつかの実施形態では、2つ以上の構成要素702、704、706、710、および714の間で通信するための任意の適切な機構であり得る。

任意の他の適切な構成要素は、いくつかの実施形態によれば、ハードウェア700に含まれ得る。

いくつかの実施形態では、図1〜図5のプロセスの上記で説明されたブロックのうちの少なくともいくつかは、図に示され、図に関連して説明される順序およびシーケンスに限定されない、任意の順序またはシーケンスで実行または実施され得る。また、図1〜図5の上記のブロックのうちのいくつかは、レイテンシおよび処理時間を低減するために、適切な場合には実質的に同時にまたは並行して実行または実施され得る。追加または代替として、図1〜図5のプロセスの上記で説明されたブロックのうちのいくつかは省略され得る。

いくつかの実施形態では、任意の適切なコンピュータ可読媒体は、本明細書の機能および/またはプロセスを実施するための命令を記憶するために使用され得る。たとえば、いくつかの実施形態では、コンピュータ可読媒体は一時的または非一時的であり得る。たとえば、非一時的コンピュータ可読媒体は、非一時的な形態の磁気媒体(ハードディスク、フロッピーディスク、および/または任意の他の適切な磁気媒体など)、非一時的な形態の光媒体(コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、および/または任意の他の適切な光媒体など)、非一時的な形態の半導体媒体(フラッシュメモリ、電気的プログラマブル読取り専用メモリ(EPROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、および/または任意の他の適切な半導体媒体など)、一過性ではないかもしくは送信中に何らかの永続性の外観を欠いていない任意の適切な媒体、および/または任意の適切な有形媒体などの媒体を含むことができる。別の例として、一時的コンピュータ可読媒体は、ネットワーク上の、ワイヤ、導体、光ファイバ、回路、一過性であり送信中に何らかの永続性の外観を欠いている任意の適切な媒体、および/または任意の適切な非有形媒体における信号を含むことができる。

したがって、マニフェストなしストリーミングメディアコンテンツを配信するための方法、システム、および媒体が提供される。

本発明が上記の例示的な実施形態において説明および図示されてきたが、本開示は単に例として行われたものであり、本発明の実装形態の詳細の多数の変更は、以下の特許請求の範囲によってのみ限定される本発明の趣旨および範囲から逸脱することなしに行われ得ることを理解されたい。開示される実施形態の特徴は、様々な方法で組み合わされ、並べ替えられ得る。

100 情報フロー図
200 プロセス
300 情報フロー図
400 情報フロー図
500 情報フロー図
602 オリジンサーバ、デバイス
604 コンテンツ配信ネットワーク
606 サーバ、デバイス
608 サーバ、デバイス
610 通信ネットワーク
612 ユーザデバイス、デバイス
614 ユーザデバイス
616 ユーザデバイス
618 ウェブサーバ、デバイス
700 ハードウェア
702 ハードウェアプロセッサ、構成要素
704 メモリおよび/またはストレージ、構成要素
706 入力デバイスコントローラ、構成要素
708 入力デバイス
710 ディスプレイ/オーディオドライバ、構成要素
712 ディスプレイおよびオーディオ出力回路、ディスプレイ/オーディオ出力デバイス
714 通信インターフェース、インターフェース、構成要素
716 アンテナ
718 バス

Claims (18)

1. ライブストリーミングコンテンツを配信するための方法であって、
   ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するステップであって、
   前記ライブストリームが、前記複数のフォーマットの各々のための複数のセグメントを含み、
   前記複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ステップと、
   前記要求されたURLに基づいて、前記ライブストリームの特定のセグメントに対して前記要求を解決するステップであって、前記解決するステップが、
   前記要求されたURLに基づいて、前記複数のフォーマットから前記要求に関連付けられた前記ライブストリームの前記フォーマットを識別するステップと、
   前記要求されたURLに基づいて、前記要求に関連付けられたシーケンス番号を識別するステップと、
   前記識別されたフォーマットに対応し、前記識別されたシーケンス番号と一致するシーケンス番号を有する、前記複数のセグメントのうちのセグメントを識別するステップと
   を含む、ステップと、
   前記特定のセグメントに対応するセグメントファイルをロードするステップと、
   前記要求に対する応答において、前記セグメントファイルを前記ユーザデバイスに返すステップと
   を含む方法。
2. 前記URLがベースURLを含み、
   前記要求に関連付けられた前記ライブストリームの前記フォーマットが、前記ベースURLに基づいて前記複数のフォーマットから識別される、請求項1に記載の方法。
3. 前記セグメントファイルが、前記識別されたシーケンス番号を示すメタデータを含む、請求項1または2に記載の方法。
4. 前記シーケンス番号が、前記1つまたは複数のセグメントのプレイバックに利用可能な最も最近のセグメントのための現在のヘッドシーケンス番号を判定することによって識別され、
   前記識別されたシーケンス番号が、前記現在のヘッドシーケンス番号であり、
   前記識別されたセグメントが、プレイバックに利用可能な前記最も最近のセグメントである、請求項1、2または3に記載の方法。
5. 前記シーケンス番号が、前記URLに基づいて、ロードするのに利用可能な最も最近完成したセグメントのためのシーケンス番号よりも大きい、前記要求に関連付けられたシーケンス番号を識別することによって識別される、請求項1、2または3に記載の方法。
6. 前記セグメントファイルの1つまたは複数の部分が生成されているときに前記1つまたは複数の部分を反復的にロードするステップと、
   単一の応答において、前記生成された1つまたは複数の部分を前記ユーザデバイスに反復的に返すステップと
   をさらに含む、請求項5に記載の方法。
7. ライブストリーミングコンテンツを配信するためのシステムであって、
   メモリと、
   前記メモリに結合されたハードウェアプロセッサと
   を備え、前記ハードウェアプロセッサが、
   ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信することであって、
   前記ライブストリームが、前記複数のフォーマットの各々のための複数のセグメントを含み、
   前記複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、受信することと、
   前記要求されたURLに基づいて、前記ライブストリームの特定のセグメントに対して前記要求を解決することであって、前記解決することが、
   前記要求されたURLに基づいて、前記複数のフォーマットから前記要求に関連付けられた前記ライブストリームの前記フォーマットを識別することと、
   前記要求されたURLに基づいて、前記要求に関連付けられたシーケンス番号を識別することと、
   前記識別されたフォーマットに対応し、前記識別されたシーケンス番号と一致するシーケンス番号を有する、前記複数のセグメントのうちのセグメントを識別することと
   を含む、解決することと、
   前記特定のセグメントに対応するセグメントファイルをロードすることと、
   前記要求に対する応答において、前記セグメントファイルを前記ユーザデバイスに返すことと
   を行うように構成される、システム。
8. 前記URLがベースURLを含み、
   前記要求に関連付けられた前記ライブストリームの前記フォーマットが、前記ベースURLに基づいて前記複数のフォーマットから識別される、請求項7に記載のシステム。
9. 前記セグメントファイルが、前記識別されたシーケンス番号を示すメタデータを含む、請求項7または8に記載のシステム。
10. 前記シーケンス番号が、前記1つまたは複数のセグメントのプレイバックに利用可能な最も最近のセグメントのための現在のヘッドシーケンス番号を判定することによって識別され、
    前記識別されたシーケンス番号が、前記現在のヘッドシーケンス番号であり、前記識別されたセグメントが、プレイバックに利用可能な前記最も最近のセグメントである、請求項7、8または9に記載のシステム。
11. 前記シーケンス番号が、前記URLに基づいて、ロードするのに利用可能な最も最近完成したセグメントのためのシーケンス番号よりも大きい、前記要求に関連付けられたシーケンス番号を識別することによって識別される、請求項7、8または9に記載のシステム。
12. 前記ハードウェアプロセッサが、
    前記セグメントファイルの1つまたは複数の部分が生成されているときに前記1つまたは複数の部分を反復的にロードし、
    単一の応答において、前記生成された1つまたは複数の部分を前記ユーザデバイスに反復的に返す
    ようにさらに構成される、請求項11に記載のシステム。
13. プロセッサによって実行されると、ライブストリーミングコンテンツを配信するための方法を前記プロセッサに実施させるコンピュータ実行可能命令を記憶したコンピュータ可読記録媒体であって、前記方法が、
    ユーザデバイスから、複数のフォーマットで提供されるライブストリームのフォーマットに対応するURLの要求を受信するステップであって、
    前記ライブストリームが、前記複数のフォーマットの各々のための複数のセグメントを含み、
    前記複数のセグメントのうちの各セグメントが、それぞれのシーケンス番号を含む、ステップと、
    前記要求されたURLに基づいて、前記ライブストリームの特定のセグメントに対して前記要求を解決するステップであって、前記解決するステップが、
    前記要求されたURLに基づいて、前記複数のフォーマットから前記要求に関連付けられた前記ライブストリームの前記フォーマットを識別するステップと、
    前記要求されたURLに基づいて、前記要求に関連付けられたシーケンス番号を識別するステップと、
    前記識別されたフォーマットに対応し、前記識別されたシーケンス番号と一致するシーケンス番号を有する、前記複数のセグメントのうちのセグメントを識別するステップと
    を含む、ステップと、
    前記特定のセグメントに対応するセグメントファイルをロードするステップと、
    前記要求に対する応答において、前記セグメントファイルを前記ユーザデバイスに返すステップと
    を含む、コンピュータ可読記録媒体。
14. 前記URLがベースURLを含み、前記要求に関連付けられた前記ライブストリームの前記フォーマットが、前記ベースURLに基づいて前記複数のフォーマットから識別される、請求項13に記載のコンピュータ可読記録媒体。
15. 前記セグメントファイルが、前記識別されたシーケンス番号を示すメタデータを含む、請求項13または14に記載のコンピュータ可読記録媒体。
16. 前記シーケンス番号が、前記1つまたは複数のセグメントのプレイバックに利用可能な最も最近のセグメントのための現在のヘッドシーケンス番号を判定することによって識別され、
    前記識別されたシーケンス番号が、前記現在のヘッドシーケンス番号であり、前記識別されたセグメントが、プレイバックに利用可能な前記最も最近のセグメントである、請求項13、14または15に記載のコンピュータ可読記録媒体。
17. 前記シーケンス番号が、前記URLに基づいて、ロードするのに利用可能な最も最近完成したセグメントのためのシーケンス番号よりも大きい、前記要求に関連付けられたシーケンス番号を識別することによって識別される、請求項13、14または15に記載のコンピュータ可読記録媒体。
18. 前記方法が、
    前記セグメントファイルの1つまたは複数の部分が生成されているときに前記1つまたは複数の部分を反復的にロードするステップと、
    単一の応答において、前記生成された1つまたは複数の部分を前記ユーザデバイスに反復的に返すステップと
    をさらに含む、請求項17に記載のコンピュータ可読記録媒体。

Images